Here’s a fairytale. Once upon a time, you woke up abruptly to your shift supervisor begging for your help with an emergency. The chemical feed system PLC got smashed to bits by a reckless forklift, and downtime was racking up. Your shift supervisor was frantic, explaining that the specific PLC model was backordered into the next year.
That’s all? Thank goodness, there was no need to panic at all. You just securely remoted into the facility over the VPN and spun up a virtual machine on the server to temporarily run the logic. It was the same, unconverted program but just running on different hardware. Since OPC UA was used for communications, a couple of new firewall rules got the data routed to the temporary VM controller without any new mappings or drivers. SCADA was happy, and the process was back online. The whole swap was fast and secure, as is every instance of part replacement in this ideal world.
That kind of “plug-and-produce” interoperability is the intent behind open automation. Because all the devices such as RTUs, VFDs, and edge gateways implement standard protocols and information models, they are modular and vendor-neutral. This vendor-neutral interchangeability really hasn’t been supported across top PLC brands, requiring program rewrites to switch between manufacturers.
Within the next five years, open automation is poised to enhance industrial control systems with increased flexibility, interoperability, and vendor independence.
Open automation refers to an industrial automation approach that uses standardized, vendor-independent software and hardware components. Its intent is to achieve interoperability, portability, and modularity based on open international standards, such as IEC 61499 and OPC UA.
Key characteristics include:
The long-term vision is a “plug and produce” ecosystem where software components from multiple vendors can be integrated easily, akin to mobile app stores.
Fabrice Meunier, VP at the System Integrator and Software Business at Schneider Electric, stated, “Open automation represents a turning point in how industrial operations think about resilience and flexibility. When hardware and software are truly decoupled, you gain the freedom to innovate, adapt, and recover on your own terms, not your vendor’s.” Through his experience with EcoStruxure Automation Expert, he has “seen firsthand that the organizations best positioned for the future are those investing now in open standards…The competitive advantage shifts from which vendor you chose to how well your systems can evolve and integrate.”
In decoupling hardware from software, these are the core benefits of adopting open automation standards:
Still, adopting open automation standards isn’t the best immediate path for every facility. Here are some factors to consider before making the switch:
Open automation can also come with risks that need to be proactively addressed before a facility can make a worthwhile investment.
Asset Administration Shell (AAS): A standardized digital representation (IEC 63278) that describes an asset’s data, capabilities, and lifecycle in a uniform, machine-readable format, enabling cross-vendor interoperability. Central to Industrie 4.0 architectures.
Digital twin: A live, synchronized digital replica of a physical asset, process, or system used for monitoring, simulation, prediction, and analysis. Implemented in platforms such as AVEVA System Platform, TwinThread, and Azure Digital Twins.
Distributed Control Node (DCN): A small, low-cost, modular compute and I/O component within an Open Process Automation system that hosts portable, vendor-neutral control applications, replacing traditional monolithic controllers.
Edge computing: Processing and control executed close to the data source, on or near the device, to reduce latency, bandwidth, and cloud dependency. Examples include IIoT gateways, smart cameras, and edge controllers.
FDI (Field Device Integration): IEC 62769 standard for integrating field device information into engineering and asset management tools, unifying the older EDDL and FDT/DTM approaches.
Gateway: A device or service that translates between different protocols, networks, or data models (e.g., Modbus to OPC UA, OT to IT) so otherwise incompatible systems can interoperate.
IEC 61131-3: International standard defining the five traditional PLC programming languages: Ladder Diagram, Function Block Diagram, Structured Text, Instruction List, and Sequential Function Chart.
IEC 61499: International standard for distributed industrial control built on event-driven, reusable function blocks that can be deployed and executed across multiple devices independent of vendor hardware. Successor concept to IEC 61131-3 for distributed systems.
IEC 62443: International standard for cybersecurity in industrial automation and control systems (IACS), defining security levels, zones, and conduits across the asset lifecycle.
IIoT (Industrial Internet of Things): Networked industrial sensors, controllers, and devices that exchange operational data for monitoring, analytics, optimization, and control across plant and enterprise systems.
ISA-95: International standard defining the functional hierarchy and data exchange between enterprise (ERP) and manufacturing operations (MES/SCADA) systems. Foundational reference for IIoT and Unified Namespace architectures.
MQTT (Message Queuing Telemetry Transport): A lightweight publish/subscribe messaging protocol designed for low-bandwidth or constrained networks with an encrypted option (MQTTS). Widely used for IIoT telemetry and commonly paired with Sparkplug B in industrial contexts.
MTP (Module Type Package): A vendor-neutral description standard (VDI/VDE/NAMUR 2658) for modular process equipment. A supplier creates an MTP for a Process Equipment Assembly (PEA), which is imported by a higher-level Process Orchestration Layer (POL). MTP is a description standard, not a field protocol like Modbus or OPC UA.
Namespace (OPC UA): A logically scoped naming domain that uniquely identifies nodes, types, and information models within an OPC UA server’s address space, allowing multiple companion specifications and vendor models to coexist without identifier collisions.
NAMUR Open Architecture (NOA): A reference architecture from the NAMUR user association for safely extracting plant data for monitoring and optimization without compromising the core control system.
OPC UA (Open Platform Communications Unified Architecture): A secure, vendor-neutral, platform-independent standard (IEC 62541) for industrial interoperability, providing data access, alarms and events, historical data, and rich semantic modeling via companion specifications.
Open Process Automation Standard (O-PAS): A “standard of standards” from The Open Group’s Open Process Automation Forum (OPAF) that defines modular, vendor-neutral interfaces for secure, interoperable process control. Builds on existing standards including OPC UA, IEC 62443, DDS, and IEC 61131/61499.
Plug-and-Produce: The ability for a device, module, or asset to be automatically discovered, identified, configured, and integrated into a production system with minimal manual engineering. The industrial analog to consumer “plug-and-play.”
Sparkplug B: An open Eclipse Foundation specification that defines MQTT topic namespaces, payload encoding (Protocol Buffers), and session state management for industrial use, turning generic MQTT into an interoperable industrial protocol.
Unified Namespace (UNS): An architectural pattern in which all operational data is published to a single, hierarchically organized broker, typically MQTT/Sparkplug, serving as a single source of truth across OT and IT systems.