Industrial IoT & Edge-Integration

Was umfasst Industrial IoT und Edge-Integration?

Industrial IoT und Edge-Integration umfasst alles zwischen der Steuerungsebene einer Maschine und den IT-Systemen, die ihre Daten nutzen.

Dazu gehören Erfassung, Vereinheitlichung, ein für die Zielsysteme geeignetes Datenmodell, der Transport in Richtung IT-Systeme (im Englischen „Northbound“) und die IT-Sicherheit und Compliance, ohne die keine dieser Daten das Werk verlassen darf. Es gibt drei Einstiege in diese Arbeit: die Nachrüstung von Linien, die nicht stillstehen dürfen, die Edge-Integration in Produkte, die gerade entwickelt werden, und das CRA-Audit für Industriegeräte, die unter den CRA fallen, sobald ihr bestimmungsgemäßer Gebrauch eine Datenverbindung umfasst. Diese Seite behandelt den Weg der Daten zu MES, ERP und Cloud. Die Geräte- und Netzwerkintegration behandelt den Weg zwischen Geräten, von Protokoll zu Protokoll.

Unser Team hat OPC-UA-zu-MQTT-Konnektoren für eine Fernservice-Plattform an Landmaschinen gebaut, OPC UA in Azure integriert, Node-RED-Module in die Cloud eines Kunden geliefert und ein zentrales Gateway entwickelt, über das jedes entfernte ERP Live-Daten mehrerer Maschinen per OPC UA abruft. Es ersetzt die bisherige MQTT-Brücke des Kunden. Typische Projekte sind:

• Ein Edge-Gateway oder Edge-Gerät, als Thin oder Thick Edge, je nachdem, wo die Verarbeitung hingehört.
• Eine Brücke zwischen zwei Datenwelten: OPC UA zu MQTT, OPC UA zu HTTP/REST oder ein Gateway von DDS zu OPC UA.
• Eine laufende Linie anbinden: Nachrüstung von Gateways an Bestandsanlagen, ohne Steuerungen zu tauschen.
• Der Schritt ins Unternehmen: Integration von OT in MES und ERP über Edge-Gateways und die OT/IT-Architektur dazu.
• Cloud-Telemetrie und Steuerbefehle: Maschinendaten in die Cloud und Befehle zurück zum Gerät.
• Ein Audit: Sicherheitsaudit für Industriegeräte nach IEC 62443 und Bewertung des CRA-Konformitätsstands eines bereits ausgelieferten Produkts.

Ein gewachsener Bestand muss seine Daten hergeben, ohne ersetzt zu werden. Ein neues Produkt muss von Anfang an vernetzt und konform sein. Oder ein bereits vernetztes Produkt muss gegen Pflichten geprüft werden, die erst nach seiner Auslieferung entstanden sind.

Die Inbetriebnahme der Anlage übernehmen wir nicht. Wir bauen einen Proof of Concept, machen daraus eine einsatzfähige Lösung und übergeben sie an den, der die Inbetriebnahme verantwortet. Während Integration und Test arbeiten unsere Ingenieure mit Ihren zusammen.

Welche Anforderungen stellt der Cyber Resilience Act an vernetzte Produkte?

Der CRA verlangt einen sicheren Update-Weg, ein Verfahren für den Umgang mit Schwachstellen und eine erzeugte Software-Stückliste (SBOM), und zwar für den gesamten Unterstützungszeitraum des Produkts.

Die Verordnung (EU) 2024/2847 gilt für Produkte mit digitalen Elementen, die in der EU in Verkehr gebracht werden. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle nach Artikel 14 gelten seit dem 11. September 2026; grundsätzlich gilt die Verordnung ab dem 11. Dezember 2027. Alle drei Anforderungen müssen im Feld funktionieren: der Update-Weg auf Geräten, die schon ausgeliefert sind, das Schwachstellenverfahren mit einer verantwortlichen Person dahinter und die Software-Stückliste, die erzeugt und nicht von Hand gepflegt wird.

Das Thema steht auf dieser Seite und nicht auf einer Compliance-Seite, weil erst die Datenverbindung im bestimmungsgemäßen Gebrauch eine Maschine in den Geltungsbereich bringt. Ein CRA-Audit für Industriegeräte wird deshalb meist zusammen mit dem Vernetzungsprojekt beauftragt, und den Update-Weg in diesem Projekt einzubauen ist weit günstiger, als ihn später in eine ausgelieferte Flotte nachzurüsten. Wir prüfen und beheben die Lücken, zertifizieren aber nicht. Eine notifizierte Stelle ist für wichtige Produkte der Klasse II und für kritische Produkte erforderlich, außerdem für wichtige Produkte der Klasse I, wenn keine harmonisierten Normen angewandt werden. Für kritische Produkte kann stattdessen ein europäisches Cybersicherheitszertifikat nötig sein.

Wie lässt sich eine Produktionslinie ohne Stillstand nachrüsten?

Die Nachrüstung läuft neben den Steuerungen und nie im Steuerungspfad, deshalb produziert die Linie weiter.

Sie ergänzt nur: Die OPC-UA-Anbindung bestehender Fertigungslinien entsteht neben den Steuerungen und nicht durch sie hindurch. Sie liest, was schon da ist, und gibt es an die IT-Systeme weiter. Am Steuerungsverhalten der Maschine ändert sich nichts, und deshalb lässt sich die Änderung in einem Wartungsfenster einplanen und braucht keinen Stillstand. Gibt es schon einen Datenweg, etwa eine ältere MQTT-Brücke, wird er schrittweise ersetzt: Der neue Weg liest parallel mit, läuft eine Zeit lang neben dem alten, der führend bleibt, und übernimmt dann in einem geplanten Fenster. Der alte Weg bleibt als Rückfallebene erhalten.

• Der gewachsene Bestand. Er stammt meist von mehreren Herstellern und aus mehreren Generationen und ist kaum dokumentiert. Die Integration beginnt deshalb mit der Frage, was tatsächlich in der Halle steht. Kann eine Steuerung die nötigen Daten nicht liefern, erfasst sie stattdessen ein Edge-Gerät auf der Feldseite direkt am Gerät.
• Ein Unified Namespace. Sollen die Daten über die reine Verbindung hinaus vereinheitlicht werden, gibt ihnen ein Unified Namespace über alle Standorte eine einheitliche Struktur. Diese Struktur richtig anzulegen ist zuerst Modellierungsarbeit und erst danach Infrastruktur, und sie greift direkt auf die Informationsmodellierung mit OPC UA zurück.

Was ist bei einer Neuentwicklung anders als bei einer Nachrüstung?

Bei einer Neuentwicklung verschiebt sich die Kostenrechnung: Datenmodell, IT-Sicherheit und Update-Weg gleich mit zu entwerfen kostet einen Bruchteil der späteren Nachrüstung.

Datenmodell, IT-Sicherheit und Update-Weg sind eine Entwurfsfrage, nicht drei, weil jede die anderen begrenzt. Was ein Gerät meldet, bestimmt, was ein sicheres Update anfassen muss, und beides bestimmt, welche Nachweise ein CRA-Audit später verlangt.

Bei Neuentwicklungen wird hier oft zu wenig investiert, in der Annahme, die Vernetzung lasse sich am Ende ergänzen. Das geht, aber die Nachrüstung kostet deutlich mehr, besonders wenn eine CRA-Pflicht auf eine Flotte ohne Update-Mechanismus trifft.

Wann reicht ein Standard-Edge-Gateway aus?

Ein Standard-Gateway reicht, wenn das Protokollpaar üblich ist und am Datenmodell nichts entworfen werden muss.

Hersteller wie Hilscher und HMS Networks (Anybus) verkaufen Edge-Gateways für die gängigen Kombinationen von Feldbus zu MQTT und Feldbus zu OPC UA. Für eine einzelne Maschine mit einem bekannten Protokoll ist ein Katalogteil meist die richtige und oft die günstigere Wahl. Auch die Empfehlung eines Standard-Gateways kann das Ergebnis der Bestandsaufnahme sein, und wir sagen das, bevor die Entwicklung beginnt. Steht der Preis im Vordergrund, ist ein reiner Software-Konnektor auf vorhandener Hardware eine dritte Möglichkeit und oft günstiger als beide. Eine Eigenentwicklung lohnt sich, wenn einer von drei Punkten zutrifft:

• Für die nötige Protokollkombination gibt es kein passendes Standardprodukt.
• Das Gateway soll in Ihrem Produkt sitzen, mit Ihrem Service dahinter, und nicht als Fremdteil daneben im Schaltschrank.
• Das Datenmodell muss für das Zielsystem entworfen werden und nicht aus den Standard-Tags der Steuerung entstehen.

Die entsprechende Frage zwischen Geräten, von Protokoll zu Protokoll, beantwortet die Seite zur Geräte- und Netzwerkintegration.

Welche Datenverarbeitung gehört an die Edge, welche in die Cloud?

Die Grenze richtet sich nach Latenz, Bandbreite und der Frage, wo das Vertrauen enden muss.

Ob Thin oder Thick Edge, entscheiden diese drei Faktoren und nicht eine Produktkategorie. Eine Thin Edge erfasst und transportiert, ausgewertet wird in der Cloud. Eine Thick Edge wertet vor Ort aus und sendet die Ergebnisse. Die meisten Systeme liegen zwischen diesen beiden Mustern, und wo die Verarbeitung stattfindet, kann sich im Lauf des Produktlebenszyklus ändern. Deshalb behandeln wir Edge und Cloud als Kontinuum und nicht als zwei feste Orte.

Am häufigsten bauen wir die einfache Variante: an der Maschine erfassen, an der Edge normalisieren, lokal puffern, damit ein Verbindungsausfall keine Daten kostet, und in die Cloud mit einem Datenmodell senden, das für das Zielsystem entworfen ist und nicht die Rohwerte der Sensoren weiterreicht. Der Rückweg, also Befehle von der Cloud zum Gerät, bekommt mehr Entwurfsaufwand als die Telemetrie, weil ein Befehl den Zustand einer Maschine ändert und ein Messwert nicht.