JP7025381B2 - 空調装置のメンテナンス方法 - Google Patents

Description

本発明は、空調装置をメンテナンスするための方法に関する。

下記特許文献１は、建物内の複数の空間を空調するための空調システムを提案している。この空調システムは、少なくとも１台の空気調和機を含む一つの熱源で空調された空気を、複数の空間に供給する。

特開２０１６－１９１４８３号公報

一般に、上記のようなセントラル空調タイプの空調システムでは、不具合が発生した場合に、その不具合の原因を特定するのに多く時間を要する。さらに、不具合の原因が特定された後には、例えば、空調システムのメンテナンスを取り扱うカスタマーサービスによって、修理に必要な部材の特定や、費用の見積もり等が行われるため、実際に修理が開始されるまでに多くの時間を要する。特に、セントラル空調タイプの空調システムでは、他の空調手段を具えていないことが多いため、不具合発生時には、一切の空調を使うことができない。したがって、この種の空調システムでは、より迅速な復旧が望まれている。

本発明は、以上のような実状に鑑み案出されたもので、空調装置を迅速に復旧させることが可能なメンテナンス方法を提供することを主たる目的としている。

本発明は、ユーザーの建物内の空間を空調する空調装置をメンテナンスするための方法であって、前記空調装置の運転状況を示すログデータをコンピュータに入力するステップと、前記コンピュータが、前記ログデータを予め定められた第１手順に従って計算し、前記空調装置の不具合の有無を判定する不具合判定ステップと、前記不具合判定ステップにおいて、前記不具合があると判定された場合に、前記コンピュータが、前記ログデータを予め定められた第２手順に従って計算し、前記不具合の原因を特定した空調装置診断情報を生成するステップと、前記コンピュータが、前記空調装置診断情報に基づいて、前記不具合を修理するために必要な部材リストを含むカスタマーサービス向け情報と、前記修理のために必要な見積もり金額を含むユーザー向け情報とをそれぞれ生成するステップと、前記コンピュータが、前記ユーザー向け情報を、前記ユーザーに送信するステップと、前記コンピュータが、前記ユーザーが前記修理を承諾したことを示す承諾信号を受信したときに、カスタマーサービスに、前記ユーザー向け情報及び前記カスタマーサービス向け情報を送信するステップとを含むことを特徴とする。

本発明に係る前記空調装置のメンテナンス方法において、前記ログデータは、前記空調装置の設定温度と、前記空間の実温度とを含み、前記不具合判定ステップは、前記設定温度と前記実温度との温度差の変化に基づいて、前記不具合の有無を判定してもよい。

本発明に係る前記空調装置のメンテナンス方法において、前記コンピュータが、予め記憶されたサービスマンのスケジュールデータベースを参照し、前記修理を実行可能な作業日を検索するステップと、前記コンピュータが、前記スケジュールデータベースに、検索された前記作業日に、予約データを書き込むステップとをさらに含み、前記ユーザー向け情報には、前記作業日に関するデータが含まれてもよい。

本発明に係る前記空調装置のメンテナンス方法において、前記コンピュータが、前記ユーザーが前記不具合の前記修理を承諾しなかったことを示す非承諾信号を受信したときに、前記スケジュールデータベースから前記予約データを削除するステップをさらに含んでもよい。

本発明に係る前記空調装置のメンテナンス方法において、前記コンピュータが、前記ユーザー向け情報を送信してから予め定められた期間内に、前記承諾信号を受信しなかったときに、前記スケジュールデータベースから前記予約データを削除するステップと、前記コンピュータが、前記スケジュールデータベースを参照し、前記作業日を再検索するステップと、前記コンピュータが、前記スケジュールデータベースに、再検索された前記作業日に、予約データを書き込むステップと、前記コンピュータが、再検索された前記作業日に関するテータを含む前記ユーザー向け情報を、前記ユーザーに送信するステップとを含んでもよい。

本発明は、前記コンピュータが、前記ログデータを前記第１手順に従って計算することにより、前記空調装置の不具合の有無を容易に判定することができる。さらに、前記不具合があると判定された場合には、前記コンピュータが、前記ログデータを前記第２手順に従って計算することにより、前記不具合の原因を早期に特定することができる。

また、本発明は、前記コンピュータが、前記不具合の原因を特定した前記空調装置診断情報に基づいて、前記カスタマーサービス向け情報と、前記ユーザー向け情報とをそれぞれ生成し、前記ユーザーが前記修理を承諾したときに、前記カスタマーサービスに、前記ユーザー向け情報及び前記カスタマーサービス向け情報を送信できる。これにより、本発明は、前記空調装置の修理を早期に開始することができるため、前記空調装置を迅速に復旧させることが可能となる。

空調装置を具えた建物の一例を示す断面図である。 制御手段の構成の一例を示す概念図である。 空調装置のメンテナンス装置の構成の一例を示すブロック図である。 空調装置のメンテナンス方法の処理手順の一例を示すフローチャートである。 （ａ）は、第１グループに含まれる１つの空間のログデータの一例を示すグラフ、（ｂ）は、第２グループに含まれる１つの空間のログデータの一例を示すグラフである。 診断情報生成ステップの処理手順の一例を示すフローチャートである。 第１特定ステップの処理手順の一例を示すフローチャートである。 第２特定ステップの処理手順の一例を示すフローチャートである。 （ａ）及び（ｂ）は、第１ファンの回転数、及び、第２グループの温度差と、時間との関係の一例を示すグラフである。 第３特定ステップの処理手順の一例を示すフローチャートである。 第４特定ステップの処理手順の一例を示すフローチャートである。 空調装置診断情報の一例を示す図である。 修理情報生成ステップの処理手順の一例を示すフローチャートである。 カスタマーサービス向け情報の一例を示す図である。 ユーザー向け情報の一例を示す図である。 ユーザー向け情報生成ステップの処理手順の一例を示すフローチャートである。 スケジュールデータベースのテーブルの一例を示す図である。 再送信ステップの処理手順の一例を示すフローチャートである。

以下、本発明の実施の一形態が図面に基づき説明される。
本実施形態の空調装置のメンテナンス方法（以下、単に「メンテナンス方法」ということがある。）では、ユーザー（本例では、居住者）の建物内の空間を空調する空調装置（空調システム）がメンテナンスされる。図１は、空調装置８を具えた建物２の一例を示す断面図である。なお、図面は、発明の内容の理解を高めるためのものであり、誇張された表示が含まれる他、図面間において、縮尺等は厳密に一致していない点が予め指摘される。

建物２としては、住宅である場合が例示されているが、例えば、ビル等であってもよい。本実施形態の建物２には、床下空間３と、床上空間４とが設けられている。本実施形態において、空調装置８によって空調される空間５は、床上空間４に設けられているが、床下空間３に設けられてもよい。

床下空間３は、基礎と地面と１階の床とで囲まれた空間である。基礎には、外気Ａ１を取り入れるための開口部６が設けられている。開口部６から取り入れられた外気Ａ１は、地面を介して、１年を通じて温度変化の少ない地中の熱と熱交換される。

床上空間４は、床下空間３の上方に床を介して設けられた空間である。本実施形態の床上空間４は、複数の空間（居室）５を含んでいる。複数の空間５は、１階の空間５ａ及び５ｂと、２階の空間５ｃ及び５ｄとを含んでいる。

本実施形態の空間５は、複数のグループ７に区分されている。本実施形態のグループ７は、第１グループ７Ａ及び第２グループ７Ｂを含んで構成されているが、１つのグループのみで構成されてもよいし、３つ以上のグループで構成されてもよい。

第１グループ７Ａは、一部の空間５で構成されている。本実施形態の第１グループ７Ａは、１階の空間５ａ及び５ｂで構成されているが、これらのいずれか一方の空間のみで構成されてもよいし、他の空間が含まれてもよい。一方、第２グループ７Ｂは、第１グループ７Ａの空間５（本例では、１階の空間５ａ及び５ｂ）とは異なる空間５で構成されている。本実施形態の第２グループ７Ｂは、２階の空間５ｃ及び５ｄで構成されているが、これらのいずれか一方の空間で構成されてもよいし、他の空間が含まれてもよい。

本実施形態の空調装置（システム）８は、セントラル空調タイプのものである。空調装置８は、少なくとも１台の空気調和機９を含む１つの熱源で、建物２内の複数の空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）を空調している。本実施形態の熱源は、１台の空気調和機（エアコン）９で構成されているが、複数台の空気調和機９で構成されていてもよい。

本実施形態の空調装置８は、空気調和機（熱源）９と、温度センサー１１と、ファン１２と、ダンパー１３と、ダクト１４と、制御手段１５とを含んでいる。なお、空調装置８は、これらの構成部材に限定されるわけではなく、一部の構成部材が省略されていてもよい。

本実施形態の空気調和機９及びファン１２は、例えば、チャンバーボックス１６の内部に収容されている。チャンバーボックス１６は、その内部にスペース（空間）を有する箱状に形成されている。本実施形態のチャンバーボックス１６には、複数の空間５を循環した空気Ａ３を内部に供給するための給気口（図示省略）、及び、外気（床下空気）Ａ１を内部に供給するための外気取込口（図示省略）が設けられている。本実施形態の外気Ａ１は、ダクト１７と外気供給ファン１８とを介して、床下空間３から取り込まれている。なお、外気Ａ１は、屋外から直接取り込まれてもよい。

空気調和機９は、例えば、一般的な家庭用のセパレート型エアコンである。空気調和機９は、室内機と、建物２の外部に設置された室外機（図示省略）とをセットとして含んでいる。室内機は、吸込口（図示省略）と吹出口（図示省略）とを有している。吸込口は、室内機の内部の熱交換器（図示省略）に空気を取り込むためのものである。一方、吹出口は、熱交換器で空調された空気Ａ２を吐出するためのものである。空気調和機９の設定温度や風量は、例えば、制御手段１５によって制御される。本実施形態では、空調された空気Ａ２が、チャンバーボックス１６に設けられたフィルター１９によって浄化されているが、このような態様に限定されない。

