In this topic the relationships between the design world and the actual world will be discussed. Some modeling at Class level is necessary for proper understanding.
The following model is the Plant Life-cycle Model. Its implementation will be discussed in this topic.
Where the model shows ClassOfPhysicalIndividual that can in real life be a subtype thereof: ClassOfInanimatePhysicalObject, ClassOfOrganization, ClassOfPerson or even ClassOfOrganism (e.g. for 3D-printed organisms).
Since it is important to fully grasp what this model intends to represent the explanantion below will be done by using templates.
The imaginary Design World
We start with the part of above life-cycle model that describes the imaginary world of designed objects.
A designed object (18a) is deemed to start its existence as an instance of dm:PhysicalObject that is a member of dm:WholeLifeIndividual. It then gets a Tag Number. There is no further information attributed to it. All such information is attributed to temporal parts. Usually a subtype of dm:PhysicalObject is being selected: InanimatePhysicalObject, InformationObject, Person, Organization, Organism, or Feature. All six have the lci: prefix.
We start with a temporal part (15) that is an instance of the Part 2 entity type dm:FunctionalPhysicalObject ("FPO") (a subclass of dm:PhysicalObject). There is no further information attributed to it. All such information is attributed to its temporal parts.
That FPO normally is shown on some kind of Functional Diagram (15a). For process equipment that is a P&ID (Piping & Instrument Diagram). On such diagrams its place in the plant topology is defined. See Mapping of a P&ID.
This FPO is a member of an instance of ClassOfFunctionalObject (14), purely defining the functional requirements ("what shall it do? So what state transition shall it cause (here on a Stream)?"). For the pump P-101 in the examples these functional requirements are defined with "operating conditions" by the Process Engineers. These are generated by simulators and marked up for regulatory reasons (e.g. an overcapacity as required by client rules). These operating conditions are shown on data sheets (specifications) such as this sample from the API 610 Centrifugal Pump Data Sheet:
Now we address the physical aspects of our designed object. In fact these include the functional aspects by inheritance (16 is a subclass of 14).
We create another temporal part of our "anchor" dm:PhysicalObject. That temporal part is an instance of dm:MaterializedPhysicalObject ("MPO") to which the physical aspects are being attributed.
This MPO is a member of an instance of dm:ClassOfPhysicalObject or a subtype thereof: ClassOfInanimatePhysicalObject, ClassOfInformationObject, ClassOfPerson, ClassOfOrganization, ClassOfOrganism, or ClassOfFeature. There is no further information attributed to it. All such information, mainly as represented in a 3D model or derived documents like isometrics, is attributed to its temporal parts (when no longer valid, the temporal part is deprecated).
All other requirements are defined at class level in a class (13) of temporal part of the "anchor" class (16).
Similar to INSTALLING Activity (23) causing the installed asset (22) on the first diagram above, this can be modeled in a similar way for (15) and (17) causing (18b). Read more on this. This will be the subject of a separate topic.
At times the PhysicalObject (18b) will, as we will see below, have a counterpart in the real world.
The Real World
Now we have a look at the real world part of the first diagram:
It can be seen that the real world has many links to the classes. These will be discussed as well.
The model part in the righthand top shows how to model options. The definition of ClassOfPhysicalObject (32) excludes the definition of the options #1 (33), #2 (34), and #3 (35). Since any of those options is a subclass of (32) each option inherits its information that is common to all options.
The applicable options are then collected, by classification, in an instance of dm:EnumeratedSetOfClass. Subsequently we use one of the esoteric entity types of Part 2: UnionOfSetOfClass. Its "result" is the derived Product Class (37) including, in the example, options 1 and 3. This is technically what is being offered by the supplier. A class of temporal part thereof (38) includes commercial and logistics information, so is the product that is referred to in a quotation. Note that a class is being offered, rather one or more, yet unnamed, members of that class.
This model can also be used in Process Engineering and Plant Design to model Modes of Operation and the related plant line-ups. This is being discussed in the topic Operational modes and Catalog options (will be revamped).
The rest of the model is essentially the same as discussed for the design world. One extra is the use of dm:IntendedRoleAndDomain. This could be instantiated by the supplier to confirm that his product functionally complies with the design intent of the client (9).
In the Procurement Activity (41) the "anchor" Requirements Class (16) is "involved by reference" to define the scope of the RFQ (Request For Quotation). And when the quotations arrive that can be recorded as an dm:InvolvementByReference relationship between the quoted class (38) and the Procurement Activity (41). Obviuously there is much more to procuring, but this will do in this context.
The manufacturer makes an actual physical object (19) that is a WholeLifeIndividual and a member of the required product class (37). A temporal part of it (20) is being functionally and physically tested and when it is OK, it is a temporal part of (40) and (19) and in principle ready for shipment.
When the actual PhysicalObject arrives at the site a temporal part (21) of it is registered in the Asset Register. Being a temporal part, it inherits all information attibuted to (20), (19), and (40). The Asset (21) is a member of the offered instance of ClassOfPhysicalObject (38). If not, the Inspector didn't do his work. If the Asset (21) fulfils the design requirements it is classified with the ClassOfPhysialObject (13) that was involved by reference in the Procurement Activity above.
The INSTALLING Activity (23) causing the Event (24) that begun the installed temporal part of the Asset (22). This is a Counterpart of the designed PhysicalObject (18b). The Counterpart relationship does not mean that both sides are identical (being each in its own world). That being identical with respect to funtional and physical characteristics that is put on record with the Classification relationship between Asset (21) and ClassOfPhysialObject (13), as stated above.
NOTE - The dotted actual FunctionalPhysicalObject is, as such, correctly modeled, but since it comes and goes together with its temporal part (22) and since, being a WholeLifeIndividual, no information is attributed to it, its declaration is deemed of little use.
A temporal part of the installed Asset (22) now participates in an operational activity (26), here PUMPING of a Stream (27). In case that Stream fulfils the criteria for membership of the ClassOfStream that is recorded on the Heat & Material Balance (3), a Classification relationship can be put on record to show that the plant works as designed.
The installed Asset (22) is participating in an On-site Maintenance Activity (29) in case that asset is not de-installed for that maintenance.
In case an Asset needs to be de-installed for participation in Shop Maintenance (31), that Asset is deemed to have returned in the Asset pool, so to be (21) again.