How does pump P-101 fit in?

latest update 2024-05-03  

Introduction

This topic is to show how our proverbial pump P-101 fits in ISO 15926.

Graph

Description

The blue part shows a subset (~10%) of the ISO 15926-2 data model, starting with ClassOfIndividual and PossibleIndividual. These are specialized as shown.

The RDL - Reference Data Library in the green part contains instances of the subclasses of ClassOfIndividual (and many other things that are not relevant in this context). These are also subclasses of subclasses of PossibleIndividual (see ARTEFACT in above diagram).

Most instances of (subtypes of) ClassOfInanimatePhysicalObject start, in the top of their hierarchy, with being a specialization of an instance of ClassOfFunctionalObject. In above diagram CENTRIFUGAL PUMP SYSTEM is a subclass of the instance PUMP SYSTEM of ClassOfFunctionalObject. (NOTE - a PUMP SYSTEM has a BARE PUMP as a part).

CENTRIFUGAL PUMP SYSTEM, or any of its many subclasses (not shown) is the superclass of a so-called Requirements Class in the brown part, often defined in a Specification (here, in this example for pump P-101, such as an API 610 Pump Data Sheet).

That Requirements Class classifies pump P-101 in the ochre part, or actually a temporal part thereof. How this is done has been worked out in the topic "Plant Life-cycle Model"

P-101 is an instance (member) of PUMP SYSTEM (its essential function), InanimatePhysicalObject, WholeLifeIndividual, and NonActualIndividual (because it exists in the Design World, see the PossibleWorlds topic).

Already on the P&ID it is shown with the symbol of CENTRIFUGAL PUMP. So we classify a temporal part as such. Later, when the specification has been declared, we classify another temporal part with that Requirements Class.

Another view

Below are two diagrams, in which the same pump is further specialized, and related to its real-world implementation.
Also a similar diagram for the specification for that pump. These diagrams are assumed to be self-explanatory.


It appeared that these diagrams have been misunderstood, so a top-to-bottom explanation seems necessary.

The Standards

The following standards are playing a role:

So far all this is readily, and free of charge, available on the internet.

That purple box is an instance of ClassOfInanimatePhysicalObject that usually is defined by means of (here) the API/ANSI 610 Standard 610 and the related API Std 610 Centrifugal Pump Data Sheet.

The implementer can chose to use that data sheet as document for the Class definition, or to define the pump Class with Template instances. Important is to know that the boxes shown are placeholders to which these definitions are to be attributed.

The Project Data

The Pump

The three green boxes are representing "Requirement Classes", instances of ClassOfInanimatePhysicalObject that are specializations of the Class represented by the purple box. All deprecated information remains in the triple store as historical information.

Those three green boxes are representing revisions 0, 1, and 2 of that pump ClassOfInanimatePhysicalObject, corresponding with revisions 0, 1, and 2 of the related API Std 610 Centrifugal Pump Data Sheet. They are related by means of an instance of ClassOfTemporalPartWhole to the darkgreen "anchor" pump Requirements Class. The latter has no attributed information, but is a fixed reference point that remains in place forever and is only deprecated when the individual pump is being deprecated.

At the bottom we find the "anchor" Individual pump P-101, alias "Tag", alias "Functional Location", that is represented on a functional diagram, such as a P&ID. Again, that anchor has no attributed information. It is declared as member of dm:InanimatePhysicalObject, of dm:WholeLifeIndividual, and of dm:NonActualIndividual. This means, in other words, that it is a physical object that is not a living organism, it cannot be a temporal part of something else, and it exists in the Design & Engineering World (see here).

Our "anchor" Individual pump P-101 has a Temporal Part that is the only temporal part of a NonActualIndividual that is explicitly declared, for the reason outlined below. All other temporal parts are made an integral part of template models and don't have to be declared.The reason why this temporal part is required is that it has two informations attributed to it, via integral temporal parts in the template model:

So it tells which revision of the Requirements Class is implemented by the installed actual Asset.

The Pump Data Sheet

As can be seen the diagram for the document has the same structure as that for the pump. Where the values of the API Std 610 Centrifugal Pump Data Sheet, representing the purple box, are empty ("fill in the blanks"), these value are entered for the green boxes. A new revison deprecates the previous one.

The Actual World

An member of a Manufactured Product Class has been manufactured, and is declared as a member of dm:InanimatePhysicalObject, of dm:WholeLifeIndividual, and of dm:ActualIndividual. This means, in other words, that it is a physical object that is not a living organism, it cannot be a temporal part of something else, and it exists in the actual world around us.

Our manufactured object has a temporal part that is called "Asset" (whether or not you maintain an asset register of it), and this Asset has a temporal part that is installed (and commissioned, where applicable). The installed object has a temporal part that plays its role in a process activity, such as (here) PUMPING. For futher details see here.