(57)【要約】【課題】  通信構造を柔軟に形成する方法を提供すること。【解決手段】  通信構造を柔軟に形成する方法は、少なくとも一つの一般化された通信モデルに、少なくとも一つの通信要素タイプをバスモデルとして設ける。各通信要素タイプは、ターゲット通信媒体の対応するプロトコル層を示すために適応可能なユーザ定義可能構造を有する。ユーザは、特定のターゲットプロトコルを実質的に示すために特定の通信要素タイプを定義することができる。また、ユーザは、正確な方法で定義されたターゲットプロトコルから外れるために通信要素タイプを定義することができる。
2006516834.tif 000002
【特許請求の範囲】
【請求項１】
複数の異なるターゲットメディアにわたる通信方法において、
該方法は、複数の異なるターゲットバスのそれぞれに、それぞれがターゲット通信メディアの特定のプロトコル層を示すように構成された複数の通信要素タイプを設けることを特徴とする通信方法。
【請求項２】
前記各通信要素タイプのインスタンスを、前記各ターゲットメディアのデータを交換するために構築可能であることを特徴とする請求項１に記載の通信方法。
【請求項３】
前記各ターゲットメディアのプロトコルにより許可された交換に応答して前記複数の通信要素タイプを形成することを特徴とする請求項１に記載の通信方法。
【請求項４】
前記複数の通信要素タイプの少なくとも一つのインスタンスを構築し、前記各ターゲットメディアの情報を交換するために前記通信要素タイプのインスタンスを処理することを特徴とする請求項1に記載の通信方法。
【請求項５】
前記通信要素タイプは、前記ターゲットメディアにデータを送信するために構造を形成することを特徴とする請求項１に記載の通信方法。
【請求項６】
前記通信要素タイプは、前記ターゲットメディアのデータを受信するために構造を形成することを特徴とする請求項１に記載の通信方法。
【請求項７】
少なくとも一つの通信要素タイプは、前記各メッセージタイプのインスタンスに関連したメッセージデータを保持するための部分を有するメッセージタイプであることを特徴とする請求項１に記載の通信方法。
【請求項８】
前記メッセージデータは、固定長であることを特徴とする請求項７に記載の通信方法。
【請求項９】
前記メッセージデータは、可変長であることを特徴とする請求項７に記載の通信方法。
【請求項１０】
前記通信要素タイプは、該通信要素タイプの全てのインスタンスに同等の固定部分を有することを特徴とする請求項９に記載の通信方法。
【請求項１１】
前記通信要素タイプを、他の通信要素タイプに関して定義可能であることを特徴とする請求項１に記載の通信方法。
【請求項１２】
前記複数の通信要素タイプは、少なくとも一つのメッセージタイプを有し、前記メッセージタイプの各インスタンスは、タイミングを定義する部分を有することを特徴とする請求項１に記載の通信方法。
【請求項１３】
前記タイミングは、プレメッセージギャップを指定するための設定を有することを特徴とする請求項１２に記載の通信方法。
【請求項１４】
前記タイミングは、プレワードギャップを指定するための設定を有することを特徴とする請求項１２に記載の通信方法。
【請求項１５】
前記タイミングは、初期メッセージタイムアウトを指定するための設定を有することを特徴とする請求項１２に記載の通信方法。
【請求項１６】
前記タイミングは、トレーリングギャップを指定するための設定を有することを特徴とする請求項１２に記載の通信方法。
【請求項１７】
周知のプロトコルを有する通信メディアの通信の構築方法において、
該構築方法は、少なくとも一つの一般化された通信モデルの層に、少なくとも一つのユーザ定義可能通信要素タイプを設け、
ユーザ定義可能構造を有する各通信要素タイプは、対応する前記プロトコルの層を示すために適応可能であることを特徴とする構築方法。
【請求項１８】
前記通信要素タイプの特定のインスタンスを、前記メディアのトランザクションを示すために構築可能であることを特徴とする請求項１７に記載の構築方法。
【請求項１９】
プロトコルを有する通信メディアとのインターフェイスの構築方法において、
少なくとも一つの一般化された通信モデルの層に、少なくとも一つのユーザ定義可能通信要素タイプを構築し、
前記一般化された通信モデルの前記各層で前記メディアの前記プロトコルを実質的に示すために、少なくとも一つのユーザ定義可能通信要素タイプを構造化し、  
前記少なくとも一つのユーザ定義可能通信要素タイプを、前記メディアで通信するためにアクセス可能なコンピュータ読み取り可能フォーマットに保存することを特徴とする構築方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概述すると、電子通信に関し、更に詳細に述べると、通信プロトコルを示し且つ操作するためのデータ構造に関する。
【背景技術】
【０００２】
近年、ユニバーサルバステスト装置が、異なるインターフェイスの仕様及びプロトコルで作動する種々のシリアルバスを制御するために開発されてきた。米国特許出願番号10/325,070「種々のシリアルバスタイプのシミュレーション、エミュレーション及びテストのユニバーサルアプローチ」は、この装置の特徴について記載しており、本願に参考のために組み込まれている。組み込まれた出願及び本出願の両出願は、同日に出願された仮出願に基づいている。一方の出願は、他方に対する従来技術ではない。
【０００３】
組み込まれた特許出願は、「バスモデル」の使用を通じてジェネリックシリアルバスのプロトコル及び性質を定義している。上述のように、バスモデルは、シリアルバスプロトコルを、全てのバスに共通な個々のジェネリック層に分解する。特定のターゲットバスでは、バスモデルは、ジェネリック層に関してターゲットバスプロトコルを示し、各ジェネリック層にバス特有属性を割り当てる。従って、バスモデルは、ジェネリック層に関してターゲットバスプロトコルの抽象的な表現を形成する。
【０００４】
図１は、バスモデル１００のブロック図を示す。バスモデルの層は、例えば、フレーム１１２、１３２、メッセージ１１４、１３４、ワード１１６、１３６、フィールド１１８、１３８、シンボル１２０、１４０、シーケンス１２２、１４２、エンコード１２４、１４４及びタイミング１２６、１４６を備える。
【０００５】
従来のバステスト装置は、主にバス特有のものである。バステスト装置は、一つ以上の特定のタイプのバスを制御するために設計されているが、他のタイプのバスを制御するために用いることはできない。従って、これらの装置に含まれ用いられる通信構造は、特に支持されたバスとの通信に必要な構造のみである。それらは、他のタイプのバスに適応することができない。
【０００６】
図２は、従来技術のバス特有テスト装置により使用された典型的な通信構造を示す。説明のために、MIL-STD-１５５３バステスト装置の通信構造を示す。この装置は、一組のバス特有メッセージタイプ２１０を支持する。メッセージタイプ２１０は、ターゲットバスで行なうことができる高レベルな操作を規定する。１５５３バスでは、これらのメッセージタイプは、特に、バスコントローラからリモートターミナルへのメッセージタイプ（BC−RT）、リモートターミナルからバスコントローラへのメッセージタイプ（RT−BC）及びリモートターミナルからリモートターミナルへのメッセージタイプ（RT−RT）を含む。
【０００７】
各メッセージタイプ２１０は、ワードからなる。一般的に、ターゲットバスの仕様は、種々のバス操作を行なうための一組のワードタイプを形成する。バス１５５３では、コマンドワード、データワード及びステータスワードの３つの異なるワードタイプ２１２が設けられている。
【０００８】
ワードは、フィールドからなる。ワード内のフィールドの識別及び配置は、ターゲットバスの規定により定められている。図２に示すように、１５５３コマンドワード２１６は、６フィールド２１４からなる。これらのフィールドは、１５５３規格により規定されたように、同期（Sync）、RTアドレス、送信/受信、サブアドレスモード、データワードカウント/モードカウント及びパリティを備える。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
従来技術のバス特有構造のそれぞれは、特定のターゲットバスを制御するために必要なメッセージタイプ及びワードタイプを支持する。しかしながら、一般的に、バス特有構造は、それぞれのターゲットバスのプロトコルに限定されている。バス特有構造は、ユーザが、異なるタイプのバスに異なるメッセージタイプやワードタイプを定義する方法を提供しない。従って、バス通信を定義するより柔軟な方法が必要とされる。
【００１０】
上述の背景をふまえ、本発明の目的は、ユーザが、ターゲットバス又は他の通信媒体とやり取りするための通信構造を柔軟に形成することができるようにすることである。
【課題を解決するための手段】
【００１１】
上述の目的を達成するために、他の目的及び効果と同様に、通信構造を柔軟に形成する方法は、バスモデルとして、一般化された通信モデルの少なくとも一つの層に、少なくとも一つの通信要素タイプを提供する。各通信要素タイプは、ターゲット通信媒体の対応するプロトコル層を示すために適応可能なユーザ定義可能構造を有する。ユーザは、ターゲットプロトコルを実質的に示すために特定の通信要素タイプを定義することができる。また、ユーザは、正確な方法で定義されたターゲットプロトコルから外れるために通信要素タイプを定義することができる。
【発明を実施するための最良の形態】
【００１２】
本発明の別の目的、効果及び新規な特徴は、以下に続く詳細な説明及び図面により明らかとなる。
【実施例】
【００１３】
本発明によるジェネリック通信構造は、ユーザが、ユーザの選択する通信要素タイプを定義することにより、従来技術のバス特有構造から逸脱する。通信要素タイプは、バスモデルの異なる層を示す。これらの通信要素タイプは、例えば、メッセージタイプ、ワードタイプ及びフィールドタイプを含む。バスモデルの他の層を示すために、他の通信要素タイプを構築することもできる。ユーザは、これらの通信要素タイプを既存のバス又は次のバスのために定義することができる。
【００１４】
図３は、本発明によるジェネリック通信構造の実施態様を示す。従来技術のように、図３の構造は、メッセージタイプ（例えば、メッセージタイプ３１０）、ワードタイプ（例えば、ワードタイプ３１２）及びフィールドタイプ（例えば、フィールドタイプ３１４）を備える。各メッセージタイプは、少なくとも一つのワードタイプを備え、各ワードタイプは、少なくとも一つのフィールドタイプを備える。
【００１５】
しかしながら、図３の構造は、柔軟性において従来技術とは明らかに異なる。この柔軟性の達成に特に重要なものは、バスモデル３００である。上述のように、バスモデルは、あらゆるシリアルバスの仕様を示すためのジェネリック層構造である。異なるバスタイプと通信するために、異なるインスタンスのバスモデルを構築することができる。各バスモデルのインスタンスは、特定のタイプのバスに調整された通信要素タイプを定義する。
【００１６】
バスモデル３００又はそのインスタンスは、一組のメッセージタイプ３１０を備える。従来技術の定義されたメッセージタイプとは異なり、メッセージタイプ３１０は、ユーザ定義可能構造を有する。各メッセージタイプでは、ユーザは、ターゲットバスにわたるいくつかの重要な通信を構築するワードタイプの順序グループ及び名前を定義することができる。例えば、ユーザは、ワードタイプA、B及びCからなるメッセージタイプN３１６を構築することができる。ワードタイプA、B及びCを、バスモデルに定義されたワードタイプ（１からM）のいずれかにすることができ、ワードタイプA、B及びCのシーケンスは、いくつかの有益な機能を実行する。ユーザは、所望の数のメッセージタイプを定義することができる。
【００１７】
バスのメッセージタイプは、典型的には、バスのプロトコルにより規定されたメッセージ、即ち、バスタイプのスタンダードメッセージタイプに対応することができる。しかしながら、メッセージタイプは、広範囲のアプリケーションを有することができる。ユーザは、特定のテストシナリオを扱うために、カスタムメッセージタイプを構築することができる。従って、一般的には、メッセージタイプは、ターゲットバスのプロトコルに一致しているが、そのプロトコルが規定する特定のメッセージに限定される必要はない。
【００１８】
また、ユーザ定義メッセージタイプを、ターゲットバスのプロトコルに規定されたメッセージタイプとは異なって構築することができる。例えば、プロトコルは、シンプル又は異なるメッセージのシーケンスとしてバスモデルに表示されやすいコンプレックスメッセージを定義することができる。従って、バスプロトコルで定義されたメッセージとバスモデルで求められたメッセージとの間に直接一対一の関係は必要ない。
【００１９】
バスモデル３００は、一組のユーザ定義ワードタイプ３１２を備える。各ワードタイプは、フィールドタイプのグループ及び名前により定義される。例えば、ワードタイプC（メッセージタイプNの一部）を、フィールドタイプA、B、C及びDを含むように定義することができる。ユーザは、所望の数のワードタイプを定義することができる。
【００２０】
また、フィールドタイプは、バスモデル３００に含まれている。フィールドタイプは、メッセージタイプ又はワードタイプよりもバス通信のより具体的な面を定義する。本発明者達は、限定された数の目的にのみにフィールドタイプが用いられることを発見した。簡略化のために、ユーザにフィールドタイプの特徴を定義する無限の柔軟性を提供する必要はない。代わりに、ユーザは、フィールド指定を割り当てることよりフィールドタイプの特徴を定義する。好ましい実施態様では、ユーザは、それぞれのフィールドタイプに次のフィールド指定のうちの一つを設定することができる。
【００２１】
【表１】
2006516834.tif 000003
【００２２】
テーブル１から明らかなように、いくつかのフィールドタイプは、コンスタントデータのように指定された固定値を有し、同様に、他のフィールドタイプは、パリティ又はCRCのように指定された変数値を有する。好ましくは、固定フィールドの特定の値は、それぞれのバスモデルで指定される（以下のテーブル2で設定する「値」参照。）。
【００２３】
フィールドタイプ、ワードタイプ及びメッセージタイプは、本質的に、より高いレベルの構造を構築するために結合させることができる明確な構造を形成する。例えば、異なるワードタイプを構築するために、同一のフィールドタイプを異なるコンビネーションで用いることができ、異なるメッセージタイプを構築するために、同一のワードタイプを異なるコンビネーションで用いることができる。より高いレベル構造（例えば、１５５３コマンド・リスポンストランザクションのようなトランザクション）を形成するために、メッセージタイプさえも結合させることができる。
【００２４】
通信要素タイプの定義は、多くの方法で行なうことができる。例えば、単一のコンピュータファイル、異なるコンピュータファイル、ハードウエアー又はこれらのいずれかのコンビネーションにより行なうことができる。好ましい実施態様において、通信要素タイプは、XMLフォーマットのバスファイルの形式に設けられている。バスファイルは、「タグ」により通信要素タイプを同定する。例えば、異なるタグは、各フィールドタイプ、各ワードタイプ及び各メッセージタイプに用いられる。以下のコードセクションは、バスファイルのフィールドタイプ定義の一般化された例である。
【００２５】
〈フィ―ルド[フィールド属性]  〉
〈フィールド名  ＝  「フィールド１」  [フィールドタイプ設定]／〉
〈フィールド名  ＝  「フィールド２」  [フィールドタイプ設定]／〉
…
〈フィールド名  ＝  「フィールドL」  [フィールドタイプ設定]／〉
〈／フィールド〉
【００２６】
バスファイル内で、ワードタイプは、また、XMLタグを用いて示される。好ましくは、バスファイルは、次のフォーマットを用いるワードタイプを定義する。
【００２７】
〈ワード[ワード属性]〉
〈ワード名  ＝「ワード１」／〉
〈ワード名  ＝「ワード２」／〉
…
〈ワード名  ＝「ワードM」／〉
〈／ワード〉
【００２８】
各ワードタイプは、フィールドタイプのグループからなる。周知のように、XMLは、タグの階層的配列を支持し、特定のタグを他のタグの下位とすることができる。これにより、下位のタグを、特定のワードタイプに「属する」フィールドタイプを示すために用いることができる。例えば、以下の通り、バスファイルは、ユーザ定義ワードタイプ「ユーザワード」を構築するフィールドタイプを示すことができる。
【００２９】
〈ワード名  ＝  「ユーザワード」〉
〈ワードフィールド  フィールド名  ＝「フィールドタイプA」／〉
〈ワードフィールド  フィールド名  ＝「フィールドタイプB」／〉
〈ワードフィールド  フィールド名  ＝「フィールドタイプC」／〉
〈／ワード〉
【００３０】
フィールドタイプA、B及びCは、「ユーザワード」ワードタイプを構築するフィールドタイプであり、好ましくは、バスファイルのどこかに定義される。
【００３１】
また、バスファイルは、メッセージタイプを示すタグを用いる。メッセージタイプを以下の通り示すことができる。
【００３２】
〈メッセージ〉
〈メッセージ名  ＝  「メッセージタイプ１」  [メッセージタイプ設定]／〉
〈メッセージ名  ＝  「メッセージタイプ２」  [メッセージタイプ設定]／〉
…
〈メッセージ名  ＝  「メッセージタイプN」  [メッセージタイプ設定]／〉
〈／メッセージ〉
【００３３】
下位のタグを、メッセージタイプを構築するワードタイプを定義するために使用することができる。例えば、「マイメッセージ」を構築するワードタイプを以下の通り定義することができる。
【００３４】
〈メッセージ名  ＝  「マイメッセージ」  [メッセージタイプ設定]  〉
〈メッセージワード  ワード名  ＝  「ワードタイプA」  〉
〈メッセージワード  ワード名  ＝  「ワードタイプB」  〉
〈メッセージワード  ワード名  ＝  「ワードタイプC」  〉
〈／メッセージ〉
【００３５】
ワードタイプA、B及びCは、「マイメッセージ」を構築する特定のワードであり、好ましくは、バスファイルのどこかに定義される。
【００３６】
メッセージタイプ、ワードタイプ及びフィールドタイプのそれぞれは、バスの特徴及び性質をさらに定義するための設定を提供することができる。XMLは、ユーザにタグの属性を指定させることができる。データタイプの設定を定義するために、バスファイルは、これらのタグの属性を利用する。
【００３７】
メッセージタイプは、「可変長」設定を提供し、該設定は、メッセージが固定数のワードからなるか可変数のワードからなるかを、ユーザに指定させることができる。また、可変長メッセージでは、最長及び最短設定が設けられている。また、ワードタイプ及びフィールドタイプは、可変長設定を提供することができる。
【００３８】
ユーザは、フィールドタイプに種々の設定を定義することができる。次の設定は、好ましい実施態様において提供される。
【００３９】
【表２】
2006516834.tif 000004
【００４０】
メッセージタイプ、ワードタイプ及びフィールドタイプを定義するための通信要素タイプの使用は、ユーザにバス通信を構築する点において多大な柔軟性を提供する。 ユーザは、バスのフィールドを定義することができ、特定のフィールドからワードを構築し、特定のワードからメッセージを構築することができる。
【００４１】
この柔軟性により、テストの品質を向上させるための多くの機会が生じる。例えば、ユーザは、バス装置のテストにおいて、故障インジェクションを行なう広い能力を有する。ユーザは、バスのプロトコル又は仕様を意図的に乱す方法でフィールドタイプ、ワードタイプ及びメッセージタイプを定義することができる。テスト目的のために、フィールドを多数のビット又は少数のビットを備えるものとして定義することができる。ワードを多数のフィールド又は少数のフィールドを備えるものとして、又は、フィールドをワード内の不適切な位置に備えることにより、ワードを規定することができる。この柔軟性により、メッセージ、ワード及びフィールドのユーザ定義構造では、装置の反応を観察するために、制御された方法で、バスプロトコルから外れる大きな可能性がある。
【００４２】
また、この柔軟性により、ユーザはカスタムバスを含む新しいタイプのバスの新しいバスモデルを構築することができる。図４は、新しいバスモデルを構築するための工程を示す。ステップ４１０にて、ユーザは、ターゲットバスの仕様を調べる。ステップ４１２から４１６にて、ユーザは、支持される特定のフィールドタイプ、ワードタイプ及びメッセージタイプを、ターゲットバスの仕様及び使用者の特別なテストの必要性に応じて決定する。ステップ４１８にて、ユーザは、ターゲットバスのためにバスファイルの所望のフィールドタイプ、ワードタイプ及びメッセージタイプのための定義を構築する。その後、ユーザは、装置とやり取りするためにアクセスすることができる場所にバスファイルを保存する（ステップ４１８）。
【００４３】
一般的に、ユーザは、必要がある度にスクラッチから新しいバスファイルを構築する必要はない。異なるバスは、多数の同様の特徴を共有する。バスファイル（即ち、XMLファイル）の簡略化のために、既存のものをコピーし、少数の設定を変更することにより、ユーザは、しばしば簡単に新しいバスファイルを構築することができる。
【００４４】
ここで記載されているデータタイプ、即ち、メッセージタイプ、ワードタイプ及びファイルタイプは、基本的には、バスファイル内での定義として存在する。「インスタンス」の概念を通じて物理的なバスを実際に制御するために、これらの定義を実行することができる。周知のとおり、インスタンスは、特別なタイプの特定の表現である。従って、「メッセージインスタンス」は、メッセージタイプの特定の表現である。同様に、「ワードインスタンス」は、ワードタイプの特定の表現であり、「フィールドインスタンス」は、フィールドタイプの特定の表現である。これらのインスタンスを、より一般的に「通信要素インスタンス」としてみなすことができる。
【００４５】
特定のコンピュータ言語に設けられたユーザ定義データタイプ及びバスファイルの通信要素タイプを比較することができる。例えば、「C」コンピュータ言語は、特定のデータタイプを構築するための指示 「typedef」を提供する。データタイプのインスタンスを、そのタイプの変化を示すことによりコンピュータプログラムで構築することができる。その後、コンピュータプログラムは、ランタイムでそのタイプのインスタンスにアクセスすることができそのインスタンスを扱うことができる。 
【００４６】
バスファイルの通信要素タイプは、同様の方法で機能する。ユーザは、プログラムのコンテキストで用いられ且つ扱われるように、これらのタイプを指定し、それらインスタンスを構築することができる。例えば、コンピュータソフトウエアーを、マイメッセージのインスタンスを構築するために用いることができる。その後、プログラムは、その設定を確立し、そのデータを指定すること等によりマイメッセージのインスタンスを扱うことができる。その後、扱われたマイメッセージのインスタンスを、ワード及びフィールドにより定義された特定の転送を行なうために、送信又は受信することができる。
【００４７】
メッセージタイプは、構成ワードタイプ及びフィールドタイプを定義に含む階層構造であるため、「メッセージインスタンス」が、メッセージのインスタンス自身のみを含むだけではなく、それらの構成ワードタイプ及びフィールドタイプのインスタンスを含むことは明らかである。好ましい実施態様において、バステスト装置は、ユーザがメッセージインスタンスを構築することができるソフトウエアAPI（アプリケーションプログラムインターフェイス）を有する。各メッセージインスタンスは、ソフトウエア「ハンドル」を備え、メモリー内に持続される。APIは、そのハンドルを介してメッセージインスタンスにアクセスすることができ、そのデータを扱い又はメッセージインスタンスを実行する。
【００４８】
好ましくは、ユーザは、ファンクションコールを用いてAPIと通信する。好ましい実施態様においては、バステスト装置はVXI装置であり、APIは、VXIプラグ・アンド・プレイドライバーにより実行される。
【００４９】
２つのタイプのメッセージインスタンス、送信メッセージインスタンス及び予想メッセージインスタンスを、メッセージタイプのために構築することができる。送信メッセージインスタンスは、バスに情報を送るために用いられる。予想メッセージインスタンスは、バスの情報を受信するために用いられる。予想メッセージインスタンスは、また、バス又は他の通信媒体に現れる情報のブロック構造を形成する点において、送信メッセージインスタンスと同様である。しかしながら、送信メッセージインスタンスは、送信されるデータの提供をユーザに要求する一方、予想メッセージインスタンスは、ユーザが、データ自身ではなく、予想されたデータの構造（例えば、ワードタイプ及びタイミング）のみを指定することを要求する。しかしながら、テストの目的のために、予想メッセージインスタンスのために予想データ、即ち、バスで予想されたデータを指定することもできる。予想された結果が得られたかを決定するために、予想データを実際に受信されたデータと比較することもできる。
【００５０】
送信及び予想メッセージインスタンスでは、ユーザがメッセージのタイミングをコントロールすることが望ましい。好ましくは、バスモデルで検出されたメッセージタイプの定義は、デフォルトタイミング値を含む。メッセージインスタンスは、これらのデフォルトを用いることができ又は代えることができる。好ましい実施態様では、ユーザは、メッセージタイプ又はメッセージインスタンスの次のタイミング特徴を指定することができる。
【００５１】
メッセージインスタンスを送信することができる前に実施される遅延は、プレメッセージギャップとみなされる。プレメッセージギャップ定義は、最後の送信ワードの終わり、最後の受信ワードの終わり、 又は、システムの別のイベントを含む遅延が実施される時点からの仕様を含む。
【００５２】
送信されるメッセージのワード間で実施される遅延は、プレワードギャップとみなされる。  
【００５３】
予想メッセージの初期を受信するタイムアウトは、初期メッセージタイムアウトとしてみなされる。プレメッセージギャップと同様に、この仕様は、この時間の期間が始まる時点の柔軟な定義を含む。
【００５４】
予想メッセージのワードを受信するためのタイムアウトは、ワードギャップタイムアウトとしてみなされる。
【００５５】
メッセージが適切に終了したことを保証するために、予想メッセージに続くためにチェックするための期間は、トレーリングギャップとしてみなされる。
【００５６】
全体のバスプロトコルの共通のタイミングのデフォルト、即ち、多数のメッセージタイプに影響するデフォルトを同様に設けることができる。このようなデフォルトは、インターメッセージギャップ、インターワードギャップ、リスポンスタイム、ノーリスポンスタイムアウト、ノーワードリスポンスタイムアウト、ノーワードタイムアウト及びこれらの最小値及び最大値を含む。好ましくは、これらのデフォルトを、上述のメッセージタイミング設定のために用いることができる。
【００５７】
一つの実施態様について説明したが、多数の別の実施態様又は変形を行なうことができる。例えば、上述のように、メッセージタイプ、ワードタイプ及びフィールドタイプについて述べたが、通信プロトコルの別のレイヤーを示すために、他の通信要素タイプを用いることもできる。例えば、メッセージタイプのグループを含む「トランザクションタイプ 」を実行することができる。従って、本発明は、上述の３つの通信要素タイプに限定されるものではない。
【００５８】
更に、いくつかの通信プロトコルは、バスモデルの全ての層を規定しない。例えば、RS−２３２は、メッセージタイプを規定しない。しかしながら、プロトコルが支持する他の層のためのユーザ定義可能要素を支持することにより、本発明をこれらのバスに更に適応する。従って、一つのバスがここで開示された全ての通信要素タイプを支持しない場所に本発明を適応することは当然である。
【００５９】
「複数のバス」のコンセプトは、広い定義を有する。それでも尚、上述の説明からも明らかなように、ユーザ定義可能通信要素タイプを、正式に「バス」としてみなされるかに関わらず、通信媒体のいずれにも適応することができる。従って、本発明は、複数のバスに完全に限定されるものではない。
【００６０】
更に、ここでは、通信要素タイプは、ジェネリックバスモデルの特定の層に対応して説明されている。しかしながら、本発明は、開示された特別なバスモデルに用いることに限定されない。本発明は、むしろ、その形式に関わらず、一般的なものに適応することができ、通信のためのレイヤーモデルを表現することができる。
【００６１】
通信要素タイプの使用は、バス試験と関連して説明されたが、本発明が種々のコンテキストに適応され、特別な装置に用いられ又は一般的な装置に用いられることに限定されないことは明らかである。ユーザ定義可能通信要素タイプのコンセプトは、通信媒体のシュミレーション、エミュレーション又はテストに適応することができる。例えば、所望のバスのプロトコルを予測することができる一般的なI/O回路を介してバスの通信に用いることができる。また、単に、バス構造及び性質を示し又は述べるために用いることもできる。
【００６２】
従って、本発明は、好ましい実施態様を参照し特別に示され記載されたが、本発明の精神及び範囲から逸脱しない限り、本発明に様々な変形が当業者によりなされることは当然である。
【００６３】
本特許出願は、２００２年８月１日に出願された仮特許出願番号６０/４００１４０の優先権を主張する。
【図面の簡単な説明】
【００６４】
【図１】ジェネリックバスモデルの概念を示すブロック図である。
【図２】従来技術によるMIL-STD -1553バスの通信構造の部分を示す図である。
【図３】本発明による柔軟な通信構造の部分を示す図である。
【図４】バスモデル内のバス通信のためのあるデータタイプを定義するための本発明による工程を示すフローチャートである。
【符号の説明】
【００６５】
３００    バスモデル
３１０    ユーザ定義バスモデル
３１２    ユーザ定義ワードタイプ
３１４    ユーザ定義フィールドタイプ
３１６    メッセージタイプN
３１８    メッセージタイプC
【図１】
2006516834.tif 000005
【図２】
2006516834.tif 000006
【図３】
2006516834.tif 000007
【図４】
2006516834.tif 000008
【国際調査報告】
2006516834.tif 000009
2006516834.tif 000010