ISO 15926 overview

Issued 2023-05-17, latest revision 2023-09-27


ISO 15926 has as ambitious scope: Integration of life-cycle data for process plants.

That means: All, or selected, data that have been generated by all, or selected, software, used for all, or selected, activities for and during the life of a facility, from cradle to grave, are to be integrated, stored and shared in a standard way.

For example, it is possible to find the root cause of a problem, or the design data required for an energy savings project. But it also creates the possibility to share data that are always the latest.

This topic will give you an overview of the scope and implementation of ISO 15926-7/8.

The implementation is defined using W3C Semantic Web technologies: RDF, SHACL, SPARQL, triple stores and SPARQL endpoints.

One of the largest suppliers of engineering software has, for that reason, decided to use ISO 15926 as the basis of his new Digital Twins software.

ISO 15926 Parts

ISO 15926 has the following parts that are used in the scope of ISO 15926-7/8:

ISO 15926-7/8 basics

ISO 15926-7 and -8 deal with:


Templates represent information about something. But if that something is unknown or ill-defined the information will be useless. It therefore is necessary to place things, that play a role in the information, in the fabric of the ISO 15926-2 generic data model. Example:

	rdf:type lci:InanimatePhysicalObject, dm:WholeLifeIndividual, lci:NonActualIndividual, rdl:RDS327239 ;
	rdfs:label "21-P-101" ;
	meta:valEffectiveDate "2020-04-15T15:01:00Z"^^xsd:dateTime .

That long number is called a UUID - Universally Unique IDentifier. Labels may change, but the UUID stays, for ever. The above declaration states that it is about something with a label "21-P-101", that is an InanimatePhysicalObject, a WholeLifeIndividual, a NonActualIndividual, and a PUMP.

This is information that is valid for the entire existence of that pump (and thereafter in its history).
Later we can reclassify it as a CENTRIFUGAL PUMP:

      rdf:type tpl:ClassificationOfIndividual ;
      tpl:hasClassified ex:709c4cdc-93f2-4ac3-b45d-86d09dfc0e28 ; # 21-P-101
      tpl:hasClassifier rdl:RDS416834 ; # CENTRIFUGAL PUMP
      meta:valEffectiveDate "2020-11-15T13:45:00Z"^^xsd:dateTime . 

where we, in fact, declare that instance of the template type tpl:ClassificationOfIndividual.

Why so cumbersome and why not typed directly as Centrifugal Pump? Think what happens with your data when at a later date it appears better to use a Positive Displacement Pump, and you know the answer: not all data would be valid for a PD pump and an awkward situation would arise. When we keep the declared thing at the highest level in the class hierarchy, we can deprecate that classification template and start a new for classification as a PD pump and keep all older information in store, whilst we deprecate the data exclusively related to that Centrifugal Pump.

Remember: we integrate all life-cycle information, including that change to a PD pump.


An ISO 15926-7 Template is, in the background, an elementary knowledge graph consisting of instances of ISO 15926-2 entity types, and in case of specialized templates, also ISO 15926-4 classes, that together define the semantics of the template. For brevity reasons the variables in that graph are collected in the so-called signature of the template. In above template that signature is as shown.

The graph of the above example template is a simple one:

Graph of the template ClassificationOfIndividual

The diamonds are a Relationship or ClassOfRelationship with two predicates. These have the advantage that they can be addressed, for example classifying a DirectConnection relationship with a ClassOfDirectConnection called FLANGED CONNECTION.

Templates are more verbose than a graph with predicates, but have the following advantages:

Temporal Parts

When you look at above graph you see that PossibleIndividual [4] is a temporal part of PossibleIndividual [1]. What does that mean? Well, take yourself as example: your weight this morning was x kg, but tomorrow x+0.2 kg. So who owns those two properties? You, that is: temporal parts of you.

In above graph the semantics are: a temporal part of 21-P-101 is classified as CENTRIFUGAL PUMP as of 2020-11-15T13:45:00Z. The reason why [4] is not in the signature simply is that there is hardly, if at all, commercial software that works with temporal parts, so we keep referring to the temporal whole, in most cases the declared thing, serving as an anchor, but the semantics are about a temporal part of that anchor.

A temporal part must be declared when it is considered to be representing an object in the context of a domain of activities. For example the domains of Process Engineering, Detailed Engineering, Procurement, Construction, Operations, and Maintenance, that each has a domain-specific information set.

A class of temporal part is used to maintain an audit trail of document revisions and Class versions. In those cases the declared temporal part class serves as a temporal whole class for the templates directly attributed to it.


All declarations, including those of templates, shall have a meta:valEffectiveDate, and it shall be in UTC+00:00 in order to avoid confusions when sharing information internationally. The Z stands for Zulu time = UTC+00:00.


