Wie können Automatisierer KI-Modelle intuitiv entwickeln und in die Steuerung integrieren? Wie lässt sich überschüssige Energie im Antriebsverbund wieder...
KEM Konstruktion: Herr Lutz, Sie sind seit April Director Field Level Communications bei der OPC Foundation. Was genau ist Ihre Aufgabe?
Peter Lutz (OPC Foundation): Unser Ziel ist die Verbesserung der Durchgängigkeit und die Vereinheitlichung industrieller Kommunikationssysteme. Die heutige Landschaft in der industriellen Automatisierung ist geprägt durch eine Vielzahl inkompatibler Feldbusse und Echtzeit-Ethernet-Systeme. Ziel der 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. Ich kümmere mich – gemeinsam mit den entsprechenden Gremien – um alle Themen, die zur erfolgreichen Umsetzung der FLC-Technologie erforderlich sind, wie Standardisierung und Zertifizierung.
KEM Konstruktion: OPC UA hat 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 verborgen ist. Sogenannten Discovery-Mechanismen schaffen die Möglichkeit, von einer beliebigen Software-Komponente zu erfragen, welche Schnittstellen (Funktionen und Eigenschaften) sie bietet. So lässt sich z.B. von einem Roboter abfragen, welche Dienste er zur Verfügung stellt, wie Funktionen zum Verfahren oder Referenzieren des Roboterarms. Das unterscheidet sich deutlich von der herkömmlichen Feldgeräte-Kommunikation, bei der 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 Entwicklung von Industrie 4.0 unerlässlich ist.
KEM Konstruktion: Beinhaltet OPC auch Security?
Lutz: Die IT-Security ist bei OPC UA von vornherein berücksichtigt. Es gibt Mechanismen zur Authentifizierung und auch zur Verschlüsselung der Daten. Die OPC UA Security ist sowohl für das traditionelle Client-Server-Konzept als auch für Publish-Subscribe einsetzbar. Somit kann neben der One-to-One- auch die One-to-Many-Kommunikation abgesichert werden. Möchten wir OPC UA ins Feld bringen, müssen wir neben der IT-Sicherheit auch die Funktionale Sicherheit (Safety) berücksichtigen. 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.
KEM Konstruktion: OPC hat sich eher als ein Kommunikationsstandard für die IT 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 entwickeltes Ethernet-Protokoll oder ein Feldbus. OPC UA beinhaltet aber viele Funktionen, die ein Feldbussystem nicht berücksichtigt, wie 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. Aufgrund der Skalierbarkeit von OPC UA kann die Technologie auch in kompakte Komponenten mit limitierten Ressourcen implementiert werden. 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 Kommunition in der Feldebene.
KEM Konstruktion: 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.
KEM Konstruktion: 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 eine logische Konsequenz, zumal der Claim der OPC Foundation schon immer ‚Industrial Interoperability from Sensor to Cloud‘ gewesen ist.
KEM Konstruktion: Wie weit ist die Standardisierung von TSN vorangekommen, welche Standards sind relevant für FLC?
Lutz: Tatsächlich ist TSN quasi ein Baukasten und nicht jeder Substandard des Baukastens ist 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. 802.1Qbv beschreibt, wie Echtzeit-Streams in 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. Damit ist sichergestellt, dass für einen hoch priorisierten Traffic unterbrochene Streams im nächsten Switch wieder zusammengesetzt werden. 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, das festlegt, wie verschiedene Protokolle über eine gemeinsame TSN-Netzwerkinfrastruktur übertragen werden können. Setzen Protokolle unterschiedliche TSN-Substandards voraus, sind die Protokolle nicht mehr koexistent. Die Koexistenz ist jedoch ein ganz wichtiger Aspekt bei der Migration bestehender Lösungen. Der Anwender soll frei entscheiden, wie schnell er alte Anlagen oder Anlagenteile durch neue ersetzt.
KEM Konstruktion: Welche 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 Zeitabschnitt. Mit der Verfügbarkeit von OPC-UA-TSN-Feldgeräten wird die Akzeptanz der proprietären Feldbusse und Protokolle zurückgehen. Wichtig ist, dass das Ökosystem von allen Anbietern unterstützt wird.
KEM Konstruktion: Welche technischen Entwicklungen sind hierfür erforderlich?
Lutz: Wichtiges Thema bei FLC ist das Verbindungsmanagement. Wie wird eine Verbindung zwischen Feldgeräten konfiguriert, damit mittels Pub/Sub Daten 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. Bei FLC werden außerdem die Profile (sogenannte Facets) spezifiziert, die die Semantik der Geräte beschreiben (z.B. dezentrale E/As, Servoantriebe, Sensoren, Safety-Komponenten). Die Roadmap sieht vor, dass in einem ersten Schritt (das sogenannte Minimum Viable System) zunächst die wichtigsten Funktionen realisiert werden, um erste Produkte vollumfänglich nutzen zu können. Wir möchten die Dienste flexibel auf unterlagerte Kommunikationsprotokolle und Übertragungsphysiken abbilden, sodass der eigentliche Datenaustausch drahtgebunden oder auch über 5G erfolgen kann.
Peter Lutz, Director Field Level Communications, OPC Foundation, SüßenBild: Rüdiger J. Vogel/Konradin Mediengruppe
„Der Ansatz von FLC ist, die bestehende OPC-UA-Technologie mit all ihren Eigenschaften ins Feld zu bringen.“
Peter Lutz, Director Field Level Communications, OPC Foundation, SüßenBild: Rüdiger J. Vogel/Konradin Mediengruppe
„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.“
Peter Lutz, Director Field Level Communications, OPC Foundation, SüßenBild: Rüdiger J. Vogel/Konradin Mediengruppe
„OPC UA eignet sich insbesondere auch für flexible und dynamische Automatisierungsstrukturen und -konzepte, was ja für die Entwicklung von Industrie 4.0 unerlässlich ist.“
