Tabelle 1: Meilensteine in der Geschichte von OPC UA

© OSADL

Es ist bemerkenswert, dass sich jetzt eine Reihe von Automatisierungstechnik-Anbietern – die zusammen wohl mehr als 95 % des Marktes abdecken – anlässlich der SPS IPC Drives 2018 für ein einheitliches echtzeitfähiges Kommunikationssystem aussprechen. Bemerkenswert ist auch, dass sich die Firmen mit OPC UA PubSub über TSN für keinen der bisher verwendeten über 50 verschiedenen Feldbusse beziehungsweise kein Echtzeit-Kommunikationsverfahren entschieden haben. Sondern es wird ein bisher nur für einen Teilbereich verwendetes Informationsmodell mit einem ebenfalls vorbestehenden, aber noch nicht für diesen Zweck eingesetztes Synchronisierungsprotokoll kombiniert, gemeinsam weiterentwickelt und standardisiert.

Möglicherweise hat den Einigungsprozess vereinfacht, dass nun kein Anbieter den Vorteil hat, sein eigenes Verfahren weiterverwenden zu können, sondern alle beteiligten Unternehmen sich mit ähnlichem Entwicklungsaufwand in das neue Verfahren einarbeiten müssen. Die Wahl von schon lange in einem anderen Kontext verwendeter Verfahren (siehe Tabelle 1) könnte auch den Vorteil haben, dass es entweder keine relevanten Patente dafür gibt oder diese, wenn es welche geben sollte, nur noch eine kurze Restlaufzeit haben.

OPC UA – die Lizenzfrage

Im Vergleich zu vielen anderen Verfahren verfügt OPC UA über ein sehr mächtiges Informationsmodell, das es gestattet, Daten zwischen verschiedenartigen Teilnehmern auszutauschen, ohne vorher – wie sonst üblich – auf Bit-Ebene starre Protokoll-Telegramme festzulegen. Allerdings war die allgemeine und uneingeschränkte Nutzung in Forschung und Industrie dadurch beeinträchtigt, dass es keine Referenzimplementierung gab, die unter einer freien Lizenz industriell genutzt und mit proprietärer Software kombiniert werden konnte. Denn die Referenzimplementierung der OPC Foundation in ANSI C ist dual lizenziert – ­entweder für Mitglieder der OPC Foun­dation unter einer proprietären Lizenz oder für Nicht-Mitglieder unter der GPL-2.0. Letztere erlaubt aber nicht das Linken mit einer proprietär Applikation, wie es für den Einsatz in der Industrie unverzichtbar ist. Diese Lizenzierung war umso verwunderlicher, als seit der Bereitstellung von TCP/IP unter der permissiven BSD-Lizenz der Berkeley Software Distribution und dem weltweiten Siegeszug dieses Internet-Protokolls allgemein klar war, dass ein Protokoll mit vergleichbarem Anspruch unter einer freien und uneingeschränkt verwendbaren Lizenz stehen muss.

Weiterhin implementiert die Referenz-Implementierung der OPC Foundation nur den sogenannten Protokoll-Stack und stellt kein vollständiges SDK für Client- und Serveranwendungen zur Verfügung. Daher wurde ab Ende 2013 das Kooperationsprojekt ‚open62541‘ vom Lehrstuhl für Prozessleittechnik der RWTH Aachen, dem Fraunhofer IOSB in Karlsruhe und der Professur für Prozessleittechnik der TU Dresden ins Leben gerufen. Mittlerweile sind auch das Forschungsinstitut Fortiss sowie eine Reihe von Unternehmen aus dem Umfeld industrieller Automatisierung an der Entwicklung beteiligt.

Als Lizenz wurde für das open62541-Projekt die mit einem schwachen Copyleft behaftete Mozilla Public License in der Version 2.0 (MPL-2.0) verwendet, die es gestattet, eine so lizenzierte Software mit einer proprietär lizenzierten Applikation zu verlinken und zu vertreiben. Eine wichtige Lizenzpflicht der MPL-2.0 besteht unter anderem darin, dass jedem Empfänger einer solchen verlinkten Applikation mitgeteilt werden muss, wo der verwendete frei lizenzierte Quellcode der Bibliothek schnell und einfach verfügbar ist. Diese Lizenzpflicht ist zwar aufwendiger als die der sehr großzügigen BSD-Lizenz von TCP/IP, steht aber einer uneingeschränkten Verbreitung nicht nur nicht im Wege, sondern befördert im Gegenteil die gemeinschaftliche Weiterentwicklung der Software.

