Add specification for importance factor reporting

[rakhimov]

The commonly calculated importance factors (DIF, MIF, ...)
can be reported in attributes of variables (basic events).
The approach has been tested with SCRAM
and is flexible for new factors or omitted factors.

Note that importance factor reporting is missing for CCF events
because the general representation of them
is not yet accepted into the report layer.
It should be trivial to add CCF event importance factor reporting
(if not cumbersome, though)
after the initial formatting is established.

[cfolleau]

Dear Olzhas,
I am not sure that using attributs of variable for results is a good thing.
It could be a "measure". We should use a type for the measure. type could be : proba, MIF, CIF, DIF, frequency, etc ...
And moreover, if we want to handle results for different times an attribut won't be enough.
I think it will be more flexible.
Best regards
Cyrille

[rakhimov]

@cfolleau Indeed, I haven't considered the time at all. Would it be overkill to create/report one "importance" container with all basic events (a la state) per time point?

If we make it flexible with (measure, type, value)-like structure,
it can potentially cover more than importance factors.
Then, I think we would need to find a more general name instead of "importance"
used in this proposal,
or we could separate other parameters into their own containers and keep "importance" focused.
Honestly, I am a bit confused with reporting probability/frequency per basic event in report.
I was guessing that this information can be retrieved from the input model through the reference names of basic events.

[cfolleau]

@rakhimov
Either everything in measure with a type, or one entity per type (probability, UFI, CFI, DIF, MIF, ...). As you want. But keeping "measure" will be compatible with old files, assuming default type is probability.

Anyway, some industries absolutly need result at different points of time (see in attachment an exemple of what we do in our software)

example.zip

For frequency, the CFI of an event is very often given by its law, you are right. And UFI can be deduced from CFI and Unavailability. But when law are more complicated (Weibull or others) you can not. And for gate you can not deduce frequency (CFI or UFI) directely from event laws, it is a big computation. That why we need to save these results

[rakhimov]

@cfolleau Gotta love our acronyms :-)

[cfolleau]

@rakhimov
You are right, I may use to many acronyms :-)
UFI : Unconditional failure intensity
CFI : Conditional failure intendity
MIF : Marginal Importance Factor (Birnbaum)
CIF : Critical importance factor
DIF : Diagnostic importance factor (Fussel Vesely)

[rakhimov]

@cfolleau In the current specification, I see that "measure" is provided for statistical results.
Do you want the importance factors in similar fashion (i.e. importance-measure) ?
That sounds good to me as well.

Is the example in your attachment from pre-2.0d o post-2.0d? (I couldn't find the schema)

[cfolleau]

@rakhimov yes importance-measure if you want, so we would have a importance-measure entity with a "type" attribut among MIF CIF DIF RRW RAW etc ..., and a "component" attribut
And a measure attribut with type among Probability (Unavalailability would be better) UFI and CFI

The attached file comes from our computation engine ALBIZIA, which file format mainly comes from XML format of ARALIA made by Antoine Rauzy in 2000's
We wasn't involved in Open-PSA before 2012 so we defined our own format.

[rakhimov]

@cfolleau Can you share the schema for you own format?
By the way, you can use GitHub gists: https://gist.github.com/
to write notes or share text snippets.

[rakhimov]

@cfolleau
This is my current opinion on the (measure, type, value) construction.
I am starting to doubt that prob/unavailability, UFI, CFI per component are relevant to this container
(correct me if I am wrong, but these values sound like an input rather than output of analysis).

This container is specifically designed to hold importance factors of events
analyzed as a result of FTA/MCS given in the same report.

A programmer in me cringes a bit seeing (measure/type/value) constructs;
this reminds me too much of string-ly typed interfaces/code and jeopardized type safety.
I believe in the MEF schema currently,
we don't have (measure/type/value) approach for data
except for very general/extensible attributes.

Moreover, it adds redundant noise into the file being unnecessarily general for importance factors.
If anyone comes up with another factor,
they can stick it as attribute in any order.
The only importance factor I think missing and worth supporting is JIF(joint importance reliability factor),
but its format doesn't fit into the current proposal
due to its involvement of more than one components.

Finally, just to clarify for myself probability vs. unavailability,
probability seems to be common in PRA/PSA,
while unavailability is coming from Reliability engineering.
I really want probability of an event.
There's no guarantee that the event is always a component/part of a system.
Probability is more general and covers unavailability if one wishes.

I really believe that whoever came up with "product" for reporting both MCS/Prime Implicants
instead of going into the trap of naming them "cut-sets", for example,
was a wise man.
In the same fashion, I guess, the MEF is silent about unavailability for much of its specification.

[rakhimov]

@cfolleau Exploring the Safety Integrity Level metrics,
I now see where CFI and UFI are relevant.
I think a different schema can be suggested for reporting these SIL metrics.
It could also address your note about the evaluation of these metrics over time period.

[cfolleau]

CFI and UFI are not only SIL metrics, they were computed far before the IEC61508 exists.
Yes we can put them in a different schema to handle metrics over time, but it should be made also for "Probability".

[rakhimov]

@cfolleau Thank you!
I will hack up a schema proposal based on tag.

[rakhimov]

Two or three dimensional curves are often produced in PSA studies. A typical example
is indeed to study the evolution of the system unavailability through the time.

I completely forgot that Measure vs. Time can be reported with Curves feature;
it is general enough to support importance factors as well,
so there's no need to invent a new schema.