JP4428230B2 - 機器状態変化報知方法、該方法を用いたローカル機器コントローラ及び該ローカル機器コントローラを用いた遠隔監視システム - Google Patents

Description

本発明は、ユーザーのＷｅｂブラウザ搭載型端末にローカル機器の各種検知状態、各種被制御状態をブラウジング表示する遠隔監視システムに用いられる機器状態変化報知方法、その方法を用いたローカル機器コントローラ及び該ローカル機器コントローラを用いた遠隔監視システムに関するものである。

従来、ローカル機器に相当する監視端末と、ローカル機器コントローラに相当する監視端末と、ローカル機器コントローラ機器に相当するサーバと、ユーザーのＷｅｂブラウザ搭載型端末に相当するパーソナルコンピュータ（以下パソコンという）とをネットワークで接続している遠隔監視システムとしては例えば、特許文献１に開示されているようなシステムがあった。

この特許文献１に開示されている遠隔監視システムの監視端末は、各種検知状態、各種被制御状態が変化する機器であり、ビニールハウス内の植物などの生育環境を監視したり制御したりするものである。

またサーバは監視端末から出力される報告情報を受信し、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）等でパソコンに提供するＷＷＷサーバとして機能する。この場合パソコンは、サーバから報告情報を配信してもらうクライアントマシンとなる。

このようなサーバ（ローカル機器コントローラ）からネットワークを介してクライアントマシンとなるパソコン（ユーザーのＷｅｂ）に対して監視端末（ローカル機器）の各種検知状態、各種被制御状態をブラウジング表示させるように構成された遠隔監視システムにおいては、監視端末（ローカル機器）の各種検知状態、各種被制御状態の状態変化検知に関する各監視端末の各種検知状態、各種被制御状態の状態変化報知に関する各種方法（ＨＴＴＰｄ，ＣＧＩによる旧来の報知情報更新手順，他）が用いられていた。
特開２００３−２９６８６５号公報（図１，段落番号００４４）

ところで、上述の特許文献１に開示のシステムでは、パソコン（ユーザーのＷｅｂブラウザ搭載型端末）のネットワークでの接続ポイントの位置がサーバ（ローカル機器コントローラ）に地理的に近い位置に配置されていればよいが、例えば情報管理をしているサーバの設置場所から地理的に極めて遠方の場所においてユーザーがパソコン（ユーザーのＷｅｂブラウザ搭載型端末）をネット接続して閲覧したい場合、通信経路が長くなるゆえに監視端末（ローカル機器）の現場の状況変遷に即時に追随した情報配信をサーバが行えるとは限らず、監視端末（ローカル機器）の現場で異常発報が起こった直後に状態復旧（状態復帰）したとしても、パソコンには定期的な情報取得タイミング（配信要求タイミング）での状態変化情報でしか情報伝達がされないため、今回の配信要求タイミングまでの間に状態復旧した事実が前記パソコンに伝わらなかった。

これを改善すべく、サーバ（ローカル機器コントローラ）に各監視端末（ローカル機器）毎の状態変化記憶メモリを設け、監視端末（ローカル機器）一台毎について、前回の配信要求から今回の配信要求までに起きた状態変化を状態変化記憶メモリに記録してその記録内容をパソコン（ユーザーのＷｅｂブラウザ搭載型端末）に配信する通信手法が考えられる。

しかしこの方法では、各監視端末（ローカル機器）の台数に応じてサーバ（ローカル機器コントローラ）に状態変換記憶メモリを準備する必要があるため記憶装置のコストも高くなる上に、サーバ（ローカル機器コントローラ）内の情報処理が煩雑になって好ましくない。

このような問題は、特許文献１に示されるような遠隔監視システムを遠隔制御型ビル管理システムや遠隔監視型ホームセキュリティシステムに適用した場合にも当然にして起こりうる問題である。

本発明は、上述のような問題点に鑑みて為されたものであって、その目的とするところは、ローカル機器コントローラに大容量の記憶装置を要せずとも、簡単な動作で監視端末の状態変化が監視できる機器状態変化報知方法、該方法を用いたローカル機器コントローラ及び該ローカル機器コントローラを用いた遠隔監視システムを提供することにある。

上述の目的を達成するために、請求項１の機器状態変化報知方法の発明では、各種検知状態、各種被制御状態が変化するローカル機器と、該ローカル機器と通信して該ローカル機器の各種検知状態、各種被制御状態を収集するローカル機器コントローラとを備えて構成され、前記ローカル機器コントローラをサーバとし所定通信線を介してクライアントマシンとなるユーザーのＷｅｂブラウザ搭載型端末に前記ローカル機器の各種検知状態、各種被制御状態を前記ローカル機器コントローラがブラウジング表示する遠隔監視システムに用いられる機器状態変化報知方法において、前記ローカル機器コントローラは、前記ローカル機器の各種検知状態、各種被制御状態を収集して、前記ローカル機器の各種検知状態や各種被制御状態が一の状態から二の状態へ変化している現状状態の発生回数をカウントしてカウント値を記録する現状態カウンタと、前記ローカル機器の各種検知状態や各種被制御状態が一の状態から二の状態へ変化した回数及び二の状態から一の状態へ復帰した回数の総数をカウントしてカウント値を記録する状態変化カウンタとが設けられ、前記Ｗｅｂブラウザ搭載型端末から周期的に繰り返される配信要求毎に前記現状態カウンタ及び状態変化カウンタの記録された各カウント値に応じて、前記Ｗｅｂブラウザ搭載型端末における機器状態変化の報知の要否を決定することを特徴とする。

請求項１の機器状態変化報知方法の発明によれば、Ｗｅｂブラウザ搭載型端末からの前回の配信要求時と今回の配信要求時との間で起きたローカル機器の各種検知状態や各種被制御状態の変化の監視を、ローカル機器コントローラに大容量の記憶装置を要せずとも、簡単な動作ででき、所定接続線にＷｅｂブラウザ搭載型端末を接続したポイントとローカル機器コントローラの接続ポイントの間の距離や、使用するネットワークの速度、更にＷｅｂブラウザ搭載型端末の処理速度に関係なく、状態変化を失報すること無く、ユーザーへＷｅｂブラウザ搭載型端末を介して伝えることが可能となる。

請求項２の機器状態変化報知方法の発明では、請求項１の発明において、前記現状態カウンタの今回の配信要求時のカウント値が前回の配信要求時のカウント値よりも増加し、且つ前記状態変化カウンタの今回の配信要求時のカウント値が前回の配信要求時のカウント値よりも増加した場合、前記ローカル機器の各種検知状態、各種被制御状態が一の状態から二の状態に変化したものとみなし、機器状態変化の報知を決定することを特徴とする。

請求項２の機器状態変化報知方法の発明によれば、前回の配信要求時から今回の配信要求時までに起き且つ継続している状態変化を報知させることができる。

請求項３の機器状態変化報知方法の発明では、請求項１又は２の発明において、前記現状態カウンタの今回の配信要求時のカウント値が前回の配信要求時のカウント値と同値で、且つ前記状態変化カウンタの今回の配信要求時のカウント値が前回の配信要求時のカウント値よりも増加した場合、前記ローカル機器の各種検知状態、各種被制御状態が一の状態から二の状態に変化したものとみなし、機器状態変化の報知を決定することを特徴とする。

請求項３の機器状態変化報知方法の発明によれば、前回の配信要求時から今回の配信要求時までに起き且つ既に復帰した状態変化を報知させることができる。

請求項４の機器状態変化検知方法の発明では、請求項１乃至３の何れの発明において、前記現状態カウンタの今回の配信要求時のカウント値から前回の配信要求時のカウント値を減じた差分値である現状態カウンタ差分値と、前記状態変化カウンタの今回の配信要求時のカウント値から前回の配信要求時のカウント値を減じた差分値である状態変化カウンタ差分値とを求めておき、前記現状態カウンタの今回の配信要求時のカウント値が前回の配信要求時のカウント値よりも減少し、且つ前記状態変化カウンタ差分値から前記現状態カウンタ差分値の絶対値を減じた値が２以上の値である場合、前記ローカル機器の各種検知状態、各種被制御状態が一の状態から二の状態に変化したものとみなし、機器状態変化の報知を決定することを特徴とする。

請求項４の機器状態変化報知方法の発明によれば、前回の配信要求時から今回の配信要求時までに起き且つ既に復帰した新たな状態変化が起きたことを捉えて報知させることができる。

