JP2003526223A

JP2003526223A - 通信システム用開発およびテストツール

Info

Publication number: JP2003526223A
Application number: JP2000512312A
Authority: JP
Inventors: マークスジョアンヌズスクミドット
Original assignee: コミュニケイションアンドコントロールエレクトロニクスリミテッド
Priority date: 1997-09-12
Filing date: 1998-09-14
Publication date: 2003-09-02
Also published as: WO1999014891A2; EP1013033A2; WO1999014891A3

Abstract

(57)【要約】開発システムは、機能しているネットワークでデバイスをエミュレートするために、ハードウェアネットワークインタフェースとともに使用される再使用可能なコンピュータに実装された構成要素を含む。この構成要素は、ネットワークトラフィックのシミュレートと分析および適合検証するためのツールを提供することができる。これらの構成要素は、クライアントプログラムとネットワークインタフェースハードウェアの間のインタフェースを提供する。これらは、ＣＤチェンジャやアンプ、音声−画像制御装置等のデバイスに特有のアプリケーションレベルのプロトコルを規定する、プロトコルデータベースを含む。提案するツールは、ユーザ（クライアントプログラム）から命令されたコマンドを、それらがエミュレートされたデバイスの特定の型について規定されたプロトコルと矛盾する場合に、フィルタリングする機構を提供する。これらの構成要素は、ネットワーク管理やソースデータの接続経路指定等の、標準的な挙動を自動的に実装するプログラムモジュールを含む。特定のプロトコルを利用する全てのネットワーク構成に汎用なアプリケーションプロトコルに加えて、ツールは、正常コマンドの範囲をさらに限定するために、ネットワーク上に存在するまたはエミュレートされるデバイスの特定の数および型を規定するネットワークシステムの記述を記憶する。

Description

【発明の詳細な説明】

【０００１】本発明は、ローカル通信システム中で使用され、開発およびテスト用装置で使
用するハードウェアまたはソフトウェアに実装される開発ツールに関する。本発
明は特に、例えば消費者の音声／ビデオネットワーク中で、低レベルの通信プロ
トコルだけでなく、より高レベルなアプリケーションプロトコルにも実装される
製品の開発に関する。

【０００２】低コストのファイバネットワーク中でソースデータ（ＣＤ音声やＭＰＥＧビデ
オ、電話音声など）を制御メッセージと結合するローカル通信システムは、Ｄ２
ＢＯｐｔｉｃａｌの形式で提案されている。詳細については、例えばＣｏｍｍ
ｕｎｉｃａｔｉｏｎ＆ＣｏｎｔｒｏｌＥｌｅｃｔｒｏｎｉｃｓＬｉｍｉ
ｔｅｄ、２ＯｃｃａｍＣｏｕｒｔ、ＯｃｃａｍＲｏａｄ、ＴｈｅＳｕｒ
ｒｅｙＲｅｓｅａｒｃｈＰａｒｋ、Ｇｕｉｌｄｆｏｒｄ、Ｓｕｒｒｅｙ、Ｇ
Ｕ２５ＹＱ（ｈｔｔｐ：／／ｗｗｗ．ｃａｎｄｃ．ｃｏ．ｕｋ）から入手可能
な、「ＣｏｎａｎＴｅｃｈｎｏｌｏｇｙＢｒｏｃｈｕｒｅ」および「Ｃｏｎ
ａｎＩＣＤａｔａＳｈｅｅｔ」を参照されたい。また、ＢｅｃｋｅｒＧ
ｍｂＨのヨーロッパ特許出願ＥＰ−Ａ−０７２５５１６（９５Ｐ０３）、ＥＰ−
Ａ−０７２５５１８（９５Ｐ０４）、ＥＰ−Ａ−０７２２５５１５（９５Ｐ０５
）、ＥＰ−Ａ−０７２５５２０（９５Ｐ０６）、ＥＰ−Ａ−０７２５５２１（９
５Ｐ０７）、ＥＰ−Ａ−０７２５５２２（９５Ｐ０８）、ＥＰ−Ａ−０７２５５
１７（９５Ｐ０９）、およびＥＰ−Ａ−０７２５５１９（９５Ｐ１０）も参照さ
れたい。「Ｃｏｎａｎ」はＣｏｍｍｕｎｉｃａｔｉｏｎ＆Ｃｏｎｔｒｏｌ
ＥｌｅｃｔｒｏｎｉｃｓＬｉｍｉｔｅｄの登録商標である。本記述はさらに、
本発明者等の同時係属の出願ＰＣＴ／ＧＢ９８／００３４９（６２７９３ＷＯ）
に記載の、倍速インタフェース（ｄｏｕｂｌｅｓｐｅｅｄｉｎｔｅｒｆａｃ
ｅ）も参照する。

【０００３】通常はソフトウェアとインタフェースハードウェアの組合せを含むツールとし
ては、一般にパーソナルコンピュータ（ＰＣ）または、このようなネットワーク
中で使用するために開発中の製品をエミュレートすることができ、既に開発され
ている現実の製品を検証／テストすることができるその他のデバイスが知られい
る。本発明は、このような開発ツールの有用性を改善することを目的とするもの
である。適用分野としては、ユーザインタフェースおよび高レベル制御機構も含
めた新製品の製造前のシミュレーション、および現実の製品の検証／互換性テス
トがある。開発中のシステムの性質として、異なるタイプのいくつかのユニット
が同時に開発されることがあり、またそれらの機能要件の定義およびデバッギン
グが非常に複雑になる。特に、ネットワーク中のあるデバイスの故障が、別のデ
バイスで望ましくないふるまいとして現れ、診断を困難にすることがある。

【０００４】本発明は、第１の態様で、添付の請求項１で規定するシステムを提供する。別
の態様では、本発明は、ハードウェアネットワークインタフェースとともに使用
されるコンピュータに実装された構成要素を含むツールを提供し、前記ツールの
構成要素は、ユーザまたはクライアントプログラムとネットワークインタフェー
スとの間のインタフェースを規定する。このツールは、少なくとも１つのアプリ
ケーションプログラムインタフェース（ＡＰＩ）と、プロトコルデータベースお
よび／またはシステムモデルと、このデータベース／モデルを参照することによ
ってユーザまたはクライアントプログラムからのメッセージおよびイベントを処
理する構成要素とを組み込む。ネットワークに送信されたまたはネットワークか
ら受信した違法メッセージを検出するためである。

【０００５】特に、ＣＤチェンジャ、アンプ、音声／ビデオ制御装置などのデバイスに特有
のアプリケーションレベルのプロトコルは、Ｄ２ＢＯｐｔｉｃａｌシステムと
して定義されている。提案するツールは、ユーザ（クライアントプログラム）か
ら命令されたコマンドを、フィルタリングする機構を提供する。ここではエミュ
レートされた特定タイプのデバイスについて規定されたプロトコルと矛盾する場
合である。一般に、アプリケーションプロトコルは、単なる通信管理またはネッ
トワーク管理のタスクと関係するのではなく、ネットワークに接続されたデバイ
スの本質的な機能と関係するプロトコルである。

【０００６】一般に、プロトコルは、特定の製品設計者の必要に応じて、彼または彼女自身
の設計した挙動を達成するために個別のメッセージおよび応答のフォーマットを
規定することができるが、プロトコルには挙動のシーケンスを規定する領域が存
在し、特にネットワーク中の複数のステーション間の拡張された協調動作が必要
な場合に、設計結果を達成する必要がある。例としては、ネットワーク管理（初
期化）、および少なくともＤ２ＢＯｐｔｉｃａｌにおいて、ソースデータの接
続管理がある。このツールは、これらの標準的な挙動を自動的に実施するための
プログラムモジュールを含むことができるために、ツールのユーザが自分のアプ
リケーションの標準部分を明示的にコーディングする必要はない。

【０００７】本明細書に与える実施形態では、このツールを含むプログラムモジュールは、
所定の規則に従って互いにメッセージを交換するオブジェクトの形をとる。いく
つかのオブジェクトは、同一コンピュータハードウェアの中で動作している異な
るアプリケーション間で共用することができ、その他のオブジェクトは単一の動
作中のアプリケーションのために予約される。したがって、開発システムは、異
なるクライアントアプリケーションを提供する、予約された各オブジェクトクラ
スのいくつかのインスタンスを含むことができる。共用されるオブジェクトは、
特に、ツールシステム（ハードウェアドライバ）の特定のインタフェースハード
ウェアに対するインタフェースを提供するオブジェクトを含むことができる。特
定の「システムインスタンス」に確保されるオブジェクトは、複数のネットワー
クデバイスを単一のコンピュータで、完全に独立してエミュレート、テスト、ま
たは制御することができる。

【０００８】特定のプロトコルを利用する全てのネットワーク構成に汎用なアプリケーショ
ンプロトコルに加えて、ツールは、特定の数およびネットワーク上のまたはエミ
ュレートされるデバイスのタイプを規定するネットワークシステムの記述を記憶
し、正常コマンドの範囲をさらに限定することができる。

【０００９】本発明はさらに、添付の図面に関連しておよそ本明細書に記述する、製品をエ
ミュレートおよびテストする方法も提供する。このシステムのプログラムおよび
ハードウェア構成要素は、合わせて提供することも別々に提供することもでき、
また既存の汎用コンピュータとともに使用される構成要素として提供することも
できることを理解されたい。

【００１０】（好適実施形態の詳細な説明）（Ｄ２ＢＯｐｔｉｃａｌシステムの概要）例示のみを目的として、Ｄ２ＢＯｐｔｉｃａｌネットワークに適用する本発
明の様々な態様について説明する。背景として、このネットワークの性質および
動作について最初に簡単に述べる。

【００１１】図１に示すシステムは、ローカルエリアネットワーク（ＬＡＮ）のステーショ
ン（またはノード）として接続された、音声または画像と関連する９個の装置１
０１〜１０９を含む。言うまでもなく、９個より多いまたは少ないステーション
を収容することもできる。この例のシステムでは、これらの装置は、制御および
表示ユニット１０１、コンパクトディスクメモリ（ＣＤ−ＲＯＭ）読取り装置１
０２、ラジオチューナ１０３、ＣＤチェンジャユニット１０４、オーディオパワ
ーアンプ１０５、ファクシミリ送受信ユニット（ＦＡＸ）１０６、画像記録シス
テム（ＶＣＲ／ＣＡＭＣＯＲＤＥＲ）１０７、ビデオチューナ１０８、および電
話１０９である。制御および表示ユニット１０１の表示機能は、例えば、ＣＤ−
ＲＯＭによるメモリデバイスから読取った情報の表示、および／あるいはチュー
ナ１０８またはＶＣＲ１０７からのビデオ信号の表示を行うことができる。

【００１２】既知のシステム中のＬＡＮの相互接続は、９本の一方向性ポイントツーポイン
ト光ファイバリンク１１１、１１２など、および連結インタフェースモジュール
１２１などを含み、これらはそれぞれ構造的にほぼ同じであるので、全てのノー
ドが環状に接続されるようになっている。各光ファイバリンクは、以下で詳細に
述べるフレーム構造に従って、デジタル音声／画像信号、ＣＤ−ＲＯＭデータ、
および制御メッセージの組合せを搬送する。制御／表示ユニット１０１など、指
定されたステーション（以下システムマスタと呼ぶ）は、２０〜５０ｋＨｚ（Ｃ
Ｄの標本化の場合は通常４４．１ｋＨｚ）のフレームサンプリングレートで連続
的にフレーム構造を生成する。スタートアップ時にネットワーク上のあるステー
ションがシステムマスタとして動作するように指定されるが、システムマスタの
役割は、その後、例えば後述のような障害状態にあるときに、別のステーション
に再割当することができる。

【００１３】ステーションの光ファイバリングとのインタフェースの実施態様を、図２に概
略的に示す。リング１１９〜１１１から、メディアアクセス制御（ＭＡＣ）／物
理層３００が、制御メッセージのための通信管理層３０２とともにインタフェー
スモジュール１２１中に設けられる。通信管理層３０２は、アドレスの初期化お
よび検証を管理し、規定されたタイミング規則に従って再送することによって、
信頼性の高いメッセージの送達を保証する。ソースデータ３０４のデータ処理お
よび制御メッセージ３０６は、アプリケーションプロトコルとともにステーショ
ンレベル１０１で提供される。このアプリケーションプロトコルは、通常は、そ
のステーションのデバイス／サブデバイスのグループ化および制御階層と、製品
間で交換される情報のフォーマットと、デバイス／サブデバイスの挙動と、アプ
リケーションレベルのタイミングとを規定する。インタフェースモジュール１２
１は、例えばＣｏｎａｎ集積回路、または同様のネットワークトランシーバおよ
びそれと関連する制御ソフトウェアの形で、物理的にステーション内に存在する
ことができることは容易に理解されるであろう。

【００１４】図３に示すように、同様のインタフェースモジュール１２３は、ラジオカセッ
トプレーヤー１０３の中の１つの機能として提供され、アンプ３１０、チューナ
３１２、テープ再生デッキ３１４、音声／画像制御装置（ＡＶＣ）３１６、およ
びユーザＩ／Ｏ３１８の機能も有する。これらの機能およびそれらの相互接続は
本発明とは直接の関係がなく、図示していない。それらの実施態様は、当業者に
は容易に分かるであろう。

