WO2022180671A1

WO2022180671A1 - 遠隔監視システム

Info

Publication number: WO2022180671A1
Application number: PCT/JP2021/006806
Authority: WO
Inventors: 一輝秋葉
Original assignee: 三菱電機株式会社
Priority date: 2021-02-24
Filing date: 2021-02-24
Publication date: 2022-09-01
Also published as: JP7493670B2; JPWO2022180671A1

Abstract

遠隔監視システム（１００）は、空調機（１）に発生する異常を検出し、検出された異常を通報するように構成された遠隔監視装置（２）と、遠隔監視装置（２）とネットワークを介して通信し、遠隔監視装置（２）を経由して空調機（１）の異常の発生の通報を受けるように構成されたネットワークサーバ（３）とを備える。ネットワークサーバ（３）は、空調機（１）に発生した異常の種類に基づいて、遠隔監視装置（２）に対して空調機（１）にリセットコマンドを送信させるか否かを決定する。

Description

遠隔監視システム

　本開示は、遠隔監視システムに関する。

　国際公開第２００７／０８８９２８号公報は、室外機のアクチュエータに故障が生じた場合に、インバータ基板に対して自動的に電源リセットがかけられる空気調和機を開示する。

国際公開第２００７／０８８９２８号公報

　しかしながら、リセットをかけても空気調和機が正常に復帰するとは限らない。故障の種類によっては、リセットでは復帰しない場合もあり、リセットが繰返されてしまうなどの事態が発生する。

　本開示は、上記のような課題を解決するためになされたものであって、故障発生時に復帰可能性の高い場合に空気調和機にリセットをかけることが可能な遠隔監視システムを提供することを目的とする。

　本開示は、遠隔監視システムに関する。遠隔監視システムは、空調機に発生する異常を検出し、検出された異常を通報するように構成された遠隔監視装置と、遠隔監視装置とネットワークを介して通信し、遠隔監視装置を経由して空調機の異常の発生の通報を受けるように構成されたサーバとを備える。サーバは、空調機に発生した異常の種類に基づいて、遠隔監視装置に対して空調機にリセットコマンドを送信させるか否かを決定する。

　本開示の遠隔監視システムによれば、遠隔地から空気調和機の状態を監視しつつ、リセットによる復帰の可能性が高い場合に限定して、リセットを指示することが可能である。

実施の形態１に係る遠隔監視システムの構成を示す概略図である。遠隔監視装置２およびネットワークサーバ３の構成を示すブロック図である。登録された異常が発生した場合の動作を説明するための図である。図３のステップＳ５においてネットワークサーバ３で実行される処理を説明するためのフローチャートである。実施の形態２においてネットワークサーバ３に登録されているリストの例を示す図である。実施の形態２における成功確率の算出およびリセット実行の判断を説明するためのフローチャートである。図６のフローチャートの変形例を示す図である。実施の形態３における成功確率の算出およびリセット実行の判断を説明するためのフローチャートである。実施の形態３においてネットワークサーバ３に登録されているリストの例を示す図である。

　以下、本開示の実施の形態について、図面を参照しながら詳細に説明する。以下では、複数の実施の形態について説明するが、各実施の形態で説明された構成を適宜組み合わせることは出願当初から予定されている。なお、図中同一または相当部分には同一符号を付してその説明は繰返さない。なお、以下の図は各構成部材の大きさの関係が実際のものとは異なる場合がある。

　実施の形態１．
　図１は、実施の形態１に係る遠隔監視システムの構成を示す概略図である。図１に示す遠隔監視システム１００は、空調機１を遠隔監視する。

　空調機１は、室外機１２と、室内機１３－１～１３－ｎと、室内機１３－１～１３－ｎにそれぞれ接続される手元リモコンであるローカルコントローラ１４－１～１４－ｎと、室外機１２に接続される中央コントローラ１１とを備える。図１に示す構成では、中央コントローラ１１は１台の室外機１２に接続されているが、中央コントローラ１１は複数台の室外機に接続され、複数の室外機を集中制御するものであっても良い。

　遠隔監視システム１００は、空調機１に加えて、遠隔監視装置２とネットワークサーバ３とを備える。

　遠隔監視装置２は、空調機１とネットワークサーバ３との間で通信プロトコルを変換する通信プロトコル変換機の役割を果たしている。ネットワークサーバ３は、インターネット６を介して世界中の空調システムと接続することが可能な大容量のクラウドサーバを想定する。ネットワークサーバ３は、空調機１の内部通信網５および遠隔監視装置２を介して各ユニットから運転データを受信し、空調機１全体の運転データを蓄積する。また、ネットワークサーバ３は、空調機１の内部通信網５および遠隔監視装置２を介して、空調機１で使用している任意の通信コマンドを送信することもできる。

　さらに、ネットワークサーバ３は、空調機１で発生する異常コードおよび異常コード別のリセット必要度を登録することができる。空調機で発生する異常は、総合ユニット異常、冷媒系異常、水系異常、空気系異常、電気系異常、センサ故障系異常、通信系異常、システム異常に大きく分類される。異常コードによって、発生した故障がどの分類の故障かを知ることができる。

