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

Abstract

【課題】空気調和装置本体に対するアクセスを様々なロケーションから行うことができるプラットフォームを備えた空気調和システムを提供すること。
【解決手段】空気調和システムは、本体装置と遠隔装置を備える。遠隔装置は、少なくとも演算処理部と該演算処理部を制御するソフトウェアを備え、本体装置とネットワークを介して接続される。本体装置のソフトウェアは、各ハードウェアを駆動するドライバ群を有するハードウェアアクセス層と、ハードウェア群をドライバ群を介して制御する制御層と、本体装置への命令を受け付けて制御層に指示を出力する本体装置側機能層とを備える。遠隔装置のソフトウェアは、本体装置への命令を受け付けて本体装置側機能層を介して制御層に指示を出力する遠隔装置側機能層を備える。そして、少なくとも本体装置側機能層と遠隔装置側機能層のいずれか一方に、本体装置が提供する機能を実行する機能実行プログラムが配置される。
【選択図】図２

Description

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

近年、空気調和装置は、スマートフォンなどの携帯端末からネットワークを介して遠隔制御を行う機能など様々な機能を利用者に提供している。これらの機能は、ソフトウェアによって実現されている。

特開２００４−２８９５０５号公報

従来の空気調和装置では、空気調和装置に含まれるハードウェア（圧縮機、熱交換器、送風ファンなど）と各種機能を実行するソフトウェアとが空気調和装置本体に集約されている。従って、空気調和装置本体に対する制御や空気調和装置本体からの運転情報などの収集は、基本的に空気調和装置本体にアクセスする必要があるためその自由度が限られており、保守サービスや機能追加などのサービスを提供しづらいという問題があった。

本発明は上記課題を解決するものであり、空気調和装置本体に対するアクセス（制御や情報収集など）を、様々なロケーション（空気調和装置やクラウドなど）から行えるプラットフォームを備えた空気調和システムを提供することを目的とする。ここで、プラットフォームとは、それぞれのロケーションに設けられた機能層である。

開示の態様では、空気調和システムは、本体装置と遠隔装置を備える。前記本体装置は、少なくとも圧縮機と、熱交換器と、送風ファンとを含むハードウェア群と、前記ハードウェア群を制御するソフトウェアとを備える。前記遠隔装置は、少なくとも演算処理部と該演算処理部を制御するソフトウェアを備え、前記本体装置とネットワークを介して接続される。前記本体装置のソフトウェアは、各ハードウェアを駆動するドライバ群を有するハードウェアアクセス層と、前記ハードウェア群を、前記ドライバ群を介して制御する制御層と、前記本体装置への命令を受け付けて前記制御層に指示を出力する本体装置側機能層と、を備える。前記遠隔装置のソフトウェアは、前記本体装置への命令を受け付けて前記本体装置側機能層を介して前記制御層に指示を出力する遠隔装置側機能層を備える。そして、少なくとも前記本体装置側機能層と前記遠隔装置側機能層のいずれか一方に、前記本体装置が提供する機能を実行する機能実行プログラムが配置されることを特徴とする。

開示の空気調和システムは、空気調和装置本体に対するアクセスを、様々なロケーションから行うことを可能とする。

図１は、実施例に係る空気調和システムの構成を示す図である。 図２は、空気調和システムが備えるソフトウェアの部品構成を示す図である。 図３は、気流調整部がクラウドに配置され、利用者が遠隔端末から風量又は風向を変更する場合の空気調和システムによる処理のシーケンスを示す図である。 図４は、気流調整部が室内機に配置され、利用者が赤外線リモコンから風量又は風向を変更する場合の空気調和システムによる処理のシーケンスを示す図である。 図５は、機能層における処理を中心に、空気調和システムによる処理のシーケンスを示す図である。 図６は、気流調整部が室内に配置される場合を示す図である。 図７は、クラウドに気流調整部が配置された場合に気流調整部が風量変更指示及び風向変更指示に対するイベント型応答を空調機ＡＰＩ処理部から受信する場合を示す図である。

以下に、本願の開示する空気調和システムの実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本願の開示する空気調和システムが限定されるものではない。

まず、実施例に係る空気調和システムの構成について説明する。図１は、実施例に係る空気調和システムの構成を示す図である。図１に示すように、実施例に係る空気調和システム１は、ＧＷ（ゲートウェイ）２と、遠隔端末４と、クラウド５と、空調機６と、リモコン６ｃと、加湿器７と、他機器８とを有する。

ＧＷ（ゲートウェイ）２は、遠隔端末４又はクラウド５からインターネット３（ネットワーク）を経由した操作指示を受けて、空調機６を制御する機器である。ＧＷ２は、ＧＷ制御部２ａを有する。ＧＷ制御部２ａは、ＧＷ２を制御する。

遠隔端末４は、利用者から操作指示を受け付けて、インターネット３及びＧＷ２を介して空調機６を制御する端末である。遠隔端末４は、例えば、スマートフォン、タブレットである。遠隔端末４は、端末制御部４ａを有する。端末制御部４ａは、遠隔端末４を制御する。

クラウド５は、インターネット３及びＧＷ２を介して空調機６を制御するシステムである。クラウド５は、複数の情報処理装置５ａを有し、複数の情報処理装置５ａの中でいくつかの情報処理装置５ａでソフトウェアを実行することにより、空調機６を制御する。

空調機６は、冷暖房機能を備えた空気調和装置である。空調機６は、室外機６ａと、室内機６ｂとを有する。室外機６ａと室内機６ｂは、液管６ｐとガス管６ｑで接続される。

リモコン６ｃは、室内機６ｂと無線通信を行う。リモコン６ｃは、利用者により操作され、利用者の指示を無線通信を用いて室内機６ｂに送信する。リモコン６ｃは、リモコン制御部６ｓを有する。リモコン制御部６ｓは、リモコン６ｃを制御する。リモコン６ｃには、赤外線リモコンとＢＬＥ（Bluetooth(登録商標、以下同様) Low Energy）リモコンが含まれる。赤外線リモコンは、赤外線を用いて室内機６ｂと通信する。ＢＬＥリモコンは、Bluetoothを用いて室内機６ｂと通信する。

室外機６ａは、圧縮機６ｄと、室外熱交換器６ｅと、室外ファン６ｆと、室外制御部６ｇとを有する。室外機６ａは、室外熱交換器６ｅを用いて、室外機６ａの内部に取り込んだ室外空気と冷媒の熱交換を行う。室外機６ａは、室外ファン６ｆを用いて室外機６ａの内部に空気を吸い込む。冷媒は、圧縮機６ｄにより圧縮され、室外機６ａ、液管６ｐ、室内機６ｂ、ガス管６ｑを循環する。室外制御部６ｇは、室外機６ａを制御する。

