Das "Echtzeit"-OPC-UA OPC UA over TSN: Architektur und Anwendung

Autor / Redakteur: Heinrich Munz und Georg Stöger / Jürgen Schreier

OPC UA kommt wegen seiner Herstellerunabhängigkeit und Datensicherheit in vielen industriellen Anwendungen zum Einsatz. Erweitert um das Publish/Subscribe-Modell und den Ethernet-Standard Time Sensitive Networking (TSN) wird OPC UA zum echtzeitfähigen Kommunikationsstandard.

Firma zum Thema

Jedes Gerät kann als Funktionsserver aufgefasst werden, das seine Dienste der es ansteuernden Instanz «über» ihn – der Cloud, der Edge – oder anderen Automatisierungsgeräten zur Verfügung stellt. Ein Roboter wird dadurch beispielsweise zum «Bewegungsserver», der nicht mehr wie heute für sich programmiert wird, sondern seine Bewegungsbefehle zentral aus der Edge bzw. Cloud als Service-Aufrufe erhält.
Jedes Gerät kann als Funktionsserver aufgefasst werden, das seine Dienste der es ansteuernden Instanz «über» ihn – der Cloud, der Edge – oder anderen Automatisierungsgeräten zur Verfügung stellt. Ein Roboter wird dadurch beispielsweise zum «Bewegungsserver», der nicht mehr wie heute für sich programmiert wird, sondern seine Bewegungsbefehle zentral aus der Edge bzw. Cloud als Service-Aufrufe erhält.
(Bild: gemeinfrei / Pixabay )

Schon seit Jahren entwickeln Hersteller von Steuerungen und Automatisierungslösungen in der Industrie innovative Lösungen, um den Nutzern ihrer Systeme aktuelle Betriebsdaten zur Verfügung zu stellen. Das Internet der Dinge ist also längst in der Industrieautomatisierung angekommen und sollte als Grundlage für die Flexibilisierung der Produktion in der Industrie-4.0-Welt dienen.

Bildergalerie
Bildergalerie mit 8 Bildern

Im Jahr 2015 stellte die Arbeitsgruppe Referenzarchitektur und Standardisierung der Plattform Industrie 4.0 das Referenzmodell Architekturmodell Industrie 4.0 (RAMI 4.0) vor [01]. Dieses dient seither als einheitliche Architekturvorlage für Industrie-4.0-Anwendungen. Darin wird deutlich, dass bei der Auswahl einer gemeinsamen Informations- und Kommunikationsschicht für Industrie 4.0 nur der OPC-UA-Standard [02] alle Anforderungen erfüllen konnte und dessen Implementierung als mindeste Anforderung für Industrie-4.0-taugliche Geräte dient.

Durchgehend auf allen Ebenen der Industrie-Infrastruktur einsetzbar

OPC UA wurde unter anderem aufgrund seiner Schlüsselkompetenzen in den Bereichen Datensicherheit und Informationsmodellierung ausgewählt. Ein weiterer Faktor von OPC UA war die Möglichkeit, durchgehend auf allen Ebenen der Industrie-Infrastruktur einsetzbar zu sein – von Cloud-basierten Diensten über Enterprise-Resource-Planning- Systeme (ERP) und Produktionsleitsysteme (Manufacturing Execution Systems, MES) bis hinab in die Feldebene.

Um das Ziel von offenen, standardbasierten und durchgängigen Industrie-4.0-Architekturen zu erreichen, sollen bisher durch Technologiebrüche abgekapselte Bereiche der Automatisierungspyramide in das einheitliche Kommunikationsmodell von OPC UA integriert werden. Dazu gehören beispielsweise Echtzeitsteuerung, Sicherheitsanwendungen und Cloud-Kommunikation.

Aus diesem Grund arbeitet eine Gruppe von Unternehmen in der OPC Foundation zusammen, um zwei zukünftige Standarderweiterungen zu kombinieren: das Publish/Subscribe-Modell der OPC Foundation und das Time Sensitive Networking-Ethernet (TSN), definiert in der Ethernet-Standardisierung IEEE 802.1 [03]. Durch diese Kombination können OPC-UA-Daten auf allen Infrastrukturebenen über reguläres Ethernet übertragen werden. Eine weitere Erweiterung wird zukünftig mittels AMQP erfolgen, um die Vorteile von OPC UA auch über mehrere Clouds hinweg nutzen zu können.

Zentralisierung vs. Dezentralisierung von Rechenleistung

Während der Trend der Zentralisierung in der Cloud für reine Privat- oder Geschäftssoftware, Plattformen und Infrastrukturen sicher sehr erfolgversprechend ist und viele Vorteile hat, macht ein anderer Trend eine gewisse Dezentralisierung wieder notwendig, nämlich das Internet der Dinge oder Internet of Things, IoT. Dabei werden nicht nur normale Computer zur elektronischen Datenverarbeitung an das Internet und verwandte Netzwerke angeschlossen, sondern Geräte jeglicher Art – meist aus dem täglichen Lebensumfeld der Menschen (Bild 1).

Diese Geräte werden entweder jedes einzelne selbst mit entsprechender Rechenleistung ausgestattet (z.B. ein autonom fahrendes Fahrzeug) oder für eine sinnvolle Ansammlung mehrerer Geräte wird ein so genanntes Edge Gateway bzw. Edge Controller installiert, um in der Nähe der Geräte die notwendigen Rechenaufgaben zu übernehmen. Beispiele für die heute vorhandenen Stellen, wo die aus Cloud-Sicht dezentralen Edge Gateways bzw. Edge Controller Einzug halten werden, sind die heimischen DSL- bzw. Kabel-Router zum Anschluss des Privathaushaltes an das Internet bzw. die so genannten Zellen-SPSen in heutigen Produktionseinrichtungen. Die Aufgaben der Edge werden uns weiter unten nochmals begegnen.

Bildergalerie
Bildergalerie mit 8 Bildern

Das große Aufholpotenzial, das die OT gegenüber der IT aufweist, hat allerdings auch einen großen Vorteil: Man kann sich die historischen Fehler der anderen Branche anschauen und braucht diese nicht zu wiederholen. Einer dieser – zugegeben damals unvermeidbaren – Fehler war, dass die IT es dem Markt überlassen hat, gemeinsame Standards für die so wichtigen Kommunikationstechnologien zu etablieren.

Der Feldbus - Benchmark für Inkompatibilität

Alle Hersteller haben dies eingesehen? Nein! Eine von beratungsresistenten Geräteherstellern besetzte Branche hört nicht auf, dieser Vernunft Widerstand zu leisten. Und das ist die Branche der Fertigungsindustrie. Wie in der IT vor ca. 20 bis 30 Jahren gibt es eine Vielzahl von zueinander völlig inkompatiblen Kommunikationstechnologien, hier «Feldbusse» genannt.

Automatisierungsgeräte-Hersteller sind gezwungen, für ein und dasselbe Gerät – z.B. einen Industrieroboter – bis zu 15 unterschiedliche Kommunikationstechnologien für das jeweilige Gerät vorzuhalten – und das bei immer völlig identischer und gleichbleibender Gerätefunktionalität. Den Gipfel der Ironie bildet der Standard IEC 61 158, in dem sage und schreibe 19 zueinander inkompatible Feldbusse «standardisiert» sind [04].

Der große Vorteil bei der Beibehaltung von OPC UA über alle Hierarchielevels hinweg ist der, dass die wertvollen Informationsmodelle zur semantischen Service- bzw. Selbstbeschreibung der Geräte über alle Levels sowohl in der Echtzeit als auch bis hinauf zur Connected World beispielsweise durch Clouds beibehalten werden können. Natürlich ist es utopisch anzunehmen, dass der einheitliche Standard OPC UA neben der Produktionsindustrie sich auch in allen anderen Bereichen des Internet der Dinge durchsetzen wird, obwohl es technisch sicher für viele andere Bereiche passen würde.

Jede Domäne wird hierbei früher oder später ihre eigenen Standards herausarbeiten und etablieren. Die private Hausautomatisierung z.B. hat sich bisher nur deshalb noch nicht durchsetzen können, weil die einschlägigen Hersteller sich ebenfalls nicht auf einen gemeinsamen Standard einigen können, wie Jalousien, Beleuchtung, Klimaanlagen und Heizungen usw. herstellerübergreifend angesteuert werden sollen. Das Problem ist nicht, dass Standards fehlen, das Problem ist, dass es zu viele Standards gibt und man sich nicht auf einen gemeinsamen einigen kann, ja es noch nicht einmal versucht.

Service-orientierte Architektur im Internet der Dinge

Bevor wir uns der für Industrie 4.0 bevorzugten Service-orientierten Architektur (SoA) zuwenden, wollen wir zuerst einen Blick auf die für das Internet der Dinge üblichen Architekturen werfen (Bild 2). Hierfür haben sich ebenfalls bereits eine Referenzarchitektur und eine Vielzahl unterschiedlicher Implementierungen durchgesetzt.

Der als erster zu beschreibende Leistungsbereich ist die «Connectivity». Hier stehen die Assets, also die Geräte, Maschinen und Anlagen sowie deren Communication, im Vordergrund. Sie produzieren Daten und sind zu steuern. Die unmittelbare zweite Verarbeitung danach wird «Edge» (Kante, Rand) genannt. Der Name rührt von der Tatsache her, dass hier an den Geräten das Internet-Netzwerk endet.

Bildergalerie
Bildergalerie mit 8 Bildern

Die Edge hat den Vorteil, sich räumlich sehr nah an den Geräten meist auf demselben geswitchten Ethernet-Netzwerk zu befinden. Dadurch werden durch die verwendeten Computer (Edge Controller) eng geschlossene Regelschleifen und sehr schnelle Reaktionen auf Ereignisse in den Dingen möglich, die echtzeitfähige Reaktionen erfordern. Was hierbei mit dem Begriff «echtzeitfähig» gemeint ist, werden wir weiter unten noch kennenlernen.

Ein weiterer Vorteil der Edge kommt bei sogenannten Brownfield-Anlagen als Datenkonzentrator und Kommunikator zur Cloud zum Tragen (Edge Gateways). Mit Brownfield bezeichnet man bereits bestehende, produzierende Anlagen, wohingegen mit Greenfield neu zu erstellende Anlagen gemeint sind, bei denen man auch mal neue Wege gehen kann.

So werden Brownfield-Anlagen Industrie-4.0-fit

Da Brownfield-Anlagen in erster Linie ungehindert weiter produzieren sollen, dürfen keinerlei Veränderungen an den an der Produktion beteiligten Geräten erfolgen, die die Produktion stören würden. Andererseits sind die Betreiber sehr wohl an Datenerfassung und -auswertung zur Optimierung ihrer bestehenden Produktionsprozesse interessiert. Abhilfe können die nachträglich minimalinvasiv installierbaren Edge Gateways schaffen, die Daten aus den Geräten über bereits vorhandene Schnittstellen erfassen und über das Internet an die entsprechenden Clouds weiterleiten.

Nach dem Bereich «Connectivity» folgt die eigentliche Cloud, hier als Leistungsbereich «Services » bezeichnet. Diese Dienste können sowohl On Premise, im öffentlichen Internet oder aber auch in einem privaten Netz im Internet installiert sein. Innerhalb dieses Bereiches gibt es eine Vielzahl von einzelnen Diensten, die sogenannten «Micro-Services», die die von den Assets stammenden Daten und Ereignisse vorverarbeiten, speichern, auswerten und weiterverwenden.

«On Premise» bedeutet hierbei die Installation und den Betrieb der Cloud im eigenen Rechenzentrum des Produzenten, sozusagen «gleich nebenan» neben dem eigenen Plant Floor auf dem gemeinsamen Firmengelände. Gründe, warum man die Cloud in eigenen Rechenzentren halten möchte, sind hauptsächlich die Angst vor Datendiebstahl, Spionage, Sabotage, Hackerangriffen zur Störung der Produktion usw.

Die Alternative zu On Premise ist es, die Cloud «irgendwo» im Internet betreiben zu lassen und nur die Dienste wie IaaS, PaaS und SaaS in Anspruch zu nehmen. Die Verantwortung für die Einrichtung und den störungsfreien Betrieb der Cloud übernehmen dabei einschlägige Anbieter.

Cloud-Services: Selber machen oder einkaufen?

Eine Mischform ist das bereits bestehende Angebot einiger Cloud-Anbieter, die Cloud-Server garantiert in einem ganz bestimmten Land und an einem dedizierten Ort zu betreiben, um den Datenschutzgesetzen des jeweiligen Landes zu unterliegen. Der bereits erkennbare Trend ist der, dass nach anfänglichen Bedenken mehr und mehr Firmen die Cloud nicht On Premise selbst betreiben wollen, sondern die Dienste der einschlägigen Anbieter in Anspruch nehmen werden.

Gründe sind der Aufwand, der mit dem Aufbau und Betrieb einer eigenen Cloud einhergehen; hinzu kommt die Schnelllebigkeit der Cloud-Technologien, die ein Mithalten mit dem Stand der Technik sehr aufwendig machen. Schließlich ist die Kernkompetenz von produzierenden Betrieben das Herstellen von Produkten und nicht die Einrichtung und der Betrieb von Cloud-Software.

Schließlich kommt der hier als «Applications» bezeichnete Bereich der Human Machine Interfaces (HMI) und der Anwendungen hinzu. Dieses ist der Bereich, auf dem Computerprogramme (Apps) auf die Daten, Ereignisse, Dienste usw. in der Cloud zugreifen können, die von den Assets herrühren, um sie entsprechend aufgabenspezifisch weiter zu verarbeiten.

Bildergalerie
Bildergalerie mit 8 Bildern

Beispiele sind Verwaltung der Assets, zusammenfassendes Anzeigen von Leistungsdaten der Produktion wie Overall Equipment Effectiveness (OEE) und Key Performance Indicators (KPIs) [06]. Zusätzlich befinden sich auf dieser Ebene Programme, um den menschlichen Bearbeitern die Daten in entsprechender Form aufbereitet anzuzeigen bzw. die Bedienhandlungen der Bearbeiter entgegenzunehmen (HMI).

Beim Internet der Dinge (Internet of Things, IoT) und auch bei dem für Produktionszwecke gemachten Ableger des IoT namens «Industrie 4.0» steht heute meistens das reine Datensammeln im Vordergrund: Die «Dinge» (Sensor, Aktor, ganze Maschine usw.) produzieren während ihrer eigentlichen Aufgabe Daten, die der Cloud zugeführt und dort mit Technologien wie z.B. Machine Learning gesammelt und ausgewertet werden. Condition Monitoring, vorausschauende Wartung, Event Processing, Prozessoptimierungen usw. werden dadurch möglich. Die Daten werden dabei entweder direkt von den Assets oder über sogenannte Edge Gateways in die Cloud übertragen.

