
軟體錯誤通常讓人聯想到當機、錯誤操作或資料遺失,但你知道嗎?在 1980 年代,一個醫療設備的程式漏洞不但沒有被即時發現,甚至造成至少 三人死亡、六人嚴重受傷,成為全球公認最早的致命軟體 Bug 事件。
這起災難的主角,是一款名為 Therac-25 的放射治療機。這部機器原本是為了治療癌症病患而設計,卻因設計上的重大疏忽,造成了史上罕見的醫療災難。
Therac-25:革命性設計卻缺乏防護
Therac-25 在 1983 年問世時被譽為創新之舉,因為它結合了兩種治療模式:
-
電子束療法:適用於皮膚癌等淺層治療
-
兆伏特 X 射線療法:用於深層腫瘤照射
這兩種療法需要不同劑量與能量輸出,但如果混淆模式,後果將非常嚴重。
為了精簡設計,Therac-25 放棄了前代機型常用的「硬體機械互鎖裝置」,完全依賴軟體控制。換句話說,一旦程式出錯,就沒有實體裝置能阻止錯誤發生。
Bug 機制:競態條件與人為操作導致錯殺
根據加州州立大學碩士研究生 Anne-Marie Poretto 的報告,這起軟體漏洞其實來自一個經典的「競態條件(race condition)」:當操作人員快速變更治療模式時,軟體尚未完成前一指令的運算,下一個指令已被送出,導致錯誤堆疊與防護失效。
例如:
-
操作員誤選了電子束模式,接著迅速更改為 X 射線模式
-
軟體仍處於上一筆操作流程中,導致兩種模式混合
-
電子束遮蔽未啟動,病患因此直接暴露於高強度輻射下
這樣的 Bug 曾在 1985 至 1987 年間至少造成六起事故,其中三位患者當場或數天內死亡,另三人重傷、留下永久傷害。
AECL 態度消極,美國 FDA 最終介入調查
製造商 AECL(加拿大原子能公司)最初否認系統有問題,反而歸咎於操作人員。直到 1986 年,美國 FDA(食品藥物管理局)正式介入調查,才揭露真相並要求全面停機整改。
最終,Therac-25 被全面停用,成為醫療設備歷史上的警世教材。
Therac-25 之後:醫療軟體安全的轉捩點
這起事件之後,醫療設備界與電腦科學領域都重新審視「軟體就是安全核心」的概念。Therac-25 成為促成以下改革的契機:
-
所有醫療軟體需進行形式化驗證(formal verification)
-
必須保留硬體層級的安全保護機制
-
強化使用者操作介面的錯誤防護設計
-
撰寫清楚完整的錯誤紀錄與文件
Therac-25 的故事提醒我們,在醫療、交通、核能等高風險領域,軟體錯誤不是小事。再精密的 AI 系統與自動化設備,都需要經過重重驗證與交叉防護,才能避免悲劇重演。
相關資料:https://www.cs.columbia.edu/~junfeng/08fa-e6998/sched/readings/therac25.pdf
- 延伸閱讀:微軟工程師揭露 Windows 7 的奇妙 Bug:設定「純色桌布」竟導致登入慢 30 秒
- 延伸閱讀:AI 能寫程式卻難除錯?微軟研究揭示問題關鍵:不懂人類是怎麼 debug 的
- 延伸閱讀:姓「Null」的人生bug:電腦的出現怎麼將他們的人生變空值
請注意!留言要自負法律責任,相關案例層出不窮,請慎重發文!