温度センサー１１は、各空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）の温度（実温度）を計測するためのものである。本実施形態の温度センサー１１は、各空間５にそれぞれ設けられており、制御手段１５に接続されている。温度センサー１１で計測された各空間５の実温度は、制御手段１５に伝達される。

ファン１２は、空調された空気Ａ２を、複数の空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）に送るためのものである。本実施形態のファン１２は、第１ファン１２ａと、第２ファン１２ｂとを含んで構成されている。

第１ファン１２ａは、空調された空気Ａ２を、第１グループ７Ａ（本例では、１階の空間５ａ及び５ｂ）に送る（供給する）ためのものである。一方、第２ファン１２ｂは、空調された空気Ａ２を、第２グループ７Ｂ（本例では、２階の空間５ｃ及び５ｄ）に送る（供給する）ためのものである。なお、ファン１２は、空調された空気Ａ２を、１つのファンで全ての空間に供給してもよいし、３つ以上のファンで供給してもよい。ファン１２の風量は、例えば、建物２に必要な換気回数に基づいて、制御手段１５によって制御される。本実施形態のファン１２は、一定の風量となるように、回転数が制御される定風量ファンとして構成されているが、このような態様に限定されるわけではない。

ダンパー１３は、複数の空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）のそれぞれにおいて、空調された空気Ａ２の風量を調節するためのものである。本実施形態のダンパー１３は、その開度（開口面積）の大きさに応じて、空調された空気Ａ２の風量を大きくすることができる。ダンパー１３の開度は、例えば、制御手段１５によって制御される。本実施形態のダンパー１３は、各空間５にそれぞれ設けられている。

ダクト１４は、ファン１２とダンパー１３との間を接続している。本実施形態のダクト１４は、第１ダクト１４ａと、第２ダクト１４ｂとを含んで構成されている。第１ダクト１４ａは、第１ファン１２ａと、１階の空間５ａ及び５ｂに設けられたダンパー１３、１３との間を、それぞれ接続している。本実施形態の第１ダクト１４ａは、第１ファン１２ａと、１階の一方の空間５ａのダンパー１３、及び、１階の他方の空間５ｂのダンパー１３との間に、分岐部２５が設けられている。一方、第２ダクト１４ｂは、第２ファン１２ｂと、２階の空間５ｃ及び５ｄに設けられたダンパー１３、１３との間を、それぞれ接続している。本実施形態の第２ダクト１４ｂは、第２ファン１２ｂと、２階の一方の空間５ｃのダンパー１３、及び、２階の他方の空間５ｄのダンパー１３との間に、分岐部２５が設けられている。

制御手段１５は、予め定められた処理手順（制御手順）に基づいて、空調装置８を構成する各構成部材（本例では、空気調和機９、温度センサー１１、ファン１２及びダンパー１３）を制御するためのものである。本実施形態の制御手段１５は、コンピュータによって構成され、例えば、空間５の間仕切り壁等に設置されている。図２は、制御手段１５の構成の一例を示す概念図である。

制御手段１５は、例えば、ＣＰＵ（中央演算装置）からなる演算部２０と、処理手順が予め記憶されている記憶部２１と、記憶部２１から処理手順を読み込む作業用メモリ２２とを含んで構成されている。演算部２０には、入力手段２３及び出力手段２４が接続されている。

入力手段２３は、例えば、制御手段１５の筐体（図１に示す）に設けられた操作ボタンやタッチパネル等によって構成されている。この入力手段２３により、例えば、ユーザー（居住者等）によって入力された情報を、演算部２０に伝達することができる。入力される情報としては、例えば、空調装置８の設定温度（本例では、図１に示した１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄの設定温度から決定）や、空調運転の開始及び停止の指示情報等が含まれる。

出力手段２４は、制御手段１５の筐体（図１に示す）に設けられたディスプレイとして構成されている。演算部２０は、出力手段２４に信号を伝達することにより、例えば、空調装置８の運転状況等を表示させることができる。

演算部２０には、空気調和機９、温度センサー１１、ファン１２（本例では、図１に示した第１ファン１２ａ及び第２ファン１２ｂ）及びダンパー１３が接続されている。演算部２０は、温度センサー１１に信号を伝達することにより、図１に示した各空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）の実温度を、各温度センサー１１に計測させ、かつ、それらの実温度の計測結果を演算部２０に伝達させることができる。また、演算部２０は、空気調和機９及びファン１２に信号を伝達することにより、これらの運転の開始及び停止や、空気調和機９の設定温度、及び、ファン１２の風量を調節することができる。さらに、演算部２０は、ダンパー１３に信号を伝達することにより、各空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）に設けられたダンパー１３の開度をそれぞれ調節することができる。

本実施形態の記憶部２１には、空調装置８の運転状況を示すログデータが記憶される。ログデータは、過去の空調装置８の運転状況を示すものである。本実施形態のログデータは、図１に示した空調装置８が、複数の空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）それぞれを空調したときの履歴情報である。

ログデータには、空調装置８の設定温度と、空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）の実温度とが含まれる。設定温度は、ユーザーによって設定されてもよいし、制御手段１５によって日付情報等から自動で設定されてもよい。一方、空間５の実温度は、上記の各空間５ａ～５ｄについて、温度センサー１１によって計測される。

本実施形態のログデータには、上記の設定温度及び実温度の他に、空気調和機９の吸込口（図示省略）の温度と、吹出口（図示省略）の温度とが含まれている。さらに、ログデータには、第１ファン１２ａ及び第２ファン１２ｂのそれぞれの回転数が含まれている。なお、ログデータは、このような態様に限定されるわけではなく、一部が省略されてもよいし、他の履歴情報が含まれてもよい。

ログデータは、予め定められた時間間隔で記憶される。時間間隔については、適宜設定することができる。本実施形態では、例えば、５～３０分（本例では、１０分）の時間間隔で、ログデータが取得されている。これらのログデータは、記憶部２１に記憶される。

本実施形態の空調装置８では、図１に示した複数の空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）それぞれの実温度が、温度センサー１１によって計測される。そして、これらの実温度が、設定温度に近づくように、制御手段１５が、例えば、予め定められた処理手順（制御手順）に基づいて、空調装置８の構成部材（装置）を制御（例えば、空気調和機９の設定温度、ファン１２の風量及びダンパー１３の開度などを制御）している。

ところで、本実施形態のようなセントラル空調タイプの空調装置８では、複数の構成部材（本例では、空気調和機（熱源）９、温度センサー１１、ファン１２及びダンパー１３）によって構成されているため、それらの構成部材が複雑に制御されている。このため、空調装置８に不具合が発生した場合には、どの箇所に原因があるかを突き止めるのに多く時間を要するという問題がある。

さらに、不具合の原因が特定された後には、例えば、空調装置８のメンテナンスを取り扱うカスタマーサービスによって、修理に必要な部材の特定や、費用の見積もり等が行われる。さらに、部材の特定や費用の見積もりが作成されると、ユーザーの承諾を得た後に、サービスマンのスケジュール調整や、部材の納期の調整等が必要となる。このため、空調装置８に不具合が発生してから実際に修理が開始されるまでに、多くの時間を要する。とりわけ、セントラル空調タイプの空調装置８が設けられた建物２は、他の空調手段を具えていないことが多い。このため、空調装置８の不具合発生時には、一切の空調を使うことができないため、迅速な復旧が望まれる。

本実施形態において、カスタマーサービスとは、空調装置８のメンテナンス（不具合の修理を含む）を行う企業や組織等の受付窓口である。一方、サービスマンとは、空調装置８の不具合の修理等を行う技術者等である。本実施形態のサービスマンには、空気調和機９の修理を専門に行うサービスマン、ダクト１４の修理を専門に行うサービスマン、ダンパー１３の修理を専門に行うサービスマン、及び、温度センサー１１の修理を専門に行うサービスマンが含まれているが、このような態様に限定されない。例えば、サービスマンには、複数の構成部材（例えば、空気調和機９及びダクト１４）の修理を行うことが可能なサービスマンが含まれてもよい。

本実施形態のメンテナンス方法では、空調装置８の不具合の有無を判定し、不具合があると判定された場合に、空調装置８のメンテナンス（本例では、不具合が生じた空調装置８の復旧）が行われる。本実施形態のメンテナンス方法では、空調装置のメンテナンス装置（以下、単に「メンテナンス装置」ということがある。）が用いられる。図３は、空調装置８のメンテナンス装置２６の構成の一例を示すブロック図である。

本実施形態のメンテナンス装置２６は、コンピュータ２７によって構成されている。本実施形態のコンピュータ２７（メンテナンス装置２６）は、クラウドサーバとして構成されており、制御手段１５（図１及び図２に示す）と、インターネットを介して接続されている。なお、コンピュータ２７（メンテナンス装置２６）は、例えば、パーソナルコンピュータや、携帯情報端末（タブレット型等）等で構成されてもよいし、図１及び図２に示した制御手段１５で構成されてもよい。

本実施形態のメンテナンス装置２６（コンピュータ２７）は、入力デバイスとしての入力部２８、出力デバイスとしての出力部２９、及び、演算処理装置３０を有している。

入力部２８には、例えば、キーボード、マウス、又は、タッチパネル等が用いられる。出力部２９には、例えば、ディスプレイ装置又はプリンタ等が用いられる。演算処理装置３０には、各種の演算を行う演算部（ＣＰＵ）３１、データやプログラム等が記憶される記憶部３２、及び、作業用メモリ３３が含まれている。

記憶部３２は、例えば、磁気ディスク、光ディスク、ＳＳＤ又はフラッシュメモリ等で構成される不揮発性の情報記憶装置である。記憶部３２は、データ部３４及びプログラム部３５を含んで構成されている。

