Executive Health and Safety

Feasibility of storybuilder software tool for major hazards intelligence

Prepared by the Health and Safety Laboratory for the Health and Safety Executive 2010

RR778 Research Report

Executive Health and Safety

Feasibility of storybuilder software tool for major hazards intelligence

Diego Lisbona & Mike Wardman PhD CEng Health and Safety Laboratory Harpur Hill Buxton Derbyshire SK17 9JN

The aim of this research was to investigate the feasibility of using the software tool Storybuilder version 2.0.34 (2008), developed by the Workgroup Occupational Risk Model (WORM) project in the Netherlands, for recording and analysing major hazards loss of containment (LOC) incident data as a tool to better understand how accidents happen and where prevention efforts should be focused. The ultimate aim of the project is to determine if Storybuilder can provide enhanced intelligence about major accident hazards and therefore allow better targeting of HSE intervention resources.

This report and the work it describes were funded by the Health and Safety Executive (HSE). Its contents, including any opinions and/or conclusions expressed, are those of the authors alone and do not necessarily reflect HSE policy.

HSE Books

© Crown copyright 2010

First published 2010

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording or otherwise) without the prior written permission of the copyright owner.

Applications for reproduction should be made in writing to: Licensing Division, Her Majesty’s Stationery Office, St Clements House, 2-16 Colegate, Norwich NR3 1BQ or by e-mail to hmsolicensing@cabinet-office.x.gsi.gov.uk

ACKNOWLEDGEMENTS

The authors wish to thank Tom Maddison, Colin Harris and Kirstin Wattie for their assistance in this work.

ii

CONTENTS

1 INTRODUCTION......................................................................................... 1 1.1 Loss of Containment Incident Report....................................................... 1 1.2 Workgroup Occupational Risk Model (WORM) ....................................... 2

2 STORYBUILDER STRUCTURE................................................................. 4 2.1 Bow-ties................................................................................................... 4 2.2 Barriers .................................................................................................... 5 2.3 Management System............................................................................... 7 2.4 Storybuilder bow-tie for LOC incidents .................................................. 13

3 UK LOSS OF CONTAINMENT INCIDENT CODIFICATION AND ANALYSIS ....................................................................................................... 20 3.1 Incident codification (Dutch LOC bow-tie).............................................. 20 3.2 Changes to Storybuilder’s LOC bow-tie................................................. 24 3.3 Analysis of LOC incident data using Storybuilder .................................. 28

4 DISCUSSION............................................................................................ 32 4.1 Introduction............................................................................................ 32 4.2 Issues raised in the LOC Report Review document (2005) ................... 32 4.3 Comments raised from Storybuilder evaluation ..................................... 36

5 CONCLUSIONS AND RECOMMENDATIONS......................................... 37

6 REFERENCES.......................................................................................... 38

7 GLOSSARY.............................................................................................. 39

iii

iv

EXECUTIVE SUMMARY The aim of this research was to investigate the feasibility of using the software tool Storybuilder version 2.0.34 (2008), developed by the Workgroup Occupational Risk Model (WORM) project in the Netherlands, for recording and analysing major hazards loss of containment (LOC) incident data as a tool to better understand how accidents happen and where prevention efforts should be focused. The ultimate aim of the project is to determine if Storybuilder can provide enhanced intelligence about major accident hazards and therefore allow better targeting of HSE intervention resources.

Storybuilder is based on a bow-tie structure where the incident is at the centre, linking the event causes and its consequences. In the bow-tie framework, an accident path is represented in terms of the breakdown of one or several barriers that would otherwise have prevented the accident or mitigated its consequences. Barrier failures are most frequently traceable to management delivery system failures through tasks. This enables Storybuilder to summarise rich, varied and often complex data collected in accident reports in the form of a series of common scenarios from where conclusions can more easily be drawn.

Staff at HSL were trained in the use of Storybuilder by White Queen Safety Strategies, who developed the software. A suitable modified bow-tie structure for codifying LOC HID and RIDDOR incident reports was designed. Incident data available from the LOC Incident Analysis Report dataset (Collins & Keeley, 2003) were entered for a preliminary assessment of Storybuilder’s ability to store and analyse LOC incident information.

Storybuilder’s performance was critically evaluated and compared against the issues raised in the LOC Incident Analysis Report Review (2005).

Objectives

1. To instruct HSL staff in the use of Storybuilder software for accident recording and analysis.

2. To develop a suitable bow-tie framework for storing HID and RIDDOR LOC incident information.

3. To perform a preliminary evaluation of Storybuilder as a tool to store and analyse LOC incident information.

4. To compare Storybuilder’s potential against the methodology used in the LOC Incident Analysis Report (2003) with an emphasis on the issues raised in the LOC Incident Analysis Report Review (draft 2005).

Main Findings

1. Storybuilder can be used as a tool to assess the quality of existing incident reports. In Storybuilder’s framework, each of an incident’s direct causes are directly linked to task and management delivery failures. HID and RIDDOR incident reports identify the main cause and one or several of the underlying causes, although very often failures in the management system and task failures associated are not codified in the incident report.

2. Accounting for all incident causes, including their related management delivery and task failures, is necessary to map the accident sequence of events and causal interactions taking place. Storybuilder can provide enhanced intelligence, as extensive information

v

can be stored whilst the bow-tie framework keeps data organised and easily accessible. This contrasts with the SPSS database used in the LOC Incident Analysis Report, where a much more reduced classification criteria could be used. The improved quality of the stored data will have a significant positive impact on the accuracy of the conclusions extracted from them.

3. The Microsoft Access framework used in Storybuilder could allow the implementation of alternative custom-made codes for data analysis. This would provide enhanced flexibility for the database to evolve with data analysis trends. An up-to-date database would also allow incident analysis at regular time intervals, to monitor the effect of targeted intervention.

4. Storybuilder’s bow-tie for LOC analysis provides a flexible structure that can assist the inspector to direct the investigation towards the failing elements and to dissect the motives behind them in an organised manner. It can therefore be used as a training tool. There is no need of new static forms to fill in as the Storybuilder structure can be embedded within the existing inspection procedures and forms.

5. The contribution of human error is stored within the LOC bow-tie, as opposed to the LOC Incident Analysis report where it was only selected as a cause if there were no other direct incident causes.

6. Data stored in Storybuilder can be selectively extracted and analysed by performing directed searches using the Boolean search tool. Frequency data for incidental factors associated to a barrier failure together with the respective management deliveries and task failures associated can be determined for a particular activity or containment type, type of industry etc.

7. The relatively reduced number of incidents analysed in this work (32) was too small to extract definitive conclusions; a full comparison exercise using the same dataset as the LOC indent analysis report should be performed for a better picture of Storybuilder’s performance.

vi

1 INTRODUCTION

1.1 LOSS OF CONTAINMENT INCIDENT REPORT

The key aim of the LOC Incident Analysis Report (2003) was “to produce a profile of incidents that result in loss of containment within the UK, and to identify the underlying factors that led to the incident”. A total of 718 LOC incidents reports from onshore chemical and hazardous installations compiled between 1991 and 2002 were codified and recorded in a database using the statistical software package SPSS. The fields used for codifying the data included:

• type of incident (fire, explosion of release of a hazardous substance);

• nature of the substance (whether it was extremely flammable, highly flammable, very toxic according to the Chemicals Regulations 2002);

• quantity lost;

• operating mode (normal operation or maintenance);

• release site (pipe or flange etc);

• incident cause and underlying causes; and

• type of injury, the total injured and whether there had been offsite consequences.

The analysis concluded that

• 88% LOC resulted from uncontrolled releases;

• 7.4% from fires;

• 4.7% from explosions;

• 64% of the incidents occurred during normal operation; and

• 16% LOC incidents occurred during maintenance.

The main direct causes of the incidents were inadequate isolations (10.9%), overflow (10.2%), and runaway/unplanned chemical reactions (9.6%).

In the LOC Incident Analysis report, the risk control system that was the underlying cause of each incident (design of the plant and process, operating procedures, maintenance, etc) was identified. The safety management system involved in the incident causes was also identified according to HSG65 (HSE, 2001) criteria of policy, organisation, planning and implementation, measuring, audit and review (POPMAR). The HID (LD1-4) Inspection Manual was used to determine the particular POPMAR element.

The primary risk control systems failings were maintenance (27.2%) plant & process design (25.8%), and operating procedures (24.4%). Although in the LOC report the codified incident data was able to identify the most frequent direct causes and the associated POPMAR framework elements, the generally broad categories that incident information had been classified into did not help to identify the critical safety issues involved that the LOC Incident Report Review (draft 2005) highlighted.

1

In 2007, Storybuilder, an incident analysis tool developed by Workgroup Occupational Risk Model (WORM) in the Netherlands, was successfully used to record overfilling incidents (Baksteen, 2007). This work highlighted the fact that failures of the barriers ‘batch size preparation’ and ‘flow feed control’ were the main causes for high-level deviations. In 75% of all batch size failures the batch size preparation was performed but not used. 85% of the flow feed control failures were due to the control system not being used, properly maintained or monitored. In almost 60% of the overfilling incidents, indication failure was the direct cause; in 40% of the cases there was no high-level indicator. The identification of management and task failures for all the incident causes using WORM methodology was particularly effective to identify the most common failing elements within the system, therefore providing useful information to better target interventions. It follows that Storybuilder could represent a valuable tool to record and analyse incident information from all types of LOC incidents, in a way that overcomes the shortfalls of the LOC Incident Analysis Report.

