Skip to main content

Fault injection

Functional tests prove the robot works. Fault tests prove it fails safely. Both are required by every safety standard you’ll certify against (ISO 13849, IEC 61508, EU MR 2023/1230 Annex III). Roboticks ships four fault-injection primitives that operate over the rclpy DDS layer without modifying the system under test.
Fault injection runs between rclpy and the node — it manipulates the DDS layer for the test process. It does not require root, does not need a custom DDS vendor, and does not patch your node.

The four primitives

All four are context managers. The fault is scoped to the with block. On exit, the original behaviour is restored, even if the test asserts inside the block.
Full signatures in SDK fault injection reference.

When to use injection vs. mocks

Rule of thumb: mock until the node is built; inject once it’s running. Roboticks’s evidence pack tags fault-injection tests separately so the auditor sees them without you having to label by hand.

Example: E-stop survives comms loss

The safety requirement is “E-stop functions even if the supervisor’s heartbeat is lost.” A passing test asserts the robot enters a safe stop state when /supervisor/heartbeat stops arriving.

Example: navigation handles a slow LIDAR

Example: watchdog restarts a dead planner

Example: sensor corruption

Stacking faults

Context managers nest:
The DDS interceptor multiplexes both faults. Order is irrelevant; the per-topic state is isolated.

What surfaces in the evidence pack

Fault-injection tests get a dedicated section in the evidence pack PDF: requirement → fault primitive → topic → result. Auditors quote that section verbatim when defending the safety case.

Next

Fault injection reference

Full signatures, rate semantics, lifecycle interaction.

MCAP capture

Pair fault injection with bag-recording for failure forensics.

Launch testing

Inject faults across a multi-node graph.

Standards mapping

Which standards require which kind of fault test.