JP2022070128A - 空気調和システム - Google Patents

Abstract

【課題】各空気調和機の試運転を分散して実行することで、中間期での保守作業者の作業負担を分散して軽減できる空気調和システムを提供する。【解決手段】空気調和システムは、複数の空気調和機と、同各空気調和機と通信網を介して接続されて前記各空気調和機の機器情報を記憶するサーバと、前記各空気調和機毎に前記サーバを介して接続される端末と、を有する。前記サーバは、前記複数の空気調和機を前記機器情報に基づく複数のグループに分類する分類部と、前記グループに分類された空気調和機の試運転に関わる情報を前記端末に通知する通知部とを有する。【選択図】図１０

Description

本発明は、空気調和システムに関する。

例えば、春や秋のように空気調和機の運転が頻繁に行われないような時期（以下、中間期という）に空気調和機の試運転を行うことで、空気調和機の異常を予知又は検知する空気調和システムが提案されている。この空気調和システムでは、中間期に空気調和機の異常を予知又は検知することで、事前に保守作業が行えるため、空調運転が頻繁に行われる稼働期に保守作業で空調運転が行えなくなるような事態を回避できる。

特開２０１１－８９７５１号公報

しかしながら、従来の空気調和システムでは、中間期のある時期、例えば、５月の同一時期に保守作業者が担当する区域の全ての空気調和機で一斉に試運転が実行されてしまうと、空気調和機の異常が検知された場合に保守作業が一時期に集中してしまうことが考えられる。その結果、保守作業者側の作業負担が大きくなる。

本発明ではこのような問題に鑑み、各空気調和機の試運転を分散して実行することで、中間期での保守作業者の作業負担を分散して軽減できる空気調和システムを提供することを目的とする。

一つの態様の空気調和システムは、複数の空気調和機と、同各空気調和機と通信網を介して接続されて前記各空気調和機の機器情報を記憶するサーバと、前記各空気調和機毎に前記サーバを介して接続される端末と、を有する。前記サーバは、前記複数の空気調和機を前記機器情報に基づく複数のグループに分類する分類部と、前記グループに分類された空気調和機の試運転に関わる情報を前記端末に通知する通知部とを有する。

一つの側面として、試運転を分散して実行することで、例えば、中間期での保守作業者の作業負担を分散して軽減できる。

図１は、本実施例の空気調和システムの一例を示す説明図である。 図２は、空気調和機の構成の一例を示すブロック図である。 図３は、サーバの構成の一例を示すブロック図である。 図４は、機器管理テーブルのテーブル構成の一例を示す説明図である。 図５は、試運転管理テーブルのテーブル構成の一例を示す説明図である。 図６は、保守管理テーブルのテーブル構成の一例を示す説明図である。 図７は、スマホ端末の構成の一例を示すブロック図である。 図８は、スマホ端末の試運転要求画面の一例を示す説明図である。 図９は、スマホ端末の保守推奨画面から保守予約画面への切替画面の一例を示す説明図である。 図１０は、空気調和システムの試運転要求から保守作業完了までの処理動作の一例を示す説明図である。 図１１は、試運転要求受信処理に関わるスマホ端末内の制御部の処理動作の一例を示すフローチャートである。 図１２は、保守予約処理に関わるスマホ端末内の制御部の処理動作の一例を示すフローチャートである。 図１３は、試運転要求処理に関わるサーバ内の制御部の処理動作の一例を示すフローチャートである。 図１４は、試運転結果通知処理に関わるサーバ内の制御部の処理動作の一例を示すフローチャートである。 図１５は、予約登録処理に関わるサーバ内の制御部の処理動作の一例を示すフローチャートである。 図１６は、第１の試運転要求処理に関わるサーバ内の制御部の処理動作の一例を示すフローチャートである。 図１７は、第２の試運転要求処理に関わるサーバ内の制御部の処理動作の一例を示すフローチャートである。 図１８は、第３の試運転要求処理に関わるサーバ内の制御部の処理動作の一例を示すフローチャートである。

以下、図面に基づいて、本願の開示する空気調和システムの実施例を詳細に説明する。尚、本実施例により、開示技術が限定されるものではない。また、以下に示す各実施例は、矛盾を起こさない範囲で適宜変形しても良い。

図１は、本実施例の空気調和システム１の一例を示す説明図である。図１に示す空気調和システム１は、空気調和機２と、サーバ３と、スマホ端末４と、通信網５とを有する。空気調和機２は、各場所に配置された空気調和機である。サーバ３は、空気調和システム内の複数の空気調和機２の機器情報を管理するサーバである。スマホ端末４は本発明の端末に相当し、空気調和機２の使用者が携帯してサーバ３との通信が行えるものである。通信網５は、例えば、インターネット等の通信網である。

図２は、空気調和機２の構成の一例を示すブロック図である。図２に示す空気調和機２は、室外機１１と、室内機１２と、アダプタ１３と、リモコン１４とを有する。室外機１１は、本体１１Ａを有する。本体１１Ａには、例えば、室外ファン、圧縮機、室外熱交換器や膨張弁等が備えられている。室内機１２は、本体１２Ａと、受光部１２Ｂと、制御部１２Ｃとを有する。室内機１２は、例えば、室内に配置され、室内の空気を加熱又は冷却する空気調和機の一部である。リモコン１４は、室内機１２の利用者の操作に応じて室内機１２を遠隔操作できる。本体１２Ａには、例えば、室内ファンや室内熱交換器が備えられ、室内熱交換器で冷媒と熱交換を行った室内空気が本体１２Ａから吹き出されることで、部屋の暖房、冷房、除湿等が行われる。

アダプタ１３は、第１の通信部１３Ａと、第２の通信部１３Ｂと、記憶部１３Ｃと、制御部１３Ｄとを有する。第１の通信部１３Ａは、アダプタ１３と室内機１２内の制御部１２Ｃとを通信接続する、例えば、ＵＡＲＴ（Universal Asynchronous Receiver Transmitter）等の通信ＩＦ（Interface）である。第２の通信部１３Ｂは、アダプタ１３と通信網５との間を通信で接続するＩＦである。制御部１３Ｄは、室内機１２をＡＩ（Artificial Intelligence）制御する。アダプタ１３は、室内機１２毎に配置するものである。記憶部１３Ｃは、運転履歴メモリ１３１Ｃと、故障推定モデル１３２Ｃと、冷媒量推定モデル１３３Ｃとを有する。

