JP2022175536A - データ統合装置、通信システム、統合データの生成方法及びプログラム - Google Patents

Abstract

【課題】設備機器から異なる通信経路を経由して送信されたデータを管理し易くする。【解決手段】データ統合装置３０において、機器通信部３３ａは、室内機１２ａに関する第１の機器データを第１の通信経路を経由して受信し、室内機１２ａに関する第２の機器データを、第１の通信経路とは異なる第２の通信経路を経由して受信する。データ統合部３１２は、第１の機器データと第２の機器データとに共通して含まれる項目を含む統合データＳを生成する。データ統合部３１２は、第１の機器データに含まれる項目の名称又はデータフォーマットと、第２の機器データに含まれるその項目の名称又はデータフォーマットと、が異なる場合、統合データＳにおけるその項目の名称又はデータフォーマットを、統一された名称又はデータフォーマットに設定する。【選択図】図４

Description

本開示は、データ統合装置、通信システム、統合データの生成方法及びプログラムに関する。

設備機器を遠隔で管理するために、設備機器に関するデータを外部の装置に送信する技術が知られている。例えば、特許文献１は、空調ユニットと外部コンピュータであるサーバとの間で公衆回線を介してデータを送受信する空気調和システムを開示している。

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

上記のように、設備機器に関するデータを外部の装置に送信するシステムにおいて、システムの構成によっては、設備機器から外部の装置に異なる複数の通信経路を経由してデータが送信される場合がある。このような場合、従来の技術では、たとえ同一の設備機器から送信されたデータであっても、同一の設備機器から送信されたデータとして扱うことが難しい。そのため、同一の設備機器から送信されたデータであっても異なる設備機器から送信されたデータとして扱われざるを得ず、設備機器から送信されたデータの管理が複雑になる、との課題がある。

本開示は、上記のような問題点を解決するためになされたものであり、設備機器から異なる通信経路を経由して送信されたデータを管理し易くすることが可能なデータ統合装置等を提供することを目的とする。

上記目的を達成するために、本開示に係るデータ統合装置は、
設備機器に関する第１の機器データを第１の通信経路を経由して受信し、前記設備機器に関する第２の機器データを、前記第１の通信経路とは異なる第２の通信経路を経由して受信する機器通信手段と、
前記第１の機器データと前記第２の機器データとに共通して含まれる項目を含む統合データを生成するデータ統合手段と、を備え、
前記データ統合手段は、前記第１の機器データに含まれる前記項目の名称又はデータフォーマットと、前記第２の機器データに含まれる前記項目の名称又はデータフォーマットと、が異なる場合、前記統合データにおける前記項目の名称又はデータフォーマットを、統一された名称又はデータフォーマットに設定する。

本開示に係るデータ統合装置は、設備機器に関する第１の機器データを第１の通信経路を経由して受信し、設備機器に関する第２の機器データを第２の通信経路を経由して受信し、第１の機器データと第２の機器データとに共通して含まれる項目を含む統合データを生成する。このとき、本開示に係るデータ統合装置は、第１の機器データと第２の機器データとに共通して含まれる項目の、統合データにおける名称又はデータフォーマットを、統一された名称又はデータフォーマットに設定する。従って、本開示によれば、設備機器から異なる通信経路を経由して送信されたデータを管理し易くすることができる。

実施の形態１に係る通信システムの全体構成を示す図 実施の形態１に係るデータ統合装置のハードウェア構成を示す図 実施の形態１に係る端末のハードウェア構成を示す図 実施の形態１に係るデータ統合装置の機能的な構成を示す図 実施の形態１に係るデータ統合装置に記憶される第１の機器データの例を示す図 実施の形態１に係るデータ統合装置に記憶される第２の機器データの例を示す図 実施の形態１に係るデータ統合装置に記憶される第３の機器データの例を示す図 実施の形態１に係る統合データの例を示す図 実施の形態１に係る物理プロパティ名及びデータ型の統合ルールを示す図 実施の形態１に係る運転状態の統合ルールの例を示す図 実施の形態１に係る風量の統合ルールの例を示す図 実施の形態１に係る運転モードの統合ルールの例を示す図 実施の形態１に係るデータ統合装置により実行されるデータ統合処理の流れを示すフローチャート 実施の形態１に係るデータ統合装置により実行されるデータ出力処理の流れを示すフローチャート 実施の形態２に係るデータ統合装置により実行されるデータ出力処理の流れを示すフローチャート

以下、実施の形態について、図面を参照しながら詳細に説明する。なお、図中同一又は相当部分には同一符号を付す。

（実施の形態１）
図１に、実施の形態１に係る通信システム１の構成を示す。図１に示すように、通信システム１は、空調機１０と、データ統合装置３０と、ユーザ端末５０と、を備える。

空調機１０は、対象となる室内空間を空調する。空調機１０は、一例として、ＣＯ_２（二酸化炭素）、ＨＦＣ（ハイドロフルオロカーボン）等を冷媒として用いたヒートポンプ式の空調設備である。空調機１０は、室外に設置される室外機１１と、室内に設置される複数の室内機１２ａ，１２ｂ，…と、空調機１０の動作を制御するシステムコントローラ１３と、を備える。空調機１０は、いわゆるマルチエアコンであって、複数の室内機１２ａ，１２ｂ，…により複数の室内空間を空調することができる。

室外機１１と複数の室内機１２ａ，１２ｂ，…との間には、冷媒が流れるヒートポンプが設けられている。室外機１１は、冷媒を圧縮してヒートポンプを循環させる圧縮機と、冷媒の循環方向を切り替える四方弁と、室外空気と冷媒との間で熱交換する室外熱交換器と、冷媒を減圧して膨張させる膨張弁と、室外空気を室外熱交換器に送る室外ファンと、を備える。複数の室内機１２ａ，１２ｂ，…のそれぞれは、室内空間の空気と冷媒との間で熱交換する室内熱交換器と、熱交換された空気を室内空間に送る室内ファンと、を備える。

システムコントローラ１３は、室外機１１及び複数の室内機１２ａ，１２ｂ，…の動作を制御する集中コントローラである。システムコントローラ１３は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、通信インタフェース及び読み書き可能な不揮発性の半導体メモリを備えており、空調機１０全体の動作を制御する。具体的に説明すると、システムコントローラ１３は、室外機１１に設けられた圧縮機の駆動周波数、四方弁の切り換え、室外ファンの回転速度、及び、膨張弁の開度を制御し、複数の室内機１２ａ，１２ｂ，…のそれぞれに設けられた室内ファンの回転速度を制御する。

システムコントローラ１３は、フィールドネットワークＮ２を介して、室外機１１及び複数の室内機１２ａ，１２ｂ，…と通信する。フィールドネットワークＮ２は、室外機１１と複数の室内機１２ａ，１２ｂ，…とシステムコントローラ１３との間に構築された通信ネットワークである。フィールドネットワークＮ２では、予め定められた通信プロトコルに従って通信が行われる。フィールドネットワークＮ２に接続された各ユニットにはアドレスが割り当てられている。送信元のユニットは、送信先のユニットのアドレスに対して、又はブロードキャストでコマンドを送信する。

システムコントローラ１３は、ゲートウェイ１４を介して広域ネットワークＮ１と接続されている。広域ネットワークＮ１は、地理的に離れた広域なエリア間で通信するための通信ネットワークであって、具体的にはインターネット通信網である。システムコントローラ１３は、広域ネットワークＮ１を介してデータ統合装置３０と通信し、システムコントローラ１３で集約した空調機１０の情報をデータ統合装置３０に送信する。

ゲートウェイ１４は、通信プロトコルが異なるネットワーク間で送信されるデータを中継する装置であって、具体的には、システムコントローラ１３とデータ統合装置３０との間で送信されるデータを中継する。

アダプタ１５は、室内機１２ａをＷｉ-Ｆｉ（Wireless Fidelity）及び広域ネットワークＮ１に接続させるためのインタフェースである。アダプタ１５は、室内機１２ａに対して通信可能に取り付けられる。より詳細には、アダプタ１５は、室内機１２ａとの間で情報のやり取りをすることができるように、室内機１２ａに対して有線ケーブルで電気的に接続される。アダプタ１５は、室内機１２ａから取得した情報を広域ネットワークＮ１に送信し、広域ネットワークＮ１から受信した情報を室内機１２ａに伝送する。

