Aufmacher KUKA_robots

(Bild: Kuka)

Für viele Aufgaben im Kontext von Digitalisierung werden spezialisierte Werkzeuge und Technologien entwickelt und eingesetzt, um spezifische Anforderungen abzudecken. Das ist auch im Bereich der Industrieautomatisierung der Fall, wo für die Sensordatenerfassung, die Echtzeitsteuerung von Maschinen und die Abarbeitung von zyklischen Regelschleifen sehr genaue Anforderungen an Zeitabläufe und Latenzen existieren, die unter allen Betriebsbedingungen garantiert bleiben müssen.

Je nach Anwendungsfall reichen diese von weniger als 100 Mikrosekunden (Motion Control) bis zu hunderten Millisekunden (Prozesssteuerung). So sind anwendungs- und anbieterspezifische Lösungen für Software und Netzwerkprotokolle entstanden, die im Bedarfsfall unter Berücksichtigung gewisser Einschränkungen und Trade-Offs optimiert wurden, beispielsweise im Bereich von Kosten versus Zuverlässigkeit, Einfachheit von Installation und Inbetriebnahme versus Flexibilität, oder Diagnose von Problemen versus Erweiterbarkeit eines bestehenden Systems.

Proprietäre Systeme stoßen an ihre Grenzen

Bild 1: Die durch spezialisierte Lösungen entstandene Architektur industrieller Produktionsanlagen macht Gateways für den Daten- und eventuell auch Kontrollfluss zwischen einzelnen Schichten notwendig.

Bild 1: Die durch spezialisierte Lösungen entstandene Architektur industrieller Produktionsanlagen macht Gateways für den Daten- und eventuell auch Kontrollfluss zwischen einzelnen Schichten notwendig. TTTech

Um diese Optimierungen weiterzutreiben, war Kompatibilität mit allgemeingültigen Standards im Bereich von Netzwerken und Interoperabilität von Komponenten unterschiedlicher Hersteller nicht von primärer Bedeutung. Da große Systemintegratoren entweder auch Komponentenhersteller waren oder aufgrund ihrer Marktbedeutung andere Unternehmen zur Unterstützung ihrer optimierten Lösung bewegten, konnten sich proprietäre Ökosysteme entwickeln. Darin agiert eine Vielzahl von Herstellern und Komponentenzulieferern, die aber jeweils zueinander nicht, oder nur über aufwendige Übersetzungsmechanismen und Gateways, anschlussfähig waren.

Durch diese Spezialisierung von Technologien entstand in der Steuer- und Kommunikationsinfrastruktur von industriellen Produktionsanlagen zunehmend eine üblicherweise als „Pyramidenstruktur“ dargestellte Architektur (Bild 1). Die unterste Schicht repräsentiert die IO-Elemente direkt am physischen Produktionsvorgang, die nächsthöhere Schicht zumeist die Steuer- und Kontrolllogik (PLCs, SPS,…), darüber befinden sich Schichten für Produktionssteuerung und Diagnose sowie Anbindung an Verwaltungssysteme wie ERP bis hin zur Cloud.

Die höheren Schichten sind die Domäne der IT-Abteilungen, in der IT-übliche Technologien, Mechanismen und Standards genutzt werden, während in den untersten Schichten meist branchen- oder herstellerspezifische Technologien zum Einsatz kommen. Daher gibt es in dieser Automatisierungspyramide ein oder mehrere „Gateways“, die notwendig sind, um Daten- und eventuell auch Kontrollfluss zwischen den Schichten zu gewährleisten.

Solange einzelne Maschinen für die Automatisierung eingesetzt und dauerhaft vernetzt wurden, war dieser Zustand akzeptabel. Durch die steigenden Anforderungen an flexible Produktionsabläufe, geringere Downtimes im Fall von Linienumstellungen und nicht zuletzt die Notwendigkeit, systemübergreifend Daten für die „Internet of Things“-Anbindung verfügbar zu machen, sieht nun eine zunehmende Zahl von Unternehmen offene Standards als essenziell an. Allerdings müssen diese Standards einerseits die funktionalen Eigenschaften der Steuerungswelt weiterhin unterstützen, andererseits auch die Anforderungen an Offenheit, Flexibilität und Sicherheit der an die Produktionswelt heranrückenden Domäne von Data Centers und Cloud-Infrastruktur erfüllen.

