Integrating Quality Standards and Core Tools Across Development Gates

Welcome back. In the last lesson, you built a controlled standards register: the source-control layer that identifies whether a regulation, standard, customer requirement, or core tool applies, which revision governs, and what evidence it calls for.

This lesson turns that register into a working development system. You will map quality-system standards, customer overlays, and automotive core tools to a simulated set of development gates for the assumption-based EDV projects. The central discipline is to keep their roles distinct: ISO 9001 and IATF 16949 define expectations for the management system; APQP organizes product-quality planning; FMEA and Control Plans manage risk and process control; PPAP provides a customer-facing production approval submission; and CSRs add customer-specific obligations.

---

Start with the correct mental model: layers, not synonyms

In automotive programs, documents are often casually grouped under “quality requirements.” That is convenient shorthand, but it produces weak engineering decisions. These items interact, yet none can substitute for another.

Item	What it is	Its main job	What it is not
ISO 9001	General quality-management-system standard	Defines disciplined organizational processes for planning, documented information, competence, control of nonconformity, improvement, and more	A component test specification or an APQP timing plan
IATF 16949	Automotive QMS standard used with ISO 9001	Adds automotive expectations, including stronger attention to product safety, supplier development, contingency, traceability, change management, and manufacturing-process control	A PPAP package or a customer engineering specification
Customer-specific requirements (CSRs)	Customer-owned supplemental requirements	Specify how a particular customer expects relevant QMS, core-tool, submission, approval, portal, and record requirements to be handled	A universal requirement applicable to every OEM
APQP	Product-quality planning framework	Organizes cross-functional work, timing, risks, deliverables, reviews, and readiness decisions across a program	A certification standard or evidence that a part is approved for production
AIAG-VDA FMEA	Risk-analysis methodology	Identifies functions, failure chains, controls, and actions to improve a design or process before failures reach the customer	A final inspection plan or a PPAP approval
Control Plan	Controlled manufacturing-process document	States what characteristics and process parameters are controlled, by whom, how often, with what method, and what happens when results are unacceptable	An FMEA, drawing, or one-time launch report
PPAP	Production-part approval process and evidence submission	Demonstrates that production-intent parts and processes meet agreed design-record and specification requirements	The entire APQP process or a substitute for ongoing process control

A useful way to think about the relationship is this:

• ISO 9001 and IATF 16949 establish the organization’s operating discipline.
• CSRs overlay specific customer expectations onto that discipline.
• APQP provides the program roadmap and gate structure.
• FMEA identifies and prioritizes risk within that roadmap.
• Control Plans convert relevant manufacturing risks and requirements into recurring controls.
• PPAP assembles selected evidence to support a customer decision on production readiness.

The APQP flowchart below shows why confusion occurs: its phases contain deliverables from several different tools. The flowchart is an integration view, not proof that all the tools are the same thing.

---

APQP phases and management gates

APQP is normally described through five overlapping phases:

1. Plan and define the program.
2. Product design and development.
3. Process design and development.
4. Product and process validation.
5. Feedback, assessment, and corrective action.

A company gate is the management decision point placed at a meaningful program boundary. It asks whether the team has sufficient evidence, resources, and risk control to proceed. A gate is therefore not merely a meeting, and it is not a ceremonial signature after the engineering work is complete.

The APQP third-edition gated-management example uses six gates because it separates initial concept approval from detailed program approval. Your simulated EDV program will use the same practical convention:

Simulated gate	Primary decision	APQP emphasis
G0 — Concept initiation	Should the team authorize planning work and resource the concept?	Before or at the start of Phase 1
G1 — Program approval	Are requirements, timing, risks, sourcing assumptions, and quality planning sufficient to proceed?	End of Phase 1
G2 — Design feasibility	Can the proposed design meet requirements and be manufactured, assembled, and serviced?	End of Phase 2
G3 — Process feasibility	Is the proposed manufacturing system capable of controlling the design?	End of Phase 3
G4 — Launch readiness	Is production-intent product and process evidence sufficient for launch and PPAP disposition?	End of Phase 4
G5 — Feedback and stabilization	Has performance justified transition from enhanced launch controls to normal production controls?	Phase 5

These are simulated internal gate names, not asserted Rivian or Amazon procedures. In a real program, the customer’s product-development system, statement of work, and CSR may prescribe different names, dates, approval authorities, or submission portals.