　上記の通信系異常は、「リセット必要度：大」に登録されている。通信系の異常は一時的な通信混雑により発生し、リセットで復旧する見込みが高いためである。逆に、システム異常は、「リセット必要度：小」に登録されている。システム系の異常は、空調機１を立上げている時に室外機１２が取得する室内機１３－１～１３－ｎの情報に基づいて判定されるため、リセット後も必ず同じ異常が発生するからである。

　上記のように、リセットしても復旧する見込みが薄く、サービス業者によるメンテナンスが必要と考えられる異常は、リセット必要度が小に設定される。たとえば、システム異常の中には接続台数に関する異常があり、また、冷媒系異常の中には冷媒不足、冷媒過多が発生している異常がある。このような異常は、リセットして再立上げしても正常に復帰することはないので、電源リセットする時間が無駄となる。したがって、このような異常は、リセット必要度が小に設定される。

　リセットすると復旧する見込みが高い異常は、リセット必要度が大に設定される。たとえば、ユニット間の通信異常、ユニット内の異常（基板間のシリアル通信の異常など）は、一時的な通信線の混雑または接触不良で発生する場合があるため、リセット必要度が大に設定される。なお、リセット必要度の大／小に代えて、リセットの要／否を登録しても良い。

　空調機では異常が発生したら予め定められたコマンドを用いて、空調機で相互に接続している機器に通報する。そのコマンド内の予め定められた箇所を取り出すことで、異常種類を識別することができる。

　なお、空調機１と遠隔監視装置２との通信異常の検知は、送信されるはずの定時通信を確認できない場合に検知しても良い。通信異常を検知したとき、空調機１側においてリセットした後、リセットした結果がネットワークサーバ３に通知される。

　図２は、遠隔監視装置２およびネットワークサーバ３の構成を示すブロック図である。遠隔監視システム１００は、遠隔監視装置２と、ネットワークサーバ３とを備える。

　遠隔監視装置２は、空調機１と専用の通信網５によって接続され、空調機１の運転データの収集、および、空調機１の制御などを行なう。

　ネットワークサーバ３は、遠隔監視装置２とインターネット６を介して接続される。ネットワークサーバ３は、遠隔監視装置２が収集した空調機１の運転データを蓄積する。運転データは、たとえば、空調機１が運転開始および終了した時刻、温度の設定の変更、冷房／暖房の運転切替、などのリモコン操作を示すデータと、冷媒配管などに設置されたセンサで計測された温度および圧力などの空調機１の状態を示すデータとを含む。

　遠隔監視装置２は、中央処理装置（ＣＰＵ：Central　Processing　Unit）２０と、記憶装置（ＲＯＭ（Read　Only　Memory）、ＲＡＭ（Random　Access　Memory）およびハードディスクなど）２１と、空調機接続部２２と、通信部２３とを含む。

　ＣＰＵ２０は、ＲＯＭに格納されているプログラムをＲＡＭ等に展開して実行する。ＲＯＭに格納されるプログラムは、遠隔監視装置２として動作する処理手順が記されたプログラムである。ＣＰＵ２０は、これらのプログラムに従って、ＦＷアップデート部２５、空調制御部２６、データ収集部２７、データ受信部２８としての処理を実行する。なお、ＦＷアップデート部２５、空調制御部２６、データ収集部２７、およびデータ受信部２８は、図２に示すように同じＣＰＵが制御する１つの制御部であっても良いが、異なるＣＰＵによって制御される別々の制御部であっても良い。

　ＦＷアップデート部２５は、ネットワークサーバ３から新規のファームウエアをダウンロードする。ＦＷアップデート部２５は、ダウンロードしたファームウエアが遠隔監視装置用のファームウエアであった場合、遠隔監視装置２自体に適用する。ＦＷアップデート部２５は、ダウンロードしたファームウエアが空調機用のファームウエアであった場合、空調機１に転送する。

　空調制御部２６は、ネットワークサーバ３から空調機１の制御コマンド（温度設定、風量設定など）を受信した場合に、制御コマンドを空調機１の専用通信プロトコルに変換し、変換したコマンドを空調機１に送信する。

　データ受信部２８は、空調機１から運転データを受信したら、記憶装置２１に保存する。記憶装置２１は、空調機１の運転データをたとえば最大５日分蓄積することができる。

　データ収集部２７は、ネットワークサーバ３から空調機１の運転データの収集要求があった場合に、遠隔監視装置のデータベースである記憶装置２１から空調機１の運転データを取り出し、ネットワークサーバ３に送信する。

　ネットワークサーバ３は、中央処理装置（ＣＰＵ：Central　Processing　Unit）３０と、記憶装置（ＲＯＭ（Read　Only　Memory）、ＲＡＭ（Random　Access　Memory）およびハードディスクなど）３１と、遠隔監視装置通信部３２とを含む。

