BS en 62740. Root Cause Analysis (RCA). (Draft)

Responsible Committee Secretary: Mrs Phillippa Younas (BSI)Direct tel: 020 8996 7239E-mail: [email protected]

WARNING: THIS IS A DRAFT AND MUST NOT BE REGARDED OR USED AS A BRITISH STANDARD.THIS DRAFT IS NOT CURRENT BEYOND 9 April 2014

This draft is issued to allow comments from interested parties; all comments will be given consideration prior topublication. No acknowledgement will normally be sent. See overleaf for information on the submission ofcomments.

No copying is allowed, in any form, without prior written permission from BSI except as permitted under theCopyright, Designs and Patent Act 1988 or for circulation within a nominating organization for briefing purposes.Electronic circulation is limited to dissemination by e-mail within such an organization by committee members.

Further copies of this draft may be purchased from BSI Shop http://shop.bsigroup.comor from BSI Customer Services, Tel: +44(0) 20 8996 9001 or email [email protected], International and foreign standards are also available from BSI Customer Services.

Information on the co-operating organizations represented on the committees referenced above may be obtained fromhttp://standardsdevelopment.bsigroup.com

Latest date for receipt of comments: 9 April 2014 Project No. 2012/01932Responsible committee: DS/1 Dependability

Interested committees:

Date: 12 February 2014Origin: European

DPC: 14 / 30267079 DC

Form 36Draft for Public Comment

BSI Group Headquarters

389 Chiswick High Road London W4 4AL

Tel: +44 (0)20 8996 9000Fax: +44 (0)20 8996 7400www.bsigroup.com

Title: Draft BS EN 62740 Root Cause Analysis (RCA)

Please notify the secretary if you are aware of any keywords that might assist in classifying or identifying thestandard or if the content of this standard i) has any issues related to 3rd party IPR, patent or copyright ii) affects other national standard(s) iii) requires additional national guidance or information

IntroductionThis draft standard is based on European discussions in which the UK took an active part. Your comments on thisdraft are welcome and will assist in the preparation of the consequent British Standard. Comment is particularlywelcome on national legislative or similar deviations that may be necessary.

Even if this draft standard is not approved by the UK, if it receives the necessary support in Europe, the UK willbe obliged to publish the official English Language text unchanged as a British Standard and to withdraw anyconflicting standard.

UK VotePlease indicate whether you consider the UK should submit a negative (with reasons) or positive vote on this draft.

EXAMPLE ONLY

Microsoft and MS-DOS are registered trademarks, and Windows is a trademark of Microsoft Corporation.

Submission of Comments- The guidance given below is intended to ensure that all comments receive efficient and appropriate attention by the

responsible BSI committee. Annotated drafts are not acceptable and will be rejected.- All comments must be submitted, preferably electronically, to the Responsible Committee Secretary at the address

given on the front cover. Comments should be compatible with version 6.0 or version 97 of Microsoft Word forWindows, if possible; otherwise comments in ASCII text format are acceptable. Any comments not submittedelectronically should still adhere to these format requirements.

- All comments submitted should be presented as given in the example below. Further information on submittingcomments and how to obtain a blank electronic version of a comment form are available from the BSI website at:http://drafts.bsigroup.com/

Template for comments and secretariat observations Date: xx/xx/20xx Document: ISO/DIS xxxx

1 2 (3) 4 5 (6) (7)MB Clause No./ Subclause

No./Annex

(e.g. 3.1)

Paragraph/

Figure/

Table/Note

Type of com-

ment

Commend (justification for change) bythe MB

Proposed change by the MB Secretariat observations on each

comment submitted

3.1 Definition 1 ed Definition is ambiguous and needs

clarifying.

Amend to read '...so that the mains

connector to which no connection...'

6.4 Paragraph 2 te The use of the UV photometer as an

alternative cannot be supported as

serious problems have been encountered in

its use in the UK.

Delete reference to UV photometer.

56/1542/CDV

COMMITTEE DRAFT FOR VOTE (CDV) PROJET DE COMIT POUR VOTE (CDV)

Project number IEC 62740/Ed1 Numro de projet

IEC/TC or SC: TC 56

CEI/CE ou SC:

Secretariat / Secrtariat

UK

Submitted for parallel voting in CENELEC Soumis au vote parallle au CENELEC

Date of circulation Date de diffusion

2014-02-07

Closing date for voting (Voting mandatory for P-members) Date de clture du vote (Vote obligatoire pour les membres (P))

2014-05-09

Also of interest to the following committees Intresse galement les comits suivants

Supersedes document Remplace le document 56/1527/CD and 56/1540/CC

Proposed horizontal standard Norme horizontale suggre

Other TC/SCs are requested to indicate their interest, if any, in this CDV to the TC/SC secretary Les autres CE/SC sont requis dindiquer leur intrt, si ncessaire, dans ce CDV lintention du secrtaire du CE/SC

Functions concerned Fonctions concernes

Safety Scurit

EMC

CEM Environment

Environnement Quality assurance

Assurance qualit CE DOCUMENT EST TOUJOURS L'TUDE ET SUSCEPTIBLE DE

MODIFICATION. IL NE PEUT SERVIR DE RFRENCE.

LES RCIPIENDAIRES DU PRSENT DOCUMENT SONT INVITS

PRSENTER, AVEC LEURS OBSERVATIONS, LA NOTIFICATION DES

DROITS DE PROPRIT DONT ILS AURAIENT VENTUELLEMENT

CONNAISSANCE ET FOURNIR UNE DOCUMENTATION EXPLICATIVE.

THIS DOCUMENT IS STILL UNDER STUDY AND SUBJECT TO CHANGE. IT

SHOULD NOT BE USED FOR REFERENCE PURPOSES.

RECIPIENTS OF THIS DOCUMENT ARE INVITED TO SUBMIT, WITH THEIR

COMMENTS, NOTIFICATION OF ANY RELEVANT PATENT RIGHTS OF

WHICH THEY ARE AWARE AND TO PROVIDE SUPPORTING

DOCUMENTATION.

Title : IEC 62740/Ed1: Root Cause Analysis (RCA)

Introductory note

ATTENTION IEC CENELEC

PARALLEL VOTING The attention of IEC National Committees, members of CENELEC, is drawn to the fact that this Committee Draft for Vote

(CDV) for an International Standard is submitted for parallel voting. The CENELEC members are invited to vote through the CENELEC online voting system.

Copyright 2013 International Electrotechnical Commission, IEC . All rights reserved. It is

permitted to download this electronic file, to make a copy and to print out the content for the sole

purpose of preparing National Committee positions. You may not copy or "mirror" the file or

printed version of the document, or any part of it, for any other purpose without permission in

writing from IEC.

62740/Ed1/CDV IEC(E) 2

CONTENTS 1

2

FOREWORD ........................................................................................................................... 4 3

1 Scope .............................................................................................................................. 7 4

2 Normative references ...................................................................................................... 7 5

3 Terms and definitions ...................................................................................................... 7 6

4 Introduction to RCA ......................................................................................................... 9 7

5 The RCA process .......................................................................................................... 10 8

5.1 Overview.......................................................................................................... 10 9

5.2 Initiation ........................................................................................................... 10 10

5.3 Establishing facts ............................................................................................. 12 11

5.4 Analysis ........................................................................................................... 13 12

5.4.1 Description ..................................................................................... 13 13

5.4.2 The analysis team .......................................................................... 14 14

5.5 Validation ......................................................................................................... 15 15

5.6 Presentation of results ..................................................................................... 16 16

6 Selection of techniques for analysing causes ................................................................. 16 17

6.1 General ............................................................................................................ 16 18

6.2 Selection of analysis techniques ...................................................................... 17 19

6.3 Useful tools to assist RCA................................................................................ 17 20

Annex A (informative) Summary and criteria of commonly used RCA techniques ................. 19 21

A.1 General ............................................................................................................ 19 22

A.2 RCA techniques ............................................................................................... 19 23

A.3 Criteria ............................................................................................................. 20 24

Annex B (Informative) RCA models ...................................................................................... 23 25

B.1 General ............................................................................................................ 23 26

