Table 1: Milestones in the history of OPC UA

© OSADL

It is remarkable that a number of automation technology providers - which together probably cover more than 95% of the market - are now speaking out in favor of a standardized, real-time-capable communication system at SPS IPC Drives 2018. It is also noteworthy that with OPC UA PubSub via TSN, the companies have not opted for any of the more than 50 different fieldbuses or real-time communication methods used to date. Instead, an information model that has only been used for one area to date is being combined with a synchronization protocol that also exists but has not yet been used for this purpose, and is being jointly developed and standardized.

The agreement process may have been simplified by the fact that no provider now has the advantage of being able to continue using its own process, but all companies involved must familiarize themselves with the new process with similar development effort. The choice of processes that have already been used for a long time in a different context(see Table 1) could also have the advantage that there are either no relevant patents for them or, if there are any, they only have a short remaining term.

OPC UA - the license issue

Compared to many other methods, OPC UA has a very powerful information model that allows data to be exchanged between different types of participants without previously defining rigid protocol telegrams at bit level, as is usually the case. However, general and unrestricted use in research and industry was hampered by the fact that there was no reference implementation that could be used industrially under a free license and combined with proprietary software. This is because the OPC Foundation's reference implementation in ANSI C is dual-licensed - either for members of the OPC Foundation under a proprietary license or for non-members under GPL-2.0. However, the latter does not allow linking with a proprietary application, which is essential for use in industry. This licensing was all the more surprising as, since the provision of TCP/IP under the permissive BSD license of the Berkeley Software Distribution and the worldwide triumph of this Internet protocol, it was generally clear that a protocol with a comparable claim must be under a free and unrestricted license.

Furthermore, the reference implementation of the OPC Foundation only implements the so-called protocol stack and does not provide a complete SDK for client and server applications. For this reason, the 'open62541' cooperation project was launched at the end of 2013 by the Chair of Process Control Engineering at RWTH Aachen University, the Fraunhofer IOSB in Karlsruhe and the Chair of Process Control Engineering at TU Dresden. The Fortiss research institute and a number of companies from the field of industrial automation are now also involved in the development.

The license used for the open62541 project is the Mozilla Public License version 2.0 (MPL-2.0) with a weak copyleft, which allows software licensed in this way to be linked and distributed with a proprietary licensed application. An important license obligation of MPL-2.0 is, among other things, that each recipient of such a linked application must be informed where the freely licensed source code of the library used is quickly and easily available. Although this license obligation is more complex than that of the very generous BSD license of TCP/IP, it not only does not stand in the way of unrestricted distribution, but on the contrary promotes the joint further development of the software.

The integration of TSN in OPC UA PubSub

Recently, the phrase has repeatedly appeared that you only need to "switch from UDP to TSN" if you want to give OPC UA PubSub real-time properties. Unfortunately, this wording is all too misleading and also technically incorrect. This is because UDP is a layer 3 protocol, while TSN is a generic term for a whole range of layer 2 processes that are mainly implemented in the hardware or firmware of the network adapter. The main procedures currently standardized and already implemented, for example, in the Intel network adapter I210 and in the corresponding Linux driver from patch level 4.19 concern the high-precision synchronization of computers, bandwidth reservation and the time-stamp-based sending of network packets.

This means that you cannot simply 'switch over', but must purchase suitable hardware for all the computers involved, configure computer synchronization, update driver and configuration software and create and use the command lines, which are still extremely complicated at present.

If there are plans to use switches, suitable Layer 2 or TSN-capable switches must be purchased, which are around ten to twenty times more expensive than conventional devices. OSADL operates several TSN test tracks in its QA farm in order to be able to determine this expense and the performance - especially with regard to the achievable real-time properties.

First TSN test results

The test tracks were also used to time-stamp OPC UA data packets and check their real-time behavior. The results confirm the expectation that OPC UA PubSub via TSN has the potential to achieve comparable technical data to the currently established real-time Ethernet protocols and to be fundamentally competitive with them. At the very least, this is the declared aim of the OPC Foundation's activities mentioned at the beginning and ultimately also the aim of the development activities within the relevant OSADL projects.

Phase 2 of the OSADL project

Following the successful completion of the first phase of an OSADL project, which included the implementation of PubSub for the above-mentioned open62541 project, the 'Letter of Intent' for phase 2 of the project is now available. In this phase, it is planned to carry out the following development work, among others:

1. Configuration of TSN endpoints
2. Preparations for a generic interface to TSN
3. Improvement of the real-time properties
4. Support for the certification of individual devices
5. Extension to include a security layer

1. the configuration of TSN endpoints

Part 14 of the OPC UA specification prescribes how the configuration of OPC UA PubSub is to be represented in the information model of the associated OPC UA server. Interaction with the information model makes it possible to change the PubSub configuration at runtime. The OPC UA TSN working group in the OPC Foundation is working on an analog representation of the TSN configuration in OPC UA. Parallel to the ongoing standardization, the TSN configuration is to be implemented via OPC UA for selected hardware examples. By participating in the relevant working group, the experience gained will in turn benefit standardization.