　ＣＰＵ３０は、ＲＯＭに格納されているプログラムをＲＡＭ等に展開して実行する。ＲＯＭに格納されるプログラムは、ネットワークサーバ３として動作する処理手順が記されたプログラムである。ＣＰＵ３０は、これらのプログラムに従って、空調コントローラ３４、空調メンテナンス部３５、ＦＷアップデート部３６、トレンドデータ収集部３７、機器登録部３８、機器管理部３９としての処理を実行する。なお、空調コントローラ３４、空調メンテナンス部３５、ＦＷアップデート部３６、トレンドデータ収集部３７、機器登録部３８、機器管理部３９は、図２に示すように同じＣＰＵが制御する１つの制御部であっても良いが、異なるＣＰＵによって制御される別々の制御部であっても良い。またインターネット上に分散配置された複数のサーバによってネットワークサーバ３が実現されても良い。

　機器管理部３９は、ユーザに、他のユーザが使用する遠隔監視装置を操作させないための機能を備える。記憶装置３１は、遠隔監視装置２に固有の情報（機器データ）を蓄積する。

　空調コントローラ３４は、空調機１の設定温度および運転モードなどを管理する。空調コントローラ３４は、空調機１の付随するリモコンに相当する操作管理が可能である。空調メンテナンス部３５は、空調機１の設置時に工事担当者が使用する機能、およびサービスマンが使用する故障診断の機能などを有する。

　ＦＷアップデート部３６は、遠隔監視装置２のファームウエア、および、空調機１のファームウエアを送信および管理する機能を有する。

　トレンドデータ収集部３７は、空調機１の電力消費量および運転データ（設定温度および運転モードなどの遷移情報）などを一定周期で遠隔監視装置２から収集する。

　機器登録部３８は、遠隔監視装置２をネットワークサーバ３に登録する機能を有する。
　遠隔監視装置通信部３２は、遠隔監視装置２とインターネット６を介して通信を行なう。

　ネットワークサーバ３は、記憶装置３１に、空調機の異常種類（または異常分類）を登録したリストを記憶している。このリストに登録された異常が発生した通知を受けると、ネットワークサーバ３は、リストの内容に従って空調機１に対してリセットコマンドを送信するように、遠隔監視装置２を制御する。

　図３は、登録された異常が発生した場合の動作を説明するための図である。ステップＳ１に示すように、正常動作時には、ローカルコントローラ１４、室内機１３、室外機１２、中央コントローラ１１、から遠隔監視装置２は運転データを収集し、ネットワークサーバ３に運転データを定期的に送信している。

　たとえば一時的な通信の混雑が原因となり、空調システムを構成するユニットに異常が発生する場合がある。ここでは、ステップＳ２に示すように、室外機１２に異常が発生したと仮定する。

　異常発生した場合、ステップＳ３に示すように、異常が発生したユニット（室外機１２）から、そのユニットが接続しているユニット（室内機１３）および中央コントローラ１１およびローカルコントローラ１４に向けて、異常が発生したことを通報する通信コマンドが送信される。そして、異常の発生は、遠隔監視装置２を経由してネットワークサーバ３にも受信される。

　ネットワークサーバ３は、異常通報の通信コマンドを受信することで、ユニット（室外機１２）に異常が発生したことを検知する。なお、運転データを受信し、運転データからユニット（室外機１２）に異常が発生したことをネットワークサーバ３が検知しても良い。

　ステップＳ５に示すように、異常検知後、ネットワークサーバ３は、記憶装置３１に登録されている異常コードと登録されているリストの内容とに基づいて、ユニットのリセット要否を判断する。

　ステップＳ５において、ネットワークサーバ３がリセット必要と判断した場合、ステップＳ６に示すように、ネットワークサーバ３は、遠隔監視装置２を経由して、異常発生したユニット（室外機１２）にリセット要求コマンドを送信する。

　ステップＳ７において、遠隔監視装置２および中央コントローラ１１を経由して、リセット要求コマンドを受信したユニット（室外機１２）は、そのユニット自身でリセットをかける。

　図４は、図３のステップＳ５においてネットワークサーバ３で実行される処理を説明するためのフローチャートである。このフローチャートの処理は、メインルーチンから、一定時間ごとまたは予め定められた条件が成立するごとに呼び出されて実行される。

　ネットワークサーバ３は、ステップＳ１０１において、リセット必要度が登録されている異常発生の通報を受けたか否かを判断する。異常発生の通報がない場合には（Ｓ１０１でＮＯ）、ステップＳ１０２～Ｓ１０６の処理を実行せずに、メインルーチンに処理を戻す。

　異常発生の通報を受けた場合（Ｓ１０１でＹＥＳ）、ネットワークサーバ３は、通報された異常の種類に対応するリセット必要度が大であるか否かを判断する。通報された異常の種類が、リセット必要度大の登録リストにない場合には（Ｓ１０２でＮＯ）、リセット必要度は小であり、リセットしても復帰の見込みが低いので、ネットワークサーバ３はステップＳ１０６において空調機１を停止させる。

　通報された異常の種類に対応するリセット必要度が大であった場合には（Ｓ１０２でＹＥＳ）、ネットワークサーバ３は、遠隔監視装置２に対して空調機１をリセットするようにリセットコマンドを送信する（Ｓ１０３）。

