JP4171240B2

JP4171240B2 - Program verification system

Info

Publication number: JP4171240B2
Application number: JP2002123082A
Authority: JP
Inventors: 克己鶴本; 司永木
Original assignee: Panasonic Corp; Matsushita Electric Industrial Co Ltd
Current assignee: Panasonic Corp; Panasonic Holdings Corp
Priority date: 2002-04-24
Filing date: 2002-04-24
Publication date: 2008-10-22
Anticipated expiration: 2022-04-24
Also published as: JP2003316603A

Description

【０００１】
【発明の属する技術分野】
本発明は、ＩＣＥを用いてマイコンプログラムの動作検証を行うプログラム検証システムであって、特に、プログラム実行に必要な周辺デバイスとして実機デバイスと仮想デバイスとを用いるプログラム検証システムに関する。
【０００２】
【従来の技術】
図１５に、従来の実機デバッグセットの一例を示す。図１５に示すように、シングルチップマイコン制御用アプリケーションプログラムの評価は、ターゲットとなるシングルチップマイコンの代わりに、シングルチップマイコンの全機能をエミュレートできるインサーキットエミュレータ（以下ＩＣＥと称する）４００をデバッグボード１８に組み込んだものを、ハードウエアで構成された実機デバッグセット（周辺デバイス１２０）に接続して行われていた。
【０００３】
しかし、このようなデバッグセットを用いる場合、プログラムのテストを行うためには、システムを動作させるハードウエアが先行完成していることが必須条件であるため、ソフトウエア開発の工程がハードウエア開発の進捗状況に大きく左右されるという問題があった。
【０００４】
この問題を解決するために、ターゲットとなるシングルチップマイコンのシミュレーションおよび周辺デバイスのシミュレーションを行うことで、実機を使わずに、プログラムを評価する方法が提案されている。
【０００５】
このようなシミュレーション方法の一例が、例えば特開平９−１１４７００号公報に開示されている。特開平９−１１４７００号公報に開示されたシステムは、テスト／デバッグの対象となる組込みソフトウエアと、マイクロプロセッサユニット（ＭＰＵ）およびメモリを模擬するＭＰＵシミュレータと、入出力を模擬する入出力装置模擬部と、ＭＰＵと１つ以上の入出力装置を接続する信号線を模擬する入出力装置実行制御機構と、シミュレータの起動順序を記述した起動定義ファイルと、Ｉ／ＯモニタとＩ／Ｏモデルのプロセスを起動／終了する手段と、ユーザが全てのＩ／Ｏモデルのリソース情報を参照・変更できる手段と、Ｉ／ＯモデルとＩ／Ｏモニタの接続関係を表示する手段を持つ入出力模擬部操作環境とで構成されている。それぞれの構成要素は、複数のプロセスで構成され、仮想配線にて接続されている。このシミュレーション方法では、図１６に示す通り、実機周辺デバイス１２０を全て仮想デバイス１００にて実現する。
【０００６】
また、実機デバッグ方法とシミュレータデバッグ方法の両方の良いところを合わせた実機・シミュレータ混載システムの一例が、特開平８−６８１０号公報に開示されている。特開平８−６８１０号公報に開示されたシステムは、図１７に示す通り、ＩＣＥ６４を利用した実機デバッグセットと、仮想デバイス（シミュレーション部５０）との混載システムである。このシステムでは、シミュレーション部５０とＩＣＥ６４との入出力データの受渡しは、専用の実機インターフェースボード６０を用いて実現されている。
【０００７】
【発明が解決しようとする課題】
しかし、従来の実機・シミュレータ混載システムでは、図１７に示したように、仮想デバイスとＩＣＥとの入出力データの受渡しを実現するために、専用のインターフェースボード６０を必要とする。このため、周辺デバイスの仕様変更等が発生した場合は、それに合わせてインターフェースボードを設計変更するために費用と時間が必要となり、プログラムのデバッグおよび検証を効率良く行えないという問題があった。
【０００８】
本発明は、上記の問題を解決するために、実機デバイスおよび仮想デバイスを周辺デバイスとして用いる場合に、効率良くプログラムの検証を行うことが可能なプログラム検証システムを提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記の目的を達成するために、本発明にかかるプログラム検証システムは、マイコンの周辺デバイスとして実機デバイスおよび仮想デバイスを用いて、前記マイコン用プログラムの動作を検証するプログラム検証システムであって、前記マイコン上の前記プログラムの動作をエミュレーションするエミュレータと、前記実機デバイスに対応した検証動作を行うよう前記エミュレータを制御する検証制御部と、前記検証制御部と前記仮想デバイスとの間に設けられ、前記仮想デバイスからの制御信号およびデータを前記検証制御部に適合させるブリッジ部と、前記実機デバイスと前記プログラムとの間の入出力データを格納する実機用ＲＡＭと、前記実機用ＲＡＭと前記仮想デバイスとの間に設けられた同期化ＲＡＭと、前記実機デバイスに対する前記プログラムの入出力動作に同期させて、前記同期化ＲＡＭと前記実機用ＲＡＭとの間のデータ転送を制御する、仮想・実機同期処理部とを備えたことを特徴とする。
【００１０】
この構成は、実機のハードウェア開発よりもプログラム開発の方が先行した場合でも、実機デバイスの完成を待たずにプログラム検証を可能とするために、既存の実機デバイスの仕様に対応した検証制御部と、新規プログラムに対応する実機デバイスの仕様をソフトウェアによりシミュレーションする仮想デバイスとの間に、この仮想デバイスからの制御信号やデータを検証制御部に適合させるべく例えばコマンドやデータの変換等を行うブリッジ部を設けたものである。これにより、実機デバイスの完成を待たずに、新規プログラムの検証を行うことが可能となる。また、実機デバイスと仮想デバイスとの動作速度の違いを吸収するために、プログラムが使用する実機用ＲＡＭとは別に、同期化を行うための同期化ＲＡＭを設ける。さらに、同期化ＲＡＭと実機用ＲＡＭとのデータ転送を同期制御するために仮想・実機同期処理部を設ける。
【００１１】
これにより、例えば、主機能が共通であるがユーザインターフェース周り（操作と表示に関する部分）の仕様にバリエーションを有する、いわゆる展開機種の開発を行うような場合に、新たにデバッグ用の実機セットをハードウェアで作らずとも、既存の実機セットを利用しつつ仮想デバイスでシミュレーションすることが可能となる。また、従来のように、仮想デバイスとＩＣＥとの間で入出力データを受け渡しするための、専用のインターフェースボードを作成する必要もない。以上のように、本発明によれば、実機デバッグセットの完成を待たずして、効率良くプログラムの開発を行うことが可能なプログラム検証システムを提供できる。
【００１２】
前記プログラム検証システムにおいて、前記仮想デバイスと前記ブリッジ部とを仮想配線により接続した構成とすることが好ましい。また、前記仮想デバイスを各機能毎に分けて複数備えた構成とすれば、他の自動検証システムにも各デバイスの再利用が容易に行えるという利点がある。
【００１３】
前記プログラム検証システムにおいて、前記実機デバイスにてモニタ出力される実機モニタ出力画像を撮影する撮影装置と、前記実機モニタ出力画像と前記仮想デバイスにてモニタ出力される仮想モニタ出力画像とを検証結果ファイルへ記録する検証結果書込部とをさらに備えた構成とすることが好ましい。
【００１４】
この構成によれば、例えば、新規プログラムを搭載すべき実機デバイスの試作機が完成した場合等に、プログラム検証のために当該実機デバイスの仕様に対応させて準備した仮想デバイスを利用して、完成した実機デバイスの動作検証を行うことができる。すなわち、同じ仕様の実機デバイスおよび仮想デバイスを動作させ、それらのモニタ出力画像を検証結果ファイルへ書き込む。これにより、開発担当者が、検証結果ファイルに書き込まれたモニタ出力画像を比較することにより、実機デバイスが目的の仕様を満たしているか否かを判定できる。また、異常があった場合、実機デバイスおよびプログラムのどちらに問題があるのかを把握することが容易になる。
【００１５】
さらに、この好ましい構成において、前記周辺デバイスにおける所定の変化を検出するイベント検出部と、前記イベント検出部の検出結果に従ったタイミングで、前記実機モニタ出力画像と前記仮想モニタ出力画像とを取り込む画像取得部とをさらに備えれば、例えば実機デバイスおよび仮想デバイスにおける入出力タイミングに合わせてモニタ出力画像を取り込むことができ、さらに効率良く検証を行うことが可能となる。
【００１６】
さらに、前記撮影装置を複数台備えた構成とすれば、より多くの情報を検証結果ファイルへ記録することが可能となり、例えば実機デバイスを複数種類有する機器等の検証の際に、検証精度を向上させることができる。
【００１７】
また、前記イベント検出部の検出結果に従い、前記実機モニタ出力画像または仮想モニタ出力画像を含む検証処理状況を検証処理状況を外部端末へ送信する検証状況配信部をさらに備えた構成とすることが好ましい。これにより、検証作業担当者が遠隔地に居る場合でも、リアルタイムで正確な情報が掴める。さらに、携帯情報端末等の外部端末から、制御信号およびその宛先を含むメッセージを受信し、受信したメッセージから前記制御信号を抽出し、当該制御信号の宛先へ配信するリモート制御部をさらに備えた構成とすればなお好ましい。これにより、プログラム自動検証作業中に何らかの問題が発生した場合に、プログラム検証システムをリモート制御することが可能となり、効率良いデバッグおよび検証が可能になる。
【００１８】
また、前記した各構成にかかるプログラム検証システムにおいて、プログラムを自動的に検証するための操作手順を記録したシナリオファイルからデータを読み込み、前記ブリッジ部へ転送するシナリオ制御部をさらに備えたことが好ましい。
【００１９】
この構成によれば、予め検証すべき操作手順が記録されたシナリオファイルからデータを読み込むことにより、仮想デバイスまたは実機デバイスから検証用の操作を行う必要がなくなり、本プログラム検証システムに自動的に検証作業を実行させることが可能となる。これにより、プログラム検証効率をさらに向上させることができる。
【００２０】
また、前記シナリオファイルから読み込んだデータの前記ブリッジ部への転送を、前記エミュレータの動作状況に合わせて制御するタイミング制御部をさらに備えた構成とすれば、なお好ましい。この構成によれば、例えば何らかの要因によりエミュレータが異常動作した場合等にも、タイミング制御部が、例えばシナリオファイルを再度読み込んでブリッジ部へ転送する等の制御を行う。これにより、自動検証作業の信頼性が向上する。
【００２１】
【発明の実施の形態】
最初に、以下の各実施形態で共通する構成および用語について、図１を参照しながら説明する。
【００２２】
プログラム４１４は、マイコン上で動作するプログラムとして開発されたものであり、本発明にかかるプログラム検証システムにおいてデバッグ対象となるプログラムである。
【００２３】
実機プログラム４１０とは、デバッグ対象のプログラム４１４と、同期化プログラム４１２とを含む。同期化プログラム４１２は、実機のマイコンには搭載されず、プログラム検証システムにおいてのみ用いられ、後に詳述するが、仮想デバイス１００からユーザＲＡＭ４０２へのデータ書き込みを、実機デバイス１５０からのデータ書き込みと同期させる処理を行う。
【００２４】
周辺デバイス１２０とは、プログラム４１４の動作検証に必要な入出力デバイスであり、実機デバイス１５０と仮想デバイス１００とを含む。実機デバイス１５０とは、プログラム４１４が搭載される実機の入出力デバイス（ハードウェアそのもの）である。これに対して、仮想デバイス１００は、プログラム４１４が搭載される実機のハードウェアをソフトウェアでシミュレーションするものである。
【００２５】
ＩＣＥ４００は、プログラム４１４を実行検証するために、プログラム４１４が搭載される実機の組み込みマイコンをエミュレートするインサーキットエミュレータ（in circuit emulator）であり、マイコンエミュレータ４０６、ユーザＲＡＭ４０２、および同期化ＲＡＭ４０４を含む。ユーザＲＡＭ４０２は、実機デバイス１５０とプログラム４１４との間の入出力データを格納するＲＡＭであり、同期化ＲＡＭ４０４は、後に詳述するが、仮想デバイス１２０からユーザＲＡＭ４０２へ書き込むべきデータを一時的に格納するＲＡＭである。
【００２６】
ＩＣＥ４００の動作は、デバッガ５００により制御される。デバッガ５００は、ブリッジ５０４およびＩＣＥデバッガ５０６（検証制御部）を含む。ＩＣＥデバッガ５０６は、実機デバイス１５０の仕様に対応した検証動作をＩＣＥ４００に実行させるように設計されている。これに対して、ブリッジ５０４は、実機デバイス１５０の代わりに仮想デバイス１００を入出力デバイスとして用いた検証動作を可能とするために、仮想デバイス１００とＩＣＥ５０６との間で制御コマンドの変換等を行うものであり、ソフトウェアで実現される。
【００２７】
すなわち、本実施形態にかかるプログラム検証システムは、実機のハードウェア開発よりもプログラム開発の方が先行した場合でも、実機デバイスの完成を待たずにプログラム検証を可能とするために、既存の実機デバイス１５０およびＩＣＥデバッガ５０６を用いながら、新規プログラム（プログラム４１４）に対応する実機デバイスの仕様をソフトウェアによりシミュレーションする仮想デバイス１００と、この仮想デバイス１００をＩＣＥデバッガ５０６に適合させるブリッジ５０４とを設けたものである。
【００２８】
仮想配線２０６とは、仮想デバイス１２０とデバッガ５００、並びに後の実施形態で説明する自動検証制御部等を、仮想的に接続する配線である。仮想デバイス１００およびデバッガ５００等を複数のパーソナルコンピュータで実現した場合は、この仮想配線２０６として、ネットワーク、ＵＳＢ、ＲＳ２３２Ｃ、ＩＥＥＥ１３９４を使用できる。また、仮想デバイス１００およびデバッガ５００等を、一台のパーソナルコンピュータ内で単独実行可能な複数のアプリケーションまたはプロセスとして実現した場合は、仮想配線２０６は、アプリケーションまたはプロセス間にて通信可能なＤＤＥ、ＣＯＭ等のデータ通信機能を利用して実現できる。なお、仮想配線２０６の具体的な実施形態は、本発明の発明者らによってなされた発明にかかる先の出願（特願２００１−２１９８８７号）に、詳しく開示されている。
【００２９】
仮想配線２０６による通信方法は、非同期通信または同期通信のどちらでもよい。非同期通信とは、データを通信相手に一方的に送信するだけで、返信がない通信方法である。同期通信とは、データを通信相手に送信した後、通信相手から返信データが返ってくるまで待っている通信方法である。
【００３０】
ＨＴＡとは、ＨＴＭＬＡｐｐｌｉｃａｔｉｏｎｓの略で、Ｗｅｂページで実行可能なさまざまな機能（ＨＴＭＬ、ＣＳＳ、スクリプト言語（Ｊａｖａ（登録商標、以下略）Ｓｃｒｉｐｔ、ＶＢＡ等）、Ｂｅｈａｖｉｏｒ）をサポートする。
【００３１】
ＡｃｔｉｖｅＸとは、Ｉｎｔｅｒｎｅｔ対応のＯＬＥドキュメントオブジェクトであるＡｃｔｉｖｅＸドキュメントや、Ｉｎｔｅｒｎｅｔアクセス機能を持ったクライアントアプリケーションを開発するためのＡＰＩである。
【００３２】
ＯＬＥとは、ＯｂｊｅｃｔＬｉｎｋｉｎｇａｎｄＥｍｂｅｄｄｉｎｇの略で、アプリケーションが別のアプリケーションの機能を呼出して自分自身の機能のように利用したりできる。後述の実施形態では、ＨＴＡからＭｉｃｒｏｓｏｆｔ社のＥｘｃｅｌアプリケーションを利用する例を説明する。
【００３３】
（第１実施形態）
以下、本発明の一実施形態について、図を用いて説明する。
【００３４】
本実施形態にかかるプログラム検証システムは、仮想デバイス１００とＩＣＥ４００との間の入出力データの転送および同期化を全てソフトウエアで実現し、周辺デバイス１２０およびＩＣＥ４００等をそれぞれ仮想配線２０６上に接続することで、プログラム４１４の検証目的に合わせて柔軟な対応を可能にしたシステム構成である。すなわち、図１７に示したような、ＩＣＥ６４とシミュレーション部５０との間に、ハードウエアで実現した専用のＩ／Ｆ６０を有する従来のシステムとは異なる構成である。
【００３５】
＜システム構成＞
本実施形態にかかるプログラム検証システムでは、図１等に示す通り、プログラム４１４の動作に必要な周辺デバイス１２０は、仮想デバイス１００および実機デバイス１５０により構成される。また、仮想デバイス１００およびデバッガ５００は、共に、仮想配線２０６に接続されている。
【００３６】
＜初期化処理＞
本プログラム検証システムは、起動すると、初期化処理を行う。初期化処理において、仮想デバイス１００およびデバッガ５００は、仮想配線２０６に接続するための接続処理を行う。また、デバッガ５００のブリッジ５０４は、予め、仮想デバイス１００の仮想入力１０２および仮想出力１０４からのメッセージ受信を行うために、受信割込み許可しておく。また、ＩＣＥ４００は、予め、プログラム４１４を実行状態にしておく。
【００３７】
＜仮想入力からＩＣＥへのデータ転送＞
仮想入力１０２からＩＣＥ４００へのデータ転送は、以下の（ａ１）〜（ａ３）のとおりに実行される。
【００３８】
（ａ１）仮想入力から仮想配線へのデータ送出；
仮想入力１０２にて発生した入力イベントは、デバッガ５００へのＲＡＭ書込みメッセージ転送を指定し、入力イベントデータを書込む同期化ＲＡＭ４０４のＲＡＭアドレスとＲＡＭデータとを、バススロット１０６経由で、仮想配線２０６へ同期通信にて送出する。
【００３９】
（ａ２）ブリッジの書込み処理；
仮想入力１０２から、仮想配線２０６およびバススロット５０２経由でブリッジ５０４に送られて来たメッセージは、図２に示す通り、ブリッジ５０４内で受信割込み処理を行う同期受信部５５０で受け取られる。その後、コマンド変換部５５２が、仮想入力１０２からのメッセージをＩＣＥデバッガ５０６が処理できるフォーマットに適合させるために、図３に示すようなメッセージ一覧表に従い、受け取ったメッセージが、１バイトメモリライト、１バイトメモリリード、ＩＣＥリセット、ＩＣＥ実行等のどのメッセージであるかを分析する。コマンド発行部５５４は、その分析結果を、ＩＣＥデバッガ５０６内のＶｉｒｔｕａｌＬｉｎｋ５６０に渡す。
【００４０】
ＶｉｒｔｕａｌＬｉｎｋ５６０は、実機デバイス１５０の仕様に対応した検証動作を行うように設計されている既存デバッガ５６２を制御して、プログラム実行中のＩＣＥ４００内の同期化ＲＡＭ４０４に、仮想入力１０２から渡された指定ＲＡＭアドレスのＲＡＭデータを、オンザフライにて書込む。その後、同期受信部５５０が、前記メッセージへの返信としての書込み完了通知を、メッセージの送信元である仮想入力１０２へ返信する。なお、「オンザフライ」とは、プログラム４１４が実行中でも、ＩＣＥ４００内のユーザＲＡＭ４０２と同期化ＲＡＭ４０４のＲＡＭデータ、およびマイコンエミュレータ４０６内のレジスタの読書きを可能とする、ＩＣＥ４００の機能である。
【００４１】
（ａ３）同期化ＲＡＭからユーザＲＡＭへの転送処理；
同期化プログラム４１２は、マイコンエミュレータ４０６に、同期化ＲＡＭ４０４に書込まれたデータの変化を、プログラム４１４に必要なタイミングでチェックさせている。
【００４２】
同期化プログラム４１２は、例えばキー入力の場合は、プログラム４１４のキー入力処理の直後に呼ばれ、キー入力データにより同期化ＲＡＭ４０４に生じる変化をマイコンエミュレータ４０６経由でチェックし、変化が有れば、キー入力データを、ユーザＲＡＭ４０２内に設けられたキー入力データ確定エリアに転送する。なお、仮想入力１０２のキーデータと実機入出力１５６からのキー入力データとが同時に入力された場合は、仮想キーデータが優先される。この処理の順番は、用途に合わせて、実機デバイス１５０からのキー入力データを優先する変更も可能である。
【００４３】
同期化プログラム４１２内のキー入力処理は、具体的には、図４に示す通り、プログラム４１４から同期化プログラム４１２を呼出すことにより開始される（ステップＳ４００）。まず、マイコンエミュレータ４０６経由にて仮想デバイス１００から転送され同期化ＲＡＭ４０４に格納されているキー入力データを読込み（ステップＳ４０２）、キー入力データの変化をチェックする（ステップＳ４０４）。
【００４４】
もし変化が有れば、キー入力データを、ユーザＲＡＭ４０２内に設けられた実機キー入力データ確定エリアに上書きする（ステップＳ４０６）。実機キー入力データ確定エリアとは、ユーザＲＡＭ４０２において、実機入出力１５６からキー入力されて確定されたデータが記録されるべき領域である。このように、実機キー入力データ確定エリアに仮想デバイス１００からのキー入力を上書きすることにより、仮想キー入力が、実機キー入力より優先されて処理される。
【００４５】
また、同期化ＲＡＭ４０４内の仮想デバイスから転送されたキーデータをクリアし（ステップＳ４０８）、周期的に呼ばれるキー処理にて連続データ処理されない様に対応している。もし連続キーを有効にする場合は、このステップＳ４０８を削除して、仮想入力１０２からキー押下時にＯＮキーデータを送信し、キーが離された時に、ＯＦＦキーデータを送信する様にすれば良い。
【００４６】
＜ユーザＲＡＭから仮想出力へのデータ転送＞
一方、仮想入力１０２からの入力データ等によって、プログラム４１４がユーザＲＡＭ４０２内の出力ＲＡＭデータを変更した場合、この出力ＲＡＭデータをユーザＲＡＭ４０２から仮想出力１０４へ転送する手順は、以下の（ｂ１）〜（ｂ４）のとおりである。
【００４７】
（ｂ１）プログラムのユーザＲＡＭ変更；
プログラム４１４により、ユーザＲＡＭ４０２内の仮想出力１０４に関係するＲＡＭデータが変更された直後に、ユーザＲＡＭ４０２から同期化ＲＡＭ４０４内の特定ＲＡＭに変化を伝えるための処理を行う。具体的には、図５に示す通り、プログラム４１４から仮想同期化プログラムを呼び出すことにより、処理を開始する（ステップＳ４２０）。プログラム４１４からユーザＲＡＭ４０２への出力処理（ステップＳ４２２）を行った直後に、ユーザＲＡＭ４０２における出力ＲＡＭデータの変化を検出し（ステップＳ４２４）、変化があれば、出力ＲＡＭデータをユーザＲＡＭ４０２から同期化ＲＡＭ４０４内に転送する（ステップＳ４２６）。
【００４８】
（ｂ２）仮想出力から仮想配線へのデータ送出；
次に、仮想出力１０４から、同期化ＲＡＭ４０４内の出力ＲＡＭデータの変化イベントを読込むために、仮想出力１０４からデバッガ５００へのメッセージ転送の指定とイベントを読込むためのＲＡＭアドレスとを一緒に、バススロット１０８経由で、仮想配線２０６に同期通信により送出する。
【００４９】
（ｂ３）ブリッジデバイスの読込み処理；
仮想出力１０４からバススロット５０２経由でブリッジ５０４に送られて来たメッセージは、図２に示す通り、受信割込み処理を行う同期受信部５５０で受け取られる。その後、コマンド変換部５５２が、図３に示すようなメッセージ一覧表に従い、受け取ったメッセージが、１バイトメモリライト、１バイトメモリリード、ＩＣＥリセット、ＩＣＥ実行等のどのメッセージであるかを分析する。コマンド発行部５５４は、その分析結果を、ＩＣＥデバッガ５０６内のＶｉｒｔｕａｌＬｉｎｋ５６０に渡す。ＶｉｒｔｕａｌＬｉｎｋ５６０は、既存デバッガ５６２を制御して、プログラム実行中にＩＣＥ４００内の同期化ＲＡＭ４０４内の出力ＲＡＭデータをオンザフライにて読み込む。その後、読み込んだ出力ＲＡＭデータを、同期受信部５５０が、前記メッセージの送信元である仮想出力１０４へ返信する。これにより、出力ＲＡＭデータの仮想出力１０４への転送が、完了する。
【００５０】
（ｂ４）仮想出力の表示処理；
仮想出力１０４は、出力ＲＡＭデータを元に、パソコンモニタに仮想ＬＣＤ表示等を行う。
【００５１】
また、上述したように同期化ＲＡＭ４０４の変化のイベントを使う代わりに、仮想入力１０２から一定周期にて、デバッガ５００にユーザＲＡＭ４０２のデータを読込むことにより、仮想出力１０４で仮想ＬＣＤ表示等を行うようにしてもよい。
【００５２】
＜効果＞
以上のように、本実施形態によれば、周辺デバイス１２０として実機デバイス１５０と仮想デバイス１００とを用い、ＩＣＥ４００内に同期化ＲＡＭ４０４を設け、仮想デバイス１００とＩＣＥ４００との同期化処理を全てソフトウエア（ブリッジ５０４および同期化プログラム４１２）で行うことが可能となる。これにより、実機デバッグセットの完成を待たずして、効率良くプログラムの開発が可能となる。
【００５３】
なお、本実施形態において、機能の異なる複数の仮想デバイス１００を、仮想配線２０６に接続した構成としてもよい。この構成によれば、他の自動検証システムにも各デバイスの再利用が容易に行えるという利点がある。
【００５４】
（第２実施形態）
ハードウェア開発よりもプログラム開発が先行している場合、実機デバッグセットが完成すれば、実機デバッグセットが正常に動作しているかを、開発中のプログラムを用いて動作検証することが必要になる。しかし、従来は、動作検証の際に実機デバッグセットが正常に動作しない場合、プログラムあるいは実機デバッグセットのどちらが悪いのかを判断することが難しく、解析に時間がかかるという問題もあった。
【００５５】
そこで、本発明の第２実施形態にかかるプログラム検証システムは、図６等に示す通り、プログラム４１４のプログラム動作に必要な実機デバイス１５０の実入力１５２および実出力１５４を、ＩＣＥ４００からデバッガ５００を経由して仮想配線２０６に接続した構成である。また、本プログラム検証システムは、実入力１５２および実出力１５４と同等な機能を仮想的に実現した仮想入力１０２および仮想出力１０４を、仮想配線２０６に接続した構成である。
【００５６】
また、本プログラム検証システムでは、実出力１５４の表示をＰＣカメラ２０４にて撮影し、このＰＣカメラ２０４で撮影された映像を表示するカメラモニタ２０２を、パソコンのモニタ上に設ける。また、実出力１５４と同等機能である仮想出力１０４の画像も、パソコンのモニタに表示する。
【００５７】
カメラモニタ２０２および仮想出力１０４の表示画像を記録するために、記録制御部３０２が、仮想入力１０２のキーコードをＩＣＥ４００に向けて転送した後、ＩＣＥ４００内の表示用イメージデータに合わせて表示する実出力１５４および仮想出力１０４の表示画像をクリップボード２００にコピーし、検証結果ファイル３５０に記録する。合わせて、その時の表示ダンプデータも、検証結果ファイル３５０に記録する構成となっている。
【００５８】
検証結果ファイル３５０は、実出力１５４と仮想出力１０４の実行結果をデバッグ作業者が目視で比較できるようにするためのアプリケーションファイルであり、例えば、Ｍｉｃｒｏｓｏｆｔ社のＥｘｃｅｌ（登録商標、以下略）等を利用して実現することができる。検証結果ファイル３５０の読み書きを制御する記録制御部３０２の制御プログラムは、ＨＴＡを利用して記述されている。また、検証結果ファイル３５０をＥｘｃｅｌで作成する場合、その読書きを記録制御部３０２から行うために、ＯＬＥ機能を利用する。また、記録制御部３０２と仮想配線２０６との間のデータ通信は、ＡｃｔｉｖｅＸを利用して実現できる。
【００５９】
＜初期化処理＞
本実施形態にかかるプログラム検証システムも、起動されると、まず初期化処理を行う。仮想デバイス１００、デバッガ５００、および記録制御部３０２は、仮想配線２０６に接続するための接続処理を行う。ブリッジ５０４は、仮想入力１０２および仮想出力１０４からのメッセージ受信を行うために、予め、受信割込みを許可しておく。ＩＣＥ４００は、予め、プログラム４１４を実行状態にしておく。イベント検出部３０８は、仮想入力１０２およびブリッジ５０４からのメッセージ受信を許可しておく。画像データ取得部３１０は、仮想出力１０４からのメッセージ受信を許可しておく。
【００６０】
＜実機デバッグセットの動作確認＞
本プログラム検証システムでは、例えば実出力１５４の動作確認を行うために、実出力１５４が完成するまでシミュレータによるプログラム評価に利用していた仮想出力デバイス１００と、完成した実出力１５４との動作比較を、以下のとおりに行うことができる。
【００６１】
＜仮想入力からＩＣＥへのデータ転送＞
仮想入力１０２からＩＣＥ４００にデータを転送する際の手順は、第１の実施形態で説明した（ａ１）〜（ａ３）とほぼ同じである。ただし、（ａ１）の手順において、仮想入力１０２が、デバッガ５００だけでなく、イベント検出３０８へもＲＡＭ書き込みメッセージ転送を指定する点のみが、第１の実施形態とは異なる。
【００６２】
＜ユーザＲＡＭから仮想出力へのデータ転送＞
仮想入力１０２からの入力データ等によって、プログラム４１４がユーザＲＡＭ４０２内の出力ＲＡＭデータを変更した場合、この出力ＲＡＭデータを仮想出力１０４へ転送する手順は、第１の実施形態で説明した（ｂ１）〜（ｂ４）とほぼ同じである。ただし、（ｂ４）の手順において、仮想出力１０４が、出力ＲＡＭデータをパソコンモニタに仮想ＬＣＤ表示等するだけでなく、出力ＲＡＭデータに変化があれば、イベント検出部３０８に対し、仮想配線２０６経由で画面変化のイベント及び表示ダンプデータを転送する点が、第１の実施形態と異なる。
【００６３】
＜仮想入力から画像コピーイベント検出＞
仮想入力１０２からキーイベントの発行を検出するために、イベント検出部３０８に、仮想入力１０２から仮想配線２０６経由にて、キーデータが送られてくる。イベント検出部３０８は、そのキーデータを、画像データ取得部３１０に渡す。また、同期化ＲＡＭ４０４またはユーザＲＡＭ４０２から仮想出力１０４に取得した画像データの変化が有れば、仮想出力１０４から画像データ取得部３１０に対して、画像変化のメッセージおよび仮想出力１０４の表示ダンプデータを転送する。
【００６４】
＜表示画像の記録＞
画像データ取得部３１０は、前記キーデータを、検証結果書込部３０４経由で、検証結果ファイル３５０に書込む。検証結果書込部３０４は、検証結果ファイル３５０の形式に適した方法で、データの読み書きを行う。
【００６５】
また、画像データ取得部３１０は、仮想出力１０４から表示変化のメッセージを受けると、キャプチャー制御部３０６に指示を出し、実出力１５４の画像データであるカメラモニタ２０２の画像を、クリップボード２００にキャプチャーする。また、仮想出力１０４の表示画像も、同様に、クリップボード２００にキャプチャーする。クリップボード２００にキャプチャーされた画像は、検証結果書込部３０４により、検証結果ファイル３５０に書込む。
【００６６】
検証結果ファイル３５０の具体例を、図７に示す。図７に示すように、検証結果ファイル３５０には、画面モードと操作キーとの組み合わせ毎に、仮想画面および実機画面のそれぞれの画像イメージと、それらの表示の際に仮想出力１０４から送られてきた表示ダンプデータとが、記録される。
【００６７】
図７に示す検証結果ファイル３５０からは、画面モードを“ＭＤＰＷＲＯＮ”として、“ＫＰＯＷＥＲ”という名称で定義されているキー操作（電源をＯＮにする操作）をした場合、仮想画面および実機画面の両方に何も表示されなかったことが分かる。また、“ＫＣＨＵＰ”という名称で定義されているキー操作により、画面右上方に“ＣＨ０３”という文字が表示され、さらに“ＫＶＯＬＵＰ”という名称で定義されているキー操作により、画面左下に“Ｖｏｌ２４”という文字が表示されたことが分かる。以上のキー操作の場合は、いずれも、仮想画面と実機画面との表示が一致している。しかし、“ＫＭＥＮＵ”という名称で定義されたキー操作に対しては、仮想画面において最上行に“ＭＥＮＵ”と表示されているのに、実機画面では“ＭＥＵ０”と表示されており、仮想画面と実機画面の表示状態が一致していない。これにより、“ＫＭＥＮＵ”のキー操作に関して、実機デバイス１５０にバグがあることが分かる。
【００６８】
なお、図７では模式的に示したが、実際には、検証結果ファイル３５０の「仮想画面」の欄には、クリップボード２００にキャプチャーされた仮想出力１０４の画像イメージそのものが貼り付けられる。また、「実機画面」の欄には、ＰＣカメラ２０４で撮影されカメラモニタ２０２からクリップボード２００にキャプチャーされた実出力１５４の画像イメージそのものが貼り付けられる。従って、これらの画像イメージを見比べることにより、デバッグ作業者が、仮想画面と実機画面との相違を容易に認識することが可能となる。
【００６９】
＜複数台のＰＣカメラを制御＞
また、図８に示すように、実出力１５４の状態を撮影するＰＣカメラ２０４に加えて、実機入出力１５６の状態を撮影するＰＣカメラ２０５をさらに設けて、実機デバイス１５０を撮影する構成としてもよい。なお、実機入出力１５６の状態とは、例えば、実機デバイス１５０へのキー入力が実機モニタにエコー表示される様子や、処理結果がモニタへ表示される様子等をいう。ＰＣカメラ２０４およびＰＣカメラ２０５には、カメラモニタ２０２およびカメラモニタ２０３をそれぞれ接続する。また、カメラモニタ２０２およびカメラモニタ２０３からクリップボード２００へキャプチャーすべきモニタ画像を選択するキャプチャー選択部３２４を記録制御部３０２にさらに設ける。これにより、より多くのモニタ画像を記録することが可能になる。
【００７０】
＜効果＞
以上のように、本実施形態では、新規に開発した実出力１５４の動作確認を行うために、この実出力１５４と同等の動作をする仮想出力１０４（動作検証済み）をＩＣＥ４００にて動作させて、実出力１５４および仮想出力１０４の実行結果を、デバッグ作業者が目視で確認できる状態で、検証結果ファイル３５０に書込む。これにより、実出力１５４と仮想出力１０４の動作比較が容易になり、実出力１５４のハードウエアの動作検証を効率良く行える。また、実機デバイス１５０の状態を撮影するためのＰＣカメラを複数台備えた構成とすれば、より多くの情報の記録が可能となり、検証精度を向上できる。
【００７１】
（第３の実施形態）
本発明の第３の実施形態にかかるプログラム検証システムと、第２の実施形態にかかるプログラム検証システムとの主な相違点は、本実施形態にかかるプログラム検証システムは、プログラム自動検証を行うことにある。このため、図９等に示すとおり、本プログラム検証システムは、第２の実施形態で説明した検証結果ファイル３５０および記録制御部３０２の他に、シナリオファイル３５２と、これに対する読み書きを制御するシナリオ制御部３１４とを備えている。なお、記録制御部３０２およびシナリオ制御部３１４により、プログラム自動検証を実現するための自動検証制御部３００が構成されている。
【００７２】
シナリオファイル３５２とは、プログラム４１４を自動的に検証するための操作手順（シナリオ）を記録したファイルであり、検証結果ファイル３５０と同様に、例えば、Ｍｉｃｒｏｓｏｆｔ社のＥｘｃｅｌ等を利用して実現することができる。自動検証制御部３００の制御プログラムは、ＨＴＡを利用して記述されている。また、検証結果ファイル３５０およびシナリオファイル３５２をＥｘｃｅｌで作成する場合、これらの読書きを自動検証制御部３００から行うために、ＯＬＥ機能を利用する。また、自動検証制御部３００と仮想配線２０６との間のデータ通信は、ＡｃｔｉｖｅＸを利用して実現できる。
【００７３】
以下、本プログラム検証システムの構成および動作について、具体的な説明を行う。
【００７４】
本プログラム検証システムは、ＩＣＥ４００内の表示用イメージデータの変化に基づいて、仮想出力１０４の表示を更新し、仮想出力１０４の表示画像をクリップボード２００経由にて検証結果ファイル３５０に記録し、予め検証結果ファイル３５０に記録されていた検証用の期待値データと自動比較する構成となっている。
【００７５】
＜シナリオからＩＣＥへのデータ転送の自動シーケンス＞
以下、本プログラム検証システムの自動検証処理について説明する。自動検証処理は、自動検証制御部３００が、シナリオファイル３５２からキーデータ等を読み出し、ＩＣＥ４００へ自動的に転送して実行させ、その実行結果を検証結果ファイル３５０へ書き込んで評価することにより行う。
【００７６】
シナリオファイル３５２には、動作検証に必要な操作情報（キーデータ等）が、検証手順に従ってあらかじめ記録されている。シナリオファイル３５２は、Ｅｘｃｅｌファイルを利用して、例えば、図１１に示すような状態遷移表として作成される。本プログラム検証システムでは、シナリオファイルに記述されている動作シーケンスに従って画面モードを所定の状態にした後、イベントであるキーの発行を実行して、各キー入力に対するアクション（有効または無効）の確認を行う。例えば、図１１に示すシナリオファイル３５２の場合、図１１中に示した実行順番に従い、まず、画面モードを“ＭＤＰＷＲＯＮ”にした状態で、“ＫＰＯＷＥＲ”、“ＫＣＨＵＰ”、“ＫＶＯＬＵＰ”、“ＫＭＥＮＵ”、“ＫＳＥＴ”のキー入力を順次行い、これらの各キー操作に対する仮想デバイスおよび実機デバイスの動作を検証する。そして、次に、画面モードを“ＭＤＭＥＮＵ”とした状態で、上述と同様に“ＫＰＯＷＥＲ”、“ＫＣＨＵＰ”、“ＫＶＯＬＵＰ”、“ＫＭＥＮＵ”、“ＫＳＥＴ”のキー入力を順次行い、仮想デバイスおよび実機デバイスの動作を検証する。以降、“ＭＤＴＩＭＥＲ”、“ＭＤＳＥＴ”、“ＭＤＴＥＳＴ”の各画面モードについて、同様に検証を行う。
【００７７】
ここで、図１１に示すシナリオファイル３５２を用いた自動検証処理の詳細について、画面モード“ＭＤＭＥＮＵ”の状態での各キー入力に対する動作検証を行う場合を例にとり、さらに具体的に説明する。自動検証制御部３００は、以下の（１）〜（９）の手順により、画面モード“ＭＤＭＥＮＵ”の状態でのキー入力に対する動作検証を行う。
【００７８】
（１）同期化ＲＡＭ４００内のリセット完了モニタ用フラグＲＡＭに“１”をセットする。
【００７９】
（２）ＩＣＥ４００にプログラム４１４を初期化させるために、シナリオ読込部３１６からデータ送信部３２０へ、リセットＧＯコマンド発行を指示する。なお、“リセットＧＯ”コマンドとは、ＩＣＥ４００に実機プログラム４１０の実行を停止させ初期化する“リセット”コマンドと、ＩＣＥ４００に実機プログラム４１０を最初から実行開始させる“ＧＯ”コマンドとを一連に実行させるものである。データ送信部３２０は、同期通信により、ブリッジ５０４を経由してＩＣＥデバッガ５０６に対してリセットＧＯのメッセージを送る。ＩＣＥデバッガ５０６が、ＩＣＥ４００をリセットＧＯ実行させることにより、実機プログラム４１０がリセットスタートされる。実機プログラムリセットスタート実行の先頭プログラムで、前記のリセット完了モニタ用フラグＲＡＭ値を“０”にする。ＩＣＥ４００がリセットＧＯ完了すれば、ブリッジ５０４からデータ送信部３２０を経由して、シナリオ読込３１６部にリセットＧＯ完了通知を行う。
【００８０】
（３）リセット完了モニタ用フラグＲＡＭ値が“０”になったことを確認した後、画面モードを“ＭＤＭＥＮＵ”にするために、シナリオファイル３５２において当該画面モードの動作シーケンスに記述されているキーをシナリオ読込部３１６により順次読み込み、発行する。発行されたキーは、データ送信部３２０、バススロット３１２、仮想配線２０６、デバッガ５００を介して、ＩＣＥ４００へ渡される。図１１の例では、“ＭＤＭＥＮＵ”の動作シーケンスの最初の動作（図１１のシナリオファイルにおける動作１の欄）として“ＫＰＯＷＥＲ”というキーが記述されているので、このキーが最初に発行される。
【００８１】
（４）“ＫＰＯＷＥＲ”キーの処理を実機プログラム４１０が完了したかを、ユーザＲＡＭ４０２内の特定ＲＡＭにおける値の変化をチェックすることにより、確認する。特定ＲＡＭの変化が確認できると、次に、動作シーケンスの動作２に記述されている“ＫＭＥＮＵ”キーを発行し、上記と同様に、ユーザＲＡＭ４０２内の特定ＲＡＭの変化をチェックすることにより、“ＫＭＥＮＵ”キーの処理が完了したかを確認する。以上の処理を、シナリオファイル３５２の動作シーケンスに記述されている最後のキーまで、繰り返し実行する。図１１に示す“ＭＤＭＥＮＵ”の場合、“ＫＰＯＷＥＲ”キーおよび“ＫＭＥＮＵ”キーの実行により、目的の画面モードである“ＭＤＭＥＮＵ”になる。
【００８２】
（５）目的の画面モードになったら、まず、ユーザＲＡＭ４０２内の画像データを同期ＲＡＭ４０４に取り込む。
【００８３】
（６）次に、シナリオファイル３５２に記述されている発行キーを、順次発行し、動作を検証する。図１１の例では、最初に、“ＫＰＯＷＥＲ”キーを発行する。“ＫＰＯＷＥＲ”キーの処理が完了したことを、ユーザＲＡＭ４０２内の特定ＲＡＭ値の変化で確認する。
【００８４】
（７）“ＫＰＯＷＥＲ”キーの処理が完了したことが確認できたら、この“ＫＰＯＷＥＲ”キーの処理結果を検証する。仮想出力１０４は、画面変化の有無を、イベント検出部３０８に伝える。イベント検出部３０８は、画面変化の有無が、シナリオファイル３５２に記述されている有効・無効仕様に合致するかを判断する。
【００８５】
例えば、図１１に示すシナリオファイルの場合、○記号は、当該画面モードにおける当該キー発行が有効であることを表し、×記号は、当該画面モードにおける当該キー発行が無効であることを表す。なお、「キー発行が有効である」とは、そのキー発行により画面上に何らかの変化が生じることをいい、「キー発行が無効である」とは、そのキー発行によっても画面に変化が生じないことをいう。
【００８６】
ここでは、“ＭＤＭＥＮＵ”の列と“ＫＰＯＷＥＲ”の行との交点にあたる欄には○記号が記述されているので、画面モードが“ＭＤＭＥＮＵ”である場合に“ＫＰＯＷＥＲ”キーを発行した場合、このキーが正しく処理されたならば、何らかの画面変化が生じるべきである。従って、“ＫＰＯＷＥＲ”キーの発行により画面変化が生じていれば、イベント検出部３０８は、“ＭＤＭＥＮＵ”画面モードにおける“ＫＰＯＷＥＲ”キーの有効・無効仕様は満たされているものと判断する。
【００８７】
イベント検出部３０８は、有効・無効仕様が満たされているか否かの判断結果に応じて、シナリオファイル３５２の有効・無効仕様欄に色付けする。すなわち、イベント検出部３０８が、シナリオファイル３５２に記述されている有効・無効仕様が満たされていると判断すれば、検証結果書込部３０４を介して、シナリオファイル３５２の当該有効・無効仕様欄の表示属性を例えば青色に設定し、満たされていないと判断した場合は例えば赤色に設定することにより異常動作であることが分かるようにする。これにより、デバッグ作業者は、シナリオファイル３５２の有効・無効仕様欄の表示色により、目標仕様が満たされているかを容易に識別することが可能となる。また、ここでは、有効・無効仕様の検証結果をシナリオファイル３５２に記録することとしたが、検証結果ファイル３５０に、有効・無効仕様の検証結果を記録する欄を別途設けるようにしてもよい。
【００８８】
（８）また、検証結果書込部３０４は、画像データ取得部３１０によりユーザＲＡＭ４０２から取得した画面データ（実行画像データ）を、検証結果ファイル３５０へ書き込む。さらに、検証結果書込部３０４は、前記実行画像データと、検証処理の実行に先立って予め作成されている基準画像データとを比較し、比較結果を検証結果ファイル３５０へ書き込む。基準画像データとは、キーが正しく処理された結果として表示されるべき画像データのダンプデータであり、図１２に示すように検証結果ファイル３５０へ書き込まれている。例えば図１２に示した例にかかる検証結果ファイル３５０では、基準画像データと実行画像データとの比較結果が一致すれば○記号、一致しなければ×記号が、「判定」の欄に書き込まれている。これにより、デバッグ作業者は、検証結果ファイル３５０の判定欄を見るだけで、キー発行により所定の画面データが表示されたか否かを容易に検証できる。
【００８９】
（９）また、検証結果ファイル３５０には、基準画像データに基づく画面イメージ（基準画面）が予め貼り付けられている。検証結果書込部３０４は、図１２に示すように、この基準画面の隣の列に、仮想出力１０４に出力された画面（実行画面）を、クリップボード２００を介して貼り付ける。これにより、デバッグ作業者は、検証結果ファイル３５０を見るだけで、基準画面と実行画面との違いを容易に識別することが可能となる。
【００９０】
“ＫＰＯＷＥＲ”キーについて上記の（９）までの処理が終了したら、（５）へ戻り、（６）においてシナリオファイルに記述されている次の発行キー“ＫＣＨＵＰ”を発行し、以降の処理を行う。同様にして、シナリオファイルに記述されている全ての発行キーについて、（５）〜（９）の処理を繰り返すことにより、図１２に示すような検証結果ファイルが完成する。
【００９１】
また、本実施形態では、自動検証処理中の何らかの要因により、ＩＣＥ４００が異常動作になった場合に、自動検証処理が続行できなくなることを防ぐため、既存デバッガ５６２がＩＣＥ４００の挙動を監視する。そして、ＩＣＥ４００の動作に変化が発生した場合は、図１３に示すようなメッセージを、ＩＣＥデバッガ５０６が、ブリッジ５０４内のＩＣＥ状態モニタ５５８（図２参照）に伝える。さらに、このメッセージは、ＩＣＥ状態送信部５５６から、仮想配線２０６を介して、シナリオ制御部３１４内のタイミング制御部３１８に伝えられる。これにより、タイミング制御部３１８は、ＩＣＥ４００の動作変化に合わせて、シナリオ読込部３１６にシナリオファイル３５２のデータを再発行させる等の処理を行う。
【００９２】
以上のとおり、本実施形態によれば、プログラム自動検証を実現することができる。
【００９３】
＜リモート制御＞
また、図１０に示すように、記録制御部３０２内に自動検証処理の実行状況を配信する実行状況配信部３２２を設けると共に、外部装置との間で電子メールの送受信を行う電子メール送受信部６０２をさらに設けた構成としてもよい。この構成により、実行状況配信部３２２から電子メール送受信部６０２を経由して、自動検証処理の実行状況を携帯情報端末６０４等に電子メールにて配信すれば、し、自動検証処理の実行状況を遠隔地からリアルタイムでモニタすることが可能となる。
【００９４】
そして、自動検証処理の実行中に、プログラム４１４の不具合等が見つかった場合は、携帯情報端末６０４等から、図３に示すようなデバッガ制御コマンドを、電子メールのメッセージとして本プログラム検証システムに送信することで、リモートにて本プログラム検証システムを制御することができる。また、リモート制御結果は、実行状況配信部３２２から電子メール送受信部６０２を経由して、携帯情報端末６０４等に電子メールにより配信する。
【００９５】
これにより、プログラム検証システムをリモート制御可能となる。
【００９６】
なお、自動検証処理において、シナリオファイル３５２として前記の状態遷移表を用いる代わりに、シナリオファイル３５２の記述方法や自動検証制御部３００の制御方法を適宜変更することで、任意の自動検証処理を実現可能である。
【００９７】
＜具体的動作＞
以下、プログラム自動検証を行う本プログラム検証システムの動作について、さらに具体的に説明する。
【００９８】
＜初期化処理＞
本実施形態のプログラム検証システム（図１０に示す構成）も、起動すると、まず、初期化処理を行う。仮想デバイス１００、デバッガ５００、自動検証制御部３００、および電子メール送受信部６０２は、仮想配線２０６に接続するための接続処理を行う。また、ブリッジ５０４は、予め、データ送信部３２０および仮想出力１０４からのメッセージ受信を行うために、受信割込み許可しておく。また、実行状況配信部３２２は、仮想出力１０４からのメッセージ受信を許可しておく。また、電子メール送受信部６０２内の実行状況モニタ６０６は、実行状況配信部３２２からの受信を許可しておく。
【００９９】
＜シナリオ読込から仮想配線へリセットＧＯコマンドデータを流す＞
シナリオ読込部３１６から、ＩＣＥ４００の実行を初期化するために、リセットＧＯコマンドの送信をデータ送信部３２０に指示する。データ送信部３２０は、図３に示すようなリセットＧＯコマンドのフォーマットに従って作成したメッセージを、ブリッジ５０４に宛てて、バススロット１０６から仮想配線２０６に同期通信にて送出する。
【０１００】
＜ブリッジデバイスの書込み処理＞
データ送信部３２０からバススロット５０２経由でブリッジ５０４に送られて来たメッセージは、図２に示す通り、受信割込み処理を行う同期受信部５５０に受け取られる。コマンド変換部５５２は、図３に示すようなテーブルを参照し、受け取ったメッセージが、１バイトメモリライト、１バイトメモリリード、ＩＣＥリセット、ＩＣＥ実行等のどのメッセージであるかを分析し、その結果をコマンド発行部５５４からＩＣＥデバッガ５０６内のＶｉｒｔｕａｌＬｉｎｋ５６０に渡す。
【０１０１】
ＶｉｒｔｕａｌＬｉｎｋ５６０は、既存デバッガ５６２を制御して、ＩＣＥ４００にリセットコマンドを発行した後、実行開始コマンドを発行して、実行完了通知を同期受信部５５０の返信データとして、メッセージの送信元であるデータ送信部３２０に返信する。データ送信部３２０は、シナリオ読込部３１６にリセットＧＯコマンド実行完了を伝え、シナリオファイル３５２の内容に従った実行を行う。
【０１０２】
＜シナリオファイルから仮想配線へのデータを流す＞
シナリオ読込部３１６は、シナリオファイル３５２からキーコードを読込んで、データ送信部３２０に指示して、図３に示すようなメッセージ一覧表内の１バイトメモリライトコマンド発行フォーマットに従って作成したメッセージを、ブリッジ５０４に宛てて、バススロット１０６から仮想配線２０６へ同期通信にて送出する。
【０１０３】
＜ブリッジの書込み処理＞
データ送信３２０から、バススロット５０２経由でブリッジ５０４に送られて来たメッセージは、図２に示す通り、受信割込み処理を行う同期受信部５５０に受け取られる。そして、コマンド変換部５５２が、図３に示すようなテーブルに基づき、受け取ったメッセージが、１バイトメモリライト、１バイトメモリリード、ＩＣＥリセット、ＩＣＥ実行等のどのメッセージであるかを分析する。その分析結果は、コマンド発行部５５４からＩＣＥデバッガ５０６内のＶｉｒｔｕａｌＬｉｎｋ５６０に渡される。
【０１０４】
ＶｉｒｔｕａｌＬｉｎｋ５６０は、既存デバッガ５６２を制御して、プログラム４１４を実行中のＩＣＥ４００内の同期化ＲＡＭ４０４に、仮想入力１０２から渡された指定ＲＡＭアドレスのＲＡＭデータをオンザフライにて書込んだ後、書込み完了通知を、同期受信部５５０の返信データとして、メッセージの送信元であるデータ送信部３２０へ返信する。返信を受けると、キーデータを配信したことを、実行状況配信部３２２からイベント検出部３０８に伝える。
【０１０５】
＜同期化ＲＡＭからユーザＲＡＭへの転送処理＞
同期化プログラム４１２は、同期化ＲＡＭ４０４の変化を、プログラム４１４に必要なタイミングでマイコンエミュレータ４０６にチェックさせている。
【０１０６】
同期化プログラム４１２は、例えばキー入力の場合は、プログラム４１４のキー入力処理の直後に呼ばれ、同期化ＲＡＭ４０４内のキーデータＲＡＭの変化を、マイコンエミュレータ４０６経由でチェックし、もし変化が有れば、キーデータをユーザＲＡＭ４０２のキーデータ確定エリアに転送する。この際、仮想入力１０２のキーデータと実機デバイス１５０からのキーデータとが同時に入力された場合は、仮想入力１０２からのキーデータが優先される。
【０１０７】
同期化プログラム４１２内のキー入力処理は、具体的には、第１の実施形態において図４を用いて説明したとおりである。これにより、仮想キー入力が、実機キー入力より優先されて処理される。
【０１０８】
＜ユーザＲＡＭから仮想出力へのデータ転送＞
シナリオファイル３５２から読み込んだキーコードによってプログラム４１４がユーザＲＡＭ４０２内の出力ＲＡＭデータ（仮想出力１０４への出力データ）を変更した場合、この出力ＲＡＭデータを仮想出力１０４へ転送する方法は、以下の（ｃ１）〜（ｃ４）のとおりである。
【０１０９】
（ｃ１）プログラムのユーザＲＡＭ変更；
プログラム４１４により、ユーザＲＡＭ４０２内の仮想出力１０４に関係するＲＡＭエリアが変更された直後に、ユーザＲＡＭ４０２から同期化ＲＡＭ４０４内の特定ＲＡＭに変化を伝えるための処理を行う。具体的には、図５に示す通り、プログラム４１４から仮想同期化ルーチンを呼び出すことにより、処理を開始する（ステップＳ４２０）。実機デバイス１５０への出力処理（ステップＳ４２２）を行った直後に、実機デバイス１５０への出力ＲＡＭデータの変化を検出し（ステップＳ４２４）、変化があれば、出力ＲＡＭデータをユーザＲＡＭ４０２から同期化ＲＡＭ４０４内に転送する（ステップＳ４２６）。
【０１１０】
（ｃ２）仮想出力から仮想配線へデータを流す；
次に、仮想出力１０４から、同期化ＲＡＭ４０４内の出力ＲＡＭデータの変化イベントを読込むために、仮想出力１０４からデバッガ５００へのメッセージ転送の指定とイベントを読込むためのＲＡＭアドレスとを一緒に、バススロット１０８経由で、仮想配線２０６に同期通信により送出する。
【０１１１】
（ｃ３）ブリッジデバイスの読込み処理；
仮想出力１０４からバススロット５０２経由でブリッジ５０４に送られて来たメッセージは、図２に示す通り、受信割込み処理を行う同期受信部５５０で受け取られる。その後、コマンド変換部５５２が、図３に示すようなメッセージ一覧表に従い、受け取ったメッセージが、１バイトメモリライト、１バイトメモリリード、ＩＣＥリセット、ＩＣＥ実行等のどのメッセージであるかを分析する。コマンド発行部５５４は、その分析結果を、ＩＣＥデバッガ５０６内のＶｉｒｔｕａｌＬｉｎｋ５６０に渡す。ＶｉｒｔｕａｌＬｉｎｋ５６０は、既存デバッガ５６２を制御して、プログラム実行中にＩＣＥ４００内の同期化ＲＡＭ４０４内の出力ＲＡＭデータをオンザフライにて読み込む。その後、読み込んだ出力ＲＡＭデータを、同期受信部５５０が、前記メッセージの送信元である仮想出力１０４へ返信する。これにより、出力ＲＡＭデータの仮想出力１０４への転送が、完了する。
【０１１２】
（ｃ４）仮想出力の表示処理；
仮想出力１０４では、出力ＲＡＭデータを元にパソコンモニタに仮想ＬＣＤ表示等を行う。また、同期化ＲＡＭ４０４またはユーザＲＡＭ４０２から仮想出力１０４に取得した画像データの変化があれば、仮想出力１０４は、画像データ取得部３１０に対して、実行状況配信部３２２経由で、画像変化のメッセージおよび仮想出力１０４の表示ダンプデータを転送する。
【０１１３】
また、前記イベントを使わずに、仮想入力１０２から一定周期にて、デバッガ５００にユーザＲＡＭ４０２のデータを読込み、仮想出力１０４にて仮想ＬＣＤ表示等を行う方法でも良い。
【０１１４】
＜データ転送からイベント検出に転送＞
実行状況配信部３２２にデータ送信部３２０から前記キーデータが送られてくると、そのキーデータは、イベント検出部３０８から画像データ取得部３１０に渡される。また、同期化ＲＡＭ４０４またはユーザＲＡＭ４０２から仮想出力１０４に取得した画像データの変化が有れば、仮想出力１０４から実行状況配信部３２２を経由して、画像データ取得部３１０に対して画像変化のメッセージおよび、仮想出力の表示ダンプデータを転送する。画像データ取得部３１０は、前記キーデータを検証結果書込部３０４から検証結果ファイル３５０に書込む。
【０１１５】
また、画像データ取得部３１０は、仮想出力１０４から表示変化のメッセージを受けると、仮想出力１０４の表示画像を、クリップボード２００にキャプチャーする。クリップボード２００にキャプチャーされた画像は、検証結果書込部３０４により、検証結果ファイル３５０に対して書込まれる。
【０１１６】
具体的には、図１２に示すように、キーデータは操作キーの欄に書込み、シナリオファイル３５２の画面モードは、画面モードの欄に書込む。
【０１１７】
＜基準画像データと実行画像データとの比較＞
検証結果ファイル３５０において、「基準画像データ」と「実行画像データ」とのデータの相違を判定し、判定結果を「判定」の欄に「○」と「×」として書込む。なお、検証結果ファイル３５０をＥｘｃｅｌで作成する場合は、ＩＦ関数を用いて「基準画像データ」と「実行画像データ」の相違の判定を行うことができる。
【０１１８】
＜基準画像データの作成＞
尚、自動検証処理を行うための基準画像およびその表示ダンプデータの作成については、前記自動実行する方法で、画像データおよび表示ダンプデータを図１２に示す基準画面および実行画像データに書込むことで作成できる。
【０１１９】
＜効果＞
以上のように、本実施形態によれば、シナリオファイルを利用することにより、プログラム自動検証が行える様になり、評価効率の向上が可能となる。また、プログラム自動検証の実行状況を、遠隔地からも監視できるようになる。
【０１２０】
（第４の実施形態）
プログラム４１４を搭載すべき実機のハードウェアが完成した後は、図１４に示すように、仮想デバイスを利用せず、実機デバッグセットのみを利用したプログラム検証システムにより、自動検証を行うことも可能である。
【０１２１】
【発明の効果】
以上のように、本発明によれば、ＩＣＥを利用したプログラム検証システムにおいて周辺デバイスを実機デバイスと仮想デバイスに分けたプログラム検証を行うためのハードウエアは必要とせず実現でき、短期間にプログラム検証システムを構築できる。また、自動検証に関しては、ＬＣＤ表示等の出力表示を実機デバイスおよび仮想デバイス問わず、表示イメージのまま記録できるため、プログラム検証時間の短縮が可能となる。更に、自動検証をリモート制御できるため、遠隔操作によりプログラムのデバッグおよび検証が出来るようになり作業効率が向上する。
【図面の簡単な説明】
【図１】本発明の第１の実施形態にかかるプログラム検証システムの構成を示すブロック図
【図２】デバッガの内部構成を示すブロック図
【図３】仮想デバイスからブリッジへのメッセージ一覧の説明図
【図４】キー入力処理のフローチャート
【図５】表示出力処理のフローチャート
【図６】本発明の第２の実施形態にかかるプログラム検証システムの構成を示すブロック図
【図７】検証結果ファイルの一例を示す説明図
【図８】第２の実施形態にかかるプログラム検証システムの変形例として、複数のカメラを用いたプログラム検証システムのブロック図
【図９】本発明の第３の実施形態にかかるプログラム検証システムの構成を示すブロック図
【図１０】第３の実施形態にかかるプログラム検証システムの変形例のブロック図
【図１１】シナリオファイルの一例を示す説明図
【図１２】第３の実施形態にかかる検証結果ファイルの一例を示す説明図
【図１３】ＩＣＥから仮想デバイスへ向けてのイベント一覧を示す説明図
【図１４】本発明の第４の実施形態にかかるプログラム検証システムの構成を示すブロック図
【図１５】従来の実機デバッグセットを用いたプログラム検証システムのブロック図
【図１６】従来のシステムシミュレータセットを用いたプログラム検証システムのブロック図
【図１７】従来の実セット・シミュレータ混載のプログラム検証システムのブロック図
【符号の説明】
１００仮想デバイス
１０２仮想入力
１０４仮想出力
１２０周辺デバイス
１５０実機デバイス
１５２実入力
１５４実出力
１５６実機入出力
２００クリップボード
２０２，２０３カメラモニタ
２０４，２０５ＰＣカメラ
２０６仮想配線
３００自動検証制御部
３０２記録制御部
３０４検証結果書込部
３０８イベント検出部
３１０画像データ取得部
３１２バススロット
３１４シナリオ制御部
３１６シナリオ読込部
３１８タイミング制御部
３２０データ送信部
３２２実行状況配信部
３５０検証結果ファイル
３５２シナリオファイル
４００ＩＣＥ
４０２ユーザＲＡＭ
４０４同期化ＲＡＭ
４１０実機プログラム
４１２同期化プログラム
５００デバッガ
５０２バススロット
５０４ブリッジ
５０６ＩＣＥデバッガ
６００電子メール送受信部
６０４携帯情報端末
６０６実行状況モニタ
６０８リモート制御部
６１０メール配信制御部[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a program verification system that performs operation verification of a microcomputer program using ICE, and particularly to a program verification system that uses a real device and a virtual device as peripheral devices necessary for program execution.
[0002]
[Prior art]
FIG. 15 shows an example of a conventional real machine debug set. As shown in FIG. 15, the evaluation of an application program for controlling a single chip microcomputer is performed by debugging an in-circuit emulator (hereinafter referred to as ICE) 400 that can emulate all functions of a single chip microcomputer instead of a target single chip microcomputer. What is built into the board 18 is connected to an actual machine debug set (peripheral device 120) configured by hardware.
[0003]
However, when such a debug set is used, in order to test the program, it is essential that the hardware that operates the system is completed in advance, so the software development process is the hardware development process. There was a problem that it was greatly influenced by the progress.
[0004]
In order to solve this problem, a method of evaluating a program without using a real machine by simulating a target single-chip microcomputer and a peripheral device has been proposed.
[0005]
An example of such a simulation method is disclosed in, for example, JP-A-9-114700. The system disclosed in Japanese Patent Application Laid-Open No. 9-114700 includes embedded software to be tested / debugged, an MPU simulator for simulating a microprocessor unit (MPU) and a memory, and an input / output device simulation for simulating input / output. Unit, an input / output device execution control mechanism for simulating a signal line connecting the MPU and one or more input / output devices, a startup definition file describing the startup sequence of the simulator, an I / O monitor and an I / O model Input / output simulation unit having means for starting / ending processes, means for allowing a user to refer to / change resource information of all I / O models, and means for displaying connection relations between I / O models and I / O monitors It consists of an operating environment. Each component is composed of a plurality of processes and connected by virtual wiring. In this simulation method, as shown in FIG. 16, all of the actual peripheral devices 120 are realized by the virtual device 100.
[0006]
An example of an actual machine / simulator mixed system that combines the advantages of both an actual machine debugging method and a simulator debugging method is disclosed in Japanese Patent Laid-Open No. 8-6810. As shown in FIG. 17, the system disclosed in Japanese Patent Application Laid-Open No. 8-6810 is a mixed system of a real machine debug set using an ICE 64 and a virtual device (simulation unit 50). In this system, the transfer of input / output data between the simulation unit 50 and the ICE 64 is realized by using a dedicated actual machine interface board 60.
[0007]
[Problems to be solved by the invention]
However, in the conventional real machine / simulator mixed system, as shown in FIG. 17, a dedicated interface board 60 is required in order to exchange the input / output data between the virtual device and the ICE. For this reason, when a change in the specification of the peripheral device or the like occurs, the cost and time are required to change the design of the interface board accordingly, and there is a problem that the program cannot be debugged and verified efficiently.
[0008]
In order to solve the above problems, an object of the present invention is to provide a program verification system capable of efficiently verifying a program when a real device and a virtual device are used as peripheral devices.
[0009]
[Means for Solving the Problems]
In order to achieve the above object, a program verification system according to the present invention is a program verification system that verifies the operation of a program for a microcomputer using a real device and a virtual device as peripheral devices of the microcomputer, the microcomputer An emulator that emulates the operation of the program above, a verification control unit that controls the emulator to perform a verification operation corresponding to the real device, and provided between the verification control unit and the virtual device, A bridge unit that adapts a control signal and data from a device to the verification control unit, a real machine RAM that stores input / output data between the real machine device and the program, a real machine RAM, and the virtual device. The synchronization RAM provided between the real device and the real device That in synchronism with the input operation of the program, and controls the data transfer between said synchronized RAM and the actual use RAM, characterized in that a virtual-actual synchronization processing unit.
[0010]
In order to enable program verification without waiting for completion of the actual device even when program development precedes actual hardware development, this configuration is a verification control unit that supports the specifications of the existing actual device. And a virtual device that simulates the specifications of the real device corresponding to the new program by software, for example, a command or data conversion to adapt the control signal and data from this virtual device to the verification control unit A part is provided. This makes it possible to verify a new program without waiting for completion of the actual device. Further, in order to absorb the difference in operation speed between the real device and the virtual device, a synchronization RAM for synchronization is provided separately from the real device RAM used by the program. In addition, a virtual / real machine synchronization processing unit is provided for synchronously controlling data transfer between the synchronization RAM and the real machine RAM.
[0011]
As a result, for example, when developing a so-called deployment model that has variations in the specifications around the user interface (parts related to operation and display) that have the same main functions, a new hardware set for debugging is newly installed. Even if it is not made with hardware, it is possible to simulate with a virtual device while using an existing real machine set. Further, unlike the prior art, there is no need to create a dedicated interface board for transferring input / output data between the virtual device and the ICE. As described above, according to the present invention, it is possible to provide a program verification system capable of efficiently developing a program without waiting for completion of an actual machine debug set.
[0012]
In the program verification system, it is preferable that the virtual device and the bridge unit are connected by virtual wiring. In addition, if a configuration including a plurality of virtual devices for each function is provided, another automatic verification system has an advantage that each device can be easily reused.
[0013]
In the program verification system, a verification result file including a photographing device that captures an actual monitor output image output by the actual device, a virtual monitor output image output by the virtual device, and a virtual monitor output image output by the virtual device It is preferable that the apparatus further includes a verification result writing unit for recording the data.
[0014]
According to this configuration, for example, when a prototype of a real device to be loaded with a new program is completed, the virtual device prepared according to the specification of the real device is used for program verification. The operation verification of the actual device can be performed. That is, an actual device and a virtual device having the same specifications are operated, and their monitor output images are written in the verification result file. Thus, the person in charge of development can determine whether or not the actual device satisfies the target specification by comparing the monitor output images written in the verification result file. Further, when there is an abnormality, it becomes easy to grasp which of the actual device and the program has a problem.
[0015]
Further, in this preferred configuration, an event detection unit that detects a predetermined change in the peripheral device, and an image that captures the actual monitor output image and the virtual monitor output image at a timing according to a detection result of the event detection unit. If the acquisition unit is further provided, for example, the monitor output image can be captured in accordance with the input / output timing of the real device and the virtual device, and the verification can be performed more efficiently.
[0016]
Furthermore, if the configuration includes a plurality of the photographing devices, more information can be recorded in the verification result file. For example, when verifying a device having a plurality of types of actual device, the verification accuracy is improved. Can be made.
[0017]
In addition, it is preferable to further include a verification status distribution unit that transmits the verification processing status including the actual machine monitor output image or the virtual monitor output image to the external terminal according to the detection result of the event detection unit. . Thereby, even when the person in charge of the verification work is in a remote place, accurate information can be grasped in real time. Further, a configuration further includes a remote control unit that receives a control signal and a message including its destination from an external terminal such as a portable information terminal, extracts the control signal from the received message, and distributes the control signal to the destination of the control signal This is still more preferable. As a result, when any problem occurs during the automatic program verification operation, the program verification system can be remotely controlled, enabling efficient debugging and verification.
[0018]
The program verification system according to each of the above-described configurations preferably further includes a scenario control unit that reads data from a scenario file that records an operation procedure for automatically verifying the program and transfers the data to the bridge unit. .
[0019]
According to this configuration, it is not necessary to perform a verification operation from the virtual device or the real device by reading data from the scenario file in which the operation procedure to be verified in advance is recorded, and the program verification system automatically performs verification. Work can be executed. Thereby, the program verification efficiency can be further improved.
[0020]
It is further preferable to further include a timing control unit that controls transfer of data read from the scenario file to the bridge unit in accordance with the operation status of the emulator. According to this configuration, for example, when the emulator malfunctions for some reason, the timing control unit performs control such as rereading the scenario file and transferring it to the bridge unit, for example. This improves the reliability of the automatic verification work.
[0021]
DETAILED DESCRIPTION OF THE INVENTION
First, configurations and terms common to the following embodiments will be described with reference to FIG.
[0022]
The program 414 was developed as a program operating on a microcomputer, and is a program to be debugged in the program verification system according to the present invention.
[0023]
The actual machine program 410 includes a debug target program 414 and a synchronization program 412. The synchronization program 412 is not installed in the actual microcomputer and is used only in the program verification system. As will be described in detail later, the data writing from the virtual device 100 to the user RAM 402 is synchronized with the data writing from the actual device 150. To perform the process.
[0024]
The peripheral device 120 is an input / output device necessary for the operation verification of the program 414, and includes the real device 150 and the virtual device 100. The actual device 150 is an input / output device (hardware itself) of an actual device in which the program 414 is installed. On the other hand, the virtual device 100 simulates the hardware of the actual machine on which the program 414 is installed with software.
[0025]
The ICE 400 is an in-circuit emulator that emulates a built-in microcomputer of a real machine on which the program 414 is mounted in order to verify the execution of the program 414, and includes a microcomputer emulator 406, a user RAM 402, and a synchronization RAM 404. . The user RAM 402 is a RAM that stores input / output data between the real device 150 and the program 414. The synchronization RAM 404 temporarily stores data to be written from the virtual device 120 to the user RAM 402, which will be described in detail later. RAM.
[0026]
The operation of the ICE 400 is controlled by the debugger 500. The debugger 500 includes a bridge 504 and an ICE debugger 506 (verification control unit). The ICE debugger 506 is designed to cause the ICE 400 to execute a verification operation corresponding to the specification of the actual device 150. On the other hand, the bridge 504 performs control command conversion between the virtual device 100 and the ICE 506 in order to enable a verification operation using the virtual device 100 as an input / output device instead of the actual device 150. And implemented in software.
[0027]
That is, the program verification system according to the present embodiment is configured so that, even when program development precedes hardware development of actual devices, in order to enable program verification without waiting for completion of actual device, 150 and the ICE debugger 506, a virtual device 100 that simulates the specifications of a real device corresponding to a new program (program 414) by software, and a bridge 504 that adapts the virtual device 100 to the ICE debugger 506 It is.
[0028]
The virtual wiring 206 is a wiring that virtually connects the virtual device 120, the debugger 500, the automatic verification control unit described in the following embodiment, and the like. When the virtual device 100, the debugger 500, and the like are realized by a plurality of personal computers, a network, USB, RS232C, and IEEE1394 can be used as the virtual wiring 206. When the virtual device 100, the debugger 500, and the like are realized as a plurality of applications or processes that can be executed independently in one personal computer, the virtual wiring 206 is connected to the DDE, COM that can communicate between the applications or processes. It can be realized by using a data communication function such as A specific embodiment of the virtual wiring 206 is disclosed in detail in an earlier application (Japanese Patent Application No. 2001-219887) related to the invention made by the inventors of the present invention.
[0029]
The communication method using the virtual wiring 206 may be either asynchronous communication or synchronous communication. Asynchronous communication is a communication method in which data is transmitted unilaterally to a communication partner and there is no reply. Synchronous communication is a communication method in which data is sent to a communication partner and then waiting until return data is returned from the communication partner.
[0030]
HTA is an abbreviation of HTML Applications and supports various functions (HTML, CSS, script language (Java (registered trademark), Script, VBA, etc.), Behavior, etc.) that can be executed on a Web page.
[0031]
ActiveX is an API for developing an ActiveX document object that is an Internet-compatible OLE document object and a client application having an Internet access function.
[0032]
OLE is an abbreviation of Object Linking and Embedding, and an application can call a function of another application and use it like its own function. In the embodiment described later, an example in which an Microsoft Excel application from HTA is used will be described.
[0033]
(First embodiment)
Hereinafter, an embodiment of the present invention will be described with reference to the drawings.
[0034]
In the program verification system according to the present embodiment, transfer and synchronization of input / output data between the virtual device 100 and the ICE 400 are all realized by software, and the peripheral device 120, the ICE 400, and the like are connected to the virtual wiring 206, respectively. In this way, the system configuration allows flexible support in accordance with the verification purpose of the program 414. That is, the configuration is different from that of a conventional system having a dedicated I / F 60 realized by hardware between the ICE 64 and the simulation unit 50 as shown in FIG.
[0035]
<System configuration>
In the program verification system according to the present embodiment, the peripheral device 120 necessary for the operation of the program 414 includes the virtual device 100 and the real device 150 as shown in FIG. Both the virtual device 100 and the debugger 500 are connected to the virtual wiring 206.
[0036]
<Initialization process>
When the program verification system is activated, it performs an initialization process. In the initialization process, the virtual device 100 and the debugger 500 perform a connection process for connecting to the virtual wiring 206. In addition, the bridge 504 of the debugger 500 permits a reception interrupt in advance in order to receive a message from the virtual input 102 and the virtual output 104 of the virtual device 100. Also, the ICE 400 sets the program 414 in an execution state in advance.
[0037]
<Data transfer from virtual input to ICE>
Data transfer from the virtual input 102 to the ICE 400 is executed as follows (a1) to (a3).
[0038]
(A1) Data transmission from virtual input to virtual wiring;
An input event generated at the virtual input 102 designates a RAM write message transfer to the debugger 500, and the RAM address and RAM data of the synchronization RAM 404 to which the input event data is written are transferred via the bus slot 106 to the virtual wiring 206. Is sent out by synchronous communication.
[0039]
(A2) Bridge write processing;
A message sent from the virtual input 102 to the bridge 504 via the virtual wiring 206 and the bus slot 502 is received by the synchronous reception unit 550 that performs reception interrupt processing in the bridge 504 as shown in FIG. Thereafter, in order for the command conversion unit 552 to adapt the message from the virtual input 102 to a format that can be processed by the ICE debugger 506, the received message is written in 1 byte memory write, 1 in accordance with the message list shown in FIG. It analyzes which message is a byte memory read, ICE reset, ICE execution, or the like. The command issuing unit 554 passes the analysis result to the Virtual Link 560 in the ICE debugger 506.
[0040]
The VirtualLink 560 controls the existing debugger 562 designed to perform a verification operation corresponding to the specification of the real device 150, and designates the specified RAM passed from the virtual input 102 to the synchronization RAM 404 in the ICE 400 that is executing the program. Write address RAM data on the fly. Thereafter, the synchronous reception unit 550 returns a write completion notification as a reply to the message to the virtual input 102 that is the message transmission source. Note that “on the fly” is a function of the ICE 400 that allows the RAM data of the user RAM 402 and the synchronization RAM 404 in the ICE 400 and the register in the microcomputer emulator 406 to be read and written even when the program 414 is being executed.
[0041]
(A3) Transfer processing from the synchronization RAM to the user RAM;
The synchronization program 412 causes the microcomputer emulator 406 to check a change in data written in the synchronization RAM 404 at a timing necessary for the program 414.
[0042]
For example, in the case of key input, the synchronization program 412 is called immediately after the key input processing of the program 414, and checks for changes that occur in the synchronization RAM 404 by the key input data via the microcomputer emulator 406. The key input data is transferred to a key input data confirmation area provided in the user RAM 402. Note that when the key data of the virtual input 102 and the key input data from the actual machine input / output 156 are input simultaneously, the virtual key data has priority. The order of this processing can be changed to give priority to key input data from the actual device 150 according to the application.
[0043]
Specifically, the key input process in the synchronization program 412 is started by calling the synchronization program 412 from the program 414 as shown in FIG. 4 (step S400). First, the key input data transferred from the virtual device 100 via the microcomputer emulator 406 and stored in the synchronization RAM 404 is read (step S402), and a change in the key input data is checked (step S404).
[0044]
If there is a change, the key input data is overwritten on the actual machine key input data determination area provided in the user RAM 402 (step S406). The actual machine key input data confirmation area is an area in the user RAM 402 in which data that is confirmed by key input from the actual machine input / output 156 is to be recorded. Thus, by overwriting the key input from the virtual device 100 in the real machine key input data determination area, the virtual key input is processed with priority over the real machine key input.
[0045]
In addition, the key data transferred from the virtual device in the synchronization RAM 404 is cleared (step S408), so that the continuous data processing is not performed by the periodically called key processing. If the continuous key is to be enabled, step S408 can be deleted so that ON key data is transmitted when the key is pressed from the virtual input 102, and OFF key data is transmitted when the key is released. .
[0046]
<Data transfer from user RAM to virtual output>
On the other hand, when the program 414 changes the output RAM data in the user RAM 402 by the input data from the virtual input 102, the procedure for transferring the output RAM data from the user RAM 402 to the virtual output 104 is as follows (b1) to It is as (b4).
[0047]
(B1) Program user RAM change;
Immediately after the RAM data related to the virtual output 104 in the user RAM 402 is changed by the program 414, processing for transmitting the change from the user RAM 402 to the specific RAM in the synchronization RAM 404 is performed. Specifically, as shown in FIG. 5, the process is started by calling the virtual synchronization program from the program 414 (step S420). Immediately after the output processing from the program 414 to the user RAM 402 (step S422), a change in the output RAM data in the user RAM 402 is detected (step S424). If there is a change, the output RAM data is synchronized from the user RAM 402 to the synchronization RAM 404. (Step S426).
[0048]
(B2) Data transmission from virtual output to virtual wiring;
Next, in order to read the change event of the output RAM data in the synchronization RAM 404 from the virtual output 104, the message slot designation from the virtual output 104 to the debugger 500 and the RAM address for reading the event are combined with the bus slot 108. Via the virtual wiring 206 via synchronous communication.
[0049]
(B3) Bridge device read processing;
A message sent from the virtual output 104 to the bridge 504 via the bus slot 502 is received by the synchronous reception unit 550 that performs reception interrupt processing, as shown in FIG. After that, the command conversion unit 552 analyzes which message is 1 byte memory write, 1 byte memory read, ICE reset, ICE execution, or the like, according to the message list as shown in FIG. The command issuing unit 554 passes the analysis result to the Virtual Link 560 in the ICE debugger 506. The VirtualLink 560 controls the existing debugger 562 to read output RAM data in the synchronization RAM 404 in the ICE 400 on the fly during program execution. Thereafter, the synchronous reception unit 550 returns the read output RAM data to the virtual output 104 that is the transmission source of the message. Thereby, the transfer of the output RAM data to the virtual output 104 is completed.
[0050]
(B4) Virtual output display processing;
The virtual output 104 displays a virtual LCD on a personal computer monitor based on the output RAM data.
[0051]
Further, instead of using the change event of the synchronization RAM 404 as described above, the virtual output 104 is displayed on the virtual output 104 by reading the data of the user RAM 402 from the virtual input 102 into the debugger 500 at a constant cycle. You may do it.
[0052]
<Effect>
As described above, according to the present embodiment, the real device 150 and the virtual device 100 are used as the peripheral device 120, the synchronization RAM 404 is provided in the ICE 400, and all the synchronization processing between the virtual device 100 and the ICE 400 is performed by software. (Bridge 504 and synchronization program 412). As a result, the program can be efficiently developed without waiting for completion of the actual machine debug set.
[0053]
In this embodiment, a plurality of virtual devices 100 having different functions may be connected to the virtual wiring 206. According to this configuration, another automatic verification system has an advantage that each device can be easily reused.
[0054]
(Second Embodiment)
When program development precedes hardware development, when the actual machine debug set is completed, it is necessary to verify the operation of the actual machine debug set using the program under development. However, conventionally, when the actual machine debug set does not operate normally during operation verification, it is difficult to determine which of the program and the actual machine debug set is bad, and there is a problem that analysis takes time.
[0055]
Therefore, the program verification system according to the second exemplary embodiment of the present invention transmits the actual input 152 and the actual output 154 of the actual device 150 necessary for the program operation of the program 414 from the ICE 400 via the debugger 500 as shown in FIG. Thus, the configuration is connected to the virtual wiring 206. Further, the program verification system has a configuration in which a virtual input 102 and a virtual output 104 that virtually realize a function equivalent to the actual input 152 and the actual output 154 are connected to a virtual wiring 206.
[0056]
Further, in this program verification system, the display of the actual output 154 is taken by the PC camera 204, and a camera monitor 202 for displaying the video taken by the PC camera 204 is provided on the monitor of the personal computer. The image of the virtual output 104 having the same function as the actual output 154 is also displayed on the monitor of the personal computer.
[0057]
In order to record the display image of the camera monitor 202 and the virtual output 104, the recording control unit 302 transfers the key code of the virtual input 102 to the ICE 400, and then displays it according to the display image data in the ICE 400. The display images of the output 154 and the virtual output 104 are copied to the clipboard 200 and recorded in the verification result file 350. In addition, the display dump data at that time is also recorded in the verification result file 350.
[0058]
The verification result file 350 is an application file that allows a debug operator to visually compare the execution results of the actual output 154 and the virtual output 104. For example, Microsoft Excel (registered trademark, hereinafter abbreviated) or the like can be used. It can be realized by using. The control program of the recording control unit 302 that controls reading and writing of the verification result file 350 is described using HTA. When the verification result file 350 is created by Excel, the OLE function is used in order to read and write from the recording control unit 302. Further, data communication between the recording control unit 302 and the virtual wiring 206 can be realized using ActiveX.
[0059]
<Initialization process>
When the program verification system according to the present embodiment is also activated, it first performs an initialization process. The virtual device 100, the debugger 500, and the recording control unit 302 perform a connection process for connecting to the virtual wiring 206. In order to receive messages from the virtual input 102 and the virtual output 104, the bridge 504 permits a reception interrupt in advance. The ICE 400 places the program 414 in an execution state in advance. The event detection unit 308 permits message reception from the virtual input 102 and the bridge 504 in advance. The image data acquisition unit 310 permits message reception from the virtual output 104.
[0060]
<Operation check of actual machine debug set>
In this program verification system, for example, in order to confirm the operation of the actual output 154, an operation comparison between the virtual output device 100 used for program evaluation by the simulator until the actual output 154 is completed and the completed actual output 154 is performed. Can be performed as follows.
[0061]
<Data transfer from virtual input to ICE>
The procedure for transferring data from the virtual input 102 to the ICE 400 is substantially the same as (a1) to (a3) described in the first embodiment. However, in the procedure of (a1), only the point that the virtual input 102 designates the RAM write message transfer not only to the debugger 500 but also to the event detection 308 is different from the first embodiment.
[0062]
<Data transfer from user RAM to virtual output>
The procedure for transferring the output RAM data to the virtual output 104 when the program 414 changes the output RAM data in the user RAM 402 by the input data from the virtual input 102 or the like has been described in the first embodiment (b1). Is substantially the same as (b4). However, in the procedure (b4), the virtual output 104 not only displays the output RAM data on the personal computer monitor on the virtual LCD, but also if there is a change in the output RAM data, the event detection unit 308 is routed via the virtual wiring 206. Is different from the first embodiment in that a screen change event and display dump data are transferred.
[0063]
<Image copy event detection from virtual input>
In order to detect issuance of a key event from the virtual input 102, key data is sent from the virtual input 102 to the event detection unit 308 via the virtual wiring 206. The event detection unit 308 passes the key data to the image data acquisition unit 310. Further, if there is a change in the image data acquired from the synchronization RAM 404 or the user RAM 402 to the virtual output 104, an image change message and display dump data of the virtual output 104 are sent from the virtual output 104 to the image data acquisition unit 310. Forward.
[0064]
<Recording of display image>
The image data acquisition unit 310 writes the key data into the verification result file 350 via the verification result writing unit 304. The verification result writing unit 304 reads and writes data using a method suitable for the format of the verification result file 350.
[0065]
When the image data acquisition unit 310 receives a display change message from the virtual output 104, the image data acquisition unit 310 instructs the capture control unit 306 to capture the image of the camera monitor 202 as the actual output 154 image data on the clipboard 200. . Similarly, the display image of the virtual output 104 is also captured on the clipboard 200. The image captured on the clipboard 200 is written into the verification result file 350 by the verification result writing unit 304.
[0066]
A specific example of the verification result file 350 is shown in FIG. As shown in FIG. 7, the verification result file 350 is sent from the virtual output 104 when displaying each image of the virtual screen and the real machine screen for each combination of the screen mode and the operation key. Displayed dump data is recorded.
[0067]
From the verification result file 350 shown in FIG. 7, when the screen mode is “MDPWRON” and the key operation defined by the name “KPOWER” (operation to turn on the power) is performed, both the virtual screen and the actual machine screen are displayed. You can see that nothing was displayed on the screen. In addition, by the key operation defined by the name “KCH UP”, the characters “CH03” are displayed in the upper right corner of the screen, and further, by the key operation defined by the name “KVOL UP”, “ It can be seen that the characters "Vol 24" are displayed. In the case of the above key operations, the display on the virtual screen and the actual machine screen are the same. However, for a key operation defined with the name “KMENU”, “MENU” is displayed on the top line of the virtual screen, but “MEU0” is displayed on the actual screen, and the virtual screen The display state of the actual machine screen does not match. Thus, it can be seen that there is a bug in the actual device 150 regarding the key operation of “KMENU”.
[0068]
Although schematically shown in FIG. 7, the image image of the virtual output 104 captured on the clipboard 200 is actually pasted in the “virtual screen” field of the verification result file 350. In the “actual machine screen” field, an image image of the actual output 154 captured by the PC camera 204 and captured from the camera monitor 202 to the clipboard 200 is pasted. Therefore, by comparing these image images, the debug operator can easily recognize the difference between the virtual screen and the actual machine screen.
[0069]
<Control multiple PC cameras>
Further, as shown in FIG. 8, in addition to the PC camera 204 that captures the state of the actual output 154, a PC camera 205 that captures the state of the actual input / output 156 may be further provided to capture the actual device 150. Good. Note that the state of the real machine input / output 156 refers to, for example, a state in which key inputs to the real machine device 150 are echoed on the real machine monitor, a process result being displayed on the monitor, and the like. A camera monitor 202 and a camera monitor 203 are connected to the PC camera 204 and the PC camera 205, respectively. The recording control unit 302 is further provided with a capture selection unit 324 that selects a monitor image to be captured from the camera monitor 202 and the camera monitor 203 to the clipboard 200. This makes it possible to record more monitor images.
[0070]
<Effect>
As described above, in this embodiment, in order to confirm the operation of the newly developed actual output 154, the virtual output 104 (operation verified) that operates equivalent to the actual output 154 is operated on the ICE 400. The execution results of the actual output 154 and the virtual output 104 are written in the verification result file 350 in a state where the debugging operator can visually confirm the execution results. Thereby, the operation comparison between the actual output 154 and the virtual output 104 is facilitated, and the hardware operation verification of the actual output 154 can be performed efficiently. In addition, if the configuration includes a plurality of PC cameras for photographing the state of the actual device 150, more information can be recorded, and verification accuracy can be improved.
[0071]
(Third embodiment)
The main difference between the program verification system according to the third embodiment of the present invention and the program verification system according to the second embodiment is that the program verification system according to the present embodiment performs automatic program verification. is there. For this reason, as shown in FIG. 9 and the like, this program verification system, in addition to the verification result file 350 and the recording control unit 302 described in the second embodiment, the scenario control for controlling the scenario file 352 and reading / writing thereof. Part 314. The recording control unit 302 and the scenario control unit 314 constitute an automatic verification control unit 300 for realizing automatic program verification.
[0072]
The scenario file 352 is a file in which an operation procedure (scenario) for automatically verifying the program 414 is recorded. Like the verification result file 350, the scenario file 352 is realized using, for example, Microsoft Excel. Can do. The control program of the automatic verification control unit 300 is described using HTA. Further, when the verification result file 350 and the scenario file 352 are created by Excel, the OLE function is used in order to perform reading and writing from the automatic verification control unit 300. In addition, data communication between the automatic verification control unit 300 and the virtual wiring 206 can be realized using ActiveX.
[0073]
The configuration and operation of the program verification system will be specifically described below.
[0074]
The program verification system updates the display of the virtual output 104 based on the change in the display image data in the ICE 400, records the display image of the virtual output 104 in the verification result file 350 via the clipboard 200, and performs verification in advance. It is configured to automatically compare with the expected value data for verification recorded in the result file 350.
[0075]
<Automatic sequence of data transfer from scenario to ICE>
The automatic verification process of the program verification system will be described below. The automatic verification process is performed by the automatic verification control unit 300 reading key data and the like from the scenario file 352, automatically transferring them to the ICE 400 and executing them, and writing and executing the execution results in the verification result file 350 for evaluation.
[0076]
In the scenario file 352, operation information (key data or the like) necessary for operation verification is recorded in advance according to the verification procedure. The scenario file 352 is created as a state transition table as shown in FIG. 11, for example, using an Excel file. In this program verification system, after setting the screen mode to a predetermined state according to the operation sequence described in the scenario file, the key is issued as an event to confirm the action (valid or invalid) for each key input. Do. For example, in the case of the scenario file 352 shown in FIG. 11, according to the execution order shown in FIG. 11, first, with the screen mode set to “MDPWRON”, “KPOWER”, “KCH UP”, “KVOL UP”, “ Key inputs of “KMENU” and “KSET” are sequentially performed, and the operations of the virtual device and the real device for each of these key operations are verified. Next, with the screen mode set to “MMENU”, key inputs of “KPOWER”, “KCH UP”, “KVOLUP”, “KMENU”, and “KSET” are sequentially performed in the same manner as described above. Verify the operation of the actual device. Thereafter, the screen modes “MDTIMER”, “MDSET”, and “MDTEST” are similarly verified.
[0077]
Here, the details of the automatic verification process using the scenario file 352 shown in FIG. 11 will be described more specifically, taking as an example the case where operation verification is performed for each key input in the state of the screen mode “MDMENU”. The automatic verification control unit 300 performs the operation verification for the key input in the state of the screen mode “MDMENU” by the following procedures (1) to (9).
[0078]
(1) “1” is set in the reset completion monitor flag RAM in the synchronization RAM 400.
[0079]
(2) In order to initialize the ICE 400 with the program 414, the scenario reading unit 316 instructs the data transmission unit 320 to issue a reset GO command. The “reset GO” command causes the ICE 400 to sequentially execute a “reset” command for stopping and initializing the execution of the actual machine program 410 and a “GO” command for causing the ICE 400 to start executing the actual machine program 410 from the beginning. Is. The data transmission unit 320 sends a reset GO message to the ICE debugger 506 via the bridge 504 by synchronous communication. When the ICE debugger 506 causes the ICE 400 to execute reset GO, the actual machine program 410 is reset and started. The reset completion monitor flag RAM value is set to “0” in the head program of the actual program reset start execution. When the ICE 400 completes the reset GO, the reset GO completion notification is sent from the bridge 504 to the scenario reading 316 via the data transmission unit 320.
[0080]
(3) After confirming that the reset completion monitor flag RAM value is “0”, the key described in the operation sequence of the screen mode in the scenario file 352 in order to set the screen mode to “MDMENU”. Are sequentially read and issued by the scenario reading unit 316. The issued key is transferred to the ICE 400 via the data transmission unit 320, the bus slot 312, the virtual wiring 206, and the debugger 500. In the example of FIG. 11, since the key “KPOWER” is described as the first operation (operation 1 column in the scenario file of FIG. 11) of the operation sequence of “MDMENU”, this key is issued first.
[0081]
(4) Whether the actual machine program 410 has completed the processing of the “KPOWER” key is confirmed by checking a change in the value in the specific RAM in the user RAM 402. When the change of the specific RAM can be confirmed, next, the “KMENU” key described in the operation 2 of the operation sequence is issued, and the change of the specific RAM in the user RAM 402 is checked in the same manner as described above. Check whether the processing of the “KMENU” key is completed. The above processing is repeatedly executed up to the last key described in the operation sequence of the scenario file 352. In the case of “MDMENU” shown in FIG. 11, the target screen mode “MDMENU” is set by executing the “KPOWER” key and the “KMENU” key.
[0082]
(5) When the target screen mode is reached, first, the image data in the user RAM 402 is taken into the synchronous RAM 404.
[0083]
(6) Next, issue keys described in the scenario file 352 are issued sequentially to verify the operation. In the example of FIG. 11, first, a “KPOWER” key is issued. The completion of the processing of the “KPOWER” key is confirmed by a change in the specific RAM value in the user RAM 402.
[0084]
(7) When it is confirmed that the processing of the “KPOWER” key is completed, the processing result of the “KPOWER” key is verified. The virtual output 104 notifies the event detection unit 308 of the presence / absence of a screen change. The event detection unit 308 determines whether the screen change matches the valid / invalid specification described in the scenario file 352.
[0085]
For example, in the scenario file shown in FIG. 11, the symbol O indicates that the key issuance is valid in the screen mode, and the symbol X indicates that the key issuance is invalid in the screen mode. “Key issuance is valid” means that the key issuance causes some change on the screen. “Key issuance is invalid” means that the key issuance does not cause any change on the screen. That means.
[0086]
Here, since the circle symbol is described in the column corresponding to the intersection of the “MDMENU” column and the “KPOWER” row, when the “KPOWER” key is issued when the screen mode is “MDMENU”, If the key is processed correctly, some screen change should occur. Accordingly, if a screen change occurs due to the issuance of the “KPOWER” key, the event detection unit 308 determines that the “KPOWER” key valid / invalid specification in the “MDMENU” screen mode is satisfied.
[0087]
The event detection unit 308 colors the valid / invalid specification column of the scenario file 352 according to the determination result of whether the valid / invalid specification is satisfied. That is, if the event detection unit 308 determines that the valid / invalid specification described in the scenario file 352 is satisfied, the valid / invalid specification column of the scenario file 352 is passed through the verification result writing unit 304. The display attribute is set to, for example, blue, and when it is determined that the display attribute is not satisfied, for example, the display attribute is set to red so that the abnormal operation is understood. As a result, the debug operator can easily identify whether the target specification is satisfied by the display color of the valid / invalid specification column of the scenario file 352. Here, the verification result of the valid / invalid specification is recorded in the scenario file 352, but a column for recording the verification result of the valid / invalid specification may be separately provided in the verification result file 350.
[0088]
(8) Further, the verification result writing unit 304 writes the screen data (executed image data) acquired from the user RAM 402 by the image data acquisition unit 310 to the verification result file 350. Further, the verification result writing unit 304 compares the execution image data with reference image data created in advance prior to execution of the verification process, and writes the comparison result in the verification result file 350. The reference image data is dump data of image data to be displayed as a result of correctly processing the key, and is written in the verification result file 350 as shown in FIG. For example, in the verification result file 350 according to the example shown in FIG. 12, a symbol “◯” is written in the “judgment” column if the comparison result between the reference image data and the execution image data matches, and a symbol “x” is not matched. Yes. As a result, the debug operator can easily verify whether or not the predetermined screen data is displayed by issuing the key only by looking at the determination field of the verification result file 350.
[0089]
(9) In addition, a screen image (reference screen) based on the reference image data is pasted in the verification result file 350 in advance. As illustrated in FIG. 12, the verification result writing unit 304 pastes the screen (execution screen) output to the virtual output 104 to the next column of the reference screen via the clipboard 200. Thereby, the debug operator can easily identify the difference between the reference screen and the execution screen only by looking at the verification result file 350.
[0090]
When the processing up to the above (9) is completed for the “KPOWER” key, the processing returns to (5), the next issuance key “KCH UP” described in the scenario file is issued in (6), and the subsequent processing is performed. Do. Similarly, the verification result file as shown in FIG. 12 is completed by repeating the processes (5) to (9) for all the issuance keys described in the scenario file.
[0091]
In the present embodiment, the existing debugger 562 monitors the behavior of the ICE 400 in order to prevent the automatic verification process from being unable to continue when the ICE 400 becomes abnormal due to some factor during the automatic verification process. If a change occurs in the operation of the ICE 400, the ICE debugger 506 transmits a message as shown in FIG. 13 to the ICE status monitor 558 (see FIG. 2) in the bridge 504. Further, this message is transmitted from the ICE state transmission unit 556 to the timing control unit 318 in the scenario control unit 314 via the virtual wiring 206. Thereby, the timing control unit 318 performs processing such as causing the scenario reading unit 316 to reissue the data of the scenario file 352 in accordance with the operation change of the ICE 400.
[0092]
As described above, according to this embodiment, automatic program verification can be realized.
[0093]
<Remote control>
As shown in FIG. 10, an execution status distribution unit 322 that distributes the execution status of the automatic verification process is provided in the recording control unit 302, and an email transmission / reception unit 602 that transmits / receives an email to / from an external device. It is good also as a structure which provided further. With this configuration, if the execution status of the automatic verification process is distributed to the portable information terminal 604 or the like via the electronic mail transmission / reception unit 602 from the execution status distribution unit 322, the execution status of the automatic verification process is changed. It becomes possible to monitor in real time from a remote location.
[0094]
If a problem or the like of the program 414 is found during the execution of the automatic verification process, a debugger control command as shown in FIG. 3 is transmitted to the program verification system as an e-mail message from the portable information terminal 604 or the like. By doing so, the program verification system can be controlled remotely. The remote control result is distributed from the execution status distribution unit 322 via the electronic mail transmission / reception unit 602 to the portable information terminal 604 or the like by electronic mail.
[0095]
As a result, the program verification system can be remotely controlled.
[0096]
In the automatic verification process, instead of using the state transition table as the scenario file 352, any automatic verification process can be realized by appropriately changing the description method of the scenario file 352 and the control method of the automatic verification control unit 300. Is possible.
[0097]
<Specific operation>
Hereinafter, the operation of this program verification system that performs automatic program verification will be described more specifically.
[0098]
<Initialization process>
When the program verification system of the present embodiment (configuration shown in FIG. 10) is also activated, first, initialization processing is performed. The virtual device 100, the debugger 500, the automatic verification control unit 300, and the e-mail transmission / reception unit 602 perform connection processing for connecting to the virtual wiring 206. The bridge 504 permits reception interrupts in advance in order to receive messages from the data transmission unit 320 and the virtual output 104. Further, the execution status distribution unit 322 permits message reception from the virtual output 104. The execution status monitor 606 in the e-mail transmission / reception unit 602 permits reception from the execution status distribution unit 322.
[0099]
<Flow reset GO command data from scenario reading to virtual wiring>
The scenario reading unit 316 instructs the data transmission unit 320 to transmit a reset GO command in order to initialize the execution of the ICE 400. The data transmission unit 320 sends a message created according to the format of the reset GO command as shown in FIG. 3 to the bridge 504 and sends it from the bus slot 106 to the virtual wiring 206 by synchronous communication.
[0100]
<Bridge device write processing>
The message sent from the data transmission unit 320 to the bridge 504 via the bus slot 502 is received by the synchronous reception unit 550 that performs reception interrupt processing as shown in FIG. The command conversion unit 552 refers to the table as shown in FIG. 3 and analyzes which message is a received message such as 1 byte memory write, 1 byte memory read, ICE reset, ICE execution, and the result. Is sent from the command issuing unit 554 to the VirtualLink 560 in the ICE debugger 506.
[0101]
The VirtualLink 560 controls the existing debugger 562, issues a reset command to the ICE 400, issues an execution start command, uses the execution completion notification as return data of the synchronous reception unit 550, and a data transmission unit that is a message transmission source. Reply to 320. The data transmission unit 320 notifies the scenario reading unit 316 that the reset GO command has been executed, and executes the execution according to the contents of the scenario file 352.
[0102]
<Flow data from scenario file to virtual wiring>
The scenario reading unit 316 reads the key code from the scenario file 352, instructs the data transmission unit 320, and bridges the message created according to the 1-byte memory write command issue format in the message list as shown in FIG. Addressed to 504, the data is sent from the bus slot 106 to the virtual wiring 206 by synchronous communication.
[0103]
<Bridge writing process>
The message sent from the data transmission 320 to the bridge 504 via the bus slot 502 is received by the synchronous reception unit 550 that performs reception interrupt processing as shown in FIG. Then, the command conversion unit 552 analyzes which message, such as 1-byte memory write, 1-byte memory read, ICE reset, and ICE execution, is based on the table shown in FIG. The analysis result is passed from the command issuing unit 554 to the VirtualLink 560 in the ICE debugger 506.
[0104]
The VirtualLink 560 controls the existing debugger 562, writes the RAM data of the designated RAM address passed from the virtual input 102 to the synchronization RAM 404 in the ICE 400 executing the program 414 on the fly, and then notifies the completion of writing. Is sent back to the data transmission unit 320, which is the message transmission source, as reply data of the synchronous reception unit 550. When receiving the reply, the execution status distribution unit 322 notifies the event detection unit 308 that the key data has been distributed.
[0105]
<Transfer processing from synchronization RAM to user RAM>
The synchronization program 412 causes the microcomputer emulator 406 to check changes in the synchronization RAM 404 at a timing required for the program 414.
[0106]
For example, in the case of key input, the synchronization program 412 is called immediately after the key input processing of the program 414, and the change of the key data RAM in the synchronization RAM 404 is checked via the microcomputer emulator 406. For example, the key data is transferred to the key data confirmation area of the user RAM 402. At this time, when the key data of the virtual input 102 and the key data from the real device 150 are input at the same time, the key data from the virtual input 102 is given priority.
[0107]
Specifically, the key input process in the synchronization program 412 is as described with reference to FIG. 4 in the first embodiment. Thereby, the virtual key input is processed with priority over the actual machine key input.
[0108]
<Data transfer from user RAM to virtual output>
When the program 414 changes the output RAM data (output data to the virtual output 104) in the user RAM 402 by the key code read from the scenario file 352, the method of transferring this output RAM data to the virtual output 104 is as follows ( c1) to (c4).
[0109]
(C1) Program user RAM change;
Immediately after the RAM area related to the virtual output 104 in the user RAM 402 is changed by the program 414, processing for transmitting the change from the user RAM 402 to the specific RAM in the synchronization RAM 404 is performed. Specifically, as shown in FIG. 5, the process is started by calling a virtual synchronization routine from the program 414 (step S420). Immediately after performing the output process to the real device 150 (step S422), a change in the output RAM data to the real device 150 is detected (step S424). If there is a change, the output RAM data is synchronized from the user RAM 402 to the synchronization RAM 404. (Step S426).
[0110]
(C2) flowing data from the virtual output to the virtual wiring;
Next, in order to read the change event of the output RAM data in the synchronization RAM 404 from the virtual output 104, the message slot designation from the virtual output 104 to the debugger 500 and the RAM address for reading the event are combined with the bus slot 108. Via the virtual wiring 206 via synchronous communication.
[0111]
(C3) Bridge device read processing;
A message sent from the virtual output 104 to the bridge 504 via the bus slot 502 is received by the synchronous reception unit 550 that performs reception interrupt processing, as shown in FIG. After that, the command conversion unit 552 analyzes which message is 1 byte memory write, 1 byte memory read, ICE reset, ICE execution, or the like, according to the message list as shown in FIG. The command issuing unit 554 passes the analysis result to the Virtual Link 560 in the ICE debugger 506. The VirtualLink 560 controls the existing debugger 562 to read output RAM data in the synchronization RAM 404 in the ICE 400 on the fly during program execution. Thereafter, the synchronous reception unit 550 returns the read output RAM data to the virtual output 104 that is the transmission source of the message. Thereby, the transfer of the output RAM data to the virtual output 104 is completed.
[0112]
(C4) Virtual output display processing;
The virtual output 104 displays a virtual LCD on a personal computer monitor based on the output RAM data. If there is a change in the image data acquired from the synchronization RAM 404 or the user RAM 402 to the virtual output 104, the virtual output 104 sends an image change message and an image change message to the image data acquisition unit 310 via the execution status distribution unit 322. The display dump data of the virtual output 104 is transferred.
[0113]
Alternatively, a method may be used in which the data in the user RAM 402 is read into the debugger 500 from the virtual input 102 at a constant cycle and the virtual output 104 is displayed on the virtual output 104 without using the event.
[0114]
<Transfer from data transfer to event detection>
When the key data is sent from the data transmission unit 320 to the execution status distribution unit 322, the key data is transferred from the event detection unit 308 to the image data acquisition unit 310. If there is a change in the image data acquired from the synchronization RAM 404 or the user RAM 402 to the virtual output 104, the image change message is sent from the virtual output 104 to the image data acquisition unit 310 via the execution status distribution unit 322. And transfer the display dump data of virtual output. The image data acquisition unit 310 writes the key data from the verification result writing unit 304 to the verification result file 350.
[0115]
Further, upon receiving a display change message from the virtual output 104, the image data acquisition unit 310 captures a display image of the virtual output 104 on the clipboard 200. The image captured on the clipboard 200 is written into the verification result file 350 by the verification result writing unit 304.
[0116]
Specifically, as shown in FIG. 12, the key data is written in the operation key column, and the screen mode of the scenario file 352 is written in the screen mode column.
[0117]
<Comparison of reference image data and execution image data>
In the verification result file 350, the data difference between the “reference image data” and the “executed image data” is determined, and the determination result is written as “◯” and “X” in the “determination” column. When the verification result file 350 is created by Excel, the difference between “reference image data” and “executed image data” can be determined using an IF function.
[0118]
<Creation of reference image data>
The reference image for performing the automatic verification process and the display dump data thereof are created by writing the image data and the display dump data on the reference screen and the execution image data shown in FIG. Can be created.
[0119]
<Effect>
As described above, according to the present embodiment, by using a scenario file, automatic program verification can be performed, and evaluation efficiency can be improved. In addition, the execution status of automatic program verification can be monitored from a remote location.
[0120]
(Fourth embodiment)
After the hardware of the actual machine on which the program 414 is to be mounted is completed, as shown in FIG. 14, automatic verification can be performed by a program verification system using only the actual machine debug set without using a virtual device. is there.
[0121]
【The invention's effect】
As described above, according to the present invention, in a program verification system using ICE, hardware for performing program verification in which peripheral devices are divided into real devices and virtual devices is not required, and program verification can be performed in a short time. You can build a system. As for automatic verification, output display such as an LCD display can be recorded as a display image regardless of a real device or a virtual device, so that the program verification time can be shortened. Furthermore, since the automatic verification can be controlled remotely, the program can be debugged and verified by remote operation, thereby improving work efficiency.
[Brief description of the drawings]
FIG. 1 is a block diagram showing the configuration of a program verification system according to a first embodiment of the present invention.
FIG. 2 is a block diagram showing the internal configuration of the debugger
FIG. 3 is an explanatory diagram of a list of messages from a virtual device to a bridge.
FIG. 4 is a flowchart of key input processing.
FIG. 5 is a flowchart of display output processing.
FIG. 6 is a block diagram showing a configuration of a program verification system according to a second embodiment of the present invention.
FIG. 7 is an explanatory diagram showing an example of a verification result file
FIG. 8 is a block diagram of a program verification system using a plurality of cameras as a modification of the program verification system according to the second embodiment.
FIG. 9 is a block diagram showing a configuration of a program verification system according to a third embodiment of the present invention.
FIG. 10 is a block diagram of a modification of the program verification system according to the third embodiment.
FIG. 11 is an explanatory diagram showing an example of a scenario file
FIG. 12 is an explanatory diagram showing an example of a verification result file according to the third embodiment.
FIG. 13 is an explanatory diagram showing a list of events from the ICE to the virtual device.
FIG. 14 is a block diagram showing a configuration of a program verification system according to a fourth embodiment of the present invention.
FIG. 15 is a block diagram of a conventional program verification system using an actual machine debug set.
FIG. 16 is a block diagram of a program verification system using a conventional system simulator set.
FIG. 17 is a block diagram of a conventional program verification system mixed with a real set simulator.
[Explanation of symbols]
100 virtual devices
102 Virtual input
104 Virtual output
120 peripheral devices
150 Actual device
152 Actual input
154 Actual output
156 Actual input / output
200 clipboard
202, 203 Camera monitor
204,205 PC camera
206 Virtual wiring
300 Automatic verification controller
302 Recording control unit
304 Verification result writing unit
308 Event detector
310 Image data acquisition unit
312 bus slot
314 Scenario control unit
316 Scenario reading part
318 Timing control unit
320 Data transmitter
322 execution status distribution part
350 Verification result file
352 scenario file
400 ICE
402 User RAM
404 Synchronization RAM
410 Real machine program
412 Synchronization program
500 Debugger
502 bus slot
504 bridge
506 ICE debugger
600 Email sending and receiving part
604 portable information terminal
606 Execution status monitor
608 Remote control unit
610 Mail delivery control unit

Claims

Using a real device and a virtual device as a peripheral device of a microcomputer, a program verification system for verifying the operation of the microcomputer program,
An emulator for emulating the operation of the program on the microcomputer;
A verification control unit that controls the emulator to perform a verification operation corresponding to the actual device;
A bridge unit that is provided between the verification control unit and the virtual device, and adapts a control signal and data from the virtual device to the verification control unit;
RAM for actual machine for storing input / output data between the actual machine device and the program;
A synchronization RAM provided between the real machine RAM and the virtual device;
A program comprising a virtual / real machine synchronization processing unit for controlling data transfer between the synchronization RAM and the real machine RAM in synchronization with an input / output operation of the program to the real machine device Verification system.

The program verification system according to claim 1, wherein the virtual device and the bridge unit are connected by virtual wiring.

The program verification system according to claim 1, comprising a plurality of the virtual devices.

A photographing device for photographing a real machine monitor output image output by the real machine device;
The program verification system according to claim 1, further comprising a verification result writing unit that records the actual monitor output image and a virtual monitor output image output by the virtual device in a verification result file. .

An event detector for detecting a predetermined change in the peripheral device;
5. The program verification system according to claim 4, further comprising an image acquisition unit that captures the actual machine monitor output image and the virtual monitor output image at a timing according to a detection result of the event detection unit.

The program verification system according to claim 5, further comprising a verification status distribution unit that transmits a verification processing status including the real machine monitor output image or the virtual monitor output image to an external terminal according to a detection result of the event detection unit.

The program according to claim 6, further comprising a remote control unit that receives a message including a control signal and its destination from an external terminal, extracts the control signal from the received message, and distributes the control signal to the destination of the control signal. Verification system.

The program verification system according to any one of claims 4 to 7, comprising a plurality of the photographing devices.

The program according to any one of claims 1 to 8, further comprising a scenario control unit that reads data from a scenario file that records an operation procedure for automatically verifying the program and transfers the data to the bridge unit. Verification system.

The program verification system according to claim 9, further comprising a timing control unit that controls transfer of data read from the scenario file to the bridge unit in accordance with an operation state of the emulator.