Process cases and conditions

Message
Author
OnnoPaap
Posts: 189
Joined: Sun Jan 22, 2012 9:14 pm

Process cases and conditions

#1 Post by OnnoPaap »

In file http://15926.org/publications/mapping/l ... t-data.txt

which can be reached by using publication Mapping of a Line List and clicking behind "A file with the mapped data as shown in above table"

there is this template instance:

Code: Select all

<!-- Operating Temperature -->

<tpl:ClassOfIndividualHasIndirectPropertyWithPointValue rdf:about="T6af67102-67b6-11e1-b86c-0800200c9a66">
    <rdf:type rdf:resource="&owl;Thing"/>
    <skos:definition>"Any member of CO_RZ17801-S shall have a NORMAL OPERATING TEMPERATURE with a value of 70 DEGREE CELSIUS."@en</skos:definition>
    <tpl:hasUrClass rdf:resource="CO_RZ17801-S"/> 
    <tpl:hasPossessorType rdf:resource="Cc88763cd-dbc2-11e1-9b23-0800200c9a66"/>
    <tpl:hasIndirectPropertyType rdf:resource="&rdl;RDS369674"/> <!-- NORMAL OPERATING TEMPERATURE -->
    <tpl:valMinimumValue rdf:datatype="&xsd;float">70</tpl:valMinimumValue>
    <tpl:hasScale rdf:resource="&rdl;RDS1322684"/> <!-- DEGREE CELSIUS -->
    <meta:valEffectiveDate rdf:datatype="&xsd;dateTime">2011-09-04T13:45:00Z</meta:valEffectiveDate>
</tpl:ClassOfIndividualHasIndirectPropertyWithPointValue>
It maps the normal operating temperature of a stream.

I am setting up the model structure of streams. I have this question:

Do we use compound classes like this one NORMAL OPERATING TEMPERATURE (http://posccaesar.org/rdl/RDS369674)
or do we make a structure of the conditions of a stream, like minimum operating, normal operating and maximum operating, and merely put a TEMPERATURE property there.

Another question: we have process data cases. DESIGN, OPERATING, STARTUP, SHUTDOWN etc. Are they also in compound classes (NORMAL OPERATING TEMPERATURE) or in a cases model?

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

Re: Process cases and conditions

#2 Post by KeithWillshaw »

We seem to have crossed threads. I just posted a little write up on the EDRC forum :)

Here it is again in word and pdf format

Keith
Attachments
Typical STREAM and CASE hierarchy and Properties.docx
(1.25 MiB) Downloaded 751 times
Typical STREAM and CASE hierarchy and Properties.pdf
(326 KiB) Downloaded 736 times

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

Re: Process cases and conditions

#3 Post by HansTeijgeler »

@Onno - The RDL is incorrect here in stating (typically) that an indirect property is a subclass of a SinglePropertyDimension. In this case even OPERATING TEMPERATURE is incorrect. Its definition states: A temperature under which an object is supposed to work. That clearly is an indirect property and not, as stated, a SinglePropertyDimension. It is NOT a subclass of TEMPERATURE !! But this is an MRAIL issue (probably the most serious one).

To answer your question: All are instances of ClassOfIndirectProperty which is a ClassOfRelationship between ClassOfindividual and PropertySpace (of which SinglePropertyDimension is a subtype). If you can't say TEMPERATURE (with or without location and/or time) without being too vague, then you deal with an indirect property. Properties can be physically measured. Part 2 states: "NOTE A property is indirect because it does not directly apply. There can only be one temperature that a thing has (at a time), so a Maximum Allowable Working Temperature is not its temperature, but an indirect property derived from doing some tests or calculations to determine its value (as opposed to it being a current measurement). This is what makes it indirect."

Assume you have two complete sets of stream data that are each other's alternative ("mode of operation", or "process case"), like "Kuwait Light" or "Brent Light" as feed stock, or Demineralization mode (of boiler feedwater) OR Regeneration mode of that unit. Here also different line-ups apply with reversal of certain streams. In those cases you must treat the two modes of operation as if you functionally design two different plants (fortunately with a maximized re-use of the same equipment).
Please read: http://www.15926.org/publications/gener ... /index.htm.

OnnoPaap
Posts: 189
Joined: Sun Jan 22, 2012 9:14 pm

Re: Process cases and conditions

#4 Post by OnnoPaap »

This doesn't answer the question. The term property wasn't used as a part 2 data type, but merely in the sense of the legacy property. I wasn't trying to say it wasn't an indirect property.

