Programmierung dynamischer AMR-Sicherheitszonen in einer SPS mit LiDAR-Logik

Ein virtueller Sicherheitszaun für ein AMR ist eine SPS-gesteuerte Geschwindigkeits- und Stoppstrategie, die LiDAR-Feldverletzungen auf deterministische Bewegungsgrenzen abbildet. In der Praxis drosselt die Steuerung den Roboter von voller Geschwindigkeit auf einen Warn-Geschwindigkeits-Sollwert oder auf Null, basierend auf aktiven Schutzfeldern und fehlersicherer Eingangslogik gemäß ISO 3691-4.

Ein virtueller Sicherheitszaun ist kein gemalter Kreis in einer Software. Er ist eine deterministische Steuerungsreaktion auf eine räumliche Intrusion. Wenn der Reaktionspfad schwach ist, ist der Zaun im falschen Sinne imaginär.

Für AMRs ist die nützliche Unterscheidung nicht „Sensor installiert versus Sensor abwesend“, sondern Warnfeld-Verzögerung versus Schutzfeld-Stopp, ausgeführt über einen Scan-Pfad, den Sie tatsächlich verifizieren können. Die ISO 3691-4 definiert das Sicherheitsziel; die SPS und die Sicherheitsarchitektur entscheiden, ob die Maschine korrekt reagiert, wenn jemand in den Pfad tritt.

Ampergon Vallis Metrik: Bei der internen Validierung eines AMR-LiDAR-Szenarios in OLLA Lab führte die Weiterleitung der Warnzonen-Geschwindigkeitsreduzierung über einen standardmäßigen, nicht sicherheitsgerichteten Ethernet-Pfad zu einer Befehlsverzögerung, die bei 3 von 12 Hochgeschwindigkeits-Anfahrtests zu einer Zonenüberschreitung führte. Die direkte Abbildung des virtuellen Warnsignals auf lokale Steuerungseingänge eliminierte diese Überschreitungen im gleichen Szenario-Set. Methodik: 12 simulierte Anfahrtests bei 2,0 m/s gegen ein festes Warn-/Schutzfeld-Layout, Basis-Vergleichswert = netzwerkgeroutete Geschwindigkeitsdrosselung, Zeitfenster = Validierungssitzung März 2026. Dies stützt eine einzige, eng gefasste Erkenntnis: Das Design des Signalpfads beeinflusst das simulierte Stoppverhalten maßgeblich. Es stellt keine universelle Latenzzahl für alle AMR-Architekturen dar.

Die Rolle von OLLA Lab ist hier begrenzt und praxisorientiert. Es ist eine webbasierte Umgebung für Kontaktplan-Logik und digitale Zwillinge, um risikoreiche Validierungsaufgaben – Logiktests, E/A-Tracing, Fehlerinjektion und Revisionen im Stil der Inbetriebnahme – zu erproben, bevor sie an einem echten Fahrzeug getestet werden. Syntax ist günstig. Sichere Implementierbarkeit ist es nicht.

Eine dynamische Sicherheitszone ist eine LiDAR-definierte Schutzhülle, die den zulässigen Bewegungszustand des AMR basierend auf erkannter Intrusion und – in manchen Architekturen – Fahrzeugkinematik wie Geschwindigkeit oder Lenkwinkel ändert.

Operativ gesehen ist der „virtuelle Sicherheitszaun“ keine einzelne Zone, sondern ein Feldsatz. Eine typische Anordnung umfasst:

• ein Freifeld, in dem die befohlene Fahrt erlaubt ist,
• ein Warnfeld, in dem die Geschwindigkeit reduziert wird, und
• ein Schutzfeld, in dem die Bewegung durch eine sicherheitsgerichtete Aktion gestoppt wird.

Diese Unterscheidung ist wichtig, da nicht jede Intrusion die gleiche Maschinenreaktion hervorrufen sollte. Eine Geschwindigkeitsdrosselung ist oft die richtige Antwort, bevor ein Nothalt notwendig wird.

Wie unterscheiden sich Warn- und Schutzfelder?

Das Warnfeld ist eine Bedingung für eine kontrollierte Verzögerung. Das Schutzfeld ist eine Stopp-Bedingung.

