1. Euro NCAP overview and protocol landscap

Euro NCAP (the European New Car Assessment Programme) is an independent consumer-oriented vehicle safety assessment programme, not a regulatory type-approval scheme. Its outputs do not grant legal permission to sell a vehicle; instead, they publish star ratings and detailed test reports that inform buyers, insurers, fleet operators, and increasingly regulators. For a vehicle programme, this distinction matters: homologation proves a vehicle meets a legal minimum, while Euro NCAP measures how far beyond that minimum it performs under standardised, progressively demanding test scenarios. A programme that treats the two as interchangeable will under-resource the safety attribute and discover the gap late, when the body structure and restraint tuning are already frozen.

The programme is governed by a consortium of European motoring and consumer organisations, insurers, and government-backed bodies, with testing performed by accredited independent laboratories. Protocol content is developed through working groups that include OEM technical experts, suppliers, and research institutions, then released on a defined cadence. Because the protocols are consensus documents rather than legislation, they evolve faster than regulation — typically on a multi-year cycle with interim updates — and they can introduce entirely new assessment domains (for example, active safety and, more recently, assisted driving) without waiting for a legislative process. The practical consequence for engineering planning is that the applicable protocol version is a function of the assessment date, not the programme start date or the SOP date alone.

How the rating scheme has evolved

The rating scheme has shifted from a crashworthiness-centric model to a four-pillar structure: Adult Occupant Protection, Child Occupant Protection, Vulnerable Road User (VRU) Protection, and Safety Assist. Each pillar produces a score expressed as a percentage of the available points, and the overall star rating is derived from a weighted combination with minimum performance thresholds — a vehicle cannot reach five stars by excelling in one pillar while failing another. This "no weak pillar" logic is the single most important structural feature for programme planning, because it means the safety attribute cannot be managed as a set of independent workstreams with independent budgets; a deficit in Safety Assist can cap the overall result regardless of body structure performance.

Two further evolutions deserve attention. First, the scoring philosophy has moved from "performance in a defined test" toward "performance in a defined scenario, including the system's ability to avoid or mitigate the event." This is why pedestrian and cyclist AEB, lane support, and speed assistance now carry substantial point allocations. Second, the programme has introduced assessment of assisted driving as a separate grading, distinct from the star rating, reflecting that a vehicle can be safe in a crash sense while its driver-assistance system behaves poorly in terms of collaboration with the driver. Programmes that plan only for the star rating will miss this separate deliverable.

Mapping protocols to vehicle programme milestones

The central planning problem is that Euro NCAP assessment happens at a specific point in the vehicle lifecycle, but the design decisions that determine the result are made much earlier. The mapping below is the working relationship most programmes adopt; the exact gate names differ by OEM, but the dependency structure is consistent.

The most common programme failure is a version mismatch: the vehicle is engineered to the protocol current at concept, but assessed against a protocol released during development. Because protocol updates frequently tighten thresholds or add scenarios rather than remove them, the effect is asymmetric — late changes almost always increase required performance. A disciplined programme maintains a protocol watch item at every gate and explicitly records which protocol revision each requirement traces to.

What this means in practice

Three working rules follow from the landscape described above. First, pin the protocol version to the assessment date and re-validate that pin at every gate; record the revision in the requirement traceability matrix so that a late change can be assessed for impact rather than discovered in the test lab. Second, manage the pillars as a portfolio with thresholds, not as an aggregate score — a programme reporting "we are at 82% overall" without pillar-level margins is not in control. Third, treat the sensor and front-end package as a safety-critical architecture decision, because Safety Assist and VRU performance are largely determined before the first prototype exists.

A concrete example of the version-pin discipline: a programme targeting a five-star result with assessment in a given year should, at concept, identify the protocol revision expected to be in force at that assessment date, extract the point allocations and thresholds for each pillar, and convert them into pillar-level performance targets with margin. If a new revision is released at the architecture gate, the impact assessment should answer one question per pillar: does the new revision change the threshold, the scenario, or the scoring weight? Any "yes" is a change request against the safety attribute, with cost and timing consequences, not a note for later.

With the landscape established — independent programme, four-pillar weighted rating with minimum thresholds, protocol versions tied to assessment date, and a milestone mapping that front-loads the irreversible decisions — the remaining chapters can examine each pillar and each protocol domain in detail, always returning to the question of which programme decision the requirement constrains and when that decision must be made.