ISO 26262との向き合い方 (20) 品質と安全の違い

これまで安全の領域に携わっていなかった人達が医療機器ドメインに入ってきたこともあってか、ソフトウェアの品質の向上と安全の確保が同意であると考える人が増えてきて困っている。

ソフトウェア品質の向上と安全の確保とは概念が異なることは何度となくこのブログで書いてきたが、今回、機能安全規格である IEC 61508 や ISO 26262 や、医療機器ソフトウェアのプロセス規格であるIEC 62304 の上位に位置する ISO/IEC GUIDE 51:1999  安全側面-規格への導入指針 にそのことがキチンと書いてあったので今回はそれを紹介しようと思う。

ISO/IECガイドとは、ISO と IEC の国際規格制定に関連する共通事項のガイドラインだ。ISO や IEC の規格制定、利用にあたっては ISO/IEC ガイドに留意する必要がある。例えば、下記のようなガイドがある。

ISO/IEC GUIDE 2 (2004)
Standardization and related activities -- General vocabulary
標準化及び関連活動－一般用語

ISO/IEC GUIDE 21 (1999)
Adoption of International Standards as regional or national standards
国際規格の国家規格への採用

ISO/IEC GUIDE 51 (1999)
Safety aspects -- Guidelines for their inclusion in standards
安全側面-規格への導入指針

これらは、ISO/IEC 規格を策定する際の共通事項のガイドなので、IEC 61508 も ISO 26262 も 　IEC 62304 もこれらのガイドに考慮する必要があるという訳だ。

今回、紹介するのは ISO/IEC GUIDE 51:1999 で、規格に安全に関する側面を導入する際の指針である。

なお、安全に関しては 日本では明治大学  理工学部  情報科学科の 向殿 政男 教授が有名である。向殿先生は、日本テレビ「世界一受けたい授業」やNHKの「クローズアップ現代」などにも出演されているのでテレビで顔を見たことがある方もいると思う。

向殿先生は ISO/IEC GUIDE 51 を解説した本『安全設計の基本概念―ISO/IEC Guide51(JIS Z 8051)、ISO 12100(JIS B 9700) (安全の国際規格) 』も出されているが、インターネット上の ISO/IEC GUIDE 51を説明した資料『2006-10-4日機連シンポジウム：「機械安全」の新しい波「機械安全」を取り巻く最近の動向』も公開されているのでそれを読むのもよいと思う。

なお、ISO/IEC GUIDE 51は JIS Z 8051：2004 として JIS にもなっているので、このガイドのもとを日本語で読むことも可能である。

安全の定義

ISO/IEC GUIDE 51 によると安全(safety) とは 『受容できないリスクがないこと』 (safety: freedom from unacceptable risk)　とある。この定義は非常に重要なのでクリティカルデバイスの開発に携わる技術者は頭の中にたたき込んでおいて欲しい。（受容できないリスク = unacceptable risk がキーワード。Risk は Acceptable か Unacceptable かを判断する。）

安全の概念について ISO/IEC GUIDE 51に解説がある。

安全という概念

安全は，あらゆる技術領域にまたがり，かつ，ほとんどすべての製品，プロセス及びサービスのための規格で扱われている。市場に投入される製品，プロセス及びサービスは，ますます複雑化しており，安全の視点に立った配慮の優先度を高くすることが求められている。 

絶対的な安全というものはありえない。この規格で残留リスクを定義しているように，ある程度のリスクは残る。そのため，製品，プロセス又はサービスは，相対的に安全であるとしかいえない。

安全は，リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは，絶対的安全という理念，製品，プロセス又はサービス及び使用者の利便性，目的適合性，費用対効果，並びに関連社会の慣習のように諸要因によって満たされるべき要件とのバランスで決定される。したがって，許容可能なレベルは常に見直す必要がある。技術及び知識の両面の開発が進み，製品，プロセス又はサービスの使用と両立して，最小リスクを達成できるような改善が経済的に実現可能になったときには，特に見直しが必要である。

許容可能なリスクは，リスクアセスメント（リスク分析及びリスクの評価）によるリスク低減のプロセスを反復することによって達成させる（図 1 参照）。

下記に「リスクアセスメント及びリスク低減の反復プロセス」の図を示す。


また、この図に出てくる用語も重要なので、言葉の定義を開催しておく。

 リスク (risk)：危害の発生確率及びその危害の程度の組合せ。

危害 (harm)：人の受ける身体的傷害若しくは健康傷害，又は財産若しくは環境の受ける害。

危険事象 (harmful event)：危険状態から結果として危害に至る出来事。

ハザード (hazard)：危害の潜在的な源。備考  ハザードという用語は，起こる可能性のある危害の発生源又は性質を定義するために用いることが一般的に認められている（例えば，感電，押しつぶし，切断，毒性によるもの，火災，おぼれなどのハザード）。

危険状態 (hazardous situation)：人，財産又は環境が，一つ又は複数のハザードにさらされる状況。

許容可能なリスク(tolerable risk)：社会における現時点での評価に基づいた状況下で受け入れられるリスク。

保護方策 (protective measure)：リスクを低減するための手段。
備考  保護方策には，本質安全設計，保護装置，保護具，使用上及び据付け上の情報並びに訓練によるリスクの低減策を含む。

残留リスク (residual risk)：保護方策を講じた後にも残るリスク。

リスク分析 (risk analysis)：利用可能な情報を体系的に用いてハザードを特定し，リスクを見積もること。

リスクの評価 (risk evaluation)：リスク分析に基づき，許容可能なリスクに到達したかどうかを判定する過程。

リスクアセスメント (risk assessment)：リスク分析及びリスクの評価からなるすべてのプロセス。

意図した使用目的 (intended use)：供給者が提供する情報に基づいた製品，プロセス又はサービスの使用。

合理的に予見可能な誤使用  (reasonably foreseeable misuse)：供給者が意図しない方法であるが，人間の挙動から生じる容易に予測しうる製品，プロセス又はサービスの使用。

品質の定義

品質と安全を比較するために品質に関する情報を示す。

SQuBOK（ソフトウェア品質知識体系ガイド）に品質の定義についていろいろな考え方が書かれているので、参考までに一部紹介しておく。（品質の概念はいろいろあるようだ。）

定義というよりは、つぶやきのようなもの？もある。詳細な説明はSQuBOKを参照して欲しい。なお、品質とソフトウェア品質は区別されていない。

• 「本来備わっている特性の集まりが、要求事項を満たす程度」[ISO 9000:2005]
• 「(1) システム、コンポーネント、またはプロセスが指定された要求を満たしている度合い。(2) システム、コンポーネント、またはプロセスが顧客またはユーザのニーズ、または期待を満たしている度合い」[IEEE Std 610.12-1990]
• 「指定された特定の条件で利用する場合の、明示的または暗示的なニーズを満たすソフトウェア製品の能力」[ISO/IEC 25000:2005]
• 「品質は誰かにとっての価値である。」[Weinberg 1994]
• 「システムが本稼働するときに、どこまで真のビジネス（ユーザ）ニーズにあっているかということ。」[Martin 1994]
• 「一つ目はプロダクトの特性が顧客のニーズに応えることで満足を提供するという観点、二つ目は不備（障害や誤り）から免れるという観点である」[Juran 1998]
• 「要件に対する適合」[Crosby 1980]
• 「機能および性能に関する明示的な要求事項、明確に文書化された開発標準、および職業的に開発が行われた全てのソフトウェアに期待される暗黙の特性に対する適合。」[Pressman 2005]

まあ、ISO 90001 の「本来備わっている特性の集まりが、要求事項を満たす程度」で品質を説明しておけば間違いはないであろう。

品質と安全は観点が異なる

一方、ISO/IEC GUIDE 51 には安全に関して次のような解説が書かれている。

