latest update: 24 april 2014
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:
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.
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.
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:
RDF has some limitations, such as the fact that it does not support "inheritance" (see below).
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.
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.
'ACME Model FD372' is a member of dm:ClassOfIndividual, 'mass' is a member of dm:SinglePropertyDimension, etc.
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.
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.
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:
This is the core business of iRING. You can find all information on: http://iringug.org/wiki/index.php?title=IRINGTools
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):
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:
The components discussed above are combined in the following typical configuration:
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.
Click here for a paper that is based on the above and other material.