View unanswered posts | View active topics It is currently Tue Sep 25, 2018 3:09 am



Reply to topic  [ 3 posts ] 
 Properties in a HEED lifecycle model 
Author Message

Joined: Mon Feb 27, 2012 11:01 pm
Posts: 282
Location: Moscow, Russia
It is probable a stupid question from a non-engineer, but the one important for data model parsing.

Judging by the first diagram (Margin model) in publications/HEED/introduction/index.htm ,margins are applied to the same "data field".

The second diagram (Lifecycle Information Model) clearly shows that this "data field" is mapped to properties of different objects at different lifecycle stages (indirect properties of a class of stream and of a class of functional object and finally indirect properties of an individual object and stream).

Are these really the same properties of different objects? Or there will be some additional taxonomy or ontology of properties allowing to trace lifecycle history of margin application?

There are no examples for that at publications/HEED/mapping/facade-contents.htm yet.


Sun Mar 10, 2013 10:16 pm
Profile WWW

Joined: Tue May 15, 2012 8:48 am
Posts: 77
vvagr wrote:
It is probable a stupid question from a non-engineer, but the one important for data model parsing.

Judging by the first diagram (Margin model) in publications/HEED/introduction/index.htm ,margins are applied to the same "data field".

The second diagram (Lifecycle Information Model) clearly shows that this "data field" is mapped to properties of different objects at different lifecycle stages (indirect properties of a class of stream and of a class of functional object and finally indirect properties of an individual object and stream).

Are these really the same properties of different objects? Or there will be some additional taxonomy or ontology of properties allowing to trace lifecycle history of margin application?

There are no examples for that at publications/HEED/mapping/facade-contents.htm yet.


Well the situation as I see it in engineering terms is tha we are dealing with at least three different objects
and possibly more.

Take the example of a pump with the Tag Name P-100

Initially there will be a defined need for a Pumping Activity which may be either
explicitly defined in a process simulation or inferred. This typically is displayed
as a single object on a Process Flow Diagram (PFD) or as a unit operation in
the simulation package produced as part of the Conceptual design

At the detailed design stage this usually expands to a pump group of 2 or more
devices (P-100A and P-110B) and thse are Functional Objects that are show on the
P&ID. As such they do not physically exist but form the basis for the object that
will be purchased. They have properties that are derived from the Conceptual design
in the form of required mass and volumetric flowrates, auction and discharge pressures
and temperatures and estimated power consumption. These usually have safety margins
assigned by the designer.

There is then the materialized physical object which is the device actually purchased
from a supplier to meet out the functional requirements. In most cases it will be
a standard model from a manufacturers catalog that meets the needs articulated
in the design. That is to say it will have rated mass and volumetric flowrates that
at least equal and usually exceed those required in the design.
It is the difference bewteen these values that are the margins.

Finally there is the object actually in service, the performance of
physical plant usually degrades with time, espcially between services so
its usual to monitor critical performance parameters during service to
watch for this. It may become necessary to replace the pumping device
at some point so in that vase we are left with the Functional Object P-100
but now have a different physical device.

Traditionally the manner in which designers have attempted to differentiate
between such properties has been by assigning different names. So for
our example they would use the following

DESIGN MASS FLOWRATE - The Design Value
NORMAL MASS FLOWRATE - Flowrate at normal conditions
MASS FLOWRATE - Actual instantaneous Flowrate
LOWER LIMIT MASS FLOWRATE
UPPER LIMIT MASS FLOWRATE
TOTAL MASS FLOWRATE

The problems here are self evident. There is no clear guidance on which property
to use for a given lifecycle stage so the result is confusion. The IIP group
has attempted to provide a consensus on best practise but other groups may
choose an alternate.

Keith


Mon Mar 11, 2013 10:25 am
Profile

Joined: Tue Sep 23, 2014 4:23 am
Posts: 1
I understand, there was only a human-readable ID, no alpha-numerical UUIDs?

_________________
Decrease your exam stress by using our latest Pass4sure 1Y0-400 and best quality testking and wikipedia We provide with 100% pass Massachusetts Institute of Technology (MIT) along with COMPTIA and selftestengine EXIN


Tue Sep 23, 2014 9:39 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 3 posts ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
eXTReMe Tracker
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.