Industrial and Engineering: ISO 15926, IDO and the Industrial Ontology Foundry
A process plant is handed over twice: once as steel and concrete, and once as data. The second handover routinely arrives as a few hundred thousand tag records in spreadsheets, a supplier document dump, and a maintenance system that does not agree with the design system about what a pump is. Industrial ontology exists because that gap costs real money over a forty-year asset life, and because the industry worked out decades ago that the fix is a shared reference model rather than yet another point-to-point interface. This lesson covers what each of the main industrial standards actually is, who owns it, whether you can get hold of it, and where it is genuinely running.
ISO 15926: the ancestor everyone still argues about
ISO 15926 is the multipart standard for integration of life-cycle data for process plants, including oil and gas production facilities. It is not one artefact but a family. Part 1 gives the overview and principles. Part 2 is the data model, an upper ontology of roughly two hundred entity types written in EXPRESS because that was the mandated language of ISO TC 184/SC 4, and it is thoroughly 4D: individuals have temporal parts, so the pump in commissioning and the pump in service are distinct states of one whole-life object. Part 4 is the reference data library, the enormous vocabulary of actual industrial classes such as centrifugal pump or flanged connection. Part 7 defines the template methodology used to express facts in a controlled way, and ISO/TS 15926-8:2011 specifies how Parts 2 and 7 are implemented in RDF and OWL. ISO/TS 15926-12:2018 added a lifecycle integration ontology expressed directly in OWL.
The honest assessment is that ISO 15926 is intellectually superb and operationally heavy. The EXPRESS core plus template layer demands specialist tooling, the reference data library is large enough that governance becomes the main cost, and many implementations quietly used a fraction of the model. Its influence, however, is everywhere: every serious industrial ontology since has borrowed its 4D commitments or explicitly reacted against its complexity.
IDO: ISO 15926-14 renumbered into ISO 23726-3
The modernisation route came through Part 14, an OWL upper ontology for industrial data developed with heavy Norwegian participation and delivered around 2020. That work has been renumbered into a new series, ISO 23726 “Ontology based interoperability”, with Part 3 being the Industrial Data Ontology, IDO. As of this sweep, Part 3 sits at Final Draft International Standard stage, having gone out as DIS version 4.0 in November 2024, and further parts are in the pipeline, including a committee draft for Part 100 on schedule data.
IDO does three things. It provides a small OWL DL upper ontology inspired by the ISO 15926-2 data model and by BFO, so it inherits 4D thinking without inheriting EXPRESS. It gives a disciplined pattern for connecting reference data libraries to asset models, which is the practical problem in engineering data. And it keeps the profile inside OWL DL so that real reasoners terminate on real plant data. The ontology is published with individual web pages for every class and property by the POSC Caesar Association, which holds the copyright, at the PCA reference data service. The ISO text itself is paid; the ontology artefacts are browsable and downloadable, which is the usual industrial split you must plan for.
The deployment example is the READI joint industry project on the Norwegian continental shelf, which ran from 2018 to 2022 with Equinor, Aker BP, Aibel and Aker Solutions among the participants. READI built a digital reference data library to the Part 14 model, tied to the Krafla and NOA field development projects, and published it through POSC Caesar. That is a decade of continuous operator experience with an ontology essentially equivalent to what is now ISO 23726-3, which is a far stronger evidence base than most standards can show.
The Industrial Ontology Foundry: BFO for manufacturing
The Industrial Ontology Foundry is an organisational unit of OAGi with a mission modelled explicitly on the OBO Foundry in biology: one core ontology plus a coordinated set of domain ontologies for digital manufacturing, all built on BFO. The 202301 suite promoted IOF Core to released status, and the second Core release in 2024 added support for temporal relations between occurrences using Allen interval algebra, which matters because manufacturing is full of “this operation must finish before that one starts” constraints. Domain modules extend the core, the maintenance ontology iof-maint being the best documented, described in arXiv 2404.05224. Specifications live at spec.industrialontologies.org with maturity levels attached, so you can see which modules are stable and which are still developmental. NIST researchers have published the Core ontology’s design rationale, which gives you a citable description rather than a marketing page.
IOF and IDO are the live comparison in industrial ontology today. IOF is BFO-realist and 3D at the top, with occurrents handling process; IDO carries the 4D lineage of ISO 15926. Both are OWL, both are open enough to inspect, and both are used in earnest. Choosing between them is a genuine engineering decision, not a matter of taste, and it should be driven by whether your hardest questions are about the identity of physical assets through change, which favours the 4D route, or about the classification of processes, capabilities and products, which the BFO plus IOF stack handles fluently.
What breaks · the tag number as the whole-life identity
A handover maps the design system to the maintenance system on the functional tag, P-101 to P-101, across 40,000 items. It is the only key both sides share, and for the first year it works.
Then the plant does what plants do. The pump at position P-101 is removed for overhaul and a refurbished unit is installed in its place; two years later the position is re-rated and a different model goes in. The tag is a functional position, a slot in the design that persists for the life of the plant, and it has now hosted three physical machines, each with its own serial number, warranty, vibration history and remaining-life estimate. Because the integration keyed on the tag, all three histories accumulate on one record: mean-time-between-failures is computed across three different machines, and the reliability model that drives the maintenance budget is fitted to a machine that has never existed.
This is the register’s lesson 5 failure, the reused tag as identifier, on a forty-year asset life, and it is precisely what the 4D commitment in this standards family exists to prevent: position, physical item and installation period are three modelled things, and the question “which machine was in P-101 in March 2023” has an answer. Note the honest trade the lesson sets up: the 4D route costs specialist tooling and training, and this failure is the bill you pay for skipping it.
Asset management, condition monitoring and digital twins
Alongside the ontologies sit standards that are not ontologies at all but which you will meet in the same room. MIMOSA’s Common Conceptual Object Model, CCOM, is an information model for exchanging asset lifecycle data, published by MIMOSA, a not-for-profit trade association. It underpins the Open Systems Architecture for Enterprise Application Integration, OSA-EAI, which is aligned with the layered architecture of ISO 13374 for condition monitoring and diagnostics, and it covers asset registers, work management, diagnostic and prognostic assessment, vibration and lubricant data, and reliability information. MIMOSA’s broader Open Industrial Interoperability Ecosystem work pairs CCOM with OPC UA companion specifications, which is how the shop floor and the enterprise are supposed to meet.
Digital twins have their own framework series. ISO 23247 defines a digital twin framework for manufacturing: Parts 1 to 4, published in 2021, cover overview and general principles, reference architecture, digital representation of manufacturing elements, and information exchange. Part 5 on the digital thread was published in June 2026 and Part 6 on digital twin composition is at Final Draft stage. Note what this series is: an architecture and information exchange framework, not a formal ontology. It tells you how observable manufacturing elements map to their digital representations. It does not axiomatise what a manufacturing element is. That job falls to IOF or IDO, which is exactly why the two families are increasingly cited together.
| Standard | What it is and does | Maintainer | Licence and access | Real deployment |
| ISO 15926 family | Life-cycle data integration for process plants: 4D data model in EXPRESS, reference data library, templates, RDF and OWL implementation parts | ISO TC 184/SC 4 with POSC Caesar and USPI communities | Paid ISO text; reference data browsable through POSC Caesar services | Decades of use in oil, gas and petrochemical engineering data handover |
| IDO, ISO 23726-3 | Small OWL DL upper ontology for industrial data; successor numbering for the former ISO 15926-14 | ISO with POSC Caesar Association; PCA holds ontology copyright | FDIS stage at this sweep; ontology pages public at the PCA reference data service | READI joint industry project 2018-2022, digital reference data library for Krafla and NOA field developments |
| IOF Core and modules | BFO-based core plus manufacturing domain ontologies; 2024 Core release added Allen interval temporal relations | Industrial Ontology Foundry, an OAGi unit, with NIST participation | Public specification site with maturity levels; open artefacts | Maintenance module iof-maint, documented in arXiv 2404.05224 |
| MIMOSA CCOM and OSA-EAI | Asset lifecycle and condition monitoring information exchange aligned to ISO 13374 layers | MIMOSA, not-for-profit trade association | Specifications published by MIMOSA; open industrial ecosystem positioning | Asset register, work management and condition monitoring integration in heavy industry |
| ISO 23247 series | Digital twin framework for manufacturing: reference architecture, digital representation, information exchange, digital thread | ISO TC 184/SC 4, with NIST analysis published | Paid ISO text; Parts 1 to 4 from 2021, Part 5 published June 2026 | Framework layer beneath vendor digital twin platforms in discrete manufacturing |
Check yourself
Your hardest questions are about which physical item occupied which position when, and what its configuration was at the time of an incident. Which stack fits, and why?
- The 4D lineage, because identity of physical assets through change is its design centre.
- The BFO-realist manufacturing stack, because it has released core and domain modules with maturity levels.
- The digital twin framework series, because it defines how manufacturing elements map to digital representations.
- An asset-management information model, because it already covers work management and condition monitoring data.
Show the answer, and why each wrong option is wrong
A is correct. The question names a time and asks which individual was where: that is identity through change, and temporal parts make it answerable natively rather than through bolted-on audit tables. The lesson states the selection rule directly, and this is the case it points at.
B is not a weak stack, and it is optimised for a different question: classification of processes, capabilities and products, where its Allen-interval treatment of operation ordering shines. Maturity levels tell you a module is stable, not that it answers your question, and choosing a stack by release quality rather than by question is how projects end up with excellent tooling pointed at the wrong problem. C is an architecture and information-exchange framework, explicitly not a formal ontology: it says how elements map to representations and never axiomatises what an element is, which is why it is cited alongside an ontology rather than instead of one. D carries exactly the operational data you want and provides no account of identity through change; without one, all that data lands on the tag, which is the failure in the block above.
Why half the detail dies between standards
Run a crosswalk between any two of these and the same losses appear. Units and tolerances survive only if both sides carry a measurement pattern rather than a numeric field. Temporal qualification dies first: a 4D model that says this asset had this configuration during this period collapses into a current-value attribute on the target side, and the history is gone. Roles and functions get flattened into class membership, so “this vessel is functioning as a separator on this project” becomes “this is a separator” forever. Provenance and confidence almost never cross, because most exchange schemas have nowhere to put them.
The discipline that answers this is crosswalk engineering: declare the mapping predicate honestly, record what does not map and why, and put machine-checkable tests around the claim so that a later change breaks a build rather than a plant. Our own validation tooling for exactly this workflow is public at the open-ontologies repository, and the method is taught end to end in the crosswalk certification course. In industrial settings this is not academic hygiene. It is the difference between a handover that a maintenance team can trust and another forty-year pile of spreadsheets.
