"CPU内に故障が発生した場合に、影響の現れる命令と影響が現れた後の命令が故障内容に対応づけて登録された故障ライブラリと、アプリケーションソフトを記憶したアプリケーション記憶手段と、前記アプリケーションソフトを前記CPUが実行した際の動作を別々にシミュレートする第1のシミュレート手段及び第2のシミュレート手段と、前記第1のシミュレート手段が前記影響の現れる命令を実行したことを検出して、前記アプリケーションソフトの実行を中断させると共に前記第2のシミュレート手段に通知する実行検出手段と、前記実行検出手段から前記第1のシミュレート手段が前記影響の現れる命令を実行したという通知を取得し、前記第2のシミュレート手段に、前記影響の現れる命令と対応づけられた前記影響が現れた後の命令を実行させる命令置き換え手段と、を有し、前記第1のシミュレート手段は、前記第2のシミュレート手段が実行した前記影響が現れた後の命令の実行結果を引き継いで、前記アプリケーションソフトの実行を再開する、ことを特徴とする故障再現装置。前記第2のシミュレート手段は、少なくとも前記影響の現れる命令の実行に必要なサイクル数だけ前記第1のシミュレート手段よりも遅延して、アプリケーションソフトを実行する、ことを特徴とする請求項1記載の故障再現装置。前記命令置き換え手段は、前記実行検出手段から前記第1のシミュレート手段が前記影響の現れる命令を実行したという通知を取得してから、前記影響の現れる命令の手前の命令までを前記第2のシミュレート手段に実行させた後、前記影響が現れた後の命令を実行させる、ことを特徴とする請求項1又は2記載の故障再現装置。前記第1のシミュレート手段が、前記影響が現れた後の命令の実行結果を前記第2のシミュレート手段から引き継いだ場合、アプリケーションソフトの動作内容が記録された動作記録に基づき、前記故障ライブラリに登録された故障内容の故障が検出可能か否かを判定する、ことを特徴とする請求項1~3いずれか1項記載の故障再現装置。前記第2のシミュレート手段が実行した前記影響が現れた後の命令の数と、検出可能な故障の数から故障検出率を算出する、ことを特徴とする請求項4記載の故障再現装置。前記実行検出手段は、前記アプリケーションソフトの命令に、前記影響の現れる命令と一致する命令が複数個含まれている場合、不作為に決定したそのうちのいずれか1つを前記第1のシミュレート手段が実行した場合にのみ、前記アプリケーションソフトの実行を中断させ、前記第2のシミュレート手段に通知する、ことを特徴とする請求項1~5いずれか1項記載の故障再現装置。前記故障ライブラリには、故障内容に発生頻度情報が対応づけられており、前記実行検出手段は、閾値以上の前記発生頻度情報が故障内容に対応づけられた前記影響の現れる命令を前記第1のシミュレート手段が実行した場合にのみ、前記アプリケーションソフトの実行を中断させ、前記第2のシミュレート手段に通知する、ことを特徴とする請求項1~6いずれか1項記載の故障再現装置。前記命令置き換え手段は、前記第2のシミュレート手段が実行した前記影響の現れる命令の手前の命令までの実行結果を記録しておき、前記第2のシミュレート手段が前記影響が現れた後の命令を実行した後、前記影響の現れる命令の手前の命令までの実行結果を引き継いでアプリケーションソフトの実行を再開する、ことを特徴とする請求項1記載の故障再現装置。CPU内に故障が発生した場合に、影響の現れる命令と影響が現れた後の命令が故障内容に対応づけて登録された故障ライブラリと、アプリケーションソフトを記憶したアプリケーション記憶手段と、を有する故障再現装置の故障再現方法であって、第1のシミュレート手段及び第2のシミュレート手段が、前記アプリケーションソフトを前記CPUが実行した際の動作を別々にシミュレートするステップ、実行検出手段が、前記第1のシミュレート手段が前記影響の現れる命令を実行したことを検出して、前記アプリケーションソフトの実行を中断させると共に前記第2のシミュレート手段に通知するステップと、命令置き換え手段が、前記実行検出手段から前記第1のシミュレート手段が前記影響の現れる命令を実行したという通知を取得し、前記第2のシミュレート手段に、前記影響の現れる命令と対応づけられた前記影響が現れた後の命令を実行させるステップと、前記第1のシミュレート手段が、前記第2のシミュレート手段が実行した前記影響が現れた後の命令の実行結果を引き継いで、前記アプリケーションソフトの実行を再開するステップと、を有する故障再現方法。しかしながら、特許文献1に記載された手法で故障リストを作成しても、被試験ICの故障を検出する際には、ゲートレベルでテストパターンを入力し、入力された信号がトランジスタにどのように伝播していくかを監視トレースする必要がある。信号は1サイクル毎動作クロック毎に伝播するため、全てのゲートの動作を1サイクルずつシミュレートするのではかなりの時間を要してしまう。ここで、CPUコアの故障の検出は、CPUコアが実行するアプリケーションソフトの動作と関連づけることが有効であると考えられる。すなわち、例えばシミュレータが、あるCPUコアでアプリケーションソフトを実行した場合に、CPUコアに故障が発生するとアプリケーションソフトの動作にどのような障害が現れるか又は現れないかを調べておく。これにより、シミュレータがCPUコアのゲートレベルの故障の伝播を網羅的にトレースしなくても、CPUコアの故障をアプリケーションソフトの動作から検出することができる。しかし、この場合でも、アプリケーションソフトの命令毎にゲートレベルの動作の伝播をトレースする必要があるため、アプリケーションソフトの規模が比較的大きくない中規模程度の場合でもシミュレーションに数ヶ月必要になる。このように、従来、デュアルロックステップ以外に、十分な検出率にてCPUコアの故障を検出する実用的な手法がなかった。本発明は、上記課題に鑑み、短時間でCPUコアの故障を比較的高い検出率で検出することが可能な故障再現装置を提供することを目的とする。本発明は、CPU内に故障が発生した場合に、影響の現れる命令と影響が現れた後の命令が故障内容に対応づけて登録された故障ライブラリと、アプリケーションソフトを記憶したアプリケーション記憶手段と、前記アプリケーションソフトを前記CPUが実行した際の動作を別々にシミュレートする第1のシミュレート手段及び第2のシミュレート手段と、前記第1のシミュレート手段が前記影響の現れる命令を実行したことを検出して、前記アプリケーションソフトの実行を中断させると共に前記第2のシミュレート手段に通知する実行検出手段と、前記実行検出手段から前記第1のシミュレート手段が前記影響の現れる命令を実行したという通知を取得し、前記第2のシミュレート手段に、前記影響の現れる命令と対応づけられた前記影響が現れた後の命令を実行させる命令置き換え手段と、を有し、前記第1のシミュレート手段は、前記第2のシミュレート手段が実行した前記影響が現れた後の命令の実行結果を引き継いで、前記アプリケーションソフトの実行を再開する、ことを特徴とする。短時間でCPUコアの十分な検出率の故障を検出することが可能な故障再現装置を提供することができる。以下、本発明を実施するための形態について図面を参照しながら説明する。図1は、故障再現装置100の概略動作を説明する図の一例である。本実施形態の故障再現装置100は、故障箇所の再現に故障ライブラリ11を利用する。故障ライブラリ11の作成方法は後述するが、故障ライブラリ11には、故障時に影響が現れる動作と故障が現れた後の動作が、故障部位に対応づけて登録されている。故障時に影響が現れる動作:何らかの故障が生じている状態で実行されると動作に影響を及ぼす命令本来そのまま実行されることが意図された命令故障が現れた後の動作:故障時に影響が現れる動作により引き起こされる意図しない命令故障再現装置100は2つのCPUシミュレータ200以下、区別する場合、CPUシミュレータ1、2というを有する。CPUシミュレータ1は、アプリケーションソフトを実行するCPUシミュレータであり、照合モジュールにより故障時に影響が現れる動作を実行するか否かが監視される。CPUシミュレータ2は、CPUシミュレータ1よりも数クロック遅れながら同じアプリケーションソフトを実行する。数クロック遅れて実行するのは、照合モジュール12によりCPUシミュレータ1が故障時に影響が現れる動作が実行したと検出された時、CPUシミュレータ1はすでに故障時に影響が現れる動作を実行しているためである。よって、CPUシミュレータ2は、故障時に影響が現れる動作を、故障が現れた後の動作で置き換える時間的な余裕がある。上記のように、CPUシミュレータ1がアプリケーションソフトを実行している間、照合モジュール12は、CPUシミュレータ1が実行する命令が、故障ライブラリ11に登録された故障時に影響が現れる動作と一致するか否かを連続的1ステップ毎に照合する。一致した場合、照合モジュール12は、故障時に影響が現れる動作が検出されたことを故障挿入モジュール13に通知する。故障挿入モジュール13は、CPUシミュレータ2によるアプリケーションソフトの実行を中断させ、故障ライブラリ11から読み出した故障が現れた後の動作をCPUシミュレータ2が実行する予定だった故障時に影響が現れる動作と置き換える。したがって、CPUシミュレータ2は、故障部位が故障していた場合の動作を再現することができる。CPUシミュレータ2が故障が現れた後の動作を実行すると、故障挿入モジュール13はCPUコア2の動作を一時中断し、CPUシミュレータ2のコンテキストをCPUシミュレータ1に通知する。CPUシミュレータ1は、CPUシミュレータ2の動作終了時の状態からアプリケーションソフトの実行を再開する。CPUシミュレータ2も、CPUシミュレータ1から数クロック遅れてアプリケーションソフトの実行を再開する。したがって、CPUシミュレータ1は、故障部位が故障していた場合のアプリケーションソフトの動作を再現したことになる。実際にCPUコアが故障していなくても故障した状態でCPUコアがアプリケーションソフトを実行したことになるので、CPUコアの故障時にアプリケーションソフトがどのような動作を行うかをシミュレートすることができる。CPUシミュレータ1には、一般的な機能としてレジスタなどの値を記録するログ機能等が搭載されている。これから、アプリケーションソフトの動作を検証すれば正常動作時との比較など、故障再現装置100は故障がアプリケーションソフトの動作に与えた影響を定量化して、故障検出率等を算出することができる。故障ライブラリ図2は、故障ライブラリ11の作成を模式的に説明する図の一例である。故障ライブラリ11の作成は、開発者がCPUコアの設計図を見ながら作成することもできるが、CPUシミュレータ200を使用することが効率的である。図示するように、CPUシミュレータ200は、コンピュータパーソナルコンピュータやワークステーションである。後述するようにCPUシミュレータ200は、車載対象のCPUコアの動作をソフトウェアで模擬的に再現する。CPUシミュレータ200にはCPUコア設計図に基づくゲートレベルの素子、回路、及び、ゲートレベルの素子の接続状況、がデータとして記憶されている。また、CPUコアは、実行可能な命令の集合である命令セットが決められている。命令はアセンブラ言語又は機械語で記述され、各種の算術演算や論理演算などが用意されている。また、CPUコアでは命令毎にオペランドに記述可能なアドレス指定モード絶対アドレス指定,レジスタアドレス指定,即値アドレス指定,インデックスアドレス指定等が定められている。したがって、1つの命令のオペランドに記述可能なアドレス指定モードを組み合わせることで、命令毎に漏れのない故障シミュレーションが可能になる。図3は、ECU300による処理を模式的に説明する図の一例である。一般的なECUElectronicControlUnit300は、ROMに記憶されたアプリケーションソフトをCPUコアで実行しながら、各種の入力インタフェースA/D変換器、I/O、車載LAN用の通信装置等から入力されるアナログ信号やデジタル信号を処理し、出力インタフェースD/A変換器、I/O、車載LAN用の通信装置等からPWM信号、オンオフ信号などを出力する。アナログ信号には、センサの検出信号や制御対象物の状態を表す電圧値や電流値がある。デジタル信号は、各種のスイッチのオン/オフ、操作位置に対応したHレベル又はLレベルの信号、車速パルス等である。アクチュエータは、スロットルモータ、ブレーキ液圧ポンプモータ、電動パワステモータ等であり、ソレノイドは燃料噴射弁等の各種の弁であり、リレーはバッテリからの給電を開始するメインリレーやACCリレー等である。図4は、CPUコア21の構成を概略的に示す図の一例である。CPUコア21は、バスに接続されたPCプログラムカウンタ22、プログラムメモリ23、データメモリ26、レジスタファイル27、及び、ALUarithmeticlogicalunit29等を有する。また、CPUコアにはバスを介して各種の周辺機器INTC、WDT、A/D、D/A等が接続される。CPUコアが命令を実行する際、PC22が示すアドレスの命令が命令バスを介して命令レジスタ24に読み込まれ、命令デコーダ25でデコードされる。命令デコーダ25は命令の種類を判別し、また、オペランドのアドレス指定モードを判別し、実効アドレスを算出することで、不図示のシーケンサに各ゲートや回路の制御信号を出力させる。データメモリ26には、演算対象のデータや演算中のデータが記憶される。レジスタファイル27には、汎用レジスタ0~7が配置されており、各種の演算に使用されるデータが一時的に記憶される。マルチプレクサ28は、制御線の状態に応じてデータメモリ26又は汎用レジスタの一方をALU29に出力する。なお、マルチプレクサ28の入力側が命令デコーダ25と接続されているのは、ジャンプ命令やサブルーチンコールの際、ALU22がPC22にアドレスを記憶するためである。この時、スタックポインタレジスタ不図示に元の処理に戻るためのアドレスが記憶される。ALU29は、制御信号の状態に応じて、レジスタファイル27やデータメモリ26の2つの入力の少なくとも一方を使用して加算、減算、乗算、除算などの算術演算を実行する。また、不図示の論理演算回路が論理演算することもある。検算結果はレジスタファイル27やデータメモリ26に書き込まれる。また、ALU29の他に又はALU29と一体にシフト演算するシフタを有していてもよい。ALU29の演算結果によりステータス30には、演算結果がゼロであることや負であることを示すための1,0が設定される。図5は命令セットの一例を示す図である。CPUコアが実行可能な、算術演算子ADDSUBMULDIVREM、ビット演算子NOTANDORXOR、シフト演算子SLLSRLSRA、ロードLD、ストアST、データ代入MOVE、ポップPOP、プッシュPUSH、コールCALL、ジャンプJMP、条件分岐BEQZ、ノンオペレーションNOPが登録されている。図5では各命令の記述例を示したが、一命令のアドレス指定モードは1つとは限らない。例えば、算術演算子では、絶対アドレス指定,レジスタアドレス指定,即値アドレス指定及びインデックスアドレス指定が可能であり、データ代入には、レジスタアドレス指定と即値アドレス指定が可能である。CPUシミュレータ200には、各命令で可能なアドレス指定モードが登録されており、その全ての組み合わせで1つの命令を実行できるようになっている。本実施形態のCPUシミュレータ200は、故障をシミュレートするため、開発者がゲートレベルで故障を設定できる。CPUシミュレータ200において図4のようなCPUコア21の命令デコーダ等の各回路はオブジェクトデータと操作手順で記述されている。各オブジェクトは、制御信号の状態及び入力されたデータに応じて決まった処理を行い、処理結果を出力する。ゲートレベルの故障を挿入するには、開発者等が、トランジスタのオンオフをいずれかに固定すること制御信号のいずれかがオン又はオフ一定になる、入力データの入力や出力データの出力が正常に行われないように記述を加えること、回路内の処理が正常に実行されないように記述すること異なる処理を記述する、等を行う。したがって、ゲートレベルの故障には種々の形態がありうるが、例えば、以下のような故障を挿入すればよい。レジスタファイル27に入力される制御線が断線している、途中のトランジスタが常時オンオフ状態になっている、又は、ショートしている、データバスの一部例えば32ビットの一部のトランジスタが常時オンオフ状態になっている、又は、ショートしている、ALU29に入力される制御線が断線している、途中のトランジスタが常時オンオフ状態になっている、又は、ショートしている、命令デコーダから出力される制御線が断線している、途中のトランジスタが常時オンオフ状態になっている、又は、ショートしているALU29の加算回路が作動しない、乗算回路が作動しないシフト演算時に1ビットシフト漏れがある開発者は、このような想定されうる故障の1つ以上をCPUシミュレータ200に記述して、命令セットの命令を全てのアドレス指定モードの組合せで実行する。なお、必ずしも全てのアドレス指定モードの組合せで実行する必要はなく、記述した故障により影響があり得るアドレス指定モードのみを選択して命令を実行してもよい。1つの命令毎に故障がどのように伝播するかを調べるため、CPUシミュレータ200は検査対象の命令を1つ実行する毎に、NOP命令を1つ以上実行する。NOP命令の数は、1つの命令が動作の完了までに必要とするクロック数程度である。こうすることで、CPUシミュレータ200が一命令を実行するまでの故障の伝播を検査することができる。開発者が、例えば、レジスタファイル27に入力される制御線の1つ例えば3の途中にあるトランジスタが常時オンになる故障をCPUシミュレータ200に記述し、CPUシミュレータ200がmove13という命令を実行した場合を例に説明する。この命令は汎用レジスタ3の内容を汎用レジスタ1に書き込むという命令である。しかし、CPUシミュレータ200が実行した結果、汎用レジスタ3の内容が汎用レジスタ2に書き込まれていた場合、CPUシミュレータ200に記述された故障が伝播した結果であることが推定される。このため、CPUシミュレータ200は、記述された故障部位例えば、汎用レジスタ3と接続されたトランジスタが常時オンにmove13とmove23を対応づけて、故障ライブラリ11に登録する。実際には、CPUシミュレータ200が故障に影響された実効結果を帰納的に解析して命令move23を生成することが困難な場合もあるので、開発者が実行結果を監視して、命令move23を生成してもよい。また、実行結果が故障に影響されたか否かを判別するため、開発者がCPUシミュレータ200に故障を記述していない状態で実行した実行結果と、開発者がCPUシミュレータ200に故障を記述した状態で実行した実行結果とを比較して、CPUシミュレータ200の処理結果が異なる場合に異なる実行結果をリストアップしてもよい。異なる実行結果とは、汎用レジスタの内容、ステータスフラグ30の内容、及び、データメモリ26の内容などである。こうすることで、CPUシミュレータ200や開発者は、CPUシミュレータ200の処理結果の帰納的な解析や命令move23の生成が容易になる。また、開発者が、例えばALU29の加算回路が作動しないという故障を、CPUシミュレータ200に記述し、CPUシミュレータ200がadd12という命令を実行したとする。この命令は汎用レジスタ2と1の内容を加算して、汎用レジスタ1に書き込むという命令である。しかし、CPUシミュレータ200が実行した結果、汎用レジスタ1の内容に変化がなく、加算されていない場合、CPUシミュレータ200に記述された故障が伝播した結果であることが推定される。このため、CPUシミュレータ200は、記述された故障部位例えば、ALUの加算回路が作動しないに、add12とNOP又はadd10を対応づけて、故障ライブラリ11に登録する。故障部位に応じてNOP又はadd10のうち適切な方を選択すればよい。以上のようにして、故障ライブラリ11には故障時に影響が現れる動作と故障が現れた後の動作が故障部位と対応づけて登録される。故障再現装置図6は、故障再現装置100のハードウェア構成図の一例を示す。故障再現装置100は所定のスペックを備えた汎用的なコンピュータであればよい。故障再現装置100は、バス1により接続されたCPU31、ROM39及びRAM40、並びに、バス2により接続された外部I/F41、通信制御部42、入力装置I/F32、表示装置I/F34、記憶装置36、及び、補助記憶装置38を有する。バス1とバス2はブリッジ44を介して接続されている。CPU31は故障再現装置100の全体の制御を司るものであり、その他のブロックはCPU31の制御下におかれる。ROM39は、入出力用の簡易なプログラム及びその他の静的な書き換えのないデータを記憶している。RAM40は、CPU31がプログラムを実行する際、プログラムやデータの一時的な記憶場所として利用される。外部I/F41は、USB等のインタフェースを用いて外部の機器との通信を可能とする。通信制御部42は、有線または無線によりイーサネット登録商標等のネットワークに接続し、外部の機器との通信を可能とする。入力装置I/F32にはキーボードやマウス等の入力装置33が接続され、開発者からの操作を受け付けるインタフェースとなる。表示装置I/F34にはディスプレイ35が接続され開発者に視覚的な情報を提供するインタフェースとなる。記憶装置36は、プログラム43や大量のデータなどのデータベースの記憶場所として利用される不揮発のメモリHDD等である。本実施形態のプログラム43は、故障再現装置100を実現するためのプログラムであり、また、記憶装置36はデータとして故障ライブラリ11及びアプリケーションソフトを記憶している。プログラム43や故障ライブラリ11は、不図示のサーバからダウンロードすることでインストールされたり、可搬型記憶媒体37に記憶された状態で配布される。補助記憶装置38は、DVDやメモリカードなどの可搬型記憶媒体37からデータを読み込んだり、バックアップのためのデータを書き込んだりする、可搬型記憶媒体37のインタフェースとして利用される。まず、一般的なCPUシミュレータ200について説明する。図7は、CPUシミュレータ200の機能ブロック図の一例を示す。CPUシミュレータ200は主にコマンド入力受け付け部51、実行部52、データ記録部53及び表示部54を有する。コマンド入力受け付け部51は、開発者の操作コマンドを受け付けるGUI又はCUIである。GUIの場合、いくつかのボタンが表示され開発者がマウスなどで操作すると、コマンド入力受け付け部51は操作されたボタンに応じたコマンドの入力を受け付ける。CPUシミュレータ200はこのコマンドにより作動を開始及び終了する。コマンドには種々のものがあるが、例えば、アプリケーションソフトの読み込み、実行開始、実行停止、実行命令数の設定、ブレイクポイント実行停止位置の設定、レジスタファイル27やPC22の表示、等が可能になっている。実行部52は、図4のようなCPUコアの各回路がソフト的に再現されたオブジェクトを有し、各オブジェクトの動作を動作クロック毎に制御して、実機のCPUコアの動作を模擬する。1オブジェクトのPC22の値にて指定されるアドレスの命令が、オブジェクトの命令レジスタに入力される。PC22は動作クロックに応じて内容をインクリメントする。2命令レジスタは、オブジェクトの命令デコーダに命令を出力する。3命令デコーダは、命令の解釈結果に応じて各回路に接続されたオブジェクトの制御線をそれぞれHLレベルに切り換える。4制御線の状態に応じて、オブジェクトのALUに2つの汎用レジスタのデータ又は1つの汎用レジスタとデータメモリのデータが入力される。5ALUは、制御線の状態に応じて、入力されたデータに対し算術演算や論理演算を行う。6ALUは、演算結果に基づきオブジェクトのステータスフラグ30に10を設定する。なお、分岐命令の場合、ALUは分岐先のアドレスをPC22に設定する。7ALUは、演算結果をレジスタに書き込む。このように、実行部の各回路は実際のCPUコアと同様に命令を実行し、レジスタファイル27やステータスフラグ30に実行結果に応じた値を設定するので、実機と同様の処理結果が得られる。データ記録部53は、例えば動作クロック毎のPC22の値、レジスタファイル27の値、ステータスフラグ30の値、及び、データメモリ26に書き込まれた値等、を記録する。したがって、CPUコア21がアプリケーションソフトを実行する際にどのような状態をであったかを記録することができる。また、例えば、アプリケーションソフトに、ウォッチドッグ定期的にWDTをリセットする処理やランタイムモニタ特定のスレッドや各スレッドの実行開始から終了までの時間を監視する処理が組み込まれている場合がある。この場合の、ウォッチドッグ処理やランタイムモニタ処理の結果もデータ記録部53が記録するCPUの状態に含まれるはずである。または、データ記録部53に、アプリケーションソフトがウォッチドッグ処理やランタイムモニタ処理を実行した際のログを記録する機能を加えてもよい。したがって、開発者はデータ記録部53が記録したデータを解析することで、ウォッチドッグ処理が適切に行われているか否かや、ランタイムモニタ処理により記録された実行時間が適切か否かを判断することができる。表示部54は、データ記録部53が記録している内容の全て又は一部を順次、更新しながらディスプレイ35に表示する。仮に表示されないデータがあっても、開発者が操作することでデータ記録部53が記録しているデータを表示することができる。また、この他、表示部54は、命令レジスタ24、データメモリ26など、CPUシミュレータ200がオブジェクトとして保持しているデータであれば表示することができる。また、表示部54は、命令実行数、各命令の種類毎の実行数、実行時間等を表示できる。なお、図4に示したようなINTC、WDT、A/D等の周辺機器までをシミュレート可能なCPUシミュレータ200は、INTC等のレジスタの内容を模擬することもできる。したがって、本実施形態の故障再現装置100はCPUコア21の故障の再現に限られず、マイコンやECUの故障を再現することもできる。開発者は、例えば、D/Aに設定されたデジタル値を適正値と比較することで、D/Aが変換したアナログ値を使用するアクチュエータ等が想定どおりに動作しないことを検出できる。図8は、本実施形態の故障再現装置100の機能ブロック図の一例を示す。本実施形態の故障再現装置100は実行部52が2つのCPUコア21のシミュレートに対応していており、コア1用の実行部55及びコア2用の実行部56を有する。つまり、実行部52は、2つのCPUコア21のシミュレーションを並行して実行することができる。並行して実行するとは、故障再現装置100が2つのCPUコア21のシミュレーションを同時に実行するリソースを有すれば同時に実行し、そうでない場合には1命令ずつ交互に実行することをいう。本実施形態のコマンド入力受け付け部51は、開発者からの故障部位の指定を受け付け、実行部52に通知する。なお、必ずしも開発者が故障部位を指定する必要はなく、順番に又は無作為に全ての故障部位を実行部に通知するモジュールを設けておいてもよい。まず、コア1用の実行部55はアプリケーションソフトを実行していく。実行部52が有する照合モジュール12は、故障ライブラリ11から指定された故障部位を特定し、故障部位に対応づけられた故障時に影響が現れる動作を読み出し、コア1用の実行部55が実行する命令が一致するか否かを監視する。ここで一致とは、オペコードのみ、オペコード及びオペランドの一部、又は、オペコード及びオペランドの全て、のいずれかが一致することをいい、開発者がコマンド入力受け付け部51から設定できるようになっている。照合モジュール12は、コア1用の実行部55が実行する命令が故障時に影響が現れる動作と一致する場合、コア1用の実行部55に命令の実行を中止させ、故障挿入モジュール13に通知する。コア2用の実行部56は、コア1用の実行部55よりも数クロック遅れながら、アプリケーションソフトを実行している。数クロックは、故障時に影響が出る命令の実行完了に必要なサイクル数以上である。故障時に影響が出る命令は種々のものがあるが、命令のサイクル数は命令によって異なることが多い。このため、コア2用の実行部56は、命令が必要としうる最大のサイクル数遅れながら、アプリケーションソフトを実行する。図では、コア1用の実行部55がMOVE命令を実行している際、コア2用の実行部56はADD命令を実行している。故障挿入モジュール13は、故障ライブラリ11から指定された故障部位を特定し、故障部位に対応づけられた影響が現れた後の動作を読み出しておく。そして、照合モジュール12から通知を受けると、アプリケーションソフトの実行を中断し、故障が現れた後の動作をコア2用の実行部52が実行する故障時に影響の出る動作と置き換えて実行する。置き換えるには、命令レジスタの命令を故障が現れた後の動作で上書きすればよい。ただし、照合モジュールから通知された時点では、コア2用の実行部56がコア1用の実行部55よりも数クロック遅れているので、コア2用の実行部56は故障時に影響が現れる動作の手前の命令まで実行してから命令の実行を中断する。図の例ではST0[1]まで実行する。コア1用の実行部55に対しコア2用の実行部56が遅れているクロック数は既知なので、コア2用の実行部56はこの決まったクロック数正確にはこれより1つ少ないクロック数だけ命令の実行を継続する。または、コア2用の実行部56は照合モジュール12からコア1用の実行部55のPC22の値を取得し、その1つ手前の命令までを実行してもよい。故障挿入モジュール13は、コア2用の実行部56が故障が現れた後の動作のみを実行したタイミングで原則的にコア2の動作を停止する。原則的にと説明したのは、ジャンプ命令の場合、コア2用の実行部56がジャンプ先の命令を実行する準備が整うまでクロック数を消費する必要があるためである。よって、故障挿入モジュール13は、コア2用の実行部56が実行した故障が現れた後の動作がジャンプ命令か否かによって、コア2の動作を停止するまでのクロック数を可変にする。そして、故障挿入モジュール13は、データ記録部53が記録したコア2用の実行部56仮想的なコア2の各オブジェクトの状態を表す全てのデータコンテキストを照合モジュール12に出力する。すなわち、PC22の値、レジスタファイルの値、ステータスフラグの値、及び、スタックポインタレジスタの値などである。照合モジュール12は、PC22の値、レジスタファイルの値、ステータスフラグの値、及び、スタックポインタ等を仮想的なコア1のオブジェクトのPC22等に書き込む。これにより、コア1用の実行部55は、コア2用の実行部56が故障が現れた後の動作を実行した後の状態からアプリケーションソフトを実行できる。故障が現れた後の動作は故障部位が故障したことで生じた動作なので、故障部位が故障した場合にアプリケーションソフトの動作にどのような影響が生じるかを故障再現装置100がシミュレートすることができる。コア2用の実行部56は、例えばコア1用の実行部55から再開のタイミングを受け取り、故障が現れた後の動作を実行する前と同様に、数クロック遅れてアプリケーションソフトの実行を再開する。なお、再度、上述した処理をコア1用の実行部55とコア2用の実行部56が行う場合、コア2用の実行部56は故障が現れた後の動作の履歴の影響を受ける。コア1用の実行部55とコア2用の実行部56が全く同じ実行履歴であることが望まれる場合は、コア2用の実行部56は故障が現れた後の動作の履歴の影響を受けたままでよい。一方、例えば、開発者の設定により、コア2用の実行部56が故障が現れた後の動作の履歴の影響を受けることがないように、コア2用の実行部56が、故障が現れた後の動作を実行する前に、コンテキストを退避しておくことも可能である。そして、故障が現れた後の動作を実行した後にコンテキストをコア2用の実行部56に設定することが好ましい。この場合のコンテキストは、故障が現れた後の動作の1つ前の命令までのものである。したがって、コア2用の実行部56は、再開時に故障時に影響が現れる動作から実行を開始する。こうすることで、コア2用の実行部56は、故障が現れた後の動作を実行しなかった状態にできるので、故障が現れた後の動作の履歴の影響を受けることを防止でき、どの故障によりアプリケーションソフトの動作が影響されるかを特定しやすくできる。故障ライブラリ11の全ての故障部位が指定され、データ記録部53がウォッチドッグ処理やランタイムモニタ処理の処理結果を記録した場合、故障再現装置100は故障率を算出することができる。ウォッチドッグ処理が実行されていない場合やランタイムモニタ処理により得られた実行時間が規定を超えている場合、故障部位がアプリケーションソフトの動作から検出されたことになるためである。例えば、ISO26262では安全機構が持ち得る故障検出のカバー率DCを規定するが、このDCを算出できる。本実施形態の例ではDC=ウォッチドッグ処理やランタイムモニタ処理により検出された実行エラー/故障ライブラリに登録された故障部位の数である。軽微な故障まで故障ライブラリに登録することで分母が大きくなるとDCが下がる可能性がある。しかし、これは故障の粒度の問題であり、アプリケーションソフトの動作に影響のない故障を故障ライブラリに登録するか否かは開発者等が考慮することができる。適切な故障のみを考慮する一つの手法として、例えば、ゲートレベルでなく回路レジスタ、ALUなど単位で故障を登録する手法がある。また、開発者の指示などにより再現装置100が故障ライブラリの全ての故障部位を再現しない場合、DCはDC=ウォッチドッグ処理やランタイムモニタ処理により検出された実行エラー/再現装置が再現した故障部位の数となる。また、故障ライブラリ11の各故障部位に発生頻度情報を対応づけておき、故障再現装置100は開発者により設定された閾値以上の発生頻度情報の故障部位のみについて、故障を再現することが有効な場合がある。ISO26262ではハザード潜在的な好ましくない事象の対応に必要なASILAutomotiveSafetyIntegrityLevelが4段階に区分して規定されている。このASILの決定には、ハザードの発生頻度が考慮されることになっている。故障部位によりハザードが生じると仮定すれば、故障部位の発生頻度情報はASILと相関を持つと考えてよい。したがって、故障再現装置100が閾値以上の故障部位のみについて、故障を再現すれば、開発者はASILに応じた対応が可能になる。動作手順図9は、故障再現装置100が故障を再現する手順を示すフローチャート図の一例である。まず、コマンド入力受け付け部51は、故障部位の指定を受け付けるS10。照合モジュール12は、故障ライブラリ11から故障部位に対応づけられた故障時に影響が現れる動作を読み出し、故障挿入モジュール13は故障ライブラリ11から故障部位に対応づけられた故障が現れた後の動作を読み出すS20。コア1用の実行部55がアプリケーションソフトの実行を開始するとS30、その通知を受けたコア2用の実行部56が予め決まったクロック数遅れてアプリケーションソフトの実行を開始するS40。照合モジュール12は、アプリケーションソフトの実行対象の命令と故障時に影響が現れる動作とを逐次比較するS50。一致しない場合はS52のNo、比較を繰り返す。一致した場合にはS52のYes、照合モジュール12はコア1用の実行部55にアプリケーションソフトの実行を中断させるS60。また、故障挿入モジュール13は照合モジュールからの通知を受けて、コア2用の実行部56が故障時に影響が現れる動作の手前の命令まで実行した後、アプリケーションソフトの実行を中断させるS60。故障挿入モジュール13は、故障が現れた後の動作でコア2用の実行部56が実行する命令を置き換えるS70。故障挿入モジュール13は、故障が現れた後の動作をコア2用の実行部56が実行したら中断させるS80。故障挿入モジュール13は、コア2のコンテキストを照合モジュール12に通知するので、照合モジュールはコア1用の実行部55にコンテキストを設定してアプリケーションソフトの実行を再開させるS90。故障再現装置100は、以上の処理を繰り返し実行する。なお、1回のアプリケーションソフトの動作で、ステップS50の判定アプリケーションソフトの実行対象の命令と故障時に影響が現れる動作が複数回Yesとなる場合もある。この場合、全てのYesの判定で故障挿入モジュール13が故障を挿入してもよいが、開発者は任意の1回のみのYesの判定で故障を挿入するように設定することができる。任意の1回のみとは、S50でYesとなった際に照合モジュールが実際にYes側の処理を実行するか否かランダムに決定し、一度実際に処理したら、それ以降はS50でYesとなってもYes側の処理を実行しないことをいう。このような設定により、故障再現装置100は一過性の故障トランジェント故障の影響を再現可能になり、ISO26262が要求するトランジェント故障の考慮にも対応したものとなる。以上説明したように本実施形態の故障再現装置100は、故障ライブラリ11を予め用意しておくことで、ゲートレベルで故障が起こった場合の命令とCPUコアの動作の関係が明らかになるので、ゲートレベルで故障が起こった場合にアプリケーションの動作に現れる影響を評価することができる。故障再現装置100がシミュレーションを実行するために必要な時間は、ゲートレベルの故障の伝播をシミュレートするよりも高速であるので、実用的な時間で故障をシュミュレートすることができる。"