Guardian in the ISO 26262 Frame

guardian is a toy, but we place it where its real counterpart would live: inside an item developed under ISO 26262. Before writing code, we walk the safety structure the code would sit in.

Three-hour path

Keep four ideas in the live session:

1. Both missed intervention and unwarranted braking are safety-relevant.
2. The two channels buy diversity only when their failures are sufficiently independent.
3. The arbiter owns the decision and must state what happens when channels disagree or disappear.
4. Generated code is acceptable only inside a claim about how its failures are detected by human-owned boundaries and evidence.

The detailed standard, regulation, rating, and protocol discussion later on this page is after-workshop reading in the compressed route.

What ASIL is this?

An automotive safety integrity level (ASIL; ISO 26262-1:2018, 3.6) is assigned per hazardous event by a hazard analysis and risk assessment (HARA; ISO 26262-1:2018, 3.76, method in Part 3, Clause 6). The HARA classifies severity, exposure, and controllability (S, E, C; Part 3, Tables 1, 2, and 3) and reads the result out of the determination table (Part 3, Table 4). For a forward collision warning (FCW) function, two hazards dominate:

• a missed or late intervention in a real conflict, and
• an unwarranted brake at speed, which is itself a hazard for following traffic.

For this workshop, assume the HARA lands the braking path at ASIL D and a warning-only path at ASIL B. The point isn’t these letters; it’s that the false-alarm rows in our acceptance table aren’t comfort requirements. Both directions of failure are safety-relevant.

Decomposition

An ASIL D requirement doesn’t force every element to be developed at D. ISO 26262-9:2018, Clause 5 allows decomposing an initial safety requirement into redundant requirements on sufficiently independent elements (9, 5.4.3). The schemas are fixed in 5.4.9. For D, the options are C(D) + A(D), B(D) + B(D), or D(D) + QM(D), where QM means quality management: no ASIL assigned. The notation keeps the original ASIL in parentheses, because some obligations follow the original requirement, not the decomposed element. These terms and the rest of the safety vocabulary are collected in the glossary.

Our architecture uses the B(D) + B(D) schema, the classic one for forward collision systems, with the two decomposed requirements allocated to two sensing channels built on different physics:

Safety goal: no unwarranted brake; no missed intervention   [assumed D]

   decompose per ISO 26262-9:2018, 5.4.9 a)

├─ camera channel: detection, tracking, TTC estimate        [B(D)]
│    strong on classification and lateral position;
│    degrades in low light, fog, and glare
├─ radar channel: detection, tracking, TTC estimate         [B(D)]
│    strong on range and closing speed in all weather;
│    produces ghosts from multipath and clutter
└─ combiner: cross-channel agreement and envelope checks       [D]
     small, dull, hand-written; Brake requires corroboration,
     and a confident closing track inside the braking envelope
     implies at least Warn within N cycles

The whole decomposition claim rests on independence, and here’s the catch: independence has to be analyzed, not assumed. That’s Part 9, Clause 7. Different physics buys you different failure modes. Fog degrades the camera but not the radar. The multipath ghost that fools the radar is invisible to the camera. What different physics doesn’t buy you is freedom from shared causes: common power, a shared clock, one housing heating both sensors, one software update train. Or, and this is the one that matters for us, the same generated tracking code pasted into both channels. Do that and your B(D) + B(D) collapses back into a single channel wearing two names.

The element that merges the channels keeps the original D. Someone has to own the decision. Decomposition moves rigor around; it never makes the safety goal cheaper. In this exercise both channels are real code: every sensor-sim report carries a sensor field, radar and camera watching the same world with different noise and decorrelated dropouts and ghosts. Your arbiter consumes both streams, which makes it the decision element and the combiner at once, and the combiner keeps the D. So your SAFETY-NOTES need to say how the design weighs the channels when they disagree, and what it does while one of them reports nothing. That statement is your independence argument.

Where the LLM sits, and where the guarantees sit

The generated code lives inside a decomposed B(D) channel, and the letters spell out the cost. B still means the full safety lifecycle at B rigor. The (D) means confirmation obligations that follow the original requirement around. Decomposition doesn’t exempt the agent. It just bounds what one channel’s misbehavior can do. The guarantees live in what stays human-owned: the skeleton and its types, the monitor, the review (compare the independent confirmation measures of ISO 26262-2:2018, 6.4.7 and Table 1), and the verification evidence. Our three-layer suite is a miniature of the Part 6 verification tables. Example tests are requirements-based testing (26262-6:2018, Tables 7 and 8). The properties are the plausibility end of those methods. And the statistical layer, with its recorded threshold origin, is the shape of evidence the acceptance rows demand. A code-generating agent, viewed through Part 8, Clause 11 (tool confidence, TCL), is a software tool whose output you either trust because its failures are detected downstream or qualify separately (8, 11.4.5): our detection argument is the skeleton, the monitor, and the suite.

After workshop: a rating, a regulation, and a standard

Three kinds of document govern a system like this, and they argue different things. Euro NCAP is a consumer rating: it scripts test scenarios (CCRs, CCRm, CCRb), grades each grid cell, and awards FCW points when the warning comes at TTC >= 1.70 s.¹ FMVSS No. 127 is a regulation: FCW required from 10 to 145 km/h when a collision is imminent, lead-vehicle avoidance up to 62 mph, on US light vehicles from September 2029.² ISO 26262 is a standard for how you develop: it governs the process and the evidence, not the test drive. A car is developed under the standard, certified against the regulation, and rated by the program. Passing any one of them is not the other two.

One detail from the protocol is worth reading aloud, because it’s the industrial twin of what our evaluator does. The protocol defines TAEB, the moment braking activates, by signal processing: find the last data point where filtered acceleration is below -1 m/s^2, then walk back to where it first crossed -0.3 m/s^2. “When did the system act” is a definition you write down. Our latency-at-truth-crossing rule is the same move at classroom scale.

1. Euro NCAP, “AEB Car-to-Car Test Protocol” v4.3, https://cdn.euroncap.com/cars/assets/euro_ncap_aeb_c2c_test_protocol_v43_1e6ed06def.pdf. ↩

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