Industrielles IoT in der Praxis: Was Pilotprojekte von Großprojekten unterscheidet

Bei industriellen IoT-Projekten gibt es ein wiederkehrendes Muster, das jeder Automatisierungsingenieur nach ein paar Jahren seiner Karriere erkennt: Der Pilot funktioniert. Die zehn Sensoren senden, das Dashboard zeigt die Daten in Echtzeit an, der Werksleiter ist begeistert und gibt die Erweiterung frei. Sechs Monate später, wenn zweihundert Sensoren installiert sind, beginnt das System Daten zu verlieren, die Latenz steigt, Warnungen kommen nicht mehr zur richtigen Zeit an und das IT-Team streitet mit dem Automatisierungsteam darüber, wer für welchen Teil der Infrastruktur verantwortlich ist. Erweiterungsstände. Das Projekt bleibt in der Schwebe. Die Investition bringt nicht die erwartete Rendite. Was Unternehmen, die das industrielle IoT skalieren können, von solchen unterscheidet, die in der Pilotphase stecken, ist nicht die Technologie – es ist eine architektonische Entscheidung, die vor der Installation des ersten Sensors getroffen wird.

Das Netzwerkproblem, das der Pilot nicht verrät

Industrielle Umgebungen wurden für die Zusammenarbeit mit OT-Netzwerken (Operational Technology) konzipiert, die physisch und logisch von den IT-Netzwerken des Unternehmens getrennt sind. Diese Trennung hat eine historische Berechtigung: SCADA-Systeme, SPS und Feldnetzwerke wie Profibus und Modbus wurden für deterministische Zuverlässigkeit in Umgebungen mit elektromagnetischen Störungen konzipiert, nicht für IP-Konnektivität mit der Außenwelt. Das Ergebnis ist, dass die meisten Industrieanlagen über ein seit Jahren problemlos funktionierendes OT-Netzwerk und ein unternehmensweites IT-Netzwerk verfügen, das Computer, Drucker und Managementsysteme verbindet. Beim industriellen IoT müssen beide miteinander reden, und bei diesem Prozess stoßen die meisten Projekte auf Probleme.

OT/IT-Konvergenz ist kein Kabel und ein Schalter. Es handelt sich um ein Sicherheits-, Governance- und Architekturprojekt, bei dem Entscheidungen darüber getroffen werden müssen, welche Daten mit welcher Häufigkeit, mit welchem Übersetzungsprotokoll und mit welchem Authentifizierungssystem den Perimeter zwischen den beiden Umgebungen passieren können. In einem Pilotprojekt mit zehn Sensoren ist es möglich, einen Workaround zu schaffen – ein Gateway, das Sensordaten aufnimmt und an das IT-Netzwerk veröffentlicht, ohne das OT-Netzwerk zu berühren. Im großen Maßstab führt dieser Workaround zu Single Points of Failure, Latenzproblemen und Angriffsflächen, die weder OT- noch IT-Teams verwalten möchten.

Vor dem Pilotprojekt wird die richtige Entscheidung getroffen: die Definition der vollständigen Netzwerkarchitektur für den Zielmaßstab, einschließlich des Segmentierungsmodells, der Kommunikationsprotokolle zwischen den Schichten und des Governance-Modells dafür, wer was betreibt. Die meisten Unternehmen treffen diese Entscheidung nach dem Pilotprojekt, wenn auf beiden Seiten der OT/IT-Kluft bereits Termindruck und interne Widerstände bestehen.

Datenvolumen: Was wo und wann verarbeitet werden soll

Ein hochfrequenter Lagerschwingungssensor kann zwischen 5 und 50 Megabyte Daten pro Stunde erzeugen. Eine Computer-Vision-Kamera zur Qualitätsprüfung kann Gigabyte pro Stunde erzeugen. In einem Projekt mit Hunderten von Überwachungspunkten wird die Übertragung von Daten an die zentrale Cloud mathematisch schnell undurchführbar – sowohl im Hinblick auf die Bandbreitenkosten als auch im Hinblick auf die Latenz für Anwendungen, die eine Reaktion in Echtzeit erfordern.

Vor der Skalierung der Infrastruktur muss entschieden werden, wo verarbeitet werden soll. Das allgemeine Modell, das im großen Maßstab funktioniert, verteilt die Verarbeitung auf drei Ebenen: Auf dem Gerät selbst oder auf einem lokalen Gateway findet eine Filterung und Vorverarbeitung statt, die redundante Daten eliminiert und Ereignisse erkennt, die sofortiges Handeln erfordern. Auf einer Edge-Ebene – Servern in der Fabrikhalle oder in einem technischen Lager – findet die komplexeste Analyseverarbeitung statt, die kein Senden an die Cloud erfordert, einschließlich Anomalieerkennungsmodellen, die eine geringe Latenz erfordern. Die zentrale Cloud beherbergt den Verlauf, das Modelltraining, die Korrelation zwischen mehreren Anlagen und Executive-Dashboards.

Diese Aufteilung erscheint offensichtlich, wenn man sie so beschreibt, aber die meisten Pilotprojekte sind darauf ausgelegt, alles in die Cloud zu schicken, weil dies die einfachste Möglichkeit ist, das Konzept zu demonstrieren. Wenn das Projekt skaliert und die Kosten für die Datenübertragung auf der Cloud-Rechnung erscheinen oder wenn die Antwortlatenz nicht den betrieblichen Anforderungen entspricht, würde die Neugestaltung der Architektur doppelt so viel kosten, als wenn sie von Anfang an durchgeführt worden wäre.

Geräteverwaltung: das Problem, das mit dem Quadrat wächst

