JP2758054B2 - 通信回路網の状態に関する情報収集・表示装置 - Google Patents

Description

【発明の詳細な説明】 発明の背景 〔発明の分野〕 本発明は通信回路網の状態を監視する装置に関し、よ
り特定的には回路網に関するステータス情報を図形で操
作員に提示する装置に関する。

〔関連技術の説明〕

大規模通信回路網は、通信リンクによって相互接続さ
れた多くのスイッチングノードからなる。これらのスイ
ッチングノードは、呼出し経路指定、リンク制御及びデ
ータ圧縮のような複雑な通信タスクを遂行する。回路網
内の種々のスイッチは、ノードが利用者によって構成さ
れた態様に依存して異なる集合のこれらの通信タスクを
遂行する。更にノードを相互接続するリンクは、衛星ラ
イン或は地上ラインのようにそれぞれ独特な特色を有す
る種々の型のリンクである。

これらのスイッチ及びリンクは、ある距離だけ地理的
に離間していることが多い。スイッチが変化したり、新
しい機器が付加されたり、或はスイッチが削除されたり
すると、回路網の構成は操作員から極めて離れた場所に
おいて重大に変化する恐れがある。更に分散したスイッ
チングノードは、機能モジュールの故障、或は通信プロ
トコルの実時間内の障害のように、システムの操作員に
通信しなければならない警報状態に悩まされる。同様
に、リンクは地理的に離間した場所から実時間内に付
加、削除及び変化し得る。

回路網の診断或は障害追跡タスクを遂行する操作員
は、回路網に関連する現ステータス情報に効率的にアク
セスする必要がある。即ち、回路網のトポロジ、警報状
態、及び回路網内の種々のノード及びリンクの構成は臨
界的情報である。

大規模通信回路網からのステータス情報をタイムリな
技法で収集するタスク、及びその情報を使用可能な形で
操作員に提示するタスクは極めて複雑となり得る。好ま
しくは、この監視タスクは回路網内で進行中の通信タス
クに可能な限り干渉すべきではなく、回路網内の単一の
監視ステーションに向う監視用情報で通信チャネルが過
負荷にならないようにすべきである。更に、監視装置
は、監視機能を支援するために回路網内を走る通信タス
クに大規模な変化を生じさせることなく実現することが
好ましい。

〔発明の概要〕

本発明は、回路網内の通信チャネルを過負荷にせずに
通信回路網のステータスに関する情報を収集し表示する
装置を提供する。更に、この情報は新規且つ有用な形で
操作員に表示される。最後に、本装置は回路網内を走る
通信タスクの設計に最小の衝撃しか与えずに実現され
る。

本発明が動作する回路網は、複数の分散したスイッチ
ングノード及びこれらのスイッチングノードを接続する
複数のリンクを含む。各スイッチングノードは回路網を
通して転送される呼出し及びデータを取扱う通信機能を
遂行する。更に、各スイッチングノードは、そのノード
の警報状態をリストしたノード警報表を含むノード事象
ログを保持し、ノード上を走るタスク及びハードウェア
の構成を識別するノード構成データベースを保持する。

本発明による監視装置は、操作員入力インタフェース
を含むモニタノードを具備する。モニタノードは分散し
た複数のスイッチングノード内の第１のスイッチングノ
ードに結合される。モニタノードは、回路網のトポロジ
を表わすトポロジデータを維持し且つデータを更新する
ために第１のスイッチングノードとの第１のプロトコル
をサポートする第１のアプリケーションを含む。更にモ
ニタノードは、回路網内のノード事象ログは挿入された
警報状態のリストを維持し且つリストを更新するために
分散した複数のスイッチングノードとの第２のプロトコ
ルをサポートする第２のアプリケーションをも含む。第
３のアプリケーションは、スイッチングノードの構成を
表わすモニタデータベースが回路網内のノード構成デー
タベースに挿入されるとモニタデータベースを維持する
ためにモニタノード内を走る。この第３のアプリケーシ
ョンも、ノード構成データベースへの更新のために、モ
ニタデータベースを更新すべく分散した複数のスイッチ
ングノードとの第３のプロトコルをサポートする。

モニタノードは、回路網内の対象ノードまたは他の物
体を識別する操作員入力に応答し且つモニタデータベー
ス、警報状態のリスト及びトポロジデータに結合されて
いる表示アプリケーションをも含む。表示アプリケーシ
ョンは表示モニタ上に複数のウインドウを表示して対象
ノード、回路網トポロジ及び警報状態に関する構成デー
タを操作員に提示する。

モニタノードが結合されている第１のスイッチングノ
ード上では、アプリケーションがノード上で遂行される
通信機能に応答してトポロジデータを生成し、モニタノ
ード内の第１アプリケーションとの第１のプロトコルに
応答してトポロジデータを第１のアプリケーションへ送
る。

第１のスイッチングノードを含む回路網内に分散され
た各スイッチングノード上では、ノード事象ログに結合
され且つ第２のアプリケーションとの第２のプロトコル
に応答するアプリケーションが、ノード事象ログに入っ
た警報状態を表わすデータをパッケージ化して第２のア
プリケーションへ送る。更に、第１のスイッチングノー
ドを含む回路網内に分散されている各スイッチングノー
ド上では、ノード構成データベースに結合され且つ第３
のアプリケーションとの第３のプロトコルに応答するア
プリケーションが、ノード構成データベースからのデー
タをパッケージ化し回路網を通して第３のアプリケーシ
ョンへ送る。

本発明の別の面によれば、モニタノードは、回路網内
のノード事象ログに入った事象記録のリストを維持し且
つ分散したスイッチングノードとの第４のプロトコルを
サポートする第４のアプリケーションを含む。分散した
複数の各スイッチングノード上では、そのノード上のノ
ード事象ログに結合され且つ第４のアプリケーションと
の第４のプロトコルに応答するアプリケーションが、ノ
ード事象ログに入った事象報告を表わすデータをパッケ
ージ化して第４のアプリケーションへ送る。

本発明の付加的な特色は、添附図面に基く以下の説明
及び請求の範囲の精査から決定することができる。

〔図面の簡単な説明〕

第１図は本発明によるシステムの概要を示すブロック
線図であり、 第２図は本発明によるモニタノードの表示上のマルチ
ウィンドウの図であり、 第３図は本発明によるモニタノードのブロック線図で
あり、 第４図は本発明によるスイッチングノードのブロック
線図であり、 第５図は本発明により複数のモニタノードを含むシス
テムのブロック線図であり、 第６図はモニタノードとスイッチングノードとの間に
分散されている事象ログアプリケーションのためのシス
テムの概要であり、 第７図は折返しの前後のスイッチングノード上の事象
ログのスナップショットであり、 第８図は通報バッファと、スイッチングノード上の事
象アプリケーション上で発生するバッファ内のデータの
圧縮とを示し、 第９図は事象アプリケーション内のセッション開通通
報の通報構造を示し、 第10図は事象アプリケーションの確認通報構造を示
し、 第11図は事象アプリケーションの次のパケット通報構
造を示し、 第12図は事象アプリケーションのセッション閉鎖通報
構造を示し、 第13図は事象アプリケーションの事象パケット通報構
造を示し、 第14図はモニタノード上を走る事象アプリケーション
の一部の事象遷移図であり、 第15図はスイッチングノード上を走る事象アプリケー
ションの一部の状態遷移図であり、 第16図はスイッチングノード上及びモニタノード上の
事象記録を記憶するための書式を示し、 第17図はモニタノード上及び複数のスイッチングノー
ド上の警報表アプリケーションのためのデータ流れ図で
あり、 第18図はモニタノード上の警報表アプリケーションと
分散してスイッチングノード上の対応アプリケーション
との間のセッション初期化プロトコルを示し、 第19図はモニタノード上の警報表アプリケーションと
分散したスイッチングノード上の対応アプリケーション
との間の正常セッションプロトコルを示し、 第20図はモニタノード上の警報表アプリケーションと
スイッチングノード上の対応アプリケーションとの間の
リセットプロトコルを示し、 第21図はデータベースアプリケーションのためのデー
タ流れ図であり、 第22図はデータベースアプリケーションのためのモー
ドノード上のデータ構造を示し、 第23図はデータベースアプリケーションのための分散
したスイッチングノード上のデータ構造を示し、 第24図及び第25図はモニタノード上を走るDBAとスイ
ッチングノード上を走るDBAPEとの間の正常動作のため
の通報交換プロトコルを示し、 第26図及び第27図はモニタノード上を走るDBAとスイ
ッチングノード上を走るDBAPEとの間の失通報のための
通報交換プロトコルを示し、 第28図及び第29図はモニタノード上を走るDBAとスイ
ッチングノード上を走るDBAPEとの間の通報同期乱れの
ための通報交換プロトコルを示し、 第30図はモニタノード上を走るDBAとスイッチングノ
ード上を走るDBAPEとの間の異常障害のための通報交換
プロトコルを示す。

〔実施例〕

以下に添附図面を参照して本発明の好ましい実施例を
詳述する。

即ち、先ず第１図乃至第５図を参照してシステムレベ
ルを説明し、このシステムレベルの説明の後に好ましい
実施例内を走る、本発明に関連する分散したアプリケー
ションを説明する。

I.システムの概要 第１図は本発明が操作する通信システムを示す。詳述
すれば、通信システムは、カリフォルニア州レッドウッ
ドシティ，ペノブスコット400のネットワーク・イクイ
ップメント・テクノロジース社から供給されている集積
ディジタル回路網交換器（IDNX）のような分散して複数
のスイッチングノード１、２、３、４を含む。これらの
スイッチングノードはリンク５、６、７によって互に相
互接続され、リンク８、９、10を介して回路網内の他の
スイッチングノードに接続されている。

スイッチングノード１はリンク12を介してモニタノー
ド11の接続されている。モニタノード11に結合されてい
るのは、回路網内のスイッチングノードを走る構成プロ
グラムにアクセスするために使用され、且つリンク14を
介してスイッチングノード１と通信する操作員インタフ
ェース13である。モニタノードは、回路網内の分散した
複数のスイッチングノード及びリンクに関するステータ
ス情報を表示する。ノード11上に表示された情報を利用
して操作員は、インタフェース13を通して構成プログラ
ムを操作し回路網全体の診断機能、障害追跡、及び構成
タスクを遂行する。

II.表示ウィンドウ モニタノードは、第２図に示すような複数のウィンド
ウを含む例えばサン・マイクロシステムズ社のワークス
テーションが設けられているモニタのような表示装置を
含む。表示の第１のウィンドウ20は回路網のトポロジを
操作員に提示する。第２図に示すように、回路網は北米
大陸内の合衆国にまたがって地理的に広がっている複数
の分散したスイッチングノード21を含む。ウィンドウ20
は合衆国の地図と、スイッチングノードの位置の標識
と、それらの間のリンクを表わす線とを表示する。更
に、ウィンドウ20は特定ノードのための強調表示機能を
も含み、22に示すようにそのノードで発生した警報状態
を表示する。好ましい実施例においては、ノードはカラ
ーを使用して強調表示され、また解釈を容易ならしめる
ために凡例29が設けられている。凡例29は回路網成分を
図形的に示す記号を識別する情報をも含む。

表示の第２のウィンドウ23は対象ノード、即ちノード
Ｘの構成を示す。利用者インタフェースを通して操作員
は、ウィンドウ表示システムに広く用いられている例え
ばマウス及びカーソルを使用して対象ノードを指定する
ことができる。マウスは、ウィンドウ20内の回路網トポ
ロジ地図上の主体ノードまでカーソルを移動させるため
に使用される。マウス上のスイッチを設定することによ
って選択されたノード構成をウィンドウ23内へ移して、
表示させることができる。ノード構成はノードの機能要
素CRD1,CRD2,……を示図形表示を含む。更にマウス及び
ウィンドウィングアルゴリズムを使用して回路網内のカ
ード及びリンクに関する文章情報をリストすることがで
きる。

表示上の第３のウィンドウ27は回路網全体で発生して
いる警報状態のリストを提示する。

表示上の第４のウィンドウ28は、操作員インタフェー
ス31をスイッチ構成ツール、スイッチ診断等に役立て得
るように、対対話形使用者インタフェースウィンドウと
して使用される。スクリーン上のこの領域は、モニタノ
ードの構成プログラムのためにも使用される。

表示上の第５のウィンドウ29はアイコンによって操作
員にメニューサービスを提示する。

付加的な文章ウィンドウ30は、種々のモニタアプリケ
ーションのステータスのようなモニタシステム通報を表
示する。

この表示型式は回路網内のステータス及び警報状態に
関する情報を使用可能な形で提供する。

III.モニタノードの概要 第３図は本発明によるモニタノード上で走るアプリケ
ーションのブロック線図である。前述のように、モニタ
ノードは第２図に基いて説明した表示をサポートする表
示プロセッサ33を含む。情報は、警報表アプリケーショ
ン34、トポロジデータアプリケーション35及びデータベ
ースアプリケーション36から表示プロセッサ33へ供給さ
れる。モニタノードはその他に、回路網内の分散したス
イッチノードからの事象記録のログを維持する事象ログ
アプリケーション37も含む。これは、表示プロセッサ33
が直接使用するのではなく、報告生成のために使用され
る。

モニタノードは、表示プロセッサ33のノード構成ウィ
ンドウ23内に表示するために対象ノードを識別する前述
のキーボード及びマウスのような１或は複数の利用者入
力インタフェースデバイス38を含む。

モニタノードはハイレベルデータリンク制御手順（HD
LC）リンク39を通して回路網内のスイッチングノードに
接続されている。従ってHDLCポートサーバアプリケーシ
ョン40が含まれており、このアプリケーションを通して
警報表アプリケーション、トポロジデータアプリケーシ
ョン、データベースアプリケーション及び事象ログアプ
リケーションが分散したスイッチングノードへ送られ
る。更に要求に応答して、分散したスイッチングノード
からHDLCポート40を通してデータが受信される。

事象ログアプリケーション37、警報表アプリケーショ
ン34、トポロジデータアプリケーション35及びデータベ
ースアプリケーション36は分散したタスクであり、各タ
スクの一部はモニタノード上を走り、残りのタスクは回
路網のスイッチングノード上を走る。これらのタスクの
詳細に関しては後述する。

IV.スイッチングノードの概要 第４図は、回路網内のモニタノードに結合されている
スイッチングノード上を走るタスクを示す。即ちこのス
イッチングノードは、通信を受信し通報をモニタノード
へ供給するHDLCリンク39に結合されたHDLCポート45を含
む。また第４図に示すように、スイッチングノードは回
路網47を通る通信を管理するために46で概示した通信機
能も遂行する。事象ログ48は、通信タスク46に応答して
スイッチングノードによって維持される。更にローカル
ノードの構成を示す構成データベース49もスイッチング
ノード上に維持されている。最後に、呼出し経路及び類
似操作の際に通信タスク46によって使用される回路網の
トポロジを示すデータベースを保持するために、トポロ
ジアプリケーション50がスイッチングノード上を走る。

更に、警報表インタフェース51、事象ログインタフェ
ース52及びデータベース53が第４図に示すスイッチング
ノード上を走る。結合されたプロセッサエグゼキュータ
APEと呼ぶこれらの各インタフェース51、52、53は、事
象ログ48或は構成データベース49からの情報を前処理し
てパッケージ化し、モニタノードからの要求に応答して
モニタノードへこの情報を送る。またこれらの各インタ
フェース51、52、53は単一のモニタノードに奉仕する。
第４図に示す実施例においては、これらのインタフェー
スはモニタNo.1に奉仕する。もし回路網に第２のモニタ
が付加されれば、第２のモニタ用の第２の警報表インタ
フェース、第２のモニタ用の第２の事象ログインタフェ
ース、及び第２のモニタ用の第２のデータベースインタ
フェースが必要である。

トポロジアプリケーション50は、そのスイッチングノ
ードに結合されたモニタノードから受信した要求に直接
応答してトポロジデータを供給する。この情報は回路網
全体のために維持されているから、HDLCリンク39を介し
てモニタノードが結合されているノードは、モニタノー
ドへトポロジデータを送らなければならない唯一のノー
ドである。

好ましい実施例における情報ログは、そのノード用の
情報記録及び警報表を維持する。この警報表用のインタ
フェースは、後述するように警報の保全性を保証するた
めに、事象ログ用のインタフェースから分離されてい
る。

第５図は２つのモニタを含む回路網の概要図である。
本発明によるモニタタスクは回路網内の通信タスクを殆
んど妨害しないから、本発明は単一の回路網に複数のモ
ニタの結合を可能ならしめる。例えば第１のモニタ65は
回路網内の第１のスイッチングノード66に結合されてい
る。スイッチングノード66はスイッチングノード67及び
68に結合され、またノード67及び68を通して回路網内の
他のスイッチングノードに結合されている。第２のモニ
タ69はスイッチングノード70に結合されている。スイッ
チングノード70はスイッチングノード71及び回路網内の
他のノードに結合されている。前述のように、それぞれ
のモニタ１及び２によって奉仕されている回路網内の各
ノードは、各モニタ毎に警報表インタフェース51、各モ
ニタ毎に事象ログインタフェース、及び各モニタ毎にデ
ータベースインタフェースを有していよう。スイッチン
グノード66はトポロジデータをモニタ１に送り、スイッ
チングノード70はトポロジデータをモニタ２へ送ること
になろう。

V.モニタシステム操作 好ましい実施例においては、モニタシステムの表示プ
ロセスサーバ33及び利用者入力インタフェース38は回路
網の現状態及びトポロジの表示を管理し、メニューサー
ビスを提供し、そして操作員が使用するための構成モジ
ュールを提供する。回路網の現状態は、分散したスイッ
チングノード内で発生する警報の警報表アプリケーショ
ン34から、回路網の全域で作動しているノードの回路網
トポロジアプリケーション35から、及びスイッチングノ
ード構成に対する変化のデータベースアプリケーション
36からの通知によって決定される。また構成モジュール
は、回路網にノードが付加されたり或は回路網からノー
ドが削除されたことを表わし、且つ表示されるウィンド
ウを変更するための情報を表示プロセッサ33へ供給す
る。

全てのノードが最大の大きさに構成されているような
大規模な回路網においては、モニタノードのためのデー
タ空間要求は莫大であろう。合理的で実際的な大きさを
維持するために、表示プロセッサ33は操作員によって像
が要求された場合に限ってカードレベル及びそれ以下で
カード構成情報を構成する。

モニタノードはオラクル（ORACLE）として知られてい
る市販のデータベースに基づく基本データ管理システム
を含む。オラクルを使用するモニタ上の各アプリケーシ
ョンは広範に異なる表、行及び列上での読み出し、挿入
及び更新機能を必要とする。モニタ上のデータベース管
理システムへのインタフェースは、アプリケーションが
発行するSQLステートメントに応答する関数呼び出しで
ある。データベースは、データベースアプリケーション
36からの全てのノード構成データ、事象ログアプリケー
ション37からの事象記録を文章記述と共に含む。標準SQ
Lウィンドウは、利用者がデータベースの任意問合せを
行うことができるモニタノードを通してモニタノードの
操作員に提供される。

ウォッチドッグタスクは、データベース内にリストさ
れた事象の数を周期的に計数して利用者とのセッション
を開始し、事象及び誤りを記憶システム内の自由空間に
所定期間保存し、消去することを利用者に要求する。

