ISO 22000 Resource Center: ISO 31010:2011 Risk Assessment Techniques

Function Analysis

As part of decision making approach, a problem is broken down into its component functions (accounting, marketing, manufacturing, etc.) in which, these functions are further divided into sub-functions and sub-sub functions ... until the function level suitable for solving the problem is reached. Thus, in a mathematical point of view; functional analysis is a methodology that is used to explain the workings of a complex system. The basic idea is that the system is viewed as computing a function (or, more generally, as solving an information processing problem). Functional analysis assumes that such processing can be explained by decomposing this complex function into a set of simpler functions that are computed by an organized system of sub processors. The hope is that when this type of decomposition is performed, the sub functions that are defined will be simpler than the original function, and as a result will be easier to explain. The following risk assessment techniques are based on function analyses and are more complex than previous set of assessment methods.

This is the third article of ISO 31010:2009 risk assessment methods, which continuing to explain 31 risk assessment methods given in the standard. We already discussed the initial 12 methods given in the ISO 31010:2009 standard. This part of the methods is more complex and resource requirements are high requiring expert knowledge on the subject.

13. Failure Mode Effect Analysis

FMEA (Failure modes and effects analysis) and FMECA (Failure modes and effects and criticality analysis) FMEA/FMECA is an inductive reasoning (forward logic) single point of failure analysis and is a core task in reliability engineering, safety engineering and quality engineering. Quality engineering is especially concerned with the “Process” (Manufacturing and Assembly) type of FMEA.

FMEA/FMECA identifies:

All potential failure modes of the various parts of a system (a failure mode is what is observed to fail or to perform incorrectly);

The effects these failures may have on the system;

The mechanisms of failure;

How to avoid the failures, and/or mitigate the effects of the failures on the system.

FMEA/FMECA is a systematic analysis technique that can be used to identify the ways in which components, systems or processes can fail to fulfill their design intent, highlighting:

Design alternatives with high dependability;

Failure modes of systems and processes, and their effects on operational success have been considered;

Human error modes and effects;

A basis for planning testing and maintenance of physical systems;

Improvements in the design of procedures and processes.

FMEA/FMECA also provides qualitative or quantitative information for other types of analysis, such as fault tree analysis, and is used in quality assurance applications. For example, it can produce a semi-quantitative measure of criticality known as the risk priority number (RPN) obtained by multiplying numbers from rating scales (usually between 1 and 10) for (a) consequence of failure, (b) likelihood of failure, (c) ability to detect the problem, where a failure is given a higher priority if it is difficult to detect.

14. Fault Tree Analysis

Fault tree analysis is a deductive procedure used to determine the various combinations of hardware and software failures and human errors that could cause undesired events (referred to as top events) at the system level. The deductive analysis begins with a general conclusion, then attempts to determine the specific causes of the conclusion by constructing a logic diagram called a fault tree. This is also known as taking a top-down approach. It is a technique used in safety engineering and reliability engineering, mostly in the aerospace, nuclear power, chemical and process, pharmaceutical, petrochemical and other high-hazard industries. Fault tree analysis (FTA) can be used to understand how systems can fail, to identify the best ways to reduce risk or to determine or ‘get a feel for’ event rates of a safety accident or a particular system level (functional) failure. It sounds more complicated than it actually is; however, it is a resource hungry method. The analysis starts with undesired event (top event) and determines all the ways in which it could occur, shown graphically in a logical tree diagram.

Fault tree analysis is a time-consuming and costly exercise although it can be invaluable in determining the probability of (undesirable) outcomes.

FTA can be used to:

Understand the logic leading to the top event / undesired state.

Show compliance with the (input) system safety / reliability requirements.

Prioritize the contributors leading to the top event – Creating the Critical Equipment/Parts/Events lists for different importance measures.

Monitor and control the safety performance of the complex system (e.g., is a particular aircraft safe to fly when fuel valve x malfunctions? For how long is it allowed to fly with the valve malfunction?).

Minimize and optimize resources.

Assist in designing a system. The FTA can be used as a design tool that helps to create (output / lower level) requirements.

Function as a diagnostic tool to identify and correct causes of the top event. It can help with the creation of diagnostic manuals / processes.

Fault tree construction

To do a comprehensive FTA, follow these steps:

1. Define the top event

To define the top event the type of failure to be investigated must be identified. This could be whatever the end result of an incident may have been, such as a forklift overturning.

2. Determine all the undesired events in operating a system

Separate this list into groups having common characteristics. Several FTAs may be necessary to study a system completely. Finally, one event should be established representing all events within each group. This event becomes the undesired event to study.

3. Know the system

All available information about the system and its environment should be studied. A job analysis may prove helpful in determining the necessary information.

4. Construct the fault tree

This step is perhaps the simplest because only the few symbols are involved and the actual construction is pretty straightforward.

Principles of construction

The tree must be constructed using the event standard symbols which should be kept simple.

Maintain a logical, uniform, and consistent format from tier to tier.

Use clear, concise titles when writing in the event symbols.

The logic gates used should be restricted to the “and gate” and “or gate” with constraint symbols used only when necessary.

The transfer triangle should be used sparingly if at all.

The more the transfer triangle is used, the more complicated the tree becomes.

The purpose of the tree is to keep the procedure as simple as possible.

5. Validate the tree

This requires allowing a person knowledgeable in the process to review the tree for completeness and accuracy.

6. Evaluate the fault tree

The tree should then be scrutinized for those areas where improvements in the analysis can be made or where there may be an opportunity to utilize alternative procedures or materials to decrease the hazard.

7. Study tradeoffs

In this step, any alternative methods that are implemented should be further evaluated. This will allow evaluators to see any problems that may be related with the new procedure prior to implementation.

8. Consider alternatives and recommend action

This is the last step in the process where corrective action or alternative measures are recommended.

15. Event Tree Analysis

Event tree analysis (ETA) is an analysis technique for identifying and evaluating the sequence of events in a potential accident scenario following the occurrence of an initiating event and a forward, bottom up, logical modeling technique for both success and failure. ETA utilizes a visual logic tree structure known as an event tree (ET). The objective of ETA is to determine whether the initiating event will develop into a serious mishap or if the event is sufficiently controlled by the safety systems and procedures implemented in the system design. An ETA can result in many different possible outcomes from a single initiating event, and it provides the capability to obtain a probability for each outcome. It is arguably less resource intensive than fault tree analysis. ETA can be applied to a wide range of systems including: nuclear power plants, spacecraft, and chemical plants. Once again, if you are managing the quality system of a small enterprise in a relatively ‘low risk’ context, this technique is unlikely to be for you.

ETA Process in 10 steps

Step	Task	Description
1	Define the system.	Examine the system and define the system boundaries, subsystems, and interfaces.
2	Identify the initiating events.	Perform a system assessment or hazard analysis to identify the system hazards and accident scenarios existing within the system design
3	Identify the initiating events.	Refine the hazard analysis to identify the significant IEs in the accident scenarios. IEs include events such as fire, collision, explosion, pipe break, toxic release, etc.
4	Identify the pivotal events.	Identify the safety barriers or countermeasures involved with the particular scenario that are intended to preclude a mishap.
5	Build the event tree diagram.	Construct the logical ETD, starting with the IE, then the PEs, and completing with the outcomes of each path.
6	Obtain the failure event probabilities.	Obtain or compute the failure probabilities for the PEs on the ETD. It may be necessary to use FTs to determine how a PE can fail and to obtain the probability.
7	Identify the outcome risk.	Compute the outcome risk for each path in the ETD.
8	Evaluate the outcome risk.	Evaluate the outcome risk of each path and determine if the risk is acceptable.
9	Recommend corrective action.	If the outcome risk of a path is not acceptable, develop design strategies to change the risk.
10	Document ETA.	Document the entire ETA process on the ETDs. Update for new information as necessary.

16. Cause and Consequence Analysis

Cause-consequence analysis (CCA) is a method for analyzing consequence chains and can be used individually or as a supportive method for other analysis methods. The objective of the analysis is to recognize consequence chains developing from failures or other unwanted events, and to estimate these consequences with their probabilities. The cause-consequence structure of the analysis is formed by combining two different types of tree structures together. To the consequence tree, built from left to right, includes the examined primary event and its follow-up events leading eventually to a failure or some other unwanted event like for example a serious injury of a person.

ISO 31010 describes the Cause and consequence analysis method as: “A combination of fault and event tree analysis that allows inclusion of time delays. Both causes and consequences of an initiating event are considered.”

It starts from a critical event and analyses consequences by means of a combination of “YES/NO” logic gates which represent conditions that may occur or failures of systems designed to mitigate the consequences of the initiating event. The causes of the conditions or failures are analyzed by means of fault trees. Cause-consequence analysis does provide a comprehensive view of the entire system. However, it is more complex than fault tree and event tree analysis, both to construct and in the manner in which dependencies are dealt with during quantification, and so requires more time and resources.

The causes and the probabilities for the realization of the primary event and the follow-up events are defined to cause trees built from top to down. Often cause trees describe failures and are therefore called fault trees. The top level of the cause tree is at the same time a node in the consequence tree describing an event realizing or not. Cause and consequence tree together create a visual consequence chain to help illustrate the relations between causes and consequences that lead into different damages. Consequence tree shows the possible consequence chains and damages of a single event, whereas cause trees (fault trees) describe the causes and probabilities of each consequence.

Cause-consequence analysis includes the following phases:

Recognizing damage chains

Recognizing the primary event (failure or some unwanted event that triggers the damage chain)

Recognizing the follow-up events (events between primary event and final damages)

Final consequence damages (damages coming from different levels of follow-up events)

Defining causes of primary and follow-up events to cause/fault trees

Inputting realization probabilities (failure data) for the causes of primary and follow-up events

Cause-consequence analysis is an effective tool when confirming that the operational safety features have been taken into account already on the design phase. The method can be applied especially when examining complex event chains where there are many possible consequence damages for a single primary event.

The results of cause-consequence analysis include among other things:

Visual and logical description of the consequence chain evolving from the examined primary event

Probabilities for the final consequence damages based on the cause-consequence structure

Cause-consequence relations (causalities) between events

Requirements for the safety features

17. Cause-and-Effect Analysis/Fishbone Diagrams

An effect can have a number of contributory factors which can be grouped in Ishikawa diagrams. Contributory factors are identified often through a brainstorming process (see Part I of this article for more information).

Ishikawa diagrams were popularized by Kaoru Ishikawa in the 1960s, who pioneered quality management processes in the Kawasaki shipyards. The basic concept was first used in the 1920s, and is considered one of the seven basic tools of quality control. Ishikawa diagrams are known as fishbone diagrams because their shape is like the side view of a fish skeleton.

The basic steps in performing a cause-and-effect analysis are as follows:

Establish the effect to be analyzed and place it in a box. The effect may be positive (an objective) or negative (a problem) depending on the circumstances;

Determine the main categories of causes represented by boxes in the Fishbone diagram. Typically, for a system problem, the categories might be people, equipment, environment, processes, etc. However, these are chosen to fit the particular context;

Fill in the possible causes for each major category with branches and sub-branches to describe the relationship between them;