Field Level Communications (FLC) Initiative der OPC Foundation zeigt die erste OPC UA FX Multi-Vendor-Demo

OPC UA für die Feldebene

Die Field Level Communications (FLC) Initiative der OPC Foundation wurde ins Leben gerufen, um OPC UA auch in der Feldebene als einheitliche, durchgängige und herstellerunabhängige Industrie-Interoperabilitätslösung zu etablieren. Dazu werden Erweiterungen für das OPC UA Framework spezifiziert, welche die Semantik und das Verhalten von Steuerungen und Feldgeräten verschiedener Hersteller vereinheitlichen und dies sowohl für die diskrete Fertigung wie auch für die Prozessindustrie.
 Abb. 1: Die OPC UA FX Multi-Vendor-Demo zeigt das Zusammenspiel von Automatisierungs- und Netzwerkinfrastrukturkomponenten
verschiedener Hersteller, um Prozessdaten in der Feldebene auszutauschen.
Abb. 1: Die OPC UA FX Multi-Vendor-Demo zeigt das Zusammenspiel von Automatisierungs- und Netzwerkinfrastrukturkomponenten verschiedener Hersteller, um Prozessdaten in der Feldebene auszutauschen.Bild: OPC Foundation, ©metamorworks /shutterstock.com

Drei Jahre nach ihrem Start hat die Initiative die ersten Spezifikationen fertiggestellt. In diesen werden unter der Bezeichnung OPC UA FX (Field eXchange) Anwendungsfälle für die Vernetzung von Steuerungen adressiert, welche flexible und rekonfigurierbare Verarbeitungs- und Fertigungsprozesse unterstützen. Im Rahmen einer Multi-Vendor-Demo wurde das Zusammenspiel von Steuerungsprototypen erprobt, welche Prozessdaten auf der Basis von OPC UA und den OPC UA FX Erweiterungen austauschen (siehe Abb. 1).

 Abb. 2: Schematischer Aufbau der ersten OPC UA FX Multi-Vendor-Demo
Abb. 2: Schematischer Aufbau der ersten OPC UA FX Multi-Vendor-DemoBild: OPC Foundation

Anwendungsbeispiel

Zur Veranschaulichung der Anwendung von OPC UA FX ein Beispiel: Ein Maschinenbetreiber kauft zwei identische Werkzeugmaschinen von Hersteller 1 und zwei identische Roboter von Hersteller 2, um das Be- und Entladen der Werkzeugmaschinen zu automatisieren. Um die Abläufe zwischen Werkzeugmaschine und Roboter zu steuern und zu synchronisieren, müssen die jeweiligen Steuerungen definierte Prozessdaten untereinander austauschen. Weder die Werkzeugmaschine noch der Roboter ändern nach der Installation ihre Funktion oder ihren Betrieb, aber es wird nicht vorab geplant, welche Maschine an welchen Roboter angeschlossen wird und möglicherweise wird auch die Netzwerk-Identifikation der verschiedenen Steuerungen nicht vorab festgelegt. Zum Zeitpunkt der Inbetriebnahme muss jeder Maschine und jedem Roboter (oder genauer gesagt, den jeweiligen Steuerungen) ihre Netzwerkidentifikation und die Netzwerkidentifikation des jeweiligen Kommunikationspartners zugewiesen werden. Weitere Konfigurationen sollen von Seiten des Anwenders nicht erforderlich sein, um einen Plug&Produce-Betrieb mit einem Austausch von Echtzeit- und Safety-Daten zu ermöglichen.

 Abb. 4: Dashboard der Multi-Vendor-Demo (Asset View)
Abb. 4: Dashboard der Multi-Vendor-Demo (Asset View)Bild: OPC Foundation

Technischer Lösungsansatz von OPC UA FX

Um das oben beschriebene Plug&Produce-Konzept zu ermöglichen, wird das OPC UA Framework um entsprechende Features erweitert, die nachfolgend beschrieben werden. UAFX-Steuerungen müssen ausgewählte Informationen über ein vorgeschriebenes OPC-UA-Informationsmodell, das so genannte Automation Component (AC), das sowohl das Funktionsmodell als auch das Anlagenmodell enthält, offenlegen. Der Umfang eines AC liegt im Ermessen des Anbieters. Es kann so klein sein wie ein einzelner, kompakter I/O-Controller mit acht Datenpunkten oder so groß wie eine komplexe, raumgroße Maschine. Das Anlagenmodell beschreibt physische Objekte, kann aber auch nicht physische Objekte wie Firmware oder Lizenzen umfassen. Das Funktionsmodell beschreibt eine logische Funktionalität. Es besteht aus einer oder mehreren Funktionseinheiten (Functional Entities), die jeweils Ein-/Ausgabevariablen, Kommunikations- und Geräteparameter sowie Kommunikationsverbindungen kapseln. Eine Functional Entity (FE) ist von der Hardware abstrahiert, was die Portierung von Anwendungen auf neue Hardware ermöglicht. Der sogenannte Connection Manager (CM) ist ein Dienst, der in der Regel in einer der Steuerungen angesiedelt ist und für den Aufbau bzw. die Verwaltung von Verbindungen zwischen FEs in verschiedenen Steuerungen zuständig ist. Eine UAFX-Verbindung wird zunächst über Client/Server-Mechanismen aufgebaut, wobei Informationen zum Aufbau einer bidirektionalen PubSub-Verbindung (u.a. Kompatibilitätsprüfung, Parametrierung) ausgetauscht werden. Danach wird die PubSub-Verbindung vorbereitet und in Betrieb genommen.

