Leaderboard

Fault Tree Analysis (FTA) is a graphical technique for Reliability and Safety Analysis of Systems. It is used: to investigate potential faults its mode and causes and quantify their contribution to system unreliability in the course of product design. The basic constructs in a fault tree diagram are gates (conditions) and events (causes leading to failure). Fault tree diagrams are logic block diagrams that display the state of a system (top event) in terms of the states of its components (basic events). An FTD is built top-down in term of events. It begins with the foreseeable, undesirable loss event (or a fault condition). Subsequently, it attempts to determine the specific causes (events) by constructing a logic diagram using a graphic model of the pathways within a system that can lead to the failure. Each cause is further broken down till a basic fault: human, hardware or software is reached. The pathways connect contributory events and conditions, using standard logic symbols (AND, OR, etc.). Example of an FTD – The Root Causes of Hazard to Patients during surgery [1] The two most commonly used gates in a fault tree are the AND and OR gates. OR Gate represent Logical Addition. Even if one of the Inputs to an OR gate is “1” or “TRUE”, then the Output is “1” or “TRUE”. If all the inputs are “0” or “FALSE”, then the Output is “0” or “FALSE” AND Gate represents Logical Multiplication. Even if one of the Inputs to an AND gate is “0” or “FALSE”, then the Output is “0” or “FALSE”. If all the inputs are “1” or “TRUE”, then the Output is “1” or “TRUE” The main purpose of the fault tree analysis is to help identify potential causes of system failures before the failures actually occur. It can also be used to evaluate the probability of the top event using analytical or statistical methods. These calculations involve system quantitative reliability and maintainability information, such as failure probability, failure rate and repair rate. After completing an FTA, efforts can be focused on improving system safety and reliability. Situations where FTD is most effective: It works well to identify possible causal relationships in cases where Output has a Boolean (True/False) relation with inputs, especially in small and medium sized systems where all causes /events can be conceived. It can be used in situations where specific data regarding known failure rates of components is known. It is used to supplement Root Cause analysis on engineered systems, by reviewing assumptions and design decisions made during initial system design. Situations where FTD is least useful: It is not effective in large complex systems as it is difficult to conceive all possible scenarios leading to the top event. The construction of fault trees can become very tedious and are prone to have errors. It does not function well as a Root Cause Analysis tool because FTD does not work well when some of the causes could be Human actions. This is because wide variance of possible human failure rates prevents FTD from providing accurate results. FTD is not very effective when there is event dependency or load sharing i.e. the occurrence of each event (cause) affects the probability of occurrence of the other events. [1] http://asq.org/quality-progress/2002/03/problem-solving/what-is-a-fault-tree-analysis.html

Fault tree analysis is logical analysis of root cause of a fault that has occurred. Least useful - Since it is used to analyse faults that have occurred, it may not unearth any other potent faults in the system. Most useful - When used during design of system to analyse probable faults and their causes (FMEA), and build in the mitigants.

Fault Tree Analysis was first introduced by Bell Laboratories and a popular technique for reliability, maintainability and safety analysis. It is a top-down deductive failure analysis technique used to determine the various combinations of events / causes that could cause undesired events. In simple words it is a technique to decompose a problem and identify situation that may lead to failure. Usage Scenarios: - Understand the logic leading to top event or undesired state - Show compliance with input system safety / reliability requirements - Prioritize contributors to top event - Minimize and optimize resources Steps for performing FTA: - Step 1: Define scope of analysis - Step 2: Define the fault condition and top level failure - Step 3: Identify possible causes for top level failure to occur - Step 4: Consider the relationship between elements to decide logic gates o or (one event can cause failure alone) o and (requires multiple events to result in failure) o exclusive or (output occurs if exactly one event occurs) o priority and (output occurs if events occur in a specific sequence specified by a conditioning event) o inhibit (output occurs if event occurs under an enabling condition specified by a conditioning event) - Step 5: Continue to breakdown each level by repeating Step 3 and 4 - Step 6: Identify probability of the causes - Step 7: Analysis the fault tree Illustration Practical applications - Hospital uses FTA to identify how incorrect prescriptions may be given through combination of events - Airplane parts manufacturer uses FTA to identify critical faults that could lead to hazardous failure - NASA uses FTA for risk and reliability analysis post Challenger accident - Used for process hazard analysis in high hazard process industry - Software industry uses FTA for debugging and software testing Situations wherein FTA is not effective - Complex man-made systems with too many causes for failure - Scarce or insufficient data

When it comes to VA.. definations mention the above questions & answer to these if yes then it is value adding. However needs to define who the customer is ... External/ internal/ Cross-functional department/stake holders ,accordingly the value that they are looking for will also change.this means that the accept the work/ find value in it/they support the idea. Let us see a example of a R& D lab .. team works resurch & develop a new product... In this effort if the resurch is successful then only the value is added? But is the work & efforts that concluded with the knowledge & other findings are they be called wast? No so you need to some times modify the question as per the process.

I believe we have all the three major factors required to arrive at the true value add activity in our processes. It is applicable to all setups. The “to be” process recommended will have the thorough usage of lean tools. Therefore when we say… A value adding activity is one that customer is willing to pay for – It’s the activity which determines the price customer is ready to pay. This helps us to establish the cost involved running the process and the profits we are targeting to rake in, since Price – Cost = Profit. Exceptions could be the cases when the manufacturer/provider wanted to adopt KANO model and try to DELIGHT the customer. The risk here could be manufacturer’s market competitiveness and customer acceptance. A value adding activity is transformational by nature - the activity in a process has to help the product /service reach to the next phase of realization. The time invested in the effort should assist the product/service attain its entirety. Exceptions are based on the assumptions and the knowledge on the transformation/stages. Continuous learning will rock the boat and force us to consider a detour in the journey. A value adding activity is done first time right – the activity of the process should be carried out with utmost quality. The service/product should be free from failures otherwise it will lead to rework. Exceptions are limited here if we assume that the manufacturer/provider has got the right VOC/CTQ. If the requirements are sorted, quality management should be effortless. I think, in the sequences of new-product-design/ innovative product creation/ unique offerings/ one time projects, we need to modify our understanding of VA/ NVA. In an established process/ repetitive sequences, the original three questions seem to work well.