当前位置:首页 > 尘凡 > 正文内容

THERAC-25事件(键盘连击导致过量辐射)

满纸空言2个月前 (05-07)尘凡40810

转自:Therac-25 事件 - 每日 WTF (thedailywtf.com) 

当您将患者绑在能够发射 25MeV 粒子束的电子枪上时,以下程序至关重要。在东德克萨斯癌症中心 (ETCC) 操作 Therac-25 放射治疗机的技术人员一直在运行这台机器,以及那些类似的机器,时间足够长,以至于她已经习惯了例行公事。

1986 年 3 月 21 日,技术人员将一名患者带入治疗室。她检查了他们的处方,并把他们放在Therac-25的床上。患者上方是发射器的终点,一个转盘,允许她选择设备将发射的光束类型。首先,她将转盘设置为简单的光学激光模式,并用它来定位患者,使光束照射到他上背部的一小部分,就在他脊柱的一侧。

Therac 25 54.gif
作者:Ajzh2074 - 自己的作品, CC BY-SA 4.0, 链接

当病人处于正确的位置时,她再次旋转转盘。还有另外两个职位。一种是在光束和患者之间放置一组磁铁;这些将塑造和瞄准光束。另一个在横梁和病人之间放置了一块金属。当被25MeV的电子束击中时,金属会辐射出X射线。

这位病人的处方是电子束,所以她定位了转盘并离开了房间。在隔壁的房间里,屏蔽了辐射,是控制终端。技术人员开始输入处方以开始治疗。

如果事情完全按照常规进行,她将能够通过对讲机与患者沟通,并通过摄像机监控患者。可悲的是,这个系统今天已经崩溃了。尽管如此,这位患者已经接受过多次治疗,因此他们知道会发生什么,因此几乎不需要沟通。事实上,Therac-25 和所有支持设备总是很挑剔,所以“有些东西不起作用”实际上是例行公事的一部分。

技术人员已经运行了这个过程很多次,她开始输入处方。她已经变成了一个速度极快的打字员,至少在这台设备上是这样,而且可能太快了。在光束类型的字段中,她不小心输入了“X”,即“X射线”。这是一个自然的错误,因为大多数患者都接受了X射线治疗,这并不是什么大问题:计算机会看到转盘处于错误的位置并拒绝给患者剂量。她迅速点击键盘上的“UP”箭头返回场,将电子的值更正为“E”,并确认了其他参数。

她的手指悬停在键盘上的“B”键上,同时确认了她的数据输入。一旦她确定一切正确,她就按“B”表示“光束开始”。没有噪音,从来没有,但过了一会儿,终端显示:“故障 54”,然后是“治疗暂停”。

错误代码不足为奇。技术人员在控制台旁边保留了一张图表,其中记录了所有错误代码。在这种情况下,“故障 54”意味着“剂量输入 2”错误。

这可能并不能解释任何事情,但技术人员已经习惯了错误代码的神秘性。这是一个“治疗暂停”,这意味着下一步是恢复治疗。根据终端的说法,尚未发出辐射,因此她按下了“P”键以取消暂停光束。

就在这时,她听到了尖叫声。

患者已经经历了许多这样的会议,并且知道他们不应该有任何感觉。然而,当技术人员第一次激活光束时,他感到一种灼热的感觉,他后来形容这就像“热咖啡”被倒在他的背上。没有任何对讲机可以呼救,他开始从治疗台上下来。当技术人员松开光束时,他仍然在挣脱自己,尖叫着寻求帮助,这时他感觉到像是巨大的电击。

起初,这就是诊断。机器故障一定是触电造成的。病人被送回家,医院的物理学家检查了Therac-25,确认一切正常,没有麻烦的迹象。这似乎不会再发生了。

作为为期六周的治疗计划的一部分,患者被开了180拉德的剂量,总共将提供6,000拉德。根据Therac-25的说法,病人接受了剂量不足的治疗,只是该辐射的一小部分。目前还没有人知道,但故障实际上已经造成了 16,000 到 25,000 拉德的损失。病人看起来很好,但实际上,他们已经死了,还没有人知道。


