Programmierung sicherer Mensch-Roboter-Koexistenz in Industrie 5.0

Um eine sichere Mensch-Roboter-Koexistenz in Industrie 5.0 zu programmieren, müssen Ingenieure dynamische Schutzzonen, deterministische Verriegelungen und die Logik zur Geschwindigkeits- und Abstandsüberwachung validieren. OLLA Lab bietet eine abgegrenzte Digital-Twin-Umgebung, in der Kontaktplan-Logik (Ladder Logic), E/A-Kausalität und Fehlerreaktionen getestet werden können, bevor die physische Inbetriebnahme beginnt.

Industrie 5.0 ist kein Slogan, um Fabriken „menschlicher“ wirken zu lassen. Es ist eine Korrektur der engeren Annahme, dass vollständige Autonomie immer die optimale Steuerungsphilosophie darstellt. Die Formulierung der Europäischen Kommission ist explizit: Die Industrie der Zukunft muss menschenzentriert, resilient und nachhaltig sein und nicht bloß mit maximaler Intensität automatisiert (Europäische Kommission, 2021).

Der praktische Grund ist einfach. „Lights-out“-Systeme (dunkle Fabriken) bewältigen Wiederholbarkeit gut, aber sie scheitern an Varianz, wenn diese nicht im Voraus modelliert wurde. Eine Linie kann perfekt optimiert sein, bis die Realität eintritt – was sie meist ohne Vorwarnung tut.

In aktuellen OLLA Lab WebXR-Stresstests stellten Ingenieure, die dynamische Zonenverletzungen simulierten, fest, dass KI-generierte Entwürfe für Sicherheits-Kontaktsprossen in 7 von 32 Aufgabenläufen das erforderliche Hard-Stop-Verhalten nicht erfüllten, wenn sie nicht durch menschliche Überprüfung korrigiert wurden – eine Fehlerquote von 21,9 %. Methodik: n=32 simulierte Verriegelungsaufgaben in kollaborativen Zellen, Basis-Vergleichswert = menschlich geprüfter deterministischer Sprossensatz, Zeitfenster = Januar–März 2026. Dies stützt nur eine eng begrenzte Aussage: Die Entwurfsgenerierung ist kein Beweis für einsatzbereite Sicherheitslogik. Sie stützt keine pauschale Behauptung über alle KI-gestützten SPS-Arbeiten.

Die „dunkle Fabrik“ wandelt sich, weil Optimierung ohne adaptives menschliches Urteilsvermögen spröde ist. Industrie 4.0 betonte Konnektivität, Automatisierung und datenreiche Abläufe. Industrie 5.0 behält diese Gewinne bei, stellt aber den menschlichen Bediener, Techniker und Ingenieur als aktive Komponenten der Systemresilienz wieder her, anstatt sie als Restarbeitskraft am Rande zu betrachten.

Das Industrie-5.0-Modell der Europäischen Kommission ist die klarste formale Aussage zu diesem Wandel. Es lehnt Automatisierung nicht ab. Es lehnt die Vorstellung ab, dass Automatisierung allein das höchste industrielle Ziel ist (Europäische Kommission, 2021).

Dies ist in der Regelungstechnik wichtig, weil anormale Zustände der Punkt sind, an dem Philosophie zu Kontaktplan-Logik wird. Versorgungsunterbrechungen, Sensordrift, fehlerhafte Produkte, Wartungsüberbrückungen und manuelle Teilinterventionen verschwinden nicht, nur weil eine Linie hochautomatisiert ist. Sie werden zu den Bedingungen, die offenlegen, ob die Steuerungsstrategie für die Realität oder für eine Broschüre entworfen wurde.

### Steuerungsphilosophien: Industrie 4.0 vs. Industrie 5.0

