Mit OPC UA Pub/Sub und TSN mit und in der Feldebene kommunizieren

Interview: Andreas Gees, stv. Chefredakteur elektro AUTOMATION

elektro AUTOMATION: Herr Lutz, Sie waren fast zwei Jahrzehnte das Gesicht von Sercos. Was ist der Grund für Ihren Einstieg bei der OPC Foundation? Was genau ist Ihre Aufgabe?

Peter Lutz (OPC Foundation): Meinen Wechsel zur OPC Foundation darf man nicht als eine Entscheidung gegen Sercos werten. Ich habe vielmehr die Chance genutzt, an einem sehr spannenden und zukunftsweisenden Projekt der OPC Foundation mitzuarbeiten. Es hat zum Ziel, einen wesentlichen Beitrag zur Verbesserung der Durchgängigkeit und zur Vereinheitlichung der industriellen Kommunikation zu leisten. Denn die heutige Landschaft in der industriellen Automatisierung ist geprägt durch eine Vielzahl verschiedener und untereinander inkompatibler Feldbusse und Echtzeit-Ethernet-Systeme. Dies führt bei Anwendern und Herstellern zu erheblichen Mehraufwänden, da verschiedene Netzwerktechnologien in Maschinen und Anlagen implementiert und unterstützt werden müssen. Ich bin seit April als Director Field Level Communications (FLC) bei der OPC Foundation tätig. Ziel unserer Initiative mit aktuell 25 Unternehmen – darunter auch die Marktführer in der Automatisierungstechnik – ist es, den Anwendungsbereich von OPC UA auf die Feldebene auszudehnen und OPC UA in Kombination mit TSN als Technologie für die Kommunikation auf der Feldebene zu etablieren. Meine Aufgabe besteht darin, als neutrale und unabhängige Person die Koordination der Arbeitsgruppen und ihrer Aktivitäten zu übernehmen. Außerdem kümmere ich mich – zusammen mit entsprechenden Gremien – um alle Themen, die zur erfolgreichen Umsetzung der FLC-Technologie erforderlich sind, wie Standardisierung und Zertifizierung. Ganz entscheidend sind natürlich die Beiträge der bei FLC engagierten Firmen, die Ressourcen und Entwickler zur Verfügung stellen, um die Technik in Form von Spezifikationen und Implementierungen voranzubringen.

elektro AUTOMATION: Können Sie uns einen kurzen Abriss über die einzelnen Entwicklungsschritte von OPC von Object Linking and Embedding bis zur Open Platform Communication von heute geben? Was zeichnet OPC UA für die Feldebene aus?

Lutz: OPC wurde vor etwa 20 Jahren entwickelt und war die Nachfolgetechnologie zum Dynamic Data Exchange DDE. Da das klassische OPC auf der Microsoft-Technologie COM/DCOM basierte und damit auf Windows-Umgebungen beschränkt war, fiel 2002 der Startschuss für die OPC Unified Architecture (OPC UA), die plattform-, sprach- und softwareunabhängig konzipiert wurde und auch in Embedded-Systemen zum Einsatz kommen sollte. 2006 erschien ein erste Spezifikationsrelease. Über die Jahre sind weitere Bausteine hinzugekommen. Das aktuell gültige Spezifikations-Release 1.04 wurde 2017 veröffentlicht. OPC UA wurde ehemals als verbindungsorientierte Client-Server-Architektur entwickelt. Allerdings wurde schnell deutlich, dass es auch anderer Kommunikationsbeziehungen bedarf, die zu unterstützen sind. Entstanden ist daraus die Pub/Sub-Erweiterung von OPC UA, die flexible, verbindunglose Kommunikationsbeziehungen unterstützt und sowohl für die Cloud-Anbindung wie auch für die Kommunikation auf Feldebene unabdingbar ist. Somit steht mit OPC UA heute eine sichere, skalierbare und sehr flexible Kommunikationsarchitektur für ganz unterschiedliche Anwendungen zur Verfügung. Dabei lassen sich Funktionen wie aus einem Baukasten zusammenstellen. Neben den Security-Mechanismen von OPC UA ist – gerade auch im Hinblick auf Industrie 4.0 und IoT – die Informationsmodellierung entscheidend. Diese ist zentral in der Basisarchitektur enthalten und versetzt den Anwender in die Lage, auch hoch komplexe Komponenten bis hin zu einer kompletten Maschine zu modellieren. In einem definierten Adressraum sind die modellierten Informationen dann über standardisierte Dienste (lesen, schreiben, benachrichtigen bei Änderung, usw.) zugänglich. Damit wurde die Basis für einen standardisierten Informationsaustausch als plattformunabhängige, service-orientierte Architektur (SOA) geschaffen.

