Definition<\/strong><\/h4>\nThe fault tree analysis is a top-down, deductive failure analysis that analyzes the undesirable state of a scheme using Boolean logic to combine a sequence of lower-level occurrences.<\/p>\n
Synonym(s):\u00a0<\/strong><\/h4>\nFault Tree Diagram, Negative Analytical Tree -though technically, the Fault Tree Analysis outputs the diagram\/ tree<\/p>\n
Description:\u00a0<\/strong><\/h4>\nThe technique is used mainly in aerospace, engineering and high-hazard industries, but also in software engineering for debugging purposes and determining data quality issues and their causes. The main output is a Fault Tree Diagram (FTD). It is a top-down approach to show the pathways within a system that can lead to a foreseeable, undesirable failure – in our case, a data quality issue. The pathways connect contributory events and conditions, using standard logic symbols (AND, OR, etc.). At the very basic level, the constructs in a fault tree diagram are:<\/p>\n
\n- gates\/ conditions\/ logic gates (all synonyms), and<\/li>\n
- events.<\/li>\n<\/ol>\n
![\"data](\"https:\/\/i0.wp.com\/www.lightsondata.com\/wp-content\/uploads\/2019\/09\/ftd.png?resize=1663%2C1189&ssl=1\")
<\/p>\n
<\/p>\n
<\/div>\n![\"fault](\"https:\/\/i0.wp.com\/www.lightsondata.com\/wp-content\/uploads\/2019\/09\/ftd-gates.png?resize=300%2C184&ssl=1\")
This is oversimplified, but you get the idea. By the way, there are a few other gate types and diagram elements that can be used. If you’re interested in learning more, you can check out the Fault Tree Analysis: A Bibliography from the NASA Scientific and Technical Information (STI) Program<\/a>.<\/p>\nFun fact<\/strong><\/h4>\nThe basic concept was developed at Bell Telephone Laboratories in 1962 by H.A. Watson, under contract for the US Air Force for use with the Minuteman system. Fun fact within a fun fact: Minuteman system refers to the Minuteman I Intercontinental Ballistic Missile (ICBM) Launch Control System. All the fail safe needed to be in place for this. The technique was later adopted and extensively used by Boeing and the rest is history.<\/p>\n
When to use the fault tree analysis<\/strong><\/h4>\n\n- When needed to understand the logic leading to the data quality issue<\/li>\n
- To show compliance with the data quality requirements<\/li>\n
- Prioritize the resolution of the causes leading to the top event, i.e. the data quality issue<\/li>\n
- If you need to create a diagnostic processes for a data quality resolution<\/li>\n<\/ul>\n
Pros<\/strong><\/h4>\n\n- A highly structured and graphical representation of causes and events leading to the data quality issue<\/li>\n
- Can effectively be used for analysis of recurrent and persistent data quality issues, because such issues tent to have common causes<\/li>\n
- Good visualization for presenting issues to stakeholders<\/li>\n<\/ul>\n
Cons<\/strong><\/h4>\n\n- If a wrong cause is identified, subsequent causes in the tree might be erroneous or invalid and time is wasted exploring that branch of the tree<\/li>\n
- If there are too many branches and levels, it might be hard to keep track.<\/li>\n<\/ul>\n
\nAvoid the pitfalls of bad data quality.\u00a0 Here are the\u00a04 myths about data quality everyone thinks are true<\/a>.<\/em><\/h3>\n
\n <\/p>\n
Steps to develop it<\/strong><\/h4>\n1. State the data quality issue:<\/strong> This is the issue for which you will determine the causes. Ideally you will have a different fault tree diagram for each system\/ process that you want to examine<\/p>\n2. Determine top level faults:<\/strong> Brainstorm the main categories with the subject matter experts in the system\/ process.<\/p>\n3. Identify causes for top level faults:<\/strong> Brainstorm the main reasons for bad data quality and point them to the above top levels<\/p>\n4. Identify next levels:<\/strong> For each cause, see if the tree goes deeper and keep on adding levels.<\/p>\nTips<\/strong><\/h4>\n
Fault Tree Diagram, Negative Analytical Tree -though technically, the Fault Tree Analysis outputs the diagram\/ tree<\/p>\n
Description:\u00a0<\/strong><\/h4>\nThe technique is used mainly in aerospace, engineering and high-hazard industries, but also in software engineering for debugging purposes and determining data quality issues and their causes. The main output is a Fault Tree Diagram (FTD). It is a top-down approach to show the pathways within a system that can lead to a foreseeable, undesirable failure – in our case, a data quality issue. The pathways connect contributory events and conditions, using standard logic symbols (AND, OR, etc.). At the very basic level, the constructs in a fault tree diagram are:<\/p>\n
\n- gates\/ conditions\/ logic gates (all synonyms), and<\/li>\n
- events.<\/li>\n<\/ol>\n
<\/p>\n
<\/p>\n
<\/div>\nThis is oversimplified, but you get the idea. By the way, there are a few other gate types and diagram elements that can be used. If you’re interested in learning more, you can check out the Fault Tree Analysis: A Bibliography from the NASA Scientific and Technical Information (STI) Program<\/a>.<\/p>\nFun fact<\/strong><\/h4>\nThe basic concept was developed at Bell Telephone Laboratories in 1962 by H.A. Watson, under contract for the US Air Force for use with the Minuteman system. Fun fact within a fun fact: Minuteman system refers to the Minuteman I Intercontinental Ballistic Missile (ICBM) Launch Control System. All the fail safe needed to be in place for this. The technique was later adopted and extensively used by Boeing and the rest is history.<\/p>\n
When to use the fault tree analysis<\/strong><\/h4>\n\n- When needed to understand the logic leading to the data quality issue<\/li>\n
- To show compliance with the data quality requirements<\/li>\n
- Prioritize the resolution of the causes leading to the top event, i.e. the data quality issue<\/li>\n
- If you need to create a diagnostic processes for a data quality resolution<\/li>\n<\/ul>\n
Pros<\/strong><\/h4>\n\n- A highly structured and graphical representation of causes and events leading to the data quality issue<\/li>\n
- Can effectively be used for analysis of recurrent and persistent data quality issues, because such issues tent to have common causes<\/li>\n
- Good visualization for presenting issues to stakeholders<\/li>\n<\/ul>\n
Cons<\/strong><\/h4>\n\n- If a wrong cause is identified, subsequent causes in the tree might be erroneous or invalid and time is wasted exploring that branch of the tree<\/li>\n
- If there are too many branches and levels, it might be hard to keep track.<\/li>\n<\/ul>\n
\nAvoid the pitfalls of bad data quality.\u00a0 Here are the\u00a04 myths about data quality everyone thinks are true<\/a>.<\/em><\/h3>\n
\n <\/p>\n
Steps to develop it<\/strong><\/h4>\n1. State the data quality issue:<\/strong> This is the issue for which you will determine the causes. Ideally you will have a different fault tree diagram for each system\/ process that you want to examine<\/p>\n2. Determine top level faults:<\/strong> Brainstorm the main categories with the subject matter experts in the system\/ process.<\/p>\n3. Identify causes for top level faults:<\/strong> Brainstorm the main reasons for bad data quality and point them to the above top levels<\/p>\n4. Identify next levels:<\/strong> For each cause, see if the tree goes deeper and keep on adding levels.<\/p>\nTips<\/strong><\/h4>\n
<\/p>\n
<\/p>\n
The basic concept was developed at Bell Telephone Laboratories in 1962 by H.A. Watson, under contract for the US Air Force for use with the Minuteman system. Fun fact within a fun fact: Minuteman system refers to the Minuteman I Intercontinental Ballistic Missile (ICBM) Launch Control System. All the fail safe needed to be in place for this. The technique was later adopted and extensively used by Boeing and the rest is history.<\/p>\n <\/p>\n 1. State the data quality issue:<\/strong> This is the issue for which you will determine the causes. Ideally you will have a different fault tree diagram for each system\/ process that you want to examine<\/p>\n 2. Determine top level faults:<\/strong> Brainstorm the main categories with the subject matter experts in the system\/ process.<\/p>\n 3. Identify causes for top level faults:<\/strong> Brainstorm the main reasons for bad data quality and point them to the above top levels<\/p>\n 4. Identify next levels:<\/strong> For each cause, see if the tree goes deeper and keep on adding levels.<\/p>\nThis is oversimplified, but you get the idea. By the way, there are a few other gate types and diagram elements that can be used. If you’re interested in learning more, you can check out the Fault Tree Analysis: A Bibliography from the NASA Scientific and Technical Information (STI) Program<\/a>.<\/p>\nFun fact<\/strong><\/h4>\n
When to use the fault tree analysis<\/strong><\/h4>\n
\n
Pros<\/strong><\/h4>\n
\n
Cons<\/strong><\/h4>\n
\n
\nAvoid the pitfalls of bad data quality.\u00a0 Here are the\u00a04 myths about data quality everyone thinks are true<\/a>.<\/em><\/h3>\n
\nSteps to develop it<\/strong><\/h4>\n
Tips<\/strong><\/h4>\n