Introduction
In 98% of all product models there are physical whole-part relations, such as 'my car has an engine'.
In this blog I will explain where, and why these relations apply in ISO 15926.
Individuals
Assume a non-actual pump with tag P-101 that has impeller with subtag P-101-IMP as a part. (NOTE - Each user company is of course free to have their proprietary tagging convention). The installed and commissioned actual pump in the real world is tagged with a combination of tag + asset number, here P-101/AN58382.
Where in the design world the Individual PhysicalObject is used for topological information, any record of the whole-part relation between P-101 and P-101-IMP doesn't make much sense. Actually the record of the latter doesn't make much sense either, unless an 'implements' relation between P-101-IMP/L6584ZX-1 and P-101-IMP is contemplated. That may be so in case of subsystems that require detailed engineering and utility connections. In that case there are topological relations.
In the real world a partOf relation between P-101-IMP/L6584ZX-1 and P-101/AN58382 does make sense, because it allows for a book keeping of parts exchanges.
In both worlds it does make sense to relate all plant items to a higher agglomerate (e.g. system, unit, etc), and relate the latter to the next higher, etc. Since a whole-part relationship is transitive, it does not make much sense to relate each plant items to all higher agglomerates.
Classes
The instance of ClassOfPhysicalObject with tag 'CO-P-101' is an 'Asset Requirements Class' (BTW - CO = ClassOf). The definition of this class includes classes of whole-part relations, with Cardinalities. In case P-101 were a Centrifugal Pump, the cardinality for coPartOf would normally be 1-to-many (actually, in parctice 1-to-9). Often the number of stages will be determined by the purchased pump.
Is it required to define all components? No, only those components for which you put information on record. Keep in mind that during the ISO ballot of ISO 15926-4, the reference data, the decision has been taken to avoid Property names that include the object of which it is a Property. So in this case no 'impeller diameter', but: here is an impeller and this is its diameter. Another reason for declaring components/parts is the possibility to define spare parts.
The Product Classes (MODEL) PH467X and (PART) L6584ZX : In a world where ISO 15926 were the standard, the coPartOf relation between would be mandatorily modeled to ISO 15926 by the manufacturer, and that information would made available to their customers. That would help in the years after the purchase for the communications between Supplier and Maintenance.
Finally this: Other than with Individuals a reference to the next higher agglomerate is meaningless unless you define the entire plant with all its systems and plant items as classes. But then we deal with subclass relations.