Industrie 5.0 und Human-in-the-Loop-Überwachung zur Validierung von KI-gestützter SPS-Logik

In der Industrie 5.0 ist die Human-in-the-Loop (HITL)-Überwachung der ingenieurtechnische Akt, bei dem überprüft wird, ob sich KI-generierte Steuerungslogik gegenüber physikalischen Anlagengrenzen vor der Inbetriebnahme sicher verhält. OLLA Lab unterstützt diese Validierung, indem es Ingenieuren ermöglicht, Kontaktplan-Logik (Ladder Logic) in der Simulation zu testen, das E/A-Verhalten zu inspizieren, Fehler zu injizieren und die Code-Absicht mit dem 3D- oder VR-Maschinenverhalten zu vergleichen.

KI-Unterstützung in der Automatisierung scheitert nicht an der mangelnden Syntaxgenerierung. Sie scheitert an der Tatsache, dass industrielle Steuerung physikalisch, deterministisch und ausfallkritisch ist. Eine Kontaktplan-Sprosse kann plausibel aussehen und dennoch eine Maschine in einen gefährlichen Zustand versetzen.

Diese Unterscheidung ist wichtig, da es bei Industrie 5.0 nicht darum geht, Menschen aus der Produktion zu entfernen. Die Rahmenbedingungen der Europäischen Kommission stellen den menschlichen Arbeiter wieder in den Mittelpunkt, wobei Resilienz, Zusammenarbeit und die Komplementarität von Mensch und Maschine als Kernprinzipien und nicht als dekorative Sprache dienen.

Ein kürzlich durchgeführter interner Stresstest von Ampergon Vallis unterstreicht diesen Punkt: Bei 500 KI-generierten Motorsteuerungssequenzen produzierte die rohe LLM-Ausgabe durchweg Logik, die vor einer sicheren Validierung in der Simulation eine menschliche Korrektur erforderte, wobei häufig Fehler bei Entprellung, Freigabebedingungen (Permissives) und ausfallsicheren Annahmen auftraten. Methodik: 500 Prompt-Response-Generierungen für Motor-Start/Stopp- und Verriegelungsaufgaben, verglichen mit einer von Ausbildern erstellten Basislogik, evaluiert über ein 30-tägiges internes Testfenster. Diese Metrik stützt eine enge Aussage: Ungeprüfte KI-Ausgabe ist nicht bereit für die Bereitstellung zur Steuerungsvalidierung. Sie stützt nicht die breitere Behauptung, dass KI in der Automatisierung nutzlos sei. Sie ist nützlich. Sie ist nur kein Sicherheitsargument.

Industrie 4.0 betonte Konnektivität, Automatisierung und cyber-physische Integration. Industrie 5.0 fügt einen anderen Schwerpunkt hinzu: Der menschliche Bediener, Ingenieur und Entscheidungsträger bleibt für eine resiliente Produktion unerlässlich.

Das ist keine bloße Anpassung des Brandings. Es ist eine systemische Unterscheidung. Industrie 4.0 wurde oft durch Maschine-zu-Maschine-Konnektivität, autonome Zellen und das Ideal der „dunklen Fabrik“ zusammengefasst. Industrie 5.0, insbesondere im Kontext der europäischen Politik, verlagert sich in Richtung Menschzentrierung, Nachhaltigkeit und Resilienz (Europäische Kommission, 2021).

Für Steuerungsingenieure ist die praktische Konsequenz eindeutig. Der Ingenieur wird nicht mehr nur als die Person definiert, die Logik schreibt. Der Ingenieur wird zu der Person, die validiert, ob die generierte Logik physikalisch kohärent, betriebssicher und unter anormalen Bedingungen wiederherstellbar ist. Syntax ist billig. Deterministisches Urteilsvermögen nicht.

Hier muss der Begriff Human-in-the-Loop diszipliniert verwendet werden. In diesem Artikel bedeutet HITL nicht „eine Person hat einen Blick auf die Ausgabe geworfen“. Es bedeutet, dass ein menschlicher Ingenieur:

• die Steuerungssequenz logisch überprüft hat,
• sie gegen das Anlagenverhalten geprüft hat,
• die ausfallsichere Reaktion unter anormalen Bedingungen verifiziert hat,
• und bestätigt hat, dass Maschinenstatus und Kontaktplan-Status im Einklang bleiben.

Alles andere ist Workflow-Theater.

LLMs generieren wahrscheinlichen Text. SPS führen deterministische Logik gegen reale E/A- und Zykluszeit-Beschränkungen aus. Diese Diskrepanz ist das Kernproblem.

Ein Sprachmodell sagt das nächste Token basierend auf Mustern in Trainingsdaten voraus. Es führt keinen Maschinenzyklus aus, besitzt kein Feldgerät und schließt nicht inhärent aus Aktorträgheit, Verdrahtungskonventionen oder Prozess-Totzeiten. Die Steuerungsprogrammierung nach IEC 61131-3 lebt in einer Welt geordneter Ausführung, explizitem Status und beobachtbarer Kausalität. Die funktionale Sicherheit gemäß Normen wie IEC 61508 ist noch strenger.

Das Ergebnis ist vorhersehbar. KI-generierte Kontaktplan-Logik sieht oft strukturell kompetent aus, bleibt aber betrieblich unvollständig. Sie kann Sprossen produzieren. Sie kann kein sicheres Maschinenverhalten garantieren. Das sind unterschiedliche Leistungen.

Die 3 physikalischen Gefahren, die KI-Code häufig ignoriert

#### 1. Mechanisches Moment

KI-Logik geht oft davon aus, dass das Löschen eines Ausgangsbits bedeutet, dass die Maschine gestoppt hat. Physikalische Systeme sind weniger gehorsam.

Förderbänder laufen nach. Rotierende Anlagen haben Trägheit. Pneumatische Achsen schwingen über. Ein Roboter-Greifkopf stoppt nicht sofort, nur weil die Sprosse auf „falsch“ gesetzt wurde. Wenn nachgelagerte Freigabebedingungen einen sofortigen Stopp voraussetzen, werden Kollisionen und Staus leicht geschrieben und teuer erklärt.

#### 2. Sensor-Hysterese und Rauschen

KI-Ausgaben spezifizieren Entprellung, Totbänder und Signalvalidierung häufig unzureichend.

Echte Sensoren „flattern“. Niveauschalter oszillieren nahe dem Schwellenwert. Lichtschranken flackern je nach Produktgeometrie. Analogwerte driften, sättigen und zeigen Spitzen. Eine Steuerungssequenz, die auf jeden Übergang reagiert, als wäre das Instrument ein Theorembeweiser, führt im besten Fall zu Fehlabschaltungen und im schlimmsten Fall zu instabilen Abläufen.

#### 3. Öffner-Feldverdrahtung und ausfallsichere Konventionen

KI-Modelle handhaben den Unterschied zwischen logischer Wahrheit und sicherer Interpretation des Feldzustands regelmäßig falsch.

Ein Öffner-Stoppkreis, eine gesunde Freigabekette oder ein Gerät, das bei Stromausfall abschaltet (de-energize-to-trip), lässt sich nicht sauber auf simplistische „1 bedeutet aktiv“-Annahmen abbilden. Dies ist ein häufiger Fehlermodus, da das Modell Symbole sieht; die Anlage sieht Verdrahtungsphilosophie.

Determinismus ist nicht verhandelbar, weil industrielle Steuerung nach wiederholbarem Verhalten unter definierten Bedingungen beurteilt wird, nicht danach, ob generierter Code früheren Beispielen ähnelt.

