JP5361564B2 - 異なるバスプロトコルを示す柔軟なアプローチ - Google Patents

Description

本発明は、概述すると、電子通信に関し、更に詳細に述べると、通信プロトコルを示し且つ操作するためのデータ構造に関する。

近年、ユニバーサルバステスト装置が、異なるインターフェイスの仕様及びプロトコルで作動する種々のシリアルバスを制御するために開発されてきた。米国特許出願番号１０／３２５、０７０「種々のシリアルバスタイプのシミュレーション、エミュレーション及びテストのユニバーサルアプローチ」は、この装置の特徴について記載しており、本願に参考のために組み込まれている。組み込まれた出願及び本出願の両出願は、同日に出願された仮出願に基づいている。一方の出願は、他方に対する従来技術ではない。

組み込まれた特許出願は、「バスモデル」の使用を通じてジェネリックシリアルバスのプロトコル及び性質を定義している。上述のように、バスモデルは、シリアルバスプロトコルを、全てのバスに共通な個々のジェネリック層に分解する。特定のターゲットバスでは、バスモデルは、ジェネリック層に関してターゲットバスプロトコルを示し、各ジェネリック層にバス特有属性を割り当てる。従って、バスモデルは、ジェネリック層に関してターゲットバスプロトコルの抽象的な表現を形成する。

図１は、バスモデル１００のブロック図を示す。バスモデルの層は、例えば、フレーム１１２、１３２、メッセージ１１４、１３４、ワード１１６、１３６、フィールド１１８、１３８、シンボル１２０、１４０、シーケンス１２２、１４２、エンコード１２４、１４４及びタイミング１２６、１４６を備える。

従来のバステスト装置は、主にバス特有のものである。バステスト装置は、一つ以上の特定のタイプのバスを制御するために設計されているが、他のタイプのバスを制御するために用いることはできない。従って、これらの装置に含まれ用いられる通信構造は、特に支持されたバスとの通信に必要な構造のみである。それらは、他のタイプのバスに適応することができない。

図２は、従来技術のバス特有テスト装置により使用された典型的な通信構造を示す。説明のために、ＭＩＬ−ＳＴＤ−１５５３バステスト装置の通信構造を示す。この装置は、一組のバス特有メッセージタイプ２１０を支持する。メッセージタイプ２１０は、ターゲットバスで行なうことができる高レベルな操作を規定する。１５５３バスでは、これらのメッセージタイプは、特に、バスコントローラからリモートターミナルへのメッセージタイプ（ＢＣ−ＲＴ）、リモートターミナルからバスコントローラへのメッセージタイプ（ＲＴ−ＢＣ）及びリモートターミナルからリモートターミナルへのメッセージタイプ（ＲＴ−ＲＴ）を含む。

各メッセージタイプ２１０は、ワードからなる。一般的に、ターゲットバスの仕様は、種々のバス操作を行なうための一組のワードタイプを形成する。バス１５５３では、コマンドワード、データワード及びステータスワードの３つの異なるワードタイプ２１２が設けられている。

ワードは、フィールドからなる。ワード内のフィールドの識別及び配置は、ターゲットバスの規定により定められている。図２に示すように、１５５３コマンドワード２１６は、６フィールド２１４からなる。これらのフィールドは、１５５３規格により規定されたように、同期（Ｓｙｎｃ）、ＲＴアドレス、送信/受信、サブアドレスモード、データワードカウント/モードカウント及びパリティを備える。

従来技術のバス特有構造のそれぞれは、特定のターゲットバスを制御するために必要なメッセージタイプ及びワードタイプを支持する。しかしながら、一般的に、バス特有構造は、それぞれのターゲットバスのプロトコルに限定されている。バス特有構造は、ユーザが、異なるタイプのバスに異なるメッセージタイプやワードタイプを定義する方法を提供しない。従って、バス通信を定義するより柔軟な方法が必要とされる。

上述の背景をふまえ、本発明の目的は、ユーザが、ターゲットバス又は他の通信媒体とやり取りするための通信構造を柔軟に形成することができるようにすることである。

上述の目的を達成するために、他の目的及び効果と同様に、通信構造を柔軟に形成する方法は、バスモデルとして、一般化された通信モデルの少なくとも一つの層に、少なくとも一つの通信要素タイプを提供する。各通信要素タイプは、ターゲット通信媒体の対応するプロトコル層を示すために適応可能なユーザ定義可能構造を有する。ユーザは、ターゲットプロトコルを実質的に示すために特定の通信要素タイプを定義することができる。また、ユーザは、正確な方法で定義されたターゲットプロトコルから外れるために通信要素タイプを定義することができる。