Offline Engineering ist ein wichtiges Element für die Entwicklung, den Betrieb und die Wartung eines Automatisierungssystems. Dadurch, dass der Benutzer in die Lage versetzt wird, die Funktionsweise des Automatisierungssystems zu verstehen bevor er das System in physischer Hardware einsetzt, weiß er, dass das System die Steuerungsfunktion zuverlässig und korrekt ausführen wird, sobald das physische System installiert ist. Um dies zu ermöglichen, werden sogenannte Deskriptoren verwendet. Der Deskriptor eines AC ist ein Satz von Dokumenten, der ein OPC UA Informationsmodell und möglicherweise andere nützliche Informationen für Konfigurationszwecke enthält. Die Informationen können für ein einzelnes AC oder eine Gruppe von ACs (wie eine Maschine oder ein Maschinenmodul) sein. Der AC-Deskriptor wird in einem verpackten Containerformat geliefert, das sowohl Produkt- als auch Konfigurationsinformationen enthält. Der Produktdeskriptor enthält die Produktdaten der Steuerung und wird in der Regel vom Hersteller der Steuerung bereitgestellt. Der Konfigurationsdeskriptor enthält Informationen wie Funktionseinheiten, Kommunikationsdatensätze, erforderliche Dienstgüte (QoS) und Daten, die für eine oder mehrere Verbindungen erforderlich sind. Der Konfigurationsdeskriptor wird im Engineering-Prozess erstellt, normalerweise mit der Absicht, Engineering-Informationen zwischen zwei Engineering-Tools auszutauschen.

Auch Safety-Daten können zwischen Steuerungen ausgetauscht werden. Zum Einsatz kommt dafür OPC UA Safety, ein Sicherheitsprotokoll, das über die Standard UAFX-Verbindungen übertragen wird. Der Vorteil dieses Ansatzes ist es, dass sich der Bewertungs- und Prüfungsaufwand durch eine benannte Stelle (z.B. TÜV) auf das sichere Übertragungsprotokoll beschränkt, und die zugrunde liegenden UAFX-Verbindungen keiner zusätzlichen Bewertung und Prüfung bedürfen.

Jede UAFX-Verbindung kann durch Standard OPC UA Security-Mechanismen, die für die Client/Server und PubSub Kommunikation spezifiziert sind, authentifiziert und optional verschlüsselt werden. Der Verbindungsaufbau erfolgt nach dem Aufbau einer OPC UA Secure Session unter Verwendung von asymmetrischer Kryptographie mit Zertifikaten und privaten Schlüsseln.

 Abb. 5: Dashboard der Multi-Vendor-Demo mit der Visualisierung von zwei Produktionslinien
Abb. 5: Dashboard der Multi-Vendor-Demo mit der Visualisierung von zwei ProduktionslinienBild: OPC Foundation

Erste OPC UA FX Multi-Vendor-Demo

Im November 2021 wurde erstmals eine Multi-Vendor-Interoperabilitätsdemo realisiert, in der Automatisierungs- und Netzwerkkomponenten von insgesamt über 20 Herstellern kombiniert wurden, um einen herstellerübergreifenden Datenaustausch über OPC UA und die OPC UA FX Erweiterungen zu veranschaulichen. Dazu wurden 17 Steuerungen (u.a. SPS- und Robotersteuerungen, sowie DCS-Systeme) von verschiedenen Anbietern – darunter die größten Automatisierungshersteller der Welt – über eine gemeinsame Netzwerkinfrastruktur vernetzt. Diese Infrastruktur besteht aus herkömmlichen Ethernet Switches, Ethernet TSN (Time-Sensitive-Networking) Switches, sowie einem 5G-Testbed unter Nutzung des Millimeterwellen-Frequenzbereichs (siehe Abb. 2).

Alle Steuerungen des Demonstrators stellen über einen integrierten OPC UA Server aktuelle Status- und Anlageninformationen zur Verfügung, die über ein zentrales Dashboard abgefragt und visualisiert werden. Im All Controller View werden für alle 17 Steuerungen der Multi-Vendor Demo der Status der OPC UA Verbindungen, sowie Informationen über die von den UAFX Steuerungsprototypen jeweils konfigurierten, PubSub-basierten UAFX Verbindungen angezeigt (siehe Abb. 3).

Das Dashboard selbst ist interaktiv und wechselt beim Klicken auf eine der 17 Steuerungen in die Asset View, in welcher die von den Steuerungen modellierten und bereitgestellten UAFX Asset Informationen angezeigt werden (siehe Abb. 4).