Ein SPS-Zyklus wird in einer bekannten Sequenz ausgeführt. Eingänge werden gelesen, Logik gelöst, Ausgänge aktualisiert und das Zeitverhalten in einem wiederholbaren Zyklus bewertet. Sicherheitsbezogene Funktionen erfordern eine noch strengere Disziplin hinsichtlich definierter Zustände, Diagnoseabdeckung und Fehlerreaktion. Die IEC 61508 existiert genau deshalb, weil „wahrscheinlich korrekt“ keine akzeptable Designkategorie für gefährliche Systeme ist.

Das bedeutet nicht, dass KI keinen Platz in der SPS-Arbeit hat. Es bedeutet, dass KI vor die Validierung gehört, nicht dahinter. Die Entwurfserstellung kann nützlich sein. Das deterministische Veto muss menschlich kontrolliert bleiben.

Dieser Kontrast ist es wert, im Blick behalten zu werden: Entwurfserstellung versus deterministisches Veto. Das eine ist Unterstützung. Das andere ist Verantwortung.

Human-in-the-Loop bedeutet, dass ein menschlicher Ingenieur verifiziert, dass die generierte Logik das physikalische System sicher steuert, das reale Anlagenverhalten berücksichtigt und unter anormalen Bedingungen vor der Inbetriebnahme sicher ausfällt.

Diese Definition ist bewusst eng gefasst. Sie ist beobachtbar. Sie kann auditiert werden. Sie vermeidet den üblichen Nebel um den Begriff.

In operativen Begriffen umfasst die HITL-Validierung:

• die Überprüfung, ob Freigaben, Abschaltungen und Verriegelungen der Steuerungsphilosophie entsprechen,
• die Verifizierung, dass Start-, Stopp- und Fehlerrücksetzverhalten deterministisch sind,
• die Bestätigung, dass Annahmen zu Feldgeräten mit der tatsächlichen Verdrahtung und den Fehlermodi übereinstimmen,
• das Testen anormaler Zustände wie Sensorausfall, klemmende Rückmeldungen und verzögerte Bewegungen,
• und die Überprüfung, ob die Maschine bei Bedarf einen sicheren Zustand erreicht.

Eine schnelle Code-Überprüfung reicht nicht aus. Ein Kommentar-Thread reicht nicht aus. Wenn der Ingenieur das Verhalten nicht anhand eines simulierten oder physikalischen Systemmodells beobachtet hat, ist der Regelkreis nicht geschlossen.

Ein Simulation-Ready-Ingenieur ist jemand, der Steuerungslogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor diese Logik einen Live-Prozess erreicht.

Dies ist kein Synonym für „kennt die Kontaktplan-Syntax“. Es ist eine strengere Schwelle.

Ein Simulation-Ready-Ingenieur kann:

• Tags und E/A auf ein Maschinen- oder Prozessmodell abbilden,
• definieren, wie korrektes Verhalten aussieht, bevor Tests beginnen,
• Abweichungen zwischen Kontaktplan-Status und Anlagenstatus beobachten,
• Fehler gezielt injizieren, anstatt darauf zu warten, dass sie zufällig auftreten,
• die Logik nach einem Fehler überarbeiten,
• und dokumentieren, warum die Überarbeitung das Risiko schließt.

Das ist der Unterschied zwischen theoretischer Kenntnis und praktischem Nutzen bei der Inbetriebnahme.

Ingenieure üben HITL sicher, indem sie generierte oder entworfene Logik innerhalb einer risikobegrenzten Simulationsumgebung validieren, bevor eine Live-Bereitstellung erfolgt.

Hier wird OLLA Lab operativ nützlich. OLLA Lab ist eine webbasierte Trainingsumgebung für Kontaktplan-Logik und digitale Zwillinge, die es Benutzern ermöglicht, Kontaktplan-Logik im Browser zu erstellen, Simulationen auszuführen, E/A und Variablen zu inspizieren, realistische industrielle Szenarien durchzuarbeiten und das Logikverhalten mit 3D- oder VR-Modellen zu vergleichen. In begrenztem Rahmen ist es eine Übungsumgebung für Validierungs- und Fehlerbehebungspraxis.

