医学仪器设计中的软件安全性.docx

医学仪器设计中的软件安全性.docx

《医学仪器设计中的软件安全性.docx》由会员分享，可在线阅读，更多相关《医学仪器设计中的软件安全性.docx（35页珍藏版）》请在冰豆网上搜索。

医学仪器设计中的软件安全性

《医学仪器设计》中“软件安全性”一章

目录

引言Therac25安全性事故案例

第一节医学软件安全性

1.1软件安全性定义

1.2软件安全性标准

1.3安全性设计任务

第二节软件安全性分析

2.1需求安全性分析

2.2结构设计安全性分析

2.3编程安全性分析

2.4详细设计安全性分析

2.5编码安全性分析

2.6测试安全性分析

2.7软件变更安全性分析

第三节软件安全性设计与实现

3.1软件安全性实现内容

3.2软件安全性实现环境

3.3安全性设计的认识误区

3.4安全性设计的原则

第四节软件安全性测试

4.1测试方法与技术

4.2安全性测试内容

本章小结

附录：

软件可靠性和安全性设计模板

引言

近年来，随着计算机技术、网络通信技术和软件开发技术的快速发展，医学仪器的数字化、智能化和网络化成为必然的趋势。

数字化医疗设备中嵌入式软件以及医院信息系统（HospitalInformationSystem，简称HIS）、医学影像与归档系统（PictureArchivingandCommunicationSystems，简称PACS）、医学放射信息系统（RIS）和医学检验信息系统（LIS）从本世纪初开始成熟并迅速形成市场巨大的新兴产业，医学软件的重要性日益显现。

在商业化进程突飞猛进的同时，由软件引发的安全性事故也频频发生。

近年来，由于软件安全性问题，已经造成了一些重大事故。

例如，由于控制放射性治疗设备的软件错误，在加拿大已经造成了多起癌症病人因受到过量放射性辐射而死亡。

在英国伦敦，救护车调度软件刚投入使用几小时就发生故障，造成急诊病人延误达十几小时。

其中上世纪80年代中期、美国和加拿大的Therac25放射治疗仪，发生了多次医疗事故，若干病人治疗后死亡。

病人提出诉讼，逐渐引起媒体和公众注意，美国食品与药物管理局（FDA）逐渐参与了事件调查。

设备制造商起初一再声称，对仪器制造提供了严格的质量监控，再加上一部分关键设计人员早以离职，原始文档缺乏，事故场景难于重现，调查过程进展缓慢。

80年代末，才最终确定事故是由超剂量辐射造成，但实际上，深层的原因是系统和软件的安全性设计方面存在严重问题。

现在Therac25事故已经成为美国大学讲解软件安全性设计的一个经典案例。

案例分析：

Therac25医疗安全事故

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

1985年至1987年Therac25共发生了6次放射剂量大规模超标的严重事故。

由于发生了多次医疗事故，若干病人治疗后死亡，病人及家属提出诉讼，逐渐引起媒体和公众注意，美国食品与药物管理局（FDA）逐渐参与了事件调查。

设备制造商起初一再声称，对仪器制造提供了严格的质量监控，再加上一部分关键设计人员早以离职，原始文档缺乏，事故场景难于重现，调查过程进展缓慢。

80年代末，才最终确定事故是由超剂量辐射造成，但实际上，深层的原因是系统和软件的安全性设计方面存在严重问题。

Therac25及其功能简介

放射线治疗肿瘤技术起源于20世纪60年代，Therac25属于第三代医用高能电子线性加速器，具有两种工作模式。

其一是加速电子模式，用来治疗相对较浅的病变。

其二是X射线模式，这种模式，将25兆电子伏特的电子束转化为X射线，用来治疗较深度的病变。

Therac6和Therac20是Therac25的前身，Therac6能量为6兆电子伏特，只有一种X射线工作模式，Therac20属于第二代医用高能电子线性加速器，能量为20兆电子伏特，具有电子和X射线两种工作模式。

这两种型号的仪器都具有独立的合乎工业标准的硬件控制系统，对病人的治疗完全依靠硬件实施，仪器采用硬件反锁技术控制过剂量辐射，治疗过程耗时较长。

两种仪器都配置有PDP11计算机，但计算机控制属辅助性质，计算机软件控制仅为在某些情况下方便操作而设置。

Therac25由AECL独家制造，采用双通概念，使仪器的空间更加紧凑和易于使用。

Therac25具有更高的能量，能够对深部的病变进行治疗，降低了治疗费用，缩短了治疗时间。