The key point from this model is that gate deliverables are not isolated. Outputs from one phase become inputs to the next. For example, a design requirement and a preliminary special characteristic identified at G1 shape the DFMEA at G2. The DFMEA then informs the process PFMEA and Control Plan developed at G3.

---

Map each framework to the gates

ISO 9001 and IATF 16949: the system operating throughout every gate

Neither ISO 9001 nor IATF 16949 belongs only at G0 or G4. They govern how the organization controls its work across the whole program.

For the simulated EDV program, evidence of IATF-aligned behavior should be visible at every gate:

Gate	Quality-system behavior expected
G0	Defined roles, competence needs, document-control approach, initial risk assessment, controlled assumptions
G1	Reviewed customer inputs, controlled requirements baseline, supplier-interface responsibilities, planned design and development controls
G2	Design-review records, verification status, controlled design outputs, feasibility assessment, traceable approvals
G3	Supplier and manufacturing-process readiness, documented process controls, measurement planning, escalation of open issues
G4	Production-intent evidence, nonconformance handling, traceability, customer submission records, launch controls
G5	Performance monitoring, corrective action, lessons learned, controlled updates to FMEAs and Control Plans

Thus, do not write “IATF complete” as a G4 deliverable. A stronger G4 statement would be:

“The release package demonstrates that the simulated QMS has controlled the applicable design, supplier, configuration, validation, nonconformance, and approval records through the launch-readiness baseline.”

That wording acknowledges that IATF-aligned discipline is demonstrated by the controlled records and decisions made across the program.

Customer-specific requirements: the gate-specific overlay

A CSR can affect any gate. It may require a particular FMEA method, specific special-characteristic symbols, customer approval of selected documents, a prescribed PPAP level, an electronic submission portal, defined safe-launch exit criteria, or retention periods.

However, never infer an EDV customer requirement from another OEM’s CSR. Use public OEM documents to understand how CSRs work, but label the actual EDV requirement as:

• approved customer requirement, if you have a controlled customer source; or
• program assumption pending customer confirmation, if you do not.

The Ford CSR is a useful illustration of a genuine customer overlay. It shows that customer expectations may require acceptance of FMEAs and Control Plans, prescribe traceability between special characteristics and risk records, and require a particular PPAP approach. Those details are Ford-specific, not transferable by default to another customer.

For your simulated project records, create a CSR-SIM-001 entry in the standards register. It can define the course’s required deliverable formats and evidence, but it must be clearly identified as a simulated program requirement, not a real Rivian or Amazon CSR.

---

APQP is the gate framework; PPAP is a late-stage evidence submission

APQP starts early, when information is incomplete. It is deliberately preventive: it brings customer needs, requirements, risks, feasibility, supplier readiness, test planning, and manufacturing planning into view before production problems become expensive.

PPAP normally occurs much later, around product and process validation. It is the formal evidence package that supports a production approval decision for a defined production-intent configuration.

The relationship can be expressed precisely:

Statement	Accurate?	Why
“APQP is a structured planning framework.”	Yes	It coordinates activities and deliverables across development and launch.
“PPAP is one output of APQP.”	Yes	It uses evidence generated through design, process development, validation, and production-intent trials.
“PPAP replaces APQP once approved.”	No	APQP feedback, production control, corrective action, and change management continue after launch.
“A PPAP is automatically required for every engineering change.”	Not necessarily	The applicable customer PPAP and change-notification requirements determine whether resubmission is required.
“An approved PPAP means the FMEA and Control Plan can never change.”	No	Both are living records; changes need controlled review, evidence, and customer notification or approval where required.

At G4, a strong gate decision does not say, “All paperwork is done.” It says something closer to:

“The production-intent configuration, manufacturing process, measurement systems, validation evidence, special-characteristic controls, and customer-required PPAP evidence have been reviewed. The customer disposition is approved, interim approved, rejected, not required, or pending.”

That distinction matters. A supplier can have a technically complete internal package while still awaiting customer approval. Conversely, an interim customer approval does not make unresolved process risk disappear; it requires clear containment, ownership, and timing.

---

FMEA and Control Plans: connected records with different responsibilities

The AIAG-VDA FMEA method is built around understanding intended functions before analyzing failure. It supports prevention and risk optimization, rather than treating risk analysis as a static form to be completed for a gate.

For a design-responsible component such as the simulated high-voltage ECU housing:

• The DFMEA examines design functions and potential design failure mechanisms.
• The PFMEA examines manufacturing-process functions and potential process failure mechanisms.
• The Control Plan defines the recurring controls used during prototype, pre-launch, safe-launch, or production conditions.

The records should be linked, but they should not be copied mechanically into one another.

Record	Typical gate maturity	Main content
Preliminary DFMEA scope and known-risk review	G1	Intended functions, historic risks, new technology, early risk assumptions
Part DFMEA	G2	Product structure, functions, failure effects, causes, prevention and detection controls, action-priority decisions
Process flow	G3	End-to-end manufacturing and inspection sequence
PFMEA	G3	Process-step functions, process failure chains, controls, and improvement actions
Prototype Control Plan	G2	Measurements and tests needed to learn from prototype builds
Pre-launch Control Plan	G3	Enhanced temporary controls before the manufacturing process is fully validated
Production Control Plan	G4	Sustained production controls, methods, frequency, reaction plans, and ownership
Revised FMEAs and Control Plans	G5 and changes	Learning from production performance, corrective actions, supplier issues, and engineering changes

A practical traceability chain for the ECU enclosure could look like this:

1. The requirement baseline states that the installed enclosure must maintain its specified ingress performance under the approved test conditions.
2. The DFMEA identifies loss of sealing as a potential functional failure and evaluates causes such as inadequate gasket compression, distorted sealing land, or incomplete fastener clamp load.
3. The team identifies potential special characteristics only where justified by the approved requirement and risk analysis. A sealing-land geometry or gasket-compression-related feature might become a candidate.
4. The PFMEA examines manufacturing causes such as warped molded parts, flash on the sealing land, incorrect gasket installation, or an incorrect fastener-tightening program.
5. The pre-launch and production Control Plans define the actual prevention and detection controls, including the characteristic, specification, measurement method, sample frequency, responsible role, reaction plan, and record.
6. PPAP evidence draws on the approved design record, material evidence, dimensional results, validation records, process flow, PFMEA, Control Plan, measurement-system studies, capability evidence, and required customer documentation.

The Ford CSR provides an important general lesson here: a foundation FMEA can preserve organizational knowledge from prior injection-molding programs, but it does not replace the part-specific FMEA. A foundation FMEA might include generic risks such as short shots, sink, warpage, gate vestige, or incorrect resin drying. The ECU-housing DFMEA and PFMEA must still address the actual geometry, sealing concept, material, tooling strategy, and functional risks of this component.

---

The simulated EDV gate-and-deliverable map

The following map is the operating model for the rest of the course. It applies to the ECU housing first, then will be adapted for the door trim and HVAC outlet projects.

G0 — Concept initiation

Decision: authorize planning and assign accountable owners.

Deliverable	Primary framework	Controlled purpose
Assumptions log with confidence levels	ISO/IATF-aligned documented information	Separates public facts, engineering assumptions, and unknowns
Standards and source register	ISO/IATF-aligned document control; CSR input	Identifies applicable sources and source owners
Preliminary risk register	APQP	Makes program, technology, capacity, supplier, packaging, and timing risks visible
APQP timing plan and responsibility matrix	APQP	Defines planned deliverables, owners, and gate dates
Initial supplier and interface strategy	IATF-aligned supplier management	Assigns ownership for components, tooling, tests, and interfaces

Not expected at G0: finished CAD, a completed DFMEA, a Control Plan, or PPAP evidence.

G1 — Program approval

Decision: approve the planned quality path and requirements baseline sufficiently to begin detailed design.

Deliverable	Primary framework	Controlled purpose
Approved requirements baseline and RTM	ISO/IATF design planning; customer inputs	Links each measurable requirement to verification and evidence
Product Assurance Plan or equivalent	APQP	Consolidates quality, reliability, technology, and program risks
Preliminary EBOM and manufacturing concept	APQP; PLM control	Makes product structure and likely process visible
Preliminary special-characteristic candidates	APQP; customer overlay where applicable	Flags characteristics needing deliberate risk and control analysis
Initial validation strategy	APQP; customer requirements	Establishes intended test ownership, timing, and configuration needs
G1 decision log and action tracker	ISO/IATF-aligned documented information	Captures approval boundaries, open items, owners, and due dates

Not expected at G1: a customer PPAP approval. APQP planning is underway; production process capability cannot yet be demonstrated.

G2 — Design feasibility

