ISO 26262との向き合い方 (25) B787バッテリ故障FTAモデル

現在、SESSAMEで主催するソフトウェア安全分析・設計セミナ（第1回 6/7, 第2回 7/19)の講義スライドを作っている。

この特集記事を書いているせいか、第1回目のセミナの応募者の半分以上が自動車ドメインの方になっている。

第1回目のセミナは募集開始から10日間で定員に達してしまったため、第2回を 7/19 に行うことになった。

第2回は自動車ドメイン以外の方にも是非多くきて欲しいと思っているので、最近ニュースになっているボーイング787のバッテリ故障について FTAを使ってケーススタディをしてみようと思う。（このケーススタディはソフトウェア安全分析・設計セミナで詳しく解説する）

B787のトラブルのうち 1/8 と 1/16 のぶんがリチウムイオンバッテリの発熱・発煙事故だった。

日付 （日本時間）	会社	トラブル
01月08日	JAL	米・ボストンのローガン国際空港で、駐機中の日航機の機体内部から出火
01月09日	JAL	同空港で、地上走行中の日航機の主翼から燃料漏れ
01月09日	ANA	羽田発山口宇部行きの全日空機でブレーキに不具合
01月11日	ANA	羽田発松山行きの全日空機で操縦席窓にひびが入るトラブル
01月11日	ANA	宮崎空港で離陸前点検中の全日空機の左エンジンからオイル漏れ
01月13日	JAL	成田空港で、米国ボストンの空港で燃料漏れを起こした機体が、整備作業中に燃料漏れ
01月16日	ANA	山口宇部発羽田行きの全日空機で飛行中、操縦室内で異臭がしたため高松空港に緊急着陸。乗客129人と乗員8人が脱出用シューターで避難、乗客5人が軽傷

ニュースソースによるとボーイング社はリチウムイオン電池の故障確率を1000万時間に1度としていたが、実際には5200時間以下で事故が発生した。

FTAでは部品の故障確率を計算して総合的にトップ事象が発生する確率を計算できるが、個々の基本事象の発生確率の根拠が不確かな場合、トップ事象の確率がいい加減になるという典型的な例だ。

歴史的にもFTAによって、事故事象の発生確率が意図的に低いように見せるために、基本事象の発生確率を低く設定した例はある。また、ソフトウェアが起因する不具合の場合、不具合の発現は統計的な確率を持たないため、FTAでもこのことを考慮する必要がある。（詳しくはソフトウェア安全分析・設計セミナで解説する）

リチウムイオンバッテリが熱暴走し発熱・発煙したことは事実だが、結局その原因はまだ分かっていない。そこで、ボーイング社は80の可能性について対策を施すことで、FAAに B787 の飛行許可を申請し受理された。

ニュースでは熱暴走の本当の原因が分からないままで、運行を許可してよいのかというコメントが必ず付く。その通りなのだが、実際、セーフティ・クリティカルな製品を製造し市場に出している中で、再現しない不具合に対処しなければならないことはある。

そのような場合は、今回ボーイング社が行ったように、想定されるすべてのリスクを洗い出してその対策を施す。これが、リスクアセスメント（リスクの特定、リスク分析及びリスク評価）とリスクコントロールであり、ソフトウェア安全分析・設計セミナのメインテーマだ。

ボーイング社が80の対策を行ったということは、逆に言えば、対策を行う前は新たに想定した故障が具現化するとバッテリが熱暴走を起こし発火・発煙を起こすということだ。

これを FTA で表すと左記のようになる。実際はそう単純ではないが、何らかのハードウェアの故障及びソフトウェアの不具合が発生するとそれが OR 接続でトップ事象に結びく。

何か一つクリティカルな故障が起こるとそれが重大事故に繋がることを FTA は表している。

一般の人は、なぜ前もって対策をしなかったのかと思うだろうが、このような トップ事象に至る基本事象は無限に存在するのだ。

だから、ボーイング社が事故が起こった後に行った追加対策は80もあった。ただ、それで全てではない。リスクは無限に存在するので対策も無限に存在する。

そういった場合、仮にトップ事象の発現を押さえる包括的な対策があれば、それをシステムに追加することが安全面では非常に有効だ。（エレベータで安全用のブレーキを追加するなど）

これを FTA 表すと左のようになる。熱暴走故障の発現は包括的な安全装置で押さえられており、安全装置が故障しない限りトップ事象には至らない。

トップ事象は熱暴走の故障と安全装置故障が AND で起こらないと発生しないので、非常に低い確率に抑えることができる。

ただし、これは安全装置をハードウェアで用意した場合であって、ソフトウェアが絡んでいると必ずしも確率を言えないので注意が必要だ。

では、包括的な安全対策がない場合はどうするのか。それは、この図のように、ひとつひとつのハードウェア故障の発生確率を下げる対策を取る（Fault Avoidance)か、ハードウェア故障が発生したことを検出して、故障の発生を認知したら、オペレータに知らせそのための対策をオペレータが取る。

実際今回の80の対策のうち、バッテリの状態をB787の運行中も地上で監視できるようにしたそうだ。

バッテリ状態に異常があることが分かったら、パイロットに緊急着陸の指示を出す。

これを FTA で表すと左記のようになる。ハードウェア故障1の発生確率を下げ、かつ、故障検出装置を付けることで故障検出装置が故障しない限り、ハードウェア故障1のトップ事象への影響を下げることができることが分かる。

そして、最後に問題として残るのがソフトウェアの不具合がトップ事象に与える影響だ。

ハードウェアによる包括的な安全装置が使えない場合、個々のハードウェアの対策をしても、ソフトウェアの不具合がトップ事象に直接作用してしまう場合がある。

ソフトウェアの不具合の発生確率は統計的な性質を持たないため、高いとも低いとも言い切れない。

これが Systematic Failure の特徴だ。このように包括的な Fail Safe 対策が取れない場合、Fault  Avoidance  対策かFault Tolerance 対策で対処するしかない。

そこがソフトウェア対策の難しいところだ。実際、B787のバッテリ制御ソフトウェアに対しても、今回対策を行ったと報じられている。どんな対策か詳細は伝えられていないが、おそらくソフトウェアの信頼性検証を再度行ったか(Fault  Avoidance対策)、冗長設計(Fault Tolerance対策)を施したのだろう。

なお、FMEA（ハザード分析）をするとこんな感じになる。

ソフトウェア安全分析・設計セミナでは上記のことを含めた安全実現の手順について下記を紹介している。

1. Intended Use （意図した使用目的）を定義する
2. リスク分析を実施する。（ユーザビリティを考慮する）
3. リスクを評価する。（FMEA：ハザード分析、FTA)
4. リスクコントロール手段を考える。（ハード or ソフト or 表記）
5. ハードウェアによるリスクコントロールを優先する。
6. ソフトウェアによるセーフティアーキテクチャを可視化する。
7. 安全に貢献するソフトウェアアイテムを特定する。
8. それらのソフトウェアアイテムの信頼性を高める。
9. セーフティアーキテクチャを維持する。
10. フィールドで発生した問題をトリガにして1から繰り返す。

セミナでは、今回説明したB787バッテリ事故モデル以外にも、放射線治療器 Therac-25 の事故モデル、体温計モデル、エレベータモデル、電気メスモデル、緊急操舵回避支援システムモデルについて解説する。

7/19 の回にはまだ空きがあるので、是非セミナを聞きにきて欲しい。