AD-28 — Autonomous Driving Safety Case: Safety Case and the UL 4600 Standard

FACT — In a century of automotive engineering, the standard way to prove a braking system or an airbag was safe was: follow a recognized process (the ISO 26262 V-model), run the required tests, document it. But to prove the claim “this vehicle drives safely, without a human, within this ODD, at an acceptable level of risk” for a driverless L4 vehicle, there is no century of precedent to lean on — no insurer holding millions of L4 vehicle-years of crash statistics, no regulator who can say “systems like this are generally safe” from a historical record. This lesson examines the discipline that was born in exactly this gap left by process compliance: the Safety Case, and the standard that formalizes it, UL 4600.

In this lesson, you will learn:

1. Why Process Compliance Alone Is Not Enough: The Precedent Gap at L4
2. What UL 4600 Is and How It Diverges from ISO 26262/ISO 21448
3. Safety Case Architecture via Goal Structuring Notation (GSN)
4. The Three Pillars of a Safety Case: Claim, Argument, Evidence
5. The Synthesis Point: Wiring Prior Lessons into the Evidence Chain
6. Continuous Safety Assurance
7. Independent Audit and the “Negative Evidence” Principle
8. The Limits of UL 4600: What a Safety Case Is Not

---

1. Why Process Compliance Alone Is Not Enough: The Precedent Gap at L4

ISO 26262 (see AD-19 — Functional Safety (ISO 26262): HARA, ASIL and Safety Goals) and ISO 21448/SOTIF (see AD-20 — SOTIF (ISO 21448): Safety of the Intended Functionality) both implicitly assume the presence of a human driver: ISO 26262 assumes the driver can intervene at the point of a fault (Controllability), and SOTIF’s scenario coverage is generally framed around an L2/L3 context where the driver can take back control. For a conventional ABS or ESC system, saying “we applied ISO 26262, we ran a HARA, we met our ASIL-D targets” is a sufficient basis for confidence — because those systems sit on decades of field data, millions of vehicle-years of exposure, and a well-understood failure taxonomy.

The situation for an L4 robotaxi is fundamentally different:

• There is no precedent. No manufacturer holds a decade of field record from which to say “driverless vehicles are generally safe.”
• The driver is not a fallback. ISO 26262’s Controllability assumption collapses — there is no one in the cabin to take over on fault.
• The public and regulators do not accept “we followed the process” as a sufficient answer. The question asked after a crash is not “which standard did you follow?” but “how, and why, do you know this vehicle is safe?”

CRITICAL — The distinction between process compliance and a safety case is this: process compliance says “we followed the correct steps”; a safety case says “here is the evidence, and here is the logical argument for why that evidence SUPPORTS the safety conclusion.” The former is a checklist; the latter is an active defense. At L4/L5, the former is not accepted as sufficient without the latter.

To fill this gap, Underwriters Laboratories (UL) published the first major standard purpose-built to evaluate the FULL safety case of an autonomous product: UL 4600.

---

2. What UL 4600 Is and How It Diverges from ISO 26262/ISO 21448

UL 4600 (Standard for Safety for the Evaluation of Autonomous Products) was developed to prove that autonomous driving systems can operate safely without a human driver, and it diverges from prior standards in three ways:

• Goal-Based, Not Process-Based: The standard does not say “run this test” or “follow this V-model.” Instead it asks: “How do you prove the vehicle will never drive over a pedestrian?” — and leaves the burden of proof to the engineer.
• Mandatory Safety Argument: The manufacturer must present a structured, transparent, evidence-backed logical argument that the system is safe — not merely a list of test reports.
• The “Did You Think of That?” Interrogation: UL 4600 uses an extensive catalog of prompts that force engineers to systematically confront edge scenarios, sensor limitations, and unstated assumptions they might otherwise overlook.

This full, autonomy-specific scope stems directly from a real gap: traditional automotive safety standards were never designed with full autonomy in mind when they were written.

Dimension	ISO 26262	ISO 21448 (SOTIF)	UL 4600
Primary Focus	E/E hardware faults & systematic software bugs	Perception & algorithm performance limits (insufficiency, even fault-free)	FULL end-to-end autonomy safety of a driverless system
Driver’s Role	Driver intervention assumed at fault (Controllability)	Driver takeover assumed (L2/L3 context)	No driver in the cabin (L4/L5)
Approach	Process-based (V-model compliance)	Risk analysis & scenario/coverage testing	Goal-based, evidence-backed Safety Case
Role of Evidence	Shows process steps were completed	Shows coverage of unknown-unsafe scenarios has been reduced	Unifies HARA + SOTIF + TARA + V&V + ODD results into ONE argument