リモコン１６は、室内機１２ａを操作するための装置である。リモコン１６は、例えば、室内機１２ａにより空調される室内空間の壁、柱等に設置されている。リモコン１６は、室内空間に居るユーザの操作を受け付けて、室内機１２ａに送信する。例えば、ユーザは、リモコン１６を操作して、室内機１２ａに運転指令を入力する。運転指令は、例えば、運転と停止との切換、運転モード、設定温度、設定湿度、風量又は風向の設定等である。室内機１２ａは、リモコン１６に入力された運転指令に従って動作する。

操作端末１７は、パーソナルコンピュータ、スマートフォン、タブレット等の情報端末である。操作端末１７は、図示を省略するが、ＣＰＵ、ＲＯＭ、ＲＡＭ、操作部、表示部、通信インタフェース及び読み書き可能な不揮発性の半導体メモリを備えており、主に空調機１０を点検及び保守する作業員により操作される。操作端末１７は、ＢＬＥ（Bluetooth Low Energy：登録商標）等の通信媒体を介してリモコン１６と通信する。操作端末１７は、作業員の操作を受け付けて、リモコン１６を介して室内機１２ａに送信する。

このように、室内機１２ａは、システムコントローラ１３、アダプタ１５及びリモコン１６を介して、外部と通信することができる。そのため、室内機１２ａは、システムコントローラ１３により制御されるだけでなく、アダプタ１５及びリモコン１６によっても制御される。一方で、室内機１２ｂは、アダプタ１５及びリモコン１６とは接続されていないため、システムコントローラ１３のみにより制御される。

データ統合装置３０は、広域ネットワークＮ１を介して空調機１０と通信可能に接続されており、空調機１０を遠隔的に管理する。データ統合装置３０は、一例として、クラウドコンピューティングのリソースを提供するサーバである。図２に示すように、データ統合装置３０は、制御部３１と、記憶部３２と、通信部３３と、を備える。

制御部３１は、ＣＰＵ、ＲＯＭ及びＲＡＭを備える。ＣＰＵは、中央処理装置、中央演算装置、プロセッサ、マイクロプロセッサ、マイクロコンピュータ等とも呼び、データ統合装置３０の制御に係る処理及び演算を実行する処理部として機能する。制御部３１において、ＣＰＵは、ＲＯＭに格納されているプログラム及びデータを読み出し、ＲＡＭをワークエリアとして用いて、データ統合装置３０を統括制御する。

記憶部３２は、フラッシュメモリ、ＥＰＲＯＭ（Erasable Programmable ROM）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ROM）等の不揮発性の半導体メモリを備えており、いわゆる二次記憶装置又は補助記憶装置としての役割を担う。記憶部３２は、制御部３１が各種処理を行うために使用するプログラム及びデータを記憶する。また、記憶部３２は、制御部３１が各種処理を行うことにより生成又は取得するデータを記憶する。

通信部３３は、データ統合装置３０の外部の装置と通信するための通信インタフェースを備える。通信部３３は、具体的には、機器通信部３３ａと、端末通信部３３ｂと、を備える。

機器通信部３３ａは、広域ネットワークＮ１を介して、空調機１０と通信する。これにより、機器通信部３３ａは、空調機１０の現在の運転状態、アドレス等の情報を取得する。より詳細には、機器通信部３３ａは、フィールドネットワークＮ２、システムコントローラ１３及びゲートウェイ１４を通る通信経路２１により、空調機１０に含まれる室外機１１及び複数の室内機１２ａ，１２ｂ，…のそれぞれと通信する。また、図１に示したように、室内機１２ａには、アダプタ１５とリモコン１６とが接続されている。そのため、機器通信部３３ａは、アダプタ１５を通る通信経路２２でも室内機１２ａと通信することができ、リモコン１６及び操作端末１７を通る通信経路２３でも室内機１２ａと通信することができる。このように、機器通信部３３ａは、それぞれシステムコントローラ１３とアダプタ１５とリモコン１６という異なるシステムノードを通る３つの通信経路２１～２３で室内機１２ａと通信することができる。

機器通信部３３ａは、設備機器である室内機１２ａに関する機器データを、異なる通信経路２１～２３を経由して受信する。第１に、機器通信部３３ａは、第１の通信経路を経由して、室内機１２ａから第１の機器データを受信する。第２に、機器通信部３３ａは、第２の通信経路を経由して、室内機１２ａから第２の機器データを受信する。第３に、機器通信部３３ａは、第３の通信経路を経由して、室内機１２ａから第３の機器データを受信する。

以下では、フィールドネットワークＮ２、システムコントローラ１３及びゲートウェイ１４を通る通信経路２１を第１の通信経路と呼び、アダプタ１５を通る通信経路２２を第２の通信経路と呼び、リモコン１６及び操作端末１７を通る通信経路２３を第３の通信経路と呼ぶ。また、第１、第２、第３の通信経路を経由して受信された機器データを、それぞれ第１、第２、第３の機器データと呼ぶ。なお、第１、第２、第３の通信経路の呼び方は例示であって、これら３つの通信経路２１～２３のうちのどれを第１の通信経路、第２の通信経路、又は第３の通信経路と呼んでも良い。

通信経路２１～２３では、通信に使用される通信プロトコルが異なる。一例として、通信経路２１では、主にマルチエアコン内のフィールドネットワークＮ２で採用されている通信プロトコルが使用され、通信経路２２では、主にスリムエアコン又はルームエアコンで採用されている通信プロトコルが使用され、通信経路２３では、操作端末１７にインストールされているアプリケーションソフトウェア独自の通信プロトコルが使用される。

なお、ゲートウェイ１４、アダプタ１５、及びリモコン１６のそれぞれを「アダプタ」と総称することもできる。機器通信部３３ａは、各アダプタと通信を行うインタフェースを備えており、アダプタ毎のプロトコルの吸収を行う。機器通信部３３ａは、機器通信手段の一例である。

端末通信部３３ｂは、広域ネットワークＮ１を介して、ユーザ端末５０と通信する。具体的に説明すると、端末通信部３３ｂは、ユーザ端末５０上で動作するアプリケーションプログラムと通信するためのインタフェースであるＡＰＩ（Application Programming Interface）を備える。例えば、端末通信部３３ｂは、ＭＱＴＴ（Message Queuing Telemetry Transport）、ＨＴＴＰＳ（Hypertext Transfer Protocol Secure）等のプロトコルで、ユーザ端末５０と通信する。

図１に戻って、ユーザ端末５０は、ユーザにより操作されるパーソナルコンピュータ、スマートフォン、タブレット等の情報端末である。ユーザ端末５０を操作するユーザは、主に空調機１０を利用する一般ユーザである。図３に示すように、ユーザ端末５０は、制御部５１と、記憶部５２と、通信部５３と、操作部５４と、表示部５５と、を備える。

制御部５１は、ＣＰＵ、ＲＯＭ及びＲＡＭを備える。ＣＰＵは、中央処理装置、中央演算装置、プロセッサ、マイクロプロセッサ、マイクロコンピュータ等とも呼び、ユーザ端末５０の制御に係る処理及び演算を実行する中央演算処理部として機能する。制御部５１において、ＣＰＵは、ＲＯＭに格納されているプログラム及びデータを読み出し、ＲＡＭをワークエリアとして用いて、ユーザ端末５０を統括制御する。

記憶部５２は、フラッシュメモリ、ＥＰＲＯＭ、ＥＥＰＲＯＭ等の不揮発性の半導体メモリを備えており、いわゆる二次記憶装置又は補助記憶装置としての役割を担う。記憶部５２は、制御部５１が各種処理を行うために使用するプログラム及びデータを記憶する。また、制御部５１が各種処理を行うことにより生成又は取得するデータを記憶する。

通信部５３は、ユーザ端末５０が外部の装置と通信するための通信インタフェースを備える。例えば、通信部５３は、データ統合装置３０を含む外部の装置との間で、広域ネットワークＮ１又はその他のネットワークを介して通信する。

操作部５４は、キーボード、マウス、スイッチ、タッチパッド、タッチパネル等の入力デバイスを備えており、ユーザから操作を受け付ける。ユーザは、操作部５４を操作することによって、様々な指示をユーザ端末５０に入力することができる。操作部５４は、ユーザから入力された操作指示を受け付けると、受け付けた操作指示を制御部５１に送信する。

表示部５５は、ＬＣＤ（Liquid Crystal Display）パネル、有機ＥＬ（Electro-Luminescence）等の表示デバイスを備える。表示部５５は、図示しない表示駆動回路によって駆動され、制御部５１による制御のもとで様々な画像を表示する。

