Therac-25案例

维基百科,自由的百科全书
跳转至: 导航搜索

Therac-25事件是在軟體工程界被大量引用的案例。

Therac-25是Atomic Energy of Canada Limited所生產的一種輻射治療的機器。由於其軟體設計時的瑕疵,劑量設定超過安全範圍,導致在1985年六月到1987年一月之間,六件已知的醫療事故中,患者死亡或受到嚴重輻射灼傷[1]

Therac-25事件也因而喚醒軟體開發工程化管理方法論的省思。

Therac 25系统和软件安全性典型案例分析[编辑]

上世纪80年代中期、美国和加拿大的Therac 25放射治疗仪,发生了多次医疗事故,若干病人治疗后死亡。病人提出诉讼,逐渐引起媒体和公众注意,美国食品与药物管理局(FDA)逐渐参与了事件调查。设备制造商起初一再声称,对仪器制造提供了严格的质量监控,再加上一部分关键设计人员早以离职,原始文档缺乏,事故场景难于重现,调查过程进展缓慢。80年代末,才最终确定事故是由超剂量辐射造成,但实际上,深层的原因是系统和软件的安全性设计方面存在严重问题。现在Therac 25事故已经成为美国大学讲解软件安全性设计的一个经典案例。

Therac 25 及其功能简介[编辑]

Therac 系列仪器是由加拿大原子能有限公司(AECL)和法国CGL公司联合制造的一种医用高能电子线性加速器,用来杀死病变组织癌细胞,同时使其对周围健康组织影响尽可能降低。

放射线治疗肿瘤技术起源于20世纪60年代,Therac 25属于第三代医用高能电子线性加速器,具有两种工作模式。其一是加速电子模式,用来治疗相对较浅的病变。其二是X射线模式,这种模式,将25兆电子伏特的电子束,转化为X射线,用来治疗较深度的病变。

Therac 6 和Therac20是Therac 25的前身,Therac 6能量为6兆电子伏特,只有一种X射线工作模式,Therac20 属于第二代医用高能电子线性加速器,能量为20兆电子伏特,具有电子和X射线两种工作模式。这两种型号的仪器都具有独立的合乎工业标准的硬件控制系统,对病人的治疗完全依靠硬件实施,仪器采用硬件反锁技术控制过剂量辐射,治疗过程耗时较长。两种仪器都配置有PDP11计算机,但计算机控制属辅助性质,计算机软件控制仅为在某些情况下方便操作而设置。

Therac 25由AECL独家制造,采用双通概念,使仪器的空间更加紧凑和易于使用。Therac 25 具有更高的能量,能够对深部的病变进行治疗,降低了治疗费用,缩短了治疗时间。Therac 25 同样采用PDP11计算机进行自动控制,与Therac 6 和Therac20不同的是,PDP11计算机通过软件对Therac 25 的全部操作进行控制,而且取消了硬件自锁装置。

Therac 25 的操作过程如下:

  • 操作人员进入治疗舱;
  • 病人安置在治疗台上;
  • 确定治疗现场数据,旋转治疗台,安置机器的各种附件;
  • 操作人员离开治疗舱;
  • 在控制台输入各种数据;
  • 如果数据满足设置要求,屏幕上显示Verified ,表示治疗已经可以进行。

操作人员通过闭路视听设备观察病人的状况,如果在治疗过程中出现异常或病人抱怨,操作人员可采取下列方式停止机器运行

  1. 悬挂Suspend:在悬挂状态机器必须重启动才能运行
  2. 暂停Pause: 在暂停状态机器只需敲击键盘,就可继续运行
  3. 每次运行中暂停超过5次,需重启动。

系统错误信息定义为低优先权事件,错误信息含义比较模糊,如‘Malfunction 47’ 、‘ VTILT’等。包含经常发生的小错误在内,Therac 25每天可能发生40次左右的错误、错误信息中极少涉及病人安全的信息。操作人员对这些错误信息习以为常,并不给予特别的重视。

事故情况简介[编辑]

