Plant Life-cycle Model

Introduction

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

Process Design
Process Engineering
Plant Design
Detailed Engineering
Product Configuration
Product Sales & Procurement
Manufacturing & Inspection
Asset Management
Construction & Commissioning
Operations
Maintenance
Performance Analysis
Demolition

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 held 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.
Each of the numbered nodes plays a role in one to many Template instances, other than the templates that replace the shown predicates (see Predicates used).

NOTE - Interrelationsships between Nodes of different instances of this Lifecycle Model shall be such, that the interrelated objects are in the same Lifecycle Activity. See for example here

Predefined Code

In each of the above chapters you will find the applicable predefined Turtle code in a generic form, that can be used to declare the information placeholders and their shown interrelationships. NOTE- this is Work in Progress.

WARNING - The Node Numbers have been rearranged on 21 Sept. 2023

Predicates used

The following predicates (rdf:Property) are being used in above graph:

rdf:id - required for graph, but implied in Turtle;

rdf:type - if fixed: use as-is, in case it can change: tpl:ClassificationOfIndividual;
rdfs:label - use as-is in declarations;
rdfs:subClassOf - if fixed: use as-is, in case it can change: tpl:SpecializationOfClassOfIndividual ;

tpl:causesBeginOf - use tpl:ActivityCausesBegunIndividual ;

tpl:coIntendedForUseAs - tpl:ClassOfIntendedRoleAndDomainDefinition;
tpl:coPartOf - use tpl:ClassOfCompositionDefinition ;

tpl:coParticipatesInRoleIn - use tpl:ClassOfParticipationDefinition ;

tpl:coRepresentedOn - use tpl:ReferenceToClassOfIndividualOnDocument;
tpl:coTemporalPartOf - use tpl:ClassOfTemporalWholePartDefinition ;

tpl:contains - use tpl:ContainmentOfAnIndividual ;

tpl:implements - use tpl:InstallingPhysicalObjectInFunctionalLocation ;

tpl:unionResultTo - use tpl:UnionOfEnumeratedSetOfClass ;

tpl:involvedByReferenceIn - use tpl:InvolvementByReferenceOfClassInActivity ;

tpl:partOf - use tpl:CompositionOfAnIndividual ;

tpl:participatesAsDirectObjectIn - use tpl:ParticipationOfPhysicalObjectInActivity;
tpl:participatesAsInputIn - use tpl:InvolvementByReferenceOfClassInActivity ;

tpl:participatesAsOutputIn - use tpl:InvolvementByReferenceOfClassInActivity ;

tpl:participatesInRoleIn - use tpl:ParticipationOfPhysicalObjectInActivity;
tpl:representedOn - use tpl:ReferenceToIndividualOnDocument ;

tpl:temporalPartOf - use tpl:IndividualHasTemporalPart ;

These predicates shall be mapped into the template types shown.

Process Design

This first part of the lifecycle has the following model:

Exegesis

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) [6] and Streams of Matter and Energy [16] above). Next comes the FunctionalObject [26] that can, functionally, perform these Activities.

We start with a WholeLife Stream 16] that is on a Block Flow Diagram [D1], and a temporal part [17] values of which are represented on a Heat & Material Balance [D2] (see below).

And we have a WholeLife FunctionalObject [26] that is represented on a Process Flow Diagram [D3].

That WholeLife Stream [16] is a member of WholeLife ClassOfStream [14] that is a specialization of a ClassOfStream [R2] in the RDL.

That WholeLife FunctionalObject [26] is a member of WholeLife ClassOfFunctionalObject [24] that is a specialization of ClassOfFunctionalObject [R3] in the RDL.

Between that WholeLife ClassOfStream [14] and WholeLife ClassOfFunctionalObject [24] we see a ClassOfActivity model of which the Activity model between Stream [17] and FunctionalObject [27] is a member/instance.

In the top of the diagram is a set of reference data that can be defined in an RDL extension, 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 [12], [2] and [22] have an information set, in the form of a set of generic templates, around them, defining which information must be given for the stream, the activity and the functional object that they share.
Note that there can be more than one stream and/or more than one functional object related to an Activity.

These templates are semi-specialized, for example they state that the stream must have an UPPER LIMIT OPERATING TEMPERATURE, with or without mentioning that this must be in DEGREE CELSIUS, but they do not define a numeric value. Optionally further details can be defined for a project in a class of temporal part [13], [3] and [23]. Ultimately that value, and eventually also the Units of Measure, is attributed to a Requirements Classes [15], [5] and [25].

