JP2001312783A

JP2001312783A - 災害推定システム及び方法

Info

Publication number: JP2001312783A
Application number: JP2000130913A
Authority: JP
Inventors: Yutaka Katsuyama; 豊勝山
Original assignee: Japan Science and Technology Corp
Current assignee: Japan Science and Technology Agency
Priority date: 2000-04-28
Filing date: 2000-04-28
Publication date: 2001-11-09

Abstract

(57)【要約】【課題】Ｗｅｂ上のネットワークをモニタし、被災地
の複数地点の情報を入手することで、被災地の特定及び
規模を推定する。【解決手段】一般ＣＬ端末３０の使用者がブラウザを
起動し（Ｓ２０１）、ノード１０内のサーバ１１の情報
を利用するために、Ｗｅｂサーバにアクセスする。この
際、一般ＣＬ端末３０に自動的にダウンロードされたＡ
Ｃは、ネットワークモニタ用に起動される（Ｓ２０
５）。また、ＡＣは、ＳＣ内のＣＬモニタとの間で、モ
ニタを開始する（Ｓ２０７）。次に、故障／災害が発生
した場合（Ｓ２１１）、ＣＬモニタは、モニタ信号不到
着を認識し（Ｓ２１３）、一定時間（例えば、１５秒）
待機後に再度不到着ならば（Ｓ２１５）、異常発生と判
断する（Ｓ２１７）。また、モニタデータは、ログとし
て定期的にサーバ内のＤＢに転送され保存される（Ｓ２
０９）。さらに、ノード１０内のＡＰを起動させ、災害
地点及び規模の推定を開始する（Ｓ２１９）。その際、
ＡＰは、関連するログを収集すると共に、災害地点及び
規模の推定を行う（Ｓ２２１）。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、災害推定システム
及び方法に係り、特に、Ｗｅｂ上のネットワークモニタ
を利用する災害推定システム及び方法に関する。

【０００２】

【従来の技術】近年、電話網、ＩＳＤＮ網、インターネ
ットに代表される通信網は、社会活動の神経系としての
役割を担っている。このため、通信網が機能停止した場
合、その社会的影響は、極めて大きくなることが予想さ
れる。通信網の故障・異常は、人為的、設備的な要因だ
けでなく、地震、風水害及び火災等の自然災害による要
因も考えられる。特に、自然災害が発生した場合、通信
網には、被災地への安否確認や見舞い呼等によって、過
剰なトラフィックが発生する、いわゆる「地域輻輳」が
発生し、通信機能が麻痺してしまう場合がある。

【０００３】そこで、特に自然災害等が発生した被災地
に関する情報が入手できるように、通信網の自然災害対
策が種々検討されている（渡辺和文「これからの災害
対策」、ＮＴＴ技術ジャーナルＰ．３０，１９９６年１
２月号等参照）。

【０００４】

【発明が解決しようとする課題】通信網の自然災害対策
では、被災地の特定とその規模の把握を明確にすること
が重要である。しかしながら、被災地の特定は、自然災
害時での通信網自体の障害により、困難を伴うことが多
いため、もっぱら他の情報の収集に依存している傾向が
見受けられる。

【０００５】本発明は、以上の点に鑑み、Ｗｅｂ上のネ
ットワークをモニタし、被災地の複数地点の情報を入手
することで、被災地の特定及び規模を推定することがで
きる災害推定システム及び方法を提供することを目的と
する。

【０００６】

【課題を解決するための手段】本発明の第１の解決手段
によると、複数のエリアに区分された対象地域について
の災害推定システムであって、各エリアには、他のエリ
アと伝送路で接続されたノードと、前記ノードに伝送路
を介して接続されたクライアント端末とを備え、前記ノ
ードは、対象地域に発生した災害地点及び／又は規模を
推定する第１アプリケーションと、クライアント端末と
のモニタ信号の送受信に基づくログを保存するためのデ
ータベースサーバと、クライアント端末にダウンロード
され、ノードとクライアント端末間でモニタ信号を送受
信し、異常を判定するためのノード側第２アプリケーシ
ョンと、前記クライアント端末に情報及び前記第２のア
プリケーションを提供するＷｅｂサーバと、ノードとク
ライアント端末間でモニタ信号を送受信し、その間の異
常を判定するクライアントモニタとを備え、前記クライ
アント端末は、前記Ｗｅｂサーバの情報を得るためのブ
ラウザと、前記Ｗｅｂサーバにアクセスした際にダウン
ロードすることで得られ、前記クライアントモニタとモ
ニタ信号を送受信するためのクライアント側第２アプリ
ケーションとを備え、前記ノードは、前記クライアント
端末と、定期的にモニタ信号を送受信してログを保存
し、また、モニタ信号を送受するいずれかの部分に異常
があると判断した場合、ログを保存して前記第１アプリ
ケーションを起動することにより災害規模を推定する災
害推定システムを提供する。

