1. Automotive safety development landscape

Modern automotive development operates under two dominant process standards that shape nearly every engineering decision: ISO 26262 for functional safety and Automotive SPICE (ASPICE) for software and systems process quality. Both are process-oriented, evidence-driven, and audit-heavy. At the same time, vehicle programs face compressed timelines, over-the-air update cycles, and rapidly evolving ADAS/AD features — pressures that push teams toward agile delivery. The central tension of this course is how to reconcile the rigor demanded by safety standards with the speed and adaptability that agile methods promise. This chapter establishes the landscape: what each standard actually requires, where they overlap and diverge, and why a naive "agile vs. stage-gate" framing fails in practice.

What ISO 26262 Actually Demands

ISO 26262 is a functional safety standard for electrical/electronic (E/E) systems in road vehicles. Its core logic is risk-based: hazards are identified, an Automotive Safety Integrity Level (ASIL) is assigned from A (lowest) to D (highest), and the rigor of the development process scales with that level. ASIL assignment derives from three parameters — Severity (S0–S3), Exposure (E0–E4), and Controllability (C0–C3) — combined per the standard's lookup tables.

The standard defines a safety lifecycle spanning concept, system development, hardware development, software development, production, operation, and decommissioning. Key work products include the Hazard Analysis and Risk Assessment (HARA), Functional Safety Concept (FSC), Technical Safety Concept (TSC), and safety analyses such as FMEA and FTA. Critically, ISO 26262 requires traceability from safety goals down to implementation and verification evidence, and it mandates confirmation measures — reviews, audits, and assessments — performed by personnel independent of the development team.

Two properties of ISO 26262 matter most for this course. First, it is plan-driven: safety plans, validation plans, and verification plans are baselined before execution. Second, it is evidence-based: an auditor must be able to reconstruct why each safety requirement exists and how it was verified. Neither property is inherently incompatible with iteration, but both constrain how iteration can be structured.

What ASPICE Adds

ASPICE (Automotive SPICE, based on ISO/IEC 330xx) assesses the capability of software and systems development processes. It defines process groups — primarily SYS.1–SYS.5 (system requirements analysis, architecture design, integration, verification) and SWE.1–SWE.6 (software requirements, architecture, detailed design, unit construction, integration, qualification testing) — plus supporting processes like MAN.3 (project management), SUP.1 (quality assurance), and SUP.8 (configuration management).

Each process is rated at capability levels 0–5. Most OEMs require suppliers to achieve Level 2 (managed) or Level 3 (established) for safety-related projects. The assessment looks for process outcomes and work products, not for a specific lifecycle model. This is an important nuance: ASPICE does not mandate waterfall. It mandates that whatever process you use produces consistent, traceable, verifiable outcomes.

Where the Tension Arises

Agile development emphasizes working software over comprehensive documentation, responding to change over following a plan, and short feedback loops. Safety standards emphasize documented rationale, baselined plans, and change control with impact analysis. The conflict is real but often misdiagnosed. The actual friction points are:

• Traceability overhead. Agile teams resist maintaining bidirectional traceability from safety goals to test cases because it feels like bureaucracy. But without it, neither ISO 26262 nor ASPICE assessment can pass.
• Change impact analysis. Agile welcomes changing requirements mid-sprint. Safety standards require that any change to a safety-related item triggers re-evaluation of the safety case. Uncontrolled change is the single most common audit finding.
• Verification timing. Agile favors continuous integration and testing. ISO 26262 requires verification independence that scales with ASIL — for ASIL D, verification must be performed by someone other than the author, which constrains how "self-organizing" a team can be.
• Planning horizon. Stage-gates assume a plan that is stable enough to gate against. Agile assumes the plan will change. The resolution is not to abandon gates but to redefine what a gate evaluates.

Why Stage-Gates Still Matter

A stage-gate process divides development into phases separated by decision points. At each gate, a cross-functional review determines whether the project proceeds, proceeds with conditions, or is held. In safety development, gates serve three irreducible functions:

1. Safety milestone enforcement. The safety lifecycle has mandatory checkpoints — e.g., confirmation that the FSC is consistent with the HARA before TSC development begins. These are not optional.
2. Risk containment. A gate can stop a project before a safety-relevant defect propagates into production. This is a governance function, not a scheduling function.
3. Evidence consolidation. Gates force the team to assemble and review the safety case at defined points, which is exactly what auditors expect to see.

The failure mode of traditional stage-gates is that they become calendar-driven rather than evidence-driven. A gate that passes because "the date arrived" rather than because "the evidence is sufficient" provides no safety value and creates false confidence. The integration challenge is to make gates evidence-triggered while keeping them compatible with sprint cadence.

An Integrated Operating Model

The model this course develops treats the safety lifecycle as the backbone and agile delivery as the execution layer. Safety goals, ASIL allocations, and the safety case structure are defined up front and change only through controlled change requests. Within that backbone, development proceeds in sprints that produce increments of both functionality and safety evidence.

Gates are placed at safety-relevant transitions — not at arbitrary calendar intervals. A gate is triggered when a defined set of work products reaches a defined maturity state. Between gates, sprints run with their own definition of done, which explicitly includes the safety evidence items relevant to that increment.

What This Means for the Rest of the Course

The integrated model has concrete implications that later chapters will develop in detail. Safety goals and ASIL allocations must be stable enough to plan against, which means the HARA and FSC are completed before sprint execution begins — this is a genuine up-front commitment that agile purists resist but safety standards require. Within that constraint, requirements can be elaborated incrementally, as long as each increment is traced to a safety goal and verified to the appropriate ASIL rigor.

Gates become evidence-triggered rather than date-triggered. A gate passes when its entry criteria — defined work products at defined maturity — are met, not when a calendar milestone arrives. This preserves the governance function of stage-gates while allowing sprint cadence to vary. The practical consequence is that gate readiness must be tracked continuously, not assessed in a panic the week before the review.

The remainder of this course builds on this foundation: how to write safety requirements that survive iterative refinement, how to structure verification for ASIL-dependent independence, how to maintain traceability without drowning in tooling overhead, and how to run gate reviews that add safety value rather than ceremonial delay. The landscape is complex, but the integration problem is tractable once the safety backbone and the agile execution layer are clearly separated and their interfaces — evidence, traceability, and change control — are explicitly managed.