特許 7453594 通信方法、冷凍空調関連システム、及び通信ノード

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-03-12

(45)【発行日】2024-03-21

(54)【発明の名称】通信方法、冷凍空調関連システム、及び通信ノード

(51)【国際特許分類】

   H04L 12/28 20060101AFI20240313BHJP

【ＦＩ】

H04L12/28 400

【請求項の数】 12

(21)【出願番号】P 2023139888

(22)【出願日】2023-08-30

(65)【公開番号】P2024035190

(43)【公開日】2024-03-13

【審査請求日】2023-08-30

(31)【優先権主張番号】P 2022136957

(32)【優先日】2022-08-30

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000002853

【氏名又は名称】ダイキン工業株式会社

(74)【代理人】

【識別番号】100114557

【弁理士】

【氏名又は名称】河野 英仁

(74)【代理人】

【識別番号】100078868

【弁理士】

【氏名又は名称】河野 登夫

(72)【発明者】

【氏名】徳田 三恵春

(72)【発明者】

【氏名】村上 友樹

(72)【発明者】

【氏名】青戸 渉

【審査官】木村 雅也

(56)【参考文献】

【文献】特開２０１８－１４６１９４（ＪＰ，Ａ）

【文献】特開２０１９－２１６５３７（ＪＰ，Ａ）

【文献】特開２００８－０２００９２（ＪＰ，Ａ）

【文献】ＥＣＨＯＮＥＴ Ｌｉｔｅ Ｗｅｂ ＡＰＩ 初級編，シーテック ２０２１ ［ｏｎｌｉｎｅ］ ，日本，2021年10月22日，第5頁-第16頁

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ １２／２８

(57)【特許請求の範囲】

【請求項1】

冷凍空調関連ユニットに関する情報を複数の通信ノードの間で通信する通信方法であって、
第一の通信ノードは、第二の通信ノードへ情報を送信する場合に、
前記情報の属性を示すコード、又は前記属性に応じて指定する応答の要否を示すタイプを含むメッセージを生成し、
生成した前記メッセージを前記第二の通信ノードへ送信し、
前記第二の通信ノードは、受信した前記メッセージに含まれる前記コード又は前記タイプに基づいて、応答の要否を判断し、
前記メッセージの属性は、少なくとも第２属性を含み、
前記第２属性は、前記メッセージを生成したアプリケーションの種類とする
通信方法。

【請求項2】

前記複数の通信ノードは、室外機及び室内機を含み、
前記室外機は、前記室内機へ前記情報を送信する場合に、応答不要をタイプとして含むメッセージを生成し、生成したメッセージを前記室内機へ送信する
請求項１に記載の通信方法。

【請求項3】

前記複数の通信ノードは、室外機及び室内機を含み、
前記室内機は、前記室外機へ前記情報を送信する場合に、応答不要をタイプとして含むメッセージを生成し、生成したメッセージを前記室外機へ送信する
請求項１に記載の通信方法。

【請求項4】

前記複数の通信ノードは、集中制御装置を更に含み、
前記集中制御装置は、前記室外機へ集中制御に係る情報を送信する場合に、応答要をタイプとして含む前記メッセージを生成し、生成したメッセージを前記室外機へ送信する
請求項２又は請求項３に記載の通信方法。

【請求項5】

前記複数の通信ノードは、集中制御装置を更に含み、
前記集中制御装置は、前記室内機へ集中制御に係る情報を送信する場合に、応答要をタイプとして含む前記メッセージを生成し、生成したメッセージを前記室内機へ送信する
請求項２又は請求項３に記載の通信方法。

【請求項6】

前記複数の通信ノードは、集中制御装置を更に含み、
前記室内機は、前記集中制御装置へ集中制御に係る情報を送信する場合に、応答不要をタイプとして含む前記メッセージを生成し、生成したメッセージを前記集中制御装置へ送信する
請求項２又は請求項３に記載の通信方法。

【請求項7】

前記メッセージは、ＲＥＳＴ ＡＰＩ（REST : Representational State Transfer, API : Application Programing Interface）により規定される形式を有する
請求項１に記載の通信方法。

【請求項8】

前記メッセージの属性は、更に第１属性を含み、
前記第１属性は、データの取得要求、更新要求、及び通知を含む
請求項１に記載の通信方法。

【請求項9】

前記第二の通信ノードは、受信したメッセージに含まれる第１属性及び第２属性の少なくとも一方に基づいて、応答の要否を判断する
請求項８に記載の通信方法。

【請求項10】

冷凍空調関連ユニットに関する情報を複数の通信ノードの間で通信する冷凍空調関連システムであって、
第一の通信ノードは、
制御部と、
通信部と
を備え、
前記制御部は、第二の通信ノードへ情報を送信する場合に、前記情報の属性を示すコード、又は前記属性に応じて指定する応答の要否を示すタイプを含むメッセージを生成し、
前記通信部は、前記制御部が生成した前記メッセージを前記第二の通信ノードへ送信し、
前記第二の通信ノードは、受信した前記メッセージに含まれる前記コード又は前記タイプに基づいて、応答の要否を判断し、
前記メッセージの属性は、少なくとも第２属性を含み、
前記第２属性は、前記メッセージを生成したアプリケーションの種類とする
冷凍空調関連システム。

【請求項11】

冷凍空調関連システムにおける通信ノードであって、
制御部と、
通信部と
を備え、
前記制御部は、他の通信ノードへ情報を送信する場合に、前記情報の属性を示すコード、又は前記属性に応じて指定する応答の要否を示すタイプを含むメッセージを生成し、
前記通信部は、前記制御部が生成した前記メッセージを前記他の通信ノードへ送信し、
前記メッセージの属性は、少なくとも第２属性を含み、
前記第２属性は、前記メッセージを生成したアプリケーションの種類とする
通信ノード。

【請求項12】

冷凍空調関連システムにおける通信ノードであって、
制御部と、
通信部と
を備え、
前記通信部は、他の通信ノードから、情報の属性を示すコード、又は前記属性に応じて指定する応答の要否を示すタイプを含んだメッセージを受信し、
前記制御部は、受信した前記メッセージに含まれる前記コード又は前記タイプに基づいて、応答の要否を判断し、
前記メッセージの属性は、少なくとも第２属性を含み、
前記第２属性は、前記メッセージを生成したアプリケーションの種類とする
通信ノード。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信方法、冷凍空調関連システム、及び通信ノードに関する。

【背景技術】

【0002】

大規模な冷凍空調関連システムでは、例えば、１つの集中制御装置に複数の室外機を接続し、各室外機に複数の室内機を接続して、通信のためのネットワークを構築している（例えば、特許文献１を参照）。集中制御装置、室外機及び室内機を含む複数の機器の間で種々のデータが送受信され、各機器の集中制御や協調動作等が実現される。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２００８－２００９２号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

本開示の目的は、拡張性や保守性が高く、通信帯域の消費を抑えることができる通信方法、冷凍空調関連システム、及び通信ノードを提供することである。

【課題を解決するための手段】

【0005】

本開示の一側面に係る通信方法は、冷凍空調関連ユニットに関する情報を複数の通信ノードの間で通信する通信方法であって、第一の通信ノードは、第二の通信ノードへ情報を送信する場合に、前記情報の属性を示すコード、又は前記属性に応じて指定する応答の要否を示すタイプを含むメッセージを生成し、生成した前記メッセージを前記第二の通信ノードへ送信し、前記第二の通信ノードは、受信した前記メッセージに含まれる前記コード又は前記タイプに基づいて、応答の要否を判断する。

【0006】

本開示の一側面に係る通信方法は、前記複数の通信ノードは、室外機及び室内機を含み、前記室外機は、前記室内機へ前記情報を送信する場合に、応答不要をタイプとして含むメッセージを生成し、生成したメッセージを前記室内機へ送信する構成が好ましい。

【0007】

本開示の一側面に係る通信方法は、前記複数の通信ノードは、室外機及び室内機を含み、前記室内機は、前記室外機へ前記情報を送信する場合に、応答不要をタイプとして含むメッセージを生成し、生成したメッセージを前記室外機へ送信する構成が好ましい。

【0008】

本開示の一側面に係る通信方法は、前記複数の通信ノードは、集中制御装置を更に含み、前記集中制御装置は、前記室外機へ集中制御に係る情報を送信する場合に、応答要をタイプとして含む前記メッセージを生成し、生成したメッセージを前記室外機へ送信する構
成が好ましい。

【0009】

本開示の一側面に係る通信方法は、前記複数の通信ノードは、集中制御装置を更に含み、前記集中制御装置は、前記室内機へ集中制御に係る情報を送信する場合に、応答要をタイプとして含む前記メッセージを生成し、生成したメッセージを前記室内機へ送信する構成が好ましい。

【0010】

本開示の一側面に係る通信方法は、前記複数の通信ノードは、集中制御装置を更に含み、前記室内機は、前記集中制御装置へ集中制御に係る情報を送信する場合に、応答要をタイプとして含む前記メッセージを生成し、生成したメッセージを前記集中制御装置へ送信する構成が好ましい。

【0011】

本開示の一側面に係る通信方法は、前記メッセージは、ＲＥＳＴ ＡＰＩ（REST : Representational State Transfer, API : Application Programing Interface）により規定される形式を有する構成が好ましい。

【0012】

本開示の一側面に係る通信方法は、前記メッセージの属性は、少なくとも第１属性を含み、前記第１属性は、データの取得要求、更新要求、及び通知を含む構成が好ましい。

【0013】

本開示の一側面に係る通信方法は、前記メッセージの属性は、少なくとも第２属性を含み、前記第２属性は、前記メッセージを生成したアプリケーションの種類とする構成が好ましい。

【0014】

本開示の一側面に係る通信方法は、前記メッセージの属性は、少なくとも第１属性及び第２属性を含み、前記第１属性は、データの取得要求、更新要求、及び通知を含み、前記第２属性は、前記メッセージを生成したアプリケーションの種類とし、前記第二の通信ノードは、受信したメッセージに含まれる第１属性及び第２属性の少なくとも一方に基づいて、応答の要否を判断する構成が好ましい。

【0015】

本開示の一側面に係る冷凍空調関連システムは、冷凍空調関連ユニットに関する情報を複数の通信ノードの間で通信する冷凍空調関連システムであって、 第一の通信ノードは、 制御部と、通信部とを備え、前記制御部は、第二の通信ノードへ情報を送信する場合に、前記情報の属性を示すコード、又は前記属性に応じて指定する応答の要否を示すタイプを含むメッセージを生成し、前記通信部は、前記制御部が生成した前記メッセージを前記第二の通信ノードへ送信し、前記第二の通信ノードは、受信した前記メッセージに含まれる前記コード又は前記タイプに基づいて、応答の要否を判断する。

【0016】

本開示の一側面に係る通信ノードは、冷凍空調関連システムにおける通信ノードであって、 制御部と、通信部とを備え、前記制御部は、他の通信ノードへ情報を送信する場合に、前記情報の属性を示すコード、又は前記属性に応じて指定する応答の要否を示すタイプを含むメッセージを生成し、前記通信部は、前記制御部が生成した前記メッセージを前記他の通信ノードへ送信する。

【0017】

本開示の一側面に係る通信ノードは、冷凍空調関連システムにおける通信ノードであって、制御部と、通信部とを備え、前記通信部は、他の通信ノードから、情報の属性を示すコード、又は前記属性に応じて指定する応答の要否を示すタイプを含んだメッセージを受信し、前記制御部は、受信した前記メッセージに含まれる前記コード又は前記タイプに基づいて、応答の要否を判断する。

【発明の効果】

【0018】

本開示によれば、拡張性や保守性が高く、通信帯域の消費を抑えることができる。

【図面の簡単な説明】

【0019】

【図1】実施の形態に係る冷凍空調関連システムの構成例を示す模式図である。

【図2】室外機の構成例を説明するブロック図である。

【図3】室内機の構成例を説明するブロック図である。

【図4】集中制御装置の構成例を説明するブロック図である。

【図5】中継機器の構成例を示すブロック図である。

【図6】機器間で送受信するメッセージ（電文）のフォーマットを示す概念図である。

【図7】冷媒制御に関する通信における通信手順を説明するフローチャートである。

【図8】冷媒制御に関する通信における通信手順を説明するフローチャートである。

【図9】集中制御に関する通信における通信手順を説明するフローチャートである。

【図10】集中制御に関する通信における通信手順を説明するフローチャートである。

【図11】室内機がメッセージを受信した際に実行する処理の手順を説明するフローチャートである。

【図12】実施の形態３における冷媒制御での通信手順を説明するフローチャートである。

【図13】実施の形態３における集中制御での通信手順を説明するフローチャートである。

【図14】実施の形態３における集中制御での通信手順を説明するフローチャートである。

【図15】送信タイミングの設定例を説明する説明図である。

【図16】実施の形態４における通信手順を説明するタイミングチャートである。

【発明を実施するための形態】

【0020】

以下、実施の形態に係る冷凍空調関連システムを図面に基づいて具体的に説明する。なお、本技術はこれらの例示に限定されるものではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

【0021】

（実施の形態１）
図１は実施の形態に係る冷凍空調関連システムの構成例を示す模式図である。実施の形態に係る冷凍空調関連システム１は、冷凍空調関連ユニットに関する情報を複数の通信ノードの間で通信するためのシステムである。冷凍空調関連システム１を構成する通信ノードは、集中制御装置１０、室外機３０、室内機５０、中継機器７０等の冷凍空調関連機器を含む。通信ノード間で送受信する情報は、冷凍空調関連ユニットに関する情報であり、冷媒制御に関する情報や集中監視操作に関する情報などを含む。ここで、冷凍空調関連ユニットに関する情報とは、機器自体の情報であってもよく、冷凍空調関連機器を構成する一部の要素に関する情報であってもよい。

【0022】

通信ノードは、上記のものに限らず、サービスチェッカー、リモコン（リモートコントローラ）、換気装置、通信装置、制御装置などの種々の冷凍空調関連機器を含んでもよい。以下の説明において、通信ノードとして冷凍空調関連システム１に接続される冷凍空調関連機器を単に機器とも記載する。

【0023】

図１に示す冷凍空調関連システム１では、１つの集中制御装置１０と複数の室外機３０とが伝送線を介して接続されている。本実施の形態では、複数の機器がデイジーチェイン方式にて接続される。すなわち、集中制御装置１０には第１の室外機３０が第１の伝送線を介して接続され、第１の室外機３０には第２の室外機３０が第２の伝送線を介して接続され、第２の室外機３０には第３の室外機３０が第３の伝送線を介して接続される。ここで、集中制御装置１０と複数の室外機３０とを接続している複数の伝送線は電気的に導通している。このため、例えば集中制御装置１０が送信した信号はデイジーチェイン方式で接続された全ての室外機３０にて受信することが可能であり、いずれか１つの室外機３０が送信した信号は集中制御装置１０及び他の全ての室外機３０にて受信可能である。

【0024】

また、冷凍空調関連システム１では、各室外機３０に対して複数の室内機５０が伝送線を介してデイジーチェイン方式で接続されている。すなわち、１つの室外機３０には、第１の室内機５０が第１の伝送線を介して接続され、第１の室内機５０には第２の室内機５０が第２の伝送線を介して接続される。室外機３０と複数台の室内機５０とを接続している複数の伝送線は電気的に導通しており、いずれかの機器が送信した信号はデイジーチェイン方式で接続された全ての機器にて受信可能である。

【0025】

各室外機３０には、集中制御装置１０及び他の室外機３０との通信を行うための伝送線と、室内機５０との通信を行うための伝送線とが接続される。本実施の形態において、この２つの伝送線は室外機３０の内部において電気的に導通している。このため、例えば集中制御装置１０は、室外機３０を経て室内機５０と通信を行うことができる。また、第１の室外機３０に接続された室内機５０は、第１の室外機３０及び第２の室外機３０を経て、第２の室外機３０に接続された他の室内機５０と通信を行うことができる。なお、集中制御装置１０及び他の室外機３０との通信を行うための伝送線と、室内機５０との通信を行うための伝送線とは、室外機３０内で電気的に遮断されていてもよい。

【0026】

また、冷凍空調関連システム１には中継機器７０が含まれてもよい。例えば、伝送線を介して直接的に接続されるべき２つの機器間の距離が長く、伝送線の長さが所定長を超える場合、これら機器間に中継機器７０が設けられる。図１に例示した冷凍空調関連システム１には、２つの室内機５０，５０の間に接続された中継機器７０が２つ設けられている。すなわち、第１の室内機５０に対して中継機器７０が第１の伝送線を介して接続され、この中継機器７０に対して第２の室内機５０が第２の伝送線を介して接続されている。

【0027】

中継機器７０は、冷凍空調関連システム１のいずれの箇所に設けられてもよい。例えば、集中制御装置１０と室外機３０との間、２つの室外機３０，３０の間、室外機３０と室内機５０との間に中継機器７０が設けられてもよい。また、集中制御装置１０、室外機３０、室内機５０以外の各種機器の間に中継機器７０が設けられてもよい。なお、中継機器７０は必須ではなく、冷凍空調関連システム１は、中継機器７０を含まずに構築されてもよい。

