SPS-Störungsmeldungen automatisch diagnostizieren

Das echte Ausmaß des Problems

Fehlersuche in modernen SPS-Systemen ist kein Problem von gestern — im Gegenteil. Je komplexer die Maschinen werden, desto mehr Fehlercodes und Diagnosebits gibt es, und desto weniger Wartungstechniker kennen alle auswendig.

Die Realität im Mittelstand: Bei ungeplanten Ausfällen einer Produktionsmaschine verbringen Techniker im Schnitt 30 bis 50 Prozent der Reparaturzeit mit der Fehlersuche, nicht mit der Reparatur. Eine Auswertung von Service-Einsätzen an über 80 Siemens-SPS-Installationen (2025) zeigt: 60 Prozent der Ausfälle wären mit besserer Dokumentation und systematischer Diagnosevorbereitung vermeidbar gewesen — sie gehen nicht auf Hardware-Versagen zurück, sondern auf Bedienungsfehler, veraltete Parametereinstellungen und unbekannte, aber wiederkehrende Fehlermuster.

Das Problem verschärft sich mit jeder neuen Maschine: Jeder Maschinentyp hat sein eigenes Handbuch, seine eigene Fehlerlogik, seine eigenen Kalibrierungsparameter. Wer im Betrieb drei oder vier verschiedene Maschinentypen fährt, braucht entweder Techniker mit sehr breiter Erfahrung — oder ein System, das diese Erfahrung an den Ort der Störung bringt.

Die Kosten sind unbarmherzig: Laut Siemens-Auswertung von 2024 (analysiert von IndexBox) kosten Netzwerk- und Produktionsausfälle Fortune-500-Hersteller im Schnitt rund 260.000 US-Dollar pro Stunde pro Anlage. Für den deutschen Mittelstand liegt die Zahl bescheidener, aber immer noch schmerzhaft: 500 bis 2.000 Euro pro Stunde Stillstand für eine mittlere Produktionsmaschine. Ein Pharmahersteller mit Reinraumanforderungen zahlt das Drei- bis Fünffache. Dauert die Fehlersuche im Schnitt 2 bis 3 Stunden, kostet ein ungeplanter Ausfall 1.000 bis 6.000 Euro — bevor überhaupt die erste Schraube gelöst ist.

Das Alarmflut-Problem: Warum Fehlercodes allein nicht reichen

Moderne SPS-Systeme generieren bei einer Störung nicht einen einzigen Fehlercode. Sie generieren Dutzende — manchmal Hunderte — von Alarm-Ereignissen in wenigen Minuten. Dieses Phänomen hat einen Namen in der Automatisierungstechnik: Alarm Flood (Alarmflut).

Der ANSI/ISA-18.2-Standard definiert eine Alarmflut als mehr als 10 Alarme innerhalb von 10 Minuten. In der Praxis sehen Wartungstechniker bei größeren Störungen 50 bis 200 Meldungen — überlagert, kaskadierend, ohne klare Kausalstruktur. Der erste Alarm ist oft nicht die Ursache, sondern eine Folgeerscheinung. Das eigentliche Problem liegt drei Ebenen tiefer in der Logik.

Klassische Alarmmanagement-Systeme (SCADA-Alarmlisten, HMI-Protokolle) zeigen dir was gemeldet wurde — aber nicht warum und in welcher Reihenfolge die kausale Kette verlief. Ein LLM-basiertes Diagnosesystem kann die zeitliche Abfolge der Alarm-Ereignisse, die Sensor-Zustandswerte und die historischen Reparaturberichte gemeinsam auswerten und daraus die wahrscheinlichste Ursachenkette ableiten. Das ist der Kernvorteil gegenüber einem einfachen Fehlercode-Nachschlagewerk.

Das SPS-Protokoll-Ökosystem — was du wirklich vorfindest

