Skip to content

Part V — Safety: ISO 26262 (Automotive)

GUIDE · PART V — ISO 26262

Disclaimer

Syscribe is a modeling and documentation tool provided "as-is" without warranty of any kind. The authors and contributors accept no responsibility or liability for the use of this tool in safety-critical, life-critical, or mission-critical applications.

Output from Syscribe — including validation results, generated templates, traceability reports, and analysis artifacts — must be independently reviewed and verified by qualified engineers before use in any certification, regulatory submission, or safety case. Compliance with standards such as ISO 26262, IEC 61508, ISO 13849-1, ISO/SAE 21434, IEC 61025, DO-178C, or any other functional safety or cybersecurity standard remains the sole responsibility of the user and their organisation.

This tool does not replace a certified safety process, a qualified safety engineer, or a formal assessment body.

5.1 The complete workflow

HazardousEvent (HE-*)          ← from HARA — operational situation + hazard (S/E/C)
    ↓ hazardousEvents:
SafetyGoal (SG-*)              ← top-level safety requirement; ASIL set by the analyst
    ↓ derivedFromSafetyGoal:
Requirement (REQ-*)            ← technical requirements, ASIL inherited/decomposed
    ↓ satisfies: (on PartDef)
PartDef (architecture)         ← design element implementing the requirement
    ↓ verifies:
TestCase (TC-*)                ← evidence that the requirement is met
    ↓
FaultTree / FaultTreeEvent     ← quantitative FMEDA (SPFM, LFM, PMHF)
Argument (ARG-*)               ← GSN safety case linking everything together
AssumptionOfUse (AOU-*)        ← safety manual / SRACs
ConfirmationMeasure (CM-*)     ← review records, independence assessment

5.2 HARA — HazardousEvent

The Hazard Analysis and Risk Assessment begins with HazardousEvent elements. A HazardousEvent records the ISO 26262 risk parameters severity (S0–S3, else E801), exposure (E0–E4, else E802) and controllability (C0–C3, else E803). syscribe derives the ASIL from them (ISO 26262-3 Table 4): show prints it as derivedASIL, hara matrix tabulates it, and W811 flags a SafetyGoal whose asilLevel: is lower than the derived level of an event it references. The analyst still records the decided ASIL as asilLevel: on the SafetyGoal (§5.3), and the reasoning in the body so a reviewer can check it. An event that derives QM needs no goal (W800 is not raised for it).

---
type: HazardousEvent
id: HE-KERNEL-001
name: "Scheduler starvation causes safety monitor thread to miss deadline"
status: approved
severity: S3
exposure: E4
controllability: C3
---

**Hazard**: Priority inversion or starvation in the kernel scheduler.  
**Operational situation**: Vehicle in motion at highway speed; safety monitor
thread rate-monotonic at 10 ms period.  
**ASIL determination**: D (S3 × E4 × C3 → ASIL D per ISO 26262-3 Table 4).

5.3 SafetyGoal

SafetyGoals are the top-level safety requirements derived from the HARA. Each SafetyGoal carries the normative integrity level — set by the analyst from the HARA — and the ftti: (fault-tolerant time interval — ISO 26262 §8.4.2.3).

---
type: SafetyGoal
id: SG-KERNEL-001
name: "Kernel scheduler shall not starve any safety-relevant thread"
status: approved
asilLevel: D
safeState: "Hardware watchdog reset; vehicle enters safe stop state"
ftti: "10 ms — bounded by the watchdog supervision period (100 Hz tick)"
hazardousEvents:
  - HE-KERNEL-001
---

W806 fires if hazardousEvents: is absent. W801 fires if no integrity level is set. W811 cross-checks asilLevel against the ASIL derived from the S/E/C of the referenced HazardousEvents (a goal below the derived level is flagged); a goal above it is allowed, as ASIL decomposition or a conservative choice, and remains a review item.

5.4 Derived requirements

Requirements derived from a safety goal must carry its integrity level (set explicitly — it is checked, not inherited). Use derivedFromSafetyGoal: to express this link directly (and derivedFrom: — with the breakdownAdr: it requires — for hierarchical decomposition between requirements):

---
type: Requirement
id: REQ-SCHED-001
name: "Scheduler shall select highest-priority ready thread at every scheduling point"
status: approved
reqDomain: software
asilLevel: D
derivedFromSafetyGoal: SG-KERNEL-001
verificationMethod: test
---

The scheduler **shall** select the highest-priority ready thread at every scheduling
point (thread release, blocking call, and interrupt return).

If the SafetyGoal carries an integrity level and the requirement sets neither asilLevel nor silLevel, that is E841. A lower level than the goal's (ASIL decomposition) is accepted only with a breakdownAdr: justifying it — otherwise W808.

5.5 Fault Tree Analysis (FTA)

FTA decomposes a top-level failure (the safety goal violation) into hardware and software contributing causes. syscribe implements a three-level structure:

FaultTree (FT-*)               ← the tree root; topEvent: names the SafetyGoal
  FaultTreeGate (FTG-*)        ← AND/OR/XOR/NOT/inhibit gates; inputs: lists children
    FaultTreeEvent (FTE-*)     ← basic / undeveloped / house events (leaf failures)

FaultTree root — id, name, status and topEvent are required (E900); topEvent must resolve to a SafetyGoal (E902):

---
type: FaultTree
id: FT-KERNEL-001
name: "Scheduler fails to execute highest-priority thread"
status: approved
topEvent: SG-KERNEL-001       # the SafetyGoal whose violation is the top event
---

FaultTreeGate — gateType: is one of AND, OR, XOR, NOT, inhibit (E905); inputs: lists the child gates/events by id or qualified name (a gate with no inputs is W901). The tree's root gate is the one no other gate lists as an input:

---
type: FaultTreeGate
id: FTG-KERNEL-001
name: "Ready queue corruption"
gateType: OR                  # top event occurs if any input occurs
inputs:
  - FTE-KERNEL-101
  - FTE-KERNEL-102
---

FaultTreeEvent (basic event with FMEDA fields) — eventKind: is basic, undeveloped or house (required, E907/E909):

---
type: FaultTreeEvent
id: FTE-KERNEL-101
name: "Stack overflow corrupts TCB ready-queue pointer"
eventKind: basic
failureRate: 5.0e-9          # failures per hour (IEC 61508-7 T.C.6 estimate)
diagnosticCoverage: 0.97     # fraction of faults detected by the safety mechanism
latentDiagnosticCoverage: 0.75  # fraction detected by the latent fault mechanism
---

Stack overflow undetected by PSPLIM corrupts the TCB's `next_ready` pointer.

**Failure rate**: 5e-9/h — PSPLIM is a hardware mechanism on ARMv8-M; this is
a first-order software estimate for the residual probability of PSPLIM
misconfiguration or stack frame miscalculation.

**DC = 0.97**: TC-STKLIM-FAULT-HIL-001 validates the full overflow-to-trap-to-
reaction path on hardware. TC-PORT-STKLIM-001 covers register programming.

**DCl = 0.75**: Watchdog deadman backstop provides latent coverage. 25% residual
represents the window between a silent TCB corruption and the next scheduler
selection that would expose it.

Nesting rule (W900): gates and events must live in a subdirectory named after the FaultTree file:

model/Safety/FTA/
  FT-KERNEL-001.md
  FT-KERNEL-001/
    FTG-KERNEL-001.md
    FTE-KERNEL-101.md
    FTE-KERNEL-102.md

Do not add an _index.md to the tree's subdirectory: the directory already takes the FaultTree's qualified name, so a package _index.md there would collide with it (E108).

Render the tree as Mermaid:

syscribe -m model fault-tree render FT-KERNEL-001

5.6 Quantitative FMEDA metrics

Once failureRate, diagnosticCoverage, and latentDiagnosticCoverage are populated on the basic events, syscribe computes SPFM, LFM, and PMHF per safety goal, over every FaultTreeEvent (with a failureRate) nested under a FaultTree whose topEvent is that goal:

syscribe -m model metrics

Example output:

| SafetyGoal | ASIL | SIL | SPFM | LFM | PMHF (/h) | Verdict |
|---|---|---|---|---|---|---|
| SG-KERNEL-001 | D | — | 0.9733 | 0.7754 | 1.471e-9 | fail |

The verdict is pass/fail against the goal's ASIL/SIL targets, or n/a when the goal has no diagnostic-coverage data (the metrics are opt-in).

For ISO 26262 ASIL D: targets are SPFM ≥ 0.99, LFM ≥ 0.90, PMHF < 1e-8/h. A goal that misses any of its targets raises W033. Gate the metrics in CI:

syscribe -m model validate --deny W033

Interpreting a sub-target SPFM: in the example above the goal misses SPFM and LFM (W033). The W033 message names the goal, its level and each missed metric with its actual value and target — it does not attribute the miss to a particular event. To find the dominant gap, look for the FaultTreeEvents with the largest residual contribution failureRate × (1 − diagnosticCoverage); use this to prioritise safety-mechanism work.

5.7 FMEA

The FMEASheet element holds a Failure Mode and Effects Analysis (id, name and status required — E911). Each row in entries: is exploded into a virtual FMEAEntry (FM-* id, required) recording the failure mode, its effect and cause, and the fmeaSeverity / occurrence / detection ratings (1–10 each, E914). The RPN is computed as S × O × D; an explicit rpn: that disagrees is W928. Row keys outside the recognised set (id, ref, name, failureMode, status, effect, cause, fmeaSeverity, occurrence, detection, rpn, recommendedAction, satisfies, ftaRef, failureRate, diagnosticCoverage, latentDiagnosticCoverage) are E922.

A row missing severity, occurrence or detection has no RPN and is W931. A high severity (S ≥ 9, occurrence ≥ 2 or absent) with no recommendedAction is W932 even when the RPN is low (RPN under-weights severity). A row may carry FMEDA data — failureRate (/h), diagnosticCoverage and latentDiagnosticCoverage (0–1) — and, when its ftaRef names a FaultTreeEvent of a tree whose topEvent is a SafetyGoal and that event declares no failureRate of its own, the row contributes to that goal's SPFM/LFM/PMHF (metrics, W033).

---
type: FMEASheet
id: FMEA-KERNEL-001
name: "Kernel FMEA — scheduling and memory protection"
status: approved
entries:
  - id: FM-KERNEL-001
    ref: Software::KernelScheduler        # the analysed component
    failureMode: "Ready queue pointer corruption"
    effect: "Wrong thread selected; priority inversion starves the safety monitor"
    cause: "Stack overflow into an adjacent TCB"
    fmeaSeverity: 10
    occurrence: 2
    detection: 1
    recommendedAction: "Enforce PSPLIM stack limits on every thread (SC-KERNEL-001)"
    ftaRef: FTE-KERNEL-101                # the reconciling fault-tree event
---

Render the RPN-ranked report (all sheets, or one sheet with --fmea-sheet):

syscribe -m model fmea report --fmea-sheet FMEA-KERNEL-001

5.8 Safety case (GSN)

The Argument type implements GSN (Goal Structuring Notation) nodes. argumentType: is claim, strategy, or solution (absent → claim; invalid → E854). supports: names the SafetyGoal or parent Argument argued for; evidence: names the supporting Requirement / TestCase / sub-Argument / AssumptionOfUse. Every ref must resolve (E855). A claim/strategy with neither supports nor evidence is an orphan (W040).

---
type: Argument
id: ARG-KERNEL-001
name: "Top claim: kernel scheduling is safe for ASIL D"
argumentType: claim
status: approved
supports: SG-KERNEL-001
evidence:
  - ARG-KERNEL-002          # strategy sub-argument
  - REQ-SCHED-001           # requirement
  - TC-SCHED-001            # test case
  - AOU-KERNEL-001          # assumption of use
---

The kernel scheduler implements priority-preemptive scheduling that satisfies
SG-KERNEL-001 for all defined configurations.

Visualise the full safety case tree for a goal:

syscribe -m model safety-case SG-KERNEL-001

5.9 Assumptions of Use (SRACs)

AssumptionOfUse elements record the safety manual conditions that the integrator must fulfil. appliesTo: names the SafetyGoal / Argument / Requirement each one constrains (unresolved → E858). They appear as nodes in the safety-case view.

---
type: AssumptionOfUse
id: AOU-KERNEL-001
name: "Integrator shall not use priority 0 for safety-critical threads"
status: approved
appliesTo: REQ-SCHED-001
---

Priority 0 is reserved for the idle thread. Safety-relevant threads **shall**
use priorities 1–7 to guarantee preemption by the safety monitor.

5.10 Confirmation measures

ConfirmationMeasure elements record confirmation reviews, audits and assessments per ISO 26262-2 §6. measureType: is confirmation_review, functional_safety_audit, functional_safety_assessment or cybersecurity_assessment (E849); independenceLevel: is I1, I2 or I3 (E850); status: is planned, in_progress or completed (E924); confirms: names the confirmed work product(s) (E851 if unresolved).

---
type: ConfirmationMeasure
id: CM-KERNEL-001
name: "Functional safety assessment — kernel scheduling"
status: completed
measureType: functional_safety_assessment
independenceLevel: I3
confirms:
  - SG-KERNEL-001
  - REQ-SCHED-001
---

Once at least one ConfirmationMeasure exists, W039 flags every ASIL D (or SIL 3/4) SafetyGoal or native Requirement that no I3 functional_safety_assessment confirms. ISO 26262-2 requires I3 (independence from the developing organisation's management) for the ASIL D assessment; if your project is at I2, document it here and include it as a known gap in your safety plan. For ISO/SAE 21434, W039 also flags a calLevel: CAL4 CybersecurityGoal without an I3 cybersecurity_assessment and a CAL3 one without an I2-or-higher assessment (an I3 measure satisfies the CAL3 rule).

5.11 Key commands for ISO 26262

syscribe -m model metrics                      # SPFM / LFM / PMHF per SafetyGoal
syscribe -m model safety-case                  # full GSN tree for all goals
syscribe -m model safety-case SG-KERNEL-001    # GSN tree for one goal
syscribe -m model fmea report                  # RPN-ranked FMEA table (all sheets)
syscribe -m model fault-tree render FT-KERNEL-001  # Mermaid FTA diagram
syscribe -m model co-analysis                  # safety ↔ security overlap
syscribe -m model audit                        # readiness dashboard
syscribe -m model verification-depth --sil D --min-levels 2  # depth gate