2012-10-27

ISO 26262との向き合い方 (17) 安全機能の複雑性を分析する

最近、ISO 26262 の ASIL D に対応した○○を開発しましたとか、△△(ツールの名前)が ISO 26262 の認証を取りましたとか、ISO 26262 の適合支援をしますといったニュースリリースをよく見かける。

そのような喧噪をよそに、今回も複雑な安全機能に対してエンジニアはどう対処してけばよいのかについて書こうと思う。

さて、前回の記事『ISO 26262との向き合い方 (16) 安全を売りにすることの意味』の冒頭で取り上げた日産自動車が開発したという「緊急操舵回避支援システム」について掘り下げて考えてみる。(公開情報だけで考えているので想像している部分と現実とは違っているかもしれません。ブログでは特定の会社のシステムを評価したいのではなく、安全機能の複雑性について理解を深めたいだけなので、その点、誤解なきようよろしくお願いします。)

緊急操舵回避システムの分析

日産自動車が2012年10月17日に発表した日産のニュースリリース『日産自動車、「緊急操舵回避支援システム」を開発』は、よく読んでみると、まだ市販の乗用車への搭載の予定は書かれていなかった。実用実験の成果を発表した段階ということのようだ。

ニュースリリースを読むと、緊急操舵回避支援システムは1台のカメラ、3つのレーダー、5つのレーザースキャナを入力源として使っている。添付されいている資料によると、「前方衝突回避支援コンセプト」と「緊急操舵支援システム」が作動する一般的なシナリオは次のようなものが想定されている。(YouTubeによる動画はこちら。すごいです。)

【前方衝突回避支援コンセプト】
  1. 対象物を検知・識別する。
  2. ドライバーに警告を発する。
  3. 緩やかな減速を開始。
  4. 衝突に備えてシートベルトをきつく締める。
  5. コンマ数秒後、システムが衝突回避の限界に近づきドライバーが自力で衝突を回避できないと判断すると緊急ブレーキを作動しはじめ、衝突回避動作を支援する。
【緊急操舵支援システム】
  1. 対象物を検知・識別する。
  2. ドライバーに警告を発する。
  3. 物理的に回避可能な限界に近づきドライバーの操作は不十分と判断する。
  4. ECUは緊急ブレーキと緊急ステアリングのどちらで対応するかを一瞬で決定する。
  5. ステアリングが最適な措置の場合ハンドルを切ることが可能な方向をドライバーにモニタで知らせる。
  6. その直後に必要な操作(緊急ブレーキの作動か、緊急操舵か、それらの両方)を正確に実行する。
資料には「考えられるすべてのシナリオでこのシステムを検証し、高い効果を確認した。」とあったが、シナリオは無限に存在するので検証が終わったと判断するのはなかなか難しいと思う。

記事をもとに緊急操舵支援システムの入力部と衝突リスクを分析判定するECUの関係を図に書いてみた。分析判定のECUはもしかしたら一個ではないかもしれないが、ここはシンプルに一つだと仮定した。

ちなみに、レーダーとは電磁波を照射してその反射波を受信するデバイスで、照射された電磁波は広範囲に広る。一方レーザーは直進性が高く探りたい方向に向けて首を振らなければいけない。だからレーザーの方はスキャニングする必要がある。レーダーよりはデバイスの内部構造が複雑になると想像する。

まず、これらの入力装置だけを考えてもこの安全機能の複雑性がうかがえる。1つのカメラ、3つのレーダー、5つのレーザースキャナはそれぞれ監視するエリアがオーバーラップしてはいるものの、各自持ち場、見張る方向、センシングの方法が異なるので、どれかが故障すると緊急操舵支援システムは期待通りの働きができない。

合わせて9つのセンサを使っていて、どれか一つが故障してもシステムは正常動作しないという状態を FTA で描くと左記のようになる。

どのセンサが故障してもトップ事象の「緊急操舵支援システムのセンサ入力が利用できない」に至るため各基本事象は OR で接続される。

仮に各部品の故障率が 0.0001(1万分の1)だった場合、トップ事象としての故障率は各故障率を足すため0.0009 となり、およそ10倍の故障率にあたる 1000分の1に近づく。

たぶん、現実はそんなに故障率は高くないだろう。1000万分の1くらいかもしれない。頻度の低い使用なら問題ないレベルだろうが、例えば自動車の場合は販売量が非常に多い。10万台売れて100回使えば、トータルで1000万回になる。センサの故障は無視できるレベルではないことが分かる。

なお、故障状態を検出する手段があれば、どれかのセンサが故障した時点で故障状態を表示して修理に出して欲しいとドライバーに訴えることになる。修理をしてもらえば確率は元に戻るから、この足し算は必ずしも現実的とは言えない。また、部品の故障率は自動車のライフサイクルに対して一定であるとも限らない。自動車が生産されて廃棄されるまでの期間が仮に10年だったとして最後の1年がその前の9年と同じ確率かどうかは分からない。部品の故障率がバスタブ曲線状に変わる場合、製造後10年経過したときの「緊急操舵支援システムのセンサ入力が利用できない」確率は上記の確率よりも高くなっているかもしれないのだ。だから、FTAにおける事象発生の確率が一人歩きしないように注意しなければいけない。FTA における確率は目安というか、分析者がどれくらいの故障率を考えているかの程度の意思表示のようなものだ。後述する Systematic Failures や Usability が絡んでくると Random Failures の確率はトップ事象の発生に対して影響が小さくなってくる。(部品の故障に気を配っても、ソフトウェアの不具合やユーザーの誤使用で簡単にトップ事象が発生してしまうようになるということ) FTA における確率は 1/100 か 1/1000 か 1/10000 かくらいのおおざっぱなことを示すことが多いような気がする。(厳密な測定結果に基づく場合もあるかもしれないが・・・)

よって、上記の FTA 図で分析者やレビューワーが認識すべきなのは、9つのセンサがトップ事象に与える影響が同等であるということだ。別な言い方をするとどのセンサが故障しても緊急支援システムの正常動作の障害になるということである。そのリスクを軽減するための手段として、Fault Tolerant (構成部品の一部が故障しても正常に処理を続行するシステム)の構成を考えることはできる。ようするに部品の故障を見越して同じ役割分担のセンサを複数設置するという考え方だ。故障率の低い高信頼性部品に頼らず、標準部品を並列に設置して信号出力の OR を取るという安全設計の方法は故障期間がわずかでもあるとまずいようなシステムで使われている。

