INTRODUCTION

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. 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.

ISO 15926-4 will also have reference individuals, like geographical objects (e.g. London, UK), organizations (like the United Nations, or the XYZ Corporation), persons (like Albert Einstein), etc. At present this part has not yet been addressed.

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 the 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-7 - implementation methodology

Part 7 of ISO 15926 defines an implementation methodology for ISO 15926 at large, that is based on the new 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 ISO 15926-7.

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 deals with "individuals", for the most the things that exist around us. With OWL (Web Ontology Language) we can define "schemas", that prescribe how a particular chunk of information shall be represented in RDF.

For the above example we now can define, in OWL, that the property 'isFatherOf' shall have:

  •     a subject that is a member of a class called "MalePerson", and
  •     an object that is a member of the class called "Person" (of which MalePerson and FemalePerson are subclasses).

Any deviation from that rule will result in an error message or other action.

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, for starters, we mapped (translated) the data model of ISO 15926-2 to OWL. If you are really curious, you can have a peek at:

http://www.tc184-sc4.org/ts/15926/-7/ed-1/tech/dm/data_model.xml

The next step, that at present is being worked on, is to map the entire Reference Data Library of ISO 15926-4

(see http://projects.dnv.com/reference_data/RD7Browser/ for its present format) to OWL as well.

ISO 15926 Part 7

Now we come to the topic of this lecture: ISO 15926 Part 7, be it that for now we will only give an overview. In the next pages of this website this standard will be discussed in detail.

Let us start with the "the ISO 15926 stack":

Part 7 of ISO 15926 covers layers 5 to 2 inclusive. We will briefly address them.

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.

Using the earlier example of John being the father of Sue, we might define a template for "family", such as:

 

Template = n-ary relation (here: n=5)

The template instance shown here can also be defined in OWL. The templates that are standardized are defined in Template Specifications, and the OWL code can be found on the Internet: http://www.tc184-sc4.org/ts/15926/-7/ed-1/tech/tpl/templates.xml .

OIMs - Object Information Models

The templates defined in the Template Specifications are generic. In the OIM ontologies we specialize them, to make them precisely applicable for a particular class in the taxonomy of ISO 15926-4.

So, for example, we define for the class CentrifugalPump:

OIM (partly) for the class CentrifugalPump

All things we can say about a centrifugal pump throughout its lifetime, and for which there is a business need, are then represented with a set of specialized templates in which the centrifugal pump plays a direct role. That set of templates is dubbed the "OIM" of that class.

OIMs are 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!).

An other, more common name, for OIM is "ontology". 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 OIMs 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.

Façades

We still haven't discussed how all these niceties are deployed on the Internet. For this the concept of "Façade" has been designed. A Façade is a web server that can store 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 a different language like Java), but they behave in the same manner.

Important to know for now is that all façades can communicate with each other, IF allowed. That "IF" 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 are two more features:

  • from any façade to any other façade you can send a Message with one to many read-only Documents included (e.g. Request For Quotation with a set of data sheets)
  • 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.

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-7.

This mapping is not, and cannot be, controlled by ISO 15926-7, 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-7.

The mapping involves:

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

In case you are really curious how that looks like, you may peek at:

http://www.infowebml.ws/descr/facade/transfer-from-user-application.htm

Configuration

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

This diagram is used throughout this site for navigation purposes.

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 to improve this introduction by sending your feedback to:

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

More introductionary material can be found here.