ジェネリックバスモデルの概念を示すブロック図である。 従来技術によるＭＩＬ−ＳＴＤ−１５５３バスの通信構造の部分を示す図である。 本発明による柔軟な通信構造の部分を示す図である。 バスモデル内のバス通信のためのあるデータタイプを定義するための本発明による工程を示すフローチャートである。

本発明の別の目的、効果及び新規な特徴は、以下に続く詳細な説明及び図面により明らかとなる。

本発明によるジェネリック通信構造は、ユーザが、ユーザの選択する通信要素タイプを定義することにより、従来技術のバス特有構造から逸脱する。通信要素タイプは、バスモデルの異なる層を示す。これらの通信要素タイプは、例えば、メッセージタイプ、ワードタイプ及びフィールドタイプを含む。バスモデルの他の層を示すために、他の通信要素タイプを構築することもできる。ユーザは、これらの通信要素タイプを既存のバス又は次のバスのために定義することができる。

図３は、本発明によるジェネリック通信構造の実施態様を示す。従来技術のように、図３の構造は、メッセージタイプ（例えば、メッセージタイプ３１０）、ワードタイプ（例えば、ワードタイプ３１２）及びフィールドタイプ（例えば、フィールドタイプ３１４）を備える。各メッセージタイプは、少なくとも一つのワードタイプを備え、各ワードタイプは、少なくとも一つのフィールドタイプを備える。

しかしながら、図３の構造は、柔軟性において従来技術とは明らかに異なる。この柔軟性の達成に特に重要なものは、バスモデル３００である。上述のように、バスモデルは、あらゆるシリアルバスの仕様を示すためのジェネリック層構造である。異なるバスタイプと通信するために、異なるインスタンスのバスモデルを構築することができる。各バスモデルのインスタンスは、特定のタイプのバスに調整された通信要素タイプを定義する。

バスモデル３００又はそのインスタンスは、一組のメッセージタイプ３１０を備える。従来技術の定義されたメッセージタイプとは異なり、メッセージタイプ３１０は、ユーザ定義可能構造を有する。各メッセージタイプでは、ユーザは、ターゲットバスにわたるいくつかの重要な通信を構築するワードタイプの順序グループ及び名前を定義することができる。例えば、ユーザは、ワードタイプＡ、Ｂ及びＣからなるメッセージタイプＮ３１６を構築することができる。ワードタイプＡ、Ｂ及びＣを、バスモデルに定義されたワードタイプ（１からＭ）のいずれかにすることができ、ワードタイプＡ、Ｂ及びＣのシーケンスは、いくつかの有益な機能を実行する。ユーザは、所望の数のメッセージタイプを定義することができる。

バスのメッセージタイプは、典型的には、バスのプロトコルにより規定されたメッセージ、即ち、バスタイプのスタンダードメッセージタイプに対応することができる。しかしながら、メッセージタイプは、広範囲のアプリケーションを有することができる。ユーザは、特定のテストシナリオを扱うために、カスタムメッセージタイプを構築することができる。従って、一般的には、メッセージタイプは、ターゲットバスのプロトコルに一致しているが、そのプロトコルが規定する特定のメッセージに限定される必要はない。

また、ユーザ定義メッセージタイプを、ターゲットバスのプロトコルに規定されたメッセージタイプとは異なって構築することができる。例えば、プロトコルは、シンプル又は異なるメッセージのシーケンスとしてバスモデルに表示されやすいコンプレックスメッセージを定義することができる。従って、バスプロトコルで定義されたメッセージとバスモデルで求められたメッセージとの間に直接一対一の関係は必要ない。

バスモデル３００は、一組のユーザ定義ワードタイプ３１２を備える。各ワードタイプは、フィールドタイプのグループ及び名前により定義される。例えば、ワードタイプＣ（メッセージタイプＮの一部）を、フィールドタイプＡ、Ｂ、Ｃ及びＤを含むように定義することができる。ユーザは、所望の数のワードタイプを定義することができる。

また、フィールドタイプは、バスモデル３００に含まれている。フィールドタイプは、メッセージタイプ又はワードタイプよりもバス通信のより具体的な面を定義する。本発明者達は、限定された数の目的にのみにフィールドタイプが用いられることを発見した。簡略化のために、ユーザにフィールドタイプの特徴を定義する無限の柔軟性を提供する必要はない。代わりに、ユーザは、フィールド指定を割り当てることよりフィールドタイプの特徴を定義する。好ましい実施態様では、ユーザは、それぞれのフィールドタイプに次のフィールド指定のうちの一つを設定することができる。

テーブル１から明らかなように、いくつかのフィールドタイプは、コンスタントデータのように指定された固定値を有し、同様に、他のフィールドタイプは、パリティ又はＣＲＣのように指定された変数値を有する。好ましくは、固定フィールドの特定の値は、それぞれのバスモデルで指定される（以下のテーブル２で設定する「値」参照。）。

