archive-org.com » ORG » C » COMPUTINGCASES.ORG

Total: 197

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Role Playing the Case
    In class give each group the description of the two Tyler incidents Also give to them the explanation of the Tyler code and why it produced Malfunction 54 This is what each participant knew shortly after the Tyler accidents Allow each group 15 minutes to produce a proposal regarding what should be done Keep this part of the assignment vague enough to allow them to propose a wide variety of

    Original URL path: http://computingcases.org/case_materials/therac/exercises/role_playing.html (2016-04-30)
    Open archived version from archive


  • Aliases in Therac25
    our presentation is not to blame individuals but to see the ethical and social issues that surround the design manufacture and use of computing systems in the real world We have not attempted to hide the identity of some organizations that were widely known e g the Food and Drug Administration Therac 25 is the real name of the machine involved in this case and we felt it useless to

    Original URL path: http://computingcases.org/case_materials/therac/supporting_docs/therac_resources/Aliases%20in%20this%20case.html (2016-04-30)
    Open archived version from archive

  • Therac History
    million electron volt MeV accelerator capable of producing X rays only and later 2 the Therac 20 a 20 Me V dual mode X rays or electrons accelerator Both were versions of older CGR machines the Neptune and Sagittaire respectively which were augmented with computer control using a DEC PDP 11 minicomputer Software functionality was limited in both machines The computer merely added convenience to the existing hardware which was capable of standing alone Industry standard hardware safety features and interlocks in the underlying machines were retained We know that some old Therac 6 software routines were used in the Therac 20 and that CGR developed the initial software The business relationship between CMC and CGR faltered after the Therac 20 effort Citing competitive pressures the two companies did not renew their cooperative agreement when scheduled in 1981 In the mid 1970 s CMC developed a radical new double pass concept for electron acceleration A double pass accelerator needs much less space to develop comparable energy levels because it folds the long physical mechanism required to accelerate the electrons and it is more economic to produce since it uses a magnetron rather than a klystron as the energy source Using this double pass concept CMC designed the Therac 25 a dual mode linear accelerator that can deliver either photons at 25 Me V or electrons at various energy levels see Figure 1 Compared with the Therac 20 the Therac 25 is notably more compact more versatile and arguably easier to use The higher energy takes advantage of the phenomenon of depth dose As the energy increases the depth in the body at which maximum dose buildup occurs also increases sparing the tissue above the target area Economic advantages also come into play for the customer since only one machine is required for both treatment modalities electrons and photons Several features of the Therac 25 are important in understanding the accidents First like the Therac 6 and the Therac 20 the Therac 25 is controlled by a PDP 11 However CMC designed the Therac 25 to take advantage of computer control from the outset CMC did not build on a stand alone machine The Therac 6 and Therac 20 had been designed around machines that already had histories of clinical use without computer control In addition the Therac 25 software has more responsibility for maintaining safety than the software in the previous machines The Therac 20 has independent protective circuits for monitoring electron beam scanning plus mechanical interlocks for policing the machine and ensuring safe operation The Therac 25 relies more on software for these functions CMC took advantage of the computer s abilities to control and monitor the hardware and decided not to duplicate all the existing hardware safety mechanisms and interlocks This approach is becoming more common as companies decide that hardware interlocks and backups are not worth the expense or they put more faith perhaps misplaced on software than on hardware reliability Finally some software for the machines

    Original URL path: http://computingcases.org/case_materials/therac/supporting_docs/levenson/Therac%20History.html (2016-04-30)
    Open archived version from archive

  • Turntable
    third position called the field light position involves no beam at all it facilitates correct positioning of the patient Proper operation of the Therac 25 is heavily dependent on the turntable position the accessories appropriate to each mode are physically attached to the turntable The turntable position is monitored by three microswitches corresponding to the three cardinal turntable positions electron beam X ray and field light These microswitches are attached to the turntable and are engaged by hardware stops at the appropriate positions The position of the turntable sent to the computer as a 3 bit binary signal is based on which of the three microswitches are depressed by the hardware stops The raw highly concentrated accelerator beam is dangerous to living tissue In electron therapy the computer controls the beam energy from 5 to 25 MeV and current while scanning magnets spread the beam to a safe therapeutic concentration These scanning magnets are mounted on the turntable and moved into proper position by the computer Similarly an ion chamber to measure electrons is mounted on the turntable and also moved into position by the computer In addition operator mounted electron trimmers can be used to shape the beam if necessary For X ray therapy only one energy level is available 25 MeV Much greater electron beam current is required for photon mode some 100 times greater than that for electron therapy Rawlinson to produce comparable output Such a high dose rate capability is required because a beam flattener is used to produce a uniform treatment field This flattener which resembles an inverted ice cream cone is a very efficient attenuator To get a reasonable treatment dose rate out a very high input dose rate is required If the machine produces a photon beam with the beam flattener not in

    Original URL path: http://computingcases.org/case_materials/therac/supporting_docs/levenson/The%20TurnTable.html (2016-04-30)
    Open archived version from archive

  • Software Design
    minimal with most effort directed at the integrated system test At a Therac 25 user group meeting the same quality assurance manager said that the Therac 25 software was tested for 2 700 hours Under questioning by the users he clarified this as meaning 2 700 hours of use The programmer left CMC in 1986 In a lawsuit connected with one of the accidents the lawyers were unable to obtain information about the programmer from CMC In the depositions connected with that case none of the CMC employees questioned could provide any information about his educational background or experience Although an attempt was made to obtain a deposition from the programmer the lawsuit was settled before this was accomplished We have been unable to learn anything about his background CMC claims proprietary rights to its software design However from voluminous documentation regarding the accidents the repairs and the eventual design changes we can build a rough picture of it The software is responsible for monitoring the machine status accepting input about the treatment desired and setting the machine up for this treatment It turns the beam on in response to an operator command assuming that certain operational checks on the status of the physical machine are satisfied and also turns the beam off when treatment is completed when an operator commands it or when a malfunction is detected The operator can print out hard copy versions of the CRT display or machine setup parameters The treatment unit has an interlock system designed to remove power to the unit when there is a hardware malfunction The computer monitors this interlock system and provides diagnostic messages Depending on the fault the computer either prevents a treatment from being started or if the treatment is in progress creates a pause or a suspension of the treatment The manufacturer describes the Therac 25 software as having a stand alone real time treatment operating system The system is not built using a standard operating system or executive Rather the real time executive was written especially for the Therac 25 and runs on a 32K PDP 11 23 A preemptive scheduler allocates cycles to the critical and noncritical tasks The software written in PDP 11 assembly language has four major components stored data a scheduler a set of critical and noncritical tasks and interrupt services The stored data includes calibration parameters for the accelerator setup as well as patient treatment data The interrupt routines include a clock interrupt service routing a scanning interrupt service routing traps for software overflow and computer hardware generated interrupts power up initiated at power up to initialize the system and pass control to the scheduler treatment console screen interrupt handler treatment console keyboard interrupt handler service printer interrupt handler service keyboard interrupt handler The scheduler controls the sequences of all noninterrupt events and coordinates all concurrent processes Tasks are initiated every 0 1 second with the critical tasks executed first and the noncritical tasks executed in any remaining cycle time Critical

    Original URL path: http://computingcases.org/case_materials/therac/supporting_docs/levenson/Software%20Design.html (2016-04-30)
    Open archived version from archive

  • Safety analysis
    for the Therac 25 are high dose per pulse and illegal gantry motion The immediate causes for the event are then generated in an AND OR tree format using a basic understanding of the machine operation to determine the causes The tree generation continues until all branches end in the basic events Operationally a basic event is sometimes defined as an event that can be quantified for example a resistor fails open CMC used a generic failure rate of 10 4 per hour for software events The company justified this number as based on the historical performance of the Therac 25 software The final report on the safety analysis said that many fault trees for the Therac 25 have a computer malfunction as a causative event and the outcome of quantification is therefore dependent on the failure rate chosen for software Leaving aside the general question of whether such failure rates are meaningful or measurable for software in general it seems rather difficult to justify a single figure of this sort for every type of software error or software behavior It would be equivalent to assigning the same failure rate to every type of failure of a car no matter what particular failure is considered The authors of the safety study did note that despite the uncertainty that software introduces into quantification fault tree analysis provides valuable information in showing single and multiple failure paths and the relative importance of different failure mechanisms This is certainly true Software examination Because of the difficulty of quantifying software behavior CMC contracted for a detailed code inspection to obtain more information on which to base decisions The software functions selected for examination were those related to the Class I software hazards identified in the FMEA electron beam scanning energy selection beam shutoff and dose calibration The outside consultant who performed the inspection included a detailed examination of each function s implementation a search for coding errors and a qualitative assessment of its reliability The consultant recommended program changes to correct shortcomings improve reliability or improve the software package in a general sense The final safety report gives no information about whether any particular methodology or tools were used in the software inspection or whether someone just read the code looking for errors Conclusions of the safety analysis The final report summarizes the conclusions of the safety analysis The conclusions of the analysis call for 10 changes to Therac 25 hardware the most significant of these are interlocks to back up software control of both electron scanning and beam energy selection Although it is not considered necessary or advisable to rewrite the entire Therac 25 software package considerable effort is being expended to update it The changes recommended have several distinct objectives improve the protection it provides against hardware failures provide additional reliability via cross checking and provide a more maintainable source package Two or three software releases are anticipated before these changes are completed The implementation of these improvements including design and testing

    Original URL path: http://computingcases.org/case_materials/therac/supporting_docs/levenson/Safety%20Analysis.html (2016-04-30)
    Open archived version from archive

  • Operator Interface
    field sizing gantry rotation and accessory data The system then compares the manually set values with those entered at the console If they match a verified message is displayed and treatment is permitted If they do not match treatment is not allowed to proceed until the mismatch is corrected Figure A shows the screen layout Figure A Operator interface screen layout When the system was first built operators complained that it took too long to enter the treatment plan In response the manufacturer modified the software before the first unit was installed so that instead of reentering the data at the keyboard operators could use a carriage return to merely copy the treatment site data Miller A quick series of carriage returns would thus complete data entry This interface modification was to figure in several accidents The Therac 25 could shut down in two ways after it detected an error condition One was a treatment suspend which required a complete machine reset to restart the machine If a treatment pause occurred the operator could press the P key to proceed and resume treatment quickly and conveniently The previous treatment parameters remained in effect and no reset was required This convenient and simple feature could be invoked a maximum of five times before the machine automatically suspended treatment and required the operator to perform a system reset Error messages provided to the operator were cryptic and some merely consisted of the word malfunction followed by a number from 1 to 64 denoting an analog digital channel number According to an FDA memorandum written after one accident The operator s manual supplied with the machine does not explain nor even address the malfunction codes The Maintenance Manual lists the various malfunction numbers but gives no explanation The materials provided give no indication

    Original URL path: http://computingcases.org/case_materials/therac/supporting_docs/levenson/Interface.html (2016-04-30)
    Open archived version from archive

  • Tyler Software
    entry and changes the Data entry completion variable to denote this Once the Data entry completion variable is set the Datent subroutine detects the variable s change in status and changes the value of Tphase from 1 Data Entry to 3 Set Up Test In this case the Datent subroutine exits back to the Treat subroutine which will reschedule itself and begin execution of the Set Up Test subroutine If the Data entry completion variable has not been set Datent leaves the value of Tphase unchanged and exits back to Treat s main line Treat will then reschedule itself essentially rescheduling the Datent subroutine The command line at the lower right corner of the screen is the cursor s normal position when the operator has completed all necessary changes to the prescription Prescription editing is signified by cursor movement off the command line As the program was originally designed the Data entry completion variable by itself is not sufficient since it does not ensure that the cursor is located on the command line Under the right circumstances the data entry phase can be exited before all edit changes are made on the screen The keyboard handler parses the mode and energy level specified by the operator and places an encoded result in another shared variable the 2 byte mode energy offset MEOS variable The low order byte of this variable is used by another task Hand to set the collimator turntable to the proper position for the selected mode energy The high order byte of the MEOS variable is used by Datent to set several operating parameters Initially the data entry process forces the operator to enter the mode and energy except when the operator selects the photon mode in which case the energy defaults to 25 MeV The operator can later edit the mode and energy separately If the keyboard handler sets the data entry completion variable before the operator changes the data in MEOS Datent will not detect the changes in MEOS since it has already exited and will not be reentered again The upper collimator on the other hand is set to the position dictated by the low order byte of MEOS by another concurrently running task Hand and can therefore be inconsistent with the parameters set in accordance with the information in the high order byte of MEOS The software appears to include no checks to detect such an incompatibility Figure 3 Datent Magnet and Ptime subroutines The first thing that Datent does when it is entered is to check whether the mode energy has been set in MEOS If so it uses the high order byte to index into a table of preset operating parameters and places them in the digital to analog output table The contents of this output table are transferred to the digital analog converter during the next clock cycle Once the parameters are all set Datent calls the subroutine Magnet which sets the bending magnets Figure 3 is a simplified pseudocode

    Original URL path: http://computingcases.org/case_materials/therac/supporting_docs/levenson/Tyler%20Software%20Problem.html (2016-04-30)
    Open archived version from archive



  •