Validierung von ISO 10218-1:2025 Robotersicherheits-Verriegelungen in der Kontaktplan-Logik

Die Validierung von Robotersicherheits-Logik gemäß ISO 10218-1:2025 erfordert mehr als nur die Überprüfung der Syntax im Kontaktplan. Ingenieure müssen das Verhalten bei Stopp-Kategorie 0 und Stopp-Kategorie 1 im Hinblick auf Bewegung, Verzögerung, Rückmelde-Timing und Verriegelungssequenzen in einer risikobegrenzten Simulation testen, bevor die physische Inbetriebnahme erfolgt.

Robotersicherheits-Logik ist nicht allein deshalb validiert, weil der Programmbaustein übersichtlich aussieht. Sie ist validiert, wenn der befohlene Stopp, der Rückmeldepfad und das physische Verhalten der Maschine unter fehlerhaften und zeitkritischen Bedingungen übereinstimmen.

Diese Unterscheidung ist unter ISO 10218-1:2025 umso wichtiger, da die Norm Robotersicherheit stärker in Richtung dynamischer Überwachung, koordinierter Zustandsübergänge und cyber-physischer Integrität lenkt. Statische Überprüfungen sind nach wie vor wertvoll, geben jedoch keinen Aufschluss darüber, ob ein Roboter mit hoher Trägheit tatsächlich zum Stillstand kommt, bevor das Drehmoment abgeschaltet wird.

Ampergon Vallis Metrik: In einem internen Benchmark des OLLA Lab verpassten Ingenieure bei einer begrenzten Validierungsaufgabe für Stopp-Kategorie 1 in 34 von 50 Durchläufen zunächst Timing-Fehler in der Verzögerungssequenz. Nachdem sie dieselbe Logik in einer 3D-Simulation und mittels Variablen-Trace beobachtet hatten, korrigierten sie die Sequenz in einer Medianzeit von 14 Minuten. Methodik: Stichprobengröße = 50 Validierungsläufe bei geführten Roboterzellen-Übungen; Aufgabenstellung = Identifizierung und Korrektur von Timing-/Reihenfolgefehlern in einer simulierten Kontaktplan-Sequenz für Stopp-Kategorie 1; Basis-Vergleichswert = statische Kontaktplan-Überprüfung vor der Simulation; Zeitfenster = interne Laborsitzungen bei Ampergon Vallis, Q1 2026. Dies stützt eine eng gefasste Aussage: Die Simulation verbesserte die Fehlererkennung bei dieser Aufgabe. Sie stützt keine allgemeine Aussage über alle Ingenieure, alle Sicherheitsfunktionen oder formale Konformität.

Die praktische Änderung besteht darin, dass es bei der Robotersicherheit weniger um isolierte physische Schutzeinrichtungen geht, sondern um die validierte Interaktion zwischen Logik, Sensorik, Bewegungszustand und Systemintegrität. SPS-Programmierer rücken nun stärker in den Mittelpunkt der Nachweispflicht.

Für die Arbeit mit Kontaktplänen ist die entscheidende Verschiebung nicht „mehr Sicherheitscode schreiben“, sondern „nachweisen, dass die Steuerungssequenz auch dann sicher bleibt, wenn sich Bewegung, Sensorik und Kommunikation nicht ideal verhalten“. Das ist ein anderer Standard für den Nachweis.

Kritische Standard-Updates für die Abbildung im Kontaktplan

Sicherheitsfunktionen hängen zunehmend von überwachten Übergängen ab, nicht nur von einfachen binären Abschaltungen. Bei kollaborativem oder nähebasiertem Betrieb muss die Logik auf sich ändernde Zustände reagieren, nicht nur auf einen einzelnen geöffneten Kontakt.

• Dynamisches Schutzverhalten gewinnt an Bedeutung.

In der Praxis bedeutet dies, dass die SPS oder der Sicherheitscontroller sich ändernde Informationen zu Abstand, Geschwindigkeit und Zonenzustand verarbeiten muss, anstatt die Anwesenheitserkennung als einzelnes boolesches Ereignis zu behandeln.

