JP2022117261A - ＩｏＴシステム、及び、管理サーバ - Google Patents

Abstract

【課題】センサが無線通信経由で管理サーバと接続された場合などにおいて、メンテナンスの作業を軽減させたＩｏＴシステム及び管理サーバを提供する。【解決手段】ＩｏＴシステムは、複数のノード端末と、管理サーバとを備える。各ノード端末は、無線通信モジュールとセンサを備え、無線通信モジュールを通して、センサ情報を管理サーバに送信する。管理サーバは、センサ情報を受信し、センサ情報に基づいて、通知の必要の有無を判断し、通知の必要がある場合には、チャットルームに投稿する。【選択図】図１

Description

本発明は、ＩｏＴシステム、及び、管理サーバに関する。より具体的には、センサを活用したＩｏＴシステム、及び、管理サーバに関する。

近年、あらゆる物をインターネットに接続する構想（ＩｏＴ、Ｉｎｔｅｒｎｅｔ Ｏｆ Ｔｈｉｎｇｓ）が提唱されている。こうした分野における応用の一形態において、所定の場所に各種センサを設置して、環境を監視する仕組みがある。

特許文献１では、環境センサがトリガー情報を出力して、前記ボットが、トークルームを作成するか否かに関する判定を、前記トリガー情報に基づいて行うことを開示している。

特許第６５８５３１９号公報

センサを導入したシステムにおいては、導入時の手間が問題となることがしばしばある。例えば、センサを取り付けたとしても、その情報を送るために配線を検討する必要がある。しかし、多数のセンサを広大なエリアに配置する場合には、配線を用意する手間も膨大なものとなる。

本発明は以上の点に鑑み、センサが管理サーバと接続された場合などにおいて、作業を軽減させたＩｏＴシステムを提供することを目的とする。

上記目的を達成するための本発明は、一側面において、以下の発明を包含する。
（発明１）
ＩｏＴシステムであって、
前記システムは、ノード端末と、管理サーバとを備え、
前記ノード端末は無線通信モジュールとセンサを備え、
前記ノード端末は、前記無線通信モジュールを通して、センサ情報を前記管理サーバに送信するように構成され、
前記管理サーバは、前記センサ情報を受信するように構成され、
前記管理サーバは、前記センサ情報に基づいて、通知の必要の有無を判断するように構成され、
前記管理サーバは、通知の必要がある場合には、チャットルームに投稿するように構成される、
システム。
（発明２）
発明１のＩｏＴシステムであって、
前記管理サーバは、複数の前記センサ情報に基づいて、通知の必要の有無を判断するように構成される、
システム。
（発明３）
発明１又は２のＩｏＴシステムであって、
前記管理サーバは、前記センサ情報が所定の閾値範囲外か否かを判定するように構成される、
システム。
（発明４）
発明３のＩｏＴシステムであって、
前記管理サーバは、前記センサ情報を記録するためのデータベースを備え、
前記データベースは、前記センサ情報が所定の閾値範囲外となった場合に動作するデータベーストリガーを備える、
システム。
（発明５）
発明１～４いずれか１つに記載のＩｏＴシステムであって、
前記管理サーバは、複数のチャットルームに投稿可能であり、
前記管理サーバは、前記センサ情報に基づいて、通知の重要度を判断するように構成され、
前記管理サーバは、前記通知の重要度に基づいてチャットルームを選択するように構成される、
システム。
（発明６）
発明１～４いずれか１つに記載のＩｏＴシステムであって、
前記管理サーバは、複数のチャットルームに投稿可能であり、
前記管理サーバは、前記センサの設置場所に基づいてチャットルームを選択するように構成される、
システム。
（発明７）
発明１～４いずれか１つに記載のＩｏＴシステムであって、
前記管理サーバは、複数のチャットルームに投稿可能であり、
前記管理サーバは、前記センサの種類に基づいてチャットルームを選択するように構成される、
システム。
（発明８）
発明１～７いずれか１つに記載のＩｏＴシステムであって、
前記管理サーバは、ユーザがチャットルームに投稿したメッセージを取得するように構成され、
前記管理サーバは、前記投稿されたメッセージに基づいて、前記センサ情報の表示の必要の有無を判断するように構成され、
前記管理サーバは、表示の必要がある場合には、前記チャットルームに前記センサ情報を含むメッセージを投稿するように構成される、
システム。
（発明９）
ＩｏＴシステムに組み込まれる管理サーバであって、
前記管理サーバは、ノード端末に通信可能に接続され、前記ノード端末からセンサ情報を受信するように構成され、
前記管理サーバは、前記センサ情報に基づいて、通知の必要の有無を判断するように構成され、
前記管理サーバは、通知の必要がある場合には、チャットルームに投稿するように構成される、
管理サーバ。