| LiDAR-Feldzustand | Typische Auslösebedingung | SPS / Sicherheitsreaktion | AMR-Geschwindigkeitsbefehl | Typischer Zweck | |---|---|---|---|---| | Freizone | Keine Intrusion erkannt | Normale Bewegung erlaubt | 100% Referenz, z. B. 2,0 m/s | Normalfahrt | | Warnzone | Objekt oder Person im äußeren Feld erkannt | Geschwindigkeitsdrosselung, oft mit Alarm oder Warnleuchte | Reduzierter Sollwert, z. B. 15% | Kontrollierte Verzögerung und Risikoreduzierung | | Schutzzone | Objekt oder Person im inneren Feld erkannt | Schutzstopp, oft gekoppelt an STO oder äquivalenten sicheren Stopppfad | 0% | Kontakt oder gefährliche Annäherung verhindern |

Welchen Bezug hat die ISO 3691-4 zu dieser Logik?

Die ISO 3691-4:2020 behandelt Sicherheitsanforderungen und die Verifizierung für fahrerlose Flurförderzeuge und deren Systeme. Für diesen Artikel ist der relevante technische Punkt einfach: Das AMR muss Gefahren erkennen und in einem validierten Architektur-Rahmen in einen geeigneten risikoreduzierenden Zustand übergehen.

Das bedeutet nicht: „Scanner drauf und hoffen, dass der Antrieb reagiert.“ Es bedeutet, dass Feldlogik, Stoppkategorie, Verzögerungsverhalten und Verifizierungsmethode als System kohärent sein müssen.

Was bedeutet „Simulation-Ready“ in diesem Kontext?

„Simulation-Ready“ bedeutet, dass ein Ingenieur die Zonenlogik gegen realistisches Maschinenverhalten beweisen, beobachten, diagnostizieren und härten kann, bevor sie ein echtes AMR erreicht.

Operativ umfasst dies die Fähigkeit:

• LiDAR-Feldzustandsänderungen zu beobachten,
• diese Änderungen in SPS- oder Sicherheitssteuerungseingänge zu verfolgen,
• den resultierenden Geschwindigkeitssollwert oder Stoppbefehl zu verifizieren,
• anormale Bedingungen wie veraltete Eingänge oder verzögerte Befehle zu injizieren,
• den Kontaktplan-Zustand mit der simulierten Fahrzeugbewegung zu vergleichen, und
• die Logik nach einem fehlgeschlagenen Test zu überarbeiten.

Das ist die nützliche Schwelle: nicht nur eine Sprosse zu zeichnen, sondern einen Reaktionspfad zu validieren.

Sie bilden LiDAR-Felddaten auf die SPS-Logik ab, indem Sie Scanner-Ausgänge in deterministische Eingangszustände umwandeln, die den Feldstatus repräsentieren, und diese Zustände dann nutzen, um die Geschwindigkeitsdrosselung oder das Stoppverhalten zu steuern.

In vielen realen Systemen stellen Sicherheitsscanner den Feldstatus über sicherheitsgerichtete Ausgänge wie OSSD-Paare, sichere Feldbusse oder eine Schnittstelle zur Sicherheitssteuerung bereit. Der genaue Hardwarepfad variiert, aber das Steuerungsprinzip nicht: Die SPS oder Sicherheitsebene muss einen eindeutigen Zustand erhalten, der ohne interpretative Vermutungen ausgewertet werden kann.

Was sollte die SPS tatsächlich empfangen?

Die Steuerung sollte diskrete, begrenzte Feldzustandssignale empfangen, wie zum Beispiel:

• `LIDAR_CLEAR_OK`
• `LIDAR_WARNING_ACTIVE`
• `LIDAR_PROTECTIVE_ACTIVE`
• `SCANNER_FAULT`
• `FIELDSET_SELECT_VALID`

Dies ist vagen Abstraktionen vorzuziehen. Wenn der Tag-Name Ihnen nicht sagen kann, welchen Maschinenzustand er repräsentiert, wird die Inbetriebnahme dies schließlich für Sie tun.

Warum sind fehlersichere Eingangskonventionen wichtig?

Das Design fehlersicherer Eingänge ist wichtig, da ein Kabelbruch, ein Signalverlust oder ein Scannerfehler das System in einen sicheren Zustand versetzen muss, anstatt eine fortgesetzte Bewegung zu erlauben.