1.2 WORKGROUP OCCUPATIONAL RISK MODEL (WORM)

The Workgroup Occupational Risk Model (WORM) project started in 2003, funded by the Ministry of Social Affairs and Employment of the Kingdom of the Netherlands (SZW) to develop an Occupational Risk Model (ORM). The model’s aim was to quantify the risks associated to individual workers and, ultimately, to provide industry with a tool that allows a more effective allocation of resources in risk reduction (National Institute for Public Health and the Environment, 2008).

In the development of the ORM, the risks arising from having a particular occupation are calculated from ‘the risks associated to the hazards the worker has to face’ and each job was associated with the relevant hazards and exposures over a year of employment (Ale et al., 2008). Therefore, it was crucial to identify the list of hazards relevant to a particular occupation by using any data on the hazards’ materialisation that is available. At this point, accident statistics that had been compiled over the years in three European databases were used: GISAI (The Netherlands), RIDDOR (UK) and ORI (Denmark). In the Netherlands, serious accidents are reportable according to article 9 of the Dutch Working Conditions Act (Arbowet, 1998) and stored in GISAI (Geïntegreerd Informatie Systeem Arbeids Inspectie) if “the victim is hospitalised within 24 h and for at least 24 h or the injury is permanent whether or not the victim is hospitalised” (Storybuilder Manual, 2008). In the UK, employers and the self-employed are required to report deaths, major injuries, over-three-day injuries, reportable work-related diseases and dangerous occurrences to the Health and Safety Executive (HSE) under the 1995 Reporting of Injuries, Diseases and Dangerous Occurrences Regulations (RIDDOR).

The Storybuilder software package was created within the ORM framework out of two requirements:

i. The need to classify the wealth of accident data according to the particular hazard or group of hazards.

ii. The need to quantify the contribution of each class of hazard to a job’s overall risk.

A bow-tie structure based on fault and event trees, joined together by the centre event and the materialisation of the hazard, was constructed. The causes and consequences of each particular accident are entered as an individual sequence of events from left to right in the cause-consequence Storybuilder structure. Accidents were classified according to the hazard behind the injury (centre event in the bow-tie) such as a fall from ladders, overfilling or loss of containment. In the development of ORM, a total of 9142 reportable occupational accidents were entered in 36 Storybuilder bow-ties (Storybuilder Manual, 2008).

2

Accidents within each particular type of centre event can be entered and simultaneously visualised within the structure. When an incident consists of a complex combination of events, i.e. LOC followed by explosion and fire; Storybuilder allows accurate representation of the accident path whilst avoiding double counting.

The main features of the Storybuilder software package as provided to HSL by WORM are presented in section 2. These have been compiled from Storybuilder’s supporting documentation, WORM publications and training sessions at HSL Buxton.

3

2 STORYBUILDER STRUCTURE

2.1 BOW-TIES

In an accident scenario, the link between an accident and all its possible causes can be represented in the form of a fault tree. In an analogous approach, the relationship between an accident and its possible multiple consequences can be represented by means of an event tree. Fault and event trees can be integrated in the form of a bow-tie diagram where the centre event represents ‘the release of a hazardous agent’ as presented in Figure 2-1. This structure is particularly useful for analysing accidents, as their causes and consequences remain linked together. Moreover, it provides the user with a simplified classification framework where the usually varied information available in incident reports can be consistently stored and summarised according to a fixed common criteria.

Figure 2-1 Bow-tie diagram (Storybuilder manual, 2008)

In some accidents, the centre event of the bow-tie can be selected from a series of options, whether it is an essential item not functioning properly or the moment in which that particular item was not prepared in the correct manner, all are valid options as centre event of the bow-tie. Bellamy et al (2007) stressed the importance of an appropriate selection of the centre event in the bow-tie, as some of the bow-tie diagrams generated will be more detailed than others and therefore more useful.

In the development of ORM, a series of Storybuilder bow-ties were created for entering the accident data. The bow-ties were produced from several accident classification frameworks: the EU ESAW (European Statistics on Accidents at Work), the Dutch Labour Inspectorate’s priorities in reducing exposures to risks, and the Health and Safety Executive’s RIDDOR. An example of a Storybuilder bow-tie diagram for loss of containment as centre event is shown in Figure 2-2.

Both the left hand side (LHS) and right hand side (RHS) of the bow-tie framework, where the causes and effects of the accident are represented, are actually modifications to fault and event

4

tree structures. To build a fault tree, detailed study of the event is needed to identify the primary events and establish how these can lead to a top-event. For the purpose of analysing incident data, a full fault tree is not necessary, therefore the LHS of the bow-tie is more similar to a classification of the causes. Furthermore, information that does not constitute an accident cause, such as the type of industry and the type of activity, are incorporated in the left hand side. A similar situation occurs on the RHS, as the causes of an accident’s severity are stored alongside the event effects.

Figure 2-2 Storybuilder’s bow-tie diagram with accident paths (GISAI database)

2.2 BARRIERS

In Storybuilder a barrier is ‘a state or condition of an object or action that acts as an obstacle in an accident path’. The concept of barrier was first introduced by Haddon (1973) and has evolved into a great deal of different barrier types according to their role in preventing an accident (Bellamy et al, 2007).

5

There can be passive hardware barriers whereby an accident is prevented and/or its consequences mitigated without the need of any intervention, activation mechanism or moving parts. Retention bunds are a classic example of passive hardware barriers. Active hardware barriers are those that need activation either manually or automatically and require “a sequence of detection-diagnosis-action” for them to work. An example of active hardware barriers can be an automatic shutdown system. Finally, behavioural barriers need human judgement and/or intervention of any kind, such as detector reading by a plant operator for switching off equipment. Barriers usually take aspects from the three types to fulfil their mission. The ARAMIS project definition of safety functions and barriers also included symbolic barriers, which are those that require interpretation by a person for them to act as barriers, such as a line keeping out of a working area (de Dianous & Fiévez, 2006).

Barriers are embedded in Storybuilder’s bow-tie diagrams in the form of Primary Safety Barriers (PSBs), which are those directly involved in an accident’s sequence of events and whose state is essential to determine whether the centre event of the bow-tie is materialised, and Support Safety Barriers (SSBs), which influence the failure probability of a PSB (Ale et al, 2008).

Figure 2-3 PSB, SSB and barrier failure and success modes

Figure 2-3 shows PSB, SSB and barrier failure and success modes for the barrier states. Groups of barriers are indicated by red rectangles such as the group ‘Containment condition/content barrier failure group G. The control of process conditions is represented by PSB Process settings and controls in the green box (B), which is directly influenced by any deviations detected in the process conditions (SSB Process deviations). The final state of the PSB can be either Barrier

6

Success Mode (BSM), when the deviations were controlled or a Barrier Failure Mode (BFM) if the system was unable to control them, leading to an accident. Barrier failures are represented in Storybuilder with a red oval; descriptions of the barrier failure state can be accessed by double clicking the mouse on the barrier failure oval. Barrier failures are further illustrated by influencing factor (light blue diamond shape box).

2.3 MANAGEMENT SYSTEM

The underlying causes of an accident can usually be traced back to failures in management. In Storybuilder’s framework, the failure of a barrier is caused by the failure of one or several management deliveries through tasks. Storybuilder’s management delivery system structure in relation to a task is shown in Figure 2-4. Storybuilder represents management deliveries to ensure that a barrier is in place in the form of the following categories:

• Plans and procedures;

• Availability;

• Competence;

• Communication and collaboration;

• Conflict resolution;

• Motivation/commitment;

• Ergonomics (Man-Machine Interface, MMI); and

• Equipment (tools, spares, parts)

Management is delivered to the barrier through tasks, which represent the act of providing, operating, maintaining and monitoring the state of the barrier. For each particular barrier failure in an accident’s sequence of events, Storybuilder rules allow a maximum of three failed management deliveries and one task that has been failed.

Storybuilder’s user manual provides a description of each type of management delivery and the task categories. This assists the person codifying the incident report in choosing the relevant management delivery and task failures to a particular barrier failure in an accident path. The description of Storybuilder’s Management deliveries and tasks are collected in Table 2-1.

7

Figure 2-4 Storybuilder’s structure for task groups and management delivery systems

8

Table 2-1 Storybuilder’s management delivery classification and descriptions (Storybuilder user manual, 2008)

Management Delivery

Description

Plans & procedures

Procedures refer to specific performance criteria which specify in detail, usually in written form, a formalised 'normative' behaviour or method for carrying out tasks, such as: checklist, task list, action steps, plan, instruction manuals, fault-finding heuristic etc.

