Technologieüberblick Industrienetze
Ganz nach Protokoll
Veröffentlicht in Ausgabe 07/2024 - SCHWERPUNKT
Industrievernetzung ist an sich nichts Neues. Dass Maschinen digital angesteuert werden, um Automatisierungsprozesse zu vereinfachen, ist seit mehreren Jahrzehnten geübte Praxis. Klassische Industrienetze gliedern sich in drei Ebenen: Auf der untersten werden die Signale von Sensoren ausgelesen und an eine Sammelstelle transportiert oder Signale an Aktoren verschickt. Auf diesem Level arbeiten normalerweise sogenannte Feldbussysteme. Darauf folgt die Steuerungsebene, auf der sich die Steuerungseinheiten für die daran angebundenen Maschinen befinden. Sie sind in der Regel über Ethernet mit höheren Ebenen und gegebenenfalls auch untereinander verbunden. Auf der obersten Leitebene, wo sogenannte Manufacturing-Execution-Systeme arbeiten, finden übergeordnete Steuerungsprozesse statt.
Dieses Modell ist hierarchisch angelegt: Die Steuerung erfolgt von oben nach unten, Signale fließen von unten nach oben. Damit einhergeht, dass von der untersten Ebene relativ überschaubare Datenmengen auf eher schmalen Bandbreiten eingesammelt und auf höheren Ebenen konsolidiert und analysiert werden. Oft stammen in solchen Infrastrukturen die Steuereinheiten der Maschinen samt ihren Protokoll-Stacks, um die es hier geht, vom selben Hersteller, sind also proprietär. Das aber ist eines der wesentlichen Hindernisse für moderne, softwaregetriebene Infrastrukturen und Anwendungen.
Industrie 4.0 stellt hohe Anforderungen
Mit der neuen Technologiegeneration, im industriellen Sektor umschrieben mit den Begriffen Industrie 4.0 und Industrial IoT (IIoT), verschärfen sich die Anforderungen. Bei diesen Konzepten finden sich erheblich mehr Sensoren in oder an den Maschinen und anderen Komponenten, um die Überwachung und Steuerung genauer zu gestalten.
Industrievernetzung ist an sich nichts Neues. Dass Maschinen digital angesteuert werden, um Automatisierungsprozesse zu vereinfachen, ist seit mehreren Jahrzehnten geübte Praxis. Klassische Industrienetze gliedern sich in drei Ebenen: Auf der untersten werden die Signale von Sensoren ausgelesen und an eine Sammelstelle transportiert oder Signale an Aktoren verschickt. Auf diesem Level arbeiten normalerweise sogenannte Feldbussysteme. Darauf folgt die Steuerungsebene, auf der sich die Steuerungseinheiten für die daran angebundenen Maschinen befinden. Sie sind in der Regel über Ethernet mit höheren Ebenen und gegebenenfalls auch untereinander verbunden. Auf der obersten Leitebene, wo sogenannte Manufacturing-Execution-Systeme arbeiten, finden übergeordnete Steuerungsprozesse statt.
Dieses Modell ist hierarchisch angelegt: Die Steuerung erfolgt von oben nach unten, Signale fließen von unten nach oben. Damit einhergeht, dass von der untersten Ebene relativ überschaubare Datenmengen auf eher schmalen Bandbreiten eingesammelt und auf höheren Ebenen konsolidiert und analysiert werden. Oft stammen in solchen Infrastrukturen die Steuereinheiten der Maschinen samt ihren Protokoll-Stacks, um die es hier geht, vom selben Hersteller, sind also proprietär. Das aber ist eines der wesentlichen Hindernisse für moderne, softwaregetriebene Infrastrukturen und Anwendungen.
Industrie 4.0 stellt hohe Anforderungen
Mit der neuen Technologiegeneration, im industriellen Sektor umschrieben mit den Begriffen Industrie 4.0 und Industrial IoT (IIoT), verschärfen sich die Anforderungen. Bei diesen Konzepten finden sich erheblich mehr Sensoren in oder an den Maschinen und anderen Komponenten, um die Überwachung und Steuerung genauer zu gestalten.
Sie erzeugen natürlich auch viel mehr Daten, und diese Datenmengen fließen anschließend an die in der Nähe befindlichen Steuereinheiten oder weiter an kleine lokale Rechenzentren (Edge-DC), wo sie von der dortigen Intelligenz ausgewertet oder gefiltert werden. Dort werden als Reaktion auf die Datenlage auch bereits autonom Steuerimpulse generiert.
Zudem, so das IIoT/Industrie-4.0-Konzept, sollen sich die einzelnen sensor- und aktornahen Steuersysteme oder am Ende sogar intelligente Sensoren und Aktoren selbst in übergreifenden Prozessketten automatisch miteinander verzahnen, beispielsweise, um den nächsten Produktionsschritt oder Nebenprozesse anzustoßen. Diese Verkettungen können durchaus Betriebsgrenzen überschreiten.
Ziel ist es, vollständige Produktions- und Lieferketten digital und vernetzt in Echtzeit zu steuern und dabei möglichst wenig verzögernden Overhead und Eingriffe zu benötigen. Kombiniert mit Digital-Ledger-Systemen, KI und Datenräumen sollen so vollständig digitalisierte, sehr reagible und lernfähige, dennoch zuverlässige und fälschungssichere Geschäftsprozessketten entstehen. Vorläufiger Endpunkt der Entwicklung soll ein "Industrial Metaverse" sein.
Digitale Zwillinge brauchen Daten schnell
Das dafür vielleicht wichtigste Werkzeug sind sogenannte digitale Zwillinge, die die "Plattform Industrie 4.0" als digitale Verwaltungsschale bezeichnet. Sie sind das Datenabbild von Maschinen, Aggregaten oder ganzen Produktionsprozessen und basieren idealerweise auf Echtzeitdaten unmittelbar aus dem dargestellten Prozess oder Gerät mit allen Komponenten und Prozessschritten.
So ist einerseits am Bildschirm zu sehen, was gerade geschieht beziehungsweise gemessen wird – meist in einer aussagekräftigen optischen Darstellung und tiefen Drill-Down-Möglichkeiten. Mit geeigneter Software lässt sich beispielsweise schon vor einem Ausfall erkennen, wo besser ein Modul ersetzt oder ein Wartungsvorgang durchgeführt wird (Predictive Maintenance). Auch Optimierungen am Design, die die Erfahrungen im praktischen Betrieb widerspiegeln, werden so möglich. Sie lassen sich sofort in die digitalen Pläne entsprechender Maschinen oder Prozesse übertragen und zuvor in ihren Auswirkungen am digitalen Zwilling simulieren.
Damit solche Anwendungen mit zahlreichen Echtzeit-Rückkopplungen und exzessiver Datengewinnung und -analyse funktionieren, muss jedes einzelne Gerät, jeder einzelne Sensor oder Aktor in die Vernetzung eingebunden sein. Gewonnene Daten oder sich aus ihrer Analyse ergebende Steuerimpulse müssen möglichst in harter Echtzeit oder aber echtzeitnah dorthin fließen können, wo sie benötigt werden – sei es, an eine benachbarte Steuerung, sei es an ein Edge-Datenzentrum oder den digitalen Zwilling in der zentralen Private oder Public Cloud.
Anforderungskatalog an Industrieprotokolle
Daraus ergeben sich die Herausforderungen, denen die Protokoll-Stacks und Vernetzungssysteme in Industrie-4.0-Umgebungen gerecht werden müssen:
- Sie müssen zum Teil exotische oder bereits sehr alte Gerätschaften und Aggregate in die bidirektionale Kommunikation im Industrienetz einbeziehen, also über entsprechende Schnittstellen verfügen. Auf den oberen Netzwerkebenen bedeutet das, dass ihre Daten für andere Maschinen, Steuerungen und digitale Systeme les- und verstehbar sind.
- Die Protokolle und ihnen unterliegende Bussysteme müssen Daten je nach Anwendung in Echtzeit oder echtzeitnah und taktgenau befördern.
- Die Verbindungen dürfen nicht ausfallen, sind also durch Redundanz und andere Mechanismen ausfallsicher zu gestalten.
- Sie müssen sicher sein, um zu verhindern, dass sich externe Eindringlinge in die Steuerungsebene von Produktionsprozessen einschleichen und sie manipulieren können – genannt sei hier nur Stuxnet.
- Im Idealfall sollten sie ökonomisch arbeiten, also viele Daten(pakete) mit wenig Overhead transportieren können, um die Netzwerkinfrastruktur – ob nun drahtlos oder verkabelt – nicht übermäßig zu beanspruchen.
- Industrienetze müssen in einem auch elektrisch herausfordernden Umfeld arbeiten. Ihre Protokolle und Übertragungswege brauchen daher besonderen Schutz gegen Störungen der Übertragungsgenauigkeit durch elektrische Felder oder andere Irritationen.
- Die Protokolle sollten möglichst nicht proprietär, sondern standardisiert und offen sein, damit plötzliche Verschiebungen in der Industrielandschaft die Verfügbarkeit der Verbindungen nicht beeinträchtigen.
Marktstrukturen behindern den Fortschritt
Wären all die eben genannten Forderungen erfüllt, wäre der ideale Zustand erreicht. Aber tatsächlich laufen gerade ältere Systeme und Maschinen, die es in Produktionsstraßen oder Lagern haufenweise gibt, oft genug weiter nur mit einem proprietären Protokoll ihres Herstellers.
Sonst sind Gateways erforderlich, die die Datenformate ineinander umsetzen. Denn das Protokoll, das der Hersteller ursprünglich nicht vorgesehen hatte, braucht eine allgemein lesbare Schnittstelle, wenn sich das Gerät nicht auf eine modernere Methode umrüsten lässt. Das ist nicht immer trivial.
Manchmal ist das Übergewicht eines Herstellers auf einem nationalen Markt so stark, dass es großer Anstrengungen bedarf, anderen Protokollen, die die heutigen technischen Anforderungen möglicherweise genauso gut oder besser erfüllen, eine Chance zu verschaffen. Ein typisches Beispiel für eine etablierte Landschaft ist Siemens mit seinen Simatic-Steuerungen und dem darauf laufenden S7-Protokoll, das in Deutschland sehr verbreitet ist.
Siemens unterstützt damit Geräte, die kein TCP/IP können, also niemals für Ethernet-Vernetzung ausgerüstet wurden. Dafür braucht es allerdings S7- oder C7-CPUs, die die fehlenden Funktionen für die Kommunikation über die genutzten Busstrukturen bereitstellen. S7 selbst arbeitet auf den oberen Protokollebenen, eröffnet also den Zugriff für Anwendungen.
S7 selbst kann große und kleine Datenmengen übertragen, schreiben und lesen. Das Protokoll überträgt 1 Byte bis 64 KByte – je nach Dienst und verwendeter S7-CPU. Es quittiert die Datensätze selbsttätig und belastet laut Siemens Prozessoren und Bus wenig.
Eine Ebene tiefer, bei den Bussystemen, ist Siemens mit dem proprietären Profibus-Abkömmling MPI (Multipoint Interface) ebenfalls vertreten. MPI ist Programmier- und Diagnoseschnittstelle für viele Siemens-Steuerungen. Maximal 32 Geräte lassen sich damit über eine Strecke von bis zu 50 Meter anbinden.
Echte Echtzeit ist ein Problem
Auch das Thema (Near)-Realtime sorgt immer wieder für Verdruss. Denn je mehr Umsetzungen und Schnittstellen und je mehr Netzebenen eine Information bis zum Ziel passieren muss, desto größer ist der Header der Informationspakete und desto länger dauert der Datentransport. Dann haben im schlimmsten Fall ungeduldige Applikationen ihren Timeout schon überschritten und müssen neu gestartet werden.
Für das Funktionieren von IoT/Industrie-4.0-Umgebungen ganz entscheidend sind aber moderne, offene Plattformen, Protokolle und Konzepte, die die Kommunikationswege technologieunabhängig durchgängig halten. Um solche Technologien soll es im Folgenden hauptsächlich gehen.
Hier ist im industriellen Umfeld vor allem die Plattform OPC-UA (IEC 62541) wichtig. Der 2006 erstmalig veröffentlichte und seitdem stetig weiterentwickelte Standard wurde von dem Industriekonsortium Open Platform Communication (ehemals Object Linking and Embedding for Process Control) entwickelt. UA steht für Unified Architecture. 2008 kam die erste von Microsoft-Betriebssystemen unabhängige Version auf den Markt.
Ein Rahmen für alles: OPC-UA
OPC-UA ist als Client-Server-Lösung definiert. Es ist offen, denn technische Weiterentwicklungen beispielsweise bei den Kommunikationsprotokollen lassen sich einbeziehen. Mit seiner Offenheit und seinem objektorientierten Informationsmodell ermöglicht OPC-UA den Aufbau einer serviceorientierten Architektur.
Die Technologie unterstützt physische und Cloudserver, speicherprogrammierbare Steuerung und Mikrocontroller sowie sämtliche wichtigen Betriebssysteme (Windows, macOS, Android, alle Linux-Distributionen). Kern sind ein flexibles Informationsmetamodell und eine Zugriffsebene für den Zugang zu diesem Modell. Diese Zugriffsebene besteht aus einem Modul für Datenzugriff und Semantik, Ausführung von Methoden und Konfiguration und einem anderen für Daten- und Event-Benachrichtigungen. Die Module setzen auf einer Client/Server-beziehungsweise Publish/Subscribe-Infrastruktur und den Mappings zu den anwendungsspezifischen Protokollen auf.
Über dem zentralen Informationsmodell liegen die Kerninformationsmodelle für bestimmte Vorgänge wie Alarme, Dateitransfer oder analoge Daten. Darüber folgen die Informationsmodelle für angeschlossene Systeme (etwa Roboter, Windturbinen oder CNC-Maschinen) und schließlich die schon erwähnten herstellerspezifischen Erweiterungen.
OPC-UA erlaubt die Kommunikation nach dem Client/Server- und dem Publish/Subscribe-Prinzip, bei dem sich Knoten in Publisher (erzeugen Daten) und Subscriber (beziehen Daten) aufteilen. Dafür braucht OPC UA ein entsprechendes Plug-in. Dieser Modus überträgt die Daten in einem strukturierten Format.
Wegen der Heterogenität der Industrieumgebungen ist es entscheidend, dass OPC-UP mit vielfältigen Protokollen und Bussystemen zusammenarbeitet. Diese Vielfalt bedeutet, dass Anwender nahezu für jede Umgebung das richtige Protokoll finden werden. Gleichzeitig gestaltet sich natürlich die Auswahl komplexer und erfordert deshalb Know-how.
Gängige Protokolle
Zu den von OPC-UA unterstützten Protokollen gehört MQTT (Message Queuing Telemetry Transport, ISO/IEC 20922), für das es ein OPC-UA-Plug-in gibt. Dieses Protokoll arbeitete auf der Anwendungsebene der Netze. Entwickelt wurde es speziell für industrielles IoT/M2M. MQTT versendet mit geringer Bandbreite und hoher Latenz kleine Datenmengen zwischen Maschinen. Das Protokoll bedarf eines zentralen Brokers, an den die Daten geliefert und von dem sie abgeholt werden. Auch die Anbindung von Maschinen an die Cloud ist über MQTT möglich.
MQTT arbeitet mit sogenannten Topics, also Themen, die sich mit zunehmender Detaillierung verzweigen. Zugriffe der Subscriber erfolgen auf bestimmte Ebenen des Topics, wo sich dann die gesuchte Information befindet. Besonders gern wird MQTT in unzuverlässigen Netzwerken gewählt, da die Daten bei Ausfall gepuffert werden, bis die Verbindung wieder steht. Es gehört zu den verbreitetsten Protokollen in IoT-Netzwerken.
Auf der Middleware-Ebene arbeitet das Open-Source-Messaging-Protokoll AMQP (Advanced Message Queuing Protocol), standardisiert als ISO 19464. Es vernetzt heterogene Betriebssysteme und vereinfacht Plattformen über mehrere Betriebssysteme hinweg. AMQP ist mittlerweile in Linux integriert.
Es unterstützt unterschiedliche Routing-Optionen und ist komplexer als etwa die weit verbreitete Kombination HTTP/REST. Außerdem erzeugt es Protokolloverhead. AMQP ist binär und verbindungsorientiert sowie sehr zuverlässig. Es bietet eine portable Datenrepräsentation und unterstützt Peer-to-Peer-, Client-Broker- und Broker-Broker-Topologien. Wie das Broker-Modell intern organisiert ist, ist für das Protokoll unerheblich. Im Endeffekt lässt sich über AMQP jedes Gerät anbinden und über jede Applikation auf Daten zugreifen.
Auch Standard-HTTP/REST ist als Protokoll nutzbar. Es dient bei der Entwicklung vieler Webanwendungen zum Datenversand an einen Webserver. Nachteilig ist die verbindungslose Arbeitsweise – jede Nachricht benötigt Authentifizierungsinformationen und damit mehr Energie und Platz auf dem Netz. AWS IoT und Azure IoT beispielsweise unterstützen HTTP/REST.
Für die Anwendungsebene schmalbandiger Netze mit schlechter Qualität wurde CoAP entwickelt. Besonders geeignet ist es für Anwendungen mit begrenzter Batterielebensdauer. Der Standard wurde von der IETF unter RFC 7252 2014 veröffentlicht. CoAP ähnelt HTTP und arbeitet nach REST-Prinzipien, also nach dem Pub/Sub-Verfahren. Alle angebundenen Ressourcen haben einen einmaligen Ressourcen-Identifikator (URI), über den das Protokoll sie anspricht. Auf der Transportschicht nutzt CoAP meist UDP. TCP oder SMS sind ebenfalls möglich. Der Overhead von Meldungen ist sehr gering. Zum Protokoll gehören auch Ressourcenverzeichnisse und Discovery. Ein typische Anwendung sind drahtlose Sensornetze.
Auf CoAP basiert das sehr effiziente LwM2M (Lightweight Machine-to-Machine). Das Protokoll verfügt über einige Funktionen für die Geräteverwaltung und -bereitstellung, etwa zur Sicherung der Geräte oder Firmwareaktualisierung.
DDS (Data Distribution Service) wurde für Umfelder entwickelt, in denen sich Geräte genau koordinieren, Daten zuverlässig übertragen und verteilt verarbeitet werden. Hier werden Daten nicht über einen Broker zugänglich gemacht, sondern direkt zwischen den angebundenen Geräten verteilt beziehungsweise unter ihnen ausgetauscht. Das erhöht die Effektivität und die Robustheit der Verbindungen. Die Transportebne lässt sich über TCP, SMS oder UDP darstellen.
Das bidirektionale Websocket-Kommunikationsprotokoll transportiert große Datenmengen in Webanwendungen, würde also in Industrie-4.0-Umgebungen möglicherweise auf der Verbindung zum Daten verarbeitenden zentralen Server im Rechenzentrum zum Einsatz kommen. Geräte und Server senden und empfangen gleichzeitig in Echtzeit, also mehr oder weniger latenzfrei. Websocket verbindet Client und Server so, dass anschließend viele Pakete mit geringem Overhead über die Verbindung laufen können.
Protokolldschunmgel
Weitere bestehende Verbindungstechnologien und -protokolle, deren Namen immer wieder auftauchen dürften, sind:
- IO-Link, Modbus, Profibus, Devicenet, CAN (Controller Area Network), EtherCAT, HART und Wireless HART, RS232, und RS485 dienen der Kommunikation zwischen Sensoren und Aktoren untereinander oder mit übergeordneten Systemen.
- Auf der physischen Ebene finden auch im ddustriebereich heute häufig drahtlose Protokolle und Technologien wie LoRa, WiFi, diverse Mobilfunkprotokolle, NB-IoT Verwendung. Sie haben unterschiedliche Reichweiten und Transportraten.
- Ethernet/IP und seine Verwandten sind Ethernet-Abkömmlinge, die industriellen Anforderungen genügen. Jedes mit Ethernet ausgerüstete Gerät lässt sich damit in Industrienetze integrieren. Dazu gehört EtherCAT (Kommunikation zwischen Steuerungsgeräten und Feldsystemen).
Zenoh startet durch
Ganz neu ist Zenoh, ein offenes Protokoll für harte Echtzeitumgebungen. In der Industrie betrifft dies etwa Roboter und deren Vernetzung oder autonome Fahrzeuge, zum Beispiel im Lager. Im Unterschied zu den meisten anderen Protokollen wurde Zenoh von Grund auf neu entwickelt. Ziel war es, ein Protokoll zu entwerfen, das Daten, nicht Netzwerkhierarchien, in den Mittelpunkt stellt.
Denn die Netze mit ihren vielen Ebenen, die eine Information nach den üblichen Protokollregeln durchfließen muss, bis sie ihr Ziel erreicht, taugen nicht optimal. Sie sind zwar sehr nützlich, wenn es darum geht, verästelte Strukturen zu sortieren. Sie stehen einem beschleunigten Echtzeit-Datentransport aber im Weg, da die vielen Ebenen und großen Adressierungsheader eben auch ärgerliche Zeitverluste bedeuten. Die aber kann sich beispielsweise bei Schwarmsteuerungen in der Produktionshalle niemand mehr leisten.
Zenoh produziert minimalen Overhead. Seine Header sind vergleichsweise winzig und es kann mehrere Datenschnipsel mit dem gleichen Ziel in einem Paket zusammenführen. Es arbeitet wie HTTP/REST nach dem Publish/Query/Subscribe-Verfahren. Außerdem erlaubt es die anfrageorientierte Vorverarbeitung von Daten, wo sie sich befinden. Auch das minimiert die Datenmenge.
Von höheren Protokollebenen (ab Ebene 3) ist Zenoh unabhängig. Es passt sich dem an, was vorhanden ist. Auch die Topologie ist egal. Vom Baum bis zum Mesh funktioniert es überall. Das Protokoll benötigt lediglich eine funktionierende physische Verbindung. Das bedeutet: Die bisher ständig nötigen Umsetzungen entfallen ersatzlos. Dass das Protokoll im harten Echtzeitbereich seine Meriten hat, zeigt sich nicht zuletzt daran, dass Autosar (AUTomotive Open System ARchitecture) es bereits zertifiziert hat.
Initiative für Interoperabilität
Bei all diesem Durcheinander erfreut die Bestrebung der OPC-UA-Organisation, das Chaos im Industrienetz bis hin zum Endgerät transparenter und einfacher zu gestalten. Zu diesem Zweck wurde im Januar 2024 innerhalb der OPC Foundation eine neue Arbeitsgruppe gegründet, OPC UA FX (OPC-UA Field Exchange). Diese Gruppe soll ein standardisiertes Profil für Ein-/Ausgabegeräte der industriellen Automatisierung erstellen, sodass Remote-Geräte und Steuerungen untereinander und miteinander nahtlos kommunizieren können. Mehr als 30 Unternehmen beteiligen sich daran, weil diese wohl erkannt haben, dass das Wirrwarr im Netz langfristig den Fortschritt hin zu hochautomatisierten, sich selbst steuernden Systemen eminent behindert und verteuert.
Die Spezifikation soll Definitionen für typische Schnittstellen und Verhaltensweisen von Ein-/Ausgabegeräten enthalten. Der Standard wird wohl nach dem Pub/Sub-Verfahren arbeiten und lässt sich mit verschiedenen unterliegenden Protokollen und physischen Schichten wie UDP/IP oder Ethernet kombinieren. Er soll alle in OPC-UA heute üblichen Sicherheitsanforderungen erfüllen und zeitsensitiv gemäß Ethernet Time-Sensitive Networking (TSN) arbeiten, wo das nötig ist. Überlappungen mit anderen Informationsmodellen, die es schon gibt oder die in Arbeit sind, will PCI-UA FX mit einbeziehen.
Fazit
Industrielle Kommunikation bis hinunter in die Feldbusebene und bis hinauf in die Cloud ist mitnichten einfach und unkompliziert. Industrie-4.0-Konzepte verlangen hier neuartige Lösungen, die die Infrastruktur vereinfachen. Daher sind Initiativen wie OPC-UA FX sehr zu begrüßen. Bis sie Ergebnisse erzielt haben, müssen sich Unternehmen durch den Dschungel der Protokolle und Busse schlagen. Dabei sollten sie, wenn das eigene Know-how nicht reicht, auf jeden Fall den Rat erfahrener Partner suchen. Denn funktionierende Verbindungen sind die Voraussetzung für funktionierende Industrie-4.0-Projekte.
(ln)