【００１５】図４は、ステーションを既知の光ファイバリングに連結するインタフェースモ
ジュール１２１（この場合にはノード１２１）を示す概略図である。ＬＡＮに接
続された全てのステーションは、ソースデータ（３つ以下のチャネルＳＤ０〜Ｓ
Ｄ２）および制御データ（ＣＴＲＬ）を生成し、かつ／または受信することがで
きる。制御データは小容量であり、バースト的に到着し、かつユーザ／イベント
駆動（例えばユーザ命令や状態変化など）であるが、ソースデータは連続した大
容量のストリーム（例えば音声や圧縮画像、ＣＤ−ＲＯＭデータなど）である。

【００１６】Ｄ２ＢＯｐｔｉｃａｌシステムでは、ソースデータおよび制御メッセージは
、システムマスタとして指定されたステーションが生成したフレームで、ネット
ワーク上でノードからノードに伝達される。フレームは、音声標本化周波数、通
常はｆｓ＝４４．１ｋＨｚと同じ速度で循環する。フレームは、４８個のフレー
ムからなるブロックにグループ化される。

【００１７】図５は、各ネットワークフレームがどのようにして２つのサブフレーム（「左
側」および「右側」）に分割されるかを示す図である。ｆｓ＝４４．１ｋＨｚで
は、毎秒８８，２００個のサブフレームが存在することになる。左側のサブフレ
ームは、常にネットワーク上を伝送される対の先頭となる。物理レベルでは、ビ
ットは２相符号化されて伝達される。ブロック、フレーム、サブフレーム、およ
び制御フレームの間の関係を図５に示す。

【００１８】図６は、各サブフレームが、トランシーバ内で８バイトフィールドとして処理
される６４個のビットを、どのように含むかを示す図である。フィールドは、プ
リアンブルと、透過チャネルと、６バイトのソースデータと、制御フレームおよ
びＳＰＤＩＦ状態ビットを構成する８ビットの制御／状態ビットとを含む。次に
、様々なフィールドの意味について詳細に述べる。

【００１９】図６のサブフレーム構造のフィールドは下記の通りである。・プリアンブル：プリアンブルは、ネットワークでの受信の同期をとる。プリ
アンブルには３つのタイプがあり、ＩＥＣ−９５８（ＳＰＤＩＦ）仕様で規定さ
れたものと同様である。これらは、受信器が識別できる２相の符号則違反を含む
。３つの一意的なプリアンブルは、左側サブフレーム、右側サブフレーム、およ
びサブフレームのブロックを識別する。左側プリアンブルはフレームの開始を識
別し、ブロックプリアンブルはブロックの開始を識別する。ブロックプリアンブ
ルは、左側プリアンブルが４８番目になるたびにこれと置き換わる。これにより
、制御フレームデータが同期するブロック構造がもたらされる。

【００２０】・ソースデータバイト：ソースデータバイトは、大容量の実時間デジタルソー
スデータを搬送する。これらのバイトはフレキシブルに割り振ることができ、シ
ステム中のデバイスが、そのシステムにとって最も効率的な方法でソースデータ
バイトを使用することができる（ＥＰ−Ａ−０７２５５２０およびＥＰ−Ａ−０
７２５５２１を参照されたい）。

【００２１】・制御ビット：制御ビットＣＦ０およびＣＦ１は、（デバイスを制御し、状態
情報を送信するための）制御メッセージを搬送する。サブフレームごとに２つの
ＣＦビットが存在し、制御フレームは１９２ビットの長さであり、従って、完全
な制御フレームを構築するためには９６個（左側４８個＋右側４８個）のサブフ
レームが必要となる。制御フレームは、図７に示してある。

【００２２】図５に示すように、制御フレームは、９６個のサブフレームのブロックから組
み立てられ、これと位置合わせされる。すなわち、新しい制御フレームの最初の
２ビットは、ブロックプリアンブルを有するサブフレームからとり、後続のビッ
ト対は後続のサブフレームからとって、制御フレームを構築する。制御フレーム
のフィールドは、下記の通りとなる。

【００２３】・調停（ａｒｂｉｔｒａｔｉｏｎ）ビット：これらは、制御フレームが空いて
いるか占有されているかを示す。送信器は、これらのビットを自動的に処理する
。

【００２４】・送信先アドレス：これは、′０００′Ｈから′ＦＦＦ′Ｈの範囲の、メッセ
ージの宛先の１２ビットアドレスである。送信側デバイスは、これを送信バッフ
ァから伝達されるメッセージ中に書き込む。いくつかのアドレスおよびアドレス
範囲は特殊な意味を有し、リング位置、またはアプリケーションと関連する「デ
バイスアドレス」によって、ステーションのアドレス付けをすることができる。
ブロードキャストおよび「グループキャスト」も提供される。

【００２５】・送信元アドレス：これは、′０００′Ｈから′ＦＦＦ′Ｈの範囲の、メッセ
ージの送信側の１２ビットアドレスである。受信側デバイスは、受信バッファに
受信した、そのメッセージからこれを読取ることができる。

【００２６】・メッセージのタイプおよび長さ：メッセージのタイプ／長さを示すために通
常使用される、２つの４ビットフィールドである。メッセージのタイプは、コマ
ンド、状態通知、および状態通知要求を含む。

【００２７】・データ０から１５：メッセージデータである。すべての１６バイトが、常に
伝達される。メッセージの長さは、通常は、１６バイトのうちのどの程度が実際
にそのメッセージで有効であるかを示す。送信側デバイスは、これを送信バッフ
ァから伝達されるメッセージ中に書き込む。受信側デバイスは、受信バッファに
受信した、そのメッセージからこれを読取ることができる。メッセージは、通常
は、演算コードおよび１つまたは複数のオペランドを含む。

【００２８】・ＣＲＣ：制御フレームがエラーなしで伝達されていることを検証するために
使用される、１６ビットの巡回冗長検査の値である。ＣＲＣは、メッセージ伝送
時にインタフェースモジュールによって自動的に生成され、メッセージ受信時に
自動的に検査される。

【００２９】・ＡＣＫ／ＮＡＫ：肯定応答および否定応答（それぞれ２ビット）は、メッセ
ージの伝達が成功したことを示す。本発明者等の出願ＧＢ−Ａ−２３０２２４３
に記載されているように、別個のＡＣＫフラグおよびＮＡＫフラグを使用するこ
とにより、信頼性の高いポイントツーポイントおよびブロードキャストのメッセ
ージ伝達が可能となる。これらのフラグは、送信先デバイス（存在する場合）に
よって自動的に満たされ、送信側デバイスによって読取られる。

【００３０】・予約：１０ビットが、将来的に規定されるために予約されている。

【００３１】（製品開発システムの概要）本明細書に記載の新しい製品開発環境は、個々の製造業者またはシステムイン
テグレータが、製品および／または自社または他社の製品とともに動作できる完
全なネットワークシステムの、開発ならびにテストを補助するために使用するこ
とができる。特に重要なものは、図７の制御フレーム機構を介して制御メッセー
ジおよびデータを交換するためのプロトコルの適切な実装である。Ｄ２ＢＯｐ
ｔｉｃａｌの仕様は、メディアアクセス層からアプリケーション層のいくつかの
プロトコルを（ＩＳＯ／ＯＳＩネットワークモデルの用語を使用して）規定する
。換言すれば、ネットワークを初期化し、制御フレームメッセージ（以下Ｄ２Ｂ
メッセージと呼ぶ）を交換するための機構が規定されるだけでなく、目的の範囲
においてメッセージの特定の内容および意味も規定される。

【００３２】例えば、ネットワーク管理レベルでは、各ステーションがＤ２Ｂメッセージを
受信するための一意的なアドレスを獲得できるように、手続きおよびメッセージ
のフォーマットが規定される。アプリケーションレベルでは、メッセージは、ネ
ットワークに接続されたアンプのボリューム設定を増加させたり、または各ネッ
トワークフレーム（図５）中のソースデータフィールドのいくつかのバイトで搬
送される音声データストリームを再生するように切り替えることができるように
規定される。同時に、最大限の自由が意図され、どのような種類の製品がネット
ワークに接続されても、製造業者が独自の好ましい機能を実装することができる
。

【００３３】図８は、新しい製品開発システムの概要を与える図あり、これは特に、ＰＣ上
で動作する様々なソフトウェア構成要素を含むソフトウェアエンジン８００と、
一または複数の異なる種類のインタフェースボード（「ＯｐｔｉｃａｌＰｏｗ
ｅｒＢｏａｒｄ」（ＯＰＢ）８０４および「ＡｄｖａｎｃｅｄＯＰＢ」（Ａ
ＯＰＢ）８０６）を載架するインタフェースボードラックシステム８０２とを含
む。各インタフェースボードは、上述のＣｏｎａｎチップなど、１つまたは複数
のネットワークトランシーバの集積回路を含む。開発システムエンジン８００は
、以下でさらに詳細に述べる、様々なプログラムモジュールおよびデータベース
モジュール８１２から８３６を含む。システム制御モジュール８３２は、クライ
アントアプリケーションプログラム８１０に、アプリケーションプログラムイン
タフェース（ＡＰＩ）を提供する。クライアントアプリケーション８１０は、こ
の開発システムを備えた標準アプリケーションにすることも、開発中の所与の製
品をエミュレートするために特別に開発することもできる。

【００３４】この実施形態の開発システムエンジン８００は、低レベルおよび高レベルのＤ
２ＢＯｐｔｉｃａｌの標準速または倍速の通信、ならびにＣｏｎａｎ製品のこ
れらＩＣの制御の両方とも提供する汎用サーバである。

【００３５】開発システムエンジンは、実際には、ＡｃｔｉｖｅＸなど、高度な最新のソフ
トウェア設計技術を使用した、プログラマブルソフトウェア構成要素の組合せで
ある。これにより最大限のフレキシビリティがもたらされ、明確に定義されたア
プリケーションプログラムインタフェース（ＡＰＩ）を介してアクセスされる、
全てのプログラムおよびアプリケーションについて高度の機能的信頼性を保持さ
れる。エンジン８００は、Ｄ２ＢＯｐｔｉｃａｌアプリケーションを書き込む
ことをきわめて容易にする設計システムである。これは、トランシーバＩＣを操
作し、Ｄ２ＢＯｐｔｉｃａｌ制御メッセージで通信するための汎用機能を提供
する。これは、ＶｉｓｕａｌＢａｓｉｃ、ＶｉｓｕａｌＣ＋＋、Ｂｏｒｌａ
ｎｄＤｅｌｐｈｉなど、ＡｃｔｉｖｅＸをサポートする任意の環境を使用して
プログラムすることができる。

【００３６】このエンジンは、例えばＤ２ＢＯｐｔｉｃａｌデバイスをエミュレートし、
または現実のＤ２ＢＯｐｔｉｃａｌ製品をテスト／検証するために使用するこ
とができ、また、言うまでもなくその他のプロトコルに適合させることもできる
。エミュレーションだけでなく、この開発システムを形成する同じ構成要素で、
ネットワークトラフィックをシミュレートおよび／または解析し、製品が標準プ
ロトコルを遵守しているかを検証するための、共通のフレームワークを提供する
ことができる。

【００３７】ネットワーク上の現実の製品と同様に、ソフトウェア構成要素とともに使用さ
れる各インタフェースボードは、１つまたは複数のネットワークトランシーバの
集積回路を載架する。ＡｄｖａｎｃｅｄＯＰＢ８０６は、いくつかのネットワ
ークインタフェースボードが、「デイジーチェーン」配列でラックシステム８０
２を介して接続するため、１つのネットワーク中の複数のデバイスまたは複数の
別個のネットワークを、同一ＰＣからシミュレートまたはテストすることができ
る機構を提供する。以下で、ソフトウェアツールのアーキテクチャについて、い
くらか詳細に述べる。理解の助けとなるように、使用中のシステムを示す２つの
図を最初に与える。

【００３８】図９の例では、開発システムソフトウェアは、ＲＳ−２３２シリアルケーブル
９１０によって、１つまたは複数のネットワークトランシーバの集積回路である
インタフェースボード９２０に接続された、ポータブルＰＣ９００上で動作して
いる。このセットアップは、例えば、開発中のＤ２ＢＯｐｔｉｃａｌ電話をシ
ミュレートするために使用することができる。デバイスの製造業者は、現実の製
品の完全な挙動モデルを例えば「Ｃ」プログラムで実装することができ、概念／
設計を検証した後で、同じコードを現実の製品中の組込み型マイクロコントロー
ラに転送することができる。図１の大規模ネットワーク中の構成要素に関して言
うと、製品１０１（ヘッドユニット）、１０４（ＣＤチェンジャ）、および１０
５（アンプ）が存在しており、開発システムは電話製品１０９のエミュレーショ
ン１０９′を提供する。

