How to Program AMR Dynamic Safety Zones in a PLC with LiDAR Logic

A virtual safety fence for an AMR is a PLC-controlled speed and stop strategy that maps LiDAR field infringements to deterministic motion limits. In practice, the controller clamps the robot from full speed to a warning-speed setpoint or to zero, based on active protective fields and fail-safe input logic aligned with ISO 3691-4.

A virtual safety fence is not a painted circle in software. It is a deterministic control response to spatial intrusion, and if the response path is weak, the fence is imaginary in exactly the wrong way.

For AMRs, the useful distinction is not “sensor installed versus sensor absent,” but warning-field deceleration versus protective-field stop, executed through a scan path you can actually verify. ISO 3691-4 frames the safety objective; the PLC and safety architecture decide whether the machine behaves correctly when someone steps into the path.

Ampergon Vallis Metric: In internal validation of an AMR LiDAR scenario in OLLA Lab, routing warning-zone speed reduction through a standard non-safety Ethernet path added enough command delay to produce zone overrun in 3 of 12 high-speed approach tests, while direct mapping of the virtual warning signal to local controller inputs eliminated those overruns in the same scenario set. Methodology: 12 simulated approach tests at 2.0 m/s against a fixed warning/protective field layout, baseline comparator = network-routed speed clamp, time window = March 2026 validation session. This supports one narrow point: signal-path design materially affects simulated stopping behavior. It does not establish a universal latency figure for all AMR architectures.

OLLA Lab’s role here is bounded and practical. It is a web-based ladder logic and digital twin environment for rehearsing high-risk validation tasks—logic testing, I/O tracing, fault injection, and commissioning-style revision—before anyone tries them on a live vehicle. Syntax is cheap. Safe deployability is not.

A dynamic safety zone is a LiDAR-defined protective envelope that changes the AMR’s permitted motion state based on detected intrusion and, in some architectures, vehicle kinematics such as speed or steering angle.

In operational terms, the “virtual safety fence” is not one zone but a field set. A typical arrangement includes:

• a clear field, where commanded travel is allowed,
• a warning field, where speed is reduced, and
• a protective field, where motion is stopped through a safety-rated action.

That distinction matters because not every intrusion should produce the same machine response. A speed clamp is often the right answer before a hard stop becomes necessary.

How do warning and protective fields differ?

The warning field is a controlled deceleration condition. The protective field is a stop condition.

| LiDAR Field State | Typical Trigger Condition | PLC / Safety Response | AMR Speed Command | Typical Purpose | |---|---|---|---|---| | Clear Zone | No intrusion detected | Normal motion permitted | 100% reference, e.g. 2.0 m/s | Normal travel | | Warning Zone | Object or person detected in outer field | Clamp speed, often with alarm or beacon | Reduced setpoint, e.g. 15% | Controlled deceleration and risk reduction | | Protective Zone | Object or person detected in inner field | Protective stop, often tied to STO or equivalent safe stop path | 0% | Prevent contact or hazardous approach |

How does ISO 3691-4 relate to this logic?

ISO 3691-4:2020 addresses safety requirements and verification for driverless industrial trucks and their systems. For this article, the relevant engineering point is straightforward: the AMR must detect hazards and transition to an appropriate risk-reducing state within a validated architecture.

That does not mean “put a scanner on it and hope the drive behaves.” It means the field logic, stop category, deceleration behavior, and verification method must be coherent as a system.

What does “Simulation-Ready” mean here?

“Simulation-Ready” means an engineer can prove, observe, diagnose, and harden the zone logic against realistic machine behavior before it reaches a live AMR.

Operationally, that includes the ability to:

• observe LiDAR field-state changes,
• trace those changes into PLC or safety-controller inputs,
• verify the resulting speed reference or stop command,
• inject abnormal conditions such as stale inputs or delayed commands,
• compare ladder state against simulated vehicle motion, and
• revise the logic after a failed test.

That is the useful threshold: not just drawing a rung, but validating a response path.

You map LiDAR field data to PLC logic by converting scanner outputs into deterministic input states that represent field status, then using those states to drive speed clamping or stop behavior.

In many real systems, safety scanners expose field status through safety-rated outputs such as OSSD pairs, safe fieldbus, or a safety controller interface. The exact hardware path varies, but the control principle does not: the PLC or safety layer must receive an unambiguous state that can be evaluated without interpretive guesswork.

What should the PLC actually receive?

The controller should receive discrete, bounded field-state signals such as:

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

This is preferable to vague abstractions. If the tag name cannot tell you what machine state it represents, commissioning will eventually do it for you.