運転履歴メモリ１３１Ｃは、第１の通信部１３Ａを用いて室外機１１の本体１１Ａ及び室内機１２の本体１２Ａから収集した各種の運転状態データを定期的に収集し、収集した運転状態データを記憶する。第２の通信部１３Ｂは、運転履歴メモリ１３１Ｃに記憶中の運転状態データをサーバ３に送信する。尚、後述するが、サーバ３は、空気調和機２の運転状態データを教師データとし、この教師データに基づき、冷媒量推定モデル及び故障推定モデルを生成する。更に、サーバ３は、生成した冷媒量推定モデル及び故障推定モデルを通信網５経由でアダプタ１３に送信する。アダプタ１３は、第２の通信部１３Ｂを用いてサーバ３から冷媒量推定モデル１３３Ｃ及び故障推定モデル１３２Ｃを受信し、受信した冷媒量推定モデル１３３Ｃ及び故障推定モデル１３２Ｃを記憶部１３Ｃに記憶する。

故障推定モデル１３２Ｃは、室外機１１の本体１１Ａ及び室内機１２の本体１２Ａから収集した運転状態データの一部を入力することで、室外機１１の本体１１Ａ及び室内機１２の本体１２Ａ内の故障を予知又は検知、すなわち推定する。故障推定モデル１３２Ｃは、例えば、室外熱交換器の汚れ、膨張弁のロックや、圧縮機の劣化に係る異常等の空気調和機２の故障を推定する。

冷媒量推定モデル１３３Ｃは、室外機１１の本体１１Ａ及び室内機１２の本体１２Ａから収集した運転状態データの一部を入力することで、室外機１１の本体１１Ａ及び室内機１２の本体１２Ａ内の図示せぬ冷媒回路における現在の残存冷媒量を推定する。例えば、冷媒量推定モデル１３３Ｃは、運転時の運転状態を示す運転状態データのうち、少なくとも圧縮機の回転数、圧縮機の冷媒吐出温度、熱交換器温度、膨張弁の開度及び外気温度を用いて、冷媒回路に残存する現在の冷媒量を推定する。その結果、冷媒量推定モデル１３３Ｃは、冷媒量不足による異常を推定する。

図３は、サーバ３の構成の一例を示すブロック図である。図３に示すサーバ３は、通信部３１と、操作部３２と、表示部３３と、記憶部３４と、制御部３５とを有する。記憶部３４は、機器管理テーブル３４１と、試運転管理テーブル３４２と、保守管理テーブル３４３とを有する。通信部３１は、通信網５との間の通信を行うためのインターフェースである。操作部３２は、操作コマンド等の各種情報を入力するためのインターフェースである。表示部３３は、各種情報を表示するためのインターフェースである。記憶部３４は、各種情報を記憶する領域である。制御部３５は、サーバ３全体を制御する。

図４は、機器管理テーブル３４１のテーブル構成の一例を示す説明図である。図４に示す機器管理テーブル３４１は、機器情報として空気調和機２を識別する空気調和機ＩＤに関わる情報を管理するテーブルである。機器管理テーブル３４１は、空気調和機ＩＤ３４１Ａ毎に、機種３４１Ｂと、顧客名３４１Ｃと、郵便番号３４１Ｄと、住所３４１Ｅと、端末ＩＤ３４１Ｆとを対応付けて管理する。機種３４１Ｂは、空気調和機２の機種を識別する情報である。顧客名３４１Ｃは、空気調和機２の使用者を識別する情報である。郵便番号３４１Ｄは、空気調和機２の配置場所の地域を特定する情報である。住所３４１Ｅは、空気調和機２の配置場所を特定する情報である。端末ＩＤ３４１Ｆは、空気調和機２の使用者の連絡先となるスマホ端末４の電話番号である。

図５は、試運転管理テーブル３４２のテーブル構成の一例を示す説明図である。図５に示す試運転管理テーブル３４２は、空気調和機２の使用者への試運転要求の有無を管理するテーブルである。試運転管理テーブル３４２は、空気調和機２の使用者の連絡先となるスマホ端末４の電話番号である端末ＩＤ３４２Ａ毎に、空気調和機ＩＤ３４２Ｂと、試運転要求済みフラグ３４２Ｃとを対応付けて管理する。試運転要求済みフラグ３４２Ｃは、スマホ端末４に対して空気調和機２の試運転を要求したか否かを識別する識別子である。試運転要求済みの場合、試運転要求済みフラグ３４２Ｃは“１”、試運転要求済みでない場合、試運転要求済みフラグ３４２Ｃは“０”である。

図６は、保守管理テーブル３４３のテーブル構成の一例を示す説明図である。図６に示す保守管理テーブル３４３は、空気調和機２の保守を識別する保守ＩＤ３４３Ａ毎に保守情報を管理するテーブルである。保守管理テーブル３４３は、保守ＩＤ３４３Ａ毎に、保守作業日時３４３Ｂと、保守内容３４３Ｃと、顧客情報３４３Ｄと、端末ＩＤ３４３Ｅと、空気調和機ＩＤ３４３Ｆと、保守作業実行済みフラグ３４３Ｇとを対応付けて管理する。保守作業日時３４３Ｂは、保守作業の予約日時である。保守内容は、空気調和機２の保守内容、例えば、故障内容や保守を担当する保守作業者等を識別する情報である。顧客情報３４３Ｄは、保守対象の空気調和機２の使用者を識別する、例えば、顧客名、メールアドレス、住所や郵便番号等の情報である。端末ＩＤ３４３Ｅは、保守対象の空気調和機２の使用者の連絡先となるスマホ端末４を識別する電話番号等の情報である。空気調和機ＩＤ３４３Ｆは、保守対象の空気調和機２を識別する情報である。保守作業実行済みフラグ３４３Ｇは、保守作業が実行済みであるか否かを識別する識別子である。保守作業実行済みの場合、保守作業実行済みフラグ３４３Ｇは“１”、保守作業実行済みでない場合、保守作業実行済みフラグ３４３Ｇは“０”である。

