Signal Processing Drives Network Design

By Dan Hebert, PE, Senior Technical Editor

With its ability to transmit large amounts of information quickly, a digital network enables remote signal processing and control via intelligent I/O. But remote I/O doesn't make sense in all cases because it's sometimes better to bring raw signals directly from sensors and dumb instruments to local I/O for centralized signal processing and control.

In the early days of remote I/O, a remote terminal unit (RTU) acted as a simple data concentrator. An RTU at a remote location gathered inputs from multiple sensors and instruments, packaged the data points in a "data frame," and transmitted the frame to a central location via a proprietary, low-performance data network.

Today's remote smart I/O does much more than just gather, condense and transmit data—and much of its increased capability is enabled by modern, high-speed, two-way digital networks. Smart I/O now performs many signal processing and control functions right at the I/O module, including real-time control. Typical signal processing functions include filtering, high-speed counting, thermocouple linearization and more.

But smart remote I/O costs much more than local rack-mounted I/O—and networking this remote I/O back to a centralized controller also can add complexity, cost and overhead. Is it worth the trouble?

Remote vs. Centralized I/O

Lantech (www.lantech.com), a packaging machine builder (Figure 1) in Louisville, Ky., uses both local hardwired I/O and networked remote I/O in its products, says Derek Jones, senior marketing product manager. The decision is based on the machine and the customer's environment. Sometimes the choice is obvious.

"Our Ring Straddle shrink-wrapping machine has an elevator that carries a roll carriage up and down around a package," Jones explains. "The elevator has 64 inputs and 16 outputs, and the I/O must be wired with flex-rated cable. The long, large bundle of expensive flexible wiring is replaced by remote I/O with a single flexible communication and power cable. The cost savings in wiring and labor from fewer cables makes this a clear choice in favor of remote I/O." See the sidebar, "The Decision Process," for a look at how Lantech decides what to use.

"Wiring and installation costs for retrieving individual instrument signals from a remote unit are reduced considerably if you can concentrate them at a location within the unit rather than having to wire all of them back," advises Richard McCormick, automation engineer with system integrator Mick Automation in Levis, Quebec, who sees advantages in both approaches.

McCormick prefers centralized signal processing when the entire area of automation is relatively compact—that is when "a controller can be put in the middle of a relatively small unit, so the hardwiring is easier and not that expensive, making the total installation less expensive than one with remote I/O," he says.

But deciding between remote and centralized I/O involves more than just reducing the wire count and installation costs because network performance also must be considered.

"There are trade-offs between remote and centralized processing in a distributed architecture," says Curt Wilson, vice president of engineering and research at Delta Tau Data Systems (www.deltatau.com), adding that one of the key determinants is the degree of interaction you wish to support between data sets from different remote devices.

"In one notorious case we're aware of, one remote drive faulted in a system moving cassettes of silicon wafers through a semiconductor fabrication plant," Wilson explains. "The information didn't get back to the central controller via the network in time, and then from there to the remote drives for the other axes, so they continued to move. As a result, the system crashed and destroyed millions of dollars worth of microprocessors."

In another case, a user had a system working, but was dissatisfied with the throughput. "By moving them to a system with more centralized processing, we were able to reduce cycle time by 30%, mainly by eliminating the delays from ‘Are you there yet?' queries and responses over the network," Wilson recounts.

Improved network speeds now minimize such problems, Wilson says, with 100 Mbps Ethernet-based industrial networks now common. "These high-performance networks facilitate quick interaction between remote nodes," he adds. "Higher bandwidth and speed also greatly simplify system setup, diagnostics and repair."

The Numina Group (www.numinagroup.com) in Woodridge, Ill., builds high-performance conveyor control and automation systems (Figure 2) using networked Beckhoff Automation (www.beckhoff.com) controllers and remote I/O. "EtherCat I/O is an order of magnitude faster than any I/O system Numina has ever used," says Mark Woodworth, vice president of design. "This is important in high-speed sorters or sophisticated print/apply applications in which even a millisecond lag can be too much."

With Numina's previous I/O system, performance would degrade as the size of the application and number of required I/O increased. "Each time we polled a system of 20 modules or more, it took 25 ms, which wasn't fast enough," Woodworth says. "Now, we consistently get the industry's fastest real-time speed, and we've seen no degradation in performance even with high I/O counts."

Network Redundancy

McCormick points out a problem that emerges when you compare the use of a centralized controller with remote I/O to having a local controller with its own I/O. "A drawback to using remote I/O is that a single point of failure caused by an electrical fire or other problem could take out the network communications link," McCormick says. "This is why vendors normally offer redundant links from controllers to remote I/O, recommending different paths as much as possible. The second path could save a shutdown to the unit controlled with remote I/O."