Marvin Rausand - Risk Assessment

A lot of information about the study object is required, in particular for detailed analyses. Information sources of interest may include (e.g. see IAEA 2002):

System layout drawings, including the relation to other systems and assets.

System flow, logic, and control diagrams.

Descriptions of normal and possible abnormal operations of the study object.

Inventories of hazardous materials.

Operation procedures and operator training material.

Testing and maintenance procedures.

Emergency procedures.

Previous risk assessments of the same or similar systems

Descriptions of engineered safety systems (barriers) and safety support systems, including reliability assessments.

Description of previous hazardous events and accidents in the study object.

Feedback from experience with similar systems.

Environmental impact assessments (if relevant).

The document control system fills an important role in keeping track of all the documentation that is used as input to the risk assessment. In system development projects, the design is developing continuously, and it is important to know which versions of documents have been used as basis for the analysis.

When the study team has been established, it is important that the team members have access to all relevant information and documentation so they can become familiar with the study object and its operating context. As part of the familiarization, it may be necessary to revisit the previous substep:

More information may be required because the delimitations of the study object are extended or because the information is incomplete.

Details may be insufficient and have to be supplemented.

There may be discrepancies in the documentation.

Part of the information may be unclear and open for interpretation and needs to be discussed with designers/operators.

A number of analytical methods have been developed for risk analysis. Many factors influence the choice of methods, some of which are as aforementioned:

In general, we need to choose a method that gives the answers required for the decisions to be made. This means that we need to understand the problem and the decisions to choose method.

If several alternative methods are available, we will usually choose the method that requires least work.

The acceptance criteria may determine which methods can be used. If quantitative criteria are given, quantitative methods must be used. If we do not have quantitative criteria, qualitative methods usually suffice.

Methods have been developed for special types of systems and for special types of problems. We, therefore, need to consider the system and problem type before choosing which method to apply.

If limited information about the study object is available, it may be more relevant to choose a coarse method than a detailed method. In early project phases, coarse methods are therefore often used, switching to more detailed methods later in the project.

Consider the availability of data before choosing method. If no or little quantitative input data are available, performing a quantitative analysis may not be possible.

Usually, there are time constraints on when the results need to be ready. This may place constraints on which method to choose.

The size and how complicated the study object is, will influence the choice of method.

There may be authority requirements, and/or relevant guidelines and standards that impose requirements and constraints on how the risk assessment should be performed.

An overview of the most relevant methods is given in Table 3.1, together with an indication of the phase(s) of a system's life in which they are suitable.

Table 3.1Applicability of analysis methods in the various phases of a system's life.

G = good/suitable, M = medium/could be used, B = bad/not suitable.

A number of data sources are required for a risk assessment. We seldom have many alternative data sources to choose from and often we struggle to find data at all, in particular data that are directly relevant. Types of data and data sources are discussed in Chapter 9. Factors, such as quality, age, completeness, and relevance of data should be considered when making the choice.

Before starting the risk analysis, we need to identify the assets that are relevant to consider. The assets to consider (e.g. people, environment, and reputation) are defined as part of the scope of the study, but we may need to define more precisely which assets may be harmed by accidents. An example may be that we have to specify whether we are looking only at employees at a plant or also neighbors who may be affected.

The structure of step 3 is shown in Figure 3.6.

Figure 3.6Step 3: Identify hazards and initiating events.

Methods that may be used to perform this step are presented in Chapter 10. The aim of this step is to answer the question “What can go wrong?” Based on the terminology discussion in Chapter 2, we see that this question may be answered in different ways. We may identify:

Sources of possible harm (i.e. hazards).

Starting points for accident scenarios (i.e. initiating events).

Events that are the “center” of the bow‐tie (i.e. hazardous events).

Events and conditions that trigger accidents (i.e. enabling events and conditions).

At an initial stage of a practical risk analysis, we often identify several or all of these when we try to answer the question. We may identify both flammable materials, gas leaks, ignition, fire, and explosion as separate hazards/events to consider, but when we inspect these more closely, we can see that they can form different events in a sequence, that is, an accident scenario.

The important point in this process is to identify as many events and conditions as possible. At this stage, we should not be too concerned about whether these are hazards, initiating events, enabling events, or enabling conditions.

Hazard and event identification may be supported by generic lists of hazards. Examples of such lists can be found in the standards related to machinery safety (ISO 12100 2010) and for major accident hazard management during design of offshore installations (ISO 17776 2016). When looking at these lists, we often find that the lists are also a mix of hazards, initiating events, and enabling events and conditions in the way that it is defined in this book. This may be confusing, but this should not stop us from using these lists for brainstorming purposes because the structuring of the information can be done afterwards.