1. Occupant safety systems engineering land
Occupant safety is one of the most heavily regulated and standards-dense domains in automotive engineering. A restraint control module that deploys an airbag a few milliseconds late, or a seat-belt reminder that fails to satisfy a regional mandate, can trigger recalls, legal liability, and — most importantly — preventable injury. Systems engineering exists in this domain to make safety intent explicit, verifiable, and defensible from the first regulatory clause to the final calibration dataset. This chapter maps the landscape: which regulatory frameworks impose legal obligations, which industry standards define accepted engineering practice, and why bidirectional traceability is the connective tissue that holds the whole evidence chain together.
Regulatory frameworks: the legal floor
Regulations define the minimum performance a vehicle must demonstrate before it may be sold in a given market. They are legally binding, type-approval oriented, and typically verified through prescribed test procedures rather than through process audits. For occupant safety, the most consequential families are:
- FMVSS (United States) — Federal Motor Vehicle Safety Standards issued by NHTSA. FMVSS 208 governs occupant crash protection (frontal barriers, unbelted and belted configurations, airbag suppression logic); FMVSS 209/210 cover seat-belt assemblies and anchorages; FMVSS 213 addresses child restraint systems; FMVSS 225 defines child restraint anchorage (LATCH). Compliance is self-certified, but NHTSA audits and can require recalls.
- ECE Regulations (UN/Europe and adopting markets) — UN R94 (frontal impact), R95 (lateral impact), R16 (safety belts), R14 (belt anchorages), R44/R129 (child restraints). These are type-approval regulations: an approval authority tests and certifies, and the manufacturer must demonstrate conformity of production.
- China GB standards — GB 11551 (frontal impact occupant protection), GB 20071 (lateral impact), GB 14166 (safety belts). Increasingly aligned with UN regulations but with distinct test conditions and timelines.
The engineering consequence is that regulatory clauses are not background context — they are requirements sources. Each test procedure implies a set of derived requirements: dummy type and seating position, impact velocity and barrier geometry, allowed injury criteria (HIC, chest deflection, femur load, neck Nij), and pass/fail thresholds. A well-run program traces every one of these derived requirements back to the specific clause that motivated it, and forward to the test or simulation that demonstrates satisfaction.
Industry standards: the accepted way to engineer safety
Where regulations say what must be achieved, standards describe how to engineer and evidence it. The occupant safety landscape draws on several interlocking standards:
| Standard | Scope relevant to occupant safety | Traceability implication |
|---|---|---|
| ISO 26262 (parts 3–8) | Functional safety of E/E systems; ASIL classification; safety goals, FSRs, TSRs | Safety goals must trace to technical safety requirements and to verification evidence |
| ISO 21448 (SOTIF) | Safety of the intended functionality; performance limitations and triggering conditions | Scenario-based requirements trace to validation coverage arguments |
| ASPICE (Automotive SPICE) | Process capability for system and software development | Bidirectional traceability is an explicit process attribute (SWE.1–SWE.6, SYS.2–SYS.5) |
| SAE J1739 / AIAG-VDA FMEA | Failure mode and effects analysis | Failure modes link to requirements and to design verification actions |
| ISO 20653 / IEC 60529 | Ingress protection for restraint electronics | Environmental requirements trace to test specifications |
Two standards deserve particular attention because they shape the traceability model directly. ISO 26262 introduces a requirement hierarchy — safety goal → functional safety requirement → technical safety requirement → hardware/software requirement — where each level must be allocated to an architectural element and verified by an independent method. ASPICE, meanwhile, assesses whether an organization can demonstrate that this hierarchy is consistently maintained across projects, not just on paper for one program. In practice, auditors and assessors sample the trace links: pick a random software unit, walk up to its technical safety requirement, then to the safety goal, and check that the verification evidence at each level exists and matches.
Why traceability is the backbone of safety-critical development
Traceability in occupant safety is not a documentation chore; it is the mechanism by which three distinct questions get answered under audit and in the field:
- Completeness — Have all regulatory clauses and safety goals been decomposed into implementable, verifiable requirements? An untraced clause is an unaddressed obligation.
- Consistency — Does the deployed calibration or software build correspond to the requirements that were verified? A changed deployment threshold without a corresponding requirement and test update is a latent nonconformity.
- Impact analysis — When a requirement changes (e.g., a new UN R94 amendment tightens chest deflection limits), which design elements, test cases, and safety analyses are affected? Trace links make this a query rather than an archaeology project.
A practical way to see the chain is to follow one requirement end to end. Consider a derived requirement from FMVSS 208: "The frontal airbag shall be suppressed when the occupant classification system detects a rear-facing child restraint in the front passenger seat." This traces upward to the regulatory clause and to a safety goal ("prevent airbag-induced injury to a child in a rear-facing restraint"), sideways to the occupant classification sensor specification and the suppression logic design, and downward to verification: a suppression test matrix covering child-restraint types, seat positions, and sensor fault states. If any link is missing, the argument has a gap that a regulator, assessor, or plaintiff's expert will find.
The landscape as a connected system
The figure below shows how the three layers interact. Regulatory frameworks and industry standards both feed the requirements baseline; the baseline is decomposed through the ISO 26262 hierarchy into design and verification artifacts; and traceability links form the bidirectional evidence chain that connects every artifact back to its source obligation.
What this means for the working engineer
Three practical consequences follow from this landscape. First, requirements are sourced, not invented: every occupant-safety requirement should carry an origin — a regulatory clause, a standard-derived safety goal, a customer specification, or a documented internal decision. Requirements without a source are candidates for deletion or for escalation to a formal assumption. Second, verification is planned alongside requirements: the moment a requirement is written, its verification method (test, analysis, inspection, simulation) and acceptance criterion should be identified, because that pairing is what makes the trace link meaningful. Third, change is the normal case: regulations are amended, calibrations evolve, and suppliers deliver updated components. A traceability model that supports impact queries turns a potentially catastrophic missed update into a routine review.
The remainder of this course builds on this foundation. Subsequent chapters will move from the landscape into the mechanics: how to write verifiable occupant-safety requirements, how to structure the trace model across the ISO 26262 hierarchy, how to link FMEA and test evidence, and how to audit and maintain the chain through production and field updates. The organizing principle throughout is the one established here — every safety claim must be traceable to its source obligation and to the evidence that supports it.