　そして、ネットワークサーバ３は、運転状態または異常コードを取得して、ステップＳ１０４において空調機１が正常復帰したか否かを判断する。正常復帰した場合（Ｓ１０４でＹＥＳ）、メインルーチンに処理が戻り、通常の運転が継続される。一方、正常復帰しなかった場合（Ｓ１０４でＮＯ）、ステップＳ１０５において、ネットワークサーバ３は運転状態または異常コードに基づいて、ステップＳ１０３のリセット前と同じ異常が発生したか否かを判断する。

　発生した異常がリセット前と異なる場合には（Ｓ１０５でＮＯ）、再びステップＳ１０１以降の処理が実行される。一方、発生した異常がリセット前と同じであった場合には（Ｓ１０５でＹＥＳ）、リセットしても復帰の見込みが低いので、ネットワークサーバ３はステップＳ１０６において空調機１を停止させる。

　実施の形態１に示した遠隔監視システム１００では、空調機１の運転データを保存するため、空調機１を監視する遠隔監視装置２にインターネット６経由でネットワークサーバ３を接続する。ネットワークサーバ３は、空調機１で使用している任意の通信コマンドを送信することもできる。また、ネットワークサーバ３は、空調機１内で発生する異常とそのリセット必要度の登録機能を備えている。ネットワークサーバ３、その異常の登録内容に応じて空調機１のリセット要否を判断し、空調機１全体または空調機１を構成する単一ユニットごとにリセットをかけることができる。

　したがって、実施の形態１の遠隔監視システムによれば、エンドユーザー、サービス業者、代理店を含む空調機メーカー担当者が空調機１の据付現場に行かずに、空調機１の運転状態のデータを収集することができる。

　また、ネットワークサーバ３から空調機１および空調機１を構成する単一ユニットに通信コマンドを送信することができる。特に、１つのコマンドによって、空調機１の全体をリセットできるようにしたり、空調機１を構成する単一ユニットごとにリセットをかけたりできるように遠隔監視装置２に対するコマンドを作成しておけば、ネットワークサーバ３がインターネット６を介して送信する内容を単純にすることができる。

　また、ネットワークサーバ３に登録している異常であれば、空調機１をリセットすることができ、一度再立上げし直すことで、自動的に異常復旧を試みることができる。その結果、空調機１が異常で停止し続ける期間の短縮、およびサービス業者の現地訪問の回数削減が期待できる。

　また、実施の形態１の遠隔監視システム１００によれば、リセットすれば正常復帰の可能性が高い異常の場合を判別して、異常が発生したユニットにリセットをかけることができる。このため、リセットが繰返されるなどの事態を避けることができる。

　実施の形態２．
　実施の形態１では、登録されていない異常が発生した場合については、特に限定していなかった。実施の形態２では、未登録の異常が発生した場合に、ネットワークサーバ３がリセットによって正常に復帰する確率（以下、成功確率という）を算出し、これに基づいてリセットを行なうか否かを判断する。

　実施の形態２においても、図４に示した実施の形態１と同様な処理が随時実行されている。図５は、実施の形態２においてネットワークサーバ３に登録されているリストの例を示す図である。

　図５に示すリストでは、「異常コードＦ１－０１：冷媒過充填」がリセット必要度小、「異常コードＦ１－０２：冷媒不足」がリセット必要度小、「異常コードＦ２－０１：応答フレーム無返送」がリセット必要度大、「異常コードＦ３－０１：接続台数異常」がリセット必要度小、「異常コードＦ３－０２：組合せ異常」がリセット必要度小、と予め登録されている。ここまでは、実施の形態１と同様であり、「リセット必要な異常」がリセット必要度大と登録され、「リセットしても意味のない異常」がリセット必要度小と登録されている。

　実施の形態２では、リセット必要度が不明である異常がさらに登録される。図５の例では、「異常コードＦ４－０１：ＩＰＭ異常」は、リセット必要度は不明であり登録されていないが、代わりに成功確率が登録されている。このＩＰＭ異常は、リセットで復旧する場合と、復旧しない場合があり、成功確率は、リセットをかける空調機１が置かれている状況に左右される。

　実施の形態２では、ネットワークサーバ３に、学習機能を搭載し、運転データを解析する機能を持たせる。リセット必要度が登録されていない異常が発生した場合、学習機能により、リセットの要否を運転データから解析することで、より正確なリセット要否を判断することができると考えられる。

　学習方法の一つとして、リセット後の再立上げ時、リセット前に発生していた異常が、リセット後には発生しなくなったパターンを「成功データ」、逆にリセット後も同じ異常が発生してしまった場合を「失敗データ」として学習データに保存する。

　図６は、実施の形態２における成功確率の算出およびリセット実行の判断を説明するためのフローチャートである。

