ISO 14224, and building an asset hierarchy that holds up
ISO 14224 gives maintenance data a common structure: nine taxonomy levels, equipment classes with defined boundaries, and standard codes for failures and maintenance. What the standard covers, how to apply it in a CMMS, and what to do about the register you already have.
Key takeaways
- ISO 14224 is a standard for collecting and exchanging reliability and maintenance data. It supplies a taxonomy, equipment boundaries and standard codes, not a hierarchy you copy into your CMMS.
- The taxonomy has nine levels. Levels 1 to 5 say where the equipment sits and what it is part of, levels 6 to 9 break the equipment down, and level 6, the equipment unit, is where most data is reported.
- Equipment boundaries decide what counts as part of the pump. Without an agreed boundary, failure rates from two sites, or two areas of one site, cannot be compared.
- Functional location and equipment are different things. The location is the position in the process, the equipment is the physical item that can be swapped out of it.
- Codes are worth only what the person closing the work order can apply. Short lists, tied to the equipment class, beat long lists nobody uses.
Every maintenance analysis rests on the same question. Did these records describe the same kind of equipment, failing in the same way, recorded the same way? Where the answer is no, the mean time between failures, the bad actor list and the spares model are all describing the data entry rather than the plant.
ISO 14224 exists to make that answer yes. It is the international standard for collecting and exchanging reliability and maintenance data, and it supplies the parts that have to be agreed before data means anything: a taxonomy for classifying equipment, boundaries for what each class includes, and standard codes for failures and maintenance.
This guide covers what the standard actually contains, how the nine taxonomy levels land in a CMMS hierarchy, how functional locations and equipment differ, which codes are worth enforcing, and how to approach a register that was built without any of it. The day to day consequences of getting it wrong are covered in master data is boring, until your schedule falls apart.
What the standard is, and what it is not
ISO 14224:2016 is titled collection and exchange of reliability and maintenance data for equipment. It came from the petroleum, petrochemical and natural gas industries, and it grew out of the same work as the OREDA reliability data project, which is why published reliability data sets and the standard share a taxonomy.
What it gives you is a common language. Equipment classified the same way, boundaries drawn the same way, failures described with the same words, and a defined minimum set of data to collect. That is what makes one site's numbers comparable with another's, and one year's comparable with the next.
- It is not a CMMS design standard. It says nothing about how SAP, Maximo, Pronto or any other system should be configured.
- It is not a hierarchy to copy. The taxonomy is a classification, and your hierarchy has to serve work management as well as reliability analysis.
- It is not mandatory outside contracts and regulators that call it up, and few sites implement all of it. Most adopt the taxonomy, the boundaries and the failure coding.
- It is not a substitute for a maintenance strategy. It structures the evidence that strategies such as FMECA are built from.
The standard is worth reading for the boundary diagrams and the code lists alone. Those two parts settle more arguments than any policy document.
The nine taxonomy levels
The taxonomy runs from the industry down to the individual part. Levels 1 to 5 describe use and location, which is the business context an asset sits in. Levels 6 to 9 subdivide the equipment itself. The example below follows one lubrication pump through all nine.
| Level | Name | Example |
|---|---|---|
| 1 | Industry | Mining |
| 2 | Business category | Iron ore |
| 3 | Installation | Mine site and processing hub |
| 4 | Plant or unit | Crushing and screening plant |
| 5 | Section or system | Primary crushing circuit |
| 6 | Equipment unit | Primary crusher |
| 7 | Subunit | Lubrication system |
| 8 | Component or maintainable item | Lube oil pump |
| 9 | Part | Pump bearing |
- Level 6, the equipment unit, is where most reliability data is reported, because it is the level at which equipment classes and failure rates are defined.
- Level 8, the maintainable item, is usually where work orders and job plans land, because it is the level maintenance is actually performed on.
- Levels 1 and 2 rarely appear in a CMMS. They matter when data is exchanged or benchmarked outside the organisation.
- The nine levels are a classification, not a mandate to build nine levels of hierarchy. Most operations collapse them into four to six usable ones.
Equipment classes and boundaries
An equipment class groups equipment that fails in similar ways, such as centrifugal pumps, electric motors, heat exchangers, valves, compressors, cranes and conveyors. The class is what gives you a sensible failure mode list, a comparable failure rate and a template strategy, so it deserves more care than the free text description it usually gets.
The boundary is the part most registers never define. It says what is inside the equipment unit and what is not. Does the pump include its driver, its coupling, its base frame, its local starter, its instrumentation and its lubrication system? Both answers are defensible. Only one can be used consistently.
Get it wrong and the numbers quietly lie. A site that counts motor failures inside the pump boundary will show pumps failing far more often than a site that does not, and neither is wrong about its own plant. ISO 14224 supplies boundary diagrams for each class, which are worth adopting even where the rest of the standard is not.
Write the boundary down once, per equipment class, and put it in the data standard. It is the cheapest thing you will ever do for the credibility of a failure rate.
Functional locations and equipment
Most systems separate the place from the thing. A functional location is a position in the process, such as the lube pump position on the primary crusher. The equipment record is the physical pump currently installed there, with its serial number, warranty and its own history.
The separation earns its keep when items rotate. Send a pump to the workshop and fit the spare, and the location keeps the history of that duty, while the pump keeps the history of that machine. Analysis then answers both questions people actually ask, which are whether this position keeps eating pumps and whether this pump keeps failing wherever it goes.
Terminology differs by system. SAP PM uses functional locations, equipment, assemblies and bills of material. Maximo uses locations, assets and classifications. The concepts map closely enough that the design questions are the same, and the answers belong in a written data standard rather than in the head of whoever configured it.
| Record | What it represents | What it carries |
|---|---|---|
| Functional location | A position in the process that exists whether or not equipment is installed in it | Process context, tag number, criticality of the duty, parent in the hierarchy |
| Equipment | The physical item installed in a location, which can be removed and reinstalled elsewhere | Serial number, manufacturer and model, warranty, repair history |
| Classification and characteristics | The attributes that describe an equipment class | Rated duty, size, speed, material, voltage and the fields analysis needs |
| Bill of materials | The parts that make the item up | Part numbers and quantities, which is what makes planning a lookup rather than a memory test |
Designing a hierarchy people can use
A hierarchy has two jobs that pull in different directions. Work management wants to find things quickly and roll costs up sensibly. Reliability analysis wants consistent classes and boundaries. A good design serves both by being shallow enough to navigate and consistent enough to group.
- Aim for four to six levels that people actually use, between the site and the maintainable item. Depth beyond that gets abandoned within a year.
- Keep depth consistent within an equipment class. If one conveyor is broken down to idler sets and the next stops at the drive, nothing about conveyors can be compared.
- Structure by process, not by organisation. Departments and contracts change more often than the plant does.
- Stop where work orders stop. If nobody would ever raise a job against it, it is a part, not a location.
- Put attributes in fields, not in descriptions. A description of "PUMP CENTRIF 150MM 2POLE SPARE" is four data fields crammed into a text box.
- Decide how rotables and floats are handled before the first swap, not after the history has already gone to the wrong record.
Tags, naming and reference designations
Most plants already have a tag number system on their drawings, in the control system and on the equipment itself. The CMMS should use it rather than invent a second one. Two numbering systems for the same pump is a permanent translation cost, and it is why work orders end up on the wrong equipment.
Where a new system is being designed, IEC 81346 gives structuring principles and reference designations, which set out how to build tags that carry function, product and location consistently. New projects are the moment to get this right, because retro-tagging an operating plant is expensive and disruptive.
Descriptions need a standard too. A noun first convention, with modifiers in a fixed order, makes the register searchable and duplicates visible. "Pump, centrifugal, lube oil" sorts and groups. "Lube oil pump (new one)" does neither.
The codes that make data comparable
Coding is where the standard meets the person closing a work order at the end of a shift, which is why it fails more often than it fails anywhere else. The fields below are the ones that carry analytical weight.
| Field | What it answers | Example |
|---|---|---|
| Failure mode | How the item failed to perform its function, from a list defined for the equipment class | Fail to start on demand, external leakage, vibration, overheating |
| Failure severity | How badly, separating a critical failure from a degraded or incipient one | Critical, where the function was lost completely |
| Detection method | How the failure was found | Operator round, condition monitoring, functional test, on demand |
| Failure mechanism and cause | What physically happened, and why it happened | Fatigue from misalignment, or blockage from contamination |
| Maintenance activity | What was done about it | Replace, repair, adjust, refit, overhaul, inspect, test |
| Maintenance data | What it took and what it cost the operation | Hours by trade, parts used, downtime, production consequence |
- Tie the code list to the equipment class, so a fitter closing a pump work order sees pump failure modes rather than every code on site.
- Keep lists short. A list of a dozen options gets used, a list of eighty gets whatever is at the top of it.
- Separate the failure mode from the cause. What failed and why are different fields, and merging them loses both.
- Check coding quality in the same review where the numbers are discussed, so the crew sees where their entries end up.
- Where the CMMS cannot enforce the list by class, put the class code in the job plan so the correct list travels with the work.
Every code you enforce has a cost at the end of a shift. Enforce the ones you will genuinely analyse, and delete the rest from the screen.
What good data actually buys
None of this is worth doing as an end in itself. The structure pays for itself when it answers questions that were previously arguments.
- Reliability by equipment class, so the MTBF and MTTR of your pumps can be compared with your other pumps, with the fleet, and with published data on the same taxonomy.
- Bad actor lists that survive scrutiny, because the failures counted are genuinely the same kind of failure on genuinely comparable equipment.
- Occurrence scores for FMECA that come from counted history rather than from the memory of whoever is in the room.
- Spares holdings sized from failure rates and lead times, rather than from the last shortage.
- Criticality that can be applied consistently across a class, which is what the asset criticality assessment depends on.
- Cost roll-ups that mean something, because the work order landed on the right functional location in the first place.
Fixing the register you already have
Almost nobody starts clean. The usual inheritance is a register built over a decade by several teams and at least one migration, with duplicates, gaps, retired equipment still live, and a hierarchy that changes shape by area.
The failure mode of these projects is scope. A full rebuild of every record, on every system, before anything improves, runs out of sponsorship long before it runs out of records. Sequencing by criticality is what keeps it delivering.
- Assess first. Count duplicates, orphans, missing parents, blank classes and equipment that no longer exists, so the size of the problem is a number rather than an opinion.
- Write the data standard before touching records. Levels, classes, boundaries, naming, mandatory fields and who may create what.
- Start with the critical systems. Structure and verify them against the field, then extend by criticality band.
- Verify in the field. A register corrected only from drawings inherits every change that was never drawn.
- Fix bills of material as you go, because that is where planning feels the benefit first.
- Decide the history rule early. Code consistently from a date, recode a recent window if analysis needs it, and accept the rest as trend data.
- Migrate with rules and a reconciliation report, not with a spreadsheet nobody can reproduce.
Governance is what keeps it clean
A rebuilt register drifts back within a couple of years unless somebody owns it. The controls are not elaborate. A named data owner, a short standard, a request process for creating or changing records, mandatory fields the system enforces, and a periodic audit against the field.
New assets are the other leak. Equipment arriving from a project usually brings its own numbering, its own descriptions and no failure codes. Setting the taxonomy, the codes and the bills of material as a deliverable of the project, as part of operational readiness, is far cheaper than repairing it afterwards.
The same applies to what the standard asks of the data itself. ISO 14224 expects data to be complete, consistent and traceable to a source, which is the same expectation ISO 8000 makes of master data generally, and ISO 55001 makes of the information an asset management system runs on.
Common mistakes
- Copying the nine taxonomy levels into the CMMS as nine levels of hierarchy, then watching people give up navigating it.
- Leaving equipment classes blank or free text, which makes every class based analysis impossible later.
- Never defining boundaries, so failure rates cannot be compared between areas, let alone between sites.
- Collapsing functional location and equipment into one record, so rotables destroy both histories.
- Structuring the hierarchy around departments or contracts, which change more often than the plant.
- Enforcing long code lists nobody understands, which produces consistent data that is consistently wrong.
- Rebuilding the whole register at once instead of sequencing by criticality.
- Cleaning the data without fixing the process that dirtied it, which buys a couple of quiet years and then the same project again.
Rebuilding a hierarchy
Assess
Count duplicates, gaps and orphans, so the problem has a size.
Standard
Levels, classes, boundaries, naming and mandatory fields, written down.
Structure
Build the hierarchy by process, starting with critical systems.
Verify
Check it against the field, not only against the drawings.
Code
Classes, failure and maintenance codes tied to each class.
Migrate
Rules, a reconciliation report and a repeatable load.
Govern
An owner, a change process and an audit that actually runs.
Assess
Count duplicates, gaps and orphans, so the problem has a size.
Standard
Levels, classes, boundaries, naming and mandatory fields, written down.
Structure
Build the hierarchy by process, starting with critical systems.
Verify
Check it against the field, not only against the drawings.
Code
Classes, failure and maintenance codes tied to each class.
Migrate
Rules, a reconciliation report and a repeatable load.
Govern
An owner, a change process and an audit that actually runs.
Common questions
What is ISO 14224?
ISO 14224:2016 is the international standard for the collection and exchange of reliability and maintenance data for equipment. It was written for the petroleum, petrochemical and natural gas industries and is widely used beyond them. It defines a taxonomy for classifying equipment, boundaries for what each equipment class includes, the data to collect about equipment, failures and maintenance, and standard codes for recording it.
Is ISO 14224 only for oil and gas?
It was written there, and the equipment classes reflect it, but the structure applies to any industry with rotating and static equipment. Mining, processing, water and power operations commonly adopt the taxonomy levels, the boundary concept and the failure coding, and extend the class list with equipment the standard does not cover.
What are the nine levels of the ISO 14224 taxonomy?
Industry, business category, installation, plant or unit, section or system, equipment unit, subunit, component or maintainable item, and part. Levels 1 to 5 describe use and location. Levels 6 to 9 subdivide the equipment itself. Most reporting happens at level 6, the equipment unit.
What is the difference between a functional location and equipment?
A functional location is a position in the plant where equipment is installed, such as the primary crusher lube pump position. The equipment is the physical item currently installed there, with its own serial number and history. Keeping them separate lets history follow both the position and the machine when a rotable is swapped.
What is an equipment boundary?
The boundary defines what is included in an equipment unit, such as whether the driver, the coupling, the base frame, the local control panel and the lubrication system count as part of a pump. It matters because failure rates are only comparable when two organisations, or two areas of one site, drew the boundary the same way. ISO 14224 gives boundary diagrams by equipment class.
How many levels should an asset hierarchy have?
Enough to locate the work and no more, which for most operations means four to six usable levels between the site and the maintainable item. Depth should be consistent within an equipment class rather than varying with whoever built that branch, and the hierarchy should stop where work orders stop being written.
What failure data does ISO 14224 ask for?
For each failure, what failed and where, the failure mode from a list for that equipment class, how it was detected, the severity of the failure, the mechanism and cause where they are known, and the maintenance that followed, including activity, resources, downtime and any consequence.
Do we have to recode our old failure history?
Usually not all of it. Recoding history is expensive and the quality of the original records limits what can be recovered. A practical approach is to code consistently from a chosen date, recode a recent window where analysis is planned, and accept that older records support trends rather than reliability calculations.
How does ISO 14224 relate to ISO 55001?
ISO 55001 requires that the information needed for asset management decisions is determined, available and controlled, without saying what the data looks like. ISO 14224 is one of the practical answers, because it defines a structure and codes that make maintenance data usable for those decisions.
Where do we start with a bad asset register?
With the critical systems rather than the whole site. Agree the standard, structure and verify those systems against the field, correct the codes and the bills of material, and put governance around creation and change before extending to the rest. Rebuilding everything at once usually stalls before it delivers anything.
Key terms
Plain-language definitions from our glossary for the concepts this article leans on.
Standards and further reading
- ISO 14224:2016 Collection and exchange of reliability and maintenance data for equipment (ISO)
- IEC 81346-1:2022 Structuring principles and reference designations, basic rules (IEC)
- ISO 8000-61:2016 Data quality management, process reference model (ISO)
- ISO 55001:2024 Asset management system requirements (ISO)
- OREDA, offshore and onshore reliability data (OREDA)
- Best practices metrics (SMRP)
Related case studies and tools
- Rebuilding asset hierarchies and maintenance master data (case study)
- MTBF / MTTR Calculator (tool)
Related reading
Working through something like this?
See how we approach these initiatives, or tell us what you are dealing with.