Failure codes and ISO 14224: maintenance data you can analyse

Failure codes are fixed codes you use to record, for every failure, what went wrong, how it happened, why, and what was done about it. Free text such as "pump broken" cannot be counted or compared; codes for failure mode, failure mechanism, failure cause and action can. The international standard ISO 14224 provides a worked-out framework for this, with a fixed list of failure modes for each type of equipment, and it is a useful reference well beyond the oil and gas industry.

Why free text doesn't work

Open the closed work orders for any set of pumps and you will find descriptions like "pump broken", "leaking", "not working", "replaced seal" and "see previous WO". For the technician who did the job, that says enough. For anyone who wants to know a year later which failure mode causes the most downtime, it is useless.

Free text has three problems:

• The same failure gets ten descriptions, with typos and abbreviations, so searching and counting don't work.
• Observation, process and cause get mixed up, or half of them are missing. "Bearing failed" doesn't say whether the pump vibrated, stopped or ran hot, nor why the bearing gave out.
• The text mostly describes what was done, such as "replaced seal", rather than what was wrong.

A question like "how often did a shaft seal leak on the cooling water pumps last year, and why?" can't be answered from free text, yet it is exactly the question that leads to an improvement. Codes solve this, provided you set them up well: a limited list, with definitions, filled in when every corrective job is closed. The free text stays for the story; the codes make it countable.

The code chain: what to record for each failure

Useful failure reporting follows a fixed chain, in which each link answers its own question:

• Asset: which asset, and if needed which component, failed? This is the link with your asset register.
• Failure mode: the way the failure shows itself, in other words what you observe: the pump won't start, leaks externally or delivers too little. The IEC's International Electrotechnical Vocabulary defines the failure mode as the manner in which failure occurs, and ISO 14224 adopts that definition.
• Failure mechanism: the process that leads to the failure. It can be physical, chemical or logical: wear, corrosion, fatigue, blockage, a software fault.
• Failure cause: the circumstances that led to the failure. According to the IEC definition of failure cause, a cause can originate in any phase: specification, design, manufacture, installation, operation or maintenance. ISO 14224 also uses the term root cause for it.
• Detection method: how the failure was discovered. ISO 14224 distinguishes ten categories, from periodic maintenance, functional testing and inspection to condition monitoring, production interference and casual observation.
• Action: what was done about it, such as replace, repair, adjust or modify.

The diagram below follows one failure on cooling water pump P-201 through the chain.

Note the order. The leak is what the operator saw on the round, the worn seal faces are what the technician found on dismantling, and dry running at start-up is why it happened. Record only "replaced seal" and you capture the action and lose the rest. The action here also has two parts: the repair and a measure against the cause. Without that second part, the same failure will come back.

One word, two meanings

In RCM and FMECA, a failure mode often sits closer to the cause; in the article on RCM, "the impeller wears" is a failure mode of a pump. In failure reporting it works better to keep the failure mode at what you observe at asset level ("low output"), and to record the worn impeller as the component and mechanism. Both conventions are defensible. Agree on one meaning within your organisation, or two departments will end up measuring different things.

ISO 14224 in brief

ISO 14224 is the international standard for collecting and exchanging reliability and maintenance data for equipment. It was written for the petroleum, natural gas and petrochemical industries and covers the whole operating life of equipment. The current third edition dates from 2016 and was confirmed again in 2022. In the standard's own words, its terms and definitions form a "reliability language" for communicating operating experience, and its failure modes can serve as a "reliability thesaurus".

It distinguishes three kinds of data: equipment data (such as taxonomy and technical attributes), failure data (such as cause and consequence) and maintenance data (such as the action taken, the resources used and the downtime). Data on direct costs are explicitly out of scope.

Taxonomy: from industry to part

The standard arranges equipment in a taxonomy of nine levels. The upper levels describe use and location, from industry down to installation and system. From level 6 down it deals with the equipment itself: the equipment unit, such as a single pump, and below it subunits, maintainable items and parts. Similar units together form an equipment class, such as all pumps.

Failure modes per equipment class

For each equipment class the standard gives its own list of failure modes, each with a fixed abbreviation. Failure mechanisms and failure causes, by contrast, are general lists that apply to all classes. That split makes sense: what you observe differs per type of equipment (a valve does not open, an engine does not start), but wear and corrosion are the same everywhere. The standard also classifies failures by severity: critical (the function stops immediately), degraded (the function still works, but less well) or incipient (an imperfection that could develop into a real failure if nothing is done).

