Lifecycle Model

Introduction

This topic is a sequel of Functional and Physical Objects - the big picture, and deals with the three layers of Engineering & Construction:

• Process Design & Conceptual Engineering (also referred to as FEED - Front-End Engineering and Design)
• Detailed Engineering and Plant Design
• Procurement and Construction
• Operations and Maintenance
• Inheritance

The data model shown below is clearly a "back bone" model and open for debate. In case you disagree, please speak up.

I will first show the model, and then discuss each layer.

Data Model

The date-time is left out of the diagram, because it would clutter it too much. For each of the instances of PossibleIndividual the following diagram applies:

What if no conceptual engineering data are available?

In case no Process Design & Conceptual Engineering data are available, the above model reduces to:

Process Design & Conceptual Engineering

Let's look at the model for this first part of the lifecycle:

Process Design deals with hydraulic networks, with Unit Operations and Streams of Matter and Energy. 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 we see P24 at Node 06 in which 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).

The Duty Specification could, as a minimum, list the two streams with their data, implying that the Unit Operation P24 shall cause a state change from the S11 state to the S12 state. This can be done in many ways. One of them is shown in the form of a PFD (Process Flow Diagram), an extension of the BFD, like this:

The instances of ClassOfActivity at the righthand side of the large diagram above must be capable of creating such a state change. They can be defined with what we could give a generic name: Transfer Function Definitions. For a centrifugal pump that can be presented with something like this:

but also, for that matter, Logic Diagrams like this, as a part of Conceptual Engineering:

Such Logic Diagrams spell out the required functionality, but not its physical implementation (e.g. in software, solid state logic ,or relay system).

Note that process simulation software is based on such transfer functions, which can be parameterized.

Process Engineers do process simulations, in which they define the streams and the activities to be performed on these streams, like heating, pumping, distilling. These simulations produce lots of data. These end up in a Heat & Material Balance and in Process Data Sheets for Engineering of equipment, instrumentation and piping.

Under Conceptual Engineering we also find engineering activities like Start-up Sequencing of electric motors, or also Logic Diagrams, as shown above.

Process design results, next to the documents already mentioned, in PFDs (Process Flow Diagram). In fact these are more detailed Activity Diagrams, but unfortunately they are often mistaken for a kind of simplified P&IDs.

Detailed Engineering & Plant Design

Based on the results of process design we produce schematic diagrams, like the P&IDs (Piping and InstrumentDiagram), Instrument Loop Diagrams and Electrical Schematics, as well as equipment and instrument specifications. 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.

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

The functionality of pump P-101 is actually taken from the results of the process design, BUT... the stream data cannot be used as is, because often there are design rules that require a change to these process data. For example, the plant owner requires that pumps shall be designed with a 10% overcapacity (just as your car has an overcapacity). These adjusted process data appear in the specification, usually in terms of minimum, normal, and maximum.

Our P-101 also appears on the P&ID, showing its place in the hydraulic network, and in the 3D plant model, showing its location and details for its support and controls. In short: configuration information.

So, ideally all functional information would come from the left, and all physical information from the right. But for the reasons outlined, the required functional data are entered on the specifications.

See further here.

Procurement & Construction

Procurement and Construction is covered by the lower part of the first diagram:

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 ClassOfInanimatePhysicalObject (brown) is a class of temporal part of both the requirements (blue) and the selected pump type (ocre) of the successful supplier.

Then comes construction, where we deal with the real-world "hardware":

The actual pump, (ocre) with serial number 654321, is taken from the warehouse and a temporal part of it, (brown), is installed to fulfil the requirements of "Function Place" (a term used by SAP) P-101-rev.1 (blue).

For further details see here.

It is this installed item that is the placeholder for all O&M (Operations and Maintenance) information. All equipment design and plant design information is inherited from the catalog and the function place, such as:

• its position, in terms of XYZ-coordinates
• its mass (weight) of 254 kg
• its connection to the adjacent pipe

Temporal parts of the PhysicalObject are the placeholders of construction data, operational data and maintenance data.

Operations and Maintenance

Operations and Maintenance is covered by the far lower part of the first diagram:

The installed physical objects participate in the maintenance activities, and the documentation related to the physical object class, such as Maintenance Manuals, is "involved by reference". Maintenance activities are, for the most, human activities.

The installed physical objects participate in the process activities, e.g. pumping, cracking, platforming, etc and so do the handled streams.

At some time the properties and composition of the streams are being compared with the values of the process design results. If there is a reason for it, the design may be adapted, and the life cycle starts again.

Inheritance

This is shown in the redrawn schema below (the inherited information is shown in the same color):