JP3074027B2

JP3074027B2 - 伝送装置監視方式

Info

Publication number: JP3074027B2
Application number: JP03049993A
Authority: JP
Inventors: 康雄藤井
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 1991-03-15
Filing date: 1991-03-15
Publication date: 2000-08-07
Anticipated expiration: 2015-08-07
Also published as: JPH04286250A

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は多数の伝送装置を集中し
て監視する集中監視方式のアーキテクチャに関し、特に
カレントテーブル及びヒストリテーブルを効率よく作成
するようにした伝送装置監視方式に関する。

【０００２】近年、保守作業の効率化のために、遠隔に
点在する多数の伝送装置を一ヶ所で集中して監視する集
中監視装置を核とした集中監視方式の要求が増大してい
る。集中監視装置は高度な処理を実現するためにミニコ
ンピュータあるいはワークステーションを使用してい
る。

【０００３】ミニコンピュータあるいはワークステーシ
ョンは高機能なヒューマン・インタフェース・デバイス
をもつため、監視結果の表示は従来のＬＥＤによる監視
と比べ、障害名称や障害の発生した伝送装置、障害の発
生した系統を表示する等の高度な表示機能が可能になっ
ている。さらに、障害の統計処理を行う等、監視結果の
管理も重要な課題で、従来のログと呼ばれる障害データ
よりも高度なヒストリデータが必要とされる。

【０００４】

【従来の技術】集中監視装置と監視される伝送装置は専
用の通信回線によって接続され、障害データを送る。障
害データは、伝送装置の現在の状態を示す現状データ
と、前回伝送装置が集中監視装置に通知してからの変化
分のみを示すイベントデータの二種類がある。この障害
データを電文として受け、障害情報の収集及び管理を行
っている。なお、以下の説明では集中監視装置をＣＳ
Ｖ、伝送装置をＮＥ（Ｎｅｔｗｏｒｋｅｌｅｍｅｎ
ｔ）と称する。また、ＮＥからの情報の流れは、ＮＥか
ら監視装置の一種であるＳＶを経由して、統括的な監視
装置であるＸＳＶに集められ、さらにＣＳＶに送られ
て、障害データの収集、管理、表示が行われる。ここで
は、説明を簡単にするために、電文の流れをＸＳＶとＣ
ＳＶの流れとして説明する。すなわち、ＸＳＶは各ＮＥ
からの電文を、ＳＶを経由して集め、これをＣＳＶに送
るが、もっぱらＸＳＶからＣＳＶに電文を送ることで、
ＮＥ，ＳＶ，ＣＳＶの電文の流れは、特別の場合を除い
て省略する。このような障害データの収集では、以下の
ような時間的な経過を有する場合がある。

【０００５】第１は先にＸＳＶ側が立ち上がり、ＣＳＶ
側が後から立ち上がる場合である。第２は逆にＣＳＶ側
が先に立ち上がり、後からＸＳＶ側が立ち上がる場合で
ある。第３はＸＳＶ側が立ち上がり、途中で立ち下が
り、再度立ち上がる場合である。以下これらの３つケー
スに分けて、ＸＳＶとＣＳＶとの障害データの流れを説
明する。勿論、ここでＸＳＶ側の立ち上がりというの
は、ＸＳＶ，ＳＶ及びＮＥの立ち上がりも含む。

【０００６】図１３はＣＳＶ側が後から立ち上がった場
合のタイムチャートである。ＣＳＶ７０内には時刻毎の
障害内容を示すカレントテーブル７４と、各障害の履歴
を記録するヒストリデータ７５がある。実際にはＮＥは
数千〜数万の台数になり、障害の内容も相当数になる
が、ここでは説明を簡単にするために、障害をＡ，Ｂ，
Ｃの３種類として説明する。また、ヒストリデータ７５
も多数の障害データからなるが、ここでは障害Ａ，Ｂ，
Ｃについての障害データのみとする。

【０００７】まず、ＸＳＶ６０側が先に立ち上がり、時
刻ｔ０に障害Ａが発生し、時刻ｔ１で回復している。ま
た、時刻ｔ２で障害Ｂが発生している。この間、ＣＳＶ
７０側は立ち上がっていないので、これらの障害データ
はＸＳＶ６０のバッファメモリにＳＶからの障害データ
をバッファリングする。

【０００８】次に、ＣＳＶ７０側が立ち上がると、カレ
ントテーブル７４の内容をすべてクリア（回復）して、
ＸＳＶ６０に対して、現状データ要求コマンドを発行
し、現状データ要求を行う。ＸＣＶ６０側は現状データ
要求に対して、現在の状態（ｔ２：Ｂのみ発生、ＡとＣ
は回復）を表す現状データ８１をＣＳＶ７０側に通知す
る。ＣＳＶ７０は現状データ８１をもとに、カレントテ
ーブル７４を作成し、障害Ｂのヒストリデータ８４を作
成する。ついで、ＸＳＶ６０側はバッファリングされて
いたイベントデータ８２をＣＳＶ７０側に通知する。Ｃ
ＳＶ７０側はイベントデータ８２をもとに、カレントテ
ーブル７４の障害Ａを一旦発生させ、回復させる。ま
た、障害Ｂを再度発生させる。これらの変化を、カレン
トテーブル７４上に８３で示す。ついで、この障害Ａの
発生、回復に対応するヒストリデータ８５、障害Ｂのヒ
ストリデータ８６を作成する。

