thanks for taking this to the tool. It is bridging a big gap between Software and Systems Engineering modellers.
But the FTA approach requires some further details to be fully effective:
1) The data must somehow be integrated with the system elements. As far as I understand at the moment, they are seperately created shapes. In the reliability world there are blocks/classes as the main "containers", then methods and functions as the "purpose bringers" inside of the first ones. Historically design stopped there, being focussed on more and more features - not on risks. But todays projects focus more and more and risk estimations. So methods/functions again can have 1 to many failure modes, causes and effects (or in cybersecurity damages, threats and vulnerabilities).
Having this together makes way more purpose on modelling.
2) The FTA uses quantities. The example shows qualities (important either, sure). At vehicle, railway, avionics etc. approval authorities OEMs must demonstrate quantities. There you show how much some AND gates lowered FIT rates in comparison to OR gates. Shortly: the calculations are missing urgently.
3) Beneath this reliability engineers look for automatic transformations of an "as is" tree. Often some brewn construction looks like having lots of ANDs (making top failures improblable). But the retransformation to so called Minimal Cut Sets (MCS) shows, if this is true. In bigger examples a human cannot really recognize this, that's why this is required.
If you are interested in details I can support here. Let me know.
Reply To: Further usage of this
Hi Dusan,
thanks for taking this to the tool. It is bridging a big gap between Software and Systems Engineering modellers.
But the FTA approach requires some further details to be fully effective:
1) The data must somehow be integrated with the system elements. As far as I understand at the moment, they are seperately created shapes. In the reliability world there are blocks/classes as the main "containers", then methods and functions as the "purpose bringers" inside of the first ones. Historically design stopped there, being focussed on more and more features - not on risks. But todays projects focus more and more and risk estimations. So methods/functions again can have 1 to many failure modes, causes and effects (or in cybersecurity damages, threats and vulnerabilities).
Having this together makes way more purpose on modelling.
2) The FTA uses quantities. The example shows qualities (important either, sure). At vehicle, railway, avionics etc. approval authorities OEMs must demonstrate quantities. There you show how much some AND gates lowered FIT rates in comparison to OR gates. Shortly: the calculations are missing urgently.
3) Beneath this reliability engineers look for automatic transformations of an "as is" tree. Often some brewn construction looks like having lots of ANDs (making top failures improblable). But the retransformation to so called Minimal Cut Sets (MCS) shows, if this is true. In bigger examples a human cannot really recognize this, that's why this is required.
If you are interested in details I can support here. Let me know.
Thanks
Michael
Michael Gellner 2 June 2023 18:04:09