From thermostats in building automation to computer numerical controls in factory automation, device and sensor information is traveling over the same technology that is powering our e-world. But how well is it working, and where is the trend taking us?
Mark Fondl, ICT and Lynn Linse, Lantronix, Inc.
The volume of data carried on a network increases as the devices on it become more sophisticated. Low-end devices may transmit data in 1 bit increments, indicating a simple on/off condition. High-end sensors, on the other hand, contain local intelligence and transmit complex data types measured in bytes (see Figure 1.)
To meet the need for more complex data communications, the industry has looked to other networks. In the process, many have asked: Can Ethernet/TCP/IP be used to replace some of these networks? Can some of the networks be integrated into higher level Ethernet architectures (e.g., DeviceNet over Ethernet, Interbus-S over Ethernet, LonWorks over Ethernet)? Some of the answers to these questions can be found in an examination of implementation costs, ease of use, performance, and vendor support.
Implemention Costs
Ethernet costs are not inherently lower than the other networks. For the foreseeable future, cost can be justified only by concentrating multiple sensors on one Ethernet interface.
Other factors contributing to the cost of implementation are the CPU resources. Here, Ethernet does not compare favorably with an architecture such as DeviceNet. For example, DeviceNet can run on a CPU with 4000 bytes of code and 176 bytes of RAM. Ethernet, though, requires a minimum of 64,000 bytes of code and 64,000 bytes of RAM. Here, many implementers insist the minimum is more like 256 KB each, but they would prefer 2–4 MB of code and RAM. If the volumes are low and the margins are high, the simpler software offsets Ethernet’s greater CPU requirements. But as volumes rise and margins shrink, the lower resource needs of something like DeviceNet will force a price premium for Ethernet with the same sales volumes.
Consideration of connection costs—especially for bit-level sensors in industrial environments—causes some to favor ASI and DeviceNet wiring. Optimized for machines in which many discrete sensors are located in a relatively small area (50 m), these sensor networks are ideal. But extending their range poses some difficulty, and based on response times of these clusters, bridging with Ethernet may provide value.
Ease of Use
Here the focus is on long-term support of software configuration. This has multiple facets:
TCP/IP ease of use is based on the wide availability of skilled technicians and tools.
But TCP/IP (at the moment) lacks the high-level standards that allow auto-replacement, which is supported in DeviceNet and ASI.
The complexity of the options found in TCP/IP can overwhelm inexperienced users.
Systems such as DeviceNet and ASI are well suited for applications in which the communications are kept on a local scale. But when the data travel into extended areas and applications in which specialized network skills are required, then a commercial TCû/IP network becomes attractive. Network evaluation can be as simple as a “ping” from almost any computer. Commercial technologies aimed at simple diagnostics will eventually become common. Training individuals to support TCP/IP will be much easier. Device networks feeling this pressure will undoubtedly develop simpler and even browser-based tools.
Performance
With a well-designed network, TCP/IP will perform quite well. But the network must be well designed. An isolated subnet with limited or master/slave functions can expect reliable 2–5 ms times. But the instant you add routers or other noncontrol traffic (including Web servers), you can expect delays of 500 ms or more. So Ethernet performs only as well as the user designs it to perform.
A sparsely designed Ethernet, which underuses its capacity, can rival or beat any deterministic control network. But a poorly designed Ethernet can be an operational nightmare.
Web access via TCP/IP is a common unrealistic hope. With control traffic running at 5–10,000 Bps, users often overlook the fact that a Web page can attempt to force millions of bytes of data through a network at the same time that control data are being transmitted, dwarfing the control traffic. Users and vendors still have to learn the tradeoffs here. Some Web access is wonderful, but this needs to be shared/supplemented with Web resources stored off the control network.
To improve performance on the sensor level, automation companies are experimenting with UDP and variations of limited TCP/IP stacks. These stacks listen only to certain types of transmissions, ignoring others and eliminating a retry structure for a high-speed master-slave structure. This is similar to how I/O has worked for years with PLCs. The architecture and wiring are Ethernet, but the openness is traded for performance.
Most systems don’t need this level of performance and should stay with standard Ethernet. As the technology continues to improve, you can imagine a time when a conventional approach will surpass proprietary methods.
Service and Support
Support for Ethernet TCP/IP systems is good, but the actual media (e.g., cables, connectors, and power) are rather unindustrial. Many TCP/IP experts have an IT mentality, not a plant-floor mindset, so they misunderstand what users want or modify existing systems in ways that hurt the industrial user in an effort to improve the system according to other criteria.
«o users still need to learn about the technology and watch over the shoulders of the experts. Ask questions, and make sure the IT experts learn how you view the problem.
Openness
Ethernet TCP/IP systems provide an open network platform, but high-level application standards are still in flux. TCP/IP is often viewed as a false open standard because its higher layers are proprietary. Modbus/TCP and some of the new encapsulations of òeviceNet, Foundation Fieldbus, and Profibus will help in this area by providing interfaces that will allow different protocols to communicate with each other. But that still leaves a lot of application standards that are not interoperable.
Many of these network architectures encapsulate other protocols, but the interoperability does not extend to the physical and transport layers. This prevents the various buses from communicating with each other. So there is still a great deal of work to be done in this area.
Flexibility
Just about anything is possible with global TCP/IP, but the reliability of its performance depends on the skill of the implementer. However, there is still a need for a more industrial and optimized sensor bus.
As data requirements increase, hybrid and direct Ethernet systems will become commonplace. High-level sensors with serial ports are already being linked over Ethernet. The protocols are transported transparently on top of TCP/IP and delivered to a host, which in some cases is unaware that they were carried over a LAN.
Posts
