2013-06-27

ISO 26262との向き合い方 (27) 最終回:何に向き合いますか?

2011年12月1日から1年半、27回に渡り続けてきた特集記事「ISO 26262との向き合い方」をいったん終了にすることに決めた。

書きたいネタはまだまだあるのだが、6/7 に開催した SESSAME のソフトウェア安全分析・設計セミナの参加された自動車ドメインの方達と接して、ハタと気がついたのだ。

薄々気がついていたのだが、自動車業界は業界構造がサプライヤが部品を作りメーカ(OEM)がアセンブリするというスタイルが出来上がっている。

だから、ソフトウェア安全分析・設計セミナで訴えている「現代の大規模・複雑化したシステムでは Fault Avoidance(個々の構成要素の信頼性を高めることで安全を確保しようとする設計)は無理で、Fail Safe, Fault Tolerance, Error Proof(Fool Proof) の設計を目指しましょう」という主張が肩すかしにあう。

サプライヤは自分達が供給している部品やその部品を制御するソフトウェアにしか関心がなく、完成品の安全について切々と語ってもぼんやりとしか受け取ってもらえないということに気がついた。

だから、メーカから ISO 26262 の規格に適合せよと言われて、そこで要求されているいろいろなことをクリアできるようになりたいという欲求はあっても、「エンドユーザの安全について考えよう」という問いかけには反応が薄い。

コンサルタントも含めてセミナで訴える最終製品の安全の実現よりも、リスク分析の手法を習得することに興味が集中しているらしい。

そして、ISO 26262 という規格の構造自体が 自動車業界の構造を意識したものであり、サプライヤが供給する部品に Fault Avoidance(個々の構成要素の信頼性を高めることで安全を確保しようとする設計) を求める規格であることが分かった。

ISO 26262 も上流工程(ISO 26262-1,2,3 機能安全の管理、コンセプトフェーズ、システムレベルでの製品開発)でシステム全体のリスクアセスメントをすることになっているが、これは絵に描いた餅で後から取って付けた要求に見えてきた。

メーカとサプライヤが一緒になって、コンセプトフェーズやシステムレベルでの製品開発について、頭を付き合わせてディスカッションしている構図がまったく想像できない。

雰囲気的には、メーカはサプライヤの規格適合を命令するだけ、サプライヤはISO 26262に適合せよと言われてやるだけのように見える。間をつなぐはずのソフトウェア系コンサルタントはハードウェアによるリスクコントロール手段には興味がなく自分達の守備の範囲外だという顔をしているように見える。

唯一、ECUのプラットフォームを担当する会社のエンジニアはセミナの内容にビビッときたようだが、自動車のシステム全体を見渡せるようなポジションにはいないようだ。

そんなことを考えていたら、下記のようなニュースが飛び込んできた。

【中日新聞2013年6月27日記事より引用「衝突軽減装置、誤作動の恐れ トヨタ、2万台リコール」】
トヨタ自動車は26日、前の車にぶつかりそうになると自動ブレーキがかかる衝突軽減装置に誤作動の恐れがあるとして、昨年末に発売した新型「クラウン」約1万9千台と、5月に発売した新型「レクサスIS」約1000台のリコール(無料の回収・修理)を国土交通省に届け出た。衝突軽減装置のリコールは国内2例目で、トヨタ車では初めて。
 この装置は車体から前方に電波を飛ばし、跳ね返った電波を受信して障害物の距離を測る。近づきすぎると警報音が鳴り、自動的にブレーキがかかる仕組みだ。
 国交省によると、4月以降、リコールの対象車の所有者から「突然ブレーキがかかった」などの情報が6件あった。うち5月下旬、東京の首都高速道路で、渋滞で徐行中のクラウンに急ブレーキがかかり、後続車に追突された。運転手にけがはなかった。 
 トヨタは、クラウンとISを全面改良した際、隣車線からの割り込みにも対応できるよう、障害物検知の感度を上げた。東京の追突事故では、先行車に当たって乱反射した電波が、並走のタンクローリーにも反射。電波が横から来たため「割り込み」と誤って認識して急ブレーキがかかったという。 
 リコールでは、障害物検知のソフトを修正する。衝突軽減装置は、各メーカーがここ10年ほど開発にしのぎを削り、量産効果で価格も下がってきたことで搭載車が増えている。トヨタによると、販売台数のうち新型クラウンでは4割、新型ISでは6割が搭載車という。 
 国交省によると、搭載車のIS約800台が北米や欧州に輸出されており、リコールが必要かどうかトヨタが調べている。
 衝突軽減装置をめぐっては今月4日、三菱自動車もスポーツタイプ多目的車(SUV)「アウトランダー」で、トンネルの壁を前の車と誤認して自動ブレーキがかかる不具合が判明し、リコールを届け出た。
【引用終わり】

ソフトウェア安全分析・設計セミナでは、車の基本機能である「走る」「止まる」「曲がる」がアーキテクチャ的に独立している時には、問題が起こりにくいが、今後市場要求が多様化して「走る」「止まる」「曲がる」の機能が相互に干渉してくると、これまで予想もしなかったような原因の分かりにくい不具合が増えてくるということをレクチャーしている。

安全をインテリジェントにするということの裏側には、思いもよらない副作用も付いてくる。その複雑性に伴うリスクの怖さが自動車ドメインの技術者にはピンときていない。

プリクラッシュ・セーフティシステムは「走る」「止まる」がソフトウェア的に結合し、緊急操舵回避支援システムでは「走る」「止まる」「曲がる」が結合する。

上記の誤動作は「止まる」の機能の中に閉じた問題だが、各機能が結合した状態で発生する不具合はこんなに簡単には原因がつかめないかもしれない。しかし、時代はそういった複雑な安全機能・安全性能を求めている。