【0028】

図２は室外機３０の構成例を説明するブロック図である。室外機３０は、例えば、制御部３１、記憶部３２、通信部３３、及び接続端子３４～３６を備える。制御部３１は、例えば、マイコンやＣＰＵ（Central Processing Unit）などの演算処理装置により構成される。制御部３１は、記憶部３２に記憶されたプログラムを読み出して実行することにより、種々の処理を行う。制御部３１は、室外機３０の各部の動作の制御、並びに、集中制御装置１０、他の室外機３０、及び室内機５０等との通信の制御等の種々の制御処理を行う。制御部３１は、時刻情報を出力するクロックや経過時間を計時するためのタイマ等を内蔵する。

【0029】

記憶部３２は、例えば、フラッシュメモリやＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）などの不揮発性メモリ、及び、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）などの揮発性メモリを備える。記憶部３２は、制御部３１が実行する各種のプログラム、及び、制御部３１の制御処理に必要な各種のデータを記憶する。各種のプログラムは不揮発性メモリに記憶される。一方、各種のデータは、揮発性メモリのみに記憶されてもよく、揮発性メモリに記憶させた後に不揮発性メモリにコピーして記憶させてもよい。

【0030】

通信部３３は、例えばトランシーバＩＣ（Integrated Circuit）により構成される。通信部３３は、室外機３０が備える複数の接続端子３４～３６に接続された伝送線を介して、集中制御装置１０、他の室外機３０、及び室内機５０との間で通信を行う。通信部３３は、例えば、ＯＦＤＭ（Orthogonal Frequency Division Multiplexing、直交周波数分割多重）方式により送受信するデータの変調を行う。具体的には、通信部３３は、２～２８ＭＨｚの周波数帯域を利用して、マルチキャリアによる伝送を行う。通信部３３は、制御部３１から与えられた送信データを変調した信号を伝送線に対して出力することでデータを送信すると共に、伝送線上の信号を取得して復調することで得られるデータを受信データとして制御部３１へ与える。

【0031】

通信部３３はマルチホップ機能を有していてもよい。マルチホップ機能とは、第一の機器より送信された信号を第二の機器が受信した場合、受信した信号と同じ信号を第二の機器が伝送線に対して出力する機能である。受信した信号と同じ信号を各機器が出力することにより、信号の減衰を抑え、信号の伝送距離を延ばすことができる。

【0032】

３つの接続端子３４～３６は、コネクタ又はソケットなどの電子部品を用いて構成され、通信のための伝送線が着脱可能に接続される。本実施の形態に係る室外機３０では、３つの接続端子３４～３６は、例えば回路基板上の配線パターンを介して電気的に導通していると共に、通信部３３に電気的に接続されている。このため、いずれかの接続端子３４～３６から入力された信号は、他の接続端子３４～３６から出力されると共に、通信部３３へ入力される。また通信部３３が出力した信号は、接続端子３４～３６から出力される。なお本実施の形態において３つの接続端子３４～３６は、配線パターン等を介して直接的に導通しているが、例えば接続端子３４～３６の間にフィルタ回路等が設けられてもよい。室外機３０が備える接続端子の数は２つ以下又は４つ以上であってもよい。

【0033】

図３は室内機５０の構成例を説明するブロック図である。室内機５０は、制御部５１、記憶部５２、通信部５３、及び２つの接続端子５４，５５を備える。制御部５１は、マイコンやＣＰＵなどの演算処理装置により構成される。制御部５１は、室内機５０の各部の動作の制御、並びに、集中制御装置１０、室外機３０及び他の室内機５０等との通信の制御等の種々の制御処理を行う。制御部５１は、時刻情報を出力するクロックや経過時間を計時するためのタイマ等を内蔵する。

【0034】

記憶部５２は、例えば、フラッシュメモリやＥＥＰＲＯＭなどの不揮発性メモリ、及び、ＤＲＡＭやＳＲＡＭなどの揮発性メモリを備える。記憶部５２は、制御部５１が実行する各種のプログラム、及び、制御部５１の制御処理に必要な各種のデータを記憶する。各種のプログラムは不揮発性メモリに記憶される。一方、各種のデータは、揮発性メモリのみに記憶されてもよく、揮発性メモリに記憶させた後に不揮発性メモリにコピーして記憶させてもよい。

【0035】

通信部５３は、例えばトランシーバＩＣにより構成される。通信部５３は、室外機３０の通信部３３と同様の機能を有しており、室外機３０の通信部３３に用いられるＩＣと同じ又は同種のＩＣが用いられ得る。通信部５３は、ＯＦＤＭ方式による変調機能、及び、マルチホップ機能を備えており、室内機５０が備える接続端子５４，５５に接続された伝送線を介して、集中制御装置１０、室外機３０及び他の室内機５０等との間で通信を行う。通信部５３は、制御部５１から与えられた送信データを変調した信号を伝送線に対して出力することでデータを送信すると共に、伝送線上の信号を取得して復調することで得られるデータを受信データとして制御部５１へ与える。

【0036】

２つの接続端子５４，５５は、コネクタ又はソケットなどの電子部品を用いて構成され、通信のための伝送線が着脱可能に接続される。接続端子５４，５５は、例えば回路基板上の配線パターンを介して電気的に導通していると共に、通信部５３に電気的に接続されている。室内機５０が備える接続端子の数は１つ又は３つ以上であってもよい。

【0037】

図４は集中制御装置１０の構成例を説明するブロック図である。集中制御装置１０は、例えば、制御部１１、記憶部１２、通信部１３、表示部１４、操作部１５、及び接続端子１６を備える。制御部１１は、ＣＰＵなどの演算処理装置により構成される。制御部１１は、集中制御装置１０の各部の動作の制御、並びに、室外機３０及び室内機５０等との通信の制御等の種々の制御処理を行う。制御部１１は、時刻情報を出力するクロックや経過時間を計時するためのタイマ等を内蔵する。

【0038】

記憶部１２は、フラッシュメモリやＥＥＰＲＯＭなどの不揮発性メモリ（若しくは、ハードディスク等の磁気記憶装置）、及び、ＤＲＡＭやＳＲＡＭなどの揮発性メモリを備える。記憶部１２は、制御部１１が実行する各種のプログラム、及び、制御部１１の制御処理に必要な各種のデータを記憶する。各種のプログラムは不揮発性メモリに記憶される。一方、各種のデータは、揮発性メモリのみに記憶されてもよく、揮発性メモリに記憶させた後に不揮発性メモリにコピーして記憶させてもよい。

【0039】

通信部１３は、例えばトランシーバＩＣにより構成される。通信部１３は、室外機３０の通信部３３及び室内機５０の通信部５３と同様の機能を有しており、室外機３０の通信部３３及び室内機５０の通信部５３に用いられるＩＣと同じ又は同種のＩＣが用いられ得る。通信部１３は、ＯＦＤＭ方式による変調機能、及び、マルチホップ機能を備えており、集中制御装置１０が備える接続端子１６に接続された伝送線を介して、室外機３０及び室内機５０等との間で通信を行う。通信部１３は、制御部１１から与えられた送信データを変調した信号を伝送線に対して出力することでデータを送信すると共に、伝送線上の信号を取得して復調することで得られるデータを受信データとして制御部１１へ与える。

【0040】

表示部１４は、液晶ディスプレイ等により構成されており、制御部１１の制御に応じて種々の画像及び文字等を表示する。操作部１５は、ユーザの操作を受け付け、受け付けた操作を制御部１１へ通知する。例えば操作部１５は、機械式のボタン又は表示部１４の表面に設けられたタッチパネル等の入力デバイスによりユーザの操作を受け付ける。また例えば操作部１５は、マウス及びキーボード等の入力デバイスであってよく、これらの入力デバイスは集中制御装置１０に対して取り外すことが可能な構成であってもよい。接続端子１６は、例えばコネクタ又はソケット等の電子部品を用いて構成され、通信のための伝送線が着脱可能に接続される。接続端子１６は、例えば回路基板上の配線パターンを介して通信部１３に電気的に接続されている。集中制御装置１０が備える接続端子の数は２つ以上であってもよい。

【0041】

