JP2021149386A

JP2021149386A - 監視システム

Info

Publication number: JP2021149386A
Application number: JP2020047399A
Authority: JP
Inventors: 康之荒木; Yasuyuki Araki; 大典本田; Daisuke Honda
Original assignee: Hitachi Building Systems Co Ltd
Current assignee: Hitachi Building Systems Co Ltd
Priority date: 2020-03-18
Filing date: 2020-03-18
Publication date: 2021-09-27

Abstract

【課題】顧客が不在でブレーカーが切断されていた場合の無駄な点検出動を抑制できる監視システムを提供する。【解決手段】建物の共用部に設置される共用部端末５１と、建物の専有部に設置される専有部端末５０１〜５０３と、共用部端末及び専有部端末に対してネットワークを介して接続された監視サーバーと、で構成された監視システムにおいて、監視サーバーは、共用部端末との接続が可能であり、かつ、専有部端末との接続が不可能であった場合、専有部を使用する顧客の外出スケジュールを参照し、専有部端末との接続が不可能であった日時が顧客の外出スケジュールの外出期間内であるとき、専有部端末が異常である旨の警告を出力しない。【選択図】図１

Description

本発明は、監視システムに関する。

近年、マンションなどの集合住宅において、空調機、給湯機、照明機器や各種家電製品は、建物外部からネットワークを介して管理が可能になってきている。これらのシステムは、建物の共用部や専有部に管理用の端末（共用部端末、専有部端末）を設置し、建物内外とネットワーク接続することで、設備機器の管理を実現している。また、端末自体もネットワークを介して監視センターにある監視サーバーと接続され、監視サーバーが定期的に共用部端末や専有部端末との接続通信を試行することにより、各端末の生存監視を実施することで、システムが健全に稼働しているかを確認している。

同様の技術として、例えば、特許文献１には、集合住宅インターホンの異常監視技術が開示されている。

特開2001-188979号公報

マンションの専有部に置かれる専有部端末は、監視サーバーからインターネットなどのネットワークを介して遠隔で生存監視しており、監視サーバーと専有部端末との間で通信ができない場合は、通信異常となり警報が監視サーバーより警報や点検指示が発生する。

一方、居住者が外出の際に専有部のブレーカーを遮断した場合、専有部端末の電源も当然電源遮断されており、通信異常として監視サーバーより警報や点検指示が発生する。しかしながら、監視サーバーより警報や点検指示を受けた監視員は、通信異常が端末異常によるものか電源遮断によるものかの判断がつかない。また、点検指示を受けた監視センターの監視員は、現地の確認が必要となるが、居住者不在の場合、確認対応もできない。

本発明の目的は、顧客が不在でブレーカーが切断されていた場合の無駄な点検出動を抑制できる監視システムを提供することにある。

上記目的を達成するために、本発明は、建物の共用部に設置される共用部端末と、前記建物の専有部に設置される専有部端末と、前記共用部端末および前記専有部端末に対してネットワークを介して接続された監視サーバーと、で構成された監視システムにおいて、前記監視サーバーは、前記共用部端末との接続が可能であり、かつ、前記専有部端末との接続が不可能であった場合、前記専有部を使用する顧客の外出スケジュールを参照し、前記専有部端末との接続が不可能であった日時が前記顧客の外出スケジュールの外出期間内であるとき、前記専有部端末が異常である旨の警告を出力しない。

本発明によれば、顧客が不在でブレーカーが切断されていた場合の無駄な点検出動を抑制できる監視システムを提供できる。

本発明の実施形態に係る監視システムの全体構成を示すブロック図である。本発明の実施形態における監視サーバーにおける端末テーブルの一例を示す図である。本発明の実施形態における監視サーバーによる端末異常確認動作を示すフローチャートである。本発明の実施形態における監視サーバーによる端末異常確認動作を示すタイミングチャートである。通知種別の優先度を示す表である。本発明の実施形態に係る監視システムでのやり取りを時系列的に示すシーケンス図である。

