Inject One Failure on Purpose and Prove the Evidence Process Can Catch It

A system review that only observes healthy behavior can miss whether the evidence process is capable of detecting a defect.

A controlled failure injection deliberately introduces one bounded problem so you can observe detection, diagnosis, repair, and recovery evidence.

The failure must be safe, reversible, and tied to one named requirement.

Do not create unsafe physical robot failures for this capstone.

Choose from failures already taught

You may use one of these course cases:

Java boundary defect

Change:

rangeMeters < cautionDistanceMeters

to:

rangeMeters <= cautionDistanceMeters

Expected detector:

exact-boundary JUnit test at 0.50 m

Invalid range update

Attempt:

3.70 m

against a component whose allowed interval is:

0.10..2.00 m

Expected evidence:

exception/rejection
last valid state preserved

ROS QoS mismatch

Request:

RELIABLE

from the Week 12 inspection subscription while the supplied publisher offers:

BEST_EFFORT

Expected detector:

QoS incompatibility evidence

Unsourced overlay

Open a fresh shell and omit:

source ~/robot_ws/install/setup.bash

Expected detector:

ros2 pkg prefix robotnix_bringup

Stale installed launch resource

Edit the source launch default and intentionally skip the rebuild.

Expected detector:

source default differs from launched installed behavior

One-sided remapping

Remap the talker but not the listener.

Expected detector:

publisher/subscriber relationships appear on different topic names

Write the hypothesis before injecting the failure

Do not break something and then invent the purpose afterward.

Use this structure:

Requirement:
Expected healthy behavior:
Injected defect:
Expected detector:
Expected failure evidence:
Repair:
Recovery criterion:

For example:

Requirement:
The obstacle guard stops only when range < 0.50 m.

Injected defect:
Change < to <=.

Expected detector:
JUnit exact-boundary test at 0.50 m.

Expected failure:
Test expects false but receives true.

Repair:
Restore strict < comparison.

Recovery criterion:
Boundary test and full selected suite pass again.

Now the experiment has a reason.

Detection and diagnosis are different

A failing test can detect that behavior is wrong.

It does not automatically tell you why.

For the boundary defect, the failing exact-boundary case narrows the problem to the comparison behavior. Reading the implementation then identifies <= as the defect.

For a QoS mismatch, an incompatible reliability warning narrows the problem to endpoint policy compatibility. It does not prove every other communication layer is healthy.

Write both steps separately.

Recovery evidence should match the original acceptance criterion

After repair, rerun the same evidence that detected the failure.

Do not replace the failing test with an easier test.

If the defect was:

RELIABLE subscriber incompatible with BEST_EFFORT publisher

then the repair record should show the intentionally compatible subscription and the expected message evidence.

If the defect was stale launch installation, rebuild and verify the installed runtime now matches the source change.

The recovery criterion should close the same claim that failed.

Preserve the failure artifact

Do not erase the failing screenshot, test output, or CLI record after repair.

Your capstone should show:

healthy expectation
failure injection
failure evidence
diagnosis
repair
recovery evidence

That sequence demonstrates the evidence system is meaningful.

Do not inject multiple failures at once

If you simultaneously:

• break the QoS profile;
• unsource the overlay;
• edit the launch remap;

then a failure tells you very little.

A controlled experiment changes one intended variable while keeping the rest of the case stable.

That makes the diagnosis defensible.

Physical failure injection requires a different safety process

Do not disconnect motors, defeat interlocks, create collisions, or force unsafe battery/sensor states for this course capstone.

Physical fault injection can be legitimate engineering work when proper hardware safety procedures, supervision, and test fixtures exist.

That is outside the required course path.

Use software/simulation/supplied evidence instead.

Worked failure injection: stale overlay

Requirement

robotnix_bringup must resolve from ~/robot_ws in a clean-shell startup.

Injected defect

Open a new terminal and source only:

source /opt/ros/jazzy/setup.bash

Detector

ros2 pkg prefix robotnix_bringup

Failure evidence

Package not found

Diagnosis

Build evidence exists, but the workspace overlay is not sourced in this shell.

Repair

source ~/robot_ws/install/setup.bash

Recovery evidence

ros2 pkg prefix robotnix_bringup

resolves the expected workspace prefix.

Nothing needed to be rebuilt.

Your turn

Choose one failure injection.

Before executing or analyzing it, complete the seven-line experiment definition:

Requirement
Healthy behavior
Injected defect
Expected detector
Expected failure evidence
Repair
Recovery criterion

Then execute it locally if safe/available, or use the course's deterministic/supplied failure evidence.

Preserve both the failed and repaired states.

In the next lesson, you will decide whether the evidence is strong enough to mark each readiness claim as pass, conditional pass, blocked, or not demonstrated.