维基百科

Therac-25案例

Therac-25事件是在软件工程界被大量引用的案例。Therac-25是加拿大原子能有限公司（AECL）所生产的放射线疗法机器，在Therac-6和Therac-20之后推出（以往的Therac-6和Therac-20是加拿大原子能有限公司和法国的CGL公司合作开发）。在1985年到1987年之间，在美国及加拿大至少有六起和Therac-25相关的医疗事故，因为软件设计时的瑕疵，使病人受到了过量的辐射[1]:425。软件的瑕疵是因为竞争危害（二个同时进行程序之间时序冲突造成的问题），有瑕疵时会使病患接受到比正常剂量高一百倍的辐射，因此造成患者死亡或重伤[2]。

此一事故突显了安全关键系统若使用软件控制时的潜在危险性，也是软件工程及医学资讯学的经典案例。另外因为工程师的过度自信[1]:428，而且没有进行适当的尽职调查来修复已知的软件问题，这也是一个极端的例子，工程师因为对其初期的工程过度自信，没有相信终端用户提出的问题，最后产生了严重的结果。Therac-25事件后，软件开发工程化管理方法论开始得到重视。

设计

编辑

Therac-25可以进行二种放射线疗法：

若是要进行直接电子束疗法，装置会直接产生低能量的电子束，利用电磁铁扫描方式让电子束分散到安全的剂量范围。若是要进行百万伏特级X射线疗法，装置会转动四个零件调整电子束的路径，使电子束进入X射线腔中，而X射线腔也有装置会侦测电子束的强度。

问题描述

编辑

此事件发生时，所发射的是高能量的电子束，而不是预期的低能量电子束，而且装置对应的零件没有让电子束进入X射线腔中。以前的机种有硬件互锁机制以避免这种情形发生，而Therac-25取消了硬件互锁机制，为了安全起见改用软件的互锁机制。软件互锁机制在有竞争危害时会失效。其缺陷如下：有一个测试程序中一字节的计数器常常会溢出，若操作员恰好在计数器溢出时输入命令，软件互锁机制会失效[2]。

高能量的电子束给予的能量是理想辐射剂量的100倍，是可能会造成β辐射的致命剂量。患者Ray Cox描述其感觉像“强烈的电击”，他因此尖叫跑出诊疗室[3]。几天后病人开始出现辐射灼伤（英语：radiation burn），病人也开始出现辐射过量的症状，其中有三个病患后来因为辐射过量而死亡[4]。

根本原因

编辑

调查委员会调查后的结论是此一系列事故的主因是不良的软件设计及开发实务，没有明确的将主因归因到所找到的软件编程错误。而软件的设计方式也让软件在实务上不可能以自动化测试进行测试[5]。

研究这系列事故的研究者发现了几个造成此事件的主因，包括了以下的组织层面原因：

  • AECL没有将代码由第三方来进行审查。
  • AECL在软件设计评估时，没有考虑装置产生预期结果的方式，以及会有哪些已知的失效模式，这些形成了可靠度建模及风险管理的通用技巧。
  • 系统在运作时，有发现有组件异常，中止了X光束，但是其显示只显示了"MALFUNCTION"（机能异常），后面配合了1到64的数字，而使用手册没有说明这些异常消息，甚至连消息都没有列出。因此操作员按了P键，跳过了警告消息，继续运作。
  • AECL的人员，以及机器的操作者一开始不相信用户的抱怨，这可能是因为过度的自信[1]:428。
  • AECL在到医院组装Therac-25装置之前，完全没有将软件及硬件一起组合测试。

研究者也发现一些工程方面的原因：

  • 装置中有一个VT-100（英语：VT-100）终端（控制PDP-11电脑），此错误只有在操作员在终端键盘上输出二个不常输入的按键组合后才会出现，先输入X选择（错误的）25 MeV X光模式，之后输入E，选择（正确的）25 MeV 电子模式，之后输入Enter，三个按键组合在8秒钟内完成[5]，上述的按键组合看起来很少会按到，因此这个问题也不是很常出现，长期没有被重视[3]。
  • 设计上没有加入硬件互锁机制避免电子束运作在高能量模式，而且没有对应X光腔。
  • 工程师复用了以前旧机种的代码，旧机种有硬件互锁机制，因此软件上的问题没有造成失效。硬件的互锁机制也没有产生对应报告，说明互锁曾被触发，因此没有办法看出存在错误的软件指令。
  • 硬件没有提供软件对应方式来确认传感器是否有正常工作（参考开回路控制器）。X光腔和X光转向系统是首先造成此失效的原因。制造商曾建议增加冗余的开关来交互检查其状态及运作。
  • 装置的控制行程没有和操作员接口的行程建立互斥锁，因此若操作员设置的太快，就有可能有竞争危害。这部分在测试时没有测到，因为操作员需要一段时间熟悉相关操作，才能输入的够快，触发此一失效模式。
  • 软件中有设置旗标变量，但是有变化时会让变量加1，而不是将其设置为固定的非零值，因此偶尔会出现算术溢出，让旗标变量变为0，软件就会跳过安全相关的检查。

此软件是用汇编语言撰写，因此在软件的设计和测试时需要耗费更多精力。不过语言选择本身没有列为事故的主要原因。装置也使用其自己的操作系统。

Leveson指出此事件的一个重大教训就是不可以假设复用的软件就一定安全： “有一个天真的假设，就是认为软件复用以及用现有的商业软件可以增加安全性，因为要使用的软件已经频繁使用过。复用的软件模块无法保证在配合新系统使用时的安全性...”[5]。为了因应像Therac-25这类的事件，创立了IEC 62304（英语：IEC 62304）标准，导入了针对医疗装置的开发生命周期标准，而且也有针对使用未知谱系的软件（英语：software of unknown pedigree）时的特定建议作法[6]。

参见

编辑

参考资料

编辑
  1. ^ 1.0 1.1 1.2 Baase, Sara. A Gift of Fire. Pearson Prentice Hall. 2008. 
  2. ^ 2.0 2.1 Leveson, Nancy G.; Turner, Clark S. An Investigation of the Therac-25 Accidents (PDF). IEEE Computer. July 1993, 26 (7): 18–41 [2017-03-25]. （原始内容存档 (PDF)于2004-11-28）. 
  3. ^ 3.0 3.1 Casey, Steven. Set Phasers On Stun - Design and Human Error. Aegean Publishing Company. : 11–16. 
  4. ^ Rose, Barbara Wade. Fatal Dose - Radiation Deaths linked to AECL Computer Errors. www.ccnr.org. [2016-06-14]. （原始内容存档于2018-01-06）. 
  5. ^ 5.0 5.1 5.2 Nancy G. Leveson, University of Washington. Medical Devices: The Therac-25 Accidents (PDF). Safeware: System Safety, and Computers Update of the 1993 IEEE Computer article (Addison-Wesley). 1995 [2017-03-25]. （原始内容 (PDF)存档于2008-02-16）. 
  6. ^ Hall, Ken. Developing Medical Device Software to IEC 62304. MDDI - Medical Device and Diagnostic Industry. June 1, 2010 [2016-12-12]. （原始内容存档于2016-11-12）. 

延伸阅读

编辑


检索自“https://zh.wikipedia.org/w/index.php?title=Therac-25案例&oldid=72707566”