次に、図４を参照して、データ統合装置３０及びユーザ端末５０の機能的な構成について説明する。図４に示すように、データ統合装置３０は、機能的に、データ保存部３１１と、データ統合部３１２と、データ出力部３１３と、を備える。また、ユーザ端末５０は、機能的に、データ取得部５１１を備える。

これらの各機能は、ソフトウェア、ファームウェア、又は、ソフトウェアとファームウェアとの組み合わせによって実現される。ソフトウェア及びファームウェアは、プログラムとして記述され、ＲＯＭ又は記憶部３２，５２に格納される。そして、ＣＰＵが、ＲＯＭ又は記憶部３２，５２に記憶されたプログラムを実行することによって、これらの各機能を実現する。

データ保存部３１１は、機器通信部３３ａにより室内機１２ａから通信経路２１～２３を経由して受信された機器データを、記憶部３２に保存する。ここで、機器データは、管理対象の設備機器である室内機１２ａに関するデータであって、具体的には、室内機１２ａの現在の運転状態、アドレス等を示すデータである。

通信経路２１～２３毎に通信プロトコルが異なるため、データ保存部３１１は、室内機１２ａから受信された機器データを、通信経路２１～２３毎に別々のテーブルに保存する。具体的に説明すると、データ保存部３１１は、通信経路２１を経由して受信された機器データを、機器データＡとして記憶部３２に保存する。データ保存部３１１は、通信経路２２を経由して受信された機器データを、機器データＢとして記憶部３２に保存する。データ保存部３１１は、通信経路２３を経由して受信された機器データを、機器データＣとして記憶部３２に保存する。データ保存部３１１は、制御部３１が記憶部３２と協働することにより実現される。データ保存部３１１は、データ保存手段の一例である。

図５～図７に、それぞれ機器データＡ～Ｃの例を示す。機器データＡ，Ｂは、動的データと静的データとを含んでいる。動的データは、室内機１２ａの運転状態、運転モード等のように、変化するデータであって、室内機１２ａから定期的に送信されるデータである。動的データは、具体的には、室内機１２ａの運転状態、運転モード、設定温度、風量、風向、湿度、外気温等の情報を含む。

これに対して、静的データは、基本的に変化しないデータである。静的データは、室内機１２ａの設定情報、設置情報、メタ情報等のように、初回設定又は設定更新のタイミングで、保守作業員により入力される。静的データは、具体的には、室内機１２ａのアドレス、リモコングループ、設置場所、設置日、機器点検日、機器点検報告者、機器点検結果、次回点検日等の情報を含む。

動的データと静的データは、更新されるタイミングが異なる。そのため、動的データと静的データは、室内機１２ａからデータ統合装置３０に別々のタイミングで送信され、データ統合装置３０において別々のテーブルに保存される。

図５に示すように、機器データＡは、動的データとして、運転状態、運転モード、設定温度、風量及び風向の各項目について、プロパティ名称、物理プロパティ名及び値の情報を有する。また、機器データＡは、静的データとして、アドレス及びグループの各項目について、プロパティ名称、物理プロパティ名及び値の情報を有する。

図６に示すように、機器データＢは、動的データとして、運転状態、運転モード、設定温度、湿度及び風量の各項目について、プロパティ名称、物理プロパティ名及び値の情報を有する。また、機器データＢは、静的データとして、ソフトウェアバージョン及びＭＡＣ（Media Access Control）アドレスの各項目について、プロパティ名称、物理プロパティ名及び値の情報を有する。

図７に示すように、機器データＣは、静的データとして、点検日、点検結果及び次回点検日の各項目について、プロパティ名称、物理プロパティ名及び値の情報を有する。一方で、機器データＣは、動的データを有さない。

また、各機器データＡ～Ｃは、動的データと静的データのそれぞれにおいて、更新時刻の情報を有する。ここで、更新時刻は、各データが取得された時刻である。更新時刻が付与されるタイミングは、通信経路毎の設計に応じて決められている。例えば、更新時刻は、室内機１２ａで付与されても良いし、ゲートウェイ１４、アダプタ１５又はリモコン１６で付与されても良いし、データ統合装置３０で付与されても良い。

なお、機器データＡ～Ｃに含まれるプロパティ名称、物理プロパティ名、値、更新時刻等の情報を総称して、「プロパティ」又は「データプロパティ」と呼ぶこともできる。また、項目は、プロパティ項目とも呼ばれ、機器データＡ～Ｃのテーブルにおける行単位の情報に対応する。言い換えると、機器データＡ～Ｃは、動的データ及び静的データのそれぞれのテーブルにおいて、１行当たり１つの項目の情報を有する。

ここで、「プロパティ名称」は、論理プロパティ名又は論理名とも呼ばれ、機器データＡ～Ｃに含まれる各項目の意味を示す名称である。「物理プロパティ名」は、物理名とも呼ばれ、通信システム１上のデータベース及びソフトウェアで処理する際において、各項目を一意に定義する変数名である。言い換えると、「プロパティ名称」と「物理プロパティ名」はどちらも各項目を識別するための名称であるが、「プロパティ名称」が各項目をユーザが識別するための名称であり、「物理プロパティ名」は、コンピュータ上で各項目を識別するための名称である。例えば、「運転状態」、「設定温度」等は「プロパティ名称」であり、「setTemp」、「targetTemperature」等は「物理プロパティ名」である。

また、機器データＡ～Ｃに含まれる「値」は、プロパティ値とも呼ばれ、プロパティのデータ値である。「値」は、数値であることに限らず、「ＯＮ」、「ＣＯＯＬ」等のＳｔｒｉｎｇ型のフォーマットで表されるものであっても良い。

図４に戻って、データ統合部３１２は、機器通信部３３ａにより室内機１２ａから異なる通信経路２１～２３を経由して受信された機器データＡ～Ｃを統合する。これにより、データ統合部３１２は、機器データＡ～Ｃが統合された統合データＳを生成する。データ統合部３１２は、制御部３１が記憶部３２と協働することにより実現される。データ統合部３１２は、データ統合手段の一例である。

図８に、データ統合部３１２により生成される統合データＳの例を示す。統合データＳは、機器データＡ～Ｃと同様に、動的データのテーブルと静的データのテーブルとを別々に有する。統合データＳは、機器データＡ～Ｃのうちの２以上の機器データに共通して含まれる項目を含んでいる。

具体的には、統合データＳは、動的データとして、機器データＡの動的データと機器データＢの動的データとに共通して含まれる運転状態、運転モード、設定温度及び風量の項目を含んでいる。更に、統合データＳは、動的データとして、機器データＡの動的データのみに含まれる風向の項目と、機器データＢの動的データのみに含まれる湿度の項目と、を含んでいる。

また、統合データＳは、静的データとして、機器データＡの静的データに含まれるアドレス及びグループの項目と、機器データＢの静的データに含まれるソフトウェアバージョン及びＭＡＣアドレスの項目と、機器データＣの静的データに含まれる点検日、点検結果及び次回点検日の項目と、を含んでいる。

このように、統合データＳは、機器データＡ～ＣをＯＲ、すなわち論理和で統合した項目のデータを有する。言い換えると、統合データＳは、機器データＡ～Ｃのうちの少なくとも１つに含まれる項目のデータを有する。

なお、データ統合装置３０は、統合データＳに含まれる項目を定義した定義ファイルを、予め記憶部３２に有する。定義ファイルに定義された項目以外は、機器データＡ～Ｃに含まれていても、統合データＳに含めなくても良い。統合データＳに不要な項目を含めないことで、統合データＳの容量の肥大化を抑え、統合処理を軽減できる。

統合データＳは、このような機器データＡ～ＣのＯＲをとった項目のそれぞれについて、プロパティ名称、物理プロパティ名、値及び更新時刻の情報を有する。ここで、物理プロパティ名、値及び更新時刻は、図５～図７に示したように、機器データＡ～Ｃ間で統一されていない。言い換えると、複数の機器データに共通に含まれる項目であっても、その項目の物理プロパティ名、値及び更新時刻は、複数の機器データ間で同じではない。例えば、「運転状態」の物理プロパティ名は、機器データＡでは「Ｄｒｉｖｅ」であるが、機器データＢでは「ｏｐｅｒａｔｉｏｎＳｔａｔｕｓ」である。また、「運転モード」の値は、機器データＡでは「ＣＯＯＬ」であるが、機器データＢでは「ｃｏｏｌｉｎｇ」である。

