Internet of Things
OPC UA - ein Muss für die Industrie (Teil 2)
OPC UA gilt als der neue Kommunikations-Standard der industriellen Automation. Teil 1 erläuterte, warum eine neue Kommunikationstechnik in der Automation nötig ist und beschrieb die OPC-UA-Methoden. Teil 2 geht auf die OPC-UA-Pub/Sub-Methoden und die Macht der Modellierung ein.
Der Slogan ‚IT meets OT‘ wird dank OPC UA Realität und bringt wertvollen Mehrwert für die seit über 30 Jahren im Dornröschenschlaf ruhende OT – was die konsequente IT-Nutzung angeht. Einen großen Anteil hierbei haben die Methoden bei OPC UA. Damit alle Vorteile von OPC-UA-Client/Server-Methoden auch in harter Echtzeit genutzt werden können, haben einige Mitglieder der PLCopen und des VDMA anlässlich des Devokos-Projektes und des VDMA-OPC-UA-Demonstrators eine Arbeitsgruppe gebildet, welche sich zur Aufgabe gemacht hat, die OPC-UA-Methoden auch auf Basis von OPC UA Pub/Sub zu realisieren. Es war von vorneherein eine wichtige Anforderung, dass die Modellierung von Pub/Sub-Methoden sich so wenig wie möglich von der von Client/Server-Methoden unterscheiden sollte, damit ein einfacher Umstieg möglich wird. Wie immer bei OPC UA sollten auch die Pub/Sub-Methoden technologieunabhängig sein und sowohl für SPS-Programmierung, Node.js aber auch für Hochsprachen wie C/C++, Java, C# zur Verfügung stehen. Schließlich war eine weitere wichtige Anforderung, die Pub/Sub-Methoden so performant und effizient wie möglich zu implementieren – es geht ja hauptsächlich um den Einsatz unter harten Echtzeit-Bedingungen.
Kompensation der fehlenden Sicherungsschicht
Als erste und wichtigste Voraussetzung musste zunächst ein Weg gefunden werden, um die fehlende Sicherungsschicht von UDP auszugleichen. Dies wurde mit einem Mechanismus gelöst, wie er bei den herkömmlichen Feldbussen seit jeher eingesetzt wird und welcher ebenso einfach wie stabil funktioniert: die zyklische Wiederholung.
OPC UA Pub/Sub für die Anwendung auf Controller/Feldebene hat wie die Feldbusse eine Art Prozessdaten-Abbilder, welche zwischen den Teilnehmern zyklisch ausgetauscht werden, beispielsweise im Takt von einer Millisekunde. Jeder Kommunikationsteilnehmer, welcher einen Methoden-Caller beziehungsweise -Callee implementieren möchte, muss Daten zyklisch sowohl senden, als auch empfangen können. Daher muss in jedem Caller oder Callee sowohl ein Publisher als auch ein Subscriber vorhanden sein. Dank dem One-to-many-Prinzip von Pub/Sub, welches auf UDP mittels Multicast realisiert ist, kann ein Telegramm eines Publisher Daten für mehrere Subscriber gleichzeitig enthalten. Dies ist bei typischen Line-Architekturen mit einem Master und mehreren Slaves sehr hilfreich. Mit entsprechender Hardware-Unterstützung und ‚Frame Aggregation‘ mit Summenrahmen-Telegramm und On-the-Fly-Bearbeitung wird auch die Rückrichtung von den Slaves zum Master in nur einem einzigen Telegramm möglich. Daran arbeitete bereits die Shaper Gruppe, die Ende 2018 in der neuen FLC-Initiative der OPC Foundation aufgegangen ist.
Das Grundprinzip der Sicherung von OPC-UA-Pub/Sub-Methoden besteht nun darin, dass die Publisher sowohl im Caller wie auch im Callee die Daten in ihren Sendepuffern mindestens so lange unverändert halten und zyklisch wiederholen, bis eine Reaktion auf diese Aktion von der Gegenseite erfolgt. Dafür wird jede Aktion mit einem durchlaufenden Sequenzzähler versehen. Die Gegenseite macht dasselbe, lässt nämlich ihre Sendedaten ebenfalls so lange anstehen bis die ursprüngliche Seite darauf reagiert hat. Dies führt zu einer Art implizitem Token-Pingpong, wobei immer nur eine der beiden Seiten das Token zum Ändern der Sendedaten besitzt, etwa um die aktuelle Methode als beendet zu melden (Callee) oder die nächste Methode zu initiieren (Caller). Geht ein Ethernet-Telegramm verloren, ist dies kein Problem. Da die Gegenseite es nicht erhalten hat, wird sie darauf nicht reagieren und sie erhält dasselbe Telegramm im nächsten Zyklus nochmals. Es ist klar, dass durch dieses Verfahren die Reaktionszeit um einen oder auch mehrere Taktzyklen verschlechtert werden kann, aber dies ist auf den meisten Ethernet-basierten Feldbussen seit vielen Jahren auch nicht anders – und die industrielle Automatisierung funktioniert trotzdem. Warum? Weil die Kommunikationszykluszeit meist wesentlich kleiner ist, als die maximal akzeptable deterministische Latenzzeit und dadurch viele Telegrammwiederholungen stattfinden, bevor die Deadline abgelaufen ist. Und weil durch zusätzliche Mechanismen wie Telegramm- und Sequenzzähler beziehungsweise Zeitstempel beide Seiten problemlos feststellen können, ob und wie viele, beziehungsweise wie lange Telegramme verloren gegangen sind und entsprechend darauf reagieren können. Das Grundprinzip von Methoden mit ihrem Variablen-Hin und -Zurück kann hervorragend auf dem beschriebenen Token-Pingpong-Verfahren ohne weitere Handshakes oder Telegrammwiederholungen innerhalb eines Zyklus implementiert werden.
Das Token-Pingpong
Eine weitere Eigenschaft dieses Token-Pingpong-Verfahrens ist es, dass auch mehrere Methoden gleichzeitig aktiv sein können. Jede gleichzeitig aktive Methode benötigt lediglich ein paar Byte Verwaltungsdaten und natürlich den Platz für die Hin- und Rückvariablen im Pub/Sub-Prozessdatenabbild. Damit die Größe des Prozessdatenabbild nicht dauernd dynamisch geändert werden muss, belegen nicht gleichzeitig aktive Methoden wie C/C++ Unions denselben Maximalausbau-Speicherplatz innerhalb des zyklischen Prozessdatenabbildes. Mehrere gleichzeitig aktive Methoden zum selben Callee erscheinen jedoch nicht notwendig, da eine Methode ja sehr kurzlebig sein soll und lediglich etwa zum Weiterschalten von State-Machine-Instanzen verwendet werden soll. Von diesen State-Machine-Instanzen kann es im Callee so viele gleichzeitig aktiv geben, wie für die Funktion des Callee notwendig ist.
Ein weiterer Vorteil von Pub/Sub-Me-thoden gegenüber Client/Server ist, dass ein Publisher und Subscriber zwangsläufig symmetrisch in jedem Teilnehmer enthalten sein muss. Dadurch kann jeder Teilnehmer ohne weiteres Methoden-Caller oder -Callee sein. Bei Client/Server geht das nicht so einfach. Dort kann nur ein Client am Server Methoden aufrufen. Für eine Symmetrie von Methoden-Caller/Callee auf beiden Seiten müsste jeder Client-Knoten auch einen Server enthalten und umgekehrt.
Ein willkommener Nebeneffekt von Pub/Sub-Methoden ist der Umstand, dass für OPC-UA-basierte Cloud-Kommunikation meist Pub/Sub auf den Transportprotokollen MQTT beziehungsweise AMQP verwendet wird. Da Pub/Sub und alle darauf basierenden Dienste auf allen für Pub/Sub vorgesehenen Transportprotokollen funktioniert, können Pub/Sub-Methoden auch für Methoden-Aufrufe von der Cloud zum Gerät oder auch umgekehrt verwendet werden – prinzipbedingt ohne den Echtzeit-Aspekt. Voraussetzung ist allerdings, dass die Pub/Sub-Kanäle in beide Richtungen implementiert sind.
Die Macht der Modellierung
Bild 1: Unabhängig von der Programmiersprache generieren die Engineering-Systeme anhand der Geräte-Informationen den Bibliotheksquellcode zur Ansteuerung der Geräte.
© KukaBei OPC UA müssen die Daten-, Methoden- oder State-Machine-Eigenschaften eines Gerätes oder einer Maschine entsprechend im Informationsmodell in Companion Specifications modelliert werden. Der VDMA hat bereits in mehr als zehn Arbeitsgruppen damit begonnen, für diverse Maschinentypen seiner Fachbereiche herstellerübergreifend entsprechende Companion Specifications zu erstellen. Die momentan laufende erste Welle fokussiert sich mehr auf Daten, welche aus den Geräten ausgelesen und an übergeordnete Systeme wie SCADA, MES, ERP und Cloud gesendet werden sollen. In einem kommenden zweiten Schritt, sollen auch Methoden zum Steuern der Maschinen und Geräte erfolgen.
Bild 2: Der ‚Method Stack‘ – rechts unten im Bild – mit seiner einfachen Methoden-State-Machine.
© KukaDie Methoden mit ihren In- und OutVars, oder die State Machines mit ihren States, Transitions und Methoden zum Auslösen der Transitions müssen ebenfalls in den Companion Specifications festgelegt werden. Aus diesem Modellierungszwang ergibt sich ein möglicher Zusatznutzen, welcher das Potenzial hat, die industrielle Automatisierung zu revolutionieren. Ähnlich wie bei USB an PCs kann das Engineering-System der Steuerungen (des Callers) die Companion Specifications der anzusteuernden Geräte (der Callees) offline als XML-Datei erhalten oder online über den OPC-UA-Server des Gerätes auslesen. Anhand der Geräte-Informationen können die Engineering-Systeme den Bibliotheksquellcode zur Ansteuerung der Geräte für die Applikationsprogrammierer unabhängig von der gewünschten Programmiersprache automatisch generieren. Den Workflow dazu zeigt Bild 1. Für die Realisierung der Methoden über OPC UA Pub/Sub muss zusätzlicher Programmcode vorhanden sein und zwar der ‚Method Stack‘ (Bild 2) mit seiner einfachen Methoden-State-Machine. Dieser wird durch das Generierungs-Tool ebenfalls entsprechend mit erzeugt und setzt auf dem regulären Pub/Sub-Stack auf.
Ein beispielhaftes Tool zur Erzeugung des Bibliothek-Quellcodes wird zu gegebener Zeit von der Arbeitsgruppe auf Github als Open-Source-Projekt bereitgestellt, sodass die unterschiedlichen Engineering-System-Hersteller den Source-Code-Erzeugungsmechanismus in ihre Engineering-Systeme standardisiert und interoperabel integrieren können.
Erster Schritt: SPS-Funktionsbausteine
Bild 4: Das Verhalten jeder einzelnen FB-Instanz im Callee ist stateful. Es wird in einer für alle FBs gemeinsamen FB-State Machine Type abgebildet.
© KukaBeispielhaft werden die OPC-UA-Pub/Sub-Methoden zunächst zur Realisierung von SPS-Funktionsbausteinen der PLCopen implementiert. Die PLCopen ‚Motion Control Function Blocks‘ (MCFB) weisen ein wohl definiertes ‚Application Programmer Interface‘ (API) sowohl zur Ansteuerung von Antrieben (Part 1/2) als auch von Kinematiken wie etwa Roboter (Part 4) für den Automatisierungsprogrammierer auf. Dieses API besteht aus einer Sammlung von Funktionsblöcken (FB), wobei jeder Block immer einen Funktionsnamen und zugehörige Eingangs-/Ausgangvariable hat (Bild 3). Alle FBs eines Parts folgen je einer übergeordneten FB-Familien-State-Machine, welche ebenfalls in der entsprechenden PLCopen-Spezifikation definiert ist. Dadurch ergibt sich folgende Hierarchie von State Machines im Callee:
- Die grundsätzliche Maschinen-/Geräte-State-Machine wie vom VDMA spezifiziert.
- In dem State zur Ansteuerung des Gerätes von 1. läuft die gesamte MCFB-Familien-State-Machine ab.
- Jeder FB weist dieselbe FB-State-Machine auf (Bild 4).
- Jede Methode hat eine kleine, implizite State Machine.
Ursprünglich wurden die MCFBs geschaffen, um lokalen, auf der SPS direkt vorhandenen Motion-Subsystemen mit der Implementierung der entsprechenden Motion-Bausteinen ein SPS-API zu geben. Ziel war: Einzelnen Achsen, koordinierten Achsbewegungen, wie Phasing, Gearing, Caming (Part 1/2), sowie Kinematiken (Part 4) von den speicherprogrammierbaren Steuerungen aus anzusteuern. Die derart von der SPS beauftragten Motion-Subsysteme haben dann ihrerseits über entsprechende Antriebsbusse wie Sercos, Ethercat oder Powerlink lediglich die Kaskadenregler in den jeweiligen Antrieben angesteuert. Mit den OPC-UA-Pub/Sub-Methoden benötigen die SPSen lokal keine Motion-Subsysteme mehr. Vielmehr verbleibt die eigentliche Motion-Aufgabe eines FB im Antrieb oder in der Kinematik und wird lediglich über einen in der SPS verbleibenden Proxy-Stub des FB über OPC-UA-Pub/Sub-Methoden sozusagen ferngesteuert. Das Verhalten jeder einzelnen FB-Instanz im Callee ist stateful und wird in einer für alle FBs gemeinsamen FB-State Machine Type abgebildet (Bild 4). Lediglich der FB-Instanzname und In-/OutVars unterscheiden die einzelnen FBs voneinander. Bild 5 zeigt die beispielhafte Modellierung eines FB in OPC UA Notation.
Ein FB läßt sich entweder flankengetriggert am Execute-Eingang (ETrigType) oder durch ein statisch anliegendes Signal am Enable-Eingang (LConType) starten. Beim ETrigType werden die InVars nur mit der steigenden Flanke des Execute-Eingangs übernommen. Eine Änderung der InVars durch den Caller während der FB aktiv ist, hat keine Auswirkung beim Callee. Beim LConType hingegen ist der FB so lange aktiv, wie das Enable-Signal auf logisch 1 anliegt, und es werden mit jeder CheckExecuting-Methode die aktuellen InVar-Werte vom Caller zum Callee übertragen. Bei beiden FB-Typen werden die aktuellen OutVar-Werte als Rückgabewerte der CheckExecuting-Methode vom Callee zum Caller zurück übertragen.
Schickt der Caller statt der CheckExecuting-Methode die Abort-Methode, bricht der Callee die laufende Instanz des FB ab und wartet im Dormant-State auf neue Methodenaufrufe. Die CheckDormant-Methode ist eine Art NoOperation und dient lediglich der Statusabfrage des Callee, ohne ihn mit neuen Aufgaben betreuen zu wollen.
Beliebige OPC-UA-Methoden für Echtzeit-Anwendungen zwischen Controllern untereinander und zur Feldebene, aber auch zur Weiterschaltung von State Machines bieten völlig neue Möglichkeiten, Automatisierungsaufgaben wesentlich direkter gleich auf Applikationsebene lösen zu können.
Die neuen Möglichkeiten
Es ist nicht mehr zeitgemäß und notwendig, Gerätefunktionen auf Bits und Bytes wie auf Feldbussen abzubilden und erst mal eigene Zugriffsbibliotheken nach Konsultierung entsprechender Bit-Tabellen aus der Dokumentation des Automatisierungsgerätes zu erstellen. Stattdessen können die Gerätedienste direkt vom Applikationsprogrammierer aufgerufen werden, nachdem anhand der entsprechenden OPC-UA-Gerätemodellierung die Zugriffsbibliotheken für die Automatisierungsgeräte für die entsprechende Engineering-Umgebung automatisch generiert worden sind. Das Automatisierungsgerät bringt sozusagen indirekt seine Treiber zur Ansteuerung selbst mit – sogar in Source Code.
Die aktuelle Arbeitsgruppe wird die entsprechenden Tools und Beispiel-Implementierungen entwickeln und auf Github zu gegebener Zeit bereitstellen. Zusätzlich sind interessierte Firmen aufgerufen, sich durch Review, Feedback und gegebenfalls aktive Mitarbeit an den aktuellen Arbeiten zu beteiligen. Parallel dazu wird versucht, die OPC-UA-Pub/Sub-Methoden zur Standardisierung in die OPC Foundation einzubringen. Schließlich machen die OPC-Pub/Sub-Methoden nur dann Sinn, wenn sie herstellerübergreifend in Steuerungen, Geräten und Maschinen funktionieren.
Der Artikel entstand in Kooperation mit Codesys-Consulting.
Autor:
Heinrich Munz ist Lead Architect Industry 4.0 bei Kuka.
Das könnte Sie auch interessieren
Die Computer&Automation 09-2025 als E-Paper
Das E-Paper berichtet über Entwicklungen in KI, Robotik und Industrie 4.0 – von Connected-Worker-Lösungen bis zu Robotersteuerungen. Ein Schwerpunkt liegt auf Datenarchitekturen, Resilienzstrategien und regulatorischen Anforderungen wie beim CRA...
mehr...Wago rüstet sich für Time Sensitive Networking (TSN)
Ethernet TSN soll im Maschinen- und Anlagenbau in Zukunft eine durchgängige Kommunikation ohne Gateways und Brüche ermöglich. Zur SPS bringt Wago zwei neue Automatisierungssysteme auf den Markt, mit denen Anwender alle Vorteile des erweiterten...
mehr...Ankommen in der Realität!
Time Sensitive Networking hat sich fest im Vokabular der Automatisierungsbranche etabliert. Alle namhaften Anbieter haben Aktivitäten zur Evaluierung oder sogar zur Einführung von TSN gestartet. Doch wo genau liegen die Ziele für den TSN-Einsatz...
mehr...Das Zusammenspiel von Ethernet TSN, OPC UA und 5G
Nur ein zuverlässiges und strukturiertes Zusammenwirken aller Einheiten sichert in einer Ameisen-Kolonie deren Erhalt. Nicht anders funktioniert im übertragenen Sinn die Datenkommunikation in einem modernen Industrie-Netzwerk.
mehr...OPC UA und DDS vereint
Bis dato wurden OPC UA und DDS oft als Konkurrenten dargestellt. Konkurrenten, die beide auf dem Ethernet-Standard TSN aufsetzen werden. – Der Schlüssel einer erfolgreichen Automation von morgen liegt aber vielmehr in einer Kombination der drei...
mehr...Wo es bei 5G noch hakt
5G in der Automation – ein derzeit heiß gehandeltes Thema. Wie schnell ist ein industrieller Einsatz von 5G tatsächlich zu erwarten? Welche Hemmnisse gilt es noch auszuräumen? Thomas Schildknecht fasst im Interview wesentliche Punkte zusammen.
mehr...Datenpipeline ASi-5
Hohe Datenbreite, kurze Zykluszeiten, verbesserte Integration intelligenter Sensoren und Aktuatoren mittels IO-Link sowie Cloud-Konnektivität per OPC UA – ASi-5 macht AS-Interface fit für die Anforderungen der Digitalisierung.
mehr...OPC UA, MQTT und Co.
Das Industrielle Internet der Dinge (IIoT) deckt ganz unterschiedliche Anwendungsbereiche ab. Genauso vielfältig wie die Anwendungsbereiche sind die zur Auswahl stehenden Konnektivitätstechnologien und Standards. Wie lässt sich die jeweils passende...
mehr...Die Frage der Lizenzen
Wird OPC UA in Kombination mit TSN 'der' Standard der Industrie-Kommunikation? Welche Rolle spielen bei dieser Frage die Lizenzen und welcher Part kommt hierbei der OSADL zu?
mehr...