Software fault tree analysis

Software System Hazard Analysis This type of analysis is conducted similar to a hardware system hazard analysis (SHA), analyzing software functional processing steps to determine whether they may have any particular hazardous effect on the system. The analysis utilizes a hazard-risk index to illustrate the severity of each potential failure. The main advantage to this method is in its ability to positively identify safety-critical hardware and software functions as well as consider the effect of the human element in system software operations. The results of the software SHA, which identifies single-point failures or errors within a system, can often be used to assist in the development of a software fault tree analysis or, to some degree, a system FMEA. However, as with the other various SWHA techniques briefly described above, this method is also time-consuming and costly to perform. 

Dehlinger, J., Lutz, R. PLFaultCAT A Product-Line Software Fault Tree Analysis Tool. Automated Software Engineering 13(1), 169-193 (2006)... 

Temporal (relationship) gate in software fault tree analysis. 

Soft Tree Also known as Software Fault Tree Analysis, a system safety technique used to evaluate a single loss event and/or the effect of simultaneous failures with a software system on that single loss, or top event. 

There are numerous software safety tools on the market, some quite good. And you can even take some of our current tools and use them for analyzing software systems. The most common ones are software hazard analysis, software fault tree analysis, and software FMECA. These are good starts, but insufficient to do the job completely. However, before you can attack the problem of software safety, a few facts should be stated first ... 

Software fault tree analysis (also called soft tree analysis)... 

It has become quite popular to integrate timed Petri-Nets with software fault tree analysis. You can use the Petri-Net to describe the system architecture and then switch to software fault trees to describe the hazards in the system and the events that lead to that top event and keep switching back and forth to analyze the software safety of the system. 

SFTA (Software Fault Tree Analysis) [1] is a static analysis technique which is primarily used to discover all potential faults such as faulty inputs or software bugs that could occur in software. SFTA has also been used for verifying software... 

Phuh Westerheide, Quirk, Taylor and Voges, Software fault tree analysis in Verification and Validation of Real time software ed W.J.Quick Springer Verlag 1985. 

At the specification phase we intend to concentrate on the benefits of a formal specification for safety analysis proofs. Proof is currently a very expensive activity and so careful analysis of which requirements should be proven is necessary. We intend to use software fault tree analysis to help identify the key safety requirements that should be proven. 

A more careful comparison has also been made. JAXA (the Japanese Space Agency) and MIT engineers compared the use of STPA on a JAXA unmanned spacecraft (HTV) to transfer cargo to the International Space Station (ISS). Because human life is potentially involved (one hazard is collision with the International Space Station), rigorous NASA hazard analysis standards using fault trees and other analyses had been employed and reviewed by NASA. In an STPA analysis of the HTV used in an evaluation of the new technique for potential use at JAXA, all of the hazard causal factors identified by the fault tree analysis were identified also by STPA [88]. As with the BMDS comparison, additional causal factors were identified by STPA alone. These additional causal factors again involved those related to more sophisticated types of errors beyond simple component failures and those related to software and human errors. 

Dugan, X, Sullivan, K., Coppit, D. (2000). Developing a low-cost high-quality software tool for dynamic fault-tree analysis. IEEE Trans, on Rel. 49-59( ), 49ff. 

Instrumentation and Control (I C) systems are very often subject of probabilistic examination either within separate structural reliability analysis or Probabilistic Safety Assessment of a whole technological complex (e.g. Nuclear Power Plant). Use of programmable components in the design of these systems represents a challenge and utilizes the methods, which have been developed for components with a different behaviour. The typical method used for above mentioned examination is Fault Tree Analysis (FTA) (Vesely et al., 1981). The way of software faults modelling within Fault Trees vary a lot between particular models and there is no generally accepted modelling technique. 

The experience is that for I C systems approval the probabilistic goals are set and needs to be fulfilled. Reasonable consideration of software reliabihty is desired. This could lead to sometimes senseless way of involvement of software faults into Fault Trees and their quantification. The sensitivity analysis of system tolerance to software faults and their common cause aspects is much more meaningful and could reveal the weak points of the I C design. Even if this analysis is mostly quahtative unless we have applicable methodology to estimate particular basic events prob-abftistic parameters, the Fault Tree Analysis Method represents a good base to demonstrate a sound fault tolerant design. 

The fault tree analysis describes a hazardous top event and the basic event which maybe leads to such a top event in a top-down method. The methods are dev-ided in static fault tree analysis and dynamic fault tree analysis. The static fault tree analysis describes the system top event in static way. In further steps it is not possible to describe functional system redundancy with this static Fault Tree Analysis (FTA). Especially if cold and hot spares are integrated or if triggers are used, the static fault tree analysis is unsatisfying these requirements. Therefore it is more suitable to use the extended Dynamic Fault Tree Analysis. The DIFTree (Dynamic Innovative Fault Tree) software package could be a helpful tool for the system development... 

The recommended techniques for preliminary hazard analysis are energy trace and barrier analysis (ETBA) and failure modes and effects analysis (FMEA). Recommended techniques for system and subsystem hazard analyses are FMEA, fault tree analysis (FTA), common cause analysis, sneak circuit analysis (for electrical, electronic, and some hydraulic or pneumatic circuits) and, of course, software hazard analysis for software. 

Based on the results of the PHA, recommendations made by 30% review boards, and guidance provided in the system safety program plan, detailed hazard analyses are made of specified (critical) subsystems. The techniques for these SSHAs are as outlined in the system safety program plan or as selected by the SSWG. Failure modes and effects analysis (FMEA) and/or fault tree analysis (FTA) are generally the techniques of choice. Software hazard analysis, common cause analysis, and/or sneak circuit analysis may also be appropriate. 

Unfortunately, the state of the art in software hazard analysis appears to be woefully lagging. Even though traditional hazard analysis techniques like fault tree analysis and tailored versions of operating hazard analysis may be applied to the evaluation of software, validated, specific methods of software hazard analysis appear lacking. 

Much of the functional safety practitioner s work involves random hardware failure modes and failure rates as a way of providing quantitative information to support claims that a SIL specification has been met. This is accompanied by rehabihty engineering calculations, as described in detail in lEC 61508. Standard software packages have eased the calculation burden, particularly with fault tree analysis and probabihty of failure estimates. 

Software Fault Tree ( Soft Trees ) The soft tree technique is used to determine what software event, failure, or combination of each will result in a real or hypothetically loss event (a top event). This top-down analytical approach, which assumes a problem and then evaluates affecting conditions backward to determine causal factors, also takes into consideration any influencing environmental factors. It is concerned primarily with the analysis of any hardware-software interfaces that deal directly with the operation of mechanical components. 

Fault Tree Analysis (FTA) is a well known and widely used safety tool, implementing a deductive, top down approach. It starts with a top level hazard, which has to be known in advance and "works the way down" through all causal factors of this hazard, combined with Boolean Logic (mainly AND and OR gates). It can consider hardware, software and human errors and identifies both single and multiple points of failure. Both a quantitative and qualitative analysis is possible. 

FIGURE 21.31 Software fault tree. The solid lines define the requirements definition and analysis phase fault tree. The requirements definition and analysis phase and coding phase fault tree is obtained by adding solid and dashed contributions. 

---