【０００９】ここで、問題になるのは、障害Ｂのヒスト
リデータが８４、８６と２回重複して作成されてしまう
ことである。また、実際にはＮＥの台数が多いので、バ
ッファリングされたイベントデータが大きく、ＣＳＶ７
０側の立ち上げに相当の時間がかかる。

【００１０】図１４はＸＳＶ側が後から立ち上がった場
合のタイムチャートである。まず、ＣＳＶ７０側が立ち
上がると、カレントテーブル７４の内容の全項目を回復
（クリア）して、ＸＳＶ６０側との回線リンクの確立を
待つ。次にＸＳＶ６０側が立ち上がり、時刻ｔ０に障害
Ａ及びＢが発生する。ＣＳＶ７０側からＸＳＶ６０側へ
現状データ要求コマンドを発行し、現状データを要求す
る。これに対して、ＸＳＶ６０側は各ＮＥの状態を示す
現状データ９１（時刻ｔ０，Ａ：発生，Ｂ：発生，Ｃ：
回復）をＣＳＶ７０側に通知する。ＣＳＶ７０側は現状
データ９１をもとに、カレントテーブル７４を作成し、
発生のあった障害Ａ，Ｂのヒストリデータ９３，９４を
作成する。時刻ｔ１に障害Ａが回復し、ＸＳＶ６０側は
回復をイベントデータ９２によって、ＣＳＶ７０側に通
知する。ＣＳＶ７０側はイベントデータ９２によって、
カレントテーブル７４の項目Ａを回復し、ヒストリデー
タ９３の回復時刻にｔ１を書き込む。

【００１１】ここで、ＣＳＶ７０側はカレントテーブル
７４の内容をクリアするが、実際にはＸＳＶ６０側との
リンクが成立していない間は各ＮＥの状態は不定であ
る。従って、この間ＣＳＶ７０側の表示装置に回復状態
を表示することは現実のＮＥの状態を表していないこと
になる。特に、ＣＳＶ７０側のデータベースに登録され
ているＮＥが実際に可動状態にない場合（対応するボー
ドが抜かれている場合）には、通信リンクが確立した後
も、可動状態にないことがＣＳＶ７０側に通知されな
ず、正常な状態で運転されているように解釈される。

【００１２】図１５は一度立ち上がったＸＳＶ６０側が
一旦立ち下がり、再度立ち上げした場合のタイムチャー
トである。最初にＣＳＶ７０側が立ち上がり、次にＸＳ
Ｖ６０側が立ち上がり、このときの現状データ１０１に
よって、ＣＳＶ７０側はカレントテーブル７４を作成
し、同時にヒストリデータ１０３、１０４を作成する。
次に、一旦ＸＳＶ６０側が立ち下がり、再度立ち上が
る。このときに、ＸＳＶ６０側は現状データ１０２（時
刻ｔ１，障害Ａ，Ｂが発生、障害Ｃは回復）を送る。Ｃ
ＳＶ７０側は現状データ１０２によって、再度ヒストリ
データ１０５、１０６を作成する。

【００１３】ここで、再度ヒストリデータが重複して作
成されてしまう。このようなことを避けるために、ヒス
トリデータ７５のすべてについて、同一の障害データが
ないかどうかサーチしてチェックすることも理論的に可
能であるが、現実にはヒストリデータ７５は相当大きな
容量を有し、全ての現状データ毎にヒストリデータ７５
をチェックすることは、サーチ時間が大きくなり、現実
の使用には向かない。

【００１４】

【発明が解決しようとする課題】上記に説明したよう
に、図１３、図１４、図１５のいずれの場合も従来の伝
送装置監視方式では問題がある。

【００１５】まず、図１３で説明したように、ＣＳＶ７
０側の立ち上げ時に、ＸＳＶ６０側にバッファリングさ
れたていたイベントデータ８２がＣＳＶ７０側に通知さ
れるが、その都度カレントテーブル７４を更新するの
で、現在の監視上は必要のない過去の障害情報処理のた
めに、カレントテーブル７５が変化し、ＣＳＶ７０側の
表示装置の障害表示画面が過去の障害変化を表示し、さ
らに、多数のＮＥの大量のバッファリングデータを処理
するために、多大な時間を必要とする。このため、ＣＳ
Ｖ７０側が実質的な監視業務を開始するまでに、長時間
を必要とした。すなわち、ＣＳＶ７０側の立ち上がり時
間が遅かった。

【００１６】また、図１３に示したように、現状データ
８１とバッファリングされていたイベントデータ８２が
通知されるので、同一の障害Ｂがヒストリデータ７５に
８４，８６として重複して作成されるという問題もあ
る。

【００１７】さらに、図１４で説明したように、ＣＳＶ
７０側は立ち上げ時にカレントテーブル７４の内容をク
リアするが、実際にはＸＳＶ６０側とのリンクが成立し
ていない間は各ＮＥの状態は不定である。従って、この
間ＣＳＶ７０側の表示装置に回復状態を表示することは
現実のＮＥの状態を表していないことになる。特に、Ｃ
ＳＶ７０側のデータベースに登録されているＮＥが実際
に可動状態にない場合（対応するボードが抜かれている
場合）には、通信リンクが確立した後も、可動状態にな
いことがＣＳＶ７０側に通知されず、回復状態、すなわ
ち正常な状態で運転されているように解釈される。