　図６に示すフローチャートでは、まずステップＳ１１１において、ネットワークサーバ３は、遠隔監視装置２から運転データを取得する。ステップＳ１１２では、ネットワークサーバ３は、未登録の異常が発生したか否かを判断する。未登録の異常の発生がない場合（Ｓ１１２でＮＯ）、ステップＳ１１３において一定時間の経過が確認されるまではステップＳ１１２の処理に戻り、一定時間の経過が確認されると、再び、ステップＳ１１１に処理が戻される。このようにして、ネットワークサーバ３は、通常時は一定周期ごとに運転データを取得し続けている。

　未登録の異常が発生した場合（Ｓ１１２でＹＥＳ）、ステップＳ１１４において、ネットワークサーバ３は、最新の異常コードを保存し、異常発生直前の運転データを「異常前データ（１回目）」として保存する。

　そして、ステップＳ１１５において、ネットワークサーバ３は、発生した異常種類に対応する成功確率がしきい値以上であるか否かを判断する。たとえば、成功確率の初期値は１００％に設定されており、２回目以降は、成功した回数と失敗した回数から成功確率が算出される。

　ネットワークサーバ３は、発生した異常と各ユニットの異常前データより、「成功確率」を計算し、保持しておく。今回リセットした場合の「成功確率」があるしきい値以上である場合（Ｓ１１５でＹＥＳ）、ステップＳ１１６において、ネットワークサーバ３は、遠隔監視装置２にリセットを指示する。成功確率がしきい値未満の場合は（Ｓ１１５でＮＯ）、リセットせず、ステップＳ１２２において、ネットワークサーバ３は遠隔監視装置に空調機１を停止させるように指示する。

　ステップＳ１１６でリセットが実行された場合、ステップＳ１１７においてネットワークサーバ３は、リセットからたとえば１時間以内を「異常復帰状態」として運転データを取得する。そしてステップＳ１１８において、ネットワークサーバ３は、空調機１が正常復帰したか否かを取得した運転データに基づいて判断する。

　正常復帰した場合は（Ｓ１１８でＹＥＳ）、ネットワークサーバ３は、異常前データ（１回目）を「成功データ」として保存し、復帰に成功した回数に１を加算し、成功確率を再計算する。そして、ステップＳ１１１に処理が戻って、再び運転データの取得が行なわれる。

　一方、リセットしても正常復帰しなかった場合（Ｓ１１８でＮＯ）、ステップＳ１２０において、ネットワークサーバ３は、異常コードまたは運転データに基づいて、異常種類が同じであるか否かを判断する。異常種類が異なる場合は（Ｓ１２０でＮＯ）、新たな異常種類について、ステップＳ１１５以降の処理が再実行される。

　異常種類が同じであった場合（Ｓ１２０でＹＥＳ）、ステップＳ１２１において、ネットワークサーバ３は、最新の異常コードを保存し、異常発生直前の運転データを異常前データ（２回目）として保存し、異常前データ（１回目）および異常前データ（２回目）をともに、「失敗データ」として保存し、これらを復帰に失敗した回数にカウントし、成功確率を再計算する。その後、ステップＳ１２２において、ネットワークサーバ３は遠隔監視装置に空調機１を停止させるように指示する。

　実施の形態２では、ネットワークサーバ３の運転データ蓄積量が多くなるほど、成功のサンプル数は増えていくと考えられる。成功のサンプル数がある回数を超えた異常種類については、リストのリセット必要度大の登録に追加しても良い。

　図７は、図６のフローチャートの変形例を示す図である。図６では、成功確率を実績に基づいて計算していたが、当初の成功確率を１００％に定めて、その後リセットによる正常復帰が失敗した場合には成功確率を減少（たとえば－１０％）させ、リセットによる正常復帰が成功した場合には上限を１００％として成功確率を増加（たとえば＋１０％）させるようにしても良い。図７に、そのような変形例の処理を示す。

　図７のフローチャートの処理は、メインルーチンから、一定時間ごとまたは予め定められた条件が成立するごとに呼び出されて実行される。

　まずステップＳ１３１において、ネットワークサーバ３は、遠隔監視装置２から運転データを取得する。ネットワークサーバ３は、ステップＳ１３２において、リセット必要度が登録されていない異常発生の通報を受けたか否かを判断する。そのような異常発生の通報がない場合には（Ｓ１３２でＮＯ）、ステップＳ１４１においてメインルーチンに処理を戻す。

　異常発生の通報を受けた場合（Ｓ１３２でＹＥＳ）、ステップＳ１３３において、ネットワークサーバ３は、通報された異常の異常コードを参照して、当該異常の発生が初回か否かを判断する。初回であった場合（Ｓ１３３でＹＥＳ）、ステップＳ１３４において、ネットワークサーバ３は、当該故障の成功確率を１００％に設定する。たとえば、図５の異常コードＦ４－０１のＩＰＭ故障については、リセット必要度は登録されていない一方、初回に異常が検出された場合には、成功確率は初期値として１００％に設定される。そして、ステップＳ１３６においてネットワークサーバ３は遠隔監視装置２にリセットを指示する。

　初回でなかった場合（Ｓ１３３でＮＯ）、すでに成功確率が記録されているので、ステップＳ１３５において、ネットワークサーバ３は、図５に示したリストを参照して、発生した異常種類に対応する成功確率がしきい値以上であるか否かを判断する。しきい値は、たとえば５０％に設定することができる。

　発生した異常について登録されている「成功確率」があるしきい値以上である場合（Ｓ１３５でＹＥＳ）、ステップＳ１３６において、ネットワークサーバ３は、遠隔監視装置２にリセットを指示する。成功確率がしきい値未満の場合は（Ｓ１３５でＮＯ）、リセットせず、ステップＳ１４２において、ネットワークサーバ３は遠隔監視装置２に空調機１を停止させるように指示する。

　ステップＳ１３６でリセットが実行された場合、ステップＳ１３７においてネットワークサーバ３は、リセットからたとえば１時間以内を「異常復帰状態」として運転データを取得する。そしてステップＳ１３８において、ネットワークサーバ３は、空調機１が正常復帰したか否かを取得した運転データに基づいて判断する。

　正常復帰した場合は（Ｓ１３８でＹＥＳ）、ネットワークサーバ３は、今回の異常発生時のリセットによる結果を成功と判断し、ステップＳ１３９において上限を１００％として成功確率を増加させる。たとえば、増加幅を１０％とすることができる。

　一方、リセットしても正常復帰しなかった場合（Ｓ１３８でＮＯ）、ネットワークサーバ３は、今回の異常発生時のリセットによる結果を失敗と判断し、ステップＳ１５９において成功確率を減少させる。たとえば、減少幅を－１０％とすることができる。

　ステップＳ１３９またはステップＳ１４０において、成功確率が変更された後には、図５に示したリストの成功確率は更新される。たとえば、正常復帰に失敗した場合、図５の異常コードＦ４－０１に示すように成功確率は、１００％から９０％に減少する。その後、ステップＳ１４１において処理はメインルーチンに戻される。

　以上説明したように、実施の形態２では、ネットワークサーバ３は、空調機１に異常が発生する直前のデータ、およびリセット実施後の運転状況から、リセット立上げ時の「成功確率」を算出する。ネットワークサーバ３に登録していない異常が発生した場合、「成功確率」をもとに、ネットワークサーバ３は、リセット要否を判定し、リセットが必要と判断された場合は、空調機１にリセット要求を送信する。「成功確率」は、リセットの結果「失敗（リセット後にリセット実施前と同じ異常が発生する場合）」、「成功（リセット後にリセット実施前と同じ異常が発生しない場合）」と「異常前データ」から算出される。

　実施の形態２の遠隔監視システムによれば、リセット成功確率はネットワークサーバ３内で計算、学習できるため、リセット要否をより正確に判断できるようになる。その結果、リセットで復帰できる場合は復帰することができ、復帰できない場合はサービス業者を派遣することができることで、より正確なメンテナンスを実施することができるようになる。

　実施の形態３．
　実施の形態２では成功確率を算出することを示したが、成功確率をすべての異常種類に対して算出し、リセット必要度に代えて成功確率に基づいてリセット実行するか否かを判定するようにしても良い。

　図８は、実施の形態３における成功確率の算出およびリセット実行の判断を説明するためのフローチャートである。図９は、実施の形態３においてネットワークサーバ３に登録されているリストの例を示す図である。

　図８のフローチャートの処理は、メインルーチンから、一定時間ごとまたは予め定められた条件が成立するごとに呼び出されて実行される。

　まずステップＳ１５１において、ネットワークサーバ３は、遠隔監視装置２から運転データを取得する。ネットワークサーバ３は、ステップＳ１５２において、異常発生の通報を受けたか否かを判断する。異常発生の通報がない場合には（Ｓ１５２でＮＯ）、ステップＳ１５８においてメインルーチンに処理を戻す。

　異常発生の通報を受けた場合（Ｓ１５２でＹＥＳ）、ステップＳ１５３において、ネットワークサーバ３は、図８に示したリストを参照して、発生した異常種類に対応する成功確率がしきい値以上であるか否かを判断する。

　図９に示す例では、異常種類Ｆ１，Ｆ２，Ｆ３，Ｆ４について、それぞれ、現時点の成功確率が１００％、７５％、５０％、３３％と記録されている。しきい値を、たとえば５０％にした場合は、異常種類Ｆ１～Ｆ３の異常発生時には、リセットが実行され、異常種類Ｆ４の異常発生時にはリセットは実行されない。

　たとえば、成功確率の初期値は１００％に設定されており、２回目以降は、成功した回数と失敗した回数から成功確率が算出される。運転データを分析して、異常の種類が未登録であった場合には、当該種類の欄がリストに追加され、成功確率は、初期値の１００％に設定される。

　発生した異常について登録されている「成功確率」があるしきい値以上である場合（Ｓ１５３でＹＥＳ）、ステップＳ１５４において、ネットワークサーバ３は、遠隔監視装置２にリセットを指示する。成功確率がしきい値未満の場合は（Ｓ１５３でＮＯ）、リセットせず、ステップＳ１６０において、ネットワークサーバ３は遠隔監視装置２に空調機１を停止させるように指示する。