データ部３４は、空調装置８（図１に示す）をメンテナンスするために必要な情報を記憶するためのものである。本実施形態のデータ部３４は、ログデータ記憶部３４ａ、関係性記憶部３４ｂ、空調不良空間記憶部３４ｃ、不具合原因記憶部３４ｄ、プラン情報記憶部３４ｅ、診断情報記憶部３４ｆ、部材データベース３４ｇ、スケジュールデータベース３４ｈ、カスタマー情報記憶部３４ｉ、ユーザー情報記憶部３４ｊ及び顧客データベース３４ｋを含んで構成されている。なお、データ部３４は、このような態様に限定されるわけではなく、それらの一部（例えば、スケジュールデータベース３４ｈや、顧客データベース３４ｋ）を、別のコンピュータの記憶部（図示省略）で構成して参照されてもよい。

プログラム部３５は、演算部３１に、本実施形態のメンテナンス方法を実行させるためのプログラムである。本実施形態のプログラム部３５は、ログデータ入力部３５ａ、不具合判定部３５ｂ、診断情報生成部３５ｃ、カスタマー情報生成部３５ｄ、ユーザー情報生成部３５ｅ、ユーザー情報送信部３５ｆ、及び、カスタマー情報送信部３５ｇを含んで構成されている。プログラム部３５は、このような態様に限定されるわけではなく、一部が省略されてもよいし、他の構成が含まれてもよい。図４は、空調装置のメンテナンス方法の処理手順の一例を示すフローチャートである。

本実施形態のメンテナンス方法では、先ず、ログデータが、図３に示したコンピュータ２７（メンテナンス装置２６）に入力される（ステップＳ１）。ステップＳ１では、図３に示されるように、プログラム部３５のログデータ入力部３５ａが、作業用メモリ３３に入力される。そして、ログデータ入力部３５ａが、演算部３１によって実行される。

上述したように、本実施形態のログデータは、例えば、図２に示した制御手段１５の記憶部２１に記憶されている。本実施形態のように、図３に示したメンテナンス装置２６（コンピュータ２７）がクラウドサーバとして構成されている場合には、記憶部２１（図２に示す）に記憶されているログデータが、インターネット等を介して、メンテナンス装置２６に送信される。送信されたログデータは、ログデータ記憶部３４ａに記憶される。ログデータのデータ量（取得期間）についても、適宜設定することができる。空調装置８の不具合を確実に検知するために、本実施形態では、例えば、３０～９０日分のログデータが記憶される。

図５（ａ）は、第１グループ７Ａに含まれる１つの空間５のログデータの一例を示すグラフである。図５（ｂ）は、第２グループ７Ｂに含まれる１つの空間５のログデータの一例を示すグラフである。図５（ａ）及び（ｂ）では、図１に示した空調装置８の設定温度及び空間５の実温度と、時間との関係が示されており、空気調和機９の吸込口（図示省略）の温度、吹出口（図示省略）の温度、及び、ファン１２（第１ファン１２ａ及び第２ファン１２ｂ）の回転数については省略されている。

次に、本実施形態のメンテナンス方法では、図４に示されるように、コンピュータ２７が、空調装置８の不具合の有無を判定する（不具合判定ステップＳ２）。本実施形態の不具合判定ステップＳ２では、図３に示されるように、ログデータ記憶部３４ａに記憶されているログデータ、及び、不具合判定部３５ｂが、作業用メモリ３３に入力される。そして、不具合判定部３５ｂが、演算部３１によって実行される。

不具合判定ステップＳ２では、コンピュータ２７（メンテナンス装置２６）が、ステップＳ１で入力されたログデータを、予め定められた第１手順に従って計算して、空調装置８（図１に示す）の不具合の有無が判定される。本実施形態の不具合判定ステップＳ２は、空調装置８の設定温度と、実温度との温度差の変化に基づいて、不具合の有無が判定される。このような不具合の有無を判定するために、本実施形態の第１手順には、設定温度と実温度との温度差Ｄ（図５（ａ）及び（ｂ）に示す）を、ログデータの時間間隔ごとに計算する手順と、それらの温度差Ｄの絶対値の平均値を計算する手順とが含まれている。

温度差Ｄの計算には、図１に示した各空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）のログデータがそれぞれ用いられる。これにより、各空間５において、温度差Ｄ（例えば、図５（ａ）及び（ｂ）に示す）が計算される。また、温度差Ｄの絶対値の平均値は、各空間５について、予め定められた時間（例えば、２～４時間）分の温度差Ｄを用いて計算される。

図５（ａ）に示されるように、時間の経過とともに温度差Ｄが大きくなる空間５では、空調装置８の設定温度に対して、その実温度が乖離している。上述したように、本実施形態の空調装置８は、各空間５の実温度が設定温度に近づくように制御されるものであるため、図５（ａ）のようなログデータが取得された空間５では、空調装置８に不具合があると推測することができる。一方、図５（ｂ）に示されるように、時間の経過とともに温度差Ｄが小さくなる空間５については、上記の制御どおりに空調されているため、空調装置８に不具合はないと推測することができる。

このような観点に基づいて、本実施形態の不具合判定ステップＳ２では、時間の変化とともに温度差Ｄが大きくなる空間５（以下、単に「空調不良空間」ということがある。）が一つでもあれば、空調装置８に不具合があると判断している。

空調不良空間を特定するための判断基準については、時間の変化とともに温度差Ｄが大きくなる空間５を特定することができれば、適宜設定することができる。本実施形態の不具合判定ステップでは、例えば、ユーザーの扉の開閉等による実温度への影響を考慮して、温度差Ｄの絶対値の平均値が、予め定められた閾値（例えば、２．０～３．０℃）よりも大きい空間５を、空調不良空間として特定している。なお、平均値は、適宜計算することができ、例えば、予め定められた時間（例えば、２～４時間）分の温度差Ｄが用いられるのが望ましい。不具合判定ステップＳ２では、空調不良空間記憶部３４ｃ（図３に示す）に、空調不良空間を識別するための情報（例えば、フラグ）が記憶される。

不具合判定ステップＳ２において、空調装置８に不具合がある（本例では、空調不良空間が一つ以上ある）と判定された場合に（ステップＳ２で、「Ｙ」）、次の診断情報生成ステップＳ３が実施される。一方、不具合判定ステップＳ２において、空調装置８に不具合がない（本例では、空調不良空間が一つもない）と判定された場合（ステップＳ２で、「Ｎ」）、ログデータを入力するステップＳ１、及び、不具合判定ステップＳ２が再度実施される。これらのステップＳ１～Ｓ２の再度の実施には、予め定められた時間（例えば、１～１０時間）が経過した後に行われてもよい。

このように、本実施形態の不具合判定ステップＳ２では、コンピュータ２７（メンテナンス装置２６）が、ログデータを第１手順に従って計算することにより、例えば、サービスマンが建物２に訪問しなくても、空調装置８の不具合の有無を、容易かつ短時間に判定することができる。

次に、本実施形態のメンテナンス方法では、図４に示されるように、コンピュータ２７（メンテナンス装置２６）が、空調装置８の不具合の原因を特定した空調装置診断情報を生成する（診断情報生成ステップＳ３）。診断情報生成ステップＳ３では、図３に示されるように、ログデータ記憶部３４ａに記憶されているログデータ、空調不良空間記憶部３４ｃに記憶されている空調不良空間を識別するための情報、及び、診断情報生成部３５ｃが、作業用メモリ３３に入力される。そして、診断情報生成部３５ｃが、演算部３１によって実行される。

診断情報生成ステップＳ３では、コンピュータ２７（メンテナンス装置２６）が、ログデータを予め定められた第２手順に従って計算することによって、空調装置８の不具合の原因が特定される。本実施形態の診断情報生成ステップＳ３では、空調不良空間の組み合わせに基づいて、空調装置８の不具合の原因が特定される。このような不具合の原因を判定するために、本実施形態の第２手順には、空調不良空間の組み合わせを計算する手順が含まれる。図６は、診断情報生成ステップＳ３の処理手順の一例を示すフローチャートである。

本実施形態の診断情報生成ステップＳ３では、先ず、空調不良空間の組み合わせが計算され、その組み合わせについて判定される（ステップＳ２１）。組み合わせは、空調不良空間を識別するための情報に基づいて計算（特定）される。

ステップＳ２１において、空調不良空間の組み合わせが、図１に示した建物２内の全ての空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）である場合、これらの全ての空間５が適切に（即ち、本来の制御手順に基づいて）空調されていない。このため、全ての空間５の空調に影響する空気調和機９（図１に示す）に、空調装置８の不具合の原因がある可能性が高い。したがって、ステップＳ２１において、空調不良空間の組み合わせが、建物２内の全ての空間５である場合、空気調和機９の不具合の有無を特定するための第１特定ステップＳ２２が実施される。図７は、第１特定ステップＳ２２の処理手順の一例を示すフローチャートである。

本実施形態の第１特定ステップＳ２２では、先ず、空気調和機９（図１に示す）の空調能力が計算される（ステップＳ４１）。本実施形態の第２手順には、空気調和機９の空調能力を計算する手順が含まれている。空調能力は、例えば、ログデータに含まれる空気調和機９の吸込口（図示省略）の温度と、吹出口（図示省略）の温度とを用いて、従来と同様の手順（例えば、特開２０１７－０８３１３９号公報に記載の手順）に基づいて計算することができる。本実施形態のステップＳ４１では、上述の期間分の空調能力が、上記の時間間隔毎に計算される。

次に、本実施形態の第１特定ステップＳ２２では、空気調和機９（図１に示す）の空調能力が、予め定められた閾値以下であるか否かが判断される（ステップＳ４２）。本実施形態のステップＳ４２では、空気調和機９の空調能力の変動を考慮して、上述の期間分の空調能力の平均値が、閾値以下であるか否かが判断される。閾値については、空気調和機９に求められる空調能力に基づいて、適宜設定することができる。本実施形態の閾値は、例えば、８～１１ｋＷに設定されている。