【００１８】また、再度ヒストリデータが重複して作成
されてしまう。このようなことを避けるために、ヒスト
リデータ７５のすべてについて、同一データがないかど
うかサーチしてチェックすることも理論的に可能である
が、現実にはヒストリデータ７５は相当大きな容量を有
し、サーチ時間が大きくなり、現実の使用には向かな
い。

【００１９】本発明はこのような点に鑑みてなされたも
のであり、集中監視装置の処理を効率化した伝送装置監
視方式を提供することを第１の目的とする。また、本発
明の第２の目的は集中監視装置の立ち上げ時間を短縮し
た伝送装置監視方式を提供することである。

【００２０】さらに、本発明の第３の目的は集中監視装
置の立ち上げ時に各伝送装置の状態を正確に認識できる
伝送装置監視方式を提供することである。また、本発明
の第４の目的は伝送装置に過去の表示を行わせないよう
な伝送装置監視方式を提供することである。

【００２１】さらに、本発明の第５の目的は重複したヒ
ストリデータを作成しないようにした伝送装置監視方式
を提供することである。

【００２２】

【課題を解決するための手段】図１は本発明の伝送装置
監視方式を実施するための伝送装置監視システムの全体
構成図である。監視装置（ＸＳＶ）２０は各伝送装置
（ＮＥ）１，２，３の状態データを監視装置ＳＶ１１，
１２，１３を経由して、収集して集中監視装置（ＣＳ
Ｖ）３０に送る。状態データは現在の状況を示す現状デ
ータ（ＣＤ）２３、状態が変化（障害の発生、回復）し
たときのイベントデータ（ＩＤ）２４、バッファリング
された履歴データ（ＨＤ）２５を送る。ＣＳＶ３０はこ
れらのデータから、カレントテーブル作成部３２でカレ
ントテーブル３４、ヒストリデータ作成部３３でヒスト
リデータ３５を作成し、表示装置３７に各伝送装置１，
２，３の状況を表示する。また、ヒストリデータ３５に
よって、各伝送装置の障害履歴を管理する。

【００２３】また、監視装置（ＸＳＶ）２０が最初のイ
ベントデータ２４を履歴データ２５として集中監視装置
３０に送る。さらに、集中監視装置３０は立ち上げ時に
カレントテーブル３４の各伝送装置１，２，３に対応す
るデータを未確認状態にする。

【００２４】また、履歴データ２５が集中監視装置３０
に送られたときは、カレントテーブル３４の更新は行わ
ないようにする。さらに、集中監視装置３０に現状デー
タ２３が送られたとき、現状データ２３がカレントテー
ブル３４の内容と異なる場合にカレントテーブル３４を
更新する。

【００２５】そして、集中監視装置３０に現状データ２
３が送られたとき、現状データ２３がカレントテーブル
３４の内容と異なる場合にデータをヒストリデータ作成
部３３に送りヒストリデータ３５を作成する。

【００２６】また、集中監視装置３０は、データが履歴
データ２５のときは、前記ヒストリデータに同一の障害
データがないか調べて、ない場合に新しくヒストリデー
タを作成する。

【００２７】また、集中監視装置３０は、データが回復
の場合は、ヒストリデータ３５の前記回復に対応する発
生データを調べて、回復時刻を書き込む。さらに、ヒス
トリデータ３５は個々の障害Ａ，Ｂ，Ｃ毎に、少なくと
も障害の属性、障害の名称、障害の発生時刻、障害の回
復時刻を含める。

【００２８】

【作用】監視装置２０はデータを現状データ２３、イベ
ントデータ２４、履歴データ２５に分けて障害データを
送ることにより、各データに応じてカレントテーブル３
４の更新、ヒストリデータ３５の作成を行う。これによ
って、データ処理が効率化され、集中監視装置３０の立
ち上げ時間の短縮、重複データの防止を可能にする。

【００２９】また、集中監視装置３０の立ち上げ時に最
初のイベントデータ２４を履歴データ２５として送るよ
うにすることにより、下位からのイベントデータを簡単
に履歴データ２５に変換できる。

【００３０】さらに、集中監視装置３０は立ち上げ時に
カレントテーブル３４の内容を全て未確認の状態にし、
監視装置２０からデータを受信して、各伝送装置１，
２，３の状態を確認し、カレントテーブル３４を書き替
え、障害のない場合に回復とする。これによって、未確
認の伝送装置の状況を回復と誤って表示することがなく
なる。従って、伝送装置１，２，３の状態は、未確認状
態、障害発生状態、障害回復状態となる。さらに、各伝
送装置１，２，３のみでなく、これらを接続するルート
も各状態を表示することにより、ネットワークの稼働状
態を正確に認識できる。

【００３１】また、履歴データ２５が送られたときは、
カレントテーブル３４を更新しないことにより、集中監
視装置３０の立ち上げ時の表示装置３７に表示される内
容が過去の障害によって乱されず、集中監視装置３０の
立ち上げ時間も短縮される。

【００３２】さらに、現状データ２３が送られたとき
に、カレントテーブル３４の対応するデータと比較し、
異なる場合のみ更新することにより、カレントテーブル
３４の更新を行わずにすむ。