Bevor du eine KI-Diagnose aufbaust, musst du verstehen, was deine Maschinen überhaupt an Daten liefern können. Die SPS-Landschaft in deutschen Fertigungsbetrieben ist nicht homogen — und die Anbindungsmöglichkeit hängt stark vom Hersteller und Baujahr ab.

Siemens SIMATIC S7 (S7-300, S7-400, S7-1200, S7-1500) Die mit Abstand häufigste SPS in Deutschland. Die alten S7-300- und S7-400-Baureihen (Baujahr vor 2010) sprechen kein OPC UA nativ — du brauchst entweder einen OPC-UA-Gateway (z. B. Softing oder KEPServerEx) oder eine Kommunikationskarte mit S7-TCP/IP. Neuere S7-1500- und S7-1200-Steuerungen haben OPC-UA-Server integriert und sind direkt ansprechbar. Im TIA Portal lässt sich der Diagnose-Puffer per Programm auslesen und an externe Systeme exportieren.

Beckhoff TwinCAT (TwinCAT 2, TwinCAT 3) TwinCAT 3 hat OPC-UA nativ eingebaut und gilt als eines der integrations-freundlichsten SPS-Systeme auf dem Markt. Der OPC-UA-Server läuft direkt auf dem PLC-Prozess, nicht als externes Add-on. Diagnosedaten, Programm-Variablen und Alarm-Events sind per Standard-Interface abrufbar. Das macht Beckhoff-Installationen technisch zum einfachsten Ausgangspunkt für eine KI-Diagnose-Pipeline.

Rockwell Automation / Allen-Bradley (ControlLogix, CompactLogix) In Nordamerika und in exportorientierten deutschen Maschinenbauunternehmen mit Kunden in den USA häufig anzutreffen. Allen-Bradley nutzt das proprietäre EtherNet/IP-Protokoll — OPC-UA ist über FactoryTalk Gateway oder KEPServerEx als Adapter erhältlich. Direkte OPC-UA-Unterstützung hat Rockwell erst mit neueren Controllern (CompactLogix 5380+) eingeführt. Ältere Installationen erfordern Middleware.

Fazit für die Praxis: Fragt vor dem Projektstart, welche SPS-Generationen und -hersteller ihr im Betrieb habt. Ein gemischter Maschinenpark mit S7-300 (kein OPC UA), Beckhoff TwinCAT (OPC UA nativ) und alten Allen-Bradley-Steuerungen (EtherNet/IP) braucht ein Protokoll-Gateway als erste Investition — bevor irgendetwas in Richtung KI passieren kann.

Mit vs. ohne KI — ein ehrlicher Vergleich

Die Vergleichswerte stammen aus Interviews mit Maschinenherstellern und Wartungsdienstleistern in Deutschland sowie aus Praxisberichten der industriellen Automatisierungs-Community. Die Einsparung ist nicht nur Zeit, sondern auch die Vermeidung von Fehldiagnosen, die zu unnötigem Teileaustausch und zusätzlichen Stillständen führen.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5) 30 bis 60 Minuten Diagnosezeit je Störfall sind messbar und real — das ist nicht der größte Hebel im Vergleich zur Bildverarbeitung oder automatisierten Maschinendokumentation, die Zeit in Stunden sparen, aber bei häufigen Störungen und hohen Stillstandkosten absolut relevant. Warum nicht 5? Weil die Reparaturzeit selbst nicht sinkt — nur die Diagnose wird schneller.

Kosteneinsparung — mittel (3/5) Die Einsparung ergibt sich indirekt: kürzere Ausfallzeiten, weniger Eskalationen an den Hersteller-Support, Vermeidung von Fehldiagnosen. Weniger greifbar als bei der Optimierung des Energieverbrauchs, wo du direkt Kilowattstunden einsparst. Die ROI-Rechnung braucht realistische Stillstandkosten deiner Anlage.

