This topic is about instrumentation and controls, and in particular how these are being represented in the RDL.
All Instrumentation & Controls classes are, in the top of their class hierarchies, strictly separated by function. In the table below this is shown for the first level in the hierarchy:
Click here for a report showing all 738 subclasses of INSTRUMENTATION FUNCTION.
No combinatory explosion
Since most instrumentation items and all controls are combinations of above functions the number of possible combinations is unmanageable. And they are not required either, because these combinations can be made on-the-fly in a kind of "cafetaria mode", similar to composing your food by selecting food from a counter.
An integrated measuring element of a transmitter, process switch, process gauge, or process-connected recorder gets a subtag (see B14-FT-101-E below) and is related to that instrument with an AssemblyOfAnIndividual template.
Combinations of functions are done by typing with the applicable functions (see B14-FRC-101 below, typed with RECORDER and CONTROLLER).
Using templates allows for a different choice of for a further specialization at a later time. Just deprecate the old template and create a new one, whilst maintaining the old template for an audit trail.
Below three examples are given:
In ISO 15926 the concept of Possible Worlds has been adopted, for the most Actual World vs Design World, in the code defined as ActualIndividual vs NonActualIndividual.
The only relation between a PhysicalObject in a Design World and a PhysicalObject in the Actual World is by using the Counterpart relationship. The only information implied with that relationship is that the object in the Actual World has been installed in the designed function. Not that that function is 100% fulfilled. That is put on record by classifying that PhysicalObject in the Actual World with the designed Requirements Class that is also clasifying the object in the Design World. This all is shown in an excerpt from the Plant Life-cycle Model below:
Designed PhysicalObject 17 is classified with a ClassOfFunctionalObject 14 that defines the functional aspects .
Designed PhysicalObject 17 is classified with a ClassOfPhysicalObject 21 that defines the physical and functional aspects (the latter by the subClassOf relation with the ClassOfFunctionalObject).
Actual PhysicalObject 55 is the Counterpart of designed PhysicalObject 17 in the Design World.
Actual PhysicalObject 53 is classified with ClassOfPhysicalObject 19 (defined on Specification 20) and 19 is also the Requirements Class for PhysicalObject 17.