Re: Class Model
Posted: Thu May 17, 2012 1:39 pm
[HT Said]
> Much more than I have written in:
> - http://www.15926.info/plant-design/index.htm
> - http://www.15926.info/functional-vs-mat ... object.htm
> - http://www.15926.info/functional-physic ... /index.htm
> - http://www.15926.info/cradle-to-grave/index.htm
> I cannot bring to the table.
> If that does not convince you, I rest my case.
I have been through these documents and you make some very good points
with regard to the importance and nature of the Tag Code
I agree that the tag is in itself not that important.
However we still have to model both a functional and physical object that may
or may not have a tag number and what I am struggling with is why do we think it
appropriate to model it as a CLASS prior to installation and as an Individual
afterwards ?
I would argue that we have separate but related physical and functional objects well before
we bolt a pump onto its baseplate. On typical offshore projects the process
of procurement of major plant items proceeds in parallel with detailed design.
I have personallyy worked ona major gas compression project where we
ordered the compressors before the P&ID's were finalized let alone the 3D model.
There are some important aspects of the CLASS proposal that are not clear to me
from the documents and I need to clearly understand these before making any
decisions. One of the major ones is this.
If we accept that a functional plant item such as a specific PUMP should be modelled
as a class does this mean that the CLASS that represents P-101 has to be defined
in our Reference Data Library with a url and unique reference ID just as we do with
the CLASS CENTRIFUGAL PUMP ?
The implications of this are obvious in terms of maintaining and propagating the Reference Data
[HT Said]
> In response to your 4+ points:
> Re 1) - You misread me. I didn't say that for a given plant there are unlimited classes.
> But no matter how you store the lifecycle information of a plant, you end up with petabytes of data.
If I misrepresented you then I apologize for that. I understand that petabytes of data
will be acquired in the course of a plant lifecycle the issue in my mind is the
balance between having to actively maintaining Reference Data and Repositories
> Re 2) - That clean point is installation, see Part 2 fig. 51
As I mentioned earlier in the thread I thinks this is arguable. Procurement and
testing of the physical object occurs long before installation. As an example
in the case of a pump the actual shop performance test data of the physical
item being bought will be available long before installation.
> Re 3) - See http://www.infowebml.ws/mapping-methodology/index.htm
I looked at this carefully and I still have some problems with this, let me give you a use case
We are approaching the end of the detailed design phase and the client gas requested
we transfer data that essentially amounts to the Equipment List
Lets say he requires the following information
Tag Number - Normal Operating Pressure - Purchase Order Number - Purchase Status - Serial No
Clearly here we are transferring data about both the functional and physical object
so when we get to P-100 does this imply we have to define both in our Part 8 file
then associate the Design properties with the CLASS that represents P-100 and the
Physical Properties with the Individual that represents P-100 ?
IF so does this change after installation ?
> Re 4) - How do you do that in iRING?
Well within the current iRING protocols both the physical and functional objects
are individuals so the templates used dont change when we reach some particular milestone.
This does not imply that the templates currently used are correct or adequate
for lifecycle modelling. I would be the first to agree that we need to handle
the temporal aspects much better than we do at present.
> Furthermore:
> Quote:
> Its relatively easy to mak rules such as PID = Class BUT as PID's remain important and are updated long after the plant is commissioned is this a valid distinction ?
> [HT] - A distinction between what? Nobody said that you have to do away with P&IDs and other documents.
> It so happens that in the Part 2 data model we model documents as instances of ClassOfInformationObject,
> of which the contents are defined with instances of ClassOfInformationRepresentation.
> If the document deals with plant design, the objects on that document represent instances of Class.
> That remains the case until the end of the plant when all records are destroyed.
I was somewhat imprecise here. I am not speaking of the PID as a document but rather
alluding to the objects modelled as that part of the detailed design process commonly
referred to as the PID.
> Finally:
> Quote:
> Additionally an increasing number of owner operators are wanting to operate a consolidated Data Management
> system that acts as an asset register and which issues tags and stores approved changes.
> Its not clear to me how using a Class for a tagged item instead of an individual fits into this requirement.
> [HT] - ISO 15926 does not replace application software, so the issue of tags etc stays where it is now.
> But these data are mapped from such applications to the ISO 15926 Part 8 format and stored in
> federated or consolidated triple stores. Storing lifecycle information means a kind of sedimentation.
> At a later date you can do data mining and see what exactly happened in the plant.
> And by the way, if you look at the far righthand bottom corner of
> http://15926.org/publications/general-d ... /index.htm you can
> see that the assets are instances of MaterializedPhysicalObject.
Clearly ISO 15926 does not replace application software but the way we model data at
the design stage as against that from the procurement and construction phase impacts
the way we map data from the master Asset Register to the ISO 15926 world.
My problem here is practical not philosophical. My asset register is initially
populated at the design stage and contains data derived from the design, procurement
construction and operational phases. Much but not all of the data produced in the
detailed design remains important long after installation and commissioning, clearly
its subject to change so we need to consider termporal aspects but the notion of
passing some properties of the Asset in the form of Classes and others as Individuals
seems confusing to me and quite hard to manage.
If this is indeed required then we can look at the implementation issues in
greater detail but at this point I just do not see the end to go down this route.
If I am missing something important please let me know.
Regards Keith
> Much more than I have written in:
> - http://www.15926.info/plant-design/index.htm
> - http://www.15926.info/functional-vs-mat ... object.htm
> - http://www.15926.info/functional-physic ... /index.htm
> - http://www.15926.info/cradle-to-grave/index.htm
> I cannot bring to the table.
> If that does not convince you, I rest my case.
I have been through these documents and you make some very good points
with regard to the importance and nature of the Tag Code
I agree that the tag is in itself not that important.
However we still have to model both a functional and physical object that may
or may not have a tag number and what I am struggling with is why do we think it
appropriate to model it as a CLASS prior to installation and as an Individual
afterwards ?
I would argue that we have separate but related physical and functional objects well before
we bolt a pump onto its baseplate. On typical offshore projects the process
of procurement of major plant items proceeds in parallel with detailed design.
I have personallyy worked ona major gas compression project where we
ordered the compressors before the P&ID's were finalized let alone the 3D model.
There are some important aspects of the CLASS proposal that are not clear to me
from the documents and I need to clearly understand these before making any
decisions. One of the major ones is this.
If we accept that a functional plant item such as a specific PUMP should be modelled
as a class does this mean that the CLASS that represents P-101 has to be defined
in our Reference Data Library with a url and unique reference ID just as we do with
the CLASS CENTRIFUGAL PUMP ?
The implications of this are obvious in terms of maintaining and propagating the Reference Data
[HT Said]
> In response to your 4+ points:
> Re 1) - You misread me. I didn't say that for a given plant there are unlimited classes.
> But no matter how you store the lifecycle information of a plant, you end up with petabytes of data.
If I misrepresented you then I apologize for that. I understand that petabytes of data
will be acquired in the course of a plant lifecycle the issue in my mind is the
balance between having to actively maintaining Reference Data and Repositories
> Re 2) - That clean point is installation, see Part 2 fig. 51
As I mentioned earlier in the thread I thinks this is arguable. Procurement and
testing of the physical object occurs long before installation. As an example
in the case of a pump the actual shop performance test data of the physical
item being bought will be available long before installation.
> Re 3) - See http://www.infowebml.ws/mapping-methodology/index.htm
I looked at this carefully and I still have some problems with this, let me give you a use case
We are approaching the end of the detailed design phase and the client gas requested
we transfer data that essentially amounts to the Equipment List
Lets say he requires the following information
Tag Number - Normal Operating Pressure - Purchase Order Number - Purchase Status - Serial No
Clearly here we are transferring data about both the functional and physical object
so when we get to P-100 does this imply we have to define both in our Part 8 file
then associate the Design properties with the CLASS that represents P-100 and the
Physical Properties with the Individual that represents P-100 ?
IF so does this change after installation ?
> Re 4) - How do you do that in iRING?
Well within the current iRING protocols both the physical and functional objects
are individuals so the templates used dont change when we reach some particular milestone.
This does not imply that the templates currently used are correct or adequate
for lifecycle modelling. I would be the first to agree that we need to handle
the temporal aspects much better than we do at present.
> Furthermore:
> Quote:
> Its relatively easy to mak rules such as PID = Class BUT as PID's remain important and are updated long after the plant is commissioned is this a valid distinction ?
> [HT] - A distinction between what? Nobody said that you have to do away with P&IDs and other documents.
> It so happens that in the Part 2 data model we model documents as instances of ClassOfInformationObject,
> of which the contents are defined with instances of ClassOfInformationRepresentation.
> If the document deals with plant design, the objects on that document represent instances of Class.
> That remains the case until the end of the plant when all records are destroyed.
I was somewhat imprecise here. I am not speaking of the PID as a document but rather
alluding to the objects modelled as that part of the detailed design process commonly
referred to as the PID.
> Finally:
> Quote:
> Additionally an increasing number of owner operators are wanting to operate a consolidated Data Management
> system that acts as an asset register and which issues tags and stores approved changes.
> Its not clear to me how using a Class for a tagged item instead of an individual fits into this requirement.
> [HT] - ISO 15926 does not replace application software, so the issue of tags etc stays where it is now.
> But these data are mapped from such applications to the ISO 15926 Part 8 format and stored in
> federated or consolidated triple stores. Storing lifecycle information means a kind of sedimentation.
> At a later date you can do data mining and see what exactly happened in the plant.
> And by the way, if you look at the far righthand bottom corner of
> http://15926.org/publications/general-d ... /index.htm you can
> see that the assets are instances of MaterializedPhysicalObject.
Clearly ISO 15926 does not replace application software but the way we model data at
the design stage as against that from the procurement and construction phase impacts
the way we map data from the master Asset Register to the ISO 15926 world.
My problem here is practical not philosophical. My asset register is initially
populated at the design stage and contains data derived from the design, procurement
construction and operational phases. Much but not all of the data produced in the
detailed design remains important long after installation and commissioning, clearly
its subject to change so we need to consider termporal aspects but the notion of
passing some properties of the Asset in the form of Classes and others as Individuals
seems confusing to me and quite hard to manage.
If this is indeed required then we can look at the implementation issues in
greater detail but at this point I just do not see the end to go down this route.
If I am missing something important please let me know.
Regards Keith