TSN macht Ethernet echtzeitfähig

Bild 2: Mit den als Time-Sensitive Networking bezeichneten Standards wird es möglich, Echtzeitverhalten und Zuverlässigkeit in Standard-Ethernet auch für kritische Anwendungen ausreichend darstellen zu können.

Bild 2: Mit den als Time-Sensitive Networking bezeichneten Standards wird es möglich, Echtzeitverhalten und Zuverlässigkeit in Standard-Ethernet auch für kritische Anwendungen ausreichend darstellen zu können. TTTech

Neben verschiedenen sehr kostengünstigen Feldbussen hat sich Ethernet schon vor über einem Jahrzehnt auch in der Industrieautomatisierung als Layer-1-Technologie mit gutem Preis-Performance-Verhältnis etabliert. Weil aber unterschiedliche Methoden für garantiertes Echtzeitverhalten entwickelt und auf Ethernet realisiert wurden, war meistens schon auf Layer 2 dieser Netzwerke keine Kompatibilität mehr möglich. „Ethernet“ wurde hier also nicht in der üblichen Bedeutung verwendet, sondern nur der physische Layer mit 10, 100 oder auch 1000 Megabit pro Sekunde.

In anderen Industrien, speziell in der professionellen Audio-Video-Übertragung und -verarbeitung, wurde daher an echtzeitfähigen Erweiterungen von Switched Ethernet gearbeitet. Diese Erweiterungen sind auch als Teil der IEEE 802-Ethernet-Standards unter dem Namen „AVB“ (Audio Video Bridging) bekannt und bieten für echtzeitsensitive Audio- und Videoapplikationen streambasierte Quality-of-Service-Mechanismen für Ethernet-Netzwerke an, um Synchronisation (beispielsweise von Lautsprechern) und Latenz-Obergrenzen (etwa von Audio-Daten) zu erreichen.

Allerdings waren die solcherart zu erreichenden Echtzeiteigenschaften von Ethernet für den Einsatz in manchen kritischen Applikationen noch immer nicht ausreichend. Dies gilt speziell für die Datenverarbeitung in Pkw-Bordnetzen und auch in der Automatisierung. AVB stellt zwar Bandbreite für dedizierte Echtzeit-Datenstreams zur Verfügung, kann aber keine Garantien für das Echtzeitverhalten auch unter hoher Last und in gewissen Fehlerfällen geben. Manche systembedingten Einschränkungen von AVB, wie beispielsweise maximal sieben Switches in Serie für latenzkritische Daten, sind für größere Netzwerke in der Automatisierung nicht akzeptabel.

Mit Time-Sensitve Networking (TSN) steht nun eine zweite Generation von Mechanismen in IEEE-802-Ethernet zur Verfügung, um das Echtzeitverhalten und seine Zuverlässigkeit in Standard-Ethernet auch für kritische Anwendungen ausreichend darstellen zu können. Einige der Mechanismen von TSN sind Erweiterungen oder Verallgemeinerungen von bereits in anderen (industriespezifischen) Ethernet-Standards verfügbaren Funktionen, wie beispielsweise redundante Übertragung von Ethernet-Paketen über unterschiedliche Netzwerk-Pfade nach 802.1CB.  Andere Mechanismen wie unter anderem Frame Preemption nach 802.1Qbu und 802.3br sind völlig neu und ermöglichen noch mehr Echtzeitfähigkeit von Ethernet. Besonders hervorzuheben ist der TSN-Standard IEEE 802.1Qbv, mit dem Quality of Service für zeitsynchrone Kommunikation in Ethernet beschrieben wird und damit ein Mechanismus, der hochpräzise Echtzeitdatenströme zusammen mit ganz gewöhnlichem, „ad hoc“ Ethernet-Verkehr in einem einzigen Netzwerk erlaubt (Bild 2).

Damit lässt sich eine Vereinheitlichung von Ethernet-Netzwerken von der untersten „Pyramidenschicht“ bis hinauf zur Cloud-Anbindung realisieren, ohne Gateways und andere Übersetzungselemente zu benötigen. Da es sich bei TSN um eine voll kompatible Erweiterung von Ethernet handelt, sind bestehende Standard-Ethernet-Geräte grundsätzlich in einem TSN-Netzwerk anschlussfähig, mit gewissen Einschränkungen bezüglich Echtzeit-Performance.

