See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220579284

Accident and Incident Analysis Based on the Accident Evolution and Barrier Function
( AEB) Model
Article in Cognition Technology and Work · February 2001
DOI: 10.1007/PL00011521 · Source: DBLP

CITATIONS READS

49 605
1 author:

Ola Svenson
Stockholm University
136 PUBLICATIONS 7,076 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Time saving bias View project

Coherence in decision making View project

All content following this page was uploaded by Ola Svenson on 05 December 2018.

The user has requested enhancement of the downloaded file.

Cognition, Technology & Work (2001) 3:42–52
# 2001 Springer-Verlag London Limited Cognition
Technology &
Work

Accident and Incident Analysis Based on the Accident

Evolution and Barrier Function ( AEB) Model
O. Svenson
Department of Psychology, Stockholm University, Stockholm, Sweden

Abstract: This contribution presents a model and a description of how to conduct incident and accident analyses using the Accident Evolution and Barrier
Function (AEB) method. The method enforces human factor experts and other experts to cooperate in a conjoint process leading to the analysis. An
accident is modelled as a sequence of interacting malfunctions and errors in human and technical systems leading to an accident. Coupled with most links
in the chain there are possibilities to arrest the evolution through barrier functions (e.g., a physical barrier function) serving to stop the sequence of
events. The barrier functions are executed by barrier function systems (e.g., a computer-controlled lock). Organisational systems are analysed in parallel or
directly after having modelled an accident evolution. The analysis of an incident involves several steps and issues, such as deciding about when to stop
going further back in the chain, in what detail to model and barrier function analysis to eliminate or decrease the risk of another accident. The paper also
contains material of
interest for analysts using other methods of accident analysis. accident is a sequence of events leading to at least one
non-intentional and unwanted consequence. An incident is
Keywords: Accident analysis; Human factor; Incident analysis a near-accident in the sense that the sequence of events
was triggered and went on for some time but was stopped
before the final negative consequence appeared. With
Leplat’s statement and the systems producing the
accidents in mind, it is not surprising that one finds a great
number of different methods for analysis of accidents
1. INTRODUCTION ( Hale et al 1997). Many of the methods for incident and
accident analysis were developed in practical applications
Introducing his conclusions in a recent study, Leplat writes,
by private companies and therefore are not easily
‘In theory event analysis is multidimensional and cannot
accessible to scientists and practitioners (e.g., INPO 1988).
ever be exhaustive. It must select aspects, which will
Other methods were developed by scientists at universities
change according to the context, the objectives and the
for industry and private enterprises and those methods are
analyst’s competencies and interests’ (Leplat 1997, p. 36).
often published and can be used by everybody (e.g., Kjelle
The present contribution represents one such selection of
´n and Larsson 1981; Schaaf et al 1991; Schaaf 1992;
aspects and a way of modelling an accident sequence in a
Johnson et al 1995). From an initial focus on the accident
complex system that is systematic, transparent, open and
outcome or the negative event in itself, accident analyses
enables an organisation to act in order to prevent further
over the years gradually increased their scope to include
incidents and accidents of the same or of a similar kind.
the chain of events leading to the negative event (e.g.,
An accident in a complex system (e.g., a nuclear power Kjelle´n and Larsson 1981).
plant, a hospital, a road traffic system) is the result of a
Although there are many different methods for
system that has not been kept at its normal stable state. It
accident analysis, many of them have common
is because accidents are the result of malfunctions of
elements (e.g., causal trees and barriers or safeguards
complex systems and subsystems in interaction that it is so
that can stop an accident evolution), there are also
difficult to model the antecedents of an accident. The
great differences among them concerning, for example,
multitude of dynamic interactions and the low frequencies
demands on analyst competence. To illustrate, some
of accidents make it necessary to choose models that can
methods might stress human factor errors and, others;
only approximate some aspects of these interactions. An
 Accident and Incident Analysis
technological failures. Most current methods using
expert analysts integrate human factor expertise and
engineering expertise by having the different kinds of
experts first consider the aspects that are classified to
fall under their respective domains of expertise and
then the different perspectives are integrated in the
analysis. By way of contrast, the Accident Analysis and
Barrier Function (AEB) model (Svenson 1990; 1991)
describes an accident evolution in such a way that it is
necessary to adopt several perspectives, e.g., both an
engineer and a human factor perspective, when the
analysis is performed. The interaction between
different kinds of experts should take place during the
data collection, the analysis of the data and the
presentation of the results in an AEB accident analysis.
There are two main aims of the present paper. One
aim is to present the AEB model and to provide an
instruction that can be used by the reader who wants
to use the AEB approach or parts of the method. It is
important to stress that although the present
contribution is complete up to a certain point of detail
and the method may seem quite straightforward, the
analyst who starts applying the method will need
preliminary training before she or he uses the method
in the field. In the following when presenting the
method, some of the problems that beginners usually
have will be pointed out so that they can be solved
early on by the analyst starting to apply AEB.
Another aim of the present contribution is to
communicate important aspects of incident and
accident analysis performed by experts using any
method. In this way analysts who are not interested in
applying AEB can learn from AEB in order to improve
their own methodology.
2. ACCIDENT EVOLUTION ANDBARRIER
FUNCTION MODEL OF ACCIDENTS
2.1. General Characteristics of the Model
The AEB model provides a method for analysis of
incidents and accidents that models the evolution
towards an incident/accident as a series of interactions
between human and technical systems (Svenson 1991).
The interactions consist of failures, malfunctions or
errors that could lead to or have resulted in an
accident. As mentioned above, the model forces
analysts to integrate human and technical systems
simultaneously when modelling an accident evolution.
The model can be visualised in a flow chart
consisting of empty boxes in two parallel columns: one
43
for the human systems and one for the technical
systems. Figure 1 provides an illustration of this
diagram. When modelling an accident evolution in an
analysis the error boxes are identified as failures,
malfunctions or errors constituting the accident
evolution. In general, the sequence of error boxes in
the diagram follows the time order of events. Between
each pair of successive error boxes there can be a
possibility to arrest the evolution towards an
incident/accident. Barrier function systems (e.g.,
computer programs) that are activated can arrest the
evolution through effective barrier functions (e.g., the
computer making an incorrect human intervention –
modelled in the next error box – impossible through
blocking a control).
2.2. Graphical Representation of the Model
As mentioned above, an incident/accident that is analysed
using the AEB method describes the accident evolution in a
flow diagram. Sometimes, the flow diagram can be only
approximately chronological because a sequential model is
used to approximate the interaction of complex systems,
much of which goes on simultaneously. As illustrated by
Fig. 1, the AEB model makes use of a decomposition of the
sequence of errors into human and technical systems
categories. It is establishment of this sequence of error
events that is the first main focus of an AEB analysis.
2.3. Systems and Components in the AEB Model
There are three important system components in the AEB
model: human factor, technical and organisational systems.
Of these the human factor and technical systems play the
dominating role when modelling an incident or accident.
However, the organisational system component is just as
important for understanding accidents and this component
is therefore covered in parallel with the evolution as a
system in itself as well as a barrier function system. All
three systems can form barrier function systems, i.e.,
systems that can arrest the evolution towards an accident –
another important component of the AEB model.
2.3.1. The Human Factor Systems
Humans always play a role in an accident, either as actors
in the accident evolution or as designers of failing or
inadequate technology or in organisations that contribute
to the accident evolution. Therefore, one of the main
components in an AEB analysis is the human system
component modelled in the left column of boxes in the
flow diagram describing an accident (Fig. 1). To exemplify,
an operator initiating an action at the wrong time would be
modelled in an error box in the human systems part of the
44
diagram (e.g., event 2). In the right column of the flow
diagram technological errors are located. The erroneous
technological system state or process resulting from the
inappropriate operator action mentioned above should
therefore be modelled in the next box of the technology
systems part of the diagram.
Factors that have an influence on human performance
have been called performance-shaping factors (Swain and
Guttman, 1983) or performance-moderating factors.
Fig. 1. Graphical representation of an AEB analysis. The meanings of the symbols are described in the text.
Hollnagel (1998) introduced the concept Common
Performance Conditions (CPC), acknowledging that
different performance-shaping factors (PSFs) interact when
influencing human performance. In addition, CPCs are
derived in task analyses prior to other analyses, while PSFs
typically are used for adjustments of parameters estimated
in prior HRAs. Examples of such factors are alcohol, drugs,
lack of sleep and stress. In applications of the AEB model
PSFs will be analysed as CPCs when possible but included
in the flow diagram as PSFs. They are analysed in parallel
with the modelling of the accident but also in more detail
after the diagram has been completed. PSFs are included in
the flow diagram in cases where it is possible that one or a
set of such factors could have set the scene for or
contributed to one or more human error events. Note that
PSFs (or CPCs) are never modelled as barrier functions or
failure events in AEB. PSFs contribute to the conditions
under which an operator, a team, an organisation etc.
executes barrier functions and makes errors. To exemplify,
a driver who drives through red lights under the influence
of alcohol would be analysed as an error event of ‘the
driver driving through red traffic signals’ with alcohol
(under the influence of alcohol), that is, one of several
possible PSFs.
Note, that AEB does not analyse organisational factors
as PSFs, which contrasts with Swain and Guttman’s (1983)
human reliability (HRA) approach that adjusts human
O. Svenson
relative error probabilities according to the judged quality
of the organisation. Instead, the organisation system
component is integrated as a system in itself and analysed
in parallel with the accident evolution diagram with failures
and working, failing or inadequate barrier functions. Thus,
to repeat, organisational factors should always be treated
in their own right in AEB analyses and in parallel with the
flow diagram representation because organisational factors
affect and include both human and technical systems.
2.3.2.
Technical
Systems
As
mentioned earlier, the right-side column of an AEB flow
diagram describes technical errors. Such errors can
relate to construction, maintenance, processes and
other aspects of technical systems. An example of
technical errors in the road traffic area is insufficient or
failing brakes. Also, latent conditions will be modelled
as errors, earlier dormant in the system but revealed
during the accident sequence. In this case, there is a
choice of modelling. Either the latent condition can be
modelled when it was first implanted into the system
(usually early in the sequence), or later when it
changed from a latent condition to a manifest error
(later in the sequence). It is often practical to model the
error in both modes. Sometimes, it is practical to repeat
a latent condition and error in more than one box in a
sequence. For example, if the latent error condition
could have been detected and eliminated at different
points in the accident evolution there should be error
boxes at those locations. To illustrate, a valve that is
erroneously left open, was inspected without error
detection, and finally allowed mass to pass can be
modelled as open both before inspection and before
the box representing the consequence of the erroneous
flow of mass.
2.3.3. Error Event Boxes and Accident Evolution Analysis
Failures, malfunctions and errors that contribute to the
 Accident and Incident Analysis