請求項５の機器状態変化検知方法の発明では、請求項１乃至４の何れの発明において、今回の配信要求時の前記現状態カウンタのカウント値から前回の配信要求時のカウント値を減じた差分値である現状態カウンタ差分値と、今回の配信要求時の前記状態変化カウンタのカウント値から前回の配信要求時のカウント値を減じた差分値である状態変化カウンタ差分値とを求めておき、前記現状態カウンタの今回の配信要求時のカウント値が前回の配信要求時のカウント値よりも減少し、且つ前記状態変化カウンタ差分値から前記現状態カウンタ差分値の絶対値を減じた値が２未満の値である場合、新たな報知の必要は無いと決定することを特徴とする。

請求項５の機器状態変化報知方法の発明によれば、前回の配信要求時に既に起きた状態変化が今回の配信要求時までに復帰したことを捉えて不必要な新たな報知を行わせることが無く、また今回の配信要求以前から継続されている報知があればそれを維持させることができる。

請求項６の機器状態変換検知方法の発明では、請求項１乃至５の何れの発明において、今回の配信要求時の前記現状態カウンタのカウント値が前回の配信要求時のカウント値よりも増加し、且つ今回の配信要求時の前記状態変化カウンタのカウント値が前回の配信要求時のカウント値よりも減少又は同値である場合、新たな報知を行う必要は無いと決定することを特徴とする。

請求項６の機器状態変化検知方法の発明によれば、前回の配信要求時から今回の配信要求時までに現状態カウンタのカウント値が増加しても、状態変化カウンタのカウント値の増加が見られないことによってエラー等のトラブルを識別することができ、エラー等による誤った報知を排除することができ、また今回の配信要求以前から継続されている報知があればそれを維持させることができる。

請求項７の機器状態変化検知方法の発明では、請求項１乃至６の何れの発明において、前記現状態カウンタの今回の配信要求時のカウント値が前回の配信要求時のカウント値と比べて変わらず、且つ前記状態変化カウンタの今回の配信要求時のカウント値が前回の配信要求時のカウント値よりも減少又は同値である場合、新たな報知を行う必要は無いと決定することを特徴とする。

請求項７の機器状態変化検知方法の発明によれば、前回の配信要求時から今回の配信要求時までにおいて状態変化が無かったことや、或いはエラー発生を識別することができ、結果エラー等による誤った報知を排除することができ、また今回の配信要求以前から継続されている報知があればそれを維持させることができる。

請求項８の機器状態変化検知方法の発明では、請求項２乃至４の何れの発明において、機器状態変化の報知を行う場合、前記Ｗｅｂブラウザ搭載型端末に鳴動させる報知音の仕様を、報知内容の重要度によって鳴動時間及び／又は音色を変化させることで、変更することを特徴とする。

請求項８の機器状態変化検知方法の発明によれば、ユーザーがＷｅｂブラウザ搭載型端末において発鳴される報知音により報知の重要度を識別することができる。

請求項９の機器状態変化検知方法の発明では、請求項１乃至８の何れの発明において、前記Ｗｅｂブラウザ搭載型端末に、報知対象のローカル機器に対応させたアイコンを表示させておき、前後の配置要求のタイミングで区切られる期間毎の現状態カウンタと状態変化カウンタの各記録カウント値の変化に応じてアイコンの表示態様を変更することによって、当該ローカル機器の各種被制御状態を表現することを特徴とする。

請求項９の機器状態変化検知方法の発明によれば、アイコン表示によりローカル機器の状態をユーザーが視認によって知ることができ、特に報知音と併用することでき、ローカル機器の状態を確実に知ることができる。

請求項１０の機器状態変化検知方法の発明では、請求項１乃至９の何れの発明において、機器状態変化報知内容を前記Ｗｅｂブラウザ搭載型端末にブラウジング表示させる以前に、各種被制御状態が変化前の状態に復帰していたとしても、その復帰した旨を、前記Ｗｅｂブラウザ搭載型端末にメッセージ表示させることを特徴とする。

請求項１０の機器状態変化検知方法の発明によれば、ユーザーに機器状態変化があったことを確実に知らせることができる。

請求項１１のローカル機器コントローラの発明では、請求項１乃至１０の何れに記載の機器状態変化報知方法を用いて、ユーザーのＷｅｂブラウザ搭載型端末との間の通信を行うことを特徴とする。

請求項１１のローカル機器コントローラの発明によれば、Ｗｅｂブラウザ搭載型端末からの前回の配信要求時と今回の配信要求時との間で起きたローカル機器の各種検知状態や各種被制御状態の変化の監視を、ローカル機器コントローラに大容量の記憶装置を要せずとも、簡単な動作ででき、所定接続線にＷｅｂブラウザ搭載型端末を接続したポイントとローカル機器コントローラの接続ポイントの間の距離や、使用するネットワークの速度、更にＷｅｂブラウザ搭載型端末の処理速度に関係なく、状態変化を失報すること無く、ユーザーへＷｅｂブラウザ搭載型端末を介して伝えることが可能なローカル機器コントローラを提供できる。

請求項１２の遠隔監視システムでは、各種検知状態、各種被制御状態が変化するローカル機器と、ローカル機器と通信してローカル機器の各種検知状態、各種被制御状態を収集する請求項１１のローカル機器コントローラとを備えて構成されることを特徴とする。

請求項１２の遠隔監視システムの発明によれば、Ｗｅｂブラウザ搭載型端末からの前回の配信要求時と今回の配信要求時との間で起きたローカル機器の各種検知状態や各種被制御状態の変化の監視を、ローカル機器コントローラに大容量の記憶装置を要せずとも、簡単な動作ででき、所定接続線にＷｅｂブラウザ搭載型端末を接続したポイントとローカル機器コントローラの接続ポイントの間の距離や、使用するネットワークの速度、更にＷｅｂブラウザ搭載型端末の処理速度に関係なく、状態変化を失報すること無く、ユーザーへＷｅｂブラウザ搭載型端末を介して伝えることが可能な遠隔監視システムを提供できる。

本発明は、Ｗｅｂブラウザ搭載型端末からの前回の配信要求時と今回の配信要求時との間で起きたローカル機器の各種検知状態や各種被制御状態の変化の監視を、ローカル機器コントローラに大容量の記憶装置を要せずとも、簡単な動作ででき、所定接続線にＷｅｂブラウザ搭載型端末を接続したポイントとローカル機器コントローラの接続ポイントの間の距離や、使用するネットワークの速度、更にＷｅｂブラウザ搭載型端末の処理速度に関係なく、状態変化を失報すること無く、ユーザーへＷｅｂブラウザ搭載型端末を介して伝えることが可能な機器状態変化報知方法、該方法を用いたローカル機器コントローラ及び該ローカル機器コントローラを用いた遠隔監視システムを提供できるという効果がある。

以下本発明を一実施形態により説明する。

図２は本発明の遠隔監視システムの概略構成を示しており、本遠隔監視システムは、例えば監視・制御対象のローカル機器１と、ローカル機器コントローラ２と、ユーザーのＷｅｂブラウザ搭載型端末（以下端末と略す）３とを備えて構成される。

ローカル機器１は、例として、動力機器、電力機器、空調機器などの設備機器４ａの入出力制御を行う入出力端末器１ａ、照明器具４ｂへ調光電力を供給する出力端末器１ｂ、特定の負荷の消費電力を計量する計量機器４ｃを監視する計量端末器１ｃ、別設の防犯・防災システム４ｄからの情報を吸い上げる防災・防犯端末器１ｄ、出力端末器１ｂに接続される照明器具の点灯／消灯を操作する壁スイッチ１ｅ、出力端末器１ｂに接続される照明器具以外の多数の照明器具を多点管理し点灯／消灯のパターンを設定する設定入力器であるアナンシェータ１ｆ、更に増設用の警報ユニット１ｇ等が挙げられる。これら各種ローカル機器１（１ａ〜１ｇ）は、遠隔制御型ビル管理システムや遠隔監視型ホームセキュリティシステムの用途のものであり、要するに、各種検知状態、各種被制御状態が変化する機器である。

ローカル機器コントローラ２は、図１に示すように中央演算装置２０ａ及び記憶装置２０ｂからなるコンピュータシステムにより構成され、中央演算装置２０ａでは変化状態の監視制御対象となる上述のローカル機器１（１ａ〜１ｇ）と例えばポーリング／セレクティング方式で伝送信号送受信部２１により伝送線５を介して通信してローカル機器１（１ａ〜１ｇ）の各種検知状態、各種被制御状態を収集するとともにローカル機器１（１ａ〜１ｇ）の制御を行う監視制御部２２と、後述するＷｅｂサーバ部２３と、ＣＧＩサーバ部２４とが、対応ソフトウェアを実行することで構築されるようになっている。

ＣＧＩサーバ部２４は監視制御部２２を通じて取得した状態の監視情報によりローカル機器１（１ａ〜１ｇ）の状態変化を判定するために現状態カウンタ２４ａと状態変化カウンタ２４ｂという２つのカウンタと後述する判定処理をアプレットにより実現しており、これによりローカル機器１（１ａ〜１ｇ）の各種検知状態、各種被制御状態について判定した結果を、ユーザーの端末３に対してイーサネット（登録商標）＜Ｅｔｈｅｒｎｅｔ（登録商標）＞（Ｘｅｒｏｘ社登録商標）に対応する通信部２５と所定の通信線６とを介してＷｅｂサーバ部２３から配信する。

ユーザーの端末３は、ローカル機器コントローラ２にとってはクライアントマシンであり、ローカル機器コントローラ２との間をイントラネットやインターネットなどのネットワークで接続可能な通信部を備え、世界中のどこからでもローカル機器コントローラ２に対して例えばＪａｖａ（登録商標）（Sun Microsystems社登録商標）バーチャルマシンによってＷｅｂブラウザを起動してローカル機器コントローラ２に所定周期で配信要求をローカル機器コントローラ２に対して行うことができるようなっている。勿論移動体通信網を利用する移動体通信用の端末３’を用いてもよい。

これに応じるべく、ローカル機器コントローラ２では、ＨＴＴＰｄ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ｄａｅｍｏｎ）、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）などの対応ソフトウェアを実装して上述のＷｅｂサーバ部２３やＣＧＩサーバ部２４を構築しており、Ｗｅｂサーバ部２３はＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で配信要求のあった端末３へ返信を送ることができるものである。従ってローカル機器コントローラ２のＷｅｂサーバ部２３から返信を受け取った端末３は、自器の画面に、ローカル機器１（１ａ〜１ｇ）の各種検知状態、各種被制御状態をブラウジング表示することになる。

次に本発明の主要構成であるＣＧＩサーバ部２４の現状態カウンタ２４ａと状態変化カウンタ２４ｂの働きについて詳説する。

ここで取り上げる現状態カウンタ２４ａと状態変化カウンタ２４ｂは、ローカル機器１において通常状態（一の状態）から非通常（二の状態）状態へ状態が変化した場合に、この発生をユーザーに警報報知するかの判定を行うために用いるカウンタであって、予めグループ分けされたローカル機器群毎に設けられており、現状態カウンタ２４ａは対応するローカル機器群内の何れのローカル機器１が通常状態から非通常状態（以下警報発生という）になったことを示す情報を監視制御部２２から受け取るとそのカウント値Ｃｎｔ１をインクリメントし、またローカル機器群内の何れのローカル機器１から、警報発生状態から通常状態に復旧（復帰）したことを示す情報を監視制御部２２から受け取るとカウント値Ｃｎｔ１をデクリメントすることで、対応するローカル機器群において現在警報発生状態の機器の数をカウント値Ｃｎｔ１として示すようになっている。

つまり現状態カウンタ２４ａは対応する種別のローカル機器群の何れで警報発生状態が復旧すればカウント値Ｃｎｔ１がデクリメントされるので、値ゼロを下限値として増減を繰り返すのである。

一方状態変化カウンタ２４ｂは同じローカル機器群内の何れかのローカル機器１で状態が一の状態から二の状態或いは二の状態へ変化する度にカウント値Ｃｎｔ２がインクリメントされるので、例えば警報発生状態（二の状態）が復旧（一の状態へ復帰）してもカウント値が減少せず、増加するのである。

ここで、図３は各ローカル機器群における警報発生と復旧状態の変遷と、夫々のローカル機器群に対応する両カウンタ２４ａ，２４ｂのカウント値Ｃｎｔ１，Ｃｎｔ２の変化を示しており、例えば図３（ａ）に示すローカル機器群では、タイミングｔ１−１で或るローカル機器１−１が警報発生状態となり、そのため対応する現状態カウンタ２４ａのカウント値Ｃｎｔ１は図３（ｄ）に示すように”０”から”１”にインクリメントされる。同時に対応する状態変化カウンタ２４ｂのカウント値Ｃｎｔ２も図３（ｄ）に示すように”０”から”１”にインクリメントされる。

更にタイミングｔ１−２で別のローカル機器１−２が警報発生状態となると、現状態カウンタ２４ａのカウント値Ｃｎｔ１は図３（ｄ）に示すように”２”にインクリメントされ、状態変化カウンタ２４ｂのカウント値Ｃｎｔ２も図３（ｄ）に示すように”２”にインクリメントされる。

そしてタイミングｔ１−３でローカル機器１−２が復旧すると、現状態カウンタ２４ａのカウント値Ｃｎｔ１は図３（ｄ）に示すように”１”にデクリメントされる一方、状態変化カウンタ２４ｂのカウント値Ｃｎｔ２は”３”にインクリメントされる。

更にタイミングｔ１−４でローカル機器１−１が復旧すると、現状態カウンタ２４ａのカウント値Ｃｎｔ１は図３（ｄ）に示すように”０”にデクリメントされるが、状態変化カウンタ２４ｂのカウント値Ｃｎｔ２は図３（ｄ）に示すように”４”にインクリメントされる。

図３（ｂ）は別のローカル機器群におけるローカル機器状態の変遷を示しており、この場合タイミングｔ２−１でローカル機器１−３が、タイミングｔ２−２でローカル機器１−４が、タイミングｔ２−３でローカル機器１−５が夫々警報発生状態となり、タイミングｔ２−４でローカル機器１−４が、タイミングｔ２−５でローカル機器１−３が、更にタイミングｔ２−６でローカル機器１−５が夫々復旧している。

これらの変遷に伴い、対応する両カウンタ２４ａ，２４ｂのカウント値Ｃｎｔ１，Ｃｎｔ２は図３（ｅ）に示すように変遷する。つまりタイミングｔ２−１では両カウンタ２４ａ，２４ｂのカウント値Ｃｎｔ１，Ｃｎｔ２は図示するように”０”から夫々”１”にインクリメントされる。タイミングｔ２−２では両カウンタ２４ａ，２４ｂのカウント値Ｃｎｔ１，Ｃｎｔ２は図示するように”２”に夫々インクリメントされる。更にタイミングｔ２−３では両カウンタ２４ａ，２４ｂのカウント値Ｃｎｔ１，Ｃｎｔ２は図示するように”３”に夫々インクリメントされる。そしてタイミングｔ２−４ではローカル機器１−４が復旧するため、現状態カウンタ２４ａのカウント値Ｃｎｔ１は”２”にデクリメントされるが、状態変化カウンタ２４ｂのカウント値Ｃｎｔ２は”４”にインクリメントされる。またタイミングｔ２−５ではローカル機器１−３が復旧するため、現状態カウンタ２４ａのカウント値Ｃｎｔ１は”１”にデクリメントされるが、状態変化カウンタ２４ｂのカウント値Ｃｎｔ２は”５”にインクリメントされる。更にタイミングｔ２−６ではローカル機器１−５が復旧するため、現状態カウンタ２４ａのカウント値Ｃｎｔ１は”０”にデクリメントされるが、状態変化カウンタ２４ｂのカウント値Ｃｎｔ２は”６”にインクリメントされる。

図３（ｃ）は他のローカル機器群におけるローカル機器状態の変遷を示しており、この場合タイミングｔ３−１でローカル機器１−６が、タイミングｔ３−２でローカル機器１−７が夫々警報発生状態となり、タイミングｔ３−３でローカル機器１−７が、タイミングｔ３−４でローカル機器１−６が、更にタイミングｔ３−５でローカル機器１−６が再び警報発生状態となり、タイミングｔ３−６で復旧している。