Model for Process Cases

In the above diagram you see an area within brown-dotted lines. That is basically representing an ontology for a process case. It follows the generic ontology of the area above it ([12], [2] and [22]). The coTemporalPart relations allow for zero-to-many such temporal parts for variations of process cases.

NOTE - The relations temporalPartOf and coTemporalPartOf actually are specializations that are relevant for a period in time between a given EffectiveDate and a DeprecationDate . Temporal parts may exiat simultaneously over different periods in time.

In the above diagram you also see an area within blue-dotted lines. That is basically representing one process case with its Requirements Classes. Those requirements follow the ontology just discussed. A process case is kind of 'suspended', like a trampoline, by 'WholeLife' individuals and classes by means of temporalPartOf and coTemporalPartOf relations. Again, keep in mind that process cases usually have more than one (ClassOf)Stream.

The Individuals [17], [7] and [27] are, predominantly, the placeholder for topological information (source, destination, location), and the Classes [15], [5] and [25] are the Requirements Classes, holding the design information for a process case.

Example

See the topic: ISO 15926 Process Design Model

Interfaces with Plant Design and Process Engineering

The WholeLife FunctionalObject [26] has the WholeLife Tag [43] as its specialization. That means that the Process Design history is inherited by that WholeLife Tag. Keep in mind that that history is typed with its ClassOfFunctionalObject [24] and via the coTemporalPartOF relation with [25] (which may involve a number of simulations for a number of modes of operation).

The ClassOfFunctionalObject [24] is used by Process Engineering for the "design case" [31] 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 "design case".

Block Flow Diagram

The BFD (Block Flow Diagram [D1], 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 [D2], 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) [D3], such as this example:

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

Code listing for this life-cycle activity

Don't let it scare you off, this one is the most complex; Click here

Process Engineering

The input for Process Engineering are the results 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 [D4] 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.

Interfaces with Process Design, Plant Design and Detailed Engineering

The Activity [30], typed with rdl:RDS9701927 (PROCESS ENGINEERING), has the information, attributed to:

ClassOfStream [14] and its class of temporal part Class(es),
ClassOfFunctionalObject [24] and its class of temporal part Class(es),

as inputs. After defining the 'design case', that design case defines ClassOfFunctionalObject [31].

The Functional Requirements Class [31] is a (class of) temporal part of ClassOfFunctionalObject [44]; the semantics of that are explained below in chapter Plant Design'. It boils down to the following: The ClassOfFunctionalObject [44] is declared to be an 'anchor', i.e. it remains fixed in place as long as the information about its member Functional Location [43] is kept in store. The Functional Requirements Class [31] may change over the life cycle of the plant into revisions rev0, rev1, etc. This structure with a coTemporalPartOf (dm:ClassOfTemporalWholePart) relationship allows for a cradle-to-grave audit trail of the functional requirements of the Functional Location a.k.a. 'Tag'.

NOTE - That relation coTemporalPartOf actually is a specialization, that is relevant for a period in time only.

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

Code listing for this life-cycle activity

Click here

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 plant items. From this the Isometrics for piping are produced.

As can be seen the Functional Location a.k.a.Tag [43] 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 may link it to FunctionalObject [26] by means of an rdfs:subClassOf ; thus the Tag inherits the Process Design history of [26]
When the Tag is being declared we automatically declare a companion ClassOfFunctionalObject [44] and a companion ClassOfPhysicalObject [45] 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 and/or its life-cycle information needs to be kept in store ;
A temporal part of the Tag is represented on a P&ID [D5], and another temporal part of the Tag is represented in a 3D Model [D6] ;
An explicit temporal part [46] of the Tag, existing in the Design World, is linked with the installed Asset [84], existing in the Real World, via a 'Counterpart' relationship dubbed 'Implementation' (see here for an explanation). A Digital Twin 'avant la lettre'.
A Tag contains, in many cases, a Stream [40], that is, at declaration time, hard-typed with an anchor ClassOfStream [41]. The latter is an anchor for the Functional Requirements Class [31].
Like the Tag, the Stream is a subClassOf Stream anchor [16] in Process Design, thus inheriting the design information.
Finally an explicit temporal part [42] of the Stream, existing in the Design World, is linked with the actual anchor Stream [81], existing in the Real World, via a 'Counterpart' relationship dubbed 'Implementation'.