B.2 Barrier Analysis ............................................................................................... 23 27

B.3 Reasons Model (Swiss Cheese Model) ........................................................... 24 28

B.4 Systems models ............................................................................................... 25 29

B.5 Systems Theoretic Accident Model and Processes (STAMP) ........................... 25 30

Annex C (Informative) Detailed description of RCA techniques ............................................ 27 31

C.1 General ............................................................................................................ 27 32

C.2 Events and Causal Factors (ECF) Charting ...................................................... 27 33

C.3 Multilinear Events Sequencing (MES) and Sequentially Timed Events 34 Plotting (STEP) ................................................................................................ 28 35

C.4 The Why method ............................................................................................ 31 36

C.5 Causes Tree Method (CTM) ............................................................................. 32 37

C.6 Why-Because Analysis (WBA) ......................................................................... 35 38

C.7 Fault Tree and Success Tree Method ............................................................... 38 39

C.8 Fishbone or Ishikawa Diagram ......................................................................... 40 40

C.9 Safety through Organisational Learning (SOL) ................................................. 42 41

C.10 Management Oversight and Risk Tree (MORT) ................................................ 43 42

C.11 AcciMaps ......................................................................................................... 45 43

C.12 Tripod Beta ...................................................................................................... 47 44

C.13 Casual Analysis using STAMP (CAST) ............................................................. 49 45

Annex D (Informative) Useful tools to assist RCA ................................................................ 53 46


D.1 General ............................................................................................................ 53 47

D.2 Data mining and clustering techniques ............................................................. 53 48

Annex E (Informative) Analysis of human performance ........................................................ 55 49

E.1 General ............................................................................................................ 55 50

E.2 Technique for Retrospective and Predictive Analysis of Cognitive Errors 51 (TRACEr) ......................................................................................................... 56 52

E.3 Human Factors Analysis and Classification Scheme (HFACS) ......................... 58 53

54

Figure 1 RCA process ........................................................................................................ 10 55

Figure B.1 Broken, ineffective and missing barriers causing the focus event ...................... 23 56

Figure C.1 Example of an ECF chart .................................................................................. 27 57

Figure C.2 Data in an event building block ......................................................................... 29 58

Figure C.3 Example of a Time-Actor Matrix ........................................................................ 30 59

Figure C.4 Example of a Why Tree .................................................................................... 31 60

Figure C.5 Symbols and links used in CTM ........................................................................ 33 61

Figure C.6 Example of a Cause Tree ................................................................................. 34 62

Figure C.7 Example of a WBG ........................................................................................... 37 63

Figure C.8 Example of a Fault Tree during the analysis ..................................................... 39 64

Figure C.9 Example of a Fishbone diagram ........................................................................ 41 65

Figure C.10 Example of a MORT diagram .......................................................................... 44 66

Figure C.11 Example of an AcciMap .................................................................................. 46 67

Figure C.12 Example of a Tripod Beta tree diagram ........................................................... 48 68

Figure C.13 Control structure for the water supply in Walkerton, Canada. .......................... 50 69

Figure C.14 Example CAST causal analysis for the local Department of Health ................. 50 70

Figure C.15 Example CAST causal analysis for the local public utilit y operations 71 management ......................................................................................................................... 51 72

Figure E.1 Example of an TRACEr Model [23] .................................................................... 56 73

Figure E.2 Generation of Internal Error modes ................................................................... 57 74

Figure E.3 Level 1 Unsafe Acts .......................................................................................... 59 75

Figure E.4 Level 2 Preconditions ....................................................................................... 59 76

Figure E.5 Level 3 Supervision Issues ............................................................................... 60 77

Figure E.6 Level 4 Organisational Issues ........................................................................... 60 78

79

Table 1 Steps to RCA ........................................................................................................ 10 80

Table A.1 Brief description of RCA techniques ................................................................... 19 81

Table A.2 Summary of RCA technique criteria.................................................................... 20 82

Table A.3 Attributes of the generic RCA techniques ........................................................... 22 83

Table B.1 Examples of barriers .......................................................................................... 24 84

Table B.2 Example Barrier Analysis Worksheet .................................................................. 24 85

Table C.1 Direct and indirect causal factors ....................................................................... 43 86

Table E.1 External Error Modes ......................................................................................... 58 87

Table E.2 Psychological Error Mechanisms ........................................................................ 58 88

89


90

91

INTERNATIONAL ELECTROTECHNICAL COMMISSION 92

____________ 93

94 ROOT CAUSE ANALYSIS (RCA) 95

96 97 98

FOREWORD 99

1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising 100 all national electrotechnical committees (IEC National Committees). The object of IEC is to promote 101 international co-operation on all questions concerning standardization in the electrical and electronic fields. To 102 this end and in addition to other activities, IEC publishes International Standards, Technical Specifications, 103 Technical Reports, Publicly Available Specifications (PAS ) and Guides (hereafter referred to as IEC 104 Publication(s)). Their preparation is entrusted to technical committees; any IEC National Committee interested 105 in the subject dealt with may participate in this preparatory work. International, governmental and non-106 governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely 107 with the International Organization for Standardization (ISO) in accordance with conditions determined by 108 agreement between the two organizations. 109

2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international 110 consensus of opinion on the relevant subjects since each technical committee has representation from all 111 interested IEC National Committees. 112

3) IEC Publications have the form of recommendations for international use and are accepted by IEC National 113 Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC 114 Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any 115 misinterpretation by any end user. 116

4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications 117 transparently to the maximum extent possible in their national and regional publications. Any divergence 118 between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in 119 the latter. 120

5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity 121 assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any 122 services carried out by independent certification bodies. 123

6) All users should ensure that they have the latest edition of this publication. 124

7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and 125 members of its technical committees and IEC National Committees for any personal injury, property dama ge or 126 other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and 127 expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC 128 Publications. 129

8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is 130 indispensable for the correct application of this publication. 131

9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of 132 patent rights. IEC shall not be held responsible for identifying any or all such patent rights. 133

International Standard IEC 62740 has been prepared by IEC technical committee 56: 134 Dependability. 135

The text of this standard is based on the following documents: 136

FDIS Report on voting

XX/XX/FDIS XX/XX/RVD

137 Full information on the voting for the approval of this standard can be found in the report on 138 voting indicated in the above table. 139

This publication has been drafted in accordance with the ISO/IEC D irectives, Part 2. 140


The committee has decided that the contents of this publication will remain unchanged until 141 the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data 142 related to the specific publication. At this date, the publication will be 143

reconfirmed, 144

withdrawn, 145

replaced by a revised edition, or 146

amended. 147

148

The National Committees are requested to note that for this publication the stability date 149 is 2018 150

THIS TEXT IS INCLUDED FOR THE INFORMATION OF THE NATIONAL COMMITTEES AND WILL BE 151 DELETED AT THE PUBLICATION STAGE. 152

153

154


155

INTRODUCTION 156

Root Cause Analysis (RCA) refers to any systematic process that identifies factors that 157 contributed to a particular event of interest (focus event). RCA aims to reveal root causes so 158 that either the likelihood of them occurring or their impact if they do occur can be changed. 159 RCA is performed with the understanding that events are addressed by understanding the 160 root causes, rather than the immediately obvious symptoms. 161

RCA is used to analyse the root causes of focus events with both positive and negative 162 outcomes, but it is most commonly used for the analysis of failures and incidents. Causes for 163 such events can be varied in nature, including design, processes and techniques, 164 organisational characteristics, human aspects and external events. RCA can be used for 165 investigating the causes of non-conformances in quality (and other) management systems as 166 well as for failure analysis. 167

An important distinction to make is that RCA is used to analyse a focus event that has 168 occurred and therefore analyses the past (a posteriori). However, knowledge of the root 169 causes of past events can lead to actions that generate improvements in the future. 170

This standard is intended to reflect current good pract ices in the conduct of RCA. This 171 standard is general in nature, so that it may give guidance across many industries and 172 situations. There may be industry specific standards in existence that establish preferred 173 methodologies for particular applications. If these standards are in harmony with this 174 publication, the industry standards will generally be sufficient. 175

