Ist IT/OT-Konvergenz nur ein Buzzword? Der wahre Wert dahinter

Also, ist „IT/OT-Konvergenz“ nur ein weiterer gimmickiger Buzzword-Begriff?

Man könnte argumentieren, dass dem so ist. Sobald jemand eine neue Idee aufgreift, wird versucht, sie einprägsam zu machen und als „das Beste seit geschnittenem Brot“ zu verkaufen. Natürlich kommt jemand mit einem eingängigen Begriff, der Veränderung inspirieren und für Marketing nutzbar sein soll.

Aber: Diese „Konvergenz“ von IT und OT ist tatsächlich nur der nächste logische Schritt, Daten nutzbar zu machen.

Was ist IT/OT-Konvergenz?

Vor einiger Zeit begann die Automation in der Fertigung. Automatisierte Anlagen wurden für Funktionen entworfen, die Geschwindigkeit oder Leistung erforderten, die Menschen nicht leisten konnten. Bei Ausfall musste der Steuerungstechniker ins System, um die Ursache zu finden – in die Register der SPS-Systeme. Das war der Start der Operational Technology (OT) Datennutzung.

Daten vor dem Ausfall waren gut für Diagnostik – um zu sehen, was vorher passierte. Daraufhin nutzten SPS-Systeme Historian für längere Datensströme von Sensoren, Heizungen, Aktoren – mit großen OT-Datenmengen.

Durch Monitoring der OT-Daten aus Historian konnten SCADA-Funktionen Operatoren Einblicke in den Anlagenzustand geben. Bei drohendem Ausfall erlaubten SCADA-Funktionen Operatoren/Supervisoren, vor dem Ausfall einzugreifen. Dies erforderte SCADA-Zugriff auf Historian-Daten über proprietäre Kommunikation wie MODBUS oder PROFIBUS, um Daten über HMIs bereitzustellen. Das Monitoring blieb exklusiv auf Anlagenperformance beschränkt – weitere OT-Datennutzung.

Durch Beobachtung dieser Datenströme (Anzeigen, Operator-Screens etc.) und Verständnis der Datendrift konnte man via SCADA nicht nur drohende Anlagenausfälle erkennen, sondern die Daten auch nutzen, um Produktqualitätsfehler bei Test und Inspektion – mehrere Prozessschritte später – zu analysieren.

Das schuf den Bedarf, OT-Daten mit IT-Daten zu verknüpfen. Es entstanden komplexe Schnittstellen von SPS/SCADA zu IT-Systemen wie MES, um relationale Produktfehlerdaten mit operativen Anlagendaten zu verknüpfen. Manche versuchten direkten ERP-Zugriff (und tun es noch), aber ERP-Systeme sind nicht dafür ausgelegt, diese Daten schnell und detailliert genug im Kontext anderer Fertigungsereignisse zu verarbeiten und darzustellen.

Das Problem der MES-Schnittstellen: Sie sind hochgradig individualisiert und teuer, manchmal 40–50 % der Implementierungskosten. Der nächste Schritt: SPS-Daten für MES und andere relationale Datenbanken zugänglicher machen. Kombiniert mit sinkenden Rechen- und Speicherkosten und stabilerer Netzwerkkommunikation (5G) ergab es Sinn, SPS-Sensoren und -Aktoren direkt an IT-Netze anzubinden (IIoT) und ihre Daten für – wer auch immer sie brauchte – verfügbar zu machen.

Dieser Hintergrund soll verdeutlichen: OT-Daten für IT-Systeme leichter zugänglich zu machen, ist einfach der nächste Schritt in einem längeren Prozess der Technologieevolution, der uns zu Industrie 4.0 brachte.

Wie kann IT/OT-Konvergenz genutzt werden?

Die Anbindung von OT-Daten an IT-Systeme stieß auf ein neues Problem.