【０００７】本発明の第２の解決手段によると、ノード
と、前記ノードに伝送路を介して接続されたクライアン
ト端末を含むエリアに区分された対象地域についての災
害推定方法であって、ノードとクライアント端末は、ノ
ードとクライアント端末間で、データを送受し異常を判
定するための第２アプリケーションを起動し、モニタ信
号を送受し、モニタ信号の送受に基づいてログをサーバ
内に定期的に保存し、モニタ信号が一定時間を超えて途
絶えた場合、モニタ信号を送受するいずれかの部分に異
常があると判断し、ログをサーバ内に保存すると共に、
対象地域に発生した災害地点及び規模を推定する第１ア
プリケーションを起動することにより災害規模を推定す
る災害推定方法を提供する。

【０００８】

【発明の実施の形態】以下、図面を用いて本発明の実施
の形態を詳細に説明する。図１は、本発明に関する災害
推定システムを適用した地域のネットワークモデルを示
す説明図である。このネットワークモデルは、例えば、
通常使われているＷｅｂのネットワークをベースとす
る。ネットワークの張り巡らされた地域１００は、例え
ば、エリア１、エリア２、エリア３及びエリア４に区切
られている。エリア1には、ノード１と、ノード１に伝
送路を介して接続された、例えば、３つのクライアント
（以下、一般ＣＬ端末という）とが散在して配置されて
いる。同様に、エリア２は、ノード２と、ノード２に伝
送路を介して接続された、例えば、３つの一般ＣＬ端末
とが散在して配置されている。また、エリア３は、ノー
ド３と、ノード３に伝送路を介して接続された、例え
ば、３つの一般ＣＬ端末とが散在して配置されている。
なお、エリア４も同様である。

【０００９】また、ノードｉとノードｊ間は、ノード自
体が被災した場合に対応できるように、ルートｉｊで結
び、このネットワークにより、モニタデータ（後述）
は、すべてのノードで保有できる。各ノード１〜４は、
この例では、伝送路Ｌ１２、Ｌ２３、Ｌ３４、Ｌ１３、
Ｌ１４及びＬ２４でそれぞれ接続され、ネットワークを
構築している。なお、エリア、ノード、一般ＣＬ端末の
数及び配置は、適宜定めることができる。このネットワ
ークモデルを、県単位で支店と複数の営業所を持つ企業
としてとらえると、本システムでは、一例として、支店
をノードとし営業所の端末をクライアント（ＣＬ）と想
定される。そして、社内で必要なデータを支店（ノー
ド）単位で集め、営業所の端末（一般ＣＬ端末）とデー
タを共有する場合に対応している。

【００１０】図２は、本発明に関するノードと一般ＣＬ
端末の構成図である。但し、上述した各ノード１〜４、
各ノード１〜４と情報ネットワークで結ばれた一般ＣＬ
端末は、それぞれ同等なものであり、説明の便宜上、ノ
ード１０と他のノード２０に分けて説明する。

【００１１】本発明に関する災害推定システムを適用し
た地域を、災害規模推定対象とする。この災害規模推定
対象とは、例えば、ノード１０及びその他のノード２０
を含むエリアが、複数隣接している地域である（例え
ば、図１では４つのノードを含むエリア）。ノード１０
は、サーバ１１と、モニタ用のパソコン端末（モニタＣ
Ｌ）１２とを備える。サーバ１１には、Ｗｅｂサーバ、
データベースサーバ（ＤＢ）、アクティブコンポーネン
ト（ＡＣ）及びアプリケーション（ＡＰ）等がインスト
ールされている。モニタＣＬ１２には、スタティックコ
ンポーネント（ＳＣ）がインストールされている。ＳＣ
は、例えば、データインターフェース（ＤＢ−ＩＦ）、
ノードモニタ及びＣＬモニタを備える。ＡＣは主に、異
常を判定し、ＡＰは主に、災害規模推定を実行する。