Das ist wichtig, weil die meisten Junior-Ingenieure diese Lektionen nicht sicher an unter Spannung stehenden Anlagen, aktiven Förderbändern, Pumpen-Skids oder Roboterzellen lernen können. Die Kosten für das Lernen an echter Hardware sind oft beschädigte Ausrüstung, Zeitverlust oder vermeidbare betriebliche Störungen.

Der Generate-Validate-Loop in OLLA Lab

Ein praktischer HITL-Workflow in OLLA Lab kann vier Schritten folgen:

#### Schritt 1: Einen Entwurf (Baseline) generieren

Verwenden Sie den Kontaktplan-Editor und, wo angemessen, GeniAI, um eine Basis-Logik für ein definiertes Szenario wie einen Palettierer, ein Förderband, eine Pumpstation oder eine HLK-Sequenz zu entwerfen.

Der Punkt hier ist nicht die blinde Akzeptanz. Der Punkt ist, die Erstellung des ersten Entwurfs zu beschleunigen, damit die eigentliche Arbeit – die Validierung – beginnen kann.

#### Schritt 2: Logik an simulierte Anlagen binden

Ordnen Sie Tags, Eingänge, Ausgänge und relevante Variablen dem Szenariomodell in der Simulationsumgebung von OLLA Lab zu, einschließlich 3D- oder WebXR-Ansichten, sofern verfügbar.

Dies ist der Moment, in dem abstrakte Logik auf physikalische Konsequenzen trifft. Viele Fehler bleiben unsichtbar, bis ein Ausgang mit Bewegung, Verzögerung oder Sequenzabhängigkeit verknüpft wird.

#### Schritt 3: Fehler injizieren und Ausfallverhalten beobachten

Verwenden Sie das Variablen-Panel, um anormale Bedingungen zu erzwingen, wie:

• fehlerhafte Sensorübergänge,
• verzögerte Rückmeldungen,
• verrauschtes Verhalten diskreter Eingänge,
• analoge Ausschläge,
• oder inkorrekte Freigabezustände.

Beobachten Sie dann, ob die Sequenz sicher ausfällt, sicher anhält oder inkorrekt fortfährt. Gute Validierung besteht nicht darin, den „Happy Path“ zu beweisen.

#### Schritt 4: Menschliche Korrektur anwenden

Überarbeiten Sie die Kontaktplan-Logik im Editor, um deterministische Sicherheitsvorkehrungen hinzuzufügen, wie:

• Entprell-Timer,
• Selbsthaltungskorrekturen,
• ausfallsichere Stopp-Logik,
• Bewegungsprüfungen,
• Alarm-Timeouts,
• und explizite Verriegelungen.

Der menschliche Beitrag ist keine kosmetische Bearbeitung. Es ist das Einfügen von ingenieurtechnischem Urteilsvermögen, wo dem generierten Entwurf physikalischer Realismus fehlte.

Eine Förderband- oder Palettierer-Sequenz ist ein nützliches Beispiel, da sie Zeit-, Bewegungs- und Verriegelungsfehler schnell aufdeckt.

Angenommen, eine KI-generierte Sequenz startet ein Förderband, wenn ein Produkt erkannt wird, und stoppt es, wenn die nachgelagerte Zone belegt ist. Auf dem Papier mag die Logik kohärent erscheinen. In der Simulation zeigt sich der Fehler: Der nachgelagerte Sensor flattert, das Förderband läuft nach dem Stopp aus, und die Sequenz schaltet wieder ein, bevor die Zone tatsächlich geräumt ist. Das Ergebnis ist ein Stau oder eine Kollision im 3D-Modell.

Ein menschlicher Validierer würde dies durch drei Prüfungen bemerken:

• ob der Sensor eine Entprellung oder Zustandsbestätigung erfordert,
• ob das Stoppverhalten des Förderbands die physikalische Nachlaufzeit berücksichtigt,
• und ob die Neustart-Logik eine deterministische Freigabebedingung erfordert, anstatt eines einzelnen transienten Bits.

