Downtime Data Analysis for Production Lines

What line event data looks like

Any line with a historian or a downtime tracking system already records the raw material for this analysis: one row per stop. ReliaStats calls it line event data (LEDS), the event tape. Formats vary from one system to the next, but the useful content is always the same:

• Where: the machine, place or unit operation that stopped.
• Why: the interrupt or cause code, such as "Misalignment", "Photo Eye" or "Micro Stop".
• When: a stop start and a stop end, or a start and a duration.
• Or already derived: the uptime before the stop and the downtime of the stop, in minutes.

Here are the first rows of the Bottling Line demo file that the ReliaStats tools load by default. It holds 6,000 stop events across five machines, with uptime and downtime already in minutes.

First six rows of bottling-line-demo.csv. Uptime is the run before the stop and Downtime is the length of the stop, both in minutes.

Real exports are messier. Some systems write the end column as a date with no clock time, so the end has to be rebuilt from start plus duration. Many plants export dates day-first (13/10/2024), which a parser expecting month-first will silently scramble. Rows flagged as planned or excluded need to come out. Long non-operating gaps, like a weekend or an idle shift, should not count as time the machine ran without failing. The Interrupt Explorer handles each of these. It reads .xlsx and .csv, works out whether a date column is day-first, rebuilds end times from durations, and offers an optional exclude filter and an abnormal-uptime cutoff.

Why downtime totals and a Pareto aren't enough

The standard downtime report ranks causes by total minutes lost. That is a good place to start and a poor place to stop, for three reasons.

Totals merge frequency and duration

A hundred one-minute stops and a single hundred-minute stop cost the same minutes. On a line with accumulation between machines they are different problems. A buffer rides out the short stops completely and does little about the long one. ReliaSim's guide How big should a buffer be? works through that arithmetic.

Totals ignore when stops happen

A machine that stops again within two minutes of every restart behaves differently from one that runs for an hour between stops, even with the same stop count. Chronic re-stops are a pattern in the timing, and a total can't show a pattern.

Loss is not gain

Removing a failure mode does not simply hand back its downtime. Buffers absorbed some of that loss, and some of it happened while the machine was starved anyway. Some of it cascaded downstream. In ReliaSim's methodology example on the bottling line, Labeler Misalignment accounts for a 6.78% loss but returns a 5.10% gain when removed. Filler Micro Stop accounts for 6.67% and returns 7.97%. The losses are close, the conclusions are opposite, and no ranking of losses could have told you which was which.

Questions like that need a model of the line driven by the statistical behavior of each failure mode. Building one starts with the event data.

Separate failure modes before you fit anything

A machine rarely fails in just one way. In the demo file the Capper stops for twelve different interrupt codes, the Palletizer for twelve and the Filler for seven. A glue-station fault, a jam at the plow and a sub-minute micro stop have different causes, different fixes and different statistical shapes. If you pool them into one "Capper" distribution, you get a blend that fits none of them. You also get a model that can't tell you what happens when you fix one.

So downtime analysis works at the level of the cause group: the place and interrupt code that behave as one failure mode. The ReliaStats desktop app identifies cause groups automatically, and the Explorer lets you drill down from a place to the modes within it.

TTF and TTR: two distributions per interrupt

Each failure mode becomes an interrupt with two distributions:

• Time to failure (TTF): how long the machine runs before this interrupt occurs. It controls how often the line is interrupted.
• Time to repair (TTR): how long the machine is unavailable once it happens. It controls how disruptive each interruption is.

Their means are the MTBF and MTTR, and availability follows from them: MTBF / (MTBF + MTTR). But a simulation doesn't sample the means. It samples the distributions, and the spread and tail of each one decide how often stops outlast a buffer and how often they cluster. The distributions are the model's inputs; MTBF and MTTR are outputs, summaries of what happened that you check a model run against. The companion guide, MTBF vs MTTR: outputs, not inputs, shows why two machines with identical MTBF and MTTR can run a line very differently.

Fitting distributions to downtime data

Once runs and repairs are separated by cause, each sample is fitted against candidate distributions. ReliaStats fits all eight distribution types ReliaSim supports: Weibull, LogNormal, Normal, Exponential, Uniform, Triangular, Johnson SU and Fixed. It tests goodness of fit with Kolmogorov-Smirnov and Anderson-Darling and ranks the candidates. Parameters come out exactly as ReliaSim stores them, including real-space mean and standard deviation for LogNormal, so there is nothing to convert by hand.

A good statistical fit still needs an engineering read. For uptime, the Weibull shape parameter κ tells you where the failure mode sits on the bathtub curve. κ < 1 means early-life failures whose rate falls over time, κ = 1 means random failures at a constant rate, and κ > 1 means wear-out. If a fit puts a mature, well-maintained machine in infant mortality, check the data again before the fit goes into a model. For repair time, check the right tail. A handful of very long stops often matter more to throughput than the typical one.

The ReliaStats workflow: explore, fit, inspect, simulate, validate

1. Explore Interrupt Explorer

   Load a stop log and get an Interrupt Pareto by place, with drill-down into modes. For each cause it shows stops per 24 operating hours, the share of runs that end within a reliability window of the previous restart (2 minutes by default) and the resulting chronic stop rate. It also overlays survival curves R(t) for the whole line and selected causes. Everything runs locally in your browser.

2. Fit ReliaStats desktop app

   Import the raw failure and repair event log. The app identifies cause groups automatically, fits and ranks distributions, and exports a fitted interrupt file for ReliaSim.

3. Inspect Interrupt Designer & Viewer

   Look at any TTF + TTR pair: PDF, CDF and survival curves, a p5–p95 box-and-whisker, a working/failed timeline over a shift and the availability the pair implies.

4. Simulate ReliaSim

   Run the line with each machine carrying its own interrupt signature instead of a shared average.

5. Validate Interrupt Validation

   Plot source availability against simulated availability, interrupt by interrupt, with fixed 95% prediction-interval and 99% confidence-interval bands. Points on the diagonal match history, and points outside the bands show where to refine and re-run.

This is the loop ReliaSim's methodology describes: build from real data, validate that the model matches the line’s measured OEE within 1%, and only then use it for what-if decisions. Quick Start and Designer are free with no account. The Explorer opens with the Bottling Line demo after you sign in. Working with your own files, and desktop fitting, are part of a ReliaStats subscription.

How the output parameterizes a ReliaSim model

The end product of downtime data analysis is an interrupt file with one row per interrupt. Each row carries an uptime distribution type with up to four parameters, a downtime distribution type with up to four parameters, and a maximum downtime. ReliaSim imports it as CSV. From there the simulation reports availability, throughput and efficiency. Blocking and starving emerge from how rates, buffers and interrupts interact, not from rules someone had to write.

That is the difference between OEE simulation and an OEE report. The report describes the losses you had, and the model predicts the losses you will have after a change. It is also why a reliability block diagram falls short for a buffered line. Series and parallel reliability math tells you whether a path is up, not what the accumulation between two machines is holding. For the modeling itself, see ReliaSim's production line simulation software. For help scoping a line, ChiAha offers manufacturing simulation consulting.

Frequently asked questions