安全は『受容できないリスクがないこと』と定義される。すなわち安全は受け入れ不可能なリスクから解放されていることであり「受容できないリスクがない」ことを持って「安全」と規定される。 

安全はリスクを経由して定義され，リスクはその時代，社会の情勢、環境によっても変化するため安全の尺度を一定にすることはできず，絶対的な安全を定義することはできない。そのため，製品，プロセスまたはサービスは相対的に安全であるとしか言えない。

機器製造業者にとってリスクの概念は時代とともに厳しい方向に推移する。機器に施された安全装置、安全対策は消費者や社会が成熟するにつれて「付いているのが当たり前」「対策されているのが当たり前」と捉えるようになるからである。自動車のABS（アンチロック・ブレーキ・システム）が最初に登場したときはオプション機能だったが、今日本ではABSは付いていて当たり前になりつつある。国によって差がある点にも留意して欲しい。（機器の利用環境の成熟度によっても変わる。）

だから、リスクコントロール手段は一度設計すれば終わりという訳にはいかない。時代、社会の情勢、環境によって見直しを続けなければいけない。だから、上記の図は「リスクアセスメント及びリスク低減の反復プロセス」なのだ。機器が市場にある限り、リスクアセスメントとリスク低減は反復しなければならない。

安全は，リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは，製品，プロセスまたはサービスにおける使用者の利便性，目的適合性，費用対効果，並びに関連社会の慣習のように諸要因によって満たされるべき要件とのバランスで決定される。 

したがって，許容可能なリスクは常に見直す必要がある。技術及び知識の両面の開発が進み，製品，プロセスまたはサービスの使用と両立して，最小リスクを達成できるような改善が経済的に実現可能になったときは，特に見直しが必要である。

技術は時代とともに進歩する。リスクコントロール手段も新しい技術によって、より効果的な対策に置き換えることができるかもしれない。だから、機器の後継機種を開発する際には、「リスクアセスメント及びリスク低減の反復プロセス」をもう一度回して、よりよいリスクコントロール手段がないかどうかを検討しなおす必要がある。

下記にリスクを受容可能にするための手順を示す。

1. 製品，プロセスまたはサービスの対象と考えられる使用者及び触れることが予見される者を特定する。
2. 製品，プロセスまたはサービスの意図した使用を特定し，合理的に予見可能な誤使用を見積もる。
3. 製品，プロセスまたはサービスの使用（据え付け，保全，修理及び解体，廃棄を含む。）の全段階及び全条件においてハザード（危険状態及び危険事象を含む。）を個々に特定する。
4. 特定したハザードが引き起こす個々に特定された使用者群及び接触者群に対するリスクを見積もり評価する。
5. そのリスクが許容可能かどうかを判断する（例えば，類似の製品，プロセスまたはサービスを比較して）。
6. そのリスクが許容可能なものでなければ，許容可能なレベルまでリスクを低減する。

そして、リスクを低減させる際の優先順位は次の順番になる。

1. 本質安全設計
2. 保護装置
3. 使用者に対する情報

本質安全設計を実現する本質的安全設計方策とは「ガードまたは保護装置を使用しないで，機械の設計または運転特性を変更することによって，ハザードを除去するまたはハザードに関連するリスクを低減する保護方策」である。 

また，保護安全を実現する方策は安全防護策と付加保護方策がある。保護防護策とは「本質安全設計によって合理的に除去できないハザード，または十分に低減できないリスクから人を保護するための安全防護物の使用による保護方策」であり，付加保護方策とは，非常停止，機械などに人が捕捉された場合の救助手段，脱出ルートの設置などを指す。この方策は支援安全機能と考える。

安全はリスクを許容可能なレベルまで低減させることで達成される。リスクを低減させるためには事前にリスクの特定、リスク分析、リスク評価といったリスクアセスメントが必要になる。

このことが安全に責任を負ったことのない人にはピンとこないらしい。品質を高める手法が仮にあったとしても、それがすべてのリスク低減に効くとは限らない。

例えば、OSやアプリケーションソフトウェアが暴走したときにCPUをリセットさせるためのウォッチドッグタイマーというCPUから独立したデバイスがある。一見、ウォッチドッグタイマーはすべてのリスクに有効なリスクコントロール手段になり得るような感じがする。

しかし、ウォッチドッグタイマーだけでは解決できないリスクもある。例えば、医療機器の生体情報モニタには意識のない患者さんの血圧を自動で定期的に測定するインターバル測定の機能がある。健康診断で使う上腕にカフを巻いて血圧を測定するやり方を例えば30分おきに機械が自動的に計測する機能だ。

そして、この非観血血圧測定の国際規格には次のような要求がある。

電源の瞬断があっても、血圧のインターバル測定の設定は維持されなければいけない。

※正確には下記が該当する要求文章。（すべての設定は変更されてはならない）

When the equipment contains an internal electrical power source and is capable of operating from it, and the mains supply is interrupted, does not apply. In this case the equipment shall continue operation, and the mode of operation and all operator settings shall not be changed. (IEC 60601-2-30:1999)

なぜ、こんな要求があるのかと言えば、意識のない患者さんの生体信号を計測している生体情報モニタにリセットがかかって、インターバル測定がリセットされると血圧の測定が中止されてしまう。ナースステーションにいる看護師さんや先生は血圧測定が定期的に行われていると思っているから、患者さんの血圧の変化に気がつかない。

このようなリスクがあるから個別規格にはこんな要求があるのだ。ちなみに、この要求は技術的にどのようにクリアすればよいか分かるだろうか。

まず、血圧のインターバル測定を開始したときは、装置内の不揮発性メモリ（例えばフラッシュメモリ）にその内容を記録しておく。インターバル測定が終了したときにはクリアする。

そして、電源が立ち上がったときに、まず、その領域をチェックしに行きインターバル測定のデータが残っている場合は、何らかの原因でインターバル測定が異常終了したと判断する。

※この方法を実施するには不揮発性のメモリが必ず必要だからコストダウンを理由にフラッシュメモリを取り除くことはできない。リスクアセスメントをしていなければやってしまうかもしれない。

ウォッチドックタイマーによるCPUのリセットはそこだけを捉えれば、信頼性を確保するための有効な手段かもしれないが、どんなシステムに使うのかが分からなければ、リスクの特定、リスクの分析、リスク評価ができないから、リスク低減策として使えるのかどうかを判定できない。したがって、”安全”を示す、すなわち「受容できないリスクがないこと」が言えないのである。

このことは、すべてのリスクに対して有効に働くリスク低減手段は存在せず、個々の製品、プロセスまたはサービスに対してスクアセスメントを行った上でリスク低減策を設計しなければ安全は確保できないことを示している。

これは、製品、プロセスまたはサービスの品質が高いことと安全であるとは同位ではなく、品質の概念と安全の概念の間に異なる観点が存在することを意味している。

品質と安全はビュー（観点）が異なるのだ。このことは、すべてのドメインに共通の品質向上策を武器に商売したい人たちにはとてつもなくマイナスな要素である。

品質の概念の一つに「顧客満足を高める」があり、これが安全の定義である「受容できないリスクがないこと」につながると思うが、どっちにしても安全を確保するためには、リスクを特定、分析、評価することは絶対に必要であり、それは機器やシステムが使われる場面を知っている者でなければできない。

ソフトウェアの品質特性を説くことと、リスクの特定、分析、評価は観点が異なるのだ。このことが分かっていないソフトウェア品質のエキスパートと呼ばれる人と話していても目指しているところが異なるからいつまでたっても議論がかみ合わない。

最後にもう一度繰り返すと、製品、プロセスまたはサービスの品質が高いことと安全であるとは同位ではなく、品質の概念と安全の概念では観点が異なる。