このように機器データＡ～Ｃ間でプロパティが異なる理由は、機器データＡ～Ｃが互いに異なる通信経路２１～２３を経由して送信されるためである。通信経路２１～２３で使用される通信プロトコルが異なるため、送信されるデータに含まれるプロパティが通信経路２１～２３によって異なる。従来の技術では、通信経路２１～２３によってプロパティが異なると、同一の設備機器から送信されたデータであっても、同一の設備機器から送信されたデータであると扱うことが難しい。そのため、別の設備機器から送信されたデータとして扱わざるを得ず、設備機器から送信されたデータの管理が複雑になる、との課題がある。

そこで、データ統合部３１２は、異なる通信経路２１～２３を経由して送信された機器データＡ～Ｃから、各機器データＡ～Ｃに含まれるプロパティが統合された統合データＳを生成する。図８に示すように、統合データＳは、物理プロパティ名、値及び更新時刻のそれぞれの情報として、機器データＡ～Ｃのそれぞれに含まれる情報を全て有するのではなく、１つの項目当たり、統一された１つの情報を有する。

このような統合データＳを生成するために、データ統合部３１２は、予め定められた統合ルールＲを参照する。ここで、統合ルールＲは、機器データＡ～Ｃから統合データＳを生成するためのルールを定めたデータである。統合ルールＲは、予め定められており、記憶部３２に記憶されている。以下、図９～図１２を参照して、統合ルールＲの具体例について説明する。

（１）名称の統合
データ統合部３１２は、機器データＡ～Ｃのうちの第１の機器データに含まれる一の項目の名称と、機器データＡ～Ｃのうちの第２の機器データに含まれるその項目の名称と、が異なる場合、統合データＳにおけるその項目の名称を、統一された１つの名称に設定する。言い換えると、データ統合部３１２は、２以上の機器データに共通して含まれる項目の名称がその２以上の機器データ間で異なる場合、統合データＳにおけるその項目の名称を、１つの名称に統一する。

ここで、項目の名称は、機器データＡ～Ｃに含まれる項目を通信システム１上で識別するための情報であって、具体的には、物理プロパティ名である。図５及び図６に示したように、機器データＡと機器データＢとは、共通の項目として、どちらも運転状態、運転モード、設定温度及び風量の項目を有するが、これらの項目の物理プロパティ名は、機器データＡと機器データＢとで異なる。そこで、統合ルールＲは、統合データＳにおけるこれらの項目の物理プロパティ名として、統一された物理プロパティ名を定める。

図９に、機器データＡと機器データＢとの双方に共通に含まれる運転状態、運転モード、設定温度及び風量の各項目について、統合ルールＲにおける物理プロパティ名及びデータ型の対応例を示す。図９に示す統合ルールＲは、統合データＳにおけるこれらの項目の物理プロパティ名として、機器データＢの物理プロパティ名と同じ物理プロパティ名を使用することを定めている。

この理由は、一例として、機器データＡの物理プロパティ名はメーカー独自の名称であり、機器データＢの物理プロパティ名は国際標準規格であるＥＣＨＯＮＥＴ Ｌｉｔｅ（登録商標）に準拠していることを想定しているためである。統合データＳの物理プロパティ名として、国際標準規格に準拠する機器データＢの物理プロパティ名に統一することで、社外のアプリケーションソフトウェアとデータ連携する場合でも、データフォーマットを公開できるというメリットがある。

なお、統合ルールＲは、図９に示した機器データＡ，Ｂと統合データＳとの間の対応だけではなく、図示は省略するが、機器データＣと統合データＳとの間の対応も定めている。データ統合部３１２は、このような統合ルールＲに従って、機器データＡ～Ｃにおける物理プロパティ名及びデータ型を、統合データＳにおける物理プロパティ名及びデータ型に変換する。

（２）データフォーマットの統合
データ統合部３１２は、機器データＡ～Ｃのうちの第１の機器データに含まれる一の項目のデータフォーマットと、機器データＡ～Ｃのうちの第２の機器データに含まれるその項目のデータフォーマットと、が異なる場合、統合データＳにおけるその項目のデータのデータフォーマットを、統一されたデータフォーマットに設定する。言い換えると、データ統合部３１２は、２以上の機器データに共通して含まれる項目のデータフォーマットが２以上の機器データ間で異なる場合、統合データＳにおけるその項目のデータフォーマットを、１つのフォーマットに統一する。

ここで、データフォーマットは、機器データＡ～Ｃ及び統合データＳにおける値のデータ型、値の持ち方、値のステップ幅、値のステップ数、値の表現形式等を含む。データ型は、Ｓｔｒｉｎｇ型、Ｂｏｏｌｅａｎ型、Ｎｕｍｂｅｒ型等のような、機器データＡ～Ｃ及び統合データＳにおける値のフォーマットである。値の持ち方は、例えば風量の値を１－３で持つか、ＨＩＧＨ／ＭＩＤ／ＬＯＷで持つかである。

データ型に関して、図９の例では、機器データＡでは、全ての項目のデータ型としてＳｔｒｉｎｇ型が使用されている。これに対して、統合ルールＲは、統合データＳでは、運転状態のデータ型としてＢｏｏｌｅａｎ型を使用し、運転モードのデータ型としてＳｔｒｉｎｇ型を使用し、設定温度及び風量のデータ型としてＮｕｍｂｅｒ型を使用することを定める。

更に、図１０～図１２に、運転状態、風量及び運転モードのデータフォーマットに関する統合ルールＲの例を示す。図１０～図１２の例では、統合ルールＲは、図９と同様に、統合データＳにおけるデータフォーマットを、機器データＢにおけるデータフォーマットに統一することを定めている。

より詳細には、図１０に示すように、機器データＡにおける運転状態の値は、｛ＯＮ，ＯＦＦ，ＴＥＳＴＲＵＮ｝の３状態で表される。これに対して、機器データＢ及び統合データＳにおける運転状態の値は、｛Ｔｒｕｅ，Ｆａｌｓｅ｝の２状態のみで表される。なお、「ＴＥＳＴＲＵＮ」は、運転状態が試運転であることを示す。

このように機器データＡと統合データＳとで状態数が異なるため、図１０に示すように、データＡと統合データＳとの間で状態の合わせ込みを行う。具体的に説明すると、運転状態の統合ルールＲは、データＡにおけるＯＮ，ＯＦＦは、それぞれ統合データＳにおけるＴｒｕｅ，Ｆａｌｓｅに対応すると定める。更に、運転状態の統合ルールＲは、データＡにおけるＴＥＳＴＲＵＮは、統合データＳにおける運転状態がＴｒｕｅに対応し、且つ、運転モードがＴｅｓｔＲｕｎの状態に対応すると定める。

図１１に示すように、機器データＡにおける風量の値は、｛ＬＯＷ，ＭＩＤ１，ＭＩＤ２，ＨＩＧＨ｝の４ステップで表される。これに対して、機器データＢ及び機器データＳにおける風量の値は、１～１０の１０ステップで表される。このように、機器データＡと統合データＳとでステップ数が異なるため、図１１に示すように、統合ルールＲは、機器データＡと統合データＳとの間でステップの合わせ込みを行うことを定めている。

このように情報の粒度が異なるデータの統合ルールＲは、設計者が定める以外にも、以下の（ａ）～（ｄ）の処理のように、データ間のステップ数の差から計算により自動的に定めることができる。
（ａ）以下のように、ソートされた２つのレベルリストを用意する。
機器データＡ［Ｓｔｒｉｎｇ］：ＬＯＷ，ＭＩＤ１，ＭＩＤ２，ＨＩＧＨ
機器データＢ［Ｎｕｍｂｅｒ］：１，２，３，４，５，６，７，８，９，１０
（ｂ）大きいリストの配列数を小さいリストの配列数で割ることで、レンジ幅を決める。
（ｃ）リストにインデックスを振り、小さいリストのインデックス×レンジ幅を計算する。
（ｄ）小数点は四捨五入などして、小さいリストに合わせた大きいリストのインデックス幅を決定する。例では、レンジ幅＝２．５となるので、［３，５，８，１０］が機器データＡの各モードの範囲となる。つまり、ＬＯＷは１－３、ＭＩＤ１は４－５、ＭＩＤ２は６－８、ＨＩＧＨは９－１０に合わせ込まれる。

図１２に示すように、機器データＡにおける運転モードの値は「ＣＯＯＬ」と表される。これに対して、機器データＢ及び統合データＳにおける運転モードの値は「ｃｏｏｌｉｎｇ」と表される。このように、データ型はいずれもＳｔｒｉｎｇ型であるが、値の表現形式が異なる。そのため、統合ルールＲは、運転モードの値について、機器データＡと統合データＳとの間で、Ｓｔｒｉｎｇ値の変換を行うことを定めている。

