3. Stage-gate process essentials

A stage-gate process divides product development into a sequence of stages, where engineering work is performed, separated by gates, where a cross-functional review board decides whether the project may proceed. In automotive safety development, the gate is not merely a schedule checkpoint. It is the point where the safety argument is re-baselined against the current design, and where the evidence trail for functional safety (ISO 26262), SOTIF (ISO 21448), and cybersecurity (ISO/SAE 21434) is either accepted, conditionally accepted, or rejected.

The essential discipline is this: a gate is defined by its exit criteria, not by its date. If the criteria are not met, the correct outcome is a hold or a conditional pass with a bounded, tracked action list — never a silent slip of the milestone.

Gate anatomy: criteria, deliverables, and decision types

Every gate has three distinct layers that are frequently confused:

  • Deliverables — the artifacts that must exist and be under configuration control (e.g., item definition, HARA report, safety plan, TSC).
  • Gate criteria — the quality and completeness conditions applied to those deliverables (e.g., "all ASIL D safety goals have at least one allocated safety requirement with a verified ASIL decomposition rationale").
  • Decision — the recorded outcome: Pass, Conditional Pass (with owner and due date per action), or Fail/Hold.

A deliverable can exist and still fail its criterion. This distinction is what prevents "checkbox safety" — the common failure mode where documents are produced to satisfy a template rather than to support an argument.

Practical rule: For each gate criterion, name the evidence that proves it and the role accountable for that evidence. A criterion without a named evidence source is not auditable.

Safety work products mapped to lifecycle gates

The table below shows a representative mapping for a passenger-car ECU program using a classic stage-gate model (G0–G5). The exact naming varies by OEM, but the logical dependency — what must be true before the next stage can be trusted — is stable.

Gate Stage focus Key safety work products Representative exit criterion
G0 Concept / feasibility Item definition (draft), preliminary HARA, safety plan v0.1 Item boundary and operational modes agreed; preliminary ASILs assigned
G1 System concept HARA report, safety goals, functional safety concept (FSC) Every safety goal has an ASIL, safe state, and FTTI budget
G2 System design Technical safety concept (TSC), safety requirements allocated to HW/SW Traceability from safety goal → FSR → TSR is complete and reviewed
G3 HW/SW implementation Safety analyses (FMEA, FTA), SW safety architecture, unit verification reports Diagnostic coverage targets met; no open ASIL D anomalies
G4 Integration & verification Integration test reports, safety validation plan, cybersecurity TARA closure All safety requirements verified; validation scenarios executed
G5 Production release Safety case, confirmation measures report, release note Safety case accepted; residual risk documented and signed off

Two properties of this mapping deserve emphasis. First, safety work products are cumulative: the safety case at G5 is not written at G5, it is assembled from artifacts that were created and reviewed at every prior gate. Second, the HARA is not frozen at G1. If the item definition changes — a new operating mode, a changed sensor set, a new ODD boundary — the HARA must be revisited and the affected safety goals re-evaluated. A gate that ignores this becomes a false assurance.

How a gate review actually runs

Consider a G2 gate for a brake-by-wire ECU. The safety manager prepares a gate package containing the TSC, the allocation matrix, and the current open-issue list. The review board — system lead, safety manager, HW/SW leads, quality, and an independent assessor — evaluates against pre-agreed criteria.

A concrete criterion might read: "For each ASIL D safety goal, the TSC shall specify at least one technical safety requirement with a defined fault reaction time, and the sum of detection and reaction times shall not exceed the FTTI allocated in the FSC."

During review, the team checks a specific case: safety goal SG-03 (unintended braking) has FTTI = 100 ms. The TSC allocates a plausibility check in the brake controller with a detection time of 30 ms and a reaction time of 40 ms, totaling 70 ms — within budget. However, the review finds that the wheel-speed sensor path has no documented diagnostic coverage for a stuck-signal fault. The gate outcome is Conditional Pass: the project may enter G3, but a specific action (add stuck-signal diagnostic with defined coverage target) is assigned to the HW lead with a due date before the G3 review.

Common pitfall: Treating a conditional pass as a full pass. If the action is not tracked in the same configuration-managed system as the safety requirements, it will be forgotten, and the gap will surface during assessment — or worse, in the field.

Agile integration without losing gate rigor

Agile development does not eliminate gates; it changes their cadence and granularity. In a scaled agile automotive program, gates remain at the program level (e.g., every 12–16 weeks), while safety work products are produced incrementally inside sprints. The key adaptation is to define gate criteria as a rolling readiness state rather than a one-time document dump.

A practical mechanism is a safety backlog with gate-linked items. Each safety work product is a backlog item with an owner, a definition of done that matches the gate criterion, and a link to the gate it feeds. At any point, the team can query: "Which G3 criteria are not yet evidenced?" This turns the gate from a periodic crisis into a continuous readiness signal.

For example, a team working on an ADAS feature might maintain a sprint-level check: every safety requirement allocated to software must have a linked test case before the sprint is considered done. This is a micro-gate that feeds the macro-gate. The macro-gate then verifies that the aggregate evidence is complete and consistent — not that each individual artifact was produced on time.

Making gates auditable and repeatable

To keep gates defensible, three practices matter more than any template:

  1. Version everything. Gate decisions must reference specific artifact versions. "TSC v1.3 reviewed at G2" is auditable; "TSC reviewed" is not.
  2. Record the rationale for conditional passes. The action, owner, due date, and the criterion it closes must be written into the gate minutes and linked to the safety plan.
  3. Re-verify at the next gate. A conditional pass is only closed when the evidence is presented and accepted at the following gate. This creates a closed loop.

The SVG below illustrates the relationship between stages, gates, and the flow of safety work products, including the conditional-pass feedback loop that keeps unresolved actions visible.

Stage 1 Concept Stage 2 System Design Stage 3 Implementation Stage 4 Verification Stage 5 Production G1 G2 G3 G4 Safety Work Products Flow (cumulative) Item Def → HARA → FSC → TSC → Safety Analyses → Verification Reports → Safety Case Conditional Pass → Action tracked to next gate Gate Criteria (example: G2) • Every safety goal has ASIL + safe state + FTTI • FSR → TSR traceability complete • Fault reaction time ≤ FTTI budget • No open ASIL D anomalies without waiver • Diagnostic coverage targets defined Decision: Pass / Conditional Pass / Hold Agile Micro-Gate (per sprint) • Safety backlog item has owner + DoD • Each SW safety req → linked test case • Evidence versioned in config management • Open actions from last gate reviewed Feeds macro-gate readiness signal Stage Gate Safety Work Product Conditional Pass Loop

The diagram makes the cumulative nature of safety evidence explicit: each stage contributes artifacts that flow into the next gate, and a conditional pass creates a visible, tracked loop back to the unresolved criterion. The agile micro-gate on the right is not a replacement for the macro-gate — it is the mechanism that keeps the macro-gate from becoming a last-minute documentation exercise.

Key takeaways for gate design

  • Define gates by exit criteria, not by calendar dates. A gate without criteria is a meeting, not a control point.
  • Separate deliverables (what exists) from criteria (what must be true about it). Both are necessary.
  • Map safety work products to gates by logical dependency: HARA before FSC, FSC before TSC, TSC before implementation verification.
  • Treat conditional passes as open loops that must be closed at the next gate, with named owners and due dates.
  • In agile programs, use sprint-level micro-gates to maintain continuous readiness, while preserving program-level macro-gates for formal safety acceptance.

When these practices are in place, the gate becomes what it was always intended to be: a defensible, evidence-based decision point that protects both the project and the people who will eventually drive the vehicle.

← Previous 📖 Contents Next →