室内機６ｂは、室内熱交換器６ｈと、室内ファン６ｉと、風向板６ｊと、室内制御部６ｋとを有する。室内機６ｂは、室内熱交換器６ｈを用いて、室内機６ｂの内部に取り込んだ室内空気と冷媒の熱交換を行う。室内機６ｂは、室内ファン６ｉを用いて室内機６ｂの内部に空気を取り込み、冷媒と熱交換が行われた空気を室内に吹き出す。風向板６ｊは、室内ファン６ｉにより吐き出される空気の方向を変える。室内制御部６ｋは、室内機６ｂを制御する。

加湿器７は、空調機６と連携して動作する。例えば、空調機６が暖房運転を開始する場合に、連携機能が設定されていると、加湿器７も動作を開始する。

他機器８は、連携機能が設定されていると、空調機６と連携して動作する。他機器８は、例えば、暖房器具や照明器具などの家庭用電気機器である。なお、図１では、他機器８を１つだけ示すが、空気調和システム１は、複数の他機器８を有してもよい。

ＧＷ制御部２ａ、端末制御部４ａ、室外制御部６ｇ、室内制御部６ｋ及びリモコン制御部６ｓは、ソフトウェアを用いて制御機能を実現する。ＧＷ制御部２ａ、端末制御部４ａ、室外制御部６ｇ、室内制御部６ｋ及びリモコン制御部６ｓは、それぞれ、演算処理部としてのＣＰＵ（Central Processing Unit）２ｂ、４ｂ、６１ｂ、６２ｂ及び６３ｂとメモリ２ｃ、４ｃ、６１ｃ、６２ｃ及び６３ｃとを有する。そして、これらの制御部は、メモリ２ｃ、４ｃ、６１ｃ、６２ｃ及び６３ｃがそれぞれ記憶するプログラムをＣＰＵ２ｂ、４ｂ、６１ｂ、６２ｂ及び６３ｂで実行することにより、制御機能を実現する。

また、情報処理装置５ａは、演算処理部としてのＣＰＵ５ｂとメモリ５ｃとを有し、メモリ５ｃが記憶するプログラムをＣＰＵ５ｂで実行することにより、空調機６を制御する。

次に、空気調和システム１が備えるソフトウェアの部品構成について説明する。図２は、空気調和システム１が備えるソフトウェアの部品構成を示す図である。図１に示すように、実施例に係る空気調和システム１が備えるソフトウェアは、ドライバ層１０と、ハードウェア抽象化層２０と、制御層３０と、機能層４０とを含む階層構造を有する。

ドライバ層１０は、ハードウェア９にアクセスするハードウェアアクセス層である。ここで、ハードウェア９には、室内熱交換器６ｈ、室内ファン６ｉ、風向板６ｊ、圧縮機６ｄ、室外熱交換器６ｅ、室外ファン６ｆが含まれる。ドライバ層１０に含まれる部品は、ハードウェア抽象化層２０に含まれる部品の指示に基づいて、ハードウェア９を制御し、ハードウェア９からの応答をハードウェア抽象化層２０に返す。

ドライバ層１０には、ファンモータドライバ１１と、ステッピングモータドライバ１２と、室外機ドライバ１３と、赤外線通信モジュールドライバ１４と、有線通信ドライバ１５と、Ｗｉ−Ｆｉ規格に対応した通信モジュールドライバ（以下、ＷｉＦｉモジュールドライバ１６）と、ＢＬＥモジュールドライバ１７が部品として含まれる。

ファンモータドライバ１１、ステッピングモータドライバ１２及び室外機ドライバ１３は、空調機６の室内機内に配置される。赤外線通信モジュールドライバ１４、有線通信ドライバ１５、ＷｉＦｉモジュールドライバ１６及びＢＬＥモジュールドライバ１７は、空調機６の室内機内に配置されるとともに遠隔配置される。ここで、遠隔配置とは、クラウド５、ＧＷ２、遠隔端末４、リモコン６ｃなどのように、室内機６ｂから離れたロケーションにおける配置である。クラウド５は、複数の情報処理装置５ａを有するシステムであるが、ここでは、クラウド５を１つの装置とみなす。

ファンモータドライバ１１は、室内ファン６ｉを回転させるファンモータを制御する。ステッピングモータドライバ１２は、例えば風向板６ｊを動作させるステッピングモータを制御する。室外機ドライバ１３は、例えば室外機６ａが備える圧縮機６ｄを室外機６ａとの通信を介して制御する。

赤外線通信モジュールドライバ１４は、赤外線を用いて無線通信を行う赤外線通信モジュールを制御する。有線通信ドライバ１５は、有線ネットワークを介して通信を行う通信モジュールを制御する。ＷｉＦｉモジュールドライバ１６は、Ｗｉ−Ｆｉ規格に対応した無線通信を行うＷｉＦｉモジュールを制御する。ＢＬＥモジュールドライバ１７は、Bluetoothを用いて無線通信を行うBluetoothモジュールを制御する。

ハードウェア抽象化層２０に含まれる部品は、制御層３０に含まれる部品の指示に基づいて、ドライバ層１０に含まれる部品にハードウェア９の制御を指示すると共に、制御層３０からの指示を受け付けたことを伝える応答信号を制御層３０に返す。ドライバ層１０に含まれる部品は、ハードウェア抽象化層２０に含まれる部品の指示に基づいて、ハードウェアの制御を指示する。このとき、ハードウェアがいわゆるフィードバック制御（制御量の値を目標値と比較し，制御量の値が目標値と一致するように訂正動作を行う制御）により制御される場合には、ハードウェアはドライバ層１０に対して、指示に対する応答信号（フィードバック信号）を出力する。ドライバ層１０の部品は、ハードウェアからのフィードバック信号に応じて、ハードウェア抽象化層２０の部品に対してフィードバック信号を出力する。フィードバック信号を受けたハードウェア抽象化層２０の部品は、受信したフィードバック信号に応じて、追加の制御を下位層（ドライバ層１０を介したハードウェア）に指示する。

ハードウェア抽象化層２０には、ファン制御部２１と、風向板制御部２２と、室外機制御部２３と、赤外線通信制御部２４と、有線通信制御部２５と、ＷｉＦｉ通信制御部２６と、ＢＬＥ通信制御部２７が部品として含まれる。ファン制御部２１、風向板制御部２２及び室外機制御部２３は、室内機内に配置される。赤外線通信制御部２４、有線通信制御部２５、ＷｉＦｉ通信制御部２６及びＢＬＥ通信制御部２７は、室内機内に配置されるとともに遠隔配置される。