development of an accident/incident are described in
the error event boxes. It is very important to stress that
AEB only models errors and that it is not an event
sequence method (as, for example, Human
Performance Evaluation System; INPO, 1988). The most
common error made by novice analysts starting to use
AEB is that they model also correct events. Error event
boxes are numbered and marked H for human error
events, and T for technical error events. To repeat, the
most common mistake made by beginners is to also
model also events other than errors, failures and
malfunctions in the AEB analysis. (This mistake is the
same kind of erroneous analysis as it would be to
introduce events other than faults in a fault tree.)
Arrows link the error event boxes together in order
to show the evolution of the accident/incident. It is not
allowed to let more than one arrow lead to an error
box. An error box cannot have more than one arrow
going from it. Because systems interactions are
modelled, it is often quite tempting to try to model
multiple influences or energy flows but this is not
allowed. Such interactions are covered later in the
barrier system function analysis. These analyses can be
used for modelling subsystem interactions that cannot
be represented sequentially in AEB. However, in the
traffic research area, Sjo¨stro¨m (1997) used parallel
AEB diagrams to model the accident evolution leading
to a collision between two vehicles.
The course of events is described in as close as
possible chronological order in an AEB analysis. At what
point in time a certain error event occurred is written (if
such information is available) in the time column to the
left of the flow diagram. The description of the course
of events in the AEB analysis is primarily approximately
chronological, and each link is not always (but in a great
majority of the cases) causal. Thus, the analysis
presupposes that a time order is reflected in the model,
even if this order can be only approximate at some
points.
The choice of a starting point for an AEB analysis is
to some extent dependent on the analysts and their
knowledge and motivations. Svenson (1991) has
commented on this in relation to AEB and we shall
return to this later. In addition, the definition of
accident is also partly dependent on the analysts. To
exemplify, the pre-crash and crash phases of a road
traffic accident may provide the definition of an
accident in one analysis, while the sequence of injuries
caused by the accident can be the focus in another
accident analysis.
The chain of errors in an AEB analysis is not
necessarily complete with the box describing the
45
accident as, for example, an injury. The AEB model can
also be applied to analysis of courses of events
following the accident event. The purpose of including
also post-accident errors is to stimulate identification of
as many barrier functions as possible. For example, one
may ask if there are any actions that could have
prevented or mitigated human injury if the accident in
itself was not prevented. An AEB analysis can also be
used to describe hypothetical sequences of events after
the accident. In some cases, fault and/or event trees
can be appended to the AEB analysis, when possible
postaccident failures and errors are analysed.
2.3.4. Barrier Function Systems and Barrier Functions A
barrier function represents a function that can arrest
the accident/incident evolution so that the next event
in the chain will not be realised. A barrier function is
always identified in relation to the system(s) it protects,
protected or could have protected. Barrier function
systems are the systems performing the barrier
functions. Barrier function systems can be an operator,
an organisation, an instruction, a physical separation,
an emergency control system, other safety-related
systems etc.
The same barrier function can be performed by different
barrier function systems. An example of this is the blocking
of a robot moving into a prohibited area – a function that
can be performed by an operator or a computer.
Correspondingly, a barrier function system can perform
different barrier functions. An example of this is an
operator who can perform a number of different barrier
functions (opening a valve, disconnecting a pump,
restoring electric power manually in a plant etc.) directed
towards protecting different subsystems. Recently,
Hollnagel (1999) reviewed and classified different kinds of
barrier systems and barrier functions. Using this
classification of barrier systems and functions should
improve an AEB analysis because the classification creates
a structure that can be used in the search for alternative
solutions and improvements of existing arrangements.
An important purpose of conducting an AEB analysis is
to identify broken barrier functions and suggest how they
can be improved and/or supported by other yet non-
existing barrier functions – often executed by other barrier
function systems. Thus, in the course of events described in
an AEB analysis, barrier functions are identified that can
arrest the unwanted evolution of an accident/incident.
Barrier functions belong to one of three main categories.
. ineffective barrier functions – barrier functions that were
ineffective in the sense that they did not prevent the
development toward an accident/incident;
46
. non-existing barrier functions – barrier functions who, if
they had been present, could have stopped the
accident/ incident evolution;
. effective barrier functions – barrier functions that actually
prevented the progress toward an accident/incident.
Effective barrier functions are normally not included in
an AEB analysis except at the very end of the chain, since
the AEB model is based on errors.
If a particular accident/incident should happen, it is
necessary that all barrier functions in the sequence are
broken and ineffective. Thus, the specific chain of
malfunctions, errors and barrier function failures appearing
in an accident evolution are sufficient for the particular
accident/incident to occur. The ultimate objective of an
AEB analysis is to understand why a number of barrier
functions failed, and how they could be reinforced or
supported by other barrier functions.
From this perspective, identification of a root cause of
an accident/incident is meaningless (Svenson 1999). The
starting point of the analysis cannot be regarded as the
root cause because not only the removal of that error, but
also the removal of any other error in the sequence, would
also eliminate the accident. A root cause concept that
includes all errors that could be found and excludes no one
is not a meaningful concept.
When performing an accident analysis it is sometimes
difficult to know if an error should be modelled as an error
or as a failing barrier function. This is because a barrier
function failure can sometimes be seen as an error and be
modelled in a box of the diagram. To exemplify, an error
consisting of an act or function that was not performed to
restore the system can be modelled either as a barrier
function failure or as an error in a box. When the error is
modelled in a box, this permits more detailed analyses of
the two links connecting the box in the accident evolution
chain. As a rule of thumb, when uncertain the analysts
should prefer a failure event box over a broken or
ineffective barrier function representation in the initial AEB
analysis.
3. PERFORMING AN AEB ANALYSIS
An AEB analysis consists of two main phases. The first
phase is the modelling of the accident evolution in a flow
diagram based on a preprinted or a computer-based flow
chart. The second phase consists of the barrier function
analysis. In this phase, barrier functions are identified
(ineffective and/or non-existent), which could have
arrested the unwanted evolution. The reasons why there
were no barrier functions or why the existing ones failed
O. Svenson
are analysed and improvements are suggested. The first
phase will be in the main focus of the present contribution.
The AEB method provides a common theoretical
framework that is useful for communication and
improvements of complex systems. As emphasised before,
the method presupposes that human factor and technical
systems by experts participate together and at the same
time in an analysis.
3.1. Graphical Representations
This section first describes different graphical
representations used in an AEB analysis and then gives a
schematic representation of an AEB analysis diagram.
Error event box
Accident/incident
Arrows describe the development of the
accident evolution in an approximately
chronological order
Represents possible barrier functions,
which could have arrested the accident
and barrier function that were
ineffective. Failing and possible barrier
functions described in the margin for
later barrier function analysis. Failing
and possible barrier functions should
be coded differently in the margin
Both symbols represent a barrier
function that arrested the accident
evolution. Effective
barrier functions are
normally not included
in an AEB analysis
except at the very end of the evolution
PSF Represents a performance-shaping factor
(PSF) or Common Performance –
Conditions). PSFs are marked in the flow
diagram above relevant human error
event boxes, described in the margin
and later analysed. PSFs represent
conditions such as tiredness and time
pressure that affect human
performance. AEB does not analyse
 Accident and Incident Analysis 47
