ISO 15926 overview

Introduction

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 allows 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 at a granular level.

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:

• Part 2 - Data Model - the Upper Ontology of which everything is a specialization ;
• Part 4 - Reference Data - a specialization of Part 2 with common classes/concepts ;
• Part 7 - Templates - elementary ontologies, using Parts 2 and 4 classes as components ;
• Part 8 - Implementation of Part 7 in RDF, RDFS, and SPARQL, with OWL for definitions only ;
• Part 9 - Triple Store (to be developed) ;
• Part 10 - Conformance testing, using SHACL.

ISO 15926-7/8 basics

ISO 15926-7 and -8 deal with:

• declared things ;
• templates that represent information about declared things.

Declarations

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:

ex:709c4cdc-93f2-4ac3-b45d-86d09dfc0e28
	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:

ex:4cef7d77-aa8e-49b8-a962-e607494fd38f
      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 (that still makes sense), 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.

Templates

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:

• represents an elementary information, with full definition of its semantics ;
• parametric, can be used in many cases by referring to the applicable RDL class(es) ;
• self-contained, can be referred to in many circumstances, no lock-up in a hard-coded schema ;
• can be attributed with meta data, such as dc:source, meta:valEffectiveDate, meta:hasRule, meta:hasStatus, meta:hasAccessCode, skos:editorialNote, skos:changeNote, meta:valChangeDate, meta:valDeprecationDate, etc.

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, as shown in the diagram below:

EffectiveDate

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.

DeprecationDate

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:

• Process Design is represented in classes: ClassOfActivity, ClassOfStream, and ClassOfFunctionalObject, so as Classes, because these activities do not take place now, but repetitively in a distant future ;
• The Part 4 Reference Data Library is one big class hierarchy, with dm:Thing at the top, and with subclasses and subsubclasses. For example: the class PUMP in the RDL has 258 subclasses ;
• The requirements for assets and other plant items are also represented in Classes. Classes have range values, where individuals have point values. For example: the class "Lightweight Boxer" has as criterium for membership that the boxer shall have a weight, right before a match, inside the range of 130-135 lb (59.0-61.2 kg), so a range value. John Doe weighs, at the "weigh-in", 60.4 kg (a point value) and is admitted to the match. Note that often an attribute may seem a point value, for example a maximum value. But it actually means a range, with that maximum value as the upper boundary and an undefined minimum as a lower boundary ;
• The manufacturers of assets and other plant items design their products in Classes, of which their manufactured products are members. Inspection means checking whether the point values of the manufactured product are inside the range values of the offered product class in the quotation.

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:

• Property - e.g. a particular degree of hotness can be represented as an instance of Property "Temperature", which may be quantified by mapping that degree of hotness to a number on a Scale ;
• A Status is a ClassOfIndividual that is a characteristic or quality that is described by discrete, unordered values, like 'open', 'painted', 'approved', 'old', 'new', 'worn', 'hazardous', 'safe', etc. Defining the criteria for membership of specializations of these classes has been done in many standards, rules and regulations ;
• A Language is a ClassOfClassOfInformationRepresentation whose members are all the information representations made in the language ;
• etc., there are 78 class types and 59 relationship classes, but you dont have to know them all, because by far most of them are used for the template graphs only.

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 PLM - Plant Life-cycle Model, 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 [46] 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 PLM instance, shall both be involved in the same Life-cycle (ClassOf)Activity. The 'Implementation' relationship is the only exception.

Architecture

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.

Mapping

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.

Status

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

What is missing in the standard? This:

• Part 2 shall be extended with a number of entity types that were left out because the document would become too thick (which is a rather strange and unacceptable reason). See here for those additional entity types ;
• Part 4 has been extended during the years, and those extension have been ISO balloted. When something is missing any user can offer one or more classes for inclusion in the RDL, and until that materializes: create an RDL extension ;
• Parts 7 and 8 need an update, reflecting the developments in the years after their first publication. In particular the focus shall be shifted from OWL to RDF. The authors discovered a better use of OWL in Part 14 ;
• Part 9 has to be developed, as an additional API for a standard, commercial, triple store ;
• Part 10 has been published, but is too conceptual to be usable for implementation. The automatic generation of SHACL "shapes" has to be investigated.

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.