（３）更新時刻の統合
データ統合部３１２は、機器データＡ～Ｃのうちの第１の機器データに含まれる一の項目の更新時刻と、機器データＡ～Ｃのうちの第２の機器データに含まれるその項目の更新時刻と、が異なる場合、統合データＳにおけるその項目の更新時刻を、統一された更新時刻に設定する。言い換えると、データ統合部３１２は、２以上の機器データに共通して含まれる項目の更新時刻がその２以上の機器データ間で異なる場合、統合データＳにおけるその項目の更新時刻を、１つの時刻に統一する。

図５～図７に示したように、機器データＡ～Ｃのそれぞれは、更新時刻の情報を有する。データ統合部３１２は、統合データＳにおいて、機器データＡ～Ｃのうちのいずれか１つの機器データにのみ含まれる項目の更新時刻を、その機器データにおける更新時刻に設定する。一方で、更新時刻は機器データＡ～Ｃにより異なるため、データ統合部３１２は、統合データＳにおいて、機器データＡ～Ｃのうちの２つ以上の機器データに共通に含まれる項目の更新時刻を、統一された１つの更新時刻に設定する。

より詳細には、データ統合部３１２は、統合データＳにおける一の項目が、機器データＡ～Ｃのうちの２以上の機器データに共通して含まれる場合、統合データＳにおけるその項目の更新時刻を、その２以上の機器データにおけるその項目の更新時刻のうちの最新の更新時刻に設定する。例えば、機器データＡの動的データの更新時刻は、機器データＢの動的データの更新時刻よりも新しい。そのため、データ統合部３１２は、統合データＳにおいて、機器データＡ，Ｂに共通に含まれる運転状態、運転モード、設定温度及び風量の各項目の更新時刻を、機器データＡの更新時刻に設定する。このように更新時刻を１つに統一することで、データの管理をし易くする。

なお、統合前の機器データＡ～Ｃは、統合データＳが生成された後も削除されず、履歴データとして統合データＳとは別にデータ統合装置３０に保存される。これにより、例えば、ユーザ端末５０で使用されているアプリケーションソフトウェアのバージョンが古い場合のように、機器データＡ～Ｃからデータを取得する機能を備えるが、統合データＳからデータを取得する機能を備えない場合であっても対応可能となるため、ユーザの利便性を損なわない。

図４に戻って、ユーザ端末５０において、データ取得部５１１は、通信部５３によりデータ統合装置３０と通信し、データ統合装置３０に格納されている統合データＳ又は機器データＡ～Ｃを取得する。データ取得部５１１は、制御部５１が通信部５３と協働することにより実現される。データ取得部５１１は、データ取得手段の一例である。

ユーザ端末５０には、データ統合装置３０からデータを取得するためのアプリケーションソフトウェアがインストールされている。ユーザは、アプリケーションソフトウェアを起動させ、操作部５４を操作して、統合データＳと機器データＡ～Ｃのうちから取得することを望むデータを選択する。データ取得部５１１は、ユーザにより選択されたデータの要求をデータ統合装置３０に送信する。そして、データ取得部５１１は、要求に対する応答として、統合データＳ又は機器データＡ～Ｃを取得する。

データ統合装置３０において、データ出力部３１３は、ユーザ端末５０のデータ取得部５１１から要求を受け付けると、受け付けた要求に応答して、統合データＳに含まれる少なくとも１つの項目のデータを出力する。具体的に説明すると、データ出力部３１３は、ユーザ端末５０から統合データＳに対する要求を受け付けた場合、統合データＳに含まれる運転状態、運転モード、設定温度等の情報を示す出力データを生成する。

このとき、データ出力部３１３は、例えばデータ統合装置３０に接続された設備機器のリスト一覧が１００件ある場合、５０件ずつの２ページにページングを行い、２ページにわたる出力データを生成する。このように、データ出力部３１３は、統合データＳに格納されているデータを、ユーザが確認し易い形式に変換して、出力データを生成する。

出力データを生成すると、データ出力部３１３は、端末通信部３３ｂを介してユーザ端末５０と通信し、生成した出力データをユーザ端末５０に出力する。データ出力部３１３は、制御部３１が端末通信部３３ｂと協働することにより実現される。データ出力部３１３は、データ出力手段の一例である。ユーザ端末５０において、データ取得部５１１は、データ出力部３１３から出力された出力データを受信すると、受信した出力データを表示部５５に表示する。

更に、データ出力部３１３は、ユーザ端末５０から個別の機器データ、すなわち機器データＡ～Ｃのいずれかのデータに対する要求を受け付けた場合、機器データＡ～Ｃのうちの要求先の機器データに含まれる少なくとも１つの項目のデータを出力する。言い換えると、データ出力部３１３は、統合データＳに格納されているデータを要求された場合、上述のように、統合データＳから出力データを生成し、ユーザ端末５０に出力する。これに対して、データ出力部３１３は、個別の機器データに格納されているデータを要求された場合、統合データＳからではなく、その機器データから出力データを生成し、ユーザ端末５０に出力する。

例えば、ユーザが空調機１０を利用する一般ユーザである場合、ユーザは、空調のオン／オフ、設定温度の変更等のような運転に関連する情報を確認できればよく、点検日、点検結果等の保守管理に関する情報を確認する必要がない。そのため、個別の機器データに格納されているデータを参照できれば、ユーザの要望を満たすことができる。これに対して、ユーザが空調機１０の保守作業員である場合、ユーザは、運転に関連する情報だけではなく、保守管理に関する情報も確認する必要がある。そのため、ユーザは、統合データＳの情報を参照することが必要となる。

このように、空調機１０のユーザの違いによって、必要とする情報が異なる。そのため、データ出力部３１３は、ユーザ端末５０からの要望に応じて、統合データＳと機器データＡ～Ｃとのうちのいずれかに格納されているデータを、ユーザ端末５０に出力する。これにより、機器データＡ～Ｃを個別に参照すれば済む場合に、わざわざ統合データＳを生成する必要がなくなる。

次に、データ統合装置３０により実行されるデータ統合処理の流れについて、図１３に示すフローチャートを参照して説明する。図１３に示すデータ統合処理は、データ統合装置３０が正常に動作可能な状態において、適宜のタイミングで繰り返し実行される。

データ統合処理を開始すると、制御部３１は、室内機１２から通信経路２１～２３のうちのいずれかを経由して機器データから送信された場合、送信された機器データを機器通信部３３ａにより受信する（ステップＳ１１）。

機器データを受信すると、制御部３１は、データ保存部３１１として機能し、受信した機器データを記憶部３２に保存する（ステップＳ１２）。具体的に説明すると、制御部３１は、通信経路２１により受信した機器データを機器データＡとして保存し、通信経路２２により受信した機器データを機器データＢとして保存し、通信経路２３により受信した機器データを機器データＣとして保存する。

機器データを保存した後、統合データＳを生成するタイミングが到来すると、制御部３１は、データ統合部３１２として機能し、機器データＡ～Ｃを統合することにより、統合データＳを生成する（ステップＳ１３）。具体的に説明すると、制御部３１は、統合ルールＲに従って物理プロパティ名、データフォーマット及び更新時刻を統一し、機器データＡ～Ｃを論理和で結合した統合データＳを生成する。

ここで、統合データＳを生成するタイミングは、定期的なタイミング、データ統合装置３０にある程度の量の機器データＡ～Ｃが蓄積されたタイミング、ユーザ端末５０から統合データＳが要求されたタイミング等、適宜のタイミングに設定することができる。

統合データＳを生成すると、制御部３１は、端末通信部３３ｂによりユーザ端末５０からデータの要求を受け付けたか否かを判定する（ステップＳ１４）。ユーザ端末５０からデータの要求を受け付けていない場合（ステップＳ１４；ＮＯ）、制御部３１は、ステップＳ１５のデータ出力処理をスキップし、図１３に示すデータ統合処理を終了する。

これに対して、ユーザ端末５０からデータの要求を受け付けた場合（ステップＳ１４；ＹＥＳ）、制御部３１は、データ出力部３１３として機能し、データ出力処理を実行する（ステップＳ１５）。ステップＳ１５におけるデータ出力処理の詳細は、図１４を参照して説明する。

データ出力処理を開始すると、制御部３１は、ユーザ端末５０から受け付けたデータの要求が、統合データＳに対する要求であるか、それとも個別の機器データに対する要求であるかを判定する（ステップＳ１０１）。

