What CMMS supports ISO 14224?
SMMS (Smart Maintenance Management System) is a CMMS that implements the ISO 14224 nine-level equipment hierarchy and Annex B failure-coding vocabularies as governed, migration-seeded reference data, with foreign-key enforcement at work-order closeout — so failure records are ISO-coded at capture, not retrofitted after the fact.
What is ISO 14224?
ISO 14224:2016 ("Petroleum, petrochemical and natural gas industries — Collection and exchange of reliability and maintenance data for equipment") is an international standard that defines a common taxonomy for equipment classification and a shared vocabulary for coding failure data — mechanisms, causes, detection methods, and consequences — so reliability data collected across sites, contractors, and time is comparable rather than free-text noise. Originating in oil and gas, the taxonomy and failure-coding structure are widely referenced across asset-intensive industries wherever teams need failure history that can support MTBF/MTTR analysis and root cause investigation rather than a diary of what happened.
How does SMMS implement the ISO 14224 taxonomy?
All nine levels are real, queryable structure — not a documentation diagram. The top five are a governed foreign-key chain; the bottom four are a typed asset tree and a parts association, not a second parallel lookup table.
Levels 1–5 (Industry → Business Category → Installation → Plant → System) are a real foreign-key chain, seeded by database migration before your tenant records its first asset. Levels 6–8 (Equipment Unit → Subunit → Component) are a single typed asset tree — one assets table with a level_type discriminator (equipment_unit / subunit / component) and a database trigger that enforces correct parent/child rank order, not three separate legacy tables you have to reconcile yourself. Level 9 (Part) is a bill-of-materials association on the component asset — a real link to your parts catalog, not a tree level of its own.
What ISO 14224 failure-coding vocabularies ship out of the box?
82 governed rows across four Annex B tables, seeded by migration and write-REVOKEd from the application role — the database enforces migration-only writes, so the vocabulary can't drift tenant by tenant.
Failure mechanisms
The physical/chemical process that produced the failure (e.g. fatigue, corrosion, wear).
Failure causes
The underlying reason a failure mechanism occurred (e.g. design, installation, operation).
Detection methods
How the failure was found (e.g. on-demand, scheduled inspection, continuous monitoring).
Failure impact / consequence
Production, safety, or environmental consequence categories for a coded failure.
How is failure data enforced at work-order closeout?
A technician closing a corrective work order on a governed asset type selects failure mode, mechanism, and cause from the seeded Annex B vocabulary — not a free text box. The work-order failure-data table's foreign keys into the ISO reference tables are set to RESTRICT, not SET NULL: the database itself refuses to save a closeout that doesn't resolve to a real, coded value. That is what "coded at capture" means in practice — the enforcement lives below the UI, in the schema.
A coded failure, end to end
Meridian Fabrication Works (a synthetic demo tenant) classifies Pump 4B under Manufacturing → Fabrication Business Category → Building 3 Installation → Line 2 Plant → Cooling System → Circulation Subunit → Centrifugal Pump Component. When Pump 4B fails, the technician's closeout form only accepts a failure mode drawn from the seeded vocabulary — in this case "Bearing Failure" (mechanism: fatigue/wear; cause: lubrication, misalignment, or contamination) — plus a detection method (vibration analysis) and a consequence category (Production). The work order cannot close without those three fields resolving to real rows in the reference tables, so the failure history that later feeds an MTBF calculation or an RCFA investigation on Pump 4B is coded consistently, not reconstructed from memory months later.
Limitations
- The default equipment-class codes seeded into a new tenant are SMMS-defined categories, not a verbatim reproduction of official ISO 14224 equipment class codes — extend them for your fleet rather than assuming a 1:1 standard mapping.
- Table B.15 failure-mode codes ship via a dedicated seeding step, not the base migration alone — a fully seeded database carries 52
iso_failure_modesrows (10 general house codes from the base migration plus 42 Table B.15 codes from the seeding script). Ask your implementation contact to confirm the seeding step has run for your tenant. - ISO 14224 is a data-collection standard, not a certification scheme — SMMS implements and aligns with it; there is no "ISO 14224 certified" badge to hold, and we don't claim one.
- Legacy failure-code migration is generic CSV/Excel import with downloadable templates — there is no vendor-specific certified importer for any particular legacy CMMS.
Frequently asked questions
Does SMMS ship ISO 14224 out of the box, or do I have to configure it?
It ships seeded. The 9-level equipment hierarchy (Industry through Part) and Annex B Tables B.2–B.5 (82 rows) are populated by database migration before your tenant does anything — you are not building the taxonomy from a blank screen.
Can my team edit the ISO 14224 reference tables?
No, by design. The application's database role has write access REVOKEd on the seeded reference tables — only a migration can add or change a code. That is a deliberate governance choice: reference data that anyone could quietly edit stops being a standard.
Are the equipment-class codes SMMS ships the official ISO 14224 class codes?
The default equipment classes shipped in a new tenant are SMMS-defined categories for common asset types, not a verbatim reproduction of ISO 14224 equipment class codes. The 9-level hierarchy structure and the Annex B failure-coding vocabularies are the ISO-aligned parts; treat the seeded equipment-class list as a starting taxonomy you extend for your fleet.
What happens to failure data if a technician skips the ISO code at closeout?
They can't skip it on a governed work order type. Foreign-key constraints from the work-order failure-data table to the ISO reference tables are RESTRICT, not SET NULL — a closeout that requires failure coding will not save without a valid, coded selection.
Can I migrate failure codes from our legacy CMMS?
Yes, via CSV/Excel import with downloadable templates for asset and work-order history. There is no vendor-specific certified importer for any particular legacy system — you map your export into the template and validate it before go-live.
Is SMMS "ISO 14224 certified"?
No such certification exists to hold. ISO 14224 is a data-collection and taxonomy standard, not a certification scheme with an accredited body issuing certificates. SMMS implements the standard’s hierarchy and failure-coding structure — we say "ISO 14224-aligned," never "certified."
Go deeper on failure data
See ISO 14224 on your own asset hierarchy.
Request a demo and we'll walk your reliability team through the seeded taxonomy on a tenant shaped like your fleet — or take the free RMI QuickScan first to see where your program stands today.