Fault or Functional Hazard Analysis

Vat Fault Hazard Analysis (FHA also referred to as the Functional Hazard Analysis, method follows an inductive reasoning approach to problem solving in that the analysis concentrates primarily on the specific and moves toward the general (TAI 1989). The FHA is an expansion of the FMEA (Stephenson 1991). As demonstrated in the previous chapter, the FMEA is concerned with the critical examination and documentation of the possible ways in which a system component, circuit, or piece of hardware may fail and that failure s effect upon the performance of that element. The FHA takes this evaluation a step further by determining the effect of such failures upon the system, the subsystem, or personnel. In fact, when an FMEA has already been completed for a given system and information on the adverse safety effect of component or human failures is desired for that system, the safety engineer can often utilize the data from the FMEA as an input to the FHA. 

Although it can be performed later in the product development cycle than the PHA, the maximum benefit fi om an FHA is obtained if it is properly performed in the early stages of system development. The minimum requirements of an FHA are as follows  

Basic Guide to System Safety, Third Edition. Jeffrey W. VincoU. 

The FHA may derive hazard control criteria or even performance criteria where none previously existed. It may also establish the exact applicability of mandated criteria (standards and regulations). However, because of its ability to determine actual applicability of specific criteria as well as verify that maximum allowable probabilities are correct, the FHA is often useful in the analysis of a fully operational system as well. Like the SHA and SSHA, the FHA will examine small eomponents or events to determine potential impacts on safety and reliability of the system or subsystem. The FHA requires a detailed evaluation of the system or subsystem and examines 

More simply stated, the properly performed FHA will attempt to answer at least the following two questions with respect to system or subsystem components (Larson 

---

Fault (or Functional) Hazard Analysis (FHA) Management Oversight and Risk Tree (MORT) Energy Trace and Barrier Analysis (ETBA) Sneak Circuit Analysis (SCA)... 

Fault (or Functional) Hazard Analysis A system safety analysis method, usually an extension of the failure mode and effect analysis that evaluates the overall effect of functional failures on other subsystems or the overall system itself. 

Model Based Safety Assessment aims at supporting the Preliminary System Safety Assessment (PSSA) [8]. Before the PSSA is performed, the Functional Hazard Analysis identifies the Failure Conditions (e.g. safety critical situations of the system) and assesses their severity on a scale going from No Safety Effect (NSE) to Catastrophic (CAT). Then, during the Preliminary System Safety Assessment, safety models (or alternatively fault-trees) axe built and analysed. A safety model describes formally in which node a fault occurs and how this fault propagates inside the system architecture in order to cause a Failure Condition. 

This approach is based on a safety analysis, often used for safety critical systems. The safety analysis performed at each stage of the system development is intended to identify all possible hazards with their relevant causes. Traditional safety analysis methods include, e.g. Functional Hazard Analysis (FHA) [1], Failure Mode and Effect Analysis (FMEA) [2] and Fault Tree Analysis (FTA). FMEA is a bottom-up method since it starts with the failure of a component or subsystem and then looks at its effect on the overall system. First, it lists all the components comprising a system and their associated failure modes. Then, the effects on other components or subsystems are evaluated and listed along with the consequence on the system for each component s failure modes. FTA, in particular, is a deductive method to analyze system design and robustness. Within this approach we can determine how a system failure can occur. It also allows us to propose countermeasures with a higher coverage or having wider dimension. 

Earlier method of identifying hazards involved a procedure consisting of asking questions such as what if This approach consists of questioning the proper function at every stage of the process, along with consequences or the remedial features. A checklist for the simplified process hazard analysis by the what if method is shown in Table 3.3. Although this method is an old method of hazard analysis compared with other methods such as hazop or fault tree analysis it has proven to be quite useful. 

A systems hazards analysis (SHA) is a systematic and comprehensive search for and evaluation of all significant failure modes of facility systems components that can be identified by an experienced team. The hazards assessment often includes failure modes and effects analysis, fault tree analysis, event tree analysis, and hazards and operability studies. Generally, the SHA does not include external factors (e.g., natural disasters) or an integrated assessment of systems interactions. However, the tools of SHA are valuable for examining the causes and the effects of chemical events. They provide the basis for the integrated analysis known as quantitative risk assessment. For an example SHA see the TOCDF Functional Analysis Workbook (U.S. Army, 1993-1995). 

The enterprise analyzes and prioritizes potential functional failure modes to define failure effects and identify the need for fault detection and recovery fimctions. Functional reliability models are established to support the analysis of system effectiveness for each operational scenario. Failures, which represent significant safety, performance, or environmental hazards, are modeled to completely understand system impacts. 

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

For this paper we treat hazard assessment as a combination of two interrelated concepts hazard identification, in which the possible hazardous events at the system boundary are discovered, and hazard analysis, in which the likelihood, consequences and severity of the events are determined. The hazard identification process is based on a model of the way in which parts of a system may deviate fi om their intended behaviour. Examples of such analysis include Hazard and Operability Studies (HAZOP, Kletz 1992), Fault Propagation and Transformation Calculus (Wallace 2005), Function Failure Analysis (SAE 1996) and Failure Modes and Effects Analysis (Villemeur 1992). Some analysis approaches start with possible deviations and determine likely undesired outcomes (so-called inductive approaches) while others start with a particular unwanted event and try to determine possible causes (so-called deductive approaches). The overall goal may be safety analysis, to assess the safety of a proposed system (a design, a model or an actual product) or accident analysis, to determine the likely causes of an incident that has occurred. 

Also, a subsystem hazard analysis (SSHA) examines each major subsystem (such as shown on the functional organizational tree in Figure 5.3) and identifies specific hazards and safety concerns including failures, faults, processes, or procedures and human errors. An SSHA also should address hazard controls and how those controls are verified. 

CONSTRUCTING THE FAULT TREE. Fault tree construction begins at the top event and proceeds, level by level, until all fault events have been traced to their basic contributing events or basic events. The analysis starts with a review of system requirements, function, design, environment, and other factors to determine the conditions, events, and failures that could contribute to an occurrence of the undesired top event. The top event is then defined in terms of sub-top events, i.e., events that describe the specific "whens and wheres" of the hazard in the top event. Next, the analysts examine the sub-top events and determine the immediate, necessary, and sufficient causes that result in each of these events. Normally, these are not basic causes, but are intermediate faults that require further development. For each intermediate fault, the causes are determined and shown on the fault tree with the appropriate logic gate. The analysts follow this process until all intermediate faults have... 

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 approach used for the estimation of loss of life in floods shows considerable resemblance to the approach that is used in the Dutch major hazards policy. In both cases, the probability of a critical event (loss of containment or flood) is estimated using fault tree analysis, after which the physical effects associated with that critical event are considered (using e.g. dispersion or flood propagation models) and related to mortality estimates (using dose-response functions or flood mortality functions). But while the potential for evacuation is often limited when it comes to explosions or toxic releases, it could be significant when it comes to floods. 

Normal Event As pertains to fault tree analysis (FTA) and/or the Management Oversight and Risk Tree (MORT), an event which occurs as a normal function in system operation that may or may not present a risk of hazard to that system. Represented graphically by a house shape in FTA and a scroll shape in MORT. 

In addition, it is the author s recommendation to perform at least a qualitative (or just illustrative) Fault Tree Analysis [10] going down the hazards, in order to check with all relevant experts how they could arise (based on the functional system architecture) and to show where reference is made to redundant elements, which require special considerations to prove their independence. ASIL decomposition can be better justified using a Fault Tree. 

---