Skip to content
RiverCore
Zurück zu ArtikelnENGINEERING
Observability überschreitet die IT/OT-Grenze: MQTT, OPC und der neue Telemetrie-Stack
IT OT observabilitytelemetry stackindustrial IoTunified MQTT OPC telemetry platformIT OT convergence engineering

Observability überschreitet die IT/OT-Grenze: MQTT, OPC und der neue Telemetrie-Stack

25 Apr 20266 Min. LesezeitSarah Chen

Eine Plattform, die gleichzeitig Server, Kubernetes-Cluster, Geldautomaten-Hardware, Anästhesiegeräte und Kühl-LKW überwacht. Das ist der Vorschlag, den ATS Network Management aus Johannesburg auf den Tisch legt – und er stellt eine bedeutende Erweiterung dessen dar, was der Begriff „Observability" im letzten Jahrzehnt bedeutet hat. Der Pitch trifft auf einen Moment, in dem die meisten Engineering-Teams noch damit beschäftigt sind, ihre erste Generation von Metriken, Logs und Traces für Cloud-native Apps fertigzustellen, ganz zu schweigen von Operational Technology.

Die Verschiebung, wenn sie real ist, fasst zwei Telemetrie-Stacks (IT und OT) zu einem zusammen. Das verändert, wie Platform-Teams Storage budgetieren, Alerting konzipieren und On-Call-Strukturen aufbauen. Es verändert auch, wer was verantwortet.

Wichtige Details

Das Argument, wie ITWeb am 12. März 2026 berichtete, lautet: Observability-Plattformen können jetzt Telemetrie von Maschinen, Infrastruktur, Cloud-Workloads und physischen Umgebungen in Echtzeit erfassen – mithilfe von IoT-Protokollen wie MQTT (leichtgewichtiges Messaging für Sensoren und Geräte) und industriellen Standards wie OPC (ein weit verbreitetes Protokoll für die Maschinenkommunikation). Die genannten Zielbranchen sind Banking, Gesundheitswesen, Bergbau, Logistik und Versorgungsunternehmen.

Das Banking-Beispiel ist das eindeutigste. Jeder Geldautomat wird als verteiltes IoT-Gerät beschrieben, das Hardware-Sensoren, ein Betriebssystem, Netzwerkkonnektivität und Transaktionsverarbeitungssoftware kombiniert. Eine Bank, die Tausende solcher Endpunkte betreibt, kann theoretisch Hardware-Verschlechterung, Konnektivitätsausfälle, abnormale Temperaturbedingungen und Fehler im Transaktionssystem erkennen, bevor Kunden betroffen sind. Das sind vier verschiedene Fehlermodi pro Gerät, multipliziert über eine gesamte Flotte, auf einem einzigen Dashboard.

Das Gesundheitswesen erhält eine ähnliche Behandlung. Operationssäle bündeln Anästhesiegeräte, chirurgische Bildgebung, Patientenüberwachung, Sterilisationssysteme und Umgebungssteuerungen. Die pharmazeutische Kühlkette erweitert die Sensorabdeckung auf Kühlgeräte, Kühllager, Transportbehälter und Lagerumgebungen, wobei die Plattform Temperaturabweichungen, Kühlausfälle und Stromunterbrechungen flaggen soll, bevor Inventar beschädigt wird. Der Artikel nennt eine konkrete Zahl für die Einsätze: Ein einziger verhinderte Kühlausfall kann Millionen an verdorbenem Inventar einsparen. Das ist die einzige explizite finanzielle Angabe in der Quelle.

Die Cloud-Schicht wird als nicht verhandelbar behandelt. Das Argument lautet: Eine Verlangsamung einer Cloud-Anwendung kann sich auf die ATM-Transaktionsverarbeitung auswirken, ein Ausfall einer Logistikplattform kann die Temperaturüberwachung der Kühlkette unterbrechen, und ein Cloud-Service-Ausfall kann die Produktionsüberwachung auf dem Fertigungsgelände stören. Die Abdeckung muss daher hybride und Multi-Cloud-Workloads, Container und Kubernetes-Umgebungen, Application Performance und Datenbanken sowie die Netzwerkkonnektivität zwischen Cloud und operativen Standorten umfassen. Der Bergbau fügt Telemetrie von Förderanlagen, Bohrgeräten, Belüftungssystemen und Sicherheitssensoren unter Tage hinzu. Versorgungsunternehmen ergänzen Umspannwerke, Transformatoren, erneuerbare Energien und Netzsensoren, wobei Transformatorüberhitzung und abnormale Stromschwankungen als Erkennungsziele genannt werden.

Warum das für Engineering-Teams wichtig ist

