弊社は、自動車業界向けに開発支援ツールを作成させていただいています。これまでは、特別規制などなくやってこられましたが、今後はそうもいかなさそうです。

というのも、ISO26262が法律で義務化されそうな見通しだからです。複数のお客様から、ISO26262が義務化されると開発ツールにも規制が入るとの情報をいただいており、大変に気をもんでいました。

「いったい、ツールベンダーの立場からISO26262とどう関わっていけばいいのでしょうか?」

これが今回のテーマです。どうしたものか・・・と思っていた所に、ESEC2010にて機能安全セミナーが開催されるとの事で、喜んで行ってきました。

セミナー超ざっくり

詳しい内容を全部書くと怒られそうなので、それは講演テキスト要録というものに譲ります。(組み込みシステム開発技術展の専門セミナー全部ふくんで¥80,000だそうです)

ここでは、怒られそうにないくらいに、超いいかげんにまとめてみます。(あんまり信用しないでくださいね。)

まず、ISO26262では安全に関わるいろんな事象をランク分けします。

ASIL D: 超ヤバイ (人が死んじゃいそう、など)
ASIL C: ややヤバイ
ASIL B: まぁまぁヤバイ
ASIL A: ちょっとはヤバイ

という感じで、 ヤバさでA~Dにランク分けします。(具体的なランク分けの仕方は講演テキストに含まれていますので、ご興味のある方はどうぞ)

んで、ISO26262は、ASIL Dの超ヤバイ事象に関しては、こうこうこんな手厚さで開発しなさいね。Cならこれくらい、Bならこれくらい、Aならこれくらい頑張りましょうね、という事が延々と書いてあるそうです。セミナーでは、これらの詳しい話を色々とお聞かせいただきました。

そして問題はツールです。たとえば、自動車メーカーさんがASIL Dの事象についてものすごく頑張ってソフトを作りました。ところが、使ってるツールがヘボくて正しい結果が得られませんでした。結果として事故が起きちゃいました。こんなことになると何をやっているのか分かりません。だから、ツールそのものについてもキチンとしたものを使う必要があります。ツールベンダーからすれば、「うちの製品はキチンとしてますよー」という事を、何らかの形で示さないといけないという事です。

ツールベンダーはどうしたものかな?

セミナーの内容はほぼ自動車メーカーさん、部品メーカーさん目線のものでした。そこで、講師の先生に、迷惑を承知で突撃してきました。

「あのぅ、私、実はツールベンダーなんですけれども。ISO26262だとツールにも認定ってのが必要らしいのですが、どうしたもんでしょうか?」

先生は、イヤな顔ひとつせず色々と教えてくださいました。まとめますと、

  • ISO26262には、「認証」と「認定」がある。「認証」は第三者機関に見てもらう必要があるが、「認定」は自分で宣言してもいい(オレオレ認定書?)
  • ツールに関しては「認定」レベルでもよい
  • オレオレ認定書を作るには、やはりそれなりの根拠は必要。たとえば、ツール自体がISO26262-6(ソフトウェア)に従って作られている、というのも根拠になりうるかも

とのことでした。なるほど!

注意:上記はあくまで私(吉武)の解釈です。もしも間違っている点があれば、それは100%私の理解不足が原因です。

ISO26262導入してみます

もう既に、ISO26262のドラフトがネットで購入できるようになっています。そこで、ISO26262-6(ドラフト)を購入して、開発ツールプロセスに組み入れられないかやってみる事にします。どう考えてもムリという事になれば、業種替えも視野に入れないといけなさそうです。

それにしても、まじめにISO26262を導入するとなると開発支援ツールを作るにもものすごい追加工数が必要になります。その結果、ツールの値段がガンガン上がっていきそう(安価なツールが駆逐されそう)な気がするのですが、いいのかな…