Plans refer to explicit planning of activities in time: either how frequently tasks should be done, or when and by whom they will be done within a particular time period (month, shutdown period, etc). It includes maintenance regime, maintenance scheduling (including shutdown planning), and testing and inspection activities. This delivery system also refers to rules, permits, programs and risk assessments.

Availability

Availability refers to allocating the necessary time (or numbers) of competent and suitable (including anthropometrics and biomechanics) people to the tasks to be carried out. It emphasises time-criticality, i.e. people available at the moment (or within the time frame) when the tasks should be carried out.

This delivery system includes the availability of staff for repair work on critical equipment outside normal work hours, including coverage for absence and holidays.

Competence

Competence refers to the knowledge, skills and abilities of the people selected for the execution of tasks. It also covers the selection and training function of a company to deliver sufficient staff for overall manpower planning. This delivery system also refers to 'right person for the job', i.e. with the proper knowledge to provide, use, maintain or monitor the barrier effectively.

Communication, collaboration

Communication/ collaboration refers to internal communication and coordination. Internal communications are those communications that occur implicitly or explicitly, within any primary business activity, i.e. within one task or activity in order to ensure that the tasks are coordinated and carried out according to relevant criteria.

This delivery also refers to task instructions and communication channels and means (such as meetings, logs, phones, radio).

Note: this delivery system is only relevant if the activity is carried out by more than one person (or group), who have to coordinate or plan joint activities.

Motivation, Commitment and Alertness

Motivation/ commitment refers to incentives and motivation with which people have to carry out their tasks and activities, i.e. with suitable care and alertness, and according to the appropriate safety criteria and procedures the organisation specified for the activities.

This delivery system also includes the aspect of alertness, care and attention, concern for safety of self and others, risk avoidance and willingness to learn and improve.

Note: • This delivery system is fairly closely related to Conflict resolution, in that it deals

with the incentives of individuals carrying out tasks to not choose other criteria above safety, such as ease of working, time saving, social approval, etc.

• Organisational aspects of conflicts are covered by Conflict resolution. • More personal aspects, such as violation of procedures, are covered by

Motivation/ commitment.

9

Conflict Resolution

Conflict resolution deals with conflicts between safety and other goals within the performance of tasks. It deals with the mechanisms (such as supervision, monitoring, procedures, learning, group discussion) by which potential and actual conflicts between safety and other criteria in the allocation and use of personnel, hardware and other resources, are recognised, avoided or resolved.

Note: • This delivery system is closely related to Motivation/ commitment. • Issues of violations within tasks at an individual level are covered by Motivation/

commitment. • Conflict resolution covers the organisational mechanisms for resolving conflicts

across tasks, between people at operational level and at management level.

Ergonomics

Ergonomics/MMI deals with the fit between the man and the task. It refers to the ergonomics of all equipment used/operated by operations, inspection or maintenance to provide, use, maintain or monitor the barriers.

This delivery system covers both the appropriateness of the interface for the task and the user-friendliness to carry out tasks.

It includes: • appropriate equipment, tools and software; • robust/ appropriate/ good interface and labelling; and • operability and maintainability.

Ergonomics/ MMI also covers: • design and layout of control rooms and manually operated equipment; • location and design of inspection and test facilities; • the maintenance-friendliness of equipment; and • ergonomics of the tools used to maintain it.

Equipment (tools, spares, parts)

Equipment refers to the hardware needed for provision, maintenance and monitoring of barriers.

This delivery system covers both the correctness of the equipment for their use (compatibility, suitability, quality), and the availability of equipment where and when needed to carry out the activities. It includes: spares and parts (including. those needed for maintenance) and adequate and correct stocks.

Tasks are operated and delivered at a lower level in the management hierarchy, as it is usually the plant operators/workers who ensure that the barrier is provided, used, monitored and maintained. The failed tasks, whether it was a failure in providing, using, monitoring or maintaining what caused a barrier to fail, can be identified by answering a number of questions, according to the decision diagram provided by WORM (Figure 2-5). Further information to assist in the selection of the adequate type of task failure associated with a barrier is given in Table 2-2.

10

Figure 2-5 Decision diagram for selecting the most relevant failed tasks to failed barrier

(Storybuilder user manual, 2008).

Table 2-2 Storybuilder’s failed tasks classification and descriptions (Storybuilder user manual, 2008)

Management Delivery

Description

Provide-[barrier] failure

It does not exist, has not been well designed, or it is not provided and/or sufficiently/easily available when you want to use it. Such a barrier can be hardware or a specific method (sequence, composition, or other parameter(s) with safe limits).

Use-[barrier] failure

The correct barrier is provided, but the way in which the provided barrier is used is incorrect, it is only partially used, or it is not used at all. A ‘use’ failure is also the case, when somebody chooses to use a barrier other than the correct one, despite the correct one being available.

Maintain-[barrier] failure

The barrier is not kept available according to its designed function, i.e. in an adequate state. This does not only cover the maintenance aspect but also the management of change aspect of a barrier, i.e. a barrier is modified without ensuring that it maintains its barrier function.

Monitor-[barrier] failure

The barrier condition is not checked/measured/observed/inspected. This task relates directly to the state of the barrier, or to the supervision of the use of the barrier.

11

Figure 2-6 Example of Storybuilder’s management delivery and

task failure structure

A section of a Storybuilder diagram showing the management and task failures associated with the failure of a barrier is provided in Figure 2-6. In Storybuilder, barriers are indicated by red ovals. The example in Figure 2-6 codifies an accident involving the release of a hazardous substance as a consequence of overfilling a storage tank. The operator who started the pump miscalculated the filling time and did not regularly check the level indicator, as recommended by the plant procedures. The accident path linking the relevant boxes is represented by the coloured lines. The management system items ‘plans and procedures’ and ‘commitment/alertness’ are relevant to the failed task, which was the adequate monitoring of the tank level. Management delivery failures to barriers eventually lead to the failure of the barriers. In Storybuilder, the failure of a barrier is linked to one or several Loss of Control Events (LCE) that participate in the ‘release of the hazard agent’ (centre event of the bow-tie). These are described in more detail in section 2.4.

12

2.4 STORYBUILDER BOW-TIE FOR LOC INCIDENTS

2.4.1 Left hand side (LHS) of LOC bow-tie (WORM structure)

The type of industry, activity, equipment type and regulations are entered in Storybuilder as the first boxes on theLHS of the LOC bow-tie. These are elements that do not strictly belong in a fault tree structure, but were included in the LHS of Storybuilder’s LOC bow-tie as they assist to illustrate the causes of an event in more detail.

Figure 2-7 Left hand side (LHS) of LOC bow-tie (WORM structure)

2.4.1.1 Type of Industry

The type of industry is represented in the structure by the first box, where it is selected whether the industry is process-related. In the process state box, the operation mode where the incident took place can be selected: normal operation, not normal operation, maintenance on containment and cleaning of containment.

2.4.1.2 Type of Activity

The activity box collects more detailed information about the type of activity that was taking place near or in the containment when the incident happened. According to WORM’s classifications of activity type, the incident may have occurred whilst:

• a substance was being added to or removed from a containment;

• transporting the containment;

• a temporary connection was being used;

• the containment was being opened or operated opened; and

• activities were being carried out near or on the containment.

There is also a passive type of activity, when either the containment itself or the person operating it was not performing an activity that was directly connected to the containment itself. Each one of these classification boxes has one or several sub-boxes than can be used to describe the effect in more detail.

13

2.4.1.3 Equipment classification

The equipment type-containment type group box branches out into several sub-boxes that allow the user to enter information about the containment and/or element of equipment directly involved in the LOC. Storybuilder’s equipment classification follows the European Statistics on Accidents at Work (ESAW) classification structure. An additional equipment type group box is provided in the Storybuilder LOC bow-tie to enter information about other secondary equipment that played a role in the LOC event. Apart from the categories in the previous boxes, this box includes additional boxes to account for the involvement of any building structures and surfaces or the presence of materials, objects, machine parts, dust or debris etc.

2.4.1.4 Regulations

A regulations group box where the Dutch regulations applicable to LOC events is included in the Dutch LOC bow-tie. The box branches into a group of children boxes, one for each article, and these branch into several sub-articles that are normally related to the type of activity.

2.4.1.5 Support Safety Barriers (SSB): Containment condition – content barrier failure (BFM)

The first group of barrier failures in connection to the LOC event comes next to the Regulations box in the LHS of the LOC bow-tie (Group box 4). It groups the barrier failures related to the containment condition and contents in four Support Safety Barrier (SSB) groups:

• containment not safeguarded;

• process deviations;

• substandard containment; and

• containment protection against external influences failure.

The SSBs branch into BFMs, which are not exclusive in a LOC; several barrier failures may be playing a role in the LOC event. A total of 14 different BFMs were included in the Dutch BFM bow-tie, apart from one box to account for unknown barrier failures (Figure 2-8). Each BFM state is linked to the barrier box, the barrier’s success mode box (BSM) and its management and task delivery systems. A BSM allow the user to enter a barrier’s effectively performing its role in an accident path. The underlying causes behind each BFM is entered by means of the Management Delivery System and tasks associated to it following the structure and descriptions given in Figures 2-4 and 2-5 and Tables 2-1 and 2-2.