　ステップＳ１５４でリセットが実行された場合、ステップＳ１５５においてネットワークサーバ３は、リセットからたとえば１時間以内を「異常復帰状態」として運転データを取得する。そしてステップＳ１５６において、ネットワークサーバ３は、空調機１が正常復帰したか否かを取得した運転データに基づいて判断する。

　正常復帰した場合は（Ｓ１５６でＹＥＳ）、ネットワークサーバ３は、今回の異常発生時のリセットによる結果を成功と判断し、復帰に成功した回数に１を加算し、ステップＳ１５７において成功確率を再計算する。この場合、成功確率は増加する。

　一方、リセットしても正常復帰しなかった場合（Ｓ１５６でＮＯ）、ネットワークサーバ３は、今回の異常発生時のリセットによる結果を失敗と判断し、復帰に失敗した回数に１を加算し、ステップＳ１５９において成功確率を再計算する。この場合、成功確率は減少する。

　ステップＳ１５７またはステップＳ１５９において、成功確率が再計算された後には、図９に示したリストの成功確率は更新され、ステップＳ１５８において処理はメインルーチンに戻される。

　以上説明した実施の形態３では、実施の形態２のように予めリセット必要度が登録されていなくても、リセットによる復帰見込みが高い場合を学習し、ネットワークサーバ３がリセットを自動的にかけるように変化していく。なお、実施の形態３においても図７で説明した実施の形態２の変形例のように、Ｓ１５７，Ｓ１５９の成功確率の増減を実績（復帰の成功回数および失敗回数）に基づいて再計算するのではなく、復帰の成否に基づいて一定値（たとえば１０％）増減させるようにしても良い。

　（まとめ）
　本開示は、遠隔監視システム１００に関する。図１および図２に示す遠隔監視システム１００は、空調機１に発生する異常を検出し、検出された異常を通報するように構成された遠隔監視装置２と、遠隔監視装置２とネットワークを介して通信し、遠隔監視装置２を経由して空調機１の異常の発生の通報を受けるように構成されたネットワークサーバ３とを備える。ネットワークサーバ３は、空調機１に発生した異常の種類に基づいて、遠隔監視装置２に対して空調機１にリセットコマンドを送信させるか否かを決定する。

　ネットワークサーバ３は、検出された異常の種類が予めサーバにリセット必要度大として登録されているリスト（図５）に含まれている場合には、遠隔監視装置２に対して空調機１にリセットコマンドを送信させるように構成される。

　ネットワークサーバ３は、リセット必要度大として登録されているリストに含まれていない異常の種類（図５の異常コードＦ４－０１など）ごとに、リセットコマンドを送信した場合に空調機が正常に復帰する成功確率を記憶するように構成される。

　図６のステップＳ１１５に示すように、ネットワークサーバ３は、検出された異常の種類がリストに含まれていない場合には、遠隔監視装置２からの通報に応じて検出された異常の種類に対応する成功確率に基づいて、遠隔監視装置２に対して空調機１にリセットコマンドを送信させるか否かを決定する。

　図６のステップＳ１１８～Ｓ１２１に示すように、ネットワークサーバ３は、遠隔監視装置２に対して空調機１にリセットコマンドを送信させた場合、空調機１が正常に復帰したか否かに基づいて成功確率を更新する。

　図５または図９に示すように、ネットワークサーバ３は、異常の種類ごとに、リセットコマンドを送信した場合に空調機１が正常に復帰する成功確率を記憶するように構成される。ネットワークサーバ３は、遠隔監視装置２からの通報に応じて検出された異常の種類に対応する成功確率に基づいて、遠隔監視装置２に対して空調機１にリセットコマンドを送信させるか否かを決定する。

　図５のステップＳ１３８～Ｓ１４０または図８のステップＳ１５４～Ｓ１５９に示すように、ネットワークサーバ３は、遠隔監視装置２に対して空調機１にリセットコマンドを送信させた場合、空調機１が正常に復帰したか否かに基づいて成功確率を更新する。

　なお、異常の種類の判別については、異常コードから判別する場合と、運転状態から判別する場合とが考えられる。

　すなわち、遠隔監視装置２は、検出された異常の種類に応じた異常コードをサーバに送信するように構成される。この場合は、ネットワークサーバ３は、異常コードに基づいて検出された異常の種類を判別するように構成される。

　他の例では、遠隔監視装置２は、空調機１の異常の発生の通報とともに、空調機１の運転状態をサーバに送信するように構成される。この場合は、ネットワークサーバ３は、遠隔監視装置２から通報を受けた場合には、運転状態に基づいて検出された異常の種類を判別するように構成される。

　以上、実施の形態１～３の遠隔監視システムによれば、以下の効果が得られる。
　システムをリセットコマンドで再立上げすることにより、異常復旧できることがある。たとえば、通信異常は一時的なシステム不調によることが原因で発生することがあり、一度リセットすることで十分に復帰することができるケースがある。リセット後はリモコンに異常コードが表示されることもなく、無事異常から復帰できた場合はサービス業者によるメンテナンスなしで運転再開することができる。