これらの変遷に伴い、対応する両カウンタ２４ａ，２４ｂのカウント値Ｃｎｔ１，Ｃｎｔ２は図３（ｆ）に示すように変化する。つまりタイミングｔ３−１では両カウンタ２４ａ，２４ｂのカウント値Ｃｎｔ１，Ｃｎｔ２は図示するように”０”から”１”に夫々インクリメントされ、更にタイミングｔ３−２では両カウンタ２４ａ，２４ｂのカウント値Ｃｎｔ１，Ｃｎｔ２は図示するように”２”に夫々インクリメントされる。更にタイミングｔ３−３ではローカル機器１−７が復旧するため現状態カウンタ２４ａのカウント値Ｃｎｔ１は図示するように”１”にデクリメントされるが、状態変化カウンタ２４ｂのカウント値Ｃｎｔ２は”３”にインクリメントされる。そしてタイミングｔ３−４ではローカル機器１−６が復旧するため、現状態カウンタ２４ａのカウント値Ｃｎｔ１は”０”にデクリメントされるが、状態変化カウンタ２４ｂのカウント値Ｃｎｔ２は”４”にインクリメントされる。更にまたタイミングｔ３−５ではローカル機器１−６が再び警報発生状態となるため、現状態カウンタ２４ａのカウント値Ｃｎｔ１は”１”にインクリメントされ、また状態変化カウンタ２４ｂのカウント値Ｃｎｔ２は”５”にインクリメントされる。更にタイミングｔ３−６ではローカル機器１−６が復旧するため、現状態カウンタ２４ａのカウント値Ｃｎｔ１は”０”にデクリメントされるが、状態変化カウンタ２４ｂのカウント値Ｃｎｔ２は”６”にインクリメントされる。

以上のように夫々のローカル機器群毎に設けられた両カウンタ２４ａ，Ｃｎｔ２は対応するローカル機器１の状態変化に応じて夫々のカウント値Ｃｎｔ１，Ｃｎｔ２を変化させるようになっている。

ここで図３に示しているタイミングＴ（ｎ）、Ｔ（ｎ＋１）、Ｔ（ｎ＋２）は端末３からローカル機器コントローラ２のＷｅｂサーバ部２３に対して定周期（例えば１０秒周期）で出される配信要求のタイミングを示しており、今回の配信要求時におけるＣＧＩサーバ部２４内の両カウンタ２４ａ，２４ｂのカウント値Ｃｎｔ１，Ｃｎｔ２と、カウンタ２４ａ，２４ｂで夫々一時記録している前回の配信要求時でのカウント値Ｃｎｔ１，Ｃｎｔ２に応じて端末３に内蔵しているスピーカやブザーを鳴動させて警報の報知音を発鳴させるか、させないかの判定（決定）をＣＧＩサーバ部２４は図４のフローチャートに基づいて行うのである。

尚配信要求のタイミングは基本的には一定周期であるが、通信路の混雑、更にローカル機器コントローラ２での処理の遅延、更に端末３での処理遅れ等により配信要求が出されるタイミングが多少ばらつくこともある。

さて図４において、ステップＳ１では現状態カウンタ２４ａの現在のカウント値Ｃｎｔ１と前回配信要求時のカウント値Ｃｎｔ１との差分値ΔＣｎｔ１が（正）か、（負）又は（０）かを判定する。ここで（正）の場合には次のステップＳ２において、状態変化カウンタ２４ｂの現在のカウント値Ｃｎｔ２と前回配信要求時のカウント値Ｃｎｔ２の差分値ΔＣｎｔ２が（正）か、（負）か或いは（０）かを判定し、（正）の場合には今回の配信要求のタイミングでの現状態カウンタ２４ａのカウント値Ｃｎｔ１が前回の配信要求のタイミングでのカウント値Ｃｎ１より増加し且つこれに対応して状態変化カウンタ２４ｂのカウント値Ｃｎｔ２も前回の配信要求のタイミングよりも今回増加したことにより、何れかのローカル機器１で新たな警報発生になったと判定でき、その結果端末３で警報の報知（以下警報鳴動という）を行うと決定する（ステップＳ３）。

図５は上述の両カウンタ２４ａ，２４ｂのカウント値Ｃｎｔ１，Ｃｎｔ２が共に増加する事例を示し、同図（ａ）は同じローカル機器群内の或るローカル機器１が前回の配信要求のタイミングＴａから今回の配信要求のタイミングＴｂまでの期間において、警報発生状態なり、今回の配信要求のタイミングＴｂ以後に警報発生状態にある何れのローカル機器１が復旧がした場合を示し、この場合前回の配信要求のタイミングＴａのときにカウント値Ｃｎｔ２が”ｎ”であったのが、今回の配信要求のタイミングＴｂには”ｎ＋１”とインクリメントされている。勿論現状態カウンタ２４ａもカウント値がインクリメントされる。

同図（ｂ）は同じローカル機器群内の何れのローカル機器１で前回の配信要求のタイミングＴａから今回の配信要求のタイミングＴｂまでの期間において、ｍ回警報発生と復旧が繰り返された後、今回の配信要求のタイミングＴｂまでに警報発生があって今回の配信要求のタイミングＴｂに至るまでに何れのローカル機器１での復旧が無く、今回の配信要求のタイミングＴｂ以後に復旧があった場合を示し、この場合前回の配信要求のタイミングＴａのときにカウント値Ｃｎｔ２が”ｎ”であったのが、今回の配信要求のタイミングＴｂには”ｎ＋２ｍ＋１”となっている。この場合前回の配信要求のタイミングでの現状態カウンタ２４ａのカウント値Ｃｎｔ１は、今回の配信要求のタイミングＴｂに最も近いタイミングでの警報発生に対応してインクリメントされて増加している。

さて図４のステップＳ２においては、ステップＳ１で差分値ΔＣｎｔ１が（正）の場合、当然差分値ΔＣｎｔ２も（正）とならなければならないが、エラーなどの原因でカウント値Ｃｎｔ２が減少している場合（負）や変化無し（０）の場合も有り得る。そこでステップＳ２で（負）若しくは（０）と判定された場合には変化無しと判定し、新たな警報鳴動を行う必要無しと決定する（ステップＳ４）。

一方上述のステップＳ１で（０）と判定された場合にはステップＳ５において、状態変化カウンタ２４ｂの現在のカウント値Ｃｎｔ２と前回の配信要求時のカウント値Ｃｎｔ２との差分値ΔＣｎｔ２が（正）か否（０又は負）かを判定する。ここで、（正）と判定された場合、つまりカウント値Ｃｎｔ２が増加している場合には、前回の配信要求のタイミングから今回の配信要求のタイミングまでの期間で警報発生状態と復旧が行われたと考えられる。つまり新たに警報が発生したと考えられるので、ステップＳ３により警報鳴動を行うと決定する。

図６は現状態カウンタ２４ａのカウント値Ｃｎｔ１に変化が無く、状態変化カウンタ２４ｂのカウント値Ｃｎｔ２が増加した場合の事例を示しており、同図（ａ）は同じローカル機器群内の何れのローカル機器１が前回の配信要求のタイミングＴａ以前に警報発生状態となり、今回の配信要求のタイミングＴｂまでの期間において復旧し、この復旧後、今回の配信要求のタイミングＴｂまでに何れのローカル機器１が警報発生状態となった場合を示しており、この場合前回の配信要求のタイミングＴａのときにカウント値Ｃｎｔ２が”ｎ”であったのが、今回の配信要求のタイミングＴｂには”ｎ＋２”となっている。この場合現状態カウンタ２４ａのカウント値Ｃｎｔ１はタイミングＴｂなるまでの警報発生に応じてインクリメントされるため、前回と今回の配信要求のタイミングＴａとでのカウント値Ｃｎｔ１は変わらない。

同図（ｂ）は同じローカル機器群内の何れのローカル機器１が前回の配信要求のタイミングＴａ以前に警報発生状態となり、今回の配信要求のタイミングＴｂまでの期間において復旧し、この復旧後、今回の配信要求のタイミングＴｂまでに警報発生と復旧とがｍ回繰り返された後、何れのローカル機器１で警報発生があって今回の配信要求のタイミングＴｂまで復旧が無かった場合を示しており、この場合前回の配信要求のタイミングＴａのときにカウント値Ｃｎｔ２が”ｎ”であったのが、今回の配信要求のタイミングＴｂには”ｎ＋２ｍ＋２”と増加している。この場合現状態カウンタ２４ａのカウント値Ｃｎｔ１はタイミングＴｂに最も近い警報発生に応じてインクリメントされるため、前回の配信のタイミングＴａと今回の配信要求のタイミングＴｂでのカウント値Ｃｎｔ１は変わらない。

更に同図（ｃ）は前回の配信要求のタイミングＴａから今回の配信要求のタイミングＴｂまでの期間において、警報発生と復旧とがｍ回繰り返され、最後の復旧から今回の配信要求のタイミングＴｂまで状態変化が無い場合を示しており、この場合前回の配信要求のタイミングＴａのときにカウント値Ｃｎｔ２が”ｎ”であったのが、今回の配信要求のタイミングＴｂには”ｎ＋２ｍ”となっている。一方現状態カウンタ２４ａのカウント値Ｃｎｔ１は前回の配信要求のタイミングＴｂと今回の配信要求タイミングＴａとでは変化が無い。

そしてステップＳ５での判定で差分値ΔＣｎｔ２が（０）の場合には前回の配信要求時から現在まで何の状態変化も無かったと判定し、新たな警報鳴動の必要無しと決定する（ステップＳ４）。

図７は両カウンタ２４ａ，２４ｂのカウント値Ｃｎｔ１，Ｃｎｔ２が共に変化無しの場合の事例を示しており、同図（ａ）は前回の配信要求のタイミングＴａから今回の配信要求のタイミングＴｂまでの期間において、警報発生も復旧も無かった場合を、同図（ｂ）は前回の配信要求のタイミングＴａの手前で警報発生があり、今回の配信要求のタイミングＴｂ以後において復旧があった場合を夫々示しており、何れの場合にも両カウンタ２４ａ、２４ｂのカウント値Ｃｎｔ１，Ｃｎｔ２は前回の配信要求のタイミングＴａと、今回の配信要求のタイミングＴｂとで変化が無い。

尚ステップＳ５で差分値ΔＣｎｔ２が（負）と判定された場合は、エラーと考えられるため、（０）の場合と同様に変化無しと判定される。

次の上述のステップＳ１でΔＣｎｔ１が（負）と判定された場合、つまり現状態カウンタ２４ａのカウント値Ｃｎｔ１が前回の配信要求時のカウント値Ｃｎｔ１よりも減少した場合には、ステップＳ６において、状態変化カウンタ２４ｂに対応する差分値ΔＣｎｔ２から現状態カウンタ２４ａに対応する差分値ΔＣｎｔ２の絶対値を差し引いた値が２未満か２以上かを判定する。ここで前回の配信要求時には警報発生状態であったローカル機器１が今回の配信要求時までに復旧のみがあった場合には、差分値ΔＣｎｔ１は（負）となる一方、差分値ΔＣｎｔ２はこの復旧に数だけ増加することになり、そのため差分値ΔＣｎｔ２から差分値ΔＣｎｔ１の絶対値を差し引いた値は２未満となる。そして復旧のみの場合には新たな警報発生が無かった考えられるので、２未満の場合には変化無しと判定し、新たな警報鳴動の必要無しと決定する（ステップＳ４）。

一方前回の配信要求時から今回の配信要求時までの期間でローカル機器１において、復旧や警報発生が複数回繰り返されて、現状態カウンタ２４ａに対応する差分値ΔＣｎｔ１が減少した場合には、状態変化カウンタ２４ｂのカウント値Ｃｎｔ２は前回の配信要求時のカウント値よりも少なくとも２以上増加することになり、そのため差分値ΔＣｎｔ２から差分値ΔＣｎｔ１の絶対値を差し引いた値が２以上となる。この場合には新たな警報発生があったと考えられるので、警報鳴動を行う（ステップＳ３）。

図８は現状態カウンタ２４ａのカウント値Ｃｎｔ１が減少し、状態変化カウンタ２４ｂのカウント値が増加する事例を示しており、同図（ａ）では、前回の配信要求のタイミングＴａより前において警報発生があってカウント値Ｃｎｔ２が”ｎ”となり、前回の配信要求のタイミングＴａの経過後、今回の配信要求のタイミングＴｂまでに復旧があった場合を示しており、この場合現状態カウンタ２４ａのカウント値Ｃｎｔ１が復旧時においてデクリメントされる一方、カウント値Ｃｎｔ２が”ｎ＋１”にインクリメントされるため、今回の配信要求のタイミングＴｂでのΔＣｎｔ２−｜ΔＣｎｔ１｜の計算値は２未満となる。

同図（ｂ）では、前回の配信要求のタイミングＴａより前において警報発生があってカウント値Ｃｎｔ２が”ｎ”となり、前回の配信要求のタイミングＴａの経過後、今回の配信要求のタイミングＴｂまでに復旧があり、更にｍ回警報発生と復旧が繰り返された場合を示しており、この場合、今回の配信要求のタイミングＴｂでの現状態カウンタ２４ｂのカウント値Ｃｎｔ１が前回の配信要求のタイミングＴａでのカウンタ値より減少する一方、状態変化カウンタ２４ｂのカウント値Ｃｎｔ２が”ｎ＋２ｍ＋１”にインクリメントされるため、今回の配信要求のタイミングＴｂでのΔＣｎｔ２−｜ΔＣｎｔ１｜の計算値は２以上となる。

表１は図４のフローチャートの動作をまとめた表である。

さてローカル機器コントローラ２のＷｅｂサーバ部２３に対して上述のように端末３からＷｅｂサーバ部２３に配信要求があってＣＧＩサーバ部２４で上述のようにグループ化されて区別されるローカル機器群において警報鳴動を行うか、新たな警報鳴動を行わない（変化無し）かを決定しているが、本実施形態では、ローカル機器群毎に警報のレベルを決めており、警報鳴動を行う場合には、レベルの高いものを優先して行い、またレベルの高いローカル機器群に対して設定している警報鳴動時間が終了し、その終了時点でレベルの低いローカル機器群に対して設定している警報鳴動時間が残っている場合には、レベルの低いローカル機器群における警報鳴動を開始するという警報鳴動処理を行うようになっている。

ここで本実施形態では、火災報知関連のローカル機器群に対して最も高いレベル（以下火災レベルという）を設定し、更に停電検知に関連するローカル機器群に対して次のレベル（以下停電レベルという）を割り当て、その他のローカル機器群に対しては停電レベルより低いレベルを割り当て、その割り当てレベルはユーザーが任意に設定するようになっており、重要度の高い方から重警報レベル、中警報レベル、軽警報レベルとして設定される。

而して上述のように各ローカル機器群における状態変化に対応して警報鳴動を行うか行わないかを決定した後、図９に示すフローチャートの各レベルの鳴動時間判定のステップＳ１０、Ｓ２０、Ｓ３０、Ｓ４０、Ｓ５０において警報鳴動を行うか、行わないかを判定し、これらの判定後において、各レベルの鳴動処理をステップＳ６０、Ｓ７０，Ｓ８０，Ｓ１００で行って、鳴動するべき警報に鳴動時間を割り振るのである。この場合各レベルの警報の鳴動時間は、当該レベルに割り当てている警報鳴動設定時間から高いレベルの警報の鳴動時間を差し引いた時間が割り当てられることになる。

つまり最もレベルの高い火災レベル鳴動時間判定のステップＳ１０では、図１０（ａ）に示すように、まずステップＳ１０−１で火災レベルの警報鳴動を新たに行うか否かの判定を行い、警報鳴動をすると判定された場合には、ステップ１０−２で火災警報鳴動時間として当該レベルに設定されている火災警報鳴動設定時間を割り当てる。また新たに警報鳴動を必要としない場合にはステップＳ１０−３で前回から継続している警報鳴動の残り時間である火災警報鳴動継続時間が割り当てられる。つまり警報鳴動を継続させるのである。

次の停電レベル鳴動時間判定のステップＳ２０では、図１０（ｂ）に示すようにステップＳ２０−１で停電レベルの警報鳴動を新たに行うか否かの判定を行い、警報鳴動をすると判定された場合には、ステップＳ２０−２で停電警報鳴動時間として当該レベルに設定されている停電警報鳴動設定時間から火災警報鳴動時間を差し引いた時間を割り当てる。また新たに警報鳴動を必要としない場合にはステップＳ２０−３で前回から継続している警報鳴動の残り時間である停電警報鳴動継続時間から火災警報鳴動時間を差し引いた時間が割り当てられる。

そしてステップＳ２０−４では上述のように割り当てた停電警報鳴動時間が正か負かを判定し負の場合にはステップＳ２０−５において、停電警報鳴動時間を０とする。正の場合にはそのまま次のステップＳ３０へ移行する。

更に次の重警報レベル鳴動時間判定のステップＳ３０では、図１１（ａ）に示すようにステップＳ３０−１で重警報レベルの警報鳴動を新たに行うか否かの判定を行い、警報鳴動をすると判定された場合には、ステップＳ３０−２で重警報鳴動時間として当該レベルに設定されている重警報鳴動設定時間から火災警報鳴動時間と停電警報鳴動時間とを差し引いた時間を割り当てる。また新たに警報鳴動を必要としない場合にはステップＳ３０−３で前回から継続している警報鳴動の残り時間である重警報鳴動継続時間から火災警報鳴動時間と停電警報鳴動時間とを差し引いた時間を割り当てる。そしてステップＳ３０−４では上述のように割り当てた重警報鳴動時間が正か負かを判定し負の場合には重警報鳴動時間をステップＳ３０−５で０とする。正の場合にはそのまま次のステップＳ４０へ移行する。

