3.6.31 · D3Spacecraft Structures & Systems Engineering

Worked examples — Reliability — MTTF, MTBF, exponential failure model

2,277 words10 min readBack to topic

This page is a firing range. We line up every kind of question the exponential reliability model can throw at you — every sign, every extreme value, the degenerate cases, a word problem, and an exam twist — and shoot each one down with a full worked solution. If you can do all ten below, no reliability question on this topic can surprise you.

Before we start, one reminder from the parent note: our whole world here rests on one picture — a curve that starts at height (certain to be alive at launch) and slides down toward (certain to be dead eventually). The number (lambda) is the failure rate: how many failures happen per unit time per surviving unit. Everything below is just reading that one curve at different points.

Figure — Reliability — MTTF, MTBF, exponential failure model
Recall The four formulas we will lean on

The exponential survival curve ::: The mean time to failure ::: Reliability at exactly the MTTF ::: Two units in parallel (works if either works) :::


The scenario matrix

Every reliability problem is one of these case classes. The right-hand column names the worked example that nails that cell.

# Case class What makes it special Covered by
A Forward: given → find plug straight in Ex 1
B Inverse: given → find (or ) must use to "undo" Ex 2
C Degenerate curve at its starting height Ex 3
D Limit curve's floor value Ex 3
E Degenerate a component that never fails Ex 4
F The landmark the "" surprise Ex 5
G Parallel redundancy two curves combined Ex 6
H Series stacking rates add Ex 7
I Word problem (real mission) translate English → math Ex 8
J Exam twist (unit trap / partial mission) hidden conversion or piecewise time Ex 9, Ex 10

We march through them in order.


Worked examples

Forecast: Guess — will be closer to or to ? The exponent is small-ish, so expect something above .

  1. Compute the exponent . Why this step? The whole curve depends only on the single dimensionless number (failures/hour × hours = failures, a pure number). We must build it before touching .

  2. Feed it into . Why this step? This is literally reading the curve's height at — see figure s01, the dot at on the exponent axis.

Answer: , so about a 54.9% chance of surviving.

Verify: ✓ recovers our exponent. Units: exponent is dimensionless ✓. And sits between and as any probability must ✓.


Forecast: High reliability over a long time → we expect a tiny .

  1. Write the equation with the unknown. Why this step? Now is trapped inside an exponent. To free it we need the tool that undoes .

  2. Apply the natural logarithm. The natural log is the exact question "what power must be raised to?" — the inverse of the exponential. That is why we pick and not any other function.

  3. Solve for .

Answer: failures/hour (equivalently MTTF hours).

Verify: Plug back: ✓. Tiny as forecast ✓.


Forecast: At launch the thing works; wait forever and it's surely dead. So expect and .

  1. At : . Why this step? is the degenerate "start of mission" input. The curve must pass through height — a system cannot fail before it turns on.

  2. As : since , the exponent , so . Why this step? This is the curve's floor. It tells us exponential components are never immortal — given enough time, failure is certain.

Answer: and . (Look at figure s01: the curve touches the top-left corner and hugs the bottom axis on the right.)

Verify: ✓; decreasing and bounded below by ✓.


Forecast: No failure rate at all → it should never fail.

  1. Substitute : Why this step? Setting the driver of decay to zero flattens the curve — a horizontal line at height .

  2. Check the MTTF: . Why this step? An infinite expected life is the honest answer: a component that never fails has no finite average failure time. This is the boundary of the model — physically nothing has , but it's the ideal limit.

Answer: , . The idealized never-failing part.

Verify: As , for any fixed ✓, and ✓.


Forecast: Many people guess ("it's the average, so 50/50"). Watch out.

  1. Recall means . So the exponent is Why this step? At the MTTF the exponent always equals exactly , no matter what is. That's why this point is a universal landmark.

  2. Evaluate:

Answer: Only 36.8% survive to their MTTF — not 50%. Because the curve is bent (convex), most of the failures pile up early. This kills the "MTTF = safe lifetime" intuition.

Verify: ✓. Confirms the parent note's Mistake 1.


Figure — Reliability — MTTF, MTBF, exponential failure model

Forecast: Two chances to survive → system should beat a single unit.

  1. Single-unit reliability first. Why this step? Redundancy math is built from the individual survival probabilities, so we compute one unit's chance first.

  2. The system fails only when BOTH fail. Each fails with probability . Because the units are independent, the chance both fail is the product: Why this step? Independence lets us multiply — this multiplication is the whole reason redundancy helps (see figure s02: the tiny purple overlap where both curves are dead).

  3. System survives if not-both-fail.

Answer: (69.6%), well above the single unit's 44.9%. Compare with Series vs. Parallel System Reliability and Redundancy Design.

Verify: ✓, and (redundancy always helps) ✓.


Forecast: More parts in series → worse than any single part → smaller MTTF than the best unit.

  1. For series, multiply survival curves: Why this step? All parts must survive, so multiply — and multiplying exponentials adds their exponents. That is precisely why failure rates add in series.

  2. Add the rates:

  3. Series MTTF:

Answer: hours — shorter than the best single part ( h), exactly as forecast.

Verify: ✓; and ✓. Contrast with the parallel case in Ex 6 (this is the Series vs. Parallel System Reliability split).


Forecast: 12 failures in 60,000 hours is a modest rate; a 1-year job is short. Might just pass.

  1. Estimate from test data. The failure rate is failures per hour: Why this step? Real data gives us empirically — count failures, divide by total operating time. This links to the Poisson Process view of counting rare events.

  2. Convert 1 year to hours. Why this step? The rate is per hour, so the time must be in hours — a units match is mandatory before exponentiating.

  3. Compute reliability.

Answer: (17.3%) — fails the 90% requirement badly. You'd need redundancy (Ex 6) or a much better part. This feeds directly into Mission Design Constraints.

Verify: ✓; ✓; so requirement not met ✓.


Forecast: 6 months is only a small slice of 15 years → expect near .

  1. Convert from the MTTF, keeping ONE unit system. Work in years: Why this step? The trap is mixing months and years. Convert everything to years and the mismatch disappears.

  2. Express the mission time in the same unit. Six months year.

  3. Reliability:

Answer: (96.7%). The unit conversion was the whole exam.

Verify: ✓, and near as forecast ✓. (Cross-check: — same exponent whether you use years or convert to hours, since the ratio is unit-free ✓.)


Forecast: The exponential is famously "memoryless." Guess: the past 4000 hours don't matter.

  1. Write the conditional-survival ratio. The chance of surviving to h given it reached h is: Why this step? Conditional probability = (survive whole)/(survive so far). We divide the two curve heights.

  2. Simplify — the exponents subtract. Why this step? Dividing exponentials subtracts exponents, leaving only the extra 6000 hours. The starting 4000 cancels — that is the memoryless property in one line.

  3. Evaluate:

Answer: — exactly the same as a brand-new unit's chance over 6000 hours. The exponential model has no memory of age (a limitation cured only by the Weibull Distribution / Bathtub Curve wear-out phase).

Verify: ✓, and it equals a fresh ✓.


Recall Self-test

At , what is ? ::: , not . Series of three parts — how do rates combine? ::: They add: . Two parallel units each — system ? ::: . Why can't we add for parallel units? ::: Parallel needs both to fail (a product of failure probs), not a rate sum.