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

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

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

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

セミナー超ざっくり

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

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

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

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

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

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

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

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

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

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

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

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

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

注意：上記はあくまで私（吉武）の解釈です。もしも間違っている点があれば、それは１００％私の理解不足が原因です。

ISO26262導入してみます

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

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