一側面において、本発明のノード端末は無線通信モジュールとセンサを備える。これにより、通信ケーブルなどが不要となり、導入の手間を軽減できる。

一実施形態における本発明のシステムの構成を示す。 一実施形態における本発明のノード端末の構成を示す。 一実施形態における本発明の管理サーバの構成を示す。 一実施形態における本発明の異常判定モジュールがセンサデータを取得する方法を示す。 一実施形態における本発明の異常判定モジュールがセンサデータを取得する方法を示す。 一実施形態における本発明の異常判定モジュールがセンサデータを取得する方法を示す。 一実施形態における本発明の異常判定モジュールが重要度を判定するために使用する判定表を示す。 一実施形態における本発明の異常判定モジュールがどのメッセージを投稿するかを判定するために使用する判定表を示す。 一実施形態における本発明の異常判定モジュールがどのチャットルームに投稿するか判定するために使用する判定表を示す。 一実施形態における本発明の異常判定モジュールがどのチャットルームに投稿するか判定するために使用する判定表を示す。 一実施形態における本発明の異常判定モジュールがどのチャットルームに投稿するか判定するために使用する判定表を示す。 一実施形態における本発明の異常判定モジュールがどのチャットルームに投稿するか判定するために使用する判定表を示す。 一実施形態における本発明の異常判定モジュールがどのチャットルームに投稿するか判定するために使用する判定表を示す。 一実施形態における本発明のモニタリング端末の構成を示す。 一実施形態における本発明の監視方法のフローを示す。

以下、本発明を実施するための具体的な実施形態について説明する。以下の説明は、本発明の理解を促進するためのものである。即ち、本発明の範囲を限定することを意図するものではない。

１．応用分野
一実施形態において、本発明のＩｏＴシステムは、様々な産業分野で使用することができる。例を挙げると、工場敷地内での異常検知、オフィスビル等の建物管理での異常検知、病院建物内での異常検知、ショッピングモールでの異常検知、フードコートでの異常検知、小売店での異常検知、データセンターでの異常検知などが挙げられる。以下では、管理ビル内での異常検知を例にして、本発明の具体例を説明する。

２．システム全体の構成（図１）
一実施形態において、本発明は、異常発生の通知を行うシステムに関する。前記システムの具体例を図１に示す。前記システムは、ノード端末（１１００）と、管理サーバ（１２００）と、モニタリング端末（１４００）とを備える。これらの構成要素は、相互にネットワークで接続される。ネットワークは、無線接続であってもよく、有線接続であってもよく、これらの組み合わせであってもよい。また、管理サーバ（１２００）とノード端末（１１００）との間には、ゲートウェイ（１３００）などを設けてもよい。システム内において、ノード端末（１１００）は、複数設けてもよい。

管理サーバ（１２００）は、特定の形態に限定されず、クラウド形態であってもよく、オンプレミス形態であってもよい。また、オンプレミスの管理サーバ（１２００）は、当分野で公知の情報処理装置（典型的には、プロセッサ、メモリ、記憶媒体、通信モジュール（例えばネットワークアダプタ等）を備える物）を用いて構成されてもよい。また、管理サーバ（１２００）は、所望のプログラムがインストールされており、当該プログラムがプロセッサに命じることにより所定のモジュール、データベース等が実装され、所定の動作を実行することができる。管理サーバ（１２００）にて実装されるモジュール、データベース等については、後述する。

なお、システムを構成する要素として含まれる必要はないが、システムは、チャットを管理するためクラウドサーバと接続されてもよい。例えば、システムの管理サーバ（１２００）が、チャットを管理するためクラウドサーバと接続されてもよい。これにより、管理サーバ（１２００）は、チャットルームへの投稿を行うことができる。

３．ノード端末（図２）
図２は、各ノード端末における構成を示す。ノード端末は、少なくともセンサ（２１００）及び無線通信モジュール（２２００）を備える。また、図２には、示さないが、バッテリ等を更に備えてもよい。ノード端末は、典型的には、導入時の手間、及び、メンテナンスの手間の観点から、ケーブルレスに設けられる。即ち、電源配線や、ネットワーク配線が無くても動作するように構成される。こうした目的で、無線通信モジュール、バッテリ等が搭載される。

