2. Vehicle program integration

Euro NCAP publishes assessment protocols, not engineering specifications. A vehicle program cannot be "compliant with Euro NCAP" in the abstract; it can only be compliant against a defined protocol version, a defined test configuration, and a defined set of scoring thresholds. The integration task is therefore a translation problem: convert protocol clauses into verifiable engineering requirements, allocate them to attributes and systems, and bind them to program gates so that evidence exists before the assessment happens. This chapter describes how that translation is structured across concept, design, validation, and Start of Production (SOP).

From protocol clause to requirement: the three-layer decomposition

A workable decomposition uses three layers. The first layer is the protocol clause — the literal text and test procedure, for example an MPDB frontal offset test at 50 km/h with a 50% overlap against a moving deformable barrier, or a far-side occupant protection assessment. The second layer is the engineering requirement — a statement of what the vehicle must do, expressed in physical or functional terms, with a tolerance and a verification method. The third layer is the attribute target — the numeric value the program commits to, with margin, at a named gate.

The critical discipline is that layer two must be written so that it can be verified without re-reading the protocol. "Meet Euro NCAP frontal offset requirements" is not a requirement; it is a pointer. A usable requirement reads: "For the MPDB 50 km/h 50% overlap configuration, occupant restraint must limit driver chest deflection to a value consistent with the protocol's 4-point threshold band, verified by sled and full-vehicle testing at the design freeze and confirmation gates." The threshold band itself is protocol-version dependent and must be quoted from the controlled document, not from memory.

Allocating requirements to attributes and systems

Euro NCAP assessment areas map unevenly onto vehicle attributes. Some are dominated by a single system — pedestrian upper-leg protection is largely a front-end geometry and material problem — while others are cross-attribute. Far-side occupant protection, for example, depends on restraint geometry, seat structure, console stiffness, and the interaction between the two occupants; it cannot be owned by the restraints team alone.

A practical allocation uses an attribute ownership matrix with three columns: the assessment area, the primary owning attribute, and the supporting attributes that must co-sign the target. The matrix is not a reporting artifact; it is the mechanism that prevents the classic failure mode where each attribute optimizes locally and the combined vehicle underperforms in the integrated test. When a target is co-signed, a change in one attribute that degrades the shared target triggers a review rather than a silent regression.

Gate structure: what evidence must exist, and when

Gates are only useful if they are defined by evidence, not by calendar. The following structure is typical for a program targeting a five-star result, and the deliverables are deliberately written as things that can be inspected.

The concept gate is where most integration failures originate. If the pedestrian geometry targets are set as "best effort" at concept, no amount of later CAE will recover the front-end architecture, because the bonnet leading edge height and the available deformation space are fixed by styling and package. Concept deliverables must therefore be geometric and numeric, not aspirational.

Setting attribute targets with margin

Targets should be set from the protocol threshold plus a margin that reflects test-to-test variation and CAE correlation uncertainty. A defensible approach is to derive the margin from the observed spread of repeat tests on comparable vehicles and the correlation delta at the previous gate. If full-vehicle chest deflection correlates with CAE within ±3 mm at design freeze, a target set exactly at the threshold leaves no room for that delta and will produce a nominal pass that fails in confirmation.

Consider a worked example. Suppose the protocol's 4-point band for a given injury criterion corresponds to a normalized value of 0.80, and the program's correlation history shows a CAE-to-test delta of +0.04 (test worse than CAE) with a repeat-test spread of ±0.02. The design target should be set at 0.80 − 0.04 − 0.02 = 0.74, not 0.80. This is a target-setting calculation, not a test result; the numbers are illustrative and must be replaced with the program's own correlation data.

target = threshold - correlation_delta - repeat_spread
       = 0.80      - 0.04              - 0.02
       = 0.74   (normalized injury criterion, illustrative)

The same logic applies to scoring-based areas. Where the protocol awards points in bands, the target should be expressed as the minimum points the program commits to per assessment area, with the margin expressed as the gap to the next band boundary. This makes the target auditable: at each gate, the program can state whether it is above or below the committed band, and by how much.

Making the integration visible: the requirement flow

The diagram below shows how a single protocol clause propagates through the program. It is deliberately drawn as a traceability chain rather than a process flow, because the integration problem is one of maintaining links, not of executing steps in sequence.

The feedback path at the bottom is the part most programs underuse. The correlation delta measured at validation is not only a report card on CAE; it is the input that should recalibrate the margin for the next program and, where the delta is large, trigger a re-examination of the current targets. A program that treats validation as a one-way confirmation loses the most valuable data it will generate.

Common integration failure modes

• Version drift. Requirements written against an earlier protocol version remain in the register after the assessment cycle updates. Mitigation: version field is mandatory and audited at every gate.
• Orphan targets. An attribute target exists with no owning requirement and no verification method, so it can never be closed. Mitigation: the register rejects targets without a clause reference and a verification method.
• Late geometry. Pedestrian and compatibility geometry targets are treated as styling outcomes rather than concept inputs. Mitigation: concept gate requires CAD sections against numeric geometry targets.
• Margin erosion. Targets are progressively relaxed toward the threshold as issues accumulate, until the program is nominally compliant with no margin. Mitigation: target changes require a documented risk acceptance at the gate, not a silent edit.

The output of this integration work is a controlled requirement register, an ownership matrix, a target sheet with margins, and a gate evidence plan — four artifacts that together make the program's Euro NCAP position inspectable at any point between concept and SOP. The next stage of the course applies this structure to the individual assessment areas, beginning with the protocols that dominate the concept phase.