2.000 Maschinen, 20 Milliarden Datenpunkte: Wo IIoT-Architektur schwierig wird

Industrial IoT wird zu einer anderen Ingenieursaufgabe, sobald vernetzte Anlagen Fabrikmaßstab erreichen. Hyundai Motor India verbindet im Werk Chennai bei Sriperumbudur sieben Fertigungsbereiche und mehr als 2.000 kritische Maschinen über mehr als 1.000 intelligente Sensoren. Daraus entstehen 20 Milliarden Datenpunkte pro Jahr. In dieser Größenordnung geht es nicht mehr um Konnektivität.

Hyundai Motor India liefert ein dokumentiertes Beispiel. Im Werk Chennai bei Sriperumbudur verbindet ein eigenes Netz sieben Fertigungsbereiche – im Werksjargon Shops, also Presswerk, Rohbau, Lackiererei und weitere Gewerke – und mehr als 2.000 kritische Maschinen über mehr als 1.000 intelligente Sensoren.

Der Börsenprospekt-Entwurf vom 14. Juni 2024 nennt 20 Milliarden Datenpunkte pro Jahr und die Echtzeit-Überwachung von mehr als 300 Prozessparametern über 150 Dashboards. Der Geschäftsbericht 2024/25 meldet später: Das IIoT-Netz deckt mehr als 86 Prozent der kritischen Maschinen in sieben großen Fertigungsbereichen ab, erzeugt mehr als 20 Milliarden Datenpunkte jährlich und wertet die Datensätze in Echtzeit über 200 Dashboards aus. Diese Zahlen beschreiben, was Hyundai offenlegt.

Die vollständige Netz-, Verarbeitungs- und Speicherarchitektur verraten sie nicht. Sie reichen aber, um die Fragen aufzuwerfen, die jede IIoT-Installation dieser Größe beantworten muss: Wo verarbeitet man die Daten? Wie behalten Messwerte ihren Kontext? Was muss man übertragen und speichern? Und wie schnell muss eine Information einen Anlagenbediener oder ein System erreichen?

Warum wird Datenvolumen zum Architekturproblem?

20 Milliarden Datenpunkte pro Jahr sind nicht nur eine Durchsatzzahl. Sie verändern die Arbeit, die nach der Messung beginnt. Ein Werk mit Tausenden Anlagen empfängt Temperatur, Druck, Strom, Schwingung, Taktzeit, Qualitäts- und Statusdaten – in unterschiedlichen Abtastraten und von unterschiedlichen Maschinentypen. Wer diese Werte einfach in ein zentrales System kippt, macht sie damit weder vergleichbar noch nutzbar. Die ersten Architekturfragen sind deshalb praktische:

• Datenerfassung: Wie kommen die Messwerte aus verschiedenen Maschinen und Systemen heraus?
• Normalisierung: Können Anwendungen die Werte über alle Anlagen hinweg einheitlich deuten?
• Verarbeitung: Was wertet man lokal aus, was wandert nach oben?
• Aufbewahrung: Muss jeder Messwert gleich lange in voller Auflösung bleiben?

Sieben Fertigungsbereiche und mehr als 2.000 Maschinen verschärfen jede dieser Fragen. Ein Entwurf, der für eine Maschine oder eine Fertigungszelle funktioniert, kann quer durch das Werk unwirtschaftlich werden.

Wie wird aus einem Messwert kontextualisierte Information?

Ein Sensorwert ist noch keine Information. Nehmen wir 87 °C. Die Zahl allein sagt nicht, ob ein Fehler vorliegt. Das System muss auch wissen, welche Anlage den Wert geliefert hat, zu welchem Teilsystem der Sensor gehört, wann die Messung stattfand, was die Maschine gerade tat und unter welchen Betriebsbedingungen sie lief. Im Fabrikmaßstab gehört dazu:

• Anlagen- und Sensorkennung
• Zeitstempel und Datenqualität
• Einheit und Messbereich
• Maschinenzustand und Betriebsart
• Fertigungslinie und Prozessschritt
• Anlagenhierarchie
• Produkt, Charge oder Fertigungsauftrag