Rein datenzentrierter Ansatz ist zu kurz gesprungen

Dieser rein datenzentrierte Ansatz ist jedoch zu kurz gesprungen und wird dem Potenzial der Architekturebenen Things / Edge / Cloud / HMI-Apps nicht gerecht. Wendet man sich von der bisherigen reinen Datenorientierung im IoT der Service-Orientierung im Sinne von SoA zu und erweitert das bisher ausschließliche Einsatzumfeld von SoA von reinen Softwarestrukturen auf die Things im IoT, kommt man zwangsläufig erneut zu «Everything as a Service» (XaaS), und zwar diesmal im doppelten Wortsinn:

Zum einen ergeben sich neue Business-Modelle, indem z.B. Automatisierungsgeräte nicht mehr verkauft, sondern dem Kunden beigestellt und per Benutzung abgerechnet werden («Pay per Use»), zum anderen kann jedes Gerät als Funktionsserver aufgefasst werden, das seine Dienste der es ansteuernden Instanz «über» ihn – der Cloud, der Edge – oder anderen Automatisierungsgeräten zur Verfügung stellt. Ein Roboter wird dadurch beispielsweise zum «Bewegungsserver», der nicht mehr wie heute für sich programmiert wird, sondern seine Bewegungsbefehle – genau wie alle anderen am Prozess beteiligten Automatisierungsgeräte – zentral aus der Edge bzw. Cloud als Service-Aufrufe erhält.

Der Applikations-Engineer der Automatisierungsaufgabe kann sich dadurch auf das eigentliche Gesamtsystem, bestehend aus mehreren Automatisierungskomponenten, konzentrieren und muss nicht wie heute jede Komponente einzeln programmieren bzw. parametrisieren.

Dass man durch das Senden von Daten an ein entsprechendes Gerät Aktionen an diesem auslösen kann, ist nicht neu. Bisher mussten allerdings die gewünschten Aktionen umständlich in Daten codiert werden, meist in Bits und Bytes. Die Bedeutung der Daten musste dabei zwischen dem Programmierer des Sende-Gerätes (das eine Aktion an einem Empfänger bewirken wollte, z.B. eine SPS) und des Empfängers (z.B. ein Roboter) meist immer wieder projektbezogen festgelegt werden bzw. – wenn sie unveränderbar waren – mussten sie im Benutzerhandbuch des Empfängergerätes dokumentiert worden sein.

Das Empfängergerät musste dann oft noch entsprechend programmiert bzw. parametrisiert werden, um die empfangenen Daten zu interpretieren und die entsprechenden Aktionen durchzuführen. Diese umständliche Art der Verwendung von Diensten über den Umweg der Codierung in Daten wird durch den SoA-Ansatz hinfällig.

Mittels SoA-Diensten kann der Sender direkt eine Aktion – einen Service – im Empfangsgerät auslösen. Eine Absprache der Bedeutung des Dienstes bzw. der einzelnen Bits und Bytes zwischen dem Sende- und Empfangsgerät entfällt dadurch.

SoA-Dienste steuern im IoT reale physikalische Geräte

Woher weiß aber der Sender, welche Dienste der Empfänger anzubieten hat? Hier kommt eine zentrale Eigenschaft von SoA ins Spiel, nämlich die Entdeckbarkeit von Diensten (Discovery), und zwar sowohl in maschinen- als auch computerlesbarer Form. Die Dienste, die ein SoA-Teilnehmer anzubieten hat, werden in entsprechenden Verzeichnisdiensten aufgelistet. Diese Verzeichnisdienste können sowohl im anbietenden Gerät ablaufen (semantische Selbstbeschreibung) oder auf zentralen Diensteverzeichnis-Servern vorhanden sein.

Bildergalerie
Bildergalerie mit 8 Bildern

Die bisher für reine Softwaredienste verwendete SoA kann somit im IoT zur Steuerung von realen physikalischen Geräten ausgeweitet werden. Die Edge hat dabei den weiteren Vorteil, dass sie aufgrund ihrer physikalischen Nähe zu den Assets und der Kommunikationsteilnahme auf demselben Netzwerk mit diesen in harter Echtzeit kommunizieren kann. Dazu bedarf es jedoch sogenannter Echtzeitbetriebssysteme in den Assets und den Edge-Computern inklusive deterministischer Echtzeitkommunikation zwischen den Teilnehmern. Dies ist heute mit Cloud-Kommunikation und Cloud-Betriebssystemen nicht möglich. Dadurch beschränkt sich die deterministische Echtzeitkommunikation allein auf die Edge und die Assets.

Semantische Servicebeschreibungen und Informationsmodelle

Wenn man sich nun auf gemeinsame Kommunikationsprotokolle auf allen Ebenen geeinigt hat, ist das zwar schon mal ein erster Schritt, aber für eine moderne Produktionstechnik noch nicht ausreichend. Für eine vollständige Interoperabilität fehlt nämlich noch etwas Entscheidendes, was bei den herkömmlichen Feldbussen mit dem Begriff Geräteprofile bezeichnet wird bzw. im Kontent von Maschinen und Anlagen die semantische Servicebeschreibung genannt wird.

Bei den Feldbussen wird darunter die Abbildung von Gerätedaten und -funktionen von gemeinsamen Geräteklassen wie z.B. von elektrischen Antrieben oder Input/Output-Modulen auf entsprechende Bits und Bytes des Feldbusses verstanden, die in genau festgelegter Reihenfolge und Größe über den jeweiligen Feldbus übertragen werden. Dadurch kann eine bestimmte Geräteklasse weitestgehend unabhängig vom Hersteller auf dieselbe Art und Weise angesteuert werden.

Dies erhöht zwar die Austauschbarkeit, was den Geräteherstellern nicht so gut gefällt, liegt jedoch im Interesse des Kunden. Und in einem kundenorientierten Markt werden sich Kundenwünsche früher oder später immer durchsetzen. Derjenige Hersteller, der sich durch Protektionismus, Technologie-Lock-Ins und Preisdiktate seine Kunden halten muss und nicht durch Qualität und ehrlichen Wettbewerb, wird es künftig nicht leichter haben.

Es ist müßig zu erwähnen, dass die in den bisherigen Geräteprofilen festgelegten Bits und Bytes bei jedem Feldbus natürlich meist völlig unterschiedlich definiert sind. Jeder Feldbus hat also seinen eigenen Satz von Geräteprofilen, in denen z.B. auch der Ablauf von Zustandsmaschinen definiert ist. Dieses Verhalten müssen wiederum die Gerätehersteller für jeden Feldbus unterschiedlich implementieren.

OPC UA kann auch hierbei helfen. Neben der reinen Übertragungstechnik als Kommunikationsprotokoll, bietet OPC UA auch definierte Mechanismen an, wie derartige Gerätebeschreibungen bei OPC UA standardisiert durchgeführt werden können. Daher kann man mit Fug und Recht behaupten, dass OPC UA mehr als nur «ein weiteres Feldbusprotokoll » ist. Bei den Feldbussen fehlt dieser Mechanismus der im Standard verankerten semantischen Selbstbeschreibung, die zur Laufzeit aus den OPC-UA-Geräten ausgelesen werden kann und somit Selbstauskunft über das Gerät gibt.