制御部３５は、生成部３５Ａと、分類部３５Ｂと、通知部３５Ｃと、管理部３５Ｄとを有する。生成部３５Ａは、各空気調和機２からの運転状態データを教師データとして故障推定モデル及び冷媒量推定モデルを生成する。分類部３５Ｂは、機器管理テーブル３４１内の機器情報に基づき、サーバ３が管理する複数の空気調和機２を後述する所定ルールに応じた複数のグループに分類する。通知部３５Ｃは、中間期内において、グループ毎に時期をずらして試運転を要求すべく、当該グループ内の空気調和機２への試運転に関わる情報、すなわち試運転要求を当該グループ内の空気調和機２の使用者のスマホ端末４に通知する。尚、試運転要求は、各空気調和機２に試運転を要求する通知である。管理部３５Ｄは、機器管理テーブル３４１、試運転管理テーブル３４２及び保守管理テーブル３４３を管理する。

図７は、スマホ端末４の構成の一例を示すブロック図である。図７に示すスマホ端末４は、通信部４１と、操作部４２と、表示部４３と、記憶部４４と、制御部４５とを有する。通信部４１は、通信網５との間の通信を行うためのインターフェースである。操作部４２は、操作コマンド等の各種情報を入力するためのインターフェースである。表示部４３は、各種情報を表示するためのインターフェースである。記憶部４４は、各種情報を記憶する領域である。制御部４５は、スマホ端末４全体を制御する。

図８は、スマホ端末４の試運転要求画面４３Ａの一例を示す説明図である。スマホ端末４は、サーバ３からの試運転要求に応じて試運転要求画面４３Ａを表示部４３に表示する。図８に示す試運転要求画面４３Ａは、顧客に対して空気調和機２の試運転を要求する画面である。試運転要求画面４３Ａは、「オフシーズン中の試運転をおすすめします。試運転を開始しますか？」のメッセージ４３１Ａと、試運転実行の「はい」のボタン４３２Ａと、試運転不要の「いいえ」のボタン４３３Ａとを有する。メッセージ４３１Ａは、空気調和機２の試運転開始をスマホ端末４の使用者に促すメッセージである。スマホ端末４は、試運転要求画面４３Ａ上のボタン４３２Ａのボタン操作を検出した場合、試運転開始を空気調和機２に送信し、試運転要求画面４３Ａを消去する。また、スマホ端末４は、試運転要求画面４３Ａ上のボタン４３３Ａのボタン操作を検出した場合、試運転要求画面４３Ａを消去する。

図９は、スマホ端末４の保守推奨画面４３Ｂから保守予約画面４３Ｃへの切替画面の一例を示す説明図である。スマホ端末４は、サーバ３からの保守推奨に応じて保守推奨画面４３Ｂを表示部４３に表示する。図９に示す保守推奨画面４３Ｂは、顧客に対して空気調和機２の保守作業の予約を要求する画面である。「故障している可能性があります。修理を依頼しますか？」のメッセージ４３１Ｂと、機種名４３２Ｂと、エラーコード４３３Ｂと、修理依頼開始の「はい」のボタン４３４Ｂと、修理依頼不要の「いいえ」のボタン４３５Ｂとを有する。メッセージ４３１Ｂは、保守作業の予約を空気調和機２の使用者に促すメッセージである。機種名４３２Ｂは、空気調和機２の機種を識別する情報である。エラーコード４３３Ｂは、エラー内容を識別するコードである。スマホ端末４は、保守推奨画面４３Ｂ上のボタン４３４Ｂのボタン操作を検出した場合、保守推奨画面４３Ｂから保守作業の予約画面である保守予約画面４３Ｃに切替える。スマホ端末４は、保守推奨画面４３Ｂ上のボタン４３５Ｂのボタン操作を検出した場合、保守推奨画面４３Ｂを消去する。

保守予約画面４３Ｃは、顧客に対して空気調和機２の保守予約内容を入力する画面である。保守予約画面４３Ｃは、名前入力欄４３１Ｃと、郵便番号入力欄４３２Ｃと、住所入力欄４３３Ｃと、メールアドレス入力欄４３４Ｃと、電話番号入力欄４３５Ｃと、希望日時入力欄４３６Ｃとを有する。更に、保守予約画面４３Ｃは、確認ボタン４３７Ｃと、キャンセルボタン４３８Ｃと、機種名４３９Ｃとを有する。名前入力欄４３１Ｃは、保守対象の空気調和機２の使用者名を入力する欄である。郵便番号入力欄４３２Ｃは、保守対象の空気調和機２の配置箇所の地域を識別する郵便番号を入力する欄である。住所入力欄４３３Ｃは、保守対象の空気調和機２の配置箇所の住所を入力する欄である。メールアドレス入力欄４３４Ｃは、保守対象の空気調和機２の使用者の連絡先であるメールアドレスを入力する欄である。電話番号入力欄４３５Ｃは、保守対象の空気調和機２の使用者の連絡先である電話番号を入力する欄である。希望日時入力欄４３６Ｃは、保守対象の空気調和機２の保守作業の希望日時を入力する欄である。機種名４３９Ｃは、保守対象の空気調和機２の機種を識別する情報である。スマホ端末４は、保守予約画面４３Ｃ上の確認ボタン４３７Ｃを検出した場合、サーバ３に対して保守内容を送信して保守予約画面４３Ｃを消去する。スマホ端末４は、保守予約画面４３Ｃ上のキャンセルボタン４３８Ｃを検出した場合、保守予約画面４３Ｃを消去する。

次に本実施例の空気調和システム１の動作について説明する。図１０は、空気調和システム１の試運転要求から保守作業完了までの処理動作の一例を示す説明図である。サーバ３は、所定タイミングで所定ルールに応じた空気調和機２の使用者のスマホ端末４に対して試運転要求を通知する（ステップＳ１）。所定タイミングは、試運転要求を発行するタイミング、例えば、１日１回のタイミングである。尚、所定タイミングは、１日１回に限定されるものではなく、例えば、２日に１回、３日に１回のように適宜変更可能である。所定ルールは、最終的に所定期間内に保守作業者６が担当する空気調和機２をグループ化する条件であって、例えば、空気調和機２の配置箇所を識別する設置地域を示す設置地域情報や空気調和機２の台数を示す台数情報に応じたグループの空気調和機２を指定する条件である。

