自動車業界では、MATLAB/Simulinkをベースとしたモデルベース開発が有望視されています。言うと、適用方法によってはそれなりに工数削減や品質向上が出来ると言う事が実証されてきたからです。一方ではモデルベース開発によって逆に工数が増加してしまうケースもあり、まだまだ課題が山積みです。これは、ユーザー様にとっては課題が山積みと言えますが、私にとっては仕事のネタが山積みとも言えます。このブログでは、そういったモデルベース開発に関わっていく中で思った事について書いていきます。更新日は月曜日+気が向いた日です。調査途中の、とりとめもない記事です。整理された記事を書くかも分かりません。自動車ECUを作成する際、ソフトウェアのツールを色々と使う事になります。これまでは好きなツールを使っても良かったのですが、ISO26262が法制化されてしまうと、好き勝手なツールを使う訳にはいかなくなります。ツールを評価した上で、ツール認定レポートなど、いくつかのドキュメントを作成しなくてはいけません。ツール認定レポートを書くにあたり、何をどうする必要があるのでしょうか?ここでは、ツール認定についてISO/DIS26262-8を読んで勉強した事をまとめてみます。勉強中の上に独学です。「あちこち間違ってるんじゃないの?」と半信半疑(?)でご覧下さい。ツール認定はなぜ必要か?ISO/DIS26262-8のツール認定の章で気にしている事を一言でいうと、「ツールが誤動作したら、どうするのさ?」だと思います。ツールが誤動作する事もある、という前提の元に、なんとか危険性をコントロールしないといけません。そのために、ツール認定というものを行うのだと理解しています。ツール認定の流れツール認定には、3つのパラメータがあります。Level)、もう1つはASIL、そして最後に「ツール評価」です。TCLとは、「ツールの誤動作のせいで、安全性要求に違反してしまう恐れ」のレベルです。危険ありというTCL1~TCL4の四段階に分かれます。(「危険なし」「ちょっと危険あり」「やや危険あり」「とても危険あり」という言葉は、わかりやすいように私が造語しました。ISO/DIS26262-8の正式な表現ではありません)ASILは、どれくらい重大な安全性要求なのか?です。A(ちょっと重要)まで、4段階に分かれます。(「とても重大」「ちょっと重要」なども、私の造語です。Aの組み合わせが、いちばん安全的に軽いです。Dの組み合わせがいちばん安全的に重いです。これらの重さに従って、「ツールの評価」を行います。Aであれば、安全的に軽すぎてツールの評価は必要ありません。Dであれば、かなり手厚いツール評価が必要になってきます。TCLとASILに応じた「ツール評価」を行い、ツール認定レポートを作成するこのツール認定レポートによって、このツールは使っても大丈夫なように思われる!という事になれば、やっとそのツールを使う事が出来るようになります。TCLを決めるには?2つの切り口TCLを決めるには、「ツールが誤動作したら、どうするのさ?」という疑問に対して、2つの切り口で分析をします。1つ目は「ツールの誤動作のせいで、安全性要求に違反しそう?」、2つ目は「ツールの誤動作を予防もしくは検出できそう?」です。構成これらを理解するために、まずISO/DIS26262-8で想定されている(と私が感じた)ツール周り構成について整理します。「ツール」と、「ツール出力をチェックするツール」が登場するまずは、これから認定しようとしているツールについて着目します。コンパイラだったとしましょう。コンパイラの吐くバイナリコードが本当に正しいのか?が心配なのであれば、それをチェックするためのツールが必要になります。別のコンパイラを走らせて結果を比較するなり、バイナリコードを実行しておかしくないかチェックしたりします。そんなわけで、「認定したいツール」と、「その出力をチェックするツール」の2つのツールが登場します。問題が起きるまでの流れTCLを決めるために、なぜこの2つの切り口が用意されたのか?を考えてみました。「ツールの誤動作のせいで、安全性要求に違反しそう?」です。誤動作しても、別に安全とは関係ないよね?ということであれば、そもそも気にする必要すらありません。(注:あくまで、「機能安全の観点からは、気にする必要が無い」という意味です)次に、「ツールの誤動作を予防もしくは検出できそう?」です。ツールが誤動作しても、それを別のツールで予防・検出できるのであれば、最終的な問題にはつながりません。ツールが誤動作し、なおかつそれを検出しそこねた時にのみ、安全性に関する問題が発生します。問題が起きるまで安全性要求に違反しそう?ツールの誤動作のせいで、安全性要求に違反しそうでしょうか?これについて、2つのレベルが定義されています。Impact(日本語部分は造語)ちょっと具体例が思い浮かびませんが・・・どんな場合なんでしょうね。具体的にどう決めれば良いのかは、ISO/DIS26262-8では触れられていないように思います。予防・検出できそう?ツールの誤動作のせいで、出力に誤りがありました。それをうまく検出できそうでしょうか?これについては、4つのレベルが定義されています。Detection(日本語部分は造語)どのツールをどの程度のレベルと評価すればいいのかは、よく分かりません。できる仕組みがないのであれば、問答無用でTD4になるという事です。その場合、誤動作がみつかるのは偶然でしかありませんから。「信頼性」に、かなり、中くらい、低いとありますが、これらをどのように選べばよいかのさじ加減は、ISO/DIS26262-8では触れられていないように思います。TCLの決定TI0か1か、TD1~TD4のどれか?この2つのパラメータにより、TCL1~4が決定します。Levelこれでやっと、TCLが決定しました。ツールの評価ツールのTCLが決まり、目標とするASILが分かったなら、いよいよツールの評価です。A~Dのマトリクスで、どの評価方法がお勧めか?が定義されています。定義されているのは、ラフなものから、手厚いものの順番に次の4つです。standardに従って開発された「これまで使ってきたからオッケー」というのは、いちばんラフな評価方法です。これは、担当者の感想ではダメです。どのバージョンのツールをどうつかって、どういう結果になったのか?が全て記録されていない限り、この手はつかえません。「開発プロセスの評価」は、ツールがCMMIなど一般的なプロセスにしたがって作られているか否か?という判定です。これは、正式にアセスメントを受けていないとダメなようです。「ツールのValidation」は、誤解を恐れずに書くのであれば、ひたすら色々テストしましょう!という事です。ツールのテストをユーザーがするのも変な感じですが、規格ではユーザー側で使う機能をきちんとチェックしなさい、という風に決められているようです。standardに従って開発された」というのは、たとえばISO26262にしたがって開発されたツールです。その証拠は?たとえばアセスメントが必要なのか?については触れられていません。個人的な予想では、何らかの公式アセスメントをツールベンダーが受けないとダメなのではないかと思います。TCL1であれば、そもそもツールの評価は必要ありません。A~Dどれでも、「これまで使ってきたからオッケー」「開発プロセスの評価」のいずれか(もしくは両方)を採用します。standardに従って開発された」のいずれか(もしくは両方)を採用します。standardに従って開発された」のいずれか(もしくは両方)を採用します。細かい情報がISO/DIS26262-8に記載されていますので、そちらを見ていただいたほうが分かりやすいかもわかりません。認定レポートを書くツール評価まですんだら、認定レポートを書きます。(本当は、もっと色々なドキュメントを作成する必要があります。ISO/DIS26262-8をご参照ください)ツール認定は、外部機関から認証してもらわなくても良い(もちろん、してもらっても良い)との事です。1回は外部機関の力を借りることになるのでしょうが、それ以降は自力でやっても良さそうです。目標とするASILを決めるツールの使われ方によって、TCLを決めるASILとTCLに応じて、ツールの評価手法を決め、実施する認定レポートを書くという流れになります。おまけツール認定の章を読んでいて思ったのですが、信頼性が高いとか低いとか、かなり曖昧なモノサシが用意されています。CMMIならそれでも良いのでしょうが、ISO26262は法制化されます。何かあったら裁判にかけられるわけで、これはちょと心配です。<妄想>欧州で、事故があって裁判になりました。訴状には、「ISO26262に従っていないから事故が起きたんだ!」と書かれています。裁判官「ほほう、欧州の企業で認定うけたんやな。裁判官「あーん?よく分からん島国の企業で認定うけとるのぅ。コリャ信用できんわい。くわしく詮議せんといかんのう(ニヤリ)」という事がありえるんじゃないか・・・なんて妄想してみました。魚心あれば水心...</妄想>基準があいまいということは、見る人のさじ加減1つでどうとでもなるわけで、これはちょっと恐ろしい事のように思います。はてさて、どうしたものでしょうか。コメントを投稿して頂くには、JavascriptとCookieを有効にしていただく必要がございます。