OPC UA is the new information and communication standard (ICT) for industrial automation. There has been no doubt about this since SPS IPC Drives 2018: over 20 of the world's leading automation providers actively committed to OPC UA and TSN as part of the OPC Foundation's Field-Level Communication (FLC) initiative. After four years of intensive negotiations between all well-known global automation providers, the implementation phase is now beginning. OPC UA must now be made fit for industrial automation - from sensors and actuators at field level right up to the cloud. Technology disruptions in the automation pyramid should soon be a thing of the past.

But why is there an urgent need for new ICT in industrial automation? After all, conventional fieldbuses have been doing their job for over 40 years.

Disadvantages of today's automation

A major disadvantage is the large number of existing, non-interoperable fieldbuses and the technology disruptions when moving from one level of the automation pyramid to the next. Every device manufacturer has to develop and maintain the connection and engineering of each of its products to more than ten different fieldbuses - a business and economic disaster.

All of these fieldbuses have only rudimentary semantic modeling capabilities. The simple mapping of data and device functions to bits and bytes of the different fieldbuses in device profiles is the highest of feelings. Powerful, object-oriented options for the semantic self-description of complex machines and components, such as inheritance or direct function calls, are not available with conventional fieldbuses.

Over the years, automated machines such as tools, injection molding machines, robots and the controllers for the processes that support the robot arms have become increasingly powerful. However, much of their performance capability cannot be used at all, as the cooperation of the individual network nodes is restricted by the bottleneck of fieldbus communication.

Another obstacle is the need for decentralization and component-centric thinking. Solutions such as a modular cell always comprise a large number of automation components. Each of these must be configured and programmed individually - usually using different engineering tools from different manufacturers.

Model PC

The goal: Just like USB on a PC, OPC UA should help any controller to identify connected devices in the same way.

© Munt

Wouldn't it make more sense to focus on the entire solution instead and to program and configure an automation task centrally in one place, with the automation components used merely representing peripheral devices? Just as a person has arms, legs, eyes and ears, but only a single central brain. Or in the same way that a printer, mouse, keyboard and hard disk are connected to a PC, which then takes control of all the peripheral devices. And just as USB helps the PC to identify and control the connected devices, OPC UA can help the controller to identify the components to be controlled and make the corresponding access libraries available to the automation application programmer through automatic code generation.

Current products from various robot manufacturers represent an initial approach in this direction: Robots that no longer have to be programmed individually, but whose atomic motion commands come directly from the higher-level PLC or the Edge. The motion subsystem remains in the robot, the PLC merely triggers the movement commands and monitors them, just like many other concurrent processes that form the overall solution for controlling an entire cell. Unfortunately, this scenario can only be realized today via conventional fieldbuses and is proprietary to each robot manufacturer.

OPC UA - more than just a protocol

With OPC UA plus some additional transport technologies such as TSN, MQTT or AMQP, all the disadvantages listed above are a thing of the past. Of course, conventional fieldbuses and OPC UA will continue to coexist peacefully for many years to come. But whenever true manufacturer-independent interoperability with modern IT modeling tools is required, there is no way around OPC UA.

While OPC UA, like fieldbuses, also contains protocols for pure data transmission, the information technology (IT) for semantic self-description and modeling of communication participants in OPC UA is very powerful - this is the real and essential difference to conventional fieldbuses. OPC UA is independent of the physical transmission and can be used on any Ethernet such as GBit, WiFi, mobile radio or cloud protocols. It offers services such as browsing the device information model, read/write/subscribe data and methods.

With uniform information and modeling technology, OPC UA offers two different communication patterns: Client/Server and Publisher/Subscriber (Pub/Sub).

While client/server represents a directed point-to-point connection in which the OPC UA client can retrieve and process services and data from the OPC UA server, pub/sub represents undirected one-to-many communication. The publisher sends one and the same message to many recipients in the network at the same time, regardless of whether there are no, one or many subscribers for the same message. This can take place cyclically - regardless of whether the message has changed or not - or alternatively non-cyclically only if data has changed.

In addition to these distinctions, however, there are also some technical constraints regarding the transport technologies. For example, the client/server pattern is only based on TCP/IP-based communication or websockets, while pub/sub is specified for UDP/IP, TSN (MAC layer 2) including multicast or the AMQP and MQTT broker services. Due to the mandatory use of TCP, client/server and all services based on it, such as the previous methods, are not possible with sufficient deterministic real-time capability as required for industrial automation. The specified time span here is in the millisecond range and below.

The advantage of TCP-based communication is that TCP itself ensures secure communication with subordinate confirmation and repetition. This type of communication security is necessary as telegrams can occasionally be lost in Ethernet-based communication. As TCP communication security is random and not deterministic, TCP is generally not suitable for real-time tasks in the (sub-)millisecond range. However, the TCP and OPC UA client/server software stacks in the devices are also not designed for hard real-time communication and are also not suitable for this due to their power.

The shortcoming of the lack of real-time capability is eliminated with the unsecured UDP/MAC-based pub/sub and both the UDP and the pub/sub software stacks can be kept lean and therefore hard real-time capable. However, since the UDP protocol lacks any security layer, the error-free transmission of Ethernet telegrams must take place in a different way in the higher protocol layers up to the application level.

UDP/MAC-based Pub/Sub can therefore basically be used in real time, provided that other boundary conditions such as the correct implementation of drivers, stacks and network infrastructure such as switches are met. Unfortunately, however, the OPC UA pub/sub pattern has so far lacked the ability to execute method calls.

The OPC UA methods

OPC UA methods are comparable to remote procedure calls (RPC), which have long been known in computer science. A service consumer (caller) wants to initiate a specific service call - often also called a method, procedure or function - to another participant (callee) that is disconnected via the network. The caller sends the desired service with the corresponding transfer parameters to the callee. The called callee executes the requested service with the transferred parameters, returns the corresponding return parameters to the caller and thereby reports the completion of the service call or an error message if something has gone wrong. This is comparable to a function call within a computer program with forward and return parameters, but across the network.

The OPC UA architecture: With uniform information and modeling technology, OPC UA offers two different communication patterns: Client/Server and Publisher/Subscriber (Pub/Sub).

© OPC Foundation

Such network-wide function calls are a great help in building a service-oriented architecture (SOA). Industry 4.0 follows an SOA, which is why the OPC UA methods are indispensable for the implementation of Industry 4.0. Other stakeholders of network-wide method calls include functional safety applications due to the possibility of atomically indivisible consistency of call and return variables, PackML or the Intelligent Assembly Solutions (IAS specialist department of the VDMA to allow machine modules to communicate with each other via methods), various funding projects such as DEVEKOS or BaSys, function blocks distributed across the network according to PLCopen (such as Motion Control Function Blocks - MCFB).

From the caller's point of view, a method call in pseudo code can be implemented as follows:

if (READY == Method(Name, InVars, ref OutVars)) {
Method is finished and OutVars are valid
} else {
Method is not finished, OutVars are not valid
}

The function call in the caller's program code called Method() takes over the InVars variable structure, triggers the 'Name' action via the network on the Callee side and should return immediately with a status value so as not to block the caller's program run. The status value of this non-blocking, asynchronous local function call indicates whether the callee method has ended or whether a formal error has occurred during the call. The caller must call this function until the status is 'READY'. The method is then completed in the callee and the OutVars are valid. InVars and OutVars in OPC UA structures can be variable collections of any data type such as bool, integer, real, string, variants. As long as the service continues in the callee and in the communication mechanisms, it cannot be interrupted. This is also referred to as a blocking or synchronous function call via the network.

This property of passing and returning variables to a method that cannot be interrupted by other network participants results in the possibility of atomically indivisible read/write operations, such as Test and Set (TaS), as required for mutual exclusion or semaphore operations. With OPC UA methods, network-wide semaphores are possible if implemented correctly in the participants.

OPC UA methods - Gearbox for state machines

An OPC UA state machine always has three characteristics: states, methods and transitions. The OPC UA Programs State Machine has 4 states, 5 methods and 9 transitions.

© Munt

According to the OPC UA philosophy, the methods for longer-lasting callee services should not be used directly so that the individual methods are not occupied for the entire duration of the service in the case of longer-lasting services such as machine movement commands. Instead, it is recommended to implement corresponding state machines in the callee and to use the methods only for the forwarding of the state machines through transitions.

As mentioned, the local function call Method() in the caller immediately returns to the caller and the caller can recognize from the direct return value whether the callee has already completed the method or not. This type of line-oriented concurrency with mainly asynchronous or only very short synchronous function calls - in contrast to thread-based concurrency with local functions that block for longer periods of time - is a characteristic of the PLC programming paradigm widely used in the automation industry. Significantly, the web server-side JavaScript programming called Node.js, which originated in modern web IT, also uses this paradigm. The reason is: Node.js was developed with a particular focus on performance.

When many things need to be monitored and processed in parallel and virtually simultaneously, line-oriented concurrency achieves much better performance values than thread-based concurrency. Since there is only a single main thread that controls many concurrent actions, there is no need for semaphores and other inter-process communication mechanisms (IPC), which would make the automation solution complex and error-prone.

To ensure that the modelling and implementation of state machines in the callee with their states, transitions and methods for switching states can also be carried out in a standardized manner, the OPC Foundation has defined in Part 5 of the OPC UA specifications how state machines are to be modelled and structured. Finally, an exemplary state machine, called 'Programs', was modeled in Part 10.

This article was written in cooperation with Codesys Consulting.

Author:
Heinrich Munz is Lead Architect Industry 4.0 at Kuka.