ファン制御部２１は、室内ファン６ｉをファンモータドライバ１１を用いて制御する。風向板制御部２２は、風向板６ｊをステッピングモータドライバ１２を用いて制御する。室外機制御部２３は、例えば室外機６ａが備える圧縮機６ｄを室外機ドライバ１３を用いて制御する。

赤外線通信制御部２４は、赤外線通信を赤外線通信モジュールドライバ１４を用いて制御する。有線通信制御部２５は、有線ネットワークを介した通信を有線通信ドライバ１５を用いて制御する。ＷｉＦｉ通信制御部２６は、ＷｉＦｉ通信をＷｉＦｉモジュールドライバ１６を用いて制御する。ＢＬＥ通信制御部２７は、Bluetooth通信を無線通信をＢＬＥモジュールドライバ１７を用いて制御する。

ハードウェア抽象化層２０は、抽象化されたハードウェア９を制御する手段を制御層３０に提供する。例えば、ファン制御部２１は、ファンモータの種類やファンの種類に依存しないファン制御手段を制御層３０の風量制御部３１に提供する。

制御層３０に含まれる部品は、機能層４０に含まれる機能部の指示に基づいて、ハードウェア抽象化層２０に含まれる部品に、抽象化されたハードウェア９の制御を指示し、ハードウェア抽象化層２０からの応答を機能層４０に返す。制御層３０には、風量制御部３１と、風向制御部３２と、圧縮機制御部３３と、通信制御部３４と、保護制御部３５とが部品として含まれる。風量制御部３１、風向制御部３２、圧縮機制御部３３及び保護制御部３５は、室内機内に配置される。通信制御部３４は、室内機内に配置されるとともに遠隔配置される。

風量制御部３１は、室内ファン６ｉが出力する風の量をファン制御部２１を用いて制御する。風向制御部３２は、室内ファン６ｉが出力する風の方向を風向板制御部２２を用いて制御する。圧縮機制御部３３は、室外機６ａが備える圧縮機６ｄを室外機ドライバ１３を介して制御する。

通信制御部３４は、室内機６ｂとＧＷ２、室内機６ｂと遠隔端末４、室内機６ｂとクラウド５など異なるロケーションに配置された装置（遠隔装置）の間の通信を赤外線通信制御部２４、有線通信制御部２５、ＷｉＦｉ通信制御部２６又はＢＬＥ通信制御部２７を用いて制御する。通信制御部３４は、ＭＱＴＴ（Message Queue Telemetry Transport）、ＣｏＡＰ（Constrained Application Protocol）、ＲＥＳＴ（Representational State Transfer）、ＢＬＥサービスプロファイルなどから室内機６ｂと遠隔装置との間の通信に適した通信プロトコルを用いる。

保護制御部３５は、ハードウェア９の保護に関する制御を行う。例えば、保護制御部３５は、室内ファン６ｉの回転数が大きくなりすぎないように制御する。

制御層３０は、機能層４０に含まれる機能を実現する手段を提供する。例えば、風量制御部３１及び風向制御部３２は、それぞれ風量及び風向を制御することで気流調整を実現する。

機能層４０に含まれる機能部は、空気調和システム１が利用者に提供する機能を実現する処理を行う。機能層４０に含まれる機能部は、利用者の要求（設定の変更）に基づいて、利用者の要求を実現する機能部がその機能を実現する処理を行う。機能層４０には、機能部として、例えば気流調整部４１と、室温調整部４２と、遠隔操作部４３と、快適気流部４４と、自動運転部４５と、空調＿加湿器連携部４６と、他機器連携部４７ａ、４７ｂ、４７ｃなどが含まれる。

気流調整部４１は、利用者の設定に基づいて、室内機６ｂの風量及び室内機６ｂの風向をそれぞれ風量制御部３１及び風向制御部３２を用いて調整する。室温調整部４２は、設定温度と室温の温度差分、室温の時間変化に基づいて、室外機６ａが備える圧縮機６ｄへ要求する能力を圧縮機制御部３３を用いて調整する。遠隔操作部４３は、赤外線リモコン、ＢＬＥリモコン、遠隔端末４などを用いて利用者が遠隔操作により設定した要求を、対応する機能部に伝える。

快適気流部４４は、床温度などを検出し、室内の温度ムラをなくすよう自動的に室内機６ｂの風量を風量制御部３１を用いて調節する。自動運転部４５は、室内温度、外気温度に基づいて自動的に運転モード（冷房、ドライ、送風、暖房）を選択し、選択した運転モードに従った運転を行う。空調＿加湿器連携部４６は、空調機６の動作と加湿器７の動作を連携させる。他機器連携部４７ａ、４７ｂ、４７ｃ、・・・は、空調機６の動作と他機器８の動作を連携させる。他機器８としては例えば図示しないカーテンや照明機器などがある。例えば他機器連携部４７ａ、４７ｂ、４７ｃ、・・・からの制御信号が空調機ＡＰＩ処理部を通じて他機器８に送られることで、空調機６と他機器８との連携が行われる。他機器連携部を設けることで、空調機側に他機器の制御に必要なセンサー（例えば明度センサーなど）が搭載されていなくても、他機器との連携が可能になる。

機能層４０に含まれる機能部は、室内機６ｂに配置されてもよいし、ＧＷ２、遠隔端末４、クラウド５、リモコン６ｃなどの遠隔装置に配置されてもよい。また、機能層４０に含まれる機能部は、ＣＰＵ２ｂ，４ｂ，５ｂ，６１ｂ，６２ｂ，６３ｂで、機能毎に個別に作成された機能実行プログラムが実行されることで実現される。

機能層４０には、空調機データ部５１と、空調機ＡＰＩ（Application Programming Interface）処理部５２と、空調機機能間連携部５３とが含まれる。空調機データ部５１、空調機ＡＰＩ処理部５２及び空調機機能間連携部５３は、室内機６ｂ、ＧＷ２、遠隔端末４、クラウド５など、機能部が配置される場所に配置される。

空調機データ部５１は、異なる装置に配置された機能部間で共有されるデータを管理し、遠隔配置された装置の一方側でデータが更新された場合に更新内容を他方側でも更新する（データを同期する）ことでデータの一貫性を保持する。空調機データ部５１は、ＧＷ２、遠隔端末４、クラウド５、リモコン６ｃなどの物理メモリにそれぞれ分散されて記憶されているデータを同期させて、空調機システム全体としてのデータの一貫性を保持する。空調機データ部５１により管理されるデータは、各機能部間での競合制御、調停に使用される。このように、空調機システムは、システム全体として統合されたメモリ（統合メモリ５０）を仮想的に持つことができる。