SPS/SCADA-Systeme, die Sensoren in Historian überwachen, erzeugen riesige Datenströme (Megabytes) in Sekunden. Für das Verständnis der Ereignischarakterisierung zurück zu IT-Systemen ist dieser Strom – auch in kleinen Zeitfenstern – schlicht zu viel für relationale Datenbanken von IT-Systemen wie MES. Viele Implementierungen versuchten, eine Instanz von Sensordaten (aus dem Strom) aufzuzeichnen, um ein einzelnes Datenelement zu erfassen und OT-Ereignisse auf IT-Ebene abzubilden. Viele stellten jedoch fest, dass das Verknüpfen einer OT-Dateninstanz mit einem Qualitätsereignis während der Fertigung nicht sehr effektiv für generelles Prozessqualitätsmonitoring ist.

Wir müssen nun Wege finden, Datenströme aus OT-Systemen zu aggregieren, wobei die wichtigen Charakteristika eines Produktionsereignisses erhalten bleiben. OEE-Reporting ist ein solcher Aggregationsversuch. Wichtig: Bei jeder Datenaggregation gehen wichtige Details eines Qualitätsereignisses verloren. Deshalb ist OEE ein Monitoring-Level-Datenobjekt, kein Analyse-Level-Objekt. Doch durch Monitoring des Echtzeit-OEE-Werts kann ein IT-System Änderungsrate und -magnitude erkennen und Alarm auslösen.

Zur Analyse des eigentlichen Problems muss man zum Originaldatenstrom zurück, der den OEE-Wert erzeugte. Zumindest mit Echtzeit-OEE erhalten Fertigungs- und Steuerungstechniker frühzeitig Sicht auf Probleme, bevor der Ereignisstrom im OT-Datenstrom begraben wird.

Die Frage bleibt: Wie aggregieren Sie die Daten?

Die Antwort, wie immer: Es kommt darauf an!

Die Aggregationsmethode hängt ab von den zu aggregierenden Daten, dem Überwachungsziel im Prozess und der Interpretierbarkeit von Änderungen im Aggregationsmodell.

In diesem Abschnitt betrachte ich eine Aggregationsmethode und zeige Interpretationsmöglichkeiten.

Die „natürliche Verteilkurve“ (Histogramm) ist eine der häufigsten grafischen Darstellungen von Sensordaten. Die Grundprämisse: Wenn nur normale Zufallsvariation im Prozess vorliegt, fällt die Verteilung der Dateninstanzen in ein Muster, das einer Normalverteilungskurve ähnelt.

Abbildung 1 zeigt, wie die Verteilung von Ofensensor-Messwerten bei normaler Variation im Histogramm aussehen könnte.

Abbildung 1: Verteilkurve der Ofentemperatur mit Mittelwert, Median, Modus. Courtesy of the author.

Das Schlüsselmerkmal der Kurve: Mittelwert (Average), Median (Mittelwert des Datenstroms) und Modus (häufigster Wert) sind alle annähernd gleich. Dies dient als Referenz zur Problemerkennung. Solange der Prozess unter Kontrolle ist, ist es wertvoll, ±3-Sigma-Werte zu bestimmen und mit oberen/unteren Kontrollgrenzen und Produktspezifikationsgrenzen zu vergleichen.

Beispielszenario

Zur Überwachung einer Produktionseinheit im Härteofen notiert das MES Ein- und Austrittszeit. Währenddessen erzeugt das SPS-System (mit Smart Sensor) einen konstanten Temperatursensordatenstrom, gespeichert in einem lokalen Historian im Sensorgehäuse. Beim Austritt fordert das MES eine Aggregation der Temperaturdaten für den definierten Zeitraum an. Selbst mit begrenzter Rechenleistung am Gerät kann dieses Hunderte (oder Tausende) Datenpunkte nehmen und einen aggregierten Datensatz an das MES zurückgeben – statt einer einzelnen Sensordinstanz oder dem Versuch, den gesamten Strom zu verarbeiten.

