放疗设备的软件缺陷 (Therac-25)：一台更省事的医疗设备，为什么会在软件上反复造成同一类事故？

# 商业复盘备忘录：放疗设备的软件缺陷 (Therac-25)

> 一台更省事的医疗设备，为什么会在软件上反复造成同一类事故？
> 周期: 1983 - 1987 | 行业: 医疗与健康
> 巅峰: 医疗设备厂商推出的放射治疗设备，以软件控制替代了大量硬件安全措施，因操作更简便而在医院中被广泛采用
> 终局: 软件缺陷导致多起严重过量照射事故，多名患者死亡或受伤，设备被召回停用，医疗设备软件的开发与监管标准因此被永久改写

## 核心概览
当安全交给软件，软件的缺陷就变成了病人的剂量。巅峰期医疗设备厂商推出的放射治疗设备，以软件控制替代了大量硬件安全措施，因操作更简便而在医院中被广泛采用；终局是软件缺陷导致多起严重过量照射事故，多名患者死亡或受伤，设备被召回停用，医疗设备软件的开发与监管标准因此被永久改写。

## 社区公投头号死因
1. [产品技术] 用软件替代硬件安全联锁 (959 票)
2. [组织管理] 软件测试未覆盖并发与时序场景 (806 票)
3. [外部合规] 事故反馈与信息共享机制缺失 (652 票)

## 可执行教训
### 安全功能应当在软件之外保留独立防线
> 把「软件失效时谁来兜底」当作设计问题，而不是实现细节。

- ✅ 推荐做 (DOs):
  - 为安全关键功能保留独立于软件的防护机制
  - 对并发与时序场景做专门测试
- ❌ 绝不能做 (DON'Ts):
  - 不要用软件替代所有硬件安全措施
  - 不要把同类事故当作个案处理

## 救亡方案
### 先把独立安全防线补回来，再谈设备可用性 — 良略编辑部
干预时点: 1986 年多起事故被集中报告、软件竞态条件被确认为主因时
- 必须断腕:
  - 停止在无独立安全联锁的情况下继续使用设备
  - 停止把事故归因于操作失误
  - 停止依赖常规测试覆盖并发场景
- 破局动作:
  - 为安全关键功能恢复独立防护机制
  - 对时序与并发场景做专门建模与测试
  - 建立统一的设备事故上报与信息共享机制
- 预期结果: 设备具备独立的失效防护，同类风险在设计与验证阶段被覆盖。

## 社区见解
### 这批事故最沉重的地方在于：医院一开始以为是自己操作错了，而事实是软件在特定节奏下会忽略安全设置。 — 良略编辑部 (工程师)
设备的旧型号有独立的硬件联锁，即使操作有误也不会输出超量剂量；新型号为了操作便利，把这些防护改由软件承担，结果当操作员用熟练的高速节奏输入指令时，软件会进入一个未预期的分支，界面显示的是正常状态，实际的束流却是过量的。这类竞态条件的可怕之处在于它难以复现：同样操作十次可能九次都正常，而错误的那一次没有规律。加上事故早期分散在不同医院、上报渠道不统一，问题被拖延了很久才被集中发现。此后，医疗设备软件被纳入更严格的监管与验证体系，代价是几位患者的生命。
- 如果重来一次的纠偏招式 安全设计的原则是「纵深防御」：任何单一环节都可能是那个出错的环节。

---
来源: 良略 · https://www.lianglue.com/c/therac-25