ステップＳ４２において、空気調和機９（図１に示す）の空調能力が閾値以下である場合（ステップＳ４２で、「Ｙ」）、空気調和機９の空調能力が低下している。このような空調能力の低下は、例えば、空気調和機９の冷媒漏れや、室外機（図示省略）の設置スペースが空気調和機９の仕様に基づいて確保されていないことが原因と考えられる。この場合、空気調和機９に、空調装置８の不具合の原因があると特定される（ステップＳ４３）。ステップＳ４３では、不具合原因記憶部３４ｄ（図３に示す）に、空調装置８の不具合の原因が、空気調和機９にあることを特定する情報（例えば、フラグなど）が記憶される。この情報には、例えば、計算された空調能力の平均値等が含まれてもよい。

一方、ステップＳ４２において、空気調和機９（図１に示す）の空調能力が閾値よりも大きい場合（ステップＳ４２で、「Ｎ」）、空気調和機９に、空調装置８の不具合の原因はないと判断される。この場合、次のステップＳ４４が実施される。

上記のような空気調和機９（図１に示す）の不具合を除いて、全ての空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）が適切に空調されない原因としては、例えば、図１に示したフィルター１９の目詰まりによる圧損によって、空調された空気Ａ２が十分に供給されてないことが考えられる。このような圧損が生じている場合において、ファン１２が定風量ファンとして構成されている場合には、建物２に必要な換気回数を維持するために、図１に示したファン１２（本例では、第１ファン１２ａ及び第２ファン１２ｂの双方）の回転数が大きくなる。このような観点に基づいて、ステップＳ４４では、ログデータのファン１２の回転数が、予め定められた閾値よりも大きいか否かが判断される。

閾値については、フィルター１９（図１に示す）に目詰まりがない状態のファン１２（本例では、第１ファン１２ａ及び第２ファン１２ｂ）の回転数に基づいて、適宜設定することができる。また、ステップＳ４４では、ファン１２の回転数の変動を考慮して、ファン１２の回転数の平均値を求めて、その平均値と閾値とが比較されるのが望ましい。

ステップＳ４４において、図１に示したファン１２（本例では、第１ファン１２ａ及び第２ファン１２ｂ）の回転数が閾値よりも大きい場合（ステップＳ４４で、「Ｙ」）、フィルター１９の目詰まりによる圧損が生じている。この場合、フィルター１９に、空調装置８の不具合の原因があると特定される（ステップＳ４５）。ステップＳ４５では、不具合原因記憶部３４ｄ（図３に示す）に、空調装置８の不具合の原因が、フィルター１９にあることを特定する情報（例えば、フラグなど）が記憶される。この情報には、例えば、ファン１２の回転数等が含まれてもよい。

一方、ステップＳ４４において、ファン１２の回転数が閾値以下である場合（ステップＳ４４で、「Ｎ」）、上記のような圧損が生じておらず、空調装置８の不具合の原因を特定できない。この場合、不具合原因記憶部３４ｄ（図３に示す）に、空調装置８の不具合の原因が特定できないことを示す情報（例えば、フラグなど）が記憶され、第１特定ステップＳ２２の一連の処理が終了する。このように、ステップＳ４４において、空調装置８の不具合の原因を特定できない場合には、これまでの判断履歴（本例では、空調能力と閾値との比較結果や、ファン１２の回転数と閾値との比較結果など）が、不具合原因記憶部３４ｄ（図３に示す）に入力されてもよい。このような判断履歴は、例えば、その後に空調装置８の不具合の原因が判明した場合に、その判明した不具合の原因を判断するための新たな手順を作成するのに役立つ。この新たな手順が、第１特定ステップＳ２２に追加されることにより、不具合の原因の検知精度を向上させることができる。

次に、図６に示されるように、本実施形態の診断情報生成ステップＳ３では、ステップＳ２１において、空調不良空間の組み合わせが、図１に示した第１グループ７Ａの全ての空間５ａ及び５ｂ、又は、第２グループ７Ｂの全ての空間５ｃ及び５ｄであると判断された場合、第２特定ステップＳ２３が実施される。

第１グループ７Ａの全ての空間５ａ及び５ｂ、又は、第２グループ７Ｂの全ての空間５ｃ及び５ｄが適切に空調されない原因としては、例えば、第１グループ７Ａに第２ファン１２ｂが接続され、かつ、第２グループ７Ｂに第１ファン１２ａが接続されたことにより、本来の制御に基づいて、第１グループ７Ａ及び第２グループ７Ｂに空調された空気Ａ２を送ることができないことが考えられる。このような観点に基づいて、第２特定ステップＳ２３では、第１ファン１２ａ又は第２ファン１２ｂの不具合の有無が特定される。図８は、第２特定ステップＳ２３の処理手順の一例を示すフローチャートである。

本実施形態の第２特定ステップＳ２３では、先ず、ログデータについて、図１に示した第１ファン１２ａの回転数と、第２グループ７Ｂの温度差Ｄとの関係性（以下、単に、「第１関係性」ということがある。）が求められる（ステップＳ５１）。図９（ａ）及び（ｂ）は、第１ファン１２ａの回転数、及び、第２グループ７Ｂの温度差と、時間との関係の一例を示すグラフである。図９（ａ）及び（ｂ）において、第２グループ７Ｂの温度差Ｄは、第２グループ７Ｂの２階の空間５ｃ及び５ｄの各温度差の絶対値の平均が求められる。

本実施形態の第２手順には、第１関係性（本例では、第１ファン１２ａの回転数と、第２グループの温度差Ｄとの関係性）を計算する手順が含まれている。第１関係性については、適宜計算することができる。本実施形態では、第１関係性として、第１ファン１２ａの回転数の増加率と、第２グループの温度差Ｄの増加率との関係が求められる。なお、これらの増加率は、適宜計算することができる。本実施形態では、予め定められた期間（例えば、２～４時間）において、その期間の開始時及び終了時のそれぞれの回転数及び温度差Ｄを用いて、増加率が計算される。第１関係性は、図３に示した関係性記憶部３４ｂに記憶される。

次に、本実施形態の第２特定ステップＳ２３では、ログデータの第２ファン１２ｂの回転数と、第１グループの温度差Ｄとの関係性（以下、単に「第２関係性」ということがある。）が求められる（ステップＳ５２）。本実施形態の第２手順には、第２関係性を計算する手順が含まれている。第２関係性については、適宜計算することができる。本実施形態では、ステップＳ５１と同様に、第２ファン１２ｂの回転数の増加率と、第１グループの温度差Ｄの増加率との関係が求められる。第２関係性は、図３に示した関係性記憶部３４ｂに記憶される。

次に、本実施形態の第２特定ステップＳ２３では、第１関係性（第１ファン１２ａの回転数と、第２グループの温度差Ｄとの関係性）、又は、第２関係性（第２ファン１２ｂの回転数と、第１グループ７Ａの温度差Ｄとの関係性）に基づいて、図１に示した第１ファン１２ａ又は第２ファン１２ｂの不具合の有無が判断される（ステップＳ５３）。

例えば、第１ファン１２ａが第２グループ７Ｂに誤って接続された場合において、図９（ａ）に示されるように、第１ファン１２ａの回転数の増加率が上昇すると、第２グループ７Ｂに送られる空調された空気Ａ２の量が多くなる。これにより、例えば、第２グループ７Ｂの空間の実温度が目標温度に未達の場合（本例では、暖房時）には、第２グループの温度差Ｄが小さくなり、その温度差Ｄの増加率が低下する。

一方、図９（ｂ）に示されるように、第１ファン１２ａの回転数の増加率が低下すると、第２グループ７Ｂに送られる空調された空気Ａ２の量が少なくなる。これにより、第２グループ７Ｂの空間の実温度が目標温度に未達の場合（本例では、暖房時）には、その温度差Ｄが大きくなり、その温度差Ｄの増加率が上昇する。

このように、第１ファン１２ａが第２グループ７Ｂに誤って接続された場合において、第２グループ７Ｂの空間５の実温度が目標温度に未達の場合（本例では、暖房時）には、第１ファン１２ａの回転数と、第２グループ７Ｂの温度差Ｄとの間に、二律背反の関係がある。なお、冷房時においても、第２グループ７Ｂの空間の実温度が目標温度に未達の場合には、暖房時と同様に、二律背反の関係がある。このような二律背反の関係は、空調装置８が目的とする空調制御に反するため、第１関係性に問題がある。

なお、第２グループ７Ｂの空間５の実温度が目標温度に達成した後については、上記のような二律背反の関係とは異なり、例えば、第１ファン１２ａの回転数の増加率が上昇すると、第２グループ７Ｂの温度差Ｄの増加率も上昇する関係となる。このような関係も、空調装置８が目的とする空調制御に反するため、第１関係性に問題がある。

同様に、第２ファン１２ｂが第１グループ７Ａに誤って接続された場合において、第１グループ７Ａの空間５の実温度が目標温度に未達の場合（本例では、暖房時）には、第２ファン１２ｂの回転数と、第１グループ７Ａの温度差Ｄとの間に、二律背反の関係がある。このような二律背反の関係は、空調装置８が目的とする空調制御に反するため、第２関係性に問題がある。

なお、第１グループ７Ａの空間５の実温度が目標温度に達成した後については、上記のような二律背反の関係とは異なり、例えば、第２ファン１２ｂの回転数の増加率が上昇すると、第１グループ７Ａの温度差Ｄの増加率も上昇する関係となる。このような関係も、空調装置８が目的とする空調制御に反するため、第２関係性に問題がある。

ステップＳ５３では、第１ファン１２ａの回転数と第２グループの温度差Ｄとの間の関係性（第１関係性）、又は、第２ファン１２ｂの回転数と第１グループ７Ａの温度差Ｄとの間の関係性（第２関係性）に、問題があるか否かが判断される。

ステップＳ５３において、第１関係性又は第２関係性に問題があると判断された場合（ステップＳ５３で、「Ｙ」）、図１に示した第１ファン１２ａ又は第２ファン１２ｂが誤って接続されている可能性が高い。この場合、第１ファン１２ａ又は第２ファン１２ｂに、空調装置８の不具合の原因があると特定される（ステップＳ５４）。

ステップＳ５４では、第１関係性に問題があると判断された場合、第１ファン１２ａ（図１に示す）に、空調装置８の不具合の原因があると特定される。一方、第２関係性に問題があると判断された場合、第２ファン１２ｂ（図１に示す）に、空調装置８の不具合の原因があると特定される。本実施形態のステップＳ５４では、不具合原因記憶部３４ｄ（図３に示す）に、空調装置８の不具合の原因が、第１ファン１２ａ又は（及び）第２ファン１２ｂにあることを特定する情報（例えば、フラグなど）が記憶される。この情報には、例えば、第１関係性又は第２関係性等が含まれてもよい。

一方、ステップＳ５３において、第１関係性及び第２関係性に問題がないと判断された場合（ステップＳ５３で、「Ｎ」）、図１に示した第１ファン１２ａ及び第２ファン１２ｂに、空調装置８の不具合の原因がないと判断される。この場合、次のステップＳ５５が実施される。

上記のような第１ファン１２ａ及び第２ファン１２ｂ（図１に示す）の接続の不具合を除いて、第１グループ７Ａ又は第２グループ７Ｂ（図１に示す）が適切に空調されない原因としては、例えば、図１に示した各ダクト１４ａ又は１４ｂについて、第１ファン１２ａ又は第２ファン１２ｂから各分岐部２５、２５までの領域で潰れ等が生じ、空調された空気Ａ２が圧損によって、第１グループ７Ａ又は第２グループ７Ｂに十分に供給されていないことが考えられる。

このような圧損が生じている場合には、本実施形態のようにファン１２が定風量ファンとして構成されている場合、建物２に必要な換気回数を維持するために、ファン１２（本例では、第１ファン１２ａ及び第２ファン１２ｂの双方）の回転数が大きくなる。このため、ステップＳ５５では、ファン１２の回転数が、予め定められた閾値よりも大きいか否かが判断される。閾値については、ステップＳ４４と同様に設定することができる。

ステップＳ５５において、ファン１２（本例では、図１に示した第１ファン１２ａ又は第２ファン１２ｂ）の回転数が閾値よりも大きい場合（ステップＳ５５で、「Ｙ」）、図１に示したダクト１４ａ又は１４ｂに潰れ等が生じている可能性が高い。この場合、ダクト１４ａ又は１４ｂに、空調装置８の不具合の原因があると特定される（ステップＳ５６）。ステップＳ５６では、不具合原因記憶部３４ｄ（図３に示す）に、ダクト１４ａ又は１４ｂに、空調装置８の不具合の原因があることを特定する情報（例えば、フラグなど）が記憶される。この情報には、例えば、ファン１２の回転数等が含まれてもよい。

一方、ステップＳ５５において、ファン１２（本例では、図１に示した第１ファン１２ａ及び第２ファン１２ｂ）の回転数が閾値以下である場合（ステップＳ５５で、「Ｎ」）、上記のような圧損が生じておらず、空調装置８の不具合の原因を特定できない。この場合、不具合原因記憶部３４ｄ（図３に示す）に、空調装置８の不具合の原因が特定できないことを示す情報（例えば、フラグなど）が記憶され、第２特定ステップＳ２３の一連の処理が終了する。このように、空調装置８の不具合の原因を特定できない場合には、これまでの判断履歴が、不具合原因記憶部３４ｄ（図３に示す）に入力されてもよい。

次に、図６に示されるように、本実施形態の診断情報生成ステップＳ３では、ステップＳ２１において、空調不良空間の組み合わせが、図１に示した第１グループ７Ａの全ての空間５、及び、第２グループ７Ｂの全ての空間５ではなく、空調不良空間の組み合わせが、２つ以上の空間５であると判断された場合、第３特定ステップＳ２４が実施される。

２つ以上の空間５が適切に空調されない原因としては、例えば、図１及び図２に示したダンパー１３や温度センサー１１の制御手段１５への接続が適切でないことが考えられる。接続が適切とは、制御手段１５に接続されているダンパー１３及び温度センサー１１が設けられている空間５（例えば、１階の一方の空間５ａ）と、制御手段１５で認識されているダンパー１３及び温度センサー１１が設けられている空間５（例えば、１階の一方の空間５ａ）とが一致していることを意味している。一方、接続が適切でない場合としては、例えば、ダンパー１３及び温度センサー１１が１階の一方の空間５ａに設けられるべきところ、１階の他方の空間５ｂに設けられている場合である。このような観点に基づいて、本実施形態の第３特定ステップＳ２４では、図１及び図２に示したダンパー１３又は温度センサー１１の不具合の有無が特定される。図１０は、第３特定ステップＳ２４の処理手順の一例を示すフローチャートである。

本実施形態の第３特定ステップＳ２４では、先ず、図１及び図２に示したダンパー１３又は温度センサー１１の接続に誤りがあるか否かが判断される（ステップＳ６１）。ステップＳ６１では、プラン情報記憶部３４ｅ（図３に示す）に記憶されているプラン情報が用いられる。本実施形態のプラン情報は、建物２の設計情報である。このプラン情報には、各空間５（本例では、図１に示した１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）のダンパー１３の接続に関する情報、及び、各空間５の温度センサー１１の接続に関する情報が含まれている。

本実施形態のダンパー１３の接続に関する情報には、例えば、図１に示した各空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）のダンパー１３と制御手段１５とを接続する配線コード（図示省略）等について、それらのコードが接続される制御手段１５の端子の位置が示されている。このような情報により、制御手段１５に実際に接続されているダンパー１３と、制御手段１５で認識されているダンパー１３との関係を計算することができる。本実施形態の第２手順には、このような関係を計算する手順が含まれている。

温度センサー１１の接続に関する情報は、例えば、各空間５（本例では、１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）の温度センサー１１と制御手段１５とを接続する配線コード（図示省略）等について、それらのコードが接続される制御手段１５の端子の位置を示している。このような情報により、制御手段１５に実際に接続されている温度センサー１１と、制御手段１５で認識されている温度センサー１１との関係を特定することができる。さらに、温度センサー１１の接続に関する情報には、各空間５において、温度センサー１１が設置されている位置が含まれてもよい。

図１０に示したステップＳ６１では、上記のプラン情報に基づいて、制御手段１５に実際に接続されているダンパー１３及び温度センサー１１と、制御手段１５で認識されているダンパー１３及び温度センサー１１とが一致しているか否かが判断される。ダンパー１３及び温度センサー１１が一致してない場合には、ダンパー１３又は温度センサー１１が誤って接続されている。

ステップＳ６１において、図１に示したダンパー１３又は温度センサー１１の接続に誤りがあると判断された場合（ステップＳ６１で、「Ｙ」）、ダンパー１３又は温度センサー１１に、空調装置８の不具合の原因があると特定される（ステップＳ６２）。ステップＳ６２では、不具合原因記憶部３４ｄ（図３に示す）に、空調装置８の不具合の原因がダンパー１３又は温度センサー１１にあることを特定する情報（例えば、フラグなど）が記憶される。

一方、ステップＳ６１において、ダンパー１３及び温度センサー１１の接続に誤りがないと判断された場合（ステップＳ６１で、「Ｎ」）、次のステップＳ６３が実施される。

上記のようなダンパー１３又は温度センサー１１の不具合を除いて、２つ以上の空間５が適切に空調されない原因としては、例えば、図１に示した各ダクト１４ａ又は１４ｂについて、各分岐部２５、２５から各ダンパー１３までの領域で潰れ等が生じ、空調された空気Ａ２が圧損によって十分に供給されていないことが考えられる。このような圧損が生じている場合には、ファン１２（本例では、第１ファン１２ａ又は第２ファン１２ｂ）の回転数が大きくなる。このため、ステップＳ６３では、ファン１２の回転数が、予め定められた閾値よりも大きいか否かが判断される。閾値については、ステップＳ５５と同様に設定することができる。

ステップＳ６３において、ファン１２（本例では、第１ファン１２ａ又は第２ファン１２ｂ）の回転数が閾値よりも大きい場合（ステップＳ６３で、「Ｙ」）、ダクト１４に潰れ等が生じている可能性が高い。この場合、ダクト１４に、空調装置８の不具合の原因があると特定される（ステップＳ６４）。ステップＳ６４では、不具合原因記憶部３４ｄ（図３に示す）に、空調装置８の不具合の原因が、ダクト１４にあることを特定する情報（例えば、フラグなど）が記憶される。この情報には、例えば、ファン１２の回転数等が含まれてもよい。

一方、ステップＳ６３において、ファン１２の回転数が閾値以下である場合（ステップＳ６３で、「Ｎ」）、上記のような圧損が生じておらず、空調装置８の不具合の原因を特定できない。この場合、不具合原因記憶部３４ｄ（図３に示す）に、空調装置８の不具合の原因が特定できないことを示す情報（例えば、フラグなど）が記憶され、第３特定ステップＳ２４の一連の処理が終了する。このように、空調装置８の不具合の原因を特定できない場合には、これまでの判断履歴が、不具合原因記憶部３４ｄ（図３に示す）に入力されてもよい。

次に、図６に示されるように、本実施形態の診断情報生成ステップＳ３では、ステップＳ２１において、空調不良空間の組み合わせが、１つの空間５（図１に示す）であると判断された場合、第４特定ステップＳ２５が実施される。

１つの空間５が適切に空調されない原因としては、例えば、温度センサー１１の不具合が考えられる。この不具合の一例としては、家具などの障害物によって温度センサー１１が遮られることにより、空間５の温度を正確に測定できず、制御手段１５が、空調された空気Ａ２の供給を適切に制御できないことが考えられる。

なお、１つの空間５が適切に空調されない場合には、上述のような２つ以上の空間５が適切に空調されない場合とは異なり、ダンパー１３及び温度センサー１１の接続に誤りがある可能性は低いと考えられる。これは、一方の空間５のダンパー１３又は温度センサー１１の接続に誤りがあると、他方の空間５のダンパー１３又は温度センサー１１の接続も必然的に誤るため、２つ以上の空間５が適切に空調されなくなるためである。このような観点に基づいて、本実施形態の第４特定ステップＳ２５では、温度センサー１１の不具合が特定される。図１１は、第４特定ステップＳ２５の処理手順の一例を示すフローチャートである。