図５は中継機器７０の構成例を示すブロック図である。本実施の形態に係る中継機器７０は、通信部７１及び２つの接続端子７２，７３等を備えて構成されている。通信部７１は、例えばトランシーバＩＣ等を用いて構成されている。通信部７１は、室外機３０の通信部３３、室内機５０の通信部５３、及び集中制御装置１０の通信部１３と同様の機能を有しており、これらに用いられるＩＣと同じ又は同種のＩＣが用いられ得る。通信部７１は、ＯＦＤＭ方式による変調機能、及び、マルチホップ機能を備えており、中継機器７０が備える接続端子７２，７３に接続された伝送線を介して、集中制御装置１０、室外機３０、及び室内機５０等との間で通信を行う。なお、中継機器７０の通信部７１は、少なくともマルチホップ機能を備えていればよく、ＯＦＤＭ方式による変調機能を備えていなくてもよい。

【0042】

２つの接続端子７２，７３は、例えばコネクタ又はソケット等の電子部品を用いて構成され、通信のための伝送線が着脱可能に接続される。接続端子７２，７３は、例えば回路基板上の配線パターンを介して電気的に導通していると共に、通信部７１に電気的に接続されている。中継機器７０が備える接続端子の数は１つ又は３つ以上であってもよい。

【0043】

冷凍空調関連システム１は、集中制御装置１０、室外機３０、室内機５０、及び中継機器７０等の複数の機器が伝送線を介してデイジーチェイン方式で接続され、ＯＦＤＭ変調方式によるマルチキャリアの通信を行う。複数の機器を接続する複数の伝送線は電気的に導通しており、一の機器が送信した信号は、他の全ての機器にて受信可能である。各機器が受信した信号と同じ信号を伝送線に対して出力するマルチホップ機能を備える場合、送信元からの伝送距離に応じて減衰する信号の強度を高めることで、信号の伝送距離を伸ばすことが可能である。

【0044】

ＯＦＤＭ変調及びマルチホップ機能を用いることができる通信方式として、例えばＨＤ－ＰＬＣ（High Definition Power Line Communication）の通信方式がある。各機器の通信部は、例えばＨＤ－ＰＬＣの通信方式を採用したトランシーバＩＣにより構成されてもよい。なお、ＨＤ－ＰＬＣの通信方式は電力線を介して通信を行うものであるが、実施の形態に係る冷凍空調関連システム１において各機器は電力線を介して通信を行うのではなく、電力線とは別に設けられた伝送線を介して通信を行う。

【0045】

図６は機器間で送受信するメッセージ（電文）のフォーマットを示す概念図である。実施の形態に係る冷凍空調関連システム１で使用する通信プロトコルは、以下の通りである。物理・データリンク層にはＨＤ－ＰＬＣ及びイーサネット（登録商標）が使用される。ネットワーク層にはＩＰｖ６が使用される。トランスポート層にはＵＤＰ（User Datagram Protocol）やＴＣＰ（Transmission Control Protocol）が使用される。アプリケーション層にはＨＴＴＰ（HyperText Transport Protocol）などを用いたＲＥＳＴ ＡＰＩが使用される。

【0046】

ＩＰｖ６は冷凍空調関連システム１に好適である。相互乗り入れ可能に接続された種々の機器を共通仕様のＩＰアドレスによって識別し、通信を行うことができる。

【0047】

ＵＤＰは冷凍空調関連システム１に好適である。室外機３０に多数の室内機５０が接続される場合であっても、ＴＣＰのようにコネクションを張らないため、室外機３０のメモリを圧迫しない。

【0048】

ＲＥＳＴ ＡＰＩは冷凍空調関連システム１に好適である。リクエストとレスポンスとの対応がとれ、リクエストに失敗した場合にデータの再送を行うことができる。また、後述のメソッドを指定することにより、機器間で制御、運転状態等に係るデータの取得及び更新を行うことができる。

【0049】

実施の形態では、一の機器（第一の通信ノード）から他の機器（第二の通信ノード）に情報を送信する場合、送信元である第一の通信ノードは、情報の属性を示すコードと、属性に応じて指定する応答の要否を示すタイプとを含んだメッセージを生成し、生成したメッセージを宛先である第二の通信ノードへ送信する。

【0050】

情報の属性を示すコードは、データに対する操作を表しており、メソッドとも呼ばれる。実施の形態では、相手のデータを取得する操作を表す「ＧＥＴ」、相手のデータを更新する操作を表す「ＳＥＴ」、自身のデータを通知する操作を表す「ＩＮＦ」等をメソッドとして用いることができる。データを取得するためには応答が必要であるため、「ＧＥＴ」というメソッドに対しては、応答要をタイプとして指定する。一方、値を更新する操作や情報を通知する操作には応答は不要であるため、「ＳＥＴ」や「ＩＮＦ」というメソッドに対しては、応答不要をタイプとして指定する。なお、メソッドは、上記のものに限定されず、相手のデータを削除する操作を表す「ＤＥＬＥＴＥ」等が含まれてもよい。

【0051】

上述したメソッドや応答の要否は、アプリケーション層ヘッダに記述することが可能である。「ＧＥＴ」，「ＳＥＴ」，「ＩＮＦ」の各メソッドは、例えばＨＴＴＰの定義である「ＧＥＴ」，「ＰＯＳＴ」，「ＰＵＴ」をそれぞれ流用すればよく、ＨＴＴＰヘッダにおいて指定することが可能である。

【0052】

また、応答の要否には、ＨＴＴＰのクエリを用いることができる。すなわち、応答が必要な場合には「ｒｅｓ＝ｔｒｕｅ」を、応答が不要な場合には、「ｒｅｓ＝ｆａｌｓｅ」をＨＴＴＰのクエリにおいて指定すればよい。

【0053】

以下、冷凍空調関連システム１における適用例について説明する。
冷凍空調関連システム１における通信は、大別して、冷媒制御に関する通信と、集中制御に関する通信とを含む。冷媒制御に関する通信は、主に冷媒配管で繋がった室外機３０と室内機５０との間の通信であり、適切に機器を制御して空気調和を行うための通信である。一方、集中制御に関する通信は、室外機３０や室内機５０を集中制御装置１０から集中監視・操作するための通信である。

【0054】

図７及び図８は冷媒制御に関する通信における通信手順を説明するフローチャートである。冷媒制御に関する通信では、冷媒系統内で１台の室外機３０が親となり、複数の室内機５０（子）や他の室外機３０（親）と通信を行う。図７のフローチャートでは、簡略化のために、親となる１台の室外機３０と子となる１台の室内機５０との間の通信手順について説明する。室外機３０及び室内機５０は、それぞれ通信相手のデータを内部に保持しておき、通信によってそのデータを更新する。室外機３０及び室内機５０は、内部に保持されたデータを参照して、自機の動作を決定する。

【0055】

室外機３０の制御部３１は、室内機５０のデータを取得するか否かを判断する（ステップＳ１０１）。制御部３１は、内蔵クロック又は内蔵タイマの出力を参照し、現時点が取得タイミングとして設定されたタイミングに該当するかを判断して、室内機５０のデータを取得するか否かを判断すればよい。データを取得するタイミングには、例えば定期的なタイミングが指定される。

【0056】

室内機５０のデータを取得すると判断した場合（Ｓ１０１：ＹＥＳ）、制御部３１は、メソッドを「ＧＥＴ」、応答の要否を「要」に指定したアプリケーション層ヘッダを含むメッセージを生成する（ステップＳ１０２）。制御部３１は、生成したメッセージを通信部３３より、宛先の室内機５０へ送信する（ステップＳ１０３）。

【0057】

室内機５０の制御部５１は、室外機３０から送信されるメッセージを受信した場合、受信したメッセージのアプリケーション層ヘッダを確認する。アプリケーション層ヘッダにおいて、メソッドが「ＧＥＴ」に指定されている場合、応答の要否は「要」であるため、制御部５１は、室外機３０が要求するデータを含んだメッセージを生成して室外機３０へ返信する（ステップＳ１０４）。

【0058】

室外機３０の制御部３１は、室内機５０からの返信メッセージを受信した場合、受信したメッセージに含まれるデータを記憶部３２に記憶させる（ステップＳ１０５）。ここで、受信したメッセージは、記憶部３２が備える揮発性メモリのみに記憶させてもよく、揮発性メモリに記憶させた後に、不揮発性メモリにコピーして記憶させてもよい。

【0059】

次いで、室外機３０の制御部３１は、室内機５０のデータを更新するか否かを判断する（ステップＳ１０６）。制御部３１は、内蔵クロック又は内蔵タイマの出力を参照し、現時点が更新タイミングとして設定されたタイミングに該当するかを判断して、室内機５０のデータを更新するか否かを判断すればよい。データを更新するタイミングには、例えば定期的なタイミングが指定される。

【0060】

