Functional safety

Functional safety – definition

Functional safety is the part of overall system safety that depends on a system responding correctly to inputs, detected faults, and defined hazardous conditions. In mobile robotics, it concerns safety functions that reduce risk when a UGV loses communication, detects an emergency stop request, exceeds a permitted speed, reports a critical battery condition, or encounters a fault in propulsion, sensing, or control.

Functional safety is not a general synonym for “safe robot operation.” It does not replace mechanical stability analysis, electrical protection, electromagnetic compatibility testing, risk assessment, operator training, or site procedures. It specifically addresses whether safety-related control functions achieve the required risk reduction with defined reliability and fault behaviour.

For a Leo Rover or Raph Rover integration, a safety function may include a hardware emergency stop circuit that removes traction power, a monitored enable circuit, a speed limit in a defined operating mode, or a fail-safe stop when a control link is lost. The required functions depend on the application risk assessment, payload, speed, terrain, operating area, and human access to the robot.

Functional safety standards relevant to mobile UGVs

Functional safety is normally developed from a documented hazard and risk assessment. ISO 12100:2010 defines principles for risk assessment and risk reduction for machinery. IEC 61508 is the generic functional safety standard for electrical, electronic, and programmable electronic safety-related systems.

The following standards are commonly relevant when defining safety-related functions for a mobile robot or its payload. Their applicability must be determined for the specific machine, jurisdiction, and intended use.

Standard	Scope	Relevant concept
IEC 61508-1:2010	Generic E/E/PE functional safety	Safety Integrity Level (SIL), safety lifecycle
ISO 12100:2010	Machinery risk assessment and risk reduction	Hazard identification, protective measures, residual risk
ISO 13849-1:2023	Safety-related parts of machinery control systems	Performance Level (PL), Categories, MTTF_d, DC, CCF
ISO 13849-2:2012	Validation of safety-related parts of machinery control systems	Validation by analysis and testing
IEC 62061:2021	Safety-related control systems of machinery	SIL for machinery safety functions; SIL claim limit (SILCL) for subsystems
ISO 25119 series	Safety-related control systems for agricultural and forestry machinery	AgPL and application-specific agricultural machinery requirements

ISO 13849 uses Performance Levels from PL a to PL e. IEC 61508 uses SIL 1 to SIL 4. These scales are not interchangeable without a justified engineering analysis. A project should not assign “SIL-rated” or “PL-rated” status to a ROS node, LiDAR, camera, or rover platform unless the complete safety function has been assessed against the applicable standard.

Safety functions on a mobile robot

A safety function has a defined input, logic, output, safe state, response time, diagnostic coverage, and fault reaction. On a differential-drive UGV, the safe state is commonly a controlled stop or removal of motor torque. The correct choice depends on braking behaviour, slope, payload inertia, and the risk of uncontrolled rolling.

Typical functions in a mobile robotics integration include:

Emergency stop – operator-initiated transition to a defined safe state.
Protective stop – stopping motion after a protective device or monitored zone is triggered.
Communication-loss stop – stopping after a command heartbeat or safety channel timeout.
Overspeed limitation – preventing wheel speed or vehicle velocity above a validated limit.
Motion enable – allowing traction only when defined prerequisites are valid.
Battery fault response – disabling or limiting motion after a critical power-system condition.

Stopping distance must include sensing, communication, logic, actuator, and mechanical braking delays. A simplified model is:

d_stop = v × t_response + v² / (2 × a_deceleration)

Here, v is initial ground speed, t_response is total safety-function response time, and a_deceleration is verified deceleration magnitude. This model must be validated on the actual surface, tyre condition, payload mass, and slope. A simulation-only result is not sufficient for safety validation.

ROS 2 and the safety boundary

ROS 2 is useful for non-safety control, perception, navigation, logging, and supervision. A ROS 2 navigation stack can publish velocity commands such as geometry_msgs/msg/Twist on /cmd_vel, while odometry may be published as nav_msgs/msg/Odometry. These interfaces alone do not create a safety-rated control function.

ROS 2 uses DDS middleware and supports mechanisms such as Quality of Service policies, lifecycle nodes, managed parameters, and DDS-Security. These mechanisms improve system design and operational robustness, but ROS 2 distributions are not generally delivered as certified functional safety platforms. The ROS 2 package quality model defined by REP-2004 describes package quality practices, not functional safety certification.

A practical architecture separates the safety path from the autonomy path. The autonomy computer can request motion, but an independent safety controller or certified drive interface remains able to inhibit torque or stop propulsion when a safety condition occurs.

# Example conceptual safety interface configuration
safety_supervisor:
  command_timeout_ms: 250
  maximum_linear_velocity_mps: 0.4
  maximum_angular_velocity_radps: 0.8
  safe_state: "traction_disabled"
  required_inputs:
    - emergency_stop_loop
    - motor_controller_fault
    - communication_heartbeat

The values above are example engineering parameters, not Leo Rover or Raph Rover specifications. They must be derived from the application risk assessment and validated on the integrated robot.

Leo Rover and Raph Rover integration context

Leo Rover is a four-wheel, differential-drive mobile platform with onboard Raspberry Pi compute running LeoOS and ROS 2. It can run navigation, perception, teleoperation, and supervisory software, but it is not an autonomous vehicle out of the box. Integrators must add and validate the required sensing, navigation stack, operating limits, and safety functions.

For Leo Rover, a common engineering separation is to run ROS 2 nodes on the onboard computer while keeping emergency-stop and motor-inhibit paths independent of normal application processes. A LiDAR-based obstacle detector may command zero velocity, but a safety claim requires evidence that the sensor, processing path, output interface, timing, diagnostic behaviour, and final drive response meet the selected safety requirement.

Raph Rover supports projects requiring higher payload capacity. This can increase kinetic energy and stopping distance, making verified braking performance, centre-of-mass analysis, cable retention, payload restraint, and emergency-stop placement more important. Raph Rover does not replace Leo Rover in laboratory or educational work where a smaller platform is more appropriate.

Verification, validation, and documentation

Functional safety requires traceable evidence. A test that shows a robot stopped once is not enough. The engineering record should connect each hazard to a safety requirement, implementation, verification method, and acceptance criterion.

Useful project artefacts include:

Hazard analysis and risk assessment with operating assumptions.
Safety requirements specification for every safety function.
System architecture showing the safety boundary and independent channels.
Failure mode and diagnostic analysis for sensors, controllers, power, and actuators.
Measured response-time and stopping-distance test reports.
Configuration control for firmware, ROS 2 packages, parameters, and wiring revisions.

Normative references and standards

Primary references include IEC 61508-1:2010, ISO 12100:2010, ISO 13849-1:2023, ISO 13849-2:2012, and IEC 62061:2021. For ROS 2 software quality expectations, see ROS REP-2004. ROS 2 interface definitions and middleware documentation are available through docs.ros.org.