Server- und -Client-Architekturen und was Anwender davon haben
PLCopen OPC UA
Die Digitalisierung der Produktion bedingt eine effiziente Verbindung von intelligenten Systemen, Sensoren und Aktoren als eines ihrer zentralen Elemente. Dieser Artikel zeigt, dass die aktuellsten Lösungen bereits den meisten Anforderungen genügen und mit Erweiterungen sogar die aufwändigsten Vorgaben mit Spezifikationen, Werkzeugen und Implementierungen erfüllen können - ein weiterer Schritt in Richtung Akzeptanz von neuen Technologien und Architekturen.
Bild: PLCopenDas Thema Kommunikation ist in der industriellen Steuerung nicht neu. Das berühmte CIM-Dreieck ist rund 30 Jahre alt und es werden heute in verschiedenen Industriezweigen nach wie vor viele historisch gewachsene Datenaustauschprotokolle genutzt. Sie bieten nur wenig Möglichkeit zum Transport von komplexen Daten und die Erweiterbarkeit ist sehr begrenzt.
Bild: PLCopen
Bild: PLCopenEinführung in die OPC UA-Technologie
OPC Unified Architecture (OPC UA) bietet die Basis für universelle, offene, hardware- und softwareunabhängige, sichere und zuverlässige Netzwerkkommunikation - also für die Überwachung von konfigurierbaren Timeouts und Verbindungsunterbrechungen sowie verschlüsselte Kommunikation. Hierfür dient eine skalierbare Client/Server-Architektur, in der der Client die Datenabfrage initiiert und der Server darauf reagiert und - möglicherweise über einen abgesicherten Kanal - diese Daten gebrauchsfertig liefert (Siehe Abbildung 1). Diese Funktionalitäten waren die Basis für PLCopen, die OPC UA-Technologie zu nutzen, um in Kooperation mit der OPC Foundation die Kommunikation in industriellen Steuerungen zu harmonisieren.
Die OPC UA-Servertechnologie in der IEC61131-3
Zu diesem Zweck wurde eine gemeinsame Arbeitsgruppe gebildet. Der erste Schritt dieser Arbeitsgruppe war die Definitionsplanung und -darstellung des OPC UA-Informationsmodells im IEC61131-3-Softwaremodell. Das OPC UA-Informationsmodell beinhaltet einen standardisierten Weg, wie Server Objekte den Clienten freigeben. Objekte bestehen in der OPC UA-Bezeichnung aus anderen Objekten, Variablen und Methoden. In diesem Fall werden Objekte dazu genutzt, die Komponenten des IEC61131-3-Softwaremodells zu repräsentieren, wie 'CtrlProgram', 'CtrlTask', 'CtrlResource' und 'CtrlFunction Blocks', und Variablen repräsentieren Werte. Das führt zu einem standardisierten Weg, wie Steuerungen mit integrierter OPC UA-Servertechnologie Datenstrukturen und Funktionsblöcke an OPC UA-Clienten, wie HMIs und ERP-Systeme, weitergeben. In Abbildung 2 sind insgesamt vier Schichten zu sehen, wovon die obersten beiden in Bezug zu OPC UA stehen. In Schicht 3 ist die Verbindung zwischen IEC61131-3 und OPC UA abgebildet. Hier werden die Elemente des IEC-Softwaremodells gezeigt, die der untersten Schicht der Steuerungsarchitektur zugeordnet sind. Diese Zuordnung sorgt für transparente Kommunikation, da man heutzutage, wenn ein IEC61131-3-Steuerungsprogramm auf verschiedenen Steuerungsplattformen von verschiedenen Steuerungsanbietern läuft, durch die Nutzung von OPC UA und Zugangsprozess-Variablen mit diesen Steuerungen kommunizieren kann. Jedoch ist die Darstellung im Namensbereich der OPC UA-Server für jede Plattform verschieden: Ein Visualisierungsprogramm muss für jede Steuerung angepasst werden, auch wenn der Steuercode identisch ist. Das erfüllt nicht die Erwartungen der Kunden, nämlich dass ein identisches Steuerungsprojekt via OPC UA auf die selbe Art und Weise zugänglich ist. Hier kommt die Definition von PLCopen OPC UA ins Spiel. Diese definiert den Zugang zu den Instanzen der Steuerungsvariablen sowie die Beschreibungen, wie komplexe Datenstrukturen konstruiert sind, den genutzten Funktionsblock-Typ und welche Variable ein Ein- oder Ausgangs-Parameter ist. Andere Metadaten können die Anzahl an Aufgaben und ihre Zykluszeiten sein. Die PLCopen hat dafür gesorgt, dass das gesamte IEC61131-3-Softwaremodell und der Inhalt des Steuerungsprogrammes im OPC UA Namensbereich abgebildet sind. Dieser Namensbereich kann - sogar während des laufenden Betriebes - mithilfe eines OPC UA-Servers zur Verfügung gestellt werden, der in einem Embedded Controller integriert und mit Benennungskonventionen harmonisiert ist, wodurch er für verschiedene OPC UA-Clients, also verschiedene HMI- und ERP-Systeme, gleich aussieht. Allgemein gesagt definiert die OPC UA also 'wie' und die PLCopen definiert 'was' kommuniziert wird. Die Spezifikation für das PLCopen OPC UA-Informationsmodell kann auf der Webseite von PLCopen heruntergeladen werden.
Bild: PLCopenErgänzung der OPC UA-Clienttechnologie um IEC61131-3
In unserer modernen Welt haben die strikte Trennung von Ebenen und der Top-Down-Ansatz im Informationsfluss, wie sie im CIM-Dreieck definiert sind, keine dominante Stellung mehr. In einem smarten Netzwerk muss jedes Gerät und jeder Service dazu in der Lage sein, eigenständige Kommunikation mit allen anderen Services einzuleiten. Um das umzusetzen haben die PLCopen und OPC UA dem PLCopen/IEC61131-3-Controller die OPC UA-Clientfunktionalität hinzugefügt - häufig neben der Serverfunktionalität. Dafür haben die Organisationen eine Reihe von Client-Funktionsblöcken definiert. Mit dieser in eine Steuerung implementierten Funktionalität ist es möglich, eine Kommunikation zu jedem anderen verfügbaren OPC UA-Server aufzubauen. Die Steuerung kann komplexe Datenstrukturen horizontal mit anderen Steuerungen und unabhängig von Feldbus-Systemen austauschen oder vertikal mit anderen Geräten, die einen OPC UA-Server mit einem MES/ERP-System nutzen, um Daten zu sammeln oder neue Produktionsanweisungen in die Cloud zu schreiben. Das erlaubt einer Produktionslinie eigenständig in Kombination mit integrierten OPC UA-Sicherheitsfunktionen aktiv zu sein. Dies beinhaltet Funktionalitäten wie 'Connect', um eine (optional gesicherte) Transportverbindung einer OPC UA-Sitzung zu erstellen, und 'Read and Write' für sowohl einzelne als auch eine Liste aller Elemente. Man kann ein Abonnement erstellen und diesem überwachte Items hinzufügen; man kann nach einem Client zur Navigation durch den Adressenbereich eines OPC UA-Servers suchen, um Events sowie natürlich Diagnose-Funktionen anzeigen zu lassen. Zusätzlich gibt es einen Methodenabruf, mit dem man Routinen in anderen Systemen, beispielsweise einer Cloud, abrufen und das Feedback lokal oder in jedem anderen intelligenten System, mit dem man kommunizieren kann, nutzen kann. Die Spezifikation für den PLCopen OPC UA-Client für IEC61131-3 kann auf der PLCopen-Webseite heruntergeladen werden.
Bild: PLCopenWo liegt der Nutzen für den Anwender?
Durch die Zuordnung des OPC UA-Informationsmodelles in das PLCopen/IEC61131-3-Softwaremodell erhält man einen einheitlichen Blick und ein Gefühl für die in verschiedene Fabrikate von Steuerungen eingebettete OPC UA-Servertechnologie. Das ist die Basis einer 'Out-of-the-Box'-Kommunikation, die Security enthalten kann. Wenn man Benennungskonventionen innerhalb des Unternehmens harmonisiert, kann man leicht und unabhängig von Marken ein Template im HMI mit den zutreffenden Daten(-strukturen) in der Steuerung verbinden, solange diese die PLCopen OPC UA-Zuordnung unterstützen. Ein Beispiel für diese Benennungskonventionen sind die PackTags und die Statemachine für Verpackungsspezifikationen, definiert in der OMAC PackML als Teil des 'ISA 88 Technical Report on Machine and Unit States'. Nutzt man diese Benennungen konsequent, kann man eine Steuerung 'Out-of-the-Box' mithilfe des OPC UA-Clients mit der PLCopen-Umgebung verbinden. Mit dem in der Steuerung beinhalteten Client kann man die Kommunikation auf der niedrigsten Ebene initiieren, wodurch komplett neue Hierarchien und Architekturen ermöglicht werden. Sogar eine Steuerung-zu-Steuerung-Kommunikation kann einfach verwirklicht werden, unabhängig von der genutzten Kommunikationsarchitektur. Das gibt die Möglichkeit einer neuen Steuerungsarchitektur, in der die Kommunikation den verschiedenen Phasen der Fertigstellung eines Produktes folgt, wie in Abbildung 3 zu sehen ist. Ein Beispiel: Wenn eine Steuerung eine spezifische Geschwindigkeit für ein Transportsystem (z.B. ein Transportband) festlegt, das ein Produkt bewegt, das von einem Roboterarm aufgenommen werden soll. Hier kann die Steuerung einen Methodenaufruf zur Robotersteuerung für die Aufnahme des Produktes durchführen, während sie die Geschwindigkeit des Transportbandes überträgt. Umgedreht kann der Roboter einen Methodenaufruf zur intelligenten Kamera durchführen, um die Rotation und den Translationswert des Produktes zu erhalten. Mit diesen Werten kann der Roboter die Bahn kalkulieren, um das Produkt sanft und korrekt aufzugreifen. Außerdem ist eine Kommunikation der Steuerung mit dem ERP/MES-System möglich, um Empfangsinformationen und die Produktverfolgung abzurufen. Das erlaubt ebenfalls neue Möglichkeiten, wie die Einleitung von Kommunikation auf der niedrigsten möglichen Ebene der Organisation als Basis der Produktion im Konzept Industrie 4.0, wie in Abbildung 5 zu sehen ist. Das bedeutet, dass ein Produkt eine RFID haben kann, die alle relevanten Informationen über seine Herstellung beinhaltet. Diese Informationen können von der Steuerung gelesen werden und die verschiedenen Arbeitsstationen können dann die entsprechenden Schritte durchführen, z.B. das Hinzugeben von 98g Joghurt im ersten Schritt. Am Ende schreibt dann die Inspektionseinheit die Schritte zurück, die geprüft wurden, und führt einen Methodenabruf zum ERP-System durch, um die Resultate der Verarbeitung und Abwicklung an das Track-and-Trace-System weiterzuleiten. So ein System kann sogar in der Cloud laufen und ist bereits heute möglich.
Zukünftige Entwicklungen in der OPC Foundation
Das ist nicht das Ende der Entwicklung. Verbesserungen für OPC UA, wie Real-Time-Erweiterungen mit TSN (Time Sensitive Network, das das Ethernet deterministisch macht), werden eine Real-Time-Datenkommunikation möglich machen, die die Basis zum Transportieren sicherheitsrelevanter Informationen schafft und eine Synchronisation zwischen verschiedenen intelligenten Geräten (wie beispielsweise Robotern) erlaubt. Besonders die Synchronisation, kombiniert mit Publisher/Subscriber-Funktionen, macht verschiedene Kommunikationsphilosophien möglich. Das zeigt wieder, dass weitere Verbesserungen und Optimierungen bei der Programmierung, Installation und Wartung von kommunikationsbasierten Architekturen möglich sind. Egal was Initiativen wie Industrie 4.0, Smart Factories, Industrial Internet of Things oder andere verlangen: Aktuelle Lösungen können bereits heute die meisten Anforderungen erfüllen und mit den richtigen Erweiterungen sind sogar die anspruchsvollsten Anforderungen mit normalen Spezifizierungen, Werkzeugen und Implementierungen umsetzbar. Kommunikation war noch nie so einfach, solange man auf der richtigen Spur ist: PLCopen und OPC UA.
Die Digitalisierung der Produktion bedingt eine effiziente Verbindung von intelligenten Systemen, Sensoren und Aktoren als eines ihrer zentralen Elemente. Dieser Artikel zeigt, dass die aktuellsten Lösungen bereits den meisten Anforderungen genügen und mit Erweiterungen sogar die aufwändigsten Vorgaben mit Spezifikationen, Werkzeugen und Implementierungen erfüllen können - ein weiterer Schritt in Richtung Akzeptanz von neuen Technologien und Architekturen.
Bild: PLCopenDas Thema Kommunikation ist in der industriellen Steuerung nicht neu. Das berühmte CIM-Dreieck ist rund 30 Jahre alt und es werden heute in verschiedenen Industriezweigen nach wie vor viele historisch gewachsene Datenaustauschprotokolle genutzt. Sie bieten nur wenig Möglichkeit zum Transport von komplexen Daten und die Erweiterbarkeit ist sehr begrenzt.Bild: PLCopen
Bild: PLCopenEinführung in die OPC UA-Technologie
OPC Unified Architecture (OPC UA) bietet die Basis für universelle, offene, hardware- und softwareunabhängige, sichere und zuverlässige Netzwerkkommunikation - also für die Überwachung von konfigurierbaren Timeouts und Verbindungsunterbrechungen sowie verschlüsselte Kommunikation. Hierfür dient eine skalierbare Client/Server-Architektur, in der der Client die Datenabfrage initiiert und der Server darauf reagiert und - möglicherweise über einen abgesicherten Kanal - diese Daten gebrauchsfertig liefert (Siehe Abbildung 1). Diese Funktionalitäten waren die Basis für PLCopen, die OPC UA-Technologie zu nutzen, um in Kooperation mit der OPC Foundation die Kommunikation in industriellen Steuerungen zu harmonisieren.
Die OPC UA-Servertechnologie in der IEC61131-3
Zu diesem Zweck wurde eine gemeinsame Arbeitsgruppe gebildet. Der erste Schritt dieser Arbeitsgruppe war die Definitionsplanung und -darstellung des OPC UA-Informationsmodells im IEC61131-3-Softwaremodell. Das OPC UA-Informationsmodell beinhaltet einen standardisierten Weg, wie Server Objekte den Clienten freigeben. Objekte bestehen in der OPC UA-Bezeichnung aus anderen Objekten, Variablen und Methoden. In diesem Fall werden Objekte dazu genutzt, die Komponenten des IEC61131-3-Softwaremodells zu repräsentieren, wie 'CtrlProgram', 'CtrlTask', 'CtrlResource' und 'CtrlFunction Blocks', und Variablen repräsentieren Werte. Das führt zu einem standardisierten Weg, wie Steuerungen mit integrierter OPC UA-Servertechnologie Datenstrukturen und Funktionsblöcke an OPC UA-Clienten, wie HMIs und ERP-Systeme, weitergeben. In Abbildung 2 sind insgesamt vier Schichten zu sehen, wovon die obersten beiden in Bezug zu OPC UA stehen. In Schicht 3 ist die Verbindung zwischen IEC61131-3 und OPC UA abgebildet. Hier werden die Elemente des IEC-Softwaremodells gezeigt, die der untersten Schicht der Steuerungsarchitektur zugeordnet sind. Diese Zuordnung sorgt für transparente Kommunikation, da man heutzutage, wenn ein IEC61131-3-Steuerungsprogramm auf verschiedenen Steuerungsplattformen von verschiedenen Steuerungsanbietern läuft, durch die Nutzung von OPC UA und Zugangsprozess-Variablen mit diesen Steuerungen kommunizieren kann. Jedoch ist die Darstellung im Namensbereich der OPC UA-Server für jede Plattform verschieden: Ein Visualisierungsprogramm muss für jede Steuerung angepasst werden, auch wenn der Steuercode identisch ist. Das erfüllt nicht die Erwartungen der Kunden, nämlich dass ein identisches Steuerungsprojekt via OPC UA auf die selbe Art und Weise zugänglich ist. Hier kommt die Definition von PLCopen OPC UA ins Spiel. Diese definiert den Zugang zu den Instanzen der Steuerungsvariablen sowie die Beschreibungen, wie komplexe Datenstrukturen konstruiert sind, den genutzten Funktionsblock-Typ und welche Variable ein Ein- oder Ausgangs-Parameter ist. Andere Metadaten können die Anzahl an Aufgaben und ihre Zykluszeiten sein. Die PLCopen hat dafür gesorgt, dass das gesamte IEC61131-3-Softwaremodell und der Inhalt des Steuerungsprogrammes im OPC UA Namensbereich abgebildet sind. Dieser Namensbereich kann - sogar während des laufenden Betriebes - mithilfe eines OPC UA-Servers zur Verfügung gestellt werden, der in einem Embedded Controller integriert und mit Benennungskonventionen harmonisiert ist, wodurch er für verschiedene OPC UA-Clients, also verschiedene HMI- und ERP-Systeme, gleich aussieht. Allgemein gesagt definiert die OPC UA also 'wie' und die PLCopen definiert 'was' kommuniziert wird. Die Spezifikation für das PLCopen OPC UA-Informationsmodell kann auf der Webseite von PLCopen heruntergeladen werden.
Bild: PLCopenErgänzung der OPC UA-Clienttechnologie um IEC61131-3
In unserer modernen Welt haben die strikte Trennung von Ebenen und der Top-Down-Ansatz im Informationsfluss, wie sie im CIM-Dreieck definiert sind, keine dominante Stellung mehr. In einem smarten Netzwerk muss jedes Gerät und jeder Service dazu in der Lage sein, eigenständige Kommunikation mit allen anderen Services einzuleiten. Um das umzusetzen haben die PLCopen und OPC UA dem PLCopen/IEC61131-3-Controller die OPC UA-Clientfunktionalität hinzugefügt - häufig neben der Serverfunktionalität. Dafür haben die Organisationen eine Reihe von Client-Funktionsblöcken definiert. Mit dieser in eine Steuerung implementierten Funktionalität ist es möglich, eine Kommunikation zu jedem anderen verfügbaren OPC UA-Server aufzubauen. Die Steuerung kann komplexe Datenstrukturen horizontal mit anderen Steuerungen und unabhängig von Feldbus-Systemen austauschen oder vertikal mit anderen Geräten, die einen OPC UA-Server mit einem MES/ERP-System nutzen, um Daten zu sammeln oder neue Produktionsanweisungen in die Cloud zu schreiben. Das erlaubt einer Produktionslinie eigenständig in Kombination mit integrierten OPC UA-Sicherheitsfunktionen aktiv zu sein. Dies beinhaltet Funktionalitäten wie 'Connect', um eine (optional gesicherte) Transportverbindung einer OPC UA-Sitzung zu erstellen, und 'Read and Write' für sowohl einzelne als auch eine Liste aller Elemente. Man kann ein Abonnement erstellen und diesem überwachte Items hinzufügen; man kann nach einem Client zur Navigation durch den Adressenbereich eines OPC UA-Servers suchen, um Events sowie natürlich Diagnose-Funktionen anzeigen zu lassen. Zusätzlich gibt es einen Methodenabruf, mit dem man Routinen in anderen Systemen, beispielsweise einer Cloud, abrufen und das Feedback lokal oder in jedem anderen intelligenten System, mit dem man kommunizieren kann, nutzen kann. Die Spezifikation für den PLCopen OPC UA-Client für IEC61131-3 kann auf der PLCopen-Webseite heruntergeladen werden.
Bild: PLCopenWo liegt der Nutzen für den Anwender?
Durch die Zuordnung des OPC UA-Informationsmodelles in das PLCopen/IEC61131-3-Softwaremodell erhält man einen einheitlichen Blick und ein Gefühl für die in verschiedene Fabrikate von Steuerungen eingebettete OPC UA-Servertechnologie. Das ist die Basis einer 'Out-of-the-Box'-Kommunikation, die Security enthalten kann. Wenn man Benennungskonventionen innerhalb des Unternehmens harmonisiert, kann man leicht und unabhängig von Marken ein Template im HMI mit den zutreffenden Daten(-strukturen) in der Steuerung verbinden, solange diese die PLCopen OPC UA-Zuordnung unterstützen. Ein Beispiel für diese Benennungskonventionen sind die PackTags und die Statemachine für Verpackungsspezifikationen, definiert in der OMAC PackML als Teil des 'ISA 88 Technical Report on Machine and Unit States'. Nutzt man diese Benennungen konsequent, kann man eine Steuerung 'Out-of-the-Box' mithilfe des OPC UA-Clients mit der PLCopen-Umgebung verbinden. Mit dem in der Steuerung beinhalteten Client kann man die Kommunikation auf der niedrigsten Ebene initiieren, wodurch komplett neue Hierarchien und Architekturen ermöglicht werden. Sogar eine Steuerung-zu-Steuerung-Kommunikation kann einfach verwirklicht werden, unabhängig von der genutzten Kommunikationsarchitektur. Das gibt die Möglichkeit einer neuen Steuerungsarchitektur, in der die Kommunikation den verschiedenen Phasen der Fertigstellung eines Produktes folgt, wie in Abbildung 3 zu sehen ist. Ein Beispiel: Wenn eine Steuerung eine spezifische Geschwindigkeit für ein Transportsystem (z.B. ein Transportband) festlegt, das ein Produkt bewegt, das von einem Roboterarm aufgenommen werden soll. Hier kann die Steuerung einen Methodenaufruf zur Robotersteuerung für die Aufnahme des Produktes durchführen, während sie die Geschwindigkeit des Transportbandes überträgt. Umgedreht kann der Roboter einen Methodenaufruf zur intelligenten Kamera durchführen, um die Rotation und den Translationswert des Produktes zu erhalten. Mit diesen Werten kann der Roboter die Bahn kalkulieren, um das Produkt sanft und korrekt aufzugreifen. Außerdem ist eine Kommunikation der Steuerung mit dem ERP/MES-System möglich, um Empfangsinformationen und die Produktverfolgung abzurufen. Das erlaubt ebenfalls neue Möglichkeiten, wie die Einleitung von Kommunikation auf der niedrigsten möglichen Ebene der Organisation als Basis der Produktion im Konzept Industrie 4.0, wie in Abbildung 5 zu sehen ist. Das bedeutet, dass ein Produkt eine RFID haben kann, die alle relevanten Informationen über seine Herstellung beinhaltet. Diese Informationen können von der Steuerung gelesen werden und die verschiedenen Arbeitsstationen können dann die entsprechenden Schritte durchführen, z.B. das Hinzugeben von 98g Joghurt im ersten Schritt. Am Ende schreibt dann die Inspektionseinheit die Schritte zurück, die geprüft wurden, und führt einen Methodenabruf zum ERP-System durch, um die Resultate der Verarbeitung und Abwicklung an das Track-and-Trace-System weiterzuleiten. So ein System kann sogar in der Cloud laufen und ist bereits heute möglich.
Zukünftige Entwicklungen in der OPC Foundation
Das ist nicht das Ende der Entwicklung. Verbesserungen für OPC UA, wie Real-Time-Erweiterungen mit TSN (Time Sensitive Network, das das Ethernet deterministisch macht), werden eine Real-Time-Datenkommunikation möglich machen, die die Basis zum Transportieren sicherheitsrelevanter Informationen schafft und eine Synchronisation zwischen verschiedenen intelligenten Geräten (wie beispielsweise Robotern) erlaubt. Besonders die Synchronisation, kombiniert mit Publisher/Subscriber-Funktionen, macht verschiedene Kommunikationsphilosophien möglich. Das zeigt wieder, dass weitere Verbesserungen und Optimierungen bei der Programmierung, Installation und Wartung von kommunikationsbasierten Architekturen möglich sind. Egal was Initiativen wie Industrie 4.0, Smart Factories, Industrial Internet of Things oder andere verlangen: Aktuelle Lösungen können bereits heute die meisten Anforderungen erfüllen und mit den richtigen Erweiterungen sind sogar die anspruchsvollsten Anforderungen mit normalen Spezifizierungen, Werkzeugen und Implementierungen umsetzbar. Kommunikation war noch nie so einfach, solange man auf der richtigen Spur ist: PLCopen und OPC UA.
PLCopen
Dieser Artikel erschien in SPS-MAGAZIN 1+2 2017 - 10.02.17.Für weitere Artikel besuchen Sie www.sps-magazin.de
