Pexon Consulting | 11 Min. Lesezeit | 20.06.2026
TL;DR
Ein KI Workflow Instandhaltung verbindet Maschinensensor und CMMS so, dass aus einer Schwellwert- oder Anomalie-Meldung automatisch ein priorisiertes Wartungs-Ticket mit Diagnose-Vorschlag entsteht. Pexon baut diesen End-to-End-Pfad als 6-Wochen-Pilot — Azure-Partner, 80 Mitarbeiter, DSGVO-konform. Ungeplante Stillstände kosten in der Automobilfertigung 5.000 bis 20.000 EUR pro Minute.
Das Problem: Der Sensor weiß es, das CMMS erfährt es zu spät
Die meisten Werke haben das eigentliche Problem schon gelöst — sie wissen es nur nicht. An Spindeln, Pumpen und Getrieben hängen längst Schwingungs-, Temperatur- und Stromsensoren. Die Daten landen in einer Historian-Datenbank oder einem OPC-UA-Server. Und dann? Liegen sie. Bis ein Bediener eine Auffälligkeit bemerkt, ein Ticket im CMMS (Computerized Maintenance Management System) anlegt und der Disponent es einsortiert, sind Stunden vergangen — bei einem akuten Lagerschaden zu viel.
Das ist die Lücke, um die es hier geht. Nicht „wie sammle ich Maschinendaten“ (das machen Lakehouse- und OEE-Projekte), nicht „wie hilft ein Assistent dem Techniker vor Ort“. Sondern der konkrete, automatisierte Pfad dazwischen: Sensor-Event → KI-Anreicherung → CMMS-Ticket. Genau dieser Pfad entscheidet, ob teuer beschaffte Sensorik einen Euro Wert produziert oder nur ein Dashboard füttert, das niemand öffnet.
Die Zahlen dahinter sind nicht klein. Der Markt für Predictive Maintenance lag 2025 bei rund 14,3 Mrd. USD und wächst laut Grand View Research mit 27,9 % jährlich. Über 60 % der deutschen Maschinenbau-KMU bewerteten in einer VDMA-Erhebung 2024 intelligente Instandhaltung als einen ihrer wichtigsten Digitalisierungshebel. Und seit September 2025 ist der EU Data Act in Kraft — Maschinendaten müssen Betreibern in maschinenlesbarer Qualität zugänglich sein, was den rechtlichen Deckel von vielen Sensor-Datenströmen nimmt.
Die Architektur: vier Stufen vom Event zum Ticket
Der Workflow hat vier klar getrennte Stufen, und genau diese Trennung macht ihn robust. Wer Anomalieerkennung, Anreicherung und Ticket-Erzeugung in einen Monolithen wirft, kann später keine Stufe einzeln tauschen — und genau das wird man wollen, wenn das ML-Modell besser wird oder das CMMS wechselt.
┌──────────────┐ ┌────────────────┐ ┌──────────────────┐ ┌─────────────┐
│ 1. SENSOR │ │ 2. ANOMALIE │ │ 3. KI-ANREICHE- │ │ 4. CMMS │
│ Schwingung │──▶│ Schwellwert │──▶│ RUNG │──▶│ Ticket via │
│ Temp, Strom │ │ + Isolation │ │ Prioritaet + │ │ REST/Webhook│
│ OPC-UA/MQTT │ │ Forest (Edge)│ │ Diagnose (LLM) │ │ + Diagnose │
└──────────────┘ └────────────────┘ └──────────────────┘ └─────────────┘
Report-by- Kein Fixed- claude-sonnet-4-6 eMaint, Fiix,
Exception Polling, nur mit Maschinen- IBM Maximo,
echte Abweichung Kontext (RAG) oder n8n-BridgeStufe 1 — Datentransport. OPC UA für die semantische Maschinen-Kommunikation, MQTT mit Sparkplug B für hochfrequente Telemetrie. Sparkplug B löst die Schwächen von rohem MQTT (kein Datenmodell, kein State, keine Namensraum-Konvention) und liefert Report-by-Exception: Die Pipeline bewegt sich nur bei echten Zustandsänderungen, nicht im festen Polling-Takt. Das spart Bandbreite und reduziert Fehlalarme.
Stufe 2 — Anomalieerkennung am Edge. Reine Schwellwerte fangen die offensichtlichen Fälle. Die teuren, schleichenden Degradationen fängt erst ein ML-Modell. Ein Hybrid aus Autoencoder (Feature-Lernen) und Isolation Forest (unüberwachtes Scoring) erreicht in aktuellen Benchmarks auf dem CIC-IoT-DIAD-2024-Datensatz eine Accuracy von 0,98 — und ist leicht genug, um auf einem Edge-Gateway zu laufen. Wir empfehlen bewusst diesen Hybrid statt eines großen Deep-Learning-Modells: Er ist erklärbar, ressourcenschonend und braucht keine GPU im Schaltschrank.
Stufe 3 — KI-Anreicherung. Hier kommt das LLM ins Spiel — aber nicht, um eine Anomalie zu erkennen, sondern um sie zu interpretieren. Ein claude-sonnet-4-6 bekommt den Sensor-Kontext, die Maschinen-Historie und die Wartungs-Doku (per RAG) und liefert: Verdachts-Diagnose, Kritikalitäts-Score, vorgeschlagene Maßnahme und benötigtes Ersatzteil. Das ist der Schritt, der aus einem nackten Alarm ein arbeitsfähiges Ticket macht.
Stufe 4 — CMMS-Anbindung. 73 % der CMMS-Käufer bewerten 2026 die API-Verfügbarkeit als kritisches Auswahlkriterium — aus gutem Grund. Drei API-Typen sind relevant: REST (Standard), GraphQL (gezielte Feld-Abfragen) und Webhooks (Event-getrieben). Systeme wie eMaint (Fluke) oder Fiix erzeugen über diese Wege automatisch Work Orders, sobald sich Zustände ändern.
So sieht der Workflow im Code aus
Der Kern ist überraschend kompakt. Unten ein lauffähiges Python-Beispiel für die Stufen 2 bis 4: Sensor-Event rein, Anomalie prüfen, anreichern, Ticket raus. In der Praxis sitzt das entweder in einem n8n-Workflow (für No-Code-Teams) oder als Azure Function (für IT-Teams, die Code bevorzugen).
# Sensor-Event -> Anomalie -> KI-Diagnose -> CMMS-Ticket
# Lauffaehig mit: pip install scikit-learn anthropic requests
import requests
from anthropic import Anthropic
from sklearn.ensemble import IsolationForest
import numpy as np
# --- Stufe 2: Anomalie-Check am Edge (vortrainiertes Modell laden) ---
def ist_anomalie(modell: IsolationForest, messwerte: list[float]) -> bool:
# Isolation Forest: -1 = Anomalie, 1 = normal
vektor = np.array(messwerte).reshape(1, -1)
return modell.predict(vektor)[0] == -1
# --- Stufe 3: KI-Anreicherung mit Maschinen-Kontext ---
def diagnose_erzeugen(anlage: str, messwerte: dict, historie: str) -> dict:
client = Anthropic() # ANTHROPIC_API_KEY aus Umgebung
prompt = (
f"Anlage: {anlage}n"
f"Aktuelle Messwerte: {messwerte}n"
f"Wartungshistorie (Auszug): {historie}nn"
"Liefere als JSON: verdacht (Kurzdiagnose), "
"prioritaet (1-5, 5=Stillstand droht), "
"massnahme (konkreter Folge-Schritt), ersatzteil (oder null)."
)
antwort = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=400,
messages=[{"role": "user", "content": prompt}],
)
return antwort.content[0].text # In Produktion: JSON parsen + validieren
# --- Stufe 4: Ticket via CMMS-REST-API anlegen ---
def ticket_anlegen(cmms_url: str, token: str, diagnose: dict) -> str:
antwort = requests.post(
f"{cmms_url}/api/v1/workorders",
headers={"Authorization": f"Bearer {token}"},
json={
"title": diagnose["verdacht"],
"priority": diagnose["prioritaet"],
"description": diagnose["massnahme"],
"required_part": diagnose["ersatzteil"],
"source": "predictive-maintenance-workflow",
},
timeout=10,
)
antwort.raise_for_status()
return antwort.json()["work_order_id"]Wer No-Code bevorzugt: Genau dieselbe Logik läuft als n8n-Workflow (Stand Juni 2026: n8n 2.x), bei dem ein MQTT-Trigger das Event empfängt, ein Code-Node die Anomalie prüft und ein HTTP-Request-Node das Ticket anlegt. Ein Stolperstein bei selbst gehostetem n8n: Die WEBHOOK_URL muss exakt der öffentlichen HTTPS-URL entsprechen, inklusive korrektem Trailing-Slash — das ist fast immer der Grund, wenn Webhooks nach dem Setup nicht feuern. Welcher Weg besser passt, hängt vom Team ab; mehr dazu in unserem Leitfaden zur Workflow-Automatisierung mit Active Directory und n8n, der dasselbe Trigger-Prüfung-Aktion-Muster zeigt. Für den produktiven Betrieb mit SLA und DSGVO-Rahmen begleiten wir die Workflow-Automatisierung mit n8n im Enterprise-Kontext.
Schwellwert oder Anomalie-Modell: Was zuerst?
Die kurze Antwort: Schwellwert zuerst, Modell danach — aber beides am Ende parallel. Wer mit einem ML-Modell startet, verbrennt Wochen mit Labeling und Tuning, bevor das erste Ticket fließt. Wir raten in fast allen Piloten dazu, in Woche 1 mit harten Schwellwerten zu beginnen (Temperatur über X, Vibration über Y). Das liefert sofort funktionierende Tickets und — wichtiger — die Trainingsdaten und das Vertrauen der Instandhalter.
Das Anomalie-Modell kommt dazu, sobald genug Normalbetriebs-Daten vorliegen. Es fängt dann genau die Fälle, die feste Regeln verpassen: die langsame Lagerverschlechterung, die erst in der Kombination dreier Sensoren auffällt. Beide Pfade speisen am Ende denselben Anreicherungs- und Ticket-Schritt — die Architektur oben ändert sich dadurch nicht.
Ein Wort zur Datenbasis: Ohne sauberen, einheitlichen Maschinendaten-Strom bleibt jeder Workflow ein Provisorium. Wenn die Daten noch in Insel-Historians liegen, ist der erste Schritt oft ein Lakehouse-Fundament — wie wir es im Beitrag zur KI-Prozessverbesserung in der Fertigung beschreiben. Erst danach lohnt der Ticket-Workflow.
Kosten und Zeitrahmen: Was ein Pilot realistisch kostet
Ein erster produktiver Workflow für eine abgegrenzte Anlagengruppe (5 bis 15 Maschinen) ist in 6 Wochen machbar — das ist unser Standard-Schnitt für solche Piloten. Die Logik dahinter: lieber eine Anlagengruppe end-to-end zum Laufen bringen, als zehn Anlagen halb anzubinden. Predictive Maintenance senkt Instandhaltungskosten gegenüber rein reaktiver Wartung um bis zu 40 % und reduziert ungeplante Ausfallzeit um bis zu 50 % (Grand View Research) — bei 5.000 bis 20.000 EUR Stillstandskosten pro Minute in der Automobilfertigung amortisiert sich der Pilot oft am ersten verhinderten Ausfall.
Der größte versteckte Kostentreiber ist nicht die KI, sondern das CMMS. Wenn das System keine brauchbare API hat (älter als ~2019), wird die Stufe-4-Anbindung zur eigentlichen Arbeit. Deshalb klären wir die API-Reife immer in der ersten Woche — nicht in der fünften.
Worauf Sie bei der Umsetzung achten sollten
- CMMS-API zuerst prüfen. REST oder Webhook vorhanden? Ohne API kein automatisches Ticket. Das ist das k.o.-Kriterium.
- Fehlalarm-Budget definieren. Ein Workflow, der 30 Tickets pro Schicht erzeugt, wird ignoriert. Lieber konservativ scoren und nur ab Priorität 3 automatisch ticketn.
- Mensch im Loop für Priorität 5. Bei akutem Stillstands-Verdacht zusätzlich Push/SMS — nicht nur ein Ticket in einer Queue.
- Edge statt Cloud für die Anomalie-Stufe. Latenz und Datensouveränität sprechen dafür, das Modell nah an der Maschine laufen zu lassen.
- EU Data Act als Hebel nutzen. Seit September 2025 haben Sie Anspruch auf Ihre Maschinendaten in nutzbarer Qualität — auch von OEMs, die bisher gemauert haben.
Häufig gestellte Fragen
Was kostet ein KI Workflow für die Instandhaltung?
Ein 6-Wochen-Pilot für eine Anlagengruppe (5 bis 15 Maschinen) bewegt sich im Rahmen eines mittleren fünfstelligen Budgets — abhängig vor allem von der API-Reife des CMMS und dem Zustand der Sensorik. Bei Stillstandskosten von 5.000 bis 20.000 EUR pro Minute in der Automobilfertigung rechnet sich das oft schon am ersten verhinderten Ausfall. Den Großteil der KI-Anreicherungs-Logik verwenden Sie über weitere Anlagen hinweg, sodass jeder zusätzliche Workflow günstiger wird.
Brauche ich Predictive Maintenance oder reichen Schwellwerte?
Kommt drauf an, aber starten Sie mit Schwellwerten. Feste Regeln fangen die offensichtlichen Fälle sofort und liefern die Trainingsdaten für das spätere Modell. Das Anomalie-Modell (z. B. Autoencoder plus Isolation Forest) kommt dazu, sobald genug Normalbetriebs-Daten vorliegen — es fängt die schleichenden Degradationen, die Regeln verpassen. Beides parallel ist das Ziel, nicht entweder/oder.
Wie wird aus einem Sensor-Event automatisch ein Ticket im CMMS?
Über die CMMS-API. Sobald die Anomalie-Stufe ein Event als relevant einstuft und die KI es angereichert hat (Diagnose, Priorität, Maßnahme), legt ein REST-Aufruf oder Webhook das Work Order automatisch an. Voraussetzung ist ein CMMS mit nutzbarer Schnittstelle — bei Systemen jünger als rund sechs Jahre meist gegeben, bei Altsystemen oft die eigentliche Hürde.
Welches CMMS passt für so einen Workflow?
Jedes mit einer dokumentierten REST- oder Webhook-API. eMaint (Fluke), Fiix und IBM Maximo bieten das nativ. Hat Ihr bestehendes System keine API, ist eine Integrationsschicht — etwa über n8n als Bridge — der pragmatische Weg, statt das CMMS zu wechseln. Den CMMS-Wechsel würden wir nur empfehlen, wenn ohnehin eine Ablösung ansteht.
Läuft die KI lokal oder in der Cloud?
Gemischt, und das ist Absicht. Die Anomalieerkennung gehört aus Latenz- und Souveränitäts-Gründen ans Edge, direkt an die Maschine — das Modell ist leicht genug dafür. Die LLM-Anreicherung kann je nach Datenschutz-Anforderung in der Azure-Cloud oder on-prem laufen. Für regulierte Branchen bauen wir die Anreicherungs-Stufe DSGVO-konform mit europäischem Hosting.
Nächster Schritt
Wenn Sie Sensorik im Werk haben, deren Daten aktuell nur ein Dashboard füttern, ist der Sensor-zu-Ticket-Workflow der Schritt mit dem schnellsten messbaren Effekt. Bringen Sie eine konkrete Anlagengruppe und Ihr CMMS mit — wir klären im Workshop, ob der End-to-End-Pfad in 6 Wochen steht.
Verwandte Themen
→KI-Implementierung im Maschinenbau: eine Case Study
