HansTeijgeler wrote:When we load a template instance in a façade, the façade software shall be capable of detecting whether or not there is an older version of that template that needs to be deprecated
This topic is to start an exchange of views on the following question: HOW?
Some thoughts:
1) it depends on the template type, some seem too generic for such detection
2) an example of that are templates for connections; fortunately this can be solved by the CAD software suppliers
3) another example was ClassificationOfxxx because there are so many classifications possible (e.g. with property, status, etc); this has been solved(?) by adding the applicable ClassOfClass to the signature (still to be discussed in the MMT)
4) for templates for Individual the cardinalities at Class level are important in order to know how many instances of the same template may exist for the same Individual, and if more than one, the problem arises to know which one of the two or more existing templates are to be deprecated.
In short: a lot of food for thought, there are no fixed solutions yet. Your thoughts and suggestions are welcome.
An interesting topic - here are some initial thoughts
a) Connections - these typically will have to be handled in the context of the 3D model or 2D representation in which they occur. In a 3D model
you may concern yourself with direct connections at Ports but typically in a 2D Schematic you deal with notional Connect Points which are Functional
rather than physical in nature.
Process Direct Connections are typically one individual or class of individual connecting to another but in electrical engineering you can have
multiple individuals directly connected. For example several wires may connect to the same screw terminal.
b) Properties - the key I think here is some form of time stamp such as meta:valEffectiveDate. The strategy here would normally be to retrieve
the latest values with option of retrieving historic values if required - to establish a historic pattern for equipment degradation for example.
c) Classification- another interesting set of problems. Adding the applicable ClassOfClass certainly helps but we do need to handle the situation
that results when Classification is refined during the design process. Let me give an example
i) A P&ID Diagram shows an equipment as being of class CentrifugalPump and a supplier is asked to tender for that and provides his data.
The solution he suggests is of class SubmersibleCentrifugalPump. If this data is put into the facade we need to be smart enough to handle
the fact that the SubmersibleCentrifugalPump is a subclass of CentrifugalPump and that in effect both are valid.
ii) If on the other hand the supplier advises that a better solution would be a PropellerPump then we need a way of depreacting the original
classification.
d) Cardinalities - this really is going to depend somewhat on the template. In the case of Identification for example its
valid to have multiple ways of identifying an individual. The classic case is where an object may be referred to using its Functional identifier
(tag number) or its physical identifier (modelno/serial number) Ideally we would rigorously differentiate between the two
but I guarantee on a process plant everybody in the control room will use the Tag Number to refer to major equipment
items even though they really mean the physical object. e.g. P-100A is broken down again.
For properties at any given time there should only be one valid template for a specific property and that will probably be established
by time stamping.
Connections are an issue especially when dealing with IndirectConnections as a given individual can be validly connected
to many others, cardinalties may be more useful with Direct Connections. ie only one Port can directly Connect to Another
but even there we have issues since as lready mentioned a screw terminal can directly connect to many wires so adding cardinalities
to conenction templates may be a useful approach.
For representation templates we have to hand the fact that a given Individual or ClassOfIndividual may have many Representations.
An Instrument may be represented on a P&ID, Hookup Drawing, Instrument Schematic Diagram, Hazop Study etc Fortunately the new
template set allows us to handle this by specifiying the Document on Which its represented.
When it comes to Activities a Thing may participate in many Activities but again I think the new templates help by letting us specify the
ClassOfParticpation. P-100 Participates in the Activity of Pumping in the role of Pumper while Stream S-100 Particpates in the same activity
in the role of Pumped.
Regards
Keith