Validierung von Standards für kollaborative Anwendungen im Jahr 2026 mit Digitalen Zwillingen

Um den Standards für kollaborative Anwendungen im Jahr 2026 zu entsprechen, müssen OEMs die gesamte Roboteranwendung validieren, nicht nur den Roboterarm. In der Praxis bedeutet dies, die PLC-Sicherheitslogik, die Zonensensorik, das Stoppverhalten und die Interaktionen im Arbeitsbereich anhand eines Digitalen Zwillings zu testen, um zu prüfen, ob die beabsichtigte Sicherheitssequenz mit dem physischen Maschinenverhalten übereinstimmt.

Ein kollaborativer Roboter ist nicht automatisch eine sichere kollaborative Anwendung. Diese Unterscheidung ist zentral für die Diskussion im Jahr 2026 und oft der Punkt, an dem schwache Sicherheitsannahmen beginnen.

Ein aktueller Validierungslauf von Ampergon Vallis in einem Palettierszenario zeigte, dass eine simulierte LiDAR-Zonenverletzung bei 1,6 m/s eine zusätzliche Verzögerungstoleranz von 140 ms in der Steuerungssequenz erforderte, um eine virtuelle Kollision zu vermeiden. [Methodik: 12 wiederholte Durchläufe einer Palettier-Aufgabe im Digitalen Zwilling, verglichen mit derselben Logik ohne zusätzliche Verzögerungstoleranz, beobachtet im 1. Quartal 2026.] Dies stützt einen engen Punkt: Zeitmargen, die in einer statischen Logikprüfung akzeptabel erscheinen, können versagen, sobald Bewegung und Trägheit modelliert werden. Es stützt keine allgemeine Aussage über alle Roboterzellen, alle Nutzlasten oder formale Konformität.

Das praktische Problem ist einfach: Sicherheitslogik, die in einem Ladder-Editor korrekt aussieht, kann in einem realen Arbeitsbereich dennoch zu spät reagieren.

Ein sicherer Roboter und eine sichere kollaborative Anwendung sind nicht dasselbe. Im Rahmen des ISO 10218-Frameworks und der zugehörigen kollaborativen Richtlinien wird die Sicherheit auf Anwendungsebene bewertet und nicht allein durch den Manipulator gewährleistet.

Das bedeutet, dass der Sicherheitsnachweis das gesamte Arbeitssystem umfassen muss:

• den Robotermanipulator,
• den Endeffektor oder das Werkzeug,
• das Werkstück oder die Nutzlast,
• das Layout des Arbeitsbereichs,
• die Sensorarchitektur,
• und die Steuerungslogik, die die Interaktionszustände regelt.

Dies ist wichtig, da ein Roboterarm, der für den kollaborativen Einsatz vermarktet wird, gefährlich werden kann, sobald er einen scharfen Greifer, einen Schweißbrenner, einen schweren Karton oder ein starres Blechteil trägt. Die interne Kraftbegrenzung neutralisiert nicht jede Anwendungsgefahr.

Die drei Anwendungselemente, die den Sicherheitsnachweis verändern

Das Risikobild auf Anwendungsebene ändert sich wesentlich, wenn diese Elemente hinzugefügt werden:

- Manipulator: Reichweite, Geschwindigkeit, Stoppverhalten, Achsbewegung und Steuerungsschnittstellen. - Endeffektor/Werkzeug: Quetschstellen, scharfe Kanten, thermische Gefahren, gespeicherte Energie, Vakuumverlust oder Greifversagen. - Werkstück/Nutzlast: Masse, Geometrie, Trägheit, Absturzrisiko und sekundäres Aufprallrisiko.

ISO/TS 15066 wird häufig als Leitfaden für den kollaborativen Betrieb verwendet, insbesondere in Bezug auf Kontaktgrenzwerte und Anwendungsbewertung, während ISO 10218-1 und ISO 10218-2 den breiteren Rahmen für Roboter und Integration definieren. Die entscheidende technische Implikation ist stabil: Der Integrator muss das Anwendungsverhalten im Kontext validieren und darf nicht bloß die Marketingaussagen des Roboterherstellers übernehmen.

