If you have typed "ISO 14224 equipment hierarchy" into a search box, you are almost certainly midway through designing a taxonomy, and you have hit the question the standard does not answer for you.

ISO 14224 gives you a spine. It settles how to classify equipment consistently and gives you a hierarchy backbone down to the equipment unit, so that reliability and maintenance data can be pooled and compared across sites and operators. What it does not do is design the levels below that unit for your specific assets, or tell you how to fit that spine into your own CMMS. That part is engineering judgement, and it is where taxonomy projects quietly succeed or fail.

This article is about that line. What the standard actually settles, and what it hands to you.

What is ISO 14224:2016?

ISO 14224:2016 is the current 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 it is now used well beyond them as a de facto reference for equipment taxonomy and failure data.

This article describes the 2016 edition, which is the version in force. That matters for a simple reason. Your reader owns the standard, and a page that describes older content as current is a page they will stop trusting on the first sentence. Everything below is about the 2016 text.

A note on scope. The value of the standard is not a folder structure you copy. It is a common language, a way to define an equipment class and record why it failed so that one operator's data means the same thing as another's. That is the whole point, and it is also the reason the standard stops where it does.

What does ISO 14224:2016 actually settle, and what does it leave to you?

It is prescriptive above the equipment unit and advisory below it, and the change of register happens at exactly the level most people never notice.

The standard sets out a nine level taxonomy. The upper five levels place the asset in its world: the industry, the business category, the installation, the plant or unit, and the section or system. The lower four break the equipment down: the equipment unit, which is the tag level you hang everything off, then the subunit, the component or maintainable item, and finally the part. Levels one to five tell you where the asset sits. Levels six to nine tell you what it is made of.

That classification spine, down to the equipment unit, is the settled part. It is what makes one operator's data mean the same thing as another's, and it is the asset the standard actually delivers.

Below the equipment unit the register changes. The standard recommends a small, workable subdivision, equipment unit to subunit to maintainable item, and then treats the depth beyond that as a matter of complexity and data use rather than a fixed requirement. The decomposition of your specific machines, how far you go, and how it sits inside your maintenance system is guidance you apply with judgement, not a numbered clause you can point at.

This is the line almost nobody writing about the standard draws. Above the tag level it prescribes. Below the tag level it advises. Two organisations can both be ISO 14224 based and still end up with hierarchies that do not reconcile, because the standard governed the part they had in common and left the part where they differ to them. Knowing which part is which is the first skill of taxonomy design.

Asset classification, functional location, equipment hierarchy: what is the difference?

These three are the single most common confusion in this field, and most failed taxonomies collapse them into one tree. They are not the same thing, and they should not live in the same structure.

Hold these three apart and everything downstream gets easier. Conflate them, and you will spend the next two years explaining why the history is attached to the wrong thing.

How does a 14224 hierarchy map onto a CMMS or SAP PM structure?

It maps onto two structures, not one. In a system like SAP PM this is the functional location structure and the equipment master, and the standard's taxonomy informs the classification rather than being the folder tree itself.

In practice, the functional location structure carries the process and place view, the equipment master carries the physical assets that are installed into those locations, and the equipment class and characteristics carry the ISO 14224 style classification and attributes. The taxonomy is not the hierarchy of folders. It is the classification you apply to the objects that sit in those folders, which is why teams who try to make the SAP functional location tree be their ISO 14224 taxonomy end up fighting the system.

The clean pattern is to let the functional location structure model the plant, let the equipment master model the assets, and use classification to carry the standardised equipment class and the attributes you want to report on. Keep the reliability taxonomy as a classification layer over the structure, not as the structure.

Failure mode coding: where does 14224 stop and your CMMS begin?

The standard gives you a common vocabulary of failure modes and a disciplined way to record an event. Your CMMS failure catalogue, the object, damage and cause codes a technician actually selects, is your implementation, and reconciling the two is the work.

Two distinctions the standard keeps, and most CMMS setups quietly lose, are worth calling out, because your reader will recognise them from their own system.

The first is the split between what was observed and why it happened. The standard separates the failure descriptor, the manner in which the failure showed itself, from the failure cause, the circumstances that led to it. Most implementations collapse these into a single field, and the moment they do you can no longer analyse either cleanly. You cannot ask how often a seal leaks separately from why it leaked, because both got typed into the same box.

