OPC UA ist der neue Informations- und Kommunikations-Standard (IKT) für die industrielle Automation. Daran besteht seit der SPS IPC Drives 2018 kein Zweifel mehr: Über 20 der weltweit führenden Automatisierungsanbieter haben sich dort im Rahmen der Field-Level-Communication-Initiative (FLC) der OPC Foundation aktiv zu OPC UA und TSN bekannt. Nach vier Jahren intensiven Verhandelns aller namhaften globalen Automatisierungs-Anbieter, beginnt jetzt die Umsetzungsphase. OPC UA muss nun fit gemacht werden für die industrielle Automation – und zwar vom Sensor und Aktor auf der Feldebene bis hinauf zur Cloud. Technologiebrüche in der Automatisierungspyramide sollen schon bald der Vergangenheit angehören. 

Aber warum ist eigentlich eine neue IKT in der industriellen Automation dringend vonnöten? Die herkömmlichen Feldbusse haben doch über 40 Jahre lang ihre Arbeit gemacht. 

Nachteile heutiger Automation

Ein großer Nachteil ist die Vielzahl der existierenden, nicht interoperablen Feldbusse und die Technologiebrüche beim Übergang von einer Ebene der Automatisierungspyramide zur nächsten. Jeder Gerätehersteller muss die Anschaltung und das Engineering jedes seiner Produkte an mehr als zehn unterschiedliche Feldbusse entwickeln und pflegen – ein betriebs- und volkswirtschaftlicher Super-GAU.

Dabei haben alle diese Feldbusse nur rudimentäre Möglichkeiten der semantischen Modellierung. Die einfache Abbildung von Daten und Gerätefunktionen auf Bits und Bytes der unterschiedlichen Feldbusse in Geräteprofilen ist das höchste der Gefühle. Leistungsfähige, objektorientierte Möglichkeiten zur semantischen Selbstbeschreibung von komplexen Maschinen und Komponenten wie etwa Vererbung oder direkte Funktionsaufrufe sind bei den herkömmlichen Feldbussen Fehlanzeige. 

Im Laufe der Jahre sind automatisierte Maschinen, wie Werkzeug, Spritzgussmaschinen, Roboter beziehungsweise die Steuerungen für die Prozesse, welche die Roboterarme tragen, immer leistungs­fähiger geworden. Viel von deren Leis-tungsfähigkeit lässt sich allerdings gar nicht nutzen, da die Zusammenarbeit der einzelnen Netzwerk-Knoten durch das Nadelöhr Feldbus-Kommunikation eingeschränkt ist.

Ein weiterer Bremsklotz ist der Zwang zur Dezentralisierung und zum komponentenzentrierten Denken. Lösungen, wie eine modulare Zelle, umfassen immer eine Vielzahl von Automatisierungskomponenten. Diese müssen jede einzeln für sich konfiguriert und programmiert werden – meist mit unterschiedlichen Engineering-Tools unterschiedlicher Hersteller.

Vorbild PC

Das Ziel: Wie die USB beim PC – so soll OPC UA einer x-beliebigen Steuerung auf dieselbe Weise dabei helfen, angeschlossene Geräte zu identifizieren.

© Munz

Wäre es nicht sinnvoller sich stattdessen auf die gesamte Lösung zu konzentrieren und eine Automatisierungsaufgabe zentral an einer Stelle zu programmieren und zu konfigurieren, wobei die verwendeten Automatisierungskomponenten lediglich Peripheriegeräte darstellen? So wie ein Mensch Arme, Beine, Augen und Ohren hat, aber nur ein einziges zentrales Gehirn. Oder so wie Drucker, Maus, Tastatur und Festplatte an einen PC angeschlossen werden und dieser dann die gesamte Kontrolle über alle Peripheriegeräte übernimmt. Und genauso wie USB dem PC dabei hilft, die angesteckten Geräte zu identifizieren und anzusteuern, so kann OPC UA der Steuerung helfen, die anzusteuernden Komponenten zu identifizieren und die entsprechenden Zugriffsbibliotheken dem Automatisierungs-Applikationsprogrammierer durch automatische Code-Generierung zur Verfügung zu stellen.

