News and Views 2016 Winter / Vol. 16: 上流設計&組込み

エミュレーションを用いたISO 26262準拠プロセッサ検証

はじめに

自動車の機械システムは、アンチロックブレーキシステム(ABS)、電子スロットルシステム、アダプティブクルーズコントロールなどをはじめ、その多くが電子制御の対象となっています。いわゆるドライブバイワイヤ(DBW)が進み、さらにインフォテイメントやコネクテッドカー、サラウンドビューモニタなどを含めると、最も電子化が進んだ車種では1台あたりの車載ソフトウェアは1億行を超えたとも言われています。

クルマに搭載されるソフトウェアは、ECUに含まれるプロセッサ上で稼働します。機能安全の国際標準であるISO 26262では、ソフトウェア、ハードウェア、それらを統合したシステムに対する安全のためのガイドラインを規定しています。膨大な量のソフトウェアを支えるハードウェアとしてのプロセッサに課せられる安全要件を満たすには、故障注入による検証が必須要件となります。

実際、ハードウェアとしてのプロセッサは、外部要因である電磁干渉や放射線による故障や誤作動のリスクに晒されています。これらの原因を詳細にモデリングして評価するよりも、故障注入を用いた検証がより効果的であり、これはISO 26262の中でも推奨されている手法です。

プロセッサの耐故障性を高める方法

プロセッサの耐故障性を高める方法には、専用のRad Hard(Radiation Hardening)プロセスを用いる方法からハードウェアを冗長化させるアプローチまでさまざまです。それぞれに一長一短がありますが、ここではその中からソフトウェアの冗長化とハードウェアの冗長化により安全性を得る方法について紹介しましょう。

  • SIFT: Software Implemented Fault Tolerance
    実行するソフトウェアの全体もしくは一部を複数回実行させ、冗長化させるアプローチです。命令レベルの冗長化では個々の命令を2回実行し、別の命令により結果を比較します。プロシージャレベルの冗長化では特定のプロシージャを2回実行し、結果を比較します。相異が検出されるとソフトウェアによるリカバリを行います。コスト的には高くつきませんが、複数回実行というオーバーヘッドによる性能低下が短所となります。
  • DMR: Dual Modular Redundancy
    同じプロセッサを2つ実装し、その結果を特別なハードウェアで比較します。相異のリカバリはソフトウェア処理となり、基本的にはソフトウェア制御により計算をキャンセルし、再実行させる手法です。比較的安価で実現できますが、結果比較はサイクル単位で行うため、プロセッサをクロックサイクルごとに強制的に実行させることで性能低下を引き起こします。
  • TMR: Triple Modular Redundancy
    図1. マルチキャスト通信図1. Triple Modular Redundancyの構成プロセッサを三重化構造にし、図1.にあるように多数決回路により結果を決定する仕組みです。高性能を実現できる反面、消費電力やシリコン面積でのデメリットがあります。また、多数決回路として特別なハードウェアが必要になります。
  • TTMR: Time Triple Modular Redundancy
    この手法ではVLIW(Very Long Instruction Word: 超長命令語)により高速化可能なプロセッサを使用します。VLIWは、依存関係のない複数の命令を1つの命令ストリームとして並列実行させます。同一のVLIWプロセッサ内で個々の命令を3回実行し、結果を比較します。三重化構造により耐故障性と性能を両立させることができますが、コストが高くつくことやVLIWプロセッサに限定されることがデメリットになります。

エミュレータを用いた故障注入によるプロセッサの検証

図2. Veloce 2ハードウェアエミュレーションプラットフォーム図2. Veloce 2ハードウェアエミュレーションプラットフォーム
図3. Nucleus RTOSのパワーマネジメント図3. 故障注入テストベンチの構成

故障注入を用いてシステムを検証するには、シミュレーションやFPGAプロトタイプ、エミュレーションなどが考えられます。メンター・グラフィックスが提供するVeloceなどの最先端エミュレーションプラットフォームを用いると、故障モデルと故障注入メカニズムの両方を完全に制御でき、全ノードの観測が可能になります。リアルタイムの故障に対応しつつ充分な制御性と可視性が得られるエミュレーションは、故障注入を用いた検証手法として理想的と言えます。

以下に、Veloceを用いた故障注入の仕組みについて説明します。

  • セットアップ
    注入する故障の分布には、一様的なランダム、アクティビティに基づいたランダム、マニュアルで直接指定する手法があります。アクティビティに基づいたランダムの場合、一度テストを実行し、SAIF(Switching Activity Interchange Format)というフォーマットで測定します。そこからフリップフロップ(FF)のサブセットを抽出し、故障を注入します。最後に、ゴールデンモデルのDUTと故障を注入したDUTをトップにインスタンス化し、図3.に示すようなテストベンチと接続します。
  • エミュレーション
    ゴールデンモデルと故障注入モデルを実行し、すべてのインタフェース信号を取得、記録します。
  • 評価
    結果を比較し、解析、レポートを行います。

まとめ

故障注入は、ISO 26262でも推奨されている検証手法です。特にプロセッサの場合は、ソフトウェアによる手法とハードウェアの手法を駆使して耐故障性を引き上げることができます。それぞれにメリットとデメリットがあるため、市場戦略や機能安全に関するOEMとの合意などを基に、どの手法で耐故障性を上げていくかを決めていく必要があります。そしてもちろん、耐故障性が上がっていることは故障注入により検証しなくてはなりません。Veloceのように観測性と可視性に優れ、かつトランザクションベースでテストシーケンスや分析、カバレッジ、レポートが自動化できるエミュレーションシステムを用いることにより、効率的に故障注入による検証を進めることが可能です。