Why do fail-safe input conventions matter?

Fail-safe input design matters because a broken wire, lost signal, or scanner fault must bias the system toward a safe state rather than continued motion.

For safety circuits, this usually means designing around normally closed safety logic behavior at the functional level, even if the exact device interface uses dual-channel electronic outputs rather than a literal dry-contact NC chain. The engineering principle is the point: loss of healthy signal must not be interpreted as permission to run.

A practical mapping might look like this:

• Healthy scanner channels present = motion may be evaluated
• Warning field infringed = reduced speed command
• Protective field infringed = stop command
• Channel disagreement or scanner fault = stop command
• Invalid fieldset selection = stop or inhibit motion, depending on risk assessment

What about dynamic field switching?

Dynamic field switching means the active LiDAR field set changes with machine state, commonly based on:

• current speed,
• steering angle,
• direction of travel,
• load condition,
• aisle mode or open-area mode,
• docking or precision approach state.

This is where the “dynamic” in dynamic safety zone becomes real. The protective envelope for a slow docking maneuver should not necessarily match the envelope for open-floor travel at full speed.

You write AMR speed clamping logic by evaluating the active LiDAR zone state, assigning a bounded speed reference for each valid condition, and forcing a zero-speed or stop path for any protective or faulted state.

The ladder logic should be readable enough that another engineer can audit it quickly. Safety-adjacent logic is not the place for ornamental cleverness.

### Step 1: Read and normalize the LiDAR inputs

Start by bringing the scanner or safety-controller status into named tags.

Example input tags:

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

At this stage, normalize contradictory states. If `Zone_Warning` and `Zone_Protective` are both active, the logic should resolve to the more restrictive state.

### Step 2: Create a single zone-state decision

Use internal bits or an integer state register to establish one authoritative motion condition.

Example state priority:

1. Fault or unhealthy scanner
2. Protective zone active
3. Warning zone active
4. Clear zone

Priority matters because motion logic should degrade safely under ambiguity.

### Step 3: Move the correct speed setpoint

Use bounded integer or real values to drive the AMR speed reference.

Illustrative ladder concept:

Language: Ladder Diagram

// Protective stop logic |---[/]-------------------------------[MOV]---|     LIDAR_Healthy                       0                                             AMR_Speed_Ref

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

// Warning zone speed clamp logic |---[ ]---[/]--------------------------[MOV]---|     Zone_Warning  Zone_Protective       15                                             AMR_Speed_Ref

// Clear zone normal speed |---[/]---[/]---[ ]--------------------[MOV]---|     Zone_Warning Zone_Protective AMR_Enable                                             100                                             AMR_Speed_Ref

This is intentionally simple. In a production architecture, you would often separate standard speed-reference logic from the safety-rated stop path and verify the interaction carefully.

### Step 4: Separate speed clamping from the protective stop path

A reduced speed command is not the same thing as a safety stop.

That distinction is easy to blur in a simulator and dangerous to blur on a real machine. A speed reference of zero issued over standard control logic is not automatically equivalent to a safety-rated stop function. Depending on architecture, the protective action may need to trigger Safe Torque Off, Safe Stop 1, or another validated safety function under IEC 62061 / IEC 61508-aligned design principles.

### Step 5: Add diagnostics and latching where justified

Diagnostics improve commissioning and fault isolation.

Useful additions include:

• scanner unhealthy alarm,
• invalid state alarm,
• field-overrun event logging,
• stop-cause register,
• manual reset requirement after protective stop, where risk assessment requires it.

A machine that stops without telling you why is only half-cooperative.

The correct stop behavior depends on the machine’s risk assessment, payload, dynamics, and validated safety function design.

A common misconception is that the fastest stop is always the safest stop. It is not. A Category 0 stop removes power immediately; on some AMRs, especially those carrying unstable loads or liquids, that can create secondary hazards through inertia, slosh, or loss of controlled braking.

When is warning-zone speed reduction appropriate?

Warning-zone reduction is appropriate when the goal is to lower kinetic energy before a protective stop becomes necessary.

Typical uses include:

• open-floor travel where pedestrian presence is plausible,
• long stopping distances at higher speed,
• environments with intermittent intrusion into outer detection fields,
• applications where controlled deceleration improves stability.

When is a protective stop required?

A protective stop is required when intrusion reaches the inner field or when the scanner or safety path can no longer guarantee safe motion.

That may result in:

• Safe Torque Off,
• a controlled stop followed by torque removal,
• motion inhibit plus reset sequence,
• or another validated safety response defined by the machine’s safety function.

The standard does not reward improvisation. It rewards proof.