【００３９】図１０では、システムソフトウェアは、ＲＳ−２３２リンク１０１０を使用し
てＯＰＢラックシステム１００２に接続された、異なるＰＣ１０００上で動作し
ている。ＯＰＢラックシステム自体は、ラック内で「デイジーチェーン」となっ
た５個のＯＰＢのホストとなる。このシステムは、Ｄ２ＢＯｐｔｉｃａｌイン
タフェースを含む製品の、その製品が合意された互換性レベルを確実に満たすた
めの、所定の基準セット（プロトコルおよび基本機能の挙動の検証（再生や停止
など）など）に対する適合性をテストすることができる。これは、製品サイクル
のどの段階でも、システムインテグレータまたは製品開発エンジニアを補助する
ために使用することができ、低レベルおよびアプリケーションプロトコルレベル
の両方で、Ｄ２ＢＯｐｔｉｃａｌまたはその他の適用可能な仕様に対する製品
の適合性を高い確度で識別することによる。図１の参照番号を使用して、テスト
中の５個のＣＤチェンジャ製品１０４−１〜１０４−５を示す。

【００４０】このようなシステムの利点は下記の通りである。・テストおよびテストシーケンスの両方、ならびにテストに対する応答および
不整合性の報告が予め決められているので、品質検査および妥当性検査の確度お
よび再現性が改善される。

【００４１】・自動テスト能力によって製品開発サイクルが短縮される。開発された製品が
システム中で正しく機能するか否か、またＤ２ＢＯｐｔｉｃａｌまたは他の要
求されたプロトコルが、所定のレベルまで機能するか否かを、機器が専門のテス
トエンジニアより正確にかつはるかに速く検査することができるからである。

【００４２】・生産ライン上および／または生産された製品のサンプルまたは全てについて
、所定のテストサイクルに基づいて製品を検査することができる。

【００４３】・テストエンジニアが、以前に検査したデバイスが修理され、「修理」サイク
ルの後で、合意された標準に合わせて機能するかどうかを識別することができる
。

【００４４】（開発システムのソフトウェア構造：導入）インタフェースボードに加えて、開示のツールは、クライアントアプリケーシ
ョンにサービスを提供するために統合され、相互に影響する、ソフトウェア構成
要素のシステムを含み、それらのアプリケーションが、ＭｉｃｒｏｓｏｆｔＷ
ｉｎｄｏｗｓオペレーティングシステムから、Ｄ２ＢＯｐｔｉｃａｌネット
ワーク内で動作し、これを使用し、制御することができるようにする。

【００４５】以下で、このツールシステムのためのソフトウェアアーキテクチャについて述
べる。システムはオブジェクト指向法で設計されるので、オブジェクトの一般的
な設計、それらの目的、および全体的なシステムの他の部分との対話について議
論することには意味がある。詳細な設計は、設計ツールＲａｔｉｏｎａｌＲｏ
ｓｅで実行されるが、代替ツールも同様に適している。

【００４６】（設計目標）設計は、下記のことを念頭に置いて実行される。・その最終目標が、Ｄ２ＢＯｐｔｉｃａｌおよびそれと同様の技術を利用す
るためのソフトウェアおよび／またはファームウェアの開発を容易にすることで
ある、ソフトウェア構成要素のファミリを生成すること。

【００４７】・低レベル制御（例えばハードウェアと直接対話する）から非常に高レベルな
制御（例えば自動化されたデバイスの挙動）まで、様々なレベルの制御をユーザ
に与えるようなかたちで、その範囲の構成要素を設計すること。

【００４８】・構成要素を階層的に設計し、より高レベルな構成要素が、その下にあるより
低レベルの構成要素のサービスを利用するようにすること。これにより、構成要
素およびソフトウェアを最大限に再利用することが可能となる。

【００４９】・構成要素自体を拡張可能かつ柔軟にし、新たな要件が将来発生した場合に、
それらの新しい変更形態を容易に作成できるようにすること。

【００５０】・構成要素のエンドユーザをハードウェアから抽象化すること。これにより、
ユーザは、その基礎となるハードウェアについて心配することなく、またいつそ
のソフトウェアを書き込むかを考慮する必要なく、ソフトウェアを書き込むこと
が可能となる。

【００５１】・構成要素を利用するための簡単かつ分かりやすいインタフェースをユーザに
提供すること。

【００５２】・その他のエミュレータ、コンプライアンスチェッカ、およびユーザ定義（専
有の）エミュレータに、その基礎となる信頼できるアーキテクチャを提供するこ
と。

【００５３】・以下で説明する、自動応答システムを提供すること。

【００５４】（クラス設計）以下のセクションでは、この設計のオブジェクトについて論じる。この考察は
一般的なものであるが、必要な箇所は具体的にしてある。当業者には周知のオブ
ジェクト指向アーキテクチャの用語では、「オブジェクト」の様々な「クラス」
が定義される。各クラスの１つまたは複数の「インスタンス」は、明確に定義さ
れた方法で別個の「オブジェクト」として互いに作用し、対話することができる
。図８は、階層的なクラスを示しており、「低レベル」構成要素は最下部に、よ
り高レベルな構成要素は最上部にある。これらの構成要素または「オブジェクト
」は、メッセージの交換によって対話することができる。矢印は、システム内の
通信の主な流れを説明している。

【００５５】（ＯＰＢドライバ８１２）ＯＰＢドライバ８１２のオブジェクトは、実際のネットワークトランシーバの
ハードウェアとの最低レベルのインタフェースを提供する。各オブジェクトは、
特定のインタフェースボードの型、例えば並列、直列構成、Ａ−ＯＰＢ等とのＡ
ＰＩ（アプリケーションプログラムインタフェース）を提供する。ＯＰＢドライ
バクラスは、低レベル通信および制御機構の知識をカプセル化し、それらの機能
にアクセスするためのオブジェクト指向インタフェースを提供する。さらに、各
クラスが、それがカプセル化したドライバ中のエクスポート関数それぞれについ
てメンバ関数を提供すれば、既存のアプリケーションを将来的にクラスを使用す
るために改変することができる。

【００５６】任意の新しいインタフェースボード（例えばＵＳＢまたはＰＣＩインタフェー
スを備えた）が開発されると、その新しいインタフェースボードを実際に制御す
るドライバについて、新しいＯＰＢドライバのクラスも再度設計しなければなら
なくなる。

【００５７】（ＯＰＢ８１４）ＯＰＢクラスは、エンドユーザのアプリケーションおよび開発システム自体が
、ＯｐｔｉｃａｌＰｏｗｅｒＢｏａｒｄファミリィの中のハードウェアボー
ドを制御するために使用するクラスである。従って、ユーザが利用できる機能は
、ＯＰＢクラスがそのＡＰＩの中で表明する（ｅｘｐｏｓｅ）機能に制限される
。ＯＰＢオブジェクトはそれぞれ、関連する型のＯＰＢドライバオブジェクトに
接続される。ＯＰＢオブジェクトは、ドライバオブジェクトを使用して、ＯＰＢ
ファームウェアとの実際の通信を実行する。ＯＰＢオブジェクトは、ディレクタ
構成要素（以下参照）によって、ＯＰＢドライバへのアクセスを与えられる。デ
ィレクタ構成要素は、全てのＯＰＢオブジェクトを作成し、最終的に破棄するオ
ブジェクトである。

【００５８】ＯＰＢクラスの主な目的は、ＯＰＢハードウェアとエンドユーザの間に抽象化
の階層を提供することである。これにより、ユーザは、汎用ソフトウェア機構を
使用して、任意の構成におけるＯＰＢの任意の型を制御することが可能となる。
その結果として、ユーザソフトウェアの複雑さが軽減される。この抽象化は、全
てのＯＰＢクラスが関数の共通のインタフェースを実装することを保証すること
によって実現される。この場合、ユーザは、プログラムでこのインタフェースを
使用して、ＯＰＢオブジェクトを制御する。ユーザは、ＯＰＢを制御するために
ＯＰＢの型またはその構成を知っている必要はない。

【００５９】抽象化のその他の大きな利点は、インタフェースボード（例えばＵＳＢ、ＰＣ
（ＰＣＭＣＩＡ）、ＰＣＩ、またはＩＳＡバスを介して）と通話するために新し
い通信機構が開発する場合に、この新しい構成中のＯＰＢと通話するために、Ｏ
ＰＢクラスのソフトウェアをいかなる形でも改変する必要がないことである。そ
れよりむしろ、どのようにしてこの新しい機構を使用して通信するかについての
必要な知識をカプセル化する、新しいＯＰＢドライバクラスを単に使用すること
になる。

【００６０】ＯＰＢクラスは、現実の物理的インタフェースボードをソフトウェアの形で表
そうと試みる。物理的ＯＰＢは、ネットワークトランシーバや音声コーデックＩ
Ｃ、マイクロコントローラファームウェアなどの構成要素を含む。これらは、Ｄ
２ＢＯｐｔｉｃａｌの開発者が、操作および制御したいと望む構成要素である
。従って、ＯＰＢクラスは、対応するハードウェア構成要素を表す補助的なソフ
トウェア構成要素も含む。これらのソフトウェア構成要素は、本質的にクラスで
ある。このシステムでは、このような４つのクラスを定義する（以下でより詳細
に述べる）。・ネットワークトランシーバ８１６・コーデック８１８・ネットワーク管理８２０・インタフェースファームウェア８２２

【００６１】ＯＰＢオブジェクト８１４は、補助的な構成要素オブジェクトを作成し、これ
は、インタフェースボードの型およびどのハードウェアが実際のＯＰＢ上にある
かに依存している。これは、ＯＰＢオブジェクトのユーザに、そのＡＰＩ中の機
能を介したこれら他の構成要素オブジェクトを与える。ユーザは、適当な構成要
素オブジェクトを使用して、物理的インタフェースボード上のハードウェア構成
要素の機能にアクセスすることができる。

【００６２】一例として、インタフェースボードにおけるＯＰＢの型は、音声コーデックＣ
Ｓ４２２５ＩＣおよびネットワークトランシーバＯＣＣ８００１ＩＣの上に有る
。ＯＰＢオブジェクト８１４が作成されたときに、ネットワークトランシーバオ
ブジェクト８１６およびコーデックオブジェクト８１８を作成する。ＯＰＢクラ
スは、これらのオブジェクトへのアクセスを可能にするために、そのＡＰＩ中の
関数ＧｅｔＣｏｍｐｏｎｅｎｔ（“ＮｅｔｗｏｒｋＴｒａｎｃｅｉｖｅｒ”，
０）、およびＧｅｔＣｏｍｐｏｎｅｎｔ（“Ｃｏｄｅｃ”，０）を表明する。ネ
ットワークトランシーバおよびコーデックのクラスはＡＰＩを表明し、ユーザが
物理的インタフェースボード上の対応するハードウェアを制御することができる
ようにする。インデックス（ここでは‘０’）は、ボード上の構成要素の数を示
す。これにより、１つのボード上で複数の同一の構成要素を許容する（例えば２
つのトランシーバＩＣを備え、その第２は、ＧｅｔＣｏｍｐｏｎｅｎｔ（“Ｎｅ
ｔｗｏｒｋＴｒａｎｃｅｉｖｅｒ”、１）でアクセスされる）。

【００６３】この手法は以下のいくつかの利点を与える。・モジュラ分解。ＯＰＢクラスの機能性をいくつかの別個のソフトウェアモジ
ュールに分割する。従って、ＯＰＢの複雑さをより単純な構成部分に分割するこ
とができる。これにより、ソフトウェアがより単純になり、保守もより容易にな
る。

【００６４】・構成部品の再利用。構成要素が別個のモジュールであるので、その他のソフ
トウェアモジュールの間でこれらを容易に共用することができる。例えば、ネッ
トワークトランシーバおよびコーデックのクラスは、同等のＩＣがボードの両方
の型に存在することから、ＯＰＢおよびＡＯＰＢのクラス双方によって使用され
る。構成要素のためのコードは集中化され、構成要素の変更は一箇所で行うだけ
でよい。

【００６５】・拡張性。上記の点の結果として、ハードウェアの新しい要素が、ＯＰＢ（例
えばＤＳＰＩＣ）に追加された場合には、単にそのための新しい構成要素クラ
スを開発し、これをＯＰＢクラスに「差し込む」だけとなる。このプロセスは、
ＯＰＢクラス自体をほとんど変更せずに実行することができる。

【００６６】ＯＰＢによって作成された構成要素オブジェクトはそれぞれ、最終的にインタ
フェースボードファームウェアと通話して、所望の動作をハードウェア上で実行
しなければならない。このファームウェアとの全ての通信は、ＯＰＢドライバオ
ブジェクトを介して行われなければならないので、各構成要素が関連するＯＰＢ
ドライバオブジェクト８１２にアクセスできることが必要と考えられる。しかし
ながら、これは、ＯＰＢクラスを第１に有するという利点を損なうことになる（
ファームウェアとの通信機構を抽象化するために）。各構成要素は、任意の構成
であらゆる型のＯＰＢと通話するために、固有のコードを実施しなければならな
くなる。

【００６７】この問題を軽減するために、ＯＰＢの構成要素オブジェクト８１６、８１８の
一方から実際のインタフェースボードへの全ての通信は、ＯＰＢオブジェクト８
１４自体を介して行われる。これはつまり、構成要素オブジェクトが、ＯＰＢの
特定の知識および通信機構をそれらのコードに埋め込む必要がないということで
ある（これがＯＰＢオブジェクト中にあるため）。しかしながら、ＯＰＢクラス
が、ファームウェアと通話するためには、これらの構成要素オブジェクトについ
て厳密に定義された（ただし多様な）インタフェースを表明しなければならない
ことを意味する。構成要素オブジェクトは、ＯＰＢクラスのどの型にそれらが接
続されるかについて仮定を立てることができない。様々な型のＯＰＢオブジェク
トに接続される可能性があるからである（上述した構成要素の再利用の点を参照
のこと）。しかし、構成要素オブジェクトは、それらが接続される任意の型のＯ
ＰＢクラスとどのようにして通話するかを知らなければならない。これはつまり
、全てのＯＰＢクラスのオブジェクトが、それらの構成要素について定義された
インタフェースを提供しなければならないということである。

