JP2001520777A

JP2001520777A - 遠距離通信ネットワークにおいてクライアントプログラムをネットワークデバイスにインターフェースするインターフェース

Info

Publication number: JP2001520777A
Application number: JP54578998A
Authority: JP
Inventors: カウァン，ダン
Original assignee: エムシーアイワールドコムインコーポレーテッド
Priority date: 1997-03-24
Filing date: 1998-03-17
Publication date: 2001-10-30
Also published as: EP0972385A2; US6389129B1; CA2285484A1; AU6471598A; US20020031214A1; WO1998043390A2; WO1998043390A3

Abstract

(57)【要約】包括的なインターフェースが、多数のクライアントアプリケーションプログラムを多数のネットワークデバイスにインターフェースすることを提供する。クライアントアプリケーションプログラムは、互いに異なってもよく、かつ、ネットワーク復旧とネットワークメンテナンスとネットワーク管理とを実行するためのアプリケーションプログラムを含んでもよい。ネットワークデバイスは、異なるデバイスタイプのものであってもよい。インターフェースは、クライアントアプリケーションプログラムとネットワークデバイスとの間における通信が目的地の要求と互換性があるように、該通信を変換する。該インターフェースは、（自動検査メカニズムおよびデータリンク管理メカニズムのような）追加機能を具備してもよい。

Description