図２では、センサは、１つしか示していないが、１つのノード端末に、センサが複数備えられてもよい。センサの種類は、特に限定されないが、例えば、以下の例が挙げられる：人感センサ（例えば、ヒトの立ち入りを検出）、超音波センサ（例えば、対象物までの距離間異常を検出）、音センサ（例えば、感音、マイク等。異常音などにより異常を検知）、圧力センサ（例えば、容器等密閉空間内の圧力の異常な上昇などを検知）、電流及び／又は電圧センサ（例えば、装置の稼働状況を監視）、エンコーダ（例えば、ロータリエンコーダ、リニアエンコーダ、例えば、ロボットアームの関節部の角度異常の検出）、水分量センサ、ガスセンサ（例えば、Ｏ₂／ＣＯ₂センサ、臭気等）、光センサ（赤外線センサ、照度センサ等も含む。例えば、熱、温度に関する異常を検出、暗室など光厳禁のエリアでの光漏れを検出、或いは、カメラなどでの異常物体の存在の認識）、湿度センサ、温度センサ、気圧センサ、ジャイロセンサ（例えば、建物や地面の傾きなどを検知）、磁気センサ、加速度センサ（例えば、地震や振動などの検知）等。

無線通信モジュール（２２００）は、図１に示すようなゲートウェイ（１３００）との無線通信接続に寄与することができる。無線通信規格は、特に限定されず、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉｆｉ（登録商標）、ＬＰＷＡなど、当分野で公知の通信規格を利用することができる。好ましい通信規格はＬＰＷＡである。この理由として、ノード端末は、屋外に設置される場合に、電力を大量に消費するとバッテリ交換などのメンテナンスが発生したり、或いは設置時に電源ケーブルを引くなどの手間が生じたりしてしまう。しかし、ＬＰＷＡの場合には、低消費電力という特性があるため、こうした手間が生じることを回避できる。更には、ＬＰＷＡは到達距離が長いため、屋外のような非限定的な空間に設置する場合に適している。

ＬＰＷＡは、当分野で公知の規格を含むことができ、例えば、「ＬｏＲａ」「ＳＩＧＦＯＸ」「ＮＢ－ＩｏＴ」等が挙げられる。特に好ましいのは、「ＬｏＲａ」である。この理由として、無料で使用可能であること、消費電流が小さいこと、自営網が自由に作れることなどが挙げられる。

無線通信モジュール（２２００）は、上述したセンサが検知した情報を、ゲートウェイ（１３００）を通して、管理サーバ（１２００）に送信することができる。無線通信モジュール（２２００）が送信する情報として、例えば、以下の情報を含まれてもよい：ノード端末の識別情報、センサの識別情報、タイムスタンプ、センサが検知した測定値（例えば、湿度センサが検知した湿度の数値情報、温度センサが検知した温度の数値情報、その他のセンサが検知した数値情報）、ノード端末の動作ログ、ノードの死活監視情報等。

４．ゲートウェイ
ゲートウェイ（１３００）は、ノード端末（１１００）と管理サーバ（１２００）との間の情報の送受信を仲介するのに寄与することができる。典型的には、ノード端末（１１００）との間では無線通信で接続され、管理サーバ（１２００）との間では有線通信で接続されてもよい。これに対応して、ゲートウェイ（１３００）は、無線通信モジュール、有線通信モジュールを備えることができる。ゲートウェイ（１３００）については、特に限定されず、当分野で公知の装置を使用することができる。

５．管理サーバ
管理サーバ（１２００）は、図３に示すように、異常判定モジュール（３１００）と、第２の通信モジュール（３２００）と、チャットモジュール（３３００）とを備える。第２の通信モジュール（３２００）は、システム内の他の構成要素（例えば、ゲートウェイ（１３００）、モニタリング端末（１４００）等）と、データの送受信を行うように構成される。より具体的には、第２の通信モジュール（３２００）は、ノード端末から送信される情報等を受信するように構成される。また、第２の通信モジュール（３２００）は、システム外に存在する外部のチャット管理サービスに接続する機能を有する。

５－１．異常判定モジュール
異常判定モジュール（３１００）は、センサが検知した測定値に基づいて、ユーザに通知する必要性があるかどうかの判断を行うように構成される。更には、通知の必要がある場合には、異常判定モジュール（３１００）は、チャットモジュール（３３００）に、通知情報を出力するように構成される。

５－１－１．判定方法１（上限及び／又は下限との比較）
判定方法については、特に限定されず、例えば、センサ情報が所定の閾値範囲外か否かを判定することによってもよい。例えば、センサが検知した測定値に関する許容値の上限及び／又は下限を設定しておき、これらの値と、センサの測定値とを比較することで、判定を行ってもよい。或いは、別の例として、直近の複数日数間の平均測定値などを算出し、当該平均測定値から、一定以上乖離した測定値が検出されたかどうかを判定してもよい。或いは、更に別の例として、所定時間内の変化率を算出し、当該算出率が一定以上となったかどうかを判定してもよい。

５－１－２．判定方法２（３段階以上の判定結果）
好ましくは、異常判定モジュール（３１００）は、測定センサの測定値のデータに応じて、異なる警告情報を生成してもよい。例えば、異常判定モジュール（３１００）は、単に正常・異常といった２段階の判定ではなく、３段階以上の重要度の判定を行うように構成されてもよい。例えば、異常判定モジュール（３１００）が、正常、注意、警告、緊急などといったように、３段階以上での重要度の判定を行うことで、通知を受けた側が適正な対処を行うことができる。こうした段階を設定していないと、通知を受けた時点で、常に最悪の事態を想定（例えば緊急の状態を想定）しながら対処を行わなければならない。しかし、段階を設定しておけば、担当者レベルで動けばよいのか、それとも上長への報告が必要かなど、段階に応じたアクションを可能にすることができる。こうした判定方法についても、特定の方法に限定されず、任意の方法で判定してもよい。例えば、測定値の変化率（緩やかな変化なのか、急激な変化なのか）を判定することで、経年劣化が原因なのか、急激な事故なのかを判定することができる。そして、前者の場合には、重要度の低い判定（例えば、注意）を出力し、後者の場合には、重要度の高い判定（例えば、緊急）の判定を出力するようにしてもよい。

５－１－３．判定方法３（１台のノード端末に複数のセンサ）
別の好ましい形態においては、異常判定モジュール（３１００）は、１台のノード端末（１１００）の複数のセンサの測定値のデータに応じて、通知の必要の有無の判定を行ってもよい。例えば、筐体に取り付けた１台のノード端末が、筐体内の圧力と筐体内の温度を測定するセンサを備えている場合、筐体の耐久限度は、温度と圧力の組み合わせによって決まる可能性がある。温度が高いと筐体自体が軟化して、圧力が低くても破損する可能性があるし、一方で、温度が低くても、圧力が極端に高ければ破損する可能性がある。従って、異常判定モジュール（３１００）は、温度センサと、圧力センサの２つの測定値に基づいて、通知の必要の有無の判定を行う。判定するための具体的なアルゴリズム等は特に限定されず、当分野で公知の手法を採用すればよい。例えば、パラメータが２つの場合には、多次元のマトリックス表などを利用してもよい。

５－１－４．判定方法４（複数のノード端末）
別の好ましい形態においては、異常判定モジュール（３１００）は、複数のノード端末（１１００）からのセンサの測定値のデータに応じて、通知の必要の有無の判定を行ってもよい。例えば、１か所のノード端末（１１００）だけの測定値の異常があった場合と、同じエリアの複数個所のノード端末（１１００）で同時に測定値の異常があった場合とでは、深刻度合いが異なる可能性がある。複数のノード端末（１１００）からの情報を考慮した判定方法についても、具体的な方法に限定されず、任意の方法で判定してもよい。例えば、各ノード端末（１１００）での測定値の異常度合いに加えて、同じ時間帯に異常を示した、各ノード端末間の距離に応じて、係数を乗じるようにしてもよい。このようにすれば、２か所で測定値の異常が同じ時間帯に生じたとしても、距離の大小に応じて違った判定を行うことができる。

変形例として、複数のセンサが、同じ時間帯に（例えば、１分以内、１０分以内等）に送信した情報の組み合わせに基づいて、異常判定モジュール（３１００）は、異なる警告情報を生成することができる。具体例としては、同じ場所にガスセンサに基づく第１のセンサと人感センサに基づく第２のセンサを備えるケースが挙げられる。この場合、ガス漏れを第１のセンサが検知して、無線通信モジュール（２２００）によって、管理サーバ（１２００）に送信される。管理サーバ（１２００）の異常判定モジュール（３１００）は、これに基づいて、警告情報を生成する。ただし、ガス漏れを第１のセンサが検知し、尚且つ、同じ時間帯に、人が近くにいることを第２のセンサが検知した場合、管理サーバ（１２００）の異常判定モジュール（３１００）は、これに基づいて、更に高いレベルの警告を示すデータを送信することができる。

