JP6718827B2 - ＩｏＴを活用した管理システム及びこれを応用した給湯器データ送信システム - Google Patents

Description

本発明は、ＩｏＴを活用した管理システムに関し、さらに詳しくは、これを応用した給湯器データ送信システムに関する。

例えば給湯器の管理のためには種々の検討が行われている。一例として、通信を利用した遠隔管理に関しては、給湯器から出力された運転情報を携帯端末からサーバに送信するとともに、給湯器の運転状態に対応してサーバが設定した運転モードを携帯端末により給湯器に返信し、そのモードでの運転を給湯器に実行させることが開示されている。（特許文献１）また、故障情報への対応のため、ＧＰＳ機能を利用して給湯器の設置場所を管理センタへ通知することのできる給湯器リモートコントローラも提案されている。（特許文献２）、さらに、ＩｏＴを活用した給湯器の保守に関しては、従来、給湯器が故障した場合にサービス担当者が現場に急行して保守用のパソコンを給湯器に接続して異常を確認して対処していたのに対し、燃焼時間や不完全燃焼の有無、各種センサの異常など給湯器の稼働データをクラウドサービスに送信し、異常が発生した場合に担当者が対処法を想定して現場に向かえるようにするとともに、クラウドに蓄積したデータを分析することで、部品を故障前に交換できるようにする提案も報道されている。一方、給湯器における異常対策に関しても、過電流監視により遮断されたスイッチング素子を導通状態に復帰させる処理を所定回数以上実行した場合には、給電復帰処理を禁止することが提案されている。（特許文献３）

特開２０１３−１３４００１号公報 特開２０１６−０５０６９１号公報 特開２０１６−２０１９２５号公報

しかしながら、ＩｏＴを活用した給湯器の管理に関しては、さらに検討すべき点が多い。

本発明の課題は、上記に鑑み、ＩｏＴを活用した管理システムおよびこれを応用した給湯器データ送信システムを提案することにある。

上記課題を達成するため、本発明は、多数の機器とこれを管理するクラウドシステムにおいて、多数の機器はそれぞれクラウドシステムに送信する複数の項目のデータ保持部と、これら複数のデータ項目を所定の送信トリガに基づいて前記データ保持部から前記クラウドシステムに送信する制御部とを有し、前記制御部は前記送信トリガの度に毎回複数のデータ項目のすべてを前記クラウドシステムに送信することを特徴とするＩｏＴを活用した管理システムを提供する。これによって、予断なしに多数の機器をクラウドシステムにより管理することができる。

具体的な特徴によれば、前記制御部は、想定される前記複数のデータ項目の少なくとも一つの変化を前記送信トリガとして、変化のないデータ項目を含め前記複数のデータ項目の全てを前記クラウドシステムに送信する。これによって、データ送信に適切なトリガをかけることができるとともにトリガの別によるバイアスなしに複数のデータ項目のすべてを前記クラウドシステムに送信することができる。より具体的な特徴によれば、前記制御部は、前記機器における通常機能に伴う前記データ項目の少なくとも一つの変化を前記送信トリガとして前記複数のデータ項目の全てを前記クラウドシステムに送信する。

他のより具体的な特徴によれば、前記制御部は、前記機器における機能における前記データ項目の少なくとも一つにおける異常レベル以下の所定以上のレベルの変化を前記送信トリガとして前記複数のデータ項目の全てを前記クラウドシステムに送信する。これによって、管理効率のよいデータ送信が可能となる。さらに具体的な特徴によれば、前記クラウドシステムは、前記多数の機器から送信される前記複数のデータ項目に基づき、前記送信トリガとなるデータ項目を修正し、前記多数の機器にそれぞれフィードバックする。これによってより適切な送信トリガの改善を図ることができる。

他のより具体的な特徴によれば、前記多数の機器は、それぞれ制御基板を有し、前記制御基板において過電流と判断される閾値以下の値の定格内電流範囲内における所定以上の電流データの発生の有無、前記電流データの発生頻度、および前記電流データの値の所定の変動パターンの少なくとも一つを前記送信トリガとして前記複数のデータ項目の全てを前記クラウドシステムに送信する。これによって、クラウドシステムは、機器における過電流発生の予兆を事前に判定することができる。

他の具体的な特徴によれば、前記制御部は、関連する一連の送信トリガに基づいて前記クラウドシステムに複数回送信する前記複数のデータをグループ化する共通の指標を前記複数回送信する前記複数のデータにそれぞれ付与する。これによって、関連する送信データが効果的にグループ化され、効率のよい制御が可能となる。

他の具体的な特徴によれば、前記多数の機器は給湯器であり、前記クラウドシステムは、前記給湯器から送信される前記複数のデータ項目に基づき前記給湯器の故障予兆を判定する。これによって、給湯器の故障予兆が効果的に判定できる。より具体的な特徴によれば、前記クラウドシステムは、前記多数の給湯器から送信される前記複数のデータ項目に基づき、前記給湯器の故障予兆を判定する基準を修正する。

他の具体的な特徴によれば、前記制御部は、さらに、所定時刻の到来を送信トリガとして前記データ保持部から前記クラウドシステムに送信する。これによって、データ項目によるトリガがないタイミングにおいても、クラウドシステムは定期的に管理下の複数機器のデータ項目を把握することができる。

本発明の他の特徴によれば、多数の給湯器とこれを管理するクラウドシステムにおいて、多数の給湯器はそれぞれクラウドシステムに送信する複数の項目のデータ保持部と、これら複数のデータ項目を所定の送信トリガに基づいて前記データ保持部から前記クラウドシステムに送信する制御部とを有し、前記クラウドシステムは、前記多数の給湯器から送信される前記複数のデータ項目に基づき、前記送信トリガとなるデータ項目を修正し、前記多数の機器にそれぞれフィードバックすることを特徴とするＩｏＴを活用した管理システムが提案される。これによってより適切な送信トリガの改善を図ることができる。

本発明の他の特徴によれば、多数の給湯器とこれを管理するクラウドシステムにおいて、多数の給湯器はそれぞれクラウドシステムに送信する複数の項目のデータ保持部と、これら複数のデータ項目を所定の送信トリガに基づいて前記データ保持部から前記クラウドシステムに送信する制御部とを有し、前記クラウドシステムは、前記給湯器から送信される前記複数のデータ項目に基づき前記給湯器の故障予兆を判定するとともに、前記多数の給湯器から送信される前記複数のデータ項目に基づき、前記給湯器の故障予兆を判定する基準を修正することを特徴とするＩｏＴを活用した管理システムが提供される。これにより給湯器のより適切な故障予兆判定が可能となる。