【発明の詳細な説明】遠距離通信ネットワークにおいてクライアントプログラムをネットワークデバイスにインターフェースするインターフェース技術分野本発明は、一般的には、遠距離通信ネットワークに関し、かつ、より詳細には、遠距離通信ネットワークにおいてクライアントプログラムをネットワークデバイスにインターフェースするインターフェースに関する。本発明の背景（電話ネットワークのような）遠距離通信ネットワークは、多数の異なる構成要素を具備する。一般的に、遠距離通信ネットワークは、ネットワークデバイスを具備する。該ネットワークデバイスは（通信を容易にする）リンクによって相互連結されている。ネットワークデバイスの例は、デジタルクロスコネクト（ＤＸＣ）と多重送信装置とライン終端装置とコンピュータシステムとファイバ送信システムとである。ここで使用される「リンク」は、ネットワークデバイス間における（ネットワークトラヒックを伝える）物理的接続である。単一リンクは、多数の中継線を具備してもよい。ここで、「中継線」は、通信の論理的チャネルであり、１または２以上のネットワークデバイスおよび／または１または２以上の（ネットワークデバイス間における）リンクを横断する能力を伴う。上述されたように、ネットワークデバイスは、多数の異なるタイプからなってもよい。（外部コマンドに基づいて通信中継線を切り換える）ＤＸＣについて考える。多くの異なるタイプのＤＸＣが存在し、かつ、（ＤＸＣを販売する）多くの異なる販売者が存在する。一般的に、各販売者のデバイスは、該デバイスに独特なコマンドセットと（該コマンドを具備するデータメッセージに対して）該デバイスに独特なフォーマットとを有する。大抵の遠距離通信ネットワークは、様々なネットワークデバイスを利用する。そのため、共通の制御システムを用いてそのようなデバイスを管理することは困難である。例えば、（故障の後に遠距離通信ネットワーク内のトラヒックを復旧する）復旧システムは、（復旧を実現するために使用される）異なるタイプのデバイスの各々と通信できなくてはならない。これらのデバイスは、ＤＸＣを具備する。中央制御システムは、（ネットワークにおいて故障の影響を及ぼされたエリア内の）各ＤＸＣへコマンドを送信できなくてはならず、かつ、該各ＤＸＣからメッセージを受信できなくてはならない。中央制御システムは、デバイスのタイプと（そのデバイスに対する）コマンドのフォーマットとを識別できなくてはならない。加えて、中央制御システムは、異なるタイプのデバイスからの異なるフォーマットにおけるメッセージを受信できなくてはならず、かつ、共通の包括的な方法でこれらのメッセージを翻訳処理できなくてはならない。これらの困難性は、ネットワークデバイスの多くが（与えられたバージョンのソフトウェアを実行する）プログラマブルデバイスであることによって、複雑化される。同一のデバイスが異なるバージョンのソフトウェアを実行するかもしれず、故に、追加の互換性問題が発生する。本発明の概要本発明は、（多数のクライアントプログラムを多数のネットワークデバイスにインターフェースする）共通インターフェースを提供することによって、先行技術の困難性を解消する。該インターフェースは、共通フォーマットでクライアントプログラムと通信し、かつ、デバイス特有フォーマットでネットワークデバイスと通信する。該インターフェースは、ネットワークデバイスのデバイス特有フォーマットからの通信を、クライアントプログラムの共通フォーマットへ変換できる。同様に、該インターフェースは、共通フォーマットにおけるクライアントプログラムからの通信を、ネットワークデバイスのデバイス特有フォーマットにおける通信へ変換できる。該インターフェースは、また、最適のデータリンクを利用するために、（データリンクの自動検査および自動監視のような）追加機能を具備してもよい。本発明の第１特徴によれば、プログラムをネットワークデバイスにインターフェースする方法が、遠距離通信ネットワークにおいて、コンピュータシステムによって実行される。インターフェースは、プログラムをネットワークデバイスにインターフェースするために提供される。ここで、各ネットワークデバイスは、デバイス特有通信フォーマットを有する。（選択されたネットワークデバイスに行先を定められた）第１通信は、インターフェースにおいて、プログラムから、第１フォーマットで受信される。該インターフェースは、第１通信を、第１フォーマットから、第２フォーマットへ変換する。第２フォーマットは（通信が行先を定められた）選択されたネットワークデバイスのデバイス特有通信フォーマットである。そして、変換された通信は、第２フォーマットで、インターフェースから、選択されたネットワークデバイスへ送られる。本発明の他の特徴によれば、遠距離通信ネットワークは、プロセッサ上で実行されるプログラムを具備する。プログラムは、通信のための通信フォーマットを採用する。遠距離通信ネットワークは、また、多数のネットワークデバイスを具備する。ここで、各ネットワークデバイスは、デバイス特有通信フォーマットを有する。プログラムとネットワークデバイスとの間における通信を容易にするために、プログラムをネットワークデバイスにインターフェースするためのインターフェースが、遠距離通信ネットワークにおいて提供される。インターフェースは、変換器を具備する。該変換器は、（ネットワークデバイスへ行先を定められた）プログラムからの通信を、ネットワークデバイスのデパイス特有通信フォーマットへ変換する。本発明の更なる特徴によれば、ネットワークデバイスと（プログラムを実行する）プロセッサと（ネットワークデバイスへ通じる）データリンクとを有するコンピュータ実行方法が、遠距離通信ネットワークにおいて実行される。プログラムをネットワークデバイスにインターフェースするインターフェースが提供される。該インターフェースは、データリンクのうちのどのデータリンクが最も信頼性があるかを判断し、かつ、該データリンクを（ネットワークデバイスとの通信に対して使用されるべき）主要リンクとして決定する。データリンクのうちの他の１つのデータリンクが（主要リンクが故障したときにネットワークデバイスとの通信に対して使用されるべき）第２リンクとして指定される。図面の簡単な説明本発明に対する例示的な実施形態が、以下の図面に関連して、より詳細に以下に説明される。図１は（本発明による第１オプションを実施するために適切な）遠距離通信ネットワークの一部を図解するブロック図である。図２は、図１のコンピュータシステムをより詳細に図解するブロック図である。図３は（本発明による第２オプションを実施するために適切な）遠距離通信ネットワークの一部のブロック図である。図４は、本発明の例示的な実施形態のＮＩＦＴＥの主要な構成要素を図解する。図５は、図４の共通インターフェースモジュールのためのデータフロー図である。図６は、図５のQueue_Input_Cmdsオブジェクトによって実行されるステップを図解するフローチャートである。図７は、図５のParse_Input_Cmdsオブジェクトによって実行されるステップを図解するフローチャートである。図８は、図５のNIFTE_Data_Managerオブジェクトによって実行されるステップを図解するフローチャートである。図９は、図５のAdminister_Alarm_Subscriber_Listオブジェクトによって実行されるステップを図解するフローチャートである。図１０は、図５のNIFTE_Shutdownオブジェクトによって実行されるステップを図解するフローチャートである。図１１Ａは、図５のProcess_State_ChangeオブジェクトがChange_Readiness_M ode_Cmdを受信するときに該オブジェクトによって実行されるステップを図解するフローチャートである。図１１Ｂは、図５のProcess_State_ChangeオブジェクトがChange_Ex_State_Cm dを受信するときに該オブジェクトによって実行されるステップを図解するフローチャートである。図１２は、図５のVerify_Device_Cmdsオブジェクトによって実行されるステップを図解するフローチャートである。図１３は、図４のデバイス特有インターフェースモジュールの構成要素ためのデータフロー図である。図１４Ａおよび図１４Ｂは、検査コマンドが受信されるときにデバイス特有インターフェースによって実行されるステップのフローチャートを表す。図１５Ａおよび図１５Ｂおよび図１５Ｃは、ポート接続コマンドまたはポート接続断コマンドが受信されるときにデバイス特有インターフェースモジュールによって実行されるステップのフローチャートを示す。図１６は、要求されていないアラームがＮＩＦＴＥによって受信されるときに実行されるステップを図解するフローチャートである。図１７は、図４の初期化モジュールの構成要素のためのデータフロー図である。図１８は、初期化モジュールによって実行されるステップを図解するフローチャートである。発明の詳細な説明ここで説明される本発明の例示的な実施形態は（クライアントアプリケーションプログラムを多数のネットワークデバイスにインターフェースする）包括的なインターフェースを提供する。クライアントアプリケーションプログラムは（遠距離通信ネットワークの復旧とメンテナンスと管理とを含む）異なる機能を実行してもよい。該インターフェースは、電話ネットワークにおける使用に対して特によく適合される。そこで、以下の討論のために、「該インターフェースが電話ネットワークにおいて利用される」ということが仮定される。該インターフェースは、（クライアントアプリケーションプログラムによって共有される）共通フォーマットにおいて生じる通信を、ネットワークデバイスのデバイス特有フォーマットへ変換する。逆に、該インターフェースは、デバイス特有フォーマットにおける（ネットワークデバイスからの）通信を、クライアントアプリケーションプログラムの共通フォーマットにおける通信へ変換する。結果として、該インターフェースは、クライアントアプリケーションプログラムとネットワークデバイスとの間において、制約のない通信を可能とする。クライアントアプリケーシヨンプログラムは、様々なネットワークデバイスの各々との通信のためのコードと構成情報とを有する必要がない。同様に、ネットワークデバイスは（クライアントアプリケーションプログラムと直接通信するための）追加構成要素を有する必要がない。故に、該インターフェースは、ネットワークデバイスと通信する（クライアントアプリケーションプログラムの）能力を、大いに簡単化する。該インターフェースは、コンピュータが実行可能な命令において実現されてもよい。該インターフェースは、ソフトウェアまたはハードウェアまたはファームウェアまたはそれらの組み合わせにおいて実現されてもよい。より詳細に以下に説明されるように、該インターフェースの多数の実体が、与えられた遠距離通信ネットワーク内に存在してもよい。該インターフェースは、検査要求を（外部からの刺激なしに）周期的な間隔で生成する自動検査機能のような追加機能を具備してもよい。該検査要求は、ネットワークデバイスの状態と構成とに関する情報を検索するために、ネットワークデバイスを検査する。該インターフェースは、また、（該インターフェースをネットワークデバイスと接続する）データリンクを管理するための機能を具備してもよい。この機能は、インターフェースが「（与えられたネットワークデパイスへ通じるデータリンクのうちの）どのデータリンクが最も信頼性があるか」ということを判断することを、可能にする。この最も信頼性のあるデータリンクは、ネットワークデバイスへの（および、ネットワークデバイスからの）通信を伝えるための主要リンクとして指定される。第２のリンクもまた、（主要リンクが故障したときに活動中となる）バックアップリンクとして働くために指定される。該インターフェースは、遠距離通信ネットワーク内のイベントおよび状態を変化させることに応答して、「主要リンクおよび第２リンクとしてどのリンクが指定されるのか」ということを変化させる知的機能を具備する。図１は、本発明に基づく第１オプションを示す遠距離通信ネットワークの一部を表す。第２オプションは、より詳細に以下に討論される。コンピュータシステム１０は、ネットワーク資源１２にインターフェースされる。コンピュータシステム１０は、多数のクライアントアプリケーションプログラム１４Ａ〜１４Ｎを実行する。クライアントアプリケーションプログラム１４Ａ〜１４Ｎは、遠距離通信システムの動的ネットワーク復旧を実行するためのアプリケーションプログラム１４Ａを具備してもよい。復旧アプリケーションプログラム１４Ａは、ネットワークデバイスからアラームを受信する。そして、故障の後に遠距離通信ネットワーク上のトラヒックを復旧するために、該デバイスへコマンドを送信する。クライアントアプリケーションプログラムは、また、メンテナンスアプリケーションプログラム１４Ｂを具備してもよい。メンテナンスアプリケーションプログラム１４Ｂは、遠距離通信システム内のネットワークデバイスへ、メンテナンスコマンドを送信する。当業者は、「異なるクライアントアプリケーションプログラムがコンピュータシステム１０上で実行されてもよい」ということと、「追加のクライアントアプリケーションプログラムもまたコンピュータシステム上で実行されてもよい」ということとを認識する。更に、アプリケーションプログラムは、単一のコンピュータシステム上で実行される必要はなく、むしろ（互いに通信中である）多数のコンピュータシステム上で実行されてもよい。コンピュータシステムは（ネットワークにおける現在の構成およびトポロジーを反映する）リアルタイムネットワークデバイスデータを記憶する。このデータは、独立したデータベース１６において組織化されてもよい。コンピュータシステム１０は、また、ネットワークアイテムフロントエンド（network item front end：ＮＩＦＴＥ）として知られるインターフェースとして機能する。ＮＩＦＴＥ１８は、アプリケーションプログラムとネットワークデバイスとの間における共通インターフェースとして働く。ＮＩＦＴＥ１８の詳細は、以下に説明される。ネットワーク資源１２は、ＮＩＦＴＥ１８を介して、コンピュータシステム１０と通信する。ネットワーク資源１２は、多数のネットワークデバイス２０Ａ〜２０Ｎを具備する。当業者は、「ネットワークデバイスは、デジタルクロスコネクト（ＤＸＣ）を含む多数の異なるタイプの遠距離通信デバイスのうちの如何なるものであってもよい」ということを認識する。上述されるように、ＤＸＣは（トラヒックを経路決定するために）様々なポートの間で中継線を切り換えるデバイスである。ＤＸＣは、ネットワーク復旧において、欠くことのできない機能を果たす。ＤＸＣは、該ＤＸＣのポート上のトラヒックを監視でき、かつ、故障が検出されるとアラームを生成することができる。加えて、ＤＸＣは、ネットワークトラヒックを復旧するために、復旧クライアントアプリケーションプログラム１４Ａからコマンドを受信しかつ処理してもよい。以下の討論のために、「ネットワークデバイス２０Ａ〜２０ＮはＤＸＣである」ということが仮定される。ＮＩＦＴＥ１８は、各ネットワークデバイスへの（通信ゲートウエー２４を介する）バックアップ通信経路を有する。ゲートウエー２４は、ＮＩＦＴＥ１８とネットワーク資源１２との間において、ネットワーク集信機インターフェースとして働く。通信リンク２１は、通信ゲートウエー２４とＮＩＦＴＥ１８との間における接続を提供し、かつ、通信リンク２３は、サイトコントローラ２２Ａ〜２２ＮとＮＩＦＴＥとの間における接続を提供する。通信リンク２１，２３は、規格Ｘ．２５接続であってもよい。サイトコントローラ２２Ａ〜２２Ｎは、ネットワークデバイス２０Ａ〜２０Ｎへのアクセスを提供する。独立したサイトコントローラが、各場所に置かれている。図２は、図１のコンピュータシステム１０に対して適切なコンピュータシステム構成を示す。該コンピュータシステムは、中央処理ユニット（ＣＰＵ）２６を具備する。該ＣＰＵ２６は（ビデオディスプレイ２８とマウス３０とキーボード３２とを含む）多数の周辺デバイスと通信する。ＣＰＵ２６は、また、メモリ３４および第２記憶装置３６へのアクセスを有する。ＮＩＦＴＥ１８を実現するためのオブジェクトが、クライアントアプリケーションプログラム１４Ａ〜１４Ｎと共に、メモリ３４内に記憶されている。リアルタイムネットワークデバイスデータ１６が、第２記憶装置３６内に記憶されていてもよく、または、主要メモリ３４内に常駐していてもよい。コンピュータシステム１０は、更に、モデム３８を具備してもよい。モデム３８は、コンピュータシステムが電話線上で通信を送受信することを可能とする。コンピュータシステム１０は、また、ネットワークアダプタ４０を具備してもよい。ネットワークアダプタ４０は（コンピュータ資源を有する）ネットワークにインターフェースする。当業者は、「図２に表されるコンピュータシステム構成は、単なる実例を意図するものであり、本発明の限定を意図するものではない」」ということが認識する。本発明は、他のコンピュータシステム構成を伴って実施されてもよい。上述されたように、クライアントプログラム１４Ａ〜１４ＮおよびＮＩＦＴＥ１８は、異なる機械上に存在してもよい。更に、コンピュータシステム１０は、単一のプロセッサまたはパーソナルコンピュータシステムとしてよりも、むしろ、分散コンピューティングシステムとして実現されてもよい。図３は、本発明に基づく第２オプションを表す。第２オプションでは、ＮＩＦＴＥの多数の実体が提供される。図３に表される実施形態では、各ネットワークデバイス２０Ａ〜２０Ｎが（該各ネットワークデバイス２０Ａ〜２０Ｎ自身に対応する）ＮＩＦＴＥを有するように、ＮＩＦＴＥ１８Ａ〜１８Ｎが提供される。ＮＩＦＴＥの各実体は、同じコードを具備するが、独立したプロセスとして（コンピュータシステム１０によって）実行される。各クライアントアプリケーションプログラム１４Ａ〜１４Ｎは、与えられたネットワークデバイス２０Ａ〜２０Ｎに関連するＮＩＦＴＥを介して、該ネットワークデバイス２０Ａ〜２０Ｎと通信してもよい。図３に示されるように、各クライアントアプリケーションプログラムは、各ＮＩＦＴＥとの接続を有する。更に、各ＮＩＦＴＥは、リアルタイムネットワークデバイスデータデータベース１６へのアクセスを有する。各ＮＩＦＴＥ１８Ａ〜１８Ｎは、２つの冗長なデータリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎを介して、該各ＮＩＦＴＥ１８Ａ〜１８Ｎに対応するネットワークデバイス２０Ａ〜２０Ｎへ接続される。該データリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎは、例えば、Ｘ．２５データリンクであってもよい。そのような各データリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎは、（関連するネットワークデバイス２０Ａ〜２０Ｎに対する）主要リンクまたは第２リンクであるとして指定される。ＮＩＦＴＥ１８Ａ〜１８Ｎとネットワークデバイス２０Ａ〜２０Ｎとの間における通信は、１つのリンク上で、一度に実行される。このとき、使用されていないリンクは、バックアップ第２リンクとして働く。各リンク対に対して、ＮＩＦＴＥは、リンクのうちの片方を、主要リンクとして指定し、かつ、他のリンクを、第２リンクとして指定する。好ましくは、ＮＩＦＴＥは、より信頼性のあるリンクを、主要リンクとして指定する。一般に、ＮＩＦＴＥがネットワークデバイス２０Ａ〜２０Ｎとの通信を確立するときに、該ネットワークデバイスへ通じるリンクの対における両方のリンク上で、接続要求が送信される。そして、接続を伴って応答する最初のリンクが主要リンクとして指定され、他のリンクが第２リンクとして指定される。もし、主要リンクが故障したならば、ＮＩＦＴＥは、該ＮＩＦＴＥの通信を、指定された第２リンクへ自動的にシフトし、かつ、（該第２リンクが新たな主要リンクであるように）リンクの指定を変更する。「バイナリデータリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎの各々は、多数の論理的な（通信の）チャネルを具備してもよい」ということが認識されるべきである。例えば、アルカテル（Alcatel）ＤＸＣデバイスは、１つのリンクあたり４つの論理的チャネルをサポートする。論理的チャネルの数は、ネットワークデバイスのタイプに依存してもよい。上述されたように、通信ゲートウエー２４は、個々のネットワークデバイス２０Ａ〜２０Ｎに対するデータリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎが故障した場合に、バックアップ通信経路として働く。各ＮＩＦＴＥ１８Ａ〜１８Ｎは、ネットワークデバイス２０Ａ〜２０Ｎに対して、管理機能およびメンテナンス機能を提供できる。メンテナンスシステム１４Ｂは、メンテナンス機能を実行するために、コマンドを生成する。該メンテナンス機能は、例えば、バイナリリンクの許可および不許可や、バイナリリンクの動的構成や、内部構成パラメータの変更である。各ＮＩＦＴＥは、また、周期的な間隔で、ネットワークデバイスの自動検査を行ってもよい。図４は、ＮＩＦＴＥ１８の（高い水準での）内部構成図を表す。ＮＩＦＴＥ１８の各実体は、３つの主要なソフトウェアモジュール（共通インターフェースモジュール５０とデバイス特有インターフェースモジュール５２と初期化モジュール５４と）からなる。共通インターフェースモジュール５０は、クライアントアプリケーションプログラム１４Ａ〜１４Ｎから共通フォーマット構文でコマンドを受信することに対して責任を負っている。共通インターフェースモジュール５０は、ネットワークデバイス２０Ａ〜２０Ｎへコマンドを送るために、デバイス特有インターフェースモジュール５２と通信する。加えて、共通インターフェースモジュール５０は、デバイス特有インターフェースモジュール５２を介して、ネットワークデバイス２０Ａ〜２０Ｎから、コマンドに対する応答を受信し、かつ、該応答を、変換されたフォーマットで、クライアントアプリケーションプログラム１４Ａ〜１４Ｎへ送る。共通インターフェースモジュール５０は、該モジュール自身のコマンドを生成することによって、自動化された検査および管理を実行する。デバイス特有インターフェースモジュール５２は、コマンドを、共通フォーマットから、（目的地ネットワークデバイス２０Ａ〜２０Ｎによって要求される）デバイス特有フォーマットへ変換する。デバイス特有インターフェースモジュール５２は、また、ネットワークデバイス２０Ａ〜２０Ｎから応答を受信し、かつ、該応答を共通フォーマットへ変換する。それによって、該応答は、共通インターフェースモジュール５０を介して、適切なクライアントアプリケーションプログラム１４Ａ〜１４Ｎへ送られる。初期化モジュール５４は、ＮＩＦＴＥ１８の始動時に、初期化を実行する。これらの機能は（ネットワークデバイス構成情報を判断する際における）バイナリデータリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎの初期化を含む。好ましい実施形態において、共通インターフェースモジュール５０は、多数の異なるオブジェクトとして実行される。図５は、共通インターフェースモジュール５０の個々のオブジェクト間におけるデータフローを示すデータフロー図である。以下の討論は、これらのオブジェクトによって実行される機能を詳述する。 Queue_Input_Cmdsオブジェクト６２は、クライアントアプリケーションプログラム１４Ａ〜１４Ｎからコマンドを受信することと、（共通インターフェースモジュール５０内の他のオブジェクトへの分配のために）これらのコマンドを待ち行列に入れることとに対して責任を負っている。図５において見られることができるように、Queue_Input_Cmdsオブジェクト６２によって受信されたコマンド６０は、Input_Cmd_Queue ６４内に置かれる。以下のコマンドが、Queue_Input_Cmds オブジェクト６２において受信されてもよい。 Change_Ex_State_Cmd Change_Readiness_Mode_Cmd NIFTE_Force_Audit_Cmd NIFTE_Alarm_Registration_Cmd NIFTE_Port_Connect_Cmd NIFTE_Port_Disconnect_Cmd NIFTE_Data_Update_Cmd NIFTE_Stop_NIFTE_Cmd Change_Ex_State_Cmdコマンドは、ＮＩＦＴＥ１８の実行状態を変化させることに対して責任を負っている。実行状態は、より詳細に以下に説明される。Chan ge_Readiness_Mode_Cmdコマンドは、ＮＩＦＴＥ１８の準備完了モードを変化させる。準備完了モードもまた、より詳細に以下に説明される。NIFTE_Force_Audi t_Cmdコマンドは、開始されるべきネットワークデバイスの検査を引き起こす。N IFTE_Alarm_Registration_Cmdコマンドは「（ネットワークデバイス２０Ａ〜２０Ｎから生じる）ある要求されていないアラームが、クライアントアプリケーションプログラムへ送られるべきである」ということを要求する。NIFTE_Port_Con nect_Cmdコマンドは、ポートを接続することを、ネットワークデバイス２０Ａ〜２０Ｎに指示する。逆に、NIFTE_Port_Disconnect_Cmdコマンドは、ポートの接続を断つことを、ネットワークデバイスに指示する。NIFTE_Data_Update_Cmdコマンドは、ＮＩＦＴＥの内部構成内のデータ（または、リアルタイムネットワークデバイスデータ内のデータ）を更新する。NIFTE_Data_Request_Cmdコマンドは「データが、ＮＩＦＴＥの内部構成またはリアルタイムネットワークデバイスデータのいずれかから、検索される」ということを要求する。最後に、NIFTE_Stop _NIFTE_Cmdコマントは「ＮＩＦＴＥ１８がシャットダウンする」ということを引き起こす。図６は、上述されたコマンドのうちの１つがQueue_Input_Cmdオブジェクト６２によって受信されるときに実行されるステップを図解するフローチャートである。最初に、コマンドが、クライアントアプリケーションプログラム１４Ａ〜１４Ｎのうちの１つから受信される（図６のステップ１４０）。そして、Queue_In put_Cmdオブジェクト６２は、受信されたコマンドを、Input_Cmd_Queue ６４へ加える（図６のステップ１４２）。コマンドを受信すると、Queue_Input_Cmdオブジェクト６２は、また、Parse_Input_Cmdオブジェクト７０を起動６８するために、Set_Eventメッセージ６６を発送する（図６のステップ１４４）。Set_Eve ntメッセージ６６の発送は、Parse_Input_Cmdオブジェクト７０の起動６８を引き起こす（図６のステップ１４６）。 Parse_Input_Cmdオブジェクト７０は、Input_Cmd_Queue ６４内に記憶されるコマンドを適切な目的地オブジェクトへ分配することに対して責任を負っている。図７は、Parse_Input_Cmdsオブジェクト７０によって（単一の検索コマンドに対して）実行されるステップのフローチャートである。最初に、Parse_Input_Cm dsオブジェクト７０は、Input_Cmd_Queue ６４から、コマンドを検索する（図７のステップ１４８）。そして、Parse_Input_Cmdsオブジェクト７０は、該コマンドのタイプを識別する（図７のステップ１５０）。コマンドのタイプに基づいて、Parse_Input_Cmdsオブジェクト７０は、「適切な処理のために、該コマンドを何処に分配するのか」ということを決定する。もし、該コマンドがNIFTE_Data_U pdate_CmdコマンドまたはNIFTE_Data_Request_Cmdコマンドであるならば（図７のステップ１５２参照）、Parse_Input_Cmdsオブジェクトは、該コマンドを、NI FTE_Data_Managerオブジェクト７２へ送る（図７のステップ１５４）。もし、該コマンドがNIFTE_Alarm_Registration_Cmdコマンドであるならば（図７のステップ１５６参照）、Parse_Input_Cmdsオブジェクト７０は、該コマンドNIFTE_Alar m_Registration_Cmdを、Administer_Alarm_Subscriber_Listオブジェクト８２へ送る（図７のステップ１５８）。もし、該コマンドがNIFTE_Stop_NIFTE_Cmdコマンドであるならば（図７のステップ１６０参照）、Parse_Input_Cmdsオブジェクト７０は、該コマンドを、NIFTE_Shutdownオブジェクト９２へ送る（図７のステップ１６２）。もし、該コマンドがChange_Ex_State_CmdコマンドまたはChange_ Readiness_Mode_Cmdコマンドであるならば（図７のステップ１６４参照）、該コマンドは、Process_State_Changeオブジェクト９６へ送られる（図７のステップ１６６）。もし、該コマンドがNIFTE_Force_Audit_CmdコマンドまたはNIFTE_Por t_Connect_CmdコマンドまたはNIFTE_Port_Disconnect_Cmdコマンドであるならば、該コマンドは、Verify_Device_Cmdsオブジェクト１２０へ送られる（図７のステップ１６８）。上述されたように、NIFTE_Data_Update_CmdコマンドおよびNIFTE_Data_Reques t_Cmdコマンドは、NIFTE_Data_Managerオブジェクト７２へ送られる。図８は、このオブジェクトによって実行されるステップのフローチャートである。最初に、NIFTE_Data_Managerオブジェクト７２は、該コマンドを、Parse_Input_Cmdオブジェクト７０から受信する（図８のステップ１７０）。そして、NIFTE_Data_M an agerオブジェクト７２は、該コマンドに基づいて、データを更新またば検索するために、該データにアクセスする（図８のステップ１７２）。もし、データ更新またはデータ検索が内部ＮＩＦＴＥ構成情報に対するものならば、NIFTE_Data_M anagerオブジェクト７２は、該更新を行うために、ＮＩＦＴＥの内部データテーブルにアクセスする。もし、要求または更新が内部ＮＩＦＴＥ構成情報に対するものでないならば、適切なデータへのアクセスを得るために、RealTime_Network _Device_Data１２６が、リアルタイムネットワークデバイスデータデータベース１６（図１）からアクセスされる。そして、NIFTE_Data_Managerオブジェクト７２は、（コマンドを送った）クライアントアプリケーションプログラム１４Ａ〜１４Ｎへ応答を送る（図８のステップ１７４）。NIFTE_Data_Update_Resp応答７４が、（受信された）各NIFTE_Data_Update_Cmdコマンドに対して送られ、かつ、NIFTE_Data_Request_Resp応答７５が、（受信された）各NIFTE_Data_Request_ Cmdコマンドに対して送られる。加えて、データが、NIFTE_Data_Request_Cmdに応答して戻される。応答７４，７５は「対応するコマンドが、受信されかつ処理された」ということを確かにする。これらの応答７４，７５の生成時に、NIFTE_ Data_Managerオブジェクト７２は、Respondent_list ９０を使用する。Responde nt list ９０は、全てのクライアントアプリケーションプログラム１４Ａ〜１４Ｎとそのようなクライアントアプリケーションプログラムに対する論理的アドレスとのリストを保持する。 NIFTE_Data_Managerオブジェクト７２は、ある条件のイベントが実行（または、検出）されると、時々、状態メッセージ（Status_Msg）７８を生成してもよい。条件イベントの例は（ユーザーが知ることを望む）エラーの検出またはタスクの完了を含む。そのような状態メッセージは、ＮＩＦＴＥ１８のための内部ログにおいて保持され、かつ、（報告を見る）ユーザーに対して利用可能である。共通インターフェースモジュール５０（図４）内の他のオブジェクトもまた、そのような状態メッセージを生成する。例えば、Parse_Input_Cmdオブジェクト７０は、条件イベントが発生すると、Status_Msgメッセージ８０を生成する。図９は、Administer_Alarm_Subscriber_Listによって実行されるステップを表す。図９は、Administer_Alarm_Subscriber_Listオブジェクト８２が（Parse_In put_Cmdオブジェクト７０から）NIFTE_A1arm_Registration_Cmdコマンドを受信するときに、該オブジェクト８２によって実行されるステップを図解するフローチャートである。最初に、該コマンドが受信される（図９のステップ１７６）。そして、Administer_Alarm_Subscriber_Listオブジェクト８２は、アラームリクェストを、Alarm_Subscriber_List ８４に登録する（図９のステップ１７８）。要求されていないアラームを登録するために、NIFTE_Alarm_Registration_Cmdコマンドが、クライアントアプリケーションプログラムに対するAdminister_Alarm _Subscriber_Listオブジェクト８２へ送られる。それによって、クライアントアプリケーションプログラムは、該クライアントアプリケーションプログラムへは通常送られないアラームを、ネットワークデバイス２０Ａ〜２０Ｎから受信する。Alarm_Subscriber_List ８４は、要求されていないアラームを受信するために（要求によって）登録されたクライアントアプリケーションプログラムのリストであり、かつ、該リストは、Administer_Alarm_Subscriber_Listオブジェクト８２によって、更新されかつ維持される。Administer_Alarm_Subscriber_Listオブジェクト８２は、応答（即ち、登録されたクライアントアプリケーションプログラム１４Ａ〜１４ＮへのNIFTE_Alarm_Registration_Resp ８６）を生成する（図９のステップ１８０）。該応答は、「アラーム登録コマンドが、受信されかつ処理された」ということを確かにする。Administer_Alarm_Subscriber_Listオブジェクト８２は、（応答が送られる）クライアントアプリケーションプログラムの名前およびアドレスの位置を捜し当てるために、Respondent_list ９０を使用する。共通インターフェースモジュール５０内の他のオブジェクトと同様に、Admini ster_Alarm_Subscriber_Listオブジェクト８２は、あるトリガイベントが発生すると、Status_Message８８を生成する。 NIFTE_Shutdownオブジェクト９２は、Parse_Input_Cmdオブジェクト７０から、NIFTE_Stop_NIFTE_Cmdコマンドを受信してもよい。図１０は、そのような場合に実行されるステップを図解するフローチャートである。最初に、NIFTE_Shutdo wnオブジェクト９７は、NIFTE_Stop_NIFTE_Cmdコマンドを受信する（図１０のステップ１８２）。NIFTE_Shutdownオブジェクト９２は、応答（即ち、NIFTE_Stop _N IFTE_Resp ９４）を生成する。NIFTE_Shutdownオブジェクト９２は、該応答を、（コマンドを起こした）クライアントアプリケーションプログラム１４Ａ〜１４Ｎへ送る（図１０のステップ１８４）。そして、NIFTE_Shutdownオブジェクト９２は、ＮＩＦＴＥをシャットダウンすることを進める（図１０のステップ１８６）。各ＮＩＦＴＥは、２つの実行状態（主要またはバックアップ）のうちの１つにおいて動作する。故障耐性を高めるために、好ましい実施形態は、ＮＩＦＴＥの２つの実体を提供する。その１つは、アクティブ（即ち、主要）ＮＩＦＴＥとして働き、１つは、バックアップＮＩＦＴＥとして働く。好ましくは、ＮＩＦＴＥのこれらの実体は、分離したコンピュータシステム上で実行される。ＮＩＦＴＥが主要実行状態からバックアップ実行状態へ移行すると、該ＮＩＦＴＥは、ネットワークの残部との（該ＮＩＦＴＥの）通信を終了し、かつ、該ＮＩＦＴＥのバイナリリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎを終止する。ＮＩＦＴＥがバックアップ実行状態から主要実行状態へ移行すると、該ＮＩＦＴＥは、該ＮＩＦＴＥのバイナリリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎを開き、かつ、通信を開始する。（実行状態における）そのような移行は、Change_Ex_State_Cmdコマンドによって引き起こされる。主要ＮＩＦＴＥ１８はまた、２つの準備完了モード（正常および警戒）のうちの１つにおいて動作する。正常モードは（ＮＩＦＴＥがルート検査とルート管理と他の機能とを実行する）動作の正常モードである。（ネットワーク故障を示す）要求されていないアラームが受信されると、復旧システムアプリケーションプログラム１４Ａが、Change_Readiness_Mode_Cmdコマンドを、ＮＩＦＴＥへ送る。このコマンドは、準備完了モードにおける変化を引き起こす。それによって、ＮＩＦＴＥは、警戒準備完了モードへ移行する。警戒準備完了モードでは、全ての検査処理およびバックグラウンド処理が終了し、かつ、ＮＩＦＴＥ１８は、NI FTE_Port_Connect_CmdコマンドおよびNIFTE_Port_Disconnect_Cmdコマンドを（復旧１４Ａから）受信しかつ処理する準備を整える。図１１Ａは、Process_State_Changeオブジェクト９６がChange_Readiness_Mod e_Cnldコマンドを受信するときに該オブジェクト９６によって実行されるステップを図解する。最初に、該コマンドは、Process_State_Changeオブジェクト９６で受信される（図１１Ａのステップ１９０）。そして、Process_State_Changeオブジェクト９６は、準備完了モード状態における変化を反映するために、Curren t_NIFTE_State ９８内に保持される状態を更新する。もし、準備完了モード状態が正常から警戒へ変化しているならば（図１１Ａのステップ１９４参照）、Proc ess_State_Changeオブジェクト９６は、全ての自動検査動作を終了するために、 Audit_Intervalメッセージ１００を、Audit_Interval_Timer１０２へ送る（図１１Ａのステップ１９６）。このことは、より詳細に以下に説明される。変化が正常状態から警戒状態へ（または、その逆）の場合、Process_State_Changeオブジェクト９６は、（現在進行中の）全ての検査を一時停止することを進める（図１１Ａのステップ１９８）。しかしながら、（初期化中に実行される）不完全な初期デバイス検査は、一時停止されない。そして、Process_State_Changeオブジェクト９６は、Change_Readiness_Mode_Resp１０６を、（初期コマンドを送った）クライアントアプリケーションプログラムへ送る（図１１Ａのステップ２００）。図１１Ｂは、Change_Ex_State_Cmdコマンドが受信されるときにProcess_State _Changeオブジェクト９６によって実行されるステップを示す。最初に、該オブジェクトは、Change_Ex_State_Cmdコマンドを受信する（図１１Ｂのステップ２０２）。そして、Process_State_Changeオブジェクト９６は、「状態変化が実行されるかも知れない」ということを保証するために、System_Logicals １０８を調べる（図１１Ｂのステップ２０４）。System_Logicals １０８は、（状態を示す）コンピュータのオペレーティングシステムとコンピュータのパフォーマンスコンディションとに基づいて、データを構成する。そして、Current_NIFTE_Stat e ９８内に保持される状態が、実行状態における変化を示すために、変更される（図１１Ｂのステップ２０６）。もし、該コマンドが、主要からバックアップへの（実行状態における）変化のためのものであるならば（図１１Ｂのステップ２０８）、バイナリリンクを閉じるために、コマンド１１２が、該バイナリリンクへ送られる（図１１Ｂのステップ２１０）。加えて、自動化された検査を停止するために、Audit_Intervalメッセージ１００が、Audit_Interval_Timer１０２へ送られる（図１１Ｂのステップ２１２）。この場合、Process_State_Changeオブジェクト９６は、Change_Ex_State_Resp応答１０８を、（初期コマンドを送った）クライアントアプリケーションプログラムへ送る（図１１Ｂのステップ２１８）。もし、コマンドが、バックアップから主要への変化のためのものであるならば（図１１Ｂのステップ２０８）、Process_State_Changeオブジェクト９６は、バイナリリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎを開くために必要とされる情報を得るために、RealTime_Network_Device_Data１１０を読み込む（図１１Ｂのステップ２１４）。そして、コマンド１１２が、該バイナリリンクを開くために送られる。また、自動検査を開始するために、Audit_Intervalメッセージ１００が、 Audit_Interval_Timer１０２へ送られる（図１１Ｂのステップ２１６）。Change _Ex_State_Resp応答１０８が、（初期コマンドを送った）クライアントアプリケーションプログラムへ送られる。あるイベントが引き起こされると、Process_State_Changeオブジェクト９６が、Status_Msgメッセージ１１４を生成する。 Auto_Auditオブジェクト１０５が、ＮＩＦＴＥ１８に対する自動検査処理を実行する。該検査処理は、指定された時間間隔で、NIFTE_Force_Audit_Cmdコマンド１１６を、自動的に生成する。これらのコマンドは（ネットワークデバイス２０Ａ〜２０Ｎのうちの）様々なネットワークデバイスへ送られる。該コマンドは、ネットワークデバイス２０Ａ〜２０Ｎがそれらの内部構成を指定するように、該デバイス２０Ａ〜２０Ｎからの応答を引き起こす。 Audit_Interval_Timer１０２は、そのようなNIFTE_Force_Audit_Cmdコマンド１１６の送信の実行を引き起こす。該タイマ１０２は、「Auto_AuditオブジェクトがNIFTE_Force_Audit_Cmdコマンドを生成する」ということを引き起こすために、Audit_Interruptメッセージ１０４を、Auto_Auditオブジェクト１０５へ送る。そのようなコマンドは、Queue_Input_Cmdオブジェクト６２へ送られる。そのようなコマンドを生成した後、Auto_Auditオブジェクト１０５は、Audit_ Intervalメッセージを送ることによって、Audit_Interval_Timer１０２をリセットする。 Verify_Device_Cmdsオブジェクト１２０は（ポートを接続し、かつ、ポートの接続を断ち、かつ、検査を強制するために）Parse_Input_Cmdオブジェクト７０からコマンドを受信しかつ処理する。特に、Verify_Device_Cmdsオブジェクト１２０は、NIFTE_Port_Connect_CmdコマンドとNIFTE_Port_Disconnect_CmdコマンドとNIFTE_Force_Audit_Cmdコマンドとを、Parse_Input_Cmdオブジェクト７０から受信する。Verify_Device_Cmdsオブジェクト１２０は「該オブジェクト１２０が受信するタイプのコマンドが、適切な引数を具備し、かつ、デバイス特有インターフェースによって現在処理されることができる」ということを確認する。図１２は、受信されたコマンドを処理する際に、Verify_Device_Cmdsオブジェクト１２０によって実行されるステップのフローチャートである。最初に、Veri fy_Device_Cmdsオブジェクト１２０は、ポート接続コマンドとポート接続断コマンドと強制検査コマンドとを受信する（図１２のステップ２２０）。そして、Ve rify_Device_Cmdsオブジェクト１２０は、「現在の動作モード１２２および実行状態１２４は、該コマンドの処理に対して適切である」ということを保証するために、Current_NIFTE_Stateにアクセスする（図１２のステップ２２２）。例えば、ポート接続コマンドおよびポート接続断コマンドに対しては、適切な実行状態は、主要実行状態であり、かつ、いずれの準備完了モードも受け入れられる。しかしながら、強制検査モードの場合、適切な実行状態は、主要実行状態であり、かつ、適切な準備完了モードは、正常モードである。もし、適切なモードおよび状態が確認されることができないならば、該コマンドは、それ以上処理されない。もし、適切な動作モード１２２および実行状態１２４が（図１２のステップ１２２において）確認されたならば、コマンドの引数を確認するために、Rea1Ti me_Network_Device_Data１２６が読み込まれる（図１２のステップ２２４）。例えば、ポート接続コマンドおよびポート接続断コマンドに対しては、該コマンドにおいて指定されたポート範囲が確認されなくてはならない。該データは、また、（コマンドが行先を定められる）ネットワークデバイス２０Ａ〜２０Ｎに対するネットワークアドレスを得るために使用される。もし、引数が確認されるならば、デバイス特有インターフェースモジュールによる処理のために、コマンド１２８がQueue_Device_Cmdsオブジェクトへ送られる（図１２のステップ２２６）。このことは、より詳細に以下に説明される。そして、Verify_Device_Cmdsオブジェクト１２０が、適切な応答１３０または１３２または１３４を、（コマンドを開始した）クライアントアプリケーションプログラムへ送る（図１２のステップ２２８）。もし、同じ理由のために、コマンドがデバイス特有インターフェースモジュールへ送られることができないならば、Verify_Device_Cmdsオブジェクト１２０は（該コマンドを送ることの不可能性を示す）応答メッセージを送る。しかしながら、もし、コマンドが首尾良く送られるならば、応答がネットワークデバイス２０Ａ〜２０Ｎから受信されるときに、該応答はクライアントアプリケーションプログラム１４Ａ〜１４Ｎへ送られる。図１３は、デバイス特有インターフェースモジュール５２（図４）のアーキテクチャを、より詳細に図解する。特に、図１３は（デバイス特有インターフェースモジュール５２を具備する）オブジェクト間におけるデータフローを示すデータフロー図を表す。上述されたように、デバイス特有インターフェースモジュール５２は、共通インターフェースモジュール５０から、共通フォーマットでクライアントコマンドを受信し、かつ、該コマンドを、目的地ネットワークデバイス２０Ａ〜２０Ｎに特有のフォーマットへ変換する。変換されたコマンドは、データリンク４２Ａ〜４２Ｎまたは４４Ａ〜４４Ｎを使用して、目的地ネットワークデバイス２０Ａ〜２０Ｎへ送られる。デバイス特有インターフェースモジュール５２は、ネットワークデバイス２０Ａ〜２０Ｎから、応答および（要求されていない）メッセージを受信し、かつ、該応答およびメッセージを、共通フォーマットへ変換する。そのうえ、デバイス特有インターフェースモジュール５２は、バイナリデータリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎを管理することに対して責任を負っている。デバイス特有インターフェースモジュール５２内のデバイス間に、Queue_Devi ce_Cmdsオブジェクト２３０が存在する。このオブジェクトは、デバイスコマンドを適切な待ち行列に入れることに対して責任を負っている。以下の討論は、異なるタイプのコマンドがQueue_Device_Cmdsオブジェクト２３０によって受信されるときに実行されるステップに焦点を合わせる。図１４Ａ，１４Ｂは、検査コマンドがQueue_Device_Cmdsオブジェクト２３０によって受信されるときに実行されるステップを図解する。最初に、Queue_Device_Cmdsオブジェクト２３０は、（コマンドの実体を一意に識別する）シーケンス番号を、検査コマンドに割り当てる（図１４Ａのステップ３３０）。該シーケンス番号は、Next_Sequence_Numb erサーバ２３４から得られる。Next_Sequence_Numberサーバ２３４は、ＮＩＦＴＥ１８によって、内的に維持される。該コマンドは検査コマンドであるので、Qu eue_Device_Cmdsオブジェクト２３０は、検査コマンドを、Audit_Cmd_Queue ２３６内に置く（図１４Ａのステップ３３２）。その後、Format_And_Submit_Cmds オブジェクト２５２が、検査コマンドを、Audit_Cmd_Queue２３６から検索する（図１４Ａのステップ３３４）。Format_And_Submit_Cmdsオブジェクト５２は、様々な待ち行列から、コマンドを検索し、かつ、該コマンドを、（クライアントアプリケーションプログラム１４Ａ〜１４Ｎによって使用される）共通フォーマットから、（ネットワークデバイス２０Ａ〜２０Ｎによって使用される）デバイス特有フォーマットへ変換する。そして、Format_And_Submit_Cmdsオブジェクト２５２は、（目的地デバイスについての）特定デバイスタイプ情報とバージョン情報とを、Device_Statusファイル２５４から検索する（図１４Ａのステップ３３６）。Device_Statusファイル２５４は（各々のネットワークデバイス２０Ａ〜２０Ｎに対する）デバイスタイプおよびバージョン情報に関する情報を保持する。Format_And_Submit_Cmdsオブジェクト２５２は、「目的地ネットワークデバイスが、適切に構成され、かつ、コマンドを受信できる」ということを確認するために、目的地ネットワークデバイスについてのデバイス構成情報を、リアルタイムネットワークデバイスデータデータベース１６（図１）内に記憶されるRealTime_Network_Device_Data２５６から検索する（図１４Ａのステップ３３８）。Format_And_Submit_Cmdsオブジェクト２５２は、検査コマンドをデバイス特有フォーマット内に生成することを進める（図１４Ａのステップ３４０）。そして、デバイス特有コマンドのコピーが、Audit_Cmd_Queue ２３６内に置かれる（図１４Ａのステップ３４２）。 Format_And_Submit_Cmdsオブジェクト２５２は、検査チャネル２６０に関する状態に対する要求を、Manage_Binary_Linksオブジェクト２５８へ送る（図１４Ａのステップ３４４）。「例えば、大抵のネットワークデバイス２０Ａ〜２０Ｎへのバイナリリンクに対して、多数のチャネルが存在してもよい」ということを注意する価値がある。そのような場合、１つのチャネルが、検査コマンドに対して使用され、かつ、audit_channel ２６０として指定される。他のチャネルが、管理コマンドに対して使用され、かつ、admin_channel ２６１として指定される。追加のチャネルが、接続／接続断コマンドに対して使用され、かつ、connect_ channel ２８２として指定される。normalization_channel ２７１もまた、提供されてもよい。そして、Message_Binary_Linksオブジェクト２５８が、Audit_ch annel ２６１の状態をチェックする（図１４Ａのステップ３４６）。そして、Me ssage_Binary_Linksオブジェクト２５８は、Binary_Link_Statusメッセージ２６２を、（audit_channel ２６０が利用可能であるか否かを指定する）Format_And _Submit_Cmdsオブジェクト２５２へ送る（図１４Ａのステップ３４８）。もし、 audit_channel ２８１がいずれのバイナリリンクに対しても利用可能でないならば（図１４Ｂのステップ３５０）、Format_And_Submit_Cmdsオブジェクト２５２は、該コマンドを拒絶する。そして、「該コマンドは処理されることができない」ということを示す応答を、クライアントアプリケーションプログラムへ送る（図１４Ｂのステップ３５２）。しかしながら、もし、バイナリリンク上のaudit_ channelが利用可能ならば（図１４Ｂのステップ３５０）、Format_And_Submit_C mdsオブジェクト２５２は、フォーマットされた検査コマンドを、Manage_Binary _Linksオブジェクト２５８へ送る（図１４Ｂのステップ３５４）。そして、Mana ge_Binary_Linksオブジェクト２５８は、検査コマンドを、Binary_Device_Cmdコマンド２６４として、目的地ネットワークデバイスへ送る（図１４Ｂのステップ３５６）。目的地ネットワークデバイスは、フォーマットされた検査コマンドを受信し、かつ、構成情報を（Binary_Device_Data２６６のフォーマットで）生成する。該構成情報は、Queue_Binary_Device_Dataオブジェクト２６８によって受信される（図１４Ｂのステップ３５８）。Queue_Binary_Device_Dataオブジェクト２６８は、応答を、Binary_Device_Data_Queue２７０内に置く（図１４Ｂのステップ３６０）。Parse_Binary_Device_Dataオブジェクト２７２は、Binary_Device_Data _Queue２７０内に記憶されたデータを、検索しかつ構文解析する（図１４Ｂのステップ３６２）。該データは、Parse_Binary_Device_Dataオブジェクト２７２によって、Process_Audit_Responseオブジェクト２７４へ送られる（図１４Ｂのステップ３６４）。Process_Audit_Responseオブジェクト２７４は、検索されたデータのコピーを、Audit_Cmd_Queue２３６内に置き、かつ、該データを、オリジナル検査コマンドと照合する（図１４Ｂのステップ３６６）。Audit_Cmd_Queue ２３６は、同じ待ち行列である。該待ち行列内には、Queue_Device_Cmdsオブジェクト２３０によって、検査コマンドが置かれる。応答の（オリジナルコマンドとの）照合は、シーケンス番号を照合することによって達成される。特に、該応答は（Queue_Device_Cmdsオブジェクト２３０によって追加された）同じシーケンス番号を具備する。Process_Audit_Responseオブジェクト２３４は、「最後の検査コマンドに対する応答が受信されるまで、特定のネットワークデバィスに対するコマンドが提出されない」ということを保証することによって、検査コマンドの提出を制御する。Process_Audit_Responseオブジェクト２７４は、RealTime _Network_Device_Data２５６へのアクセスを有し、かつ、（受信された応答データに応答して）このデータを更新する。Process_Audit_Responseオブジェクト２７４は、該応答（即ち、NIFTE_Force_Audit_Resp２７８）を、（オリジナルコマンドを送った）クライアントアプリケーションプログラムへ送る。「該応答を何処へ送るのか」ということを判断するために、Respondent_Nailbox_List ３０８が使用される（図１４Ｂのステップ３６８）。 Queue_Device_Cmdsオブジェクト２３０もまた、Verify_Device_Cmdsオブジェクト１２０（図５）から、ポート接続コマンドおよびポート接続断コマンドを受信してもよい。図１５Ａ〜図１５Ｃは、そのようなポート接続コマンドおよびポート接続断コマンドをデバイス特有インターフェースモジュール５２（図４）内で処理する際に実行されるステップのフローチャートを提供する。最初に、Queu e_Device_Cmdsオブジェクト２３０は、シーケンス番号を、（受信された）ポート接続コマンドまたはポート接続断コマンドへ割り当てる（図１５Ａのステップ３７０）。該シーケンス番号は、Next_Sequence_Numberサーバ２３４から得られる。このことは上述された。そして、Queue_Device_Cmdsオブジェクト２３０は、接続コマンドまたは接続断コマンドを、Connect_Disconnect_Cmd_Queue２３８内に置く（図１５Ａのステップ３７２）。この待ち行列は（該コマンドが行先を定められた）目的地ネットワークデバイスに専用とされる。効率のために、多数の接続／接続断コマンドが、一緒にまとめられ、かつ、該束を単位として、ネットワークデバイス２０Ａ〜２０Ｎへ送受信される。最大束サイズは、個々のネットワークデバイス２０Ａ〜２０Ｎが処理できるコマンドの最大数である。最大束間隔は「（処理のための）コマンドの次の束を提出する前に、Queue_Device_Cmds オブジェクト２３０が待機する」ということを指示される時間である。このことは、最大束サイスを実現するのに十分な数の接続／接続断コマンドを集めるために、過度の待機を防止する。図１５Ａのステップ３７４では、Queue_Device_Cmdsオブジェクト２３０が、最大束サイズ（即ち、max_batch_size）と最大束間隔（即ち、max_batch_interv al）とConnect_Disconnect_Cmd_Queue２３８内の提出されなかつたコマンドの数とを検索する。この（提出されなかった）コマンドは、Num_Unsubmitted_Cmds２４２として指定される。Queue_Device_Cmdsオブジェクト２３０は、Num_Unsubmi tted_Cmds２４２を（検索された）最大束サイズと比較することによって、「最大束サイズが達せられたか否か」ということを判断する。また、Queue_Device_C mdsオブジェクト２３０は、「最大束間隔が達せられたか否か」ということを判断する（図１５Ａのステップ３７６）。もし、最大束サイズが達せられなかったならば、または、もし、最大束間隔が達せられなかったならば、該オブジェクトは、次の接続／接続断コマンドを待たなくてはならない（図１５Ａのステップ３７８）。しかしながら、（図１５Ａのステップ３７６においてチェックされるように、）もし、最大束サイズが達せられたならば、または、もし、最大束間隔が達せられたならば、Queue_Device_Cmdsオブジェクト２３０は、今後の処理のために、コマンドの束を、Format_And_Submit_Cmdsオブジェクト２５２へ提出する（図１５Ａのステップ３８０）。Format_And_Submit_Cmdsオブジェクト２５２は、max_batch_intervalを、割込ジェネレーター２７３へ送る。割込ジェネレーター２７３は、該最大間隔が達せられると、wakeup_interrupt２７５を生成する。 Format_And_Submit_Cmdsオブジェクト２５２は、また、コマンドを送るか否かを判断する際に、いくつかの追加値２７７を調べる。Max_Cmd_Age_Before_Resen dingは、最初にコマンドが送り出された後、応答の欠如に起因して再送信する前に待機される時間の最大量を指定する。Max_Resend_Retries値は（所定の送信能力が使い果たされるまでに）コマンドが再送信される回数を指定する。Cmd_Mete ring値は、同時に未処理であるコマンドの最大数を指定する。 Format_And_Submit_Cmdsオブジェクト２５２は、Device_Statusファイル２５４から、目的地デバイスに対するデバイスタイプとバージョン情報とを検索する（図１５Ａのステップ３８２）。この情報は、目的地ネットワークデバイス２０Ａ〜２０Ｎに対するデバイスタイプと現在バージョン情報とを判断するために使用される。その後、Format_And_Submit_Cmdsオブジェクト２５２は、「ネットワークデバイスが、適切に構成されているか否か、および、接続／接続断コマンドを受信できるか否か」ということを判断するために、RealTime_Network_Device_ Data２５６から、デバイス構成情報を検索する（図１５Ａのステップ３８４）。 Format_And_Submit_Cmdsオブジェクト２５２は、目的地ネットワークデバイス２０Ａ〜２０Ｎのデバイス特有フォーマットで、接続／接続断コマンドを生成する（図１５Ａのステップ３８６）。該デバイス特有コマンドのコピーは、Connect_Disconnect_Cmd_Queue２３８内に置かれる（図１５Ａのステップ３８８）。Format_And_Submit_Cmdsオブジェクト２５２は、バイナリリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎに対する接続チャネル状態を調べるために、Manage_Binary_Linksオブジェクト２５８へ要求を送る（図１５Ａのステップ３９０）。Manage_Binary_Linksオブジェクト２５８は、バイナリリンクの接続チャネル２８２の状態を調べ（図１５Ａのステップ３９２）、かつ、この情報を、Binary_Link_Statusメッセージ２６２において送る。該メッセージ２６２は、Format_And_Submit_Cmdsオブジェクト２５２へ送られる（図１５Ａのステップ３９４）。接続／接続断コマンドは、主要通信経路またはバックアップ通信経路上を送られることができる。主要通信経路またはバックアップ通信経路上は、通信ゲートウエー２４（図１，３）を通過する。もし、両主要リンク上の接続チャネルが利用不可能であるならば、バックアップリンクが利用される。図１５Ｂのステップ３９６において、Format_And_Submit_Cmdsオブジェクト２５２は、「バイナリリンク上の接続チャネルが利用可能であるか否か」ということを判断する。もし、主要バイナリリンクまたはバックアップバイナリリンク上の接続チャネルが利用可能ならば、Format_And_Submit_Cmdsオブジェクト２５２は、フォーマットされた接続／接続断コマンドを、Manage_Binary_Linksオブジェクト２５８へ送る（図１５Ｂのステップ３９８）。Manage_Binary_Linksオブジェクト２５８は、該コマンドを、Binary_Device_Cmdコマンド２６４として、目的地ネットワークデバイスへ送る（図１５Ｂのステップ４００）。目的地ネットワークデバイスは、接続／接続断コマンドを受信し、かつ、応答を生成する。この応答は、Queue_Binary_Device_Dataオブジェクト２６８へ送られる（図１５Ｂのステップ４０２）。Queue_Binary_Device_Dataオブジェクト２６８は、該応答を、Binary_Device_Data_Queue２７０内に置く（図１５Ｂのステツプ４０４）。Parse_Binary_Device_Dataオブジェクト２７２は、Binary_Devic e_Data_Queue２７０から該応答を検索し、かつ、該応答を構文解析する（図１５Ｂのステップ４０６）。Parse_Binary_Device_Dataオブジェクト２７２は、応答コマンドを、Process_Connection_Responseオブジェクト３０４へ送る（図１５Ｂのステップ４０８）。Process_Connection_Responseオブジェクト３０４は、該応答のコピーを、Connect_Disconnect_Cmd_Queue２３８内に置く。Connect_Di sconnect_Cmd_Queue２３８では、該応答が、シーケンス番号に基づいて、オリジナルコマンドと照合される（図１５Ｂのステップ４１０）。Process_Connection _Responseオブジェクト３０４は、該応答に関して、RealTime_Network_Device_D ata２５６を更新する。そして、Process_Connection_Responseオブジェクトは、応答３１０または３１２を生成する。該応答３１０または３１２は、（初期コマンドを送った）クライアントアプリケーションプログラムへ送られる（図１５Ｂのステップ４１２）。もし、図１５Ｂのステップ３９６において、「いずれのバイナリリンク上の接続チャネルも利用可能でない」ということが判断されるならば、Format_And_Sub mit_Cmdsオブジェクト２５２は、接続チャネルの状態に対する要求を、Send_Cmd _IDC_SLinkオブジェクト２８４へ送る（図１５Ｂのステップ４１４）。これに応じて、Send_Cmd_IDCS_Linkオブジェクト２８４は、バックアップリンク上の接続チャネル２８３の状態を調べ（図１５Ｂのステップ４１６）、かつ、（バックアップリンク上の接続チャネル２８３の状態に関する情報を具備する）ＩＤＣＳメッセージ２８６を、Format_And_Submit_Cmdsオブジェクト２５２へ送る（図１５Ｂのステップ４１８）。故に、図１５Ｂのステップ４２０において、Format_And _Submit_Cmdsオブジェクト２５２は、「バックアップリンク上の接続チャネルが利用可能であるか否か」という判断を行う。もし、バックアップリンク上の接続チャネル２８３が利用可能ならば、Forma_ And_Submit_Cmdsオブジェクト２５２は、フォーマットされた接続／接続断コマンドを、Send_Cmd_IDCS_Linkオブジェクト２８４へ送る（図１５Ｂのステップ４２２）。Send_Cmd_IDCS_Linkオブジェクト２８４は、接続／接続断コマンドを、 IDCS_Gateway_Cmdコマンド２９０として、目的地ネットワークデバイスへ送る（図１５Ｂのステップ４２４）。目的地ネットワークデバイスは、該コマンドを受信し、かつ、（該コマンドの特質に依存して）ポートを接続または接続断することを試みる。応答が、目的地ネットワークデバイスから送られる。この応答（即ち、IDCS_G ateway_RESP ２９４）は、Queue_IDCS_GW_Responseオブジェクト２９２によって受信される（図１５Ｂのステップ４２６）。このオブジェクト２９２は、該応答を、IDCS_GW_Data_Queue２９６内に置く（図１５Ｂのステップ４２８）。Parse_ IDCS_GW_Responseオブジェクト３００が、（IDCS_GW_Data_Queue２９６内に置かれた）該応答を、検索しかつ構文解析する（図１５Ｂのステップ４３０）。Pars e_IDCS_GW_Responseオブジェクト３００は、該コマンドを、Process_Connection _Responseオブジェクト３０４へ送る（図１５Ｂのステップ４３２）。該オブジェクト３０４では、該コマンドが（ステップ４１０で始まって）上述されるように処理される。「もし、代わりに、該待ち行列２９６から検索された該応答が、管理コマンドに対する応答であったならば、該応答は、Process_IDCS_GW_Admin_Responseオブジェクト３０２へ送られ、該オブジェクト３０２は該応答を処理する」ということが注意されるべきである。もし、図１５Ｂのステップ４２０において、「バックアップリンク内の接続チャネル２８３が利用可能でない」ということが判断されるならば、Format_And_S ubmit_Cmdsオブジェクト２５２は、接続／接続断コマンドを拒絶する（図１５Ｃのステップ４３４）。そして、Format_And_Submit_Cmdsオブジェクト２５２は、該拒絶を示す応答を、クライアントアプリケーションプログラムへ送る（図１５Ｃのステップ４３６）。 Queue_Device_Cmdsオブジェクトによって受信されるコマンドは、また、管理コマンドであってもよい。これらのコマンドは、直ちに、Administration_Cmd_Q ueue２４０内に置かれる。Administration_Cmd_Queueにおいて、該コマンドは、直ちに、Format_And_Submit_Cmdsオブジェクト２５２によって従われる。管理コマンドは、バイナリリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎとネットワークデバイス識別子とアラームフィルターテーブルとを構成するために、始動時に、ＮＩＦＴＥによって生成される。そのような管理コマンドは、admin_channel ２６１上において、Manage_Binary_Linksオブジェクト２５８へ送られてもよい。該オブジェクト２５８は、該コマンドを、適切な目的地へ送る。 Manage_Binary_Linksオブジェクト２５８は、バイナリリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎを監視することによって、かつ、（該オブジェクト２５８が主要リンクとして指定する）各対のうちの最も信頼性のあるリンクを判断することによって、バイナリリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎを管理する。Manage _Binary_Linksオブジェクト２５８は、また、片方のリンクが故障すると（該リンクから他方のリンクへ）通信を切り換えることに対して、および、リンクを動的に構成することに対して、および、メンテナンスを提供することに対して責任を負っている。 Manage_Binary_Linksオブジェクト２５８は、キープアライブ（keepalive）コマンドを規定間隔でネットワークデバイス２０Ａ〜２０Ｎへ送ることによって、「リンクが利用可能である」ということを保証する。キープアライブコマンドは、「ネットワークデバイスが動作を実行する」ということを引き起こさないが、もし、ネットワークデバイスと対応リンクとが（今までどおり）適切に機能しているならば、該ネットワークデバイスと対応リンクとからの応答を要求する。Ke epalive_Timer ２６３が、「Manage_Binary_Linksオブジェクト２５８が、キープアライブコマンドを、指定された時間間隔で送る」ということを引き起こす。 Manage_Binary_Linksオブジェクト２５８は、Keepalive_Timer_Intervalメッセージ２６５をKeepalive_Timer ２６３へ送ることによって、キープアライブコマンドの送信の後に、Keepalive_Timer ２６３を、再び待ち行列に入れる。もし、ある時間間隔の後、キープアライブコマンドに対する応答が受信されないならば、 Manage_Binary_Linksオブジェクト２５８は、該リンクを、接続断しかつ再接続する。キープアライブコマンドに対する該応答は、Queue_Binary_Device_Dataオブジェクト２６８を介して送られる。該オブジェクト２６８は、関連するリンクの利用可能性を確かにするために、Keepalive_Timer_Intervalメッセージ２６５を、Keepalive_Timer ２６３へ送る。上述されたように、Manage_Binary_Linksオブジェクト２５８は、バイナリリンク対のうちの最も信頼性のあるリンクを判断し、かつ、該最も信頼性のあるリンクを、主要リンクとして指定する。他の対は、第２リンクとして指定される。もし、主要リンクが故障すると、Manage_Binary_Linksオブジェクト２５８は、通信を、第２リンクへ切り換える。また、上述されたように、Manage_Binary_Linksオブジェクト２５８は、バイナリリンクを動的に構成することができる。もし、主要リンクの構成またはメンテナンスが要求されるならば、このオブジェクトは、通信を第２リンクへ切り換え、かつ、第２リンクを新たな主要リンクであると指定し、かつ、古い主要リンクを停止する。この構成が完了すると、新たに指定された第２リンクがバックアップとしてもたらされるが、通信は（新たに指定された）主要リンクを伴ったままである。このアプローチは、構成動作およびメンテナンス動作の間でさえも、通信の利用可能性を保証する。上記討論は、「Queue_Binary_Device_Dataオブジェクト２６８が、接続／接続断メッセージへの応答、または、キープアライブコマンドへの応答、または、検査コマンドへの応答のうちのいずれかを受信した」という実例について述べてきた。もし、メッセージが「バイナリリンクの接続断」を示す（要求されていない）メッセージであるならば、（そのような応答の受信を示す）Binary_Link_Stat usメッセージ２６７が、Manage_Binary_Linksオブジェクト２５８へ送られる。 Queue_Binary_Device_Dataオブジェクト２６８は、また、ネットワークデバイス２０Ａ〜２０Ｎから、要求されていないアラームを受信してもよい。図１６は、そのような場合において実行されるステップを図解するフローチャートである。最初に、Queue_Binary_Device_Dataオブジェクト２６８は、ネットワークデバイス２０Ａ〜２０Ｎから、要求されていないアラームを受信する（図１６のステップ４４０）。Queue_Binary_Device_Dataオブジェクト２６８は、該要求されていないアラームを、Binary_Device_Data_Queue２７０内に置く（図１６のステップ４４２）。Parse_Binary_Device_Dataオブジェクト２７２は、該要求されていないアラームを、該待ち行列から検索し、かつ、該アラームを構文解析する（図１６のステップ４４４）。Parse_Binary_Device_Dataオブジェクト２７２は、構文解析されたアラームを、Process_Unsolicited_Alarmsオブジェクト３１８へ送る（図１６のステップ４４６）。このオブジェクト３１８は、そのような要求されていないアラームを受信するために登録されたいずれかのクライアントアプリケーションプログラムを識別するために、Alarm_Subscriber_List ３２０を照会する（図１６のステップ４４８）。そして、Process_Unsolicited_Alarmsオブジェクト３１８は、該要求されていないアラームをフォーマットする。そして、NIFT E_Alarm_Notificationメッセージ３２２を送ることによって、該要求されていないアラームを、クライアントアプリケーションプログラムへ送る（図１６のステップ４５０）。Process_Unsolicited_Alarmsオブジェクト３１８は、アラーム状態情報を用いて、RealTime_Network_Device_Data２５６を更新する（図１６のステップ４５２）。図１７は、初期化モジュール５４（図４）のアーキテクチャを示す。特に、図１７は、初期化構成要素を構成するオブジェクトのデータフロー図を示す。図１７において見られることができるように、初期化モジュールは、Initialize_NIF TEオブジェクト４６０を具備する。このオブジェクト４６０は、初期化処理を開始することに対して責任を負っている。図１８において示されるように、Initia lize_NIFTEオブジェクト４６０は、指定されたデバイス番号（即ち、Device_Num ）４６２を伴った初期化を開始するために、スタートメッセージを受信する（図１８のステップ５００）。該スタートメッセージ内のDevice_Numは、（ＮＩＦＴＥの現在の実体が、通信を確立するために伴う）個々のネットワークデバイス２０Ａ〜２０Ｎを識別する。Initialize_NIFTEオブジェクト４６０は、初期化を開始する。そして、バイナリリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎを開くために必要とされる構成情報を得るために、RealTime_Network_Device_Data２５６を読み込む（図１８のステップ５０２）。Initialize_NIFTEオブジェクト４６０は、また、後の使用のために、オペレーティングシステムから、System_Logicals １０８を読み込む（図１８のステップ５０４）。Current_NIFTE_State ９８が、Init ialize_NIFTEオブジェクト４６０によって、確立されかつ送り出される（図１８のステップ５０６）。加えて、Initialize_NIFTEオブジェクト４６０は、検査間隔を確立するために、Audit_Intervalメッセージ４６４を、Audit_Interval_Tim er１０２（図５）へ送る（図１８のステップ５０８）。最後に、Initialize_NIF TEオブジェクト４６０は、Initialize_Binary_Linksオブジェクト４６６とIniti alize_IDCS_Linkオブジェクト４６８とConfigure_Deviceオブジェクト４７０との実行を引き起こす（図１８のステップ５１０）。 Initialize_Binary_Linksオブジェクト４６６は、バイナリリンク４２Ａ〜４２Ｎ，４４Ａ〜４４Ｎを開くために必要とされる情報を、Initialize_NIFTEオブジェクト４６０から検索する。これは、Initialize_NIFTEオブジェクト４６０によってRealTime_Network_Device_Data２５６から検索された情報である。Initia lize_Binary_Linksオブジェクト４６６は、バイナリリンクを開くために、構成データを伴うメッセージを、Manage_Binary_Linksオブジェクト２５８（図１３）へ送る（図１８のステップ５１２）。 Initialize_IDCS_Linkオブジェクト４６８は、バックアップリンクを開くために、Initialize_NIFTEオブジェクト４６０からデータを受信する。そして、Init ialize_IDCS_Linkオブジェクト４６８は、バックアップリンクを開くために、このデータを伴うメッセージを、Send_Cmd_IDCS_Linkオブジェクト２８４（図１３）へ送る（図１８のステップ５１４）。 Configure_Deviceオブジェクト４７０が、管理処理を開始する。このオブジェクト４７０は、ネットワークデバイス２０Ａ〜２０Ｎからの情報を要求するために、ネットワークデバイス２０Ａ〜２０Ｎへ、管理コマンド４７４を送る（図１８のステップ５１６）。該コマンドは、Set_Node_IDコマンドとRetrieve_Softwa re_VersionコマンドとConfigure_Alarm_Filtersコマンドとを含む。その後、これらのコマンドに対する応答４７２が、Configure_Deviceオブジェトによって受信される。以上の説明から、「本発明の特定の実施形態が（図解を目的として）ここでは説明されたが、様々な変更が本発明の趣旨および範囲からはずれることなく行われてもよい」ということが認識される。従って、本発明は、添付された請求範囲による以外は限定されない。

