Distributing I/O

May 16, 2018
Our slow climb from DCS to Internet protocol is getting steeper faster

Despite the name “distributed control system,” the original systems did not distribute the I/O but kept all the hardware located near the control room in a controlled-environment interface room. Then, in the 1990s when networks improved and fiber optic became more common, the I/O started being moved further from the control room to remote instrument buildings—again in controlled environments, but now closer to the process units, reducing the need for long multiconductor cables. This trend is continuing with I/O now being distributed to the field itself, replacing the traditional field junction boxes. European manufacturers such as R. Stahl, Turck, and Pepperl-Fuchs transitioned products from the manufacturing sector to the process industries, and now all the major DCS and PLC suppliers have remote I/O offerings under their various trade or marketing names.

A case can also be made that a wireless access point is somewhat akin to a remote I/O unit, it just aggregates signals from wireless rather than wired devices, so many of the attributes and requirements—at least the ones below—are also similar.

One challenge with the available offerings is their ability to integrate and interoperate. The Open Process Automation Group also wants to make not only the remote I/O (Distributed Control Nodes (DCN) in their nomenclature) interoperable, but to also have interchangeability, which means being able to replace a device from one manufacturer with one from a different manufacturer and still have identical capabilities. Integration, on the other hand, means that you are able to incorporate the device into a broader system and ensure the interaction between all enterprise entities that is necessary to achieve a given purpose in a given constrained environment. Interoperable is the ability of two or more systems or components to exchange information, then be able to use the information that has been exchanged, which is one step up the usability chain from integration. Integration normally requires more manual effort when the systems are being built than interoperability, and for many years, third-party integration (TPI) was the bane and source of lots of billable hours on many projects.

With the adoption of Internet protocol (IP)-based networks and agreement on a single protocol for a project and facility, the level of interoperability improves significantly, and hence the integration effort as well. Further improvements can be made by selecting a single protocol from end-to-end (i.e. controller through to field devices) so that a gateway (an integration device that translates from one language or protocol to another) is not required.

[pullquote]

Considering that, for the process industries at least, the most commonly used protocol is HART, and though not widely supported, HART/IP is therefore important to allow the above-mentioned end-to-end integration within a single protocol for wired or wireless HART. Other common protocols for remote I/O include Ethernet/IP, Profibus DP and ProfiNET, as well as the ubiquitous Modbus/TCP, though most of these will require mapping of data, as with a gateway.

As I have indicated before when discussing access points, because these units are mounted in the field and therefore will be connected to field power, care must be taken to ensure they have a reliable power supply—as a minimum, that in a plant environment they are fed from two separate sources on separate buses, or alternately, they contain a small uninterruptible power supply (UPS) to ride through any accidental AC source outages. Of course, knowing when there is an incident and that the entire set of I/O is a risk is also good, but unfortunately, in most cases, the available option consists of a single “power supply common trouble” contact. Some manufacturers provide a digital interface to configure the UPS system, however it may be a USB connection, meaning work must be done with a local laptop rather than being accessible over the network via a common protocol using the available Ethernet in the panel. One reason for not using a protocol may be the costs associated with developing and certifying (check marks) for the individual protocol organizations.

Distributed I/O is definitely coming and if we believe the Internet of Things (IOT) hype, it will no longer be required or will be replaced by routers and switches because the individual sensors themselves will correct directly to the associated cloud-based database from which all the information we require will be mined or pulled. A great vision, and like most things that we do as engineers, it will be magic to everyone using it.