本発明の他の特徴によれば、多数の給湯器とこれを管理するクラウドシステムを有するＩｏＴを活用した管理システムにおいて、給湯器が故障した場合に保守用パソコンを接続するためのインターフェースを有する給湯器と、前記インターフェースに接続可能であり、前記クラウドシステムに前記給湯器の複数のデータ項目を送信するための制御ユニットとを有することを特徴とする給湯器データ送信システムが提案される。これによって、給湯器が故障した場合に保守用パソコンを接続するためのインターフェースを有する通常の給湯器を対象としてクラウドシステムによる管理が可能となる。

具体的な特徴によれば、前記制御ユニットに、給湯器の遠隔操作のための携帯電話との通信機能が備えられる。これによって、これによって、遠隔操作が可能な給湯器においてクラウドシステムによる管理が可能となる。

他の具体的な特徴によれば、前記給湯器は排気口を有し、前記排気口からの排気を検知するとともに前記給湯器に設置される排気センサが前記制御ユニットに接続可能である。他の具体的な特徴によれば、前記給湯器に給電される電流を検知する電流センサを有し、前記電流センサが前記制御ユニットに接続可能である。これによって、通常の給湯器を対象としてクラウドシステムによる多様な管理が可能となる。

他の具体的な特徴によれば、前記給湯器は制御基板を有し、前記制御基板において過電流と判断される閾値以下の値の定格内電流範囲内における所定以上の電流データの発生の有無、前記電流データの発生頻度、および前記電流データの値の所定の変動パターンの少なくとも一つを前記制御ユニットから前記クラウドシステムに送信する。これによって、クラウドシステムは、給湯器における過電流発生の予兆を事前に判定することができる。

他の具体的な特徴によれば、前記制御ユニットは、給湯器の異音を検知するためのマイクを有し、前記マイクからの情報を前記クラウドシステムに送信する。また、他の具体的な特徴によれば、前記制御ユニットは、給湯器の振動を検知する振動センサを有し、前記振動センサからの情報を前記クラウドシステムに送信する。さらに他の具体的な特徴によれば、前記制御ユニットは、気圧計を有し、前記気圧計に基づく情報を前記クラウドシステムに送信する。これらのいずれかによって、クラウドシステムによる多様な給湯器の管理が可能となる。

上記のように、本発明によれば、より有用なＩｏＴを活用した管理システムおよびこれを応用した給湯器データ送信システムが提供される。

本発明の実施例の全体構成を示すブロック図である。（実施例） 図１の実施例において情報交換に用いられる単位データのデータ構造を示す表である。 図２の「単位データ送信条件」として単位データに付与される種々の「履歴ＩＤ」をまとめた表である。 上記実施例における保守制御部の動作を説明する基本フローチャートである。 上記実施例におけるクラウドサービスで実行される機能を説明する基本フローチャートである。 図５のステップＳ５２の詳細を示すフローチャートである。 図６のステップＳ７６の詳細を示すフローチャートである。 図６のステップＳ７８の詳細を示すフローチャートである。

図１は、本発明の実施の形態に係る給湯器管理システムの実施例の全体構成を示すブロック図である。給湯器２はガスバーナ４と熱交換器６を収納する燃焼筐８を有する。ガスバーナ４には点火装置１０が備えられているとともに、燃料ガスの供給路には、外部ガス管から燃焼ガスを導入するガス元電磁弁１２およびガスバーナ４への燃焼ガス供給を制御するガス給湯電磁弁１４が設けられている。燃焼筐８の下端には燃焼用空気を供給する燃焼ファン１６が設けられているととともに、燃焼筐８の上端には給湯器外部への排気口１８が開口している。

また、熱交換器６には、給水管２０と出湯管２２とを連通する通水路２４が巡っており、流水栓２６により、通水路への水の流入が制御される。点火装置１０、ガス元電磁弁１２、ガス給湯電磁弁１４、燃焼ファン１６および流水栓２６は、それぞれ給湯器制御部２８によって制御される。一方、給湯器制御部２８によるこれらの制御情報の履歴は後述の保守制御ユニットにより故障予兆情報として利用される。例えば、点火装置１０による点火回数のカウントは点火装置１０の寿命判定に利用される。

また、給湯器２には、給水管２０に流入する水の水温を測定する水温計３０、出湯管２２から流出する湯の温度を測定する湯温計３２、出湯管２２から流出する湯の流量を測定する流量計３４、ガスバーナ４の炎を検知する炎検知センサ３６等の各種センサが設けられており、これら各種センサによる測定結果または検知結果は給湯器制御部２８に入力される。さらに、給湯器２には、気温センサ３８が設けられており、給湯器２の運転が停止した状態で気温センサ３８の検出温度が所定の基準温度以下になったときに、給湯器制御部２８の制御により凍結防止ヒータ４０を作動させて、通水路２４の凍結を防止している。また、電源部４２は家庭用の電力線から電力供給を受けて給湯器各部にそれぞれ必要な電圧の電力を供給している。また電源部４２は入力電圧を検知する電圧計を有しその測定結果が給湯器制御部２８に入力される。図１では電源部４２の詳細図示を省略する。

給湯器制御部２８は、ＣＰＵを含む制御基板４４を有し、上記の各種センサからの情報を処理するとともに上記の給湯器２の各部の制御を実行している。また、制御基板４４は過電流検知部４６を有し、所定の過電流検知により給湯器の所定機能を遮断する。過電流検知部４６は制御基盤の通常動作における電流データも出力し、この電流データは制御基板４４の故障予兆情報として利用される。例えば、過電流と判断される閾値以下の値の定格内電流ではあるが、比較的高めの値の電流データの発生の有無、そのような高めの値の電流データの発生頻度、または電流データの値の変動パターンなどと過電流の発生との因果関係がＡＩにより分析され、過制御基板４４の故障予兆情報として利用される。その詳細については後述する。

また、給湯器制御部２８は操作パネル４８を有する。なお、給湯器２は通常は室外に設置されるが、操作パネル４８は、実際には、給湯器２から離れた室内に設置され、給湯器制御部２８との間はケーブルまたは近距離通信手段で接続されている。また、給湯器２はインターフェース５０を有し外部との情報交換が可能となっている。例えば、携帯電話等で給湯器２を遠隔操作する場合に携帯電話からの操作信号を受信するとともに給湯器２の現状を携帯電話に送信するための通信部がインターフェース５０に接続可能である。また、インターフェース５０には、給湯器が故障した場合に保守用パソコンを接続し、給湯器制御部２８との情報交換により異常を確認することが可能である。

以上説明した給湯器２は、本発明の給湯器管理システムの構成要素であり、上記のとおり管理に必要な各種センサを備えているが、これらは基本的には通常の給湯器に備わっている構成である。そして本発明の給湯器管理システムはこのような通常の給湯器２の構成をベースとし、以下に説明する保守制御ユニット５２をインターフェース５０に常時接続することによって成立する。