Schnelle Umsetzung — mittel (3/5) 8 bis 12 Wochen für einen produktiven Pilot mit einem Maschinentyp sind realistisch: Dokumente sammeln, OPC-UA-Anbindung konfigurieren, Reparaturberichte indexieren, Prompts justieren, Feldtest mit echten Störfällen. Das geht schneller als Bildverarbeitung oder Predictive Maintenance (die Monate an Trainingsdaten braucht), aber langsamer als eine einfache Chatbot-Einbindung. Wer ältere SPSen ohne OPC UA hat, addiert 2–4 Wochen für die Gateway-Einrichtung.

ROI-Sicherheit — hoch (4/5) Diagnosezeit ist direkt messbar — du kannst vor und nach der Einführung stoppen, wer wie lange an der Fehlersuche arbeitet. Das macht die Rechnung transparenter als bei indirekten Effekten. Der einzige Unsicherheitsfaktor ist die Qualität der vorhandenen Dokumentation — schlechte Handbücher führen zu schlechteren KI-Diagnosen.

Skalierbarkeit — niedrig (2/5) Das ist die echte Schwäche: Jeder neue Maschinentyp braucht seine eigene Wissensbasis. Wenn du heute eine KEBA-Spritzgießanlage, morgen eine Negri Bossi und nächste Woche eine Krauss Maffei kaufst, musst du jedes Mal von vorne dokumentieren und einpflegen. Das Modell lässt sich nicht einfach auf die nächste Maschine übertragen — es ist maschinentyp-spezifisch, nicht universell.

Richtwerte — stark abhängig von Stillstandkosten der Anlage, Verfügbarkeit von Maschinendokumentation und vorhandener OPC-UA-Anbindung.

Was ein KI-Diagnose-System konkret macht

Ein SPS-Diagnose-System kombiniert drei Komponenten:

OPC-UA-Datenanbindung: Moderne SPS-Systeme sprechen OPC UA — einen offenen Standard für Industrie-4.0-Kommunikation. Das System verbindet sich mit der SPS, liest in Echtzeit Fehlercodes, Diagnosebits, Sensor- und Stellgliedwerte aus und speichert sie zur Analyse. Ältere Steuerungen ohne nativen OPC-UA-Support werden über Protokoll-Gateways eingebunden.

Wissensbasis aus Dokumentation: Alle Maschinenhandbücher, Schaltpläne, Fehler-Nachschlagewerke und internen Reparaturberichte werden in eine durchsuchbare Basis eingespielt. Das RAG-Verfahren (Retrieval-Augmented Generation) sorgt dafür, dass das System nur auf tatsächlich vorhandene Dokumentation antwortet — kein Erfinden, keine Halluzination.

Strukturierte Diagnoseausgabe: Tritt eine Störung auf, erzeugt das System einen Diagnosebericht: Fehlercode interpretiert, wahrscheinliche Ursachen mit Quellenangabe aus der Dokumentation, zeitliche Abfolge der Alarm-Ereignisse ausgewertet, Selbsthilfeschritte oder Eskalationsempfehlung (“Hersteller anrufen” versus “bekanntes Problem, Lösung im Servicehandbuch S. 342”).

Das System ersetzt nicht das Urteil des Technikers — es beschleunigt die Diagnose. Ein Berufsanfänger mit guter KI-Unterstützung findet die richtige Ursache schneller als ein Senior-Techniker, der ohne System durchs Handbuch blättern muss.

Die OPC-UA-Pipeline konkret: Vom Fehlerbit zur Diagnose

Die technische Kette hinter einem SPS-Diagnose-System ist weniger komplex als sie klingt — aber sie hat drei Integrationspunkte, an denen Projekte in der Praxis stecken bleiben.

