Data Integration - How is it done in ISO 15926?

latest update: 2019-11-05


The title of ISO 15926 is:

Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities

This topic explains a way to achieve that integration.


When looking at the Plant Life-cycle Model we can see three domains: Class (blue), Design World (green) and Real World (yellow). Please make sure you read Possible Worlds.

Of course this is not the entire model of a plant, it is a skeleton for one plant item (not really, see later) during its entire cradle-to-grave existence.Def

Design and Engineering

First we address the Design and Engineering side of the above model:

  1. On a functional diagram, such as a P&ID, a PUMP SYSTEM is shown with a tag P-101. It is an InanimatePhysicalObject, a WholeLifeIndividual, a NonActualIndividual, and a PUMP SYSTEM .
  2. We use the TIP Declaration of Individual, that declares three things together (they eventually are deprecated together as well): P-101 (17), its functional aspects class (CFIHOS “Tag Class”) CO_P-101-FO (14) and its physical aspects class (CFIHOS “Equipment Class”) CO_P-101 (21)
  3. (14) and (21) are “anchors”, a kind of ClassOfWholeLifeIndividual. As can be seen both are a subClassOf PUMP SYSTEM (9) from which they inherit the generic OIM (Object Information Model) that shows, with Cardinalities range starting with zero, all possible components. Except for meta data and a service description (which actually is meta information) nothing else shall be attributed to (17), (14) or (21). Whatever is added shall be added to their (class of) temporal parts (17a), (17b), (12), and (19).
  4. Temporal parts of (17) will, for the most, occur for the topological information around that InanimatePhysicalObject, as found on the P&ID and sometimes on the 3D model (mainly piping components that are not shown on a P&ID).
  5. ClassOf(temporal)Part (12) defines the functional requirements for P-101. The story behind that covers most of the diagram:
    • Functional design is done with ClassOfActivity (1) models (“Unit Operations”) in which an instance of ClassOfFunctionalObject (10) participates in the Role of PERFORMER (11), and a ClassOfStream (5) participates in the Role of SUBJECT (6) *);
    • the ClassOfFunctionalObject is being represented on a PFD – Process Flow Diagram (8) which most often show the stream information in data blocks;
    • the ClassOfStream is being represented on a Heat & Material Balance (3), a document on which the plant design is based;
    • now ClassOf(temporal)Part (12) of (14)  is also a ClassOf(temporal)Part of (7) . This makes the link between the Functional Design to the Plant Design in that it defines what the function shall be;
    • however, these functional data are purely theoretical and don’t include the margins that an engineer requires for the equipment to operate properly. Engineering standards may presribe, for exaple, a 10% overcapacity;
    • that is done by a Process Engineer who issues a Process Data Sheet (13) with these marked-up process conditions. These define the Functional Requirements Class (12).
  6. Finally to the Requirements Class (19) which is a ClassOf(temporal)Part of (21) and a subClassOf the FunctionalRequirementsClass (12) . It is defined by means of a Technical Specification (20), for example an API 610 Centrifugal Pump Data Sheet
  7. But where did the information come from that it is a CENTRIFUGAL PUMP SYSTEM? And where the applicable OIM? After the Requirements Class (19) has been declared as subClassOf PUMP SYSTEM it can be specialized to CENTRIFUGAL PUMP SYSTEM and inherit the generic OIM for the latter, that in turn has inherited the OIM of PUMP SYSTEM. That generic OIM then can be specialized for CO_P-101, in line with the Technical Specification (20) . Note that whenever the choice of pump type changes outside its taxonomy, (19) is to be deprecated and a new (19) shall be declared (with a different Technical Specification type (20).

*) other participants are possible, such as some metal oxide in the role of CATALYST.


There are three steps to be taken:

  1. Determine the Individuals or Classes, that are shown or implied on functional diagrams, such as a PFD, P&ID, Control Diagram, One-line Diagram, etc. and declare those objects;
  2. Determine the interrelationships (mainly connections) between these objects and represent those with templates;
  3. Attribute information, that is exclusively about an such object, to that object using the applicable templates; this is preferrably based on an agreed-upon Product Model.

Actual World

The Individuals in the actual world around us are on the righthand side of the overall model:

  1. The Procurement Activity is at both sides dealing with abstractions: a Product Requirements Class (19), as defined Technical Specification (20 ) at one side, and a offered Product Class (38), defined in a quotation, of which one or more members are to be purchased. Because of these abstractions, that cannot physically participate in any Activity, they are InvolvedByReference.
  2. Based on the successful ClassOfPhysicalObject (38 ) individual PhysicalObject (51) is manufactured (not always true, e.g. when taken from stock, but once manufactured nevertheless);
  3. A temporal part (53) is inspected and shipped to site and registered as an Asset (54) (not all PhysicalObjects are registered as such, but they are there anyway).
  4. On site a temporal part of (54) is being installed as temporal part (55). This installed plant item (55) serves as temporal whole for a temporal part (60 ) that participates in a process activity (61)
  5. Another paricipant is Stream (62 ).
  6. When required (55) is, at a different time, also the temporal whole of (70) which participates in an in-line maintenance activity (71).
  7. When the installed object gets defective that temporal part of (54) is uninstalled and a new temporal part (80) participates in a shop maintenance activity (81).
For easy reference all TemporalWholePart relationships have been marked in red. See also the topic Temporal Parts.

Upper Ontology, Elementary Ontologies and Object Information Models

All information is modeled on the basis of ISO 15926-2, which is an Upper Ontology where all 200+ entity types are interlinked and are subtypes of Thing.
The templates of ISO 15926-7 are elementary ontologies that use entity types from this Upper Ontology and use the Relationships of same.
The things that are the variables in a template are declared as instances of the entity types in the Upper Ontology.
The Upper Ontology can be extended in the Reference Data Library, inclusive of Object Information Models that use template instances.
This rigourous approach contributes to the required integration.