スマホ端末４は、試運転要求を受信した場合、図８に示す試運転要求画面４３Ａを表示部４３に表示する。スマホ端末４の使用者は、試運転要求画面４３Ａを見て空気調和機２の試運転要求を認識できる。そして、スマホ端末４は、試運転要求画面４３Ａ上の試運転開始操作に応じて空気調和機２への試運転開始を要求する（ステップＳ２）。空気調和機２は、試運転開始要求に応じて試運転を実行することになる。空気調和機２は、試運転を実行した場合、その試運転結果をサーバ３に通知する（ステップＳ３）。尚、空気調和機２は、試運転を実行し、例えば、冷媒量推定モデル１３３Ｃや故障推定モデル１３２Ｃを使用して空気調和機２の異常を推定した場合に異常の内容を試運転結果として得る。

サーバ３は、空気調和機２からの試運転結果を受信し、受信内容が空気調和機２の異常の推定を示すものである場合、保守推奨をスマホ端末４に通知する（ステップＳ４）。スマホ端末４は、サーバ３からの保守推奨を受信した場合、図９に示す保守推奨画面４３Ｂを表示する。スマホ端末４の使用者は、保守推奨画面４３Ｂを見て空気調和機２の保守推奨を認識できる。スマホ端末４は、保守推奨画面４３Ｂ上の保守推奨操作に応じて、図９に示す保守予約画面４３Ｃを表示する。スマホ端末４の使用者は、保守予約画面４３Ｃを見て保守作業の予約内容を入力できる。

スマホ端末４は、保守予約画面４３Ｃ上の保守予約操作に応じて保守予約要求をサーバ３に送信する（ステップＳ５）。サーバ３は、スマホ端末４からの保守予約要求を受信した場合、保守予約内容に応じて保守作業者６に保守依頼を通知する（ステップＳ６）。尚、保守依頼は、前述した所定タイミングで所定ルールの空気調和機２のスマホ端末４に対してのみ試運転を要求した結果発生しているものであるため、中間期内で同時期に受ける保守推奨の集中を分散できる、つまり、空気調和機２の試運転の時期を分散することで試運転結果による保守依頼を分散できる。そして、保守作業者６は、保守対象の空気調和機２の保守作業を実行する（ステップＳ７）。

各空気調和機２に試運転を要求する際に、例えば、あるサービス拠点が担当する地域内の３００００台の空気調和機２の試運転を一斉に開始して、２００台の空気調和機２の保守が必要との試運転結果を取得し、そして、保守作業者６が１日で保守できる空気調和機２の台数を１００台と想定する。この場合、保守作業者６は、この地域の空気調和機２の保守作業が２００台分のため、２日間かかることになる。

本実施例の空気調和システム１では、上述した想定結果に基づき、所定タイミングを中間期内の１日毎に５回、所定ルールを同地域内の３００００台の空気調和機２のうちの６０００台を１グループとする。この場合、サーバ３は、１日毎に同地域内の６０００台の空気調和機２の使用者のスマホ端末４に対して試運転要求を行い、５日間で同地域内の全ての空気調和機２の使用者のスマホ端末４に対して試運転を要求する。その結果、１日当たりの試運転結果による保守推奨の数が減少する、つまり、保守推奨の数が５日間に分散することになる。そして、地域内の空気調和機２の試運転の時期を分散することで試運転結果から保守依頼（保守予約）が分散する。保守依頼（保守予約）が分散されることで、保守作業者６の作業も分散され、保守作業者６の作業負担を軽減できる。

図１１は、試運転要求受信処理に関わるスマホ端末４内の制御部４５の処理動作の一例を示すフローチャートである。図１１においてスマホ端末４の制御部４５は、サーバ３から試運転要求を受信したか否かを判定する（ステップＳ１１）。制御部４５は、試運転要求を受信した場合（ステップＳ１１：Ｙｅｓ）、図８に示す試運転要求画面４３Ａを表示部４３に表示する（ステップＳ１２）。その結果、スマホ端末４の使用者は、試運転要求画面４３Ａを見て空気調和機２の試運転が必要なことを認識できる。

制御部４５は、試運転要求画面４３Ａ上の試運転開始操作（ボタン４３２Ａのボタン操作）を検出したか否かを判定する（ステップＳ１３）。制御部４５は、試運転開始操作を検出した場合（ステップＳ１３：Ｙｅｓ）、空気調和機２の試運転を実行し、図１１に示す処理動作を終了する。試運転要求受信処理に関わる処理動作の終了後、スマホ端末４の使用者は、試運転要求画面４３Ａ上のボタン操作で空気調和機２の試運転を実行できる。

制御部４５は、試運転開始操作を検出しなかった場合（ステップＳ１３：Ｎｏ）、試運転不要操作（ボタン４３３Ａのボタン操作）を検出したか否かを判定する（ステップＳ１４）。制御部４５は、試運転不要操作を検出した場合（ステップＳ１４：Ｙｅｓ）、試運転を実行することなく、図１１に示す処理動作を終了する。

制御部４５は、試運転要求を受信しなかった場合（ステップＳ１１：Ｎｏ）、図１１に示す処理動作を終了する。制御部４５は、試運転不要操作を検出しなかった場合（ステップＳ１４：Ｎｏ）、試運転開始操作を検出したか否かを判定すべく、ステップＳ１３に移行する。

図１２は、保守予約処理に関わるスマホ端末４内の制御部４５の処理動作の一例を示すフローチャートである。図１２に示すスマホ端末４内の制御部４５は、サーバ３から保守推奨を受信したか否かを判定する（ステップＳ２１）。制御部４５は、保守推奨を受信した場合（ステップＳ２１：Ｙｅｓ）、図９に示す保守推奨画面４３Ｂを表示部４３に表示する（ステップＳ２２）。その結果、スマホ端末４の使用者は、保守推奨画面４３Ｂを見て空気調和機２の試運転結果を認識できる。

制御部４５は、保守推奨画面４３Ｂ上の保守推奨開始操作（ボタン４３４Ｂのボタン操作）を検出したか否かを判定する（ステップＳ２３）。制御部４５は、保守推奨開始操作を検出した場合（ステップＳ２３：Ｙｅｓ）、保守予約画面４３Ｃを表示部４３に表示する（ステップＳ２４）。その結果、スマホ端末４の使用者は、保守予約画面４３Ｃを見て、空気調和機２の保守予約の入力内容を認識できる。制御部４５は、保守予約画面４３Ｃ上の保守予約開始操作（確認ボタン４３７Ｃのボタン操作）を検出したか否かを判定する（ステップＳ２５）。