ユーザ端末５０から統合データＳに対する要求を受け付けた場合（ステップＳ１０１；ＹＥＳ）、制御部３１は、統合データＳに含まれる運転状態、運転モード、設定温度等の情報を示す出力データを生成する（ステップＳ１０２）。

一方で、ユーザ端末５０から個別の機器データに対する要求を受け付けた場合（ステップＳ１０１；ＮＯ）、制御部３１は、機器データＡ～Ｃのうちの、要求先の機器データに含まれる運転状態、運転モード、設定温度等の情報を示す出力データを生成する（ステップＳ１０３）。

ステップＳ１０２又はＳ１０３で出力データを生成すると、制御部３１は、端末通信部３３ｂによりユーザ端末５０と通信し、データの要求元であるユーザ端末５０に対して、生成した出力データを出力する（ステップＳ１０４）。以上により、図１４に示したデータ出力処理、及び、図１３に示したデータ統合処理を終了する。

以上説明したように、実施の形態１に係るデータ統合装置３０は、室内機１２ａに関する機器データＡ～Ｃを異なる通信経路２１～２３を経由して受信し、受信した機器データＡ～Ｃを予め定められた統合ルールＲに従って統合して統合データＳを生成する。そして、データ統合装置３０は、第１の機器データに含まれる項目の名称又はデータフォーマットと、第２の機器データに含まれるその項目の名称又はデータフォーマットと、が異なる場合、統合データＳにおけるその項目の名称又はデータフォーマットを、統一された名称又はデータフォーマットに設定する。このように、統合データＳにおける項目の名称及びデータフォーマットを統一された名称及びデータフォーマットに設定することにより、同一の設備機器から送信されたデータが、別の設備機器から送信されたデータとして扱われることを回避することができる。これにより、室内機１２ａから異なる通信経路２１～２３を経由して送信された機器データＡ～Ｃを管理し易くすることができる。その結果として、室内機１２ａを遠隔で管理する効率を高めることにつながる。

（実施の形態２）
次に、本開示の実施の形態２について説明する。実施の形態１と同様の構成及び機能については、適宜説明を省略する。

上記実施の形態１において、データ出力部３１３は、ユーザ端末５０から受け付けた要求に応答して、統合データＳに含まれる少なくとも１つの項目のデータを出力した。これに対して、実施の形態２では、データ出力部３１３は、ユーザ端末５０から統合データＳに対する要求を受け付けた場合、統合データＳに含まれる複数の項目の更新時刻の時間差Δｔを計算する。

ここで、統合データＳに含まれる複数の項目の更新時刻の時間差Δｔは、統合データＳの動的データに含まれる全項目に付与された更新時刻のうちの、最も新しい更新時刻と最も古い更新時刻との差である。具体的に、図８に示した統合データＳの例では、最も古い更新時刻は湿度に付与された「１２／２３ ０：００」であり、最も新しい更新時刻は湿度以外の各項目に付与された「１２／２３ ０：１３」である。この場合、更新時刻の時間差Δｔは１３分となる。このように更新時刻に時間差Δｔが生じる理由は、機器データが送信される通信経路２１～２３の設計思想の違いから、通信経路２１～２３で機器データが送信される送信周期が異なるためである。

データ出力部３１３は、ユーザ端末５０から統合データＳに対する要求を受け付けた場合、統合データＳに含まれる複数の項目の更新時刻の時間差Δｔを計算する。そして、データ出力部３１３は、計算した時間差Δｔが予め定められた時間Ｔよりも小さいか否かを判定する。予め定められた時間Ｔは、例えば１０分、２０分等の適宜の時間に予め設定される。

判定の結果、データ出力部３１３は、更新時刻の時間差Δｔが予め定められた時間Ｔよりも大きい場合、機器通信部３３ａに対して、新たな機器データを取得することを要求する。具体的に説明すると、データ出力部３１３は、統合データＳに含まれる複数の項目のうちの、最も古い更新時刻の項目に対応する機器データを、室内機１２ａから新たに受信するように、機器通信部３３ａに対して要求する。ここで、最も古い更新時刻の項目に対応する機器データは、機器データＡ～Ｃのうちの、その項目のデータの取得元である機器データである。

機器通信部３３ａは、データ出力部３１３の要求に応答して、室内機１２ａに対して、最も古い更新時刻の項目に対応する機器データの送信を要求する。要求を受けた室内機１２ａは、データ統合装置３０に対して新たな機器データを送信する。機器通信部３３ａは、室内機１２ａから送信された新たな機器データを受信する。

データ統合部３１２は、機器通信部３３ａにより新たに受信された機器データに基づいて、統合データＳを更新する。具体的に説明すると、データ統合部３１２は、新たに受信された機器データを含む機器データＡ～Ｃを、統合ルールＲに従って統合することにより、新たな統合データＳを生成する。これにより、更新時刻の時間差Δｔが小さくなった統合データＳが生成される。

なお、機器通信部３３ａは、統合データＳに含まれる複数の項目の更新時刻の中に、最も新しい更新時刻との時間差Δｔが予め定められた時間Ｔよりも大きい更新時刻が複数存在する場合、それら複数の更新時刻の項目に対応する全ての機器データを、室内機１２ａから新たに受信しても良い。これにより、統合データＳを効率的に更新することができる。

以下、図１５を参照して、実施の形態２に係るデータ統合装置３０により実行されるデータ出力処理の流れについて説明する。実施の形態２に係るデータ統合装置３０は、図１３に示すデータ統合処理のステップＳ１５において、実施の形態１で図１４を参照して説明したデータ出力処理に代えて、図１５に示すデータ出力処理を実行する。

データ出力処理を開始すると、制御部３１は、ユーザ端末５０から受け付けたデータの要求が、統合データＳに対する要求であるか、それとも個別の機器データに対する要求であるかを判定する（ステップＳ２０１）。

ユーザ端末５０から統合データＳに対する要求を受け付けた場合（ステップＳ２０１；ＹＥＳ）、制御部３１は、統合データＳの各項目に付与された更新時刻の時間差Δｔを計算する（ステップＳ２０２）。そして、制御部３１は、計算した時間差Δｔが予め定められた時間Ｔよりも小さいか否かを判定する（ステップＳ２０３）。

時間差Δｔが予め定められた時間Ｔよりも大きい場合（ステップＳ２０３；ＮＯ）、制御部３１は、室内機１２ａから機器データを新たに受信する（ステップＳ２０４）。具体的に説明すると、制御部３１は、室内機１２ａに対して、統合データＳに含まれる複数の項目のうちの最も古い更新時刻の項目に対応する機器データの送信を要求し、室内機１２ａから機器データを受信する。

機器データを取得すると、制御部３１は、新たに受信された機器データに基づいて、統合データＳを更新する（ステップＳ２０５）。具体的に説明すると、制御部３１は、新たに受信された機器データを含む機器データＡ～Ｃを、統合ルールＲに従って統合することにより、新たな統合データＳを生成する。

統合データＳを新たに生成すると、制御部３１は、処理をステップＳ２０２に戻し、再び更新時刻の時間差Δｔを計算する。そして、制御部３１は、時間差Δｔが予め定められた時間Ｔよりも小さいか否かを判定する。このように、制御部３１は、時間差Δｔが予め定められた時間Ｔよりも小さくなるまで、ステップＳ２０２～Ｓ２０５の処理を繰り返す。

一方で、ステップＳ２０３で時間差Δｔが予め定められた時間Ｔよりも小さい場合（ステップＳ２０３；ＹＥＳ）、制御部３１は、統合データＳに含まれる運転状態、運転モード、設定温度等の情報を示す出力データを生成する（ステップＳ２０６）。

一方で、ステップＳ２０１において、ユーザ端末５０から個別の機器データに対する要求を受け付けた場合（ステップＳ２０１；ＮＯ）、個別の機器データでは更新時刻が揃っているため、ステップＳ２０２～Ｓ２０５の処理は必要ない。そのため、この場合、制御部３１は、ステップＳ２０２～Ｓ２０５の処理を実行せずに、機器データＡ～Ｃのうちの、要求先の機器データに含まれる運転状態、運転モード、設定温度等の情報を示す出力データを生成する（ステップＳ２０７）。

ステップＳ２０６又はＳ２０７で出力データを生成すると、制御部３１は、端末通信部３３ｂによりユーザ端末５０と通信し、データの要求元であるユーザ端末５０に対して、生成した出力データを出力する（ステップＳ２０８）。以上により、図１５に示したデータ出力処理を終了する。