«Companion Specifications » werden je Geräteklasse erstellt

Die so erstellten Gerätebeschreibungen werden im OPC-UA-Umfeld «Companion Specifications » genannt und müssen je Geräteklasse erstellt werden [07] – also beispielsweise eine Companion Specification für die Geräteklasse der elektrischen Antriebe, eine Companion Specification für Industrieroboter, eine weitere für Prozesssteuerungen der Prozesse, die von den Robotern bewegt werden usw. Dabei werden sogenannte Informationsmodelle definiert, die sowohl die Daten als auch die Services – oft auch Funktionen oder Methoden genannt – des jeweiligen Gerätes beschreiben.

Da bei OPC UA immer sowohl Daten als auch Services eine Rolle spielen, sollte der Begriff Datenmodell vermieden und stattdessen «Informationsmodell» verwendet werden (Bild 3). Während man bei Feldbussen Funktionen in Bits oder Bytes codieren musste, kann man bei OPC UA gewünschte, an einem Gerät auszuführende Aktionen direkt als Funktionen mit Parameterübergabe an das Gerät senden. Als Antwort enthält der Sender entsprechende Parameter zurück.

Ein weiterer Unterschied zwischen OPC UA und den Feldbussen ist die Tatsache, dass bei den Feldbussen Sender und Empfänger implizit über die Bedeutung der jeweiligen Bits und Bytes Bescheid wissen mussten. Ein Kommunikationsteilnehmer konnte den anderen Teilnehmer nicht fragen, was er denn für ein Informationsmodell in sich trägt.

Bildergalerie
Bildergalerie mit 8 Bildern

Bei OPC UA gibt es diese Möglichkeit. Der OPC UA Client kann den OPC UA Server browsen (discovern) und erhält dessen komplettes Informationsmodell als Antwort zurückgeliefert. Dieses Informationsmodell ist sowohl menschen- als auch maschinenlesbar. Sollte der Kommunikationspartner über genügend künstliche Intelligenz verfügen oder sollte es sich um einen menschlichen Benutzer handeln, der die Anlage engineeren möchte, so können diese einfach herausfinden, um welche Art Gerät es sich handelt und was dieses Gerät an Daten und Diensten anbietet. Diese können dann sofort angewendet werden und falls das Engineering-System dies unterstützt, auch gleich automatisch. Dies kann so ähnlich gesehen werden wie in der Hochsprachenentwicklung die Reflections. Langwieriges Nachschlagen in Benutzer-Manuals und das Herausfinden der Bedeutung von Bits und Bytes entfällt, was das Engineering stark vereinfacht.

Wie kommt man aber denn nun zu diesen Companion Specifications? Da diese die Geräte, ihre Daten und Funktionen beschreiben, ist es natürlich naheliegend und am sinnvollsten, dass die Gerätehersteller selbst diese Companion Specifications für ihre Gerätetypen erstellen. Deshalb haben sich unter dem Dach des Vereins Deutscher Maschinen- und Anlagenbauer (VDMA) bereits mehrere Arbeitsgruppen gebildet, um herstellerübergreifend entsprechende Gerätebeschreibungen für eine bestimmte Geräte- oder Maschinenart zu erstellen. Die OPC Foundation unterstützt diese Bestrebungen und steht aktiv mit Rat und Tat zur Seite.

Echtzeit – ein häufig missverstandener Begriff

Obwohl die Services und Daten, so wie sie grundsätzlich von den «Things» zur Verfügung gestellt und dann mittels OPC UA oder anderen Informationsmodellen auf standardisierte Weise verfügbar gemacht werden können, immer gleich sind, so gibt es dennoch eine Qualität, die die Datenerzeugung und -übermittlung je nach Verwendungszweck entweder unbedingt haben muss – oder aber auch gar nicht benötigt: Echtzeitfähigkeit.

In der Automatisierung und in Industriesteuerungen, im Umfeld Industrie 4.0, aber auch in der IT wird häufig der Begriff «Echtzeit» verwendet. Damit werden jedoch – je nach Kontext – hauptsächlich zwei unterschiedliche Verhaltensweisen gemeint, die bei nicht sauberer Trennung oft zu Verwirrung und Missverständnissen führen.

Zum einen wird der Begriff in dem Verständnis verwendet, dass Menschen oder Computer, Maschinen usw. momentan in das aktuelle Geschehen eingebunden sind und beispielsweise über Apps, Kamerabilder, Bedienhandlungen usw. die Situation beobachten und kontrollieren können.

Das, was die Menschen sehen, hören und bewirken, sind keine Bilder, Videos oder Simulationen aus der Konserve, sondern das Geschehen findet momentan real ggf. an einem weit entfernten Ort statt. Es wird jedoch mit einer technisch bedingten Verzögerung von einigen Zehntelsekunden bis Sekunden übertragen. Insofern würde der Begriff «Online» hierfür besser passen als «Echtzeit».

Andererseits gibt es den technischen Begriff der «Echtzeit», der auch standardisiert ist. Die Definition der inzwischen durch ISO/IEC 2382 [08] abgelösten Norm DIN 44 300 [09] lautete: «Unter Echtzeit versteht man den Betrieb eines Rechensystems, bei dem Programme zur Verarbeitung anfallender Daten ständig betriebsbereit sind, derart, dass die Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind. Die Daten können je nach Anwendungsfall nach einer zeitlich zufälligen Verteilung oder zu vorherbestimmten Zeitpunkten anfallen.»

Der wichtigste Aspekt aus dieser Definition ist «innerhalb einer vorgegebenen Zeitspanne». Wer also den Begriff «Echtzeit» in diesem Zusammenhang gebraucht, muss auch immer die «vorgegebene Zeitspanne» (oft mit «D» für «Determinismus» abgekürzt) angeben. Insofern hat Echtzeit nichts mit Schnelligkeit zu tun, was ebenfalls oft verwechselt wird. Die Temperatursteuerung eines Gewächshauses mit beispielsweise D < 1 Stunde oder die Auszahlung des monatlichen Gehalts mit D < 1,1 Monaten sind weitere Beispiele für Echtzeitsysteme.

Bildergalerie
Bildergalerie mit 8 Bildern

Insbesondere bei der Überweisung des Monatsgehaltes wird deutlich, wie wichtig die Einhaltung der vorgegebenen Zeitspanne «D» ist. Wird diese nämlich verletzt, ist dies ein Fehler des Systems, der beispielsweise bei Computerprogrammen einer Division durch 0 gleichkommt: Es müssen dafür spezielle Fehlerbehandlungsabläufe etabliert werden, was sich anschaulich durch die Beschwerde des Angestellten darstellen lässt, wenn er drei Tage nach dem üblichen Auszahlungstermin sein Gehalt immer noch nicht erhalten hat.

Im Embedded Computing sind hohe D-Werte nutzlos

Im Bereich des Embedded Computing bzw. des Steuerns von Produktionsmaschinen und -anlagen sind derartig hohe D-Werte natürlich nutzlos. Hier liegen die D-Werte je nach Einsatzort in der gesamten Steuerkette von Maschinen meist in Bereichen von unter einer Millisekunde bis Hunderten von Millisekunden (ms), aber auch teilweise unter 100 Mikrosekunden (μs). Wie die monatliche Gehaltsüberweisung finden Steuerungsaufgaben meist zyklisch mit einer konstanten Zykluszeit statt. Alle Detailtätigkeiten innerhalb eines Zyklus zur Erledigung einer Steuer- bzw. Regelaufgabe müssen innerhalb der vorgegebenen Zeit «D» erledigt sein, damit der nächste Zyklus beginnen kann.