トヨタ自動車は自動車メーカの中では唯一プリクラッシュ・ブレーキシステムをCMで大々的に宣伝せず、あのろくでもない読み切る前に消える免責事項の表示もしていない。おそらく、プリクラッシュ・セーフティシステムに不具合が絶対に起こらないこともないとは思っていないし、仮に起こったとしてもCMで免責を表示しているからといってユーザに責任を押しつけることなどできないから、そうしないのだろう。

そして、実際問題が起こったらソフトウェアを修正して粛々とリコールをする。それが正しい自動車メーカとして立ち振る舞いだと思う。

CMで免責を表示している他の自動車会社は事故が起きたときに、免責出しているので不具合があっても許してくれと言うのだろうか。そんな言い訳は通用しないのだから、一刻も早くCMの免責表示を取るべきだと思う。

さて、ISO 26262 はこのような複雑化した自動車ソフトウェアシステムの不具合の再発防止に役立たなければ、まったく意味がないと思っている。

だから、ISO 26262 を推進している担当者やコンサルタントは、上記のような不具合は ISO 26262 を使ってどうやって防止するのか現場のエンジニアに説明して欲しい。

自分は自動車業界の産業構造と、自動車業界の産業構造を意識した規格である ISO 26262 は、このような問題には有効には働かない(どこかに方法は埋め込まれているのだろうが、上手くマネジメントされる気がしない)と感じている。

数年後、自動車への安全要求が多様化した後、分かりにくい不具合が増えてくる。そして、電気自動車の割合が増えて、聞いたことがないメーカの車が出てくると、分かりにくい不具合が一気に増えて社会問題になるだろう。

そうなって初めて、自動車業界は現在の産業構造のままでは問題を解決できない、サプライヤにISO 26262 の適合を押しつけただけでは、安全を確保できないことに気が付くようになる。

そうなるには、あと数年以上はかかると見た。そして、自動車メーカもサプライヤもそういった痛い目に遭わなければ、真剣にリスク分析やリスクコントロール設計を学ぼうと思わないと悟った。

だから、ISO 26262との向き合い方の特集記事はいったん今回で終わりにすることに決めた。

時代が再び自分の知識や経験を求めるようになったら、また書き始めようと思う。

長い間、特集記事「ISO 26262との向き合い方」におつきあいいただきありがとうございました。

※ブログ「組込みソフトウェア工房」は続きますので、記事のリクエストは引き続き募集します。単発で ISO 26262 の記事を書くことはあります。

P.S.

2013年7月1日に『トヨタの部品共通化、海外メガサプライヤーに好機到来』という記事が掲載された。部品が共通化し中小のサプライヤが淘汰されメガサプライヤーに集約されるとう内容だ。どっちにしても、自動車業界はサプライヤの供給部品を組み合わせて使うサプライチェーンの仕組みは変わらないらしい。安全の考え方も Fault Avoidance をやめるつもりはないようだ。安全機能が複雑化したときのことは考えているのだろうか。

2013-06-01

電子出版された著書2冊

技術評論社から出版されているリアル書籍『リコールを起こさないソフトウェアのつくり方』の電子書籍版がリリースされた。

センセーショナルなタイトルだが、中身は至ってまじめな内容で、なぜ、ソフトウェア品質を高める必要があるのか、ソフトウェア品質を高めるためにはどんな取り組みが必要であるかを地道に解説している。

また、後半では、6/7, 7/19 のSESSAME のソフトウェア安全分析・設計セミナの内容にも通じる ソフトウェアの潜在的な価値を高めるためのアーキテクチャについて解説し、具体的にどうすれば実現できるのかを説明した。

価格はリアル書籍と同じ値段で、PDF形式で提供されるので、電子書籍の方が読みやすい、また、タブレット端末で本を読み慣れている方にはお勧めだ。

【こんな方におすすめ】

  • ソフトウェア開発の初級者の方
  • 新人でこれから目指すべき道筋が見えていない方
  • ハードウェアエンジニアで「なぜ,ソフトウェアは問題を起こすのか」を常々疑問に思っている方
  • ソフトウェアプロジェクトマネージメントの技術を学んでいて,どうして自分のプロジェクトでうまくいかないのか悩んでいる方
  • 組織内でソフトウェア品質問題に頭を抱えている方


次に紹介するのは、CQ出版さんから電子出版された『クリティカル・システムに使う市販ソフトウェアの検証方法』だ。

これは、Tech Village で書いたコラムの記事を精査してPDFにしたもので、90ページ525円となっている。

商用のソフトウェア(OTSソフトウェア)をどうやって検証すればよいのか、またどういった検証記録を作ればいいのかを具体例とともに示したもので、リーズナブルな価格設定なので気軽に購入していただきたい。

【解説】 ソフトウェアに対する安全対策の要求は,航空宇宙産業や軍事産業に始まり,医療機器,自動車など,今や多くの電子機器へと広がっている.これらのセーフティ・クリティカル・システムの開発においては,製品が要求される安全レベルを満たしていることを証明するため,システムの検証結果の提出や,適合証明が求められるようになってきている.そのような中で,システムに組み込むOS やプロトコル・スタック,ファイル・システムなどに市販ソフトウェアやオープン・ソース・ソフトウェアが含まれる場合,これらがシステムに危険を及ぼさないことをどのように確認すればよいのだろうか? 本書では,市販ソフトウェアの使用に際して求められるリスク分析や検証作業,市販ソフトウェアの検証記録の作り方について解説する.

どちらの電子書籍もみなさんの商品の価値を高めることに貢献できることを願っている。