JP2013003633A - 故障再現装置、故障再現方法 - Google Patents

Abstract

【課題】短時間でＣＰＵコアの十分な検出率の故障を検出することが可能な故障再現装置を提供すること。
【解決手段】故障再現装置は、影響の現れる命令と影響が現れた後の命令が故障内容に対応づけて登録された故障ライブラリ１１と、アプリを記憶したアプリケーション記憶手段３６と、アプリをＣＰＵが実行した際の動作を別々にシミュレートする第１のシミュレート手段５５及び第２のシミュレート手段５６と、第１のシミュレート手段が影響の現れる命令を実行したことを検出して、アプリの実行を中断させると共に第２のシミュレート手段に通知する実行検出手段１２と、前記第２のシミュレート手段に影響の現れる命令と対応づけられた影響が現れた後の命令を実行させる命令置き換え手段１３と、を有し、第１のシミュレート手段が第２のシミュレート手段が実行した影響が現れた後の命令の実行結果を引き継いでアプリの実行を再開する。
【選択図】図１

Description

本発明は、マイコンの故障を再現する故障再現装置に関し、特に、故障率の定量化が可能な故障再現装置に関する。

電子装置に対し安全性を保証する機能安全という考え方がある。車載された電子装置の場合、ＩＳＯ２６２６２に機能安全規格が定められており、準拠するためには搭載する半導体や電子部品についてもさまざまなことが求められている。例えば、ＩＳＯ２６２６２では、想定されるハザード（潜在的な好ましくない事象）のレベル（ASIL）に対し目標故障率と故障検出率が定められている。

目標故障率は単位時間当たりに生じる最大故障数であり、故障検出率は、発生した故障を検出する安全機構を組み込んでおき、安全機構によって故障を検出できる確率である。故障検出のための安全機構としてよく知られているのが、ＲＡＭやフラッシュメモリーなどに配置される誤り検出訂正回路や自己診断回路である。

また、ＣＰＵコアの場合、複数のコアが同じ処理を行い、処理結果が同じだった場合に有効な実行結果とするデュアルロックステップ方式の安全機構が知られている。しかしながら、デュアルロックステップ方式ではＣＰＵコアが複数必要になるため、コスト増になってしまう。そこで、ゲートレベルで故障を検出して故障検出率を上げる試みがある。

しかしながら、ＣＰＵコアのような集積回路は部品数（トランジスタ数）が膨大であり、例えば、開発者がある回路の故障を設定した場合に、故障がどのように伝播するかをゲートレベルでトレースする（設計図面を辿る）などして物理的に検査することは困難である。このため、ＣＰＵコアの故障の検出として故障シミュレータを用いる手法が知られている（例えば、特許文献１参照。）。特許文献１には、テストパターンを用いて被試験ＩＣを動作させた時の回路内部の各信号線に生じる遷移信号値列を遷移シミュレーションにより求めておき、テストパターンにより検出可能な故障リストを作成する故障シミュレーション方法が開示されている。

特開２００２−００７５０８号公報

しかしながら、特許文献１に記載された手法で故障リストを作成しても、被試験ＩＣの故障を検出する際には、ゲートレベルでテストパターンを入力し、入力された信号がトランジスタにどのように伝播していくかを監視（トレース）する必要がある。信号は１サイクル毎（動作クロック毎）に伝播するため、全てのゲートの動作を1サイクルずつシミュレートするのではかなりの時間を要してしまう。

ここで、ＣＰＵコアの故障の検出は、ＣＰＵコアが実行するアプリケーションソフトの動作と関連づけることが有効であると考えられる。すなわち、例えばシミュレータが、
あるＣＰＵコアでアプリケーションソフトを実行した場合に、ＣＰＵコアに故障が発生するとアプリケーションソフトの動作にどのような障害が現れるか（又は現れないか）を調べておく。これにより、シミュレータがＣＰＵコアのゲートレベルの故障の伝播を網羅的にトレースしなくても、ＣＰＵコアの故障をアプリケーションソフトの動作から検出することができる。

しかし、この場合でも、アプリケーションソフトの命令毎にゲートレベルの動作の伝播をトレースする必要があるため、アプリケーションソフトの規模が比較的大きくない中規模程度の場合でもシミュレーションに数ヶ月必要になる。

このように、従来、デュアルロックステップ以外に、十分な検出率にてＣＰＵコアの故障を検出する実用的な手法がなかった。

本発明は、上記課題に鑑み、短時間でＣＰＵコアの故障を比較的高い検出率で検出することが可能な故障再現装置を提供することを目的とする。

本発明は、ＣＰＵ内に故障が発生した場合に、影響の現れる命令と影響が現れた後の命令が故障内容に対応づけて登録された故障ライブラリと、アプリケーションソフトを記憶したアプリケーション記憶手段と、前記アプリケーションソフトを前記ＣＰＵが実行した際の動作を別々にシミュレートする第１のシミュレート手段及び第２のシミュレート手段と、前記第１のシミュレート手段が前記影響の現れる命令を実行したことを検出して、前記アプリケーションソフトの実行を中断させると共に前記第２のシミュレート手段に通知する実行検出手段と、前記実行検出手段から前記第１のシミュレート手段が前記影響の現れる命令を実行したという通知を取得し、前記第２のシミュレート手段に、前記影響の現れる命令と対応づけられた前記影響が現れた後の命令を実行させる命令置き換え手段と、を有し、前記第１のシミュレート手段は、前記第２のシミュレート手段が実行した前記影響が現れた後の命令の実行結果を引き継いで、前記アプリケーションソフトの実行を再開する、ことを特徴とする。