Schritt 1 — Datenerfassung (OPC-UA-Server → Datenpuffer) Die SPS läuft als OPC-UA-Server. Ein leichtgewichtiger Client — zum Beispiel Node-RED mit dem node-red-contrib-opcua-Paket — verbindet sich bei jeder Alarm-Aktivierung oder zyklisch (alle 5–30 Sekunden) und liest den Diagnose-Puffer aus. Die Rohdaten (Alarm-Code, Zeitstempel, Kanal-ID, Sensor-Zustand) gehen in eine Zeitreihendatenbank wie InfluxDB.

Schritt 2 — Kontext-Anreicherung (Zeitreihen → strukturierter Kontext) Das Diagnose-System aggregiert die letzten N Alarm-Ereignisse (z. B. 30 Minuten vor der Haupt-Störung), korreliert sie mit Sensor-Werten aus InfluxDB und formuliert einen strukturierten Kontext-Block für das LLM: “Fehlercode 4731 aufgetreten; vorangegangene Alarme: Temperatur-Warnung bei 62 °C (vor 18 Min.), Kommunikations-Timeout PE-Modul (vor 11 Min.); letzter Maschinenzyklus normal beendet.”

Schritt 3 — LLM-Diagnose (Kontext + Wissensbasis → Diagnosebericht) Das LLM (z. B. Claude über API) empfängt den Kontext-Block zusammen mit den relevanten Handbuch-Abschnitten aus der RAG-Wissensbasis und gibt einen strukturierten Bericht aus: Ursache, Wahrscheinlichkeit, Quellenangabe, Handlungsschritte.

Wo Projekte stecken bleiben: Schritt 1 ist oft der aufwendigste — nicht wegen der Technologie, sondern weil OT-Netzwerke und IT-Systeme häufig physisch getrennt sind (Demilitarisierte Zone). Den Weg vom SPS-Netzwerk in die Unternehmens-IT zu öffnen erfordert die Abstimmung zwischen Produktion, IT-Security und manchmal dem Maschinenhersteller. Plane dafür 2–4 Wochen Abstimmungsaufwand ein.

Konkrete Werkzeuge — was wann passt

Claude oder Gemini als LLM-Kern Beide Modelle sind auf technische Dokumente trainiert und können komplexe Fehlerlogik in strukturierten Ausgaben darstellen. Claude hat eine größere Kontextlänge (bis 200.000 Token), was hilft, wenn du Handbücher mit Hunderten von Seiten verarbeitest. Gemini ist bei hohem Durchsatz günstiger. Beide erlauben API-Nutzung ohne Training auf deinen Daten, wenn du das im Vertrag festlegst.

Node-RED für die OPC-UA-Pipeline Visueller Flow-Editor mit über 5.000 Community-Nodes — darunter vollständige OPC-UA-Client-Nodes für Siemens S7 (via S7-Protokoll), Beckhoff TwinCAT und alle anderen OPC-UA-Server. Kostenlos und selbst-hostbar. Ideal, um den Daten-Pipeline-Schritt von der SPS in die Zeitreihendatenbank zu realisieren, ohne eigenen Code schreiben zu müssen.

Siemens Industrial Edge oder Siemens Insights Hub für größere Siemens-Umgebungen Wenn du bereits tief in Siemens-Automatisierung investiert hast, bringt Industrial Edge vorkonfigurierte OPC-UA-Konnektoren und direkte S7-1500-Anbindung mit. Die Diagnose-App läuft dann am Edge-Device direkt in der Produktion, ohne Cloud-Latenz. Insights Hub ist die werkübergreifende Cloud-Variante für Betriebe mit mehreren Standorten.

InfluxDB für Zeitreihendaten Um Störungen rückwirkend zu analysieren und Muster zu erkennen (“Dieser Fehler tritt immer auf, wenn die Temperatur über 65 °C steigt”), brauchst du eine Zeitreihendatenbank. InfluxDB ist Open Source, läuft on-premise und ist günstig im Betrieb. Die OSS-Version ist kostenlos.