このケースでは例えば、前方レーダーが故障したときのことを考えて、もう一つ前方レーダーを設置する。宇宙で簡単に修理ができないときは、そういう選択肢は大いにありうるだろう。しかし、自動車の場合、前述の例のように部品が故障したことが分かれば、ドライバーに異常を知らせ、販売店で修理をしてもらえるので、コストアップにもつながるし、このケースでは Fault Tolerant は採用されないと考えられる。

そうなると重要なのは各センサが故障しているかどうかを正確に判定できるかどうかだ。衝突リスク分析判定ECUに入力される情報だけでセンサの故障が判定できれば一番よいが、センサからの入力だけでは確実に判定できない場合、故障検出のためのハードウェアを追加しなければいけない。

上記のセンサ故障の FTA の図にセンサの故障検出デバイスの故障事象を追加して、トップ事象を「緊急操舵支援システムを故障状態で使ってしまう」にしてみた。センサが故障していても、ドライバーがそれに気がついていればリスクを減らせる。しかし、センサの故障検出デバイスが故障していたら、センサの故障を知らせることはできない。

それなら、センサの故障検出デバイスの故障を検出するデバイスを追加するかと考える。こうやって、リスクコントロール手段は追加すればするほど、リスクが具現化する確率を減らすことができる。(AND接続が可能となるため、確率はどんどん小さくなっていく。)

しかし、リスクコントロール手段を追加するたびにコストは上がるし、システムが複雑化する。システムが複雑になることにより新たな Hazardous Situation が生まれるかもしれない。設計者が恐れるのは前者よりも後者の方だ。アーキテクチャが複雑になるとシステムが完全に動作するかどうかの検証作業も増える。故障検出機能の検証のためには故障状態を再現しなければいけない。完成品ではなかなか再現できないから、劣化の加速試験やシミュレーションが必要になる。シミュレーション環境を準備したら、シミュレーション環境が期待通りに動いているかどうかを Validation(妥当性確認)しないといけない。もう、切りがないのである。

なお、ここまで書いたことは FTA が発明された 1960年代の分析とそれほど変わりはないと思っている。静的な構造ベースでの 故障解析はなんだかんだ言っても有限の場合分けにしかならない。複雑でもいろいろなケースを想定して積み上げていけば、トップ事象を起こさない確率を高めることはできる。

故障の原因が統計的な要因のみ、すなわち Random Failures だけならなんとかなる 。しかし、そこに、Systematic failures や Usability が絡んでくると問題はそんなに簡単ではなくなる。

機能の独立性が脅かされるということ

緊急操舵回避システムの制御モデルを描くとこんな感じかではないかと思う。ブレーキ制御やステアリング制御はこんなに単純ではないと思うが、まずはこの単純なモデルで考えて見たい。

さきほどは、センサ類の入力側のデバイスの故障について考えたが、緊急操舵回避システムでは「表示灯」「表示装置」「警告ブザー」といった出力系のデバイスも制御しなければいけない。

それぞれの出力デバイスの故障も入力系と同じだが、表示装置となるモニタはもしかするとTVやカーナビと共通で使用するかもしれないので複雑性はさらに増加する。

緊急操舵回避システムでは、緊急時のドライバーがどちらにステアリングを切ればよいかを指示する。その指示をドライバーが実行できないとシステムが判断したときに初めてシステムが自動でステアリングを操作する。

だから、表示装置で方向を指示しなければいけない。カーナビ画面に小さく赤い矢印を出したのでは気づかれないかもしれない。いったん画面を全部消してでかでかと矢印を表示しないといけないだろう。しかも滅多に表示されるものではないから、それが何を意味するのか瞬時に判断できるようでなければいけない。ドライバーが20代でも30代でも40代でも50代でも60代でも70代でも判断できなければいけない。人が絡んだ安全オペレーションを考えるときは、Usability の分析も必要になる。相手が人間になると、統計的な手法の信頼性は低下する。Usability 分析で有効なのは シナリオである。どんなユーザーシナリオを想定したのかを記録しておく必要がある。よく使われるシナリオ、最大負荷となるシナリオを分析段階で記録しておき、それをもとに作ったシステムで事故が起こったら、事故のシナリオを追加して再分析する。人間の行動には一貫性はないから、設計時に想定できないような振る舞いをされることは現実にある。したがって、このフィードバックサイクルを積み重ねることが Usability 起因のリスク対策には有効となる。だから、実戦経験のない機能を初めて市場に出すときは、 Usability 対策が未熟であることはよくある。

さて、緊急操舵回避システムとカーナビとTVで表示装置を共有したのなら、緊急操舵回避システムが他に対して優先順位が高くなければいけないのだが、期待通りに動いていることは誰が検証するのか。カーナビ屋さんが「オレには知ったこっちゃない」と考えていると、思わぬコミュニケーションギャップにより緊急時に画面が切り替わるかどうかのテストが漏れる可能性がある。リスクレベルが高いシステムとリスクレベルが低いシステムでデバイスを共有する場合は、そこにある意識の違いがミスを生む可能性がある。

それはそれとして、緊急操舵回避システムで最も大きな問題は機能の独立性が崩れることだと考えている。

左の図を見てもらいたい。かつて自動車はその基本機能である、ステアリング、ブレーキ、エンジン(加速)の機能は完全に独立していた。

それぞれの機能は他の機能を意識する必要がなく、各機能の信頼性を高めることに集中すればよかった。これはソフトウェアの構造化設計、オブジェクト指向設計の基本である高凝集(High Cohesion)、疎結合(Low Coupling) の状態である。高凝集・疎結合が実現できていると、開発チーム側の役割分担もしやすい。

また、この図で分かるように機能にトリガーをかけるのはすべてドライバーである。それぞれの機能が正常に動作していれば、ステアリングのミス、ブレーキの遅れ、アクセルとブレーキの踏み間違いはすべてドライバーの責任になる。(『ISO 26262との向き合い方 (16) 安全を売りにすることの意味』参照のこと)

その後、ステアリングもブレーキもエンジン・アクセル制御も ECUとソフトウェアが絡むようになって、ブレーキとアクセルが同時に踏まれたときは、ブレーキを優先させるという判定をECU内部で行うようになった。このことは、ブレーキ制御とアクセス制御のECUに間に結合が生まれたことになるが、この程度であれば非常に小さな結合で留まっていると言えるだろう。


それがプリクラッシュセーフティのように自動でブレーキを制御することになるとシステムの中に大きな結合ができてしまう。

衝突回避のための自動ブレーキなら入力はもっと少なくてもよいかもしれないが、それでも衝突リスクを分析・判定するシステムの複雑性は小さくない。