本発明の実施形態を図１〜図６を用いて説明する。

図１は、本実施形態における監視システムの全体構成を示すブロック図である。本実施形態に係る監視システムは、マンション５などの建物の共用部に設置される共用部端末５１と、建物の専有部に設置される専有部端末５０１〜５０３と、各端末の制御、各種情報の取集、各端末の動作確認などを行う監視サーバー１と、で構成されている。そして、共用部端末５１および専有部端末５０１〜５０３に対して、監視サーバー１がインターネット等のネットワーク２を介して接続されている。

監視センターに置かれた監視サーバー１は、接続確認部１１と、端末テーブル１２と、端末異常警報部１３と、通知部１４と、を備えている。なお、本実施形態では、監視サーバー１を含む監視センターを、便宜的に監視サーバーと呼ぶこととする。接続確認部１１は、ネットワーク２を介して共用部端末５１および専有部端末５０１〜５０３と接続確認を行い、確認の結果によって、当該端末が正常動作か異常動作（接続通信失敗）かを判別するものである。端末テーブル１２は、各マンションに設置された共用部端末および専有部端末の状態を記録するものである。接続確認部１１は、この端末テーブル１２を参照して動作を行う。端末異常警報部１３は、各端末との接続通信ができなかった場合に、当該端末が異常動作であるとして警報を出力するものである。通知部１４は、異常動作している端末に対して、動作確認のために出動するなどの具体的な作業を指示するものである。また、監視サーバー１は、マンション５の入居者である顧客が使用する顧客端末４に、マンション５の設備の状態や計測値、お知らせなどを提供するためのＷｅｂサーバー１５も備えている。さらに、監視サーバー１は、顧客端末４に対して、メールにより各種情報の提供を行うメールサーバー１６も備えている。

マンション５（マンションＡＢＣ）は、共用部端末５１および専有部端末５０１〜５０３を備えている。共用部端末５１は、マンション５のエントランスの図示しない自動ドアのセキュリティ機能やエレベータの制御、インターホン５２の制御、宅配ロッカー５３への荷物の配達状況などを検知して記録する機能などを有している。専有部端末５０１〜５０３は、各居室（１０１号〜１０３号）に設置され、各居室の図示しない電気錠の制御や電力や水道、ガスなどの使用量を計測する機能を有している。

ここで、共用部端末５１は、マンション５の共用部の電源に接続されているため、マンション５全体が停電しない限り電源供給を絶たれることは無い。しかし、専有部端末５０１〜５０３は、各居室のブレーカー５０１ｂ〜５０３ｂを介して電源が供給されているため、顧客が長期に渡って不在とするなど、自室のブレーカーを切断して不在とする場合がある。例えば１０１号室の顧客がブレーカーを切断して不在とした場合、監視サーバー１は専有部端末５０１と接続通信ができなくなるため、端末異常警報部１３がこれを検知し、通知部１４から点検指示が出される。

従来の方法では、マンション５の専有部端末５０１が通信や機器異常により接続通信ができないのか、ブレーカー５０１ｂが切断されたため専有部端末５０１への電源供給が絶たれて接続通信ができないのか、を判別することができず、また顧客が不在であるため居室に立ち入って確認を行うことができず、無駄な点検出動となる場合があった。そこで、本実施形態では、共用部端末５１との接続が可能であり、かつ、専有部端末５０１との接続が不可能であった場合、監視サーバー１は、専有部端末５０１を使用する顧客の外出スケジュールを参照し、専有部端末５０１との接続が不可能であった日時が顧客の外出スケジュールの外出期間内であるとき、顧客が不在のためブレーカー５０１ｂが切断されたと見做す。したがって、この場合、監視サーバー１は、専有部端末５０１が異常である旨の警告は出力しないため、無駄な点検出動をすることが抑制される。

