Introduction to ISO 15926                                                                                                    

latest update: 24 april 2014 

An analogy

In today's world we often see that people from all over the world can communicate in meetings and on the Internet. This is possible despite the fact that many of them speak another language back home. In those meetings and on the Internet they use a common language, be it English, Spanish, Chinese, or any other major language.

Computer systems also speak their own language internally, and as such can only communicate with other systems by means of interfaces. The number of interfaces grows exponentially with the number of systems. If you have two systems you have, for each system, one interface. But if you have ten systems you already have, as a maximum, 90 interfaces.

This is, at present, the common situation. The cost for setting up and maintaining all these interfaces usually is in the order of 70% of all IT costs.

Through the years this problem hasn't been solved. Sure, we see an abundance of application-to-application interface tools, but they don't really help to solve that problem, because they keep being, for the most, application-to-application.

So, now we teach all our systems one common language.

This language can be anything, if you do not have more requirements.

Why ISO 15926?

Back in the early nineties an international group of companies, active in the process industries, embarked on a long quest for the grail of a full integration of all lifecycle information about facilities (oil refineries, chemical plants, platforms, etc).

The requirement of wanting to integrate lifecycle information for the facilities means that we had to cope with the fact that:

  •     the number of different application programs is very large;
  •     the terminology for the various phases in that life cycle are widely different;
  •     we need a stable standard that will be there for decades.

ISO 15926-2 data model

The ISO 15926-2 data model, stable since 2003, has been designed specifically for this purpose. It is highly generic, which can be explained as follows. If you break data down to "atomic" level, you can create many combinations from these "atoms", just like you can create 100 combinations from 20 objects in a 10x10 matrix.

The data model only knows 201 "entity types", like ClassOfInanimatePhysicalObject and PhysicalObject. Because information is a particular relationship between known things, half of these entity types are Relationships or ClassOfRelationship.

If you are curious to see some of this data model, click here.

The data model is a kind of "grammar". But grammar without words doesn't build sentences. So we need "words".

ISO 15926-4 reference data

These "words" come in the form of "reference data", such a "Pump", "GateValve", "DesignPressure", "barg", etc. These are defined in ISO 15926-4 and stored in the RDL - Reference Data Library.

Now we can model sentences like: myPump isA CentrifugalPump, and many other, more complex ones, like: "stream AK-14 at the inlet of control valve 21-FV-145 has an pressure of 12.76 barg at normal flow conditions".

These "core classes" are organized in class hierarchies, with "superclasses" and "subclasses". An example from daily life is the "Vehicle" taxonomy.

In case you wouldn't totally agree with this taxonomy, you noticed where this can go wrong: there is not a single "correct" taxonomy. So if you want to use a taxonomy on a global scale, you simply must standardize it with a globally recognized organization, like ISO. If it would be wrong, at least we all are consistently wrong.

If you can't wait: click here to have a peek.

Now what?

This is all very nice, but how do we achieve that integration? What was still missing was an implementation methodology.

To set the scene, let us try to imagine the complexity that must be mastered. Take, for example, the case of large EPC contractors (EPC = Engineering, Procurement, Construction).

These contractors have many projects in execution, and these projects range from single-person projects to project involving thousands of persons. The larger projects often are handled in a Joint Venture with one or more other contractors, each having their own working methods and their own computer systems. Even when they would all use the same commercially available system, these are invariably configured (tweaked) differently to suit the requirements of their working methods.

Each contractor has some ten different disciplines (Process, Mechanical, Control Systems, Structural, Electrical, etc.), and may work on a project from more than one of its offices worldwide.

Then we have hundreds of suppliers, ranging from mom-and-pop shops to very large internationally operating companies. The suppliers are in fact the largest contributors of information that must be integrated at the end of the project.

There are also subcontractors, requiring data and generating data, all with their own software.

For the work also data are required from standardization bodies, like DIN, ASME, etc. Mostly available on paper only, or at best 'electronic paper', no data base....

