電氣自動裝置事故案例

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軟體中，操作的簡單性是以犧牲系統安全性為代價的。最後不僅在初始設計中必須考慮軟體和軟體界面的安全性，而且需要記錄決策理由，使得以後的變更有依據可查。