3. Requirements engineering for airbag systems

Airbag requirements engineering is the discipline of converting a small number of high-level obligations into thousands of verifiable, individually owned engineering statements. A typical frontal airbag ECU program starts with fewer than twenty regulatory and customer top-level requirements, yet the released requirement baseline for the sensing and deployment function can exceed 2,000 items once hardware, software, calibration, diagnostics, and manufacturing constraints are decomposed. The purpose of this chapter is to show how that decomposition is performed in practice and how traceability is maintained so that every deployed airbag can be justified back to a source obligation.

The Three Requirement Sources and Their Authority Order

Airbag requirements originate from three distinct authorities, and they do not carry equal weight when they conflict.

• Regulatory requirements are mandatory and non-negotiable. In the United States, FMVSS 208 defines occupant crash protection performance, including the unbelted and belted test matrix, the 25 km/h rigid barrier condition, and the suppression or deactivation logic required for occupants in rear-facing child restraints. In Europe, UN Regulation No. 94 and No. 95 govern frontal and lateral impact protection, while UN R16 covers safety-belt and restraint-system warnings. These documents specify what performance must be demonstrated, not how the system is built.
• Customer requirements are contractual. An OEM requirement specification typically adds brand-specific targets: deployment thresholds tuned to the vehicle's body structure, seat-position-dependent suppression, telltale timing, and diagnostic coverage. These are binding once the nomination letter and technical specification are signed.
• Internal requirements are self-imposed engineering constraints: component derating rules, EMC margins, software architecture rules, and supplier process capabilities. They exist to guarantee that the regulatory and customer requirements are met with margin.

The authority order is regulatory > customer > internal. When an internal rule conflicts with a customer requirement, the internal rule is relaxed or a deviation is raised; it is never the reverse.

Decomposition: From Obligation to Verifiable Statement

Decomposition is not paraphrasing. A source requirement such as "the restraint system shall protect a 50th-percentile male occupant in a 56 km/h frontal barrier impact" cannot be verified directly at the ECU level. It must be broken into measurable sub-requirements along the system architecture.

A practical decomposition follows the signal chain. Consider the regulatory obligation to deploy the frontal airbag within a defined time window. The decomposition proceeds through four layers:

1. System-level performance: airbag must reach full inflation before the occupant's torso displaces 127 mm forward of the seat reference point, derived from the crash pulse.
2. Function-level timing: the ECU must issue the deployment command no later than 15 ms after impact detection at the defined crash severity.
3. Algorithm-level: the crash discrimination algorithm must classify the event within 8 ms of the first acceleration signal exceeding the arming threshold.
4. Component-level: the accelerometer must have a signal latency below 1.5 ms and a noise floor below 0.5 g RMS over the 0–400 Hz band.

Each layer inherits a timing budget. The sum of the allocated latencies must leave margin against the system-level deadline. In this example, 1.5 ms sensor + 8 ms algorithm + 3 ms squib firing + 2.5 ms margin = 15 ms. If any layer exceeds its allocation, the system-level requirement is at risk and the decomposition must be revisited.

Traceability: The Bidirectional Link

Traceability means that every requirement can be followed upward to its source and downward to its verification. In practice this is maintained in a requirements management tool such as Polarion, DOORS, or Jama, using link types: derives_from, satisfies, verifies, and allocated_to.

The critical property is bidirectionality. Forward traceability answers "if this regulation changes, what must I re-verify?" Backward traceability answers "why does this software function exist?" A requirement with no upward link is orphaned and should be challenged; a source requirement with no downward link is unimplemented.

For airbag programs, traceability must also cross the supplier boundary. The ECU supplier's software requirements trace to the OEM's function requirements, which trace to the regulatory text. When a field issue occurs, this chain determines whether the root cause is a supplier implementation defect, an OEM specification gap, or a regulatory interpretation error.

Practical Decomposition Example: Suppression Logic

Consider the customer requirement that the passenger frontal airbag shall be suppressed when an occupant is classified as a rear-facing child restraint. This decomposes as follows.

The system requirement states that the occupant classification system (OCS) must output a suppression command within 200 ms of the child restraint being placed on the seat. The function requirement allocates this to the weight-sensing and capacitive-sensing fusion algorithm, which must reach a classification confidence above 0.95 within 150 ms. The component requirement specifies that the pressure sensor must resolve 0.5 kg increments and the capacitive sensor must detect a 10 pF change within 50 ms.

Verification is then defined at each level: component bench test for sensor resolution, HIL test for algorithm classification time, sled test with a CRABI 12-month dummy for system-level suppression, and finally the regulatory test matrix for the complete vehicle. Each verification method is linked to the requirement it verifies, closing the traceability loop.

Common Failure Modes in Requirements Engineering

Deliverable: Requirement Decomposition and Traceability Record

The following record structure is used to capture a single decomposed requirement with its full trace chain. It is intended to be completed for each requirement at the point of decomposition, not retrospectively.

Requirement ID:        SYS-AIRB-0042
Title:                 Frontal airbag deployment timing
Source (upward link):  CUST-OEM-0117 (derives_from)
                       FMVSS208-S14.5 (derives_from)
Description:           The ECU shall issue the frontal airbag deployment
                       command no later than 15 ms after impact detection
                       at 56 km/h equivalent severity.
Rationale:             Derived from system-level occupant displacement
                       budget of 127 mm at 50th-percentile male.
Allocation (downward): SW-ALG-0088 (allocated_to)
                       HW-SENS-0031 (allocated_to)
Verification Method:   HIL timing measurement (verifies)
                       Sled test, 56 km/h frontal (verifies)
Timing Budget:         Sensor 1.5 ms + Algorithm 8 ms + Squib 3 ms
                       + Margin 2.5 ms = 15 ms
Status:                Released
Owner:                 Restraint Systems Engineering

Completing this record forces the engineer to confirm that the requirement has a source, an allocation, a verification method, and a quantified budget. When any field is empty, the requirement is not ready for release. This discipline is what separates a requirements database from a requirements engineering process.