以上説明したように、実施の形態２に係るデータ統合装置３０は、統合データＳにおける更新時刻の時間差Δｔが予め定められた時間Ｔよりも大きい場合、最も古い更新時刻の項目に対応する機器データを室内機１２ａから新たに受信し、新たに受信された前記機器データに基づいて統合データＳを更新する。このように、統合データＳ内の更新時刻の時間差Δｔを小さくすることにより、ユーザに表示するデータの時刻と実際の時刻の乖離が少なくなり、状態の不一致が起きにくくなる。

（実施の形態３）
次に、本開示の実施の形態３について説明する。実施の形態１，２と同様の構成及び機能については、適宜説明を省略する。

実施の形態１では、データ統合部３１２は、統合データＳにおける一の項目が、２以上の機器データに共通して含まれる場合、統合データＳにおけるその項目の更新時刻を、その２以上の機器データにおけるその項目の更新時刻のうちの最新の更新時刻に設定した。これに対して、実施の形態３では、データ統合部３１２は、統合データＳに設定される更新時刻を調整するために、統合データＳに設定する更新時刻の基準となる個別の機器データＡ～Ｃの更新時刻に対して、尤度となる尤度時間を持たせる。

例えば、機器データＡ，Ｂに共通して含まれる項目の更新時刻が、機器データＡよりも機器データＢの方が後である場合、実施の形態１の統合ルールＲに従うと、統合データＳにおけるその項目の更新時刻として、機器データＢの更新時刻が設定される。これに対して、機器データＡの更新時刻に尤度時間を加えた時刻が、機器データＢの更新時刻よりも後になる場合、データ統合部３１２は、統合データＳの更新時刻として、機器データＡの更新時刻に尤度時間を加えた時刻を設定する。尤度時間は、例えば＋３０分のような時間幅に設定される。

このように、尤度時間を用いて統合データＳに設定される更新時刻を調整することにより、統合データＳに含まれる複数の項目の更新時刻を揃えることができる。複数の項目間で更新時刻がずれていると、統合データＳを出力する際に、項目毎に時刻を出力する必要が生じるため、出力データが複雑になる。実施の形態３では、尤度時間を用いて統合データＳの更新時刻を揃えることで、統一された時刻をユーザに提示することができる。そのため、ユーザにとって確認し易いデータを提供することができる。

（実施の形態４）
次に、本開示の実施の形態４について説明する。実施の形態１～３と同様の構成及び機能については、適宜説明を省略する。

実施の形態４において、データ統合部３１２は、統合データＳが論理的に矛盾するデータを含む場合、そのデータを論理的に矛盾しないデータに修正する。ここで、論理的に矛盾するデータとは、通常では起こり得ない順序、組み合わせ等でプロパティが変化したことを示すデータを意味する。例として、運転状態がオフにもかかわらず設定温度、運転モード等が設定されたことを示すデータ、試運転の最中に風量が設定されたことを示すデータ等が挙げられる。

このような論理的に矛盾するデータは、具体的には、データ統合装置３０で更新時刻を付与する場合において、通信遅延によりデータスワップが発生することに起因して生じる。一例として、０：００に室内機１２ａから機器データＡが送信され、０：０１に室内機１２ａから機器データＢが送信された場合において、機器データＢは０：０１にデータ統合装置３０に到着したが、機器データＡは通信遅延により０：０２にデータ統合装置３０に到着した場合が挙げられる。

データ統合部３１２は、統合データＳに含まれるデータが論理的に矛盾していないかを定期的に判定する。具体的に説明すると、データ統合部３１２は、統合データＳに含まれる複数の項目に付与された更新時刻の前後関係が論理的に矛盾する順序であるか否かを判定する。

判定の結果、データ統合部３１２は、更新時刻の前後関係が矛盾する順序である場合、データ統合部３１２は、関連する項目の更新時刻を、互いに矛盾しない更新時刻に修正する。例えば、データ統合部３１２は、新しく受信された機器データの更新時刻を、それより１つ前に受信された機器データの更新時刻よりも前の時刻に変更する。

統合データＳが論理的に矛盾するデータを含んでいると、統合データＳを分析して異常を検知する場合において、誤って異常が検知される恐れがある。実施の形態４では、データ統合部３１２は、統合データＳに含まれる論理的に矛盾するデータを論理的に矛盾しないデータに修正することにより、誤って異常が検知されることを抑制することができる。

（変形例）
以上、実施の形態を説明したが、各実施の形態を組み合わせたり、各実施の形態を適宜、変形、省略したりすることが可能である。

例えば、上記実施の形態では、データ統合部３１２は、統合ルールＲに従って機器データＡ～Ｃを統合して、統合データＳを生成した。しかしながら、上記は一例であり、データ統合部３１２は、上記で説明した統合ルールＲ以外のルールに従って統合データＳを生成しても良い。

例えば、データ統合部３１２は、統合データＳにおける物理プロパティ名を、機器データＡ～Ｃのいずれとも異なる物理プロパティ名に変換しても良い。また、データ統合部３１２は、機器データＡ～Ｃのうちの２以上の機器データに共通して含まれる項目のデータに使用されている物理量単位が異なる場合、統合データＳにおけるその項目のデータに使用される物理量単位を、統一された１つの物理量単位に設定しても良い。

上記実施の形態では、データ統合部３１２は、統合データＳにおける一の項目が、機器データＡ～Ｃのうちの２以上の機器データに共通して含まれる場合、統合データＳにおけるその項目の更新時刻を、その２以上の機器データにおけるその項目の更新時刻のうちの最新の更新時刻に設定した。しかしながら、データ統合部３１２は、統合データＳにおける一の項目が、機器データＡ～Ｃのうちの２以上の機器データに共通して含まれる場合、統合データＳにおけるその項目の更新時刻を、その２以上の機器データのうちの、室内機１２ａからデータ統合装置３０に送信される送信間隔が最も短い機器データの更新時刻に設定しても良い。この理由は、送信間隔が長い方の更新時刻が最新であっても、通信経路、アプリケーションソフトウェア等によっては機器データの取得時刻が遅い場合があるためである。また、送信間隔が短い機器データは、高い頻度で室内機１２ａからデータ統合装置３０に送信されるため、変化しやすいプロパティを扱っていることが多い。そのため、送信間隔が短い機器データの更新時刻を優先して統合データＳに設定することで、実際の状態との乖離が発生しにくくすることができる。

或いは、データ統合部３１２は、統合データＳにおける一の項目が、機器データＡ～Ｃのうちの２以上の機器データに共通に含まれる場合、統合データＳにおけるその項目の更新時刻を、その２以上の機器データのうちの、その項目の物理プロパティ名が統合データＳに採用された機器データの更新時刻に設定しても良い。言い換えると、物理プロパティ名が採用された機器データは重要である可能性が高いため、更新時刻もその機器データから優先して採用するという方針でも良い。

統合データＳのプロパティに、機器データＡ～Ｃのうちのデータ取得元を示すリンクを付与しても良い。これにより、機器データＡ～Ｃの形式でデータを要求された場合、統合データＳから取得元のデータを辿ってプロパティを取得できる。また、機器データＡ～Ｃは、それぞれ、システムコントローラ１３、アダプタ１５及びリモコン１６のＩＤ、型番、アドレス等のような、送信された通信経路２１～２３が識別可能な情報を有していても良い。

データ統合部３１２は、室内機１２ａから機器データを受信する受信タイミングを過去の受信タイミングから推定し、統合データＳを生成又は更新するタイミングを、推定した受信タイミングに合わせても良い。一般的なパブリッククラウドでは、プログラムの実行時間で課金が生じる。そのため、統合データＳを生成又は更新する処理が、機器データを受信する時間間隔よりも短い時間間隔で実行されると、オーバーヘッドが大きくなり、課金が多くなる。そこで、統合データＳを生成又は更新する処理のタイミングを機器データの受信タイミングに最適化することで、コストを抑えることができる。

上記実施の形態では、データ統合部３１２は、通信経路２１～２３を経由して受信された機器データＡ～Ｃに基づいて、物理プロパティ名とデータフォーマットと更新時刻とのそれぞれが統一された統合データＳを生成した。しかしながら、データ統合部３１２は、統合データＳを生成する際に、名称とデータフォーマットと更新時刻との全てを統一することに限らず、これらのうちの少なくとも１つのみ又は２つのみを統一しても良い。名称とデータフォーマットと更新時刻とのうちのいずれかのみを統一することによっても、同一の設備機器から送信されたデータが、別の設備機器から送信されたデータとして扱われることを回避することができる。そのため、室内機１２ａから異なる通信経路２１～２３を経由して送信された機器データＡ～Ｃを管理し易くすることができる。