保守制御ユニット５２は、給湯器２に常時取り付けられるもので、給湯器２を管理するための情報処理機能を有するとともに、クラウドサービス５４との通信機能を担い、給湯器２の故障予兆の判定を行う。例えば、上記の過電流検知部４６による過電流閾値以下の値の定格内電流における比較的高めの値の電流データの発生の有無や頻度、または電流データの値の変動パターンなどが保守制御ユニット５２からクラウドサービス５４に常時送信され、クラウドサービス５４のＡＩ機能によりそのような電流データと過電流の発生との因果関係が分析され、過制御基板４４の故障予兆の判定が行われる。

さらに、保守制御ユニット５２は、通常遠隔操作のための携帯電話５６との通信機能を兼用する。以上の機能のため、保守制御ユニット５２は保守制御部５８を有し、給湯器２への取り付けによってインターフェース５０に常時接続される接続部６０を介して給湯器２と情報交換するとともに、通信部６２によりクラウドサービス５４および携帯電話５６と通信している。

保守制御ユニット５２には振動センサ６４が設けられており、給湯器２との機械的接触により伝導する給湯器２の異常振動を検知して保守制御部５８に通報する。同様にマイク６６は給湯器２が発する異音を検知し保守制御部５８に通報する。また、保守制御ユニット５２の付属品として、給湯器２には電源部４２への電流を検知する電流センサ６８が取り付けられ、給湯器２の電力消費の異常を検知して保守制御部５８に通報する。さらに、保守制御ユニット５２の付属品である排気センサ７０は、給湯器２の排気口１８に取り付けられ、不完全燃焼等の排気ガスの異常を検知して保守制御部５８に通報する。また、保守制御ユニット５２には湿度センサ７２および気圧計７４が設けられており、給湯器２の設置地域における気象状況を検知して保守制御部５８に通報する。

保守制御ユニット５２の記憶部７６は、保守制御部７６の機能に必要なプログラム、給湯器属性や設置属性などの諸データ等を記憶するとともに、上記の各種センサ等から通報される検知結果を一時記憶することにより、これらの検知結果のクラウドサービス５４への送信を中継する。電池７８は、保守制御ユニットの各部に電源を供給する。なお簡単のために図示しないが、各部への電力供給は電池７８の電圧を各部にそれぞれ必要な所定の電圧に変換する電源部を介して行われる。

また、湿度センサ７２は、給湯器２が雨露を凌ぐ屋根の下に防護されているか濡れやすい暴露状態にあるか等の設置環境の情報も提供する。気温計３８も、気象情報だけでなく、給湯器２が日陰にあるか直射日光下状態にあるか等の設置環境の情報も提供する。一方、気圧計７４は、気象状況だけでなく、平均気圧から、給湯器２が設置されている標高を判断して記憶部７６に記憶させる。この標高の情報は、空気の薄さに応じた適切な燃焼条件の情報を提供するための給湯器２の設置属性情報となる。また通信部６２は携帯電話５６との間で近距離通信も可能であり、携帯電話５６の所有者が自宅に戻って近距離通信圏内に入ったとき、携帯電話５６のＧＰＳ情報を自動受信する。受信したＧＰＳ情報は、給湯器２の設置属性情報となるとともに、ＧＰＳにより標高情報も得ることができれば上記の気圧計による標高情報と併用することができる。

図２は、図１の実施例における保守制御ユニット５２とクラウドサービス５４との情報交換に用いられる単位データのデータ構造を示す表である。クラウドサービス５４は、ビッグデータを処理して因果関係を推論するＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ；人工知能）を備えている。従って、保守制御ユニット５２からクラウドサービス５４へのデータ送信にあたっては、予断によりＡＩ自由度を縛ったりバイアスをかけたりするのを避けるため、結果的な無駄や重複は厭わず、毎回、図２に示すデータ構造を有する単位データ全体が保守制御ユニット５２からクラウドサービス５４に送信される。単位データ送信の実行は、後述する送信条件に基づいて行われる。

図２に示す単位データのデータ構造に含まれる各データ項目は、「給湯器属性」、「設置属性」、「使用履歴」、「機能停止」、「データグループ」に大区分される。「給湯器属性」は個々の給湯器固有の情報であり、変更されることはないが、個々の給湯器のＩＤ情報として、また不特定多数の給湯器群の製造時期別統計情報等に利用される。このような「給湯器属性」に大区分されるデータ項目は、給湯器の種類、製品ＩＤである。また「設置属性」は、不特定多数の給湯器群の設置環境別統計情報等に利用される。このような「設置属性」に大区分されるデータ項目は、個々の給湯器の使用開始日、設置位置および設置環境である。「設置属性」も通常は変更されることはないが、位置と環境については、住居の増改築や引越しの際に変更される可能性がある。

「使用履歴」は通常の使用において発生する種々のデータ項目で、ビッグデータの大半を占めるものである。このような「使用履歴」に大区分されるデータ項目は、水温、湯温、給湯器内の湯の循環、ガスバーナの燃焼、動作振動や動作音などの機械的要素、消費電力、動作電流である。「機能停止」は、給湯器の種々の故障状態に対応しており、予め想定される故障状態にはエラーコードが割り当てられている。「データグループ」は、時系列的にセットになっている単位データを関連付けるもので、関連する単位データに共通して付与されるグループ化指標、保守制御ユニット５２からクラウドサービス５４への単位データ送信条件、および単位データ送信日時を示すタイムスタンプを含む。単位データ送信条件の詳細については後述する。

ここで簡単に「データグループ」について補足する。通常、一回の給湯開始から停止までには、給湯開始操作に始まって、流水栓が開かれるとともに燃焼が開始して水温が上昇する經過を経て給湯が行われ、給湯停止操作に至る一連のイベントがある。また、この一連のイベントの途中で湯温の設定変更というイベントが発生する可能性もある。これら一連のイベントは予断に左右されないＡＩ分析を可能とするため、相互関係なしにバラバラの単位データとして分析するのも有益である。また、その一方で、因果関係で結ばれている可能性が大きい複数の単位データを一つの「データグループ」として把握可能として分析することも有益である。このような目的のため、一回の給湯開始から停止に至る同じ「データグループ」に属する単位データには共通の「グループ化指標」が付与される。

また、単位データの送信は、予断に左右されないＡＩ分析を可能とするため、イベントの発生と無関係に定期的に（例えば給湯継続中において想定されるイベントが何も発生していなくても５秒毎に）保守制御ユニット５２からクラウドサービス５４に送信するのが有益である。また、一方で、予め想定されるイベントの発生をトリガとして単位データを送信することも、有意データの収集のために有益である。この目的のため、「データグループ」の「単位データ送信条件」により、各単位データが何をトリガとして送信されたかを明示する。