ETCC事件不是第一次,可悲的是,这并不是Therac-25系统的最后一次故障。1985 年 6 月至 1987 年 7 月期间,发生了六起涉及加拿大原子能有限公司 (AECL) 制造的 Therac-25 的事故。每一次都是严重的辐射过量,导致严重伤害、致残和死亡。

当第一批事件开始出现时,没有人完全确定发生了什么。辐射中毒很难诊断,尤其是在您没有预料到的情况下。与ETCC事件一样,尽管患者用药过量,但机器仍报告剂量不足。当医院的物理学家怀疑服用过量时,他们甚至联系了AECL,只是被告知这样的事情是不可能的。

几周后,ETCC发生了第二次过量用药,大约在那个时候,FDA和媒体开始介入。早期,人们对原因有很多猜测。有趣的是 1986 年 RISKS 邮件列表中的这条评论

以下是我对所发生情况的推测:我怀疑在 X 射线模式下电子束中的电流可能要大得多(因为你希望在两种模式下都有相似的剂量率,而 X 射线的产生更间接)。因此,当您选择 X 射线时,我敢打赌目标会下降到位并且光束电流会增强。我怀疑在这种情况下,电流在目标移动到位之前就被增强了,并且非常高电流的电子束进入了患者体内。

怎么会允许这种情况发生呢?我的猜测是,软件人员不会认为有必要防范这种故障模式。传统上,机器设计人员使用机电联锁来确保安全。治疗机器的计算机控制是一个相当新的发展,它建立在旧的机电机制之上,而不是取代旧的机电机制。


Therac-25 是第一款完全由软件控制的放射治疗设备。正如上面Jacky的引述所指出的那样:大多数此类系统都使用硬件联锁来防止在目标配置不正确时发射光束。Therac-25 没有。

该软件包括许多在PDP-11上运行的关键模块。首先,处理系统的每个关键功能都有单独的流程:用户输入、光束对准、剂量跟踪等。这些流程中的每一个都在 PDP-11 程序集中实现。管理这些流程的是一个实时操作系统,也在 Assembly 中实现。所有这些软件,从单个进程到操作系统本身,都是单个软件开发人员的工作。

不过,AECL对这个软件充满信心,因为它并不新鲜。该软件的最早版本出现在 Therac-6 上。开发始于 1972 年,该软件于 25 年适应了 Therac-1976。Therac-20 也使用了相同的核心。在AECL内部,人们的态度是软件必须是安全的,因为他们已经使用了很长时间。

事实上,当AECL在1983年对Therac-25进行内部安全分析时,他们基于以下假设进行分析:

1) 通过在硬件模拟器上和远程治疗装置的现场条件下进行广泛测试,减少了编程错误。任何残留的软件错误都不包括在分析中。 2)程序软件不会因磨损、疲劳或复制错误而衰减。 3)计算机软件错误是由硬件组件故障引起的,以及由α粒子或电磁噪声引起的“软”(随机)错误。

换句话说:我们已经使用该软件很长时间了,软件总是可以完美地复制和部署。因此,我们看到的任何错误都必须是由辐射或硬件错误引起的暂时性错误。


在ETCC发生第二次事故后,医院物理学家停止了Therac-25的使用,并与技术人员合作,复制了导致过量服用的步骤。触发“故障 54”错误消息并不容易,尤其是当他们试图有条不紊地复制确切的步骤时,因为事实证明,如果您缓慢输入数据,则没有问题。

要触发过量,您需要快速打字,这是有经验的操作员可能拥有的速度。物理学家一直练习,直到他能够复制错误,然后通知AECL。当他进行测量以查看过量用药的程度时,AECL回电了。他们无法复制这个问题。“它在我的机器上工作,”基本上。