【００３３】そして、現状データ２３とカレントテーブ
ル３４の内容が異なる場合のみヒストリデータ３５の作
成を行うことにより、ヒストリデータ３５内の障害デー
タの重複作成を避けることができる。

【００３４】また、履歴データ２５を受信したときのみ
に、同一の障害が発生していないかヒストリデータ３５
をチェックするので、ヒストリデータの重複を避けるこ
とができ、チェックも履歴データ２５を受けた場合のみ
であるので、効率よくチェックを行うことができる。

【００３５】また、集中監視装置３０は、データが回復
のときは、ヒストリデータ３５の対応する発生を調べ
て、回復時刻を書き込むので、ヒストリデータ３５は障
害毎のデータが作成できる。

【００３６】さらに、ヒストリデータ３５内の個々のデ
ータを障害属性、障害発生時刻、回復時刻等を含めるこ
とにより、ヒストリデータ３５によって、伝送装置１，
２，３の障害管理を正確に行うことができる。

【００３７】

【実施例】以下、本発明の実施例を図面に従って説明す
る。図１は本発明の伝送装置監視方式を実施するための
伝送装置監視システムの全体構成図である。一般の伝送
装置システムでは、多数の端局中継装置、中継装置等の
伝送装置を有する。ここでは、これらの伝送装置をＮＥ
（ＮｅｔｗｏｒｋＥｌｅｍｅｎｔ）と称する。説明を
簡単にするために、ＮＥ１，２，３の３台で説明する。
各ＮＥは監視装置ＳＶ１１，１２，１３によって監視さ
れ、その状況データはより高位の監視装置（ＸＳＶ）２
０に集められる。実際には監視装置は何重もの階層構造
になっているが、ここではＳＶ１１，１２，１３がＸＳ
Ｖ２０に接続されていることで説明する。各ＳＶ１１，
１２，１３はＸＳＶ２０のＳＶ通信部２１に接続され、
データが伝送される。各ＳＶ１１，１２，１３とＸＳＶ
２０の間の通信はＨＤＬＣ（Ｈｉｇｈ−ｌｅｖｅｌＤ
ａｔａＬｉｎｋＣｏｎｔｒｏｌｐｒｏｃｅｄｕｒ
ｅ）によって行われる。

【００３８】ＳＶ通信部２１では監視装置１１，１２，
１３からの監視データをそれぞれ、現状データ（ＣＤ）
２３，イベントデータ（ＩＤ）２４，履歴データ（Ｈ
Ｄ）２５に分けバッファメモリ２２に格納する。これら
のデータの詳細については後述する。現状データ要求フ
ラグ２７は後述の集中監視装置（ＳＣＶ）３０からデー
タを要求されるときに書き込まれるフラグである。これ
らのデータは電文としてＣＳＶ通信部２６を経由して、
集中監視装置（ＣＳＶ）３０に送られる。

【００３９】ＣＳＶ３０ではＸＳＶ通信部３１を経由し
て、各データを受信する。ＸＳＶ２０とＣＳＶ３０の間
の通信はＨＤＬＣのＡＢＭ（Ａｓｙｎｃｒｏｎｏｕｓ
ＢａｌａｎｃｅｄＭｏｄｅ）で行われる。各データは
カレントテーブル作成部３２でカレントテーブル３４を
作成する。また、ヒストリデータ作成部３３でヒストリ
データ３５を作成する。カレントテーブル３４とヒスト
リデータ３５の作成の詳細については後述する。カレン
トテーブル３４、ヒストリデータ３５は表示制御部３６
で必要に応じて、表示信号に変換され、表示装置３７に
表示される。

【００４０】次に、ＸＳＶ２０とＣＳＶ３０との電文の
フレーム構成について説明する。図２は電文のデータフ
レーム構成を示す図である。データフレーム４０は識別
子（ＩＤ）４１，データ長（Ｌ）４２，データ（ＤＡＴ
Ａ）４３から構成されている。ＩＤ４１は電文の種別を
表すもので、１バイトのコードで表され、以下の意味を
有する。

【００４１】Ｃ１又はＥ１：データが現状データであるＥ３：データが履歴データであるＣ２又はＥ２：データがイベントデータであるデータ長（Ｌ）４２はデータ（ＤＡＴＡ）４３のデータ
長を表す。データ（ＤＡＴＡ）４３の内容は障害等の情
報を意味する。

【００４２】現状データ２３はＣＳＶ３０あるいはＸＳ
Ｖ２０の立ち上げ時に、ＣＳＶ３０から現状データ要求
コマンドを発行して、ＸＳＶ２０から現状データを受け
取る。また、ＳＶ１１〜１３及びＮＥ１〜３が立ち上が
った場合は、その時の状態を現状データとして上位（例
えばＸＳＶ２０）に通知する。このとき上位のＸＳＶ２
０からＳＶ１１〜１３には現状データ要求コマンドは発
行されない。また、イベントデータは個々の障害の発
生、回復をその都度伝送するデータである。

【００４３】履歴データはＣＳＶ３０の立ち上がり時間
の短縮と、ＣＳＶ３０内のヒストリデータ３５の作成時
の問題を解決するために必要なデータであり、ＸＳＶ２
０とＣＳＶ３０の間のみ存在し、障害やヒストリデータ
を表示する機能を有しないＳＶ１１〜１３では存在しな
い。

【００４４】次にＸＳＶ２０のＳＶ通信部２１の処理に
ついて説明する。図３はＳＶ通信部のフローチャートで
ある。図において、Ｓに続く数値はステップ番号を示
す。〔Ｓ１〕下位（ＳＶ１１〜１３）との通信リンクを確立
する。〔Ｓ２〕下位に現状データ要求コマンドを送信する。〔Ｓ３〕ＣＳＶ３０からの現状データ要求フラグ２７が
オンか調べ、オンならＳ４へ、オフならＳ５へ進む。〔Ｓ４〕ＳＶ（１１〜１３）への現状データコマンドを
送信し、現状データ要求フラグ２７をオフにする。〔Ｓ５〕下位からのデータを受信するまで待つ。〔Ｓ６〕下位からの電文を調べ、現状データを表す現状
電文ならＳ７へ、イベントデータを表すイベント電文な
らＳ８へ進む。〔Ｓ７〕電文が現状電文であるので、現状電文キューに
受信した電文をキューイングする。これによって、個々
に送られてきた現状データをチェーン状に結合して、将
来ＣＳＶ３０に送る。〔Ｓ８〕電文がイベント電文であるので、イベント電文
キューに受信した電文をキューイングする。これによっ
て、個々に送られてきたイベントデータをチェーン状に
結合して、将来ＣＳＶ３０に送る。

【００４５】これらのＳ７、Ｓ８でキューイングされた
電文は現状データ（ＣＤ）２３あるいはイベントデータ
（ＩＤ）２４として、ＣＳＶ３０からデータ要求コマン
ドがあったとき（Ｓ３）、ＣＳＶ３０に送られる（Ｓ
４）。

【００４６】次に、ＸＳＶ２０におけるＣＳＶ通信部２
６の処理について説明する。図４及び図５はＣＳＶ通信
部２６の処理のフローチャートである。〔Ｓ１１〕ＣＳＶ３０との回線リンクを確立する。〔Ｓ１２〕ＣＳＶ３０から現状データ要求があるか調
べ、有ればＳ１３へ、なければＳ１６（図５）へ進む。〔Ｓ１３〕現状データ要求があるので、現状データ要求
フラグ２７をオンして、現状キューを削除する。〔Ｓ１４〕イベント電文キューの先頭を履歴キューに移
す。すなわち、最初のイベント電文は履歴データである
ので、履歴データを送るための準備を行う。〔Ｓ１５〕履歴キューの履歴データ２５を履歴電文とし
てＣＳＶ３０に送信する。図５へ進み、〔Ｓ１６〕現状データキューがあるか調べ、あればＳ１
７へ、なければＳ１８へ進む。〔Ｓ１７〕現状キューの現状データ２３を現状電文とし
てＣＳＶ３０に送信する。〔Ｓ１８〕イベントキューがあるか調べ、あればＳ１９
に進み、なければＳ１２に戻り処理を続行する。〔Ｓ１９〕イベントキューのイベントデータをイベント
電文としてＣＳＶ３０に送信する。

【００４７】ついで、ＣＳＶ３０のＸＳＶ通信部３１の
処理について説明する。図６はＸＳＶ通信部の処理のフ
ローチャートである。〔Ｓ２１〕ＸＳＶ２０との回線のリンクを確立する。〔Ｓ２２〕現状データ要求コマンドを送る。〔Ｓ２３〕ＸＳＶ２０からのデータ（現状データ、イベ
ントデータ、履歴データ）の送信を待つ。〔Ｓ２４〕データが送信されたら、そのデータをカレン
トテーブル作成部３２に送る。

【００４８】次に、カレントテーブル作成部３２の処理
について述べる。図７はカレントテーブル３２の処理フ
ローチャートである。〔Ｓ３１〕まず、最初は各ＮＥ１，２，３に関するデー
タはなにもないので、全てのカレントテーブルを未確認
状態にする。これによって、ＮＥは現状データが送信さ
れるまでは未確認状態となり、その状態が表示装置３７
に表示される。〔Ｓ３２〕ＸＳＶ２０のＣＳＶ通信部２６から受信電文
を受信する。〔Ｓ３３〕電文の内容を調べ、イベント電文ならＳ３４
へ、履歴電文ならＳ３７へ、現状電文ならＳ３５へ進
む。〔Ｓ３４〕電文がイベント電文であるので、カレントテ
ーブル３４を更新する。〔Ｓ３５〕電文の内容が現状電文であるので、カレント
テーブル３４と比較し、一致しなければＳ３６へ進む。
一致すればＳ３２へ戻り処理を続行し、このときにヒス
トリデータ作成部３３にデータは送らない。すなわち、
これはＸＳＶ２０が再立ち上げしたときに、ヒストリデ
ータの重複を避けるためである。また、カレントテーブ
ル３４と現状電文と同じであるので、カレントテーブル
３４の書き換えは行わないので、表示装置３７での無駄
な変化がない。〔Ｓ３６〕カレントテーブル３４の内容と一致しないの
で、現状が変化しており、カレントテーブル３４を更新
する。〔Ｓ３７〕必要に応じて、ヒストリデータ作成部３３に
ヒストリデータ３５の作成を依頼する。ヒストリデータ
作成部３３の処理は次に述べる。