モニタノードとスイッチングノードとの間のインタフ
ェースは、モニタノードとスイッチングノード内のタス
クとの間に通報の送信を可能ならしめる。前述のよう
に、このインタフェースは、インタフェースを管理する
ためにタスクがモニタノード及びその結合されたスイッ
チングノード上を走るHDLCリンクである。

リンクのモニタ側においては、モニタ上を走るアプリ
ケーションからの通報はHDLCリンク上に書き込まれる。
またリンクから受信したパケットは、モニタノード上の
適切なアプリケーションに分配される。リンク39のスイ
ッチングノード側ではタスクは入通報を回路網とモニタ
とから受信する。このタスクは全てのモニタアプリケー
ションに対して“ゴーストライタ”として作用する。入
パケットは全回路網通報を含む。モニタシステムに奉仕
する分散されたタスクは、それらが走っているノードの
識別名を、回路網に透過的に送られる通報内に単に挿入
するだけである。このモニタノードに結合されているス
イッチングノード上のタスクは、モニタノードからの通
報を見出しはそのままで転送する。

モニタノードは、ブロック線図には示してないが、核
及びシステム初期化アプリケーションを含む。核は、そ
のノード上を走る複数のアプリケーションに対してタス
ク間通信、メモリ管理、デバッギング及び追跡、及びタ
スク管理機能を提供する。核はその基本移送機構として
ユニックスIPC利用者データグラムプロトコル（UDP）を
使用する。核は、モニタ上を走るアプリケーションから
の通報をHDLCリンクを通して結合されたスイッチングノ
ードへ、そして回路網内へ供給すべきか否かを決定す
る。

モニタシステム事象アプリケーションは回路網内の全
てのノードから事象を検索する。このアプリケーション
は２つの部分、即ちモニタ上を走る事象ログアプリケー
ション、及び分散したスイッチングノード上を走る事象
ログインタフェースからなる。モニタノードは回路網を
通してスイッチングノードから事象情報を受け、オクラ
ルデータベースへの情報を記録（ログ）する。スイッチ
ングノード上を走る事象ログインタフェースは、スイッ
チングノード上の事象ログ管理者から事象情報を検索
し、この情報をモニタノードへ送る。

これらのタスクの詳細な明細は後述する。

警報表アプリケーションは、モニタノード上を走るア
プリケーション及びスイッチングノード上を走るインタ
フェースアプリケーションからなる。このアプリケーシ
ョンは回路網内の分散したスイッチングノードが変化す
るとそれらからの警報表を検索するので、表示システム
及び爾後にモニタ上を走る他のアプリケーションは回路
網のステータスの変化を追跡することが可能である。警
報表アプリケーション（ATA）は、モニタノードへの単
一の警報情報源である。この情報は事象列から入手する
こともできるが、このようにして抜き出されるのではな
い。また、警報表アプリケーションは、ウィンドウに供
給される臨界性、時間及びノードによって分類された回
路網内の活警報の表示を含む情報を管理する。

回路網トポロジアプリケーション（NTA）は、モニタ
ノードでは既知の回路網トポロジの現状態に関する情報
を、残余のモニタノードアプリケーションに対して提供
する単一の情報源である。NTAは、モニタノードが結合
されているノード上を走る回路網管理タスクから回路網
トポロジマップを検索する。この情報は規則的なポーリ
ングによって検索される。

データベースアプリケーション（DBA）は回路網全体
に分散しているスイッチングノードから構成データベー
スを検索し、それらをモニタノードのデータベースシス
テムにモニタノード書式で記憶させる。構成データベー
スは、スイッチングノードのデータベースを変化し、モ
ニタノードがそのデータベースのどの部分が変化したの
かを決定できなければ、アップロードされる。このアプ
リケーションはモニタノードと複数のスイッチングノー
ドとの間に分散されている。アプリケーションの２つの
部分は、データベースの信頼できる順序引渡しを行うプ
ロトコルと通信する。またスイッチングノードにおいて
データベースが更新されると、これらの変化はモニタノ
ードに送られる。

図形構成ツールは、表示プロセッサのためにノード、
回路網及びビューの定義及び配置を可能ならしめる。基
本的な回路網対象はノードである。あるノードに関する
情報の表示が構成される前に、利用者はノードをモニタ
ノードのオラクルデータベース内へ挿入しなければなら
ない。このノードがデータベース内に配置された後に、
それは表示プロセッサに対して使用可能となる。

表示システム内を走る図形構成アプリケーションは、
もし必要ならば表示の目的でノード及び副回路網に集群
させるために、操作員によって作用される。回路網及び
ノードはビュー内に配置される。あるビューの中で利用
者はノードを任意の位置に配置することが可能であり、
それによって容易に解読できるビューを作ることができ
る。

それぞれのモニタノードアプリケーションのスイッチ
ングノード側の若干のアーキテクチャ特性を共用する。
第１は、モニタノードとの順序付けられた、信頼できる
データ交換を保証するプロトコルを、それらの全てが使
用することである。全てのアプリケーションのためのこ
のプロトコルはウィンドウサイズが１の肯定応答プロト
コルである。これはこのプロトコルを簡単な指令応答シ
ーケンスならしめ、モニタノードに奉仕する所与の時点
における回路網内のトラフィック量の制御を行わせる。
最大の関心事は、モニタノードに結合されているスイッ
チングノードに到着する通報の数である。このプロトコ
ルは大量のモニタ情報がそのノードに過ロードされるの
を防ぐ。

スイッチングノード側のアプリケーションの第２のア
ーキテクチャ特性は、そのインタフェースが対話するス
イッチングノードの通信機能に奉仕するタスクと同一の
スイッチングノード内の中央処理ユニット上を各アプリ
ケーションが走ることである。これはインタフェースの
設計を簡易化し、インタフェースとインタフェースが対
話するタスクとの間で通報が失われ得ないことを保証
し、且つモデル内バス上のトラフィックを減少させる。

第３に、その上をインタフェースが走るCPUは、もし
可能ならば、ノードのマスタプロセッサではなく双対プ
ロセッサである。これは、インタフェースが使用できる
データのためのメモリの量を最適化し、またノード内の
呼出し処理タスクに及ぼす監視タスクの衝撃を最小にす
る。

モニタアプリケーションの第４のアーキテクチャ特性
は、各インタフェースが単一のモニタアプリケーション
に奉仕し、単一のモニタタスクと対話することを要求す
る。これはインタフェースの設計を簡略化する。前述の
ように、もし２つのモニタノードが同じスイッチングモ
ードを管理するれば、各モニタノードはそれ自信のイン
タフェースの集合をそのスイッチングノード上に有する
ことになろう。

回路網トポロジアプリケーション（NTA）、データベ
ースアプリケーション（DBA）、警報表アプリケーショ
ン（ATA）及び事象アプリケーション（EVA）の詳細な実
施例を以下に説明する。

VI.事象アプリケーションの設計 1.序節 事象アプリケーションは、第６図に示す回路網内のス
イッチングノードで発生する事象を収集する責を負う分
散したアプリケーションである。このアプリケーション
は２つの半部分、即ちモニタ側の一方の半部（EVA）と
ノード回路網の側の他方の半部（EVAPE）とからなる。
モニタ部分は回路網部分から事象を受け、必要に応じて
それらをモニタシステムを通して分配する。

事象アプリケーションのモニタ側は事象アプリケーシ
ョンタスクEVA104を含む。EVAは回路網トポロジアプリ
ケーションNTA105及びモニタデータベースシステムDBS1
06と通信する。

事象アプリケーションの回路網側においては、事象AP
EタスクEVAPE102が各ノード内を走り、ロール事象ログ
管理者ELM103と対話する。

モニタ上のEVA104は、事象の信頼できる引渡しを保証
するために、回路網内の各EVPE102とのセッションを維
持する。またこのセッションのアイディアはEVA104にEV
APEの流れ制御をも可能ならしめ、従ってモニタノード
が回路網からの通報で溢れるのを防ぐ。

更にEVAPEは、伝送効率を増加させることができ、回
路網トラフィックを減少させ、ELM103から到着する事象
通報をEVA104に転送する前にパッケージ化することによ
ってローカルバッファ空間の使用を効率的にする。

2.システムの概要 第６図は実現されるシステムの概要を示す。同図は論
理モジュールと、それらの間を渡る通報を示す。転送サ
ービス101はタスク間、ここではEVA104とEVAPE102との
間を通る透過通報を取扱う。これらは転送サービス101
に気付かない。

3.EVAPE 3.1 要求されるELM機能 事象アプリケーションの設計は、ELM103の１つの機能
特色に基く。このアプリケーションは、折返しが発生し
たことを検出する付加機能を有し且つこの折返しをそれ
に従属するタスク（EVAPE102）へ通信する。

第７図に示すように、ここでは折返しとは意味論的に
事象ログの中のｎ個の事象の年代順シーケンスの切れ目
のことであり、例えばｎ事象の中の事象１が成功裏に検
索されたものとすれば、EVAPE102が事象１及び２を読み
出すために複数のCPUサイクルに亘って待機している間
にELM103が事象１及び２に重ね書きしてしまうであろ
う。従ってEVAPE102が再び走る時にELM103から入手する
であろう次の事象は、EVAPE102が実際に欲している事象
２ではなく、既に読み出された事象１を伴うシーケンス
内には最早存在しない事象である。折返しが発生したの
である。

ELM103は未知数の事象の損失をもたらすこの折返し
を、事象ログ通報のフラグフィールドでEVAPE102に通知
しなければならない。EVAPE102自体はこのような折返し
を検出することはできない。

折返しが発生した時、モニタデータベースにマークす
ることを除いて、他の動作は行われない。折返しによっ
て失われた事象は検索不能である。

3.2 EVAPEパッケージ化方式 EVAPE102タスクは、回路網内の全てのスイッチングノ
ード上のローカルELM103と通信する。

EVAPE102は事象ログからの読み出し要求を、モニタ上
の対等事象アプリケーションタスクEVA104から受ける。
そこでEVAPE102は事象パッケージ内に含まれた若干数の
事象で返答することになろう。

EVA104とEVAPE102との間のプロトコルの詳細は4.2節
において説明する。

EVAPEはいわゆる据置きモードでELMと通信する。即ち
事象はELM103から非同期でEVAPE102へ送られる。EVAPE1
02は、最大の大きさ（900バイト）の通信タスクから１
つのパケット内に正確に適合するようなある数の事象に
到達するまで、または他のある状態が発生する（4.2節
参照）までは一時に単一の事象を要求する。

この数は28物理事象記録とすることが決定されており
（28^*32バイト＝896バイト）、各事象の大きさ（１〜３
物理記録）に依存して、動的に調整可能な数の論理事象
に変換する。

ノードメモリは最小512バイトのチャンクに割当られ
ているので、ログから検索される全ての事象を送るので
はなく事象の束を送ることによって、モニタノードを溢
れさせることなく処理能力が増加し、また内部バッファ
が最良に使用されることになる。

前述のように、ELMから事象ログ通報（Event Log Ms
g）を受けるとEVAPAはそれをアンパックする。即ち基本
的には事象情報（82バイト）を検索し、事象トークンが
全て使用されていなければ、初期要求への応答としてEV
A104へ送るべき通報をアセンブルするために使用するバ
ッファの中によりコンパクトな形で記憶する。“完全に
ロードされた”事象は圧縮することができず、事象ログ
通報で到来した通りに記憶される。

EVAPEが事象を圧縮する方法を第８図に示す。

第８図は２トークンを有する事象を保持する事象ログ
通報を示す。従って、EVAPE102通報バッファ内には２ト
ークンのみが記憶され、この事象には使用されない他の
６トークン分の空間（６^*６バイト＝36バイト）が節約
される。〔Ex-pand−これはクリアではない〕 3.3 EVAPE緩衝方式 EVAPEがその事象パケットをアセンブルし終り、EVAか
ら要求されると、EVAPEはそれをモニタ上のEVAに送る。
EVAPEがEVAから次の送信許可を入手するまでに待機しな
ければならない時間（ここではラウンドトリップ遅延と
呼ぶ）中、EVAPEは次のパケットを生成するために事前
緩衝を開始する。このようにすると事象を少し早く収集
することができるがEVAPEが数事象を見逃す恐れがあ
る。

勿論EVAPE102がどの程度事前緩衝できるかの限界は存
在する。ノードメモリ割当ての制約の故に、及び平均的
には多分それ程多くの事象は存在しないので、EVAPEは
次のパケットのアセンブルを試みるだけである。

ラウンドトリップ遅延中に次の事象パケットをアセン
ブルするためにここで必要とする緩衝空間は1Kバイトで
ある。EVAPEに恒久的に割当てられているメモリは、EVA
PEが送られて来たばかりの、しかし未だ肯定応答してい
ないパケットを記憶しなければならないため、2Kバイト
である（4.2.2参照）。

3.4 EVAPE-ELMプロトコルの基本 EVAPEは、ELM及びモニタ上のEVAからセッション開通
通報を受けているEVAとのセッションを開始する。EVA-E
VAPEセッションが確立された後EVAPEは、EVAから受けた
フィルタ要求通報をELMへ送ることによってELMとの通信
を開始する（EVA-EVAPEセッション開通に関しては4.2.1
節参照）。

フィルタ要求通報は据置きモードを表わし、ELMが再
びポーリングされるまで一時に単一の事象を送るように
ELMに告げる。

ELMは、もしフィルタ要求通報が全て順番に受信され
ていれば、またもしフィルタ指令ブロックFCBを構成す
るためにELMが使用できる充分なメモリが存在したなら
ば、事象ログ通報内の最後のフィルタ要求通報への応答
として第１の一致事象を返す。もし一致事象が存在しな
ければ、無事象通報を返す。もしフィルタ要求通報の順
序が乱れているか、またはELMがFCBのためのメモリを失
っていれば、サービス不能通報が返される。

フィルタ要求通報の順番引渡しを保証するために、EV
APEはそれらをEVAから受信するとそれらを緩衝し、必要
ならばそれを順序付ける。これは、EVAPEがセッション
開通通報内のパラメタを通してどれ程多くのフィルタ要
求通報が予期されるかを知るので（第９図参照）、行う
ことができるのである。

EVAPEは１事象毎に返される次の事象通報を通してELM
から更なる事象を要求する。

最後のポーリング以後に事象が記録されなかった場合
には、ELMは無事象通報を返す。

ELMから返された事象は全て順番になっている。但し
事象ログが２つの次の事象通報間で折返された時はこの
限りではなく、この場合はELMは事象ログ通報のフラグ
フィールドによって通知する。

EVAPEはELMとのその関係のためにタイマを保持しなけ
ればならない。このタイマはEVAPEが通報に対する応答
をELMから受信しない場合にはタイムアウトしなければ
ならない。これは多分、ELMが最早生きていないことを
表わす。EVAPEは、応答を受信するかまたはEVAにその状
態を告げる（事象パケット通報のフラグフィールド内の
ELMクラッシュフラグ）まで、２回までその通報を送る
ことを最試行する。

ELMの死は潜在的に事象に損失に結びつく。何故なら
ばそれらが発生したとしてもそれらを記録できないから
である。明らかに事象ログバッファがクリアされること
はない。

ELMが復活した場合、勿論ELMは何者をも再呼出ししな
いので、EVAPEはELMとの新セッションを確立しなければ
ならない（無FCB）。EVAPEはそのセッションパラメタ
（フィルタ要求通報）にEVAPEの通告に対するEVAからの
応答として受信する。何故ならば新EVAPE-ELMセッショ
ンはEVA-EVAPEセッションの再初期化を暗示するからで
ある。

障害を起したELMを検出するためにEVAPEが使用するタ
イムアウトは、EVA-EVAPEプロトコルに使用されるタイ
ムアウトよりも小さく選択される。

4.EVA 4.1 EVAの概要 モニタ事象アプリケーションタスク（EVA）はモニタ
上を走り、ノード回路網内の各EVAPPEとのセッションを
維持する。

EVAは、EVAPEが事象を送る度に各ノードからそれらを
収集する。EVAは全ての事象をモニタデータベースDBS内
に記録する。基本的には、事象の型及び副型は問合せ及
び報告生成の目的のために意味ある情報に変換しなけれ
ばならない。EVAは事象記録をDBS内にそれらの生の形で
記憶するだけである。事象意味論は別のアプリケーショ
ンによって説明する（７節のEVA-DBインタフェース参
照）。

EVAは、モニタ回路網トポロジアプリケーションNTA10
5が回路網内に新ノードが付加されたこと、または１つ
のノードが消滅したか否かを知っているので、このアプ
リケーションとインタフェースしなければならないであ
ろう。NTA105はEVAに何れかの状態を通告する。

あるノードがモニタによって管理されている区分内に
入ると（リセット或は新ノードの場合の何れかの後
に）、NTA105はノードアップ通報をEVAへ送る。同様にE
VAは、あるノードがクラッシュした場合にはノードダウ
ン通報を、またあるノードがその区分から外されるとノ
ード削除通報を受ける。

最初の場合にはEVAは新モード上を走るEVAPEとのセッ
ションを開かなければならない。。これに先立って、EV
Aはそのノードに創成通報を送ることによってEVAPEタス
クを遠隔的に創成する。後の２者の場合には、そのノー
ドは最早到達不能であるかまたは何等の関心もないか
ら、EVAはEVAPEのポーリングを停止できる。

4.2 EVA-EVAPEプロトコル EVAは回路網内のノード上の各EVAPEとのセッションを
維持する。各セッションは、セッション開通通報を介し
てEVAによって初期化される。EVAPEがセッションを開始
することはできない。

EVAは、EVAPEがELMとの通信を開始するために必要と
するフィルタ要求通報を供給する。これによってモニタ
側に、どのノードからどの事象を記憶したいのかを制御
する柔軟性を与えることができる（ハードコーデッ
ド）。

4.2.1 セッションの開通 EVAは、セッション開通通報のシーケンスを用いて全
てのセッションを開き、全てのEVAPEからの応答パケッ
トを待機する。これは、例えば32ノード回路網において
は、もしリンクが許容すれば、32事象パケットが殆んど
同時にモニタノードに到着する可能性がある。しかしEV
Aは一時に１パケットだけしか受入れられない。

オープンセッション通報は、パラメタとして後続する
フィルタ要求通報の数（フィルタ数）を、また未使用フ
ィールドとしてEVAから要求された時にEVAPEが送ること
を許される事象パケットの数（許可パケット）を有して
いる。この数は１である。セッション開通通報の構造に
関しては第９図を参照されたい。

セッション開通通報当り１事象パケット（許可パケッ
ト＝１）のEVAPEからの応答は本質的に順序付けられた
引渡しを規定し、従って容易に実現される。２或はそれ
以上の未決パケットはウィンドウ機構を要求することに
なろうが、より大きいウィンドウサイズを許可する柔軟
性を遠隔のノードに提供して性能を高めよう。これは変
形実施例において望ましいことであるかも知れない。

セッション開通通報を受信した後、EVAPEは確認通報
を送ることによって確認する。確認通報の構造は第10図
に示してある。確認通報は、送られた最後の事象パケッ
トのシーケンス番号を保持する（一貫性検査のため）フ
ィールド（パケットシーケンス番号）を有する。セッシ
ョン開通通報への応答としては、確認通報のパケットシ
ーケンス番号は０となろう。