The second is method of detection. How the failure was found, on inspection, on demand, or by a monitoring alarm, is a coded field in its own right. It is one of the first fields dropped in a real implementation, and dropping it removes your ability to tell whether your maintenance program is finding failures or your process is running into them.

Beyond those, the standard stops at the shared vocabulary. It does not populate your dropdown menus, decide the granularity your technicians can realistically record at the tool, or map your existing codes onto its definitions. That mapping is where most of the value and most of the effort sits, because a failure catalogue that is too fine will not be used, and one that is too coarse will not support analysis. Designing that middle is judgement, informed by the standard, not dictated by it.

The equipment boundary is not a preliminary step, it is half the work

Before you can record a single failure against a pump, you have to decide what counts as the pump. That is the equipment boundary, and in ISO 14224 it is a substantial part of the standard rather than a warm up to it.

The boundary decides which failures attach to which asset. Where does the pump stop and the driver begin. Is the local instrument part of the pump or part of the control system. Is a shared coupling on the pump's account or the motor's. The standard gives you rules of thumb for these calls. For example, where a driver and a driven unit share a subunit, its failures are recorded against the driven unit, so that two analysts looking at the same machine record the same event the same way.

Get the boundary right and your reliability data is comparable across sites and over time. Leave it implicit and every analysis downstream inherits the ambiguity. It is the least glamorous part of taxonomy design and one of the most consequential, which is why it deserves as much attention as the levels above it.

How do you reconcile ISO 14224 with a coding scheme like VMRS?

You do not reconcile them into a single tree. You build a mapping layer between them, because they answer different questions and neither should be forced to do the other's job.

This is the part almost nobody writes about, so it is worth being precise. ISO 14224 governs equipment structure and failure semantics. What the asset is, how it decomposes, and why it failed, in a form built for reliability analysis. VMRS, the Vehicle Maintenance Reporting Standards maintained by the American Trucking Associations Technology and Maintenance Council, governs codes and work classification for road transport fleets. It is a nine digit convention grouped in threes, system then assembly then component, with separate code keys for things like why a technician believes a part failed, why the asset came in, and what was actually done. It has been the maintenance and cost coding language of the trucking world since 1970.

Put those two next to each other and the instinct is to merge them into one master hierarchy. That instinct is the mistake. One scheme is built for reliability structure and failure semantics. The other is built for parts, labour and cost coding on a vehicle. They operate at different granularities and they are authoritative about different things.

The right architecture is a mapping layer, not a merge. Keep one scheme as the structural spine, usually the ISO 14224 style equipment hierarchy, and treat the other as a code overlay that meets it at a defined join. That join lives at the component or maintainable item level, where a 14224 component maps to the relevant VMRS code keys through a governed crosswalk table. Structure and reliability semantics stay authoritative in the equipment hierarchy. Codes, work and cost stay authoritative in VMRS. Neither is bent out of shape to accommodate the other, and the crosswalk is maintained as a first class artefact rather than living in someone's head.

The test of whether you have this right is simple. If a change to your parts coding forces a change to your equipment structure, you have merged two things that should have been mapped. Map them at the join, and each scheme can evolve without breaking the other.

How do you design the levels below the standard?

Start from the decision the hierarchy has to support, and decompose only as far as those decisions need. This is the method, and it holds at a sector level regardless of the asset class.

The value here is the method, not any particular set of numbers. Match the depth to the decisions, separate the concerns, and govern the result, and the hierarchy will hold up long after the project that built it has closed.

The spine, and the judgement

ISO 14224 is a spine, not a blueprint. It settles the classification and the vocabulary that let reliability data mean the same thing everywhere, and it deliberately leaves the decomposition below the equipment unit, and the fit into your own systems, to you. That is not a gap in the standard. It is the standard being honest about where a numbered clause ends and engineering judgement begins.

The organisations that build taxonomies that last are the ones that know exactly which is which, keep classification, functional location and equipment hierarchy apart, and treat the join between their reliability structure and their coding schemes as a mapping layer rather than a merge.

SAS-AM helps asset owners design equipment taxonomies that sit correctly inside a CMMS or SAP PM, hold the classification, functional location and hierarchy distinction cleanly, and map to the coding schemes the business already runs on.

Get the worksheet

The Asset Hierarchy Design Worksheet takes you from the ISO 14224 spine to a working CMMS structure, with the level design decisions laid out and a worked example. It is the template the reliability manager who found this page was already trying to build.

Continue reading