一番の懸念事項は運転手のブレーキ操作、ステアリング操作と衝突リスク分析判定ECUの判断が異なった場合はどうするかだ。

衝突回避のブレーキシステムの場合は、ドライバーがステアリング操作をした場合、緊急ブレーキは動作させない仕様だったと思う。この場合は、上記の図でステアリング制御ECUから衝突リスク分析判定ECUに向かう矢印が一本増える。それによって、ステアリング制御と衝突リスク分析判定機能は結合したことになる。

そして、緊急操舵支援となるとこのように結合度はさらなに強くなる。

ドライバーのハンドル操作やブレーキペダル、アクセルペダルの操作と衝突リスク分析判定ECUの判断が相反したときの問題もさることながら、刻々と変わる状況に対して、センサーからの入力やドライバーの操作、ブレーキかステアリングかといった複雑な判定が必要になる。しかも、その判断は時間毎に変えなければいけないのである。

部品故障に関しても、緊急事態でないときに故障が分かればよいが、仮に衝突回避の直前または回避中にセンサ類に異常が検出されてしまった場合、どのような対応をしなければいけないだろうか。

故障検出が割り込み処理で入ってくるのか、ポーリングなのかによっても状況は変わってくる。衝突リスク分析判定ECUが自分で故障検出デバイスをポーリングするようになっていれば、衝突回避動作中はポーリングをやめればテストケースは減る。(衝突回避動作に入ったらセンサの情報は使わないという設計にした場合)

しかし、割り込み処理だったら、衝突回避中だろうがなんだろうが割り込まれてきて、故障認識時の処理が意図せず動いてしまうかもしれない。衝突回避中だけは割り込みを無視するようなソフトウェア設計にすると、ソフトウェアアイテムの高凝集(High Cohesion)、疎結合(Low Coupling)が崩れてくる。そうなってしまったソフトウェアを完璧にテストしようと思ったら、すべてのタイミングで期待通りの動作するかどうか検証しなければならず、有限の場合分けができなければ永遠にテストは終わらない。

この記事の前半で、静的な構造に関する問題だけならば有限事象なので検証は時間がかかっても収束するといったのはこのことだ。静的な構造の要素だけでなく、時間によって状況が変わる事象を考えなければいけないとなると、シナリオはすぐに爆発し、検証作業が時間切れになる可能性が高まる。

3.11 の後に「想定外を想定する」といったキーワードをよく聞いたが、時間によって状況が変化してしまう場合、想定外はあるという前提でシステムを設計しないと事故は起こってしまう。「想定外を想定する」のではなく、「想定外が起こる前提で最も効果的な安全対策を考えよう」が正しいアプローチだと思う。

システマティック故障

これまでの話の中で、ソフトウェアの中の問題(=バグ)は考慮していなかった。しかし、9つのセンサの入力をリアルタイムに解析するとなると、解析の中には画像解析も含まれる訳だから、ソフトウェアの複雑化は避けらず、バグがまったくない状態にするのは相当難しい。ソフトウェアの内部構造を高凝集・疎結合にする努力はしたとしても、メモリリークなどがあるとその影響は他に伝搬してしまうし、仕様変更や不具合対策でソフトウェアを変更するとそれによって新たなバグを生む可能性もある。

ただ、だからといってツールや開発プロセス、各デバイスの高信頼性化だけに着目するのは木を見て森を見ずであると感じる。もっと上位層、要求仕様や安全やリスク分析の中で考えるべき問題、抽象化できない具体的なリスクやハザードに対するリスクコントロールについて考えることが遙かに重要である。抽象論ではなく、具体的なリスクを前にして、そこに対処することがシステムやユーザーの安全への寄与が大きいということを安全設計をするエンジニアは忘れてはいけない。

機器製造業者としては複雑な安全機能を追加しないことによってシステムのアーキテクチャをシンプルにし、テストケースを減らして、システム全体で安全性や信頼性を高めるという選択肢もあるのだ。安全機能を追加しない方がユーザーへの利益が大きいケースはあると思っている。

複雑な安全機能はソフトウェア設計者としてもイヤな感じがするが、安全システム設計者としてシステム全体を見なければいけない立場だったら、そのイヤな感じは増大する。

それは、ソフトウェアの世界で凝集度が低く、結合の強いソフトウェアの集まりが起こす、原因が非常に分かりにくい不具合の数々をこれまで見てきたからそう思うのかもしれない。

そのようなシステムで頭を悩ませてこなかった人たちは、独立性の高いハードウェアを組み合わせることで、多少複雑性が高くなっても、付加価値が高まればよいだろうと考えているのかもしれない。

いったん複雑なシステムを作ってしまうと、予防・是正の取り組みを繰り返しただけでは追いつかない場合がある。変更によって新たな不具合を作り込んでしい、負のスパイラルに陥ってしまう可能性があるからだ。複雑な安全機能にさらなるリスクコントロール手段を追加すると、それによって新しい Hazardous Situation が生まれる。

Random Failures, Systematic Failures, Usability に絡む問題がそれぞれ独立して考えられるのなら、そのようなアーキテクチャを選択した方が絶対にいい。この3つの要素が絡み合うシステムを作ってしまったら、後が大変で、ブログで解決方法を解説するレベルではなくなる。

実際の自動車制御はこんな単純なものではないことはわかっている。だからこそ、独立した機能同士の結合を弱くしておく努力の重要性を感じる。そこを崩してしまうと際限がなくなる。付加的安全機能は際限をなくしてしまうトリガーになるような気がするのである。

どんなに複雑でも、どうせソフトウェアで制御するなら一つの高性能なECUにやらせてしまえという考え方が出てくると、1980年代に医療機器の世界で起こった Therac-25 の事故が、自動車ドメインでも起きるかもしれない。

2012-10-20

ISO 26262との向き合い方 (16) 安全を売りにすることの意味

2012年10月17日 日産自動車が回避支援を行う「緊急操舵回避支援システム」を開発したことを発表した。(日産のニュースリリース『日産自動車、「緊急操舵回避支援システム」を開発』)

緊急操舵回避支援システムとは(ニュースリリースから引用)
このシステムは、ブレーキでは衝突を避けることが難しい状況において、障害物に衝突しそうになった際、自動ブレーキだけでなく自動操舵も行うことにより、高度な回避の支援を行うシステムです。低速域での急な飛び出しのような予測できないリスクが発生した場合、また、ドライバーの認知の遅れにより高速で渋滞末尾に追突しそうになった場合などにその効果は発揮されます。
スバルのプリクラッシュセーフティシステムは自動ブレーキをかけるシステムだったが、日産の緊急操舵回避支援システムは、自動ブレーキに加えて自動でハンドルも切って衝突を回避するシステムとなっている。