本実施形態の第４特定ステップＳ２５では、先ず、図１に示した温度センサー１１の設置位置に誤りがあるか否かが判断される（ステップＳ７１）。ステップＳ７１では、プラン情報記憶部３４ｅ（図３に示す）に記憶されているプラン情報が用いられる。本実施形態のプラン情報には、各空間５（本例では、図１に示した１階の空間５ａ及び５ｂ、並びに、２階の空間５ｃ及び５ｄ）の温度センサー１１の設置に関する情報が含まれている。この情報には、例えば、各空間５において、温度センサー１１が設置されている位置情報が含まれる。

ステップＳ７１では、上記のプラン情報に基づいて、例えば、家具などの障害物と、温度センサー１１との間の距離や位置関係を計算して、温度センサー１１の設置位置に誤りがあるか否かが判断される。本実施形態の第２手順には、上記の距離や位置関係を計算する手順が含まれている。

ステップＳ７１において、温度センサー１１の設置位置に誤りがあると判断された場合（ステップＳ７１で、「Ｙ」）、温度センサー１１に、空調装置８に不具合の原因があると特定される（ステップＳ７２）。ステップＳ７２では、不具合原因記憶部３４ｄ（図３に示す）に、空調装置８の不具合の原因が、温度センサー１１にあることを特定する情報（例えば、フラグなど）が記憶される。

一方、ステップＳ７１において、温度センサー１１（図１に示す）の設置位置に誤りがないと判断された場合（ステップＳ７１で、「Ｎ」）、次のステップＳ７３が実施される。

上記のような温度センサー１１（図１に示す）の不具合を除いて、１つの空間５が適切に空調されない原因としては、例えば、図１に示した各ダクト１４ａ又は１４ｂについて、各分岐部２５、２５から各ダンパー１３までの領域で潰れ等が生じ、空調された空気Ａ２が圧損によって十分に供給されていないことが考えられる。このような圧損が生じている場合には、ファン１２（本例では、第１ファン１２ａ又は第２ファン１２ｂ）の回転数が大きくなる。このため、ステップＳ７３では、ファン１２の回転数が、予め定められた閾値よりも大きいか否かが判断される。閾値については、ステップＳ５５と同様に設定することができる。

ステップＳ７３において、ファン１２（本例では、第１ファン１２ａ又は第２ファン１２ｂ）の回転数が閾値よりも大きい場合（ステップＳ７３で、「Ｙ」）、ダクト１４に潰れ等が生じている可能性が高い。この場合、ダクト１４に、空調装置８の不具合の原因があると特定される（ステップＳ７４）。ステップＳ７４では、不具合原因記憶部３４ｄ（図３に示す）に、不具合の原因がダクト１４にあることを特定する情報（例えば、フラグなど）が記憶される。

一方、ステップＳ７３において、ファン１２の回転数が閾値以下である場合（ステップＳ７３で、「Ｎ」）、上記のような圧損が生じておらず、空調装置８の不具合の原因を特定できない。この場合、不具合原因記憶部３４ｄ（図３に示す）に、空調装置８の不具合の原因が特定できないことを示す情報（例えば、フラグなど）が記憶され、第４特定ステップＳ２５の一連の処理が終了する。このように、空調装置８の不具合の原因を特定できない場合には、これまでの判断履歴が、不具合原因記憶部３４ｄ（図３に示す）に入力されてもよい。

次に、図６に示されるように、本実施形態の診断情報生成ステップＳ３では、空調装置８の不具合の原因を特定した空調装置診断情報が生成される（ステップＳ２６）。ステップＳ２６では、不具合原因記憶部３４ｄ（図３に示す）に記憶されている空調装置８の不具合の原因（空気調和機９）に基づいて、予め定められた形式の空調装置診断情報４１が生成される。図１２は、空調装置診断情報の一例を示す図である。図１２では、図３に示した診断情報記憶部（データベース）３４ｆに記憶されている空調装置診断情報４１が、テーブル形式で示されている。

空調装置診断情報４１に含まれる項目（情報）については、適宜設定することができる。本実施形態では、ユーザーの基本情報（例えば、氏名や住所等）、建物の基本情報（例えば、製品名や、床面積等）、及び、空調装置８の不具合の原因（不具合のある構成部材）、及び、不具合の特定に有効な情報（空調能力、ファンの回転数等）が含まれているが、このような態様に限定されない。

空調装置診断情報４１において、「ユーザーの基本情報」及び「建物の基本情報」は、適宜取得することができ、本実施形態では、予め記憶されている顧客データベース３４ｋ（図３に示す）等から取得されている。また、「空調装置８の不具合の原因」や「空調能力」等については、不具合原因記憶部３４ｄ（図３に示す）に記憶されている空調装置８の不具合の原因（空気調和機９）から取得することができる。なお、空調装置８の不具合の原因を特定できなかった場合には、「空調装置８の不具合の原因」にその旨が記載される。空調装置診断情報４１は、診断情報記憶部３４ｆに記憶される。なお、空調装置診断情報４１は、ユーザーの基本情報に基づいて、ユーザー毎に識別可能に生成されるのが望ましい。これにより、複数のユーザーの空調装置診断情報４１を、診断情報記憶部３４ｆ（図３に示す）に記憶することができる。

このように、本実施形態の診断情報生成ステップＳ３では、図４に示した不具合判定ステップＳ２において、空調装置８に不具合があると判定された場合に（ステップＳ２で、「Ｙ」）、コンピュータ２７（メンテナンス装置２６）が、ログデータを第２手順に従って計算することにより、例えば、建物２に訪問したサービスマンによって実際に調査等が行わなくても、空調装置８の不具合の原因を特定することができる。また、診断情報生成ステップＳ３において、空調装置８の不具合の原因が特定できなくても、例えば、空調装置診断情報４１に含まれる不具合の特定に有効な情報（空調能力、ファンの回転数等）に基づいて、サービスマンが不具合の原因を早期に特定することが可能となる。

次に、図４に示されるように、本実施形態のメンテナンス方法では、コンピュータ２７（メンテナンス装置２６）が、カスタマーサービス向け情報と、ユーザー向け情報とをそれぞれ生成する（修理情報生成ステップＳ４）。本実施形態の修理情報生成ステップＳ４では、図３に示されるように、診断情報記憶部３４ｆに記憶されている空調装置診断情報４１（図１２に示す）、部材データベース３４ｇ、スケジュールデータベース３４ｈ、顧客データベース３４ｋ、カスタマー情報生成部３５ｄ及びユーザー情報生成部３５ｅが、作業用メモリ３３に入力される。そして、カスタマー情報生成部３５ｄ及びユーザー情報生成部３５ｅが、演算部３１によって実行される。図１３は、修理情報生成ステップＳ４の処理手順の一例を示すフローチャートである。

本実施形態の修理情報生成ステップＳ４では、先ず、コンピュータ２７（メンテナンス装置２６）が、カスタマーサービス向け情報を生成する（ステップＳ３１）。図１４は、カスタマーサービス向け情報４７の一例を示す図である。図１４では、カスタマーサービス向け情報４７が、レポート形式で生成されているが、電子データ（テキスト形式など）として生成されてもよい。

カスタマーサービス向け情報４７は、カスタマーサービスが、空調装置８の修理に必要な部材の手配や納品に必要な情報である。カスタマーサービス向け情報４７には、空調装置８の不具合を修理するために必要な部材リスト４２が含まれる。なお、カスタマーサービス向け情報４７には、部材リスト４２の他の情報が含まれてもよい。本実施形態の部材リスト４２には、修理に必要な各部材４６について、例えば、品番、製品名、単価、個数、及び、在庫の有無が含まれている。

ステップＳ３１では、空調装置診断情報４１に含まれる空調装置８の不具合の原因（本例では、不具合のある構成部材）に基づいて、その不具合の修理に必要な部材４６に関する情報が、図３に示した部材データベース３４ｇから検索される。なお、診断情報生成ステップＳ３において、空調装置８の不具合の原因が特定できなかった場合には、部材データベース３４ｇの検索が省略されてもよい。

本実施形態の部材データベース３４ｇ（図３に示す）は、空調装置８の不具合の原因（例えば、空気調和機９など）ごとに、その不具合の修理に必要な少なくとも一つの部材４６（例えば、空気調和機９の本体、ドレンホース等）に関する情報が定義されている。部材４６に関する情報には、例えば、製品名、品番、単価、及び、個数（すなわち、修理に必要な個数）等が定義されている。これにより、ステップＳ３１では、空調装置８の不具合の原因に基づいて、その不具合の修理に必要な部材４６に関する情報を、容易に検索（取得）することができる。

さらに、部材データベース３４ｇには、各部材（製品）４６について、在庫に関する情報（現在の在庫の個数）が含まれている。これにより、ステップＳ３１では、各部材４６について、修理に必要な個数と、在庫の個数とが比較されることにより、部材リスト４２の在庫の有無に関する情報を取得することができる。本実施形態のステップＳ３１において、修理に必要な個数が、在庫の個数以下の場合には、部材リスト４２の在庫の有無に関する情報として、「有り（在庫あり）」が取得される。そして、部材データベース３４ｇの在庫の個数は、修理に必要な個数で減じられることで、最新の状態に更新されるのが望ましい。一方、修理に必要な個数が、在庫の個数よりも多い場合には、部材リスト４２の在庫の有無に関する情報として、「無し（在庫なし）」が取得される。

次に、本実施形態のステップＳ３１では、部材データベース３４ｇから取得された修理に必要な部材４６に関する情報に基づいて、図１４に示した部材リスト４２が生成される。部材リスト４２を含むカスタマーサービス向け情報は、カスタマー情報記憶部３４ｉ（図３に示す）に記憶される。