EVAは、EVAPEから確認通報を受けない時にはフィルタ
要求通報を送ることを試みない。その代りにEVAはタイ
ムアウトし、通常の再伝送及び後述のタイムアウト方式
に従ってセッション開通通報を再送する。確認通報を入
手すると、EVAは引続きセッション開通通報内は指定さ
れているフィルタ要求通報の番号を送る。

これは、フィルタ要求通報が失われた場合もカバーす
る。もしEVAPEが応答しなければEVAはタイムアウトし、
それから回復する。

EVAPEは、別の確認通報（パケットシーケンス番号
０）を送ることによって全てのフィルタ要求通報の受信
を確認する。EVAが１つを受信しない場合には、EVAは全
再伝送方式に従って再び作動する。

セッション開通相は、EVAがこの確認通報を受信した
時に完了する。EVAが、次のパケット通報を介して第１
のパケットを要求することによって直ちにパケット転送
相に入る。

4.2.2 事象パケットの転送 EVAは、第11図に示す次のパケット通報を介してEVAPE
からパケットを要求する。

次のパケット通報はパラメタとして、予期されるパケ
ットのシーケンス番号を保持するパケットシーケンス番
号を有する。

＊ もしパケットシーケンス番号が予期される次のパケ
ットのシーケンス番号であれば、シーケンス内の次のパ
ケットが要求され、先に受信したパケットシーケンス番
号１のパケットが肯定応答される。

＊ もしパケットシーケンス番号が受信した最後のパケ
ットのシーケンス番号であれば、送られた最後のパケッ
トの再伝送が命令される。

EVAPEは、EVAからの次のパケット通報を待機している
間も、2.2節で説明したように事象に関してELMをポーリ
ングし続け次のパケットをアセンブルしている。次のパ
ケット通報が到着した時そのパケットシーケンス番号が
このパケットのシーケンス番号と一致すればEVAPEは応
答として直ちにこのパケットを送ることができる。

もし次のパケット番号が再伝送された通報であり、EV
APEは最後に送ったパケットを再び送る（このパケット
は肯定応答されるまで将にこの目的のために記憶されて
いるのである）。

以上の如く、EVAPEは恒久的に２つの事象パケット、
即ち最後に送ったパケット及び次に送るパケットを保持
している。これは2Kバイトのバッファ空間を使用する。

事象パケット通報がEVAPEからEVAへ送られる際の書式
を第13図に示す。

EVAは、リンク上で失われた事象パケットを検出する
ためにEVAPEとの関係においてタイマを保持しなければ
ならない（パケット時間）。問題は、各EVA-EVAPEセッ
ションとは異なり且つ回路網トポロジ及び経路指定表に
依存するこのタイマの値をどのように決定するかであ
る。しかし、パケットが失われることは殆んどないか
ら、パケット時間は経路長には関係なく全てのセッショ
ンに同一の値を使用できるように寛大に選択することが
できる。

32ノード回路網においては、１分のパケット時間が平
均経路状態における遅延を過大にすることなく最長経路
状態を取扱うのに充分な長さであろう。

4.2.3 再伝送方式 パケット時間中にEVAがEVAPEから次のパケット通報に
対する応答を受信しない場合には、EVAはパケットシー
ケンス番号をインクリメントさせることなく２回まで次
のパケット通報を再伝送する（計３回の試行）。

このようにしても事象パケット通報を受信しなければ
EVAは、EVAPEが将にクラッシュしたか、ノードがリセッ
トされたか、或はモニタを回路網に接続するHDLCリンク
が消滅したかの何れかであると推測しなければならな
い。何れにしても、EVAはある理由のためにEVAPEとの連
結性を損ったのである。回復機構は何れの場合に対して
も同一である。

EVAはVAPEとはそのセッションを閉じる。次にEVAはNT
A105からノードダウン通報或はノード削除通報を受けて
いるか否かを検査する。もし受けていれば、EVAはNTA10
5からそのノードに関するノードアップ通報を入手する
までEVAPEとの新しいセッションを開かない。もし受け
ていなければ、EVAはセッション開通通報を送ることに
よって今閉じたばかりのセッションの再開を直ちに試み
る。

以上に説明した方式は、次のパケット通報に対する応
答が得られない場合にのみ有効なのではない。通報に対
する応答が得られないためEVAがタイムアウトすれば、
同じ回復機構が適用される。

EVAは、潜在的に事象が失われたためにEVAPEとの連結
性が損われた時には、DBSをマークしなければならな
い。

もしEVA自身がクラッシュすれば、EVAはEVAPEとの全
てのセッションを、あたかも最初に行う時のように、初
期化する。それに応じてDBSをマークしなければならな
い。

4.2.4 セッションの閉鎖 先行節においては、EVAがEVAPEに到達し得なくなる、
即ちパケット時間が３回のシーケンスを終了した時、或
はEVAがNTA105からノードダウン通報またはノード削除
通報を受けた時にEVAPEとのセッションを閉じると説明
した。

EVAは、EVAPEがELMからそれ以上の応答を入手してい
ないことを表わすELMクラッシュフラグがセットされた
事象パケット通報を受けてもセッションを閉じる。EVAP
Eは、この通報を送る前にそれ自身の回復方式を実行す
る。

セッションの閉鎖は、モニタによって制御されている
回路網の区分からあるノードが削除され、且つEVAが未
だにEVAPEとの連結性を有している時には、ある通報を
送るだけである。この場合、EVAは大掃除の目的でセッ
ション閉鎖通報をEVAPEに送る。セッション閉鎖通報は
パラメタとして、受信した最後の事象パケット通報のシ
ーケンス番号を有する（第12図参照）。

5.EVAPE有限状態モデル 第15図はEVAPE状態図である。EVAPE有限状態空間は３
つの状態を有し、“閉鎖"1501が初期状態である。この
状態図は遷移状態を決定する入力通報を示す。読み易く
するために、通報がステートマシン（即ち通報待ち行
列）の何処から“入り”、何処から“出る”かは説明し
ない。また付加的な遷移状態及び動作も図には含まれて
いない。

（１） EVAPEが始動する時、EVAPEはその初期の状態で
ある“閉鎖"1501にあり、EVAからのセッション開通通報
を待っている。EVAPEはEVAに確認通報を送ることによっ
て受信を確認し、“開通”状態1502へスイッチする。

（２） “開通”状態においては、EVAPEはEVAから複数
のフィルタ要求通報を予期する。この数は上記セッショ
ン開通通報内にパラメタとして指定されている。EVAPE
は無秩序に到達し得る全ての入フィルタ要求通報を記憶
する。EVAPEはそれらをELMへ送る前に順序付ける。ある
EVAからの途中のフィルタ要求通報が失われると、EVAPE
はその到着を待つ。EVAPEは全てのフィルタ要求通報を
入手するまで、それらをELMへ転送しない（６節のEVAプ
ロトコルマシン参照）。EVAは“開通”状態1502に留ま
る。

（３） 全てのフィルタ要求通報をELMに転送した後、E
VAPEは応答の戻りを入手する。もしこれがサービス不能
通報であれば、ELMがフィルタ指令ブロック（FCB）を割
当てるためのメモリを瞬時に見出すことは殆んど不可能
であろう。従ってEVAPEはあと２回までフィルタ要求通
報を送ることを試みる。EVAPEの状態は３回目のサービ
ス不能通報を受けるまで（（５）項参照）“開通"1502
に留まる。

（４） もしEVAPEが“開通”状態1502でセッション開
通通報を受ければ、EVAへ確認通報を送ることによって
確認する。EVAPEは“開通”状態1502に留まる。

注：このセッション開通通報は多分異なるEVAから発
信されたものであろう。

（５） EVAPEが３回目のサービス不能通報を入手する
と、EVAPEは断念してEVAへ拒絶通報を送る。EVAPEはそ
の状態を“開通"1501に変化させる。

（６） （３）項と同様に、EVAPEは全てのフィルタ要
求を転送した後、ELMから応答を待機した。この時間ELM
は事象ログ通報または無事象通報の何れかで応答した。
何れの場合もEVAPEはEVAへ確認通報を送ることによって
確認し、開通相を完了する。同時にEVAPEはELMへ次の事
象通報を送ってELMからの更なる事象を要求する。EVAPE
は“次”の状態1503へスイッチする。

（７） もし“次”の状態1503においてEVAPEがELMから
事象ログ通報または無事象通報を受信すれば、EVAPEは
次の事象通報を介してELMをポーリングし続ける。EVAPE
はそのバッファが一杯である場合に限ってポーリングを
停止する。EVAPEは使用されていないバッファが生ずる
と直ちにポーリングを再開する。これはEVAPEが先に送
った事象パケット通報を肯定応答するEVAからの次のパ
ケット通報を受けると行われる。EVAPEは現状態を保
つ。

（８） EVAPEは“次”状態1503においてEVAからの次の
パケット通報を入手すると、EVAが予期するパケットシ
ーケンス番号を有し次のパケット通報で指示されている
事象パケット通報で応答する。これは再伝送でも、また
は新事象パケット通報でもあり得る。

次のパケット通報において予期されるパケットシーケ
ンス番号は、最後に送られた事象パケット通報内のパケ
ットシーケンス番号と同一であり、EVAPEはこの最後の
パケットを再伝送する。EVAPEはその現内部パケットシ
ーケンス数（初期値は１）をインクリメントさせない。

もし予期されたパケットシーケンス番号が、EVAPEが
送るべき次のパケットシーケンス番号（現パケットシー
ケンス数）に一致すれば、EVAPEはこのパケットシーケ
ンス番号を有する事象パケット通報を送る。EVAPEはそ
のパケットシーケンス数（モジュロ２）をインクリメン
トさせ、最後に送った、そして今肯定応答された事象パ
ケット通報を収容しているバッファ開放する。即ちEVAP
Eは次の事象パケット通報をアセンビルするためのメモ
リを有することになる。

もしEVAPEが次のパケット通報を入手した時に如何な
る事象をも有していなければ、EVAPEは応答しない。同
一のパケットシーケンス番号に関して問合せる３回目の
次のパケット通報を受信した後にのみEVAPEは、事象が
０であることを表わし且つ要求されたパケットシーケン
ス番号を有する事象パケット通報を送る。この方式は、
報告すべき事象が存在しない場合、EVAPEとEVAとの間で
交換される通報を最小ならしめる。EVAは３回の試行後
に（EVAPEに到達し得ないものとして）そのセッション
をリセットするので、EVAPEは３回目には応答しなけれ
ばならない。

（９） EVAPEが“次”状態にある時にセッション開通
通報を受信すると、確認通報を送ることによって応答し
てその状態を“開通”に変える。このセッション開通通
報は多分、EVAPEが今まで対話していたEVAとは異なるモ
ニタ上のEVAから発信されたものであろう。これは、シ
ステムを完全に遮断することなくモニタのプラグが抜か
れた時に発生し得る。別のモニタ（或は同一モニタでさ
えも）が再び接続された時、このノードが切離されてい
ない限りEVAPEは未だ走っている。従ってEVAPEは“次”
状態1503においてセッション開通通報を受入れなければ
ならない。

（10） EVAPEは“開通”状態1502または“次”状態150
3においてセッション閉鎖通報を入手するかも知れず、
これによって状態は“閉鎖"1501へ変化させられるEVAPE
が走っているノードは、モニタが管理する回路網区分か
ら削除されたのである。従ってEVAはEVAPEとのそのセッ
ションを閉じる。

注：これはEVAPEが最早ELMをポーリングしないこと、
及びそのバッファを解放することを意味する。従ってEV
APEは如何なるCPUまたはRAMも使用せず、そのノードは
最早モニタに管理されることはない。同じ結果は、EVAP
Eに長いタイマを持たせることによっても達成される。
このタイマが終了する時までにEVAPEがEVAから入手する
ものが無ければ、そのノードが区分から除かれたものと
してセッションを閉じる。EVAPEは前述のような大掃除
を行う。

（11） EVAPEは次の事象通報に対するELMからの応答を
入手しない場合には、更に２回まで再試行する。それで
も何も戻って来なければ、ELMには最早到達し得ない
（即ちクラッシュした）ものと見做す。そこでEVAPEはE
LMクラッシュフラグをセットした事象パケット通報によ
って次のパケット通報に応答してEVAに通告する。

（12） EVAPEが“次”状態においてELMからサービス不
能通報を受ければ、これはELMがFCBを失った（多分クラ
ッシュ後）ことを意味する。従ってEVAPEは次の事象通
報を介してELMをポーリングを停止し、ELMクラッシュフ
ラグをセットした事象パケット通報で次のパケット通報
に応答する。EVAPEは次の状態を“閉鎖"1501に変える。

（13） EVEPEはリセットされたばかりであり、その初
期“閉鎖”状態1501にあるEVAPEが次のパケット通報を
入手する時、EVAは未だにこのリセットを告知されてい
ない。従ってEVAPEは拒絶通報を送ってそれを告げる。

注:EVAPEは、“閉鎖"1501にある時には、次のパケッ
ト通報を完全に無視することもできる。３回目の次のパ
ケット通報に応答しなければEVAは何とかしてセッショ
ンを再開しよう。しかし拒絶通報はこれを直ちに実行さ
せる。

以下の諸通報は以下の諸状態においては無視すること
ができ（即ち、EVAPEは動作を起さず、それらをドロッ
プする）、従って状態図ではそれぞれの場所に示してな
い。

ａ） “閉鎖"1501においては ＊ ELMからの事象ログ通報（EVAPEのクラッシュ後にの
み可能） ＊ ELMからの無事象通報（EVAPEのクラッシュ後のみ可
能） ＊ ELMからのサービス不能通報（ELMのクラッシュ後に
可能） ＊ EVAからのフィルタ要求通報（異なるEVA/モニタか
らのみ到来可能） ｂ） “開通"1502においては ＊ EVAからの次のパケット通報（異なるEVA/モニタか
らのみ到来可能） ｃ） “次"1503においては ＊ フィルタ要求通報（異なるEVA/モニタからのみ到来
可能）。

6.EVA有限状態モデル 第14図はEVAプロトコルステートマシンを示す。実際
にはEVAは多重有限ステートマシンであり、これらのノ
ード上の全EVATEとのセッションを保持しなければなら
ないので、モニタによって管理される全てのノードのた
めの１つのオートマトンとなり得る。図にはこれらのス
テートマシンの中の特定のEVA-EVAPEセッションを表わ
す１つのみを示してある。有限状態空間は３つの状態を
有し、“閉鎖”が初期状態である。入力通報はEVAPEま
たはNTA105の何れかから到来する。出力通報は全て、そ
れぞれの遷移に対する動作としてEVAPEへ送られる。

（１） 特定のセッションはその初期“閉鎖”状態1401
にある。EVAはNTA105からこのセッションの発生に関連
するノードを告げるノードアップ通報を受ける。EVAは
そのノード上を走るEVAPEのためにセッション制御ブロ
ックSCBを割当て、セッション開通通報を送ってそのEVA
PEとのセッションを開く。EVAはセッションの状態を
“開通"1402に変える。

（２） EVAは１つのEVAPEとのセッションを閉じたばか
りであり、そのセッションに対して“閉鎖”状態1401に
ある。もしそのEVAPEが走っていのノードが未だにアッ
プであれば（例えば閉鎖の理由がELMに到達し得なかっ
た）、EVAはオープンセッション通報を送ることによっ
てセッションを再開し、セッションを再び“開通”状態
1402に置く。

（３） EVA-EVAPEセッションは“開通”状態1402に
る。EVAはセッション開通通報の受信を確認するためにE
VAPEからの確認通報を待つ。確認通報を入手すると、EV
Aはセッション開通通報内に指定されているフィルタ要
求通報の番号をEVAPEに送る（（７）項も参照）。

（４） 最後のフィルタ要求通報を送った後、EVAは全
てのフィルタ要求通報が到着したことを表わす確認通
報、または拒絶通報がEVAPEから送られて来るのを待機
する（（８）項及び（５）項をそれぞれ参照のこと）。

EVAがタイムアウト終了までに確認通報を受信しなけ
れば、EVAは１或はそれ以上のフィルタ要求通報が失わ
れたものと見做す。従って、EVAは更に２回までフィル
タ要求通報を再伝送する（（６）項も参照）。

（５） EVAは“開通”状態1402においてEVAPEから拒絶
通報を入手する。これは、供給されたフィルタ要求に対
してELMが否定的に応答したことを意味する（EVAPE状態
図（５）参照）。EVAはセッションの状態を“閉鎖"1401
へ変化させることによってセッションを閉じる。

（６） もしEVAが、そのフィルタ要求通報を確認する
応答を待機するシーケンス中に３回タイムアウトすれ
ば、EVAはそのセッションに関して“閉鎖”状態1401へ
スイッチする。

（７） もしEVAが、そのタイムアウトパケット時間の
前に確認通報を受信しなければ、このセッションの状態
を“閉鎖"1401に変え、そこから回復する。

（８） EVAが結局、到達した全てのフィルタ要求通報
への応答としてEVAPEから確認通報を受信したフィルタO
Kの場合には、EVAは予期されるパケットシーケンス番号
１を有する事象パケット通報を要求する最初の次のパケ
ット通報をEVAPEへ送る。これがパケット転送相を開か
せる。EVAはセッションを“次”状態1403に置く。

（９） “次”状態1403においてEVAが予期されるパケ
ットシーケンス番号を有する事象パケット通報を受信す
ると、EVAはその内部パケットシーケンス数をイクリメ
ントさせ（モジュロ２）、パケットシーケンス数に等し
いパケットシーケンス番号を有する別の次のパケット通
報を送ることによって後続する事象パケット通報をEVAP
Eに請求する。EVAはそのタイマパケット時間をリセット
し、“次”状態1403に留まる。

（10） EVAが事象パケット通報を待機中にタイムアウ
トすると、そのパケットが失われたものと見做してそれ
を再伝送するように請求する。EVAはタイマをリセット
し、現状態を保つ。EVAはパケットシーケンス数をイン
クリメントさせない（（14）項も参照）。

事象パケット通報は失われていないが極度に遅れた時
にはEVAタイマが終了する恐れがあるかも知れない。こ
れらの場合には、前述の再伝送が２回行われたことにな
る。従ってEVAは、既に受信されたあるパケットシーケ
ンス番号を有する事象パケット通報を破棄する。

（11） EVAは“開通”状態1402または“次”状態1403
においてNTAらノードダウン通報（EVAPEが走っているノ
ードのための）を受信する。EVAはその現状態を“閉鎖"
1401とすることによってセッションを閉じる。

（12） EVAは、あるノードがモニタによって管理され
ている回路網から外されるとNTA105からノード削除通報
（EVAPEが走るノードのための）を入手する。従ってEVA
はセッション閉鎖通報をEVAPEへ送ることによって大掃
除を行う。EVAはその状態を“閉鎖"1401に変える。

（13） もしELMクラッシュフラグがセットされていな
い事象パケット通報をEVAが受ければ、EVAは“閉鎖”状
態1401へスイッチすることによってEVAPEとのセッショ
ンを閉じる。EVAPEは事象パケット通報を送って“閉
鎖”状態1501へ状態を変化させる。

（14） もし、EVAが事象パケット通報を待機している
シーケンス中にタイマパケット時間が３回終了すれば、
EVAはその状態を“閉鎖"1401に変えることによってEVAP
Eとのセッションを内部的に閉じる。

タイマを３回終了せしめた極度に遅れた事象パケット
通報は、EVAが“閉鎖”状態1401にあることによって廃
棄される。

（15） EVAPEはEVAに事象パケット通報を送った後にリ
セットされている。EVAは事象パケット通報を受信する
と、次のパケット通報を介して更なるパケットを要求す
る。EVAPEは、リセット後“閉鎖”状態1501にあるか
ら、この要求に対して拒絶通報によって応答する。拒絶
通報を受信するとEVAは（も）“閉鎖”状態1401へ移
る。

以下に挙げる通報は、セッションの状態に依存してEV
Aによってドロップされ得る。

1.“閉鎖"1401においては ＊ NTA105からのノードダウン通報（無動作、セッショ
ンは既に閉じている） ＊ NTA105からのノード削除通報（無動作、セッション
は既に閉じている） ＊ EVAPEからの事象パケット通報（EVAクラッシュ或は
閉じたばかりのセッションからの遅れたパケット後にの
み可能） ＊ EVAPEからの拒絶通報（EVAクラッシュ後にのみ可
能） ＊ EVAPEからの確認通報（多分EVAは開通相においてク
ラッシュしている） 2.“開通"1402においては ＊ NTA105からのノードアップ通報（セッションは既に
開かれているのであるから起りそうにないが、害を与え
ることはないであろう） ＊ EVAPEからの事象パケット通報（不可能） 3.“次"1403においては ＊ NTA105からのノードアップ通報（セッションは既に
開かれているのであるから起りそうにないが、害を与え
ることはないであろう） ＊ EVAPEからの確認通報（不可能） 7.EVA-DBS EVAは、EVAPEから受信する全ての事象をモニタデータ
ベースDBS内に記録するために、関数呼出しによってDBS
とインタフェースする。

基本的にはEVAは、事象パケット通報の中で到来する
事象ログ記録の構造をDBS内の事象記録の構造に変換す
る。これは極めて率直なプロセスである。これは第16図
に示されている。

開始時に、EVAはノード番号をマップする表をDBSだけ
の独自のノード識別名に復帰させる関数を呼出す。１つ
のノードは幾つかの回路網用に構成できるから、そのノ
ード番号はDBSの観点からは独自ではない。独自のノー
ド識別名は、EVAによって全てのDBS事象記録内に満たさ
れなければならない。

そのノード上のEVAPEは各事象のタイムスタンプを絶
対時間（エポック時間）に変換しなければならない。こ
れは、任意の２つのノードの時間基準が潜在的に異なる
ために必要なのである。従ってモニタ上では２つの異な
るノードからの２つの事象タイムスタンプを絶対時間に
変換しなければ比較することができない。

事象が有するトークンは、問合せ或は報告の目的のた
めに意味ある情報に変換される。これは、EVA内の関数
呼出しを介して、或は事象をモニタDBS内へ記憶する前
にまたは検索時に別のプロセスによって、行うことがで
きる。

事象文章列はDBS内に記憶する時に大量のディスク空
間を占めるので、多分この変換は事象を検索する時に行
うべきであろう。SQLステートメントを受入れ、それら
をDBSへ転送し、そして生の事象情報を利用者に対して
表示する前に復帰される該情報に変換関数を走らせるア
プリケーションプロセスは、利用者によって呼出すこと
ができる。

DBS内へ挿入される１つのノードからの事象のシーケ
ンス内の折返しは切れ目の記録であり、これは基本的に
は“事象ログ切れ目”の事象型フィールドを有し且つノ
ード識別名及びタイムスタンプのためのフィールドが満
たされている正常な事象記録である。

同様にして、ノードのELMへの連結性の欠如は、事象
の潜在的な損失としてデータベース内へ挿入される。連
結性が失われている時間中は事象が失われたか否かは不
確実であるので、“未知状態”のような異なる事象の型
が使用されよう。

VII.警報表アプリケーション 1.序節 警報表アプリケーションATAの目的は、回路網内の活
警報を収集し、分配することである。

ATAは、IDNX事象ログ管理者ELMタスクによって創成さ
れ管理されているIDNX警報ログから警報を収集する。警
報表APE（ATAPE）は各IDNXノード内で創成され、警報ロ
グ変化を監視し、これらの変換を問合せに応答してモニ
タATAタスクへ送る。モニタ回路網トポロジアプリケー
ションNTAは、監視しているノードの状態に関してATAに
通知する。

警報は、モニタメニュー及び図形インタフェースコン
ソールアプリケーションMAGICと、モニタ回路網警報モ
ニタNAMアプリケーションとに分配される。MAGICはこの
情報を使用して警報状態を表わすカラーダイナミックス
を回路網の成分の図形表示に割当てる。NAMは、スクロ
ール可能なサンツールズ文章サブウィンドウ内に警報情
報を表示する。ATAは警報情報をオラクルデータベース
内へは記憶しない。

この方式に対する合理的な変形が、同じようにIDNX事
象ログから事象を収集するモニタ事象アプリケーション
EVAから警報情報を受信していたことに注目されたい。
（IDNX警報ログは事象ログから誘導される。）この方法
はATAPEを排除するがEVA及び附属EVAPEに大きい負担を
負わせる。IDNXと現警報状態のモニタビューとの間の多
くの困難な同期問題を考慮してこの方法は破棄された。
同期の問題点は以下のようであった。

1.不可避の“事象ログ折返し”問題からの回復は、失わ
れた情報を回復するために警報表を収集する機構を必要
とした。

2.ATAのEVAへの依存性が、回路網のトラフィックを減少
させる目的で事象収集にフィルタを適用するEVAの自由
度を制限した。

3.ELMは、操作員によって手動でクリアされる警報を報
告するように変形しなければならなかった。

4.モニタは、“警報の抹消”を認識しなければならなか
った。これは、警報表を保持するELM論理と共に冗長で
ある。

2.外部参照仕様 第17図は、ATA170とそれが通信する他のプロセスとの
間の論理的関係、及びIDNX事象ログアプリケーションEL
M172とATAが警報を分配するアプリケーションとの間の
データ流を示す。

モニタ上でATAは、オラクルデータベース管理サービ
スDBS173、回路網トポロジアプリケーションNTA174、回
路網警報モニタNAM175、及びMAGICと名付けたメニュー
及び図形インタフェース176と通信する。回路網内に分
散しているIDNXノードにおいては、警報表ATAPE177のた
めに結合されているプロセッサエグゼキュータは、モニ
タノード上のATAとのプロトコルをサポートする。更
に、各IDNX上の対象管理者OM178はATA170及びATAPE177
からの通報によってそれぞれATAPEがを創成し、削除す
ることを要求される。

ATA/ATAPEの外部インタフェースはこの節で説明す
る。ATA及びATAPEの内部設計に関しては３節で説明す
る。

2.1 ATA及びATAPEのOMへのインタフェース IDNX対象管理者OMはIDNXタスクを創成し、削除する責
を負う。従ってOMはATAPEを創成し、削除するように要
求される。ATAは、あるIDNXノードが監視されているこ
とをNTAから通知されると、そのノード上のOMに創成通
報を送る。この通報には応答は存在せず、従ってATAは
このタスクが開始されたものと見做す。もしATAPEとの
セッション開通プロトコルに失敗すれば、ATAはAPEタス
クを再び創成することを試みる。

ATAはOMの“双対プロセッサ選択インスタンス”へ創
成通報を送るので、ATAPEはIDNX双対プロセッサ上に
（もし一方が使用可能であれば）創成されよう。この企
図は、IDNXマスタCPUに及ぼす衝撃を最小にするためで
ある。

ATAは、あるIDNXノードが最早監視されていないこと
をNTAから通知させると、そのノード上のそのATAPEを削
除する。ATAは、APEが走っているのはどのCPUであるの
かを知らないから、またATAPEを創成したOMにOM削除通
報を送らなければならないから、削除通報をOMに送るよ
うにATAPEに要求する。削除通報に対する応答は存在せ
ず、ATAPEはOMが通報を受信するまで走り続け、タスク
を強制排除して削除する。もしATAPE削除に失敗すれば
（例えば、APEへのATAの通報が失われて）、ATAはAPEを
削除することを再び試みる。

ATAPEタスクは、ATAPEが異常に終るかまたはATAPEが
走っているCPUがリセットされれば、ATAによって再創成
されよう。これは、内部参照仕様に記載されたATA-ATAP
E回復プロトコルの一部である。

IDNX回路網当り複数のモニタワークステーションは、
任意のIDNXノードに１つのモニタだけが接続されるとい
う制限を伴ってサポートされ得る。モニタAPEの設計及
び実現を簡易化するために各モニタは、監視中の各ノー
ド上にそれ自身の独自のAPEタスクの集合を創成する。
全てのIDNXタスクは、総称タスク識別名、及び独自のタ
スクインスタンスによって指定される。これらの値は番
目OM創成通報及び削除通報内に指定される。モニタAPE
インスタンスは、そのモニタが接続されているIDNXノー
ドの番目ノード番号から誘導され。これは、各APEタス
クが独自のインスタンスと共に創成され、且つ単一のモ
ニタと通信することを保証する。

2.2 ELMへのATAPEインタフェース ATAPEはELM警報ログから警報情報を収集する。ATAがA
TAPEとの“セッション”を開く場合、ATAPEはELMの警報
ログをローカル警報表内に、及びATAへ送る（１つの或
は複数の）通報内にコピーする。次でATAPEは変化（ク
リアされた、変更された、または新警報）を検出するた
めに、警報ログに対して警報ログ“要約”情報を問合せ
る。変化が検出されると、ATAPEは警報ログを再び読
み、これらの変化をその警報表及びATAの両者に通知す
る。

ATAPEは“事象ログ警報表”通報を使用してELM警報ロ
グを読む。ATAPEはこの通報をELMに送って表内に１つの
オフセットを記入し、ELMはそのオフセットから始まる
８つの警報を含む通報を返す。

ELMは警報ログに対応付けられた“要約”情報を保持
する。この要約情報は“事象ログ警報要約”通報を使用
して問合せられる。ELMは活警報の総計と合計警報とを
含む要約情報を通報内へコピーし、それを返却すること
によって応答する。ATAPEは２つの総計値と、その最後
の要約問合せから検索した合計とを比較する。もし要約
が変化していればATAPEは新しい警報表を読み、変化し
ていなければあるビットを待って再び要約を問合せる。
ATAPEは、警報ログがATAによって削除されるまで要約情
報の問合せと、警報ログのコピーの更新とを続行する。

もしATAPEがマスタCPU上に創成されれば、マスタCPU
はマスタELMタスクと通信する。もしATAPEが双対プロセ
ッサ上に創成されれば、それはシャドウELMタスクと通
信する。これら２つのタスク間のインタフェースは本質
的に同一である。

2.3 MAGICへのATAインタフェース ATAはATAPEタスクから収集した警報情報をMAGICへ分
配する。MAGICは、もし特定回路網成分が複数の警報を
トリガしていればその成分上で最も臨界的な警報だけが
通知されることを予期している。一旦警報がMAGICに報
告されると、MAGICは全ての警報のクリアを含むその成
分上の警報状態の何等かの変化を通知されるものと予期
している。新しい回路網成分が存在することをDBAプロ
セスによって通知されると、MAGICはその成分上の警報
情報に関してATAに問合せる。

警報情報がATAPEタスクから収集されるとATAはこの情
報を若干数の“GIステータス通報”でMAGICへ分配す
る。この通報は、回路網成分のデバイス識別名をアスキ
ー書式（例えばＮ_xxＣ_yy.zz）で、及びその現警報状態
を含む。複数のデバイス識別名／警報記録は、余地があ
る限り（“最大SCLP通報サイズ”まで）単一の通報内に
配置される。MAGICに報告される警報レベル値は以下の
通りである。

1. クリアされた警報 2. 情報警報 3. それ程重大ではない警報 4. 重大な警報 5. 臨界的警報。

ATAがMAGICに警報を報告するまで、MAGICは回路網内
には警報が存在しないものと見做し、従って回路網の初
期警報状態は“クリアされた”警報状態である。ATAプ
ログラムは、（再）始動すると、MAGICが全ての警報状
態を“クリアされた”警報状態に初期化するのを保証す
るMAGICアプリケーション（もしMAGICが走っていれば）
とのハンドシェークを遂行する。これによってプログラ
ムは全ての回路網デバイスの警報状態のビューを再同期
させる。ハンドシェークは、デバイス識別名が“全部”
にセットされ且つ警報レベルが“クリアされた警報”に
セットされたATAからの“GIステータス通報”と、それ
に続く全ての警報用回路網成分の現警報状態を送るよう
にATAに要求するMAGICからの“GI全部再送通報”とから
なる。ATAがATAPEから警報を収集すると、この情報はMA
GICへ送られる。

MAGICは（再）始動すると、ATAに“GI再送明細通報”
を送って全ての警報用回路網成分の現警報状態を要求す
る。

MAGICは“GI再送明細通報”を用いてATAからの特定警
報情報を問合せる。この通報は、MAGICが現警報状態を
欲している回路網成分デバイス識別名のリストを含む。
ATAは若干数の“GIステータス通報”で応答する。

ATAはMAGICアプリケーションからの“GI再送明細通
報”を検査する。もし通報内の何れかの情報が検出でき
る程劣化すれば、ATAは誤り通報をモニタシステム通報
ウィンドウへ記録する。

ATAはIDNXダイグループとポートデバイスとの間を弁
別する責を負う。ELMから収集された警報記録はこの区
別を行わない。ATAは、もし警報がポート警報であれ
ば、デバイス識別名を形Ｎ_xxＣ_yyＰ_zzに変更する。もし
警報がダイグループ警報であれば、形Ｎ_xxＣ_yy.zzが使
用される。

2.4 NAMへのATAインタフェース ATAはATAPEタスクから収集した警報情報をNAMに分配
する。NAMは全ての活警報、全ての変更された活警報
（例えば警報が再トリガされた時、数フィールドのよう
なある警報記録情報が変更される）、及び全てのクリア
された活警報を通知されることを予期する。NAMは、ATA
PEタスクから受けた警報内に含まれる殆んどの情報をサ
ンツールズ文章サブウィンドウ内に表示する。

警報情報はATAPEタスクから収集され、ATAはこの情報
を若干数の“NAM更新通報”でNAMへ分配する。この通報
は、ELM警報ログから検索された警報記録構造、及び警
報に対して遂行する関数を含む。複数の警報記録／関数
集合は余地がある限り（“最大SCLP通報の大きさ”）単
一の通報内に配置される。NAMへ渡される関数は以下の
通りである。

NAM付加 文章サブウィンドウへ警報を付加 NAM変更 文章サブウィンドウ内に既に表示されて
いる警報を変更 NAM削除 文章サブウィンドウから警報を削除。

ATAが警報をNAMへ報告するまで、NAMは回路網内には
警報が存在しないものと見做し、従って回路網の初期警
報状態は“無”警報状態である。ATAプログラムは、
（再）始動すると、NAMが文章サブウィンドウ内に現在
表示されている全ての警報をクリアするのを保証するNA
Mアプリケーション（もしNAMが走っていれば）とのハン
ドシェークを遂行する。これによって、プログラムは回
路網の警報状態のビューを再同期させる。ハンドシェー
クは、ATAからの“ATAリセット通報”と、それに続くAT
Aが収集した全ての現在活動中の警報を送るようにATAに
要求するNAMからの“NAMリセット通報”とからなる。AT
AがATAPEから警報を収集すると、この情報はNAMに送ら
れる。

NAMは、（再）始動すると、ATAに“NAMリセット通
報”を送ってATAが収集した全ての現在活動中の警報を
要求する。

ATAはIDNXダイグループとポートデバイスとの間を弁
別する責を負う。ELMから収集された警報記録はこの区
別を行わない。ATAは、もし警報がダイグループ警報で
あれば、ELM回路網アドレスフィールドのビット30をセ
ットすることによって警報記録構造内のデバイス識別名
を変更する。

ATAは、あるノードがモニタ域から削除された時、NAM
に通知する責を負う。これは、削除されたノードの番号
を含む“NAMノード削除通報”をNAMに送ることによって
行われる。

2.5 NTAへのATAインタフェース モニタ回路網トポロジアプリケーション（NTA）は、
モニタにより監視されているIDNXノードのステータスが
変化した時それをATAに通知する。これは、あるノード
が回路網に付加されたこと、あるノードが回路網から削
除されたこと、及び回路網内のあるノードへの連結性の
欠如または取得を含む。

ATAは、（再）始動すると、NTAに（もしそれがアップ
であれば）“ATAリセット通報”を送る。NTAは“NTA回
路網内ノード通報”で応答し、モニタが結合されている
IDNXノード（“隣のノード”と呼ぶ）のノード番号、及
びモニタとの連結性を有し現在監視されているノードの
リストをATAに通知する。ATAは、このリスト内に含まれ
る各ノード上にATAPEタスクを創成する。

ATAがNTAとのハンドシェークを（再）始動した後、NT
Aは回路網内の何れかのノードのステータスの変化を３
つの通報の中の１つを用いてATAに通知する。各通報は
単一のノード番号を指定する。これらの通報を以下に示
す。

NATノードアップ通報 新ノードがモニタ域に付加
された場合、または“ダウンした”ノードとの連結性が
再び取得された場合、 NATノードダウン通報 ノードがダウンした、即ち
そのノードとの連結性が破れた場合、 NATノード削除通報 ノードがモニタ域から削除さ
れた場合。

ATAはこの情報を使用して、どのノードにATAPEタスク
を創成するか、及びATAが現在セッションを有しているA
TAPEタスクと通信を試みる何等かの目的が存在するか否
かを決定する。ノードダウン通報を受信するとATAは、
そのノード上のATAPEとのセッションを中断する。ノー
ドアップ通報を受信するとATAは、新しいATAPEを創成し
てそれとのセッションを確立するか、または中断されて
いた既に活動しているセッションを再開する。ノード削
除通報を受信するとATAは、そのノード上のATAPEを削除
する。

NTAは、隣のノードへのHDLCリンクが使用不能になっ
たこと、或は爾後に使用可能になったことをATAに通知
する。HDLCリンクが使用不能になると、NTAは“NTA・HD
CLリンクダウン”通報を送り、ATAはそのATAPEとの全て
のセッションを中断する。

HDLCリンクが再び使用可能になると、NTAは“NTA・HD
LCリンクアップ“通報を送る。この通報は“NTA回路網
内ノード通報”と同一の書式を有している。もし隣のノ
ード番号が変化しなければ、ATAは、その通報内にリス
トされているノード上のATAPEタスクとのセッションを
再開する。もし隣のノード番号が変化すればATAは、創
成した全てのATAPEタスクを削除し、新しい隣のノード
番号から誘導した新タスクインスタンス番号を用いて、
通報内にリストされているノード上にATAPEタスクを再
創成する。

NTAアプリケーションは、（再）始動すると、“NTA回
路網内ノード通報”と同一の書式を有する“NTAリセッ
ト通報”をATAに送る。もし隣のノード番号が変化しな
ければATAは、先に警報が収集されなかった何れかのノ
ード上のATAPEタスクとのセッションを再開する。もし
隣のノード番号が変化すればATAは、創成した全てのATA
PEタスクを削除し、新しい隣のノード番号から誘導した
新タスクインスタンス番号を用いて通報内にリストされ
ているノード上にATAPEタスクを再創成する。

またATAは、“NTAリセット通報”を受信すると、現在
モニタ域内に限定されているIDNXノードのノード番号を
含むオラクルデータベース内のノード表を読み出す。こ
れは、NTAアプリケーションが不活動であった間にどの
ノードも域から削除されなかったことを確認するために
行われるのである。もしATAがオラクルノード表内に存
在しない何れかのノード上のATAPEとのセッションを有
していれば、そのATAPEは削除される。

ATAはNTAアプリケーションから受信した全ての通報を
検査する。もし通報内の何れかの情報が検出できる程劣
化していれば、ATAは核関数報告“不良通報（ ）”を
使用して送信者にその通報を返却する。またATAはNTAに
“ATAリセット通報”を送って情報の潜在的損失から回
復しようと試みる。また誤り通報をモニタシステム通報
ウィンドウへ送る。

2.6 データベースインタフェース オラクルデータベースは、“NTAリセット通報”を受
信した時、ノード表からノード番号を検索するために使
用される。SQL問合せの書式は： “SELECT NODE.NODENMBR FROM NODE,NET NODE WHERE NE
T NODE.NODEID＝NODE.NODEID" である。

3.内部設計仕様 警報表アプリケーションには２つの論理成分が存在す
る。第１（モニタ内に在留）はATAである。第２は、モ
ニタ回路網内の各IDNXノード内に在留するATAPEであ
る。

ATAは、警報をMAGICとNAMとの分配する。ATAPEは、ID
NX事象ログ管理者ELMから警報表情報を収集し、それをA
TAへ送る。

3.1 ATAPEへのATAインタフェース ATAは、（再）始動すると、モニタ域内に限定されて
いる各IDNXノード上のATAPEタスクとのセッションを創
成して開始し、それらの警報表を検索する。次で、セッ
ション接続誤りがなければ、ATAPEは周期的ステータス
通報（遊休或は警報変化）をATAへ送る。

ATAとATAPEとの間で交換される通報の書式は付録。Ａ
に定義されている。

3.1.1 セッション初期化 もしATAがある時点に１以上のATAPEを創成すれば（例
えば“NAT回路網内ノード通報”を介して複数の新ノー
ド番号が送られて来れば）、ATAは短い累積遅延によっ
て各ATAPEセッションを時差開通させる。これは個々のA
TAPEセッション活動をずらせるために使用される唯一の
機構である。セッションは、第18図に示す交換を使用し
て開かれる。

“ATA開通通報”通報を受信するとATAPEはELM警報ロ
グをローカル警報表内にコピーし、若干数の“ATA警報
通報”通報をATAのために構成する。これらの通報は、
“ATA次の通報”に応答して一時に１警報通報ずつATAに
送られる。各警報通報は可能な限り多くの（“最大SCLP
通報サイズ”まで）警報記録を含む。警報通報は、通報
の受信を肯定応答する“ATA次の通報”がATAによって受
信されるまでATAPEによって緩衝される。通報番号（モ
ジュロ256）はATAPEからの“ATA警報通報”の肯定或は
否安応答に使用される。ATAから否定応答を受信する
と、ATAPEは最後の“ATA警報通報”を再伝送する。

このセッション初期化交換における最後の“ATA次の
通報”は警報表ステータス通報に関する未決要求として
使用される。これに関しては次節において説明する。

ATAPEは、警報記録タイムスタンプをIDNXの内部時間
書式からエポックSSE書式以来のモニタの秒に変換する
責を負う。IDNXは、モニタNTAアプリケーションによっ
て間接的に初期化されるSSEクロックを維持する。

3.1.2 正常セッション手順 正常セッションプロトコルは、最小回路網トラフィッ
クとIDNXノードからの警報のタイムリな収集との間の平
衡を達成するように設計されている。これは第19図に示
されている。

正常シナリオは、“ATA次の通報”を受信した後、且
つ送るべき警報表変化が存在しなければ、ATAPEに遊休
タイマを始動させるように要求する。タイマが終了し、
且つ警報表無変化が累積していれば、ATAPEは“ATA遊休
通報”をATAへ送る。これは無番号通報であり、ATAから
の応答を要求していない。これは単にATAPEが未だに応
答することをATAに通知するだけである。（ATAはATAPE
との通信が中断されたような場合から回復するための非
活動タイマを維持する。これに関しては次節で説明す
る。） ATAPEの遊休タイマがデクレメントされている間、ATA
PEは規則的な間隔でELMの警報ログの変化を検査し続け
る。変化が検出されると、これらの変化はAPEのローカ
ル警報表内へコピーされ、次でこれらの変化をATAへ伝
えるために“ATA警報通報”が構成される。ATAPEは可能
な限り多くの（“最大SCLP通報”内に収める。“ATA警
報通報”に対するATAからの応答は、通報シーケンス数
が１だけインクリメントされた“ATA次の通報”であ
る。

セッション初期化中に、始めに警報ログがATAへ送ら
れていれば、変化（新しい警報、変更された警報、及び
クリアされた警報）だけがATAに伝えられる。ATAPEはそ
の警報表内に、次の“ATA警報通報”の集合を構成する
時にどの警報記録をATAへ送る必要があるかを表わす内
部アカウンティングを維持する。

“ATA警報通報”の書式は、活警報記録が“ATA警報エ
ントリ”構造定義を使用して送られることを規定する。
クリアされた警報は圧縮された形で送られる。ATAはそ
れ自身、ELM警報ログの内部コピーを維持しているか
ら、これはどの警報ログ記録がクリアされたかを送るに
等しい。クリアされた警報記録の内容は送られない。

ATAPEとELMとのインタフェースと、ATAPEとATAとのイ
ンタフェース間の同期は、ELMの警報ログの任意のコピ
ーが一貫しないかも知れない現実的な可能性が存在する
事実を感知可能である。これは、ATAPEが警報ログを読
み出している間にELMがそれを更新できることに起因す
る（表全部を読み出すためにはELMと数回の交換が必要
である）。依って、ATAPEは、警報ログの読み出しを開
始した時点から警報ログの読み出しを終了する時点まで
警報要約が変化しなかったことを確認する。もし警報要
約情報が変化していれば、ATAPEは再び警報ログを読み
出し、警報ログが安定するまでそれを続行する。ATAへ
応答を送る前のATAPEによる警報の再読み出しの回数に
は限度がある（ATAとのそのインタフェースのタイムア
ウト、或はATAへの警報更新の不必要な遅延を回避する
ため）。この限度に達すると、ATAPEは警報ログが未だ
に流動状態にあるかも知れなくとも、それが一貫してい
る（例えば“重複した”警報記録は存在しない。重複警
報は、警報記録がより臨界的な警報によって強制排除さ
れ、次でATAPEが警報ログを読み出している間に表内へ
再挿入される場合に発生する）ものと確認する。

3.1.3 セッションの誤り回復及びセッション終了 3.1.3.1 失われた通報の回復 ATAは幹線のダウン、異常な回路網の遅延、或はIDNX
及びノードの障害によって失われた通報を回復する責を
負う。この目的のために、ATAはATAPEへ通報を送る時に
は非活動タイマを始動させる。このタイマは、この型の
回復はまれであると考えられることから、比較的長い終
了期間を有している。タイマが終了すると、ATAはその
最後の通報を再伝送し、その非活動タイマを再始動させ
る。ATAは、セッションが回復不能であると結論付ける
前に３回回復を試みる。

回復の試みに失敗するとATAはATAPEにそれ自体を削除
することを通知し、ATAPEタスクを再創成してATAPEとの
セッションを再開する。この手順は、ATAPEが応答する
まで、またはNTAがATAにそのノードがダウンしたこと或
はそのノードがモニタ回路網から削除されたことを通知
するまで繰り返される。

3.1.3.2 アプリケーションのリセット ATAは再始動すると、ATAPEタスクとのセッションを創
成して開通させる。もしATAの先行動作によって既にATA
PEが存在していれば、ATAPEはATAとのそのセッションを
再初期化し、その警報表の全コピーをATAへ送る。

もしATAPEタスクが異常に終了しOMによって再始動さ
れれば、新ATAPEは先ずATAからの“ATA開通通報”以外
の通報を受信することが可能である。この場合ATAPEは
“ATAリセット通報”をATAへ送る。これによりATAは“A
TA開通通報”応答を用いてセッションを再初期化する。
ATAは新警報表をATAPEから受信すると、その表を表の内
部（古い）コピーと記録毎に比較する。差が注目されMA
GIC及びNAMアプリケーションへ適切に送られる。この交
換を第20図に示す。

ATAPEは、ATAとのそのインタフェース上に極めて長い
非活動タイマを維持する。タイマは正常な幹線が機能不
全中のATA-ATAPEセッションを維持するために充分に長
くしてある。このタイマの目的は、もし適当に長い間隔
の後にATAに語るべきものが存在しなければATAPEタスク
が自身を削除することである。これは、ATAからATAPEへ
の“ATA削除通報”が回路網によってドロップされる可
能性を提供する。またこれは、モニタを回路網から長期
間に亘って切離す（例えば利用者が週末にモニタの使用
を止める）ことも可能ならしめる。

またATAPEはELMとそのインタフェース上にも非活動タ
イマを維持する。もしELMが要約情報に関する問合せに
応答しなければ、この問合せはある回数再送される。こ
れは、シャドウELMがマスタELMとの初期化を完了する前
にATAPEが要約情報を要求するかも知れないために行わ
れるのである。ATAPEが警報ログを読み出し中にもしELM
が応答しなければ、ATAPEタスクはそれ自身を異常に終
了させる。ATAは前節で説明したようにATAPEを再始動さ
せよう。

3.1.3.3 セッションの終了 ATAは、NTAから“NTAノード削除通報”を受信するとA
TAPEを削除する。ATAは“ATA削除通報をATAPEへ送る。A
TAPEはそれが走っているCPU上のOMへ“タスク削除”通
報を送り、正常セッション処理を続行する。それによっ
てOMはタスクを強制排除して削除する。

3.2 ATAプログラム内部 本節は、先行節において説明した機能性を遂行するた
めにATAにおいて創成される主要データ構造及び方法を
説明する。ATAプログラムは、モニタ環境において供給
されるのと同様に、IDNX状核層上を走るように書かれ
た。アプリケーションによって要求される全てのシステ
ムレベルサービスはこの核層を通して入手される。プロ
グラム内に埋め込まれたスタティックメモリは存在せ
ず、全てのデータ空間は核層への“メモリ要求（ ）”
を介して入手される。

3.2.1 ATA主要データ構造 データ構造は付録Ｂに定義されている。

ATAアプリケーション内の主要データ構造は、大域デ
ータ領域、ノード表（NT）、セッション制御表（SCT）
及びその付属セッション制御ブロック（SCB）、及び回
路網警報表（NAT）である。

3.2.1.1 大域データ領域 大域データ構造は、本アプリケーションのための主デ
ータ構造である。このデータ構造は、アプリケーション
スタックスペース上に割当てられたローカルルーチンデ
ータ変数用を除き、本アプリケーションによって管理さ
れている全ての他のデータを指し示す（直接的に及び間
接的に）ポインタを含む。

タイマブロックポインタ（タイマポインタ）は、ATA
アプリケーションのために維持されている核レベルタイ
マを指し示す。このタイマはATAPEセッション活動を管
理するために使用される。対応付けられたタイマ変数
（セッションタイマ）も大域データ領域内に定義されて
いる。該タイマは本アプリケーションが開始された時に
始動し、本アプリケーションの寿命中の規則的な間隔の
省略時によって終了する。タイマがリセットされる度
に、それがオフとなる時間がセッションタイマ変数内に
記憶される。このタイマの使用の説明は、ATAPEセッシ
ョン制御ブロックの説明まで据置く。

大域データ領域内の他の変数は、セッションタイマ
値、ATAPEセッションに対して遂行される再試行の数、N
AM及びMAGICアプリケーションの状態、及びモニタ及び
その隣接ノードのノード番号のような、本アプリケーシ
ョンが必要とする情報のためのものであり、また本アプ
リケーションの作用域内の大域である。

プログラムは、アプリケーションが活動でない時にそ
れらに通報を送ることを試みることによってもたらされ
る誤りを回避するために、警報を分配するアプリケーシ
ョンの状態を追跡し続ける。ATAは（再）始動すると
“核タスク発見（ ）”サービスを使用してNAM及びMAG
ICの状態を決定する。もしタスクがアップであれば始動
時ハンドシェークが遂行され、論理（NAMアップまたはM
AGICアップ）が“真”にセットされる。戻りハンドシェ
ークを受信するとATAは、核に“通知送れ通報”を送る
ことによって、アプリケーションが終了したか否かを通
知するように核に要求する。核はアプリケーションが終
了するとこの通報を返却する。MAGIC及びNAMアプリケー
ションへ警報情報へ送る前にATAは、大域データ領域内
のそれぞれの状態論かを調べる。

3.2.1.2 ノード表 ノード表（NT）は主として、索引を有するIDNXノード
番号をセッション制御表内へ対応付ける。これは、特定
のATAPEタスクを有するセッションを管理するために適
切なセッション制御ブロックを検索するのに使用され
る。

ノード表は各ノードの状態も記憶するが、これは部分
的に実行されるだけであり、プログラムの機能性内の雑
部分にしか役立たない。

3.2.1.3 セッション制御表及びセッション制御ブロッ
ク セッション制御表はセッション制御ブロックの固定長
アレイである。セッション制御ブロックは特定のATAPE
セッションのための制御用データ構造である。

ATAPEセッションは状態駆動され、SCB変数“セッショ
ン状態”はあるATAPEの現状態を定義する。NTAから“ノ
ードダウン”通報を受信したことによってATAがATAPEセ
ッションを中断すると、現状態はSCB変数（セッション
ペンディング状態）内にバックアップされ、“セッショ
ン状態”がセットされて中断したセッション状態を指示
する。発生し得るセッション状態は以下の通りである。

“空白セッション” ATAPEタスクが削除され、短時
間後に再創成すべき場合に誤り回復中に使用される状
態、 “休眠セッション” ATAPEタスクの創成とセッショ
ン初期化との間の状態、 “開通時セッション” ATAが“開通通報”に応答してA
TAPEを待機中の状態、 “活セッション” ATAが警報通報及び遊休通報をA
TAPEから受信を予期している状態、 “中断セッション” セッションが中断され、ATAPE
のノードへの再連結性がペンディングである状態。

セッションを制御するために使用されるSCB内には、A
TAPEが存在しているノードの番号、誤り回復に使用され
る再試行カウンタ、及び順番が乱れた通報を検出するた
めに使用される現セッション通報カウンタのような、多
くの変数が存在する。

SCBタイマ変数は、ATAがATAPEセッションを管理中に
遂行する種々のセッション始動及び誤り回復活動を駆動
するために使用される。特定の活動（“ATA開通通報”
の送出のような）が発生するようにスケジュールされる
と、ATAはSCBタイマ変数をセットする。次でATAは、セ
ッションタイマが終了することになっている時点を決定
するために大域データ領域内の総合セッションタイマを
検査する。もしATAPEのタイムアウト値前にセッション
タイマが終了する予定であれば、ATAは何もしない。ATA
PEのタイムアウト値後にタイマが終了する予定であれ
ば、ATAはより早い時点に終了するようにセッションタ
イマをリセットする。大域セッションタイマが終了する
と、ATAは各ATAPEタイマ値を走査してどのATAPEセッシ
ョンがある活動の遂行を要求しているかを決定する。

ATAPEタイマからの入警報通報と、MAGICタスク及びNA
Mタスクへの出警報通報を緩衝するために、SCB内には３
つのリンクされたリストが定義されている。ATAは、警
報情報がMAGIC及びNAMに分配される前に、警報表のスナ
ップショット全体を処理しなければならない。そのよう
にしない場合の危険性は、ELMがその警報ログを管理す
るために使用するアーキテクチャ及びアルゴリズムに関
係付けられる。このような態様による緩衝を行わないた
めに生ずる徴候は、NAM及びMAGICの両者へ冗長で誤った
警報情報がもたらされることを含む。

SCB変数“警報表長”は、IDNX回路網にまたがって可
変の大きさの警報表を収容するために使用される。警報
ログは固定の大きさを有しているが、より大きく複雑な
回路網の要求に合致させるために、警報ログのサイズが
増大することが予測される。これが行われると、異なる
マシン上のATAPEタスクのために異なる大きさの警報ロ
グを監視することが可能であろう。従ってATAPEはセッ
ション初期化中に“ATA開通通報”ハンドシェークの一
部として警報ログのサイズをATAへ報告する。このサイ
ズは、警報ログのATAのコピー（NAT、これに関しては以
下に説明する）の長さ、及びATAが警報ログの単一のス
ナップショットで（SCB変数“最大警報通報”）ATAPEか
ら受信することを予期する警報通報の最大数を決定す
る。

任意ATAPEのための回路網警報表はSCB変数“NATポイ
ンタ”によて指し示される。この表は次節で説明する。

3.2.1.4 回路網警報表 回路網警報表（NAT）は、ELM警報ログ内に維持されて
いる関連警報情報の像を含む。ATAPE当り１つのNATが存
在する。

表内の各記録は，活動対非活動警報及びELMの警報ロ
グの最初の像をATAPEから受信したか否かを弁別するた
めに使用される状態変数、警報のレベル（非活動警報、
或は活警報の臨界度）、“ATA警報エントリ”書式の警
報記録、及びNAT構造を通って迂回する警報記録の一連
のリンクされたリストを維持するために使用される２つ
のポインタを含む。

ATAは、作成中及び実行中の両方の便宜のために、活
警報のリストではなく警報ログの像を維持する。NATへ
の更新は、ATAPEの“ATA警報通報”記録内に設けられた
警報表索引を使用して直接的に達成される。

NAT記録内のリンクされたリストポインタは、任意の
回路網デバイスのための全ての警報を一緒にリンクさせ
るために使用される。何れかのリスト内の最初の警報記
録は、そのデバイスのための最も臨界的な警報を表わ
す。NATへの更新は、警報情報の訂正のみならずその特
定デバイスのための表内の他の警報に対するリンクリス
トポインタの訂正をも必要とする。リスト及びそれらを
維持するために要求される論理によって誘導される複雑
さが、MAGICへの警報の分配を促進する。要約すれば、
警報は、もしそれがリンクされたリストの頂部にあれ
ば、或はもしそれが以前に活動していてクリアされたも
のであれば、MAGICに報告される。

ATAは、１つの活警報記録がより臨界的に警報のため
に警報表から追い出された時点を認識しなければならな
い。この警報は、あるデバイスのためのものであるかも
知れないし、またはそうではないかも知れない。殆んど
の場合、ATAは、１つの警報が削除（またはクリア）さ
れると、及び新しい警報が付加されるとこれを中断さ
せ、結果をMAGIC及びNAMに適切に報告しなければならな
い。

3.3 ATAPEプログラム内部 本節では、前節までに説明した機能性を遂行するため
にATAPE内で創成させる主要データ構造及びルーチンを
説明する。

3.3.1 ATAPE主要データ構造 本データ構造は付録Ｃに定義されている。

ATAPEアプリケーション内の主要データ構造は、大域
データ領域、セッション制御ブロックSCB、ELM制御ブロ
ックECB、及び警報表ATである。

3.3.1.1 大域データ領域 大域データ構造はATAPEのための一次データ構造であ
る。本構造は、タスクのスタックに割当てられているロ
ーカルルーチンデータ変数を除き、アプリケーションに
よって管理されている全ての他のデータを直接的に、ま
たは間接的に指し示すポインタを含む。