This international standard is a generic standard and does not explicitly address safety or 176 accident investigation although the methods described in this standard may be used for this 177 purpose. 178

179


180

ROOT CAUSE ANALYSIS 181

1 Scope 182

This International Standard describes the basic principles of Root Cause Analysis (RCA) and 183 specifies the steps that a process for RCA should include. 184

This International Standard identifies a number of attributes for RCA techniques which assist 185 with the selection of an appropriate technique. It describes each RCA technique and its 186 relative strengths and weaknesses. 187

RCA is used to analyse focus events that have occurred, therefore this International Standard 188 only covers a posteriori analyses. It is recognised that some of the RCA techniques with 189 adaptation could be used proactively in the design and development of items and for causal 190 analysis during risk assessment; however, this International Standard focuses on the analysis 191 of events which have occurred. 192

The intent of this International Standard is to explain the techniques to identify root causes. 193 These techniques are not designed to assign responsibility or liability, which is outside the 194 scope of this International Standard. 195

2 Normative references 196

The following documents, in whole or in part, are normatively referenced in this document and 197 are indispensable for its application. For dated references, only the edition cited applies. For 198 undated references, the latest edition of the referenced document (including any 199 amendments) applies. 200

IEC 60050-191, International Electrotechnical Vocabulary Part 191: Dependability, 201 Terminology 202

3 Terms and definitions 203

For the purposes of this document, the definitions given in IEC 60050-191 and the following 204 apply. 205

3.1 206 cause 207 set of circumstances that leads to failure or success 208

Note 1 to entry: A cause may originate during specification, design, manufacture, installation, operation or 209 maintenance. 210

[SOURCE: IEC 60050-191, definition 191-43-11 modified to relate to failure or success] 211

3.2 212 causal factor 213 condition, action, event or state that produced or contributed to the occurrence of the focus 214 event 215

3.3 216 contributory factor 217 a causal factor regarded as secondary, according to an explicitly-given prioritisation of causal 218 factors 219

3.4 220 direct cause 221 immediate cause where there is no other cause between the direct cause and the focus event 222

Note 1 to entry: There may be more than one direct causal factor. 223


3.5 224 event 225 occurrence or change of a particular set of circumstances 226

Note 1 to entry: An event can be one or more occurrences, and can have several causes. 227

Note 2 to entry: An event can consist of something not happening. 228

Note 3 to entry: An event can sometimes be referred to as an incident or accident. 229

[SOURCE: ISO Guide 73 2009 [1]] 230

3.6 231 failure (of an item) 232 loss of ability to perform as required 233

Note 1 to entry: When the loss of ability is caused by a pre-existing latent fault, the failure occurs when a particular 234 set of circumstances is encountered. 235

Note 2 to entry: A failure of an item is an event that results in a fault state of that item. 236

Note 3 to entry: Qualifiers, such as catastrophic, critical, major, minor, marginal and insignificant, may be used to 237 categorize failures according to the severity of consequences, the choice and definitions of severity criteria 238 depending upon the field of application. 239

Note 4 to entry: Qualifiers, such as misuse, mishandling and weakness, may be used to categorize failures 240 according to the cause of failure. 241

[SOURCE: IEC 60050-191, definition 191-43-01] 242

Note 5 to entry: This is failure of an item, not more generally of behaviour. 243

3.7 244 failure mechanism 245 process that leads to failure 246

Note 1 to entry: The process may be physical, chemical, logical, psychological or a combination thereof. 247

[SOURCE: IEC 60050-191, definition 191-43-12 modified psychological added] 248

3.8 249 focus event 250 event which the RCA is intended to explain causally 251

3.9 252 necessary causal factor (of an event or state) 253 condition, action, event or state, that resulted in the given event or state, without which the 254 given event or state would not have occurred 255

3.10 256 human error 257 discrepancy between the human action taken or omitted, and that intended or required 258

Note 1 to entry: Ed.1 of IEC 60050-191 identified mistake as a synonym for human error, but a mistake is a type 259 of human error. 260


3.11 262 item 263 subject being considered 264

Note 1 to entry: The item may be an individual part, component, device, functional unit, equipment, subsystem, or 265 system. 266

Note 2 to entry: The item may consist of hardware, software, people or any combination thereof. 267

Note 3 to entry: The item is often comprised of elements that may each be individually considered . 268


3.12 270 root cause 271 type of cause with no predecessor that is relevant for the purpose of the analysis 272


Note 1 to entry: A focus event normally has more than one root cause. 273

Note 2 to entry: In some languages the term root cause refers to the combination of causes which have no causal 274 predecessor (a cut set of causes). 275

3.13 276 Root Cause Analysis 277 RCA 278 systematic process to identify the causes of a focus event 279

Note 1 to entry: IEC 60050-191, definition 191-52-05 provides the following more restrictive definition systematic 280 process to identify the cause of a fault, failure or undesired event, so it can be removed by design, process or 281 procedure changes. This standard uses an extended definition to allow a wider applicability of the process. 282

3.14 283 stakeholder 284 person or organisation that can affect, be affected by, or perceive themselves to be affected 285 by a decision or activity 286

[SOURCE: IEC 60300-1, definition 3.1.17 [2]] 287

3.15 288 stopping rule 289 a reasoned and explicit means of determining when a necessary causal factor is defined as 290 being a root cause 291

4 Introduction to RCA 292

RCA refers to any systematic process that identifies the cause or causes that contribute to a 293 focus event. The immediate or obvious cause of a focus event is often a symptom of 294 underlying causes and may not truly identify the root cause or causes that should be identified 295 and addressed. RCA provides a greater understanding about why events have occurred. RCA 296 may identify the following: 297

single root cause; 298

multiple root causes in which the elimination of any cause will prevent the focus event 299 from occurring; 300

root causes which are causal factors where elimination will change the likelihood of the 301 focus event occurring but may not directly prevent it; 302

root causes of successes. 303

By addressing the root cause or causes it is possible to make decisions regarding appropriate 304 actions that will generate better outcomes in the future; implementing appropriate actions 305 based on RCA are more effective at preventing the same or similar events with negative 306 outcomes occurring or increasing the probability of repeating events with positive outcomes, 307 when compared with just addressing the direct cause. 308

RCA can be applied to any focus event whether success or failure, for example: 309

investigation for technological, medical and occupational focus events; 310

failure analysis of technological systems, to determine why an item failed to perform as 311 and when required; 312

analysis of quality control and business processes; 313

analysis of successful outcomes. 314

RCA can be carried out at various levels of decomposition for example from system to 315 component level or by selecting different events or outcomes as a starting point. The level 316 appropriate to conduct the analysis will be dependent on the focus event. 317

RCA is used to analyse focus events which have actually occurred and is therefore applicable 318 during the testing and operational phases of a project or product life cycle. 319

62740/Ed1/CDV IEC(E) 10

The benefits of performing RCA include: 320

obtaining a greater understanding into what has happened; 321

finding the source of problems so corrective action can prevent future events; 322

identifying the causes of events with beneficial outcomes so they can be repeated; 323

identifying more effective actions to address the causes of focus events; 324

achieving the objectives of focus event investigations more effectively; 325

supporting traceability between focus event investigation evidence and conclusions; 326

increasing consistency between investigations of similar focus events; 327

increasing objectivity of focus event analysis. 328

5 The RCA process 329

5.1 Overview 330

To be effective RCA should be performed systematically as an investigation, with the root 331 causes and conclusions backed up by documented evidence. To achieve this, RCA should 332 include the five steps shown in Table 1 and illustrated in Figure 1. 333

Table 1 Steps to RCA 334

Step Concepts and tasks to be performed

Initiation Determine the need to carry out RCA and define the purpose and scope

Establishing Facts Collect data and establish the facts of what happened, where, when and who

Analysis Use RCA tools and techniques to ascertain how and why the focus event occurred

Validation Distinguish and resolve the different possibilities as to how and why the focus event was caused

Presentation of Results

Present the results of the focus event analysis

