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.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.
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: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.