How to compute a specific gate

[Emmanuel]

Hi everybody,

Is there a way to compute a specific gate in a whole fault tree ?

It is often necessary to focus on small part of a whole fault tree.

Thank you,
regards.

[Olzhas Rakhimov]

Hi Emmanuel,

On Wed, Jan 17, 2018 at 6:04 AM, Emmanuel <manu.c...@gmail.com> wrote:

Hi everybody,

Is there a way to compute a specific gate in a whole fault tree ?

It is often necessary to focus on small part of a whole fault tree.

​It must be in its own fault tree (i.e. a root of another fault tree).

​Currently, the analysis targets are picked up implicitly.

This thread may also be relevant:

https://groups.google.com/d/msg/scram-users/Pg5qDlzB0iw/nKuYiXf-CgAJ

Regards,

Olzhas Rakhimov​

[Olzhas Rakhimov]

Dear Emmanuel,

Please keep the discussion on the users list.

On Wed, Jan 17, 2018 at 6:49 AM, Emmanuel CLEMENT <manu.c...@gmail.com> wrote:

Thank Olzhas, but in this case, the whole fault tree will be computed and then may take long time for huge fault trees.

Is-that true ?

​

​The current approach is you have to split model into multiple files.

Each file containing an analysis target,

so you don't need to compute the whole model each time

Olzhas

[Emmanuel CLEMENT]

How can I split a model like this:

G1 = G2 or G3

G2 = E1 and E2

G3 = E3 and E4

I want to compute G1 and then G2.

Of course, a real fault tree contains much more gates and events. It's just an example.

[Olzhas Rakhimov]

On Wed, Jan 17, 2018 at 05:46:12PM +0100, Emmanuel CLEMENT wrote:
> How can I split a model like this:
>
> G1 = G2 or G3
> G2 = E1 and E2
> G3 = E3 and E4
>
> I want to compute G1 and then G2.
>
> Of course, a real fault tree contains much more gates and events. It's just
> an example.

There are multiple ways.
An example could be as follows.

file my_model.xml:

<opsa-mef name="my-model">
<define-fault-tree name="G1-tree">
<define-gate name="G1">
<or>
<event name="G2"/>
<event name="G3"/>
</or>
</define-gate>
<define-gate name="G3">
<and>
<event name="E3"/>
<event name="E4"/>
</and>
</define-gate>
</define-fault-tree>
</opsa-mef>


file my_model_basic_events.xml:

<opsa-mef>
<model-data>
<define-basic-event name="E1"/>
<define-basic-event name="E2"/>
<define-basic-event name="E3"/>
<define-basic-event name="E4"/>
</model-data>
</opsa-mef>


file my_G2.xml:

<opsa-mef>
<define-fault-tree name="Subsystem">
<define-gate name="G2">
<and>
<event name="E1"/>
<event name="E2"/>
</and>
</define-gate>
</define-fault-tree>
</opsa-mef>


analysis of the subsystem:

scram my_G2.xml my_model_basic_events.xml

or to analyze the whole model & subsystem:

scram my_model.xml my_G2.xml my_model_basic_events.xml


Alternatively, XInclude or config file can be used
to group files for analysis.

Note that this assumes that the gate is a legitimate subsystem
that is of analysis interest -- not any ad-hoc intermediate events.

As discussed in the previous threads,
there was an interest in explicit analysis target specification,
for example in command-line or config:
scram --target G2

But this didn't get much priority
because ideally, such configuration will need to be a language in itself
alongside the model exchange format.
That "config" language needs to be able to distinguish
fault trees, event trees, sequences, alignments, etc.
This may seem simple for a fault tree with gate targets only,
but in an analysis of a whole model with other constructs,
it becomes unwieldy and requires a full-fledged domain specific language.

Instead, the current approach is to utilize
the power of the command-line
with file-based analysis.
This approach should also be beneficial
for the model maintenance and collaboration.
No more putting everything into one gigantic file.

Regards,
Olzhas

[Emmanuel CLEMENT]

Ok, I understand your point of view.

I agree with your proposition to use file-based analysis for complex systems. But I think that it address a different problem. File-based analysis allows to address industrial sized models with many contributors. This feature doesn't address correctly our problem.
However, I thing that our request (gate target by command line) is very very important for industrial use cases such as :

1. To know the importance of each scenarios described in the fault trees (safety models);
2. To compute intermediate events related to sub-systems;
3. To compute intermediate events for RAMS allocation requirements.
4. etc...

If one of goals is to get SCRAM adopted in industrial projects, I think that this feature is absolutely necessary.

Regards.

--
You received this message because you are subscribed to the Google Groups "SCRAM Support and User Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scram-users+unsubscribe@googlegroups.com.
To post to this group, send email to scram...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scram-users/20180117172722.GA11123%40Acer-4830T.

For more options, visit https://groups.google.com/d/optout.

[Jacob Ormerod]

I think progressive calculation of gates had been on a list of things to do, or at least thought about.

This would be one of my priority items if we were to embed the SCRAM core into an R package. As you could see having intermediate results at each gate is a key feature of the FaultTree package on R.

To unsubscribe from this group and stop receiving emails from it, send an email to scram-users...@googlegroups.com.

To post to this group, send email to scram...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/scram-users/CABwf_GWmfD-7xQOhSFny5dLfgh0oPrDVU8%2Bdq8SpQb-5%3D1r71A%40mail.gmail.com.