How Open Standards Support Industry’s Push for Interoperability
Key Highlights
- Connectivity is no longer measured by the number or type of physical ports, but by how easily equipment interfaces with modern tools like REST APIs, MQTT and OPC UA-enabled applications.
- Open standards like MQTT and OPC UA should be built into device architecture from the start — not added as an afterthought — to enable flexible, multi-platform connectivity.
- Cybersecurity must keep pace with openness through adherence to EU Cyber Resilience Act and IEC 62443 standards, as well as using segmented networks, multifactor authentication and role-based access controls.
Interoperability remains a persistent challenge for manufacturing. The principal reason for this has been the use of proprietary protocols and communication standards among manufacturers of control systems, sensors and other devices commonly used in industrial automation.
Though industry is increasingly moving toward the use of open systems technologies and generally easing the process of establishing interoperability, the prevelance of legacy systems and devices designed for closed-sysyem applications continues to make it difficult for manufacturers to create unified systems.
An increasingly popular path around these proprietary protocols has been open communications standards, such as Message Queuing Telemetry Transport (MQTT) and OPC UA. At Weidmuller, for example, OPC UA is a core communications protocol on its u-mation portfolio of control, I/O and visualization technologies designed for IIoT (industrial Internet of Things). Components in this portfolio function as OPC UA servers that allow Codesys-based controllers to share data with supervisory control and data acquisition (SCADA) systems, human-machine interfaces (HMIs) and an array of IIoT devices.
To gain perspective on how such open standards are helping industry overcome the barrier posed by legacy systems’ proprietary protocols, Automation World spoke with Ken Crawford (KC), senior director of automation at Weidmuller USA.
AW: How does Weidmuller currently support open communication standards like OPC UA and MQTT, and what is your roadmap for expanding this support across your product portfolio?
KC: To reap their benefits, open communication standards like MQTT and OPC UA should be part of the DNA of the I/O’s capabilities to allow extracting data from the edge in a flexible way. In other words, these standards shouldn’t be an afterthought. They should be built into the interfaces as well as the configuration to make it intuitive and adoptable across multiple architectures and platforms.
This ability to handle multiple protocols can help users to break out of that one vendor trap that so many are caught in. They no longer have to buy their controller and I/O and their HMI and SCADA software all from the same source.
Manufacturers used to be able to measure connectivity by the number of ports the hardware had. For example, did it have USB or serial ports? Did it have one, two or four Ethernet ports? Today, connectivity is measured more by the ease of interfacing with equipment. For example, how do I adopt a spreadsheet application that wants to plug in and get data from a controller?
The question the becomes: Will it use a RESTful API in a web server, or OPC UA or MQTT to receive published messages? The automation industry has pushed in the last five years to make all these protocols widely available. In our case, our operating system, u-OS, is built from the ground up to provide that level of connectivity.
AW: How are you moving away from proprietary protocols?
KC: It depends on what you call a proprietary protocol. Universal connectivity is the foundation of our value proposition. For instance, our u-remote I/O system can communicate with just about any automation vendor’s equipment, whether the equipment uses closed or open protocols.
U-remote is a modular I/O that we developed before we even offered a controller. So, its claim to fame has always been that it doesn’t matter what PLC you have. Not having a unified system of our own, we had to be able to follow 14 different protocols to enable our I/O to work in other, unified systems. As a result, we could talk to other unified systems by offering drivers, such as an EtherNet/IP driver to talk to Allen-Bradley systems.
With our history of being more of a universal company, we adopted others’ protocols rather than trying to establish our own and we’ve been open to using open protocols.
AW: How do you advise manufacturers to approach interoperability?
KC: Adopting open standards like MQTT and OPC UA is probably your first step in ensuring interoperability. But we’ve also developed a hardened Linux-based operating system called u-OS. Because it’s Linux-based, it’s a kind of open architecture that lends itself to containerization, which allows you to load and run a lot of applications simultaneously on our platform. Not only can our OS interface to networks using the protocols of 14 different PLC manufacturers, but it also can run competitors’ applications like Grafana and Inductive Automation’s Ignition as visualization platforms. At the same time, you also run Codesys and InfluxDB as a historian and data aggregator.
All these different applications talk to one another, not because you wrote a special program that stitched the output of one to the input of another, but because they all use OPC UA as their underlying transport mechanism.
All these different applications talk to one another, not because you wrote a special program that stitched the output of one to the input of another, but because they all use OPC UA as their underlying transport mechanism.
AW: How do you handle data standardization when connecting devices?
KC: Our systems can handle multiple protocols. We have the specifications for 14 protocols developed by the big vendors. So, we adhere to those specs and constantly do acceptance testing every time they release a patch or an update.
Some customers will talk to our u-remote I/O with one protocol from a Siemens PLC and then use another protocol running on our u-control PACs (programmable automation controllers) to talk to a Siemens PLC and a visualization platform. This ability to handle multiple protocols can help users to break out of that one vendor trap that so many are caught in. They no longer have to buy their controller and I/O and their HMI and SCADA software all from the same source.
AW: How do you address security concerns when implementing open communication standards and what best practices do you recommend for maintaining cybersecurity in interoperable industrial systems?
KC: Today, security is more critical than ever. You’re hearing more about poor security allowing breaches that lead to such things as HMIs showing a set point being an order of magnitude lower than a critical variable that’s been changed. These kinds of issues are what’s leading manufacturers here in the U.S. to adopt more of a cybersecurity posture with their automation.
Standards like OPC UA and MQTT shouldn’t be an afterthought. They should be built into the interfaces as well as the configuration to make it intuitive and adoptable across multiple architectures and platforms.
Our designs adhere to the European Union’s Cyber Resilience Act, which has been in force in Europe since 2024. We also follow the IEC 62443 cybersecurity standards. The result is multiple layers of security in our products, starting with the hardware and going to the OS.
We also advise that users’ industrial networks should allow for the installation of patches in front of the machine or through remote access. Network architectures should also include segmented zones and multifactor authentication. Users should also implement role-based authentication that limits the time and reach of someone’s access to need. Examples of this include restricting the access of causal users and issuing temporary passwords to vendors that provide service.
More interoperability insights from Automation World:
About the Author