Diese Hierarchie zählt, sobald Daten mehrere Fertigungsbereiche umfassen. Ein Temperatursignal bedeutet etwas anderes, je nachdem ob es von einem Motor, einer Hydraulik, einer Spindel oder einem anderen Teilsystem stammt.

Derselbe Parameter verlangt außerdem eine andere Deutung beim Anfahren, in der laufenden Produktion oder während der Wartung. Hier setzt die Informationsmodellierung an. Die OPC-UA-Spezifikation, der von der OPC Foundation gepflegte Interoperabilitätsstandard der Industrie, beschreibt einen AddressSpace: Objekte, Variablen und ihre Beziehungen bilden dort Struktur und Bedeutung ab, statt lose Werte auszugeben.

Reale Objekte lassen sich über Referenzen, typisierte Objekte und branchenspezifische Datendefinitionen verknüpfen. Bei Tausenden Maschinen liegt der Nutzen auf der Hand: Nachgelagerte Systeme arbeiten mit einer Anlage und ihren Beziehungen, statt diese Beziehungen jedes Mal aus rohen Tags zu rekonstruieren.

OPC UA oder MQTT? Die Schicht entscheidet

Beide Standards werden oft verglichen, als müsste sich eine Industriearchitektur für einen entscheiden. Das verfehlt ihre unterschiedlichen Rollen.

• OPC UA: zielt auf industriellen Informationsaustausch, Interoperabilität, strukturierte Modelle und Semantik. Der Standard umfasst AddressSpace-Modell, typisierte Objekte, Dienste, Events und mehrere Kommunikationswege.
• MQTT: liefert schlanke Publish/Subscribe-Kommunikation. Ein Sender schickt Nachrichten an einen Server, der sie an alle Clients mit passendem Abonnement verteilt. MQTT 5.0 definiert dazu drei Dienstgüten: höchstens einmal, mindestens einmal, genau einmal.

Damit lautet die Architekturfrage nicht, welches Protokoll besser ist, sondern wo welcher Mechanismus hingehört. Die maschinennahe Schicht profitiert von strukturierten Industriedaten und semantischen Beziehungen. Die nachgelagerte Transportschicht profitiert von der Entkopplung: Erzeuger müssen ihre Abnehmer nicht kennen.

Ein Gateway bildet die Grenze: Maschinensysteme → Industrieprotokoll/Datenmodell → Gateway → ausgewählte Telemetrie und Events → Messaging-Infrastruktur → Anwendungen Nicht jede Fabrik folgt genau diesem Muster. Hyundai legt in seinen öffentlichen Dokumenten nicht offen, welche Protokolle das Chennai-Netz tragen. Der Punkt bleibt: Bei mehr als 2.000 Maschinen wird die Protokollwahl zu einer Architekturentscheidung pro Schicht, nicht zu einem werksweiten Wettbewerb um das eine Protokoll.

Was bleibt am Edge, was wandert nach oben?

Die Frage nach Edge oder Cloud gewinnt an Gewicht, sobald das Datenvolumen schneller wächst als der Nutzen, jeden Rohwert zu transportieren. Das Prinzip lautet nicht, Edge schlage Cloud. Es lautet: Verarbeitung dorthin legen, wo Latenz, Bandbreite, Ausfallsicherheit und Rechenbedarf es nahelegen. Am Edge: Plausibilisierung, Filterung, Verdichtung, Pufferung und zeitkritische Ereigniserkennung passen oft nah an die Maschine. Weiter oben: linienübergreifende Korrelation, Langzeitanalyse, Modellentwicklung und Unternehmensberichte nutzen zentrale Infrastruktur.

Ein Beispiel sind hochfrequente Schwingungsdaten. Wer jede Rohsignalform dauerhaft nach oben schickt, erzeugt eine weit größere Transport- und Speicherlast, als wenn er ausgewählte Kennwerte überträgt. Eine Edge-Anwendung berechnet Merkmale wie Effektivwert, Spitzenwerte oder Frequenzband-Indikatoren.