室内機５０のデータを更新すると判断した場合（Ｓ１０６：ＹＥＳ）、制御部３１は、メソッドを「ＳＥＴ」、応答の要否を「不要」に指定したアプリケーション層ヘッダを含むメッセージを生成する（ステップＳ１０７）。制御部３１は、生成したメッセージを通信部３３より、宛先の室内機５０へ送信する（ステップＳ１０８）。

【0061】

室内機５０の制御部５１は、室外機３０から送信されるメッセージを受信した場合、受信したメッセージのアプリケーション層ヘッダを確認する。アプリケーション層ヘッダにおいて、メソッドが「ＳＥＴ」に指定されている場合、応答の要否は「不要」であるため、制御部５１は、受信したメッセージに対する返信は行わずに、記憶部５２に保持しているデータの更新を行う（ステップＳ１０９）。更新対象のデータは、記憶部５２が備える揮発性メモリに保持されてもよく、不揮発性メモリに保持されてもよい。

【0062】

次いで、室外機３０の制御部３１は、自機のデータを室内機５０に通知するか否かを判断する（ステップＳ１１０）。制御部３１は、内蔵クロック又は内蔵タイマの出力を参照し、現時点が通知タイミングとして設定されたタイミングに該当するかを判断して、室内機５０に通知するか否かを判断すればよい。室内機５０に通知するタイミングには、例えば定期的なタイミングが指定される。また、室内機５０に通知するタイミングは、内部状態が変化したタイミングが指定されてもよい。ここで、内部状態の変化とは、機器が備える各種センサやアクチュエータの値の変化や制御状態の変化を表す。

【0063】

室内機５０にデータを通知すると判断した場合（Ｓ１１０：ＹＥＳ）、制御部３１は、メソッドを「ＩＮＦ」、応答の要否を「不要」に指定したアプリケーション層ヘッダを含むメッセージを生成する（ステップＳ１１１）。制御部３１は、生成したメッセージを通信部３３より、宛先の室内機５０へ送信する（ステップＳ１１２）。

【0064】

室内機５０の制御部５１は、室外機３０から送信されるメッセージを受信した場合、受信したメッセージのアプリケーション層ヘッダを確認する。アプリケーション層ヘッダにおいて、メソッドが「ＩＮＦ」に指定されている場合、応答の要否は「不要」であるため、制御部５１は、受信したメッセージに対する返信は行わずに、通知されたデータを記憶部５２に記憶させる（ステップＳ１１３）。ここで、受信したメッセージは、記憶部５２が備える揮発性メモリのみに記憶させてもよく、揮発性メモリに記憶させた後に、不揮発性メモリにコピーして記憶させてもよい。

【0065】

室内機５０は、基本的には室外機３０からの通信を受けるだけであるが、リモコンが操作されて内部状態が変化した場合等において、室外機３０にデータを通知してもよい。

【0066】

室内機５０の制御部５１は、自機のデータを室外機３０に通知するか否かを判断する（ステップＳ１１４）。自機の内部状態に変化があり、通知すると判断した場合（Ｓ１１４：ＹＥＳ）、制御部５１は、メソッドを「ＩＮＦ」、応答の要否を「不要」に指定したアプリケーション層ヘッダを含むメッセージを生成する（ステップＳ１１５）。制御部５１は、生成したメッセージを通信部５３より、宛先の室外機３０へ送信する（ステップＳ１１６）。

【0067】

室外機３０の制御部３１は、室内機５０から送信されるメッセージを受信した場合、受信したメッセージのアプリケーション層ヘッダを確認する。アプリケーション層ヘッダにおいて、メソッドが「ＩＮＦ」に指定されている場合、応答の要否は「不要」である。この場合、制御部３１は、応答を返すことなく、室内機５０より受信したメッセージに含まれるデータを記憶部３２に記憶させる（ステップＳ１１７）。ここで、受信したメッセージは、記憶部３２が備える揮発性メモリのみに記憶させてもよく、揮発性メモリに記憶させた後に、不揮発性メモリにコピーして記憶させてもよい。

【0068】

図７及び図８に示すフローチャートでは、データを取得するか否か、相手のデータを更新するか否か、相手にデータを通知するか否かの順序で判断を実行する構成としたが、これらの判断の順序は便宜的なものに過ぎず、任意の順序で実行することが可能である。

【0069】

図９及び図１０は集中制御に関する通信における通信手順を説明するフローチャートである。集中制御に関する通信では、集中制御装置１０が各室外機３０及び各室内機５０を集中監視・操作するための通信を行う。集中制御装置１０は、各室外機３０及び各室内機５０の状態をアイコンにより表示部１４に表示し、操作部１５を介したアイコン操作により、空調制御やスケジュール運転を行う。図９及び図１０に示すフローチャートでは、簡略化のために、集中制御装置１０と室内機５０との間の通信手順について説明する。

【0070】

集中制御装置１０の制御部１１は、室内機５０のデータを取得するか否かを判断する（ステップＳ１２１）。制御部１１は、内蔵クロック又は内蔵タイマの出力を参照し、現時点が取得タイミングとして設定されたタイミングに該当するかを判断して、室内機５０のデータを取得するか否かを判断すればよい。データを取得するタイミングは、例えば定期的なタイミングが指定される。

【0071】

室内機５０のデータを取得すると判断した場合（Ｓ１２１：ＹＥＳ）、制御部１１は、メソッドを「ＧＥＴ」、応答の要否を「要」に指定したアプリケーション層ヘッダを含むメッセージを生成する（ステップＳ１２２）。制御部１１は、生成したメッセージを通信部１３より、宛先の室内機５０へ送信する（ステップＳ１２３）。

【0072】

室内機５０の制御部５１は、集中制御装置１０から送信されるメッセージを受信した場合、受信したメッセージのアプリケーション層ヘッダを確認する。アプリケーション層ヘッダにおいて、メソッドが「ＧＥＴ」に指定されている場合、応答の要否は「要」であるため、制御部５１は、集中制御装置１０が要求するデータを含んだメッセージを生成して集中制御装置１０へ返信する（ステップＳ１２４）。

【0073】

集中制御装置１０の制御部１１は、室内機５０からの返信メッセージを受信した場合、受信したメッセージに含まれるデータを記憶部１２に記憶させる（ステップＳ１２５）。ここで、受信したメッセージは、記憶部１２が備える揮発性メモリのみに記憶させてもよく、揮発性メモリに記憶させた後に、不揮発性メモリにコピーして記憶させてもよい。

【0074】

次いで、集中制御装置１０の制御部１１は、室内機５０のデータを更新するか否かを判断する（ステップＳ１２６）。制御部１１は、例えば、操作部１５を介したアイコン操作やスケジュールによって状態変化が生じた場合、室内機５０のデータを更新すると判断する。

【0075】

室内機５０のデータを更新すると判断した場合（Ｓ１２６：ＹＥＳ）、制御部１１は、メソッドを「ＳＥＴ」、応答の要否を「不要」に指定したアプリケーション層ヘッダを含むメッセージを生成する（ステップＳ１２７）。制御部１１は、生成したメッセージを通信部１３より、宛先の室内機５０へ送信する（ステップＳ１２８）。

【0076】

室内機５０の制御部５１は、集中制御装置１０から送信されるメッセージを受信した場合、受信したメッセージのアプリケーション層ヘッダを確認する。アプリケーション層ヘッダにおいて、メソッドが「ＳＥＴ」に指定されている場合、応答の要否は「不要」である。制御部５１は、「ＳＥＴ」要求に従って、記憶部５２に保持しているデータの更新を行う（ステップＳ１２９）。更新対象のデータは、記憶部５２が備える揮発性メモリに保持されてもよく、不揮発性メモリに保持されてもよい。

【0077】

室内機５０は、基本的には集中制御装置１０からの通信を受けるだけであるが、リモコンが操作されて内部状態が変化した場合等において、集中制御装置１０にデータを通知してもよい。

【0078】

室内機５０の制御部５１は、自機のデータを集中制御装置１０に通知するか否かを判断する（ステップＳ１３０）。自機の内部状態に変化があり、通知すると判断した場合（Ｓ１３０：ＹＥＳ）、制御部５１は、メソッドを「ＩＮＦ」、応答の要否を「不要」に指定したアプリケーション層ヘッダを含むメッセージを生成する（ステップＳ１３１）。制御部５１は、生成したメッセージを通信部５３より、集中制御装置１０へ送信する（ステップＳ１３２）。

【0079】

