3. Structural design team interfaces

A crash pulse is not a single deliverable that one engineer hands to another. It is a requirement that originates in vehicle-level safety targets, gets decomposed into subsystem and component-level acceleration, intrusion, and force targets, and then lands on the desks of body structure, closures, chassis, restraint, and battery-enclosure teams — each of which interprets it through its own CAE models, test fixtures, and design constraints. The quality of the cascade depends less on the fidelity of the original pulse than on whether the interfaces between these teams carry the right information, in the right form, at the right time. This section maps those interfaces: who owns what, what artifacts cross each boundary, and how to keep the cascade traceable from the full-vehicle pulse down to a single structural gauge or joint.

Why the Interface Is the Weak Point

In practice, pulse cascading failures rarely come from a wrong acceleration curve. They come from interpretation drift: the full-vehicle team delivers a pulse defined at the seat track or sill, the body team applies it at a rocker node with a different boundary condition, the closure team receives a "door intrusion target" with no statement of the pulse it was derived from, and the restraint team tunes an airbag to a pulse that has since been revised. Each team is technically correct within its own scope, yet the chain no longer represents one consistent load case. The interface, not the analysis, is where consistency is won or lost.

Three properties make an interface robust: a single accountable owner per requirement, an explicit artifact contract (what file, what coordinate system, what boundary conditions, what version), and a defined change-propagation path so that a pulse revision reaches every downstream consumer before it is baked into a design freeze.

Roles and Their Requirement Ownership

The table below summarizes the typical ownership split on a passenger-car program. Titles vary by OEM, but the functional boundaries are consistent.

Two rules keep this split workable. First, the owner of a requirement is the owner of its verification — the BIW lead who sets an intrusion target also signs off the sled or subsystem test that demonstrates it. Second, no team may silently re-derive an upstream requirement. If the closure team needs a different pulse boundary, it raises a change request to VSI rather than adjusting the input locally; local adjustment is the most common source of drift.

The Information Flow Across the Cascade

The diagram below shows the cascade as a directed flow of requirement artifacts, with the verification loop returning to the originating owner. Note that the pulse is not simply "passed down": each stage transforms it into a form its consumer can act on — a full-vehicle acceleration-time history becomes a subsystem force target, which becomes a component intrusion limit, which becomes a restraint timing window.

What Crosses Each Boundary: The Artifact Contract

An interface is only as good as the artifact that crosses it. For crash pulse cascading, every hand-off should carry a minimum data set. A practical contract for the VSI-to-BIW boundary, for example, includes:

• Pulse definition: acceleration-time history with sign convention stated (e.g., positive = rearward, vehicle coordinate system), sample rate, and the measurement location (sill, seat track, tunnel).
• Boundary conditions: what is constrained, what is free, and the mass/inertia representation used to derive the pulse.
• Load-case identity: barrier type, impact speed, overlap percentage, and the regulatory or consumer protocol it maps to.
• Allocation rationale: how the full-vehicle target was split among body, closures, chassis, and restraint, and the assumed contribution of each.
• Version and status: revision number, date, and whether the pulse is preliminary, correlated, or frozen.

When this contract is missing, downstream teams fill the gaps with assumptions. A common example: the BIW team receives a pulse but not the measurement location, applies it at the rocker, and produces an intrusion prediction that is 15–20 mm optimistic because the sill pulse is attenuated relative to the rocker. The error is not in the CAE model — it is in the missing field of the artifact.

Change Propagation: Keeping the Cascade Consistent

Pulse requirements change. A barrier revision, a mass increase, or a correlation result from the first sled test can all shift the target. The interface must define how that change travels. A workable rule set:

1. Single change entry point. All pulse revisions enter through VSI, which issues a numbered change notice with an impact statement listing every downstream requirement affected.
2. Downstream acknowledgment window. Each consuming team confirms within an agreed interval (e.g., five working days) whether the change alters its targets, and if so, by how much.
3. Freeze gates. Requirements are frozen at defined program milestones; after freeze, changes require a formal deviation with a verification plan.
4. Traceability record. Every component-level target carries a link to the pulse revision it was derived from, so that a later audit can reconstruct the chain.

Common Interface Failure Modes and Their Symptoms

Recognizing the symptoms early is often more useful than a formal process. The table below pairs typical failure modes with the observable signs that a team can use to detect them.

Making the Interface Operational

The most effective interface discipline is not a document — it is a short, recurring review where the cascade is walked end to end. A 30-minute weekly "pulse cascade sync" attended by VSI, BIW, closures, chassis, and restraint representatives, with a standing agenda of (1) current pulse revision status, (2) open change notices and their downstream impact, (3) any target whose verification is at risk, and (4) correlation findings that may shift a target, catches most drift before it reaches a design freeze. The artifact contract and traceability record make that meeting efficient; without them, the meeting becomes a status report rather than a consistency check.

In summary, the structural design team interface is a requirement-management problem disguised as an engineering problem. The pulse itself is well understood; what determines whether the cascade holds is whether each boundary has a named owner, a complete artifact, and a defined path for change. Teams that treat the interface as a first-class deliverable — with the same rigor applied to a pulse curve — keep their subsystem targets aligned with the full-vehicle intent from concept through verification.