elektro AUTOMATION: Die OPC-UA-Architektur ist eine Service-orientierte Architektur. Wo liegen die Vorteile von SOA?

Lutz: Der Begriff SOA kommt aus der IT und ist ein Architekturmuster aus dem Bereich der verteilten Systeme. Möchte man komplexe Software miteinander verknüpfen, dann ist es sinnvoll, klare Schnittstellen zur Verfügung zu stellen. Diese lassen sich dann einfach implementieren und nutzen, unabhängig von der Komplexität der durch die Schnittstelle bereitgestellten Funktionalität, quasi wie eine Black Box, deren Inhalt abgetrennt und verborgen ist. Mit sogenannten Discovery-Mechanismen wird die Möglichkeit geschaffen, von einer beliebigen Software-Komponente zu erfragen, welche Schnittstellen (Funktionen und Eigenschaften) sie bietet. So lässt sich von einem Roboter abfragen, welche Dienste er zur Verfügung stellt, beispielsweise Funktionen zum Verfahren oder Referenzieren des Roboterarms. Er stellt diese Funktionen zur Verfügung, ihre Implementierung in der Robotersteuerung bleibt jedoch komplett verborgen. SOA bietet somit eine klare Trennung von Schnittstelle und Implementierung, was Systeme mit einer entsprechenden Komplexität durch Mechanismen der Strukturierung und Modularisierung beherrschbar macht. Das unterscheidet sich deutlich zur herkömmlichen Kommunikation bei Feldgeräten, bei denen der Datenaustausch mit Bits und Bytes kodiert ist. OPC UA eignet sich daher insbesondere auch für flexible und dynamische Automatisierungsstrukturen und -konzepte, was ja für die Entwicklungen von Industrie 4.0 unerlässlich ist.

elektro AUTOMATION: Beinhaltet OPC UA auch IT-Security?

Lutz: Die IT-Security ist bei OPC UA von vornherein berücksichtigt. So gibt es beispielsweise Mechanismen zur Authentifizierung und auch zur Verschlüsselung der zu transportierenden Daten. So ist sichergestellt, dass nur Teilnehmer Daten schreiben und lesen dürfen, deren Identität bekannt ist. Die OPC UA Security ist sowohl für das traditionelle Client-Server-Konzept ebenso wie für Pub/Sub einsetzbar. Somit kann neben der One-to-One- auch die One-to-Many-Kommunikation abgesichert werden. Um OPC UA ins Feld zu bringen, muss jedoch neben der IT-Sicherheit auch die Funktionale Sicherheit (Safety) berücksichtigt werden. Dazu ist bereits eine erste Spezifikation verfügbar. Das Besondere an dem Safety-Konzept für OPC UA ist, dass man sichere Teilnehmer auch während der Laufzeit in die Kommunikation einbinden kann, was in dieser Form bei den herkömmlichen Safety-Protokollen nicht möglich ist.

elektro AUTOMATION: OPC hat sich als ein Kommunikationsstandard für die Datenübertragung beispielsweise aus der Steuerung ins ERP oder nach SAP herauskristallisiert. Ist OPC nicht zu komplex für die Feldkommunikation?

Lutz: OPC UA ist nicht für die Kommunikation auf der Feldebene entwickelt worden. Es ist deutlich komplexer als ein speziell für die Feldkommunikation oder die Antriebstechnik entwickeltes Echtzeit-Ethernet-Protokoll oder ein Feldbus. OPC UA beinhaltet aber viele Funktionen, die ein Feldbussystem nicht berücksichtigt, wie z.B. Security. Ein 1:1-Vergleich ist somit nicht möglich. Gleiches gilt im Übrigen auch für die Cloud-Kommunikation. MQTT ist sehr viel einfacher als OPC UA, bietet aber keine integrierte Security. Muss ich MQTT aber um solche Funktionen erweitern, resultiert am Ende eine ähnliche Komplexität. Komplexität bedeutet dabei allerdings nicht, dass diese nicht mehr handhabbar ist, denn natürlich lässt sich Komplexität entsprechend kapseln und über Schnittstellen einfach nutzbar machen. Und aufgrund der Skalierbarkeit von OPC UA kann die Technologie auch in kompakten Komponenten mit limitierten Ressourcen implementiert werden, also auch in Feldgeräten. Mit dem Client-Server-Konzept allein wäre OPC UA jedoch für die Feldkommunikation nicht geeignet. Deswegen kommt hier die Publish-Subscribe-Funktionalität ins Spiel. Und mit einem unterlagerten TSN wird zudem eine deterministische Datenübertragung ermöglicht. Erst dadurch wird OPC UA echtzeitfähig und tauglich für die Kommunikation in der Feldebene. Der Ansatz von FLC ist dabei, die bestehende OPC-UA-Technologie mit all ihren Eigenschaften ins Feld zu bringen, das Anwendungsspektrum dieser etablierten Technologie auf die Feldebene auszuweiten und so eine durchgängige Lösung von der Feldebene bis in die Cloud (und vice versa) zu schaffen. Es geht nicht darum, einen weiteren Feldbus zu entwickeln, sondern mit OPC UA plus Pub/Sub und TSN eine effiziente Kommunikation zu schaffen, die auch echten Determinismus beinhaltet.

