Why distributed I/O is the “new” default
Key Highlights
- Distributed I/O reduces cabling costs and control panel size, making system setup more economical and flexible.
- Shorter sensor-to-module wiring minimizes signal degradation and electrical noise interference.
- System expansion is simplified by allowing new I/O points to be added without extensive rewiring or spare capacity concerns.
Distributed I/O has, in many ways, become the new default method of interacting with field devices. One could even argue that fieldbus and wireless mesh networks are the most granular implementations of distributed I/O but that is not what comes to mind when discussing the diverse ways of collecting and distributing field signals.
The main benefits of distributed I/O are:
- Cost savings through reduced cabling costs and smaller control panels, particularly in the PLC and/or central controller at the control center;
- Minimized signal degradation because distributed I/O shortens sensor-to-module wire runs, and reduces electrical noise interference, voltage drop, and analog signal attenuation;
- System expansion is simplified by allowing new I/O drops to be spliced into the existing network ring or line without worrying about the number of “spares” in the home run multiconductor back to the main control panel; and
- Skid packages have a distributed I/O panel prewired to its equipment that can be fully tested by connecting the controller to the panel.
Of course, there are disadvantages as well:
- Ethernet connectivity to the host system and the required home run cable, configuration, and IP addressing;
- Network vulnerability, latency and cybersecurity exposure with reduced physical protection beyond a locked cabinet door; and
- Power distribution issues around getting reliable power to what is now a core part of the control system.
For the power distribution problem, you must either provide loop power at the I/O panel in the field or make all devices four-wire while still needing to power the remote I/O module itself. Fortunately, the market offers field mountable, including area-classified UPS power supplies, with power monitoring diodes, battery saving algorithms and alarm contacts to remotely monitor the health of a power system.
One difference between the Internet of Things (IoT) and Industrial Internet of Things (IIoT) is how they power their edge devices. IoT tends to use Power-over-Ethernet (PoE), which works because there is typically a single edge device rather than a traditional I/O data collection system.
Get your subscription to Control's tri-weekly newsletter.
Ethernet APL has a little of both worlds, addressing both power and connectivity issues. It also provides power for the field switch, which is like distributed I/O. It is based on power availability and several APL spur devices. Currently, APL does not support legacy field devices and doesn’t behave as a gateway for traditional fieldbus devices. However, I suspect the fieldbus gateway will soon be an option.
The same 10Base-T1L technology on which Ethernet APL relies can also run in Ethernet-only mode over single twisted-pair cable making it possible to expand existing multi-conductor cable capacity at end-of-wire, daisy-chained field junction boxes with legacy devices, potentially addressing part of the connectivity problem.
The other part of the connectivity challenge is the I/O itself. Most remote I/O systems are designed to integrate with a specific manufacturer’s controller, and the manufacturers have many useful tools to make it easy for you to do so. However, I personally believe the “Slice I/O” options originally developed for the factory environment is a great option. Most of the industrial connectivity suppliers offer some form of this technology that has a processor and communication head power, communication backplane and individual I/O cards the size of terminal blocks for almost every type of signal, including support for analog HART at a fraction of the cost of traditional remote I/O. These systems also support most of the major protocols including OPC (process) and MQTT (SCADA). So, how much interoperability do you need for your distributed I/O?
Does the I/O need to support protocols only, or must it take the next step and include interchangeability as the Open Process Automation Forum (OPAF) is striving to achieve?
My take is that interoperability is sufficient and today’s systems certainly have that capability.
Now, if we can sort out the cybersecurity challenges—though I suppose deep packet inspection can help some in that space as well—the potential for increasing growth and use of distributed I/O has few barriers, which is why practically every project that I am aware of is using this approach.
About the Author
Ian VerhappenIan Verhappen
Ian Verhappen
Leaders LogoLeaders relevant to this article:
