JP4015733B2 - 監視データ収集方式及びその装置 - Google Patents
監視データ収集方式及びその装置 Download PDFInfo
- Publication number
- JP4015733B2 JP4015733B2 JP00943198A JP943198A JP4015733B2 JP 4015733 B2 JP4015733 B2 JP 4015733B2 JP 00943198 A JP00943198 A JP 00943198A JP 943198 A JP943198 A JP 943198A JP 4015733 B2 JP4015733 B2 JP 4015733B2
- Authority
- JP
- Japan
- Prior art keywords
- monitoring
- notification
- monitored
- data
- frame
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Small-Scale Networks (AREA)
- Debugging And Monitoring (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は監視データ収集方式及びその装置に関し、更に詳しくは監視装置と複数の被監視装置とが相互に接続し、各被監視装置から監視装置に監視フレームを送信するシステムの監視データ収集方式及びその装置に関する。
例えば遠隔の複数のノード間でデータ通信を行うネットワークシステムでは、監視ノードと複数の被監視ノード（本来は通信制御を行う）とがバス，スター，リンク方式等により相互に接続すると共に、各被監視ノードから監視ノードに監視フレームを送信することを行う。また、例えば前記ノードを構成する通信装置では、架構成のシェルフ（スロット等）に搭載された監視用基板と複数の被監視用基板（本来は各種通信制御を行う）とがバス，スター，リンク方式等により相互に接続し、各被監視基板から監視基板に監視フレームを送信することを行う。本発明はこの様なシステム（ネットワーク，通信装置等）における監視データの収集制御に適用して好適なるものである。
【０００２】
【従来の技術】
図１４は従来のネットワーク監視方式の構成を示す図で、監視装置７０及び複数の被監視装置５０がバス型ネットワーク上に接続された場合のネットワーク監視方式の例を示している。
図において、５０は被監視装置（ノード）、５１はポーリング応答フレーム及び監視フレームの送信とポーリングフレームの受信とを行うフレーム送／受信部、５２は通知待ちの監視データを一時的に蓄積する待ちキュー部、５３は自装置内の監視データの収集及び待ちキュー部５３へのキューイングを行うプロトコル処理部、５４は本来のデータ通信制御を行うと共に該データ通信制御に関する監視データを収集（生成）する制御処理部、５５はその他の監視データを収集する監視処理部、７０は監視装置、７１はポーリングフレームの送信とポーリング応答フレーム及び監視フレームの受信とを行うフレーム送／受信部、７２は各被監視装置５０に対するポーリング処理を行うポーリング処理部、７３は各被監視装置５０からの監視フレームを分解・蓄積処理するフレーム蓄積処理部、７４は監視データを蓄積するフレーム管理バッファ、７５はフレーム管理バッファ７４の監視データを上位の監視装置９０に通知する監視通知部、９０は上位監視装置、８０は伝送路である。
【０００３】
監視装置７０は、各被監視装置５０を定期的にポーリングしており、各被監視装置５０からの応答有／無に基づき当該被監視装置５０が運用されているか否かを認識できる。なお、被監視装置５０が監視データの通知を停止している場合は無応答となる。
係るやり取りの下で、被監視装置５０では、制御処理部５４及び監視処理部５５から監視装置７０へ通知すべき監視データ（警報データ，状態変化通知に係るデータ等）がプロトコル処理部５３に渡される。プロトコル処理部５３はこれらの監視データを時間軸上にソートし、待ちキュー部５２にキューイングする。フレーム送／受信部５１は定期的に待ちキュー行列から１キュー情報をデキューし、かつネットワーク８０上に他キャリアが存在しないことを確認した後、監視装置７０に対して監視データのフレーム（監視フレーム）を送信する。
【０００４】
監視装置７０において、フレーム送／受信部７１は受信した監視フレームをフレーム蓄積処理部７３に渡し、フレーム蓄積処理部７３は該フレームを分解して上位監視装置９０へ通知するための監視情報単位にフレーム管理バッファ７４に格納する。一方、監視通知部７５は定期的にフレーム管理バッファ７４を検索し、該バッファ内の監視データを上位監視装置９０へ順次送信すると共に、送信完了後はフレーム管理バッファ７４から当該監視データを削除する。
【０００５】
従って、各被監視装置５０における監視データの量が通常であるような場合には、監視装置７０に対する通知及び監視装置７０における監視データの収集も適正に行われる。
【０００６】
【発明が解決しようとする課題】
しかし、１又は２以上の被監視装置５０において警報や状態変化が頻発すると、各被監視装置５０の待ちキュー数が増大すると共に、監視装置７０における監視データの蓄積量も大幅に増大し、最悪の場合は監視装置７０のフレーム管理バッファ７４がオーバフローし、全被監視装置５０からの通知が廃棄されてしまうこととなる。
【０００７】
そこで、従来は、被監視装置５０が自装置内の待ちキュー数に基づき監視装置７０への通知可／不可を自ら判定すると共に、被監視装置５０の待ちキュー数が所定閾値を越えると、仮に監視装置７０におけるフレーム管理バッファ７４の蓄積量に余裕があっても、被監視装置５０は監視データの通知を停止していた。
このため、監視装置７０では、その後にこの被監視装置５０から監視データを収集できない不都合があった。また、被監視装置５０からの通知が停止した場合は、保守者がその状況を判断し、別途に通知再開の処理を行う必要があり、作業が煩雑であった。
【０００８】
本発明は上記従来技術の問題点に鑑み成されたもので、その目的とする所は、監視データのトラフィック量が様々に変化する様な状況下にあっても、各被監視装置からの監視データを効率よく収集できる監視データ収集方式及びその装置を提供することにある。
【０００９】
【課題を解決するための手段】
上記の課題は例えば図１の構成により解決される。即ち、本発明（１）の監視データ収集方式は、監視装置３０と複数の被監視装置１０とが相互に接続し、各被監視装置＃１〜＃ｎから監視装置３０に監視フレームを送信するシステムの監視データ収集方式において、被監視装置（例えば＃２）は自装置内の通知待ち監視データが所定以上となったことにより該通知待ち監視データのデータ量に係る所定の情報を監視装置に通知し、監視装置３０は、前記通知された情報に基づき、かつ自身が当該被監視装置＃２に対して許容可能な蓄積データ量の範囲内で、当該被監視装置＃２の監視フレームを通知可能とするものである。
【００１０】
本発明（１）によれば、被監視装置＃２は自装置内の通知待ち監視データが所定以上となったことにより前記通知待ち監視データのデータ量に係る所定の情報を監視装置３０に通知するので、監視装置３０は被監視装置＃２が輻輳状態にあること及びその輻輳の程度（データ量に係る情報）を早期に明確に把握できる。
また、監視装置３０は、前記通知された情報に基づき、かつ自身が被監視装置＃２に対して許容可能な蓄積データ量の範囲内で、被監視装置＃２の監視フレームを通知可能とするので、他の輻輳中又は輻輳予定の被監視装置（例えば＃１等）に対して許容可能な蓄積データ量には何らの影響を与えることも無く、当該被監視装置＃２からの通知待ち監視データを効率よく収集できる。
【００１１】
好ましくは、本発明（２）においては、上記本発明（１）において、前記所定の情報は対応するデータ量を通知フレーム数又は通知点数に換算した情報である。一般に被監視装置は１フレームで複数の通知点（伝送路断，クロック異常，パッケージ異常等）の監視データを通知してくるため、この様に監視データの収集制御をフレーム単位又は通知点単位で管理すると、制御が容易となる上、多様な管理単位で制御できる。なお、上記所定の情報は対応するデータ量そのものであっても良いことは明らかである。
【００１２】
また本発明（３）の被監視装置は、監視装置と複数の被監視装置とが相互に接続し、各被監視装置から監視装置に監視フレームを送信するシステムの被監視装置において、自装置内の通知待ち監視データが所定以上となったことにより該通知待ち監視データのデータ量に係る所定の情報を監視装置に通知し、監視装置より該監視装置が許容可能なデータ量の範囲内で通知してきた容量の監視情報を監視装置に通知するものである。これは上記被監視装置の部分をクレームしたものである。
【００１４】
また好ましくは、本発明（４）においては、上記本発明（３）において、前記各所定の情報は対応するデータ量を通知フレーム数又は通知点数に換算した情報である。
また本発明（５）の監視装置は、監視装置と複数の被監視装置とが相互に接続し、各被監視装置から監視装置に監視フレームを送信するシステムの監視装置において、自装置内の通知待ち監視データが所定以上となったことを検出した被監視装置より前記通知待ち監視データのデータ量に係る所定の情報を通知されたことにより、該通知された情報に基づき、かつ自身が当該被監視装置に対して許容可能な蓄積データ量の範囲内で、当該被監視装置の監視フレームを通知可能とするものである。これは上記監視装置の部分をクレームしたものである。
【００１５】
好ましくは、本発明（６）においては、上記本発明（５）において、監視装置は、監視データのトラフィック量に基づき求められた輻輳中及び輻輳予定の被監視装置の台数Ｓcnqstと、監視データの最大蓄積可能データ量に係る所定の情報Ｉｍａｘと、現時点の蓄積データ量に係る所定の情報Ｉｃｕｒとに基づき、通知待ち監視データのデータ量に係る所定の情報を通知してきた被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐを、
Ｐ＝（Ｉｍａｘ−Ｉｃｕｒ）／Ｓcnqst
により求める。
【００１６】
ところで、今、定常時における監視フレームの送信レートを一定とし、かつ警報や状態変化が少ない場合の１監視フレーム（例えば最大１８０点分通知可能）に含まれる通知点数を数点〜数十点と仮定する。この状態では生成監視データは各監視フレームにより漏れなく通知され、よって被監視装置における監視データの輻輳は生じ得ない。しかし、何らかの理由で警報や状態変化が頻発すると、これに伴い通知点数（即ち、単位時間当たりのトラフィック量）が増大し、やがて１フレームに全監視データを搭載しきれなくなり、この様な被監視装置は実際に輻輳状態となる（即ち、輻輳通知をしてくる）可能性が高い。
【００１７】
そこで、本発明（６）においては、監視装置は、係る状況下でも残余の蓄積メモリを最大限に活用し、かつ輻輳中及び上記輻輳予定の各被監視装置から夫々公平に輻輳監視データを収集できる様に、該輻輳中及び輻輳予定の各被監視装置に対して夫々に許容可能な蓄積データ量に係る所定の情報Ｐを予め求める。
この場合に、輻輳中及び輻輳予定の被監視装置の台数Ｓcnqstは、例えば監視データ（通知点）のトラフィック量が所定閾値を越えた被監視装置の台数として簡単に求められる。この台数の中には既に通知中（輻輳中）の被監視装置も含まれる。そして、実際に輻輳通知をしてきた被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐを、
Ｐ＝（Ｉｍａｘ−Ｉｃｕｒ）／Ｓcnqst
により求める。
【００１８】
具体的に言うと、例えばＩmax ＝１０単位，Ｉcur ＝２単位，Ｓcngst ＝２台とすると、Ｐ＝（１０−２）／２＝４単位となり、実際に輻輳通知をしてきた１又は２台の被監視装置に対して夫々に最大４単位分の許容蓄積データ量を余分に配分できる。また、例えばＩmax ＝１０単位，Ｉcur ＝６単位，Ｓcngst ＝４台とすると、Ｐ＝（１０−６）／４＝１となり、実際に輻輳通知をしてきた１乃至４台の被監視装置に対して夫々に最大１単位分の許容蓄積データ量を余分に配分できる。従って、上記本発明（７）によれば、輻輳中及び輻輳予定の被監視装置の台数Ｓcngst に応じて、監視装置の現時点の許容蓄積データ量を平準化して配分可能とする構成により、同時に複数の被監視装置が輻輳中となっても、それらからの監視データを公平にかつ効率よく一括収集できる。
【００１９】
また好ましくは、本発明（７）においては、上記本発明（６）において、監視装置は、被監視装置の台数Ｓと、監視データのトラフィック量に応じて各被監視装置を夫々Ｎ段階にランク付けした整数値Ｎｉとに基づき、輻輳中及び輻輳予定の被監視装置の台数Ｓcnqstを、
Ｓcnqst＝Ｓ−Σｉ（１／Ｎｉ） 但し、ｉ＝１〜Ｓ
により求める。
【００２０】
例えばＳ＝３台，Ｎ1 〜Ｎ3 ＝１（通常）とすると、Ｓcngst ＝３−｛（１／１）＋（１／１）＋（１／１）｝＝０となり、輻輳及び輻輳予定の被監視装置の台数Ｓcngst は０台と推定される。これは現実と良く一致している。但し、Ｓcngst ＝０の場合はＳcngst ＝１としても良い。これはＳcngst が分母に用いられる場合の制限である。また、最小でもＳcngst ＝１としておくと、最小でも１台分の輻輳を予定していることとなり、不測の輻輳発生に対処できる。
【００２１】
また例えばＳ＝３台，Ｎ１＝１（通常），Ｎ２＝６（輻輳中），Ｎ３＝３（輻輳予定）とすると、Ｓｃｎｑｓｔ＝３−｛（１／１）＋（１／６）＋（１／３）｝＝（９／６）＝１．５台となり、被監視装置＃３が輻輳通知をしてもこれに十分な許容蓄積データ量Ｐを配分できる。
従って、本発明（７）によれば、監視データのトラフィック量に応じて各被監視装置を夫々Ｎ段階にランク付けした整数値Ｎｉを使用することにより、輻輳及び輻輳予定の被監視装置の台数Ｓｃｎｑｓｔを監視データのトラフィック量に応じてきめ細かく管理できる。
【００２２】
また好ましくは、本発明（８）においては、上記本発明（６）において、監視装置は、被監視装置より通知待ち監視データのデータ量に係る所定の情報を通知された際に、該被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐ＞０の場合は、通知許可のデータ量に係る所定の情報ｒをｒ≦Ｐの範囲内で求め、これを前記被監視装置に通知する。この場合でも、被監視装置は、少なくとも指定情報ｒ分の監視データを通知でき、輻輳状態を緩和できる。
【００２３】
また好ましくは、本発明（９）においては、上記本発明（６）において、監視装置は、被監視装置より通知待ち監視データのデータ量に係る所定の情報を通知された際に、該被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐ＝０の場合は、前記被監視装置に監視データの通知停止を通知する。この場合は、当該被監視装置においてその輻輳監視データが廃棄される結果となるが、監視装置における他の被監視装置からの監視データの収集制御には何らの影響も与えない。
【００２４】
また好ましくは、本発明（１０）においては、上記本発明（９）において、監視装置は、被監視装置に監視データの通知停止を通知した場合に、その後該被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐ＞０となった場合は、前記被監視装置に監視データの通知再開を通知する。従って、従来の様に保守者の手を煩わすことも無く、監視データの収集は自動的に再開される。
【００２５】
また好ましくは、本発明（１１）においては、上記本発明（５）〜（１０）において、前記各所定の情報は対応するデータ量を通知フレーム数又は通知点数に換算した情報である。
【００２６】
【発明の実施の形態】
以下、添付図面に従って本発明に好適なる実施の形態を詳細に説明する。なお、全図を通して同一符号は同一又は相当部分を示すものとする。
図２は実施の形態によるネットワーク監視方式の構成を示す図で、監視装置３０と複数の被監視装置１０（＃１〜＃ｎ）とがバス型の伝送路を介して相互に接続する場合のネットワーク監視方式の例を示している。
【００２７】
図において、１０は実施の形態による被監視装置（ノード）＃１〜＃ｎ、１１はフレーム送／受信部、１２は通知待ちの監視データを一時的に保持する待ちキュー部、１３は監視データの収集及び待ちキュー部１２へのキューイング処理等を行うプロトコル処理部、１４は本来のデータ通信制御及び該データ通信制御に関する監視データの収集（生成）を行う制御処理部、１５はその他の監視データを収集する監視処理部、１６は監視装置３０からのポーリングフレームを解析して必要な処理を行う通知制御部、１７は監視フレームの一括通知制御に必要な情報を保持する通知管理テーブル、１８は待ちキュー部１２からの監視データのデキュー処理及び監視データの輻輳有無の検査を行う輻輳通知部である。
【００２８】
また、３０は実施の形態による監視装置、３１はフレーム送／受信部、３２は各被監視装置１０に対するポーリング制御、通知制御及び運用被監視装置の台数等の管理を行う定常監視部、３３は受信したポーリング応答フレームや監視フレームの内容解析及びフレーム管理バッファ３６への必要な情報の蓄積制御を行うフレーム蓄積管理部、３３Ａはポーリング応答フレームの内容に基づき被監視装置の輻輳判定を行う輻輳判定部、３４は単位時間当たりの通知点数に基づき被監視装置毎のトラフィック量を求め、夫々をＮ段階にランク付けするトラフィック管理部、３５は被監視装置毎の通知制御情報等を管理する被監視装置状態管理テーブル、３６は被監視装置毎の監視フレームの内容等を蓄積するフレーム管理バッファ、３７は被監視装置毎のトラフィック量やランク値を保持するトラフィック管理テーブル、３８はフレーム管理バッファ３６の監視データを上位監視装置に通知する監視通知部、９０は外部の上位監視装置、８０は伝送路である。
【００２９】
ここで、上記各部が参照する各種テーブル、バッファ、及び監視装置３０と各被監視装置１０との間でやりとりするポーリングフレーム、ポーリング応答フレームについて説明しておく。
図３，図４は実施の形態による各種テーブル等を説明する図（１），（２）であり、図３（Ａ）は監視装置における被監視装置状態管理テーブル３５の構成を示す。被監視装置状態管理テーブル３５は、運用中の全被監視装置の台数（Ｓ）、輻輳中（輻輳予定を含む）の被監視装置の総数（Ｓcngst ）、監視装置の許容蓄積フレーム量（Ｐf ）、許容蓄積通知量（Ｐt ）を夫々記憶する欄を備える。また監視装置３０から各被監視装置＃１〜＃ｎに通知するための一括通知フレーム数（ｒf1〜ｒfn）、一括通知許可数（ｒt1〜ｒtn）、通知停止指示を夫々に記憶する欄を被監視装置毎に備える。
【００３０】
図３（Ｂ）は監視装置におけるフレーム管理バッファ３６の構成を示す。フレーム管理バッファ３６は、監視装置の最大蓄積フレーム量（Ｆmax ）、現蓄積フレーム量（Ｆcur ）、最大蓄積通知量（Ｔmax ）、現蓄積通知量（Ｔcur ）を夫々記憶する欄を備える。また各被監視装置＃１〜＃ｎから受信された現受信フレーム量（Ｒf1〜Ｒfn）、現受信通知量（Ｒt1〜Ｒtn）を夫々記憶する欄を被監視装置毎に備える。更に各被監視装置＃１〜＃ｎから送られた監視フレームの情報（通知情報＃１〜＃ｎ）を夫々記憶する欄を被監視装置毎に備える。
【００３１】
図４（Ａ）は監視装置におけるトラフィック管理テーブル３７の構成を示す。トラフィック管理テーブル３７は、各被監視装置＃１〜＃ｎにつき夫々に求めた単位時間当たりのフレームトラフィック量（ＴＲf1〜ＴＲfn）、通知トラフィック量（ＴＲt1〜ＴＲtn）を夫々記憶する欄を被監視装置毎に備える。また前記フレームトラフィック量及び通知トラフィック量につき夫々Ｎ段階にランク付けされたフレーム輻輳ランク（Ｎf1〜Ｎfn）、通知輻輳ランク（Ｎt1〜Ｎtn）を夫々記憶する欄を被監視装置毎に備える。
【００３２】
図４（Ｂ）は被監視装置における通知管理テーブル１７の構成を示す。通知管理テーブル１７は、装置内で収集された監視データが時々刻々とキューイング／デキューされる中で、現時点の待ちキュー内フレーム数、待ちキュー内通知点数を夫々記憶する欄を備える。また監視装置３０から通知された一括通知フレーム数（ｒf ）、一括通知許可数（ｒt ）の通知制御情報を記憶する欄を備える。
【００３３】
図１２は実施の形態によるポーリングフレームのフォーマットを示す図で、監視装置３０から各被監視装置１０に送信される。図において、第１オクテットは送信先（被監視装置）ＩＤ、第２，第３オクテットはアプリケーション（ＡＰ）データユニット識別子であり、該第２オクテットのビットｂ2 は通知再開指示ビット、ビットｂ3 は通知停止指示ビット、ビットｂ4 は一括通知指示ビットとして夫々使用される。なお、上記一括通知指示ビットがＯＮとされる時は、同時に第４オクテットに一括通知フレーム数ｒf の情報及び又は第５オクテットに一括通知許可数ｒt の情報が搭載される。
【００３４】
図１３は実施の形態によるにポーリング応答フレームのフォーマットを示す図で、各被監視装置１０から監視装置３０に送信される。図において、第１オクテットは送信先（監視装置）ＩＤ、第２，第３オクテットはＡＰデータユニット識別子であり、該第２オクテットのビットｂ3 は通知点数が輻輳していることを表す通知輻輳通知ビット、ビットｂ4 はキュー（フレーム）数が輻輳していることを表すキュー輻輳通知ビットとして夫々使用される。なお、通知輻輳通知ビット又はキュー輻輳通知ビットがＯＮとされる時は、同時に第４オクテットに監視装置３０に送りたい総通知点数又はフレーム総数の情報が搭載される。更に、第５オクテットはポーリング応答フレームのデータ長（この例では１１バイト固定とする）、第６〜第８オクテットは応答フレームの転送時刻、第９オクテットは被監視装置の置かれているフロア・群、そして、第１０，第１１オクテットは架番号である。なお、図示しないが、各被監視装置１０から監視装置３０に送信される監視フレームが存在する。
【００３５】
以下、監視装置及び被監視装置における上記各主要構成部の制御・処理をフローチャートに従って説明する。まず監視装置を説明する。
図５，図６は実施の形態による定常監視処理のフローチャート（１），（２）である。定常監視部３２は、定期的に（例えば１秒間隔で）起動され、その都度被監視装置の通知制御に必要な各種パラメータＳcngst ，Ｐf ，Ｐt を更新すると共に、各被監視装置を順にポーリングし、その応答有／無に基づいて運用中の被監視装置の台数Ｓを更新する等の処理を行う。またポーリングの際には、必要ならポーリングフレームに通知制御情報を搭載して送信し、併せて各被監視装置の通知制御を行う。以下、詳細に説明する。
【００３６】
図５において、ステップＳ１では輻輳中（輻輳予定を含む）の被監視装置数Ｓcngst を、
Ｓcngst ＝Ｓ−Σ（１／Ｎi ） ｉ＝１〜Ｓ
により求め、これを被監視装置状態管理テーブル３５に格納する。
ここで、Ｎi は被監視装置毎のフレームトラフィック量又は通知トラフィック量に対応する重み係数（例えばＮ段階の整数１〜Ｎ）を表し、トラフィック量の多い被監視装置のＮi は大きく、またトラフィック量の少ない被監視装置のＮi は小さい。詳細は後述する。上記式によれば、輻輳中の被監視装置数Ｓcngst は、トラフィック量の多い被監視装置が多い場合は大きく、またトラフィック量の多い被監視装置が少ない場合は小さくなる。但し、Ｓcngst ＝０の場合は、Ｓcngst ＝１とする。
【００３７】
ステップＳ２では、上記求めたＳcngst 及びフレーム管理バッファ３６中の最大蓄積フレーム量Ｆmax 、現蓄積フレーム量Ｆcur に基づき許容蓄積フレーム量Ｐf を、
Ｐf ＝（Ｆmax −Ｆcur ）／Ｓcngst
により求め、これを被監視装置状態管理テーブル３５に格納する。
【００３８】
ステップＳ３では上記求めたＳcngst 及びフレーム管理バッファ３６中の最大蓄積通知量Ｔmax 、現蓄積通知量Ｔcur に基づき許容蓄積通知量Ｐt を、
Ｐt ＝（Ｔmax −Ｔcur ）／Ｓcngst
により求め、これを被監視装置状態管理テーブル３５に格納する。
ステップＳ４では、運用中の各被監視装置にポーリングするため、レジスタｎに全被監視装置数Ｓ、カウンタｉ，ｊに夫々０をセットする。ステップＳ５では被監視装置状態管理テーブル３５から被監視装置＃ｉに対する通知制御情報を読み出し、ステップＳ６では通知停止指示有りか否かを判別する。有りの場合は更にステップＳ９で許容蓄積フレーム量Ｐf ＞０又は許容蓄積通知量Ｐt ＞０か否かを調べる。Ｐf ＞０又はＰt ＞０でない場合は、監視装置のフレームバッファに余裕が無いので、ステップＳ１０でポ−リングフレ−ムに通知停止指示ビット＝１（ＯＮ）をセットする。またＰf ＞０又はＰt ＞０の場合は、監視装置のフレームバッファに余裕ができたので、ステップＳ１１でポ−リングフレ−ムに通知再開指示ビット＝１をセットする。
【００３９】
また、上記ステップＳ６の判別で通知停止指示無しの場合は、更にステップＳ７で一括フレーム通知数有りか否かを調べる。有りの場合は、ステップＳ１２でポ−リングフレ−ムに一括通知指示ビット＝１及び一括通知フレーム数ｒf をセットする。
また、上記ステップＳ７の判別で一括フレーム通知無しの場合は、更にステップＳ８で一括通知許可数有りか否かを調べる。有りの場合は、ステップＳ１３でポ−リングフレ−ムに一括通知指示ビット＝１及び一括通知許可数ｒt をセットする。
【００４０】
制御は図６に進み、ステップＳ１４ではポ−リングフレ−ムを送信する。ステップＳ１４では所定時間の間ポ−リング応答フレ−ムを待ち、応答があった場合は、当該被監視装置は運用されているので、ステップＳ１６でカウンタｊに＋１する。また応答が無い場合はステップＳ１６の処理をスキップする。ステップＳ１７ではカウンタｉに＋１し、ステップＳ１８ではｉ＜ｎか否かを判別する。ｉ＜ｎの場合はステップＳ５に戻り、次の被監視装置に対する上記処理を行う。
【００４１】
こうして、やがて、全被監視装置に対する上記処理を終了すると、ステップＳ１８の判別でｉ＝ｎとなる。ステップＳ１９では被監視装置状態管理テーブル３５の全被監視装置数Ｓにカウンタｊの内容（ポーリング応答のあった被監視装置数）をセットし、この処理を抜ける。
図７は実施の形態によるフレーム受信処理のフローチャートで、フレーム蓄積管理部３３が被監視装置からの監視フレームを受信するとこの処理に入力する。なお、ここでは被監視装置が送信する監視フレーム内に、監視データと共に、監視装置に通知するための輻輳情報（総フレーム数、総通知点数）を搭載できる場合を説明する。
【００４２】
ステップＳ２１ではフレーム管理バッファ３６の現蓄積フレーム量Ｆcur に＋１（フレーム）し、かつ被監視装置毎に管理する現受信フレーム量Ｒf に＋１（フレーム）する。ステップＳ２２では監視フレームの内容を通知点数に換算し、その通知点数を現蓄積通知量Ｔcur 及び当該被監視装置に対応する現受信通知量Ｒt に夫々加算する。
【００４３】
ステップＳ２３では輻輳判定部３３Ａが受信フレーム中に総フレーム数がセットされているか否かを調べる。セットされている場合はステップＳ２６で、その時点における許容蓄積フレーム量Ｐf との関係に基づき、当該被監視装置に割り当てるべき一括フレーム通知数ｒf を求める。具体的に言うと、Ｐf ≧総フレーム数の場合はｒf ＝総フレーム数とし、また０≦Ｐf ＜総フレーム数の場合はｒf ＝Ｐf とし、またＰf ＝０の場合はｒf ＝０とする。
【００４４】
ステップＳ２７ではｒf ＝０か否かを判別する。ｒf ＝０の場合は、フレーム管理バッファ３６に余裕が無いので、ステップＳ２８で被監視装置状態管理テーブル３５の当該被監視装置の制御情報格納欄に通知停止指示を格納する。またｒf ≠０の場合はステップＳ２９で被監視装置状態管理テーブル３５に前記求めた一括通知フレーム数ｒf を格納する。
【００４５】
また輻輳判定部３３Ａは、上記ステップＳ２３の判別で総フレーム数がセットされていない場合は、更にステップＳ２４で受信フレーム中に総通知点数がセットされているか否かを調べる。セットされている場合はステップＳ３０で、その時点における許容蓄積通知量Ｐt との関係に基づき、当該被監視装置に割り当てるべき一括通知許可数ｒt を求める。具体的に言うと、Ｐt ≧総通知点数の場合はｒt ＝総通知点数とし、また０≦Ｐt ＜総通知点数の場合はｒt ＝ｐt とし、またＰt ＝０の場合はｒt ＝０とする。
【００４６】
ステップＳ３１ではｒt ＝０か否かを判別する。ｒt ＝０の場合は、フレーム管理バッファ３６に余裕が無いので、ステップＳ３２で被監視装置状態管理テーブル３５の当該被監視装置の制御情報格納欄に通知停止指示を格納する。またｒt ≠０の場合はステップＳ３３で被監視装置状態管理テーブル３５に前記求めた一括通知許可数ｒt を格納する。ステップＳ２５では監視フレームの監視データをフレーム管理バッファ３６の当該被監視装置の欄に格納し、処理を抜ける。
【００４７】
なお、被監視装置は上記輻輳情報（総フレーム数、総通知点数）をポーリング応答フレームに搭載して通知するように構成しても良い。この方法は後述の実施例の説明で示される。
図８は実施の形態によるトラフィック管理処理のフローチャートである。
トラフィック管理部３４は、定期的（例えば１秒間隔）に起動され、以下の処理を全被監視装置について行う。即ち、ステップＳ４１ではフレーム管理バッファ３６より現受信フレーム量Ｒf 及び現受信通知量Ｒt を獲得する。ステップＳ４２では単位時間（例えば１秒）当たりのフレームトラフィック量ＴＲf 及び通知トラフィック量ＴＲt を夫々算出し、これらをトラフィック管理テーブル３７に格納する。ステップＳ４３では前記求めたフレームトラフィック量ＴＲf 及び通知トラフィック量ＴＲt を夫々Ｎ段階（例えば１〜６段階）にランク付けする。ステップＳ４４では求めたランク値をトラフィック管理テーブル３７に格納する。ステップＳ４５ではフレーム管理バッファ３６の当該現受信フレーム量Ｒf 及び現受信通知量Ｒt をクリアする。
【００４８】
以下、被監視装置における制御・処理を説明する。
図９は実施の形態によるキューイング処理のフローチャートである。プロトコル処理部１３は、ステップＳ５１で通知停止中か否かを判別する。被監視装置がポーリングフレームで通知停止指示を受け取った場合は通知停止中である。この場合はそのまま処理を抜ける。また通知停止中でない場合は、ステップＳ５２で待ちキュー部１２に１フレーム分の監視データをキューイングする。ステップＳ５３では通知管理テーブル１７の待ちキュー内フレーム数に＋１し、かつ待ちキュー内通知点数に該キューイングしたフレームの通知点数を加算する。
【００４９】
図１０は実施の形態によるデキュー処理のフローチャートである。
輻輳通知部１８は、定期的に（例えば１秒間隔で）起動され、待ちキュー部１２からの監視データのデキューを行う。即ち、ステップＳ６１では本装置に対して一括フレーム通知又は一括通知許可が有る状態か否かを判別する。無い場合はステップＳ６２で、通常に従い、１フレーム分のデキューを行う。ステップＳ６３では通知管理テーブル１７内の待ちキュー内フレーム数を獲得し、上記デキュー分をマイナスする。ステップＳ６４では残りのキュー数が上限値のＮ1 ％以上か否かを判別する。Ｎ1 ％以上の場合は、本装置が輻輳状態であると判断し、そのデキューフレーム中に残りの待ちキュー内総フレーム数をセットする。またＮ1 ％以上でない場合はステップＳ６５の処理をスキップする。
【００５０】
ステップＳ６６では通知管理テーブル１７の待ちキュー内通知点数を獲得し、上記デキュー分をマイナスする。ステップＳ６７では通知点数が上限値のＮ2 ％以上か否かを判別する。Ｎ2 ％以上の場合は、本装置が輻輳状態であると判断し、そのデキューフレーム中に待ちキュー内通知点数をセットする。またＮ2 ％以上でない場合はステップＳ６８の処理をスキップする。
【００５１】
また、上記ステップＳ６１の判別で一括フレーム通知又は一括通知許可がある状態の場合は、ステップＳ７０で一括通知分の連続デキューを行う。ステップＳ７１では送信フレームに再輻輳通知情報をセットする。そして、ステップＳ６９では上記デキュー分の監視フレームを一つ又は複数連続（一括）で監視装置３０に送信する。従って、通常は、例えば１秒間に１フレームの割合の監視フレームの通知となるが、監視装置に輻輳通知をした結果、監視装置から一括通知を許可されると、例えば１秒間に数フレームの割合で監視フレームを一括通知できることとなる。
【００５２】
図１１は実施の形態による通知指示処理のフローチャートである。
通知制御部１６は、監視装置からのポーリングフレームを受信すると、ステップＳ８１でポーリングフレーム内の指示ビットを検査する。ステップＳ８２では一括通知指示ビット＝１か否かを判別し、一括通知指示ビット＝１の場合はステップＳ８６で通知管理テーブル１７に一括処理情報（一括通知フレーム数ｒf 又は一括通知許可数ｒt ）を格納し、ステップＳ８５に進む。
【００５３】
また一括通知指示ビット＝１でない場合は、ステップＳ８３で更に通知停止指示ビット＝１か否かを判別する。通知停止指示ビット＝１の場合はステップＳ８７で輻輳通知部１８及びプロトコル処理部１３に通知停止を依頼し、ステップＳ８５に進む。これにより輻輳通知部１８は待ちキュー部１２の待ちキュー行列からのデキューを停止し、プロトコル処理部１３は待ちキュー部１２へのキューイングの停止及び待ちキュー行列のクリアを行う。
【００５４】
また通知停止指示ビット＝１でない場合は、ステップＳ８４で更に通知再開指示ビット＝１か否かを判別する。通知再開指示ビット＝１の場合はステップＳ８７で輻輳通知部１８及びプロトコル処理部１３に通知再開を依頼する。これにより輻輳通知部１８は待ちキュー部１２からのデキューを再開し、プロトコル処理部１３は待ちキュー部１２へのキューイングを再開する。そして、ステップＳ８５ではポーリング応答フレームを送信する。
【００５５】
以下、システム全体の動作を、いくつかのケースに従って説明する。
まず、被監視装置が輻輳状態になった場合の監視装置による一括通知指示の動作を説明する。被監視装置１０において、輻輳通知部１８は待ちキュー部１２からのデキュー時に待ちキュー内フレーム数を獲得すると共に、待ちキュー内フレーム数が上限値のＮ1 ％に達している場合は、輻輳状態にあると判断し、該デキューフレーム中に待ちキュー内の総フレーム数をセットし、監視装置３０へ通知する。
【００５６】
また、輻輳通知部１８は待ちキュー部１２からのデキュー時に待ちキュー内通知点数を獲得すると共に、待ちキュー内通知点数が上限値のＮ2 ％に達している場合は、輻輳状態にあると判断し、該デキューフレーム中に待ちキュー内の総通知点数をセットし、監視装置３０へ通知する。
監視装置３０において、輻輳判定部３３Ａは受信フレーム内に総フレーム数がセットされているのを認識すると、許容蓄積フレーム量Ｐf を越えない範囲内で、一括フレーム通知数ｒf を求める。更に当該監視フレームの内容をフレーム管理バッファ３６に格納し、被監視装置状態管理テーブル３５に上記求めた一括通知フレーム数ｒf を格納する。
【００５７】
また、輻輳判定部３３Ａは受信フレーム内に総通知点数がセットされているのを認識すると、許容蓄積通知量Ｐt を越えない範囲内で、一括通知許可数ｒt を求める。更に当該監フレームの内容をフレーム管理バッファ３６に格納し、被監視装置状態管理テーブル３５に上記求めた一括通知許可数ｒt を格納する。
一方、定常監視部３２が定期的に起動されると、定常監視部３２は被監視装置状態管理テーブル３５から上記格納された一括通知フレーム数ｒf 、一括通知許可数ｒt を獲得すると共に、これをポーリングフレーム中に一括通知許可ビットと共にセットし、当該被監視装置１０に対して通知する。また被監視装置状態管理テーブル３５の当該一括通知フレーム数ｒf 、一括通知許可数ｒt をクリアする。
【００５８】
被監視装置１０において、通知制御部１６がポーリングフレーム中に一括通知許可ビットと一括通知フレーム数ｒf ／一括通知許可数ｒt がセットされているのを認識すると、輻輳通知部１８に対して一括通知処理を依頼する。これを受けた輻輳通知部１８は通知された一括通知フレーム数ｒf ／一括通知許可数ｒt 分の監視データの連続デキューを行い、監視装置３０に対して通知する。この時、以下の条件により、監視フレームに輻輳情報をセットする。
【００５９】
即ち、待ちキュー数が上限値を超えている場合に、一括通知フレーム数ｒf ＝現キュー数の場合は、現キュー数＝０とする。この場合は１回の連続デキューで輻輳状態が解消されたことになる。また一括通知フレーム数ｒf ＜現キュー数の場合は現キュー数＝現キュー数−一括通知フレーム数ｒf とする。この場合は１回の連続デキューで通知しきれなかった分の現キュー数（残り分）が再度輻輳通知される。
【００６０】
また、通知点数が上限値を超えている場合に、一括通知許可数ｒt ＝現通知点数の場合は現通知点数＝０とする。この場合は１回の連続デキューで輻輳状態が解消されたことになる。また一括通知許可数ｒt ＜現通知点数の場合は現通知点数＝現通知点数−一括通知許可数ｒt とする。この場合は１回の連続デキューで通知しきれなかった分の現通知点数（残り分）が再度輻輳通知される。
【００６１】
次に被監視装置が輻輳状態になった場合の監視装置による通知停止指示の動作を説明する。上記図７のフレーム受信処理において、Ｐf ＝０又はＰt ＝０のため、ｒf ＝０又はｒt ＝０と判定された場合には、監視装置３０の側には許容バッファ量がなく、監視装置自身が輻輳状態であると判断して、当該受信監視フレームの内容をフレーム管理バッファ３６に格納すると共に被監視装置状態管理テーブル３５に通知停止指示がセットされる。
【００６２】
一方、定常監視部３２が定期的に起動されると、定常監視部３２は被監視装置状態管理テーブル３５から通知停止指示を獲得すると共に、ポーリングフレーム中に通知停止指示ビットをセットし、当該被監視装置に対して通知する。
被監視装置１０において、通知制御部１６はポーリングフレーム中に通知停止指示ビット＝１がセットされているのを認識すると、プロトコル処理部１３及び輻輳通知部１８に対して通知停止処理を依頼し、これにより輻輳通知部１８は待ちキュー部１２の待ちキュー行列からのデキューを停止し、またプロトコル処理部１３は待ちキュー行列へのキューイングの停止及び待ちキュー行列のクリアを行う。
【００６３】
次に、上記通知停止指示を受けた被監視装置に対して、輻輳状態が緩和された監視装置より通知再開指示が送られた場合の動作を説明する。定常監視部３２がＰf ＞０又はＰt ＞０と判断した時に、被監視装置状態管理テーブル３５に通知停止指示状態にある被監視装置が存在する場合は、ポーリングフレーム中に通知再開指示ビット＝１をセットし、当該被監視装置に対して通知する。これを受けた被監視装置では、通知制御部１６よりプロトコル処理部１３及び輻輳通知部１８に対して通知再開処理を依頼し、これによりプロトコル処理部１３は待ちキュー部１２へのキューイングの再開を行い、輻輳通知部１８は待ちキュー行列からのデキューを再開する。
【００６４】
以下、バス上に接続された１台の監視装置と複数（例えば３台）の被監視装置とに対して本発明を適用した一実施例を具体的数値例に従って説明する。
被監視装置１０において、監視装置３０への監視フレームの送出間隔は１秒間隔、１フレーム内に含まれる通知点数は可変でその最大値は１８０点とする。また待ちキュー内フレーム数の上限値は１０フレームであり、輻輳通知のしきい値としてＮ1 ％→１０％（１フレーム）とする。但し、一括通知後の待ちキュー内に残存フレームがある場合には輻輳通知を行う。また待ちキュー内通知点数の最大値は１０×１８０＝１８００点であり、輻輳通知のしきい値としてＮ2 ％→２％（３６点）とする。
【００６５】
監視装置３０において、被監視装置１０に対するポーリング間隔は１秒間隔とし、フレーム管理バッファ３６に格納できる最大の通知点数（Ｔmax ）は１０００００点、従って、Ｆmax ＝（１０００００／１８０）＝５５５フレームとする。またトラフィック測定のための単位時間は１秒とする。なお、この例では被監視装置１０からの監視フレームの到着時間は１秒間隔のため、フレームトラフィック量ＴＲf は常に１となる。一方、通知トラフィック量ＴＲt については１秒単位で収集し、例えば以下の如く通知輻輳ランクＮt の重み付けを行う。
【００６６】
Ｎt ＝１： 通知トラフィック量ＴＲf ≦ １個／ｓ
Ｎt ＝２： １個／ｓ＜通知トラフィック量ＴＲf ≦ ３６個／ｓ
Ｎt ＝３： ３６個／ｓ＜通知トラフィック量ＴＲf ≦ ７２個／ｓ
Ｎt ＝４： ７２個／ｓ＜通知トラフィック量ＴＲf ≦１０８個／ｓ
Ｎt ＝５：１０８個／ｓ＜通知トラフィック量ＴＲf ≦１４４個／ｓ
Ｎt ＝６：１４４個／ｓ＜通知トラフィック量ＴＲf ≦１８０個／ｓ
係る構成で、以下、全被監視装置からのポーリング応答以外の通知がない状態（即ち、監視装置側は蓄積フレーム及び蓄積通知がない状態）から、被監視装置＃１のみが輻輳状態になった場合の動作を説明する。
【００６７】
＜被監視装置からの輻輳通知＞
被監視装置＃１において、待ちキュー内に３フレーム分、各フレーム内に５通知点数分が存在するとすると、輻輳通知部１８は、デキュー時に通知管理テーブル１７内の待ちキュー内フレーム数を１つデクリメントし、かつ待ちキュー内通知点数をデキューフレーム内の通知点数分デクリメントする。
【００６８】
この例では、ポーリングフレームの応答時に上記待ちキュー内フレーム数、待ちキュー内通知点数の残数をチェックする。この時、残フレーム数＝２（＞Ｎ1 ％）、残通知点数＝１０（＜Ｎ2 ％）である。この結果、ポーリング応答フレームにキュー輻輳通知ビット＝１、フレーム総数＝２を搭載し、監視装置３０に通知する。
【００６９】
＜監視装置での輻輳判定と一括通知許可＞
監視フレームの受信前において、定常監視部３２では、被監視装置からの監視データが無いことから、Ｓcngst ＝１，Ｐr ＝Ｆmax 、Ｐt ＝Ｔmax となる。またトラフィック管理でも、フレームトラフィック＝１、通知トラフィック＝０となり、フレーム輻輳ランクＮf ＝通知輻輳ランクＮt ＝１となっている。
【００７０】
輻輳通知を含むポーリング応答受信後において、輻輳判定部３３Ａにてキュー輻輳通知ビット＝１及びフレーム総数＝２を獲得すると、Ｐf ＝Ｆmax （＝５５５）であることから、フレーム総数２＜Ｐf よりｒf ＝２と判定され、被監視装置状態管理テーブル３５の当該被監視装置＃１の管理レコードに一括通知フレーム数ｒf1＝２をセットする。
【００７１】
＜一括通知許可を被監視装置へ通知＞
定常監視部３２は、被監視装置状態管理テーブル３５の各被監視装置毎の管理レコードを検索し、被監視装置＃１への一括通知フレーム数ｒf1＝２を獲得する。更に、ポーリングフレームに一括通知指示ビット＝１、一括通知フレーム数ｒf ＝２（一括通知許可数ｒt ＝０）をセットして被監視装置＃１宛のポーリングを発行する。
【００７２】
＜被監視装置にて一括通知許可受信＞
通知制御部１６は、ポーリングの受信フレームより２フレーム分の一括通知許可を得ると、通知管理テーブル１７の一括通知フレーム数ｒf の欄に２を加算する。輻輳通知部１８では、デキュー時に通知管理テーブル１７を検索し、一括通知フレーム数ｒf ＝２を獲得し、２フレーム分の連続デキューを行う。なお、各デキュー情報は２フレーム分の監視フレームに搭載され、自発的、連続的に送られる。また通知管理テーブル１７の待ちキュー内フレーム数から２をデクリメントし、残値をチェックする。この例では残値が０であるため、輻輳状態は解除されたと判断し、その後のポーリング応答フレームには輻輳通知は付加しないで送信する。また通知管理テーブル１７の一括通知フレーム数ｒf をクリアする。
【００７３】
なお、上記実施の形態ではバス型ネットワーク上におけるネットワーク監視方式の例を述べたが、本発明はスター型、リンク型等のネットワーク上における監視データ収集方式及びその装置にも適用できることは言うまでも無い。
また、上記実施の形態ではネットワーク監視方式の例を述べたが、本発明は例えば架構成のシェルフに搭載される複数の各種機能ユニット（被監視基板等）から中央の監視ユニット（監視基板等）に監視情報を収集する場合にも適用できることは明らかである。
【００７４】
また、上記本発明に好適なる実施の形態を述べたが、本発明思想を逸脱しない範囲内で各部の構成、制御、及びこれらの組合せの様々な変更が行えることは言うまでも無い。
【００７５】
【発明の効果】
以上述べた如く本発明によれば、被監視装置から待ちキュー数が上限を超える前に輻輳状態であることを監視装置へ通知し、監視装置の許容蓄積量に余裕がある場合は、被監視装置からの一括通知を受け付けることにより、被監視装置の通知停止を防ぎ、監視を連続的に行うことが出来る。
【００７６】
また監視装置で許容蓄積量を超えた場合は、連続的に通知を発生させている被監視装置に対して通知を停止させることで、監視装置の安定運用を行うことが出来る。
また、監視装置から被監視装置への通知停止／再開が自動で行えるため、保守者のオペレーションが不要となる。
【図面の簡単な説明】
【図１】本発明の原理を説明する図である。
【図２】実施の形態によるネットワーク監視方式の構成を示す図である。
【図３】実施の形態による各種テーブル等を説明する図（１）である。
【図４】実施の形態による各種テーブル等を説明する図（２）である。
【図５】実施の形態による定常監視処理のフローチャート（１）である。
【図６】実施の形態による定常監視処理のフローチャート（２）である。
【図７】実施の形態によるフレーム受信処理のフローチャートである。
【図８】実施の形態によるトラフィック管理処理のフローチャートである。
【図９】実施の形態によるキューイング処理のフローチャートである。
【図１０】実施の形態によるデキュー処理のフローチャートである。
【図１１】実施の形態による通知指示処理のフローチャートである。
【図１２】実施の形態によるポーリングフレームのフォーマットを示す図である。
【図１３】実施の形態によるにポーリング応答フレームのフォーマットを示す図である。
【図１４】図１４は従来のネットワーク監視方式の構成を示す図である。
【符号の説明】
１０ 被監視装置
１１ フレーム送／受信部
１２ 待ちキュー部
１３ プロトコル処理部
１４ 制御処理部
１５ 監視処理部
１６ 通知制御部
１７ 通知管理テーブル
１８ 輻輳通知部
３０ 監視装置
３１ フレーム送／受信部
３２ 定常監視部
３３ フレーム蓄積管理部
３３Ａ 輻輳判定部
３４ トラフィック管理部
３５ 被監視装置状態管理テーブル
３６ フレーム管理バッファ
３７ トラフィック管理テーブル
３８ 監視通知部
８０ 伝送路
９０ 上位監視装置
【発明の属する技術分野】
本発明は監視データ収集方式及びその装置に関し、更に詳しくは監視装置と複数の被監視装置とが相互に接続し、各被監視装置から監視装置に監視フレームを送信するシステムの監視データ収集方式及びその装置に関する。
例えば遠隔の複数のノード間でデータ通信を行うネットワークシステムでは、監視ノードと複数の被監視ノード（本来は通信制御を行う）とがバス，スター，リンク方式等により相互に接続すると共に、各被監視ノードから監視ノードに監視フレームを送信することを行う。また、例えば前記ノードを構成する通信装置では、架構成のシェルフ（スロット等）に搭載された監視用基板と複数の被監視用基板（本来は各種通信制御を行う）とがバス，スター，リンク方式等により相互に接続し、各被監視基板から監視基板に監視フレームを送信することを行う。本発明はこの様なシステム（ネットワーク，通信装置等）における監視データの収集制御に適用して好適なるものである。
【０００２】
【従来の技術】
図１４は従来のネットワーク監視方式の構成を示す図で、監視装置７０及び複数の被監視装置５０がバス型ネットワーク上に接続された場合のネットワーク監視方式の例を示している。
図において、５０は被監視装置（ノード）、５１はポーリング応答フレーム及び監視フレームの送信とポーリングフレームの受信とを行うフレーム送／受信部、５２は通知待ちの監視データを一時的に蓄積する待ちキュー部、５３は自装置内の監視データの収集及び待ちキュー部５３へのキューイングを行うプロトコル処理部、５４は本来のデータ通信制御を行うと共に該データ通信制御に関する監視データを収集（生成）する制御処理部、５５はその他の監視データを収集する監視処理部、７０は監視装置、７１はポーリングフレームの送信とポーリング応答フレーム及び監視フレームの受信とを行うフレーム送／受信部、７２は各被監視装置５０に対するポーリング処理を行うポーリング処理部、７３は各被監視装置５０からの監視フレームを分解・蓄積処理するフレーム蓄積処理部、７４は監視データを蓄積するフレーム管理バッファ、７５はフレーム管理バッファ７４の監視データを上位の監視装置９０に通知する監視通知部、９０は上位監視装置、８０は伝送路である。
【０００３】
監視装置７０は、各被監視装置５０を定期的にポーリングしており、各被監視装置５０からの応答有／無に基づき当該被監視装置５０が運用されているか否かを認識できる。なお、被監視装置５０が監視データの通知を停止している場合は無応答となる。
係るやり取りの下で、被監視装置５０では、制御処理部５４及び監視処理部５５から監視装置７０へ通知すべき監視データ（警報データ，状態変化通知に係るデータ等）がプロトコル処理部５３に渡される。プロトコル処理部５３はこれらの監視データを時間軸上にソートし、待ちキュー部５２にキューイングする。フレーム送／受信部５１は定期的に待ちキュー行列から１キュー情報をデキューし、かつネットワーク８０上に他キャリアが存在しないことを確認した後、監視装置７０に対して監視データのフレーム（監視フレーム）を送信する。
【０００４】
監視装置７０において、フレーム送／受信部７１は受信した監視フレームをフレーム蓄積処理部７３に渡し、フレーム蓄積処理部７３は該フレームを分解して上位監視装置９０へ通知するための監視情報単位にフレーム管理バッファ７４に格納する。一方、監視通知部７５は定期的にフレーム管理バッファ７４を検索し、該バッファ内の監視データを上位監視装置９０へ順次送信すると共に、送信完了後はフレーム管理バッファ７４から当該監視データを削除する。
【０００５】
従って、各被監視装置５０における監視データの量が通常であるような場合には、監視装置７０に対する通知及び監視装置７０における監視データの収集も適正に行われる。
【０００６】
【発明が解決しようとする課題】
しかし、１又は２以上の被監視装置５０において警報や状態変化が頻発すると、各被監視装置５０の待ちキュー数が増大すると共に、監視装置７０における監視データの蓄積量も大幅に増大し、最悪の場合は監視装置７０のフレーム管理バッファ７４がオーバフローし、全被監視装置５０からの通知が廃棄されてしまうこととなる。
【０００７】
そこで、従来は、被監視装置５０が自装置内の待ちキュー数に基づき監視装置７０への通知可／不可を自ら判定すると共に、被監視装置５０の待ちキュー数が所定閾値を越えると、仮に監視装置７０におけるフレーム管理バッファ７４の蓄積量に余裕があっても、被監視装置５０は監視データの通知を停止していた。
このため、監視装置７０では、その後にこの被監視装置５０から監視データを収集できない不都合があった。また、被監視装置５０からの通知が停止した場合は、保守者がその状況を判断し、別途に通知再開の処理を行う必要があり、作業が煩雑であった。
【０００８】
本発明は上記従来技術の問題点に鑑み成されたもので、その目的とする所は、監視データのトラフィック量が様々に変化する様な状況下にあっても、各被監視装置からの監視データを効率よく収集できる監視データ収集方式及びその装置を提供することにある。
【０００９】
【課題を解決するための手段】
上記の課題は例えば図１の構成により解決される。即ち、本発明（１）の監視データ収集方式は、監視装置３０と複数の被監視装置１０とが相互に接続し、各被監視装置＃１〜＃ｎから監視装置３０に監視フレームを送信するシステムの監視データ収集方式において、被監視装置（例えば＃２）は自装置内の通知待ち監視データが所定以上となったことにより該通知待ち監視データのデータ量に係る所定の情報を監視装置に通知し、監視装置３０は、前記通知された情報に基づき、かつ自身が当該被監視装置＃２に対して許容可能な蓄積データ量の範囲内で、当該被監視装置＃２の監視フレームを通知可能とするものである。
【００１０】
本発明（１）によれば、被監視装置＃２は自装置内の通知待ち監視データが所定以上となったことにより前記通知待ち監視データのデータ量に係る所定の情報を監視装置３０に通知するので、監視装置３０は被監視装置＃２が輻輳状態にあること及びその輻輳の程度（データ量に係る情報）を早期に明確に把握できる。
また、監視装置３０は、前記通知された情報に基づき、かつ自身が被監視装置＃２に対して許容可能な蓄積データ量の範囲内で、被監視装置＃２の監視フレームを通知可能とするので、他の輻輳中又は輻輳予定の被監視装置（例えば＃１等）に対して許容可能な蓄積データ量には何らの影響を与えることも無く、当該被監視装置＃２からの通知待ち監視データを効率よく収集できる。
【００１１】
好ましくは、本発明（２）においては、上記本発明（１）において、前記所定の情報は対応するデータ量を通知フレーム数又は通知点数に換算した情報である。一般に被監視装置は１フレームで複数の通知点（伝送路断，クロック異常，パッケージ異常等）の監視データを通知してくるため、この様に監視データの収集制御をフレーム単位又は通知点単位で管理すると、制御が容易となる上、多様な管理単位で制御できる。なお、上記所定の情報は対応するデータ量そのものであっても良いことは明らかである。
【００１２】
また本発明（３）の被監視装置は、監視装置と複数の被監視装置とが相互に接続し、各被監視装置から監視装置に監視フレームを送信するシステムの被監視装置において、自装置内の通知待ち監視データが所定以上となったことにより該通知待ち監視データのデータ量に係る所定の情報を監視装置に通知し、監視装置より該監視装置が許容可能なデータ量の範囲内で通知してきた容量の監視情報を監視装置に通知するものである。これは上記被監視装置の部分をクレームしたものである。
【００１４】
また好ましくは、本発明（４）においては、上記本発明（３）において、前記各所定の情報は対応するデータ量を通知フレーム数又は通知点数に換算した情報である。
また本発明（５）の監視装置は、監視装置と複数の被監視装置とが相互に接続し、各被監視装置から監視装置に監視フレームを送信するシステムの監視装置において、自装置内の通知待ち監視データが所定以上となったことを検出した被監視装置より前記通知待ち監視データのデータ量に係る所定の情報を通知されたことにより、該通知された情報に基づき、かつ自身が当該被監視装置に対して許容可能な蓄積データ量の範囲内で、当該被監視装置の監視フレームを通知可能とするものである。これは上記監視装置の部分をクレームしたものである。
【００１５】
好ましくは、本発明（６）においては、上記本発明（５）において、監視装置は、監視データのトラフィック量に基づき求められた輻輳中及び輻輳予定の被監視装置の台数Ｓcnqstと、監視データの最大蓄積可能データ量に係る所定の情報Ｉｍａｘと、現時点の蓄積データ量に係る所定の情報Ｉｃｕｒとに基づき、通知待ち監視データのデータ量に係る所定の情報を通知してきた被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐを、
Ｐ＝（Ｉｍａｘ−Ｉｃｕｒ）／Ｓcnqst
により求める。
【００１６】
ところで、今、定常時における監視フレームの送信レートを一定とし、かつ警報や状態変化が少ない場合の１監視フレーム（例えば最大１８０点分通知可能）に含まれる通知点数を数点〜数十点と仮定する。この状態では生成監視データは各監視フレームにより漏れなく通知され、よって被監視装置における監視データの輻輳は生じ得ない。しかし、何らかの理由で警報や状態変化が頻発すると、これに伴い通知点数（即ち、単位時間当たりのトラフィック量）が増大し、やがて１フレームに全監視データを搭載しきれなくなり、この様な被監視装置は実際に輻輳状態となる（即ち、輻輳通知をしてくる）可能性が高い。
【００１７】
そこで、本発明（６）においては、監視装置は、係る状況下でも残余の蓄積メモリを最大限に活用し、かつ輻輳中及び上記輻輳予定の各被監視装置から夫々公平に輻輳監視データを収集できる様に、該輻輳中及び輻輳予定の各被監視装置に対して夫々に許容可能な蓄積データ量に係る所定の情報Ｐを予め求める。
この場合に、輻輳中及び輻輳予定の被監視装置の台数Ｓcnqstは、例えば監視データ（通知点）のトラフィック量が所定閾値を越えた被監視装置の台数として簡単に求められる。この台数の中には既に通知中（輻輳中）の被監視装置も含まれる。そして、実際に輻輳通知をしてきた被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐを、
Ｐ＝（Ｉｍａｘ−Ｉｃｕｒ）／Ｓcnqst
により求める。
【００１８】
具体的に言うと、例えばＩmax ＝１０単位，Ｉcur ＝２単位，Ｓcngst ＝２台とすると、Ｐ＝（１０−２）／２＝４単位となり、実際に輻輳通知をしてきた１又は２台の被監視装置に対して夫々に最大４単位分の許容蓄積データ量を余分に配分できる。また、例えばＩmax ＝１０単位，Ｉcur ＝６単位，Ｓcngst ＝４台とすると、Ｐ＝（１０−６）／４＝１となり、実際に輻輳通知をしてきた１乃至４台の被監視装置に対して夫々に最大１単位分の許容蓄積データ量を余分に配分できる。従って、上記本発明（７）によれば、輻輳中及び輻輳予定の被監視装置の台数Ｓcngst に応じて、監視装置の現時点の許容蓄積データ量を平準化して配分可能とする構成により、同時に複数の被監視装置が輻輳中となっても、それらからの監視データを公平にかつ効率よく一括収集できる。
【００１９】
また好ましくは、本発明（７）においては、上記本発明（６）において、監視装置は、被監視装置の台数Ｓと、監視データのトラフィック量に応じて各被監視装置を夫々Ｎ段階にランク付けした整数値Ｎｉとに基づき、輻輳中及び輻輳予定の被監視装置の台数Ｓcnqstを、
Ｓcnqst＝Ｓ−Σｉ（１／Ｎｉ） 但し、ｉ＝１〜Ｓ
により求める。
【００２０】
例えばＳ＝３台，Ｎ1 〜Ｎ3 ＝１（通常）とすると、Ｓcngst ＝３−｛（１／１）＋（１／１）＋（１／１）｝＝０となり、輻輳及び輻輳予定の被監視装置の台数Ｓcngst は０台と推定される。これは現実と良く一致している。但し、Ｓcngst ＝０の場合はＳcngst ＝１としても良い。これはＳcngst が分母に用いられる場合の制限である。また、最小でもＳcngst ＝１としておくと、最小でも１台分の輻輳を予定していることとなり、不測の輻輳発生に対処できる。
【００２１】
また例えばＳ＝３台，Ｎ１＝１（通常），Ｎ２＝６（輻輳中），Ｎ３＝３（輻輳予定）とすると、Ｓｃｎｑｓｔ＝３−｛（１／１）＋（１／６）＋（１／３）｝＝（９／６）＝１．５台となり、被監視装置＃３が輻輳通知をしてもこれに十分な許容蓄積データ量Ｐを配分できる。
従って、本発明（７）によれば、監視データのトラフィック量に応じて各被監視装置を夫々Ｎ段階にランク付けした整数値Ｎｉを使用することにより、輻輳及び輻輳予定の被監視装置の台数Ｓｃｎｑｓｔを監視データのトラフィック量に応じてきめ細かく管理できる。
【００２２】
また好ましくは、本発明（８）においては、上記本発明（６）において、監視装置は、被監視装置より通知待ち監視データのデータ量に係る所定の情報を通知された際に、該被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐ＞０の場合は、通知許可のデータ量に係る所定の情報ｒをｒ≦Ｐの範囲内で求め、これを前記被監視装置に通知する。この場合でも、被監視装置は、少なくとも指定情報ｒ分の監視データを通知でき、輻輳状態を緩和できる。
【００２３】
また好ましくは、本発明（９）においては、上記本発明（６）において、監視装置は、被監視装置より通知待ち監視データのデータ量に係る所定の情報を通知された際に、該被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐ＝０の場合は、前記被監視装置に監視データの通知停止を通知する。この場合は、当該被監視装置においてその輻輳監視データが廃棄される結果となるが、監視装置における他の被監視装置からの監視データの収集制御には何らの影響も与えない。
【００２４】
また好ましくは、本発明（１０）においては、上記本発明（９）において、監視装置は、被監視装置に監視データの通知停止を通知した場合に、その後該被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐ＞０となった場合は、前記被監視装置に監視データの通知再開を通知する。従って、従来の様に保守者の手を煩わすことも無く、監視データの収集は自動的に再開される。
【００２５】
また好ましくは、本発明（１１）においては、上記本発明（５）〜（１０）において、前記各所定の情報は対応するデータ量を通知フレーム数又は通知点数に換算した情報である。
【００２６】
【発明の実施の形態】
以下、添付図面に従って本発明に好適なる実施の形態を詳細に説明する。なお、全図を通して同一符号は同一又は相当部分を示すものとする。
図２は実施の形態によるネットワーク監視方式の構成を示す図で、監視装置３０と複数の被監視装置１０（＃１〜＃ｎ）とがバス型の伝送路を介して相互に接続する場合のネットワーク監視方式の例を示している。
【００２７】
図において、１０は実施の形態による被監視装置（ノード）＃１〜＃ｎ、１１はフレーム送／受信部、１２は通知待ちの監視データを一時的に保持する待ちキュー部、１３は監視データの収集及び待ちキュー部１２へのキューイング処理等を行うプロトコル処理部、１４は本来のデータ通信制御及び該データ通信制御に関する監視データの収集（生成）を行う制御処理部、１５はその他の監視データを収集する監視処理部、１６は監視装置３０からのポーリングフレームを解析して必要な処理を行う通知制御部、１７は監視フレームの一括通知制御に必要な情報を保持する通知管理テーブル、１８は待ちキュー部１２からの監視データのデキュー処理及び監視データの輻輳有無の検査を行う輻輳通知部である。
【００２８】
また、３０は実施の形態による監視装置、３１はフレーム送／受信部、３２は各被監視装置１０に対するポーリング制御、通知制御及び運用被監視装置の台数等の管理を行う定常監視部、３３は受信したポーリング応答フレームや監視フレームの内容解析及びフレーム管理バッファ３６への必要な情報の蓄積制御を行うフレーム蓄積管理部、３３Ａはポーリング応答フレームの内容に基づき被監視装置の輻輳判定を行う輻輳判定部、３４は単位時間当たりの通知点数に基づき被監視装置毎のトラフィック量を求め、夫々をＮ段階にランク付けするトラフィック管理部、３５は被監視装置毎の通知制御情報等を管理する被監視装置状態管理テーブル、３６は被監視装置毎の監視フレームの内容等を蓄積するフレーム管理バッファ、３７は被監視装置毎のトラフィック量やランク値を保持するトラフィック管理テーブル、３８はフレーム管理バッファ３６の監視データを上位監視装置に通知する監視通知部、９０は外部の上位監視装置、８０は伝送路である。
【００２９】
ここで、上記各部が参照する各種テーブル、バッファ、及び監視装置３０と各被監視装置１０との間でやりとりするポーリングフレーム、ポーリング応答フレームについて説明しておく。
図３，図４は実施の形態による各種テーブル等を説明する図（１），（２）であり、図３（Ａ）は監視装置における被監視装置状態管理テーブル３５の構成を示す。被監視装置状態管理テーブル３５は、運用中の全被監視装置の台数（Ｓ）、輻輳中（輻輳予定を含む）の被監視装置の総数（Ｓcngst ）、監視装置の許容蓄積フレーム量（Ｐf ）、許容蓄積通知量（Ｐt ）を夫々記憶する欄を備える。また監視装置３０から各被監視装置＃１〜＃ｎに通知するための一括通知フレーム数（ｒf1〜ｒfn）、一括通知許可数（ｒt1〜ｒtn）、通知停止指示を夫々に記憶する欄を被監視装置毎に備える。
【００３０】
図３（Ｂ）は監視装置におけるフレーム管理バッファ３６の構成を示す。フレーム管理バッファ３６は、監視装置の最大蓄積フレーム量（Ｆmax ）、現蓄積フレーム量（Ｆcur ）、最大蓄積通知量（Ｔmax ）、現蓄積通知量（Ｔcur ）を夫々記憶する欄を備える。また各被監視装置＃１〜＃ｎから受信された現受信フレーム量（Ｒf1〜Ｒfn）、現受信通知量（Ｒt1〜Ｒtn）を夫々記憶する欄を被監視装置毎に備える。更に各被監視装置＃１〜＃ｎから送られた監視フレームの情報（通知情報＃１〜＃ｎ）を夫々記憶する欄を被監視装置毎に備える。
【００３１】
図４（Ａ）は監視装置におけるトラフィック管理テーブル３７の構成を示す。トラフィック管理テーブル３７は、各被監視装置＃１〜＃ｎにつき夫々に求めた単位時間当たりのフレームトラフィック量（ＴＲf1〜ＴＲfn）、通知トラフィック量（ＴＲt1〜ＴＲtn）を夫々記憶する欄を被監視装置毎に備える。また前記フレームトラフィック量及び通知トラフィック量につき夫々Ｎ段階にランク付けされたフレーム輻輳ランク（Ｎf1〜Ｎfn）、通知輻輳ランク（Ｎt1〜Ｎtn）を夫々記憶する欄を被監視装置毎に備える。
【００３２】
図４（Ｂ）は被監視装置における通知管理テーブル１７の構成を示す。通知管理テーブル１７は、装置内で収集された監視データが時々刻々とキューイング／デキューされる中で、現時点の待ちキュー内フレーム数、待ちキュー内通知点数を夫々記憶する欄を備える。また監視装置３０から通知された一括通知フレーム数（ｒf ）、一括通知許可数（ｒt ）の通知制御情報を記憶する欄を備える。
【００３３】
図１２は実施の形態によるポーリングフレームのフォーマットを示す図で、監視装置３０から各被監視装置１０に送信される。図において、第１オクテットは送信先（被監視装置）ＩＤ、第２，第３オクテットはアプリケーション（ＡＰ）データユニット識別子であり、該第２オクテットのビットｂ2 は通知再開指示ビット、ビットｂ3 は通知停止指示ビット、ビットｂ4 は一括通知指示ビットとして夫々使用される。なお、上記一括通知指示ビットがＯＮとされる時は、同時に第４オクテットに一括通知フレーム数ｒf の情報及び又は第５オクテットに一括通知許可数ｒt の情報が搭載される。
【００３４】
図１３は実施の形態によるにポーリング応答フレームのフォーマットを示す図で、各被監視装置１０から監視装置３０に送信される。図において、第１オクテットは送信先（監視装置）ＩＤ、第２，第３オクテットはＡＰデータユニット識別子であり、該第２オクテットのビットｂ3 は通知点数が輻輳していることを表す通知輻輳通知ビット、ビットｂ4 はキュー（フレーム）数が輻輳していることを表すキュー輻輳通知ビットとして夫々使用される。なお、通知輻輳通知ビット又はキュー輻輳通知ビットがＯＮとされる時は、同時に第４オクテットに監視装置３０に送りたい総通知点数又はフレーム総数の情報が搭載される。更に、第５オクテットはポーリング応答フレームのデータ長（この例では１１バイト固定とする）、第６〜第８オクテットは応答フレームの転送時刻、第９オクテットは被監視装置の置かれているフロア・群、そして、第１０，第１１オクテットは架番号である。なお、図示しないが、各被監視装置１０から監視装置３０に送信される監視フレームが存在する。
【００３５】
以下、監視装置及び被監視装置における上記各主要構成部の制御・処理をフローチャートに従って説明する。まず監視装置を説明する。
図５，図６は実施の形態による定常監視処理のフローチャート（１），（２）である。定常監視部３２は、定期的に（例えば１秒間隔で）起動され、その都度被監視装置の通知制御に必要な各種パラメータＳcngst ，Ｐf ，Ｐt を更新すると共に、各被監視装置を順にポーリングし、その応答有／無に基づいて運用中の被監視装置の台数Ｓを更新する等の処理を行う。またポーリングの際には、必要ならポーリングフレームに通知制御情報を搭載して送信し、併せて各被監視装置の通知制御を行う。以下、詳細に説明する。
【００３６】
図５において、ステップＳ１では輻輳中（輻輳予定を含む）の被監視装置数Ｓcngst を、
Ｓcngst ＝Ｓ−Σ（１／Ｎi ） ｉ＝１〜Ｓ
により求め、これを被監視装置状態管理テーブル３５に格納する。
ここで、Ｎi は被監視装置毎のフレームトラフィック量又は通知トラフィック量に対応する重み係数（例えばＮ段階の整数１〜Ｎ）を表し、トラフィック量の多い被監視装置のＮi は大きく、またトラフィック量の少ない被監視装置のＮi は小さい。詳細は後述する。上記式によれば、輻輳中の被監視装置数Ｓcngst は、トラフィック量の多い被監視装置が多い場合は大きく、またトラフィック量の多い被監視装置が少ない場合は小さくなる。但し、Ｓcngst ＝０の場合は、Ｓcngst ＝１とする。
【００３７】
ステップＳ２では、上記求めたＳcngst 及びフレーム管理バッファ３６中の最大蓄積フレーム量Ｆmax 、現蓄積フレーム量Ｆcur に基づき許容蓄積フレーム量Ｐf を、
Ｐf ＝（Ｆmax −Ｆcur ）／Ｓcngst
により求め、これを被監視装置状態管理テーブル３５に格納する。
【００３８】
ステップＳ３では上記求めたＳcngst 及びフレーム管理バッファ３６中の最大蓄積通知量Ｔmax 、現蓄積通知量Ｔcur に基づき許容蓄積通知量Ｐt を、
Ｐt ＝（Ｔmax −Ｔcur ）／Ｓcngst
により求め、これを被監視装置状態管理テーブル３５に格納する。
ステップＳ４では、運用中の各被監視装置にポーリングするため、レジスタｎに全被監視装置数Ｓ、カウンタｉ，ｊに夫々０をセットする。ステップＳ５では被監視装置状態管理テーブル３５から被監視装置＃ｉに対する通知制御情報を読み出し、ステップＳ６では通知停止指示有りか否かを判別する。有りの場合は更にステップＳ９で許容蓄積フレーム量Ｐf ＞０又は許容蓄積通知量Ｐt ＞０か否かを調べる。Ｐf ＞０又はＰt ＞０でない場合は、監視装置のフレームバッファに余裕が無いので、ステップＳ１０でポ−リングフレ−ムに通知停止指示ビット＝１（ＯＮ）をセットする。またＰf ＞０又はＰt ＞０の場合は、監視装置のフレームバッファに余裕ができたので、ステップＳ１１でポ−リングフレ−ムに通知再開指示ビット＝１をセットする。
【００３９】
また、上記ステップＳ６の判別で通知停止指示無しの場合は、更にステップＳ７で一括フレーム通知数有りか否かを調べる。有りの場合は、ステップＳ１２でポ−リングフレ−ムに一括通知指示ビット＝１及び一括通知フレーム数ｒf をセットする。
また、上記ステップＳ７の判別で一括フレーム通知無しの場合は、更にステップＳ８で一括通知許可数有りか否かを調べる。有りの場合は、ステップＳ１３でポ−リングフレ−ムに一括通知指示ビット＝１及び一括通知許可数ｒt をセットする。
【００４０】
制御は図６に進み、ステップＳ１４ではポ−リングフレ−ムを送信する。ステップＳ１４では所定時間の間ポ−リング応答フレ−ムを待ち、応答があった場合は、当該被監視装置は運用されているので、ステップＳ１６でカウンタｊに＋１する。また応答が無い場合はステップＳ１６の処理をスキップする。ステップＳ１７ではカウンタｉに＋１し、ステップＳ１８ではｉ＜ｎか否かを判別する。ｉ＜ｎの場合はステップＳ５に戻り、次の被監視装置に対する上記処理を行う。
【００４１】
こうして、やがて、全被監視装置に対する上記処理を終了すると、ステップＳ１８の判別でｉ＝ｎとなる。ステップＳ１９では被監視装置状態管理テーブル３５の全被監視装置数Ｓにカウンタｊの内容（ポーリング応答のあった被監視装置数）をセットし、この処理を抜ける。
図７は実施の形態によるフレーム受信処理のフローチャートで、フレーム蓄積管理部３３が被監視装置からの監視フレームを受信するとこの処理に入力する。なお、ここでは被監視装置が送信する監視フレーム内に、監視データと共に、監視装置に通知するための輻輳情報（総フレーム数、総通知点数）を搭載できる場合を説明する。
【００４２】
ステップＳ２１ではフレーム管理バッファ３６の現蓄積フレーム量Ｆcur に＋１（フレーム）し、かつ被監視装置毎に管理する現受信フレーム量Ｒf に＋１（フレーム）する。ステップＳ２２では監視フレームの内容を通知点数に換算し、その通知点数を現蓄積通知量Ｔcur 及び当該被監視装置に対応する現受信通知量Ｒt に夫々加算する。
【００４３】
ステップＳ２３では輻輳判定部３３Ａが受信フレーム中に総フレーム数がセットされているか否かを調べる。セットされている場合はステップＳ２６で、その時点における許容蓄積フレーム量Ｐf との関係に基づき、当該被監視装置に割り当てるべき一括フレーム通知数ｒf を求める。具体的に言うと、Ｐf ≧総フレーム数の場合はｒf ＝総フレーム数とし、また０≦Ｐf ＜総フレーム数の場合はｒf ＝Ｐf とし、またＰf ＝０の場合はｒf ＝０とする。
【００４４】
ステップＳ２７ではｒf ＝０か否かを判別する。ｒf ＝０の場合は、フレーム管理バッファ３６に余裕が無いので、ステップＳ２８で被監視装置状態管理テーブル３５の当該被監視装置の制御情報格納欄に通知停止指示を格納する。またｒf ≠０の場合はステップＳ２９で被監視装置状態管理テーブル３５に前記求めた一括通知フレーム数ｒf を格納する。
【００４５】
また輻輳判定部３３Ａは、上記ステップＳ２３の判別で総フレーム数がセットされていない場合は、更にステップＳ２４で受信フレーム中に総通知点数がセットされているか否かを調べる。セットされている場合はステップＳ３０で、その時点における許容蓄積通知量Ｐt との関係に基づき、当該被監視装置に割り当てるべき一括通知許可数ｒt を求める。具体的に言うと、Ｐt ≧総通知点数の場合はｒt ＝総通知点数とし、また０≦Ｐt ＜総通知点数の場合はｒt ＝ｐt とし、またＰt ＝０の場合はｒt ＝０とする。
【００４６】
ステップＳ３１ではｒt ＝０か否かを判別する。ｒt ＝０の場合は、フレーム管理バッファ３６に余裕が無いので、ステップＳ３２で被監視装置状態管理テーブル３５の当該被監視装置の制御情報格納欄に通知停止指示を格納する。またｒt ≠０の場合はステップＳ３３で被監視装置状態管理テーブル３５に前記求めた一括通知許可数ｒt を格納する。ステップＳ２５では監視フレームの監視データをフレーム管理バッファ３６の当該被監視装置の欄に格納し、処理を抜ける。
【００４７】
なお、被監視装置は上記輻輳情報（総フレーム数、総通知点数）をポーリング応答フレームに搭載して通知するように構成しても良い。この方法は後述の実施例の説明で示される。
図８は実施の形態によるトラフィック管理処理のフローチャートである。
トラフィック管理部３４は、定期的（例えば１秒間隔）に起動され、以下の処理を全被監視装置について行う。即ち、ステップＳ４１ではフレーム管理バッファ３６より現受信フレーム量Ｒf 及び現受信通知量Ｒt を獲得する。ステップＳ４２では単位時間（例えば１秒）当たりのフレームトラフィック量ＴＲf 及び通知トラフィック量ＴＲt を夫々算出し、これらをトラフィック管理テーブル３７に格納する。ステップＳ４３では前記求めたフレームトラフィック量ＴＲf 及び通知トラフィック量ＴＲt を夫々Ｎ段階（例えば１〜６段階）にランク付けする。ステップＳ４４では求めたランク値をトラフィック管理テーブル３７に格納する。ステップＳ４５ではフレーム管理バッファ３６の当該現受信フレーム量Ｒf 及び現受信通知量Ｒt をクリアする。
【００４８】
以下、被監視装置における制御・処理を説明する。
図９は実施の形態によるキューイング処理のフローチャートである。プロトコル処理部１３は、ステップＳ５１で通知停止中か否かを判別する。被監視装置がポーリングフレームで通知停止指示を受け取った場合は通知停止中である。この場合はそのまま処理を抜ける。また通知停止中でない場合は、ステップＳ５２で待ちキュー部１２に１フレーム分の監視データをキューイングする。ステップＳ５３では通知管理テーブル１７の待ちキュー内フレーム数に＋１し、かつ待ちキュー内通知点数に該キューイングしたフレームの通知点数を加算する。
【００４９】
図１０は実施の形態によるデキュー処理のフローチャートである。
輻輳通知部１８は、定期的に（例えば１秒間隔で）起動され、待ちキュー部１２からの監視データのデキューを行う。即ち、ステップＳ６１では本装置に対して一括フレーム通知又は一括通知許可が有る状態か否かを判別する。無い場合はステップＳ６２で、通常に従い、１フレーム分のデキューを行う。ステップＳ６３では通知管理テーブル１７内の待ちキュー内フレーム数を獲得し、上記デキュー分をマイナスする。ステップＳ６４では残りのキュー数が上限値のＮ1 ％以上か否かを判別する。Ｎ1 ％以上の場合は、本装置が輻輳状態であると判断し、そのデキューフレーム中に残りの待ちキュー内総フレーム数をセットする。またＮ1 ％以上でない場合はステップＳ６５の処理をスキップする。
【００５０】
ステップＳ６６では通知管理テーブル１７の待ちキュー内通知点数を獲得し、上記デキュー分をマイナスする。ステップＳ６７では通知点数が上限値のＮ2 ％以上か否かを判別する。Ｎ2 ％以上の場合は、本装置が輻輳状態であると判断し、そのデキューフレーム中に待ちキュー内通知点数をセットする。またＮ2 ％以上でない場合はステップＳ６８の処理をスキップする。
【００５１】
また、上記ステップＳ６１の判別で一括フレーム通知又は一括通知許可がある状態の場合は、ステップＳ７０で一括通知分の連続デキューを行う。ステップＳ７１では送信フレームに再輻輳通知情報をセットする。そして、ステップＳ６９では上記デキュー分の監視フレームを一つ又は複数連続（一括）で監視装置３０に送信する。従って、通常は、例えば１秒間に１フレームの割合の監視フレームの通知となるが、監視装置に輻輳通知をした結果、監視装置から一括通知を許可されると、例えば１秒間に数フレームの割合で監視フレームを一括通知できることとなる。
【００５２】
図１１は実施の形態による通知指示処理のフローチャートである。
通知制御部１６は、監視装置からのポーリングフレームを受信すると、ステップＳ８１でポーリングフレーム内の指示ビットを検査する。ステップＳ８２では一括通知指示ビット＝１か否かを判別し、一括通知指示ビット＝１の場合はステップＳ８６で通知管理テーブル１７に一括処理情報（一括通知フレーム数ｒf 又は一括通知許可数ｒt ）を格納し、ステップＳ８５に進む。
【００５３】
また一括通知指示ビット＝１でない場合は、ステップＳ８３で更に通知停止指示ビット＝１か否かを判別する。通知停止指示ビット＝１の場合はステップＳ８７で輻輳通知部１８及びプロトコル処理部１３に通知停止を依頼し、ステップＳ８５に進む。これにより輻輳通知部１８は待ちキュー部１２の待ちキュー行列からのデキューを停止し、プロトコル処理部１３は待ちキュー部１２へのキューイングの停止及び待ちキュー行列のクリアを行う。
【００５４】
また通知停止指示ビット＝１でない場合は、ステップＳ８４で更に通知再開指示ビット＝１か否かを判別する。通知再開指示ビット＝１の場合はステップＳ８７で輻輳通知部１８及びプロトコル処理部１３に通知再開を依頼する。これにより輻輳通知部１８は待ちキュー部１２からのデキューを再開し、プロトコル処理部１３は待ちキュー部１２へのキューイングを再開する。そして、ステップＳ８５ではポーリング応答フレームを送信する。
【００５５】
以下、システム全体の動作を、いくつかのケースに従って説明する。
まず、被監視装置が輻輳状態になった場合の監視装置による一括通知指示の動作を説明する。被監視装置１０において、輻輳通知部１８は待ちキュー部１２からのデキュー時に待ちキュー内フレーム数を獲得すると共に、待ちキュー内フレーム数が上限値のＮ1 ％に達している場合は、輻輳状態にあると判断し、該デキューフレーム中に待ちキュー内の総フレーム数をセットし、監視装置３０へ通知する。
【００５６】
また、輻輳通知部１８は待ちキュー部１２からのデキュー時に待ちキュー内通知点数を獲得すると共に、待ちキュー内通知点数が上限値のＮ2 ％に達している場合は、輻輳状態にあると判断し、該デキューフレーム中に待ちキュー内の総通知点数をセットし、監視装置３０へ通知する。
監視装置３０において、輻輳判定部３３Ａは受信フレーム内に総フレーム数がセットされているのを認識すると、許容蓄積フレーム量Ｐf を越えない範囲内で、一括フレーム通知数ｒf を求める。更に当該監視フレームの内容をフレーム管理バッファ３６に格納し、被監視装置状態管理テーブル３５に上記求めた一括通知フレーム数ｒf を格納する。
【００５７】
また、輻輳判定部３３Ａは受信フレーム内に総通知点数がセットされているのを認識すると、許容蓄積通知量Ｐt を越えない範囲内で、一括通知許可数ｒt を求める。更に当該監フレームの内容をフレーム管理バッファ３６に格納し、被監視装置状態管理テーブル３５に上記求めた一括通知許可数ｒt を格納する。
一方、定常監視部３２が定期的に起動されると、定常監視部３２は被監視装置状態管理テーブル３５から上記格納された一括通知フレーム数ｒf 、一括通知許可数ｒt を獲得すると共に、これをポーリングフレーム中に一括通知許可ビットと共にセットし、当該被監視装置１０に対して通知する。また被監視装置状態管理テーブル３５の当該一括通知フレーム数ｒf 、一括通知許可数ｒt をクリアする。
【００５８】
被監視装置１０において、通知制御部１６がポーリングフレーム中に一括通知許可ビットと一括通知フレーム数ｒf ／一括通知許可数ｒt がセットされているのを認識すると、輻輳通知部１８に対して一括通知処理を依頼する。これを受けた輻輳通知部１８は通知された一括通知フレーム数ｒf ／一括通知許可数ｒt 分の監視データの連続デキューを行い、監視装置３０に対して通知する。この時、以下の条件により、監視フレームに輻輳情報をセットする。
【００５９】
即ち、待ちキュー数が上限値を超えている場合に、一括通知フレーム数ｒf ＝現キュー数の場合は、現キュー数＝０とする。この場合は１回の連続デキューで輻輳状態が解消されたことになる。また一括通知フレーム数ｒf ＜現キュー数の場合は現キュー数＝現キュー数−一括通知フレーム数ｒf とする。この場合は１回の連続デキューで通知しきれなかった分の現キュー数（残り分）が再度輻輳通知される。
【００６０】
また、通知点数が上限値を超えている場合に、一括通知許可数ｒt ＝現通知点数の場合は現通知点数＝０とする。この場合は１回の連続デキューで輻輳状態が解消されたことになる。また一括通知許可数ｒt ＜現通知点数の場合は現通知点数＝現通知点数−一括通知許可数ｒt とする。この場合は１回の連続デキューで通知しきれなかった分の現通知点数（残り分）が再度輻輳通知される。
【００６１】
次に被監視装置が輻輳状態になった場合の監視装置による通知停止指示の動作を説明する。上記図７のフレーム受信処理において、Ｐf ＝０又はＰt ＝０のため、ｒf ＝０又はｒt ＝０と判定された場合には、監視装置３０の側には許容バッファ量がなく、監視装置自身が輻輳状態であると判断して、当該受信監視フレームの内容をフレーム管理バッファ３６に格納すると共に被監視装置状態管理テーブル３５に通知停止指示がセットされる。
【００６２】
一方、定常監視部３２が定期的に起動されると、定常監視部３２は被監視装置状態管理テーブル３５から通知停止指示を獲得すると共に、ポーリングフレーム中に通知停止指示ビットをセットし、当該被監視装置に対して通知する。
被監視装置１０において、通知制御部１６はポーリングフレーム中に通知停止指示ビット＝１がセットされているのを認識すると、プロトコル処理部１３及び輻輳通知部１８に対して通知停止処理を依頼し、これにより輻輳通知部１８は待ちキュー部１２の待ちキュー行列からのデキューを停止し、またプロトコル処理部１３は待ちキュー行列へのキューイングの停止及び待ちキュー行列のクリアを行う。
【００６３】
次に、上記通知停止指示を受けた被監視装置に対して、輻輳状態が緩和された監視装置より通知再開指示が送られた場合の動作を説明する。定常監視部３２がＰf ＞０又はＰt ＞０と判断した時に、被監視装置状態管理テーブル３５に通知停止指示状態にある被監視装置が存在する場合は、ポーリングフレーム中に通知再開指示ビット＝１をセットし、当該被監視装置に対して通知する。これを受けた被監視装置では、通知制御部１６よりプロトコル処理部１３及び輻輳通知部１８に対して通知再開処理を依頼し、これによりプロトコル処理部１３は待ちキュー部１２へのキューイングの再開を行い、輻輳通知部１８は待ちキュー行列からのデキューを再開する。
【００６４】
以下、バス上に接続された１台の監視装置と複数（例えば３台）の被監視装置とに対して本発明を適用した一実施例を具体的数値例に従って説明する。
被監視装置１０において、監視装置３０への監視フレームの送出間隔は１秒間隔、１フレーム内に含まれる通知点数は可変でその最大値は１８０点とする。また待ちキュー内フレーム数の上限値は１０フレームであり、輻輳通知のしきい値としてＮ1 ％→１０％（１フレーム）とする。但し、一括通知後の待ちキュー内に残存フレームがある場合には輻輳通知を行う。また待ちキュー内通知点数の最大値は１０×１８０＝１８００点であり、輻輳通知のしきい値としてＮ2 ％→２％（３６点）とする。
【００６５】
監視装置３０において、被監視装置１０に対するポーリング間隔は１秒間隔とし、フレーム管理バッファ３６に格納できる最大の通知点数（Ｔmax ）は１０００００点、従って、Ｆmax ＝（１０００００／１８０）＝５５５フレームとする。またトラフィック測定のための単位時間は１秒とする。なお、この例では被監視装置１０からの監視フレームの到着時間は１秒間隔のため、フレームトラフィック量ＴＲf は常に１となる。一方、通知トラフィック量ＴＲt については１秒単位で収集し、例えば以下の如く通知輻輳ランクＮt の重み付けを行う。
【００６６】
Ｎt ＝１： 通知トラフィック量ＴＲf ≦ １個／ｓ
Ｎt ＝２： １個／ｓ＜通知トラフィック量ＴＲf ≦ ３６個／ｓ
Ｎt ＝３： ３６個／ｓ＜通知トラフィック量ＴＲf ≦ ７２個／ｓ
Ｎt ＝４： ７２個／ｓ＜通知トラフィック量ＴＲf ≦１０８個／ｓ
Ｎt ＝５：１０８個／ｓ＜通知トラフィック量ＴＲf ≦１４４個／ｓ
Ｎt ＝６：１４４個／ｓ＜通知トラフィック量ＴＲf ≦１８０個／ｓ
係る構成で、以下、全被監視装置からのポーリング応答以外の通知がない状態（即ち、監視装置側は蓄積フレーム及び蓄積通知がない状態）から、被監視装置＃１のみが輻輳状態になった場合の動作を説明する。
【００６７】
＜被監視装置からの輻輳通知＞
被監視装置＃１において、待ちキュー内に３フレーム分、各フレーム内に５通知点数分が存在するとすると、輻輳通知部１８は、デキュー時に通知管理テーブル１７内の待ちキュー内フレーム数を１つデクリメントし、かつ待ちキュー内通知点数をデキューフレーム内の通知点数分デクリメントする。
【００６８】
この例では、ポーリングフレームの応答時に上記待ちキュー内フレーム数、待ちキュー内通知点数の残数をチェックする。この時、残フレーム数＝２（＞Ｎ1 ％）、残通知点数＝１０（＜Ｎ2 ％）である。この結果、ポーリング応答フレームにキュー輻輳通知ビット＝１、フレーム総数＝２を搭載し、監視装置３０に通知する。
【００６９】
＜監視装置での輻輳判定と一括通知許可＞
監視フレームの受信前において、定常監視部３２では、被監視装置からの監視データが無いことから、Ｓcngst ＝１，Ｐr ＝Ｆmax 、Ｐt ＝Ｔmax となる。またトラフィック管理でも、フレームトラフィック＝１、通知トラフィック＝０となり、フレーム輻輳ランクＮf ＝通知輻輳ランクＮt ＝１となっている。
【００７０】
輻輳通知を含むポーリング応答受信後において、輻輳判定部３３Ａにてキュー輻輳通知ビット＝１及びフレーム総数＝２を獲得すると、Ｐf ＝Ｆmax （＝５５５）であることから、フレーム総数２＜Ｐf よりｒf ＝２と判定され、被監視装置状態管理テーブル３５の当該被監視装置＃１の管理レコードに一括通知フレーム数ｒf1＝２をセットする。
【００７１】
＜一括通知許可を被監視装置へ通知＞
定常監視部３２は、被監視装置状態管理テーブル３５の各被監視装置毎の管理レコードを検索し、被監視装置＃１への一括通知フレーム数ｒf1＝２を獲得する。更に、ポーリングフレームに一括通知指示ビット＝１、一括通知フレーム数ｒf ＝２（一括通知許可数ｒt ＝０）をセットして被監視装置＃１宛のポーリングを発行する。
【００７２】
＜被監視装置にて一括通知許可受信＞
通知制御部１６は、ポーリングの受信フレームより２フレーム分の一括通知許可を得ると、通知管理テーブル１７の一括通知フレーム数ｒf の欄に２を加算する。輻輳通知部１８では、デキュー時に通知管理テーブル１７を検索し、一括通知フレーム数ｒf ＝２を獲得し、２フレーム分の連続デキューを行う。なお、各デキュー情報は２フレーム分の監視フレームに搭載され、自発的、連続的に送られる。また通知管理テーブル１７の待ちキュー内フレーム数から２をデクリメントし、残値をチェックする。この例では残値が０であるため、輻輳状態は解除されたと判断し、その後のポーリング応答フレームには輻輳通知は付加しないで送信する。また通知管理テーブル１７の一括通知フレーム数ｒf をクリアする。
【００７３】
なお、上記実施の形態ではバス型ネットワーク上におけるネットワーク監視方式の例を述べたが、本発明はスター型、リンク型等のネットワーク上における監視データ収集方式及びその装置にも適用できることは言うまでも無い。
また、上記実施の形態ではネットワーク監視方式の例を述べたが、本発明は例えば架構成のシェルフに搭載される複数の各種機能ユニット（被監視基板等）から中央の監視ユニット（監視基板等）に監視情報を収集する場合にも適用できることは明らかである。
【００７４】
また、上記本発明に好適なる実施の形態を述べたが、本発明思想を逸脱しない範囲内で各部の構成、制御、及びこれらの組合せの様々な変更が行えることは言うまでも無い。
【００７５】
【発明の効果】
以上述べた如く本発明によれば、被監視装置から待ちキュー数が上限を超える前に輻輳状態であることを監視装置へ通知し、監視装置の許容蓄積量に余裕がある場合は、被監視装置からの一括通知を受け付けることにより、被監視装置の通知停止を防ぎ、監視を連続的に行うことが出来る。
【００７６】
また監視装置で許容蓄積量を超えた場合は、連続的に通知を発生させている被監視装置に対して通知を停止させることで、監視装置の安定運用を行うことが出来る。
また、監視装置から被監視装置への通知停止／再開が自動で行えるため、保守者のオペレーションが不要となる。
【図面の簡単な説明】
【図１】本発明の原理を説明する図である。
【図２】実施の形態によるネットワーク監視方式の構成を示す図である。
【図３】実施の形態による各種テーブル等を説明する図（１）である。
【図４】実施の形態による各種テーブル等を説明する図（２）である。
【図５】実施の形態による定常監視処理のフローチャート（１）である。
【図６】実施の形態による定常監視処理のフローチャート（２）である。
【図７】実施の形態によるフレーム受信処理のフローチャートである。
【図８】実施の形態によるトラフィック管理処理のフローチャートである。
【図９】実施の形態によるキューイング処理のフローチャートである。
【図１０】実施の形態によるデキュー処理のフローチャートである。
【図１１】実施の形態による通知指示処理のフローチャートである。
【図１２】実施の形態によるポーリングフレームのフォーマットを示す図である。
【図１３】実施の形態によるにポーリング応答フレームのフォーマットを示す図である。
【図１４】図１４は従来のネットワーク監視方式の構成を示す図である。
【符号の説明】
１０ 被監視装置
１１ フレーム送／受信部
１２ 待ちキュー部
１３ プロトコル処理部
１４ 制御処理部
１５ 監視処理部
１６ 通知制御部
１７ 通知管理テーブル
１８ 輻輳通知部
３０ 監視装置
３１ フレーム送／受信部
３２ 定常監視部
３３ フレーム蓄積管理部
３３Ａ 輻輳判定部
３４ トラフィック管理部
３５ 被監視装置状態管理テーブル
３６ フレーム管理バッファ
３７ トラフィック管理テーブル
３８ 監視通知部
８０ 伝送路
９０ 上位監視装置
Claims (11)
- 監視装置と複数の被監視装置とが相互に接続し、各被監視装置から監視装置に監視フレームを送信するシステムの監視データ収集方式において、
被監視装置は自装置内の通知待ち監視データが所定以上となったことにより該通知待ち監視データのデータ量に係る所定の情報を監視装置に通知し、
監視装置は、前記通知された情報に基づき、かつ自身が当該被監視装置に対して許容可能な蓄積データ量の範囲内で、当該被監視装置の監視フレームを通知可能とすることを特徴とする監視データ収集方式。 - 前記所定の情報は対応するデータ量を通知フレーム数又は通知点数に換算した情報であることを特徴とする請求項１に記載の監視データ収集方式。
- 監視装置と複数の被監視装置とが相互に接続し、各被監視装置から監視装置に監視フレームを送信するシステムの被監視装置において、
自装置内の通知待ち監視データが所定以上となったことにより該通知待ち監視データのデータ量に係る所定の情報を監視装置に通知し、監視装置より該監視装置が許容可能なデータ量の範囲内で通知してきた容量の監視情報を監視装置に通知することを特徴とする被監視装置。 - 前記各所定の情報は対応するデータ量を通知フレーム数又は通知点数に換算した情報であることを特徴とする請求項３に記載の被監視装置。
- 監視装置と複数の被監視装置とが相互に接続し、各被監視装置から監視装置に監視フレームを送信するシステムの監視装置において、
自装置内の通知待ち監視データが所定以上となったことを検出した被監視装置より前記通知待ち監視データのデータ量に係る所定の情報を通知されたことにより、該通知された情報に基づき、かつ自身が当該被監視装置に対して許容可能な蓄積データ量の範囲内で、当該被監視装置の監視フレームを通知可能とすることを特徴とする監視装置。 - 監視データのトラフィック量に基づき求められた輻輳中及び輻輳予定の被監視装置の台数Ｓcnqstと、監視データの最大蓄積可能データ量に係る所定の情報Ｉｍａｘと、現時点の蓄積データ量に係る所定の情報Ｉｃｕｒとに基づき、通知待ち監視データのデータ量に係る所定の情報を通知してきた被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐを、
Ｐ＝（Ｉｍａｘ−Ｉｃｕｒ）／Ｓcnqst
により求めることを特徴とする請求項５に記載の監視装置。 - 被監視装置の台数Ｓと、監視データのトラフィック量に応じて各被監視装置を夫々Ｎ段階にランク付けした整数値Ｎｉとに基づき、輻輳中及び輻輳予定の被監視装置の台数Ｓcnqstを、
Ｓcnqst＝Ｓ−Σｉ（１／Ｎｉ） 但し、ｉ＝１〜Ｓ
により求めることを特徴とする請求項６に記載の監視装置。 - 被監視装置より通知待ち監視データのデータ量に係る所定の情報を通知された際に、該被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐ＞０の場合は、通知許可のデータ量に係る所定の情報ｒをｒ≦Ｐの範囲内で求め、これを前記被監視装置に通知することを特徴とする請求項６に記載の監視装置。
- 被監視装置より通知待ち監視データのデータ量に係る所定の情報を通知された際に、該被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐ＝０の場合は、前記被監視装置に監視データの通知停止を通知することを特徴とする請求項６に記載の監視装置。
- 被監視装置に監視データの通知停止を通知した場合に、その後該被監視装置に対して許容可能な蓄積データ量に係る所定の情報Ｐ＞０となった場合は、前記被監視装置に監視データの通知再開を通知することを特徴とする請求項９に記載の監視装置。
- 前記各所定の情報は対応するデータ量を通知フレーム数又は通知点数に換算した情報であることを特徴とする請求項５乃至１０の何れか１に記載の被監視装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP00943198A JP4015733B2 (ja) | 1998-01-21 | 1998-01-21 | 監視データ収集方式及びその装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP00943198A JP4015733B2 (ja) | 1998-01-21 | 1998-01-21 | 監視データ収集方式及びその装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11215159A JPH11215159A (ja) | 1999-08-06 |
| JP4015733B2 true JP4015733B2 (ja) | 2007-11-28 |
Family
ID=11720153
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP00943198A Expired - Fee Related JP4015733B2 (ja) | 1998-01-21 | 1998-01-21 | 監視データ収集方式及びその装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4015733B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4664252B2 (ja) * | 2006-07-31 | 2011-04-06 | 富士通株式会社 | 監視ユニット及び被監視ユニット |
| JP2012063904A (ja) * | 2010-09-15 | 2012-03-29 | Toshiba Corp | ファイル通信装置およびファイル通信方法 |
-
1998
- 1998-01-21 JP JP00943198A patent/JP4015733B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11215159A (ja) | 1999-08-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6746087B2 (ja) | センサネットワークシステム | |
| JP4574600B2 (ja) | ゲートウェイ装置、データ集約装置、データ集約システム、データ送信方法、及びプログラム | |
| JPH0787096A (ja) | トラヒック制御方式およびネットワーク制御システム | |
| JPH1056469A (ja) | Ａｔｍネットワークにおける明示レート・フロー制御用の方法と装置 | |
| JP2836505B2 (ja) | 遠隔監視システム | |
| Gambhir et al. | DWBAN: Dynamic priority based WBAN architecture for healthcare system | |
| JP4015733B2 (ja) | 監視データ収集方式及びその装置 | |
| JP3309834B2 (ja) | Ａｔｍ交換装置及びセルバッファ使用率監視方法 | |
| JPH07168790A (ja) | 情報処理装置 | |
| JP2002171262A (ja) | 通信方法及びその通信システム | |
| CN115766586A (zh) | 一种can总线间的负载均衡控制系统 | |
| JP2005141466A (ja) | コンピュータの監視装置および監視対象のコンピュータに関するメッセージの処理方法 | |
| JP2836356B2 (ja) | 非同期転送モードにおける輻輳判定方式 | |
| JP2823710B2 (ja) | ビル管理システム | |
| JP2001084196A (ja) | ネットワーク管理システム | |
| JPH05191405A (ja) | 情報収集装置 | |
| JP3270235B2 (ja) | 通信回線ルート統制システム | |
| JP2004120592A (ja) | 通信ネットワークオペレーションシステム及び該通信ネットワークオペレーションシステムにおけるメッセージ送信制御方法 | |
| JPH02270426A (ja) | 通信制御方式 | |
| JP2002026908A (ja) | 通信の時限監視を可変とする監視管理システム | |
| JP2727672B2 (ja) | ポーリング方式 | |
| JP4284203B2 (ja) | ビル遠隔監視システム | |
| Rubin et al. | Performance Evaluation and Control of Distributed Computer Communication Networks. | |
| CN118101584A (zh) | 一种客户端的请求处理方法以及装置 | |
| El-Taha et al. | Queueing network models of credit-based flow control |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050105 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070104 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070116 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070316 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070911 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070914 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100921 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100921 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110921 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120921 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120921 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130921 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |