Skip to content

Tolerance Stack Analysis

An analytical method — instantiates Tolerance Stack Management

The end-to-end analytical procedure that gathers each contributor's tolerance, selects an accumulation model to combine them, and checks the predicted total against the system's fit requirement.

Several siblings are a specific way of combining variation — a worst-case sum, a root-sum-square, a simulation. Tolerance Stack Analysis is the method that wraps around them: the full procedure of taking a fit requirement, enumerating the contributors and their tolerances, choosing the accumulation model appropriate to the stakes, and returning a verdict on whether the design fits with margin. Its defining role is orchestration and inventory, not a formula — it is method-agnostic about how the deviations combine, delegating that to whichever calculating sibling suits the case, while owning the framing question the whole exercise answers: does the predicted accumulation stay inside the requirement, and by how much? It is the practice that turns a pile of part tolerances and a fit spec into a pass/fail with a margin.

Example

An engineer must confirm that a printed circuit board seats far enough into its edge connector — the board edge has to reach a minimum insertion depth, with a required margin of about 0.5 mm, once the connector, its mounting, the board thickness, and the standoff heights all stack up. Tolerance Stack Analysis is the procedure they run: identify the fit requirement (minimum seated depth), inventory each contributor and its tolerance from the drawings, decide — given this is a non-safety fit with independent, well-behaved contributors — to combine them by root-sum-square rather than worst-case, run that combination, and compare the predicted worst realistic depth against the requirement. The result is a stated margin (say ≈0.3 mm of slack) and, just as important, an explicit record of which model was chosen and why. Had the fit been safety-critical, the same procedure would have selected worst-case instead — the method is the constant; the accumulation model is the choice it makes.

How it works

The method is a disciplined sequence rather than a calculation: state the system-level fit requirement, enumerate every contributor and record its tolerance, choose an accumulation model matched to the risk and the independence structure, run it, and check the combined result against the requirement with an explicit margin. Its distinctive work is the framing and the choice — deciding what the fit limit even is, ensuring the contributor inventory is complete, and selecting the combination rule — while the arithmetic of combining is handed to a sibling. It is what makes a tolerance calculation an analysis (with a documented requirement, inventory, and rationale) rather than a loose number.

Tuning parameters

  • Model selection — which accumulation method the procedure invokes (worst-case, RSS, statistical, simulation). This is the method's central dial, and choosing it wrong makes every downstream number the wrong kind of answer.
  • Inventory completeness — how exhaustively contributors are enumerated; a missed contributor is an omission no accumulation model can recover from.
  • Requirement definition — how precisely the system fit limit is stated, including its margin. A vague requirement makes the pass/fail meaningless.
  • Margin policy — how much slack against the limit counts as "pass"; a design that just barely clears is different from one with comfortable reserve.
  • Analysis depth — a quick single-direction check versus a full multi-axis treatment, traded against the criticality of the fit.

When it helps, and when it misleads

Its strength is that it is the coherent whole the calculating methods live inside: it forces the requirement to be stated, the contributors to be inventoried, and the choice of combination rule to be made deliberately and recorded — so a stack result is auditable rather than a naked number. It is the method that keeps a team honest about what was combined and against what.

It misleads chiefly through its choices. Selecting the wrong accumulation model — root-sum-square where deviations are actually correlated, or worst-case where it needlessly over-constrains and inflates cost — produces a number that is internally correct but strategically wrong, which is the archetype's warning against false precision made concrete. An incomplete inventory or an ill-defined requirement corrupts the analysis regardless of the model. And it is a favorite to run backwards — reverse-engineered from the part tolerances a supplier already offers to declare the design "fits." The discipline is to justify the model choice explicitly, validate the contributor inventory against the physical design, and treat the analysis as a prediction to be confirmed at integration, not a proof.

How it implements the components

  • local_tolerance_inventory — it enumerates each contributor and records its tolerance band, assembling the roster the accumulation then operates on.
  • system_fit_limit — it defines and enforces the requirement the combined deviation is checked against, giving the analysis its pass/fail reference.

It does not itself supply the combination rule — that accumulation model comes from Worst-Case Stack Calculation, Root-Sum-Square Calculation, Statistical Tolerance Analysis, or Monte Carlo Stack Simulation — nor does it draw the contributor loop, which is Dimensional Chain Diagram.

Notes

This method is easy to confuse with its accumulation-model siblings, but the division of labor is the whole point: this mechanism owns the requirement, the inventory, and the choice of rule; the siblings own the rule itself. Keeping that split explicit is what lets a team swap worst-case for RSS on a given fit without re-doing the framing — and what stops "we did a tolerance stack" from hiding which model was actually used.