短時間でＣＰＵコアの十分な検出率の故障を検出することが可能な故障再現装置を提供することができる。

故障再現装置の概略動作を説明する図の一例である。 故障ライブラリの作成を模式的に説明する図の一例である。 ＥＣＵによる処理を模式的に説明する図の一例である。 ＣＰＵコアの構成を概略的に示す図の一例である。 命令セットの一例を示す図である。 故障再現装置のハードウェア構成図の一例である。 一般的なＣＰＵシミュレータの機能ブロック図の一例である。 本実施形態の故障再現装置の機能ブロック図の一例である。 故障再現装置が故障を再現する手順を示すフローチャート図の一例である。

以下、本発明を実施するための形態について図面を参照しながら説明する。
図１は、故障再現装置１００の概略動作を説明する図の一例である。本実施形態の故障再現装置１００は、故障箇所の再現に故障ライブラリ１１を利用する。故障ライブラリ１１の作成方法は後述するが、故障ライブラリ１１には、「故障時に影響が現れる動作」と「故障が現れた後の動作」が、故障部位に対応づけて登録されている。
故障時に影響が現れる動作：何らかの故障が生じている状態で実行されると動作に影響を及ぼす命令（本来そのまま実行されることが意図された命令）
故障が現れた後の動作：「故障時に影響が現れる動作」により引き起こされる意図しない命令
故障再現装置１００は２つのＣＰＵシミュレータ２００（以下、区別する場合、ＣＰＵシミュレータ１、２という）を有する。ＣＰＵシミュレータ１は、アプリケーションソフトを実行するＣＰＵシミュレータであり、照合モジュールにより「故障時に影響が現れる動作」を実行するか否かが監視される。ＣＰＵシミュレータ２は、ＣＰＵシミュレータ１よりも数クロック遅れながら同じアプリケーションソフトを実行する。数クロック遅れて実行するのは、照合モジュール１２によりＣＰＵシミュレータ１が「故障時に影響が現れる動作」が実行したと検出された時、ＣＰＵシミュレータ１はすでに「故障時に影響が現れる動作」を実行しているためである。よって、ＣＰＵシミュレータ２は、「故障時に影響が現れる動作」を、「故障が現れた後の動作」で置き換える時間的な余裕がある。

上記のように、ＣＰＵシミュレータ１がアプリケーションソフトを実行している間、照合モジュール１２は、ＣＰＵシミュレータ１が実行する命令が、故障ライブラリ１１に登録された「故障時に影響が現れる動作」と一致するか否かを連続的（１ステップ毎）に照合する。一致した場合、照合モジュール１２は、「故障時に影響が現れる動作」が検出されたことを故障挿入モジュール１３に通知する。

故障挿入モジュール１３は、ＣＰＵシミュレータ２によるアプリケーションソフトの実行を中断させ、故障ライブラリ１１から読み出した「故障が現れた後の動作」をＣＰＵシミュレータ２が実行する予定だった「故障時に影響が現れる動作」と置き換える。したがって、ＣＰＵシミュレータ２は、故障部位が故障していた場合の動作を再現することができる。ＣＰＵシミュレータ２が「故障が現れた後の動作」を実行すると、故障挿入モジュール１３はＣＰＵコア２の動作を一時中断し、ＣＰＵシミュレータ２のコンテキストをＣＰＵシミュレータ１に通知する。

ＣＰＵシミュレータ１は、ＣＰＵシミュレータ２の動作終了時の状態からアプリケーションソフトの実行を再開する。ＣＰＵシミュレータ２も、ＣＰＵシミュレータ１から数クロック遅れてアプリケーションソフトの実行を再開する。

したがって、ＣＰＵシミュレータ１は、故障部位が故障していた場合のアプリケーションソフトの動作を再現したことになる。実際にＣＰＵコアが故障していなくても故障した状態でＣＰＵコアがアプリケーションソフトを実行したことになるので、ＣＰＵコアの故障時にアプリケーションソフトがどのような動作を行うかをシミュレートすることができる。ＣＰＵシミュレータ１には、一般的な機能としてレジスタなどの値を記録するログ機能等が搭載されている。これから、アプリケーションソフトの動作を検証すれば（正常動作時との比較など）、故障再現装置１００は故障がアプリケーションソフトの動作に与えた影響を定量化して、故障検出率等を算出することができる。

〔故障ライブラリ〕
図２は、故障ライブラリ１１の作成を模式的に説明する図の一例である。故障ライブラリ１１の作成は、開発者がＣＰＵコアの設計図を見ながら作成することもできるが、ＣＰＵシミュレータ２００を使用することが効率的である。図示するように、ＣＰＵシミュレータ２００は、コンピュータ（パーソナルコンピュータやワークステーション）である。後述するようにＣＰＵシミュレータ２００は、車載対象のＣＰＵコアの動作をソフトウェアで模擬的に再現する。ＣＰＵシミュレータ２００にはＣＰＵコア設計図に基づくゲートレベルの素子、回路、及び、ゲートレベルの素子の接続状況、がデータとして記憶されている。また、ＣＰＵコアは、実行可能な命令の集合である命令セットが決められている。命令はアセンブラ言語（又は機械語）で記述され、各種の算術演算や論理演算などが用意されている。また、ＣＰＵコアでは命令毎にオペランドに記述可能なアドレス指定モード（絶対アドレス指定，レジスタアドレス指定，即値アドレス指定，インデックスアドレス指定等）が定められている。したがって、１つの命令のオペランドに記述可能なアドレス指定モードを組み合わせることで、命令毎に漏れのない故障シミュレーションが可能になる。

