JP2015114703A - 警報通知装置、警報通知システムおよび警報通知プログラム - Google Patents

Abstract

【課題】時系列に状態が変化する警報データを効率的に送信すること。
【解決手段】機器管理装置２は、設備機器１で発生する警報イベントを、時系列の履歴データとして履歴テーブル２４に格納するとともに、設備機器１ごとの最新の警報イベントを現状態テーブル２３に格納する登録部２１と、履歴テーブル２４の未通知分の警報イベント集合、および、現状態テーブル２３の警報イベント集合のうちの比較結果として小さいデータ量である片方の警報イベント集合を、通知要求の送信元である状態表示装置３に対して通知する通知応答部２５とを有する。状態表示装置３は、通知された警報イベント集合を表示する。
【選択図】図１

Description

本発明は、警報通知装置、警報通知システムおよび警報通知プログラムに関する。

特許文献１や特許文献２には、ストリーミングによってコンテンツデータを配信する際に、中断された配信処理が再開されると、既に配信済みのデータの再送を省略することで、データ通信量を削減する旨が記載されている。

特開２０１１−１８２０６１号公報 特開２００８−３１０６２１号公報

設備機器の管理用ローカルネットワークとして、専用のネットワークが用いられてきており、設備機器の監視端末も専用のネットワーク内に設置されてきた。近年は、監視端末を専用のネットワークではなく、イントラネットなどのＯＡ用のネットワークに設置し遠隔から監視できるような構成が出現している。

監視端末（状態表示装置）は、設備機器で発生した警報イベントなどの状態変化を表示することで、設備機器の監視を支援する。この監視端末に通知される警報イベントのデータ通信量の効率化が求められている。警報イベントの通知に専用のネットワークを介さない場合、設備機器以外が原因のネットワーク負荷で、制御や状態変化の取得に失敗する場合があるためである。

また、設備機器で管理する機器の数が多く、それぞれの機器で連続的かつ大量に警報が発生した場合、警報ごとに取得処理が行われると、通信量が増大し通信経路を圧迫されることで、警報の伝達が遅くなってしまう。また、警報の発生ごとに表示更新処理を行うと、警報状態を表示する装置の負荷が増大してしまう。

特許文献１や特許文献２に記載の配信システムを警報イベントの通知処理に適用しても、充分にデータ通信量を削減することはできない。これらの従来の配信システムでは、時系列に連続して再生されるストリーミングデータを前提としており、同じデータを２回重複して送信しないだけでは、データ通信量の削減は困難である。

なお、時系列に突発的に発生する警報イベントは、最新ではない多くの警報イベントの送信を省略することができる。例えば、過去５分おきに警報が鳴ったり鳴り止んだりを繰り返すような事象では、現在の（最新の）警報が鳴っているか否かだけを送信すればよく、過去の５分ごとの警報イベントの送信を省略できる。

そこで、本発明は、時系列に状態が変化する警報データを効率的に送信することを、主な課題とする。

前記課題を解決するために、本発明の警報通知装置は、
設備機器で発生する警報イベントを、時系列の履歴データとして履歴管理用データに格納するとともに、前記設備機器ごとの最新の警報イベントを現状態管理用データに格納する登録部と、
状態表示装置に対して既に通知された警報イベントを示す情報を含む通知要求を前記状態表示装置から受信し、前記履歴管理用データの履歴データから、前記通知要求の送信元である前記状態表示装置に対して未通知分の履歴データを特定し、前記未通知分の履歴データのデータ量と、前記現状態管理用データのデータ量とを比較し、
前記履歴管理用データの未通知分の警報イベント集合、および、前記現状態管理用データの警報イベント集合のうちの前記比較結果として小さいデータ量である片方の警報イベント集合を、前記通知要求の送信元である前記状態表示装置に対して通知する通知応答部とを有することを特徴とする。
その他の手段は、後記する。

本発明によれば、時系列に状態が変化する警報データを効率的に送信することができる。

本発明の一実施形態に関する状態通知システムを示す構成図である。 本発明の一実施形態に関する状態通知システムの各テーブルを示す構成図である。 本発明の一実施形態に関する状態通知処理（ＩＤ＝１〜６）を示す説明図である。 本発明の一実施形態に関する状態通知処理（ＩＤ＝７）を示す説明図である。 本発明の一実施形態に関する状態通知処理（ＩＤ＝１〜１４）を示す説明図である。 本発明の一実施形態に関する警報表示部による表示画面を示す画面図である。 本発明の一実施形態に関する登録部が実行する、新規イベントの登録処理を示すフローチャートである。 本発明の一実施形態に関する通知応答部が実行する、通知要求への応答処理を示すフローチャートである。 本発明の一実施形態に関する図８のＳ２１０（一覧通知処理）の詳細を示すフローチャートである。 本発明の一実施形態に関する図８のＳ２２０（履歴通知処理）の詳細を示すフローチャートである。 本発明の一実施形態に関する通知要求部が実行する、通知要求処理およびその応答結果の表示処理を示すフローチャートである。

以下、本発明の一実施形態を、図面を参照して詳細に説明する。

図１は、状態通知システムを示す構成図である。
状態通知システムは、設備機器１と、機器管理装置（警報通知装置）２と、状態表示装置３とがネットワークで接続されて構成される。
これらの各装置は、演算処理を行う際に用いられる記憶手段としてのメモリと、前記演算処理を行う演算処理装置とを少なくとも備えるコンピュータを搭載または内蔵している。このコンピュータのメモリは、ＲＡＭ（Random Access Memory）などにより構成される。演算処理は、ＣＰＵ（Central Processing Unit）によって構成される演算処理装置が、メモリ上のプログラムを実行することで、実現される。
なお、状態通知システムを構成する各装置の台数について、図１に例示した台数だけでなく、状態表示装置３や、機器管理装置２をそれぞれ複数設置してもよい。

設備機器１は、センサ、電力メータ、空調や照明といった機器である。各設備機器１は、自身の制御状態が変化した場合に、機器管理装置２に対して警報イベントを通知する。警報イベントには、ユーザに警報を知らせる状態（以下「ＯＮ」）を示す情報や、ユーザに警報を知らせない状態（以下「ＯＦＦ」）を示す情報や、設備機器１が管理する状態値（例えば、電力計の計測値）が含まれる。

機器管理装置２は、設備機器１ごとの警報イベントを管理する装置であり、設備機器１とＬＡＮ（Local Area Network）やＬＯＮ（Local Operation Network）、ＲＳ（Recommended Standard）−２３２Ｃ、ＲＳ−４８５などで相互に接続される。
状態表示装置３は、機器管理装置２が管理する設備機器１ごとの警報イベントに従って、「ＯＮ」である警報を表示する装置である。状態表示装置３は、機器管理装置２とＬＡＮなどのビル内に設置されたネットワークで相互に接続される。

機器管理装置２は、登録部２１と、通知元制御データ２２と、現状態テーブル（現状態管理用データ）２３と、履歴テーブル（履歴管理用データ）２４と、通知応答部２５とを含めて構成される。
状態表示装置３は、通知要求部３１と、通知先制御データ３２と、通知先テーブル３３と、警報表示部３４とを含めて構成される。

登録部２１は、設備機器１から警報イベントを受けると、受けた警報イベントを履歴テーブル２４に時系列に追加（履歴登録）し、その追加に伴って現状態テーブル２３内の警報の状態（ＯＮまたはＯＦＦ）を更新する（履歴反映）。そして、登録部２１は、警報イベントが新規に発生した旨を通知応答部２５に通知する。
通知元制御データ２２は、ＯＮ警報数、最新発生ＩＤ、最新ＯＮＩＤなどの通知元（機器管理装置２）での制御に使用されるデータである。これらのデータの詳細は、図２以降の説明で明らかにする。
現状態テーブル２３には、設備機器１ごとの最新の警報の状態（ＯＮまたはＯＦＦ）が格納されている（詳細は、図２（ｂ））。
履歴テーブル２４は、警報イベントごとの履歴情報が格納されている（詳細は、図２（ａ））。

通知応答部２５は、通知要求部３１から通知要求を受信すると、状態表示装置３に未通知分の警報イベントを履歴テーブル２４または現状態テーブル２３から取得し、状態通知として通知要求部３１に送信する。
なお、状態通知の方式は、履歴テーブル２４から取得した履歴データの通知（以下、「履歴通知」）か、現状態テーブル２３から取得した状態一覧データの通知（以下、「一覧通知」）かのいずれかである。これらの２方式の詳細は、図８などで後記する。

通知要求部３１は、通知先制御データ３２内の最新通知ＩＤを含む通知要求を、通知応答部２５に送信する。そして、通知要求部３１は、通知要求への応答として、状態通知（履歴通知または一覧通知）を受信すると、その状態通知に含まれる警報イベントを通知先テーブル３３へと更新（状態更新）する。なお、通知要求や状態通知の通信には、ＨＴＴＰ（Hyper Text Transfer Protocol）などの通信プロトコルが利用される。

通知先制御データ３２は、最新通知ＩＤなどの通知先での制御に使用されるデータである。これらのデータの詳細は、図２以降の説明で明らかにする。
通知先テーブル３３は、
警報表示部３４は、通知先テーブル３３の更新などを契機として、プロセス間通信などで通知要求部３１から表示要求を受ける。そして、警報表示部３４は、通知先テーブル３３からＯＮである警報の一覧を取得し（状態取得）、液晶ディスプレイなどの画面に表示する。

図２は、状態通知システムの各テーブル（現状態テーブル２３、履歴テーブル２４、通知先テーブル３３）を示す構成図である。各テーブル間で同じ名称の列（例えば「機器」）は、同じ意味である。

図２（ａ）の履歴テーブル２４は、設備機器１で発生した警報イベントを時系列の履歴形式で保存するテーブルである。履歴テーブル２４は、警報ＩＤ、日時、機器、イベント、状態から構成される。
警報ＩＤ列は、警報イベントに対して一意に割り当てられた数値であり、警報イベントの登録時に連番で割り当てられる。
日時列は、設備機器１で発生した警報の発生日時が保持される。例えば、警報ＩＤ＝１の「2013-08-15T08:00:32」とは、２０１３年８月１５日８時０分３２秒を示す。
機器列には、警報イベントの発生元である設備機器１の識別情報が保持される。
イベント列には、警報イベントの種別が保持される。
状態列には、警報を知らせるのか（ＯＮ）、知らせないのか（ＯＦＦ）という警報の状態が保持される。なお、警報の状態として、ＯＮ−ＯＦＦの２値だけでなく、警報を知らせる状態（ＯＮ）を細分化して、知らせる警報の種別（赤ランプ点灯、黄ランプ点灯など）を特定する情報を含ませてもよい。

通知元制御データ２２の最新発生ＩＤは、履歴テーブル２４内の警報ＩＤのうちの最新のものである。
通知元制御データ２２の最新ＯＮＩＤは、履歴テーブル２４内の状態がＯＮである警報ＩＤのうちの最新のものである。
なお、図２（ａ）の例では、最新発生ＩＤ＝１４，最新ＯＮＩＤ＝１２である。

図２（ｂ）の現状態テーブル２３は、履歴テーブル２４に登録されている警報イベントから、各設備機器１について、最新のレコード（イベント、状態、警報ＩＤ）を抜粋（履歴反映）したテーブルである。
例えば、図２（ｂ）の現状態テーブル２３は、図２（ａ）の履歴テーブル２４のうちのすべて（ＩＤ＝１〜１４）のレコードを対象として、最新のレコードが履歴反映されている。よって、機器「第２設備」のレコードは、履歴テーブル２４内に警報ＩＤ＝７，１４の２つ存在するが、そのうちの最新である警報ＩＤ＝１４のレコードだけ、現状態テーブル２３に反映されている。つまり、警報ＩＤ＝７である古いレコードは、警報ＩＤ＝１４である新しいレコードによって上書きされる。
なお、通知元制御データ２２のＯＮ警報数は、現状態テーブル２３内の状態がＯＮである警報の総数であり、図２（ｂ）の例では、警報ＩＤ＝５，６の２つである。

図２（ｃ）の通知先テーブル３３は、現状態テーブル２３および履歴テーブル２４から通知された警報イベント（日時、機器、イベント）のうちの状態がＯＮであるものを格納する。例えば、図２（ｃ）の通知先テーブル３３は、図２（ｂ）の現状態テーブル２３のうちの警報ＩＤ＝１〜６に該当するデータが通知されたものである。
通知先制御データ３２の最新通知ＩＤは、通知先テーブル３３に反映されている最新の警報ＩＤ、換言すると、機器管理装置２から応答された警報イベントのうちの最新の警報ＩＤである。

図３は、状態通知処理（ＩＤ＝１〜６）を示す説明図である。
図３（ａ）では、機器管理装置２内の履歴テーブル２４に警報ＩＤ＝１〜６の警報イベントがあり、それらの警報イベントが現状態テーブル２３に履歴反映されている。よって、最新発生ＩＤ＝６である。しかし、警報ＩＤ＝１〜６の警報イベントは、いずれも状態表示装置３に通知されておらず、状態表示装置３の最新通知ＩＤ＝０（未通知を示す）である。そして、状態表示装置３は、機器管理装置２に対して最新通知ＩＤ＝０を含む通知要求を送信する。

