Control logic execution decoupled from proprietary controller hardware and run instead as software on standard, virtualised compute — scaled, patched and failed-over like any other enterprise application.
Software-defined / virtualised remote I/O
I/O termination that virtualises the signal-processing and protocol-conversion layer in software running on standard servers, rather than in dedicated I/O card firmware.
Short entry. This page summarises our current placement. Full, sourced analyses are published first for the technologies closest to practical use; see the list of full analyses.
How it works
In a conventional system each I/O card contains the electronics and firmware for one signal type, and the number of card slots fixes how much can be connected. Software-defined I/O separates those roles. Field wires still land on physical terminals, often on universal channels that can be set as analogue or discrete, input or output, but scaling, diagnostics, protocol conversion and the mapping to controllers run in software.
Once I/O is published on the network as data rather than wired to a particular controller, any controller can subscribe to any signal. Capacity, redundancy and assignment become configuration choices, and the software layer can run on standard industrial servers alongside virtualised controllers.
Why it matters
Decouples I/O count and type from physical card slots — capacity is added by licence, not by a cabinet retrofit, and failover is a software, not a hardware, event.
Where it fits
It fits projects where design changes arrive late, since a signal type or controller assignment can change without rewiring, and modernisation projects that want to keep field wiring while replacing the system above it. It is the natural companion to a software-defined control system, and features in open-architecture initiatives that aim to decouple hardware from software.
Why we place it at the Over-Promise stage
Multiple automation vendors have shipped commercial virtual-I/O products since 2024; the pattern is following software-defined DCS/PLC into mainstream project specifications. Estimated time to the Proven in Use stage: 2–5 yrs. What the stages mean.
Key risk
Cybersecurity and change-management discipline for the hosting server layer becomes as important as it is for any other server in the OT environment.
Questions to ask before committing
- Which functions remain in hardware at the termination, and what happens to outputs if the software layer or network is lost?
- What scan times and failover times are guaranteed, and under what server load?
- Who patches and hardens the hosting servers, and on what schedule?
Standards and terms to know
- Universal I/O
- A channel whose signal type is set by configuration rather than by the card fitted.
- Electronic marshalling
- Assigning field signals to controllers in software instead of with cross-wiring.
- O-PAS
- The Open Process Automation Standard, a vendor-neutral reference architecture from The Open Group.
Related technologies
See this entry on the full maturity map · All Control Devices entries · How placements are made. Stage and time-horizon placements are editorial judgements based on public information as of October 2026, not engineering, safety or investment advice; see the Terms of Use.