elektro AUTOMATION: OPC UA over TSN wird als das Kommunikationsprotokoll für Industrie 4.0 angesehen. Die Anforderungen der Feld-Kommunikation sind jedoch andere.

Lutz: Die Echtzeitfähigkeit bzw. die Genauigkeit bei der Synchronisierung müssen wir zunächst nicht in Frage stellen, die wird durch die TSN-Substandards sichergestellt und in verteilten Systemen lassen sich die Uhren exakt synchronisieren. Interessant ist das Thema der Protokolleffizienz, also die Frage, welche Zyklus- und Latenzzeiten erreicht werden. Mit Pub/Sub ist OPC UA deutlich effizienter geworden, sodass auch performante Anwendungen, wie Motion Control, umgesetzt und Zykluszeiten von unter 1 ms realisiert werden können. Grundsätzlich aber ist die erreichbare Performance immer von mehreren Faktoren wie der eingesetzten Netzwerktopologie, der zur Verfügung stehenden Bandbreite und der Durchleitungszeiten der externen oder integrierten Switche abhängig. Entscheidend ist aber nicht nur das Thema Performance: Denn wir decken durch den gewählten Ansatz mit OPC UA auch Anforderungen wie Durchgängigkeit und Security ab. Dies beherrschen herkömmliche Feldbusse und Ethernet-Lösungen nicht bzw. sehr eingeschränkt.

elektro AUTOMATION: Vor zwei Jahren haben sich Unternehmen zusammengeschlossen, um OPC UA over TSN zur Feldbus-Alternative zu entwickeln. Die OPC Foundation hat diese Entwicklung anfangs nicht unterstützt. Wie kam es zum Sinneswandel?

Lutz: Die Frage kommt nicht überraschend. Man konnte in der Öffentlichkeit tatsächlich den Eindruck gewinnen, als hätte es einen solchen Sinneswandel gegeben. Die OPC Foundation hat aber bereits vor Gründung der FLC-Initiative begonnen, den Weg in die Feldebene zu ebnen. Zu nennen sind hier Safety over OPC UA sowie die Pub/Sub-Erweiterungen und das Mapping auf TSN. Die Erweiterung des Anwendungsspektrums von OPC UA auf die Feldebene ist im Grunde eine logische Konsequenz, zumal der Claim der OPC Foundation schon immer ‚Industrial Interoperability from Sensor to Cloud‘ gewesen ist.

elektro AUTOMATION: Mit TSN wird ganz allgemein ein Paket von Standards beschrieben, die das Ethernet echtzeitfähig machen. Wie weit ist die Standardisierung vorangekommen, welche Standards sind relevant für FLC?

Lutz: Tatsächlich ist TSN quasi ein Baukasten und im Grunde ist nicht jeder Substandard des Baukastens relevant für OPC. Es gibt einen Kern an Substandards, die unabdingbar sind, um den Determinismus sicherzustellen. Da ist zum einen 802.1AS bzw. 802.1AS-Rev (Revision) als Basisstandard, der dafür sorgt, dass alle Teilnehmer (Endgeräte und Netzwerkinfrastrukturkomponenten) in verteilten Netzwerken synchron arbeiten können. Darauf setzen dann weitere Substandards auf. So beschreibt 802.1Qbv, wie Echtzeit-Streams in fest definierten Zeitschlitzen und mit einer garantierten Bandbreite übertragen werden können. Das ist die Basis für zyklische Echtzeitkommunikation. 802.1Qbu und 802.3br sind Standards für Frame Preemption. Frame Preemption stellt sicher, dass für einen hoch priorisierten Traffic unterbrochene Streams im nächsten Switch wieder zusammengesetzt werden. Neben diesen Basisstandards gibt es weitere Substandards, die ‚nice to have‘ sind. In einer Arbeitsgruppe der OPC Foundation wird zur Zeit erarbeitet, welche Substandards tatsächlich relevant sind und dann als verpflichtend vorgeschrieben werden. Wichtig ist, dass sich die OPC Foundation ganz klar zum TSN-Profil IEC/IEEE 60802 bekennt, welches zum Ziel hat, dass verschiedene Protokolle über eine gemeinsame TSN-Netzwerkinfrastruktur übertragen werden können. In jedem Falle muss verhindert werden, dass Protokolle unterschiedliche TSN-Substandards voraussetzen, denn dann sind die Protokolle nicht mehr koexistent. Die Koexistenz ist aber ein ganz wichtiger Aspekt bei der Migration bestehender Lösungen. Wir möchten kein neues Ökosystem schaffen, sondern der Anwender soll frei entscheiden können, wie schnell er alte Anlagen oder Anlagenteile durch neue ersetzt.