【００１２】ＡＣは、一般ＣＬ端末３０がＷｅｂサーバ
にアクセスし、このＷｅｂサーバ内に保存されているデ
ータを利用しようとすると（一点鎖線による両側矢印：
データの利用）、一般ＣＬ端末３０に自動的にダウンロ
ードされるソフトウェアである。このため、一般ＣＬ端
末３０には、Ｗｅｂサーバの情報の取り出し等を行うた
めのブラウザと、ＡＣ（但し、初期状態では、インスト
ールされていない）とを備える。この複数エリア内のノ
ード１０に設置されているモニタＣＬ１２は、他のノー
ド２０内に設置されているモニタＣＬ２２と伝送路（実
線による両側矢印：ネットワークモニタ）を介し、情報
ネットワークを構築している。なお、図中に示した、一
点鎖線による両側矢印（データの利用）、実線による両
側矢印（ネットワークモニタ）及び実線による片側矢印
（ＤＢに保存）の流れについては、以下に図３乃至図５
を用いて詳しく説明する。

【００１３】図３は、本発明に関する災害推定方法にお
けるノードと一般ＣＬ端末間のシーケンス図である。ま
ず、災害推定システムの初期段階として、例えば、ある
ノード１０と一般ＣＬ端末３０との間で、ネットワーク
モニタを行う場合について説明する。一般ＣＬ端末３０
の使用者がブラウザを起動し（Ｓ２０１）、ノード１０
内のサーバ１１の情報を利用するために、Ｗｅｂサーバ
にアクセスする。この際、サーバ１１上のＡＣが一般Ｃ
Ｌ端末３０に自動的にダウンロードされ、ネットワーク
モニタ用に起動される（Ｓ２０５）。また、ノード１０
のモニタＣＬには、予めＳＣが実装され起動され、モニ
タが開始される（Ｓ２０７）。ＡＣは、モニタＣＬ１２
にインストールされているＳＣ内のＣＬモニタとの間
で、一般ＣＬ端末３０の使用者がサーバ１１の情報を利
用している間（図２：一点鎖線による両側矢印参照）、
バックグラウンドで自動的にＣＬモニタと定期的にモニ
タ信号を送受信する。そして、得られたモニタデータ
は、ＳＣにあるＤＢ−ＩＦ部がログとして定期的にサー
バ１１のＤＢに転送し、保存される（Ｓ２０９：図２：
実線による片側矢印参照）。

【００１４】次に、伝送路又は各装置等、モニタ信号を
送受するいずれかの部分に故障／災害が発生した場合
（Ｓ２１１）、モニタＣＬ１２のＣＬモニタは、モニタ
信号の不到着を認識し（Ｓ２１３）、一定時間（例え
ば、１５秒）待機後にモニタ信号が再度不到着ならば
（Ｓ２１５）、異常発生と判断する（Ｓ２１７）。な
お、故障／災害が発生した場合、一般ＣＬ端末３０の使
用者は、ブラウザを起動し、Ｗｅｂサーバにアクセスし
ている状態で、動作不具合が発生する（Ｓ２０３）。ま
た、異常が発生した場合のモニタデータも、ＳＣ内のＤ
Ｂ−ＩＦを介して、ログとして定期的又は異常発生時に
サーバ内のＤＢに転送され保存される（Ｓ２０９：図
２：実線による片側矢印参照）。さらに、ノード１０の
サーバ１１内のＡＰが起動され、災害地点及び規模の推
定が開始される（Ｓ２１９）。その際、ＡＰは、前述し
たログを収集すると共に、災害の推定又は判定を行う
（Ｓ２２１）。

【００１５】図４は、本発明に関する災害推定方法にお
ける複数ノード間のシーケンス図である。ここでは、あ
るノード１０及び他のノード２０間で、ネットワークモ
ニタを行う場合について説明する（図２：実線による両
側矢印参照）。なお、説明の便宜上、上述したように、
ノード１０と一般ＣＬ端末３０との間で、ネットワーク
モニタを行う場合についての説明と重複する部分は、省
略した。