Therac 25一共售出了11台,5台配置在美国,6台在加拿大,1985年至1987年共发生了6次放射剂量大规模超标的严重事故,全部设备于1987年召回。对原设计方案作了重大修改,其中包括安装防止软件错误发生的硬件保护装置。下面是这6次事件中的4个事件:

  1. 1985年6月,一名61岁的妇女,到Marietta 的Kennestone 肿瘤中心接受锁骨部位的10兆电子伏特电子射线照射,治疗中病人感到炙热和疼痛,大声喊叫,医生Tim Still无法解释,怀疑与过量辐射有关,并与AECL电话联系。AECL工程师答复称设备没有发生超剂量的可能。随后病人提出诉讼,病人由于遭受严重的烧伤,肩部和手臂被切除,但是诉讼也因为证据不足不能立案。
  2. 1985年7月,一个40岁女性子宫颈癌患者,在加拿大安大略 Hamilton接受Therac 25治疗,治疗剂量为200拉德,治疗过程中机器停机,显示出现出现‘HTILT’错误。同时控制台显示‘No dose’(无剂量)和治疗暂停,于是操作人员按键盘恢复继续运行,同样错误再次发生,在发生5次之后,机器进入悬挂状态,进行了重启动的操作。病人当时反应有强烈烧灼感和电击麻刺感。该病人在5个月后死亡。据以后的分析,该病人在治疗过程中实际受到15000拉德的辐射,对人体而言,辐射剂量达到1000拉德就已经是致命的了。
  3. 1986年3月,一个男性背部肿瘤患者,在美国东得克萨斯ETCC泰勒医院接受Therac 25治疗,治疗模式为电子射线,剂量为180拉德,面积为10厘米×17厘米,操作人员对设备操作十分熟悉,迅速敲击键盘,输入相关数据,发现模式显示为X(X射线),于是更改为E(电子射线),启动机器,机器很快停机,显示‘Malfunction 54’,这个信息的含义在说明书中没有明确定义,其解释是能量已发射,可能过低或过高。控制台显示为剂量过低,操作人员于是进行了恢复和重启动的操作,这时治疗舱内的病人已无法忍受,跳下床敲门,治疗被迫终止。5个月后该病人死亡,据分析该病人接受了16000至25000 拉德的辐射。
  4. 1986年4月在上述事件发生三周之后,美国东得克萨斯ETCC为一个男性面部皮肤癌患者作Therac 25电子射线治疗,剂量为180拉德,仍然由相同的操作人员操作,事件发生过程几乎与上例完全相同,病人剧痛大声叫喊。由于脑部受损,20天后死亡,据分析该病人接受了25000拉德的辐射。

故障诊断[编辑]

放射治疗议在美国从20世纪60年代开始使用以来,一直没有发生过重大的事故,所以无论是患者、医院或制造商,对于可能发生超剂量辐射事故毫无思想准备。1985年第一件事故发生并由患者提出诉讼后,设备制造方AECL完全否认故障出现的可能,由于厂方和医院都缺乏必要的记录,FDA完全无从着手调查。

1985年7月, Hamilton事故发生后,FDA督促AECL进行调查,AECL虽无法重现事故场景,他们已经开始怀疑事故可能是旋转台固定位置微开关的瞬时故障引发,微开关的瞬时故障又追溯至软件输入数据错误。AECL为此作出了相应的改进,并通知医院和FDA,声称:“分析表明新方案的风险率比旧方案降低了5个数量级”。

1986年美国东得克萨斯泰勒医院连续两次发生事故后,在操作人员和医生的共同努力下,终于发现Therac 25的控制系统可能存在重大隐患。

Therac 25的软件控制系统[编辑]

从Therac 6开始,设备已经使用了计算机软件控制,但是其主要控制功能由硬件电路承担,软件只起辅助作用。在设计Therac20和Therac25时,开发商声称,计算机控制系统是独立设计的。实际上由于对Therac 6控制软件的信任,这两台设备都重用了Therac 6的主要控制软件。

Therac 25的软件控制系统的特征是: 1. 按定制的任务优先次序,循环运行。即“任务”按关键度顺序执行,关键度高的任务,先于关键度低的任务执行。除了test & set (测试和设置)外,没有其他同步运行的任务。 2. 软件由四个部件构成,分别是:

  • 数据存储:机器设置和病人治疗数据;
  • 中断处理;
  • 关键任务:检测数据输入、读入编码数据,查找运行参数,调用子程序,设置激励机器弯曲的磁铁(有8秒钟的延迟),循环或延迟直至磁铁设置完成,在设置治疗时,执行治疗;