次の中警報レベル鳴動時間判定のステップＳ４０では、図１１（ｂ）に示すようにステップＳ４０−１で中警報レベルの警報鳴動を新たに行うか否かの判定を行い、警報鳴動をすると判定された場合には、ステップＳ４０−２で中警報鳴動時間として当該レベルに設定されている中警報鳴動設定時間から火災警報鳴動時間と停電警報鳴動時間と重警報鳴動時間とを差し引いた時間を割り当てる。また新たに警報鳴動を必要としない場合にはステップＳ４０−３で前回から継続している警報鳴動の残り時間である中警報鳴動継続時間から火災警報鳴動時間と停電警報鳴動時間と重警報鳴動時間を差し引いた時間を割り当てる。そしてステップＳ４０−４では上述のように割り当てた中警報鳴動時間が正か負かを判定し負の場合には中警報鳴動時間をステップＳ４０−５で０とする。正の場合にはそのまま次のステップＳ５０へ移行する。

更に次の軽警報レベル鳴動時間判定のステップＳ５０では、図１２（ａ）に示すようにステップＳ５０−１で軽警報レベルの警報鳴動を新たに行うか否かの判定を行い、警報鳴動をすると判定された場合には、ステップＳ５０−２で軽警報鳴動時間として当該レベルに設定されている軽警報鳴動設定時間から火災警報鳴動時間と停電警報鳴動時間と重警報鳴動時間と中警報鳴動時間とを差し引いた時間を割り当てる。また新たに警報鳴動を必要としない場合にはステップＳ５０−３で前回から継続している警報鳴動の残り時間である軽警報鳴動継続時間から火災警報鳴動時間と停電警報鳴動時間と重警報鳴動時間と中警報鳴動時間とを差し引いた時間を割り当てる。そしてステップＳ５０−４では上述のように割り当てた軽警報鳴動時間が正か負かを判定し負の場合には軽警報鳴動時間をステップＳ５０−５で０とする。正の場合にはそのまま次のステップＳ６０へ移行する。

ステップＳ６０は火災レベル鳴動処理を図１２（ｂ）に示すように行う。つまりステップＳ６０−１では火災警報鳴動時間が０であるのか正であるのかを判定し、０の場合にはステップＳ６０−２において周期的に行われる次の配信要求（定周期更新）までの残り時間Ｎｆを予め設定されている配信要求間隔（定周期更新間隔）Ｎとして次のステップＳ７０へ移行する。

またステップＳ６０−１の判定で正と判定された場合には、ステップＳ６０−３で火災警報鳴動時間と予め設定されている配信要求間隔Ｎとを比較し、火災鳴動時間がＮより小さい場合には、ステップＳ６０−４で配信要求（定周期更新）までの残り時間Ｎｆを（Ｎ−火災警報鳴動時間）とし、更にステップＳ６０−５で火災警報鳴動時間を０とし、ステップＳ６０−６で火災警報鳴動の処理を行い、次のステップＳ７０へ移行する。

一方ステップＳ６０−３での判定で火災警報鳴動時間がＮより大きな場合にはステップＳ６０−７で火災警報鳴動時間を、割り振りされた火災警報鳴動時間からＮを差し引いた時間とし、ステップＳ６０−８で火災警報鳴動の処理を行ってステップＳ１０へ戻り、配信要求に対する処理を開始する。

ステップＳ７０は停電レベル鳴動処理を図１３（ａ）に示すように行う。つまりステップＳ７０−１では停電警報鳴動時間が０であるのか正であるのかを判定し、０の場合にはステップＳ７０−２において次の配信要求（定周期更新）までの残り時間Ｎｂを火災レベル鳴動処理後から次の配信要求（定周期更新）までの残り時間Ｎｆとし、次のステップＳ８０へ移行する。

またステップＳ７０−１の判定で正と判定された場合には、ステップＳ７０−３で停電警報鳴動時間と火災警報鳴動処理後から次の配信要求（定周期更新）までの残り時間Ｎｆとを比較し、停電警報鳴動時間がＮｆより小さい場合には、ステップＳ７０−４で配信要求（定周期更新）までの残り時間Ｎｂを（Ｎｆ−停電警報鳴動時間）とし、更にステップＳ７０−５で停電警報鳴動時間を０とし、ステップＳ７０−６で停電警報鳴動の処理を行い、次のステップＳ８０へ移行する。

一方ステップＳ７０−３での判定で停電警報鳴動時間がＮより大きな場合にはステップＳ７０−７で停電警報鳴動時間を、割り振りされた停電警報鳴動時間からＮｆを差し引いた時間とし、次のステップＳ７０−８で停電警報鳴動の処理で行ってステップＳ１０へ戻り、配信要求に対する処理を開始する。

ステップＳ８０は重警報レベル鳴動処理を図１３（ｂ）に示すように行う。つまりステップＳ８０−１では重警報鳴動時間が０であるのか正であるのかを判定し、０の場合にはステップＳ８０−２において次の配信要求（定周期更新）までの残り時間Ｎａ１を停電警報レベル鳴動処理後から次の配信要求（定周期更新）までの残り時間Ｎｂとし、次のステップＳ９０へ移行する。

またステップＳ８０−１の判定で正と判定された場合には、ステップＳ８０−３で重警報鳴動時間と停電警報鳴動処理後から次に配信要求（定周期更新）までの残り時間Ｎｂとを比較し、重警報鳴動時間がＮｂより小さい場合には、ステップＳ８０−４で配信要求（定周期更新）までの残り時間Ｎａ１を（Ｎｂ−重警報鳴動時間）とし、更にステップＳ８０−５で重警報鳴動時間を０とし、ステップＳ８０−６で重警報鳴動の処理を行い、次のステップＳ９０へ移行する。

一方ステップＳ８０−３での判定で重警報鳴動時間がＮｂより大きな場合にはステップＳ８０−７で重警報鳴動時間を、割り振りされた重警報鳴動時間からＮｂを差し引いた時間とし、次のステップＳ８０−８で重警報鳴動の処理を行ってステップＳ１０へ戻り、配信要求に対する処理を開始する。

ステップＳ９０は中警報レベル鳴動処理を図１４（ａ）に示すように行う。つまりステップＳ９０−１では中警報鳴動時間が０であるのか正であるのかを判定し、０の場合にはステップＳ９０−２において次の配信要求（定周期更新）までの残り時間Ｎａ２を重警報レベル鳴動処理後から次の配信要求（定周期更新）までの残り時間Ｎａ１とすし、次のステップＳ１００へ移行する。

またステップＳ９０−１の判定で正と判定された場合には、ステップＳ９０−３で中警報鳴動時間と重警報鳴動処理後から次に配信要求（定周期更新）までの残り時間Ｎａ１とを比較し、中警報鳴動時間がＮａ１より小さい場合には、ステップＳ９０−４で配信要求（定周期更新）までの残り時間Ｎａ２を（Ｎａ１−中警報鳴動時間）とし、更にステップＳ９０−５で中警報鳴動時間を０とし、ステップＳ９０−６で中警報鳴動の処理を行い、次のステップＳ１００へ移行する。

一方ステップＳ９０−３での判定で中警報鳴動時間がＮａ１より大きな場合にはステップＳ９０−７で中警報鳴動時間を、割り振りされた中警報鳴動時間からＮａ１を差し引いた時間とし、ステップ９０−８で中警報鳴動の処理を行ってステップＳ１０へ戻り、配信要求に対する処理を開始する。

ステップ１００は軽警報レベル鳴動処理を図１４（ａ）に示すように行う。つまりステップ１００−１では中警報鳴動時間が０であるのか正であるのかを判定し、０の場合にはステップ１００−２において次の配信要求（定周期更新）までの残り時間Ｎａ３を中警報レベル鳴動処理後から次の配信要求（定周期更新）までの残り時間Ｎａ２とし、ステップＳ１００−３で時間Ｎａ３（秒）スリープ処理後ステップＳ１０へ戻る。

またステップ１００−１の判定で正と判定された場合には、ステップ１００−４で軽警報鳴動時間と中警報鳴動処理後から次に配信要求（定周期更新）までの残り時間Ｎａ２とを比較し、軽警報鳴動時間がＮａ２より小さい場合には、ステップ１００−５で配信要求（定周期更新）までの残り時間Ｎａ３を（Ｎａ２−軽警報鳴動時間）とし、更にステップ１００−６で軽警報鳴動時間を０とし、ステップ１００−７で軽警報鳴動の処理を行い、上述のステップＳ１００−３の処理へ移行する。