集中制御装置１０の制御部１１は、室内機５０から送信されるメッセージを受信した場合、受信したメッセージのアプリケーション層ヘッダを確認する。アプリケーション層ヘッダにおいて、メソッドが「ＩＮＦ」に指定されている場合、応答の要否は「不要」である。この場合、制御部１１は、応答を返すことなく、室内機５０より受信したメッセージに含まれるデータを記憶部３２に記憶させる（ステップＳ１３３）。ここで、受信したメッセージは、記憶部３２が備える揮発性メモリのみに記憶させてもよく、揮発性メモリに記憶させた後に、不揮発性メモリにコピーして記憶させてもよい。

【0080】

図９及び図１０に示すフローチャートでは、データを取得するか否か、相手のデータを更新するか否か、相手にデータを通知するか否かの順序で判断を実行する構成としたが、これらの判断の順序は便宜的なものに過ぎず、任意の順序で実行することが可能である。

【0081】

一般には、通信では要求（リクエスト）と応答（レスポンス）との関係を規定するが、本実施の形態では、応答を必要としない場面では、応答の要否を「不要」に指定し、受信した要求に対して応答を返さない構成としている。以上の構成を採用することにより、本実施の形態では、通信帯域を確保すると共に、各機器の負荷を軽減することができる。

【0082】

（実施の形態２）
実施の形態１では、第一の通信ノードから第二の通信ノードに対してメッセージを送信する際に、第一の通信ノードが応答の要否を指定する構成とした。代替的に、第一の通信ノードにおいて応答の要否を指定せずに、第二の通信ノードが受信したメッセージに含まれるコード（メソッド）に基づき応答の要否を判断してもよい。
実施の形態２では、第二の通信ノードが受信したメッセージに含まれるコード（メソッド）に基づき応答の要否を判断する構成について説明する。

【0083】

実施の形態２における冷凍空調関連システム１の全体構成、及び冷凍空調関連システム１に含まれる各機器の内部構成は実施の形態１と同様であるから、その説明を省略する。また、各機器（通信ノード）において生成するメッセージの構成は実施の形態１と同様であるが、実施の形態２では、ＨＴＴＰのクエリを利用した応答要否の指定は不要である。

【0084】

以下、室内機５０が外部からメッセージを受信した際の動作について説明する。
図１１は室内機５０がメッセージを受信した際に実行する処理の手順を説明するフローチャートである。冷媒制御に関する通信において、室内機５０は、例えば室外機３０から送信されるメッセージを受信する。また、集中制御に関する通信において、室内機５０は、例えば集中制御装置１０から送信されるメッセージを受信する。

【0085】

室内機５０の制御部５１は、室外機３０や集中制御装置１０から送信されるメッセージを受信した場合（ステップＳ２０１）、受信したメッセージのアプリケーション層ヘッダを確認し、応答の要否を判断する（ステップＳ２０２）。受信したメッセージのアプリケーション層ヘッダで指定されているメソッドが「ＧＥＴ」であれば、メッセージの送信元は室内機５０に対してデータの送信を要求しているので、制御部５１は、応答の要否を「要」と判断する。一方、受信したメッセージのアプリケーション層ヘッダで指定されているメソッドが「ＳＥＴ」であれば、メッセージの送信元は室内機５０に対してデータの更新を要求しているだけなので、制御部５１は、応答の要否を「不要」と判断する。また、受信したメッセージのアプリケーション層ヘッダで指定されているメソッドが「ＩＮＦ」であれば、メッセージの送信元は室内機５０に対して情報を通知しているだけなので、制御部５１は、応答の要否を「不要」と判断する。

【0086】

ステップＳ２０２で応答の要否を「要」と判断した場合（Ｓ２０２：ＹＥＳ）、すなわち、受信したメッセージのアプリケーション層ヘッダで指定されているメソッドが「ＧＥＴ」である場合、制御部５１は、メッセージの送信元である室外機３０又は集中制御装置１０が要求しているデータ（例えば、センサ値や室内機５０の制御状態などのデータ）を含んだメッセージを生成して、送信元に返信する（ステップＳ２０３）。

【0087】

ステップＳ２０２で応答の要否を「不要」と判断した場合（Ｓ２０２：ＮＯ）、制御部５１は、受信したメッセージに対する応答は行わずに、メッセージで指定されているメソッドに応じた処理を行う（ステップＳ２０４）。すなわち、制御部５１は、受信したメッセージのアプリケーション層ヘッダで指定されているメソッドが「ＳＥＴ」である場合、記憶部５２に記憶されているデータを更新する処理を行い、「ＩＮＦ」である場合、通知されたデータを記憶部５２に記憶させる処理を行う。

【0088】

図１１のフローチャートでは、室内機５０が外部からメッセージを受信した場合の動作について説明したが、集中制御装置１０又は室外機３０がメッセージを受信した場合についても、受信したメッセージに含まれるコード（メソッド）に基づき応答の要否を判断すればよい。

【0089】

以上のように、実施の形態２では、メッセージにおいて応答の要否を指定することなく、メッセージに含まれるコード（メソッド）に基づき、受信側で応答の要否を判断することができる。

【0090】

（実施の形態３）
実施の形態１及び２は、メッセージに含まれるコード（メソッド）又はタイプに基づき応答の要否を判断する構成としたが、他の属性に基づき、応答の要否を判断する構成としてもよい。
実施の形態３では、メッセージを生成したアプリケーションの種類に応じて、応答の要否を判断する構成について説明する。

【0091】

実施の形態３における冷凍空調関連システム１の全体構成、及び冷凍空調関連システム１に含まれる各機器の内部構成は実施の形態１と同様であるから、その説明を省略する。各機器（通信ノード）が送受信するメッセージのフォーマットは実施の形態１に示したものと同様であるが、実施の形態３では、ＵＲＩ（Uniform Resource Identifiers）領域にＡＰＩ（Application Programming Interface）バージョン／アプリケーション名／リソース名を含む情報が格納される。例えば、冷媒制御において送受信されるメッセージが「ｐｒｏｄｕｃｔ ｃｏｎｔｒｏｌ」というアプリケーションよって生成されるとした場合、当該メッセージのアプリケーション名には「ｐｒｏｄｕｃｔ ｃｏｎｔｒｏｌ」を表す「ｐｒｄ」が指定される。また、集中制御において送受信されるメッセージが「ｍｏｎｉｔｏｒ」というアプリケーションによって生成されるとした場合、当該メッセージのアプリケーション名には「ｍｏｎｉｔｏｒ」を表す「ｍｏｎ」が指定される。なお、ＡＰＩバージョン及びリソース名については適宜の値が格納される。実施の形態３では、アプリケーションとして応答が必要か否かの観点から、応答の要否が判断される。

【0092】

図１２は実施の形態３における冷媒制御での通信手順を説明するフローチャートである。冷媒制御では、室外機３０及び室内機５０において上述した「ｐｒｏｄｕｃｔ ｃｏｎｔｒｏｌ」というアプリケーションが実行され、このアプリケーションを通じて生成されるメッセージを送受信することで冷媒制御に係る通信を行う。

【0093】

室外機３０は、全体の制御を行うため、室内機５０のデータを定期的に要求する。室外機３０の制御部３１は、室内機５０のデータを取得するか否かを判断し（ステップＳ３０１）、取得すると判断した場合（Ｓ３０１：ＹＥＳ）、メソッドを「ＧＥＴ」、アプリケーション名を「ｐｒｄ」、応答の要否を「要」に指定したアプリケーション層ヘッダを含むメッセージを生成する（ステップＳ３０２）。室外機３０が室内機５０に対してデータを要求する場合、室内機５０による応答が必要である。すなわち、「ｐｒｏｄｕｃｔ ｃｏｎｔｒｏｌ」アプリケーションとして応答が必要であるため、応答の要否は「要」に指定される。制御部３１は、生成したメッセージを通信部３３より、宛先の室内機５０へ送信する（ステップＳ３０３）。

【0094】

室内機５０の制御部５１は、室外機３０より、メソッドを「ＧＥＴ」、アプリケーション名を「ｐｒｄ」、応答の要否を「要」に指定したメッセージを受信した場合、室外機３０が要求するデータを含んだメッセージを生成して室外機３０へ返信する（ステップＳ３０４）。

【0095】

室外機３０の制御部３１は、室内機５０から返信されるメッセージを受信した場合、受信したメッセージに含まれるデータを記憶部３２に記憶させる（ステップＳ３０５）。

【0096】