在接受所需速度的指导后,AECL 技术人员又回到了它,并确认他们可能会引发过量服用。当医院物理学家进行测量时,他们发现过量服用了大约4,000拉德。AECL进行了类似的测试,引发了25,000拉德的过量服用。现实情况是,根据时间的不同,输出可能是随机的。

有了这些信息,根本原因就更容易理解了:存在竞争条件。具体来说,当技术人员错误地输入X射线的“X”时,计算机将计算出光束激活顺序,以提供高能光束以产生X射线。当技术人员点击“向上”箭头来纠正他们的错误时,它应该强制重新计算该激活序列,但如果用户键入得太快,UI 将更新,并且重新计算永远不会发生。


到 1986 年年中,美国食品和药物管理局 (FDA) 参与其中,并要求 AECL 提供纠正行动计划 (CAP)。随之而来的是一个漫长的修订过程,因为AECL将提供他们的CAP,FDA将跟进问题,从而对CAP进行新的修订。

例如,FDA审查了第一次CAP修订版,并指出它不完整。具体来说,它不包括测试计划。AECL回应:

该软件没有单一的测试计划和报告,因为硬件和软件多年来一直是分开测试和练习的。

FDA对此并不满意,经过多次反复后,回答说:

我们还表达了我们的担忧,即您不打算执行 [测试] 协议以对软件进行未来修改。我们认为,每次进行修改时都必须进行严格的测试,以确保修改不会对系统的安全性产生不利影响。

虽然 AECL 努力将测试等复杂任务纳入其 CAP 中,但他们已经发布了允许临时修复以防止未来发生事件的说明。不幸的是,在1月,1987,发生了另一起事件,由不同的软件错误引起。

在这个错误中,有一个由多个进程共享的变量,旨在作为标志来决定是否需要检查转盘中的光束准直器以确保一切都处于正确的位置。如果该值不为零,则需要执行检查。如果该值为零,则不为零。不幸的是,软件会递增该字段,并且该字段只有一个字节宽。这意味着每增加 256 个增量,变量本应为非零,但该变量将为零。如果不正确的零点与操作员的动作对齐,则光束将在转盘处于正确位置的情况下以全能量发射。

AECL 对此有一个修复程序(停止递增并设置值),并修改了他们的 CAP 以包含该修复程序。美国食品和药物管理局认识到这可能会解决这个问题,但仍然有顾虑。在内部备忘录中:

我们可以说,可以合理地预期拟议的 CAP 将纠正其制定时的缺陷(Tyler)。我们不能说我们对整个系统的安全性有[合理]的信心......

这种反复持续了多次 CAP 修订。在这个过程的每一步,FDA都发现了测试问题。到目前为止,AECL的测试过程只是运行机器并记录是否有任何问题。由于该软件在某些版本中已经使用了十多年,他们认为没有任何理由测试该软件,因此没有能力或计划在FDA要求时实际测试该软件。

美国食品和药物管理局(FDA)在审查一些测试结果时指出:

令人惊讶的是,为处理 Therac-25 中的编辑问题而进行的软件更改是适当的测试数据证明了相反的结果。...我只能假设修复不正确,或者数据输入不正确。


最终,软件修复了。立法和监管方面进行了修改,以确保将来不会发生此类事件,至少不会以同样的方式发生。

值得注意的是,有一个开发人员编写了所有这些代码。他们于 1986 年离开了 AECL,值得庆幸的是,没有人透露过他们的身份。虽然把责任归咎于他们可能很诱人——他们做出了每一个技术选择,他们编写了每一个错误——但这样做是非常不公平的。

由于AECL一直未能解释如何测试他们的设备,因此应该清楚该问题是一个系统性问题。你的软件开发人员有多好并不重要;软件质量不会因为你有优秀的开发人员而出现。这是一个过程的最终结果,这个过程既可以通知你的软件开发实践,也可以通知你的测试。您的管理层。甚至您的销售和服务。