図２は、監視サーバー１における端末テーブル１２の一例を示す図である。端末テーブル１２には、各マンションに設置されている共用部端末と各専有部端末に対応するデータか記録されている。そして、各端末に対して、端末ＩＤ、端末タイプ、点検周期、顧客の不在開始日時、顧客の在宅開始日時、各端末の接続異常回数、が記録されている。

まず、（１）通常時、監視サーバー１は、基本的に１日１回動作確認のため各端末と接続通信を行っており、接続通信が可能であった場合は、接続異常回数に０が記録される。

（２）不在登録時、２０１９／１２／２８２０：００から２０２０／１／５１２：００まで顧客が居室に不在であるという情報が、端末テーブル１２に記録される。

ここで、接続確認部１１は、顧客が使用しているスケジューラーであるジョルテ（登録商標）やOutlook（登録商標）などの外部のスケジュール管理サーバー３を定期的に参照して、顧客の不在状況の有無を確認している。ただし、スケジュール管理サーバー３から外出スケジュールを受信する場合、監視サーバー１は、顧客端末４へ確認のための情報を送信し、顧客から許可を得ることが望ましい。なお、顧客の不在状況の取得方法は、この方法に限らず、顧客自身が顧客端末４を操作してＷｅｂサーバー１５に接続して不在登録を行っても良いし、所定の書式でメールサーバー１６に不在登録の電子メールを送信し不在登録を行っても良い。

スケジュール管理サーバー３に顧客の不在状況（例えば家族全員が不在の期間）があった場合、監視サーバー１は、これを参照して、不在期間の情報として、顧客の不在開始日時、顧客の在宅開始日時を、端末テーブル１２に書き込む。

（３）不在期間中、１０１号居室のブレーカーが切断されていた場合、監視サーバー１は専有部端末５０１と接続通信ができないため、端末テーブル１２における専有部端末５０１の接続異常回数が増加する。しかし、顧客の不在期間においては、接続通信異常がブレーカー５０１ｂの切断による電源断か、専有部端末５０１自体の異常なのかを判別することはできないため、接続異常回数のみ増加させ警報や出動指示は行わない。

（４）不在期間終了後、接続確認部１１は、通常の接続通信確認周期（１日）より短い間隔（例えば１分〜１０分）で、専有部端末５０１への接続通信を試行する。接続通信を試行したものの接続異常となった場合、その接続異常が所定回数に達するか、成功できずに所定時間が経過すると、通知部１４は、接続異常の警告を出力する。

（５）不在期間終了かつブレーカー復旧時、専有部端末５０１への接続通信は成功し、監視サーバー１は、顧客がブレーカー５０１ｂを復旧したため居室に居ると判断する。このとき、監視サーバー１は、共用部端末５１に顧客へ送るべき情報があるかを確認し、情報がある場合には顧客端末４へメールで送信する。顧客端末４へ送信される情報は、監視サーバー１に予め登録された優先度設定又は要否設定に基づいて、選定される。また、これらの設定は、顧客端末４によって各顧客の要望に応じて登録内容が変更できるようになっている。なお、端末テーブル１２に記録される情報は、通常時に戻る。

次に、図３のフローチャートを用いて、監視サーバー１による端末異常確認動作を説明する。本フローチャートによる動作は、基本的に１日に１回、所定の時刻に実施される。

まず、接続確認部１１は、端末テーブル１２を参照して、マンション毎の端末情報を取得する（ステップＳ１）。

次に、接続確認部１１は、マンション毎の端末情報より共用部端末を選択し（ステップＳ２）、選択した共用部端末に対して接続通信を試行する。

接続通信が可能であった場合、接続確認部１１は、マンション毎の端末情報より専有部端末を選択し、接続通信を試行する（ステップＳ３〜Ｓ５）。

ここで、選択した専有部端末との接続通信が可能であった場合は、接続確認部１１は、次の専有部端末を選択する（ステップＳ６）。

選択した専有部端末が当該マンションにおける最後の専有部端末であった場合（ステップＳ７）、接続確認部１１は、次のマンションを選択し、同様に共用部端末と専有部端末との接続通信を試行する（ステップＳ８）。

すべてのマンションの共用部端末と専有部端末への接続通信試行が完了した場合、監視サーバー１の端末異常確認動作を終了する（ステップＳ９）。

一方、ステップＳ３において、共用部端末への接続通信が異常であった場合、共用部端末自体の異常や故障、共用部端末とネットワーク２との接続異常などが考えられるため、端末異常警報部１３は、共用部端末異常を警告し、通知部１４より当該マンションへの点検出動指示を行う（ステップＳ１２）。

また、接続確認部１１が選択した専有部端末に対する接続通信が異常であった場合、当該専有部端末に対応する顧客の不在開始日時、顧客の在宅開始日時を参照する（ステップＳ１０）。

ここで、現在の日時が顧客の不在期間内であった場合、顧客のブレーカー切断による専有部端末への電源断も異常の原因として考えられるため、接続確認部１１は、端末異常回数のみ増加させ、警告は行わない（ステップＳ１１）。

一方、接続確認部１１が選択した専有部端末に対する接続通信が異常であり、現在日時が顧客の在宅開始日時以降である場合は、顧客によるブレーカー復旧により専有部端末の機能が復旧することが予想されるため、接続確認部１１は、再度専有部端末に対する接続通信を試行する（ステップＳ１３）。

ここで、接続通信が異常であった場合、接続確認部１１は、通常の端末接続確認の間隔（例えば１日）よりも短い間隔（例えば１分〜１０分）で専有部端末への接続通信を試行する（ステップＳ１５）。

接続通信を試行したものの接続異常となった場合、その接続異常をカウントし（ステップＳ１６）、カウントした接続異常回数が所定回数に達したか否かを判定する（ステップＳ１７）。

所定回数試行しても専有部端末への接続が復旧しない場合、専有部端末の機器故障も原因として考えられるため、通知部１４は、専有部端末の接続異常を警告し点検指示を行う（ステップＳ１９）。

一方、接続異常回数が所定回数に達していない場合、ステップＳ１３に戻って、接続確認部１１が再び接続通信を試行する（ステップＳ１８）。

ステップＳ１３〜ステップＳ１８を繰り返し、専有部端末への接続通信が可能となった場合、接続確認部１１は、点検周期を1日に再設定する（ステップＳ１４）。

図４は、監視サーバー１による端末異常確認動作のタイミングチャートである。図４に示すように、顧客の外出スケジュールの外出期間が経過した後は、通常の点検周期よりも短い間隔で専有部端末との接続試行を繰り返す。

次に、監視サーバー１は、ブレーカーを復旧した顧客は宅内に在室であるとみなし、共用部端末に顧客向けの通知情報があるかを問合せする（ステップＳ２０）。

顧客向けの通知情報があった場合は、図５に示す通知種別の優先度に従って、メールサーバー１６は、顧客端末４に通知情報をメールで配信する（ステップＳ２１）。ここで、通知情報としては、来訪者画像通知、来訪者履歴表示通知、宅配着荷通知、専有部警報通知等がある。

なお、ステップＳ２１にて参照する通知種別の優先度は、環境や時間帯別に複数の優先度を持っても良く、また顧客が設定した優先度を持っていても良い。例えば、宅配が届くと予想される時間帯は、宅配着荷通知の優先度を高く設定するなどが考えられる。顧客が設定した優先度が存在する場合は、顧客が設定した優先度をシステム側が持つ優先度より優先して参照しても良い。

以上の動作のうち、ステップＳ１３以降の動作は、別プロセスとし、通常の端末異常確認動作のプロセス（ステップＳ１〜Ｓ９）とは別個に実施してもよい。この場合、ステップ１３以降の動作以上の端末異常確認動作のプロセスには戻らず、別プロセスを終了させる動作とする。ステップＳ１３以降の端末異常確認動作のプロセスは、長い待ち時間が発生する可能性があるためである。