冷媒制御において、室外機３０は室内機５０のアクチュエータを制御する場合がある。室外機３０の制御部３１は、室内機５０のアクチュエータを制御するか否かを判断し（ステップＳ３０６）、制御すると判断した場合（Ｓ３０６：ＹＥＳ）、メソッドを「ＳＥＴ」、アプリケーション名を「ｐｒｄ」、応答の要否を「不要」に指定したアプリケーション層ヘッダを含み、制御値をデータに含むメッセージを生成する（ステップＳ３０７）。室外機３０は、指令内容が変化した場合に制御指令を室内機５０へ送信するが、そのタイミングを逃したとしても定期的なタイミングで制御指令を室内機５０へ送信すればよいので、室内機５０からの応答は不要である。すなわち、「ｐｒｏｄｕｃｔ ｃｏｎｔｒｏｌ」アプリケーションとして応答が不要であるため、応答の要否は「不要」に指定される。制御部３１は、生成したメッセージを通信部３３より、宛先の室内機５０へ送信する（ステップＳ３０８）。

【0097】

室内機５０の制御部５１は、室外機３０より、メソッドを「ＳＥＴ」、アプリケーション名を「ｐｒｄ」、応答の要否を「不要」に指定し、制御値を含んだメッセージを受信した場合、アクチュエータに対する制御値を更新することによって、アクチュエータの制御を行う（ステップＳ３０９）。

【0098】

冷媒制御において、室内機５０はリモコン操作などで制御状態が変化した場合、制御状態の変化を室外機３０に通知する。室内機５０の制御部５１は、制御状態を室外機３０に通知するか否かを判断し（ステップＳ３１０）、通知すると判断した場合（Ｓ３１０：ＹＥＳ）、メソッドを「ＩＮＦ」、アプリケーション名を「ｐｒｄ」、応答の要否を「不要」に指定したアプリケーション層ヘッダを含み、制御状態の情報をデータに含むメッセージを生成する（ステップＳ３１１）。室内機５０は、室外機３０がＧＥＴメソッドで定期的に取得している情報を、内容変化時に通知しているだけなので、室外機３０からの応答は不要である。すなわち、「ｐｒｏｄｕｃｔ ｃｏｎｔｒｏｌ」アプリケーションとして応答が不要であるため、応答の要否は「不要」に指定される。制御部５１は、生成したメッセージを通信部５３より、室外機３０へ送信する（ステップＳ３１２）。

【0099】

室外機３０の制御部３１は、室内機５０より、メソッドを「ＩＮＦ」、アプリケーション名を「ｐｒｄ」、応答の要否を「不要」に指定し、制御状態の情報を含んだメッセージを受信した場合、メッセージに含まれる制御状態の情報を記憶部３２に記憶させる処理を行う（ステップＳ３１３）。

【0100】

図１３及び図１４は実施の形態３における集中制御での通信手順を説明するフローチャートである。集中制御では、集中制御装置１０、室外機３０及び室内機５０において上述した「ｍｏｎｉｔｏｒ」というアプリケーションが実行され、このアプリケーションを通じて生成されるメッセージを送受信することで集中制御に係る通信を行う。以下では、集中制御装置１０と室内機５０との間の通信について説明する。

【0101】

集中制御装置１０は、全体の制御を行うため、室内機５０のデータを定期的に要求する。集中制御装置１０の制御部１１は、室内機５０のデータを取得するか否かを判断し（ステップＳ３２１）、取得すると判断した場合（Ｓ３２１：ＹＥＳ）、メソッドを「ＧＥＴ」、アプリケーション名を「ｍｏｎ」、応答の要否を「要」に指定したアプリケーション層ヘッダを含むメッセージを生成する（ステップＳ３２２）。集中制御装置１０が室内機５０に対してデータを要求する場合、室内機５０による応答が必要である。すなわち、「ｍｏｎｉｔｏｒ」アプリケーションとして応答が必要であるため、応答の要否は「要」に指定される。制御部１１は、生成したメッセージを通信部１３より、宛先の室内機５０へ送信する（ステップＳ３２３）。

【0102】

室内機５０の制御部５１は、集中制御装置１０より、メソッドを「ＧＥＴ」、アプリケーション名を「ｍｏｎ」、応答の要否を「要」に指定したメッセージを受信した場合、集中制御装置１０が要求するデータを含んだメッセージを生成して集中制御装置１０へ返信する（ステップＳ３２４）。

【0103】

集中制御装置１０の制御部１１は、室内機５０から返信されるメッセージを受信した場合、受信したメッセージに含まれるデータを記憶部１２に記憶させる（ステップＳ３２５）。

【0104】

集中制御において、集中制御装置１０から室内機５０に対してユーザ操作やスケジュール設定を行う場合がある。集中制御装置１０の制御部１１は、室内機５０に対するユーザ操作又はスケジュール設定を行うか否かを判断し（ステップＳ３２６）、ユーザ操作又はスケジュール設定を行うと判断した場合（Ｓ３２６：ＹＥＳ）、メソッドを「ＳＥＴ」、アプリケーション名を「ｍｏｎ」、応答の要否を「要」に指定したアプリケーション層ヘッダを含み、ユーザ操作に係る操作値又はスケジュール設定に係る設定値をデータに含むメッセージを生成する（ステップＳ３２７）。集中制御装置１０は、ユーザ操作やスケジュール設定の指示に対して室内機５０から応答がない場合、通信異常であるか否かを確定させる必要があるため、室内機５０からの応答を要とする。すなわち、「ｍｏｎｉｔｏｒ」アプリケーションとして応答が必要であるため、応答の要否は「要」に指定される。制御部１１は、生成したメッセージを通信部１３より、室内機５０へ送信する（ステップＳ３２８）。

【0105】

室内機５０の制御部５１は、集中制御装置１０より、メソッドを「ＳＥＴ」、アプリケーション名を「ｍｏｎ」、応答の要否を「要」に指定し、操作値又は設定値を含んだメッセージを受信した場合、受信したメッセージに基づくユーザ操作又はスケジュール設定を行い、ユーザ操作又はスケジュール設定が完了した旨の情報を含むメッセージを返信する（ステップＳ３２９）。

【0106】

集中制御装置１０の制御部１１は、室内機５０から返信されるメッセージを受信した場合、受信したメッセージに含まれるデータを記憶部３２に記憶させる（ステップＳ３３０）。

【0107】

集中制御において、室内機５０はユーザ操作などで制御状態が変化した場合、制御状態の変化を集中制御装置１０に通知する。室内機５０の制御部５１は、制御状態を集中制御装置１０に通知するか否かを判断し（ステップＳ３３１）、通知すると判断した場合（Ｓ３３１：ＹＥＳ）、メソッドを「ＩＮＦ」、アプリケーション名を「ｍｏｎ」、応答の要否を「不要」に指定したアプリケーション層ヘッダを含み、制御状態の情報をデータに含むメッセージを生成する（ステップＳ３３２）。室内機５０は、集中制御装置１０がＧＥＴメソッドで定期的に取得している情報を、内容変化時に通知しているだけなので、集中制御装置１０からの応答を不要である。すなわち、「ｍｏｎｉｔｏｒ」アプリケーションとして応答は不要であるため、応答の要否は「不要」に指定される。制御部５１は、生成したメッセージを通信部５３より、集中制御装置１０へ送信する（ステップＳ３３３）。

【0108】

集中制御装置１０の制御部１１は、室内機５０より、メソッドを「ＩＮＦ」、アプリケーション名を「ｍｏｎ」、応答の要否を「不要」に指定し、制御状態の情報を含んだメッセージを受信した場合、メッセージに含まれる制御状態の情報を記憶部１２に記憶させる処理を行う（ステップＳ３３４）。

【0109】

図１３及び図１４のフローチャートでは、集中制御装置１０と室内機５０との間の通信について説明したが、集中制御装置１０と室外機３０との通信についても同様である。

【0110】

以上のように、実施の形態３では、メッセージを生成したアプリケーションの種類に応じて応答の要否が判断される。例えば、同じ「ＳＥＴ」リクエストであっても、冷媒制御用のアプリケーション（ｐｒｏｄｕｃｔ ｃｏｎｔｒｏｌ）では応答の要否は「不要」に指定され、集中制御用のアプリケーション（ｍｏｎｉｔｏｒ）では応答の要否は「要」に指定される。

【0111】

実施の形態３では、メッセージの送信側にて応答の要否を指定する構成としたが、実施の形態２と同様に、送信すべきメッセージでは応答の要否を指定せずに、受信側の機器がメッセージに含まれる情報（メソッド名及びアプリケーション名）を参照して、応答の要否を判断してもよい。

【0112】

（実施の形態４）
実施の形態４では、室外機３０から室内機５０にメッセージを送信することにより、室内機５０が状態変化を検出した場合のデータの送信タイミングを指定する構成について説明する。

【0113】

実施の形態４では、室内機５０から室外機３０に対して、冷凍空調関連ユニットの状態変化に関するデータを送信する場合、室外機３０に負荷が集中しないようにタイムスライスを行う。ここで、冷凍空調関連ユニットの状態変化とは、例えば、室内機５０が備える各種センサやアクチュエータの値の変化を表す。

