电气自动装置事故案例

1. S型气溶胶自动灭火装置的灭火案例

长沙市国际电子大厦起火：
西安坚瑞化工有限责任公司生产的DKL自动灭火装置在长回沙市国际答电子大厦2004年5月29日中午13时由于电源线老化引起的短路事故中，及时有效启动，避免了一起火灾事故的发生，有效的保护了基站内部的各种电器设备。事故发生后对传输、电源、空调及主设备等均未造成影响。在更换电源线后，5月29日16时30分所有设备恢复正常工作。
工程环境简介：移动通讯基站，站内有交换机、电源柜、空调等设备，控制器JB-QB-JR01
喷放过程：5月29日中午1：00左右钟移动公司人员接到该基站故障申报，于1：25分进入该基站发现机房内冒烟，温度极高，DKL灭火装置已经启动，正在喷洒灭火剂。

2. Therac-25案例的情况简介

二、事故情况简介
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的控制系统可能存在重大隐患。
1、Therac 25的软件控制系统
从Therac 6开始，设备已经使用了计算机软件控制，但是其主要控制功能由硬件电路承担，软件只起辅助作用。在设计Therac20和Therac25时，开发商声称，计算机控制系统是独立设计的。实际上由于对Therac 6控制软件的信任，这两台设备都重用了Therac 6的主要控制软件。
Therac 25的软件控制系统的特征是：
1）按定制的任务优先次序，循环运行。即“任务”按关键度顺序执行，关键度高的任务，先于关键度低的任务执行。除了test & set (测试和设置)外，没有其他同步运行的任务。
2）软件由四个部件构成，分别是：
数据存储：机器设置和病人治疗数据；
中断处理；
关键任务：检测数据输入、读入编码数据，查找运行参数，调用子程序，设置激励机器弯曲的磁铁（有8秒钟的延迟），循环或延迟直至磁铁设置完成，在设置治疗时，执行治疗；
非关键任务：由键盘处理，包括文字输入，2数位共享数据变量编码，在数据输入完毕后树立旗标。
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软件中，操作的简单性是以牺牲系统安全性为代价的。最后不仅在初始设计中必须考虑软件和软件界面的安全性，而且需要记录决策理由，使得以后的变更有依据可查。