これにより、ガス漏れを検知しても周辺に人がいない場合と、ガス漏れを検知して尚且つ周辺に人がいる場合とで、異なるレベルの警告情報を、異常判定モジュール（３１００）が生成することが可能となる。そして、異なるレベルの警告情報に基づいて、担当者が、適切な対応を取ることが可能となる。

また、必須ではないものの、典型的には、ガス漏れを第１のセンサが検知しておらず、尚且つ、同じ時間帯に、人が近くにいることを第２のセンサが検知した場合については、異常判定モジュール（３１００）は、警告情報を生成しないという判断を行うこともできる。

５－１－５．チャットルームへの投稿
また、異常判定モジュール（３１００）が生成した警告情報の少なくとも一部は、チャットルームへの投稿に活用されてもよい。チャットルームが複数存在する場合には、異常判定モジュール（３１００）は、チャットルームの識別情報を、別途送信するように構成されてもよい。これにより、チャットモジュール（３３００）が、警告情報の少なくとも一部を、適切なチャットルームに投稿することができる。

上述した管理サーバ（１２００）側の異常判定モジュール（３１００）による判定の機構は、ノード端末（１１００）側に、異常判定モジュール（３１００）を組み込むことで実現してもよい。しかし、上述の様に消費電力の観点から、異常判定モジュール（３１００）による判定は、管理サーバ（１２００）側で行うことが好ましい。また、ノード端末（１１００）側の通信回線速度が限られている場合には、異常を知らせる情報を送信する分、通信に負荷がかかる。この点、ノード端末（１１００）と比べて、管理サーバ（１２００）側ではこうした通信回線速度の制限や消費電力の制限が生じる蓋然性が低い。このような理由からも、異常判定モジュール（３１００）による判定は、管理サーバ（１２００）側で行うことが好ましい。

管理サーバ（１２００）は、更に分析モジュール（図には示さず）を備えることができる。分析モジュールは、各所のノード端末（１１００）の各種のセンサからの情報を収集し、集計することができる。例えば、時系列でデータを記憶したり、或いは、グラフ等の形式でデータを出力したりすることができる。こうした出力データは、第２の通信モジュール（３２００）を通して、尚且つ、チャットモジュール（３３００）を通して、モニタリング端末（１４００）に送信されてもよい。

５－１－６．異常判定モジュールによるセンサの測定値のデータの取得
異常判定モジュール（３１００）が、センサの測定値のデータを取得する具体的な方法については、特に限定されない。例えば、図４に示すように、第２の通信モジュール（３２００）が、異常判定モジュール（３１００）と、ログデータベースの両方にセンサデータを送信してもよい。ログデータベースは、センサデータを記憶することができる。異常判定モジュール（３１００）は、第２の通信モジュール（３２００）からセンサデータを取得するたびに、上述した仕組みで通知の必要の有無を判断することができる。そして、通知の必要がある場合には、異常判定モジュール（３１００）は、チャットモジュール（３３００）へ、必要な情報及び指示を送信することができる。

別の方法としては、図５に示すように、第２の通信モジュール（３２００）が、ログデータベースにセンサのデータを送信し、その後で、異常判定モジュール（３１００）が定期的にログデータベースにアクセスして、センサデータを取得し、上述した仕組みで通知の必要の有無を判断してもよい。この方法の場合、センサの測定値のデータを取得するたびに、異常判定モジュール（３１００）が判断処理を行う必要が無く、判定処理の頻度が少なくなり、処理負荷を軽減することができる。また、ログデータベースにアクセスして複数のセンサのデータを一度に取得できるので、複数のセンサのデータに基づいた判断を行ううえで都合が良い。

更に別の方法としては、図６に示すように、第２の通信モジュール（３２００）が、ログデータベースにセンサデータを送信し、ログデータベースには、一定のデータベーストリガーを実装してもよい。データベーストリガーは、テーブル等への挿入、更新、及び、削除等のいずれかのイベントが発生したときに、所定の処理を実行させる仕組みである。例えば、センサのデータがログデータベースの所定のテーブルに挿入されたときに、測定値の値について、異常の有無を判定するように、データベーストリガーを実装してもよい。そして、異常有りの場合には、異常判定モジュール（３１００）に、異常有りを知らせる情報を送信してもよい。その際には、センサのデータを共に送信してもよい。或いは、これに代えて、異常有りと判断した記録を管理するテーブルに、データを記録してもよい。