organisational factors as PSFs, but the accident/incident are also identified if the analysis
recommends detailed analyses of the did not start with the final accident.
organisation as a system that provides Earlier failures include latent conditions of too worn
context and can act as a barrier function tires (below legal standards) and poor bumpers.
system
4. The description of the sequence of error events
includesidentification of barrier functions that failed to
3.2. Stages in Analysis arrest the sequence towards an accident/incident.
At least two analysts should cooperate when
performing an analysis. One of them should be a
human factor specialist and the other a systems expert
familiar with the (technical) systems related to the
accident. The following describes the different steps in
an AEB analysis. A road accident from the mid-970s will
be used to illustrate the different stages.
The accident involved a car that was driven on a
motorway in daylight. The surface of the road was
wet after an intense shower of rain with pools of water.
The driver is in the left lane after having passed a car.
The road curves to the right and the driver intends to
bring his vehicle back to the right lane. During the
manoeuvre the car skids and the driver is unable to
counteract this and loses control. The car spins around
and goes backwards off the road ending upside down
on the roof.
1. A general but detailed description of the accident/
incident, the narrative, is first secured and studied. The
narrative can be based on data of different kinds
obtained from interviews, computer logs, written
reports and other sources. The goal when establishing
the narrative is to get a very comprehensive and yet
general view of what has occurred.
The accident example above is based on a several
pages based on an on-the-site interview followed by
analyses of three different experts (human factors,
vehicle and road engineers).
2. Next the first error event is located in an error box. One
way of doing this is to select an important error or
failure in the middle of the diagram. Another way is to
locate the accident in an error box low in the diagram
(close to the final accidental outcome).
The first error in the car accident marked in the flow
diagram was the skidding of the car (Fig. 2).
3. Starting with the error box first marked, the
analyststhen identify earlier failures preceding the first
located failure and indicate them in the flow diagram. In
this process several iterations are usually needed to
arrive at an accident sequence model that is
satisfactory. Failures further down the evolution toward
48 O. Svenson
The driver’s attempts to control the skidding car
exemplifies this.