制御部４５は、保守予約画面４３Ｃ上の保守予約開始操作を検出した場合（ステップＳ２５：Ｙｅｓ）、保守予約要求をサーバ３に送信し（ステップＳ２６）、図１２に示す処理動作を終了する。その結果、スマホ端末４の使用者は、保守予約画面４３Ｃから保守予約を入力できる。使用者は、スマホ端末４を使用して、保守対象の空気調和機２に関わる顧客名、郵便番号、住所、メールアドレス、電話番号、保守希望日時、空気調和機の機種名４３９Ｃ等を含む予約情報を入力できる。制御部４５は、保守推奨を受信しなかった場合（ステップＳ２１：Ｎｏ）、図１２に示す処理動作を終了する。

制御部４５は、保守推奨開始操作を検出しなかった場合（ステップＳ２３：Ｎｏ）、保守推奨不要操作（ボタン４３５Ｂのボタン操作）を検出したか否かを判定する（ステップＳ２７）。制御部４５は、保守推奨不要操作を検出した場合（ステップＳ２７：Ｙｅｓ）、保守推奨画面４３Ｂを消去し（ステップＳ２８）、図１２に示す処理動作を終了する。

制御部４５は、保守推奨不要操作を検出しなかった場合（ステップＳ２７：Ｎｏ）、保守推奨開始操作を検出したか否かを判定すべく、ステップＳ２３に移行する。

また、制御部４５は、保守予約開始操作を検出しなかった場合（ステップＳ２５：Ｎｏ）、保守予約不要操作（キャンセルボタン４３８Ｃのボタン操作）を検出したか否かを判定する（ステップＳ２９）。制御部４５は、保守予約不要操作を検出した場合（ステップＳ２９：Ｙｅｓ）、保守予約画面４３Ｃを消去し（ステップＳ３０）、図１２に示す処理動作を終了する。また、制御部４５は、保守予約不要操作を検出しなかった場合（ステップＳ２９：Ｎｏ）、保守予約開始操作を検出したか否かを判定すべく、ステップＳ２５に移行する。

図１３は、試運転要求処理に関わるサーバ３内の制御部３５の処理動作の一例を示すフローチャートである。図１３においてサーバ３内の制御部３５は、所定タイミングを検出したか否かを判定する（ステップＳ３１）。制御部３５は、所定タイミングを検出した場合（ステップＳ３１：Ｙｅｓ）、機器管理テーブル３４１を参照し、所定ルールに応じたグループの未指定の空気調和機ＩＤを指定する（ステップＳ３２）。

制御部３５は、機器管理テーブル３４１を参照し、指定の空気調和機ＩＤに対応した端末ＩＤを特定する（ステップＳ３３）。制御部３５は、特定の端末ＩＤに基づくスマホ端末４に試運転要求を送信する（ステップＳ３４）。その結果、サーバ３は、所定タイミングに所定ルールで指定した空気調和機ＩＤに対応した空気調和機２のスマホ端末４にのみ試運転を要求する。制御部３５は、試運転要求を送信済みのスマホ端末４の端末ＩＤに対応する試運転要求済みフラグ３４２Ｃを“１”に設定して試運転管理テーブル３４２の内容を更新する（ステップＳ３５）。サーバ３は、試運転管理テーブル３４２の試運転要求済みフラグ３４２Ｃを参照し、試運転要求済みの空気調和機ＩＤ及び端末ＩＤを認識できる。

更に、制御部３５は、試運転要求済みフラグ３４２Ｃを“１”に更新した後、未指定の空気調和機ＩＤがあるか否かを判定する（ステップＳ３６）。制御部３５は、未指定の空気調和機ＩＤがある場合（ステップＳ３６：Ｙｅｓ）、所定タイミングを検出したか否かを判定すべく、ステップＳ３１に移行する。つまり、サーバ３は、所定タイミング毎に所定ルールに適した未指定の空気調和機ＩＤを指定できる。制御部３５は、未指定の空気調和機ＩＤがない場合（ステップＳ３６：Ｎｏ）、図１３に示す処理動作を終了する。制御部３５は、所定タイミングを検出しなかった場合（ステップＳ３１：Ｎｏ）、所定タイミングを検出したか否かを判定すべく、ステップＳ３１に移行する。つまり、サーバ３は、所定タイミングを検出するまで試運転を要求しない。

図１４は、試運転結果通知処理に関わるサーバ３内の制御部３５の処理動作の一例を示すフローチャートである。図１４においてサーバ３内の制御部３５は、空気調和機２から試運転結果を受信したか否かを判定する（ステップＳ４１）。尚、空気調和機２は、故障推定モデル１３２Ｃ及び冷媒量推定モデル１３３Ｃを用いて空気調和機２の異常を検知した場合、その試運転結果をサーバ３に送信する。制御部３５は、試運転結果を受信した場合（ステップＳ４１：Ｙｅｓ）、試運転結果から空気調和機ＩＤ及び保守内容を抽出する（ステップＳ４２）。

制御部３５は、試運転管理テーブル３４２を参照し、抽出した空気調和機ＩＤに対応する端末ＩＤを特定し（ステップＳ４３）、特定の端末ＩＤに基づくスマホ端末４に保守推奨を送信し（ステップＳ４４）、図１４に示す処理動作を終了する。その結果、サーバ３は、各空気調和機２からの試運転結果に応じて空気調和機２の使用者のスマホ端末４に対して保守推奨を送信できる。制御部３５は、試運転結果を受信しなかった場合（ステップＳ４１：Ｎｏ）、図１４に示す処理動作を終了する。

図１５は、予約登録処理に関わるサーバ３内の制御部３５の処理動作の一例を示すフローチャートである。図１５においてサーバ３内の制御部３５は、スマホ端末４から保守予約要求を受信したか否かを判定する（ステップＳ５１）。制御部３５は、保守予約要求を受信した場合（ステップＳ５１：Ｙｅｓ）、保守予約要求から予約情報を抽出する（ステップＳ５２）。尚、予約情報とは、保守対象の空気調和機２に関わる顧客名、郵便番号、住所、メールアドレス、電話番号、保守希望日時、空気調和機の機種名４３９Ｃ等を含む情報である。