フィールドタイプ、ワードタイプ及びメッセージタイプは、本質的に、より高いレベルの構造を構築するために結合させることができる明確な構造を形成する。例えば、異なるワードタイプを構築するために、同一のフィールドタイプを異なるコンビネーションで用いることができ、異なるメッセージタイプを構築するために、同一のワードタイプを異なるコンビネーションで用いることができる。より高いレベル構造（例えば、１５５３コマンド・リスポンストランザクションのようなトランザクション）を形成するために、メッセージタイプさえも結合させることができる。

通信要素タイプの定義は、多くの方法で行なうことができる。例えば、単一のコンピュータファイル、異なるコンピュータファイル、ハードウエアー又はこれらのいずれかのコンビネーションにより行なうことができる。好ましい実施態様において、通信要素タイプは、XMLフォーマットのバスファイルの形式に設けられている。バスファイルは、「タグ」により通信要素タイプを同定する。例えば、異なるタグは、各フィールドタイプ、各ワードタイプ及び各メッセージタイプに用いられる。以下のコードセクションは、バスファイルのフィールドタイプ定義の一般化された例である。

〈フィ―ルド[フィールド属性]〉
〈フィールド名 ＝ 「フィールド１」 [フィールドタイプ設定]／〉
〈フィールド名 ＝ 「フィールド２」 [フィールドタイプ設定]／〉
…
〈フィールド名 ＝ 「フィールドL」 [フィールドタイプ設定]／〉
〈／フィールド〉

バスファイル内で、ワードタイプは、また、ＸＭＬタグを用いて示される。好ましくは、バスファイルは、次のフォーマットを用いるワードタイプを定義する。

〈ワード[ワード属性]〉
〈ワード名 ＝「ワード１」／〉
〈ワード名 ＝「ワード２」／〉
…
〈ワード名 ＝「ワードM」／〉
〈／ワード〉

各ワードタイプは、フィールドタイプのグループからなる。周知のように、ＸＭＬは、タグの階層的配列を支持し、特定のタグを他のタグの下位とすることができる。これにより、下位のタグを、特定のワードタイプに「属する」フィールドタイプを示すために用いることができる。例えば、以下の通り、バスファイルは、ユーザ定義ワードタイプ「ユーザワード」を構築するフィールドタイプを示すことができる。

〈ワード名 ＝ 「ユーザワード」〉
〈ワードフィールド フィールド名 ＝「フィールドタイプＡ」／〉
〈ワードフィールド フィールド名 ＝「フィールドタイプＢ」／〉
〈ワードフィールド フィールド名 ＝「フィールドタイプＣ」／〉
〈／ワード〉

フィールドタイプＡ、Ｂ及びＣは、「ユーザワード」ワードタイプを構築するフィールドタイプであり、好ましくは、バスファイルのどこかに定義される。

また、バスファイルは、メッセージタイプを示すタグを用いる。メッセージタイプを以下の通り示すことができる。

〈メッセージ〉
〈メッセージ名 ＝ 「メッセージタイプ１」 [メッセージタイプ設定]／〉
〈メッセージ名 ＝ 「メッセージタイプ２」 [メッセージタイプ設定]／〉
…
〈メッセージ名 ＝ 「メッセージタイプN」 [メッセージタイプ設定]／〉
〈／メッセージ〉

下位のタグを、メッセージタイプを構築するワードタイプを定義するために使用することができる。例えば、「マイメッセージ」を構築するワードタイプを以下の通り定義することができる。

〈メッセージ名 ＝ 「マイメッセージ」 [メッセージタイプ設定] 〉
〈メッセージワード ワード名 ＝ 「ワードタイプＡ」 〉
〈メッセージワード ワード名 ＝ 「ワードタイプＢ」 〉
〈メッセージワード ワード名 ＝ 「ワードタイプＣ」 〉
〈／メッセージ〉

ワードタイプＡ、Ｂ及びＣは、「マイメッセージ」を構築する特定のワードであり、好ましくは、バスファイルのどこかに定義される。

メッセージタイプ、ワードタイプ及びフィールドタイプのそれぞれは、バスの特徴及び性質をさらに定義するための設定を提供することができる。ＸＭＬは、ユーザにタグの属性を指定させることができる。データタイプの設定を定義するために、バスファイルは、これらのタグの属性を利用する。

メッセージタイプは、「可変長」設定を提供し、該設定は、メッセージが固定数のワードからなるか可変数のワードからなるかを、ユーザに指定させることができる。また、可変長メッセージでは、最長及び最短設定が設けられている。また、ワードタイプ及びフィールドタイプは、可変長設定を提供することができる。

ユーザは、フィールドタイプに種々の設定を定義することができる。次の設定は、好ましい実施態様において提供される。

メッセージタイプ、ワードタイプ及びフィールドタイプを定義するための通信要素タイプの使用は、ユーザにバス通信を構築する点において多大な柔軟性を提供する。 ユーザは、バスのフィールドを定義することができ、特定のフィールドからワードを構築し、特定のワードからメッセージを構築することができる。

この柔軟性により、テストの品質を向上させるための多くの機会が生じる。例えば、ユーザは、バス装置のテストにおいて、故障インジェクションを行なう広い能力を有する。ユーザは、バスのプロトコル又は仕様を意図的に乱す方法でフィールドタイプ、ワードタイプ及びメッセージタイプを定義することができる。テスト目的のために、フィールドを多数のビット又は少数のビットを備えるものとして定義することができる。ワードを多数のフィールド又は少数のフィールドを備えるものとして、又は、フィールドをワード内の不適切な位置に備えることにより、ワードを規定することができる。この柔軟性により、メッセージ、ワード及びフィールドのユーザ定義構造では、装置の反応を観察するために、制御された方法で、バスプロトコルから外れる大きな可能性がある。

また、この柔軟性により、ユーザはカスタムバスを含む新しいタイプのバスの新しいバスモデルを構築することができる。図４は、新しいバスモデルを構築するための工程を示す。ステップ４１０にて、ユーザは、ターゲットバスの仕様を調べる。ステップ４１２から４１６にて、ユーザは、支持される特定のフィールドタイプ、ワードタイプ及びメッセージタイプを、ターゲットバスの仕様及び使用者の特別なテストの必要性に応じて決定する。ステップ４１８にて、ユーザは、ターゲットバスのためにバスファイルの所望のフィールドタイプ、ワードタイプ及びメッセージタイプのための定義を構築する。その後、ユーザは、装置とやり取りするためにアクセスすることができる場所にバスファイルを保存する（ステップ４１８）。

一般的に、ユーザは、必要がある度にスクラッチから新しいバスファイルを構築する必要はない。異なるバスは、多数の同様の特徴を共有する。バスファイル（即ち、ＸＭＬファイル）の簡略化のために、既存のものをコピーし、少数の設定を変更することにより、ユーザは、しばしば簡単に新しいバスファイルを構築することができる。

ここで記載されているデータタイプ、即ち、メッセージタイプ、ワードタイプ及びファイルタイプは、基本的には、バスファイル内での定義として存在する。「インスタンス」の概念を通じて物理的なバスを実際に制御するために、これらの定義を実行することができる。周知のとおり、インスタンスは、特別なタイプの特定の表現である。従って、「メッセージインスタンス」は、メッセージタイプの特定の表現である。同様に、「ワードインスタンス」は、ワードタイプの特定の表現であり、「フィールドインスタンス」は、フィールドタイプの特定の表現である。これらのインスタンスを、より一般的に「通信要素インスタンス」としてみなすことができる。

特定のコンピュータ言語に設けられたユーザ定義データタイプ及びバスファイルの通信要素タイプを比較することができる。例えば、「Ｃ」コンピュータ言語は、特定のデータタイプを構築するための指示 「ｔｙｐｅｄｅｆ」を提供する。データタイプのインスタンスを、そのタイプの変化を示すことによりコンピュータプログラムで構築することができる。その後、コンピュータプログラムは、ランタイムでそのタイプのインスタンスにアクセスすることができそのインスタンスを扱うことができる。

バスファイルの通信要素タイプは、同様の方法で機能する。ユーザは、プログラムのコンテキストで用いられ且つ扱われるように、これらのタイプを指定し、それらインスタンスを構築することができる。例えば、コンピュータソフトウエアーを、マイメッセージのインスタンスを構築するために用いることができる。その後、プログラムは、その設定を確立し、そのデータを指定すること等によりマイメッセージのインスタンスを扱うことができる。その後、扱われたマイメッセージのインスタンスを、ワード及びフィールドにより定義された特定の転送を行なうために、送信又は受信することができる。

メッセージタイプは、構成ワードタイプ及びフィールドタイプを定義に含む階層構造であるため、「メッセージインスタンス」が、メッセージのインスタンス自身のみを含むだけではなく、それらの構成ワードタイプ及びフィールドタイプのインスタンスを含むことは明らかである。好ましい実施態様において、バステスト装置は、ユーザがメッセージインスタンスを構築することができるソフトウエアAPI（アプリケーションプログラムインターフェイス）を有する。各メッセージインスタンスは、ソフトウエア「ハンドル」を備え、メモリー内に持続される。ＡＰＩは、そのハンドルを介してメッセージインスタンスにアクセスすることができ、そのデータを扱い又はメッセージインスタンスを実行する。