Einheitliches Datenmodell OPC UA

Effizienter Informationsaustausch über Ländergrenzen hinweg setzt bei Menschen eine gemeinsame Sprache voraus. Müsste man ständig Dolmetscher dazwischenschalten, ginge Zeit und auch Inhalte verloren. Das gilt auch für Maschinen: Um Daten zwischen Robotern, Verpackungs- oder Abfüllanlagen auszutauschen, ist eine allgemein verständliche Repräsentation von generischen Methoden für Discovery („Ich bin da und betriebsbereit“), Security („Um mit mir zu sprechen, musst du dich zuerst authentifizieren“), und andere Klassen von Funktionalität erforderlich. Darüber hinaus sollen auch geräte- oder anwendungsspezifische Funktionen und Parameter („Ich kann maximal zwei Flaschen pro Sekunde etikettieren und habe derzeit noch acht Flaschen in der Warteschlange“) über eine generische und hinreichend flexible Repräsentationsschicht darstellbar sein.

Die OPC Foundation standardisiert seit 1996 solche Mechanismen, basierend auf Technologien, die Microsoft bereits in den 1980ern entwickelt hat. 2006 wurden diese in ein einheitliches Datenmodell (UA, Unified Architecture) überführt, seither steht mit OPC UA eine herstellerunabhängige, standardisierte Plattform zur Verfügung, die in mehreren Bereichen laufend an Unterstützung gewinnt, ganz besonders auch in der Industrieautomatisierung. Trotz der Ursprünge in der Microsoft-Welt wird OPC UA Software von verschiedenen Anbietern auf unterschiedlichen Plattformen von der Cloud bis hin zu PLCs und Embedded Systemen verfügbar gemacht.

OPC UA basiert grundsätzlich auf einem Client-Server-Modell, wurde aber um eine Publish/Subscribe-Architektur erweitert. Letztere bietet die Möglichkeit, periodischen Datenaustausch zwischen OPC-UA-Knoten mit einer wohldefinierten Zykluszeit durchzuführen. Damit sind Echtzeit-Anwendungen mit Steuerungscharakter auf den unteren Schichten der „Pyramide“, beispielsweise eine enge Kopplung von Verarbeitungszyklen auf der Machine-to-Machine-Ebene auf Basis eines standardisierten und herstellerunabhängigen Datenmodells möglich.

Die Verknüpfung von OPC UA und TSN

Bild 3: Mit der Kombination aus OPC UA und TSN können IoT-Anforderungen und ausreichende Bandbreite bei garantierter Echtzeitfähigkeit für alle Anwendungen und Datenverbindungen vom Sensor bis in die Cloud gewährleistet werden.

Bild 3: Mit der Kombination aus OPC UA und TSN können IoT-Anforderungen und ausreichende Bandbreite bei garantierter Echtzeitfähigkeit für alle Anwendungen und Datenverbindungen vom Sensor bis in die Cloud gewährleistet werden. TTTech

Um nun eine einheitliche Plattform für Internet-of-Things-Datenzugriffe vom Sensor bis zur Cloud zu schaffen, müssen Netzwerk und Datenzugriffsmodell die Anforderungen so abdecken, dass in einer Plattform letztendlich nur ein System beschrieben, konfiguriert und betrieben wird. Es ist also naheliegend, die Performance- und Echtzeitanforderungen der Applikationen für OPC UA und die daraus folgenden Latenzanforderungen für das Netzwerk in einem gesamtheitlichen System zu realisieren. Mit anderen Worten, OPC UA und TSN sind zwei separate, aber sinnvollerweise eng integrierbare Schichten für Datenzugriff und Datenkommunikation, mit denen die Kombination aus bislang schwer in Einklang zu bringenden Anforderungen möglich wird: garantierte Echtzeit in Anwesenheit flexibler Zugriffe, beispielsweise für Operator-Zugriffe und IoT-Anbindung, und volle Interoperabilität trotz Herstellerunabhängigkeit dank offener Standards (Bild 3).

