適合支援をしますといったニュースリリースをよく見かける。そのような喧噪をよそに、今回も複雑な安全機能に対してエンジニアはどう対処してけばよいのかについて書こうと思う。システム」について掘り下げて考えてみる。(公開情報だけで考えているので想像している部分と現実とは違っているかもしれません。ブログでは特定の会社のシステムを評価したいのではなく、安全機能の複雑性について理解を深めたいだけなので、その点、誤解なきようよろしくお願いします。システム」を開発』は、よく読んでみると、まだ市販の乗用車への搭載の予定は書かれていなかった。実用実験の成果を発表した段階ということのようだ。システムは1台のカメラ、3つのレーダー、5つのレーザースキャナを入力源として使っている。コンセプト」と「緊急操舵支援システム」が作動する一般的なシナリオは次のようなものが想定されている。(YouTubeによる動画はこちら。対象物を検知・識別する。ドライバーに警告を発する。衝突に備えてシートベルトをきつく締める。コンマ数秒後、システムが衝突回避の限界に近づきドライバーが自力で衝突を回避できないと判断すると緊急ブレーキを作動しはじめ、衝突回避動作を支援する。対象物を検知・識別する。ドライバーに警告を発する。物理的に回避可能な限界に近づきドライバーの操作は不十分と判断する。ECUは緊急ブレーキと緊急ステアリングのどちらで対応するかを一瞬で決定する。ステアリングが最適な措置の場合ハンドルを切ることが可能な方向をドライバーにモニタで知らせる。その直後に必要な操作(緊急ブレーキの作動か、緊急操舵か、それらの両方)を正確に実行する。資料には「考えられるすべてのシナリオでこのシステムを検証し、高い効果を確認した。」とあったが、シナリオは無限に存在するので検証が終わったと判断するのはなかなか難しいと思う。記事をもとに緊急操舵支援システムの入力部と衝突リスクを分析判定するECUの関係を図に書いてみた。分析判定のECUはもしかしたら一個ではないかもしれないが、ここはシンプルに一つだと仮定した。ちなみに、レーダーとは電磁波を照射してその反射波を受信するデバイスで、照射された電磁波は広範囲に広る。レーザーは直進性が高く探りたい方向に向けて首を振らなければいけない。レーザーの方はスキャニングする必要がある。レーダーよりはデバイスの内部構造が複雑になると想像する。これらの入力装置だけを考えてもこの安全機能の複雑性がうかがえる。1つのカメラ、3つのレーダー、5つのレーザースキャナはそれぞれ監視するエリアがオーバーラップしてはいるものの、各自持ち場、見張る方向、センシングの方法が異なるので、どれかが故障すると緊急操舵支援システムは期待通りの働きができない。描くと左記のようになる。1000分の1に近づく。現実はそんなに故障率は高くないだろう。1000万分の1くらいかもしれない。頻度の低い使用なら問題ないレベルだろうが、例えば自動車の場合は販売量が非常に多い。10万台売れて100回使えば、トータルで1000万回になる。センサの故障は無視できるレベルではないことが分かる。故障状態を検出する手段があれば、どれかのセンサが故障した時点で故障状態を表示して修理に出して欲しいとドライバーに訴えることになる。修理をしてもらえば確率は元に戻るから、この足し算は必ずしも現実的とは言えない。部品の故障率は自動車のライフサイクルに対して一定であるとも限らない。自動車が生産されて廃棄されるまでの期間が仮に10年だったとして最後の1年がその前の9年と同じ確率かどうかは分からない。部品の故障率がバスタブ曲線状に変わる場合、製造後10年経過したときの「緊急操舵支援システムのセンサ入力が利用できない」確率は上記の確率よりも高くなっているかもしれないのだ。FTAにおける事象発生の確率が一人歩きしないように注意しなければいけない。おける確率は目安というか、分析者がどれくらいの故障率を考えているかの程度の意思表示のようなものだ。確率はトップ事象の発生に対して影響が小さくなってくる。おおざっぱなことを示すことが多いような気がする。図で分析者やレビューワーが認識すべきなのは、9つのセンサがトップ事象に与える影響が同等であるということだ。別な言い方をするとどのセンサが故障しても緊急支援システムの正常動作の障害になるということである。(構成部品の一部が故障しても正常に処理を続行するシステム)の構成を考えることはできる。ようするに部品の故障を見越して同じ役割分担のセンサを複数設置するという考え方だ。取るという安全設計の方法は故障期間がわずかでもあるとまずいようなシステムで使われている。このケースでは例えば、前方レーダーが故障したときのことを考えて、もう一つ前方レーダーを設置する。宇宙で簡単に修理ができないときは、そういう選択肢は大いにありうるだろう。採用されないと考えられる。なると重要なのは各センサが故障しているかどうかを正確に判定できるかどうかだ。衝突リスク分析判定ECUに入力される情報だけでセンサの故障が判定できれば一番よいが、センサからの入力だけでは確実に判定できない場合、故障検出のためのハードウェアを追加しなければいけない。図にセンサの故障検出デバイスの故障事象を追加して、トップ事象を「緊急操舵支援システムを故障状態で使ってしまう」にしてみた。センサが故障していても、ドライバーがそれに気がついていればリスクを減らせる。センサの故障検出デバイスが故障していたら、センサの故障を知らせることはできない。それなら、センサの故障検出デバイスの故障を検出するデバイスを追加するかと考える。やって、リスクコントロール手段は追加すればするほど、リスクが具現化する確率を減らすことができる。(AND接続が可能となるため、確率はどんどん小さくなっていく。)しかし、リスクコントロール手段を追加するたびにコストは上がるし、システムが複雑化する。生まれるかもしれない。設計者が恐れるのは前者よりも後者の方だ。アーキテクチャが複雑になるとシステムが完全に動作するかどうかの検証作業も増える。故障検出機能の検証のためには故障状態を再現しなければいけない。完成品ではなかなか再現できないから、劣化の加速試験やシミュレーションが必要になる。Validation(妥当性確認)しないといけない。1960年代の分析とそれほど変わりはないと思っている。故障解析はなんだかんだ言っても有限の場合分けにしかならない。複雑でもいろいろなケースを想定して積み上げていけば、トップ事象を起こさない確率を高めることはできる。絡んでくると問題はそんなに簡単ではなくなる。機能の独立性が脅かされるということ緊急操舵回避システムの制御モデルを描くとこんな感じかではないかと思う。ブレーキ制御やステアリング制御はこんなに単純ではないと思うが、まずはこの単純なモデルで考えて見たい。ブザー」といった出力系のデバイスも制御しなければいけない。それぞれの出力デバイスの故障も入力系と同じだが、表示装置となるモニタはもしかするとTVやカーナビと共通で使用するかもしれないので複雑性はさらに増加する。緊急操舵回避システムでは、緊急時のドライバーがどちらにステアリングを切ればよいかを指示する。その指示をドライバーが実行できないとシステムが判断したときに初めてシステムが自動でステアリングを操作する。表示装置で方向を指示しなければいけない。カーナビ画面に小さく赤い矢印を出したのでは気づかれないかもしれない。画面を全部消してでかでかと矢印を表示しないといけないだろう。滅多に表示されるものではないから、それが何を意味するのか瞬時に判断できるようでなければいけない。ドライバーが20代でも30代でも40代でも50代でも60代でも70代でも判断できなければいけない。相手が人間になると、統計的な手法の信頼性は低下する。どんなユーザーシナリオを想定したのかを記録しておく必要がある。使われるシナリオ、最大負荷となるシナリオを分析段階で記録しておき、それをもとに作ったシステムで事故が起こったら、事故のシナリオを追加して再分析する。人間の行動には一貫性はないから、設計時に想定できないような振る舞いをされることは現実にある。起因のリスク対策には有効となる。対策が未熟であることはよくある。緊急操舵回避システムとカーナビとTVで表示装置を共有したのなら、緊急操舵回避システムが他に対して優先順位が高くなければいけないのだが、期待通りに動いていることは誰が検証するのか。カーナビ屋さんが「オレには知ったこっちゃない」と考えていると、思わぬコミュニケーションギャップにより緊急時に画面が切り替わるかどうかのテストが漏れる可能性がある。リスクレベルが高いシステムとリスクレベルが低いシステムでデバイスを共有する場合は、そこにある意識の違いがミスを生む可能性がある。それはそれとして、緊急操舵回避システムで最も大きな問題は機能の独立性が崩れることだと考えている。左の図を見てもらいたい。自動車はその基本機能である、ステアリング、ブレーキ、エンジン(加速)の機能は完全に独立していた。それぞれの機能は他の機能を意識する必要がなく、各機能の信頼性を高めることに集中すればよかった。高凝集・疎結合が実現できていると、開発チーム側の役割分担もしやすい。この図で分かるように機能にトリガーをかけるのはすべてドライバーである。それぞれの機能が正常に動作していれば、ステアリングのミス、ブレーキの遅れ、アクセルとブレーキの踏み間違いはすべてドライバーの責任になる。ECUとソフトウェアが絡むようになって、ブレーキとアクセルが同時に踏まれたときは、ブレーキを優先させるという判定をECU内部で行うようになった。このことは、ブレーキ制御とアクセス制御のECUに間に結合が生まれたことになるが、この程度であれば非常に小さな結合で留まっていると言えるだろう。それがプリクラッシュセーフティのように自動でブレーキを制御することになるとシステムの中に大きな結合ができてしまう。衝突回避のための自動ブレーキなら入力はもっと少なくてもよいかもしれないが、それでも衝突リスクを分析・判定するシステムの複雑性は小さくない。懸念事項は運転手のブレーキ操作、ステアリング操作と衝突リスク分析判定ECUの判断が異なった場合はどうするかだ。衝突回避のブレーキシステムの場合は、ドライバーがステアリング操作をした場合、緊急ブレーキは動作させない仕様だったと思う。この場合は、上記の図でステアリング制御ECUから衝突リスク分析判定ECUに向かう矢印が一本増える。それによって、ステアリング制御と衝突リスク分析判定機能は結合したことになる。緊急操舵支援となるとこのように結合度はさらなに強くなる。ドライバーのハンドル操作やブレーキペダル、アクセルペダルの操作と衝突リスク分析判定ECUの判断が相反したときの問題もさることながら、刻々と変わる状況に対して、センサーからの入力やドライバーの操作、ブレーキかステアリングかといった複雑な判定が必要になる。その判断は時間毎に変えなければいけないのである。部品故障に関しても、緊急事態でないときに故障が分かればよいが、仮に衝突回避の直前または回避中にセンサ類に異常が検出されてしまった場合、どのような対応をしなければいけないだろうか。故障検出が割り込み処理で入ってくるのか、ポーリングなのかによっても状況は変わってくる。衝突リスク分析判定ECUが自分で故障検出デバイスをポーリングするようになっていれば、衝突回避動作中はポーリングをやめればテストケースは減る。(衝突回避動作に入ったらセンサの情報は使わないという設計にした場合)しかし、割り込み処理だったら、衝突回避中だろうがなんだろうが割り込まれてきて、故障認識時の処理が意図せず動いてしまうかもしれない。Coupling)が崩れてくる。なってしまったソフトウェアを完璧にテストしようと思ったら、すべてのタイミングで期待通りの動作するかどうか検証しなければならず、有限の場合分けができなければ永遠にテストは終わらない。この記事の前半で、静的な構造に関する問題だけならば有限事象なので検証は時間がかかっても収束するといったのはこのことだ。静的な構造の要素だけでなく、時間によって状況が変わる事象を考えなければいけないとなると、シナリオはすぐに爆発し、検証作業が時間切れになる可能性が高まる。後に「想定外を想定する」といったキーワードをよく聞いたが、時間によって状況が変化してしまう場合、想定外はあるという前提でシステムを設計しないと事故は起こってしまう。「想定外を想定する」のではなく、「想定外が起こる前提で最も効果的な安全対策を考えよう」が正しいアプローチだと思う。システマティック故障これまでの話の中で、ソフトウェアの中の問題(=バグ)は考慮していなかった。9つのセンサの入力をリアルタイムに解析するとなると、解析の中には画像解析も含まれる訳だから、ソフトウェアの複雑化は避けらず、バグがまったくない状態にするのは相当難しい。ソフトウェアの内部構造を高凝集・疎結合にする努力はしたとしても、メモリリークなどがあるとその影響は他に伝搬してしまうし、仕様変更や不具合対策でソフトウェアを変更するとそれによって新たなバグを生む可能性もある。いってツールや開発プロセス、各デバイスの高信頼性化だけに着目するのは木を見て森を見ずであると感じる。上位層、要求仕様や安全やリスク分析の中で考えるべき問題、抽象化できない具体的なリスクやハザードに対するリスクコントロールについて考えることが遙かに重要である。抽象論ではなく、具体的なリスクを前にして、そこに対処することがシステムやユーザーの安全への寄与が大きいということを安全設計をするエンジニアは忘れてはいけない。機器製造業者としては複雑な安全機能を追加しないことによってシステムのアーキテクチャをシンプルにし、テストケースを減らして、システム全体で安全性や信頼性を高めるという選択肢もあるのだ。安全機能を追加しない方がユーザーへの利益が大きいケースはあると思っている。複雑な安全機能はソフトウェア設計者としてもイヤな感じがするが、安全システム設計者としてシステム全体を見なければいけない立場だったら、そのイヤな感じは増大する。それは、ソフトウェアの世界で凝集度が低く、結合の強いソフトウェアの集まりが起こす、原因が非常に分かりにくい不具合の数々をこれまで見てきたからそう思うのかもしれない。そのようなシステムで頭を悩ませてこなかった人たちは、独立性の高いハードウェアを組み合わせることで、多少複雑性が高くなっても、付加価値が高まればよいだろうと考えているのかもしれない。複雑なシステムを作ってしまうと、予防・是正の取り組みを繰り返しただけでは追いつかない場合がある。変更によって新たな不具合を作り込んでしい、負のスパイラルに陥ってしまう可能性があるからだ。絡む問題がそれぞれ独立して考えられるのなら、そのようなアーキテクチャを選択した方が絶対にいい。この3つの要素が絡み合うシステムを作ってしまったら、後が大変で、ブログで解決方法を解説するレベルではなくなる。実際の自動車制御はこんな単純なものではないことはわかっている。独立した機能同士の結合を弱くしておく努力の重要性を感じる。そこを崩してしまうと際限がなくなる。付加的安全機能は際限をなくしてしまうトリガーになるような気がするのである。事故が、自動車ドメインでも起きるかもしれない。システム」を開発したことを発表した。システム」を開発』)緊急操舵回避支援システムとは(ニュースリリースから引用)このシステムは、ブレーキでは衝突を避けることが難しい状況において、障害物に衝突しそうになった際、自動ブレーキだけでなく自動操舵も行うことにより、高度な回避の支援を行うシステムです。低速域での急な飛び出しのような予測できないリスクが発生した場合、また、ドライバーの認知の遅れにより高速で渋滞末尾に追突しそうになった場合などにその効果は発揮されます。スバルのプリクラッシュセーフティシステムは自動ブレーキをかけるシステムだったが、日産の緊急操舵回避支援システムは、自動ブレーキに加えて自動でハンドルも切って衝突を回避するシステムとなっている。このニュースを見たとき、自動車業界は「こっちの世界に来たな」と思った。こっちの世界というのは、ソフトウェアエンジニアが製品やシステムとユーザーとの間に立って安全を確保が脅かされる恐怖に立ち向かい、そして不幸にして事故や事件が起こってしまったときの再発防止に取り組む責任を負わなければならない世界のことだ。自動車メーカーの経営層は「安全を売りにすること」の重みについてまだ実感がないと思う。その重みは事故・事件があっちこっちで大小さまざま起きるような環境になったときに初めて感じることになる。先進国の自動車メーカーは自動車の本質的な機能や性能、見た目のかっこよさ、価格などではもう他社と差が付けられなくなってきたのだろう。そこで、安全を売りにしようと考えた。スバルがEyeSightで大々的に宣伝を始め、その後各社ともプリクラッシュセーフティシステムを市販車に搭載し、日産がさらに機能を追加した。なると、安全機能での競争は止まらなくなり、安全機能の複雑化が加速する。マツダ・スマート・シティ・ブレーキ・サポート、BMW・ドライビング・アシスト・プラス、トヨタ(最高級車レクサスのみ衝突回避する)・衝突回避支援型プリクラッシュセーフティシステムリスクマネジメントがとてつもなく多様化しているクリティカルデバイスの開発の世界にいて感じるのは、安全のためにもっとも効果があるのはシンプルなアーキテクチャだということだ。自動車業界は安全のためと言いながら、最初は安全機能は単純だったのに、その後わざわざ安全機能を複雑化させ、安全を脅かす方向に向かおうとしている。安全機能の複雑化に伴うリスクと対策については次回以降に書こうと思う。安全機能を複雑にするリスクと共に非常に大きな問題は、安全機能を自動車の付加価値にしたことで、事故・障害が発生したときの責任についての社会の見方が変わるということだ。運転手がブレーキペダルを踏んでその圧力を油圧で伝達しブレーキパッドをプレートに押しつけることで摩擦によりタイヤを制動する。ハンドルを傾きをタイヤの向きの制御に変換する。いったシンプルな構造で自動車の機構が成り立っているときに発生する事故の責任は運転手にあった。このことは社会通念上、誰もが認識していることであり、口を挟むものはいない。ブレーキとアクセルを踏み間違えたり、居眠りしたり、ハンドル操作をミスした責任は運転手にあると考える。時代は変遷し、パワーステアリングやABSなどの機能が自動車に付加されるようになり、ハイブリッド車や電気自動車が出てきたことで、ブレーキやハンドル操作のメカニズムはすでにシンプルではなくなっている。正確には「こっちの世界にようこそ」は何年も前に起こっていた。これまでは自動車の安全機能はキチンと動いて当たり前だったし、自動車メーカーやサプライヤも安全・安心の堅い信用を守り通してきた。自動車の内部システムが複雑になっていても自動車事故が起こったときに事故の責任は運転手にあると未だにみんなが認識しているのだ。当たり前品質はシステムが正常に動いているときは、誰もその機能や性能について関心を持たないし、ありがたみも感じない。当たり前品質を提供する側がシステムを正常に動かしている限り、事故の責任は運転手にあるという社会的なコンセンサスは変わらない。プリクラッシュセーフティシステムや緊急操舵回避支援システムは、どの自動車メーカーも実現している当たり前品質ではなく、自分達しか実現できていないユーザーに対する付加価値だ。ユーザーは他社にはない差別化された安全機能を目当てにその車を買うのだ。安全機能を売りにして差別化を図った自動車メーカーは禁断の果実に手を出したようなものだと思う。安全を売りにした以上、そこに問題があることは許されない。そこに問題があった場合の社会に与えるマイナスの印象は非常に大きい。リスクの大きい賭けとなる。医療機器の場合、装置が与える効果効能と安全・信頼を確保するためのリスクは表裏一体であり、エンジニアもそういうものだと思ってこの世界に入ってくる。社会への貢献度も高いがその裏に大きな責任やリスクがあることも分かってこの仕事を選んでいる。自動車業界のエンジニアはどれくらいそういう感覚を持っているのだろうかと思う。ブレーキを作っているサプライヤのエンジニアはその責任の重さを認識しているだろう。複雑な安全機能を複数のサプライヤで分担したり、異なる専門の技術者が協力して安全機能を開発したときに、安全に関する責任やリスクについてメンバー全員が同じような感覚を持てるかが疑問だ。システムが複雑化すると「それは俺たちの担当じゃない」という場面が増えてくる。その台詞に言葉では言い表せない恐怖を感じるのは品質保証担当やプロジェクトリーダーであり、経営者ではない。安全に関する機能がシステムに隠れていて正常に動作している間は、社会は事故の責任は運転手のミスと認識する。安全機能をシステムの付加価値にして表に出し、それを顕在的な価値(=カタログスペック)として他社との差別化に使って、安全機能の不具合が原因で事故が起こった場合、責任は自動車メーカーにあると誰もが考える。自動車メーカーが安全機能を売りにすることの最大の経営上のリスクは、実は複雑な安全機能システムに内在するソフトウェアのバグではない。発生した事故の原因が安全機能の不具合なのか運転手の運転ミスなのかはっきりと切り分けができないことが自動車メーカー自らが新たに抱えることになった最大のリスクなのである。アメリカ人なら発生した事故が運転手のミスではなく、プリクラッシュセーフティシステムや緊急操舵回避支援システムが正常に動かなかったからだと訴訟を起こすことは必ずあると思う。一回でもユーザー側が勝訴すれば後に続く人は増えるだろうし、そんなことが続けばよかれと思って他社と差別化を図るために付けた安全機能は一転してメーカーのマイナスイメージになりかねない。それを見越して自動車メーカーは飛行機のフライトレコーダーのような事故が起こったときにどのような制御がなされていたのかを記録するデバイスを搭載しているだろう。ようするに表では新しい安全機能によりドライバーの安心に貢献していますという顔をしておきながら、裏では事故が起こったときに「安全機能には問題がありません。」「悪いのは運転手です。」ということを証明するための証拠を集めながら自動車は走っているのだ。(事故の再発防止のためにはログの収集は必要であり、この表現はこういう見方もあるよという意味。)しかし、事故が起こったときに自動車メーカーが「安全機能には瑕疵がない」と主張するのは事故の当事者以外に対しても極めて印象が悪い。自動車を売るときだけはプラスのことだけ宣伝しておいて、事故が起こったとたんに守りに入る姿が不誠実に映るからだ。安全機能が当たり前品質として、また、潜在的価値としてシステムの内部に隠蔽されていたときは、事故の責任は運転手にあると社会は認識しているが、自動車メーカーが安全機能を表に出して顕在的な価値として大々的に宣伝し始めると、事故が起きたときの責任は自動車メーカーにもあるという認識が社会全体に生まれる。このことを自動車メーカーの経営層は実感していないだろうと思っている。自動車メーカーの経営者は技術者に「そんなことがないようにしろ」というだけだ。リスクマネジメントによってあらゆる問題に対して対策を取り、それらのリスクコントロール手段が確実に動くようにすることがいかに難しいか実感があるわけもない。いうときメーカーは問題が起こったときの防衛線を張ろうとする。それが、スバルのEyeSightのコマーシャルに現れている。CMの一番最後にチラッと白地の画面に注意書きのようなものが表示されているのにみんな気がついているだろうか。「こっちの世界」にいる者として、ここに安全機能が期待通りに動かないときの注意が書かれていることは分かっていたが消えるのが早くて読み取れなかった。お目当てのCMを探して問題の部分を静止して文言を読み取ってみた。書いてあることはこうだ。EysSight(ver.2)はお客様の安全運転を前提としたシステムです。道路・天候等の条件によっては衝突を回避できず、減速による被害軽減になる場合があります。詳しくは最寄りのSUBARU販売店にお問い合わせください。「衝突を回避できず、減速による被害軽減になる場合がある」は言い換えると「衝突回避は完全ではなく、減速するだけとなって怪我をすることもあります」であり、また、運転手が安全運転をしていなかったら衝突回避できないかもしれませんと言っている。EyeSight(アイサイト)クイックユーザーガイドにはもっと直接的な注意文が書かれている。EyeSight(アイサイト)は自動運転/自動衝突回避システムではありません。EyeSight(アイサイト)を過信せず、交通環境に注意して安全にご使用ください。ご使用の前には必ず取扱説明書をお読みください。CMの注意文が表示されている時間はストップウォッチではかったら0.8秒だった。0.8秒では注意文を全部読めないから、この注意文表示は後で何かあったときに「一般の方にもCMで注意喚起しています。」という既成事実を作っておきたかったのだろう。ちなみに、フォルクスワーゲンの「シティエマージェンシーブレーキ」のCMでの注意文も同様に読み取れないくらい早く消える。システムに問題が起こったとき(自動車の場合は事故が発生したとき)青い部分がメーカーの責任で赤い部分がユーザーの責任である。使用者から見たときの通常使用の範囲とメーカーから見たときの誤使用の範囲が重なっているのが分かるだろう。ここがグレーゾーンであり、メーカーとユーザーの認識のギャップとなる。メーカーとユーザーの間の安全に関する認識のギャップはメーカーがユーザーにどのような事前注意を求めているかで推し量ることができる。メーカーはユーザーが勘違いしそうなことについては、ユーザビリティ分析を行いできるだけ設計上の対策で回避しようとするが、設計上の対策でも防ぎきれない場合は注意喚起によりリスクを軽減しようとする。ユーザーはメーカーサイドが表示する注意喚起を気にしてくれるとは限らない。この図は機器のユーザビリティに関するリスクマネジメントの判断基準を説明するときのものだが、原因がはっきり分からない場合の事故でも同じで、いったん事故が起こればユーザーはメーカーの責任を拡大解釈し、メーカーサイドの瑕疵の可能性を徹底的に追求する。自動車は免許証を持った人しか扱えないが、一般的な運転の技術しか学んでいないし、機器を扱うスペシャリストではないから、基本機能以外の部分で起きた事故の責任はよりメーカーに強く求めるだろう。リスクに対する意識は時間が経つにつれてメーカー責任の範囲が広くなる方向に動く。導入された画期的な安全機能は仮に問題が起こっても「新しい技術だから」ということでユーザーサイドも割り引いて考えてくれるとこもあるかもしれないが、正常に動いて当たり前という状況、時代になった場合、責任はメーカー側に強く求められるようになる。リスクに対する意識は時代と共にメーカーにとっては厳しい方向に動くのである。リスクマネジメントはどこまでやればよいのあろうか。それは、左図にあるように、意図した使用目的に基づき、世間の常識、他社の状況を参考にし、そのときに考えられる使用条件(シナリオ)をベースにリスク分析をするのだが、ここまで述べてきたように自動車の安全機能を表に出したのは「付加価値」であり「商品価値」にしたことになるので、リスクマネジメントの要求レベルはさらに高くなっている。際限のないリスクマネジメントが辛くなり、時間切れになると、警告や注意文といった表記上の対策で逃げようと考えるようになる。上記の注意文がその典型的な例だが、実際に事故が起きて裁判になったとき、事前に注意喚起をしたことが有利に働くとは言い切れない。運転者が取扱説明書をじっくり読むとは誰も思っていないからだ。ユーザーが注意喚起を認知する努力をどれだけしたのか、ユーザーが実質的にどれだけ認知していたのかは裁判でも争点になる。刑事責任を逃れたいのならば、契約書を交わすのが確実だ。これは笑い話ではなく、自動車の付加的安全機能を使う際に契約書にサインする時代は必ず来ると思っている。ちなみに、契約書にサインさせても民事裁判では負ける可能性はある。日本では生命保険の契約内容が保険加入者に伝わっておらず、保険金が払われていない実態が問題視され、きちんと説明するように生命保険会社に行政指導が行われた。契約書にサインしても、ユーザーが書かれている内容を理解しないでサインさせた場合、メーカーの社会的責任は免れない。注意文をCMで0.8秒間だけ表示する行為はPL(製造物責任)の対策にはなっていないし、リスクコントロール手段にもなっていない。逆に不誠実さをさらけ出しているだけのように感じる。安全を売りにするということは、こういったことをすべてひっくるめてリスクマネジメントできているという自信があるということだと思う。エンジニアが絶対やってはいけないのは、設計上の対策でできることがあるのに、権威を笠に着た言い訳やユーザーへの注意文を取扱説明書に書いて、安全に対する責任から逃れようとすることだ。分析したらどうなるか、アーキテクチャ的にどんなリスクが想定できるのかまで書こうと思ったのだが、安全機能に対する考え方の解説だけで終わってしまった。複雑な安全機能をいかにユーザーに安全に使ってもらうかについては、今後我々が乗り越えなければならないハードルであることは分かっているので、次回以降に書こうと思う。教訓がまったく活かされていない。安全は静かに硬く実現するものであり、派手派手しく前面に押し出すものではないと個人的には思っている。P.S.自分は『機能安全』という言葉がどうしても好きになれない。システムは間違いなく安全のための機能だが、安全のために本当に必要かどうかは緊急操舵回避支援システムの効果効能が緊急操舵回避支援システムに不具合が起きるリスクを上回かどうかの判断で決まる。安全機能のシステムが複雑になるとソフトウェアによるシステマティック故障が起こる可能性が上がってくるので、安全機能の御利益がリスクを相当上回らないといけない。付加した安全機能があってもなくてもよい程度のものであると効用よりリスクの方が大きくなる。リスクの重大さを考えて効用の方を切るという判断もあってしかるべきだと思う。リスク効用分析が十分でなく、効用の方ばっかりに目が行くようになると危ない。機能安全という言葉はリスクの存在はあってもしようがないという前提で、効用の方に注目を集めようとする言葉のような気がする。『機能安全』は主役がリスクによって危害を被るユーザーではなく、安全機能を提供する機器製造業者側の視点の言葉になっていないだろうか。~ISO26262の認証証明だけで本当に安心できますか?~」のコマで、「市販ソフトウェアの信頼性検証」についてのプレゼンをします。Software:商用で即利用可能な市販ソフトウェア)をクリティカルデバイスで使用する際には、どんな検証を行い、どのように検証記録を残すべきか、どうすれば根拠のある信頼性の説明となるのかについて実例を使って解説するものです。適合証明は信頼性の根拠として説得力がなく、対象物の何をどうやって検証したのかを説明できるようにすることが重要であるという想いから付けました。FTAを描いてみる1今回は、FTAを描くときの注意点、特にソフトウェアが原因となって障害が発生する場合について考えてみる。いうUMLツールを使っている。なく、ソフトウェアはモデルを描いて分析しなければ全体を俯瞰できないところまで規模が拡大し複雑性が増している。モデルはプログラムと同じで一回描いたら終わりということはない。ソフトウェア開発の上流工程である要求分析からアーキテクチャ設計、詳細設計まで頻繁に書き換えるし、テストしながらモデルの問題に気がついて直すこともある。そこモデルは容易に変更が可能で情報を共有したり場合によってはドキュメントとして印刷できるようになっていた方がよい。バージョン9.3以降でインストーラにFTAの作図機能が同梱されており、すべてのエディションで後から追加して利用できるようになっている。サイトにFTAの作成について解説があるので、そこから少し引用したいと思う。トップ事象あるいは中間の事象。他の事象の組み合わせで表現される。通常の状況で発生する事象。展開不可能な、基本的な事象。展開することはできない。現時点では展開できない事象。追加の情報取得や状況の変化などにより、将来的に展開可能になる場合がある。展開することはできない。図を分割する場合に利用する記号。ANDゲート・ORゲート上位(上)の事象と、複数の下位(下)の事象の関係を示す。ANDゲートは、下位の全ての事象が発生すると上位の事象が発生する。ORゲートは、下位の少なくとも1つが発生すると、上位の事象が発生する。(ANDゲートは、下位の事象の発生確率の積が、上位事象の発生確率となる。ORゲートは、下位の事象の発生確率の和が、上位事象の発生確率となる。事象に発生条件がある場合、その条件を明示するためのゲートと要素。(下位の事象の発生確率と条件の確率の積が、上位事象の発生確率となる。)【FTAの特徴】FTAの特徴はある事象が発生するための要因を複数描くことができ、しかもその要因がANDの要因で発生するのか、ORの要因で発生するのかを図で表せる点にある。描いてしまえばどうってことない図だが、1961年当時ミニットマンミサイルをなんとしても固体燃料で飛ばしたいという意志とベル研究所のH・A・ワトソンのグループのアイディアがこの表記法を生んだのである。その歴史を踏まえつつ、ありがたく使わせてもらおう。上記の図で○の基本事象はこれ以上展開できないということをしてしており、長方形の事象を起こす要因は別にあると考えられるためさらに展開が可能だ。FTAはトップから下に向かって広がっていく。表現されているのである。特徴として、このように各事象の発生確率を追記することができる。この確率を自動的に計算する機能もある。ここで気をつけて欲しいのは、FTAの事象の発生確率は一人歩きしやすいという点だ。モデルに数値が追加されるととたんにもっともらしくなって、例えば論文などに好んで使われるようになる。自然科学の場合は論文に記された数字は裏付けとなる根拠が求められる。示される確率の数字はあてにならない場合があるので鵜呑みにしてはいけない。事象の確率を記載できるようにしたのは画期的ではあった。ORゲートで結合されている事象の場合低い確率の事象と高い確率の事象があれば、高い確率の事象の発生を抑える対策を取った方が、トップ事象の発生確率を低くできるはずだ。(決定論的原因故障/障害)の違いをおさらいしておきたいと思う。(ランダム故障)構成部品・機器などの多様な劣化のメカニズムの下で時間的に無秩序に発生する故障。故障率を計測することで統計的に品質を管理する。ランダム故障は故障率が計測できる故障だから統計的に管理できる。よって品質を高めることができる。出荷前の検査で発見することが難しく、出荷後に故障や障害が発生してから始めて分かることが多い。作り込みを防止し、検証や妥当正確認によって発見・除去する。要因であった場合、発生確率を論じるのは極めて困難だ。ポイントを使っていて、そこを通ると過大なエネルギーが照射されて患者が火傷を負うとする。一万回ユーザビリティの実験を実施して一回のみオペレータがその滅多に通らないパスを通るような条件で操作をしたとしよう。起こる確率は一万分の一と言えるだろうか。起こる確率は高くなる。この問題は、製造業者とユーザーの心理的な感情そして、技術者の倫理に関わる問題なのだ。場合、問題のある箇所のソフトウェアを修正すれば永久にその不具合の発生を防ぐことができる。それができるのに発生確率が低いという論理で、既知の不具合を放置することは、事故が起こってしまえばユーザーは製造業者を許さないだろうし、技術者の倫理的観点から見ても許されることではない。つながるバグを見つけたらすでに市場に出回っているソフトウェアも含めて確実に修正しなければいけない。場合は、その確率の低さを根拠に修正しないという選択肢もあるのでその点が最大の相違点である。Severity(重大度)のみを評価し、Probability(発生確率)は1と置くのである。起因する障害により事象が発現する可能性があるのであれば、事象の発生確率を担保に安全対策を取らないという選択をしてはならないのである。10のマイナス11乗で、「コンピュータが誤ったモードを選択する」が発生する確率は4×10のマイナス9乗となっていた。要因になりうるので、確率は10のマイナス11乗、4×10のマイナス9乗どころか1と考えなければいけない。結局、コンピュータをハードウェア部品と考えランダム故障しかしない部品としたことが、そもそもの間違いだ。1980年代という古い時代のものであったとしても、たましいの入っていない分析になっていたと思っている。人を簡単に殺せるような巨大なエネルギーを照射できることがエンジニアの頭に残っていれば、このような分析にはならなかったのではないかと思う。おける事象の発生確率を見るときには二つのケースがあり、二つの視点が必要だ。一つは相当な根拠があり発生確率を考慮してもよい場合、もう一つは、発生確率に再現性の裏付けがなく、「まあ、そんなもんだろう」という程度で数字を見ないといけない場合だ。クリティカルな事象を検討するとき、発生確率に統計的な裏付けがある場合は、FTAのダイアグラムにノートとして事象の発生確率の根拠を書き示しておくとよい。してもその発生確率を過大評価するのは危険だと思う。事象の発生要因がハードウェア部品の故障だったとしよう。ハードウェアの部品故障ならば、統計的に発生確率を計算できるし、その値もそれなりに信頼できるだろう。その部品を高信頼性部品としてシステムのクリティカルな部分に使う場合、本当にその確率の数字を信用していいのかよく考えて見る必要がある。いっても、さいころを振ったときの1の目がでる確率のようには起こらない。部品の故障率が時間とともにバスタブのように変化することはよく知られている。初期故障期間では故障の発生確率は高く、その後故障率は一定になり、耐用寿命を過ぎるとまた故障率は高くなる。使われる確率はバスタブ曲線の偶発故障期間の値だろう。システム導入初期また、耐用寿命を過ぎてからの高い故障率は考慮しなくてもよいのだろうか。耐用寿命を超えてもシステムを使い続けて事故が起こった場合の責任はユーザーにあるのだろうか。40年を耐用期限としている事故が起こると甚大な被害を及ぼす機器の使用期限を延ばしたときに、FTAに使った確率は変わらないのだろうか。部品であっても、バスタブ曲線のような変化をしないものもあるだろう。おける事象の発生確率は確率が低いからといって決して過信してはいけない。ランダムかシステマティックかといったことではなく、ソフトウェアの品質向上に関する方法論を適用して、従来より○○%向上したという記述をよく見かけるが、その数字も自分は信用していない。人間の活動を評価しようと思っても、技術者のソフトウェア開発という活動が統計的な母集団を持つとは思えないからだ。癖のあるやつは常に癖があるし、慎重な者でも体調が悪ければミスを犯す。人種や組織文化などにも影響を受ける。同じプロジェクトにならその数字もある程度再現性はあるのかもしれないが、他の組織や、他の業種、他の国で同じ結果がでるかどうかはわからない。Quality)」が良い解析ができるかどうかを左右すると思う。26262の世の中の動きをウォッチしていくこと自体にいささか疲れてきた。言って、本当にユーザーのことを考えて安全や安心を実現したいのなら、自動車業界の規格適合に関する浮かれた熱が冷めるのを2~3年待った方がよいと考えるようになってきた。機能安全に群がる商魂たくましい人たちとは一線を画して、クリティカルデバイス、クリティカルソフトウェアに役立つことは何かに集中していくかだ。今回は後者を選択して、FTAとFMEAの歴史を調べてみたいと思う。調べて改めてその歴史的背景を知ることで、いろいろ思うことがあった。(フォルトツリー解析)の略で故障・事故の分析手法の一つだ。フォルトツリーというくらいだから、左のような感じで木のように上から下に向かって広がった形になる。Fault(不良、傷害)が発生する要因を論理的にたどり、望ましくない事象がどのようなメカニズムでまたどのような発生確率で起こるのかを論理的に分析する方法だ。望ましくない事象に対してその要因を探るトップダウンの解析手法で、FMEA(故障モード影響解析)とは逆のアプローチだと言われている。個人的には、FMEAは既知の問題の再発防止に有効であり、経験を積み重ねていくほど発散しがちであるのに対し、FTAはどうしてもこれだけは発生させたくないという事象に対して、何を押さえなければいけないのか、どんな故障を考慮すべきなのかを分析する集中思考型の手法だと思っている。FTAの歴史の話を戻そう。目的として、その協力先であるベル研究所のH・A・ワトソンのグループが考案し、その後ボーイング(BOEING)社により完成された。歴史の解説はこんなもんである。ここから歴史的背景を掘り下げていく。1961年と言えば、米ソ冷戦のまっただ中の時代だ。