上記実施の形態では、データ統合装置３０に対して機器データを送信する設備機器は、室内機１２ａであった。しかしながら、設備機器は、室内機１２ａに限らず、データ統合装置３０に対して２以上の異なる通信経路で機器データを送信する機器であれば、どのような機器であっても良い。例えば、設備機器は、給湯機、照明機器、冷蔵庫、炊飯器等であっても良い。

上記実施の形態では、機器通信部３３ａは、システムコントローラ１３及びゲートウェイ１４を通る第１の通信経路２１と、アダプタ１５を通る第２の通信経路２２と、リモコン１６及び操作端末１７を通る第３の通信経路２３と、を経由して、設備機器の一例である室内機１２ａから機器データを受信した。しかしながら、これら３つの通信経路２１～２３は例示であって、機器通信部３３ａは、これら３つの通信経路２１～２３以外の通信経路を経由して設備機器から機器データを受信しても良い。また、通信経路は３つであることに限らず、機器通信部３３ａが機器データを受信する通信経路は、異なる２以上の通信経路であれば良い。

上記実施の形態では、制御部３１，５１において、ＣＰＵがＲＯＭ又は記憶部３２，５２に記憶されたプログラムを実行することによって、図４に示した各部として機能した。しかしながら、制御部３１，５１は、専用のハードウェアであってもよい。専用のハードウェアとは、例えば単一回路、複合回路、プログラム化されたプロセッサ、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）、又は、これらの組み合わせ等である。制御部３１，５１が専用のハードウェアである場合、各部の機能それぞれを個別のハードウェアで実現してもよいし、各部の機能をまとめて単一のハードウェアで実現してもよい。

また、各部の機能のうち、一部を専用のハードウェアによって実現し、他の一部をソフトウェア又はファームウェアによって実現してもよい。このように、制御部３１，５１は、ハードウェア、ソフトウェア、ファームウェア、又は、これらの組み合わせによって、上述の各機能を実現することができる。

制御部３１，５１の動作を規定するプログラムを、パーソナルコンピュータ、情報端末装置等の既存のコンピュータに適用することで、当該コンピュータを、データ統合装置３０として機能させることも可能である。

また、このようなプログラムの配布方法は任意であり、例えば、ＣＤ－ＲＯＭ（Compact Disk ROM）、ＤＶＤ（Digital Versatile Disk）、ＭＯ（Magneto Optical Disk）、メモリカード等のコンピュータ読み取り可能な記録媒体に格納して配布してもよいし、インターネット等の通信ネットワークを介して配布してもよい。

本開示は、本開示の広義の精神と範囲を逸脱することなく、様々な実施の形態及び変形が可能とされるものである。また、上述した実施の形態は、この開示を説明するためのものであり、本開示の範囲を限定するものではない。すなわち、本開示の範囲は、実施の形態ではなく、特許請求の範囲によって示される。そして特許請求の範囲内及びそれと同等の開示の意義の範囲内で施される様々な変形が、この開示の範囲内とみなされる。

１ 通信システム、１０ 空調機、１１ 室外機、１２ａ，１２ｂ 室内機、１３ システムコントローラ、１４ ゲートウェイ、１５ アダプタ、１６ リモコン、１７ 操作端末、２１，２２，２３ 通信経路、３０ データ統合装置、３１ 制御部、３２ 記憶部、３３ 通信部、３３ａ 機器通信部、３３ｂ 端末通信部、５０ ユーザ端末、５１ 制御部、５２ 記憶部、５３ 通信部、５４ 操作部、５５ 表示部、３１１ データ保存部、３１２ データ統合部、３１３ データ出力部、５１１ データ取得部、Ａ，Ｂ，Ｃ 機器データ、Ｎ１ 広域ネットワーク、Ｎ２ フィールドネットワーク、Ｒ 統合ルール、Ｓ 統合データ

Claims (12)

1. 設備機器に関する第１の機器データを第１の通信経路を経由して受信し、前記設備機器に関する第２の機器データを、前記第１の通信経路とは異なる第２の通信経路を経由して受信する機器通信手段と、
   前記第１の機器データと前記第２の機器データとに共通して含まれる項目を含む統合データを生成するデータ統合手段と、を備え、
   前記データ統合手段は、前記第１の機器データに含まれる前記項目の名称又はデータフォーマットと、前記第２の機器データに含まれる前記項目の名称又はデータフォーマットと、が異なる場合、前記統合データにおける前記項目の名称又はデータフォーマットを、統一された名称又はデータフォーマットに設定する、
   データ統合装置。
2. 前記データ統合手段は、前記第１の機器データに含まれる前記項目の名称と、前記第２の機器データに含まれる前記項目の名称と、が異なる場合、前記統合データにおける前記項目の名称を、統一された名称に設定する、
   請求項１に記載のデータ統合装置。
3. 前記データ統合手段は、前記第１の機器データに含まれる前記項目のデータフォーマットと、前記第２の機器データに含まれる前記項目のデータフォーマットと、が異なる場合、前記統合データにおける前記項目のデータフォーマットを、統一されたデータフォーマットに設定する、
   請求項１又は２に記載のデータ統合装置。
4. 前記データ統合手段は、前記第１の機器データに含まれる前記項目の更新時刻と、前記第２の機器データに含まれる前記項目の更新時刻と、が異なる場合、前記統合データにおける前記項目の更新時刻を、統一された更新時刻に設定する、
   請求項１から３のいずれか１項に記載のデータ統合装置。
5. 前記データ統合手段は、前記統合データにおける前記項目の更新時刻を、前記第１の機器データにおける前記項目の更新時刻と前記第２の機器データにおける前記項目の更新時刻とのうちの最新の更新時刻に設定する、
   請求項４に記載のデータ統合装置。
6. 前記データ統合手段は、前記統合データにおける前記項目の更新時刻を、前記第１の機器データと前記第２の機器データとのうちの、前記設備機器から前記データ統合装置に送信される送信間隔が最も短い機器データに含まれる前記項目の更新時刻に設定する、
   請求項４に記載のデータ統合装置。
7. ユーザ端末から受け付けた要求に応答して、前記統合データに含まれる少なくとも１つの項目のデータを出力するデータ出力手段、を更に備える、
   請求項１から６のいずれか１項に記載のデータ統合装置。
8. 前記データ出力手段は、前記ユーザ端末から前記第１の機器データ又は前記第２の機器データに対する要求を受け付けた場合、前記第１の機器データ又は前記第２の機器データに含まれる少なくとも１つの項目のデータを出力する、
   請求項７に記載のデータ統合装置。
9. 前記機器通信手段は、前記ユーザ端末から前記統合データに対する要求を受け付けた場合であって、且つ、前記統合データに含まれる複数の項目の更新時刻のうちの、最も新しい更新時刻と最も古い更新時刻との時間差が予め定められた時間よりも大きい場合、前記最も古い更新時刻の項目に対応する機器データを、前記設備機器から新たに受信し、
   前記データ統合手段は、前記機器通信手段により新たに受信された前記機器データに基づいて、前記統合データを更新する、
   請求項７又は８に記載のデータ統合装置。
10. 請求項１から９のいずれか１項に記載のデータ統合装置と、前記設備機器と、を備える、
    通信システム。
11. 設備機器に関する第１の機器データを第１の通信経路を経由して受信し、
    前記設備機器に関する第２の機器データを、前記第１の通信経路とは異なる第２の通信経路を経由して受信し、
    前記第１の機器データと前記第２の機器データとに共通して含まれる項目を含む統合データを生成し、
    前記統合データを生成する際、前記第１の機器データに含まれる前記項目の名称又はデータフォーマットと、前記第２の機器データに含まれる前記項目の名称又はデータフォーマットと、が異なる場合、前記統合データにおける前記項目の名称又はデータフォーマットを、統一された名称又はデータフォーマットに設定する、
    統合データの生成方法。
12. コンピュータを、
    設備機器に関する第１の機器データを第１の通信経路を経由して受信し、前記設備機器に関する第２の機器データを、前記第１の通信経路とは異なる第２の通信経路を経由して受信する機器通信手段、
    前記第１の機器データと前記第２の機器データとに共通して含まれる項目を含む統合データを生成するデータ統合手段、として機能させ、
    前記データ統合手段は、前記第１の機器データに含まれる前記項目の名称又はデータフォーマットと、前記第２の機器データに含まれる前記項目の名称又はデータフォーマットと、が異なる場合、前記統合データにおける前記項目の名称又はデータフォーマットを、統一された名称又はデータフォーマットに設定する、
    プログラム。

Images