| Dimension | Fokus Industrie 4.0 | Fokus Industrie 5.0 | |---|---|---| | Primäres Ziel | Effizienz, Konnektivität, Durchsatz | Resilienz, menschenzentrierter Betrieb, nachhaltige Leistung | | Rolle des Menschen | Überwacher automatisierter Anlagen | Aktiver Ausnahme-Behandler, Kollaborateur, Entscheidungsträger | | Rolle der SPS/Steuerung | Deterministisches Automatisierungs-Rückgrat | Deterministisches Rückgrat plus sichere Mensch-Maschine-Koexistenz | | Sicherheitsansatz | Bewachte Trennung, feste Automatisierungszonen | Dynamische Kollaboration, risikoreduzierte geteilte Räume, wo gerechtfertigt | | Fehlerhaltung | Unterbrechung minimieren | Sicherer Wiederanlauf nach Unterbrechung und Varianz |

Das Missverständnis, das korrigiert werden muss, ist, dass Industrie 5.0 „weniger Automatisierung“ bedeutet. Es bedeutet meist eine bessere Zuweisung von Kognition. Roboter wiederholen. Menschen interpretieren. Gute Systeme nutzen beides gezielt.

Sichere Roboter existieren nicht isoliert; sichere Anwendungen schon. Diese Unterscheidung ist keine semantische Haarspalterei. Sie ist der Kern dessen, wie kollaborative Systeme bewertet, validiert und in Betrieb genommen werden.

Für kollaborative Roboteranwendungen konzentriert sich die Normendiskussion typischerweise auf:

• ISO 10218 für Sicherheitsanforderungen an Industrieroboter
• ISO/TS 15066 für Leitlinien zum Betrieb kollaborativer Roboter
• IEC 61508 für funktionale Sicherheit elektrischer, elektronischer und programmierbarer elektronischer sicherheitsbezogener Systeme

Die ISO/TS 15066 verleiht einem Roboter keinen mystischen „Sicherheitsstatus“. Sie definiert Konzepte für den kollaborativen Betrieb, Erwartungen an die Risikominderung und anwendungsbezogene Überlegungen wie Kraft, Kontakt, Geschwindigkeit, Trennung und überwachte Zustände. Die IEC 61508 hingegen bietet den breiteren Rahmen der funktionalen Sicherheit für sicherheitsbezogenes Steuerungsverhalten und Lebenszyklusdisziplin.

Die vier anerkannten kollaborativen Betriebsmodi

1. Sicherheitsgerichteter überwachter Halt (SRMS) Der Roboter stoppt, wenn eine Person den kollaborativen Raum betritt, und die Bewegung wird nur unter kontrollierten Bedingungen wieder aufgenommen.
2. Handführung (HG) Der Mensch führt die Roboterbewegung physisch durch Zustimmeinrichtungen und eingeschränkte Betriebslogik.
3. Geschwindigkeits- und Abstandsüberwachung (SSM) Der Geschwindigkeits- oder Bewegungszustand des Roboters ändert sich dynamisch basierend auf dem gemessenen Abstand zu einer Person.
4. Leistungs- und Kraftbegrenzung (PFL) Der Roboter und die Werkzeuge sind so ausgelegt, dass die Kontaktkräfte innerhalb der für die definierte Anwendung akzeptablen Grenzen bleiben.

Der technische Aufwand ist bei SSM am größten, da er von dynamischer Sensorik, deterministischer Reaktion und validierter Zonenlogik abhängt. „Dynamisch“ bedeutet nicht vage. Es bedeutet, dass die Logik ihren Zustand basierend auf der gemessenen Trennung unter definierten Zeit- und Sicherheitsvorgaben ändert.

Was diese Normen in SPS-Begriffen bedeuten

Für einen Steuerungstechniker werden Normen zu beobachtbaren Verhaltensweisen:

• Scanner- oder Sicherheitssensorzustände müssen durch ausfallsichere Eingänge repräsentiert werden.
• Freigaben müssen bei Signalverlust oder ungültigem Zustand in einen sicheren Zustand zurückfallen.
• Geschwindigkeitsreduzierungs- und Stoppbefehle müssen deterministisch sein.
• Das Rücksetzverhalten muss bewusst, begrenzt und nicht automatisch sein, sofern die Risikobeurteilung dies erfordert.
• Anormale Bedingungen müssen getestet und nicht einfach vorausgesetzt werden.

Hier entdecken viele Teams den Unterschied zwischen Syntax und Einsatzfähigkeit.

VR-Simulation ist für SSM nützlich, da physische Tests von Zonenverletzungen teuer, langsam und manchmal unnötig riskant sind. Wenn ein Ingenieur die Scanner-Logik bei menschlichem Eindringen zum ersten Mal während der Live-Inbetriebnahme beobachtet, ist der Prozess bereits zu weit in der Risikokurve fortgeschritten.

In der Praxis erfordert die SSM-Validierung, dass Ingenieure Folgendes verifizieren:

• Zonen-Zustandsübergänge bei sich ändernder Bedienerposition
• Geschwindigkeitsreduzierungsbefehle bei Verletzung äußerer Warnzonen
• Stoppbefehle bei Verletzung innerer Schutzzonen
• Rücksetz- und Neustartbedingungen nach Zonenfreigabe
• Ausfallsicheres Verhalten bei Sensorausfall, veraltetem Zustand oder ungültigen Übergängen

OLLA Lab ist hier als abgegrenzte Übungsumgebung nützlich. Ingenieure können Kontaktplan-Logik im Browser erstellen, Simulationen ausführen, Variablen und E/A-Zustände prüfen und beobachten, wie eine 3D- oder WebXR-Arbeitszelle reagiert, wenn ein virtueller Bediener definierte Zonen betritt. Es geht nicht um visuelle Neuheit. Es geht um Kausalität.

Was „Simulationsbereit“ operativ bedeutet

„Simulationsbereit“ sollte durch Verhalten definiert werden, nicht durch Vertrauen. Ein Ingenieur ist simulationsbereit, wenn er:

• beabsichtigtes Steuerungsverhalten vor dem Einsatz nachweisen kann
• E/A-Kausalität während normaler und anormaler Zustände beobachten kann
• diagnostizieren kann, warum eine Freigabe fehlgeschlagen ist oder verriegelt blieb
• einen realistischen Fehler injizieren und den resultierenden sicheren Zustand verifizieren kann
• Logik nach dem Fehlerfall überarbeiten und die Sequenz erneut testen kann
• den Kontaktplan-Zustand mit dem simulierten Gerätezustand vergleichen kann, ohne vage Vermutungen anzustellen

Das ist eine Definition für die Inbetriebnahme, kein Adjektiv für den Lebenslauf.

Warum WebXR und digitale Zwillinge hier wichtig sind

Ein digitaler Zwilling ist operativ nützlich, wenn der virtuelle Gerätezustand nah genug an der Realität ist, um Steuerungsannahmen, Sequenzlogik und Fehlerreaktionen vor der Arbeit vor Ort zu testen. Er ist kein Ersatz für die endgültige Inbetriebnahme und sollte auch nicht als solcher beschrieben werden. Er ist jedoch äußerst nützlich, um Kategorienfehler frühzeitig zu erkennen: falsche Freigabereihenfolge, falscher Rücksetzpfad, falscher Standardzustand, falsche Zeiterwartung.

Eine virtuelle kollaborative Zelle zum Absturz zu bringen, ist billiger als eine physische. Dies ist keine tiefgreifende Erkenntnis, wird aber immer noch zu wenig angewendet.

Die Logik für dynamische Schutzzonen sollte deterministisch, ausfallsicher und leicht zu prüfen sein. Die Struktur trennt üblicherweise die Geschwindigkeitsreduzierung der äußeren Zone, das Stoppverhalten der inneren Zone und manuelle Rücksetzbedingungen, anstatt sie in einer einzigen „cleveren“ Sprosse zu vermischen. Cleverness altert schlecht bei der Inbetriebnahme.