図２における「データ内容」は各「データ項目」におけるデータの内容を示すもので、例えば、「燃焼」というデータ項目には、「点火累積回数」、「炎検知」、「燃焼ファン回転累積（累積回転時間）」、「排気成分」がまとめられている。また図２における「取得手段」は、各データ内容におけるデータの取得手段を示すもので、例えば、「点火累積回数」は給湯器制御部２８から点火装置１０への点火制御信号をカウントすることによって、「炎検知」は炎検知センサ３６によって検知される検知信号が給湯器制御部２８に入力されることによって、「燃焼ファン回転累積」は給湯器制御部２８から燃焼ファン１６に送られる回転開始信号から回転停止信号までの時間を累積カウントすることによって、「排気成分」は排気センサ７０の検知信号が給湯器制御部２８に入力されることによって、それぞれ取得される。図２における他の「データ内容」および「取得手段」の関係は、上記例示説明に準じて図２から理解できるので、個々の説明は省略する。

図３は、図２の「単位データ送信条件」として単位データに付与される種々の「履歴ＩＤ」をまとめたものである。履歴ＩＤ１から履歴ＩＤ１２は「通常動作」に区分されるもので、例えば、「履歴ＩＤ」におけるＩＤ４は、点火という「イベント」をトリガとして単位データが送信されたとき、その単位データに付与される。そしてＩＤ４を付与する際の「トリガ情報源」は、給湯器制御部２８から点火装置１０に送られる点火制御信号の発生である。換言すれば、点火制御信号が発生することをトリガにＩＤ４を付与して保守制御ユニット５２からクラウドサービス５４に単位データが送信される。このようにして、多数の給湯器の通常動作における種々のイベントをトリガとした単位データがクラウドサービス５４にビッグデータとして終結されＡＩによる分析に供される。例えば、同一の「グループデータ」において、ＩＤ４の「点火」をトリガとする単位データのタイムスタンプ（図２参照）とＩＤ５の「炎検知」をトリガとする単位データのタイムスタンプまでの時間差は点火に関連する故障予兆の情報となりうる。但し、履歴ＩＤ１から履歴ＩＤ１２は、予断に左右されないＡＩ分析を可能とするビッグデータとして各単位データそのものが判断を配してそのままクラウドサービス５４に送信される。

実施例において、保守制御ユニット５２からクラウドサービス５４に単位データを送信するトリガとなるイベントは上記の通常操作だけではない。図３の履歴ＩＤにおけるＩＤ１３からＩＤ２７は、予め想定される異常をイベントとし、これをトリガとして単位データを送信する場合をまとめたものである。例えば、ＩＤ１４のイベントである「点火−炎検知時間差」は、給湯器制御部２８から点火装置１０に送られる点火制御信号の発生からこれに後続する炎検知センサ３６炎検知から給湯器制御部２８への炎検知信号の送信までの時間をカウントし、その時間が所定基準より長いというイベントをトリガとして単位データを送信するものである。

このように、点火という観点を例にとれば、上記のＩＤ４とＩＤ５が付与された単位データが予見を排除したトリガにより送信されるのに対し、ＩＤ１４が付与された単位データは、予め想定される異常をイベントとして送信される。ＩＤ２２からＩＤ２７は想定異常の予備であり、後述のクラウドサービス５４のＡＩ分析により新たに発見追加される想定異常に当てられる。一方、クラウドサービス５４のＡＩ分析では、想定異常の追加だけでなく、エラーメッセージ発生実績に照らして不適当と判断される想定異常の廃止も行われる。また、想定異常には上記のように判断のための所定基準が設定されるが、クラウドサービス５４のＡＩ分析によりこのような所定基準の修正も行われる。

クラウドサービス５４は以上のようにして履歴ＩＤとして付与される単位データ送信条件も加味してＡＩ分析を行う。なお、上記のように、履歴ＩＤに係わらず、保守制御ユニット５２からクラウドサービス５４に送信される単位データは、常に図２に示すデータ構造を有する単位データ全体である。この意味では、履歴ＩＤは送信のトリガの別を示すに過ぎない。つまり、想定異常に区分されるものもあくまで送信トリガとしての意味しかなく、必ずしもそれ自体が故障の「予兆」ではない。つまりトリガとして利用される「想定異常」のレベルは、故障予兆の判定基準よりも低いものであり、正常範囲の上限に近いレベルのものである。例えば、ＩＤ１４が付与された「点火−炎検知時間差」において、送信トリガとなるレベルは例えば３秒以上であって、故障予兆と判断されるレベルではなく正常範囲の上限値近くのものである。これに対し、ＩＤ１４が付与された「点火−炎検知時間差」において例えば１０秒以上が検知された場合はもはや正常範囲ではなく、故障予兆のレベルとして処理される。いずれにしても、上記のように各イベントについて履歴ＩＤを付与することは、ＡＩ分析への有用な情報となる。

さらに、図３の履歴ＩＤにおけるＩＤ２８は、実際に機能停止に至ったエラーメッセージの発生をトリガとして単位データを送信する場合に付与される。このとき、図２の単位データのデータ構造における大区分「機能停止」のデータ内容には「エラーコード」が含まれる。クラウドサービス５４は、多数の給湯器から提供されるビッグデータに基づき、このように実際に生じてしまった故障をトリガとする単位データと、まだ故障には至らない図３の履歴ＩＤ１から履歴ＩＤ２２をトリガとする単位データとの因果関係をＡＩ分析し、履歴ＩＤ１から履歴ＩＤ２７をトリガとする単位データに基づく故障予兆の判定を行い、個々の給湯器にフィードバックする。

また、保守制御部５８は、後述のように、図３に示したイベントの発生をトリガとして単位データを送信するだけでなく、所定時刻の到来をトリガに（例えば一分經過毎に）単位データをクラウドサービス５４に送信する。これによって、例えば、特にイベントの発生なしに給湯器２がガスの燃焼を伴って給湯を継続している場合においても、例えば一分ごとに単位データが送信され、クラウドサービス５４は、想定されるイベントや異常の発生というトリガがなくても給湯器動作中の単位データを収集することができる。そして、図３に示したイベントの発生と所定時刻の到来を単位データ送信のトリガとして併用することで、適切かる効率のよい単位データの送信を行うことができる。

図４は、上記実施例における保守制御部５８の動作を説明する基本フローチャートである。なお、図４のフローは主に保守制御ユニット５２とクラウドサービス５４との情報交換（得に保守制御ユニット５２からクラウドサービス５４への情報送信）について説明するため、関連する機能を中心に動作を抽出して図示している。従って、保守制御ユニット５２と携帯電話５６との通信による給湯器２の通常の遠隔操作の詳細等、図４のフローに表記していない保守制御部５８の動作も存在する。

