Introduction
In the mid nineties there was a fundamental difference of opinion about the relationship between functional and physical objects, or as GARM (Generic AEC Reference Model) says (on page 173): between 'functional units' and 'technical solutions'.
In 1996 a compromise was reached and two subtypes of PhysicalObjects were added to the model of ISO 15926-2: FunctionalPhysicalObject and MaterializedPhysicalObject.Unfortunately these have caused more confusion.
In Part 2 you can find the infamous Figure 51:
In 2018 Matthew West introduced the concept of Possible Worlds, which actually had been implied already by the entity names PossibleIndividual and ActualIndividual.
ISO 15926-2 states:
4.7.6 Actual individual
actual_individuals are possible_individuals that actually exist in the real world (see 5.2.6.1). things that we may have planned in the past, or plan or expect in the future that never happen remain as just possible_individuals. Only those possible_individuals that come to pass are also actual_individuals.
Matthew agreed with the introduction of NonActualIndividual, which now have already found acceptance in Parts 11 and 12 of ISO 15926. It has been proposed for inclusion in the next update of Part 2.
A 'Tag', a.k.a. 'Functional Location', now is typed as a NonActualIndividual and a (subtype of) PhysicalObject in an 'Engineering World'. So in fact we don't need FunctionalPhysicalObject any longer. Neither do we need the MaterializedPhysicalObject, because that simply is an ActualIndividual and a (subtype of) PhysicalObject.
BUT: paradigms play a big role in modeling, and that soon become apparent here again. Let me explain that:
ISO 15926 and its predecessor ISO 10303-221 were driven by owner/operator folks. If we step back one or two decades most information about a project, handed over from an EPC contractor to the owner/operator came in the form of paper documents, ship containers full of them.
I remember a project where the O/O had a team of 25 persons who had to organize all that information into a locally used system. That system then, I guess, was seen as their Actual FunctionalPhysicalObject. (In order to contrast that with actual physical objects the concept of MaterializedPhysicalObject was created in 1996.)
Given the fact that the process industries are rather conservative, this is still the situation, be it that organizations like IOGP now work on their standard set of hand-over data with their JIP36 a.k.a. CFIHOS endeavour. For that reason alone that Actual FunctionalPhysicalObject, PLM Node [83] has been re-instated in the PLM.
Whenever an owner/operator would decide to demand from EPC contractors to hand over all information in an integrated manner according ISO 15926-8, then PLM Node [83] can be eliminated and Nodes [46] amd [84] are counterparts again.
"As-built"
A related subject of disagreement is that of "As-built" documents and data. O/O's who have not implemented ISO 15926-8 now can attribute that information to their Actual FPO. That raises the question: where to put "As-built" information in ISO 15926-8 information? Well, that depends what the definition of "As-built" applies. My definition would be as follows:
As-built documents are engineering documents that are marked-up with changes during the life of a plant of component thereof.
In case you have implemented ISO 15926-8 those changes must be made in the engineering documents that are made or revised in one of the Life-cycle Activities, represented in the PLM. It means that when you make a change that must be done under the rules and checks of the applicable Life-cycle Activity. Actually you change one or more aspects of the "design intent" (or correct errors in it).
A related mistake, rooting in the paper era without computers, is to mix supplier data in requirements data, often done in specifications. IOGP, in their JIP33 project, is curing that by separating these data, be it on the same document. But what about the situation that the purchased plant item has been replaced with an existing, but different, one from stock? Requirements data belong in Technical Specifications, whereas supplier data belong in Product Specifications of the suppliers. Bringing the two sets together is where computers are for.