The Specification

As handed to students.

guardian v0.1: forward collision warning arbiter

In the decomposed architecture from the safety page, the track stream below is the radar channel’s input, and this arbiter is that channel’s B(D) decision element.

Input

The starter repo provides sensor-sim, which produces a stream of TrackReports at 20 Hz for scripted scenarios (constant-speed lead vehicle, hard-braking lead, cut-in, empty road). Two perception channels observe the same world: each report carries a sensor field, radar or camera. Reports carry an object id, range (m), range rate (m/s), and a confidence in [0, 1]. Reports are noisy, and the channels differ: radar’s range rate is precise, the camera’s is much noisier; each channel drops tracks for 1 to 3 cycles on its own schedule; and each channel produces its own spurious low-confidence ghosts. A cycle may carry reports from both channels, one, or neither. Your arbiter consumes the merged stream and owns the decision.

Behavior

Each cycle, guardian ingests the current reports and emits exactly one Decision:

• Brake when collision is imminent (time-to-collision below a hard threshold).
• Warn when a collision is plausible soon (time to collision, TTC, below a soft threshold).
• NoAction otherwise.

TTC for a closing track is range / closing_speed. Tracks with confidence below 0.3 must not, on their own, trigger Brake.

Acceptance targets (per scenario suite, over many runs)

Classification semantics, shared by every evaluator of this table: “ending in Brake” means Brake appears within the final 20 cycles (one second) of the run. Latency medians are computed over responders only; a run that never reaches the required decision is a miss, which lowers the corresponding rate row and contributes no latency sample. Zero responders reports n/a. Latency output states its response coverage (responders over total runs) alongside the median.

Deliverables

The guardian crate; a reviewed use of the prepared runner; one deterministic example test; at least two properties; measured before/after behavior; and a compact safety case in SAFETY-NOTES.md.

The prepared runner owns trial loops, replay commands, noiseless truth crossings, response coverage, medians, and chatter diagnostics. Its metric semantics are reviewable course code, not an oracle. If you disagree with a semantic, write the claim you need and amend the harness explicitly.

End of spec.

Protocol alignment (stretch)

Real FCW systems are tested against published protocols. Two matter here, and they’re different kinds of document. Euro NCAP’s AEB Car-to-Car protocol is a consumer rating: it scripts rear-end test scenarios and awards FCW points when the warning comes at TTC >= 1.70 s.¹ FMVSS No. 127 is a US regulation: it requires FCW between 10 and 145 km/h whenever a collision is imminent, and full avoidance of a lead vehicle at speeds up to 62 mph, on new light vehicles from September 2029.²

The protocol’s CCRb scenario is close to this project’s world: two vehicles at 50 km/h, then the lead brakes at -2 or -6 m/s^2, from a headway of 12 or 40 m. Four cells.

The sim gives you the mechanism and nothing more: Scenario::Scripted(ScriptedLead { .. }) takes an initial range, an initial closing speed, a start time, a closing acceleration, and a closing-speed cap. Building the four CCRb cells out of it is your agent’s work, under your review:

1. Ask the agent to translate the protocol cells into ScriptedLead values. Review the unit conversions and the closing-speed cap (what does a stopped lead do to closing speed when both cars started at 50 km/h?).
2. Ask it for a grid runner: N seeded trials per cell, median TTC at first Warn per cell, measured against noiseless ground truth.
3. Add the acceptance row: median TTC at first warn >= 1.70 s on every CCRb cell. This row has a published origin; cite it.
4. Then ask the room’s question: your arbiter can pass this row by warning constantly. Which other acceptance row stops that?

Simplifications to note in your SAFETY-NOTES: this world is one-dimensional, so the protocol’s lateral overlap grid has no meaning here, and the sim applies the lead’s deceleration as a constant rather than the protocol’s ramp-in tolerance.

Three-hour finish line

The workshop path is complete when the pair has:

1. written a skeleton that makes state and channel policy visible;
2. produced a first working arbiter and one deterministic test;
3. measured a 200-trial baseline;
4. replayed at least one failing or chattering seed;
5. written a policy amendment from that trace;
6. implemented one deliberate stateful revision;
7. added or reviewed at least two properties;
8. run the final metrics, preferably at 1,000 trials; and
9. completed the claim/evidence/assumption/limitation safety case.

A final target miss remains valid workshop evidence when it is recorded and explained.

After-workshop extensions

• Turn measured rates into formal confidence statements with feotest or a documented alternative.
• Build the Euro NCAP protocol grid.
• Add mutation testing and a Kani proof.
• Expand the safety sketch into a requirements-to-evidence matrix and dependent failure analysis.

1. Euro NCAP, “AEB Car-to-Car Test Protocol” v4.3 and “Assessment Protocol, Safety Assist, Collision Avoidance”, https://cdn.euroncap.com/cars/assets/euro_ncap_aeb_c2c_test_protocol_v43_1e6ed06def.pdf. FCW points are awarded at TTC >= 1.70 s. ↩

2. NHTSA, FMVSS No. 127, final rule May 2024, amended November 2024, https://www.federalregister.gov/documents/2024/11/26/2024-27349/federal-motor-vehicle-safety-standards-automatic-emergency-braking-systems-for-light-vehicles. ↩