Equipment Failure Record Data Model: Fields and Codes

Key takeaways

• A downtime event, a work order and a failure record are three objects with three keys. One stop can produce no failure record, and one work order can produce two.
• Code the failure mode, never the symptom. "High vibration" is not a failure mode, and a Pareto built on symptoms sends the action to the wrong department.
• The is_failure flag doubles the MTBF of the pump below: 225.0 hours counting every job, 450.0 hours counting only failures.
• Two repairs nobody wrote down lift the reported MTBF from 300.0 to 450.0 hours with nothing changed on the floor, and availability barely moves.
• One repair left open drops the reported MTTR from 135.0 to 100.0 minutes. Both errors flatter you, which is why neither gets reported.

A stop, a job and a failure are three different objects

Most systems blur these three into one screen, and every reliability number downstream inherits the blur.

A downtime event is a period when the asset was not producing. It exists whether or not anything broke.

A work order is authorised work on one asset, with an assignee, hours and a cost.

A failure record is a statement about one named component: it stopped performing its function, in a specific way, for a specific reason.

These are separate because they do not line up one to one. Four asymmetries break the link in real plants.

The second row is the one that surprises people. A redundant unit can fail without the line ever noticing, and that failure still belongs in your MTBF.

The third row is why the codes cannot live as four extra columns on the work order. Four columns force the technician to pick the more impressive of two findings.

Where each object lives and how they join

The downtime event is usually owned by the machine data layer, because a stop is detected at the machine.

Keep event_id nullable on the work order. A job on a standby asset has no stop to point at, and forcing a link there is how plants end up inventing downtime.

The operator facing side of this is a different design problem with its own rules, covered in our guide to downtime reason code design. That list is picked in seconds at the machine, while everything on this page is written afterwards by the person who did the repair.

For the surrounding schema, the asset, meter, plan, request and part tables, see our CMMS data model. This page goes deeper on the one table that model only sketches.

The failure record, field by field

Sixteen fields carry a failure. Eight are filled in when the record is created, and eight when the work is signed off.

Mandatory when the record is created

component_id is the field that decides whether this data is ever useful. Without it you can say the pump failed four times, which is not something anyone can act on.

Point it at a real row, never at typed text: a child asset in the hierarchy, or a row in a component list per asset class. Our asset hierarchy data model covers how deep to go.

Filled in at close

operating_hours_at_failure is the field with the highest value per keystroke, and almost nobody stores it. It is what turns a list of repairs into a component life history.

With it you can say this seal ran 4,200 hours and the one before it ran 11,000, which is a question you can take to a supplier. Without it you only have dates, and dates include every week the machine stood still.

Take the value from the meter at downtime_start, not at the moment somebody typed the record. A record written three days later carries three days of the wrong number.

The severity scale

Severity is not downtime. A ten minute stop on a safety interlock is S1, and a four hour repair on a redundant pump that never stopped the line is S4.

Keep it to four classes, and never let it be typed as free text. An S1 list must be readable in a management review without opening a work order.

verified_by is the field auditors ask for. It records that a second person confirmed the asset performs its function again, the only evidence you have that the remedy worked.

Failure mode, cause and symptom are not the same field

These three answer three different questions, and merging them is the single most expensive mistake in failure data.

A symptom is an observation: an alarm, a noise, a smell, a reading over a limit. It belongs in the description and in detection_method, and it belongs nowhere near the failure_mode field.

A failure mode is always stated about a named component and always describes a loss of function. "Bearing seized" is a mode, "vibration high" is not.

A cause is why the mode occurred: lubricant starvation, misalignment, erosion, wrong part fitted, end of service life.

One symptom, two causes, two different actions

Take two events on the same pump family, both reported as a vibration alarm over the limit.

Code the symptom and both events land in a bucket called "vibration". The Pareto then reads "vibration, two events" and the plant goes shopping for a vibration analyser.

Code the mode and the cause, and the two events split into a lubrication problem and a materials problem. Neither is solved by buying an instrument.

Scale that up. In one example quarter across a pump fleet, fourteen events were logged as high vibration, and recoding them properly gave nine bearing failures from lubrication, three impeller erosions and two misalignments after a coupling change.

The test is simple. If the entry in failure_mode could have been written by somebody standing outside the machine, it is a symptom and it is in the wrong field.

Three level coding: problem, cause and remedy

Three code axes answer three questions: what was wrong, why, and what was done about it.

Each axis is a tree, not a flat list, because a flat list long enough to be precise is too long to be picked correctly.

Level 1 is not a code the technician picks on the problem axis. It comes from component_id and it decides which level 2 and level 3 lists are shown at all.

That single move is what keeps the menus short. A pump technician never sees a winding insulation code, and a drive technician never sees a cavitation code.

How long each list may be

The categories are the level you report on, so they must be fixed for the whole plant and changed only by a formal decision.

The detail level is where a component class differs from another, and it is the only level a reliability engineer should be allowed to extend.

These tables are a working model to copy, not a published standard. Reliability data standards exist, ISO 14224 among them in the process industries, and if a customer or a corporate rule names one, adopt its code names and map your lists onto it.

Problem and cause codes for a centrifugal pump

Problem and cause codes for an electrical drive

The remedy list is plant-wide

Problems and causes are specific to the component class. Remedies are not, because "replace it" means the same thing on a pump and on a drive.

One plant-wide list of about eleven remedies is enough, and it makes the most valuable query in the scheme possible.

That query is: which cause keeps coming back after the same remedy. A PMP‑C03 that returns three times after an R07 is telling you the lubrication route is the problem, not the bearing.

R10 deserves its own row and its own review. A machine that keeps being reset with no defect found has a real fault that nobody has caught yet, and burying it inside "repair" hides it forever.

The is_failure flag and what it does to MTBF

Not every job on a machine is a failure. Preventive work, inspections, calibration, modifications and cleaning are all work orders, and none of them is evidence that the asset is unreliable.

A single boolean on the record settles it. is_failure = yes means the component lost its function unexpectedly.

Row two is the one people argue about. A cracked impeller found during a PM is still a failure, because the component lost its function and it was not planned to.

The work was planned. The failure was not, and that is the distinction the flag has to carry.

Set it by default from the work order type, then let the technician override it with a logged reason.

Worked example: one pump, one quarter

Asset PMP‑04, a centrifugal process pump, from 1 April to 30 June 2026.

The run hour meter read 21,300.0 h at the start and 23,100.0 h at the end, so operating time is 1,800.0 hours.

1. The eight work orders

Failure downtime is 90 + 240 + 150 + 60 = 540 minutes, which is 9.0 hours across 4 failures.

Non-failure downtime is 120 + 90 + 30 + 150 = 390 minutes, or 6.5 hours. All eight jobs together stopped the pump for 930 minutes, 15.5 hours.

2. MTBF and MTTR

• MTBF = operating time ÷ failures = 1,800.0 ÷ 4 = 450.0 hours.
• MTTR = failure downtime ÷ failures = 540 ÷ 4 = 135.0 minutes, or 2.25 hours.
• Read strictly, "between" failures includes the repair: (1,800.0 + 9.0) ÷ 4 = 452.25 hours.

The two MTBF definitions differ by 0.5% here, and the gap widens on assets with long repairs. Put the definition in the report header, as our guide to mean time between failures explains.

MTTR has the same problem. 135.0 minutes is downtime per failure, and wrench time per failure would be a smaller number on the same four jobs (mean time to repair).

3. Availability, computed two ways

• From the means: 450.0 ÷ (450.0 + 2.25) = 450.0 ÷ 452.25 = 99.50%.
• From the raw hours: 1,800.0 ÷ (1,800.0 + 9.0) = 1,800.0 ÷ 1,809.0 = 99.50%.

These two agree because they are the same arithmetic written twice. Treat the match as a check on your transcription, not as proof the definition is right.

The genuine cross-check comes from the other side of the plant, the time ladder that the machine data layer keeps.

1,872.0 minus 72.0 is 1,800.0, and that figure has to equal the meter delta. If it does not, one of the two systems is wrong and you have found a real defect rather than a rounding error.

The OEE availability factor from the same ladder is 1,800.0 ÷ 1,872.0 = 96.15%.

So the same pump honestly reports 99.50% on the reliability page and 96.15% on the OEE dashboard. The first counts only failures, the second counts every hour the line was planned to run.

4. Falsification one: two repairs nobody recorded

A fitter cleared a blocked seal flush line in 25 minutes and freed a sticking level switch in 35 minutes, both without opening a work order.

The truth is therefore 6 failures and 600 minutes of failure downtime, not 4 and 540.

The reported MTBF is 50% higher than reality, and nothing on the floor changed. The pump did not get better, the paperwork got thinner.

MTTR moved the other way, because the two missing repairs were short. Under-recording short jobs inflates MTBF and inflates MTTR at the same time.

Now look at availability: 99.50% against 99.45%, a gap of 0.05 points. Availability is almost blind to missing records, so a stable availability number is no evidence that your failure capture is complete.

The detector that does work is a count: failure records per asset per month, plotted next to unplanned stops from the machine data. When one falls and the other does not, the records are the problem (unplanned downtime).

5. Falsification two: one record left open

WO‑26‑0834, the 240 minute bearing job, was completed but its failure record never got a downtime_end.

The reliability report filters on closed records, so that row disappears from both the numerator and the denominator.

MTBF rises by 33.3% and MTTR falls by 25.9%, from one missing timestamp on the single longest repair in the quarter.

Both moves look like an improvement, which is exactly why nobody queries them. The longest repairs are also the ones most often left open.

The fix is a rule, not a reminder. A reliability report must print the number of open failure records alongside every figure, and refuse to age a record past seven days without an owner.

6. What actually holds the example together

Three fields carry every number above: is_failure, the downtime window and a meter reading at each end of the period.

Drop any one and you are counting work orders. Counting the flag alone, with every job included, gives MTBF 1,800.0 ÷ 8 = 225.0 hours and MTTR 930 ÷ 8 = 116.25 minutes.

That is exactly half the correct MTBF. An MTBF quoted without stating the failure rule is not a number anyone can compare with anything.

One more thing the example glosses over. If WO‑26‑0834 had found a failed bearing and a failed coupling, you would hold five failure records against four stops.

The MTBF denominator is the number of stops, while the component Pareto uses the number of records. Report both counts in the header so nobody has to guess which one produced the mean.

Detection method and detected-by

How a failure was found is a fact about your maintenance programme, not about the machine. It is also the only way to prove that inspections and condition monitoring pay for themselves.

Five values is enough, and the fifth one has to exist. A plant with no "failure in service" option simply records everything as an operator report and loses the whole measurement.

detected_by holds the identity: an employee number, or the system that raised it. A named person for a human finding, and a system identifier for an automatic one.

What the split buys you

Take an example quarter across a pump fleet, with 34 failure records.

The three records found by inspection or condition monitoring averaged 45 minutes of downtime. The nineteen found by the stop itself averaged 210 minutes.

That gap is the entire business case for the inspection route, and it is invisible the moment detection_method is missing or is a free text box.

The same table is also an honest scorecard. Nineteen out of 34 found by the stop itself says the preventive maintenance schedule is not catching much, whatever its completion rate looks like.

Where readings come from instruments rather than rounds, the method field is what separates a genuine condition based maintenance catch from a lucky operator.

What the failure record feeds

Four consumers depend on this one table, and each needs a different subset of the fields.

The warranty claim is the one that pays for the whole exercise in a single afternoon. A manufacturer rejects a claim for a missing running hour count far more often than for a missing invoice.

Assemble it from the asset record and the failure record together: serial number, commissioning date, warranty expiry, operating_hours_at_failure, the failure mode, the parts fitted and the dates.

The customer audit is the other one. An automotive or pharmaceutical customer asks which failures touched the equipment that made their batch in week 18, and the answer has to come back in minutes with a name against each verification.

Five questions to ask a vendor about failure capture

1. Can one work order carry two failure records? Ask them to add a second failed component to a job in front of you, with its own codes and its own severity.
2. Is there an is_failure flag, and can we see its rule? Ask which work order types default to yes, whether a technician can override it, and whether the override is logged.
3. Do the code lists filter by component class? Picking a pump must not show a winding insulation cause, and picking a drive must not show cavitation.
4. Is the meter reading captured at the moment of failure? Ask whether operating_hours_at_failure comes from the meter at downtime_start or from whenever the record was typed.
5. How does the report treat records with no downtime_end? Ask to see the open record count printed on the reliability report, because that is the difference between a measurement and a flattering guess.

Question five is the one that separates the tools. Any system can show you an MTBF, and very few will show you how much of the underlying data is incomplete (equipment maintenance software).

How Fabrico helps

Fabrico is an OEE platform with a full CMMS built in, so the failure history and the machine data sit in the same place.

Work orders run through a status workflow with approvals, shifts, assignment and time tracking, and your team records the repair from the iOS, Android or web app, with QR codes on machines and parts to open the right record without typing.

Parts are booked against the work order from inventory, machine registry files and history stay with the asset, and the analytics include MTTR and MTBF by machine alongside downtime from PLC connections, IoT sensors and AI cameras.

What Fabrico does not do: there is no formal root cause investigation in the product, no cause tree and no auditor-ready investigation dossier, and it never forces problem, cause and remedy codes before a work order can be closed.

It is the data foundation under an RCA, not the RCA tool, and the coding scheme here is a specification, not a feature list.

Want your failure history captured as data instead of as descriptions? Book a 30 minute demo with a Fabrico consultant, no commitment, or contact us with your questions.