KI-Wartung für Brückenkrane: RAG-Diagnose & Fehleranalyse

Was bereitet bei einem Brückenkran die größten Sorgen? Nicht die Störung selbst, sondern das fehlende Fachwissen zur Behebung. Wenn der erfahrene Meister, der die alte Anlage seit Jahrzehnten betreut, in Rente geht, blättert der neue Azubi ratlos in einem 300-seitigen Handbuch und findet die richtige Seite nicht. Ein Umrichteralarm kann dann schnell einen ganzen Vormittag vor Ort kosten – die häufigste Klage, die wir bei Wartung und Umbau hören.

KI-Sprachmodelle (Large Language Models, LLMs) haben sich in den letzten zwei Jahren rasant entwickelt. In Kombination mit den Daten aus einem Digitalen Zwilling für Brückenkrane liefern sie wertvollen Kontext für die Fehlerdiagnose. Der Weg von generischen Chatbots hin zu vertikalen Industrieanwendungen ist technisch geebnet. Die Wartung von Brückenkranen ist ein ideales Einsatzszenario für LLMs: Das Wissenssystem ist klar abgegrenzt (nur die vorhandenen Handbücher und Wartungsdokumente), die Fehlermuster folgen erkennbaren Regeln (die häufigsten Alarmcodes umfassen weniger als 100 Typen), und das Entscheidungsrisiko bleibt kontrollierbar (KI liefert Empfehlungen, der Mensch trifft die Entscheidung).

Dieser Beitrag beschreibt den vollständigen Engineering-Ansatz von der Bereitstellung bis zum Betrieb: Lokal installiertes Ollama in Verbindung mit einer RAG-Wissensdatenbank – die Fehlerdiagnose für Brückenkrane liefert sofort Antworten. Die Hardware-Investition liegt bei ca. 30.000–80.000 EUR, ein Industrie-PC versorgt 20–30 Wartungsterminals, und die einmal aufgebaute Wissensdatenbank bleibt dauerhaft nutzbar.

Systemarchitektur im Überblick

Das KI-Wartungsassistenten-System basiert auf einer Drei-Schichten-Architektur. Jede Schicht übernimmt klar definierte Aufgaben, die Kommunikation zwischen den Schichten erfolgt über standardisierte APIs:

Technische Umsetzung im Detail

Die Systemarchitektur wird in vier Schritten aufgebaut, wobei jeder Schritt klar definierte Werkzeuge und Parameter verwendet.

2.1 Modellbereitstellung: Ollama + Qwen2.5

Ollama ist das derzeit ausgereifteste Framework für lokale LLM-Ausführung. Es unterstützt Linux und Windows; nach der Installation per Einzelbefehl steht die API sofort zur Verfügung. Empfohlen wird Alibabas Qwen2.5 14B (14 Mrd. Parameter) – überzeugt durch starke Chinesisch-Kompetenz bei moderaten Hardware-Anforderungen. Die quantisierte 4-bit-Version benötigt lediglich 8 GB VRAM für flüssigen Betrieb.

Bereitstellungsbefehl:

# MontageOllama（UnterstützungGPUAutomatische Erkennung） curl -fsSL https://ollama.com/install.sh | sh # AbrufenQwen2.5 14B（ca.8.5GB） ollama pull qwen2.5:14b # Service starten（Standard127.0.0.1:11434） ollama serve

Dienstvalidierung:

curl http://localhost:11434/api/generate -d '{"model": "qwen2.5:14b","prompt": "Brückenkran-Frequenzumrichter meldetOCMögliche Ursachen für Überstromfehler？Fünf Punkte auflisten","stream": false}'

2.2 Aufbau der RAG-Wissensdatenbank

Das Modellwissen allein genügt nicht – Qwen2.5 kennt zwar das grundlegende Konzept eines Brückenkrans, weiß jedoch nicht, wie die SPS Ihres spezifischen Typs zurückgesetzt wird oder welche Ersatzteile im letzten Jahr getauscht wurden. RAG (Retrieval-Augmented Generation) löst genau dieses Problem: Betriebsanleitungen, Wartungsprotokolle und technische Zeichnungen werden in eine Vektordatenbank eingespeist. Bei jeder Anfrage werden zunächst relevante Dokumente abgerufen, die Ergebnisse in den Prompt integriert und anschließend vom Modell beantwortet.

Ablauf der Wissensdatenbank-Erstellung:

Für die Vektor-Datenbank empfehlen wir ChromaDB – rein in Python implementiert, keine separate Bereitstellung erforderlich, In-Memory-Modus unterstützt. Ideal für den Einsatz auf Industrie-PCs. Als Embedding-Modell empfehlen wir BAAI BGE-small-zh-v1.5 (384 Dimensionen, nur 150 MB, ca. 50 ms Inferenzzeit pro Anfrage auf einer CPU). Es liefert gute Ergebnisse für die semantische Suche im Chinesischen und stellt nur geringe Hardware-Anforderungen.

