Field-Service-Copilot: Multimodal GraphRAG mit SAP-PLM, Sensor, CAD

Pexon Consulting | 11 Min. Lesezeit | 13.06.2026

TL;DR

Field Service Copilot ist 2026 der vermutlich anspruchsvollste produktive RAG-Use-Case im Maschinenbau-Aftermarket: Der Service-Techniker vor Ort braucht in 30 Sekunden eine Diagnose, die Daten aus SAP-PLM (Stamm- und Wartungs-Daten), dem Service-Manual (PDFs), Sensor-Telemetrie (Live-Daten aus der Maschine) und CAD-Zeichnungen (Geometrie der Komponenten) zusammenführt. Klassisches Single-Source-RAG schafft das nicht — wir bauen Multimodal-GraphRAG mit Live-Telemetrie-Integration.

Warum Field-Service besonders schwierig ist

Wir hören das in fast jedem Erstgespräch mit Service-Verantwortlichen im Maschinenbau: Der Service-Techniker steht vor einer Maschine mit einem Fehler-Code. Um den Fehler zu diagnostizieren, braucht er typisch: die Maschinen-Historie aus SAP-PLM (Welche Wartungen wurden durchgeführt, wann wurden Komponenten getauscht), das relevante Kapitel des Service-Manuals (typisch 200-1.500 Seiten dick), die aktuellen Sensor-Werte (Drücke, Temperaturen, Vibrationen), und manchmal die CAD-Zeichnung des betroffenen Bauteils.

Aktuell läuft das so: Techniker ruft die Hotline an, beschreibt das Problem, der Service-Engineer im Hauptsitz klickt sich durch fünf Tools, kompiliert die Antwort, ruft zurück. Hin-und-Her-Zeit typisch 20-45 Minuten pro Diagnose. Bei einem Mittelständler mit 60 Service-Technikern und je 8-12 Diagnose-Vorfällen pro Woche sind das 320-540 Stunden pro Woche allein für die Hotline-Diagnostik.

Klassisches RAG kann das nicht lösen, weil die Datenquellen strukturell verschieden sind. Tabellarisch (SAP), Volltext (Manual), Zeitreihen (Sensor), Geometrie (CAD). Ein einzelnes Embedding-Modell deckt diese Vielfalt nicht ab.

Was Multimodal GraphRAG mit Telemetrie macht

Architektur in vier Schichten.

Schicht 1: Maschinen-Identifikation. Beim Aufruf identifiziert der Copilot die Maschinen-Instanz (Seriennummer, Standort, Kunden-ID). Daraus folgen alle nachgelagerten Anfragen — kein blindes Suchen, sondern gezielter Lookup.

Schicht 2: Multimodale Datenquellen. Vier parallele Anfragen. SAP-PLM liefert die Wartungs-Historie. Service-Manual liefert die relevanten Kapitel (vom CAD-Schaltplan über die Wartungs-Schritte). Sensor-Telemetrie liefert die aktuellen Mess-Werte über OPC-UA-Connector. CAD-Repository liefert die Geometrie-Skizze des betroffenen Bauteils.

Schicht 3: Knowledge Graph als Verbindungs-Layer. Hier liegt der Unterschied zu klassischen Multi-Source-Setups. Die Datenquellen werden nicht nur parallel angezapft, sondern über einen Knowledge Graph verbunden. Knoten: Maschine, Komponente, Wartungs-Vorgang, Fehler-Code, Sensor-Messpunkt, CAD-Geometrie. Beziehungen: Maschine --hasComponent--> Komponente, Komponente --readBySensor--> Sensor, Komponente --depictedIn--> CAD, Komponente --maintainedBy--> Vorgang.

Damit kann der Copilot Multi-Hop-Anfragen beantworten: „Welche Komponenten sind mit Fehler-Code 4711 historisch verbunden, welche Sensoren überwachen sie, welche CAD-Schaltpläne zeigen sie, welche Wartungs-Vorgänge wurden in den letzten 12 Monaten durchgeführt“.

Schicht 4: Vision-LLM für CAD-Zeichnungen. Der Vision-Anteil ist Claude Opus 4.7 Vision oder GPT-4o, das die CAD-Schaltpläne plus Sensor-Werte als Bild plus Text verarbeitet und in die Antwort einbaut. Mehr im CAD-Vision-Blog.

Sensor-Telemetrie als Echtzeit-Komponente