【００１６】ノード１０及び２０がモニタを開始すると
（Ｓ２５５、Ｓ２５７）、ノード１０にあるモニタＣＬ
１２内のノードモニタは、他のノード２０にあるモニタ
ＣＬ２２内のノードモニタと、自動的、かつ定期的にモ
ニタ信号を送受信する。得られたモニタデータは、各ノ
ードのＤＢにログが保存される（Ｓ２５１、Ｓ２５９：
図２：実線による片側矢印参照）。伝送路などモニタ信
号を送受信するいずれかの部分に異常が発生した場合
（Ｓ２６１）、ノードモニタは、モニタ信号不到着を認
識し（Ｓ２６３、Ｓ２７３）、一定時間（例えば、１５
秒）待機後に再度不到着ならば（Ｓ２６５、Ｓ２７
５）、異常発生と判断する（Ｓ２６７、Ｓ２７７）。ま
た、上述したように得られるノード間のモニタデータ
は、ＳＣ内のＤＢ−ＩＦを介して、ログとして定期的に
サーバ１１，１２内のＤＢに転送され保存される（Ｓ２
５１、Ｓ２５９）。このように、モニタＣＬ１２にある
ノードモニタは、サーバ１１のＤＢに保存しているログ
を、定期的又は異常発生時に他のノード２０等にあるＤ
Ｂに転送し保存することにより（Ｓ２５１、Ｓ２５
９）、災害規模推定対象とされた地域内のどのノードに
含まれるＤＢにおいても、全ての地域内のログを保存す
ることができる。さらに、ノード１０及び２０のサーバ
１１及び２１内のＡＰが起動され、災害地点及び規模の
推定が開始される（Ｓ２６９、Ｓ２７９）。その際、Ａ
Ｐは、前述したログを収集すると共に、災害の推定又は
判定を行う（Ｓ２７１、Ｓ２８１）。

【００１７】図５は、本発明に関する災害推定方法のフ
ローチャートである。ここでは、上述した図３と同様
に、災害推定システムの初期段階として、例えば、１つ
のノード１０と１つの一般ＣＬ端末３０との間で、ネッ
トワークモニタを行う場合について説明する。なお、図
５は、図３のシーケンスをフローチャート化したもので
あり、冗長にならない程度に、重複する部分を省略して
説明する。

【００１８】まず、例えば、サーバ１１内の情報を利用
するために、使用者がサーバ１１にアクセスすること
で、モニタ開始となる（Ｓ３０１）。一般ＣＬ端末３０
にダウンロードされたＡＣは、災害規模推定対象である
地域をモニタするために常時待機しているモニタＣＬ１
２内のＳＣに対して、コネクション確立要求を行う（Ｓ
３０３）。一方、モニタＣＬ１２のＳＣはこのコネクシ
ョン確立要求に対して、コネクション受諾を行う（Ｓ３
１９）。コネクション確立要求及び受諾が成功であれば
（Ｓ３０５、３２１）、ＡＣとＳＣとの間でコネクショ
ンが確立されると共に、ＡＣとＳＣそれぞれでモニタル
ープが開始される（Ｓ３０７、３２７）。ここで、保守
者による作業、電源のＯＮ／ＯＦＦ又はシステムの機能
停止等により、モニタループ終了か否かを判断する（Ｓ
３０９、３２９）。

【００１９】ループが終了していない場合、ＡＣとＳＣ
間でデータの送受信を行う。まず、ＡＣからＳＣへのデ
ータの送受信を行うと共に（Ｓ３１１、３３１）、成功
すれば（Ｓ３１３、３３３）、ＳＣからＡＣへのデータ
の送受信を行う（Ｓ３３７、３１５）。次に、このデー
タの送受信が成功すれば（Ｓ３１７、３３９）、再びル
ープ終了かどうかを確認する。このようにＡＣとＳＣ間
でコネクションを確立させ、その後、ＡＣとＳＣは、一
定間隔で交互にメッセージデータを送信し合うことにな
る。なお、ここでは、受信時刻をログとして記録する。

【００２０】以下、一般ＣＬ端末３０のＡＣ及びノード
１０のＳＣを、それぞれ別々に説明する。ＡＣは、ルー
プが終了であれば（Ｓ３０９）、再びＡＣとＳＣとの間
のコネクションを確立するために、ＳＣに対してコネク
ション確立要求を行う（Ｓ３０３）。また、ＳＣは、ス
テップＳ３２１でＡＣとのコネクション確立が成功しな
いと判断されると、一定時間（例えば、１５秒）待機す
ると共に（Ｓ３２３）、さらに、成功かどうかを確認す
る（Ｓ３２５）。成功であればステップＳ３２７によ
り、上述したモニタループを開始し、成功しなければ、
この情報をログとして送信し（Ｓ３４３）、同時に災害
規模推定ＡＰを動作させる（Ｓ３４７）。また、ステッ
プＳ３３３でＡＣからＳＣへのデータの送受信が成功し
ないと判断されると、一定時間（例えば、１５秒）待機
すると共に（Ｓ３３５）、成功するかどうかを再び確認
する（Ｓ３４１）。成功すれば、上述したように、再び
ステップＳ３２９へ移行してループが終了したかを確認
する（Ｓ３２９）。一方、ステップＳ３４１で成功しな
いと判断されると、この情報をログとして送信し（Ｓ３
４３）、災害規模推定ＡＰを動作させる（Ｓ３４７）。
ステップＳ３４３で送信された受信時刻等を含むログ
は、ＤＢに転送され保存される（Ｓ３４５）。また、ス
テップＳ３４７で災害地点及び規模を推定するＡＰが起
動されると、ＡＰは、異常に関連するログをＤＢから取
得し、被災地の特定及び規模を推定すると共に、判定結
果を出力する（Ｓ３４９）。

【００２１】次に、上述したＡＰによって、災害地点及
び規模を推定する場合の具体例を説明する。自エリア内
のひとつの一般ＣＬ端末とノードとの間に異常が発生
し、かつ、他の全てのログが正常である場合では、この
一般ＣＬ端末、又は、この一般ＣＬ端末に接続されてい
る１本の伝送路の異常が原因であり、単なる故障の可能
性が大きい。このため、ＡＰは、この状況を災害とは推
定しない。

【００２２】自エリア内の複数の一般ＣＬ端末とノード
との間に異常が発生し、かつ、この一般ＣＬ端末は、全
て同一伝送路で接続されている場合では、この伝送路の
異常が原因である可能性が高い。このため、伝送路自体
の人為的な断線等による故障か、又は、伝送路が通って
いるルート上の災害の可能がある。このため、ＡＰは、
この状況を小規模の災害と推定する。

【００２３】自エリア内の複数の一般ＣＬ端末とノード
との間に異常が発生し、かつ、これらの一般ＣＬ端末
は、複数の伝送路で接続されている場合では、この複数
の伝送路の異常が原因である可能性が高い。この場合、
この複数の伝送路が通っているルートにもよるが、互い
に離れたルートを通っている複数の伝送路が異常であれ
ば、同時に人為的な故障とは考えにくい。このため、Ａ
Ｐは、この状況をルートを含む地域の災害が発生したと
推定する（具体例を図６に示す：後述）。

【００２４】自エリア内のノードと他のエリア内のノー
ドとのモニタに異常が発生し、かつ、更に別のエリア内
のノードと他のエリア内のノードとのログが正常である
場合では、他のエリア内のノード自体は動作しており、
自エリア内のノードと他のエリア内のノードとの間の伝
送路の故障の可能性が高い。このため、ＡＰは、この状
況を災害とは推定しない。

【００２５】自エリア内のノードと他のエリア内のノー
ドとのモニタに異常が発生し、かつ、更に別のエリア内
のノードと他のエリア内のノードとのログが異常である
場合では、他のエリア内のノード自体の故障か、又は、
自エリア内のノード、他のエリア内のノード及び更に別
のエリア内のノード間における各々の伝送路を含む地域
の災害である可能性が高い。このため、ＡＰは、この状
況をやや広域の災害が発生したと推定する。

【００２６】このように、ＡＰは、いずれかのノードで
異常が発生したと、例えば、モニタＣＬ１２内のＳＣに
よって判断された場合には、程度に応じて異常に関連す
るログをＤＢから取得し、被災地の特定及び規模を推定
する。