次に、本実施形態の修理情報生成ステップＳ４では、コンピュータ２７（メンテナンス装置２６）が、ユーザー向け情報を生成する（ユーザー向け情報生成ステップＳ３２）。ユーザー向け情報は、ユーザーが、空調装置８の不具合の修理を承諾するか否かを判断するのに必要な情報である。図１５は、ユーザー向け情報４３の一例を示す図である。図１５では、ユーザー向け情報がレポート形式（本例では、「故障診断レポート」）で生成されているが、このような態様に限定されない。ユーザー向け情報４３は、例えば、電子データ（テキスト形式など）として生成されてもよい。

ユーザー向け情報４３には、図１に示した空調装置８の不具合の修理のために必要な見積もり金額４８が含まれている。また、本実施形態のユーザー向け情報４３には、空調装置８の不具合の修理を実行可能な作業日（候補日）４５に関するデータが含まれている。このような情報により、ユーザーが、空調装置８の不具合の修理を承諾するか否かを、容易に判断することができる。図１６は、ユーザー向け情報生成ステップＳ３２の処理手順の一例を示すフローチャートである。

本実施形態のユーザー向け情報生成ステップＳ３２では、先ず、コンピュータ２７（図３に示す）が、空調装置８の不具合の修理のために必要な見積もり金額４８を計算する（ステップＳ８１）。本実施形態のステップＳ８１では、先ず、図１４に示したカスタマーサービス向け情報４７（部材リスト４２）の各部材４６について、それらの単価に、個数（すなわち、修理に必要な個数）がそれぞれ乗じられる。これにより、ステップＳ８１では、各部材４６のコストを求めることができる。次に、本実施形態のステップＳ８１では、カスタマーサービス向け情報４７（部材リスト４２）の全ての部材４６のコストが積算され、その積算値に、サービスマンの工賃やその他必要な経費等が加えられることで、見積もり金額４８が計算される。なお、診断情報生成ステップＳ３において、空調装置８の不具合の原因が特定できなかった場合には、見積もり金額４８の計算が省略されてもよい。

次に、本実施形態のユーザー向け情報生成ステップＳ３２では、コンピュータ２７が、空調装置８の不具合の修理を実行可能な作業日を検索する（ステップＳ８２）。ステップＳ８２では、予め記憶されたサービスマンのスケジュールデータベース３４ｈが参照される。図１７は、スケジュールデータベース３４ｈの一例を示す図である。図１７では、図３に示したスケジュールデータベース３４ｈが、テーブル形式で示されている。

スケジュールデータベース３４ｈには、不具合のある構成部材（本例では、空気調和機９など）の修理を実行するサービスマンのスケジュールが記憶されている。このスケジュールデータベース３４ｈには、例えば、検索される日から、例えば０．５～３ヶ月後までのサービスマンのスケジュールが含まれるのが望ましい。

スケジュールデータベース３４ｈに記憶されている情報としては、例えば、各サービスマンについて、氏名（又は会社名）、専門分野、サービスエリア、作業日、及び、予約状況が含まれているが、その他の情報が追加されていてもよい。専門分野には、サービスマンが修理を専門に行う構成部材（例えば、空気調和機９）に関する情報が記憶されている。サービスエリアには、サービスマンが建物２（図１に示す）に訪問修理が可能な地域に関する情報が記憶されている。作業日には、サービスマンが修理を実行可能な日が記憶されている。予約状況には、作業日に予約が入っていることを示す予約データ（例えば、「予約済」を示すフラグなど）が書き込まれる。

本実施形態のステップＳ８２では、例えば、図１２に示した空調装置診断情報４１に含まれる「空調装置８の不具合の原因（不具合のある部材）」に基づいて、スケジュールデータベース３４ｈの「専門分野」の情報から、空調装置８の不具合を修理することが可能なサービスマンが抽出される。次に、ステップＳ８２では、空調装置診断情報４１に含まれる「ユーザーの基本情報（例えば、住所）」に基づいて、抽出されたサービスマンのうち、スケジュールデータベース３４ｈの「サービスエリア」から、訪問修理可能なサービスマンが抽出される。次に、ステップＳ８２では、抽出された訪問可能なサービスマンのうち、スケジュールデータベース３４ｈの「予約状況」に予約データ（例えば、「予約済」）が書き込まれていないサービスマンが抽出される。これにより、ステップＳ８２では、予約データが書き込まれていないサービスマンについて、スケジュールデータベース３４ｈの「作業日」を、修理を実行可能な作業日として検索することができる。なお、ステップＳ８２の処理手順については、上記の手順に限定されるわけではなく、抽出される順序が前後してもよい。

また、診断情報生成ステップＳ３において、空調装置８の不具合の原因が特定できなかった場合には、例えば、不具合の原因を特定可能なサービスマンについて、調査可能な作業日が検索されてもよい。

次に、本実施形態のユーザー向け情報生成ステップＳ３２では、コンピュータ２７（メンテナンス装置２６）が、スケジュールデータベース３４ｈで検索された作業日において、予約データを書き込む（ステップＳ８３）。ステップＳ８３では、スケジュールデータベース３４ｈにおいて、ステップＳ８２で検索された少なくとも１つの作業日の「予約状況」に、予約データ（例えば、「予約済」を示すフラグ）が書き込まれる。

なお、ステップＳ８２において、複数の作業日が検索された場合には、それらの作業日のうち、予め定められた上限値（例えば、２つ）までの作業日について、予約データが書き込まれるのが望ましい。これは、検索された全ての作業日に予約データが書き込まれると、上記の検索条件が一致する他のユーザーの修理について、予約できなくなるからである。本実施形態では、検索された作業日のうち、最先の作業日に、予約データが書き込まれる。

次に、本実施形態のユーザー向け情報生成ステップＳ３２では、コンピュータ２７（メンテナンス装置２６）が、ユーザー向け情報４３を生成する（ステップＳ８４）。本実施形態のステップＳ８４では、ステップＳ８１で計算された見積もり金額、及び、ステップＳ８３で予約データが書き込まれた作業日に基づいて、図１５に示されるように、見積もり金額４８及び作業日４５に関するデータを含むユーザー向け情報４３が生成される。

ユーザー向け情報４３には、空調装置８の不具合のある箇所を示す不具合箇所５０に関するデータが含まれてもよい。この不具合箇所５０は、図１２に示した空調装置診断情報４１に含まれる「空調装置の不具合の原因」から取得することができる。ユーザー向け情報４３は、ユーザー情報記憶部３４ｊに記憶される。

次に、本実施形態のメンテナンス方法では、コンピュータ２７（メンテナンス装置２６）が、図１５に示したユーザー向け情報４３を、ユーザーに送信する（ステップＳ５）。ステップＳ５では、図３に示されるように、ユーザー情報記憶部３４ｊに記憶されているユーザー向け情報４３、及び、ユーザー情報送信部３５ｆが、作業用メモリ３３に入力される。そして、ユーザー情報送信部３５ｆが、演算部３１によって実行される。

ユーザー向け情報４３の送信方法については、適宜採用することができる。本実施形態では、ユーザー向け情報４３が、コンピュータ２７（本例では、クラウドサーバ）からインターネット等を介して、空調装置８の制御手段１５に送信されている。この場合、ユーザー向け情報４３は、制御手段１５の出力手段２４（図１に示す）に出力される。なお、ユーザー向け情報４３は、例えば、コンピュータ２７が電子メール等に添付して、ユーザーの所有する端末（例えば、スマートフォンやパソコン等）に送信されてもよいし、プリンタで印刷されたレポート等が、ユーザーに届けられてもよい。

本実施形態のメンテナンス方法では、例えば、カスタマーサービスによって、修理に必要な部材の特定や、費用の見積もり等が行われなくても、ユーザー向け情報４３を受信したユーザーに、空調装置８に不具合があること、不具合の修理に必要な金額、及び、修理可能な作業日（候補日）を同時に知らせることができる。このようなユーザー向け情報４３に基づいて、ユーザーは、修理を承諾するか否かを迅速に決定することができる。

次に、本実施形態のメンテナンス方法では、図４に示されるように、コンピュータ２７（メンテナンス装置２６）が、ユーザーが修理を承諾したことを示す承諾信号を受信したか否かを判断する（ステップＳ６）。承諾信号には、図１５に示したユーザー向け情報４３に複数の作業日４５が含まれる場合、ユーザーによって選択された作業日が含まれてもよい。

承諾信号の送信手順については、適宜選択することができる。本実施形態の承諾信号は、図２に示した制御手段１５の入力手段２３に、修理を承諾したことを示す情報を、ユーザーが入力（例えば、タッチパネルに表示された「承諾ボタン」を押下）することによって、制御手段１５からインターネット等を介して、図３に示したコンピュータ２７（本例では、クラウドサーバ）に送信される。また、他の送信手順として、承諾信号は、例えば、ユーザーの端末（例えば、スマートフォンやパソコン等）からカスタマーサービスに、修理に承諾することが記載された電子メール等を送信し、電子メール等を受信したカスタマーサービスのオペレータが、コンピュータ２７に承諾信号を送信してもよい。これらの送信手順が実行されることにより、コンピュータ２７は、承諾信号を受信することができる。

ステップＳ６において、承諾信号を受信したと判断された場合（ステップＳ６で、「Ｙ」）、コンピュータ２７（メンテナンス装置２６）が、カスタマーサービスに、ユーザー向け情報４３（図１５に示す）及びカスタマーサービス向け情報４７（図１４に示す）を送信する（ステップＳ７）。ステップＳ７では、図３に示されるように、ユーザー情報記憶部３４ｊに記憶されているユーザー向け情報４３、カスタマー情報記憶部３４ｉに記憶されているカスタマーサービス向け情報４７、及び、カスタマー情報送信部３５ｇが、作業用メモリ３３に入力される。そして、カスタマー情報送信部３５ｇが、演算部３１によって実行される。

