Internet of Things
OPC UA - a must for the industry (Part 2)
OPC UA is regarded as the new communication standard for industrial automation. Part 1 explained why a new communication technology is needed in automation and described the OPC UA methods. Part 2 deals with the OPC UA pub/sub methods and the power of modeling.
The slogan 'IT meets OT' is becoming a reality thanks to OPC UA and brings valuable added value to OT, which has been dormant for over 30 years - in terms of consistent IT usage. The OPC UA methods play a major role in this. To ensure that all the advantages of OPC UA client/server methods can also be used in hard real time, some members of PLCopen and the VDMA have formed a working group on the occasion of the Devokos project and the VDMA OPC UA demonstrator, which has set itself the task of implementing the OPC UA methods on the basis of OPC UA Pub/Sub. From the outset, it was an important requirement that the modeling of pub/sub methods should differ as little as possible from that of client/server methods so that a simple changeover is possible. As always with OPC UA, the pub/sub methods should also be technology-independent and be available for PLC programming, Node.js as well as for high-level languages such as C/C++, Java and C#. Finally, another important requirement was to implement the pub/sub methods as performantly and efficiently as possible - after all, it is mainly about use under hard real-time conditions.
Compensation for the missing fuse layer
The first and most important requirement was to find a way to compensate for the missing UDP data link layer. This was solved with a mechanism that has always been used with conventional fieldbuses and which is as simple as it is stable: cyclic repetition.
Like fieldbuses, OPC UA Pub/Sub for use at controller/field level has a type of process data image that is exchanged cyclically between the participants, for example every millisecond. Every communication participant that wants to implement a method caller or callee must be able to both send and receive data cyclically. Therefore, each caller or callee must have both a publisher and a subscriber. Thanks to the one-to-many principle of pub/sub, which is implemented on UDP using multicast, a telegram from a publisher can contain data for several subscribers simultaneously. This is very helpful in typical line architectures with one master and several slaves. With appropriate hardware support and 'frame aggregation' with a total frame telegram and on-the-fly processing, it is also possible to return data from the slaves to the master in a single telegram. The Shaper Group, which was merged into the OPC Foundation's new FLC initiative at the end of 2018, was already working on this.
The basic principle of securing OPC UA pub/sub methods is now that the publishers in both the caller and the callee keep the data in their send buffers unchanged and repeat it cyclically at least until a response to this action is received from the other side. For this purpose, each action is provided with a continuous sequence counter. The other side does the same, namely it also leaves its send data pending until the original side has reacted to it. This leads to a kind of implicit token ping-pong, whereby only one of the two sides has the token to change the send data, for example to report the current method as completed (Callee) or to initiate the next method (Caller). If an Ethernet telegram is lost, this is not a problem. As the other side has not received it, it will not react to it and will receive the same telegram again in the next cycle. It is clear that this procedure can reduce the response time by one or more clock cycles, but this has been the case on most Ethernet-based fieldbuses for many years - and industrial automation still works. Why? Because the communication cycle time is usually much shorter than the maximum acceptable deterministic latency time and therefore many telegram repetitions take place before the deadline has expired. And because additional mechanisms such as telegram and sequence counters or time stamps allow both sides to easily determine whether and how many or how long telegrams have been lost and to react accordingly. The basic principle of methods with their variable back and forth can be implemented excellently on the described token ping-pong procedure without further handshakes or telegram repetitions within a cycle.
The token ping-pong
Another feature of this token ping-pong method is that several methods can be active at the same time. Each simultaneously active method only requires a few bytes of management data and, of course, the space for the back and forth variables in the pub/sub process data image. So that the size of the process data image does not have to be changed dynamically all the time, methods that are not active at the same time, such as C/C++ unions, occupy the same maximum memory space within the cyclic process data image. However, several simultaneously active methods for the same callee do not appear to be necessary, as a method should be very short-lived and should only be used to switch state machine instances, for example. There can be as many of these state machine instances active simultaneously in the callee as is necessary for the function of the callee.
Another advantage of pub/sub methods over client/server is that a publisher and subscriber must necessarily be contained symmetrically in each participant. This means that each subscriber can be a method caller or callee without further ado. This is not so easy with client/server. There, only a client can call methods on the server. For a symmetry of method caller/callee on both sides, each client node would also have to contain a server and vice versa.
A welcome side effect of pub/sub methods is the fact that pub/sub is usually used on the MQTT or AMQP transport protocols for OPC UA-based cloud communication. Since Pub/Sub and all services based on it work on all transport protocols intended for Pub/Sub, Pub/Sub methods can also be used for method calls from the cloud to the device or vice versa - in principle without the real-time aspect. However, the prerequisite is that the pub/sub channels are implemented in both directions.
The power of modeling
Figure 1: Regardless of the programming language, the engineering systems use the device information to generate the library source code for controlling the devices.
© KukaWith OPC UA, the data, method or state machine properties of a device or machine must be modeled accordingly in the information model in Companion Specifications. The VDMA has already started working in more than ten working groups to create corresponding Companion Specifications for various machine types in its specialist areas across all manufacturers. The first wave, which is currently underway, is focusing more on data that is to be read from the devices and sent to higher-level systems such as SCADA, MES, ERP and the cloud. In an upcoming second step, methods for controlling the machines and devices will also be developed.
Figure 2: The 'Method Stack' - bottom right in the picture - with its simple method state machine.
© KukaThe methods with their In- and OutVars, or the state machines with their states, transitions and methods for triggering the transitions must also be defined in the Companion Specifications. This modelling constraint results in a possible additional benefit that has the potential to revolutionize industrial automation. Similar to USB on PCs, the engineering system of the controllers (the caller) can receive the Companion Specifications of the devices to be controlled (the callees) offline as an XML file or read them out online via the OPC UA server of the device. Using the device information, the engineering systems can automatically generate the library source code for controlling the devices for the application programmers, regardless of the desired programming language. The workflow for this is shown in Figure 1. Additional program code must be available to implement the methods via OPC UA Pub/Sub, namely the 'method stack' (Figure 2) with its simple method state machine. This is also generated accordingly by the generation tool and is based on the regular pub/sub stack.
An exemplary tool for generating the library source code will be made available in due course by the working group on Github as an open source project so that the various engineering system manufacturers can integrate the source code generation mechanism into their engineering systems in a standardized and interoperable manner.
First step: PLC function blocks
Figure 4: The behavior of each individual FB instance in the callee is stateful. It is mapped in an FB state machine type that is common to all FBs.
© KukaAs an example, the OPC UA pub/sub methods are first implemented to realize PLC function blocks of PLCopen. The PLCopen 'Motion Control Function Blocks' (MCFB) have a well-defined 'Application Programmer Interface' (API) for controlling drives (Part 1/2) as well as kinematics such as robots (Part 4) for the automation programmer. This API consists of a collection of function blocks (FB), whereby each block always has a function name and associated input/output variable (Fig. 3). All FBs of a part each follow a higher-level FB family state machine, which is also defined in the corresponding PLCopen specification. This results in the following hierarchy of state machines in the callee:
- The basic machine/device state machine as specified by the VDMA.
- The entire MCFB family state machine runs in the state for controlling the device from 1.
- Each FB has the same FB state machine (Fig. 4).
- Each method has a small, implicit state machine.
The MCFBs were originally created to provide local motion subsystems directly available on the PLC with a PLC API by implementing the corresponding motion blocks. The aim was to control individual axes, coordinated axis movements such as phasing, gearing, camming (Part 1/2) and kinematics (Part 4) from the programmable logic controllers. The motion subsystems commissioned by the PLC in this way then only controlled the cascade controllers in the respective drives via corresponding drive buses such as Sercos, Ethercat or Powerlink. With the OPC UA pub/sub methods, the PLCs no longer require local motion subsystems. Instead, the actual motion task of an FB remains in the drive or in the kinematics and is only controlled remotely, so to speak, via a proxy stub of the FB remaining in the PLC using OPC UA pub/sub methods. The behavior of each individual FB instance in the callee is stateful and is mapped in an FB state machine type common to all FBs (Figure 4). Only the FB instance name and In/OutVars distinguish the individual FBs from each other. Figure 5 shows the exemplary modeling of an FB in OPC UA notation.
An FB can be started either edge-triggered at the Execute input (ETrigType) or by a statically applied signal at the Enable input (LConType). With ETrigType, the InVars are only accepted with the rising edge of the Execute input. A change to the InVars by the caller while the FB is active has no effect on the Callee. With the LConType, on the other hand, the FB is active as long as the Enable signal is present at logic 1, and the current InVar values are transferred from the caller to the callee with each CheckExecuting method. With both FB types, the current OutVar values are transferred back from the callee to the caller as return values of the CheckExecuting method.
If the caller sends the Abort method instead of the CheckExecuting method, the callee aborts the current instance of the FB and waits in the Dormant state for new method calls. The CheckDormant method is a type of NoOperation and is only used to query the status of the callee without wanting to provide it with new tasks.
Any OPC UA methods for real-time applications between controllers and to the field level, but also for forwarding state machines, offer completely new possibilities for solving automation tasks much more directly at application level.
The new possibilities
It is no longer up-to-date or necessary to map device functions to bits and bytes as on fieldbuses and first create your own access libraries after consulting the corresponding bit tables from the automation device documentation. Instead, the device services can be called directly by the application programmer after the access libraries for the automation devices have been automatically generated for the corresponding engineering environment based on the corresponding OPC UA device modeling. The automation device indirectly provides its own drivers for control - even in source code.
The current working group will develop the corresponding tools and sample implementations and make them available on Github in due course. In addition, interested companies are invited to participate in the current work through review, feedback and, if necessary, active collaboration. At the same time, efforts are being made to contribute the OPC UA pub/sub methods to the OPC Foundation for standardization. After all, the OPC pub/sub methods only make sense if they work across manufacturers in controllers, devices and machines.
This article was written in cooperation with Codesys-Consulting.
Author:
Heinrich Munz is Lead Architect Industry 4.0 at Kuka.
You might also be interested in
Wago gears up for Time Sensitive Networking (TSN)
In the future, Ethernet TSN will enable continuous communication in machine and plant engineering without gateways and interruptions. Wago is launching two new automation systems on the market for the SPS, with which users can take advantage of all...
read more...Arrive in reality!
Time Sensitive Networking has firmly established itself in the vocabulary of the automation industry. All well-known suppliers have started activities to evaluate or even introduce TSN. But where exactly are the goals for the use of TSN and what is...
read more...OPC UA and DDS combined
To date, OPC UA and DDS have often been presented as competitors. Competitors that will both be based on the Ethernet standard TSN. - However, the key to successful automation in the future lies in a combination of the three standards DDS, OPC UA...
read more...The interaction of Ethernet TSN, OPC UA and 5G
Only the reliable and structured interaction of all units in an ant colony ensures its survival. Data communication in a modern industrial network works no differently in a figurative sense.
read more...Where there are still problems with 5G
5G in automation - a hot topic at the moment. How quickly can we actually expect 5G to be used in industry? What obstacles still need to be overcome? Thomas Schildknecht summarizes the key points in this interview.
read more...Data pipeline ASi-5
High data width, short cycle times, improved integration of intelligent sensors and actuators using IO-Link and cloud connectivity via OPC UA - ASi-5 makes AS-Interface fit for the requirements of digitalization.
read more...OPC UA, MQTT and co.
The Industrial Internet of Things (IIoT) covers very different areas of application. The available connectivity technologies and standards are just as diverse as the application areas. How can the right technology be filtered out in each case?
read more...The question of licenses
Will OPC UA in combination with TSN become 'the' standard for industrial communication? What role do licenses play in this question and what part does OSADL play?
read more...The safety solution for OPC UA
Safety over OPC UA based on Profisafe: A year ago, the OPC Foundation and PI launched a joint concept for this. Now the specification is about to be published and is available for OPC UA-based controller-controller communication.
read more...