(57)【要約】【課題】通信ネットワークを介したメッセージによって複数のデバイスの動作を同期させるシステム及び方法を提供する。【解決手段】本発明が提供するシステムに含まれるデバイスは、通信ネットワークを介して通信可能に結合されており、デバイスのローカル・クロックは、ＩＥＥＥ１５８８、ＮＴＰ、または、他の技法を利用して、高精度の同期がとられている。デバイスのそれぞれがイベントマネージャを含んでいる。このイベントマネージャは、デバイスのうちの他方から、イベントおよびタイムスタンプを識別する情報を含むメッセージを受け取るように動作可能である。また、イベントマネージャは、受信したメッセージで識別されたイベントに応答して、対応するデバイスによる動作をトリガすべきか否か判定するように動作可能であり、該動作をトリガすべきであると判定されると、動作が、受信したメッセージに含まれるタイムスタンプに基づいてトリガされる。【選択図】図１
2006081192.tif 000002
【特許請求の範囲】
【請求項１】
同期されたクロックを備え、通信ネットワークを介して通信可能に結合された、少なくとも２つのデバイスを有し、
前記少なくとも２つデバイスのそれぞれが、前記デバイスのうちの他方から、イベントおよびタイムスタンプを識別する情報を含むメッセージを受け取るように動作可能なイベントマネージャを含み、
前記イベントマネージャが、受信したメッセージで識別されたイベントに応答して、その対応するデバイスによる動作をトリガすべきか否か判定するように動作可能であり、該動作をトリガすべきであると判定されると、前記動作が、受信したメッセージに含まれるタイムスタンプに基づいてトリガされる、
システム。
【請求項２】
前記少なくとも２つのデバイスが、互いに対話することにより、そのクロックを能動的に同期させる、請求項１に記載のシステム。
【請求項３】
前記少なくとも２つのデバイスが、ＩＥＥＥ１５８８規格に従ってそのクロックを同期させる、請求項１に記載のシステム。
【請求項４】
前記タイムスタンプが、前記メッセージを送るデバイスのクロックに基づく、請求項１に記載のシステム。
【請求項５】
前記イベントマネージャが、前記通信ネットワークで同報通信される前記メッセージを受け取るよう動作可能である、請求項１に記載のシステム。
【請求項６】
前記デバイスの少なくとも１つが、前記識別されたイベントに応答してトリガすべき動作に関してプログラム可能である、請求項１に記載のシステム。
【請求項７】
前記動作が、前記受信したメッセージのタイムスタンプによって定義された時間にトリガされる、請求項１に記載のシステム。
【請求項８】
通信ネットワークに通信可能に結合された複数のデバイスの少なくとも１つによって、イベント及びタイムスタンプの識別子を含むメッセージを受信するステップと、
前記少なくとも１つの受信するデバイスによって、前記受信されたメッセージが前記少なくとも１つの受信するデバイスの動作基準となるイベントを識別するか否かを判定するステップと、
前記受信されたメッセージが、前記少なくとも１つの受信側デバイスの動作基準となるイベントを識別すると判定されると、前記少なくとも１つの受信するデバイスが、前記受信されたメッセージに含まれるタイムスタンプに基づき、前記識別されたイベントに従って動作するステップと、
を有する方法。
【請求項９】
前記少なくとも１つの受信するデバイスが、イベントに応答した動作を行うように前記受信するデバイスを構成するプログラミング・メッセージを受信するステップをさらに有する、請求項８に記載の方法。
【請求項１０】
前記複数のデバイスのローカル・クロックが同期をとられている、請求項８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
通信ネットワークを介したメッセージによって複数のデバイスの動作を同期させるためのシステム及び方法に関する。
【背景技術】
【０００２】
システムをなす各種コンポーネントの動作を同期させることが望ましい場合が多い。例えば、いくつかの従来のオール・イン・ワン・ボックス型計器から構成される測定システムの場合、複雑な測定には、それぞれの動作を適正に同期させるため、いくつかの計器をまとめて制御しなければならない場合が多い。一例として、信号源が整定するまで、スペクトル・アナライザによる測定を許すべきではない。また、正確さを確保するのに十分な数のサンプルについて平均値が得られるまで、電力計の測定を実施すべきではない。また、現周波数における測定が完了するまで、周波数掃引信号源の新周波数への切換えを許すべきではない。従って、各種コンポーネントの相対的動作の同期が望ましくなる。
【０００３】
ハードウェア・トリガ・ライン（Hardware Trigger Line）を利用して、テスト・システムにおける各種計器を同期させる場合が多い。ハードウェア・トリガ・ラインは、正確な同期が必要とされる、あるいは、測定速度が重要になる測定システムにおいてとりわけ有効である。ハードウェア・トリガ・ラインを実施する場合、計器には、トリガ出力とトリガ入力が設けられ、専用ハードウェア・ライン（例えば、ワイヤ）によって１つの計器のトリガ出力と別の計器のトリガ入力が接続される。
【０００４】
例えば、スペクトル・アナライザは、一般に、同じボックス内に受信計器とディジタイザが含まれており、受信計器からの出力信号の測定は、整定までのある時間期間の経過後に実施すべきである。受信計器とディジタイザの間にハードウェア・トリガ・ラインを設ける場合、受信計器のトリガ出力ポートは、ハードウェア・ライン（例えば、ワイヤ）を介してディジタイザのトリガ入力ポートに結合されることになる。このハードウェア・ラインの電圧は、受信計器からの出力信号が整定する時点において高になる。ディジタイザ・ユニットのトリガ入力によってその電圧の高への変化が感知され、その測定が開始するようトリガされる。従って、ハードウェア・トリガ・ラインによれば、計器の相対的動作を所望のやり方で確実に同期させることになる。
【０００５】
ハードウェア・トリガ・ライン技法には、これら２つの計器間に延びる物理的ワイヤが必要になり、そのワイヤの機能は、トリガとしての利用に固定され、専用化される。さらに、こうしたハードウェア・トリガ・ラインを取り入れると、配線量が増大し、従って、ワイヤの経路指定に関する問題が生じたり、問題解決の困難さが増すといったように、配線の複雑性及び／または混乱を生じることになる。また、ハードウェア・トリガ・ラインの長さが増すにつれて（例えば、結合される計器相互間の配置間隔が増すにつれて）、こうしたハードウェア・トリガ・ラインによって伝達される信号の待ち時間も長くなる。
【０００６】
もう１つの同期技法では、ソフトウェアを用いて、各種計器の動作を同期がとれるように制御する。こうしたソフトウェアによる同期は、同期させる計器の配置が、あまりにも離れすぎていて、ハードウェア・トリガ・ラインを利用することができないといった場合のように、ハードウェア・トリガを利用できない状況において用いることが可能である。各種計器の動作の同期を制御するために、ソフトウェアを実施する場合、ソフトウェアは、所定の時間遅延、計器への問い合わせ、及び／または、ソフトウェア割り込みを利用して、計器の動作を調整することが可能である。例えば、第１の計器に命じて、第１の動作を実施させた後、外部コントローラのソフトウェアは、ある特定の時間量にわたって待機してから、別の計器に対して、第１の動作の完了後に実施すべきある特定の動作を行うように命じる。場合によっては、外部コントローラのソフトウェアが、計器に問い合わせて、ある特定の機能の完了時点を確認し、その結果、次の動作のトリガに適した時点を決定することが可能になることもある。場合によっては、計器を使用して、外部コントローラに信号を送り、コントローラにソフトウェア割り込みを発生させて、例えば、ある特定の計器がある特定の動作を完了したことを表示することも可能である。
【０００７】
上述の受信計器及びディジタイザの動作の同期にソフトウェア同期化技法を利用する例として、制御コンピュータから受信計器に、周波数変更を命じるメッセージを送ることが可能である。既知のように、周波数が変更された信号の測定をトリガする前に、ある量の待機時間が必要になる（変更周波数を整定させるため）。従って、受信計器に周波数変更を命じた後、制御コンピュータは１００ミリ秒といった、所定の時間量にわたって待機（または「休止」）する。その後、制御コンピュータは、ディジタイザに命じて、測定を開始させる。
【０００８】
ネットワーク化されたデバイス（device）のクロックを高い精度で同期させる技法も既知のところである。一例として、ネットワーク・タイム・プロトコル（Network Time Protocol、ＮＴＰ）は、コンピュータ・ネットワークにおけるコンピュータ・クロック時間の同期に利用されるプロトコルである。同様のプロトコルと同じように、ＮＴＰは協定世界時（Coordinated Universal Time、ＵＴＣ）を利用して、１ミリ秒以内まで、場合によっては、数分の１ミリ秒以内まで、コンピュータ・クロック時間を同期させる。もう１つの例として、電気電子技術者協会規格協会（Institute of Electrical and Electronics Engineers Standards Association、ＩＥＥＥ−ＳＡ）によって、ＩＥＥＥ１５８８「ネットワーク化測定及び制御システムのための精密同期プロトコルに関する規格」と呼ばれる、ネットワークにおけるクロック間の同期性を維持するための新規の規格が承認されている。一般に、このＩＥＥＥ１５８８規格では、クロックを同期状態に保つため、ネットワーク化されたデバイス間におけるタイミング情報の交換に利用することが可能なメッセージが定義されている。ＩＥＥＥ１５８８規格によれば、ＮＴＰによって得られるよりいっそう高精度の（例えば、１マイクロ秒以内までの）クロック同期が可能になる。
【０００９】
しかし、ＮＴＰ及びＩＥＥＥ１５８８規格によれば、ネットワーク化されたデバイスのクロックを高精度で同期させることによって、それぞれ、ローカル・クロックを備えるネットワーク化されたデバイスが、共通時間感覚を持つようにする技法が得られるが、これらの技法は、デバイスの動作の同期に対応しない。それどころか、こうした技法は、ネットワーク化されたデバイス間において、クロックを同期された状態に能動的に（actively）維持することに焦点を絞ったものである。従って、この能動クロック同期化技法の場合、仮にあるとしても、それぞれの動作を同期させるために、デバイスが同期されたクロック（synchronized clock）を活用できるようにする方法については未解決のままである。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
本発明の目的は、通信ネットワークを介したメッセージによって複数のデバイスの動作を同期させるシステム及び方法を提供することにある。
【課題を解決するための手段】
【００１１】
例えば、複数のデバイスが、通信ネットワークを介して通信可能に結合されており、それらのデバイスのローカル・クロックは、ＩＥＥＥ１５８８、ＮＴＰ、または、それらのローカル・クロックを同期させるための他の何らかの技法を用いて、高精度の同期がとられている。イベントの識別子、並びに、送信側のローカル・クロックに基づくタイムスタンプを含む、イベントメッセージを送ることが可能である。イベントメッセージの受信側では、識別されたイベントに基づいて動作するように構成／プログラムされているか否かを判定することが可能であり、識別されたイベントに基づいて動作すべき場合には、イベントメッセージに含まれるタイムスタンプに基づいて、その動作を行うことが可能である。実施態様によっては、各デバイス毎に、動作をトリガすることになるイベント及び／または、ある特定のイベントに関して行うべき特定の応答動作を動的にプログラムすることが可能なものもある。本明細書に記載のように、各デバイス毎に実施される動作は、イベントメッセージに含まれるタイムスタンプを基準にすることが可能であるため、イベントメッセージを利用して、高い時間精度で各種デバイスの動作を調整することが可能である。
【００１２】
例えば、少なくとも１つの実施態様によれば、システムには、通信ネットワークを介して通信可能に結合された少なくとも２つのデバイスが含まれており、この少なくとも２つのデバイスには、それらのクロックを同期させるための手段が含まれている。本明細書に提示されるさまざま実施態様による、それらのクロックを同期させるための手段は、例えば、デバイス間でメッセージを交換することによってデバイスのローカル・クロックを同期させる。こうした同期クロックは、例えば、ＩＥＥＥ１５８８規格またはＮＴＰ規格に従って実施することが可能である。少なくとも２つのデバイスにはさらに、通信ネットワークを介して、タイムスタンプを含み、イベントを識別するメッセージを少なくとも２つのデバイスのもう一方に伝達するための手段も含まれている。さらに、少なくとも２つのデバイスには、メッセージを受信して、識別イベントに応答して行うべき応答動作を決定するための手段も含まれており、決定された動作は、メッセージに含まれるタイムスタンプに基づいて実施される。従って、デバイスの動作は、通信ネットワークを介して伝達されるイベントメッセージを利用することにより、同期がとられたそれらのローカル・クロックに基づいて調整することが可能である。
【００１３】
実施態様によっては、イベントメッセージを、例えばＵＤＰを利用して、通信ネットワークを介して同報通信することが可能である。従って、イベントメッセージの送信側は、メッセージが送られる他のデバイスに関心を抱く必要はなく、他のデバイスのどれが通信ネットワークに結合しているかについて認識していない場合さえあり得る。通信ネットワーク（例えば、ＬＡＮまたはＷＡＮのサブネット）上の全てのデバイスが、同報通信されたイベントメッセージを受信することが可能であり、各デバイスは、その識別イベントに応答して、ある動作を行うように構成されているか否かを判定することが可能である。受信側デバイスが、その識別イベントについて動作を行うように構成されていなければ、同報通信されたイベントメッセージを無視することが可能である。もちろん他の実施態様では、例えばＴＣＰを利用するといったように、非同報通信方式でイベントメッセージを送ることが可能な場合もある。
【００１４】
以上の説明は、下記の本発明に関する詳細な説明をより明確に理解できるようにするため、本発明の特徴及び技術的利点をかなり大まかに概説したものである。本発明の請求の範囲の内容を形成する本発明のさらなる特徴及び利点については、後述することにする。当然明らかなように、開示の概念及び特定の実施態様は、本発明の同じ目的を実施するための修正または他の構造の設計の基礎として容易に利用することが可能である。やはり当然明らかなように、こうした同等構成は、付属の請求の範囲に記載された本発明から逸脱するものではない。その構成と動作方法の両方に関して本発明に固有のものであると信ずるところの新規の特徴、並びに、さらなる目的及び利点については、付属の図と関連づけて検討すれば、下記の説明からさらに明確な理解が得られるであろう。ただし、特に理解しておくべきは、図のそれぞれは、例証及び説明だけを目的として提示されたものであり、本発明の限界を定義することを意図したものではないという点である。
【００１５】
次に、本発明のより完全な理解が得られるように、添付の図面に関連してなされる下記の説明について言及することにする。
【発明を実施するための最良の形態】
【００１６】
上述のように、測定システムは、正確な測定結果が得られるようにするため、適切なやり方で、いくつかの計器の動作を同期させる（または調整する）必要がある。例えば、スペクトル・アナライザは、信号源計器がその出力周波数で整定するのに十分な機会を得た後で、その測定を行うように調整すべきである。
【００１７】
測定システムの全てまたは一部は、「合成計器（synthetic instruments）」によって形成することが可能である。合成計器は、単独で測定を達成することはできないが、代わりに、それらの集合体が、共同作業によって、測定を実施しなければならない。一方、従来のオール・イン・ワン・ボックス計器（本明細書では、「完全収納計器（fully contained instruments）」と呼ばれる）には、所望の測定を実施するのに必要な全てのサブシステムが完全に収納されている。例えば、スペクトル・アナライザは、完全収納計器として実施することもできるし、あるいは、こうしたスペクトル・アナライザは、通信ネットワークを介して通信可能に結合された、受信計器、ディジタイザ等のような、合成計器の集合体によって形成することも可能である。完全収納システムは、測定対象を得るため、他のシステムとのインターフェイスが必要になる可能性がある。例えば、完全収納システムは、信号源計器（source）によって生じる信号を測定するため、信号源計器とインターフェイスする。複数の完全収納計器（例えば、スペクトル・アナライザ、ＲＦ源等）を利用するか、複数の合成計器（または、完全収納計器と合成計器の組み合わせ）を利用するかにかかわらず、正確な測定を可能にするため、何らかのやり方で、各種計器の相対動作を調整するのが望ましい場合が多い。
【００１８】
従来の完全収容計器内の各種サブシステムは、ハードウェア・トリガ・ライン及び／またはその基礎ファームウェアを介して時間調整及び同期機能を実施することが可能である。完全収納計器の機能部品である合成計器は、例えば、その配置があまりに離れすぎているために、ハードウェア・トリガ・ラインの利用が実用的でなくなるので、及び／または、こうしたハードウェア・トリガ・ラインの導入にかかわる配線の複雑さによって、その解決法が望ましくないものになる可能性があるので、他の何らかの方法で同期させることが必要になる可能性がある。さらに、各合成計器（または「モジュール」）には、より小規模の組をなす機能が含まれているので、合成計器の同期に関する要件は、独立した完全収容計器間における同期よりも厳しい場合が多い。
【００１９】
もう一度、スペクトル・アナライザの上述の例に言及すると、最新の完全収容スペクトル・アナライザには、一般に、受信計器（receiver）とディジタイザ（digitizer）が含まれている。スペクトル・アナライザのファームウェアは、受信計器の掃引周波数、並びに、ディジタイザを制御し、正確な測定の実施を保証するため、ディジタイザと受信計器周波数を容易に同期させることが可能である。一方、合成計器システムには、受信計器とディジタイザを含むことが可能であるが、同じ計器にではない。これらのデバイス間の同期は、従って、単一計器内に制限されない。この合成計器システムの場合、ディジタイザと受信計器周波数の同期は、ディジタイザによる測定が受信計器周波数の整定時に行われ、それより早くも、遅くもならないことを保証するようにとることが求められる。本明細書では、複数の合成計器及び／または完全収容計器の動作を同期させるのに用いることが可能な技法が提示される。
【００２０】
図１を参照すると、複数のネットワーク化デバイス（または「計器（instruments）」）の動作を調整するためのシステム例１０が、実施態様の１つに従って示されている。システム例１０には、ローカル・エリア・ネットワーク（ＬＡＮ）、インターネット、または、他の広域ネットワーク（ＷＡＮ）、公衆交換電話網（ＰＳＴＮ）、無線ネットワーク、以上の任意の組み合わせ、及び／または、少なくとも１つのデバイスから他の少なくとも１つのデバイスに情報を伝達するための、現在知られているか、または、今後開発される他の任意のネットワークとすることが可能な通信ネットワーク１４を介して、全て、通信可能に結合されたコントローラ１１、信号源計器１２、及び、受信計器１３が含まれている。この例では、信号源計器１２及び受信計器１３が示されているが、もちろん、本明細書で解説される、動作の同期をとるための実施態様は、これら典型的な計器への適用に制限されるものではない。本明細書に解説の技法は、測定システムを形成する任意の計器の動作を同期させるために用いることが可能である。こうした技法は、測定システムの合成計器及び／または完全収容計器の動作の同期にも用いることが可能である。さらに、これらの技法は、測定の実施に利用される各種計器の動作に高精度の同期を施すため、とりわけ、測定システムに適用可能であるが、本明細書で解説の技法は、複数のネットワーク化デバイスの動作を同期させることが求められる、他のタイプのシステムにおいても同様に用いることが可能である。
【００２１】
パーソナル・コンピュータ（ＰＣ）または他のプロセッサ・ベースのデバイスとすることが可能なコントローラ１１には、ＣＰＵ１０５Ａが含まれている。同様に、信号源計器１２には、ＣＰＵ１０５Ｂが含まれており、受信計器１３には、ＣＰＵ１０５Ｃが含まれている。コントローラ１１、信号源計器１２、及び、受信計器１３は、この例の場合、それぞれ、同期されたローカル・クロックを備えている。この特定の例では、ＩＥＥＥ１５８８が利用されており、コントローラ１１は、ＩＥＥＥ１５８８クロック１０３Ａを使用し、信号源計器１２はＩＥＥＥ１５８８クロック１０３Ｂを使用し、受信計器１３はＩＥＥＥ１５８８クロック１０３Ｃを使用している。もちろん他の実施例では、ＮＴＰを用いるといったようにローカル・クロックを能動的に同期させるための他の技法を用いることも可能である。デバイスが互いに対話して、用いられる特定の同期技法（例えば、ＩＥＥＥ１５８８またはＮＴＰ）に従ってそれぞれのローカル・クロックを同期された状態に維持するので、ローカル・クロックは、「能動的に同期された（actively synchronized）」と称される。代替実施態様の場合、ＧＰＳ（全地球測位システム）受信計器等を用いてローカル・クロックを同期させる他の技法（例えば、受動技法）を用いることも可能である。従って、コントローラ１１、信号源計器１２、及び、受信計器１３は、共通時間感覚を備えるように、ローカル・クロック１０３Ａ、１０３Ｂ、及び、１０３Ｃに高精度の同期を施す。さらに後述するように、実施態様によっては、コントローラ１１のローカル・クロックと、信号源計器１２及び受信計器１３などの測定システムにおける他の計器のクロックとを同期させる必要のないものもある。
【００２２】
コントローラ１１、信号源計器１２、及び、受信計器１３のそれぞれは、１０１Ａ、１０１Ｂ、及び、１０１Ｃとそれぞれ表示されて、それらにおいて実行するイベントマネージャを備えている。一般に、イベントマネージャは、各種計器による時間依存イベントに関する情報伝達を可能にするように設計されたソフトウェア及び／またはハードウェアである。本実施態様例によるイベントマネージャの働きについては、さらに詳細に後述する。
【００２３】
さらに図１のシステム例１０についての論考を続行する前に、本明細書において用いられることになる用語のいくつかについて簡単に述べておくことが有用である。
【００２４】
「イベント」という用語は、単独で用いられる場合、システム例１０の信号源計器１２内または受信計器１３内といった、計器内部で発生するものを表わしている。例えば、ディジタイザの入力バッファが満杯になると、あるいは、出力信号が整定すると、あるイベントが生じる可能性がある。イベントは、通常、計器のハードウェアによって生じるが、それは制限ではない。ソフトウェアによってイベントを生じさせることも可能である。
【００２５】
「イベントメッセージ」という用語は、通信ネットワークで送られ、イベントの発生を他の計器に通知するために用いられるメッセージを表す。本明細書に提示のいくつかの実施態様では、イベントメッセージは、例えば、ユーザ・データグラム・プロトコル（ＵＤＰ）を利用して、ある特定の通信ネットワークにおける（例えば、ある特定のサブネットにおける）全ての計器に同報通信される。他の実施態様では、イベントメッセージは、伝送制御プロトコル（ＴＣＰ）のようなポイント・ツー・ポイント・プロトコルによって送られる。どの計器も、イベントメッセージを送ることが可能である。他の計器には、イベントメッセージに応答することが可能なものもあれば、あるいは、無視することが可能なものもある。
【００２６】
「出力イベント」という用語は、その結果、イベントメッセージが通信ネットワークで伝達されることになるイベントを表わしている。全てのイベントが出力イベントというわけではないという点に留意されたい。ある計器は、いくつかのイベントを内部で処理することが可能である。
【００２７】
「入力イベント」という用語は、別の計器から受信するイベントを表わしている。入力イベントは、通信ネットワークによってイベントメッセージの形で到着する。
【００２８】
「動作（action）」という用語は、イベントまたはイベントメッセージに応答して、計器が実施する何かを表している。本明細書に提示されるいくつかの実施態様では、動作はコールバック・ルーチンによって実行される。これに関して、動作は原子イベントではなく、例えばコールバック・ルーチンは、複雑なシーケンスの命令を実行することが可能である。
【００２９】
「プログラミング・メッセージ」という用語は、ある特定イベントの検出に応答してある特定動作を行うように受信側デバイスにプログラムするために用いられて、通信ネットワークで送られるメッセージを表わしている。
【００３０】
本明細書に解説の実施態様によれば、イベントメッセージは、信号源計器１２及び受信計器１３のような、計器の動作を調整するために、通信ネットワーク１４によって送られる。従って、測定システムに用いられる計器の全ての間にハードウェア・トリガ・ラインを必要とするのではなく、少なくとも一部の計器は、本明細書に解説のメッセージ・ベース技法を利用して同期がとられる。少なくとも実施態様の１つによれば、イベントメッセージには、イベントの識別子並びに対応するタイムスタンプが含まれる。計器は、内部で受信するイベントまたはイベントメッセージ（「入力イベント」）に含まれるイベントとすることが可能なある特定のイベントを受信すると、特定の動作を行うように構成／プログラムすることが可能である。本明細書においてさらに明らかにされるように、実施態様によっては、動作の動的プログラミングが可能な場合もある。例えば、コントローラ１１は、ある特定イベントの検出時に、信号源計器１２にプログラミング・メッセージを送り、そのイベントマネージャ１０１Ｂに対してある特定の動作を行うように命じることが可能である。実施態様によっては、信号源計器１２は、このように動的にプログラムされるのではなく、ある特定イベントに応答して、所望の動作を行うように事前構成することが可能なものもある。従って、計器は、検出イベントに応答して、適切な動作を行うようにプログラム（または別様に構成）されるので、イベントを識別するイベントメッセージ及び対応するタイムスタンプ（計器の同期されたローカル・クロックによる）を利用して、本明細書においてさらに後述するように、計器のそれぞれの動作を調整することが可能である。
【００３１】
図１の実施態様例の場合、コントローラ１１、信号源計器１２、及び、受信計器１３のそれぞれには、１０２Ａ、１０２Ｂ、及び、１０２Ｃとそれぞれ表示されたプログラムイベント情報が含まれている。こうしたプログラムイベント情報によって、例えば指定のイベントに応答して、対応する計器が実施するように構成される動作を指定することが可能である。プログラムイベント情報は、例えば、データベースとして構成するか、または他の適合する任意のやり方で記憶することが可能である。実施態様によっては、ユーザ１５がイベントマネージャ１０１Ａとの対話によって、例えば各種計器に関するイベント情報をプログラムできるようにするため、コントローラ１１にユーザ・インターフェイス１０４が設けられる場合もある。プログラムイベント情報１０２Ａ〜１０２Ｃの例については、後掲の表２に提示された特定の例を含めて、本明細書においてさらに解説することにする。
【００３２】
計器のローカル・クロックは高精度の同期がとられるので、各種ネットワーク化計器の動作には、こうした高精度の調整を施すことが可能になる。メッセージ・ベース・アプローチを利用して計器の動作を調整することができるが、計器のローカル・クロックは高精度の同期がとられているので、メッセージによって可能になるよりも高い精度で動作を調整することが可能になる（例えば、通信ネットワーク１４を介してメッセージを送る場合に被る可能性のある待ち時間等のため）。
【００３３】
例えば、信号源計器１２が、「１番イベント」の検出に応答して、その出力周波数（例えば、ＲＦ周波数）を変更し、その周波数が整定すると、「２番イベント」を識別するイベントメッセージを出力するように構成／プログラムされているものと仮定する。さらに、受信計器１３が、２番イベントの検出に応答して、信号の測定（例えば、信号のパワー及び／または他の特性）を行うように構成／プログラムされているものと仮定する。実施態様によっては、ユーザ１５が、ユーザ・インターフェイス１０４を介してコントローラ１１と対話し、信号源計器１２に１番イベントを遅らせることによって、測定プロセスを開始することが可能なものもある。本明細書においてさらに後述するように、実施態様によっては、通信ネットワーク１４を介してこうした１番イベントを同報通信することが可能なものもある。信号源計器１２のイベントマネージャ１０１Ｂは、１番イベントを検出し、この１番イベントに関するプログラムイベント情報１０２Ｂにおいて識別される対応するプログラム動作に従って、その周波数を変更し、その後、２番イベントを識別するイベントメッセージを受信計器１３に送ることになる。やはり、実施態様によっては、信号源計器１２によって送られるこのイベントメッセージを通信ネットワーク１４を介して同報通信することが可能なものもある。イベントメッセージには、さらに、変更周波数が整定する（従って、測定準備が整う）時点に対応して、信号源計器のローカル・クロック１０３Ｂに基づくタイムスタンプが含まれている。
【００３４】
受信計器１３は、２番イベントを識別するイベントメッセージと対応するタイムスタンプを受信し、これにより、２番イベントに応答し、イベントメッセージ内の対応するタイムスタンプに基づいて、そのプログラム動作を実施することが可能になる。例えば、受信計器１３は、２番イベントの検出に応答して、受信したイベントメッセージに含まれるタイムスタンプにおいて測定を実施し、コントローラ１１にその測定結果を送るようにプログラムすることが可能である。この例では、受信計器１３が、イベントメッセージに含まれていたタイムスタンプ後にイベントメッセージを受信することになっても、受信計器１３が連続して測定を行い、緩衝記憶していれば、そのバッファから、イベントメッセージに含まれるタイムスタンプに対応する測定結果を検索し、コントローラ１１に送ることが可能である。従って、コントローラ１１は、信号源計器１２から受信計器１３へのイベントメッセージに含まれる正確なタイムスタンプに対応する測定結果を受信する。信号源計器１２から受信計器１３へのイベントメッセージが、受信計器１３のバッファに、イベントメッセージに含まれるタイムスタンプに対応した測定結果がもはやなくなる程にまで遅延した場合、受信計器１３は、例えば、エラーを発生することが可能である。
【００３５】
もう１つの例では、受信計器１３は、２番イベントの検出に応答して、例えば、受信イベントメッセージに含まれるタイムスタンプから２秒後といった、受信イベントメッセージに含まれるタイムスタンプからある時間期間後に、測定を実施し、その測定結果をコントローラ１１に送る。メッセージに含まれるタイムスタンプから２秒以内に、イベントメッセージを生成し、通信ネットワーク１４を介して送ることが可能であると仮定すると、受信計器は、このメッセージを受信して、然るべくその測定を実施する（または、連続して測定を実施している場合には、そのバッファから対応する測定結果を検索する）ことが可能である。従って、受信計器１３は、受信計器がイベントメッセージを受信する時点とは対照的に、イベントメッセージに含まれるタイムスタンプに関連した時間に測定を実施することが可能になる。従って、信号源計器１２及び受信計器１３は、イベントメッセージに含まれるタイムスタンプに従って調整することが可能であり、こうしたタイムスタンプは、メッセージの受信時（ネットワークの待ち時間に基づいて変動する可能性のある）に基づいて動作の同期をとることに制限されないで、メッセージの送信側、すなわちこの例の場合では、信号源計器の同期されたクロックを基準としている。
【００３６】
図２を参照すると、ネットワーク化計器の動作を調整するためのシステム１０（図１の）において、メッセージ・ベース技法を利用する特定の例が示されている。図２の例では、操作ブロック２０１において、コントローラ１１を利用して、信号源計器１２のプログラミングが行われる。例えば、ユーザ１５は、ユーザ・インターフェイス１０４と対話して、信号源計器１２のプログラミングの基準となる特定の情報を指定することが可能である。この例では、信号源計器１２は、１：００：００にその周波数を変更し、次に、１番イベントを識別するイベントメッセージを同報通信するようにプログラムされる。従って、信号源計器１２は、コントローラ１１からこの情報を受信すると（プログラミング・メッセージによって）、そのプログラムイベント情報１０２Ｂに納める。このやり方で絶対時間またはある相対時間（例えば、「イベントＸを識別したイベントメッセージに含まれるタイムスタンプから１０秒」といったように、他のある時間に対して指定された時間）に生じるようにあるイベントのスケジューリングを行うことは、絶対または相対爆発時間を有する「時限爆弾（Time Bomb）」をセットすると称することが可能であり、こうした時限爆弾が爆発すると、時限爆弾がセットされた対応するデバイス（この例の場合、信号源計器１２）は、あるプログラム動作を実施する（この例の場合、その周波数を変更する）。こうした時限爆弾を実施し、それらを利用して、ネットワーク化デバイスの動作を調整する例については、その開示が参考までに本明細書において援用されて、同時に提出され譲渡先が共通の、「SYSTEM AND METHODS FOR COORDINATING THE ACTIONS OF A PLURALITY OF DEVICES VIA SCHEDULING THE ACTIONS BASED ON SYNCHRONIZED LOCAL CLOCKS」と題する米国特許出願（代理人整理番号１００４１３２８）にさらなる記載がある。
【００３７】
操作ブロック２０２では、コントローラ１１を利用して、受信計器１３のプログラミングが行われる。例えば、ユーザ１５は、ユーザ・インターフェイス１０４と対話して、受信計器１３のプログラミングの基準となる特定の情報を指定することが可能である。この例では、受信計器１３は、１番イベントを検出すると、測定を実施し、次に、２番イベントを識別するイベントメッセージを同報通信するようにプログラムされる。従って、受信計器１３は、コントローラ１１からこの情報を受信すると、そのプログラムイベント情報１０２Ｃに納める。
【００３８】
さらに、この例では、ブロック２０３において、特定のイベントを検出すると応答動作を行うように、コントローラ１１自体のプログラミングが行われる。例えば、ユーザ１５は、ユーザ・インターフェイス１０４と対話して、コントローラ１１のプログラミングの基準となる特定の情報を指定することが可能である。この例では、コントローラ１１は、２番イベントを検出すると、受信計器１３から測定データを読み取り、次に、その読み取りデータを表示するようにプログラムされる。従って、コントローラ１１は、この情報を受信すると、そのプログラムイベント情報１０２Ａに納める。
【００３９】
図２の操作ブロック２０４に示すように、１：００：００に信号源計器１２のセットされた時限爆弾が爆発し、その結果、信号源計器１２はその周波数を変更し、さらに１番イベントを識別するイベントメッセージを生成する。上述のように、イベントメッセージには、信号源計器１２のローカル・クロック１０３Ｂに基づく対応するタイムスタンプも含まれている。この例では、信号源計器１２が、ＵＤＰまたは他の何らかの適合するマルチキャスト・プロトコルを利用して、通信ネットワーク１４を介して、イベントメッセージの同報通信を行う。こうして伝達されるメッセージに依存して、ネットワーク化計器間の動作を調整する場合に求められる可能性のあるＵＤＰのような「信頼性に欠ける」プロトコルを利用するために、その信頼性を高めるやり方でいくつかの実施態様において用いることが可能な技法については、その開示が参考までに本明細書において援用され、同時に提出され譲渡先が共通の、「SYSTEM AND METHOD FOR ROBUST COMMUNICATION VIA A NON-RELIABLE PROTOCOL」と題する米国特許出願（代理人整理番号１００４１３３１−１）にさらなる記載がある。
【００４０】
従って、信号源計器１２のイベントマネージャ１０１Ｂは、１番イベントを識別し、信号源計器１２のローカル・クロック１０３Ｂに基づく対応するタイムスタンプを含むイベントメッセージを同報通信する。例えば、タイムスタンプは、変更周波数が整定する時間に対応する、時間１：００：０１とすることが可能である。もちろん、信号源計器１２は、その周波数変更の開始時間にメッセージを送るようにプログラムすることが可能であり、従って、イベントメッセージに含まれるタイムスタンプは、信号源計器が周波数変更を開始する時間に対応するといって差し支えなく、この場合、受信計器１３は、周波数の整定を考慮し、含まれているタイムスタンプに対してある時間遅らせて、その測定を行うようにプログラムすることが可能である。このようにすると、信号源計器において周波数変更が行われている間に、イベントメッセージが受信計器に向かっている可能性があり、その結果、測定の効率が向上する可能性がある。
【００４１】
同報通信される１番イベントは、コントローラ１１のイベントマネージャ１０１Ａによって検出され、操作ブロック２０５においては、コントローラ１１のこうしたイベントマネージャ１０１Ａによって、コントローラ１１による応答動作が不要であると判定される。すなわち、コントローラ１１は、受信した１番イベントに対して応答動作するようにプログラムされておらず、従って、イベントマネージャ１０１Ａは、信号源計器１２によって同報通信されたイベントメッセージを無視する。
【００４２】
同様に、同報通信された１番イベントは、受信計器１３のイベントマネージャ１０１Ｃによって検出される。受信計器１３は、１番イベントを受信すると、測定を行うようにプログラムされているので（操作ブロック２０２参照）、操作ブロック２０６において、受信計器１３のイベントマネージャ１０１Ｃは、受信計器１３にこうした応答動作を実施させる。上述のように、受信計器１３は、イベントメッセージに含まれているタイムスタンプにおいてその測定を行うようにプログラムすることもできるし（受信計器１３は、こうしたタイム・スタンプに行う、緩衝記憶されている測定を検索することが可能である）、あるいは、例えば、イベントメッセージに含まれているタイムスタンプからプログラムされた時間間隔が経過してから、その測定を行うようにプログラムすることも可能である。
【００４３】
受信計器１３がブロック２０２において実施するようにプログラムされていたのとちょうど同じように、操作ブロック２０７において、受信計器１３は２番イベントを識別し、そのローカル・クロック１０３Ｃに基づく対応するタイムスタンプを含むイベントメッセージの同報通信を行う。同報通信される２番イベントは、信号源計器１２のイベントマネージャ１０１Ｂによって検出され、操作ブロック２０８においては、信号源計器１２のこうしたイベントマネージャ１０１Ｂによって、信号源計器１２による応答動作が不要であると判定される。すなわち、信号源計器１２は、受信した２番イベントに対して応答動作するようにプログラムされておらず、従って、イベントマネージャ１０１Ｂは、受信計器１３によって同報通信されたイベントメッセージを無視する。
【００４４】
同報通信された２番イベントメッセージは、コントローラ１１のイベントマネージャ１０１Ａにも検出される。コントローラ１１は、２番イベントを受信すると、受信計器１３から測定データを読み取って、前記データを表示するようにプログラムされているので（操作ブロック２０３参照）、操作ブロック２０９において、コントローラ１１のイベントマネージャ１０１Ａは、コントローラ１１にこうした応答動作を実施させる。従って、コントローラ１１は、受信計器１３から測定データを読み取る。例えば、受信計器１３が信号源計器１２から受信したイベントメッセージのタイムスタンプに従って、受信計器１３によって捕捉された測定データは、受信計器１３のある特定メモリ・アドレスに記憶することが可能であり、ブロック２０９において、コントローラ１１は、受信計器１３のその特定メモリ・アドレスの読み取りを行うことが可能である。もう１つの例として、受信計器１３によって生成されるイベントメッセージには、その測定が行われたタイムスタンプ（例えば、信号源計器１２から受信計器１３に送られたイベントメッセージに含まれている同じタイムスタンプ、または、信号源計器１２から受信計器１３に送られたイベントメッセージに含まれているタイムスタンプからある特定間隔をあけたタイムスタンプ）を含むことが可能であり、コントローラ１１は、ブロック２０９において実施された、そのタイムスタンプに対応するその測定について、受信計器１３に問い合わせることが可能である。次に、ブロック２１０において、コントローラ１１は、読み取った測定データを表示する。
【００４５】
上記の例では、コントローラ１１は、受信計器１３による測定からある時間経過するまで、２番イベントを識別するイベントメッセージを受信せず、さらに後の時間まで、こうした測定データの読み取り及び表示を行わない。しかし、イベントメッセージにおける同期されたクロックのタイプスタンプを利用するので、コントローラ１１は、適切な測定データを表示していると確信することができる。例えば、受信計器１３が、１：００：０１に測定を行った場合、コントローラ１１は、例えば、１：００：０５まで測定データの読み取り及び表示を行うことができなくても、１：００：０１に捕捉された測定データを表示していると確信することができる。
【００４６】
もちろん、デバイスの動作を同期させるため、本明細書に提示の実施態様を適用することについては、図２の特定例に制限されるものではない。
【００４７】
上記例によって明らかなように、イベントマネージャ１０１Ａ〜１０１Ｃ（図１）は、同期されたクロックに関するＩＥＥＥ１５８８機能性に基づいて構成されているが、任意の非同期イベントを生じさせ、他の計器に同報通信できるようにすることで、ＩＥＥＥ１５８８の範囲を超えるものである。実施態様によっては、システム内の各計器毎に、あるイベントが起こると、いつでもネットワークによるイベントメッセージの同報通信が可能というものもある。各計器毎に動作誘因となるイベントのリストは、計器によって異なる可能性があり、実施態様によっては、各計器毎に動作をプログラムすることが可能なものもある。例えば、信号源は、図２の上記例の操作ブロック２０４におけるように、周波数変更後、出力信号が整定すると、いつでもイベントメッセージを同報通信するようにプログラムすることが可能であり、あるいは、ディジタイザは、その入力バッファが満杯になると、いつでもイベントメッセージを送信することが可能である。従って、各計器毎に、動作誘因となるイベントの集合を明確に定義することが可能である。
【００４８】
実施態様によっては、イベントメッセージを受信するために、どの計器もイベントメッセージに対する「同意」を行うことが可能なものもある。すなわち、各計器は、他の計器によって同報通信される（それぞれのイベントマネージャを通じて）イベントメッセージを受信すると、適宜それらに応答する（あるいはそれらを無視する）ことが可能であることが望ましい。
【００４９】
例えば、周波数変更にアップコンバータを必要とする測定が行われているものと仮定する。アップコンバータは、ディジタイザによる任意のデータ読み取りが可能になる前に、整定しなければならない。アップコンバータは、出力信号が整定すると、いつでも内部イベント（おそらくは、割り込み）を発生する組み込み能力を備えている。こうしたアップコンバータ及びディジタイザのために用いられるイベントマネージャを利用すると、これは、下記シーケンスによって実施することが可能になる。
【００５０】
１．ユーザが、コントローラＰＣからアップコンバータに、アップコンバータにおいて定義済みの内部イベントである「信号整定（signal settled）」イベントに応答するように、アップコンバータにプログラムするコマンドを送る。このイベントを構成する一部として、ユーザは、コールバック・ルーチンを指定する。このルーチンは、「信号整定」イベントが生じるといつでも呼び出されるものであり、ネットワーク上の他の計器にイベントメッセージを同報通信する責務を負っている。
【００５１】
２．ユーザが、アップコンバータからの「信号整定」イベントメッセージに応答するように、ディジタイザにプログラムする。やはり、コールバック・ルーチンが指定される。この場合、コールバック・ルーチンは、ディジタイザにおける測定を開始させる責務を負っている。
【００５２】
３．ユーザが、周波数を変更するコマンドをアップコンバータに送る。
【００５３】
４．アップコンバータの出力信号が整定すると、内部イベントが発生し、アップコンバータのコールバック・ルーチンが呼び出される。この結果、イベントメッセージがネットワークで同報通信される。メッセージには、イベント識別子（例えば、「１番アップコンバータの信号整定」）及びタイムスタンプが含まれる。
【００５４】
５．メッセージが、ディジタイザによって受信され、構文解析されて、そのメッセージが関連するものか否かの判定が行われる。ディジタイザは、このメッセージに応答するようにプログラムされていたので、コールバック・ルーチンが実行され、測定が開始される。
【００５５】
イベントメッセージが、ＩＥＥＥ１５８８クロックを用いてタイムスタンプが施されているという点に注目するのが重要である。これによって、受信計器は、適切であれば、その応答を調整できる。例えば、循環測定バッファを備えたディジタイザの場合、ネットワーク待ち時間によってイベントメッセージの到着が遅れても、もとのイベントの正確な時間における（あるいはそれ以前における）データを保存することが可能になる。
【００５６】
認識しておくべきは、イベントを識別し、タイムスタンプを含むメッセージを生成することによって、デバイスに生じるイベントに基づいて、各種ネットワーク化計器の動作を調整することが可能になるという点である。もちろん、図２の例に示されるように、イベントベースのアプローチと時間ベースのアプローチ（例えば、時限爆弾を利用して、絶対時間か相対時間かはともかく、スケジュールされた時間にイベントが生じるようにスケジュールする）を組み合わせることも可能である。例えば、計器に固有のイベント以外に、計器は、「時限爆弾」をサポートするために用いられることも可能である。これによって、ユーザは、イベントが生じることになる時間を定義することが可能になる（システムにおける他の全ての計器のクロックと同期されたＩＥＥＥ１５８８クロックを利用して）。同時に、ユーザ定義可能イベントをネットワーク上の他の計器に送ることもできるし、あるいは、他のある内部機能を実行することもできるし、あるいは、その両方を行うことも可能になる。
【００５７】
もう１つの例として、ネットワーク化アップコンバータ及びディジタイザからなる上述の合成システムは、時間ベース・モデル及びイベントベース・モデルの組み合わせを利用して、下記のように動作を調整することが可能である。
【００５８】
１．ホスト・コンピュータが、測定の開始に用いられるイベントメッセージを定義する。この新しいイベントメッセージは、「開始（start）」メッセージと呼ばれる。
【００５９】
２．「開始」イベントメッセージを受信するといつでも新しい周波数にスイッチするように、アップコンバータに対しプログラミングが施される。すなわち、「開始」メッセージには、タイムスタンプを含むことが可能であり、アップコンバータには、それからある時間経過後に、新しい周波数にスイッチするようにプログラムされる。これには、ネットワーク待ち時間が考慮されており、アップコンバータ及びディジタイザが同じ時間基準によって作業しているという保証が得られる。
【００６０】
３．アップコンバータの出力信号は、１００マイクロ秒（μｓｅｃ）後に整定することが分っている。ディジタイザには、「開始」イベントメッセージの受信から１００μｓｅｃ後に測定を開始するようにプログラムされる。すなわち、ディジタイザは、「開始」メッセージからのタイムスタンプを利用して、アップコンバータのスイッチングから１００μｓｅｃ後に測定を行うことが可能である。
【００６１】
４．ホスト・コンピュータによって、「開始」イベントメッセージが同報通信される。
【００６２】
イベントマネージャの特定の実施例についてはさらに詳細に後述するが、実施態様が、この特定の実施例に制限されることを意図したものではない。
【００６３】
この説明に役立つ実施例の場合、イベントマネージャは、多くの点で、ＦＴＰサーバまたはＷｅｂサーバのような、ネットワーク・サービス・デーモンと類似しており、入力を待ち、それに従って動作する。こうした実施例の場合、イベントマネージャは、入力を処理する場合、受信専用ネットワーク・サーバであるが、出力イベントの場合、その実施例は異なる。イベントマネージャの説明に役立つこの実施例は、スレッドの集合とみなすことが可能であるが、イベントマネージャが、実際に、スレッド・モデルを用いて実施されるものと決めてかかるべきではない（これは、オペレーティング・システムによって決まる）。説明に役立つ実施例は、全てがあるタイプの入力を待っているスレッドの集合としてモデル化することが可能である。各スレッドは、その入力バッファのデータが利用可能になるまで、休止状態になる。
【００６４】
入力イベントは、通信ネットワークで到着する。イベントマネージャは、まさに他の全てのネットワーク・サーバがするように、ただイベントメッセージの到着を待つだけである。イベントメッセージが到着すると、イベントマネージャは目を覚ましてデータ・パケットを調べる。データ・パケットに、計器が応答するようにプログラムされているイベントＩＤ（さらに後述する）が含まれていると、イベントマネージャは、対応するコールバック・ルーチンを呼び出す。
【００６５】
出力イベントが内部で生じる。出力イベント（例えば、時限爆弾）は、ハードウェア割り込みの結果であることが多い。この場合、計器に用いるため、割り込みサービス・ルーチン（ＩＳＲ）がインストールされる。ＩＳＲは、イベントのタイムスタンプを捕捉し、データを記憶し、イベントマネージャの目を覚ます責務を負っており、その結果、イベントマネージャが、適正なコールバック・ルーチンを実行することになる。ＩＳＲはコールバック・ルーチンと同じではない。
【００６６】
他のイベントは、計器のハードウェア／ソフトウェア・アーキテクチャに基づいて、別様に処理することが可能である。イベントマネージャによって、任意のコールバック・ルーチンをあるイベント時に実行することが可能になり、そのコールバック・ルーチンによって、イベントを内部で処理することが可能になる。
【００６７】
この実施例の場合、イベントマネージャは、マルチキャスト・メッセージに依存している。マルチキャスト・メッセージは、通常、高信頼性のサービスになるようには設計されていないＵＤＰプロトコルによって実施される。パケットは、損失を被る可能性がある（そして被る）。イベントマネージャは、損失パケットを検出する能力を備えることが望ましいが、イベントメッセージはほとんどの測定計器において時間制約型のため、ＴＣＰのようなハンド・シェイク・プロトコルに固有のオーバヘッドを回避するのが望ましい場合も同様に多い。
【００６８】
イベントマネージャの信頼性は、下記の技法の１つ以上を用いることによって向上させることが可能である。
【００６９】
１．スイッチの慎重な選択。パケットの損失を最小限に抑えるため、高レベルの蓄積転送機能を含んでおり、ＵＤＰパケットに高優先順位を付与することができるように、ＱｏＳ機能を向上させるスイッチを選択すべきである。
【００７０】
２．イベントメッセージの冗長同報通信。イベントメッセージは、確実に受信されるように、複数回にわたって同報通信することが可能であり、受信モジュールは、同じメッセージの複数受信を無視するように構成することが可能である。信頼性を高めるためにＵＤＰパケットの冗長同報通信を利用する技法例については、その開示が参考までに本明細書において援用され、同時に提出されて譲渡先が共通の、「SYSTEM AND METHOD FOR ROBUST COMMUNICATION VIA A NON-RELIABLE PROTOCOL」と題する米国特許出願（代理人整理番号１００４１３３１−１）にさらなる記載がある。
【００７１】
３．イベントメッセージのユーザ指定時間切れ。計器が、あるイベントに対して「同意」すると、そのイベントに関する最大時間遅延が指定される。イベントメッセージが到着すると、イベントメッセージに含まれているタイムスタンプと現在の時間が比較される。その差が所定の最大値より大きければ、エラー状態が生じる。エラーは、例えば、通信ネットワークで同報通信することもできるし、あるいは、ＴＣＰ接続を介して制御コンピュータに送ることも可能である。
【００７２】
このイベントマネージャの説明に役立つ例において用いられるデータ・タイプがいくつか存在する。第１のデータ・タイプは、時間である。イベントマネージャは、２つの異なる時間ベース・データ・タイプを備えている。１つは絶対時間（TimeStamp）に関するものであり、もう１つは時間間隔（TimeInterval）に関するものである。
【００７３】
もう１つのデータ・タイプは、機能ＩＤ（「ＦＩＤ」）である。ＦＩＤは、計器のある内部機能を表わした値（例えば、１６ビットの整数）である。ＦＩＤは、計器に固有の各種機能を識別するために用いられる計器固有番号として導入することが可能である。
【００７４】
計器機能は、「入力」または「出力」として分類される。この命名法において、「出力」機能は、計器内部で生じ、その結果、イベントメッセージを他の計器に送らせることになる何かである。「入力」機能は、計器が他のどこかからのイベントメッセージに応答して実行することが可能なものである。時限爆弾は、特定のＡＰＩ操作（例えば、爆発時間（detonation time）をセットする）が存在するための特殊バージョンの出力機能である。これらの機能は、「入力イベント」及び「出力イベント」の定義に密接に対応している。厳密に言えば、「入力イベント」は、結果として「入力機能」を実行させることになるイベントである。
【００７５】
この実施例の場合、全ての計器が、下記の表１に示す例のように、ＦＩＤ値及びその記述の表を備えている。
【表１】
2006081192.tif 000003
【００７６】
留意すべきは、これらの機能の一部は、対応するハードウェア・トリガ（トリガ入力またはトリガ出力）を備えることも可能であるという点である。
【００７７】
ユーザは、ある特定の計器について、機能ＩＤをプログラムで拡張することが可能である。外部イベントに応答するように計器にプログラムする必要がある場合、例えば、新しい内部機能を表に加えることが可能である。
【００７８】
もう１つのデータ・タイプは、イベントＩＤ（「ＥＩＤ」）である。ＥＩＤは、同報通信イベントメッセージに含まれてイベントを識別するためのユーザ定義値（例えば、１６ビットの整数）である。イベントメッセージが入力されると、計器は、ＥＩＤを読み取って、応答すべきか否かを判定する（例えば、識別されたイベントが、計器がある応答動作を行うように構成／プログラムされたものであるか否かを判定する）ことになる。出力時には、計器は、他の計器がイベントの信号源計器を識別することができるように、イベントメッセージ・パケットにＥＩＤを付加する。
【００７９】
一般に、これによって、ユーザがＦＩＤ値と共に用いられるＥＩＤ値を定義することが可能になる。例えば、計器は、「時限爆弾」イベントに遭遇する可能性があり、そのイベントに対するＦＩＤは「３」である（計器にハード・コードされる）。しかし、イベントメッセージがこのイベントの結果として同報通信される場合には、ＥＩＤ値はユーザ定義が可能であり、ＦＩＤと同じである必要はない。
【００８０】
各個別計器は、ＦＩＤの大部分について省略時ＥＩＤを事前定義することが可能である。しかし、システム・インテグレータ／エンドユーザは、ＦＩＤのうち所望される可能性のある任意のものについてＥＩＤ値を設定／変更することが可能である。
【００８１】
ユーザは、例えば、テスト・システムの各計器に一意なＥＩＤを指定することが可能である。さもなければ、テスト・システムに複数の同一計器が含まれる場合には必ず問題に遭遇する可能性がある。ある特定のテスト・システムの場合、ユーザは、各計器のイベント毎に一意なＥＩＤを指定することも可能である。
【００８２】
この実施例の場合、機能ＩＤ／イベントＩＤマップが設けられる。
【００８３】
すなわち、各計器のイベントマネージャ・サブシステムはＦＩＤ／ＥＩＤマップを保持している。これは、例えば、表として実施することが可能である。この表には、ＥＩＤとＦＩＤとの間のマッピングが保持され、また、下記のような他のデータも含まれている。
【００８４】
（ａ）各機能をディスエーブル／イネーブルにするためのフラグ、
（ｂ）イベントに利用されるコールバック機能（のアドレス）、
（ｃ）問題となるイベントが入力であるか、出力であるかに関する情報。時限爆弾が出力イベントであれば、特定のＡＰＩ機能が対応付けられるので、テーブル中においてそのイベントに対する特殊なフラグを立てることが可能である。
【００８５】
（ｄ）時間切れ値。これは、入力イベントに用いられ、イベントメッセージの受信前に許容することが可能な最大遅延を表わしている。
【００８６】
計器に関するこうした表の一例が、下記の表２に提示されている。
【表２】
2006081192.tif 000004
【００８７】
表のある特定のＦＩＤは、入力または出力を表すが、両方を表わすことはない。時限爆弾は、特殊タイプの出力機能である。表２には、信号源計器１２のプログラムイベント情報１０２Ｂに納めることが可能な情報の一例が示されている。コントローラ１１及び受信計器１３のプログラムイベント情報１０２Ａ及び１０２Ｃも同様に構成することが可能である。
【００８８】
表２のイネーブル／ディスエーブル設定によって、出力イベントに関する通信ネットワークによる不必要なトラフィックが減少することになり、また、これらを利用して、入力イベントに関する関連イベントメッセージが識別される。省略時設定により、個々の計器は、全ての機能にイネーブル／ディスエーブル・フラグ状態を設定することが可能であり（ほとんどがディスエーブルになる）、各機能毎に省略時ＥＩＤを設定することが可能になる。ある特定のＦＩＤに関して複数のＥＩＤを指定する（そしてイネーブルにする）ことが可能である。これにより、イベントマネージャは、ＥＩＤのどれかを受信すれば、それに一致する機能を実行することが可能になる。
【００８９】
もう１つのデータ・タイプは、イベントメッセージ・データである。この説明に役立つ実施例によれば、イベントメッセージは、データ・フォーマットが単純であり、下記の情報を含んでいる。
【００９０】
１．イベントＩＤ
２．タイムスタンプ
３．後続バイト数
４．イベント固有データ
イベントメッセージは、SendEvent（）の呼び出しを利用して送られる。このルーチンは、ユーザ・コールバック・ルーチン内から呼び出される。イベントと共に送られるデータは、ネットワーク待ち時間問題を回避する／最小限に抑えるため、最小であることが望ましい。
【００９１】
この説明に役立つ実施例では、さまざまなＡＰＩ関数が提示される。ＡＰＩ関数の１つにＲｅｓｅｔ（）がある。この関数は、イベントマネージャをその省略時（工場出荷時）状態にする。全ての機能がディスエーブルになる。保留中の時限爆弾及びイベントメッセージがキャンセルされることになる。ユーザ定義イベントが削除されることになる。
【００９２】
もう１つのＡＰＩ関数は、GetCurrentTime（）である。この関数は、ＩＥＥＥ１５８８クロックの現在値を戻す。
【００９３】
もう１つのＡＰＩ関数は、CreateInputFn（FID）である。この関数は、特定のＦＩＤを備えた新しい入力機能を生成する。その機能は、ＥＩＤまたはコールバックを伴わないように生成され、入力機能である（出力機能または時限爆弾ではない）とみなされる。特定のＦＩＤが既に用いられているか、または、機能表を拡張するのに十分なメモリがなければ、この関数はエラーを戻し、何もしない。
【００９４】
もう１つのＡＰＩ関数は、DestroyInputFn（FID）である。この関数は、機能表から特定の機能を除去する。この関数は、特定のＦＩＤが存在しなければ、エラーを戻し、何もしない。
【００９５】
提示されるもう１つのＡＰＩ関数は、SetCallBackFn（FID，CallBackFn，CancelCallBackFn，ErrorCallBackFn，PtrToVendorData）である。この関数は、任意のＦＩＤ値に関するコールバック機能を設定する。「CallBackFn」は、あるイベントの発生時に呼び出される。出力イベントの場合、コールバック機能は、通常、イベントメッセージをフォーマットし、通信ネットワークで同報通信するが、イベントメッセージによって、コールバックの機能性が制限を受けることはない。入力イベントに関して、コールバック機能が呼び出されるのは、特定の機能にマップするイベントメッセージの受信時である。
【００９６】
機能がディスエーブルになる場合にはいつでも、「CancelCallBackFn」が呼び出される。その機能が既にディスエーブル状態の場合、このコールバックは実行されない。何らかの警告またはエラーの場合には、「ErrorCallBackFn」が呼び出される。例えば、時間調整が起こると、このＡＰＩ関数は、いくつかの時限爆弾を強制的に無視させることが可能であり、警告／エラーを生じさせることになる。このルーチンが呼び出されるようにするエラー・タイプは、一般に計器に固有のものである。ユーザが、存在しないＦＩＤにコールバックを割り当てようとする場合には、SetCallBackFnは何もせず、エラーを戻す。
【００９７】
この実施例において、コールバック機能は、下記のパラメータと共に渡される。
【００９８】
機能ＩＤ
イベントＩＤ
タイムスタンプ
ベンダ固有データ
いかなるものであろうと不要な機能呼び出しを回避するため、コールバック機能のどれでもヌルにすることが可能である。
【００９９】
提示されるもう１つのＡＰＩ関数は、SetTimeout（FID，MaxYTimeDelay）である。この関数は、イベントメッセージの受信前に許容することが可能な最大遅延を設定する。受信イベントが、MaxTimeDelayを超えて遅延すると、エラー状態が生じる。特定の機能が入力機能でなければ、この関数は何もせず、エラーを戻す。
【０１００】
MapFIDtoEID（FID，EID）は、提示されるもう１つのＡＰＩ関数である。この関数は、ある特定のＦＩＤをあるＥＩＤにマップする。ユーザが存在しないＦＩＤからのマッピングを試みると、この関数は何もせず、エラーを戻す。
【０１０１】
UnMapFIDtoEID（FID，EID）は、あるＥＩＤからある特定のＦＩＤをマップ解除するＡＰＩ関数である。これによって、マッピングが省略時状態に戻され、さらに、イベントがディスエーブルされる（後述のEnableEvent参照）。この関数は、EnableEvent呼び出し（後述する）と同様であるが、複数ＥＩＤが単一ＦＩＤにマップされ、ＥＩＤの１つだけしかマップ解除されない場合に利用される。特定のＦＩＤ／ＥＩＤ対を見つけることができなければ、この関数は何もせずに、エラーを戻す。
【０１０２】
EnableEvent（FID，EID，true/false）は、ＦＩＤまたはＥＩＤまたは両方を利用して、あるイベントをイネーブルまたはディスエーブルするＡＰＩ関数である。機能が入力であれば、その全ての発生に同意／不同意し、機能が出力であれば、その出力の全ての発生をイネーブル／ディスエーブルする。ＦＩＤまたはＥＩＤにゼロが指定されている場合、パラメータは無視されることになり、他の（おそらくは、非ゼロの）パラメータが用いられることになる。
【０１０３】
ある特定のＦＩＤが時限爆弾に相当する場合、その機能は、この関数によってイネーブルされ、CreateTimeBomb（）関数（下記参照）によって初期化される。この関数ＥｎａｂｌｅＥｖｅｎｔを利用して、時限爆弾をディスエーブルにすることが可能であり、この場合、CancelTimeBomb（）呼び出しと同じことを行う。ＦＩＤ／ＥＩＤ対を見つけることができなければ、この関数EnableEventは何もせずに、エラーを戻す。
【０１０４】
SendEvent（EID，TimeStamp，Data，Bytes）は、提示されるもう１つのＡＰＩ関数である。この関数は、イベントメッセージの同報通信を行う。それは、コールバック・ルーチン内から呼び出されることを意図したものであり、その機能がディスエーブルされている場合には呼び出すべきではないが、これによって、エラーが生じることはない。
【０１０５】
CreateTimeBomb（FID，TimeStamp，RepeatCount，TimeInterval）は、提示さるもう１つのＡＰＩ関数である。この関数は、特定のタイムスタンプから開始される反復時限爆弾をセットし、次に、特定の時間間隔を利用してRepeatCount-１回にわたって反復する（従って、爆発総数は、RepeatCountである）。無限ループの場合、RepeatCountを−１に設定することが可能である。時限爆弾が期限切れになる毎に、実行のため、CallBackFnが呼び出される。
【０１０６】
CreateTimeBomb（FID，TimeStamp，Frequency）は、上記関数の特殊バージョンであるもう１つの関数である。この関数は、repeat_count＝−１の反復時限爆弾を生成する。時間間隔は、周波数パラメータから計算される。
【０１０７】
提示されるもう１つのＡＰＩ関数は、CancelTimeBomb（FID）である。この関数は、時限爆弾をキャンセルしようとする。時限爆弾が発火前にキャンセルされるという保証はない。場合によっては、CallBackFnが、内部フラグでこれを処理することもあり得る。このCancelTimeBomb関数は、EnableEvent（）を利用して、時限爆弾機能をディスエーブルにする場合のEnableEvent（）と同じことをする。特定のＦＩＤに、セットされた時限爆弾がないか、あるいは、ＦＩＤが開始する時限爆弾ではない場合、CancelTimeBomb関数は、エラーを戻し、何もしない。
【０１０８】
GetFunctionMap（）は、ＦＩＤ／ＥＩＤマップ（上述の）に含まれる情報を戻す関数である。この関数は、例えば、デバッギングのために利用することが可能である。
【０１０９】
イベントマネージャには、通信ネットワークでコマンドを受信し、計器のローカル・プロセッサで適正なＡＰＩ呼び出しを行う、ネットワーク・デーモンが含まれている。この機能によって、（遠隔）ホスト・コンピュータは、計器に対して測定固有タスクに関するプログラミングを施すことが可能になる。制御コンピュータは、例えば計器に対して、ある特定のイベントメッセージを受信すると測定を開始するようにプログラムすることが可能である。そうするため、制御コンピュータは、計器にプログラミング・コマンドを送る。
【０１１０】
上述のように、イベントマネージャは、他の計器からの同報通信イベントメッセージも受信する。これは、この実施例のイベントマネージャに２つのネットワーク・リスナが含まれていて、１つは、他の計器からのイベントメッセージを受信し（マルチキャストＵＤＰポートで受信し）、１つは、遠隔プログラミング・コマンドを受信する（ＴＣＰポートで受信する）ことを表わしている。
【０１１１】
ネットワーク・デーモンは、ただ単にＴＣＰポートでコマンドを受信するだけである。各コマンドは、追加データを伴う可能性がある。許されるコマンドが上述のＡＰＩ関数に対応するという点に留意されたい。
【０１１２】
イベントマネージャの説明に役立つ実施例について詳細に上述したが、実施態様は、その実施例に制限されるものではない。それどころか、代替実施態様では、上述の各種特徴及び実施例の細部を変更することが可能である。例えば、実施態様によっては、ＵＤＰを介してイベントメッセージを同報通信するのではなく、ＴＣＰを利用してイベントメッセージを送ることも可能である。また、上述のイベントマネージャ例に設けられているさまざまなＡＰＩ関数例が変更可能であり、こうした関数の全てまたは一部を設けることができないかもしれず、および／または、代替イベントマネージャに追加関数を設けることが可能であるかもしれない。
【０１１３】
次に図３を参照すると、実施態様の１つに基づいて、複数のネットワーク化デバイスの動作を同期させるためのオペレーショナル・フロー図が示されている。操作ブロック３１において、イベント識別子及びタイムスタンプを含むイベントメッセージが、複数のネットワーク化デバイスの少なくとも１つによって受信されるが、この場合、デバイスのクロックは同期がとられている。上述のように、実施態様によっては、イベントメッセージは、送信側デバイスから通信ネットワーク上の他の全てのデバイスに対して同報通信される。ブロック３２では、イベントメッセージを受信した少なくとも１つのデバイスが、受信イベントメッセージによって、少なくとも１つの受信側デバイスの動作の基準となるイベントが識別されるか否かの判定を行う。上述のように、実施態様によっては、デバイスが応答動作を実施することになるイベント、並びに、デバイスがある特定のイベントについて実施することになる特定の応答動作に関して、デバイスに動的プログラミングを施すことが可能である。ブロック３３では、受信メッセージによって、少なくとも１つの受信側デバイスの動作基準となるイベントが識別されると判定されると、少なくとも１つの受信側デバイスは、受信メッセージに含まれるタイムスタンプに基づいて、識別されたイベントに従って動作する。従って、同期されたクロックに基づいて、受信側デバイスの動作と送信側デバイスとの調整をとることが可能である。
【０１１４】
本発明及びその利点について、詳述してきたが、もちろん、付属の請求の範囲で定義されている本発明から逸脱することなく、さまざまな変更、置換、及び、改変を施すことが可能である。さらに、本出願の範囲は、本明細書に記載のプロセス、機械、製造、合成物、手段、方法、及び、ステップの特定の実施態様に制限されることを意図したものではない。本開示から容易に明らかになるように、本明細書に記載の対応する実施態様とほぼ同じ機能を実施するか、または、ほぼ同じ結果を実現する、現存する、または、今後開発されることになるプロセス、機械、製造、合成物、手段、方法、または、ステップを利用することも可能である。従って、付属の請求の範囲は、その範囲内に、こうしたプロセス、機械、製造、合成物、手段、方法、または、ステップを包含することを意図したものである。
【図面の簡単な説明】
【０１１５】
【図１】複数のネットワーク化デバイスの動作を同期させるための実施態様の１つによるシステム例を示す図である。
【図２】複数のネットワーク化デバイスの動作を調整させるために図１のシステムにおいてメッセージ・ベースの技法を利用する特定の例を示す図である。
【図３】実施態様の１つによる複数のネットワーク化デバイスの動作を同期させるためのオペレーショナル・フロー図である。
【符号の説明】
【０１１６】
１２、１３  デバイス
１４  通信ネットワーク
１０１Ｂ、１０１Ｃ  イベントマネージャ
１０３Ｂ、１０３Ｃ  クロック
【図１】
2006081192.tif 000005
【図２】
2006081192.tif 000006
【図３】
2006081192.tif 000007