2. Functional safety fundamentals for agile teams

Agile delivery and functional safety are often framed as opposites: one embraces change, the other demands traceable, frozen commitments. In practice, ISO 26262 does not forbid iterative development — it forbids uncontrolled change to safety-relevant items. The reconciliation point is the safety requirements hierarchy. Once a team understands how a safety goal becomes an ASIL-tagged technical requirement, it can plan sprints around that hierarchy instead of around documents.

From Hazard to Safety Goal

A safety goal is a top-level safety requirement expressed at the vehicle level, not at the component level. It is derived from hazard analysis and risk assessment (HARA). The HARA evaluates each hazardous event against three parameters:

• Severity (S0–S3) — potential harm to persons if the hazard occurs.
• Exposure (E0–E4) — how often the operational situation occurs.
• Controllability (C0–C3) — the ability of the driver or other road users to avoid harm.

The combination of S, E, and C maps to an Automotive Safety Integrity Level (ASIL A–D, or QM for no safety relevance). Consider a concrete example: an electric parking brake (EPB) that can apply unintentionally while the vehicle is travelling at highway speed.

The resulting safety goal might read: "The EPB shall not apply unintended braking torque while the vehicle is in motion above 5 km/h." Note the structure: it states what must not happen, under which condition, and it is measurable. A safety goal is never "the EPB shall be safe."

Functional Safety Concept and Functional Safety Requirements

The safety goal is then refined into a Functional Safety Concept (FSC). Each safety goal is decomposed into one or more Functional Safety Requirements (FSRs) that describe what function must be performed, still independent of a specific implementation. For the EPB example:

• FSR-01: The system shall inhibit EPB application when vehicle speed exceeds 5 km/h, unless a dedicated emergency-braking request is active.
• FSR-02: The system shall detect a discrepancy between the commanded and actual brake state within 100 ms.
• FSR-03: Upon detection of an unintended application, the system shall release the brake within 200 ms and notify the driver.

Each FSR inherits the ASIL of its parent safety goal unless a justified ASIL decomposition is applied. ASIL decomposition allows a high-integrity requirement to be split across two independent, sufficiently independent elements — for example, ASIL D decomposed into ASIL B(D) + ASIL B(D). This is attractive for agile teams because it can be mapped to two separate development streams, but it requires demonstrated freedom from interference and independence, which is a design constraint, not a paperwork exercise.

Technical Safety Requirements and the Agile Backlog

FSRs are allocated to architectural elements and refined into Technical Safety Requirements (TSRs). This is where agile teams gain traction: TSRs are concrete, testable, and can be expressed as backlog items with acceptance criteria. A TSR for FSR-02 might be:

TSR-02.1: The brake ECU shall compare the commanded
          actuator current with the measured current
          every 10 ms.
TSR-02.2: If |I_cmd - I_meas| > 0.5 A for 3 consecutive
          cycles, the ECU shall set fault flag F_EPB_DISCREPANCY.
TSR-02.3: Fault flag latency from physical discrepancy to
          flag set shall be <= 100 ms (ASIL D).

These map cleanly to sprint-level work: TSR-02.1 is a software task, TSR-02.2 is a diagnostic logic task, TSR-02.3 is a verification task with a measurable pass/fail criterion. The ASIL tag travels with each item and determines the rigor of verification — ASIL D requires methods such as fault injection, structural coverage analysis (MC/DC), and independent verification review, whereas QM items follow normal quality processes.

ASIL-Aware Definition of Done

An agile team working on safety-relevant items needs an ASIL-aware Definition of Done. A generic "code reviewed and unit tests pass" is insufficient for ASIL C or D. A practical example:

The team should not treat this table as a checklist to be completed at the end of a release. Each sprint that touches an ASIL-tagged item should produce the corresponding evidence incrementally. This is the core of "safety in agile": the evidence is a by-product of the sprint, not a separate phase.

Derivation in Practice: A Worked Trace

To make the derivation concrete, consider the trace from hazard to sprint task for the EPB unintended-application scenario:

1. Hazard: Unintended EPB application at speed.
2. Safety goal: Prevent unintended EPB application above 5 km/h (ASIL D).
3. FSR-02: Detect commanded/actual discrepancy within 100 ms (ASIL D).
4. TSR-02.2: Set fault flag after 3 consecutive cycles of >0.5 A deviation (ASIL D).
5. Sprint task: Implement discrepancy monitor in brake ECU software; acceptance test injects a 0.6 A deviation for 30 ms and asserts flag set within 100 ms.

If the team later decides to decompose ASIL D into ASIL B(D) + ASIL B(D), the trace must show which architectural element carries which decomposed requirement, and the independence argument must be documented. In agile terms, this is a spike or architecture task that must be completed before the decomposed requirements enter a sprint.

Common Pitfalls

• Confusing safety goals with requirements. A safety goal is vehicle-level and solution-independent; a TSR is implementation-specific. Mixing them makes traceability impossible.
• Ignoring ASIL inheritance. A TSR derived from an ASIL D goal is ASIL D unless decomposition is formally justified. Teams sometimes downgrade ASIL informally to reduce verification effort.
• Treating decomposition as a free lunch. ASIL decomposition requires independence and freedom from interference; without it, the decomposition is invalid.
• Deferring evidence. Collecting verification evidence at release end creates a waterfall in disguise and breaks the agile feedback loop.

The diagram above shows the derivation chain and the ASIL inheritance rule. Each downward arrow represents a refinement step that adds implementation detail while preserving the safety intent. The ASIL tag is not re-evaluated at each level; it is inherited from the safety goal unless a formal decomposition with independence evidence is applied. For agile teams, the practical consequence is that the ASIL tag on a backlog item determines the verification rigor required in the Definition of Done, and that traceability from sprint task back to safety goal must be maintained continuously — not reconstructed at the end of the project.