elektro AUTOMATION: Neben der Entwicklung von TSN war es auch notwendig, OPC UA um einen sogenannten Publish/Subscribe-Mechanismus zu erweitern.

Lutz: Beim Client-Server-Konzept, das verbindungsorientiert arbeitet, muss ein Server in der Feldebene eine große Zahl von Verbindungen aufbauen bzw. verwalten. Das ist ein hoher Aufwand, insbesondere wenn nur kleine Datenmengen übertragen werden. Pub/Sub arbeitet hingegen verbindungslos. Ein Publisher (Datenanbieter) stellt Daten bereit, in dem er diese verbindungslos ins Netzwerk sendet. Netzteilnehmer (Subscriber), die diese Daten benötigen, können diese Daten dann empfangen. Dieses Konzept ist ideal geeignet für die Feldebene, wo effiziente und flexible Kommunikationsbeziehungen benötigt werden.

elektro AUTOMATION: Es gibt Companion Specification etwa für Spritzgießmaschinen, für Robotik und industrielle Bildverarbeitung. Es gibt CS für CC-Link oder Profinet. Welche Bedeutung haben diese Spezifikation für die Einbindung von Feldgeräten?

Lutz: Zunächst stellt OPC UA mit seinen Informationsmodellen eine leistungsfähiges Handwerkszeug zur Verfügung, das es ermöglicht, diese Anwendungen zu modellieren. OPC UA schreibt jedoch nicht selbst vor, wie eine Maschine oder eine Maschinenkomponente zu modellieren ist. Dem Nutzer selbst bleibt es überlassen, wie beispielsweise ein RFID-Reader oder ein Vision-System zu modellieren ist. Die Arbeitsgruppen im VDMA oder im VDW nutzen diese Informationsmodellierung, um damit ihre Maschinen für definierte Use Cases zu modellieren. Die Companion Specification beschreibt dabei genau, wie die Daten zu modellieren und darzustellen sind, beispielsweise ein Temperatur- oder Achswert. Die Teilnehmer, die Daten austauschen, wissen somit ganz genau, welche Bedeutung diese Daten haben. So lässt sich eine erhebliche Vereinheitlichung erreichen, die die Basis für eine herstellerübergreifende Interoperabilität bildet. Auch bei FLC werden über sogenannte Facets die Profile für Feldgeräte (wie Motion, Safety und IO) vereinheitlicht. Alle Hersteller sind gefordert, diese Informationen einheitlich umzusetzen. Selbstverständlich kann jeder Hersteller zusätzliche Funktionen als Erweiterung der Standard-Profile entwickeln. Die Companion Spezifikationen der Feldbusorganisationen, z.B. für Profinet, CC-Link oder Sercos verfolgen einen anderen Ansatz. Dort wird eine bestehende Feldbus-Spezifikation mit Diensten und Objekten über OPC UA zugänglich gemacht. In der Companion Specification wird beispielsweise beschrieben, wie ein Profinet-Dienst auf einen OPC-UA-Dienst und wie Profinet- auf OPC-UA-Objekte abgebildet werden. Somit stehen dann alle Profinet-Objekte und -Dienste über OPC zur Verfügung.

elektro AUTOMATION: Welche Rolle spielen die sogenannten Testbeds für die Einführung von OPC UA over TSN in der Feldebene?