図３は、ＥＣＵ３００による処理を模式的に説明する図の一例である。一般的なＥＣＵ（Electronic Control Unit）３００は、ＲＯＭに記憶されたアプリケーションソフトをＣＰＵコアで実行しながら、各種の入力インタフェース（Ａ／Ｄ変換器、Ｉ／Ｏ、車載ＬＡＮ用の通信装置等）から入力されるアナログ信号やデジタル信号を処理し、出力インタフェース（Ｄ／Ａ変換器、Ｉ／Ｏ、車載ＬＡＮ用の通信装置等）からＰＷＭ信号、オン・オフ信号などを出力する。

アナログ信号には、センサの検出信号や制御対象物の状態を表す電圧値や電流値がある。デジタル信号は、各種のスイッチのオン／オフ、操作位置に対応したＨレベル又はＬレベルの信号、車速パルス等である。アクチュエータは、スロットルモータ、ブレーキ液圧ポンプモータ、電動パワステモータ等であり、ソレノイドは燃料噴射弁等の各種の弁であり、リレーはバッテリからの給電を開始するメインリレーやＡＣＣリレー等である。

図４は、ＣＰＵコア２１の構成を概略的に示す図の一例である。ＣＰＵコア２１は、バスに接続されたＰＣ（プログラムカウンタ）２２、プログラムメモリ２３、データメモリ２６、レジスタファイル２７、及び、ＡＬＵ（arithmetic logical unit）２９等を有する。また、ＣＰＵコアにはバスを介して各種の周辺機器（ＩＮＴＣ、ＷＤＴ、Ａ／Ｄ、Ｄ／Ａ等）が接続される。

ＣＰＵコアが命令を実行する際、ＰＣ２２が示すアドレスの命令が命令バスを介して命令レジスタ２４に読み込まれ、命令デコーダ２５でデコードされる。命令デコーダ２５は命令の種類を判別し、また、オペランドのアドレス指定モードを判別し、実効アドレスを算出することで、不図示のシーケンサに各ゲートや回路の制御信号を出力させる。データメモリ２６には、演算対象のデータや演算中のデータが記憶される。レジスタファイル２７には、汎用レジスタ$0〜$7が配置されており、各種の演算に使用されるデータが一時的に記憶される。マルチプレクサ２８は、制御線の状態に応じてデータメモリ２６又は汎用レジスタの一方をＡＬＵ２９に出力する。なお、マルチプレクサ２８の入力側が命令デコーダ２５と接続されているのは、ジャンプ命令やサブルーチンコールの際、ＡＬＵ２２がＰＣ２２にアドレスを記憶するためである。この時、スタックポインタレジスタ（不図示）に元の処理に戻るためのアドレスが記憶される。

ＡＬＵ２９は、制御信号の状態に応じて、レジスタファイル２７やデータメモリ２６の２つの入力の少なくとも一方を使用して加算、減算、乗算、除算などの算術演算を実行する。また、不図示の論理演算回路が論理演算することもある。検算結果はレジスタファイル２７やデータメモリ２６に書き込まれる。また、ＡＬＵ２９の他に又はＡＬＵ２９と一体にシフト演算するシフタを有していてもよい。ＡＬＵ２９の演算結果によりステータス３０には、演算結果がゼロであることや負であることを示すための“１”，“０”が設定される。

図５は命令セットの一例を示す図である。ＣＰＵコアが実行可能な、算術演算子（ADD SUB MUL DIV REM）、ビット演算子（NOT AND OR XOR）、シフト演算子（SLL SRL SRA）、ロード（LD）、ストア（ST）、データ代入（MOVE）、ポップ（POP）、プッシュ（PUSH）、コール（CALL）、ジャンプ（JMP）、条件分岐（BEQZ）、ノンオペレーション（NOP）が登録されている。

図５では各命令の記述例を示したが、一命令のアドレス指定モードは１つとは限らない。例えば、算術演算子では、絶対アドレス指定，レジスタアドレス指定，即値アドレス指定及びインデックスアドレス指定が可能であり、データ代入には、レジスタアドレス指定と即値アドレス指定が可能である。ＣＰＵシミュレータ２００には、各命令で可能なアドレス指定モードが登録されており、その全ての組み合わせで１つの命令を実行できるようになっている。

本実施形態のＣＰＵシミュレータ２００は、故障をシミュレートするため、開発者がゲートレベルで故障を設定できる。ＣＰＵシミュレータ２００において図４のようなＣＰＵコア２１の命令デコーダ等の各回路はオブジェクト（データと操作手順）で記述されている。各オブジェクトは、制御信号の状態及び入力されたデータに応じて決まった処理を行い、処理結果を出力する。

ゲートレベルの故障を挿入するには、開発者等が、トランジスタのオン・オフをいずれかに固定すること（制御信号のいずれかがオン又はオフ一定になる）、入力データの入力や出力データの出力が正常に行われないように記述を加えること、回路内の処理が正常に実行されないように記述すること（異なる処理を記述する）、等を行う。