Ein aggregierter Datensatz für diese Produktionseinheit wäre:

• Mittelwert: 90,0
• Median: sehr nahe an 90,0
• Modus: ca. 90,0 Grad
• ±3-Sigma-Verteilung: 87,0 / 93,0 (mit UCL/LCL abzugleichen)

Durch schnelle Analyse der Differenzen zwischen Mittelwert, Median und Modus kann das MES auf akzeptables Prozessmonitoring und Trendänderungen gegenüber vorherigen Einheiten prüfen. Liegen ±3-Sigma-Werte außerhalb akzeptabler Grenzen, flaggt das MES die Einheit als verdächtig – ebenso bei signifikanten Abweichungen der Statistiken voneinander oder von Vorprodukten.

Abbildung 2 zeigt, wie dieselben Werte einen nicht beherrschten Prozess anzeigen. Auch hier könnten ±3-Sigma-Werte theoretisch noch innerhalb der Limits liegen.

Abbildung 2: Beispiel für Differenzen von Mittelwert, Median, Modus bei schiefem Prozess. Courtesy of the author.

Technisch sind bei schiefer Verteilung ±3-Sigma-Werte möglicherweise nicht valide. Doch die sofortige Analyse am Gerät kann trotzdem Kontrollgrenzverletzungen erkennen.

Der Kernpunkt: Liefert ein smarter Sensor solche Datensätze, ist das ein Hinweis an das Fertigungsengineering, dass der Ofen nicht nur mit zufälliger Varianz operiert – und untersucht werden sollte.

Andere Differenzen (z. B. Mittelwert = Median, aber Modus abweichend) können auf Bedingungen wie bimodale Verteilungen hinweisen, die mehrfache Prozesseinflüsse suggerieren. Auch hier: Fertigungsengineering sollte prüfen.

Werden diese Datensätze direkt mit der Produktionseinheit auf MES-Ebene verknüpft, können sie – mit Test- und Inspektionsergebnissen – aufzeigen, ob ein Zusammenhang zwischen Ofentemperaturschwankungen und Produktionsfehlern besteht.

Ob das Produkt durch Prozessprobleme versagte oder nicht: Driftende Datenwerte während eines Produktionslaufs können auch fundamentale Prozessmanagement-Probleme anzeigen, die untersucht werden müssen.

Zusammenfassung

Die obigen Aggregationsbeispiele reflektieren nur ein spezifisches Szenario, sollen aber einen Einblick in die Gründe für die Konvergenz von OT- und IT-Daten sowie den potenziellen Wert dieser Konvergenz geben. In jedem Produktionsszenario muss die korrekte Aggregationsmethode evaluiert und die Programmierung smarter Geräte diese Funktionalität bereitstellen. Alternativ würden Edge-Computing-Systeme die beschriebenen Smart-Device-Funktionen ersetzen.

Die Quintessenz: Obwohl die Industrie „IT/OT-Konvergenz“ stark als Buzzword für Technologiewandel nutzt, gibt es eine legitime Änderung in der Datenverarbeitung, die die Technologie hinter dem Buzzword liefert. Unternehmen, die die Konvergenztechnologie nutzen und lernen, OT-Daten richtig zu aggregieren und zu interpretieren, gewinnen praktische Vorteile in der Effektivität von Qualitäts- und Anlagenmanagement. In der heutigen wettbewerbsintensiven globalen Umgebung ist jeder Vorteil gut für das Ergebnis.

Die Antwort lautet also: Nein. IT/OT-Konvergenz ist nicht nur ein Buzzword. Es ist ein wertvolles Werkzeug in der Evolution der Datenerfassung und -management-Technologie, das Fertigungsunternehmen 크게 nutzen können. Zu lernen, wie man OT-Daten so aggregiert, dass IT-Systeme damit umgehen können, ist ein wichtiger Teil der Konvergenz.