ISO 26262との向き合い方 (23) ソフトウェア安全分析・設計セミナ

ISO 26262 が2011年に発行されてから時間が経過し、今になって自動車の設計開発の現場で混乱が起こり始めたような気がする。

ソフトウェアの開発経験のないハードウェアエンジニアにもISO 26262の存在がクローズアップされるようになり、ソフトウェアエンジニア達に規格適合できているの問いただすような視線を送るようになってきた。

ISO 26262 は基本的にプロセスアプローチだから、規格が要求するプロセス通りにもの作りをし、エビデンスとなるドキュメントが作成していないと規格に適合していると認めてはもらえない。

規格適合について監査したり、自分達でアセスメントをしたりすると、いろいろと漏れが出てくる。そうすると、ソフトウェアのことを分からない人達は「なんだ、ダメじゃないか」「どうして、国際規格の要求ができていないんだ」「怠慢だ」とソフト屋さんを責める。

電気的安全性のように試験で白黒がはっきりするような規格なら、不合格のままで出荷されることなどないから、ハード屋さんや品質保証担当は、ソフトウェアの規格が満たされないまま商品が世界に出荷されていることが我慢ならないのだろう。

しかし、そこがソフトウェアの評価の難しいところだ。ソフトウェアはハードウェア部品のように確率論的な故障のしかたをしない。だから、ソフトウェアの信頼性を高めるためにはソフトウェアの開発プロセスを管理するしかないというのが定説になっている。

しかし、ソフトウェアの信頼性を高めたからと言って、システムが安全かと言えばそうではない。このことを上記のような感情を抱くハードウェアエンジニアや品質保証担当は分かっていない。

分かっていないにもかかわらず、ソフトウェアの開発プロセスの管理ばかりに注力を注いでいると、規格の目的とは対照的に商品の安全性が脅かされる危険さえある。

そういう背景もあって、所属しているコミュニティの SESSAMEで 2013年6月7日(金)にソフトウェア安全分析・設計セミナ（1日）を開催することになった。

6月7日のセミナは、ソフトウェアプロセスアプローチとはまったく別の切り口から安全設計を考えるセミナだ。


セミナのプログラム案はこのようになっている。

22nd Open SESSAME Seminar プログラム（案）
10:00～10:30	クリティカルソフトウェアを取り巻く環境
10:30～11:30	安全（セーフティ）の考え方 ・安全（セーフティ）の定義 ・リスクアセスメント,リスク低減 ・リスクマネジメントの反復プロセス ・ソフトウェア起因の障害のリスク評価
12:30～13:30	リスク分析手法1（FMEA) ・FMEAの歴史、ハザード分析 ・ソフトウェア視点のFMEA
13:40～14:40	リスク分析手法2（FTA) ・FTAの歴史 ・ソフトウェア視点のFTA
14:50～16:10	リスクコントロール手法 ・フェールセーフ ・エラープルーフ（フールプルーフ） ・フォールト・アボイダンス ・フォールト・トレランス ・ソフトウェアコンポーネントの分離 ・事例検討
16:10～16:30	リスクコントロールの維持
16:30～17:00	質疑応答

プログラムを見てもらえば分かるように、リスク分析とリスクコントロールの方法に注力を注いだ構成になっている。FMEAやFTAは古くからあるリスク分析手法で、教科書も日科技連から出ていて、セミナも定期的に行われている。ただ、改めて教科書となっている本を眺めていると、事例が古いのと、ソフトウェアのことが考慮されていない。

これらの教科書が書かれた時代から、すでに40年近く経過している。時の流れとともに、商品はソフトウェアへの依存度が高くなり、その構造自体もかなり変わってきた。

例えば、これはFMEA/FTAの教科書に載っているガス暖房システムのブロック図だ。昔のシステムはハードウェアコンポーネントが独立したブロックになっていて、ブロック図の四角と実際のコンポーネントが一致していた。

だから、FMEAを実施する前に作成する信頼性ブロック図の各ブロックはそれぞれ独立性が高かった。別な言い方をするとブロックで書かれたコンポーネントの凝集度は高く、他のコンポーネントとの結合度は低い設計になっていたということだ。

しかし、システムの制御の大半をソフトウェアが担うことになって、信頼性ブロック図で書かれたコンポーネントと現実のハードウェア、ソフトウェアのコンポーネントは一致しなくなった。

また、ソフトウェアコンポーネント同士は密接に結合するようになり、どことどこがくっついているのか、どこがどこに影響を与えるのかどんどん見えにくくなってきている。

システム構造の変化が激しく起こったため、FMEAやFTAなどのリスク分析の手法も時代に合わせて使い方を変える必要がでてきた。6/7のセミナでそれを解説したいと思う。

また、これだけソフトウェアの規模が拡大し、複雑化した今日において、システムを構成するすべてのソフトウェア部品の信頼性を高めようとするアプローチは効果が薄く、苦労する割には得るものが小さい。

安全設計の方法（日経ものづくり 2010年8月号 の特集記事『ソフトが揺さぶる製品安全』参考）

現在のソフトウェアシステムのセーフティを実現するための考え方は全体最適の発想が必要である。それを表したのがこの図である。

フォールト・アボイダンスは個別最適の発想であり、大規模ソフトウェアシステムの安全性はそのやり方では確保できない。

全体最適の手法としてフェール・セーフ、フォールト・トレランス、エラー・プルーフといった考え方をシステムの設計者は常に考慮しなければいけない。

また、ソフトウェアによってシステムは格段にユーザーインタフェースが向上した。UIが向上した一方で、オペレーションが複雑になり、ユーザーが誤った使い方をすることでリスクを生むようになった。このため、ソフトウェア搭載機器の危険を避けるためのユーザビリティエンジニアリングは重要性が増している。

セミナでは、これらのリスクコントロール手段についても解説をしたいと思っている。正式なアナウンスは SESSAME のホームページでの掲載を待っていただきたいが、興味のある方は自動車ドメインの技術者だけでなく、さまざまな産業のソフトウェアエンジニア、ハードウェアエンジニア、品質保証担当に参加して欲しいと思っている。