Ein kompaktes Korrekturmuster beinhaltet oft eine verzögerte Bestätigungslogik. Zum Beispiel:

[Sprache: Kontaktplan] // Menschlich korrigierte Entprell-Logik |---[ Physical_Sensor ]-------[ TON: Timer_On_Delay, 50ms ]---| |---[ Timer_On_Delay.DN ]-----( Latch_Valid_Signal )----------|

Dieses Code-Fragment ist keine universelle Lösung. Es illustriert einen breiteren Punkt: Der menschliche Ingenieur fügt zeitliche und physikalische Disziplin hinzu, die der generierte Entwurf oft auslässt.

VR- und 3D-Simulation bauen nützliches Urteilsvermögen auf, weil sie Ingenieuren ermöglichen, die physikalischen Konsequenzen schlechter Logik zu sehen, ohne für diese Lektionen an echter Ausrüstung zu bezahlen.

Dieser Ausdruck – „Kampfnarben“ – sollte vorsichtig behandelt werden. Er bedeutet keine Theatralik oder Gamification. Er bedeutet wiederholte Konfrontation mit Fehlermustern: Race Conditions, fehlende Verriegelungen, falsche Freigaben, schlechtes Reset-Design und unsicheres Neustartverhalten. Visuelle Konsequenz beschleunigt das Verständnis.

Wenn ein Junior-Ingenieur sieht, wie ein virtuelles Förderband staut, ein Palettierer kollidiert oder eine Pumpensequenz nicht umschaltet, weil die Rückmeldung nie eintrifft, wird die Lektion kausal statt abstrakt. Kontaktplan-Status, Variablen-Status und Anlagen-Status können direkt verglichen werden. Genau das ist die Art von mentalem Modell, das Inbetriebnahmearbeit erfordert.

Forschung zu simulationsbasiertem und immersivem technischem Training unterstützt diese Richtung im Allgemeinen, wenn die Umgebung mit Aufgabenrealismus, Feedback und wiederholbarer Praxis verbunden ist, statt nur mit Neuheit. Die wichtige Einschränkung ist offensichtlich: Immersion ist nützlich, wenn sie die diagnostische Beobachtung verbessert. Ein Headset allein ist keine Pädagogik.

Ingenieure sollten einen kompakten Korpus an technischen Nachweisen dokumentieren, keine Galerie attraktiver Schnittstellen.

Ein glaubwürdiges Validierungsartefakt sollte genau sechs Elemente enthalten:

1. Systembeschreibung Definieren Sie die Maschine oder den Prozess, das Betriebsziel und die wichtigsten E/A.
2. Operative Definition von „korrekt“ Geben Sie an, was in welcher Reihenfolge unter welchen Bedingungen passieren muss und wie ein sicherer Ausfall aussieht.
3. Kontaktplan-Logik und simulierter Anlagenzustand Zeigen Sie die relevanten Sprossen, Tags und den entsprechenden simulierten Maschinenzustand.
4. Der injizierte Fehlerfall Identifizieren Sie die eingeführte anormale Bedingung, wie Sensorflattern, verlorene Rückmeldung, klemmendes Ventil oder analoge Grenzwertüberschreitung.
5. Die vorgenommene Überarbeitung Dokumentieren Sie die exakte Logikänderung, einschließlich Timer, Verriegelungen, Zustandsbehandlung, Alarme oder Freigabekorrekturen.
6. Gelernte Lektionen Erklären Sie, was der ursprüngliche Entwurf verpasst hat und warum die Überarbeitung die physikalische und operative Realität besser widerspiegelt.

Diese Struktur ist weitaus überzeugender als Screenshots mit Bildunterschriften wie „Palettierer-Labor abgeschlossen“. Abschluss ist kein Beweis. Diagnose ist es.

