Functional and Physical Objects - the big picture
The activities around the implementation of ISO 15926 are, for the most, bottom-up, which is good for a quick deployment. This document tries to sketch a scenario for true lifecycle information management on the basis of ISO 15926.
The design of a plant is, in principle, not different from the design of a car or airplane. Just the number of copies is different. Where a car design is used to produce upto millions of such a car, a plant design usually (not always) results in one plant. Sometimes multiple plants or parts thereof are built according a plant design (e.g. in cases of parallel "trains", and in cases the design of a process licensor is being used).
The objects handled in the design process are classes, resulting in a car class (e.g. Mercedes 300SEL) or airplane class (e.g. Boeing 747), with numerous variant classes, due to customer requirements.
All components of such a design are classes as well.
The design of a plant starts with process design. In essence this is ClassOfActivity-centric, with instances of ClassOfStream*) as input and output, and instances of ClassOfFunctionalObject as the participants whose function, once materialized, it is to execute the activity to the stream(s).
*) Not a Part 2 entity type, shall be in the EDM (extended data model) as a subclass of ClassOfInanimatePhysicalObject.
This functional process design results in documents like a PFD (Process Flow Diagram) and Heat and Material Balances. Derived from that the "Process Conditions" for equipment, piping, and instrumentation are produced.
Oil refinery processes, showing instances of ClassOfActivity and ClassOfStream
Although disputed by some, the concept of the so-called Hamburger Model, designed by Wim Gielingh et al in 1988, explains this:
This can be applied at all composition levels, from the entire plant down to components.
If you read:
you're pretty close to understanding the concept.
Now the engineering groups (Process, Mechanical, Control Systems, Electrical, Piping) translate this process design into P&IDs (Piping and Instrument Diagrams) and specifications for all plant items.
If you look at the specification/data sheet for P101, you see things like:
All of them are criteria for membership of the requirements class P101.
Most of these requirements are based on the place and role that P101 has in the plant design. If the process design and/or plant design changes, we may need a different P101 class, with its definition recorded in a revised specification/data sheet.
And if a member of the P101 class had already been installed, we may need another pump. If the existing installed pump complies with those new criteria for membership, it can stay in situ, if not we have to obtain and install another PhysicalObject that does comply with the revised P101 class.
Karl Popper's Three Worlds of Knowledge
Although equally disputed by some, the concept of the so-called Three Worlds of Knowledge, described by the late philosopher Kart Popper has validity in our case.
World 1: There is, first, the world that consists of physical bodies: of stones and of stars; of plants and of animals; but also of radiation, and of other forms of physical energy. I (Karl Popper) will call this physical world ‘world 1’.
World 2: There is, secondly, the mental or psychological world, the world of our feelings of pain and of pleasure, of our thoughts, of our decisions, of our perceptions and our observations; in other words, the world of mental or psychological states or processes, or of subjective experiences. I will call it ‘world 2’.
World 3: My main argument will be devoted to the defence of the reality of what I propose to call ‘world 3’. By world 3 I mean the world of the products of the human mind, such as languages; tales and stories and religious myths; scientific conjectures or theories, and mathematical constructions; songs and symphonies; paintings and sculptures. But also aeroplanes and airports and other feats of engineering.
Note - An exegesis of these worlds can be found here.
Looking back to the above we may conclude:
Difference between process design and plant design
For critical equipment a spare can be purchased at the same time, or later, against the same specification. This spare unit can be put in the warehouse or can be installed as an "installed spare", with or without automatic switch-over (below the resulting numbering with A and B will be addressed). If, for some reason, the supplier cannot deliver, e.g. because of bankruptcy, another MaterializedPhysical Object is purchased from another supplier against the same specification of the class P101.
In case an installed spare pump is required, we usually number them with A and B, here: P101A and P101B. That means that there are two classes that happen to have the same class definition, except for their service description. That spare pump did not come into existence for process technical reasons, but for business reasons (we want a maximum uptime of the plant).
Another case of A and B we may find in certain control valve configurations. For the process engineer there may be, at a particular point in the plant design, just one control valve, say FV5. Based on the heat and material balance he then may define a minimum and maximum flow that are far apart from each other, i.e. a large rangeability is required, larger than any single control valve can possibly deliver because of leakage. The control systems engineer (I used to be one for many years) then specifies two control valves, one with linear and one with equal percentage characteristics, and with split-range positioners.
What does that mean? From a process design point of view (i.e. the activity model shown on the Process Flow Diagram) we have the instance of ClassOfFunctionalObject ("Functional Unit") named FV5. The class definition of FV5 is mainly in terms of process data. The control systems engineer then designs a "Technical Solution" for FV5, here consisting of a set of interconnected things. This technical solution in its entirety still is a class, and is shown on a P&ID. This technical solution class is a subclass of FV5, it inherits the class definition from the latter.
In that technical solution we find two control valves, say FV101A and FV101B. Unlike the P101 example these two valves are completely different from each other, and are specified on two different specifications/data sheets. Without the process and control interconnections those two valves would not be able to do what FV5 requires. That is why I said that the class definition of any plant item must include data about its place and role in the plant. That sets these classes apart from those defined by standardization bodies and suppliers, because these are only focussing on the object itself, detached from any plant context (they may use a hypothetical set of "standard" process conditions for their class definition).
A peculiar example of my thesis, that tag numbers are for classes, is the pressure gauge. There are plant owners that want them to be tagged like any other instrument item, such as PG-101, PG-102, etc, but there are also plant owners that want ALL gauges with the same range tagged with that range, e.g. all pressure gauges with a range of 0-10 barg are to be tagged PG10. They are then considered to be interchangeable commodity items. For special gauges, like ones with a diaphragm seal, a special variation on that numbering system is prescribed.
We send our specification with an RFQ (Request for Quotation) to three or more potential suppliers. Each of these suppliers has a catalog which in effect is a class library, filled with subclasses of RDL classes (these subclasses shall never be part of the RDL content, by the way, but in a local library, controlled by the owner of that library).
The definition of that supplier class is completely detached from the process plant data. If process conditions are required to define the function of the class members, that is done with "standard" conditions.
Upon receipt of the quotations the responsible engineer deliberates whether or not the class definition of the offered goods complies with the criteria for membership of the ClassOfFunctionalObject P101. Then one is selected and purchased. After some time an instance of MaterializedPhysicalObject arrives at the plant and can be installed.
A temporal part of that instance of MaterializedPhysicalObject is classified as a member of the supplier's class AND, as long as it is installed as such, as a member of the P101 functional class. As soon as it has been de-installed it is no longer a member of that P101 class, because it cannot actually function as such.
In Construction we deal with instances of MaterializedPhysicalObject, each of them does, when installed (they are all properly interconnected and the plant is, after commissioning, ready to go), theoretically comply with one of the plant design classes .
In Operations we deal, as navigation reference, with the installed temporal part of instances of FunctionalPhysicalObject that are members of the instances of ClassOfFunctionalObject that resulted from the functional plant design AND of the physical plant design. Here measurement results of process fluids (e.g. flow rate, pressure, temperature) and equipment (e.g. vibration) will be collected and stored.
In Maintenance we deal with the physical plant design classes as reference, and in reality with instances of MaterializedPhysicalObject that are members of the supplier classes, and with instances of Activity that are of the maintenance-type. Here information about costs and component replacements will be collected and stored.
Please refer to http://www.15926.org/publications/general-discussions/plant-lifecycle-model/index.htm for a lifecycle model, reflecting the above.
The reader may wonder why documents are mentioned at all, where the ultimate goal of ISO 15926 seemed to be to do away with them. That goal will not be achieved in our lifetime, but we still can apply the standard. No matter how far and deep the standard is being applied, it always ends up with strings, integers and reals, and binaries.
So, rather than spending countless hours in expressing all specifications (also referred to as data sheets) fully in 15926 terms, it might be considered follow one or more of these routes:
An example from civil engineering is the difference between an architect and a civil engineer. The architect says: there shall be a dining room and the kitchen, they shall have certain dimensions and shall be close to each other. The civil engineer produces the construction drawings to make that happen. The architect does the functional design, and the civil engineer the physical design.
An example from human affairs is The President of The United States. From time to time the person "installed" as the President changes completely. At one time it is George W. Bush, at another time it is Barack Obama. The office survives these changes, presidents not always (Kennedy). But "President of The United States" is a ClassOfFunctionalObject, with rather strict criteria for membership, and a temporal part of the person Barack Obama is at present the sole active member of that functional class. The "president" is not the person alone, but the person in its role in the fabric of government, defined by the US Constitution and US laws.
Finally the infamous "pump used as an anchor" case: The class "Anchor of a Dragonfly 920 Extreme" has particular functional criteria for membership, depending on its role in the Dragonfly 920 Extreme design, such as its required mass, form and possibility to attach the anchor chain. If myPump complies with those criteria, and a temporal part of it is "installed" as anchor of myDragonfly, it is a member of that functional anchor class.