RCA is iterative in nature especially the data collection and analysis , in that data is collected 335 on what happened, which is then analysed in order to determine what ot her data needs to be 336 collected. Once gathered, further analysis is conducted and any gaps identified, for which 337 further data is collected. This process is repeated until the purpose of the analysis is fulfilled 338 and the root causes identified. The outputs of the RCA will be dependent on the purpose and 339 scope. 340

Establish

the need,

purpose &

scope

Immediate

Facts

Step 1: Initiation

What,

Where,

When &

Who

Data

Collection

Step 2: Establishing Facts

How and why

(identify

potential

causes)

Application of

specific tools

Step 3: Analysis

Potential

causes

distinguished

and resolved

Further data

and testing

Step 4: Validation

Outputs

Step 5: Presentation

of Results

341

Figure 1 RCA process 342

5.2 Initiation 343

The first step initiates the RCA process by evaluating the need to carry out RCA. It defines 344 the purpose and scope of the analysis, in response to the focus event, and establishes a team 345 and resources to carry out the RCA. 346

62740/Ed1/CDV IEC(E) 11

There is usually some criterion which is used to determine when an RCA is required, which 347 may include: 348

any single event with a large effect; 349

multiple similar undesirable events; 350

a parameter moving out of a defined tolerance level; 351

failures or successes (whatever the level of effect) that involve critical items of equipment 352 or activities. 353

When defining the type of events that require the conduct of RCA, it is important to consider 354 that an event with a large effect may have common root causes to events with minor effects. 355 Analysing and addressing root causes for events with minor effects may prevent a large effect 356 event occurring. Examples of events where RCA may be required include: completion of a 357 project (successes and failures), failures that result in unacceptable costs, injury or fatality, 358 unacceptable performance or delays, large contractual consequences, and equipment 359 breakdown. 360

If a RCA is required, the focus event(s) to be analysed is/are described and an appropriate 361 team appointed for the analysis. The description should include the background and context 362 in which the focus event(s) occurred. A good description of a focus event is short, simple, and 363 easy to understand and should not be biased towards a specific solution. This description is 364 used to identify appropriate members of the analysis team and ascertain where to start 365 collecting data. 366

The purpose and scope of the RCA should be determined taking into account knowledge of 367 system, functions, interfaces etc. In some cases the purpose of the analysis is to iden tify the 368 causes of the focus event, in others the purpose may be broader. For example, to also 369 identify matters of concern outside those that led to the focus event. 370

There are in general two different types of RCA that have different objectives and should not 371 be mixed up. These two types can be described as follows: 372

analysis of an observed focus event from other observed events; 373

analysis of an observed focus events from potential events, not actually observed. 374

The first version focuses on observed facts only. It may be an analysis "per se" according to 375 the purpose of the study and no hypothesis about event occurrence is acceptable for this 376 analysis. The second version focuses on potential (non-observed) events which may have led 377 to the actually observed focus event. It can be implemented when more facts are needed and 378 the use of hypothesis on the occurrence of events is acceptable for this analysis. 379

The outputs required of the RCA should also be identified, examples are as follows: 380

provide a description of each root cause along with sufficient background information to 381 allow the identification of suitable actions; 382

recommend actions that, taken together, prevent further occurrences of similar events with 383 adverse consequences and improve the likelihood of successes; 384

identify, implement and review actions to address root causes. 385

RCA can include the analysis of open systems (systems which continuously interact with their 386 environment); this interaction can take the form of information, energy, or material transfer . 387 Therefore, the scope should specify the boundary of the analysis (what is included and what 388 is excluded). 389

The scope of the analysis should where possible include a definition of the stopping rule , 390 which is the point at which action can be defined or additional proof of cause is no longer 391 necessary for the purpose of the analysis. For example the last point where corrective action 392 can be identified, before factors that cannot be influenced e.g. weather. It may however be 393

62740/Ed1/CDV IEC(E) 12

more appropriate to ascertain the stopping rule at review points that determine whether 394 further analysis is required. 395

The team members for the analysis should be selected based on the specific expertise 396 needed to analyse the focus event. The team should include: 397

a person or persons who between them can provide a complete systems overview and 398 knowledge of the programme or project and focus event; 399

a facilitator skilled in the causal analysis technique, desirably trained or experienced in the 400 facilitation of the causal analysis technique; 401

at least one member experienced in the causal analysis technique being applied. 402

Team members can change depending on the activity being conducted e.g. team members 403 responsible for data collection will not necessarily be the same as those conducting the 404 analysis. Team members can include engineers, technicians, operators, sales 405 representatives, managers etc. The use of external parties should be considered to provide 406 an independent perspective and avoid blind spots that may exist in the organisation. 407 Additional team members should be included for specific activities during the investigation to 408 either bring expertise into the team or to increase the influence of the team. The role of these 409 additional team members is to support the investigation so that it is not halted for technical or 410 organisational boundary reasons. It is not appropriate for persons who may have had a role in 411 causation of the focus event to be part of the team. Their input should be collected during the 412 first two steps. 413

RCA can be effectively carried out by one person provided that person is experienced with the 414 causal analysis technique, is a domain expert (or has immediate access to domain experts) 415 and has access to all the data required. However, it is more common to conduct RCA as a 416 team. 417

5.3 Establishing facts 418

This step includes all the activities necessary to prepare for the analysis. Establishing the 419 facts is usually the largest part of the RCA. Facts should be determined on what happened, 420 where, when and by whom. 421

Data should be collected, before it is lost (e.g. before evidence is disturbed or removed, or 422 memories fade). Data should aim to identify: 423

the context in which the focus event occurred; 424

the conditions before, during, and after the focus event; 425

personnel involvement including actions taken (or not taken) and decisions made; 426

context data about the surroundings, including environmental data ; 427

how the organisation operates including organisation charts, processes and procedures, 428 training and skills data; 429

historical data relating to similar events or precursors; 430

deviations from the expected; 431

interactions with other items and personnel; 432

equipment involved and its operating state. 433

The following lists examples of data that may be relevant. 434

Inspection of physical evidence such as failed components and failure reports. Generally, 435 it is experience that will determine what physical evidence is required. If there is doubt, 436 the evidence should be retained, it is also important to preserve the evidence. 437

Photographs and videos taken by monitoring cameras. Photographing the area of the 438 occurrence from several views will also be useful in the analysis phase. 439

62740/Ed1/CDV IEC(E) 13

Operational data, recorded by monitoring systems, control systems, alarm and event 440 loggers etc. Operator logs can be critical to understanding the operating conditions at the 441 time of failure and since they are typically dated, they are ideal for generating a timeline of 442 events. 443

Personal testimony gathered by conducting interviews. Interviews should concentrate on 444 data collection e.g. building a consistent timeline etc; any premature discussion of the 445 causes of the failure may adversely impact the interview process. Questions should 446 be prepared before the interview to ensure that all necessary information is obtained. 447 Interviews should be conducted with those people, who are most familiar with the focus 448 event, however, consider interviewing other personnel e.g. people who have performed 449 the job in the past. All interviews should be documented. 450

Documentary evidence of relevant procedures, operating environment and regulatory 451 environment. 452

Once all the data associated with the focus event has been collected, the data should be 453 reviewed for correctness and suitability, missing data should be obtained and any 454 inconsistencies should be resolved to ensure a clear and consistent picture of the focus event 455 is determined. 456

This step can include failure analysis which examines failed components using a wide array of 457 methods including microscopy, spectroscopy and Non-Destructive Testing or models on the 458 development of failure such as fire modelling or crash modelling. 459

The outcome of this step is information and understanding, supported by physical evidence 460 and witness statements, concerning: 461

what happened including the circumstances that lead to the focus event; 462

the time sequence of events which lead to the focus event; 463

the location of the focus event; 464

actions of people associated with the focus event; 465

any necessary conditions for the focus event; 466

the consequences of the focus event. 467

5.4 Analysis 468

5.4.1 Description 469

Having determined what happened, where, when and by whom, this step establishes 470 how and why the focus event occurred. The objective of this step is to understand the focus 471 event and its causes by structuring the data that has been collected into a form that allows 472 root causes to be systematically derived. 473