安全を実現するためには、リスクの特定、分析、評価といったリスクアセスメントを行った上で、リスク低減策を考える必要がある。リスク低減策を考える上で品質向上策は役立つかもしれないが、それはあくまでもリスクアセスメントを行った後に初めて判断できる。

そして、リスクアセスメント及びリスク低減のプロセスは、製品やサービスが市場にある限り反復しなければいけない。

したがって、セーフティ・クリティカルな製品を開発しているエンジニアは、リスク低減策について学ぶ前にリスクアセスメントに役立つ技術を習得すべきであると自分は考えている。そうしないと、受容できないリスクがなくなったかどうか判断できないからだ。

工業会主催のホンモノのセミナーが開催されるようです

Google Alarm で 「ISO 26262」とキーワード登録しておくと、いろいろなニュースが引っかかる。

「またかぁ」というものが多いが、これは参加する価値があるセミナーだと思う。

東京：2013 年2 月6 日（水）～8 日（金）3 日間
名古屋：2013 年2 月18 日（月）～ 20 日（水）3 日間

「ISO 26262 規格原文読み込みワークショップ～ISO 26262 の要件を原典で理解できる！」

なぜ、そう思うかというと、主催が（公社）自動車技術会（そのドメインの工業会）で講師が規格の適合を目指す当事者側の方たちだからだ。

テキストが規格の対訳で全部そろえると10万円くらいかかるが、本気で取り組むつもりなら持っていないと話が始まらないのでしようがないだろう。

ISO 26262との向き合い方 (19) 事故の再発防止について考える

2012年12月2日に中央道 笹子トンネルで天井が崩落する事故が起こった。事故に遭われた方、ご親族の方、お悔やみ申し上げます。

エンジニアができることやらなければいけないことは、一つは事故が起こらないようにリスクを分析し設計に活かすこと、そしてもう一つは事故が起こってしまったときに再発をしないような仕組みを作ることである。

むろん、規格に適合することが目的ではない。エンジニアには安全を確保するために今よりも前進できるかどうかが問われている。

よって、エンジニアは評論家のように単純に批判を繰り返すだけではいけない。「自分の関わっている製品、システムだったら」という観点で考えなければいけない。

設計 FMEA を実施した例

笹子トンネルの天井崩落事故について、エンジニアが考えなければいけないのは、まずは、FMEA(Failure Mode and Effect Analysis)の視点である。つり金具の老朽化が疑われているようだが、システム（今回の場合はトンネルの天井構造）の構成部品の故障モード（つり金具の脱落もその一つ）が起こったときの次の項目についての分析が必要となる。

下記に設計FMEAを実施した例を示す。

【設計FMEAの分析項目例】

1. 故障モード（具体的に）
2. 故障原因
3. 故障の影響：部分的影響
4. 最終システムへの影響（天井の崩落）
5. 故障検出方法（打音検査→それで正確に分かるのか）
6. 故障の重要性（重要度は極めて高いことが分かっている）
7. 故障の発生頻度（過去にどれくらい発生したことがあるか）
8. 対策案
9. 検出難易度
10. 致命度ランク（重要度×発生確率×検出難易度）

※設計FMEAの分析項目はこうでなければいけないという決まりはない。形式にとらわれないことが大事である。

トンネル構造部の設計FMEA の例（一部）

故障モード	故障原因	故障の影響		故障検出方法	故障の重要性	故障の発生頻度	対策案	検出難易度	致命度ランク
		部分的影響	最終システムへの影響
つり金具が折れるまたは脱落する。	つり金具の振動、腐食による老朽化。	天井ユニットの脱落。	連結している天井ユニットの連鎖的脱落。	打音検査等による定期検査。	走行中の車両に当たると死に至る可能性がある。	全国のトンネルに付き、○○年に○回。	異常が発見された場合、一週間以内に補修し、トンネルあたりの修理数が○回を超えたら、○ヶ月以内に恒久対策を講じる。	中程度	最上

【設計 FMEA の分析のしかた】

FTA に見られるトップダウンの安全分析方法に対して、FMEAはボトムアップの解析手法と言われる。FTA が最終的に起こしてはならない事象をトップにおいて分析を始めるのに対し、FMEA では故障モードを左端において解析を進める。

よって、FMEA の使い方としては、市販前の製品の設計段階において故障モードを洗い出し分析、対策し、市販後に起こった障害や事故の故障モードの分析をそれに追加するという使い方をするのが一般的であろう。

[故障モード]
システムの構成部品が故障するときの状況について具体的に記述する。故障モードの前（左側）にシステム全体に対して、どの部分に関する故障であるかを示すための階層を追加することもできる。

例) トンネルシステム→天井部分→接続部

[故障原因]
故障モードが発生する推定原因を記載する。

[故障の影響：部分的影響]
故障が引き起こす部分的な影響、例えば「天井ユニットの脱落」を書く。

[故障の影響：最終システムへの影響]
部分的影響がもたらす最終システムへの影響の可能性を書く。

[故障検出方法]
故障の検出方法を書く。ちなみに「仕業点検」や「目視」という検出方法もあるが、故障の重要性が大きい場合、人間の目に頼る検出方法はお勧めできない。

[故障の重要性]
故障の重要性をシステム利用者が被る危害に焦点を当てて書く。

[故障の発生頻度]
故障の発生頻度を定量的（定量的に計算できない場合は、定性的）に記載する。数値化することが難しい場合のために、目安となる指標（頻繁に起こる、まれ、極めて少ないなど）をあらかじめ準備しておく。

[対策案]
具体的な対策を示す。設計上の対策を行うことがベストであるが、表記上の対策（説明書記載のラベリング）でしか対策できない場合もある。

[検出難易度]
故障モードを検出する難易度を示す。

[致命度ランク]
故障の重要性、発生頻度、検出難易度の3つのパラメータから致命度ランクを計算する。決まりはないため分析対象物やドメインに対して、判定基準をあらかじめ作成し、SOP(Standard Operation Procedure) に記載しておく。

今回のトンネル天井崩落事故の場合、注視すべき点は故障モードが起こす部分的な影響と最終システムへの影響である。つり金具の脱落という天井のユニット（板）に発生する部分影響が連鎖的に周りにユニットの崩落につながっていることを認識した上で再発防止の対策を考える必要がある。

事故が起こると「なんで、こんなことが分からなかったのか」と皆が思う。しかし、事故が起こる前に危険性を指摘すると「今から変えられない」とか「コストがかかる」とか「これまで起こっていなかった」という理由で動かない組織はたくさんある。

そのネガティブな組織判断をサイエンスとエンジニアリングによって突破するのがシステムの安全に対して責任を負うエンジニアの役目であり、それを組織的に支援・管理するのが品質マネジメントシステムである。

今回のような事故の場合、故障検出方法の設計、故障発生頻度、検出難易度の決定が再発防止に大きな影響を与える。実際には打音検査によるボルトの緩み等のチェックが行われているようであるが、人間の感性、感覚に頼る検査方法は本質的なリスクとは異なるヒューマンエラーのリスクを伴う。

FMEA の結果は、表にしなくても見識者ならだいたい思いつくような内容だ。しかし、FMEA を行う意味は、他のリスクと同様にある一定の手順に基づいて、故障によるリスクを分析することにある。

人間の記憶は時間と共に薄れていくものなので、知見を継承するためにも、同じ様式による分析結果を組織が保持することが大事なのだ。

FMEAには市場からのフィードバックとして修理情報や苦情情報などをインプットするため、設計 FMEA はどんどん積み重なっていく。故障モードや想定されるハザードは無限に存在するのでFMEA では追加対策自体が新たな Hazardous Situations を生み出したり、故障モードはハザードが多すぎて、どこの焦点を合わせたらよいかわかりにくくなる傾向を持つ。

