Ethernet technology has been widely accepted on the factory floor, but whether it will migrate to the sensor level is still under debate.

THE FUTURE OF
SENSOR
NETWORKS

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 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.

Figure 1. The data content of sensor networks increases as the devices connected to them grow in sophistication. But to accommodate applications that range from the simple to the complex, the data packets vary in length from a single bit to many bytes.

A number of bit-oriented industrial networks (e.g., ASI, DeviceNet, Interbus-S, and Bitbus) service low-level devices. At first, these sensor networks operated at simple levels, but with time, they added devices with more complexity and features that enhanced interoperability and intelligence. For example, the microprocessor in a chip embedded in a limit switch provides not only the on/off status but total cycles and device information.

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.

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.

Home | About Us | Site Index | Privacy Policy © 2006 Questex Media Group, Inc.. All rights reserved. Reproduction in whole or in part is prohibited. Please send any technical comments or questions to our webmaster.