3. Define phase deliverables

In a DMAIC project aimed at crash simulation correlation, the Define phase is not a formality before the "real" engineering work begins. It is the stage where the investigation earns the right to exist: a vague complaint such as "the CAE model does not match the test" cannot be solved, measured, or closed out. The Define phase converts that complaint into three interlocking deliverables — a quantified problem statement, measurable Critical-to-Quality characteristics (CTQs), and an explicit project boundary. Together they answer three questions: What exactly is wrong, how wrong is it, and where are we allowed to look?

These deliverables are tightly coupled. A problem statement without a CTQ has no acceptance criterion; a CTQ without a boundary invites scope creep into every subsystem of the vehicle; a boundary without a problem statement is arbitrary. The practical discipline is to draft all three together and iterate until they are mutually consistent.

1. The Problem Statement: Quantify the Gap, Not the Feeling

A usable problem statement for a correlation project contains five elements: the object (which model, which test, which configuration), the response (the physical quantity being compared), the magnitude and direction of the discrepancy, the reference condition (load case, impact speed, barrier type, occupant or structure variant), and the consequence (why it matters — e.g., design decisions are being made on unvalidated outputs).

Consider a frontal offset impact program. A weak statement reads: "The crash model correlation is poor for the front structure." A Define-phase statement reads: "For the 64 km/h ODB (offset deformable barrier, 40% overlap) load case on the MY25 body-in-white, the CAE-predicted peak longitudinal deceleration at the left sill is 48 g versus 41 g measured (17% high), and the predicted time-to-peak is 12 ms earlier than the test. The discrepancy exceeds the correlation acceptance band and currently blocks sign-off of the front rail gauge change." Note what has been added: a specific load case, a specific response location, a numeric gap with sign, and a business consequence. The statement is falsifiable — anyone can re-run the comparison and check it.

Two practical rules apply. First, express discrepancies as signed relative errors against a stated reference, and state the reference convention explicitly (here, error = (CAE − test) / test × 100%, so a positive value means the model over-predicts). Second, avoid embedding a cause in the statement. "The model is wrong because the spot welds are too stiff" is a hypothesis, not a problem statement; it belongs in the Analyze phase and will bias the investigation if it appears in Define.

2. Measurable CTQs: Turning "Good Correlation" into Numbers

CTQs translate stakeholder expectations into metrics with a target, a specification limit, and a measurement method. For crash correlation, the most defensible CTQs are derived from the response channels that drive the downstream decision — not from every curve in the output deck. A typical set includes:

• Peak value error — relative deviation of the simulated peak from the measured peak for a named channel (e.g., sill deceleration, intrusion at the toe board, steering-wheel displacement).
• Time-of-peak error — absolute difference in milliseconds between simulated and measured peak timing, which captures pulse phasing.
• Pulse-shape metric — e.g., the integral of the deceleration pulse over the crash duration (velocity change) or a correlation coefficient computed over a defined window.
• Intrusion metric — maximum residual deformation at specified measurement points, compared in millimeters.

Each CTQ needs an operational definition: the channel name, the filter (e.g., SAE J211 CFC 60 for structural acceleration), the time window, and the acceptance band. A worked example of a CTQ specification table is shown below; the numeric bands are illustrative and must be replaced by the program's own correlation criteria.

Two cautions are worth stating. First, CTQs must be measurable with the data actually available; if the test channel was recorded at a lower sample rate or with a different filter, the CTQ definition must reflect that, or the comparison is invalid before it starts. Second, avoid CTQs that are merely restatements of the problem statement. The problem statement says the gap is 17%; the CTQ says the acceptable gap is 10%. The CTQ is the acceptance criterion, not the observation.

3. Boundary Definition: What Is In, What Is Out, and Why

Boundary definition is where correlation projects most often fail quietly. A boundary has four dimensions: physical scope (which subsystems and which model regions are under investigation), load-case scope (which impact configurations), data scope (which test runs, channels, and filters are admissible), and temporal scope (the simulation window and the project timeline). Each dimension should be stated as an explicit inclusion or exclusion with a rationale.

For the ODB example, a defensible boundary might read: physical scope includes the front rails, bumper beam, crash boxes, and the left/right sill load paths; the occupant restraint system, airbag timing, and rear structure are out of scope because the CTQs are structural and the restraint model is known to be a placeholder. Load-case scope is the 64 km/h ODB only; the 50 km/h full-frontal and side-pole cases are excluded to keep the investigation tractable. Data scope admits test runs T-03 and T-04 (both valid, same build level) and excludes T-01 (instrumentation fault flagged in the test report). Temporal scope is 0–120 ms of simulation time.

The rationale column matters as much as the inclusion/exclusion itself. A boundary without a reason is a boundary that will be renegotiated at the first inconvenient result. Writing "rear structure excluded because no CTQ depends on it and the rear model is carried over unchanged from the validated predecessor" gives the team a defensible position when someone asks why the trunk floor was not investigated.

4. How the Three Deliverables Fit Together

The relationship among the deliverables is best seen as a chain from observation to acceptance to investigation scope. The problem statement fixes the observed gap; the CTQs define the band within which the gap is acceptable; the boundary defines the region of the model, the load cases, and the data within which the team is authorized to search for causes. The SVG below shows this structure, including the feedback loop in which an infeasible boundary forces a revision of the CTQs or the problem statement.

The feedback loop is not decorative. In practice, the first boundary draft frequently excludes a subsystem that a CTQ depends on — for example, excluding the bumper beam while CTQ-1 is measured at the sill, even though the bumper beam load path feeds the sill pulse. When that inconsistency is found, the correct response is to revise the boundary or the CTQ, not to quietly widen the investigation mid-project. Documenting the revision and its rationale in the Define-phase record keeps the project auditable and prevents the "we also looked at the rear structure" drift that erodes schedule and credibility.

5. A Practical Define-Phase Record

The three deliverables should be captured in a single, short record that the team and the project sponsor sign off before the Measure phase begins. A workable structure is: one paragraph for the problem statement; a CTQ table with operational definitions, limits, and measurement methods; a boundary table with inclusion/exclusion and rationale for each dimension; and a short list of open assumptions (e.g., "test T-03 and T-04 are assumed to be at the same build level; to be confirmed with the test engineer"). The record should be version-controlled alongside the CAE model and test data, because the CTQ limits and boundary will be referenced repeatedly during Analyze and Control.

One final discipline: resist the temptation to make the Define deliverables look complete by filling them with plausible numbers. Every value in the problem statement and CTQ table must trace to a specific test report, channel, or correlation criterion. If a number is an assumption, label it as one. A Define phase that is honest about its assumptions is far more useful downstream than one that is polished but untraceable — because in a correlation investigation, the traceability of the reference values is precisely what determines whether the eventual root cause can be defended.