Fig. 2. Graphical representation of an AEB analysis of a road accident.

 Accident and Incident Analysis
5. As a fifth step, the flow diagram is completed with
barrier functions that could have arrested the accident
evolution chain. The goal is to identify sequences where
barrier functions could have been present to prevent
the same or a similar accident evolution. A
recommendation is to go through the evolution chain
starting from the top and to analyse every link between
consecutive error event boxes and try to find out if
some possible barrier function could have arrested the
development. This can be done several times by experts
with different backgrounds. For some of these barrier
functions, there are existing technical, human factors or
organisational solutions, but for others those solutions
have to be invented by the analysts.
Warning signs on the roadside could have alerted the
driver so that he would have postponed going back into
the right lane until he had passed the pools of water on
the road.
6. Each existing barrier function is analysed according to
the guidelines provided later in this manual in the
section about barrier function analysis.
Here, the barrier between the traffic in different
directions, seat belts (effective barrier functions) and
the driver reactions (failing barrier function) etc. are
analysed.
7. Characteristics of the technical, human factors
andorganisational systems which may change the
strength of each existing barrier function are identified.
To exemplify, the ability of the driver to control a
skidding car (a barrier function) could be improved
through mandatory training.
8. This step includes a presentation of proposals for new
barrier functions and what is needed for their
maintenance. The step is closely related to step 5.
Signs indicating risks for skidding is a new barrier system
that would execute a new barrier function.
9. Finally, an AEB analysis concludes with a written
document giving the account of the accident and
recommendations concerning how to improve safety of
the systems analysed.
3.3. When to Stop Searching for More Errors Upstream of
the Accident Evolution
There are five informal criteria that are used to stop an
accident analysis from going further back. Thus, an analysis
can be stopped when:
. the chain of events cannot be traced further backwards in
time because necessary information is missing. The
49
analyst should consider if it is cost effective to search for
more information;
. a well-known abnormal event has been found and
accepted as a valid explanation. Here, there is a risk
of routine errors or errors that fit the fashion of the
time as initiating errors in an accident evolution
sequence;
. a barrier function is encountered that can be fixed
easily, perhaps as a result of earlier experience. Here
is the obvious risk of accepting just one effective
barrier function as the most prominent even though
defence in depth requires several effective barrier
functions. The analyst should also consider
alternative barrier systems and functions;
. there is input to a system from another less well-
known system. This stop rule depends on the
background of an analyst. To exemplify, if an
electrician makes the analysis and finds out that an
incident was caused by a human error, his analysis is
likely not to go further back beyond the human error.
In contrast, an analysis performed by a human factor
expert would go further back in order to discover the
evolution beyond the human error. This underlines
the importance of different disciplinary perspectives
applied at the same time;
. a failure event is classified as random and judged as
reflecting system characteristics. Here, there is a risk
that rare failure events that actually could have been
eliminated are neglected and the analyst should be
alerted to look for non-random causes, in particular
if the failure is important for overall system safety.
3.4. Barrier Function Analysis and Protected Systems
Analysis
A broken or non-existing barrier function signals that
there is something wrong. There is a protected system
and there are barrier function systems protecting this
system. In order to avoid further errors the barrier
function systems can be changed or the protected
system can be changed. A failing barrier function
system can be substituted or reinforced. But the
protected system can also be changed to eliminate
failures in the future. In addition, the context of the
systems can be changed to improve safety. For
example, organisational routines or technical solutions
can be altered to avoid future risks of malfunction and
error.
3.4.1. Barrier Function Systems
Before the first error box and between all pairs of
consecutive errors there can be opportunities for
50
barrier functions to arrest the accident evolution. In the
barrier function analysis all these possibilities are
considered. Therefore, the analysis starts from the top
of the AEB diagram and proceeds down towards the
accident.
As mentioned earlier, barrier functions are defined
by the system(s) they protect and the system(s) that
execute the barrier function. The essential point is to
find barrier functions protecting the system and, other
conditions being equal, it does not matter which barrier
function system executes a particular barrier function
as long as it is effective.
In the first round of analysis all existing barrier
functions are identified including the last barrier
function(s) that, hopefully, arrested the incident. When
this has been done, the diagram is again processed, this
time with the purpose of finding means to strengthen
existing barrier functions and/or alternative barrier
systems to execute the functions that failed. To give an
example , changing the organization so that it promotes
improved training would strengthen an operator as a
barrier function system. Alternatively, the system could
be changed so that a computer process performs the
checking that is normally done by the operators. To
illustrate, if an operator makes a commission error (the
operator did something that the technology was not
prepared for as input), this could have been blocked by
a computer safety system instead of an operator who
finds that something goes wrong.
3.4.2. In-Depth Analysis
Some barrier functions are candidates for systematic
indepth analysis. Such analyses can be performed using
different techniques. One such technique is to apply
AEB once more, but now in a level 2 analysis. The error
following the failing barrier function that one wants to
analyse is modelled as the accident in the level 2
analysis. The failing barrier function is modelled as an
AEB series of error boxes, when the detailed story
behind a failing barrier function is analysed. Another
technique is the causal tree technique with ‘and’
nodes, in which the failing barrier function is given the
top position and the different conditions that could be
derived behind the failure are interconnected in the
tree. After another level of AEB or other kinds of
analysis general organisational, technical and human
factors systems analyses follow.
For practical reasons, most barrier functions are
analysed directly relating to the initial (level 1) AEB
diagram. When this is done it is important both to
follow some kind of scheme and to document sources
and the evidence that the analysts use.
O. Svenson
3.4.3. Barrier Function Analysis
For each existing and possible barrier function position,
the analysts should first indicate the system(s)
executing the function. First, improvements concerning
existing barrier function are considered.. Note that
when improvements are suggested this frequently
involves system changes that can have unwanted
negative side effects on safety.
1. Possible improvements
2. The effectiveness of the suggested improvements
ifimplemented, e.g., the probability that the
improvements will arrest another accident
3. The costs of implementation – manpower, economy
andother aspects
4. Probability of implementation
5. The costs of maintaining the barrier function –
manpower, human attention resources, economy etc.
6. The probability that maintenance of the barrier function
will be kept up to standards
7. Negative side effects analysis of possible changes
8. The generalisability (to other accident sequences) of
thesuggested improvement
Second, following this analysis (or in parallel), possible
barrier functions (other than those who failed) are listed.
The above sequence, from 1 to 7, is then followed in the
analysis of the suggested barrier functions and barrier
function systems.
3.4.4. Protected Systems Analysis
Subsystems that should be protected by barrier functions
in complex technological systems are integrated in those
complex systems. In addition to questions concerning
barrier function systems, there are issues related to the
protected subsystems. If protected subsystems that are
likely to fail are substituted with less failure prone systems,
a risk has been decreased or eliminated. The two most
important questions concerning protected subsystems are:
1. Can the protected subsystem be substituted by
anotherand safer subsystem?
2. Can the protected subsystem be eliminated?
If the answer is yes to either of these questions, the new
situation has to be assessed in a risk analysis.
3.4.5. Systems Context Analysis: Organisation and Technical
systems
All barrier function failures, incidents and accidents take
place in man–technology–organisation contexts. Therefore,
an AEB analysis also includes issues about the context in
which the incident or accident took place. The
organisational and technological context provides the
 Accident and Incident Analysis
