This article is only available in German.
Der Demonstrator der Hochschule Kempten hat schon ein Vorleben: Er diente als vielfach verwendetes Messe-Exponat und wurde der Hochschule Kempten in einem nicht betriebsfähigen Zustand zur Verfügung gestellt. Ursprünglich diente er innerhalb eines Forschungsprojektes dazu, die Vernetzung von dezentralen Steuerungsarchitekturen zu veranschaulichen. Im Rahmen einer Abschlussarbeit erfolgte die Wiederinbetriebnahme der Anlage. Genutzt wurde hierzu eine neue Steuerungsarchitektur mit drei dezentralen Kleinsteuerungen auf Raspberry-Pi-Basis und einer übergeordneten Soft-SPS (Industrie-PC) zur Anlagensteuerung inklusive Visualisierung. Die Kommunikation zwischen den Steuerungen erfolgte in einem ersten Schritt über TCP/IP. In einem nächsten Schritt erfolgte jetzt die Implementierung OPC UA PubSub.
Wozu PubSub?
In vernetzten Anlagen mit einer verteilten Steuerungsarchitektur, deren Kommunikation nicht komplett echtzeitfähig sein muss, besteht immer die Anforderung, Daten zwischen den Teilnehmern einfach und effizient austauschen zu können. Bisher gängige Übertragungsverfahren wie beispielsweise TCP/IP erfordern es, alle Teilnehmer im Netzwerk, die miteinander kommunizieren sollen, einzeln in einem selbstdefinierten (proprietären) Übertragungsprotokoll zu vernetzen und zu implementieren. An diesem Punkt setzt OPC UA PubSub an: In einem standardisierten Protokoll, das in Sender (Publisher) und Empfänger (Subscriber) untergliedert ist, können die Daten plattformübergreifend übertragen werden, ohne Details der Kommunikation zu kennen oder selbst umzusetzen. Der grundsätzliche Aufbau von PubSub ähnelt dem des bekannten Internetprotokolls MQTT: Ein Publisher bietet unter einem bestimmten Thema (Topic) Daten an, für die generell nicht relevant ist, ob sie tatsächlich genutzt oder empfangen werden. Hat eine Steuerung Interesse an dem Topic eines Publishers, kann sie sich als ein Subscriber – von beliebig vielen möglichen Subscribern – das entsprechende Thema abonnieren. Als Folge werden alle Daten, die im Netzwerk unter dem ‚Abonnement‘ gesendet werden, automatisch empfangen und können genutzt werden.
Für die unteren Netzwerk-Schichten (OSI-Modell) der Übertragung mit PubSub wird das User Data Protokoll (UDP) genutzt. Das heißt, der Datentransport findet verbindungslos und damit zum Beispiel ohne Rückmeldungen des Empfängers statt. Das führt dazu, dass PubSub seine Übertragungen schneller als bestätigte, verbundene Protokolle – als etwa TCP-IP – übermitteln kann. Gleichzeitig sind keine Empfangsbestätigungen vorgesehen, sodass ein Sender sich über den Empfang seiner Nachrichten nicht im Klaren sein kann. Natürlich wäre es bei Bedarf denkbar, ein Bestätigungssystem auch über PubSub umzusetzen. Zur besseren Absicherung des Datentransports verwendet die Umsetzung von PubSub in CODESYS zusätzliche Sicherheitsfunktionen des Message Mapping Protokolls (UADP, beispielsweise Verschlüsselung oder die Signierung von Daten).
Wie ist PubSub in CODESYS anzuwenden?
CODESYS bietet zur Umsetzung von PubSub eine objektorientiert aufgebaute IEC-Bibliothek an, die sich als Standard-IEC-Code in beliebige IEC-Programme auf nahezu beliebigen CODESYS-basierten Steuerungen einbinden lässt. Dazu ist die PubSub-Bibliothek zunächst aus dem CODESYS-Store herunterzuladen und anschließend ‚ganz normal‘ innerhalb des Bibliotheksmanagers einzubinden. Zu Testzwecken kann die Bibliothek – ohne inhaltliche Einschränkungen – im Demo-Modus für 30 Minuten genutzt werden, bevor das zugehörige Programm neu gestartet werden muss. Für eine dauerhafte Nutzung von PubSub ist eine Lizenzierung notwendig, die für jede Steuerung, die PubSub nutzen soll, zu erwerben ist und über den Lizenzmanager auf dem jeweiligen Gerät installiert wird. Die Kosten einer Lizenz belaufen sich auf 50 Euro (Stand 02.12.2020). Die PubSub-Bibliothek von CODESYS enthält alle notwendigen Bausteine, um Publisher oder Subscriber zu erstellen. Der Aufbau für beide Varianten ist sehr ähnlich gehalten: Der Code zur Datenübertragung besteht aus fünf Funktionsbausteinen, die miteinander zu verschalten sind. Der Baustein UADP.Connection übernimmt den Verbindungsaufbau und erfordert deshalb die aufwendigste Parametrierung. Im Baustein UADP.WriterGroup werden mehrere DataSet Messages zu einer Netzwerk-Nachricht zusammengefasst. Diese wird im UADP.Writer mit zusätzlichen Parametern, wie beispielsweise einem Zeitstempel, versehen.
Für den Subscriber werden nur die Writer-Group- und der Writer-Baustein durch einen ReaderGroup- und einen Reader-Baustein ersetzt und die Parametrierung des Connection-Bausteins angepasst. Die Zuordnung der Daten zu einem Topic wird statt über klare Themennamen über frei wählbare IDs im Unsigned-integer-Format ausgeführt. Um die Daten an die gewünschten Steuerungen zu übertragen, werden die IP-Adressen und die Ports aller beteiligter Geräte eingetragen. Für den Datentransfer an mehrere Steuerungen kann eine Multicast-IP gewählt werden. Ein wesentlicher Unterschied zu bekannten Übertragungsprotokollen wie TCP/IP liegt in der Aufbereitung der Daten: Alle Variablen müssen in einem Daten-Set-Funktionsbaustein referenziert und zugeordnet werden. Letzterer wird dazu von einem in der Bibliothek angebotenem DataSet-Funktionsbaustein nach den Konzepten der objektorientierten Programmierung, abgeleitet und ‚erbt‘ dadurch eine bestimmte, notwendige Grundstruktur.
Diese sieht vor, dass die Referenzen auf die zu übertragenden Variablen in einem Array des Bausteins hinterlegt werden. Zur zugehörigen Registrierung der Variablen steht die Methode PrepareValues zur Verfügung. Um sicherzustellen, dass zusammengehörige Publisher und Subscriber den gleichen DataSet-Baustein nutzen, wird in der Methode Init ein Versionscode generiert, der für alle an der Kommunikation beteiligten Geräte identisch sein muss. Er sollte bei einer Änderung der DataSet-Baustein- Inhalte aktualisiert beziehungsweise neu generiert werden. Unterscheiden sich die Versionscodes eines Publisher und eines Subscribers, kann zwischen ihnen keine Datenübertragung stattfinden.
Die PubSub-Umsetzung
Für den Einstieg in die Datenübertragungssysteme bietet CODESYS mit OPC UA PubSub ein System, das sich mit etwas Einarbeitungszeit auch für Einsteiger eignet. Allerdings sind Vorkenntnisse in objektorientierter Programmierung notwendig. Sind diese nicht vorhanden, schlägt sich das in der Projektierungszeit des Erstprojekts nieder. So ist es für fortgeschrittene Programmierer mit Erfahrungen in der objektorientierten Programmierung durchaus möglich, innerhalb weniger Stunden die Anforderungen zu verstehen und in einem Grundprojekt umzusetzen. Für Anfänger kann dies hingegen durchaus mehrere Tage in Anspruch nehmen. Hilfreich ist in jedem Falle das in der Bibliothek mitgelieferte Beispielprojekt, das einen grundsätzlichen Aufbau für Publisher und Subscriber beinhaltet. Die professionelle, durchwegs objektorientierte Umsetzung dieses Beispielprojekts kann für Neueinsteiger auf diesem Gebiet fordernd und zum Teil aufwendig sein. Etwas gewöhnungsbedürftig ist die Namensgebung der internen Variablen der Funktionsbausteine der Bibliothek. So ist etwa im Baustein Connection nicht immer auf den ersten Blick erkennbar, welche IPAdresse welcher Variablen zugeordnet werden muss. Hilfreich erweisen sich in diesem Falle die zugeordneten Kommentare. Empfehlenswert ist, die Kommunikation separat zu erstellen und zu testen, da die Bibliothek den Namensraum NBS verwendet, der auch bei der Datenübertragung mittels TCP/IP in CODESYS zum Einsatz kommt. Damit kann es bei gleichzeitiger Verwendung von PubSub und TCP/IP zu Überlagerungen und damit zu Fehlern kommen.
Ist beim eigentlichen Test eines PubSub-Projektes etwa der Kommunikationsaufbau fehlerhaft, ist dies einfach an den genutzten PubSub-Bausteinen zu erkennen. Diese besitzen drei Ausgangs-Variablen, die den Status, die Aktivität sowie einen Fehlerzustand anzeigen. Hier sei angemerkt, dass ein Fehlerzustand im Subscriber nicht grundsätzlich im Subscriber-Programm seinen Ursprung haben muss. So kann ein weiterer falsch parametrierter Publisher, der selbst eine korrekte Aktivität meldet, in einem Subscriber zu Verbindungsproblemen führen. Das separate Testen jeder Übertragung kann aber eine Falschinterpretation eines Kommunikationsproblems vermeiden.
Ein Resümee
Die Möglichkeit zur einfachen, schnellen Übertragung von Daten zwischen einem Publisher und beliebig vielen Subscribern macht OPC UA PubSub zu einem mächtigen Werkzeug. Insbesondere wenn es gilt, Projekte zu realisieren, die den Anspruch haben, das Internet of Things in der Industrie umzusetzen. Die erstmalige Verwendung der Objektorientierung bringt sicherlich Schwierigkeiten bei der Umsetzung eines CODESYS- PubSub-Projektes mit sich. Der etwas höhere und objektorientierte Programmieraufwand im ersten Projekt lässt sich in Folgeprojekten dank der guten Wiederverwendbarkeit des Codes kompensieren. Abschließend bleibt anzumerken: Momentan ist die Umsetzung von PubSub in CODESYS alternativlos und: sie funktioniert!
Dieser Artikel von Meinrad Happacher erschien in der Computer&Automation-Ausgabe 1/2021 (S.36-38).