(57)【要約】【課題】  給湯システム使用上の支障を生じさせることなく、最適なメンテナンス体制を提供することができる給湯システム及び遠隔監視システムを提供する。【解決手段】  深夜等の第１時間帯にエラー検知情報をうけたとき（Ｓ１，Ｓ４でＹＥＳ）、エラー内容が重度であれば、即座に報知する（Ｓ５でＹＥＳ，Ｓ３）。一方、エラー内容が軽度であれば、稼働可能情報（運転可能な連結台数）から稼働実績情報（最大稼働台数）を減じた差分が判定基準値以上であれば、給湯要求に対し余裕度が大きく、メンテナンスの緊急性はないものと判定し、報知処理を翌日の日中等の第２時間帯が到来するまで保留して遅延させる。【選択図】図４
2016217671.tif 000002
【特許請求の範囲】
【請求項１】
複数の給湯器を備え、これら複数の給湯器の台数制御を行う給湯システムにおいて、
メンテナンスのための報知処理を実行する制御手段を備え、
前記制御手段は、運転可能な給湯器の合計給湯能力から実際の稼働における最大稼働給湯能力を減じた差分の演算、又は、運転可能な給湯器の連結台数から実際の稼働における最大稼働実績台数を減じた差分の演算を行い、この演算結果に基づいて前記メンテナンスのための報知処理を実行するか否かを決定するように構成されている、
ことを特徴とする給湯システム。
【請求項２】
請求項１に記載の給湯システムであって、
前記制御手段は、メンテナンスに要する負荷が重負荷となる時間帯として予め設定した第１時間帯において、前記複数の給湯器のいずれかについてエラー発生を検知したことのエラー検知情報を受けたとき、前記演算された差分が所定の判定基準値よりも大きければ、前記メンテナンスのための報知処理の実行を、メンテナンスに要する負荷が低負荷となる時間帯として予め設定した第２時間帯の到来まで遅延させるように構成されている、給湯システム。
【請求項３】
請求項２に記載の給湯システムであって、
前記制御手段は、前記演算結果についても併せて報知処理するように構成されている、給湯システム。
【請求項４】
それぞれ個別制御部を有する複数の給湯器及びこれら複数の給湯器の個別制御部と通信接続されて台数制御を行う統括制御部を備えた給湯システムと、管理サーバと、前記給湯システムの前記個別制御部もしくは前記統括制御部を前記管理サーバに対しネットワークを介して通信接続するための中継装置と、前記管理サーバと前記ネットワークを介して通信接続される通信端末装置とを備えた遠隔監視システムであって、
前記管理サーバは、前記給湯システムに係る情報を蓄積・更新する記憶部を備え、
前記個別制御部、前記統括制御部、前記中継装置、前記管理サーバ及び前記通信端末装置の内のいずれかが、前記給湯システムのメンテナンスのための報知処理を実行する制御手段を備え、
前記制御手段は、前記記憶部からの情報を受けて、運転可能な給湯器の合計給湯能力から実際の稼働における最大稼働給湯能力を減じた差分の演算、又は、運転可能な給湯器の連結台数から実際の稼働における最大稼働実績台数を減じた差分の演算を行い、この演算結果に基づいて前記メンテナンスのための報知処理を実行するか否かを決定するように構成されている、
ことを特徴とする遠隔監視システム。
【請求項５】
請求項４に記載の遠隔監視システムであって、
前記制御手段は、メンテナンスに要する負荷が重負荷となる時間帯として予め設定した第１時間帯において、前記複数の給湯器のいずれかについてエラー発生を検知したことのエラー検知情報を受けたとき、前記演算された差分が所定の判定基準値よりも大きければ、前記メンテナンスのための報知処理の実行を、メンテナンスに要する負荷が低負荷となる時間帯として予め設定した第２時間帯の到来まで遅延させるように構成されている、遠隔監視システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の給湯器を備え、これら複数の給湯器の台数制御を行う給湯システム及びこの給湯システムの遠隔監視システムに関し、例えばエラー検知を受けたとき、要メンテナンスである旨の報知処理を、運転可能な給湯器の給湯能力や給湯器の台数と、実際に稼働している最大実績給湯能力や最大実績給湯台数との比較に基づいて、実行するか否かを決定するための技術に係る。
【背景技術】
【０００２】
従来、給湯器に対する各種処理を実行するか否かを決定する際に、その給湯器の状況を判断するための技術が開示されている。例えば、下記の特許文献１には、給湯器の余命期間を給湯器の使用履歴情報に基づいて査定する手法が記載されている。すなわち、その給湯器の制御部と査定用のサーバーとを通信接続し、給湯器側から使用履歴情報を読み出し、その使用履歴情報と給湯器の寿命値との差に基づいて給湯器の余命期間をサーバー側で算出することが記載されている。又、特許文献２には、家電の累積使用時間が予め定めた寿命時間に到達したとしても、外気温が設定温度よりも高ければ家電の運転を強制停止する一方、外気温が設定温度よりも低ければ家電の運転を自動継続させることが記載されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００２−１４９８６５
【特許文献２】特許第４９３７７０６
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、複数の給湯器を備えた給湯システムの場合、いずれか１台についてでもエラー検知があれば、それをユーザーに報知（例えばリモコンに表示）することで、サービスマンがメンテナンスのために来訪して対処することが行われている。又、近年、これを自動化し、通信による遠隔監視によってユーザーの手を煩わせることとなく対処することも可能になっている。この場合、エラー検知が発生すると、そのエラー検知は昼・夜の時間帯の如何を問わず通信回線を介して伝えられ、このエラー検知を受けたサービスマンは時間帯の如何を問わず、たとえ深夜であってもメンテナンスのために対処することになる。
【０００５】
しかしながら、前記の給湯システムの場合、いずれか給湯器が故障したとしても、他の給湯器でバックアップが可能な場合もあり、このような場合にはメンテナンスの緊急性はないものと考えられる。又、ユーザーの側も、給湯要求に対し給湯システム全体として正常に作動していれば、たとえいずれかの給湯器が故障（エラー発生）していたとしても、早急なメンテナンスの必要性はなく、夜中等にメンテナンスのためにサービスマンの来訪は迷惑なことも考えられる。これらの事情を勘案して最適なメンテナンス体制を構築する上で、各種の状況把握や自動化に係る技術の開発が要請される。
【０００６】
本発明は、このような事情に鑑みてなされたものであり、その目的とするところは、給湯システム使用上の支障を生じさせることなく、最適なメンテナンス体制を提供することができる給湯システム及び遠隔監視システムを提供することにある。
【課題を解決するための手段】
【０００７】
前記目的を達成するために、給湯システムに係る第１の発明として次の技術的手段を講じた。
【０００８】
すなわち、複数の給湯器を備え、これら複数の給湯器の台数制御を行う給湯システムを対象にして、メンテナンスのための報知処理を実行する制御手段を備えることとし、前記制御手段として、運転可能な給湯器の合計給湯能力から実際の稼働における最大稼働給湯能力を減じた差分の演算、又は、運転可能な給湯器の連結台数から実際の稼働における最大稼働実績台数を減じた差分の演算を行い、この演算結果に基づいて前記メンテナンスのための報知処理を実行するか否かを決定する構成とした（請求項１）。
【０００９】
第１の発明の場合、運転可能な給湯器の合計給湯能力から実際の稼働における最大稼働給湯能力を減じた差分の演算、又は、運転可能な給湯器の連結台数から実際の稼働における最大稼働実績台数を減じた差分の演算により得られる差分が要求される給湯に対する余裕度を表すことになる。従って、演算により得られた差分が大きな余裕度を表すものであれば、たとえエラーが発生して検知されたとしても、そのエラーを解消するためのメンテナンスの緊急性はない又は低いものと判定することができる。このため、メンテナンスのための報知処理を即座には実行しないものとすることにより、そのような緊急性の無い又は低い場合にも時間の如何に拘わらず即座に報知処理を実行することによるデメリットの発生を回避し得ることになる。
【００１０】
前記発明の給湯システムにおいて、制御手段として、メンテナンスに要する負荷が重負荷となる時間帯として予め設定した第１時間帯において、複数の給湯器のいずれかについてエラー発生を検知したことのエラー検知情報を受けたとき、演算された差分が所定の判定基準値よりも大きければ、メンテナンスのための報知処理の実行を、メンテナンスに要する負荷が低負荷となる時間帯として予め設定した第２時間帯の到来まで遅延させるように構成することができる（請求項２）。このようにすることにより、本発明がより明確化する。すなわち、エラー検知情報を前記第１時間帯に受けた場合に、前記差分が所定の判定基準値よりも大きくて、給湯要求に対し余裕度が所定以上に大きければ、低負荷でメンテナンスを行い得る第２時間帯が到来するまで報知処理を遅延させることで、例えば深夜等にメンテナンス対応を依頼するという過度の対応を回避して、人的・経済的な負担を軽減しつつ必要なメンテナンス対応をも満足させ得ることになる。
【００１１】
又、制御手段として、演算結果についても併せて報知処理するように構成することができる（請求項３）。このようにすることにより、稼働実績情報や稼働可能情報に基づく余裕度をも併せて報知されるため、メンテナンス時に、これらの情報に基づいて、余裕度が大幅に大きければ、エラー検知された給湯器を修理等せずに給湯システムから切り離して、給湯システムを構成する連結台数を減らすことをユーザーに対し提案することが可能となる。これにより、給湯システムの稼働状況が分かるため、メンテナンス（修理）するだけの対応ではなく、ユーザーに対し以後の経費節減等のアドバイスを行うことも可能となし得る。
【００１２】
又、遠隔監視システムに係る第２の発明として次の技術的手段を講じた。
【００１３】
すなわち、それぞれ個別制御部を有する複数の給湯器及びこれら複数の給湯器の個別制御部と通信接続されて台数制御を行う統括制御部を備えた給湯システムと、管理サーバと、前記給湯システムの前記個別制御部もしくは前記統括制御部を前記管理サーバに対しネットワークを介して通信接続するための中継装置と、前記管理サーバと前記ネットワークを介して通信接続される通信端末装置とを備えた遠隔監視システムを対象にして、前記管理サーバとして、前記給湯システムに係る情報を蓄積・更新する記憶部を備えるものとする。加えて、前記個別制御部、前記統括制御部、前記中継装置、前記管理サーバ及び前記通信端末装置の内のいずれかが、前記給湯システムのメンテナンスのための報知処理を実行する制御手段を備えるものとする。そして、前記制御手段として、前記記憶部からの情報を受けて、運転可能な給湯器の合計給湯能力から実際の稼働における最大稼働給湯能力を減じた差分の演算、又は、運転可能な給湯器の連結台数から実際の稼働における最大稼働実績台数を減じた差分の演算を行い、この演算結果に基づいて前記メンテナンスのための報知処理を実行するか否かを決定するように構成した（請求項４）。
【００１４】
この第２の発明の場合、給湯システムの遠隔監視システムにおいて、運転可能な給湯器の合計給湯能力から実際の稼働における最大稼働給湯能力を減じた差分の演算、又は、運転可能な給湯器の連結台数から実際の稼働における最大稼働実績台数を減じた差分の演算により得られる差分が要求される給湯に対する余裕度を表すことになる。従って、演算により得られた差分が大きな余裕度を表すものであれば、たとえエラーが発生して検知されたとしても、そのエラーを解消するためのメンテナンスの緊急性はない又は低いものと判定することができる。このため、メンテナンスのための報知処理を即座には実行しないものとすることにより、そのような緊急性の無い又は低い場合にも時間の如何に拘わらず即座に報知処理を実行することによるデメリットの発生を回避し得ることになる。
【００１５】
前記発明の遠隔監視システムにおいて、制御手段として、メンテナンスに要する負荷が重負荷となる時間帯として予め設定した第１時間帯において、前記複数の給湯器のいずれかについてエラー発生を検知したことのエラー検知情報を受けたとき、前記演算された差分が所定の判定基準値よりも大きければ、前記メンテナンスのための報知処理の実行を、メンテナンスに要する負荷が低負荷となる時間帯として予め設定した第２時間帯の到来まで遅延させるように構成することができる（請求項５）。このようにすることにより、エラー検知情報を前記第１時間帯に受けた場合に、前記差分が所定の判定基準値よりも大きくて、給湯要求に対し余裕度が所定以上に大きければ、低負荷でメンテナンスを行い得る第２時間帯が到来するまで報知処理を遅延させることで、例えば深夜等にメンテナンス作業に出かけるという過度のメンテナンスを回避しつつ必要なメンテナンス対応をも満足させ得ることになる。
【発明の効果】
【００１６】
以上、説明したように、第１の発明の給湯システムによれば、運転可能な給湯器の合計給湯能力から実際の稼働における最大稼働給湯能力を減じた差分の演算、又は、運転可能な給湯器の連結台数から実際の稼働における最大稼働実績台数を減じた差分の演算により得られる差分により、要求される給湯に対する余裕度を表すことができる。従って、演算により得られた差分が大きな余裕度を表すものであれば、たとえエラーが発生して検知されたとしても、そのエラーを解消するためのメンテナンスの緊急性はない又は低いものと判定することができる。このため、メンテナンスのための報知処理を即座には実行しないものとすることにより、そのような緊急性の無い又は低い場合にも時間の如何に拘わらず即座に報知処理を実行することによるデメリットの発生を回避することができるようになる。
【００１７】
特に請求項２の給湯システムによれば、制御手段として、メンテナンスに要する負荷が重負荷となる時間帯として予め設定した第１時間帯において、複数の給湯器のいずれかについてエラー発生を検知したことのエラー検知情報を受けたとき、演算された差分が所定の判定基準値よりも大きければ、メンテナンスのための報知処理の実行を、メンテナンスに要する負荷が低負荷となる時間帯として予め設定した第２時間帯の到来まで遅延させるように構成することにより、本発明をより明確化することができる。すなわち、エラー検知情報を深夜等の第１時間帯に受けた場合に、前記差分が所定の判定基準値よりも大きくて、給湯要求に対し余裕度が所定以上に大きければ、日中等の低負荷でメンテナンスを行い得る第２時間帯が到来するまで報知処理を遅延させているため、例えば深夜等にメンテナンス対応を依頼するという過度の対応を回避することができ、併せて、必要なメンテナンス対応をも満足させることができる。
【００１８】
請求項３の給湯システムによれば、演算結果についても併せて報知処理するように構成することにより、稼働実績情報や稼働可能情報に基づく余裕度をも併せて報知することができ、メンテナンス時に、これらの情報に基づいて、余裕度が大幅に大きければ、エラー検知された給湯器を修理等せずに給湯システムから切り離して、給湯システムを構成する連結台数を減らすことの検討資料をユーザーに与えることができたり、情報に接したサービスマンからユーザーに対し提案することができたりすることができる。つまり、給湯システムの稼働状況が分かるため、メンテナンス（修理）するだけの対応ではなく、ユーザーに対し以後の経費節減等の検討資料にしたり、ユーザーに対しアドバイスを行うこともできるようになる。
【００１９】
又、第２の発明の遠隔監視システムによれば、運転可能な給湯器の合計給湯能力から実際の稼働における最大稼働給湯能力を減じた差分の演算、又は、運転可能な給湯器の連結台数から実際の稼働における最大稼働実績台数を減じた差分の演算により得られる差分によって、要求される給湯に対する余裕度を表すことができるようになる。従って、演算により得られた差分が大きな余裕度を表すものであれば、たとえエラーが発生して検知されたとしても、そのエラーを解消するためのメンテナンスの緊急性はない又は低いものと判定することができる。このため、メンテナンスのための報知処理を即座には実行しないものとすることにより、そのような緊急性の無い又は低い場合にも時間の如何に拘わらず即座に報知処理を実行することによるデメリットの発生を、回避することができるようになる。
【００２０】
特に請求項５の遠隔監視システムによれば、制御手段として、メンテナンスに要する負荷が重負荷となる時間帯として予め設定した第１時間帯において、前記複数の給湯器のいずれかについてエラー発生を検知したことのエラー検知情報を受けたとき、前記演算された差分が所定の判定基準値よりも大きければ、前記メンテナンスのための報知処理の実行を、メンテナンスに要する負荷が低負荷となる時間帯として予め設定した第２時間帯の到来まで遅延させるように構成することにより、前記第２の発明をより明確化することができる。すなわち、エラー検知情報を前記第１時間帯に受けた場合に、前記差分が所定の判定基準値よりも大きくて、給湯要求に対し余裕度が所定以上に大きければ、低負荷でメンテナンスを行い得る第２時間帯が到来するまで報知処理を遅延させるようにしているため、例えば深夜等にメンテナンス作業に出かけるという過度のメンテナンスを回避することができ、必要なメンテナンス対応をも満足させることができるようになる。
【図面の簡単な説明】
【００２１】
【図１】給湯システム及び給湯システムについての遠隔監視システムの全体模式図である。
【図２】図１の連結型給湯システムの例を示す模式図である。
【図３】図２の１台の給湯器の例を示す模式図である。
【図４】遠隔監視システムにおける報知管理制御に係るフローチャートである。
【発明を実施するための形態】
【００２２】
以下、本発明の実施形態を図面に基づいて説明する。
【００２３】
＜第１実施形態＞
図１は、本発明の実施形態に係る給湯システム及びその遠隔監視システムの全体模式図である。遠隔監視システムは、台数制御される複数の給湯器３，３，…を備えた給湯システム２と、この給湯システム２に付設されて遠隔通信制御を担う中継装置４と、情報を収集，蓄積，更新して情報管理を行うことにより監視を行う管理サーバ５と、この管理サーバ５から情報の提供を受けてメンテナンス手配指令を発するための第１クライアント端末６と、第１クライアント端末６からのメンテナンス手配指令を受ける第２クライアント端末７とを備えている。管理サーバ５は例えば給湯システム２やこれを構成する給湯器３の製造販売を担った企業等に設置し、第１クライアント端末６は例えば該企業又はこの企業から委託を受けた外部企業により設置されたコールセンター等に設置し、第２クライアント端末７は例えば当該給湯システム２が設置された地域を管轄するサービスショップ等に設置することができる。このため、管轄地域毎に第２クライアント端末７を設けることができる。サービスショップは、第２クライアント端末７が受けたメンテナンス手配指令に基づきメンテナンスのための個別具体的なサービスを提供する業務を担い、その業務遂行のために個々のサービスマンが携帯するための可搬式の通信端末装置８を備えることができる。あるいは、サービスショップに対し、第２クライアント端末７に代えて前記同様の可搬式の通信端末装置８を設けることができる。可搬式の通信端末装置８としては、例えば無線通信機能を備えたタブレット端末を用いることができる。そして、前記の管理サーバ５、第１クライアント端末６及び第２クライアント端末７はそれぞれネットワーク９を介して互いに通信可能に接続される他、ネットワーク９に接続された無線通信基地局１０を介して、遠隔通信制御装置４や通信端末装置８とも互いに通信可能に接続されている。これらの内、第１クライアント端末６，第２クライアント端末７もしくは通信端末装置８が通信端末装置を構成する。第１実施形態では、管理サーバ５が本発明の報知管理制御を担う構成を採用するため、管理サーバ５から後述のエラー報知を受ける通信端末装置として前記の内の少なくとも１つ備えることができる。
【００２４】
給湯システム２は、図２に一例を示すように、それぞれ子システムコントローラＳＣにより台数制御等の制御が実行される単位給湯システム２１を２セット以上（図例のものは２セット）組み合わせ、これらの単位給湯システム２１，２１の子システムコントローラＳＣ，ＳＣを親システムコントローラＰＳＣにより統括して制御するというように階層構造の制御システムが適用された連結型の給湯システムである。子システムコントローラＳＣ及び親システムコントローラＰＳＣが統括制御部を構成し、後述の個別コントローラ３１が個別制御部を構成することになる。
【００２５】
各単位給湯システム２１は、子システムコントローラＳＣにより制御される２台以上の所定数の同じ構成の給湯器３，３，…を入水経路２２と出湯経路２３との間に並列に連結したものである。すなわち、各単位給湯システム２を構成する各給湯器３は、図３に例示するように、入水口３２が水道管等から給水を受ける入水経路２２に対し接続される一方、各出湯口３３が図示省略の貯湯槽や給湯栓等を下流端とする出湯経路２３に対しそれぞれ並列に接続されている。各給湯システム２において、各給湯器３は各給湯器３に内蔵された個別コントローラ３１により主として燃焼系の作動制御に基づく給湯運転制御が行われ、これら各給湯器３の個別コントローラ３１が通信線を介して子システムコントローラＳＣと双方向通信可能に通信接続されて、各個別コントローラ３１は、子システムコントローラＳＣから、主として台数制御における運転設定や設定出湯温度の設定に係る制御信号を受けるようになっている。そして、各単位給湯システム２１の子システムコントローラＳＣが親システムコントローラＰＳＣと通信線を介して個別に双方向通信可能に通信接続されて、各子システムコントローラＳＣは、親システムコントローラＰＳＣから、主としていずれの単位給湯システム２１が最初に給湯作動するために待機するかの設定信号や、リモコンＲＣに設定された設定出湯温度に関する指令信号を受けるようになっている。
【００２６】
各子システムコントローラＳＣは、各単位給湯システム２１を構成する各給湯器３の個別コントローラ３１，３１，…との通信接続により、各単位給湯システム２１を構成する給湯器３，３，…の連結台数（図例では６台）、給湯器３毎の個別認識、給湯器３毎の稼働状況や給湯器３毎のエラー検知情報等の把握・収集が可能となっている。これらの情報に基づいて各子システムコントローラＳＣや親システムコントローラＰＳＣでは、特に、所定時間（例えば１時間）毎にその時間内に燃焼作動した給湯器３,３,…の最大台数（稼働実績台数）や、燃焼作動した給湯器３,３,…内の後述の入水流量センサ３６により検出された検出入水流量を合計して得られる給湯流量の内、前記所定時間内の最大の給湯流量を収集して稼働実績情報として親システムコントローラＰＳＣの記憶部（例えば不揮発性メモリ）に記憶する。そして、これらの情報が親システムコントローラＰＳＣから中継装置４を介して管理サーバ５に自動送信されるようになっている。中継装置４は、無線通信基地局１０及びネットワーク９を介した管理サーバ５との送受信のために、通信制御部４１、送信部４２、受信部４３及びアンテナ４４を備えて構成されている。
【００２７】
図３に例示した給湯器３の構成を簡単に説明すると、入水経路２２からの水を入水路３２を通して熱交換器３３に入水させ、熱交換器３３を通る間に燃焼バーナ３４の燃焼熱との熱交換により加熱された湯を出湯路３５に出湯させて出湯経路２３に出湯するようになっている。入水路３２には入水流量を検出するための入水流量センサ３６が設けられ、出湯路３５には出湯流量を調整する全閉切換機能付きの流量制御弁３７が設けられている。流量制御弁３７を子システムコントローラＳＣからの制御信号により全閉状態に閉止切換することで、台数制御等による給湯使用（流量制御弁３７を開）・不使用（流量制御弁３７を閉止）の切換えが可能となっている。  
【００２８】
台数制御について簡単に説明すると、子システムコントローラＳＣが属する単位給湯システム２１を構成する全給湯器３，３，…の内から選択したいずれか２台の給湯器３,３を最初に燃焼させるメイン給湯器に、他の給湯器３，３，…を給湯要求を満たす上で追加燃焼させるサブ給湯器にそれぞれ役割を割り付け、給湯待機時にはメイン給湯器３，３のみに燃焼許可指令を送出し、他のサブ給湯器３，３，…には燃焼禁止指令を送出する。つまり、図３の例では流量制御弁３７の開閉切換により、給湯待機時にはメイン給湯器３,３のみを介して給水経路２２と給湯経路２３とを連通させ、他のサブ給湯器３，３，…は給水経路２２と給湯経路２３とを遮断状態（通水不能）にしておくようになっている。
【００２９】
そして、例えば下流端の給湯栓等が開かれて入水経路２２に入水が生じてメイン給湯器３，３への入水流量がＭＯＱ以上になればメイン給湯器３，３の燃焼が開始されて給湯運転制御に入り、メイン給湯器３，３の給湯能力だけでは給湯要求量に対し不足するようになると、メイン給湯器３，３から子システムコントローラＳＣに対し補完要求が出力され、これを受けた子システムコントローラＳＣはいずれか１台のサブ給湯器３に燃焼許可指令を送出することになる。これにより、サブ給湯器３の流量制御弁３７が開切換えされ、入水流量センサ３６によるＭＯＱ以上の入水流量検知により燃焼される。さらに３台の給湯器３，３，３の燃焼によっても給湯要求量に対し不足すれば、さらに他のサブ給湯器３も燃焼されるというように燃焼台数を増加させることになる。同様に、給湯要求が低くなると、それに応じて燃焼禁止指令を順に送出することにより、逆に燃焼台数を順次減らしていくことになる。そして、燃焼が許可されて給湯運転に使用される所定台数の給湯器３,３,…の内のいずれかの給湯器３にエラーが検知されて使用不可になったとしても、サブ給湯器を代替させてバックアップ可能となっている。
【００３０】
管理サーバ５は、ネットワーク９を介して通信を行う通信部、サーバ機能や監視機能を有しメンテナンスに係る報知管理制御を実行する制御部及び各種情報毎に割り当てられた記憶部を備えている。そして、給湯システム２のシステムコントローラＳＣ,ＰＳＣから少なくとも次のものを含む情報を受けて記憶部に記憶・更新・蓄積するようになっている。すなわち、給湯システム２の識別情報（設置場所等の情報）及び給湯システム２を構成する給湯器３の台数や給湯能力（例えば５０号）等の性能に係る設置情報と、所定時間（例えば１時間）毎にその所定時間内に実際に燃焼作動して給湯稼働した給湯器３,３,…の稼働実績台数、及び、前記所定時間内に給湯稼働した給湯器３,３,…からの稼働給湯流量（各入水流量センサ３６の検出流量の合計）等の稼働実績情報と、故障等で運転不能となっている給湯器３を除外した前記所定時間内において実際に運転可能な給湯器３，３，…の連結台数等の稼働可能情報と、給湯システム２の各給湯器３についてのエラー検知情報とである。エラー検知情報としては、軽度のエラーに係る検知情報として、例えば燃焼バーナ３４に着火作動したにも拘わらず着火検知不能であることに基づく不着火検知情報や、燃焼中であるにも拘わらず炎検知が途切れる途中失火検知情報等があり、重度のエラーに係る検知情報として、例えば出湯路３５に設けられた温度センサが設定温度を超える異常な高温度を検出したことによる高温出湯異常検知情報や、排気筒に設けたＣＯセンサが設定値以上のＣＯ濃度を検出したことによるＣＯ異常検知情報等があり、管理サーバ５の記憶部には、各種のエラー内容が軽度なエラーと、重度なエラーとに予め分類されてデータベース化した情報として登録されている。
【００３１】
管理サーバ５の制御部は、前記情報の情報管理制御を行う一方、給湯システム２から送信されたエラー検知情報を受信すると、そのエラー検知情報のエラーが重度か軽度かの如何によって第１クライアント端末に対する報知処理として異なる対応処理を行う報知管理制御を実行するようになっている。情報管理制御は、前記所定時間経過毎に送信される稼働実績台数及び稼働給湯流量等の稼働実績情報を時間情報と共に記憶部に蓄積するとともに、運転可能な連結台数に係る稼働可能情報について順次新しい情報に更新する。併せて、前記給湯システム２を構成する給湯器３の給湯能力、及び、前記の実際に運転可能な給湯器３，３，…の連結台数に基づき、その時点で運転可能な合計給湯能力（例えば１台が５０号の給湯能力で４台が運転可能であれば２００号分の合計給湯能力）を演算し、この合計給湯能力を稼働可能情報の１種として記憶・更新する。
【００３２】
報知管理制御は、図４に示すように、まず、今が予め定めた第１時間帯の範囲であるか否かを判定し（ステップＳ１）、今が第１時間帯以外の時点であるときには（ステップＳ１でＮＯ）、エラー検知情報が有れば（ステップＳ２でＹＥＳ）、原則通り、即座に第１クライアント端末６に対し報知処理を行う（ステップＳ３）。第１時間帯とは、給湯システム２にもしもエラーが発生した場合、その時間帯にサービスマンがメンテナンスのために出向いて作業を行うのに要する負荷、つまりメンテナンスに要する負荷が重負荷となるものとして予め設定された時間帯のことである。このような第１時間帯として、例えば夜間や深夜の時間帯、あるいは、サービスショップの通常の就業時間帯以外の時間帯を設定することができる。又、ステップＳ３の報知処理では、エラー検知情報の内容に加え、そのエラー検知情報が発せられた給湯システム２の識別情報や設置情報を含む、エラー解消のためのメンテナンスに必要な情報の他に、稼働実績情報や稼働可能情報も参考情報として送信される。そして、第１クライアント端末６では、受信した識別情報に基づいて管轄するサービスショップを割り出し、そのサービスショップの第２クライアント端末７に前記の情報を送信する。第２クライアント端末７が設置されたサービスショップでは、可搬式の通信端末装置８を備えていなければ、受信した情報に基づいて、そのサービスショップからサービスマンを当該給湯システム２の設置場所に対しメンテナンスのために急行させ、可搬式の通信端末装置８を持参しているサービスマンが存在すれば、その通信端末装置８に前記の情報を送信してサービスマンを同給湯システム２の設置場所にメンテナンスのために急行させることになる。
【００３３】
一方、ステップＳ１の判定で、今が前記第１時間帯の範囲内であるときには（ステップＳ１でＹＥＳ）、エラー検知情報が有れば（ステップＳ４でＹＥＳ）、まず、そのエラー内容が予め登録されている重度なエラーに該当するか否かを判定する（ステップＳ５）。エラー内容が重度なエラーに該当すれば（ステップＳ５でＹＥＳ）、前記のステップＳ２でＹＥＳの場合と同様に、第１クライアント端末６に対し即座に報知処理を実行する（ステップＳ３）。これにより、たとえ深夜の時間帯であったとしても、エラー検知された給湯システム２に対しサービスマンが急行して、エラー解消のためのメンテナンスが行われることになる。
【００３４】
ステップＳ５の判定において、エラー内容が重度のエラーに該当せずに軽度なエラーに該当すれば（ステップＳ５でＮＯ）、次に、給湯システム２のシステム全体としての余裕度を判定する。すなわち、給湯システム２における稼働可能情報値から稼働実績情報値を減じた差分が所定の判定基準値以上であるか否かを判定する（ステップＳ６）。例えば給湯器３の台数を判定の基準とする場合には、稼働可能情報値として運転可能な連結台数の値を選択する一方、稼働実績情報値として過去の所定期間（例えば２４時間あるいは１年間等）内に蓄積された稼働実績台数の内から最大稼働実績台数を選択設定して、次の判定式に基づいて判定する。
（運転可能な連結台数−最大稼働実績台数）≧判定基準台数
左辺の解である差分の台数は余裕台数を表し、この余裕台数が判定基準台数（例えば２台）以上の余裕度であれば（ステップＳ６でＹＥＳ）、メンテナンスの緊急性はないものと判定する。あるいは、例えば給湯器３の給湯能力（給湯流量）を判定の基準とする場合には、稼働可能情報値として運転可能な合計給湯能力（運転可能な合計給湯流量）の値を選択する一方、稼働実績情報値として過去の所定期間（例えば２４時間あるいは１年間等）内に蓄積された稼働給湯流量の内から最大値を選択設定して、次の判定式に基づいて判定する。この際、稼働給湯流量を設定入水温度や設定給湯温度等の情報に基づいて号数に統一して演算に適用することができる。もちろん、稼働可能情報値及び稼働実績情報値の双方を流量に統一して演算に適用してすることができる。
（運転可能な合計給湯能力−最大稼働給湯能力）≧判定基準能力
左辺の解である差分の給湯能力は余裕能力を表し、この余裕能力が判定基準能力（例えば１００号）以上の余裕度であれば（ステップＳ６でＹＥＳ）、メンテナンスの緊急性はないものと判定する。
【００３５】
そして、メンテナンスの緊急性はないものと判定されると、メンテナンスに係る報知処理の実行を第２時間帯になるまで遅延させる遅延処理を実行する（ステップＳ７）。第２時間帯とは、給湯システム２にもしもエラーが発生した場合、その時間帯にサービスマンがメンテナンスのために出向いて作業を行うのに要する負荷、つまりメンテナンスに要する負荷が通常作業の軽負荷で事足りるものとして予め設定した時間帯のことである。このような第２時間帯として、例えば、第１時間帯以外の時間帯、サービスショップの通常の就業時間帯、あるいは、サービスショップからメンテナンスに出かけるのに都合の良い時間帯（例えば１０：００〜１５：００の時間帯）を設定することができる。遅延処理により報知処理を一時保留状態に維持し、時間経過により第２時間帯の始期（例えば朝の１０：００）に到達すれば、第１クライアント端末６に対しステップＳ３で説明したと同様の報知処理を実行する。以後、第２クライアント端末７等に情報送信されて、給湯システム２に対するメンテナンスが行われることになる。
【００３６】
以上の場合、管理サーバ５がエラー検知情報を深夜等の第１時間帯に受信したとしても、前記の遅延処理によって、メンテナンス実行のための指令が発せられるタイミングが、例えばサービスショップによるメンテナンス作業が通常業務として行い得る第２時間帯になるまで保留されるため、軽度なエラーで、しかも、稼働可能な台数や能力に余裕度が一定以上あるような緊急性の無いメンテナンス作業のためにサービスマンが深夜等にユーザー宅まで出かける手間を回避することができる。又、給湯システム２のユーザーにとってもそのような緊急性のないメンテナンス作業のために深夜等に対応せざるを得ない事態を回避することができる。一方、重度のエラーである場合や、軽度のエラーであっても余裕度が所定のものよりも低い場合には、たとえ深夜等であっても原則通りに報知処理がなされてメンテナンス対応を可能とすることができる。さらに、報知処理に伴い、稼働実績情報や稼働可能情報も併せて報知されるため、メンテナンス時に、これらの情報に基づいて、余裕度が大幅に大きければ、エラー検知された給湯器３を修理等せずに給湯システム２から切り離して給湯システムを構成する連結台数を減らすことをユーザーに対し提案することができる。つまり、ユーザーの給湯システム２の稼働状況が分かるため、メンテナンス（修理）するだけの対応ではなく、前記提案等によりユーザーに対し以後の経費節減等のアドバイスを行うことができる。
【００３７】
＜第２実施形態＞
第２実施形態は、前記の報知管理制御に係るプログラムが第１クライアント端末６にインストールされて、報知管理制御を管理サーバ５ではなくて第１クライアント端末６が実行するものである。なお、それ以外の全体のシステム構成等は第１実施形態で説明したものと同じである。又、図４のフローチャートのステップの内容説明では、第１実施形態と異なる部分について主として説明し、第１実施形態で説明したものと同じ内容部分については説明を省略する。
【００３８】
この第２実施形態の場合、今が第１時間帯の範囲であるか否かの判定（ステップＳ１；図４参照）により、今が第１時間帯以外の時点であるときには（ステップＳ１でＮＯ）、エラー検知情報が有れば（ステップＳ２でＹＥＳ）、原則通り、第１クライアント端末６から管轄するサービスショップの第２クライアント端末７に対し即座に報知処理を行う（ステップＳ３）。一方、ステップＳ１の判定で、今が前記第１時間帯の範囲内であるときには（ステップＳ１でＹＥＳ）、エラー検知情報が有れば（ステップＳ４でＹＥＳ）、そのエラー内容が重度なエラーに該当するか否かを判定し（ステップＳ５）、エラー内容が重度なエラーに該当すれば（ステップＳ５でＹＥＳ）、前記のステップＳ２でＹＥＳの場合と同様に、第２クライアント端末７に対し即座に報知処理を実行する（ステップＳ３）。報知処理の内容は第１実施形態で説明したものと同じである。第２クライアント端末７が設置されたサービスショップからサービスマンが、あるいは、第２クライアント端末７からさらに情報報知が行われた通信端末装置８を見たサービスマンが、メンテナンス作業のためにユーザー宅に急行することになる。
【００３９】
そして、ステップＳ５の判定において、エラー内容が重度のエラーに該当せずに軽度なエラーに該当すれば（ステップＳ５でＮＯ）、次に、給湯システム２のシステム全体としての余裕度を判定する。すなわち、管理サーバ５からそれぞれ読み出した稼働可能情報値から稼働実績情報値を減じた差分が所定の判定基準値以上であるか否かを判定する（ステップＳ６）。前記差分により表される余裕度が判定基準値（例えば２台もしくは１００号）以上の余裕度であれば（ステップＳ６でＹＥＳ）、メンテナンスの緊急性はないものと判定する。そして、メンテナンスの緊急性はないものと判定されると、メンテナンスに係る報知処理の実行を第２時間帯になるまで遅延させる遅延処理を実行する（ステップＳ７）。遅延処理により報知処理を一時保留状態に維持し、時間経過により第２時間帯の始期（例えば朝の１０：００）に到達すれば、第１クライアント端末６から第２クライアント端末７に対し前記と同様の報知処理を実行する。これにより、ユーザーの給湯システム２に対するメンテナンスが行われることになる。
【００４０】
この第２実施形態の場合においても、第１実施形態で説明したと同様の作用効果を得ることができる。
【００４１】
＜第３実施形態＞
第３実施形態は、前記の報知管理制御に係るプログラムが給湯システム２のシステムコントローラＳＣ又はＰＳＣにインストールされて、報知管理制御をシステムコントローラＳＣ，ＰＳＣが実行するものである。なお、それ以外の全体のシステム構成等は第１実施形態で説明したものと同じである。又、図４のフローチャートの各ステップの内容説明では、第１実施形態と異なる部分について主として説明し、第１実施形態で説明したものと同じ内容部分については説明を省略する。さらに、以後の説明では報知管理制御に係るプログラムがインストールされて報知管理制御を実行するのは親システムコントローラＰＳＣであるものとして説明する。
【００４２】
この第３実施形態の場合、今が第１時間帯の範囲であるか否かの判定（ステップＳ１；図４参照）により、今が第１時間帯以外の時点であるときには（ステップＳ１でＮＯ）、エラー検知情報の出力が有れば（ステップＳ２でＹＥＳ）、中継装置４に指令を発して管理サーバ５に対しそのエラー検知情報について報知処理を行う（ステップＳ３）。報知処理によりエラー検知情報が送信された管理サーバ５は、第１クライアント端末６に対し、エラー検知情報の内容に加え、既に蓄積・更新されている各種情報の内から、前記エラー検知情報が発せられた給湯システム２の識別情報や設置情報を含む、エラー解消のためのメンテナンスに必要な情報の他に、稼働実績情報や稼働可能情報も参考情報として送信する。そして、第１クライアント端末６は、メンテナンス対応のために管轄するサービスショップの第２クライアント端末７に対し前記の各情報を送信する。これにより、第２クライアント端末７が設置されたサービスショップからサービスマンが、あるいは、第２クライアント端末７からさらに情報報知が行われた通信端末装置８を見たサービスマンが、メンテナンス作業のためにユーザー宅に急行することになる。
【００４３】
一方、ステップＳ１の判定で、今が前記第１時間帯の範囲内であるときには（ステップＳ１でＹＥＳ）、エラー検知情報が有れば（ステップＳ４でＹＥＳ）、そのエラー内容が重度なエラーに該当するか否かを判定し（ステップＳ５）、エラー内容が重度なエラーに該当すれば（ステップＳ５でＹＥＳ）、前記のステップＳ２でＹＥＳの場合と同様に、管理サーバ５に対し即座に報知処理を実行する（ステップＳ３）。
【００４４】
あるいは、ステップＳ５の判定において、エラー内容が重度のエラーに該当せずに軽度なエラーに該当すれば（ステップＳ５でＮＯ）、次に、給湯システム２のシステム全体としての余裕度を判定する。すなわち、中継装置４を介して管理サーバ５からそれぞれ読み出した稼働可能情報値から稼働実績情報値を減じた差分が所定の判定基準値以上であるか否かを判定する（ステップＳ６）。前記差分により表される余裕度が判定基準値（例えば２台もしくは１００号）以上の余裕度であれば（ステップＳ６でＹＥＳ）、メンテナンスの緊急性はないものと判定する。そして、メンテナンスの緊急性はないものと判定されると、メンテナンスに係る報知処理の実行を第２時間帯になるまで遅延させる遅延処理を実行する（ステップＳ７）。遅延処理により報知処理を一時保留状態に維持し、時間経過により第２時間帯の始期（例えば朝の１０：００）に到達すれば、中継装置４に指令を発して管理サーバ５に対し前記ステップＳ３で説明したと同様の報知処理を実行する。これにより、ユーザーの給湯システム２に対するメンテナンスが行われることになる。
【００４５】
この第３実施形態の場合においても、第１実施形態で説明したと同様の作用効果を得ることができる。なお、本実施形態で説明した報知管理制御に係るプログラムをインストールして報知管理制御を実行するものとして、システムコントローラＳＣ，ＰＳＣではなくて、給湯システム２を構成するいずれかの給湯器３の個別コントローラ３１とすることができ、あるいは、中継装置４の通信制御部４１とすることもできる。これらの場合、いずれも、報知処理を遅延させる対象は管理サーバ５に対してである。
【００４６】
＜第４実施形態＞
第４実施形態は、本発明に係る報知管理制御を給湯システム２内で完結させたものである。すなわち、給湯システム２が中継装置４を備えず、ネットワーク９とも通信接続されてはいなくて、給湯システム２単独で構成されているものである。この第４実施形態では、前記の報知管理制御に係るプログラムが給湯システム２のシステムコントローラＳＣ又はＰＳＣにインストールされて、報知管理制御をシステムコントローラＳＣ，ＰＳＣが実行するものである。そして、報知処理は、リモコンＲＣの表示部等を対象に行うものである。以後の説明では報知管理制御に係るプログラムがインストールされて報知管理制御を実行するのは親システムコントローラＰＳＣであるものとして説明するが、もちろん、子システムコントローラＳＣであっても、あるいは、いずれかの給湯器３の個別コントローラ３１、さらには、リモコンＲＣであってもよく、これらのいずれかに当該プログラムがインストールされて報知管理制御を実行するように構成することができる。
【００４７】
この第４実施形態の場合の報知管理制御を担当する親システムコントローラＰＳＣ等は、所定の記憶部を備え、その記憶部に対し、前述の管理サーバ５の場合と同様に少なくとも次のものを含む情報を記憶・更新・蓄積するようになっている。すなわち、給湯システム２の識別情報（設置場所等の情報）及び給湯システム２を構成する給湯器３の台数や給湯能力（例えば５０号）等の性能に係る設置情報と、所定時間（例えば１時間）毎にその所定時間内に実際に燃焼作動して給湯稼働した給湯器３,３,…の稼働実績台数、及び、前記所定時間内に給湯稼働した給湯器３,３,…からの稼働給湯流量（各入水流量センサ３６の検出流量の合計）等の稼働実績情報と、故障等で運転不能となっている給湯器３を除外した前記所定時間内において実際に運転可能な給湯器３，３，…の連結台数等の稼働可能情報と、給湯システム２の各給湯器３についてのエラー検知情報とである。そして、第１実施形態で説明したと同様の重度のエラーや軽度のエラーのリストが予め登録されている。
【００４８】
この第４実施形態の場合、今が第１時間帯の範囲であるか否かの判定（ステップＳ１；図４参照）により、今が第１時間帯以外の時点であるときには（ステップＳ１でＮＯ）、エラー検知情報の出力が有れば（ステップＳ２でＹＥＳ）、即座にリモコンＲＣに対しエラー検知情報について報知処理を行う（ステップＳ３）。この報知処理は、リモコンＲＣの表示部にテキスト文字やエラーコード等を表示させたり、リモコンＲＣの音声ガイドを利用してエラー発生に係る警告案内をさせたり、警告灯を点灯させたり、警告音を吹鳴させたり、あるいは、これらの内の２種類以上を組み合わせたり、することでできる。これにより、リモコンＲＣによる報知に気付いたユーザー自身によるメンテナンスの依頼を促進させることができる。
【００４９】
一方、ステップＳ１の判定で、今が前記第１時間帯の範囲内であるときには（ステップＳ１でＹＥＳ）、エラー検知情報が有れば（ステップＳ４でＹＥＳ）、そのエラー内容が重度なエラーに該当するか否かを判定し（ステップＳ５）、エラー内容が重度なエラーに該当すれば（ステップＳ５でＹＥＳ）、前記のステップＳ２でＹＥＳの場合と同様に、管理サーバ５に対し即座に報知処理を実行する（ステップＳ３）。
【００５０】
あるいは、ステップＳ５の判定において、エラー内容が重度のエラーに該当せずに軽度なエラーに該当すれば（ステップＳ５でＮＯ）、次に、給湯システム２のシステム全体としての余裕度を判定する。すなわち、親システムコントローラＰＳＣの記憶部に記憶された稼働可能情報値から稼働実績情報値を減じた差分が所定の判定基準値以上であるか否かを判定する（ステップＳ６）。前記差分により表される余裕度が判定基準値（例えば２台もしくは１００号）以上の余裕度であれば（ステップＳ６でＹＥＳ）、メンテナンスの緊急性はないものと判定する。そして、メンテナンスの緊急性はないものと判定されると、メンテナンスに係る報知処理の実行を第２時間帯になるまで遅延させる遅延処理を実行する（ステップＳ７）。遅延処理により報知処理を一時保留状態に維持し、時間経過により第２時間帯の始期（例えば朝の１０：００）に到達すれば、リモコンＲＣに対し前述と同様の報知処理を実行する。これに気付いたユーザーにより、メンテナンスの依頼が行われることになる。
【００５１】
この第４実施形態の場合、親システムコントローラＰＳＣがエラー検知情報を深夜等の第１時間帯に受けたとしても、前記の遅延処理によって、リモコンＲＣに対する報知処理のタイミングが、例えば翌日の日中の第２時間帯になるまで保留されるため、軽度なエラーで、しかも、稼働可能な台数や能力に余裕度が一定以上あるような緊急性の無いエラー報知のために、深夜等においてユーザーを驚かせる事態を招くことを解消することができる。一方、重度のエラーである場合や、軽度のエラーであっても余裕度が所定のものよりも低い場合には、たとえ深夜等であっても原則通りにリモコンＲＣを用いた報知処理がなされるため、ユーザーに対し確実に報知することができる。さらに、報知処理に伴い、稼働実績情報や稼働可能情報も併せて報知することにより、これらの情報に基づいて、余裕度が大幅に大きければ、エラー検知された給湯器３を修理等せずに給湯システム２から切り離して給湯システムを構成する連結台数を減らす等について検討資料をユーザーに対し提供することができる。
【００５２】
＜他の実施形態＞
なお、本発明は前記実施形態に限定されるものではなく、その他種々の実施形態を包含するものである。すなわち、報知管理制御に係るプログラムがインストールされて報知管理制御を実行するのを第２クライアント端末７とすることができる。この場合の報知処理の対象はサービスマンが持参する通信端末装置８とする。つまり、サービスショップの第２クライアント端末７にはエラー検知情報等が届いてはいるものの、その時点が第１時間帯内であり、しかも、そのエラーが軽度のエラーである場合には、実際にメンテナンス作業に出かけるサービスマンの通信端末装置８への報知処理を、翌日の日中等の第２時間帯に入るまで保留させて遅延させるのである。
【００５３】
管理サーバ５としては、１台のみに限らず、別の所に設置した複数台の管理サーバにより構成することができる。例えば、個人情報に関係する情報を記憶・更新・蓄積するための管理サーバと、稼働実績情報や稼働可能情報を記憶・更新・蓄積するための管理サーバとに分けることができる。この場合、互いの情報を関連付けて記憶することができる。
【００５４】
給湯システムにおいて、システムコントローラＳＣ，ＰＳＣ等がエラー検知情報を受けた場合、前記差分により表される余裕度が判定基準値（例えば２台もしくは１００号）以上の余裕度であれば、即座の報知も、遅延処理に基づく報知も、いずれの報知も行わないように構成することができる。この場合、そのエラー検知情報を、給湯器３（例えば個別コントローラ３１）、システムコントローラＳＣ，ＰＳＣ、あるいは、リモコンＲＣのいずれかが備える記憶部に記憶させるようにすることができる。そして、システムコントローラＳＣ，ＰＳＣ又はリモコンＲＣが備えるメンテナンスモニタ機能（過去に出力されたエラー検知情報を時間情報と共に記憶保持し、表示指令を受けて表示させる機能）を用いて、後日、定期点検等の際に、サービスマン等による所定操作（表示させるための操作）によって、過去に生じたエラー検知情報をシステムコントローラＳＣ，ＰＳＣやリモコンＲＣが備える表示部に表示させるようにすることができる。
【００５５】
又、給湯システムの遠隔監視システムにおいても、前記と同様に、エラー検知情報を受けた場合に、前記差分により表される余裕度が判定基準値（例えば２台もしくは１００号）以上の余裕度であれば、即座の報知も、遅延処理に基づく報知も、いずれの報知も行わないように構成することができる。この場合、そのエラー検知情報を、中継装置４、管理サーバ５、第１クライアント端末６あるいは第２クライアント端末７のいずれかが備える記憶部に記憶させるようにすることができる。そして、後日、定期点検等の際に、サービスマン等による所定操作（記憶情報を呼び出して表示させるための操作）によって、過去に生じたエラー検知情報を前記の第１クライアント端末６、第２クライアント端末７、あるいは、通信端末装置８が備える表示部に表示させるようにすることができる。
【符号の説明】
【００５６】
２      給湯システム
３      給湯器
４      中継装置（制御手段）
５      管理サーバ（制御手段）
６      第１クライアント端末（通信端末装置，制御手段）
７      第２クライアント端末（通信端末装置，制御手段）
８      通信端末装置
９      ネットワーク
３１    個別コントローラ（個別制御部，制御手段）
ＳＣ    子システムコントローラ（統括制御部，制御手段）
ＰＳＣ  親システムコントローラ（統括制御部，制御手段）
ＲＣ    リモコン（報知部）
【図１】
2016217671.tif 000003
【図２】
2016217671.tif 000004
【図３】
2016217671.tif 000005
【図４】
2016217671.tif 000006