Therac25同样采用PDP11计算机进行自动控制，与Therac6和Therac20不同的是，PDP11计算机通过软件对Therac25的全部操作进行控制，而且取消了硬件自锁装置。

Therac25的操作过程如下：

操作人员进入治疗舱；

病人安置在治疗台上；

确定治疗现场数据，旋转治疗台，配置置机器的各种附件；

操作人员离开治疗舱；

在控制台输入各种数据；

如果数据满足设置要求，屏幕上显示Verified，表示治疗已经可以进行。

   图1 Therac25设备的全视图。

图1Therac25设备的全视图

图2Therac25控制台屏幕显示图

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

1、挂起Suspend：

在挂起状态机器必须重启动才能运行

2、暂停Pause:

在暂停状态机器只需敲击键盘，就可继续运行

3、每次运行中暂停超过5次，需重启动。

系统错误信息定义为低优先权事件，错误信息含义比较模糊，如‘Malfunction47’、‘VTILT’等。

包含经常发生的小错误在内，Therac25每天可能发生40次左右的错误、错误信息中极少涉及病人安全的信息。

操作人员对这些错误信息习以为常，并不给予特别的重视。

Therac25事故情况简介

Therac25一共售出了11台，5台配置在美国，6台在加拿大，1985年至1987年共发生了6次放射剂量大规模超标的严重事故，全部设备于1987年召回。

对原设计方案作了重大修改，其中包括安装防止软件错误发生的硬件保护装置。

下面是这6次事件中的4个：

1、1985年6月，一名61岁的妇女，到Marietta的Kennestone肿瘤中心接受锁骨部位的10兆电子伏特电子射线照射，治疗中病人感到炙热和疼痛，大声喊叫，医生TimStill无法解释，怀疑与过量辐射有关，并与AECL电话联系。

AECL工程师答复称设备没有发生超剂量的可能。

随后病人提出诉讼，病人由于遭受严重的烧伤，肩部和手臂被切除，但是诉讼也因为证据不足不能立案。

2、1985年7月，一个40岁女性子宫颈癌患者，在加拿大安大略Hamilton接受Therac25治疗，治疗剂量为200拉德，治疗过程中机器停机，显示出现出现‘HTILT’错误。

同时控制台显示‘Nodose’（无剂量）和治疗暂停，于是操作人员按键盘恢复继续运行，同样错误再次发生，在发生5次之后，机器进入悬挂状态，进行了重启动的操作。

病人当时反应有强烈烧灼感和电击麻刺感。

该病人在5个月后死亡。

据以后的分析，该病人在治疗过程中实际受到15000拉德的辐射，对人体而言，辐射剂量达到1000拉德就已经是致命的了。

3、1986年3月，一个男性背部肿瘤患者，在美国东得克萨斯ETCC泰勒医院接受Therac25治疗，治疗模式为电子射线，剂量为180拉德，面积为10厘米×17厘米，操作人员对设备操作十分熟悉，迅速敲击键盘，输入相关数据，发现模式显示为X（X射线），于是更改为E（电子射线），启动机器，机器很快停机，显示‘Malfunction54’，这个信息的含义在说明书中没有明确定义，其解释是能量已发射，可能过低或过高。

控制台显示为剂量过低，操作人员于是进行了恢复和重启动的操作，这时治疗舱内的病人已无法忍受，跳下床敲门，治疗被迫终止。

5个月后该病人死亡，据分析该病人接受了16000至25000拉德的辐射。

4、1986年4月在上述事件发生三周之后，美国东得克萨斯ETCC为一个男性面部皮肤癌患者作Therac25电子射线治疗，剂量为180拉德，仍然由相同的操作人员操作，事件发生过程几乎与上例完全相同，病人剧痛大声叫喊。

由于脑部受损，20天后死亡，据分析该病人接受了25000拉德的辐射。

故障诊断

放射治疗仪在美国从20世纪60年代开始使用以来，一直没有发生过重大的事故，所以无论是患者、医院或制造商，对于可能发生超剂量辐射事故毫无思想准备。

1985年第一件事故发生并由患者提出诉讼后，设备制造方AECL完全否认故障出现的可能，由于厂方和医院都缺乏必要的记录，FDA完全无从着手调查。

1985年7月，Hamilton事故发生后，FDA督促AECL进行调查，AECL虽无法重现事故场景，他们已经开始怀疑事故可能是旋转台固定位置微开关的瞬时故障引发，微开关的瞬时故障又追溯至软件输入数据错误。