制御部３５は、予約情報内の保守作業日時、保守内容、顧客情報、端末ＩＤ及び空気調和機ＩＤを保守管理テーブル３４３に登録する（ステップＳ５３）。サーバ３は、保守管理テーブル３４３を参照して、保守ＩＤ毎の予約情報を確認できる。制御部３５は、保守内容に対応した保守作業者６を選択し（ステップＳ５４）、保守作業者６に保守内容を通知し（ステップＳ５５）、図１５に示す処理動作を終了する。制御部３５は、保守予約要求を受信しなかった場合（ステップＳ５１：Ｎｏ）、図１５に示す処理動作を終了する。

以上、説明したように本実施例のサーバ３は、管理する複数の空気調和機２を所定ルールに応じたグループに分け、中間期内において、グループ毎に時期をずらして試運転を要求すべく、当該グループ内の空気調和機２への試運転要求を当該グループ内の空気調和機２の使用者のスマホ端末４に通知する。その結果、各空気調和機２の試運転を行う時期を分散できるため、中間期の一時期に保守作業が集中することを抑制でき、保守作業者６の作業負担を軽減できる。しかも、中間期に保守作業を行うことで、稼働時期に空気調和機２が保守作業で運転できなくなるような事態を回避できる。

スマホ端末４は、試運転要求を受信した場合に、所定操作に応じて当該スマホ端末４の使用者に対応した空気調和機２に対して試運転の開始を要求する。更に、空気調和機２は、試運転の開始の要求に応じて試運転を実行し、当該空気調和機２の保守を要する試運転の結果を検出した場合に当該試運転の結果をサーバ３に通知する。そして、サーバ３は、空気調和機２から試運転の結果を受信した場合に、当該空気調和機２の使用者のスマホ端末４に対して空気調和機２の保守の推奨を通知する。その結果、各スマホ端末４の使用者は、時期をずらして実行した空気調和機２の試運転の試運転結果で保守の推奨を得るため、迅速に保守作業を受けることができ、稼働時期に空気調和機２が保守作業で運転できなくなるような事態を回避できる。

スマホ端末４は、サーバ３から保守の推奨を受信した場合に、所定の予約操作に応じて当該空気調和機２の保守作業の予約に関わる情報をサーバ３に通知する。その結果、顧客は、容易に保守作業を予約できる。

空気調和機２は試運転の開始に応じて、故障推定モデル１３２Ｃを使用して当該空気調和機２の故障を推定した場合に試運転の結果としてサーバ３に通知する。その結果、各空気調和機２は、故障推定モデル１３２Ｃを用いて試運転の結果をサーバ３に通知できる。

空気調和機２は、空気調和機２の試運転の開始に応じて、冷媒量推定モデル１３３Ｃを使用して当該空気調和機２内を流通する現在の残存冷媒量の不足を推定した場合に試運転の結果としてサーバ３に通知する。その結果、各空気調和機２は、冷媒量推定モデル１３３Ｃを用いて試運転の結果をサーバ３に通知できる。

本実施例の試運転要求処理としては、図１３に示す所定ルールに応じた未指定の空気調和機ＩＤを指定する場合を例示したが、所定ルールのより具体的な例を、図１６～図１８に基づき、説明する。

図１６は、第１の試運転要求処理に関わるサーバ３内の制御部３５の処理動作の一例を示すフローチャートである。図１６においてサーバ３内の制御部３５は、所定タイミングを検出したか否かを判定する（ステップＳ６１）。制御部３５は、所定タイミングを検出した場合（ステップＳ６１：Ｙｅｓ）、機器管理テーブル３４１を参照し、所定ルールとしてグループを識別する郵便番号で地域を指定する（ステップＳ６２）。尚、所定ルールは、空気調和機２の配置箇所を使用者により登録された郵便番号でグループ分けし、各郵便番号に対応する空気調和機２の空気調和機ＩＤを当該郵便番号のグループに紐付ける。または、郵便番号に代えて、空気調和機２が設置された市町村単位でグループ分けをしても良い。

制御部３５は、機器管理テーブル３４１を参照し、指定地域内の未指定の空気調和機ＩＤを指定する（ステップＳ６３）。制御部３５は、機器管理テーブル３４１を参照し、指定の空気調和機ＩＤに対応した端末ＩＤを特定する（ステップＳ６４）。制御部３５は、特定の端末ＩＤに基づくスマホ端末４に試運転要求を送信する（ステップＳ６５）。制御部３５は、試運転要求を送信済みのスマホ端末４の端末ＩＤに対応する試運転要求済みフラグ３４２Ｃを“１”に設定して試運転管理テーブル３４２の内容を更新する（ステップＳ６６）。

更に、制御部３５は、試運転要求済みフラグ３４２Ｃを“１”に設定した後、未指定の地域があるか否かを判定する（ステップＳ６７）。制御部３５は、未指定の地域がある場合（ステップＳ６７：Ｙｅｓ）、所定タイミングを検出したか否かを判定すべく、ステップＳ６１に移行する。制御部３５は、未指定の地域がない場合（ステップＳ６７：Ｎｏ）、図１６に示す処理動作を終了する。制御３５部は、所定タイミングを検出しなかった場合（ステップＳ６１：Ｎｏ）、所定タイミングを検出したか否かを判定すべく、ステップＳ６１に移行する。

第１の試運転要求処理を実行する制御部３５は、所定タイミング毎に空気調和機２の配置箇所を識別する所定のルールとして複数の郵便番号から未指定の郵便番号に対応した地域を指定し、指定地域内の未指定の空気調和機ＩＤを指定する。更に、制御部３５は、指定の空気調和機２の端末ＩＤに基づき、指定の空気調和機２の使用者のスマホ端末４に試運転を要求する。その結果、指定地域毎に空気調和機２の使用者のスマホ端末４に対する試運転要求を分散して試運転結果の取得時期を分散するため、保守予約の時期も分散できる。保守予約の時期が分散されることで、保守作業者６の作業も分散され、保守作業者６の作業負担を軽減できる。しかも、地域単位で試運転要求を分散したので、保守作業者６の保守作業時の移動距離を短縮化することで保守作業者６の作業負担を軽減できる。

図１７は、第２の試運転要求処理に関わるサーバ３内の制御部３５の処理動作の一例を示すフローチャートである。図１７においてサーバ３内の制御部３５は、所定タイミングを検出したか否かを判定する（ステップＳ７１）。制御部３５は、所定タイミングを検出した場合（ステップＳ７１：Ｙｅｓ）、機器管理テーブル３４１を参照し、複数の空気調和機ＩＤから所定ルールとして所定台数の空気調和機ＩＤを指定する（ステップＳ７２）。

