latest update: 9 June 2012
This is a short story about functional and materialized physical objects, and how they relate to each other.
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:
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:
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 in ISO 15926-2 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 fact that a P&ID (co-)defines a ClassOfInanimatePhysicalObject is because 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.
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 FPOs. 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 requirements, then this can be put on record by creating a ClassOfInanimatePhysicalObject that is a class-of-temporal-part of the offered ClassOfInanimate PhysicalObject AND of the requirements ClassOfInanimatePhysicalObject. This is in fact a class of function place.
This should be done not only for the successful bidder, but also forany 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.
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 (see Figure 51 of ISO 15926-2).
An interesting aspect is that the installed item inherits all information (except meta-information) from its temporal "wholes".
The following two templates apply:
Item #1 is declared as an instance of FunctionalPhysicalObject and as an instance of WholeLifeIndividual. Using the template IdentificationOfTemporalPart it gets its tag number ('P-101' in the diagram). Using this template allows you to change the tag number without many problems (tag numbers are notmally not changed, but it does happen).
This item #1 is the "Ur"-functional physical object that never changes, and only can be ended when it is no longer required in the system it belongs to.
A temporal part of item #1 is created in item #2, and that item is classified with the applicable instance of ClassOfArrangedIndividual (that can be a ClassOfInanimatePhysicalObject, a ClassOfOrganism (with ClassOfPerson as a subtype), ClassOfOrganization, etc.).
Whenever that class changes, you end the validity of item #2 with an instance of template EndingOfTemporalPart and you create a new instance of above template, with a new item #2 that is classified with the new version of the ClassOfArrangedIndividual.
This may sound complex, but it reflects reality. Fortunately it can be automated.
The installation activity is modeled in above template. It is based on the match between the requirements class and the class of the purchased/available object.
The item #4 physical object that is in the hasInstalledIndividual role is a temporal part of item #1 in both this and the previous template and also a temporal part of the materialized physical object item #2 in this template. The ID can be generated automatically.
Once a materialized physical object (here a pump with a serial number) is installed to perform the function defined for the functional physical object, the "Function Place", an instance of the above template is created.
All information about the installed physical object (item #4) shall be attributed to that item #4 with instances of the applicable templates, whereby item #4 fulfils the 'hasTemporalWhole' role in those templates.
Any information about the materialized physical object (item #2), that does not apply to it being installed, shall be attributed to item #2. Example: the physical object is de-installed for maintenance reasons, then any information about that maintenance shall be attributed to item #2. In the templates used for that this item #2 shall fulfil the 'hasTemporalWhole' role.
The installed individual may be replaced because of a change in the requirements that no longer can be met, or of course because of wear and tear. In that case item #4 is ended, using the EndingOfTemporalPart template, thus ending the validity of above template.
This keeps the plant information in sync with the design.