ISO26262と自動コード生成ツール

自動コード生成ツールについて、ちょっと小ネタを。

ISO26262では、開発ツールについても認定が必要な場合があります。しょうもないツールを使ってたら、安全が確保できなくなりますよ！という話です。

ISO/DIS26262とツール認定で書いた通り、ツール認定にはいくつかの方法があります。ツール認定というのは、「ツールが誤動作したら、どうすんのさ！」という疑問にこたえるためのものです。

ツールを認定するには、大雑把に３つのパスがあります。

１．ツールが誤動作しても、安全性要求には違反しない
２． ツールが誤動作しても、他のツールやプロセスでカバーできる
３． ツール自体がものすごく信頼性がある（ツール自体が、ISO26262準拠で作られている、など）

誤動作したら、ものすごくヤバいものの代表格がコンパイラですが、それに次いでヤバイのがモデルの自動コード生成ツールです。

現在、コード生成ツールの代表格と言えば、TargetLink（dSPACE社）、Realtime-Workshop Embedded Coder（The MathWorks社）の２つで、勢力図としては半々くらいのように見えます。

これらは、どちらもISO26262準拠をうたっていますが、いったいどういうパスで準拠したのでしょうか？

Realtime-Workshop Embedded Coderでは、PolySpace製品と組み合わせて使う事で、ISO26262に準拠しているみたいです。上の３択でいくと２番の、「ツールが誤動作しても、他のツールやプロセスでカバーできる」という所ですね。

一方、TargetLinkの方はTargetLinkがISO26262の認証を取得としかWeb上には情報がありません。３択でいうところの、どれなのかな・・・？と疑問に思っていたのですが、つい先日情報が得られました。どうやら、TargetLinkの場合も２番の、「ツールが誤動作しても、他のツールやプロセスでカバーできる」というパスで認証取得した模様です。MESさんやBTCさんなどのツールと組み合わせる事が前提みたいです。（ちょっと情報が怪しいかも。正確に、ISO26262のためにどんなプロセスやツールが必要なのかは、dSPACEさんに問い合わせてください）

ここから先は個人的な意見です。

ISO26262のツール認定のキモは、「ツールが誤動作したら、どうすんのさ！」という所です。これをタテにとって、うちのツールを使いたいなら、ついでにあのツールも買いなさい、このツールも買いなさいという話になるのは、ツールベンダーとしてはオイシイ話です。しかし、ユーザーにしてみれば、どゆこと？と思えるのではないでしょうか。

少なくとも、ユーザーはそれぞれに独自の社内プロセスを持っているわけで、一方的なツールのお仕着せは良くない。かといって、自動コード生成ツールをISO26262に従って作れ！というのも現実的ではない。じゃあどうするかというと、せめて市販のツールをユーザーが自由に組み合わせられるようにするべきだと思います。

そしてこれは、現在のISO26262の枠組みのなかで普通に実現可能な事だと思います。ツール認定をベンダーがやらないといけないケースは、３番の「ツール自体がものすごく信頼性がある（ツール自体が、ISO26262準拠で作られている、など）」だけだと思います。（個人的意見です）

ですから、「ツールが誤動作しても、他のツールやプロセスでカバーできる」という主張をするだけであれば、ユーザーにとってベストなツールチェーンやプロセスを用意した上で、「このツールチェーンなら、自動コード生成の不具合があっても、後工程で検出できるよね？」という確認を取れば良い。そのための認定作業は、TUVさんなどに手伝ってもらえば良いのではないでしょうか。

（ISO26262では、「認証」と「認定」は区別されます。「認証」は第三者機関に見てもらう必要がありますが、「認定」は自分で宣言してもOKです。そして、ツールは「認定」レベルでも良いとされています。ですから、TUVさんに手伝ってもらって、自前のツールチェーンを「認定」するのは、アリだと思います）

まぁ、私がお話するユーザーさんは、たいがい私なんかよりはるかにISO26262に詳しくって、対策も十分に進んでいるように思えます。ですから、私がここで落書きしても意味がないような気もしますけどね・・・ふぅ。