2.3 Ablauf der Retrieval-Augmented Generation (RAG)

Ein vollständiger Frage-Antwort-Durchlauf läuft wie folgt ab:

from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings import requests embeddings = HuggingFaceEmbeddings( model_name="BAAI/bge-small-zh-v1.5") db = Chroma(persist_directory="./crane_kb", embedding_function=embeddings) question = "Brückenkran-Frequenzumrichter meldetOUBehandlung von Überspannungsfehlern？" docs = db.similarity_search(question, k=4) context = "\\\\n\\\\n".join([d.page_content for d in docs]) prompt = f"""Beantwortung der Benutzerfrage anhand des folgenden Brückenkran-Wartungshandbuchs。 Wenn das Handbuch keine Angaben enthält，sagen"Kein entsprechender Inhalt im Handbuch gefunden"。 Handbuchinhalt： {context} Beantwortung der Benutzerfrage anhand des folgenden Brückenkran-Wartungshandbuchs：{question}""" resp = requests.post( "http://localhost:11434/api/generate", json={"model": "qwen2.5:14b", "prompt": prompt, "stream": False}) print(resp.json()["response"])

Der Kern dieses Prozesses ist das Zusammenstellen des Prompts. Die Qualität des RAG-Ergebnisses hängt weniger vom großen Sprachmodell ab (Qwen2.5 ist völlig ausreichend), sondern vielmehr davon, ob die abgerufenen Dokumente wirklich relevant sind. Wir empfehlen, bei Tests jedes typische Problem manuell zu bewerten (Trefferquote, Antwortgenauigkeit). Liegt die Trefferquote unter 80 %, sollten Sie die Chunking-Strategie oder das Embedding-Modell anpassen.

Empfohlenes Bewertungsskript:

def evaluate_rag(test_qs, db, llm_url): results = [] for q, expected in test_qs: docs = db.similarity_search(q, k=4) hit = any(expected in d.page_content for d in docs) results.append({"q": q, "hit": hit}) rate = sum(1 for r in results if r["hit"]) / len(results) print(f"Retrieval hit rate: {rate:.1%}") return results

Typische Anwendungsfälle

3.1 Unterstützte Fehlerdiagnose (häufigster Anwendungsfall)

Ein Wartungstechniker gibt die Fehlersymptome auf einem Mobiltelefon oder Tablet ein, und die KI liefert mögliche Ursachen und Handlungsschritte. Am Beispiel eines OC-Überstromfehlers (OC = Over Current) eines Frequenzumrichters:

3.2 Wartungsanleitung (mit Schritt-für-Schritt-Anleitung)

Die KI sagt nicht nur, was los ist, sondern auch, welche Schraube zuerst gelöst werden muss. Jede Wartungsmaßnahme ist im Wissensspeicher als standardisierter Ablauf dokumentiert:

Benutzer fragt：Wie tauscht man den Bremsbelag der Brückenkranbremse aus？ AIAntwort：Folgende Schritte für den Austausch—— 1. Spannungsfrei schalten und abschildern，Sicherstellen, dass die Bremse gelöst ist 2. Befestigungsschrauben des Staubschutzes entfernen（M8 x 4） 3. Bremsfeder mit Spezialwerkzeug zusammendrücken 4. Passstift des Reibbelags herausziehen 5. Alten Reibbelag entnehmen（Auf Einbaulage (Vorderseite/Rückseite) achten） 6. Neuen Reibbelag einbauen（Gleiche Dicke sicherstellen） 7. Feder entlasten，Staubschutz wieder anbringen 8. Bremsspiel einstellen（charakteristischer Wert0.5~1.0mm） 9. Einschalten und Probelauf：Heben im Tippbetrieb3Mal，Kein ungewöhnliches Geräusch feststellen

3.3 Fehlerhistorie und Trendanalyse

Die KI wertet die Fehlerprotokolle des vergangenen Jahres aus und identifiziert wiederkehrende Probleme. Über die Schnittstelle zur Fernüberwachungsplattform des Brückenkrans ergänzt die KI bei einer Fehlerabfrage automatisch Hinweise wie: „Dieser Brückenkran hatte in den letzten 3 Monaten viermal denselben Fehler. Wir empfehlen, den Hersteller für eine systematische Prüfung zu kontaktieren."

4. Technische Parameter im Überblick

5. Umsetzung in der Praxis