【００２７】図６は、モニタによる障害地点を特定する
具体例を示す説明図である。ここでは、エリア２で障害
があった場合について説明する。まず、各ノードのモニ
タＣＬでは、定期モニタによって得られたログに基づい
て、第１及び第２のテーブル６１及び６２を作成する
（例えば、正常なら○、異常なら×とする）。第１及び
第２のテーブル６１及び６２は、ノード１１の適宜の記
憶装置に記憶することができる。「ノード間」の第１の
テーブル６１では、ノード２とノード４との間にのみ異
常が検出されるので、伝送路Ｌ２４が異常の原因である
可能性が高い。更に、「ノード・ＣＬ間」の第２のテー
ブル６２では、ノード２と、ＣＬ１及びＣＬ２との間に
異常が見られる。このため、ＡＰは、これらのテーブル
の結果に基づいて、被害の規模（例えば、図中、エリア
２内で多数の点（メッシュ）を付与した領域）を推定す
ることになる。

【００２８】なお、本実施の形態では、１つのノードと
１つの一般ＣＬ端末間での災害推定システムについて主
に言及したが、複数のノード間でのモニタ情報の交換等
を行い、広域災害の推定を行うこともできる。ログに
は、受信時刻、送信時刻、一般ＣＬ端末識別データ、ノ
ード識別データ、温度、湿度等適宜の情報を含むことが
できる。

【００２９】また、モニタＣＬでモニタが途絶えた時等
のように異常と判断された場合、被災地での被災規模を
推定することにより、通信網を応急に復旧できる自動復
旧システム（高橋賢他「光ファイバ切り替えによる光
ＷＡＮ障害の自動復旧システム」電気関係学会での予稿
集：１９９９年１１月５日発刊等参照）により提供され
る通信路切り替えプログラムに情報を出力することで、
災害時に限らず、通信ネットワークの信頼性を向上させ
ることもできる。

【００３０】具体的には、本実施の形態による災害推定
方法において、例えば図５中のステップＳ３４７の後
に、この通信路切り替えプログラムの処理に移行するよ
うにし、通信路（伝送路）が切断された場合、伝送路の
異常を検出すると共に、上述の自動復旧プログラムが起
動される。

【００３１】なお、本発明の災害推定方法は、災害推定
プログラムを記録したコンピュータ読み取り可能な記録
媒体、災害推定プログラムを含むコンピュータのメモリ
に転送可能なプログラム製品及び災害推定プログラムを
含むコンピュータでストアされるプログラム製品のいず
れかにより提供することができる。

【００３２】

【発明の効果】本発明によれば、Ｗｅｂ上のネットワー
クをモニタし、被災地の複数地点の情報を入手すること
で、被災地の特定及び規模を推定することができる。ま
た、本発明で採用するモニタによる災害推定システム及
び方法では、通常モニタする両端に特別に構成されたモ
ニタ装置が必要となるが、本発明では、Ｗｅｂ利用時の
動作端末とサーバとの間でこれを実行するもので、特別
な装置が不要という顕著な効果がある。

【図面の簡単な説明】

【図１】本発明に関する災害推定システムを適用した地
域のネットワークモデルを示す説明図。

【図２】本発明に関するノードと一般ＣＬ端末の構成
図。

【図３】本発明に関する災害推定方法におけるノードと
一般ＣＬ端末間のシーケンス図。

【図４】本発明に関する災害推定方法における複数ノー
ド間のシーケンス図。

【図５】本発明に関する災害推定方法のフローチャー
ト。

【図６】モニタによる障害地点を特定する具体例を示す
説明図。

【符号の説明】