Die Integration von TSN in OPC UA PubSub

In der letzten Zeit ist wiederholt die Formulierung aufgetaucht, man müsse nur „von UDP auf TSN umschalten“, wenn man OPC UA PubSub Echtzeit-Eigenschaften verleihen will. Diese Formulierung ist leider allzu missverständlich und darüber hinaus technisch inkorrekt. Denn UDP ist ein Layer-3-Protokoll, während TSN einen Oberbegriff für eine ganze Reihe von überwiegend in der Hard- beziehungsweise Firmware des Netzwerk-Adapters implementierten Layer-2-Verfahren darstellt. Wesentliche zur Zeit standardisierte und zum Beispiel im Intel-Netzwerk-Adapter I210 und im entsprechenden Linuxtreiber ab Patchlevel 4.19 bereits implementierte Verfahren betreffen die hochgenaue Synchronisation der Rechner, Bandbreitenreservation und den auf Zeitstempel basierenden Versand von Netzwerk-Paketen.

Man kann also nicht einfach ‚umschalten‘, sondern muss geeignete Hardware für alle beteiligten Rechner erwerben, Rechnersynchronisation konfigurieren, Treiber- und Konfigurations-Software aktualisieren und die zur Zeit noch extrem komplizierten Kommandozeilen erstellen und verwenden. 

Ist geplant, Switche einzusetzen, müssen entsprechend geeignete Layer-2- beziehungsweise TSN-fähige Switche erworben werden, die im Vergleich zu herkömmlichen Geräten etwa zehn- bis zwanzigmal teurer sind. Um diesen Aufwand sowie die Leistungsfähigkeit – speziell im Hinblick auf die erreichbaren Echtzeit-Eigenschaften – ermitteln zu können, betreibt OSADL in seiner QA-Farm mehrere TSN-Test­strecken.

Erste TSN-Test-Ergebnisse

Die Teststrecken dienten auch dazu, OPC-UA-Datenpakete mit Zeitstempel zu versehen und deren Echtzeit-Verhalten zu prüfen. Die Ergebnisse bestätigen die Erwartung, dass OPC UA PubSub über TSN das Potenzial hat, vergleichbare technische Daten wie die zur Zeit etablierten Echtzeit-Ethernet-Protokolle zu erreichen und zu diesen grundsätzlich konkurrenzfähig zu sein. Zumindest ist dies das erklärte Ziel der eingangs genannten Aktivität der OPC Foundation und letztlich auch das Ziel der Entwicklungstätigkeit im Rahmen der betreffenden OSADL-Projekte.

Phase 2 des OSADL-Projekts

Nach erfolgreichem Abschluss einer ersten Phase eines OSADL-Projekts, in der unter anderem PubSub für das oben genannte open62541-Projekt implementiert wurde, ist nun der ‚Letter of Intent‘ für eine Phase 2 des Projekts verfügbar. In dieser Phase ist geplant, unter anderem die folgenden Entwicklungsarbeiten zu leisten:

1. Konfiguration von TSN-Endpunkten
2. Vorbereitungen für ein generisches Interface zu TSN
3. Verbesserung der Echtzeit-Eigenschaften
4. Unterstützung bei der Zertifizierung einzelner Geräte
5. Erweiterung um einen Security-Layer

1. Die Konfiguration von TSN-Endpunkten

Part 14 der OPC-UA-Spezifikation schreibt vor, wie die Konfiguration von OPC UA PubSub im Informationsmodell des zugehörigen OPC-UA-Servers zu repräsentieren ist. Über die Interaktion mit dem Informationsmodell gibt es die Möglichkeit, zur Laufzeit die PubSub-Konfiguration zur verändern. Die Arbeitsgruppe für OPC UA TSN in der OPC Foundation arbeitet an einer analogen Repräsentation der TSN-Konfiguration in OPC UA. Parallel zur fortschreitenden Standardisierung soll für beispielhaft ausgewählte Hardware die Konfiguration TSN über OPC UA umgesetzt werden. Durch die Teilnahme in der relevanten Arbeitsgruppe kommen die Erfahrungen wiederum der Standardisierung zugute.

2. Das generisches Interface zu TSN

Tabelle 2: In der Hardware des Intel-I210-Netzwerk-Adapters und im entsprechenden Treiber des Linux-Kernels 4.19.x implementierte TSN-Standards.

© OSADL

Die im Rahmen der Phase 1 des OPC-UA-Projekts sowie bei Evaluierungen in der OSADL-QA-Farm vorgenommenen Tests wurden überwiegend mit dem Intel-Netzwerk-Adapter I210 vorgenommen und basieren auf dem vom Hersteller für den Linux-Kernel bereitgestellten Treiber (siehe Tabelle 2). Für die einfachere Anbindung zukünftiger von anderen Herstellern entwickelter TSN-fähiger Netzwerk-Adapter beziehungsweise System-on-Chip-Lösungen ist es wünschenswert, dass ein geeignetes Framework zur Verfügung steht. Dieses Framework soll darüber hinaus dazu dienen, eine einheitliche Konfigurations-Schnittstelle zu schaffen. Ein solches Framework bereitzustellen, ist  das Ziel des AccessTSN-Projektes, dessen Ergebnisse, sobald sie vorliegen, unmittelbar in das OSADL-Projekt integriert 
werden sollen.

3. Verbesserung der Echtzeit-Eigenschaften

Im Vergleich zu den klassischen Feldbussen macht OPC UA PubSub initial keine Vorgaben zur eigentlichen Payload. Der Nutzer kann diese in sogenannten Data-Sets konfigurieren. Wie im Standard beschrieben, ermöglicht die Implementierung von OPC UA PubSub für open62541 die Anpassung der Konfiguration der Data-Sets auch zur Laufzeit. Weiterhin ist die Quelle der Werte für PubSub-Nachrichten ein OPC-UA-Informationsmodell. Abhängig von dessen Implementierung sind die Werte nur über den OPC-UA-‚Read‘-Service zugänglich. Dieser ist im allgemeinen mit mehr Overhead verbunden als das Auflösen einer bekannten Speicheradresse.

In der ersten Phase des Projekts wurden noch eine Reihe technischer Kniffe eingesetzt, um die im Standard beschriebene Flexibilität mit Echtzeit-Anforderungen zu verbinden. Eine Reihe von Zugriffen in das OPC-UA-Informationsmodell und Überprüfungen von initial noch unbekannten Nachrichtenlängen bleiben aber unumgänglich. Für den Einsatz in ressourcenbegrenzten Endgeräten ist eine weitere Verschlankung des Publisher-Codes wünschenswert. Für einen separaten PubSub-‚Fast-Path‘ soll in Phase 2 die Konfiguration der Data-Sets bereits zur Compile-Zeit festgelegt werden und über die Generierung von angepasstem Quellcode die Netzwerk-Payload mit möglichst wenig Prozessorzyklen erzeugt werden.

4. Unterstützung bei der Zertifizierung 

Viele Kunden bestehen auf zertifizierte Produkte, um Interoperabilität sicherstellen zu können. Im Rahmen der Phase 2 des Projekts erhalten die teilnehmenden Unternehmen Unterstützung für die Zertifizierung ihrer OPC-UA-PubSub-Lösungen. Die Zertifizierung selbst kann jedoch nur durch die Testlabore der OPC Foundation erfolgen und wird auf den Empfehlungen des neu gegründeten Steering-Committees der OPC Foundation basieren.

5. Erweiterung um einen Security-Layer

Für den produktiven Einsatz im Feld ist die Verschlüsselung der Kommunikation erforderlich. Für diesen Zweck muss ein Keyserver bereitgestellt werden, der es allen teilnehmenden Kommunikationspartnern ermöglicht, Unversehrtheit und Herkunft der Daten zu verifizieren.

Synchronisation zwischen OSADL und OPC Foundation?