図３（ｂ）は、図３（ａ）の後の状態である。機器管理装置２は、最新通知ＩＤ＝０の通知要求を受け、自身が管理する警報ＩＤ＝１〜６の警報イベントをすべて送信対象とする。機器管理装置２は、履歴テーブル２４の警報イベント（ＩＤ＝１〜６）を状態表示装置３に履歴通知する。
状態表示装置３は、通知された警報イベント（ＩＤ＝１〜６）を自身の通知先テーブル３３へと反映し、最新通知ＩＤ＝６に更新し、通知先テーブル３３の反映結果（ＯＮである警報内容）をユーザに知らせる。

図４は、図３（ｂ）の後に警報イベント（ＩＤ＝７）が発生したときの状態通知処理を示す説明図である。
図４（ａ）では、機器管理装置２は、新規に発生した警報イベント（ＩＤ＝７）を現状態テーブル２３および履歴テーブル２４にそれぞれ反映する。その後、機器管理装置２は、状態表示装置３から最新通知ＩＤ＝６の通知要求を受けると、自身で管理する７つの警報イベントのうち、６つが既に通知済であり、最新の１つが未通知であることを認識する（未通知分の警報件数＝最新発生ＩＤ−最新通知ＩＤ）。
そして、機器管理装置２は、現状態テーブル２３の警報イベント件数よりも、履歴テーブル２４の未通知分の警報イベント件数（１件）のほうが少ないと判断する。

図４（ｂ）では、図４（ａ）での機器管理装置２の判断に従い、状態表示装置３は、警報イベント（ＩＤ＝７）だけの履歴通知を受ける。そして、状態表示装置３は、受信した警報イベント（ＩＤ＝７）を自身の通知先テーブル３３へと反映する。
なお、ここでの反映とは、レコードの追加処理だけでなく、レコードの書き換え処理やレコードの削除処理を含む（詳細は、図１１で後記）が、反映前に通知先テーブル３３のリフレッシュ（全消去）は行わない。
以上、図４で説明したように、未通知分が少ないときにはその未通知分だけを履歴通知することで、通信のデータ量を削減することができる。

図５は、図３（ｂ）の後に警報イベント（ＩＤ＝７〜１４）が発生したときの状態通知処理を示す説明図である。
図５（ａ）では、機器管理装置２は、新規に発生した警報イベント（ＩＤ＝７〜１４）を現状態テーブル２３および履歴テーブル２４にそれぞれ反映する。その後、機器管理装置２は、状態表示装置３から最新通知ＩＤ＝６の通知要求を受けると、自身で管理する１４つの警報イベントのうち、前半の７つが既に通知済であり、後半の７つが未通知であることを認識する。
そして、機器管理装置２は、履歴テーブル２４の未通知分の警報イベント件数（７件）よりも、現状態テーブル２３の警報イベント件数のほうが少ないと判断する。

そして、機器管理装置２の判断に従い、状態表示装置３は、現状態テーブル２３の警報イベント（ＩＤ＝１〜１４）の一覧通知を受ける。ここで、図２（ｂ）ですでに説明したように、現状態テーブル２３には、警報ＩＤ＝１〜１４の１４件分が反映されているものの、同じ設備機器１について複数回の警報イベントが発生したときには、古いデータが新しいデータで上書きされる。よって、現状態テーブル２３のデータ件数は、１４件よりも少なくて済む。
状態表示装置３は、受信した警報イベント（現状態テーブル２３の各データ）を自身の通知先テーブル３３へと反映する。なお、反映前に通知先テーブル３３のリフレッシュ（全消去）が行われる。そして、状態表示装置３は、最新通知ＩＤを最新発生ＩＤと同じ値（ＩＤ＝１４）へと更新する。

図５（ｂ）は、図５（ａ）の一覧通知が反映された通知先テーブル３３の内容を示す。図２（ｂ）の現状態テーブル２３のうち、状態がＯＮである２件のデータが反映されている。
以上、図４で説明したように、未通知分が多いときには、未通知分だけを履歴通知するより、一覧通知を選択することで、通信のデータ量を削減することができる。

図６は、警報表示部３４による表示画面を示す画面図である。この表示画面は、ビルの平面図であり、設備機器１として、ＤＩ１〜ＤＩ５，電力計，第２設備がビル内に配備されている。ＤＩ１〜ＤＩ５とは、ドアに備え付けられた開閉センサであり、ドアが開いた状態で警報がＯＮになるようになっている。なお、本実施形態の設備機器１は、ビルに適用するだけでなく、マンション、オフィス、工場などの施設に設置することも可能である。