Bei Sicherheitskreisen bedeutet dies in der Regel, auf der funktionalen Ebene mit Öffner-Logik (Normally Closed) zu arbeiten, selbst wenn die exakte Geräteschnittstelle zweikanalige elektronische Ausgänge anstelle einer wörtlichen NC-Kette mit Trockenkontakten verwendet. Das technische Prinzip ist der Punkt: Der Verlust eines gesunden Signals darf nicht als Erlaubnis zum Fahren interpretiert werden.

Eine praktische Abbildung könnte so aussehen:

• Gesunde Scannerkanäle vorhanden = Bewegung kann ausgewertet werden
• Warnfeld verletzt = reduzierter Geschwindigkeitsbefehl
• Schutzfeld verletzt = Stoppbefehl
• Kanal-Diskrepanz oder Scannerfehler = Stoppbefehl
• Ungültige Feldsatzwahl = Stopp oder Bewegungshemmung, je nach Risikobeurteilung

Was ist mit dynamischer Feldumschaltung?

Dynamische Feldumschaltung bedeutet, dass sich der aktive LiDAR-Feldsatz mit dem Maschinenzustand ändert, üblicherweise basierend auf:

• aktueller Geschwindigkeit,
• Lenkwinkel,
• Fahrtrichtung,
• Beladungszustand,
• Gang-Modus oder Freiflächen-Modus,
• Andock- oder Präzisionsanfahrzustand.

Hier wird das „dynamisch“ in der dynamischen Sicherheitszone real. Die Schutzhülle für ein langsames Andockmanöver muss nicht zwingend der Hülle für eine Fahrt auf freier Fläche bei voller Geschwindigkeit entsprechen.

Sie schreiben die Logik für die AMR-Geschwindigkeitsdrosselung, indem Sie den aktiven LiDAR-Zonenzustand auswerten, für jede gültige Bedingung einen begrenzten Geschwindigkeitssollwert zuweisen und für jeden Schutz- oder Fehlerzustand einen Nullgeschwindigkeits- oder Stopppfad erzwingen.

Die Kontaktplan-Logik sollte so lesbar sein, dass ein anderer Ingenieur sie schnell prüfen kann. Sicherheitsrelevante Logik ist nicht der Ort für ornamentale Cleverness.

### Schritt 1: LiDAR-Eingänge lesen und normalisieren

Beginnen Sie damit, den Status des Scanners oder der Sicherheitssteuerung in benannte Tags zu bringen.

Beispiel-Eingangs-Tags:

• `LIDAR_Healthy`
• `Zone_Warning`
• `Zone_Protective`
• `AMR_Enable`
• `Drive_Permissive`
• `Scanner_Fault`

Normalisieren Sie in diesem Stadium widersprüchliche Zustände. Wenn `Zone_Warning` und `Zone_Protective` beide aktiv sind, sollte die Logik den restriktiveren Zustand auflösen.

### Schritt 2: Eine einzelne Zonen-Zustandsentscheidung treffen

Verwenden Sie interne Bits oder ein Ganzzahl-Zustandsregister, um eine maßgebliche Bewegungsbedingung festzulegen.

Beispiel-Zustandspriorität:

1. Fehler oder ungesunder Scanner
2. Schutzzone aktiv
3. Warnzone aktiv
4. Freizone

Priorität ist wichtig, da die Bewegungslogik bei Mehrdeutigkeit sicher degradieren sollte.

### Schritt 3: Den korrekten Geschwindigkeitssollwert bewegen

Verwenden Sie begrenzte Ganzzahl- oder Real-Werte, um den AMR-Geschwindigkeitssollwert zu steuern.

Illustratives Kontaktplan-Konzept:

Sprache: Kontaktplan (Ladder Diagram)

// Schutzstopp-Logik |---[/]-------------------------------[MOV]---|     LIDAR_Healthy                       0                                             AMR_Speed_Ref

|---[ ]--------------------------------[MOV]---|     Zone_Protective                    0                                             AMR_Speed_Ref