Um die Möglichkeiten und Vorteile der UAFX-Erweiterungen exemplarisch aufzuzeigen, wurde im Demonstrator eine modulare Flaschenabfüllanlage simuliert, in der jeweils vier Maschineneinheiten zum Reinigen, Abfüllen, Verschließen und Etikettieren der Flaschen zu einer Produktionslinie kombiniert werden. Jede dieser Einheiten ist für Demozwecke mit einer Steuerung eines anderen Herstellers ausgerüstet.

Die Konfiguration der Kommunikationsverbindungen und der über diese Verbindungen ausgetauschten Prozessdaten zur Umsetzung einer funktionierenden Produktionslinie erfolgt über einen UAFX Connection Manager, wie bereits oben beschrieben. Im Demonstrator kommen ein externer, auf dem UA Expert basierender Connection Manager von Unified Automation, sowie ein in die SIMATIC-SPS von Siemens integrierter Connection Manager, jeweils mit einer eigenen grafischen Benutzeroberfläche, zum Einsatz. Die Connection Manager agieren dabei als OPC UA Client und nutzen die in die UAFX Steuerungsprototypen integrierten OPC UA Server, um zwischen den jeweiligen Steuerungen UAFX Verbindungen zu konfigurieren. Über diese UAFX Verbindungen werden dann die entsprechenden Prozessdaten mittels OPC UA Pub/Sub ausgetauscht. Die Steuerungen agieren dabei als UAFX Publisher und/oder UAFX Subscriber. Bei den Prozessdaten kann es sich um Echtzeitdaten oder beispielsweise auch Safety-Daten handeln. Im Dashboard können die konfigurierten Produktionslinien visualisiert und überwacht werden (siehe Abb. 5).

 Abb. 6: Vereinheitlichung der horizontalen Kommunikation über OPC UA FX (a), sowie Migration zu einem durchgängigen, konvergenten Netzwerk (b) auf Basis von Ethernet TSN (Time-Sensitive Networking).
Abb. 6: Vereinheitlichung der horizontalen Kommunikation über OPC UA FX (a), sowie Migration zu einem durchgängigen, konvergenten Netzwerk (b) auf Basis von Ethernet TSN (Time-Sensitive Networking).Bild: OPC Foundation

Zusammenfassung und Ausblick

Mit der ersten OPC UA FX Spezifikation werden Erweiterungen des OPC UA Frameworks definiert, welche eine einheitliche Vernetzung zwischen Steuerungen über eine gemeinsame Netzwerkinfrastruktur ermöglicht, um Prozessdaten auf Basis einer herstellerübergreifenden Schnittstelle auszutauschen. Damit etabliert sich OPC UA als herstellerunabhängige Schnittstelle nicht nur für die vertikale Integration von der Steuerungsebene in die Edge bzw. bis in die Cloud, sondern zusätzlich als Schnittstelle zum Austausch von Prozessdaten zwischen Steuerungen, unabhängig davon, über welches Protokoll diese Steuerungen jeweils mit den unterlagerten Feldgeräten, wie z.B. Servoantriebe, dezentrale I/Os, Sensoren kommunizieren (Abb. 6a).

Im nächsten Schritt werden die für den Use Case Controller-to-Controller erarbeiteten Konzepte für Controller-to-Device (C2D) und Device-to-Device (D2D) erweitert. Damit werden zusätzliche Anwendungsfälle unterstützt, einschließlich weiterer Funktionen und gerätespezifischer Modelle, z.B. für Motion Control, Instrumentierung und dezentrale I/Os. Damit steht dann mit OPC UA ein einheitlicher Kommunikationsstandard zur Verfügung, der über alle Ebenen hinweg, vom Feld bis in die Cloud, komplett skaliert, sowohl vertikal als auch horizontal.

Gerade weil in der Feldebene heutzutage verschiedene konkurrierende und inkompatible Protokolle verwendet werden und OPC UA FX eine Harmonisierung herbeiführen soll, kommt dem deterministischen Ethernet TSN und dem TSN IA (Industrial Automation) Profil der IEC/IEEE60802 eine besonders wichtige Bedeutung zu. Denn damit können unterschiedliche Protokolle, unabhängig davon, ob es sich um IT- oder OT-Protokolle handelt, in einer einheitlichen und gemeinsamen Netzwerkinfrastruktur koexistieren. Damit wird eine schrittweise Migration herkömmlicher industrieller Ethernet-Protokolle hin zu einer einheitlichen OPC UA-basierten Kommunikationslösung ermöglicht (Abb. 6b) und Barrieren aufgrund von inkompatiblen Protokollen und Profilen können Zug um Zug abgebaut werden. Ein entscheidender Erfolgsfaktor dabei ist, dass OPC UA von allen großen Anbietern unterstützt wird, sodass Anwender künftig in ihrer Entscheidung frei werden, welche Systeme und Komponenten sie in ihren Produktionsanlagen und Fabriken einsetzen.

Das könnte Sie auch Interessieren

Anzeige

Anzeige

Anzeige

Anzeige

Anzeige