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.
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
Design and Engineering
First we address the Design and Engineering side of the above model:
- 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 .
- 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)
- (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).
- 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).
- ClassOf(temporal)Part (12) defines the functional requirements for P-101. The story behind that covers most of the diagram:
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
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).
- 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).
participants are possible, such as some metal oxide in the role of CATALYST.
There are three steps to be taken:
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;
Determine the interrelationships (mainly connections) between these objects and represent those with templates;
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.
The Individuals in the actual world around us are on the righthand side of the overall model:
For easy reference all TemporalWholePart relationships have been marked in red. See also the topic Temporal Parts.
- 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
- Based on the successful
ClassOfPhysicalObject (38 ) individual PhysicalObject (51) is
manufactured (not always true, e.g. when taken from stock, but once
- 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).
- 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)
- Another paricipant is Stream (62 ).
- When required (55) is,
at a different time, also the temporal whole of (70) which participates
in an in-line maintenance activity (71).
- 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).
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.