Die vier kollaborativen Betriebsmodi sind der sicherheitsgerichtete überwachte Stopp (Safety-Rated Monitored Stop), die Handführung (Hand Guiding), die Geschwindigkeits- und Abstandsüberwachung (Speed and Separation Monitoring) sowie die Leistungs- und Kraftbegrenzung (Power and Force Limiting). Dies sind die Standard-Referenzmodi, die bei der Konstruktion kollaborativer Roboteranwendungen verwendet werden.

Für Steuerungstechniker ist die wichtige Unterscheidung, dass es sich nicht nur um Bezeichnungen handelt. Sie implizieren unterschiedliche Sensorarchitekturen, unterschiedliche Steuerungsverhalten und unterschiedliche Validierungsanforderungen.

1. Sicherheitsgerichteter überwachter Stopp (SMS)

Sicherheitsgerichteter überwachter Stopp bedeutet, dass der Roboter stoppt, wenn ein Mensch den kollaborativen Raum betritt, während der Wiederanlauf der Bewegung gesteuert und bedingt erfolgt.

Typische steuerungstechnische Implikationen sind:

• Sicherheitseingang von Scanner, Tor oder Zonengerät,
• sicherer Stopp-Befehlspfad,
• Freigaben für Reset und Neustart,
• Nachweis, dass die Bewegung gehemmt bleibt, während Personal anwesend ist.

2. Handführung (HG)

Handführung ermöglicht es einem Bediener, die Roboterbewegung direkt mithilfe einer dedizierten Zustimmeinrichtung und unter eingeschränkten Betriebsbedingungen zu führen.

Typische steuerungstechnische Implikationen sind:

• Validierung der Zustimmeinrichtung,
• Auswahl des eingeschränkten Betriebsmodus,
• eingeschränktes Geschwindigkeits- oder Kraftverhalten,
• überwachter Übergang in den und aus dem Handführungsmodus.

3. Geschwindigkeits- und Abstandsüberwachung (SSM)

Geschwindigkeits- und Abstandsüberwachung bedeutet, dass die Robotergeschwindigkeit dynamisch so gesteuert wird, dass ein minimaler Schutzabstand zwischen dem Robotersystem und dem Menschen eingehalten wird.

Typische steuerungstechnische Implikationen sind:

• Bereichsscanner oder vision-basierte Zoneneingänge,
• Zustände zur Geschwindigkeitsreduzierung,
• sichere Stoppzustände bei Verletzung des Abstands,
• dynamische Übergänge zwischen normaler, reduzierter und gestoppter Bewegung.

4. Leistungs- und Kraftbegrenzung (PFL)

Leistungs- und Kraftbegrenzung bedeutet, dass die Anwendung so ausgelegt ist, dass ein Kontakt, falls er auftritt, unter definierten Bedingungen innerhalb akzeptabler biomechanischer Grenzwerte bleibt.

Typische steuerungstechnische Implikationen sind:

• validierte Kraft- oder Drehmomentgrenzwerte,
• Nutzlast- und Werkzeugbeschränkungen,
• Geschwindigkeitsbegrenzungen,
• anwendungsspezifische Bewertung des Verletzungsrisikos.

PFL wird oft missverstanden als „der Roboter ist sicher zu berühren“. Das ist zu allgemein, um nützlich zu sein. Die eigentliche Frage ist, ob die Anwendung unter definierten Betriebsbedingungen innerhalb akzeptabler Grenzwerte bleibt.

Das Programmieren der SSM-Logik erfordert mehr als das Zuordnen eines Scanner-Bits zu einer Stopp-Spule. Die Logik muss die menschliche Annäherung, die Robotergeschwindigkeit, die Reaktionszeit, den Anhalteweg und die Übergangsregeln zwischen Warn-, Reduziergeschwindigkeits- und Stoppzuständen berücksichtigen.

