Agentenbasierte prädiktive Wartung mit OpenVINO: Eine Pipeline, fünf industrielle Anwendungsfälle.

Pipelines, Versorgungsanlagen und andere kritische Anlagen benötigen ständige Überprüfungen, um Ausfälle, Lecks und Sicherheitsvorfälle zu vermeiden. Eine rein reaktive oder kalenderbasierte Wartung führt zu wiederholten Inspektionsfahrten, übersehenden Frühwarnsignalen für Defekte sowie zu unübersichtlichen Unterlagen bei Audits. KI-basierte Systeme ermöglichen eine kontinuierliche Überwachung und früheres Handeln, wodurch Inspektionsbesuche eingespart, Stillstandszeiten verkürzt, die Sicherheit verbessert und ein für Audits geeignetes Nachweissystem geschaffen wird.

In diesem Artikel wird ein Projekt des Google Summer of Code 2026 vorgestellt, das den prädiktiven Wartungsansatz des Intel Metro AI Suite, der auf OpenVINO basiert, mit neuen Anwendungsfällen und Datensätzen erweitert hat.

Die Lücke zwischen Vorhersage und Entscheidung

Ein Modell kann Tausende von Vorhersagen abgeben, doch die Person, die die Ergebnisse erhält, möchte dennoch drei Antworten: Was ist passiert, warum, und was sollte als Nächstes überprüft werden. Eine Beschriftung mit einem Zuverlässigkeitswert liefert diese Informationen nicht. Ein praktisches Pipeline-System muss die Belege hinter jedem Ergebnis beibehalten, verschiedene Arten von Eingaben akzeptieren und es den Nutzern ermöglichen, die Ausgaben zu untersuchen, ohne den zugrunde liegenden Code verstehen zu müssen.

Genau das war das Ziel des Projekts. Es verband die Modellinferenz mit strukturiertem Speichern, koordinierte KI-Agenten, Fragen in natürlicher Sprache sowie evidenzbasierte Tickets – alles innerhalb eines einzigen Workflows.

Wie das Pipeline-System aufgebaut ist

Die Verarbeitung beginnt mit einem OpenVINO-Modell, dessen Ergebnisse in JSONL-Dateien sowie in einer SQLite-Datenbank gespeichert werden. Anschließend koordiniert ein LangGraph-Ablauf drei Agenten – einen für die Strategieentwicklung, einen für die Analyse und einen für die Erstellung von Beweisen. Die Benutzer können die Ergebnisse anschließend über Chat untersuchen oder ein Ticket mit den entsprechenden Beweisen erstellen.

Vier Verbesserungen prägten die Arbeit und zielen auf Benutzerfreundlichkeit, Erklärbarkeit, Erweiterbarkeit sowie eine breitere Anwendbarkeit ab. Es handelt sich um unterschiedliche Korrekturen, doch alle fallen in denselben End-to-End-Ablauf.

Vier Beiträge

Eine Box für jede Art von Frage

Zuvor musste ein Benutzer vor dem Eingeben irgendetwas zwischen Analyse-, Beweis- und SQL-Modus wählen. Das bedeutete, dass er wissen musste, wie die internen Komponenten aufgeteilt waren – was eine hohe Anforderung an einen Bediener ist. Die neue Version erkennt die Absicht und sendet die Anfrage automatisch an den richtigen Backend, sowohl in der Kommandozeile als auch in der Web-Oberfläche. Niemand muss sich mehr für einen Modus entscheiden.

Fragen zu Rohdaten der Sensoren

Das konfigurierbare SQLite-Schema wurde erweitert, um rohe Sensorwerte, die Zuverlässigkeit pro Modus sowie Metadaten zum Anwendungsfall zu speichern. Dadurch werden Fragen wie diese möglich: Welche Proben wiesen eine höhere Sensorzuverlässigkeit auf als eine höhere Bildzuverlässigkeit? Die Bedingung in natürlicher Sprache wird in eine Datenbankabfrage umgewandelt, die die entsprechenden Messwerte, Etiketten und Quelldaten zurückgibt. Derselbe Kontext erreicht auch die Richtlinien- und Analyseagenten. Entscheidend ist die Nachvollziehbarkeit, da die gespeicherten Rohwerte und Metadaten jede Antwort auf die zugrunde liegenden Datensätze zurückführen.

Neue Modelle ohne Neubau

Der ursprüngliche Eingangspunkt für die Inferenz hatte zu viele Aufgaben. Er wurde in separate Teile aufgeteilt: Einstellungen, Routing, modellbezogene Handler, der Ausführungsschritt, das Schreiben von Ergebnissen und das Erstellen von Diagrammen. Ein Dispatcher wählt nun einen kleinen, fokussierten Handler aus, während gemeinsame Komponenten sich um das Verhalten kümmern, das für alle Anwendungsfälle gilt. Das Hinzufügen eines neuen Datentyps bedeutet nun das Schreiben eines Handlers und einer Konfiguration sowie die Wiederverwendung des Rests des Lebenszyklus.

Fünf industrielle Anwendungsfälle in einem Laufzeitumfeld

Die Eingaben, die Vorhersageziele und die Belege unterscheiden sich in den fünf Fällen voneinander, doch sie nutzen dieselbe zugrundeliegende Infrastruktur. Vier Eingabemuster werden abgedeckt: tabellarische Daten, Bilder, Audio mit Text sowie Rasterdaten mit Text.

Öl- und Gasleitungen. Tabellarische Betriebs- und Materialdaten werden an ein OpenVINO MLP übergeben, das gleichzeitig zwei Dinge vorhersagt: den Zustand der Leitung sowie den Verlust an Wandstärke. Zu den Eingabedaten gehören geometrische Angaben, Materialien sowie wertbezogene Informationen zum Betrieb und zur Korrosion. Jeder verarbeitete Datensatz liefert eine Zustandsklasse sowie eine Schätzung des Wandstärkeverlusts, wobei beide Werte weiterhin mit den ursprünglichen Messwerten verknüpft bleiben. Diese Verbindung ermöglicht es nachgelagerten Systemen, ein Ergebnis anhand der tatsächlichen Betriebswerte zu erklären, und der Arbeitsablauf beinhaltet außerdem eine auf Korrosion ausgerichtete Analyse.

Solarmodule. Ein YOLO-basierter OpenVINO-Detektor sucht nach Defekten in einkanaligen Elektrolumineszenzbildern von Solarmodulen und speichert die Begrenzungskästchen als Beweismittel. In einem Beispiel markiert ein rotes Kästchen einen tatsächlichen Riss in Form eines Sterns, den der Detektor finden soll. Eine Auswertung aller 19.150 Testbilder ergab einen F1-Wert von 0,8277. Das vorhergesagte Kästchen wird zusammen mit seiner Klasse und dem Zuverlässigkeitsgrad gespeichert, sodass der Benutzer erkennen kann, wo der Defekt gefunden wurde.

Stromübertragung. Ein fein abgestimmtes YOLOv8s-cls-Modell sortiert Bilder von Übertragungsleitungen in drei Kategoriegruppen ein. Es verarbeitet sowohl synthetische als auch reale Bilder, wodurch getestet wird, ob ein Klassifikator mit dargestellten Schaltplänen sowie Fotos von Feldinspektionen zurechtkommt. Bei 348 ausgeschlossenen Bildern lag die Genauigkeit bei 334 richtigen Ergebnissen, was einem Wert von 0,9598 entspricht. Beide Bildquellen durchlaufen dieselbe Vorausverarbeitung und Inferenz.

Instandhaltung der Betriebsumgebung. In diesem Fall wird ein Audiodateiabschnitt mit einer Untertitelung kombiniert. Beide werden getrennt voneinander vorverarbeitet, durch zwei OpenVINO MLP-Ableitungen klassifiziert und anschließend durch späte Fusion zusammengeführt. Ein Beispiel mit der Bezeichnung „drehende Maschinen“ enthielt den Untertitel, dass ein Elektrowerkzeug beim Betrieb vibriert. Ein Videoframe liefert dem menschlichen Leser Kontext, doch die Eingabe für das Modell besteht aus dem Audio des Clips sowie dem Text. Die Ableitungen bleiben bis zur Zusammenführung ihrer Ergebnisse einzeln überprüfbar.

Wasseraufbereitung. Ein 15-Kanäle-Sentinel-2-Rasterausschnitt wird mit einer textbasierten Beschreibung der Umwelt kombiniert, beispielsweise einer Beschreibung einer Grafschaft in Arizona mit Angaben zu Evapotranspiration, Niederschlag, Grundwasserspiegel und Oberflächenwasserspiegel. Statistische Merkmale des Rasters sowie TF-IDF-Merkmale des Textes werden vor der endgültigen Fusion durch separate OpenVINO-Branchen verarbeitet, wodurch die Zuverlässigkeit jeder Branche erhalten bleibt. Es wird eine JPEG-Voransicht erstellt, damit die Nutzer sich das Beispiel ansehen können, doch das Modell selbst verwendet den ursprünglichen mehrkanaligen NumPy-Array. Die Voransicht kann auch einem Ticket beigefügt werden, um eine mehrmodale Vorhersage mit sichtbaren Beweismitteln zu liefern.