【００４９】図８はヒストリデータ作成部の処理のフロ
ーチャートである。〔Ｓ４１〕カレントテーブル作成部３２から電文を受け
取る。〔Ｓ４２〕電文の種類を調べ、履歴電文ならＳ４３へ、
それ以外の電文ならＳ４７へ進む。〔Ｓ４３〕障害の回復か、発生かを調べ発生ならＳ４４
へ、回復ならＳ４８へ進む。〔Ｓ４４〕／〔Ｓ４５〕ヒストリデータ３５について、
同一の障害の発生があるか調べなければＳ４６へ、あれ
ばＳ４１に戻り処理を続行する。これによって、重複し
たヒストリデータの作成を避けることができる。また、
ヒストリデータ３５をチェックするのは履歴データの場
合のみであるので、処理が効率化できる。〔Ｓ４７〕履歴電文以外の電文であり、発生か回復か調
べ、回復ならＳ４８へ進み、発生ならＳ４６へ進みあら
たなヒストリデータを作成する。〔Ｓ４８〕／〔Ｓ４９〕回復であるので、ヒストリデー
タ３５の最後まで、回復に対応する発生をサーチする。
そして発生があればＳ５０へ進み、なければＳ４１へ戻
り、処理を続行する。〔Ｓ５０〕回復に対応する発生が発見されたので、その
障害の回復時刻を書き込む。

【００５０】次にヒストリデータの詳細について述べ
る。図９はヒストリデータの一個の内容を示す図であ
る。ヒストリデータ３５はこのようなデータが、多数ハ
ードディスクあるいはフロッピィディスク等の不揮発性
メモリに格納されている。

【００５１】障害の属性は障害内容を示すもので、重要
なアラームか、重要でないアラームか、リスポンスアラ
ーム等の種別を意味する。障害等の名称は障害の名称、
障害の識別コードがある。障害が発生した装置名称は実
際の障害の発生した伝送装置名あるいはその識別コード
を意味する。障害が発生した装置の場所は障害が発生し
た伝送装置の局名称、ルート名称等が記載される。障害
が発生した装置のアドレスは障害の発生した伝送装置の
ＨＤＬＣ上のアドレスが表される。その他に、障害の発
生時刻、回復時刻、発生継続時間がある。

【００５２】次に本実施例の動作についせ説明する。図
１０はＣＳＶ３０側が後から立ち上げた場合のタイムチ
ャートである。ここでは説明を簡単にするために、障害
をＡ，Ｂ，Ｃの３種類として説明する。まず、ＸＳＶ２
０側が先に立ち上がり、この間に時刻ｔ０に障害Ａが発
生し、時刻ｔ１で回復している。また、時刻ｔ２で障害
Ｂが発生している。この間、ＣＳＶ３０側は立ち上がっ
ていないので、ＸＳＶ２０のバッファメモリ２２にデー
タをバッファリングする。

【００５３】次にＣＳＶ３０側が立ち上がると、カレン
トテーブル３４の内容をすべて未確認状態にして、ＸＳ
Ｖ２０に対して、現状データ要求コマンドを発行して、
現状データを要求する。ＸＳＶ２０側は現状データの要
求に対して、現在の状態（Ａ：回復，Ｂ：発生，Ｃ：回
復）を表す現状データ２３ａをＣＳＶ３０側に通知す
る。ＣＳＶ３０は現状データ２３ａをもとに、カレント
テーブル３４を作成し、発生のあった障害Ｂのヒストリ
データ３５ａを作成する。ついで、ＸＳＶ２０側はバッ
ファリングされていたデータを履歴データ２５ａとし
て、ＣＳＶ３０に送る。ＣＳＶ３０は履歴データ２５ａ
に対しては、カレントテーブル３４の更新は行わず、障
害Ａの発生、回復のヒストリデータ３５ｂを作成する。
障害Ｂの発生は現にヒストリデータ３５中にヒストリデ
ータ３５ａとして存在するので、作成されない。

【００５４】ここで、図１３の場合と比較すると、図１
３の場合は障害Ｂのヒストリデータが８４、８６と２回
重複して現れるが、図１０の場合はこのようなことがな
い。また、バッファリングされたデータは履歴データ２
５ａとして処理され、カレントテーブル３４は更新され
ず、このための処理は不要となり、ＣＳＶ３０側の立ち
上げ時間が短縮される。

【００５５】ついで、ＸＳＶ２０側が後から立ち上がっ
た場合の動作について説明する。図１１はＸＳＶ２０側
が後から立ち上がった場合のタイムチャートである。ま
ず、ＣＳＶ３０側が立ち上がると、カレントテーブル３
４の内容の全項目を未確認状態にして、ＸＳＶ２０側と
の回線リンクの確立を待つ。次にＸＳＶ２０側が立ち上
がり、時刻ｔ０に障害Ａ及びＢが発生する。ＣＳＶ３０
側からＸＳＶ２０側へ現状データが要求され、ＸＳＶ２
０側は各ＮＥの状態を示す現状データ２３ｃ（時刻ｔ
０，Ａ：発生，Ｂ：発生，Ｃ：回復）をＣＳＶ３０側に
送る。ＣＳＶ３０側は現状データ２３ｃをもとに、カレ
ントテーブル３４を作成し、発生のあった障害Ａ，Ｂの
ヒストリデータ３５ｃ，３５ｄを作成する。時刻ｔ１に
障害Ａが回復し、ＸＳＶ２０側は回復をイベントデータ
２４ｃよって、ＣＳＶ３０側に通知する。ＣＳＶ３０側
はイベントデータ２４ｃによって、カレントテーブル３
４の障害項目Ａを回復し、ヒストリデータ３５の障害Ａ
に対応する項目を調べ、ヒストリデータ３５ｃに回復時
刻をｔ１を書き込む。

