4. Safety program planning integration

APQP provides the program management backbone for automotive development: five phases, defined gate reviews, and a disciplined flow of deliverables from concept to production. ISO 26262 (functional safety) and ISO 21448 (safety of the intended function, SOTIF) provide the technical safety lifecycle. The two are complementary but not automatically synchronized. This section explains how to integrate them so that each APQP gate carries the correct safety evidence, and so that safety work products are produced at the moment they are actually needed — not retrofitted before a gate review.

Why Integration Is Necessary

If functional safety is run as a parallel, loosely coupled activity, three failure patterns appear repeatedly:

• Evidence lag: the safety case is assembled at the end of Phase 4, but the architectural decisions it depends on were frozen in Phase 2. Late discovery forces rework or, worse, an argument that no longer matches the design.
• Gate mismatch: a gate review asks for a DFMEA while the safety team is still finalizing the technical safety concept. The gate either passes on incomplete evidence or stalls the program.
• Ownership gaps: SOTIF activities (scenario analysis, triggering condition identification) are often assumed to belong to the ADAS team, while ISO 26262 activities belong to the safety manager. Without a single integrated plan, items fall between organizational boundaries.

The integration objective is therefore: every APQP gate has a defined safety entry and exit condition, and every safety work product has a named owner, a due gate, and a defined input from the APQP side.

Mapping the Safety Lifecycle onto APQP Phases

The table below shows a practical mapping for an item with an ASIL D target and an intended function that includes driver assistance. The mapping is a planning template; the exact placement of work products should be confirmed against the organization's safety plan and the customer's APQP expectations.

Two points deserve emphasis. First, the ASIL determination in Phase 1 constrains everything downstream: it sets the rigor of the safety analyses, the required independence of confirmation measures, and the acceptable residual risk. If the ASIL is revised later, the impact on already-completed work products must be assessed and the safety plan updated. Second, SOTIF work is not a subset of ISO 26262. A function can be free of E/E faults and still be unsafe because of performance limitations or foreseeable misuse. The integration plan must therefore carry both streams explicitly.

Integrating the Safety Plan with the APQP Timing Plan

The safety plan (ISO 26262-2, Clause 6) and the APQP timing plan should be a single schedule with two views. In practice this means:

1. Anchor safety milestones to gates. Each safety work product gets a "required by gate" attribute. For example, the technical safety concept is required by the Phase 2 gate; the safety validation report is required by the Phase 4 gate.
2. Define gate entry criteria for safety. A gate should not open unless the safety deliverables for that phase are complete and reviewed. This prevents the common situation where safety evidence is accepted "pending" and never closed.
3. Plan confirmation measures early. Functional safety assessment and safety validation require independence. The assessor must be identified in Phase 1–2, not recruited in Phase 4.
4. Align supplier milestones. If a supplier delivers a safety-related element, the DIA (Development Interface Agreement) must specify which work products the supplier provides and at which gate. Supplier safety evidence that arrives after the Phase 3 gate cannot support the Phase 3 exit decision.

Worked Example: Aligning a Phase 2 Gate for an ASIL D Steering Function

Consider an electric power steering (EPS) item with an ASIL D torque-assist function. The Phase 2 gate is approaching. The safety manager and APQP lead jointly review the following:

• Inputs: item definition and HARA from Phase 1; preliminary architecture; customer safety requirements; DIA with the motor supplier.
• Expected safety outputs: technical safety concept; technical safety requirements with ASIL attributes; architecture-level FMEA and FTA; safety requirements traced to architecture elements.
• Expected SOTIF outputs: intended function description for the assist behavior; ODD boundaries; list of known unsafe scenarios (e.g., assist torque during a tire blowout, sensor drift at low temperature).
• Gate check: are all technical safety requirements allocated to architecture elements with an owner? Are the safety analyses consistent with the current architecture revision? Is the SOTIF scenario list reviewed by both the safety team and the function owner?

If the FTA identifies a single-point fault with no diagnostic coverage, the gate should not pass until a diagnostic measure is defined and allocated. This is exactly the kind of decision that must happen at the gate, not after design freeze.

Common Integration Pitfalls

Treating the safety case as a Phase 4 document. The safety case is an argument built incrementally. Each gate should add its portion. A safety case assembled at the end is a documentation exercise, not an engineering one.

Confusing confirmation measures with validation. Confirmation measures (confirmation reviews, functional safety assessment, safety audit) verify that the safety process was followed. Safety validation verifies that the safety goals are achieved in the vehicle. Both are required, and they have different independence requirements.

Ignoring SOTIF in the control plan. SOTIF-relevant parameters (e.g., sensor fusion thresholds, performance limits under rain or glare) must appear as special characteristics in the control plan, with corresponding process controls and test coverage.

Letting the DIA lag the APQP plan. Supplier safety interfaces should be agreed before the supplier's development starts. A DIA signed in Phase 3 cannot retroactively shape the supplier's Phase 2 work products.

Visualizing the Integrated Flow

The diagram below shows how the two safety streams feed the APQP gates. Note that the gate is the synchronization point: both streams must deliver their evidence before the gate exit condition is met.

Practical Checklist for the Integration Plan

The following checklist can be used when reviewing whether an APQP timing plan and a safety plan are genuinely integrated. It is deliberately short; each item should be answerable with a document reference, not a verbal assurance.

Integration is not a one-time alignment exercise. It is a planning discipline that must survive design changes, ASIL re-evaluation, ODD expansion, and supplier delays. The gate structure of APQP provides the natural synchronization points; the safety plan provides the content. When both are maintained as a single, change-controlled schedule, the program avoids the two most expensive outcomes: discovering a safety gap after design freeze, and discovering that the safety evidence does not actually support the claim being made at the gate.