JP2004252585A - プログラム検証システム - Google Patents

Abstract

【課題】実機デバイスの完成を待たずにプログラム検証が可能であって、かつ、動作フリーズ等を起こさずにシステムの自動評価を長時間安定して行えるプログラム検証システムを提供する。
【解決手段】ＩＣＥ４００と、実機デバイス１５０に対応した検証動作を行うようＩＣＥを制御する検証制御部３００と、仮想デバイス１００からの制御信号等を検証制御部３００に適合させるブリッジ５０４と、実機デバイス１５０に対するプログラム４１０の入出力動作に同期させて、同期化ＲＡＭ４０４と実機用ユーザＲＡＭ４０２との間のデータ転送を制御する仮想・実機同期処理部４１２とを備え、ブリッジ５０４内に、検証制御部３００からの検証動作指示が正常に処理されているかを判断する監視部を備えたプログラム検証システム。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、ＩＣＥを用いてマイコンプログラムの動作検証を行うプログラム検証システムであって、特に、プログラム実行に必要な周辺デバイスとして実機デバイスと仮想デバイスとを用いるプログラム検証システムに関する。
【０００２】
【従来の技術】
図１４に、従来の実機デバッグセットの一例を示す。図１４に示すように、シングルチップマイコン制御用アプリケーションプログラムの評価は、ターゲットとなるシングルチップマイコンの代わりに、シングルチップマイコンの全機能をエミュレートできるインサーキットエミュレータ（以下ＩＣＥと称する）４００をデバッグボード１８に組み込んだものを、ハードウェアで構成された実機デバッグセット（周辺デバイス１２０）に接続して行われていた。
【０００３】
しかし、このようなデバッグセットを用いる場合、プログラムのテストを行うためには、システムを動作させるハードウェアが先行完成していることが必須条件であるため、ソフトウェア開発の工程がハードウェア開発の進捗状況に大きく左右されるという問題があった。
【０００４】
この問題を解決するために、ターゲットとなるシングルチップマイコンのシミュレーションおよび周辺デバイスのシミュレーションを行うことで、実機を使わずに、プログラムを評価する方法が提案されている。
【０００５】
このようなシミュレーション方法の一例が、例えば特許文献１（特開平９−１１４７００号公報）に開示されている。特許文献１に開示されたシステムは、テスト／デバッグの対象となる組込みソフトウェアと、マイクロプロセッサユニット（ＭＰＵ）およびメモリを模擬するＭＰＵシミュレータと、入出力を模擬する入出力装置模擬部と、ＭＰＵと１つ以上の入出力装置を接続する信号線を模擬する入出力装置実行制御機構と、シミュレータの起動順序を記述した起動定義ファイルと、Ｉ／ＯモニタとＩ／Ｏモデルのプロセスを起動／終了する手段と、ユーザが全てのＩ／Ｏモデルのリソース情報を参照・変更できる手段と、Ｉ／ＯモデルとＩ／Ｏモニタの接続関係を表示する手段を持つ入出力模擬部操作環境とで構成されている。それぞれの構成要素は、複数のプロセスで構成され、仮想配線にて接続されている。このシミュレーション方法では、図１５に示す通り、実機周辺デバイス１２０を全て仮想デバイス１００にて実現する。
【０００６】
また、実機デバッグ方法とシミュレータデバッグ方法の両方の良いところを合わせた実機・シミュレータ混載システムの一例が、特許文献２（特開平８−６８１０号公報）に開示されている。特許文献２に開示されたシステムは、図１６に示す通り、ＩＣＥ６４を利用した実機デバッグセットと、仮想デバイス（シミュレーション部５０）との混載システムである。このシステムでは、シミュレーション部５０とＩＣＥ６４との入出力データの受渡しは、専用の実機インターフェースボード６０を用いて実現されている。
【０００７】
【特許文献１】
特開平９−１１４７００号公報
【０００８】
【特許文献２】
特開平８−６８１０号公報
【０００９】
【発明が解決しようとする課題】
しかし、従来の実機・シミュレータ混載システムでは、図１６に示したように、仮想デバイスとＩＣＥとの入出力データの受渡しを実現するために、専用のインターフェースボード６０を必要とする。このため、周辺デバイスの仕様変更等が発生した場合は、それに合わせてインターフェースボードを設計変更するために費用と時間が必要となるという問題があった。
【００１０】
本発明は、このような問題に鑑み、実機のハードウェア開発よりもプログラム開発の方が先行した場合でも実機デバイスの完成を待たずにプログラム検証が可能であって、かつ、動作フリーズ等を起こさずにシステムの自動評価を長時間安定して行えるプログラム検証システムを提供することを目的とする。
【００１１】
【課題を解決するための手段】
上記の目的を達成するために、本発明にかかるプログラム検証システムは、マイコンの周辺デバイスとして実機デバイスおよび仮想デバイスを用いて、前記マイコン用プログラムの動作を検証するプログラム検証システムであって、前記マイコン上の前記プログラムの動作をエミュレーションするエミュレータと、前記実機デバイスに対応した検証動作を行うよう前記エミュレータを制御する検証制御部と、前記検証制御部と前記仮想デバイスとの間に設けられ、前記仮想デバイスからの制御信号およびデータを前記検証制御部に適合させるブリッジ部と、前記実機デバイスと前記プログラムとの間の入出力データを格納する実機用ＲＡＭと、前記実機用ＲＡＭと前記仮想デバイスとの間に設けられた同期化ＲＡＭと、前記実機デバイスに対する前記プログラムの入出力動作に同期させて、前記同期化ＲＡＭと前記実機用ＲＡＭとの間のデータ転送を制御する、仮想・実機同期処理部とを備えると共に、前記ブリッジ部内に、前記検証制御部からの検証動作指示が正常に処理されているかを判断する監視部を備えたことを特徴とする。
【００１２】
この構成は、実機のハードウェア開発よりもプログラム開発の方が先行した場合でも、実機デバイスの完成を待たずにプログラム検証を可能とするために、既存の実機デバイスの仕様に対応した検証制御部と、新規プログラムに対応する実機デバイスの仕様をソフトウェアによりシミュレーションする仮想デバイスとの間に、この仮想デバイスからの制御信号やデータを検証制御部に適合させるべく例えばコマンドやデータの変換等を行うブリッジ部を設けたものである。これにより、実機デバイスの完成を待たずに、新規プログラムの検証を行うことが可能となる。また、実機デバイスと仮想デバイスとの動作速度の違いを吸収するために、プログラムが使用する実機用ＲＡＭとは別に、同期化を行うための同期化ＲＡＭを設ける。さらに、同期化ＲＡＭと実機用ＲＡＭとのデータ転送を同期制御するために仮想・実機同期処理部を設ける。
【００１３】
これにより、例えば、主機能が共通であるがユーザインターフェース周り（操作と表示に関する部分）の仕様にバリエーションを有する、いわゆる展開機種の開発を行うような場合に、新たにデバッグ用の実機セットをハードウェアで作らずとも、既存の実機セットを利用しつつ仮想デバイスでシミュレーションすることが可能となる。また、従来のように、仮想デバイスとＩＣＥとの間で入出力データを受け渡しするための、専用のインターフェースボードを作成する必要もない。以上のように、本発明によれば、実機デバッグセットの完成を待たずして、効率良くプログラムの開発を行うことが可能なプログラム検証システムを提供できる。
【００１４】
さらに、検証制御部からの検証動作指示が正常に処理されているかを判断する監視部を備えたことにより、異常動作が生じた場合にこれを検知することができ、動作フリーズ等を起こさずにシステムの評価を長時間安定して行うことが可能となる。
【００１５】
本発明にかかるプログラム検証システムは、検証動作の手順を記載したシナリオファイルを記憶するシナリオファイル記憶部をさらに備え、前記検証制御部が、前記シナリオファイル記憶部から読み出したシナリオファイルに基づいて前記エミュレータを制御する構成とすることが好ましい。これにより、検証動作手順を手入力する手間が省け、入力ミスも防止できるので、検証作業を効率的にかつ高精度に行うことが可能となる。
【００１６】
本発明にかかるプログラム検証システムは、前記検証動作指示がリスタートコマンドであり、前記監視部が、前記リスタートコマンドが所定時間以内に処理されたか否かを判断する構成とすることが好ましい。
【００１７】
この構成によれば、例えば、検証制御部からリスタートコマンドが発行された後、エミュレータやデバッグ対象プログラムに対して確実にリセット処理がされたかを確認することが可能になる。
【００１８】
本発明にかかるプログラム検証システムは、前記検証動作指示がキー実行コードであり、前記監視部が、前記キー実行コードが所定時間以内に処理されたか否かを判断する構成とすることが好ましい。
【００１９】
このように、各キーイベントに対してキー処理時間制限を付けることで、デバッグ対象プログラムのバグ等により、デバッグ対象プログラムが無限ループ等に陥った場合に、次の処理が行えなくなることを回避できる。例えば、制限時間内にキー実行コードの処理が行われなければ、次の検査項目の処理を行う様に回避策を入れることにより、検査項目全てを実行することが可能になる。
【００２０】
本発明にかかるプログラム検証システムは、前記検証動作指示がシーケンス実行コードであり、前記監視部が、前記シーケンス実行コードが所定時間以内に処理されたか否かを判断することが好ましい。
【００２１】
これにより、各シーケンス実行コードに対してシーケンスが実行完了したかどうかの判断を行うことにより、シーケンスの検証動作が停止した場合でも、例えば次のシーケンスの検証を行う等の回避策を講ずることが可能となる。これにより、さらに効率良く検証を行えると共に、自動検証作業の信頼性の向上が可能となる。
【００２２】
本発明にかかるプログラム検証システムは、前記仮想デバイスに対する前記エミュレータの入出力データを取得するデータ取得部をさらに備え、前記ブリッジ部内に、前記データ取得部によるエミュレータ入出力データの取得タイミングを制御するデータ取得タイミング制御部をさらに備えたことが好ましい。
【００２３】
この構成によれば、検証制御部から送られるキーのメッセージに対してエミュレータ入出力データの取得タイミングの同期がとれるため、例えば、仮想デバイスで模擬される実機の表示状態においてフラッシング等の表示の点滅（オン／オフ）がある場合に、表示画像が「オフ」の時にデータ取得せず、「オン」の時に確実にデータ取得できる。これにより、自動検証精度を向上できる。
【００２４】
本発明にかかるプログラム検証システムは、上記のシナリオファイル記憶部を備えた構成において、前記ブリッジ部内に、前記監視部により異常動作が発見された場合、検証動作の手順を、前記シナリオファイル記憶部からではなく前記仮想デバイスから入力するよう切り替える切替設定部をさらに備えたことが好ましい。
【００２５】
これにより、シナリオファイルを用いた自動検証作業の途中に異常動作を発見した場合等に、自動検証を一時中断して、仮想デバイスからの入力による手動検証に切り替えることが可能になる。
【００２６】
【発明の実施の形態】
最初に、以下の各実施形態で共通する構成および用語について、図１を参照しながら説明する。
【００２７】
プログラム４１４は、マイコン上で動作するプログラムとして開発されたものであり、本発明にかかるプログラム検証システムにおいてデバッグ対象となるプログラムである。
【００２８】
実機プログラム４１０とは、デバッグ対象のプログラム４１４と、同期化プログラム４１２とを含む。同期化プログラム４１２は、実機のマイコンには搭載されず、プログラム検証システムにおいてのみ用いられ、後に詳述するが、仮想デバイス１００からユーザＲＡＭ４０２へのデータ書き込みを、実機デバイス１５０からのデータ書き込みと同期させる処理を行う。
【００２９】
リスタートとは、シナリオファイル３５２や仮想入力１０２から取得するシーケンスキーがリセットのコードであれば、マイコン制御をリセットさせ、自動検証システムを再スタートさせることである。
【００３０】
周辺デバイス１２０とは、プログラム４１４の動作検証に必要な入出力デバイスであり、実機デバイス１５０と仮想デバイス１００とを含む。実機デバイス１５０とは、プログラム４１４が搭載される実機の入出力デバイス（ハードウェアそのもの）である。これに対して、仮想デバイス１００は、プログラム４１４が搭載される実機のハードウェアをソフトウェアでシミュレーションするものである。
【００３１】
ＩＣＥ４００は、プログラム４１４を実行検証するために、プログラム４１４が搭載される実機の組み込みマイコンをエミュレートするインサーキットエミュレータ（ｉｎ ｃｉｒｃｕｉｔ ｅｍｕｌａｔｏｒ）であり、マイコンエミュレータ４０６、ユーザＲＡＭ４０２、および同期化ＲＡＭ４０４を含む。ユーザＲＡＭ４０２は、実機デバイス１５０とプログラム４１４との間の入出力データを格納するＲＡＭであり、同期化ＲＡＭ４０４は、後に詳述するが、仮想デバイス１２０からユーザＲＡＭ４０２へ書き込むべきデータを一時的に格納するＲＡＭである。
【００３２】
ＩＣＥ４００の動作は、デバッガ５００により制御される。デバッガ５００は、ブリッジ５０４およびＩＣＥデバッガ５０６（検証制御部）を含む。ＩＣＥデバッガ５０６は、実機デバイス１５０の仕様に対応した検証動作をＩＣＥ４００に実行させるように設計されている。これに対して、ブリッジ５０４は、実機デバイス１５０の代わりに仮想デバイス１００を入出力デバイスとして用いた検証動作を可能とするために、仮想デバイス１００とＩＣＥ５０６との間で制御コマンドの変換等を行うものであり、ソフトウェアで実現される。
【００３３】
すなわち、本実施形態にかかるプログラム検証システムは、実機のハードウェア開発よりプログラム開発の方が先行した場合でも、実機デバイスの完成を待たずにプログラム検証を可能とするために、既存の実機デバイス１５０およびＩＣＥデバッガ５０６を用いながら、新規プログラム（プログラム４１４）に対応する実機デバイスの仕様をソフトウェアによりシミュレーションする仮想デバイス１００と、この仮想デバイス１００をＩＣＥデバッガ５０６に適合させるブリッジ５０４とを設けたものである。
【００３４】
仮想配線２０６とは、仮想デバイス１２０とデバッガ５００、並びに後の実施形態で説明する自動検証制御部等を、仮想的に接続する配線である。仮想デバイス１００およびデバッガ５００等を複数のパーソナルコンピュータで実現した場合は、この仮想配線２０６として、ネットワーク、ＵＳＢ、ＲＳ２３２Ｃ、ＩＥＥＥ１３９４を使用できる。また、仮想デバイス１００およびデバッガ５００等を、一台のパーソナルコンピュータ内で単独実行可能な複数のアプリケーションまたはプロセスとして実現した場合は、仮想配線２０６は、アプリケーションまたはプロセス間にて通信可能なＤＤＥ、ＣＯＭ等のデータ通信機能を利用して実現できる。なお、仮想配線２０６の具体的な実施形態は、本発明の発明者らによってなされた発明にかかる先の出願（特願２００１−２１９８８７号）に、詳しく開示されている。
【００３５】
仮想配線２０６による通信方法は、非同期通信または同期通信のどちらでもよい。非同期通信とは、データを通信相手に一方的に送信するだけで、返信がない通信方法である。同期通信とは、データを通信相手に送信した後、通信相手から返信データが返ってくるまで待っている通信方法である。
【００３６】
ＨＴＡとは、ＨＴＭＬ Ａｐｐｌｉｃａｔｉｏｎｓの略で、Ｗｅｂページで実行可能なさまざまな機能（ＨＴＭＬ、ＣＳＳ、スクリプト言語（Ｊａｖａ（登録商標、以下略）Ｓｃｒｉｐｔ、ＶＢＡ等）、Ｂｅｈａｖｉｏｒ）をサポートする。
【００３７】
ＡｃｔｉｖｅＸとは、Ｉｎｔｅｒｎｅｔ対応のＯＬＥドキュメントオブジェクトであるＡｃｔｉｖｅＸドキュメントや、Ｉｎｔｅｒｎｅｔアクセス機能を持ったクライアントアプリケーションを開発するためのＡＰＩである。
【００３８】
ＯＬＥとは、Ｏｂｊｅｃｔ Ｌｉｎｋｉｎｇ ａｎｄ Ｅｍｂｅｄｄｉｎｇの略で、アプリケーションが別のアプリケーションの機能を呼出して自分自身の機能のように利用したりできる。
【００３９】
（第１実施形態）
以下、本発明の一実施形態について、図１を用いて説明する。
【００４０】
本実施形態にかかるプログラム検証システムは、長時間動作を安定させ、検証システムの停止やデータ取得失敗を起こさないで、プログラム自動検証を行うことを目的とする。このため、図１に示すとおり、本プログラム検証システムは、検証結果ファイル３５０および記録制御部３０２と、シナリオファイル３５２と、これに対する読み書きを制御するシナリオ制御部３１４を備えている。なお、記録制御部３０２およびシナリオ制御部３１４により、プログラム自動検証を実現するための自動検証制御部３００が構成されている。
【００４１】
シナリオファイル３５２とは、プログラム４１４を自動的に検証するための操作手順（シナリオ）を記録したファイルであり、検証結果ファイル３５０と同様に、例えば、Ｍｉｃｒｏｓｏｆｔ社のＥｘｃｅｌ等を利用して実現することができる。自動検証制御部３００の制御プログラムは、ＨＴＡを利用して記述されている。また、検証結果ファイル３５０およびシナリオファイル３５２をＥｘｃｅｌで作成する場合、これらの読書きを自動検証制御部３００から行うために、ＯＬＥ機能を利用する。また、自動検証制御部３００と仮想配線２０６との間のデータ通信は、ＡｃｔｉｖｅＸを利用して実現できる。
【００４２】
以下、本プログラム検証システムの構成および動作について、具体的な説明を行う。
【００４３】
本プログラム検証システムは、ＩＣＥ４００内の表示用イメージデータの変化に基づいて、仮想出力１０４の表示を更新する。仮想出力１０４の表示画像は、クリップボード２００および検証結果書込部３０４を経由して検証結果ファイル３５０に記録され、予め検証結果ファイル３５０に記録されていた検証用の期待値データと自動比較される構成となっている。
【００４４】
＜シナリオからＩＣＥへのデータ転送の自動シーケンス＞
以下、本プログラム検証システムの自動検証処理について説明する。自動検証処理は、自動検証制御部３００が、シナリオファイル３５２からキーデータ等を読み出し、ＩＣＥ４００へ自動的に転送して実行させ、その実行結果を検証結果ファイル３５０へ書き込んで評価することにより行う。
【００４５】
シナリオファイル３５２には、動作検証に必要な操作情報（キーデータ等）が、検証手順に従ってあらかじめ記録されている。シナリオファイル３５２は、Ｅｘｃｅｌファイルを利用して、例えば、図１２に示すような状態遷移表として作成される。本プログラム検証システムでは、シナリオファイルに記述されている動作シーケンスに従って画面モードを所定の状態にした後、イベントであるキーの発行を実行して、各キー入力に対するアクション（有効または無効）の確認を行う。例えば、図１２に示すシナリオファイル３５２の場合、図１２中に示した実行順番に従い、まず、画面モードを”ＭＤＰＷＲＯＮ”にした状態で、”ＫＰＯＷＥＲ”、”ＫＣＨ ＵＰ”、”ＫＶＯＬ ＵＰ”、”ＫＭＥＮＵ”、”ＫＳＥＴ”のキー入力を順次行い、これらの各キー操作に対する仮想デバイスおよび実機デバイスの動作を検証する。そして、次に、画面モードを”ＭＤＭＥＮＵ”とした状態で、上述と同様に”ＫＰＯＷＥＲ”、”ＫＣＨ ＵＰ”、”ＫＶＯＬ ＵＰ”、”ＫＭＥＮＵ”、”ＫＳＥＴ”のキー入力を順次行い、仮想デバイスおよび実機デバイスの動作を検証する。以降、”ＭＤＴＩＭＥＲ”、”ＭＤＳＥＴ”、”ＭＤＴＥＳＴ”の各画面モードについて、同様に検証を行う。
【００４６】
ここで、図１２に示すシナリオファイル３５２を用いた自動検証処理の詳細について、画面モード”ＭＤＭＥＮＵ”の状態での各キー入力に対する動作検証を行う場合を例にとり、さらに具体的に説明する。自動検証制御部３００は、以下の（１）〜（９）の手順により、画面モード”ＭＤＭＥＮＵ”の状態でのキー入力に対する動作検証を行う。
【００４７】
（１）同期化ＲＡＭ４００内のリセット完了モニタ用フラグＲＡＭに”１”をセットする。
【００４８】
（２）ＩＣＥ４００にプログラム４１４を初期化させるために、シナリオ読込部３１６からデータ送信部３２０へ、リセットＧＯコマンド発行を指示する。なお、”リセットＧＯ”コマンドとは、ＩＣＥ４００に実機プログラム４１０の実行を停止させ初期化する”リセット”コマンドと、ＩＣＥ４００に実機プログラム４１０を最初から実行開始させる”ＧＯ”コマンドとを一連に実行させるものである。データ送信部３２０は、同期通信により、ブリッジ５０４を経由してＩＣＥデバッガ５０６に対してリセットＧＯのメッセージを送る。ＩＣＥデバッガ５０６が、ＩＣＥ４００をリセットＧＯ実行させることにより、実機プログラム４１０がリセットスタートされる。実機プログラムリセットスタート実行の先頭プログラムで、前記のリセット完了モニタ用フラグＲＡＭ値を”０”にする。ＩＣＥ４００がリセットＧＯ完了すれば、ブリッジ５０４からデータ送信部３２０を経由して、シナリオ読込３１６部にリセットＧＯ完了通知を行う。
【００４９】
（３）リセット完了モニタ用フラグＲＡＭ値が”０”になったことを確認した後、画面モードを”ＭＤＭＥＮＵ”にするために、シナリオファイル３５２において当該画面モードの動作シーケンスに記述されているキーをシナリオ読込部３１６により順次読み込み、発行する。発行されたキーは、データ送信部３２０、バススロット３１２、仮想配線２０６、デバッガ５００を介して、ＩＣＥ４００へ渡される。図１２の例では、”ＭＤＭＥＮＵ”の動作シーケンスの最初の動作（図１２のシナリオファイルにおける動作１の欄）として”ＫＰＯＷＥＲ”というキーが記述されているので、このキーが最初に発行される。
【００５０】
（４）”ＫＰＯＷＥＲ”キーの処理を実機プログラム４１０が完了したかを、ユーザＲＡＭ４０２内の特定ＲＡＭにおける値の変化をチェックすることにより、確認する。特定ＲＡＭの変化が確認できると、次に、動作シーケンスの動作２に記述されている”ＫＭＥＮＵ”キーを発行し、上記と同様に、ユーザＲＡＭ４０２内の特定ＲＡＭの変化をチェックすることにより、”ＫＭＥＮＵ”キーの処理が完了したかを確認する。以上の処理を、シナリオファイル３５２の動作シーケンスに記述されている最後のキーまで、繰り返し実行する。図１２に示す”ＭＤＭＥＮＵ”の場合、”ＫＰＯＷＥＲ”キーおよび”ＫＭＥＮＵ”キーの実行により、目的の画面モードである”ＭＤＭＥＮＵ”になる。
【００５１】
（５）目的の画面モードになったら、まず、ユーザＲＡＭ４０２内の画像データを同期化ＲＡＭ４０４に取り込む。
【００５２】
（６）次に、シナリオファイル３５２に記述されている発行キーを、順次発行し、動作を検証する。図１２の例では、最初に、”ＫＰＯＷＥＲ”キーを発行する。”ＫＰＯＷＥＲ”キーの処理が完了したことを、ユーザＲＡＭ４０２内の特定ＲＡＭ値の変化で確認する。
【００５３】
（７）”ＫＰＯＷＥＲ”キーの処理が完了したことが確認できたら、この”ＫＰＯＷＥＲ”キーの処理結果を検証する。仮想出力１０４は、画面変化の有無を、イベント検出部３０８に伝える。イベント検出部３０８は、画面変化の有無が、シナリオファイル３５２に記述されている有効・無効仕様に合致するかを判断する。
【００５４】
例えば、図１２に示すシナリオファイルの場合、○記号は、当該画面モードにおける当該キー発行が有効であることを表し、×記号は、当該画面モードにおける当該キー発行が無効であることを表す。なお、「キー発行が有効である」とは、そのキー発行により画面上に何らかの変化が生じることをいい、「キー発行が無効である」とは、そのキー発行によっても画面に変化が生じないことをいう。
【００５５】
ここでは、”ＭＤＭＥＮＵ”の列と”ＫＰＯＷＥＲ”の行との交点にあたる欄には○記号が記述されているので、画面モードが”ＭＤＭＥＮＵ”である場合に”ＫＰＯＷＥＲ”キーを発行した場合、このキーが正しく処理されたならば、何らかの画面変化が生じるべきである。従って、”ＫＰＯＷＥＲ”キーの発行により画面変化が生じていれば、イベント検出部３０８は、”ＭＤＭＥＮＵ”画面モードにおける”ＫＰＯＷＥＲ”キーの有効・無効仕様は満たされているものと判断する。
【００５６】
イベント検出部３０８は、有効・無効仕様が満たされているか否かの判断結果に応じて、シナリオファイル３５２の有効・無効仕様欄に色付けする。すなわち、イベント検出部３０８が、シナリオファイル３５２に記述されている有効・無効仕様が満たされていると判断すれば、検証結果書込部３０４を介して、シナリオファイル３５２の当該有効・無効仕様欄の表示属性を例えば青色に設定し、満たされていないと判断した場合は例えば赤色に設定することにより異常動作であることが分かるようにする。これにより、デバッグ作業者は、シナリオファイル３５２の有効・無効仕様欄の表示色により、目標仕様が満たされているかを容易に識別することが可能となる。また、ここでは、有効・無効仕様の検証結果をシナリオファイル３５２に記録することとしたが、検証結果ファイル３５０に、有効・無効仕様の検証結果を記録する欄を別途設けるようにしてもよい。
【００５７】
（８）また、検証結果書込部３０４は、画像データ取得部３１０によりユーザＲＡＭ４０２から取得した画面データ（実行画像データ）を、検証結果ファイル３５０へ書き込む。さらに、検証結果書込部３０４は、前記実行画像データと、検証処理の実行に先立って予め作成されている基準画像データとを比較し、比較結果を検証結果ファイル３５０へ書き込む。基準画像データとは、キーが正しく処理された結果として表示されるべき画像データのダンプデータであり、図１３に示すように検証結果ファイル３５０へ書き込まれている。例えば図１３に示した例にかかる検証結果ファイル３５０では、基準画像データと実行画像データとの比較結果が一致すれば○記号、一致しなければ×記号が、「判定」の欄に書き込まれている。これにより、デバッグ作業者は、検証結果ファイル３５０の判定欄を見るだけで、キー発行により所定の画面データが表示されたか否かを容易に検証できる。
【００５８】
（９）また、検証結果ファイル３５０には、基準画像データに基づく画面イメージ（基準画面）が予め貼り付けられている。検証結果書込部３０４は、図１３に示すように、この基準画面の隣の列に、仮想出力１０４に出力された画面（実行画面）を、クリップボード２００を介して貼り付ける。これにより、デバッグ作業者は、検証結果ファイル３５０を見るだけで、基準画面と実行画面との違いを容易に識別することが可能となる。
【００５９】
”ＫＰＯＷＥＲ”キーについて上記の（９）までの処理が終了したら、（５）へ戻り、（６）においてシナリオファイルに記述されている次の発行キー”ＫＣＨＵＰ”を発行し、以降の処理を行う。同様にして、シナリオファイルに記述されている全ての発行キーについて、（５）〜（９）の処理を繰り返すことにより、図１３に示すような検証結果ファイルが完成する。
【００６０】
また、本実施形態では、自動検証処理中の何らかの要因によりＩＣＥ４００が異常動作になった場合に、自動検証処理が続行できなくなることを防ぐため、既存デバッガ５６２（図２参照）がＩＣＥ４００の挙動を監視する。そして、ＩＣＥ４００の動作に変化が発生した場合は、図１１に示すようなメッセージを、ＩＣＥデバッガ５０６が、ブリッジ５０４内のＩＣＥ状態モニタ５５８（図２参照）に伝える。さらに、このメッセージは、ＩＣＥ状態送信部５５６から、仮想配線２０６を介して、シナリオ制御部３１４内のタイミング制御部３１８に伝えられる。これにより、タイミング制御部３１８は、ＩＣＥ４００の動作変化に合わせて、シナリオ読込部３１６にシナリオファイル３５２のデータを再発行させる等の処理を行う。
【００６１】
なお、自動検証処理において、シナリオファイル３５２として前記の状態遷移表を用いる代わりに、シナリオファイル３５２の記述方法や自動検証制御部３００の制御方法を適宜変更することで、任意の自動検証処理を実現可能である。
【００６２】
＜具体的動作＞
以下、プログラム自動検証を行う本プログラム検証システムの動作について、さらに具体的に説明する。
【００６３】
＜初期化処理＞
本実施形態のプログラム検証システム（図１に示す構成）は、起動すると、まず、初期化処理を行う。仮想デバイス１００、デバッガ５００、及び自動検証制御部３００は、仮想配線２０６に接続するための接続処理を行う。また、ブリッジ５０４は、予め、データ送信部３２０および仮想出力１０４からのメッセージ受信を行うために、受信割込み許可しておく。
【００６４】
＜シナリオ読込から仮想配線へリセットＧＯコマンドデータを流す＞
シナリオ読込部３１６から、ＩＣＥ４００の実行を初期化するために、リセットＧＯコマンドの送信をデータ送信部３２０に指示する。データ送信部３２０は、図３に示すようなリセットＧＯコマンドのフォーマットに従って作成したメッセージを、ブリッジ５０４に宛てて、バススロット３１２から仮想配線２０６に同期通信にて送出する。
【００６５】
＜ブリッジデバイスの書込み処理＞
データ送信部３２０からデバッガ５００のバススロット５０２経由でブリッジ５０４に送られて来たメッセージは、図２に示す通り、受信割込み処理を行う同期受信部５５０に受け取られる。コマンド変換部５５２は、図３に示すようなテーブルを参照し、受け取ったメッセージが、１バイトメモリライト、１バイトメモリリード、ＩＣＥリセット、ＩＣＥ実行等のどのメッセージであるかを分析し、その結果をコマンド発行部５５４からＩＣＥデバッガ５０６内のＶｉｒｔｕａｌＬｉｎｋ５６０に渡す。
【００６６】
ＶｉｒｔｕａｌＬｉｎｋ５６０は、既存デバッガ５６２を制御して、ＩＣＥ４００にリセットコマンドを発行した後、実行開始コマンドを発行して、実行完了通知を同期受信部５５０の返信データとして、メッセージの送信元であるデータ送信部３２０に返信する。データ送信部３２０は、シナリオ読込部３１６にリセットＧＯコマンド実行完了を伝え、シナリオファイル３５２の内容に従った実行を行う。
【００６７】
＜シナリオファイルから仮想配線へのデータを流す＞
シナリオ読込部３１６は、シナリオファイル３５２からキーコードを読込んで、データ送信部３２０に指示して、図３に示すようなメッセージ一覧表内の１バイトメモリライトコマンド発行フォーマットに従って作成したメッセージを、ブリッジ５０４に宛てて、バススロット１０６から仮想配線２０６へ同期通信にて送出する。
【００６８】
＜ブリッジの書込み処理＞
データ送信部３２０から、バススロット５０２経由でブリッジ５０４に送られて来たメッセージは、図２に示す通り、受信割込み処理を行う同期受信部５５０に受け取られる。そして、コマンド変換部５５２が、図３に示すようなテーブルに基づき、受け取ったメッセージが、１バイトメモリライト、１バイトメモリリード、ＩＣＥリセット、ＩＣＥ実行等のどのメッセージであるかを分析する。その分析結果は、コマンド発行部５５４からＩＣＥデバッガ５０６内のＶｉｒｔｕａｌＬｉｎｋ５６０に渡される。
【００６９】
ＶｉｒｔｕａｌＬｉｎｋ５６０は、既存デバッガ５６２を制御して、プログラム４１４を実行中のＩＣＥ４００内の同期化ＲＡＭ４０４に、仮想入力１０２から渡された指定ＲＡＭアドレスのＲＡＭデータをオンザフライにて書込んだ後、書込み完了通知を、同期受信部５５０の返信データとして、メッセージの送信元であるデータ送信部３２０へ返信する。返信を受けると、キーデータを配信したことを、実行状況配信部３２２からイベント検出部３０８に伝える。
【００７０】
＜リセットコードの判定およびコマンド変換処理＞
自動検証制御部３００から、仮想配線２０６およびバススロット５０２経由でブリッジ５０４に送られて来たリセットコードは、図２に示す通り、ブリッジ５０４内で受信割込み処理を行う同期受信部５５０で受け取られる。ここで、リセットコードを受け取ったコマンド変換部５５２が行うコマンド変換処理の内容を、図６に示す。
【００７１】
図６に示すように、コマンド変換部５５２は、受け取ったリセットコードの種類を判断し（ステップＳ６０）、リセットコードの種類に応じた処理を行う。
【００７２】
（１）リスタートコードの場合
受け取ったリセットコードがリスタートコードであった場合、コマンド変換部５５２は、リスタート初期化処理（ステップＳ６１１）を行い、コマンド変換部５５２内に設けられたリスタート判定部（図示せず）により、リスタートの完了確認フラグが一定時間以内にセットされたか否かを判定するリスタート判定処理（ステップＳ６１２）を行う。リスタート判定処理の結果は、「受付異常」または「リスタートＯＫ」のいずれかを表す返信データとして、コマンド発行部５５４へ返信される（ステップＳ６９）。
【００７３】
リスタート判定処理の内容を、図７に示す。リスタート初期化処理（ステップＳ６１１）の後、図７に示すように、リスタートの完了確認フラグがセットされたか判断し（ステップＳ６１２ａ）、フラグがセットされていれば、返信データの内容に、「リスタートＯＫ」を表すデータをセットする（ステップＳ６１２ｂ）。フラグがセットされていなければ、予め設定された所定の時間以内であるか否かを判断し（ステップＳ６１２ｃ）、時間内であればステップＳ６１２ａへ戻る。前記所定の時間を越えた場合は、返信データの内容に、「受付異常」を表すデータをセットする（ステップＳ６１２ｄ）。
【００７４】
（２）キー実行コードの場合
受け取ったリセットコードがキー実行コードであれば、コマンド変換部５５２は、イベントキーの発行初期化処理（ステップＳ６２１）を行い、コマンド変換部５２２内に設けられたキー実行判定部（図示せず）により、イベントキー発行が一定時間以内に行われたか否かを判定するキー実行判定処理（ステップＳ６２２）を行う。キー実行判定処理の結果は、コマンド発行部５５４へ返信される（ステップＳ６９）。
【００７５】
キー実行判定処理の内容を、図８に示す。イベントキーの発行初期化処理（ステップＳ６２１）の後、図８に示すように、イベントキーが発行されたか判断し（ステップＳ６２２ａ）、イベントキーが発行されていれば、コマンド発行部５５４への返信データとして表示画像を取得し（ステップＳ６２２ｂ）、コマンド変換部５２２内に設けられたフラグセット部（図示せず）によってフラッシングフラグをセットする（ステップＳ６２２ｃ）。ステップＳ６２２ａにおいてイベントキーが発行されていないと判断されれば、予め設定された所定の時間以内であるかを判断し（ステップＳ６２２ｄ）、時間内であればステップＳ６２２ａへ戻る。前記所定の時間を越えた場合は、コマンド発行部５５４への返信データの内容に、「応答なし」を表すデータをセットする（ステップＳ６２２ｅ）。
【００７６】
なお、上述のフラッシングフラグは、検証プログラムにフラッシング表示仕様があれば、表示をフラッシングできるようにするためのフラグであり、図１０に示すように、実機プログラム内のリセット時の初期化処理の時に、フラグクリア部によってクリアされる。なお、フラグクリア部は、図２に示すコマンド変換部５５２内に設けられる（図示省略）。
【００７７】
（３）シーケンス実行コードの場合
受け取ったリセットコードがシーケンス実行コードであれば（ステップＳ６３０）、コマンド変換部５５２は、キー発行処理（ステップＳ６３１）を行い、コマンド変換部５２２内に設けられたシーケンス実行判定部（図示せず）により、キー発行が一定時間以内に行われたか否かを判定するシーケンス実行判定処理（ステップＳ６３２）を行う。シーケンス実行判定処理の結果は、「シーケンス実行異常」または「シーケンス実行ＯＫ」のいずれかを表す返信データとして、コマンド発行部５５４へ返信される（ステップＳ６９）。
【００７８】
シーケンス実行判定処理の内容を、図９に示す。キー発行処理（ステップＳ６３１）の後、図９に示すように、キーが発行されたか判断し（ステップＳ６３２ａ）、キーが発行されていれば、返信データの内容に、「シーケンス実行ＯＫ」を表すデータをセットする（ステップＳ６３２ｂ）。キーが発行されていなければ、予め設定された所定の時間以内であるか否かを判断し（ステップＳ６３２ｃ）、時間内であればステップＳ６３２ａへ戻る。前記所定の時間を越えた場合は、返信データの内容に、「シーケンス実行異常」を表すデータをセットする（ステップＳ６３２ｄ）。
【００７９】
以上の（１）〜（３）に説明したように、コマンド変換部５５２によりリセットコードに応じた返信データが作成され、コマンド発行部５５４へ返信される。コマンド発行部５５４は、その分析結果を、ＩＣＥデバッガ５０６内のＶｉｒｔｕａｌＬｉｎｋ５６０に渡す。
【００８０】
ＶｉｒｔｕａｌＬｉｎｋ５６０は、実機デバイス１５０の仕様に対応した検証動作を行うように設計されている既存デバッガ５６２を制御して、プログラム実行中のＩＣＥ４００内の同期化ＲＡＭ４０４に、仮想入力１０２から渡された指定ＲＡＭアドレスのＲＡＭデータを、オンザフライにて書込む。その後、同期受信部５５０が、前記メッセージへの返信としての書込み完了通知を、メッセージの送信元である仮想入力１０２へ返信する。なお、「オンザフライ」とは、プログラム４１４が実行中でも、ＩＣＥ４００内のユーザＲＡＭ４０２と同期化ＲＡＭ４０４のＲＡＭデータ、およびマイコンエミュレータ４０６内のレジスタの読書きを可能とする、ＩＣＥ４００の機能である。
【００８１】
このようにすれば、シーケンス実行時に、万一なんらかの理由で動作がフリーズした場合でも検証システムが止まることなく、長時間安定した動作検証することができ、検証精度を向上させることができる。
【００８２】
また、各テスト項目を実行する前にリセットを掛ければ、前テスト項目においてデバッグ対象プログラムのバグ等にて無限ループに陥った場合でもリスタートが可能となり、各項目のテストを行う事が可能になる。
【００８３】
＜同期化ＲＡＭからユーザＲＡＭへの転送処理＞
同期化プログラム４１２は、同期化ＲＡＭ４０４の変化を、プログラム４１４に必要なタイミングで、マイコンエミュレータ４０６にチェックさせている。
【００８４】
同期化プログラム４１２は、例えばキー入力の場合は、プログラム４１４のキー入力処理の直後に呼ばれ、同期化ＲＡＭ４０４内のキーデータＲＡＭの変化を、マイコンエミュレータ４０６経由でチェックし、もし変化が有れば、キーデータをユーザＲＡＭ４０２のキーデータ確定エリアに転送する。この際、仮想入力１０２のキーデータと実機デバイス１５０からのキーデータとが同時に入力された場合は、仮想入力１０２からのキーデータが優先される。
【００８５】
同期化プログラム４１２内のキー入力処理は、図４に示すように、仮想キー入力が、実機キー入力より優先されて処理される。
【００８６】
＜ユーザＲＡＭから仮想出力へのデータ転送＞
シナリオファイル３５２から読み込んだキーコードによってプログラム４１４がユーザＲＡＭ４０２内の出力ＲＡＭデータ（仮想出力１０４への出力データ）を変更した場合、この出力ＲＡＭデータを仮想出力１０４へ転送する方法は、以下の（ｃ１）〜（ｃ４）のとおりである。
【００８７】
（ｃ１）プログラムのユーザＲＡＭ変更；
プログラム４１４により、ユーザＲＡＭ４０２内の仮想出力１０４に関係するＲＡＭエリアが変更された直後に、ユーザＲＡＭ４０２から同期化ＲＡＭ４０４内の特定ＲＡＭに変化を伝えるための処理を行う。具体的には、図５に示す通り、プログラム４１４から仮想同期化ルーチンを呼び出すことにより、処理を開始する（ステップＳ４２０）。実機デバイス１５０への出力処理（ステップＳ４２２）を行った直後に、実機デバイス１５０への出力ＲＡＭデータの変化を検出し（ステップＳ４２４）、変化があれば、出力ＲＡＭデータをユーザＲＡＭ４０２から同期化ＲＡＭ４０４内に転送する（ステップＳ４２６）。
【００８８】
（ｃ２）仮想出力から仮想配線へデータを流す；
次に、仮想出力１０４から、同期化ＲＡＭ４０４内の出力ＲＡＭデータの変化イベントを読込むために、仮想出力１０４からデバッガ５００へのメッセージ転送の指定とイベントを読込むためのＲＡＭアドレスとを一緒に、バススロット１０８経由で、仮想配線２０６に同期通信により送出する。
【００８９】
（ｃ３）ブリッジデバイスの読込み処理；
仮想出力１０４からバススロット５０２経由でブリッジ５０４に送られて来たメッセージは、図２に示す通り、受信割込み処理を行う同期受信部５５０で受け取られる。その後、コマンド変換部５５２が、図３に示すようなメッセージ一覧表に従い、受け取ったメッセージが、１バイトメモリライト、１バイトメモリリード、ＩＣＥリセット、ＩＣＥ実行等のどのメッセージであるかを分析する。コマンド発行部５５４は、その分析結果を、ＩＣＥデバッガ５０６内のＶｉｒｔｕａｌＬｉｎｋ５６０に渡す。ＶｉｒｔｕａｌＬｉｎｋ５６０は、既存デバッガ５６２を制御して、プログラム実行中にＩＣＥ４００内の同期化ＲＡＭ４０４内の出力ＲＡＭデータをオンザフライにて読み込む。その後、読み込んだ出力ＲＡＭデータを、同期受信部５５０が、前記メッセージの送信元である仮想出力１０４へ返信する。これにより、出力ＲＡＭデータの仮想出力１０４への転送が、完了する。
【００９０】
（ｃ４）仮想出力の表示処理；
仮想出力１０４では、出力ＲＡＭデータを元に、パソコンモニタに、実機液晶画面を模した仮想表示等を行う。また、同期化ＲＡＭ４０４またはユーザＲＡＭ４０２から仮想出力１０４に取得した画像データの変化があれば、仮想出力１０４は、画像データ取得部３１０に対して、画像変化のメッセージおよび仮想出力１０４の表示ダンプデータを転送する。
【００９１】
また、前記イベントを使わずに、仮想入力１０２から一定周期にて、デバッガ５００にユーザＲＡＭ４０２のデータを読込み、仮想出力１０４にて実機液晶画面を模した仮想表示等を行う方法でも良い。
【００９２】
＜データ転送からイベント検出に転送＞
データ送信部３２０から前記キーデータが送られてくると、そのキーデータは、イベント検出部３０８から画像データ取得部３１０に渡される。また、同期化ＲＡＭ４０４またはユーザＲＡＭ４０２から仮想出力１０４に取得した画像データの変化が有れば、仮想出力１０４を経由して、画像データ取得部３１０に対して画像変化のメッセージおよび、仮想出力の表示ダンプデータを転送する。画像データ取得部３１０は、前記キーデータを検証結果書込部３０４から検証結果ファイル３５０に書込む。
【００９３】
また、画像データ取得部３１０は、仮想出力１０４から表示変化のメッセージを受けると、仮想出力１０４の表示画像を、クリップボード２００にキャプチャーする。クリップボード２００にキャプチャーされた画像は、検証結果書込部３０４により、検証結果ファイル３５０に対して書込まれる。
【００９４】
具体的には、図１３に示すように、キーデータは操作キーの欄に書込み、シナリオファイル３５２の画面モードは、画面モードの欄に書込む。
【００９５】
＜基準画像データと実行画像データとの比較＞
検証結果ファイル３５０において、「基準画像データ」と「実行画像データ」とのデータの相違を判定し、判定結果を「判定」の欄に「○」と「×」として書込む。なお、検証結果ファイル３５０をＥｘｃｅｌで作成する場合は、ＩＦ関数を用いて「基準画像データ」と「実行画像データ」の相違の判定を行うことができる。
【００９６】
＜基準画像データの作成＞
尚、自動検証処理を行うための基準画像およびその表示ダンプデータの作成については、前述したように画像データおよび表示ダンプデータを図１３に示す基準画面および実行画像データに書込むことで作成できる。
【００９７】
＜表示の出力抑制処理＞
また、本実施形態のプログラム検証システムでは、図１０（ｂ）に示すように、表示同期判定プログラムによって、実機プログラム内の出力処理でフラッシングフラグがセットされていれば仮想出力１０４へ出力しないようにする。なお、表示同期判定プログラムは、実機プログラム内に検証用プログラムとして埋め込む。このようにすれば、フラッシングフラグのタイミングにより表示出力するため、画像取得のタイミングが同期化される。このことにより、自動検証制御部３００から来るキーのメッセージに対して同期がとれるため、フラッシング等の表示の点滅がある場合に、仮想出力１０４の画像表示の記録時と完全に同期がとれるために、表示画像を「滅」の時にキャプチャーせず、「点」の時に確実にキャプチャーできるため、自動検証精度を向上できる。
【００９８】
＜仮想入力からの表示の出力抑制処理＞
なお、仮想デバイス１００からの入力からも画像キャプチャーの同期を行えるようにするために、図６に示すように、コマンド変換部５５２において通常のキーコードを受理した場合は、キー発行処理（ステップＳ６４１）およびキー受理処理（ステップＳ６４２）を行い、仮想デバイス１００からの入力がリセットキーであれば（ステップＳ６４３）、コマンド変換部５５２に設けられた表示同期化フラグクリア部（図示せず）によってフラッシングフラグをクリアする（ステップＳ６４４）。なお、ステップＳ６４２のキー受理処理とは、キー受付をしたかどうかを判定する処理である。これにより、仮想デバイス１００からのリセット時にも画像取得を同期化することができる。
【００９９】
このようにすれば、自動検証途中に異常動作を発見したときなど、自動検証を一時中断して手動検証する場合に、仮想デバイスからの入力に対して、通常の動作に切り替えて手動検査を行う事が可能になり、検証精度を向上させることができる。
【０１００】
以上のとおり、本実施形態によれば、長時間安定した動作が可能なプログラム自動検証システムを実現することができる。また、表示画像取得をキーと同期させることにより、画像のキャプチャーずれを防止することができる、これにより、検証精度および作業効率が向上する。
【０１０１】
【発明の効果】
以上のように、本発明によれば、万一なんらかの理由で動作がフリーズした場合でも自動検証システムが停止することなく、長時間安定して動作検証を行えると共に、検証精度を向上させることができる。
【図面の簡単な説明】
【図１】本発明の一実施形態にかかる実セット・シミュレータ混載のプログラム自動検証システムを示すブロック図
【図２】デバッガの内部構成を示すブロック図
【図３】仮想デバイスからブリッジへのメッセージ一覧の説明図
【図４】仮想から実機同期化フローチャート
【図５】実機から仮想同期化フローチャート
【図６】本発明の一実施形態にかかるプログラム自動検証システムにおけるコマンド変換処理の内容を示すフローチャート
【図７】図６のリスタート判定処理の内容を示すフローチャート
【図８】図６のキー実行判定処理の内容を示すフローチャート
【図９】図６のシーケンス実行判定処理の内容を示すフローチャート
【図１０】（ａ）および（ｂ）は本実施形態のプログラム自動検証システムにおける入出力処理のフローチャート
【図１１】ＩＣＥから仮想デバイスへ向けてのイベント一覧を示す説明図
【図１２】シナリオファイルの一例を示す説明図
【図１３】本検証結果ファイルの一例を示す説明図
【図１４】従来のプログラム検証システムの一例を示すブロック図
【図１５】従来のプログラム検証システムの一例を示すブロック図
【図１６】従来のプログラム検証システムの一例を示すブロック図
【符号の説明】
１００ 仮想デバイス
１０２ 仮想入力
１０４ 仮想出力
１２０ 周辺デバイス
１５０ 実機デバイス
１５２ 実入力
１５４ 実出力
１５６ 実機入出力
２００ クリップボード
２０６ 仮想配線
３００ 自動検証制御部
３０２ 記録制御部
３０４ 検証結果書込部
３０８ イベント検出部
３１０ 画像データ取得部
３１２ バススロット
３１４ シナリオ制御部
３１６ シナリオ読込部
３１８ タイミング制御部
３２０ データ送信部
３５０ 検証結果ファイル
３５２ シナリオファイル
４００ ＩＣＥ
４０２ ユーザＲＡＭ
４０４ 同期化ＲＡＭ
４１０ 実機プログラム
４１２ 同期化プログラム
５００ デバッガ
５０２ バススロット
５０４ ブリッジ
５０６ ＩＣＥデバッガ
５２２ コマンド変換部
５２４ コマンド発行部

