2010-02-27スマートフォン用の表示で見るある組込みソフトエンジニアの日記この広告は、90日以上更新していないブログに表示しています。25(セラック25)の事故】Therac-25は高エネルギーの透過性放射線を患者の身体の奥に照射し、周囲の組織を傷つけることなくがん細胞を破壊する装置で、巨大なアームの照射口からは、電子線とX線の二種類の放射線が照射される。透過性の高いX線を生成するときは、高エネルギーの電子の流れを金属製のターゲットにぶつけ、電子線生成モードのときは、金属のターゲットを自動的に移動して電子線のエネルギーレベルを下げ、直接腫瘍にビームを送る。低エネルギーの電子線はX線より透過性が低いため、皮膚の表層に近いがんの治療に使われた。いうミニコンピュータを使って制御を行っていた。ディジタル・イクイップメント・コーポレーション(DEC)が1970年代から1980年代に販売した16ビットミニコンピュータシリーズ。事故では複数の医療機関で放射線治療装置が誤動作し、過大な放射線を浴びた患者に死傷者(6名)がでた。この事故はソフトウェアの不具合が原因であり、見えないソフトウェアのせいで再発防止が進まない中、ナンシー・レブソン(現マサチューセッツ工科大学教授)らの努力により事故原因が詳細に調査され、レポートが発表されており、このレポートは20年以上たった今でも、ソフトウェアエンジニアにとって深い教訓として伝えられてる。詳細が記載されている。事故は20年以上も前に起こった事例だが、ナンシー・レブソンの詳細な調査により現代にいろいろな教訓を残した。普通、後継機種の場合「枯れた」ソフトウェアを再利用できるため、安全や信頼は増す。Therac-20のソースが使われていた。それなのに何故事故が起きたのか。誤解されたくないので、ここで注釈を入れておく。ソフトウェアが絡んだ事故は「○○だから××である」といったように簡単には語れない。プリウスのブレーキソフト改変に関する分析だって結構な時間と労力をかけて書いた。(しかも、本当のことは分かっていないし、ソフトウェアの問題ではないかもしれない。よる事故の原因を知り、自分達のドメインの再発防止に利用したいのなら、必ず原本を読んでいただきたい。ここでは、あえて、複雑な問題発生の原因のうちの一端のみを紹介する。努々ここで紹介したことだけで6名もの犠牲者がでるような事故に発展したのではないことを理解していただきたい。20年も前のソフトウェアエンジニアだって、そこまでいい加減ではないということを強調しておく。枯れたソフトウェア資産を再利用しているのになぜ事故が起こったのかの。その安全装置を取ってしまったことが原因の一端となっている。独立した安全装置が異常エネルギーの出力をブロックしていた。開発をする際に、経済性の理由(たぶんコストダウンだろう)から、このハードウェアの安全装置をソフトウェアに置き換えた。内包していた不具合が表面化してしまった。(実際にはそんな簡単な話ではないがここでは簡略化して書いている)当然のことながら、機器の品質保証担当は「そんなことして大丈夫か?」と思っただろう。対する安全解析を実施した。FTA(フォールトツリー解析)で行われた。インターネットでどんなものか理解しておいて欲しい。次のような報告を出した。引用】ハードウェアエミュレータ上と遠隔治療装置の照射野条件の下で大規模な試験を行うことにより、プログラミングエラーは減少していた。未解決のソフトウェアエラーは分析には含まない。ソフトウェアは長期使用、疲労、あるいは再生産プロセスが原因で品質が低下することはない。コンピュータの実行エラーは、ハードウェアコンポーネントの欠陥や、α粒子や電磁ノイズによって引き起こされる「ソフト」(ランダム)エラーが原因である。このレポートは複雑なソフトウェアを作ったことがない人が書いたのだろう。解説すると、1は、「ハード・ソフト込みのシステム(ハードウェアはエミュレータ)でさんざんいろいろな試験を行ったのでバグはほとんど潰した」ということだ。再現できているので心配ないという主張だ。事故から20年以上たった現在でも、ほとんどの機器がこの方法でシステムの安全を確認している。そこにソフトウェアが絡んでおり、ソフトウェアの規模が大きく、複雑であればあるほど、そのやり方では漏れが生じる。ちなみに、1で「未解決のソフトウェアエラーは分析には含まない。」は正直な申告だと思う。日本人ならこの一文は削除して報告しただろう。未解決のソフトウェアエラーが既存のシステムに影響を与えないという根拠は何もないからだ。この安全解析報告の作成から実際の製品のリリースまでの間にソフトウェアが改変されたらその改変がデグレードを誘発しない保証はない。2の「ソフトウェアは長期使用、疲労、あるいは再生産プロセスが原因で品質が低下することはない。」はハード屋さんがソフトウェアをどう見ているか端的に表している。ようするにハードウェアでは部品の故障や生産時のさまざまな問題があり、品質保証の活動とはこれらの問題をいかに押さえ込むかが我々の仕事なのだ、その点ソフトウェアは何回コピーしても品質が劣化しない、すばらしい、品質は完璧だと考えているのだろう。今となってはソフトウェアの不具合で商品をリコールすることは日常茶飯事になっているから、QA担当もそうは思っていないだろうが、多くのQAはソフトウェアは分からない、自分では品質を保証できないから誰かお墨付きをくれ!と考えているような気がする。3は笑ってしまうが、ソフトウェアの実行エラーは放射線などでメモリーのデータ化けなどが原因であり、バグは1で潰しているから、ハードウェアや外部環境の影響からプログラムやデータを守れば大丈夫だと言っているのだ。障害を発生させる原因コンポーネントとして、「コンピュータの故障」も含まれている。10のマイナス11乗で、「コンピュータが誤ったモードを選択する」が発生する確率は4×10のマイナス9乗となっている。ハードウェア部品として故障する確率を示したのだろうと予想される。このことから安全解析実施者はソフトウェアやソフトウェアの不具合についてほとんど知識がなくブラックボックスとして分析をしていることが分かる。ソフトウェアの恐いところは、どんなに難しいオペレーションでなければ発生しない不具合でも、その通りに操作すると100%確実のその不具合は発生するということだ。6名の犠牲者を出してしまった。現在、トヨタのリコール問題でアメリカが騒いでいるのは、犠牲者が増えることをできるだけ抑えるための手順、プロセスを組織が定めて、それを確実に実施しなさい、また、その手続きの間に隠蔽や怠慢などがあったら絶対に許さない、責任はトップにあると言っているのだと思う。事故が発生したときのオペレーションはその通りなのだが、ソフトウェアが絡んでいるときは困ってしまう。原因が簡単にはわからないし、事故の発生確率をはじき出すのが難しいからだ。ソフウェアがらみのときは、事故の重大性だけでランクを判定する。・アクセルが急加速する→重大といった具合だ。(ソフトウェアが原因だった場合は発生する確率は考慮できない)国際安全規格のリスク(risk)の定義は危害(harm)の発生確率×危害の重大(severity)である。ソフトウェアに起因するリスクにおいては発生確率はハードウェアの部品故障率のようなものにはできない。原因が分かってしまうと直せるなら直せと言われてしまう。今後、ソフトウェアをブラックボックスにしかとらえられないハードウェア出身の組織上位層や品質保証担当が、自組織や協力会社が作ったソフトウェアの安全性や信頼性について第三者に安全性や信頼性についてお墨付きを付けてもらおうという動きが増えることが目に見えているが、ここではっきり言っておくがその考え方では絶対に安全は確保できない。大規模複雑化したソフトウェアの各サブシステムの統合時のわずかな検証漏れ、設計コンセプトの考え方の違いなど、設計者達のヒューマンエラーに起因した問題は、設計サイドの技術者がアーキテクチャを可視化して、自分達で問題点を見つけないと見つからない可能性が高いからである。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。