図６（ａ）は、図２（ｃ）の通知先テーブル３３のエントリを表示した画面図である。ＤＩ１〜ＤＩ５および電力計に警報が発生した旨を、警報マークでわかりやすく表示している。図６（ｂ）は、図５（ｂ）の通知先テーブル３３のエントリを表示した画面図である。Ｄ２および電力計に警報が発生している。なお、状態表示装置３は、警報マークを画面表示する他にも、音声などを鳴らしてユーザに知らせることができる。

さらに、図６（ａ）（ｂ）それぞれにおいて、画面の左下に「今回警報ＯＮ：あり」が表示されている。この表示は、最新通知ＩＤから最新発生ＩＤまでの間に、いずれかの設備機器１でＯＮである警報イベントが１回以上発生した旨を、ユーザに知らせるための表示である。この表示を行うため、機器管理装置２は、最新通知ＩＤ＜最新ＯＮＩＤであるときに、状態通知に今回警報ＯＮフラグを含ませて状態表示装置３に送信する。
この表示により、ユーザは、現在（最新発生ＩＤの日時）は警報では知らされないものの、過去に警報が発生したこと（何らかの異常が発生したが、現在はその異常から復帰していること）を知ることができる。

図７は、登録部２１が実行する、新規イベントの登録処理を示すフローチャートである。このフローチャートは、機器管理装置２の起動後に実行される。
Ｓ１０１として、登録部２１は、設備機器１に新規警報イベントが発生したか否かを判定する。新規警報イベントには、その日時と、発生元の機器ＩＤと、警報の状態（ＯＮまたはＯＦＦ）とが含まれている。Ｓ１０１でＹｅｓならＳ１０２へ進み、ＮｏならＹｅｓになるまでＳ１０１を繰り返す。

Ｓ１０２として、登録部２１は、Ｓ１０１で発生した新規警報イベントに関する通知元制御データ２２を、以下のように更新する。
・最新発生ＩＤに、現在の最新発生ＩＤ＋１（未使用のＩＤ値）を代入する。
・新規警報イベントの状態＝ＯＮなら、通知元制御データ２２の最新ＯＮＩＤに、更新された最新発生ＩＤを代入し、通知元制御データ２２のＯＮ警報数を＋１する。
・新規警報イベントの状態＝ＯＦＦなら、通知元制御データ２２のＯＮ警報数を−１する。

Ｓ１０３として、登録部２１は、Ｓ１０１で発生した新規警報イベントを、履歴テーブル２４に追加する。つまり、登録部２１は、Ｓ１０２で更新された最新発生ＩＤを警報ＩＤとする新たなレコードを作成し、その作成したレコードデータとして、新規警報イベントに含まれている日時と、発生元の機器と、警報の状態とを格納する。

Ｓ１０４として、登録部２１は、Ｓ１０１の新規警報イベントに含まれる機器ＩＤのレコードが現状態テーブル２３に存在するか否かを判定する。Ｓ１０４でＹｅｓならＳ１０５へ進み、ＮｏならＳ１０６へ進む。
Ｓ１０５として、登録部２１は、現状態テーブル２３内のＳ１０４で存在した既存エントリを、Ｓ１０１の新規警報イベントに含まれる各データで書き換える。
Ｓ１０６として、登録部２１は、Ｓ１０２で更新された最新発生ＩＤに対応する新規エントリを現状態テーブル２３内に追加する。登録部２１は、新規エントリのレコードデータとして、Ｓ１０１の新規警報イベントに含まれる各データを書き出す。
Ｓ１０７として、登録部２１は、Ｓ１０１の新規警報イベントが発生した旨を通知応答部２５に通知し、Ｓ１０１に戻る。

図８は、通知応答部２５が実行する、通知要求への応答処理を示すフローチャートである。このフローチャートは、通知要求部３１から通知要求があった場合に実行される。
Ｓ２０１として、通知応答部２５は、通知要求部３１から最新通知ＩＤを含む通知要求を受信する。この通知要求の送信処理は、後記する図１１のＳ３０２で説明する。
Ｓ２０２として、通知応答部２５は、図３〜図５で説明したように、未通知分の警報イベントが履歴テーブル２４に存在するか否かを判定する。なお、Ｓ２０１の通知要求に含まれる最新通知ＩＤ＜最新発生ＩＤなら、未通知分の警報イベントが存在する。Ｓ２０２でＹｅｓならＳ２０３へ進み、Ｎｏなら新たに、登録部２１から新規警報イベントが通知（Ｓ１０７）されるまでＳ２０２で待機する。

