セラック25

セラック25（Therac-25）とは、カナダ原子力公社 (AECL) とフランスCGR-MeV社によって開発・製造されたコンピュータ制御の放射線療法機器である425。この機械は、1985年から1987年にかけて知られる限り6つの過度の被曝事故を引き起こし、少なくとも5人の患者を死亡させた。装置を制御するオペレーティングシステム (OS) に存在する、並行プログラミングにおける誤り（競合状態とも呼ばれる）が原因で、患者に通常の数百倍もの放射線量を浴びせ、死亡や重傷を負わせることもあった。これらの事故は、生命に関わるようなシステムにおけるソフトウェア制御の危険性を浮き彫りにし、医療情報学とソフトウェア工学における標準的な事例研究のひとつとなった。さらに、技術者の自信過剰と428、報告されたソフトウェアのバグを解決するための適切なデューディリジェンスの欠如は、技術者の初期作業に対する過信とエンドユーザーの主張を信じられなかったことが大きな影響を与えた極端なケースとして強調されている。

**背景**
セラック25はAECL社とCGR社によって、医療用線形加速器セラック6 (Therac-6) とセラック20 (Therac-20) の後継機として開発された。前者は6MeVまでのX線を、後者は20MeVのX線と電子線を生成することができた。セラック25はAECLによって新たに開発されたダブルパス技術を用いた電子加速器であり、従来機に比べてより小さなスペースで、より効率的に25MeVまでのX線と電子線を生成することができた。
これらの機器はいずれもPDP-11によってコンピュータ制御できるが、セラック25は従来機と違って、最初からコンピュータ制御を念頭においてデザインされていた。また、従来機ではハードウェアの監視装置は機器とは独立した電子回路で実装していたが、セラック25ではメンテナンス性のためにこれをソフトウェアで置き換えた。ソフトウェアにはCGR社が開発したセラック6用のコードが多く流用された。またセラック20用のコードもいくつか混入していたが、このコードにはバグがあり、後の事故を引き起こす一要因となった。セラック20にはハードウェアによる安全装置があったため事故は起こらず、このバグはセラック25の事故調査で判明することとなる。
1976年にはプロトタイプ機が製造され、1982年に商業的に販売された。1983年に危険性分析が行われたが、これはソフトウェアのバグの存在を仮定しない、不十分なものであった。

**設計**
この装置には、2つの放射線治療モードがある。- 直接Electron therapyモード：高エネルギー（5 MeV～25 MeV）で、細く、低電流での電子線を磁石によって治療部位全体をスキャンする。- 超高圧X線治療英語版（または光子）モード：25 MeVの電子線をターゲットに衝突させ、放出された固定幅のX線を平坦化フィルターとコリメータの両方に通し、照射する。
また「フィールドライト」モードも含まれており、これにより、治療領域を可視光で照らすことにより患者を正確に位置決めすることができるようになっていた。

**問題の説明**
シミュレートされたTherac-25のユーザーインターフェース
記録された6件の事故は、X線モードで発生させた大電流の電子線を患者に直接照射した際に発生した。原因となったのは2つのソフトウェアの不具合であった。1つは、オペレータがX線モードを誤って選択してからすぐに電子モードに切り替えた場合で、X線ターゲットが配置されていない状態で電子線がX線モードに設定されてしまったことである。もう1つは、ビームスキャナが作動していないフィールドライトモード中に電子線が作動してしまい、ターゲットが配置されていない状態で電子線が作動してしまったことである。
以前のモデルでは、このような欠陥を防ぐためにハードウェア・インターロックがあったが、セラック25ではそれを取り除き、ソフトウェアによる安全性のチェックに頼っていた。
大電流電子線は、意図した線量の約100倍の放射線量で、より狭い範囲で患者に当たり、致死量の可能性のあるベータ線を照射した。患者のレイ・コックス氏は、この感覚を「強烈な電気ショック」と表現し、悲鳴を上げて治療室から飛び出した。数日後、放射線熱傷が現れ、患者は放射線中毒の症状を示した。3つのケースでは、負傷した患者は後に過剰照射の結果として死亡した。