Eigenes RAG mit Chroma oder Weaviate als Vektordatenbank Für maximale Kontrolle über deine Reparaturberichte und Wissensbasis: Chroma (Open Source, kostenlos) oder Weaviate (selbst hostbar, EU-DSGVO-konform) als Vektorspeicher, Handbücher und Reparaturberichte als indexiertes Wissen, Claude oder Gemini für die Diagnoseantwort. Das ist die Variante mit den niedrigsten laufenden Kosten und der höchsten Datenkontrolle. Erfordert initiale Entwicklerarbeit, aber danach vollständige Unabhängigkeit von Cloud-Diensten.

Zusammenfassung — wann welcher Ansatz:

• Siemens-SPS, Siemens-First-Strategie → Siemens Industrial Edge
• Beckhoff oder gemischter Maschinenpark → Node-RED + InfluxDB + eigene RAG-Pipeline
• Mehrere Standorte, zentrale Auswertung → Siemens Insights Hub
• Datenkontrolle und Kostenoptimierung → Chroma + Claude API on-premises

Datenschutz und Datenhaltung

Reparaturberichte enthalten oft sensible Informationen: Betriebsparameter, Fehlerfrequenzen, standortbezogene Ausfallmuster. Das fällt zwar nicht unter die DSGVO — es sind keine personenbezogenen Daten —, aber sehr wohl unter Betriebsgeheimnis und den Schutz von Geschäftsgeheimnissen gegenüber Maschinenhersteller und Wettbewerbern.

Datenhaltungs-Empfehlungen je Tool:

• Claude und Gemini erlauben API-Nutzung ohne Speicherung von Trainingsdaten, wenn du das explizit per Enterprise-Vertrag vereinbarst. Anthropic und Google bieten beide AVV (Auftragsverarbeitungsvertrag) an.
• Chroma und Weaviate (selbst gehostet) — Daten verlassen das Unternehmen nicht. Maximale Kontrolle.
• Siemens Industrial Edge verarbeitet Daten lokal am Edge-Device; nur explizit konfigurierte Datenpunkte gehen optional in die Cloud. Siemens ist ein deutsches Unternehmen, DSGVO-konforme Datenhaltung in der EU ist Standard.
• InfluxDB on-premises: kostenlos und vollständig unter eigener Kontrolle. InfluxDB Cloud hostet auf US-Servern — für sensible Betriebsdaten die schlechtere Wahl.

Besondere Vorsicht bei: Rezeptur- und Verfahrensdaten in der Pharmaindustrie sowie Sicherheits-SPS-Daten (Safety-PLCs für Maschinenverriegelungen). Diese Daten sollten nie in eine externe Cloud gehen — hier ist ein vollständig selbst gehostetes System Pflicht.

Was es kostet — realistisch gerechnet

Einrichtung:

• Dokumente digitalisieren und per OCR erfassen: 2.000–8.000 € (abhängig von Handbuchvolumen und Format)
• OPC-UA-Gateway einrichten (bei älteren SPS ohne nativen OPC-UA-Support): 2.000–6.000 € (Software-Lizenz + Konfigurationsaufwand)
• Reparaturberichte indexieren und aufbereiten: 5.000–15.000 € (intern oder über einen externen Dienstleister)
• RAG-System aufbauen (eigenentwickelt oder als Managed Service): 8.000–25.000 € (abhängig von Komplexität)

Laufende Kosten:

• LLM-API-Kosten (Claude oder Gemini): 300–1.500 € pro Monat (abhängig von Störungshäufigkeit und Abfragevolumen)
• Vektordatenbank-Hosting (Chroma selbst gehostet oder Weaviate Cloud): 0–400 € pro Monat
• InfluxDB on-premises: 0 € (Open Source)
• Pflege und laufende Dokumentations-Updates: 1.500–3.000 € pro Monat (interne oder externe Ressource)

Gesamtrechnung (konservativ):

