MTBF and MTTR Are Outputs, Not Inputs: Model the TTF and TTR Distributions

MTBF and MTTR summarize; they don't generate

For one interrupt on one machine, the event data gives you two samples. The uptimes are the runs before each stop, or time to failure (TTF). The downtimes are the lengths of each stop, or time to repair (TTR). MTBF is the mean of the first sample, MTTR is the mean of the second, and availability follows:

Availability = MTBF / (MTBF + MTTR)

A machine with an MTBF of 60 minutes and an MTTR of 5 is available 60/65 of the time, about 92.3%. That number is correct and useful, and it is an output: a summary of runs and stops that already happened. It is the same for every pair of distributions with those two means, whatever their shape. A model doesn't run on summaries. Each run draws individual uptimes and downtimes, and the line responds to each draw, so the model needs the distributions the draws come from.

Same MTBF and MTTR, different line

Illustrative. Solid bars are stop time the buffer covers; the hatched section is stop time that outlasts it.

Illustrative arithmetic under the full-buffer assumption above.

Feed a model MTBF = 60 and MTTR = 5 and it cannot tell A from B. The downstream machine can. None of A's stops reaches it, while B's long stop starves it for 31 minutes in every ten stops. A buffer covers stops up to its size and very little beyond, as ReliaSim's guide How big should a buffer be? explains. The mean threw away exactly the information that decides throughput.

The simplifications cut both ways. A real buffer is not always full when a stop begins, and upstream starvation, blocking and the other machines' interrupts all interact. Working that out for a real line is what simulation is for. The arithmetic only shows that the averages can't settle it.

An exponential built from the mean is still an assumption

When all you have is MTBF and MTTR, the usual way to turn them into model inputs is the exponential distribution, whose only parameter is its mean. That doesn't recover the missing shape; it imposes one. The exponential is memoryless, which describes the random-failure stretch of the bathtub curve, and it commits you to two things:

• Its standard deviation equals its mean. Choosing exponential still chooses a spread.
• The tail is fixed by the mean. For any exponential repair time, about 13.5% of stops last more than twice the MTTR (e⁻²) and about 1.8% more than four times (e⁻⁴).

Exponential is the right model when a failure mode really is random. The data can tell you whether it is.

Weibull uptime: same MTBF, different clustering

The Weibull distribution adds a shape parameter κ (often written β) to the scale λ. κ < 1 is a falling failure rate, κ = 1 is constant and identical to exponential, and κ > 1 is a rising rate, or wear-out (see the bathtub curve). Hold MTBF at 60 minutes and change only the shape:

Illustrative values computed from the Weibull distribution with a mean of 60 min: λ = 60 / Γ(1 + 1/κ) and P(T ≤ t) = 1 − exp(−(t/λ)^κ). Not fitted to any data.

At κ = 0.5, more than one run in five ends within two minutes of a restart, the chronic re-stop pattern the Interrupt Explorer's reliability window is designed to expose. At κ = 2 almost nothing fails that soon. All three rows report the same MTBF. For more on reading the shape, see Weibull analysis of downtime data.

LogNormal downtime: the heavy right tail

Repair times are often right-skewed: most stops are quick resets and a few are real repairs. LogNormal captures that shape, and ReliaStats parameterizes it the way ReliaSim stores it, as a real-space mean and standard deviation. Two repair-time distributions with the same 5-minute MTTR:

Illustrative values computed from the distributions. Not fitted to any data.

Beyond 40 minutes the LogNormal machine has roughly 1 stop in 90, against about 1 in 3,000 for the exponential. If the downstream buffer covers 20 minutes, those long stops are the ones that reach the rest of the line. An input that gets the MTTR right and the tail wrong is wrong about exactly the stops that matter.

Per failure mode, not per machine

A machine's MTBF usually spans several failure modes, and pooling them hides shape in two ways.

The pooled distribution is a mixture. Put quick resets and long mechanical repairs in one downtime sample and you get a shape neither mode has, so any single distribution fitted to it is a compromise. Fit TTF and TTR for each cause group separately. That is the purpose of the automatic cause-group identification in ReliaStats.

The modes compete. Each run ends at the first failure of any mode. A mode's time to failure is therefore the run since the previous stop of any cause, credited to the cause that ended it. Measuring the gap between stops of the same cause instead counts other causes' stops as uptime, which inflates every TTF, flattens survival curves toward 100% and makes per-cause MTBF come out too long.

On a line, observed MTBF is shaped by the line

There is a second reason MTBF belongs on the output side. When failures accrue on operating time, a machine that is starved or blocked isn't running, so it isn't failing either. How often it actually stops depends on the machines around it and the buffers between them.

So a machine's MTBF measured on the line, and the line's own MTBF and availability, are results of the whole system. A simulation that takes per-mode TTF and TTR distributions as inputs produces them, including the blocking and starving that shaped them. Feeding an MTBF measured on the line back in as an input can count those interactions twice.

The workflow: distributions in, MTBF and OEE out

1. Line event data historian or stop log

   One row per stop: where, why, and when it started and ended.

2. TTF and TTR per failure mode Interrupt Explorer · ReliaStats

   Separate cause groups and measure each run on the any-cause clock.

3. Fitted distributions ReliaStats desktop app

   Fit the eight ReliaSim distribution types, rank them with Kolmogorov-Smirnov and Anderson-Darling, and export for ReliaSim.

4. Model ReliaSim

   Each machine carries its own interrupt signature; blocking and starving emerge from rates, buffers and stops.

5. Results checked against history Interrupt Validation

   MTBF, MTTR, availability and OEE come out of the run and are compared with the historian, interrupt by interrupt.

With the model and the data handled correctly, a line model can match measured OEE to within 1%. Tom Lange rebuilt the food-plant model from Fischel and Lange's WSC 2020 paper in ReliaSim and validated it to within 1% of both the plant's measured OEE and the original published model (case study). ReliaSim's methodology validates each interrupt individually, because a model can match the overall total while getting individual failure modes wrong.

What MTBF and MTTR are still good for

Keep them. They are the right KPIs for a report, they give availability directly, and they are a good sanity check: a fitted distribution's mean should land near the sample mean, and a validated model's MTBF and MTTR should land near history. What they can't do is stand in for the distributions as inputs.

Distributions are what make OEE simulation predictive rather than descriptive. They are also the part a reliability block diagram can't carry through a buffer. To model the line, see ReliaSim's production line simulation software or ChiAha's manufacturing simulation consulting. For how the averages relate to uptime, see availability vs reliability.

Check the shape in your own data

• Interrupt Explorer: survival curves R(t) by cause, plus the share of runs that end inside the reliability window.
• Interrupt Designer (free): set a TTF + TTR pair and see p5, Q1, median, Q3 and p95 in a box-and-whisker, the PDF, CDF and survival curves, and a working/failed timeline over a shift that you can switch between mean, median, Q1, Q3 and p95 scenarios.
• ReliaStats desktop app: fit all eight ReliaSim distribution types per cause group, rank them with Kolmogorov-Smirnov and Anderson-Darling, and export for ReliaSim.

For the full process, from event log to validated model, see downtime data analysis for production lines.

Frequently asked questions