[科普中国]-Therac-25案例

Therac-25事件是在软件工程界被大量引用的案例。Therac-25是Atomic Energy of Canada Limited所生产的一种辐射治疗的机器。由于其软件设计时的瑕疵，致命地超过剂量设定导致在1985年6月到1987年1月之间，六件已知的医疗事故中，患者死亡或严重辐射灼伤。事后的调查发现整个软件系统没有经过充分的测试，而最初所做的Therac-25全分析报告中有关系统安全分析只考虑了系统硬件，没有把计算机故障（包括软件）所造成的隐患考虑在内。

设计该机提供三种放射治疗模式：

1、直接电子束治疗，其中通过磁体在治疗区域上扫描窄电流的高能（5MeV至25MeV）电子束;

2、Megavolt X射线治疗，通过将一个狭窄的100倍电流的25 MeV电子束与目标相撞，产生固定的宽X射线束，然后将发射的X射线通过平坦滤波器和准直器;

3、“场光”模式，通过用可见光照射治疗区域，使患者能够正确定位。

问题描述当X射线模式产生的高电流电子束直接传递给患者时，发生了六起事故。两个软件故障是罪魁祸首：一，当操作员在快速切换到电子模式之前错误地选择X射线模式时，允许将电子束设置为X射线模式而不需要X射线靶。第二个故障允许电子束在场光模式下激活，在此期间没有光束扫描器处于活动状态或目标处于适当位置。

以前的型号有硬件互锁以防止此类故障，但Therac-25已将其移除，取决于软件检查的安全性。

高电流电子束以大约100倍的预期辐射剂量击中患者，并且在较窄的区域内，提供可能致命剂量的β辐射。患者Ray Cox将这种感觉描述为“强烈的电击”，导致他尖叫并跑出治疗室。几天后，出现放射性烧伤，患者出现放射性中毒症状;在三例中，受伤的患者后来因过量服用而死亡1。

根本原因一个委员会的结论是，主要原因应该归咎于糟糕的软件设计和开发实践，而不是明确地发现了几个编码错误。特别是，该软件的设计使得实际上不可能以干净的自动方式对其进行测试。

调查事故的研究人员发现了几个原因。这些包括以下制度原因：

1、AECL没有独立审查的软件代码。

2、在评估机器如何产生预期结果以及存在哪种故障模式时，AECL没有考虑软件的设计。这些形成了称为可靠性建模和风险管理的一般技术的一部分。

3、系统注意到出现了问题并停止了X射线束，但只显示了“MALFUNCTION”字样，后跟1到64之间的数字。用户手册没有解释甚至解决错误代码，因此操作员按下了P键覆盖警告并继续进行。

4、AECL人员以及机器操作员最初都不相信投诉。这可能是由于过度自信造成的。

5、AECL从未使用软件和硬件的组合测试Therac-25，直到它在医院组装。

研究人员还发现了几个工程问题：

仅在控制PDP-11计算机的VT-100终端上输入特定的非标准击键序列时发生故障：“X”到（错误地）选择25 MeV光子模式，然后是“向上光标”，“E”至（正确）选择25 MeV电子模式，然后“输入”，均在8秒内完成。[6]这一系列的击键是不可能的，因此这个问题并不经常发生，并且很长时间没有被注意到。

该设计没有任何硬件互锁，以防止电子束在没有目标的情况下以其高能模式运行。

工程师重用了旧型号的软件。这种方法在所谓的货物崇拜节目中表现出来，其中盲目依赖于先前创建的代码，该代码被很难理解并且可能适用或可能不适用。这些模型具有掩盖其软件缺陷的硬件互锁。这些硬件安全无法报告它们已被触发，因此没有迹象表明存在错误的软件命令。

硬件无法让软件验证传感器是否正常工作（参见开环控制器）。桌位系统是第一个涉及Therac-25失败的系统;制造商用冗余开关对其进行了修改，以交叉检查其操作。

设备控制任务未与操作员界面任务正确同步，因此如果操作员更快地更改设置，则会出现竞争条件。这在测试过程中被遗漏了，因为在操作员能够快速工作以触发此故障模式之前需要一些练习。

软件通过递增来设置标志变量，而不是将其设置为固定的非零值。偶尔会发生算术溢出，导致标志返回零并且软件绕过安全检查。

该软件是用汇编语言编写的，可能需要更多关注测试和良好的设计。但是，语言本身的选择并未列为报告中的主要原因。该机器还使用了自己的操作系统。

Leveson指出，从事件中吸取的教训是不要假设重复使用的软件是安全的：“通常假设重复使用软件或使用商业现成的软件会增加安全性，因为软件将被运用重复使用软件模块并不能保证它们被转移到的新系统的安全性......“这种对软件编码范式知之甚少的盲目信仰被称为货物崇拜编程。针对与Therac-25相关的事件，创建了IEC 62304标准，该标准引入了医疗设备软件的开发生命周期标准，以及使用未知谱系软件的具体指导。

本词条内容贡献者为:

王沛 - 副教授、副研究员 - 中国科学院工程热物理研究所