FTA is an analysis method that breaks down an undesired behavior of a system to different root causes and thus reveals systematic failures and weak points of the system. Just like FMEA, FTA also originates from aerospace engineering, hence is it highly utilized in safety critical engineering. One of the most significant differences between FMEA and FTA is that FTA takes simultaneous errors into account while FMEA does not.
In regards of ISO26262 FTA is most commonly used as the mandatory deductive analysis tool for ASIL C and D safety artifacts. The most beneficial aspect of FTA however is the effective and structured breakdown of a safety artifact. If you are already experienced with FTAs here are 5 mistakes to avoid:
I. Seeing FTA as a requirement breakdown method
It’s a common mistake, when safety engineers set a requirement as the top element of the FTA. For example, “Blockage of steering shall be avoided”, then as the root failures they define the requirements that shall be fulfilled in order to fulfill the top requirement. This is a way of skipping a few steps between analysis and the outcome, and therefore it can jinx the whole point of the FTA. Remember, the top of the fault tree is the failure that is caused by not fulfilling a functional safety requirement or safety goal. And on the branches of the fault tree there should be root errors. Only and the end of a branch shall we define the preventing requirement.
II. Skipping levels
If we return to the previous example an error of skipping levels would be to flatten the fault tree and skipping interim failures. This usually happens when the product is almost ready for production and the functional safety work was not carried out parallel to the product development. An example of this mistake would be listing a root cause to a top failure of “Picture freeze of the rear-view camera on the display” as “ISP buffer freeze”. This mistake not only costs us higher ASIL level requirements (as the common cause errors are not discovered, thus decomposition is not possible) but poses a higher risk on missing a possible fault on lower levels.
III. Listing unplausible errors
Similar to the FMEA this is where domain knowledge and industry experience plays a large role in the completeness of the analysis. And again, important to mention that FTA is not a design tool either. It’s an analysis tool for a system that has been designed and the limitations are well known. For example, we can’t expect an ISP buffer freeze causing a complete image freeze if the buffer cache memory exceeds the size of a full frame.
IV. Not minding the independence
A very handy feature of the FTA is that if the precondition to a failure is two other failures occurring simultaneously, we are allowed to decompose the ASIL of the top failure. This method is supported and described in the ISO26262 standard and comes it useful when we want to decrease the integrity level of our safety requirements. But very often the requirement of the independence is forgotten. For example, if out top failure is “communication loss due to undervoltage” we can’t decompose it to “undervoltage in the MCU” and “undervoltage in the CAN phy” since they are not independent errors.
V. Not breaking down the timing
Usually forgotten and described in later stages of the development, but FTTI is just as important as the requirement itself. In the concept phase the FTTI is usually omitted or just added as <tbd>, but it should be handles as an important part of the requirement. The same applies when breaking them down, The timing of the resulting requirements and even the safety mechanisms depend largely on the needed timing. For example, if an MCU can not fulfill the fault detection time requirement an complete redesign might be necessary, and with the progression of the development it gets exponentially more expensive. Therefore, the timings shall be handled early and with the same focus as the requirements.
Leave a Reply