Replacing old with new information in a façade

Post Reply
Message
Author
HansTeijgeler
Posts: 283
Joined: Sun Jan 22, 2012 10:02 pm

Replacing old with new information in a façade

#1 Post by HansTeijgeler »

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.

KeithWillshaw
Posts: 77
Joined: Tue May 15, 2012 8:48 am

Re: Replacing old with new information in a façade

#2 Post by KeithWillshaw »

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

HansTeijgeler
Posts: 283
Joined: Sun Jan 22, 2012 10:02 pm

Re: Replacing old with new information in a façade

#3 Post by HansTeijgeler »

@Keith - Thanks for your contribution! In general I agree with what you wrote. I have a few remarks:
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.

I start to believe that on 2D schemas we should look at the line as a whole with two or more ports, connecting to ports of equipment and instruments. The real connection information comes from 3D where "intra-pipe" connections are between instances of FunctionalPhysicalObject, for piping being the segments and the fittings.

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 deprecating the original
classification.

Agreed. There is a template for deprecating that original classification (or specialization in case of design classes) as defined at declaration of the thing.

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.

Any installed physical object is a temporal part of both the applicable functional physical object AND the applicable materialized physical object. Since the relationship TemporalWholePart is transitive, that installed physical object has automatically both the tag and the serial number.

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.

Agreed. When it comes to time series of properties I suggest to store these in HDF5 format per period in time (e.g. shift). That HDF5 file is an instance of ClassOfInformationRepresentation that quantifies a possessed real-world Property. Analysis of such time series can provide information like max, min, average, normal, etc.

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.

Agreed. Cardinalities shall be defined selectively indeed.

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.

Yes, see for example http://www.15926.org/templatespecs/CL-DOCS-11.xml and http://www.15926.org/templatespecs/CL-DOCS-12.xml. The former is a mere reference on a document to a referred class (e.g. P-101 is shown on a P&ID), the latter states that the class is defined/described in the document (e.g. a data sheet).

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.

Yes, a Class or Individual can, by virtue of its (class of) temporal parts be participating or be involved_by_reference in many activities at the same time. And those actvities can have many participants/involvants as well at the same time. The cardinalities regulate that, see http://www.15926.info/class-of-relation ... nality.htm. The cardinalities defines how many member relationships of the (subtype of) ClassofRelationship may exist involving end1 and how many with end 2 involved.

BUT... having said all this we will have to discover and formally define (Rules) the criteria upon which it can be detected that a new template does replace an older template, or not. Let's keep that in mind and revisit this topic when, at any time, we have found more examples.

Post Reply