一方ステップ１００−４での判定で軽警報鳴動時間がＮ２より大きな場合にはステップ１００−８で軽警報鳴動時間を、割り振りされた軽警報鳴動時間からＮａ２を差し引いた時間とし、ステップ１００−９で軽警報鳴動の処理を行ってステップＳ１０へ戻り、配信要求に対する処理を開始する。

而してＣＧＩサーバ部２４での上述の処理の結果はＷｅｂサーバ部２３を通じてＨＴＭＬとして配信要求を行った端末３へ返信されることになり、端末３ではＷｅｂブラウザ上で実行されるスクリプト言語で書かれたプログラム、例えばＪａｖａ（登録商標）（Sun Microsystems社登録商標）スクリプトなどやＷｅｂサーバ部２３から提供されるアプレットにより返信された処理結果が反映され、上述の処理結果に対応する警報鳴動が行われたり、その停止が行われることになり、ユーザーは端末３での警報鳴動によりローカル機器１が警報発生状態にあることを知ることになる。

ここで本実施形態では上記火災レベル、停電レベル、重警報レベル、中警報レベル、軽警報レベルのレベル順に、警報鳴動設定時間を段々と短く設定し、重要度（優先度）の高警報鳴動の時間を長くすることで、また警報鳴動として発鳴させる報知音の音色をレベル毎に変えることで識別性を持たせ、ユーザーの注意喚起を促す効果を高めてある。またローカル機器コントローラ２の近傍では警報ユニット１ｇを必要に増設することで、監視制御部２２の制御の下で警報鳴動をモニタすることもできる。

一方、本実施形態では、端末３のブラウジングの画面上に、警報発生内等を各レベル毎に対応させてアイコンにより表示を行うために。ＣＧＩサーバ部２４では監視制御部２２から受け取るローカル機器１からの状態情報に基づいて描画処理の判定を行うようになっている。

つまり本実施形態では、火災警報関連のローカル機器１において、前回の配信要求時以後から今回の配信要求時までの間に新たに火災警報発生があった場合や、前回の配信要求時において既に発生していた火災警報が現在も継続している場合、つまり今回の配信要求時において火災警報が発生中の場合には、図１５に示す端末３でのブラウジング画面に設けられた代表警報表示部３０の火災警報アイコン３０ａを点灯させると判定する。つまり今回の配信要求時点で火災警報発生中であれば、火災警報アイコン３０ａを点灯させると判定する。尚以前発生した火災警報が現在も発生中においては、火災警報鳴動時間が終了している場合も有り得るが、火災警報アイコン３０ａの点灯によりユーザーに火災警報発生中であることを知らせることができる。また火災警報鳴動時間が終了しているものの、火災警報のレベルより低いレベルによる警報鳴動中であっても、火災警報アイコン３０ａの点灯によってユーザーに火災警報発生中であることを知らせることができる。

一方今回の配信要求時点で火災警報発生が無い、或いは既に復旧している場合には火災警報アイコン３０ａを消灯させると判定する。この場合他のレベルに対応する警報鳴動の有無にかかわらず、火災警報アイコン３０ａを消灯させる。つまりアイコンの表示形態を変えることで、警報発生中か復旧している状態なのかをブラウザ画面上で報知させるようになっている。

同様に停電警報関連のローカル機器１において、前回の配信要求時以後から今回の配信要求時までの間に新たに警報発生があった場合や、前回の配信要求時において既に発生していた停電警報が現在も継続している場合、つまり今回の配信要求時において停電警報が発生中の場合には、図１５に示す端末３でのブラウジング画面に設けられた代表警報表示部３０の停電警報アイコン３０ｂを点灯させると判定する。つまり今回の配信要求時点で停電発生中であれば、停電警報アイコン３０ｂを点灯させると判定する。尚以前発生した停電警報が現在も発生中においては、停電警報鳴動時間が終了している場合も有り得るが、この停電警報アイコン３０ｂの点灯によりユーザーに停電警報発生中であることを知らせることができる。また停電警報鳴動時間が終了しているものの、停電警報のレベルより低い重又は中又は軽の警報による警報鳴動中であったり、或いは停電警報より高いレベルの火災警報による警報鳴動中であっても、停電警報アイコン３０ｂの点灯によってユーザーに停電警報発生中であることを知らせることができる。

一方今回の配信要求時点で停電警報発生が無い、或いは既に復旧している場合には停電警報アイコン３０ｂを消灯させると判定する。この場合停電警報に対して高いレベルの火災警報や他のレベルに対応する警報鳴動の有無にかかわらず、停電警報アイコン３０ｂを消灯させる。

更にユーザーにより設定される重・中・軽警報対象のローカル機器１において、前回の配信要求時以後から今回の配信要求時までの間に新たに警報発生があった場合や、前回の配信要求時において既に発生していた警報発生が現在も継続している場合、つまり今回の配信要求時において重・中・軽警報が発生中の場合には、図１５に示す端末３でのブラウジング画面に設けられた代表警報表示部３０の警報アイコン３０ｃを点灯させると判定する。つまり今回の配信要求時点で警報発生中であれば、警報アイコン３０ｃを点灯させると判定する。尚以前発生した当該警報が現在も発生中においては、警報鳴動時間が終了している場合も有り得るが、警報アイコン３０ｃの点灯によりユーザーに重・中・軽警報が発生中であることを知らせることができる。また警報鳴動時間が終了しているものの、当該重・中・軽警報のレベルより低いレベルに対応する警報鳴動中であったり、或いは重・中・軽警報より高いレベルの火災警報や停電警報による警報鳴動中であっても、警報アイコン３０ｃの点灯によってユーザーに重・中・軽警報発生中であることを知らせることができる。

而してＣＧＩサーバ部２４において上述の警報アイコンの点灯／消灯の判定をユーザーの端末３のブラウザ画面に反映させるために、端末３からの配信要求時にＷｅｂサーバ部２３からＨＴＭ形式のＬデータによって返信して、警報鳴動と同様に端末３側の例えばＪａｖａ（登録商標）（Sun Microsystems社登録商標）スクリプトにより描画させるのである。

尚本実施形態では、各警報アイコン３０ａ〜３０ｃと、各警報詳細画面とにリンクを張っており、ユーザーがブラウザ画面上でポインティングデバイスにより点灯中の警報アイコンをクリックすると、当該警報に対応した警報詳細画面に対応するＨＴＭＬ形式のデータをローカル機器コントローラ２から取得して警報詳細画面を表示させ、警報内容を確認することができる。このようにして各警報詳細についてユーザーが確認することができるのであるが、確認が済んでいない警報が存在している間は未確認アイコン３０ｄを点灯させることでユーザーに注意喚起することができるようになっている。

また、本実施形態では、最新の警報発生があると、その警報情報をブラウジング画面のメッセージ表示部３１においてスクロール表示させることができるようになっている。また当該警報発生が今回の配信要求時に復旧している場合にも同様に情報をスクロール表示させてその警報発生が復旧したことをユーザーに提示できるようになっている。この場合発生と復旧を識別するために文字色を異ならしている。

尚本実施形態ではローカル機器コントローラ２の記憶装置２０ｂにおいて各ローカル機器１の状態の変遷などの履歴や各種設定内容を記憶しており、ユーザーは端末３のブラウザ画面のメニュー欄３２上の釦操作によりこれら内容を呼び出して表示させることをローカル機器コントローラ２側へ要求することができるようになっている。またシステムとして必要な設定のための設定画面も、ユーザーが端末３のブラウザ画面のメニュー欄３２上の釦操作で呼び出すことができ、設定内容をローカル機器コントローラ２の記憶装置２０ｂに保存させることができるようにもなっている。

尚、現状態カウンタ２４ａ、状態変化カウンタ２４ｂの２つのカウンタによって、前後の配信要求のタイミングの期間中に発生し消滅した事象の回数をカウントし、所定閾値を超えるとチャタリング発生の旨の通知（警報というほどでもない）を行うようにしてもよい。このような事例としては、ビル屋上の貯水タンクに貯水量が所定水位に達したか否かを検出する水位センサを設けておく場合、本当は所定水位に達していないのに地震が起きると水位センサはチャタリングを検出してしまうことになる。しかしこの場合は地震若しくは貯水タンクが何らかの原因で揺れたものと判定し、水位センサがチャタリングなく水位を検出できてはじめて所定水位到達だとローカル機器コントローラ２内で判定すればよいのである。このようにチャタリングを検出した場合には、安定した検知結果が得られるまで、設計時当初に想定した事象には至っていないものとみなし、その旨をローカル機器コントローラ２からユーザーの端末３に配信提供すればよい。この設計仕様は、貯水タンクの水位センサのみに限らず、チャタリングを検出するタイプのセンサであれば、どんなセンサにも適用可能である。