【0114】

具体的には、室外機３０（第一の通信ノード）は、室内機５０（第二の通信ノード）が状態変化を検出した場合、室内機５０がデータを送信すべき送信タイミングに係る情報を含むメッセージを生成し、生成したメッセージを室内機５０へ送信する。送信タイミングに係る情報は、例えば、アプリケーション層ヘッダに続くデータのペイロードに記述される。室内機５０は、メッセージに記述されたタイミングに従ってデータの送信を行うことにより、室外機３０への負荷の集中を回避する。

【0115】

図１５は送信タイミングの設定例を説明する説明図である。送信タイミングは、複数の室内機５０で同期した基準時間からの経過時間に基づき規定され、複数の室内機５０のそれぞれに固有のタイミングとして定められる。図１５の例では、３台の室内機５０，５０，５０における送信タイミングを示している。

【0116】

時間Ｔ０は３台の室内機５０，５０，５０で同期した基準時間を表す。時間Ｔ１１，Ｔ１２，Ｔ１３，…は、第一の室内機５０について定められた送信タイミングを示し、時間Ｔ２１，Ｔ２２，Ｔ２３，…は、第二の室内機５０について定められた送信タイミングを示し、時間Ｔ３１，Ｔ３２，Ｔ３３，…は、第三の室内機５０について定められた送信タイミングを示している。

【0117】

図１５の例では、送信タイミングの周期は各室内機５０において共通である。すなわち、Ｔ１２－Ｔ１１（＝Ｔ１３－Ｔ１２＝Ｔ１４－Ｔ１３＝…）＝Ｔ２２－Ｔ２１（＝Ｔ２３－Ｔ２２＝Ｔ２４－Ｔ２３＝…）＝Ｔ３２－Ｔ３１（＝Ｔ３３－Ｔ３２＝Ｔ３４－Ｔ３３＝…）である。図１５の例では、基準時間と最初の送信タイミングとの時間間隔を各室内機５０に固有の値としている。すなわち、Ｔ１１≠Ｔ２１≠Ｔ３１としている。以上のように、各室内機５０の送信タイミングを設定することにより、各室内機５０の送信タイミングをずらすことができる。

【0118】

各室内機５０は、自機に定められた送信タイミングに基づき、状態変化に関する情報を送信することが可能なタイミングを計算する。例えば、集中制御装置１０から各室内機５０に対して一斉に運転指令を送信したことに伴い、図１５に記入した時間ＴＡで各室内機５０において状態変化が検出されたとする。この場合、第一の室内機５０では、複数の送信タイミングＴ１１，Ｔ１２，…のうち、状態変化を検出した後の最先のタイミングはＴ１４であるため、その時間までデータの送信を遅延させる。すなわち、第一の室内機５０の遅延時間はＴ１４－ＴＡである。また、第二の室内機５０では、複数の送信タイミングＴ２１，Ｔ２２，…のうち、状態変化を検出した後の最先のタイミングはＴ２３であるため、その時間までデータの送信を遅延させる。すなわち、第二の室内機５０の遅延時間はＴ２３－ＴＡである。同様に、第三の室内機５０では、複数の送信タイミングＴ３１，Ｔ３２，…のうち、状態変化を検出した後の最先のタイミングはＴ３３であるため、その時間までデータの送信を遅延させる。すなわち、第三の室内機５０の遅延時間はＴ３３－ＴＡである。

【0119】

図１５の例では、各室内機５０に設定される送信タイミングの周期は一定としたが、２つ以上の室内機５０で送信タイミングが重ならないのであれば、室内機５０間で異なる周期を設定してもよい。室内機５０の送信タイミングは、データを送信すべき室内機５０の数やデータを送信すべき室内機５０の優先順位等に応じて、適宜設定され得る。

【0120】

更に、室内機５０の送信タイミングは、各室内機５０が状態変化を検出してからの経過時間に基づき設定されてもよい。例えば、各室内機５０が時間ＴＡに状態変化を検出した場合、第一の室内機５０はＴＡから時間Ｔ１が経過したタイミングを送信タイミングとし、第二の室内機５０は時間ＴＡからＴ２（≠Ｔ１）が経過したタイミングを送信タイミングとし、第三の室内機５０は時間ＴＡからＴ３（≠Ｔ１≠Ｔ２）が経過したタイミングを送信タイミングとしてもよい。

【0121】

図１６は実施の形態４における通信手順を説明するタイミングチャートである。室外機３０の制御部３１は、各室内機５０がデータを送信すべき送信タイミングに係る情報を含むメッセージを生成し、生成したメッセージを通信部３３より各室内機５０へ送信することによって、各室外機３０に送信タイミングを通知する（ステップＳ４０１）。ステップＳ４０１では、室外機３０から室内機５０への通知であるから、制御部３１は、メソッドを「ＩＮＦ」、応答の要否を「不要」に指定したアプリケーション層ヘッダを含み、データのペイロードに各室内機５０に固有の送信タイミングを記述したメッセージを生成し、各室内機５０へ送信する。

【0122】

各室内機５０の制御部５１は、室外機３０から送信されるメッセージを受信した場合、受信したメッセージのアプリケーション層ヘッダを確認する。アプリケーション層ヘッダにおいて、メソッドが「ＩＮＦ」に指定されている場合、応答の要否は「不要」であるため、制御部５１は、受信したメッセージに対する返信は行わずに、送信タイミングを含むデータを記憶部５２に記憶させる（ステップＳ４０２～Ｓ４０４）。ここで、受信したメッセージは、記憶部５２が備える揮発性メモリのみに記憶させてもよく、揮発性メモリに記憶させた後に、不揮発性メモリにコピーして記憶させてもよい。

【0123】

各室内機５０の制御部５１は、それぞれが備えるセンサやアクチュエータの状態を監視する。制御部５１は、自機の状態変化を検出した場合（ステップＳ４０５～Ｓ４０７）、記憶部５２に記憶されている送信タイミングに基づき、自機がデータを送信することが可能なタイミングを計算する（ステップＳ４０８～Ｓ４１０）。ここで、自機の送信タイミングは、記憶部５２が備える揮発性メモリに保持されてもよく、不揮発性メモリに保持されてもよい。

【0124】

各室内機５０は、現時点が送信可能なタイミングであるか否かを判断し、送信可能なタイミングであると判断した場合、状態変化に関する情報を含むメッセージを生成し、生成したメッセージを通信部５３より室外機３０へ送信することによって、室外機３０に状態変化を通知する（ステップＳ４１１～Ｓ４１３）。ステップＳ４１１～Ｓ４１３では、室内機５０から室外機３０への状態変化に伴う通知であるから、制御部３１は、メソッドを「ＩＮＦ」、応答の要否を「不要」に指定したアプリケーション層ヘッダを含み、状態変化に関する情報をデータに含むメッセージを生成し、室外機３０へ送信する。

【0125】

室外機３０は、各室内機５０から送信されるメッセージを受信する都度、ＡＣＫ電文を返信すると共に、各室内機５０の状態変化に係る情報を記憶部３２に記憶させる（ステップＳ４１４～Ｓ４１６）。ここで、受信したメッセージは、記憶部３２が備える揮発性メモリのみに記憶させてもよく、揮発性メモリに記憶させた後に、不揮発性メモリにコピーして記憶させてもよい。

【0126】

以上のように、実施の形態４では、例えば集中制御装置１０から各室内機５０に対して一斉に運転指令を送信したことに伴い、各室内機５０が同じタイミングで状態変化を検出し、各室内機５０から状態変化に関する通知が一斉に実行される状況であっても、各室内機５０は各機器に固有に定められた送信タイミングに従って状態変化に関する通知を遅延させるので、受信側の室外機３０における負荷集中を回避することができる。

【0127】

本実施の形態では、室外機３０から各室内機５０に対して送信タイミングを通知する構成としたが、集中制御装置１０から各室内機５０に対して送信タイミングを通知してもよく、冷凍空調関連ユニットにサービスチェッカーを接続し、サービスチェッカーから各室内機５０に送信タイミングを通知してもよい。

【0128】

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

【符号の説明】

【0129】

１ 冷凍空調関連システム
１０ 集中制御装置
１１ 制御部
１２ 記憶部
１３ 通信部
１４ 表示部
１５ 操作部
１６ 接続端子
３０ 室外機
３１ 制御部
３２ 記憶部
３３ 通信部
３４～３６ 接続端子
５０ 室内機
５１ 制御部
５２ 記憶部
５３ 通信部
５４～５５ 接続端子

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】