図４のフローは、電池７８からの保守制御ユニット５２への電源供給でスタートし、ステップＳ２において記憶部７６から図２に示す給湯器属性データを取得する処理を行う。次いで、ステップＳ４で記憶部７６から図２に示す設置属性のデータを取得する処理を行って、ステップＳ６に移行する。ステップＳ６以降では、図３に示す種々のイベントの発生の有無がチェックされる。まずステップＳ６では、図３に示す異常状態の発生によって給湯器２が機能停止状態にあるか否かがチェックされ、該当しなければステップＳ８に移行する。ステップＳ８では、図３に示す想定異常に該当するイベントが発生しているか否かがチェックされ、該当しなければステップＳ１０に移行する。ステップＳ１０では、図３に示す通常動作に該当するイベントが発生しているか否かがチェックされる。

ステップＳ１０で通常動作イベントの発生が検知されるとステップＳ１２に進み、検知した通常動作イベントの履歴ＩＤを検知結果に付与してステップＳ１４に進む。ステップＳ１４では、検知した通常動作イベントが給湯開始操作か否かチェックし、該当すればステップＳ１６に進む。記憶部７６は給湯レジスタを有し、図２に示すデータグループの給湯ＩＤを示す数字を記憶しているが、ステップＳ１６ではこの給湯レジスタ内の給湯ＩＤの数値を一つインクリメントしてステップＳ１８に移行する。例えば給湯レジスタ内の給湯ＩＤが「１１５」であれば、ステップＳ１４からステップＳ１６に至ることで給湯レジスタ内の給湯ＩＤが「１１６」にインクリメントされる。一方、ステップＳ１４で通常動作イベントが給湯開始操作でなかったときは直接ステップＳ１８に至るので、上記の例では、給湯レジスタ内の給湯ＩＤは「１１５」のままとなる。

ステップＳ１８では、給湯レジスタ内の給湯ＩＤを検知した通常動作イベントに付与してステップＳ２０に移行する。これによって、ステップＳ１４で検知されるのが給湯開始操作でない限り、検知した通常イベントには同じ給湯ＩＤ（上記の例では給湯ＩＤ「１１５」）が付与され、同じデータグループ内のイベントデータとして認識される。このようにして、一回の給湯開始操作に後続する通常操作が一連のイベントとして関連付けて処理される。一方、ステップＳ１４で検知されるのが給湯開始操作であった場合は、上記の例では、後続する一連の通常操作には、以後、給湯ＩＤ「１１６」が付与されていくことになる。

ステップＳ２０では、図２に示す単位データ内の全項目が記憶部７６から取得されるとともに、ステップＳ２２に進んで通信部６２からクラウドサービス５４に取得したデータを送信し、ステップＳ２４に移行する。一方、ステップＳ１０で通常動作イベントが検知されなかったときはステップＳ２６に進み、定期的なデータ送信のために設定されている所定時刻が到来しているか否かチェックする。そして所定時刻であればステップＳ２０に移行し、上記と同様にステップＳ２０で所定時刻での単位データ内の全項目を取得し、ステップＳ２２に進んでクラウドサービス５４に送信する。これに対し、ステップＳ２６で所定時刻が到来していなければ直接ステップＳ２４に移行する。

また、ステップＳ８で、想定異常イベントが検知されれば、ステップＳ２８に進み、図３に示す想定異常イベントのイベント履歴ＩＤを付与してステップＳ２０に移行する。そして上記と同様にして、想定異常イベント発生時の単位データ内の全項目を取得し、ステップＳ２２に進んでクラウドサービス５４に送信する。一方、ステップＳ６で機能停止が検知されたときは、ステップＳ３０に移行し、機能停止の原因に基づいて発生しているエラーメッセージを記憶部７６から取得してステップＳ３０に進む。ステップＳ３２では、発生したエラーが所定の回復操作（操作マニュアルに示された手順に従う）により回復可能か否かチェックされ、回復可能であればステップＳ３４に進んで回復履歴を記憶部７６から取得してステップＳ２０に進む。そして上記と同様にして、回復後の単位データ内の全項目を取得し、ステップＳ２２に進んでクラウドサービス５４に送信する。これに対し、ステップＳ３２でエラー回復が不可能であれば、ステップＳ２２に進み、エラーメッセージをクラウドサービス５４に送信して、ステップＳ２４に移行する。

また、ステップ２４では、引越し等によるＧＰＳ情報の変化の有無をチェックし、変化があればステップＳ４に移行して記憶部７６から設置属性データを再取得する処理を行った上で図４のフローの繰り返しに入る。これに対し、ステップＳ２４でＧＰＳの変化が検知されないときはステップＳ３６に進み保守制御部５８への電源供給が立たれたか否かチェックする。そして電源供給が継続していればステップＳ６に戻り以下、図４のフローの繰り返しに入る。一方、ステップＳ３６で電源断が検知されたときはフローを終了する。

図５は、クラウドサービス５４で実行される機能を説明する基本フローチャートであり、システムの起動または再起動によりスタートする。システムが起動または再起動されると、まずステップＳ４２でシステムの初期化およびデータ回復処理を行う。次いでステップＳ４４で、管理下にある多数の給湯器における各保守制御ユニットからの単位データ受信に対応するための処理を行い、クラウドサービスの機能を開始してステップＳ４６に移行する。

ステップＳ４６では、いずれかの給湯器における保守制御ユニットから単位データを受信下か否かチェックする。受信があればステップＳ４８に進み、受信データをシステム内に蓄積してステップＳ５０に移行する。ステップＳ５０では、新たに蓄積した受信データについて図２の給湯器属に関するデータを暗号化し、単位データをビッグデータの一つとして処理する際のプライバシー保護を行い、ステップＳ５２に移行する。一方、ステップＳ４６で単位データの受信がない場合は直接ステップＳ５２に移行する。

ステップＳ５２では、クラウドシステム内に蓄積された単位データについてＡＩ分析処理を行う。ＡＩ処理には後述のフィードバック処理および各給湯器の故障予兆判定が含まれるが、その詳細は後述する。なお、ステップＳ５２におけるフィードバック処理は後述するフィードバック処理割当時間が経過すると中断され、各給湯器の故障予兆判定が完了するとステップＳ５４に移行する。後述のように図５のフローは繰り返されるので、ステップＳ５２に至る都度、前回まで進行したフィードバック処理を割当時間だけ続行することが繰り返される。

