Take the Fast Lane to Automated Driving
We sat down with two experts in the field of industrial communication, Hans-Werner Auberg (Softing) and Georg Stöger (TTTech) to discuss the OPC UA Publisher/Subscriber (Pub/Sub) model, real-time requirements and the upcoming IEEE TSN (Time-Sensitive Networking) standard.
Let’s start with OPC UA. What exactly is it and what is it useful for?
Auberg: OPC has a 20 year history in the market of industrial communication and it’s a well-established platform for industrial communication between SCADA systems, MAS systems, field applications and shop floor applications. But we also learned that there are some limitations on the system, for instance the dependence on DCOM functionality from Microsoft. Because of this we implemented a new protocol, a new architecture called OPC UA which is now fully independent of any operating systems, fully based on TCP/IP or in the future also on UDP. So now we are able to bring this open standard not only to the SCADA system but also down to the device or down to the controller, and we can create a fully distributed control system based on UA. So OPC UA is a really good management platform for industrial data, and it is also a standard connector into the IT world and from my point of view the only open standard that provides access for everybody – the IT people as well as the control people.
Stöger: OPC UA is a data management platform for industrial control systems. It is industry and application independent, and very importantly it’s vendor independent. Nobody owns OPC UA; it’s an open standard with a wide and quickly growing eco-system. It supports use cases for solutions like cloud-to-machine or cloud-to-factory connections where other platforms solutions, such as PROFINET for example, are not so strong. It offers all of the necessary services today – like encryption and security, browsing and services discovery, data logging and historian functions. But as of today it lacks one thing, and that is the real-time capability for machine-to-machine and machine-to-fog connections and data management.
Georg, you mentioned real-time capabilities, can you explain how real-time fits into the picture with OPC UA?
Stöger: For the machine people, real-time is one of the key properties of what they do. In controls and motion and even in process you must have some amount of real-time. Even if it’s not very fast, it is necessary because you are responding to physical properties of the world. In the IT world that’s totally different because there, performance is important but real-time isn’t a criterion so anything which is fast is good and anything which is slow is probably annoying, but meeting deadlines is not really a requirement. So the concept of real-time, which is very common in motion and in automation systems, is just not applicable in the IT world. Therefore any management system such as OPC UA, which aims to combine these worlds, must somehow be sensitive to the requirements of both sides. Until now OPC UA has not provided real-time functions, but as the OPC community starts to demand that real-time capabilities be added to OPC UA, real-time behaviour in the software and on the network suddenly becomes a requirement. That was not true in the past, but it is becoming true now so it requires some new concepts within the framework of both, the specifications and the implementations of OPC UA.
Auberg: To add to that, real-time does not mean performance in terms of being first, it means being deterministic. We aren’t talking about isochronous communication where you have to be really fast at the same time, we are talking about standard real-time where you get a time-window in which you have to deliver. There was no real-time demand on OPC in the past because everything was user driven. Thinking about a traditional SCADA system; it gives some control in terms of seeing some behaviours of the system on the visualization, but that happens totally asynchronously to the rest of the process, so if everything is asynchronous you don’t need any real-time. But now if you think about IoT and machine-to-machine communication, we have to exchange data like PROFINET or EtherNet/IP does, and there you have some real-time requirements. Real-time means it has to be delivered in a determined time-frame and industrial communication cannot work without real-time, 100 percent sure. So if we want not to replace but to add additional functionality to the current Industrial Ethernet structure, we have to add real-time also to the OPC UA.
OPC UA users might have heard about the Publisher/Subscriber (Pub/Sub) communication model. Can you tell us what this is and what it will do for OPC UA?
Auberg: When we talk about OPC UA, there is a client-server architecture, where one part of the server provides the data and another part is doing the acquisition, always in a fixed point-to-point relation. It’s done asynchronously – while one is doing the acquisition and the cyclic process, the other one is taking the data out of the system at some time-point. Now with Pub/Sub you get the functionality to define a fixed time-window where you exchange data, not point-to-point but with a multi-point connection via UDP. This gives you a communication frame which is addressed to many other PLCs, not only to one. And that’s the biggest advantage; that you have a defined time-frame with multiple addressing.
Stöger: Not a lot to add to that, maybe an example from everyday life: If you’re interested in a specific telephone number you can call up a directory. This is totally user-driven and you don’t really care whether or not the service responds in real-time because all you want is the information. However, if there is a service which gives the time in order to synchronize watches, that needs to be broadcast so that it goes to everyone who is interested simultaneously. This multicast service will also need to always be online in order for you to synchronize at any time. So there is a big difference between an on-demand information exchange which is between the client and the server, and a multicast service like the one that Pub/Sub will establish. The publisher may not always have to offer a real-time service, but we know of numerous industrial use cases where a real-time mechanism will be required.
OPC UA users may also be aware of the upcoming IEEE TSN standard. What impact does this have on OPC UA compared to current Industrial Ethernet solutions?
Stöger: OPC UA is a distributed platform so obviously there is always networking happening. However OPC UA by itself does not depend on a specific type of network so quite different network sizes, network topologies, network speeds and network technologies can be used and OPC UA will always work with any of them. As soon as we have the real-time requirements that we’ve discussed for OPC UA architectures, the type of network we are using becomes relevant. OPC UA typically runs across standard IP-based Ethernet networks which provide a lot of performance and are very flexible but do not guarantee real-time behaviour at all. So depending on the load on the network, the topology on the network and the components which are currently active in the network, the same Ethernet network may sometimes be rather fast and sometimes be rather slow and you cannot really know as a user of OPC UA services how the network will perform the next time you need it. Industrial Ethernet from the beginning has been developed to support real-time requirements but is typically constrained in its flexibility. So it often has to be a well-architected network which meets the needs of a certain machine or a certain application but is not as flexible as standard Ethernet on which OPC UA typically operates. The Time-Sensitive Networking standardization effort happening in the IEEE 802 is now bringing real-time capabilities into standard Ethernet. With TSN, for the first time standard based Ethernet will have capabilities for guaranteed in-time message delivery. It is compatible to any other standard Ethernet based applications and transparent to higher layers and it can be used to guarantee real-time delivery of certain messages in a network. For these reasons, TSN can be the platform for OPC UA Pub/Sub real-time use cases.
Auberg: Very difficult to follow a specialist on TSN but just one point to add, because at the beginning you asked about Industrial Ethernet and in the current Industrial Ethernet world there are advantages and disadvantages. The basic advantage is that they run a control loop between one controller and a lot of devices where the control is initiated by one system only. The disadvantage these systems have is in controller-controller communication because that’s not what they are focussed on. Pure controller-controller communication is not foreseen in these systems and work-around solutions are needed. OPC UA comes more from the controller to ERP or IT connection and this means that there are uses for controller-controller communication. But even there we have to synchronize controllers, so we need some time-stamps in between, we have some determinism requirements and that’s the biggest challenge for Industrial Ethernet systems. Typically they cannot follow, for instance PROFINET has some disadvantage there and they are still working on it. With TSN we can solve this problem and establish easily a master-master, controller-controller communication with the integration of the IP / IT world, and that’s one advantage if you combine OPC UA and TSN from my point of view.
What is your vision for the adoption of these new standards?
Auberg: The vision is for a standard world, using standard Ethernet without any special components. There’ll be standard chips using TCP/IP providing determinism on a low cost level and offering a very easy entry point for the customers. Currently we have a situation where special Ethernet protocols are implemented somewhere in the lower layers, 1 to 2 or 4 maximum, and this requires specific knowledge by the customer. With TSN and Pub/Sub we can solve this problem using just standard Ethernet with just standard OPC UA.
Stöger: I think cost saving will be a major driver for innovation in this area. Industrial Ethernet solutions are specially tailored for the requirements they solve, which they do very well. But the disadvantage is, as we just heard, that they can’t solve other problems so well, or that they cannot even be used for other types of networking needs. So any advances that Ethernet makes – like going into the gigabit or 10 gigabit range, inventing new physical layers, making configuration and management easier - cannot flow into the world of Industrial Ethernet today because Industrial Ethernet was specifically tailored and cannot easily be modified to adopt those new advantages. If something is part of standard Ethernet but also has the necessary deterministic properties required by industrial networking, then this adoption becomes much easier, and therefore will be much cheaper.
Many thanks to Hans-Werner Auberg (Managing Director, Softing Industrial Automation) and Georg Stöger (Director Industrial Projects and Products, TTTech) for taking the time to answer our questions.
Hans-Werner Auberg, Managing Director - Softing Industrial Automation GmbH
Auberg joined Softing in 2006. His responsibilities included strategic marketing for Industrial Ethernet and product management for factory automation products. In his current role as Managing Director he is mainly in charge for the product management in factory & process automation. His team specializes on industrial communication, network diagnostic, asset management and data integration. Softing Industrial Automation is also driving OPC technology now for more than 20 years. Auberg lives in Augsburg and works in Haar b. Munich, Germany.
Georg Stöger, Director Products & Projects Industrial - TTTech
Stöger holds an MSc in computer sciences and joined TTTech in 1998. His responsibilities included embedded software design, architecture consulting and technical trainings for real-time control networks as well as specifications of time-triggered protocols and systems. He currently holds the position of Director Products & Projects in TTTech’s industrial business unit. His team specializes in development and services for deterministic networking and robust distributed control systems. He lives and works in Vienna, Austria.