【００５６】図１４と比較すると、図１４では立ち上げ
時にカレントテーブル７４の状態を回復（クリア）状態
にしている。すなわち、未確認のＮＥが回復、すなわち
正常に動作していると認識されてしまう。これに対し
て、図１１ではＣＳＶ３０側はカレントテーブル３４の
内容をクリアではなく、未確認としている。従って、未
確認の各ＮＥ１，２，３等は表示装置に未確認の状態を
表示する。例えば、正常なＮＥは青、障害の発生してい
るＮＥは赤、未確認のＮＥは灰色等で表示装置３７に表
示する。この結果、未確認のＮＥの状態が正常であると
表示されるようなことがなくなる。また、各ＮＥの状態
を表示すると同時に、各ＮＥが接続されるルートの状態
も同様に、３種類に分けて表示することができる。これ
によって、各ＮＥの状態と各ルートの運転状態も確実に
認識することができる。

【００５７】図１２は一度立ち上がったＸＳＶ２０側が
一旦立ち下がり、再度立ち上がる場合のタイムチャート
である。最初にＣＳＶ３０側が立ち上がり、次にＸＳＶ
２０側が立ち上がり、このときの現状データ２３ｄによ
って、ＣＳＶ３０側はカレントテーブル３４を作成し、
同時にヒストリデータ３５ｅ、３５ｆを作成する。次
に、一旦ＸＳＶ２０側が立ち下がり、再度立ち上がる。
このとき（時刻ｔ１）に、ＸＳＶ２０側は現状データ２
３ｅを送る。ＣＳＶ３０側は現状データ２３ｅとカレン
トテーブル３４を比較し、カレントテーブル３４の内容
と同じために、カレントテーブル３４の変更も行わない
し、ヒストリデータ３５の作成も行わない。

【００５８】従って、図１５の場合と比較すると、図１
５の場合は再立ち上げのとき、カレントテーブル７４が
書き換えられ、表示装置３７の表示もちらつく。また、
ヒストリデータ１０５，１０６が作成され、ヒストリデ
ータ１０３，１０４と重複する。これに対して、図１２
では現状データ２３ｅをカレントテーブル３４の内容と
比較し、違いがないときはカレントテーブル３４の変更
も行わないし、ヒストリデータ３５の作成も行わない。
従って、無駄にカレントテーブル３４が変更されて、表
示装置３７の画面がちらつくことがない。また、ヒスト
リデータが重複して作成されることもない。

【００５９】上記の説明では、各ＮＥ及び監視装置ＳＶ
は３台として説明したが、これは説明を簡単にするため
であり、実際は数十〜数百台のＮＥが結合され、監視装
置も下位の監視装置、上位の監視装置等の階層構造とし
て構成される。また、障害もＡ，Ｂ，Ｃの３個で説明し
たが、実際の障害は相当数になる。

【００６０】

【発明の効果】監視装置は集中監視装置にデータを現状
データ、イベントデータ、履歴データに分けて障害デー
タを送るようにしたので、各データに応じてカレントテ
ーブルの更新、ヒストリデータの作成ができ、データ処
理が効率化され、集中監視装置の立ち上げ時間の短縮、
重複データの防止が可能になる。

【００６１】また、集中監視装置の立ち上げ時に最初の
イベントデータを履歴データとして送るようにすること
により、下位からのイベントデータを簡単に履歴データ
に変換できる。

【００６２】さらに、集中監視装置は立ち上げ時にカレ
ントテーブルの内容を全て未確認の状態にし、監視装置
からデータを受信して、各伝送装置の状態を確認し、カ
レントテーブルを書き替えるようにしたので、未確認の
伝送装置の状況を回復と誤って表示することがなくな
る。

【００６３】また、履歴データが送られたときは、カレ
ントテーブルを更新しないことにより、集中監視装置の
立ち上げ時の表示装置に表示される内容が過去の障害に
よって乱されず、集中監視装置の立ち上げ時間も短縮さ
れる。

【００６４】さらに、現状データが送られたときに、カ
レントテーブルの対応するデータと比較し、異なる場合
のみ更新することにより、カレントテーブルの更新処理
が簡単になる。

【００６５】そして、現状データとカレントテーブルの
内容が異なる場合のみヒストリデータの作成を行うよう
にしたので、ヒストリデータの障害データの重複作成を
避けることができる。

【００６６】また、履歴データを受信したときのみに、
同一の障害が発生していないかヒストリデータをチェッ
クするようにしたので、ヒストリデータの重複作成を避
けることができ、チェックも履歴データを受けた場合の
みであるので、効率よくチェックを行うことができる。

【００６７】また、集中監視装置は、データが回復のと
きは、ヒストリデータの対応する発生を調べて、回復時
刻を書き込むようにしたので、ヒストリデータは障害毎
のデータが作成できる。

【００６８】さらに、ヒストリデータ内の個々のデータ
を障害属性、障害発生時刻、回復時刻等を含めるように
したので、ヒストリデータによって、伝送装置の障害管
理を正確に行うことができる。