Einen ersten Ansatz in diese Richtung stellen aktuelle Produkte von diversen Roboterherstellern dar: Roboter, die nicht mehr einzeln programmiert werden müssen, sondern deren atomare Fahrbefehle direkt von der übergeordneten SPS oder der Edge kommen. Das Motion-Subsystem verbleibt im Roboter, die SPS stößt die Fahrbefehle lediglich an und überwacht sie, genauso wie viele andere nebenläufige Prozesse, welche die gesamte Lösung zur Steuerung einer ganzen Zelle bilden. Leider ist dieses Szenario heute nur über herkömmliche Feldbusse und von jedem Roboterhersteller proprietär realisierbar.

OPC UA – mehr als ein Protokoll

Mit OPC UA plus einigen Transportzusatz-Technologien wie TSN, MQTT oder AMQP gehören alle oben aufgezählten Nachteile der Vergangenheit an. Natürlich wird es noch viele Jahre ein friedliches Nebeneinander der herkömmlichen Feldbusse und OPC UA geben. Aber immer, wenn es um wirkliche herstellerübergreifende Interoperabilität mit modernen IT-Modellierungswerkzeugen geht, führt kein Weg mehr an OPC UA vorbei.

Während OPC UA wie Feldbusse auch Protokolle zur reinen Datenübertragung enthält, ist die Informationstechnologie (IT) zur semantischen Selbstbeschreibung und Modellierung von Kommunikationsteilnehmern bei OPC UA sehr leistungsfähig – dies ist der eigentliche und wesentliche Unterschied zu den herkömmlichen Feldbussen. OPC UA ist unabhängig von der physikalischen Übertragung und kann auf beliebigem Ethernet wie GBit, WiFi, Mobilfunk oder Cloud-Protokollen benutzt werden. Es bietet Dienste wie das Browsen des Geräte-Informationsmodells, Read/Write/Subscriptions von Daten und eben auch Methoden.

Bei einheitlicher Informations- und Modellierungstechnologie bietet OPC UA zwei unterschiedliche Kommunikations-Pattern an: Client/Server und Publisher/Subscriber (Pub/Sub).

Während Client/Server eine gerichtete Punkt-zu-Punkt Verbindung darstellt, bei welcher der OPC-UA-Client Dienste und Daten vom OPC-UA-Server abrufen und verarbeiten kann, stellt Pub/Sub eine ungerichtete One-to-Many-Kommunikation dar. Der Publisher sendet ein und dieselbe Nachricht an viele Empfänger gleichzeitig in das Netz hinaus, egal ob dort kein, ein oder viele Subscriber für dieselbe Nachricht vorhanden sind. Dies kann sowohl zyklisch erfolgen – unabhängig davon, ob sich die Nachricht geändert hat oder nicht –, oder alternativ nicht zyklisch nur dann, wenn sich Daten geändert haben.

Neben diesen Unterscheidungen gibt es allerdings noch einige technische Zwänge bezüglich der Transport-Technologien. So setzt das Client/Server-Pattern nur auf TCP/IP-basierter Kommunikation oder Websockets auf, während Pub/Sub für UDP/IP, TSN (MAC-Layer 2) inklusive Multicast oder den Broker-Diensten AMQP und MQTT spezifiziert ist. Durch die zwingende Verwendung von TCP sind Client/Server und alle darauf aufbauenden Dienste wie etwa die bisherigen Methoden systembedingt nicht so ausreichend deterministisch echtzeitfähig möglich, wie es für die industrielle Automatisierung erforderlich ist. Die vorgegebene Zeitspanne liegt hierbei im Millisekundenbereich und darunter.

Der Vorteil von TCP-basierter Kommunikation ist, dass TCP selbst für eine gesicherte Kommunikation mit unterlagerter Bestätigung und Wiederholung sorgt. Eine solche Kommunikationsabsicherung ist notwendig, da bei Ethernet-basierter Kommunikation gelegentlich Telegramme verlorengehen können. Da die Kommunikationssicherung von TCP zeitlich zufällig und eben nicht bestimmbar (deterministisch) erfolgt, ist TCP generell nicht für Echtzeit-Aufgaben im (Sub-)Millisekundenbereich geeignet. Aber auch die TCP- und OPC-UA-Client/Server- Software-Stacks in den Geräten sind nicht für harte Echtzeit-Kommunikation ausgelegt und aufgrund ihrer Mächtigkeit ebenfalls nicht dafür geeignet.

Das Manko der fehlenden Echtzeit-Fähigkeit ist mit dem ungesicherten UDP/MAC-basierten Pub/Sub ausgeräumt und sowohl die UDP- als auch die Pub/Sub-Software-Stacks können schlank und somit hart echtzeitfähig gehalten werden. Da dem UDP-Protokoll allerdings jegliche Sicherungsschicht fehlt, muss die fehlerfreie Übertragung der Ethernet-Telegramme auf eine andere Art und Weise in den höheren Protokollschichten bis hinauf zur Applikationsebene erfolgen.

UDP/MAC-basiertes Pub/Sub ist also grundsätzlich echtzeitfähig einsetzbar, sofern weitere Randbedingungen wie die richtige Implementierung der Treiber, Stacks und Netzwerk-Infrastruktur wie Switches erfüllt sind. Leider fehlt dem OPC-UA-Pub/Sub-Pattern aber bisher die Möglichkeit, Methodenaufrufe durchzuführen.

Die OPC-UA-Methoden

OPC-UA-Methoden sind vergleichbar mit den in der Computerwissenschaft lange bekannten Remote Procedure Calls (RPC). Ein Dienstkonsument (Caller) möchte an einem über das Netzwerk getrennten anderen Teilnehmer (Callee) einen bestimmten Dienstaufruf – oft auch Methode, Prozedur, Funktion genannt – veranlassen. Der Caller sendet dazu den gewünschten Dienst mit entsprechenden Übergabeparametern an den Callee. Der aufgerufene Callee führt den angeforderten Dienst mit den übergebenen Parametern durch, gibt entsprechende Rückgabeparameter an den Caller zurück und meldet dadurch die Beendigung des Dienstaufrufs beziehungsweise eine Fehlermeldung, falls etwas schief gegangen ist. Dies ist vergleichbar mit einem Funktionsaufruf innerhalb eines Computer-Programms mit Hin- und Rückgabeparametern, nur eben über das Netzwerk hinweg.

Die OPC-UA-Architektur: Bei einheitlicher Informations- und Modellierungstechnologie bietet OPC UA zwei unterschiedliche Kommunikations-Pattern an: Client/Server und Publisher/Subscriber (Pub/Sub).

© OPC Foundation

Derartige netzwerkweite Funktionsaufrufe sind eine große Hilfe, um eine serviceorientierte Architektur aufzubauen (SOA). Industrie 4.0 folgt einer SOA, daher sind die OPC-UA-Methoden für die Umsetzung von Industrie 4.0 unabdingbar. Weitere Stakeholder von netzwerkweiten Methodenaufrufen sind etwa Functional-Safety-Anwendungen wegen der Möglichkeit der atomar unteilbaren Konsistenz von Aufruf- und Rückgabevariablen, PackML oder die Intelligent Assembly Solutions (IAS-Fachabteilung des VDMA, um Maschinenmodule miteinander über Methoden kommunizieren zu lassen), diverse Förderprojekte wie DEVEKOS beziehungsweise BaSys, über das Netzwerk verteilte Funktionsblöcke nach PLCopen (etwa Motion Control Function Blocks – MCFB).

Aus Caller-Sicht kann ein Methoden-aufruf in Pseudo-Code in etwa wie folgt implementiert werden:

if (READY == Method(Name, InVars, ref OutVars)) { 
Methode ist beendet und OutVars sind gültig 
} else {
   Methode ist nicht beendet, OutVars sind nicht gültig
}

Der Funktionsaufruf im Programm-Code des Callers namens Method() übernimmt die InVars-Variablenstruktur, löst die Aktion ‚Name‘ über das Netzwerk auf der Callee-Seite aus und sollte sofort mit einem Statuswert zurückkehren, um den Programmlauf des Callers nicht zu blockieren. Der Statuswert dieses nicht blockierenden, asynchronen lokalen Funktionsaufrufes zeigt an, ob die Callee-Methode beendet ist, beziehungsweise ob ein formaler Fehler beim Aufruf aufgetreten ist. Der Caller muss diese Funktion so lange aufrufen, bis der Status ‚READY‘ ist. Dann ist die Methode nämlich im Callee abgeschlossen und die OutVars sind gültig. InVars und OutVars können bei OPC-UA-Strukturen von Variablensammlungen beliebiger Datentypen wie Bool, Integer, Real, String, Variants sein. So lange der Service im Callee und in den Kommunikationsmechanismen andauert, kann dieser nicht unterbrochen werden. Man spricht deshalb auch von einem blockierenden oder synchronen Funktionsaufruf über das Netzwerk.

Aus dieser Eigenschaft des von anderen Netzwerk-Teilnehmern nicht unterbrechbaren Übergebens und Zurückgebens von Variablen an eine Methode ergibt sich die Möglichkeit von atomar unteilbaren Lese/Schreib-Operationen, wie Test and Set (TaS), wie sie für Mutual Exclusion- oder Semaphoren-Operationen benötigt werden. Mit OPC-UA-Methoden werden dadurch – bei korrekter Implementierung in den Teilnehmern – netzwerkweite Semaphoren möglich.

OPC-UA-Methoden – Getriebe für State Machines

Eine OPC UA State Machine weist immer drei Charakteristika auf: States, Methods und Transistions. Die OPC UA Programs State Machine hat 4 States, 5 Methods und 9 Transitions.

© Munz

Damit bei länger andauernden Services wie etwa Maschinenbewegungsbefehlen die einzelnen Methoden nicht für die gesamte Service-Dauer belegt sind, sollten laut OPC-UA-Philosophie für länger andauernde Callee-Services die Methoden nicht direkt verwendet werden. Stattdessen empfiehlt es sich hierfür entsprechende State Machines im Callee zu implementieren und die Methoden lediglich für die Weiterschaltung der State Machines durch Transitions zu nutzen.

Wie erwähnt, kehrt der lokale Funktionsaufruf Method() im Caller sofort wieder zum Aufrufer zurück und dieser kann am direkten Rückgabewert erkennen, ob der Callee die Methode bereits beendet hat oder nicht. Diese Art der zeilenorientierten Nebenläufigkeit mit hauptsächlich asynchronen oder nur sehr kurzen synchronen Funktionsaufrufen – im Gegensatz zu Thread-basierter Nebenläufigkeit mit längere Zeit blockierenden lokalen Funktionen – ist eine Eigenschaft des in der Automatisierungsindustrie weit verbreitenden SPS-Programmierparadigmas. Bezeichnenderweise verwendet auch die aus der modernen Web-IT stammende Webserver-seitige Javascript-Programmierung namens Node.js dieses Paradigma. Grund ist: Node.js wurde mit besonderem Fokus auf die Performance entwickelt.

Wenn viele Dinge parallel und quasi gleichzeitig zu überwachen und zu bearbeiten sind, erreicht man mit zeilenorientierter Nebenläufigkeit wesentlich bessere Performance-Werte als mit Thread-basierter Nebenläufigkeit. Da es nur einen einzigen Haupt-Thread gibt, der viele nebenläufige Aktionen steuert, entfällt auch die Notwendigkeit von Semaphoren und anderen Interprozess-Pommunikationsmechanismen (IPC), welche die Automatisierungslösung komplex und fehleranfällig machen würden.

Damit die Modellierung und Implementierung von State Machines im Callee mit ihren States, Transitions und Methoden zum Weiterschalten der States ebenfalls auf eine standardisierte Art und Weise erfolgen kann, hat die OPC Foundation im Part 5 der OPC-UA-Spezifikationen festgelegt, wie State Machines zu modellieren und aufzubauen sind. Im Part 10 schließlich wurde eine beispielhafte State Machine modelliert, ‚Programs‘ genannt.

Der Artikel entstand in Kooperation mit Codesys Consulting. 

Autor: 
Heinrich Munz ist Lead Architect Industry 4.0 bei Kuka.