Damit dem System noch einige Reserven für unvorhersehbare Rechenaufgaben gegeben werden können, wird meist D << Zykluszeit gehalten. Beispielsweise findet man in Stromreglern von elektrischen Antrieben durchaus Zykluszeiten von 64,5 μs oder 32,25 μs vor, bei Zykluszeiten von Maschinensteuerungen Bereiche von ca. 1 ms und Zykluszeiten von speicherprogrammierbaren Steuerungen (SPS) von 1 ms bis ca. 50 ms. In jedem dieser Zyklen muss das steuernde System Eingangswerte eingelesen, verarbeitet und Ausgangswerte weitergegeben haben.

Wenn es dabei auch nach mehreren Wochen Dauerbetrieb und völlig unabhängig von der Auslastung des restlichen Systems immer rechtzeitig innerhalb der vorgegebenen Zykluszeit mit allen Aufgaben des Zyklus fertig geworden ist, ohne die vorgegebene Zykluszeit auch nur ein einziges Mal überzogen zu haben, bzw. wenn für entsprechende Ausnahmebehandlungen gesorgt worden ist, kann mit Fug und Recht von einem «harten» Echtzeitsystem gesprochen werden.

Ein «weiches» Echtzeitsystem liegt dann vor, wenn ein «gelegentliches» Überschreiten des «D» tolerierbar ist. Die Begriffe harte und weiche Echtzeit sind jedoch nirgendwo sauber definiert, und manche Zeitgenossen mögen bei den oben gemachten Definitionen anderer Meinung sein.

Industrie 4.0 funktioniert nicht ohne deterministische Netzwerkkommunikation

Durch die vorherigen Ausführungen sollte klar geworden sein, dass zur Einhaltung des Determinismus «D» alle an der Echtzeitbearbeitung wie einer Regelstrecke beteiligten Instanzen ihren deterministischen Beitrag leisten müssen. Da jede Kette nur so stark ist wie ihr schwächstes Glied, würde ein einziges nichtdeterministisches Verhalten die Echtzeitfähigkeit der gesamten Regelstrecke gefährden.

Bei Industrie-4.0-Architekturen sind jedoch einige Teilnehmer an Steuerungsaufgaben über Netzwerke verteilt. Sensoren und Aktuatoren befinden sich z.B. an anderen Stellen des Netzwerks als die Steuerungen. Daher müssen sowohl die Sensoren, die Steuerungen, die Aktuatoren und auch das übertragende Netzwerk alle einzeln deterministisch echtzeitfähig sein, und zwar mit einer derartigen Güte, dass die Summe aller Teil-«D»s das gewünschte Gesamt-«D» und somit auch die Zykluszeit nicht überschreitet – zumindest nicht ohne Ausnahmebehandlung.

Da in modernen Industrie-4.0-Netzwerken auch die echtzeitkritische Kommunikation mit abgedeckt werden soll und dafür nicht wie bisher separate, proprietäre Feldbussysteme eingesetzt werden sollen, die wieder einen Technologiebruch mit Behinderung der durchgängigen Kommunikation darstellen würden, bedarf es also einer deterministischen Netzwerkkommunikation.

Das Netzwerk muss mit dem Wesen von Zeit und Determinismus umgehen können, es muss «zeitsensitiv» werden. Dies soll mit der Einführung des Time Sensitive Networking (TSN) gewährleistet werden.

Echtzeit-Anwendungen von OPC UA

Mit TSN wurde ein offizieller IEEE- Ethernet-Standard für Quality of Service mit nachweisbaren und nachrechenbaren Echtzeiteigenschaften geschaffen. Das ist zwar notwendig und sehr sinnvoll für die Integration von unterschiedlich zeitkritischen Anwendungen in einem einzigen Netzwerk, aber es löst nicht das Problem von Interoperabilität der Datennutzung auf der Applikationsebene.

Bildergalerie
Bildergalerie mit 8 Bildern

Dafür ist Ethernet als Layer-2-Technologie auch nicht vorgesehen. Um aber auch auf der Applikationsebene Interoperabilität in Bezug auf die Darstellung von Diensten und Daten zu erzielen, braucht es nicht nur ein «Protokoll», sondern zusätzlich auch vereinheitlichte Dienste- und Datenmodelle.

Dafür ist «Informationsmodell» der passende Begriff. Diese Notwendigkeit zur Interoperabilität auf Applikationsebene ist natürlich nicht erst seit der Industrie-4.0-Initiative relevant. Sie wurde in der Vergangenheit aus unterschiedlichen Gründen von verschiedenen (großen) Herstellern unterschiedlich gelöst, weil kein einheitlicher Standard dafür existierte, der die herstellerspezifischen Anforderungen und Kompromisse – beispielsweise betreffend Kosten versus Zuverlässigkeit, Einfachheit von Installation und Inbetriebnahme versus Flexibilität, oder Diagnose von Problemen versus Erweiterbarkeit – eines bestehenden Systems adressieren konnte.

Da die großen Systemintegratoren meist auch Komponentenhersteller waren oder zumindest aufgrund ihrer Marktbedeutung andere Unternehmen zur Unterstützung ihrer jeweils optimierten Lösung bewegten, konnten sich Ökosysteme in Form von «Feldbusvereinen» entwickeln. Darin agierten jeweils eine Vielzahl von Herstellern und Komponentenzulieferern, die innerhalb ihres abgeschlossenen, proprietären Ökosystems interoperabel sind; zwischen verschiedenen solchen Systemen sind jedoch aufwendige Übersetzungsmechanismen und Gateways notwendig.

Durch Spezialisierung von Technologien auf jeder Ebene entstand in der Steuer- und Kommunikationsinfrastruktur von industriellen Produktionsanlagen zunehmend eine üblicherweise als «Pyramidenstruktur» dargestellte Architektur (Bild 4). Die unterste Ebene repräsentiert dabei das intelligente Produkt, die Sensor-, Aktuator- und IO-Elemente direkt am physischen Produktionsvorgang, die nächsthöhere Ebene zumeist die Steuer- und Kontrolllogik (SPS, Maschinen- und Prozessteuerungen usw.), darüber befinden sich die Ebene der Produktionsleitsysteme (Manufacturing Execution Systems, MES) zur Produktionssteuerung und Diagnose und die Ebene für Verwaltungssysteme wie Enterprise-Resource-Planning-Systeme (ERP).

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.

Für die IoT-Anbindung sind offene Standards essenziell

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

Effizienter Informationsaustausch über Regionen unterschiedlicher Amts- bzw. Umgangssprachen hinweg kann bei Menschen durch eine gemeinsame (Fremd-)Sprache erreicht werden. Müsste man ständig Dolmetscher dazwischenschalten, ginge Zeit und auch Inhaltsqualität verloren. Das gilt auch für Maschinen: Um Services und Daten z.B. zwischen Robotern, Verpackungs- oder Abfüllanlagen auszutauschen, sind eine allgemein verständliche Repräsentation von generischen Methoden für Discovery («Ich bin da, betriebsbereit und ich kann die beschriebenen Daten und Services anbieten»), Security («Um mit mir zu sprechen, musst du dich zuerst authentifizieren») und andere Klassen von Funktionalität erforderlich.