1. Die Qualität der Wissensdatenbank entscheidet über alles. Das große Sprachmodell ist nur die Maschine – die eigentliche Arbeit leistet die Wissensdatenbank. Nehmen Sie sich vor dem Start mindestens eine Woche Zeit, um die vollständige Dokumentation Ihres Brückenkrans zusammenzutragen: Betriebsanleitung, Stromlaufplan, PLC-Programmkommentare und die Fehlerhistorie. Falls die historischen Wartungsprotokolle nicht digital vorliegen, beauftragen Sie jemanden, die Papierprotokolle in Markdown zu übertragen. Die Qualität der Wissensdatenbank bestimmt direkt die Genauigkeit der KI-Antworten – hier lohnt sich jeder investierte Zeitaufwand.

2. Prompt-Vorlagen müssen iterativ optimiert werden. Dieselbe Frage führt ohne System-Prompt zu einer deutlich schlechteren Antwort als mit einem sorgfältig ausgearbeiteten Prompt. Empfohlenes Format: Der System-Prompt des KI-Assistenten für den Brückenkran enthält eine Rollendefinition („Sie sind ein Wartungsingenieur für Brückenkrane mit 15 Jahren Erfahrung"), Antwortrichtlinien („Nennen Sie zuerst die wahrscheinlichste Ursache, dann die Prüfschritte mit jeweiliger Zeitangabe") und einen Haftungsausschluss („Dies ist ein KI-gestützter Vorschlag; die endgültige Wartung ist von qualifiziertem Personal zu bestätigen").

3. Lokale Bereitstellung ist günstiger als gedacht. Viele gehen davon aus, dass große Sprachmodelle zwingend eine A100-GPU benötigen. Tatsächlich läuft Qwen2.5 7B quantisiert problemlos auf einer RTX 3060 – ein Industrie-PC mit 20–30 gleichzeitigen Endgeräten ist völlig ausreichend. Bei geringeren Geheimhaltungsanforderungen ist auch eine Cloud-Lösung denkbar – Qwen über die Alibaba-Cloud-API oder DeepSeek-API, abgerechnet pro Token. Für industrielle Anwendungen empfehle ich jedoch die lokale Bereitstellung: Die Daten verlassen das Netzwerk nicht, und die Latenz bleibt stabil unter 1–3 Sekunden.

4. Erwarten Sie nicht, dass KI den Menschen ersetzt. Die Rolle des großen Sprachmodells in der Kranwartung ist die eines „Hilfswerkzeugs" – es verkürzt die Recherchezeit, liefert Wartungsansätze und reduziert die Abhängigkeit von Erfahrungswissen. Die eigentliche Durchführung und die endgültige Entscheidung bleiben beim Wartungstechniker. Wenn diese Positionierung im Werk klar kommuniziert wird, steigt die Akzeptanz spürbar.

5. Mit einfachen Anwendungsfällen beginnen, nicht sofort alles abdecken wollen. In der ersten Phase empfehle ich nur zwei Funktionen: „Umrichteralarm-Code-Abfrage" und „Intelligente Suche im Wartungshandbuch". Nutzen Sie 1–2 Wochen, um diese Funktionen zu testen, Feedback zu sammeln und die Wissensdatenbank zu optimieren. Für einen Überblick über die Gesamtarchitektur der prädiktiven Wartung von Kranen verweisen wir auf unseren früheren Beitrag Prädiktive Wartung und PHM-System für Krane. In der zweiten Phase erweitern Sie das System um die Fehlerdiagnose für Kranbrücke und Laufkatze. In der dritten Phase folgt die Analyse historischer Daten. Durch die schrittweise Einführung mit sichtbaren Ergebnissen in jeder Phase steigt die Akzeptanz bei den Nutzern.

Fazit

KI-Sprachmodelle sind in der Brückenkran-Wartung kein Selbstzweck – wenn ein Wartungstechniker vor Ort sein Mobiltelefon zückt, ein Foto des Umrichteralarms macht und 30 Sekunden später die Fehlerursache und die nächsten Schritte erhält, bedarf der Wert dieses Systems keiner Erklärung. Wir haben das System drei Monate lang in zwei Werkstätten getestet. Die durchschnittliche Zeit zur Fehlerlokalisierung sank von 40 auf 15 Minuten, wobei häufige Umrichterfehler nahezu in Sekundenschnelle diagnostiziert werden.

Die technischen Anforderungen an das Gesamtsystem sind überschaubar: ein Industrie-PC mit Grafikkarte, eine Ollama-Instanz, eine Vektordatenbank und eine strukturierte Wissensdatenbank. Der größte Zeitaufwand liegt nicht in der Softwareinstallation, sondern darin, das Wartungswissen erfahrener Techniker in die Wissensdatenbank zu überführen – genau das ist jedoch der wertvollste Teil.

Häufig gestellte Fragen