Code listing for this life-cycle activity

Click here

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 [52]

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

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

Interfaces with 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 [31], the specification [D7] for the Asset Requirements Class [53] is being written. This includes physical requirements, such as material of construction and explosionproofing;
The Asset Requirements Class [53] is a class of temporal part of the "anchor" ClassOfPhysicalObject [45] that types the Tag [43];
The Asset Requirements Class [53] is 'involved by reference' in a Procurement Activity [56] , together with the 'Detailed product class, as offered (incl. price)' [68]
The PhysicalObject [74] that is being inspected can be classified with the Asset Requirements Class [53] in case it fulfills the requirements set forth in the latter ;
If the installed PhysicalObject [84] is compliant with the requirements of the Asset Requirements Class [53] it can be classified with the latter ; Note that the Implementation relationship with the Tag only states that PhysicalObject [84] is a real-world counterpart of the design-world Tag [43] and not that it complies with the Tag requirements. That can be confirmed by classifying/typing the installed item with the applicable Requirements Class [53]. /li>

Code listing for this life-cycle activity

Click here

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

A coTemporalPartOf [67] is the ClassOfPhysicalObject [68], that includes commercial and logistical information, as recorded in a Quotation.

Code listing for this life-cycle activity

Click here

Product Sales & Procurement

The ClassOfPhysicalObject [68], that has been offered by a supplier. It is a coTemporalPartOf the configuration result [67] . It adds price information and other commercial and logistical information.

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

The PhysicalObject [70] , that is manufactured, is classified with the ClassOfPhysicalObject [68] that has been offered and accepted.

Code listing for this life-cycle activity

Click here

Manufacturing & Inspection

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

Then it is often been inspected. That inspection is done to PhysicalObject [74] that is a temporal part of the manufactured product [70]. It must comply with the quotation [68] with all included documentation of the manufacturer, and with the Technical Requirements Specification [D7] .

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

Code listing for this life-cycle activity

Click here

Asset Management

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

Then, or later, the PhysicalObject [78], a temporal part of the inspected PhysicalObject [74], 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].

Code listing for this life-cycle activity

Construction & Commissioning

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

The latter has the following relationships:

As said, the Installed Asset [84] is a temporal part of Asset [78];
The Installed Asset [84] in the Real World has Tag [43] in the Design World as counterpart ; this allows for access to all Tag-related information ;
In case the Installed Asset [84] is compliant with the Asset Requirement Class [53] then it is classified with same ;
The Installed Asset [84] can, via its temporal part [85], participate in an Operations Activity [80], e.g. pumping boiler feedwater to E-101;
The Installed Asset [84] can, via its temporal part [93], participate in an In-line Maintenance Operation [88].(for a Shop Maintenance it needs to be uninstalled, thus becoming another temporal part [95] of Asset [78] again ).

Code listing for this life-cycle activity

Operations

A temporal part [85] of the Installed Asset [84] participates in Activity [80 ] as does temporal part [82] of Stream [81];

A temporal part [85] of the Installed Asset [84] contains temporal part [82] of Stream [81] ;

In case Stream [82] complies with the Process Design ClassOfStream [15] the Activity is performed as designed.

Code listing for this life-cycle activity

Maintenance

There are two types of maintenance:

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];
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].

Code listing for this life-cycle activity

Performance Analysis

In case:

Stream [82], in a process case, complies with the Process Design ClassOfStream [15], in the same process case, that can be recorded as a classification/typing;
Installed Asset [85], in a process case, complies with the Process Design ClassOfFunctionalObject [25]in the same process case, that can be recorded as a classification/typing as well.

That part of the plant runs as designed for the current process case (in case more than one process case is possible).

Code listing for this life-cycle activity

Demolition

Everything comes to an end, so does a plant or a plant item. Demolition activity [99] has the WholeLifeIndividual [70] as a participant. This does not mean that we throw away that item from the data base, we just add the triple:

ex:UUID-of-[70] meta:valDeprecationDate "yyyy-mm-ddThh:mm:ssZ"^^xsd:dateTime .

to the declaration (in fact ) of that item and all its declared temporal parts and temporal parts thereof !. It is upto the software supplier to let that be known to any user or any application that is interested in that deprecated plant item or a declared temporal part thereof, directly or when referred to in a template signature. Insert an existence check in any SPARQL query (that is necessary anyway to avoid multiple declarations).