これにより、異常判定モジュール（３１００）は、膨大なデータを保持するログデータベースへのアクセスを最小限にすることができる。異常判定モジュール（３１００）は、データベーストリガーによって異常有りの情報を取得した後は、該当のセンサのデータを用いて、通知の必要の有無を判断してもよい。

５－１－７．重要度、メッセージ、チャットルームの判定
異常判定モジュール（３１００）は、重要度の判定、どのようなメッセージを通知するかの判定、チャットルームの判定などのうち少なくともいずれか１つを行うことができる。

重要度の判定方法は、特に限定されないが、例えば、センサの測定値又はこれから算出される数値の大小に応じて決定してもよい。この目的で、センサの測定値又はこれから算出される数値と重要度とを関連付けたデータを設けることが好ましい。例えば、図７は、ボイラー等に取り付けた温度センサからのデータと、判定表とに基づいて、重要度を判定する方法の例を示す。温度が正常値の範囲（０～２００℃）の場合には、異常なしということで、重要度を０と判定する。一方で、正常値の範囲を超えて、温度が２００℃以上になった場合には、重要度を１と判定する。更には、同じ２００℃以上であっても、急激な変化の場合（例えば、変化率が２０％以上の場合）には、重要度を更に上げて２と判定する。また、温度が更に高く３００℃以上の場合にも、重要度を更に上げて２と判定する。図７の例では、判定に使用する項目として、測定値及び測定値の変化率を使用しているが、更に別のセンサの測定値等を追加してもよい。

メッセージの判定方法も、特に限定されず、例えば、図７と同様の判定表に基づいて、判定してもよい。この目的でセンサの測定値又はこれから算出される数値とメッセージの内容とを関連付けたデータを設けることが好ましい。図８に一例を示す。例えば、温度が正常値の範囲（０～２００℃）の場合には、異常なしということで、メッセージの出力は無しで良い。一方で、正常値の範囲を超えて、温度が２００℃以上になった場合には、「ボイラーの温度が正常範囲を超えました」というメッセージを選択する。更には、同じ２００℃以上であっても、急激な変化の場合（例えば、変化率が２０％以上の場合）には、「ボイラーの温度が急上昇しています。」というメッセージを選択する。また、温度が更に高く３００℃以上の場合には、「ボイラーの温度が危険域に入りました。至急停止してください」というメッセージを選択する。

チャットルームが複数ある場合には、適切なチャットルームを選択して、メッセージを投稿する必要がある。そのため、異常判定モジュール（３１００）は、どのチャットルームに投稿するかの判定も行う。例えば、図７に示すような、センサの情報と重要度とを関連付けたデータと、図９に示すような、重要度とチャットルームとを関連付けたデータを組み合わせて利用してもよい。重要度が低い（例えば０）の場合には、メッセージの投稿の必要が無く、チャットルームの選択が不要となる。重要度が１の場合には、工場内の各部門のうち、ボイラーの管理を担当する部門（図９では、現場部門Ａルーム）のチャットルームを選択してもよい。重要度が２の場合にはこれに加えて、工場長クラスのチャットルームを選択してもよい。更に重要度が高い場合（例えば、重要度が３の場合）には、役員クラスのチャットルームを追加で選択してもよい。

異常判定モジュール（３１００）は、別の情報に基づいて、どのチャットルームに投稿するかの判定を行うこともできる。例えば、センサの種類に基づいてもよい。一例を挙げると、図１０と図１１に示す判定表に該当するデータをマスタデータとして記憶しておき、これらのデータに基づいて、どのチャットルームに投稿するかの判定を行うこともできる。図１０に示すデータは、センサの識別情報とセンサの種類とを関連付けて記憶されたデータを示す。一方で、図１１に示すデータは、センサの種類とチャットルームとを関連付けて記憶されたデータを示す。

これらのデータを組み合わせて利用することで、例えば、Ａ００００１の識別情報を持つセンサにて、異常が発生した旨の判定を異常判定モジュール（３１００）が行った場合には、チャットルームとして、「ボイラー担当ルーム」を選択することができる。Ａ００００２及びＡ００００３の場合には、「空調担当ルーム」を選択することができ、そして、Ａ００００４の場合には、「倉庫担当ルーム」を選択することができる。

なお、図１１の変形例として、２つ以上のセンサの種類と、１つのチャットルームを関連付けて記憶したデータを利用してもよい。例えば、「室内温度センサ」「室外温度センサ」「冷凍保管庫温度センサ」全てにおいて異常が生じた場合には、おおもとの電気系統の異常である可能性が考えられるため、電力担当者のチャットルームに投稿するように選択してもよい。