非关键任务:由键盘处理,包括文字输入,2数位共享数据变量编码,在数据输入完毕后树立旗标。

泰勒医院1986年4月Therac 25 事故场景的重现[编辑]

ETCC泰勒医院1986年4月Therac 25 事故发生后,ETCC立即停止Therac 25工作,并通知AECL。ETCC的医生立即对事故进行了仔细的调查。由于机器的女操作员能够确切记忆事故发生时设备实际操作过程,经过一段时间的努力,终于使错误信息‘Malfunction 54 ’信息得以重现。他们发现,在机器的编辑阶段,数据的输入速度是该错误出现的关键因素,也就是说,对于一个熟练的操作人员,在重复同样的操作千百次之后,编辑速度越来越快,最终将使‘Malfunction 54 ’信息出现,即超剂量辐射事故发生。参加实验的医生是在经过了相当长的实践后达到了临界的编辑速度。次日对结果感到迷惑的AECL工程师来到现场,直到他在医生和操作人员的训练下使‘Malfunction 54 ’信息再次出现时,才接受了医院的看法,并测量这时的辐射剂量已经达到饱和的25000拉德。

得到这个消息的美国芝加哥大学联合辐射中心的医生在他们的教学设备Therac 20上进行了实验,两个月后医生们观察到在学生实验中经常出现保险丝烧毁和继电器断路的事件,经分析其实质与Therac 25故障完全相同,但是由于有硬件电路的保护,没有造成任何严重的影响。

有了这一系列的实验结果,Therac 25故障的原因最终得到确认。故障并不仅是由于一般的软件错误造成,故障的根本原因是系统总体安全设计的问题。

教训[编辑]

事故原因确定后,所有的Therac 25停止使用,召回,重新修改设计,安装硬件保护装置。此后管理层、工程界、学术界进行了长时间的讨论,对事故的教训进行了探讨,这个过程一直持续到90年代中期,各界人士观点见仁见智。其中美国著名的安全性工程专家Leveson对事故的总结和认识最具系统性和代表性,本文的下述部分引用了她得出的一些主要结论。

1.任何事故的发生,很少是单纯的,通常包含在诸多相互关联事件构成的一个复杂网络中,涉及诸如技术、人文、组织等因素。这次导致Therac 25多次事故发生的重要原因在于没有非常明确的证据的条件下,就确信事故的原因已经查明,例如将Hamilton事故中的微型开关作为事故的主要原因,并且忽略了对其他各种可能的相关因素的分析。另外一个错误的假定是认为,改正了一个软件错误,就会预防事故今后发生,实际上软件故障总是一个接一个地不断暴露。

事故原因也经常被简单地归结为人为错误,其实,事故涉及的任何因素都可以贴上人为错误的标签,甚至硬件的损耗失效也可以归结为设计人员没有提供必要的冗余以及操作人员疏于维护和置换,将一个事故仅仅归结为人为错误是没有帮助的和无意义的。

同样无意义的是将事故的原因归结为计算机错误和软件错误。Therac 25 事故中的软件确实存在问题,但它只是其中的一个因素,如果我们认为软件是Therac 25事故的根本原因,那么我们不得不得出结论,在今后为了预防类似的事故,必须构造出完美无缺的软件,在任何环境中它不会出现非预期的工作方式,这显然是不可能实现的。除此之外只好在所有系统中都不使用软件。很明显所有上述论点都过分悲观。

我们必须用系统工程的观点,从复杂系统事故的角度来分析面对的问题。对于Therac 25事故,涉及的因素包括:

  • 管理缺位,缺乏确定的程序跟踪所有报告的事故;
  • 对软件过分信任,已至删除了所有的硬件互锁装置,使软件成为可引发事故的单点失效;
  • 低水平的软件工程实践;
  • 不实际的风险评估和过分信赖评估的结果。
  • 完全同样的事故,今后不大可能重复发生,如果我们研究和改善与事故有关的各种因素,那么就有可能预防类似的错误发生。

2、必须强调系统工程。在本案例中和其他工程发生的事故中,一个共同的错误在于对软件过分信任。非软件的专业人士似乎认为软件是不会失效的,从而过分依赖计算机控制功能。其实软件虽然不会发生如同硬件一样的损耗失效,但是软件的设计错误更难于发现和消除。硬件的失效模式一般是有限的,所以构建保护机构比较容易,从Therac 25得到的教训是在实施计算机控制时不要删除标准的硬件互锁装置。