Remarks about the publication Operational modes and Catalog options:
  • The term "class of state" does it mean class_of_status? assuming it does.
  • Statusses are terms like "approved", "rejected". I think "hasImpellers" is not a status.
  • Do the arrows on the right-hand side of the diagram mean these classes classify classes of status? (the arrows point at them and it does not seem logical)
  • It it so that each process data "property" needs to have a class of temporal wholepart which is classified by an instance of class_of_class class_of_status for case (e.g. CASE DESIGN) **and** for condition?
We are trying to solve the situation of every process-connected plant item: how do you model process data of case DESIGN, and condition MINIMUM, NORMAL or MAXIMUM. The examples do not show this, as the first example of this thread should do. The process case and condition are implicit (because a compound class is used) and they should be explicit.

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

Re: Process cases and conditions

#5 Post by HansTeijgeler »

@Onno,
The term "class of state" does it mean class_of_status? assuming it does.
No state is not status. Status of an individual, such as "defective", is a state, but any information you represent with a template for individual is a state of that individual (state of being connected, of having a particular temperature, etc).
Statusses are terms like "approved", "rejected". I think "hasImpellers" is not a status.
See above
Do the arrows on the right-hand side of the diagram mean these classes classify classes of status? (the arrows point at them and it does not seem logical)
No, they mean the rest of the template.
It it so that each process data "property" needs to have a class of temporal wholepart which is classified by an instance of class_of_class class_of_status for case (e.g. CASE DESIGN) **and** for condition?
If you replace "class_of_status" with "Lifecycle Activity", then we might have a point of discussion that should have taken place long time ago. In the HEED Project it was found that it was impossible to discover in which Lifecycle Activity (e.g. Detailed Engineering") the information of a template instance originated. So we adopted the annotation property meta:hasLifecycleActivity. A few years ago I tried your solution, but that became a bit hairy, because what do you do with the instances of TemporalWholePart in templates for individual? Classify them with a class_of_class as well? Seems odd.
If we adopt that meta:hasLifecycleActivity we can, at time of mapping to OWL, use that in the applicable template of two:
ActivityCausesEffectiveClass http://www.15926.org/templatespecs/CL-PTYST-08.xml or: ActivityCausesBeginningOfIndividual http://www.15926.org/templatespecs/IN-ACTIV-06.xml

These then access the (now) hidden temporal part Individual or class-of-temporal-part ClassOfIndividual to replace the meta:valEffectiveDate and the meta:hasLifecycleActivity (the latter is used for the ClassOfActivity in above templates).

OnnoPaap
Posts: 189
Joined: Sun Jan 22, 2012 9:14 pm

Re: Process cases and conditions

#6 Post by OnnoPaap »

What does it have to do with case DESIGN, and condition MINIMUM, NORMAL or MAXIMUM of process data?

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

Re: Process cases and conditions

#7 Post by HansTeijgeler »

@Onno - What would be the alternative for your DESIGN case?

Minimum, maximum, normal xxxx are classes of indirect property.

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

Re: Process cases and conditions

#8 Post by HansTeijgeler »

@Onno - I prepared a diagram to illustrate the relation between process cases/modes of operation and stream data:
mode-of-operation.png
mode-of-operation.png (24.69 KiB) Viewed 19328 times
Pump C2 must be capable of handling, one at a time, streams 1A and 1B. Sometimes this is not possible and then two pumps may be required, with all the consequences for line-up which must also be modeled.

OnnoPaap
Posts: 189
Joined: Sun Jan 22, 2012 9:14 pm

Re: Process cases and conditions

#9 Post by OnnoPaap »

Hans, thanks.
I like the specialization of the stream to case of stream. That way a stream can also have the same process data without being a case (so, it is the design case).

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

Re: Process cases and conditions

#10 Post by HansTeijgeler »

I like the specialization of the stream to case of stream. That way a stream can also have the same process data without being a case (so, it is the design case).
I have no idea what that is supposed to mean, really. The specialization of the stream is because you have two modes of operation/process cases, so you need two sets of stream data. I still don't understand what you mean with that "design case". The only thing I could guess is that you want to store the unmodified process data coming from the heat & material balance AND the modified data for the pump specification (e.g. including a 10% overcapacity). Is it the latter that you call "design case"? If so, I think that that is not exactly what that specialization was meant for, but nobody can stop you using it.

If you do it properly, those unmodified stream data are attributed to a stream that originates from the lifecycle activity "Process Design", so there are no two data sets for the same stream.

Post Reply