そのため、故障の重要度、発生頻度、検出難易度から致命度ランクを計算し、これによって対策に優先順位を決めたり、重大な被害につながる故障に焦点を当てたり FTA を行うことで、対策が多すぎてコストや開発期間が優先になって、安全対策が後回しにならないようにする。

FTA によって他の事象との関係を確認する

「トンネル内の火災により死傷者が出る」をトップ事象にしたときのFTA図につり金具の老朽化による天井の崩落の事象を追加した例を示す。

トンネル内の火災となる原因は他にもあるはずなので左記はほんの一部の現象を切り取ったに過ぎない。

FTA が FMEA に比べて優れている点は、起こしてはならないトップ事象に対して、想定した事象がどのように影響しているのかを容易に判断できることである。

別な言い方をするとどの事象が一発でトップ事象を引き起こしてしまうのか、また、どんな歯止め、どんなリスクコントロールが失敗するとトップ事象を引き起こしてしまうのかを把握しやすいということだ。

つり金具の脱落が金具の老朽化とボルトの緩みが原因だったとして、それが仮に起こったとしても、打音検査によって見つけることができれば事故を未然に防ぐことができるかもしれない。（FMEAのところでも書いたように打音検査はヒューマンエラーのリスクを含む）

よってつり金具の故障と打音検査の失敗が AND で重なったときにトップ事象に到達してしまう。このように、FTA では着目すべき事象が、他の事象とどのような関係性を持っているのか、どのリスクコントロール手段がトップ事象への到達を押さえているのかを把握するときに有効である。

FMEA によってリスクコントロール手段を次々と追加していった場合、それらのリスクコントロールがどのようにシステムを複雑にしているのか分析するときにも  FTA が役に立つ。闇雲にリスクコントロール手段を追加していくと、かえってシステムの安全性を低下させることもあるので注意が必要である。

システム全体としてシンプルなリスクコントロールにより、トップ事象を起こさない(=安全を確保できる）ことを目指す。

リスクマネジメントのフィードバックプロセス

左図は、ISO 14971(医療機器－リスクマネジメントの医療機器への適用)のリスクマネジメントプロセスの一部である。

注目して欲しいのは、10 の製造情報及び製造後情報のアウトプットが 5 のリスク分析のインプットにつながっている点である。

ようするにリスクマネジメントのプロセスはフィードバックすることが前提であり、リスク分析、リスク評価、リスクコントロールは製品やシステムが市場にある限り継続し続けなければならないのだ。

そのとき、FMEA や FTA は、リスク分析、リスク評価、リスクコントロール、残留リスクの評価、リスクマネジメント報告に各プロセスで利用することができる。

対象となる商品やシステムを取り巻くリスクは無限に存在する。リスクが無限に存在するからといって、リスク分析やリスクコントロールを永遠に続けることはできない。組織は有限なコストや開発期間のために、リスク分析をどこかで打ち切らざるを得ないのだ。

そのため、組織はできるだけ短期間にリスクを洗い出し、有効な対策を設計に活かす必要がある。それが上手くいけば、それらの対策は商品や組織のアドバンテージとなり、商品の潜在的価値を高めることにつながる。

ただ、残念ながらそのような努力を最大限行ったとしても、事故は起こってしまうし、時代とともにリスクに対する人々の感性は変わっていく。

だからこそ、上記のリスクマネジメントプロセスはフィードバックしなければならないのだ。

CAPA（Corrective Action & Preventive Action：是正処置及び予防処置）の実施

リスクマネジメントプロセスを実施していたにもかかわらず、事故が起きてしまった場合、CAPA（Corrective Action & Preventive Action：是正処置及び予防処置）を行う。事故が起きてしまった後に実施するのが Corrective Action で 事故が起こらないように未然に察知する対策を取るのが Preventive Action となる。

Corrective Action: 是正処置で重要なのは、実際に起こった問題を除去する処置＝修正（correction）と是正は異なるという点だ。是正処置は、検出された不適合又はその他の検出された望ましくない状況の原因を除去するための処置(ISO 9000 用語の定義）であるから、根本原因を除去する処置を執らなければいけない。

つり金具を補強するとか、緊急点検するといった行為は根本原因の除去ではない。自分が考えるこの事故の根本原因は、天井構造を設計する際のリスク分析/ハザード分析の不足及び、事故が起きたときのメインテナンス事業計画への見直しのプロセスの欠如である。

対象製品やシステムのリスクが無限に存在することを考えたとき、事故発生後に根本原因を追及して、取り除くことができるかどうかが、同様の事故の発生を効果的に防止することにつながる。

事故発生後にその場しのぎの対策を取ってしまうことは根本原因を取り除くことにはならない。

高速道路上のトンネルで笹子トンネルのような天井ユニットを取り除く検討が各地で進められているようだが、それは根本原因の除去になっているだろうか。トンネル上部の天井構造は1960年代の自動車の排ガスを効率的に排出するために設計されたと聞く。現在では、排ガスをクリーンにする技術が進んだためトンネル内の排気はファンで十分なのだそうだ。

そうなると根本原因の除去として必要なのは、時代の変化、環境の変化、構造物の老朽化要因をトンネルのメインテナンス計画にインプットし、リスクが受容できるかを判定するプロセスを追加することだと考える。

12月11日の毎日新聞のニュースサイトに『トンネル崩落：中日本高速、米事故後も対応取らず』という記事が掲載された。

米国の高速道路で０６年に極めて似たトンネルの天井板崩落事故が起き、独立行政法人が０８年に作成した調査文書で事故原因などを国や高速道路各社に伝えていたことが分かった。国や中日本高速道路も事故を把握していたことを認めているが、具体的な対応は取らなかったとみられる。専門家は「緊急点検などの対処をすべきだった」と批判している。

事故が起こった後に批判するのは簡単だが、批判と是正処置（Corrective Action）は違う。このケースでは次のようなことをやりきらないと是正処置（Corrective Action）にはつながらないと思う。

• 高速道路の関する“自組織が管理する高速道路”の事故、修理、苦情情報を収集するプロセスを現行プロセスに追加する。
• “日本国内の他組織が管理する高速道路”の情報も含める。
• 関係独立行政法人からの報告書も含める。
• 海外の事故情報も含める（かどうか判断する）。
• これらのデータを品質保証部門が集計、統計的な分析を加えて、定期開催される組織の品質保証委員会に提出する。
• 品質保障委員会にて、これらのデータについてどう判断したのかを記録に残す。
• 上記のプロセス及び手順を SOP （Standard Operation Procedure）に記載し、定期内部監査によって実施されていることを確認する。

こうしておけば、海外で起きた事故のデータについて「動かない」判断をしたトップマネジメントの責任が明確になり、問題が発生したときの判断ミスがはっきりする。

これは ISO 9001 （品質マネジメントシステム）のアプローチそのものなので、ISO 9001 を取得している組織はできるはずなのだが、ISO 9001 の認証を取得することが目的になっていると、事故が起こったときに本当にやらなければいけないことができない。（このブログで口を酸っぱくして言っているのは、ISO 26262 も同じで、規格に適合できても、安全を確保する能力が高まらないのであれば意味がないということだ。）

何か問題が起こったときに批判して評論だけするのが「評論家」くんで、Corrective Action をやりきれるのが問題解決キッズである。（人気の記事『問題解決能力（Problem Solving Skill)：自ら考え行動する力』を参照されたし。）

「評論家」くんは、何か事件が起こったときに鬼の首を取ったように生き生きと問題を指摘するが、再発防止にはあまり貢献しない。本来は火消しよりも、防火活動を地道に行っている者を組織は評価するべきだと思う。

修正（correction）はそのときだけの対策であり、是正処置（Corrective Action）は、根本原因を取り除くことで、将来に渡っても同様の問題を起こさない対策である。その違いを十分に認識できていないと、事故は再発してしまう。

前述の FMEA , FTA の結果により、リスクを最小限にするにはどのような構造設計がふさわしいか、ふさわしくないかが分かる。今回のように構造物として簡単に取り替えがきかないのだとしても、保守計画はあるだろう。保守計画プロセスに、例えば過去20年間の事故や事故に至る前の予兆現象をインプットできていれば、そのための予算策定や行動計画が立てられる。事故が起こってからではなく、事故が起こる前に Preventive Action が取れるかどうかが安全エンジニアの力量が問われるところであり、そのためには予兆の検出技術が不可欠となる。

予防処置（Preventive Action）を実施するためには、対象物に対する定期的な検査が不可欠となる。

左図にあるように、定期検査の結果が管理限界に達したときに、事故が起きる前の予防処置を実施する。

破壊するところまで達してしまっては遅いので、管理限界点は過去の統計的なデータに基づいて余裕を持って設定する。

予防処置を確実に実施できるようにするためには、事故に至る前の予兆をいかに予知できるかどうかにかかっていることが分かるだろう。

したがって、この故障の予兆を検出する技術こそが、リスクコントロール手段と並んで安全を確保するを実現する重要な技術であることが分かる。

品質の向上と安全の確保は異なる

商品の安全に対して責任を負った経験がない者は「品質の向上」と「安全の確保」を同義にとらえる傾向がある。品質向上にはここまでという一線がないため、品質向上を商売にしている者にとっては都合がよい。一方、安全には超えてはならない一線が存在する。想定したリスクが受容できない限り商品を市場に出すことはできない。そして、やるべきことをやっても事故が発生してしまったときは、その経験をフィードバックしていく。

品質向上施策には Best Practice がいろいろあって、「あれをやった方がいい」「これが有効だ」などと無責任に助言できるが、「安全の確保」はそんなもんじゃない。

特にソフトウェアの場合、やれ「ISO 26262 ではフォーマルメソッドが推奨されている」とか「トレーサビリティアナリシスをやらないとダメだ」などと、言葉の知識がない者に品質向上施策の単語を並べる者がいるが、安全の確保はリスクマネジメントプロセスのフィードバックを繰り返すことによって少しずつ強固になっていくのだ。（安全の領域にも銀の弾丸はないのだ）

そして安全を強固なものにするためには、不具合や事故が起こったときの根本原因の分析と、根本原因を取り除くための対策を講じることが重要になる。

それを繰り返すことによってのみ組織は顧客から信用を得ることができる。

※この記事に書いたことは、医療機器ドメインを含む既存の安全工学に基づいた知見の応用である。自動車ドメインが安全の領域に進んで行くのであれば、規格要求を理解をするだけでなく、他のドメインや自動車ドメインで安全のためにどんな取り組みがなされてきたのかを調べてみるとよいと思う。

P.S.

2012年12月4日 日刊工業新聞に下記の記事が掲載された。（詳細は有料会員登録が必要）

【日刊工業新聞の記事より引用】

日本自動車研究所（JARI）は主要な自動車および自動車部品メーカーなどと連携し、自動車の機能安全規格「ISO26262」に対応する際の日本の自動車業界の共通見解を取りまとめる。 

　同規格の個別内容にどの程度厳格に対応するか見解をまとめることにより、対応過剰や対応不足など完成車メーカーと部品メーカーの同規格に関する考え方のミスマッチを防ぐ。2013年2月にワークショップを開き公表する予定。 

　JARIのISO26262運営委員会が進める共同研究のワーキンググループには、トヨタ自動車をはじめ完成車メーカー9社と、関連する自動車部品や電機などサプライヤー17社の合計26社が参加している。規格の1文1文について、「何を意味しているか、どうやって、どこまで対応するかを検討してきた」。

【引用終わり。】

JARIは自動車業界の中にいて安全性の試験をしているわけだから自動車ドメインのことは、何も知らない第三者認証機関よりよく知っているだろう。

また、上記の運営委員会は自動車完成メーカー9社とサプライヤー17社が参加しているので、現場の目線でISO26262で見ていると思われる。

よって、JARIから見解が出たら、雑音に惑わされずにそれを参考にするのがよいと思う。

ISO 26262との向き合い方 (18) ツール認証って何だ？

ISO 26262 Part 8: Supporting processes （支援プロセス）には「ソフトウェアツールの使用への信頼」という章がある。

いろいろな国際規格を見てきたが、商業目的につながることが目に見えているツール種別の推奨やツール使用の条件のような内容を規格の本文に書いているのは、IEC 61508-7(Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 7: Overview of techniques and measures) と、ISO 26262-8 (Supporting processes) だけではないかと思う。

ET2012 で富士設備工業（株）の浅野さんに FAA(アメリカ連邦航空局：Federal Aviation Administration)では、当初、航空機開発を行う際に使用するツール認証を一般的なソフトウェア開発プロセスの判断基準で行っていたが、問題があったので止めたことを教えてもらった。

【The Latest Trends in International Standards Required for Certification 国際スタンダード認証に必要なテストの最新動向 October 5, 2012 Tokyo　LDRA資料より引用】

The FAA and Tool “Certification” FAA のツール認証について

• The United States Federal Aviation Administration (FAA) once tried issuing “letters of certification credit” for using “pre-qualified” tools.
かつてFAA (《米》連邦航空局) では、“認定済み” ツールの証明書の発行を試みた。

– The pre-qualified tools were evaluated against a generic set of software development process criteria.
認定済みツールは一般的なソフトウエア開発プロセスの判断基準で評価された。

– The letters of certification credit imposed constraints on the use of the tools to match the generic development process criteria.
それら認定済みの証明書では、一般的なソフトウエア開発プロセスの判断基準に従ってツール
を用いるといった制約を強いた。

• Because the FAA’s software development guidance allows for various development methodologies to satisfy the objectives, it was found that many tool usage scenarios did not meet the constraints on tool use.
FAAのソフトウエア開発ガイダンスではオブジェクティブを満たすうえで、様々な開発方法論を認めている。それゆえ認定上のツール用法の制約に、様々なツール使用のシナリオは合わないことが明らかになった。

【引用終わり】

ストレートには書いていないが「認定済みの証明書があるこのツールを使え」という制約は、実際のツール使用のシナリオに合わない、すなわち本末が転倒していたことを認めている。認証済みのツールを使った方が航空機ソフトウェアシステムの安全や信頼の確保の効果が高いという傾向が見られなかったのだろう。

医薬品や医療機器の世界では、アメリカのFDA が CSV（Computer System Validation）を製造業者に求めている。CSVの目的は、クリティカルな製品を開発、製造する際に、ツールや自動工程で使うソフトウェアの妥当性を評価することである。

簡単に言えば、危ないものを作るのに何らかのソフトウェアを使っているのであれば、それが製品の安全を脅かしていないことを確認して根拠を示せと言っている。

根拠を示さなければいけないのは、製造業者サイドであって、ツールベンダーではない。（ツールベンダーやサプライヤと協力して根拠を示すことはある）

買ってきて設定だけしか変えないツールやそのまま使うソフトウェア製品（カテゴリ1と3）であってもバリデーション計画や報告、運用時の点検などは、使用者である製造業者側が行わなければいけない。

ツールやソフトウェアシステムが使われる場面、用途を知らないツールベンダーがツール認証を掲げるのとは、考え方がまったく違う。

ツールを含むコンピュータシステムのバリデーションを求めているのは、対象となる医薬品や医療機器の安全がコンピュータシステムによって脅かされないかどうかの確認であり、それを示すためには、どんなリスクが存在するのか特定しなければいけない。

どんなリスクがあるのかを知っているのは、ツールやコンピュータシステムを使う側なので、使う側がリスクに対して検証結果の有効性を確認する。一般的なソフトウェア開発プロセスに従って開発されていることを示したツール認証では、リスクを回避できることは証明できない。なぜなら、ツールを認証する際に、ツールを使用する側にどんなリスクがあるのかを想定していないからである。

例えば、モデルや高級言語からコードをジェネレートするツールがあったとしよう。それらのツールがツール認証を持っていたとして、バグが絶対にないかといったらそうではないし、ツール認証はバグがないことを保証している訳ではない。だから、ツール認証だけを安全の根拠にしてクリティカルなモジュールの開発には使えない。

だから、FAA もツール認証を止めたのだろう。（ It was found that many tool usage scenarios did not meet the constraints on tool use. )