You validate PLC LiDAR logic against a digital twin by comparing controller state, commanded speed, and simulated AMR motion under both normal and faulted conditions.

This is where OLLA Lab becomes operationally useful. Its browser-based ladder editor, simulation mode, variables panel, and 3D/WebXR scenarios allow engineers to test cause-and-effect without exposing people or hardware to the first draft of the logic.

What should you test first?

Start with the minimum deterministic cases:

• clear zone active, no warning or protective state,
• warning zone infringement at nominal speed,
• protective zone infringement at nominal speed,
• scanner fault,
• loss of healthy signal,
• contradictory zone-state input,
• reset and restart behavior after stop.

Use the variables panel to watch:

• active zone bits,
• `AMR_Speed_Ref`,
• drive enable state,
• stop-cause tag,
• alarm bits,
• any timer or debounce logic.

What does a valid digital twin test look like?

A valid test is not “the robot slowed down once.” It is a repeatable comparison between expected and observed behavior.

In OLLA Lab, that means you can:

• toggle or induce zone states,
• observe the ladder transition,
• inspect the speed-reference register,
• view the AMR response in the 3D scenario,
• repeat the test under the same conditions,
• and revise the logic when the machine response does not match the intended control philosophy.

That is the difference between animation and validation.

Why is live testing on a physical AMR a poor place to learn this?

Live testing is expensive, hazardous, and usually intolerant of exploratory mistakes.

A junior engineer should not need to discover, on a loaded vehicle in motion, that a warning-zone clamp was routed through a slow or non-deterministic path. OLLA Lab provides a bounded rehearsal environment for exactly that class of mistake: high consequence, common enough to matter, and difficult to practice safely on real equipment.

You should document a compact body of engineering evidence, not a screenshot gallery.

Use this structure:

Summarize the control insight, not just the outcome. For example: “warning-zone reduction over standard network control was functionally correct but too slow for this approach-speed case.”

1. System Description Define the AMR mode, scanner arrangement, field logic, drive interface, and relevant assumptions.
2. Operational definition of “correct” State exactly what must happen in clear, warning, protective, and fault states.
3. Ladder logic and simulated equipment state Capture the relevant rungs, tags, and corresponding AMR behavior in the simulator.
4. The injected fault case Record the abnormal condition introduced, such as scanner fault, stale warning bit, or delayed speed clamp.
5. The revision made Show what changed in the logic, sequencing, or signal path.
6. Lessons learned

This form of evidence is more useful than a polished dashboard image with no failure history. Commissioning memory is built from revisions, not cosmetics.

The primary standards and technical frameworks are functional safety and mobile robot safety, not generic robotics optimism.

The most relevant references include:

- ISO 3691-4:2020 for driverless industrial trucks and their systems,

• IEC 62061 for machinery functional safety,
• IEC 61508 as the foundational functional safety framework,
• manufacturer safety scanner manuals for field configuration and response behavior,
• and application-specific risk assessments that define required safety functions and stop behavior.

Academic and industry literature on digital twins and simulation-based validation is also relevant, but it should be used carefully. Simulation can improve rehearsal quality, fault visibility, and commissioning preparation; it does not replace formal safety validation on the real system.

OLLA Lab fits as a risk-contained validation and rehearsal environment for ladder logic, I/O behavior, digital twin observation, and commissioning-style troubleshooting.

Bounded correctly, that is a strong claim and a useful one. OLLA Lab lets engineers:

• build ladder logic in a web-based editor,
• run simulation without physical hardware,
• monitor tags and I/O in the variables panel,
• work through AMR-like scenarios in 3D/WebXR environments,
• and test how control logic maps to machine behavior before site exposure.

It does not certify a safety function, replace a formal risk assessment, or make a live AMR safe by association. A simulator is a rehearsal room, not a compliance stamp.

Programming a virtual safety fence is a control problem with safety consequences. The core task is to map LiDAR field states to deterministic machine responses, then verify that the AMR actually slows or stops as intended under normal and faulted conditions.

The durable distinction is simple: sensor presence versus validated response path. Many integration problems live in that gap.

A useful engineer in this domain is not merely fluent in ladder syntax. A useful engineer can define correct behavior, test it against simulated equipment, inject faults, revise the logic, and explain why the final control path is safer than the first draft.

- ISO 3691-4 driverless industrial trucks safety requirements - IEC 62061 functional safety of machinery control systems - IEC 61508 Functional safety overview - Digital Twin in Manufacturing review (IFAC-PapersOnLine) - Cyber-Physical Systems in Industry 4.0 (AQTR)