AECL为此作出了相应的改进，并通知医院和FDA，声称：

“分析表明新方案的风险率比旧方案降低了5个数量级”。

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

1、Therac25的软件控制系统

从Therac6开始，设备已经使用了计算机软件控制，但是其主要控制功能由硬件电路承担，软件只起辅助作用。

在设计Therac20和Therac25时，开发商声称，计算机控制系统是独立设计的。

实际上由于对Therac6控制软件的信任，这两台设备都重用了Therac6的主要控制软件。

Therac25的软件控制系统的特征是：

1）按定制的任务优先次序，循环运行。

即“任务”按关键度顺序执行，关键度高的任务，先于关键度低的任务执行。

除了test&set（测试和设置）外，没有其他同步运行的任务。

2）软件由四个部件构成，分别是：

数据存储：

机器设置和病人治疗数据；

中断处理；

关键任务：

检测数据输入、读入编码数据，查找运行参数，调用子程序，设置激励机器弯曲的磁铁（有8秒钟的延迟），循环或延迟直至磁铁设置完成，在设置治疗时，执行治疗；

非关键任务：

由键盘处理，包括文字输入，2数位共享数据变量编码，在数据输入完毕后标志位置位。

2、泰勒医院1986年4月Therac25事故场景的重现

ETCC泰勒医院1986年4月Therac25事故发生后，ETCC立即停止Therac25工作，并通知AECL。

ETCC的医生立即对事故进行了仔细的调查。

由于机器的女操作员能够确切记忆事故发生时设备实际操作过程，经过一段时间的努力，终于使错误信息‘Malfunction54’信息得以重现。

他们发现，在机器的编辑阶段，数据的输入速度是该错误出现的关键因素，也就是说，对于一个熟练的操作人员，在重复同样的操作千百次之后，编辑速度越来越快，最终将使‘Malfunction54’信息出现，即超剂量辐射事故发生。

参加实验的医生是在经过了相当长的实践后达到了临界的编辑速度。

次日对结果感到迷惑的AECL工程师来到现场，直到他在医生和操作人员的训练下使‘Malfunction54’信息再次出现时，才接受了医院的看法，并测量这时的辐射剂量已经达到饱和的25000拉德。

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

有了这一系列的实验结果，Therac25故障的原因最终得到确认。

故障并不仅是由于一般的软件错误造成，故障的根本原因是系统总体安全设计的问题。

Therac25案例教训

事故原因确定后，所有的Therac25停止使用，召回并重新修改设计，加装硬件保护装置。

此后管理层、工程界、学术界进行了长时间的讨论，对事故的教训进行了探讨，这个过程一直持续到90年代中期，各界人士观点见仁见智。

其中美国著名的安全性工程专家Leveson对事故的总结和认识最具系统性和代表性，下面引用她得出的一些主要结论：

1、任何事故的发生，很少是单纯的，通常包含在诸多相互关联事件构成的一个复杂网络中，涉及诸如技术、人文、组织等因素。

这次导致Therac25多次事故发生的重要原因在于没有非常明确的证据的条件下，就确信事故的原因已经查明，例如将Hamilton事故中的微型开关作为事故的主要原因，并且忽略了对其他各种可能的相关因素的分析。

另外一个错误的假定是认为，改正了一个软件错误，就会预防事故今后发生，实际上软件故障总是一个接一个地不断暴露。

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

同样无意义的是将事故的原因归结为计算机错误和软件错误。

Therac25事故中的软件确实存在问题，但它只是其中的一个因素，如果我们认为软件是Therac25事故的根本原因，那么我们不得不得出结论，在今后为了预防类似的事故，必须构造出完美无缺的软件，在任何环境中它不会出现非预期的工作方式，这显然是不可能实现的。

除此之外只好在所有系统中都不使用软件。

很明显所有上述论点都过分悲观。

我们必须用系统工程的观点，从复杂系统事故的角度来分析面对的问题。

对于Therac25事故，涉及的因素包括：

管理缺位，缺乏确定的程序跟踪所有报告的事故；

对软件过分信任，已至删除了所有的硬件互锁装置，使软件成为可引发事故的单点失效；

低水平的软件工程实践；

不实际的风险评估和过分信赖评估的结果。

完全同样的事故，今后不大可能重复发生，如果我们研究和改善与事故有关的各种因素，那么就有可能预防类似的错误发生。

2、必须强调系统工程。

在本案例中和其他工程发生的事故中，一个共同的错误在于对软件过分信任。