2.4.1.6 Containment condition – content Loss of Control Event (LCE)

In Storybuilder, the failure of a primary safety function is linked to a Loss Control Event (LCE) represented in the bow-tie structure by yellow-coloured boxes. LCEs are those directly linked to the release of the ‘hazardous agent’ or centre event of the bow-tie. LCEs for the containment condition-content type of barrier failures in WORM are classified into process parameter deviations (substance flow, temperature and pressure deviations) and other LCS such as unknown events, physical or chemical processes, substandard containment, unsafe location, unprotected containment against external elements. These are connected to the appropriate BFM boxes in the bow-tie section shown in Figure 2-8.

14

Figure 2-8 Barrier failures and LCE related to the containment condition and contents on the LHS of LOC bow-tie (WORM structure)

15

2.4.1.7 Direct Barrier Failure Group (BFM) and associated LCEs and PSBs A second group of barrier failures and associated LCEs are shown in Figure 2-9. A total of eight direct BFM categories were considered in WORM LOC bow-tie. LCE of direct barriers are directly linked to primary safety barriers that represent the final cause of the LOC event; the containment was bypassed, came apart or the containment strength failed.

Figure 2-9 Direct barrier failures, LCE and related PSB on the LHS of

LOC bow-tie (WORM structure)

2.4.2 Right hand side (RHS) of LOC bow-tie (WORM structure)

The consequences of a LOC are codified on the RHS of the bow-tie (Figure 2-10). A LOC incident can lead to others such as fires and explosions. These ‘domino effects’ require an independent bow-tie and therefore a Domino Effect Group box for linking the two bow-ties was included on the RHS of the LOC bow-tie. The next box group corresponds to the group of safety barriers that are responsible for providing a safe spatial separation between a potential victim and the LOC event. The group of relevant pieces of Dutch legislation related to a potential victim’s protection against the LOC event comes next, together with the group of barriers that prevent the contact of a victim with the hazardous substance (a LCE itself). All possible Emergency response safety barrier failures are collected in a square red box in terms of

16

LCEs: these account for the possible failures in restricting the dose of hazardous substance that the victim is exposed to.

The main objective of WORM was the development of a occupational risk model (ORM) to quantify the consequences of accidents in terms of time lost (money), therefore a great deal of attention was put into describing LOC effects data such as the dose determining factors, the number of casualties, the part of the body that was injured, the number of days in hospital, the injury severity duration and the total length of time that was lost.

The dose determining factors related to a victim’s contact with a hazardous agent are, for instance, the state of the substance, the type of substance, the distance between source and victim and the exposure time. Dose determining factors were given the box next to the Emergency Response failure group on the RHS of the bow-tie.

In the analysis of LOC incidents for prevention of future occurrences, these last occupational health types of boxes are not as necessary or relevant as in an ORM. These and other proposed alterations to the WORM LOC bow-tie are discussed in more detail in section 3.2.

Figure 2-10 Right hand side (RHS) of LOC bow-tie (WORM structure)

2.4.2.1 Domino effects group box

WORM allocated six sub-boxes to the Domino Effect group in the LOC bow-tie. These categories represent all the possible events triggered by a LOC incident. According to WORM, the bow-ties a LOC can be related to are:

• fall from height ladder;

• contact with object from exploding, igniting, disintegrating object;

• release of hazardous substance from open containment;

• contact with hazardous substance without LOC; and

• fire and explosion.

17

2.4.2.2 Location of victim failure group

The failure of the barrier ‘Safe distance’ between a potential victim and the location where the hazardous agent was released is represented in WORM by seven BFM that are associated to LCEs, as shown in Figure 2-11. These LCE are the answer to why the victim was in the hazardous area when the contact occurred. BFM boxes are each connected to their management delivery and task failures.

Figure 2-11 Barrier, barrier failures and LCE related to the location of a victim with

respect to the containment (RHS of LOC bow-tie)

2.4.2.3 Contact with hazardous substance (LCE)

If there is contact between a released hazardous substance and a victim during the course of an incident, the LCE event ‘contact with hazardous substance’ must be selected as part of the accident path (see Figure 2-12). There are three barrier failures associated to this LCE, which are related to the use of a safety device barrier (including personal protective equipment, PPE). The failed state of this particular barrier is further illustrated by influencing factors, which give information about the safety device or the barrier that failed.

2.4.2.4 Mitigation-Emergency response failure group

The barrier “mitigation/emergency response” has eight possible failed states that lead to LCEs. These LCEs represent cases when there has been ‘hardly no limitation of dose’ (Figure 2-12).

18

2.4.2.5 Dose determining factors

Information about the state, and type of substance released from the containment, the distance source-victim and exposure time can be entered on the RHS of the bow-tie, therefore in terms of its effects on the victim. Other dose determining factor categories considered in the WORM bow-tie are the type of exposure (skin/eyes, inhalation or ingestion) and the nature of the hazard (whether the potential to cause harm is related to the substance’s temperature or pressure, toxic or corrosive nature).

Figure 2-12 Barrier failures and LCE associated to the contact with a hazardous substance and its mitigation (emergency response) on the RHS of LOC bow-tie

19

3 UK LOSS OF CONTAINMENT INCIDENT CODIFICATION AND ANALYSIS

3.1 INCIDENT CODIFICATION (DUTCH LOC BOW-TIE)

Incidents are entered in Storybuilder as accident paths linking the boxes that correspond to the centre event, LCEs, BFM, task failures, management delivery failures etc, according to the framework presented in section 2.4. The first step in the codification of an incident is therefore the analysis of the incident report to identify the loss of control events, barrier, task and management delivery system failures.

3.1.1 Incident report analysis

An example of HID incident report analysis for entering data in the Storybuilder LOC bow-tie is shown in Figure 3-1. Five steps should be followed when gathering information from an incident report:

1. Identify the Storybuilder bow-tie. Based on the analysis of 10,000 incidents by the Dutch labour inspectorate, 37 centre events or ‘releases of the hazardous agent’ were identified. WORM developed 37 different bow-ties for entering the various types of accident data. In a LOC event, the centre event of the bow-tie is the release of the hazardous substance. There can also be associated bow-ties to account for other events originating from the LOC. Examples of these are a fire or an explosion caused, for instance, by the release of a flammable liquid followed by ignition and development of a pool fire, or the release of a cloud of flammable gas and subsequent vapour cloud explosion, respectively. These events are consequences of the LOC event, therefore the need for the domino effect boxes on the RHS of the LOC bow-tie; the relevant domino effect box can be selected as part of an accident path and therefore taken into account in the analysis. In the HID report example given in Figure 3-1, the centre event was the release of propylene oxide; no domino effect was associated.

2. Identify the Loss Control Events. LCEs are events necessary and sufficient to cause the centre event and very often appear as the main cause of the LOC in an incident report. In the report analysis illustrated in Figure 3-1, there are two LHS LCEs. First comes the LCE ‘substance/flow deviation inside containment’ which later leads to ‘overfilling of containment’ before the release of the hazardous substance occurs. The Primary Safety Barrier (PSB) that is operative is ‘Containment by-passed’, as the containment remained intact and the substance was released through an existing opening (vent).

There were no LCE related to the consequences of the release of the substance (RHS of the bow-tie); the substance was lost to bund, and no information about any effect on the operators was given in the report (no victims).

3. Identify the Barrier Failures. Once the centre event and the LCE events have been identified, it is clear for the person entering the information in Storybuilder what happened. It is now necessary to find out where things when wrong, and this can usually be found in a HID report as the incident description and underlying causes.

For the LCE ‘overfilling of containment’ the failed barrier was ‘Content deviation detection/indication’ as the high level alarm in the scrubber was not operative. The

20

associated barrier failure is ‘Content deviation (p, T, flow/substance) indication/ detection failure’.

For the LCE ‘substance/flow deviation inside containment’ the failed barrier was ‘batch size’, as batch size was not properly calculated in relation to the process equipment available and potential process deviations (Process Deviations Support Barrier).

Since no LCE related to the consequences on operators were identified, no relevant barrier failures were selected on the RHS of the bow-tie.

4. Identify the failing Barrier Tasks. The next step in an incident report analysis is to find out how things went wrong and what task caused each barrier to fall, by following the indications given in Figure 2-5 and Table 2-2.

In the example provided, the ‘batch size’ barrier failed due to the fact that the batch size calculation procedures provided were loosely worded, therefore not appropriate. The task failure associated is the failure to ‘Provide’.

The barrier ‘Content deviation detection/indication’ failed as a consequence of a failure to ‘maintain’ the high level alarm in working order. It can also be argued that the operator failed to detect the content deviation, as the underlying cause given in the report was the operator’s competence. In that case the task failure would have been a failure when ‘monitoring’ the state of the barrier. However, the fault in the high level alarm probably caused this; it is later mentioned in the Action Required by Client section of the report that the alarm should be reinstated and there should be more regular level checks. Is it then implying that the regular checks were not an established procedure that the operator had to follow? The person codifying the report into Storybuilder is left to choose the scenario that best describes the incident.