【００６８】従って、このシステム中のＯＰＢクラスは、インタフェースボード上の特定の
機能にアクセスするために、他の構成要素のいくつかのインタフェースを表明す
る。ＯＰＢクラスは、実際には、４つの異なるインタフェースを実装する。

【００６９】・クライアントインタフェース。これは、エンドユーザのアプリケーションに
対して表明される主要インタフェースであり、これを介して、それらのアプリケ
ーションはＯＰＢの全ての機能（より正確にはＯＰＢがエンドユーザにアクセス
を許す全ての機能）にアクセスすることができる。

【００７０】・レジスタインタフェース。このインタフェースは特に、ネットワークトラン
シーバおよびコーデックオブジェクトが、ネットワークトランシーバＩＣ中でレ
ジスタの読取り／書込みを実行するために使用する。

【００７１】・トランシーバサポートインタフェース。このインタフェースは、ネットワー
クトランシーバオブジェクト８１６が、Ｄ２Ｂメッセージを送信し、ＯＰＢオブ
ジェクトから取出し、そのＤ２Ｂアドレスを設定するために独占的に使用する。

【００７２】・制御インタフェース。これは、ディレクタ８２４が、ＯＰＢオブジェクトを
初期化し、操作するために独占的に使用する。

【００７３】ＯＰＢの何らかの特定の機能にアクセスするためには、クライアント（ユーザ
）は、それを提供する適当な構成要素オブジェクトを経由せざるを得ず、クライ
アントインタフェースを経由することはできない。換言すれば、ＯＰＢ上のトラ
ンシーバＩＣへのレジスタ書込みを実行するためには、ユーザはネットワークト
ランシーバオブジェクト８１６を使用しなければならない。主要なＯＰＢクライ
アントインタフェースは、トランシーバレジスタへの書込みを直接行うための機
能を表明しない。この考えを実施することにより、特定の一意的な動作を実行す
るための方法がただ１つとなることが保証される。これは一般にソフトウェアを
単純化し、保守をより容易にする。

【００７４】この開発システムのもう１つの重要な側面は、それが、インタフェースボード
上およびより広域ネットワーク中で発生したイベントを、エンドユーザのアプリ
ケーションに通告することである。これらのイベントは、ＯＰＢファームウェア
によってＯＰＢドライバオブジェクト８１２に渡され、次いでこれがそれらのイ
ベントをＯＰＢオブジェクト８１４に渡す。ＯＰＢオブジェクトはこれらのメッ
セージを復号し、開発システムの残りの部分で認識されるフォーマットに変換す
る。ＯＰＢクラスだけが、ＯＰＢドライバから渡されたメッセージの意味を理解
する。従って、特定の型のインタフェースボードのＯＰＢドライバが、これらの
メッセージについて同一のフォーマットを使用することが重要である。これは、
ＯＰＢドライバクラスからＯＰＢクラスへの抽象化を維持するために重要である
。

【００７５】ＯＰＢはメッセージを復号し、これをネットワークトランシーバオブジェクト
８１６に渡し、そこからメッセージは最終的にエンドユーザのアプリケーション
に伝達されることになる。

【００７６】（ネットワークトランシーバ８１６）ネットワークトランシーバクラスは、インタフェースボード上の実際のネット
ワークトランシーバＩＣを制御し、ネットワークトランシーバに関する情報を取
出すためのＡＰＩをもたらす。例えば、ＣｏｎａｎトランシーバＩＣ、型番ＯＣ
Ｃ８００１の知識をカプセル化するネットワークトランシーバクラスがある。

【００７７】ネットワークトランシーバクラスの主な目的は、エンドユーザとＯＰＢ上のト
ランシーバＩＣとの間に、抽象化した階層を提供することである。この考えは、
ユーザが、任意タイプのネットワークトランシーバの機能にアクセスするために
汎用ソフトウェアを使用できるようにする点で、この前のセクションで詳述した
ＯＰＢクラスの抽象化の考えとほぼ全く同じである。その結果として、ユーザは
、単一のソフトウェアを書き込めば、任意のネットワークトランシーバクラスの
機能にアクセスすることができる。この抽象化は、全てのネットワークトランシ
ーバクラスが、諸機能の共通のインタフェースを実装することを保証することに
よって実現される。この場合ユーザは、ネットワークトランシーバオブジェクト
を制御するためのプログラミングによってこのインタフェースを使用する。ユー
ザは、ネットワークトランシーバオブジェクトを使用するために、そのいかなる
特定の知識も有する必要がない。

【００７８】ネットワークトランシーバクラスは、４つの主な機能領域へのアクセスを提供
する。・レジスタの読取りおよび書込み。・レジスタについての情報（例えばそれらの名前など）の取出し。・ネットワークトランシーバについての情報（例えばその型や、多くのレジスタ
をどのようにして有するかなど）の取出し。・Ｄ２Ｂメッセージの送信および取出し。

【００７９】最初の３つの機能領域は、全てのネットワークトランシーバクラスに共通の、
主要な汎用インタフェースに含まれる。これは、クライアントアプリケーション
８１０に表明されたＡＰＩである。他の１つのＡＰＩが、Ｄ２Ｂメッセージの送
信／取出しのために設けられる。このＡＰＩは、クライアントが直接使用するこ
とができず、開発システムのその他の構成要素（すなわちメッセージ制御構成要
素）によって内部で使用されるだけである。

【００８０】その理由は、やはり抽象化と関係がある。現在、トランシーバＩＣは、Ｄ２ＢＯｐｔｉｃａｌの制御フレームフォーマットを使用している。将来、異なるプ
ラットフォームに適合するように制御フレームフォーマットが変更された場合に
は、そのＤ２Ｂメッセージの送信／取出しのためのＡＰＩは、その他のネットワ
ークトランシーバオブジェクトと異なることになる。これは、ＡＰＩを抽象化す
ることができないことを意味する（メッセージを送信する機能は、ネットワーク
トランシーバごとに異なるので）。その代わりにＤ２Ｂメッセージの概念を抽象
化することができ、ネットワークトランシーバクラスはそれらを送信するための
共通のＡＰＩを実装することになる。しかし、そのためには、ネットワークトラ
ンシーバクラスがＤ２Ｂメッセージの概念を理解する必要があり、これはネット
ワークトランシーバクラスのさらに高いレベルの概念であると判断されている。
さらに、Ｄ２Ｂメッセージを送信するために余分な制御コードが必要となり、こ
れをあらゆるユーザが書き込むことは期待できない。従って、Ｄ２ＢＯｐｔｉ
ｃａｌメッセージへのアクセスのＡＰＩは、エンドユーザに与えられない。その
代わりに、アプリケーションは、Ｄ２Ｂメッセージの送受信のために、システム
制御構成要素のＡＰＩを経由しなければならない。

【００８１】ネットワークトランシーバオブジェクト８１６は、開発システム環境中のＯＰ
Ｂオブジェクトによって作成され、破壊され、所有される。ネットワークトラン
シーバオブジェクトは、ＯＰＢオブジェクトのレジスタインタフェースおよびト
ランシーバサポートインタフェースとの接続を維持し、それを介してＯＰＢファ
ームウェア８２２にアクセスする。クライアント８１０は、書き込まれたレジス
タ、およびそれに書き込まれた値を通知される。ＯＰＢオブジェクト８１４は、
イベントをネットワークトランシーバオブジェクトに渡すこともできる。これを
行うために、ネットワークトランシーバクラスは、ＯＰＢが使用するための共通
の汎用ＡＰＩを提供する。このＡＰＩは（抽象化のために）汎用でなければなら
ず、従ってＯＰＢオブジェクトはそれらのトランシーバを透過的に取り扱うこと
ができる（すなわち、それらは同じ機構／コードを使用して、任意の型のトラン
シーバにイベントを通知することができる）。

【００８２】ＯＰＢオブジェクト８１４からのイベントは、最終的にクライアントアプリケ
ーション８１０に達しなければならないので、ネットワークトランシーバオブジ
ェクト８１６は、何らかの方法でメッセージをアプリケーションまで伝達させな
ければならない。ネットワークトランシーバオブジェクトは、メッセージ制御オ
ブジェクトを介してこれを行う。メッセージ制御オブジェクトは、ＯＰＢハード
ウェアを表す構成要素（ＯＰＢ、トランシーバ、コーデックの諸構成要素）と、
「システムインスタンス」構成要素（メッセージ制御、自動応答システム（ＡＲ
Ｓ）、デバイスの諸構成要素）との間の「ブリッジ」である。「システムインス
タンス」構成要素は、この開発システムで使用する各アプリケーションに一意的
である。各アプリケーションは、メッセージ制御、ＡＲＳ、デバイス、およびシ
ステム制御の諸構成要素の、それ自体一意的なインスタンスを有することになる
。これは、開発システムのアプリケーション間で共用される「ハードウェア構成
要素」（ＯＰＢ、トランシーバ、コーデックなど）とは対照的である。これらハ
ードウェアオブジェクトの各々のインスタンスの１つが、現実のハードウェアに
対応してそれぞれ存在する。

【００８３】従って、メッセージ制御オブジェクト８２６は、ハードウェア構成要素と開発
システムの構成要素間のブリッジを提供する。ネットワークトランシーバオブジ
ェクトは、メッセージ制御オブジェクトに接続し、および切断する能力を有する
。これを行う機能は、ネットワークトランシーバオブジェクト上の、Ｄ２Ｂメッ
セージ機能と同じインタフェース中にある。「接続」を確立するプロセスでは、
ネットワークトランシーバオブジェクトは、受信したＯＰＢイベントおよびＤ２
Ｂメッセージのメッセージ制御オブジェクトに、トランシーバが通知するために
使用する、メッセージ制御オブジェクト上のインタフェースの参照を獲得する。
接続が確立された後で、クライアントアプリケーションは、Ｄ２Ｂメッセージを
インタフェースボードハードウェアへ送信し、および受信することができる。接
続を行うためのネットワークトランシーバクラス上のＡＰＩは、やはり汎用でな
ければならず、従って、メッセージ制御オブジェクトは、それが接続しようとす
るトランシーバの型について気にする必要なく、あるいはそれを知る必要もなく
、任意の型のネットワークトランシーバオブジェクトに接続することができる。

【００８４】ネットワークトランシーバクラスの１つの最終的なサービスは、開発システム
のネットワークトランシーバオブジェクトを使用して、レジスタ書込みがトラン
シーバＩＣ上で実行されたときに、クライアントアプリケーションに通知するこ
とである。これが起こると、ネットワークトランシーバオブジェクトがメッセー
ジを生成し、これをメッセージ制御構成要素８２６に渡し、最終的にクライアン
トアプリケーションに渡す。このメッセージは、書き込まれたレジスタ、および
それに書き込まれた実際の値を示す情報を含む。

【００８５】（コーデック８１８）ネットワークで記述される型は、制御メッセージおよびデータメッセージに加
えてソースデータストリームも生成するので、コーデッククラスは、インタフェ
ースボード上の音声または画像コーデックＩＣを制御し、コーデックに関する情
報を取出すためのＡＰＩを提供する。例えば、ＣｏｄｅｃＣＳ−４２２５Ｉ
Ｃの知識をカプセル化するコーデッククラスがある。

【００８６】ネットワークトランシーバクラスの場合と同様に、コーデッククラスの主な目
的は、開発システムのアプリケーションとＯＰＢ上に存在することがある様々な
タイプのコーデックＩＣとの間に、抽象化の階層を提供することである。コーデ
ックは、以下の機能領域を有する。・コーデックのプロパティの設定／取出し。・レジスタの読取りおよび書込み。・レジスタについての情報（名前など）の取出し。・コーデックについての情報（そのタイプや、どの位のレジスタを有するかなど
）の取出し。

【００８７】この実施形態のコーデックオブジェクト８１８は４つのプロパティを有する。
・ミュート（ｍｕｔｅ）・ボリューム・バランス・フェードこれらのプロパティは、コーデックＩＣ自体の属性ではなく、開発システムが
与える概念である。これは、いくつかのコーデックＩＣレジスタ（すなわち出力
減衰レジスタ）の意味を、ユーザに対して意味をなすレベルまで抽象化するもの
である。換言すれば、コーデックＩＣの出力減衰レジスタが全てゼロであるなら
ば、これはエンドユーザに対して意味をなさない。そうではなく、コーデックＩ
Ｃのボリュームが１００％であると言えば、これはユーザに対して関連した意味
をなす。このように、ボリュームとは減衰レジスタの抽象表現であり、ユーザに
対して意味をなす。これらのプロパティは、コーデックオブジェクトの主要なク
ライアントＡＰＩを介して設定し、取出すことができる。