KI sollte als Assistent für Entwurf, Erklärung und Iterationsunterstützung dienen, während der Ingenieur für Validierung, Fehlerursachenanalyse und Bereitstellungsentscheidungen verantwortlich bleibt.

Das passt sauberer zum Industrie 5.0-Modell als jede der beiden extremen Positionen. Der Ingenieur wird nicht durch einen Textgenerator ersetzt, und der Textgenerator ist nicht irrelevant. Die nützliche Rolle ist begrenzte Unterstützung innerhalb eines menschlich kontrollierten Validierungs-Workflows.

In OLLA Lab bedeutet das, dass GeniAI helfen kann, die Einarbeitungshürden zu senken, Kontaktplan-Konzepte zu erklären und die Entwurfserstellung zu unterstützen. Der Simulationsmodus, das Variablen-Panel, die Szenariostruktur und die digitalen Zwillinge der Plattform bieten dann die Umgebung, in der diese Entwürfe getestet, herausgefordert und korrigiert werden. Produktiv gesehen heißt das nicht „KI schreibt die Anlage“. Es heißt „KI entwirft; der Ingenieur verifiziert“.

OLLA Lab passt als begrenzte Übungsumgebung für risikoreiche Inbetriebnahmetätigkeiten, die zu teuer, zu unsicher oder zu betrieblich störend sind, um sie zuerst an echter Ausrüstung zu üben.

Zu den relevanten Funktionen in diesem Workflow gehören:

• Erstellung von Kontaktplan-Logik in einem browserbasierten Editor,
• Simulation der Logikausführung ohne Hardware,
• Überwachung von Tags, E/A, Analogwerten und PID-Variablen,
• Auswahl realistischer industrieller Szenarien,
• Vergleich des Logikverhaltens mit 3D- oder VR-Maschinenansichten,
• und Überarbeitung der Logik nach beobachteten Fehlern.

Diese Positionierung ist wichtig. OLLA Lab ist kein Zertifizierungs-Proxy, kein SIL-Anspruch und kein Ersatz für standortspezifische Inbetriebnahmen gemäß formellen Verfahren. Es ist eine kontrollierte Umgebung zum Lernen und Üben der Validierungsverhaltensweisen, die reale Projekte erfordern.

Industrie 5.0 reduziert nicht den Bedarf an Steuerungsingenieuren. Sie schärft den Bedarf an Ingenieuren, die KI-unterstützte Logik gegen physikalische Realität, deterministische Ausführung und sicheres Ausfallverhalten validieren können.

Die zentrale Unterscheidung ist einfach: KI kann plausiblen Steuerungstext generieren, aber sie kann keine Verantwortung für das Maschinenverhalten übernehmen. Die Human-in-the-Loop-Überwachung schließt diese Lücke, indem sie prüft, ob die Logik nicht nur syntaktisch, sondern auch operativ funktioniert.

Ein Simulation-Ready-Ingenieur ist daher nicht nur jemand, der Kontaktplan-Logik schreiben kann. Es ist jemand, der diese Logik beweisen, beobachten, diagnostizieren und härten kann, bevor sie einen Live-Prozess erreicht. Der praktische Wert von OLLA Lab liegt genau dort: als risikobegrenzte Umgebung, in der Ingenieure Validierung üben, Fehler injizieren, Kontaktplan-Status mit Anlagen-Status vergleichen und die Art von Urteilsvermögen aufbauen können, die Anlagen selten sanft zu lehren Zeit haben.

- U.S. Bureau of Labor Statistics (BLS) – Occupational Outlook Handbook - Deloitte Insights – 2025 Manufacturing Industry Outlook - The Manufacturing Institute & Deloitte – Talent and workforce research - European Commission – Industry 5.0 - IEC 61131-3 standard overview (IEC) - IEC 61508 functional safety standard overview (IEC) - ISO 10218 industrial robot safety standard overview (ISO) - International Federation of Robotics – World Robotics reports - IFAC-PapersOnLine journal homepage - Sensors journal – industrial digital twin and monitoring research