latest update: 2 June 2018
This topic deals with the Life-cycle (Activity) Model of a Plant:
The data model shown below is clearly a "back bone" model for the integration of life-cycle plant information.
First the model is shown, and then each Life-cycle Activity is discussed.
Before reading this topic it is advisable to visit topic "Temporal Parts" first.
This first part of the lifecycle has the following model:
Process Design deals with hydraulic networks, with Unit Operations and Streams of Matter and Energy (blocks  and  above).
The BFD (Block Flow Diagram, source: The Engineering Toolbox and OSHA) shown below gives an example:
Participating in those Unit Operations (= ClassOfActivity) are those Stream classes (e.g. Waste Water). This can be modeled by using the template ClassOfParticipationDefinition. So in above BFD the tag P14 at Node 06 it can be seen that stream S11 participates in the role of 'input' and stream S12 in the role of 'output' (so in this case two instances of that template). See for further details the topic Process Design.
An important end product of Process Design is a document (or file) called Heat & Material Balance, giving all details about the streams:
Under Conceptual Engineering also belong engineering activities like Start-up Sequencing of electric motors, or also Logic Diagrams, as shown above. Such Logic Diagrams spell out the required functionality, but not its physical implementation (e.g. in software, solid state logic, or relay system).
Process design results, next to the documents already mentioned, in PFDs (Process Flow Diagram, block  in the above first graph).
In fact these are more detailed Activity Diagrams, where symbols for the instances of ClassOfFunctionalObject are shown (block  above), thereby implying the ClassOfActivity that those instances of ClassOfFunctionalObject are capable of performing. Unfortunately PFDs are often mistaken for a kind of simplified P&IDs.
Logic Diagrams like this, are also a part of Conceptual Engineering:
The Heat and Material Balance document , prepared during Process Design, gives estimated values for the inflow and outflow of energy and mass respectively.
A class of temporal part of "P14 in Role as PERFORMER"  is an instance of ClassOfFunctionalObject  that is being represented on a Process Data Sheet PD-39452 .
NOTE - The ParticipatingRoleAndDomain  is in fact a ClassOfFunctionalObject in a Role, and for that reason it can be specialized as such.
The actual representations have not been modeled here.
That Process Data Sheet, as input for Detailed Engineering, is prepared during Process Engineering, and based on the Heat & Material Balance data. Where required safety margins and engineering rules are being applied.
ClassOfFunctionalObject  is also a class of temporal part of ClassOfFunctionalObject  that is the "Ur"class of P-101  . It defines the functional requirements for P-101 (the model around P-101 will be discussed later in this topic).
Any time those process data would change, resulting in a next revision of the Process Data Sheet  a new class of temporal part of ParticipatingRoleAndDomain  will be created as well as a new ClassOfFunctionalObject  thus passing those new functional requirements to Detailed Engineering.
As stated above, the Process Engineers are taking the stream data from the Heat & Material Balance and are defining the process conditions that apply for the plant items (equipment, piping, and instrumentation) that will be in contact with those streams. For example these Operating Conditions for a pump:
These conditions may include adaptations caused by engineering rules, such as a required overcapacity, safety margins, etc.
Schematic diagrams are being produced, like the P&IDs (Piping and InstrumentDiagram), Instrument Loop Diagrams and Electrical Schematics. Then three-dimensional plant models are made, that define the exact shapes and locations of the piping and pipe supports. From this the Isometrics for piping are produced.
Our pump P-101  is a designed object that exists in the Possible World of Design. It is declared as:
P-101  has, over time, instances of
The FunctionalPhysicalObject  is represented on a P&ID , whereas the MaterializedPhysicalObject  is represented on a 3D model .
The definition of the functional aspects is attributed to an instance of ClassOfFunctionalObject , whereas the definition of the physical aspects is attributed to an instance of ClassOfPhysicalObject  (or a subtype thereof).
In order to warrant that the functional requirements are met by the physical requirments the ClassOfPhysicalObject  is a subClassOf the ClassOfFunctionalObject  (that is: between class of temporal parts thereof).
Starting with the process data, that are inherited from  , the specification  for the hardware is being written. This includes physical requirements, such as material of construction and explosionproofing .
Let us have a closer look at the applicable part of the model:
The "whole-life" ClassOfFunctionalObject  is an empty placeholder (anchor) that never changes. The information is attributed to a class-of-temporal-part of it  (see Life cycle of a Class) for the functional (process) data defined by the Process Engineer in the Process Data Sheet for the FunctionalPhysicalObject .
The "whole-life" Physical Requirements Class  is an empty placeholder (anchor) as well that never changes. The information is attributed to a class-of-temporal-part of it  for the technical requirements defined on the Technical Specification . (see Life cycle of a Class.)
In case the physical requirements change,  is being deprecated and a successor being created. That successor is representing the requirements starting from then on. That new class of temporal part  is automatically made a subclass of the ClassOfFunctionalObject  that is valid at that time. This means that the "Process Conditions" and the liquid characteristics are inherited. NOTE - In the old paper paradigm this meant that the Process Engineer was filling out those sections on the Pump Specification.
On the other hand, in the event that the ClassOfFunctionalObject  is being replaced by a newer class of temporal part, the ClassOfPhysicalObject  shall replaced with a newer class of temporal part, where the latter is a subclass of the former again.
The ClassOfPhysicalObject (COPO) (30) is the "Ur"class without any further attributed information.
It has two class of temporal part Classes:
That (COPO) (32) covers everything that is common for all options, so without any option.
The COPOs (33), (34), and (35) are defining the options (there may be fewer or more options of all different types, car catalogs usually are that option-rich).
Each of those COPOs (33), (34), and (35) inherit the common definitions of (32).
Now we have to collect all selected options (here (33) and (35)) by classifying them with the same instance of EnumeratedSetOfClass (36).
Finally we create a union of those enumerated classes (33) and (35) , thus eliminating the multiplicity of the inherited information of (32), to result in what we were after: the configured instance of COPO (37).
Product Sales & Procurement
The configured Product Class  has a class-of-temporal-part  is created in order to add prices and other commercial and logistics information. One or more members of that Class  is(are) what ultimately is being offered.
The model for Product Configuration is valid for those products that have options from which a selection must be made. For commodity products skip  to  inclusive, and use  directly.
After due evaluations of the received quotations  a choice is being made and the goods are being ordered.
The Activity  of Procuring a product that fulfils the requirements involves-by-reference the following objects:
Manufacturing & Inspection
Once the product has been manufactured  often it is being tested. That testing is done to PhysicalObject  that is a temporal part of  (for functional specification) and .
The fact that the product  is found in accordance with the Specification  is recorded with the Classification relationship between  and .
The inspected product  is shipped to the plant site.
Then, or later, it  is registered in the plant owner's books and gets an Asset Number (where applicable).
This model exists in two "possible worlds": the lefthand side in a "design world" and the righthand side in the "real world" we live in.
The Design World
In the topic Possible Worlds the possibility of modeling a planning has been briefly explained. A more detailed topic is forthcoming. PhysicalObject  is representing the imaginary fact that MaterializedPhysicalObject  has been installed to fulfil the requirements of FunctionalPhysicalObject .
The Actual World
INSTALLING Activity  causes the Event  of the beginning of the installed PhysicalObject . The latter is then declared to be the Counterpart of the imaginary PhysicalObject  by a Counterpart relationship. Please read the topic Possible Worlds for the meaning of, and the rules for, that concept.
Some members of the ISO 15926 community are of the opinion that it is necessary to declare actual WholeLife FunctionalPhysicalObject . This is correct ISO 15926, but others feel that this declaration, that ends again once the PhysicalObject  is being uninstalled, has no use, because this particular WholeLifeIndividual has no associated information other than via its temporal part . As will be seen in the next topics that temporal part  serves as (NOT: 'is' !) a WholeLifeIndividual for Operations and on-site Maintenance.
For each installed PhysicalObject all design information and all product information is readily accessible.
NOTE - There are in fact two more Counterpart relationships: between  and  and between  and , but these seem not to be very useful and difficult to maintain when equipment is being replaced.
A temporal part  of the installed physical object  participates in a process activity "Pumping Waste Water"  and so does the pumped stream .
That stream  is the placeholder for the measured stream properties as stored in some kind of Historian as time series (e.g. per shift).
At some time those properties and composition of the actual stream  are being compared with the designed values of the process design stream class  as laid down in the Heat & Material Balance .
In case those properties are within the criteria for membership of  ,the Stream  can be declared to be a member of Stream Class .
If there is a reason for it, the design may be adapted, and the life cycle starts again.
A temporal part  of the installed physical object  participates in the Activity "On-site Maintenance" . PhysicalObject  remains in situ.
When installed temporal part Asset  is de-installed it is terminated (deprecated) the temporal whole Asset  is available for Shop Maintenance or an other service (eventually after that maintenance).
A temporal part  of the non-installed or de-installed Asset  is participating in the Activity "Shop Maintenance" .