自分はFTAを描くときに Enterprise Architect というUMLツールを使っている。FTA だけでなく、ソフトウェアはモデルを描いて分析しなければ全体を俯瞰できないところまで規模が拡大し複雑性が増している。
しかも、モデルはプログラムと同じで一回描いたら終わりということはない。ソフトウェア開発の上流工程である要求分析からアーキテクチャ設計、詳細設計まで頻繁に書き換えるし、テストしながらモデルの問題に気がついて直すこともある。
だからそこモデルは容易に変更が可能で情報を共有したり場合によってはドキュメントとして印刷できるようになっていた方がよい。
そういった背景があってUMLのモデルを描くのに Enterprise Architect を使っている。Enterprise Architect はバージョン9.3以降でインストーラにFTAの作図機能が同梱されており、すべてのエディションで後から追加して利用できるようになっている。
FTAの作図
Enterprise Architect を提供する、スパークスシステムズ・ジャパン のサイトにFTAの作成について解説があるので、そこから少し引用したいと思う。
【FTA作図の要素】
| 事象 |  |
トップ事象あるいは中間の事象。他の事象の組み合わせで表現される。 |
| 通常事象 |  |
通常の状況で発生する事象。 |
| 基本事象 |  |
展開不可能な、基本的な事象。展開することはできない。 |
| 否展開展開事象 |  |
現時点では展開できない事象。追加の情報取得や状況の変化などにより、将来的に展開可能になる場合がある。展開することはできない。 |
| 移行記号 |  |
図を分割する場合に利用する記号。 |
| ANDゲート・ORゲート |   |
上位(上)の事象と、複数の下位(下)の事象の関係を示す。ANDゲートは、下位の全ての事象が発生すると上位の事象が発生する。ORゲートは、下位の少なくとも1つが発生すると、上位の事象が発生する。 (ANDゲートは、下位の事象の発生確率の積が、上位事象の発生確率となる。ORゲートは、下位の事象の発生確率の和が、上位事象の発生確率となる。) |
| 制約ゲート・条件 |  |
事象に発生条件がある場合、その条件を明示するためのゲートと要素。 (下位の事象の発生確率と条件の確率の積が、上位事象の発生確率となる。) |
【FTAの特徴】
FTAの特徴はある事象が発生するための要因を複数描くことができ、しかもその要因がANDの要因で発生するのか、ORの要因で発生するのかを図で表せる点にある。
描いてしまえばどうってことない図だが、1961年当時ミニットマンミサイルをなんとしても固体燃料で飛ばしたいという意志とベル研究所のH・A・ワトソンのグループのアイディアがこの表記法を生んだのである。その歴史を踏まえつつ、ありがたく使わせてもらおう。
さて、上記の図で○の基本事象はこれ以上展開できないということをしてしており、長方形の事象を起こす要因は別にあると考えられるためさらに展開が可能だ。だから、FTAはトップから下に向かって広がっていく。その様が故障の木：Fault Tree と表現されているのである。
FTA の特徴として、このように各事象の発生確率を追記することができる。 Enterprise Architect はこの確率を自動的に計算する機能もある。
ここで気をつけて欲しいのは、FTAの事象の発生確率は一人歩きしやすいという点だ。
モデルに数値が追加されるととたんにもっともらしくなって、例えば論文などに好んで使われるようになる。
自然科学の場合は論文に記された数字は裏付けとなる根拠が求められる。しかし、品質工学、情報工学で示される確率の数字はあてにならない場合があるので鵜呑みにしてはいけない。
FTA で事象の確率を記載できるようにしたのは画期的ではあった。ORゲートで結合されている事象の場合低い確率の事象と高い確率の事象があれば、高い確率の事象の発生を抑える対策を取った方が、トップ事象の発生確率を低くできるはずだ。
議論を進める前に、ここで Random Failures （ランダム故障）とSystematic Failures/Faults （決定論的原因故障/障害）の違いをおさらいしておきたいと思う。
■Random Failures （ランダム故障）
■Systematic Failures/Faults （決定論的原因故障/障害）
FTA で事象の発生確率を論じることができるのは、事象が Random Failures のときだけだ。Systematic Failures が要因であった場合、発生確率を論じるのは極めて困難だ。例えば、滅多に通らないパスで NULL ポイントを使っていて、そこを通ると過大なエネルギーが照射されて患者が火傷を負うとする。
一万回ユーザビリティの実験を実施して一回のみオペレータがその滅多に通らないパスを通るような条件で操作をしたとしよう。この場合、この Systematic Failure が起こる確率は一万分の一と言えるだろうか。その希な操作を好んで実施するオペレータがいた場合、Systematic Failure の起こる確率は高くなる。
この問題は、製造業者とユーザーの心理的な感情そして、技術者の倫理に関わる問題なのだ。Systematic Failures の場合、問題のある箇所のソフトウェアを修正すれば永久にその不具合の発生を防ぐことができる。それができるのに発生確率が低いという論理で、既知の不具合を放置することは、事故が起こってしまえばユーザーは製造業者を許さないだろうし、技術者の倫理的観点から見ても許されることではない。
機器製造業者は Systematic Failure が発生するまでは、 Systematic Failure を生み出す可能性のあるバグを作り込まないまた、摘出する努力（さまざまな品質向上活動やマネジメント）を最大限したかどうかを問われるのだが、一度でも重大な Systematic Failure につながるバグを見つけたらすでに市場に出回っているソフトウェアも含めて確実に修正しなければいけない。 Random Failure の場合は、その確率の低さを根拠に修正しないという選択肢もあるのでその点が最大の相違点である。
したがって、 Systematic Failure に起因するリスクを考えるとき、一般的にはリスクの Severity（重大度）のみを評価し、Probability（発生確率）は1と置くのである。ようするに、Systematic Failure に起因する障害により事象が発現する可能性があるのであれば、事象の発生確率を担保に安全対策を取らないという選択をしてはならないのである。
1980年代に事故を起こした放射線治療器 Therac-25 の開発では「コンピュータが誤ったエネルギーを選択する」が発生する確率は 10のマイナス11乗で、「コンピュータが誤ったモードを選択する」が発生する確率は4×10のマイナス9乗となっていた。
「コンピュータが誤ったエネルギーを選択する」と「コンピュータが誤ったモードを選択する」は、正確に言えば、「ソフトウェアが誤ったエネルギーを選択する」と「ソフトウェアが誤ったモードを選択する」となり、これらは Systematic Failure が要因になりうるので、確率は10のマイナス11乗、4×10のマイナス9乗どころか1と考えなければいけない。
結局、コンピュータをハードウェア部品と考えランダム故障しかしない部品としたことが、そもそもの間違いだ。自分は Therac-25 の FTA が 1980年代という古い時代のものであったとしても、たましいの入っていない分析になっていたと思っている。 Therac-25 が人を簡単に殺せるような巨大なエネルギーを照射できることがエンジニアの頭に残っていれば、このような分析にはならなかったのではないかと思う。
FTA における事象の発生確率を見るときには二つのケースがあり、二つの視点が必要だ。一つは相当な根拠があり発生確率を考慮してもよい場合、もう一つは、発生確率に再現性の裏付けがなく、「まあ、そんなもんだろう」という程度で数字を見ないといけない場合だ。
クリティカルな事象を検討するとき、発生確率に統計的な裏付けがある場合は、FTAのダイアグラムにノートとして事象の発生確率の根拠を書き示しておくとよい。
ところで、FTA の事象の要因が Random Failures だったとしてもその発生確率を過大評価するのは危険だと思う。
例えば、事象の発生要因がハードウェア部品の故障だったとしよう。ハードウェアの部品故障ならば、統計的に発生確率を計算できるし、その値もそれなりに信頼できるだろう。しかし、その部品を高信頼性部品としてシステムのクリティカルな部分に使う場合、本当にその確率の数字を信用していいのかよく考えて見る必要がある。
ハードウェアの部品の故障は Random Failures だといっても、さいころを振ったときの1の目がでる確率のようには起こらない。
部品の故障率が時間とともにバスタブのように変化することはよく知られている。初期故障期間では故障の発生確率は高く、その後故障率は一定になり、耐用寿命を過ぎるとまた故障率は高くなる。
FTA に使われる確率はバスタブ曲線の偶発故障期間の値だろう。しかし、システム導入初期また、耐用寿命を過ぎてからの高い故障率は考慮しなくてもよいのだろうか。耐用寿命を超えてもシステムを使い続けて事故が起こった場合の責任はユーザーにあるのだろうか。
40年を耐用期限としている事故が起こると甚大な被害を及ぼす機器の使用期限を延ばしたときに、FTAに使った確率は変わらないのだろうか。
また、Random Failure の部品であっても、バスタブ曲線のような変化をしないものもあるだろう。そう考えると FTA における事象の発生確率は確率が低いからといって決して過信してはいけない。
ランダムかシステマティックかといったことではなく、ソフトウェアの品質向上に関する方法論を適用して、従来より○○%向上したという記述をよく見かけるが、その数字も自分は信用していない。人間の活動を評価しようと思っても、技術者のソフトウェア開発という活動が統計的な母集団を持つとは思えないからだ。癖のあるやつは常に癖があるし、慎重な者でも体調が悪ければミスを犯す。人種や組織文化などにも影響を受ける。
同じプロジェクトにならその数字もある程度再現性はあるのかもしれないが、他の組織や、他の業種、他の国で同じ結果がでるかどうかはわからない。
だから、FTAはトップ事象をどうしたら起こさないで済むか、製品やシステムをエンドユーザーに安全に使ってもらうことができるかを考えるエンジニアの「品質を心配する意識（Awareness: Worrying about Quality）」が良い解析ができるかどうかを左右すると思う。
描いてしまえばどうってことない図だが、1961年当時ミニットマンミサイルをなんとしても固体燃料で飛ばしたいという意志とベル研究所のH・A・ワトソンのグループのアイディアがこの表記法を生んだのである。その歴史を踏まえつつ、ありがたく使わせてもらおう。
さて、上記の図で○の基本事象はこれ以上展開できないということをしてしており、長方形の事象を起こす要因は別にあると考えられるためさらに展開が可能だ。だから、FTAはトップから下に向かって広がっていく。その様が故障の木：Fault Tree と表現されているのである。
ここで気をつけて欲しいのは、FTAの事象の発生確率は一人歩きしやすいという点だ。
モデルに数値が追加されるととたんにもっともらしくなって、例えば論文などに好んで使われるようになる。
自然科学の場合は論文に記された数字は裏付けとなる根拠が求められる。しかし、品質工学、情報工学で示される確率の数字はあてにならない場合があるので鵜呑みにしてはいけない。
FTA で事象の確率を記載できるようにしたのは画期的ではあった。ORゲートで結合されている事象の場合低い確率の事象と高い確率の事象があれば、高い確率の事象の発生を抑える対策を取った方が、トップ事象の発生確率を低くできるはずだ。
議論を進める前に、ここで Random Failures （ランダム故障）とSystematic Failures/Faults （決定論的原因故障/障害）の違いをおさらいしておきたいと思う。
■Random Failures （ランダム故障）
- 構成部品・機器などの多様な劣化のメカニズムの下で時間的に無秩序に発生する故障。
- 故障率を計測することで統計的に品質を管理する。
- まず、ランダム故障は故障率が計測できる故障だから統計的に管理できる。だからこそ、統計的品質管理論によって品質を高めることができる。
■Systematic Failures/Faults （決定論的原因故障/障害）
- ハードウェアの設計に起因するもの、ソフトウェアのバグやソフトウェアに起因する問題やユーザーオペレーションが原因で発生する障害発生率の予測が難しい故障/障害
- 出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。
- 開発のプロセス（工程）、ライフサイクルの中で Systematic Failures/Faults の作り込みを防止し、検証や妥当正確認によって発見・除去する。
FTA で事象の発生確率を論じることができるのは、事象が Random Failures のときだけだ。Systematic Failures が要因であった場合、発生確率を論じるのは極めて困難だ。例えば、滅多に通らないパスで NULL ポイントを使っていて、そこを通ると過大なエネルギーが照射されて患者が火傷を負うとする。
一万回ユーザビリティの実験を実施して一回のみオペレータがその滅多に通らないパスを通るような条件で操作をしたとしよう。この場合、この Systematic Failure が起こる確率は一万分の一と言えるだろうか。その希な操作を好んで実施するオペレータがいた場合、Systematic Failure の起こる確率は高くなる。
この問題は、製造業者とユーザーの心理的な感情そして、技術者の倫理に関わる問題なのだ。Systematic Failures の場合、問題のある箇所のソフトウェアを修正すれば永久にその不具合の発生を防ぐことができる。それができるのに発生確率が低いという論理で、既知の不具合を放置することは、事故が起こってしまえばユーザーは製造業者を許さないだろうし、技術者の倫理的観点から見ても許されることではない。
機器製造業者は Systematic Failure が発生するまでは、 Systematic Failure を生み出す可能性のあるバグを作り込まないまた、摘出する努力（さまざまな品質向上活動やマネジメント）を最大限したかどうかを問われるのだが、一度でも重大な Systematic Failure につながるバグを見つけたらすでに市場に出回っているソフトウェアも含めて確実に修正しなければいけない。 Random Failure の場合は、その確率の低さを根拠に修正しないという選択肢もあるのでその点が最大の相違点である。
したがって、 Systematic Failure に起因するリスクを考えるとき、一般的にはリスクの Severity（重大度）のみを評価し、Probability（発生確率）は1と置くのである。ようするに、Systematic Failure に起因する障害により事象が発現する可能性があるのであれば、事象の発生確率を担保に安全対策を取らないという選択をしてはならないのである。
1980年代に事故を起こした放射線治療器 Therac-25 の開発では「コンピュータが誤ったエネルギーを選択する」が発生する確率は 10のマイナス11乗で、「コンピュータが誤ったモードを選択する」が発生する確率は4×10のマイナス9乗となっていた。
「コンピュータが誤ったエネルギーを選択する」と「コンピュータが誤ったモードを選択する」は、正確に言えば、「ソフトウェアが誤ったエネルギーを選択する」と「ソフトウェアが誤ったモードを選択する」となり、これらは Systematic Failure が要因になりうるので、確率は10のマイナス11乗、4×10のマイナス9乗どころか1と考えなければいけない。
結局、コンピュータをハードウェア部品と考えランダム故障しかしない部品としたことが、そもそもの間違いだ。自分は Therac-25 の FTA が 1980年代という古い時代のものであったとしても、たましいの入っていない分析になっていたと思っている。 Therac-25 が人を簡単に殺せるような巨大なエネルギーを照射できることがエンジニアの頭に残っていれば、このような分析にはならなかったのではないかと思う。
FTA における事象の発生確率を見るときには二つのケースがあり、二つの視点が必要だ。一つは相当な根拠があり発生確率を考慮してもよい場合、もう一つは、発生確率に再現性の裏付けがなく、「まあ、そんなもんだろう」という程度で数字を見ないといけない場合だ。
クリティカルな事象を検討するとき、発生確率に統計的な裏付けがある場合は、FTAのダイアグラムにノートとして事象の発生確率の根拠を書き示しておくとよい。
ところで、FTA の事象の要因が Random Failures だったとしてもその発生確率を過大評価するのは危険だと思う。
例えば、事象の発生要因がハードウェア部品の故障だったとしよう。ハードウェアの部品故障ならば、統計的に発生確率を計算できるし、その値もそれなりに信頼できるだろう。しかし、その部品を高信頼性部品としてシステムのクリティカルな部分に使う場合、本当にその確率の数字を信用していいのかよく考えて見る必要がある。
ハードウェアの部品の故障は Random Failures だといっても、さいころを振ったときの1の目がでる確率のようには起こらない。
FTA に使われる確率はバスタブ曲線の偶発故障期間の値だろう。しかし、システム導入初期また、耐用寿命を過ぎてからの高い故障率は考慮しなくてもよいのだろうか。耐用寿命を超えてもシステムを使い続けて事故が起こった場合の責任はユーザーにあるのだろうか。
40年を耐用期限としている事故が起こると甚大な被害を及ぼす機器の使用期限を延ばしたときに、FTAに使った確率は変わらないのだろうか。
また、Random Failure の部品であっても、バスタブ曲線のような変化をしないものもあるだろう。そう考えると FTA における事象の発生確率は確率が低いからといって決して過信してはいけない。
ランダムかシステマティックかといったことではなく、ソフトウェアの品質向上に関する方法論を適用して、従来より○○%向上したという記述をよく見かけるが、その数字も自分は信用していない。人間の活動を評価しようと思っても、技術者のソフトウェア開発という活動が統計的な母集団を持つとは思えないからだ。癖のあるやつは常に癖があるし、慎重な者でも体調が悪ければミスを犯す。人種や組織文化などにも影響を受ける。
同じプロジェクトにならその数字もある程度再現性はあるのかもしれないが、他の組織や、他の業種、他の国で同じ結果がでるかどうかはわからない。
だから、FTAはトップ事象をどうしたら起こさないで済むか、製品やシステムをエンドユーザーに安全に使ってもらうことができるかを考えるエンジニアの「品質を心配する意識（Awareness: Worrying about Quality）」が良い解析ができるかどうかを左右すると思う。
0 件のコメント:
コメントを投稿