Here we chat with Beckhoff Automation’s Daymon Thompson to explore how changing specifications and maturing digital initiatives are clarifying the modern industrial landscape for both OEMs and end users.
Q: What does the new publisher/subscriber specification bring in terms of new capabilities?
A: Consider the traditional client server vs Pub/Sub. Traditional TCP Ethernet is usually the transport layer for OPC UA data access (DA) which is probably the most commonly known OPC UA specification.
Traditional TCP communications works in a client/server architecture where the server is available to wait for clients to connect. In the traditional PC networking setup this makes a lot of sense. We think of the server as a piece of hardware that perhaps sits in a server room and in this case, all of the PCs in the network are clients that know how to get to the right server either by its device name or IP address.
In the traditional implementation of OPC UA, the machine controller becomes the server and the software reading and writing to that controller becomes the client. This is a very simple setup when the client is something like an HMI that connects to one or a few controllers. As this type of architecture scales up, it can get a little harder to maintain. For example, in a manufacturing facility with a few hundred controllers all connected to the network, the upper-level software such as a SCADA system or ERP would need to know the device name or IP address of each one of those OPC servers to be able to get the data.
Q: And how does the Pub/Sub principle come into play here? How does this affect processes?
A: In the first example of machines connecting to each other horizontally in a production line, OPC UA Pub/Sub over UDP can be used to eliminate the need to address each device by name or IP address, while keeping the common data types and structures as defined by the OPC standard.
With MQTT, rather than each device and application knowing the specific name or IP address of every other application or device, the applications and devices who participate in communications only need to know how to access the central message broker. If new clients or servers are added to the network, new data can be exchanged without having to configure device-specific information.
In the example of scaling to hundreds of machines in a facility, the need to manage the connections from ‘many to many’ devices can remedied with a ‘many to one’ type architecture. The key here is that with the OPC UA Pub/Sub specification (Part 14), you can choose whichever method works best for you without giving up the power delivered by OPC UA.
Q: How are machine-to-machine initiatives maturing? Who benefits from this maturation?
A: OPC UA Data Access based on the Client/Server architecture is great for managing low-frequency data (10 ms and above, e.g. supervisory control). Pub/Sub via UDP is great for working with high-frequency data (1-10 ms range, e.g. streaming real-time data).
This is a good step for a vendor neutral, common communications standard where each device in a production line can understand and exchange data between devices from multiple vendors – and now it can be done faster and with a simpler setup.
The OPC Foundation is also working on a C2C, controller to controller specification to include offline communications setup, and the possibility to establish communication over UDP or TSN. I expect that it will be some years before multiple automation vendors have this specification implemented into controllers, but it will be very interesting to follow its progress.
For OPC Pub/Sub, most automation, controls and equipment vendors only support the UDP transport method at the moment, not MQTT.
Q: Why do you think most manufacturers are focused on implementing the UDP transport mechanisms for OPC Pub/Sub and not also including MQTT as transport?
A: Most automation, controls and equipment suppliers rely on third party OPC SDK technology. This means they don’t write and maintain their own OPC UA communications stack, it’s acquired and integrated into their products. For Beckhoff, we started developing our OPC Pub/Sub communications stack in late 2015 even as the specification was still under development and we were the first automation vendor to implement OPC Pub/Sub via UDP and MQTT.
Q: Describe a device-to-cloud scenario and explain who can take advantage of this approach.
A: A common communication protocol from automation equipment to the cloud is MQTT, however this is just the transport mechanism, or the ‘delivery truck’ so to speak. What goes in that truck is up to the technology implementor. The data can be binary in which both sides would have to know exactly how the data is structured. The data could also be strings, but this would be very hard for each side to parse the meaning, or the data can be organized into formats like XML or JSON.
Major cloud service providers such as AWS and Microsoft Azure have implemented OPC UA Pub/Sub MQTT as a communications standard, enabling machine builders and end users to use the known OPC UA specification to quickly and easily connect machines to the cloud.
Robust cybersecurity is inherent to the OPC UA specification. Security is handled differently with MQTT, so by using OPC UA, the data can be encrypted at the application level. This contrasts with MQTT, where its security relies on each broker along the route not being compromised. This means OPC UA Pub/Sub over MQTT offers ‘end to end’ encryption and a complete solution.
Q: What do these capabilities enable for the modern manufacturer?
A: End users can specify that the machines they receive must include these standard communications, and they can be assured that they will simply plug into their existing IoT systems without much engineering. Machine builders that embrace these standards can count on fewer custom implementations for their customers.
If a technology has a low barrier to entry with low effort and cost required to implement data collection and analysis like OPC UA does, then it’s more likely to implemented. And we know the many benefits to end users and equipment OEMs are clear.
For more information visit www.beckhoff.com/OPC
