The distributed control system has been in use forever in the process world. In the machine-builder world, most of the control systems have been localized over the years. With the expansion of control and production platforms—edge computing and remote human-machine-interface (HMI) access—and of course robot integration, the need to take the I/O structure to the operation has been amplified by the Industrial Internet of Things (IIoT) and intelligent devices.
The 1970s and 1980s brought these devices called programmable logic controllers (PLCs) into the automation world. They initially only had local I/O, which meant that all the wiring needed to terminate back at the controller.
Wire was cheap, so it really wasn’t a big deal. Troubleshooting was easy since everything was local and in front of the troubleshooter. An I/O drawing, I/O lights, a meter and process knowledge could save the day.
In the 1990s, Rockwell Automation demonstrated a concept called highly distributed control, in which the control for the process was embedded in the device. Photo-eyes, proximity switches and solenoids all had networked intelligence to sort the colored balls circulating in an enclosed track. There was no central brain, just the code running in each device. Talk about a troubleshooting nightmare, but it paved the way for distributed control on various levels.
If you think about a PLC program, a start button has a specific function—to start a process or device. This would be called context dependencies. It is programmed to do exactly what is designed to do and nothing more or less.
The concept of distributed control wasn’t new. Most PLCs had the ability to interface with remote I/O. This just meant that an I/O chassis could be mounted outside the main PLC panel located strategically on the machine to reduce installation costs.
Software tools were added to aid in troubleshooting the system since all data is not physically in front of the troubleshooter. The usage of remote I/O in chassis led to creative diagnostic software being written to aid in unscheduled downtime recovery. Supervisory control and data acquisition (SCADA)/HMI systems became the window into the world of distributed I/O.
I chaired an ISA tech session back in the 1990s in which Rich Ryan was one of the presenters. I’d managed to coerce him into speaking. He is currently a software architect for Rockwell Automation. He and I had a conversation after the session, and he predicted that automation vendors will focus on software and processors.
DeviceNet started the ball rolling, but EtherCAT, Modbus TCP and EtherNet/IP really created our current options.
There are many I/O vendors who design and manufacture I/O systems for various protocols. MurrElektronik is one vendor whose products were being used in a Rockwell project that I was involved in. It used EtherNet/IP, and the project had three panels, all of which had I/O blocks. Drives are now commonplace and viewed as networked I/O nodes.
IEC 61499 in its infancy was cumbersome and not widely understood. It is gaining some traction and mirrors Rockwell’s highly distributed control, where the devices have the ability to have context dependencies. Each device that is 61499-compliant has the ability to be programmed using function blocks. With networking capabilities, autonomous intelligent devices can be linked together to form a control strategy in a process/machine distributed method.
Hardware/chip costs are at a very reasonable level. Form factors are small—just look at an Apple AirTag. Miniature circuitry is a reality. Cell communication as well as Wi-Fi is possible on any device. Energy harvesting may play a role in powering these remote devices.
Using distributed I/O allows the machine designer so many options for connectivity. Remote I/O, networked I/O and wireless I/O are all available to the engineer configuring the control strategy.
The software component is now most important. Documentation is a must. When a machine shows up on the plant floor, the maintenance department needs to know how the system is constructed in order to understand the process of troubleshooting.
In my honest opinion, training is essential. The knowledge base of plant-floor electricians has to expand to include PLC programming software, HMI screen presentations, wiring schedules, network topology, node addressing and probably a whole bunch more.
Software diagnostics embedded in the control can help, if done properly. Having the flexibility of placing I/O where you need it is not new, but the options now are tenfold of what they were. I’m sure there are I/O blocks with edge capabilities.