【００８８】コーデック構成要素は、常に、そのＯＰＢオブジェクトに生成され、ネットワ
ークトランシーバオブジェクトときわめてよく似た方法で、ＯＰＢオブジェクト
によって接続される。コーデックオブジェクト８１８は、ＯＰＢオブジェクトの
レジスタインタフェースを使用してＯＰＢファームウェアと通話し、レジスタ書
込みを実行する。コーデックオブジェクト８１８を使用してコーデックＩＣに対
してレジスタ書込みが行われると必ず、コーデックオブジェクトは、書き込まれ
たレジスタ、およびそれらに書き込まれた値をクライアントアプリケーションに
通知する。コーデックオブジェクトは、ＯＰＢオブジェクトのレジスタインタフ
ェース中の、別の機能を呼び出すことによってこれを行う。コーデックオブジェ
クトは、ＯＰＢオブジェクトによってイベントを通告されることはない。

【００８９】（ディレクタ８２４）ディレクタオブジェクト８２４は、本質的に、インタフェースボードマネージ
ャ構成要素である。１つだけのディレクタのインスタンスが、いつでも実行／存
在することになる点で一意的である。これにより、集中化されたインタフェース
ボードの管理がもたらされる。ディレクタは、実行中の任意のＯＰＢオブジェク
トにクライアントがアクセスできるようにする機能を含む、単一のＡＰＩを表明
する。これを行うことができるようにするために、ディレクタは、その環境中に
存在する全てのＯＰＢオブジェクトについて知っている。ディレクタは、全ての
ＯＰＢオブジェクトを実際に作成する（かつ最終的に破壊する）のがディレクタ
オブジェクト自体であるという事実の効能により、この知識を有する。これはま
た、ディレクタがＯＰＢクラスの全ての型、およびそれらを作成する方法につい
ての特定の知識を有することも意味する。

【００９０】ディレクタが作成されたときに最初に行うことは、どのインタフェースボード
がＰＣに取り付けられたかを決定することである。ディレクタは、可能なあらゆ
る型のＯＰＢドライバオブジェクトのインスタンスを作成し、それらを使用して
実際のＯＰＢを検出することによってこれを行う。ＯｐｔｉｃａｌＰｏｗｅｒ
Ｂｏａｒｄが検出された場合には、ディレクタは適当なＯＰＢオブジェクトを
作成し、そのＯＰＢオブジェクトをＯＰＢドライバオブジェクト８１２にリンク
する。その後、ＯＰＢオブジェクトは、ＯＰＢドライバを介して自由にＯＰＢと
通信することができる。ディレクタは、それらを検出することができなくなるま
で、指定された各型のドライバおよびＯＰＢオブジェクトを作成し続ける。

【００９１】例えば、ディレクタが作成されたときに、並列ＯＰＢドライバオブジェクトを
作成する。次いで、ディレクタはそのオブジェクト中のＯＰＢ検出機能を呼び出
す。この機能は、ＰＣに並列に取り付けられたＯＰＢが存在しないことを意味す
る「Ｆａｌｓｅ」を返し、従ってディレクタは並列ＯＰＢドライバオブジェクト
を破棄する。次いで、直列ＯＰＢドライバオブジェクトを作成し、そのＯＰＢ検
出機能を呼び出す。この機能は、シリアルＲＳ−２３２で接続されたＯｐｔｉｃ
ａｌＰｏｗｅｒＢｏａｒｄをＰＣが有することを意味する「ｔｒｕｅ」を返
す。従って、ディレクタはＯＰＢオブジェクト８１４のインスタンスを生成し（
ｉｎｓｔａｎｔｉａｔｅｓ）、これに直列ＯＰＢドライバオブジェクトへの参照
を渡す。ディレクタは、複数存在することはないという明示的な知識を有するの
で、それ以上の直列ＯＰＢの検出を試みようとはしない。最後に、ディレクタは
、ＡｄｖａｎｃｅｄＯＰＢ（ＡＯＰＢ）ドライバオブジェクトを作成し、これ
を用いてＡＯＰＢを検出する。ＡＯＰＢの構成要素オブジェクトが作成され、Ａ
ＯＰＢドライバオブジェクトに結合される。ＡｄｖａｎｃｅｄＯＰＢは、図１
０のセットアップで説明したデイジーチェーン機構を提供する。ディレクタは、
その他のＡＯＰＢ（例を図１０に示す）が存在することがあることを知っている
ので、別のＡＯＰＢドライバ構成要素を作成し、別のＡＯＰＢの検出を試行する
。ディレクタは、ＰＣに取り付けられた全てのインタフェースボードを検出する
まで、引き続きこれを行う。

【００９２】ディレクタは、インタフェースボードの検出に成功した、全てのＯＰＢオブジ
ェクトへの参照を記憶する。そして、ディレクタは、任意の要求側クライアント
にこれらの参照を提供することができる。

【００９３】ディレクタがオプションとして有するよう構想された唯一のその他の機能領域
は、ＯＰＢオブジェクトと同様にデバイスオブジェクト８３０等を指図すること
である。これにより、アプリケーションが、実行中のその他の開発システムを「
スパイ」することが可能となる（デバイスのセクションで述べる）。これを行う
ために、ディレクタオブジェクトは、通常、デバイスオブジェクトがディレクタ
にそれら自体を登録および登録解除することができるようにする機能と、登録さ
れたデバイスオブジェクトへの参照をアプリケーションが取出すための機能とを
備えた、もう１つのＡＰＩを表明することになる。

【００９４】（メッセージ制御８２６）メッセージ制御構成要素クラスは５つの主要な機能カテゴリを提供する。・Ｄ２Ｂメッセージのキューイングおよび送信。・Ｄ２Ｂ制御フレームの受信および変換。・ＯＰＢイベントの受信および伝達。・長いＤ２ＢＯｐｔｉｃａｌメッセージの管理。・トランシーバオブジェクトおよびＡＲＳオブジェクトへの接続の生成および破
棄。

【００９５】メッセージ制御クラスの主な機能は、Ｄ２Ｂメッセージのキューイングおよび
クライアントアプリケーションへの送信サービスを提供することである。メッセ
ージを送信できるようにするためには、最初に、メッセージ制御オブジェクトを
ネットワークトランシーバオブジェクト８１６に接続しなければならない（かつ
それにより間接的に物理的インタフェースボード８０４／８０６などに）。メッ
セージ制御クラスは、それをネットワークトランシーバオブジェクトに接続する
機能およびそこから切断する機能を備えたインタフェースを表明する。メッセー
ジ制御オブジェクトには、ネットワークトランシーバオブジェクトのインタフェ
ースへの参照が与えられ、これを介して、メッセージ制御オブジェクトは接続さ
れているネットワークトランシーバオブジェクトの型を決定する。そして、メッ
セージ制御は、ネットワークトランシーバオブジェクトに、そのインタフェース
のうちの１つへの参照を与える。このインタフェースは、そのネットワークトラ
ンシーバオブジェクトが後に、イベントおよびＤ２Ｂメッセージをメッセージ制
御オブジェクトに渡すために使用するインタフェースである。メッセージ制御オ
ブジェクトは、いくつかの異なるこのような「通告」インタフェースを表明する
ことができる。これにより、下記のように、将来の拡張性および柔軟性をもたら
すことができる。

【００９６】新しい開発システムは、拡張可能かつ「将来に備えた（ｆｕｔｕｒｅｐｒｏ
ｏｆ）」ものとなるように意図されている。メッセージ制御クラスの意義の１つ
は、Ｄ２Ｂ制御フレーム構造（図７）が将来変化することができること（おそら
くは例えば新しい型のトランシーバＩＣのために）、または同じプロトコルが異
なる型のネットワーク上で完全に実装されることになることである。従って、メ
ッセージ制御クラスは、様々な制御フレームフォーマットを使用していることが
ある、様々なネットワークトランシーバオブジェクトと対話することができなけ
ればならない。しかし、開発システムの構成要素およびクライアントアプリケー
ションは、制御フレームではなくＤ２Ｂアプリケーションプロトコルのメッセー
ジの概念を扱う。Ｄ２Ｂアプリケーションプロトコルメッセージは、メッセージ
の現実のセマンティクス（意味）を含むが、制御フレーム構造は、トランシーバ
ハードウェアによってアプリケーションプロトコルメッセージに付与された単な
る通信フォーマットである。開発システムのエンドユーザは、Ｄ２Ｂメッセージ
を送信することに関心を持つが、Ｄ２Ｂ光ネットワークを介してこれらのメッセ
ージを送信するための実際のフォーマットを覚えていない。Ｄ２Ｂメッセージは
、それを通信する際に基礎となった物理フォーマットからメッセージの意味を分
離（ａｂｓｔｒａｃｔ）するものとして考えることができる。

【００９７】従って、クライアントアプリケーションおよび開発システムの構成要素はＤ２
Ｂメッセージの概念を使用するが、同じフレームフォーマットがアプリケーショ
ン中でその他の型のネットワークまたはその他のプロトコルに適用されることは
ない。「ハードウェア」構成要素（トランシーバおよびＯＰＢクラス）は、制御
フレームを扱う。開発システムのフレームワーク中のどこかで、Ｄ２Ｂメッセー
ジを制御フレームに、またその逆に翻訳しなければならず、これはメッセージ制
御クラスの仕事である。メッセージ制御オブジェクト８２６は、全ての制御フレ
ームフォーマットを知っている。メッセージ制御オブジェクト８２６は、最初に
ネットワークトランシーバオブジェクト８１６に接続されたときに、トランシー
バの型を決定し、それによりその制御フレームフォーマットを決定する。後にＤ
２Ｂメッセージが送信されたときに、メッセージ制御はこのＤ２Ｂメッセージを
、トランシーバが期待する適当な制御フレーム構造に変換することができる。様
々なネットワークトランシーバクラスが、様々な制御フレームの型を送信するた
めの様々なＡＰＩを表明することになる（従ってこのＡＰＩは抽象化することが
できない）。これが、エンドユーザのアプリケーションが、この実施形態で、ネ
ットワークトランシーバクラスのＡＰＩへ送信するメッセージへのアクセスを与
えられない理由である。

【００９８】制御フレームが受信されると、ネットワークトランシーバオブジェクト８１６
は、これをメッセージ制御オブジェクト８２６に渡す。様々なタイプのトランシ
ーバが様々な制御フレームを使用するので、メッセージ制御オブジェクトは、存
在する制御フレームの型それぞれについてＡＰＩを提供する。メッセージ制御が
ネットワークトランシーバオブジェクトに接続されたときに、適当なメッセージ
制御の通告インタフェースへの参照をこのトランシーバに与え、トランシーバは
、これを介してその特定の制御フレームの型をメッセージ制御に渡すことができ
る。この最終的な結果として、メッセージ制御構成要素は、任意タイプのトラン
シーバＩＣを介してＤ２Ｂメッセージを送受信することができる。同時に、開発
システムの構成要素およびエンドユーザのアプリケーションは、Ｄ２Ｂメッセー
ジの考えを引き続き使用することができ、将来新しい型のトランシーバを利用す
るためにソフトウェアを改変する必要はない。

【００９９】アプリケーション８１０がＤ２Ｂメッセージを送信すると、メッセージ制御オ
ブジェクト８２６は、このメッセージを直ちに伝送しようとはせずに、バッファ
に入れる。メッセージ制御オブジェクトが接続されたネットワークトランシーバ
オブジェクト８１６は、定期的にメッセージ制御オブジェクトに信号を送り、そ
れが進行することができ、望むならＤ２Ｂメッセージの送信を開始することがで
きることを示す。そして、メッセージ制御オブジェクト８２６は、そのバッファ
から自由にＤ２Ｂメッセージを取出し、送信する。これは次いで、送信結果を取
出し、クライアントアプリケーションに通知する。メッセージをバッファ中に置
くことで、開発システムは、追加の通信管理を実行し（例えば以下の長メッセー
ジを参照されたい）、アプリケーションがそれ自体でバッファリングを実装する
実施する必要を防ぐ。

【０１００】ネットワークトランシーバオブジェクト８１６は、着信する制御フレームを受
信すると、これをメッセージ制御オブジェクト８２６に渡す。メッセージ制御オ
ブジェクト８２６は、制御フレームをＤ２Ｂメッセージに変換し、それをクライ
アントアプリケーション８１０に渡す。

【０１０１】従って、メッセージ制御オブジェクト８２６は、以下の３つのことを開発シス
テムのクライアントアプリケーションに通知する役割を担う。・Ｄ２ＢＯｐｔｉｃａｌメッセージの受信。・送信されたＤ２ＢＯｐｔｉｃａｌメッセージの送信結果。・基礎となる開発システムのハードウェア構成要素から受信したイベント。

【０１０２】これを達成するために、メッセージ制御オブジェクトは、ネットワークトラン
シーバをメッセージ制御オブジェクトに接続したのと同様に、ＡＲＳオブジェク
ト（８２８、後述）に接続することができる。これを行う機能も、ネットワーク
トランシーバオブジェクトがメッセージ制御オブジェクトに接続するために使用
したのと同じＡＰＩ中にある。

【０１０３】従って、メッセージ制御オブジェクト８２６は、以下２つのＡＰＩを有する。・クライアント／制御インタフェース。・メッセージ制御をネットワークトランシーバオブジェクトに接続。・メッセージ制御をＡＲＳオブジェクトに接続。・Ｄ２Ｂメッセージを送信。

