4. Requirements engineering for seatbelts

Seatbelt development rarely fails because engineers cannot design a retractor or a buckle. It fails because the requirements that connect a vehicle-level target to a specific component characteristic are missing, ambiguous, or untraceable. A vehicle program may declare "5-star Euro NCAP frontal occupant protection" as a target, yet the seatbelt supplier receives a drawing with a webbing width and a retractor mounting hole pattern — and nothing that explains how those numbers were derived or what happens if they change. Requirements engineering is the discipline that closes this gap.

This chapter covers three interlocking practices: cascading vehicle targets into subsystem specifications, maintaining bidirectional traceability, and controlling change once requirements are baselined. The goal is a requirements set that a supplier can design against, a test engineer can verify, and a change board can safely modify.

From Vehicle Targets to Subsystem Requirements

The cascade begins with vehicle-level attributes that are measurable and owned by the OEM. Typical seatbelt-relevant vehicle targets include:

• Regulatory compliance — FMVSS 208, FMVSS 209, ECE R16, and GB 14166 performance thresholds.
• Consumer rating — Euro NCAP / C-NCAP frontal offset and side impact occupant scores.
• Comfort and ergonomics — retraction force, extraction force, buckle insertion force, and webbing pressure distribution.
• Durability — cycle life, corrosion resistance, and temperature range.
• Packaging and mass — retractor envelope, anchor locations, and system mass budget.

Each vehicle target must be decomposed into requirements that a seatbelt subsystem can satisfy. The decomposition is not a simple division; it requires allocating a portion of the vehicle-level performance to the belt system, then to its components. For example, a vehicle target of "≤ 80 mm chest deflection in the 64 km/h offset deformable barrier test" is allocated across the restraint system: airbag, seat structure, and seatbelt. The seatbelt's share might be expressed as a load-limiter force range, a pretensioner firing time window, and a webbing elongation limit.

A practical cascade uses a requirements allocation matrix. The table below shows a simplified example for one vehicle target.

The critical engineering judgment is the allocation itself. If the load limiter is set too high, chest deflection exceeds the target; if too low, occupant excursion increases and may contact the steering wheel or A-pillar. The allocation must be validated by CAE before it becomes a requirement. A common mistake is to allocate a force value without specifying the extraction distance at which it applies, the tolerance, and the temperature condition — all of which affect the force-displacement curve.

Writing Requirements That Can Be Verified

A well-formed seatbelt requirement has five elements: a unique identifier, a measurable parameter, a target value with tolerance, a condition of measurement, and a verification method. Consider the difference:

Poor:  The retractor shall provide smooth retraction.
Good:  REQ-RET-012: The retractor shall retract 75 % of extracted
       webbing within 3.0 s at 23 °C ± 5 °C, with retraction force
       not exceeding 3.0 N. Verification: bench test per
       OEM-TS-1042, Section 5.3.

The "good" version can be tested, failed, and traced. The "poor" version invites disagreement at the worst possible time — during a design review or a launch crisis.

Requirements should also distinguish between functional (what the belt does), performance (how well it does it), and interface (how it connects to the vehicle). Interface requirements are frequently under-specified: anchor bolt torque, connector pinout for the pretensioner, webbing routing angle, and the electrical resistance of the buckle switch circuit. These details determine whether the subsystem integrates on the first build.

Traceability: The Backbone of Change Control

Traceability means that every subsystem requirement can be linked upward to a vehicle target and downward to a verification activity. Without it, a change to a vehicle target cannot be assessed for impact, and a failed test cannot be traced to the requirement it was meant to satisfy.

A traceability model for seatbelts typically has four layers:

1. Vehicle attribute — e.g., "Euro NCAP frontal score ≥ 14.5 points."
2. System requirement — e.g., "Restraint system shall limit chest deflection to ≤ 80 mm."
3. Subsystem requirement — e.g., "Load limiter force 3.5 kN ± 0.3 kN."
4. Component specification / test case — e.g., "Load limiter torsion bar material and heat treatment; sled test TC-208-014."

The links are bidirectional. Upward traceability answers "why does this requirement exist?" Downward traceability answers "what have we done to satisfy it?" In practice, this is managed in a requirements management tool (DOORS, Polarion, Jama) or, for smaller programs, a structured spreadsheet with unique IDs and link columns. The tool matters less than the discipline of maintaining the links.

The SVG below illustrates the cascade and traceability structure for a seatbelt program, showing how a single vehicle target propagates into subsystem requirements and verification activities.

Change Control After Baseline

Once requirements are baselined — typically at the design freeze or a defined gate — any change must go through a controlled process. The reason is simple: a change to a load limiter force affects the retractor design, the sled test matrix, the CAE model, the supplier tooling, and possibly the vehicle attribute itself. Uncontrolled changes create a mismatch between what was verified and what is built.

A practical change control workflow for seatbelt requirements includes:

1. Change request — identify the requirement ID, the proposed new value, and the reason (e.g., CAE correlation shows chest deflection exceeds target).
2. Impact analysis — trace upward to the vehicle attribute and downward to affected components and test cases. Determine whether the change invalidates existing verification evidence.
3. Review and approval — the change board (OEM engineering, supplier, quality) approves, rejects, or defers. Approval criteria include technical feasibility, cost, timing, and regulatory impact.
4. Implementation — update the requirement, the traceability links, the verification plan, and the affected documents. Notify all stakeholders.
5. Re-verification — execute the tests or analyses required to close the change. Record the new evidence against the updated requirement.

Change control also applies to supplier-initiated changes. If a seatbelt supplier proposes a different webbing material or a modified retractor spring, the OEM must assess whether the change affects any requirement. A material change that alters elongation by 2 % may seem minor, but if the load limiter force was tuned to that elongation, the chest deflection target may be violated. The traceability model makes this visible: the material specification links to the webbing elongation requirement, which links to the load limiter force, which links to the vehicle attribute.

Practical Deliverables for This Phase

At the end of requirements engineering, the seatbelt program should have a complete, baselined requirements specification with the following characteristics:

• Every requirement has a unique ID, a measurable value with tolerance, a condition, and a verification method.
• Every requirement traces upward to at least one vehicle target and downward to at least one verification activity.
• Interface requirements (electrical, mechanical, environmental) are explicitly stated.
• A change control procedure is defined, with a named change board and a documented impact analysis process.
• The requirements set is under configuration management — versioned, access-controlled, and auditable.

The cascade from vehicle target to subsystem specification is not a one-time exercise. It is a living model that must be maintained through design, testing, and production. When it is maintained, a change to a vehicle target can be assessed in hours rather than weeks, and a failed test can be traced to its root requirement without guesswork. When it is neglected, the program relies on tribal knowledge and late-stage firefighting — the most expensive way to develop a seatbelt.