好ましくは、ユーザは、ファンクションコールを用いてＡＰＩと通信する。好ましい実施態様においては、バステスト装置はＶＸＩ装置であり、ＡＰＩは、ＶＸＩプラグ・アンド・プレイドライバーにより実行される。

２つのタイプのメッセージインスタンス、送信メッセージインスタンス及び予想メッセージインスタンスを、メッセージタイプのために構築することができる。送信メッセージインスタンスは、バスに情報を送るために用いられる。予想メッセージインスタンスは、バスの情報を受信するために用いられる。予想メッセージインスタンスは、また、バス又は他の通信媒体に現れる情報のブロック構造を形成する点において、送信メッセージインスタンスと同様である。しかしながら、送信メッセージインスタンスは、送信されるデータの提供をユーザに要求する一方、予想メッセージインスタンスは、ユーザが、データ自身ではなく、予想されたデータの構造（例えば、ワードタイプ及びタイミング）のみを指定することを要求する。しかしながら、テストの目的のために、予想メッセージインスタンスのために予想データ、即ち、バスで予想されたデータを指定することもできる。予想された結果が得られたかを決定するために、予想データを実際に受信されたデータと比較することもできる。

送信及び予想メッセージインスタンスでは、ユーザがメッセージのタイミングをコントロールすることが望ましい。好ましくは、バスモデルで検出されたメッセージタイプの定義は、デフォルトタイミング値を含む。メッセージインスタンスは、これらのデフォルトを用いることができ又は代えることができる。好ましい実施態様では、ユーザは、メッセージタイプ又はメッセージインスタンスの次のタイミング特徴を指定することができる。

メッセージインスタンスを送信することができる前に実施される遅延は、プレメッセージギャップとみなされる。プレメッセージギャップ定義は、最後の送信ワードの終わり、最後の受信ワードの終わり、 又は、システムの別のイベントを含む遅延が実施される時点からの仕様を含む。

送信されるメッセージのワード間で実施される遅延は、プレワードギャップとみなされる。

予想メッセージの初期を受信するタイムアウトは、初期メッセージタイムアウトとしてみなされる。プレメッセージギャップと同様に、この仕様は、この時間の期間が始まる時点の柔軟な定義を含む。

予想メッセージのワードを受信するためのタイムアウトは、ワードギャップタイムアウトとしてみなされる。

メッセージが適切に終了したことを保証するために、予想メッセージに続くためにチェックするための期間は、トレーリングギャップとしてみなされる。

全体のバスプロトコルの共通のタイミングのデフォルト、即ち、多数のメッセージタイプに影響するデフォルトを同様に設けることができる。このようなデフォルトは、インターメッセージギャップ、インターワードギャップ、リスポンスタイム、ノーリスポンスタイムアウト、ノーワードリスポンスタイムアウト、ノーワードタイムアウト及びこれらの最小値及び最大値を含む。好ましくは、これらのデフォルトを、上述のメッセージタイミング設定のために用いることができる。

一つの実施態様について説明したが、多数の別の実施態様又は変形を行なうことができる。例えば、上述のように、メッセージタイプ、ワードタイプ及びフィールドタイプについて述べたが、通信プロトコルの別のレイヤーを示すために、他の通信要素タイプを用いることもできる。例えば、メッセージタイプのグループを含む「トランザクションタイプ」を実行することができる。従って、本発明は、上述の３つの通信要素タイプに限定されるものではない。

更に、いくつかの通信プロトコルは、バスモデルの全ての層を規定しない。例えば、RS−２３２は、メッセージタイプを規定しない。しかしながら、プロトコルが支持する他の層のためのユーザ定義可能要素を支持することにより、本発明をこれらのバスに更に適応する。従って、一つのバスがここで開示された全ての通信要素タイプを支持しない場所に本発明を適応することは当然である。

「複数のバス」のコンセプトは、広い定義を有する。それでも尚、上述の説明からも明らかなように、ユーザ定義可能通信要素タイプを、正式に「バス」としてみなされるかに関わらず、通信媒体のいずれにも適応することができる。従って、本発明は、複数のバスに完全に限定されるものではない。

更に、ここでは、通信要素タイプは、ジェネリックバスモデルの特定の層に対応して説明されている。しかしながら、本発明は、開示された特別なバスモデルに用いることに限定されない。本発明は、むしろ、その形式に関わらず、一般的なものに適応することができ、通信のためのレイヤーモデルを表現することができる。

通信要素タイプの使用は、バス試験と関連して説明されたが、本発明が種々のコンテキストに適応され、特別な装置に用いられ又は一般的な装置に用いられることに限定されないことは明らかである。ユーザ定義可能通信要素タイプのコンセプトは、通信媒体のシュミレーション、エミュレーション又はテストに適応することができる。例えば、所望のバスのプロトコルを予測することができる一般的なI/O回路を介してバスの通信に用いることができる。また、単に、バス構造及び性質を示し又は述べるために用いることもできる。

従って、本発明は、好ましい実施態様を参照し特別に示され記載されたが、本発明の精神及び範囲から逸脱しない限り、本発明に様々な変形が当業者によりなされることは当然である。

本特許出願は、２００２年８月１日に出願された仮特許出願番号６０/４００１４０の優先権を主張する。

３００ バスモデル
３１０ ユーザ定義バスモデル
３１２ ユーザ定義ワードタイプ
３１４ ユーザ定義フィールドタイプ
３１６ メッセージタイプN
３１８ メッセージタイプC

Claims (34)

1. プロトコルを有する通信メディアに動作可能に接続された装置のテスト方法において、
   前記プロトコルは、シリアルバスの仕様を示すバスモデルの一般的な層構造に適しており、
   それぞれが前記プロトコルの特定層に関するユーザ定義のインスタンス化可能なソフトウエアデータタイプであり、前記プロトコルの異なる通信要素を段階的に示す複数の通信要素タイプを設け、
   前記通信メディアにおいて前記装置に動作可能に接続する電子機器を設け、
   前記電子機器を制御するソフトウエアプログラムを設け、
   前記ソフトウエアプログラムにより、該ソフトウエアプログラム内で、前記各通信要素タイプの特定の表現であり前記装置に伝達されるべき送信メッセージインスタンスを作成するために、前記複数の通信要素タイプの１つをインスタンス化し、
   前記ソフトウエアプログラムにより、該ソフトウエアプログラム内で、前記各通信要素タイプの特定の表現である予想メッセージインスタンスを作成するために、前記複数の通信要素タイプの１つをインスタンス化し、
   前記ソフトウエアプログラム内で前記送信メッセージインスタンスを操作し、
   前記ソフトウエアプログラム内で前記予想メッセージインスタンスを操作し、
   前記ソフトウエアプログラムにより、前記操作された送信メッセージのインスタンスに応じて、前記電子機器にメッセージを前記装置に送信させ、前記操作された予想メッセージのインスタンスに応じて、前記電子機器にメッセージを前記装置から受信させ、
   予測結果が得られたか否かを判断するために、前記装置から受信した前記メッセージを予測結果と比較し、
   前記プロトコルの上位層に関係する少なくともいくつかの通信要素タイプは、前記プロトコルの下位層に関係する１以上の通信要素タイプに対するリファレンスを有し、
   前記複数のユーザ定義可能な通信要素タイプは、バスモデルを形成するために結合可能なメッセージタイプ、ワードタイプ、及びフィールドタイプを有し、
   少なくとも１つのメッセージタイプは、少なくとも１つのワードタイプに対するリファレンスを有し、
   少なくとも１つのワードタイプは、少なくとも１つのフィールドタイプに対するリファレンスを有することを特徴とする方法。
