3. Impact assessment workflow

An NCAP protocol change rarely arrives as a single, well-formed requirement. It typically surfaces as a draft regulation update, a Euro NCAP technical bulletin, a C-NCAP management rule revision, or a supplier notification that a test procedure has been reissued. The impact assessment workflow exists to convert that raw signal into a defensible program decision: which vehicle programs are affected, what engineering and validation work is required, how much it costs and how long it takes, and who formally accepts the resulting plan. Without a controlled workflow, the assessment degenerates into ad-hoc email threads, and the program discovers a two-week test-lab bottleneck only after the design freeze.

The workflow below is deliberately structured around evidence gates rather than calendar milestones. Each gate produces a specific artifact that the next stage consumes, and each gate has a defined owner and exit criterion. This makes the process auditable — a critical property when a type-approval authority or internal audit later asks why a particular program was classified as "no impact."

Stage 1 — Change intake and normalization

The trigger is any external or internal notification that a protocol, test procedure, rating scheme, or assessment threshold has changed or is scheduled to change. Intake has three jobs: capture the source, establish the effective date, and normalize the change into a comparable form. In practice this means recording the issuing body (Euro NCAP, C-NCAP, ANCAP, Latin NCAP, NHTSA, or an OEM-internal requirement), the protocol version identifier (for example, a transition from a 2023 to a 2026 assessment protocol), the publication date, the stated application date, and whether a phase-in or grandfathering clause applies.

A frequent failure at this stage is treating a draft as final. Draft protocols circulate for consultation and frequently change thresholds between draft and publication. The intake record should therefore carry a maturity flag — draft, published, or mandatory — and downstream assessment depth should scale with it. A draft triggers a screening-level assessment; a published protocol triggers full assessment.

Stage 2 — Structured change decomposition

Before any program is examined, the change itself must be decomposed into assessable elements. A protocol revision is not one change; it is a bundle. A typical Euro NCAP-style revision might simultaneously modify the frontal offset barrier geometry, raise the pedestrian AEB speed range, introduce a new far-side occupant criterion, and change the star-rating weighting. Each of these has a different engineering owner, a different affected subsystem, and a different validation method.

Decompose into elements with four attributes each: the test or assessment clause affected, the physical or functional vehicle attribute it stresses (structure, restraint, ADAS sensing, HMI, lighting), the direction of change (more stringent, less stringent, newly introduced, withdrawn), and the quantified delta where the protocol states one — for example, "AEB pedestrian test speed increased from 40 km/h to 60 km/h" or "MPDB barrier mass increased by 140 kg." Quantified deltas are what make the later gap analysis objective rather than opinion-based.

Stage 3 — Program screening and applicability

Not every change touches every program. Screening maps each decomposed element against the program portfolio using vehicle attributes already on file: platform architecture, body structure type, restraint configuration, sensor suite, market homologation status, and production lifecycle timing. A program already in series production with no planned facelift may be out of scope for a change that only affects new type approvals; a program at design freeze is highly exposed.

The screening output is a three-way classification per program-element pair: affected, potentially affected, or not applicable. "Potentially affected" is the most dangerous category and must never be left unresolved — it should carry an explicit owner and a resolution date. A useful discipline is to require a written justification for every "not applicable," because this is precisely the record an auditor will request.

Stage 4 — Gap analysis and technical impact

For affected pairs, the team performs a gap analysis: current vehicle performance versus the new requirement, expressed in the protocol's own metric. This is where engineering judgement meets data. If the new pedestrian AEB requirement extends the test speed to 60 km/h and the current sensor and brake actuation chain was validated to 50 km/h, the gap is not merely "10 km/h" — it is a question of whether perception range, detection latency, and deceleration authority remain sufficient at the higher closing speed. The gap analysis should state the current demonstrated performance, the required performance, the margin, and the confidence basis (test data, simulation, supplier declaration, or engineering estimate).

Where data is missing, the gap analysis should say so explicitly and convert the unknown into a validation task rather than an assumption. This is the single most common source of downstream schedule slip: an optimistic gap closure assumed on paper that fails at the test lab.

Stage 5 — Work package definition and estimation

Each confirmed gap becomes one or more work packages: design change, CAE re-analysis, physical validation, supplier re-qualification, documentation and type-approval update. Each work package carries an owner, an effort estimate, a lead time, a cost estimate, and a dependency. The estimates should be traceable to a basis — historical program data, supplier quotes, or test-facility booking lead times — because these numbers feed directly into the program disposition decision.

Stage 6 — Program disposition and sign-off

Disposition is the formal decision on how the program will respond. There are four canonical dispositions: comply within current program (absorb the work into the existing plan), comply with plan change (re-baseline timing, cost, or content), defer to a subsequent model year or variant (where the regulation permits), and accept documented non-compliance risk (only with explicit executive acceptance and a mitigation plan). The disposition must be recorded with the rationale, the chosen work packages, the revised cost and timing, and the residual risk.

Sign-off is a multi-party act, not a single signature. At minimum it involves the program manager (timing and cost), the engineering function owner (technical feasibility), the homologation or certification lead (regulatory validity), and quality or compliance (risk acceptance). Each signatory confirms a specific claim, and the sign-off record should state what each party is attesting to. This prevents the classic failure mode where everyone believes someone else verified the regulatory interpretation.

Worked example: a pedestrian AEB speed-range extension

Consider a hypothetical program at design freeze for a C-segment SUV, with a forward camera-plus-radar suite and an AEB system validated to 50 km/h for pedestrian targets. A published protocol revision raises the pedestrian AEB test speed to 60 km/h and adds a night-time scenario. Intake records the protocol version and effective date. Decomposition yields two elements: speed-range extension and night-time detection. Screening classifies the program as affected on both, since the sensor suite is fixed at design freeze. Gap analysis shows demonstrated performance at 50 km/h with a measured detection range of approximately 55 m; at 60 km/h the required detection range for equivalent braking margin rises to roughly 80 m, exposing a shortfall. Work packages are defined: sensor fusion re-tuning (supplier, 8 weeks), night-time validation campaign (test facility, 6 weeks lead time), and type-approval documentation update. Disposition is "comply with plan change," with a two-month timing shift and a cost estimate carried into the program review. Sign-off records the homologation lead's confirmation that the revised protocol applies to the program's market and build date.

The workflow's value is not in its formality but in its traceability. When a program later faces a schedule or cost challenge, the assessment record shows exactly which change element drove which work package, on what evidence, and with whose approval. That record is what turns an NCAP protocol revision from an unpredictable disruption into a managed, defensible program decision.