【図面の簡単な説明】

【図１】本発明の伝送装置監視方式を実施するための伝
送装置監視システムの全体構成図である。

【図２】電文のデータフレーム構成を示す図である。

【図３】ＳＶ通信部の処理のフローチャートである。

【図４】ＣＳＶ通信部の処理のフローチャートである。

【図５】ＣＳＶ通信部の処理のフローチャートである。

【図６】ＸＳＶ通信部の処理のフローチャートである。

【図７】カレントテーブルの処理フローチャートであ
る。

【図８】ヒストリデータ作成部の処理のフローチャート
である。

【図９】ヒストリデータの構成を示す図である。

【図１０】ＣＳＶ側が後から立ち上がった場合のタイム
チャートである。

【図１１】ＸＳＶ側が後から立ち上がった場合のタイム
チャートである。

【図１２】ＸＳＶが再度立ち上がった場合のタイムチャ
ートである。

【図１３】ＣＳＶ側が後から立ち上がった場合のタイム
チャートである。

【図１４】ＣＳＶ側が先に立ち上がった場合のタイムチ
ャートである。

【図１５】ＸＳＶ側が再度立ち上がった場合のタイムチ
ャートである。

【符号の説明】

１〜３ＮＥ１１〜１３監視装置（ＳＶ）２０監視装置（ＸＳＶ）２１ＳＶ通信部２６ＣＳＶ通信部３０集中監視装置（ＣＳＶ）３１ＸＳＶ通信部３２カレントテーブル作成部３３ヒストリデータ作成部３４カレントテーブル３５ヒストリデータ３７表示装置

───────────────────────────────────────────────────── フロントページの続き (58)調査した分野(Int.Cl.⁷，ＤＢ名) H04L 29/14

Claims

(57)【特許請求の範囲】

【請求項１】伝送装置（１，２，３）と、前記伝送装
置（１，２，３）を監視する監視装置（２０）と、前記
監視装置（２０）を集中監視する集中監視装置（３０）
からなる伝送装置監視方式において、前記監視装置（２
０）は、前記伝送装置の現在の状態を表す現状データ
（２３）と、前記伝送装置（１，２，３）の状態が変化
したときのイベントデータ（２４）と、前記集中監視装
置（３０）が立ち上がる前の前記伝送装置（１，２，
３）の状態を表す履歴データ（２５）とを収集して、前
記集中監視装置（３０）に送り、前記集中監視装置（３
０）は前記現状データ（２３）、前記イベントデータ
（２４）、前記履歴データ（２５）を受信し、前記伝送
装置（１，２，３）の状態を表すカレントテーブル（３
４）を作成し、前記カレントテーブル（３４）のデータ
を必要に応じて前記集中監視装置（３０）の表示装置
（３７）に表示し、前記伝送装置（１，２，３）の障害
履歴を含むヒストリデータ（３５）を作成して、障害デ
ータの管理を行い、前記伝送装置（１，２，３）を集中
して監視することを特徴とする伝送装置監視方式。
【請求項２】前記集中監視装置（３０）の立ち上げ時
に、前記監視装置（２０）は（３０）が立ち上げ前に受
信した前記イベントデータ（２４）を履歴データ（２
５）として、前記集中監視装置（３０）に送ることを特
徴とする請求項１記載の伝送装置監視方式。
【請求項３】前記集中監視装置（３０）は、前記集中
監視装置（３０）の立ち上げ時に前記カレントテーブル
（３４）の前記伝送装置（１，２，３）の全てのデータ
を未確認状態にすることを特徴とする請求項１記載の伝
送装置監視方式。
【請求項４】前記集中監視装置（３０）は、前記履歴
データ（２５）が送られたときは、カレントテーブル
（３４）を更新しないようにしたことを特徴とする請求
項１記載の伝送装置監視方式。
【請求項５】前記集中監視装置（３０）は、前記現状
データ（２３）が送られたときは、前記カレントテーブ
ル（３４）の内容と比較して、前記現状データ（２３）
と異なるデータのみを更新することを特徴とする請求項
１記載の伝送装置監視方式。
【請求項６】前記集中監視装置（３０）は、前記現状
データ（２３）が送られたときは、前記カレントテーブ
ル（３４）の内容と比較して、前記現状データ（２３）
と異なるデータのみをヒストリデータ作成部（３３）に
送り、ヒストリデータ３５を作成することを特徴とする
請求項１記載の伝送装置監視方式。
【請求項７】前記集中監視装置（３０）は、前記監視
装置（２０）からのデータが履歴データ（２５）のとき
は、前記ヒストリデータ（３５）に同一の障害データが
ないか調べて、ない場合に新しくヒストリデータを作成
することを特徴とする請求項１記載の伝送装置監視方
式。
【請求項８】前記集中監視装置（３０）は、データが
回復の場合は、ヒストリデータ（３５）に前記回復に対
応する発生を調べて、回復時刻を書き込むことを特徴と
する請求項１記載の伝送装置監視方式。
【請求項９】前記ヒストリデータ（３５）は、少なく
とも前記伝送装置（１，２，３）の障害の属性、障害の
名称、障害の発生時刻、障害の回復時刻を障害毎にまと
めたデータとして有することを特徴とする請求項１記載
の伝送装置監視方式。