Die OPC Foundation und OSADL stimmen sehr weitgehend im grundsätzlichen Ziel überein, das Ökosystem von OPC UA PubSub und TSN zu fördern und bestmögliche Bedingungen für dessen Verbreitung zu schaffen. In diesem Sinne ist OSADL bestrebt, die von der OPC Foundation entwickelten Standards und sonstige Vorgaben unmittelbar aufzunehmen und umzusetzen. Dies wird insbesondere dadurch ermöglicht, dass der Projektpartner Kalycito Infotech gleichzeitig auch Mitglied des Leitungsgremiums der im November 2018 gegründeten ‚Field-Level-Communication-Initiative‘ der OPC Foundation ist, welche die Standardisierungs-Aktivitäten für OPC UA PubSub und TSN koordiniert. Als wünschenswerte Zielvorstellung ist OSADL bestrebt, die Implementierung des open62541-Projektes nach dessen Erweiterung durch die beschriebene Phase 2 des OSADL-Projekts von der OPC Foundation zertifizieren zu lassen.

Autor:
Carsten Emde ist seit der Gründung des ‚Open Source Automation Development Lab‘ (OSADL) im Jahre 2005 dessen Geschäftsführer.

Wie finanziert sich frei lizenzierte Software?

Im Gegensatz zu proprietärer Software, deren Entwicklung als Investition von einem einzigen Unternehmen oder einer kleinen Gruppe von ­Unternehmen vorgenommen und mit Lizenzeinnahmen amortisiert wird, ist für die Finanzierung einer frei lizenzierten Software in der Regel eine größere Gruppe von interessierten Parteien erforderlich. 

Als Beispiele sind die Linux Foundation, die Eclipse Foundation und die Mozilla Foundation in den USA sowie das in Deutschland ansässige Open Source Automation Development Lab (OSADL) zu nennen. 

OSADL-Projekte

Das OSADL ist eine eingetragene Genossenschaft und hat das Ziel, freie Software für die Industrie nicht nur zu entwickeln, sondern auch sämtliche Dienstleistungen bereitzustellen, die für deren Einsatz in Industrieprodukten benötigt werden. Mit den Ende 2018 insgesamt über 100 gezeichneten Geschäftsanteilen beziehungsweise äquivalenten Anteilen ist eine jährlich zu entrichtende Pauschalzahlung verbunden, mit deren Hilfe die meisten Dienstleistungen finanziert werden. Dabei handelt es sich unter anderem um

• Software-Entwicklung,
• Qualitätssicherung, Betrieb eines Testzentrums,
• Vermittlung von Rechtsberatung,
• Organisation von Konferenzen, Seminaren, Workshops und Networking
• sowie Projektmanagement.

Wenn für ein bestimmtes Projekt der verfügbare finanzielle Spielraum nicht ausreicht, können interessierte Mitglieder eine Untergruppe bilden und zusätzliche Projektmittel in Form von Personal oder Finanzierung bereitstellen. Der rechtliche Rahmen einer solchen Finanzierung durch eine Untergruppe erfolgt üblicherweise mit einem ‚Letter of Intent‘, der eine Beschreibung der zu erbringenden Leistungen enthält und mit einer Finanzierungsschwelle sowie einem Zieldatum versehen ist. Wenn bis zum vereinbarten Zieldatum die Finanzierungsschwelle erreicht ist, wird der ‚Letter of Intent‘ automatisch gültig, und das Projekt beginnt, ohne dass es eines getrennten Konsortialvertrags bedarf. Beispiele für die erfolgreiche Umsetzung dieses Finanzierungskonzepts sind die Weiterentwicklung der Echtzeit-Eigenschaften des Linux-Kernels, Prozesse und Dokumente zu dessen Safety-Zertifizierung, Lizenzpflicht-Checklisten für Open-Source-Lizenzen und eben auch eine erste Phase der Weiterentwicklung von OPC UA im Rahmen des open62541-Projektes. In dieser ersten Phase wurden die PubSub-Erweiterungen nach Teil 14 der Spezifikationen der OPC Foundation implementiert. Darin enthalten sind auch bereits erste Elemente für eine Echtzeit-Fähigkeit des Publishers sowie die Implementierung eines Subscribers als Standalone-Applikation. Software-Entwicklung und System-Integration erfolgten durch das Fraunhofer IOSB und durch Kalycito Infotech Private Ltd., das Projektmanagement lag bei OSADL. 

Unterstützt wurde das gemischt finanzierte Projekt von den Firmen Heidelberger Druckmaschinen, Kontron, Linutronix, Pilz, Sick und TQ-Systems.