(57)【特許請求の範囲】
【請求項１】
ＩＥＥＥ１３９４高速シリアルバス対応の機器のプロトコルを検査する方法であって、
少なくとも前記プロトコルの検査に必要な送信アシンクロナスパケットとそれに対応する受信アシンクロナスパケットと前記バスに対してバスリセットを引き起こすバスリセットコードとをデータファイルとして保有する検査装置を用意し、この検査装置と前記機器を前記バスで接続し、前記検査装置の検査アプリケーション上で前記データファイルを開き、前記データファイルに書かれている送信アシンクロナスパケットを前記検査装置から前記機器へ前記バスを介して順次送信し、所望の場所に設定された前記バスリセットコードに基づき前記バスに対してバスリセットを行い、前記バスを介して前記機器から返ってきた受信アシンクロナスパケットと前記データファイルに書かれている前記受信アシンクロナスパケットを比較することを特徴とするＩＥＥＥ１３９４プロトコル検査方法。
【請求項２】
前記機器から返ってきた受信アシンクロナスパケットが前記データファイルに書かれている前記受信アシンクロナスパケットと異なる場合には、前記機器から返ってきた受信アシンクロナスパケットのデータ及びエラー数のデータを保存する請求項１に記載のＩＥＥＥ１３９４プロトコル検査方法。
【請求項３】
前記機器から返ってきた受信アシンクロナスパケットのデータ及びエラー数のデータをテキストファイルとして保存する請求項２に記載のＩＥＥＥ１３９４プロトコル検査方法。
【請求項４】
データファイルに誤りがあった場合には、データファイルにエラーがあることをメッセージ等でユーザーに知らせ、検査には入らない請求項３に記載のＩＥＥＥ１３９４プロトコル検査方法。
【請求項５】
ＩＥＥＥ１３９４高速シリアルバス対応の機器のプロトコルを検査する装置であって、
少なくとも前記プロトコルの検査に必要な送信アシンクロナスパケットとそれに対応する受信アシンクロナスパケットと前記バスに対してバスリセットを引き起こすバスリセットコードとを有するデータファイルを備え、検査アプリケーション上で前記データファイルを開き、前記データファイルに書かれている送信アシンクロナスパケットを前記機器へ前記バスを介して順次送信し、所望の場所に設定された前記バスリセットコードに基づき前記バスに対してバスリセットを行い、前記バスを介して前記機器から返ってきた受信アシンクロナスパケットと前記データファイルに書かれている前記受信アシンクロナスパケットを比較することを特徴とするＩＥＥＥ１３９４プロトコル検査装置。
【請求項６】
前記データファイルには、さらにアックコード、所望のメッセージを促すメッセージコード、所望の場所で待時間を入れるウェイトコード、所望の場所でルート／非ルートになるようにバスリセットを起こすことができるバスリセットコードが書かれている請求項５に記載のＩＥＥＥ１３９４プロトコル検査装置。
【請求項７】
前記データファイルを書き換えるだけで、実行ファイルは書き換えることなく検査を行うことができる請求項５に記載のＩＥＥＥ１３９４プロトコル検査装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＩＥＥＥ１３９４高速シリアルバス対応の機器を開発する際に、ＩＥＥＥ１３９４プロトコルを満たしているかどうかを検査するための方法及び装置に関する。
【０００２】
【従来の技術】
ＩＥＥＥ１３９４高速シリアルバス（以下１３９４シリアルバスという）を用いてデジタルビデオ信号及びデジタルオーディオ信号の送受信を行う機能を備えたデジタルビデオカメラが既に商品化されている。また、パーソナルコンピュータ（以下ＰＣという）に周辺装置を接続するインターフェースとして１３９４シリアルバスが注目されている。
【０００３】
１３９４シリアルバスで接続した機器の間では、デジタルビデオ信号及びデジタルオーディオ信号等のリアルタイムデータのアイソクロナス伝送と、各種制御コマンド等のアシンクロナス伝送を行うことができる。
【０００４】
従来、１３９４シリアルバス対応の機器がＩＥＥＥ１３９４プロトコル（以下１３９４プロトコルという）を満たしているかどうかを検査する際には、ＰＣ等で構成した検査装置と、検査対象機器との間を１３９４シリアルバスで接続する。そして、検査装置において例えばアシンクロナスパケットの送受信用アプリケーションを立ち上げる。そして、図８に示すようなアプリケーション画面上で、キーボードから任意の１つのパケットのヘッダー、ブロックデータ、及びサイズ等を入力して送信すると、検査対象機器から受信したレスポンスパケットがアプリケーション画面上に表示される。また、送受信したＡＣＫデータや、受信アシンクロナスパケットカウンター、バスリセット発生カウンター、そしてバスリセット発生時にはセルフＩＤパケットが受信パケット画面上に表示される。
【０００５】
これにより、所望のパケットを送り、正しいレスポンスパケットが返ってきたかどうかをチェックすることによって、１３９４プロトコルを満たしているかどうかを検査することができる。また、送受信したＡＣＫデータや、受信カウンター、バスリセット発生の有無等も合わせて検査することによって、より詳細で確実な検査を行うことができる。
【０００６】
【発明が解決しようとする課題】
しかしながら、前記の従来の方法では、１３９４プロトコルを満たしているかを検査するために膨大な量のパケットをキーボードから入力して送受信することが必要であった。また、結果が正しいかどうかも人間が判断しなければならず、大変な労力が必要であった。
【０００７】
本発明はこのような問題点に鑑みてなされたものであって、１３９４プロトコルを満たしているかどうかの検査を自動的に行えるようにした１３９４プロトコル検査方法及び装置を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明に係る１３９４プロトコル検査方法は、１３９４シリアルバス対応の機器のプロトコルを検査する方法であって、少なくともこのプロトコルの検査に必要な送信アシンクロナスパケットとそれに対応する受信アシンクロナスパケットと１３９４シリアルバスに対してバスリセットを引き起こすバスリセットコードとをデータファイルとして保有する検査装置を用意し、この検査装置と１３９４シリアルバス対応の機器をシリアルバスで接続し、検査装置の検査アプリケーション上で前記データファイルを開き、このデータファイルに書かれている送信アシンクロナスパケットを検査装置から１３９４シリアルバス対応の機器へ１３９４シリアルバスを介して順次送信し、所望の場所に設定されたバスリセットコードに基づき１３９４シリアルバスに対してバスリセットを行い、１３９４シリアルバス対応の機器から返ってきた受信アシンクロナスパケットと前記データファイルに書かれている前記受信アシンクロナスパケットを比較することを特徴とするものである。
【０００９】
本発明に係る１３９４プロトコル検査装置は、１３９４シリアルバス対応の機器のプロトコルを検査する装置であって、少なくともこのプロトコルの検査に必要な送信アシンクロナスパケットとそれに対応する受信アシンクロナスパケットと１３９４シリアルバスに対してバスリセットを引き起こすバスリセットコードとを有するデータファイルを備え、検査アプリケーション上で前記データファイルを開き、前記データファイルに書かれている送信アシンクロナスパケットを１３９４シリアルバス対応の機器へ１３９４シリアルバスを介して順次送信し、所望の場所に設定されたバスリセットコードに基づき１３９４シリアルバスに対してバスリセットを行い、１３９４シリアルバス対応の機器から返ってきた受信アシンクロナスパケットと前記データファイルに書かれている前記受信アシンクロナスパケットを比較することを特徴とするものである。
【００１０】
本発明では、１３９４プロトコルの検査に必要な送信アシンクロナスパケットとそれに対応する受信アシンクロナスパケット等をデータファイルとして作成しておき、データファイル上に書かれている送信アシンクロナスパケットを順に送信しながら、データファイル上に書かれている受信アシンクロナスパケットと実際に受信したアシンクロナスパケットとの比較を自動的に行う。
【００１１】
【発明の実施の形態】
以下本発明の実施の形態について図面を参照しながら詳細に説明する。
【００１２】
図１に本発明を適用したシステムの構成を示す。このシステムはＰＣシステム１のＰＣ本体２とカメラ一体型ビデオテープレコーダ（以下ＣＡＭという）５との間を１３９４シリアルバス６で接続したものである。そして、ＰＣＩバス対応のＩＥＥＥ１３９４インターフェースボード（以下１３９４  Ｉ／Ｆボードと略す）４をＰＣ本体２のＰＣＩスロットに挿入し、ＰＣ本体２上でプロトコル検査用のアプリケーションを作成し、アシンクロナスパケットを送受信することによって、所望の機器（ここではＣＡＭ）のＩＥＥＥ１３９４プロトコルを検査することを実現した例である。
【００１３】
図２は図１のＰＣ本体２の内部の構成の概略を示すものである。ここで、図１と同一の部分には図１に付した番号と同一の番号が付してある。
【００１４】
ＰＣ本体２の内部に設けられた１３９４  Ｉ／Ｆボード４には、物理層コントロールブロック（ＰＨＹ）１１と、リンク層コントロールブロック（ＬＩＮＫ）１２とが設けられている。
【００１５】
物理層コントロールブロック１１は１３９４バスの初期化やバスの使用権の調停等を行う。また、リンク層コントロールブロック１２との間で、各種制御信号の通信を行うとともに、これらの信号を１３９４シリアルバス６に対して送受信する。
【００１６】
リンク層コントロールブロック１２は、パケットの作成／検出、誤り訂正処理等を行う。
【００１７】
ＰＣシステム１の本体２の内部には、さらにＣＰＵ１４と、ＲＡＭ１５と、モニターインターフェース１６と、ファイルメモリ１７と、アプリケーションメモリ１８とが設けられている。
【００１８】
ＣＰＵ１４はＰＣ本体２の全体の制御等を行う。ＲＡＭ１５はＣＰＵ１４が各種データの処理を行う際のワークエリアとなる。モニターインターフェース１６はモニター３との間の制御信号の通信やモニター３に対するビデオ信号の送信を行う。ファイルメモリ１７は１３９４プロトコルの検査に必要な検査データのファイル及び検査結果のファイル等を格納する。アプリケーションメモリ１８は検査用アプリケーション等を格納する。ファイルメモリ１７及びアプリケーションメモリ１８は、実際にはハードディスク装置の記憶エリアの一部として構成される。
【００１９】
ＲＡＭ１５上のアプリケーションプログラムは物理層コントロールブロック１１とリンク層コントロールブロック１２の制御、コマンドやレスポンスの作成等の処理を行う。このアプリケーションプログラムはコマンドやレスポンスを作成するときにはリンク層コントロールブロック１２内に設けられたレジスタの所定のアドレスにデータを書き込む。また、他の機器が送信したコマンドやレスポンスは、前記レジスタの所定のアドレスに書き込まれた後、アプリケーションプログラムにより読み出される。
【００２０】
なお、実際にはＰＣ本体２内には、さらにキーボードインターフェースやＲＯＭ等が設けられているが、ここでは省略した。
【００２１】
本実施の形態ではファイルメモリ１７の内部には、検査対象である機器（ここではＣＡＭ５）が１３９４プロトコルを満たしているかどうかを検査するために必要な一連の送信パケットとそれに対応する受信アシンクロナスパケット、アック（ＡＣＫ）コード、所望のメッセージを促すメッセージコード、所望の場所で待時間を入れるウェイトコード、所望の場所でルート／非ルートになるようにバスリセットを起こすことができるバスリセットコード等がデータファイルとして格納してある。そして、検査用アプリケーションを立ち上げ、処理を開始すると、このデータファイルが開かれ、以後各種パケットの送信、アックの受信、エラーの検出等が自動的に実行される。
【００２２】
図３はＰＣ本体２上で作成した検査用アプリケーションの処理を示すフローチャートである。まずＰＣ本体２において検査用アプリケーションを立ち上げ、検査用データファイルを開く（ステップＳ１）。この時、モニター３の画面に表示される映像を図４に示す。
【００２３】
この画面のツールバー上でＧＯを選択すると（ステップＳ２）、データファイル上のデータを全て読み出し、文法エラーがないかチェックする（ステップＳ３）。ここで、文法エラーがあった場合には、データファイルにエラーがあることをメッセージ等でユーザーに知らせ、検査には入らないようにする。
【００２４】
次にデータファイルに格納されている検査項目の数をカウントする（ステップＳ４）。ここではカウント値がＮであったものとする。
【００２５】
次のステップＳ５では後述するデータ処理カウンタ（図示せず）の値がＮになっているかどうかを判断し、ＮになるまでステップＳ６の処理に移行する。そして、ステップＳ６ではデータファイルを順番に読み出し、そこに書かれている処理を実行する。さらに、データファイルから読み出した処理を実行する毎にデータ処理カウンタ（図示せず）の値を１インクリメントし、ステップＳ５に戻る。ここでは、図４に示すように、まずデータファイル上の送信を示すコード（ここではＴＸ）の後に続くパケットを送信する。次にアックデータを示すコード（ここではＡＴＡＣＫ）があるため、実際に受信したアックとファイル上のデータを比較して間違っていたら実際に受信したアックを次の行に挿入しエラーカウンタ（図示せず）を１インクリメントする。次は受信を示すコード（ここではＲＸ）が現れるため、実際に受信したパケットとファイル上のデータを比較して間違っていたら実際に受信したパケットを次の行に挿入し、エラーカウンタを１インクリメントする。次にまたＴＸが現れるため、その後に続くパケットを送信する。
【００２６】
以下同様に、データファイル上のＮ個のデータを全て読み出して処理するまでアシンクロナスパケットの送受信を繰り返し、１３９４プロトコルの検査を行なう。
【００２７】
全データ分の検査が終了したら、モニターインターフェース１６を介してモニター３の画面上に検査データと共にエラーの数を表示し、さらにセーブを促すダイアログを表示する（ステップＳ７）。そして、画面のツールバー上でセーブのコマンドが入力されたら、ファイルメモリ１７にテキストファイルとして保存する（ステップＳ８）。
【００２８】
ここで、必要に応じて、データファイル上にメッセージを示すコードを入れておけば「再生してください」等のメッセージボックスを表示したり、自分がルート（ｒｏｏｔ）になるように（ここではＢＲ＿ＲＯＯＴ）又は検査対象機器がルートになるようにバスリセットを起こす（ここではＢＲ＿ＮＯＴＲＯＯＴ）意味のコードを入れておけば、所望のバスリセットを起こすこともできる。待ち時間を入れる意味のコード（ここではＷＡＩＴ）を入れておけば待ち時間を入れることもできる。
【００２９】
図５は結果がＯＫの場合の検査結果データの例を示す。これはＣＳＲ（Ｃｏｎｔｒｏｌ  ａｎｄ  Ｓｔａｔｕｓ  Ｒｅｇｉｓｔｅｒ）のノードＩＤレジスタを検査したものである。そして、図６及び図７は結果がＮＧの場合の検査結果データの例の前半部と後半部を示す。これはＣＳＲのステートクリアレジスタを検査したものである。図７の「；ＲＥＳＵＬＴ  ＲＸ」の後に続く「ＦＦＣ０００６０，・・・  ０００００００１」は受信したレスポンスパケットを示す。そして、その１行上の「ＲＸ」と「ＦＦＣ１００６０，・・・  ０００００００１」はデータファイルに書いてあるパケットで本来受信すべきパケットである。これらの検査結果データはモニター３の画面に表示された後、ファイルメモリ１７にテキストファイルとして保存される。
【００３０】
なお、図４、図６〜図７ではモニター３の画面上にはデータファイルの内容を“ＴＸ”  “０００００１４０・・・”等のコードで表示したが、これらをメッセージ（このコードの場合は、“送信”と“パケットの宛先”等）で表示してもよい。
【００３１】
このように本実施の形態によれば、簡単操作かつ短時間で１３９４プロトコルを自動的に検査できる。また、検査装置を操作するユーザーは、プロトコルを知らなくても検査できる。さらに、検査結果はテキストファイルとして保存できるため、履歴を残したりデバッグなどに非常に有効に使える。また、検査用データの文法エラーもチェックできるため、プロトコルを正しく検査でき、かつ、ソースは書き換えなくても、データを書き換えるだけで任意のパケットの送受を行えるため、プロトコル及びセット仕様の変更等にも柔軟に対応できる。
【００３２】
【発明の効果】
以上詳細に説明したように、本発明によれば、自動的にアシンクロナスパケットの送受信を行うだけでなく、１３９４プロトコルとしてのパケットの正誤チェックまで行うため、検査のための操作が簡単になり、かつ検査時間を非常に短縮できる。また、１３９４プロトコルを知らないユーザーでも簡単操作でプロトコルの検査ができる。さらに、検査結果はテキストファイルとして保存できるため、履歴を残したりデバッグなどに非常に有効に使える。また、データファイル上の検査データの書き換えだけで様々なプロトコルの検査に柔軟に対応できる。
【図面の簡単な説明】
【図１】本発明を適用したシステムの構成を示す図である。
【図２】図１のＰＣ本体の内部の概略構成を示すブロック図である。
【図３】図１のＰＣ本体上で作成した検査用アプリケーションの処理を示すフローチャートである。
【図４】図３の検査用アプリケーションを立ち上げ、検査用データファイルを開いた時に図１のモニターの画面に表示される映像を示す図である。
【図５】結果がＯＫの場合の検査結果データの例を示す図である。
【図６】結果がＮＧの場合の検査結果データの例の前半部を示す図である。
【図７】結果がＮＧの場合の検査結果データの例の後半部を示す図である。
【図８】従来のアシンクロナスパケットの送受信用アプリケーションの画面を示す図である。
【符号の説明】
１…ＰＣシステム、２…ＰＣ本体、４…１３９４  Ｉ／Ｆボード、５…ＣＡＭ、６…１３９４シリアルバス、１７…ファイルメモリ、１８…アプリケーションメモリ。
【図１】
0003613930.tif 000002
【図２】
0003613930.tif 000003
【図３】
0003613930.tif 000004
【図４】
0003613930.tif 000005
【図５】
0003613930.tif 000006
【図６】
0003613930.tif 000007
【図７】
0003613930.tif 000008
【図８】
0003613930.tif 000009