Von erheblicher Bedeutung ist auch die breite Unterstützung in der Automatisierungsindustrie. Ende 2016 kündigten im Rahmen einer viel beachteten Pressekonferenz auf der Messe SPS IPC Drives die Unternehmen ABB, Bosch Rexroth, B&R, Cisco, General Electric, Kuka, National Instruments, Parker Hannifin, Schneider Electric, SEW-Eurodrive und TTTech ihre Unterstützung für diese Kombination aus Standards als künftige bevorzugte Lösung an.

Erwarteter Nutzen und Schlussfolgerung

Wenn die Verbreitung von OPC UA, das als herstellerunabhängiger und von Betriebssystemen unabhängiger Standard und Software-Stack verfügbar ist, sich in der Industrieautomatisierung fortsetzt, liegt es nahe, nicht nur die IoT-Cloud-Anbindung von kompletten Systemen beziehungsweise Maschinen über dieses Datenmodell abzubilden. Vielmehr ist darüber hinaus auch der Zugriff auf einzelne Datenelemente auf der untersten Ebene, also Sensoren und Aktuatoren, über diese Plattform zu ermöglichen.

Der Zugriff auf einzelne aktuelle Datenelemente innerhalb eines laufenden Steuerungsprozessystems bietet neue Möglichkeiten bei vorausschauender Diagnose und Maintenance sowie bei der Optimierung von Produktionsprozessen. Die Big-Data-Analyse lässt sich durch diese Zugriffsmethoden dynamisch um genau jene Datenelemente erweitern, die für bestimmte Analysen und Optimierungsaufgaben aus dem laufenden Prozess heraus benötigt werden. Das ist besonders in komplexen Systemen mit vielen Datenquellen hilfreich, da dort eine kontinuierliche, vollständige Übertragung aller potenziell relevanten Sensordaten in die Cloud mit herkömmlichen Methoden nicht zu bewältigen wäre. Daher muss an der Maschinengrenze oder „Edge“ die Möglichkeit für möglichst herstellerunabhängige Logging/Historian-, Filter- und Alarmierungsfunktionen im Fall von ungewöhnlichen Abweichungen von Normwerten gegeben sein. All das ist mit der Verbindung von OPC UA und TSN realisierbar.

Aber auch die für Industrie 4.0 benötigte Flexibilität in der Vernetzung zwischen Maschinen ist damit umsetzbar: So kann beispielsweise eine Maschine in einer Produktionslinie in Echtzeit auf Informationen über das Werkstück in dem direkt davor liegenden Linienelement zugreifen und sich so in Hinblick auf den nächsten auszuführenden Arbeitsschritt vorausschauend kalibrieren („Wenn ich weiß, wie das Stück beschaffen ist, das du gerade bearbeitest, kann ich meinen Greifer bereits entsprechend positionieren“).

Obwohl bestehende Lösungen für industrielle Netzwerkkommunikation die Anforderungen in herkömmlichen Systemen bestens abdecken, gibt es für die breite Durchsetzung von OPC UA und TSN stichhaltige Gründe: Offenheit und Standardisierung, die für das Internet of Things notwendig ist, Bandbreite und Übertragungsgeschwindigkeit von Gigabit-Ethernet, und garantierte Echtzeitfähigkeit für alle Anwendungen und Datenverbindungen vom Sensor bis in die Cloud.

Eck-DATEN

OPC UA und TSN sind zwei separate, aber sinnvollerweise eng integrierbare Schichten für Datenzugriff und Datenkommunikation, mit denen die Kombination aus bislang schwer in Einklang zu bringenden Anforderungen möglich wird: garantierte Echtzeit in Anwesenheit flexibler Zugriffe, beispielsweise für Operator-Zugriffe und IoT-Anbindung, sowie volle Interoperabilität trotz Herstellerunabhängigkeit dank offener Standards. Hinzu kommen die Bandbreite und Übertragungsgeschwindigkeit von Gigabit-Ethernet, sodass es für die breite Durchsetzung von OPC UA und TSN stichhaltige Gründe gibt.

Georg Stöger

(Bild: TTTech)
Director Technical Presales, Training & Support bei TTTech

(ku)

Sie möchten gerne weiterlesen?

Unternehmen

TTTech Auto AG

Operngasse 17-21
1040 Wien
Austria