じゃあ、ISO 26262-8 の「ソフトウェアツールの使用への信頼」が何を要求しているのか、キチンと読んでみよう。

ISO 26262-8 ソフトウェアツールの使用への信頼

11. ソフトウェアツールの使用への信頼
11.1 目的

この節の第一の目的はソフトウェアツールに対する信頼の要求水準を決めるための基準を提供することである。

この節の第二の目的はそのソフトウェアツールが ISO 26262 で要求される活動や、タスクのテーラリングに使用するのが適切であるという証拠を作成するための認定手段を提供することである。（すなわち、ユーザーは ISO 26262 で要求される活動やタスクのためのソフトウェアツールの正しい機能を信頼できる）

11.2 総則

システム、そのソフトウェア又はハードウェアエレメントの開発で使われるソフトウェアツールは、ISO 26262 によって要求される活動とタスクのテーラリングを通じて、安全性ライフサイクルのテーラリングを支援あるいは可能にすることができる。その場合、ソフトウェアツールが効果的に下記の目標を達成できるという信頼が必要である。

a) 誤った出力につながるソフトウェアツールの故障に起因する、開発された製品のシステマティックフォールトのリスクを最小にすること。

b) ISO 26262 によって要求される活動やタスクが、使用されているソフトウェアツールの正しい機能に依存するものであれば、開発プロセスは ISO 26262 に十分適合しうること。

備考："ソフトウェアツール"は、個別に使用されるスタンドアロン・ソフトウェアツールからツール・チェーンに統合された一連のソフトウェアツールまでを含むと考えてよい。

例：そのようなソフトウェアツールは、市販のツール、オープン・ソース・ツール、フリーソフトウェア・ツール、シェアウェア・ツール又はユーザーによって社内で開発されたツールでもかまわない。

上記の状況の下の開発で使用されるソフトウェアツールに対する信頼の要求水準を明らかに決定するために下記のような基準が評価される：

－機能不全のソフトウェアツールとそれにともなう誤った出力が開発中の安全関連アイテム又はエレメントにエラーをもたらす若しくはエラー検出ができないという可能性。

－その出力におけるそのようなエラーを防ぐ若しくは発見できることに対する信頼

防止または発見方策に対する信頼を評価するために、安全関連アイテム又はエレメントの開発プロセスに実装されるソフトウェアツールに対する外部からの方策（例えばガイドライン、テスト、レビュー）だけでなく内部からの方策（例えば監視）も考慮され評価されることができる。

決定されたツール信頼水準により必要と判断されれば、適切な認定方法はこのツール信頼水準とソフトウェアツールを使用して開発されることになっているアイテム又はエレメントに割り当てられるすべての安全要求の最大のASIL両方に適合するために適用される。その必要がなければ、そのような認定方法を適用する必要はない。

というのが総則の内容で、この後、次のような節が続く

11.3 この節への入力
11.3.1 前提条件
11.3.2 追加の支援情報
11.4 要件及び推奨
11.4.1 一般的な要件
11.4.2 あらかじめ定められたツールの信頼水準または認定の妥当性
11.4.3 ソフトウェアツールの評価基準またはその認定に対する遵守性
11.4.4 ソフトウェアツールの使用法の計画
11.4.5 分析によるソフトウェアツールの評価
11.4.6 ソフトウェアツールの認定
11.4.7 使用実績による信頼性の向上
11.4.8 ツール開発プロセスの評価
11.4.9 ソフトウェアツールの妥当性確認
11.4.10 ソフトウェアツール認定の確証レビュー

11.4.9 でソフトウェアツールの妥当性確認(Validation of the software tool)があるが、この内容なら、医療機器の世界ではValidation ではなく、Verificationになる。11.4.6 のソフトウェアツール認定の手法の中に、11.4.9 のソフトウェアツールの妥当性確認が推奨されているのだが、ツールベンダーや第三者認証機関が、そのツールを使う対象の Intended Use を知らないのに、Validation できるはずがない。

できるのは一般的なソフトウェア開発プロセス通りに作ってますよということの証明でしょ。それをクリティカルシステムに使用する際の信頼性の根拠（安全性の根拠でないことに注意）として胸を張られてもなぁと思う。

総則 a) の 「誤った出力につながるソフトウェアツールの故障に起因する、開発された製品のシステマティックフォールトのリスクを最小にすること。」を製品の Intended Use を考慮せずにやろうとしたら、検証は永遠に終わらない。「リスクを最小にする」というところがミソだ。リスクを最小にするということは、リスクは完全にはなくらならないということを示している。

医療機器ドメインでは、このような場合 「リスクコントロール手段によってリスクが受容できるレベルまで下がっていることを確認する(ISO 14971)」 となる。リスクを受容するためにはリスクとリスクを制御するための手段を特定しなければいけないが、システマティックフォールトのリスクと言ってしまったらそれはソフトウェアのバグのことになってしまう。バグの数を最小にせよというのは努力目標にしかならず、目に見える具体的なゴールにはなり得ない。

実際に、バグが一個もないツールなんてあるわけがないし、仮に一個あったとして、それがどんなことに影響するかはツールを作る側には分からない。

かつて、複雑なコンパイルオプションを指定して、特定のC言語のコードを記述すると、期待されないアセンブラが吐き出されるといったコンパイラの不具合通知を見たことがあるが、たいていの場合、そのような特殊な複合条件（例えばメモリ最小化オプションとの組合せ）で製品開発はしていないからセーフであることが多い。しかし、どこかのプロジェクトでそんな使い方をしている可能性はゼロではない。万が一、その不具合に合致した使い方をしていた製品がとても危ないところの制御をするソフトウェアだったら問題だ。

認証には保証を伴う場合もある。例えば日本の場合、医薬品の許認可をするのは国であり厚生労働省である。よって、認可した医薬品に問題があれば、国はその責任を負う。薬害エイズや肝炎訴訟では国が許認可に対する非を認め再発防止と被害者に賠償の責任を負った。だから認証する側も同じ問題を見逃してはいけないので真剣だ。

アメリカもすごい。会計検査院が 「FDA（食品医薬品局）の取り組みがなっていないから、認可した医療機器が問題を起こして国民が不利益を被っている」と平気で指摘する。

FDA が指摘に対してアクションプランとその進捗状況を公開しているので興味のある方は参照されたし。（こちら）

一方、ISO 26262 のツール認証はどうだろうか。ツールを認証した第三者認証機関は、そのツールの不具合が原因で問題が起こったときに、何らかの保証をしてくれるのだろうか。何かしらの責務を負って認証しているのだろうか。

自動車業界はツール認証も含めて、ISO 26262 の取り組みが、製品開発にどのように影響したのか、効果があった点、効果がなかった点、逆に品質向上に足を引っ張った点を今後振り返って情報発信する義務があると思う。

経営層にとっても規格適合に投入した金が、エンドユーザーの価値向上に貢献し、組織の利益にとってプラスに働いたのかどうかをいずれ検証しなくてはいけないだろう。

また、ツール認証をことさら強調するツールベンダーの人には下記のことを聞いてみるとよいだろう。

