(a) Explain the methodology of HAZOP.

HAZOP is a team based assessment which involves the use of a multidisciplinary team of specialists. A team leader is selected to guide the team and ensure that each discipline can make its contribution. A typical team would include a safety specialist, engineering specialists and operational staff; other specialists could be utilised depending on the operation under assessment, for example building and services engineers. HAZOP guide words are key supporting elements in the execution of a HAZOP analysis:

The identification of deviations from the design intent is achieved by a questioning process using predetermined “guide words”. The role of the guide word is to stimulate imaginative thinking, to focus the study and elicit ideas and discussion.

In addition to guide words, other key words used in HAZOP are “study nodes”, “intention”, ”deviations”, ”causes” and “consequences”.

Study nodes: the locations on the plant or services at which the process parameters are investigated for deviation from the design intent.

Intention: describes how the plant is designed to operate.

Deviation: the departures from the intention.

Cause: the reasons why deviations may occur.

Consequences: the results of the deviations. Example - HAZOP guide words, meanings and applications:

Guide word Meaning Parameter Deviation No Negation of the design intent Flow No flow Less Quantitative decrease Temperature Low temperature Reverse Logical opposite of the intent Open Close

The HAZOP analysis process is executed in four phases as illustrated below:

An example to illustrate the process could be the delivery of liquid propane to a fixed tank currently fitted with a pressure relief valve and a liquid level gauge. Table 3 indicates how HAZOP could be applied to this simple situation.

HAZOP is a powerful assessment tool detecting deviations through a methodical approach using specialists guided and aided by a formal system. Although formal, the approach encourages free thinking amongst the team members and the freedom to develop new guide words means that the approach can be used in all situations. The approach requires a team to be gathered and will fail if specialists with the appropriate skills and expertise are not available.

(b) Explain the methodology of FTA (Fault Tree Analysis)

The fault tree is a logic diagram based on the principle of multi-causality, which traces all branches of events which could contribute to an accident or failure. It uses sets of symbols, labels and identifiers, as shown below.

Logic Symbol Graphic Representation Description

OR gate

The output event occurs if at least one of the input events occurs.

AND gate

The output event occurs if all input events occur.

Logic Symbol Graphic Representation Description

BASIC Event

A basic initiating fault (or failure event). It requires no further

development into more basic faults or failures.

INTERMEDIATE EVENT

An event that is normally expected to occur resulting from the

combination of more basic faults acting through logic gates.

UNDEVELOPED EVENT

An event not examined further because information is unavailable

or because its consequence is insignificant

The steps of a fault tree analysis: There are nine steps involved in implementing a fault tree analysis.

1. Identify the top event or incident 2. Decide on the level of resolution 3. Define the analysis boundary conditions

4. Define the system’s physical boundaries 5. Define the system’s initial conditions 6. Construct the fault tree 7. Determine the minimal fault tree 8. Rank the elements 9. Quantify the fault tree

A fault tree diagram is drawn from the top down. The starting point is the undesired event of interest (called the ‘top event’ because it gets placed at the top of the diagram). Then it is required to logically work out (and draw) the immediate contributory fault conditions leading to that event. These may each in turn be caused by other faults and so on. It could be endless (though, in fact, it should naturally have to stop when it gets as far as primary failures). The trickiest part of the whole thing is actually getting the sequence of failure dependencies worked out in the first place. Let’s consider a simple example to illustrate the point.

The above figure shows a simple fault tree for a fire. For the fire to occur there needs to be: • Fuel. • Oxygen. • An ignition source. Notice that an AND gate is used here to connect them because all three need to be present at the same time to allow the top event. The example shows that, in this scenario, there happen to be three possible sources of fuel and three possible sources of ignition. An OR situation applies in each case, because it would only need one of these to be present. The example also shows a single source of oxygen (e.g. the atmosphere). In order to prevent the loss taking place, the diagram is examined for AND gates. This is because the loss can be prevented if just one of the conditions is prevented.

As a pure illustration, the above simple fault tree diagram will be quantified to show the calculation steps.

Essentially: • Add the probabilities which sit below an OR gate • Multiply the probabilities which sit below an AND gate So, in this example, combining probabilities upwards to the next level gives: Probability of FUEL being present = 0.1 + 0.02 + 0.09 = 0.21 Probability of OXYGEN being present = 1 Probability of IGNITION being present = 0.2 + 0.05 + 0.1 = 0.35 Now showing the tree diagram with the calculation

Now calculating the probability of the top event. These faults are below an AND gate, so we multiply the probabilities, giving 0.21 x 1 x 0.35 = 0.0735. The top of the fully quantified fault tree then looks like this:

(c) Explain the methodology of ETA (Event Tree Analysis)

 

Figure 1

Figure 1 shows an overview of the basic ETA process and summarizes the important relationships involved in the ETA process. The ETA process involves utilizing detailed design information to develop event tree diagrams (ETDs) for specific initiating event (IEs). In order to develop the ETD, the analyst must have first established the accident scenarios, IEs, and pivotal events of interest. Once the ETD is constructed, failure frequency data can be applied to the failure events in the diagram. Usually the failure frequency data is derived from FTA of the failure event. Since 1 = Probability of success + Probability of failure, the probability of success can be derived from the probability of failure calculation. The probability for a particular outcome is computed by multiplying the event probabilities in the path.

Table 1

 

Table 1 lists and describes the basic steps of the ETA process, which involves performing a detailed analysis of all the design safety features involved in a chain of events that can result from the initiating event to the final outcome.  

 

