セラック25
ハードウェアは、ソフトウェアがセンサーが正しく動作しているかどうかを確認する方法を提供しなかった。テーブルポジションシステムは、セラック25の故障の最初の原因となったもので、メーカーは、それらの動作を相互にチェックするために、冗長スイッチで修正した。
ソフトウェアは、フラグ変数を非ゼロの固定値に設定するのではなく、インクリメントすることで設定していた。時折、算術オーバーフローが発生し、フラグがゼロに戻り、ソフトウェアが安全チェックをバイパスする原因となっていた。
ナンシー・レブソン氏は、この事件から得られる教訓は、再利用されたソフトウェアが安全だと思い込まないことだと指摘している。「ソフトウェアを再利用したり、市販のソフトウェアを使用することで安全性が向上するという素朴な思い込みがよくある。ソフトウェアモジュールを再利用したからといって、それが移行先の新しいシステムでの安全性を保証するわけではない...」。このように、ソフトウェアにコード化された思考体系を不十分な理解のまま盲信することは、カーゴ・カルト・プログラミングとして知られている。セラック25に関連したような事件に対応して、IEC 62304規格が作成された。この規格は、医療機器ソフトウェアの開発ライフサイクル標準と、経歴未確認ソフトウェア(英語版)の使用に関する具体的なガイダンスを導入している。
セラック25(Therac-25)とは、カナダ原子力公社 (AECL) とフランスCGR-MeV社によって開発・製造されたコンピュータ制御の放射線療法機器である。この機械は、1985年から1987年にかけて知られる限り6つの過度の被曝事故を引き起こし、少なくとも5人の患者を死亡させた。装置を制御するオペレーティングシステム (OS) に存在する、平行プログラミングにおける誤り(競合状態とも呼ばれる)が原因で、患者に通常の数百倍もの放射線量を浴びせ、死亡や重傷を負わせることもあった。これらの事故は、生命に関わるようなシステムにおけるソフトウェア制御の危険性を浮き彫りにし、医療情報学とソフトウェア工学における標準的な事例研究のひとつとなった。さらに、技術者の自信過剰と、報告されたソフトウェアのバグを解決するための適切なデューディリジェンスの欠如は、技術者の初期作業に対する過信とエンドユーザーの主張を信じられなかったことが大きな影響を与えた極端なケースとして強調されている。
委員会では、主な原因を、特定のコーディングエラー一つに絞るのではなく、一般的なソフトウェアの設計と開発の仕方の悪さにあるとしている。特に、このソフトウェアは、クリーンな自動化された方法でテストすることが現実的に不可能なように設計されていた。
事故を調査した研究者は、いくつかの原因を発見した。その中には、以下のような制度的な原因が含まれていた。
AECLは、ソフトウェアコードを独立してレビューしておらず、オペレーティングシステムを含む社内のコードに依存することを選択した。
AECLは、機械がどのようにして望ましい結果を出すのか、どのような故障モードが存在するのかを評価する際に、ソフトウェアの設計を考慮せず、純粋にハードウェアに焦点を当て、ソフトウェアにはバグがないと主張していた。
機械オペレータは、過剰照射は不可能であるとAECLの担当者により安心させられ、多くの事故の潜在的な原因としてセラック25に対する考慮を止めさせた。
AECLは、セラック25が病院で組み立てられるまで、ソフトウェアとハードウェアを組み合わせたテストを行ったことがなかった。
研究者はまた、いくつかの工学的な問題を発見した。
いくつかのエラーメッセージは、単に "MALFUNCTION"という用語の後に1から64までの数字が表示されただけである。