>> "That's all we can say with confidence right now. Will have more to say following a thorough fault tree analysis."
You're supposed to do the fault tree analysis before you build the rocket Elon. The safety critical systems on your car have these done. Or perhaps they never did one for over pressure because it seems implausible for the pressure to increase.
> You're supposed to do the fault tree analysis before you build the rocket Elon.
How can you do a fault tree analysis before things go wrong?
Maybe fault tree analysis means something different to you.
According to Wikipedia, it is "a top down, deductive failure analysis in which an undesired state of a system is analyzed using Boolean logic to combine a series of lower-level events."
There needs to be an undesirable (and presumably unforeseen) state to be analysed before you do the fault tree analysis.
>> How can you do a fault tree analysis before things go wrong?
Formal fault tree analysis has been used byt the nuclear power industry for decades. You may consult the "Fault Tree Handbook" also known as NUREG-0492 which can be found here:
It has been adopted in parts of the auto industry for at least a decade (I was directly exposed to this).
You start with a preliminary hazard analysis based on what could go wrong and work backward through the system to identify things connected to the component in question that would lead to the undesired outcome. You'll build a large binary circuit where the inputs are events or problems and the output is a failure. The tools can do an analysis to determine what combinations can lead to that failure. If the simplified boolean expression contains any single terms, you have a single point of failure that will lead to the undesired outcome. You then redesign the system so that no single point failures lead to disaster.
THIS ANALYSIS HAS TO BE DONE BEFORE YOU BUILD IT TO BE ANY GOOD.
I always liked this way better than the more common "faulure modes and effects analysis" or FMEA, which makes you try to determine system-wide consequences of component failures - often down to individual resistors. These do find problems at design time, but IMHO it's too much work. With a fault tree you get to treat larger assemblies as a component.
I'm no Risk expert, but going from memory, you hypothesize potential failures based on experience and knowledge of the module. Then you use the FTA to understand what faults may result in the failures under examination.
Generally you do a Root Cause Analysis post-event, not a Fault Tree Analysis.
Fault Trees are typically used to determine the probability of a bad thing (fault) occurring. This probability is used to populate a Risk Matrix (Probability vs Consequence). The Risk Matrix is used to decide whether the risk is low enough vs the consequence within a design. It the risk is too high, then more redundancy or layers of protection are likely to be needed.
Root Cause Analysis builds a tree of possible causes that will look much like the Fault Tree diagram but may include more human factors (was the part inspected before use, was the equipment maintained etc).
There is a lot of overlap of techniques within the Risk Engineering discipline. Fault Trees can be mapped to Reliability Block Diagrams (AND gates are equivalent to Parallel pathways, OR gates are equivalent to Series pathways for example).
The mention of Fault Tree Analysis being required post event seems a bit odd. It may just have been a confusion of terms in the heat of the moment.
You're supposed to do the fault tree analysis before you build the rocket Elon. The safety critical systems on your car have these done. Or perhaps they never did one for over pressure because it seems implausible for the pressure to increase.