Die Installation von hundert Sensoren ist ein Ingenieursprojekt. Die Verwaltung von hundert Sensoren über einen Zeitraum von drei Jahren ist ein einziger Vorgang. Der Unterschied zwischen beiden liegt in einer Reihe von Herausforderungen, die in der Demo nicht auftauchen: Aktualisieren der Firmware auf Geräten im Feld ohne Betriebsunterbrechung, Austausch defekter Geräte ohne Verlust des Konfigurationskontexts, Bereitstellung neuer Geräte in akzeptabler Zeit und Überwachung des Zustands der Geräteflotte, um Fehler zu erkennen, bevor Daten verloren gehen.

Bei Projekten, die Tausende von Geräten ohne eine angemessene Verwaltungsplattform erreichen, stellt sich heraus, dass die Betriebskosten für die Wartung der Flotte den Nutzen der Analysen, die das Projekt liefern sollte, überwiegen. In einer Anlage mit tausend Sensoren bedeutet eine Defektrate von 5 % pro Jahr – konservativ für Hardware in einer industriellen Umgebung – fünfzig Austausche pro Jahr. Wenn der Austauschprozess die manuelle Konfiguration jedes Geräts erfordert, ist das Ingenieurzeit, die nicht im Budget enthalten war.

IoT-Geräteverwaltungsplattformen – AWS IoT Device Management, Azure IoT Hub oder Lösungen wie Balena für eingebettete Linux-Umgebungen – existieren genau zur Lösung dieses Problems. Die Entscheidung, sie bereits in der Pilotphase zu übernehmen, ist jedoch mit Implementierungskosten verbunden, die nur selten im Budget für den Machbarkeitsnachweis enthalten sind. Das Ergebnis ist, dass das Pilotprojekt manuelle Konfigurationen und selbst erstellte Skripte verwendet. Wenn das Projekt skaliert wird, muss die Migration auf eine geeignete Plattform mit Geräten erfolgen, die sich bereits im Feld befinden, was wesentlich komplexer ist als die Implementierung der Plattform von Grund auf.

Sicherheit in OT-Umgebungen: ein anderes Problem als die Unternehmens-IT

Die Sicherheit von OT-Netzwerken wurde in der Vergangenheit durch physische Isolation gelöst – was von außen nicht zugänglich ist, kann von außen nicht angegriffen werden. Das industrielle IoT verbindet diese Umgebung mit der Außenwelt, und Geräte, die der OT-Umgebung hinzugefügt werden, wurden selten mit der gleichen Sicherheitsgenauigkeit entwickelt wie bereits vorhandene Industriegeräte. Ein über IP erreichbarer Temperatursensor mit veralteter Firmware ist ein Angriffsvektor, den es vor zehn Jahren noch nicht gab.

Die Implikationen sind konkret. Der Angriff auf Colonial Pipeline im Jahr 2021 hat die OT-Systeme nicht direkt gefährdet, aber das Unternehmen hat die Systeme aufgrund mangelnder Transparenz und fehlendem Vertrauen in die Integrität des Netzwerks präventiv abgeschaltet. In Brasilien sind Kraftwerke, Wassersysteme und Energieverteilung zunehmend gefährdet, da sie immer mehr Geräte mit der industriellen Umgebung verbinden. Die Kosten eines OT-Sicherheitsvorfalls sind nicht nur Produktionsausfälle, sondern auch der Vertrauensverlust in die Integrität historischer Daten, der alle Analysen, die das IIoT-Projekt erstellt hat, ungültig macht.

Das Sicherheitsmodell für das industrielle IoT muss eine Netzwerksegmentierung umfassen, die den Wirkungsradius eines kompromittierten Geräts begrenzt, eine Geräteauthentifizierung per Zertifikat oder Token, die verhindert, dass ein nicht autorisiertes Gerät in das Netzwerk gelangt, und eine Überwachung des anomalen Datenverkehrs, die nicht standardmäßiges Geräteverhalten erkennt. Dies unterscheidet sich im Prinzip nicht vom IT-Sicherheitsmodell für Unternehmen – es unterscheidet sich jedoch in der Ausführung, da die OT-Protokolle, die akzeptable Latenz für Sicherheitsscans und die verfügbaren Tools spezifisch für die industrielle Umgebung sind.

Das skalierbare Architekturmuster: Was erfolgreiche Unternehmen anders machen

Unternehmen, die das industrielle IoT erfolgreich skalieren, haben eines gemeinsam: Sie treffen die vollständige Architekturentscheidung, bevor sie den ersten Sensor installieren, und sie betrachten das Pilotprojekt als Validierung der Architektur, nicht als Demonstration der technologischen Leistungsfähigkeit. Der Pilot soll nicht beweisen, dass Sensoren funktionieren – das ist bereits bekannt. Im Rahmen des Pilotprojekts soll überprüft werden, ob die gewählte Netzwerkarchitektur, Verarbeitung, Geräteverwaltung und Sicherheit den angestrebten Umfang bewältigen können.

Das andere gemeinsame Element ist die explizite Entscheidung darüber, wer die einzelnen Schichten des Systems betreibt. In industriellen Umgebungen ist die Grenze zwischen IT und OT sowohl eine kulturelle als auch eine technische Grenze. Projekte, die nicht explizit definieren, welches Team was betreibt – und die kein Eskalationsmodell für Konflikte zwischen den beiden Teams erstellen – stellen im großen Maßstab fest, dass das Problem nicht in der Technologie, sondern in der Governance liegt. Wer ist für den Vibrationssensor verantwortlich? Von wem wird das Edge-Gateway verwaltet? Wie läuft der Diagnoseprozess ab, wenn die Daten das Dashboard nicht erreichen, und wann wird das Ticket von einem Team zum anderen weitergeleitet?