• 認証によって何が確認されたの？
• 認証によって何が保証されるの？
• ツールのバージョンが上がったら認証やり直すんですか？
• ツールの妥当性確認って何をやったの？
• ツール認証時の審査結果のサマリを見せてもらえる？

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 の事故が、自動車ドメインでも起きるかもしれない。

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の認証証明だけで本当に安心できますか？～

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）」が良い解析ができるかどうかを左右すると思う。

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

ISO 26262との向き合い方 (11) ASILの分解は本当に可能か

日本規格協会から発売された ISO 26262 の英和対訳版が手元に届いた。まず、ISO 26262-9 Automotive Safety Integrity Level(ASIL) - oriented and safety-oriented analyses を読んでいるのだが、何しろ具体例がないからわかりにくい。

さらに混迷を深めているのは ISO 26262 ではエレメントの概念がハードとソフトを明確に区別していない、それぞれの特徴を十分に考慮できていない、エレメント同士の結合について踏み込めていないところだ。

そもそも ISO 26262 はECU を含む自動車の構成部品をメーカーがサプライヤから“調達する”という前提に立っているから、ハードウェアの特性とかソフトウェアの特性を考慮した安全設計という概念が不足していように感じる。

ASIL D は ASIL C(D) + ASIL A(D) や ASIL B(D) + ASIL B(D)にデコンポジション（分解）できると書かれているのだが、デコンポジション後のエレメントの十分な独立性の証拠が必要（原文では evidence for sufficient independence of the elements after decomposition shall be made available, 訳文では 十分な独立性の証拠が利用可能でなければならない）とされている。

この規格の問題点は独立性の証拠の証明のしかたについては言及していないところだ。（ソフトウェア開発の方法論、検証方法には言及しているのに）

エレメント同士の独立の条件として、従属故障を起こさないということが書かれており、ISO 26262-8 （支援プロセス）に従って安全分析をしなさいと書いてある。

では、最近複数の自動車メーカーがCMで宣伝している前方に障害物があると自動的にブレーキがかかるプリクラッシュブレーキシステムの場合はどうなるのだろうか。

ブレーキの基本機能は ASIL D だろう。画像解析のエレメントは ASIL D なの？という疑問が生まれる。 プリクラッシュブレーキ システムはシステム全体としては ASIL D だろうから、ブレーキの基本機能は ASIL D のままで、画像解析エレメントは ASIL C(D) にデコンボジションしたとする。

その際にブレーキエレメントと画像解析エレメントは独立しており従属故障は起こらないと言えるのだろうか。

画像解析エレメントが対象物を誤認して、対象物があるのにないと判定したり、逆に対象物がないのにあると判定したりしたら、ブレーキエレメントに誤った指令を送ることになる。これは意図した使用とは異なっているので従属故障ではないのか？

ではこれは従属故障ではないとして、システムの複雑化の代償としてのケーススタディを考えてみよう。

台風で1m以上の木の枝が車の前にが飛び出してきた。でも後ろから大型トラックがほとんど車間距離なしで追走しており、バックミラーをみたら大型トラックの運転手は携帯電話を見ている。

「 プリクラッシュブレーキシステムは今は働いて欲しくない」と運転手は思ったが、システムは作動し、大型トラックに追突された。このケースは故障ではない？　でも事故に遭ったユーザーはどう考えるだろうか。そんなことろまで考えて作るのが自動車メーカーだと考えないだろうか。想定外を想定するのが日本の企業だと思わないだろうか。

また、障害物の認識と運転手のハンドル操作がほとんど同時だった場合はどうするのだろうか。仕様では運転手のハンドル操作を認識するとプリクラッシュブレーキシステムは動作しない仕様があるとして、例えば障害物の認識とハンドルを切り始めた時点が100msも遅れていなかったら、どっちが優先されるのだろうか、判断を許容範囲の時間（例えば3秒）を設けなくてもよいのだろうか。プリクラッシュブレーキの起動が始まってから1秒後に運転手のハンドル操作を認識したら、プリクラッシュブレーキを中断するのだろうか。

プリクラッシュブレーキによる後ろの車両からの追突といった危険状態（Hazardous Situation）を回避するために、車の後ろにもセンサーを設置して、十分な車間距離が取れているときだけ自動停止システムを働くようにしたとする。しかし、そうするとますますシステムは複雑化する。また、車間距離センサに泥や異物がくっついていて十分に働かなかったらどうする。その時はエラーを表示する。そのエラーインジケート処理が失敗していたらどうする。

安全のためだと思ってリスコントロール手段を追加すると、追加したリスクコントロール手段によって発生しうる新たなリスクに対処しなければいけない。新たなリスクコントロール手段の設置によって、システムは複雑化し、さらなるリスクを生む可能性がある。リスクを回避するために追加したリスクコントロール手段によって発生する二次的なリスクは元のリスクよりも小さくなるのが普通だろうと思ったら大間違いだ。

ハードウェアの故障だったら確率は漸次小さくなる可能性が高い。ハードウェアの故障はランダム故障の場合が多いから、もとのシステムと安全装置の故障が二重に起こる確率は下がる。部品の故障率ならば1万分の１×1万分の1で、10億分の1など。

ところが、リスクコントロール手段をソフトウェアで実施した場合はそうではない、ソフトウェアはハードウェアのような壊れ方（不具合の発生のしかた）をしない。Systematic Failure を起こす。

問題の種類によっては、リスクコントロール手段として用意した安全装置のソフトウェアのちょっとした問題が元のシステムに多大な影響を与えることがある。それがソフトウェアのおそろしいところだ。

サーバー管理会社が起こした大規模障害

レンタルサーバーを提供するファーストサーバが6月20日に大規模なデータ消失事故を起こしたのをご存じだろうか。

Computerworld の記事が図入りで分かりやすかったのでリンクを示しておく。
『ファーストサーバ、大規模障害の概要と原因を中間報告――複数要因が重なりデータ消失』

こちらはファーストサーバの原因説明ページ
『大規模障害の概要と原因について（中間報告）』

自分の所属コミュニティの SESSAME のWEBサイトはファーストサーバを使っており、サイトの情報は一時、きれいさっぱり消えてしまった。（幸いSESSAMEのWEBサイトは1時間足らずの作業で元通り復旧した。）

さて、みなさんの組織は重要な企業情報のデータのバックアップを取っておられるだろう。個人のローカルPCの中のデータはもしかしたらバックアップは取っておらず、誤って消さないように気をつけて使っているかもしれない。

バックアップシステムは安全対策（=安全アーキテクチャ）はフォールト・トレラント (Fault Tolerant) の一種と言える。

フォールト・トレラント (Fault Tolerant) とは、故障や誤動作が発生しても機能が正しく維持されることで、大抵は構成要素の多重化 (冗長化) によって実現される。

本体に何かがあってもバックアップで冗長化したことで元の機能を復帰させることができる。

フォールト・トレラント (Fault Tolerant) とは対照的な安全対策として、フォールト・アボイダンス (Fault Avoidance)がある。フォールト・アボイダンス (Fault Avoidance)は故障の可能性を充分に低くすることであり、部品の高信頼性を目指すことで安全を実現する。バックアップを取らずに慎重に作業するという行為はフォールト・アボイダンス (Fault Avoidance)に近い。

フォールト・アボイダンス (Fault Avoidance)は、そもそも故障しないようにして、安全性を確保するやり方だ。

フォールト・トレラント (Fault Tolerant)は多重化・冗長化をするために、システムとしての複雑性が増す。逆に、フォールト・アボイダンス (Fault Avoidance)は冗長化設計より構造がシンプルになる。

安全対策では、フォールト・トレラント (Fault Tolerant)もフォールト・アボイダンス (Fault Avoidance)もどっちも選択できる。フォールト・トレラント (Fault Tolerant)を選べば、システムの複雑性は増すが、部品の故障率は厳格に管理しなくてもよい。（ランダム故障なら二重故障、三重故障の確率は低くなるから。）