framework for an accident. Therefore, the following
questions have to be answered:
1. To increase safety, how is it possible to change the
organisation, in which the failure, incident or accident
took place? What are the possible negative side effects?
2. To increase safety, how is it possible to change the
technical systems context , in which the failure, incident
or accident took place? What are the possible negative
side effects?
It is very important to stress that when changes are made
in the organisational and technical systems far-reaching
effects may follow. In general, the higher in the
organisational context a change is made, the more general
and widespread are the effects. To exemplify, improving
the organisation for maintenance and or changing the
safety culture in a plant influences not only the sequence
in which the accident occurred, but also other sequences
that can be safer in the future.
However, most changes have both positive and negative
effects on safety. This is particularly true for organisational
changes. In addition, organisational changes have
farreaching effects, some of which are very difficult to
predict. Therefore, it is of special importance to make
careful analyses of the ‘side effects’ of organisational
changes to strengthen barrier functions. Theory and
application of knowledge about organisations and of
technical process systems are the tools for understanding
fundamental problems at the organisational and technical
systems levels identified in an AEB analysis.
3.4.6. Reporting the Results
Just as in any other accident analysis method, a
wellstructured results and recommendation section should
follow the analysis. It is recommended that forms for
collecting the data are prepared in advance and that the
model behind the forms is used when summarising the
results. The forms used for data collection and final reports
could include, for example, empty flow diagrams, the
points in Section 3.2 and reminders concerning whether an
optimal starting point and latent conditions have been
chosen (cf. Section 3.3).
4. AN ILLUSTRATION OF AN AEBANALYSIS
This section will give a brief illustration of an AEB analysis
using a dialysis accident that occurred in Sweden. The
accident was also used by Svenson, Lekberg and Johansson
(1999) in a comparison of different analysts analysing the
same accident. The accident occurred in a university
hospital when 15 patients were given dialysis at the same
time using the same equipment. One of the patients
51
suffered a heart failure during the analysis and it soon
became clear that an accident had happened. Three
patients died as a result of fatal errors in the dialysis
equipment and procedure. The container for the
concentrate mixed with water before injecting the dialysis
mixture into the blood of the patients was emptied
without replacement and therefore pure water was
injected, causing the deaths of three patients and
threatening the lives of the surviving 12 patients.
The narrative was based on records from interviews and
site visits. Lundberg’s (1992) narrative shows that the
technical equipment had several severe ergonomic and
construction failures. The equipment for dialysis was
constructed on the site and it was a non-standard set-up
designed by hospital technicians. The following AEB
analysis was made for research purposes and the final
version displayed in Fig. 3 was based on information from a
number of analysts including behavioural, medical and
engineering experts. To the left of the diagram in Fig. 3
some key words for improvements of failing barrier
functions can be found.
It was decided that because of the equipment
failures the analysis should start with the function
specifications for the equipment used when designing
the system (Fig. 3, top). The constructor–technician
ignorance of ergonomic principles and inadequate
testing resulted both in an inadequate prototype and a
deficient final product (in which, for example, alarms
and emergency stop were dependent). This serious
latent condition was modelled in its own error box.
On the day the accident occurred, the nurse in
charge incorrectly diagnosed switches for the
equipment signals as off when they were on. She
therefore switched them on – at least that was what
she thought she did. In reality, she switched off both
the alarms and the emergency stop. Following this, the
accident evolution proceeded through a set of barrier
functions, some of which were modelled in error boxes
(e.g., another staff person who could have found out
what was happening and changed concentrate
containers or stopped the process).
These failing barrier functions could have been
modelled as mediators between error boxes, but were
instead modelled in their own error boxes to make the
analysis more fine grained. This is because a more fine-
grained representation invites an analysis of why the
barrier functions failed (an analysis of ‘lower-level’
barrier functions before and after each error box). For
illustrative purposes, there was a conscious violation of
current AEB rules in that there are two arrows at the
end of the diagram leading from one box, of which one
error leads to the three patients who died and the
52
other towards the continuation of the incident and the
effective barrier function.
To illustrate the barrier function analysis, there are
barrier functions that should be up to standard
whenever technical systems are designed (nos 3, 5 and
6). Therefore, detailed specifications of these standards
with references to relevant sources should be provided
in the final report. Behind the non-existing standards
there is a failing organisation. Other barrier functions,
such as no. 9, have to be analysed in relation to the
organisation (no responsible person was available to
receive a report that the signals had not worked
O. Svenson
properly during the dialysis and therefore turned on –
in reality off – etc.). The safety culture of the
organisation would have to be assessed and
recommendations for improvements given.
For reasons of space, it is not possible to go into
more detail concerning non-existing and ineffective
barrier functions (cf. Svenson et al 1999). The diagram
in Fig. 3 should provide some hints that this accident,
like many normal accidents, involved so many failures
that it would need a long article of its own for full
coverage. Hopefully, this present illustration and the
earlier examples provide
Accident and Incident Analysis 53

