Exploring Local, Remote and Distributed I/O

  • By Paul Harris
  • December 02, 2022
  • Moore Industries-International, Inc.
  • Feature
Exploring Local, Remote and Distributed I/O
Exploring Local, Remote and Distributed I/O

Process and factory automation controllers connect to sensors, instruments, valves and other equipment through input/output (I/O) cards or racks that are either collocated within the same cabinet (local) at the controller/CPU or installed farther away (remote). Defining the difference between local and remote I/O is straightforward, but the defining differences between remote I/O and distributed I/O can have their nuances and are further confounded by each vendor’s definitions or marketing collateral, just as many automation vendors prefer a name like process automation controller (PAC) over programmable logic controller (PLC).

The most used I/O type is local I/O. It is most often from the same vendor as the controller/CPU, since it is ordinarily directly connected to the controller/CPU by integrated racks or cages that hold 4-, 8-, 16- or 32-point I/O cards. Some local I/O expansion racks, or bricks, as they are often referred to, can be separate from the main CPU and connected over a digital bus or highway via twisted pair wires or Ethernet cables, albeit installed within the same physical cabinet. Since local I/O is typically intended to be installed within the same enclosure as the controller/CPU, environmental operational characteristics and hazardous area approvals are not as robust as remotely installed I/O.

Remote I/O characteristics

Next comes the challenge of outlining the different characteristics between remote I/O and distributed I/O, especially since many vendors refer to them interchangeably. If we use history and release to market timelines as a basis, remote I/O was first and thus less flexible, capable and smart as compared to later released distributed I/O. Initially, remote I/O was nothing more than local I/O reconfigured and housed to be remotely installed from its corresponding controller/CPU (Figure 1).

Figure 1: Remote I/O was local I/O reconfigured and housed to be remotely installed from its corresponding controller/CPU.

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 is limited in scope and does not contain a complex or advanced CPU or processor to handle math, complex control, and peer-to-peer communication with other remote I/O modules, or allow the connection of additional I/O modules. While operational characteristics and hazardous approvals exceed that of most Local I/O products, it is still somewhat more limited than its advanced cousin, distributed I/O.

Distributed I/O characteristics Distributed I/O harnesses all the capabilities of remote I/O and more. It is likely, but impossible to determine, that distributed I/O derived its name from “distributed control.” As the name suggests, distributed I/O is a more complex piece of equipment that can be distributed throughout a process plant or automation facility without the concern of continuous communication with its host controller/CPU. This is because most distributed I/O products contain an advanced CPU and often real-time operation system that allows localized control and monitoring, along with several other capabilities.

Since distributed I/O (Figure 2) is designed to exist on its own, it can be a preferred choice of remote I/O due to its ability to be redundant or fault tolerant should it lose communication with a primary controller/CPU. In addition, distributed I/O and its advanced capabilities can share signals between other peer distributed I/O systems from the same vendor or alternative vendors using industry open or standardized protocols such as MODBUS RTU. Designed to be used for remote installations, distributed I/O typically allows for installation in more harsh operating environments and often has a minimum of Class I, Div. 2/Zone 2 approvals and sometimes carry Zone 0/1 approvals.

Figure 2: Distributed I/O can share signals between other peer distributed I/O systems from the same vendor or alternative vendors using industry open or standardized protocols.

With its diverse capabilities, distributed I/O can be well suited to not only be a local controller and I/O device, but it can also have additional built-in capabilities to support peer-to-peer communications, gateway functions such as HART to MODBUS RTU or MODBUS/ TCP conversion, embedded webservers for ease of viewing real time process data with an off the shelf web browser, data logging, and even Industrial Internet of Things (IIoT) or Industry 4.0 capabilities employing message queuing telemetry transport (MQTT) protocol for seamless connections to cloud services like Amazon Web Services (AWS) or Microsoft Azure.

Looking ahead

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

Regardless of type, I/O products 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.

This feature originally appeared in InTech Focus: Control Systems 2022, the InTech Focus ebook for September 2022.

About The Author

Paul Harris is the sales and operations manager of Moore Industries Europe Inc. Before being named SAOM in 2019, Harris held various roles within the company, rising from junior test engineer through to the position of export sales manager. Joining Moore Industries in 1983, he quickly became a progressor who could span a breadth of process control instrumentation technologies and is now accountable for implementing the company’s policies while directing local strategies to enhance the overall growth of the EMEA regions.

Did you enjoy this great article?

Check out our free e-newsletters to read more great articles..