INTERPRETATION — It is a mistake to see UL 4600 as replacing ISO 26262 and ISO 21448. The more accurate framing is: ISO 26262 and ISO 21448 are evidence producers, each focused on a particular hazard class (hardware/systematic faults, functional insufficiency); UL 4600 is the overarching framework that unifies these outputs — plus cybersecurity, operational processes, and human factors — into a single coherent, traceable logical chain. We make this concrete in §5.

---

3. Safety Case Architecture via Goal Structuring Notation (GSN)

A Safety Case is a structured body of argument and evidence demonstrating that a system is acceptably safe for its intended use within a defined Operational Design Domain (ODD). Industry visualizes this argument hierarchy using Goal Structuring Notation (GSN):

                  [ G1: System Is Acceptably Safe Within Its ODD ] (Goal)
                                   |
                  +----------------+----------------+---------------------+
                  |                                 |                     |
        [ S1: Argue via Perception ]      [ S2: Argue via Motion/        [ S3: Argue via
                                            Control Safety ]              Cybersecurity ]
                  |                                 |                     |
        +---------+---------+                       |                     |
        |                   |                       |                     |
   [ G2: Objects       [ G3: Sensor            [ G4: Trajectory      [ G5: Critical Attack
    Never Missed ]      Faults Safely          Remains               Surfaces Are
                         Contained ]            Collision-Free ]      Covered by TARA ]
        |                   |                       |                     |
   [ E1: AD-20 SOTIF   [ E2: AD-22/23 HIL      [ E3: RSS Formal      [ E4: AD-21 TARA
    Scenario Coverage,  Fault-Injection         Proof & Proving       Findings and
    Unknown-Unsafe      Test Reports ]          Ground Logs ]         Penetration Test
    Set Reduction ]                                                   Reports ]
   (Evidence)          (Evidence)               (Evidence)           (Evidence)

GSN’s four core elements:

1. Goal (Rectangle): A safety claim requiring proof (e.g., “Our pedestrian detection miss rate is below the specified threshold”).
2. Strategy (Parallelogram): The approach decomposing a goal into sub-goals (e.g., “Argument via multi-modal sensor diversity”).
3. Context (Rounded Rectangle): The ODD and baseline assumptions under which the goal holds (e.g., “The ODD defined in AD-16: daylight, dry pavement, ≤80 km/h motorway”).
4. Evidence (Circle): Concrete, verifiable data supporting the claim — HIL test reports, simulation logs, formal mathematical proofs, track test data, and the outputs we produced in prior lessons.

CRITICAL — GSN’s strength is that every arrow (link) carries a logical claim: saying “E1 is sufficient to reach G2” requires a rationale for WHY that evidence supports that goal — evidence is not simply attached next to a goal because it’s topically related. This is the first thing an auditor interrogates: every link, asking “does this evidence actually support this claim, or is it merely adjacent to it?”

---

4. The Three Pillars of a Safety Case: Claim, Argument, Evidence

A safety case operates much like a legal defense — the three layers are meaningless in isolation:

• Claim: What are you asserting? (e.g., “The vehicle will never enter an intersection against a red light.”)
• Argument: Why should we believe this claim? (e.g., “Camera and HD-map perception independently verify signal state; a neural network and a rule-based controller confirm red simultaneously; if they disagree, the vehicle transitions to a minimal risk condition — see AD-17 — Fallback Strategies, MRM and Minimal Risk Condition (MRC).”)
• Evidence: What data supports this argument? (e.g., “100,000 synthetic intersection tests, 5,000 km of closed-course track testing, and 12 months of shadow-mode logs.”)

$\text{Safety Case} = \{ \text{Claim} \} \xrightarrow{\text{Argument}} \{ \text{Evidence}_1, \text{Evidence}_2, \dots, \text{Evidence}_n \}$

FACT — A claim without evidence is merely a wish; a pile of evidence without an organizing argument is meaningless data noise. UL 4600 mandates that every piece of evidence connect to the top-level safety goal via an explicit logical argument chain. This means that even a single numeric target — such as the $<10^{-8}$ hazardous-failure-per-hour target ISO 26262 sets for ASIL-D — does not by itself PROVE the claim “the vehicle is safe”; it is one piece of evidence on one branch of the argument.

