ISO 14224 provides a basis for collecting and exchanging reliability and maintenance data in a standardized format. Its official scope covers petroleum, petrochemical and natural gas industries. The standard organizes a common language for operating experience and addresses equipment, failure and maintenance data categories as well as quality practices. It does not turn incomplete records into trustworthy analysis or replace company technical governance.
Practical application starts with a data project inspired by the public objective of ISO 14224 without reproducing protected tables, codes or normative content. To claim conformity, interpret a requirement or implement the standard in its scope, an organization must consult the licensed current edition, define applicability and involve competent professionals.
The problem standardization solves
A plant may hold thousands of notifications and remain unable to compare failures. One shift records a symptom, another records a component, and another types an action into the cause field. Pump, pump set and transfer system appear as if they were the same level. Downtime starts at notification opening in one area and at loss of function in another. The volume looks substantial while the population is incoherent.
Standardization creates three conditions. First, every record references a technical object and defined hierarchy level. Second, failure mode, mechanism, cause, consequence and action occupy distinct meanings. Third, time and exposure follow documented rules. The result is a dataset that can be reconciled, compared, and audited.
What the official ISO page supports
The ISO page identifies ISO 14224:2016 as the published third edition and shows it as confirmed in the review cycle. Its public abstract describes a basis for reliability and maintenance data during operational life. It identifies three broad categories: equipment data, failure data and maintenance data. It also names uses in reliability, availability, maintenance, safety and environment.
The abstract also limits scope. Direct costs, complete equipment data sheets, laboratory testing and complete analytical methods are not the declared central focus. That boundary matters. A failure vocabulary does not mean the standard alone provides an economic model, an RCFA or a maintenance strategy.
Minimum architecture for a data project
1. Governance
Define sponsor, data owner, catalog administrators, class specialists and a review routine. The system owner does not decide technical meaning alone. A change in a term, required field or time rule needs a version, justification and effective date.
2. Equipment boundary
State where each event accumulates. A hierarchy may include site, unit, system, equipment and maintainable item according to the company model. The purpose is to prevent the same type of event from being assigned sometimes to a system and sometimes to a component without a rule.
3. Failure dictionary
Separate required function, functional failure, observed failure mode, mechanism, cause and effect. Mode describes how function was lost or degraded. Mechanism describes the physical process. Cause explains the condition that initiated or allowed the mechanism when evidence exists. Effect records what was observed or produced. An unknown remains unknown.
4. Maintenance data
Record work type, action, replaced item, resource, start and end under selected milestones, and post-work condition. The order shows what was executed. It must not receive a confirmed cause merely because a part was replaced.
5. Quality and reconciliation
Measure completeness, validity, consistency, timeliness, uniqueness and traceability. A complete record can still be technically wrong. Sampling must return to notification, order, measurement and field evidence.
A ten-step implementation method
- Define the use. Select a concrete decision such as comparing recurrence by class or revising a plan.
- Bound the population. Fix classes, locations, period, status and exposure.
- Map current fields. Locate where equipment, failure, action, time and consequence are recorded.
- Diagnose quality. Count blanks, free text, duplicates, mixed levels and impossible times.
- Create an internal dictionary. Define terms, examples, exclusions and owners without copying protected content.
- Build a crosswalk. Relate current field, internal meaning and future process destination.
- Configure and test. Apply the design to a pilot class and preserve raw values for audit.
- Train through cases. Ask users to classify anonymized real records and explain their decisions.
- Review disagreement. Adjust catalog, interface or rule when specialists classify the same event differently.
- Scale with control. Publish a version, monitor quality and prevent ungoverned changes.
Worked case: compressor group K-301
Every number and record in this case is didactic. It is not a customer result, benchmark, ISO requirement or PM Run performance claim. A unit has five equivalent compressors. Engineering wanted to compare failures that removed capacity, but records mixed symptoms, components and actions.
Pilot assumptions
| Element | Internal case definition |
|---|---|
| Pilot class | Five equivalent centrifugal compressors |
| Historical window | January 1 through June 30, 2026 |
| Maximum calendar exposure | 21,720 hours, calculated as 5 compressors × 181 days × 24 h |
| Hours outside eligible state | 3,480 hours of planned outages, event downtime, and other periods excluded by the pilot rule |
| Accumulated exposure | 18,240 hours in eligible state |
| Included event | Loss or degradation of compression function beyond the internal limit |
| Excluded event | Planned outage and order without loss of function |
| Source | Reconciled notification, order, process history and measurement |
| Time unit | Hours, with time zone and milestone defined |
The diagnosis found 27 related records. After reconciling duplicates and scope, seven were functional events. Nine were planned orders, six were duplicate notifications and five described anomalies without loss of function. No record was deleted. Every exclusion received a reason and a link to the original.
Exposure was reconciled from the physical ceiling of 21,720 calendar hours. Documented exclusion of 3,480 hours left 18,240 hours in eligible state. The seven events totaled 26.6 downtime hours, averaging 3.8 hours per event. The descriptive rate was 7 ÷ 18,240 × 1,000 = 0.384 event per 1,000 eligible hours. With only seven events and different mechanisms, that rate did not support causal comparison or a strategy change; the decision remained grounded in semantic separation and evidence for each event.
Before standardization
| Raw text | Field used | Problem |
|---|---|---|
| High vibration | Cause | Symptom recorded as cause |
| Replaced bearing | Failure description | Action recorded as failure |
| Trip | Long text | Effect without function and detailed object |
| Mechanical failure | Mode | Category too broad for comparison |
| Normalized | Cause | Work outcome without a mechanism |
Internal pilot dictionary
The team did not attempt to copy a normative taxonomy. It created internal definitions and recorded that formal implementation depended on the licensed standard. For the pilot, function was to compress gas within the defined range. Functional failure was inability to maintain flow or pressure. Mode was the observed form of loss. Mechanism was the physical process supported by evidence. Cause remained unconfirmed when no investigation existed.
| Didactic ID | Observed mode | Supported mechanism | Cause | Action | Downtime |
|---|---|---|---|---|---|
| E01 | Protective trip | Bearing degradation | Lubrication outside internal parameter | Replace and revise task | 6.2 h |
| E02 | Flow below standard | Stage deposit | Contaminant under investigation | Clean and sample | 4.5 h |
| E03 | External leakage | Seal degradation | Unconfirmed | Contain, replace and open RCFA | 3.8 h |
| E04 | Protective trip | Confirmed instrumentation fault | Degraded connection | Repair connection and test | 1.7 h |
| E05 | Unstable pressure | Mechanism unconfirmed | Unconfirmed | Collect additional data | 2.1 h |
| E06 | Start unavailable | Interlock actuated | Valid process condition | Restore condition | 0.9 h |
| E07 | Flow below standard | Confirmed internal clearance | Accumulated wear | Repair and revise limit | 7.4 h |
The table is an original didactic model. It does not represent ISO 14224 codes, required structure or taxonomy. Its role is to show semantic separation. The team retained raw text beside the controlled term so a specialist could audit the transformation.
Decision produced
The pilot showed that protective trip was not a causal family. E01 and E04 shared a trip effect but had different mechanisms and actions. Combining them under one cause would create a false priority. The decision was to revise the lubrication plan for the bearing family, open investigation for the unconfirmed seal event and keep instrumentation failure in a separate workstream.
The team also decided that mode and effect would be required in the notification for this class. Mechanism and cause could remain unconfirmed. Later completion required evidence and an authorized role. That rule protects history from invented certainty.
Path into SAP PM
In the case architecture, equipment and functional location establish the address. The notification receives condition, malfunction, mode, effect, detection method and dates according to configuration. The order records operations, materials, time and executed action. Permitted measurements and attachments support evidence. Catalogs organize language while technical text preserves context that does not fit a code.
SAP official documentation describes failure data in notifications, including mode, effect and detection method in compatible scenarios. The organization must verify version, process and Customizing. The standard does not automatically determine how every field is implemented in a company's SAP environment.
PM Run can support mobility, planning, execution and return of data over SAP PM. It does not provide a ready-made ISO taxonomy, declare conformity or replace master-data governance. SAP remains the system of record.
Indicators and verification window
The pilot was evaluated for 180 days and at least 30 classifiable events or anomalies. The longer criterion applied. Indicators included:
- completeness of pilot fields;
- unclassified percentage, followed without artificial redistribution;
- agreement between two specialists in a sample;
- event duplication after reconciliation;
- time from detection to formal notification;
- percentage of records traceable to an order and evidence;
- events per exposure only after validating the population.
In the exercise, baseline completeness was 46%. Internal criteria were at least 95% completeness, unclassified below 5% without forced classification, duplicates below 2%, and 100% sample traceability. These are didactic targets, not ISO requirements or market benchmarks.
Select the discipline that answers the question
ISO 14224 addresses data structure and quality within its scope. Reliability engineering integrates decisions and strategy. FMEA anticipates modes and effects. RCFA investigates an observed event. MTBF summarizes a defined population. Each discipline answers a different question and may use the same governed history.
Limits
- The official ISO 14224 scope is sector-specific and must be respected.
- Use in another sector can inform design but does not create automatic conformity.
- The public abstract does not replace access to the licensed standard.
- A taxonomy without review governance only standardizes error.
- A required field can increase completion and reduce quality when definitions are weak.
- Plant comparison requires equivalent populations, exposure and rules.
Quality control before analysis
The K-301 pilot established four checks before any indicator was calculated. The first confirmed that equipment, position, and operating period formed a coherent population. The second searched for duplicate records of one event using time proximity, technical object, and description. The third checked the sequence from detection and shutdown through work start and return to service. The fourth compared the controlled term with original text and attached evidence.
Rejected records were neither deleted nor forced into a convenient class. They received a quality state, reason, and correction owner. This queue separated master-data gaps, semantic disagreement, and genuine absence of information. Completeness therefore measured usable fields rather than fields containing any value.
Agreement sample
Two specialists independently classified ten pilot records. Eight had full agreement, one differed between effect and mode, and one remained inconclusive because evidence was insufficient. Joint review corrected the internal definition, preserved the inconclusive state, and added a training example. An agreement target would be enforced only after calibration.
This control reduces a common risk: consistent charts built from inconsistent meanings. Before comparing units, a company should demonstrate that people recognize the same event, apply the same time boundary, and preserve unknown status when evidence does not support classification.
Change control for taxonomy and mapping
The pilot assigned an owner to every definition, catalog entry, and SAP mapping. A proposed change required reason, affected records, effective date, migration rule, and approval. Existing records were not silently rewritten because that would alter historical series without an audit trail.
Versioning also covered extraction logic. If one report treated a trip as an event while another merged it with a preceding derate, rates could not be compared. The data dictionary therefore recorded inclusion rules, exposure source, units, null treatment, and query version. A release note identified any series break.
For K-301, the team froze the pilot dictionary for 90 days, reviewed exceptions every two weeks, and scheduled a formal decision at the end of the 180-day window. Only approved definitions would move to the wider compressor population. This sequence protected analysis from uncontrolled catalog growth.
Official references
- ISO 14224:2016, official page and public abstract, accessed August 23, 2026.
- ISO/TC 67/WG 4, Reliability Engineering and Technology, accessed August 23, 2026.
- SAP Help Portal, Failure Data, accessed August 23, 2026.
Frequently asked questions
Does ISO 14224 apply to every industry?
The official scope is petroleum, petrochemical and natural gas industries. Other operations may study its structuring principles but should not claim automatic conformity. Applicability, licensing, internal requirements and the standards of the relevant sector need review.
Does the standard provide every SAP PM code?
The standard and the system have different roles. An organization must design the mapping among its licensed taxonomy, process and SAP configuration. Copying terms without defining use, level and governance does not create comparable data.
Must every notification contain a cause?
A cause must not be invented to fill a field. Symptom, mode, effect, mechanism and cause have different meanings. When cause is unconfirmed, the unknown state must remain and can trigger investigation according to criticality.
To connect execution, planning and field feedback to SAP PM, learn about the PM Run operational layer. Taxonomy, conformity and engineering decisions remain the responsibility of the company.