ステップＳ５４では、ステップＳ５２におけるビッグデータのＡＩ分析の結果として有意の修正フィードバック（改廃を含む想定異常イベントの修正または故障予兆基準の修正のためにフィードバックすべき有意の判断）が導かれたか否かチェックする。修正フィードバックが導かれた場合は、ステップＳ５６に移行して想定異常イベントを修正するとともに、管理下の各給湯器に送信する。これを受信した各給湯器は図３の想定異常を修正し、以後のクラウドシステムへの送信トリガを修正することができる。次いで、ステップＳ５８では故障予兆基準を修正し、ステップＳ６０に移行する。なお、ステップＳ５６およびステップＳ５８の一方において該当する修正がない場合は何もせずに次のステップに移行する。一方、ステップＳ５４で修正フィードバックが導かれたことが検知されない場合は直接ステップＳ６０に移行する。

ステップＳ６０では、ステップＳ５２におけるビッグデータのＡＩ分析の結果としていずれかの給湯器における故障予兆判定が発生したか否かがチェックされる。故障予兆判定の発生があればステップＳ６２に移行して発生した故障予兆判定の履歴をシステム内に蓄積してステップＳ６４に移行する。ステップＳ６４では故障予兆判定発生の対象となった給湯器について暗号化していた給湯器属性を復号する処理を行い、ステップＳ６６において対象給湯器機に対し判定された故障予兆を通知してステップＳ６８に移行する。この故障予兆情報には想定される故障発生予測日および故障発生の確率も付記される。一方、ステップＳ６０で 故障予兆判定の発生が検知されない場合は直接ステップＳ６８に移行する。

ステップＳ６８では、以上の処理結果についてのデータバックアップ処理を行い、ステップＳ７０に移行する。ステップＳ７０ではクラウドサービスがシステムダウンしたか否かがチェックされ、システムダウンがなければステップＳ４６に戻って、以下システムダウンしない限り、ステップＳ４６からステップＳ７０を繰り返す。一方ステップＳ７０でシステムダウンが検知されるとフローを終了する。

なお、以上説明したクラウドシステムの各機能は、説明の便宜上、図５では、直列的に処理するフローとして記載しているが、実際には各機能は並列処理され、その実行に当たっては、多数の大型コンピュータが連携する。このことは、以下に示す図６から図８でも同様である。

図６は、図５のステップＳ５２におけるＡＩ分析処理の詳細を示すフローチャートであり、上記のようにフィードバック処理および各給湯器の故障予兆判定が含まれる。フローがスタートするとステップＳ７２で新規の単位データが受信蓄積されたか否かチェックされ、新規単位データがあればステップＳ７４に進んでその単位データをＡＩ分析対象に加入し、ステップＳ７６に移行する。一方、ステップＳ７２で新規単位データの受信蓄積が検知されない場合は直接ステップＳ７６に移行する。

ステップＳ７６では、単位データ群が構成するビッグデータのＡＩ分析による想定異常フィードバック処理が行われ、想定異常の修正に必要な分析を行う。その詳細は後述する。次いで、ステップＳ７８では、単位データ群が構成するビッグデータのＡＩ分析による故障予兆基準フィードバック処理が行われ、故障予兆基準の修正に必要な分析を行ってステップＳ８０に一向する。ステップＳ７８の故障予兆基準フィードバック処理の詳細についても後述する。これらステップＳ７６、７８のフィードバック処理はそれぞれ短時間（前述の「フィードバック処理割当時間」よりも短い）の単位処理に分割して順次実行され、各単位処理が完了すると次のステップに移行するようになっている。

ステップＳ８０では、最初のステップＳ７６への移行の後、フィードバック処理割当時間が経過したか否かチェックされ、時間経過がなければステップＳ７６に戻って、ステップＳ７６、７８の単位処理を順次継続する。一方、ステップＳ８０でフィードバック処理割当時間経過が検知されると、フィードバック処理を中断してステップＳ８２に移行する。以上が、ＡＩ分析処理におけるフィードバック処理に相当する。

ステップＳ８２からは、ＡＩ分析処理における各給湯器の故障予兆判定処理に相当する。まずステップＳ８２では、管理下にある多数の給湯器の中から故障予兆判定の対象とする給湯器を一つ選択する。次いで選択された給湯器について、ステップＳ８４で想定異常イベントと故障予兆基準との対比が行われる。この対比は、図３における想定異常ＩＤが付与されたイベントにおいてデータの逸脱のレベルが故障予兆レベルに達しているか否かの対比となる。例えば、前述のＩＤ１４の「点火−炎検知時間差」が予め定められている故障予兆基準である１０秒を超えていれば、ステップＳ８４において故障予兆の判定がなされる。

次いで、ステップＳ８６では、図２のクループ化指標において同一の給湯ＩＤが付与されている一連の単位データ群と故障予兆基準との対比が行われる。例えば、図２における給湯ＩＤとして同じＩＤ「１１５」が付与され一連の単位データ群において、イベント履歴ＩＤ１３の「流水栓開−点火時間差逸脱」、イベントＩＤ１６の「流量逸脱」、およびイベントＩＤ１９の「異常音逸脱」をそれぞれトリガとする単位データの組み合わせすべてが含まれていることが予め設定されている故障予兆基準に合致していれば、そのそれぞれのレベルが正常範囲であっても、ステップＳ８６において故障予兆の判定がなされる。

さらに、ステップＳ８８では、個別単位データと故障予兆基準との対比が行われる。例えば、図２データを備えた単一の単位データの中の点火累積回数が故障予兆基準として予め設定されている平均寿命回数に近いレベルに達していると判断されると、ステップＳ８８において故障予兆の判定がなされる。

以上の、ステップＳ８４からステップＳ８８のいずれかにおいて故障予兆判定がなされた場合、図５のステップＳ６０からステップＳ６６を通じて、該当する給湯器の保守制御ユニットに故障予兆の通知が行われる。

ステップＳ８２で選択された特定の給湯器についてステップＳ８４からステップＳ８８の処理を行った後、フローはステップＳ９０に移行し、管理下にある全対象給湯器について故障予兆判定を完了したか否かチェックする。完了でなければ、ステップＳ８２に戻り、残りの給湯器の中から次の故障予兆判定の対象とする給湯器を一つ選択する。以下、ステップＳ９０において全対象給湯器について故障予兆判定を完了したことが確認されるまで、ステップＳ８２からステップＳ９０を繰り返す。一方、ステップＳ９０で全対象給湯器故障予兆判定完了が確認されるとフローを終了し、図５のステップＳ５４に移行する。

図７は、図６のステップＳ７６における想定異常フィードバック処理の詳細を示すフローチャートである。想定異常フィードバック処理は、イベントとして設定される想定異常の適否をエラー発生実績と対比してフィードバックする処理である。フローがスタートすると、ステップＳ９２でいずれかの給湯器から新規にエラーコードが発生した事例の有無をチェックする。事例があればステップＳ９４に移行し、発生した事例をＡＩ分析対象に加入してステップＳ９６に移行する。一方、ステップＳ９２で新規なエラーコード発生事例が検知されなければ直接ステップＳ９６に移行する。この場合は既存のエラーコード発生事例のみがＡＩ分析対象となる。上記においてステップＳ９４を経由する場合でも経由しない場合でもＡＩ分析に対象となるのは、管理下の多数の給湯器から収集したエラーコード発生事例群のビッグデータである。