// Warnzonen-Geschwindigkeitsdrosselungs-Logik |---[ ]---[/]--------------------------[MOV]---|     Zone_Warning  Zone_Protective       15                                             AMR_Speed_Ref

// Freizonen-Normalgeschwindigkeit |---[/]---[/]---[ ]--------------------[MOV]---|     Zone_Warning Zone_Protective AMR_Enable                                             100                                             AMR_Speed_Ref

Dies ist absichtlich einfach gehalten. In einer Produktionsarchitektur würden Sie die Standard-Geschwindigkeitsreferenzlogik oft vom sicherheitsgerichteten Stopppfad trennen und die Interaktion sorgfältig verifizieren.

### Schritt 4: Trennung von Geschwindigkeitsdrosselung und Schutzstopppfad

Ein reduzierter Geschwindigkeitsbefehl ist nicht dasselbe wie ein Sicherheitsstopp.

Diese Unterscheidung ist in einem Simulator leicht zu verwischen und auf einer echten Maschine gefährlich. Eine Geschwindigkeitsreferenz von Null, die über eine Standard-Steuerungslogik ausgegeben wird, ist nicht automatisch äquivalent zu einer sicherheitsgerichteten Stoppfunktion. Je nach Architektur muss die Schutzaktion möglicherweise Safe Torque Off (STO), Safe Stop 1 (SS1) oder eine andere validierte Sicherheitsfunktion gemäß den Designprinzipien von IEC 62061 / IEC 61508 auslösen.

### Schritt 5: Diagnosen und Verriegelungen hinzufügen, wo gerechtfertigt

Diagnosen verbessern die Inbetriebnahme und Fehlerisolierung.

Nützliche Ergänzungen sind:

• Alarm bei ungesundem Scanner,
• Alarm bei ungültigem Zustand,
• Protokollierung von Zonenüberschreitungsereignissen,
• Stoppursachen-Register,
• Anforderung eines manuellen Resets nach einem Schutzstopp, sofern die Risikobeurteilung dies erfordert.

Eine Maschine, die stoppt, ohne Ihnen den Grund zu nennen, ist nur halb kooperativ.

Das korrekte Stoppverhalten hängt von der Risikobeurteilung der Maschine, der Nutzlast, der Dynamik und dem Design der validierten Sicherheitsfunktion ab.

Ein häufiges Missverständnis ist, dass der schnellste Stopp immer der sicherste Stopp ist. Das ist er nicht. Ein Stopp der Kategorie 0 unterbricht sofort die Energiezufuhr; bei einigen AMRs, insbesondere solchen, die instabile Lasten oder Flüssigkeiten transportieren, kann dies durch Trägheit, Schwappen oder Verlust der kontrollierten Bremsung sekundäre Gefahren erzeugen.

Wann ist eine Geschwindigkeitsreduzierung in der Warnzone angemessen?

Die Reduzierung in der Warnzone ist angemessen, wenn das Ziel darin besteht, die kinetische Energie zu senken, bevor ein Schutzstopp notwendig wird.

Typische Anwendungen sind:

• Fahrt auf freier Fläche, wo Fußgängerpräsenz plausibel ist,
• lange Bremswege bei höherer Geschwindigkeit,
• Umgebungen mit intermittierender Intrusion in äußere Erfassungsfelder,
• Anwendungen, bei denen eine kontrollierte Verzögerung die Stabilität verbessert.

Wann ist ein Schutzstopp erforderlich?

Ein Schutzstopp ist erforderlich, wenn die Intrusion das innere Feld erreicht oder wenn der Scanner oder der Sicherheitspfad keine sichere Bewegung mehr garantieren kann.

Dies kann führen zu:

• Safe Torque Off (STO),
• einem kontrollierten Stopp mit anschließender Abschaltung des Drehmoments,
• Bewegungshemmung plus Reset-Sequenz,
• oder einer anderen validierten Sicherheitsreaktion, die durch die Sicherheitsfunktion der Maschine definiert ist.

Die Norm belohnt keine Improvisation. Sie belohnt den Nachweis.

Sie validieren SPS-LiDAR-Logik gegen einen digitalen Zwilling, indem Sie den Steuerungszustand, die befohlene Geschwindigkeit und die simulierte AMR-Bewegung sowohl unter normalen als auch unter fehlerhaften Bedingungen vergleichen.

