1) The 1992 failure of the London Ambulance Service's computer aided dispatch system was caused by a combination of factors including flaws in the software, an unreasonable project timeline imposed by LAS management, and the inexperience of the vendor selected to develop the system. 2) Key issues included reusing outdated hardware, selecting an inexperienced vendor based primarily on cost, failing to involve key stakeholders in requirements gathering, and not following proper software development processes. 3) While software errors directly caused the failure, both LAS management and the developing vendor share responsibility - LAS for unreasonable constraints and vendor selection, and the vendor for taking on a project beyond its capabilities.

1. MSOE - SE-3811 - FORMAL METHODS, DR. WELCH, SPRING 2006 1
The 1992 London Ambulance Service Computer
Aided Dispatch System Failure
Erich Musick
Abstract— This paper goes beyond a simple glance at the 1) Call Taking : When a call requesting emergency am-
immediate results of the 1992 failure of the London Ambulance bulance service was received, the call taker filled out a paper
Service’s computer aided dispatch system and explores the form, found the caller’s location on a map, and then put the
sequence of events leading up to the incident in attempt to
determine professional responsibility and how the project might form on a conveyor belt [2].
have benefited from a more formal specification of the software 2) Resource Identification : The conveyor belt took the
system. forms to another LAS employee who analyzed the locations
and statuses of ambulances in the call’s region. He then
assigned the call to an available unit and wrote the assignment
I. I NTRODUCTION
on the form [2].
W HILE failures in software are perhaps one of the more
quickly excused types of defects (after all, it is surely
much easier to forget to free memory than it is to miscalculate
3) Resource Mobilization : Finally, a dispatcher made
contact with the ambulance to which the call was assigned
and provided the operator(s) with the details of the call [2].
the amount of weight a bridge can hold), they are not immune Looking back on this system from the perspective of 2006,
to causing immense amount of damage. The integration of in which computers dominate everyday life, a manual system
software into millions of modern electromechanical devices, that relies on people’s memories, paper, and human reasoning
combined with the fallibility of its developers allows room for for optimal resource utilization seems silly. Indeed, even at the
a wide margin of error. time, some of these inefficiencies were acknowledged and a
The London Ambulance Service’s (LAS) 1992 computer new, computer-based system was proposed [2].
aided dispatch (CAD) software system failure is one instance
of the considerable negative effect that a small error in
software can have on a large population of people. A careful
examination of the events surrounding the incident, however, C. Proposed System
suggests that there was more to the issue than just an error in
The government-imposed stipulation that calls be responded
the software. Rather, the overall carelessness with which the
to within three minutes, in addition to the obvious deficiencies
application’s development was approached from its conception
of the manual dispatch system led those in charge of the
set the stage for such a grand failure.
LAS seek out a computer-based alternative [2]. The proposed
system’s highlights consisted of an automatic vehicle locating
II. T HE L ONDON A MBULANCE S ERVICE system (AVLS) and mobile data terminals (MDTs) that would
A. Overview be placed inside emergency vehicles and would facilitate
communication using a computer terminal [1].
In 1992, the LAS provided ambulance service to 6.8 million
people living in a 600 square mile area. Of its 318 emergency The LAS looked at adopting an existing system but found
ambulances, an average of 212 were in service at any given problems with each of the available options. LAS manage-
time, in addition to 445 transport ambulances, one helicopter, ment decided to create a new one and proceeded to gather
and a motorcycle response unit. A total of 70 ambulance requirements without receiving input from ambulance crews
stations which employed 2746 staff members housed these ve- or dispatchers [2].
hicles. The entire system was managed from a central location Management set big goals. Rather than simply assisting
at the LAS Headquarters in Waterloo. On average, between dispatchers, this completely computerized system would do
2000 and 2500 calls were received daily, 60% of which were nearly everything automatically. The simple sequence of steps
requests for emergency services. The LAS devoted 55% of its performed by a person would be to answer the phone, enter
staff and 76% of its budget specifically to emergency response incident data into a computer terminal, and then respond if
[2]. According to Wikipedia, the LAS remains the “largest the system displayed exception messages resulting from no
ambulance service in the world that does not directly charge ambulances being available for longer than 11 minutes. The
its patients for its services” [4]. locations of calls would be mapped by the software. The
system would then use this map data and the location and
status details provided by the AVLS to find and dispatch the
B. Existing System available ambulance closest to the incident’s location. To top
In the mid-1980s, the LAS emergency dispatch system was it off, this system would be implemented not incrementally,
run completely manually and consisted of three main tasks: but all at once [2].