つまり、統合メモリ５０は、ＧＷ２、遠隔端末４、クラウド５、リモコン６ｃなどの物理メモリを仮想的に統合した概念としてのメモリである。

空調機ＡＰＩ処理部５２は、機能部が物理的にクラウド５、ＧＷ２、遠隔端末４、リモコン６ｃなどのいずれに配置されている場合にも、共通のＡＰＩを機能部に提供することで、配置場所によらずに同じ機能部を利用（機能部を共通化）することが可能になる。空調機ＡＰＩ処理部５２は、通信の切換と機能層４０から制御層３０への指示を空調機データ部５１を経由して行う。空調機ＡＰＩ処理部５２は、複数の装置内に配置された機能部や制御層の各部品の配置を把握しており、制御信号や応答信号が適切に通信されるように制御する。

空調機機能間連携部５３は、遠隔配置された機能部間の連携制御を行う。例えば、空調機機能間連携部５３は、遠隔配置された機能部による設定（例えば気流調整部の気流調整機能を機能させるか否か）などを変更する動作を行う。

次に、空気調和システム１の処理のシーケンスについて、気流調整を例として図３〜図６を用いて説明する。なお、図３〜図６において、室内機６ｂでは、空調機データ部５１ａ、空調機ＡＰＩ処理部５２ａ、空調機機能間連携部５３ａ、遠隔操作部４３ａ、通信制御部３４ａ、ＷｉＦｉ通信制御部２６ａ、ＷｉＦｉモジュールドライバ１６ａ、赤外線通信制御部２４ａ、赤外線通信モジュールドライバ１４ａが動作する。クラウド５では、空調機データ部５１ｂ、空調機ＡＰＩ処理部５２ｂ、空調機機能間連携部５３ｂが動作する。また、実メモリ５０ａは、仮想的なメモリである統合メモリ５０のうち室内機６ｂに配置された物理メモリであり、実メモリ５０ｂは、仮想的なメモリである統合メモリ５０のうちクラウド５に配置された物理メモリである。

まず、気流調整部４１ｂがクラウド５に配置され、利用者が遠隔端末４から風量又は風向を変更する場合について説明する。図３は、気流調整部４１ｂがクラウド５に配置され、利用者が遠隔端末４から風量又は風向を変更する場合の空気調和システム１による処理のシーケンスを示す図である。図３に示すように、クラウド５に配置された気流調整部４１ｂは、風量変更指示を遠隔端末４から受信する（Ｓ１）。ここで、まず風量を変更する場合について説明すると、気流調整部４１ｂは、自身の配置場所に関わらず風量や風向の設定変更を要求する制御信号を出力する。具体的には、気流調整部４１ｂは空調機ＡＰＩ処理部５２ｂに対して風量変更制御信号を出力する。空調機ＡＰＩ処理部５２ｂは、制御層の部品である風量制御部３１や風向制御部３２が本体装置にあることを把握しているため、風量変更制御信号を本体装置との通信用データ（ＷｉＦｉ信号）に変換し、インターネット経由で本体装置に送信する（Ｓ２）。ここで、本体装置は、空調機６である。

なお、空調機ＡＰＩ処理部５２ｂは、空調機データ部５１ｂを介して通信用データを本体装置に送信し、空調機データ部５１ｂは、風量の設定を変更して実メモリ５０ｂに格納する。空調機データ部５１ｂは、室内機６ｂの空調機データ部５１ａと同期して統合メモリ５０の一貫性を保持する。従って、空調機データ部５１ａは、室内機６ｂの実メモリ５０ａから変更された風量の設定を取得できる。

本体装置のドライバ層１０のＷｉＦｉモジュールドライバ１６ａは、クラウド５からインターネット経由で送信されたデータを受信し、ハードウェア抽象化層２０のＷｉＦｉ通信制御部２６ａに出力する。ＷｉＦｉ通信制御部２６ａは、ＷｉＦｉモジュールドライバ１６ａにより受信されたデータが正規の受信データであるか否かの確認を行い、正規の受信データであれば制御層３０の通信制御部３４ａに受信データを出力する。

通信制御部３４ａは、空調機ＡＰＩ処理部５２ｂから送信されたデータ（受信データ）を信号解析し、クラウド５側の気流調整部４１ｂからの風量変更制御信号であれば、その風量変更制御信号を本体側の空調機ＡＰＩ処理部５２ａに送る（Ｓ３）。

空調機ＡＰＩ処理部５２ａは、風量変更制御信号を受信すべき風量制御部３１の配置を把握しているため、風量制御部３１に向けて風量変更制御信号を出力することができる（Ｓ４）。空調機ＡＰＩ処理部５２ａはまた、空調機データ部５１ａに風量変更指示があったことを記憶させる。

風量制御部３１は、風量変更指示により変更後の目標ファン回転数を決定し、ハードウェア抽象化層２０のファン制御部２１に対しての制御信号として目標ファン回転数を出力する。ファン制御部２１は、風量制御部３１から風量変更指示の受け付けを完了した時点で、風量制御部３１に対して受け付けの応答信号を出力すると共に、現時点の実動作ファン回転数と変更後の目標ファン回転数との回転数差分からファンモータの制御量を算出し、ドライバ層１０のファンモータドライバ１１に対しての制御信号としてファンモータ制御量を出力する。ファンモータドライバ１１は、ファンモータ制御量に従ってファンモータドライブ回路に対して信号を出力しファンモータを制御する（Ｓ５）。

その後、ドライバ層１０のファンモータドライバ１１は、ハードウェア９のファンモータ回転数フィードバック回路より、応答信号としてファンモータ制御量変更後の実動作ファン回転数のフィードバック信号（パルス信号）を入力する（Ｓ６）。ファンモータドライバ１１は、このフィードバック信号入力の時間間隔（パルス信号の時間間隔）を応答信号としてハードウェア抽象化層２０のファン制御部２１に出力する。ファン制御部２１は、フィードバック信号入力の時間間隔（パルス信号の時間間隔）からファンモータの回転数を算出して、所定の回転数になるまで指令電圧値（ＰＷＭ信号のオン時間）を増加するように、ファンモータドライバ１１に指示する。なお、ファン制御部２１は、風量制御部３１から風量変更指示の受け付けを完了した時点で、風量制御部３１に対して受け付けの応答信号を出力し、受け付けの応答信号を受信した風量制御部３１は、機能層４０の空調機ＡＰＩ処理部５２ａに応答信号を出力する（Ｓ７）。