制御部３５は、機器管理テーブル３４１を参照し、指定の空気調和機ＩＤに対応した端末ＩＤを特定する（ステップＳ７３）。制御部３５は、特定の端末ＩＤに基づくスマホ端末４に試運転要求を送信する（ステップＳ７４）。制御部３５は、試運転要求を送信済みのスマホ端末４の端末ＩＤに対応する試運転要求済みフラグ３４２Ｃを“１”に設定して試運転管理テーブル３４２の内容を更新する（ステップＳ７５）。

更に、制御部３５は、試運転要求済みフラグ３４２Ｃを“１”に設定した後、未指定の空気調和機ＩＤがあるか否かを判定する（ステップＳ７６）。制御部３５は、未指定の空気調和機ＩＤがある場合（ステップＳ７６：Ｙｅｓ）、所定タイミングを検出したか否かを判定すべく、ステップＳ７１に移行する。制御部３５は、未指定の空気調和機ＩＤがない場合（ステップＳ７６：Ｎｏ）、図１７に示す処理動作を終了する。制御部３５は、所定タイミングを検出しなかった場合（ステップＳ７１：Ｎｏ）、所定タイミングを検出したか否かを判定すべく、ステップＳ７１に移行する。

第２の試運転要求処理を実行する制御部３５は、所定タイミング毎に複数の空気調和機ＩＤから所定のルールとして未指定の所定台数の空気調和機ＩＤを指定し、指定の空気調和機２の端末ＩＤに基づき、指定の空気調和機２の使用者のスマホ端末４に試運転を要求する。その結果、所定台数毎に空気調和機２の使用者のスマホ端末４に対する試運転要求を分散して試運転結果の収集時期を分散するため、保守予約の時期も分散できる。保守予約の時期が分散されることで、保守作業者６の作業も分散され、保守作業者６の作業負担を軽減できる。例えば、空気調和機２の試運転台数を平準化して保守作業件数を抑えることで、保守作業者６の作業負担を軽減できる。

尚、所定のルールとして、所定タイミング毎に複数の空気調和機ＩＤから未指定の所定台数の空気調和機ＩＤを指定する場合を例示したが、これとは異なる所定のルールとして、所定タイミング毎に空気調和機２の配置箇所を識別する、市町村等の地域を指定し、指定した地域内で未指定の所定台数の空気調和機ＩＤを指定しても良い。

図１８は、第３の試運転要求処理に関わるサーバ３内の制御部３５の処理動作の一例を示すフローチャートである。図１８においてサーバ３内の制御部３５は、所定タイミングを検出したか否かを判定する（ステップＳ８１）。制御部３５は、所定タイミングを検出した場合（ステップＳ８１：Ｙｅｓ）、機器管理テーブル３４１を参照し、所定ルールとして未指定の機種を指定する（ステップＳ８２）。

制御部２５は、未指定の機種に対応する台数を指定する（ステップＳ８３）。制御部３５は、機器管理テーブル３４１を参照し、指定機種の空気調和機ＩＤの内、指定台数の未指定の空気調和機ＩＤを指定する（ステップＳ８４）。

制御部３５は、機器管理テーブル３４１を参照し、指定の空気調和機ＩＤに対応した端末ＩＤを特定する（ステップＳ８５）。制御部３５は、特定の端末ＩＤに基づくスマホ端末４に試運転要求を送信する（ステップＳ８６）。制御部３５は、試運転要求を送信済みのスマホ端末４の端末ＩＤに対応する試運転要求済みフラグ３４２Ｃを“１”に設定して試運転管理テーブル３４２の内容を更新する（ステップＳ８７）。

更に、制御部３５は、試運転要求済みフラグ３４２Ｃを“１”に設定した後、指定機種の未指定の空気調和機ＩＤの内、未指定の空気調和機ＩＤがあるか否かを判定する（ステップＳ８８）。制御３５部は、未指定の空気調和機ＩＤがある場合（ステップＳ８８：Ｙｅｓ）、所定タイミングを検出したか否かを判定する（ステップＳ８９）。

制御部３５は、所定タイミングを検出した場合（ステップＳ８９：Ｙｅｓ）。指定機種に対応する指定台数を指定すべく、ステップＳ８３に移行する。また、制御部３５は、所定タイミングを検出したのでない場合（ステップＳ８９：Ｎｏ）、所定タイミングを検出したか否かを判定すべく、ステップＳ８９に移行する。

制御部３５は、指定機種の未指定の空気調和機ＩＤの内、未指定の空気調和機ＩＤがない場合（ステップＳ８８：Ｎｏ）、未指定の機種があるか否かを判定する（ステップＳ９０）。制御部３５は、未指定の機種がある場合（ステップＳ９０：Ｙｅｓ）、未指定の機種を指定すべく、ステップＳ８２に移行する。また、制御部３５は、未指定の機種がない場合（ステップＳ９０：Ｎｏ）、図１８に示す処理動作を終了する。

また、制御部３５は、所定タイミングを検出したのでない場合（ステップＳ８１：Ｎｏ）、図１８に示す処理動作を終了する。

第３の試運転要求処理を実行する制御部３５は、所定タイミング毎に、所定ルールとして複数の機種から未指定の機種を指定し、指定機種の未指定の空気調和機ＩＤから所定台数の未指定の空気調和機ＩＤを指定する。更に、指定の空気調和機２の端末ＩＤに基づき、指定の空気調和機２の使用者のスマホ端末４に試運転を要求する。その結果、指定機種の所定台数毎に空気調和機２の使用者のスマホ端末４に対する試運転要求を分散して試運転結果の取得時期を分散するため、保守予約の時期も分散できる。保守予約の時期が分散されることで、保守作業者６の作業も分散され、保守作業者６の作業負担を軽減できる。例えば、故障率の高い機種の１日の試運転台数を小さくすることで、保守作業者６の作業負担を軽減できる。

尚、説明の便宜上、サーバ３は、空気調和機２の使用者のスマホ端末４に対して試運転を要求すると共に、空気調和機２で収集した運転状態データに基づき、空気調和機２毎の冷媒量推定モデルや故障推定モデルを生成する場合を例示した。しかしながら、冷媒量推定モデルや故障推定モデルを生成する機能を別のサーバで実行しても良く、適宜変更可能である。