RCA normally analyses facts to identify the causal factors that were necessary for the focus 474 event to occur. However in some cases, for example where sufficient facts are not available, 475 the analysis may propose one or more hypotheses for cause and may also identify 476 contributing factors and prevailing conditions which were possibly associated with the focus 477 event, but cannot be proven to be necessary causes. 478

Analysis involves the following. 479

Organising the physical evidence and witness statements concerning actions, events, 480 conditions and outcomes. 481

Seeking how and why the focus event occurred using the data collected to justify 482 conclusions. Models of causation, laboratory testing, check lists and taxonomies or 483 statistical analysis of data may be used to assist this process. 484

Looking beyond direct causes to why those causes occurred. The aim is to seek all factors 485 (and conditions) that contributed, not only the immediate or obvious causes. 486

62740/Ed1/CDV IEC(E) 14

Continuing this process until the stopping rule is invoked and root causes identified. There 487 may be multiple root causes which can be independent or inter related. 488

In general causes may involve technical issues, human aspects and factors relating to the 489 physical or psycho-social environment in which the focus event occurred. All of these should 490 be considered in seeking root causes. People with expertise in these areas should therefore 491 be involved in the analysis. 492

Causes should be described clearly and unambiguously. Where a human action, omission or 493 decision is identified as a cause, the nature of the act or decision should be specified e.g. the 494 operator switched off the wrong power switch and not the human error. 495

The analysis of cause (depending on the purpose and scope of the analysis) can consider: 496

how the focus event occurred i.e. the physical chemical psychological or logical process 497 that was involved; 498

preceding events or conditions that were necessary to the focus event occurring; 499

relationships between causal factors including how they combined to cause the focus 500 event and how a root cause leads to the focus event; 501

organisational and management influences and human factors that were involved in the 502 focus event or in the events and conditions leading up to it; 503

prevailing conditions that may have contributed to the event occurring but were not 504 necessary causes; 505

matters of concern that could lead to other focus events (these are not strictly causes but 506 may be an outcome of the analysis). 507

A structured analysis technique should be used to perform the analysis. Several formal 508 techniques exist ranging from those that are based on a checklist of causes to techniques that 509 guide the analyst through consideration of causes and graphically present the results. The 510 techniques range from simple to complex and require suitably skilled practitioners or 511 facilitators to conduct the analysis. Some techniques are based on particular models of how a 512 focus event occurs and hence give a particular emphasis to the results. The different models 513 are based on different hypotheses with regard to the causation therefore they tend to lead the 514 investigator to identify different contributory factors. 515

In some cases it is appropriate to use more than one technique or take into account 516 considerations of more than one model to identify all root causes. 517

Models of causation are described in Annex B and analysis techniques are described in 518 Annex C. The most appropriate technique will be dependent on the focus event and the 519 purpose and scope of the analysis (see clause 6). 520

The analysis may indicate that further data is required. Requests for such data should be 521 expected to occur throughout the analysis to resolve inconsistencies or complete gaps in the 522 analysis. The analysis should continue until a stopping rule is invoked. 523

5.4.2 The analysis team 524

A leader should be appointed for the analysis step, who is responsible for the following 525 preparatory work. 526

Obtaining copies of the agreed role and responsibilities of the team, and purpose and 527 scope of the analysis. 528

Obtaining copies of the focus event description and the facts established. 529

Deciding the analysis technique(s) to be used. 530

Converting the focus event description and facts established into a suitable format for use 531 in the analysis technique selected. 532

Developing an analysis plan. 533

62740/Ed1/CDV IEC(E) 15

Forming the analysis team. 534

Facilitating or arranging for training of team members in the analysis technique selected. 535

Selecting software tools or other templates for use during the analysis . 536

Arranging for a search to be made of databases, media, legal proceedings etc. to identify 537 focus events of a similar nature, or which may have occurred with the same or similar 538 technologies. 539

The leader should review the information available to determine what analysis technique(s) 540 should be applied and what skills are required. Expert advice in the field of RCA may need to 541 be obtained regarding the selection of the analysis technique. The leader may also require an 542 expert RCA facilitator for all or part of the analysis, depending on the complexity o f the focus 543 event, the complexity or volume of evidence and data or analysis technique selected. 544

The analysis is usually carried out by a team, with each team member being chosen for their 545 experience and skills. The analysis team should be as small as possible, consistent with the 546 relevant technical and operating skills and experience being available. Where input will be 547 required from multiple parties, stakeholders or entities, the analysis team should contain 548 representatives of each. It is the leaders responsibility to ensure the relevant stakeholders are 549 informed, so that adequate stakeholder representation is available during the analysis. 550

The role and responsibilities of the analysis team members should be determined and 551 milestones established at the outset of the analysis. A programme of meetings should be 552 developed, which reflects the objectives and milestones provided to the analysis team. This 553 will ultimately enable any recommendations to be carried out in a timely fashion. 554

The leader should develop an analysis plan, which should contain the following: 555

focus event description; 556

agreed roles and responsibilities of the team, and the purpose and scope of the analysis; 557

a list of team members and the stakeholders to be represented; 558

time, date and location of the analysis meetings; 559

a summary of the data available; 560

analysis technique(s) to be used; 561

arrangements for training the analysis team in the selected analysis technique (if 562 required); 563

the form of recording of the analysis and the analysis results, including reference to any 564 templates or software tools to be used. 565

Adequate room facilities with visual and recording aids should be arranged by the leader for 566 the efficient conduct of the analysis meetings. A briefing package consisting of the analysis 567 plan and any essential pre-meeting reading or references should be sent to the analysis team 568 members in advance of the first meeting, to allow them to familiarise themselves with the 569 information available and the selected analysis technique. At the first analysis meeting a 570 physical review of the focus event via a re-enactment, mock-up, computer simulation or scale 571 model is desirable. 572

The leader should ensure that an appropriate communication system is in place for informing 573 and transferring the results of the analysis to those responsible for the next step of the RCA 574 process (see 5.5). 575

5.5 Validation 576

A number of review activities are conducted throughout the RCA process to determine 577 whether data collected is relevant and the analysis is representative of the data collected. 578 This step tests whether the causes identified in the analysis can be substantiated and may be 579 interleaved with the analysis or conducted as a separate activity . 580

62740/Ed1/CDV IEC(E) 16

An independent review can be carried out to assess whether the analysis is complete and 581 correct and to determine whether the purpose of the analysis has been fulfilled. The review 582 method will be dependent on the analysis technique used and on the focus event. In some 583 cases experiments can be performed to repeat the occurrence of the focus event, where 584 appropriate statistical methods should be used to assess the degree of confirmation of the 585 hypothesis of cause. If the causes are validated with the help of simulation, care should be 586 taken to ensure that the simulation is true in the casually-relevant respects. 587

During the analysis there may be several alternative hypothesis of how the event could have 588 happened, at the completion of the analysis the causes should be validated and only a single 589 hypothesis should remain. 590

This step may require further data collection to seek direct evidence to support or refute the 591 causes identified. Evidence may not always be available to fully validate all potential causes. 592

5.6 Presentation of results 593

The results of the analysis will depend on the purpose of the analysis. For example, if the 594 purpose of the analysis is to identify actions that, taken together, prevent further occurrences 595 of similar events, the analysis results should identify corrective actions which break the causal 596 network and prevent the focus event occurring again. If the purpose of the analysis is to 597 repeat successes, then actions that enhance the likelihood or the consequences of the focus 598 event should be proposed. The effectiveness of the analysis results is dependent on the 599 quality of the analysis. 600

An agreed format for presenting the results of the RCA should be developed that summarises 601 the analysis and captures the required outcomes from the analysis e.g. recommended 602 actions. If recommended actions are the required outcome from the RCA, the summary should 603 include the following as a minimum: 604

a general description of each cause and contributory environmental conditions requiring 605 action along with sufficient background information and detail to allow those who will make 606 recommendations and implement them to be able to understand the need to address each 607 cause and justify actions to be taken; 608

a set of options for treatment actions, and where practicable and within scope a summary 609 of the benefits and costs of each; 610

recommended actions to address each of the causes identified. 611

Recommended corrective actions should be evaluated for effectiveness and realism. In 612 general corrective actions aim to achieve the following: 613