5. Identify the Management Delivery Failures. Management deliveries in Storybuilder can be identified with the underlying causes of an accident. According to Storybuilder’s manual, management deliveries are “the resources and commitments delivered through the tasks towards the technical system to enforce the barriers that prevent accidents and/or reduce their consequences”. In an accident path, management deliveries failures are allocated by using Storybuilder manual’s management delivery classification and descriptions (Table 2-1).

The task failure ‘to provide’ an adequate ‘batch size’ calculation was a management failing to deliver adequate plans and procedures. The task failure ‘to maintain’ the high level alarm was due to an unknown management delivery failure. It is not clear from the information given in the incident report whether there was no maintenance plan, or a failure in the competence of the operator in doing the maintenance required. In the report, as an underlying cause of the incident, it was established that the operator competence to detect the risk of overfilling was the underlying cause, but this is not related to the management delivery failure in maintaining the high level alarm. If the operator’s failure to monitor had been selected as the task delivery failure, then it would have been a management failure in delivering ‘Competence’.

The choice of task failure according to the incident report can be problematic, as the underlying causes stated are often not directly connected to all the reported failing elements in the HID report structure. Did the operator failed to perform the task due to the alarm not being operative? Or was it the operator competence in monitoring the high level what caused the overfilling? The incident report suggests the first option in the accident description, and otherwise in the underlying causes. HID report structure

21

would need adapting to make best use of Storybuilder’s features. Each failure associated to the incident should be traced back to the task that was not performed and the management delivery failure associated with it.

3.1.2 Entering accident paths in Storybuilder

LOC incidents are entered in Storybuilder by right clicking on the appropriate boxes from left to right in the bow-tie structure under Storybuilder’s path mode (Standard toolbar). All LOC accident paths must share the same centre event ‘release of hazardous substance’ in the centre of the bow-tie.

Accident paths are shown in Storybuilder’s path list (bottom left-hand side of the screen) and can be further illustrated with notes, for instance, to record why a particular choice was made at the time the incident was analysed/codified.

Accident paths can be accessed from the path list and can also be selected and searched for using the Boolean path search tool in Storybuilder (Select View in the Menu bar, Path Search). This tool is particularly useful when a specific type of incident needs to be identified for statistical analysis (section 3.3).

22

Figure 3-1 Analysis of a HID incident report for generating a Storybuild accident path

Barrier failure (process equipment/deviation group): batch size

Task failure: provide (an adequate batch procedure)

Management delivery failure: plans and procedures

Centre event:LOC (release of

hazardoussubstance)

Alternative option to direct barrier failure

Barrier failure: Content deviation (p,T,flow/substance) indication/ detection failure

Task failure: Monitoring

Management delivery failure: Competence

LCE: Substance/flow deviation inside containment (too much substance)

1st option for directbarrier failure

Barrier failure: Contentdeviation

(p,T,flow/substance)indication/ detection failure

Task failure: Maintain

Management deliveryfailure: unknown

LCE: Overfilling ofcontainment

PSB: Containmentbypassed

23

3.2 CHANGES TO STORYBUILDER’S LOC BOW-TIE

The aim of the LOC Incident Analysis Report (2003) was to produce a profile of incidents that resulted in loss of containment, and to identify the underlying factors that led to the incidents. Information collected in HID and RIDDOR reports was entered into a database constructed using SPSS software. The categories used for codifying data in SPSS closely matched the categories used in HID reports, which are based on the Risk Control System (RCS) and POPMAR structuctre in HID inspection guidance emanating from COMAH regulations. Two main structural issues can have an effect on the use of WORM in LOC analysis:

1. WORM structure for storing LOC data using Storybuilder does not follow RCS and POPMAR structures. It is rather based on the concept of bow-tie and accident paths that follow task and management failures behind each ‘cause’ or ‘failure’ among the various that usually occur in an accident. The example illustrating incident codification that was given in section 3.1.1 highlighted the structural differences between the information in HID reports and WORM structure.

2. WORM structure was developed with the key aim of generating an ORM, which would ultimately quantify occupational risk, i.e. put a figure on all the risks associated with individual workers. As a consequence, a great deal of categorisation effort was dedicated to the consequences (RHS of the LOC bow-tie), to identify and quantify the effect that the incident had on the victims. To identify the underlying factors behind LOC incidents, detailed information on the type of injury, hospitalisation and time lost is not that relevant.

Thirty-two incident reports that were part of the LOC Incident Analysis Project were entered into the LOC bow-tie to evaluate Storybuilder’s performance at storing and analysing LOC incident information collected in HID and RIDDOR reports. As a result, a series of changes in the LOC structure presented in section 2.4 have been judged necessary to better codify information in the incident report. The Dutch regulations box in the LHS of the bow-tie has been removed as well as those in the RHS as they are not relevant to UK incident data. Additional changes on the LHS and RHS Dutch LOC bow-tie are proposed in sections 3.2.1 and 3.2.2, respectively. These are aimed at tackling the differences in categorisation and final aim between WORM and the LOC incident analysis report that were highlighted in items 1 and 2 above.

3.2.1 Left hand side (LHS) of the modified LOC bow-tie

1. Type of industry box. Two categories were considered in WORM for the type of industry: process-related industry and not process-related. The majority of installations where LOC incidents take place correspond to process industries, therefore there is the need to adapt the type of box to provide a useful classification. The type of industry box has been subdivided into four groups which represent the relevant activities in RIDDOR and the European Union Standard Industrial Classification of Economic Activities: Mining and Quarrying of Energy Producing Materials; Manufacture of Coke, Refined Petroleum; Manufacture of Chemicals and Chemical Products; and Electricity, Gas and Water Supply.

2. Process state group box. One particular incident among the thirty-two analysed occurred whilst the plant was not operative, between shut down and start up. In the WORM structure, this could be entered under not-normal operation leading to two different types of incidents accounted for under the same category: those whilst the

24

plant is operating under not-normal conditions and those when the plant has been shut down. A new box has been added.

3. Activity group and equipment type group boxes. An extra box has been added to these two groups to account for any incident and equipment type that cannot be ascribed to the categories given in the WORM structure. Although ESAW subdivisions can be seen as too exhaustive for the purpose of LOC incident analysis, no simplification attempt has been made at this stage due to the reduced pool of incident reports that were codified.

4. Containment condition/content barrier failure group. Two new BFM have been introduced within the process deviations SSB: one to enter those LOC where contact of the substance with the ground had not been prevented, and another box for any other process deviation that cannot be assigned to the categories already present. An additional BFM mode box is included for those LOC incidents where a substandard content had been involved, for instance due to unexpected reactions caused by aged stocks. An extra failure mode box for any barrier failure that has not been anticipated in the structure.

5. Direct barrier failure group. An additional box has been added to codify those incidents that were not fully represented by the types given in the WORM structure.

It is also important to highlight here the human error component present within the direct barrier failure group in WORM. There is barrier failure to account for the ‘Operator ability failure’ but also a human error component in the rest of BFMs through task and management delivery system failure. An example could be ‘Content deviation (p, T, flow/substance) indication/detection failure’ through the task ‘Use’ and the management delivery system ‘Competence’. Operator ability failure was selected as barrier failure only in the case an operator directly causing the LOC by not following procedures, or wrongly operating the containment, or opening a valve by mistake (Influencing factors for “Operator ability failure” describing these situations have therefore been created). If any other type of barrier failure, such as an indicator not properly working, caused the operator’s error then the relevant barrier failure to the event that caused the human error should be selected. The human error component is then introduced by means of the relevant task and management delivery failures as in example given in 3.1.1.

3.2.2 Right Hand Side (RHS) of the modified LOC bow-tie

1. Domino effects group box. Fall from ladders has been removed as a potential effect of a LOC as shown in Figure 3-2. If fire and explosion are consequences of a LOC incident, their presence is accounted for by the connection of the relevant domino effect box to the accident path.

2. Dose determining factors. Two boxes are provided within the RHS of the LOC bow-tie to codify the main characteristics of the released substance and the victim’s exposure to the hazardous agent. The released substance’s properties are relevant to a LOC analysis, therefore the boxes state and type of substance have been maintained. However, distance source-victim and exposure time and type of exposure have been removed, as these are not available in incident reports.

3. Part of body injury code, type of injury code, hospitalisation, injury severy/duration and lost time. These categories are not risk-determining factors and are not normally provided by HID and RIDDOR incident records. Although these are

25

useful categories in the quantification of occupational risk, they are not relevant in a study of the causes of LOC incidents. Accordingly, the RHS of the bow-tie has been simplified to three boxes: number of fatalities, number of major injuries and number of minor injuries according to the RIDDOR classification criteria (see Figure 3-3).

Figure 3-2 Modified LOC bow-tie: RHS (domino effect and RHS barrier failures)

26

Figure 3-3 Modified RHS LOC bow-tie (dose determining factors, injuries and fatalities)

27

3.3 ANALYSIS OF LOC INCIDENT DATA USING STORYBUILDER

