This tutorial is an explanation of the paper ISO 15926 on a page
The contents reflect a 30-years experience with this standard and its precursors (ISO 10303-221 and -227), but is in no way authoritive from a standards point of view. So don't even consider to sue me. :))
Buy the standards in case you want to be certain.
Welcome to this first lesson in which I will give:
A gentle introduction of the architecture of ISO 15926
I'll start with a diagram and lead you though it:
ISO 15926
The scope of ISO 15926 is "Integration of life-cycle data for process plants, including oil and gas production facilities".
- global semantic interoperability, defined as:
"Semantic interoperability is the ability of computer systems to exchange information with unambiguous, shared meaning.
It is a requirement to enable inferencing, knowledge discovery, and data federation between information systems."
This allows applications and systems, used globally during the life of a facility, to share information. - archiving, collecting and integrating plant life-cycle information that can be used for:
- interoperability during day-to-day activities
- reasoning with integrated data
- CAE - Computer Aided Engineering
- Digital Twin software
- knowledge mining
- operations optimization
- root cause analysis
- the next revamp
- etc
ISO 15926-2 - Upper Ontology
In the ISO 15926-2 data model (further referred to as Part 2) we have 201 very generic classes in a hierarchy with 'Thing' at the top.
It covers all the entity types that are required to model that plant life-cycle (predominantly technical) information. You can find it here.
As you may note, we don't define pumps, pipes or vessels, but PhysicalObjects and ClassOfPhysicalObjects.
ISO 15926-4 - Reference Data
That is done in Part 4 where we have some generic 21,000 classes, nicely ordered in taxonomies (class hierarchies), of which some 8700 are instances of above ClassOfInanimatePhysicalObject.
RDL - Reference Data Library
ISO does not maintain Part 4 as an on-line vocabulary, so that is why we did set up the RDL. The RDL is in fact an extension of ISO 15926-4. The RDL has extensions of its taxonomies, such as the ones mentioned at the lower part of the pyramid in above image. These extensions cover nearly 18,000 classes of standardization bodies, in 22 of its extensions (see here).
The entire pyramid is in fact one large taxonomy with Thing at the top. That taxonomy isn't perfect yet, so whenever you find a glitch, please let us know.
You can find 'views' on the RDL content here. These are not claimed to show all Classes.
ISO 15926-7 Templates
The classes in the pyramid can be used to build Part 7 templates. The base templates in the set of Template
Specifications are using Part 2 classes, with a very few Part 4 classes in case of the need for fixed values.
As indicated in above diagram these templates are a kind of elementary ontologies that can be instantiated to represent an elementary piece of information, such as "Pump P-101 has a MASS of 103.6 KILOGRAM" (the terms in capitals are names of Classes in the RDL).
Anyone can define specializations of these base templates by replacing one or more variables with a subclass further down the applicable taxonomy in the pyramid.
ISO 15926-8 - RDF representation of Part 7 Templates
Although there may be many ways to represent the contents of a Template instance, the ultimate choice is for RDF - Resource Description Foundation - and RDF Schema. These are standardized formats defined by W3C - World Wide Web Consortium. Part 8 standardizes the way this is done.
Mapping
Before we instantiate a template we have to do some mapping from some data element in an application model to the applicable template. The mapping code then is used for an adapter, added to existing software. In principle that existing software and its data can remain untouched. That is important to note, because ISO 15926 is for data management, not to compete with applications, but that as an aside.
The adapter actually has two parts: one for mapping and exporting data that have been generated with the application, and one for application input by querying, importing + mapping the query results to the internal format and logic (see Part 9 below).
ISO 15926-10 - Validation
The exports from the adapter have to be validated with the methodology defined in Part 10 (details later). It is important to store validated data instead of later data cleansing. The reason for that is that the stored data are to be used as import for other applications by means of tailor-made queries, so that 'later' isn't possible.
ISO 15926-9 - Storage
Part 9, that still has to be formalized, will define the storage of the template instances in a Triple Store (or Quad Store). In Part 9 an API handles the necessary tasks to keep the store in good shape. We will see later that there are (will be) many such stores, interconnected via the internet, and they all (will) behave identically. The rules in concept for that are shown here.
SPARQL - Query Language
Actually this is where our ISO 15926 universe ends. All applications with an adapter can share information, and all (life-cycle) information is integrated and extendable, as mentioned in the scope of ISO 15926: Integration of life-cycle data for process plants including oil and gas production facilities. As far as I know there is no other standard for that.
There are some other Parts with additional scopes, mainly with the intention to perform analysis on that integrated life-cycle information using OWL reasoning. The idea is that they can, some day, fetch a selected subset of all life-cycle information and map that set to OWL-DL and subsequently perform reasoning, or forms of AI.
For example: You pull all life-cycle information for all pumps of a given manufacture and analyse under which conditions they caused problems.