[カテゴリー：ネタ集め中] 調査途中の、とりとめもない記事です。いずれきちんと整理された記事を書くかも分かりません。

自動車ECUを作成する際、ソフトウェアのツールを色々と使う事になります。これまでは好きなツールを使っても良かったのですが、ISO26262が法制化されてしまうと、好き勝手なツールを使う訳にはいかなくなります。きちんとツールを評価した上で、ツール認定レポートなど、いくつかのドキュメントを作成しなくてはいけません。

では、ツール認定レポートを書くにあたり、何をどうする必要があるのでしょうか？

ここでは、ツール認定についてISO/DIS26262-8を読んで勉強した事をまとめてみます。ただし、勉強中の上に独学です。ですから、「あちこち間違ってるんじゃないの？」と半信半疑（？）でご覧下さい。

ツール認定はなぜ必要か？

ISO/DIS26262-8のツール認定の章で気にしている事を一言でいうと、「ツールが誤動作したら、どうするのさ？」だと思います。

ツールが誤動作する事もある、という前提の元に、なんとか危険性をコントロールしないといけません。そのために、ツール認定というものを行うのだと理解しています。

ツール認定の流れ

ツール認定には、３つのパラメータがあります。１つは、TCL（Tool Confidence Level）、もう１つはASIL、そして最後に「ツール評価」です。

TCLとは、「ツールの誤動作のせいで、安全性要求に違反してしまう恐れ」のレベルです。

TCL1　危険なし
TCL2　ちょっと危険あり
TCL3　やや危険あり
TCL4　とても危険あり

というTCL１～TCL４の四段階に分かれます。 （「危険なし」「ちょっと危険あり」「やや危険あり」「とても危険あり」という言葉は、わかりやすいように私が造語しました。ISO/DIS26262-8の正式な表現ではありません）

ASILは、どれくらい重大な安全性要求なのか？です。ASIL D（とても重大）からASIL A（ちょっと重要）まで、４段階に分かれます。（「とても重大」「ちょっと重要」なども、私の造語です。ISO/DIS26262-8の正式な表現ではありません）

TCL1 × ASIL Aの組み合わせが、いちばん安全的に軽いです。一方、TCL4 × ASIL Dの組み合わせがいちばん安全的に重いです。

これらの重さに従って、「ツールの評価」を行います。たとえば、TCL1 × ASIL Aであれば、安全的に軽すぎてツールの評価は必要ありません。一方、TCL４ × ASIL Dであれば、かなり手厚いツール評価が必要になってきます。

TCLとASILに応じた「ツール評価」を行い、ツール認定レポートを作成する

このツール認定レポートによって、このツールは使っても大丈夫なように思われる！という事になれば、やっとそのツールを使う事が出来るようになります。

TCLを決めるには？

２つの切り口

TCLを決めるには、「ツールが誤動作したら、どうするのさ？」という疑問に対して、２つの切り口で分析をします。

1つ目は「ツールの誤動作のせいで、安全性要求に違反しそう？」、２つ目は「ツールの誤動作を予防もしくは検出できそう？」です。

構成

これらを理解するために、まずISO/DIS26262-8で想定されている（と私が感じた）ツール周り構成について整理します。

「ツール」と、「ツール出力をチェックするツール」が登場する

まずは、これから認定しようとしているツールについて着目します。たとえば、コンパイラだったとしましょう。すると、前工程からの入力＝ソースコード、後工程への出力＝バイナリコード　になります。

もしもコンパイラの吐くバイナリコードが本当に正しいのか？が心配なのであれば、それをチェックするためのツールが必要になります。別のコンパイラを走らせて結果を比較するなり、バイナリコードを実行しておかしくないかチェックしたりします。

そんなわけで、「認定したいツール」と、「その出力をチェックするツール」の２つのツールが登場します。

問題が起きるまでの流れ

TCLを決めるために、なぜこの２つの切り口が用意されたのか？を考えてみました。

まず、「ツールの誤動作のせいで、安全性要求に違反しそう？」です。たとえ誤動作しても、別に安全とは関係ないよね？ということであれば、そもそも気にする必要すらありません。（注：あくまで、「機能安全の観点からは、気にする必要が無い」という意味です）

次に、「ツールの誤動作を予防もしくは検出できそう？」です。たとえツールが誤動作しても、それを別のツールで予防・検出できるのであれば、最終的な問題にはつながりません。ツールが誤動作し、なおかつそれを検出しそこねた時にのみ、安全性に関する問題が発生します。

問題が起きるまで

安全性要求に違反しそう？

ツールの誤動作のせいで、安全性要求に違反しそうでしょうか？

これについて、２つのレベルが定義されています。

TI0　そういう可能性はなさそうだ、という議論がなされている
TI1　それ以外

TI ＝ Tool Impact

（日本語部分は造語）

ちょっと具体例が思い浮かびませんが・・・どんな場合なんでしょうね。

具体的にどう決めれば良いのかは、ISO/DIS26262-8では触れられていないように思います。

予防・検出できそう？

ツールの誤動作のせいで、出力に誤りがありました。さて、それをうまく検出できそうでしょうか？

これについては、４つのレベルが定義されています。

TD1　かなりの信頼性でもって、予防・検出できると言える
TD2　中くらいの信頼性でもって、予防・検出できると言える
TD3　低い信頼性でもって、予防・検出できると言える
TD4　それ以外のケース

TD = Tool error Detection

（日本語部分は造語）

どのツールをどの程度のレベルと評価すればいいのかは、よく分かりません。ただ言えるのは、ツール出力をシステマチックの検証 できる仕組みがないのであれば、問答無用でTD4になるという事です。その場合、誤動作がみつかるのは偶然でしかありませんから。

「信頼性」に、かなり、中くらい、低いとありますが、これらをどのように選べばよいかのさじ加減は、ISO/DIS26262-8では触れられていないように思います。

TCLの決定

TI0か１か、TD1～TD4のどれか？この２つのパラメータにより、TCL１～４が決定します。

TCL1　　TI0の場合、もしくはTI1かつTD1の場合
TCL2　　TI1かつTD2の場合
TCL3　　TI1かつTD3の場合
TCL4　　それ以外のすべて

TCL = Tool Confidence Level

これでやっと、TCLが決定しました。

ツールの評価

ツールのTCLが決まり、目標とするASILが分かったなら、いよいよツールの評価です。

ISO/DIS26262-8には、TCL１～４とASIL A～Dのマトリクスで、どの評価方法がお勧めか？が定義されています。

定義されているのは、ラフなものから、手厚いものの順番に次の４つです。

1a　これまで使ってきたからオッケー
1b　開発プロセスの評価
1c　ツールのValidation
1d　Safety standardに従って開発された

「これまで使ってきたからオッケー」というのは、いちばんラフな評価方法です。ただしこれは、担当者の感想ではダメです。どのバージョンのツールをどうつかって、どういう結果になったのか？が全て記録されていない限り、この手はつかえません。

「開発プロセスの評価」は、ツールがCMMIなど一般的なプロセスにしたがって作られているか否か？という判定です。これは、正式にアセスメントを受けていないとダメなようです。

「ツールのValidation」は、誤解を恐れずに書くのであれば、ひたすら色々テストしましょう！という事です。ツールのテストをユーザーがするのも変な感じですが、規格ではユーザー側で使う機能をきちんとチェックしなさい、という風に決められているようです。

「Safety standardに従って開発された」というのは、たとえばISO26262にしたがって開発されたツールです。ただし、その証拠は？たとえばアセスメントが必要なのか？については触れられていません。個人的な予想では、何らかの公式アセスメントをツールベンダーが受けないとダメなのではないかと思います。

TCL1であれば、そもそもツールの評価は必要ありません。

TCL2であれば、ASIL A～Dどれでも、「これまで使ってきたからオッケー」「開発プロセスの評価」のいずれか（もしくは両方）を採用します。

TCL3であれば、ASIL A～Cなら「これまで使ってきたからオッケー」「開発プロセスの評価」、ASIL Dなら「ツールのValidation」「Safety standardに従って開発された」のいずれか（もしくは両方）を採用します。

TCL4であれば、ASIL A～Bなら「これまで使ってきたからオッケー」「開発プロセスの評価」、ASIL C～Dなら「ツールのValidation」「Safety standardに従って開発された」のいずれか（もしくは両方）を採用します。

より細かい情報がISO/DIS26262-8に記載されていますので、そちらを見ていただいたほうが分かりやすいかもわかりません。

認定レポートを書く

ツール評価まですんだら、認定レポートを書きます。（本当は、もっと色々なドキュメントを作成する必要があります。ISO/DIS26262-8をご参照ください）

ツール認定は、外部機関から認証してもらわなくても良い（もちろん、してもらっても良い）との事です。ですから、１回は外部機関の力を借りることになるのでしょうが、それ以降は自力でやっても良さそうです。

まとめ

ツール認定をするには、

• 目標とするASILを決める
• ツールの使われ方によって、TCLを決める
• ASILとTCLに応じて、ツールの評価手法を決め、実施する
• 認定レポートを書く

という流れになります。

おまけ

ツール認定の章を読んでいて思ったのですが、信頼性が高いとか低いとか、かなり曖昧なモノサシが用意されています。

CMMIならそれでも良いのでしょうが、ISO26262は法制化されます。何かあったら裁判にかけられるわけで、これはちょと心配です。

＜妄想＞

欧州で、事故があって裁判になりました。訴状には、「ISO26262に従っていないから事故が起きたんだ！」と書かれています。

パターン１：　裁判官「ほほう、欧州の企業で認定うけたんやな。ヨシャ、信用したろか」

パターン２：　裁判官「あーん？よく分からん島国の企業で認定うけとるのぅ。コリャ信用できんわい。くわしく詮議せんといかんのう（ニヤリ）」

という事がありえるんじゃないか・・・なんて妄想してみました。魚心あれば水心…

＜／妄想＞

基準があいまいということは、見る人のさじ加減1つでどうとでもなるわけで、これはちょっと恐ろしい事のように思います。はてさて、どうしたものでしょうか。