Choose your reading route
eduKateSG · Why Mathematics? · Reliability Prediction: Parts-Count Models, Physics of Failure, Calibration and Uncertainty
Start with the question, audit the worked example, or jump to the assumptions and practice. Every chapter stays open for uninterrupted reading.
Understand the question
Define the quantity and follow the mechanism.Route 2 · Chapters 8–14
Reproduce the example
Audit the numbers one step at a time.Route 3 · Chapters 15–21
Check assumptions
See where design and calibration matter.Route 4 · Chapters 22–28
Explore applications
Connect the method to a concrete investigation.Route 5 · Chapters 29–57
Study and verify
Practise, inspect failure cases and read further.
Full chapter index · Practice and checking · Mathematics Learning Hub
Why is mathematics important in reliability prediction? Early design teams often need a provisional estimate before enough field failures exist. Mathematics can combine component assumptions, mission duration, environment and architecture into a conditional forecast. The value lies in exposing what drives the result, not in turning a handbook number into a guarantee.
This guide compares parts-count and part-stress models with physics-of-failure analysis, calibration and uncertainty. It shows how predictions can support comparison and planning while remaining distinct from demonstrated reliability.
Full chapter index
Chapters 1–7 · Understand the question
Chapters 8–14 · Reproduce the example
Chapters 15–21 · Check assumptions
Chapters 22–28 · Explore applications
Chapters 29–57 · Study and verify
- Common misconception: lower predicted rate proves better
- Did You Know?
- Practice questions
- A reporting checklist
- Useful next reading
- Conclusion
- Boundary completeness
- Mission phases
- Load distributions
- Parameter provenance
- Uncertainty propagation
- Importance analysis
- Conservative assumptions
- Verification of implementation
- Field feedback
- Technology change
- Requirements traceability
- Communication to non-specialists
- Ethical decision support
- Transfer to everyday estimates
- Correlation in inputs
- Test planning from sensitivity
- Stop rules for model use
- Independent assurance
- Learning objective
- Time-dependent rates
- Rare common events
- Audit trail
- Final reflection
A reliability prediction answers: under this configuration, use profile, model and parameter set, what performance is expected? It is not an intrinsic label attached forever to a product. State mission time, environment, duty cycle, success criterion and maintenance assumptions. Without those conditions, a decimal reliability value is not interpretable.
Predictions help compare concepts, allocate requirements, identify sensitivity, estimate test burden and plan spares. They are especially useful when design changes remain cheap. Later evidence should update or challenge them. A prediction that is never compared with test and field data becomes an unexamined assumption rather than an engineering learning tool.
A parts-count model groups components, assigns each group a base failure-rate estimate and applies factors for quality or environment according to a documented method. It is quick and can support early alternatives when detailed stresses are unknown. The simplicity also hides architecture, dependencies, part application and mechanism. Treat the result as a coarse model.
A part-stress model uses component type together with electrical, thermal or mechanical stress, environment and quality assumptions. It needs more design detail and can reveal which operating margins matter. It remains empirical and conditional on source data. A precise spreadsheet does not make old or mismatched inputs representative of a new technology.
If independent components in a series mission each have constant exponential failure rate lambda_i, the system rate is the sum. Reliability is exp(-t times the sum). This convenient formula requires every component for mission success, independence and constant rates. Redundancy, dormant failures, common causes and repair require different models.
Suppose 100 identical required parts each have an assumed rate of 2×10^-6 failures per hour. The summed rate is 2×10^-4 per hour. For a 1,000-hour mission, predicted reliability is exp(-0.2), about 0.8187. This is a mathematical illustration, not a real product estimate; the answer is only as defensible as the rate, independence and architecture assumptions.
| Quantity | Value |
|---|---|
| Part count | 100 |
| Assumed rate each | 2×10^-6/hour |
| Summed rate | 2×10^-4/hour |
| Mission | 1,000 hours |
| Predicted reliability | about 0.8187 |
If the assumed part rate is 3×10^-6 instead, the sum is 3×10^-4 and 1,000-hour reliability is exp(-0.3), about 0.7408. A 50% input change does not produce a 50% reliability change because the exponential transformation is nonlinear. Sensitivity analysis makes that relationship visible and directs effort toward uncertain influential inputs.
Failure rates per hour cannot be multiplied by cycles without conversion. Active hours, calendar hours, launches and demands represent different exposure mechanisms. Define whether standby periods count and whether repair occurs during the mission. Unit checks are simple algebra with major practical value; they catch impressive-looking predictions built on incompatible clocks.
A block diagram or fault tree translates component events into system success or failure. Redundancy can improve reliability only if switching, coverage and shared resources are modelled. A component sum silently assumes a series structure. Read reliability block diagrams alongside any parts prediction.
Components exposed to the same heat, power disturbance, software command or supplier defect are not independent simply because there are several of them. A common-cause event can dominate a redundant architecture. Record shared resources and environment, then use a defensible dependence model or sensitivity case. Multiplying independent probabilities can overstate reliability sharply.
Standby components may fail silently, and a switch may fail when demanded. Their reliability depends on dormant exposure, proof-test interval, detection coverage and transition logic. A parts-count total cannot express these sequence details. Use a state, fault-tree or Markov model when the order of events and recovery affects mission success.
Physics-of-failure analysis connects loads and material or component mechanisms: fatigue, creep, corrosion, thermal cycling, electromigration or wear. Models estimate damage or life from stress history and parameters. NASA’s Physics of Failure handbook emphasises applying mechanistic reasoning across the life cycle. The approach needs validated mechanisms and input distributions, not only equations.
CHAPTER 13 OF 57 · Reproduce the example
13. Empirical and mechanistic models complement
Handbook models can provide rapid baselines; physics models can explain how design and environment create damage. Testing and field data calibrate both. Do not frame the choice as one universally correct method. Use the simplest model adequate for the decision, and record why its source population and mechanism are relevant.
Component rates, activation energies, load spectra and quality factors are estimated, not known constants. Represent plausible distributions or ranges and propagate them through the model. A Monte Carlo output should show assumptions and convergence. A narrow answer from fixed uncertain inputs understates knowledge uncertainty even if the arithmetic is exact.
| Layer | Purpose |
|---|---|
| Parts count | early coarse comparison |
| Part stress | application-sensitive estimate |
| Physics of failure | mechanism and stress history |
| System logic | architecture and dependence |
| Calibration | comparison with relevant observations |
Several plausible lifetime families, mechanisms or architecture interpretations may fit limited evidence. Compare them explicitly rather than selecting one silently. Scenario ranges, model averaging or a conservative envelope can reveal decision stability. Parameter intervals within one wrong model do not cover structural uncertainty.
Compare predicted counts or failures with qualification and field observations for similar configurations and missions. Calibration may estimate a correction factor, but it must not hide systematic mismatch. Preserve pre-calibration prediction, data inclusion rules and revised result. Recalibrate when design, supplier or use profile changes materially.
Prediction uses assumptions and existing information; demonstration uses a specified test to gather new evidence against a requirement. A good prediction helps design the test, but it cannot replace observed exposure. Read reliability demonstration testing for the distinction between model forecast and statistical evidence.
Reliability allocation divides a system target into subsystem budgets. Prediction estimates what a proposed design may achieve. Comparing allocation and prediction reveals gaps. Neither step alone proves compliance, and a component budget should not be mistaken for an observed failure rate.
A stress–strength model estimates overlap between load and capacity distributions. It can feed a mechanism-specific probability into a broader prediction. The system model must preserve conditions and dependence. A safety margin based only on means can miss variation in both stress and strength.
A component-rate sum rarely represents software logic, maintenance error or human response adequately. Their failure processes differ from random hardware wear-out. Model them using appropriate evidence and system analysis, and avoid inventing a numeric rate merely to fill a spreadsheet. Missing evidence should remain visible as uncertainty or a separate assurance activity.
A constant exponential rate ignores infant mortality and wear-out. Burn-in, screening and age-dependent mechanisms can change the hazard. If the mission overlaps those regions, use a suitable lifetime or degradation model. The constant-rate assumption may still support a narrow random-failure approximation, but state the range where it is intended.
Temperature, vibration, humidity, radiation and contamination affect mechanisms. A single environment category is a coarse proxy. Translate the actual mission into stress histories where possible, and test sensitivity to severe segments. Predictions based on benign laboratory assumptions should not be presented as field reliability.
Parts sharing a catalogue number can differ by manufacturing lot, process control and screening. Qualification evidence from one supplier may not transfer completely. Track provenance and use hierarchical or scenario models when data span sources. A global correction factor can conceal the supplier that drives risk.
Report a central prediction with a range, influential assumptions and scenarios. Distinguish aleatory variability from epistemic uncertainty where useful. Avoid extra decimal places that exceed evidence. A traffic-light dashboard should link back to equations, data versions and mission definition so reviewers can reproduce the result.
A prediction is often strongest for comparing alternatives analysed with the same method and assumptions. Even then, ranking can reverse under uncertainty. Show the break-even parameter or scenario. If two designs overlap broadly, collect targeted evidence instead of declaring a precise winner.
Build the 100-part example. Vary part count, rate and mission time, and plot reliability. Add two groups with different rates, then test a range for each. Next replace the series assumption with simple parallel redundancy. The activity teaches sums, exponentials, sensitivity and the importance of architecture without claiming a real design result.
Ask the student what evidence supports each input and which assumption most influences the answer. Encourage unit checks and one-at-a-time sensitivity before simulation. The goal is to see a prediction as an argument that can be audited, not as a number produced by authority or software.
CHAPTER 28 OF 57 · Explore applications
28. Common misconception: handbook means certified
A handbook offers methods and reference information; it does not certify a particular design. Applicability depends on technology, environment, quality and mission. NASA standards and guidance place prediction within a broader reliability and maintainability programme. Use competent review and applicable project requirements.
CHAPTER 29 OF 57 · Study and verify
29. Common misconception: lower predicted rate proves better
A lower model output can result from optimistic factors, missing components or different boundaries. Compare like with like and audit architecture. A model that includes more realistic failure mechanisms may predict a higher rate while providing better decision support. Transparency is part of prediction quality.
Two predictions can have the same expected failure count and very different mission risk if one spreads failures independently and the other includes a shared shock. The expected count alone does not describe dependence or consequence. This is why system logic accompanies component arithmetic.
1. Calculate the 100-part example. 2. Recalculate with 3×10^-6 per hour. 3. State the series assumptions. 4. Identify a common cause. 5. Compare parts-count and part-stress methods. 6. Define physics of failure. 7. Explain calibration. 8. Separate prediction and demonstration. 9. Check an exposure unit. 10. Write an uncertainty statement.
Record configuration, revision, success criterion, mission, environment, architecture, data source, model family, component mapping, dependence assumptions, parameter uncertainty, sensitivity, calibration evidence, limitations and owner. Freeze the input file and code version. A reproducible prediction can be improved when new evidence arrives.
Use NASA’s Reliability and Maintainability programme, its R&M standard page and the Physics of Failure handbook record. The historical NASA Parts Application Handbook explains early parts-count and detailed part-stress ideas; check project-specific current requirements before use.
Mathematics matters because reliability prediction links a design, mission and evidence set to a conditional forecast. Parts methods, system logic and physics-of-failure models expose different drivers. The best prediction is traceable, calibrated, uncertainty-aware and tested against later evidence. It guides learning while remaining distinct from proof.
List every function and interface included in the prediction. Missing connectors, power supplies, cooling, sensors or support software can dominate real failures. A boundary diagram prevents favourable omissions. When alternatives use different boundaries, their numerical comparison is invalid even if the formulas match.
Launch, standby, active operation and recovery can impose different stresses and success criteria. Calculate phase reliability conditionally and combine phases with appropriate dependence. A single average rate may blur the short severe phase that drives risk. State whether a failure in each phase ends the mission.
A fixed worst-case load can support margin checking, while a probabilistic load spectrum supports expected reliability. Do not mix deterministic safety factors and occurrence probabilities without a clear model. Preserve rare but credible extremes and dependency between load variables. The load description is often more influential than the lifetime formula.
For every numeric input, record source, date, technology, environment, sample size and transformation. Mark expert judgements. A copied cell without provenance is not evidence. Automated lineage can reveal when one legacy rate drives many current predictions and should be replaced by testing.
Sample parameters jointly when correlations exist. For example, temperature and electrical stress may rise together, and supplier quality factors may affect many parts. Independent sampling can understate tail risk. Report which dependencies were modelled and test alternatives when evidence is weak.
Differentiate or perturb the system output to rank influential inputs. Local sensitivity describes small changes near the baseline; global sensitivity explores the full uncertainty range. A high importance score identifies where information might matter, not automatically where redesign is cheapest or most effective.
Conservatism should be purposeful and visible. Stacking several worst cases can create an impossible scenario, while averaging can hide a severe one. Report baseline and conservative cases separately, with rationale. Decision makers can then see which margin comes from evidence and which from policy.
Independently reproduce a sample of component mappings, equations and unit conversions. Test code with cases that have known analytic answers, including the 100-part example. Review spreadsheet formulas for broken ranges and hidden overrides. Software correctness is part of model credibility.
After deployment, compare observed events and exposure with predicted distributions by configuration. Investigate mismatch before tuning. A lower observed count can result from limited exposure; a higher count can signal a missing mechanism or reporting difference. Use field learning to update the next design, not to retroactively claim the original model was correct.
Historical rates for mature components may not represent new packaging, manufacturing or use. Conversely, new technology can inherit old mechanisms in a new form. Document similarity and use targeted tests. A newer data source is not automatically more relevant; mechanism and application determine transfer.
Link each prediction output to the requirement, mission and configuration it addresses. If a requirement changes from 100 to 1,000 hours, recalculate rather than rescaling a probability linearly. Traceability prevents an old result from being reused under a new question.
Use a plain-language statement: under specified assumptions, the model predicts a range for this mission, and these inputs dominate uncertainty. Show a sensitivity plot or scenario table. Avoid saying the product is 99% reliable without a time, function and evidence boundary.
Optimistic prediction can shift risk to users, maintainers or the public. Include affected stakeholders, consequences and uncertainty in review. Do not allow schedule pressure to erase missing mechanisms or dependencies. A transparent model supports accountability even when the final decision involves values beyond mathematics.
Budget and travel forecasts use the same structure: define the scenario, combine inputs, check units, test assumptions and compare prediction with later outcomes. Reliability prediction teaches students that a forecast is a conditional claim that improves through calibration, not a promise produced by a calculator.
Rates and stresses may share uncertain sources. Sampling them independently can produce combinations that never occur or omit a common high-risk condition. Build a joint scenario or correlation model from evidence, and show sensitivity when dependence is unknown. System prediction is often most fragile in these relationships.
Use importance results to choose tests that reduce influential uncertainty. If thermal cycling dominates, collect temperature and fatigue evidence rather than more data on a low-impact part. Expected value of information can formalise this, but even a ranked sensitivity table improves test focus.
Define conditions that invalidate the prediction: a new supplier, changed mission, failure mechanism outside the model or calibration error beyond a threshold. A model should have an expiry or review trigger. Without one, a provisional early-design estimate can survive into operations long after its assumptions fail.
Have a reviewer reproduce architecture logic, unit conversions, influential inputs and uncertainty propagation. Separate model ownership from approval when consequences warrant it. Independent review is not a ceremonial signature; it should be able to change the model or decision.
Students should understand that prediction is disciplined conditional reasoning. They combine rates, time and system logic, then test how the answer changes. This is more useful than memorising one handbook equation because it teaches how evidence, assumptions and uncertainty shape every forecast.
If hazard changes with age, integrate it over the mission instead of multiplying one constant rate by time. Piecewise phases can approximate changing conditions when justified. Check continuity and units. A constant-rate shortcut should be labelled with its intended range.
A low-frequency external event can affect many components simultaneously. Include it as a separate scenario or basic event instead of distributing its probability across parts. This keeps consequence and dependence visible and prevents false redundancy credit.
Record every manual override, excluded part and chosen factor with author and reason. Hidden adjustments are difficult to review and easy to repeat. A clean audit trail lets the next team understand whether a difference reflects design improvement or simply a changed assumption.
Reliability prediction is valuable when it invites better questions: which mechanism matters, which evidence is weak and which test would change the decision? The mathematics is a map for learning, not a seal of certainty.
Extended practice laboratory
Practice case 1: Series rate
Setup: Use 100 parts at 2e-6 per hour.
Task: Sum rates.
Checking target: Obtain 2e-4 per hour under independence.
Practice case 2: Mission reliability
Setup: Use t=1,000 hours.
Task: Calculate exp(-0.2).
Checking target: Obtain about 0.8187.
Practice case 3: Input sensitivity
Setup: Raise each part rate to 3e-6.
Task: Recalculate reliability.
Checking target: Obtain exp(-0.3), about 0.7408.
Practice case 4: Units
Setup: Compare hours with cycles.
Task: Identify an invalid multiplication.
Checking target: Convert only with evidence.
Practice case 5: Architecture
Setup: Replace series with a redundant branch.
Task: Write the success logic.
Checking target: Include coverage and shared resources.
Practice case 6: Common cause
Setup: Add one shared shock.
Task: Recalculate a scenario.
Checking target: Independence can overstate redundancy.
Practice case 7: Part stress
Setup: Add temperature and load.
Task: Explain factor relevance.
Checking target: Do not borrow unrelated source data.
Practice case 8: Physics of failure
Setup: Choose fatigue or corrosion.
Task: Map stress history to damage.
Checking target: Validate the mechanism and parameters.
Practice case 9: Uncertainty
Setup: Assign ranges to influential rates.
Task: Propagate them.
Checking target: Report a range and decision stability.
Practice case 10: Calibration
Setup: Compare predictions with held-out field data.
Task: Preserve pre-calibration results.
Checking target: Do not hide systematic mismatch.
Practice case 11: Demonstration
Setup: Design a test informed by prediction.
Task: Explain the new evidence.
Checking target: Prediction does not replace exposure.
Practice case 12: Write a conclusion
Setup: State configuration, mission, model and limits.
Task: Separate estimate from proof.
Checking target: Name influential assumptions.