硬件备份、互锁和其他的安全保护器件,在许多不同的系统中现在已经被软件置换,其中包括商用飞机、核电站和武器系统。在硬件互锁装置存在的地方,他们也常被软件控制。在设计危险系统时,如果认为一个故障就足以导致严重事故,那就违反了系统工程的基本原理。软件需要作为一个单独的元件来处理,软件不应该单独承担安全的职能,在系统设计中,必须避免单个软件错误或软件工程错误就足以造成灾难性后果。

当前工程界的另外一个趋势是忽略软件,Therac 25的第一次安全分析,没有包括软件(虽然软件几乎承担了全部的安全性责任),当问题出现后,分析者又将注意力完全集中在硬件上。调查软件可能的影响不应成为事故分析的最后一个环节,事实上软件错误可以导致硬件的瞬时故障,因为软件给被控制的硬件发布指令。

在Therac 25 中,病人的反应成为衡量辐射程度的唯一实际指示。Therac 25完全依赖操作人员,没有独立的机构检查操作是否正确,而机器本身也不能检测大剂量辐射是否发生。Therac 25的离子室不能掌握高密度的电子束,在它们饱和的时候,显示的是低辐射剂量。

任何一家公司在建造安全关键系统的时,应该进行核查实验,一旦发现问题的任何线索,应该有既定的事故分析程序,医生Tim Still 的第一个电话就应该促使Kennestone和AECL进行广泛调查,第一件诉讼就应该立即启动应急反应程序。每一个使用危险设备的企业都应该有危险记录和跟踪,同时使事故的报告和分析成为其质量控制过程的一部分,这不仅有助于事故的预防,而且可以降低保险费率,并在诉讼发生后提供背景资料。

最后,过分依赖安全性分析的数字结果是不明智的,在Hamilton事故发生、微开关故障改进后宣称安全性提高了5个数量级是无法验证的。

3、软件工程不容忽视。Therac 25中包括了软件编码错误,这个问题在其他与计算机相关的一般事故中是少见的。一般计算机错误主要涉及需求、环境条件和系统状态等。虽然实施软件工程不能完全消除软件中的错误,但是可以极大地减少错误。许多公司在他们的系统中使用软件,但是并不象软件工程师那样严肃对待,下述软件工程的基本原则在Therac 25中受到明显的破坏:

  • 编制软件文档不应是一种事后行为;
  • 应该建立软件质量保证体系和标准;
  • 应保持设计简单性;
  • 如何得到错误信息,例如软件核查试验,应该从软件设计开始时就制订出方案;
  • 软件应该在模块级和软件级进行广泛的测试和分析,仅进行系统测试是不正确的;
  • 安全性必须构造入软件系统,任何安全关键软件项目必须包括特殊的安全性分析和设计程序,此外不管软件错误是否存在,系统级安全性必须得到确切的保证。Therac 20 包含有导致泰勒事件的同样软件错误,但是硬件的互锁消除了故障的后果。

在这里,我们还能够获得有关软件重用的重要教训。一般倾向认为重用软件或使用商用现成软件可以增加安全性,原因是该软件已经广泛使用过。其实重用软件模块并不能保证新系统的安全性,有时甚至会成为危险设计。安全性是系统的一个质量属性,不完全等同于软件质量,重新编写新的软件使其更加清楚、更加简单,在许多情况下才能更加安全。

一个人学习了一门编程课程,在微机上编写过程序,并不表明他已经具有开发安全关键软件的能力。从事安全关键软件开发需要进行专门的培训。任何一个工程师都不能自动具备软件工程师的能力。

用户界面在Therac 25事件中受到了某种程度的关注,实际上它在这次事件中只有部分影响,虽然软件的界面和这个软件的其他部分一样,存在改进的余地。软件工程师需要接受更多的界面设计培训,从人-机工程的角度需要更多的数据输入。必须着重指出在用户友好界面和安全性方面存在着潜在冲突。用户界面设计的一个目的是尽可能方便操作者使用,但是在Therac 25软件中,操作的简单性是以牺牲系统安全性为代价的。最后不仅在初始设计中必须考虑软件和软件界面的安全性,而且需要记录决策理由,使得以后的变更有依据可查。

参见[编辑]

參考資料[编辑]

  1. ^ [1]