Die interessante Engineering-Frage ist nicht „Kann man MQTT in ein Observability-Backend einlesen". Das kann man. Die Frage ist, ob das Datenmodell standhält, wenn man es tut. Ein traditioneller APM-Stack ist auf request-basierte Traces, Anwendungsmetriken in etwa 15- bis 60-Sekunden-Intervallen und strukturierte Logs ausgerichtet. OT-Daten sehen anders aus: hochfrequente Vibrationsmessungen, langsam verlaufende Temperaturkurven, diskrete Zustandsänderungen von PLCs über OPC. Das Kardinalitätsprofil, die Aufbewahrungsanforderungen und die Alerting-Semantik sind nicht das gleiche.

Die Quelle behauptet, Maschinen, Anwendungen und Sensoren können zusammen Millionen von Datenpunkten pro Minute erzeugen. Das ist die tragende Zahl im gesamten Beitrag, und die Quelle gibt nicht preis, welcher Anteil hochfrequente OT- gegenüber Standard-Anwendungsmetriken ausmacht – was wichtig ist, weil Speicherkosten und Query-Performance für beide sehr unterschiedlich skalieren. Wenn auch nur 20 Prozent dieser Punkte Sub-Sekunden-Sensormessungen sind, benötigt die Storage-Ebene eine für Downsampling und Rollups optimierte Zeitreihendatenbank, keinen generischen Log-Store. Teams, die diese Unterscheidung überspringen, werden sehen, wie ihre Ingest-Rechnung sich um eine Größenordnung erhöht.

Es gibt auch ein Korrelationsproblem. Die Quelle hebt KI-gestützte Observability hervor, um subtile Performance-Verschlechterungen in Cloud-Anwendungen, abnormale Maschinenvibration als Hinweis auf Geräteausfall und ungewöhnliches Kühlverhalten zu erkennen. Drei sehr unterschiedliche Signaltypen, drei sehr unterschiedliche Baselines. Ich würde argumentieren, dass der realistische kurzfristige Gewinn nicht einheitliche Anomalieerkennung über alle hinweg ist, sondern Korrelation über klar definierte Grenzen hinweg: ein Kubernetes-Pod-Neustart korreliert mit einem ATM-Endpunkt, der ausfällt; ein Datenbanklatenz-Spike korreliert mit einer Verzögerung bei Cold-Chain-Alerts. Standards wie OpenTelemetry geben Teams bereits eine gemeinsame semantische Konvention für die IT-Seite; diese Konventionen auf OT-Signale auszuweiten ist die unerledigte Hausaufgabe.

Überprüfbare Prognose: Platform-Teams, die unified IT/OT Observability einführen, ohne ihre Hot- und Cold-Storage-Ebenen zu trennen, werden innerhalb von zwei Quartalen nach dem Rollout mindestens eine Verdoppelung der Ingest-Kosten sehen und beginnen, Sensordaten still und leise zu verwerfen, um gegenzusteuern.

Auswirkungen auf die Branche

Für Banking-Platform-Leads ist die Betrachtung des Geldautomaten als IoT-Gerät längst überfällig. Einen ATM als Server mit Peripheriegeräten zu behandeln, ermöglicht es, bestehende SRE-Praktiken (SLOs, Error Budgets, Runbooks) auf eine Flotte anzuwenden, die historisch von einer separaten Facility- oder Vendor-Ops-Funktion verwaltet wurde. Das Schwierige ist organisatorischer, nicht technischer Natur. Wer die Cloud-Transaktionsverarbeitungsplattform besitzt und wer die ATM-Hardware-Gesundheit verantwortet, teilen in der Regel kein Alerting-Tool, keine On-Call-Rotation und keinen Postmortem-Prozess. Unified Observability erzwingt dieses Gespräch.

Im Gesundheitswesen ist der Gewinn die OP-Bereitschaft, aber die Einschränkung ist regulatorischer Natur. Die Quelle beschreibt die Integration von Telemetrie aus Anästhesiegeräten, Bildgebung, Patientenüberwachung, Sterilisation und Umgebungssteuerungen. Wir wissen aus der Quelle nicht, wie Gerätehersteller diese Telemetrie bereitstellen oder ob der vorgeschlagene Ansatz davon ausgeht, Daten über OPC-Bridges oder Hersteller-APIs abzurufen. Die Einschränkung: Wenn auch nur ein wichtiger Anbieter im OP-Stack sich weigert, den Maschinenzustand offenzulegen, verschlechtert sich die einheitliche Ansicht zu einer Teilansicht – und klinische Engineering-Teams werden ihr für Go/No-Go-Entscheidungen nicht vertrauen.

Logistik und Pharma sind die sauberste Anpassung. Kühlketten-Telemetrie ist bereits sensorlastig, die Fehlermodi (Temperaturabweichungen, Kühlausfälle, Stromunterbrechungen) sind gut charakterisiert, und der finanzielle Fall ist konkret. Die Überwachung der Kühlkette im Einzelhandel über Lager, Kühllieferfahrzeuge und Ladeneinheiten folgt demselben Muster. Bergbau und Versorgungsunternehmen haben die physisch kritischsten Umgebungen und das unübersichtlichste Legacy-Protokoll-Ökosystem, was die längsten Integrationszeiträume, aber die größten Gewinne pro erkanntem Ausfall bedeutet.

Worauf man achten sollte

Drei Signale, die es im nächsten Jahr zu verfolgen gilt. Erstens: ob Observability-Anbieter OT-spezifische semantische Konventionen veröffentlichen oder es als Kundenaufgabe belassen. Wenn MQTT- und OPC-Ingest in der „Bring your own Schema"-Tier bleibt, wird die Adoption auf Teams mit dedizierten Data Engineers beschränkt bleiben. Zweitens: ob Banken und Krankenhäuser beginnen, Stellenbeschreibungen zu veröffentlichen, die SRE- und Operational-Technology-Verantwortlichkeiten kombinieren. Das ist der nachlaufende Indikator dafür, dass die organisatorische Veränderung real ist und nicht nur die Tooling-Veränderung. Drittens: ob KI-gestützte Anomalieerkennung über gemischte Signaltypen hinweg weniger Fehlalarme erzeugt als domänenspezifische Erkennung. Die Quelle ist optimistisch in dieser Hinsicht; die Beweislage ist dünn.

Prognose: Bis Q2 2027 wird mindestens ein großer Observability-Anbieter einen erstklassigen OPC-Connector mit dokumentierten semantischen Konventionen veröffentlichen, und die ersten Referenzarchitekturen, die Kubernetes-Monitoring mit industrieller Telemetrie kombinieren, werden erscheinen – ähnlich im Geiste wie die im Google Cloud Architecture Framework dokumentierten Muster. Wenn das nicht passiert, bleibt die IT/OT-Konvergenzgeschichte für einen weiteren Zyklus ein Folienpunkt in Präsentationen.

Wichtige Erkenntnisse

  • Der Pitch von ATS Network Management vereint IT- und OT-Telemetrie über MQTT und OPC und richtet sich an Banking, Gesundheitswesen, Bergbau, Logistik und Versorgungsunternehmen.
  • Die Betrachtung des Geldautomaten als verteiltes IoT-Gerät ist das handlungsfähigste Beispiel: vier Fehlerklassen pro Gerät (Hardware, Konnektivität, Umgebung, Transaktionen) auf einer Plattform.
  • Der Anspruch „Millionen Datenpunkte pro Minute" ist real, aber hinsichtlich der Zusammensetzung unbelegt. Gemischte IT/OT-Kardinalität wird naive Storage-Tiers überlasten.
  • Das schwierigste Problem ist nicht der Ingest, sondern die Korrelationssemantik und die organisatorische Eigentümerschaft über bisher getrennte IT- und Facility-Teams hinweg.
  • Achten Sie auf OT-bewusste semantische Konventionen von Observability-Anbietern und kombinierte SRE/OT-Stellenausschreibungen als Frühindikatoren für echte Adoption.

Häufig gestellte Fragen

F: Was ist der Unterschied zwischen traditionellem IT-Monitoring und dem hier beschriebenen Observability-Ansatz?

Traditionelles Monitoring beantwortet die Frage „Funktioniert das IT-System?" durch die Überwachung von Servern, Netzwerken, Anwendungen und Datenbanken. Der erweiterte Observability-Ansatz zieht Operational-Technology-Daten über Protokolle wie MQTT und OPC ein, sodass dieselbe Plattform Cloud-Workloads neben Geldautomaten-Hardware, Kühlgeräten, OP-Ausstattung und Industriemaschinen überwachen kann.

F: Warum sind MQTT und OPC die Protokolle der Wahl?

MQTT ist ein leichtgewichtiges Messaging-Protokoll, das für IoT-Sensoren und -Geräte entwickelt wurde, was es effizient für hochvolumige, bandbreitenarme Telemetrie macht. OPC ist ein langjährig etabliertes Industrieprotokoll für die Maschine-zu-Maschine-Kommunikation und gibt Observability-Plattformen daher Zugang zu bestehenden Fabrik- und Infrastrukturgeräten, ohne die Steuerungsschicht zu ersetzen.

F: Was ist das realistische Risiko, OT-Daten in eine bestehende Observability-Plattform einzuspeisen?

Kosten und Signalqualität. Sensor-Streams haben sehr unterschiedliche Kardinalitäts- und Frequenzprofile gegenüber Anwendungsmetriken, sodass für APM optimierte Storage- und Query-Ebenen schnell teuer werden können. Teams, die heiße OT-Daten nicht von Standard-Anwendungstelemetrie trennen, neigen dazu, entweder beim Ingest zu viel auszugeben oder Sensormessungen still zu verwerfen – was den Zweck verfehlt.

SC
Sarah Chen
RiverCore Analyst · Dublin, Ireland
TEILEN
// RELATED ARTICLES
StartseiteLösungenProjekteÜber unsKontakt
News06
Dublin, Irland · EUGMT+1
LinkedIn
🇩🇪DE