ステップＳ９６では、分析対象を給湯器属性データによって抽出した同一給湯器からの単位データに絞り、ステップＳ９８でエラーコード発生事例と同一給湯器からの単位データ群との相関発見処理を行う。この処理は、同一給湯器においてエラーコード発生とその原因情報が含まれると考えられる単位データ群との直接的な相関を分析するものである。

次いで、ステップＳ１００では、分析対象を給湯器属性にかかわらない全ての単位データ群とする。そしてステップＳ１０２に進み、同一のエラーコードが発生している給湯器群を週出し、ステップＳ１０４で抽出した給湯器群に関する想定異常イベント群との相関を分析する。この結果、ステップＳ１０６にいたって想定異常の設定（図３のＩＤ１３からＩＤ２１参照）を修正（削除を含む）する必要が生じればステップＳ１０８に進み、想定異常修正フィードバックデータを作成してステップＳ１１０に移行する。一方、ステップＳ１０６で想定異常設定の修正を要する判断が得られなければ直接ステップＳ１１０に移行する。

ステップＳ１１０ではエラーコード発生と通常動作データとの相関関係を発見するための分析処理が行われる。また、ステップＳ１１２では、エラーコード発生と設置属性データとの相関関係を発見するための分析処理が行われる。異常の処理を経てステップＳ１１４に進み、新規な想定異常イベントが発見されたときはステップＳ１１６で想定異常を新規に追加すべきフィードバックデータを作成してフローを終了し、図６のステップＳ７８に移行する。一方、ステップＳ１１４で新規な想定異常イベントが発見されたことが検知できないときは直ちにフローを終了し、図６のステップＳ７８に移行する。

図８は、図６のステップＳ７８における故障予兆基準フィードバック処理の詳細を示すフローチャートである。故障予兆基準フィードバック処理は、故障予兆基準の適否をエラー発生実績と対比してフィードバックする処理である。フローがスタートすると、ステップＳ１２２でいずれかの給湯器から新規にエラーコードが発生した事例の有無をチェックする。事例があればステップＳ１２４に移行し、発生した事例をＡＩ分析に加入してステップＳ１２６に移行する。一方、ステップＳ９２で新規なエラーコード発生事例が検知されなければ直接ステップＳ１２６に移行する。

ステップＳ１２６では、故障予兆判定基準に合致すると判定した事例とエラーコードが発生した事例との相関分析処理を行ってステップＳ１２８に移行する。クラウドシステムから図５のステップＳ６６に示す故障予兆通知を受けたとき、給湯器がそのアドバイスに従って対策（修理や部品交換）を実施した場合は、その後のエラーコード発生が回避されるので、エラーコード発生実績は存在しない。これに対し、仮に故障予兆通知を受けた給湯器がこの通知を無視して使用を続けた場合、故障予兆情報に付記された故障発生予測日前後に故障が発生する可能性が高い。また故障予測の確率が高いほどその可能性も高まる。ステップＳ１２６の分析はこのような事態に収集されるエラーコード発生事例に基づいて行われる。そして、以下に示す故障予兆基準フィードバックを通じ、故障予兆基準（故障発生予測日情報を含む）の信頼性が高められ、付記される確率も大きくなる。そして、信頼性の向上（予測確率の向上）に伴い、故障予兆通知に基づいて対策をとる事例が増えていくことになる。この場合、相関分析に供される故障実績データが減ることになるが、ステップＳ１２６と同様の相関分析は、クラウドシステム側で別途収集される商品耐久性試験データに基づいても行われ、故障予知判定基準の信頼性の向上が図られる。

ステップＳ１２８では、ステップＳ１２８の相関分析処理に基づき、エラーコード発生事例と故障予兆判定基準の相関が低い場合（故障予兆判定をしたにもかかわらず実際に故障が発生しない場合）を判定し、該当する故障予兆判定基準があったときはステップＳ１３０に進んでその故障予兆判定基準を削除し、ステップＳ１３２に移行する。一方、ステップＳ１２８で低相関故障予知判定基準が検知されない場合は、直接ステップＳ１３２に移行する。

ステップＳ１３２では、ステップＳ１２８の相関分析処理に基づき、想定異常に関連して修正を必要とする故障予知判定基準（図６のステップＳ８４で用いられる判定基準）の有無をチェックする。該当する故障予兆判定基準があったときはステップＳ１３４に進んでその故障予兆判定基準の修正（関連する想定異常の修正、または異常レベルの修正）を行い、ステップＳ１３６に移行する。一方、ステップＳ１３２で想定異常関連要修正故障予兆判定基準が検知されない場合は、直接ステップＳ１３６に移行する。

ステップＳ１３６では、ステップＳ１２８の相関分析処理に基づき同一給湯ＩＤの単位データに関連して修正を必要とする故障予知判定基準（図６のステップＳ８６で用いられる判定基準）の有無をチェックする。該当する故障予兆判定基準があったときはステップＳ１３８に進んでその故障予兆判定基準の修正（関連する同一給湯ＩＤ因果関係の修正、または異常レベルの修正）を行い、ステップＳ１４０に移行する。一方、ステップＳ１３６で同一給湯ＩＤ関連要修正故障予兆判定基準が検知されない場合は、直接ステップＳ１４０に移行する。

ステップＳ１４０では、ステップＳ１２８の相関分析処理に基づき、個別の単位データに関連して修正を必要とする故障予知判定基準（図６のステップＳ８８で用いられる判定基準）の有無をチェックする。該当する故障予兆判定基準があったときはステップＳ１４２に進んでその故障予兆判定基準の修正（関連するデータ項目の修正、または異常レベルの修正）を行い、ステップＳ１４４に移行する。一方、ステップＳ１４０で個別単位データ関連要修正故障予兆判定基準が検知されない場合は、直接ステップＳ１４４に移行する。

ステップＳ１４４では、既存の故障予兆判定基準と相関のないエラーコードが発生したか否かチェックする。該当するエラーコードが発生したときはステップＳ１４６に進み、エラーコードとビッグデータとしての単位データ群との相関を分析する処理を行う。そしてステップＳ１４８で新たに有意の相関が発見されたか否かをチェックし、発見があればステップＳ１５０に進んで新故障予兆判定基準を加入システム内に加入し、フローを終了して図６のステップＳ８０に移行する。一方、ステップＳ１４８で新有意相関発見が検知できなければ、直ちにフローを終了する。また、ステップＳ１４４において既存故障予兆判定基準と相関のないエラーコードの発生が検知できない場合も直ちにフローを終了する。