Figure 2 Figure 2 shows the event tree concept. The ETA is based on binary logic in which an event either has or has not happened or a component has or has not failed. It is valuable in analyzing the consequences arising from a failure or undesired event. An ET begins with an IE, such as a component failure, increase in temperature/pressure, or a release of a hazardous substance that can lead to an accident. The consequences of the event are followed through a series of possible paths. Each path is assigned a probability of occurrence and the probability of the various possible outcomes can be calculated. The ETA begins with the identified IE listed at the left side of the diagram in Figure 2. All safety design methods or countermeasures are then listed at the top of the diagram as contributing events. Each safety design method is evaluated for the contributing event: (a) operates successfully and (b) fails to operate. The resulting diagram combines all of the various success/failure event combinations and fans out to the right in a sideways tree structure. Each success/failure event can be assigned a probability of occurrence, and the final outcome probability is the product of the event probabilities along a particular path. Note that the final outcomes can range from safe to catastrophic, depending upon the chain of events.

Figure 3

An example of ET structure with quantitative calculations is displayed in Figure 3. The ET model logically combines all of the system design safety countermeasure methods intended to prevent the IE from resulting in an incident/accident/failure/damage. A side effect of the analysis is that many different outcomes can be discovered and evaluated. The following diagram shows a quantified event tree for the action following a fire on a conveyor system.

The only outcome resulting in control of the event is where the sensor, valve and water spray operate (the example is a little contrived but serves to demonstrate the principles). Notice how the frequencies of the outcomes are calculated. Notice also that the sum of all the outcome frequencies adds up to 2 in this case, i.e. the frequency of the initiating event (the conveyer belt fire). The event tree could be used to check that there were adequate fire detection, warning and extinguishing systems.

(d) Explain the methodology of FMEA (Failure Mode and Effect Analysis)

The basic steps for performing an Failure Mode and Effects Analysis (FMEA) include: Assemble the team. Establish the ground rules. Gather and review relevant information. Identify the item(s) or process(es) to be analyzed. Identify the function(s), failure(s), effect(s), cause(s) and control(s) for each item or

process to be analyzed. Evaluate the risk associated with the issues identified by the analysis. Prioritize and assign corrective actions. Perform corrective actions and re-evaluate risk. Distribute, review and update the analysis as appropriate.

A typical failure modes and effects analysis incorporates some method to evaluate the risk associated with the potential problems identified through the analysis. In the FMEA context, the method is through Risk Priority Numbers. To use the Risk Priority Number (RPN) method to assess risk, the analysis team must: Rate the severity of each effect of failure. Rate the likelihood of occurrence for each cause of failure. Rate the likelihood of prior detection for each cause of failure (i.e. the likelihood of

detecting the problem before it reaches the end user or customer). Calculate the RPN by obtaining the product of the three ratings:

RPN = Severity x Occurrence x Detection

Description Low Number Low Number High Number

Severity

Severity ranking encompasses what is important to the industry, company or

customers (e.g., safety standards, environment, legal, production continuity, scrap,

loss of business, damaged reputation)

Low impact High impact

Occurence Rank the probability of a failure occuring during the expected lifetime of the product or

service

Not likely to

occur Inevitable

Detection Rank the probability of the problem being detected and acted upon before it has

happened

Very likely to be

detected

Not likely to be

detected

The RPN can then be used to compare issues within the analysis and to prioritize problems for corrective action. The sample shown in Figure 1 can be used as an example when learning how the FMEA works. The team in this case is analyzing the tire component of a car. Figure 1: FMEA for Car Tire

Function or

Process Step

Failure

Type Potential Impact SEV

Potential

Causes OCC Detection Mode DET RPN

Briefly outline

function, step

or item being

analyzed

Describe

what has

gone

wrong

What is the impact

on the key output

variables or internal

requirements?

How severe is

the effect to

the

customer?

What causes

the key input

to go wrong?

How

frequently is

this likely to

occur?

What are the

existing controls that

either prevent the

failure from occuring

or detect it should it

occur?

How

easy is it

to

detect?

Risk

priority

number

Tire function:

support

weight of car,

traction,

comfort

Flat tire

Stops car journey,

driver and

passengers stranded

10 Puncture 2

Tire checks before

journey. While

driving, steering

pulls to one side,

excess noise

3 60

Recommended Actions Responsibility Target Date Action Taken SEV OCC DET RPN

What are the actions for

reducing the occurence of the

cause or improving the

detection?

Who is responsible for

the recommended

action?

What is the target

date for the

recommended action?

What were the actions

implemented? Now recalculate

the RPN to see if the action has

reduced the risk.

Carry spare tire and

appropriate tools to change tireCar owner

From immediate

effect

Spare tire and appropriate tools

permantly carried in trunk 4 2 3 24

In the FMEA in Figure 1, for example, a flat tire severely affects the customer driving the car (rating of 10), but has a low level of occurrence (2) and can be detected fairly easily (3). Therefore, the RPN for this failure mode is 10 x 2 x 3 = 60. The Failure Modes, Effects Analysis (FMEA) procedure is a tool that has been adapted in many different ways for many different purposes. It can contribute to improved designs for

products and processes, resulting in higher reliability, better quality, increased safety, enhanced customer satisfaction and reduced costs. The tool can also be used to establish and optimize maintenance plans for repairable systems and/or contribute to control plans and other quality assurance procedures. It provides a knowledge base of failure mode and corrective action information that can be used as a resource in future troubleshooting efforts and as a training tool for new engineers. In addition, an FMEA is often required to comply with safety and quality requirements, such as ISO 9001, QS 9000, ISO/TS 16949, Six Sigma, FDA Good Manufacturing Practices (GMPs), Process Safety Management Act (PSM), etc.