- Anzeige -
Erste Ergebnisse der FLC-Initiative

Mit OPC UA bis ins Feld

01.10.2020 Die Entwicklung zur Verwendung der OPC-Technologie in der Feldebene startete schon mit der TSN-Standardisierung (Time-Sensitive Networking). Viele Single- und Multivendor-Demonstratoren zeigten früh, welche Möglichkeiten die TSN-Technologie in puncto 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 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 aber auch auf der Applikationsebene eine gemeinsame Sprache zu sprechen, wurden die beiden Technologien TSN und OPC UA Pub/Sub (Publisher/Subscriber) miteinander kombiniert.

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.

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. (Bild: Funtap@shutterstock.com)

Hierzu 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 26 Unternehmen aktiv. Sie haben sich verpflichtet, die FLC-Initiative aktiv zu unterstützen, damit auf Basis von OPC UA und TSN ein umfassender FLC-Kommunikationsstandard für die Automatisierungstechnik entwickelt wird. Die 26 Unternehmen geben die Richtung vor, wobei die eigentliche Spezifikationsarbeit in den Arbeitsgruppen offen für jedes Mitglied der OPC Foundation ist. Nach fast anderthalb Jahren werden jetzt die ersten Ergebnisse sichtbar.

Steuerung-zu-Steuerung-Kommunikation

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

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. Bild: Phoenix Contact

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 abgedeckt 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 1). Im Rahmen der initialen Arbeiten wurden Anwendungsszenarien adressiert, in denen beide Steuerungen aufeinander abgestimmt beidseitig konfiguriert werden. Die IP-Adressen sind bereits vergeben und eine Parametrierung des Kommunikationspartners ist nicht notwendig. Neben der Online-Kommunikation wurden ebenfalls Mechanismen für die Offline-Engineering-Phase definiert. Darüber hinaus soll die Steuerungen Standard- und Safety-Daten abgesichert übertragen. Allein dieser Schritt bietet einen erheblichen Mehrwert gegenüber aktuellen Lösungsansätzen.

Offline-Engineering mit FLC

Heutige Gerätebeschreibungs-Lösungen 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 Datei kann nur Typinformationen beinhalten (Product Descriptor), lässt sich allerdings auch um Instanzinformationen erweitern. Bei diesem Vorgang wird die Datei automatisch zum instanziierten Solution Descriptor. 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 Programmiersprache AML (Automation Markup Language), die FLC-spezifische ebenso wie weitere Informationen in einem Paket zusammenfasst.

Initiierung der Kommunikation durch den Datenempfänger

Automation Component B liefert sicherheitsgerichtete Daten über einen Black Channel zwischen zwei Functional Entities (FE) an Automation Component A. Bild: Phoenix Contact

Automation Component B liefert sicherheitsgerichtete Daten über einen Black Channel zwischen zwei Functional Entities (FE) an Automation Component A. Bild: Phoenix Contact

Beim Verbindungsaufbau hat die FLC-Initiative im ersten Schritt ein vereinfachtes Modell favorisiert. Hier initiiert der Datenempfänger den Verbindungsaufbau und der Sender überträgt anschließend gemäß der Anforderung des Empfängers die Daten zyklisch 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 die Weiterleitung 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 die sicherheitsgerichtete Kontrolle auf Timeouts oder CRC- und Adressfehler. Beliebige Safety-Informationen können so – auch 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 unter anderem auf Pub-/Sub-Mechanismen umgestellt werden (Bild 2).

Trennung zwischen Asset und Funktion

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. Bild: Phoenix Contact

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. Bild: Phoenix Contact

Das FLC-Gerätemodell der Kommunikationsteilnehmer wurde ebenfalls neu aufgesetzt. Die Teilnehmer 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 solche Einheit 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 3).

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 folglich zwischen Functional Entities, welche die bestehenden Pub-/Sub-Mechanismen der OPC-Spezifikation nutzen. Verbindungen zu einem Teilnehmer werden in einer Connector-Group verwaltet, die wiederum ein oder mehrere Datasets umfasst. Auf diese Weise lassen sich unterschiedliche Daten, Update-Raten und Kommunikationsteilnehmer über ein Modell abbilden. Gleichzeitig wird aktuell viel Augenmerk auf einen sicheren mehrstufigen Verbindungsaufbau gelegt. Sowohl das Asset als auch die Functional Entity lässt sich auf Kompatibilität prüfen, es gibt eine eindeutige Parametrierungsphase und danach kann in den zyklischen Datenaustausch umgeschaltet werden. Dazu ist bei beiden Kommunikationsteilnehmern eine entsprechende Statusmaschine definiert worden.

Erarbeitung funktionsspezifischer Integrationsmodelle

Mit dem ersten angekündigten Schritt haben die Mitglieder der FLC-Initiative einen reduzierten Funktionsumfang festgelegt, der für die sichere Übertragung von Standard- und Safety-Daten zwischen zwei Steuerungen ausreicht. Im zweiten Schritt erfolgt eine Beschreibung der fehlenden Funktionalitäten, die für die Datenübertragung 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 für Motion-Applikationen erarbeiten.

Das Thema TSN wird hierbei immer parallel erörtert. Es basiert auf den Mechanismen, die bereits länger in einer OPC Foundation-Arbeitsgruppe zur TSN-Integration in das Pub-/Sub-Modell definiert werden. Ob letztendlich TSN mit seinen Zeitgarantien in einem konvergenten Netzwerk mit zahlreichen verschiedenen Kommunikationssystemen eingesetzt wird, hängt von 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.

Dipl.-Ing. Robert Wilmes, System Management PLCnext, Phoenix Contact Electronics GmbH

Über den Autor

Dipl.-Ing. Robert Wilmes, System Management PLCnext, Phoenix Contact Electronics GmbH

[caption id="attachment_108836" align="alignnone" width="150"]Dipl.-Ing. Robert Wilmes, System Management PLCnext, Phoenix Contact Electronics GmbH Dipl.-Ing. Robert Wilmes, System Management PLCnext, Phoenix Contact Electronics GmbH[/caption]

Loader-Icon