The ins and outs of I/O — local, remote and distributed

Process and factory automation controllers connect to a wide variety of sensors, instruments, valves and other equipment through I/O cards or racks that are either co-located within the same cabinet (local) — as the controller or CPU — or installed remotely.

Defining the difference between local and remote I/O is straightforward. Still, the defining differences between remote I/O and distributed I/O can be more nuanced. They can be further confounded by vendors’ definitions or marketing collateral, just as many automation vendors prefer to use a name such as process automation controller (PAC) over programmable logic controller (PLC).

The most used I/O type is local I/O, usually from the same vendor as the controller or CPU, directly connected via integrated racks or cages holding 4-, 8-, 16- or 32-point I/O cards. Some local I/O expansion racks are separate but connected to the CPU through digital buses or highways via twisted pair wires or Ethernet cables, within the same cabinet.

Since local I/O is typically intended to be installed within the same enclosure as the controller or CPU, environmental operational characteristics and hazardous area approvals tend not to be as robust as for remotely installed I/O. Next comes the challenge of outlining the differing characteristics between remote I/O and distributed I/O, especially since many vendors refer to them interchangeably. Remote I/O came first and thus tends to be less flexible, capable and smart when compared to later-released distributed I/O.

Remote I/O was originally local I/O reconfigured and housed to be remotely installed from its corresponding controller. Communication was no longer along a backplane but now designed to convert its connected analog I/O signals to a digital format that was transmitted back to the host controller over proprietary buses or highways.

Remote I/O lacks complex or advanced CPUs or processors to handle maths, complex control or peer-to-peer communication with other remote I/O modules, nor does it allow the connection of additional I/O modules. Though surpassing local I/O in operational characteristics and hazardous approvals, remote I/O is still more limited than local I/O.

The advanced capabilities of distributed I/O generally exceed remote I/O capabilities, as it is a more complex technology that can be distributed throughout a process plant or automation facility, and does not need constant communication with the host controller. This is because most distributed I/O devices contain advanced CPUs and real-time operation systems that allow localised control and monitoring, and other capabilities.

Distributed I/O can stand alone and can be a preferred choice over remote I/O due to its redundancy should it lose its connection with the controller.

Designed for remote installations, distributed I/O suits installation in harsher operating environments. They often have a minimum of Class I, Div 2/Zone 2 approvals, and occasionally Zone 0/1 approvals. Distributed I/O can be well suited to serve as a local controller and I/O device but may have additional built-in capabilities to support peer-to-peer communications and gateway functions — such as HART to Modbus RTU or Modbus/TCP conversion. They usually also contain embedded webservers for real-time data viewing, data logging and even IIoT or Industry 4.0 capabilities employing the MQTT protocol for seamless connections to cloud services like AWS or Microsoft Azure.

Recent advances in secure spread spectrum, long-range and mesh wireless telemetry have further enabled I/O devices to provide solutions once thought impossible. Wireless HART, ISA 100 and many proprietary short- and long-range unlicensed solutions are now optionally embedded directly within the I/O device itself, spawning an entirely new category of remote or distributed types of I/O solutions.

I/O devices, regardless of type, have advanced incredibly fast during the last decade. So much so that several of the abovementioned differentiators have blurred the once-defined lines that separated them. For the user, it is imperative that each vendor’s solution and technology offering be thoroughly examined to ensure functional, operational and design compliance.

Image: iStock.com/PRANITI