Statistics showing path count information (number of times a particular box has been selected as part of an accident path) for a group of incidents can be accessed from the View Toolbar. Providing that Storybuilder’s rules for box number and name have been followed in the development of the LOC bow-tie structure, similar items should be grouped together, for instance, as management delivery system and task failures, barrier failures and successes or LCEs, to generate statistics about the stored LOC incidents.

Statistical information about accident paths can be visualised selecting Tree View in the View menu or toolbar. There are three options to view data in Tree View:

1. Graph view: boxes arranged in terms of their position in the graph and their connection to their children boxes;

2. Code view: boxes’ statistics sorted by box ID code; and

3. Numberless view: statistic sorted by box type, i.e. barrier failures BFM, incidental factor IF boxes etc.

Boxes in the Tree view are presented with four statistical pieces of information about their role in the selected accident paths: box count (number of times the particular box has been selected as part of an accident path), box percentage (percentage of accident paths this box forms part of), and similar counts and percentages per box for victim data between brackets [victim count], [victim %].

Items can be selected by left click and exported to Excel 2003 by right clicking and selecting ‘Export to Excel’.

3.3.1 Data analysis

Thirty-two incident reports that were part of the LOC report were introduced in the modified LOC bow-tie structure. Please note that meaningful statistical information is not available from the small pool of incidents considered. Also note that there are a number of alternatives to perform the analysis. All data collected in the bow-tie can be extracted using the Excel Statistics feature in Storybuilder (View menu > Statistics > Generate for all paths > Get for all paths), or by exporting a text file for converting into a spreadsheet by Excel (Export > All Storybuilds). The tool Boolean Search can be used to select particular accidents paths that, for instance, contain a particular barrier failure box or a combination of boxes (failure of a particular task within a barrier bailure). Sections 3.3.1.1 to 3.3.1.3 discuss the data export and analysis procedure.

3.3.1.1 Process State and Activity

Incident frequency data about the process state and operating mode during the incident can be obtained from Storybuilder by extracting to Excel the accident path information stored in the Activity Group and Process state boxes on the LHS of the bow-tie. This can be done by left clicking on Statistics (View toolbar or menu) or using the Tree View feature.

1. Using the Statistics tool. Generate statistics for all paths, and sort the resulting spreadsheet according to box type by left clicking on the field title. Data for the process state and type of activity are classified under box codes PS and A, respectively.

28

2. Using Tree View. Select all accident paths (Ctrl + left click) in the Path List window. In Tree View > Numberless Code view this information is stored as PS & A boxes. Storybuilder generates the percentages of accidents and victims for these categories by right clicking on Tree view > Refresh. Data can be exported to Excel by mouse’s right click on the Tree View window and selecting ‘Export to Excel tool’ (note that the required folders must be in expanded view). Results are presented in Table 3-1.

Table 3-1 Process state frequency data

Process state Count Paths

Count Victims % Paths

Normal operation 18 18 56.25

Not-normal operation 2 2 6.25

Maintenance on containment 7 7 21.88

Cleaning of containment 4 4 12.5 While not working, during the period between the shut down and the next start up 1 1 3.13

Detailed information about percentages of type of activity within each group of processes can be obtained by using the Boolean Path search tool to select the relevant paths (Table 3-2). An example for normal operation is shown in the sequence below:

1. Path search: 14 and (24 or 41 or 47 or 49 or 57 or 62 or 81 or 90)

Box 14 corresponds to normal operation and 24 to 90 correspond to the type of activity. Please note that box numbers correspond to the modified LOC bow-tie and do not necessarily correspond to the Dutch LOC bow-tie.

2. Press select in the Path search box. The Boolean algebra given selects the paths that pass through normal operation and for any of the activity boxes.

3. In Tree Vie > Numberless Code View expand ‘A’ folder only (Activity). Right click and select Export to Excel.

Table 3-2 Activity data related to accidents during normal operation

Operating Mode Description Count

Paths %

Paths

Normal operation (56.25%)

Adding/removing a substance to/from a containment 8 25

Adding/filling substance to containment 6 18.75

Mixing 2 6.25

Filling 1 3.13

Adding 3 9.38

unknown 1 3.13

Activities on/near containment 8 25

Sampling 1 3.13

Adding/Remove 6 18.75

Open containment 1 3.13

Passive LoC 1 3.13

Passing by 1 3.13

29

3.3.1.2 Barrier failures

When generating statistics on barrier failures it is important to note that, for one given accident, several barriers may have failed. Therefore, statistics on barrier failure are not necessarily mutually exclusive.

In the modified LOC bow-tie there are twenty-nine LHS BFM (linked to the causes of the accident), these include the boxes created for barrier failures not covered by the BFM classification. BFMs have been labelled 0_BFM to 28_BFM and as such can be found in Tree View > Numberless Code View >BFM. Information can be exported to Excel by right clicking>Export to Excel. It should be noted that both LHS and RHS BFM are exported. Within the list of BFM, LHS BFM are those between 0_BFM and 28_BFM, respectively (see Table 3-3 for LHS BFM).

Table 3-3 Frequency data for the dominant barrier failures (not mutually exclusive)

Name Count Paths % Paths

Operator ability failure 10 31.25% Substandard containment indication/ detection/diagnose/response failure 8 25%

Mixing of incompatible substances 6 18.75%

Equipment connection failure 6 18.75%

Containment condition/material failure 6 18.75% Content deviation (p,T,flow/substance) indication/detection failure 5 15.62% Content deviation (p,T,flow/substance) diagnose/response failure 4 12.5%

Isolation failure 4 12.5%

Emptying failure (not product free) 3 9.38%

Cleaning failure 2 6.25%

Prevention of not good values of T and P 2 6.25%

Others 2 6.25%

Wrong position of victim 1 3.12%

Action inside hazardous area 1 3.12%

Others 1 3.12%

Batch size failure 1 3.12%

Not prevention of substance in the ground 1 3.12%

Substandard Content 1 3.12%

Statistics about LHS BFMs for a particular process state (i.e. normal operation) or activity type or equipment type can be extracted, again using the Boolean path search. For example, the LHS barrier failures that correspond to normal operation:

Path search: 14 and (388 or 394 or 429 or 455 or 479 or 501 or 522 or 545 or 577 or 602 or 621 or 658 or 659 or 661 or 691 or 732 or 752 or 784 or 786 or 790 or 817 or 862 or 888 or 910 or 940 or 965 or 991 or 1014)

The BFMs for the selected paths can be exported to Excel using the Tree View > Numberless Code View > BFM. Once barriers corresponding to the RHS are deleted, we get a table for barrier failures under normal operation (Table 3-4).

30

Table 3-4 Frequency data for the dominant barrier failures under normal operation (not mutually exclusive)

Operating Mode Name Count Paths % Paths

Normal operation (56.25%)

Operator ability failure 7 21.88 Substandard containment indication/detection/ diagnose/response failure 4 12.50

Equipment connection failure 4 12.50

Containment condition/material failure 4 12.50 Content deviation (p,T,flow/substance) indication/ detection failure 3 9.38

Mixing of incompatible substances 3 9.38 Content deviation (p,T,flow/substance) diagnose/ response failure 2 6.25

Prevention of not good values of T and P 2 6.25

Isolation failure 1 3.13

Cleaning failure 1 3.13

Batch size failure 1 3.13

Not prevention of substance in the ground 1 3.13

3.3.1.3 Underlying barrier tasks and management delivery system failures

For each barrier failure, the underlying task and management delivery system failures can be searched and exported to Excel by right clicking on the box and selecting ‘Export branch data’. This creates a text file that can be imported into Excel including information of path count for the BFM children boxes (barrier success, influencing factors, task failures, and management delivery failures). The underlying barrier task failures for the dominant barrier failure are shown in Table 3-5.

Table 3-5 Dominant barrier task failures (not mutually exclusive)

Name Count Paths % Paths

Operate (Use): the operator is present but directly caused the LOC by not following procedures, or wrongly operating the containment, or opening a valve by mistake

6 18.75

Use of means to monitor/perform maintenance on containment condition 4 12.50

Unknown task failure associated to equipment connection 3 9.38

The dominant Management Delivery System failures that correspond with each Task Failure can be individually extracted from the group of accident paths by using the Boolean path search. For example, the various task failures associated to the Management Delivery of plans and procedures to the ‘BFM Operator Ability Failure’ can be selected by individually performing the following path searches and exporting the data to Excel: 794 and (804); 794 and (803); 794 and (808); 794 and (809).

Searches to extract frequency data can be selectively performed on those Management Delivery System failures that have been identified as dominant, whilst extracting task failures to the dominant BFMs.

31

4 DISCUSSION

4.1 INTRODUCTION

A number of issues about the information given in the LOC Incident Analysis Report (2003) were raised in the LOC Incident Analysis Project Review (draft 2005). These issues are mostly related to two main criticisms:

i. The structure followed to classify incident information, especially in relation to the level of detail of several of the categories;

ii. The way any information given in an investigation report was transferred to the structure.

Section 4.2 discusses the potential advantages and disadvantages that the use of Storybuilder could bring to overcome the limitations of the current LOC incident analysis methodology.

4.2 ISSUES RAISED IN THE LOC REPORT REVIEW DOCUMENT (2005)