• Geschwindigkeits- und Abstandsüberwachung (SSM) erfordert kontinuierliche Bewertung.

Der Übergang von normaler Produktionsgeschwindigkeit zu reduzierter oder kollaborativer Geschwindigkeit muss gesteuert, verifiziert und oft mit Rückmeldungen verriegelt werden. „Befohlen“ ist nicht gleich „erreicht“.

• Kollaborative Übergangsmodi erfordern explizite Zustandsbehandlung.

Die Verknüpfung der ISO 10218-1:2025 mit breiteren cyber-physischen Risiken bedeutet, dass Ingenieure beeinträchtigte Kommunikation, unbefugte Änderungen und den Verlust des vertrauenswürdigen Zustands als sicherheitsrelevante Bedingungen betrachten müssen, insbesondere dort, wo vernetzte Sicherheit oder übergeordnete Integration besteht.

• Cybersicherheit rückt näher an die funktionale Sicherheit.

Die Norm reduziert Sicherheit nicht auf die Syntax des Kontaktplans. Sie drängt auf ein nachweisbares Verhalten unter realistischen Betriebsbedingungen.

• Validierungserwartungen sind allein durch Dokumentenprüfung schwerer zu erfüllen.

Was dies für die Kontaktplan-Logik bedeutet

Ein SPS-Programmierer sollte darauf vorbereitet sein, Folgendes zu modellieren und zu validieren:

• Freigabebedingungen (Permissives),
• überwachte Stopp-Sequenzen,
• Modusübergänge,
• Rückmeldebestätigungen,
• Timeout-Behandlung,
• Fehlerspeicherung (Latching),
• Rücksetzbedingungen,
• Verhalten im Zustand eingeschränkter Funktionalität.

Das ist der Unterschied zwischen Syntax und Einsatzfähigkeit. Das eine kompiliert; das andere übersteht die Inbetriebnahme.

Die nützliche technische Unterscheidung liegt zwischen der sofortigen Energieabschaltung und dem überwachten kontrollierten Stopp. Der Artikel verwendet „Klasse I“ und „Klasse II“ als Arbeitsbezeichnungen, aber die sicherere formale Zuordnung erfolgt zu den Stopp-Kategorien nach IEC 60204-1 und den Architektur-/Performance-Konzepten nach ISO 13849-1, nicht zu einem informellen Klassensystem.

### Stopp-Kategorie 0: sofortige Energieabschaltung

Ein Stopp der Kategorie 0 schaltet die Energie sofort ab. Bei Roboteranwendungen ist dies das „grobe Werkzeug“: direkte Unterbrechung der Antriebsenergie, typischerweise über sicherheitsgerichtete Hardwarepfade.

#### Auswirkungen auf die Kontaktplan-Logik

- Die Sequenz ist einfach, da sie absichtlich unnachgiebig ist:

• Die Steuerungslogik kann den Stopp anfordern oder anzeigen, aber die Sicherheitsfunktion ist grundlegend an die sofortige Energieabschaltung gebunden.
• unsicherer Zustand erkannt,
• Sicherheitskette öffnet,
• Energie wird abgeschaltet,
• Bewegung endet durch unkontrollierte Stoppdynamik.

#### Betriebliche Merkmale

• Geeignet, wenn die sofortige Abschaltung die erforderliche Risikoreaktion ist.
• Mechanisch belastender für das System.
• Weniger abhängig von der Timing-Koordination zwischen Befehl und Rückmeldung.
• Erfordert dennoch die Validierung von Verdrahtung, Zustandsanzeige und Rücksetzverhalten.

Ein Kontaktplan-Baustein kann diese Logik darstellen, aber der eigentliche Nachweis liegt in der Architektur.

### Stopp-Kategorie 1: kontrollierter Stopp vor Energieabschaltung

Ein Stopp der Kategorie 1 befiehlt der Maschine, kontrolliert zu verzögern, und schaltet die Energie erst ab, nachdem die Stopp-Sequenz abgeschlossen oder bestätigt wurde. Hier wird die Kontaktplan-Logik zeitkritisch.

#### Auswirkungen auf die Kontaktplan-Logik

Eine typische Sequenz umfasst:

• Erkennung des Sicherheitsereignisses,
• Ausgabe eines kontrollierten Stopp-Befehls,
• Aufrechterhaltung der Antriebsfreigabe während der Verzögerung,
• Bestätigung des Stillstands oder des erreichten Stopps,
• Timeout-Überwachung,
• und erst dann Abschaltung des Drehmoments oder der Schützspannung.

#### Betriebliche Merkmale

• Besser geeignet für Systeme, bei denen unkontrolliertes Stoppen zusätzliche Risiken oder übermäßige mechanische Belastungen erzeugt.
• Abhängig von der korrekten Handhabung der Rückmeldungen.
• Anfällig für Race Conditions, Timer-Fehler, veraltete Bits und falsche Annahmen über das Auslaufen der Bewegung.
• Muss gegen das tatsächliche Verzögerungsverhalten validiert werden, nicht nur gegen die beabsichtigte Sequenz.

Dies ist die Stopp-Art, die bei der Überprüfung oft korrekt aussieht, aber bei der Bewegung versagt.

Beispiel für eine Kontaktplan-Struktur für eine Sequenz der Stopp-Kategorie 1

// Nur als Konzeptbeispiel. Die tatsächliche Sicherheitsimplementierung muss der // erforderlichen Sicherheitsarchitektur, den Geräte-Spezifikationen und dem Validierungsplan folgen.

// Zonenverletzung initiiert kontrollierte Stoppanforderung |---[/] Lichtschranke_Frei --------------------( ) Roboter_Stopp_Anforderung---|

// Verzögerungsfenster nach Stoppanforderung aufrechterhalten |---[ ] Roboter_Stopp_Anforderung ----[TOF Verzögerungs_Fenster 500 ms]-------|

// Stillstand bestätigen, bevor Drehmoment abgeschaltet wird |---[ ] Roboter_Stillstand --------------------( ) Sicher_Drehmoment_Abschalten-|

// Drehmoment abschalten, wenn Stillstand bestätigt oder Verzögerungsfenster abgelaufen |---[ ] Sicher_Drehmoment_Abschalten --+-------( ) STO_Befehl-------------------| | | |---[ ] Verzögerungs_Fenster.DN -------+

Dieses Beispiel dient der Veranschaulichung, nicht der Zertifizierung. Die reale Sicherheitsimplementierung hängt von der erforderlichen Sicherheitsarchitektur, dem Geräteverhalten, der Diagnoseabdeckung, der Fehlerreaktion und der Validierung gemäß den geltenden Normen ab.

Der richtige Ansatz ist es, „Klasse I“ und „Klasse II“ nicht als formale universelle Kategorien zu behandeln, es sei denn, eine projektspezifische Spezifikation definiert diese. Normbasierte Arbeit sollte sich stattdessen an anerkannten Begriffen orientieren.

Eine sicherere Normen-Zuordnung

• Sofortiges Stoppverhalten lässt sich am saubersten auf IEC 60204-1 Stopp-Kategorie 0 abbilden.
• Kontrollierte Verzögerung vor Energieabschaltung entspricht der IEC 60204-1 Stopp-Kategorie 1.
• Die Zuverlässigkeits- und Diagnosestruktur hinter der Sicherheitsfunktion sollte dann unter Verwendung von ISO 13849-1 oder dem relevanten Rahmenwerk für funktionale Sicherheit bewertet werden.

Warum diese Unterscheidung wichtig ist

Die Stopp-Kategorie beschreibt, wie die Maschine stoppt. Die Sicherheitsarchitektur-Kategorie oder das Performance Level beschreibt, wie zuverlässig die Sicherheitsfunktion erreicht wird.

Diese sind nicht austauschbar. Ihre Verwechslung kann zu einer Dokumentation führen, die präzise klingt, während das Inbetriebnahmerisiko ungelöst bleibt.

Sie scheitern, weil Syntax nicht gleich Bewegung ist. Eine Kontaktplan-Überprüfung kann die Absicht der Sequenz bestätigen, aber sie kann nicht von sich aus beweisen, dass der Roboter physisch verzögert hat, bevor der nächste Sicherheitszustand erzwungen wird.

Ein LLM kann einen fehlenden Timer, eine fehlerhafte Verriegelung oder ein wahrscheinliches Sequenzmuster identifizieren. Es kann jedoch keine Trägheit, Lastverschiebung, Bremsverzögerung oder veraltete Rückmeldungen beobachten, es sei denn, diese Verhaltensweisen sind explizit modelliert.

Der „Sieht korrekt aus“-Trugschluss

Ein Baustein für Stopp-Kategorie 1 kann logisch vollständig erscheinen, wenn er enthält:

• eine Stoppanforderung,
• einen Timer,
• ein Stillstands-Bit,
• und einen Ausgang zur Drehmomentabschaltung.

Aber die eigentliche Gefahr liegt in den Timing-Beziehungen:

• Wurde das Stillstands-Bit verzögert?
• Ist der Timer abgelaufen, bevor der Roboter tatsächlich gestoppt hat?
• Ist die Rückmeldequelle während eines Kommunikationsfehlers eingefroren?
• Hat die Scan-Reihenfolge einen vorübergehenden unsicheren Zustand zugelassen?
• Ging die Logik von einer Nennlast statt von der maximalen Trägheit aus?

Statische Überprüfung ist gut für die Struktur. Sie ist schlecht für verkörperte Konsequenzen.

Warum Momentum das Validierungsproblem verändert

Einem sich bewegenden Roboter ist es egal, ob der Kontaktplan elegant war. Er reagiert auf Drehmoment, Last, Geschwindigkeit, Bremsprofil und mechanischen Zustand.

Aus diesem Grund sollte die Validierung durch digitale Zwillinge operativ und nicht rhetorisch definiert werden:

> Validierung durch digitale Zwillinge ist der Prozess, bei dem Steuerungslogik gegen ein verhaltensrepräsentatives virtuelles Maschinenmodell getestet wird, damit der Ingenieur beobachten kann, ob befohlene Zustände, erfasste Zustände und physische Reaktion unter normalen und fehlerhaften Bedingungen im Einklang bleiben.

Wenn der virtuelle Roboter nach der Logikmeldung „sicher“ immer noch einen gefährlichen Raum einnimmt, ist das Problem nicht philosophischer Natur.

„Simulationsbereit“ sollte nicht bedeuten, mit einem Kontaktplan-Editor vertraut zu sein. Es sollte bedeuten, in der Lage zu sein, Steuerungslogik gegen realistisches Maschinenverhalten zu beweisen und abzusichern, bevor eine reale Zelle berührt wird.

Operative Definition von „Simulationsbereit“

Ein Ingenieur ist simulationsbereit, wenn er:

• die Kontaktplan-Sequenz für eine Sicherheitsfunktion erstellen oder prüfen kann,
• die relevanten E/A- und Rückmeldezustände zuordnen kann,
• definieren kann, was „korrekt“ im beobachtbaren Maschinenverhalten bedeutet,
• einen Fehler oder einen anormalen Zustand injizieren kann,
• den Logikzustand gegen den simulierten Gerätezustand vergleichen kann,
• die Logik überarbeiten kann,
• und dokumentieren kann, warum die Überarbeitung den Fehlermodus schließt.

Das ist eine Definition für die Inbetriebnahme, keine Definition für den Unterricht.

Das Nachweispaket, das Ingenieure erstellen sollten

Erstellen Sie beim Nachweis von Kompetenz ein kompaktes technisches Protokoll statt einer Screenshot-Galerie:

Geben Sie das erwartete Stoppverhalten in messbaren Begriffen an: Befehl erteilt, Verzögerung beginnt, Stillstand bestätigt, Drehmoment entfernt, Rücksetzen gesperrt, bis die Bedingungen sicher sind.

Beispiel: verzögerte Stillstandsrückmeldung, eingefrorener Zoneneingang, Timer zu kurz oder Rücksetzversuch während unsicherer Belegung.

1. Systembeschreibung Definieren Sie die Roboterzelle, Schutzeinrichtungen, Bewegungszustände und das Sicherheitsziel.
2. Operative Definition von „korrekt“
3. Kontaktplan-Logik und simulierter Gerätezustand Zeigen Sie die Sequenz zusammen mit der simulierten Bewegung des Roboters, dem Zonenzustand und den Rückmelde-Bits.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung Dokumentieren Sie die Logikänderung, Timeout-Anpassung, Speicherbedingung oder Verriegelungs-Umstrukturierung.
6. Erkenntnisse Geben Sie an, was fehlgeschlagen ist, warum es fehlgeschlagen ist und was die korrigierte Sequenz nun beweist.

Diese Struktur ist nützlich, da sie einen Nachweis über das Urteilsvermögen erbringt.

OLLA Lab ist hier am besten als eine begrenzte Validierungsumgebung für das Einüben von risikoreichem Steuerungsverhalten zu verstehen. Es zertifiziert keine Sicherheitsfunktion, ersetzt keine formale Validierung und macht eine Maschine nicht durch bloße Nähe konform. Es gibt Ingenieuren einen Ort, an dem sie beobachten können, ob ihre Logik realistische Sequenzbelastungen übersteht, bevor Hardware involviert ist.

Was OLLA Lab in diesem Workflow beiträgt

Basierend auf der Produktbeschreibung im Ausgangsmaterial bietet OLLA Lab:

• einen webbasierten Kontaktplan-Editor zum Erstellen und Überarbeiten der Sequenz,
• einen Simulationsmodus zum Ausführen der Logik ohne physische Hardware,
• ein Variablen-Panel zur Beobachtung von E/A, Tags, Analogwerten und Steuerungszuständen,
• 3D- / WebXR- / VR-Industriesimulationen zur Betrachtung des Maschinenverhaltens,
• Validierung durch digitale Zwillinge gegen realistische Maschinenmodelle,
• und szenariobasierte Übungen mit Zielen, Gefahren, Verriegelungen, Sequenzierungsanforderungen und Inbetriebnahmehinweisen.

Diese Kombination ist operativ nützlich, da die Validierung der Robotersicherheit keine einzelne Aufgabe ist. Es ist eine Kette: Erstellen, Ausführen, Beobachten, Fehlersuche, Überarbeiten, Verifizieren.

Der Validierungs-Workflow in OLLA Lab

#### 1. Auswahl eines Roboterzellen-Szenarios

Wählen Sie ein Szenario, das Folgendes beinhaltet:

• Roboterbewegung,
• Verhalten in geschützten Zonen,
• Sicherheitseingänge,
• und Erwartungen an die Stopp-Sequenz.

Der Punkt ist die kontextuelle Validierung, nicht das abstrakte Üben von Bausteinen.

#### 2. Zuordnung von Sicherheitseingängen und Maschinenzuständen

Verwenden Sie das Variablen-Panel, um Zustände zu binden und zu beobachten, wie z. B.:

• Lichtschranke frei oder unterbrochen,
• Tor geschlossen oder offen,
• Roboter-Startbefehl,
• Stoppanforderung,
• Stillstandsrückmeldung,
• Antriebsfreigabe,
• Drehmoment-Aus-Befehl,
• Fehlerspeicher-Bits.

Wenn die Tags vage sind, wird die Analyse vage sein.

#### 3. Aufbau der Stopp-Sequenz im Kontaktplan-Editor

Implementieren Sie die erforderliche Logik für:

• Ereigniserkennung,
• kontrollierte Stoppanforderung,
• Verzögerungs-Timing,
• Rückmeldebestätigung,
• Drehmomentabschaltung,
• Fehler-Timeout,
• und Rücksetzbedingungen.

Hier wird OLLA Lab operativ nützlich. Der Ingenieur kann von der symbolischen Absicht zum beobachtbaren Verhalten übergehen, ohne auf den Maschinenzugang warten zu müssen.

#### 4. Auslösen von Zonenverletzungen während der Bewegung

Führen Sie die Simulation aus und lösen Sie eine Zonenverletzung aus, während der Roboter:

• mit Nenngeschwindigkeit fährt,
• mit maximaler Geschwindigkeit fährt,
• und, wo das Szenario es zulässt, unter verschiedenen Bewegungsbedingungen.

Eine Stopp-Sequenz, die nur im einfachen Fall funktioniert, ist nicht validiert.

#### 5. Verfolgung der Sequenz gegen das Maschinenverhalten

Beobachten Sie, ob:

• die Stoppanforderung sofort ausgegeben wird,
• der Roboter wie erwartet verzögert,
• sich das Stillstands-Bit am korrekten Punkt ändert,
• das Drehmoment erst abgeschaltet wird, nachdem sichere Stoppkriterien erfüllt sind,
• und die Fehlerlogik aktiviert wird, wenn die erwartete Bestätigung nicht eintrifft.

Dies ist der Kernwert der Simulation: den Logikzustand gegen den Gerätezustand in der Zeit zu vergleichen, nicht in der Theorie.

#### 6. Injizieren von anormalen Bedingungen

Testen Sie mindestens einen Fehler, wie z. B.:

• verzögerte Stillstandsrückmeldung,
• feststeckender Sensorstatus,
• Timeout-Ablauf vor der Stoppbestätigung,
• Rücksetzversuch bei unsicherer Zone,
• oder widersprüchlicher Moduszustand.

Dieser Schritt ist wichtig, da viele Sicherheitssequenzen an den Rändern versagen, nicht auf dem „Happy Path“.

Die korrekte Validierungsmethode besteht darin, die Integrität der Sequenz sowohl unter normalen als auch unter anormalen Bedingungen zu beweisen. Ein einzelner erfolgreicher Stopp reicht nicht aus.

Checkliste für die Mindestvalidierung

• Bestätigen Sie, dass das auslösende Ereignis deterministisch erkannt wird.
• Bestätigen Sie, dass der Stoppbefehl ohne unbeabsichtigte Verzögerung ausgegeben wird.
• Bestätigen Sie, dass die Maschine nur für das konstruktiv vorgesehene Verzögerungsfenster unter Energie bleibt.
• Bestätigen Sie, dass eine Stillstands- oder gleichwertige Stopprückmeldung erforderlich ist, wenn das Design davon abhängt.
• Bestätigen Sie, dass die Drehmomentabschaltung erst erfolgt, nachdem die Stoppbedingung erreicht wurde oder der überwachte Timeout-Pfad aufgerufen wurde.
• Bestätigen Sie, dass das Timeout-Verhalten das System in einen definierten sicheren Zustand führt.
• Bestätigen Sie, dass das Rücksetzen gesperrt ist, bis alle Freigabebedingungen wiederhergestellt sind.
• Bestätigen Sie, dass Tag-Verhalten und Maschinenverhalten über wiederholte Zyklen hinweg im Einklang bleiben.

Worauf in der Simulation zu achten ist

• Race Conditions zwischen Timer-Done-Bits und Rückmelde-Bits
• Artefakte durch die Scan-Reihenfolge
• Gespeicherte Ausgänge, die einen unsicheren Übergang überdauern
• Unsachgemäße Rücksetzpfade
• Angenommene Rückmeldungen, die nie unabhängig validiert werden
• Modusübergänge, die die beabsichtigte Stopp-Sequenz umgehen

Die gefährlichste Logik kündigt sich nicht durch dramatische Syntax an.

Cybersicherheit sollte als eine Bedingung behandelt werden, die die Vertrauenswürdigkeit sicherheitsrelevanter Zustände beeinträchtigen kann. Wo Robotersicherheit von vernetzten Signalen, übergeordneten Schreibvorgängen oder verteilter Koordination abhängt, kann der Verlust der Integrität zu einem Sicherheitsproblem werden.

Praktische Auswirkungen auf die Kontaktplan-Logik

Ingenieure sollten überlegen, wie die Logik reagiert auf:

• Kommunikationsverlust mit einem sicherheitsrelevanten Subsystem,
• veraltete oder eingefrorene Statuswerte,
• unbefugte Modusänderungen,
• unerwartete Parameteränderungen,
• und Diskrepanzen zwischen befohlenem und gemeldetem Zustand.