このニュースを見たとき、自動車業界は「こっちの世界に来たな」と思った。こっちの世界というのは、ソフトウェアエンジニアが製品やシステムとユーザーとの間に立って安全を確保が脅かされる恐怖に立ち向かい、そして不幸にして事故や事件が起こってしまったときの再発防止に取り組む責任を負わなければならない世界のことだ。

自動車メーカーの経営層は「安全を売りにすること」の重みについてまだ実感がないと思う。その重みは事故・事件があっちこっちで大小さまざま起きるような環境になったときに初めて感じることになる。

先進国の自動車メーカーは自動車の本質的な機能や性能、見た目のかっこよさ、価格などではもう他社と差が付けられなくなってきたのだろう。そこで、安全を売りにしようと考えた。スバルがEyeSightで大々的に宣伝を始め、その後各社ともプリクラッシュセーフティシステムを市販車に搭載し、日産がさらに機能を追加した。そうなると、安全機能での競争は止まらなくなり、安全機能の複雑化が加速する。

市販車に搭載済みの自動停止まで行う衝突防止装置(Wikipedia より)
2008 - ボルボ・シティ・セーフティ
2010 - スバル・アイサイト
2011 - フォルクスワーゲン・シティエマージェンシーブレーキ、ボルボ・ヒューマン・セーフティ、メルセデス・ベンツ・PRE-SAFEブレーキ
2012 - マツダ・スマート・シティ・ブレーキ・サポート、BMW・ドライビング・アシスト・プラス、トヨタ(最高級車レクサスのみ衝突回避する)・衝突回避支援型プリクラッシュセーフティシステム
リスクマネジメントがとてつもなく多様化しているクリティカルデバイスの開発の世界にいて感じるのは、安全のためにもっとも効果があるのはシンプルなアーキテクチャだということだ。自動車業界は安全のためと言いながら、最初は安全機能は単純だったのに、その後わざわざ安全機能を複雑化させ、安全を脅かす方向に向かおうとしている。

安全機能の複雑化に伴うリスクと対策については次回以降に書こうと思う。安全機能を複雑にするリスクと共に非常に大きな問題は、安全機能を自動車の付加価値にしたことで、事故・障害が発生したときの責任についての社会の見方が変わるということだ。

  • 運転手がブレーキペダルを踏んでその圧力を油圧で伝達しブレーキパッドをプレートに押しつけることで摩擦によりタイヤを制動する。
  • ハンドルを傾きをタイヤの向きの制御に変換する。

こういったシンプルな構造で自動車の機構が成り立っているときに発生する事故の責任は運転手にあった。このことは社会通念上、誰もが認識していることであり、口を挟むものはいない。ブレーキとアクセルを踏み間違えたり、居眠りしたり、ハンドル操作をミスした責任は運転手にあると考える。

そして、時代は変遷し、パワーステアリングやABSなどの機能が自動車に付加されるようになり、ハイブリッド車や電気自動車が出てきたことで、ブレーキやハンドル操作のメカニズムはすでにシンプルではなくなっている。

だから、正確には「こっちの世界にようこそ」は何年も前に起こっていた。しかし、これまでは自動車の安全機能はキチンと動いて当たり前だったし、自動車メーカーやサプライヤも安全・安心の堅い信用を守り通してきた。だから、自動車の内部システムが複雑になっていても自動車事故が起こったときに事故の責任は運転手にあると未だにみんなが認識しているのだ。

当たり前品質はシステムが正常に動いているときは、誰もその機能や性能について関心を持たないし、ありがたみも感じない。だから当たり前品質を提供する側がシステムを正常に動かしている限り、事故の責任は運転手にあるという社会的なコンセンサスは変わらない。

しかし、プリクラッシュセーフティシステムや緊急操舵回避支援システムは、どの自動車メーカーも実現している当たり前品質ではなく、自分達しか実現できていないユーザーに対する付加価値だ。ユーザーは他社にはない差別化された安全機能を目当てにその車を買うのだ。

安全機能を売りにして差別化を図った自動車メーカーは禁断の果実に手を出したようなものだと思う。安全を売りにした以上、そこに問題があることは許されない。そこに問題があった場合の社会に与えるマイナスの印象は非常に大きい。リスクの大きい賭けとなる。医療機器の場合、装置が与える効果効能と安全・信頼を確保するためのリスクは表裏一体であり、エンジニアもそういうものだと思ってこの世界に入ってくる。社会への貢献度も高いがその裏に大きな責任やリスクがあることも分かってこの仕事を選んでいる。

自動車業界のエンジニアはどれくらいそういう感覚を持っているのだろうかと思う。ブレーキを作っているサプライヤのエンジニアはその責任の重さを認識しているだろう。でも、複雑な安全機能を複数のサプライヤで分担したり、異なる専門の技術者が協力して安全機能を開発したときに、安全に関する責任やリスクについてメンバー全員が同じような感覚を持てるかが疑問だ。システムが複雑化すると「それは俺たちの担当じゃない」という場面が増えてくる。その台詞に言葉では言い表せない恐怖を感じるのは品質保証担当やプロジェクトリーダーであり、経営者ではない。

さて、安全に関する機能がシステムに隠れていて正常に動作している間は、社会は事故の責任は運転手のミスと認識する。しかし、安全機能をシステムの付加価値にして表に出し、それを顕在的な価値(=カタログスペック)として他社との差別化に使って、安全機能の不具合が原因で事故が起こった場合、責任は自動車メーカーにあると誰もが考える。

自動車メーカーが安全機能を売りにすることの最大の経営上のリスクは、実は複雑な安全機能システムに内在するソフトウェアのバグではない。発生した事故の原因が安全機能の不具合なのか運転手の運転ミスなのかはっきりと切り分けができないことが自動車メーカー自らが新たに抱えることになった最大のリスクなのである。

アメリカ人なら発生した事故が運転手のミスではなく、プリクラッシュセーフティシステムや緊急操舵回避支援システムが正常に動かなかったからだと訴訟を起こすことは必ずあると思う。一回でもユーザー側が勝訴すれば後に続く人は増えるだろうし、そんなことが続けばよかれと思って他社と差別化を図るために付けた安全機能は一転してメーカーのマイナスイメージになりかねない。

それを見越して自動車メーカーは飛行機のフライトレコーダーのような事故が起こったときにどのような制御がなされていたのかを記録するデバイスを搭載しているだろう。ようするに表では新しい安全機能によりドライバーの安心に貢献していますという顔をしておきながら、裏では事故が起こったときに「安全機能には問題がありません。」「悪いのは運転手です。」ということを証明するための証拠を集めながら自動車は走っているのだ。(事故の再発防止のためにはログの収集は必要であり、この表現はこういう見方もあるよという意味。)

