Properties in a HEED lifecycle model

Post Reply
Message
Author
vvagr
Posts: 282
Joined: Mon Feb 27, 2012 11:01 pm
Location: Moscow, Russia
Contact:

Properties in a HEED lifecycle model

#1 Post by vvagr »

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 http://www.15926.org/publications/HEED/ ... /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 http://www.15926.org/publications/HEED/ ... ntents.htm yet.

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

Re: Properties in a HEED lifecycle model

#2 Post by KeithWillshaw »

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 http://www.15926.org/publications/HEED/ ... /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 http://www.15926.org/publications/HEED/ ... ntents.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

sara736
Posts: 1
Joined: Tue Sep 23, 2014 4:23 am

Re: Properties in a HEED lifecycle model

#3 Post by sara736 »

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

Post Reply