Useful beyond oil and gas

Much of the equipment found in oil and gas, such as pumps, also runs in waste-to-energy plants, factories and distribution centres. There you can use the failure modes from the standard as they are. For equipment the standard doesn't cover, such as an incinerator grate, build your own list on the same principles: failure mode, mechanism and cause kept separate, and a limited number of failure modes per class.

Setting up your own failure code set in 7 steps

1. 1Start with the asset types that matter. Pick the types with the most failures or the highest criticality; how to determine that is covered in asset criticality analysis. One working list for pumps teaches you more than half a list for everything.
2. 2Choose ten to fifteen failure modes per asset type. Read the closed work orders from the past year or two and group what actually occurs. Compare that with the ISO 14224 list for the equipment class, so your codes stay comparable with other sites and with generic reliability data.
3. 3Write a definition with an example for every code. One sentence on what it is, one example and, where needed, what it is not. For example: external leakage of process medium is medium escaping from the pump; the intended drip from a packed gland does not count.
4. 4Keep mechanism, cause and action short and generic. Use the same lists for all asset types, with main groups such as mechanical, material, electrical, instrumentation and external influence for the mechanism, and design, manufacture and installation, operation and maintenance, and management (procedures, documentation) for the cause.
5. 5Make the codes mandatory when closing corrective work. The technician who fixed the failure selects the codes when closing the work order, from pick lists filtered by asset type. Keep it quick: a handful of choices, not ten mandatory fields.
6. 6Keep "other" small and investigate it. Check every month what has been booked as other. If a description keeps coming back, it deserves its own code.
7. 7Train people and maintain the list. Give one person ownership, for example the reliability engineer. Record every change with a date and map old codes to new ones so your trends don't break, and go through the list with the technicians once a year.

Example: failure modes for a centrifugal pump

Part of a starter set for centrifugal pumps could look like this. It follows the ISO 14224 principle of observable failure modes, with the mechanism recorded separately. If you want to compare your data with other sites or with generic reliability data, align the names with the pump list in the standard itself.

From codes to insight: Pareto, bad actors and analysis

Codes only pay off when you use them. The first analysis is usually a Pareto chart: rank the failure modes for an asset type by number, or better still by hours of downtime, and see which few explain most of the failures. In the example below, 80 failures on the cooling water pumps at a chemical plant were coded over two years, spread across six failure modes and other.

External leakage of process medium tops the list with 26 failures. Together with vibration (17) and low output (12), it accounts for 55 of the 80 failures, or 69 per cent. With 4 failures, other is small enough to trust that the codes are working.

Then go one layer deeper. Of the 26 leaks, 19 have worn seal faces as the mechanism, and for 14 of those, dry running at start-up was recorded as the cause. Now you know where the improvement lies: not in a more expensive seal, but in the start-up procedure or dry-run protection. A pattern like this is the starting point for a root cause analysis.

The same data feed the rest of your reliability work:

• Bad actors. Count per asset instead of per asset type, and the few pumps that keep coming back become visible.
• MTBF per failure mode. With codes you can calculate MTBF not just per asset but per failure mode, which tells you more about where maintenance needs to change.
• FMECA. Recorded failure modes and their frequency test the assumptions in an FMECA. Failure modes that occur in practice but are missing from the analysis get added.

You build a Pareto like this from the failure data in your maintenance system; you can see what that looks like on the dashboards page.

Common pitfalls with failure codes

• Too many codes. Nobody reads a pick list of sixty failure modes. The technician picks the first one that roughly fits.
• "Other" as a dustbin. Without a monthly check, other grows into the largest category and you are back to knowing nothing.
• The top code in the list. A pick list with a default value, or one that always starts with the same code, returns that code far too often. Filter by asset type and leave nothing pre-filled.
• Mixing up failure mode and cause. Choose "bearing damage" as the failure mode and "wear" as the cause, and you have recorded the mechanism twice and missed the real cause. Stick to the chain: observation, process, circumstance.
• Codes without explanation. Without definitions and examples, each technician reads a code differently, and you end up comparing apples with oranges across shifts and sites.
• Filling in codes afterwards. Codes picked by a planner a week later from a short close-out note are guesswork. Let the technician who saw the failure choose.
• Data nobody uses. If technicians never see what happens to their codes, filling them in becomes a formality. Show the Pareto at the team meeting and tell them which improvement came out of it.