【０１０４】・接続されたトランシーバが使用する通告インタフェース。・受信した制御フレームをメッセージ制御オブジェクトに渡すこと。・ハードウェア構成要素メッセージをメッセージ制御に渡すこと。・それが自由にＤ２Ｂメッセージを送信できることをメッセージ制御に通知
すること。

【０１０５】この例でメッセージ制御クラスが提供する最後のサービスは、長いＤ２Ｂメッ
セージに関する。長いＤ２Ｂメッセージは、単一の制御フレームで伝送すること
ができず、従って長いＤ２Ｂメッセージを複数の制御フレームにパッケージ化し
、伝送するために、余分な管理コードが必要となる。同様の管理コードが、長い
Ｄ２Ｂメッセージの中に制御フレームを蓄積しパッケージ化するために、長いメ
ッセージを受信する側でも必要となる。さらに、制御フレームの送受信において
、いくつかのプロトコル（例えばフロー制御を補助するためのプロトコル）が必
要となることもある。

【０１０６】全ての長メッセージの論理は、長メッセージを扱おうとするあらゆる開発シス
テムのアプリケーションによって実装されなければならないので、その代わりに
メッセージ制御クラスがこれを実装する。メッセージ制御クラスは、ｌｏｎｇ
ｍｅｓｓａｇｅｐｒｏｔｏｃｏｌ（ＬＭＰ）クラスのオブジェクトを使用して
、これを内部で行う。このオブジェクトは、長メッセージの送受信に必要な全て
の知識を含む。このクラスは、将来開発される任意の新しい長メッセージプロト
コルを使用するために更新することができる。現在の実装は、制御フレームをＤ
２Ｂメッセージに（またその逆に）パッケージ化／パッケージ解除するための論
理を含み、またフロー制御プロトコル論理を含むように適合させることもできる
。最終的な結果として、常に、ユーザは長メッセージプロトコルから防護され、
比較的容易にかつ余分なコーディングを行わずに、それらが長メッセージを送受
信することができるようにする。特定のｌｏｎｇｍｅｓｓａｇｅｐｒｏｔｏ
ｃｏｌを使用する、または長メッセージの処理を完全に止める命令を、メッセー
ジ制御オブジェクトにするための手段が存在することもできる。

【０１０７】メッセージ制御オブジェクトは、長メッセージを受信したときには、さらに処
理するためにこれをＬＭＰオブジェクトに渡す。ＬＭＰオブジェクトは、必要な
任意の動作を実行し、制御フレームから完全なメッセージを構築する。メッセー
ジが完成すると、通常の方法によってＡＲＳオブジェクト８２８に渡される。長
メッセージの送信中には、ＬＭＰオブジェクトは、Ｄ２Ｂメッセージオブジェク
ト自体といっしょに、このメッセージを管理し、メッセージを送信するための制
御フレームにパッケージ化する。全ての制御フレームが送信された後で、クライ
アントアプリケーションにその送信結果が通知される。

【０１０８】（ＡＲＳ（自動応答システム）８２８）ＡＲＳクラスは、開発システムのクライアントアプリケーションに知的自動応
答を付加するための基礎を提供する。このクラスは以下の機能領域を提供する。
・システムおよびデバイスの仕様。・Ｄ２Ｂメッセージの妥当性検査。・Ｄ２Ｂメッセージの翻訳。・自動デバイスの挙動／応答。

【０１０９】本開発システムの背景にある動機の１つは、Ｄ２ＢＯｐｔｉｃａｌの製品の
各設計者／製造業者が、最初に独自のＤ２Ｂネットワークシステムを開発すると
いう事実である。このシステムは、Ｄ２ＢＯｐｔｉｃａｌのプロトコルの指定
されたサブセットを使用して通信する、指定されたＤ２ＢＯｐｔｉｃａｌデバ
イスを含むことになる。Ｄ２Ｂシステムインテグレータは、システム中のデバイ
スがプロトコルおよびシステム仕様に適合すること（例えば、それらがそのシス
テムの実際の構成では無効なＤ２Ｂメッセージを送信しないこと）をテストでき
ることを望む。Ｄ２Ｂシステムインテグレータはまた、デバイスエミュレータ、
および自分のＤ２ＢＯｐｔｉｃａｌシステムまたはＤ２ＢＯｐｔｉｃａｌデ
バイス／製品のテストを自動化するためのテストアプリケーションを構築するこ
とも望むことがある。

【０１１０】開発システムでこの考えをサポートするための中核となるのは、システム記述
ファイル（ＳＤＦ）８３８中でカプセル化されたプロトコルデータベースの概念
である。ＳＤＦは、以下のことを行う。・特定のＤ２ＢＯｐｔｉｃａｌバージョンについて全てのアプリケーションプ
ロトコルを含む。・その特定のシステムで有効なプロトコルのサブセットを指定する。・そのシステムで有効なデバイスを指定する。・デバイス中の有効なサブデバイス、およびそれらサブデバイスのソースデータ
の型を指定する。

【０１１１】このように、ＳＤＦは、デバイス（ＣＤチェンジャや電話など）が実際にその
中に存在する、任意の特定のＤ２ＢＯｐｔｉｃａｌシステムの仕様をカプセル
化するために作成することができる。ＡＲＳに、それが表明するＡＰＩ中の機能
を介して、特定のＳＤＦを使用するよう命令することができる。そして、ＡＲＳ
はＳＤＦ中の知識を利用することができ、またその他の開発システムの構成要素
がその同じ情報にアクセスできるようにするための、もう１つの別個のインタフ
ェースも表明する。

【０１１２】図８から分かるように、クライアントアプリケーション８１０との全てのＤ２
Ｂメッセージ通信は、ＡＲＳオブジェクト８２８を通過しなければならない。従
って、ＡＲＳオブジェクトは、送信または受信されるあらゆるメッセージを検査
することができ、プロトコルおよび（この特定のシステムでは）ＳＤＦ中に記述
されたシステムの仕様にそのメッセージが適合するかどうかをテストする。クラ
イアントアプリケーションが無効メッセージを送信しようとした場合には、ＡＲ
Ｓは、このメッセージを拒絶する（送信しない）ことも、単にアプリケーション
に警告することもできる。無効メッセージが受信された場合には、ＡＲＳはそれ
が無効であるとクライアントアプリケーションに警告することができる。無効メ
ッセージに応答したＡＲＳオブジェクト８２８の挙動は、ＡＲＳのＡＰＩ中の機
能を介して構成することができる。従って、ＳＤＦを使用することにより、ＡＲ
Ｓは、自動化されたＤ２Ｂメッセージの妥当性検査サービスをクライアントアプ
リケーション８１０に提供することができ、クライアントはいかなる作業も実行
する必要がない。

【０１１３】ＡＲＳのもう１つの特徴は、メッセージの記号翻訳（ｓｙｍｂｏｌｉｃｔｒ
ａｎｓｌａｔｉｏｎ）である。各Ｄ２Ｂアプリケーションプロトコルメッセージ
は、例えば、演算コードおよびいくつかのオペランドとして指定される。これは
複雑なために、エンドユーザにとっては非常に分かりにくい表現であり、また数
字列の意味を覚えることは困難である。これを多少とも解消するために、新しい
開発システムは、Ｄ２Ｂメッセージを人が読めるテキスト表現に、またその逆に
翻訳することができる。このサービスは、ＡＲＳオブジェクト８２８によって提
供される。従って、クライアントアプリケーション８１０は、送信すべきＤ２Ｂ
Ｏｐｔｉｃａｌメッセージをテキストで指定することができ、ＡＲＳオブジェ
クトは、このテキストを対応するＤ２ＢＯｐｔｉｃａｌメッセージに変換する
ことになる。同様に、ＡＲＳオブジェクトが受信したＤ２Ｂメッセージは、クラ
イアントアプリケーションに伝達される前にテキストに変換することができる。
ＡＲＳ中のテキスト翻訳は、そのＡＰＩ中の機能によってオンまたはオフにする
ことができる。

【０１１４】ＡＲＳオブジェクト８２８は、メッセージ制御オブジェクト８２６およびネッ
トワークトランシーバオブジェクト８１６と同様に、その他の開発システムの構
成要素に接続される。ＡＲＳオブジェクト８２８は、メッセージ制御オブジェク
ト８２６に接続され、そこから通告（Ｄ２Ｂメッセージ、送信結果、およびイベ
ント）を受信する。処理の後に、ＡＲＳオブジェクトは、受信した全ての通告を
デバイスオブジェクト８３０（以下参照）に伝達する。従って、ＡＲＳオブジェ
クトは、メッセージ制御オブジェクトおよびデバイスオブジェクトとの接続を確
立する機能と、最終的にそれらの接続を破棄する機能を提供する。これらの機能
は、専用のＡＰＩ中に設けられる。

【０１１５】ＡＲＳクラスは、現在、以下のことを行う４つのＡＰＩを提供する。・ＡＲＳの属性（例えばどのＳＤＦを使用するか、テキスト翻訳を使用するかど
うか、など）を設定すること。・ＡＲＳをその他の開発システムの構成要素に接続すること。・接続されたメッセージ制御オブジェクトから通告を受信すること。・ＳＤＦのシステム仕様へのアクセスを提供すること。

【０１１６】（デバイス８３０）デバイス構成要素は、構成要素マネージャであると考えることができ、システ
ムインスタンスの中心となる構成要素である。システムインスタンスの概念につ
いては既に述べたが、分かりやすくするためにここでさらに詳細に述べる。

【０１１７】クライアントアプリケーション８１０が開発システムを使用するときには、シ
ステム制御オブジェクト８３２、デバイスオブジェクト８３０、ＡＲＳオブジェ
クト８２８、メッセージ制御オブジェクト８２６、および（任意選択で）スイッ
チボックスオブジェクト８３４が作成される。これらのオブジェクト（以下で詳
述する）は、事実上アプリケーションに属し、ともにアプリケーションのシステ
ムインスタンスを形成する。これらのオブジェクトはアプリケーション８１０に
固有のものであり、その他のアプリケーションがアクセスすることはできない。
これは、ＯＰＢオブジェクトやネットワークトランシーバオブジェクト、コーデ
ックオブジェクト、ディレクタオブジェクト（後述）など、その他の開発システ
ムの構成要素とは対照的である。これらは共用される構成要素であり、複数のア
プリケーションがアクセスし、使用することができる。クライアントアプリケー
ションは、いくつかのＡＰＩを介してその開発システムの属性および挙動を制御
することができる。

【０１１８】クライアントアプリケーションは、ＯＰＢを制御してこの開発システムを使用
するときには、ネットワーク中の特殊な状態およびアプリケーションプロトコル
を有する、Ｄ２Ｂデバイスとして事実上動作する。このＤ２Ｂデバイスは、Ｄ２
Ｂアドレス（その物理的なリング位置とは異なる）や、それがＤ２Ｂシステムマ
スタであるかどうかなどの属性を有する。開発システムのデバイス構成要素８３
０は、クライアントアプリケーションがこれらの属性を設定し、取出すことがで
きるようにするオブジェクトである。さらに、開発システムは全体として、例え
ば、それがＤ２Ｂメッセージのテキスト翻訳を実行するかどうか、またはスイッ
チボックス構成要素を使用するかどうかなどの属性を有する。第１の属性は、事
実上ＡＲＳ８２８の属性であり、第２の属性は、開発システム全体としての属性
であるが、アプリケーションが使用している完全な開発システムについてのこの
情報をカプセル化するのはデバイス構成要素８３０である。これは、様々な属性
を設定し、取出すことができるようにするＡＰＩを表明する。

【０１１９】クライアントアプリケーションは、開発システムを使用するときには、システ
ム制御オブジェクト８３２を作成する。このオブジェクトが最初に行うのは、デ
バイスオブジェクトを作成することである。次いで、デバイスオブジェクト８３
０が、開発システムのその他の構成要素（すなわちメッセージ制御、ＡＲＳ、お
よびスイッチボックス）の作成を開始し、これらを互いに接続する。次いで、広
域ディレクタオブジェクト８２４（必要なら作成する）にアクセスし、空いてい
るＯＰＢオブジェクト８１４を取出す。最後に、そのＯＰＢのネットワークトラ
ンシーバ８１６にアクセスし、それ自体のメッセージ制御８２６とネットワーク
トランシーバオブジェクト８１６を互いにリンクする。これにより、ＯＰＢドラ
イバ構成要素８１２からデバイスオブジェクト８３０までの、全体の経路がもた
らされる。クライアントアプリケーションが終了したときに、デバイスオブジェ
クトは、それが接続する全ての構成要素のリンクを破棄し、そのシステムインス
タンス中のオブジェクトを破壊する。

【０１２０】デバイスオブジェクト８３０は、最初にどのＯＰＢオブジェクト（従ってどの
物理的ＯＰＢ）をクライアントアプリケーションのシステムインスタンスが使用
するかを決定する。デバイス８３０は、クライアントが、ＯＰＢオブジェクト、
そのトランシーバオブジェクト、およびコーデックオブジェクト（以下参照）に
アクセスすることができるようにするＡＰＩを表明する。しかし、ＰＣに取り付
けられたＯＰＢは複数存在することもあり、エンドユーザが特定のＯＰＢを選択
して使用したいと望むこともある。クライアントアプリケーションは、ディレク
タ構成要素８２４を介して、ＰＣに接続されたＯＰＢを指図し、１つを選択し、
そのシステムインスタンスにそれを使用するよう命令することができる。デバイ
スのＡＰＩがこれを行うための機能を提供し、デバイスオブジェクトは、新たに
指定されたハードウェア構成要素を、それ自体のシステム構成要素への接続を行
う。