Hier wird OLLA Lab operativ nützlich. Sein browserbasierter Kontaktplan-Editor, der Simulationsmodus, das Variablen-Panel und die 3D/WebXR-Szenarien ermöglichen es Ingenieuren, Ursache und Wirkung zu testen, ohne Menschen oder Hardware dem ersten Entwurf der Logik auszusetzen.

Was sollten Sie zuerst testen?

Beginnen Sie mit den minimalen deterministischen Fällen:

• Freizone aktiv, kein Warn- oder Schutzzustand,
• Warnzonen-Verletzung bei Nenngeschwindigkeit,
• Schutzzonen-Verletzung bei Nenngeschwindigkeit,
• Scannerfehler,
• Verlust des gesunden Signals,
• widersprüchlicher Zonenzustands-Eingang,
• Reset- und Neustartverhalten nach einem Stopp.

Verwenden Sie das Variablen-Panel, um Folgendes zu beobachten:

• aktive Zonen-Bits,
• `AMR_Speed_Ref`,
• Antriebsfreigabezustand,
• Stoppursachen-Tag,
• Alarm-Bits,
• jegliche Timer- oder Entprellungslogik.

Wie sieht ein gültiger Test mit einem digitalen Zwilling aus?

Ein gültiger Test ist nicht „der Roboter wurde einmal langsamer“. Es ist ein wiederholbarer Vergleich zwischen erwartetem und beobachtetem Verhalten.

In OLLA Lab bedeutet das, dass Sie:

• Zonenzustände umschalten oder induzieren können,
• den Übergang im Kontaktplan beobachten können,
• das Geschwindigkeitsreferenzregister inspizieren können,
• die AMR-Reaktion im 3D-Szenario sehen können,
• den Test unter denselben Bedingungen wiederholen können,
• und die Logik überarbeiten können, wenn die Maschinenreaktion nicht der beabsichtigten Steuerungsphilosophie entspricht.

Das ist der Unterschied zwischen Animation und Validierung.

Warum ist Live-Testen an einem physischen AMR ein schlechter Ort, um dies zu lernen?

Live-Tests sind teuer, gefährlich und in der Regel nicht tolerant gegenüber explorativen Fehlern.

Ein Junior-Ingenieur sollte nicht an einem fahrenden, beladenen Fahrzeug entdecken müssen, dass eine Warnzonen-Drosselung über einen langsamen oder nicht-deterministischen Pfad geleitet wurde. OLLA Lab bietet eine begrenzte Erprobungsumgebung für genau diese Art von Fehlern: hohe Konsequenz, häufig genug, um wichtig zu sein, und schwierig sicher an echter Ausrüstung zu üben.

Sie sollten einen kompakten Satz technischer Nachweise dokumentieren, keine Screenshot-Galerie.

Verwenden Sie diese Struktur:

Fassen Sie die steuerungstechnische Erkenntnis zusammen, nicht nur das Ergebnis. Zum Beispiel: „Die Warnzonen-Reduzierung über Standard-Netzwerksteuerung war funktional korrekt, aber für diesen Anfahrgeschwindigkeitsfall zu langsam.“

1. Systembeschreibung Definieren Sie den AMR-Modus, die Scanneranordnung, die Feldlogik, die Antriebsschnittstelle und relevante Annahmen.
2. Operative Definition von „korrekt“ Geben Sie genau an, was in Freizonen-, Warn-, Schutz- und Fehlerzuständen passieren muss.
3. Kontaktplan-Logik und simulierter Ausrüstungszustand Erfassen Sie die relevanten Sprossen, Tags und das entsprechende AMR-Verhalten im Simulator.
4. Der injizierte Fehlerfall Zeichnen Sie die eingeführte anormale Bedingung auf, wie z. B. Scannerfehler, veraltetes Warn-Bit oder verzögerte Geschwindigkeitsdrosselung.
5. Die vorgenommene Revision Zeigen Sie, was sich in der Logik, der Sequenzierung oder dem Signalpfad geändert hat.
6. Gelernte Lektionen

Diese Form des Nachweises ist nützlicher als ein poliertes Dashboard-Bild ohne Fehlerhistorie. Inbetriebnahmegedächtnis wird aus Revisionen aufgebaut, nicht aus Kosmetik.