Decision: confirm that the design is technically feasible and can progress into supplier process development and prototype verification.

Deliverable	Primary framework	Controlled purpose
Controlled CAD baseline, drawings in development, EBOM revision	ISO/IATF design outputs; PLM	Defines the design configuration assessed at the gate
DFMEA and action plan	AIAG-VDA FMEA	Identifies design risks and tracks risk-reduction actions
DVP&R or equivalent verification plan	APQP; customer engineering requirements	Plans analyses, tests, inspections, and demonstrations against the RTM
DFM, DFA, serviceability, and moldability review	APQP	Confirms the design is compatible with intended manufacture and service
Prototype build plan and Prototype Control Plan	APQP; Control Plan methodology	Defines what will be controlled and learned during prototype manufacture
Design-review record and team feasibility commitment	APQP; ISO/IATF design controls	Captures cross-functional technical decision and remaining risks

At G2, the DFMEA should already influence the product. If the team discovers that a rib arrangement risks sealing-land distortion, simply recording the issue in the DFMEA is insufficient. The action should drive a controlled CAD revision, a new analysis or test entry, and a re-review of the affected requirement.

G3 — Process feasibility

Decision: confirm that the planned production process can realize the design and control its critical risks.

Deliverable	Primary framework	Controlled purpose
Manufacturing process-flow diagram	APQP	Defines the full process sequence used for PFMEA and Control Plan development
PFMEA	AIAG-VDA FMEA	Identifies manufacturing failure mechanisms, controls, and improvement actions
Pre-launch Control Plan	Control Plan methodology	Provides enhanced controls while the process is maturing
Process instructions and inspection instructions	IATF-aligned operational control	Translates approved controls into executable shop-floor work
Measurement-system analysis plan	MSA core tool	Ensures needed gauges and tests will be suitable for decisions
Preliminary capability-study plan	SPC and PPAP support	Defines how process capability will be evaluated
Tooling, test-equipment, packaging, and supplier readiness plan	APQP; customer overlay	Controls launch-critical readiness activities

At this gate, the process flow, PFMEA, and Control Plan must agree. If the process flow includes resin drying, injection molding, de-gating, inspection, gasket installation, torqueing, leak testing, and packaging, the PFMEA and Control Plan must cover the relevant risks and controls at those steps. Missing steps are a traceability defect, not a minor formatting issue.

G4 — Launch readiness and PPAP disposition

Decision: determine whether production-intent evidence supports launch and the required PPAP disposition.

Deliverable	Primary framework	Controlled purpose
Significant production-run record	APQP; PPAP support	Demonstrates production tooling, equipment, personnel, environment, and rate as defined by the applicable plan
Production validation test evidence	APQP; customer engineering requirements	Confirms production-intent product meets engineering requirements
Measurement-system study results	MSA	Shows that measurements used for key decisions are adequate
Preliminary process capability results	SPC; PPAP support	Evaluates readiness of the production process, especially for identified special characteristics
Production Control Plan	Control Plan methodology	Defines normal production control strategy and reaction plans
PPAP submission index and customer disposition	PPAP; CSR	Records submission level, configuration, evidence, exceptions, and approval state
Quality-planning sign-off and launch risk register	APQP	Documents the management decision, residual risk, containment, and closure plan

The exact contents and approval path of PPAP are customer-specific. Your simulated project will prepare a PPAP-readiness package, not claim a real customer production approval.

G5 — Feedback, assessment, and corrective action

Decision: determine whether the process is stable enough to exit enhanced launch controls and how learning will be retained.

Deliverable	Primary framework	Controlled purpose
Safe-launch or enhanced-containment exit evidence	CSR and Control Plan, when required	Demonstrates that temporary additional controls can be reduced under defined criteria
Production capability and performance records	SPC; APQP feedback	Shows whether variation and quality performance are improving
Corrective-action records	ISO/IATF nonconformance and improvement	Documents containment, root cause, corrective action, and effectiveness checks
Updated DFMEA, PFMEA, and Control Plan	AIAG-VDA FMEA; Control Plan	Captures new knowledge and prevents recurrence
Lessons-learned record and foundation-FMEA review	APQP; organizational knowledge	Transfers learning to future parts and programs
ECO or change-impact assessment	IATF-aligned change control; PPAP/CSR as applicable	Evaluates the effect of a change on design, process, evidence, and approvals

---

Make every gate a controlled PLM event

Because PLM will be a continuous theme in your three projects, each gate should produce more than a slide deck. Create a controlled gate package with:

• gate identifier, such as G2-ECU-DESIGN-FEASIBILITY;
• product configuration baseline, including CAD version, drawing revision, EBOM revision, and requirements baseline;
• list of reviewed deliverables with revision identifiers;
• red, yellow, or green status for each deliverable;
• explicit decision: approved, conditionally approved, deferred, or rejected;
• open actions with owners, due dates, and escalation route;
• named approvers and dated approval evidence;
• links to related risks, deviations, supplier issues, and ECOs.

A gate may be conditionally approved only when the remaining work is visible, owned, time-bound, and does not undermine a requirement that must be satisfied before proceeding. A “green” gate with unrecorded high-risk actions is worse than a transparent “yellow” gate: it corrupts the program baseline and makes later traceability unreliable.

For the simulated ECU project, create a workbook or database called:

EDV_APQP_Gate_and_Deliverable_Matrix_RevA

Use one row per gate deliverable. Include these columns:

Field	Example
Gate ID	G2
Deliverable ID	DFMEA-ECU-001
Deliverable name	ECU enclosure DFMEA
Framework	AIAG-VDA FMEA
Owner	Mechanical Design Lead
Required input baseline	REQ-ECU-B01, CAD-ECU-BASE-V03
Required decision	Design feasibility approved or actions assigned
Evidence link	Controlled file location or Onshape document/version link
Status	Green, yellow, red, or not applicable
Approval reference	Decision-log item and approver
Open-action reference	ACT-G2-014
Change impact	RTM, CAD, drawings, DVP&R, PFMEA, Control Plan, PPAP readiness

Keep the framework field explicit. It prevents a later reviewer from mistaking an APQP gate-summary item for a PPAP requirement, or treating a CSR-required customer acceptance as merely an internal design-review action.

---

A change scenario: why the distinctions matter

Assume an ECU-housing supplier reports warpage near the gasket sealing land after the initial production trial.

A weak response would be: “Update the FMEA and resubmit PPAP.”

A controlled response separates the roles:

1. Containment and issue definition
   Record the affected lots, part revision, tool condition, measurement method, and observed sealing-land variation. Apply the simulated nonconformance and supplier-issue procedure.

2. Risk analysis
   Update the PFMEA to reflect the process mechanism causing warpage. Review the DFMEA because the process variation may threaten an intended sealing function. Assess whether the existing design is robust enough to manufacturing variation.

3. Control strategy
   Revise the pre-launch or production Control Plan if the control method, frequency, reaction plan, or process parameter needs to change. Confirm that the required gauge or fixture is suitable through the MSA plan or study.

4. Engineering and configuration impact
   If geometry, material, gate location, molding conditions, tooling, or gasket compression changes, open an ECO. Link revised CAD, drawing, BOM, mold-flow evidence, DVP&R entries, and affected requirements.

5. Customer and PPAP impact
   Consult the actual applicable customer change-notification and PPAP requirements. The change may require notification, partial submission, full resubmission, customer approval, or a documented determination that resubmission is not required.

6. APQP and gate impact
   Reassess the G3 or G4 readiness decision. A prior gate may need reapproval because evidence that supported it is no longer valid for the revised configuration.

In this scenario, FMEA identifies and manages risk, the Control Plan governs recurring control, PPAP addresses customer production approval evidence, APQP organizes the recovery work, and ISO/IATF-aligned processes ensure the records, nonconformance, supplier communication, approvals, and change history are controlled.

---

Key takeaways

You should now be able to distinguish the roles of the main automotive quality frameworks:

• ISO 9001 and IATF 16949 govern the quality-management system across the full lifecycle.
• CSRs are customer-specific overlays that can add gate criteria, formats, approvals, and submission requirements.
• APQP structures the product-quality planning work and management gates.
• AIAG-VDA FMEA provides the method for analyzing and reducing design and process risk.
• Control Plans define how production and launch conditions are controlled in practice.
• PPAP is a production-approval submission supported by evidence produced through APQP; it is not a replacement for APQP or ongoing quality control.
• Every gate needs a controlled configuration baseline, decision record, evidence index, risk status, and action tracker.

Next, you will configure an IATF-aligned simulated project record that makes these ideas operational: design responsibility, supplier interfaces, traceability, documented information, validation, nonconformance, and engineering-change control.