異常判定モジュール（３１００）は、更に別の情報に基づいて、どのチャットルームに投稿するかの判定を行うこともできる。例えば、センサの位置情報に基づいてもよい。一例を挙げると、図１２と図１３に示す判定表に該当するデータをマスタデータとして記憶しておき、これらのデータに基づいて、どのチャットルームに投稿するかの判定を行うこともできる。図１２に示すデータは、センサの識別情報とセンサの設置場所とを関連付けて記憶されたデータを示す。一方で、図１３に示すデータは、センサの設置場所とチャットルームとを関連付けて記憶されたデータを示す。上述したセンサの種類の例と同様、あるセンサにおいて異常が発生した場合に、これらのデータを組み合わせて利用することで、異常判定モジュール（３１００）が、どのチャットルームに投稿するかの判定を行うことができる。

なお、図１３の変形例として、２つ以上のセンサの場所と、１つのチャットルームを関連付けて記憶したデータを利用してもよい。例えば、「ボイラー」と「室内（〇階×号室）」の両者が物理的に近い位置にある場合には、警備員グループのチャットルーム（更には、警備員がエリアごとに別々のチャットルームが存在する場合には、ボイラーと「ボイラー」と「室内（〇階×号室）」に近いエリアに関連するチャットルームを選択するように、データが構成されてもよい。

５－２．チャットモジュール
チャットモジュール（３３００）は、異常判定モジュール（３１００）から所定の情報を受信して、チャットルームへの投稿を行うように構成される。異常判定モジュール（３１００）から受信する情報は、例えば、チャットルームの識別情報、チャットルームへ投稿するメッセージの情報等が含まれる。チャットモジュール（３３００）は、チャットルームの識別情報に基づいて、適切なチャットルームを選択することができる。そして、異常判定モジュールから送信されたメッセージを投稿することができる。

チャットモジュール（３３００）は、チャットボットとしての機能を有しており、チャットルーム内の仮想の１ユーザとして、メッセージを投稿したり、特定のメッセージに反応したりするように構成される。チャットルームは、システム外部のチャットインフラが提供するものであってもよく、典型的にはビジネスチャットを提供するインフラ等が挙げられる（例えば、Ｓｌａｃｋ（登録商標）、ＣｈａｔＷｏｒｋ（登録商標）、Ｄｉｒｅｃｔ等）。

また、ユーザが、特定のセンサのデータ（例えば、時系列データ）などをリクエストするメッセージをチャットルームに投稿した場合には、チャットモジュール（３３００）は、これに応答して、管理サーバ（１２００）の分析モジュールに、データのリクエストを送信してもよい。そして、第２のチャットモジュール（１４１００）は、管理サーバ（１２００）の分析モジュールから送られてきた特定のセンサのデータを、チャットルームに投稿してもよい。

６．モニタリング端末
モニタリング端末（１４００）は、図１４に示すように、第２のチャットモジュール（１４１００）と、第３の通信モジュール（１４２００）を備えることができる。第３の通信モジュール（１４２００）は、所望のチャットルームからのデータの送受信を行うように構成される。第２のチャットモジュール（１４１００）は、ユーザからの操作に応答して、チャットルームにメッセージを投稿する、投稿するメッセージを作成する、或いは、チャットルームに投稿されたメッセージを取得する等の所望の機能を有する。

モニタリング端末（１４００）は、当分野で公知の情報処理装置（典型的には、プロセッサ、メモリ、記憶媒体、通信モジュール（例えばネットワークアダプタ等）を備える物）であってもよい。典型的には、パソコン、タブレット端末、スマートフォン等が挙げられる。

モニタリング端末（１４００）は、管理サーバ（１２００）のチャットモジュール（３３００）が投稿したメッセージを画面などに出力して、ユーザが閲覧できるようにする。これにより、管理サーバ（１２００）が、チャットモジュール（３３００）を通して送信した警告情報等の少なくとも一部を、ユーザが閲覧することが可能となる。そして、異常、故障、事故などを認識することができ、迅速に対応することが可能となる。

好ましい実施形態においては、モニタリング端末（１４００）を通してチャットルームに投稿されるメッセージは、警告情報に関連するセンサのデータをリクエストするメッセージも含む。例えば、ガス漏れの警告情報が、チャットモジュール（３３００）から投稿された場合、これに応答して、ユーザはモニタリング端末（１４００）を操作し、「ガスセンサのデータを表示して」といったメッセージを投稿することができる。