Die primären Normen und technischen Rahmenwerke sind funktionale Sicherheit und Sicherheit mobiler Roboter, nicht generischer Robotik-Optimismus.

Die relevantesten Referenzen sind:

- ISO 3691-4:2020 für fahrerlose Flurförderzeuge und deren Systeme,

• IEC 62061 für die funktionale Sicherheit von Maschinensteuerungen,
• IEC 61508 als grundlegendes Rahmenwerk für funktionale Sicherheit,
• Handbücher der Hersteller von Sicherheitsscannern für Feldkonfiguration und Reaktionsverhalten,
• und anwendungsspezifische Risikobeurteilungen, die erforderliche Sicherheitsfunktionen und Stoppverhalten definieren.

Akademische und industrielle Literatur zu digitalen Zwillingen und simulationsbasierter Validierung ist ebenfalls relevant, sollte aber vorsichtig verwendet werden. Simulation kann die Qualität der Erprobung, die Fehlersichtbarkeit und die Vorbereitung der Inbetriebnahme verbessern; sie ersetzt nicht die formale Sicherheitsvalidierung am realen System.

OLLA Lab passt als risikobegrenzte Validierungs- und Erprobungsumgebung für Kontaktplan-Logik, E/A-Verhalten, Beobachtung digitaler Zwillinge und Fehlersuche im Stil der Inbetriebnahme.

Richtig begrenzt ist das ein starker Anspruch und ein nützlicher. OLLA Lab ermöglicht Ingenieuren:

• Kontaktplan-Logik in einem webbasierten Editor zu erstellen,
• Simulation ohne physische Hardware auszuführen,
• Tags und E/A im Variablen-Panel zu überwachen,
• AMR-ähnliche Szenarien in 3D/WebXR-Umgebungen durchzuarbeiten,
• und zu testen, wie Steuerungslogik auf Maschinenverhalten abgebildet wird, bevor sie vor Ort eingesetzt wird.

Es zertifiziert keine Sicherheitsfunktion, ersetzt keine formale Risikobeurteilung und macht ein echtes AMR nicht durch Assoziation sicher. Ein Simulator ist ein Proberaum, kein Konformitätsstempel.

Die Programmierung eines virtuellen Sicherheitszauns ist ein Steuerungsproblem mit Sicherheitskonsequenzen. Die Kernaufgabe besteht darin, LiDAR-Feldzustände auf deterministische Maschinenreaktionen abzubilden und dann zu verifizieren, dass das AMR unter normalen und fehlerhaften Bedingungen tatsächlich wie beabsichtigt verlangsamt oder stoppt.

Die dauerhafte Unterscheidung ist einfach: Sensorpräsenz versus validierter Reaktionspfad. Viele Integrationsprobleme liegen in dieser Lücke.

Ein nützlicher Ingenieur in diesem Bereich ist nicht nur in der Kontaktplan-Syntax fließend. Ein nützlicher Ingenieur kann korrektes Verhalten definieren, es gegen simulierte Ausrüstung testen, Fehler injizieren, die Logik überarbeiten und erklären, warum der endgültige Steuerungspfad sicherer ist als der erste Entwurf.

- Für angrenzenden Kontext zur Robotersicherheit, siehe ISO 10218-1:2025: Navigating the New Robot Safety Classifications. - Für Integration auf Anlagenebene und Compliance-Druck, siehe Collaborative Application Standards 2026: The OEM Survival Guide.

• Um diese Logik in ein breiteres Steuerungssystemverhalten einzuordnen, lesen Sie das Advanced Process Control and PID Simulation Lab.
• Das Testen an physischer Hardware ist riskant. Öffnen Sie das AMR-LiDAR-Szenario in OLLA Lab, um die Zonenlogik gegen einen digitalen 3D-Zwilling zu validieren.

- ISO 3691-4 Sicherheitsanforderungen für fahrerlose Flurförderzeuge - IEC 62061 Funktionale Sicherheit von Maschinensteuerungen - IEC 61508 Überblick zur funktionalen Sicherheit - Digital Twin in Manufacturing review (IFAC-PapersOnLine) - Cyber-Physical Systems in Industry 4.0 (AQTR)