FunctionalPhysicalObject vs MaterializedPhysicalObject

Introduction

A subject that the MMT SIG needs to decide upon is the role of a functional_physical_object.

This is a contribution to that discussion.

Graph

The following graph covers quite a story, about something that happens thousands of times on any construction site: the installation of a piece of equipment, an instrument, a pipe, etc.

A MaterializedPhysicalObject is installed to fulfil the requirements of a FunctionalPhysicalObject

The following sections of any EPC (Engineering, Procurement, Construction) contractor are involved:

• the engineers and designers cover the blue part;
• the procurement people and the suppliers cover the yellow part;
• the construction crew covers the green part.

Detailed Engineering & Plant Design

In this phase of the project the requirements, as defined by the Process Engineers, are the basis of so-called Piping & Instrument Diagrams (P&IDs). These schematic diagrams depict the required networks of piping and instrumentation of the plant to be built. The equipment and instrumentation items, shown with symbols, are interconnected.

Next the technical disciplines work on their detailed engineering, such as:

• Electrical One-line Diagrams for power generation and distribution
• Logic Diagams
• Instrument Loop Diagrams
• P&IDs for equipment auxiliary systems (e.g. lube and seal oil systems)
• the Piping Group starts building their 3D models, thereby detailing the geometry of the plant and the piping connections.

In this phase of the project we need to be able to generate and collect data about all these things, but there is nothing tangible yet. We deal here with what ISO 15926 calls "FunctionalPhysicalObject"s. SAP calls them Function Places. The definition for them is:          

"A FunctionalPhysicalObject is a PhysicalObject that has functional, rather than material, continuity as its basis for identity".

Functional physical objects ("FPO") often get a tag number, or equipment number, or line number, but by far not all FPOs get one (e.g. an elbow in a (pipe)line normally doesn't get one, unless we need to store information that is specifically about that elbow, such as a material certificate).

As can be seen on above diagram, a particular FPO is a member of a ClassOfFunctionalObject. The latter is a very generic class, such as PUMP FUNCTION. The definition of ClassOfFunctionalObject is:

"A ClassOfFunctionalObject is a ClassOfArrangedIndividual that indicates the function or purpose of an object."

EXAMPLE Pump, valve, and car are examples of ClassOfFunctionalObject. Particular models of pump, valve, car, etc are instances of ClassOfInanimatePhysicalObject that are specializations of these instances of ClassOfFunctionalObject.

The role of Specification ("data sheet')

Let us focus now on our proverbial pump P-101. Its story is typical for most equipment and other hardware.

The Mechanical Engineers write a Pump Specification, based on a set of process data that has been derived from the process design done by the Process Engineers. That specification also covers all sorts of requirements by the authorities and the future plant owner (e.g. required overcapacity). A specification is the definition of a ClassOfInanimatePhysicalObject of which the particular FPO is a member.

Because that FPO is already a member of the instance of ClassOfFunctionalObject "PUMP FUNCTION", the above ClassOfInanimate PhysicalObject shall be a subclass of "PUMP FUNCTION".

A specification is sent to, say, three suppliers with a request for quotation (see below). It details all requirements for the piece of hardware that we want to buy.

The role of the P&ID

The pump symbol by itself does not reveal much news. It is the place and function of that pump in the context of the plant network that tells what the role of that pump really is.

The P&ID (co-)defines a ClassOfInanimatePhysicalObject is that you can build more than one plant from the same P&ID. Think about parallel trains in a plant, or about P&IDs of process licensors.

Having said that, nothing stops a software supplier to generate FPOs on the basis of the P&ID. That is very useful when defining the connectivity of all FPOs. Manually that is undoable, and certainly not maintainable.

Procurement

The yellow part of above diagram deals with the physical world. Suppliers can specify their instances of ClassOfInanimatePhysicalObject as entries in their catalogs. Next to that they have other documentation that relates to these classes.

A task of the Procurement group, together with the related technical disciplines, is to make a selection of the offered goods (and services), by comparing them with the requirements as set forth for the PFOs. That is not always easy and certainly hard to automate.

But once the decision has been made that, in this case, the offered pump meets those requirement, then this can be put on record by creating a ClassOfInanimatePhysicalObject that is a (class of)temporal part of the offered ClassOfInanimatePhysicalObject AND of the requirements ClassOfInanimatePhysicalObject. This should be done not only for the successful bidder, but also for any other bidder, if so applicable. By doing so it will be easy to find an alternative in case of problems with the successful bidder/supplier.

Construction

Whenever the MaterializedPhysicalObject is installed at the "Function Place", that is put on record with declaring the installed item to be a temporal part of both the FunctionalPhysicalObject AND that MaterializedPhysicalObject (Figure 51 of ISO 15926-2).

Inheritance

An interesting aspect is that the installed item inherits all information (except meta-information) from its temporal "wholes".