Remote IO

What is Remote I/O?

Remote I/O (Remote Input/Output) is an arrangement in which input and output modules are not mounted in the cabinet of the central control system, but sit close to the sensors and actuators in the field and communicate with the PLC, controller or DCS over a fieldbus or industrial Ethernet. Instead of pulling hundreds of individual cores from every signal back to the central cabinet, you connect the signals locally to an I/O station. That station passes all values on digitally over a single network cable. Remote I/O is also called decentralised or distributed I/O and is found in virtually every modern machine and process plant.

🧠 How does Remote I/O work?

A remote I/O station usually consists of three parts:

• Interface module or bus coupler - the network connection (for example a ProfiNET, Ethernet IP or EtherCAT coupler) that makes the station appear on the network as a single device
• I/O modules - digital and analogue inputs and outputs, counters, IO-Link masters or safety modules; typically 2 to 32 channels per module
• Power supply and end module - 24 V DC for the electronics and field signals, sometimes split so that outputs can be switched off separately

The controller reads and writes the I/O cyclically. Every cycle it sends the output values to the station and receives the current inputs back. For the PLC program it hardly matters whether an input is local or remote; the address simply sits in the process image. The difference lies in the cycle time and in what happens when the connection drops. A properly configured station then puts its outputs into a safe substitute value, usually “off”.

Remote I/O differs from local I/O (modules next to the CPU in the same rack) and from intelligent field devices that communicate over a network themselves, such as a field instrument with HART or an IO-Link sensor. See IO for the signal types themselves.

🔧 What types of Remote I/O are there?

In the process industry universal I/O is gaining ground: channels that you configure one by one in software as AI, AO, DI or DO. Emerson calls this electronic marshalling. It removes the traditional marshalling cabinets with cross-wiring between field cables and I/O cards. Since 2011 Emerson has also offered intrinsically safe CHARMs with the Ex barrier built into the module itself, so separate barrier cabinets are no longer needed.

🔌 Which protocols does Remote I/O use?

Remote I/O is protocol-bound: the coupler determines which network the station connects to. Many vendors offer the same I/O modules with different couplers. That is why WAGO 750 is described as fieldbus-independent, Beckhoff also connects its EtherCAT Terminals to other fieldbuses via EK bus couplers, and the older Allen-Bradley FLEX I/O (1794) has adapters for EtherNet/IP, ControlNet and DeviceNet, among others. FLEX 5000 is the newer generation, built specifically for EtherNet/IP. New installations almost always use a protocol based on Ethernet.

More and more interface modules are multi-protocol. With a MultiFieldbus interface module, the Siemens ET 200SP can for instance run on PROFINET, EtherNet/IP or Modbus TCP. For process instruments, Ethernet-APL takes Ethernet into the hazardous area, which means part of the classic remote I/O carrying 4-20 mA signals may disappear over time.

🎯 What are the pros and cons of Remote I/O?

Advantages:

• Less cabling - only a network cable and a power cable to the station instead of a separate cable per signal; that saves copper, cable trays and installation hours
• Modular design - machines and production cells can be built, tested and extended module by module
• Faster installation and commissioning - stations can be delivered pre-wired and pre-tested
• Smaller central cabinet - the PLC cabinet no longer needs to house hundreds of terminals
• Better diagnostics - modern modules report wire break, short circuit and supply faults per channel

Drawbacks and points of attention:

• Dependence on the network - a cable break or failed switch can take out a whole station; redundancy and ring topologies reduce that risk
• Extra latency - the network cycle adds to the response time of the control system
• Safety functions - an emergency stop circuit may only run over the network if you use a certified safety protocol; otherwise separate, hardwired safety technology is still required
• Attack surface - every station is a network device with firmware, an IP address and sometimes a web server

🔐 How do you secure Remote I/O?

In the Purdue Model, remote I/O belongs to level 1, basic control, and is wired directly to the physical process at level 0. Anyone who can write an output on a remote I/O station can open a valve or start a motor. Even so, most real-time I/O protocols were designed without authentication: PROFINET RT, Modbus TCP and classic EtherNet/IP will in principle accept any correctly formed message.

The protocol organisations are working on improvements. PI defines three security classes for PROFINET: class 1 for robustness (including read-only DCP and signed GSD files), class 2 for integrity and authenticity of the data, and class 3 for confidentiality of the cyclic data. For EtherNet/IP there is CIP Security. In existing plants these functions are rarely available, however, so security has to come mainly from the architecture:

• Segmentation - put I/O networks in their own zone following the zones and conduits model of IEC 62443 and allow only the controller access
• No routing to office IT - I/O traffic does not belong on the corporate network; disable coupler web interfaces when they are not needed
• Physical security - lock field cabinets and disable unused switch ports
• Inventory and firmware management - know which stations exist and which firmware they run, and follow vendor patches
• Monitoring - passive OT monitoring flags unknown devices and anomalous traffic on the I/O network

For organisations covered by NIS2 and the Dutch Cyberbeveiligingswet, remote I/O networks simply fall within the duty of care for network and information systems.

🧭 How do you design a Remote I/O architecture?

1. Decide the distribution - group I/O per machine section or process area, so that a fault in one station does not stop the entire plant.
2. Choose cabinet or machine-mounted I/O - IP20 in a cabinet is cheaper per channel; IP67 saves an enclosure and is faster to fit to the machine.
3. Choose the protocol - usually determined by the controller brand: PROFINET with Siemens, EtherNet/IP with Allen-Bradley, EtherCAT with Beckhoff.
4. Calculate the cycle time - add up network cycle, PLC cycle and input filters. Input filters are often adjustable; on the ET 200SP from 0.05 to 20 ms.
5. Keep spare capacity - a rule of thumb is 10 to 20 percent free channels and free slots. An ET 200SP station with a High Feature interface module can hold up to 64 I/O modules, and a WAGO 750 node without bus extension also 64.
6. Plan safety and power - choose safety modules on PROFIsafe or CIP Safety where needed, and separate power supplies so that outputs can be switched off safely.
7. Define substitute values and diagnostics - decide per output what happens on loss of communication and make sure diagnostic messages are visible in SCADA or the HMI.

In the Netherlands remote I/O is common at water boards and drinking water companies, where pumping stations and treatment units are spread across large sites (see also Water Sector OT Security), on long conveyor lines in distribution centres and airports, and in the chemical industry, where Ex-certified I/O in Zone 1 or Zone 2 limits the cabling back to the control room.

❓ Frequently asked questions

What is the difference between remote I/O and distributed I/O?

Remote I/O and distributed I/O (also called decentralised I/O) mean the same thing in practice: I/O modules located outside the central control cabinet that communicate with the controller over a network. Siemens speaks of dezentrale Peripherie in German and of distributed I/O in English, as does Rockwell. The distinction is mainly a matter of vendor terminology.

Does a remote I/O station run its own program?

A classic remote I/O station has no program of its own; it only executes what the controller sends it cyclically. Programmable variants do exist, such as WAGO controllers and Beckhoff couplers with local logic. These then behave like a small PLC with its own I/O.

What happens to the outputs if the connection to the PLC is lost?

On loss of communication, a remote I/O station puts its outputs into a preconfigured substitute value, usually “off” or the last value. You make that choice per channel in the configuration. For safety functions you use safety I/O, which always goes to the safe state on a timeout.

Can remote I/O be installed in a hazardous area?

Remote I/O can be installed in a hazardous area if the system is certified for it. There are systems for Zone 2 and for Zone 1, with intrinsically safe channels to the field instruments. Examples include R. STAHL IS1+ and Emerson’s intrinsically safe CHARMs.

Is remote I/O vulnerable to cyberattacks?

Remote I/O is vulnerable because many real-time I/O protocols have no authentication and a station executes any valid message. In addition, couplers run firmware and sometimes a web interface with vulnerabilities of their own. Segmentation, locked field cabinets and firmware management are therefore the key measures.

Does IO-Link replace remote I/O?

IO-Link does not replace remote I/O but complements it. IO-Link is a point-to-point connection to a single sensor or actuator; the IO-Link master itself often sits as a module in a remote I/O station or as an IP67 block on the machine. That way you combine distributed I/O with digital parameterisation and diagnostics per sensor.

📌 In summary

Remote I/O moves the inputs and outputs of a control system to where the signals originate and connects them to the PLC or DCS over a single network cable. That saves cabling and cabinet space, makes machines modular and delivers better diagnostics. At the same time every I/O station becomes a network device that depends on communication and must be protected with segmentation, physical security and firmware management.