空調機ＡＰＩ処理部５２ａは、クラウド５に配置された機能層４０の気流調整部４１ｂから送信された制御信号に適した応答信号にデータ変換し、制御層３０の通信制御部３４ａに応答信号を出力する（Ｓ８）。

通信制御部３４ａは、クラウド５との通信を行うため、ＷｉＦｉ通信を選択しハードウェア抽象化層２０のＷｉＦｉ通信制御部２６ａに応答信号を出力する。ＷｉＦｉ通信制御部２６ａは、入力した応答信号をＵＡＲＴ（Universal Asynchronous Receiver/Transmitter）信号に変換しドライバ層１０のＷｉＦｉモジュールドライバ１６ａに出力する。ＷｉＦｉモジュールドライバ１６ａは、通信回路を通じて応答信号をクラウド５に送信する（Ｓ９）。

このように、ファンモータドライバ１１、ファン制御部２１、風量制御部３１及び空調機ＡＰＩ処理部５２ａは、前の層の応答信号を順次適した形式に変換して次の層に出力するので、空気調和システム１は、ハードウェア９からの応答信号をクラウド５に送信できる。なお、風量制御部３１は、気流調整部４１の配置に関わらず応答を行う。具体的には、風量制御部３１は、空調機ＡＰＩ処理部５２ａに応答し、空調機ＡＰＩ処理部５２ａは、クラウド５に対して。イベント型の応答の詳細については後述する。空調機ＡＰＩ処理部５２ａは、統合メモリ経由の非同期応答、ポーリングにより応答を行ってもよい。

クラウド５の機能層４０の空調機ＡＰＩ処理部５２ｂは、本体装置からインターネット経由で送信された信号を応答信号として入力し、入力した応答信号を変換して気流調整部４１ｂに出力する。以上で、風量変更処理が完了する。

次に、風向変更について説明する。図３に示すように、クラウド５に配置された気流調整部４１ｂは、風向変更指示を遠隔端末４から受信する（Ｓ１）。すると、気流調整部４１ｂは、自身の配置に関わらず、空調機ＡＰＩ処理部５２ｂに対して風向変更制御信号を出力する。空調機ＡＰＩ処理部５２ｂは、制御層の部品である風向制御部３２が本体装置にあることを把握しているため、風向変更制御信号を本体装置との通信用データ（ＷｉＦｉ信号）に変換し、インターネット経由で本体装置に送信する（Ｓ２）。

なお、空調機ＡＰＩ処理部５２ｂは、空調機データ部５１ｂを介して通信用データを本体装置に送信し、空調機データ部５１ｂは、風向の設定を変更して実メモリ５０ｂに格納する。空調機データ部５１ｂは、空調機データ部５１ａと同期して統合メモリ５０の一貫性を保持する。従って、空調機データ部５１ａは、室内機６ｂの実メモリ５０ａから変更された風向の設定を取得できる。

本体装置のドライバ層１０のＷｉＦｉモジュールドライバ１６ａは、クラウド５からインターネット経由で送信されたデータを受信し、ハードウェア抽象化層２０のＷｉＦｉ通信制御部２６ａに出力する。ＷｉＦｉ通信制御部２６ａは、ＷｉＦｉモジュールドライバ１６ａにより受信されたデータが正規の受信データであるか否かの確認を行い、正規の受信データであれば制御層３０の通信制御部３４ａに受信データを出力する。

通信制御部３４ａは、空調機ＡＰＩ処理部５２ｂから送信されたデータ（受信データ）を信号解析し、クラウド５側の気流調整部４１ｂからの風向変更制御信号であれば、その風向変更制御信号を本体側の空調機ＡＰＩ処理部５２ａに送る（Ｓ３）。

空調機ＡＰＩ処理部５２ａは、風向変更制御信号を受信すべき風向制御部３２の配置を把握しているため、風向制御部３２に向けて風向変更制御信号を出力することができる（Ｓ１０）。空調機ＡＰＩ処理部５２ａはまた、空調機データ部５１ａに風向変更指示があったことを記憶させる。

風向制御部３２は、風向変更指示により変更後の目標風向位置パルス数を決定し、ハードウェア抽象化層２０の風向板制御部２２に対しての制御信号として目標風向位置パルス数を出力する。風向板制御部２２は、風向制御部３２から風向変更指示の受け付けを完了した時点で、風向制御部３２に対して受け付けの応答信号を出力すると共に、現時点の実動作風向位置パルス数と変更後の目標風向位置パルス数からステッピングモータの駆動方向を決定し、ドライバ層１０のステッピングモータドライバ１２に対しての制御信号としてステッピングモータ制御量を出力する。ステッピングモータドライバ１２は、ステッピングモータ制御量に従ったタイミングでステッピングモータドライブ回路に対して信号を出力し、ステッピングモータを駆動することで風向位置を制御する（Ｓ１１）。

風向板を制御するステッピングモータに関しては、風向位置を検出するハードウェア回路がないため、ドライバ層１０のステッピングモータドライバ１２、及び、ハードウェア抽象化層２０の風向板制御部２２への下位層からの応答信号入力はない。風向板制御部２２は、制御層３０の風向制御部３２からの風向変更指示の受け付けを完了した時点で、風向制御部３２に対して受け付けの応答信号を出力する。風向制御部３２は、機能層４０の空調機ＡＰＩ処理部５２ａに応答信号を出力する（Ｓ１２）。

空調機ＡＰＩ処理部５２ａは、クラウド５に配置された機能層４０の気流調整部４１ｂから送信された制御信号に適した応答信号にデータ変換し、制御層３０の通信制御部３４ａに応答信号を出力する（Ｓ８）。

通信制御部３４ａは、クラウド５との通信を行うため、ＷｉＦｉ通信を選択しハードウェア抽象化層２０のＷｉＦｉ通信制御部２６ａに応答信号を出力する。ＷｉＦｉ通信制御部２６ａは、入力した応答信号をＵＡＲＴ信号に変換しドライバ層１０のＷｉＦｉモジュールドライバ１６ａに出力する。ＷｉＦｉモジュールドライバ１６ａは、通信回路を通じて応答信号をクラウド５に送信する（Ｓ９）。

クラウド５の機能層４０の空調機ＡＰＩ処理部５２ｂは、本体装置からインターネット経由で送信された信号を応答信号として入力し、入力した応答信号を変換して気流調整部４１ｂに出力する。以上で、風向変更処理が完了する。

次に、気流調整部４１ａが室内機６ｂに配置され、利用者が赤外線リモコンから風量又は風向の変更を行った場合について説明する。図４は、気流調整部４１ａが室内機６ｂに配置され、利用者が赤外線リモコンから風量又は風向を変更する場合の空気調和システム１による処理のシーケンスを示す図である。図４に示すように、室内機６ｂのドライバ層１０の赤外線通信モジュールドライバ１４ａは、赤外線リモコンから利用者の操作による風量変更の指示を受信する（Ｓ２１）。すると、赤外線通信モジュールドライバ１４ａは、受信信号を赤外線通信制御部２４ａに出力する。

赤外線通信制御部２４ａは、受信信号を解析し、受信信号が風量変更指示であることを特定し、制御層３０の通信制御部３４ａに風量変更指示を出力する。通信制御部３４ａは、他の通信手段からの指示入力との優先度などを判断し、問題がなければ、機能層４０の空調機ＡＰＩ処理部５２ａに風量変更指示を出力する。このとき空調機ＡＰＩ処理部５２ａは、機能部である遠隔操作部４３ａが本体側の機能層に配置されていることを把握しているため、風量変更指示を遠隔操作部４３ａに送信する（Ｓ２２）。遠隔操作部４３ａは、本体装置内の機能層４０の気流調整部４１ａに直接風量変更指示を出力する（Ｓ２３）。風量変更指示を受けた機能層４０の気流調整部４１ａは、自身の配置場所に関わらず、空調機ＡＰＩ処理部５２ａに風量変更制御信号を出力する。空調機ＡＰＩ処理部５２ａは、同一装置内の気流調整部４１ａからの制御信号であるため、通信データにデータ変換することなくそのまま、制御層３０の風量制御部３１に風量変更制御信号を出力する（Ｓ２４）。

風量制御部３１は、風量変更指示により変更後の目標ファン回転数を決定し、ハードウェア抽象化層２０のファン制御部２１に対しての制御信号として目標ファン回転数を出力する。ファン制御部２１は、現時点の実動作ファン回転数と変更後の目標ファン回転数との回転数差分からファンモータの制御量を算出し、ドライバ層１０のファンモータドライバ１１に対しての制御信号としてファンモータ制御量を出力する。ファンモータドライバ１１は、ファンモータ制御量に従ったタイミングでファンモータドライブ回路に対して信号を出力しファンモータを制御する（Ｓ２５）。

その後、ドライバ層１０のファンモータドライバ１１は、ハードウェア９のファンモータ回転数フィードバック回路より、応答信号としてファンモータ制御量変更後の実動作ファン回転数のフィードバック信号を入力する（Ｓ２６）。ファンモータドライバ１１は、このフィードバック信号入力の時間間隔を応答信号としてハードウェア抽象化層２０のファン制御部２１に出力する。ファン制御部２１は、制御層３０の風量制御部３１からの風量変更指示の受け付けを完了した時点で、風量制御部３１に対して受け付けの応答信号を出力する。風量制御部３１は、気流調整部４１の配置場所に関わらず、機能層４０の空調機ＡＰＩ処理部５２ａに応答信号を出力する（Ｓ２７）。

空調機ＡＰＩ処理部５２ａは、気流調整部４１ａが同一装置内にあるため、データ変換することなく、そのまま気流調整部４１ａに応答信号を出力する。以上で、風量変更処理が完了する。

図３及び図４に示したように、気流調整部４１は、クラウド５と室内機６ｂのいずれに配置されても、風量変更指示を受け取ると、自身の配置場所に関わらず、空調機ＡＰＩ処理部５２に風量変更制御信号を出力する。そして、空調機ＡＰＩ処理部５２は、クラウド５に配置されている場合には、気流調整部４１ｂが本体装置に配置されていることを把握しているため、風量変更制御信号を本体装置との通信用データに変換して本体装置に送信する。このため、気流調整部４１ｂは、室内機６ｂに配置された場合と同じ処理でクラウド５から室内機６ｂの風量を制御できる。従って、空気調和システム１は、気流調整部４１を室内機６ｂとクラウド５のいずれにも配置できる。

次に、風向変更について説明する。図４に示すように、室内機６ｂのドライバ層１０の赤外線通信モジュールドライバ１４ａは、赤外線リモコンから利用者の操作による風向変更の指示を受信する（Ｓ２１）。すると、赤外線通信モジュールドライバ１４ａは、受信信号を赤外線通信制御部２４ａに出力する。

赤外線通信制御部２４ａは、受信信号を解析し、受信信号が風向変更指示であることを特定し、制御層３０の通信制御部３４ａに風向変更指示を出力する。通信制御部３４ａは、他の通信手段からの指示入力との優先度などを判断し、問題がなければ、機能層４０の遠隔操作部４３ａに風向変更指示を出力する。このとき空調機ＡＰＩ処理部５２ａは、機能部である遠隔操作部４３ａが本体側の機能層に配置されていることを把握しているため、風向変更指示を遠隔操作部４３ａに送信する（Ｓ２２）。遠隔操作部４３ａは、本体装置内の機能層４０の気流調整部４１ａに直接風向変更指示を出力する（Ｓ２３）。風向変更指示を受けた機能層４０の気流調整部４１ａは、自身の配置を意識することなく、空調機ＡＰＩ処理部５２ａに風向変更制御信号を出力する。空調機ＡＰＩ処理部５２ａは、同一装置内の気流調整部４１ａからの制御信号であるため、通信データにデータ変換することなくそのまま、制御層３０の風向制御部３２に風向変更制御信号を出力する（Ｓ２８）。

風向制御部３２は、風向変更指示により変更後の目標風向位置と目標風向位置パルス数を決定し、ハードウェア抽象化層２０の風向板制御部２２に対しての制御信号として目標位置パルス数を出力する。風向板制御部２２は、現時点の実動作風向位置パルス数と変更後の目標位置パルス数からステッピングモータの駆動方向を決定する。そして、風向制御部３２は、ドライバ層１０のステッピングモータドライバ１２に対しての制御信号としてステッピングモータ駆動信号を目標風向位置パルス数に到達するまで出力する。ステッピングモータドライバ１２は、ステッピングモータ駆動信号に対して信号を出力し、ステッピングモータを駆動することで風向位置を制御する（Ｓ２９）。

風向板を制御するステッピングモータに関しては、風向位置を検出するハードウェア回路がないため、ドライバ層１０のステッピングモータドライバ１２、及び、ハードウェア抽象化層２０の風向板制御部２２への下位層からの応答信号入力はない。風向板制御部２２は、制御層３０の風向制御部３２からの風量変更指示の受け付けを完了した時点で、風向制御部３２に対して受け付けの応答信号を出力する。同様に、風向制御部３２は、機能層４０の空調機ＡＰＩ処理部５２ａからの風向変更指示の受け付けを完了した時点で、気流調整部４１の配置場所に関わらず、空調機ＡＰＩ処理部５２ａに応答信号を出力する（Ｓ３０）。

空調機ＡＰＩ処理部５２ａは、気流調整部４１ａが同一装置内にあるため、データ変換することなく、そのまま気流調整部４１ａに応答信号を出力する。以上で、風向変更処理が完了する。

次に、気流調整部４１ｂがクラウド５に配置され、利用者が赤外線リモコンから風量又は風向を変更する場合について説明する。図５は、気流調整部４１ｂがクラウド５に配置される点で図３と同じであるが、利用者が赤外線リモコンから風量又は風向を変更する点で相違する。図５は、機能層４０における処理を中心に、空気調和システム１による処理のシーケンスを示す図である。

図５に示すように、利用者は、赤外線リモコンで風量と風向を変更する（１）。遠隔操作部４３ａは、変更指示を受け付け（２）、設定（風量＝ｘ、風向＝ｙ）の変更内容を室内機６ｂの実メモリ５０ａに格納する（３）。室内機６ｂの空調機データ部５１ａとクラウド５の空調機データ部５１ｂは、連携して室内機６ｂの実メモリ５０ａとクラウド５の実メモリ５０ｂの間で内容を同期する（４）。室内機６ｂの空調機データ部５１ａとクラウド５の空調機データ部５１ｂは、実メモリ５０ａの内容を実メモリ５０ｂにコピーすることで、実メモリ５０ａと実メモリ５０ｂの間で内容を同期する。クラウド５の気流調整部４１ｂは、設定が変更されると、実メモリ５０ｂにおける設定の変更内容を参照し（５）、関数コールを用いて、空調機ＡＰＩ処理部５２ｂに風量と風向の設定変更を要求する（６）。空調機ＡＰＩ処理部５２ｂは、設定変更要求を通信データに変換して室内機６ｂに送信する（７）。

室内機６ｂの空調機ＡＰＩ処理部５２ｂは、設定変更要求を受信し、風量の設定変更要求と風向の設定変更要求（関数コール）に変換する（８）。そして、風量の設定変更要求と風向の設定変更要求に基づいて、風量と風向が変更される（９）。

図６は、気流調整部４１ａが室内機６ｂに配置される場合を示す。図６に示すように、利用者は、赤外線リモコンで風量と風向を変更する（１１）。遠隔操作部４３ａは、変更指示を受け付け（１２）、設定（風量＝ｘ、風向＝ｙ）の変更内容を室内機６ｂの実メモリ５０ａに格納する（１３）。

室内機６ｂの気流調整部４１ａは、設定が変更されると、実メモリ５０ａにおける設定の変更内容を参照し（１４）、関数コールを用いて、空調機ＡＰＩ処理部５２ａに風量と風向の設定変更を要求する（１５）。空調機ＡＰＩ処理部５２ａは、風量の設定変更を風量制御部３１に要求し、風向の設定変更を風向制御部３２に要求する。そして、風量と風向が変更される（１６）。

図５及び図６に示したように、気流調整部４１は、クラウド５と室内機６ｂのいずれに配置されても、統合メモリ５０における設定が変更されると、空調機ＡＰＩ処理部５２に風量と風向の設定変更を要求する。そして、空調機ＡＰＩ処理部５２は、クラウド５に配置されていると、設定変更要求を通信データに変換して室内機６ｂに送信する。このため、気流調整部４１ｂは、室内機６ｂに配置された場合と同じ処理でクラウド５から室内機６ｂの風量と風向を制御できる。従って、空気調和システム１は、気流調整部４１を室内機６ｂとクラウド５のいずれにも配置できる。

次に、イベント（応答信号の受信）が起きたときに応答信号を処理するイベント型応答の詳細について説明する。図７は、クラウド５に気流調整部４１ｂが配置された場合（すなわち図３、図５に示した実施例の場合）に気流調整部４１ｂが風量変更指示及び風向変更指示に対するイベント型応答を空調機ＡＰＩ処理部５２ａから受信する場合を示す図である。なお、図７は、一例として、ＭＱＴＴプロトコルを採用し、ＭＱＴＴサーバーに応答信号がパブリッシュ（Publish）されたときにサブスクライブ（Subscribe）している端末に応答信号を送信するパブリッシュ（Publish）・サブスクライブ（Subscribe）・モデルを適用した場合を示す。

図７に示すように、気流調整部４１ｂは、空調機ＡＰＩ処理部５２ｂに、室内機側からの風量変更及び風向変更の応答を期待するCallback関数を登録する（２１）。すなわち、気流調整部４１ｂは、空調機ＡＰＩ処理部５２ｂに、風量Callback関数及び風向Callback関数をそれぞれ風量制御及び風向制御に関係付けて登録する。

空調機ＡＰＩ処理部５２ｂは、Callback関数をイベントと関係付けて保持する（２２）。すなわち、空調機ＡＰＩ処理部５２ｂは、｛風向Callback関数，風向制御イベント｝、｛風量Callback関数，風量制御イベント｝を保持する。また、空調機ＡＰＩ処理部５２ｂは、室内機側の風量制御イベントと風向制御イベントを、サブスクライブするメッセージとして、通信制御部３４ｂからＭＱＴＴサーバー５４に登録する。

室内機６ｂの制御部（風量制御部３１又は風向制御部３２）は、イベント（風量変更信号の受付応答又は風向変更信号の受付応答）が発生すると、空調機ＡＰＩ処理部５２ａにイベントを引き渡す（２３）。空調機ＡＰＩ処理部５２ａは、クラウド側にこのイベント情報を伝達するため、発生したイベントをパブリッシュする（２４）。すなわち、空調機ＡＰＩ処理部５２ａは、風量変更信号の受付応答がイベントとして発生すると、風量制御イベントをパブリッシュし、風向変更信号の受付応答がイベントとして発生すると、風向制御イベントをパブリッシュする。パブリッシュされたイベントは通信制御部３４ａからＭＱＴＴサーバー経由でメッセージとしてクラウド側に配信される。

クラウド５の空調機ＡＰＩ処理部５２ｂは、通信制御部３４ａからＭＱＴＴサーバー経由で配信されたイベントを受信し、受信したイベントに関連付けられたCallback関数を起動する（２５）。すなわち、空調機ＡＰＩ処理部５２ｂは、パブリッシュされたイベントが風量制御イベントであれば風量Callback関数を起動し、パブリッシュされたイベントが風向制御イベントであれば風向Callback関数を起動する。

このように、気流調整部４１ｂは、Callback関数を空調機ＡＰＩ処理部５２ｂに登録する。そして、空調機ＡＰＩ処理部５２ｂは、Callback関数をイベントと関係付けて保持し、イベントがパブリッシュされると、パブリッシュされたイベントに関連付けられたCallback関数を起動する。従って、気流調整部４１ｂは、指示に対する応答を受信できる。

以上説明したように、空気調和システム１は、室内機６ｂに空調機ＡＰＩ処理部５２ａを備え、遠隔装置の一例としてのクラウド５に空調機ＡＰＩ処理部５２ｂを備える。そして、クラウド５に配置された機能部は、空調機ＡＰＩ処理部５２ｂと空調機ＡＰＩ処理部５２ａを介して処理を行う。つまり、空調機ＡＰＩ処理部５２ａと空調機ＡＰＩ処理部５２ｂは、空気調和装置本体に対するアクセス（制御や情報収集など）を、様々なロケーション（空気調和装置やクラウドなど）から行えるプラットフォームとして機能する（プラットフォームＡＰＩ）。従って、空気調和システム１は、機能部を遠隔配置できる。

また、実施例では、機能層４０に含まれる機能部は、室内機６ｂ及び遠隔装置のいずれに配置された場合にも、同様の処理を行う。従って、空気調和システム１は、配置場所に依存しない共通の機能部の開発を可能とし、機能部の開発を容易にできる。例えば、機能部の処理として通信処理を設ける必要がなく、空調機ＡＰＩ処理部５２が必要な場合に通信制御部３４を介して通信を行う。従って、空気調和システム１は、配置場所に依存しない共通の機能部の開発を可能とし、機能部の開発を容易にできる。

また、実施例では、機能部がクラウド５に配置される場合、空調機ＡＰＩ処理部５２ｂは、機能部からの指示を通信に適した形式に変換して空調機ＡＰＩ処理部５２ａに送信する。そして、空調機ＡＰＩ処理部５２ａは、空調機ＡＰＩ処理部５２ｂから受け取った指示を制御層３０に適した形式に変換して制御層３０の部品に出力する。そして、制御層３０の部品は、空調機ＡＰＩ処理部５２ａから受け取った指示をハードウェア抽象化層２０に適した形式に変換してハードウェア抽象化層２０の部品に出力する。そして、ハードウェア抽象化層２０の部品は、制御層３０の部品から受け取った指示をドライバ層１０に適した形式に変換してドライバ層１０の部品に出力する。従って、空気調和システム１は、１つ下の層とのインタフェースだけに基づく機能部及び部品の開発を可能とし、機能部及び部品の開発を容易にできる。

また、実施例では、遠隔配置された機能部は、パブリッシュ・サブスクライブ・モデルに基づいて、室内機６ｂへの指示に対する応答を受信するので、室内機６ｂが指示を実行したことを確認できる。

また、実施例では、機能部は、配置場所に依存することなく仮想的な統合メモリ５０によって他の機能部とデータを共有でき、他の機能部とのデータの受け渡しを簡単に行える。また、実施例では、空調機データ部５１は、仮想的な統合メモリ５０によって機能部間でのデータの一貫性を保持する。従って、室内機６ｂのハードウェア９は、異なる場所に配置された同一機能部から矛盾する指示を受けることがなく、安定して動作できる。

１ 空気調和システム
２ ＧＷ
２ｂ，４ｂ，５ｂ，６１ｂ，６２ｂ，６３ｂ ＣＰＵ
４ 遠隔端末
５ クラウド
６ 空調機
６ａ 室外機
６ｂ 室内機
６ｃ リモコン
１０ ドライバ層
２０ ハードウェア抽象化層
３０ 制御層
４０ 機能層
５０ 統合メモリ
５１，５１ａ，５１ｂ 空調機データ部
５２，５２ａ，５２ｂ 空調機ＡＰＩ処理部
５３，５３ａ，５３ｂ 空調機機能間連携部

Claims (5)

1. 少なくとも圧縮機と、熱交換器と、送風ファンとを含むハードウェア群と、前記ハードウェア群を制御するソフトウェアとを備えた本体装置と、
   少なくとも演算処理部と該演算処理部を制御するソフトウェアを備え、前記本体装置とネットワークを介して接続される遠隔装置と、
   を備えた空気調和システムであって、
   前記本体装置のソフトウェアは、
   各ハードウェアを駆動するドライバ群を有するハードウェアアクセス層と、
   前記ハードウェア群を、前記ドライバ群を介して制御する制御層と、
   前記本体装置への命令を受け付けて前記制御層に指示を出力する本体装置側機能層と、を備え、
   前記遠隔装置のソフトウェアは、
   前記本体装置への命令を受け付けて前記本体装置側機能層を介して前記制御層に指示を出力する遠隔装置側機能層を備え、
   少なくとも前記本体装置側機能層と前記遠隔装置側機能層のいずれか一方に、前記本体装置が提供する機能を実行する機能実行プログラムが配置される
   ことを特徴とする空気調和システム。
2. 前記機能実行プログラムは、前記本体装置が利用者に提供する機能毎に個別に作成されたプログラムであることを特徴とする請求項１に記載の空気調和システム。
3. 前記機能実行プログラムが前記遠隔装置側機能層に配置される場合において、
   前記遠隔装置側機能層に入力された命令は、前記遠隔装置側機能層において前記ネットワークを介して前記本体装置側機能層に入力されるのに適した形式に変換され、前記遠隔装置側機能層から前記本体装置側機能層へ入力され、
   前記本体装置側機能層に入力された命令は、前記本体装置側機能層において前記制御層に適した形式に変換されて、前記本体装置側機能層から前記制御層へ入力され、
   前記制御層に入力された命令は、前記制御層において前記ハードウェアアクセス層に適した形式に変換されて、前記制御層から前記ハードウェアアクセス層へ入力され、
   前記ハードウェアアクセス層に入力された命令は、前記ハードウェアアクセス層においてハードウェアに適した形式に変換されて、前記ハードウェアアクセス層から前記ハードウェアに入力されることを特徴とする請求項１又は２に記載の空気調和システム。
4. 前記ハードウェアに入力された命令に対し、前記ハードウェアが返す応答信号は、前記ハードウェアアクセス層と前記制御層と前記本体装置側機能層と前記遠隔装置側機能層とで順次適した形式に変換されて各層に入力されることを特徴とする請求項３に記載の空気調和システム。
5. 前記本体装置が有する物理メモリと前記遠隔装置が有する物理メモリは一貫性が保持される仮想的な統合メモリとして統合され、
   前記機能実行プログラムは、他の機能実行プログラムと前記統合メモリを用いてデータの受け渡しを行うことを特徴とする請求項１〜４のいずれか１つに記載の空気調和システム。

Images