(57)【特許請求の範囲】
【請求項１】
ＬＯＮＷＯＲＫＳで規定されるＳＮＶＴ形式のデータで通信を行う上位ネットワークと、空調機器やこれに運転指示を与える集中リモコンなどが通信接続された空調システムである下位ネットワークとの間に配置され、これらのネットワークの通信フレームを相互にプロトコル変換すると共に、前記空調システム内の通信フレームをトンネリング処理を用いて前記上位ネットワークと送受信するプロトコル変換器であって、
前記集中リモコンが他の空調システム内の前記空調機器を制御するために前記トンネリング処理を用いて前記上位ネットワークへ送出する通信フレームを識別する下位データ振分手段と、
同下位データ振分手段で識別された前記通信フレームを受け取り、所定の時間内で同一の宛先アドレスを備えた前記通信フレームを連結して１つのＳＮＶＴ形式の通信フレームを生成するトンネリングプロトコル変換手段と、
を備えたことを特徴とするプロトコル変換器。
【請求項２】
ＬＯＮＷＯＲＫＳで規定されるＳＮＶＴ形式のデータで通信を行う上位ネットワークと、空調機器やこれに運転指示を与える集中リモコンなどが通信接続された空調システムである下位ネットワークとの間に配置され、これらのネットワークの通信フレームを相互にプロトコル変換すると共に、前記空調システム内の通信フレームをトンネリング処理を用いて前記上位ネットワークと送受信するプロトコル変換器であって、
前記空調機器が同空調機器の運転状態を示す複数種類からなる監視データを他の空調システムの前記集中リモコンに周期的に通知するために前記トンネリング処理を用いて上位ネットワークへ送出する通信フレームを識別する下位データ振分手段と、
同下位データ振分手段で識別された前記通信フレームを受け取り、複数の前記空調機器の１周期の前記通信フレームをバッファリングし、バッファリングされた前記通信フレームの中から同一種類の前記監視データを抽出して連結し、前記監視データの種類毎に１つのＳＮＶＴ形式の通信フレームを生成するトンネリングプロトコル変換手段と、
を備えたことを特徴とするプロトコル変換器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＬＯＮＷＯＲＫＳ（登録商標）で構築されたビルマネッジメントシステム（以下ＢＭＳと呼称）の上位ネットワークと、このネットワークに接続される複数の下位ネットワークとのプロトコル変換を行うプロトコル変換器に係わり、より詳細には、この下位ネットワーク同士をトンネリング技術を用いて接続する構成に関する。
【背景技術】
【０００２】
従来、例えばインターネットにおいてトンネリング技術を用いたものとして、特許文献１に示すものが開示されている。
図５は、このネットワークのハードウエア構成を示す図である。図５において、９１は端末ＡでＬＡＮ−Ａ９２に接続され、９７は端末ＢでＬＡＮ−Ｂ９６に接続されている。また、前記ＬＡＮ−Ａ９２及びＬＡＮ−Ｂ９６はそれぞれレイヤ２トンネリング装置Ａ９３及びレイヤ２トンネリング装置Ｂ９５に接続され、該レイヤ２トンネリング装置Ａ９３及びレイヤ２トンネリング装置Ｂ９５は、グローバルネットワーク９４にそれぞれ接続されている。なお、グローバルネットワーク９４とは、インターネット等の公衆網である。また、ＬＡＮ−Ａ９２とＬＡＮ−Ｂ９６とはイーサネット（登録商標）である。
【０００３】
図５において、端末Ａ９１の接続されたＬＡＮ−Ａ９２で発生したイーサネットフレームａは、レイヤ２トンネリング装置Ａ９３に取り込まれ、カプセル化ヘッダ及び連結用ヘッダが付加され、新たにカプセル化が行われて、イーサネットフレームｂとしてグローバルネットワーク９４へ送出される。
【０００４】
レイヤ２トンネリング装置Ａ９３から送出されるイーサネットフレームｂのヘッダはレイヤ２トンネリング装置Ｂ９５へ到達するために必要な情報（アドレス）から構成されている。レイヤ２トンネリング装置Ａ９３から送出されたイーサネットフレームｂは、このヘッダを基にして、グローバルネットワーク９４を経由して、レイヤ２トンネリング装置Ｂ９５へ到達する。
【０００５】
レイヤ２トンネリング装置Ｂ９５へ到達したイーサネットフレームｂは、レイヤ２トンネリング装置Ａ９３でのカプセル化によって付加されたヘッダが取り除かれ、イーサネットフレームｃとしてＬＡＮ−Ｂ９６に送出される。ここで、イーサネットフレームａとイーサネットフレームｃは同等なフレームである。
【０００６】
このようにして、ＬＡＮ−Ａ９２内で発生したイーサネットフレームはＬＡＮ−Ｂ９６に伝送され、ＬＡＮ−Ｂ９６で発生したイーサネットフレームもＬＡＮ−Ａ９２に伝送されるので、端末Ａ９１と端末Ｂ９７は、ＬＡＮ−Ａ９２とＬＡＮ−Ｂ９６とが直接接続されているのと同じように相互に通信することができる。
【０００７】
このような使用方法はＢＭＳでも求められており、後から増設した空調システムと、以前からある空調システムとを連動させて、ＢＭＳではできない細かい運用を行いたい場合や、台数制限により複数の空調システムに分割されたシステムを統合的に管理したいという要望があった。
【０００８】
しかしながら、前述した従来技術はイーサネットで使用されるものであるが、この方式をＬＯＮＷＯＲＫＳで構築されたビルマネッジメントシステムに応用する場合に通信の制限が発生し、接続される台数が減少してしまうという問題があった。
【０００９】
この原因はＬＯＮＷＯＲＫＳで規定されている標準ネットワーク変数：ＳＮＶＴ（Standard Network Variable Type）を用いた場合のネットワーク変数の数の制限にある。ＳＮＶＴでは、上位レベル（ビル全体の集中管理装置など）が、下位レベル（室内機など）の機器の操作や監視を統一された操作で行うために、標準化された機能が規定されている。この標準化された機能がネットワーク変数であり、これを実現するための仕組み、例えば通信フレームの規定などがＳＮＶＴである。上位ネットワークの機器や機能と、下位ネットワークの機器や機能とは４０９６個のネットワーク変数が使用可能である。
【００１０】
例えば集中管理装置から、ある室内機を制御する場合、運転オン／オフに１個、運転モード指定に１個、設定温度に１個などである。従って１台の室内機に２０種類の制御や監視の項目を割り当てると、４０９６／２０＝２０４台の室内機しか制御できない。また、同じ項目数でトンネリング処理を行うと、通常の割当項目とトンネリング用の項目数との合計のネットワーク変数が必要になり、結果的に制御可能な台数が半減してしまうため実用的でなかった。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特開２００３−６９６４２号公報（第３−４頁、図１）
【発明の概要】
【発明が解決しようとする課題】
【００１２】
本発明は以上述べた問題点を解決し、ＬＯＮＷＯＲＫＳを使用したビルマネッジメントシステムにおいて、トンネリング処理で必要とするネットワーク変数を必要最小限にすることで、トンネリング処理を用いる場合でも接続可能な機器の台数をできる限り多くするプロトコル変換器を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明は上述の課題を解決するため、ＬＯＮＷＯＲＫＳで規定されるＳＮＶＴ形式のデータで通信を行う上位ネットワークと、空調機器やこれに運転指示を与える集中リモコンなどが通信接続された空調システムである下位ネットワークとの間に配置され、これらのネットワークの通信フレームを相互にプロトコル変換すると共に、前記空調システム内の通信フレームをトンネリング処理を用いて前記上位ネットワークと送受信するプロトコル変換器であって、
前記集中リモコンが他の空調システム内の前記空調機器を制御するために前記トンネリング処理を用いて前記上位ネットワークへ送出する通信フレームを識別する下位データ振分手段と、
同下位データ振分手段で識別された前記通信フレームを受け取り、所定の時間内で同一の宛先アドレスを備えた前記通信フレームを連結して１つのＳＮＶＴ形式の通信フレームを生成するトンネリングプロトコル変換手段とを備えたことを特徴とする。
【００１４】
また、ＬＯＮＷＯＲＫＳで規定されるＳＮＶＴ形式のデータで通信を行う上位ネットワークと、空調機器やこれに運転指示を与える集中リモコンなどが通信接続された空調システムである下位ネットワークとの間に配置され、これらのネットワークの通信フレームを相互にプロトコル変換すると共に、前記空調システム内の通信フレームをトンネリング処理を用いて前記上位ネットワークと送受信するプロトコル変換器であって、
前記空調機器が同空調機器の運転状態を示す複数種類からなる監視データを他の空調システムの前記集中リモコンに周期的に通知するために前記トンネリング処理を用いて上位ネットワークへ送出する通信フレームを識別する下位データ振分手段と、
同下位データ振分手段で識別された前記通信フレームを受け取り、複数の前記空調機器の１周期の前記通信フレームをバッファリングし、バッファリングされた前記通信フレームの中から同一種類の前記監視データを抽出して連結し、前記監視データの種類毎に１つのＳＮＶＴ形式の通信フレームを生成するトンネリングプロトコル変換手段とを備えたことを特徴とする。
【発明の効果】
【００１５】
以上の手段を用いることにより、本発明によるプロトコル変換器によれば、
請求項１に係わる発明は、所定の時間内に同一宛先アドレスに送出される下位ネットワークの通信フレームをまとめるため、宛先毎に使用されるネットワーク変数の数を削減することができる。
【００１６】
請求項２に係わる発明は、複数の宛先アドレス毎にまとめられている監視データを、同一種類の監視データ毎に１つのＳＮＶＴ形式のデータにまとめるため、宛先毎に使用されるネットワーク変数の数を削減することができる。
【図面の簡単な説明】
【００１７】
【図１】本発明によるプロトコル変換器を用いたビルマネッジメントシステムの実施例を示すシステム図である。
【図２】本発明によるプロトコル変換器を示すブロック図である。
【図３】上位ネットワークで使用されるネットワークフレームを示す説明図である。
【図４】下位ネットワークでのデータとこれを上位ネットワーク用のデータに変換する過程を説明する説明図である。
【図５】従来のトンネリング処理を説明するシステム図である。
【発明を実施するための形態】
【００１８】
以下、本発明の実施の形態を、添付図面に基づいた実施例として詳細に説明する。
【実施例１】
【００１９】
図１は本発明によるプロトコル変換器を用いたビルマネッジメントシステム（ＢＭＳ）の実施例を示すシステム図である。
このＢＭＳはビル全体の制御を総合的に管理する集中管理装置１（Subnet:0,Node:1 ）と、この集中管理装置１にＬＯＮＷＯＲＫＳで規定されているＳＮＶＴを用いた上位ネットワークを介して接続される電力システム２（Subnet:1,Node:1 ）、防犯システム３（Subnet:2,Node:1 ）、防災システム４（Subnet:3,Node:1 ）、空調システム７（Subnet:4,Node:1 ）、空調システム８（Subnet:5,Node:1 ）とがそれぞれ接続されている。なお、カッコ内のSubnetやNodeは上位ネットワーク内の機器やこれに接続される各システムを識別する番号である。これらについては後で詳細に記述する。
【００２０】
そして、空調システム７には、室外機７０（アドレス：＃０）、室内機７１（アドレス：＃１）、室内機７２（アドレス：＃２）・・・室内機７３（アドレス：＃２００）が、ＬＯＮＷＯＲＫＳを用いた下位ネットワークとして接続されている。また、この下位ネットワークと上位ネットワークとのプロトコル変換を行うプロトコル変換器５がそれぞれのネットワーク間に接続されている。なお、下位ネットワークには２０１台の機器が接続されているため、リピータ（中継機）が必要であるが、本実施例と関連がないため、図示と説明を省略する。なお、カッコ内のアドレス値は各空調システム内の機器を識別する番号である。これらについては後で詳細に記述する。
【００２１】
また、同様に空調システム８には、室外機８０（アドレス：＃３００）、室内機８１（アドレス：＃３０１）、室内機８２（アドレス：＃３０２）、室内機８３（アドレス：＃５００）、集中リモコン８４（アドレス：＃６００）が、ＬＯＮＷＯＲＫＳを用いた下位ネットワークとして接続されている。また、この下位ネットワークと上位ネットワークとのプロトコル変換を行うプロトコル変換器６がそれぞれのネットワーク間に接続されている。なお、前述のようにリピータの図示と説明を省略する。
【００２２】
本実施例のシステムでは、プロトコル変換器５及び６がトンネリング処理を行って各下位ネットワーク内のデータを相互に送受信することができる。この場合、集中管理装置１はこの処理に一切係わらない。このため、集中リモコン８４からの指示により、空調システム７内の各機器を制御したり、集中リモコン８４を用いて空調システム７内の各機器の監視を行うことができる。
【００２３】
図２はプロトコル変換器５のブロック図である。なお、プロトコル変換器６も同じ構成であるためプロトコル変換器６の説明は省略する。
プロトコル変換器５は、下位ネットワークに接続され、空調システム内の各機器が送信する通信データを受信する下位データ受信部１５と、この下位データ受信部１５で受信したデータを分析し、通常のプロトコル変換かトンネリング処理を行うプロトコル変換かを振り分ける下位データ振分部１４（下位データ振分手段）と、トンネリング処理を行うトンネリングプロトコル変換部１２（トンネリングプロトコル変換手段）と、通常のプロトコル変換を行う通常プロトコル変換部１３と、それぞれプロトコル変換されたデータを上位ネットワークに送信する上位データ送信部１１とを備えている。
【００２４】
また、プロトコル変換器５は、上位ネットワークから空調システム内の各室内機へ送信される通信データを受信する上位データ受信部１６と、この上位データ受信部１６で受信したデータを分析し、通常のプロトコル変換かトンネリング処理を行うプロトコル変換かを振り分ける上位データ振分部１７（上位データ振分手段）と、トンネリング処理を行うトンネリングプロトコル変換部１８（トンネリングプロトコル変換手段）と、通常のプロトコル変換を行う通常プロトコル変換部１９と、それぞれプロトコル変換されたデータを下位ネットワークに送信する下位データ送信部２０とを備えている。
【００２５】
このプロトコル変換器５では、上位ネットワークと下位ネットワークとのそれぞれのデータを相互にプロトコル変換する。また、プロトコル変換器５は、下位ネットワーク内に存在しないアドレスのデータを受信した場合や、トンネリング用として用意された上位ネットワークのデータを受信した場合、後述するトンネリング処理を実施する。
【００２６】
なお、図２は機能ブロック図であり、これらの各部の機能がハードウェアを用いて実現されてもよいし、図示しないマイコンなどのハードウェアとこのマイコン動作を指示するソフトウェアとを用いて各部が手段として実現されてもよい。
【００２７】
図３は上位ネットワークで使用されるネットワークフレームを説明する説明図である。
このフレームはＬＯＮＷＯＲＫＳで使用されるＬＯＮＴＡＬＫ（登録商標）の詳細を示している。物理レイヤを示すＰＰＤＵ（Physical Protocol Data Unit ）、リンクレイヤを示すＬＰＤＵ／ＭＰＤＵ（Link/MAC Protocol Data Unit ）、ネットワークレイヤを示すＮＰＤＵ（Network Protocol Data Unit）、トランスポートレイヤを示すＴＰＤＵ（Transport Protocol Data Unit, or message/ack）、アプリケーションレイヤを示すＡＰＤＵ（Application Protocol Data Unit）で構成されている。各レイヤの機能については、国際標準機構のＯＳＩ（オープンシステムインターコネクション）で規定されており、各レイヤの構造はＬＯＮＴＡＬＫの通信プロトコルで決定されているため、本実施例では本発明固有のデータ部分についてのみ説明する。
【００２８】
このネットワークフレームでは、送信元アドレス（ノード、サブネット）や送信先アドレス（ドメイン、サブネット）が指定できるようになっている。なお、本実施例のシステムではドメインの区別はない。サブネットとノードに関しては前述の通りである。
【００２９】
また、ＡＰＤＵでは『Selector』と『Data』とを使用する。『Selector』は使用するネットワーク変数と対応するものであり、この値によって、『Data』で示される値の意味が識別される。『Data』の内容については、各アプリケーションで規定されていればよい。本実施例ではこのアプリケーション用データとして２種類の通信フレームを用いる。
【００３０】
１つはトンネリング処理を行う場合であり、『Selector』で規定された各種のデータを配置する。『Selector』の規定はバインド作業により予め設定されるデータである。例えば、３２０１〜３４００は室内機８１〜室内機８３の制御データ（合計２００台分）を示している。また、３４０１は監視データ『運転』、３４０２は監視データ『運転モード』、・・・３４０８は監視データ『風量』を識別するものである。このような割当は上位ネットワーク上に接続された機器で行われている。
【００３１】
もう１つは通常の場合であり、『Selector』で規定されたネットワーク変数と対応するデータを配置する。例えば、０〜３１９９までを通常のプロトコル変換で使用する。このように２００台の室内機に対して制御と監視でそれぞれ８種類のネットワーク変数が割り当てられる。従って『Selector』は２００×（８＋８）＝３２００のネットワーク変数を指定する。なお、通常の場合とは、下位ネットワーク内の各室内機と上位ネットワーク内の集中管理装置１との間で、集中管理装置１から各室内機に対する制御の指示と、各室内機から集中管理装置１への監視（各室内機の状態）の報告とを行うことを示す。これに対し、トンネリングの場合は集中管理装置１とのデータの送受信は行わず、特定のネットワーク、この実施例では空調システム７と空調システム８との間のみでデータを送受信する。
【００３２】
なお、本実施例において『制御』の指示とは、例えば、ある室内機の運転オンや温度の設定、運転モードの指定などであり、『監視』の報告とは、ある室内機の運転オン／オフの状態や設定された温度、運転中の運転モード、現在の風量などである。
【００３３】
図４は本発明による（Ａ）制御データの流れと（Ｂ）監視データの流れを説明する説明図である。なお前提条件として本実施例で使用するネットワーク変数の数について説明する。この実施例では２つの空調システムにおいて各２００台の室内機が接続され、各室内機は運転オン、運転モード、設定温度・・・風量などで合計８種類の制御項目と、これらに対応する８種類の監視項目とを用いる。
【００３４】
前述のようにＬＯＮＷＯＲＫＳでは、１つのサブネット毎に４０９６のネットワーク変数が使用でき、１つのアドレス（１つの機器）の１つの制御項目、又は監視項目につき、１つのネットワーク変数が割り当てられる。従って、例えば空調システム７の各機器が集中管理装置１との間で通信する通常のプロトコル変換においては、２００台×（制御：８＋監視：８）で３２００個のネットワーク変数を使用する。使用可能なネットワーク変数は４０９６個であるため、残は８９６個である。もし、本発明を用いないでトンネリング処理を行うと通常のプロトコル変換と同じ数のネットワーク変数が別途必要となる。これは合計６４００個であり、実現不可能である。本発明では、データの宛先やデータ内容に着目し、データの集約、分割をプロトコル変換器で行うことで、トンネリング処理で使用するネットワーク変数の数を残８９６個以内に収めるようにしている。
【００３５】
まず最初に図４（Ａ）制御データの流れについて説明する。図４（Ａ）では、左から右に向かって、集中リモコン８４での操作、下位ネットワーク側の通信データ、上位ネットワーク側の通信データをそれぞれ記載している。
まず、集中リモコン８４を用いて、室内機７１（アドレス：＃１）に対して運転オン、運転モードを暖房運転、設定温度を２８℃、・・・風量を『大』にする８種類の操作を行った場合を説明する。
【００３６】
これらのデータは前述のネットワーク変数の規定により、１つの宛先に１つの制御項目を１通信フレームにしなければならないため、下位ネットワークの通信フレームに従って、送信元アドレス：＃６００、宛先アドレス：＃１、制御、運転オンのフレームが集中リモコン８４から送信される。同様に連続して順次、『暖房運転』、『設定温度』・・・『風量  大』の合計８つのフレームが送信される。これらは、制御項目毎に１個の通信フレームが使用される。
【００３７】
図２のプロトコル変換器６ではこれらのデータを下位データ受信部１５が受け取り、下位データ振分部１４へ引き渡す。下位データ振分部１４では引き渡されたデータの宛先アドレスを確認し、自分以外のネットワーク宛のアドレスか確認する。つまり、プロトコル変換器６では、予め内部に記憶している下位ネットワークの各機器のアドレステーブルを参照して確認する。
空調システム８内のプロトコル変換器６は＃３００〜＃５００、＃６００が割当られてアドレステーブルに記憶されているため、受け取ったデータの宛先アドレスが＃１であれば、他のネットワークである空調システム７宛のデータであると判断する。なお、３つ以上の空調システムが存在する場合は、他の空調システムのアドレステーブルを記憶しておいてもよい。他のネットワークへの送信はトンネリング処理の対象であり、この対象データは時間管理を行い、例えば１分以内の同一宛先ごとにバッファリングを行い、１分以内の同一宛先の制御データをまとめて、トンネリングプロトコル変換部１２に引き渡す。
【００３８】
一方、自分のネットワーク内宛のアドレスであればデータを無視する。ただし、自分のネットワーク内宛のアドレスであっても、制御／監視項目が『監視』の場合は集中管理装置１や集中リモコン８４へ送信するデータであるため、集中管理装置１用として通常プロトコル変換部１３へ受け取ったデータを引き渡す。通常プロトコル変換部１３は受け取ったデータを上位ネットワークで規定されたＳＮＶＴのデータにプロトコル変換し、上位データ送信部１１を介して上位ネットワークの通信ラインへ出力する。
【００３９】
一方、トンネリングプロトコル変換部１２は、受け取った複数のデータをトンネリング用の通信フレームにプロトコル変換する。具体的には、図４（Ａ）に示す上位ネットワーク側の通信データに記載しているように、宛先毎に１個のネットワーク変数を使用する。前述したように、ネットワークフレームの送信元Subnet:5,Node:1 、送信先のSubnet:4, ドメインは『０』にし、Selectorを３２０１、つまり、室内機７１の制御データにする。
【００４０】
続いてアプリケーションデータを配置する。アプリケーションデータの最初に、運転オン、暖房運転、設定温度２８℃、・・・風量『大』の８つのデータを順次格納する。これらは同一宛先、同一のデータ種別でかつ所定時間内（１分以内）に送信されたデータである。なお、ここに配置される８つのデータは、送信元、送信先のアドレスを含む下位ネットワーク側の通信データをそのまま連結して配置する。
【００４１】
図２のトンネリングプロトコル変換部１２は、このようにしてプロトコル変換したデータを上位データ送信部１１を介して上位ネットワークの通信ラインへ出力する。
【００４２】
次に図４（Ｂ）を用いて監視データの流れを説明する。図４（Ｂ）の（１）に示すように空調システム７の下位ネットワーク側の通信データは、送信元アドレス：＃１、宛先アドレス：＃６００、データの識別が監視のデータに続き、運転オフ、運転モードが冷房、・・・・風量『小』が配置されており、このデータが１つの室内機から例えば１２０秒間で１周期となる定期通信データとして周期的に送信されている。空調システム７の室内機は合計２００台あるため、１２０秒間で２００個の通信フレームが送信される。なお、各室内機からは他の室内機の送信と時間的に間隔を開けて送信される。
【００４３】
図２のプロトコル変換器６（プロトコル変換器５も同じ機能）ではこれらのデータを下位データ受信部１５が受け取って１２０秒間、つまり、全室内機の監視データをバッファリングし、下位データ振分部１４へまとめて引き渡す。下位データ振分部１４では引き渡されたデータ識別が『監視』である場合、トンネリングプロトコル変換部１２と通常プロトコル変換部１３とに同じデータを引き渡す。
【００４４】
トンネリングプロトコル変換部１２では図４（Ｂ）（２）上位ネットワーク側の通信データに示すようにプロトコル変換を行う。変換された通信フレームにおいて、ネットワークフレームの送信元Subnet: ４,Node:1 、送信先のSubnet: ５, ドメインは『０』にし、Selectorを３４０１、つまり、監視データ『運転』にする。これは集中リモコン８４に監視データを送るためである。なお、前述したように下位データ受信部１５は、監視データであれば無条件に通常プロトコル変換部を介して集中管理装置１に監視データを送出するようになっている。つまり、監視データは集中管理装置１と集中リモコン８４との両方の機器に送出される。他の監視項目も同様である。
【００４５】
次に、監視項目、つまり、運転オン／オフや運転モード、設定温度、・・・風量毎に各室内機の監視データを各室内機のアドレス順に並べる。この例では、室内機アドレス：＃１〜＃２００の順である。従って、通信フレームとしては、監視項目の数、つまり、８種類だけとなる。これはネットワーク変数が８個で済むことを意味している。
また、下位ネットワークに接続される室内機の台数が多い場合は、これに従って通信フレームも長くなる。従って室内機の台数が多い場合は、１つの監視項目の監視データの数を区切って、つまり、室内機アドレス：＃１〜＃１００、＃１０１〜＃２００等のように区切り、この区切ったデータをそれぞれ１つの通信フレームとして生成すればよい。このように２つに区切った場合、ネットワーク変数の数も２つに増加する。
【００４６】
一方、監視項目別に生成された各通信フレーム内の各監視データは、同じフォーマットで配置されており、例えば風量の場合は送信元アドレス：＃２００、送信先アドレス：＃６００、データの種別：監視、監視データ：風量『大』となっている。従って、上位ネットワーク側の通信データを逆に分解して下位ネットワーク側へ送信する場合、このアドレスをキーにして監視データをソートすることで容易に下位ネットワーク側の通信データに変換することができる。
前述したように上位ネットワーク側の通信データに変換された通信フレームは、上位データ送信部１１を介して上位ネットワークの通信ラインへ出力する。
【００４７】
一方、通常プロトコル変換部１３では、１つの宛先毎に１つの監視データとなるようにフレームを分解し、これを上位ネットワークのＳＮＶＴの規定に従ってプロトコル変換する。つまり、１つの監視項目と１つの宛先に対して１つのネットワーク変数を割当ることになる。そして変換された通信フレームは、上位データ送信部１１を介して上位ネットワークの通信ラインへ出力する。
【００４８】
以上説明したように、本発明によるトンネリング処理を行った場合、１つのサブネット内の合計２００台の室内機に対して、データ種別が制御の通信フレームが２００個、さらに、データ種別が監視の通信フレームが８個（監視項目）で合計２０８個のネットワーク変数を使用する。前述したように、通常のプロトコル変換で使用した残りのネットワーク変数が８９６個であるため、本発明によるトンネリング処理を行ってもネットワーク変数が不足することはない。
【００４９】
次に図２を用いて上位ネットワーク側の通信フレームを下位ネットワーク側の通信フレームに変換する処理を説明する。基本的には下位ネットワーク側の通信フレームを上位ネットワーク側の通信フレームに変換する処理の逆の手順となる。
【００５０】
上位データ受信部１６は、上位ネットワーク側から通信フレームを受け取ると、上位データ振分部１７にこのデータを引き渡す。上位データ振分部１７では、『Selector』の値を確認し、トンネリングデータか通常のデータかを判別し、トンネリングデータならばトンネリングプロトコル変換部１８に、通常のデータであれば通常プロトコル変換部１９に、それぞれデータを引き渡す。
【００５１】
トンネリングプロトコル変換部１８では、『Selector』の値によってデータの識別を確認し、『制御』であれば、アプリケーション用データの領域を制御項目毎にデータを区切って分解する。前述のようにこの部分は下位ネットワーク側のフレームを順次連結しただけであるため、分解したデータをそのまま下位データ送信部２０に引き渡す。
【００５２】
トンネリングプロトコル変換部１８ではデータの識別が『監視』であれば、各監視データに対応する８個の通信フレームをバッファリングし、このデータが揃った段階で各監視データの宛先アドレスをキーにして監視データをソートし、さらに、監視データの項目の順番を揃えて下位ネットワーク側の通信データを作成する。そしてこのデータをまとめて下位データ送信部２０に引き渡す。下位データ送信部２０では、監視データを受け取った場合、下位ネットワークに対して宛先アドレスの小さい順に所定間隔で順次送信を行う。
【００５３】
通常プロトコル変換部１９では受け取ったデータをＳＮＶＴの規約に従って下位ネットワーク側のフレームにプロトコル変換し、下位データ送信部２０に引き渡す。下位データ送信部２０では、受け取ったデータを下位ネットワークに対して送信する。
【００５４】
以上説明したように、本発明によるプロトコル変換器は、所定の時間内に同一宛先アドレスに送出される下位ネットワークの通信フレームをまとめるため、宛先毎に使用されるネットワーク変数の数を削減することができる。
【００５５】
また、複数の宛先アドレス毎にまとめられている監視データを、同一種類の監視データ毎に１つのＳＮＶＴ形式のデータにまとめるため、宛先毎に使用されるネットワーク変数の数を削減することができる。また、プロトコル変換器間の通信のみにトンネリングしたデータを用いるので、通信処理が単純化され、通信関係のトラブルを低減させることができる。
【００５６】
図４のトンネリングデータの作成において、同一室内機の制御データをまとめて１つの通信フレームとして生成する方法や、監視データの項目毎にデータをまとめて複数の室内機のデータを１つの通信フレームとして生成する方法を説明しているが、これに限るものでなく、同一室内機の監視データをまとめて１つの通信フレームとして生成する方法や、制御データの項目毎にデータをまとめて複数の室内機のデータを１つの通信フレームとして生成する方法にしてもよい。
【符号の説明】
【００５７】
１  集中管理装置
２  電力システム
３  防犯システム
４  防災システム
５  プロトコル変換器
６  プロトコル変換器
７  空調システム
８  空調システム
１１  上位データ送信部
１２  トンネリングプロトコル変換部（トンネリングプロトコル変換手段）
１３  通常プロトコル変換部
１４  下位データ振分部（下位データ振分手段）
１５  下位データ受信部
１６  上位データ受信部
１７  上位データ振分部（上位データ振分手段）
１８  トンネリングプロトコル変換部（トンネリングプロトコル変換手段）
１９  通常プロトコル変換部
２０  下位データ送信部
７０、８０  室外機
７１、７２、７３、８１、８２、８３、  室内機
８４  集中リモコン
【図１】
0005459133.tif 000002
【図２】
0005459133.tif 000003
【図３】
0005459133.tif 000004
【図４】
0005459133.tif 000005
【図５】
0005459133.tif 000006