Ｓ２０３として、通知応答部２５は、後記するＳ２１０の一覧通知にて送信対象となる警報イベントの件数を特定する。この特定処理は、以下の（方法１ａ）または（方法１ｂ）のいずれかである。
（方法１ａ）現状態テーブル２３の全レコードを送信対象とし、そのレコード数を送信対象件数とする。
（方法１ｂ）現状態テーブル２３のうちの状態がＯＮであるレコードを送信対象とし、そのレコード数（＝通知元制御データ２２のＯＮ警報数）を送信対象件数とする。
なお、（方法１ｂ）を用いるときには、現状態テーブル２３内に状態がＯＦＦであるレコードを保持する必要がなくなるため、現状態テーブル２３のサイズを削減できる。その場合、Ｓ１０５でＯＦＦであるレコードを削除し、Ｓ１０６でＯＦＦであるレコードの追加を行わないように、それぞれ現状態テーブル２３の新規イベントの登録処理を置き換えればよい。

Ｓ２０４として、通知応答部２５は、後記するＳ２２０の履歴通知にて送信対象となる警報イベントの件数を特定する。この特定処理は、以下の（方法２ａ）または（方法２ｂ）のいずれかである。
（方法２ａ）履歴テーブル２４内の、最新通知ＩＤ＋１から最新発生ＩＤまでの全レコードを送信対象とする。送信対象件数＝（通知元制御データ２２の最新発生ＩＤ）−（Ｓ２０１の最新通知ＩＤ）である。
（方法２ｂ）前記の（方法２ａ）のうちの設備機器１ごとの最新ではないレコードを除外したもの（換言すると、設備機器１ごとの最新レコードを抜粋したもの）を送信対象とする。つまり、１つの設備機器１の警報イベントが最新通知ＩＤより後に複数回発生していた場合に、そのうちの最新の警報イベントを示す履歴だけを送信する。
例えば、図２（ａ）では、最新通知ＩＤ＝６より後で最新発生ＩＤ＝１４以前のレコードのうち、警報ＩＤ＝１２，１３が、ともに機器「ＤＩ４」のレコードである。よって、（方法２ａ）では、警報ＩＤ＝１２，１３のレコードが送信対象となるが、（方法２ｂ）では、警報ＩＤ＝１３のレコードが送信対象となる。

Ｓ２０５として、通知応答部２５は、Ｓ２０３の一覧通知件数とＳ２０４の履歴通知件数とのうちの少ない件数の通知方式を選択する。そのため、判定式「一覧通知件数＜履歴通知件数」を満たすか否かを判定する。Ｓ２０５でＹｅｓならＳ２１０へ進み、ＮｏならＳ２２０へ進む。
Ｓ２１０として、通知応答部２５は、Ｓ２０３で特定した送信対象の警報イベントを、一覧通知で状態通知する（詳細は、図９）。
Ｓ２２０として、通知応答部２５は、Ｓ２０４で特定した送信対象の警報イベントを、履歴通知で状態通知する（詳細は、図１０）。

図９は、図８のＳ２１０（一覧通知処理）の詳細を示すフローチャートである。
Ｓ２１１として、通知応答部２５は、Ｓ２０３の（方法１ａ）または（方法１ｂ）で説明したように、現状態テーブル２３から今回送信対象の警報ＩＤ集合を取得する。
Ｓ２１２として、通知応答部２５は、今回送信対象の警報ＩＤを順に選択するループを開始する。
Ｓ２１３として、通知応答部２５は、履歴テーブル２４から、Ｓ２１２で選択した警報ＩＤを検索キーとして該当するレコードデータ（日時と機器と状態）を取得する。取得したデータは、後記するＳ２１５で使用される。
なお、変形例として、現状態テーブル２３にも警報ＩＤに対応付けてレコードデータ（日時と機器と状態）をあらかじめ記憶しておくことにより、履歴テーブル２４の代わりに現状態テーブル２３からＳ２１３の取得処理を実行できる。

Ｓ２１４として、通知応答部２５は、Ｓ２１２からのループを終了する。
Ｓ２１５として、通知応答部２５は、Ｓ２１３で取得した各レコードデータに加え、今回の状態通知が一覧通知であることを示す一覧通知フラグと、通知元制御データ２２の最新発生ＩＤとを含めた一覧通知データを作成し、その一覧通知データを通知要求部３１へと送信する。なお、（方法１ｂ）のときには、送信対象の全レコードの状態は常に「ＯＮ」であるため、その状態の送信を省略できる。

