2. Six Sigma fundamentals for simulation-driven design

Six Sigma is often introduced as a quality methodology, but for a CAE engineer it is more useful to treat it as a disciplined way of turning vague design concerns into measurable, controllable quantities. In a simulation-driven workflow, the "process" being improved is not a production line but the chain of modeling decisions, solver settings, and design parameters that produce predicted performance. Six Sigma gives that chain a vocabulary: CTQ, Y=f(X), DMAIC, and the distinction between common and special cause variation. This chapter establishes those fundamentals and shows where CAE fits inside them.

From Customer Requirement to CTQ

A Critical-to-Quality characteristic (CTQ) is a measurable output whose failure would be unacceptable to the customer or to a downstream function. The essential discipline is that a CTQ must be quantified with a target and specification limits, not stated as an adjective. "The bracket should be stiff enough" is a wish; "first natural frequency ≥ 120 Hz, target 135 Hz" is a CTQ. In simulation-driven design, CTQs are usually derived from physical responses that the FE model can predict: peak stress, first eigenfrequency, maximum deflection, plastic strain, intrusion, temperature at a critical component, or fatigue life.

A practical way to build the CTQ list is to translate each requirement into a response variable, a unit, a target, and upper/lower specification limits (USL/LSL). The table below shows a representative CTQ register for a mounting bracket study. The values are illustrative and chosen for teaching, not measured results.

Two cautions matter here. First, a CTQ must be extractable from the model in a repeatable way — define the node set, the time step, or the mode number in advance, otherwise the "measurement" drifts between runs. Second, distinguish CTQs (what the customer cares about) from process parameters (what you control). Confusing the two is the most common reason a Six Sigma project stalls.

Y = f(X): Separating Outputs from Inputs

The equation Y = f(X) is the conceptual core of Six Sigma. Y is the response you must deliver — the CTQ. X is the set of input variables that influence it. The methodology's leverage comes from the fact that you cannot directly control Y; you can only control the Xs. In a CAE context, the Xs fall into three families:

• Design Xs — geometry parameters such as rib thickness, fillet radius, wall thickness, or material grade. These are the variables a design study actually changes.
• Noise Xs — uncontrolled variation such as manufacturing tolerance, material property scatter, or load variation. These are not set by the designer but must be characterized.
• Model Xs — mesh density, element formulation, contact stiffness, time-step size. These affect the prediction of Y, not the physical product, and must be controlled so they do not masquerade as design effects.

Keeping model Xs separate from design Xs is essential. If mesh density changes between two design runs, the observed change in peak stress is confounded and the conclusion is unreliable. A well-run study freezes model Xs after a mesh-convergence check, then varies only design Xs.

Where CAE Sits in DMAIC

DMAIC — Define, Measure, Analyze, Improve, Control — maps naturally onto a simulation campaign, but the mapping is not one-to-one with "run a model at each stage." The figure below shows how CAE activities distribute across the five phases and, importantly, which phase each activity actually belongs to.

The critical insight is that Measure in a CAE project means establishing a trustworthy baseline model, not merely running the solver once. Before any DOE, verify mesh convergence on the CTQ: refine the mesh until the peak stress changes by less than, say, 3% between two successive densities. Only then is the extracted Y stable enough to compare across design variants. Skipping this step is the simulation equivalent of measuring with an uncalibrated gauge.

Common Cause vs. Special Cause in a Simulation Context

Six Sigma distinguishes variation from common causes (inherent to the process) from special causes (assignable, episodic). In CAE, common-cause variation includes mesh discretization and solver tolerance; special-cause variation includes a misapplied boundary condition, a wrong unit in a material card, or a contact definition that switched off. A control chart of repeated baseline runs — same model, same inputs — should show only common-cause scatter. If a run suddenly deviates, treat it as a special cause and audit the deck before trusting the result. This habit prevents a single bad run from contaminating a DOE.

A Minimal Working Example

Consider the bracket CTQ "peak von Mises stress ≤ 235 MPa." The design Xs are rib thickness t_rib (2.0–4.0 mm) and fillet radius r_fillet (3–8 mm); load F is a noise X with ±10% scatter. A two-factor, three-level full factorial gives nine runs. In LS-DYNA terms, each run is a separate keyword deck with the two parameters substituted, submitted in batch, and the peak stress extracted from d3plot via a Python post-processing script. The Analyze phase then fits a first-order model:

Y_stress = b0 + b1*t_rib + b2*r_fillet + b12*t_rib*r_fillet

If the interaction term b12 is negligible, the main effects tell you which X to prioritize. If t_rib dominates, the Improve phase focuses tolerance and cost attention there. The Control phase freezes the regression model as a fast surrogate so future design changes can be screened without a full solve. This is the practical payoff of Y=f(X): once the relationship is quantified, simulation effort is directed only where it changes the decision.

The next step in building a Six Sigma analytics workflow is to make the CTQ extraction and the Y=f(X) bookkeeping reproducible in Python, so that every run is measured the same way and every parameter change is traceable. That reproducibility is what separates a defensible design study from a collection of screenshots.