ステップＳ７では、空調装置８の不具合の原因の特定、修理のために必要な部材の在庫確認、修理金額の見積もり、サービスマンの作業日の予約（修理実施日）、及び、ユーザーの修理の承諾が、既に完了している。このため、カスタマーサービスは、ユーザー向け情報４３（図１５に示す）及びカスタマーサービス向け情報４７（図１４に示す）に基づいて、修理に必要な部材を納品し、かつ、サービスマンを建物２（図１に示す）に派遣して、空調装置８（図１に示す）の不具合をサービスマンに修理させることができる（ステップＳ８）。このように、本実施形態のメンテナンス方法は、空調装置８の修理を早期に開始することができるため、空調装置８を迅速に復旧させることが可能となる。

一方、ステップＳ６において、承諾信号を受信していないと判断された場合（ステップＳ６で、「Ｎ」）、コンピュータ２７（図４に示す）が、ユーザーが不具合の修理を承諾しなかったことを示す非承諾信号を受信したか否かを確認する（ステップＳ９）。非承諾信号は、承諾信号と同一の手順に基づいて、コンピュータ２７に送信することができる。

ステップＳ９において、非承諾信号を受信したと判断された場合（ステップＳ９で、「Ｙ」）、コンピュータ２７（メンテナンス装置２６）が、図１７に示したスケジュールデータベース３４ｈから予約データを削除して（ステップＳ１０）、メンテナンス方法の一連の処理が終了する。なお、ステップＳ１０の後に、カスタマーサービスからユーザーに向けて、修理に関する案内が改めて行われてもよい。

ステップＳ１０では、スケジュールデータベース３４ｈにおいて、ステップＳ８３で「予約状況」に書き込まれた予約データが削除（例えば、「予約済」を示すフラグを消去）される。これにより、予約データが削除された作業日において、他のユーザーの修理の予約データを書き込むことが可能となる。

一方、ステップＳ９において、非承諾信号を受信していないと判断された場合（ステップＳ９で、「Ｎ」）、ユーザー向け情報４３をユーザーに送信してから予め定められた期間が経過したか否かが判断される（ステップＳ１１）。期間については、適宜設定することができる。本実施形態では、ユーザー向け情報４３をユーザーに送信した日から、図１７に示した予約データが書き込まれた作業日までの期間よりも短い期間に設定されている。これにより、メンテナンス方法は、予約データが書き込まれた作業日が経過する前に、後述の再送信ステップＳ１２を実施することができる。

ステップＳ１１において、ユーザー向け情報４３を送信してから上記の期間が経過したと判断された場合（ステップＳ１１で、「Ｙ」）、上記の期間内に、承諾信号を受信できていない。この場合、ユーザー向け情報４３（図１５に示す）を、ユーザーに再送信する再送信ステップＳ１２が実施される。

一方、ステップＳ１１において、ユーザー向け情報４３を送信してから上記の期間が経過していないと判断された場合（ステップＳ１１で、「Ｎ」）、ステップＳ６～ステップＳ１１が再度実施される。これにより、本実施形態のメンテナンス方法では、ユーザー向け情報４３を送信してから上記の期間が経過するまで、承認信号及び非承認信号の受信の有無を判断することができる。

次に、本実施形態の再送信ステップＳ１２では、図３に示されるように、ユーザー情報記憶部３４ｊに記憶されているユーザー向け情報４３（図１５に示す）、及び、ユーザー情報送信部３５ｆが、作業用メモリ３３に入力される。そして、ユーザー情報送信部３５ｆが、演算部３１によって実行される。図１８は、再送信ステップＳ１２の処理手順の一例を示すフローチャートである。

本実施形態の再送信ステップＳ１２では、コンピュータ２７（メンテナンス装置２６）が、先ず、図１７に示したスケジュールデータベース３４ｈから予約データを削除する（ステップＳ９１）。予約データの削除は、図４に示したステップＳ１０と同様の手順で行うことができる。

次に、本実施形態の再送信ステップＳ１２では、コンピュータ２７（図３に示す）が、図１７に示したスケジュールデータベース３４ｈを参照し、作業日を再検索する（ステップＳ９２）。作業日を再検索する手順については、作業日を検索するステップＳ８２（図１６に示す）と同一の手順で行うことができる。なお、再検索される作業日は、ステップＳ８２で検索された作業日よりも後であるのが望ましい。

次に、本実施形態の再送信ステップＳ１２では、コンピュータ２７（メンテナンス装置２６）が、図１７に示したスケジュールデータベース３４ｈに、再検索された作業日において、予約データを書き込む（ステップＳ９３）。予約データの書き込み手順については、ステップＳ８３（図１６に示す）と同一の手順で行うことができる。

次に、本実施形態の再送信ステップＳ１２では、コンピュータ２７（メンテナンス装置２６）が、再検索された作業日に関するテータを含むユーザー向け情報４３（図１５に示す）を、ユーザーに送信する（ステップＳ９４）。ステップＳ９４では、先ず、ステップＳ９３で予約データが書き込まれた作業日に基づいて、ユーザー向け情報生成ステップＳ３２（図１３に示す）で生成されたユーザー向け情報４３の作業日４５が更新される。これにより、ステップＳ９４では、再検索された作業日が反映されたユーザー向け情報４３を再生成することができる。そして、ステップＳ９４では、再生成されたユーザー向け情報４３が、ユーザーに送信される。送信方法については、ステップＳ５（図４に示す）と同一の手順で行うことができる。

本実施形態のメンテナンス方法では、再送信ステップＳ１２の終了後に、ステップＳ６～ステップＳ１１が実施される。なお、ステップＳ１１において、ユーザー向け情報４３をユーザーに送信してから上記の期間が経過したか否かの判断は、ユーザー向け情報４３が再送信された日を基準として判断される。

このように、本実施形態の再送信ステップＳ１２では、ユーザーからの承諾信号及び非承諾信号を受信できなかったとしても、再検索された新たな作業日に基づいて、更新されたユーザー向け情報４３をユーザーに再送信することができる。したがって、本実施形態のメンテナンス方法では、コンピュータ２７（メンテナンス装置２６）が承諾信号を受信次第、カスタマーサービスに、更新されたユーザー向け情報４３及びカスタマーサービス向け情報４７を送信して（ステップＳ７）、空調装置８を迅速に復旧させることが可能となる。

以上、本発明の特に好ましい実施形態について詳述したが、本発明は図示の実施形態に限定されることなく、種々の態様に変形して実施しうる。

Ｓ２ 空調装置の不具合の有無を判定する不具合判定ステップ
Ｓ３ 空調装置診断情報を生成するステップ
Ｓ４ カスタマーサービス向け情報と、ユーザー向け情報とをそれぞれ生成するステップ
Ｓ５ ユーザー向け情報を、ユーザーに送信するステップ
Ｓ７ カスタマーサービスに、ユーザー向け情報及びカスタマーサービス向け情報を送信するステップ

Claims (4)

1. ユーザーの建物内の空間を空調する空調装置をメンテナンスするための方法であって、
   前記空調装置とインターネットを介して接続され、かつ、ユーザー向け情報を前記ユーザーに送信、及び、前記ユーザー向け情報及びカスタマーサービス向け情報をカスタマーサービスに送信するためのコンピュータに、前記空調装置の運転状況を示すログデータを入力するステップと、
   前記コンピュータが、前記ログデータを予め定められた第１手順に従って計算し、前記空調装置の不具合の有無を判定する不具合判定ステップと、
   前記不具合判定ステップにおいて、前記不具合があると判定された場合に、前記コンピュータが、前記ログデータを予め定められた第２手順に従って計算し、前記不具合の原因を特定した空調装置診断情報を生成するステップと、
   前記コンピュータが、予め記憶されたサービスマンのスケジュールデータベースを参照し、前記修理を実行可能な作業日を検索するステップと、
   前記コンピュータが、前記スケジュールデータベースに、検索された前記作業日に、予約データを書き込むステップと、
   前記コンピュータが、前記空調装置診断情報に基づいて、前記不具合を修理するために必要な部材リストを含むカスタマーサービス向け情報と、前記作業日に関するデータ及び前記修理のために必要な見積もり金額を含む前記ユーザー向け情報とをそれぞれ生成するステップと、
   前記コンピュータが、前記ユーザー向け情報を、前記ユーザーに送信するステップと、
   前記コンピュータが、前記ユーザーが前記修理を承諾したことを示す承諾信号を受信したときに、カスタマーサービスに、前記ユーザー向け情報及び前記カスタマーサービス向け情報を送信するステップと、
   前記コンピュータが、前記ユーザー向け情報を送信した日から前記予約データが書き込まれた前記作業日までの期間よりも短い期間内に、前記承諾信号を受信しなかったときに、前記スケジュールデータベースから前記予約データを削除するステップと、
   前記コンピュータが、前記スケジュールデータベースを参照し、前記作業日を再検索するステップと、
   前記コンピュータが、前記スケジュールデータベースに、再検索された前記作業日に、予約データを書き込むステップと、
   前記コンピュータが、再検索された前記作業日に関するテータを含む前記ユーザー向け情報を、前記ユーザーに送信するステップとを含む、
   空調装置のメンテナンス方法。
2. 前記ログデータは、前記空調装置の設定温度と、前記空間の実温度とを含み、
   前記不具合判定ステップは、前記設定温度と前記実温度との温度差の変化に基づいて、前記不具合の有無を判定する、請求項１に記載の空調装置のメンテナンス方法。
3. 前記空調装置は、１台の空気調和機を含む１つの熱源で、前記建物内の複数の空間を空調するセントラル空調タイプであり、
   前記第２手順は、前記複数の空間のうち、前記温度差が時間の変化とともに大きくなる空間である空調不良空間の組み合わせに基づいて、前記不具合の原因を特定する手順が含まれる、請求項２に記載の空調装置のメンテナンス方法。
4. 前記コンピュータが、前記ユーザーが前記不具合の前記修理を承諾しなかったことを示す非承諾信号を受信したときに、前記スケジュールデータベースから前記予約データを削除するステップをさらに含む、請求項１ないし３のいずれか１項に記載の空調装置のメンテナンス方法。

Images