Lutz: Testbeds sind deshalb wichtig, weil frühzeitig ausprobiert werden kann, was zunächst nur in der Theorie oder auf dem Papier spezifiziert wurde. Viele Testbeds sind entstanden, bevor es die Bemühungen um FLC gab, beispielsweise um die Pub/Sub-Erweiterungen für OPC UA zu testen. Die Spezifikation wurde geschrieben, während parallel die Prototypentwicklung erfolgte. Je mehr Hersteller dabei zusammenarbeiten, um so zuverlässiger ist am Ende die Spezifikation. In der OPC Foundation führen wir parallel zur Entwicklung der technischen Spezifikationen auch die Diskussionen, welche Anforderungen an Test und Zertifizierung von FLC-Geräten zu erfüllen sind. Es geht darum, Prüflabore zu nutzen, die Geräte gemäß definierter Prüfvorgaben testen und zertifizieren können. Im Feldbereich ist es unabdingbar, dass Geräte intensiven Konformitätstests unterzogen werden, um eine bestmögliche Interoperabilität und hohe Verfügbarkeit von Maschinen und Anlagen sicherzustellen.

elektro AUTOMATION: Welche weiteren Entwicklungen sind erforderlich, damit OPC UA zur Alternative in der Feldebene wird? Wann wird der Wunsch vieler Anwender, einen einzigen Standard für FLC zu haben, Realität?

Lutz: Mit OPC UA und TSN können wir tatsächlich eine Vereinheitlichung und Konvergenz industrieller Kommunikationssysteme erreichen. Aber natürlich ist dies kein abrupter Übergang, sondern erfolgt schrittweise über einen längeren Zeitraum. Deswegen werden kurz- bis mittelfristig alle etablierten Protokolle nebeneinander bestehen. Die Feldbusorganisationen sind darüber hinaus dabei, eigene Spezifikationen auf der Basis von TSN zu erstellen. Mit der Verfügbarkeit von OPC-UA-TSN-Feldgeräten wird jedoch die Akzeptanz der proprietären Feldbusse und Ethernet-Protokolle zurückgehen. Eine wichtige Rolle spielt dabei TSN. Durch die Möglichkeit, verschiedene Protokolle über eine gemeinsame Netzwerkinfrastruktur zu übertragen, ist eine schrittweise Migration hin zu OPC UA over TSN möglich. Mit diesem Ansatz können Barrieren aufgrund von inkompatiblen Protokollen und Profilen Zug um Zug abgebaut werden. Wichtig dabei ist, dass das Ökosystem von allen großen Anbietern unterstützt wird, sodass die Anwender in ihrer Entscheidung frei werden, welche Systeme und Komponenten sie einsetzen.

elektro AUTOMATION: Welche weiteren technischen Entwicklungen sind erforderlich?

Lutz: Ein wichtiges Thema der Field Level Communication ist das Verbindungsmanagement. Wie wird eine Verbindung zwischen Feldgeräten konfiguriert, damit Informationen mittels Pub/Sub ausgetauscht werden können? Welche Eigenschaften muss ein Feldgerät aufweisen, damit es kommunizieren kann? Und wie wird der Quality of Service in den Geräten modelliert und auf unterlagerte Kommunikationssysteme abgebildet? Zudem wird bei FLC das sogenannte Off-line-Engineering behandelt, um Feldgeräte über entsprechende Gerätebeschreibungsdateien in Projekte einzubinden. Denn neben intelligenten Steuerungen mit eigenen Engineering-Werkzeugen gibt es natürlich auch Feldgeräte, die ihre Grundkonfiguration und Parametrierung von der Steuerung bekommen. Bei den Spezifikationsarbeiten wird hier jedoch nicht ‚bei Null‘ begonnen, sondern es wird auf entsprechende Vorarbeiten und Erfahrungen der unterstützenden Automatisierungshersteller und Feldbusorganisationen zurückgegriffen. Bei FLC werden außerdem die Profile (sogenannte Facets) spezifiziert, welche die Semantik für verschiedenartige Geräte beschreiben (z.B. dezentrale E/As, Servoantriebe, Sensoren, Safety-Komponenten). Die Roadmap bei FLC sieht vor, dass in einem ersten Schritt (das sogenannte Minimum Viable System) zunächst die wichtigsten Funktionen realisiert werden, welche es ermöglichen, dass erste Produkte vollumfänglich nutzbar und wir gleichzeitig hinsichtlich zukünftiger Spezifikationsupdates rückwärtskompatibel sind. Das Ökosystem, an dem wir arbeiten, soll aber nicht nur auf kabelgebundenes oder funkbasiertes Ethernet beschränkt sein. Die Modellierung des Quality of Service und das Netzwerk-Mapping für zyklische sowie azyklische Übertragungen ermöglichen es uns, die Dienste flexibel auf unterlagerte Kommunikationsprotokolle und Übertragungsphysiken abzubilden, sodass der eigentliche Datenaustausch entweder drahtgebunden oder per Funk, wie beispielsweise 5G, erfolgen kann. Erste Gespräche wurden diesbezüglich bereits mit der 5G-ACIA-Initiative im ZVEI geführt.