Plant Lifecycle Model

latest update: 3 January 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.


Data Model


Process Design & Conceptual Engineering

This first part of the lifecycle has the following model:

Process Design

Process Design deals with hydraulic networks, with Unit Operations and Streams of Matter and Energy (blocks 1, 2, and 3 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 P24 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 5 in the above graph).

In fact these are more detailed Activity Diagrams, where symbols for the instances of ClassOfFunctionalObject are shown (block 4 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 Process Engineers are now 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.

Detailed Engineering

With these process data the specifications for this hardware are being written. These also include additional requirements, such as material of construction and explosionproofing .

Let us have a closer look at the applicable part of the model:

The "whole-life Functional Class" (block 14)  is an empty placeholder (anchor) that never changes. The information is attributed to a class-of-temporal-part of it (11) (see Life cycle of a Class) for the functional (process) data defined by the Process Engineer (9) in the Process Data Sheet for the FunctionalPhysicalObject (15).

The "whole-life Requirements Class" (block 16) is an empty placeholder (anchor) that never changes. The information is attributed to a class-of-temporal-part of it (13)  for the technical requirements defined on the Technical Specification (12). (see Life cycle of a Class.)

In case the requirements change, 11 and 13 are being deprecated and successors being created. These are representing the requirements starting from then on.

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.

The FunctionalPhysicalObject 15  appears on the P&ID (15a) for topology reasons, showing its place in the plant network, and in the 3D plant model (17a), showing its location and details for its support and controls.

The typing with an instance of ClassOfFunctionalObject (14) is done at declaration time, making the latter the "WholeLife" Functional Requirements Class.

The typing with an instance of ClassOfPhysicalObject (16) is done at declaration time, making the latter the "WholeLife" Physical Requirements Class.

Procurement & Manufacturing

In order to be able to purchase the equipment and materials required for constructing the plant, RFQs (Request For Quotation) are issued to three or more potential suppliers. The specifications are sent with these RFQs, and on the basis of the requirements outlined by these specifications the potential suppliers offer their goods (and/or services).

After due evaluations a choice is being made and the goods are being ordered. That choice can be put on record in the following manner:


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

  • The MaterializedPhysicalObject (17) for which a product has to be purchased;
  • The ClassOfPhysicalObject (16) that has been fully defined with a Technical Specification (12);
  • 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 (see NOTE);
  • Once the product has been manufactured (19) often it is being tested. That testing is done to PhysicalObject (20) that is a temporal part of (19) and (40).
  • The fact that the product (20) is found in accordance with the Specification (12) is recorded with the Classification relationship between (20) and (16).

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.

  • Product Sales

    Supplier's claim

    The supplier's claim, implicit or explicit, that his product fulfils the functional requirements of our FunctionalPhysicalObject, may be recorded with an instance of ClassOfIntendedRoleAndDomain, linking his detailed functional model (39) with the applicable functional class (9).

    Product Model with Options

    This model may require some explanation.

    • The Product Model (32) is that part of the class definition that is common for all, so exclusive of any options.
    • Each option, here (33) , (34), and (35) , is defined separately as a specialization of that common class (32). So, for example, (33) is a fully defined product model with Option #1 added.
    • In order to compose a product model that fulfils the requirements the applicable options are gathered in an EnumeratedSetOfClass (36) and then a union of them (37) is created with an instance of UnionOfSetOfClass.
    • Of the resulting class (37) a class-of-temporal-part (38is created in order to add prices and other commercial and logistic information. One or more members of that Class (38) is(are) what ultimately is being offered.

    This model for Product Sales 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.

    Logistics & Asset Management

    The inspected product (20) is shipped to the plant site.

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

    That asset (21) can be installed or maintained.


    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 actual pump (21), with asset number 654321, is taken from the warehouse and a temporal part of it (22), is installed to fulfil the requirements of the designed pump 'P-101'  (18b)

    It is this installed item (21) that is the placeholder for all Operations and some Maintenance information.

    All plant design (15a) and functional requirements (10) and equipment requirements (12) information, as well as all product information (38) for the installed PhysicalObject (22) is retrievable.


    The installed physical object (22) participates in a process activity "Pumping Boiler Feedwater" and so does the pumped stream (27).

    That stream (27) is the placeholder for the measured stream data 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 (27) are being compared with the designed values of the process design stream class (2) as laid down in the Heat & Material Balance (3). 

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


    A temporal part (28) of the installed physical object (22) participates in the Activity "On-site Maintenance" (29).

    A temporal part (30) of the non-installed or de-installed Asset (21) is participating in the Activity "Shop Maintenance" (31).