Bild 1. Die Field Level Communications Initiative der OPC Foundation – Erweiterung von OPC UA auf die Feldebene.

© OPC Foundation

Die Field Level Communications (FLC) Initiative der OPC Foundation wurde im November 2018 ins Leben gerufen, um OPC UA auch in der Feldebene als einheitliche, durchgängige und herstellerunabhängige Industrie-Interoperabilitäts- Lösung zu etablieren (Bild 1). In der ersten Phase der FLC-Initiative lag der Fokus auf der Controller-to-Controller-Kommunikation, die flexible und rekonfigurierbare Verarbeitungs- und Fertigungsprozesse unterstützt und dabei unter anderem den zyklischen Austausch von echtzeit- und sicherheitskritischen Prozessdaten ermöglicht. Der gewählte Lösungsansatz ist dabei generisch gehalten, das heißt er deckt die Anforderungen von Anwendungen in der diskreten Fertigung wie auch der Prozessindustrie gleichermaßen ab. Die Spezifikationen zur Erweiterung von OPC UA für die Feldebene wurden unter dem Namen OPC UA FX (Field eXchange) veröffentlicht. Die spezifizierten Konzepte bilden dabei die Grundlage für Spezifikationserweiterungen, welche künftig auch die Anwendungsszenarien Controller-to-Device- (C2D) und Device-to-Device-Kommunikation (D2D) unterstützen.

Die OPC UA FX Systemarchitektur

Bild 2. Die OPC UA und OPC UA FX System Architektur.

© OPC Foundation

Der Lösungsansatz für OPC UA FX basiert auf dem OPC UA Framework mit seinen Mechanismen zur Informationsmodellierung, den integrierten Security-Funktionen und den Kommunikationsdiensten Client/Server und PubSub, wie in Bild 2 dargestellt. UAFX-Steuerungen und im nächsten Schritt auch UAFX-Feldgeräte müssen ausgewählte Informationen über ein definiertes OPC UA-Informationsmodell die Automation Component (AC), die sowohl das Funktionsmodell als auch das Asset-Modell enthält, offenlegen. Der Umfang einer AC liegt im Ermessen des Anbieters. Sie kann so klein sein, wie ein einzelnes, kompaktes E/A-Modul – oder so groß wie eine komplexe, raumgroße Maschine. Das Asset-Modell beschreibt physische Objekte, kann aber auch nicht physische Objekte wie Firmware oder Lizenzen umfassen. Das Funktionsmodell beschreibt eine logische Funktionalität und definiert durch das Informationsmodell eine definierte Schnittstelle. Es besteht aus einer oder mehreren Functional Entities (FE), die jeweils Ein-/Ausgabevariablen, Kommunikations- und Geräteparameter, sowie Kommunikationsverbindungen kapseln. Eine Functional Entity ist von der Hardware abstrahiert, so dass Anwendungen auf neue Hardware portiert werden können. Der Connection Manager (CM) ist ein Dienst, der sich in der Regel in einer der Steuerungen befindet. Dieser ist für den Aufbau und die Verwaltung von Verbindungen zwischen FEs in verschiedenen Steuerungen zuständig. Eine UAFX-Verbindung wird zunächst über Client/Server-Mechanismen aufgebaut, wobei Informationen zum Aufbau einer bidirektionalen PubSub-Verbindung – unter anderem Kompatibilitätsprüfungen, Parametrisierung – ausgetauscht werden. Die PubSub-Verbindung wird dann vorbereitet und in Betrieb genommen, das heißt, ab diesem Zeitpunkt können zyklische Prozessdaten zwischen Steuerungen übertragen werden.

Auch sicherheitskritische Daten können zwischen Steuerungen ausgetauscht werden. Hierfür wird mit OPC UA Safety ein Sicherheitsprotokoll verwendet, das Standard-UAFX-Verbindungen nutzt und damit unabhängig von den verwendeten, unterlagerten Transportprotokollen ist. Der Vorteil dieses Ansatzes ist, dass sich der Evaluierungs- und Prüfaufwand durch eine benannte Stelle (z.B. TÜV) auf das sichere Übertragungsprotokoll beschränkt, während die zugrunde liegenden UAFX-Verbindungen und die unterlagerten Kommunikations-Stacks keine zusätzliche Evaluierung und Prüfung erfordern.

Jede UAFX-Verbindung kann durch die für die Client/Server- und PubSub-Kommunikation spezifizierten Standard- OPC UA-Sicherheitsmechanismen authentifiziert und optional verschlüsselt werden. Der Verbindungsaufbau erfolgt nach Abschluss eines OPC UA Secure Session Establishments mittels asymmetrischer Kryptographie mit Zertifikaten und privaten Schlüsseln.

Flexible Transportarchitektur

Features der UAFX Bridge Component Facets (o=optional, ✔=verpflichtend)

© OPC Foundation

Ein Schlüsselelement des OPC UA FX Lösungsansatzes ist die flexible Transportarchitektur, die die Interoperabilität zwischen Automatisierungskomponenten mit zyklischer Kommunikation ermöglicht, einschließlich anwendungsspezifischer Abbildungen auf unterlagerte Kommunikationsprotokolle (wie UDP/IP oder Layer-2 Ethernet) und physikalische Schichten (wie Single-Pair Ethernet, Ethernet-APL oder 5G), um den unterschiedlichen Kommunikationsbedürfnissen gerecht zu werden.

Die PubSub-Kommunikation ist für alle Geräte erforderlich, die an dem zyklischen Austausch von Prozessdaten beteiligt sind. Zusätzliche Kommunikationsfunktionen und -fähigkeiten bauen aufeinander auf, mit kompatiblen Untergruppen von Funktionen, um schrittweise fortgeschrittenere Fähigkeiten zu unterstützen, einschließlich deterministischer Kommunikation über Ethernet Time-Sensitive Networking (TSN). Alle Steuerungen und auch Feldgeräte sind interoperabel über Layer-3-Netzwerke (IP-Netzwerke), die typischerweise in einer großen Anlage mit vielen Skids, Modulen, Maschinen und Zellen eingesetzt werden. Dazu nutzen alle Steuerungen und Feldgeräte OPC UA PubSub unter Verwendung von UDP UADP.

Managed Bridges sind VLAN- (Virtual Local Area Network) und QoS- (Quality of Service) fähig. Sie unterstützen auch Dienste zur Topologie-Erkennung und implementieren IT-Standard-Management-Protokolle. Die Implementierung von Managementfunktionen ist in Bridges obligatorisch (siehe UAFX Base Bridge Component Facet gemäß Tabelle 1). Dies erleichtert die Entwicklung von Netzwerküberwachungs- und -verwaltungswerkzeugen, die die meisten UAFX-Steuerungen und -Geräte in einer einzigen Systemansicht betreiben können, unabhängig davon, ob sie TSN-Funktionen implementiert haben oder nicht.

Ethernet Time-Sensitive Networking (TSN)

Die UAFX Transport-Architektur

© OPC Foundation

TSN bietet Mechanismen zur Realisierung von Netzwerken mit garantierter Latenz und ohne Paketverlust bei Überlast, wie sie für einige Automatisierungsanwendungen erforderlich sind. Es ist für Layer-2-Netze konzipiert, die typischerweise innerhalb eines einzelnen Skids, eines Modules, einer Maschine oder einer Zelle auftreten. Verbindungen, die TSN verwenden, bieten den größten Anwendungsdeterminismus, aber der Betrieb über einen Layer-3-Switch oder -Router erfordert Erweiterungen wie die Verwendung von DetNet, welches derzeit von der IETF entwickelt wird.

Um den unterschiedlichen Kommunikationsbedürfnissen der Automatisierungsanwendungen gerecht zu werden, wurden drei optionale UAFX Bridge Component Facets definiert. Dabei sind TSN-fähige integrierte Bridges durch die UAFX Advanced & Full Bridge Component Facets gemäß der Tabelle repräsentiert.