一実施形態のローカル機器コントローラの構成図である。 一実施形態の遠隔監視システムの全体構成図である。 一実施形態のローカル機器コントローラの現状態カウンタ及び状態変化カウンタの動作説明用タイミングチャートである。 一実施形態のローカル機器コントローラでの警報鳴動決定の判定処理のフローチャートである。 一実施形態のローカル機器コントローラの現状態カウンタ及び状態変化カウンタのカウント値が増加する事例のタイミングチャートである。 一実施形態のローカル機器コントローラの現状態カウンタのカウント値が変化無しで状態変化カウンタのカウント値が増加する事例のタイミングチャートである。 一実施形態のローカル機器コントローラの現状態カウンタ及び状態変化カウンタのカウント値の変化が無い事例のタイミングチャートである。 一実施形態のローカル機器コントローラの現状態カウンタのカウント値が減少し、状態変化カウンタのカウント値が増加する事例のタイミングチャートである。 一実施形態のローカル機器コントローラでのレベル別の警報鳴動決定処理の説明用フローチャートである。 一実施形態のローカル機器コントローラでのレベル別の警報鳴動決定処理における火災レベル鳴動時間判断処理の説明用フローチャートである。 一実施形態のローカル機器コントローラでのレベル別の警報鳴動決定処理における停電レベル鳴動時間判断処理の説明用フローチャートである。 一実施形態のローカル機器コントローラでのレベル別の警報鳴動決定処理における重警報レベル鳴動時間判断処理の説明用フローチャートである。 一実施形態のローカル機器コントローラでのレベル別の警報鳴動決定処理における中警報レベル鳴動時間判断処理の説明用フローチャートである。 一実施形態のローカル機器コントローラでのレベル別の警報鳴動決定処理における軽警報レベル鳴動時間判断処理の説明用フローチャートである。 一実施形態のＷｅｂブラウザ搭載型端末のブラウザ画面の表示例図である。

符号の説明

１ ローカル機器
２ ローカル機器コントローラ
２０ａ 中央演算装置
２０ｂ 記憶装置
２１ 伝送信号送受信部
２２ 監視制御部
２３ Ｗｅｂサーバ部
２４ ＣＧＩサーバ部
２５ 通信部
３ Ｗｅｂブラウザ搭載型端末
５ 伝送線
６ 信号線

Claims (12)

1. 各種検知状態、各種被制御状態が変化するローカル機器と、該ローカル機器と通信して該ローカル機器の各種検知状態、各種被制御状態を収集するローカル機器コントローラとを備えて構成され、前記ローカル機器コントローラをサーバとし所定通信線を介してクライアントマシンとなるユーザーのＷｅｂブラウザ搭載型端末に前記ローカル機器の各種検知状態、各種被制御状態を前記ローカル機器コントローラがブラウジング表示する遠隔監視システムに用いられる機器状態変化報知方法において、
   前記ローカル機器コントローラは、前記ローカル機器の各種検知状態、各種被制御状態を収集して、前記ローカル機器の各種検知状態や各種被制御状態が一の状態から二の状態へ変化している現状状態の発生回数をカウントしてカウント値を記録する現状態カウンタと、前記ローカル機器の各種検知状態や各種被制御状態が一の状態から二の状態へ変化した回数及び二の状態から一の状態へ復帰した回数の総数をカウントしてカウント値を記録する状態変化カウンタとが設けられ、前記Ｗｅｂブラウザ搭載型端末から周期的に繰り返される配信要求毎に前記現状態カウンタ及び状態変化カウンタの記録された各カウント値に応じて、前記Ｗｅｂブラウザ搭載型端末における機器状態変化の報知の要否を決定することを特徴とする機器状態変化報知方法。
2. 今回の配信要求時の前記現状態カウンタのカウント値が前回の配信要求時のカウント値よりも増加し、且つ今回の配信要求時の前記状態変化カウンタのカウント値が前回の配信要求時のカウント値よりも増加した場合、前記ローカル機器の各種検知状態、各種被制御状態が一の状態から二の状態に変化したものとみなし、機器状態変化の報知を決定することを特徴とする請求項１記載の機器状態変化報知方法。
3. 今回の配信要求時の前記現状態カウンタのカウント値が前回の配信要求時値と同値で、且つ今回の配信要求時の前記状態変化カウンタのカウント値が前回の配信要求時のカウント値よりも増加した場合、前記ローカル機器の各種検知状態、各種被制御状態が一の状態から二の状態に変化したものとみなし、機器状態変化の報知を決定することを特徴とする請求項１又は２記載の機器状態変化報知方法。
4. 今回の配信要求時の前記現状態カウンタのカウント値から前回の配信要求時のカウント値を減じた差分値である現状態カウンタ差分値と、今回の配信要求時の前記状態変化カウンタのカウント値から前回の配信要求時のカウント値を減じた差分値である状態変化カウンタ差分値とを求めておき、前記現状態カウンタの今回の配信要求時のカウント値が前回の配信要求時のカウント値よりも減少し、且つ前記状態変化カウンタ差分値から前記現状態カウンタ差分値の絶対値を減じた値が２以上の値である場合、前記ローカル機器の各種検知状態、各種被制御状態が一の状態から二の状態に変化したものとみなし、機器状態変化の報知を決定することを特徴とする請求項１乃至３の何れに記載の機器状態変化報知方法。
5. 今回の配信要求時の前記現状態カウンタのカウント値から前回の配信要求時のカウント値を減じた差分値である現状態カウンタ差分値と、今回の配信要求時の前記状態変化カウンタのカウント値から前回の配信要求時のカウント値を減じた差分値である状態変化カウンタ差分値とを求めておき、前記現状態カウンタの今回の配信要求時のカウント値が前回の配信要求時のカウント値よりも減少し、且つ前記状態変化カウンタ差分値から前記現状態カウンタ差分値の絶対値を減じた値が２未満の値である場合、新たな報知の必要は無いと決定することを特徴とする請求項１乃至４の何れに記載の機器状態変化報知方法。
6. 今回の配信要求時の前記現状態カウンタのカウント値が前回の配信要求時のカウント値よりも増加し、且つ今回の配信要求時の前記状態変化カウンタのカウント値が前回の配信要求時のカウント値よりも減少又は同値である場合、新たな報知を行う必要は無いと決定することを特徴とする請求項１乃至５の何れに記載の機器状態変化報知方法。
7. 今回の配信前記現状態カウンタのカウント値が前回の配信要求時のカウント値と比べて変わらず、且つ前記状態変化カウンタの今回の配信要求時のカウント値が前回の配信要求時のカウント値よりも減少又は同値である場合、新たな報知を行う必要は無いと決定することを特徴とする請求項１乃至６の何れに記載の機器状態変化報知方法。
8. 機器状態変化の報知を行う場合、前記Ｗｅｂブラウザ搭載型端末に鳴動させる報知音の仕様を、報知内容の重要度によって鳴動時間及び／又は音色を変化させることで、変更することを特徴とする請求項２乃至４の何れに記載の機器状態変化報知方法。
9. 前記Ｗｅｂブラウザ搭載型端末に、報知対象のローカル機器に対応させたアイコンを表示させておき、前後の配置要求のタイミングで区切られる期間毎の現状態カウンタと状態変化カウンタの各記録カウント値の変化に応じてアイコンの表示態様を変更することによって、当該ローカル機器の各種被制御状態を表現することを特徴とする請求項１乃至８の何れに記載の機器状態変化報知方法。
10. 機器状態変化報知内容を前記Ｗｅｂブラウザ搭載型端末にブラウジング表示させる以前に、各種被制御状態が変化前の状態に復帰していたとしても、その復帰した旨を、前記Ｗｅｂブラウザ搭載型端末にメッセージ表示させることを特徴とする請求項１乃至９の何れに記載の機器状態変化報知方法。
11. 請求項１乃至１０の何れに記載の機器状態変化報知方法を用いて、ユーザーのＷｅｂブラウザ搭載型端末との間の通信を行うことを特徴とするローカル機器コントローラ。
12. 各種検知状態、各種被制御状態が変化するローカル機器と、ローカル機器と通信してローカル機器の各種検知状態、各種被制御状態を収集する請求項１１のローカル機器コントローラとを備えて構成されていることを特徴とする遠隔監視システム。