Plant Life-cycle Model

latest update 2022-10-24 

Introduction

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

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.

Placeholder Model

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.

Process Design & Conceptual Engineering

This first part of the lifecycle has the following model:

Exegesis

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 [6] and [17] above). Next come the FunctionalObjects that can, functionally, perform these Activities.

We start with a WholeLife Stream 18] of which a temporal part [19] is on a Block Flow Diagram [8] and on a Heat & Material Balance [20] (see below).

And we have a WholeLife FunctionalObject [29] of which a temporal part [30] is represented on a Process Flow Diagram [31].

That WholeLife Stream [18] is a member of WholeLife ClassOfStream [17] that is a specialization of a ClassOfStream [9] in the RDL.

That WholeLife FunctionalObject [29] is a member of WholeLife ClassOfFunctionalObject [28] that is a specialization of ClassOfFunctionalObject [35] in the RDL.

Between that WholeLife ClassOfStream [17] and WholeLife ClassOfFunctionalObject [28] we see a ClassOfActivity model that mimicks the Activity model between Stream [18] and FunctionalObject [29].

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 [11], [2] and [22] 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 [12] 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 [15].

Links to Plant Design and Process Engineering

The WholeLife FunctionalObject [29] has the WholeLife Tag [36] 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 [28] via the ClassOfTemporalWholePart relationship with [27] (which may involve a number of simulations for a number of modes of operation).

The ClassOfFunctionalObject [26] is used by Process Engineering for the "governing case" [47] 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".

Example

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 [20], 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) [31], such as this example:

Skeleton Process Flow Diagram (PFD) for the Production of Benzene via the Hydrodealkylation of Toluene (source: informIT)

Process Engineering

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 [42] that defines the Functional Requirements Class [40]. 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 [40] is a (class of) temporal part of ClassOfFunctionalObject [43]; the semantics of that are explained in the topic 'Life cycle of a Class'. Here it boils down to the following: The ClassOfFunctionalObject [43] is declared to be an 'anchor', i.e. it remains fixed in place as long as the member Tag exists. The Functional Requirements Class [40] 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 [40] is a subclass of the ClassOfFunctionalObject [25] because of extra constraints in the former.

The Functional Requirements Class [40] is a superclass of the ClassOfPhysicalObject [50] because that Asset Requirements Class adds the technical requirements to the functional requirements of [40].

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.

As can be seen the Tag [36] is the most interrelated object in the Design World. All relationships will be reviewed:

Detailed Engineering

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 [22], defined for Process Design.

The functional information, defined in Process Engineering, is inherited since the Asset Requirements Class [50] is a specialization of the Functional Requirements Class [40]. The technical requirements are being added. The full definition of the Asset Requirements Class are recorded in the Technical Specification [52]

.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 [53] and its version [50]. The declaration of a new temporal part of [52] coincides with the issue of a new revision of the Technical Specification [52].

Links to other Life-cycle Activities

Detailed Engineering has a number of links with other life-cycle activities:

Product Configuration

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 [61] the required options [62] and [64] have been added to arrive at a fully detailed technical model [66].

A specialization of [66] is the ClassOfPhysicalObject 70], that includes commercial and logistical information, as recorded in a Quotation.

Product Sales & Procurement

The ClassOfPhysicalObject [70], that has been offered by a supplier [29], is a class of temporal part of the configuration result [66] . It adds price information and other commercial and logistical information.

The ClassOfPhysicalObject [70] is 'involved by reference' in Procurement Activity [56] together with the Asset Requirements Class [50] ; the defining specification [52] is a part of an RFQ (Request For Quotation) and PO (Purchase Order).

The PhysicalObject [72] , that is manufactured, is classified with the ClassOfPhysicalObject [70] that has been offered and accepted. For brevity reasons the necessary temporal parts for the procument phases have been skipped here.

Manufacturing & Inspection

Once the product has been manufactured [72] must comply with the quotation. This is put on record by classifying it with [70]

Then it is often been functionally tested. That testing is done to PhysicalObject [75] that is a temporal part of the manufactured product [72]. It must also comply with the functional specification [60] of the manufacturer.

The fact that the product [75] is found in accordance with the Specification [53] is recorded with the Classification relationship between [75] and [50]

Asset Management

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

Then, or later, the PhysicalObject [78], a temporal part of the inspected PhysicalObject [75], is registered in the plant owner's books and gets an Asset Number (where applicable).

That Asset [78] can be installed, resulting in [84], or maintained [95].

Construction

A temporal part 81] of Asset [78] participates in installing Activity [82] that causes the Event [83] that marked the beginning of another temporal part of Asset [78] : the Asset in installed state [84] .

The latter has the following relationships:

Connecting Tags and their implementing PhysicalObject's

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:


Operations

A temporal part [87] of the Installed Asset [84] participates in Activity [88] as does temporal part [90] of Stream [89];

A temporal part [87] of the Installed Asset [84] contains temporal part [90] of Stream [89] ;

In case the temporal part [90] of Stream [89] complies with the Process Design ClassOfStream [16]it can be made a member of same.

Maintenance

There are two types of maintenance:

  1. In-line Maintenance where the maintained object remains installed : a temporal part [93] of the Installed Asset [84] participates in In-line Maintenance Activity [94];
  2. Shop Maintenance where the maintained object is uninstalled and transported to the maintenance shop : a temporal part [95] of Asset [78] participates in Shop Maintenance Activity [96].

Performance Analysis

In case the temporal part [90] of Stream [89] complies with the Process Design ClassOfStream [16] it can be made a member of same. That part of the plant runs as designed.