From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: 11232c,59ec73856b699922 X-Google-Attributes: gid11232c,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-ArrivalTime: 2003-05-11 13:59:29 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!wn12feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!sccrnsc04.POSTED!not-for-mail Message-ID: <3EBEB9AE.2060704@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,misc.misc Subject: Re: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died) References: <9fa75d42.0304230424.10612b1a@posting.google.com> <9fa75d42.0305010621.55e99deb@posting.google.com> <254c16a.0305011035.13133e8d@posting.google.com> <9fa75d42.0305011727.5eae0222@posting.google.com> <17cd177c.0305072114.24f04783@posting.google.com> <9fa75d42.0305090612.261d5a5c@posting.google.com> <9fa75d42.0305091549.48b9c5d9@posting.google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.62.164.137 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc04 1052686768 24.62.164.137 (Sun, 11 May 2003 20:59:28 GMT) NNTP-Posting-Date: Sun, 11 May 2003 20:59:28 GMT Organization: AT&T Broadband Date: Sun, 11 May 2003 20:59:28 GMT Xref: archiver1.google.com comp.lang.java.advocacy:63527 comp.object:63207 comp.lang.ada:37197 misc.misc:14090 Date: 2003-05-11T20:59:28+00:00 List-Id: John R. Strohm wrote: > It only takes one such error in safety-critical code to kill someone. > (To the best of my knowledge, the actual code error behind the > Therac-25 fatalities has never been explained. I would not be at all > surprised to learn that it was a buffer indexing problem that could > have been caught automatically by a type-safe language used > properly.) I can't let that comment about Therac-25 pass unchallenged. Nancy Leveson has a very complete write-up on the Therac-25 problems. The link http://sunnyday.mit.edu/therac-25.html will let you choose between PDF and Postscript versions. The paper is 49 pages long, and I quail at trying to describe all the safety problems found in much less text. However, at least two specific software errors that could--and did--kill patients were found and connected with specific Therac-25 overdose incidents. Other cases could be from one or the other of these bugs, or several dozen other problems, but there is insufficient data to be certain. The two bugs identified with particular patient deaths were one where, if the operator to edited the settings and hit P (for procede) within 8 seconds after an error message, some key settings were not rechecked. In the other, a semaphore was incremented instead of being set to a specific value. The semaphore was one byte long, and the code involved periodically checked settings. If you hit the right key (I think it was B this time) just after the semaphore rolled over, some checks were in effect bypassed. However, the particular software bugs that were actually determined to have killed patients were a minor part of the entire Therac-25 debacle. The real problem was that the system as a whole--hardware and software--was so buggy, and documentation and manufacturer support were so poor, that operators were used to ignoring software error codes and hardware "glitches." I'd have to re-read the entire report to be sure, but I think that in all but one case of a patient overdose, the operator continued operation after some error message appeared. As far as I am concerned, once I read that there was an error message, that indicated the dosage was too high or too low, and that if it was too high the displayed dosage was too low, I sort of gave up. I don't even want to think about Pointy-Haired Bosses and safety-critical software beyond that. I might be tempted to go on a shooting rampage. Nancy's report is practically a catalog of every type of design, management and process error you can make in building a safety-critical system. Using Ada might have helped, at least with those two bugs, but the real necessity was a safety-critical development process.