非软件的专业人士似乎认为软件是不会失效的，从而过分依赖计算机控制功能。

其实软件虽然不会发生如同硬件一样的损耗失效，但是软件的设计错误更难于发现和消除。

硬件的失效模式一般是有限的，所以构建保护机构比较容易，从Therac25得到的教训是在实施计算机控制时不要删除标准的硬件互锁装置。

硬件备份、互锁和其他的安全保护器件，在许多不同的系统中现在已经被软件置换，其中包括商用飞机、核电站和武器系统。

在硬件互锁装置存在的地方，他们也常被软件控制。

在设计危险系统时，如果认为一个故障就足以导致严重事故，那就违反了系统工程的基本原理。

软件需要作为一个单独的元件来处理，软件不应该单独承担安全的职能，在系统设计中，必须避免单个软件错误或软件工程错误就足以造成灾难性后果。

当前工程界的另外一个趋势是忽略软件，Therac25的第一次安全分析，没有包括软件（虽然软件几乎承担了全部的安全性责任），当问题出现后，分析者又将注意力完全集中在硬件上。

调查软件可能的影响不应成为事故分析的最后一个环节，事实上软件错误可以导致硬件的瞬时故障，因为软件给被控制的硬件发布指令。

在Therac25中，病人的反应成为衡量辐射程度的唯一实际指示。

Therac25完全依赖操作人员，没有独立的机构检查操作是否正确，而机器本身也不能检测大剂量辐射是否发生。

Therac25的离子室不能掌握高密度的电子束，在它们饱和的时候，显示的是低辐射剂量。

任何一家公司在建造安全关键系统的时，应该进行核查实验，一旦发现问题的任何线索，应该有既定的事故分析程序，医生TimStill的第一个电话就应该促使Kennestone和AECL进行广泛调查，第一件诉讼就应该立即启动应急反应程序。

每一个使用危险设备的企业都应该有危险记录和跟踪，同时使事故的报告和分析成为其质量控制过程的一部分，这不仅有助于事故的预防，而且可以降低保险费率，并在诉讼发生后提供背景资料。

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

3、软件工程不容忽视。

Therac25中包括了软件编码错误，这个问题在其他与计算机相关的一般事故中是少见的。

一般计算机错误主要涉及需求、环境条件和系统状态等。

虽然实施软件工程不能完全消除软件中的错误，但是可以极大地减少错误。

许多公司在他们的系统中使用软件，但是并不象软件工程师那样严肃对待，下述软件工程的基本原则在Therac25中受到明显的破坏：

·编制软件文档不应是一种事后行为；

·应该建立软件质量保证体系和标准；

·应保持设计简单性；

·如何得到错误信息，例如软件核查试验，应该从软件设计开始时就制订出方案；

·软件应该在模块级和软件级进行广泛的测试和分析，仅进行系统测试是不正确的；

·安全性必须构造入软件系统，任何安全关键软件项目必须包括特殊的安全性分析和设计程序，此外不管软件错误是否存在，系统级安全性必须得到确切的保证。

Therac20包含有导致泰勒事件的同样软件错误，但是硬件的互锁消除了故障的后果。

在这里，我们还能够获得有关软件重用的重要教训。

一般倾向认为重用软件或使用商用现成软件可以增加安全性，原因是该软件已经广泛使用过。

其实重用软件模块并不能保证新系统的安全性，有时甚至会成为危险设计。

安全性是系统的一个质量属性，不完全等同于软件质量，重新编写新的软件使其更加清楚、更加简单，在许多情况下才能更加安全。

一个人学习了一门编程课程，在微机上编写过程序，并不表明他已经具有开发安全关键软件的能力。

从事安全关键软件开发需要进行专门的培训。

任何一个工程师都不能自动具备软件工程师的能力。

用户界面在Therac25事件中受到了某种程度的关注，实际上它在这次事件中只有部分影响，虽然软件的界面和这个软件的其他部分一样，存在改进的余地。

软件工程师需要接受更多的界面设计培训，从人-机工程的角度需要更多的数据输入。

必须着重指出在用户友好界面和安全性方面存在着潜在冲突。

用户界面设计的一个目的是尽可能方便操作者使用，但是在Therac25软件中，操作的简单性是以牺牲系统安全性为代价的。

最后不仅在初始设计中必须考虑软件和软件界面的安全性，而且需要记录决策理由，使得以后的变更有依据可查。

第一节医学软件安全性

1.1软件安全性定义

在医疗卫生这类安全性要求极高的领域内，计算机及嵌入式智能控制系统的应用造成灾难性事故引起了国际上对软件安全性的高度重视。

人们把这类一旦发生故障就可能危及人的生命、财产和生存环境的软件称为安全关键软件（CriticalSafetySoftware）。

它们的基本特征是安全性具有至关重要的意义。

软件安全性（SoftwareSafety），是软件的一种属性。

严格地讲，软件安全性“Safety”应为软件失效安全性。

根据美军标MIL-STD-882D的定义，安全性有两个含义：

避免可能引起死亡、伤害或职业病：

避免对设备或财产造成损坏或损失；

因此，软件的安全性就是软件能够保证不导致上面两种情况的属性。

在软件安全中，危险（hazard）是一个专门的术语，指导致或可能引起一个失误的已存在或滞在的条件。

失误（Mishap）可认为是由任意可能组合的一系列连续的并发的相关事件。

在满足危险发生的条件情况下，这一系列事件的发生会导致系统失去控制并产生损失。

在日常生活中，广义软件安全性常常涵盖了安全性、可靠性及私密性三类不同的概念。

软件可靠性（SoftwareReliability）是指在规定条件和规定时间内，软件不引起系统失效（Failure）及执行所要求功能的能力。

一般来说，可靠性需求指的是使系统无故障（Fault），而狭义安全性需求指的是使系统无事故（Mishap）。

需要指出的是：

并非所有的软件错误都会引起安全性问题，同样也不能认为按照规定功能运行的软件都是安全的，有些事故就是在软件没有出现失效的情况下发生的。

软件保密安全性（SoftwareSecurity）是软件为秘密数据提供保护状态及保护等级的一种特性。

失效安全性（Safety）与保密安全性（Security）有着本质的差别：

保密安全性涉及软件、数据和信息的保密和安全问题，主要防止外部人员或因素造成对计算机内部的软件、数据和信息的蓄意或无意的非法访问和破坏，而失效安全性主要防止意外事故的发生。

从上面的论述可以看出，软件安全性问题是由软件的设计缺陷造成的，因此，从某种意义上讲软件的安全性是设计出来的。

软件安全性领域，包含了软件安全工程、软件安全性分析方法、软件安全性设计、测试、验证等内容。

1.2软件安全性标准

为了保障医疗相关软件的质量，政府机构纷纷迅速采取法律与管理措施，一批保障软件安全性的软件生产、使用和维护的规范与标准已开始拟订，有的已经投入实施。

下面列举了与医疗仪器中软件设计相关国际标准和国家标准：

MIL-STD-882D，SystemSafetyProgramRequirements;

IEC61508-1999，“FundamentalSafetyofEtectrical／Electronic／ProgrammableElectronicRelatedSafetySystems”;

NASA．STD-8719.13A-1997，NASASoftwareSafetyStandard;

NASA-GB-1740.13-1996，GuidebookforCriticalSoftwareandSafetyAnalysisDevelopment;

IEEE1228SoftwarePlansSafety

DEF00.55TheProcurementofCriticalSoftwareinDefenceEquipment

IEC60601-1:

MedicalElectricalEquipment-Part1:

GeneralRequirementsforSafety

IEC60601-1-4:

SafetyRequirementsforProgrammableElectronicMedicalSystems

ISO14971,2007RiskManagementforallMedicalDevices

IEEE1012-2004IEEEStandardforSoftwareVerificationandValidation

IEEE1059-1993IEEEGuideforSoftwareVerificationandValidationPlans

GJB900．1990《系统安全性通用大纲》

GJB／2；99．1997《系统安全工程手册》

GJB／Z102．97《软件可靠性和安全性设计准则》

GB/T20438.1-.7-2006E/E/PE安全相关系统的功能安全（引进IEC61508）

GB/T21109.1-.3-2007过程工业领域安全仪表系统的功能安全（引进IEC61511）

GB9706.15-2008医用电气设备第1部分：

通用安全要求并列标准医用电气系统安全要求

其中ISO／IEC61508是1999年IEC针对安全关键系统中的可编程部件的功能安全提出的一个系列标准，它的起草经历了近10年的时间，是安全性领域目前最为重要的国际标准。

IEC61508包括7个部分，既可以做为其它安全性标准的基础，又可以作为独立的标准使用。

我国在1990年制定的QJB900-90《系统安全性通用大纲》把软件安全性分析列为系统安全性分析的重要工作内容，对安全关键软件，要求在软件开发的各个阶段