A Quick Guide to Using GSN for ISO 26262 Safety Cases

In the automotive industry, generating evidence is only half the battle. You must also prove why that evidence matters. A safety case is not just a filing cabinet of documents. It is a logical, defendable argument. When systems grow complex, natural language arguments collapse under their own weight. Claims get hidden, assumptions remain unstated, and reviewers cannot audit the logic.

This guide will show you how to use GSN to build clear, modular, and highly assessable safety arguments that satisfy ISO 26262 requirements and give your assessors exactly what they need.

Why a Safety Case Needs GSN (Not Just Prose)

ISO 26262 Part 2 outlines a critical requirement for functional safety management. It states that a safety case must be developed for every item with an ASIL-rated safety goal. Crucially, this safety case must progressively compile the work products and include a safety argument demonstrating that functional safety is achieved.

Many engineering teams miss the second half of that mandate. They compile the evidence but forget the argument. An assurance case requires three distinct layers:

• Claims: Assertions that the system is safe (e.g., "Unintended self-steering is prevented").
• Argument: The logical reasoning connecting the claims to the evidence.
• Evidence: The actual work products (e.g., FMEDA results, test logs).

When you rely purely on prose, the argument layer becomes implicit. Reviewers are forced to guess how a specific Hardware Architectural Metric relates to a top-level Safety Goal. GSN solves this by making the inference steps explicit, visual, and mathematically structured.

Core Elements of GSN in an Automotive Safety Argument

A simplified GSN diagram showing the relationship between a Goal, a Strategy, a sub-Goal, and a Solution.

GSN represents an argument as a directed graph. Instead of reading paragraphs, you read a visual map of logic. To use GSN effectively, you must understand its core nodes and relationships.

The Primary Nodes

• Goals (Rectangles): These are your claims. Every GSN argument starts with a top-level Goal, such as "The EPS item is acceptably safe." Goals decompose into sub-goals until they are specific enough to be proven.
• Strategies (Parallelograms): These explain how you are breaking down a Goal. For example, your Strategy might be "Argue over all identified hazards" or "Argue by ASIL decomposition."
• Solutions (Circles): These sit at the very bottom of your argument tree. Solutions are pointers to your actual evidence. A Solution node does not contain the FMEDA, it simply cites "FMEDA Report Rev 2.1."

Contextual Nodes

An argument rarely exists in a vacuum. GSN provides specific nodes to capture the environment of your claims:

• Context (Rounded Rectangles): Defines the scope. If your Goal is about braking performance, the Context node might specify "Dry asphalt conditions."
• Assumptions (Ovals with an 'A'): States conditions assumed to be true, which is highly relevant for Safety Elements out of Context (SEooC).
• Justifications (Ovals with a 'J'): Explains why a particular Strategy is acceptable.

The Relationships

Nodes are connected by two types of lines. A solid arrowhead represents a SupportedBy relationship, showing inferential support (a Goal supported by a sub-Goal) or evidential support (a Goal supported by a Solution). A hollow arrowhead represents an InContextOf relationship, linking a Goal or Strategy to its Context, Assumption, or Justification.

A Practical Guide to Building a GSN Argument

Creating a GSN argument requires a systematic approach. The most widely adopted construction method involves a step-by-step process of defining goals, establishing context, and breaking down the logic until evidence is reached. Let us look at how this applies to an Automatic Emergency Braking (AEB) system.

Step 1: Identify the Top Goal

Start with the ultimate claim you need to make. For our AEB system, the top Goal is: "The AEB system achieves functional safety according to ISO 26262."

Step 2: Define the Context

Before breaking down the Goal, define its boundaries. Attach a Context node detailing the item definition, the operational design domain, and the specific ISO 26262 lifecycle phases covered by this argument.

Step 3: Choose a Strategy

How will you prove the top Goal? A common approach in ISO 26262 is to argue over the safety goals derived from the HARA. Your Strategy node would state: "Argue over the satisfaction of all ASIL-rated Safety Goals."