１０ノード２０他ノード１１，２１サーバ１２，２２モニタＣＬ３０一般ＣＬ端末

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｈ０４Ｌ 12/24 Ｈ０４Ｌ 11/08 12/26 Ｆターム(参考） 5C087 AA03 BB12 BB46 BB74 BB76 CC04 DD03 DD08 DD49 EE14 FF01 FF02 FF19 FF20 GG09 GG14 GG21 GG23 GG30 GG36 GG39 GG43 GG70 5K030 GA04 GA12 GA14 HA04 JA10 MA01 MB01 MB20 MC08 5K033 AA06 BA08 DA02 EA05 EA07

Claims

【特許請求の範囲】

【請求項１】複数のエリアに区分された対象地域につい
ての災害推定システムであって、各エリアには、他のエリアと伝送路で接続されたノード
と、前記ノードに伝送路を介して接続されたクライアン
ト端末とを備え、前記ノードは、対象地域に発生した災害地点及び／又は規模を推定する
第１アプリケーションと、クライアント端末とのモニタ信号の送受信に基づくログ
を保存するためのデータベースサーバと、クライアント端末にダウンロードされ、ノードとクライ
アント端末間でモニタ信号を送受信し、異常を判定する
ためのノード側第２アプリケーションと、前記クライアント端末に情報及び前記第２のアプリケー
ションを提供するＷｅｂサーバと、ノードとクライアント端末間でモニタ信号を送受信し、
その間の異常を判定するクライアントモニタとを備え、前記クライアント端末は、前記Ｗｅｂサーバの情報を得るためのブラウザと、前記Ｗｅｂサーバにアクセスした際にダウンロードする
ことで得られ、前記クライアントモニタとモニタ信号を
送受信するためのクライアント側第２アプリケーション
とを備え、前記ノードは、前記クライアント端末と、定期的にモニ
タ信号を送受信してログを保存し、また、モニタ信号を
送受するいずれかの部分に異常があると判断した場合、
ログを保存して前記第１アプリケーションを起動するこ
とにより災害規模を推定する災害推定システム。
【請求項２】前記ノードは、他のノードとモニタ信号を
送受するノードモニタをさらに備え、前記ノードと前記クライアント端末間のログを、他のノ
ードと送受し、前記データベースサーバに保存するよう
にした請求項１に記載の災害推定システム。
【請求項３】前記Ｗｅｂサーバと前記ブラウザがインタ
ーネット網で接続され、これにより、ノード側及びクラ
イアント側第２アプリケーションを用いてモニタ信号を
送受するようにした請求項１又は２に記載の災害推定シ
ステム。
【請求項４】前記ノードは、ノード間及び／又はノード
とクライアント端末間の正常・異常を定期的に記憶し
て、第１アプリケーションを用いて被害の規模を推定す
るためのテーブルをさらに備えた請求項１乃至３のいず
れかに記載の災害推定システム。
【請求項５】ノードと、前記ノードに伝送路を介して接
続されたクライアント端末を含むエリアに区分された対
象地域についての災害推定方法であって、ノードとクライアント端末は、ノードとクライアント端
末間で、データを送受し異常を判定するための第２アプ
リケーションを起動し、モニタ信号を送受し、モニタ信号の送受に基づいてログをサーバ内に定期的に
保存し、モニタ信号が一定時間を超えて途絶えた場合、モニタ信
号を送受するいずれかの部分に異常があると判断し、ロ
グをサーバ内に保存すると共に、対象地域に発生した災
害地点及び規模を推定する第１アプリケーションを起動
することにより災害規模を推定する災害推定方法。
【請求項６】前記第２アプリケーションは、クライアン
ト端末がノード内のサーバに対してアクセスした際、ク
ライアント端末にダウンロードされるようにした請求項
５に記載の災害推定方法。
【請求項７】前記ノードは、さらにノード間でモニタ信
号を送受し、他のノードのログを保存することを特徴と
する請求項５又は６に記載の災害推定方法。
【請求項８】前記第１アプリケーションは、同一エリア内の複数のクライアント端末とノード間に異
常が発生し、かつ、複数の前記クライアント端末が複数
の伝送路で接続されている場合、複数の伝送路が配され
たルートを含む地域の災害と推定し、自エリア内のノードと他のエリア内のノード間に異常が
発生し、かつ、さらに別のエリア内のノードと他のエリ
ア内のノード間との情報が異常である場合、広域の災害
と推定するようにした請求項５乃至７のいずれかに記載
の災害推定方法。
【請求項９】前記第１アプリケーションは、同一エリア内のひとつのクライアント端末とノード間に
異常が発生し、かつ、他の全ての情報が正常である場
合、災害と推定せず、自エリア内のノードと他のエリア内のノード間に異常が
発生し、かつ、さらに別のエリア内のノードと他のエリ
ア内のノード間との情報が正常である場合、災害と推定
しないようにした請求項５乃至８のいずれかに記載の災
害推定方法。
【請求項１０】前記第１アプリケーションが起動された
後、さらに、通信網を復旧するための自動復旧処理を含
むようにした請求項５乃至９のいずれかに記載の災害推
定方法。