An analogyIn 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 modelThe 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 dataThese "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, and enter the word 'pump'. 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 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 methodologyParts 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. RDFThe 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:
OWLRDF 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:
Any deviation from that rule will result in an error message or other action. ISO 15926 + RDF + OWLEven 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://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003 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 Parts 7, 8 and 9Below 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.
TemplatesReferring 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. Specialized TemplatesThe templates defined in the Template Specifications are generic. We can 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. Specialized templates 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!). A set of specialized templates forms an "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 specialized templates to the taxonomy of ISO 15926-4 and get a close-to-perfect ontology. User-defined OntologyEven 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çadesWe 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 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, 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:
MappingFinally 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-9 (Part 9 is still under development). 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:
ConfigurationThe components discussed above are combined in the following typical configuration:
This diagram is used throughout this site for navigation purposes. EpilogThis 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. Further readingClick here for a paper that is based on the above and other material. |