Step 4: Develop Sub-Goals

Based on the Strategy, create sub-Goals for each specific safety goal. For example: "SG1: Prevent unintended maximum braking (ASIL D)."

Step 5: Iterate Until Solutions are Reached

Continue this decomposition. Break SG1 down into Functional Safety Requirements (FSRs), then Technical Safety Requirements (TSRs), and finally hardware and software requirements. Once a requirement is narrow enough, attach a Solution node pointing to the exact verification report or test log that proves it.

Expert Tip: Never attach a Solution directly to a high-level Safety Goal. The inferential leap is too large. A reviewer cannot verify that a single software test proves an entire system is safe. Decompose the logic until the connection between the claim and the evidence is undeniable.

Scaling GSN for Complex Supply Chains

Modern automotive development is highly distributed. An OEM rarely builds the entire system. Instead, they integrate elements from various Tier 1 and Tier 2 suppliers. GSN handles this complexity through modularity.

In a distributed project governed by a Development Interface Agreement (DIA), the OEM creates the top-level item argument. When the argument reaches a subsystem developed by a supplier, the OEM places a special "Away Goal" node. This indicates that the argument continues in a separate GSN module provided by the supplier.

This modular approach perfectly mirrors the ISO 26262 supply chain model. It allows suppliers to protect their intellectual property by sharing only their modular safety argument and interface evidence, without handing over their entire internal database. Furthermore, GSN patterns allow organizations to reuse proven argument structures across different product lines, saving massive amounts of engineering time.

Overcoming Common GSN Pitfalls

While GSN is incredibly powerful, it is easy to misuse if you treat it merely as a drawing exercise. Assessors frequently spot fallacies in poorly constructed graphs. A beautiful diagram that contains circular logic is still a failed safety case.

One major pitfall is the "Evidence Drop." This happens when an engineer links dozens of Solution nodes to a single Strategy without intermediate Goals. The assessor is left wondering how these fifty documents collectively prove the point. Always ensure that every Solution directly supports a specific, narrow Goal.

Another common error is ignoring configuration management. A Solution node must point to a specific, version-controlled document. Citing "System Test Report" is useless. You must cite "System Test Report v3.2" so that change impact analysis can be performed accurately when updates occur.

Conclusion

Transitioning from prose to GSN transforms your safety case from a static paperwork exercise into a living, auditable argument. By making your claims, strategies, and context explicit, you drastically reduce the friction during functional safety assessments and confirmation reviews. GSN forces you to think critically about your logic, ensuring that no assumption goes unstated and no requirement goes unverified.

Ready to move beyond the basics and master the art of safety argumentation? Dive deeper with our comprehensive GSN: Goal Structuring Notation for Safety Cases module on the ISO 26262 Academy platform. You will find interactive node-by-node walkthroughs, advanced modular patterns, and practice exercises to sharpen your safety engineering skills.

Abbreviations & Key Definitions

• AEB - Automatic Emergency Braking, an advanced driver-assistance system.
• ASIL - Automotive Safety Integrity Level, a risk classification scheme defined by ISO 26262.
• DIA - Development Interface Agreement, a document specifying responsibilities between customers and suppliers.
• EPS - Electronic Power Steering, a critical automotive system controlling vehicle direction.
• FMEDA - Failure Mode, Effects, and Diagnostic Analysis, a systematic method to determine hardware failure metrics.
• FSR - Functional Safety Requirement, derived from safety goals to specify required safety behavior.
• GSN - Goal Structuring Notation, a graphical argumentation notation used to build safety cases.
• HARA - Hazard Analysis and Risk Assessment, the process used to identify hazards and assign ASILs.
• OEM - Original Equipment Manufacturer, typically the vehicle manufacturer in automotive contexts.
• SCSC - Safety-Critical Systems Club, the organization maintaining the GSN Community Standard.
• SEooC - Safety Element out of Context, a subsystem or component developed without a specific target vehicle item in mind.
• TSC - Technical Safety Concept, the specification of technical safety requirements and their allocation to system elements.