バックナンバーはこちら

today&tomorrow

Technology Update

2018 vol.111

ISO 26262のTCL(Tool Confidence Level)を評価する方法

TCL評価

前のセクションで述べたように、TCLを評価して値を決定する義務を負うのは、そのソフトウェア・ツールのユーザー(エンジニアリング・チーム)です。TCL1の決定基準は主観的なもので、その定義方法はユーザーに委ねられています。ソフトウェア・ツール使用における信頼性を高める方法はいくつもありますが、各ツールに対して十分な受入れ検査/試験を実施してからセーフティ・クリティカルなデザインに使用するというのが一般的です。この試験は、シノプシスが行っている包括的なリグレッション・テストのように、出力が正しいことが確認済みの同様のデザインを実行して行う必要があります(シノプシスは自社およびお客様のテスト・ケースとデザインの両方を使用してすべてのツールに対してリグレッション・テストを実施しています)。お客様によるTCL評価を支援するため、シノプシスはすべてのお客様に対し、このリグレッション・スイートに組み込むためにデザインを提供していただくことをお薦めしています。

ファウンドリも、すべてのルール・パラメータを満たせば正しいシリコンが保証されるため、デザインのインプリメンテーションとサインオフに使用するツールに対して徹底的な認定テストを実施しています。これらのツールには、スタティック・タイミング解析、配置配線、SPICEシミュレータ、LVS/DRCフィジカル検証など、ファウンドリのパラメータ値とルールを使用する設計/検証ツール全般が含まれます。特定のプロセスに対してファウンドリによる認定が行われていれば、顧客によるツール認定の代用として認められます。

ツール・チェーンを使用したTCL評価の例

開発フローを構成する個々のポイント・ツールはTCLの評価が困難なことがあります。ポイント・ツールの信頼性レベルを高める1つの方法として、ポイント・ツールではなくツール・チェーンのTCLを決定するというものがあります。ISO 26262-8:2011 Clause 11.2の「Note」には、個別に使用されるスタンドアロンのソフトウェア・ツールからツール・チェーンに統合された一連のソフトウェア・ツールまでを「ソフトウェア・ツール」と考えてよいと記載されています。ユーザーが作成したスクリプトもツール・チェーンの一部であり、ツール・チェーンのTCL評価に含められます。

たとえば、ある合成ツールを単独で考えた場合、ユーザーはこのツールによって誤ったロジックが挿入されていないという確証を持てないため、このツールの出力にTCL2またはTCL3を割り当てます。合成ツール出力の正しさに対する信頼レベルを高めるには、入力RTLまたはネットリストと出力ネットリストを独立したフォーマル検証によって比較するという方法があります。また、スタティック・タイミング解析とダイナミック・ゲートレベル・シミュレーションを使用しても、合成ツール出力の信頼性を高めることができます。ツール・チェーンを使用して全体のTCLを決定する場合、TCLを決定したユース・ケースとしてそのチェーン(すべてのツールとスクリプトを含む)を文書に記録する必要があります。ツール・ユーザーとセーフティ・マネージャーは、これらの比較/チェックをどの程度まで実施するのか、そしてどのような定量値(もしあれば)を満たす必要があるのかを決定する必要があります。これらはすべてツール・チェーンの文書に含める必要があります。

図3は、ツール・チェーンを使用して全体的なTCLを決定する方法の例を示したものです。この例では、合成ツールの出力(ネットリストA)を等価性検証およびスタティック・タイミング解析ツールでチェックします。これらのチェックが正しく完了すれば、合成ツール・チェーンの出力をTCL1に引き上げることも可能です。この場合、必要なツール・チェーンを「合成+等価性チェック+スタティック・タイミング解析=ネットリストA」として文書に記録します。

画像

図3:ツール・チェーンを使用してTCLを高める方法

すべてのツールをTCL1に分類する必要があるのか

これはよく誤解される点ですが、ISO 26262 Part 8 Clause 11「ソフトウェア・ツール使用における信頼性」の目標は、SoC 開発フローに含まれるすべてのツールをTCL1と評価することではありません。

本当の目標は、使用しているソフトウェア・ツールがエラーを混入しない、またはエラーの検出に失敗しないことに高い確信を持てるような開発フローを構築および説明することにあります。ツールによってはTCL1に評価できないこともあります。その場合は、当該ソフトウェア・ツールの認定を実施する必要があります。

事実、TCL2またはTCL3と評価されたソフトウェア・ツールも適切な認定を実施すれば使用してもかまいません。どのような認定方法が必要かは、ISO 26262-8:2011のTable 4(TCL3の場合)およびTable 5(TCL2の場合)に記載されています。使用する方法はTCL2もTCL3も同じで、どの方法が推奨されるかはASIL分類によって異なります。図4はTable 4とTable 5の内容をまとめたもので、強く推奨される方法を緑で示しています。説明は図の下に示しています。

画像

図4:ソフトウェア・ツールの認定方法

1a 利用実績

オートモーティブSoCの開発経験がある企業なら、過去に類似のデザインで使用したEDAツールの履歴を完全に文書化したことがあるでしょう。このような場合、利用実績に基づいてツールを認定できます。1aの方法では、過去に同様のユース・ケース、動作環境、構成で同じ目的にツールを使用したことがあり、その後ツールの仕様が変更されていないことを示すエビデンスが要求されます。また、過去の開発期間またはリリースにおいてソフトウェア・ツールで発生した機能不良およびそれに伴う出力エラーを蓄積し、体系的に文書化することも要求されます。まったく新しいデザインで初めて使用するEDAツールの場合、または最後に使用してからツールに大幅な変更があった場合は、1aの認定方法は適切でありません。

1b ツール開発プロセスの評価

この方法は、ツール・サプライヤの内部開発プロセスへのアクセスを必要とします。通常、ツール開発プロセスの評価は適切な国内または国際標準認証機関によって実施されます。シノプシスは検査、検証、試験、認証分野をリードするSGS TÜV Saar社と共同で自社のツール開発プロセスの多くを独自に評価し、これらの評価結果をご提供することでお客様によるツール認定作業の負担軽減を図っています。

カテゴリートップ