change the likelihood of the focus event and/or its consequences (i.e. reduce the 614 likelihood or consequence of undesirable events or increase the likelihood or consequence 615 of successful events); 616

not introduce new unacceptable risks e.g. the safety of other systems must not be 617 degraded by the proposed corrective action. 618

Where actions are identified they should be reviewed prior to implementation to determine 619 whether they have not only addressed the root causes, but also not introduced new 620 unexpected consequences and will therefore function as intended. Also reoccurrence of the 621 same or similar event should be monitored. If an unexpected occurrence reoccurs, the original 622 focus event should be re-evaluated to determine why actions were not effective. 623

6 Selection of techniques for analysing causes 624

6.1 General 625

Formal techniques have been devised to help analysts identify causes and eventually root 626 causes. Analysis techniques may perform one or more of the following functions: 627

organise data and provide structure to the analysis and identify where further evidence is 628 needed; 629

62740/Ed1/CDV IEC(E) 17

provide a visual display of the evidence relating to the focus event for example the time 630 sequence of events or causal chains; 631

conduct statistical analysis of the data, particularly from multiple similar events, to identify 632 common causes; 633

provide guidance to identify possible causes for further investigation and comparison with 634 data (such methods include check lists and methods based on models of causation ); 635

guide the analysts through multiple levels of cause to a set of root causes. 636

6.2 Selection of analysis techniques 637

RCA is undertaken in varying degrees of depth and may use one or several analysis 638 techniques ranging from simple to complex. The depth of the analysis and technique(s) used 639 should exhibit the following characteristics: 640

be justifiable and appropriate to the focus event under analysis and the scope and 641 purpose of the analysis; 642

provide results that enhance the understanding of the root causes of the focus event; 643

be capable of use in a manner that is traceable, repeatable and verifiable. 644

The analysis techniques to be used are selected based on the applicable factors such as: 645

characteristics of the analysis technique; 646

characteristics of the focus event e.g. severity or potential severity or complexity; 647

characteristics of the organisation e.g. industry/sector approved techniques or cost benefit 648 evaluation; 649

purpose of the analysis e.g. outputs required or stakeholder expectations ; 650

the causation model or models most appropriate to the objectives of the analysis . 651

The attributes of the most commonly used analysis techniques are described at Annex A. The 652 criteria used to characterise the techniques, described in Annex A, are as follows: 653

expertise required; 654

tool support; 655

scalability; 656

graphical representation; 657

modularity; 658

reproducibility; 659

plausibility checks; 660

intellectual rigour; 661

time sequence; 662

specificity. 663

The analysis techniques are described in Annex C, which includes the methods and process 664 used for each technique along with their strengths and weaknesses. 665

6.3 Useful tools to assist RCA 666

Modern data mining techniques enable a search for specific properties and conditions. 667 Clustering analysis selects data that are closely related, and thereby identify deviating data 668 (outliers). Modern cluster analysis can detect data that are closely related in one, two or more 669 dimensions and thereby analyse products or processes that are closely related and identify 670 deviating data points (outliers). An overview of these techniques is provided in Annex D. 671

62740/Ed1/CDV IEC(E) 18

Many focus events and analysis techniques involve human factors and several taxonomies 672 have been developed to assist in finding root causes where human behaviour is involved. Two 673 examples are given in Annex E. 674

62740/Ed1/CDV IEC(E) 19

Annex A 675 (informative) 676

677 Summary and criteria of commonly used RCA techniques 678

A.1 General 679

This Annex lists the most commonly used RCA techniques, with a brief description, and 680 provides a reference list of criteria which can be used to compare different RCA techniques. 681 The list is not comprehensive but covers examples of the different types of techniques used. 682

A.2 RCA techniques 683

Table A.1 provides a list and brief description of the most commonly used RCA techniques. 684

Table A.1 Brief description of RCA techniques 685

Technique Description

Events and Causal Factors (ECF) Charting

ECF analysis identifies the time sequence of a series of tasks and/or actions and the surrounding conditions leading to a focus event. These are displayed in a cause-effects diagram.

Multilinear Events Sequencing (MES) and Sequentially Timed Events Plotting (STEP)

MES and STEP are methods of data-gathering and tracking for the analysis of complex focus events. The results are displayed as a Time-Actor Matrix of events.

The Why Method The Why Method is a simple series of questions that guides the analysis to the root causes.

Causes Tree Method (CTM)

CTM is a systematic technique for analysing and graphically depicting the events and conditions that contributed to a focus event. CTM is similar to the why method in concept but builds a more complex tree and explicitly considers technical, organisational, human and environmental causes.

Why-Because Analysis (WBA)

WBA establishes the network of causal factors responsible for a focus event using a two-factor comparison, the Counterfactual Test. The network of factors is displayed in a Why-Because Graph.

Fault Tree and Success Tree Method

Fault or Success Tree is a graphic display of information to aid the user in conducting a deductive analysis to determine critical paths to success or failure, which are displayed graphically in a logic tree diagram.

Fishbone or Ishikawa Diagram

The Fishbone or Ishikawa Diagram is a technique that helps identify, analyse and present the possible causes of a focus event. The technique illustrates the relationship between the focus event and all the factors that may influence it.

Safety through Organisational Learning (SOL)

SOL is a checklist-driven analysis tool, oriented towards focus events in nuclear power stations. Results in the visual form of a Time-Actor Diagram, derived from the MES/STEP method.

Management Oversight and Risk Tree (MORT)

The MORT chart is a pre-populated fault tree with events, usually faults or oversights, expressed in generic terms. The MORT tree contains two main branches and many sub-branches giving a high level of detail. One main branch identifies about 130 specific control factors while the other main branch identifies over 100 management system factors. The chart also contains a further 30 information system factors common to both main branches of the tree.

AcciMaps AcciMaps is primarily a technique for displaying the results of a causal analysis. It requires an organisational model to separate factors into layers and to elicit factors in the layers; applies a version of the Counterfactual Test (see WBA) to determine the causal relations amongst the factors.

Tripod Tripod is a tree diagram representation of the causal network, focusing on human factors and looking for failures in the organisation that can cause human errors.

Causal Analysis for Systems Theoretic Accident Model and Process (STAMP) (CAST)

CAST is a technique that examines the entire socio-technical process involved in a focus event. CAST documents the dynamic process leading to the focus event including the socio-technical control structure as well as the constraints that were violated at each level of the control structure.

62740/Ed1/CDV IEC(E) 20

A.3 Criteria 686

Table A.2 provides a list and describes the criteria used to characterise the RCA techniques 687 listed in Table A.1. Each criterion has three levels indicated by a (+), (o) or a (-), where the 688 different levels indicate the range. 689

The attributes for each RCA technique using the criteria in Table A.2 are shown in Table A.3. 690

Table A.2 Summary of RCA technique criteria 691

Criteria Description Levels

Expertise required

Is the method targeted towards the "sophisticated user" (does it require use of techniques such as theorem proving which requires specific expertise)? Is it suitable for use by domain experts only?

Intuitive, little training necessary (+).

Limited training required e.g. one day (o).

Considerable training effort necessary, e.g. one week (-).

Tool Support Is tool support necessary? Can be well applied without dedicated tool support, e.g. Office type tools (+).

Tool support not required but usually needed for effective application (o).

Tool support necessary, can be applied only with dedicated tools support (-).

Scalability Is the method scalable? Can the method be used cost-effectively for simple as well as complex focus events? Can a subset of the method be applied to small, or to less-significant focus events and the full capability applied to large, or to significant focus events? So the question of scalability asks whether the complexity of analysis using the method scales with the complexity of the focus event.

Scales well with complexity (+).

Limited scalability, considerable overhead with every application (o).

Not scalable, the full method has to be applied (-).

Graphical Representation

What is the nature of the method's graphical representation?

The motivating principle is that a picture is better than a thousand words. It is often more comprehensible to display results of an analysis method as an image, a graph, or other form of illustration, than as purely written text.

The desirable properties of a graphical representation are:

to display clearly the semantics of causality (including denotation of causal factors, and taxonomic classification of factors);