図１０は、図８のＳ２２０（履歴通知処理）の詳細を示すフローチャートである。Ｓ２２１〜Ｓ２２５の各処理は、基本的には、図９のＳ２１１〜Ｓ２１５の各処理に対応する。以下、図９と図１０の違いに着目して、説明する。
Ｓ２１１では、通知応答部２５は、現状態テーブル２３から今回送信対象の警報ＩＤ集合を取得していたが、Ｓ２２１では、Ｓ２０４の（方法２ａ）または（方法２ｂ）で説明したように、履歴テーブル２４から今回送信対象の警報ＩＤ集合を取得する。
Ｓ２２２〜Ｓ２２４のループ処理は、Ｓ２１２〜Ｓ２１４のループ処理と同様である。
Ｓ２２５では、Ｓ２１５と同様に、通知応答部２５は、Ｓ２２３で取得した各レコードデータに加え、今回の状態通知が履歴通知であることを示す履歴通知フラグと、通知元制御データ２２の最新発生ＩＤとを含めた履歴通知データを作成し、その履歴通知データを通知要求部３１へと送信する。

なお、状態通知の種類は、履歴通知と一覧通知との２種類なので、一覧通知フラグが状態通知に含まれていないときは、履歴通知であることが特定できる。よって、通知応答部２５は、Ｓ２２５の送信データから履歴通知フラグを省略してもよい。
また、送信対象の各レコードデータのうちの最新の警報ＩＤが最新発生ＩＤであるので、通知応答部２５は、Ｓ２２５の送信データから最新発生ＩＤを省略してもよい。

図１１は、通知要求部３１が実行する、通知要求処理およびその応答結果の表示処理を示すフローチャートである。
Ｓ３０１として、通知要求部３１は、通知先制御データ３２から最新通知ＩＤを取得する。
Ｓ３０２として、通知要求部３１は、Ｓ３０１の最新通知ＩＤを含む通知要求を、通知応答部２５に送信する。
Ｓ３０３として、通知要求部３１は、最新発生ＩＤを含む状態通知を通知応答部２５から受信するまで待つ。なお、通知応答部２５による状態通知の送信処理は、Ｓ２１０およびＳ２２０にて説明した。

Ｓ３１１として、通知要求部３１は、Ｓ３０３で受信した状態通知の通知フラグを参照して、処理を分岐させる。通知フラグが「一覧通知フラグ」ならＳ３１２へ進み、「履歴通知フラグ」ならＳ３２１へ進む。
Ｓ３１２として、通知要求部３１は、通知先テーブル３３の全レコードを消去する。この消去処理は、通知先テーブル３３の内容を、一覧通知された現状態テーブル２３の内容にそのまま置き換えるための前処理である。そして、処理をＳ３２１へと進める。

Ｓ３２１として、通知要求部３１は、状態通知された警報イベント集合の警報ＩＤを順に選択するループを開始する。
Ｓ３２２として、通知要求部３１は、Ｓ３２１で選択した警報ＩＤのレコードの状態によって処理を分岐させる。状態が「ＯＮ」ならＳ３２３へ進み、「ＯＦＦ」ならＳ３２４へ進む。

Ｓ３２３として、通知要求部３１は、通知先テーブル３３に対して、Ｓ３２１で選択した警報ＩＤのレコードを追加する。この追加処理として、通知要求部３１は、通知先テーブル３３内に選択した警報ＩＤが存在するときには、その既存レコード内の警報ＩＤ以外の各データを通知されたデータで書き換える。一方、通知要求部３１は、通知先テーブル３３内に選択した警報ＩＤが存在しないときには、通知先テーブル３３内に新規のレコードを作成する。

Ｓ３２４として、通知要求部３１は、通知先テーブル３３から、Ｓ３２１で選択した警報ＩＤのレコードの「ＯＮ」状態を削除する。この削除処理として、通知要求部３１は、通知先テーブル３３内に選択した警報ＩＤが存在するときには、その既存レコード内の警報ＩＤ以外の各データを通知されたデータで書き換えるか、既存レコードそのものを削除する。
Ｓ３２５として、通知要求部３１は、Ｓ３２１からのループを終了する。

Ｓ３３１として、通知要求部３１は、状態通知に含まれる最新発生ＩＤを、新たに最新通知ＩＤへと代入する。なお、状態通知に最新発生ＩＤが含まれていないときは、この代入処理を省略してもよい。
Ｓ３３２として、通知要求部３１は、警報表示部３４に対し、Ｓ３２１〜Ｓ３２５のループ処理で更新された通知先テーブル３３の内容で、図６に示した警報表示画面を更新するように、警報表示部３４に指示する。