Geräte- oder anwendungsspezifische Funktionen und Parameter («Ich kann maximal zwei Flaschen pro Sekunde befüllen und habe derzeit noch acht leere Flaschen in der Warteschlange») müssen über eine generische und hinreichend flexible Repräsentationsschicht darstellbar sein.

Bildergalerie
Bildergalerie mit 8 Bildern

Die OPC Foundation standardisiert seit 1996 solche Mechanismen. Grundlage war die von Microsoft in den 1980ern entwickelte COM/DCOM-Technologie [10], die 2006 in eine vereinheitlichte Architektur (Unified Architecture, UA) überführt wurde. Seither steht mit OPC UA eine hersteller- und technologieunabhängige, standardisierte Plattform zur Verfügung, die in vielen Bereichen laufend an Unterstützung gewinnt. Ganz besonders auch in der digitalisierten Industrieautomatisierung, kurz Industrie 4.0. OPC UA wird mittlerweile von verschiedenen Anbietern auf unterschiedlichen Plattformen von der Cloud bis hin zu SPSen und Embedded-Systemen verfügbar gemacht.

OPC UA basiert primär auf einem Client/Server-Modell, wurde aber kürzlich um ein Publish/Subscribe-Modell erweitert. Letzteres 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 Informationsmodells möglich.

Die Publisher/Subscriber-Architektur von OPC UA

OPC UA verwendet einen herkömmlichen Client/Server-Mechanismus zur Datenakquisition und Service-Beauftragung, bei dem der User (oder allgemein: Client) in einem Ad-hoc-Verfahren Daten von Servern abrufen bzw. Dienste auf dem Server auslösen kann. OPC UA Publish / Subscribe wurde kürzlich durch die OPC Foundation zusätzlich zu dem bestehenden Client/Server-Mechanismus definiert [11] und steht bereits prototypisch zur Verfügung (Bild 5).

Diese Erweiterung sorgt dafür, dass einzelne Sende-Nodes zunächst Daten für mehrere Clients, die sich als Abonnenten identifiziert haben, veröffentlichen können. Im Sinne von Industrie 4.0 wird diese Erweiterung des Multicast-Datenaustausches die Kommunikation zwischen vielen Sensoren und der Cloud sowie die Koordination zwischen Maschinen ermöglichen. Es gibt eine große Untergruppe von Anwendungsszenarien, in denen Daten in einem garantierten Zeitraum – eben in deterministischer Echtzeit – übermittelt werden müssen. Dies gilt insbesondere für den Datenaustausch zwischen SPSen, Maschinensteuergeräten und Antrieben.

Um von Sende-Nodes (Publishers) Nachrichten deterministisch zu übertragen, sollten zwei Kriterien erfüllt werden:

  • Der Publish/Subscribe-(PubSub)-Stack soll in einer Echtzeit-SW-Umgebung ausgeführt werden, um zu gewährleisten, dass Daten periodisch gesendet werden können. Um für spezielle Anwendungsfälle die optimale End-to-End-Latenz zu ermöglichen, spezifiziert OPC UA Publish/Subscribe die Konfigurationsmöglichkeit, Nachrichten mit einem bestimmten Offset (Phase) innerhalb einer Periode zu übertragen und damit ein sehr präzises Zeitverhalten für die Kommunikation zwischen Publisher und Subscriber zu definieren.
  • Die PubSub-Nachrichten sollen über ein deterministisches Netzwerk übertragen werden. Herkömmliche industrielle Ethernet-Protokolle sind für die deterministische Kommunikation von Echtzeitdaten konzipiert. Es mangelt ihnen allerdings im Vergleich zu Standard-Ethernet an Eigenschaften wie Offenheit, Flexibilität und Skalierbarkeit. Diese Eigenschaften sind jedoch Anforderungen von Industrie 4.0. TSN erfüllt die Forderung nach garantierter deterministischer Kommunikation und bietet als Teil des IEEE-Ethernet-Standards auch die gleiche Flexibilität, wie OPC-UA-Nutzer sie bereits gewohnt sind.

Die Kombination von OPC UA Publish / Subscribe und TSN stellt daher eine passende Echtzeit-Kommunikationsplattform für die Anforderungen der Industrie 4.0 dar. Die Daten- und Konfigurationsschnittstelle zwischen OPC UA Pub / Sub und TSN wird ebenfalls durch eine Arbeitsgruppe der OPC Foundation definiert. Sie gewährleistet, dass OPC-UA-Daten, die eine garantierte Übermittlung erfordern, einen deterministischen Pfad durch das Netzwerk erhalten. Dies kann unter anderem erreicht werden, indem passende TSN-Konfigurationen für die Übertragung von OPC-UA-Daten verwendet werden.

Netzwerkkonfiguration erfolgt statisch oder dynamisch

Die Netzwerkkonfiguration kann entweder statisch (zum Zeitpunkt des Systemdesigns), oder dynamisch am laufenden Netzwerk konfiguriert werden. TSN standardisiert unterschiedliche Mechanismen für die dynamische TSN-Konfiguration – zentralisiert, verteilt und die Kombination aus verteiltem und zentralisiertem Ansatz. Daher spezifiziert OPC UA eine definierte Schnittstelle zu einer Service-Einheit, den sogenannten PubSub TSN Configuration Broker (PTCB). Diese Schnittstelle stellt den TSN-spezifischen Konfigurationsmechanismus von OPC-UA-Geräten transparent dar. Es sollten daher alle OPC UA Nodes diese Schnittstelle unterstützen.

Bildergalerie
Bildergalerie mit 8 Bildern

Über den PTCB werden OPC-UA-Publishers und Subscribers Anforderungen gesendet, um zur Laufzeit dynamisch die deterministischen Pfade für TSN zu konfigurieren. Das PTCB übermittelt diese Konfigurationsanforderungen an den spezifischen TSN-Konfigurationsmechanismus. Im Fall der Verwendung des zentralen TSN-Konfigurationsansatzes wird die PTCB mit dem Central Network Controller (CNC) die Daten austauschen.

Der CNC liefert danach die Konfigurationen der Nodes an den PTCB und sorgt außerdem dafür, dass die TSN Switches automatisch konfiguriert werden. Das PTCB liefert diese Konfigurationsdaten, wie z.B. die TSN Stream ID, dann an die OPC UA Nodes zurück. Sobald das Netzwerk konfiguriert ist und ein deterministischer Pfad bereitgestellt wurde, beginnt der Publisher mit der Veröffentlichung der Daten für die Echtzeitkommunikation.

Die PubSub-Spezifikation definiert ein Nachrichtenformat für verschiedene Nachrichtentypen, wie periodische Zustands- oder sporadische Ereignisnachrichten. Außerdem wird die Möglichkeit geboten, statisch konfigurierte Daten zu senden, um für einfache Implementierung für den Publisher und Subscriber zu sorgen.

Deterministische Echtzeit durch Time Sensitive Networking (TSN)

Wenn die Echtzeit-Kommunikationsverbindungen mittels OPC UA Publish / Subscribe definiert werden (Bild 6) und mittels eines Brokers an die Konfiguration des TSN-Netzwerks weitergemeldet wurden, dann obliegt es dem TSN-Netzwerk, die solcherart «angeforderten» Echtzeit-Datenströme auch tatsächlich so zu transportieren.