• Einrichtung: 17.000–54.000 €
• Monatlich: 1.800–4.900 €
• Amortisation nach 6–10 Monaten, wenn die Maschine im Schnitt 2–3 Ausfälle pro Woche hat und jeder Ausfall 1.500 € Stillstandkosten verursacht. In einem konservativen Szenario (30 % der theoretischen Einsparung) amortisiert sich das System in 12–18 Monaten.

Vier typische Einstiegsfehler

Fehler 1: Die SPS-Anbindung unterschätzt Du planst 2 Wochen für die technische Einrichtung ein — und stehst nach 6 Wochen immer noch vor der Frage, wie du das OT-Netzwerk mit dem IT-Netzwerk verbindest. Das ist in vielen Betrieben eine Sicherheits-, Infrastruktur- und Zuständigkeitsfrage, keine technische. Was hilft: Frühzeitig klären, ob euer IT-Security-Team OT-zu-IT-Traffic durch eine Demilitarisierte Zone erlaubt, und wer der Ansprechpartner auf Produktionsseite für Netzwerkfragen ist.

Fehler 2: Zu wenig Zeit für die Aufbereitung der Dokumente Du sammelst alle Handbücher, lädst sie ins RAG-System und erwartest, dass es funktioniert. In Wirklichkeit stecken die Handbücher voller Ungenauigkeiten, widersprüchlicher Versionen und schlecht gescannter Seiten. In den ersten zwei bis drei Monaten sind die Diagnosen dann schlecht, weil das Modell aus schlechten Dokumenten schlechte Ausgaben liefert. Was hilft: 4–8 Wochen Dokumentenpflege und Test mit echtem Techniker-Feedback einplanen.

Fehler 3: Keine Rückkopplung mit den Technikern Du trainierst das System am Schreibtisch und rollst es dann in der Werkstatt aus. Die Techniker sagen: “Das Ding schlägt immer Unsinn vor.” Das Modell braucht echtes Feedback aus den Reparaturberichten — wer hat den Fehler tatsächlich behoben, was war die wirkliche Ursache? Ohne diese Rückkopplung stagniert die Qualität. Was hilft: Eine feste Rückmeldeschleife einbauen — Techniker geben nach jeder Reparatur an, ob die KI-Diagnose hilfreich war (ja/nein/teilweise), und das System lernt daraus.

Fehler 4: Die Wissensbasis veraltet still Nach einem Jahr merkst du: Neue Maschinenversionen, neue Fehlercodes, neue Verfahrensdokumente sind nicht in deiner Basis. Das System stützt sich auf veraltete Informationen und gibt Diagnosen, die zum alten Hardware-Stand passen, nicht zum aktuellen. Das ist gefährlicher als gar kein System — denn es klingt selbstbewusst und irrt sich. Was hilft: Klare Verantwortung festlegen — wer aktualisiert die Dokumentation, sobald es neue Maschinensoftware gibt? Ohne aktive Pflege sinkt der Nutzen innerhalb von 12–18 Monaten deutlich.

Was mit der Einführung wirklich passiert — und was nicht

Was passiert: Die ersten Wochen sind frustrierend. Die Techniker sind skeptisch: “Noch ein IT-System, das uns Zeit kostet.” Viele überlesen die KI-Diagnose und greifen zum Handbuch, weil sie dem System nicht vertrauen. Das ist normal — Vertrauen entsteht durch echte, nachprüfbare Erfolge.

Nach 4–6 Wochen mit echtem Feedback ändert sich das. Wenn die KI drei Störungen hintereinander richtig diagnostiziert, fangen auch Berufsanfänger an, das System zu nutzen — nicht weil es angeordnet wurde, sondern weil es funktioniert und Zeit spart.

Die stärksten Treiber für die Akzeptanz sind:

• Störungen, die selten sind, aber teuer (1–2 Mal pro Monat, 5.000 € pro Ausfall): Dort spart das System sichtbar Zeit.
• Jüngere Techniker, die sich ohnehin unsicher fühlen: Sie nutzen das System als Sicherheitsnetz — wenn KI und Handbuch übereinstimmen, sind sie sicherer in der Entscheidung.
• Nachtschichten und Wochenenddienste: Wenn der Senior-Techniker nicht erreichbar ist, wird die KI-Diagnose zum Rettungsanker.

Was nicht passiert: Das System ersetzt nicht die Erfahrung der Senior-Techniker. Es macht ihre Erfahrung teilbar und skalierbar. Senior-Techniker werden nicht überflüssig — sie werden von der Routinefehlersuche entlastet und können sich auf knifflige, ungewöhnliche Ausfälle konzentrieren. Und: Die KI erkennt keine Fehler, die noch nicht beschrieben wurden. Treten völlig neue Fehlermodi auf (neue Softwareversion, Umbau der Anlage), muss das System erst mit neuem Wissen gefüttert werden.

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

Einwand 1: “Dem System vertraut doch keiner. Die Techniker gehen nach Bauchgefühl.” Das stimmt — löst sich aber nach 4–6 Wochen, wenn die Diagnosen stimmen. Der Schlüssel ist Glaubwürdigkeit durch Quellenangaben: Das System sagt nicht “Wahrscheinlich ist das Modul defekt”, sondern “Fehlercode 4731 tritt auf, wenn das Peripherie-Modul nicht antwortet. Siemens-S7-1500-Handbuch, S. 387. In deinem Fehlerlog zeigt sich dieses Muster auch am 12.03., als ein Austausch nötig war.” Mit Quellenangabe schwindet die Skepsis.

Einwand 2: “Unsere Handbücher sind auf Englisch, Französisch oder Japanisch. Das System müsste übersetzen.” Ja, und das geht: Mit DeepL oder einem mehrsprachigen LLM lassen sich Handbücher vor der Indexierung übersetzen. Der Aufwand liegt bei ein paar Tagen, nicht Monaten. Alternativ: Mehrsprachige Wissensbasis indexieren und das LLM auf Deutsch antworten lassen — das funktioniert gut mit aktuellen Modellen wie Claude.

Einwand 3: “Das ist zu komplex für unsere IT. Wir haben keine Python-Entwickler.” Dann nimm Node-RED für die Daten-Pipeline (kein Code nötig) und einen betreuten RAG-Dienst statt Eigenbetrieb. Oder hol dir für die Einrichtung eine Automatisierungs-Agentur und übernimm den Betrieb danach mit dem eigenen Team. Die Alternative — weiter mit Handbuch-Wälzen zu arbeiten — kostet jeden Monat mehr als die Einrichtung.

Woran du merkst, dass das zu dir passt

• Ihr habt drei oder mehr Maschinentypen im Betrieb, die unterschiedliche Fehlerlogik haben
• Ungeplante Ausfälle kosten mehr als 500 € pro Stunde Stillstand
• Ihr lagert Wartung aus oder habt Techniker im Nachtdienst, die bei seltenen Fehlern nicht sofort Support bekommen
• Es gibt bereits interne Reparaturberichte oder Wartungs-Logs, aus denen das System lernen kann
• Eure Maschinen sprechen OPC UA oder haben eine offene Datenschnittstelle (S7-TCP/IP, EtherNet/IP mit Gateway)

Wann es der falsche Zeitpunkt ist — drei harte Ausschlusskriterien:

1. Zu wenig Maschinenvielfalt und Störungshäufigkeit: Ihr habt nur einen Maschinentyp im Betrieb, oder es gibt durchschnittlich weniger als 5 ungeplante Störungen pro Monat. Dann lässt sich der Einrichtungsaufwand (17.000–54.000 €) nicht amortisieren. Ein gutes Fehlercode-Wiki auf Confluence und eine strukturierte Reparaturbericht-Vorlage bringt mehr.

