Signal Processing Drives Network Design

Digital Networks Enable Remote Signal Processing and Control via Intelligent I/O

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

Charlie Norz, product manager at Wago (www.wago.com), agrees. "Network redundancy is an important design aspect, especially for critical applications," he says. "Here, the focus should be on dual transmission paths for communication reliability in the event of a failure, such as a forklift severing a cable. Advanced controllers and couplers with this capability should be considered an integral network component."

Redundancy is available on fieldbus systems, as Jim McConahay, senior field applications engineer at Moore Industries (www.miinet.com), points out. "A redundant device coupler accepts separate communications cables to increase the reliability of the communications cable in critical circuits should one of the cables become faulty."
Wago's Norz cautions that when using remote I/O for signal processing, the first design consideration should be network traffic reduction. "Performance is a primary concern with high-speed operations such as packaging lines, so don't overlook traffic when designing for industrial applications," he says.

Centralized I/O Is Simpler

With the sole exception of high hardwiring costs, centralized I/O on small control systems eliminates many of the networking problems and issues experienced by users of remote I/O.

"Centralized I/O requires no communication setup time for remote devices, such as distributed I/O modules," says Lantech's Jones. "All the I/O devices are wired directly to inputs and outputs, simplifying the engineering. Direct wiring uses single-ended cables that can be cut to length. Remote I/O requires double-ended specific length cables."

Wadowick agrees. "Small systems can get by with centralized I/O and signal processing," he advises. "If the machine footprint is just a few square feet, there's usually no necessity to implement remote I/O."

Automation systems with remote networked smart I/O are more complex to design, purchase and maintain than systems with hardwired I/O. However, the installation costs for remote networked I/O can be much lower, and the total system can operate at much higher levels because the remote I/O can perform many functions such as signal processing and real-time control.

In effect, an automation system that employs remote smart I/O interconnected via a high-speed digital data network results in multiple controllers distributed throughout the machine or process. These multiple controllers will outperform a single centralized controller, and in many cases will justify the investment and complexity of distributed signal processing and control via a digital network.


Decision Process

Lantech builds packaging, stretch wrapping and pallet load conveying machines. Derek Jones, senior marketing product manager at Lantech, says the company uses both hardwired and networked remote I/O in its products, and the decision is based on the machine and the customer's environment.

"Lantech uses several key points to determine if centralized I/O or remote I/O makes sense on a given machine," Jones says. "The first deciding factor is cost. Is it cost-effective to place expensive remote I/O modules at strategic mounting locations on the machine, or is it less expensive to bring all I/O back to the main control panel?"

This can be determined by comparing the labor and material cost of routing more single-ended hardwiring to local I/O with the labor and material cost of remote I/O and its smaller overall lengths of double-ended cable, Jones explains. Overall cost will be determined by the number of I/O points, how far away they are from the main control panel, and how far away they are from each other.

"The second deciding factor is the available remote I/O technology," he says. "Remote I/O is gaining momentum, but more complex I/O such as high-speed counters and motion control could be limited depending on the automation vendor. If the machine needs several functions not offered by remote I/O, this tips the decision back to centralized I/O."

The third factor is the end-user environment where the machine will be maintained. "Remote I/O can simplify the wiring, but it requires more knowledge and understanding to set up and troubleshoot," Jones says. "If the machine is being shipped into an environment where the end user doesn't have expertise to troubleshoot or replace a remote I/O module, Lantech might not use this technology on the machine."