【０１２１】デバイスオブジェクトは、その他の構成要素と同様に、接続されたハードウェ
ア構成要素（８０２、８０４）からクライアントアプリケーション８１０に、イ
ベントを渡す役割を果たさなければならない。デバイスオブジェクトは、自動応
答サーバ（ＡＲＳ）オブジェクト８３２を作成して、デバイスオブジェクト自体
に接続し、それによりＡＲＳがイベントをメッセージ制御８２６からデバイスオ
ブジェクト自体に渡すことができるようにする。ただし、デバイスオブジェクト
は一意的であり、その他の構成要素がそれら自体をデバイスオブジェクトに接続
し、そこから通告を受信することができるようにするために、明確に定義された
標準ＡＰＩを表明する。図８から分かるように、デバイスは、システム制御オブ
ジェクト８３２およびスイッチボックスオブジェクト８３４の両方に接続される
。システム制御オブジェクトは、デバイスオブジェクトを作成した後、標準ＡＰ
Ｉを使用してそれと結合する。同様に、デバイスオブジェクトがスイッチボック
スオブジェクトを作成した後、スイッチボックスオブジェクトは同じＡＰＩを使
用して、それ自体をデバイスオブジェクトに結合する。その後、デバイスオブジ
ェクトが受信した全ての通告は、自動的にシステム制御オブジェクトおよびスイ
ッチボックスオブジェクトに伝達される。

【０１２２】この標準機構は、任意の構成要素が、デバイスオブジェクトと結合するために
使用することができる。例えば、特定のデバイス構成要素と結合することによっ
てクライアントアプリケーションを「スパイ」することができるＧＵＩアプリケ
ーションを構築することもできる。これを行おうとする構成要素には、以下の２
つの条件がある。・この構成要素は、デバイスオブジェクトがその構成要素に通告を渡すための特
定のＡＰＩを実装しなければならない。・この構成要素は最初に、デバイスオブジェクトに接続するためにそのデバイス
オブジェクトへの何らかの参照を有さなければならない。

【０１２３】これは、そのデバイスオブジェクトへの参照を既に有しているその他の開発シ
ステムの構成要素が、その参照を供給し、または外部エージェント（ディレクタ
構成要素８２４など）がそれを供給することを意味する（これは、ディレクタが
実行中の全てのデバイスオブジェクトを認識しているようにするための機構が、
存在しなければならないことになることを意味する）。

【０１２４】（システム制御８３２）システム制御オブジェクト８３２は、クライアントの、開発システム環境との
インタフェースである。開発システムを使用したいと望むあらゆるクライアント
アプリケーション８１０は、そのアプリケーション中でシステム制御オブジェク
トをインスタンス化しなければならない。そして、このオブジェクトが、開発シ
ステムを制御するためのそのアプリケーションの「ブリッジ」またはインタフェ
ースとして働く。システム制御オブジェクト８３２は、クライアントアプリケー
ションに対して単一のＡＰＩを表明し、またシステム制御オブジェクトが、その
アプリケーションに通告を渡すことができるようにするための、定義されたＡＰ
Ｉを表明するようそのアプリケーションに求める。

【０１２５】システム制御オブジェクト８３２が作成されると、デバイスオブジェクト８３
０をインスタンス化し、これがその後、対応するアプリケーション８１０に特有
の開発システムの残りの部分の構築を開始する（上記ではシステムインスタンス
と呼ぶ）。システム制御オブジェクト８３２自体は、機能性を実質上含まず、単
にその全てのＡＰＩ呼出しを接続されたデバイスオブジェクトに委任するだけで
ある。システム制御オブジェクトの主な仕事は、アプリケーションからＡＰＩ機
能呼出し中に渡されたデータを、開発システム内部で使用される適当なフォーマ
ットに翻訳すること、およびその逆の翻訳をすることである。

【０１２６】システム制御オブジェクト８３２は、デバイスオブジェクト８３０を作成した
後は、そのデバイスの標準機構を使用してそれと結合し、これによりシステム制
御オブジェクトは、デバイスオブジェクトから通告を受信することができる。従
って、システム制御オブジェクトは以下の２つのインタフェースを表明する。・開発システムを制御するアプリケーション８１０のためのクライアントアプリ
ケーションインタフェース。・システム制御オブジェクトにイベントを通告するためのデバイスオブジェクト
によって使用される通告インタフェース。

【０１２７】クライアントアプリケーション８１０が最終的に終了したときに、システム制
御オブジェクト８３２は、そのデバイスオブジェクト８３０との接続を切断し、
次いでデバイスオブジェクトを破棄する。デバイスオブジェクトは、それ自体が
破棄される間に残りのシステムインスタンスを破棄し、「クリーンアップ」する
。

【０１２８】単一のアプリケーションが、１以上のシステム制御オブジェクト８３２をイン
スタンス化することも可能である。この場合には、作成されるそれぞれが、その
他のシステム制御オブジェクトのインスタンスとは別個の、それ自体の完全に一
意的なシステムインスタンスを構築することになる。異なるシステム制御オブジ
ェクトはそれぞれ、別個のインタフェースボード（ＯＰＢ８１４）を制御するた
めに使用することができる。

【０１２９】（スイッチボックス８３４）Ｄ２ＢＯｐｔｉｃａｌ技術の最も重要な利点の１つは、単一の光ファイバを
介して複数チャネルのソースデータを伝達できることである。ソースデータの送
信を管理制御するために、Ｄ２ＢソースデータプロトコルおよびＤ２Ｂスイッチ
ボックスサブデバイスが規定されている。あらゆるＤ２Ｂデバイスは、スイッチ
ボックスおよびそれと関連するソースデータプロトコルをサポートするためのソ
フトウェアを実装しなければならない。これは、この開発システムを介してＯＰ
Ｂを制御する任意のクライアントアプリケーションも、Ｄ２ＢＯｐｔｉｃａｌ
ネットワーク中で相互動作する「開発システムデバイス」（図９の電話エミュレ
ーション１０９′など）のための、このソフトウェアを実装しなければならない
ことを意味する。いうまでもなく、これは全ての開発システムのアプリケーショ
ンにとって望ましくない負担である。

【０１３０】この問題を多少とも解消するために、この開発システムは、スイッチボックス
クラスのオブジェクトを有する。スイッチボックスオブジェクト８３４は、開発
システムを使用するクライアントアプリケーションの代わりに、Ｄ２Ｂスイッチ
ボックスおよびソースデータ接続プロトコル論理を効果的にカプセル化し、実装
する。Ｄ２Ｂメッセージを受信すると、デバイスオブジェクト８３０はこれをス
イッチボックスオブジェクト８３４に渡し、次いで、そのメッセージがスイッチ
ボックスメッセージであるかどうかを調べる。スイッチボックスメッセージであ
る場合には、スイッチボックスオブジェクト８３４はこのメッセージを処理し、
必要な任意の動作を実行する、すなわち新しいスイッチボックスメッセージを光
ネットワーク上に伝達し、それ自体のネットワークトランシーバにあるソースデ
ータの経路指定を制御する。

【０１３１】デバイスオブジェクトは、スイッチボックスオブジェクトを作成したときに、
システムインスタンスが使用しているネットワークトランシーバオブジェクト８
１６へのアクセスをスイッチボックスに与える。そして、スイッチボックスオブ
ジェクトは、Ｄ２Ｂスイッチボックスメッセージに応答して、トランシーバの経
路指定情報テーブル（ｒｏｕｔｉｎｇｉｎｆｏｒｍａｔｉｏｎｔａｂｌｅ）
（ＲＩＴ）または等価な経路指定制御を自由に改変することができる。クライア
ントアプリケーション８１０が、そのシステムインスタンスに異なるＯＰＢを使
用するよう命令した場合には、デバイスオブジェクト８３０は、スイッチボック
スオブジェクトが常に正しいネットワークトランシーバオブジェクトへのアクセ
スを備え、それを操作することを保証する。

【０１３２】様々なトランシーバＩＣのＲＩＴは、様々（ポート数、ポートサイズ、構成）
であり、スイッチボックスは様々なトランシーバタイプのいずれにも接続するこ
とができるので、スイッチボックスオブジェクトは各トランシーバの型について
の特有の知識をカプセル化する。理想的には、スイッチボックスは一般的な挙動
のみを含むべきであり、各ネットワークトランシーバクラスは、スイッチボック
スがそのトランシーバのＲＩＴに関する特定の知識にアクセスできるようにする
ＡＰＩを表明すべきである。その場合には、スイッチボックスオブジェクトは、
この知識を動的に使用して、そのトランシーバにとって正しいＲＩＴ操作を実行
するはずである。しかし、現在のトランシーバおよびスイッチボックスの設計は
この考えをサポートしていない。

【０１３３】クライアントアプリケーション８１０は、図４に示すように、現実のデバイス
をエミュレートするために、ソースデータを光ネットワーク上に、または光ネッ
トワーク外で経路指定しようとすることがある。このソースデータは、トランシ
ーバＩＣ上の特定のポートを介して経路指定されることになり、論理的にＤ２Ｂ
サブデバイスと関連することになる。スイッチボックスオブジェクト８３４は、
この情報自体を決定することができ、従って、クライアントアプリケーションか
らこれを通知される。この目的のために、スイッチボックスオブジェクトは、そ
れを構成することができるようにするインタフェースを表明する。ユーザは、デ
バイスオブジェクト８３０を介してこのＡＰＩにアクセスすることができる。こ
のＡＰＩにより、ユーザは、どのＤ２Ｂサブデバイスが論理的にトランシーバＩ
Ｃに接続されるかを、それらが接続されるトランシーバ上の実際の入出力ポート
と同様に指定することができる。スイッチボックスオブジェクトは、ＡＲＳオブ
ジェクトを使用してＳＤＦのシステム仕様にアクセスし、特定のサブデバイスと
関連するソースデータタイプを決定する。このように、スイッチボックスオブジ
ェクトは、トランシーバのポートおよびそのポートと関連するデータのフォーマ
ットについての知識を有するので、ソースデータをサブデバイスから、またはサ
ブデバイスに経路指定する必要があるときに、どのＲＩＴチャネルを操作すべき
かを知っている。

【０１３４】ソースデータ接続の構築で、スイッチボックスが使用されるときには、スイッ
チボックスは、クライアントアプリケーションに通告を送信することによって通
知する。これらの通告は、接続が設定／破棄されたかどうか、その接続のＩＤ、
およびその接続の影響を受けるサブデバイスなどの情報を含む。さらに、その接
続と関連するチャネル情報（すなわちソースデータフィールド（図５）内のどの
チャネルをその接続が使用しているか）も与えられる。スイッチボックスオブジ
ェクト８３４は、これらの通告を、それが接続されたデバイスオブジェクト８３
０に渡す。デバイスオブジェクト８３０は、通告を受信するために、既にＡＲＳ
オブジェクト８２８に対してＡＰＩを表明している。スイッチボックスオブジェ
クトはこれと全く同じＡＰＩを使用する。

【０１３５】スイッチボックス自体は以下の３つのインタフェースを表明する。・スイッチボックスを構成するためのクライアントインタフェース。・初期化とスイッチボックスオブジェクトをネットワークトランシーバオブジェ
クトに接続するために、デバイスオブジェクトが使用する制御インタフェース。
・デバイスオブジェクトが通告をスイッチボックスに渡すための通告インタフェ
ース。

【０１３６】ここまでは、クライアントアプリケーション８１０が常にスイッチボックス構
成要素のサービスを使用することを望むものと仮定している。しかし、ユーザが
それ自体のスイッチボックスの論理および動作を実装することを望むこともある
ことから、そのようにならないこともある。これをサポートするために、その主
要なＡＰＩ中のデバイスオブジェクト８３０は、スイッチボックス構成要素の使
用を切替えるための機能を設ける。この属性がオフである場合には、デバイスオ
ブジェクトはスイッチボックス構成要素を作成しない（それが存在すれば破棄す
る）。その後、属性がオンに切り替わった場合に、スイッチボックスオブジェク
トを作成することになる。オフに切り替わった場合には、クライアントアプリケ
ーションは、トランシーバのレジスタを操作し、Ｄ２Ｂメッセージを適切に取り
扱うことによって、そのアプリケーション中でスイッチボックスの挙動を実装す
る役割を全面的に担う。

【０１３７】（デバイスデータベース８３６）プロトコルおよび機能が、ある範囲の特定の製品が事前に配列したフォーマッ
トで符号化されることによって、実際に実装するところのデバイスデータベース
８３６を設けることもできる。ユーザがエミュレートのための専用アプリケーシ
ョンをプログラミングすることなく、デバイスの記述である「ライブラリ」を、
ＡＲＳオブジェクト８２８とともに使用して、選択された製品を開発システム内
でエミュレートすることができる。製造業者は、このデバイスの記述であるライ
ブラリを共用し、新製品を開発するにつれて拡張し、互換性のある製品の開発を
大きく促進することができる。

