Das aktuelle OPC UA Framework deckt Anwendungsfälle bereits funktional von der Cloud bis zum Sensor ab. Nur war mit Standard-Ethernet der Determinismus heutiger Feldbuslösungen nicht gegeben. Mit der OPC UA-Erweiterung auf die Publisher/Subscriber-Technologie und dem Aufkommen von TSN änderten sich die Randbedingungen. Viele Single- und Multivendor-Demonstratoren zeigten früh, welche Möglichkeiten bis hin zu Motion Control die TSN-Technologie in punkto Synchronität und Echtzeit eröffnet.
Doch wenn jedes Unternehmen respektive jede Nutzerorganisation das jeweils bestehende System auf TSN hebt, bringt dies keinen Vorteil für die Automatisierungswelt. Vor diesem Hintergrund wurde zusätzlich auf der IEEE-/IEC-Normungsebene zeitig ein TSN-Standardisierungsprojekt (IEC/IEEE 60802-IA) in Angriff genommen, das auf eine Vereinheitlichung des TSN-Einsatzes in der industriellen Automatisierungstechnik abzielt. Mit der Fertigstellung eines einheitlichen TSN-Profils sollen sich Automatisierungs- und IT-Protokolle ein TSN-Netzwerk mit entsprechenden Garantien teilen können. Die vorhandene Kommunikation darf dabei durch die zusätzliche neue nicht gestört werden – das „Converged Network“.
Um in diesem „Converged Network“ langfristig lediglich eine Sprache zu sprechen, nämlich OPC UA, gründeten 2018 Automatisierungsanbieter, Technologie-Provider sowie Komponenten- und Switch-Hersteller aus der Fabrik- und Prozessautomation auf der Messe SPS in Nürnberg innerhalb der Nutzerorganisation OPC Foundation die Initiative Field Level Communication (FLC). Heute sind hier 27 Unternehmen aktiv. Sie haben sich verpflichtet, die FLC-Initiative aktiv zu unterstützen, damit auf Basis von OPC UA und TSN ein umfassender Kommunikationsstandard für die Automatisierungstechnik entwickelt wird. Die 27 Unternehmen geben die Richtung vor, wobei die eigentliche Spezifikationsarbeit in den Arbeitsgruppen offen für jedes Mitglied der OPC Foundation ist. Nach knapp über zwei Jahren werden jetzt die ersten Spezifikationen als Release-Kandidaten veröffentlicht.
Sukzessive Umsetzung
Im ersten Schritt wurde die Controller-zu-Controller-Kommunikation (C2C) für Standard- und Safety-Daten definiert, um diese dann auf die Controller-zu-Device- (C2D) und Device-zu-Device-Kommunikation (D2D) zu erweitern
Die Erarbeitung eines komplett neuen Ökosystems für die Automatisierung, mit dem sich die technologischen Entwicklungen der nächsten 20 Jahre ebenfalls umsetzen lassen, erweist sich als große Herausforderung. Bei der Spezifikation sollen die Anforderungen von der Prozesstechnik bis zu synchronen Motion-Control-Applikationen erfüllt werden. Deshalb haben sich die Mitglieder der FLC-Initiative zur Realisierung eines sukzessiven Konzepts entschieden. Der erste Schritt fokussiert sich auf den Datenaustausch von Steuerung zu Steuerung (Bild links). Im Rahmen der initialen Arbeiten wurden Anwendungsszenarien adressiert, in denen beide Steuerungen aufeinander abgestimmt beidseitig konfiguriert werden. Die IP-Adressen sind schon vergeben und eine Parametrierung des Kommunikationspartners ist nicht notwendig. Neben der Online-Übertragung wurden auch Mechanismen für die Offline-Engineering-Phase definiert. Darüber hinaus sollen die Steuerungen Standard- und Safety-Daten abgesichert weiterleiten. Allein dieser Schritt der Standardisierung der Steuerungs-Steuerungs-Kommunikation bietet bereits einen erheblichen Mehrwert gegenüber aktuellen Lösungsansätzen.
Erweiterbare Gerätebeschreibung
Heutige Gerätebeschreibungs-Lösungen aus dem Feldbusbereich beschäftigen sich mit der Integration eines Gerätetyps eines bestimmten Sensors oder Aktors in das Engineering eines Systemanbieters. Ist das Gerät einmal instanziiert, wird die Datei oftmals nicht mehr aktiv verwendet. Anders bei FLC: Die Gerätebeschreibung kann nur Typinformationen beinhalten, lässt sich allerdings um Instanzinformationen erweitern. Wenn bekannt, lassen sich im Vorfeld also ebenfalls Adressinformationen oder spezifische Konfigurationen festlegen, bevor sie dann in das andere Engineering-System eingebunden werden. Damit wird die Gerätebeschreibungsdatei automatisch zum digitalen Zwilling des Kommunikationspartners. Jeder Anwender kann die Informationen hinzufügen, die er im Rahmen seiner Engineering-Aufgaben schon kennt. Die Datei wächst folglich inhaltlich mit dem Projektfortschritt. Gelöst wird das über einen Ansatz auf Basis der Beschreibungssprache AML (Automation Markup Language), die FLC-spezifische ebenso wie weitere Informationen in einem Paket zusammenfasst.
Erweiterbarer Verbindungsaufbau
Automation Component B liefert sicherheitsgerichtete Daten über einen Black Channel zwischen zwei Functional Entities (FE) an Automation Component A
Beim Verbindungsaufbau hat die FLC-Initiative ein einfaches Modell favorisiert. Dabei initiiert der Datenempfänger den Verbindungsaufbau und der Sender überträgt die Daten anschließend gemäß der Anforderung des Empfängers unidirektional in der entsprechenden Qualität und Zykluszeit. Hinter diesem Modell steckt der Gedanke, dass bei zwei Kommunikationsteilnehmern der Empfänger am besten weiß, wann seine Applikation die Daten benötigt. Soll ein bidirektionaler Datenaustausch aufgebaut werden, müssen somit beide Seiten die Datenübertragung anstoßen können. Dieser Ansatz wird derart spezifiziert, dass er auch auf bidirektionale Kommunikationsmodelle erweitert werden kann.
Ein ähnliches Kommunikationsmodell ist für den Austausch sicherheitsgerichteter Daten bei OPC UA Safety getroffen worden: Der Safety-Consumer startet zyklisch eine Anfrage an den Safety-Provider, die Daten an den Consumer zu schicken. Fragt der Consumer keine Daten an, reagiert der Provider nicht. Von daher gestaltet sich das Protokoll auf der Provider-Seite einfach, denn es sind keine Uhrzeit und Kontrollmechanismen erforderlich. Auf der Consumer-Seite erfolgt danach die sicherheitsgerichtete Kontrolle auf Timeouts oder CRC- und Adressfehler. Beliebige Safety-Informationen können so – selbst in dynamischen veränderten Applikationsszenarien – sicher übertragen werden. Die Safety-Spezifikation über OPC UA über Client-Server ist bereits abgeschlossen und wird jetzt für die FLC-Integration u.a. auf Pub-/Sub-Mechanismen umgestellt werden (Bild oben).
Flexible Kombination von Funktionalitäten
Die Trennung von Hardware und Funktion im FLC- Informationsmodell ermöglicht die flexible Zusammenstellung von unterschiedlichen Funktionen in einer Automation Component auf Basis von Pub/Sub-Datasets
Das FLC-Gerätemodell der Kommunikationsteilnehmer wurde ebenfalls neu aufgesetzt. Die Kommunikationsteilnehmer heißen nun Automation Components (AC). Egal ob Steuerung oder Sensor: Alle Geräte sind in ihrer Grundstruktur identisch aufgebaut. Dabei ist strikt zwischen dem Asset und der Funktion getrennt worden. Durch diese Trennung wird ermöglicht, dass Funktionalitäten zukünftig hardwareunabhängig betrachtet und beispielsweise einfach in neuen Produkten kombiniert werden können. Eine Gerätefunktionalität wird als Functional Entity (FE) beschrieben. Die standardisierte FE weiß nicht, ob sie in einem modularen oder festen Aufbau, in einer Steuerung oder auf einem Antrieb läuft. Das Asset beinhaltet dann sämtliche hardwarenahen Informationen, die Gerätestruktur, Ethernet-Schnittstellen sowie die Firmware-Versionen für das Gerät oder für Teile des Geräts (Bild rechts).
Bei den Security-Mechanismen wird komplett auf die schon in OPC UA definierten Mechanismen gesetzt. Die wenigen Aspekte, die noch nicht in der OPC-Security umgesetzt sind, müssen Teil der OPC-Security-Spezifikation werden.
Der eigentliche Verbindungsaufbau – die FLC-Connection – zwischen den Geräten geschieht also zwischen Functional Entities, welche die bestehenden Pub-/Sub-Mechanismen der OPC-Spezifikation nutzen. Gleichzeitig wird aktuell viel Augenmerk auf einen sicheren mehrstufigen Verbindungsaufbau gelegt. Sowohl das Asset ebenso wie die Functional Entity lässt sich auf Kompatibilität prüfen. Es gibt eine eindeutige Parametrierungsphase und erst danach kann in den zyklischen Datenaustausch umgeschaltet werden. Dazu ist bei beiden Kommunikationsteilnehmern eine entsprechende Statusmaschine festgelegt worden.
Funktionsspezifische Informationsmodelle
Mit dem ersten Schritt haben die Mitglieder der FLC-Initiative einen reduzierten Funktionsumfang definiert, der für die sichere Übertragung von Standard- und Safety-Daten zwischen zwei Steuerungen ausreicht. Ein erster Release Candidate wurde im November 2020 veröffentlicht. Er dient der Umsetzung von Prototypen, der Validierung der Spezifikation und der Entwicklung von Tests, die Bestandteil des CTT werden. Im zweiten Schritt erfolgt eine Beschreibung der fehlenden Funktionalitäten, die für die Kommunikation zwischen Controller und Device notwendig sind, etwa Adressierung, Parametrierung und erweiterte Diagnose. Außerdem entstehen erste Arbeitsgruppen, die auf der Grundlage dieses Modells funktionsspezifische Informationsmodelle beispielsweise seit Mitte 2020 für Motion-Applikationen erarbeiten.
Der Auslöser für diese Entwicklung, nämlich TSN, wurde in der Zwischenzeit über OPC-Arbeitsgruppen als optionale Funktion in die PubSub-Spezifikation integriert. Ob letztendlich TSN mit seinen Zeitgarantien eingesetzt wird, hängt von den Determinismus-Anforderungen der jeweiligen Anwendung ab. Werden bei einer unbekannten Netzlast und kurzen Zykluszeiten geringe und garantierte Latenzzeiten für die Applikation benötigt, muss der Datenaustausch im Netzwerk auf TSN-Streams umgestellt werden.
Die Aktivitäten der FLC-Initiative im Hinblick auf die Feldtauglichkeit von OPC UA laufen somit auf Hochtouren und zeigen erste Ergebnisse. In der feldnahen Kommunikation wird sich ein großer Schritt mit viel Innovationspotenzial eröffnen, wenn dann die für die OT entwickelten Geräte zukünftig mit OPC UA eine Sprache sprechen und gleichzeitig mit TSN auf einer echtzeitfähigen Ethernet-Hardware basieren.
Autor: Dipl.-Ing. Robert Wilmes, System Management PLCnext, Phoenix Contact Electronics GmbH, Bad Pyrmont
Textquelle: Phoenix Contact GmbH & Co. KG
Bildquelle: Aufmacher Funtap – shutterstock.com, Grafiken Phoenix Contact