Eine gängige Formel für den Schutzabstand lautet:

S = (v_h × T_r) + (v_r × T_r) + C

Wobei:

• S = Schutzabstand
• v_h = Annäherungsgeschwindigkeit des Menschen
• v_r = Annäherungsgeschwindigkeit des Roboters
• T_r = Gesamtreaktionszeit des Systems
• C = zusätzlicher Kompensationsfaktor für Eindringen oder Messung

Die genaue Implementierungsmethode hängt von der Sensorarchitektur und der geltenden Risikobewertung ab, aber das technische Prinzip ist stabil: Wenn die Reaktionszeit unterschätzt wird, ist der Schutzabstand nicht zuverlässig.

Was sollte die Ladder-Logik in einer SSM-Anwendung leisten?

Mindestens sollte die Ladder-Logik diese Zustandsübergänge verwalten:

- Normalbetrieb: Bewegung mit voller Geschwindigkeit zulässig, wenn keine Schutzzone verletzt wird. - Warnzone betreten: Reduzierte Geschwindigkeit befehlen und verifizieren, dass der Roboter den Zustand der reduzierten Geschwindigkeit bestätigt. - Schutzzone betreten: Die erforderliche sichere Stoppfunktion auslösen und gefährliche Bewegungen hemmen. - Zone frei: Neustartbedingungen halten, bis Reset, Bestätigung oder verfahrenstechnische Freigaben erfüllt sind. - Fehlerzustand: In einen sicheren Zustand übergehen, wenn Scanner-Integrität, Kommunikation oder die Gültigkeit der Sicherheitseingänge verloren gehen.

Beispiel für ein Ladder-Logik-Muster bei einer Sicherheitszonenverletzung

|---[ LiDAR_Healthy ]---[ Safety_Zone_Breach ]-----------------(TON Debounce_150ms)---| |---[ Debounce_150ms.DN ]--------------------------------------(CMD_Safe_Stop_Cat1)---| |---[ Debounce_150ms.DN ]--------------------------------------(INH_Motion_Enable)----| |---[/ LiDAR_Healthy ]-----------------------------------------(CMD_Safe_Stop_Cat0)---| |---[ Warning_Zone_Breach ]---[/ Safety_Zone_Breach ]---------(CMD_Reduced_Speed)----|

Dieses Muster ist bewusst einfach gehalten. In einem realen Design müssen Stoppkategorie, Diagnoseabdeckung, Reset-Verhalten und Sicherheitsarchitektur mit der Risikobewertung und dem Design des sicherheitsgerichteten Subsystems übereinstimmen.

Der Entprell-Timer verdient eine kurze Anmerkung. Er dient dazu, Fehlauslösungen durch verrauschte Zonenübergänge zu reduzieren, nicht dazu, einen gefährlichen Signalpfad ohne Rechtfertigung zu verzögern. Sicherheitsfilterung muss begründet sein.

Wie sollten Ingenieure mit Muting-Logik umgehen?

Muting-Logik muss erwartete Materialbewegungen von menschlichem Eindringen unterscheiden, ohne die Schutzfunktion zu schwächen. Das bedeutet in der Regel:

• Definition der spezifischen Förderband- oder Zuführungsbedingung, die ein Muting erlaubt,
• Begrenzung des Mutings auf eine definierte Zeit und Richtung,
• Nachweis, dass menschliches Eindringen weiterhin die erforderliche Schutzreaktion auslöst,
• Alarmierung oder Fehler bei abnormaler Dauer des Mutings.

Digitale Zwillinge sind in der Praxis erforderlich, da eine statische Logikprüfung das Bewegungs-Sicherheitsverhalten unter realistischen Fehlerbedingungen nicht beweisen kann. Bei kollaborativen Anwendungen ist die relevante Frage nicht nur „Was beabsichtigt die PLC?“, sondern „Was passiert physisch noch, bevor die Maschine einen sicheren Zustand erreicht?“

