Humanoid robots are entering real work environments now. Figure.ai has deployed systems in production. Amazon’s humanoid programs are progressing. The regulatory and standards frameworks are still catching up.
That gap — systems in deployment, standards still developing — creates a specific engineering challenge. Teams building humanoid robots need to implement functional safety without a purpose-built standard to follow. They’re applying existing frameworks (IEC 61508, ISO 12100, ISO 13849) to system architectures and interaction scenarios those frameworks were never designed to address.
The teams doing this well aren’t waiting for the standard to arrive. They’re building rigorous functional safety programs now, documenting their methodology, and creating the record that will support certification when the standards mature.
| Humanoid robot characteristic | Functional safety implication |
|---|---|
| Bipedal locomotion with dynamic balance | Novel failure modes — loss of balance, fall recovery failure, uncontrolled forward momentum |
| Whole-body manipulation | Large reach envelope, multiple simultaneous contact points with people and objects |
| Unstructured environment operation | Open-world scenarios: cannot enumerate all hazards at design time |
| High-force actuators | Significant kinetic energy, injury potential from unintended contact |
| Complex perception and decision-making | Software-intensive safety: IEC 61508 Part 3 scope, extensive testing requirements |
| Close proximity to humans | Continuous collaborative scenarios without fixed guarding |
What existing standards cover — and what they don’t
The most relevant existing standards for humanoid robot functional safety are:
IEC 61508 covers functional safety of electrical, electronic, and programmable electronic systems. It’s the foundational framework for any system where software controls safety-critical functions. It applies directly to the sensors, actuators, and controllers in a humanoid robot’s safety architecture. What it doesn’t provide is guidance specific to locomotion failures, unstructured environment operation, or whole-body dynamics.
ISO 12100 provides the general principles of machinery risk assessment. It’s the correct starting point for systematic hazard analysis. Its methodology works for humanoid robots, but teams need to extend it significantly to cover bipedal dynamics and open-world interaction scenarios.
ISO 13849 and IEC 62061 apply to specific safety functions within the robot’s control system — safe stop, torque limiting, collaborative force monitoring. They don’t address the system-level safety architecture of a mobile bipedal system.
ISO/TS 15066 addresses collaborative robot safety, particularly human-robot contact forces. It’s relevant for the collaborative interaction scenarios humanoid robots are being designed for, even though it was written with stationary cobots in mind.
The gap is at the system integration level. How do you argue that a humanoid robot with complex locomotion, full-body manipulation, and unstructured environment operation is sufficiently safe? That argument can be constructed using existing frameworks, but it requires significant work to apply them to scenarios they weren’t designed for.
The hazard analysis challenge
For a fixed robot arm in a cell, the hazard analysis is bounded: defined workspace, defined interaction points, enumerable failure modes. For a humanoid robot, the operating envelope is open and the interaction scenarios are unbounded.
The practical approach that leading teams are taking:
Enumerate failure modes by subsystem, not by scenario. Rather than trying to list every possible scenario, analyze failure modes for each subsystem: locomotion control failure, perception failure, manipulation control failure, communication failure. For each failure mode, assess the worst-case consequence based on the operating context (close proximity to humans, load in hand, elevated position, etc.).
Define the operating envelope by interaction mode. Separate safety analysis for different operating contexts: autonomous operation in a defined zone, supervised operation with a human nearby, collaborative manipulation where physical contact with a human is expected. Each mode has different hazard profiles and different acceptable risk levels.
Apply precautionary risk assessment where outcomes are severe and scenarios are novel. For failure modes with catastrophic consequence potential and limited analogous historical data, apply conservative assumptions. Document the conservatism explicitly. As operational data accumulates, the analysis can be refined.
Build the safety argument around what can be demonstrated. Physical testing, simulation-based validation, software safety analysis, and operational monitoring all contribute to a safety case. The argument doesn’t have to be complete at launch — it has to be defensible and supported by ongoing evidence.
What the safety architecture looks like
Humanoid robot safety architectures being developed by leading teams share common structural elements, even where the specific implementations differ.
Independent safety monitoring subsystem. A separate, safety-rated controller monitors the system state and can command a safe stop independently of the main control system. This addresses the dual-channel requirement for SIL 2 or SIL 3 safety functions: the safety function doesn’t depend solely on the software that could be causing the fault.
Safe stop hierarchy. Multiple levels of deceleration and stopping, triggered by different input conditions: collaborative mode transitions, proximity to defined zones, operator command, fault detection, unexpected contact. Each level has a defined response time and deceleration profile derived from worst-case kinetic energy calculations.
Whole-body torque and force monitoring. For collaborative scenarios, monitoring joint torques and external forces allows detection of unexpected contact before it becomes injurious. This is an extension of the force-limiting concepts in ISO/TS 15066, applied to whole-body dynamics.
Perimeter and proximity sensing with safety-rated latency. The detection-to-stop latency has to be short enough that an approaching person can’t cross from outside the detection zone to inside the collision zone faster than the robot can stop. This calculation drives the sensing range and the deceleration capability requirements.
Fennec Engineering has worked with Figure.ai and Amazon’s humanoid robotics programs to apply the ASAP methodology to humanoid robot safety. The platform’s pre-configured templates and guided workflows provide a starting framework that teams extend for their specific architecture, rather than starting from a blank page. Teams building functional safety for AMRs will recognize many of these structural patterns — the principles transfer, though the locomotion complexity introduces new dimensions of analysis.
FAQ: Functional Safety for Humanoid Robots
What functional safety standards apply to humanoid robots?
No single standard was specifically written for humanoid robots. The most applicable frameworks are IEC 61508 for the safety integrity of the electronic and software systems, ISO 12100 for systematic hazard analysis, and ISO/TS 15066 for collaborative interaction scenarios. Teams are applying these frameworks to humanoid systems and documenting their methodology carefully, building the evidentiary basis for certification as the specific standards develop.
What makes functional safety for humanoid robots different from cobot safety?
Cobots operate with a fixed base and defined workspace. Humanoid robots are mobile bipedal systems that operate in unstructured environments with unbounded interaction scenarios. The hazard analysis for a humanoid can’t enumerate specific scenarios — it needs to analyze failure modes by subsystem and reason about consequences across a range of operating contexts. The locomotion failure modes (loss of balance, uncontrolled fall) have no direct analog in stationary cobot safety.
Is there a specific SIL requirement for humanoid robot safety functions?
The required SIL for specific safety functions is derived from the hazard and risk assessment, not assigned by default. For safety functions that control close-proximity interaction with people (force limiting, safe stop in collaborative mode), SIL 2 or SIL 3 requirements are common given the severity potential and continuous exposure characteristics of these operations.
How do leading teams approach safety certification before humanoid-specific standards exist?
The consistent approach is to apply existing frameworks rigorously, document the methodology explicitly, and build a safety case based on what can be demonstrated rather than waiting for a purpose-built standard. IEC 61508, ISO 12100, and ISO/TS 15066 provide the methodological foundation. The gap is at the system integration level, which is addressed through engineering judgment documented in the safety argument.
What is Figure.ai’s approach to humanoid robot safety?
Figure.ai is among the organizations contributing to the development of functional safety practices for humanoid robots. Fennec Engineering has worked with Figure.ai’s teams, applying the ASAP methodology to humanoid robot safety programs. The specific details of Figure.ai’s safety approach are proprietary, but the general pattern — applying existing IEC 61508 and ISO 12100 frameworks with careful documentation of how they’re extended for humanoid-specific scenarios — is representative of the field’s leading practice.
This post covers general functional safety engineering principles and is for educational purposes only. It is not engineering advice. Consult a qualified functional safety professional and your applicable standards body before making safety-critical design decisions.
Fennec Engineering has worked with Figure.ai and Amazon’s humanoid robotics programs. If you’re building a humanoid robot safety program and want to understand what a rigorous approach looks like, let’s talk.