Zum Inhalt springen

Wonach suchen Sie?


Das könnte Ihnen auch gefallen

OpenTelemetry in der industriellen Automatisierung verstehen: Architektur, Observability und betriebliche Vorteile

  • von WUPAMBO
Understanding OpenTelemetry in Industrial Automation: Architecture, Observability, and Operational Benefits

Industrielle Steuerungssysteme entwickeln sich rasch hin zu cloudnativen Architekturen und IIoT-Integrationen. Moderne Produktionsanlagen setzen vernetzte speicherprogrammierbare Steuerungen (SPS), verteilte Leitsysteme (DCS) und Edge-Computing-Knoten ein, die kontinuierlich Daten erzeugen. Die Erfassung und Auswertung von Betriebsdaten dieser verteilten Anlagen erfordert standardisierte Überwachungsmethoden. OpenTelemetry ist ein Open-Source-Framework, das dazu entwickelt wurde, Systemmetriken, Aktivitätsprotokolle und Ausführungstraces in industriellen Automatisierungs- und IT-Infrastrukturen zu vereinheitlichen.

Die Rolle von Telemetriedaten in moderner Automatisierungsinfrastruktur

Komplexe industrielle Automatisierungsplattformen verarbeiten große Mengen an Betriebssignalen, um die Prozessintegrität aufrechtzuerhalten. Ingenieure müssen die Ausführungszyklen von Steuerungen, den Zustand von Feldbusnetzwerken und die Serverauslastung in Echtzeit bewerten. Systemtelemetrie umfasst drei primäre Datentypen: Metriken, Protokolle und Traces.

Metriken liefern kontinuierliche quantitative Werte, beispielsweise die CPU-Auslastung oder die Ausführungszeiten von Buszyklen. Protokolle erzeugen mit Zeitstempeln versehene Aufzeichnungen bestimmter Hardware- oder Softwareereignisse. Traces verfolgen Ausführungsanfragen, während sie sich durch verteilte Netzwerk-Microservices bewegen. Die Kombination dieser drei Datenströme bietet vollständige Transparenz über Steuerungsnetzwerke in der Produktionsebene und übergeordnete Cloud-Plattformen.

Architektur und Datenfluss des OpenTelemetry-Frameworks

OpenTelemetry arbeitet über eine modulare Pipeline, die Systemdiagnosedaten erfasst, verarbeitet und exportiert. Die Anwendungsschicht nutzt standardisierte APIs und Software Development Kits (SDKs), um Softwareereignisse auf niedriger Ebene zu erfassen.

Die Datenpipeline durchläuft nacheinander klar definierte Betriebsphasen:

  1. Anwendungs- und Steuerungsknoten: Eingebettete Geräte und Industriesoftware erzeugen während der Ausführung Rohdaten in Form von Metriken, Protokollen und Trace-Ereignissen.
  2. APIs und SDKs: Standardisierte Schnittstellen erfassen diese Ereignisse, ohne dass proprietäre individuelle Anbindungspunkte erforderlich sind.
  3. Erfassung durch den OpenTelemetry Collector: Dedizierte Receiver erfassen gleichzeitig die eingehenden Datenströme mehrerer Steuerungsknoten.
  4. Verarbeitung und Anreicherung durch den Collector: Interne Verarbeitungsmodule filtern Rauschen heraus, bündeln Datensätze und fügen den erfassten Telemetriedaten Kontextmetadaten hinzu.
  5. Übertragung durch Exporter: Standardisierte Exporter formatieren die angereicherten Daten und übertragen sie direkt an ausgewählte Backends für Observability und Analysen.

Diese standardisierte Erfassungs-Engine macht den Betrieb mehrerer proprietärer Agents auf der Steuerungshardware überflüssig.

Wesentliche betriebliche Vorteile der OpenTelemetry-Implementierung

  • Unabhängigkeit von Anbietern: Ingenieure können Überwachungs-Backends oder Analysedatenbanken wechseln, ohne die zugrunde liegende Instrumentierung der Steuerungen oder die eingebettete Software zu ändern.
  • Geringerer Ressourcenbedarf: Die Zusammenführung der Erfassung von Metriken, Protokollen und Traces in einem einzigen Framework reduziert den CPU- und Speicherbedarf auf industriellen Edge-Gateways.
  • Standardisiertes Datenschema: Open-Source-Telemetriestandards beseitigen Softwaresilos zwischen Netzwerken der Betriebstechnik (OT) und den IT-Systemen von Unternehmen.
  • Beschleunigte Diagnose: Vereinheitlichte Ausführungstraces ermöglichen es Steuerungsingenieuren, Netzwerkengpässe und Fehler von Steuerungen schneller zu isolieren.
  • Niedrigere Gesamtbetriebskosten: Der Verzicht auf proprietäre Überwachungssoftwarelizenzen senkt die laufenden Kosten für den Softwarelebenszyklus erheblich.

Erkenntnisse des Autors zur OpenTelemetry-Integration in Steuerungssysteme

Aus meiner Erfahrung mit der Leitung groß angelegter DCS-Upgrades und Steuerungsnetzwerke in Produktionsanlagen war die Überwachung der Anwendungsleistung historisch durch die Bindung an proprietäre Anbieter eingeschränkt. Traditionelle Automatisierungsanbieter beschränken Diagnosedaten häufig auf geschlossene Softwareplattformen. Diese Einschränkung zwingt Engineering-Teams dazu, fragmentierte Überwachungswerkzeuge in unterschiedlichen SPS- und DCS-Ökosystemen zu verwalten.

Die Einführung von OpenTelemetry stellt einen grundlegenden Wandel hin zu einheitlicher industrieller Observability dar. Durch die Standardisierung der Telemetrieerfassung können Betriebsteams von Produktionsanlagen Diagnosedaten direkt in zentralisierte Unternehmens-Dashboards einspeisen. Dieser offene Ansatz verbessert die Ursachenanalyse bei unerwarteten Ausfällen von Steuerungssystemen und bringt ältere Anlagenkomponenten mit cloudnativen Überwachungspraktiken in Einklang.

Industrielles Anwendungsszenario: Fehlerdiagnose bei Edge-Steuerungen

Betrachten wir eine moderne Automobilmontagelinie, die Edge-Steuerungen zur Verwaltung von Roboterbewegungen und zur Synchronisierung von Förderanlagen einsetzt. Wenn eine sporadische Kommunikationsverzögerung den Ausfall einer Station verursacht, zeichnet die herkömmliche Protokollierung möglicherweise nur einen allgemeinen Timeout-Fehler auf der Haupt-SPS auf.

Durch die Implementierung von OpenTelemetry auf den Edge-Steuerungen und Gateway-Microservices erfasst das System einen verteilten Trace des Fehlerereignisses. Der Diagnosetrace zeigt, dass ein zusätzlicher Dienst zur Bildverarbeitung die CPU-Auslastung sprunghaft erhöhte und dadurch die Echtzeitübertragung des Feldbuszyklus verzögert wurde. Das Engineering-Team kann die Prozessprioritäten schnell anpassen und das Problem beheben, ohne Servicetechniker für eine langwierige manuelle Fehlersuche vor Ort einsetzen zu müssen.


Zurück