また、上記の例の場合、警告情報に関連するセンサとは、ガスセンサだけに限定されない。例えば、人感センサなども関連するセンサに含まれる。従って、ガス漏れの警告情報が、チャットモジュール（３３００）から投稿された場合、これに応答して、ユーザはモニタリング端末（１４００）を操作し、「人感センサのデータを表示して」といったメッセージを投稿することができる。これによって、まずは、人命という最優先すべき内容の確認を行うことができる。

７．監視方法
一実施形態において、本発明は、センサを利用した監視方法に関する。図１５に監視方法のフローの一例を示す。まず、ノード端末（１１００）は、無線通信モジュール（２２００）を通して、センサ情報を管理サーバ（１２００）に送信する（１５１００）。次に、管理サーバ（１２００）は、センサ情報に基づいて、通知の必要の有無を判断する（１５２００）。通知の必要がある場合には、チャットルームに投稿する（１５３００）。モニタリング端末（１４００）は、チャットルームに投稿された内容を表示する（１５４００）。これにより、ユーザは異常が発生したことを知ることができる。そして、迅速に対処することができる。

以上、本発明の具体的な実施形態について説明してきた。上記実施形態は、本発明の具体例に過ぎず、本発明は上記実施形態に限定されない。例えば、上述の実施形態の１つに開示された技術的特徴は、他の実施形態に適用することができる。また、特記しない限り、特定の方法については、一部の工程を他の工程の順序と入れ替えることも可能であり、特定の２つの工程の間に更なる工程を追加してもよい。本発明の範囲は、特許請求の範囲によって規定される。

Claims (9)

1. ＩｏＴシステムであって、
   前記システムは、ノード端末と、管理サーバとを備え、
   前記ノード端末は無線通信モジュールとセンサを備え、
   前記ノード端末は、前記無線通信モジュールを通して、センサ情報を前記管理サーバに送信するように構成され、
   前記管理サーバは、前記センサ情報を受信するように構成され、
   前記管理サーバは、前記センサ情報に基づいて、通知の必要の有無を判断するように構成され、
   前記管理サーバは、通知の必要がある場合には、チャットルームに投稿するように構成される、
   システム。
2. 請求項１のＩｏＴシステムであって、
   前記管理サーバは、複数の前記センサ情報に基づいて、通知の必要の有無を判断するように構成される、
   システム。
3. 請求項１又は２のＩｏＴシステムであって、
   前記管理サーバは、前記センサ情報が所定の閾値範囲外か否かを判定するように構成される、
   システム。
4. 請求項３のＩｏＴシステムであって、
   前記管理サーバは、前記センサ情報を記録するためのデータベースを備え、
   前記データベースは、前記センサ情報が所定の閾値範囲外となった場合に動作するデータベーストリガーを備える、
   システム。
5. 請求項１～４いずれか１項に記載のＩｏＴシステムであって、
   前記管理サーバは、複数のチャットルームに投稿可能であり、
   前記管理サーバは、前記センサ情報に基づいて、通知の重要度を判断するように構成され、
   前記管理サーバは、前記通知の重要度に基づいてチャットルームを選択するように構成される、
   システム。
6. 請求項１～４いずれか１項に記載のＩｏＴシステムであって、
   前記管理サーバは、複数のチャットルームに投稿可能であり、
   前記管理サーバは、前記センサの設置場所に基づいてチャットルームを選択するように構成される、
   システム。
7. 請求項１～４いずれか１項に記載のＩｏＴシステムであって、
   前記管理サーバは、複数のチャットルームに投稿可能であり、
   前記管理サーバは、前記センサの種類に基づいてチャットルームを選択するように構成される、
   システム。
8. 請求項１～７いずれか１項に記載のＩｏＴシステムであって、
   前記管理サーバは、ユーザがチャットルームに投稿したメッセージを取得するように構成され、
   前記管理サーバは、前記投稿されたメッセージに基づいて、前記センサ情報の表示の必要の有無を判断するように構成され、
   前記管理サーバは、表示の必要がある場合には、前記チャットルームに前記センサ情報を含むメッセージを投稿するように構成される、
   システム。
9. ＩｏＴシステムに組み込まれる管理サーバであって、
   前記管理サーバは、ノード端末に通信可能に接続され、前記ノード端末からセンサ情報を受信するように構成され、
   前記管理サーバは、前記センサ情報に基づいて、通知の必要の有無を判断するように構成され、
   前記管理サーバは、通知の必要がある場合には、チャットルームに投稿するように構成される、
   管理サーバ。

Images