2. MSOE - SE-3811 - FORMAL METHODS, DR. WELCH, SPRING 2006 2
III. T HE FAILURE needed. As with any memory leak, after enough time, the
memory filled up and caused the system to fail [2].
A. What Happened
After a whole slew of issues, including a project cancellation IV. D EEPER C AUSES
and re-design, a software system got developed and was
deployed the morning of October 26, 1992 [2]. Just a few IEEE member and risk management expert Robert Charette
hours later, however, problems began to arise. The AVLS was suggests, “Bad decisions by project managers are probably the
unable to keep track of the ambulances and their statuses in single greatest cause of software failure today” [3]. While the
the system. It began sending multiple units to some locations software controlling the LAS’s CAD system had some key
and no units to other locations. The efficiency with which flaws, without which the system may not have failed to the
it assigned vehicles to call locations was substandard. The extent it did, the events surrounding the failure, the state of the
system began to generate such a great quantity of exception LAS as an organizational entity, and the process with which
messages on the dispatchers’ terminals that calls got lost. The the LAS approached the development of the CAD played just
problem was compounded when people called back additional as large, if not a larger role in the system’s failure.
times because the ambulances they were expecting did not Getting the LAS CAD system to the point of deployment
arrive. As more and more incidents were entered into the was challenging and opened the doors for failure to creep in at
system, it became increasingly clogged. The next day, the LAS several points. The original design of the LAS’s CAD system
switched back to a part-manual system, and shut down the was first proposed in 1987. It was modified in 1989 and then,
computer system completely when it quit working altogether due to gross overspending by about 300%, the project was
eight days later [1]. canceled in 1990. However, the national mandate to reduce
Because of the large area serviced by the LAS, many people emergency response times pushed the LAS to look into a
were directly affected by the computer system failure. There computerized system once again. [2].
were as many as 46 deaths that would have been avoided had
the requested ambulance arrived on time. One heart attack A. Hardware Reuse
patient waited six hours for an ambulance before her son took When the project was re-opened, those LAS individuals in
her to the hospital. Four hours after that, the LAS called to charge of it approached it with the primary goal to save as
see if the ambulance was still needed. Another woman called much time and money as possible. While this is a reasonable
the LAS every 30 minutes for almost three hours before an aim of any project, it held too much weight in the LAS’s CAD
ambulance arrived. It was too late, as her husband had already project. As part of the attempt to save money, the LAS decided
died. One ambulance crew arrived only to find that the patient to reuse some of the hardware that had already been purchased
had not only died, but his body had been taken away by a when working on the failed project instead of purchasing
mortician [2] hardware that was either more up-to-date or more suitable for
the new system [2].
B. Immediate Causes
At the time the system went live, there were 81 known B. Vendor Selection
issues with the software and no load-tests had been run. No The two people who were primarily in charge of choosing
provisions for a backup system had been made. While the a software vendor for creating the system were “a manager
gap of 10 months between the time dispatchers were first expecting to become redundant and a contractor who was
trained to use the software and when it was deployed played a temporary addition to the organisation.” These individuals’
its role in the disaster, the software had three primary flaws roles and their lack of stake in the project draw in to question
that immediately caused the failure: their ability to select the best company for the job. Further,
1) Imperfect Data : The software system did not function the selection committee weighed a bid’s price as the most
well when given invalid or incomplete data regarding the important factor in selecting a vendor. All companies that
positions and statuses of ambulances [2]. submitted bids greater than £1.5 million were immediately
2) Interface Issues : The deployed system had a wide thrown out. This is an unreasonably low price, especially
variety of quirks in different parts of the user interface. For considering the fact that even after £7.5 million had been
example, parts of the MDT terminal screens had black spots, poured into the previous attempt at a CAD system, the project
thus preventing ambulance operators from getting all infor- had failed [2].
mation needed. When ambulance crews attempted to remedy Selection of a developing organization was further con-
mistakes after pushing incorrect wrong buttons, the system did strained by the requirement that the project be completed in 11
not accept the fix. Again, the software failed to compensate for months. Once again, any bids not meeting this hard constraint
the error conditions that occur in normal, day-to-day operation were not considered. Several companies proposed modified
[2]. deployment schedules in which some functionality would be
3) Memory Leak : The root cause of the main breakdown delivered after the 11 month deadline and the rest a year later.
of the system, however, was a memory leak in a small These, too, were thrown out. [2].
portion of code. This defect retained memory that held incident The LAS accepted a bid of just under £1 million that was
information on the file server even after it was no longer submitted by a conglomeration of companies. The software