タイマブロック変数（タイマポインタ）はATAPEタス
クのための核によって管理されるタイマのブロックを指
し示す。ATAPEは４つのタイマを保持する。即ち、 “セッションウォッチドッグ” ATA-ATAPEセッション
上で長いタイムアウトとして使用される。このタイマが
終了すると、ATAPEはATAからの応答を請求するためにAT
Aに警報通報（警報に変化が無ければ空白）を送る。も
し再び終了すれば、ATAPEは自身を削除する。

“セッション遊休” セッションインタフェースのタイ
ムアウトを回避するために応答をATAに送らなければな
らない時点を決定するために使用される。このタイマが
終了すると遊休または警報変化の何れかの通報が送出さ
れる。

“ELMウォッチドッグ” ELMとの非応答状況を決定する
ために使用される。

“ELMポーリング” 規則的なレートで警報要約問合せ
を駆動するために使用される。

SCB,ECB,及びATデータ構造を後項で説明する。

変数“警報ペンディング”はELMインタフェース論理
とATAインタフェース論理との間のフラグであり、変化
して警報がATAに関してペンディング”であることを表
わす。変数“変化した警報数”は、変化した警報記録の
数を表わす。

セマフォー“ATロック済”はELMインタフェース論理
によって使用され、一貫したコピーが得られるまで警報
表内の変化の送出を禁止する。ATAインタフェース論理
は警報変化が発生した（警報ペンディング）ことを検出
すると、警報通報を送ることを試みる。もし“ATロック
済”セマフォーがセットされていれば、空の警報通報が
構成される。

3.3.1.2 セッション制御ブロック セッション制御ブロックは、ATA-ATAPEセッションイ
ンタフェースを管理するために必要な全ての変数を含
む。

セッションインタフェースは状態駆動である。発生し
得る状態は以下の通りである。

“休眠セッション” ATAPEが始動した後で、ATAから
“ATA開通通報”を受信する前の状態、 “開通時セッション” ATAPEが“ATA開通通報”を受信
した後で、ATAから最初の“ATA次の通報”を受信する前
の状態、 “遊休セッション” 送るべき警報変化が存在しない
状態、 “警報中セッション” 送るべき警報変化が存在する
か、または“セッションウォッチドッグ”タイマが終了
し且つ無警報通報が送られたかの何れかの状態。何れの
場合もATAからの応答が予期される。

セッション制御ブロック内の他の変数は、前述の機能
性を達成するために必要とする通報の順序付け及び通報
の緩衝を制御する。

3.3.1.3 ELM制御ブロック ELM制御ブロックECBはELMタスクへのインタフェース
を制御する。このインタフェースは状態駆動であり、２
つの状態（要約ポーリング及び警報読み出し）はATAPE
が要約をポーリングする（警報変化を待つ）のか、或は
警報表を読み出して記録をそのローカル制御表内に記録
するのかを定義する。

変数“合計警報数”及び“活警報数”はELMから受信
した最後の警報要約情報を反映し、警報表への変化を検
出するために次の集合の要約情報と比較される。ELMの
要約情報のこの副集合は、ELMの警報ログ内の新しい警
報、変化した警報、及びクリアされた警報の全てを検出
するのに充分である。

ポインタ変数“ポインタ要求要約通報”は検出ログを
読み出すために使用される通報バッファを追跡する。AT
APEが送る同じ通報はELMによって返却され、全警報ログ
が書き込まれるまでATAPEによって再送される。

変数“警報要求ブロック”及び“再試行カウンタ”は
ELMとの交換における誤りを検出し、回復するために使
用される。

変数“ELM TID"はATAPEが通信しているELM（マスタ、
または幾つかの考え得るシャドウELMの１つ）を識別す
る。

3.3.1.4 警報表 警報表（AT）は、ELMの警報ログ内に収容されている
関連警報情報の像を含む。また、最後のスナップショッ
トを取ってセッションインタフェースに待機して以降警
報記録が変化したか否かを表わすフラグを各警報記録内
に含む。

VIII.モニタデータベースアプリケーションの設計 1.序節 DBAは、IDNX構成データベース、及び回路網内の実時
間幹線状態に関する正確な情報を維持する責を負う。DB
Aは、APE（結合されたプロセッサエグゼキュータ）から
物理データベースブロックを受信し、この情報をDBMS
（オラクル）要求に変換する。即ち物理ブロックに論理
的意味を与える。

第21図は本アプリケーションのブロック線図及びデー
タベースがIDNXノードからモニタノードへアップロード
する際のデータ流である。モニタノードは、データベー
スアプリケーションDBA2100を含み、DBAはモジュール21
01及びデータベースをオラクル2102に基いて変換する。
更に、回路網トポロジアプリケーションNTA2103がモニ
タノード上にある。回路網内に分散している各IDNXスイ
ッチングノード上には、データベースアプリケーション
結合プロセッサエグゼキュータDBAPE2104、IDNXノード
データベースDBC2105、及び実時間幹線情報を生成するI
DNX通信タスク2106が存在する。

IDNXデータベースは、複数の128バイトブロックと、
これらのブロック内に含まれるデータのための検査合計
を含む。第21図に示すように走るアプリケーションの動
作を以下に説明する。

2.データの取得 DBAは、モニタが結合されているIDNXノード上を通報
がオーバランするのを防ぐように、データベースをアッ
プロードし、データベースへの変化を受入れなければな
らない。DBAは回路網内のノードを直列に、または並列
に扱うことができる。実際のプロトコル及び通報は後述
する。このプロトコルによれば帯域幅の、及びIDNX資源
の、効率的使用が可能となる。

DBAは、監視されているノードがモニタから切離さ
れ、再びこれらのノードに到達可能になった時に、回路
網トポロジアプリケーション（NTA）から通告されなけ
ればならない。これはモニタとIDNXとの間のリンクの障
害を含み、DBAは先ず障害を通知され、次でリンクが復
旧したことを通知されなければならない。

DBAは、DBAにまたがるクラッシュにおいてさえ、モニ
タクラッシュにおいて、及びIDNXノードクラッシュにお
いてさえ連続性を維持しなければならない。

3.データの変換 物理データベースからDBMS書式への変換は２段階プロ
セスである第１段階は物理ブロックから論理エントリへ
の変換、第２の段階は論理エントリからDBMS表エントリ
への変換である。データを変換するために、DBAは変化
を検出するための基準としてノードの物理データベース
のコピーを常時保持していなければならない。

ここでのキーは、数ブロックだけが変化した場合に変
換の努力を制限できるようにすることである。段階２に
おける変換プロセスは、何処でこれが遂行できるかであ
る。

実際の変換プロセスは、データベースの物理レイアウ
トを定義するためにIDNX構造を使用する。ノードからの
入データブロックは局所的に保持されているデータベー
スのコピーと比較され、変化したバイトの位置がIDNX構
造へマップされる。これはどの論理変化がなされたのか
を示し、各型の論理変化を取扱う特別な符号が呼出され
てDBMS SQLデータへの変換が行われる。若干の論理記録
フィールド内の若干の値が、他のフィールドに依存して
異なる意味を有する（例えば、カード記録のステータス
フィールドはカード型フィールドに依存する）ので、物
理から論理へのマッピングは非トリビアルである。

4.他のモニタタスクとのインタフェース 回路網トポロジアプリケーション（NTA）は、ノード
アップ及びノードダウン事象をDBAに通知する責を負
う。DBAは、ノードアップ事象を受信すると、目標ノー
ド上にDBAPEを創成してそのノードのデータベースの初
期コピーを入手するか、またはDBAPEを用いてそのノー
ドのデータベースに何等かの変化があったか否かを検査
する。もし変化を検出すればDBAは、ノードデータベー
スが変化したこと及びアップロードが行われるであろう
ことを表わす通報をNTAに送る。（多分行われないであ
ろうが）データベースをアップロードした後、DBAは初
期化が完了したことを表わす通報をNTAに送る。機能的
には、これはモニタ上のデータベースが完全に更新さ
れ、そのノードのために有効状態にあることを意味す
る。その後に限ってNTAは他のモニタに、そのノードが
“アップ”であることを通知する。

ノードデータベースへの変更がDBAによって記録され
ると、DBAは利用者インタフェースを新しくしておくた
めに、変化したデータを表わす通報をMAGIC（利用者へ
の図形インタフェース）へ送らなければならない。DBA
はDBMSへの変化を行うとそれらの変化を追跡し続け、終
了すると対象を付加、削除及び変更するためにMAGICの
定義された通報でMAGICへ通知する。

5.DBAデータ構造 DBAは第22図に概要を示すノード構造のリンクされた
リスト内のノードデータを追跡する。NTAから到達する
通報は新ノード2201を付加し、新データ構造2202はリス
トに割当てられ付加される。もし後刻NTAがノード削除
通報2203を送付すれば、そのデータ2204はリストから削
除され、割当てが解除される。従ってアプリケーション
が取扱い得るノードの数は使用可能なメモリの量によっ
てのみ制限され、ハードワイヤード限界は存在しない。
ノード構造は検査合計2205、データベースブロック220
6、ペンディングブロック2207、雑DBA2208及びオラクル
データ2209からなる。データブロックはノードデータベ
ース内の全てのデータベースブロック及び実時間データ
（ブロック書式の）を含む。検査合計はこれらの各ブロ
ック毎の検査合計である。ペンディングブロック域はブ
ロック番号のリスト、ブロックデータ及び受信はしたが
未だに検査されていないブロックの検査合計である。検
査されるためには、次のブロック群、或は‘全てOK'通
報がAPEから到達しなければならない。ブロックが検査
されると、それらはデータベースブロック域へ転送さ
れ、検査合計が更新される。オラクルのための雑域は、
オラクル検査合計及び表索引を保持するために使用され
る（効率化のために）。DBAのための雑域は、ノード番
号、ノードアップ／ダウン状態、送られた最後のITC通
報を指し示すポインタ、タイマ、カウント、及び‘肯定
応答’失敗を保持する。

APEは、データのアップロードを終了すると、‘全てO
K'通報を送る。これはDBAをトリガしてデータをDBMSに
変換（ブロック2101）させ始める。この変換が完了し、
DBMS2102が成功裏に更新されると、ノードデータはその
ノードの最後の既知安定状態としてディスクへ保管され
る。即ち、入変化はRAM内で行われ、それが完了する
と、ノードのRAM像がディスク像（これはDBMS内の情報
を反映している）と比較されて変換のための差が見出さ
れる。ディスク像はシステムクラッシュからの回復にも
使用させる。オラクル検査合計は、ディスクファイルが
変化しないにも拘わらずDBMSが変化（クラッシュまたは
再初期化により）することがないように保護する。もし
このようなことが発生すると、ディスクファイル内に保
持されているオラクル検査合計はオラクル内に保持され
ている検査合計に一致しなくなり、ローカルデータから
のDBMSの完全再ロードがトリガされる。

6.データベースAPE データベースAPE（DBAPE）はIDNX世界におけるモニタ
データベースアプリケーション代理である。DBAPEは、I
DNXデータベースのための責を負うIDNX DBCタスクと同
一のCPU上の走る。このCPUは、もし一方が使用可能であ
れば双対プロセッサCPUであるが、もし他方が存在しな
ければマスタCPUであり、従ってDBAPEは“双対プロセッ
サ優先”モードで走る。

APEは第23図にブロック2301で示す３つの主要データ
構造を有する。１つは、モータDBAに送った全ての最新
肯定応答検査合計の集合2302である。次は、モータDBA
にアップロードする必要があるブロック（ダーティフラ
グ2303）のリストである。最後は、幹線ステータスの変
化の結果として幹線タスク2307から受信した実時間デー
タの集合2304である。この実時間データはデータベース
のサイズのブロックにパッケージされ、検査合計2306が
計算され、以後これらのブロックは“特別”物理データ
ベースブロックとして取扱われる。

7.データベース初期化及び再初期化 APEが始動すると全ての実時間情報の集合が初期化さ
れ、アップロードされるブロック（“ダーディ”ブロッ
ク）のリストがクリアされる。次でAPEは、何等かの実
時間を集めて、モニタDBAから通報を受信するまで待機
する。

APEは、DBC自体と形式対話せずにDCBデータブロック
及び検査合計をメモリから直接読み出し、実時間データ
ブロックはそれ自身の内部データ構造から読み出す。初
期化のための要求が到着すると、データブロックは全て
のアップロードのためにマークされ、パッケージされて
DBAへ送られる。変化のための要求が到着すると、DBA検
査合計がDBC検査合計（及び実時間検査合計）と比較さ
れ、検査合計が異なるデータブロックはアップロードの
ためにマークされ、次でアップロードする（このセッシ
ョンから、または未完の先行セッションから）ためにマ
ークされた全てのブロックがパッケージされ、DBAに送
られる。

8.データベース変化 IDNXデータベース或は実時間情報に変化が発生する
と、APEはDBAに対する変化通報を開始することができ
る。20秒置きにAPEは検査合計を比較し、何等かの変化
があったブロックを“ダーティ”（ライン2305）としマ
ークする。実時間情報の変化はIDNX通信タスク2307によ
ってAPEに直接送られる。もし何等かの変化が見出され
ると、ブロックはDBAに送られ得るしかし、これは回路
網が通報で溢れるのを防ぐために、未決通報転送が進行
中でない場合に限って発生し得る。一時に１つの未決通
報のみが許容される。もし応答が受信されなければ、DB
Aとの接触が再確立されるまで異なる通報は送ることが
できない。

9.通報及びプロトコル 通報及びプロトコルは、回路網上の通報トラフィッ
ク、及びIDNX内で使用される時間と資源を最小限ならし
めるように設計されている。

DBAからDBAPEへは３つの通報が存在する。各通報は
（多分）APEからのデータパケットの流れをトリガす
る。IDNXデータベースの変化の場合には、この転送はAP
Eによって開始させることができるが、DBAへの通報の溢
れを防ぐために常に肯定応答プロトコルを伴う。DBAPE
からDBAへ戻る３つの通報も存在する。全ての通報はITC
見出しで開始される。

以下に示すパケット書式は、データベース当り255よ
り多い128バイトブロックを可能ならしめる。ブロック
番号は‘struct'内ではなく‘char'内に含まれる。解放
７データベースは既にほぼ250ブロックを有しており、
実時間データは付加的な２ブロックを使用するので、こ
の予防措置は合理的であると考えられる。

APEインタフェース： ３つの型の通報即ち何かが変化した、何も変化しない
（それ以上変化なし）、及びDBCが障害を起した（情報
に関してのみ）の通報がAPEからアプリケーションへ送
られる。

‘変化’通報は、アプリケーションからの問合せに応
答して送られるか、またはIDNXデータベース内に変化が
検出されるとAPEによって開始される。これは、通報交
換番号（もしAPEが開始すれば０）、変化したブロック
の合計数、この通報内のブロックの数、ブロック番号、
それらの検査合計、及びそれらのデータを含む。

DBA-Changes-Msg ‐struct ItcHeader Hdr ‐unsigned char exchangenum ‐unsigned Short Cur Num Change Blks ‐unsigned char NumBloks ‐unsigned short Block List Tbl 〔MAX-DB-BLOCKS-PER-MSG〕 ‐unsigned short Block Csum Tbl 〔MAX-DB-BLOCKS-PER-MSG〕 ‐unsigned char DB-Data〔MAX-DB-BLOCKS-PER-MSG〕 〔DB-BLKSIZE〕 ‘無変化’通報は、データベース内に変化が存在しな
いか、或は変化を送った後に更なる変化が存在せずデー
タが一貫していることを最後の通報が指示している場合
にのみアプリケーションからの問合せに応答して送られ
る。この通報は通報交換番号及び現大域データベース検
査合計を含む。

DBA-No-Change-Msg ‐struct Itc Header Hdr ‐unsigned char exchangenum ‐int CurDBGlsbCsum ‘DBC障害’通報は、問合せに応答して、またはDBC障
害が検出されればAPEによって送られる。これは通報交
換番号のみを含む。

DBA-DBC-Failed-Msg ‐struct ItcHeader Hdr ‐unsigned char exchangenum DBAインタフェース： ３つの型の通報、即ち受信したデータパケットの肯定
応答、全IDNXデータベースをアップロードする要求、及
びデータベースの変化に関する要求がアプリケーション
からAPEへ送られる。

‘肯定応答’通報はAPEからのデータパケット（‘変
化’通報）に応答して送られる。これはアプリケーショ
ンが予期する通報交換番号、ブロックの数、ブロック番
号、及び肯定応答しているAPE通報のブロック検査合計
を含む。

DBA-Ack-DB-Ape-Msg ‐struct ItcHeader Hdr ‐unsigned char exchangenum ‐unsigned char Num Blocks ‐unsigned short Blocks List Tbl 〔MAX-DB-BLOCKS-PER-MSG〕 ‐unsigned short Blocks Csum Tbl 〔MAX-DB-BLOCKS-PER-MSG〕 ‘全て送れ’通報は、アプリケーションがIDNXデータ
ベースのコピーを有していない（‘havedata'が偽）場
合にAPEに送られる。これはAPEを全てのデータベースブ
ロックをアップロードすることを要求する。この通報は
アプリケーションが予期する通報交換番号のみを含む。

DBA-Send-All-Msg ‐struct ItcHeader Hdr ‐unsigned char exchangenum ‘変化送れ’通報は、アプリケーションがIDNXデータ
ベースのコピーを有し（‘havedata'が真）、何等かの
変化を更新することを欲する場合にAPEに送られる。APE
は変化したブロックだけをアップロードすることを要求
される。この通報は、アプリケーションが予期する通報
交換番号、大域データベース検査合計、及びアプリケー
ションのブロック検査合計値を含む。

DBA-Send-Changes-Msg ‐struct ItcHeader Hdr ‐unsigned char exchangenum ‐int CurDBGlobCsum ‐unsigned short Block Csum Tbl〔CB-NUMBLKS〕 NTAインタフェース： ３つの型の通報、即ちアプリケーションがリセットさ
れどのノードが回路網内にあるかを知る必要がある時の
リセット通報、APEがあるノードのためのデータのアッ
プロード及び変換を終了した時のデータベース有効通
報、及びAPEがあるノードのデータベースが変化したこ
とを検出しアップロードする必要がある時のデータベー
スが変化して（変化している）通報がアプリケーション
からNTAへ送られる。

‘nta'通報は全てのNTA通報のために使用される。こ
の通報は‘有効’或は‘変化した’通報のためのIDNXを
保持する‘データ’フィールドのみからなる。このフィ
ールドは‘リセット’通報に関しては未定義である。

＃ define DBA-NTA-DBA-RESET-MSG （DBA-INCS-MSGS-BEGIN＋０） ＃ define DBA-NTA-DB-VALID＋MSG （DBA-INCS-MSGS-BEGIN＋１） ＃ define DBA-NTA-DB-CHANGED-MSG （DBA-INCS-MSGS-BEGIN＋２） DBA-NTA-Msg ‐struct ItcHeader Hdr ‐shurt data これらの通報はNTAから予期される。

NTA-ALL-NODE-UP-MSGは、特定ノードがアップであ
り、到達可能であることをdbaに知らせる。

NTA-NODE-DOWN-MSGは、特定ノードがダウンして到達
不能であることをdbaに知らせる。

NTA-NODE-DELETED-MSGは、特定ノードがモニタ域から
削除されたことをdbaに知らせる。

NTA-HDLC-LINK-DOWNは、HDLCリンクがダウンしたこと
をdbaに知らせる。

NTA-ALL-LINK-UP-MSGは、HDLCリンクがアップである
ことをDBAに知らせる。