Das ist die Komponente, die klassisches RAG nicht hat. Bei einer Diagnose-Anfrage holt der Copilot die letzten 24-72 Stunden Sensor-Daten der relevanten Mess-Punkte und gibt sie als strukturierten Input an das LLM. Damit wird die Antwort nicht „generisch was Fehler 4711 bedeutet“, sondern „Fehler 4711 typisch verbunden mit Temperatur-Spike, eure Maschine zeigt eine Temperatur-Anomalie seit 3 Stunden 27 Minuten — wahrscheinliche Ursache: Lüfter X blockiert“.

Die OPC-UA-Anbindung ist Standard-Engineering — wir bauen das mit dedizierten Edge-Connectors, die die letzten Mess-Daten gecached vorhalten, sodass Diagnose-Anfragen unter 2 Sekunden Latenz haben.

Wichtig: Sensor-Werte werden nicht im LLM-Speicher gehalten — sie kommen frisch zu jeder Anfrage. Damit bleibt die Diagnose auf dem aktuellen Stand, ohne dass der Knowledge Graph permanent aktualisiert werden muss.

Pilot-Ergebnisse aus einem Maschinenbauer

Konkrete Hausnummern aus einem Pilot 2025/2026. Sondermaschinenbauer mit 60 Service-Technikern weltweit, 2.800 installierte Maschinen, durchschnittlich 480 Diagnose-Anfragen pro Woche.

Der First-Time-Fix-Effekt ist der eigentliche Wert. Wenn der Techniker beim ersten Einsatz das richtige Ersatzteil dabei hat, fallen zweite Anreisen weg — was bei 60 Technikern und durchschnittlich 200-400 EUR Anreise-Kosten pro Wiederholungs-Einsatz schnell ins Geld geht.

Pexon-Sprint für Field-Service-Copilot

Wir liefern das als 14-20-Wochen-Sprint mit festem Preis. Lieferumfang: SAP-PLM-Anbindung über OData, Service-Manual-Indexierung mit RAG-Pipeline, OPC-UA-Anbindung an Maschinen-Sensoren, CAD-Repository-Anbindung mit Vision-LLM, Knowledge Graph mit allen Verbindungen, mobile PWA für Service-Techniker, Schulung der Power-User.

Investment 220-340k EUR je nach Maschinen-Diversität und Sensor-Anbindungs-Tiefe.

Häufig gestellte Fragen

Wie verhält sich das mit der OT-IT-Trennung?

Die OPC-UA-Verbindungen laufen über klar definierte Edge-Gateways in der DMZ. Sensor-Werte werden gepullt, nicht direkt im IT-Netz angesprochen. Bei besonders sensitiven Anlagen (Defence, KRITIS-Tier-1) bauen wir Air-Gap-Varianten — Daten werden zeitlich verzögert übertragen statt Echtzeit.

Was bei Maschinen ohne IoT-Anbindung?

Häufiger Fall in der Bestands-Maschinen-Flotte. Wir reduzieren auf SAP-PLM + Manual + CAD, ohne die Sensor-Komponente. Diagnose-Qualität sinkt um 15-25 Prozentpunkte, ist aber immer noch besser als die Bestands-Hotline.

Funktioniert das auch mit eurem System statt SAP-PLM?

Ja, alle gängigen PLM/ERP-Systeme sind unterstützt. Bei Teamcenter, Windchill, Aras nutzen wir die jeweiligen REST/OData-APIs. Bei kleineren ERP-Systemen (proAlpha, infor) bauen wir custom Connectors.

Wie lange dauert der initiale Knowledge-Graph-Aufbau?

Bei einem typischen 1.500-Maschinen-Bestand etwa 4-6 Wochen Aufbau mit LLM-Unterstützung. Service-Experten reviewen und korrigieren. Danach inkrementelles Update bei jedem neuen Maschinen-Typ oder Manual-Update.

Wie messen wir den Erfolg?

Wir bauen ein Dashboard, das die wichtigsten Metriken trackt: Anzahl Hotline-Anrufe, durchschnittliche Diagnose-Zeit, First-Time-Fix-Rate, Reise-Reduktion. Plus User-Feedback pro Diagnose-Output, das in die Eval-Pipeline für Verbesserungen fließt.

Nächster Schritt

Wenn dein Service-Team unter Diagnose-Druck steht und ihr SAP-PLM, Service-Manuals plus IoT-Daten habt: Wir machen einen 60-Minuten-Architektur-Call mit dir und idealerweise dem Service-Leiter. Du beschreibst die Datenquellen-Landschaft, wir skizzieren das Copilot-Setup mit Festpreis.

Verwandte Themen