3. MSOE - SE-3811 - FORMAL METHODS, DR. WELCH, SPRING 2006 3
portion of the system was “offered as a throw-in in a hardware likely would not have failed as it did [5]. Additional time to
deal” for a meager £35 thousand and was completed by a develop the software would have allowed the developers to
company called System Options. The fact that the majority more meticulously follow the software process and provide
of the cost for this package which relied heavily on software an opportunity for adequate testing of the entire system. Had
went instead toward hardware should have raised a flag that the LAS selected a different company with more experience
something was askew [2]. with real-time applications to develop the CAD system, the
Further, System Options was declared the project lead. project could have benefited from a firmer foundation for the
Though it had developed many smaller software packages, software’s conception.
System Options had never worked on such a large project Although the LAS erred in its decision to choose System
and had absolutely no past experience with “real-time, safety- Options to develop the CAD software, System Options is by no
critical, command and control systems.” Its inexperience de- means absolved of blame. Consider a surgeon who specializes
veloping such software led the contractor selection committee in orthopedic surgery but is completely inexperienced in heart
to raise concerns over the company’s ability to perform the task surgery. He volunteers to perform an important and difficult
at hand. However, even though these concerns were further heart surgery in one-eighth the time it would take an expe-
substantiated by an audit of the selection process, the LAS rienced heart surgeon to do it. Although this doctor believes
hired the company [2]. he is capable of performing the surgery, his inexperience and
stringent time restraints make this a high risk surgery better
C. Design, Requirements, and Specifications suited for a surgeon trained in the specific task. Similarly,
System Options’ lack of background in real time systems and
The process through which requirements were gathered and insufficient allotment of time to complete the project should
specifications and designs were written had several major have provided sufficient reason for company decision makers
flaws. First, it seems that a LAS team - not a software devel- to refrain from bidding on the project.
opment team - went through this process without attempting to One might argue that System Options is not responsible for
consult ambulance operators, dispatchers, and other key users the small window of development time, as it was a restriction
of the system. A basic understanding of the software require- imposed by the LAS. However, had no company suggested that
ments process suggests that leaving out key stakeholders is successful delivery was possible in the time frame the LAS
detrimental to the project and will result in an incomplete required, the LAS would have realized that it was unreasonable
set of requirements. Further, the requirements document was and either expanded the time frame or abandoned the project.
“highly detailed and extremely prescriptive,” very much a System Options’ acceptance of the bid implied that it was,
direct contradiction of the requirements process’ focus on the indeed, possible to create a successful CAD solution in the
what as opposed to the how. Once the companies completing time frame given.
the project were selected, they were required to provide a final While the LAS pushed for expedient delivery, System
system design specification. The LAS incorrectly assumed that Options, as “professionals” in the area of software system
if the contractor could do this, they understood the system they development, had an obligation to protect the public. Knowing
had to create. However, there was no signoff on this design that the system was incomplete, untested and buggy, System
specification and it was updated after development began [2]. Options took an enormous risk in deploying it. It failed to
do its duty to sufficiently evaluate this risk and refuse to
D. Flawed Software Process release, just as those involved with the Challenger space shuttle
Several other parts of the software process played a large incident minimized a known risk and thus failed to keep the
role in the eventual failure of the deployed product. No spacecraft from launching. Even if System Options had a lot
quality assurance was performed, configuration management riding on the timely release of the software, the loss the failure
was absent, agreed-upon changes were not tracked, and test caused was far greater than any monetary investment that could
plans were not written, just to name a few. At one point in the ever be made.
CAD system’s development, the LAS considered hiring one
of the other bidders to perform some quality assurance tasks. VI. C ONCLUSION
Because this was seen as the job of the developing organi- Though a small software error often is the straw that breaks
zation, this idea was disregarded [2]. Though any developing the camel’s back, the responsibility for the LAS’s CAD system
organization should be able to ensure its products’ quality, failure does not lie solely on the single developer who made
testing is impossible when getting the project coded in the the error or even the developing organization to which he
allotted 11 months is an already an unachievable goal. belonged. Rather, the attitudes of key LAS members toward
the project and the unreasonable restraints they placed on the
V. R ESPONSIBILITY project allowed the failure to occur.
While it is true that the CAD system’s software errors
demonstrate “carelessness and lack of quality assurance of R EFERENCES
program code changes,” had the LAS paid more attention to
[1] A. Finkelstein, J. Dowell, “A comedy of errors: the London Ambulance
selection process of the developing organization and imposed Service case study,” iwssd, p. 2, 8th International Workshop on Software
more reasonable and realistic expectations, the CAD system Specification and Design (IWSSD’96), 1996.

4. MSOE - SE-3811 - FORMAL METHODS, DR. WELCH, SPRING 2006 4
[2] D. Dalcher, “Disaster in London: The LAS Case study,” ecbs, p. 41, IEEE
Conference and Workshop on Engineering of Computer-Based Systems,
1999.
[3] R.N. Charette, “Why Software Fails,” IEEE Spectrum, Vol. 42, Issue 9,
Sept. 2005, p. 42-49.
[4] “London Ambulance Service,” Wikipedia, Mar. 20, 2006, Available
http://en.wikipedia.org/wiki/London Ambulance Service, Apr. 10, 2006.
[5] D. Page, P. Williams, and D. Boyd, Report of the Inquiry into the London
Ambulance Service, Communications Directorate, South West Thames
Regional Health Authority, London, Feb. 1993.