Warum öffnerbasierte Logik (Normally Closed) für sichere Zustände üblich ist

Die Darstellung als Öffner (Normally Closed) wird oft für sicherheitsrelevante Status verwendet, da ein Signalverlust zu einem sicheren Ergebnis führen sollte. Wenn ein Scanner ausfällt, die Kabelintegrität verloren geht oder ein Sicherheitseingang abfällt, sollte die Freigabe öffnen, anstatt fälschlicherweise als gesund zu gelten.

Einfach ausgedrückt:

• Gesunder Eingang vorhanden → Freigabe kann wahr bleiben, wenn alle anderen Bedingungen erfüllt sind.
• Eingang verloren oder fehlerhaft → Freigabe bricht zusammen.
• Freigabe zusammengebrochen → Roboter geht gemäß Sicherheitsdesign in einen Zustand mit reduziertem Risiko oder Stopp über.

Die genaue Implementierung hängt von der Sicherheitsarchitektur, der Steuerung und der Risikobeurteilung ab. Aber das leitende Prinzip ist stabil: Ein unsicherer Zustand darf sich nicht als sicherer Zustand tarnen.

Die minimale Kausalität, die ein Ingenieur erklären können sollte

Ein Ingenieur, der diese Logik validiert, sollte in der Lage sein, Folgendes zu beantworten:

• Was verursacht eine reduzierte Geschwindigkeit anstelle eines vollständigen Stopps?
• Welcher exakte Zustand verursacht einen Hard-Stop?
• Was passiert bei einem Scannerfehler im Vergleich zu einer gültigen Zonenverletzung?
• Kann die Bewegung automatisch wieder aufgenommen werden oder ist eine Quittierung erforderlich?
• Welche Bedingungen müssen erfüllt sein, bevor ein Rücksetzen akzeptiert wird?
• Was ist der sichere Zustand, wenn das Zonensignal widersprüchlich oder veraltet wird?

Wenn diese Antworten nicht explizit sind, ist die Logik nicht bereit. Sie mag zwar ausführbar sein, aber das ist nicht dasselbe.

Die Validierung mit dem Menschen in der Schleife (Human-in-the-loop) ist wichtig, weil sich Bediener nicht immer gemäß dem „Happy Path“ verhalten. Sie betreten Zonen zu früh, setzen zu schnell zurück, umgehen Sequenzerwartungen und erzeugen gelegentlich genau die Bedingung, die bei der Designprüfung vergessen wurde.

Hier wird OLLA Lab operativ nützlich. In einem kollaborativen Verpackungs- oder Materialflussszenario kann ein Ingenieur:

• die Kontaktplan-Logik für Zonenfreigaben und Roboterzustandsbefehle erstellen
• die Simulation ausführen und Ausgänge in Echtzeit beobachten
• das Variablen-Panel verwenden, um Scanner-Zustandsänderungen, Fehler und Quittierungen zu erzwingen
• den Kontaktplan-Zustand mit der 3D- oder VR-Gerätereaktion vergleichen
• die Logik nach einer injizierten anormalen Bedingung überarbeiten

Der Wert des Produkts ist hier begrenzt und glaubwürdig. Es bietet wiederholtes Training für risikoreiche Aufgaben, die an Live-Geräten schwer zu proben sind, insbesondere für junge Ingenieure. Es zertifiziert keine Kompetenz, ersetzt nicht die Aufsicht vor Ort und macht eine formale Sicherheitsvalidierung nicht überflüssig.

Ein praktischer Workflow zur Fehlerinjektion in einer simulierten kollaborativen Zelle

Eine nützliche Validierungssequenz sieht so aus:

1. Starten Sie mit einem gesunden Scanner-Zustand und einer Roboter-Freigabe bei voller Geschwindigkeit.
2. Verletzen Sie die äußere Zone und verifizieren Sie den Übergang zu nur reduzierter Geschwindigkeit.
3. Verletzen Sie die innere Zone und verifizieren Sie den Stoppbefehl und den Abfall der Freigabe.
4. Geben Sie die Zone frei, lassen Sie das Rücksetzen aber unquittiert; bestätigen Sie, dass kein automatischer Neustart erfolgt, wenn das Design dies verbietet.
5. Injizieren Sie einen Scannerfehler, während die Zone frei ist; verifizieren Sie, dass das System in einem sicheren, gesperrten Zustand bleibt.
6. Versuchen Sie ein Rücksetzen unter ungültigen Bedingungen; bestätigen Sie, dass das Rücksetzen abgelehnt wird.
7. Korrigieren Sie die Sprossenstruktur, falls ein unbeabsichtigter Neustart oder eine veraltete Freigabe bestehen bleibt.

Diese Sequenz ist lehrreicher als zehn Screenshots einer fertigen Sprosse. Ingenieurtechnische Nachweise sollten Denken unter Fehlerbedingungen zeigen, nicht nur Syntax unter idealen Bedingungen.

Ein nützliches Simulationsprotokoll ist ein kompaktes Paket technischer Nachweise, keine Screenshot-Galerie. Die Dokumentation sollte zeigen, was getestet wurde, warum es als korrekt erachtet wurde, was fehlschlug und wie die Logik geändert wurde.

Verwenden Sie diese Struktur:

Geben Sie die erwarteten Verhaltensweisen in beobachtbaren Begriffen an. Beispiel: „Verletzung der äußeren Zone erzwingt reduzierte Geschwindigkeit innerhalb des simulierten Zustandsübergangs; Verletzung der inneren Zone lässt die Sicherheitsfreigabe abfallen und befiehlt Stopp; Neustart erfordert manuelles Rücksetzen nach Zonenfreigabe.“

Beschreiben Sie die eingeführte anormale Bedingung: Scanner-Ausfall, hängender Zoneneingang, vorzeitiges Rücksetzen, widersprüchlicher Zustand, verzögerte Quittierung oder erneutes Betreten durch den Bediener.

Dokumentieren Sie die exakte Änderung an der Logik. Beispiel: Fehlerdominanz vor der Rücksetzfreigabe hinzugefügt, Geschwindigkeitslogik der äußeren Zone von der Stopplogik der inneren Zone getrennt oder unbeabsichtigten automatischen Rücksetzpfad entfernt.

1. Systembeschreibung Definieren Sie die Zelle, Maschine oder den Prozessabschnitt. Identifizieren Sie die gesteuerte Anlage, Sicherheitseingänge, Interaktionspunkte des Bedieners und beabsichtigte Betriebsmodi.
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Gerätezustand Präsentieren Sie die relevanten Sprossen und den entsprechenden Digital-Twin-Zustand. Zeigen Sie Tag-Namen, Freigaben, Ausgänge und die visuelle Maschinenreaktion.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung
6. Erkenntnisse Geben Sie an, was der Test über das Sequenzdesign, Annahmen zur Ausfallsicherheit, Rücksetzverhalten oder Bedienerinteraktion offenbart hat.

Dieses Format ist nützlich für das Lernen, die Überprüfung und Einstellungsgespräche, da es technisches Urteilsvermögen zeigt.

Der häufigste Fehlermodus ist nicht einfach „schlechter Code“. Es ist ein schlechtes Zustandsdesign. Die Logik mag kompilieren, simulieren und sogar ordentlich aussehen, während sie dennoch Grenzfälle falsch behandelt.

Typische Fehlermodi sind:

• Fehler bei der Dominanz des Rücksetzpfads, bei denen das Rücksetzen eine noch ungültige Freigabe umgeht.
• Fehlermaskierung, bei der Scannerfehler und gültiger freier Zustand zu ähnlich behandelt werden.
• Unklare Zonen-Hierarchie zwischen Warn-, Reduzierte-Geschwindigkeit- und Stopp-Bereichen.
• Annahmen über automatische Neustarts, die durch die Risikobeurteilung der Anwendung nie gerechtfertigt waren.
• Beibehaltung veralteter Zustände, bei denen Ausgänge verriegelt bleiben, nachdem sich die physische Bedingung geändert hat.
• Schlechte Tag-Semantik, die die Überprüfung erschwert und Kausalität verbirgt.
• Vermischung von Standard-Steuerungslogik mit Sicherheitsabsichten ohne klare architektonische Grenzen.

Das Korrekturmuster ist ebenso konsistent:

• Definieren Sie zuerst den sicheren Zustand.
• Definieren Sie zweitens alle gültigen Übergänge.
• Definieren Sie drittens die Fehlerdominanz.
• Testen Sie anormale Bedingungen, bevor Sie die Sequenz für abgeschlossen erklären.

Diese Reihenfolge spart Zeit und kann das Inbetriebnahmerisiko reduzieren.

KI-Unterstützung wird am besten für die Entwurfsgenerierung, Erklärungen und Überprüfungsunterstützung genutzt, nicht für das endgültige Sicherheitsurteil. Sie kann das Gerüst der Sprossen, Tag-Vorschläge und Anleitungen beschleunigen. Sie kann die Last der deterministischen Validierung nicht allein tragen.

In OLLA Lab kann GeniAI helfen, die Einstiegshürden zu senken, indem sie Kontaktplanelemente erklärt, Logikstrukturen vorschlägt und Lernende durch Szenarien führt. Das ist nützlich, besonders für Ingenieure im Anfangsstadium, die noch nicht wissen, welchen Fehler sie gerade machen. Aber der endgültige Abnahmetest bleibt menschengeführt und evidenzbasiert.

Eine sichere Formulierung ist:

• KI kann vorschlagen.
• Simulation kann aufdecken.
• Ingenieure müssen entscheiden.

Das ist die angemessene Hierarchie für kollaborative Sicherheitsarbeit.

Industrie 5.0 erweitert die Rolle des Steuerungstechnikers vom Sequenzautor zum Koexistenz-Designer. Die Aufgabe besteht nicht mehr nur darin, Bewegungen zu automatisieren. Es geht darum zu definieren, wann Bewegung erlaubt ist, wann sie sich verschlechtern muss, wann sie stoppen muss und wie Menschen sicher in den Prozess zurückkehren können, ohne versteckte Zustandsgefahren zu erzeugen.

Dieser Wandel verändert, was als Kompetenz zählt. Die Syntax von Anweisungen zu kennen, ist immer noch wichtig, aber Syntax ist nur die Eintrittskarte. Das stärkere Signal ist, ob ein Ingenieur Verhalten unter Fehlern validieren, Freigabekausalität erklären und Logik nach einem realistischen anormalen Ereignis überarbeiten kann.

Deshalb ist Simulation wichtig. Sie gibt Ingenieuren einen Ort, um Fehlererfahrung zu sammeln, ohne „Lehrgeld“ in Form von beschädigter Hardware oder unsicheren Inbetriebnahmestunden zu zahlen.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 Functional safety standards family - NIST AI Risk Management Framework (AI RMF 1.0) - EU Industry 5.0 policy background - Digital twin overview (NIST)

Dieses Dokument wurde von den Ingenieuren bei OLLA Lab erstellt, um die Lücke zwischen theoretischer Sicherheitsnormung und praktischer SPS-Implementierung in kollaborativen Umgebungen zu schließen.

Die in diesem Artikel genannten Fehlerquoten und methodischen Ansätze basieren auf internen OLLA Lab Simulationsdaten (Q1 2026). Alle technischen Empfehlungen zur IEC 61508 und ISO/TS 15066 wurden auf Übereinstimmung mit den aktuellen Industriestandards geprüft.