In diesem Artikel bedeutet Validierung durch Digitalen Zwilling: Verknüpfung der PLC-Ladder-Logik mit einem kinematikfähigen 3D-Modell, um das Delta zwischen der beabsichtigten Sicherheitssequenz und dem physischen Verzögerungsverhalten während eines Fehlerzustands zu beobachten.

Das ist eine operative Definition.

Was die Validierung durch Digitalen Zwilling zeigen kann, was statische Prüfungen oft übersehen

Eine korrekt konfigurierte Simulation kann Folgendes aufdecken:

• Verzögerung nach einem Stopp-Befehl,
• nutzlastabhängige Stopp-Unterschiede,
• Zeitfehler bei Zonenverletzungen,
• Verhalten bei Scanner-Ausfall,
• Wettlaufsituationen (Race Conditions) zwischen Geschwindigkeitsreduzierung und Stopp-Befehlen,
• Fehler bei Neustart-Freigaben,
• Diskrepanz zwischen Ladder-Zustand und physischem Gerätezustand.

Hier wird OLLA Lab operativ nützlich.

OLLA Lab ist hier am besten als eine begrenzte Validierungs- und Probenumgebung zu verstehen. Ingenieure können Ladder-Logik im Browser erstellen, im Simulationsmodus ausführen, I/Os und Variablen inspizieren und die Auswirkungen auf 3D- oder WebXR-Gerätemodelle beobachten, die realistische industrielle Szenarien darstellen. In diesem Workflow ist das Produkt kein Konformitätsgenerator und kein Ersatz für eine formale Sicherheitsbewertung. Es ist ein Ort, um abnormale Bedingungen sicher und wiederholt zu induzieren, bevor die physische Inbetriebnahme teurer wird.

Warum rein physische Tests ein schlechter erster Durchgang sind

Physische Tests von Hochgeschwindigkeits-Zonenverletzungen sind durch offensichtliche Einschränkungen begrenzt:

• sie setzen Personal und Ausrüstung vermeidbaren Risiken aus,
• sie sind mit identischem Timing schwer zu wiederholen,
• sie können die Hardware verschleißen,
• sie ermutigen Teams dazu, nur „vernünftige“ Fälle zu testen,
• und sie finden oft zu spät statt, nachdem mechanische und terminliche Festlegungen bereits getroffen wurden.

Was „Simulation-Ready“ in diesem Kontext bedeutet

Simulation-Ready bedeutet nicht, mit der PLC-Syntax vertraut zu sein oder sich in einem 3D-Viewer wohlzufühlen. Es bedeutet, dass ein Ingenieur die Steuerungslogik gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor sie einen Live-Prozess erreicht.

Beobachtbare Verhaltensweisen eines Simulation-Ready-Ingenieurs sind:

• Definition dessen, was „korrekt“ bedeutet, vor dem Testen,
• Verfolgung von I/O-Änderungen durch Ladder-Zustand und Maschinenreaktion,
• gezieltes Injizieren von Fehlern,
• Vergleich des befohlenen Zustands mit dem simulierten Gerätezustand,
• Überarbeitung der Logik nach abnormalem Verhalten,
• und Dokumentation, warum die Überarbeitung das Steuerungsergebnis verbessert.

OEMs können OLLA Lab als risikobegrenzte Sandbox nutzen, um risikoreiche Logikverhaltensweisen zu proben, die auf physischer Hardware schwer, teuer oder unsicher zu testen sind.

Innerhalb des dokumentierten Umfangs des Produkts umfasst dies:

• Erstellen von Ladder-Logik in einem webbasierten Editor,
• Ausführen und Stoppen von Logik im Simulationsmodus,
• Umschalten von Eingängen und Beobachten von Ausgängen,
• Überwachen von Variablen, Analogwerten und PID-bezogenen Zuständen,
• Validieren der Logik anhand von 3D- oder WebXR-Maschinenmodellen,
• und Durcharbeiten von szenariobasierten Sequenzen, Gefahren, Verriegelungen und Inbetriebnahmeanmerkungen.

Für kollaborative Anwendungen unterstützt dies einen praktischen Validierungsworkflow wie:

1. Erstellen der sicherheitsbezogenen Zustandslogik für Warn-, Reduziergeschwindigkeits-, Stopp-, Reset- und Fehlerbedingungen.
2. Verknüpfen des Logikverhaltens mit einem Maschinenszenario, das Bewegung und Arbeitsbereichsinteraktion beinhaltet.
3. Injizieren von Scanner-Verletzungen, Kommunikationsverlust, Nutzlaständerungen oder Neustart-Grenzfällen.
4. Beobachten, ob der simulierte Maschinenzustand mit der beabsichtigten Sicherheitssequenz übereinstimmt.
5. Überarbeiten von Timing, Freigaben oder Fehlerbehandlung.
6. Bewahren des Nachweispfads.

Der Wert liegt nicht darin, dass die Simulation Vor-Ort-Tests ersetzt. Der Wert liegt darin, dass sie vermeidbare Unwissenheit beseitigt, bevor die Vor-Ort-Tests beginnen.

Die Simulation sollte als technischer Nachweis zu einem Konformitäts-Entscheidungspaket beitragen, nicht als dekorativer Anhang. Auditoren und Sicherheitsprüfer lassen sich durch rückverfolgbare Argumentation, begrenzte Testnachweise und Revisionshistorie überzeugen, nicht durch einen Ordner voller Screenshots.

Verwenden Sie diese kompakte Nachweisstruktur:

1) Systembeschreibung

Dokumentieren Sie:

• Zweck der Zelle,
• Roboteraufgabe,
• Werkzeug und Nutzlast,
• Sensorgeräte,
• Sicherheitsfunktionen,
• Betriebsmodi,
• und die beabsichtigte Grenze der menschlichen Interaktion.

2) Operative Definition von „korrekt“

Definieren Sie beobachtbare Erfolgskriterien wie:

• Befehl zur Geschwindigkeitsreduzierung erfolgt innerhalb der Warnzonenbedingung,
• gefährliche Bewegung wird bei Verletzung der Schutzzone gehemmt,
• Neustart erfordert Reset und alle Freigaben auf „wahr“,
• Verlust der Scanner-Integrität zwingt das System in einen sicheren Zustand,
• simuliertes Stoppverhalten bleibt innerhalb der geschützten Hülle.

Wenn „korrekt“ nicht in beobachtbaren Begriffen definiert ist, ist der Test nicht sehr nützlich.

3) Ladder-Logik und simulierter Gerätezustand

Bewahren Sie auf:

• die getestete Ladder-Version,
• den Variablen- und I/O-Zustand bei jedem Übergang,
• die entsprechende Maschinenbewegung oder das Stoppverhalten im Digitalen Zwilling,
• und alle relevanten Analog- oder Timing-Werte.

Dies ist der Kernvergleich: Ladder-Zustand versus Gerätezustand.

4) Der injizierte Fehlerfall

Geben Sie genau an, was injiziert wurde, zum Beispiel:

• Warnzonenverletzung während der Bewegung mit voller Geschwindigkeit,
• Schutzzonenverletzung während der Fahrt mit maximaler Nutzlast,
• Verlust der Scanner-Kommunikation,
• Übergang durch falsche Freigabe,
• Neustartanforderung mit unvollständigen Freigaben,
• oder aktives Muting bei unerwartetem menschlichem Eindringen.

5) Die vorgenommene Revision

Dokumentieren Sie die tatsächliche technische Änderung:

• Anpassung der Entprellung,
• Änderung der Stoppkategorie,
• überarbeiteter Schwellenwert für Geschwindigkeitsreduzierung,
• hinzugefügte Freigabe für Integritätsprüfung,
• Korrektur der Reset-Sequenz,
• oder geänderte Verriegelungsstruktur.

6) Gelernte Lektionen

Halten Sie fest, was der Test ergeben hat, wie zum Beispiel:

• Annahmen zur Reaktionszeit waren optimistisch,
• Nutzlastträgheit veränderte die sichere Zeitmarge,
• Scanner-Integrität benötigte explizite Fehlerbehandlung,
• oder Zustandsübergänge waren logisch gültig, aber physisch zu spät.

Dieser Nachweis ist im Allgemeinen glaubwürdiger als ein poliertes Dashboard ohne dahinterliegende Testlogik.

Die Standardbasis sollte explizit sein. Kollaborative Anwendungen liegen an der Schnittstelle von Robotersicherheit, funktionaler Sicherheit und anwendungsspezifischer Risikobewertung.

Häufig relevante Referenzen sind:

• ISO 10218-1 / ISO 10218-2 für Sicherheitsanforderungen an Industrieroboter und deren Integration.
• ISO/TS 15066 für Leitlinien zu kollaborativen Roboteranwendungen.
• IEC 61508 für den breiteren Rahmen der funktionalen Sicherheit elektrischer, elektronischer und programmierbarer Systeme.
• Technische Beratung durch Organisationen wie exida und anerkannte Experten für Maschinensicherheit zur Interpretation der Implementierung.
• Peer-Review-Literatur zu Digitalen Zwillingen, cyber-physischer Validierung und industrieller Simulation aus Quellen wie IFAC-PapersOnLine, Sensors und verwandten Fachzeitschriften für Fertigungssysteme.

Eine Warnung sei klar ausgesprochen: Kein Simulator, einschließlich OLLA Lab, gewährt Konformität durch Assoziation. Die Konformität hängt vom vollständigen Anwendungsdesign, der Risikobewertung, der implementierten Sicherheitsarchitektur, dem Validierungsprotokoll und den endgültigen Installationsbedingungen ab.

OEM-Teams sollten aufhören zu fragen, ob der Roboter kollaborativ ist, und anfangen zu fragen, ob das Anwendungsverhalten unter Fehlerbedingungen nachweislich sicher ist.

Die praktische Sequenz ist:

• kollaborativen Modus definieren,
• Schutzfunktionen identifizieren,
• Stopp- und Abstandsverhalten modellieren,
• Ladder-Logik gegen realistische Maschinenbewegung validieren,
• abnormale Zustände vor der Vor-Ort-Inbetriebnahme injizieren,
• und ein rückverfolgbares Nachweispaket bewahren.

Das ist der Unterschied zwischen einem plausiblen Design und einem verteidigbaren.

Link UP: Für ein grundlegendes Verständnis der Sicherheitsarchitektur kehren Sie zu unserem Ladder Logic Mastery Hub zurück.

Link ACROSS 1: Um zu verstehen, wie diese Standards auf spezifische Hardwareklassen angewendet werden, lesen Sie ISO 10218-1:2025: Navigating the New Robot Safety Classifications.

Link ACROSS 2: Für einen tieferen Einblick in die Programmierung von Bereichsscannern, siehe Programming the Virtual Safety Fence: Dynamic Zone Logic in the PLC.

Link DOWN: Benötigen Sie eine begrenzte Umgebung, um kollaborative Logik und Fehlerfälle zu proben? Öffnen Sie das Collaborative Palletizer Scenario in OLLA Lab.

- ISO 10218 Roboter und Robotikgeräte Standardseite - ANSI/RIA R15.06 Übersicht - IEC 61508 Funktionale Sicherheit Übersicht - NIST Cybersecurity Framework 2.0 - Grundlagen Digitaler Zwillinge (IEEE Access)