🛡️ Safety and Standards: ISO 10218:2025
Safety-by-design and the standards governing human-robot collaboration. The safety envelope within which any VLA in production must operate — from legal compliance to technical guardrails.
Illustrative diagram — the VLA robot operates within multiple independent layers of protection.
📋 ISO 10218:2025: the industrial robot standard
A ISO 10218:2025 is the international standard that defines safety requirements for industrial robots and their integrations. The 2025 revision unified parts 1 (robot) and 2 (system/cell) and explicitly incorporated collaborative operation—the legal envelope every VLA in production must respect.
📌 What the standard covers
- Part 1Project and safety requirements for the robot itself — mechanical structure, actuators, stop functions.
- Part 2Requirements for system integration — cell, peripherals, human-robot interface, facility risk analysis.
- 2025Edition that aligned the standard with cobots and VLAs: continuous collaborative operation is explicitly included in the scope.
✓ Compliant system
- ✓Protective stop functions implemented
- ✓Performance level (PL) assessed under ISO 13849
- ✓Documented risk analysis before deployment
- ✓Safety envelope defined for the VLA
✗ Common violations
- ✗Deployment without formal risk analysis
- ✗Safety functions dependent on VLA software
- ✗Collaborative operation without integrator certification
- ✗Ignore Part 2 because you "only use the ready-made robot"
Key concepts
Reliability metric for safety functions (PLa–PLe), calculated according to ISO 13849.
Safe, controlled interruption of movement without losing the system state.
Robot + peripherals + human-robot interface as a complete system to be certified.
⚖️ ISO/TS 15066: Force and Pressure Limits
A ISO/TS 15066 complements ISO 10218 with a focus on collaborative robotics: it defines the biomechanical limits of force and pressure by region of the human body, ensuring that robot-human contact doesn’t cause injury. For a VLA that controls a cobot, these limits directly constrain the maximum speed and force of its emitted actions.
⚠️ Warning: biomechanical limits are not suggestions
The force and pressure values in TS 15066 are derived from studies on pain tolerance and tissue injury. Exceeding them—even for fractions of a second—can cause bruises, fractures, or internal injuries. No productivity argument justifies operating outside these limits.
📊 Four defined collaboration modes
💡 Practical implications for VLAs
If the VLA operates in PFL mode, every action emitted by the model must be intercepted by a deterministic safety controller that checks speed and force before sending commands to the actuator. The model should never have direct access to the low-level control bus.
🏗️ Safety-by-design for VLA
The philosophy of embedding safety from the outset of the system — not as a later patch. For VLAs, this means designing the architecture, action space, and model constraints so that dangerous behaviors are structurally difficult or impossible, regardless of what the model "decides" to do.
Illustrative diagram — the safety controller is independent of the VLA software; model failure does not bypass protection.
✓ Proper safety-by-design
- ✓Action clamping before any execution
- ✓Model-independent safety controller
- ✓Hardware-defined safe state, not software-defined
- ✓Defense in depth: multiple redundant barriers
✗ Dangerous anti-patterns
- ✗Trusting that the model “learned to be safe”
- ✗Safety controller implemented in Python/ROS
- ✗Direct access to the low-level bus
- ✗Safety added as a feature at the end of the project
💡 Fundamental principle
VLAs are probabilistic generative models — they can generate actions outside the training distribution. No benchmark evaluation guarantees safe behavior in every scenario. Safety-by-design is the only responsible response to this structural unpredictability.
🚨 Emergency Stop and Zones: SSM and PFL
The physical and logical mechanisms that stop or modulate a robot’s movement in the presence of humans. They are the last-resort safeguards — work independently of what the VLA decides to do and cannot be disabled by AI software.
Emergency stop—Category 0 and 1
Cat. 0: immediate power cutoff (emergency stop). Cat. 1: controlled deceleration before power cutoff. Both are independent of the control software and must be triggerable by physical hardware.
Speed-and-Separation Monitoring
Continuously monitors the distance between humans and robots using sensors (3D cameras, LiDAR). As a person approaches, it proportionally reduces speed. Stops completely before any contact. Ideal for cells with no intentional contact.
Power-and-Force Limiting
Allows intentional contact while ensuring that force and pressure stay within the biomechanical limits of ISO/TS 15066. Requires force/torque sensors on the robot and a certified safety controller. This is the mode that enables cobots to work side by side with humans.
Configurable safety zones
Virtual zones around the robot with different behaviors: warning zone (slows down), protective zone (stops), collaboration zone (PFL). Configured in the safety controller, not the VLA. The model operates within the envelope; the zones enforce it.
💡 Where the VLA ends and the safety controller begins
The VLA generates commands for high level (move to position X at speed Y). The safety controller intercepts these commands, checks whether they fall within the configured zones and limits, and only then sends them to the joint controller. A model failure or hallucination never reaches the actuator without passing this check.
🔍 Risk analysis and mitigation
The systematic process of identifying potential hazards in a robotic system, estimating the severity and likelihood of each, and defining measures to reduce them to acceptable levels. It is a step required by regulations before any deploy — and for systems with VLA, it needs to account for the model's unpredictability.
Mitigation hierarchy (priority order)
HAZOP — Hazard and Operability
A structured analysis that systematically asks: "what happens if this variable (speed, position, force) is higher/lower/zero/inverse of what was expected?" Very effective for uncovering failure scenarios the team did not anticipate.
FMEA — Failure Mode and Effects Analysis
Tables every possible failure mode (hardware, software, VLA) by severity, probability, and detectability (RPN). Defines a mitigation action for each failure. Required for systems that need certification.
⚠️ VLA-specific dangers — beyond the hardware
- •Action hallucination — model generates a physically valid but semantically incorrect command (grabs the wrong tool, moves in the wrong direction)
- •Distribution shift — a scene outside the training distribution leads to unpredictable behavior
- •Inference latency — VLA too slow to react to scene changes in real time
- •Silent failure — the model produces high-confidence output in a scenario it cannot solve
🔒 Guardrails, fail-safes, and VLA validation
The set of safeguards specific to generative models in physical control: guardrails that filter unsafe actions, fail-safe behaviors that bring the robot to a safe state in case of failure, and the processes of verification and validation (V&V) that prove the system works before it goes into production.
✓ Deployable VLA
- ✓Guardrails validate actions before execution
- ✓Fail-safe defined: stop and gently release the load
- ✓Runtime monitoring detects anomalies in production
- ✓V&V in simulation + real robot with >1000 episodes
✗ Experimental VLA (do not deploy)
- ✗Validation in simulation only
- ✗No defined behavior for inference failures
- ✗Guardrails as a README comment, not as code
- ✗"We tested it on benchmarks" as the only criterion
Key V&V concepts for VLAs
Continuously monitors operational metrics (force, speed, trajectory) and triggers alerts or stops when they fall outside the expected range.
Success and failure rates at scale (>1000 episodes), including adversarial scenarios and planned edge cases.
Default safe state: if inference fails, lock the joints or return to the initial position. Defined by hardware, not Python code.
Each action is checked against a set of constraints before reaching the controller: position outside the workspace, speed above the limit, force above TS 15066.
💡 The boundary between experimental and deployable
A VLA is deployable when its guardrails, fail-safes, and V&V evidence are documented and reviewed by someone outside the team that developed the model. Self-validation does not count toward safety. Independent review is part of the process—not bureaucracy.
✅ Module Summary
Next track
Learning Path 2 — Technical: VLA architectures, training, fine-tuning, and deployment in depth.