　これにより、ユーザが故障を意識しないで済むため、サービス部品交換負荷の削減、サービス備品在庫の消費を防ぐことができる。

　また、異常発生したユニットの部品は、サービス業者から工場に送付され、故障箇所がないか調査を依頼されることが多い。リセットで十分に復帰する異常の場合、工場で部品を検査しても故障箇所を見つけられないことが多く、その場合、異常発生した原因の可能性をサービス業者に教える必要があるが、部品に故障個所が見つからなかったことから想定原因を抽出することが困難である。本実施の形態の遠隔監視システムによれば、メーカーへの部品の送付回数、調査件数が減り、メーカーの負担が軽減される。

　（変形例）
　たとえば室外機で異常が発生したことを想定した場合、再立上げの時間を短縮するために、電源リセット前に現在のユニット情報およびシステム情報など、不揮発メモリに保存してからリセットし、リセット後は不揮発メモリに保存している内容を読み出して再立上げする処理にすれば、立上げ時間は短縮することができる。

　実施の形態１～３では、ネットワークサーバ３がリセットをかけることを記載しているが、空調機１のリセットのみであれば、遠隔監視装置２がリセット判断を行ない、リセットをかけることも可能である。遠隔監視装置２は、空調機１とネットワークサーバ３との間の通信を中継するものであるため、通信内容を取得して分析することも可能である。したがって、遠隔監視装置２にリセット必要度大の異常のみを登録しておき、登録されている異常が発生した場合は、異常が発生しているユニットに対し、リセット要求を送信することもできる。

　今回開示された実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本開示の範囲は、上記した実施の形態の説明ではなくて請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

　１　空調機、２　遠隔監視装置、３　ネットワークサーバ、５　通信網、６　インターネット、１１　中央コントローラ、１２　室外機、１３，１３－１～１３－ｎ　室内機、１４，１４－１～１４－ｎ　ローカルコントローラ、２１，３１　記憶装置、２２　空調機接続部、２３　通信部、２５，３６　アップデート部、２６　空調制御部、２７　データ収集部、２８　データ受信部、３０　ＣＰＵ、３２　遠隔監視装置通信部、３４　空調コントローラ、３５　空調メンテナンス部、３７　トレンドデータ収集部、３８　機器登録部、３９　機器管理部、１００　遠隔監視システム。

Claims

　空調機に発生する異常を検出し、検出された異常を通報するように構成された遠隔監視装置と、
　前記遠隔監視装置とネットワークを介して通信し、前記遠隔監視装置を経由して前記空調機の異常の発生の通報を受けるように構成されたサーバとを備え、
　前記サーバは、前記空調機に発生した異常の種類に基づいて、前記遠隔監視装置に対して前記空調機にリセットコマンドを送信させるか否かを決定する、遠隔監視システム。
　前記サーバは、前記検出された異常の種類が予め前記サーバに登録されているリストに含まれている場合には、前記遠隔監視装置に対して前記空調機に前記リセットコマンドを送信させるように構成される、請求項１に記載の遠隔監視システム。
　前記サーバは、前記リストに含まれていない異常の種類ごとに、前記リセットコマンドを送信した場合に前記空調機が正常に復帰する成功確率を記憶するように構成され、
　前記サーバは、前記検出された異常の種類が前記リストに含まれていない場合には、前記遠隔監視装置からの通報に応じて前記検出された異常の種類に対応する成功確率に基づいて、前記遠隔監視装置に対して前記空調機に前記リセットコマンドを送信させるか否かを決定する、請求項２に記載の遠隔監視システム。
　前記サーバは、前記遠隔監視装置に対して前記空調機に前記リセットコマンドを送信させた場合、前記空調機が正常に復帰したか否かに基づいて前記成功確率を更新する、請求項３に記載の遠隔監視システム。
　前記サーバは、異常の種類ごとに、前記リセットコマンドを送信した場合に前記空調機が正常に復帰する成功確率を記憶するように構成され、
　前記サーバは、前記遠隔監視装置からの通報に応じて前記検出された異常の種類に対応する成功確率に基づいて、前記遠隔監視装置に対して前記空調機に前記リセットコマンドを送信させるか否かを決定する、請求項１に記載の遠隔監視システム。
　前記サーバは、前記遠隔監視装置に対して前記空調機に前記リセットコマンドを送信させた場合、前記空調機が正常に復帰したか否かに基づいて前記成功確率を更新する、請求項５に記載の遠隔監視システム。
　前記遠隔監視装置は、前記検出された異常の種類に応じた異常コードを前記サーバに送信するように構成され、
　前記サーバは、前記異常コードに基づいて前記検出された異常の種類を判別するように構成される、請求項１に記載の遠隔監視システム。
　前記遠隔監視装置は、前記空調機の異常の発生の通報とともに、前記空調機の運転状態を前記サーバに送信するように構成され、
　前記サーバは、前記遠隔監視装置から通報を受けた場合には、前記運転状態に基づいて前記検出された異常の種類を判別するように構成される、請求項１に記載の遠隔監視システム。