Inductive analysis

An inductive analysis works bottom upwards. A failure event is postulated. The analysis team then determines what effect this failure could have on the overall system. The HAZOP and Event Tree Analysis methods are both inductive. 

Risk can be analyzed in one of two basic ways inductively or deductively, that is either bottom-up or top-down. In a deductive analysis a system failure is postulated. The analyst then works backward to deduce what combinations of events could have occurred for the system failure to have taken place (a detective solving a crime is thinking deductively). Fault tree analysis (FTA), the topic discussed in this section, is deductive. An inductive analysis works in the other direction. A single failure, such as a pmnp stopping or a valve closing at the wrong time, is postulated. The... 

Results from maneuvering simulation proved the optimal shape of designed terminal in Swinousjcie with use of statistical tools for comparison. Energy induction analysis in first point of contact lead to evolution of mooring facilities esp. fendering system. 

A quantitative risk review technique. Cause-consequence analysis is a hlend of fault tree and event tree analysis. This technique combines cause analysis (described by fault trees) and consequence analysis (described by event trees), and hence deductive and inductive analysis is used. The purpose of CCA is to identify chains of events that can result in undesirable consequences. With the probabilities of the various events in the CCA diagram, the probabilities of the various consequences can be calculated, thus establishing the risk level of the system. See also Event Tree Analysis (ETA) Fault Tree Analysis (FTA). 

Another objective of p form induction analysis, besides a form that is most often observed, is to investigate in what distance from the moved fiber the form p is present. The range of structural changes caused by moving fibers has not only a cognitive importance but also a practical dimension for composite manufacture. 

Generally, it is only possible to conduct a functional analysis as a top down approach since the function of a certain hardware element needs to be known first before the cause of failure can be derived. On the other hand, for the failure observation of sheer technical (realized) elements, such as components or structural elements, the failure of elements and also random hardware failures can be inferred from the characteristics of the elements. The failure effects can then be referred to as inductive analysis. However, as a result only the inductive analysis truly addresses the effects of random hardware failure. By a deductive approach only requirements for random hardware-failure could be elaborated so that required failure rates and related diagnostics could be specified. By adequate verifications and tests the fulfillment of given metric requirements could be shown. This will widely indicate a mix of inductive and deductive analysis, whereas the lower level is designed inductively and in the upper level the technical malfiinctional behaviour is described functionally, so that the consistency (see Figs. 4.35 and 4.36 analysis phase) could be assured. 

Basically, the inductive and deductive safety analyses are invoked in the architecture related chapters of ISO 26262, in which the inductive analysis is often demanded for all ASBL requirements and the deductive analysis only for ASIL C and D safety requirements. 

The deductive analysis is in ISO 26262 required in additions to the inductive analysis for ASIL C and D elements. The aim in this case is to have a second independent analysis method, which analyzes the product independently from top-down and bottom-up. Therefore, the combination of the inductive analysis in one step with the deductive analysis is not well accepted. An automatic transformation of one analysis result into another illustration is also not expedient for safety. Therefore an alternative approach based on Reliability Block Diagrams could be considered. 

The inductive analysis would consequently be the verification to see whether a design decision etc. is for example sufficient, appropriate, or adequate. This means that in the first iterations of the deductive analysis only information are available, which is derived from requirements, constraints etc. liom higher abstraction levels. These could also be environmental conditions, systems or operation modes and architecture or design decisions or assumptions. This deductive analysis is required for ASIL C and D in the product development on system level (Part 4 of ISO 26262) and on hardware level (Part 5 of ISO 26262). 

The same correlations can be found for the development of components. In the software it is useful to analyze deductively and functionally even during the development of requirements and therefore determine the key characteristics of the elements, which are necessary for the correct implementation of the function. After software design is finished an inductive analysis should follow. It should proof whether aU systematic failure, which stiU remain in the software, are covered by sufficient measures. 

However, the model-based safety analysis should first be seen as addition for the classic analysis methods. It would be worth considering seeing the model-based safety analysis preferably as deductive analysis and the classic FMEA further on as inductive analysis. Therefore, the systematic approach of consistent system engineering can again be applied from the vehicle level all the way down to the silicon stmcmres and the software development. 

Even so, some hazards may not be readily identifiable, and there are techniques which can be applied to assist in this respect. These include inductive analysis, which predicts failures - failure modes and effects analysis (FMEA) is one of these job safety analysis (JSA) is another. Inductive analysis assumes failure has occurred and then examines ways in which this could have happened by using logic diagrams. This is time-consuming, and therefore expen-... 

A deductive analysis is one that would conclude no more than the data provides. The specific causal factors supporting the conclusion must be identified and established, and then the conclusion will be true. It seems like reverse logic however, the hazard can be validly deduced only from the specific detailed causal factors. Deductive and inductive quaUties have become intangible attributes of HA techniques. An inductive analysis would be used to broadly identify hazards without proven assurance of the causal factors, while a deductive analysis would attempt to find the specific causal factors for identified hazards. An inductive analysis can be thought of as a what-if analysis. The analyst asks, what if this part failed, what are the consequences. A deductive analysis can be thought of as a how-can analysis. The analyst asks, if this event was to occur, how can it happen or what are the causal factors ... 

Deductive analysis tends to be a top-down approach (going from the general to the specific) and an example of this is the FTA methodology. An FMEA is just the reverse, it goes from the specific to the general and is known as an inductive analysis. 

In system safety, inductive analysis tends to be for hazard identification (when the specific root causes are not known or proven), and deductive analysis for root cause identification (when the hazard is known). Obviously, there is a fine line between these definitions because sometimes the root causes are known from the start of an inductive HA. This is why some analysis techniques can actually move in both directions. The PH A is a good example of this. Using the standard PHA worksheet, hazards are identified inductively by asking what if this component fails, and hazards are also identified by deductively asking how can this UE happen. 

Consequence Inductive analysis, which takes a given event (usually a failure) as... 

---