4.2.1 Risk Control Systems (RSC) and Safety Management Systems (SMS)

In the LOC Incident Analysis Project, the underlying causes of a LOC incident are given for a number of operating modes: normal operation, maintenance, delivery, start-up/reinstatement and cleaning/washing. Incidents falling within the two most common operating modes (normal operation and maintenance) are distributed in the Risk Control System (RCS) structure. For instance, three main RSCs for normal operation mode are: design of the plant and process, operating procedures and planned maintenance schedules. Similarly, two RSCs are given for maintenance operation: planned maintenance procedures and permit to work. More level of detail in the main relevant RSCs to each type of site of release and incident cause is also given. These were nevertheless considered very broad in the LOC Incident Analysis Project Review. However, further categorisation was envisaged to be difficult to implement, partly due to the limited amount of information contained in the investigation reports. Further categorisation was also believed as likely to not give relevant information and to possibly prevent meaningful interpretation.

The particular Safety Management System (SMS) or POPMAR (Policy, Organisation, Planning and implementation, Monitoring/Measuring, Audit and Review) framework item applicable to each failed Risk Control System was assigned to each incident of the pool of data object of study. Frequencies and percentage of occurrence were presented in the form of tables for the two main operating modes. Tables for the four most frequent sites of release and incident causes were also provided. Information regarding the mode of operation for each incident case was also in the LOC Incident Analysis Report appendices. POPMAR categories were considered too broad, suggesting that the system would benefit from subdividing the most frequent items. This is particularly noticeable in some cases, for instance, in the Planning and Implementation item under the Planned Maintenance Procedure RSC: it was responsible for 40.2% of all maintenance incidents, but no further information was given about the particular aspect of Planning and Implementation most likely to be accountable for the LOC incident.

In Storybuilder, the RCS and SMS (POPMAR) structures are implicit in the Management Delivery Systems (MDS) and Barrier Tasks (BT) frameworks. The ‘Barrier’ terminology originates from the fact that, in Storybuilder, incidents are caused by failures of ‘physical entities that act as an obstacle in an accident path’ or Barriers. ‘Barrier Failures’ are indeed categories that frequently match the ‘Incident Cause’ reported in the LOC Report, although this is not always the case.

32

Management Delivery Systems in Storybuilder are subdivided into a series of categories that are fully described and illustrated with examples in Storybuilder’s supporting documentation. Incident codification is therefore less sensitive to personal interpretation, which is a significant advantage. Each failure of a barrier is identified with the failure to deliver the Management System through a particular task. Task categories account for failure in Providing, Use, Maintaining or Monitoring the barrier state.

Apart from differences in subdivisions and scope, there are similarities between Storybuilder’s Management Delivery Systems and Task failures and the RCS-POPMAR framework used in the LOC Report. Storybuilder’s representation of an incident physically links the failure of a Barrier or multiple Barriers (often identifiable to an Incident Cause in the LOC report) to their corresponding Management Delivery System failures (RCS in HID CI, SI in Assessing Risk Control Systems Document) through Tasks (which have components of the POPMAR structure).

Storybuilder’s framework allows the user to represent a clearer and more accurate picture of an incident. This is because one particular event (centre of the bow-tie or incident) can be represented as caused by one or several LCE, each motivated and modified by one or various barrier failures and successes. Barrier failure and success modes are affected by influencing factors that are specifically defined for each particular barrier. In case of escalating events following the LOC event, these would be linked to the LOC bow-tie and accounted for in Storybuilder statistical analysis.

The possibility of organising accident causes as multiple Barrier failures and LCEs allows the user to enter complex and diverse accident data, for instance when there have been multiple direct causes, and/or several or very specific RCS and POPMAR contributions involved. In the LOC report work, a direct cause was chosen and the RCS and POPMAR items identified for the accident.

Further subdivisions in the RCS and POPMAR framework were suggested in the LOC report review. It was anticipated that these would introduce complexity in the data analysis with SPSS, whilst information from the incident report would be lost when one particular direct cause of the accident had to be chosen. Storybuilder would store an accident’s complexity in the causes of the LOC through a series of Barrier failures and LCE, with each failure being traced back to its corresponding management failures through a Management Delivery System and Task failure structure. All Management Delivery System and Task structures in Storybuilder are built using the same elements and structure; much higher levels of detail are therefore available to codify an incident without introducing new different categories.

4.2.2 Barrier failures-LCE in Storybuilder. Comparability with incident causes in the LOC Report

The LOC Review identified ambivalence in some elements of the data recording system. The dual cause-consequence nature of some ‘Incident Causes’ was particularly noticeable: a direct cause of an incident could be interpreted as a cause or a consequence of other elements listed under direct causes. For example, ‘blockage’ and ‘overfilling’ are both incident causes, but a ‘blockage’ can cause ‘overfilling’ and vice versa therefore both may be happening in a particular incident. Given the fact that the ‘direct cause’ is key in describing a LOC event using the LOC Report methodology and only one cause is used for each incident, there may be loss of relevant information when entering incident data in SPSS.

In reality, most accidents occur due to the failure of several elements that are interconnected. Storybuilder’s structure of an accident path in terms of barrier failures and LCEs allows the input of several causes and reduces the need for choosing a main direct cause, when possibly

33

two or more led to the incident. More information about what happened is included in the analysis: an incident will comprise one or several of barrier failures and LCEs, the latter directly caused by the particular barrier failure. The barrier failure is normally illustrated by incidental factors that codify further information about the cause of the incident.

There are twenty-three Left-hand side barriers in the LOC model in WORM; fifteen of them are related to the containment itself and eight with the loss of containment. They are collected in two groups: containment condition/content barrier failure group and direct barrier failure group, respectively. In the example where blockage of a pipeline and overfilling are both taking place, codification in Storybuilder would proceed according to the accident path marked in Figure 4-1: both causes of the incident are now codified and are be taken into account in the analysis.

Figure 4-1 LHS barrier failures and LCEs for a LOC incident after pipeline blockage

and overfilling leading to release of hazardous substance

4.2.3 Level of detail

In the review of the LOC incident analysis report, it was pointed out that some categories were ‘too general’ or ‘vague’ and the classification of incidents could be improved by using more precise terms. In Storybuilder, the direct causes of an incident are codified by a number of barrier failures that can be further illustrated by entering the relevant incidental factors in the accident path. Incidental factors are described in the same level of detail as the new terminology proposed in the LOC Report review.

4.2.4 Changes to the structure

To extract meaningful conclusions from incident data, it is required that all incidents are classified using the same framework and set of criteria. In the LOC review, it was pointed out that some categories were modified and some others added in 2003, which introduced uncertainty in the analysis. The lack of sufficient data under the new categories and extracting conclusions from data classified under different criteria are the main limitations.

34

Storybuilder’s graphical interface allows modification of the bow-tie layout, addition or removal of barrier failures, management delivery systems, tasks, incidental factors etc. LOC incident analysis using Storybuilder would share this limitation if the LOC bow-tie used to store LOC accident report information is modified over time. A robust storybuild for storing all LOC incident data should be developed and used in all instances. Changes in WORM LOC bow-tie have been suggested in section 3.2.

4.2.5 Consideration of human error

It was pointed out that the LOC results in the LOC report did not account for the full contribution of human error to LOC incidents. If an incident had human error as a direct cause, it was classified as human error only if it was the sole cause of the incident.

Storybuilder’s rules on the role of human error are detailed in Annex 1: Rules for scenario modelling of Storybuilder’s supporting documentation: “Human behavior alone cannot be a barrier. However, human behaviour may influence or directly cause a barrier to fail”. Human error is nevertheless present in the LOC storybuild as barrier failure, for instance Operator ability failure, or as incidental factors that influence the state of a barrier. An example could be, for instance, the incidental factor ‘Human diagnose/response failure’ to a ‘content deviation’ barrier failure. Human error is also present in the Management Delivery Systems and Tasks failures as Competence, Communication and Motivation/commitment and on the right-hand side of the bow-tie where the effects of the LOC are codified. The right-hand side of the bow-tie includes human errors in terms of their impact on the effects caused by the LOC event. An example of this for ‘Barrier failure mode: action inside danger area’ could be the Incidental factor: ‘return to danger zone to finish work’. Human error can be quantified in the data analysis in the same way as the contribution of a particular barrier or group of barriers, LCE(s) or incidental factor.

4.2.6 Clear and unambiguous definitions in the classification criteria

It was highlighted in the LOC Incident Analysis Project Review that some categories were missing clear, unambiguous definitions and should be further illustrated with examples. This would facilitate the act of codifying similar direct causes/RCS-POPMAR items under the same categories, improving overall consistency. An example of this limitation of the LOC report was given in the report review: if an organisation provided procedures but failed to ensure they were followed, then the incident was classified under ‘organising-control’. It was not possible to determine if the procedures were adequate or not by looking at the data once codified in SPSS.