フォールト・アボイダンス (Fault Avoidance)を選ぶと、故障率の低い部品を選んだり、ソフトウェアなら検証の網羅性を高めないといけないが安全システムの構造はシンプルになる。

この構造がシンプルかどうか、すなわち安全を司るエレメントやソフトウェアモジュールが、他から見て高凝集で疎結合であるかどうかが、ソフトウェアの場合非常に重要な要素である。

ハードウェアだけで構成されるシステムの場合は、フォールト・トレラント (Fault Tolerant)にしたことによるリスクは少ないが、ソフトウェアの場合フォールト・トレラント (Fault Tolerant)を採用したときのリスクは小さくない。

なぜなら、ソフトウェアによる冗長設計は問題がないことを証明することが困難であり、ちょっとした問題がシステム全体に影響を及ぼす Systematic Failure の特性を持っているからだ。

ファーストサーバの障害は、次のような事象が重なって発生した。

1. 更新プログラム自体に不具合があった。
2. 検証環境下での確認による防止機能が十分に働かなかった。
3. メンテナンス時のバックアップ仕様の変更が重なり、バックアップ・データの消失を含む今回のデータ消失が発生した。

余談だが、こういう事故が発生したとき、事故の原因を間違っても、作業者のケアレスミスなどと結論づけてはいけない。そんな結論なら、必ずまた同じことが起こる。ファーストサーバも再発防止策として当面、緊急性がなければ保守作業をしないと告知しているが、それは恒久対策ではない。

ファーストサーバの中間報告では原因1として下記の説明がある。

脆弱性対策のためのメンテナンスが必要となる都度、メンテナンスのための更新プログラムを作成しており、今回も更新プログラムを作成しています。
そのプログラムの記述において、ファイル削除コマンドを停止させるための記述漏れと、メンテナンスの対象となるサーバー群を指定するための記述漏れが発生していました。

メインテナンスのための更新プログラムを都度作成しているとある。オペレーション的には普通に思えるが、安全対策でフォールト・トレラント (Fault Tolerant)を採用していたと考えると、冗長設計したもう片方の安全システムへの変更を定常的に行っていたとも読み取れる。

もちろん、変更に対するデグレードの危険性は考慮していた。だから、検証環境で試してから本番環境に移すというオペレーションを実行していた。

しかし、それでも事故が起こってしまったのは、検証環境と本番環境には差があり、本番環境で実施して初めて分かる問題があった、すなわち検証環境で行ったテストはレグレッションテストとしては漏れがあったということである。（100%の検証はできないので、検証環境ではテストの漏れを完全に無くすことはできない。）

そして、たった数行の意図しない動作で今回の大規模障害は起こった。

具体的には「ファイル削除コマンドを停止させるための記述漏れ」と、「メンテナンスの対象となるサーバー群を指定するための記述漏れ」が組み合わさった結果である。

ソフトウェアの Systematic Failure の恐ろしさはここにある。たった二つの記述漏れが、とんでもない大規模障害を生み出してしまうのだ。ハードウェアのランダムエラーではこんな被害の拡大の仕方はしない。

今回の障害のきっかけもソフトウェアの変更だった。何事もなく動作していているシステムに対するソフトウェアの変更には危険が潜んでいる。

何事もなく動作している自動車システムのソフトウェア搭載部品を部品ごと変更するのも同様に危険を含んでいるし、エレメント内部のソフトウェアに変更を加えるのも危ない。

ASIL のデコンポジションの独立性証明

最初の話に戻ると、ISO 26262 では ASIL のデコンポジションの独立性を、従属故障の可能性の分析して判断せよと言っているが、その際にソフトウェアの特性を考慮しなくてもいいのだろうか。結合の仕方についてもっと突っ込まなくていいのだろうか。エレメントやサブエレメント同士の結合に関する考察が不足しているように感じる。下記の appropriate measures （独立性を達成するための適切な対策）って何なのということだ。

【ISO 26262-9:2011 5.4.6 より】

If ASIL decomposition is applied at the software level, sufficient independence between the elements implementing the decomposed requirement shall be checked at the system level and appropriate measures shall be taken at the software level, or hardware level, or system level to achieve sufficient independence.

ASIL デコンポジションがソフトウェアレベルで適用される場合、デコンポジションされた要求を実装するエレメント間の十分な独立性がシステムレベルにおいてチェックされなければならず、十分な独立性を達成するために、ソフトウェアレベルまたはハードウェアレベルまたはシステムレベルにおいて、適切な方策がとられなければならない。

【引用終わり】

安全対策の複雑化と安全アーキテクチャの安定性にはトレードオフの関係があり、それはシステム全体として考えていかなければいけないのに、サプライヤから供給される部品をくみ上げて車を作ることだけを前提に考えていると安全アーキテクチャの安定性が軽視されるのではないかと感じる。

市販化されているプリクラッシュブレーキシステムも、安全対策はよく考えられているのだろう。WEBサイトを覗いてみたら運転手がハンドル操作やブレーキングをした場合はシステムは動かないと書いてあった。運転手の意思の方を優先させていることが読み取れる。

しかし、システムの複雑化、特にソフトウェアが絡んだシステムの複雑化は思わぬ問題を生み出す危険性がある。ASIL D のエレメントをデコンポジションできていると言えないと、複雑化した巨大システム全体のすべての機能の信頼性が高いことを証明しないといけない。

ASIL 分解の独立性を証明できないから、数十万行、数百万行のソフトウェアシステムの信頼性をフォーマルメソッドで証明せよというのはナンセンスだと思う。安全対策をより確実なものとするために ASIL のデコンポジションは必要だ。でも、独立性の完全性や従属故障が絶対に起きないなどとは言えない。その状況下でベストな選択は何かを考えないといけない。

ソフトウェアが搭載されたエレメントの信頼性の証明は難しいし、自分はソフトウェアの完全性の証明は永遠にできないと思っている。ソフトウェアでシステムを実現している以上、Systematic Failure のリスクは一生背負っていると考えた方がよい。それを完全に排除しようとするのではなく、できるだけ小さくするには何をどうすればよいのか考えないといけない。

そう考えると、ソフトウェアモジュールの分割とその独立性の証明、アーキテクチャの洗練は非常に重要になる。それは、ASIL D = ASIL C(D) + ASIL C(D) といった単純な式で表せるようなものではないと思う。

むろん、プロセスアプローチだけで解決できない。もっと、ISO 26262 を読み込まないといけない。

P.S.

ファーストサーバの事故再発防止策はおそらくこんな感じになるだろう。

1.  検証環境におけるテストの網羅性の向上。（レグレッションテストに対するカバレッジの計測と記録も必要）
2. ファイル削除コマンドといった影響度の高いコマンドをリストアップし、保守ソフトにおいてそれらのコマンドが使用されていればそこだけ抽出し、設計者以外の第三者によるレビューを行う。
3. さらなるフォールト・トレラント (Fault Tolerant)として、保守ソフトを監視するソフトウェアを追加し、危険を察知したら保守ソフトを止める。（システムが複雑になるので、あまりお勧めはしない）

人間が関わっている限りヒューマンエラーはゼロにはならない。逆に言えば、バックアップを取らずに、大事なファイルの取り扱いや、削除コマンドを使うときは慎重に行うといった人間の意識に働きかける対策の方が実質的な効果が高かったりする。日本人の品質を心配する意識の高さが、Made in Japan の品質の高さに貢献していると考えるのはそういう理由からだ。ただ、品質を心配する意識だけで安全を担保できないほどシステムが複雑化しているのも事実だ。

----------
この記事を読まれた方は『自動車業界と医療機器業界のリスクマネジメントの違い』の記事も是非お読みください。