Fig. 3. Graphical representation of a dialysis accident.

54
sufficient information for the interested reader to start her
or his own thinking about accidents in AEB terms.
5. DISCUSSION
The AEB method produces a condensed overview of an
accident evolution that is simpler than those of the Human
Performance Evaluation System (HPES; INPO, 1988). AEB is
also explicitly devoted to the human technology interaction
and not focusing on the human component as HPES
(however, later derivatives of HPES are much more focused
on the interaction between man and technology than the
earlier versions). AEB cannot be performed without the
simultaneous interaction of human factor and other
experts, such as engineering, traffic and medical experts.
Through its focus on errors and failures, AEB explicitly
invites analysis at every link between two boxes in order to
find out what could have arrested the accident evolution.
Accidents and incidents are analysed for learning about
causes and to guide in developing countermeasures to
avoid the same event to happen again. Also, the analyses
can be used to avoid similar events in the future and to find
out what characteristics on a higher (e.g., organisational)
level could prevent further incidents and accidents. It is
important to note that an AEB analysis leads to the
identification of broken barrier functions and in itself does
not recommend how these functions should be
strengthened or replaced. Any system change with the
intention of improving the system and the barrier functions
may be accompanied by negative side effects. Therefore,
careful systems analyses are recommended to find out
about possible unintended negative side effects of any
suggested system change.
When several incidents or accidents have been
analysed, analysts often feel a need for a classification
system of the failures causing these events. If the same
cause can be found in many incidents in the same kind of
system, it is a likely target for countermeasures to prevent
that class of incidents. To exemplify, if a fuse has been
triggered the cause of this may be classified as an
equipment error without going further and asking why
there was an equipment error (Svenson, 1999). More
complex models, such as HPES (INPO, 1988) and AEB,
normally would also need more sophisticated systems for
classification of errors and failures. However, the scope of
the present contribution was to present the AEB method
and therefore the reader is left to develop her or his own
classification system or to rely on one of the existing ones.
Acknowledgements
This study was made possible through grants from the
Swedish Nuclear Power Inspectorate (SKI). Among the
O. Svenson
View publication stats
people who have worked with initial tests and applications
of the AEB method, I want to mention Lars Andemo, Irene
Blom, Anne Edland, Pia Jacobsson, Lena Jacobsson
Kecklund, Gunnar Johansson, Anders Johansson
Hammarberg, Christer Karlsson, Anna Lekberg, Nils
Malmsten and Petra Sjo¨stedt. I learned a lot from you all.
In particular, I want to thank Anne Edland and Nils
Malmsten who coauthored an early Swedish manual. Three
reviewers and the editors provided a number of highly
relevant comments on an earlier version of the article.
References
Hale A, Wilpert B, Freitag M (eds) (1997). After the event: from accident to
organizational learning. Pergamon, Oxford.
Hollnagel E (1998). Cognitive reliability and error analysis method CREAM.
Elsevier, Oxford.
Hollnagel E (1999). Accidents and barriers. Les Valenciennes 28:175–180.
INPO (1988). Human performance evaluation system. Institute of Nuclear
Power Operations, Los Angeles, USA, 87-007 revision 01.
Johnson CW, McCarthy JC, Wright PC (1995). Using a formal language to
support natural language in accident reports. Ergonomics 38:1264–
1282.
Kjelle´n U, Larsson TJ (1981). Investigating accidents and reducing risk.
Journal of Occupational Accidents 3:129–140.
Leplat J (1997). Event analysis and responsibility in complex systems. In
Hale A, Wilpert B, Freitag M (eds). After the event: from accident to
organizational learning. Pergamon, Oxford
Lundberg A (1992). Dialysma˚let – ett o¨ppet sa˚r i svensk ra¨ttsskipning.
(The dialysis court trial – an open wound in Swedish legal practice)
Unpublished paper available from the author.
Schaaf TW (1992). Near miss reporting in the chemical process industry.
Doctoral dissertation, Technische Universiteit Eindhoven.
Schaaf TW, Lucas DA, van der Hale AR (1991). Near miss reporting as a
safety tool. Butterworth-Heinemann, Oxford.
Sjo¨stro¨m P (1997). Analys av va¨gtrafikolyckor med tre olika modeller: en
ja¨mfo¨relse. (Analysis of road traffic accidents with three different
models: a comparison). Unpublished masters thesis, Department of
Psychology, Stockholm University.
Svenson O (1990). The accident evolution and barrier model applied to
incident analysis in the processing industries. Paper presented at the
International Atomic Energy Agency: technical committee meeting on
‘Human reliability data collection and modeling’, 26 February–2 March
1990.
Svenson O (1991). The accident evolution and barrier function (AEB)
model applied to incident analysis in the processing industries. Risk
Analysis 11:499–507.
Svenson O (1999). On models of incidents and accidents. Les
Valenciennes 28:169–174.
Svenson O, Lekberg A, Johansson AEL (1999). On perspective, expertise
and differences in accident analyses: arguments for a multidisciplinary
integrated approach. Ergonomics 42:1561–1571.
Swain AD, Guttman HE (1983) Handbook of human reliability analysis with
emphasis on nuclear power plant applications. NUREG/CR-1278. US
Nuclear Regulatory Commission, Washington.
Correspondence and offprint requests to: O. Svenson, Risk Analysis, Social
and Decision Research Unit Department of Psychology, Stockholm
University, S-106 91 Stockholm, Sweden. Email: Ola.Svenson@
psychology.su.se