Distributed I/O can mean different things to different people and different manufacturers, but let’s discuss I/O device hardware—digital, analog or messaging device—that is connected to the primary control device using a communication system other than the central processing unit’s backplane.
The communication connection is facilitated using multiconductor cables, a fiberoptic interconnect or a radio system of some sort. If the communication system and distributed I/O hardware are primarily designed to be used within the scope of products marketed by the primary control device manufacturer, we’ll referred to that as remote I/O. If the communication system is an open or published system that multiple manufacturers may use it will be referred to as fieldbus distributed I/O.
A manufacturer’s proprietary remote I/O system has some advantages over fieldbus distributed I/O. The most significant advantage is the manufacturer’s sole control of hardware specifications, communication protocols and required performance of the devices on the network.
Hopefully, the different product divisions within a manufacturing company share standards, data and standard manufacturing practices. This sharing of practices is not always the case. Different design centers within larger companies sometimes produce products that are not 100% compatible with the rest of the product line. Many times a software revision must be rushed out right after introduction to restore some piece of functionality lost with a new design.
By and large, most remote I/O products work well with each other, and the resulting system will be as trouble-free and reliable as the manufacturer’s local I/O equipment.
Larger automation manufacturers at times partner with other third-party manufacturers to produce specialty or low-volume products to offer additional solutions used within the local or remote I/O structure, allowing additional customer solutions.
Perhaps a third-party manufacturer produces a type of Andon display. The third-party manufacturer, the Andon expert, the automation manufacturer and creator of the Andon data work together to develop a product that works seamlessly within the I/O control structure.
The display example is just one of many types of control devices developed to extend the functionally of a control system. While these third-party speciality I/O cards are not exclusively built for remote I/O systems and may be just as easily used on a local I/O rack, most of the specialty I/O cards will, in practice be used in a remote I/O scheme.
In conclusion, remote I/O systems have constant design methods, constant performance expectations and ease of incorporation as the positives for incorporation into a control system.
In 1979, Modicon, which is now part of Schneider Electric, published the communication specification for a communication system called Modbus. Modbus is a master/slave type of communication system where a master device could send messages to slave devices and in return read the data value of memory registers in the slave, write a data value to registers in the slave and issue some basic commands to be performed by the slave.
In 1989, the German Federal Ministry of Education and Research (BMBF) promoted the adoption of Profibus, a master/slave communication system later adopted and promoted by Siemens.
These two networking systems were intended to allow communications from a master device, usually the PLC CPU, and slave devices such as displays, motor controls and I/O devices. This communication scheme differs from a remote I/O system, in that any device that follows the communication and programming rules may be used and not just products developed by the manufacturer that designed and owns the communication specifications.
The administration of the I/O specific parts of the communication protocol and the performance benchmarks for Profibus DP (decentralized peripherals) and later DeviceNet were handed over to standards originations such as Profibus International and Open DeviceNet Vendors Association (ODVA). The governing bodies work to ensure modules and devices work within the published protocols and with each other.
In conclusion, fieldbus I/O systems have a greater variety of end product types and compatible performance expectations maintained by the governing body as positive arguments for incorporating these products into a system. The ease of incorporation into a system including configuration depends on the completeness of documentation.
The variety of form factors given to remote I/O terminals range from a low protection of NEMA 1 or IP10 for components designed to be placed inside an industrial enclosure to NEMA 4X or IP69K components designed to be mounted directly to a support member of a machine requiring no additional environmental shielding.
In addition to the many environmental form factors, sizes given to both fieldbus I/O system modules and remote I/O systems vary from single-point connections to multi-word interface connections.
Evolving designs tend to blur in execution realities over time. A system designed as a pure I/O network will tend to pick up modules and devices that reduce the pureness of design. For example, adding a variable-frequency drive (VFD) or process controller to an I/O network continues the I/O interface of digital switches and status bits, as well as analog values representing set points.
At the same time, it adds a degree of distributed control operating the controller or drive alongside the distributed I/O. Very seldom will a completed system be entirely a distributed I/O or distributed control network.
There are other industrial networks that have been designed to provide solutions for specific needs. If given the task of designing an I/O bus, what would be the primary criteria for deciding on what type of network to build? Consider Industry 4.0, the Industrial Internet of Things (IIoT) and big data.
This data-driven manufacturing model requires retrieving large amounts of data from as many sources as possible and running computer analysis and modeling techniques to reduce production time and delays, predictive troubleshooting and essentially making the production control system as intelligent as possible.
As far as the network is concerned, large amounts of data translate into one thing—a high-speed network. All schemes have an Ethernet transport level version. However, you must use a communication system that retains the deterministic features of an industrial network.
Many manufacturers are offering tools that build virtual models of some of their control systems, including networking. It may be a good choice to develop the performance requirements first and design the network to meet them instead of designing the network and modifying the hardware to meet the desired performance.