したがって、ゲートレベルの故障には種々の形態がありうるが、例えば、以下のような故障を挿入すればよい。
・レジスタファイル２７に入力される制御線が断線している、途中のトランジスタが常時オン・オフ状態になっている、又は、ショートしている、
・データバスの一部（例えば３２ビットの一部）のトランジスタが常時オン・オフ状態になっている、又は、ショートしている、
・ＡＬＵ２９に入力される制御線が断線している、途中のトランジスタが常時オン・オフ状態になっている、又は、ショートしている、
・命令デコーダから出力される制御線が断線している、途中のトランジスタが常時オン・オフ状態になっている、又は、ショートしている
・ＡＬＵ２９の加算回路が作動しない、乗算回路が作動しない
・シフト演算時に1ビットシフト漏れがある
開発者は、このような想定されうる故障の１つ以上をＣＰＵシミュレータ２００に記述して、命令セットの命令を全てのアドレス指定モードの組合せで実行する。なお、必ずしも全てのアドレス指定モードの組合せで実行する必要はなく、記述した故障により影響があり得るアドレス指定モードのみを選択して命令を実行してもよい。

１つの命令毎に故障がどのように伝播するかを調べるため、ＣＰＵシミュレータ２００は検査対象の命令を１つ実行する毎に、ＮＯＰ命令を１つ以上実行する。ＮＯＰ命令の数は、１つの命令が動作の完了までに必要とするクロック数程度である。こうすることで、ＣＰＵシミュレータ２００が一命令を実行するまでの故障の伝播を検査することができる。

開発者が、例えば、レジスタファイル２７に入力される制御線の１つ（例えば$3）の途中にあるトランジスタが常時オンになる故障をＣＰＵシミュレータ２００に記述し、ＣＰＵシミュレータ２００が「move $1 $3」という命令を実行した場合を例に説明する。この命令は汎用レジスタ$3の内容を汎用レジスタ$1に書き込むという命令である。しかし、ＣＰＵシミュレータ２００が実行した結果、汎用レジスタ$3の内容が汎用レジスタ$2に書き込まれていた場合、ＣＰＵシミュレータ２００に記述された故障が伝播した結果であることが推定される。このため、ＣＰＵシミュレータ２００は、記述された故障部位（例えば、汎用レジスタ$3と接続されたトランジスタが常時オン）に「move $1 $3」と「move $2 $3」を対応づけて、故障ライブラリ１１に登録する。

実際には、ＣＰＵシミュレータ２００が故障に影響された実効結果を帰納的に解析して命令「move $2 $3」を生成することが困難な場合もあるので、開発者が実行結果を監視して、命令「move $2 $3」を生成してもよい。また、実行結果が故障に影響されたか否かを判別するため、開発者がＣＰＵシミュレータ２００に故障を記述していない状態で実行した実行結果と、開発者がＣＰＵシミュレータ２００に故障を記述した状態で実行した実行結果とを比較して、ＣＰＵシミュレータ２００の処理結果が異なる場合に異なる実行結果をリストアップしてもよい。異なる実行結果とは、汎用レジスタの内容、ステータスフラグ３０の内容、及び、データメモリ２６の内容などである。こうすることで、ＣＰＵシミュレータ２００や開発者は、ＣＰＵシミュレータ２００の処理結果の帰納的な解析や命令「move $2 $3」の生成が容易になる。

また、開発者が、例えばＡＬＵ２９の加算回路が作動しないという故障を、ＣＰＵシミュレータ２００に記述し、ＣＰＵシミュレータ２００が「add $1 $2」という命令を実行したとする。この命令は汎用レジスタ$2と$1の内容を加算して、汎用レジスタ$1に書き込むという命令である。しかし、ＣＰＵシミュレータ２００が実行した結果、汎用レジスタ$1の内容に変化がなく、加算されていない場合、ＣＰＵシミュレータ２００に記述された故障が伝播した結果であることが推定される。このため、ＣＰＵシミュレータ２００は、記述された故障部位（例えば、ＡＬＵの加算回路が作動しない）に、「add $1 $2」と「NOP」又は「add $1 [0]」を対応づけて、故障ライブラリ１１に登録する。故障部位に応じて「NOP」又は「add $1 [0]」のうち適切な方を選択すればよい。

以上のようにして、故障ライブラリ１１には「故障時に影響が現れる動作」と「故障が現れた後の動作」が故障部位と対応づけて登録される。

〔故障再現装置〕
図６は、故障再現装置１００のハードウェア構成図の一例を示す。故障再現装置１００は所定のスペックを備えた汎用的なコンピュータであればよい。故障再現装置１００は、バス１により接続されたＣＰＵ３１、ＲＯＭ３９及びＲＡＭ４０、並びに、バス２により接続された外部Ｉ／Ｆ４１、通信制御部４２、入力装置Ｉ／Ｆ３２、表示装置Ｉ／Ｆ３４、記憶装置３６、及び、補助記憶装置３８を有する。バス１とバス２はブリッジ４４を介して接続されている。

ＣＰＵ３１は故障再現装置１００の全体の制御を司るものであり、その他のブロックはＣＰＵ３１の制御下におかれる。ＲＯＭ３９は、入出力用の簡易なプログラム及びその他の静的な（書き換えのない）データを記憶している。ＲＡＭ４０は、ＣＰＵ３１がプログラムを実行する際、プログラムやデータの一時的な記憶場所として利用される。

外部Ｉ／Ｆ４１は、ＵＳＢ等のインタフェースを用いて外部の機器との通信を可能とする。通信制御部４２は、有線または無線によりイーサネット（登録商標）等のネットワークに接続し、外部の機器との通信を可能とする。

入力装置Ｉ／Ｆ３２にはキーボードやマウス等の入力装置３３が接続され、開発者からの操作を受け付けるインタフェースとなる。表示装置Ｉ／Ｆ３４にはディスプレイ３５が接続され開発者に視覚的な情報を提供するインタフェースとなる。