---

5. The Synthesis Point: Wiring Prior Lessons into the Evidence Chain

This lesson is a synthesis point that ties the academy’s safety and verification lessons under one roof. In a real L4 safety case, every result we covered in prior lessons occupies a specific branch of the GSN tree as evidence:

Prior Lesson	Evidence It Produces	Which GSN Goal It Supports
AD-16 — ODD Definition	The precise definition of the boundaries within which safety is claimed	The Context node — the validity frame for ALL sub-goals
AD-19 — HARA/ASIL	Hazard analysis, risk classification, safety goals, hardware failure rates	The “hardware/systematic faults are contained” goal
AD-20 — SOTIF	Evidence of reducing the known-safe, known-unsafe, and unknown-unsafe scenario sets	The “perception/planning is functionally sufficient” goal
AD-21 — TARA	Cybersecurity threat analysis, penetration test results, security controls	The “resilient against malicious interference” goal
AD-22/AD-23 — V&V, Scenario Testing	MIL/SIL/HIL/VIL results, RSS metrics, scenario coverage statistics	The “control/motion planning is collision-free” goal

INTERPRETATION — This table also implicitly answers why the academy proceeds in this order: every method you learned from AD-16 through AD-23 is not an isolated “exercise to complete” — it is ultimately an evidence-production line that feeds into the single logical argument tree covered in THIS lesson. A safety case author does not start from zero — they place prior lessons’ outputs into the GSN tree and identify weak or missing branches.

The practical consequence of this synthesis: a team can have executed a flawless HARA, expanded SOTIF scenario coverage, and completed an exhaustive TARA — but if they have not written the explicit argument CONNECTING these pieces of evidence to one another, they still do not have a safety case, only a disconnected collection of evidence.

---

6. Continuous Safety Assurance

Autonomous vehicle software receives continuous over-the-air (OTA) updates. When a system is updated, the entire Safety Case is not discarded; Continuous Safety Assurance is enforced instead:

• A software change (e.g., updating a perception model) affects the relevant goal and evidence in the GSN tree — for instance, the “SOTIF” row in the §5 table now requires re-evaluation.
• Only the impacted branch is re-validated, and new test results are appended to the evidence library; unaffected branches (e.g., hardware ASIL analysis, if unchanged) are not re-run.
• This requires a traceability infrastructure that can be automated through CI/CD pipelines: every code change must declare which GSN node it affects.

WARNING — Applied without discipline, continuous safety assurance can become a dangerous shortcut: the claim “we only tested the impacted branch” creates false confidence if the impact analysis itself is wrong — for example, if a perception model change is later found to also indirectly affect control behavior in a way that wasn’t identified. The impact analysis itself must therefore be independently audited — a point we expand in §7.

---

7. Independent Audit and the “Negative Evidence” Principle

Engineers who build a system cannot see their own blind spots — this is a well-documented human-factors problem in safety-case engineering. UL 4600 therefore places independent (over-the-shoulder) audit at its center: a third party not involved in building the system — and therefore without emotional or career investment in its design decisions (a body such as TÜV, UL, or a separate internal safety team) — is tasked with interrogating logical gaps and missing evidence links in the GSN tree.

Beyond this, UL 4600 formalizes the “Negative Evidence” (Did we miss anything?) principle — fundamentally different from classic positive evidence-gathering (“we tested this scenario, it passed”):

• Positive evidence asks: “In the scenarios we tested, did the system behave safely?”
• Negative evidence asks: “Which CLASSES of scenarios did we never consider, never test, or not even recognize existed?”

FACT — The second question is far harder than the first, because it requires interrogating an “unknown-unknown” set — terminology we covered in detail in AD-20 — SOTIF. UL 4600’s extensive prompt catalog exists precisely for this purpose: it forces engineers to answer systematic questions like “did you consider this sensor’s failure mode under this environmental condition?”, surfacing overlooked assumptions.

A mileage statistic alone is not sufficient. The claim “we drove one billion miles without a fatality” does not indicate which scenarios were encountered, by what logic the system made decisions, or provide proof that the system will NOT fail on the next mile. Raw statistical exposure cannot substitute for a structured causal argument.

---

8. The Limits of UL 4600: What a Safety Case Is Not

To position UL 4600 correctly, it is worth being explicit about what it does NOT do:

• UL 4600 is not a certification guarantee. Following the standard does not automatically grant regulatory approval — see AD-26 — Global Regulations: UNECE, EU GSR II, US, China, Japan and Turkey; different jurisdictions use different approval frameworks (e.g., UNECE R157), and UL 4600 does not replace them — it is a complementary engineering discipline.
• UL 4600 is not mandatory in every jurisdiction; it is a voluntary framework referenced by some regulators and manufacturers, not a universal legal requirement.
• UL 4600 does not require or promise “zero risk.” The goal is demonstrating “acceptable safety” — absolute safety is an engineering-undefined target.
• A safety case is not a static document. As covered in §6, it is a living engineering artifact that must be continually updated as the vehicle’s software or ODD evolves.

ASSUMPTION — The degree of regulatory acceptance of UL 4600 across different jurisdictions (US states, EU, China), and the extent to which specific manufacturers apply UL 4600 verbatim within their own internal safety-case processes, is not reported in detail in publicly available sources; the framework in this lesson should be taken as a general/conceptual reference, and official documentation should be consulted for a given manufacturer’s or jurisdiction’s CURRENT practice.

---

Frequently Asked Questions (FAQ)

Q: If a company claims “we drove one billion miles without a crash,” does that alone count as a Safety Case?

FACT — No. UL 4600 and safety science do not accept raw mileage counting as proof (§7). Without answering which edge cases were encountered in that billion miles, by what logic the system decided, and what proves the next mile won’t produce a crash, statistical exposure alone cannot substitute for a proven safety argument.

Q: If a team fully applies ISO 26262, do they automatically have a strong UL 4600 safety case?

INTERPRETATION — Partially. ISO 26262’s HARA/ASIL outputs (as shown in the §5 table) are IMPORTANT evidence for one branch of the safety case, but not sufficient alone — SOTIF, cybersecurity, and operational/human-factors dimensions must also be added, all UNIFIED into a single logical argument. ISO 26262 compliance is a necessary but not sufficient component of the safety case.

Q: Why is independent (over-the-shoulder) audit essential?

CRITICAL — Engineers who build a system cannot see their own blind spots (confirmation bias, §7). Independent auditors are tasked with interrogating logical gaps and missing evidence links in the safety case; this role cannot be assumed from within the development team itself.

---

Summary

• Traditional process-based standards (ISO 26262, ISO 21448) implicitly assume a human driver; at L4/L5 that assumption collapses, requiring a positive, evidence-based argument for an unprecedented class of system.
• UL 4600 is the first major goal-based standard purpose-built to evaluate the FULL safety case of an autonomous product; it does not say “run this test,” it says “prove why it’s safe.”
• GSN (Goal Structuring Notation) is a visual argument language of Goal, Strategy, Context, and Evidence nodes, where every link carries an explicit logical rationale.
• This lesson is a synthesis point: HARA/ASIL (AD-19), SOTIF scenario coverage (AD-20), TARA (AD-21), V&V results (AD-22/23), and the ODD definition (AD-16) come together as evidence on separate branches of the safety case’s GSN tree.
• Continuous Safety Assurance re-validates only the impacted branch on an OTA update rather than rebuilding the entire safety case from scratch; independent audit and the “negative evidence” principle systematically interrogate overlooked scenarios beyond mileage statistics.
• UL 4600 is not a certification guarantee, is not mandatory, and does not promise zero risk — it is a structured argumentation discipline for demonstrating acceptable safety.

Sources and Verification Note

This lesson draws on UL 4600 (Standard for Safety for the Evaluation of Autonomous Products), SAE J3016 terminology, the ISO 26262 functional safety framework, ISO 21448 (SOTIF), and the Goal Structuring Notation (GSN) community standard. The example goal/evidence mappings in the GSN diagram and the synthesis table in §5 were conceptually constructed with reference to this academy’s prior lessons (AD-16, AD-19, AD-20, AD-21, AD-22, AD-23); the degree of any specific manufacturer’s or jurisdiction’s CURRENT UL 4600 adoption is marked ASSUMPTION (§8) — consult the standard’s official text and relevant regulatory documentation for precise, current information.

Next Lesson

• AD-29 — Next-Generation Architectures: Centralized Compute, Zonal E/E and Ethernet: We examine the hardware/data architecture underlying the safety arguments covered in this lesson — centralized compute platforms, zonal E/E design, and why automotive Ethernet is partially displacing CAN.