【０１３８】（クライアントイベント）システムインスタンスは、クライアントアプリケーションからのコマンドに応
答する単なる受動システムではない。システムインスタンスは、任意の時間に起
こるイベントを、システム制御オブジェクト８３２を介して非同期にクライアン
トに通知することができる。これらのイベントは、外部のＤ２ＢＯｐｔｉｃａ
ｌネットワーク上、インタフェースファームウェア８２２中、およびシステムイ
ンスタンス自体の中で起こった事態から、発生させることができる。この例では
、システムインスタンス中のイベントを、以下のカテゴリに一般化することがで
きる。・受信されたＤ２Ｂメッセージ。・クライアントアプリケーションから送信されたメッセージについてのＤ２Ｂメ
ッセージの送信結果。・ネットワーク管理状態の変化およびその変化の原因。多くの様々なイベントが
このカテゴリに入る。多くの様々な事柄が、状態の変化、例えばロックはずれ／
確立、タイムアウト、ネットワークエラーなどを引き起こすからである。・ネットワークトランシーバのレジスタの書込み。これらは、任意のネットワー
クトランシーバのレジスタがうまく書き込まれたときに発生する。・内部エラー。例えば、クライアントアプリケーションが、何らかのシステムイ
ンスタンスのプロパティに無効値を設定しようとした場合、または内部システム
のフレームワークにエラーが発生した場合など。

【０１３９】以下の表は、システムがクライアントアプリケーションに信号を送ることがで
きるイベントの一部を定義したものである。

【０１４０】

【表１】

【０１４１】

【表２】

【０１４２】

【表３】

【０１４３】（開発システムの初期化例）図１１は、初期化中の開発システムの、様々な構成要素モジュール間の動作お
よび通信のシーケンスを示している。各構成要素の動作は、それぞれの時間線上
に表し、図８と同じ参照符で表示してある。

【０１４４】ステップ１１００で、クライアントアプリケーション８１０は、運用を開始す
るために、システム制御オブジェクト８３２のインスタンスを作成する。１１０
２で、システム制御オブジェクトが、デバイスオブジェクト８３０を作成し、１
１０４でデバイスオブジェクトが、ディレクタオブジェクト８２４を作成する。

【０１４５】１１０６で、ディレクタオブジェクト８２４が、ＯＰＢオブジェクト８１４を
作成する。１１０８から１１１４で、ＯＰＢオブジェクトは、ネットワークトラ
ンシーバオブジェクト８１６、コーデックオブジェクト８１８を作成し、インタ
フェースボードのファームウェアエレメント８２２およびネットワーク管理エレ
メント８２０を初期化する。

【０１４６】１１１６および１１１８で、デバイスオブジェクト８３０はさらに、ＡＲＳオ
ブジェクト８２８およびメッセージ制御８２６をそれぞれ作成する。１１２０で
、ＡＲＳオブジェクト８２８は、対応するメッセージ制御オブジェクト８２６と
のリンクを確立する。

【０１４７】１１２４で、デバイスオブジェクト８３０は、コマンドＧｅｔＣｏｍｐｏｎｅ
ｎｔ（“ＯＰＢ”，“０”）をディレクタ８２４に送信し、１１２６で、ディレ
クタは、予約されたＯＰＢ８１４の識別をこのアプリケーションに戻す。１１２
８で、デバイスオブジェクト８３０は、ＯＰＢ８１４にそれが空いていることを
確認するよう要求し、ステップ１１３０で確認を受信する。１１３２で、デバイ
スオブジェクト８３０は、開発システムのこのインスタンスの運用の準備ができ
ていることをシステム制御８３２に通知する。

【０１４８】（開発システムの動作例）図１２は、ネットワーク上へのＤ２Ｂメッセージの送信を示している。１２０
０で、クライアントアプリケーションは、システム制御８３２に対して機能呼出
しを行い、送信したいと望む、「ＣＤチェンジャ」にアドレス指定された「ｐｌ
ａｙ」「ＦＯＲＷＡＲＤ」などのＤ２Ｂメッセージを、テキスト表現で提供する
。１２０２で、システム制御８３２は、この呼出しをデバイスオブジェクト８３
０に渡し、デバイスオブジェクトが１２０４でこれをＡＲＳオブジェクト８２８
に渡す。ＡＲＳオブジェクト８２８は、設定されている警告レベルに従って、ま
たシステム記述ファイル８３８中のプロトコルおよびシステム記述に従ってこの
メッセージを検査する。このメッセージは受諾または拒絶される。

【０１４９】エラーが拒絶された場合には、１２０６で、ＡＲＳ８２８はデバイスオブジェ
クト８３０にエラーコードを送信し、１２０８でデバイスオブジェクトは同じエ
ラーコードをシステム制御オブジェクトに渡す。１２１０で、関連するエラーコ
ードを含むイベントが、クライアントアプリケーション８１０に通信される。

【０１５０】メッセージが警告レベルおよびシステム記述ファイルに従うテストに合格した
と仮定すると、ＡＲＳ８２８はテキストフォーマットのメッセージを１６進数に
翻訳し、１２１２でこれをメッセージ制御８２６に渡す。上記のメッセージの例
について１６進数フォーマットは、０ｘ１ｃ８、０ｘ１９０、０ｘ０ｅ、０ｘ４
２、０ｘ９０、０ｘｃ３、０ｘ７５となり、ここで、最初の２つのコードは送信
元アドレスおよび送信先アドレスである。１２１４で、メッセージ制御オブジェ
クト８２６は、メッセージをネットワークトランシーバオブジェクト８１６に渡
し、１２１６でネットワークトランシーバオブジェクトがこれをＯＰＢオブジェ
クト８１４に渡す。ここで、ＯＰＢオブジェクト８１４がＯＰＢドライバを使用
してメッセージをインタフェースボードおよびＤ２ＢＯｐｔｉｃａｌネットワ
ークに送信する。

【０１５１】１２１８で、送信結果が、ネットワークトランシーバオブジェクトからメッセ
ージ制御オブジェクト８２６に戻される。ここから、送信結果は、ステップ１２
２０から１２２４で、ＡＲＳ８２８およびデバイスオブジェクト８３０を介して
、システム制御８３２に渡される。最後に、１２２６で、システム制御オブジェ
クト８３２が、伝送情報および完全なメッセージの表現を含むイベントをクライ
アントアプリケーション８１０に送信する。

【０１５２】当業者ならば、本発明の趣旨および範囲内で、上記実施形態の多くの変更形態
が可能であることを容易に理解するであろう。さらに、記載した開発システムお
よびその重要な任意の機能を、Ｄ２ＢＯｐｔｉｃａｌシステム以外のプロトコ
ルで使用するために、またＣｏｎａｎ製品の範囲外のトランシーバ構成要素に合
わせて、適合させることもできる。

【図面の簡単な説明】

次に、添付の図面に関連して、例示のみを目的として本発明の実施形態につい
て述べる。

【図１】様々なデバイスが環状ネットワーク中で通信する範囲を含むローカル通信シス
テムを示すブロック概略図である。

【図２】図１のシステム中で使用される、制御およびソースデータアーキテクチャを示
す図である。

【図３】統合インタフェースを備えたステーションを示す図である。

【図４】図１のインタフェースモジュールの１つを示す概略図である。

【図５】既知のＤ２ＢＯｐｔｉｃａｌフォーマットに従って伝送される、デジタル信
号のフレーム構造を示す図である。

【図６】図１のシステム中の装置間で伝送される、デジタル信号のフレーム構造を示す
図である。

【図７】図６のフレーム構造内で伝達される制御フレームの構造を示す図である。

【図８】図１のネットワークと互換性のある装置を開発する際に使用される、製品開発
およびテストツールの、ソフトウェアおよびハードウェアエレメントを示す図で
ある。

【図９】開発中の製品のエミュレーションにおいて、開発ツールの使用を示す図である
。

【図１０】図１のネットワークとの互換性を検証するために、いくつかのデバイスをテス
トする際に、製品開発ツールの使用を示す図である。

【図１１】開発システムを初期化する際の様々な構成要素モジュールの動作を示す図であ
る。

【図１２】製品のエミュレーションの一部として、メッセージを送信する際の構成要素モ
ジュールの動作を示す図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＤＥ，ＧＢ，ＪＰ，ＵＳ (71)出願人ＳｔｉｒｌｉｎｇＨｏｕｓｅ，ＳｔｉｒｌｉｎｇＲｏａｄＴｈｅＳｕｒｒｅｙＲｅｓｅａｒｃｈＰａｒｋＧｕｉｌｄｆｏｒｄ，ＳｕｒｒｅｙＧＵ２５ＲＦＥｎｇｌａｎｄ (72)発明者スクミドットマークスジョアンヌズイギリスケイティー６４ビーエックスサリーサービショングローブロード 15 Ｆターム(参考） 5B014 EA06 EB03 FA05 FB03 GD05 GD22 GD23 GD49 HC05 5B042 GA12 GB09 GC08 GC12 HH07 HH12 5B089 GA21 JB03 JB05 JB07 KA12 KB09 KC15 KC28 KC47 KF04 MC15 5K034 CC02 CC05 DD03 KK27 TT02 5K035 BB03 EE13 HH02 HH07 【要約の続き】ケーションプロトコルに加えて、ツールは、正常コマンドの範囲をさらに限定するために、ネットワーク上に存在するまたはエミュレートされるデバイスの特定の数および型を規定するネットワークシステムの記述を記憶する。

Claims

【特許請求の範囲】

【請求項１】開発中の特定の製品をエミュレートするために機能している
通信ネットワークに接続されたハードウェアネットワークインタフェースととも
に使用されるコンピュータに実装された構成要素を含むシステムであって、前記
構成要素が、クライアントプログラムとネットワーク上の他のデバイスにメッセ
ージを送信するためのネットワークインタフェースとの間のインタフェースを提
供し、プロトコルデータベースを含み、ネットワーク上に送信するよう命令され
ている違法メッセージを検出するために、前記構成要素のうちの少なくとも１つ
がクライアントプログラムから命令されたメッセージをプロトコルデータベース
を参照することによって処理することを特徴とするシステム。
【請求項２】請求項１に記載のシステムであって、前記プロトコルデータ
ベースにより、ネットワーク中のデバイスの機能に特有のアプリケーションレベ
ルのプロトコルを規定し検査することを特徴とするシステム。
【請求項３】請求項２に記載のシステムであって、前記プロトコルデータ
ベースにより、エミュレートされているデバイスの特定の型と矛盾するためにネ
ットワーク中の様々なデバイスの様々な機能に特有の様々なアプリケーションレ
ベルのプロトコルを規定し検査することを特徴とするシステム。
【請求項４】請求項３に記載のシステムであって、完成した製品としてま
たはエミュレーションによってネットワーク中に存在する他のデバイスの型また
は機能を特定するシステム記述をさらに含み、ネットワーク上に送信するよう命
令されている不適切なメッセージを検出するために前記構成要素の少なくとも１
つがクライアントから命令されたメッセージを前記システム記述を参照して処理
することを特徴とするシステム。
【請求項５】請求項１ないし４のいずれかに記載のシステムであって、ネ
ットワーク中の複数のステーション間の拡張された協調動作が所望の結果を達成
するために必要である場合に、プロトコルが少なくとも１つの挙動のシーケンス
を規定することを特徴とするシステム。
【請求項６】請求項５に記載のシステムであって、特定のデバイスの機能
とは無関係に、前記シーケンスが、ネットワーク管理のための少なくとも１つの
シーケンスを含むことを特徴とするシステム。
【請求項７】請求項５または６に記載のシステムであって、前記シーケン
スが、前記メッセージに加えてネットワークを介して伝達されるデータストリー
ムの経路指定を確立するための少なくとも１つの挙動シーケンスを含むことを特
徴とするシステム。
【請求項８】請求項５、６、または７に記載のシステムであって、クライ
アントプログラムとの関与なしに、前記挙動シーケンスを自動的に実装する特定
の構成要素を含むことを特徴とするシステム。
【請求項９】請求項８に記載のシステムであって、ネットワークから受信
した全てのメッセージが各特定の構成要素に渡され、さらにその特定の構成要素
により実装される挙動シーケンスと関連がない場合にはクライアントプログラム
に渡されることを特徴とするシステム。
【請求項１０】請求項１ないし９のいずれかに記載のシステムであって、
前記構成要素が、所定の規則に従って互いにメッセージを交換する、プログラミ
ングオブジェクトの形式であることを特徴とするシステム。
【請求項１１】請求項１ないし１０のいずれかに記載のシステムであって
、ある構成要素が同一のコンピュータハードウェア内で動作する様々なアプリケ
ーションの間で共用することができ、他の構成要素がひとつの動作するアプリケ
ーションによって予約されることを特徴とするシステム。
【請求項１２】請求項１１に記載のシステムであって、共用される構成要
素が、特定のネットワークインタフェースハードウェアとのインタフェースを提
供する構成要素を含むことができることを特徴とするシステム。
【請求項１３】請求項１ないし１２のいずれかに記載のシステムであって
、検出された違法メッセージを送信するか阻止するかを決定するために動作レベ
ルを設定することができることを特徴とするシステム。
【請求項１４】請求項１ないし１３のいずれかに記載のシステムであって
、検出された違法メッセージを報告するか否か、例えばクライアントプログラム
に報告するか否か、決定するために報告レベルを設定することができることを特
徴とするシステム。