to be cognitively (relatively) easily evaluated by a single person;

ideally, a graphical representation could also display the history of the analysis.

Graphical representation with clearly defined semantics and cognitively easy to understand (+).

Graphical representation, but without semantics (o).

No graphical representation defined (-).

Reproducibility Are the results of the method reproducible? Would different analysts obtain similar results for the same focus event?

The results can be reproduced, differences are only observed on the representation of the results, wording etc. (+).

A significant amount of the results can be reproduced, but some differences will be observed (o).

The results will depend on the analyst and their expertise (-).

62740/Ed1/CDV IEC(E) 21

Criteria Description Levels

Plausibility Checks

Are there reasonable, quick plausibility checks on the results obtained which are independent of the tool? What ways are there of checking the "correctness" of the results? One example would be checklists.

There are plausibility checks for almost all aspects (+).

There are plausibility checks, e.g. checklists, but they do not necessarily cover all aspects (o).

There exist only limited means supporting plausibility checks (-).

Intellectual Rigour

How rigorous is the method? Rigor has two relevant aspects:

Does the method have a rigorous meaning, formal semantics, for the key notions of cause, causal factor and root cause? Is the semantics easy to apply?

Are the results of the method amenable to formal (mathematical) verification? To what extent is an application of the method so amenable?

Formally defined and can be formally verified (+).

Semi-formal definition (o).

Informal definition (-).

Time Sequence Does the method contain a representation of time sequence of events?

Yes (+).

Only indirectly (o).

No (-).

Specificity The extent to which the method limits analysis to necessary causal factors of the focus event rather than exploring a range of general problems with the system that existed at the time of the focus event and may have contributed.

Method analyses specific necessary causes of the focus event (+).

Method can be used to analyse generic problems as well as the necessary causes of the focus event (o).

Method seeks problems in general whether or not they were necessary causes of the focus event (-).

692

62740/Ed1/CDV IEC(E) 22

Table A.3 Attributes of the generic RCA techniques 693

Expertise Required

Tool Support

Scalability Graphical Representation

Reproducibility Plausibility checks

Intellectual Rigour

Time Sequence

Specificity

ECF o o o + o o o - +

MES and STEP - o o + + o o + +

The Why Method + + - o - - - - +

CTM o o o + o o o - +

WBA o + o + + + + o +

Fault Tree and Success Tree Method o o o + o o o - o

Fishbone or Ishikawa Diagram + + - o - o - - o

SOL o - + o + + o + o

MORT + - - o + o o - -

AcciMaps o o o + - o - - o

Tripod Beta - + o + o o o o o

CAST + + + o o o o + +

The criteria for each attribute is described in Table A.2.

694

62740/Ed1/CDV IEC(E) 23

Annex B 695 (Informative) 696

697 RCA models 698

B.1 General 699

This Annex describes the most commonly used RCA models which provide different ways of 700 thinking about focus events. The different models are based on certain hypothesis with regard 701 to the focus event e.g. Barrier Analysis assumes the focus event has occurred as a result of 702 missing, defective or ineffective barriers. Therefore, the different models tend to lead the 703 investigator to identify different causal factors. Models are used to direct thinking in 704 conjunction with the techniques of Annex C, or simply to identify a set of causes. 705

B.2 Barrier Analysis 706

B.2.1 Overview 707

Barrier analysis is based on the hypothesis that a focus event occurs as a result of the 708 interaction of a source of harm on a target and that this can be prevented by the use of 709 barriers [3]. An undesirable event occurs when the barriers are missing, defective or 710 ineffective (see Figure B.1). 711

712

Figure B.1 Broken, ineffective and missing barriers causing the focus event 713

Haddon [3] considered focus events where the source of harm is physical energy and barriers 714 relate to how the energy can be modified or prevented from impinging on the target. The 715 model has been extended in various ways [4], for example barriers are often divided into 716 physical barriers and administrative barriers (see Table B.1 for some examples). Barriers may 717 also be considered in terms of prevention, protection and detection (for example in the 718 context where the focus event is a fire these would be using non-flammable materials, 719 providing fire extinguishers and installing smoke alarms). 720

The output of the analysis generally includes a Barrier Analysis Worksheet (see Table B.2), 721 which identifies those barriers that either were available but ineffective or were not in place 722 during the occurrence of the focus event. 723

724

Source of harm

Target

Failed barrier

Missing barrier

Ineffective barrier

Missing barrier

Failed barrier Failed barrier

62740/Ed1/CDV IEC(E) 24

Table B.1 Examples of barriers 725

Physical or Energy Barriers Administrative Barriers

Engineered safety features

Safety and relief devices

Conservative design allowances

Redundant equipment

Locked doors and valves

Ground fault protection devices

Shielding and guards

Alarms

Automatic fire containment systems

Plant operating and maintenance procedures

Regulations, Policies and practices

Training and education

Work protection

Work permits

Skilled people

Methods of communication (3-way communication)

Supervisory practices

Table B.2 Example Barrier Analysis Worksheet 726

UNDESRIED OUTCOME

(WHAT HAPPENED?)

(List one at a time, need not be in sequential order.)

SOURCE OF HARM

BARRIER(S) THAT SHOULD HAVE PRECLUDED THE UNDESIRED EVENT

(List all physical and administrative barriers for each undesired outcome)

BARRIER FAILURE MECHANISM

(HOW THE BARRIER FAILED)

BARRIER ASSESSMENT

(WHY THE BARRIER(S) FAILED)

(Identify if the barrier was missing, weak, or ineffective; and why.)

Maintenance worker loosened nuts on flange of the pipe line that was pressurized

Pressurised liquid

Procedure to switch off pump and release pressure before commencing work

Pressure released on wrong system

Unclear labelling

B.2.2 Strengths and limitations 727

The strengths of Barrier Analysis are as follows: 728

identifies what corrective actions are required to ensure adequate barriers (number and 729 effectiveness) are in place. 730

The limitations of Barrier Analysis are as follows: 731

may not recognise all failed or missing barriers, or the effect of the rate of frequency with 732 which the barriers are challenged; 733

addresses direct causes rather than root causes i.e . it seeks what barrier failed and how, 734 but does not explore why in any depth. 735

B.3 Reasons Model (Swiss Cheese Model) 736

B.3.1 Overview 737

Reasons model [5] is based on the premise that the basic required elements of any 738 productive system are: 739

appropriate decisions from plant and corporate management; 740

line management activities, operations-maintenance training etc; 741

reliable and fit for use equipment; 742

motivated workforce; 743

integration of human and mechanical elements; 744

safeguards against foreseeable risks. 745

There are inevitably weaknesses in these elements that can be considered to be latent 746 failures. If these come together a triggering event, which may be unimportant in other 747 circumstances, results in failure. 748

62740/Ed1/CDV IEC(E) 25

The weaknesses in the elements of the productive system are pictured as holes in slices of 749 Swiss cheese. An event will result when all individual weaknesses align. Reasons model is 750 not strictly a barrier model as the layers are normal operating systems with weaknesses 751 rather than failed barriers or controls. 752

Human error Taxonomies based on Reasons model have been developed for a number of 753 different industries. 754


The strengths of Reasons Model are as follows: 756

encourages the analyst to explore causes of operator error and hence possible means of 757 reducing it. 758

The limitations of Reasons Model are as follows: 759

superficial analysis of technical or environmental causes which considers technical 760 aspects only in terms of failed barriers; 761

assumes the core problem is operator error (errors at other levels and organisational 762 failures are explored primarily in terms of how they influence operator error ); 763

does not supply a taxonomy to assist with the identification of motivations and 764 psychological precursors of human error or in identification of latent failures and hence 765 requires expertise in individual and organisational psychology to use properly. 766

B.4 Systems models 767

Systems theory [6] was developed in the 1940s and 1950s to handle the increase in 768 complexity of systems after WWII and to consider the social and technical aspects of systems 769 together as a whole. 770

In system models it is assumed that human interaction with technology in complex social 771 structures is influenced by the organisations goals, policy and culture and by internal and 772 external economic, legal, political and environmental elements. This system is stressed by the 773 fast pace of technological change, by an increasingly aggressive, competitive environment, 774 and by factors such as changing regulatory practices and public pressure. In this context 775 focus events are due to multiple factors and are typically waiting for release and not due to 776 any one act or event. 777