2 The generic interface to TSN

Table 2: TSN standards implemented in the hardware of the Intel I210 network adapter and in the corresponding driver of the Linux kernel 4.19.x.

© OSADL

The tests carried out as part of phase 1 of the OPC UA project and during evaluations in the OSADL QA farm were mainly carried out with the Intel network adapter I210 and are based on the driver provided by the manufacturer for the Linux kernel(see Table 2). To simplify the connection of future TSN-capable network adapters or system-on-chip solutions developed by other manufacturers, it is desirable that a suitable framework is available. This framework should also serve to create a standardized configuration interface. Providing such a framework is the aim of the AccessTSN project, the results of which will be integrated directly into the OSADL project as soon as they are available.
project as soon as they are available.

3. improvement of the real-time properties

In contrast to classic fieldbuses, OPC UA PubSub does not initially specify the actual payload. The user can configure these in so-called data sets. As described in the standard, the implementation of OPC UA PubSub for open62541 enables the configuration of the data sets to be adapted at runtime. Furthermore, the source of the values for PubSub messages is an OPC UA information model. Depending on its implementation, the values are only accessible via the OPC UA 'Read' service. This is generally associated with more overhead than resolving a known memory address.

In the first phase of the project, a number of technical tricks were used to combine the flexibility described in the standard with real-time requirements. However, a series of accesses to the OPC UA information model and checks of initially unknown message lengths remain unavoidable. Further streamlining of the publisher code is desirable for use in resource-limited end devices. For a separate PubSub 'fast path', the configuration of the data sets should already be defined at compile time in phase 2 and the network payload should be generated with as few processor cycles as possible via the generation of adapted source code.

4. support with certification

Many customers insist on certified products to ensure interoperability. As part of phase 2 of the project, participating companies will receive support for the certification of their OPC UA PubSub solutions. However, the certification itself can only be carried out by the OPC Foundation's test laboratories and will be based on the recommendations of the newly established OPC Foundation Steering Committee.

5. addition of a security layer

Encryption of communication is required for productive use in the field. For this purpose, a key server must be provided that enables all participating communication partners to verify the integrity and origin of the data.

Synchronization between OSADL and OPC Foundation?

The OPC Foundation and OSADL largely agree on the fundamental goal of promoting the OPC UA PubSub and TSN ecosystem and creating the best possible conditions for its dissemination. With this in mind, OSADL endeavors to directly adopt and implement the standards and other specifications developed by the OPC Foundation. This is made possible in particular by the fact that the project partner Kalycito Infotech is also a member of the steering committee of the OPC Foundation's 'Field-Level Communication Initiative', which was founded in November 2018 and coordinates the standardization activities for OPC UA PubSub and TSN. As a desirable goal, OSADL is striving to have the implementation of the open62541 project certified by the OPC Foundation after its expansion through the described phase 2 of the OSADL project.

Author:
Carsten Emde has been the managing director of the Open Source Automation Development Lab (OSADL) since it was founded in 2005.

How is freely licensed software financed?

In contrast to proprietary software, which is developed as an investment by a single company or a small group of companies and amortized with licensing income, a larger group of interested parties is usually required to finance freely licensed software.

Examples include the Linux Foundation, the Eclipse Foundation and the Mozilla Foundation in the USA, as well as the Open Source Automation Development Lab (OSADL) based in Germany.

OSADL projects

The OSADL is a registered cooperative and aims not only to develop free software for industry, but also to provide all the services required for its use in industrial products. The more than 100 shares or equivalent shares subscribed at the end of 2018 are linked to an annual lump sum payment, which is used to finance most of the services. These include, among other things

• Software development,
• quality assurance, operation of a test center,
• provision of legal advice,
• organization of conferences, seminars, workshops and networking
• and project management.

If the available financial scope is not sufficient for a particular project, interested members can form a sub-group and provide additional project resources in the form of personnel or funding. The legal framework for such funding by a sub-group usually takes the form of a letter of intent, which contains a description of the services to be provided, a funding threshold and a target date. If the funding threshold is reached by the agreed target date, the letter of intent automatically becomes valid and the project begins without the need for a separate consortium agreement. Examples of the successful implementation of this financing concept include the further development of the real-time properties of the Linux kernel, processes and documents for its safety certification, license obligation checklists for open source licenses and also an initial phase of the further development of OPC UA as part of the open62541 project. In this first phase, the PubSub extensions were implemented in accordance with Part 14 of the OPC Foundation specifications. This also includes the first elements for a real-time capability of the publisher and the implementation of a subscriber as a standalone application. Software development and system integration were carried out by Fraunhofer IOSB and Kalycito Infotech Private Ltd, while OSADL was responsible for project management.

The mixed-financed project was supported by the companies Heidelberger Druckmaschinen, Kontron, Linutronix, Pilz, Sick and TQ-Systems.