虽然ETCC的事件最终推动了变革,但它们并不是第一次事件。医院的物理学家已经向AECL报告了问题。至少有一名患者已经提起诉讼。但这些信息并没有在组织中传播;没有人把这些碎片放在一起来识别设备有故障。

在这个网站上,我们开了很多玩笑,以牺牲这个世界的宝拉·比恩罗伊为代价。但是,无论多么无能,无论多么鲁莽,无论TDWTF文章的对手多么无知,他们都是一个系统的一部分,而这个系统将他们置于那个位置。

IT 中的故障很少是单个故障。它们是进程失败。它们是系统性失败。它们是组织的失败。AECL 和 Therac-25 的故事说明了组织失败的结局有多严重

AECL没有软件流程。他们并不认为软件只是一个更大整体的一个组成部分。在这种环境下,在安全关键系统上工作,没有一个开发人员能够完全成功。鉴于这种情况确实是生命垂危的情况,建立一个能够生产安全、优质软件的系统似乎应该是一个优先事项。事实并非如此。

虽然 Therac-25 事件已成为古老的历史,但软件变得更加重要。虽然我们希望安全关键型软件具有严格的流程,但我们知道这并不总是正确的。737MAX是最近一个臭名昭著的例子。但是,随着软件在现代世界中的重要性,即使是更琐碎的软件问题也会大规模增加。无论是强化种族主义的机器学习,社交网络变成虚假信息的污水池,还是安全性差的物联网设备变成僵尸网络,我们的软件都存在并与世界互动,并产生现实世界的后果。

如果不出意外,我希望这篇文章能让你思考一下你用来创建软件的过程该过程是否旨在生产质量?质量存在哪些障碍?质量是重中之重吗,如果不是,为什么不呢?您的流程是否考虑了大规模的质量?您可能知道软件的故障模式,但您了解组织的故障模式吗?它的盲点是什么?它做出的假设可能并非在所有情况下都有效?


让我们暂时回到导致ETCC事件的比赛条件。这是由于用户点击向上箭头的速度太快,导致系统无法正确注册其编辑。虽然 FDA CAP 流程仍在进行中,但 AECL 希望确保人们仍然可以安全地使用 Therac-25,这意味着发布用户可以应用于其设备的快速修复程序。

这是AECL为解决该错误而发出的信函:

主题:THERAC-25 直线加速器
操作程序变更 立即生效,直至另行通知,用于在处方序列中将光标向后移动的键(即刻有向上箭头的光标“UP”)不得用于编辑或任何其他目的。
为避免意外使用此钥匙,必须取下钥匙盖,并用电工胶带或其他绝缘材料将开关触点固定在打开位置。
如需后者的帮助,请联系您当地的 AECL 服务代表。
禁用此键意味着,如果输入的任何处方数据不正确,则必须使用“R”重置命令并重新输入整个处方。
对于多端口选项的用户来说,这也意味着无法在端口之间编辑剂量率、剂量和时间。

一方面,这是一个简单的指令,可以有效地防止ETCC事件再次发生。另一方面,想象一个病人的生命挂在撕裂的键帽和电工胶带上是很可怕的。


本文旨在对事件进行简要总结。本文中的大部分技术细节都来自对 Therac-25 事件的详细描述。这是关于这个主题权威来源,我建议阅读整篇文章。它包含更多细节,包括更深入地研究软件选择和组织故障。

扫描二维码推送至手机访问。

版权声明:本文由满纸空言发布,如需转载请注明出处。

本文链接:https://mzky.cc/post/151.html

分享给朋友:
返回列表

上一篇:科学上网翻越高墙

没有最新的文章了...

“THERAC-25事件(键盘连击导致过量辐射)” 的相关文章

CSRF漏洞修复3年前 (2021-06-10)
解决goland显示导入异常3年前 (2021-07-19)
UOS编译keepalived3年前 (2021-08-06)
Git 保存用户名和密码3年前 (2021-08-16)

发表评论

访客

看不清,换一张

◎欢迎参与讨论,请在这里发表您的看法和观点。