しかし、事故が起こったときに自動車メーカーが「安全機能には瑕疵がない」と主張するのは事故の当事者以外に対しても極めて印象が悪い。なぜなら、自動車を売るときだけはプラスのことだけ宣伝しておいて、事故が起こったとたんに守りに入る姿が不誠実に映るからだ。

安全機能が当たり前品質として、また、潜在的価値としてシステムの内部に隠蔽されていたときは、事故の責任は運転手にあると社会は認識しているが、自動車メーカーが安全機能を表に出して顕在的な価値として大々的に宣伝し始めると、事故が起きたときの責任は自動車メーカーにもあるという認識が社会全体に生まれる。このことを自動車メーカーの経営層は実感していないだろうと思っている。自動車メーカーの経営者は技術者に「そんなことがないようにしろ」というだけだ。リスクマネジメントによってあらゆる問題に対して対策を取り、それらのリスクコントロール手段が確実に動くようにすることがいかに難しいか実感があるわけもない。

こういうときメーカーは問題が起こったときの防衛線を張ろうとする。それが、スバルのEyeSightのコマーシャルに現れている。スバルのEysSight のCMの一番最後にチラッと白地の画面に注意書きのようなものが表示されているのにみんな気がついているだろうか。「こっちの世界」にいる者として、ここに安全機能が期待通りに動かないときの注意が書かれていることは分かっていたが消えるのが早くて読み取れなかった。

そこで、You Tube でお目当てのCMを探して問題の部分を静止して文言を読み取ってみた。書いてあることはこうだ。
EysSight(ver.2)はお客様の安全運転を前提としたシステムです。道路・天候等の条件によっては衝突を回避できず、減速による被害軽減になる場合があります。
詳しくは最寄りのSUBARU販売店にお問い合わせください。
「衝突を回避できず、減速による被害軽減になる場合がある」は言い換えると「衝突回避は完全ではなく、減速するだけとなって怪我をすることもあります」であり、また、運転手が安全運転をしていなかったら衝突回避できないかもしれませんと言っている。

EyeSight(アイサイト)クイックユーザーガイドにはもっと直接的な注意文が書かれている。
EyeSight(アイサイト)は自動運転/自動衝突回避システムではありません。EyeSight(アイサイト)を過信せず、交通環境に注意して安全にご使用ください。ご使用の前には必ず取扱説明書をお読みください。
CMの注意文が表示されている時間はストップウォッチではかったら0.8秒だった。0.8秒では注意文を全部読めないから、この注意文表示は後で何かあったときに「一般の方にもCMで注意喚起しています。」という既成事実を作っておきたかったのだろう。ちなみに、フォルクスワーゲンの「シティエマージェンシーブレーキ」のCMでの注意文も同様に読み取れないくらい早く消える。

左の図を見て欲しい。システムに問題が起こったとき(自動車の場合は事故が発生したとき)青い部分がメーカーの責任で赤い部分がユーザーの責任である。使用者から見たときの通常使用の範囲とメーカーから見たときの誤使用の範囲が重なっているのが分かるだろう。

ここがグレーゾーンであり、メーカーとユーザーの認識のギャップとなる。メーカーとユーザーの間の安全に関する認識のギャップはメーカーがユーザーにどのような事前注意を求めているかで推し量ることができる。メーカーはユーザーが勘違いしそうなことについては、ユーザビリティ分析を行いできるだけ設計上の対策で回避しようとするが、設計上の対策でも防ぎきれない場合は注意喚起によりリスクを軽減しようとする。

しかし、ユーザーはメーカーサイドが表示する注意喚起を気にしてくれるとは限らない。この図は機器のユーザビリティに関するリスクマネジメントの判断基準を説明するときのものだが、原因がはっきり分からない場合の事故でも同じで、いったん事故が起こればユーザーはメーカーの責任を拡大解釈し、メーカーサイドの瑕疵の可能性を徹底的に追求する。

自動車は免許証を持った人しか扱えないが、一般的な運転の技術しか学んでいないし、機器を扱うスペシャリストではないから、基本機能以外の部分で起きた事故の責任はよりメーカーに強く求めるだろう。

また、リスクに対する意識は時間が経つにつれてメーカー責任の範囲が広くなる方向に動く。初めて導入された画期的な安全機能は仮に問題が起こっても「新しい技術だから」ということでユーザーサイドも割り引いて考えてくれるとこもあるかもしれないが、正常に動いて当たり前という状況、時代になった場合、責任はメーカー側に強く求められるようになる。リスクに対する意識は時代と共にメーカーにとっては厳しい方向に動くのである。

では、リスクマネジメントはどこまでやればよいのあろうか。それは、左図にあるように、意図した使用目的に基づき、世間の常識、他社の状況を参考にし、そのときに考えられる使用条件(シナリオ)をベースにリスク分析をするのだが、ここまで述べてきたように自動車の安全機能を表に出したのは「付加価値」であり「商品価値」にしたことになるので、リスクマネジメントの要求レベルはさらに高くなっている。

際限のないリスクマネジメントが辛くなり、時間切れになると、警告や注意文といった表記上の対策で逃げようと考えるようになる。

上記の注意文がその典型的な例だが、実際に事故が起きて裁判になったとき、事前に注意喚起をしたことが有利に働くとは言い切れない。なぜなら、社会通念上、自動車の運転者が取扱説明書をじっくり読むとは誰も思っていないからだ。ユーザーが注意喚起を認知する努力をどれだけしたのか、ユーザーが実質的にどれだけ認知していたのかは裁判でも争点になる。刑事責任を逃れたいのならば、契約書を交わすのが確実だ。これは笑い話ではなく、自動車の付加的安全機能を使う際に契約書にサインする時代は必ず来ると思っている。

ちなみに、契約書にサインさせても民事裁判では負ける可能性はある。日本では生命保険の契約内容が保険加入者に伝わっておらず、保険金が払われていない実態が問題視され、きちんと説明するように生命保険会社に行政指導が行われた。

たとえ契約書にサインしても、ユーザーが書かれている内容を理解しないでサインさせた場合、メーカーの社会的責任は免れない。

だから、注意文をCMで0.8秒間だけ表示する行為はPL(製造物責任)の対策にはなっていないし、リスクコントロール手段にもなっていない。逆に不誠実さをさらけ出しているだけのように感じる。