2. 前記複数の通信要素タイプを設ける工程は、前記各通信メディアの前記プロトコルにより許可された交換に応答して前記複数の通信要素タイプの１つ以上を規定することを特徴とする請求項１に記載の方法。
3. 前記複数の通信要素タイプの少なくとも１つは、前記通信メディアにデータを送信するための構造を規定することを特徴とする請求項１に記載の方法。
4. 前記複数の通信要素タイプの少なくとも１つは、前記通信メディアのデータを受信するための構造を規定することを特徴とする請求項１に記載の方法。
5. 前記複数の通信要素タイプの少なくとも１つは、前記各メッセージタイプのインスタンスに関連したメッセージデータを保持するための部分を有するメッセージタイプであることを特徴とする請求項１に記載の方法。
6. 前記メッセージデータは、固定長であることを特徴とする請求項５に記載の方法。
7. 前記メッセージデータは、可変長であることを特徴とする請求項５に記載の方法。
8. 前記複数の通信要素タイプの少なくとも１つは、該通信要素タイプの全てのインスタンスに同等の固定部分を有することを特徴とする請求項１に記載の方法。
9. 前記複数の通信要素タイプは、少なくとも１つのメッセージタイプを有し、前記メッセージタイプの各インスタンスは、タイミングを定義する部分を有することを特徴とする請求項１に記載の方法。
10. 前記タイミングは、プレメッセージギャップを指定するための設定を有することを特徴とする請求項９に記載の方法。
11. 前記タイミングは、プレワードギャップを指定するための設定を有することを特徴とする請求項９に記載の方法。
12. 前記タイミングは、初期メッセージタイムアウトを指定するための設定を有することを特徴とする請求項９に記載の方法。
13. 前記タイミングは、トレーリングギャップを指定するための設定を有することを特徴とする請求項９に記載の方法。
14. 前記送信メッセージインスタンスを操作する工程は、前記ソフトウエアプログラムによって、前記送信メッセージインスタンスの少なくとも一つの特徴を構築することを特徴とする請求項１に記載の方法。
15. 前記少なくとも１つの特徴は、タイミング特徴を有することを特徴とする請求項１４に記載の方法。
16. 前記複数の通信要素タイプをコンピュータ読み取り可能フォーマットで保存することを特徴とする請求項１に記載の方法。
17. 前記複数の通信要素タイプの一つのマルチプルインタンスを作成することを特徴とする請求項１に記載の方法。
18. 前記通信メディア上の情報を交換するために、前記各マルチプルインスタンスを処理することを特徴とする請求項１７に記載の方法。
19. 前記ソフトウエアプログラムにおける前記複数の通信要素タイプの１つのマルチプルインスタンスを作成することを特徴とする請求項１４に記載の方法。
20. 前記ソフトウエアプログラムにおいて作成された前記マルチプルインスタンスのそれぞれの特徴を、異なる方法で変えることを特徴とする請求項１９に記載の方法。
21. プロトコルを有する通信メディアの通信方法において、
    それぞれが前記プロトコルの特定の層に関するユーザ定義のデータ構造であり、バスモデルを形成するため結合可能なメッセージタイプ、ワードタイプ、及びフィールドタイプを有し、且つ前記プロトコルの異なる通信要素を示す複数の通信要素タイプを設け、
    前記通信メディアと通信するために該通信メディアに動作可能に接続された電子機器を設け、
    該電子機器を制御するソフトウエアプログラムを設け、
    前記プロトコルの上位層に関する少なくとも一つの通信要素タイプが、前記プロトコルの下位層に関する少なくとも１つの通信要素タイプに対するリファレンスを有する前記複数の通信要素タイプを段階的に配置し、
    前記ソフトウエアプログラムにより、少なくとも１つの通信要素のインスタンスを作成し、且つプロトコルを有する通信メディアに動作可能に接続された装置に伝達されるべき伝達メッセージのインスタンスを形成するために、前記複数の通信要素タイプの少なくとも１つをインスタンス化し、
    前記各通信要素インスタンスに応じて前記通信メディアでの通信に対する前記電子機器を制御する前記ソフトウエアプログラムを作動することを特徴とする通信方法。
22. メッセージ及びワードの使用をサポートするプロトコルを有する通信メディアでの通信方法において、
    それぞれがソフトウエアに示されたユーザ定義可能なデータタイプであり、前記プロトコルを利用した通信を示し複数のメッセージタイプ及び複数のワードタイプを有する複数の通信要素タイプを設け、
    前記通信メディアでの通信のために該通信メディアに動作可能に接続する電子機器を設け、
    該電子機器を制御するソフトウエアプログラムを設け、
    少なくとも１つのメッセージタイプが少なくとも１つのワードタイプに対するリファレンスを有する前記複数のメッセージタイプ及び前記複数のワードタイプを段階的に配置し、
    それぞれが前記各メッセージタイプの特定の表現であり、前記各メッセージタイプに含まれる各ワードタイプのインスタンスを有し、該ワードタイプのインスタンスのそれぞれがプロトコルを有する通信メディアに動作可能に接続された装置に伝達されるべき伝達メッセージであり且つ前記各ワードタイプのそれぞれの特定の表現である少なくとも１つのメッセージのインスタンスを作成するために、前記ソフトウエアプログラムにより前記複数の通信要素タイプの少なくとも１つのメッセージタイプをインスタンス化し、
    該少なくとも一つのメッセージインスタンスに応じて、前記通信メディアでの通信に対する前記電子機器を制御するソフトウエアプログラムを作動することを特徴とする通信方法。
