Question

The Therac-25 Radiaiton Overdoses

1. What were the all of the software & design problems in The Therac- 25? Explain why they were problems.

2. Why were there so many incidents from The Therac-25?

3. Who’s largely responsible or to blame for the failure of The Therac- 25?

4. If a judge had to assign responsibility in this case, how much responsibility should they have assigned to the programmer, the manufacturer, and the hospital or clinic using the machine?

Answer 1

1ANS:The Therac-25 is a medical linear accelerator manufactured by AECL. A linear accelerator is a particle accelerator, a device that increases the energy of electrically charged atomic particles. The charged particle are accelerated by the introduction of an electric field, producing beams of particles which are then focused by magnets
Linacs are used to treat cancer patients. A patient is exposed to beams of particles, or radiation, in doses designed to kill a malignancy. Since malignant tissues are more sensitive than normal tissues to radiation exposure, a treatment plan can be developed that permits the absorption of an amount of radiation that is fatal to tumor cells but causes relatively minor damage to normal tissue. Shallow tissue is treated with electrons, but to reach deeper tissue, X-ray photons are needed .

Software:
The design of real-time computing systems is the most challenging and complex task that can be undertaken by a software engineer. By its very nature, software for real-time systems makes demands on analysis, design, and testing techniques that are unknown in other application areas.
The Therac-25's software was developed from the Therac-20's software, which was developed from the Therac-6's software. One programmer, over several years, revised the Therac-6 software into the Therac-25 software (AECL has not released any information about the programmer or his credentials). An important difference between the Therac-20 software and the Therac-25 software is the overall role that each plays in the machine. In the Therac-20, the role of software is limited. The software simply adds convenience to the hardware. However, in the Therac-25, software exclusively performs many of the critical safety checks of the system; these safety checks are also included in the hardware of the Therac-20, but were not included in the Therac-25 hardware. The Therac-25 software is responsible for:
monitoring the machine status
accepting input about the treatment
setting the machine up for the treatment
turning on the treatment beam
turning off the treatment beam, either after a successful treatment or under a malfunction
detecting hardware malfunction and delivering diagnostic messages and either a pause or suspend of treatment
The last two responsibilities reveal some of the ways that the software is responsible for the safety of the system.
The Therac-25 runs on an custom-designed real-time operating system. The software has four major components: stored data, a scheduler, a set of critical and non-critical tasks, and interrupt services. The interrupt services include (among others): a treatment console screen interrupt handler and a treatment console keyboard interrupt handler. The scheduler directs all non-interrupt events and orders simultaneous events. Tasks are divided into critical and non-critical categories. Every 0.1 seconds tasks are initiated and critical tasks are executed first, with non-critical tasks taking up any remaining time. Critical tasks include:
The treatment monitor (Treat) directs and monitors patient setup and treatment
The servo task regulates gun emission, dose rate, symmetry, and machine motions, machine parameters, and does some error handling
The housekeeper task checks setup verification and takes care of system-status interlocks and limit checks
Non-critical tasks include .
Treatment console keyboard processor which acts as the interface between the software and the operator
Treatment console screen processor
2Ans)The first accident, in 1985, AECL was informed about the situation and was asked if the Therac-25 could operate in electron mode without scanning to spread the beam (as described in the hardware section). When AECL responded three days later, it was to say that improper scanning was impossible. The hospital staff had a difficult time discerning the cause of the first burn, because they had never seen a radiation burn of this severity. Eventually, the patient was estimated to have received a dose in the range of 15,000 - 20,000 rad (radiation absorbed dose). To help put this dosage amount into perspective, a normal dose is in the "200-rad range, and doses of 500 -1,000 rad can be fatal if delivered to the whole body . The patient eventually initiated a lawsuit against the hospital and AECL. Even upon notification of the lawsuit, AECL did not proceed to investigate the possible occurrence of scanning failure. They continued to believe that such an event was impossible .
AECL responded to the second accident by sending a service engineer to investigate the Therac-25 machine. He was unable to reproduce the malfunction that took place, but suspected that the problem lie in a microswitch used to determine turntable position. In trying to fix this situation, AECL uncovered some problems involving the turntable positioning. AECL made some hardware and software changes to fix these problems. After the changes, AECL wrote a letter to the hospital claiming to have increased the safety of the machine by "at least five orders of magnitude", yet they did not really discover why the accident occurred. The were merely guessing. AECL informed only four users in the United States to discontinue treatment with an "H-tilt" error message. AECL voluntarily recalled the machine while making the above mentioned changes to it .

3ANS)Overconfidence in Software.
A common mistake in engineering, in this case and in many others, is to put too much confidence in software. There seems to be a feeling among nonsoftware professionals that software will not or cannot fail, which leads to complacency and overreliance on computer functios.
A related tendency among engineers is to ignore software. The first safety analysis on the Therac-25 did not include software --- although nearly full responsibility for safety rested on it. When problems started occurring, it was assumed that hardware had caused them, and the investigation looked only at the hardware.

Confusing Reliability with Safety.
This software was highly reliable. It worked tens of thousands of times before overdosing anyone, and occurrences of erroneous behavior were few and far between. AECL assumed that their software was safe because it was reliable, and this led to complacency.
Lack of Defensive Design.
The software did not contain self-checks or other error-detection and error-handling features that would have detected the inconsistencies and coding errors. Audit trails were limited because of a lack of memory. However, today larger memories are available and audit trails and other design techniques must be given high priority in making tradeoff decisions.