Claims (7)

1. マイコンの周辺デバイスとして実機デバイスおよび仮想デバイスを用いて、前記マイコン用プログラムの動作を検証するプログラム検証システムであって、
   前記マイコン上の前記プログラムの動作をエミュレーションするエミュレータと、
   前記実機デバイスに対応した検証動作を行うよう前記エミュレータを制御する検証制御部と、
   前記検証制御部と前記仮想デバイスとの間に設けられ、前記仮想デバイスからの制御信号およびデータを前記検証制御部に適合させるブリッジ部と、
   前記実機デバイスと前記プログラムとの間の入出力データを格納する実機用ＲＡＭと、
   前記実機用ＲＡＭと前記仮想デバイスとの間に設けられた同期化ＲＡＭと、
   前記実機デバイスに対する前記プログラムの入出力動作に同期させて、前記同期化ＲＡＭと前記実機用ＲＡＭとの間のデータ転送を制御する、仮想・実機同期処理部とを備えると共に、
   前記ブリッジ部内に、前記検証制御部からの検証動作指示が正常に処理されているかを判断する監視部を備えたことを特徴とするプログラム検証システム。
2. 検証動作の手順を記載したシナリオファイルを記憶するシナリオファイル記憶部をさらに備え、
   前記検証制御部が、前記シナリオファイル記憶部から読み出したシナリオファイルに基づいて前記エミュレータを制御する、請求項１に記載のプログラム検証システム。
3. 前記検証動作指示がリスタートコマンドであり、
   前記監視部が、前記リスタートコマンドが所定時間以内に処理されたか否かを判断する、請求項１または２に記載のプログラム検証システム。
4. 前記検証動作指示がキー実行コードであり、
   前記監視部が、前記キー実行コードが所定時間以内に処理されたか否かを判断する、請求項１または２に記載のプログラム検証システム。
5. 前記検証動作指示がシーケンス実行コードであり、
   前記監視部が、前記シーケンス実行コードが所定時間以内に処理されたか否かを判断する、請求項１または２に記載のプログラム検証システム。
6. 前記仮想デバイスに対する前記エミュレータの入出力データを取得するデータ取得部をさらに備え、
   前記ブリッジ部内に、前記データ取得部によるエミュレータ入出力データの取得タイミングを制御するデータ取得タイミング制御部をさらに備えた、請求項１または２に記載のプログラム検証システム。
7. 前記ブリッジ部内に、前記監視部により異常動作が発見された場合、検証動作の手順を、前記シナリオファイル記憶部からではなく前記仮想デバイスから入力するよう切り替える切替設定部をさらに備えた、請求項２に記載のプログラム検証システム。

Images