Software hazard analysis fault hazards

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. 

Software hazard analysis (SWHA) is a system safety analytical technique whose primary function is to systematically evaluate any potential faults in operating system and applications software requirements, codes, and programs as they may affect overall system operation. The purpose of the SWHA is to ensure that safety specifications and related operational requirements are accurately and consistently translated into computer software programs. In this regard, the analysis will verify that specific operational safety criteria, such as failsafe or fail-passive, have been properly assimilated into operational software. The SWHA will also identify and analyze those computer software programs, routines, or functions that may have direct control over or indirect influence on the safe operation of a given system. Also, in the operation of the computer software command function, there is a potential that the actual coded software may cause identified hazardous conditions to occur or inhibit a desired function, thereby creating additional hazard potential. 

Software Hazard Analysis A system safety analytical technique whose function is to evaluate potential faults in both operating system and applications software requirements, codes, and programs as they may effect overall system operation. 

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 ... 

Fault trees are commonly used in safety critical industries such as aerospace. Their power is in being able to communicate complex failures in a simple graphical format which is relatively easy to learn. They can be applied to either potential failures or retrospectively in investigating actual failures. FTA has subtle limitations however especially when one needs to systematically identify aU possible causes of a particular hazard - for this, an alternative technique needs to supplement the analysis. Fault trees are also notoriously difficult to apply to complex software. 

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. 

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. 

Software Fault Hazard Analysis Similar in concept and structure to the system hazard analysis (SHA), which is conducted on system hardware, the software fault hazard analysis will analyze and evaluate a computer software program to identify critical areas in the programming that may contribute to or directly cause a hazard risk. Such risks may be due to an undetected hardware failure or incorrect inputs into the operation of the system software. The software FHA will also attempt to uncover any probable errors that can possible develop in the software after system activation. 

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. 

Now, efforts have been made to develop suitable software for various methods of plant (process) hazard analysis (PHA). There are a number of papers available where through suitable software it is possible not only to automate one PHA method but to integrate several automated PHA methods such as event tree/fault tree (Chapter V) with HAZOP or HAZOP with FMEA, which will be discussed in the next clause in this chapter. 

Complementary to the hazard mitigating functions that are added in response to specific risks identified through the hazard analysis for the computer system, features such as watchdog timers, program sequence checking, reinitialization of variables and other fault detection mechanisms constitute good practice. Because of the need for simplicity of the system, these features are added only to the extent that they do not make the software unnecessarily more complex. 

Such an analysis needs to include not only the obvious hazards, but also the more elusive contingent hazards which may arise due to unusual combinations of circumstances. If the hazards cannot be seen and identified in this way then clearly their potential effect cannot be removed or minimized. As the complexity of the system and the degree of hazard increases, formal techniques of hazard analysis become essential. The principles of these techniques may be based on inductive (i.e. bottom-up) or deductive (i.e. top-down) reasoning principles which will be famihar to software engineers from their use in software design and testing. Briefly, fault mode analysis (FMA) begins at the component level. The various possible modes of failure are identified and the effects of these failures... 

Chapters 5 through 9 describe the different safety analysis tools available. Hazard Analysis, H AZOF, What-If, Fault Tree Analysis, Failure Modes, and Effects Analysis, Human Factors, Software Safety, and other safety tools are described with realistic worked examples. The chapters detail how to use them, give examples, describe common mistakes in using them, and also provide best practices and tips of how to apply them judiciously. 

One important point is doing the Software Safety Analysis as part of the overall System Safety Assessment, and not as an independent task. During the FHA critical system functions and system hazards are identified and subsequently broken down to the hardware and software level. Based on the software architecture, potential software faults which might contribute to the system hazards are detected during the Software Safety Analysis. The results of the Software Safety Analysis must be considered at the system level as well. Thus, the Software Safety Analysis is an integrated element of the System Safety Assessment. 

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... 

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. 

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. 

---