Ausführung auf Intel-Hardware

Jedes Modell wurde im OpenVINO IR-Format implementiert, wobei der konfigurierbare Eingangspunkt Bilder, tabellarische Sensorvektoren, Audiodaten sowie gepaarte multimodale Eingaben verarbeiten kann. Der Code wurde auf einer Intel-GPU getestet, und die Inferenz über den gesamten Pipeline-Prozess wurde ebenfalls auf einer Intel-NPU überprüft, einschließlich der Erstellung der JSONL- und SQLite-Ausgaben.

Testen mehr als nur die Genauigkeit

Die Validierung ging über die Modellgenauigkeit hinaus. Jeder Arbeitsablauf wurde von der Modellladung über die strukturierte Ausgabe über die Agenten, Schnittstellen, Beweismittel und Tickets bis hin zur Ausführung auf Intel-Hardware durchgespielt. Die Überprüfungen umfassten sowohl die Grenzen zwischen den Komponenten als auch die Ausgaben der einzelnen Modelle.

Was die Demos zeigen

Zwei Ansichten zeigen, wie das System funktioniert. Die erste ist die Backend-Orchestrierung. Sie beginnt mit den Inferenzergebnissen in der gemeinsamen Datenschicht. Der Policy-Agent filtert diese gemäß der konfigurierten Richtlinie, und der Analysis-Agent fasst ihre operationelle Bedeutung zusammen. Der Evidence-Agent gruppiert anschließend jedes Ergebnis zusammen mit seinen Quelldaten und Metadaten zu einem nachvollziehbaren Datensatz. Gemeinsam wandeln sie die gespeicherten Modellausgaben in strukturierte Analysen und Nachweise um, die zur Überprüfung bereit sind.

Die zweite Ansicht ist das einheitliche Chat-Fenster. Nutzer prüfen Analysezusammenfassungen, inspizieren Nachweise und filtern Ergebnisse sowie fügen Anfragen zu strukturierten Wartungsdaten hinzu. Nach der Untersuchung können sie ein Wartungsticket zur weiteren Bearbeitung erstellen. Dies veranschaulicht den gesamten Weg vom Erkunden der Ergebnisse bis zur Erstellung eines Tickets.

Lektionen aus der Gestaltung

Das zentrale Designproblem bestand darin, die Wiederverwendung mit modalspezifischem Verhalten in Einklang zu bringen. Alle fünf Fälle teilen sich Konfigurations-, Ausführungs-, Speicher- und Agentenkomponenten, während kleine Handler die Vor- und Nachverarbeitung bewahren, die jedes Datentyp benötigt. Dadurch entfällt Duplizierung, ohne dass sehr unterschiedliche Eingaben durch identische Logik gezwungen werden.

Die Ergebnisse sprechen zudem dagegen, nur ein reines Label zu speichern. Wenn rohe Sensordaten, Begrenzungskästchen, Zweigspezifische Zuverlässigkeitswerte, Metadaten sowie Vorschauen der Quelle zusammen mit der Vorhersage übertragen werden, bleibt jedes Ergebnis mit Belegen verbunden, die sowohl Menschen als auch Agenten prüfen können.

Bei den multimodalen Fällen sorgt die späte Fusion dafür, dass die Audio-, Text- und Rasterzweige weiterhin einzeln nachvollziehbar bleiben. Die derzeitige gleichmäßige Gewichtung ist einfach und reproduzierbar, obwohl gelernte oder dynamisch kalibrierte Gewichte besser widerspiegeln könnten, wie zuverlässig jede Modality ist.

Die Agentenschicht ersetzt die prädiktiven Modelle nicht. Sie organisiert die gespeicherten Ergebnisse, holt unterstützende Beweise ab und leitet eine Frage an die richtige Analyse oder Datenbankoperation weiter. Die Validierung umfasst die ausgewerteten Datensätze sowie Intel-Hardware, und in echten Implementierungen wären weiterhin testspezifische Überprüfungen, Überwachung und Kalibrierung erforderlich.

Von Prototyp zu Konzept

Was ursprünglich als Pipeline für einen einzigen Anwendungsfall entwickelt wurde, ist nun modularer, multimodal und benutzerorientierter geworden. OpenVINO stellt die gemeinsame Inferenzschicht bereit, während strukturierte Speicherung sowie koordinierte Agenten die Modellausgaben in Informationen umwandeln, die ein Mensch prüfen und darauf handeln kann. Derselbe Ablauf – von industriellen Daten über Inferenz und Beweise bis hin zur Erkundung in natürlicher Sprache sowie der Erstellung von Tickets – wird nun in mehreren Wartungsbereichen wiederholt.