Neben verschiedenen sehr kostengünstigen Feldbussen hat sich Ethernet schon vor über einem Jahrzehnt auch in der Industrieautomatisierung als leistungsfähige Netzwerk-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 ISO-Schicht 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, und zwar zuerst 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 Audio Video Bridging (AVB) bekannt und bieten für echtzeitsensitive Audio- und Videoapplikationen Stream-basierte Quality-of-Service-Mechanismen für Ethernet-Netzwerke an, um Synchronisation z.B. von Lautsprechern und Latenz-Obergrenzen wie von Audiodaten zu erreichen.

Mehrere der Mechanismen von TSN sind Erweiterungen oder Verallgemeinerungen von bereits in anderen (industriespezifischen) Ethernet-Standards verfügbaren und geforderten Funktionen unter anderem redundante Übertragung von Ethernet-Paketen über unterschiedliche Netzwerk-Pfade nach 802.1CB [13]. Andere Mechanismen wie u.a. Frame Preemption nach 802.1Qbu [14] und 802.3br [15] sind völlig neu und ermöglichen noch mehr Echtzeitfähigkeit von Ethernet durch Reduktion der Latenz in Netzwerken mit «großen» Datenpaketen, wie es gerade bei konvergenten Netzen vorkommen kann, wenn «normale» Ethernet-basierte Kommunikation mit Echtzeitkommunikation ein Kabel teilt.

IEEE 802.1Qbv beschreibt zeitsynchrone Kommunikation im Ethernet

Besonders relevant ist aber der TSN-Standard IEEE 802.1Qbv [16], mit dem Quality of Service für zeitsynchrone Kommunikation in Ethernet beschrieben werden kann und damit einen Mechanismus darstellt, der hochpräzise Echtzeitdatenströme zusammen mit ganz gewöhnlichem Best-Effort-Ethernet-Verkehr in einem einzigen Netzwerk erlaubt. Eine Übersicht über die gängigsten TSN-Substandards enthält Tabelle 1.

Bildergalerie
Bildergalerie mit 8 Bildern

Zentrales Prinzip von TSN ist ein Konzept namens Time Aware Shaper (TAS). Switches, die nach diesem Prinzip arbeiten, teilen den Datenverkehr gemäß ihrer Priorität in verschiedene Warteschlangen (Queues) ein, die anhand eines globalen Zeitplans abgearbeitet werden. Zeitkritische Datenframes erhalten einen entsprechenden Eintrag, anhand dessen die Einteilung in eine bestimmte Warteschlange geschieht. Jede Warteschlange hat ein sogenanntes Transmission Gate, das entweder offen oder geschlossen sein kann. Bei der Auswahl des nächsten zu versendenden Datenpakets im Switch werden nur Warteschlangen mit offenen Transmission Gates berücksichtigt.

Diese Konzepte sind im Substandard 802.1Qbv [16] festgelegt. Datenframes mit geringer Priorität können auch während der Übertragung unterbrochen werden (Frame-Preemption), um zeitkritischem Datenverkehr den Vorzug zu geben. Für die Garantie der Echtzeitfähigkeit ist das notwendig, führt in der Regel aber nicht zur optimalen Ausnutzung der Bandbreite oder zu einer minimalen Latenzzeit. Im Substandard 802.1Qbu [14] sind Protokolle definiert, um für solche Fälle die Latenzzeit für den zeitunkritischen Datenverkehr möglichst gering zu halten.

Das TAS-Konzept ist auf einen robusten Mechanismus zur Generierung einer systemweiten, einheitlichen Zeit mit einer Genauigkeit im Sub-Mikrosekundenbereich angewiesen. Das dafür vorgesehene Prinzip ist im Substandard 802.1ASrev [17] festgeschrieben. Es handelt sich dabei um eine Weiterentwicklung des bereits weitverbreiteten Precision Time Protocol (PTP) nach IEEE 1588 [18].

Mit TSN kann eine Vereinheitlichung von Ethernet-Netzwerken von der untersten «Pyramidenschicht» bis hinauf zur Cloud-Anbindung realisiert werden, ohne Gateways und andere Übersetzungselemente zu benötigen (vergleiche dazu Bild 3). Da es sich bei TSN um eine vollkompatible und in IEEE standardisierte 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.

Performance- und Echtzeitanforderungen der Applikationen für OPC UA in einem gesamtheitlichen System realisieren

Um nun eine einheitliche Plattform für IoT-Datenzugriffe vom Sensor bis zur Cloud zu schaffen, müssen Netzwerk und Informationsmodell 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 miteinander zu bringenden Anforderungen möglich wird: garantierte Echtzeit in Anwesenheit beispielsweise flexibler Bedienerzugriffe und IoT-Anbindung inklusive voller Interoperabilität bei Herstellerunabhängigkeit dank offener Standards (Bild 7).

Von erheblicher Bedeutung ist dabei auch die breite Unterstützung in der Automatisierungsindustrie. Nach der von KUKA im Frühjahr 2015 gegründeten Initiative OPC UA, um die Echtzeitfähigkeit durch TSN zu erweitern [19], kündigten Ende 2016 im Rahmen einer viel beachteten Pressekonferenz auf der SPS/IPC/Drives-Messe 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 der OPC-UA- und TSN-Standards als künftig bevorzugte Lösung an [20].

Die Verbreitung von OPC UA in der Industrieautomatisierung legt nahe, nicht nur die IoT-Cloud-Anbindung von kompletten Systemen bzw. Maschinen über entsprechende Informationsmodelle abzubilden, sondern auch Zugriff auf einzelne Datenelemente auf der untersten Ebene, also Sensoren und Aktuatoren, über diese Plattform zu ermöglichen. Zugriff auf einzelne aktuelle Datenelemente innerhalb eines laufenden Steuerungsprozesssystems bietet neue Möglichkeiten bei vorausschauender Diagnose und Maintenance sowie bei der Optimierung von Produktionsprozessen.

Die «Big Data»-Analyse kann durch diese Zugriffsmethoden dynamisch um genau jene Datenelemente erweitert werden, 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 nicht zu bewältigen wäre. Daher muss an der Maschinenobergrenze oder der 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 dieser Plattform realisierbar.

Bildergalerie
Bildergalerie mit 8 Bildern

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 davorliegenden 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 IoT und Industrie 4.0 notwendig sind, Bandbreite und Übertragungsgeschwindigkeit von Gigabit-Ethernet, und garantierte Echtzeitfähigkeit für alle Anwendungen und Datenverbindungen vom Sensor bis in die Cloud.

Werden durch OPC UA TSN herkömmliche Feldbusse überflüssig?

Es ist nicht die Absicht der OPC-UA-TSN-Initiative, herkömmliche Feldbusse, deren Feldbusvereine oder die jeweilig treibenden Firmen überflüssig zu machen. Vielmehr ist es das Ziel, zunächst zusätzlich zu den bestehenden Lösungen einen zukunftssicheren, gemeinsamen Hauptnenner zu schaffen, auf den sich alle Parteien, auch die großen Marktführer, sowohl technisch als auch politisch zugunsten einer wirklichen, gesamtherstellerübergreifenden Interoperabilität einigen können. Sowohl OPC UA als auch TSN sind offene, frei verfügbare Standards, die nicht nur von einer einzigen dominanten Firma getrieben werden, wie dies bisher bei fast allen Feldbussen der Fall war.

Avnu Alliance veröffentlicht neues Whitepaper zu Wireless TSN