Failures arise due to the complex interactions between system components that may lead to 778 degradation of system performance. Two or more discrete events within system elements can 779 interact in unexpected ways which designers could not predict and operators cannot 780 comprehend or control without exhaustive modelling or test. Factors contributing to the focus 781 event may include effects of decisions which are normal in the circumstances in which they 782 were made but produce an unwanted outcome. 783

Methods based on a systems model do not seek a causal chain or look for individual error or 784 technical failures but consider the system as a whole, its interactions and its weaknesses. 785 Individual human or hardware failures may be recognised but the focus is on interactions and 786 systemic issues. 787

B.5 Systems Theoretic Accident Model and Processes (STAMP) 788

B.5.1 Overview 789

STAMP [7] is a causality model based on systems theory [6] that extends the traditional 790 model (chains of directly related failure events) to include both the technical and social 791 contributors to focus events and their relationships. It also captures focus event s involving 792 interactions among non-failing system components and processes, indirect and systemic 793 causal mechanisms, complex operator and managerial decision making, advanced technolog y 794 such as digital systems and software, and system design flaws. 795

796

62740/Ed1/CDV IEC(E) 26

797

STAMP assumes incidents arise in interactions among humans, machines, and the 798 environment and treats systems as dynamic control problems in which the controls aim to 799 manage the interactions among the system components and its environment. The goal of the 800 control is to enforce constraints on the behaviour of the system components, for example, 801 aircraft in an air traffic control system must always maintain a minimum separation distance. 802 Focus events result from inadequate control or enforcement of constraints on the 803 development, design, and operation of the system. In the Challenger loss, for example, the O -804 rings did not control propellant gas release through the field joint of the Space Shuttle. In 805 STAMP, the cause of a focus event is a flawed control structure. 806

STAMP also incorporates the concept that incidents often arise from a slow migration of the 807 whole system toward a state of high risk [8] so that financial and other pressures that lead to 808 changing behaviour over time can be accounted for in the causal analysis process. 809


The strengths of STAMP are as follows: 811

considers the role of the entire socio-technical system in causation; 812

includes indirect and systemic factors in the causal explanation; 813

provides a model to explain accidents in very complex systems; 814

identifies causes back to the process with which a system was developed. 815

The limitations of STAMP are as follows: 816

requires focus events to be analysed in a way that is often unfamiliar to engineers, 817 therefore may take more time to learn how to analyse focus events using causal analysis 818 processes based on STAMP. 819

820

62740/Ed1/CDV IEC(E) 27

Annex C 821 (Informative) 822

823 Detailed description of RCA techniques 824

C.1 General 825

This Annex describes a range of techniques used during a RCA. The list is not comprehensive 826 but covers examples of the different types of techniques used. Many of these techniques are 827 supported by software tools. Some of the methodologys and software tools have elements 828 that are proprietary, which may impact on the cost of implementing the technique. 829

Some techniques aim to identify causes that can be shown to be necessary if the focus event 830 is to occur. Other methods seek general weaknesses of the system as a whole that probably 831 contributed to the focus event but where the focus event could have occurred in their 832 absence. In some terminologies a cause cannot be so described unless it is necessary to 833 the focus event. In this Annex such causes are referred to as necessary causal factors. 834 Identified weaknesses that may have played a part in the focus event but may not be 835 necessary to it are referred to as contributory factors. 836

In general identification of necessary causal factors will be repeatable and based on 837 evidence. There may be a higher level of subjectivity in identifying contributory factors and 838 different analysis techniques with a different focus may identify different factors. 839

C.2 Events and Causal Factors (ECF) Charting 840

C.2.1 Overview 841

The ECF chart [9] records events in chronological order from left to right in rectangles, with 842 events characterised by single subjects and active verbs. Each event is derived strictly from 843 the one before. Conditions necessary for the events are displayed in ovals above and below 844 the sequence of events. (Conditions are states or circumstances rather than happenings). 845 Events are connected by solid lines and conditions by dashed lines. Events and conditions 846 based on evidence have a solid outline, whereas those that are presumptive have a dashed 847 outline. There may be multiple or branching sequences of events each with their own 848 conditions. 849

Figure C.1 illustrates an example of an ECF chart, in which a maintenance activity was 850 incorrectly carried out due to the maintainer turning up late, resulting in an emergency landing 851 carried out by an aircraft. 852

853

Maintainer

turns up late

for work

Inspection equipment does not

reach ambient temperature

Maintainer

receives

tasking

Maintainer

collects

required

equipment

Maintainer

ignors

requirement

for hangar

inspection

Maintainer

carries out

inspection

task on

engine

Aircraft

declared

serviceable

Engine fails

Aircraft

carries out an

emergency

landing

09:05 01/10/12 10:30 01/10/1209:50 01/10/12 13:20 01/10/1213:00 01/10/12

Flight delayed

awaiting

inspection

Flight

scheduled for

09:00

Aircraft rolled

out of hanger

for flight prep

Crew decide

to start flight

prep

Outdoor ambient temperature

15 degrees C

No other

maintainers

available

Equipment storage

ambient temperature

25 degrees C

09:20 01/10/1209:15 01/10/12

854

Figure C.1 Example of an ECF chart 855

62740/Ed1/CDV IEC(E) 28

C.2.2 Process 856

The following describes the process for developing an ECF chart. 857

1) Identify the focus event and record it in a box on the right hand side. 858

2) Record the primary chain of events that led to the focus event where each event in the 859 chain is both immediate and necessary to the event on the right hand side. Therefore, the 860 consequence is recorded on the right hand side of each event (cause). Also, the 861 consequence of a previous event may be at the same time a cause of following event. The 862 events are displayed in rectangles linked by arrows to the right of the focus event. 863

3) Determine what conditions led to these events. State each of them in an oval above the 864 relevant event. 865

4) Add any secondary chains of events that may be relevant to the focus event and their 866 conditions. 867

5) Check the validity of the causes by obtaining evidence that determines whether the 868 conditions and events are true. 869

6) Develop the ECF chart until the event at the start of the sequence is identified and all 870 conditions which can be verified by evidence are added. 871

Generally the exact chronology of events is not known at the beginning of the investigation 872 and becomes clearer as the investigation proceeds. A method should therefore be used that 873 allows investigators to easily change the sequence of events and conditions as more 874 information is gained. 875

C.2.3 Strengths and Limitations 876

The strengths of ECF are as follows: 877

assists the verification of causal chains and event sequences; 878

provides a structure for collecting, organising, and integrating evidence; 879

identifies information gaps; 880

assists communication by providing an effective visual aid that summarises key 881 information regarding the focus event and its causes. 882

The limitations of ECF are as follows: 883

identifies some causes but may not necessarily determine the roo t causes; 884

it can be overcomplicated for simple problems. 885

C.3 Multilinear Events Sequencing (MES) and Sequentially Timed Events 886 Plotting (STEP) 887

C.3.1 Overview 888

MES [10] and STEP [11] are methods developed to analyse focus events in complex systems, 889 where STEP is a successor to MES. 890

As with ECF charting, MES/STEP conceives a focus event as arising from an interlinked 891 succession of events with events characterised by a single subject and an active verb. In 892 MES and STEP the subject is called an actor (which may be human or machine, or even a 893 property). 894

Events are represented as event building blocks (BBs), which consist of (partial or full) data 895 records as described in Figure C.2. These are arranged during the analysis in a Time-Actor 896 Matrix where the vertical axis of the matrix represents the different actors, and the horizontal 897 axis represents time. 898

The Time-Actor Matrix also contains: 899

conditions necessary for enabling an event along with precursor events; 900

62740/Ed1/CDV IEC(E) 29

annotations for further tasks in an investigation, such as a note indicating a deficit of 901 information, or an incomplete explanation of an event. 902

An example showin

BS en 62740. Root Cause Analysis (RCA). (Draft)

Documents

Transcript of BS en 62740. Root Cause Analysis (RCA). (Draft)