NTA-ALL-NODE-IN-NET-MSGは、モニタ域内のアップで
ある全てのノードに関する情報を与える。

NTA-RESET-MSGは、NTAがリセットされたことをdbaに
知らせる。

10.通報プロトコル DBAとそのAPEとの間を渡る通報はデータグラムレベル
における発生するから、通報が順番に到着することを保
証するために、或は結局は通報が到着するとしても、特
別なプロトコルを使用しなければならない。DBA-DBAPE
プロトコルは、DBAからの‘肯定応答’通報、或はDBAPE
からの応答の何れかによって通報を‘肯定応答’するこ
とによって通報引渡し問題を扱う。別の問題は、通報が
回路網内で遅延し得ることである。先行通報が後に送ら
れた通報の後に到着して多分失効させられるか、或は時
代遅れとなる可能性がある。

ノードの正確な現状態をデータベースに常に反映させ
るために、DBAとそのAPEとの間で使用される通報渡しプ
ロトコルは、古い通報を破棄するために署名バイト（交
換番号）を使用する。交換番号は、１から255まで進み
再び１に戻る（０を飛び越す）無符号バイト量である。
特別な値、即ち０はAPEからの非請求通報のために保留
する。交換番号は、この通報が受信された時に、それ以
外の場合には通報交換内の誤りに出会った時に限って、
インクリメントされる。

第24図に示すように、DBAは受信が予期される交換番
号を憶えている。APEは、送られたものをまねするだけ
である。これはAPE或はDBAがクラッシュの場合に同期を
簡易化する。APEが通報を開始するものとするとすれ
ば、APEは使用する交換番号を知らないから、交換番号
を０にセットする（第25図）のはこのためである。

例えば、もし通報が転送中であって現交換番号が22で
あり、DBAからAPEへの‘肯定応答’通報が回路網内にお
いて遅延すれば、DBAはタイムアウトして‘肯定応答’
が再送される可能性がある。この場合新‘肯定応答’の
ための交換番号は23にインクリメントされる。もし両通
報がAPEによって受信されれば、返答は各通報に対して
送られる。DBAは交換番号23に対する返答だけを受入
れ、交換番号22に対する返答は破棄される（第26図〜第
30図参照）。

11.プロトコル 正常操作中、DBAは‘変化送れ’通報を検査合計の完
全リストと共にAPEへ送る。APEはそれらの検査合計をDB
C検査合計及び実時間検査合計と比較し、変化したブロ
ックのアップローディングを開始する。各アップロード
通報は６つまでのデータベースブロック、それらの番
号、及びそれらの検査合計を含む。変化を受信すると、
DBAは受信したブロック番号及び検査合計を戻すことに
よって通報を‘肯定応答’する。データはペンディング
域内に保持される。APEはこの‘肯定応答’を入手し、
肯定応答通報内の検査合計を使用してその検査合計域を
更新する。これは、既知検査合計のその知識とDBAに知
らせたものとが同一であることを保証する。‘肯定応
答’を受信するとAPEは変化したブロックの次のバッチ
を自由に送れるようになる。この次の通報はDBAによっ
て受信され、ペンディング域内に保持されているブロッ
クは有効と見做されて主データベースブロック域内へロ
ードされる。新ブロックはペンディング域内に配置さ
れ、上述のように‘肯定応答’される。これはAPEから
‘全てOK'通報を受信するまで続けられる。ペンディン
グデータは主域内へロードされ、変換ルーチンが呼出さ
れる。あるノードの完全アップロードのための現数は、
通報当り６ブロックで252データベース及び実時間ブロ
ック、即ち42通報である。

通信が困難である（パケットが大量に失われたか或は
遅れた）場合にはDBAは、そのノードが未だにアップで
あることをNTAが示している限り、そのノードに通報を
送ることを試み続ける。３回の再試行毎に、DBAはAPEの
再試動を試みる。もしモニタとの接触が40分以上に亘っ
て失われれば、APEは自身を殺す。

12.シナリオ 正常動作中、幾つかの異常状態が存在する可能性があ
る。本節ではプロトコルが如何にこれらの状態を処理す
るかを説明する。

12.1 モニタクラッシュまたはDBAクラッシュ DBAは、各アップロードが成功した後にディスクへの
ノードデータを保管する。クラッシュの後、そのデータ
はディスクから最後の既知の安定構成に復元される。次
でDBAは全ての到達可能なAPEに‘変化送れ’通報を送
り、変化したブロックだけがアップロードされる。もし
NTAが何等かの新たに構成されたノードをDBAに知らせれ
ば、DBAはこれらのノードに‘全て送れ’通報を送って
それらの全データベースをアップロードさせる。DBAは
現在ダウンしているノードに到達しようとは試みない。

12.2 リンク状態またはノード状態変化 この場合NTAは、リンク及びノードの両者或は何れか
一方のダウン、次でアップ状態をDBAに通知する。NTAか
らアップ状態を受信するとDBAは全てのノードまたは問
題のノードに適切な‘変化送れ’通報を送る。

12.3 IDNXノードクラッシュまたはDBAPEクラッシュ これはモニタに対して実質的に透過的な事象である。
もしノード或はAPEがクラッシュすればデータの損失は
発生せず、最悪の問題はDBAがそれらへの要求をタイム
アウトするまでAPEが何等の変化通報も開始しないこと
であろう。

12.4 DBCクラッシュ APEはDBCに直接頼らないから、これはモニタに対して
透過事象である。

IX.回路網トポロジアプリケーション設計 1.序節 回路網トポロジアプリケーションNTAは、ノード回路
網のトポロジに関する情報を維持する責を負うモニタ上
を走るタスクである。NTAはローカルノード上の回路網
管理者タスクと通信してトポロジマップデータを検索す
る。ノード上に特別なインタフェース（APE）は必要と
しない。トポロジに変化を生じるとNTAはその内部トポ
ロジマップを更新し、他のタスクに変化を通知する。

2.トポロジ情報検索 各ノード内の回路網管理者は回路網トポロジのマップ
を維持する。このマップ“最大ノード”ד最大リン
グ”（250^*32）のアレイである。ノード番号毎に、各行
は無で終端する隣りのノードのリストを含む隣りのノー
ドが存在しないノードは回路網内ではなく、即ち“ダウ
ン”である。各ノードへのリンクに対応付けられている
のはリンク費用及びリンク属性（衛星対地上等）であ
る。

トポロジマップの各行に対応付けられているのはバー
ジョン番号であり、これは行が変化する度にインクリメ
ントされる。全てのバージョン番号の検査合計は、トポ
ロジマップの現構成を表わすために維持される。

モニタ上では、NTAは現トポロジマップの自身のバー
ジョンを維持する。NTAタスクの始動時にはマップは全
て無に、行バージョンは０に（“経路存在せず”）に初
期化される。周期的に（例えば30秒置きに）NTAはノー
ド回路網管理者或はその隣のノードをポーリングして合
計検査合計が変化したか否かを見る。もし変化していれ
ば（そしてNTA始動時に）NTAを回路網管理者にその行バ
ージョン及び変化した各検査合計に関して問合せ、NTA
は変化して行を問合せてそのトポロジマップを更新す
る。

NTAは、モニタとローカルノードとの間のリンクがダ
ウンしているこはとを検出しなければならない（例えば
ノードのポーリングを試みた時の誤りの戻り、或は回路
網インタフェースタスからの通報）。これは発生した
時、NTAはその現マップを再初期化（全ノード“ダウ
ン”）し、他のタスクに更新を送る（後述）。

2.1 ノードソフトウェア要求 回路網管理者は、合計検査合計、行バージョン、及び
行データを問合せるために通報の型を取扱う必要があ
る。

3.他のアプリケーションとの通信 新しいノードが回路網内でアップするとNTAは先ずモ
ニタデータベース内を調査してそのノードがこのモニタ
域内にあるか否かを見る。もし否であれば、NTAは他の
タスクの何れをも通知しない。もしノードが構成されて
いれば更なる調査を行い新ノード上を走るソフトウェア
バージョンがモニタと両立できるか否かを決定する。も
し両立できれば、NTAは“ノードアップ”通報（NTAノー
ドアップ通報）でデータベースアプリケーションDBAに
通知する。DBAがノードのデータベースの現コピーを有
している場合にはDBAはNTAに通報を送る。それによりNT
Aは事象アプリケーションEVA、警報表アプリケーション
ATA、及びMAGICへ“ノードアップ”通報を送る。

これらが始動する時（即ちNTAからリセット通報を受
信すると）、EVA、DBA、ATA及びMAGICは全ノードがダウ
ンしているものと見做し、NTAへリセット通報を送るこ
とによって、アップしているノードの完全セットを要求
する。NTAが再始動する時には他のタスクへリセット通
報を送ってそれらに完全セットを要求していることを通
知しなければならない。

ノードがダウンすると、NTAは他の各アプリケーショ
ンへ“ノードダウン”通報（“NTAノードダウン通
報”）を送る。

4.構成ツール対話 ノードが構成ツールによってモニタ域に付加されるか
或はモニタ域から削除されると、ノードは域データベー
スを更新してNTAへ通報を送る。これによりNTAはデータ
ベースを再読み出しさせられ、どのノードが域に付加さ
れるか或は域から削除されるかを決定する。

もしノードが付加されるのであれば、NTAはそのトポ
ロジマップを調査してそのノードが現在回路網内にあっ
て且つ両立可能なソフトウェアバージョンを有している
か否かを決定する。もし諾ならば、トポロジ内の“ノー
ドアップ”変化に関するものと同一の手順を遂行する。
もし否であれば他に何もしない。

もしノードが削除されるのであれば、NTAはそのトポ
ロジマップを調査してそのノードが現在回路網内にあっ
て両立可能なソフトウェアバージョンを有しているか否
かを決定する。もし諾ならばNTAは他のアプリケーショ
ンタスクへ“ノード削除”通報（“NTAノード削除通
報”）を送る（これは若干のタスクによって“ノードダ
ウン”と同一に取扱われるかも知れない）。もし否であ
れば他に何もしない。

5.モニタデータベース更新 NTAは、それ自身が使用する（例えば回路網内で何が
変化したかを決定する）ために内部トポロジマップを維
持する。NTAはモニタデータベース内の表の創成または
更新を行わない。もし他のアプリケーションか全トポロ
ジマップに関して知る必要があれば、その情報を転送す
るために通報を定義することができる。

X.結論 本発明の好ましい実施例の以上の説明は例示のために
なされたものである。この説明は本発明を完全に網羅し
ているものでも、或は本発明を説明通りの形に限定する
ものでもない。明らかに、当業者ならば多くの変更及び
変化が明白であろう。これらの実施例は本発明の原理及
びその実際の応用を解読するために選択され、説明して
ものであって、他の当業者は計画した特定の用途に適す
る種々の具体化及び種々の変更を行う上で本発明の理解
できたであろう。本発明の範囲は以下の請求の範囲及び
それらの等価によって限定されるものである。

付録Ａ ATAとATAPEとの間の通報の書式 37C.F.R.§ 1.96（ａ）（２）（ii） この警報エントリ書式はIDNX ReL 7.5コード,In Rel
7.7からコピーした。書式を改訂しINCSとIDNX通報書式
との間の結合は破った。

付録Ｂ ATA内の主要データ構造 37C.F.R.§ 1.96（ａ）（２）（ii） 回路網警報表記録 特定のAPEのSCBの警報表内の警報記録の数はAPEのノ
ード上のELMの警報ログの大きさによって決定される。
（この大きさはAPEセッション初期化時に送られる。） NAT警報記録はELM警報表から直接コピーされる。

NAT内に表わされる全デバイスのための連係された警
報のリストが存在する。これは警報の分配を容易ならし
める。

ノード表記録 この表は２つの目的を有する。これはAPEセッション
制御ブロックを参照し、回路網内のノードの現ステータ
スを追跡する。ステータス情報は一般にNTAアプリケー
ションから受信した通報から誘導される。“リセット”
を受信すると回路網内に限定されているノードの現集合
がINCSデータベースから読み出される。

付録Ｃ ATAPE内の主要データ構造 37C.F.R.§ 1.96（ａ）（２）（ii） 大域記憶装装レイアウト： Global Pは核に登録されたデータポインタである。

gPはショートハンド基準として、Global Pと等価であ
ると定義される。

警報ペンディング論理はATAPE＜＝＞ELMインタフェー
スとATAPE＜＝＞ATAインタフェースとの間のスイッチで
ある。これはELMから新警報を受けるとセットされる。
これは全ての未決警報がATAへ送られるとリセットされ
る。

フロントページの続き (72)発明者 ヘルゲソン クリストファー ショーン アメリカ合衆国 カリフォルニア州 94040 マウンテン ヴィュー テュー レイン ドライヴ 1670 (72)発明者 ガノン マイケル リチャード アメリカ合衆国 カリフォルニア州 94025 メンロ パーク ウィンザー ドライヴ 1012 (72)発明者 ビショップ ウィリアム アレン アメリカ合衆国 カリフォルニア州 94040 マウンテン ヴィュー フィリ ス コート 1165 (72)発明者 ムーモー サンドラ リー アメリカ合衆国 カリフォルニア州 95127 サンホセ ラムスタッド ドラ イヴ 3502 (72)発明者 フォーキッシュ カレン リー アメリカ合衆国 カリフォルニア州 94061 レッドウッド シティ ユニオ ン アベニュー 1617 (72)発明者 タン セック エン アメリカ合衆国 カリフォルニア州 94043 マウンテン ヴィュー イージ ー ストリート 48‐302 (72)発明者 ラージケウィクズ ティム オメラン アメリカ合衆国 カリフォルニア州 94560 ニューアーク シャディー ハ ロー ドライヴ 7450 (72)発明者 デュポント ロナルド ルクセンブルグ国 エル‐5366 ムンス バック リュー プリンシパル 234 (56)参考文献 特開 昭57−143958（ＪＰ，Ａ) 特開 昭63−107249（ＪＰ，Ａ) 米国特許4464543（ＵＳ，Ａ)

Claims (27)

(57)【特許請求の範囲】
1. 【請求項１】通信機能、スイッチングノードの警報状態
   のノードリストの保持、そしてスイッチングノードの構
   成を特定するノード構造のデータベースの保持を含むタ
   スクをそれぞれのスイッチングノードが遂行しており、
   このようなスイッチングノードが多数分布し、それらの
   スイッチングノードを相互にリンクで接続して成る通信
   回路網の状態に関する情報を集め、そして表示する情報
   収集・表示装置において、 この情報収集・表示装置は、前記の多数のスイッチング
   ノードの中の第１のスイッチングノードへ接続されたモ
   ニタノードを備え、このモニタノードは、 操作員入力インターフエース、 前記の通信回路網のトポロジを指示するトポロジデータ
   を維持し、そして第１のスイッチングノードとの第１の
   プロトコルを支持する第１の手段、 前記の通信回路網における警報状態についてスイッチン
   グノードのリストに入れた警報状態のモニタリストを維
   持し、そして前記の多数の分布したスイッチングノード
   と前記の通信回路網を通して第２のプロトコルを支持す
   る第２の手段、 前記の通信回路網におけるスイッチングノードの構造の
   データベースに入れたスイッチングノードの構造を指示
   するモニタデータベースを維持し、そして前記の多数の
   分布したスイッチングノードと前記の通信回路網を通し
   て第３のプロトコルを支持する第３の手段、そして 前記の通信回路網におけるあるスイッチングノードを特
   定する操作員入力に応答し、そしてモニタデータベー
   ス、警報状態のモニタリストそしてトポロジデータへ結
   合されて、当該スイッチングノードについての構造デー
   タ、通信回路網のトポロジそして警報状態を捜査員に表
   示する表示手段を備え、 前記の情報収集・表示装置は、 前記の第１のスイッチングノードに設けられ、多数のス
   イッチングノード上で遂行される通信機能に応答してト
   ポロジデータを発生し、そして前記の第１のプロトコル
   に従ってのメッセージに応じて前記のトポロジデータを
   前記の第１の手段へ送る手段、 前記の通信回路網に分布したそれぞれのスイッチングノ
   ードに設けられ、そのスイッチングノード上の警報状態
   のスイッチングノードのリストに結合されていて、前記
   の第２のプロトコルに従ってのメッセージに応じて、警
   報状態を指示するデータをパッケージし、そして前記の
   第２の手段へ送る手段 を備え、前記の第１のスイッチングノードを除く各スイ
   ッチングノードからの前記のデータは前記の通信回路網
   を通して前記の第１のスイッチングノードへ、そして第
   １のスイッチングノードを通って前記の第２の手段へ通
   り、そして 前記の情報収集・表示装置は、 前記の通信回路網に分布したそれぞれのスイッチングノ
   ードに設けられ、そのスイッチングノード上のスイッチ
   ングノードの構造に結合され、そして前記の第３のプロ
   トコルに従ってのメッセージに応じて、スイッチングノ
   ードの構造のデータベースからのデータをパッケージ
   し、そして前記の第３の手段へ送る手段 を備え、前記の第１のスイッチングノードを除く各スイ
   ッチングノードからの前記のデータは前記の通信回路網
   を通して前記の第１のスイッチングノードへ、そして第
   １のスイッチングノードを通って前記の第３の手段へ通
   ることを特徴とした通信回路網の状態に関する情報収集
   ・表示装置。
2. 【請求項２】前記の表示手段は表示モニタとこの表示モ
   ニタ上に複数の表示ウインドウを発生する図形処理手段
   とを備え、そしてこれらの表示ウインドウの中の第１の
   ウインドウは回路網トポロジを図形表示し、第２のウイ
   ンドウは対象としたノードについての構造データを図形
   表示し、そして第３のウインドウは警報状態のモニタ・
   リストを図形表示する請求項１に記載の通信回路網の状
   態に関する情報収集・表示装置。
3. 【請求項３】前記の図形処理手段は、前記の第２の手段
   が保持している警報状態のモニタ・リストにおける少な
   くとも一つの警報状態に応答して前記の第１のウインド
   ウに表示された回路網トポロジに強い光をあてて目立た
   させる手段を含んでいる請求項２に記載の通信回路網の
   状態に関する情報収集・表示装置。
4. 【請求項４】通信回路網に分散している各スイッチング
   ノード上にあって、スイッチングノードの構造データベ
   ースから前記の第３の手段へデータをパッケージして送
   る手段は、スイッチングノードの構造データベースに対
   する変化を検出する手段と、前記の第３のプロトコルに
   応答して、その検出した変化の少なくとも一部分を含む
   メッセージを発生する手段とを含んでいる請求項１に記
   載の通信回路網の状態に関する情報収集・表示装置。
5. 【請求項５】スイッチングノードの構造データベースが
   複数のデータブロックと、各ブロックと関連したブロッ
   ク検査合計とを含み、 前記のスイッチングノードの構造データベースに対する
   変化を検出する手段が、前記の第３プロトコルに応答し
   て、スイッチングノードの構造データベースのすべての
   ブロックの総計の検査合計を発生する手段と、いま発生
   した総計の検査合計を先に発生した総計の検査合計と比
   較してデータベースに対する変化を検出する手段とを含
   んでいる請求項４に記載の通信回路網の状態に関する情
   報収集・表示装置。