Management delivery failure paths in Storybuilder are fully defined and illustrated in the supporting documentation, therefore consistency should improve. The previous example would be entered in Storybuilder as ‘Management Delivery System: Plans and Procedures’, ‘Tasks: monitor’ if the procedures were adequate but failed to ensure they were followed, and, alternatively, as ‘Management Delivery System: Plans and Procedures’, ‘Tasks: provide’ if the company failed to provide good plans and procedures regarding the failure of a barrier.

Categories are usually well defined under the rules, with descriptions and examples given in Storybuilder’s supporting documentation. These assist the user in consistently entering the data in the database. However, incident reports do not always match the LOC Storybuilder’s bow-tie structure as they have been produced identifying the relevant primary and secondary RCSs and POPMAR elements in the incident, and do not follow the barrier failure approach.

35

4.3 COMMENTS RAISED FROM STORYBUILDER EVALUATION

4.3.1 HID and RIDDOR incident report information

The underlying causes of accidents were available in the majority of HID and RIDDOR reports although these were not necessarily related to the WORM’s Barrier Failure framework.

Information that can be used to codify the Management Delivery failures associated with the failure of a barrier in an accident path were frequently not available, as in the alarm level failure example provided in section 3.1.1. Not all incident causes that are equivalent or related to a Barrier Failure in WORM are investigated up to Task and Management Delivery failure levels in HID and RIDDOR reports. This is a conclusion in line with the information collected in the report Accident Analysis using Storybuilder (Baksteen and Bellamy, 2007) (illustrated with overfilling accidents including Buncefield). Storybuilder again proved useful at generating targeted questions to assist in the investigations: in the example provided, Storybuilder codification of the incident would require information about the task and management failure behind the high-level alarm fault.

4.3.2 Dutch LOC bow-tie

Changes were needed to adapt the LHS and RHS of the bow-tie to LOC incident data. On the LHS of the bow-tie, these largely involved additional adapting the type of industry box to RIDDOR classification, and extra BFM boxes to codify situations not anticipated by WORM. Additional BFM boxes were labelled as ‘Others’. The reduced number of incidents codified in this exercise did not identify any potential type of BFM that could not be allocated to the categories given by WORM. LCE and Task and MDS failures were also adequate. The RHS required simplification of the structure: part of body injury code, type of injury code, hospitalisation, injury severity/duration and lost time were necessary for WORM to develop an ORM, but not available in HID RIDDOR reports.

4.3.3 Data analysis

The number of reports (32) codified in Storybuilder was too small to provide statistically meaningful information that could be compared to the data available from the LOC Incident Report 2003. A full-scale comparison exercise using the same pool of data is therefore needed.

Data stored in the modified Storybuilder LOC bow-tie can be easily accessed, extracted and exported to Excel using the tools embedded in the software. No significant limitations were identified, apart from those related to the reduced number of incident reports codified in the study.

36

5 CONCLUSIONS AND RECOMMENDATIONS

HSL staff were trained in the use of Storybuilder, the software tool developed by WORM to store and analyse incident information for the development of an occupational risk model. A preliminary assessment of the Dutch LOC bow-tie identified changes that could be made to adapt the RHS structure to information available in HID and RIDDOR reports.

Thirty-two RIDDOR and HID incident report were successfully entered into a modified Storybuilder LOC bow-tie. The codification exercise in Storybuilder’s LOC bow-tie highlighted the structural differences between the HSG65 criteria of policy, organisation, planning and implementation, measuring, audit and review (POPMAR) and WORM’s management and task delivery failure criteria. This resulted in a number of barrier failures for which management and task deliveries were unknown from the data collected in the incident report. Storybuilder LOC structure could therefore be used to generate targeted questions that would assist in incident investigations and subsequent data analysis.

In Storybuilder, the possibility of organising the incident causes as multiple loss of control events and barrier failures, each with its associated task and management delivery failures allows the user to store complex incident information, for instance when there have been multiple direct causes, risk control systems and POPMAR contributions involved. These had to be simplified to store information according to the methodology followed in the LOC Incident Report (2003).

Storybuilder LOC bow-tie can give a more accurate picture of the contribution of human error to LOC incidents. In the LOC Incident Report work, human error was only selected when it was the sole cause of the incident. Storybuilder LOC bow-tie does not require such simplification and the human error contribution to each barrier failure can be stored, for instance, as the task failure to ‘provide’ and the ‘competence’ management delivery failure. Moreover, human error when it was the sole cause of the incident is still accounted for as an independent barrier failure: ‘operator ability failure’.

Storybuilder’s supporting documentation provides clear definitions for the classification criteria that allow the user to consistently codify incident information. The need for subdivisions in the POPMAR framework classification highlighted in the LOC Incident Report Review would not be necessary, as these are embedded within the 29 LHS barrier failures and their individual task and management delivery system failures in the modified Storybuilder LOC bow-tie.

A method to extract incident information stored in Storybuilder was developed. The pool of incident reports codified in this feasibility study was, however, too small to extract definitive conclusions; the data set would need to be more populated to enable a full analysis and comparison exercise between the LOC Incident Report and Storybuilder.

37

6 REFERENCES

Ale B.J.M., Baksteen H., Bellamy L.J., Bloemhof A., Goossens L., Hale A., Mud M.L., Oh J.I.H, Papazoglou I.A., Post J., Whiston J.Y., 2008, Quantifying occupational risk: The development of an occupational risk model, Safety Science 46, 176-185.

Baksteen H., Mud M.L., Bellamy L.J., 2007, Accident analysis using Storybuilder: illustrated with overfilling incidents including Buncefield, Ministerie Sociale Zaken en Werkgelegenheid, available at http://www.emploi.belgique.be/defaultTab.aspx?id=13696 (accessed 8-02-2009).

Bellamy L.J., Ale B.J.M, Whiston J.Y., Mud M.L., Baksteen H., Hale A.R., Papazoglou I.A., Bloemhoff A., Damen M., Oh J.I.H., 2008, The software tool Storybuilder and the analysis of the horrible stories of occupational accidents, Safety Science 46, 186-197.

Bellamy L.J., Ale B.J.M, Geyer T.A.W., Goossens L., Hale A., Oh J.I.H, Mud M.L., Bloemhoff A., Papazoglou I.A., Whiston J.Y., 2007, Storybuilder – A tool for analysis of accident reports, Reliability Engineering and System Safety, 92, 735-744.

Collins A.M., Keely, D., 2003, Loss of Containment Incident Analysis, Health and Safety Laboratory report HSL/2003/07.

De Dianous V., Fiévez C., 2006, ARAMIS project: A more explicit demonstration of risk control trhough the use of bow-tie diagrams and the evaluation of safety barrier performance, Journal of Hazardous Materials, 130, 220-233.

Haddon Jr. W., 1973, Energy damage and the ten countermeasure strategies, Human Factors Journal 15 (4), 355-366.

HSE (2001) Successful Health and Safety Management. Health and Safety Series booklet HS(G)65. Suffolk:HSE books.

HSE, 1995, A guide to the reporting of injuries, diseases, and dangerous occurrences regulations (L73). Suffolk: HSE books.

National Institute for Public Health and the Environment, 2008, The quantification of occupational risk, the development of an risk assessment model and software, Report 62081001/2008, WORM Metamorphosis Consortium, the Netherlands.

Mud M.L., Bellamy L.J., 2008, Storybuilder user manual, programma Versterking Arbeidveiligheid, available at http://www.storybuilder.eu/catalog.htm (accessed 8-02-2009).

Storybuilder v2.0.34 (2008). White Queen BV, the Netherlands, available at http://www.storybuilder.eu/catalog.htm (accessed 8-02-2009).

Wattie K., 2005 (draft v4), Review of the Loss of Containment Incident Analysis Project, Health and Safety Executive

38

7 GLOSSARY

BFM Barrier Failure Mode

BSM Barrier Success Mode

ESAW European Statistics on Accidents at Work

LCE Loss of Control Event

LHS Left-hand Side of the bow-tie diagram

LOC Loss of Containment

MMI Man-machine Interface

ORM Occupational Risk Model

POPMAR Criteria of Policy, Organisation, Planning and Implementation, Measuring, Audit and Review

PSB Primary Safety Barrier

RIDDOR Reporting of Injuries, Diseases and Dangerous Occurrences Regulations

RHS Right-hand Side of the bow-tie diagram

RSC Risk Control System

SMS Safety Management System

SSB Support Safety Barrier

WORM Workgroup Occupational Risk Model

39

40

41

Published by the Health and Safety Executive 02/10

Feasibility of storybuilder software tool for major hazards intelligence

Health and Safety Executive

RR778

www.hse.gov.uk

The aim of this research was to investigate the feasibility of using the software tool Storybuilder version 2.0.34 (2008), developed by the Workgroup Occupational Risk Model (WORM) project in the Netherlands, for recording and analysing major hazards loss of containment (LOC) incident data as a tool to better understand how accidents happen and where prevention efforts should be focused. The ultimate aim of the project is to determine if Storybuilder can provide enhanced intelligence about major accident hazards and therefore allow better targeting of HSE intervention resources.

This report and the work it describes were funded by the Health and Safety Executive (HSE). Its contents, including any opinions and/or conclusions expressed, are those of the authors alone and do not necessarily reflect HSE policy.