The ISO 26262 Safety Chain

12.1 The shape of the safety chain

ISO 26262 specifies the safety lifecycle for road-vehicle electrical and electronic systems. That lifecycle is built around five principal artifact categories, which together make up the safety case argument. Sylang represents each one with its own file type:

1. Item definition (.itm): what is being certified.
2. Hazard analysis (.haz): what can go wrong.
3. Safety goals (.sgl): the top-level safety objectives the item must meet to prevent the hazards.
4. Safety requirements (.req): the prescriptive content that allocates the safety goals to specific functions and blocks.
5. Safety mechanisms (.sam): the concrete realizations that satisfy the requirements.

Expand

In concept, the chain is roughly waterfall: the item drives hazards, which drive goals, which drive requirements, which drive mechanisms. In practice it's iterative, with changes propagating forward and backward as the engineering evolves. Sylang supports both modes. Forward authoring is the typical first pass, and iteration relies on the bilateral traceability that the derivedfrom, leadsto, mitigates and satisfies relationships establish.

ISO 26262 clause mapping

Each artifact category maps to specific clauses in ISO 26262:2018. Here's the mapping, in case you want to read the chapter alongside the standard.

The mapping is one-to-many in both directions. One Sylang file may contribute to several ISO clauses. The .req file, for example, contributes to functional, technical and software safety requirements, depending on each requirement's level property.

Likewise, one ISO clause may be satisfied by several Sylang files. The safety mechanisms work product draws on .sam files plus the supporting .blk and .fun files that realize the mechanisms. The mapping is sufficient for an auditor cross-referencing the safety case against the standard.

What follows

Subchapters 12.2 to 12.5 take the five artifact types in order. 12.2 covers the item definition and hazard analysis, the upstream artifacts that establish what is being analyzed and what can go wrong. 12.3 covers the safety goals (the middle of the chain) and 12.4 the safety mechanisms (the downstream realization). 12.5 covers the cross-anchor mirror examples for the autopilot (DO-178C), infusion pump (IEC 62304) and cobot (IEC 61508) contexts.

By the end of the chapter, you'll have authored, or be ready to author, a complete safety chain for an ASIL-D or equivalent item.

12.2 The item definition (.itm) and hazard analysis (.haz)

The safety chain begins with the item definition (.itm) and the hazard analysis (.haz). The item definition establishes what is being certified: the boundaries of the safety-critical scope, the operating modes in which the item operates, and the external entities it interacts with. The hazard analysis enumerates what can go wrong: the malfunctions that can arise within the item's scope, the operational situations in which they manifest, and the severity-exposure-controllability scoring that determines the ASIL. In this subchapter we'll look at both file types.

The .itm file

An .itm file declares one item definition. Its role is to fix the boundary of the safety analysis: what is inside the safety boundary (and therefore subject to ISO 26262 process rigor) and what is outside (and therefore not). It also fixes which operational modes the item exhibits.

You set the boundary with def boundary clauses, each naming the includes ref function|block and excludes ref function|block that fall inside or outside. You set the operational modes with def operatingmode clauses, each naming the operating conditions and the safety level applicable in that mode.

Here's the item definition from the EPB anchor:

hdef itemdefinition EpbItem
  name "EPB Item Definition"
  iso26262part "Part 3"
  safetylevel ASIL-D

  def boundary EpbBoundary
    name "EPB Functional Boundary"
    includes ref block EpbController, ClampForceMonitorUnit, MotorDriverUnit
    includes ref function EngageController, ReleaseController, HoldMonitor

  def operatingmode Driving
    conditions "Vehicle speed > 0; ignition Run; EPB released."
    safetylevel ASIL-D

  def operatingmode StationaryEngaged
    conditions "Vehicle speed = 0; EPB clamp force at setpoint."
    safetylevel ASIL-D

Three properties on def boundary stand out:

• includes ref block|function names what is inside the boundary.
• excludes ref block|function names what is explicitly outside: typically things an auditor might expect to be inside but that this item's scope excludes by design.
• itemscope ref function|feature (less commonly used) is an alternative way to express boundary content at coarser granularity.

