Automotive

Automotive functional safety is a young discipline by aerospace standards but a high-stakes one — every road vehicle, every recall, every regulator decision lives downstream of these arguments.

ISO 26262 codified the practice in 2011 and revised it in 2018. The standard prescribes the process; it doesn't prescribe how you present the argument. GSN is one of the more common notations teams reach for when they want the argument to be readable as a single artefact rather than a stack of process records.

The standards stack

• ISO 26262 (Part 1–12) — Road vehicles — Functional safety
• ISO 21448 (formerly ISO/PAS 21448) — Safety of the intended functionality (SOTIF), covering hazards from performance limitations rather than malfunctions
• UNECE WP.29 — Type-approval framework that increasingly references both standards directly for cybersecurity (R155) and software updates (R156)

ISO 26262 introduces the Automotive Safety Integrity Level (ASIL) — A through D in order of severity, with QM (Quality Managed) below — which determines the rigour of the development and verification activities required for each safety-relevant element.

What GSN gives you

An ISO 26262 safety case spans the Hazard Analysis and Risk Assessment (HARA), the Safety Goals, the Functional Safety Concept, the Technical Safety Concept, the hardware and software development records, the integration and verification reports, and the final Confirmation Measure outputs.

GSN holds all of that together as a single argument:

• Top-level claim: the item is acceptably safe for its intended use, at the ASIL determined by the HARA.
• Decomposition strategies: by Safety Goal, by ASIL decomposition (e.g. ASIL D = ASIL B + ASIL B(D)), by safety mechanism, by lifecycle phase.
• Sub-claims: each Safety Goal achieved, each Safety Mechanism effective, each Confirmation Measure complete.
• Evidence (Solutions): HARA records, FSC/TSC documents, hardware FMEDA, software verification reports, tool qualification records.

An example fragment

A high-level argument for an Electronic Power Steering (EPS) item at ASIL D:

Each Safety Goal terminates in Solutions — the HARA entry that derived it, the FSC element that allocates safety requirements, the FMEDA that demonstrates the random hardware failure metrics meet the target, the software verification evidence for the relevant ASIL.

SOTIF (ISO 21448)

ISO 26262 covers hazards caused by E/E malfunctions. ISO 21448 covers hazards caused by the system doing what it was designed to do — performance limitations, foreseeable misuse, edge-case environmental conditions. Driver-assistance and automated-driving functions need both.

In GSN, the SOTIF argument typically attaches as a parallel branch off the top-level Goal, decomposed by hazardous behaviour rather than by component failure. Lemmatica's away-goal mechanism lets you keep the two arguments separate but linked.

Where Lemmatica fits

• Multi-team development at OEM scale — Tier 1 suppliers, OEM integration, regulator submissions — runs into the same merge-conflict pain as any other large-document workflow. Real-time collaboration removes it.
• ASIL decomposition tracking through the structured argument shows which sub-claims inherit which ASIL, making the rationale auditable.
• Modular sub-cases support the typical item / element separation, and let supplier-developed sub-arguments link in via away goals.
• Continuous validation catches structural gaps early — undeveloped Safety Goals, orphaned Solutions, missing Context — rather than during the Confirmation Measure or external assessment.