3. Voice of the customer to CTQ flow-down for automotive CAE
In Six Sigma, the Voice of the Customer (VOC) is the starting point of every meaningful improvement project. For automotive CAE, however, the VOC rarely arrives as a simulation-ready requirement. A customer complaint such as "the vehicle booms at highway speed" or a regulatory mandate such as "meet FMVSS 208 occupant protection" must be systematically decomposed into measurable, verifiable simulation targets before any mesh is generated or solver deck is written. This chapter describes how to translate NVH, crash, durability, and thermal customer expectations into Critical-to-Quality (CTQ) characteristics that a CAE team can actually design, simulate, and validate against.
From VOC to CTQ: The Translation Chain
The flow-down follows a consistent logic regardless of discipline: VOC → customer requirement → engineering characteristic → CTQ → simulation metric → acceptance criterion. Each step narrows ambiguity and adds measurability. The critical discipline is that no step may introduce a target that cannot be traced back to the customer or regulatory source, and no simulation metric may be accepted without a defined pass/fail threshold and measurement method.
Consider a concrete NVH example. The VOC is "road noise is intrusive at 80–120 km/h." The customer requirement becomes "interior cabin noise below a competitive benchmark during steady-state cruise." The engineering characteristic is structure-borne and airborne path contribution to the driver's ear position. The CTQ is sound pressure level at the driver's right ear at 100 km/h. The simulation metric is a trimmed-body acoustic response solved in the 20–500 Hz range with a defined excitation spectrum. The acceptance criterion might be ≤ 62 dB(A) overall, with no third-octave band exceeding the benchmark by more than 2 dB. Only at this point does the CAE task become executable.
Discipline-Specific Translation Patterns
Each automotive attribute has its own vocabulary and its own traps during flow-down. The table below summarizes how the four core disciplines typically translate customer language into simulation requirements.
| Discipline | Typical VOC / Source | CTQ Characteristic | Simulation Metric | Acceptance Criterion (example) |
|---|---|---|---|---|
| NVH | "Booming at cruise"; customer clinic ratings | Interior SPL at ear position | Trimmed-body FRF / acoustic response, 20–500 Hz | ≤ 62 dB(A) overall; band margin ≤ 2 dB vs. benchmark |
| Crash | FMVSS 208, Euro NCAP, internal safety targets | Occupant injury criteria | HIC15, chest deflection, femur load from explicit LS-DYNA | HIC15 ≤ 700; chest deflection ≤ 42 mm (example) |
| Durability | Warranty claims; customer duty cycle | Fatigue life of critical welds | Damage sum from transient or frequency-domain fatigue | Damage sum D ≤ 1.0 over 300,000 km duty cycle |
| Thermal | Underhood component limits; cabin comfort | Peak component temperature | CFD conjugate heat transfer, steady-state | ECU case ≤ 105 °C at 45 °C ambient, grade load |
These examples are illustrative and must be replaced with program-specific values. The pattern, however, is stable: every CTQ must name the physical quantity, the location or component, the operating condition, and the threshold.
Making CTQs Simulation-Ready
A CTQ that cannot be measured in the model is not a CTQ — it is a wish. Three properties make a CTQ simulation-ready. First, operational definition: the metric must specify where it is evaluated (node set, component, probe location), under what load case, and with what post-processing method. Second, model fidelity alignment: the CTQ must be achievable within the model's validated frequency range, mesh density, and material representation. Third, tolerance and capability: the acceptance criterion should account for model uncertainty, typically by defining a design margin between the simulation prediction and the physical limit.
For durability, this means the CTQ cannot simply be "the bracket must not fail." It must become "the damage sum at the lower control arm weld toe, evaluated with the measured road load spectrum at the proving ground, must not exceed 1.0 with a 1.5 safety factor." The safety factor is not arbitrary — it reflects the gap between CAE fatigue prediction scatter and physical test scatter, and it should be documented as part of the CTQ definition.
Worked Example: Translating a Crash Requirement
Take a frontal offset crash requirement derived from a customer safety target. The VOC is "protect the occupant in a 64 km/h offset deformable barrier impact." The engineering characteristic is occupant kinematics and restraint loading. The CTQ is HIC15 measured at the driver head CG. The simulation metric is the acceleration-time history at the head CG node extracted from the explicit solver, filtered per SAE J211 Channel Frequency Class 600. The acceptance criterion is HIC15 ≤ 700 with a 10% margin to the regulatory limit.
The flow-down also defines the load case precisely: barrier geometry, impact velocity 64 km/h, overlap 40%, vehicle mass configuration, and restraint firing timing. Without these, two CAE engineers could produce HIC15 values differing by hundreds of points from the same model. The CTQ is only as good as the load case definition attached to it.
Traceability and the CTQ Matrix
In a program with dozens of CTQs across four disciplines, traceability becomes the difference between a controlled development and a chaotic one. A CTQ matrix — sometimes called a requirements flow-down matrix — links each customer or regulatory source to its CTQ, simulation metric, owner, model version, and current status. When a customer requirement changes, the matrix shows exactly which simulations must be re-run. When a simulation fails, the matrix shows which customer expectation is at risk.
Common Failure Modes in Flow-Down
Three failure modes recur in automotive CAE programs. The first is orphan CTQs — simulation targets that no customer or regulatory source can justify, often inherited from a previous platform without re-validation. These consume analysis capacity without protecting the customer. The second is unmeasurable CTQs — requirements such as "the structure should be stiff enough" that cannot be evaluated against a threshold. The third is mismatched fidelity — a CTQ defined at a frequency or load level the model cannot resolve, such as requiring 800 Hz acoustic correlation from a model meshed for 200 Hz.
Detecting these early requires a review gate: before a CAE task is released, the CTQ matrix is checked for source traceability, operational definition completeness, and model capability alignment. A CTQ that fails any of these checks is returned to the requirements owner, not silently simulated.
Practical Guidance for the CAE Analyst
When receiving a CTQ, the analyst should confirm four things before starting work: the physical quantity and its location, the load case and boundary conditions, the post-processing method and filtering, and the acceptance threshold with its margin rationale. If any of these is missing, the correct action is to request clarification, not to assume. Documenting these four elements in the simulation report header makes the analysis auditable and reproducible.
The flow-down from VOC to CTQ is not a paperwork exercise. It is the mechanism that ensures CAE effort is spent on what the customer and regulator actually care about, and that simulation results can be judged against a defensible standard. A well-constructed CTQ matrix turns a vague customer complaint into a precise, testable engineering target — and that is the foundation on which every subsequent DMAIC phase depends.