The operating modes are the operational states the safety analysis considers. The EPB has five (Driving, StationaryEngaged, Engaging, Releasing, SafeStop). Each carries a conditions property describing when the mode is active and a safetylevel indicating the safety classification that applies in that mode. The mode set is the universe of operational situations the hazard analysis enumerates over.

The .haz file

An .haz file declares one hazard analysis (HARA). It's a list of def hazard clauses, each containing one or more nested def situation clauses. The hazard is the type of malfunction; the situation is the operational context in which the hazard manifests. The ASIL is determined per situation, and the parent hazard inherits the worst situational ASIL.

hdef hazardanalysis EpbHazards
  name "EPB Hazard Analysis"
  iso26262part "Part 3"
  safetylevel ASIL-D

  def hazard UnintendedRelease
    name "Unintended Release on Gradient"
    malfunctionof ref function HoldMonitor
    affects ref feature CoreEpb

    def situation RollawayInTraffic
      name "Rollaway in stop-and-go traffic"
      severity S3
      exposure E4
      controllability C3
      safetylevel ASIL-D

The hazard's malfunctionof ref function identifies the function whose malfunction produces the hazard. That's a key edge for the safety case argument: the hazard exists because of a specific function failing. affects ref feature|function|block names what the hazard affects.

On each situation, severity, exposure and controllability are the S/E/C scoring per ISO 26262 Part 3 Annex B. The resulting safetylevel is derived from the S × E × C table.

An auditor evaluating the HARA reads the hazard list and confirms that the enumeration is complete relative to the item's operating modes: every plausible malfunction-mode-situation combination is addressed. The auditor also confirms that the prose accompanying each situation justifies its S/E/C scoring.

Because the Sylang file is machine-readable, the auditor can also run queries. Find all ASIL-D situations; find all hazards affecting safety-critical features; find all situations with controllability C3. Queries like these would be impractical against a Word-document HARA.

What follows

Subchapter 12.3 covers the safety goals, the bridge between the hazard analysis and the safety requirements. Subchapter 12.4 covers the safety mechanisms that realize the requirements, and Subchapter 12.5 covers the cross-anchor mirror examples.

12.3 The safety goal set (.sgl)

The safety goal set bridges the hazard analysis and the safety requirements. Each safety goal is a top-level safety objective that addresses one or more hazards. Together, the safety goals constitute the functional safety concept (per ISO 26262 Part 3 §7).

Structure

An .sgl file declares a safetygoalset containing def safetygoal clauses. Each goal carries identity properties (name, description) and a safety level, inherited from the worst hazard the goal mitigates. It also carries four structurally consequential properties: safestate, safecondition, faulttoleranttime (FTTI) and emergencyoperationtime.

  def safetygoal SG_NoUnintendedRelease
    name "No Unintended Release"
    description """The EPB shall not release without an explicit, validated
      release command from the driver or from the validated auto-release logic."""
    safetylevel ASIL-D
    derivedfrom ref hazard UnintendedRelease
    derivedfrom ref situation RollawayInTraffic
    mitigates ref hazard UnintendedRelease
    safestate "EPB remains engaged at commanded clamp force; driver annunciated."
    safecondition "ClampForce >= (Setpoint - Tolerance) AND HoldStatusFlag = 1"
    faulttoleranttime 500
    emergencyoperationtime 3000
    leadsto ref requirement REQ_EPB_001, REQ_EPB_004, REQ_EPB_005
    allocatedto ref item EpbItem

Safe state, safe condition, FTTI

Together, these four properties define the safety goal's operational specification. safestate describes what the system does upon detecting a fault, typically as a prose description of the achievable safe condition: the brake remains engaged, the autopilot disconnects to manual control, the pump suspends delivery. safecondition gives the formal condition that defines the safe state: the precise sensor readings, signal states or system properties that establish the system is in the safe state.

faulttoleranttime (FTTI) is the maximum time from fault occurrence to safe-state achievement, and the safety case argues that the system reaches the safe state within this time. The value is in the timingreference units of the safety-goal set's containing project (typically milliseconds). For the EPB's SG_NoUnintendedRelease, FTTI is 500 ms: within this time after a fault is detected, the system must be back in the safe (engaged-and-holding) state.