安全を売りにするということは、こういったことをすべてひっくるめてリスクマネジメントできているという自信があるということだと思う。

エンジニアが絶対やってはいけないのは、設計上の対策でできることがあるのに、権威を笠に着た言い訳やユーザーへの注意文を取扱説明書に書いて、安全に対する責任から逃れようとすることだ。(権威に傘を着るというのは ISO 26262 への適合証明をもって安全が確保できていると説明すること)

日産の緊急操舵回避支援システムを FTA で分析したらどうなるか、アーキテクチャ的にどんなリスクが想定できるのかまで書こうと思ったのだが、安全機能に対する考え方の解説だけで終わってしまった。複雑な安全機能をいかにユーザーに安全に使ってもらうかについては、今後我々が乗り越えなければならないハードルであることは分かっているので、次回以降に書こうと思う。

知られたくない部分を隠しながら、安全機能のプラスの面だけを強調しておいて、実際に事故が起きると言い分けを始めるのでは、3.11 の教訓がまったく活かされていない。安全は静かに硬く実現するものであり、派手派手しく前面に押し出すものではないと個人的には思っている。

P.S.

自分は『機能安全』という言葉がどうしても好きになれない。機能と安全はくっつけるべきものではないと思う。緊急操舵回避支援システムは間違いなく安全のための機能だが、安全のために本当に必要かどうかは緊急操舵回避支援システムの効果効能が緊急操舵回避支援システムに不具合が起きるリスクを上回かどうかの判断で決まる。安全機能のシステムが複雑になるとソフトウェアによるシステマティック故障が起こる可能性が上がってくるので、安全機能の御利益がリスクを相当上回らないといけない。付加した安全機能があってもなくてもよい程度のものであると効用よりリスクの方が大きくなる。リスクの重大さを考えて効用の方を切るという判断もあってしかるべきだと思う。リスク効用分析が十分でなく、効用の方ばっかりに目が行くようになると危ない。機能安全という言葉はリスクの存在はあってもしようがないという前提で、効用の方に注目を集めようとする言葉のような気がする。『機能安全』は主役がリスクによって危害を被るユーザーではなく、安全機能を提供する機器製造業者側の視点の言葉になっていないだろうか。


11月14日からパシフィコ横浜で開催されるET2012 のプライベートカンファレンスの 「組込システムの安全性と信頼性 ~ISO26262の認証証明だけで本当に安心できますか?~」のコマで、「市販ソフトウェアの信頼性検証」についてのプレゼンをします。(時間60分)

これは、OTS(Off The Shelf Software:商用で即利用可能な市販ソフトウェア)をクリティカルデバイスで使用する際には、どんな検証を行い、どのように検証記録を残すべきか、どうすれば根拠のある信頼性の説明となるのかについて実例を使って解説するものです。サブタイトルの~ISO26262の認証証明だけで本当に安心できますか?~は、ISO 26262 の適合証明は信頼性の根拠として説得力がなく、対象物の何をどうやって検証したのかを説明できるようにすることが重要であるという想いから付けました。

ET2012 プライベートカンファレンス 「市販ソフトウェアの信頼性検証」

プライベートカンファレンス
IARシステムズ株式会社&イー・フォース株式会社

11月14日(水) 10:00~16:45
会場:会議センター4F[414+415]
10:00~11:45 PIA-1 組込システムの安全性と信頼性 ~ISO26262の認証証明だけで本当に安心できますか?~

2012-10-14

ISO 26262との向き合い方 (15) FTAを描いてみる1

今回は、FTAを描くときの注意点、特にソフトウェアが原因となって障害が発生する場合について考えてみる。

自分は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  (決定論的原因故障/障害)

  • ハードウェアの設計に起因するもの、ソフトウェアのバグやソフトウェアに起因する問題やユーザーオペレーションが原因で発生する障害発生率の予測が難しい故障/障害
  • 出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。
  • 開発のプロセス(工程)、ライフサイクルの中で 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)」が良い解析ができるかどうかを左右すると思う。

2012-10-06

ISO 26262との向き合い方 (14) FTAとFMEAの歴史

ISO 26262の世の中の動きをウォッチしていくこと自体にいささか疲れてきた。正直言って、本当にユーザーのことを考えて安全や安心を実現したいのなら、自動車業界の規格適合に関する浮かれた熱が冷めるのを2~3年待った方がよいと考えるようになってきた。若しくは機能安全に群がる商魂たくましい人たちとは一線を画して、クリティカルデバイス、クリティカルソフトウェアに役立つことは何かに集中していくかだ。

今回は後者を選択して、FTAとFMEAの歴史を調べてみたいと思う。リスク分析のツールとしてFTA,, FMEA, HAZOP などいろいろあるが FTA と FMEA は特に歴史が古い。

FTA や FMEA がそもそも軍事産業から開発されたことは何となく知っていたが、今回、Wikipedia などで調べて改めてその歴史的背景を知ることで、いろいろ思うことがあった。

FTAの歴史

FTAとは、Fault Tree Analysis (フォルトツリー解析)の略で故障・事故の分析手法の一つだ。フォルトツリーというくらいだから、左のような感じで木のように上から下に向かって広がった形になる。

Fault(不良、傷害)が発生する要因を論理的にたどり、望ましくない事象がどのようなメカニズムでまたどのような発生確率で起こるのかを論理的に分析する方法だ。望ましくない事象に対してその要因を探るトップダウンの解析手法で、FMEA(故障モード影響解析)とは逆のアプローチだと言われている。

個人的には、FMEAは既知の問題の再発防止に有効であり、経験を積み重ねていくほど発散しがちであるのに対し、FTAはどうしてもこれだけは発生させたくないという事象に対して、何を押さえなければいけないのか、どんな故障を考慮すべきなのかを分析する集中思考型の手法だと思っている。

さて、FTAの歴史の話を戻そう。FTAは、1961年にアメリカで開発されたミニットマンミサイルの信頼性評価・安全性解析を目的として、その協力先であるベル研究所のH・A・ワトソンのグループが考案し、その後ボーイング(BOEING)社により完成された。

Wikipedia で解説されている FTA の歴史の解説はこんなもんである。ここから歴史的背景を掘り下げていく。1961年と言えば、米ソ冷戦のまっただ中の時代だ。ミニットマンミサイルはアメリカが開発した大陸間弾道ミサイルで、1962年にミニットマン I、1965年に ミニットマン II、1970年にミニットマン IIIが配備された。核弾頭も搭載できる。ミニットマン IIIの全長は18.2m, 重量は35トン、価格は700万ドル、日本円なら一機およそ5億6千万円だ。