**根本原因**
委員会では、主な原因を、特定のコーディングエラー1つに絞るのではなく、一般的なソフトウェアの設計と開発の仕方の悪さにあるとしている。特に、このソフトウェアは、クリーンな自動化された方法でテストすることが現実的に不可能なように設計されていた。
事故を調査した研究者は、いくつかの原因を発見した。その中には、以下のような制度的な原因が含まれていた。- AECLは、ソフトウェアコードを独立してレビューしておらず、オペレーティングシステムを含む社内のコードに依存することを選択した。- AECLは、機械がどのようにして望ましい結果を出すのか、どのような故障モードが存在するのかを評価する際に、ソフトウェアの設計を考慮せず、純粋にハードウェアに焦点を当て、ソフトウェアにはバグがないと主張していた。- 機械オペレータは、過剰照射は不可能であるとAECLの担当者により安心させられた。その結果として、セラック25が多くの事故の潜在的な原因であるとは考えないようになった428。- AECLは、セラック25が病院で組み立てられるまで、ソフトウェアとハードウェアを組み合わせたテストを実施したことがなかった。
研究者はまた、いくつかの工学的な問題を発見した。- いくつかのエラーメッセージは、単に "MALFUNCTION"という用語の後に1から64までの数字が表示されただけである。ユーザーマニュアルには、エラーコードについての説明やエラーの対処方法はなく、これらのエラーが患者の安全を脅かす可能性があることを示すものすらなかった。- システムは、マシンを停止させて再起動を必要とするエラーと、単にマシンを一時停止させただけのエラー（オペレータがキーを押して同じ設定を続行できる）を区別していた。しかし、患者を危険にさらすようなエラーの中には、単に機械を一時停止させただけのものもあり、軽微なエラーが頻発したため、オペレータは機械の一時停止を解除することに慣れてしまっていた。
** 問題の1つは、PDP-11コンピュータを制御するVT-100端末で特定のキーストロークシーケンスを入力した際に発生したものである。オペレータが「X」を押して（誤って）25 MeV光子モードを選択し、次に「カーソルアップ」で入力を編集して「E」を押して（正しく）25 MeV電子モードを選択し、「Enter」を押す。最初のキー操作から8秒以内にすべてのキーが入力される。これはマシンの経験豊富なユーザーの能力の範囲内である。- この設計には、ターゲットが設置されていない状態で電子線が高エネルギーモードで動作するのを防ぐためのハードウェア・インターロックがなかった。- ソフトウェアの欠陥を隠すためにハードウェア・インターロックを使用していたセラック6とセラック20のソフトウェアを、技術者は再利用していた。これらのハードウェア安全装置にはトリガーされたことを報告する手段がないため、既存のエラーは見落とされていた。- ハードウェアは、ソフトウェアがセンサーが正しく動作しているかどうかを確認する方法を提供しなかった。テーブルポジションシステムは、セラック25の故障の最初の原因となったもので、メーカーは、それらの動作を相互にチェックするために、冗長スイッチで修正した。- ソフトウェアは、フラグ変数を非ゼロの固定値に設定するのではなく、インクリメントすることで設定していた。時折、算術オーバーフローが発生し、フラグがゼロに戻り、ソフトウェアが安全チェックをバイパスする原因となっていた。
ナンシー・レブソン氏は、この事件から得られる教訓は、再利用されたソフトウェアが安全だと思い込まないことだと指摘している。「ソフトウェアを再利用したり、市販のソフトウェアを使用したりすることで安全性が向上するだろう、なぜならば広く利用されているのだから、という素朴な思い込みがよくある。ソフトウェアモジュールを再利用したからといって、それが移行先の新しいシステムでの安全性を保証するわけではない...」。このように、ソフトウェアにコード化された思考体系を不十分な理解のまま盲信することは、カーゴ・カルト・プログラミングとして知られている。セラック25に関連したような事件に対応して、IEC 62304規格が作成された。この規格は、医療機器ソフトウェアの開発ライフサイクル標準と、Software of unknown pedigreeの使用に関する具体的なガイダンスを導入している。

**参照項目**
 IEC 62304- 放射線
*List of civilian radiation accidents- 原子力事故 英語版- Radiation protection

**脚注**

**推薦文献**
 archive-date=2007-12-12 (short summary of the Therac-25 Accidents)- The Therac-25 Accidents (PDF) Nancy LevesonによるIEEE Computerの記事。
*Ａ-III型のソフトウエアの欠陥による放射線治療機事故