New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow arbitrarily nested Boolean formulae #58

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@rakhimov
Member

rakhimov commented Jan 20, 2018

The MEF allows writing complex, nested Boolean formulae to define gates.
It is indeed very general and powerful,
but do the MEF and model developers need this power?
There is no reasoning in the standard justifying this complexity.

I can't find any FTA software currently supporting this MEF feature
except for SCRAM.
Having implemented this "feature" in SCRAM,
I concluded that this approach requires
a fundamentally different treatment of gates and input events.
It is peculiar to the MEF and confusing to users.
It is hard/impossible to represent graphically with traditional methods
without unconventional approaches
(phony gates/circuits/textual formula).

I reckon wiser people already avoid such complexity.
Excerpt from XFTA manual:

Nothing prevents to use nested formulae
(such as a ‘and’ of ‘or’ of events).
However, a best practice recommended by all safety standards is
to introduce an intermediary event per logical gate.
The only exception to this rule is negations,
as illustrated in our example...

Following the wisdom,
the MEF schema is modified to allow
only events or negations of events -- not formulas --
as Boolean formula arguments.
Note this only requires a schema/grammar change,
no specification wording is needed
because the original nested-formula is not specified in the first place.

Disallow arbitrarily nested Boolean formulae
The MEF allows writing complex, nested Boolean formulae to define gates.
It is indeed very general and powerful,
but do the MEF and model developers need this power?
There is no reasoning in the standard justifying this complexity.

I can't find any FTA software currently supporting this MEF feature
except for SCRAM.
Having implemented this "feature" in SCRAM,
I concluded that this approach requires
a fundamentally different treatment of gates and input events.
It is peculiar to the MEF and confusing to users.
It is hard/impossible to represent graphically with traditional methods
without unconventional approaches
(phony gates/circuits/textual formula).

I reckon wiser people already avoid such complexity.
Excerpt from XFTA manual:
```
Nothing prevents to use nested formulae
(such as a ‘and’ of ‘or’ of events).
However, a best practice recommended by all safety standards is
to introduce an intermediary event per logical gate.
The only exception to this rule is negations,
as illustrated in our example...
```

Following the wisdom,
the MEF schema is modified to allow
only events or negations of events -- not formulas --
as Boolean formula arguments.
Note this only requires a schema/grammar change,
no specification wording is needed
because the original nested-formula is not specified in the first place.

@rakhimov rakhimov requested a review from open-psa/mef-editors Jan 20, 2018

@cfolleau

This comment has been minimized.

Member

cfolleau commented Jan 20, 2018

Our computation engine handle it, but our user interface contains only "usual" gates, since no human behing use gate with formula.
But I am not sure it can be deleted without asking everybody, especially people generating fault tree from other models.

@rakhimov

This comment has been minimized.

Member

rakhimov commented Jan 22, 2018

There's one place the MEF implicitly assumes nested formulas:
event tree collect-formula instruction.

The collection of a top event consists in a Boolean product of the formula
associated with the sequence and a copy of the fault tree rooted with the top event.
In the Model Exchange Format,
the operation is performed by means of the instruction "collect-formula".

However, this collection approach can be left as an implementation detail.
For example, the collected nested formula can always be turned into "phony" (internal) gates,
which actually aid logging and debugging.
Anyway, the collected formulas are unlikely to be comprehensible by users in their final form.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment