WO2023148811A1 - 空気調和システムおよび空気調和装置 - Google Patents

Abstract

空調システム（１）は、空気調和装置（２００）と、サーバ（１００）とを備える。空気調和装置は、空調ソフトウェアを格納するメモリ（２１２）と、メモリの空調ソフトウェアを実行するプロセッサ（２１１）とを有する。空調ソフトウェアは、複数の応用プログラムと、基本プログラムとを含む。サーバは、プロセッサが複数の応用ソフトウェアのうちの１つを更新するために必要な第１更新用データを空気調和装置に配信し、プロセッサは、第１更新用データに基づいて、基本ソフトウェアを用いてメモリ内の対応する応用ソフトウェアを更新する。

Description

空気調和システムおよび空気調和装置

　本開示は、空気調和システムおよび空気調和装置に関する。

　従来、更新用ソフトウェアを格納するサーバと、制御ソフトウェアをサーバから受信した更新用ソフトウェアで更新する空気調和機とを含む、空気調和システムが知られている。

　たとえば、特許文献１（国際公開第２０１７／１９９３３１号）には、空気調和装置のための更新用ソフトウェアが格納されたサーバと、サーバから更新用ソフトウェアを受信する無線アダプタと、無線アダプタが受信した更新用ソフトウェアでメモリに格納されているソフトウェアを更新する空気調和装置とを含む、空気調和システムが記載されている。

国際公開第２０１７／１９９３３１号

　従来、サーバなどの遠隔装置は、空気調和装置のソフトウェアを更新するための更新用のソフトウェアを一括して空気調和装置へ配信し、空気調和装置は、受信した更新用のソフトウェアを、利用中のソフトウェアとは別に、一旦、メモリに格納していた。

　このように、従来の空気調和装置は、利用中のソフトウェアと別に更新用のソフトウェアをメモリに格納していたため、空気調和装置に必要とされるメモリ容量が多くなってしまうという問題があった。また、従来、更新用のソフトウェアの容量が大きいため、ソフトウェアの更新にかかる時間も長くなるという問題があった。

　本開示は、空気調和装置のソフトウェアを更新する場合において、空気調和装置に必要とされるメモリ容量を削減するとともに、更新時間を短縮することを目的とする。

　本開示の第１の局面に係る空気調和システムは、第１空気調和装置と、空調ソフトウェアを第１空気調和装置に配信するサーバとを備える。第１空気調和装置は、空調ソフトウェアを実行する第１プロセッサと、空調ソフトウェアを格納する第１メモリとを有し、空調ソフトウェアは、第１空気調和装置が提供する複数の機能をそれぞれ実現する複数の応用ソフトウェアと、複数の応用ソフトウェアのジョブを管理する基本ソフトウェアとを含み、サーバは、第１空気調和装置が複数の応用ソフトウェアのうちの１つを更新するために必要な第１更新用データを第１空気調和装置に配信し、第１プロセッサは、第１更新用データに基づいて、基本ソフトウェアを用いて第１メモリ内の対応する応用ソフトウェアを更新する。

　本開示の第２の局面に係る空気調和装置は、空調ソフトウェアを実行する第１プロセッサと、空調ソフトウェアを格納する第１メモリとを備える。空調ソフトウェアは、空気調和装置が提供する複数の機能をそれぞれ実現する複数の応用ソフトウェアと、複数の応用ソフトウェアのジョブを管理する基本ソフトウェアとを含み、第１プロセッサは、空調ソフトウェアを配信するサーバと通信可能であって、第１プロセッサは、複数の応用ソフトウェアのうちの１つを更新するために必要な第１更新用データをサーバから受信した場合、第１更新用データに基づいて、基本ソフトウェアを用いて第１メモリ内の対応する応用ソフトウェアを更新する。

　本開示によれば、空気調和装置のソフトウェアを更新する場合において、空気調和装置に必要とされるメモリ容量を削減するとともに、更新時間を短縮することができる。

実施の形態１における空調システムの全体構成を示す図である。 記憶装置に構築されたデータベースに含まれるデータの一部を示す図である。 空気調和装置のソフトウェア構成およびハードウェア構成の概要を示す図である。 空調ソフトウェアを更新する流れの概要を示すフローチャートである。 クラウド上で空調ソフトウェアが更新された場合に、更新された空調ソフトウェアが格納された空気調和装置を導入している物件を検索する処理の流れを示すフローチャートである。 クラウド上で空調ソフトウェアが更新された場合に、空気調和装置にて対象の空調ソフトウェアの配信を許可するか否かを判定するための処理の流れを示すフローチャートである。 クラウド上で更新された応用プログラムで空気調和装置の応用プログラムを更新するための処理の流れを示すフローチャートである。 クラウド上で更新された基本プログラムで空気調和装置の基本プログラムを更新するための処理の流れを示すフローチャートである。 クラウド上で更新された基本プログラムで空気調和装置の基本プログラムを更新するための処理の流れを示すフローチャートである。 図８および図９のフローチャートにおいて、エントリーポイントを変更する処理の具体例を示すブロック図である。 データベースに登録されている物件データを示す図である。 空気調和装置が優先順位を算出する手順の具体例を示す図である。 サーバが学習装置を用いて推定モデルを作成する手順を説明するためのブロック図である。 サーバが学習済みの推定モデルを用いて応用プログラムの利用に関する優先順位を推定する手順を説明するためのブロック図である。 新規物件に空気調和装置が導入された場合に、新規物件の第１データおよび物件ＩＤをデータベースに登録する手順を示すフローチャートである。 学習済みの推定モデルを作成する手順を説明するためのフローチャートである。 空気調和装置に推奨される応用ソフトウェアの優先順位を判定する手順を説明するためのフローチャートである。 変形例としての空調システムの全体構成を示す図である。 図６に関連する変形例を説明するためのフローチャートである。

　以下、本開示の実施の形態について、図面を参照しながら詳細に説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。

　実施の形態１．
＜空調システム１の全体構成＞
　図１は、実施の形態１における空調システム１の全体構成を示す図である。空調システム１は、遠隔制御システム３と、複数の物件３００Ａ，３００Ｂ…の各々に設置された空気調和装置２００Ａ，２００Ｂ…とにより構成される。空気調和装置２００Ａ，２００Ｂ…は、それぞれで同様のハードウェアの構成を備える。ただし、空気調和装置２００Ａ，２００Ｂ…のハードウェア構成は、完全に同一でなくてもよい。たとえば、空気調和装置２００Ａが備える室内機または室外機の数と、空気調和装置２００Ｂが備える室内機または室外機の数とが異なっていてもよい。図１には、代表例として、２つの物件３００Ａ，３００Ｂを図示している。以下において、物件３００Ａ，３００Ｂ…を「物件３００」と総称することがあり、空気調和装置２００Ａ，２００Ｂ…を「空気調和装置２００」と総称することがある。

　物件３００の数は、２つに限られるものではない。遠隔制御システム３には、さらに数多くの物件３００の各々に設置された空気調和装置２００を接続してもよい。本実施の形態において、物件３００は、空気調和装置２００の設置場所を意味する。

　遠隔制御システム３は、端末装置１０と、端末装置２０Ａ，２０Ｂ…と、クラウド３０と、広域ネットワーク６０とを含む。クラウド３０は、サーバ１００および記憶装置５０により構成される。サーバ１００は、記憶装置５０に構築されるデータベースを利用して遠隔制御システム３の種々の機能を発揮する。

　クラウド３０は、広域ネットワーク６０を介して、端末装置１０、端末装置２０Ａ，２０Ｂ…、および空気調和装置２００Ａ，２００Ｂ…と通信可能に接続される。端末装置１０および端末装置２０Ａ，２０Ｂ…は、それぞれ、ディスプレイ４０を備える。端末装置１０は、たとえば、空気調和装置２００の開発元の担当者によって操作される。端末装置２０Ａ，２０Ｂ…は、空気調和装置２００Ａ，２００Ｂ…のそれぞれのユーザによって操作される。

　たとえば、端末装置２０Ａは、物件３００Ａに設置された空気調和装置２００Ａのユーザによって操作される。端末装置２０Ｂは、物件３００Ｂに設置された空気調和装置２００Ｂのユーザによって操作される。端末装置２０Ａは、たとえば、物件３００Ａに設置される。端末装置２０Ｂは、たとえば、物件３００Ｂに設置される。端末装置２０Ａを物件３００Ａ以外の箇所に設置してもよい。端末装置２０Ｂについても同様である。以下、端末装置２０Ａ，２０Ｂ…を「端末装置２０」と総称することがある。端末装置２０は、たとえば、パーソナルコンピュータにより構成される。端末装置２０をスマートフォンなどの携帯端末により構成してもよい。

　空気調和装置２００は、管理装置２０１と、室内機２０２と、室外機２０３とを含む。管理装置２０１は、制御部として機能するプロセッサ２１１と、各種のプログラムが格納されたメモリ２１２とを備える。管理装置２０１は、空気調和装置２００にインストールされている空調ソフトウェアに基づいて空気調和装置２００を制御する。室内機２０２および室外機２０３は、それぞれ、熱交換器などの空調部品を備える。室内機２０２または室外機２０３の構成として、管理装置２０１が含まれていてもよい。

　空気調和装置２００の開発元は、様々な機種の空気調和装置２００をユーザに提供する。空気調和装置２００に導入される空調ソフトウェアの種類は、空気調和装置２００の機種に応じて異なる。空気調和装置２００に導入される空調ソフトウェアの種類は、ユーザの希望に応じて異なる。たとえば、物件３００Ａに導入されている空気調和装置２００Ａと、物件３００Ｂに導入されている空気調和装置２００Ｂとが同じ機種であっても、それぞれの空気調和装置２００Ａ，２００Ｂにインストールされている空調ソフトウェアが相異なる場合がある。
＜データベース５１に登録されるデータ＞
　図２は、記憶装置５０に構築されたデータベース５１に含まれるデータの一部を示す図である。図２に示されるように、データベース５１には、マスタデータ５２と機種特定用データ５３とが少なくとも登録されている。

　マスタデータ５２は、空気調和装置２００の機種ラインナップ毎に構成されているソフトウェア群と、ソフトウェア群に含まれる各々のソフトウェアのバージョン情報とを含む。機種特定用データは、物件３００Ａ，３００Ｂ…毎の空気調和装置２００の機種と、それぞれの空気調和装置２００Ａ，２００Ｂ…にインストールされているソフトウェアの種類およびバージョン情報とを含む。空気調和装置２００の開発元によって、複数の空調ソフトウェアのうちのいずれかがバージョンアップされた場合、バージョンアップ後の空調ソフトウェアがクラウド３０へアップロードされる。たとえば、開発元の担当者は、端末装置１０を操作することによって、更新された空調ソフトウェアをクラウド３０へアップロードすることができる。これにより、バージョンアップ後の空調ソフトウェアがデータベース５１のマスタデータ５２に新たに登録される。

　サーバ１００は、記憶装置５０に構築されたデータベース５１を参照することにより、空気調和装置２００の機種、インストールされているソフトウェアの種類、およびソフトウェアのバージョンを物件３００毎に特定することができる。サーバ１００は、空調ソフトウェアがバージョンアップされた場合、対応する空調ソフトウェアが導入されている物件３００の空気調和装置２００に対して、空調ソフトウェアを更新するためのデータを送信する。これにより、対象の空気調和装置２００は、空調ソフトウェアを最新の状態に更新することができる。
＜ソフトウェア構成およびハードウェア構成＞
　図３は、空気調和装置２００のソフトウェア構成およびハードウェア構成の概要を示す図である。空気調和装置２００は、ソフトウェア構成として、空調ソフトウェア２１０を備え、ハードウェア構成として、ハードウェアデバイス２４０を備える。空調ソフトウェア２１０は、たとえば、管理装置２０１のメモリ２１２に格納されている。

　図３には、空気調和装置２００のハードウェアデバイス２４０の一部が例示されている。図３に示されるように、ハードウェアデバイス２４０は、冷媒回路を流れる冷媒の温度を検出する温度センサ２４１と、冷媒回路を流れる冷媒の圧力を検出する圧力センサ２４２と、外気温および湿度を検出する温湿度センサ２４３と、高温かつ高圧の冷媒を冷媒回路に吐出する圧縮機２４４と、熱交換器付近において空気を対流させるファン２４５と、冷媒の圧力を調整する膨脹弁などの弁２４６とを含む。

　管理装置２０１は、空調ソフトウェア２１０に従って、空気調和装置２００を制御する。管理装置２０１（図１参照）には、温度センサ２４１、圧力センサ２４２、および温湿度センサ２４３の検出値が入力される。管理装置２０１は、温度センサ２４１および圧力センサ２４２の検出値を考慮して、圧縮機２４４の運転周波数と、弁２４６の開度とを制御する。

　基本ソフトウェア部２２０は、ジョブ制御部２２２と、データ管理部２２３と、通信部２２４と、デバイスドライバ２２５と、ジョブスケジュール２２６とを備える。ジョブスケジュール２２６には、ジョブの実行手順が記述されている。

　デバイスドライバ２２５は、ジョブスケジュール２２６およびハードウェアデバイス２４０を制御する。通信部２２４は、空気調和装置２００が接続されている広域ネットワーク６０とデータ通信を行う。データ管理部２２３は、デバイスドライバ２２５の入出力情報を管理し、応用ソフトウェア部２３０のプログラムとの間でデータを送受信する。データ管理部２２３は、ジョブ制御部２２２の指令を管理するとともに、各種プログラムの状態を管理する。

　ジョブスケジュール２２６には、プログラムの優先順位、プログラムの実行条件、およびプログラムの停止条件が記述されている。ジョブ制御部２２２は、それらのプログラムの優先順位、プログラムの実行条件、およびプログラムの停止条件に基づいて、各種プログラムの実行命令および停止命令を出力する。ここで、各種プログラムには、基本ソフトウェア部２２０の各種プログラムと、応用ソフトウェア部２３０の各種プログラムとが含まれる。

　ジョブ制御部２２２は、ジョブスケジュールの条件を判定するため、通信部２２４から受け取る指令、およびデータ管理部２２３が保有する各種プログラムの状態を監視する。

　応用ソフトウェア部２３０の応用プログラム２３１は、空気調和装置２００の様々な機能を実現する。複数の応用プログラム２３１の各々は、応用プログラム２３１間での競合を意識せず、独立で動作する。

　応用プログラム２３１は、設計者が空気調和装置２００の機能および目的をプログラム上で個別に宣言し、入力、演算アルゴリズム、および出力をプログラム上で定義することにより設計された、自由度の高いプログラムである。

　応用ソフトウェア部２３０は、空気調和装置２００の機能を実現する制御アルゴリズムを記述したプログラム群で構成される。そのプログラム群は、たとえば、運転制御プログラム２３１Ａ、機器保護制御プログラム２３１Ｂ、霜取制御プログラム２３１Ｃ…などの単独のプログラム単位で構成される。それぞれのプログラムが実行されることにより、起動、実行、および停止というプログラム制御状態が形成される。

　たとえば、運転制御プログラム２３１Ａは、通信部２２４のデータ、温度センサ２４１の検出値、および圧力センサ２４２の検出値を入力し、演算を行い、圧縮機２４４、ファン２４５、および弁２４６の制御値を出力する。機器保護制御プログラム２３１Ｂ、および霜取制御プログラム２３１Ｃも、同様に、温度センサ２４１の検出値、および圧力センサ２４２の検出値を入力し、演算を行い、圧縮機２４４、ファン２４５、および弁２４６の制御値を出力する。

　以下、運転制御プログラム２３１Ａ、機器保護制御プログラム２３１Ｂ、霜取制御プログラム２３１Ｃ…を「応用プログラム（応用ソフトウェア）２３１」と総称することがある。また、応用プログラム２３１との対比において、基本ソフトウェア部２２０のジョブ制御部２２２、データ管理部２２３、通信部２２４、デバイスドライバ２２５、およびジョブスケジュール２２６を構成するプログラムを、「基本プログラム（基本ソフトウェア）２２１」と総称することがある。

　各種の応用プログラム２３１は、ジョブ制御部２２２の命令に従って並列処理される場合がある。各種の応用プログラム２３１は、同一の時間において同じデータを共有する場合がある。共有が必要なデータは、データ管理部２２３によって管理される。

　運転制御プログラム２３１Ａは、温度センサ２４１の検出値、圧力センサ２４２の検出値、および通信部２２４が受け取った室内の設定温度に基づいて、圧縮機２４４、ファン２４５、および弁２４６へ出力する値を演算する。このようにして、運転制御プログラム２３１Ａが実行されることにより、通常運転モードによる運転（冷房運転または暖房運転）が実現する。

　運転制御プログラム２３１Ａが実行されているとき、温度センサ２４１または圧力センサ２４２の検出値が閾値を超える場合がある。この場合、通常運転モードから異常モードに運転モードを切り替えるために、応用ソフトウェア部２３０は、機器保護制御プログラム２３１Ｂを実行する必要が生じる。

　温度センサ２４１および圧力センサ２４２の情報は、データ管理部２２３を介して、運転制御プログラム２３１Ａと機器保護制御プログラム２３１Ｂとで共有される場合がある。圧縮機２４４、ファン２４５、および弁２４６への出力値も、データ管理部２２３を介して、応用ソフトウェア部２３０内の複数の応用プログラム２３１で共有される場合がある。それらの出力値は、ジョブスケジュール２２６に記述される優先順位に従って、デバイスドライバ２２５に通知される。

　基本ソフトウェア部２２０は、応用ソフトウェア部２３０内の各種の応用プログラム２３１間に跨る基本プログラム２２１で構成される。応用ソフトウェア部２３０に属する応用プログラム２３１は、各々、独立して演算結果を出力する。このため、各々の応用プログラム２３１が、圧縮機２４４、ファン２４５、および弁２４６などのアクチュエータ類に同時に演算結果を出力すると、競合が発生する。

　そこで、ジョブ制御部２２２は、予め定めた優先順位に従って、優先的に演算結果を出力させる応用プログラム２３１を決定する。優先順位は、ジョブスケジュール２２６に記述されている。データ管理部２２３は、複数の応用プログラム２３１が共有するデータを管理する。デバイスドライバ２２５は、複数の応用プログラム２３１が共通で取り扱うハードウェアデバイス２４０に対して、競合する指令が出力されることを阻止する。
＜空調ソフトウェア２１０を更新する処理の概要＞
　図４は、空調ソフトウェア２１０を更新する流れの概要を示すフローチャートである。本フローチャートは、空調システム１により実行される。空調ソフトウェア２１０は、図４に示されるとおり、更新の発生、更新の可否の判定、および更新処理の３つのステップにより更新される。更新対象は、基本ソフトウェア部２２０を構成する基本プログラム２２１または応用ソフトウェア部２３０内の応用プログラム２３１である。更新に必要なデータは、クラウド３０のサーバ１００から空気調和装置２００に対して配信される。

　たとえば、複数の応用プログラム２３１のうちの１つがクラウド３０で更新された場合、更新された応用プログラム２３１が空気調和装置２００に配信される。なお、応用プログラム２３１それ自体ではなく、更新に必要な差分データを空気調和装置２００に配信してもよい。したがって、サーバ１００から空気調和装置２００に配信される更新用データは、プログラム（基本プログラムまたは応用プログラム）自体であってもよく、対象のプログラムを更新するために必要な内容を含むデータ（たとえば、差分データ）であってもよい。

　基本ソフトウェア部２２０は、更新対象の応用プログラム２３１をサーバ１００から受信した場合、応用ソフトウェア部２３０の全てを更新するのではなく、更新に必要な応用プログラム２３１のみを更新する。したがって、更新の最小単位は、１つの応用プログラム２３１である。空気調和装置２００は、サーバ１００から基本プログラム２２１を受信した場合、基本ソフトウェア部２２０の基本プログラム２２１を更新する。

　図４に示されるとおり、はじめに、空気調和装置２００の空調ソフトウェア２１０の更新が必要か否かが判定される（ステップＳ１００）。ステップＳ１００は、サーバ１００によって判定される。サーバ１００は、空調ソフトウェア２１０を構成するいずれかの更新プログラムが記憶装置５０に登録された場合、空調ソフトウェア２１０の更新が必要であると判定する。より具体的には、サーバ１００は、データベース５１のマスタデータ５２に空調ソフトウェア２１０を構成するいずれかの更新プログラムが登録された場合、空調ソフトウェア２１０の更新が必要であると判定する。

　ステップＳ１００において、更新不要と判定された場合、本フローチャートに基づく処理は終了する。ステップＳ１００において、更新が必要と判定された場合、空気調和装置２００において空調ソフトウェア２１０を更新可能であるか否かが判定される（ステップＳ２００）。

　たとえば、空気調和装置２００のメモリ２１２の残容量が空調ソフトウェア２１０の更新に必要な容量に満たない場合、ステップＳ２００において、空調ソフトウェア２１０の更新は不可能と判定される。この判定は、たとえば、空気調和装置２００において、または、サーバ１００において実行される。更新に必要なメモリ容量をサーバ１００が空気調和装置２００に送信する場合、空気調和装置２００はステップＳ２００を判定可能である。メモリ２１２の残容量を空気調和装置２００がサーバ１００に送信する場合、サーバ１００はステップＳ２００を判定可能である。

　ステップＳ２００において、更新不可能と判定された場合、本フローチャートに基づく処理は終了する。なお、空気調和装置２００のメモリ２１２の残容量が空調ソフトウェア２１０の更新に必要な容量に満たない場合、サーバ１００は、その空気調和装置２００に対応する端末装置２０へ容量不足を通知してもよい。端末装置２０をユーザが操作することによって空気調和装置２００のメモリ２１２のデータを整理できるように構成してもよい。

　空気調和装置２００のメモリ２１２の残容量が空調ソフトウェア２１０の更新に必要な容量に満たない場合、空気調和装置２００は、メモリ２１２のデータを自動的に整理した上で、更新プログラムをサーバ１００から受信するように動作してもよい。

　たとえば、メモリ２１２内の優先順位（利用頻度）の低い応用プログラムを削除することによって、更新プログラムをファイルサイズ的にメモリ２１２に格納できる場合、空気調和装置２００は、その応用プログラムを削除してから更新プログラムをサーバ１００から受信してもよい。この場合、空気調和装置２００は、更新プログラムを用いた更新処理を実行するスケジュールをジョブスケジュール２２６に書き込んだ後、そのスケジュールに従って更新処理を実行することができる。

　ステップＳ２００において、更新可能と判定された場合、空気調和装置２００の空調ソフトウェア２１０が更新される（ステップＳ４００）。ステップＳ４００は、サーバ１００および空気調和装置２００により実行される。すなわち、サーバ１００は、更新対象の空調ソフトウェア２１０を空気調和装置２００へ配信する。空気調和装置２００は、受信した空調ソフトウェア２１０を用いて、対象の空調ソフトウェア２１０を更新する。

　図４を用いて説明した処理について、図５～図１０を用いてより詳細に説明する。図５および図６は応用ソフトウェア部２３０の更新に関し、図７は基本ソフトウェア部２２０の更新に関する。
＜空調ソフトウェア２１０の更新対象を特定する処理＞
　図５は、クラウド３０上で空調ソフトウェア２１０が更新された場合に、更新された空調ソフトウェア２１０が格納された空気調和装置２００を導入している物件３００を検索する処理の流れを示すフローチャートである。本フローチャートに基づく処理は、空調システム１により実行される。

　図５を参照して、サーバ１００は、クラウド３０上で、空調ソフトウェア２１０が更新されたか否かを判定する（ステップＳ１０２）。クラウド３０上では、基本プログラム２２１と応用プログラム２３１とが個別に更新され得る。特に、応用プログラム２３１に関しては、運転制御プログラム２３１Ａ、機器保護制御プログラム２３１Ｂ、霜取制御プログラム２３１Ｃ…などの複数の種類が存在し、それぞれがクラウド３０上で個別に更新される。ステップＳ１０２において、それらのプログラムのいずれかがクラウド３０上で更新されたか否かが判定される。

　ステップＳ１０２において、空調ソフトウェア２１０が更新されていないと判定された場合、本フローチャートに基づく処理は終了する。ステップＳ１０２において、空調ソフトウェア２１０が更新されたと判定された場合、サーバ１００は、対象の物件３００を検索する（ステップＳ１０４）。ここで検索される物件３００は、更新された空調ソフトウェア２１０に対応するプログラムを含む空気調和装置２００を導入している物件３００である。

　本実施の形態において、基本プログラム２２１には、空気調和装置２００の機種別に異なるＩＤが割り当てられている。応用プログラム２３１には、その種類別に異なるＩＤが割り当てられている。このため、たとえば、運転制御プログラム２３１Ａ、機器保護制御プログラム２３１Ｂ、霜取制御プログラム２３１Ｃ…には、それぞれ、異なるＩＤが割り当てられている。

　データベース５１の機種特定用データ５３には、空気調和装置２００の基本プログラム２２１のＩＤおよび応用プログラム２３１のＩＤが各物件３００Ａ，３００Ｂ毎に登録されている。サーバ１００は、データベース５１を利用して、更新された空調ソフトウェア２１０のＩＤと一致するＩＤのプログラムがインストールされている空気調和装置２００を検索する。さらに、サーバ１００は、データベース５１を利用して、検索の結果、見つかった空気調和装置２００を導入している物件３００を検索する。

　次に、サーバ１００は、検索によって見つかった物件３００に導入されている空気調和装置２００のうち、更新プログラムを書込む空き領域が存在する空気調和装置２００を選択する（ステップＳ１０６）。たとえば、サーバ１００は、検索によって見つかった物件３００に導入されている空気調和装置２００から、空き領域のサイズを受信する。これにより、サーバ１００は、空気調和装置２００に更新プログラムを書込む空き領域が存在するか否かを判定することができる。

　次に、サーバ１００は、選択された空気調和装置２００が導入されている物件３００に対応する端末装置２０へ更新の発生を通知する（ステップＳ１０８）。その結果、更新対象の空気調和装置２００が導入されている物件３００の数に応じて、１または複数の端末装置２０に更新の発生が通知される。

　次に、サーバ１００は、更新対象の空調ソフトウェア２１０が応用プログラム２３１であるか否かを判定する（ステップＳ１１０）。更新対象の空調ソフトウェア２１０が応用プログラム２３１でない場合、処理がステップＳ１１４に進められる。更新対象の空調ソフトウェア２１０が応用プログラム２３１である場合、サーバ１００は、ステップＳ１０６において選択されなかった他の物件３００に対応する端末装置２０へ、応用プログラム２３１を新規にインストール可能であることを通知する（ステップＳ１１２）。

　次に、サーバ１００からステップＳ１０８またはステップＳ１１２の通知を受信した１または複数の端末装置２０は、空調ソフトウェア２１０の更新が発生すること、または、新規で応用プログラム２３１をインストール可能であることを、ディスプレイ４０に表示する（ステップＳ１１４）。ディスプレイ４０の表示により空調ソフトウェア２１０の更新が発生することを理解したユーザは、空調ソフトウェア２１０の更新を許可するか否かを判定する。あるいは、ディスプレイ４０の表示により新規で応用プログラム２３１をインストール可能であることを理解したユーザは、新規の応用プログラム２３１のインストールを許可するか否かを判定する。

　端末装置２０は、空調ソフトウェア２１０（基本プログラム２２１または応用プログラム２３１）の更新または応用プログラム２３１の新規インストールを許可することを示す操作を受け付ける（ステップＳ１１６）。ステップＳ１１６において、ユーザの操作が検出された場合、端末装置２０は、空調ソフトウェア２１０を更新する対象の空気調和装置２００、または応用プログラム２３１を新規インストールする対象の空気調和装置２００を、クラウド３０のサーバ１００へ通知する（ステップＳ１２０）。これにより、本フローチャートに基づく処理は終了する。

　ステップＳ１２０により、サーバ１００は、複数の空気調和装置２００のうち、いずれに対して、更新プログラムを配信すべきかを特定することができる。なお、ステップＳ１１６において、ユーザの操作が検出されない場合（配信を許可しない操作が検出された場合）、サーバ１００へは、プログラムを更新または新規インストールする対象の空気調和装置２００が通知されない。その結果、該当の空気調和装置２００へ更新プログラムは配信されない。

　なお、本フローチャートにおいては、端末装置２０におけるユーザの指示を受けて、サーバ１００が更新プログラムを配信する例を示した。しかし、サーバ１００は、ステップＳ１０６において、対象の空気調和装置２００を選択した後、ユーザの指示を待つことなく、対象の空気調和装置２００へ更新プログラムを自動的に配信してもよい。
＜更新プログラムの配信を許可するか否かを特定する処理＞
　図６は、クラウド３０上で空調ソフトウェア２１０が更新された場合に、空気調和装置２００にて対象の空調ソフトウェア２１０の配信を許可するか否かを判定するための処理の流れを示すフローチャートである。

　はじめに、サーバ１００は、対象の空気調和装置２００に、プログラム情報および配信許可伺いを送信する（ステップＳ２０２）。対象の空気調和装置２００は、図５のステップＳ１２０によって、サーバ１００が通知を受けた空気調和装置２００である。したがって、ステップＳ２０２の処理は、１または複数の空気調和装置２００に対して実行される。プログラム情報は、配信する空調ソフトウェア２１０（基本プログラム２２１または複数の応用プログラム２３１のいずれか）のＩＤ、プログラム容量、およびバージョン情報などである。

　プログラム情報および配信許可伺いを受信した空気調和装置２００は、配信対象のプログラムをインストールするための十分な空き領域が存在するかを判定する（ステップＳ２０４）。より、具体的には、空気調和装置２００の管理装置２０１は、配信対象のプログラムをインストールするための十分な空き領域がメモリ２１２に存在するかを判定する。

　空気調和装置２００は、ステップＳ２０４にてＹＥＳと判定した場合、ジョブスケジュール２２６に更新処理を追加する（ステップＳ２０６）。更新処理は、空気調和装置２００の管理装置２０１によってジョブスケジュール２２６に追加される。基本ソフトウェア部２２０の観点で説明すると、更新処理は、ジョブ制御部２２２によってジョブスケジュール２２６に追加される。

　更新処理は、空調ソフトウェア２１０に含まれる既存の基本プログラム２２１および複数の応用プログラム２３１のいずれかを更新する処理である。あるいは、更新処理は、新規の応用プログラム２３１をインストールする処理である。

　次に、空気調和装置２００は、クラウド３０のサーバ１００に対して配信許可を返信する（ステップＳ２０８）。配信許可を受信したサーバ１００は、後に説明する図７のステップＳ４０２において、ＹＥＳと判定する。

　空気調和装置２００は、ステップＳ２０４にてＮＯと判定した場合、クラウド３０のサーバ１００に対して配信不可を返信し（ステップＳ２１０）、本フローチャートに基づく処理を終える。配信不可を受信したサーバ１００は、後に説明する図７のステップＳ４０２において、ＮＯと判定する。

　なお、図６に示されるフローチャートには、空き領域を判定するステップＳ２０４が存在する。このため、図５において、更新プログラムを書き込む空き領域の存在を判定するステップＳ１０６は、省略してもよい。
＜応用プログラム２３１を更新または新規インストールする処理＞
　図７は、クラウド３０上で更新された応用プログラム２３１で空気調和装置２００の応用プログラム２３１を更新するための処理の流れを示すフローチャートである。

　ここでは、図７に示されるフローチャートを用いて、空気調和装置２００の既存の応用プログラム２３１を更新するケースと、空気調和装置２００に新規の応用プログラム２３１をインストールするケースとを説明する。なお、図７に示されるフローチャートの説明において、「プログラム」は、複数の応用プログラム２３１のうちのいずれかを意味するものとする。

　はじめに、サーバ１００は、対象の空気調和装置２００への更新プログラム（応用プログラム２３１）の更新が許可されたか否かを判定する（ステップＳ４０２）。対象の空気調和装置２００のプログラムの更新が許可されなかった場合、本フローチャートに基づく処理は終了する。対象の空気調和装置２００のプログラムの更新が許可された場合、サーバ１００は、対象の空気調和装置２００へ更新プログラムを配信する（ステップＳ４０４）。

　対象の空気調和装置２００の通信部２２４は、配信された更新プログラムを受信し、ジョブ制御部２２２は、その受信を検知する（ステップＳ４０６）。ジョブ制御部２２２は、受信されたデータが更新プログラムであることを認識する。ジョブ制御部２２２は、ジョブスケジュール２２６の更新処理を実行する（ステップＳ４０８）。更新処理によって、データ管理部２２３が起動する。データ管理部２２３は、受信した更新プログラムをメモリ２１２の空き領域に格納する処理を開始する（ステップＳ４１０）。

　次に、データ管理部２２３は、更新プログラムを空き領域に格納する処理は終了したか否かを判定する（ステップＳ４１２）。データ管理部２２３は、更新プログラムを空き領域に格納する処理が終了するまで、ステップＳ４１２の処理を繰り返す。

　更新プログラムを空き領域に格納する処理が終了した場合、ジョブ制御部２２２は、更新プログラムのＩＤをジョブスケジュール２２６から検索し（ステップＳ４１４）、更新プログラムのＩＤと同一のＩＤのプログラムがジョブスケジュール２２６に存在するか否かを判定する（ステップＳ４１６）。

　更新プログラムのＩＤと同一のＩＤのプログラムがジョブスケジュール２２６に存在する場合、ジョブ制御部２２２は、次回、そのＩＤのプログラムを起動する際、更新前のプログラムのアドレスではなく、更新プログラムのアドレスが参照されるように、ジョブスケジュール２２６を設定する（ステップＳ４１８）。換言すると、ジョブ制御部２２２は、次回、そのＩＤのプログラムが起動するとき、更新後のプログラムが起動するようにジョブスケジュール２２６のエントリーポイントを変更する。これにより、次回、そのＩＤのプログラム（応用プログラム２３１）が呼び出される場合には、更新後のプログラムが起動する。

　なお、データ管理部２２３は、更新後のプログラムが起動した時点で、更新前のプログラムをメモリ２１２から削除してもよい。

　更新プログラムのＩＤと同一のＩＤのプログラムがジョブスケジュール２２６に存在しない場合、ジョブ制御部２２２は、新規プログラムとして、そのＩＤをジョブスケジュール２２６に登録し（ステップＳ４２０）、本フローチャートに基づく処理を終える。これにより、空気調和装置２００には新規の応用プログラム２３１がインストールされる。
＜基本プログラム２２１の更新処理＞
　図８および図９は、クラウド３０上で更新された基本プログラム２２１で空気調和装置２００の基本プログラム２２１を更新するための処理の流れを示すフローチャートである。

　図１０は、図８および図９のフローチャートにおいて、エントリーポイントを変更する処理の具体例を示すブロック図である。図１０には、ジョブスケジュール２２６とプログラム領域２１３との関係が示されている。プログラム領域２１３は、メモリ２１２に設けられる。プログラム領域２１３には、更新プログラムを格納可能な空き領域２１４が存在する。

　先に説明した図４～図６に示されるフローチャートの処理は、基本プログラム２２１の更新に関しても同様に適用される。すなわち、図６のステップＳ２０８にて配信が許可されたプログラムが応用プログラム２３１の場合には、図７のフローチャートに基づく処理が実行され、図６のステップＳ２０８にて配信が許可されたプログラムが基本プログラム２２１の場合には、以下に説明する図８および図９のフローチャートに基づく処理が実行される。

　なお、図８および図９に示されるフローチャートの説明において、「プログラム」は、基本プログラム２２１を意味するものとする。

　はじめに、サーバ１００は、対象の空気調和装置２００の更新プログラム（基本プログラム２２１）の配信が許可されたか否かを判定する（ステップＳ６０２）。対象の空気調和装置２００のプログラムの更新が許可されなかった場合、本フローチャートに基づく処理は終了する。対象の空気調和装置２００のプログラムの更新が許可された場合、サーバ１００は、対象の空気調和装置２００へ更新プログラムを配信する（ステップＳ６０４）。

　対象の空気調和装置２００の通信部２２４は、配信された更新プログラムを受信し、ジョブ制御部２２２は、その受信を検知する（ステップＳ６０６）。ジョブ制御部２２２は、受信されたデータが更新プログラムであることを認識する。ジョブ制御部２２２は、ジョブスケジュール２２６の更新処理を実行する（ステップＳ６０８）。更新処理によって、データ管理部２２３が起動する。データ管理部２２３は、受信した更新プログラムをプログラムモジュール単位でプログラム領域２１３の空き領域２１４に格納する処理を開始する（ステップＳ６１０）。複数のプログラムモジュールの各々は、基本ソフトウェア部２２０のジョブ制御部２２２、データ管理部２２３、通信部２２４、およびデバイスドライバ２２５などを構成する。

　図１０には、プログラム領域２１３の空き領域２１４に更新プログラムモジュール（１）～（３）が格納されている状態が示されている。プログラム領域２１３には、現在、利用されている、更新前の旧プログラムモジュール（１）～（３）も格納されている。ステップＳ６１０が継続的に実行されることによって、空き領域２１４に順次、更新プログラムモジュール（１）～（３）が格納されていく。

　次に、ジョブ制御部２２２は、空き領域２１４への格納が完了した更新プログラムモジュールが存在するか否かを判定する（ステップＳ６１２）。ステップＳ６１０が継続的に実行されているものの、空き領域２１４への格納が完了した更新プログラムモジュールが存在しない場合、ステップＳ６１８に処理が進む。空き領域２１４への格納が完了した更新プログラムモジュールが存在する場合、ジョブ制御部２２２は、更新プログラムモジュールと同じＩＤのプログラムモジュールをジョブスケジュール２２６から検索する（ステップＳ６１４）。

　次に、ジョブ制御部２２２は、ジョブスケジュール２２６の当該ＩＤに対応するプログラムモジュールのエントリーポイントを旧モジュールから新モジュールに変更する（ステップＳ６１６）。たとえば、図１０には、ＩＤ＝１に対応するプログラムモジュールのエントリーポイントが、旧プログラムモジュールのエントリーポイントＡから新モジュール（更新プログラムモジュール）のエントリーポイントＸに変更される様子が示されている。

　次に、ジョブ制御部２２２は、ジョブ制御部２２２に対応するプログラムモジュールを除いて、更新前のプログラムモジュールは実行中であるか否かを判定する（ステップＳ６１８）。ステップＳ６１８は、ステップＳ６１６において、エントリーポイントを変更済みのプログラムモジュールを対象にして判定される。エントリーポイントを更新前のプログラムモジュールから更新後のプログラムモジュールに変更済みであれば、更新前のプログラムモジュールを削除することができる。ただし、更新前のプログラムモジュールが動作している場合、その動作が終わった後に、更新前のプログラムモジュールを削除する必要がある。

　ステップＳ６１８において、ＮＯと判定された場合、データ管理部２２３は、更新前のプログラムモジュールをプログラム領域２１３から削除する（ステップＳ６２０）。しかし、ステップＳ６１８において、ＹＥＳと判定された場合、ステップＳ６２０の処理が実行されることなく、処理がステップＳ６２２に進む。ステップＳ６２２において、ジョブ制御部２２２は、全ての更新プログラムモジュールを空き領域２１４に格納する処理が完了したか否かを判定する。全ての更新プログラムモジュールを空き領域２１４に格納する処理が完了していない場合、ステップＳ６１０の処理に戻る。

　全ての更新プログラムモジュールを空き領域２１４に格納する処理が完了した場合、データ管理部２２３は、ジョブ制御部２２２に対応するプログラムモジュールを除いて、更新前のプログラムモジュールを全てプログラム領域２１３から削除したか否かを判定する（ステップＳ６２４）。ジョブ制御部２２２に対応するプログラムモジュールを除いて、更新前のプログラムモジュールを全てプログラム領域２１３から削除していない場合、ステップＳ６１８の処理に戻る。なお、ステップＳ６２４の判定において、ジョブ制御部２２２に対応するプログラムモジュールを除外しているのは、本フローチャートの主たる制御を実行するのはジョブ制御部２２２だからである。

　このように、ステップＳ６２２からステップＳ６１０に戻る処理と、ステップＳ６２４からステップＳ６１８に戻る処理とが繰り返し実行されることにより、やがて、全ての更新プログラムモジュールが空き領域２１４に格納され、エントリーポイントを変更する処理が全てのプログラムモジュールに対して実行される。その結果、ジョブ制御部２２２に対応するプログラムモジュールを除いて、更新前のプログラムモジュールの全てが削除された状態となる。このとき、ステップＳ６２４においてＹＥＳと判定される。

　なお、空気調和装置２００は、更新プログラムを順次、空き領域２１４に格納する処理と、空き領域に更新プログラムが格納される毎に更新プログラムの実行に関するエントリーポイントを変更する処理と、エントリーポイントを変更済みの旧プログラムモジュールを順次、削除する処理とを、並列的に実行するようにしてもよい。

　ステップＳ６２４においてＹＥＳと判定された場合、ジョブ制御部２２２に対応する更新プログラムモジュール（旧プログラムモジュール）が初期化され、更新前のプログラムモジュール（旧プログラムモジュール）のジョブスケジュールが継承される（ステップＳ６２６）。

　次に、ジョブ制御部２２２が再起動することにより、ジョブ制御部２２２に対応する更新プログラムモジュールが再起動する（ステップＳ６２８）。次に、更新前のジョブ制御部２２２に対応するプログラムモジュールが停止することを待って（ステップＳ６３０）、データ管理部２２３は、更新前のプログラムモジュールをプログラム領域２１３から削除する（ステップＳ６３２）。これにより、ジョブ制御部２２２に対応するプログラムモジュールが完全に更新される。以上により、基本プログラム２２１を更新するための全ての処理が終了する。

　以上のとおり、ジョブ制御部２２２は、複数のプログラムモジュールの各々を、順次、前記メモリ２１２に格納する（ステップＳ６１０）。ジョブ制御部２２２は、第１プログラムモジュール（たとえば、デバイスドライバ２２５に対応するプログラムモジュール）のメモリ２１２への格納が完了したときに第２プログラムモジュール（たとえば、通信部２２４に対応するプログラムモジュール）のメモリへ２１２への格納が完了していない場合、第１プログラムモジュールを用いて、メモリ２１２の対応する基本ソフトウェアの第１プログラムモジュール部分を更新する（ステップＳ６１２～ステップＳ６１６）。

　ジョブ制御部２２２は、基本プログラム２２１を更新するために用いられるジョブモジュールである。空気調和装置２００は、複数のプログラムモジュール毎にメモリ２１２内の対応する基本ソフトウェアを更新する場合、ジョブ制御部２２２のモジュール部分を最後に更新する（ステップＳ６２４）。

　以上、説明したように、本実施の形態によれば、空調ソフトウェア２１０を構成する各種のプログラムのうち、更新に必要なプログラムの単位で更新処理が実行される。このため空調ソフトウェア２１０を構成する全てのプログラムを一括して更新する場合に比べて、プログラムの更新時間を短くすることができる。また、更新に必要なプログラムのデータのみをサーバ１００から配信すればよいため、空気調和装置に必要とされるメモリ容量を削減することができるとともにサーバ１００と空気調和装置２００との間の通信量を少なくすることができる。

　従来、プログラムの更新に際して、空気調和装置２００の電源を遮断する必要が生じていた。しかし、本実施の形態では、各種の応用プログラム２３１単位の更新処理を基本ソフトウェア部２２０が担う。このため、応用プログラム２３１の更新中に、空気調和装置２００の電源を遮断することなく、空気調和装置２００の運転を継続することができる。

　このように、本実施の形態では、空気調和装置２００が提供する複数の機能のそれぞれを実現する複数の機能単位で、応用プログラム２３１を分割している。これにより、ユーザは、必要な応用プログラム２３１を選択的に空気調和装置２００に導入することができる。その結果、空気調和装置２００に要求されるプログラム容量を減らすことができる。本実施の形態では、基本ソフトウェア部２２０が応用プログラム２３１を更新する処理を担うため、プログラムの更新の際に、電源を遮断する必要がない。そのため、揮発性メモリなどに格納している状態変数などがプログラムの更新によって消去されてしまうことがない。

　なお、ここでは、管理装置２０１のメモリ２１２に空調ソフトウェア２１０が格納される例を説明した。しかし、室内機２０２または室外機２０３に対して管理装置２０１と同等の制御装置を設け、その制御装置のメモリに空調ソフトウェア２１０を格納してもよい。室内機２０２または室外機２０３が管理装置２０１を含むように構成してもよい。

　また、本実施の形態では、基本ソフトウェア部２２０を構成する基本プログラム２２１を更新する際、基本プログラム２２１のプログラムモジュール単位で更新処理が実行される。基本ソフトウェア部２２０は、ジョブ制御部２２２に対応するプログラムモジュールの他、通信部２２４に対応するプログラムモジュール、およびデバイスドライバ２２５に対応するプログラムモジュールなどによって構成される。

　ジョブ制御部２２２は、ジョブ制御部２２２を除くこれらのプログラムモジュールの更新処理を司る。ジョブ制御部２２２は、これらのプログラムモジュールをモジュール単位で更新する。空気調和装置２００は、ジョブ制御部２２２がこれらのプログラムモジュールを更新する処理を終えた後、ジョブ制御部２２２に対応する更新プログラムモジュールを初期化および再起動し（ステップＳ６２６、ステップＳ６２８）、最終的に基本プログラムの更新を終了させる。このため、本実施の形態によれば、基本プログラムを構成するプログラムモジュールのうち、ジョブ制御部２２２に対応するプログラムモジュールを再起動させることのみで、基本プログラムを更新することができる。
＜データベース５１に登録されている物件データ＞
　図１１は、データベース５１に登録されている物件データ５４を示す図である。物件データ５４には、個々の物件３００Ａ，３００Ｂ…の環境を特定するためのデータが含まれている。以下に説明するように、サーバ１００を含む遠隔制御システム３は、物件データ５４を利用した機械学習を経て、物件３００の環境特性に応じた空調ソフトウェア２１０を提供することができる。

　図１１に示されるように、物件データ５４は、物件３００Ａ，物件３００Ｂ，…毎にデータベース５１に登録されている。物件データ５４は、第１データと第２データとで構成される。

　第１データは、物件３００のほぼ恒久的で持続性のある特性を示すデータであり、たとえば、位置情報および気候情報を含む。位置情報は、物件３００の位置を示す緯度および経度により構成される。気候情報は、物件３００が比較的温暖な地域に立地しているか、寒冷地に立地しているかなどといった情報により構成される。

　たとえば、第１データは、新たな物件３００に空気調和装置２００を設置する際、空気調和装置２００の開発元の担当者によってデータベース５１に登録される。たとえば、開発元の担当者は、端末装置１０を用いて第１データをデータベース５１に登録してもよい。

　第２データは、季節および時間帯によって変動し得るデータであり、たとえば、応用プログラム２３１の優先順位および物件３００付近の気象情報などを含む。優先順位は、空気調和装置２００が有する各種の応用プログラム２３１の利用状況に基づいて算出される情報である。気象情報は、物件３００の外気温度および湿度を含む情報である。物件３００の外気温度および湿度は、空気調和装置２００の温湿度センサ２４３（図３参照）によって計測される。優先順位および気象情報は、物件３００Ａ，物件３００Ｂ，…の各々に設置された空気調和装置２００Ａ，空気調和装置２００Ｂ，…において、一定期間毎に算出される。

　空気調和装置２００Ａ，空気調和装置２００Ｂ，…は、算出された優先順位および気象情報、並びに算出日時を示す日時情報をサーバ１００へ送信する。空気調和装置２００Ａ，空気調和装置２００Ｂ，…は、それらの情報とともに物件ＩＤをサーバ１００へ送信する。サーバ１００は、受信した日時情報、優先順位および気象情報を、空気調和装置２００の物件ＩＤ別に第２データとしてデータベース５１に登録する。

　サーバ１００は、優先順位の情報を参照することよって、空気調和装置２００が有する各種の応用プログラム２３１のうち、いずれが最も利用頻度が高く、いずれか最も利用頻度が低いかを把握することができる。サーバ１００は、優先順位の情報を参照することによって、極めて利用頻度の低い応用プログラム２３１、および利用されていない応用プログラム２３１を特定することができる。

　ここで、図１２を参照して、優先順位に関して詳細に説明する。図１２は、空気調和装置２００が優先順位を算出する手順の具体例を示す図である。ここでは、空気調和装置２００が応用プログラム２３１として第１プログラム～第４プログラムを有するものとする。空気調和装置２００は、第１プログラム～第４プログラムのそれぞれが利用される毎にプログラムの利用回数を計数する。図１２に示される例では、第４プログラムの利用回数が最も多く、第１プログラムの利用回数は０である。

　空気調和装置２００は、規定期間が経過した段階で、利用回数と規定期間とに基づいて、利用頻度を算出する。たとえば、利用頻度は、「利用回数／規定期間」によって算出することができる。その結果、各々のプログラムの利用頻度が算出される。また、図１２に示されるように、第１～第４プログラムの利用に関する優先順位が算出される。

　優先順位は、空調ソフトウェア２１０によって算出される。より具体的には、空調ソフトウェア２１０は、応用ソフトウェア部２３０の各種の応用プログラム２３１の利用回数を定期的に計測する。空調ソフトウェア２１０は、その利用回数を単位時間で除することによって利用頻度を求める。空調ソフトウェア２１０は、利用頻度を順位付けすることで、空調ソフトウェア２１０が利用する各種の応用プログラム２３１の優先順位を決定する。この優先順位は、「機能優先順位」とも称される。

　機能優先順位は、１日の時間帯に応じて変動するため、時間帯に応じた利用分布を求めることもできる。この場合、時間帯に応じ、自動的に空気調和装置２００の起動、運転切換といった基本機能をスケジューリングすることも可能である。機能優先順位は、空調ソフトウェア２１０が利用する環境情報である外気温度、湿度等といった情報とともに定期的に遠隔制御システム３へ送信される。
＜学習フェーズ＞
　図１３は、サーバ１００が学習装置１１０を用いて推定モデル１１４を作成する手順を説明するためのブロック図である。図１３に示されるように、サーバ１００は、学習装置１１０と、推定モデル１１４とを備える。学習装置１１０および推定モデル１１４は、サーバ１００のプロセッサ１０１およびメモリ１０２によって実現される。特に、推定モデル１１４は、サーバ１００のメモリ１０２によって実現される。記憶装置５０の記憶領域の一部を用いて、学習装置１１０および推定モデル１１４を実現してもよい。

　学習装置１１０は、入力部１１１と、判定部１１２と、学習部１１３とを備える。推定モデル１１４は、ニューラルネットワーク１１５と、パラメータ１１６とを含む。推定モデル１１４は、ニューラルネットワーク１１５を用いることで、ディープラーニングを行う。パラメータ１１６は、ニューラルネットワーク１１５による計算に用いられる重み付け係数などを含む。

　ここで、推定モデル１１４を学習させる学習フェーズについて説明する。推定モデル１１４は、学習装置１１０によって学習される。推定モデル１１４は、学習装置１１０によって、空気調和装置２００の応用プログラム２３１の利用に関する優先順位を推定するように学習されている。

　推定モデル１１４を学習させるため、たとえば、教師あり学習のアルゴリズムが用いられる。学習装置１１０は、多数の学習用データ５を用いた教師あり学習によって、推定モデル１１４を学習させる。学習用データ５は、データベース５１に登録された第１データおよび第２データにより構成される。データベース５１には、物件３００別に第１データおよび第２データが登録されている（図１１参照）。

　学習装置１１０は、物件３００別に登録された第１データおよび第２データを１セットの学習用データ５として利用する。たとえば、図１１に示される物件データ５４において、（物件３００Ａの第１データ、物件３００Ａの日時情報Ａ１の第２データ）、（物件３００Ａの第１データ、物件３００Ａの日時情報Ａ２の第２データ）、（物件３００Ａの第１データ、物件３００Ａの日時情報Ａ３の第２データ）…、（物件３００Ｂの第１データ、物件３００Ｂの日時情報Ｂ１の第２データ）、（物件３００Ｂの第１データ、物件３００Ｂの日時情報Ｂ２の第２データ）、（物件３００Ｂの第１データ、物件３００Ｂの日時情報Ｂ３の第２データ）…、の各々が、１セットの学習用データ５に該当する。

　学習装置１１０の入力部１１１には、これらの１セットの学習用データ５のうち、第１データ（位置情報、気候情報）と、第２データの一部である気象情報とが入力される。学習装置１１０の学習部１１３には、第２データのうちの優先順位が正解データとして入力される。

　判定部１１２は、入力部１１１に入力された学習用データ５と推定モデル１１４とに基づいて優先順位を判定し、判定結果を学習部１１３に出力する。学習部１１３は、判定部１１２によって得られた判定結果と、正解データとに基づき、推定モデル１１４を学習させる。具体的には、学習部１１３は、推定モデル１１４によって得られた判定結果が、正解データに近づくように、パラメータ１１６（たとえば、重み付け係数）を調整することで、推定モデル１１４を学習させる。

　このように、推定モデル１１４は、空気調和装置２００が配置される物件３００の位置情報、気候情報、気象情報、および優先順位を含む学習用データに基づき、空気調和装置２００が配置される物件３００の位置情報、気候情報、および気象情報から優先順位を判定するように学習されている。
＜運用フェーズ＞
　図１４は、サーバ１００が学習済みの推定モデル１１４を用いて応用プログラム２３１の利用に関する優先順位を推定する手順を説明するためのブロック図である。サーバ１００は、学習済みの推定モデル１１４を利用して、新規物件３０１に新たに設置された空気調和装置２００Ｃを対象とする優先順位を出力することができる。

　サーバ１００は、判定装置１２０と、推定モデル１１４とを備える。判定装置１２０および推定モデル１１４は、サーバ１００のプロセッサ１０１およびメモリ１０２によって実現される。

　判定装置１２０は、入力部１２１と、処理部１２２と、出力部１２３とを備える。入力部１２１には、判定装置１２０がお勧めする優先順位を調べたい物件３００の情報が入力される。たとえば、新規物件３０１に新たに設置された空気調和装置２００Ｃを対象とする優先順位を調べたい場合、新規物件３０１の第１データ（位置情報、気候情報）と、現時点での新規物件３０１の気象情報（外気温度、湿度）とが入力部１２１に入力される。

　新規物件３０１の第１データは、新たな物件３００に空気調和装置２００を設置する際、空気調和装置２００の開発元の担当者によってデータベース５１に登録されている。入力部１２１へは、データベース５１に登録済みの第１データが入力される。気象情報は、たとえば、広域ネットワーク６０を介して、新規物件３０１に設置した空気調和装置２００Ｃから入力部１２１に入力される。新規物件３０１に対応する端末装置２０Ｃを用いてユーザが気象情報を入力部１２１に入力してもよい。

　処理部１２２は、入力部１２１に入力された第１データおよび気象情報と、推定モデル１１４とに基づいて優先順位を判定し、判定結果を出力部１２３に出力する。出力部１２３は、判定結果を判定装置１２０の外部に出力する。サーバ１００は、判定結果を端末装置２０Ｃに送信する。端末装置２０Ｃは、判定結果に基づいて、優先順位をお勧めの応用プログラムとしてディスプレイ４０に表示する。

　ユーザは、ディスプレイ４０の表示に基づいて、空気調和装置２００Ｃに導入する応用プログラム２３１の優先順位を設定することができる。また、ユーザは、ディスプレイ４０に表示された優先順位から、導入不要と考えられる応用プログラム２３１を特定することもできる。

　ユーザが優先順位を組み替える機能を端末装置２０Ｃに設けてもよい。端末装置２０Ｃは、ユーザが優先順位を確定する操作を検出したときに、サーバ１００に確定した優先順位を送信する機能を備えてもよい。サーバ１００は、確定した優先順位を端末装置２０Ｃから受信したときに、その優先順位に従って空気調和装置２００Ｃの応用プログラム２３１を設定する機能を備えてもよい。

　以上説明したように、サーバ１００を含む遠隔制御システム３によれば、新規物件３０１に空気調和装置２００Ｃを導入する場合、学習済みの推定モデル１１４に、新規物件３０１の物件データを入力し、応用ソフトウェア部２３０に導入すべき各種の応用プログラム２３１をレコメンドすることができる。

　学習済みの推定モデル１１４をサーバ１００に内に配置することに代えて、学習済みの推定モデル１１４を空気調和装置２００内に配置してもよい。学習装置１１０は、学習用データとして、図１２に示される応用プログラム２３１の利用回数をさらに利用して、優先順位を推定するための学習をしてもよい。この場合、新規物件３０１において空気調和装置２００Ｃは、試運転をしたときに、各応用プログラム２３１の利用回数を示すデータを学習済みの推定モデル１１４に入力してもよい。

　空気調和装置２００Ｃは、空気調和装置２００Ｃまたはサーバ１００に配置された学習済みの推定モデル１１４の出力結果を利用して、応用プログラム２３１に関する、より適切な優先順位を設定することができる。これにより、空気調和装置２００Ｃ（ジョブ制御部２２２およびデータ管理部２２３)は、自身のジョブスケジュール２２６を適切なスケジュールに更新することができる。

　図１５は、新規物件３０１に空気調和装置２００Ｃが導入された場合に、新規物件３０１の第１データおよび物件ＩＤをデータベース５１に登録する手順を示すフローチャートである。はじめに、サーバ１００は、新規物件３０１に空気調和装置２００Ｃが設置されたか否かを判定する（ステップＳ７０１）。

　たとえば、サーバ１００は、空気調和装置２００Ｃから、データベース５１に未登録の物件ＩＤを受信した場合に新規物件３０１に空気調和装置２００Ｃが設置されたと判定する。この場合、サーバ１００は、新規物件３０１の第１データを物件ＩＤとともにデータベース５１に登録する（ステップＳ７０２）。ステップＳ７０１において、ＮＯと判定された場合、ステップＳ７０２の処理が実行されることなく、本フローチャートに基づく処理は終了する。

　図１６は、学習済みの推定モデル１１４を作成する手順を説明するためのフローチャートである。ここでは、複数の物件３００の各々に設置された空気調和装置２００の処理と、サーバ１００の処理とをまとめて説明する。

　はじめに、空気調和装置２００は、タイマＴが規定時間を計時したことを判定する（ステップＳ８０１）。ここで、規定時間は、空気調和装置２００において応用プログラム２３１の優先順位と気象情報とを算出する時間間隔である。

　空気調和装置２００は、タイマＴが規定時間を計時すると、応用プログラム２３１の利用頻度を応用プログラム２３１の種類別に算出する（ステップＳ８０２）。次に、空気調和装置２００は、算出した利用頻度に基づいて、応用プログラム２３１の優先順位を作成する（ステップＳ８０３）。ここで作成される優先順位の情報には、各々の応用プログラム２３１の利用頻度が含まれる。次に、空気調和装置２００は、温湿度センサ２４３を用いて外気温度および湿度を計測する（ステップＳ８０４）。

　次に、空気調和装置２００は、物件ＩＤおよび第２データ（気象情報および優先順位を含む）をサーバ１００へ送信する（ステップＳ８０５）。その後、空気調和装置２００は、タイマＴをリスタートさせ（ステップＳ８０６）、本フローチャートに基づく処理を終える。

　サーバ１００は、第２データを受信するまで待機する（ステップＳ８１１）。やがて、いずれかの空気調和装置２００が第２データを物件ＩＤとともにサーバ１００へ送信する。サーバ１００は、受信した第２データを物件ＩＤ別にデータベース５１に登録する（ステップＳ８１２）。次に、サーバ１００は、データベース５１に登録されている第１データおよび第２データを用いて、学習処理を実行し（ステップＳ８１３）、推定モデル１１４を更新する（ステップＳ８１４）。これにより、本フローチャートに基づく処理が終了する。

　図１７は、空気調和装置２００Ｃに推奨される応用プログラム２３１の優先順位を判定する手順を説明するためのフローチャートである。

　はじめに、サーバ１００は、新規物件３０１の第１データおよび気象情報を取得する（ステップＳ９０１）。

　次に、サーバ１００は、新規物件３０１の第１データおよび気象情報を学習済みの推定モデル１１４に入力する（ステップＳ９０２）。次に、サーバ１００は、推定モデル１１４から判定結果（優先順位）を出力する（ステップＳ９０３）。次に、サーバ１００は、出力された判定結果をお勧めの応用プログラム情報として、端末装置２０Ｃへ送信し（ステップＳ９０４）、本フローチャートに基づく処理を終える。

　以上、説明したとおり、本実施の形態によれば、判定装置１２０を利用することにより、応用プログラム２３１の利用頻度に応じて、現地（各物件３００）で使用したい機能に対応する応用プログラム２３１のみを空気調和装置２００にインストールすることができる。このように、本実施の形態によれば、使っていない応用プログラム２３１を空気調和装置２００のメモリ２１２から排除することができる。これにより、メモリ２１２内のデータの空き領域を広げることができる。このことは、他の有用な応用プログラム２３１をインストールする余裕を空気調和装置２００に与えることになる。したがって、ユーザは、必要に応じて、応用プログラム２３１の種類をカスタマイズすることができる。

　本実施の形態によれば、現地（各物件３００）の情報とプログラムの利用頻度（あるいは利用回数）とから推定モデル１１４を学習させることで、各物件３００の特性を考慮した適切な優先順位データを出力することが可能な学習モデルが形成される。これにより、新規物件３０１の空気調和装置２００Ｃに対して、どの機能を適用すべきかをユーザにレコメンドすることができる。その結果、空気調和装置２００Ｃを新規物件３０１に導入した時点で、その優先順位を自動的に空気調和装置２００Ｃに適用することも可能となる。判定装置１２０を利用することにより、空気調和装置２００Ｃに適用すべき応用プログラム２３１を人が選択する必要がなくなり、その結果、人による判定ミスを防止できる。したがって、本実施の形態によれば、機械学習による最適制御を空調システム１に適用することができる。

　図１８は、変形例としての空調システム２の全体構成を示す図である。図１８に示されるように、空気調和装置２００は、物件３００内の構内ネットワーク６１を介して、遠隔制御システム３と接続される。空調システム２は、物件３００内に構内ネットワーク６１が形成される点を除くと、空調システム１と同様である。したがって、ここでは、これ以上、空調システム２の説明を繰り返すことをしない。

　図１９は、図６に関連する変形例を説明するためのフローチャートである。本変形例では、図６に示されるフローチャートに対して、ステップＳ２１１１～ステップＳ２１１５が追加されている。

　本変形例では、ステップＳ２０４において、対象プログラムをインストールする十分な空き領域がメモリ２１２に存在しない場合、メモリ２１２の中から優先順位の低い応用プログラム２３１を削除し、空き領域を確保する例を説明する。ここでは、ステップＳ２０２、ステップＳ２０４、ステップＳ２０６、ステップＳ２０８、およびステップＳ２１０の詳細な説明を繰り返さない。

　空気調和装置２００は、ステップＳ２０４において、対象プログラムをインストールする十分な空き領域がメモリ２１２に存在しないと判断した場合、メモリ２１２内から優先順位の最も低い応用プログラム２３１を選択する（ステップＳ２１１１）。ここでは、ステップＳ２１１１において選択された応用プログラム２３１を応用プログラムＸとする。優先順位は、たとえば、使用頻度によって決定される。空気調和装置２００は、応用プログラム２３１が使用される毎に使用回数を応用プログラム別に更新する。空気調和装置２００は、その使用回数に基づいて、使用頻度を判定する。

　次に、空気調和装置２００は、応用プログラムＸを削除することを、ユーザに通知する（ステップＳ２１１２）。たとえば、空気調和装置２００は、応用プログラムＸを削除すること示す情報を、ユーザの端末装置２０へ送信する。

　次に、空気調和装置２００は、応用プログラムＸの削除に関するユーザの指示をユーザから受信する（ステップＳ２１１３）。この指示は、たとえば、ユーザの端末装置２０から送信される。

　次に、空気調和装置２００は、ユーザが応用プログラムＸの削除を許可しているか否かを判定する（ステップＳ２１１４）。ユーザが応用プログラムＸの削除を許可していない場合、空気調和装置２００は、ステップＳ２１０に処理を進める。ユーザが応用プログラムＸの削除を許可している場合、空気調和装置２００は、応用プログラムＸをメモリ２１２から削除する（ステップＳ２１１５）。次に、空気調和装置２００は、ステップＳ２０８の処理を実行する。これにより、空気調和装置２００からサーバ１００に対して、対象プログラムの配信許可が返信される。その結果、メモリ２１２の空き領域が確保された状態で対象プログラムが空気調和装置２００に配信される。

　（まとめ）
　以上の実施の形態について総括する。

　（１）　本開示は、空気調和システム（１）であって、空気調和装置（２００）と、空気調和装置と通信するサーバ（１００）とを備え、空気調和装置は、空調ソフトウェアを格納するメモリ（２１２）と、メモリの空調ソフトウェアを実行するプロセッサ（２１１）とを有し、空調ソフトウェアは、空気調和装置が提供する複数の機能をそれぞれ実現する複数の応用ソフトウェア（２３１）と、複数の応用ソフトウェアのジョブを管理する基本ソフトウェア（２２１）とを含み、サーバは、プロセッサが複数の応用ソフトウェアのうちの１つを更新するために必要な第１更新用データを空気調和装置に配信し（ステップＳ４０４）、プロセッサは、第１更新用データに基づいて、基本ソフトウェアを用いてメモリ内の対応する応用ソフトウェアを更新する（ステップＳ４１８）。

　（２）　空調システムにおいて、サーバは、メモリに格納されていない新規の応用ソフトウェアを空気調和装置に配信し（ステップＳ１１２，ステップＳ１１４，ステップＳ４０４）、プロセッサは、配信された新規の応用ソフトウェアをメモリに格納することにより、新規の応用ソフトウェアによって実現される新たな機能を空気調和装置に追加する（ステップＳ４２０）。

　（３）　空調システムにおいて、サーバは、空気調和装置に基本ソフトウェアを更新するために必要な第２更新用データを配信し（ステップＳ６０４）、プロセッサは、第２更新用データに基づいて、メモリ内の対応する基本ソフトウェアを更新する（図８，図９）。

　（４）　空調システムにおいて、基本ソフトウェアは、複数のモジュールを含み（２２２～２２６）、プロセッサは、第２更新用データに基づいて、複数のモジュール毎にメモリ内の対応する基本ソフトウェアを更新する（ステップＳ６１６）。

　（５）　複数のモジュールは、第１モジュールおよび第２モジュール（ジョブ制御部２２２、データ管理部２２３、通信部２２４、デバイスドライバ２２５、およびジョブスケジュール２２６を構成するプログラムモジュールのうち、ジョブ制御部２２２を構成するモジュール以外）を含み、プロセッサは、複数のモジュールの各々を、順次、メモリに格納し（ステップＳ６１０）、第１モジュールのメモリへの格納が完了したときに第２モジュールのメモリへの格納が完了していない場合、第１モジュールを用いてメモリ内の対応する基本ソフトウェアの第１モジュールの部分を更新する（ステップＳ６１２～ステップＳ６１６）。

　（６）複数のモジュールは、メモリ内の対応する基本ソフトウェアを更新するために用いられるジョブモジュール（ジョブ制御部２２２）を含み、プロセッサは、複数のモジュール毎にメモリ内の対応する基本ソフトウェアを更新する場合、基本ソフトウェアのジョブモジュールの部分を最後に更新する（ステップＳ６２４）。

　（７）　空調システムにおいて、サーバと通信する端末装置（２０）をさらに備え、サーバは、複数の応用ソフトウェアのうちの１つを更新可能であることを端末装置へ通知し（ステップＳ１０８）、サーバは、複数の応用ソフトウェアのうちの１つを更新することに対する許可を端末装置から得た後、空気調和装置へ前記第１更新用データを配信する（ステップＳ１２０）。

　（８）　空調システムは、空気調和装置において複数の応用ソフトウェアの各々が利用される優先順位を判定する判定装置（１２０）を備え、判定装置は、空気調和装置が配置される場所の位置情報、気候情報、および気象情報、並びに、ニューラルネットワークを含む推定モデルに基づき、優先順位を判定し、優先順位の判定結果を出力する（ステップＳ９０３）。

　（９）　空調システムにおいて、サーバは、判定装置を含む（図１４）。
　（１０）　空調システムにおいて、推定モデルは、空気調和装置が配置される場所の位置情報、気候情報、気象情報、および優先順位を含む学習用データに基づき、空気調和装置が配置される場所の位置情報、気候情報、および気象情報から優先順位を判定するように学習されている（図１３）。

　（１１）　空気調和装置は、メモリ内の容量が不足する場合、メモリに格納されている複数の応用ソフトウェアのうち、優先順位の低い応用ソフトウェアを削除してから、メモリ内の対応する応用ソフトウェアを更新する（ステップＳ２１１１～ステップＳ２１１５）。

　（１２）　本開示は、サーバと通信可能な空気調和装置であって、空調ソフトウェアを格納するメモリと、メモリに格納された空調ソフトウェアを実行するプロセッサとを備え、空調ソフトウェアは、空気調和装置が提供する複数の機能をそれぞれ実現する複数の応用ソフトウェアと、複数の応用ソフトウェアのジョブを管理する基本ソフトウェアとを含み、プロセッサは、複数の応用ソフトウェアのうちの１つを更新するために必要な第１更新用データをサーバから受信した場合、第１更新用データに基づいて、基本ソフトウェアを用いてメモリ内の対応する応用ソフトウェアを更新する。

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

　１，２　空調システム、　３　遠隔制御システム、５　学習用データ、１０　端末装置、２０，２０Ａ，２０Ｂ　端末装置、３０　クラウド、４０　ディスプレイ、５０　記憶装置、５１　データベース、５２　マスタデータ、５３　機種特定用データ、５４　物件データ、６０　広域ネットワーク、６１　構内ネットワーク、１００　サーバ、１０１　プロセッサ、１０２　メモリ、１１０　学習装置、１１１　入力部、１１２　判定部、１１３　学習部、１１４　推定モデル、１１５　ニューラルネットワーク、１１６　パラメータ、１１７　処理部、１１８　出力部、１２０　判定装置、１２１　入力部、１２２　処理部、１２３　出力部、２００，２００Ａ，２００Ｂ　空気調和装置、２０１　管理装置、２０２　室内機、２０３　室外機、２１０　空調ソフトウェア、２１１　プロセッサ、２１２　メモリ、２１３　プログラム領域、２１４　空き領域、２２０　基本ソフトウェア部、２２１　基本プログラム、２２２　ジョブ制御部、２２３　データ管理部、２２４　通信部、２２５　デバイスドライバ、２２６　ジョブスケジュール、２３０　応用ソフトウェア部、２３１　応用プログラム、２３１Ａ　運転制御プログラム、２３１Ｂ　機器保護制御プログラム、２３１Ｃ　霜取制御プログラム、２４０　ハードウェアデバイス、２４１　温度センサ、２４２　圧力センサ、２４３　温湿度センサ、２４４　圧縮機、２４５　ファン、２４６　弁、３００，３００Ａ，３００Ｂ　物件、３０１　新規物件。

Claims (12)

1. 　空気調和システムであって、
   　空気調和装置と、
   　前記空気調和装置と通信するサーバとを備え、
   　前記空気調和装置は、
   　　空調ソフトウェアを格納するメモリと、
   　　前記メモリの空調ソフトウェアを実行するプロセッサとを有し、
   　前記空調ソフトウェアは、
   　　前記空気調和装置が提供する複数の機能をそれぞれ実現する複数の応用ソフトウェアと、
   　　前記複数の応用ソフトウェアのジョブを管理する基本ソフトウェアとを含み、
   　前記サーバは、前記プロセッサが前記複数の応用ソフトウェアのうちの１つを更新するために必要な第１更新用データを前記空気調和装置に配信し、
   　前記プロセッサは、前記第１更新用データに基づいて、前記基本ソフトウェアを用いて前記メモリ内の対応する応用ソフトウェアを更新する、空気調和システム。
2. 　前記サーバは、前記メモリに格納されていない新規の応用ソフトウェアを前記空気調和装置に配信し、
   　前記プロセッサは、配信された前記新規の応用ソフトウェアを前記メモリに格納することにより、前記新規の応用ソフトウェアによって実現される新たな機能を前記空気調和装置に追加する、請求項１に記載の空気調和システム。
3. 　前記サーバは、前記基本ソフトウェアを更新するために必要な第２更新用データを前記空気調和装置に配信し、
   　前記プロセッサは、前記第２更新用データに基づいて、前記メモリ内の対応する基本ソフトウェアを更新する、請求項１または請求項２に記載の空気調和システム。
4. 　前記基本ソフトウェアは、複数のモジュールを含み、
   　前記プロセッサは、前記第２更新用データに基づいて、前記複数のモジュール毎に前記メモリ内の対応する基本ソフトウェアを更新する、請求項３に記載の空気調和システム。
5. 　前記複数のモジュールは、第１モジュールおよび第２モジュールを含み、
   　前記プロセッサは、前記複数のモジュールの各々を、順次、前記メモリに格納し、前記第１モジュールの前記メモリへの格納が完了したときに前記第２モジュールの前記メモリへの格納が完了していない場合、前記第１モジュールを用いて前記メモリ内の対応する基本ソフトウェアの前記第１モジュールの部分を更新する、請求項４に記載の空気調和システム。
6. 　前記複数のモジュールは、前記メモリ内の対応する基本ソフトウェアを更新するために用いられるジョブモジュールを含み、
   　前記プロセッサは、前記複数のモジュール毎に前記メモリ内の対応する基本ソフトウェアを更新する場合、前記基本ソフトウェアの前記ジョブモジュールの部分を最後に更新する、請求項５に記載の空気調和システム。
7. 　前記サーバと通信する端末装置をさらに備え、
   　前記サーバは、前記複数の応用ソフトウェアのうちの１つを更新可能であることを前記端末装置へ通知し、
   　前記サーバは、前記複数の応用ソフトウェアのうちの１つを更新することに対する許可を前記端末装置から得た後、前記空気調和装置へ前記第１更新用データを配信する、請求項１～請求項６のいずれか１項に記載の空気調和システム。
8. 　前記空気調和装置で前記複数の応用ソフトウェアの各々が利用される優先順位を判定する判定装置を備え、
   　前記判定装置は、前記空気調和装置が配置される場所の位置情報、気候情報、および気象情報、並びに、ニューラルネットワークを含む推定モデルに基づき、前記優先順位を判定し、前記優先順位の判定結果を出力する、請求項１～請求項７のいずれか１項に記載の空気調和システム。
9. 　前記サーバは、前記判定装置を含む、請求項８に記載の空気調和システム。
10. 　前記推定モデルは、前記空気調和装置が配置される場所の位置情報、気候情報、気象情報、および前記優先順位を含む学習用データに基づき、前記空気調和装置が配置される場所の位置情報、気候情報、および気象情報から前記優先順位を判定するように学習されている、請求項８または請求項９に記載の空気調和システム。
11. 　前記空気調和装置は、前記メモリ内の容量が不足する場合、前記メモリに格納されている複数の応用ソフトウェアのうち、優先順位の低い応用ソフトウェアを削除してから、前記メモリ内の対応する応用ソフトウェアを更新する、請求項１～請求項７のいずれか１項に記載の空気調和システム。
12. 　サーバと通信可能な空気調和装置であって、
    　空調ソフトウェアを格納するメモリと、
    　前記メモリに格納された空調ソフトウェアを実行するプロセッサとを備え、
    　前記空調ソフトウェアは、
    　　前記空気調和装置が提供する複数の機能をそれぞれ実現する複数の応用ソフトウェアと、
    　　前記複数の応用ソフトウェアのジョブを管理する基本ソフトウェアとを含み、
    　前記プロセッサは、前記複数の応用ソフトウェアのうちの１つを更新するために必要な第１更新用データを前記サーバから受信した場合、前記第１更新用データに基づいて、前記基本ソフトウェアを用いて前記メモリ内の対応する応用ソフトウェアを更新する、空気調和装置。

Images