ミニットマンミサイルが開発される前は液体燃料ロケットであるアトラス及びタイタンが配備されていた。アトラスやタイタンは酸化剤に液体酸素が用いられており、発射直前に酸化剤注入の必要があリ著しく即応性を欠き、また電波による初期誘導を行なう方式であったため、全弾発射に長時間を要した。

さらに、アメリカ空軍はタイタンⅡミサイルの毒性の非常に強い推進剤が金属部品を腐食して燃料漏れ事故がたびたび発生し、死傷者が出て、そして維持管理費が高いことに悩んでいた。

そこに海軍がロッキード社の潜行中に潜水艦から発射できる固体燃料式ポラリス核ミサイルを配備したことで、危険な点検作業など運用コストのかかる液体燃料方式でなく、燃料漏れが起きない固体燃料を入れたまま長期保存ができ、整備、点検作業が不要でコストも安い、ミニットマン核ミサイルをボーイング社に開発させ、地下サイロのタイタンミサイルをすべてミニットマンミサイルに交換した。

これにより、冷戦時代の米国は当時、ソ連に対して核戦略で優勢に立った。なぜなら、ソ連のミサイルはすべて液体燃料方式で大型だったため、地下サイロの建設コストが膨大で、さらに整備、点検作業の運用コストに悩んでいたからだ。その当時、ソ連は大型固体燃料ロケットを製造する技術が未熟で、さらに固体燃料ロケットには、その振動に耐える集積回路の半導体電子回路で構成された誘導コンピユータの技術がなかった。

左が、固体燃料ロケットが発生する強烈な振動や加速度で故障しない頑丈な集積回路のミニットマンの誘導コンピュータである。

軍事機密のせいかミニットマンミサイルのFTAの事例はインターネットでは見つからなかった。ただ、容易に想像できるのは、一機700万ドルもする新規開発の大陸間弾道ミサイルを安定的に発射し目的を達成するためには、強烈な振動にも耐えうる部品と制御システムが必要だったのだろう。

失敗が許されない開発であり、信頼性評価・安全性解析の方法としてベル研究所のH・A・ワトソンのグループがFTAを考案し、ミサイルの開発を請け負ったボーイング社がFTAを完成させた。

FTAはトップ事象と基本事象の因果関係をブール論理を用いてつなげていく表現方法であり、図自体はすぐに書き始めることはできる。だから、1961年から半世紀たった現在では、誰でも簡単に使うことができる信頼性評価・安全性解析のツールになった。こんな歴史的背景を知ることもなくあちこちの安全解析に使われている。

当時、ミニットマンミサイルの開発はアメリカの国家プロジェクトであっただろう。だから、米軍はトップレベルの頭脳集団であったベル研究所に信頼性評価・安全性解析の手法の開発を依頼した。

このような背景を知って二つのことを思う。一つは今となっては故障や事故の分析手法の定番となったFTAは当時、何千万ドルといった国家規模のプロジェクトで精鋭の頭脳集団が考えた新しい方法論だったということ。そして、もう一つは、FTAはそもそも、使えば大量の人を殺すことができる軍事兵器の開発のために考えられ、今では逆に人の安全のために広く使われているという点だ。

自分はFTAを学びたいと思う人に FTA という手法が大事だとは思って欲しくない。

FTAの向こう側には必ず達成したい目的があるはずだ。当時FTAには FTAが必要な理由、FTAを必要とした背景があった。

米軍にはそれまで液体燃料で即応性が乏しく欠点の多かったミサイルを固体燃料のロケットにしたいという強い目的意識があり、そのためには固体燃料が発生する強力な振動や加速度で故障しないシステムを作る必要があった。何も対策しなければ、振動や加速度であちこちの部品が壊れたり期待どうりに動かなくなったりする。これらの故障を防いで目的であるミサイルの発射を成功させるためにはどうすればよいか、何を対策すればよいのか考えなければならない。

そのためには、故障の原因となる事象が発生するメカニズムを分析する必要があるのだが、複数の事象が従属的に起こったり、同時に発生しないと故障には至らないケースなどいろいろなケースが考えられる。また、部品の故障や事象の発生の確率もそれぞれ異なる。

これらを整理して図に表したのが FTA だ。そして、ミニットマンミサイルの場合、FTAは過酷な条件下でも故障なく安定してミサイルを発射する目的のために考えだされた。

その目的があったからこそ、FTAの分析には心血が注がれ、その結果、安定性の高いミサイルが完成したのだろう。軍事目的という点が引っかかるが、現実にはその方法論が後に社会に貢献したのである。(軍事目的で開発された手法や方法論が現代の科学技術の発展に貢献したことはよくある)

FTA は目的があるからこそ使う意味があるのであって、使い方を知っているだけでは何も寄与しない。FTAを使う者が、FTAが作られた歴史的背景を知って欲しいと考えるのはFTAを使うには何かしら発生させたくない故障や障害、リスクがあるかだということを認識して欲しいからである。

発生させたくない故障、障害、リスクに対して、分析者の思い入れがないと障害事象を抽出することさえできないだろう。そういう人が FTA を学んでも一つも組織や社会に貢献しない。

すでに完成しているシステムに新たな機能を追加するとき、それまでそのシステムに構築されてきた故障対策、安全対策をぶち壊してしまう危険性があるし、明示的に安全対策を壊さなくとも、まれな条件で発生するような安全対策のほころびを埋め込んでしまう可能性がある。

そうならないように安全を確保したい、当たり前にできていることをそのまま保持したいと思う気持ちがなければ、有効な FTA はできない。

一機700万ドルもする機器のプロジェクトならみんな本気にもなるよなと思う。でも、我々だって「FTA の向こう側にはシステムを使っているエンドユーザーが誰かしらいるんでしょ」と言いたい。その人達のために自分は何ができるかという気持ちで FTA に取り組めばよい分析ができると思う。たましいの入っていない安全分析ほど役に立たないものはない。

FTAをやりながら、先人の知恵をありがたく使わせてもらっているという感謝の気持ちも必要だろう。

そういう気持ちがないと冷たい無機質なFTA 図ができあがる。1980年代に事故を起こした放射線治療器 Therac-25 の開発では FTA 図が書かれており、「コンピュータが誤ったエネルギーを選択する」が発生する確率は 10のマイナス11乗で、「コンピュータが誤ったモードを選択する」が発生する確率は4×10のマイナス9乗となっていた。