Diese Kennwerte laufen fortlaufend nach oben, während das Rohsignal nur bei Auffälligkeiten oder für eine Untersuchung erhalten bleibt. Das NIST-Modell für Fog Computing nennt große, heterogene IoT-Umgebungen und Latenz als Gründe, Anwendungen und Analytik ins Netz zu verlagern, statt allein auf zentrale Cloud-Verarbeitung zu setzen.

NIST-Arbeiten zu Deep Learning am Edge im IIoT beschreiben ebenfalls, wie Rechenleistung nahe an der Datenquelle den Übertragungsbedarf senkt. Der Zusammenhang reicht über ein Werk hinaus. Die Marktforschung MarkNtel Advisors nennt die Fertigung als größtes Anwendersegment für Industrial IoT und die schnelle Verbreitung von Edge Computing als Chance, weil Industrieumgebungen große Mengen an Echtzeitdaten erzeugen. Hyundai zeigt konkret, warum dieses Architekturproblem überhaupt entsteht.

Wie beherrscht man Milliarden von Zeitreihen-Datensätzen?

Sobald Telemetrie Milliarden von Messwerten umfasst, wird die Speicherstrategie Teil der Architektur. Der Fehler wäre die Annahme, jeder Wert müsse für immer in gleicher Auflösung liegen bleiben. Ein praktikabler Datenlebenszyklus trennt nach Wert und Zugriffsmuster:

• Heiße Daten: aktuelle Messwerte, die Bediener und Anwendungen häufig abfragen.
• Verdichtete Daten: gröber aufgelöste Zusammenfassungen für Langzeittrends.
• Ereignisdaten: Störungen samt Umgebungskontext, aufbewahrt für die Analyse.
• Rohdaten: hochaufgelöste Messungen, dort aufbewahrt, wo diagnostischer oder regulatorischer Wert die Speicherkosten rechtfertigt.

Ein Schwingungssensor liefert über eine Schicht hinweg hochfrequente Werte. Eine Architektur behält die berechneten Kennwerte durchgehend und speichert das Rohsignal nur rund um relevante Ereignisse. Für andere Telemetrie gilt dasselbe. Routinewerte stützen Betriebstrends, ohne dass jeder Rohwert dauerhaft sofort abrufbar bleiben muss. Auch hier wirkt die Kontextualisierung auf den Speicher zurück.

Eine Zeitreihenabfrage lautet selten nur: alle Temperaturen. Nützlich ist eher: Zeige das Temperaturverhalten dieser Maschine, dieses Teilsystems, während dieses Produktionsintervalls, zusammen mit den zugehörigen Ereignissen. Je konsistenter Anlagen- und Prozesskontext vor dem Speichern anhängt, desto einfacher werden solche Abfragen über den gesamten Werksdatenbestand.

Warum hängt Echtzeit von der Entscheidung ab?

Echtzeit meint keine einheitliche Latenzvorgabe. Ein Maschinenregelkreis, ein Bediener-Dashboard und ein Produktionsbericht können dieselbe Telemetrie nutzen und dabei völlig unterschiedliche Antwortzeiten verlangen.

• Maschinensteuerung: Timing und Vorhersagbarkeit sind kritisch, weil das Ergebnis direkt den Anlagenbetrieb steuert.
• Zustandsüberwachung: Eine verzögerte Reaktion nützt weiterhin, wenn das Ziel darin besteht, einen sich anbahnenden Anlagenzustand zu erkennen.
• Bediener-Dashboards: Aktualität zählt, der Anspruch unterscheidet sich aber vom geschlossenen Regelkreis.
• Historische Analyse: Sekunden oder Minuten Verzug spielen keine Rolle, wenn es um Trends geht.

NIST hebt für die Fabrikautomatisierung hervor, dass Kommunikationsanforderungen zu Sensorik-, Roboter- und Maschinensteuerungsanwendungen passen müssen, und betont hohe Zuverlässigkeit, niedrige Latenz und Skalierbarkeit im industriellen Umfeld.

