Plant Life-cycle Model

latest update: 10 Oct. 2020    


This topic deals with the Life-cycle (Activity) Model of a Plant:

The Plant Life-cycle Model shown below is clearly a "back bone" model for the integration of life-cycle plant information. It shows the things that together form the structure of the Plant Life-cycle Model:
Since most COTS applications don't have temporal parts, these are hidden inside a template, and seemingly all information is being attirubuted to one PhysicalObject.


High-Level Model

Click here for a CFIHOS annotation

Placeholder Model


Process Design & Conceptual Engineering

This first part of the lifecycle has the following model:

Declaration Model (still requires an update)


Process Design

Process Design deals with hydraulic networks, with Unit Operations and Streams of Matter and Energy (blocks [1] and [2] 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:


Conceptual Engineering

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 [8] in the above first graph).

In fact these are more detailed Activity Diagrams, where symbols for the instances of ClassOfFunctionalObject are shown (block [10] 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:


Process Engineering

The Heat and Material Balance document [3], prepared during Process Design, gives estimated values for the inflow and outflow of energy and mass respectively.

"P14 in Role as PERFORMER"  [7] is an subclass of ClassOfFunctionalObject [12] that is being represented on a Process Data Sheet PD-39452 [13]

NOTE - The ParticipatingRoleAndDomain [7] 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 [13]  is the "engineering case", is input for Detailed Engineering. It is prepared during Process Engineering, and based on the Heat & Material Balance data. Where required safety margins and engineering rules are being applied. (that is the reason why [12] is a superclass of [7] ).

ClassOfFunctionalObject  [12] is a class of temporal part of ClassOfFunctionalObject  [14]  that is the functional "Ur"class of P-101 [17] . 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 [13] a new specialization relationship with ParticipatingRoleAndDomain [7] will be created as well as a new ClassOfFunctionalObject [12] 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.

Declaration Model (still requires an update)


Plant Design

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 [17] is a designed object that exists in the Possible World of Design. It is declared as shown in above diagram.

    A temporal part [17a] is represented on a P&ID [16] and another temporal part [17d] is represented on a 3D model [23].

    Via a temporal part [17b] the definition of the functional aspects is attributed to an instance of ClassOfFunctionalObject [14], whereas via temporal part [17c] the definition of the physical aspects is attributed to an instance of ClassOfPhysicalObject [21] (or a subtype thereof).

    In order to warrant that the functional requirements are met by the physical requirements the ClassOfPhysicalObject [21] is a subClassOf the ClassOfFunctionalObject [14]  (that is: between class of temporal parts thereof).

    Once, during Construction, an actual PhysicalObject has been installed the link between [17] via its temporal part [17e] in the design part of the Digital Twin with that installed PhysicalObject [55] is made with an instance of the Implementation relationship (an alternative name of the Counterpart relationship).

    Declaration Model  (still requires an update)


    Detailed Engineering

    Starting with the process data, that are inherited from [12] , the specification [20] 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"  Asset Requirements Class [21] is an empty placeholder (anchor) that never changes. The information is attributed to a class-of-temporal-part of it [19]  for the technical requirements defined on the Technical Specification [20]. (see Life cycle of a Class.) *)

    *) Actually the document is an instance of ClassOfInformationObject that is a specialization of the shown instance of ClassOfInformationRepresentation.

    In case the  physical requirements change, the instance of [19] , that was valid until then, is being deprecated and a successor being created. That successor is representing the requirements starting from then on.  That new class of temporal part [19] is automatically made a subclass of the ClassOfFunctionalObject [12] 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 [12] is being replaced by a newer class of temporal part, the ClassOfPhysicalObject [19] shall replaced with a newer class of temporal part, where the latter is a subclass of the former again. But the timing of both changes may be different.

    The Asset Requirements Class [19] is subsequently referred to in Procurement, Product Sales (as result of a positive Bid Evaluation), Inspection (when compliant) and Construction (when compliant). The details about those relationships are given there.

    Declaration Model (still requires an update)


    Product Configuration

    The ClassOfPhysicalObject (COPO) (30) is the "Ur"class without any further attributed information.

    It has two class of temporal part Classes:

    • a ClassOfFunctionalObject (31) that defines the functional aspects,  so a Functional Product Class

    • a ClassOfPhysicalObject (32) that defines the physical aspects and inherits the definitions of the Functional Product Class.

    That (COPO) (32) covers everything that is standard, 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).

    Declaration Model


    Product Sales & Procurement

    Product Sales

    The configured Product Class [37] has a class-of-temporal-part [38] is created in order to add prices and other commercial and logistics information. One or more members of that Class [38] 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 [32] to [36] inclusive, and use [37] directly.

    When the Bid Evaluation of the quotation is positive an instance of the relationship IntendedRoelAndDomain between [38]  and [19] puts that on record.


    After due evaluations of the received quotations [38] a choice is being made and the goods are being ordered.

    The Activity [40] of Procuring a product that fulfils the requirements involves-by-reference the following objects:

    • The ClassOfPhysicalObject [19] that is the Requirements Class of the product we want to procure;

    • and later, after receipt and evaluation of the quotation(s), the offered Detailed Product Model [38], along with the price and other commercial and logistic information. NOTE - Keeping the non-selected, but complying, other product classes [38] on record has the benefit of being able to quickly select a replacement in case of calamities.

    Declaration Model (still requires an update)


    Manufacturing & Inspection


    Once the product has been manufactured [51]  it must comply with the quotation. This is put on record by classifying it with [38] Then it is often been functionally tested. That testing is done to PhysicalObject [53] that is a temporal part of the manufactured product [51] .

    The fact that the product [53] is found in accordance with the Specification [20] is recorded with the Classification relationship between [53] and [19].

    Declaration Model


    Logistics & Asset Management

    The inspected product [53] is shipped to the plant site.

    Then, or later, it [54] is registered in the plant owner's books and gets an Asset Number (where applicable).

    That asset [54]  can be installed ([58] resulting in [55])or maintained [80].

    Declaration Models



    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

    PhysicalObject [17] , called 'Functional Location', is physically implemented by the installed PhysicalObject [55] . This is represented with an Implementation (Counterpart) relationship to indicate that the latter has been installed to fulfil the requirements of the former. The classification of the installed PhysicalObject [55] with ClassOfPhysicalObject [55] is put on record only in case it indeed fulfils the requirements defined by the latter.

    The Actual World

    INSTALLING Activity [58] causes the Event [59] of the beginning of the installed PhysicalObject [55].

    As will be seen in the next topics that temporal part [55] serves as a temporal whole for Operations and on-site Maintenance.

    For each installed PhysicalObject all design information and all product information is readily accessible.

    Connecting Tags and their implementing PhysicalObject's

    The relationship between a connection of design objects ('Tags') and the physical objects that implement those Tags (and some more) 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:

    Declaration Model  (still requires an update)



    A temporal part [60] of the installed physical object [55] participates in a process activity "Pumping Waste Water" [61] and so does the pumped stream of waste water [63].

    That stream [63] 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 [63] are being compared with the designed values of the process design stream class [2] as laid down in the Heat & Material Balance [3]

    In case those properties are within the criteria for membership of [2] ,the Stream [63] can be declared to be a member of Stream Class [2] i.e. the plant operates as designed.

    The operator has access to all integrated design & engineering information of [17]  and to the operational information attributed to temporal parts of [55] via the Implementation (Counterpart) relationship. That also hold in case [54/55] is being replaced, leading to ending the Counterpart relationship and establishing a new one with the newcomer. The operator also is interested in any in-line maintenance information, which is available via another temporal part of [55] .

    If there is a reason for it, the design may be adapted, and the life cycle starts again.

    Declaration Model (still requires some update)



    A temporal part [70] of the installed physical object [55] participates in the Activity "In-line Maintenance" [71]. PhysicalObject [55] remains in situ.

    When installed temporal part Asset [55] is de-installed it is terminated (deprecated) the temporal whole Asset [54] is available for Shop Maintenance or an other service (eventually after that maintenance).

    A temporal part [80] of the non-installed or de-installed Asset [54] is participating in the Activity "Shop Maintenance" [81]. Maintenance has access to all historical process information as well as to all hardware information via 5453 , 51 , to 38 .

    Declaration Models



    When the Properties of Stream [63] are within the criteria for membership of ClassOfStream [2] the former can be classified with the latter to indicate that that part of the plant runs as designed.

    All other analysis input information can be fetched from the integrated plant life-cycle information, but cannot be shown here since this model is a meta model of the placeholders of that information only (and how they are interlinked).

    Declaration Model