Das UAFX Advanced Bridge Component Facet unterstützt als wesentliche Features die Zeitsynchronisation und Frame Preemption, aufbauend auf dem UAFX Base Bridge Component Facet. Das Full Bridge Component Facet baut auf dem UAFX Advanced Bridge Component Facet auf und unterstützt insbesondere die Erweiterungen für „Scheduled Traffic“ (EST) – auch bekannt unter den Bezeichnungen 802.1Qbv beziehungsweise Time Aware Shaper (TAS). Die Field Level Communications Initiative hat sich verpflichtet, das IEC/IEEE 60802 TSN Profile for Industrial Automation zu unterstützen, sobald es – voraussichtlich Ende 2024 – veröffentlicht ist. Es wird erwartet, dass alle Industrial-Ethernet-Varianten und IT- Geräte, die in einem industriellen Netzwerk mit TSN betrieben werden, mit dieser Spezifikation übereinstimmen, so dass ein Netzwerkmanagement-Tool jeder Anwendung die erforderlichen Netzwerk-Ressourcen zuweisen kann. IEC/IEEE 60802 Configuration Domains erfordern, dass alle Bridges – unabhängig davon, ob diese in einer Steuerung, einem Feldgerät oder in einem Infrastruktur-Switch integriert sind – mit der IEC/IEEE 60802 konform sind. Wenn eine Steuerung oder ein Feldgerät TSN-Features unterstützt und auch eine Bridge beinhaltet, muss sie/es entweder die UAFX Advanced Bridge Component Facet oder die UAFX Full Bridge Component Facet (gemäß Tabelle) implementieren, und diese Bridge muss IEC/IEEE 60802-konform sein. Die Mechanismen zur Verbindung mehrerer IEC/IEEE 60802 Configuration Domains in einem einzigen Netzwerk und die Erweiterung von Domains durch Netzwerk-Router müssen noch genormt werden. Sobald ein Netzwerk korrekt konfiguriert ist und genügend Ressourcen zugewiesen wurden, verhindert TSN Paketverluste aufgrund von Netzwerküberlast und gewährleistet zudem auch eine begrenzte Latenzzeit bei der Zustellung der Pakete beziehungsweise Daten an das Ziel.

OPC UA FX Endgeräte werden über OPC UA konfiguriert, online oder offline, wohingegen Netzwerkinfrastrukturgeräte über gängige und etablierte Netzwerkmanagementprotokolle konfiguriert werden. Daraus folgt, dass OPC UA keine bewährten Management-Protokolle für die Konfiguration von Netzwerkgeräten ersetzen soll. Grundsätzlich wird sowohl eine zentrale wie auch eine dezentrale Konfiguration unterstützt. Dabei sind die für die TSN-Konfiguration maßgeblichen Protokolle im TSN IA Profile IEC/IEEE 60802 definiert. Die Rolle von OPC UA und OPC UA UA FX im Kontext des Netzwerkmanagements besteht darin, relevante industrielle Anwendungsszenarien und entsprechende Konfigurationsworkflows für zeitkritische OPC UA- und OPC UA FX-Anwendungen bereitzustellen.

Ein Ausblick

Der Autor: Peter Lutz ist Director FLC bei der OPC Foundation.

© OPC Foundation

Das erste UAFX-Spezifikationsrelease definiert Erweiterungen des OPC UA-Frameworks, die eine Steuerung-zu-Steuerung-Kommunikation über eine gemeinsame Netzwerkinfrastruktur ermöglichen, um zyklische Prozessdaten auf Basis des herstellerunabhängigen Standards OPC UA (IEC 62541) auszutauschen. OPC UA etabliert sich damit als industrieller Interoperabilitätsstandard nicht nur für die vertikale Integration von der Leitebene bis zur Edge und in die Cloud, sondern auch als Kommunikationsstandard für den Austausch von Prozessdaten zwischen Steuerungen, unabhängig davon, welches Protokoll diese Steuerungen für die Kommunikation mit den angeschlossenen Feldgeräten, z.B. Servoantrieben, dezentralen I/Os, Sensoren, verwenden. In Phase 2 der Field Level Communications Initiative, die im Januar 2024 gestartet ist und auf eine Dauer von vier Jahren ausgelegt ist, werden die für den Anwendungsfall Controller-to-Controller (C2C) entwickelten Konzepte für die Anwendungsfälle Controller-to-Device (C2D) und Device-to-Device (D2D) erweitert. Dazu gehören geräte- und anwendungsspezifische Informationsmodelle, etwa für Motion Control, Instrumentierung und dezentrale E/A-Peripherie. Mit OPC UA steht dann ein einheitlicher Kommunikationsstandard zur Verfügung, der vollständig über alle Ebenen skaliert, vom Feld bis in die Cloud, sowohl vertikal als auch horizontal. Ein entscheidender Erfolgsfaktor ist dabei, dass OPC UA von allen großen Automatisierungsanbietern der Welt unterstützt wird, so dass Anwender in Zukunft frei entscheiden können, welche Systeme und Komponenten sie in ihren Produktionsanlagen und Fabriken einsetzen.