3. Risk identification methods for restraint programs

Risk identification in an occupant restraint program is not a single activity performed once during design. It is a layered analytical process that must cover component-level failure modes, manufacturing and assembly variation, cross-system interfaces, and the physical behavior of the restraint system during both deployment and non-deployment events. The methods described in this chapter — DFMEA, PFMEA, interface FMEA, boundary diagrams, P-diagrams, and deployment/non-deployment hazard analysis — are complementary. Each answers a different question, and a mature program uses all of them in a coordinated sequence.

DFMEA: Design Failure Mode and Effects Analysis

DFMEA examines how a restraint component or subsystem can fail to perform its intended design function, and what the consequences are at the vehicle level. For a restraint program, the analysis is typically structured around the function of each item: an airbag inflator must produce a specified gas output within a defined time window; a seatbelt retractor must lock within a specified webbing payout; a crash sensor must detect a deceleration pulse and output a signal within a defined latency.

A practical DFMEA entry for an inflator might read as follows. The function is "deliver inflation gas to achieve target bag pressure at 30 ms after trigger." A failure mode is "insufficient gas output." The effect at vehicle level is "reduced occupant restraint, increased head excursion." The severity is rated 9 or 10 because the effect is injury-related. The cause is "propellant grain crack or moisture ingress." The current prevention control is "sealed housing with desiccant and lot-level leak test." The detection control is "sample burst test per production lot." The resulting RPN (Risk Priority Number) is calculated as Severity × Occurrence × Detection, and the team decides whether the value exceeds the program threshold and requires an action.

The key discipline in DFMEA is to separate failure mode from failure cause and from failure effect. A common mistake is to write "airbag does not deploy" as a failure mode when it is actually an effect of several distinct causes: open squib circuit, sensor communication loss, or ECU logic error. Each cause requires its own prevention and detection controls.

PFMEA: Process Failure Mode and Effects Analysis

PFMEA shifts the focus from design intent to manufacturing and assembly. In a restraint program, PFMEA is critical because many field failures originate in processes such as squib crimping, connector seating, wire routing, and inflator loading. The analysis follows the process flow: incoming inspection, subassembly, final assembly, end-of-line test, and packaging.

For example, consider the process step "connect clock spring harness to driver airbag module." A potential failure mode is "connector not fully seated." The effect is "intermittent open circuit, airbag may not deploy." The cause is "operator force insufficient or connector latch damaged." Prevention controls include a tactile click verification and a poka-yoke connector design. Detection controls include an end-of-line continuity check and a visual latch inspection. The PFMEA should also record the process parameter that most influences the failure mode — in this case, insertion force and latch engagement depth — so that the control plan can specify measurable limits.

PFMEA and DFMEA are linked: a design failure mode caused by a manufacturing variation should appear in both documents, with the DFMEA identifying the design weakness and the PFMEA identifying the process control that prevents or detects it.

Interface FMEA

Interface FMEA addresses failures that occur at the boundaries between subsystems, where responsibility is often shared and therefore easily missed. In a restraint system, typical interfaces include:

• Crash sensor to restraint ECU (signal integrity, connector pinout, ground offset)
• Restraint ECU to inflator (squib loop resistance, firing current, short-to-ground tolerance)
• Seatbelt buckle to seat frame (mechanical load path, anchor bolt torque)
• Airbag module to steering wheel or instrument panel (retention, tear seam orientation)
• Occupant classification sensor to ECU (weight threshold, seat position signal)

For each interface, the analysis defines the physical and electrical characteristics that must be compatible, the tolerance stack-up, and the failure mode if the interface is violated. A useful technique is to create an interface matrix that lists every pair of connected items and the parameters exchanged between them. This matrix becomes the input for boundary diagrams.

Boundary Diagrams and P-Diagrams

A boundary diagram is a block diagram that defines the scope of the analysis. It shows the item under study in the center, surrounded by its inputs, outputs, and the external systems it interacts with. For a restraint ECU, the boundary diagram would show power supply, ground, crash sensor inputs, occupant classification inputs, squib outputs, and communication bus lines. The boundary diagram prevents scope creep and ensures that interface effects are not overlooked.

A P-diagram (Parameter Diagram) is a more detailed extension of the boundary diagram. It identifies the intended input signal, the output response, the control factors that can be adjusted, the noise factors that cannot be controlled, and the error states that represent failure. For an airbag inflator, the input signal is the firing current; the output response is gas pressure versus time; control factors include propellant formulation and orifice size; noise factors include temperature, humidity, and aging; error states include no-fire, slow-fire, and over-pressure.

The P-diagram is particularly valuable because it forces the team to distinguish between factors that can be designed (control factors) and factors that must be tolerated (noise factors). This distinction directly informs the DFMEA occurrence rating and the validation test plan.

Hazard Analysis for Deployment and Non-Deployment

Deployment and non-deployment scenarios represent two opposite but equally important hazard classes. Deployment hazards include out-of-position occupant injury, aggressive inflation, and module housing rupture. Non-deployment hazards include failure to fire when required, delayed firing, and inadvertent firing when not required.

A structured hazard analysis for these scenarios typically uses a table with the following columns: scenario description, triggering condition, hazard, severity, existing mitigation, and residual risk. For example:

The hazard analysis should be performed early, before detailed design is frozen, and updated as the design matures. It feeds directly into the DFMEA severity ratings and into the validation plan.

Integrating the Methods

These methods are not independent. The boundary diagram defines the system scope. The P-diagram identifies control and noise factors. The DFMEA uses those factors to assess design risk. The PFMEA addresses manufacturing risk. The interface FMEA covers the gaps between subsystems. The hazard analysis provides the severity context for deployment and non-deployment scenarios. Together, they form a traceable risk identification chain from concept to production.

Practical Guidance for Program Execution

In practice, the sequence matters. Start with the boundary diagram to fix scope. Build the P-diagram to identify control and noise factors. Use those factors to populate the DFMEA. Run the PFMEA in parallel with process development. Perform the interface FMEA once subsystem designs are stable enough to define connectors, tolerances, and signal levels. Finally, consolidate deployment and non-deployment hazards into a single hazard analysis table that references the DFMEA severity ratings.

Two common pitfalls deserve attention. First, teams often treat FMEA as a documentation exercise rather than a decision tool. The value comes from using the RPN and the hazard analysis to drive design changes, test plan priorities, and process controls — not from completing the form. Second, interface failures are frequently missed because no single team owns the boundary. Assigning a responsible engineer for each interface, and reviewing the interface FMEA in a cross-functional session, is the most effective countermeasure.

The methods in this chapter form the analytical backbone of restraint risk identification. When applied together and maintained through design changes, they provide traceable evidence that both deployment and non-deployment risks have been systematically considered, rated, and controlled.