本実施例によれば、顧客が不在でブレーカーが切断されていた場合に、無駄な点検出動することを防ぐことができる。また、顧客にとっても、自らが日常で使用しているスケジューラーに不在を登録しておくだけで済むので、監視サーバーへ登録する手間がなくなる。

図６は、専有部端末、共用部端末、監視サーバー、スケジュール管理サーバーおよび顧客端末の間でのやり取りを時系列的に示すシーケンス図である。図６に示すように、顧客が顧客端末によりスケジュール登録すると、スケジュール管理サーバーがスケジュール表の更新を行う。監視サーバーが、スケジュール管理サーバーに顧客スケジュール情報要求をすると（ステップＳ１０３）、スケジュール管理サーバーが、顧客スケジュール情報を監視サーバーへ送信する（ステップＳ１０４）。なお、監視サーバーは、専有部端末との接続異常があったときにはじめて、スケジュール管理サーバーへ顧客スケジュール情報要求を出すようにしても良い。

本実施形態では、専有部端末との接続が不可能であった日時が顧客の外出スケジュールの外出期間内であった場合、警告を出力しないものであるが、顧客によっては、そのような場合であっても、警告を出して欲しい可能性がある。このため、外出期間内であっても接続異常があれば警告を出力するような設定を、顧客端末が選択できるようにするのが望ましい。

１監視サーバー
１１接続確認部
１２端末テーブル
１３端末異常警報部
１４通知部
１５Ｗｅｂサーバー
１６メールサーバー
２ネットワーク
３スケジュール管理サーバー
４顧客端末
５マンション
５１共用部端末
５２インターホン
５３宅配ロッカー
５０１〜５０３専有部端末
５０１ｂ〜５０３ｂブレーカー

Claims

建物の共用部に設置される共用部端末と、前記建物の専有部に設置される専有部端末と、
前記共用部端末および前記専有部端末に対してネットワークを介して接続された監視サーバーと、で構成された監視システムにおいて、
前記監視サーバーは、
前記共用部端末との接続が可能であり、かつ、前記専有部端末との接続が不可能であった場合、前記専有部を使用する顧客の外出スケジュールを参照し、
前記専有部端末との接続が不可能であった日時が前記顧客の外出スケジュールの外出期間内であるとき、前記専有部端末が異常である旨の警告を出力しないことを特徴とする監視システム。
前記顧客の外出スケジュールは、前記監視システムとは別のスケジュール管理サーバーから前記監視サーバーが受信したものであることを特徴とする請求項１記載の監視システム。
前記監視サーバーが前記スケジュール管理サーバーから前記顧客の外出スケジュールを受信する場合、前記監視サーバーは、顧客端末へ確認のための情報を送信することを特徴とする請求項２記載の監視システム。
前記監視サーバーは、前記専有部端末との接続が不可能であった場合、前記顧客の外出スケジュールの外出期間が経過した後に、通常の点検周期よりも短い間隔で前記専有部端末との接続試行を繰り返すことを特徴とする請求項１記載の監視システム。
前記監視サーバーは、前記顧客の外出スケジュールの外出期間が経過し、かつ、前記専有部端末との接続が可能となったとき、所定情報を顧客端末へ送信することを特徴とする請求項１記載の監視システム。
前記所定情報は、前記監視サーバーに予め登録された優先度設定又は要否設定に基づいて、前記顧客端末へ送信されることを特徴とする請求項５記載の監視システム。
前記優先度設定又は要否設定は、前記顧客端末によって前記顧客ごとに登録されることを特徴とする請求項６記載の監視システム。
前記専有部端末との接続が不可能であった日時が前記顧客の外出スケジュールの外出期間内であっても、前記監視サーバーが前記警告を出力するような設定を、顧客端末が選択できることを特徴とする請求項１記載の監視システム。