And, last but not least, there is the plant owner/operator, providing data and requiring the integrated data at the time the plant, or parts thereof, are turned over to him. During a revamp project the information about the plant-to-be-revamped even changes, and since it is hard for the plant owner to properly inform the contractor(s) on those changes, often unpleasant surprises occur on the construction site.

ISO 15926 implementation methodology

Parts 7, 8 and 9 of ISO 15926 define an implementation methodology for ISO 15926 at large, that is based on the Semantic Web ('SW') technologies of W3C (W3C = World Wide Web Consortium).

It appeared that the generic nature of the Part 2 data model and the equally generic nature of RDF and OWL, the major SW languages, are a close fit.

Let's first see, in a nutshell, what RDF and OWL are about.

RDF

The core of RDF (Resource Description Framework) is the "triple": subject - property - object

As said above "information is a particular relationship between known things", that is exactly what a triple does. The 'property' actually is a relation. It tells something about the subject and uses the object to be specific. An example:

John - isFatherOf - Sue

The lifecycle data of a plant will be represented with billions of such triples, stored in "triple stores". For that reason the way this information is represented shall be as rigourous as is possible. That has been one of the leading principles when setting up the ISO 15926 implementation technology.

One of the drawbacks of RDF is that everybody can dream up such triples, with their own ideas about naming conventions and data modelling. Therefore, using RDF alone predictably leads to the miscommunications we already have. The next steps are:

  • setting up Vocabularies, using the Reference Data of ISO 15926-4;
  • using OWL in combination with ISO 15926.

OWL

RDF has some limitations, such as the fact that it does not support "inheritance" (see below).

Inheritance is related to specialization. If Class A is a subclass (specialization) of Class B, then all members of A are also members of B (all individual Volkswagen Beetles are members of the Class "Volkwagen Beetle", but also of its superclass "Car"). All information about the superclass also applies to the subclass.

For each Class "criteria for membership" have been defined.

Specialization of a Class implies that you constrain the criteria for membership that apply for the superclass, or that you add new criteria. For example: for 'Car' the information that it has wheels as parts, for Volkswagen Beetle the 'wheel size' will be given as an extra constraint to just 'wheels'.

OWL does support inheritance of information represented by RDF triples.

ISO 15926 + RDF + OWL

Even when using OWL true lifecycle information integration, stretching over decades, will be illusionary.

If we combine the rigo(u)r of ISO 15926 with the power and flexibility of the Semantic Web technologies, we can achieve our goals.

So we mapped (translated) the data model of ISO 15926-2 to OWL. If you are really curious, you can have a peek here.

ISO 15926 Parts 7, 8 and 9

Below is an overview of the layers of the ISO 15926 implementation stack. In the next pages of this website this stack will be discussed in detail.

 

Templates

Referring to the RDF concept of "triple" we may define a template as a standard addressable set of triples that together represent some information that is more complex than just a triple.

For example we have the template ClassOfIndividualHasPropertyWithValue:

Generic template class

This is fully generic, any (valid) combination of the Part 2 entity types ClassOfIndividual, SinglePropertyDimension, ExpressReal and Scale will be valid representations of information. We call that combination the "signature" of the template class. In this example it is a combination of four RDF subject-property-object triples with a common subject, being the template class. Any such template class is standardized and defined in a Template Specification such as this one.

A member of that template class shall then have a signature with members of the four objects in the template class.

For example:

Template instance

'ACME Model FD372' is a member of dm:ClassOfIndividual, 'mass' is a member of dm:SinglePropertyDimension, etc.

Specialized Templates

The templates defined in the Template Specifications are generic. We can specialize them, to make them precisely applicable for a particular class. A possible example is the case where a company wants all units of measurement in SI units. That company may then set-up their own extension of the RDL. Using above example that template class will then be specialized in that the Scale is specialized to  SI-Scale. If that specialized template would be instantiated and someone would fill out 'lbs' rather than 'kg' it would be recognized as incorrect.

Specialized templates are usually defined by teams of domain experts. Much work still has to be done, and it can only succeed if the entire industry actively participates (don't wait till others have done the work!).

A set of specialized templates, in which a particular Class plays a role (i.e. these templates are "about" that Class), forms an "ontology" of that Class. A (there are many) definition for "ontology" is:

An ontology is a controlled vocabulary that describes objects and the relations between them in a formal way, and has a grammar for using the vocabulary terms to express something meaningful within a specified domain of interest.

So, we add the specialized templates to the taxonomy of ISO 15926-4 and get a close-to-perfect ontology.

User-defined Ontology

Even that close-to-perfect ontology will, at times, not be complete enough. What if a supplier of centrifugal pumps wants to describe his products? He will need to further specialize the classes and templates that he finds in the Part 4 ontology. This is possible. We will see later how he can publish that on the Internet.

Use Cases

We still haven't discussed how all these niceties are deployed on the Internet.

First the information, that is represented in some application in a proprietary format, must be mapped (see below).

Then there are two ways to do something useful with that mapped information:

  1. use in for application-to-application interfacing;
  2. store it in a triple store ("Fašade") and use it for:
    • lifecycle information integration;
    • information sharing by means of selective queries.

Interfacing

This is the core business of iRING. You can find all information on: http://iringug.org/wiki/index.php?title=IRINGTools

Fašades

A Fašade is a web server that can store RDF triples, and that has a standard set-up and API (Application Programming Interface).

the interaction of fašades

All fašades are standard and logically identical. Their technical implementation may be different (e.g. in  Java), but they behave in the same manner.

Important to know for now is that all fašades can communicate with each other, IFF allowed. That "IFF" is important because for security reasons we may not want this unlimited "promiscuity". Who may do what is controlled by a so-called CPF server. CPF stands for Confederation of Participating Fašades. On large projects such a confederation may include hundreds of fašades.

In a CPF we can also control the normal flow of data, from the initial application systems to, finally, the "Facility Fašade" of the plant owner/operator. The picture below shows an example. In reality you can decide yourself how these data flows shall take place.

the Information Chain

Next to this "hand-over" there will be two more features (the second still to be decided):

  • from any computer you can launch a SPARQL query, collecting information from one to many fašades inside a particular CPF, that defines your access rights;
  • from any fašade you can send an e-mail with one to many PDF document (e.g. Request For Quotation with a set of data sheets), along with credentials that allow the recipient to fetch the data shown on these documents, for use in his own computer system(s).

Mapping

Finally we address the question how all these data come into one of the fašades on a CPF. Well, we started out with the subject of interfaces. And we end with that subject. Remember that only one interface is required? That would entail mapping from the data in your system to a format defined in ISO 15926-8.

This mapping is not, and cannot be, controlled by ISO 15926, simply because there are zillions of different application systems, that all have their own peculiarities. For the mapping of your system you need a person that understands the semantics of your data and understands enough of ISO 15926.

The mapping involves:

  • mapping of (mostly physical) objects (pumps, pipes, instruments, streams, etc) to entity types of ISO 15926-2 and classes in ISO 15926-4.
  • mapping data about those objects to specializd templates that can be found in the applicable ontology. So, if the physical object is a centrifugal pump, the mapping is to one of the specialized templates in the ontology for CentrifugalPump. This means: no specialized template - no mapping (not quite true, but without predefined specialized templates it is a lot more difficult and error-prone).

Configuration

The components discussed above are combined in the following typical configuration:

Epilog

This introduction was written to give you a first impression of ISO 15926 in general, and of its implementation in a Semantic Web environment in particular.

If you missed something, or something was unclear, please help me to improve this introduction by sending your feedback to:

In the rest of the pages of this site more details will be discussed.

Further reading

Click here for a paper that is based on the above and other material.