Ein begrenztes technisches Prinzip

Der Kontaktplan sollte nicht nur fragen: „Habe ich ein sicheres Bit empfangen?“ Er sollte auch fragen: „Habe ich noch Grund, diesem Bit zu vertrauen?“

Dieses Prinzip ersetzt kein vollständiges IEC 62443-Programm. Es hilft jedoch, die Kommunikationsintegrität dort in die Sicherheitsdiskussion einzubeziehen, wo dies relevant ist.

Simulation ist wertvoll, aber kein Ersatz für formale Sicherheitstechnik, Geräteauswahl oder Validierung an der Maschine. Sie reduziert das Inbetriebnahmerisiko; sie entbindet nicht von der Verantwortung.

Was Simulation unterstützen kann

• Sequenzvalidierung,
• E/A-Tracing,
• Fehlerinjektion,
• Timing-Analyse,
• Einüben von Bedienerzuständen,
• Früherkennung von Logikfehlern vor der Hardware-Exposition.

Was Simulation allein nicht feststellt

• formale Konformität,
• zertifizierte Sicherheitsarchitektur,
• erreichtes Performance Level oder SIL,
• Hardware-Fehlertoleranz,
• endgültiges Stoppverhalten an der tatsächlichen Maschine,
• standortspezifische Risikoakzeptanz.

Diese Grenze ist für die Glaubwürdigkeit wichtig. OLLA Lab ist am stärksten, wenn es als Proben- und Validierungsumgebung für risikoreiche Aufgaben verwendet wird, die an realen Anlagen nur schwer sicher geübt werden können.

Nutzen Sie es vor der physischen Inbetriebnahme, nicht anstelle der physischen Inbetriebnahme. Der glaubwürdige Workflow ist gestuft.

Ein begrenzter Workflow

1. Definieren Sie die Sicherheitsfunktion und die Akzeptanzkriterien.
2. Erstellen Sie die Kontaktplan-Sequenz und das Tag-Modell.
3. Validieren Sie das normale und fehlerhafte Verhalten in OLLA Lab.
4. Zeichnen Sie das technische Nachweispaket auf.
5. Übertragen Sie die geprüfte Logik in den formalen Sicherheitslebenszyklus des Projekts.
6. Führen Sie hardwarespezifische Verifizierungen und die Standortabnahme am realen System durch.

Das ist das richtige Maß an Ambition. Ein Simulator sollte vermeidbare Fehler reduzieren, bevor der teure Teil beginnt.

ISO 10218-1:2025 hebt den praktischen Standard für Robotersicherheits-Logik, da sie den Nachweis des Verhaltens fordert, nicht nur den Nachweis der Absicht. Für SPS-Programmierer besteht die zentrale Aufgabe darin, Stopp-Sequenzen, Rückmeldeabhängigkeiten, dynamisches Schutzverhalten und Reaktionen auf Zustände eingeschränkter Funktionalität gegen realistische Maschinenbewegungen zu validieren.

Die entscheidende Unterscheidung ist einfach: Ein Sicherheits-Baustein ist nicht validiert, wenn er korrekt aussieht; er ist validiert, wenn die Maschine auf die vom Design geforderte Weise sicher wird, auch unter fehlerhaften Bedingungen.

Deshalb gehört Simulation in den Workflow. Eine begrenzte Umgebung für digitale Zwillinge wie OLLA Lab gibt Ingenieuren einen Ort, an dem sie Zonenverletzungen testen, Verzögerungs-Timings beobachten, den Logikzustand gegen den Maschinenzustand vergleichen und die Logik überarbeiten können, bevor die physische Inbetriebnahme jeden Fehler zu einem Kostenfaktor macht.

- ISO 10218 Roboter und Robotikgeräte – Normenseite - IEC 60204-1 Elektrische Ausrüstung von Maschinen - IEC 61508 Übersicht zur funktionalen Sicherheit - ISO 13849-1 Sicherheitsbezogene Teile von Steuerungen - NIST Cybersecurity Framework 2.0