サーバ３は、空気調和機２の故障を推定した場合に空気調和機２の保守の推奨をスマホ端末４に通知する場合を例示した。しかしながら、空気調和機２の故障を推定した場合に限定されるものではない。サーバ３は、例えば、空気調和機２の故障率が所定閾値以上、空気調和機２の保守作業頻度が所定回数以上、空気調和機２の運転積算時間が所定時間以上の場合でも、空気調和機２の保守の推奨を通知しても良い。また、サーバ３は、空気調和機２の商品発売時期が所定期間以上経過や、空気調和機２の商品保証期間が所定期間以上経過の場合でも、空気調和機２の保守の推奨を通知しても良い。

また、空気調和機２は、故障推定モデル１３２Ｃ及び冷媒量推定モデル１３３Ｃを用いて空気調和機２の故障を推定する場合を例示した。しかしながら、空気調和機２の制御部１３Ｄは、試運転開始に応じて、空気調和機２内の各種センサを通じて、例えば、空気調和機２の電源投入不良、リモコン動作不良、冷房運転不可、暖房運転不可、風向板動作不良や吐出温度異常等の故障を検知しても良い。

空気調和機２は、スマホ端末４からの試運転開始操作を検出した場合、試運転を実行する場合を例示した。これに代えて、空気調和機２が試運転開始操作を検出したときに、室内機１２の図示せぬ人検知センサで空調空間内で人を検知した場合は試運転の実行を保留し、空調空間内で人を検知しなくなってから試運転を実行しても良い。また、空気調和機２の使用者から事前に承諾を得たうえで、スマホ端末４からの試運転操作を検出しなくても、サーバ３から空気調和機２に試運転の実行が要求されれば試運転を実行しても良い。

また、空気調和機２は、スマホ端末４からの試運転開始操作を検出した場合、試運転を実行する場合を例示した。しかしながら、スマホ端末４からの試運転開始操作に限定されるものではない。使用者は、スマホ端末４への試運転に関わる情報の表示画面を見て、空気調和機２のリモコン１４等を使用して試運転開始操作を実行してもよく、適宜変更可能である。

また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

更に、各装置で行われる各種処理機能は、ＣＰＵ（Central Processing Unit）（又はＭＰＵ（Micro Processing Unit）、ＭＣＵ（Micro Controller Unit）等のマイクロ・コンピュータ）上で、その全部又は任意の一部を実行するようにしても良い。また、各種処理機能は、ＣＰＵ（又はＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしても良いことは言うまでもない。

１ 空気調和システム
２ 空気調和機
３ サーバ
４ スマホ端末
３５ 制御部
３５Ａ 生成部
３５Ｂ 分類部
３５Ｃ 通知部
１３２Ｃ 故障推定モデル
１３３Ｃ 冷媒量推定モデル

Claims (10)

1. 複数の空気調和機と、同各空気調和機と通信網を介して接続されて前記各空気調和機の機器情報を記憶するサーバと、前記各空気調和機毎に前記サーバを介して接続される端末と、を有する空気調和システムであって、
   前記サーバは、
   前記複数の空気調和機を前記機器情報に基づく複数のグループに分類する分類部と、
   前記グループに分類された空気調和機の試運転に関わる情報を前記端末に通知する通知部と
   を有することを特徴とする空気調和システム。
2. 前記試運転に関わる情報は、前記空気調和機に対する試運転の実行を前記端末に要求する情報であることを特徴とする請求項１に記載の空気調和システム。
3. 前記機器情報は前記空気調和機が設置された地域を識別する設置地域情報を含み、前記分類部は前記機器情報に基づき、前記複数の空気調和機を設置地域毎のグループに分類することを特徴とする請求項１又は２に記載の空気調和システム。
4. 前記機器情報は前記空気調和機が設置された台数を識別する台数情報を含み、前記分類部は前記機器情報に基づき、前記複数の空気調和機を所定台数毎のグループに分類することを特徴とする請求項１～３の何れか一つに記載の空気調和システム。
5. 前記機器情報は空気調和機の機種を識別する機種情報を含み、前記分類部は前記機器情報に基づき、前記複数の空気調和機を前記空気調和機の機種毎のグループに分類することを特徴とする請求項１～４の何れか一つに記載の空気調和システム。
6. 前記端末は、
   前記試運転に関わる情報を受信した場合に、所定操作に応じて前記端末に対応した前記空気調和機に対して前記通信網を介して試運転の開始を要求し、
   前記空気調和機は、
   前記試運転の開始の要求に応じて試運転を実行し、前記空気調和機の保守を要する前記試運転の結果を検出した場合に前記試運転の結果を前記サーバに通知し、
   前記サーバは、
   前記空気調和機から前記試運転の結果を受信した場合に、前記端末に対して前記空気調和機への保守の推奨を通知する
   ことを特徴とする請求項１～５の何れか一つに記載の空気調和システム。
7. 前記端末は、
   前記サーバから前記保守の推奨を受信した場合に、所定の予約操作に応じて前記空気調和機の保守作業の予約に関わる情報を前記サーバに通知する
   ことを特徴とする請求項６に記載の空気調和システム。
8. 前記端末は、
   前記試運転に関わる情報を受信した場合に、前記試運転に関わる情報を表示し、
   前記空気調和機は、
   所定操作に応じて前記空気調和機に対する試運転の開始を要求し、前記試運転の開始の要求に応じて試運転を実行し、当該空気調和機の保守を要する前記試運転の結果を検出した場合に当該試運転の結果を前記サーバに通知し、
   前記サーバは、
   前記空気調和機から前記試運転の結果を受信した場合に、前記端末に対して前記空気調和機への保守の推奨を通知する
   ことを特徴とする請求項１～５の何れか一つに記載の空気調和システム。
9. 前記空気調和機は、
   前記空気調和機の運転状態データを用いて故障の有無を推定する故障推定モデルを有し、前記空気調和機の試運転時に前記故障推定モデルを使用して当該空気調和機の故障を推定した場合に前記試運転の結果を前記サーバに通知する
   ことを特徴とする請求項１～８の何れか一つに記載の空気調和システム。
10. 前記空気調和機は、
    前記空気調和機の運転状態データを用いて冷媒量を推定する冷媒量推定モデルを有し、前記空気調和機の試運転時に前記冷媒量推定モデルを使用して当該空気調和機の冷媒量を推定した場合に前記試運転の結果を前記サーバに通知する
    ことを特徴とする請求項１～８の何れか一つに記載の空気調和システム。

Images