Hyundai beschreibt in seinem Geschäftsbericht außerdem KI-gestützte Bildverarbeitung, die Fehler im Antriebsstrangbereich in Echtzeit erkennt. Das erinnert daran, dass Echtzeit selbst innerhalb eines Werks verschiedene Lasten mit verschiedenen Architekturanforderungen bezeichnet. Die bessere Ingenieursfrage lautet deshalb: Welche Entscheidung steht an, und wie schnell muss die Information ankommen, damit sie diese Entscheidung noch trägt?

Wie wird aus Telemetrie ein handlungsfähiges Ereignis?

Der Weg von der Messung zur Handlung entscheidet über den Wert einer IIoT-Architektur. Zurück zu den 87 °C.

1. Prüfen: Ist der Wert plausibel? Ist der Sensor in Ordnung? Stimmt der Zeitstempel?
2. Einordnen: Welche Maschine, welches Teilsystem? Welche Betriebsart lief?
3. Vergleichen: Liegen 87 °C außerhalb des erwarteten Bereichs für diesen Maschinenzustand?
4. Korrelieren: Haben sich Druck, Schwingung, Stromaufnahme oder Taktzeit gleichzeitig verändert?
5. Klassifizieren: Normaler Übergang, Prozessabweichung oder möglicher Anlagenschaden?
6. Priorisieren: Nur Information, Warnung oder sofortiger Eingriff?
7. Handeln: Dashboard aktualisieren, Bediener alarmieren, Wartungsauftrag anlegen oder eine andere definierte Reaktion auslösen?

Diese Abfolge zählt, weil mehr Telemetrie nicht automatisch bessere Entscheidungen liefert. Eine Architektur, die jeden Wert weiterreicht, aber keinen Kontext herstellt, verschiebt das Datenproblem nur von der Werkshalle in ein Dashboard oder einen Data Lake. Das Ergebnis ist nicht der Rohwert. Es ist das kontextualisierte Ereignis, das einem System oder einem Menschen sagt, was sich geändert hat, warum es zählt und was als Nächstes geschehen soll.

Wie greifen die Schichten ineinander?

Eine IIoT-Architektur im Fabrikmaßstab lässt sich als Kette von Zuständigkeiten lesen:

• Maschinen und Sensoren: erzeugen Messwerte und Anlagenzustände.
• Industrieprotokolle und Gateways: öffnen den Zugang zu heterogenen Anlagen und Systemen.
• Edge-Verarbeitung: prüft, filtert, verdichtet, puffert und erkennt zeitkritische Zustände.
• Datentransport: verteilt ausgewählte Telemetrie und Ereignisse zwischen Erzeugern und Abnehmern.
• Kontextualisierung und Ereignisverarbeitung: hängt Anlagen- und Prozessbedeutung an und erkennt betrieblich relevante Zustände.
• Speicherung: hält Daten in passender Auflösung und für einen passenden Zeitraum vor.
• Analytik: verbindet aktuelle und historische Daten, um Muster und Zusammenhänge zu finden.
• Dashboards und Betriebssysteme: liefern Ergebnisse an Bediener, Ingenieure und nachgelagerte Abläufe.

In einem Werk mit Tausenden vernetzten Maschinen sind das keine bloßen Softwarekästchen. Sie legen fest, wo Bedeutung entsteht, wo Daten schrumpfen, wo Ausfallsicherheit greift und wo Entscheidungen fallen.

Fazit

Hyundai Motor India macht das Skalierungsproblem ungewöhnlich greifbar: mehr als 2.000 kritische Maschinen in sieben Fertigungsbereichen, mehr als 20 Milliarden Datenpunkte pro Jahr und zuletzt eine gemeldete Abdeckung von mehr als 86 Prozent der kritischen Maschinen. Die Ingenieursaufgabe in dieser Größe besteht nicht darin, noch mehr Telemetrie einzusammeln. Sie besteht darin, Bedeutung über Tausende Anlagen hinweg zu erhalten, für jede Schicht den passenden Kommunikationsmechanismus zu wählen, die Verarbeitung am Edge richtig zuzuschneiden, die Aufbewahrung nach Wert zu staffeln und die Latenz an die jeweilige Entscheidung zu binden. Genau das muss IIoT-Architektur im Fabrikmaßstab lösen.

- Advertisement -