This topic deals with the Life-cycle (Activity) Model of a Plant:
- Process Design
- Process Engineering
- Plant Design
- Detailed Engineering
- Product Configuration
- Product Sales & Procurement
- Manufacturing & Inspection
- Asset Management
- Performance Analysis
NOTE - The descriptions of the various life-cycle activities have a focus on the model, i.e. how information placeholders are interrelated. Not on the information itself.
As a consequence these descriptions may not do justice to the scope of the disciplines.
The Plant Life-cycle Model shown below is clearly a "back bone" model for the integration of life-cycle plant information. It shows the life cycle of ONE plant item in the structure of the Plant Life-cycle Information Model.
The network nodes actually are the placeholders of information. In the topic named "LSN (Life-cycle Stages Network)" the information is schematically shown as yellow circles.
This first part of the lifecycle has the following model:
Note that Plant Design and Process Engineering are included in the above diagram because they are impacted by Process Design information.
Process Design deals with hydraulic networks, with Unit Operations (Activities) and Streams of Matter and Energy (blocks  and  above). Next come the FunctionalObjects that can, functionally, perform these Activities.
We start with a WholeLife Stream 18] of which a temporal part  is on a Block Flow Diagram  and on a Heat & Material Balance  (see below).
And we have a WholeLife FunctionalObject  of which a temporal part  is represented on a Process Flow Diagram .
That WholeLife Stream  is a member of WholeLife ClassOfStream  that is a specialization of a ClassOfStream  in the RDL.
That WholeLife FunctionalObject  is a member of WholeLife ClassOfFunctionalObject  that is a specialization of ClassOfFunctionalObject  in the RDL.
Between that WholeLife ClassOfStream  and WholeLife ClassOfFunctionalObject  we see a ClassOfActivity model that mimicks the Activity model between Stream  and FunctionalObject .
In the top of the diagram we see a set of reference data that can be defined in an RDL extensions, for example the CFIHOS RDL extension or company-specific extensions thereof (OR a comapny-specific extension directly of the RDL for any company outside the influence sphere of CFIHOS).
The classes ,  and  have an information set, in the form of a set of templates, around them, defining which information must be given for the stream, the functional object and the activity that they share. Note that there can be more than one stream and/or more than one functional object.
These templates are semi-specialized, for example they state that the stream must have a template  for an UPPER LIMIT OPERATING TEMPERATURE, with or without mentioning that this must be in DEGREE CELSIUS, but they do not define a numeric value. That value, and eventually also the Units of Measure, is given to the subclass template .
Links to Plant Design and Process Engineering
The WholeLife FunctionalObject  has the WholeLife Tag  as its specialization. That means that the Process Design history is inherited by that WholeLife Tag. Keep in mind that that history is linked to its ClassOfFunctionalObject  via the ClassOfTemporalWholePart relationship with  (which may involve a number of simulations for a number of modes of operation).
The ClassOfFunctionalObject  is used by Process Engineering for the "governing case"  that is input for Detailed Engineering. Also here keep in mind that there may be more than one set of simulation data of more than one mode op operation, that are used by the Process Engineer to define that "governing case".
See the topic Modes Of Operation
Block Flow Diagram
The BFD (Block Flow Diagram, source: The Engineering Toolbox and OSHA) shown below gives an example:
Participating in Unit Operations (= ClassOfActivity) are Stream classes (e.g.WasteWater). This can be modeled by using the template ClassOfParticipationDefinition that is used in the starting diagram.
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).
Heat and Material Balance
An important end product of Process Design is a document (or file) called Heat & Material Balance , giving all details about the streams:
Process Flow Diagrams
The next step is to find FunctionalObjects that can perform the Activities in the BFD. This results in the Process Flow Diagram (PFD) , such as this example:
Skeleton Process Flow Diagram (PFD) for the Production of Benzene via the Hydrodealkylation of Toluene (source: informIT)
The input for Process Engineering are the result of Process Design. Together with the other disciplines de P&ID (Piping and Instrumentation Diagram) is set up.
In the context of this model it is important to note that Process Engineering defines the Process Conditions and the Stream characteristics which have to be taken into account by Detailed Engineering. This information is represented in a Process Datasheet  that defines the Functional Requirements Class . A typical example of the data involved is this part of the API 610 datasheet :
Compared with the Process Design data these conditions may include adaptations caused by engineering rules, such as a required overcapacity, safety margins, etc.
Links to Process Design, Plant Design and Detailed Engineering
The Functional Requirements Class  is a (class of) temporal part of ClassOfFunctionalObject ; the semantics of that are explained in the topic 'Life cycle of a Class'. Here it boils down to the following: The ClassOfFunctionalObject  is declared to be an 'anchor', i.e. it remains fixed in place as long as the member Tag exists. The Functional Requirements Class  may change over the life cycle of the plant. This structure with a ClassOfTemporalWholePart relationship allows for a cradle-to-grave audit trail of the functional requirements of the Tag.
The Functional Requirements Class  is a subclass of the ClassOfFunctionalObject  because of extra constraints in the former.
The Functional Requirements Class  is a superclass of the ClassOfPhysicalObject  because that Asset Requirements Class adds the technical requirements to the functional requirements of .
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.
As can be seen the Tag  is the most interrelated object in the Design World. All relationships will be reviewed:
- When the Tag is being declared it is typed with what we call its 'Essential Type', that is the class it is a member of for its entire existence ; so 'DEMINERALIZER' rather than 'MIXED BED DEMINERALIZER' since the latter may change ;
- When the Tag is being declared we automatically declare a companion FunctionalObject  of which the Tag is a subclass via a hard-coded rdfs:subClassOf ; thus the Tag inherits the Process Design history 
- When the Tag is being declared we automatically declare a companion ClassOfFunctionalObject  and a companion ClassOfPhysicalObject  via a hard-coded rdf:type ; All three are "anchors" that remain empty of information and remain in existence as long as the Tag is functionally required in the plant ;
- A temporal part [36A] of the Tag is represented on a P&ID , and another temporal part [36B] of the Tag is represented in a 3D Model  ;
- And finally: A temporal part [36C] of the Tag, existing in the Design World, is linked with the installed Asset , existing in the Real World, via a 'Counterpart' relationship dubbed 'Implementation' (see here for an explanation). A Digital Twin 'avant la lettre'.
Similar to the definition of information sets in Process Design, here infosets for the hardware requirements are defined in a local RDL extension. The functional information requirements are inherited from the ClassOfFunctionalObject , defined for Process Design.
The functional information, defined in Process Engineering, is inherited since the Asset Requirements Class  is a specialization of the Functional Requirements Class . The technical requirements are being added. The full definition of the Asset Requirements Class are recorded in the Technical Specification 
.A warning is due: It is not always so that the FunctionalObject and the PhysicalObject are of the same composition. You can functionally require things that are physically less simple. An example: A typical control valve has 2% leakage when closed, this means at best a rangeability of 50:1. In case a larger rangeability is required, then a combination of two control valves in parallel with split range control must be engineered: One larger valve with an equal percentage trim and a soft seat and a smaller valve with a linear trim. The PFD, if propertly defined and representing Functional Objects, just calls for a control valve with 62:1 rangeabilty.
The engineering history remains accessible by means of the construct using a ClassOfTemporalWholePart relationship between the 'anchor' ClassOfPhysicalObject  and its version . The declaration of a new temporal part of  coincides with the issue of a new revision of the Technical Specification .
Links to other Life-cycle Activities
Detailed Engineering has a number of links with other life-cycle activities:
- Starting with the process data, that are inherited from , the specification  for the Asset Requirements Class  is being written. This includes physical requirements, such as material of construction and explosionproofing;
- The Asset Requirements Class  is a class of temporal part of the "anchor" ClassOfPhysicalObject  that types the Tag ;
- The Asset Requirements Class  is 'involved by reference' in a Procurement Activity  , together with the 'Detailed product class, as offered (incl. price)' 
- The PhysicalObject  that is being inspected can be classified with the Asset Requirements Class  in case it fulfills the requirements set forth in the latter ;
- If the installed PhysicalObject  is compliant with the requirements of the Asset Requirements Class  it can be classified with the latter ; Note that the Implementation relationship with the Tag only states that PhysicalObject  is a real-world counterpart of the design-world Tag  and not that it complies with the Tag requirements./li>
Product Configuration is done by engineers when making a selection of options of a reference ontology or a supplier catalog.
It is also done by a supplier when preparing a quotation. It follows this typical model that has been discussed in the topic 'Catalog options'
To the base model  the required options  and  have been added to arrive at a fully detailed technical model .
A specialization of  is the ClassOfPhysicalObject 70], that includes commercial and logistical information, as recorded in a Quotation.
The ClassOfPhysicalObject , that has been offered by a supplier , is a class of temporal part of the configuration result  . It adds price information and other commercial and logistical information.
The ClassOfPhysicalObject  is 'involved by reference' in Procurement Activity  together with the Asset Requirements Class  ; the defining specification  is a part of an RFQ (Request For Quotation) and PO (Purchase Order).
The PhysicalObject  , that is manufactured, is classified with the ClassOfPhysicalObject  that has been offered and accepted. For brevity reasons the necessary temporal parts for the procument phases have been skipped here.
Once the product has been manufactured  must comply with the quotation. This is put on record by classifying it with 
Then it is often been functionally tested. That testing is done to PhysicalObject  that is a temporal part of the manufactured product . It must also comply with the functional specification  of the manufacturer.
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, the PhysicalObject , a temporal part of the inspected PhysicalObject , is registered in the plant owner's books and gets an Asset Number (where applicable).
A temporal part 81] of Asset  participates in installing Activity  that causes the Event  that marked the beginning of another temporal part of Asset  : the Asset in installed state  .
The latter has the following relationships:
- As said, the Installed Asset  is a temporal part of Asset ;
- The Installed Asset  in the Real World has Tag  in the Design World as counterpart ; this allows for access to all Tag-related information ;
- In case the Installed Asset  is compliant with the Asset Requirement Class  then it is classified with same ;
- The Installed Asset  can, via its temporal part , participate in an Operations Activity ;
- The Installed Asset  can, via its temporal part , participate in an In-line Maintenance Operation .(for a Shop Maintenance it needs to be uninstalled, thus becoming another temporal part  of Asset  again ).
The relationship between a connection of design objects ('Tags') and the physical objects that implement those Tags is shown in the diagram below:
where the colors indicate a fact, represented by a Template. The four Relationships in the center are classified to give more detail, because Connection and Impelementation require to be closer defined.
From this a subgraph shows how the CFIHOS attribute 'Tag physical connection' is modeled:
A temporal part  of the Installed Asset  participates in Activity  as does temporal part  of Stream ;
A temporal part  of the Installed Asset  contains temporal part  of Stream  ;
In case the temporal part  of Stream  complies with the Process Design ClassOfStream it can be made a member of same.
There are two types of maintenance:
- In-line Maintenance where the maintained object remains installed : a temporal part  of the Installed Asset  participates in In-line Maintenance Activity ;
- Shop Maintenance where the maintained object is uninstalled and transported to the maintenance shop : a temporal part  of Asset  participates in Shop Maintenance Activity .
In case the temporal part  of Stream  complies with the Process Design ClassOfStream  it can be made a member of same. That part of the plant runs as designed.