Whenever a declared thing is no longer in existence it must be deprecated by adding the following:

ex:709c4cdc-93f2-4ac3-b45d-86d09dfc0e28 meta:valDeprecationDate "2023-05-02T00:00:00Z"^^xsd:dateTime .

All deprecated records remain in store and can be fetched.

Information fetching

When the latest information must be fetched you use the latest meta:valEffectiveDate, that is obvious. When you want to fetch the information that was valid at a given dateTime in the past, search for the latest dateTime before that given dateTime. In fact you only shift the "now" dateTime back into the past. In a SPARQL query you can avoid fetching deprecated information.

It is also possible to find information that became valid in a given period-in-time.

Finally it is also possible to fetch planning data, but that is another story (see chapter Scheduling).

Working with Classes

Assuming that you learned the basics of Set Theory in school or college, here you can practice that.
Four use cases come to mind:

Actually these four areas are intertwined: Process design data are used for the definition of asset requirement classes, the latters are specializations (= subClassOf) Part 4 classes, and are compared, at class level, with manufactured product classes as offered in quotations.

When you study Part 2 and the Part 4 RDL you will find other classes. To mention a few:

Templates for Class and for Individual

When you look at the Template Specifications you see that these start with templates for class, and further down continue with templates for individual.

It is good to remember that templates for class actually are templates for class members at large, that define the criteria for membership, like the previously discussed criteria for Lightweight boxers. But that kind of criteria is not the only one. In fact the diversity of criteria is endless. When you define that the Asset Requirements Class shall have some feature, you actually added a criterion for membership. The union of all criteria ultimately defines that Asset Requirements Class.

In general only topological information, including stream source and destination, and perhaps some admin information, is to be defined for individuals in the design and engineering phase. All other (requirements) information shall be represented as part of the overall Asset Requirements Class, often defined with a technical specification.

For actual plant items, individuals, most - if not all - information is represented with templates for individual.

The Life cycle of a Plant Item

Undoubtedly you have seen many high-level powerpoints showing the life cycle of a plant. The problem with those images is that they are..... high-level. The devil is in the details. We have a detailed one that doesnt really fit on this page. You can see it in 100% size here.

That graph may be intimidating, so lets skip Process Design for now, that is detailed here:

The LSN, and thus above excerpt, describes the entire, cradle-to-grave, life of one plant item. As you can see there is not one placeholder for all life-cycle information. There are many, declared as what they really are in their Life-cycle Activity. For example, design object [36] is a NonActualIndividual, where its implementer in the real world is an ActualIndividual.

It is important to observe the rule that relationships between two plant items, each in its own LSN, shall both be involved in the same Life-cycle (ClassOf)Activity. The 'Implementation' relationship is the only exception.


Now you know some of the basics of ISO 15926 the next thing to discuss is: how can this be implemented? That can be shown with the following basic diagram:

Here you can find a rather wild diagram where the above one has been detailed. Since every element is standardized, other configurations are possible.


This tutorial started with: ...... All, or selected, data that have been generated by all, or selected, software, used for all, or selected, activities for and during the life of a facility, from cradle to grave, are to be integrated, stored and shared in a standard way.

For that standard way we have to map the data, generated with an application, to declared things and templates. That mapping is the difficult part of the entire set-up, because, in general, good mapping experts are scarce, and those who master ISO 15926 even scarcer. In order to mitigate that situation support by AI is being explored (see below).

The results are presented in a Turtle file. This file is validated with SHACL and temporarily stored as N-triples in a Triple Store, with Part 9 API, of the group/discipline that generated these data. Employees of that group check the correctness and completeness of the mapped data and release those for which they can take responsibility. The triples end up in the Project Triple Store. At some point in time at or before project close-out these consolidated triples are handed over to the project principal, who can have the same set-up for his integrated life-cycle information.

It should be noted that this does not replace any existing software. It is meant for consolidated information management in the background. Important is that this consolidated information is stored in ISO 15926 standard format and can be exchanged without conversion with other parties that have a similar, compliant, set-up.


Is this readily available? No, this is a standard, not an application.

What is missing in the standard? This:

Tools required

Mapping tool

Like most IT Managers know, mapping is a struggle, in particular because, in the case of ISO 15926, finding the right template for each (set of) data in a source application is hampered by a shortage of data modelers (the real ones). Considering the scope of this standard a high semantic precision is essential.

The rise of GPT AI tools seems potentially to be of help, be it as mapping assistance. But that requires teaching the tool what ISO 15926 entails, and that requires funding. In order to foster the use of ISO 15926 an online Mapping Assistance Tool would be beneficial: one enters a definition of a data element and gets two or three template types as advice. Perhaps after proper machine learning a precise advice is possible.

Validation tool

There are commercial SHACL-based tools available. These need to be fed with standard "shapes". See here for more details.