Die Avnu Alliance hat ein neues Whitepaper veröffentlicht, das sich mit Time Sensitive Networking (TSN) befasst, sowie die Einrichtung einer Avnu-Arbeitsgruppe, die die weitere Arbeit zur Ausweitung der TSN-Fähigkeiten auf drahtlose Netze unterstützen soll.

Die jüngsten Fortschritte bei den drahtlosen 5G- und IEEE 802.11-Konnektivitätstechnologien zur Bereitstellung von Kommunikation mit niedriger Latenz und hoher Zuverlässigkeit haben in der Branche ein erhebliches Interesse an der Ausweitung der TSN-Fähigkeiten auf drahtlose Netzwerke geweckt. Da TSN-fähige Geräte und Netzwerke weiterhin in einem breiten Spektrum von vertikalen Märkten eingesetzt werden - z.B. in der Industrie, der Robotik und der professionellen AV-Technik - ist die Möglichkeit der Erweiterung ähnlicher Fähigkeiten über Wireless ein natürlicher nächster Schritt.

Das neue Whitepaper "Wireless TSN – Definitions, Use Cases & Standards Roadmap" analysiert die bestehenden Standards und der Lücken in der Standardisierung, die vor einer Implementierung von Wireless TSN "in der Fläche" geschlossen werden müssen. Ferner enthält das Whitepaper eine Darstellung potenzieller Anwendungsfälle von Wireless TSN in verschiedenen Umgebungen und Märkten, dazu einen Überblick über die Arbeiten, die innerhalb der Avnu und der Industrie erforderlich sind, um in Zukunft TSN-Fähigkeiten in drahtlosen und kabelgebundenen Netzwerken zu ermöglichen.

Zu den ersten Mitgliedern der Arbeitsgruppe und Autoren des Whitepapers gehören Vertreter von Intel, Keysight Technologies, General Electric und dem professionellen AV-Hersteller L-Acoustics.

Download des Whitepaper

Hierfür kann zunächst einmal mit der nicht echtzeitfähigen Nutzung von OPC UA Client / Server auf den Schnittmengen der Layer «Communication» und «Information» mit den Hierarchie-Levels «Control Device» bis «Work Centers» nach dem RAMI-4.0-Modell begonnen und sukzessive um die echtzeitfähige Verwendung von OPC UA bis hinunter zur Feldebene erweitert werden. Herkömmliche Feldbusse können auf dem Integration Layer dazu dienen, herkömmliche Brownfield-Anlagen an Industrie 4.0 anzuschalten.

Bei einigen der bestehenden Feldbustechnologien gibt es große Überlappungen mit den technischen Eigenschaften von OPC UA TSN, bei anderen weniger. Rein technisch gesehen, hat OPC UA TSN somit durchaus das Potenzial, einige der bestehenden Feldbustechnologien zu disrupten.

Quellen

[01] DIN SPEC 91 345:2016-04 Referenzarchitekturmodell Industrie 4.0 (RAMI 4.0). Berlin: Beuth Verlag GmbH, April 2016.

[02] Normenreihe: IEC 62 541 OPC unified architecture. Genf: International Electrotechnical Commission (IEC), 2015-2016.

[03] Normenreihe: IEEE 802.1 Time Sensitive Networking – Security, Data Center Bridging, OmniRAN and Maintenance. New York: Institute of Electrical and Electronics Engineers (IEEE), 2009-2016.

[04] Normenreihe: IEC 61 158 Industrial communication networks – Fieldbus specifications. Genf: International Electrotechnical Commission (IEC), 2007-2014.

[05] Predix – The Industrial Internet Platform. Boston: General Electric, November 2016. (abgerufen am 09.05.2017).

[06] DIN 8743:2014-01 Verpackungsmaschinen und Verpackungsanlagen – Kennzahlen zur Charakterisierung des Betriebsverhaltens und Bedingungen für deren Ermittlung im Rahmen eines Abnahmelaufs. Berlin: Beuth Verlag GmbH, Januar 2014.

[07] Industrie 4.0: Kommunikation mit OPC UA. Leitfaden zur Einführung in den Mittelstand. Frankfurt am Main: VDMA e.V., Lemgo: Fraunhofer IOSB-INA. 2017.

[08] ISO / IEC 2382:2015-05 Information technology – Vocabulary. Genf: International Organization for Standardization (ISO), Mai 2015.

[09] DIN 44 300-9:1988-11 Informationsverarbeitung – Begriffe – Verarbeitungsabläufe. Berlin: Beuth Verlag GmbH, November 1988.

[10] MS-DCOM: Distributed Component Object Model (DCOM) Remote Protocol. Redmond: Microsoft Corporation, Juli 2016. (abgerufen am 09.05.2017).

[11] OPC Unified Architecture Specification Part 14: PubSub. Release Candidate 1.04.24. Verl: OPC Foundation Europe, Februar 2017.

[12] OPC Unified Architecture. Interoperabilität für Industrie 4.0 und das Internet der Dinge. Verl: OPC Foundation Europe, Februar 2015.

[13] IEEE P802.1CB – IEEE Draft Standard for Local and metropolitan area networks — Frame Replication and Elimination for Reliability. New York: Institute of Electrical and Electronics Engineers (IEEE), März 2017.

[14] IEEE 802.1Qbu – IEEE Standard for Local and metropolitan area networks – Bridges and Bridged Networks – Amendment 26: Frame Preemption. New York: Institute of Electrical and Electronics Engineers (IEEE), 2016.

[15] IEEE 802.3br – IEEE Standard for Ethernet Amendment 5: Specification and Management Parameters for Interspersing Express Traffic. New York: Institute of Electrical and Electronics Engineers (IEEE), 2016.

[16] IEEE 802.1Qbv – IEEE Standard for Local and metropolitan area networks – Bridges and Bridged Networks – Amendment 25: Enhancements for Scheduled Traffic. New York: Institute of Electrical and Electronics Engineers (IEEE), 2015.

[17] IEEE P802.1AS-Rev – IEEE Draft Standard for Local and metropolitan area networks – Timing and Synchronization for Time-Sensitive Applications. New York: Institute of Electrical and Electronics Engineers (IEEE), März 2017. 360 Quellenverzeichnis

[18] IEEE 1588-2008 – IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. New York: Institute of Electrical and Electronics Engineers (IEEE), 2008.

[19] Herkommer, Günther: Industrie 4.0: OPC UA – Arbeitsgruppe für Echtzeit gegründet. Haar: WEKA Fachmedien GmbH, April 2015. http://www.computer-automation.de/feldebene/vernetzung/ artikel/118732 (abgerufen am 09.05.2017).

[20] Schäfer, Reinhold: Industrial Internet of Things. Führende Hersteller unterstützen den Standard OPC UA TSN. Würzburg: Vogel Business Media GmbH, November 2016. (abgerufen am 09.05.2017).

Die Autoren

Dipl.-Ing. (FH) Heinrich Munz, Lead Architect Industrie 4.0 – KUKA Aktiengesellschaft, und M.Sc. Georg Stöger, Director Projects and Products – TTTech Computertechnik AG.

Dieser Beitrag stammt aus den dem Fachbuch „Industrie 4.0: Potenziale erkennen und umsetzen“ von Thomas Schulz (Hrsg.). Das Buch bietet dem Professional einen praxisorientierten und umfassenden Einblick in die Digitalisierung der Fertigung und der Produktion. Das Buch „Industrie 4.0“ kann hier versandkostenfrei oder als eBook bestellt werden.

(ID:46528209)