The fault-injection campaign

Dataset: sbw_ch2/dataset/ · 384 runs · 1,920 source files · Acceptance spec: acceptance_spec_sheet.csv (11 metrics)

Executive summary

The campaign exercises a dual-channel steer-by-wire system with 324 single-point fault injections, 48 commanded A→B handover runs, and 12 fault-free golden baselines. The 11-metric acceptance verdict is 5 PASS / 6 FAIL:

• Coverage falls short of the 99% gate at 93.21% pooled. Two fault types drive the shortfall: motor_driver_open (50%) and mild angle_sensor_bias (88.9%).
• FTTI compliance is clean on the self-steer hazard at every operating point, but incorrect-steer and handover-omission hazards both miss the 150 ms gate. Incorrect-steer breaches come from the 12 mild torque_sensor_drift runs (210–230 ms) and the four undetected mild angle_sensor_bias runs.
• Handover RWA deviation fails on 18 of 48 runs, clustered in severe motor_driver_short residual carry-over (up to 8.807 deg) and a park + severe omission cluster at ~3.3 deg.
• The eotti bounded-window metric is informational: every detected run completes handover inside an observable degraded window of 1.17–3.49 s, well below the 5 s budget.
• False positives: PASS – zero DTC latches across all 12 golden runs on 18 monitors across both ECUs.

Dataset

The run matrix from operator_log.xlsx: 324 single-point + 48 handover + 12 golden = 384. Single-point runs span nine fault types × three magnitudes (mild / moderate / severe) × three operating points (park / urban / hs) × 2 channels (ECUA / ECUB) × 2 repeats = 324.

Operator log flags two truncated runs (inj_077, inj_244); these are processed on their available samples and their detection signatures recover normally inside the truncated window.

Each run carries five synchronised sources: rig DAQ at 1 kHz (master clock), ECU-A and ECU-B at 100 Hz, steering robot at 100 Hz, ambient sensors at 1 Hz. Clock alignment uses MDF header timestamps relative to the rig master. Robot angles convert from radians to degrees; rack position in millimetres maps to road-wheel angle. ECU-B channel names reconcile to the shared schema (theta_cmd → HwaCmd_B, and so on).

Methodology

Every run goes through ingest, harmonisation, event extraction, and gate scoring.

Per-run event extraction

A run passes the timing gate if total_ms < governing_ftti_ms. Undetected runs count as a timing failure.

Processing runs in parallel via ProcessPoolExecutor (8 workers). All 384 runs complete in ~400 s. No runs failed to harmonise.

Coverage

Pooled single-point coverage: 93.21% (302 / 324). The 99% gate fails on two fault types.

motor_driver_open – standby-channel blindness

All 18 ECU-A-injected runs detect; all 18 ECU-B-injected runs miss. Coverage: 50.00%. The pattern is fully consistent with hot-standby behaviour: the standby motor carries no current, so an open-circuit monitor that relies on current/voltage residuals has no signal to detect.

angle_sensor_bias – mild-magnitude borderline

Coverage: 88.89% (32 / 36). The four misses are all mild magnitude (two at urban, two at park). All moderate and severe runs detect. This is a sensitivity boundary, not a protocol error.

Every other fault type reaches 100% coverage.

FTTI compliance

Self-steer hazard (commission faults) – PASS

All motor_driver_short, cross_channel_signal_freeze, and can_corruption runs detect inside their operating-point budget.

Incorrect-steer hazard – FAIL (16/72 breach)

All 12 mild torque_sensor_drift runs sit at 210–230 ms, well above the 150 ms gate. Moderate (110–130 ms) and severe (70–80 ms) sit cleanly below. This is magnitude-dependent monitor sensitivity. The four undetected mild angle_sensor_bias runs also count here – an undetected fault is, by construction, a gate breach.

Handover-omission hazard – FAIL (18/144 breach)

All 18 breaches are ECU-B-injected motor_driver_open runs that the standby-channel monitor cannot see. This is the coverage gap from §4.1 showing up in the timing gate.

Most other fault types resolve in 10–50 ms with low scatter. torque_sensor_drift is the outlier, with mean ~141 ms driven by the magnitude-dependent latency ladder (severe ~77 ms, moderate ~125 ms, mild ~221 ms).

Handover quality (RWA deviation)

30 / 48 runs sit at ~0.03 deg steady-state RWA deviation, well inside the 1.0 deg gate. 18 / 48 fail, and the failure population splits into three groups:

• Severe motor driver short – 6 runs: mean deviation ~5.4 deg at high-speed/urban and ~8.7 deg at park. The fault residual carries forward into B's tracking. Maximum deviation: 8.807 deg.
• Park + severe omission faults – 6 runs across motor_driver_open, channel_supply_dropout, and can_timeout. Tight cluster at ~3.2–3.4 deg, indistinguishable across the three fault types. Mechanism looks like a B-channel calibration/gain offset that only becomes observable post-handover under high-current conditions.
• Moderate motor driver short – 6 runs: ~3.40–3.46 deg across all operating points.

False-positive check

All 12 golden runs: 0 DTC latches across 18 monitors on both ECUs. false_positive_rate PASSes.

Data quality

• All 384 runs harmonised without error; no source missing.
• Truncated runs inj_077 and inj_244 processed on available samples; detection and handover signatures recovered inside the truncated window.

Acceptance verdict

Overall: 5 PASS / 6 FAIL. The campaign does not meet acceptance. Failures fall into three localised mechanisms:

1. Standby-channel blindness for motor_driver_open drives both the coverage shortfall and the handover-omission FTTI breach.
2. Mild torque_sensor_drift exceeds the incorrect-steer 150 ms gate at all three operating points (12 / 12 mild runs).
3. A park + severe operating regime exposes a steady-state B-channel gain/calibration offset of ~3.3 deg on three different omission-fault types, and a larger residual carry-over (up to 8.81 deg) for severe motor_driver_short.

Per-run feature table published (384 rows). Coverage CSV and verdict CSV in the workspace artifacts folder.

All data in this series is synthetic, generated to mirror a real steer-by-wire validation program. No customer data is used.

Next in the series: the regression run. If comparing 384 runs before and after a fix still happens in spreadsheets, we would like to talk: founders@movedot.com, or www.movedot.ai.