Claims

【特許請求の範囲】１．ネットワークデバイスとプロセッサとを有する遠距離通信ネットワークにおいてプログラムをネットワークデバイスにインターフェースする方法であって、プロセッサは、ネットワークデバイスと通信するために、少なくとも１つのプログラムを実行し、各ネットワークデバイスは、デバイス特有通信フォーマットを有し、前記方法は、プログラムをネットワークデバイスにインターフェースするインターフェースを提供するコンピュータ実行ステップと、ネットワークデバイスのうちの選択された１つのネットワークデバイスに行先を定められた第１通信を、インターフェースのプログラムから、第１フォーマットで受信するコンピュータ実行ステップと、インターフェースを用いて、第１通信を、第１フォーマットから、選択されたネットワークデバイスのデバイス特有通信フォーマットである第２フォーマットへ変換するコンピュータ実行ステップと、第２フォーマット内の変換された第１通信を、インターフェースから、選択されたネットワークデバイスヘ送るコンピュータ実行ステップとを具備することを特徴とする方法。２．請求項１記載の方法において、前記方法は、インターフェースにおいてプログラムから第２通信を受信するステップを具備し、前記第２通信は、ネットワークデバイスのうちの与えられた１つのネットワークデバイスに行先を定められ、該与えられた１つのネットワークデバイスは、ネットワークデバイスのうちの１つのネットワークデバイスであり、かつ、第１通信のネットワークデバイスとは異なるネットワークデバイスであり、前記第２通信は、第１フォーマットにおけるものであり、前記方法は、インターフェースを用いて、第２通信を、第１フォーマットから、与えられたネットワークデバイスのデバイス特有通信フォーマットである第３フォーマットへ変換するステップと、第３フォーマット内の変換された第２通信を、インターフェースから、与えられたネットワークデバイスへ送るステップとを具備することを特徴とする方法。３．請求項２記載の方法において、選択されたネットワークデバイスと与えられたネットワークデバイスとは、異なるタイプのネットワークデバイスであることを特徴とする方法。４．請求項２記載の方法において、選択されたネットワークデバイスと与えられたネットワークデバイスとは、プログラム可能な命令を実行する同じタイプのネットワークデバイスであり、しかし、選択されたネットワークデバイスと与えられたネットワークデバイスとは、異なるバージョンのプログラム可能な命令を実行することを特徴とする方法。５．請求項１記載の方法において、前記方法は、インターフェースにおいて、ネットワークデバイスのうちの与えられた１つのネットワークデバイスから、プログラムに行先を定められた第２通信を受信するステップを更に具備し、前記第２通信は、与えられたネットワークデバイスのデバイス特有通信フォーマットにおけるものであり、前記方法は、インターフェースを用いて、第２通信を、与えられたネットワークデバイスのデバイス特有通信フォーマットから、プログラムと互換性を有するフォーマットへ変換するステップと、変換された第２通信を、インターフェースから、プログラムへ送るステップとを更に具備することを特徴とする方法。６．請求項５記載の方法において、第２通信は、与えられたネットワークデバイスからの応答であり、かつ、プログラムから送られた通信に対する応答であることを特徴とする方法。７．請求項５記載の方法において、第２通信は、要求されていないアラームであり、該アラームは、遠距離通信ネットワークにおける問題を示すことを特徴とする方法。８．請求項１記載の方法において、遠距離通信ネットワークは、電話ネットワークであることを特徴とする方法。９．請求項１記載の方法において、プロセッサは、多数のプログラムを実行し、かつ、インターフェースは、多数のプログラムを、ネットワークデバイスにインターフェースすることを特徴とする方法。１０．請求項１記載の方法において、インターフェースの独立した実体が各ネットワークデバイスに対して提供されるように、インターフェースの多数の実体が提供されることを特徴とする方法。１１．請求項１記載の方法において、第１通信は、選択されたネットワークデバイスがプログラムに対するアクションを実行することを、要求するコマンドであることを特徴とする方法。１２．請求項１１記載の方法において、コマンドは、選択されたネットワークデバイスの状態に関する情報を提供することを、選択されたネットワークデバイスに対して求める検査コマンドであることを特徴とする方法。１３．請求項１記載の方法において、選択されたネットワークデバイスは、デジタルクロスコネクト（ＤＸＣ）であることを特徴とする方法。１４．請求項１記載の方法において、プログラムは、ネットワークを故障から復旧する復旧プログラムであることを特徴とする方法。１５．ネットワークデバイスとプロセッサとを有する遠距離通信ネットワークにおいてプログラムをネットワークデバイスにインターフェースする方法を実行するコンピュータ実行可能命令を保持するコンピュータ読出可能媒体であって、プロセッサは、ネットワークデバイスと通信するために、少なくとも１つのプログラムを実行し、各ネットワークデバイスは、デバイス特有通信フォーマットを有し、前記方法は、プログラムをネットワークデバイスにインターフェースするインターフェースを提供するコンピュータ実行ステップと、ネットワークデバイスのうちの選択された１つのネットワークデバイスに行先を定められた第１通信を、インターフェースのプログラムから、第１フォーマットで受信するコンピュータ実行ステップと、インターフェースを用いて、第１通信を、第１フォーマットから、選択されたネットワークデバイスのデバイス特有通信フォーマットである第２フォーマットへ変換するコンピュータ実行ステップと、第２フォーマット内の変換された第１通信を、インターフェースから、選択されたネットワークデバイスへ送るコンピュータ実行ステップとを具備することを特徴とする媒体。１６．請求項１５記載のコンピュータ読出可能媒体において、前記方法は、インターフェースにおいてプログラムから第２通信を受信するステップを更に具備し、前記第２通信は、ネットワークデバイスのうちの与えられた１つのネットワークデバイスに行先を定められ、該与えられた１つのネットワークデバイスは、ネットワークデバイスのうちの１つのネットワークデバイスであり、かつ、第１通信のネットワークデバイスとは異なるネットワークデバイスであり、前記第２通信は、第１フォーマットにおけるものであり、前記方法は、インターフェースを用いて、第２通信を、第１フォーマットから、与えられたネットワークデバイスのデバイス特有通信フォーマットである第３フォーマットへ変換するステップと、第３フォーマット内の変換された第２通信を、インターフェースから、与えられたネットワークデバイスへ送るステップとを更に具備することを特徴とする媒体。１７．請求項１５記載のコンピュータ読出可能媒体において、前記方法は、インターフェースにおいて、ネットワークデバイスのうちの与えられた１つのネットワークデバイスから、プログラムに行先を定められた第２通信を受信するステップを更に具備し、前記第２通信は、与えられたネットワークデバイスのデバイス特有通信フォーマットにおけるものであり、前記方法は、インターフェースを用いて、第２通信を、与えられたネットワークデバイスのデバイス特有通信フォーマットから、プログラムと互換性を有するフォーマットへ変換するステップと、変換された第２通信を、インターフェースから、プログラムへ送るステップとを更に具備することを特徴とする媒体。１８．請求項１５記載のコンピュータ読出可能媒体において、遠距離通信ネットワークは、電話ネットワークであることを特徴とする媒体。１９．請求項１５記載のコンピュータ読出可能媒体において、プロセッサは、多数のプログラムを実行し、かつ、インターフェースは、多数のプログラムを、ネットワークデバイスにインターフェースすることを特徴とする媒体。２０．請求項１５記載のコンピュータ読出可能媒体において、インターフェースの独立した実体が各ネットワークデバイスに対して提供されるように、インターフェースの多数の実体が提供されることを特徴とする媒体。２１．プロセッサ上で実行されるプログラムと、ネットワークデバイスと、プログラムとネットワークデバイスとの間における通信を容易にするために、プログラムをネットワークデバイスにインターフェースするインターフェースとを具備し、各プログラムは、通信のための通信フォーマットを有し、各ネットワークデバイスは、通信のためのデバイス特有通信フォーマットを有し、前記インターフェースは、ネットワークデバイスに行先を定められたプログラムからの通信を、ネットワークデバイスのデバイス特有通信フォーマットへ変換する第１変換器を具備することを特徴とする遠距離通信ネットワーク。２２．請求項２１記載の遠距離通信ネットワークにおいて、インターフェースは、ネットワークデバイスからの通信を、プログラムの通信フォーマットへ変換する第２変換器を更に具備することを特徴とする遠距離通信ネットワーク。２３．請求項２１記載の遠距離通信ネットワークにおいて、ネットワークは、電話ネットワークであることを特徴とする遠距離通信ネットワーク。２４．請求項２１記載の遠距離通信ネットワークにおいて、ネットワークデバイスと通信するプロセッサ上で実行される少なくとも１つの追加プログラムを具備し、インターフェースは、プログラムを、ネットワークデバイスにインターフェースすることを特徴とする遠距離通信ネットワーク。２５．請求項２１記載の遠距離通信ネットワークにおいて、プログラムは、ネットワークを故障から復旧する復旧プログラムであることを特徴とする遠距離通信ネットワーク。２６．請求項２１記載の遠距離通信ネットワークにおいて、インターフェースは、ネットワークデバイスの状態に関する情報を得るために、検査することに対してインターフェースの外部から起こる要求無しに、ネットワークデバイスのうちの少なくとも１つのネットワークデバイスを自動的に検査する検査メカニズムを具備することを特徴とする遠距離通信ネットワーク。２７．請求項２１記載の遠距離通信ネットワークにおいて、ネットワークデバイスのうちの少なくとも１つのネットワークデバイスは、デジタルクロスコネクトであることを特徴とする遠距離通信ネットワーク。２８．請求項２１記載の遠距離通信ネットワークにおいて、ネットワークデバイスは、異なるタイプのデバイスを含むことを特徴とする遠距離通信ネットワーク。２９．ネットワークデバイスとプログラムを実行するプロセッサとネットワークデバイスへ通じるデータリンクとを有する遠距離通信ネットワークにおける方法であって、前記方法は、プログラムをネットワークデバイスにインターフェースするインターフェースを提供するコンピュータ実行ステップと、インターフェースを用いて、データリンクのうちのどのデータリンクが最も信頼性があるかを判断するコンピュータ実行ステップと、最も信頼性があると判断されたリンクを、ネットワークデバイスとの通信に対して使用されるべき主要リンクとして、指定するコンピュータ実行ステップと、データリンクのうちの他のデータリンクを、主要リンクが故障したときにネットワークデバイスとの通信に対して使用されるべき第２リンクとして、指定するコンピュータ実行ステップとを具備することを特徴とする方法。３０．請求項２９記載の方法において、ネットワークにおける条件の変化に応答して、データリンクのうちの他のデータリンクを主要リンクとして指定するために、リンクの指定を変更するステップを更に具備することを特徴とする方法。