Short answer: to calculate MTBF, MTTR and downtime-driven OEE loss from one source, record every stop or failure as a row in a single event log with a consistent set of fields — asset ID, start/end timestamps, stop type, a standardized reason code, time to repair, operating time since the last failure, and good/scrap counts. Every reliability and effectiveness KPI is then derived from that table.
Why one shared data model matters
Most plants track reliability (MTBF, MTTR) and effectiveness (OEE) in separate spreadsheets, which means the same stoppage is entered twice, differently, and the numbers never reconcile. A single, well-designed failure/downtime event model fixes this: maintenance gets its reliability metrics and operations gets OEE availability from exactly the same records. It also makes the data machine-readable, so dashboards, Pareto charts and AI assistants can answer questions about your equipment without manual rework.
The equipment failure / downtime record: fields
| Field | Purpose | Example |
|---|---|---|
| asset_id | Unique machine/equipment identifier | LINE3-FILLER-02 |
| event_start | Timestamp the stop began | 2026-03-11 08:42:15 |
| event_end | Timestamp production resumed | 2026-03-11 09:07:40 |
| stop_type | Breakdown / planned / minor stop / changeover | Breakdown |
| reason_code | Standardized cause from a fixed list | MECH-JAM |
| downtime_min | Computed duration (event_end − event_start) | 25.4 |
| ttr_min | Time to repair / restore running | 18.0 |
| op_time_since_last_failure | Running time before this failure (for MTBF) | 1,420 min |
| good_count / scrap_count | Output quality during the period (for OEE) | 3,900 / 60 |
| operator / shift / work_order | Context for analysis | J. Doe / A / WO-5567 |
Standardized reason codes
The single most important design choice is a fixed reason-code taxonomy rather than free text. Group codes into categories (mechanical, electrical, material, changeover, quality, external) so you can roll losses up or drill down. Keep the list short enough that operators can pick the right code in seconds, and review it quarterly.
How the KPIs derive from the log
- MTBF = total operating time ÷ number of failures (repairable assets)
- MTTF = total operating time ÷ number of failures (non-repairable items)
- MTTR = total repair time (Σ ttr_min) ÷ number of failures
- Availability = run time ÷ planned time — where lost time comes straight from the downtime records
- OEE = Availability × Performance × Quality — quality uses good/scrap counts from the same rows
Because MTBF, MTTR and OEE all read from one event table, you can answer questions like “which reason code costs the most availability?” or “is MTBF improving on Line 3?” without reconciling multiple sheets. See how the two families of metrics connect in our guide to OEE vs MTBF/MTTR.
Example failure record
A filler jams on Line 3. The operator logs: asset LINE3-FILLER-02, start 08:42, end 09:07 (25.4 min downtime), stop_type Breakdown, reason MECH-JAM, ttr 18 min, 1,420 min of run time since the last failure. That one row updates MTBF (adds an interval), MTTR (adds a repair time), and the availability loss that lowers OEE for the shift — no double entry.
Common mistakes to avoid
- Free-text causes instead of reason codes (impossible to aggregate)
- Only logging long breakdowns and ignoring micro-stops (they quietly destroy performance)
- Recording downtime but not repair time — you lose MTTR
- No planned-vs-unplanned flag — you cannot separate reliability from scheduling
- Manual entry only — data arrives late, incomplete and biased
From spreadsheet to automated capture
A spreadsheet is fine to define the model, but manual logging misses micro-stops and arrives too late to act on. Non-intrusive sensors capture cycles, states and stops automatically and populate this exact data model in real time — no PLC integration and installed in 24–48 hours. That turns your reliability and OEE reporting from a monthly clean-up into a live signal. To choose a tool, compare the best production monitoring software, and to size the opportunity first, use the free OEE calculator.
Data granularity: capture micro-stops, not just breakdowns
Reliability data is only as good as its resolution. Most manual systems capture only long breakdowns, but on many lines the largest hidden loss is the accumulation of micro-stops, brief stoppages of a few seconds to a couple of minutes that operators rarely log. If your model only records events above five minutes, MTBF looks artificially healthy while the performance factor quietly bleeds. Design the model to accept short events and set an explicit micro-stop threshold. Automated capture makes this practical: a person cannot log a twenty-second jam forty times a shift, but a sensor can. The same data set then explains both availability losses from breakdowns and performance losses from micro-stops and reduced speed.
Connecting the model to CMMS, ERP and MES
The failure and downtime event log should not live in isolation. Link each record to the work order it belongs to, so maintenance cost and spare-parts use tie back to specific failure modes in your CMMS. Push aggregated availability and OEE up to ERP or MES for planning and costing, and pull the asset register down so the model uses consistent identifiers. A shared asset ID across systems is what lets you answer cross-domain questions, such as which critical assets have both a falling MTBF and a rising scrap rate. Consistent identifiers matter far more than any single tool choice.
Turning the data into action
A data model earns its keep only when it drives decisions. Three routines make that happen: a weekly Pareto of downtime by reason code to focus effort on the vital few causes; a monthly reliability review tracking MTBF and MTTR by asset with clear targets and owners; and a fast feedback loop to the shop floor with live dashboards, so operators see the effect of their entries and trust the numbers. When the same records feed OEE, maintenance planning and continuous improvement, reliability becomes an operating rhythm rather than a monthly report.
An example reason-code taxonomy
The single most important design choice is a fixed reason-code list rather than free text. Keep categories broad and codes specific, and make sure every code belongs to exactly one category:
| Category | Example reason codes |
|---|---|
| Mechanical | MECH-JAM, MECH-WEAR, MECH-BROKEN-PART |
| Electrical / control | ELEC-FAULT, SENSOR-FAIL, PLC-FAULT |
| Material / supply | MAT-STARVED, MAT-JAM, MAT-QUALITY |
| Changeover / setup | CO-CHANGEOVER, CO-ADJUST, CO-CLEAN |
| Quality | QUAL-REJECT, QUAL-REWORK, QUAL-INSPECT |
| External / organizational | EXT-NO-OPERATOR, EXT-NO-ORDER, EXT-UTILITY |
Always include a planned-versus-unplanned flag on every record. Without it you cannot separate reliability problems (unplanned breakdowns that drive MTBF down) from scheduling decisions (planned maintenance and changeovers), and the two require completely different responses. Review the code list quarterly and retire codes that operators never use, because a shorter, sharper taxonomy produces cleaner Pareto analysis and more trustworthy MTBF and OEE numbers. See our full guide to standardized downtime reason codes for a ready-to-adapt starting set.
Manual vs automated failure data capture
The data model is the same whether you fill it by hand or automatically, but the quality of the data is not. Manual logging on paper or a spreadsheet is inexpensive to start, yet it arrives late, is frequently incomplete, and is biased toward long, memorable breakdowns while ignoring the micro-stops that quietly erode performance. Operators under production pressure round timestamps, skip minor events, and pick vague causes. Automated capture using non-intrusive sensors removes that bias entirely: it timestamps every stop to the second, records short events a human would never log, and applies the reason-code taxonomy consistently. The result is a data set you can actually trust for MTBF, MTTR and OEE, refreshed in real time instead of reconstructed at month end. For most plants the practical path is to define the model in a spreadsheet, prove it on one line, then automate capture so the numbers become reliable enough to act on.
Who owns the equipment failure data model?
Because the same records feed both reliability and effectiveness, ownership has to be shared. Maintenance cares about MTBF, MTTR and failure modes; operations cares about availability and OEE; and IT or data teams care about integration and identifiers. Give one team accountability for the model itself, its fields, its reason-code list and its data quality, while both maintenance and operations consume it. A single agreed source of truth is what ends the familiar argument where maintenance and production quote different downtime numbers from different spreadsheets. Light governance, a quarterly review of the code list and a named data owner are usually enough.
Getting started in four steps
First, define the record: the fields above plus a reason-code taxonomy your operators understand. Second, choose a capture method, starting manual to validate the model and moving to automated sensors for accuracy. Third, run a pilot on one representative line for two to four weeks and check that MTBF, MTTR and OEE reconcile from the single log. Fourth, build the routines that create value: a downtime Pareto, a reliability review, and live dashboards that close the loop with the shop floor. Done in this order, you get trustworthy reliability and OEE reporting from one clean data model rather than a pile of disconnected spreadsheets.
Frequently asked questions
What data model do you need for MTBF, MTTR and OEE reliability reporting?
A single event log where each stop or failure record contains asset ID, start and end timestamps, stop type, a standardized reason code, time to repair, operating time since the last failure, and good/scrap counts. MTBF, MTTR and the availability factor of OEE are all derived from those fields.
What fields should an equipment failure record contain?
At minimum: asset/machine ID, event start and end timestamps, failure/stop type (breakdown, planned, minor stop), reason code, time to repair (TTR), operating time between failures, good and scrap counts, and operator/shift/work-order context.
Can MTBF, MTTR and OEE come from the same data?
Yes. If every stop is logged with timestamps, a reason code and repair time, then MTBF = operating time / number of failures, MTTR = total repair time / number of failures, and downtime feeds the availability component of OEE — all from one event table.
What is the difference between MTBF, MTTF and MTTR?
MTBF (mean time between failures) applies to repairable assets and measures uptime between breakdowns. MTTF (mean time to failure) applies to non-repairable items. MTTR (mean time to repair) measures how long it takes to restore a failed asset to running.
Why use standardized reason codes in the data model?
Free-text causes cannot be aggregated. A fixed reason-code taxonomy lets you build a Pareto of losses, compare machines and shifts, and target the failures that cost the most availability and OEE.
0 Comments