软件架构：Therac-25——致命辐射机器
介绍
Therac-25：致命的辐射机器
软件漏洞
结论
更多，更多，还有……
由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！
介绍
每天上课，我都会反复强调软件必须经过测试，因为他们是在拿人的生命开玩笑。他们觉得我是在开玩笑
，因为我们开发的只是使用简单的RESTful API进行一些简单的计算的Web服务。所以，对他们来说，测试只是额外的工作，他们并不认为测试是软件开发中不可或缺的一部分。
历史可以证明，这条小小的建议在开发医疗软件时至关重要。
17 年前，我还在读计算机科学的时候 :-(，
教授们向我们解释说，软件工程
与传统工程（例如建筑）一样负有民事责任，因为
如果桥梁坍塌，我们就要承担与建筑师相同的责任……在一次软件质量课上，我们讨论了著名的 Therac-25 案例，这些天在和学生们交流之后，我又想起了这个案例。
Therac-25：致命的辐射机器
1982年，加拿大原子能有限公司
（AECL）研制出一种名为Therac-25的放射治疗仪，用于癌症治疗
。该仪器利用辐射和X射线进行治疗，是Therac-20的改进型，造价约为100万美元。Therac-25在大多数
使用情况下效果良好，但也导致多人死亡，并
引发其他患者罹患严重疾病。调查过程中，共确认了6起与该仪器相关的死亡或副作用案例。
该机器提供两种放射治疗模式：
- 直接电子束治疗，其中一束窄而低电流的高能（5 MeV 至 25 MeV）电子束通过磁铁扫描治疗区域；
- 兆伏级X射线（或光子）疗法，是通过将一束能量为25兆伏、电流强度是普通X射线100倍的窄束电子束撞击靶材而产生的，然后将发射出的X射线依次通过均整滤波器和准直器。——维基百科
它还包括“视野照明”模式，该模式通过可见光照亮治疗区域，使患者能够正确定位。
该软件主要负责：
- 监控机器
- 接受治疗方案
- 设置机器以进行此项治疗
- 最后，在治疗过程中控制机器。
软件漏洞
软件中出现的漏洞很难识别。
漏洞出现的过程如下：
- 操作员在治疗开始时（使用用户界面）配置机器时出错。
- 使用机器软件进行了校正。
- 用户界面显示一切正常，或者说没有停止该过程，而是允许继续进行辐射操作。
- 患者接受的辐射剂量高达原定剂量的 125 倍。
该软件开发过程中遇到的主要问题如下：
- 程序员们并没有考虑到操作员可能会在配置过程中出错，从而需要重新配置机器。他们假定操作员总是会选择正确的配置路径。这正是为什么建议由与软件开发人员不同的人员进行测试的主要原因之一，因为开发人员对软件的使用非常熟悉，他们很少出错，而是能够做到近乎完美地使用。
- 他们没有进行任何形式的测试，也就是说，他们只是在开发软件时，在软件运行成功的情况下才对其进行测试。
一个委员会得出结论，造成这场灾难的主要原因是软件架构错误和软件开发实践不完善。该委员会并未将错误归咎于具体的编程错误，而这些错误本可以通过应用软件质量最低标准来避免。
大多数新手开发的软件由于
软件功能和组件之间的强耦合性而难以测试。真正令人惊讶
的是，一家专注于医疗器械的公司开发的价值约100万美元的软件，竟然存在与新手代码完全相同的问题。也就是说，由于开发质量低下，委托方根本无法进行任何测试。
委员会得出的结论如下：
- AECL 没有对软件代码进行独立审查（仅供开发人员审查）。
- AECL 在评估机器如何产生预期结果以及存在哪些故障模式时，并未考虑软件的设计。
这些构成了可靠性建模和风险管理等通用技术的一部分。
-
系统检测到故障并停止了X射线束，但屏幕上只显示“故障”字样，后面跟着1到64之间的数字。用户手册没有解释或提及这些错误代码，因此操作员按下P键忽略警告并继续操作。
-
AECL员工以及机器操作员最初并不相信
这些投诉。这很可能是由于他们过于自信造成的。 -
在医院组装之前， AECL从未对 Therac-25 的软硬件组合进行过测试。
研究人员还发现了一些工程方面的问题：
-
只有当在控制 PDP-11 计算机的 VT-100 终端上输入特定的非标准按键序列时才会发生故障：先按“X”键（错误地）选择 25 MeV 光子模式，然后按“光标向上”，再按“E”键（正确地）选择 25 MeV 电子模式，最后按“Enter”键，所有这些操作都在八秒钟内完成。
-
该设计没有任何硬件联锁装置来防止电子束在没有靶材的情况下以高能模式运行。
-
这位工程师重复使用了旧型号的软件。这种做法体现了所谓的“货物崇拜式编程”，即盲目依赖先前编写的代码，而这些代码本身理解不足，甚至可能并不适用。这些旧型号的硬件联锁装置掩盖了其软件缺陷。这些硬件安全装置无法报告其已被触发，因此无法检测到错误的软件指令。
-
硬件无法让软件验证传感器是否
正常工作（参见开环控制器）。工作台定位系统是Therac-25故障的首要原因；制造商对其进行了改进，增加了
冗余开关以交叉验证其运行情况。 -
设备控制任务与操作界面任务未能正确同步
，因此如果操作员更改
设置过快，就会出现竞争条件。由于
操作员需要一些练习才能快速操作以触发此故障模式，因此在测试过程中未能发现此问题。 -
该软件通过递增而非设定
固定的非零值来设置标志变量。偶尔会发生算术溢出，导致标志变量返回零，软件绕过安全检查。
结论
它呈现了医学和软件工程史上一个著名的案例，揭示了软件
工程中的不良做法是如何夺走人们生命的。
这个故事促使我们认真思考，如同其他工程领域一样，软件开发也需要制定最低
质量标准。虽然大多数软件应用并非至关重要，但也存在一些关键软件，例如安装在机场、飞机、汽车、卫生设备、电梯等场所的软件。如果缺乏最低质量标准，最终后果可能不堪设想。
因此，软件开发绝非简单的复制粘贴代码。那些自以为是超级黑客或神明，无需在自己编写的代码中引入软件测试的人，应该像建筑师或船舶工程师未能达到质量要求一样受到惩罚。
然而，事故总是难以避免，其原因未必是由于
无知或不良操作。软件开发是一门日趋
成熟的科学。尽管如此，每天都有新的专业人士
加入，他们需要接受充分的培训，并融入良好的软件工程实践文化。