以上説明した本実施形態では、各種管理システム（入退室管理、エネルギ管理、機器管理）において、設備機器１で発生する警報イベントを収集して過不足無く表示するために、警報イベントのデータ通信量を効率的に削減することを、主な特徴とする。
そのため、状態表示装置３は、通知先テーブル３３内に警報状態を持ち、警報表示部３４を介して警報一覧を表示する。通知先テーブル３３を更新するため、状態表示装置３は、機器管理装置２に対し、自身が持つ最新の警報を最新通知ＩＤで示し、その最新通知ＩＤより後に発生した警報の通知要求を行う。

機器管理装置２は、設備機器１の状態を監視し、新たに警報イベントが発生した際に、履歴テーブル２４に対して警報履歴を追加し、現状態テーブル２３に対して警報状態を更新する。
機器管理装置２は、通知要求で示された最新通知ＩＤから、履歴テーブル２４内の未通知分の履歴データ量と、現状態テーブル２３のデータ量とを計算し、両データ量を比較して少ないほうを今回の送信対象として通知要求に応答する。状態表示装置３は、応答された警報イベントの集合を通知先テーブル３３に反映する。

これにより、同じ警報の表示結果を得られる履歴通知と一覧通知とでデータ量が少ない方式を選択するので、警報イベントが連続的かつ大量に発生した場合でも、警報イベントの送信において、過不足なく、かつ、効率的なデータ送信が可能となる。

なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。
また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段などは、それらの一部または全部を、例えば集積回路で設計するなどによりハードウェアで実現してもよい。
また、前記の各構成、機能などは、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。

各機能を実現するプログラム、テーブル、ファイルなどの情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）などの記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤカード、ＤＶＤ（Digital Versatile Disc）などの記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１ 設備機器
２ 機器管理装置（警報通知装置）
３ 状態表示装置
２１ 登録部
２２ 通知元制御データ
２３ 現状態テーブル（現状態管理用データ）
２４ 履歴テーブル（履歴管理用データ）
２５ 通知応答部
３１ 通知要求部
３２ 通知先制御データ
３３ 通知先テーブル
３４ 警報表示部

Claims (5)

1. 設備機器で発生する警報イベントを、時系列の履歴データとして履歴管理用データに格納するとともに、前記設備機器ごとの最新の警報イベントを現状態管理用データに格納する登録部と、
   状態表示装置に対して既に通知された警報イベントを示す情報を含む通知要求を前記状態表示装置から受信し、前記履歴管理用データの履歴データから、前記通知要求の送信元である前記状態表示装置に対して未通知分の履歴データを特定し、前記未通知分の履歴データのデータ量と、前記現状態管理用データのデータ量とを比較し、
   前記履歴管理用データの未通知分の警報イベント集合、および、前記現状態管理用データの警報イベント集合のうちの前記比較結果として小さいデータ量である片方の警報イベント集合を、前記通知要求の送信元である前記状態表示装置に対して通知する通知応答部とを有することを特徴とする
   警報通知装置。
2. 前記通知応答部は、前記状態表示装置に対して通知する前記現状態管理用データの警報イベント集合として、表示対象の警報イベントを抽出した警報イベント集合とすることを特徴とする
   請求項１に記載の警報通知装置。
3. 前記通知応答部は、前記状態表示装置に対して通知する前記履歴管理用データの警報イベント集合として、前記未通知分の警報イベントのうちの前記設備機器ごとの最新の警報イベントを抽出した警報イベント集合とすることを特徴とする
   請求項１に記載の警報通知装置。
4. 請求項１ないし請求項３のいずれか１項に記載の警報通知装置と、前記状態表示装置とを含めて構成され、
   前記通知応答部は、前記未通知分の履歴データ内に表示対象の警報イベントが存在するときには、その存在する旨を含めて前記状態表示装置に対して通知し、
   存在する旨を通知された前記状態表示装置は、その旨を前記通知された警報イベント集合に併せて表示することを特徴とする
   警報通知システム。
5. コンピュータである警報通知装置に対して、
   設備機器で発生する警報イベントを、時系列の履歴データとして履歴管理用データに格納するとともに、前記設備機器ごとの最新の警報イベントを現状態管理用データに格納させ、
   状態表示装置に対して既に通知された警報イベントを示す情報を含む通知要求を前記状態表示装置から受信し、前記履歴管理用データの履歴データから、前記通知要求の送信元である前記状態表示装置に対して未通知分の履歴データを特定し、前記未通知分の履歴データのデータ量と、前記現状態管理用データのデータ量とを比較させ、
   前記履歴管理用データの未通知分の警報イベント集合、および、前記現状態管理用データの警報イベント集合のうちの前記比較結果として小さいデータ量である片方の警報イベント集合を、前記通知要求の送信元である前記状態表示装置に対して通知させるための
   警報通知プログラム。

Images