emergencyoperationtime is the maximum time the system may operate in degraded mode after FTTI is exceeded but before terminal safe stop is required. For the EPB it's 3000 ms, so 3 seconds of degraded operation are tolerable before the system must transition to terminal safe stop (no further engagement attempts until service). Both values are derived from the hazard's controllability assessment and from the operational context of the affected situation.

Traceability: derivedfrom, mitigates, leadsto, allocatedto

Four traceability edges position the safety goal in the safety chain:

• derivedfrom ref hazard|situation points upstream to the HARA: the hazard or specific situation that motivates the goal.
• mitigates ref hazard names the hazard the goal mitigates. It's often the same as derivedfrom, made explicit for the safety case argument.
• leadsto ref requirement points downstream to the requirements that decompose the goal.
• allocatedto ref item names the item the goal applies to.

Together, the four edges make the goal an integrated component of the safety case. The auditor's question, which hazards does this goal cover and which requirements does it decompose into?, is answered by reading them. The coverage analysis (Chapter 15) reports orphans and broken refs across the goal set, so you see safety chain gaps before they reach the audit.

What follows

Subchapter 12.4 covers the safety mechanisms: the concrete realizations that satisfy the requirements derived from the goals. Subchapter 12.5 closes the chapter with the cross-anchor mirrors and the integration argument.

12.4 The safety mechanism set (.sam)

Safety mechanisms are the concrete realizations that satisfy safety requirements. Requirements specify what must be true; mechanisms specify how it's achieved, through redundancy, monitoring, diagnostic, degradation or validation patterns. The .sam file records each mechanism with the metadata an auditor needs to assess its adequacy. That means the mechanism type, the effectiveness percentage, the detection and reaction times, the requirements satisfied and the hazards mitigated.

Structure and the mechanismtype enumeration

An .sam file declares a safetymechanismset containing def safetymechanism clauses. Each mechanism's principal property is mechanismtype, drawn from a five-value enumeration:

• redundancy: duplicated hardware or software providing diverse implementations of the same behavior.
• monitoring: a process that observes another process for fault.
• diagnostic: a test that detects and reports a specific fault class.
• degradation: a graceful-fallback strategy that maintains partial function under fault.
• validation: a precondition check that prevents a fault from arising in the first place.

  def safetymechanism RedundantClampForceMonitor
    name "Redundant Clamp Force Monitor"
    description """Two independent sensing paths for clamp force,
      cross-checked at 100 Hz."""
    mechanismtype monitoring
    safetylevel ASIL-D
    safetymechanismeffectiveness "99.9%"
    detectiontime "10ms"
    reactiontime "100ms"
    satisfies ref requirement REQ_EPB_001
    mitigates ref hazard UnintendedRelease
    allocatedto ref block EpbController
    implementedby ref function ClampForceMonitor
    detects ref failuremode ForceSensorOpenCircuit, ForceSensorDrift

Three quantitative properties distinguish a mechanism from a generic function. safetymechanismeffectiveness gives the fault-coverage percentage: the fraction of the targeted fault population the mechanism is expected to detect or prevent. It's typically 90% to 99.99%, with the exact value derived from the hazard analysis's required diagnostic coverage.

detectiontime gives the time from fault occurrence to mechanism detection. reactiontime gives the time from detection to safe-state action.

Relationships: satisfies, mitigates, allocatedto, implementedby, detects

Five relationships position the mechanism in the safety chain:

• satisfies ref requirement binds the mechanism to the requirement it realizes. This is the primary upstream edge.
• mitigates ref hazard binds the mechanism to the hazard it addresses (often inherited transitively through the requirement, made explicit here).
• allocatedto ref block names the architectural block that hosts the mechanism.
• implementedby ref function names the specific function realizing the mechanism. Note that it's file-scoped to .sam, where it targets function rather than the more general requirement.
• detects ref failuremode names the FMEA failure modes the mechanism detects, linking the mechanism to the bottom-up safety analysis of Chapter 13.

Together, the five edges make the mechanism a fully integrated component of the safety case. An auditor evaluating the mechanism reads three things:

1. Quantitative properties: do the effectiveness, detection time and reaction time satisfy the requirements?
2. Requirement satisfaction: is the requirement actually addressed by this mechanism's behavior?
3. Failure-mode coverage: are the relevant failure modes from the FMEA detected by this mechanism?

What follows

Subchapter 12.5 closes the chapter with the cross-anchor mirrors (autopilot, infusion pump, cobot) and with the integration argument: the safety chain holds together end-to-end.

12.5 Cross-anchor mirrors and the integration argument

The ISO 26262 safety chain from Subchapters 12.1 to 12.4 is the automotive instance of a more general pattern. The same chain (item, hazards, goals, requirements, mechanisms) appears in DO-178C (with DAL replacing ASIL), IEC 62304 (with software safety classes) and IEC 61508 (with SIL). In this subchapter we'll walk the mirror examples briefly. Then I'll close the chapter with the integration argument: the chain holds together end-to-end for the safety case.

DO-178C: the autopilot anchor

DO-178C's analog of the ISO 26262 safety chain replaces each link with its own work product:

• The item becomes the aircraft function (per ARP 4754A).
• The hazard analysis becomes the functional hazard assessment (FHA).
• The safety goals become the failure conditions: the hazardous events the FHA enumerates.
• The requirements become the high-level requirements (HLR) and low-level requirements (LLR) at the software level.
• The mechanisms become the software architecture elements that satisfy the requirements.

Sylang's .itm, .haz, .sgl, .req and .sam map cleanly to the DO-178C work products once you adjust the terminology. The autopilot anchor's safety chain isn't fully authored in the companion repository yet, but it would use the same five file types with DO-178C-specific content. The AlphaProtectionLaw function's malfunction produces the Stall hazardous event, and the safety goal SG_NoStall derives from that event. The requirements REQ_AP_001 to REQ_AP_005 decompose the goal, and the safety mechanism RedundantAlphaSensor satisfies the requirements.

IEC 62304: the insulin pump anchor

IEC 62304's analog operates at the software-component level, with the system-level analysis in the parent ISO 14971 risk management. In the insulin pump anchor, the pump's software classification (Class C per IEC 62304) plays the role of the ASIL. The bolus-overdose hazard is the principal failure mode, the safety goal SG_NoBolusOverdose is the top-level objective, and the dose-limiter mechanism DoseLimiter is the principal realization. The structure is identical to the EPB's; what differs is the domain content (insulin pump versus brake).

IEC 61508: the cobot anchor

IEC 61508's analog uses SIL classifications (1 to 4) and explicit Safety Functions (SF) that the safety analysis decomposes. The cobot anchor treats the SafeMonitoredSpeed feature as the principal safety function (SIL-3 per the IEC 61508 / ISO 13849 mapping). The OperatorImpact hazard is the top-level risk, SG_NoOperatorImpact is the goal, and the speed-monitor mechanism is the realization. As in the other mirrors, the five-file structure is the same; only the domain terminology differs.

The integration argument

The four anchors' safety chains illustrate the broader claim. The Sylang .itm / .haz / .sgl / .req / .sam artifact set is sufficient for any of the four dominant regulatory regimes for software-intensive safety-critical systems. The artifacts' structure is constant; the domain-specific content (the standard's terminology, the specific safety levels, the specific test methods) lives in property values, not in file structure.

Say you're an automotive supplier entering the medical-device market, moving a program from ISO 26262 to IEC 62304. You reuse the same file types with adjusted content, and your toolchain investment carries forward.

The integration argument generalizes. It's what makes this book's cross-domain anchor pattern (the same MBSE patterns expressed across automotive, aerospace, medical and industrial regulatory regimes) operationally meaningful rather than merely rhetorical.

Closing Chapter 12

Chapter 12 has covered the five-file safety chain at the depth you need for production authoring across the four anchor domains. You've seen the chain's shape (12.1), the item definition and hazard analysis (12.2), the safety goals (12.3), the safety mechanisms (12.4) and the cross-anchor mirrors (this subchapter). Next, Chapters 13 (FMEA) and 14 (FTA) cover the bottom-up and top-down failure analyses that complement the safety chain. Chapter 15 covers the traceability and coverage analyses that make the entire artifact set auditable.

Exercises (Chapter 12)