2. Keine digitale Wartungshistorie vorhanden: Reparaturberichte liegen handschriftlich vor, oder es gibt schlicht keine dokumentierten Reparaturen aus den letzten Jahren. Das System braucht mindestens 50–100 dokumentierte Störungsfälle, um sinnvolle Muster ableiten zu können. Zuerst dokumentieren — dann KI.

3. Maschinen mit vollständig proprietärem, geschlossenem Protokoll: Ältere CNC-Steuerungen bestimmter Hersteller (z. B. ältere Fanuc-Modelle ohne EtherNet/IP-Option) liefern keine externen Datenschnittstellen. Wenn der Hersteller keine OPC-UA-, Modbus- oder TCP/IP-Anbindung bietet und kein Retrofit-Kit existiert, ist das ein K.o.-Kriterium — bis zu einer zukünftigen Maschinengeneration.

Das kannst du heute noch tun

Heute kostenlos starten:

Sammle deine SPS-Handbücher (Papierkopien reichen, scanne sie bei Bedarf ein) und leg sie digital ab. Erstelle dazu eine Liste aller Fehlercodes, die in den letzten 12 Monaten an deinen Maschinen aufgetreten sind.

Öffne Claude (kostenloser Plan) und teste das Prinzip: Kopiere einen Fehlerbericht aus deinem Wartungs-Log hinein und frage: “Was könnten die Ursachen sein, basierend auf diesen Symptomen?” Das kostet dich 30 Minuten und gibt dir ein Gefühl, ob die Idee für deinen Betrieb überhaupt passt.

Wenn das gut funktioniert: Teste mit dem nächsten echten Störfall, ob die KI eine nützliche Diagnose liefert — bevor du einen Cent in Infrastruktur investierst.

Quellen & Methodik

• Siemens PLC Troubleshooting Guide 2025/2026 (koeed.com, 2026) — Auswertung von Service-Einsätzen an über 80 Siemens-SPS-Installationen; Basis für die Aussage, dass 60 % der Ausfälle durch bessere Dokumentation und systematische Diagnose vermeidbar wären.
• FD-LLM: Large Language Model for Fault Diagnosis of Machines (arXiv:2412.01218v1, Dezember 2024) — Akademische Validierung von LLM-basierter Maschinendiagnose. Zeigt: Llama3-Instruct erreicht 99,7 % Genauigkeit innerhalb bekannter Betriebsbedingungen — fällt aber auf 43–53 % ab, wenn das Modell auf andere Maschinenkomponenten als die Trainingsdaten generalisieren muss. Direkte Evidenz für die Notwendigkeit komponentenspezifischer Wissensdatenbanken.
• IndexBox / Siemens-Auswertung 2024 (indexbox.io, 2024) — Analyse der Siemens-Studie zu Produktions-Ausfallkosten: Fortune-500-Hersteller tragen im Schnitt 260.000 USD/Stunde/Anlage durch ungeplante Ausfälle.
• ANSI/ISA-18.2 Alarm Management Standard — Definition und Grenzwerte für Alarmflut (>10 Alarme in 10 Minuten); Basis für den Abschnitt zum Alarmflut-Problem.
• VDMA OPC UA — Leitfaden (vdma.org, 2022–2026) — Offizielle Dokumentation des VDMA; OPC UA ist der Standard für Industrie-4.0-Maschinenkommunikation und -Diagnose.
• OPC UA Implementation: Rockwell, Siemens, and Beckhoff (control.com, 2024) — Herstellerspezifischer Vergleich der OPC-UA-Implementierungen; Basis für den Protokoll-Ökosystem-Abschnitt.
• Eigene Interviews mit Maschinenherstellern und Wartungsdienstleistern in Deutschland (2025) — Kennzahlen zu Stillstandkosten, Support-Eskalation und Diagnosezeit basieren auf Rückmeldungen aus der KMU-Fertigung.