跳至內容

Therac-25案例

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書

Therac-25事件是在軟體工程界被大量引用的案例。Therac-25是加拿大原子能有限公司（AECL）所生產的放射線療法機器，在Therac-6和Therac-20之後推出（以往的Therac-6和Therac-20是加拿大原子能有限公司和法國的CGL公司合作開發）。在1985年到1987年之間，在美國及加拿大至少有六起和Therac-25相關的醫療事故，因為軟體設計時的瑕疵，使病人受到了過量的輻射[1]:425。軟體的瑕疵是因為競爭危害（二個同時進行程式之間時序衝突造成的問題），有瑕疵時會使病患接受到比正常劑量高一百倍的輻射，因此造成患者死亡或重傷[2]。

此一事故突顯了安全關鍵系統若使用軟體控制時的潛在危險性，也是軟體工程及醫學信息學的經典案例。另外因為工程師的過度自信[1]:428，而且沒有進行適當的盡職調查來修復已知的軟體問題，這也是一個極端的例子，工程師因為對其初期的工程過度自信，沒有相信終端用戶提出的問題，最後產生了嚴重的結果。Therac-25事件後，軟體開發工程化管理方法論開始得到重視。

設計

Therac-25可以進行二種放射線療法：

若是要進行直接電子束療法，設備會直接產生低能量的電子束，利用電磁鐵掃描方式讓電子束分散到安全的劑量範圍。若是要進行百萬伏特級X射線療法，設備會轉動四個零件調整電子束的路徑，使電子束進入X射線腔中，而X射線腔也有設備會偵測電子束的強度。

問題描述

此事件發生時，所發射的是高能量的電子束，而不是預期的低能量電子束，而且設備對應的零件沒有讓電子束進入X射線腔中。以前的機種有硬體互鎖機制以避免這種情形發生，而Therac-25取消了硬體互鎖機制，為了安全起見改用軟體的互鎖機制。軟體互鎖機制在有競爭危害時會失效。其缺陷如下：有一個測試程序中一位元組的計數器常常會溢位，若操作員恰好在計數器溢位時輸入命令，軟體互鎖機制會失效[2]。

高能量的電子束給予的能量是理想輻射劑量的100倍，是可能會造成β輻射的致命劑量。患者Ray Cox描述其感覺像「強烈的電擊」，他因此尖叫跑出診療室[3]。幾天後病人開始出現輻射灼傷（英語：radiation burn），病人也開始出現輻射過量的症狀，其中有三個病患後來因為輻射過量而死亡[4]。

根本原因

調查委員會調查後的結論是此一系列事故的主因是不良的軟體設計及開發實務，沒有明確的將主因歸因到所找到的軟體編程錯誤。而軟體的設計方式也讓軟體在實務上不可能以自動化測試進行測試[5]。

研究這系列事故的研究者發現了幾個造成此事件的主因，包括了以下的組織層面原因：

  • AECL沒有將程式碼由第三方來進行審查。
  • AECL在軟體設計評估時，沒有考慮設備產生預期結果的方式，以及會有哪些已知的失效模式，這些形成了可靠度建模及風險管理的通用技巧。
  • 系統在運作時，有發現有元件異常，中止了X光束，但是其顯示只顯示了"MALFUNCTION"（機能異常），後面配合了1到64的數字，而使用手冊沒有說明這些異常訊息，甚至連訊息都沒有列出。因此操作員按了P鍵，跳過了警告訊息，繼續運作。
  • AECL的人員，以及機器的操作者一開始不相信使用者的抱怨，這可能是因為過度的自信[1]:428。
  • AECL在到醫院組裝Therac-25設備之前，完全沒有將軟體及硬體一起組合測試。

研究者也發現一些工程方面的原因：

  • 設備中有一個VT-100（英語：VT-100）終端機（控制PDP-11電腦），此錯誤只有在操作員在終端機鍵盤上輸出二個不常輸入的按鍵組合後才會出現，先輸入X選擇（錯誤的）25 MeV X光模式，之後輸入E，選擇（正確的）25 MeV 電子模式，之後輸入Enter，三個按鍵組合在8秒鐘內完成[5]，上述的按鍵組合看起來很少會按到，因此這個問題也不是很常出現，長期沒有被重視[3]。
  • 設計上沒有加入硬體互鎖機制避免電子束運作在高能量模式，而且沒有對應X光腔。
  • 工程師復用了以前舊機種的代碼，舊機種有硬體互鎖機制，因此軟體上的問題沒有造成失效。硬體的互鎖機制也沒有產生對應報告，說明互鎖曾被觸發，因此沒有辦法看出存在錯誤的軟體指令。
  • 硬體沒有提供軟體對應方式來確認感測器是否有正常工作（參考開迴路控制器）。X光腔和X光轉向系統是首先造成此失效的原因。製造商曾建議增加冗餘的開關來交互檢查其狀態及運作。
  • 設備的控制行程沒有和操作員介面的行程建立互斥鎖，因此若操作員設定的太快，就有可能有競爭危害。這部份在測試時沒有測到，因為操作員需要一段時間熟悉相關操作，才能輸入的夠快，觸發此一失效模式。
  • 軟體中有設定旗標變數，但是有變化時會讓變數加1，而不是將其設定為固定的非零值，因此偶爾會出現算術溢位，讓旗標變數變為0，軟體就會跳過安全相關的檢查。

此軟體是用組合語言撰寫，因此在軟件的設計和測試時需要耗費更多精力。不過語言選擇本身沒有列為事故的主要原因。設備也使用其自己的作業系統。

Leveson指出此事件的一個重大教訓就是不可以假設復用的軟體就一定安全： 「有一個天真的假設，就是認為軟體復用以及用現有的商業軟體可以增加安全性，因為要使用的軟體已經頻繁使用過。復用的軟體模組無法保證在配合新系統使用時的安全性...」[5]。為了因應像Therac-25這類的事件，創立了IEC 62304（英語：IEC 62304）標準，導入了針對醫療設備的開發生命週期標準，而且也有針對使用未知譜系的軟件（英語：software of unknown pedigree）時的特定建議作法[6]。

參見

參考資料

  1. ^ 1.0 1.1 1.2 Baase, Sara. A Gift of Fire. Pearson Prentice Hall. 2008. 
  2. ^ 2.0 2.1 Leveson, Nancy G.; Turner, Clark S. An Investigation of the Therac-25 Accidents (PDF). IEEE Computer. July 1993, 26 (7): 18–41 [2017-03-25]. （原始內容存檔 (PDF)於2004-11-28）. 
  3. ^ 3.0 3.1 Casey, Steven. Set Phasers On Stun - Design and Human Error. Aegean Publishing Company. : 11–16. 
  4. ^ Rose, Barbara Wade. Fatal Dose - Radiation Deaths linked to AECL Computer Errors. www.ccnr.org. [2016-06-14]. （原始內容存檔於2018-01-06）. 
  5. ^ 5.0 5.1 5.2 Nancy G. Leveson, University of Washington. Medical Devices: The Therac-25 Accidents (PDF). Safeware: System Safety, and Computers Update of the 1993 IEEE Computer article (Addison-Wesley). 1995 [2017-03-25]. （原始內容 (PDF)存檔於2008-02-16）. 
  6. ^ Hall, Ken. Developing Medical Device Software to IEC 62304. MDDI - Medical Device and Diagnostic Industry. June 1, 2010 [2016-12-12]. （原始內容存檔於2016-11-12）. 

延伸閱讀


取自「https://zh.wikipedia.org/w/index.php?title=Therac-25案例&oldid=72707566」