記憶装置３６は、プログラム４３や大量のデータなどのデータベースの記憶場所として利用される不揮発のメモリ（ＨＤＤ等）である。本実施形態のプログラム４３は、故障再現装置１００を実現するためのプログラムであり、また、記憶装置３６はデータとして故障ライブラリ１１及びアプリケーションソフトを記憶している。プログラム４３や故障ライブラリ１１は、不図示のサーバからダウンロードすることでインストールされたり、可搬型記憶媒体３７に記憶された状態で配布される。

補助記憶装置３８は、ＤＶＤやメモリカードなどの可搬型記憶媒体３７からデータを読み込んだり、バックアップのためのデータを書き込んだりする、可搬型記憶媒体３７のインタフェースとして利用される。

まず、一般的なＣＰＵシミュレータ２００について説明する。図７は、ＣＰＵシミュレータ２００の機能ブロック図の一例を示す。ＣＰＵシミュレータ２００は主にコマンド入力受け付け部５１、実行部５２、データ記録部５３及び表示部５４を有する。コマンド入力受け付け部５１は、開発者の操作（コマンド）を受け付けるＧＵＩ又はＣＵＩである。ＧＵＩの場合、いくつかのボタンが表示され開発者がマウスなどで操作すると、コマンド入力受け付け部５１は操作されたボタンに応じたコマンドの入力を受け付ける。ＣＰＵシミュレータ２００はこのコマンドにより作動を開始及び終了する。コマンドには種々のものがあるが、例えば、アプリケーションソフトの読み込み、実行開始、実行停止、実行命令数の設定、ブレイクポイント（実行停止位置）の設定、レジスタファイル２７やＰＣ２２の表示、等が可能になっている。

実行部５２は、図４のようなＣＰＵコアの各回路がソフト的に再現されたオブジェクトを有し、各オブジェクトの動作を動作クロック毎に制御して、実機のＣＰＵコアの動作を模擬する。
（１）オブジェクトのＰＣ２２の値にて指定されるアドレスの命令が、オブジェクトの命令レジスタに入力される。ＰＣ２２は動作クロックに応じて内容をインクリメントする。
（２）命令レジスタは、オブジェクトの命令デコーダに命令を出力する。
（３）命令デコーダは、命令の解釈結果に応じて各回路に接続されたオブジェクトの制御線をそれぞれＨ・Ｌレベルに切り換える。
（４）制御線の状態に応じて、オブジェクトのＡＬＵに２つの汎用レジスタのデータ又は１つの汎用レジスタとデータメモリのデータが入力される。
（５）ＡＬＵは、制御線の状態に応じて、入力されたデータに対し算術演算や論理演算を行う。
（６）ＡＬＵは、演算結果に基づきオブジェクトのステータスフラグ３０に“１”“０”を設定する。なお、分岐命令の場合、ＡＬＵは分岐先のアドレスをＰＣ２２に設定する。
（７）ＡＬＵは、演算結果をレジスタに書き込む。

このように、実行部の各回路は実際のＣＰＵコアと同様に命令を実行し、レジスタファイル２７やステータスフラグ３０に実行結果に応じた値を設定するので、実機と同様の処理結果が得られる。

データ記録部５３は、例えば動作クロック毎のＰＣ２２の値、レジスタファイル２７の値、ステータスフラグ３０の値、及び、データメモリ２６に書き込まれた値等、を記録する。したがって、ＣＰＵコア２１がアプリケーションソフトを実行する際にどのような状態をであったかを記録することができる。

また、例えば、アプリケーションソフトに、ウォッチドッグ（定期的にＷＤＴをリセットする）処理やランタイムモニタ（特定のスレッドや各スレッドの実行開始から終了までの時間を監視する）処理が組み込まれている場合がある。この場合の、ウォッチドッグ処理やランタイムモニタ処理の結果もデータ記録部５３が記録するＣＰＵの状態に含まれるはずである。または、データ記録部５３に、アプリケーションソフトがウォッチドッグ処理やランタイムモニタ処理を実行した際のログを記録する機能を加えてもよい。したがって、開発者はデータ記録部５３が記録したデータを解析することで、ウォッチドッグ処理が適切に行われているか否かや、ランタイムモニタ処理により記録された実行時間が適切か否かを判断することができる。

表示部５４は、データ記録部５３が記録している内容の全て又は一部を順次、更新しながらディスプレイ３５に表示する。仮に表示されないデータがあっても、開発者が操作することでデータ記録部５３が記録しているデータを表示することができる。また、この他、表示部５４は、命令レジスタ２４、データメモリ２６など、ＣＰＵシミュレータ２００がオブジェクトとして保持しているデータであれば表示することができる。また、表示部５４は、命令実行数、各命令の種類毎の実行数、実行時間等を表示できる。

なお、図４に示したようなＩＮＴＣ、ＷＤＴ、Ａ／Ｄ等の周辺機器までをシミュレート可能なＣＰＵシミュレータ２００は、ＩＮＴＣ等のレジスタの内容を模擬することもできる。したがって、本実施形態の故障再現装置１００はＣＰＵコア２１の故障の再現に限られず、マイコンやＥＣＵの故障を再現することもできる。開発者は、例えば、Ｄ／Ａに設定されたデジタル値を適正値と比較することで、Ｄ／Ａが変換したアナログ値を使用するアクチュエータ等が想定どおりに動作しないことを検出できる。

図８は、本実施形態の故障再現装置１００の機能ブロック図の一例を示す。本実施形態の故障再現装置１００は実行部５２が２つのＣＰＵコア２１のシミュレートに対応していており、コア１用の実行部５５及びコア２用の実行部５６を有する。つまり、実行部５２は、２つのＣＰＵコア２１のシミュレーションを並行して実行することができる。並行して実行するとは、故障再現装置１００が２つのＣＰＵコア２１のシミュレーションを同時に実行するリソースを有すれば同時に実行し、そうでない場合には１命令ずつ交互に実行することをいう。

本実施形態のコマンド入力受け付け部５１は、開発者からの故障部位の指定を受け付け、実行部５２に通知する。なお、必ずしも開発者が故障部位を指定する必要はなく、順番に又は無作為に全ての故障部位を実行部に通知するモジュールを設けておいてもよい。

まず、コア１用の実行部５５はアプリケーションソフトを実行していく。実行部５２が有する照合モジュール１２は、故障ライブラリ１１から指定された故障部位を特定し、故障部位に対応づけられた「故障時に影響が現れる動作」を読み出し、コア１用の実行部５５が実行する命令が一致するか否かを監視する。ここで一致とは、オペコードのみ、オペコード及びオペランドの一部、又は、オペコード及びオペランドの全て、のいずれかが一致することをいい、開発者がコマンド入力受け付け部５１から設定できるようになっている。

照合モジュール１２は、コア１用の実行部５５が実行する命令が「故障時に影響が現れる動作」と一致する場合、コア１用の実行部５５に命令の実行を中止させ、故障挿入モジュール１３に通知する。

コア２用の実行部５６は、コア１用の実行部５５よりも数クロック遅れながら、アプリケーションソフトを実行している。数クロックは、故障時に影響が出る命令の実行完了に必要なサイクル数以上である。故障時に影響が出る命令は種々のものがあるが、命令のサイクル数は命令によって異なることが多い。このため、コア２用の実行部５６は、命令が必要としうる最大のサイクル数遅れながら、アプリケーションソフトを実行する。図では、コア１用の実行部５５がＭＯＶＥ命令を実行している際、コア２用の実行部５６はＡＤＤ命令を実行している。

故障挿入モジュール１３は、故障ライブラリ１１から指定された故障部位を特定し、故障部位に対応づけられた「影響が現れた後の動作」を読み出しておく。そして、照合モジュール１２から通知を受けると、アプリケーションソフトの実行を中断し、「故障が現れた後の動作」をコア２用の実行部５２が実行する「故障時に影響の出る動作」と置き換えて実行する。置き換えるには、命令レジスタの命令を「故障が現れた後の動作」で上書きすればよい。

ただし、照合モジュールから通知された時点では、コア２用の実行部５６がコア１用の実行部５５よりも数クロック遅れているので、コア２用の実行部５６は「故障時に影響が現れる動作」の手前の命令まで実行してから命令の実行を中断する。図の例では「ST $0 ［$1］」まで実行する。コア１用の実行部５５に対しコア２用の実行部５６が遅れているクロック数は既知なので、コア２用の実行部５６はこの決まったクロック数（正確にはこれより1つ少ないクロック数）だけ命令の実行を継続する。または、コア２用の実行部５６は照合モジュール１２からコア１用の実行部５５のＰＣ２２の値を取得し、その1つ手前の命令までを実行してもよい。

故障挿入モジュール１３は、コア２用の実行部５６が「故障が現れた後の動作」のみを実行したタイミングで原則的にコア２の動作を停止する。“原則的に”と説明したのは、ジャンプ命令の場合、コア２用の実行部５６がジャンプ先の命令を実行する準備が整うまでクロック数を消費する必要があるためである。よって、故障挿入モジュール１３は、コア２用の実行部５６が実行した「故障が現れた後の動作」がジャンプ命令か否かによって、コア２の動作を停止するまでのクロック数を可変にする。

そして、故障挿入モジュール１３は、データ記録部５３が記録したコア２用の実行部５６（仮想的なコア２）の各オブジェクトの状態を表す全てのデータ（コンテキスト）を照合モジュール１２に出力する。すなわち、ＰＣ２２の値、レジスタファイルの値、ステータスフラグの値、及び、スタックポインタレジスタの値などである。

照合モジュール１２は、ＰＣ２２の値、レジスタファイルの値、ステータスフラグの値、及び、スタックポインタ等を仮想的なコア１のオブジェクトのＰＣ２２等に書き込む。これにより、コア１用の実行部５５は、コア２用の実行部５６が「故障が現れた後の動作」を実行した後の状態からアプリケーションソフトを実行できる。「故障が現れた後の動作」は故障部位が故障したことで生じた動作なので、故障部位が故障した場合にアプリケーションソフトの動作にどのような影響が生じるかを故障再現装置１００がシミュレートすることができる。

コア２用の実行部５６は、例えばコア１用の実行部５５から再開のタイミングを受け取り、「故障が現れた後の動作」を実行する前と同様に、数クロック遅れてアプリケーションソフトの実行を再開する。

なお、再度、上述した処理をコア１用の実行部５５とコア２用の実行部５６が行う場合、コア２用の実行部５６は「故障が現れた後の動作」の履歴の影響を受ける。コア１用の実行部５５とコア２用の実行部５６が全く同じ実行履歴であることが望まれる場合は、コア２用の実行部５６は「故障が現れた後の動作」の履歴の影響を受けたままでよい。

一方、例えば、開発者の設定により、コア２用の実行部５６が「故障が現れた後の動作」の履歴の影響を受けることがないように、コア２用の実行部５６が、「故障が現れた後の動作」を実行する前に、コンテキストを退避しておくことも可能である。そして、「故障が現れた後の動作」を実行した後にコンテキストをコア２用の実行部５６に設定することが好ましい。この場合のコンテキストは、「故障が現れた後の動作」の１つ前の命令までのものである。したがって、コア２用の実行部５６は、再開時に「故障時に影響が現れる動作」から実行を開始する。こうすることで、コア２用の実行部５６は、「故障が現れた後の動作」を実行しなかった状態にできるので、「故障が現れた後の動作」の履歴の影響を受けることを防止でき、どの故障によりアプリケーションソフトの動作が影響されるかを特定しやすくできる。

故障ライブラリ１１の全ての故障部位が指定され、データ記録部５３がウォッチドッグ処理やランタイムモニタ処理の処理結果を記録した場合、故障再現装置１００は故障率を算出することができる。ウォッチドッグ処理が実行されていない場合やランタイムモニタ処理により得られた実行時間が規定を超えている場合、故障部位がアプリケーションソフトの動作から検出されたことになるためである。

例えば、ＩＳＯ２６２６２では安全機構が持ち得る故障検出のカバー率ＤＣを規定するが、このＤＣを算出できる。本実施形態の例では「ＤＣ＝ウォッチドッグ処理やランタイムモニタ処理により検出された実行エラー／故障ライブラリに登録された故障部位の数」である。軽微な故障まで故障ライブラリに登録することで分母が大きくなるとＤＣが下がる可能性がある。しかし、これは故障の粒度の問題であり、アプリケーションソフトの動作に影響のない故障を故障ライブラリに登録するか否かは開発者等が考慮することができる。適切な故障のみを考慮する一つの手法として、例えば、ゲートレベルでなく回路（レジスタ、ＡＬＵなど）単位で故障を登録する手法がある。

また、開発者の指示などにより再現装置１００が故障ライブラリの全ての故障部位を再現しない場合、ＤＣは「ＤＣ＝ウォッチドッグ処理やランタイムモニタ処理により検出された実行エラー／再現装置が再現した故障部位の数」となる。

また、故障ライブラリ１１の各故障部位に発生頻度情報を対応づけておき、故障再現装置１００は開発者により設定された閾値以上の発生頻度情報の故障部位のみについて、故障を再現することが有効な場合がある。ＩＳＯ２６２６２ではハザード（潜在的な好ましくない事象）の対応に必要なＡＳＩＬ（Automotive Safety Integrity Level）が４段階に区分して規定されている。このＡＳＩＬの決定には、ハザードの発生頻度が考慮されることになっている。故障部位によりハザードが生じると仮定すれば、故障部位の発生頻度情報はＡＳＩＬと相関を持つと考えてよい。

したがって、故障再現装置１００が閾値以上の故障部位のみについて、故障を再現すれば、開発者はＡＳＩＬに応じた対応が可能になる。

〔動作手順〕
図９は、故障再現装置１００が故障を再現する手順を示すフローチャート図の一例である。
まず、コマンド入力受け付け部５１は、故障部位の指定を受け付ける（Ｓ１０）。

照合モジュール１２は、故障ライブラリ１１から故障部位に対応づけられた「故障時に影響が現れる動作」を読み出し、故障挿入モジュール１３は故障ライブラリ１１から故障部位に対応づけられた「故障が現れた後の動作」を読み出す（Ｓ２０）。

コア１用の実行部５５がアプリケーションソフトの実行を開始すると（Ｓ３０）、その通知を受けたコア２用の実行部５６が予め決まったクロック数遅れてアプリケーションソフトの実行を開始する（Ｓ４０）。

照合モジュール１２は、アプリケーションソフトの実行対象の命令と「故障時に影響が現れる動作」とを逐次比較する（Ｓ５０）。一致しない場合は（Ｓ５２のＮｏ）、比較を繰り返す。

一致した場合には（Ｓ５２のＹｅｓ）、照合モジュール１２はコア１用の実行部５５にアプリケーションソフトの実行を中断させる（Ｓ６０）。また、故障挿入モジュール１３は照合モジュールからの通知を受けて、コア２用の実行部５６が「故障時に影響が現れる動作」の手前の命令まで実行した後、アプリケーションソフトの実行を中断させる（Ｓ６０）。

故障挿入モジュール１３は、「故障が現れた後の動作」でコア２用の実行部５６が実行する命令を置き換える（Ｓ７０）。故障挿入モジュール１３は、「故障が現れた後の動作」をコア２用の実行部５６が実行したら中断させる（Ｓ８０）。

故障挿入モジュール１３は、コア２のコンテキストを照合モジュール１２に通知するので、照合モジュールはコア１用の実行部５５にコンテキストを設定してアプリケーションソフトの実行を再開させる（Ｓ９０）。故障再現装置１００は、以上の処理を繰り返し実行する。

なお、１回のアプリケーションソフトの動作で、ステップＳ５０の判定（アプリケーションソフトの実行対象の命令と「故障時に影響が現れる動作」）が複数回Ｙｅｓとなる場合もある。この場合、全てのＹｅｓの判定で故障挿入モジュール１３が故障を挿入してもよいが、開発者は任意の１回のみのＹｅｓの判定で故障を挿入するように設定することができる。任意の１回のみとは、Ｓ５０でＹｅｓとなった際に照合モジュールが実際にＹｅｓ側の処理を実行するか否かランダムに決定し、一度実際に処理したら、それ以降はＳ５０でＹｅｓとなってもＹｅｓ側の処理を実行しないことをいう。

このような設定により、故障再現装置１００は一過性の故障（トランジェント故障）の影響を再現可能になり、ＩＳＯ２６２６２が要求するトランジェント故障の考慮にも対応したものとなる。