23. 送信メッセージインスタンスを作成するために、前記複数の通信要素タイプの一つをインスタンス化する前記工程は、ソフトウエアアプリケーションプログラムインターフェイス（ＡＰＩ）にアクセスする前記ソフトウエアプログラムを有することを特徴とする請求項１に記載の方法。
24. 送信メッセージインスタンスを作成するために、前記複数の通信要素タイプの一つをインスタンス化する前記工程は、ＶＸＩプラグアンドプレイドライバにアクセスする前記ソフトウエアプログラムを有することを特徴とする請求項１に記載の方法。
25. 多層プロトコルを有する通信メディアでの通信方法において、
    ソフトウエアプログラムを設け、
    該ソフトウエアプログラムによりアクセス可能であり、前記プロトコルの第１層のための異なる通信要素を示しユーザにより定義可能な複数の第１通信要素タイプを規定し、
    前記ソフトウエアプログラムによりアクセス可能であり、前記第１層よりも低い前記プロトコルの第２層のための異なる通信要素を示しユーザにより定義可能であり且つ結合可能な複数の第２通信要素タイプを規定し、
    前記複数の第１通信要素タイプの少なくとも１つの規定内で、前記複数の第２通信要素タイプの少なくとも１つに対するリファレンスを有し、
    プロトコルを有する通信メディアに動作可能に接続された装置に伝達されるべき伝達メッセージであり且つ前記ソフトウエア内の通信要素タイプであるインスタンスを作成するために、前記複数の第１通信要素タイプの１つにより参照された前記複数の第２通信要素タイプのそれぞれのインスタンスを有し、該各インスタンスが前記各通信要素タイプの特定の表現である前記複数の第１通信要素タイプの１つをインスタンス化し、
    前記ソフトウエアプログラム内で前記通信要素のインスタンスの少なくとも１つを操作し、
    前記操作された通信要素のインスタンスに応じて、前記通信メディアと通信する前記ソフトウエアプログラムを実行することを特徴とする通信方法。
26. 前記プロトコルの前記第１層は、メッセージに関し、前記プロトコルの前記第２層は、ワードに関することを特徴とする請求項２５に記載の通信方法。
27. 前記ソフトウエアプログラムによりアクセス可能であり、前記第２層よりも低い前記プロトコルの第３層に異なる通信要素を示す複数の第３通信要素タイプを規定し、
    前記複数の第２通信要素タイプの少なくとも１つの規定内で、前記複数の第３通信要素タイプの少なくとも１つに対するリファレンスを有することを特徴とする請求項２５に記載の通信方法。
28. 前記プロトコルの前記第１層は、メッセージに関し、前記プロトコルの前記第２層は、ワードに関し、前記プロトコルの前記第３層は、フィールドに関することを特徴とする請求項２７に記載の通信方法。
29. 前記複数の第１及び第２通信要素タイプは、コンピュータ読み取り可能ファイルに記憶されていることを特徴とする請求項２５に記載の方法。
30. 前記複数の第１及び第２通信要素タイプは、ＸＭＬコードにより実行されることを特徴とする請求項２５に記載の方法。
31. 多層プロトコルを有する通信メディアとの通信を行うコンピュータ実行システムにおいて、
    前記通信メディアに接続された電子機器を制御するソフトウエアプログラムと、
    該ソフトウエアプログラムによりアクセス可能であり、前記プロトコルの第１層に異なる通信要素を示すユーザにより定義可能な複数の第１通信要素タイプと、前記プロトコルの前記第１層よりも低い第２層に異なる通信要素を示すユーザにより定義可能な複数の第２通信要素タイプとを有するバスモデルファイルと、
    前記ソフトウエアプログラムによりアクセス可能であり、前記複数の第１及び第２通信要素タイプに基づき通信要素のインスタンスを作成するソフトウエアＡＰＩ（アプリケーションプログラムインターフェイス）とを備え、
    前記複数の第１及び第２通信要素タイプのそれぞれは、プロトコルを有する通信メディアに動作可能に接続された装置に伝達されるべき伝達メッセージであるインスタンスを形成するためインスタン化可能なソフトウエアデータタイプであり、
    前記複数の第１通信要素タイプの少なくとも１つは、前記複数の第２通信要素タイプの少なくとも１つに対するリファレンスを有し、
    前記通信要素のインスタンスは、前記ソフトウエアプログラム内で、前記複数の第１通信要素タイプの１つの特別な表現である少なくとも１つの第１通信要素インスタンスと、
    前記ソフトウエアプログラム内で、第一通信要素タイプのそれぞれにより含まれた前記複数の第２通信要素タイプの特別な表現である少なくとも１つの第２通信要素のインスタンスとを備えることを特徴とするシステム。
32. 前記複数の第１及び第２の通信要素タイプは、ネスト化されたソフトウエアタグを用いて実行されることを特徴とする請求項３１に記載のシステム。
33. 前記バスモデルファイルは、ＸＭＬファイルであることを特徴とする請求項３２に記載のシステム。
34. 前記バスモデルファイルは、前記ソフトウエアプログラムによりアクセス可能であり、前記第２層よりも低い前記プロトコルの第３層に異なる通信要素を示す複数の第３通信要素タイプを有し、前記複数の第２通信要素タイプの少なくとも１つは、前記複数の第３要素タイプに対するリファレンスを有することを特徴とする請求項３１に記載のシステム。