COMP60611 Directed Reading 1: Therac-25

Slides:



Advertisements
Similar presentations
ES050 – Introductory Engineering Design and Innovation Studio Prof. Ken McIsaac One last word…
Advertisements

ENGG1100 Introduction to Engineering Design Omni-wheel Car Additional Documentation.
CSCI 5230: Project Management Software Reuse Disasters: Therac-25 and Ariane 5 Flight 501 David Sumpter 12/4/2001.
“An Investigation of the Therac-25 Accidents” by Nancy G. Leveson and Clark S. Turner Catherine Schell CSC 508 October 13, 2004.
The Therac-25: A Software Fatal Failure
Background Increasing use of automated systems Hardware and software technology are improving rapidly User interface technology is lagging Critical bottleneck.
An Investigation of the Therac-25 Accidents Nancy G. Leveson Clark S. Turner IEEE, 1993 Presented by Jack Kustanowitz April 26, 2005 University of Maryland.
Can We Trust the Computer? Case Study: The Therac-25 Based on Article in IEEE-Computer, July 1993.
Therac-25 Lawsuit for Victims Against the AECL
+ THE THERAC-25 - A SOFTWARE FATAL FAILURE Kpea, Aagbara Saturday SYSM 6309 Spring ’12 UT-Dallas.
Computingcases.org Safeware
Week 5 - Wednesday.  What did we talk about last time?  Attacks on hash functions.
Accelerators. Electron Beam  An electron beam can be accelerated by an electric field. Monitors Mass spectrometers  Any charged particle can be accelerated.
Motivation Why study Software Engineering ?. What is Engineering ? 2 Engineering (Webster) – The application of scientific and mathematical principles.
SWE Introduction to Software Engineering
Jacky: “Safety-Critical Computing …” ► Therac-25 illustrated that comp controlled equipment could be less safe. ► Why use computers at all, if satisfactory.
©Ian Sommerville 2004Software Engineering, 7th edition. Insulin Pump Slide 1 The portable insulin pump Developing a dependability specification for the.
Software Failures Ron Gilmore, CMC Edmonton April 2006.
Lecture 7, part 2: Software Reliability
Dr Andy Brooks1 Lecture 4 Therac-25, computer controlled radiation therapy machine, that killed people. FOR0383 Software Quality Assurance.
DJ Wattam, Han Junyi, C Mongin1 COMP60611 Directed Reading 1: Therac-25 Background – Therac-25 was a new design dual mode machine developed from previous.
Death by Software The Therac-25 Radio-Therapy Device Brian MacKay ESE Requirements Engineering – Fall 2013.
Therac-25 : Summary Malfunction Complacency Race condition (turntable / energy mismatch) Data overflow (turntable not positioned) time‘85‘86‘88 ‘87 Micro-switch.
Software Safety Case Study Medical Devices : Therac 25 and beyond Matthew Dwyer.
Therac-25 Final Presentation
Therac 25 Nancy Leveson: Medical Devices: The Therac-25 (updated version of IEEE Computer article)
Chapter 18 Limitations of Computing. Chapter Goals – THE BIG SLICES Limitations of Hardware Limitations of Software Limitations of Problems 2.
ITGS Software Reliability. ITGS All IT systems are a combination of: –Hardware –Software –People –Data Problems with any of these parts, or a combination.
Course: Software Engineering © Alessandra RussoUnit 1 - Introduction, slide Number 1 Unit 1: Introduction Course: C525 Software Engineering Lecturer: Alessandra.
Liability for Computer Errors Not covered in textbook.
XpsOES : A New Tool for Improving Safety at Workplace Yasar Kucukefe, Ph.D., National Power Energy.
Security and Reliability THERAC CASE STUDY TEXTBOOK: BRINKMAN’S ETHICS IN A COMPUTING CULTURE READING: CHAPTER 5, PAGES
Dimitrios Christias Robert Lyon Andreas Petrou Dimitrios Christias Robert Lyon Andreas Petrou.
© 2008 Wayne Wolf Overheads for Computers as Components 2nd ed. System design techniques Quality assurance. 1.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Slide 1 Critical Systems Specification 1.
Therac-25 CS4001 Kristin Marsicano. Therac-25 Overview  What was the Therac-25?  How did it relate to previous models? In what ways was it similar/different?
CS, AUHenrik Bærbak Christensen1 Critical Systems Sommerville 7th Ed Chapter 3.
Dr. Rob Hasker. Classic Quality Assurance  Ensure follow process Solid, reviewed requirements Reviewed design Reviewed, passing tests  Why doesn’t “we.
CSCI 3428: Software Engineering Tami Meredith Chapter 7 Writing the Programs.
Dr. Rob Hasker. Classic Quality Assurance  Ensure follow process Solid, reviewed requirements Reviewed design Reviewed, passing tests  Why doesn’t “we.
Directed Reading 1 Girish Ramesh – Andres Martin-Lopez – Bamdad Dashtban –
$100 $200 $300 $400 $500 $100 $200 $300 $400 $500 $100 $200 $300 $400 $500 $100 $200 $300 $400 $500 $100 $200 $300 $400 $500 $100 $200 $300.
CHAPTER 9: PROFESSIONAL ETHICS AND RESPONSIBILITIES BY: MATT JENNINGS SHANE CRAKER KYLER RHOADES.
Interlock Systems for Machine Protection Manuel Zaera-Sanz Interlocks Engineer – ICS / Protection Systems AD and ICS Retreat mtg December 2014.
Lecture 14 Page 1 CS 236 Online Secure Programming CS 236 On-Line MS Program Networks and Systems Security Peter Reiher.
SPiiPlus Training Class
WANG chuanzhen PENG wei XIAO min LI Chunsong (SQHL)
Protecting Memory What is there to protect in memory?
Why study Software Design/Engineering ?
Lesson Plan MRI Scan Experience
Electron Beam Therapy.
ATTRACT TWD Symposium, Barcelona, Spain, 1st July 2016
Chapter 4 MATLAB Programming
EE 585 : FAULT TOLERANT COMPUTING SYSTEMS B.RAM MOHAN
Overview Introduction General Register Organization Stack Organization
When I want to execute the subroutine I just give the command Write()
Therac-25 Accidents What was Therac-25? Who developed it?
Omni-wheel Car Additional Documentation
Reliability and Safety
Therac-25.
System design techniques
Therac-25: A Lesson Learned
Design Is design important? 75%-80% of system errors are created in the analysis and design phases. Analysis and design phases account for about only.
Social and Ethical Issues in Programming Language Design
Lesson Plan MRI Scan Experience
Lesson Plan MRI Scan Experience
Social and Ethical Issues in Programming Language Design
Social and Ethical Issues in Programming Language Design
Lesson Plan MRI Scan Experience
Outline Introduction Memory protection Buffer overflows
Presentation transcript:

COMP60611 Directed Reading 1: Therac-25 Introduction: Therac-25 is a medical linear accelerator, used for destroying tumours with electron beams: Shallow tissue treated directly by low energy electron beams (~ 5 – 15 MeV) Deeper tissue treated with X-rays, which are generated by firing high energy electron beam (~ 25 MeV) at a target. Between June 1985 and January 1987, six people were massively overdosed: Due to 25 MeV beam setting being used in direct irradiation mode. Unlike earlier machines (i.e. Therac-6, Therac-20), Therac-25 had no hardwired interlock to prevent high-energy beam from being used when patient/turntable setup for direct irradiation: Therac-25 relied on software for safety checks One of the software faults that led to overdosing was a concurrency bug. A. Michelis, L. Wang, C. Goddard 2nd October 2011

COMP60611 Directed Reading 1: Therac-25 Tyler software bug: Operator edits mode/energy input field on console and returns to command line. Software calls “magnet” subroutine, which sets magnet positions (takes ~ 8 seconds). If operator edits mode/energy input field on console during this 8 seconds, change is not recognised by system, though displayed on console. Therefore, machine could operate in “electron” mode with 25 MeV beam. Yakima software bug: “Class3” shared variable is incremented every time “Set Up Test” is executed (i.e. several hundred times) As Class3 is a single byte variable, maximum value is 255. Every 256th pass through Set Up Test, Class3 overflows and has zero value: Collimator position checking subroutine is skipped A. Michelis, L. Wang, C. Goddard 2nd October 2011

COMP60611 Directed Reading 1: Therac-25 Main mistakes: Reuse of the Therac-20 software for the Therac-25 The circumstances were different as they removed the hardware safeties for the Therac-25 Too much confidence given to the software No safety analysis of the software at first Bad engineering process Design too complex, poor testing, bad error detection & reporting Poor investigations led by AECL/poor reactions after they were alerted of the incidents They learned about a first lawsuit but did not act consequently, when they were aware of a bug they just fixed the "symptom" and not the root cause (the whole design should have been changed) A. Michelis, L. Wang, C. Goddard 2nd October 2011