|

Safety Home

|

Solutions

|

Clients

|

Support

|

Hazard Management in Practice

Gabriele Schedl; Frequentis AG; Vienna, Austria Werner Winkelbauer; Frequentis AG, Vienna, Austria

(Last Revision: Nov. 16, 2010)

     

The key point of every safety process is hazard identification and management. This is required by many related standards and shall be performed for every project. It's often a challenge to find all possible hazards in advance but it's possibly an even bigger challenge to manage all hazards over a wide range of products and projects. It is therefore necessary to combine the results of several safety assessment activities with field experience of already existing systems. This paper describes in brief the development and the current state of an organization wide hazard management and tracking system, which al1ows for efficient hazard handling. The main goal is to act well in advance instead of reacting to problems in operations, which is both a safety benefit and a commercial one, as we all know about the cost explosion of problem-solving over lifecycle time. The hazard process defines the 'lifecycle' of a hazard: the phases, tasks and responsibilities from its detection to its closing. The gained knowledge about hazards is directly transferred to new projects where they might apply and possibly contribute to accidents.

 

The key to system safety is the management of hazards. To effectively manage hazards, one must understand hazard theory and the identification of hazards. Hazard analysis provides the basic foundation for system safety. It is performed to identify hazards, their effects and causal factors. It is further used to determine system risk, the significance of hazards and to establish design measures that will eliminate or mitigate the identified hazards and their associated risk. Hazard Definition: According to MIL-STD-882D (Department of Defense 2000), a Hazard is 'Any real or potential condition that can cause injury, illness, or death to personnel; damage to or loss of a system, equipment or property; or damage to the environment.' A less formal, but helpful definition might be: 'A Hazard is an accident, waiting to happen', for example oil on a staircase. A further, practical definition is: 'A Hazard is a physical condition at the system boundary of the regarded system which could lead to an accident'. Herein it's clearly stated that a hazard is defined at the system boundary. Figure 1 provides the connection between system functions, the possible failure modes and their causal factors within the considered system and several hazards at the system boundary, which then can lead to possible accidents.

 

 

Core System Safety Process: Several standards define different safety lifecycle models, whereas the core of them is always similar. As soon as hazards are identified, their risk has to be assessed and hazard mitigation methods have to be established to mitigate the risk as low as necessary. These mitigation methods are brought into the system design via safety requirements. Hazards are continually tracked until they can be closed.

 

The core system safety process can therefore be reduced to: Hazard Identification -> Hazard Risk Assessment -> Hazard Risk Control -> Hazard Risk Verification-> Hazard Identification ... (Ericson 2005). This is a closed-loop process where Hazards are identified and tracked until acceptable closure action is implemented and verified.

 

The relationship between the System Development Lifecycle and the Safety Achievement Process is illustrated in Figure 2. The first row represents a generic and simplified version of the development process. In the second row, the main phases of the safety process are shown, which start with the Safety Process Initialization and continue with the Functional Hazard Assessment (FHA), the Preliminary System Safety Assessment (PSSA) and the System Safety Assessment (SSA). Below each main phase, the primary question to be answered during this phase is shown.

 

 

The first step in the safety process comprises identification of safety relevant functions within the domain/environment in which the system will be operated.

 

These functions are the basis for the Functional Hazard Assessment (FHA), for the identification of possible hazards. In workshops with experts - to combine technical, domain and safety know-how - various techniques are applied. This includes brainstorming, use of historical data and functional failure modes and effects analysis to identify possible failure modes, their operational effects and the respective severity of the worst credible outcome. Based on the safety-relevant failure modes, potential hazards are determined and respective risks are allocated according to the risk matrix. The FHA leads to derivation of top level hazards.

 

Derived safety requirements are defined to reduce those risks which are not in the acceptable area of the matrix and to address safety issues emerging during discussions in the workshops. These safety requirements form a mandatory part of the system requirements and have to be fulfilled and verified accordingly.

 

Points of Challenge: It is often the case that a system safety program, and therefore hazard management, is required for a specific project. A typical requirement is given in MIL-STD-882D: 'The contractor shall perform and document a system hazard analysis to identify hazards and assess the risk of the total system design, including software, and specifically of the subsystem interfaces.' But it would be very inefficient to perform such analyses purely on a project by project basis. If we consider each project as a stand-alone, we would miss many important results from former analyses and experience based data from similar projects.

 

Adequate fulfillment of such a safety process requirement is a crucial point for system safety. It is often a big challenge to find 'all' possible hazards. How can we be sure to have a complete hazard list as input for further activities? And how can we manage the different results of all performed safety analyses to have a set of hazards as an input for the next project? Detailed domain know-how is necessary to perform these tasks and to estimate the operational risk for each hazard.

 

A further problem is the management of hazards in already fielded systems, especially if new hazards arise after handover of the system from the supplier to the user. It is definitely a challenge to manage hazards over the whole lifecycle.

 

For more information on how your company can quickly gain these advantages, please email one of our Senior Consultants to find out more

Printer firendly Version

Next Article  - SMS Overview