なお、上記の実施例において、同一家庭内で給湯器を買い替えた場合、図２における設置属性の「位置」のデータをキーに旧機種で蓄積した単位データが分析に関連付けられる。これは、同一家庭で使用される場合、同一の利用傾向にて新機種が使用される可能性があるためであり、このような関連付けにより、有意の分析情報としての活用が期待できる。

また、同じ給湯器が引越し等によって異なる設置属性に更新された場合も、給湯器属性により旧設置位置において蓄積した単位データが分析に関連付けられる。これも、同一家庭における同一の利用傾向が新たな設置属性との関連で有意の分析情報としての活用が期待できるからである。

以上説明した本発明の種々の特徴は、上記の実施例による実施に限るものではなく、他の実施形態が可能である。また、その利点を活用するため、他の実施形態の特徴と適宜組み合わせまたは交換することができる。例えば、上記実施例の給湯器は簡単のため燃焼室が一つの一体構成として説明されているが、風呂の給湯器等のような適宜分離型の構成をとるもの、または、風呂給湯用と炊事給湯用等複数の燃焼室を有する給湯器システムにも適用することができる。また、上記実施例においては、設置属性は各種センサからの情報やＧＰＳ情報によって自動入力されているが、住所情報などを手動入力してもよい。

さらに、上記実施例により説明した給湯器とクラウドサービスとの連携は、給湯器以外の機器とクラウドサービスとの連携にも適宜活用することができる。

本発明は、ＩｏＴを活用した管理システムおよびこれを応用した給湯器データ送信システムに適用することができる。

２ 多数の機器
５４ クラウドシステム
７６ データ保持部
５８ 制御部
４４ 制御基板
２ 給湯器
５０ インターフェース
５２ 制御ユニット
５６ 携帯電話
１８ 排気口
７０ 排気センサ
６８ 電流センサ
６６ マイク
６４ 振動センサ
７４ 気圧計

Claims (16)

1. 複数の機器とこれを管理するクラウドシステムによるＩｏＴを活用した管理システムにおいて、前記複数の機器はそれぞれ複数のデータ項目を含む単位データを保持するデータ保持部と、前記複数のデータ項目の少なくとも一つの変化を送信トリガとして前記単位データ全体を前記データ保持部から前記クラウドシステムに送信する制御部とを有し、前記単位データは、前記クラウドシステムにビッグデータとして集結され、前記クラウドシステムは、前記ビッグデータを処理して複数の単位データ間の因果関係を推論するＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ；人工知能）を備えることを特徴とするＩｏＴを活用した管理システム。
2. 前記制御部は、前記機器における通常機能に伴う前記複数のデータ項目の少なくとも一つの変化を前記送信トリガとして前記単位データ全体を前記クラウドシステムに送信するとともに前記通常機能以外に伴う前記データ項目の変化については前記送信トリガとしないことを特徴とする請求項１記載のＩｏＴを活用した管理システム。
3. 前記制御部は、前記複数のデータ項目の少なくとも一つにおける異常レベル以下であるが所定レベル以上の変化を前記送信トリガとして前記単位データ全体を前記クラウドシステムに送信することを特徴とする請求項１または２記載のＩｏＴを活用した管理システム。
4. 前記クラウドシステムは、前記複数の機器から送信される前記単位データのＡＩ分析により前記送信トリガとなるデータ項目を修正し、前記複数の機器にそれぞれフィードバックすることを特徴とする請求項３記載のＩｏＴを活用した管理システム。
5. 前記複数の機器は、それぞれ制御基板を有し、前記制御基板において過電流と判断される閾値以下の値の定格内電流範囲内における所定以上の電流データの発生の有無、前記電流データの発生頻度、および前記電流データの値の所定の変動パターンの少なくとも一つを前記送信トリガとして前記単位データ全体を前記クラウドシステムに送信することを特徴とする請求項３または４記載のＩｏＴを活用した管理システム。
6. 前記制御部は、関連する一連の送信トリガに基づいて前記クラウドシステムに複数回送信する複数の単位データをグループ化する共通の指標を前記複数回送信する前記複数の単位データにそれぞれ付与することを特徴とする請求項１から５のいずれかに記載のＩｏＴを活用した管理システム。
7. 前記クラウドシステムは、前記複数の機器から送信される前記単位データのＡＩ分析にり前記複数の機器の故障予兆を判定することを特徴とする請求項１から６のいずれかに記載のＩｏＴを活用した管理システム。
8. 前記クラウドシステムは、前記複数の機器から送信される前記単位データのＡＩ分析により前記複数の機器の故障予兆を判定する基準を修正することを特徴とする請求項７記載のＩｏＴを活用した管理システム。
9. 前記制御部は、さらに、所定時刻の到来を送信トリガとして前記データ保持部から前記単位データ全体を前記クラウドシステムに送信することを特徴とする請求項１から８のいずれかに記載のＩｏＴを活用した管理システム。
10. 前記複数の機器は、前記機器が故障した場合に保守用パソコンを接続するためのインターフェースをそれぞれ有するとともに、前記クラウドシステムに前記単位データを送信するための制御ユニットが前記インターフェースに接続可能であることを特徴とする請求項１から９のいずれかに記載のＩｏＴを活用した管理システム。
11. 前記制御ユニットに、前記機器の遠隔操作のための携帯電話との通信機能を備えたことを特徴とする請求項１０記載のＩｏＴを活用した管理システム。
12. 前記複数の機器はそれぞれ給湯器であり、前記給湯器は排気口を有し、前記排気口からの排気を検知するとともに前記給湯器に設置される排気センサが前記制御ユニットに接続可能であることを特徴とする請求項１０または１１記載のＩｏＴを活用した管理システム。
13. 前記機器に給電される電流を検知する電流センサを有し、前記電流センサが前記制御ユニットに接続可能であることを特徴とする請求項１０から１２のいずれかに記載のＩｏＴを活用した管理システム。
14. 前記制御ユニットは、前記機器が発する異音を検知するためのマイクを有し、前記マイクからの情報を前記クラウドシステムに送信することを特徴とする請求項１０から１３のいずれかに記載のＩｏＴを活用した管理システム。
15. 前記制御ユニットは、前記機器の振動を検知する振動センサを有し、前記振動センサからの情報を前記クラウドシステムに送信することを特徴とする請求項１０から１４のいずれかに記載のＩｏＴを活用した管理システム。
16. 前記制御ユニットは、気圧計を有し、前記気圧計に基づく情報を前記クラウドシステムに送信することを特徴とする請求項１０から１５のいずれかに記載のＩｏＴを活用した管理システム。

Images