Suchen

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.

(ID:46528209)