6. 【請求項６】通信回路網に分散している各スイッチング
   ノード上にあって、スイッチングノードのリストに入れ
   られた警報状態を指示するデータをパッケジーして前記
   の通信回路網を通して前記の第２の手段へ送る手段が、
   スイッチングノードのリストに入れた警報状態を検出す
   る手段と、第２のプロトコルに応答して、警報状態の少
   なくとも一部分を含むメッセージを発生する手段とを含
   んでいる請求項１に記載の通信回路網の状態に関する情
   報収集・表示装置。
7. 【請求項７】スイッチングノードのリストは、警報表と
   この警報表における警報状態の数を指示する、警報表に
   関連した数指示器を含み、そして前記の警報状態を検出
   する手段は、いま発生した数表示を先に発生した数表示
   と比較して警報表に対する変化を検出する手段とを含ん
   でいる請求項６に記載の通信回路網の状態に関する情報
   収集・表示装置。
8. 【請求項８】各スイッチングノードが、スイッチングノ
   ードの事象ログを作表した事象記録をそのスイッチング
   ノードのため保持しており、更に モニタノード上にあって、通信回路網におけるスイッチ
   ングノードの事象ログに入れられた事象記録のリストを
   保持し、そして多数の分布スイッチングノードとの第４
   のプロトコルを支持する第４の手段、そして 各スイッチングノード上にあって、スイッチングノード
   上のそれぞれのスイッチングノード事象ログに結合して
   おり、そして第４のプロトコルに従うメッセージに応じ
   て、スイッチングノードの事象ログに入れられた事象報
   告記録を指示するデータをパッケージして前記の第４の
   手段へ送る手段 を備え、前記の第１のスイッチングノードを除く各スイ
   ッチングノードからのデータが前記の通信回路網を通し
   て前記の第１のスイッチングノードへ、そして前記の第
   １のスイッチングノードから前記の第４の手段へ通る請
   求項１に記載の通信回路網の状態に関する情報収集・表
   示装置。
9. 【請求項９】各スイッチングノード上にあって、スイッ
   チングノードの事象ログに入れられた事象報告記録を指
   示するデータをパッケージして前記の通信回路網を通し
   て前記の第４の手段へ送る手段が、スイッチングノード
   の事象ログに入れられた事象記録を検出する手段と、第
   ４のプロトコルに応答して、事象記録の少なくとも一部
   分を含むメッセージを発生する手段とを含んでいる請求
   項８に記載の通信回路網の状態に関する情報収集・表示
   装置。
10. 【請求項１０】少なくとも一つのスイッチングノードが
    複数の処理ユニットを備え、そのスイッチングノードで
    遂行されているタスクが前記の複数の処理ユニットを介
    して分布し、そして警報状態のスイッチングノードのリ
    ストを保持するタスクと、そのスイッチングノード上の
    警報状態のスイッチングノードのリストに結合されてい
    て、前記の第２のプロトコルに従ってのメッセージに応
    じて、警報状態を指示するデータをパッケージし、そし
    て送る手段とが一つの処理ユニットで動いている請求項
    １に記載の通信回路網の状態に関する情報収集・表示装
    置。
11. 【請求項１１】前記の一つのスイッチングノード上の通
    信機能が前記の一つの処理ユニット以外の処理ユニット
    上で作動している請求項10に記載の通信回路網の状態に
    関する情報収集・表示装置。
12. 【請求項１２】少なくとも一つのスイッチングノードが
    複数の処理ユニットを備え、その一つのスイッチングノ
    ードで遂行されているタスクが前記の複数の処理ユニッ
    トを介して分布し、そしてスイッチングノードの構造の
    データベースを維持しているタスクと、その一つのスイ
    ッチングノード上のスイッチングノードの構造のデータ
    ベースへ結合され、そして第３のプロトコルに応答して
    スイッチングノードの構造のデータベースから通信回路
    網を通して前記の第３の手段へデータをパッケージし、
    送っている手段が一つの処理ユニット上で作動している
    請求項１に記載の通信回路網の状態に関する情報収集・
    表示装置。
13. 【請求項１３】前記の一つの処理ユニット以外の処理ユ
    ニットで通信が行われている請求項12に記載の通信回路
    網の状態に関する情報収集・表示装置。
14. 【請求項１４】多数のスイッチングノードが分布してい
    て、それぞれのスイッチングノードが通信機能を遂行
    し、そのスイッチングノードのためスイッチングノード
    の警報状態を含む事象ログを維持し、そしてそのスイッ
    チングノードのため構造を特定する構造データベースを
    維持し、それらのスイッチングノードを相互にリンクで
    接続して回路網トポロジを構成している通信回路網の状
    態に関する情報を集め、そして表示する情報収集・表示
    装置において、 この情報収集・表示装置は、 前記の多数のスイッチングノードの中の第１のスイッチ
    ングノードへ接続された第１のモニタリング手段を備
    え、このモニタリング手段は前記の第１のスイッチング
    ノードを介して回路網のノードとリンクから前記の回路
    網トポロジと、前記の回路網の警報状態と、前記の分布
    したスイッチングノードの第１のサブ・セット内の選択
    ノードのための構造に関する情報を収集して操作員に表
    示し、この第１のモニタリング手段は、 操作員入力インターフエース、 前記の通信回路網のトポロジを指示するトポロジデータ
    を維持し、そして第１のスイッチングノードとの第１の
    プロトコルを指示する第１の手段、 前記の通信回路網における警報状態についてスイッチン
    グノードのリストに入れた警報状態のモニタリストを維
    持し、そして前記の多数の分布したスイッチングノード
    と前記の通信回路網を通して第２のプロトコルを支持す
    る第２の手段、 前記の通信回路網におけるスイッチングノードの構造の
    データベースに入れたスイッチングノードの構造を指示
    するモニタデータベースを維持し、そして前記の多数の
    分布したスイッチングノードの第１のサブ・セットと前
    記の通信回路網を通して第３のプロトコルを支持する第
    ３の手段、そして 前記の多数の分布したスイッチングノードの第１のサブ
    ・セット内のあるスイッチングノードを特定する操作員
    入力に応答し、そしてモニタデータベース、警報状態の
    モニタリストそしてトポロジデータへ結合されて、当該
    スイッチングノードについての構造データ、通信回路網
    のトポロジそして警報状態を捜査員に表示する表示手段 を含み、 前記の情報収集・表示装置は、 前記の第１のモニタリング手段から独立して、前記の多
    数のスイッチングノードの中の第２のスイッチングノー
    ドへ接続された第２のモニタリング手段を備え、このモ
    ニタリング手段は前記の第２のスイッチングノードを介
    して回路網のノードとリンクから前記の回路網トポロジ
    と、前記の回路網の警報状態と、前記の分布したスイッ
    チングノードの第２のサブ・セット内の選択ノードのた
    めの構造に関する情報を収集して操作員に表示し、この
    第２のモニタリング手段は、 操作員入力インターフエース、 前記の通信回路網のトポロジを指示するトポロジデータ
    を維持し、そして第２のスイッチングノードとの第４の
    プロトコルを支持する第１の手段、 前記の通信回路網における警報状態についてスイッチン
    グノードのリストに入れた警報状態のモニタリストを維
    持し、そして前記の多数の分布したスイッチングノード
    と前記の通信回路網を通して第４のプロトコルを支持す
    る第２の手段、 前記の通信回路網におけるスイッチングノードの構造の
    データベースに入れたスイッチングノードの構造を指示
    するモニタデータベースを維持し、そして前記の多数の
    分布したスイッチングノードの第２のサブ・セットと前
    記の通信回路網を通して第６のプロトコルを支持する第
    ３の手段、そして 前記の通信回路網内のあるスイッチングノードを特定す
    る操作員入力に応答し、そしてモニタデータベース、警
    報状態のモニタリストそしてトポロジデータへ結合され
    て、当該スイッチングノードについての構造データ、通
    信回路網のトポロジそして警報状態を捜査員に表示する
    表示手段 を含み、 前記の情報収集・表示装置は、 前記の第１のスイッチングノードに設けられ、多数のス
    イッチングノードの第１のサブ・セット上で遂行される
    通信機能に応答してトポロジデータを発生し、そして前
    記の第１のプロトコルに従ってのメッセージに応じて前
    記のトポロジデータを前記の第１のモニタリングノード
    上の前記の第１の手段へ送る手段、 前記の多数のスイッチングノードの中の第２のサブ・セ
    ット上で遂行される通信機能に応答してトポロジ・デー
    タを収集し、そして第４のプロトコルによるメッセージ
    に応じて、トポロジ・データを前記の第２のモニタリン
    グノード上の第１の手段へ送る手段、 前記の通信回路網に分布した各スイッチングノードに設
    けられ、それぞれのスイッチングノード上の警報状態の
    リストへ結合され、そして第２もしくは第４のプロトコ
    ールの少なくとも一つに従うメッセージに応答して、警
    報状態を指示するデータをパッケージして前記の第１も
    しくは第２のモニタリング手段の少なくとも一方の第２
    の手段へ送る手段 を備え、前記の多数の分布したスイッチングノードの第
    １と第２のサブ・セットからのデータは前記の通信回路
    網を通って第１のスイッチングノードもしくは第２のス
    イッチングノードへ通り、そして第１のスイッチングノ
    ードを通って前記の第１のモニタリング手段上の第２の
    手段へもしくは第２のスイッチングノードを通って前記
    の第２のモニタリング手段上の第２の手段へ通り、そし
    て 前記の情報収集・表示装置は、 前記の通信回路網に分布した各スイッチングノードに設
    けられ、それぞれのスイッチングノード上の構造のデー
    タベースへ結合され、そして第３もしくは第６のプロト
    コールの少なくとも一つに従うメッセージに応答して、
    スイッチングノードの構造のデータベースからのデータ
    をパッケージして前記の第１もしくは第２のモニタリン
    グ手段の少なくとも一方の第３の手段へ送る手段 を備え、前記の多数の分布したスイッチングノードの第
    １と第２のサブ・セットからのデータは前記の通信回路
    網を通って第１のスイッチングノードもしくは第２のス
    イッチングノードへ通り、そして第１のスイッチングノ
    ードを通って前記の第１のモニタリング手段上の第３の
    手段へもしくは第２のスイッチングノードを通って前記
    の第２のモニタリング手段上の第３の手段へ通る ことを特徴とした情報収集・表示装置。
15. 【請求項１５】多数のスイッチングノードが分布してい
    て、それぞれのスイッチングノードが通信機能を含むタ
    スクを遂行し、そのスイッチングノードのため事象記録
    を作表している事象ログを維持し、そしてそのスイッチ
    ングノードのため構造を特定する構造データベースを維
    持し、それらのスイッチングノードを相互にリンクで接
    続して成る通信回路網の状態に関する情報を集め、そし
    て表示する情報収集・表示装置において、 この情報収集・表示装置は、 第１のスイッチングノードに結合されたモニタ・ノード
    を備え、このモニタ・ノードは、 操作員入力インターフエース、 前記の通信回路網のトポロジを指示しているトポロジ・
    データを維持し、そして前記の第１のスイッチングノー
    ドとの第１のプロトコールを支持している第１の手段、 前記の通信回路網におけるスイッチングノードの事象ロ
    グに入れた事象記録のモニタリストを維持し、そして前
    記の多数の分布したスイッチングノードと前記の通信回
    路網を通して第２のプロトコルを支持する第２の手段、 前記の通信回路網におけるスイッチングノードの構造の
    データベースに入れたスイッチングノードの構造を指示
    するモニタデータベースを維持し、そして前記の多数の
    分布したスイッチングノードと前記の通信回路網を通し
    て第３のプロトコルを支持する第３の手段、そして 前記の通信回路網におけるあるスイッチングノードを特
    定する操作員入力に応答し、そしてモニタデータベー
    ス、事象記録のモニタリストそしてトポロジデータへ結
    合されて、当該スイッチングノードについての構造デー
    タ、通信回路網のトポロジそして事象記録を捜査員に表
    示する表示手段を備え、 前記の情報収集・表示装置は、 前記の第１のスイッチングノードに設けられ、多数のス
    イッチングノード上で遂行される通信機能に応答してト
    ポロジデータを発生し、そして前記の第１のプロトコル
    に従ってのメッセージに応じて前記のトポロジデータを
    前記の第１の手段へ送る手段、 前記の通信回路網に分布したそれぞれのスイッチングノ
    ードに設けられ、そのスイッチングノード上のスイッチ
    ングノード事象ログに結合されていて、前記の第２のプ
    ロトコルに従ってのメッセージに応じて、スイッチング
    ノードの事象ログに入れられた事象記録を指示するデー
    タをパッケージし、そして前記の第２の手段へ送る手段 を備え、前記の第１のスイッチングノードを除く各スイ
    ッチングノードからの前記のデータは前記の通信回路網
    を通して前記の第１のスイッチングノードへ、そして第
    １のスイッチングノードを通って前記の第２の手段へ通
    り、そして 前記の情報収集・表示装置は、 前記の通信回路網に分布したそれぞれのスイッチングノ
    ードに設けられ、そのスイッチングノード上のスイッチ
    ングノードの構造に結合され、そして前記の第３のプロ
    トコルに従ってのメッセージに応じて、スイッチングノ
    ードの構造のデータベースからのデータをパッケージ
    し、そして前記の第３の手段へ送る手段 を備え、前記の第１のスイッチングノードを除く各スイ
    ッチングノードからの前記のデータは前記の通信回路網
    を通して前記の第１のスイッチングノードへ、そして第
    １のスイッチングノードを通って前記の第３の手段へ通
    ることを特徴とした通信回路網の状態に関する情報収集
    ・表示装置。
16. 【請求項１６】少なくとも一つのスイッチングノードが
    複数の処理ユニットを備え、そのスイッチングノードで
    遂行されているタスクが前記の複数の処理ユニットを介
    して分布し、そしてスイッチングノードの事象ログを保
    持するタスクと、そのスイッチングノード上のスイッチ
    ングノードの事象に結合されていて、前記の第２のプロ
    トコルに応答して、スイッチングノード事象ログに入れ
    られた事象記録を指示するデータをパッケージし、そし
    て送る手段とが一つの処理ユニットで動いている請求項
    15に記載の通信回路網の状態に関する情報収集・表示装
    置。
17. 【請求項１７】前記の一つのスイッチングノード上の通
    信機能が前記の一つの処理ユニット以外の処理ユニット
    上で作動している請求項16に記載の通信回路網の状態に
    関する情報収集・表示装置。
18. 【請求項１８】スイッチングノードの事象ログがそのス
    イッチングノードのため警報状態のスイッチングノード
    のリストを含んでおり、更に モニタノード上にあって、通信回路網における警報状態
    のスイッチングノードリストに入れられた警報状態のモ
    ニタ・リストを保持し、そして多数の分布スイッチング
    ノードとの第４のプロトコルを通信回路網を通して支持
    する第４の手段、そして 各スイッチングノード上にあって、スイッチングノード
    上の事象ログ内の警報状態のスイッチングノードリスト
    に結合しており、そして第４のプロトコルに従うメッセ
    ージに応じて、スイッチングノードの事象ログに入れら
    れた警報状態を指示するデータをパッケージして前記の
    第４の手段へ送る手段 を備え、前記の第１のスイッチングノードを除く各スイ
    ッチングノードが、前記の通信回路網を通して前記の第
    １のスイッチングノードへ、そして前記の第１のスイッ
    チングノードを通して前記の第４の手段へ警報状態を示
    す前記のデータを送る請求項15に記載の通信回路網の状
    態に関する情報収集・表示装置。
19. 【請求項１９】表示手段は、表示モニタとこの表示モニ
    タ上に複数の表示ウインドウを発生する図形処理手段と
    を備え、そしてこれらの表示ウインドウの中の第１のウ
    インドウは回路網トポロジを図形表示し、第２のウイン
    ドウは対象としたノードについての構造データを図形表
    示し、そして第３のウインドウは警報状態のモニタ・リ
    ストを図形表示する請求項18に記載の通信回路網の状態
    に関する情報収集・表示装置。
20. 【請求項２０】前記の図形処理手段は、前記の第２の手
    段が保持している警報状態のモニタ・リストにおける少
    なくとも一つの警報状態に応答して前記の第１のウイン
    ドウに表示された回路網トポロジに強い光をあてて目立
    たさせる手段を含んでいる請求項19に記載の通信回路網
    の状態に関する情報収集・表示装置。
21. 【請求項２１】通信回路網に分散している各スイッチン
    グノード上にあって、スイッチングノードの構造データ
    ベースから前記の第３の手段へデータをパッケジーして
    送る手段は、スイッチングノードの構造データベースに
    対する変化を検出する手段と、前記の第３のプロトコル
    に応答して、その検出した変化の少なくとも一部分を含
    むメッセージを発生する手段とを含んでいる請求項15に
    記載の通信回路網の状態に関する情報収集・表示装置。
22. 【請求項２２】スイッチングノードの構造データベース
    が複数のデータブロックと、各ブロックと関連したブロ
    ック検査合計とを含み、 前記のスイッチングノードの構造データベースに対する
    変化を検出する手段が、前記の第３プロトコルに応答し
    て、スイッチングノードの構造データベースのすべての
    ブロックの総計の検査合計を発生する手段と、いま発生
    した総計の検査合計を先に発生した総計の検査合計と比
    較してデータベースに対する変化を検出する手段とを含
    んでいる請求項21に記載の通信回路網の状態に関する情
    報収集・表示装置。
23. 【請求項２３】各スイッチングノード上にあって、スイ
    ッチングノードのリストに入れられた警報状態を指示す
    るデータをパッケージして前記の第４の手段へ送る手段
    が、スイッチングノードの事象ログに入れられた警報状
    態を検出する手段と、第４のプロトコルに応答して、警
    報状態の少なくとも一部分を含むメッセージを発生する
    手段とを含んでいる請求項18に記載の通信回路網の状態
    に関する情報収集・表示装置。
24. 【請求項２４】スイッチングノードのリストは、警報表
    とこの警報表における警報状態の数を指示する、警報表
    に関連した数指示器を含み、そして前記の警報状態を検
    出する手段は、いま発生した数表示を先に発生した数表
    示と比較して警報表に対する変化を検出する手段を含ん
    でいる請求項23に記載の通信回路網の状態に関する情報
    収集・表示装置。
25. 【請求項２５】各スイッチングノード上にあって、スイ
    ッチングノードの事象ログに入れられた事象記録を指示
    するデータをパッケージして前記の第２の手段へ送る手
    段が、スイッチングノードの事象ログに入れられた事象
    記録を検出する手段と、第２のプロトコルに応答して、
    事象記録の少なくとも一部分を含むメッセージを発生す
    る手段とを含んでいる請求項15に記載の通信回路網の状
    態に関する情報収集・表示装置。
26. 【請求項２６】複数のスイッチングノードが複数の処理
    ユニットを備え、各スイッチングノードで遂行されてい
    るタスクが前記の複数の処理ユニットを介して分布し、
    そしてスイッチングノードの構造のデータベースを維持
    するタスクと、そのスイッチングノード上のスイッチン
    グノードの構造のデータベースに結合されていて、前記
    の第３のプロトコルに応答して、スイッチングノードの
    構造のデータベースからのデータをパッケージし、そし
    て送る手段とが一つの処理ユニットで動いている請求項
    15に記載の通信回路網の状態に関する情報収集・表示装
    置。
27. 【請求項２７】一つのスイッチングノード上での通信機
    能が前記の一つの処理ユニットを除く処理ユニットで動
    いている請求項26に記載の通信回路網の状態に関する情
    報収集・表示装置。