当時、ソフトウェアによるシステマティック故障という概念がなかったため、コンピュータは複雑なことができるリレーのようなものだと認識されていたのだろう。Therac-25 ではこのFTAの結果をもとに、ソフトウェアの不具合要因は横に置かれ、コンピュータの故障確率は非常に低いと判断され、コストダウンの目的でハードウェアの安全装置を外したことで潜在的なソフトウェアの不具合が表面化して事故を起こしてしまった。(『ソフトウェアの特性を考慮せず事故が起きた事例』を参照のこと)

ミニットマンミサイルを開発していた技術者は当時、強烈な振動や加速度にも耐えてミサイルの発射実験が成功したとき、達成感を得て純粋にうれしかっただろうと想像する。(平和利用のロケットだったらなおよかっただろうが)

ツールを使うときは常にツールを使う目的を思い浮かべて置かなければダメだ。目指すべきゴールが何かを考えていないと、都合のよい結果を導くだけの道具になってしまう。

FTA で図を書く者は今一度、誰のために、何のために分析をするのかを考えて欲しい。そこに気持ちが集中していれば、いろいろな事象が思いつき、漏れの少ない FTA ができるはずである。

FMEAの歴史

FMEA(Failure Mode and Effect Analysis)とは、故障モード影響解析のことで、設計の不完全や潜在的な欠点を見出すために構成要素の故障モードとその上位アイテムへの影響を解析する技法である。

FMEAは Wikipedia によい歴史解説が載っているのでそれを引用しよう。
FMEAは1940年代にアメリカ陸軍が正式に導入した。その後、航空宇宙開発の分野では、製造量も少なく費用のかかるロケット技術において、間違いをなくすために使用した。例えばアポロ計画でも使用している。アポロ計画でのHACCPプロセスに適用され、その後、HACCPは食品業界全体に普及した[6]。人間を月に送り、安全に地球に帰還させる方法を開発する際、つまり1960年代にはFMEAを導入する重要な原動力があったわけである。1970年代になると、フォード が、ピントの問題後、安全と規制遵守のためにFMEAを自動車業界に導入した。自動車業界では、FMEAを製造プロセスにも適用し(PFMEA または工程FMEA)、故障を引き起こす恐れのある工程を量産開始前に検討し始めた。
FMEAは、1950年ごろのジェット機開発(アメリカ合衆国:グラマン社)の際、操縦システムの信頼性評価のために、最初に使用されたともいわれている。日本では1970年ごろから一般に使われるようになった。 
FMEAは、最初は軍が発展させた手法である。現在では半導体、食品、 合成樹脂、ソフトウェア、医療健康などを含む各種産業で広く用いている。FMEAはまた、米国自動車工業会(AIAG、自動車産業行動委員会と訳す)の先行製品品質計画(APQP)のプロセスに取り入れ、製品開発及び製造プロセス設計の際にリスクを低減することに役立てている。APQPでは、製品と製造工程に対する影響(故障)を拾い上げるために、潜在的な原因を考えなければならないことになっている。リスクの度合い(RPNと呼ばれる指標)に基づいて対策しなければならないことを決め、対策した後に再度リスクの度合いを評価する。 
自動車業界では,ISO 9000の技術仕様を定めたISO TS 16949でFTA, FMEAを参照しており幅広く取り組んでいる。 トヨタ自動車ではFMEAを「故障モードに基づく設計レビュー(DRBFM:Design Review based on Failure Mode)」をGD3(GDキューブ:良い設計、良いディスカッション、良い観察)の一部として取り入れている。現在、このDRBFMはアメリカ品質協会が対応しており、詳細な手引きを提供している。
FMEAは1949年11月9日に米陸軍により "Procedure for performing a failure mode effect and criticality analysis, November 9, 1949, United States Military Procedure, MIL-P-1629" という名前の軍事手順として発行された。この手順は、システムや機器の障害の影響を決定するために、信頼性評価技術として使用されていた。 障害はミッション成功と人員/機器の安全への影響に応じてクラス分類された。

結局、FMEAも軍事的な目的から開発されたのだが、その後アポロ計画でも使われ、人類が初めて月面に降り立った業績に貢献したと言われている。と言っても、アポロ計画ではNASAが、FMEAの実施を開発受注業者に義務付けたことから普及したらしく、あらゆる経験を集めて起こるであろう故障を予測し、帰納的な事前対策をサプライヤに課すことで効果を上げていたのだ。

その後、自動車業界では1972年にフォードモータースのピントの事故の再発防止のためにFMEAを導入した。ピントの事故とは次のようなことであった。

事例概要:米国フォード社の「ピント」が高速道路で突然エンストして停車していたところ、約50km/hの速度で走ってきた後続車に追突されて炎上し、運転者が死亡、同乗者が重度の火傷を負う事故が発生した。ガソリンタンクの配置の悪さが直接の原因であった。他社との競争のための開発期間短縮と安全軽視のポリシーが起因と考えられる。この事故は、1億ドルを越える陪審の評決がでたことで有名である(ただし控訴審で減額)。

事象:米国フォード社の「ピント」が高速道路で突然エンストして停車していたところ、約50km/hの速度で走ってきた後続車に追突されて炎上し、運転者が死亡、同乗者が重度の火傷を負う事故が発生した。

自動車業界でもこのような事故の再発を防止したいためにFMEAを導入した。

また、FMEAはHACCPにも使われた。HACCPとは食品の中に潜む危害(生物的、化学的あるいは物理的)要因(ハザード)を科学的に分析し、それが除去(あるいは安全な範囲まで低減)できる工程を常時管理し記録する方法である。例えば、ハンバーグを焼くときに、挽肉中の感染症や食中毒原因細菌などが、ハンバーグの中心の温度が何度にどれだけの時間経過すれば安全なレベルになるかを科学的に分析して、分析の結果決定した管理方法を実施して、実施した結果を記録する。これによりかつて行われていた抜き取り検査のみの管理では為し得なかった全品の安全性が高いレベルで効率よく確保され、このことを記録から証明することができる。

マクドナルドは1980年代に病原性大腸菌腸管出血性大腸菌O157の問題を解決するために自主的にHACCPに取り組んだ。合衆国ではまたHACCPは従業員数名の小規模の企業でも義務化され実践されており、効果を上げている。

食品業界では食の安全のために FMEA が使われているのである。

今回の記事で言いたかったことは、FTA や FEMA を目的意識をしっかり持って使いましょうということである。そのためには、FTA や FMEA が開発された歴史を知ることが重要である。

ISO 26262 の規格適合についても同じことが言える。誰のために、何のために規格に適合するのかを見据えていない者は機器やシステムの安全性や信頼性を向上させることはできず、その結果エンドユーザーにも社会にもプラスの貢献にはならない。