以上説明したように本実施形態の故障再現装置１００は、故障ライブラリ１１を予め用意しておくことで、ゲートレベルで故障が起こった場合の命令とＣＰＵコアの動作の関係が明らかになるので、ゲートレベルで故障が起こった場合にアプリケーションの動作に現れる影響を評価することができる。故障再現装置１００がシミュレーションを実行するために必要な時間は、ゲートレベルの故障の伝播をシミュレートするよりも高速であるので、実用的な時間で故障をシュミュレートすることができる。

１１ 故障ライブラリ
１２ 照合モジュール
１３ 故障挿入モジュール
５１ コマンド入力受け付け部
５２ 実行部
５３ データ記録部
５４ 表示部
５５ コア１用の実行部
５６ コア２用の実行部
１００ 故障再現装置
２００ ＣＰＵシミュレータ

Claims (9)

1. ＣＰＵ内に故障が発生した場合に、影響の現れる命令と影響が現れた後の命令が故障内容に対応づけて登録された故障ライブラリと、
   アプリケーションソフトを記憶したアプリケーション記憶手段と、
   前記アプリケーションソフトを前記ＣＰＵが実行した際の動作を別々にシミュレートする第１のシミュレート手段及び第２のシミュレート手段と、
   前記第１のシミュレート手段が前記影響の現れる命令を実行したことを検出して、前記アプリケーションソフトの実行を中断させると共に前記第２のシミュレート手段に通知する実行検出手段と、
   前記実行検出手段から前記第１のシミュレート手段が前記影響の現れる命令を実行したという通知を取得し、前記第２のシミュレート手段に、前記影響の現れる命令と対応づけられた前記影響が現れた後の命令を実行させる命令置き換え手段と、を有し、
   前記第１のシミュレート手段は、前記第２のシミュレート手段が実行した前記影響が現れた後の命令の実行結果を引き継いで、前記アプリケーションソフトの実行を再開する、
   ことを特徴とする故障再現装置。
2. 前記第２のシミュレート手段は、少なくとも前記影響の現れる命令の実行に必要なサイクル数だけ前記第１のシミュレート手段よりも遅延して、アプリケーションソフトを実行する、
   ことを特徴とする請求項１記載の故障再現装置。
3. 前記命令置き換え手段は、前記実行検出手段から前記第１のシミュレート手段が前記影響の現れる命令を実行したという通知を取得してから、前記影響の現れる命令の手前の命令までを前記第２のシミュレート手段に実行させた後、前記影響が現れた後の命令を実行させる、
   ことを特徴とする請求項１又は２記載の故障再現装置。
4. 前記第１のシミュレート手段が、前記影響が現れた後の命令の実行結果を前記第２のシミュレート手段から引き継いだ場合、
   アプリケーションソフトの動作内容が記録された動作記録に基づき、前記故障ライブラリに登録された故障内容の故障が検出可能か否かを判定する、
   ことを特徴とする請求項１〜３いずれか１項記載の故障再現装置。
5. 前記第２のシミュレート手段が実行した前記影響が現れた後の命令の数と、検出可能な故障の数から故障検出率を算出する、
   ことを特徴とする請求項４記載の故障再現装置。
6. 前記実行検出手段は、前記アプリケーションソフトの命令に、前記影響の現れる命令と一致する命令が複数個含まれている場合、不作為に決定したそのうちのいずれか１つを前記第１のシミュレート手段が実行した場合にのみ、前記アプリケーションソフトの実行を中断させ、前記第２のシミュレート手段に通知する、
   ことを特徴とする請求項１〜５いずれか１項記載の故障再現装置。
7. 前記故障ライブラリには、故障内容に発生頻度情報が対応づけられており、
   前記実行検出手段は、閾値以上の前記発生頻度情報が故障内容に対応づけられた前記影響の現れる命令を前記第１のシミュレート手段が実行した場合にのみ、前記アプリケーションソフトの実行を中断させ、前記第２のシミュレート手段に通知する、
   ことを特徴とする請求項１〜６いずれか１項記載の故障再現装置。
8. 前記命令置き換え手段は、前記第２のシミュレート手段が実行した前記影響の現れる命令の手前の命令までの実行結果を記録しておき、前記第２のシミュレート手段が前記影響が現れた後の命令を実行した後、前記影響の現れる命令の手前の命令までの実行結果を引き継いでアプリケーションソフトの実行を再開する、
   ことを特徴とする請求項１記載の故障再現装置。
9. ＣＰＵ内に故障が発生した場合に、影響の現れる命令と影響が現れた後の命令が故障内容に対応づけて登録された故障ライブラリと、
   アプリケーションソフトを記憶したアプリケーション記憶手段と、を有する故障再現装置の故障再現方法であって、
   第１のシミュレート手段及び第２のシミュレート手段が、前記アプリケーションソフトを前記ＣＰＵが実行した際の動作を別々にシミュレートするステップ、
   実行検出手段が、前記第１のシミュレート手段が前記影響の現れる命令を実行したことを検出して、前記アプリケーションソフトの実行を中断させると共に前記第２のシミュレート手段に通知するステップと、
   命令置き換え手段が、前記実行検出手段から前記第１のシミュレート手段が前記影響の現れる命令を実行したという通知を取得し、前記第２のシミュレート手段に、前記影響の現れる命令と対応づけられた前記影響が現れた後の命令を実行させるステップと、
   前記第１のシミュレート手段が、前記第２のシミュレート手段が実行した前記影響が現れた後の命令の実行結果を引き継いで、前記アプリケーションソフトの実行を再開するステップと、
   を有する故障再現方法。

Images