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).
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.
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.
