Die erste Generation industrieller KI bestand aus klassischen Machine-Learning-Modellen: Ein Ingenieur extrahierte Features – Mittelwerte, FFT-Koeffizienten – und trainierte darauf einen Klassifikator. Pro Anwendungsfall entstand ein Modell, pro Modell ein eigenes Entwicklungsprojekt. Deep-Learning-Architekturen haben das Feature-Engineering teilweise automatisiert und konnten direkt auf Rohsignalen arbeiten: Vibrationszeitreihen, Bilddaten, Audiospektren. Doch das Grundmuster blieb bestehen: Ein Modell löst genau eine Aufgabe. Es klassifiziert, prognostiziert oder erkennt Anomalien – mehr nicht. Es kann weder eine Serviceanleitung lesen noch dem Bediener den nächsten Schritt erklären. Large Language Models haben dieses Bild grundlegend verändert. Ein LLM versteht natürliche Sprache, kann unstrukturierte Texte auswerten – Servicehandbücher, Fehlerprotokolle, Datenblätter – und Schlussfolgerungen ziehen, die über einfache Wenn-Dann-Logik hinausgehen. Doch ein LLM allein ist noch kein Agent. Der entscheidende Schritt ist die Anbindung an Tools: Wenn ein LLM aktiv Datenquellen abfragen kann – den OPC-UA-Server nach dem aktuellen Sequenzschritt befragen, einen Ringpuffer mit Messdaten auslesen, das Handbuch nach Fehlercode F0032 durchsuchen – dann entsteht ein Agent. Er kombiniert Sprachfähigkeit mit der Fähigkeit, in der realen Welt zu handeln. Das unterscheidet ihn grundlegend vom SPS-Diagnosebaustein: Ein FB_Diagnostic prüft, ob ein Messwert außerhalb eines Grenzwerts liegt. Ein Agent kann darüber hinaus das Servicehandbuch durchsuchen, den Bediener fragen, ob das zugehörige Ventil geschaltet hat, und eine Reparaturanleitung schrittweise ausgeben – alles im Kontext der aktuellen Signallage. Dabei arbeitet er als Sidecar parallel zur SPS: Sequenzen, Interlocks und Safety-Funktionen verbleiben in der Steuerung; der Agent erzeugt Empfehlungen oder schreibt ausschließlich freigegebene Parameter in klar definierten Bereichen.
Datenzugriff und Engineering
Den größten Nutzen entfaltet der Agent, wenn er Prozessdaten direkt von der Maschine erhält – nicht über Umwege durch Historian-Datenbanken, sondern unmittelbar an der Quelle. Ob dies über OPC UA, MQTT, Modbus TCP oder S7comm geschieht, ist letztlich eine Frage der Integration, nicht der Architektur. Die Standard-Schnittstellen der SPS-Welt sind hinreichend etabliert; entscheidend ist vielmehr, dass der Agent Zeitstempel, Quality-Bits und eine konsistente Tag-Semantik erhält. Ein lokaler Ringpuffer speichert kurze Zeitfenster hochauflösend, um Vorboten vor einem Alarm zu analysieren – etwa einen schleichenden Druckabfall in den Sekunden vor dem eigentlichen Fehler. Für wartbare Agenten hat sich bewährt, Workflows mit einer Engineering-Plattform wie ForestHub zu modellieren, anstatt Einzelsoftware von Hand zu entwickeln: Asset definieren, Wissensquellen einbinden (Handbücher, Schaltpläne, Fehlerlisten), Diagnose-Workflow konfigurieren, im Shadow-Mode validieren und dann assisted Funktionen freischalten. Versionierung und Rollback sind dabei essenziell für den industriellen Einsatz.
Praxisablauf: Human-in-the-Loop
Ein konkreter Servicefall verdeutlicht den Ablauf: Die Anlage meldet eine Störung, die der Bediener nicht unmittelbar zuordnen kann. Der Agent liest Alarmcode, Betriebszustand und Messwerte aus der SPS und bewertet parallel zusätzliche Sensorsignale – etwa eine Stromaufnahme von 3,1A statt der üblichen 2,3A bei diesem Sequenzschritt. Anschließend stellt er gezielte Rückfragen, die aus der Dokumentation abgeleitet sind: Hat das zugehörige Ventil geschaltet? War eine bestimmte Betriebsart aktiv? Der Bediener wird so zum Human-in-the-Loop: Er liefert Kontextinformationen, die der Agent aus Signalen allein nicht ableiten kann, und gibt kritische Entscheidungen frei. Im nächsten Schritt empfiehlt der Agent einen sicheren Testlauf – in der SPS hinterlegt und deterministisch ausgeführt. Er bewertet die Ergebnisse gegen Referenzmuster und liefert eine technisch begründete Hypothese: Der Temperaturanstieg korreliert mit dem Lastzustand, die Kennlinie weicht um zwölf Prozent von der Referenz ab, Dokumentstelle 4.3.2 nennt eine verschlissene Dichtung als wahrscheinliche Ursache. Daraufhin führt er den Bediener Schritt für Schritt durch die Reparatur. Entscheidend dabei: Der Agent wird mit der Zeit besser. Jeder dokumentierte Fall fließt in seine lokale Wissensbasis zurück; erfolgreiche Diagnosepfade werden priorisiert, Fehlschläge gelernt.
Hardware-Anforderungen
Eine häufige Frage betrifft die benötigte Hardware: Eine klassische Kompaktsteuerung mit wenigen Megabyte RAM reicht für einen solchen Agenten nicht aus. Als Minimum eignen sich Plattformen – z.B. Cortex-A-Prozessoren mit 2 bis 4GB RAM und 8 bis 32GB Storage für Dokumente und Modelle. Komfortabler arbeitet ein kompakter Industrie-PC mit 8GB RAM, der auch bei umfangreicheren Dokumentenbasen Reserven bietet. Eine dedizierte GPU wird hingegen nicht benötigt: Quantisierte Modelle und optimierte Runtimes laufen performant auf CPU. Die SPS bleibt dabei unangetastet; der Agent läuft als Sidecar auf separater Edge-Hardware im Maschinenetz.
