JP5127528B2 - ゲートウェイ装置、制御命令処理方法及びプログラム - Google Patents

ゲートウェイ装置、制御命令処理方法及びプログラム Download PDF

Info

Publication number
JP5127528B2
JP5127528B2 JP2008081012A JP2008081012A JP5127528B2 JP 5127528 B2 JP5127528 B2 JP 5127528B2 JP 2008081012 A JP2008081012 A JP 2008081012A JP 2008081012 A JP2008081012 A JP 2008081012A JP 5127528 B2 JP5127528 B2 JP 5127528B2
Authority
JP
Japan
Prior art keywords
control command
control
query
translator
aggregator
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2008081012A
Other languages
English (en)
Other versions
JP2009239478A (ja
Inventor
雄 金子
智則 前川
裕介 土井
政浩 石山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2008081012A priority Critical patent/JP5127528B2/ja
Priority to US12/407,855 priority patent/US7984135B2/en
Publication of JP2009239478A publication Critical patent/JP2009239478A/ja
Application granted granted Critical
Publication of JP5127528B2 publication Critical patent/JP5127528B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/566—Grouping or aggregating service requests, e.g. for unified processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer Security & Cryptography (AREA)
  • Selective Calling Equipment (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、ゲートウェイ装置、制御命令処理方法及びプログラムに関する。
近年、ビルや工場における制御系のネットワークであるファシリティネットワークのＩＰ化が進んでいる。ＩＰ化されたファシリティネットワークにおいて、人々はＩＰネットワークを介して例えば照明や空調などの設備機器を制御することができる。例えば、ＰＣのＷｅｂブラウザに表示された照明の画像をクリックすることで、簡単に照明のＯＮ／ＯＦＦ制御を行うことができる。
一般的に、ＰＣから送信された設備機器に対する制御命令は、ゲートウェイとＩＰコントローラを介する。ゲートウェイは、制御系とＯＡ系のネットワークの境界に位置し、制御権限の確認やプロトコル変換を行う。ＩＰコントローラは、ＩＰネットワークの終端に位置し、ゲートウェイから送られてきた制御命令を処理して、設備機器を制御する。
ＩＰ化されたファシリティネットワークでは、従来よりも簡単に、また複数人が同時に制御を行うことが可能となる（特許文献１参照）。
したがって、ＩＰ化されたファシリティネットワークでは、ＩＰコントローラの処理性能を超えた数の制御命令が発生する可能性がある。この場合、ＩＰコントローラは全ての制御命令を処理できず、パケットロスなどが発生する。また、設備機器に対して無駄な制御を行う可能性がある。例えば、空調が暖房運転を開始するための準備運転を行っているときに、暖房運転を開始する制御を何度も行うことは、設備機器やＩＰコントローラにとって余分な負荷となる。
特開２００６−１２９２８２号公報
従来、制御命令の数が増加した場合に、ＩＰコントローラが処理可能な制御命令の数を超えてしまい或いは設備機器にとって無駄な制御を行ってしまうなどの問題があった。
本発明は、上記事情を考慮してなされたもので、制御命令の数が増加した場合であってもＩＰコントローラの制御命令の処理負荷を軽減することを可能にするゲートウェイ装置、制御命令処理方法及びプログラムを提供することを目的とする。
本発明は、一つ以上の設備機器に対する制御命令を実行するための一つ以上のコントローラが接続される第１のネットワークと、制御命令を送信する一つ以上のクライアントが接続される第２のネットワークとの境界に位置し、制御命令をプロトコル変換するためのトランスレータと、制御命令を集約するための一つ以上のアグリゲータとを備えたゲートウェイ装置であって、前記トランスレータは、各々の前記コントローラについて、当該コントローラの負荷に関する情報である負荷情報を収集するための収集部と、前記第２のネットワークを介して前記クライアントから所望の設備機器に対する制御命令を受信するための制御命令受信部と、前記制御命令が受信された場合に、該制御命令が対象とする設備機器に対応するコントローラの前記負荷情報に基づいて、該制御命令を集約の対象にするか否か判定するための判定部と、集約の対象にすると判定された場合に、前記制御命令を、該制御命令に対応する前記アグリゲータに転送するための第１の転送部と、前記アグリゲータから集約済み制御命令の転送を受けるための第２の転送部とを含み、前記アグリゲータは、前記トランスレータから前記制御命令の転送を受けるための第３の転送部と、複数の前記制御命令を、一つの集約済み制御命令に集約するための集約部と、前記集約済み制御命令令を前記トランスレータに転送するための第４の転送部とを含むことを特徴とする。
なお、装置に係る本発明は方法に係る発明としても成立し、方法に係る本発明は装置に係る発明としても成立する。
また、装置または方法に係る本発明は、コンピュータに当該発明に相当する手順を実行させるための（あるいはコンピュータを当該発明に相当する手段として機能させるための、あるいはコンピュータに当該発明に相当する機能を実現させるための）プログラムとしても成立し、該プログラムを記録したコンピュータ読み取り可能な記録媒体としても成立する。
本発明によれば、制御命令の数が増加した場合であってもＩＰコントローラの制御命令の処理負荷を軽減することが可能になる。
以下、図面を参照しながら本発明の実施形態について説明する。
以下、「クエリ」は制御命令を、「ユーザ」はクエリを送信する者を、「デバイス」は照明や空調などの設備機器をそれぞれ示すものとする。
（第１の実施形態）
第1の実施形態では、ゲートウェイがＩＰコントローラの負荷を考慮してクエリの集約を行う場合を例にとって説明する。
図１に、本実施形態で想定するネットワーク（例えば、ファシリティネットワーク）の構成例を示す。図１に示されるように、このネットワークは、ゲートウェイ１、クライアント２、ＩＰコントローラ３、デバイス４を含んでいる。
ゲートウェイ１は、制御系ネットワークとＯＡ系ネットワークとの境界に位置し、制御権限の確認やプロトコル変換などを行う点は、従来と同様であるが、これに加えて、本実施形態では、クエリの集約を行う。
クライアント２は、所望のデバイス４に対するクエリを送信する機能を有する端末であり、ＯＡ系ネットワーク側に接続される。クライアント２は、任意台数存在して構わない。
デバイス４は、制御系ネットワーク側に接続され、例えば照明や空調などの設備機器であり、制御系ネットワーク側に接続される。デバイス４は、任意台数存在して構わない。
ＩＰコントローラ３は、デバイス４を制御するための装置であり、制御系ネットワーク側に接続される。ＩＰコントローラ３は、個々のデバイス４に対応して一つずつ設けられても良いし、一纏まりのデバイス４に対応して一つずつ設けられても良いし、全てのデバイス４に対応して一つのみ設けられても良い。なお、一纏まりのデバイス４に対応して一つずつ設けられる形態には、例えば、デバイスの種別を基準にしてグルーピングされたグループごとに設けられる形態（例えば同一種別のデバイスごとに設けられる形態）、デバイスが設置される場所を基準にしてグルーピングされたグループごとに設けられる形態（例えばビルの同一フロア又はテナントに設置されたデバイスごとに設けられる形態）、それらの組み合わせなど、種々の形態が考えられる。
ここでは、ゲートウェイ１は、１台存在するものとして説明するが、ゲートウェイ１が複数台存在する構成も可能である。
図１において、クライアント２は、例えばユーザの操作などに基づいて、制御対象とするデバイス２を管理するＩＰコントローラ３を宛先とするクエリを送信する。クライアント２から送信されたクエリは、まず、ゲートウェイ１に到達し、ゲートウェイ１は、クエリを受信すると、制御権限の確認やプロトコル変換などを行う。その際、本実施形態では、ゲートウェイ１は、集約すべき条件を満たすクエリについては、その集約を行う。そして、ゲートウェイ１は、集約処理されたクエリ又は集約処理の対象外の単独のクエリを、宛先となるＩＰコントローラ３に向けて送信する。ＩＰネットワークの終端に位置するＩＰコントローラ３は、ゲートウェイ１からクエリを受信すると、これを処理して、制御対象となるデバイス４を制御する。
本実施形態では、クライアント２は、デバイス４のプロパティに任意の値を設定するというクエリを発信する場合を例にとって説明する。
図２に、この場合のクエリが持つ情報を例示する。
図２に示すクエリは、当該クエリを所有するユーザの識別情報である「ユーザＩＤ」、制御対象となるデバイスの識別情報である「デバイスＩＤ」、当該クエリの識別情報である「命令ＩＤ」、該デバイスが持つプロパティの名前である「プロパティ名」、該プロパティに設定する値である「設定値」を含む。例えば、空調に対する温度設定、照明に対する照度設定、ブラインドに対する開閉設定などを行う際に発生するクエリが、図２のクエリにあたる。
第1の実施形態では、図２のようなクエリを集約の対象とする。空調や照明の制御結果は、複数のユーザに反映されるが、個々のユーザのクエリを逐次的に処理して制御を行うだけでは、例えば、最後にクエリを送信したユーザの意図のみが反映されてしまう、といった不具合が生ずる。したがって、ゲートウェイ１において、例えば、複数ユーザから受信したクエリの持つ設定値を集約して、１つのクエリとしてＩＰコントローラ３に送信するような集約処理を行うことで、複数ユーザの意図を反映した制御を行いつつ、ＩＰコントローラ３の負荷を抑えることができる。
なお、図１において、クライアント２からゲートウェイ１に転送されるクエリは、クライアント２とゲートウェイ１との間で使用するプロトコルに従うものであり、ゲートウェイ１からＩＰコントローラ３に与えられるクエリは、ゲートウェイ１とＩＰコントローラ３との間で使用するプロトコルに従うものであり、それらプロトコルは異なるものであることを想定しているので、ゲートウェイ１は、クライアント２から受信したクエリをプロトコル変換する機能（図３等のプロトコル変換部２７参照）を有する。すなわち、クエリは、ゲートウェイ１においてプロトコル変換されて、ＩＰコントローラ３に与えられる。
次に、図３に、本実施形態に係るゲートウェイ１の構成例を示す。
図３に示されるように、ゲートウェイ１は、トランスレータ１１とアグリゲータ１２とを備える。トランスレータ１１とアグリゲータ１２は、例えば、ゲートウェイ１上で動作するプロセス（すなわち、そのもととなるプログラム）としても実現可能である。
トランスレータ１１は、ユーザから受信したクエリに対してプロトコル変換処理を行い、ＩＰコントローラ３に転送するためのものである。ただし、トランスレータ１１は、ＩＰコントローラ３の負荷を把握しており、ＩＰコントローラ３の負荷が高い場合には、アグリゲータ１２にクエリを転送し、アグリゲータ１２から集約されたクエリを受けて、これをＩＰコントローラ３に転送する。
アグリゲータ１２は、トランスレータ１１から受信したクエリを集約し、集約したクエリをトランスレータ１１に返す。本実施形態では、１つのアグリゲータ１２は、特定のデバイス４に対する特定の命令を集約する場合を例にとって説明する。アグリゲータ１２は、管理者によって設定された数だけ存在する。なお、図３には、一つのアグリゲータ１２のみ例示している。
以下、アグリゲータ１２によって集約された集約済みクエリのことを「集約クエリ」と呼ぶ。集約クエリが持つ情報は、一般のクエリと同じである。
図３に示されるように、本実施形態のトランスレータ１１は、クエリ受信部２１、クエリ転送部３４、クエリ送信部２８、集約クエリ受信部３５、負荷情報受信部３１、エラー送信部２３、クエリ受理通知部３０の７つの送受信部を有し、これらの各機能ブロックによって他プロセスや他マシンとのデータ交換を行う。
また、トランスレータ１１は、デバイスデータベース（デバイスＤＢ）７１、ＩＰコントローラデータベース（ＩＰコントローラＤＢ）７２、アグリゲータデータベース（アグリゲータＤＢ）７３の３つのＤＢを有する。ＤＢの情報の設定は、ビルや工場の管理者が行うのが一般的であるが、これに制限されるものではない。
次に、図４に、デバイスＤＢ７１の属性の例を示す。
図４の例において、デバイスＤＢ７１は、｛デバイスＩＤ，ＩＰコントローラＩＤ，テナントＩＤ，ユーザＩＤ，命令ＩＤ｝の５属性から構成され、主キーはデバイスＩＤである。デバイスＩＤごとに、当該デバイスを管理するＩＰコントローラの識別情報である「ＩＰコントローラＩＤ」、当該デバイスが設置してあるテナントの識別情報である「テナントＩＤ」、当該デバイスを制御可能なユーザの「ユーザＩＤ」、当該デバイスに対して実行可能な命令の「命令ＩＤ」が設定されている。
実行可能な命令には、例えば、デバイスが空調機器であれば、温度設定命令、冷房運転開始命令、暖房運転開始命令などがある。
次に、図５に、ＩＰコントローラＤＢ７２の属性の例を示す。
図５の例において、ＩＰコントローラＤＢ７２は、｛ＩＰコントローラＩＤ，通信用情報，負荷，閾値Ｔ１，閾値Ｔ２｝の５属性から構成され、主キーはＩＰコントローラＩＤである。ＩＰコントローラごとに、当該ＩＰコントローラへクエリを転送する際に使用する情報である「通信用情報」、当該ＩＰコントローラの負荷を表す指標である「負荷」、２つの閾値「閾値Ｔ１」「閾値Ｔ２」が設定されている。
通信用情報は、ゲートウェイ１とＩＰコントローラとの間で使用するプロトコルに依存する。例えば、ＢＡＣｎｅｔ／ＩＰを使用する場合はＩＰアドレスとなり、ＳＯＡＰを使用する場合はＵＲＩとなる。本実施形態では、ＢＡＣｎｅｔ／ＩＰを使用する場合を例にとって説明する。
負荷を表す指標には、例えば、ＩＰコントローラのＣＰＵの使用率、ＩＰコントローラのＣＰＵのアイドル状態率、ＩＰコントローラが過去一定時間に受信したクエリ数などがあり、いずれの指標を用いることも可能である。本実施形態では、ＩＰコントローラのＣＰＵ使用率を指標とする場合を例にとって説明する。
なお、図５の例では、閾値属性の数は２つであるが、これに制限されるものではない。本実施形態では、負荷状況に応じて３通りの処理を行う場合を例にとって説明するため、閾値属性の数が２つであるものを例示している。
次に、図６に、アグリゲータＤＢ７３の属性の例を示す。
図６の例において、アグリゲータＤＢ７３は、｛アグリゲータＩＤ，デバイスＩＤ，命令ＩＤ，通信用情報｝の４属性から構成され、主キーはアグリゲータＩＤである。アグリゲータごとに、当該アグリゲータが集約するクエリが持つべき、制御対象となるデバイスの「デバイスＩＤ」及び該デバイスに対する「命令ＩＤ」、当該アグリゲータへクエリを転送する際に使用する情報である「通信用情報」が設定されている。
本実施形態では、アグリゲータ１２は、デバイスＩＤと命令ＩＤとの組み合わせにより特定される。
通信用情報は、トランスレータとアグリゲータとの間の通信方法に依存する。例えば、ソケットを使用する場合はポート番号となり、ＵＮＩＸ（登録商標）のｐｉｐｅを使用する場合はファイルディスクリプタとなる。本実施形態では、ソケットを用いる場合を例にとって説明する。
また、図３に示されるように、トランスレータ１１は、制御権限確認部２２、負荷判断部２５、プロトコル変換部２７、アグリゲータ選択部３３、情報更新部３２を有する。これらの各機能ブロックは、上記の３つのＤＢを参照し、動作する。
前述のように本実施形態のアグリゲータ１２は管理者によって設定された数だけ存在し、各々のアグリゲータ１２ごとに、図３に示されるように、クエリ受信部５１、状態確認部５３、クエリ挿入部５４、タイマー部５５、クエリ集約部５６、集約クエリ送信部５７、プロパティ情報８１、クエリキュー８２を有する。
次に、図７に、プロパティ情報８１の内容の例を示す。
図７の例において、プロパティ情報８１には、「クエリを集約する期間情報」、「集約アルゴリズム」、「通信用情報」、「状態情報」が含まれる。管理者は、プロパティ情報８１を設定することで、アグリゲータ１２を設定する。
クエリを集約する期間情報とは、例えば、１０秒や１００秒などの時間である。
集約アルゴリズムには、「平均値」、「中間値」、「無作為にクエリを選択」、「最後に受信したクエリを選択」などがあり、管理者が運用ポリシーなどを考慮して選択する。集約の対象となるクエリは、あるデバイスに任意の値を設定するというクエリであるため、管理者は、集約の期間を設定し、規定の集約アルゴリズムを選択するだけで、アグリゲータ１２を設定できる。
通信用情報は、トランスレータ１１とアグリゲータ１２との間の通信方法に依存する。例えば、ソケットを使用する場合はポート番号となり、ＵＮＩＸのｐｉｐｅを使用する場合はファイルディスクリプタとなる。本実施形態では、ソケットを用いる場合を例にとって説明する。
状態情報は、アグリゲータ１２がクエリの集約を実行中であるか又は実行中でないかを表す情報である。
次に、図３及び図８等を参照しながら、ユーザからのクエリ受信時のトランスレータ１１の動作について説明する。図８は、ユーザからのクエリ受信時のトランスレータ１１の動作例を示すフローチャートである。
トランスレータ１１は、クエリ受信部２１によって、ユーザが送信したクエリを受信すると（ステップＳ１）、制御権限確認部２２によって、デバイスＤＢ７１を参照する（ステップＳ２）。クエリには、ユーザＩＤ、制御対象となるデバイスＩＤ、デバイスに対して行う制御命令の命令ＩＤが含まれている。クエリに含まれるデバイスＩＤをキーとしてデバイスＤＢ７１を参照することで、当該デバイスを管理するＩＰコントローラＩＤと、当該デバイスを制御する権限を持つユーザＩＤ、当該デバイスに対して実行可能な命令ＩＤを取得する。
クエリが持つユーザＩＤと命令ＩＤが、取得したユーザＩＤと命令ＩＤに含まれない場合は（ステップＳ３）、制御する権限がないと判断し、エラー送信部２３によって、クエリ送信者にエラーを返す（ステップＳ１４）。
制御する権限があると判断した場合は（ステップＳ３）、クエリに当該デバイスを管理するＩＰコントローラＩＤ情報を付加し（ステップＳ４）、負荷判断部２５によって、ＩＰコントローラＤＢ７２を参照する（ステップＳ５）。
ここで、図９に、ＩＰコントローラＩＤ情報を付加されたクエリが持つ情報の例を示す。
負荷判断部２５は、クエリに付加されたＩＰコントローラＩＤをキーとしてＩＰコントローラＤＢ７２を参照することで、当該ＩＰコントローラの負荷と、閾値（本例では二つの閾値）を取得する。なお、ここでは、閾値Ｔ２＞閾値Ｔ１とする。
負荷が閾値Ｔ２よりも大きい場合は（ステップＳ６）、当該ＩＰコントローラはクエリを処理不可能な状態であると判断し、エラー送信部２３によって、ユーザ（すなわち、当該クエリの送信元であるクライアント２）にエラーを送信する（ステップＳ１４）。この場合、受信したクエリは、破棄される。
負荷が閾値Ｔ２以下であり（ステップＳ６）、さらに閾値Ｔ１以下である場合は（ステップＳ７）、プロトコル変換部２７によって、クエリに対してプロトコル変換処理を行い（ステップＳ８）、クエリ送信部２８によって、当該ＩＰコントローラにクエリを送信する（ステップＳ９）。そして、クエリ受理通知部３０によって、ユーザにクエリを受理したことを通知する（ステップＳ１０）。当該ＩＰコントローラのＩＰアドレスは、ＩＰコントローラＩＤをキーとしてＩＰコントローラＤＢ７２を参照することで決定する。
負荷が閾値Ｔ２以下であり且つ閾値Ｔ１よりも大きい場合は（ステップＳ６，Ｓ７）、アグリゲータ選択部３３によって、アグリゲータＤＢ７３を参照する（ステップＳ１１）。
アグリゲータ選択部３３は、アグリゲータＤＢ７３を参照し、クエリに付加されたデバイスＩＤと命令ＩＤとの両方が一致するアグリゲータＩＤを探す。適切なアグリゲータＩＤが見つからなかった場合（ステップＳ１２）、クエリの集約は不可能と判断し、エラー送信部２３によって、ユーザにエラーを送信する（ステップＳ１４）。適切なアグリゲータＩＤが見つかった場合（ステップＳ１２）、クエリ転送部３４によって、アグリゲータ１２にクエリを転送する（ステップＳ１３）。そして、クエリ受理通知部３０によって、ユーザにクエリを受理したことを通知する（ステップＳ１０）。アグリゲータ１２にクエリを転送する際に必要な情報（ポート番号）は、アグリゲータＩＤをキーとしてアグリゲータＤＢ７３を参照することで取得する。
次に、図３及び図１０等を参照しながら、クエリ受信時のアグリゲータ１２の動作について説明する。図１０は、クエリ受信時のアグリゲータ１２の動作例を示すフローチャートである。
アグリゲータ１２は、クエリ受信部５１によって、トランスレータ１１からクエリを受信すると（ステップＳ２１）、状態確認部５３によって、プロパティ情報８１の状態情報を参照する（ステップＳ２２）。
状態が実行中である場合は（ステップＳ２３）、クエリ集約部５６によって、受信したクエリをクエリキュー８２に挿入する（ステップＳ２４）。
状態が実行中でない場合は（ステップＳ２３）、プロパティ情報８１の状態情報を実行中に変更し（ステップＳ２６）、クエリ集約部５６によって、受信したクエリをクエリキュー８２に挿入する（ステップＳ２４）。その際、タイマー部５５によって期間情報を参照し、タイマーをセットする（ステップＳ２５）。タイマーは、例えば、アグリゲータ１２のプロセスにアラームシグナルを設定することで実現できる。
次に、図３及び図１１等を参照しながら、タイマーが切れた時のアグリゲータ１２の動作について説明する。図１１は、タイマーが切れた時のアグリゲータ１２の動作例を示すフローチャートである。
タイマーが切れると（ステップＳ３１）、アグリゲータ１２は、クエリ集約部５６によって、クエリキュー８２から蓄積されたクエリ群を取得し、プロパティ情報８１の集約アルゴリズムに従ってクエリを集約する（ステップＳ３２）。
例えば、集約アルゴリズムが「平均」であれば、クエリ群の各値の平均値を計算し、その値を設定値とする集約クエリを生成する。集約アルゴリズムが「中間値」であれば、クエリ群の中間値を計算し、その値を設定値とする集約クエリを生成する。集約アルゴリズムが「無作為」であれば、クエリ群の中から無作為に１つのクエリを選択し、そのクエリを集約クエリとする。集約アルゴリズムが「最後に受信したクエリを選択」であれば、キューの最後尾のクエリを集約クエリとする。
クエリの集約が終了した後、プロパティ情報８１の状態情報を停止中に変更し（ステップＳ３３）、集約クエリ送信部５７によって、トランスレータ１１に集約クエリを送信する（ステップＳ３４）。トランスレータ１１との通信に必要な情報は、プロパティ情報８１の通信用情報を参照することで取得する。
ところで、上記では、集約を実行する基準にタイマーを用いたが、集約を実行する基準はタイマーだけに限らない。その他にも、例えば、ＩＰコントローラの負荷がある閾値を下回ったときに集約を実行する方法や、一定数のクエリを受信したときに集約を実行する方法など、種々の方法が考えられる。この場合は、プロパティ情報には期間情報の代わりとなる情報を設定すれば良い。
次に、図３及び図１２等を参照しながら、アグリゲータ１２からの集約クエリ受信時のトランスレータ１１の動作について説明する。図１２は、アグリゲータ１２からの集約クエリ受信時のトランスレータ１１の動作例を示すフローチャートである。
トランスレータ１１は、集約クエリ受信部３５によって、アグリゲータ１２から集約クエリを受信すると（ステップＳ４１）、プロトコル変換部２７によって、集約クエリに対してプロトコル変換処理を行う（ステップＳ４２）。その後、クエリ送信部２８によって、ＩＰコントローラに集約クエリを送信する（ステップＳ４３）。当該ＩＰコントローラのＩＰアドレスは、ＩＰコントローラＩＤをキーとしてＩＰコントローラＤＢ７２を参照することで決定する。
次に、図３及び図１３等を参照しながら、ＩＰコントローラからの負荷情報受信時のトランスレータ１１の動作について説明する。図１３は、ＩＰコントローラからの負荷情報受信時のトランスレータ１１の動作例を示すフローチャートである。
トランスレータ１１は、負荷情報受信部３１によって、ＩＰコントローラから負荷情報を受信すると（ステップＳ５１）、負荷情報更新部３２によって、ＩＰコントローラＤＢ７２を参照し、「負荷」の値を更新する（ステップＳ５２）。
ここで、図１４に、ＩＰコントローラから受信する負荷情報の内容の例を示す。負荷情報に含まれるＩＰコントローラＩＤを使用することで、負荷情報を更新するべきエントリを決定する。
このように、本実施形態のゲートウェイによれば、ＩＰコントローラの負荷を把握し、負荷が高い場合には「あるデバイスのプロパティに任意の値を設定する」というクエリを集約することで、複数ユーザの意図を反映した制御を行いながら、ＩＰコントローラのクエリ処理負荷を軽減することが可能となる。
なお、集約の対象とするクエリは、あるデバイスに任意の値を設定するという制御命令であるため、管理者は、集約期間と集約アルゴリズムを設定するだけで、アグリゲータ１２を設定できる。集約アルゴリズムには「平均」や「中間値」などの既定の数値計算アルゴリズムがあり、管理者は、アルゴリズムを選択することで、柔軟なクエリ集約を行うことができる。
また、アグリゲータ１２は、ゲートウェイ１上のプロセスでなくとも良い。例えば、ゲートウェイ１とは別のマシン上で動作するＷｅｂサービスプロセスであっても良い。その場合、アグリゲータＤＢ７３の通信用情報には、アグリゲータ１２のクエリ受信サービスのＵＲＩが格納される。また、アグリゲータ１２が持つ通信用情報には、ゲートウェイ１のＩＰアドレスとポート番号が格納される。
以上説明してきたように、本実施形態によれば、ゲートウェイにおいてクエリを集約することで、ＩＰコントローラやデバイスのクエリの処理負荷を軽減することが可能になる。
また、本実施形態によれば、ゲートウェイにおいてＩＰコントローラやデバイスの状態を把握し、状態に応じてクエリの集約を行うことで、複数ユーザの意図を反映した制御を行いつつ、ＩＰコントローラやデバイスの処理負荷を軽減することが可能となる。
（第２の実施形態）
第２の実施形態では、第１の実施形態におけるゲートウェイがクエリの集約を行う際に、クエリの優先度を考慮する動作例について説明する。以下、第１の実施形態と相違する点を中心に説明する。
ファシリティネットワークにおいてクエリの優先度を考慮する場合、ユーザの権限と、ユーザとデバイスが所属するテナントの２点を考慮できる。一般的に、ファシリティネットワークには、管理者権限を持つ管理者と、一般権限しか持たない一般ユーザとが存在する。ビルの管理者からのクエリを一般ユーザよりも優先することは妥当な処理だと言える。また、あるテナントに存在するデバイスに対して、複数のテナントに所属するユーザがクエリを送信した場合に、デバイスと同じテナントに所属するユーザのクエリを優先することは、妥当な処理であると言える。本実施形態では、上記２点の指標を用いて、クエリの優先度を高中低の３段階に分類する例について説明する。
図１５に、本実施形態に係るゲートウェイの構成例を示す。第１の実施形態と相違する点は、トランスレータ１１が、第１の実施形態（図３）の構成に加えて、ユーザデータベース（ユーザＤＢ）７４と優先度判断部２４とを備える点である。
図１６に、ユーザＤＢ７４の属性情報の例を示す。
ユーザＤＢ７４は、｛ユーザＩＤ，ユーザ権限，テナントＩＤ｝の３属性から構成され、主キーはユーザＩＤである。ユーザＩＤごとに、当該ユーザの権限を示す「ユーザ権限」、当該ユーザが所属しているテナントの「テナントＩＤ」が設定されている。
ユーザ権限には、管理者権限や一般ユーザ権限がある。
優先度判断部２４は、クエリが持つユーザＩＤをキーとしてユーザＤＢ７４を参照することで、クエリ送信者の権限を把握する。また、ユーザＤＢ７４とデバイスＤＢ７１を併せて参照することで、クエリ送信者が所属するテナントと制御対象デバイスが存在するテナントとが等しいかどうかを判断できる。
次に、図１５及び図１７等を参照しながら、ユーザからのクエリ受信時のトランスレータ１１の動作について説明する。図１７は、本実施形態のトランスレータ１１の、ユーザからのクエリ受信時の動作例を示すフローチャートである。
なお、図１７の手順におけるステップＳ６１〜Ｓ６４は、それぞれ、図８の手順におけるステップＳ１〜Ｓ４と同じである。また、図１７の手順におけるステップＳ７２〜Ｓ８１は、それぞれ、図８の手順におけるステップＳ５〜Ｓ１４と同じである。
トランスレータ１１は、クエリ受信部２１によって、ユーザからクエリを受信すると（ステップＳ６１）、制御権限確認部２２によって、ユーザの制御権限を確認する（ステップＳ６２）。
ユーザ（すなわち、当該クエリの送信元であるクライアント２）にデバイスの制御権限がある場合（ステップＳ６３）、クエリに当該デバイスを管理するＩＰコントローラＩＤ情報を付加し（ステップＳ６４）、優先度判断部２４によって、クエリの優先度を判断する（ステップＳ６５）。優先度判断部２４は、クエリが持つユーザＩＤをキーとしてユーザＤＢ７４を参照し、クエリ送信ユーザの権限を確認する。
クエリ送信ユーザが管理者権限を持っている場合は（ステップＳ６６）、クエリに優先度＝高という情報を付加する（ステップＳ６７）。
クエリ送信ユーザが管理者権限を持っていない場合は（ステップＳ６６）、ユーザＤＢ７４とデバイスＤＢ７１を併せて参照し、クエリ送信ユーザと制御対象デバイスのテナントＩＤが等しいかどうかを確認する（ステップＳ６８）。テナントＩＤが等しければ（ステップＳ６９）、クエリに優先度＝中の情報を付加し（ステップＳ７０）、テナントＩＤが等しくなければ（ステップＳ６９）、クエリに優先度＝低の情報を付加する（ステップＳ７１）。
ここで、図１８に、優先度情報が付加されたクエリの例を示す。
クエリに優先度情報を付加した後の処理は、第１の実施形態におけるトランスレータ１１の動作と同じである。負荷判断部２５によってＩＰコントローラの負荷状況を判断し、ユーザにエラーを返すか、クエリに対してプロトコル変換処理を行うか、適切なアグリゲータ１２にクエリを渡すか、のいずれかの処理を行う。
次に、図１５及び図１１等を参照しながら、タイマーが切れた時のアグリゲータ１２の動作例について説明する。なお、本実施形態のアグリゲータ１２の、タイマーが切れた時の動作例は、第１の実施形態（図１１）と同様であるが、ステップＳ３２の集約において優先度を考慮する点が第１の実施形態と相違している。
タイマーが切れると（ステップＳ３１）、アグリゲータ１２は、クエリ集約部５６によって、クエリキュー８２から蓄積されたクエリ群を取得し、プロパティ情報８１の集約アルゴリズムに従ってクエリを集約する（ステップＳ３２）。
ここで、本実施形態における集約アルゴリズムは、クエリの優先度情報を考慮した計算を行う。例えば、集約アルゴリズムが、「平均」、「中間値」又は「無作為」である場合に、ｗ３＞ｗ２＞ｗ１（例えば、ｗ３＝３、ｗ２＝２、ｗ１＝１）として、優先度＝高である１個のクエリは、クエリｗ３個分、優先度＝中である１つのクエリは、クエリｗ２個分、優先度＝低である１つのクエリは、クエリｗ１個分にして、集約値を計算する。
このようにすることで、優先度が低いクエリよりも、優先度が高いクエリが持つ設定値を、集約結果により反映させることができる。
クエリの集約が終了した後、プロパティ情報８１の状態情報を停止中に変更し（ステップＳ３３）、集約クエリ送信部５７によって、トランスレータ１１に集約クエリを送信する（ステップＳ３４）。トランスレータ１１との通信に必要な情報は、プロパティ情報８１の通信用情報を参照することで取得する。
このように、本実施形態のゲートウェイによれば、ユーザの権限や所属に応じてクエリに優先度を設定し、優先度を考慮してクエリを集約することで、管理者や、同じテナントに属するユーザの意図を優先的に反映した制御を行いながら、ＩＰコントローラのクエリ処理負荷を軽減することが可能となる。
（第３の実施形態）
第３の実施形態では、第２の実施形態におけるゲートウェイがクエリの集約を行う際に、「はずれ値」を除外して集約する動作例について説明する。なお、以下では、第２の実施形態と相違する点を中心に説明するが、第１の実施形態に本実施形態の「ゲートウェイがクエリの集約を行う際に、はずれ値を除外して集約する構成」を適用することも、もちろん可能である。
ファシリティネットワークにおいて、例えば、一部のユーザが操作ミス或いは興味本位などで、明らかに許容範囲から外れた設定値を持つクエリを送信し、そのクエリがアグリゲータ１２に集約された場合、多くのユーザの意図を反映しない集約結果になる可能性がある。例えば、空調に対して、一部のユーザがマイナス５度という設定を行おうとしてクエリを送信し、アグリゲータ１２がそのクエリを含めて平均値を計算することは、望ましくない。よって、空調が許容できない値は、集約対象から除外するのが望ましい。
ここで、図１９に、本実施形態におけるプロパティ情報８１の例を示す。本実施形態におけるアグリゲータ１２のプロパティ情報８１は、これまでの実施形態（図７）の「集約期間」、「集約アルゴリズム」、「通信用情報」、「状態情報」に加えて、「最大値」及び「最小値」の情報を含む。
アグリゲータ１２は、最大値と最小値を参照することで、はずれ値を含むクエリを集約対象から除外する。はずれ値であるということは、設定値が、最大値よりも大きいか又は最小値よりも小さいということである。
図２０に、本実施形態のゲートウェイの構成例を示す。第２の実施形態と相違する点は、アグリゲータ１２が、第２の実施形態（図１５）の構成に加えて、はずれ値判断部５２を備える点である。
次に、図２０及び図２１等を参照しながら、トランスレータ１１からのクエリ受信時のアグリゲータ１２の動作例について説明する。図２１は、本実施形態のアグリゲータ１２の、トランスレータ１１からのクエリ受信時の動作例を示すフローチャートである。
アグリゲータ１２は、クエリ受信部５１によって、トランスレータ１１からクエリを受信すると（ステップＳ９１）、はずれ値判断部５２によって、クエリがもつ設定値がはずれ値かどうかを判断する（ステップＳ９２）。はずれ値判断部５２は、プロパティ情報８１の最大値と最小値を参照し、クエリが持つ設定値が最大値よりも大きいか、最小値よりも小さい場合は、はずれ値であると判断する。
はずれ値である場合は（ステップＳ９３）、クエリを破棄する（ステップＳ９４）。
はずれ値でない場合は（ステップＳ９３）、状態確認部５３によって、アグリゲータ１２の実行状態を確認する（ステップＳ９５）。
状態が実行中であれば（ステップＳ９６）、クエリ集約部５６によって、受信したクエリをクエリキュー８２に挿入する（ステップＳ９７）。
状態が実行中でなければ（ステップＳ９６）、プロパティ情報８１の状態情報を実行中に変更し（ステップＳ９９）、クエリ集約部５６によって、受信したクエリをクエリキュー８２に挿入する（ステップＳ９８）。その際、タイマー部５５によって期間情報を参照し、タイマーをセットする（ステップＳ９８）。
このように、本実施形態のゲートウェイによれば、はずれ値を除外してクエリを集約することで、設定値を任意の範囲に限定した制御を行いながら、ＩＰコントローラのクエリ処理負荷を軽減することが可能となる。
（第４の実施形態）
第４の実施形態では、第３の実施形態におけるゲートウェイが、ＩＰコントローラからの制御結果を受信した後に、ユーザ（すなわち、当該クエリの送信元であるクライアント２）にクエリ受理通知を行う場合の動作例について説明する。以下、第３の実施形態と相違する点を中心に説明するが、第１又は第２の実施形態に本実施形態の「ゲートウェイが、ＩＰコントローラからの制御結果を受信した後に、ユーザにクエリ受理通知を行う構成」を適用することも、もちろん可能である。
ファシリティネットワークにおいて、例えば、あるデバイスのプロパティに任意の値を設定する際に、値を設定するだけでなく、確認のためにデバイスに設定された値を返信して欲しい場合がある。このような、あるデバイスのプロパティに任意の値を設定し、かつ、実際にデバイスに設定された値を返すことを要求するクエリのことを、readbackクエリと呼び、例えばＢＡＣｎｅｔ／ＩＰなどのプロトコルで定義されている。
第３の実施形態までのゲートウェイは、ＩＰコントローラにクエリを転送する前に、ユーザに、実際の制御結果の情報を含まないクエリ受理通知を返すが、readbackクエリを受信した場合、ゲートウェイは、ＩＰコントローラにクエリを転送した後、ＩＰコントローラから制御結果通知が送られてくるまで待機し、制御結果通知を受信してから、ユーザに制御結果を含めたクエリ受理通知を返すと好ましい。例えば、あるユーザが空調の運転温度を２８度に設定すると、ユーザには実際に空調に設定された運転温度が返される。ただし、クエリの集約を行った場合、ユーザが設定した値と、ユーザに返される制御結果の値が異なる場合がある。
図２２に、本実施形態のゲートウェイの構成例を示す。第３の実施形態と相違する点は、トランスレータ１１が、第３の実施形態（図２０）の構成に加えて、制御結果受信部２９を備える点である。
トランスレータ１１は、クエリ送信部２８によって、ＩＰコントローラにクエリを送信した後、ＩＰコントローラからの制御結果通知を待ち、制御結果受信部２９によって、制御結果を受信する。
次に、図２２及び図２３等を参照しながら、ユーザからのクエリ受信時のトランスレータ１１の動作例について説明する。図２３は、本実施形態のトランスレータ１１の、ユーザからのクエリ受信時の動作例を示すフローチャートである。
なお、図２３の手順におけるステップＳ１０１は、図１７の手順におけるステップＳ６１と同じである。また、図２３の手順におけるステップＳ１０３〜Ｓ１１７は、それぞれ、図１７の手順におけるステップＳ６２〜Ｓ７６と同じである。また、図２３の手順におけるステップＳ１１９〜Ｓ１２３は、それぞれ、図１７の手順におけるステップＳ７７〜Ｓ８１と同じである。
トランスレータ１１は、クエリ受信部２１によって、ユーザからクエリを受信すると（ステップＳ１０１）、クエリに通信用情報を付加する（ステップＳ１０２）。
ここで、図２４に、ＩＰコントローラＩＤ及び優先度情報並びに通信用情報が付加されたクエリの例を示す。
この通信用情報とは、後にユーザにクエリ受理通知を返すための情報であり、例えば、ユーザのＩＰアドレスとポート番号のセットが該当する。通信用情報は、例えば、Ｕｎｉｘのソケット機能を利用することで求めることができる。
負荷判断部２５によって、ＩＰコントローラの負荷が閾値Ｔ２以下であり（ステップＳ１１４）、さらに閾値Ｔ１以下である場合は（ステップＳ１１５）、プロトコル変換部２７によって、クエリのプロトコル変換を行い（ステップＳ１１６）、クエリ送信部２８によって、ＩＰコントローラにクエリを送信する（ステップＳ１１７）。その後、制御結果受信部２９によって、ＩＰコントローラから制御結果を受信し（ステップＳ１１８）、クエリ受理通知部３０によって、ユーザに制御結果を返す（ステップＳ１１９）。
ＩＰコントローラの負荷が閾値Ｔ２以下であり且つ閾値Ｔ１より大きい場合は（ステップＳ１１４，Ｓ１１５）、アグリゲータ選択部３３によって、適切なアグリゲータ１２を選択し（ステップＳ１２０）、適切なアグリゲータＩＤが見つかれば（ステップＳ１２１）、クエリ転送部３４によって、アグリゲータ１２にクエリを転送する（ステップＳ１２２）。
本実施形態におけるアグリゲータ１２は、クエリ集約部５６によってクエリを集約する際に、各クエリの設定値だけでなく、各クエリの通信用情報も集約する。したがって、集約されたクエリは、複数の通信用情報を持つ場合がある。これは後に、集約したクエリの各送信者に対してクエリ受理通知を返すためである。
次に、図２２及び図２５等を参照しながら、アグリゲータ１２からの集約クエリ受信時のトランスレータ１１の動作例について説明する。図２５は、本実施形態のトランスレータ１１の、アグリゲータ１２からの集約クエリ受信時の動作例を示すフローチャートである。
トランスレータ１１は、集約クエリ受信部３５によって、アグリゲータ１２から集約クエリを受信すると（ステップＳ１３１）、プロトコル変換部２７によって、クエリのプロトコル変換を行い（ステップＳ１３２）、クエリ送信部２８によって、ＩＰコントローラにクエリを送信する（ステップＳ１３３）。その後、制御結果受信部２９によって、ＩＰコントローラから制御結果を受信し（ステップＳ１３４）、クエリ受理通知部３０によって、ユーザに制御結果を返す（ステップＳ１３５）。クエリ受理通知部３０は、クエリの通信用情報を参照することで、送信先ユーザを決定する。複数のユーザからのクエリを集約している場合は、複数のユーザに対して制御結果を送信することになる。
このように、本実施形態のゲートウェイによれば、クエリにユーザとの通信用情報を付加することにより、クエリを集約した場合でも、ＩＰコントローラから返される制御結果通知を、クエリ受理通知に含めてユーザに返すことができる
（第５の実施形態）
第５の実施形態では、第４の実施形態におけるゲートウェイが、ＩＰコントローラが管理しているデバイスの状態を考慮してクエリの集約を行う場合の動作例について説明する。以下、第４の実施形態と相違する点を中心に説明するが、第１、第２又は第３の実施形態に本実施形態の「ゲートウェイが、ＩＰコントローラが管理しているデバイスの状態を考慮してクエリの集約を行う構成」を適用することも、もちろん可能である。
ファシリティネットワークには、特定の制御命令を受けると、一定時間は他の制御命令を受け付けなくなるデバイスが存在することがある。他の制御命令を受け付けない状態にあるデバイスに対して制御命令を送ると、デバイスやＩＰコントローラの負荷は増加することになる。また、ユーザの意図が反映されないため、ユーザは再び制御命令を送信する操作を行う必要がある。例えば、空調には、暖房や冷房の運転開始命令を受けてから、実際に温風や冷風を送り出すまでに、数分間の準備時間が存在する。準備を行っている最中に、空調に対して運転開始制御を行うことは、空調やＩＰコントローラにとって余分な負荷となる。
以下、受理すると一定時間は他の制御命令を受け付けなくなる制御命令のことを、「排他的クエリ」と呼ぶ。排他的クエリが持つ情報は、一般のクエリと同じである。
本実施形態におけるゲートウェイは、デバイスの状態を考慮して、クエリを送信しても受理されないと判断した場合には、クエリを集約する。これによって、デバイスやＩＰコントローラに余分な負荷を与えずに済む。なお、本実施形態において、集約の対象とするクエリは、あるデバイスのプロパティに任意の値を設定するクエリだけではなく、あるデバイスの動作を開始／停止するといったクエリも当てはまる。このクエリは、ユーザ任意のパラメータを持たない。したがって、このクエリを集約するということは、クエリの通信用情報を集約するということである。
図２６に、本実施形態のゲートウェイの構成例を示す。第４の実施形態と相違する点は、トランスレータ１１が、第４の実施形態（図２２）の構成に加えて、状態判断部２６と状態判断用データベース（状態判断用ＤＢ）７５を備える点である。
状態判断部２６は、状態判断用ＤＢ７５を参照することで、デバイスの状態を把握し、クエリを集約する。
ここで、図２７に、状態判断用ＤＢ７５の属性情報の例を示す。図２７の例においては、状態判断用ＤＢ７５は、｛デバイスＩＤ，命令ＩＤ，制御不可期間，タイムスタンプ，状態｝の５属性から構成され、主キーはデバイスＩＤである。デバイスＩＤごとに、当該排他的クエリの識別情報である「命令ＩＤ」、制御を受け付けなくなる期間である「制御不可期間」、前回排他的クエリをＩＰコントローラに送信した時間を示す「タイムスタンプ」、「デバイスの状態」を管理する。ここで、デバイスの状態とは、「制御可能」と「制御不可」のいずれかである。排他的クエリが存在しないデバイスの場合は、命令ＩＤの情報は存在せず、常に状態は「制御可能」である。
次に、図２６及び図２８等を参照しながら、ユーザからのクエリ受信時のトランスレータ１１の動作例について説明する。図２８は、本実施形態のトランスレータ１１の、ユーザからのクエリ受信時の動作例を示すフローチャートである。
なお、図２８の手順におけるステップＳ１４１〜Ｓ１５５は、それぞれ、図２３の手順におけるステップＳ１０１〜Ｓ１１５と同じである。また、図２８の手順におけるステップＳ１６２〜Ｓ１６９は、それぞれ、図２３の手順におけるステップＳ１１６〜Ｓ１２３と同じである。
トランスレータ１１は、負荷判断部２５によって、対象ＩＰコントローラの負荷を判断する（ステップＳ１５３）。負荷が閾値Ｔ２以下であり（ステップＳ１５４）、さらに閾値Ｔ１以下である場合に（ステップＳ１５５）、状態判断部２６によって、状態判断用ＤＢ７５を参照し、デバイスの状態を確認する（ステップＳ１５６）。
クエリの制御対象デバイスの状態が「制御可能」である場合には（ステップＳ１５７）、当該クエリが排他的クエリかどうかを判断する（ステップＳ１６０に進む）。
クエリの制御対象デバイスの状態が「制御不可」である場合には（ステップＳ１５７）、タイムスタンプと制御不可期間、現在時刻から、すでに制御不可期間が終了しているかどうかを判断する。制御不可期間が終了していなければ（ステップＳ１５８）、現在もデバイスは制御不可状態であるため、クエリを適切なアグリゲータ１２に転送し、クエリ集約を行う（ステップＳ１６６〜Ｓ１６８）。制御不可期間が終了してれば（ステップＳ１５８）、状態判断用ＤＢ７５の状態を「制御可能」に設定し（ステップＳ１５９）、また、当該クエリが排他的クエリかどうかを判断する（ステップＳ１６０に進む）。
さて、ステップＳ１５７でＹｅｓ又はステップＳ１５８でＹｅｓの場合に、状態判断用ＤＢ７５の命令ＩＤと、当該クエリの命令ＩＤとが一致するときは、当該クエリは排他的クエリである。
当該クエリが排他的クエリであるときは（ステップＳ１６０）、現在時刻をタイムスタンプとして設定し、状態を「制御不可」に設定する（ステップＳ１６１）。そして、プロトコル変換部２７によって、クエリに対してプロトコル変換処理を行う（ステップＳ１６２）。
当該クエリが排他的クエリではないときは（ステップＳ１６０）、状態判断用ＤＢ７５を更新することなく（ステップＳ１６１をスキップして）、プロトコル変換処理を行う（ステップＳ１６２）。
プロトコル変換処理を行った後は、クエリ送信部２８によって、ＩＰコントローラにクエリを送信する（ステップＳ１６３〜Ｓ１６５）。
このように本実施形態のゲートウェイによれば、デバイスの状態を判断してクエリの集約を行うかどうかを判断する機能を備えるため、制御命令を受け付けない状態にあるデバイスに対して制御命令を送ることで、デバイスやＩＰコントローラに余分な負荷を与えることを避けることができる。
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。
また、本実施形態は、コンピュータに所定の手順を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
本発明の第１の実施形態に係るネットワークの構成例を示す図 ユーザが送信するクエリの情報の一例を示す図 同実施形態に係るゲートウェイの構成例を示す図 デバイスＤＢの属性情報の一例を示す図 ＩＰコントローラＤＢの属性情報の一例を示す図 アグリゲータＤＢの属性情報の一例を示す図 プロパティ情報の内容の一例を示す図 同実施形態に係るトランスレータがユーザからのクエリを受信した場合の動作例を示すフローチャート ＩＰコントローラＩＤが付加されたクエリの情報の一例を示す図 同実施形態に係るアグリゲータがクエリ受信した場合の動作例を示すフローチャート 同実施形態に係るアグリゲータのタイマーが切れた場合の動作例を示すフローチャート 同実施形態に係るトランスレータが集約クエリを受信した場合の動作例を示すフローチャート 同実施形態に係るトランスレータが負荷情報を受信した場合の動作例を示すフローチャート 負荷情報の内容の一例を示す図 本発明の第２の実施形態に係るゲートウェイの構成例を示す図 ユーザＤＢの属性情報の一例を示す図 同実施形態に係るトランスレータがユーザからのクエリを受信した場合の動作例を示すフローチャート 優先度情報が付加されたクエリの情報の一例を示す図 最大値と最小値を備えるプロパティ情報の内容の一例を示す図 本発明の第３の実施形態に係るゲートウェイの構成例を示す図 同実施形態に係るアグリゲータがクエリを受信した場合の動作例を示すフローチャート 本発明の第４の実施形態に係るゲートウェイの構成例を示す図 同実施形態に係るトランスレータがユーザからのクエリを受信した場合の動作例を示すフローチャート 通信用情報が付加されたクエリの情報の一例を示す図 同実施形態に係るトランスレータが集約クエリを受信した場合の動作例を示すフローチャート 本発明の第５の実施形態に係るゲートウェイの構成例を示す図 状態判断用ＤＢの属性情報の一例を示す図 同実施形態に係るトランスレータがユーザからのクエリを受信した場合の動作例を示すフローチャート
符号の説明
１…ゲートウェイ、１１…トランスレータ、１２…アグリゲータ、２１，５１…クエリ受信部、２２…制御権限確認部、２３…エラー送信部、２４…優先度判断部、２５…負荷判断部、２６…状態判断部、２７…プロトコル変換部、２８…クエリ送信部、２９…制御結果受信部、３０…クエリ受理通知部、３１…負荷情報受信部、３２…負荷情報更新部、３３…アグリゲータ選択部、３４…クエリ転送部、３５…集約クエリ受信部、５２…はずれ値判断部、５３…状態確認部、５４…クエリ挿入部、５５…タイマー部、５６…クエリ集約部、５７…集約クエリ送信部、７１…デバイスデータベース、７２…ＩＰコントローラデータベース、７３…アグリゲータデータベース、７４…ユーザデータベース、７５…状態判断用データベース、８１…プロパティ情報、８２…クエリキュー

Claims (14)

  1. 一つ以上の設備機器に対する制御命令を実行するための一つ以上のコントローラが接続される第１のネットワークと、制御命令を送信する一つ以上のクライアントが接続される第２のネットワークとの境界に位置し、制御命令をプロトコル変換するためのトランスレータと、制御命令を集約するための一つ以上のアグリゲータとを備えたゲートウェイ装置であって、
    前記トランスレータは、
    各々の前記コントローラについて、当該コントローラ内部の負荷状態に関する情報である負荷情報を収集するための収集部と、
    前記第２のネットワークを介して前記クライアントから所望の設備機器に対する制御命令を受信するための制御命令受信部と、
    前記制御命令が受信された場合に、該制御命令が対象とする設備機器に対応するコントローラの前記負荷情報に基づいて、該制御命令を集約の対象にするか否か判定するための判定部と、
    集約の対象にすると判定された場合に、前記制御命令を、該制御命令に対応する前記アグリゲータに転送するための第１の転送部と、
    前記アグリゲータから集約済み制御命令の転送を受けるための第２の転送部とを含み、
    前記アグリゲータは、
    前記トランスレータから前記制御命令の転送を受けるための第３の転送部と、
    複数の前記制御命令を、一つの集約済み制御命令に集約するための集約部と、
    前記集約済み制御命令令を前記トランスレータに転送するための第４の転送部とを含むことを特徴とするゲートウェイ装置。
  2. 前記アグリゲータは、前記設備機器と前記制御命令との組み合わせごとに設けられ、
    前記制御命令は、該制御命令の識別情報である第１の識別情報と、該制御命令が対象とする設備機器の識別情報である第２の識別情報とを含み、
    前記トランスレータは、前記制御命令に含まれる前記第１の識別情報及び第２の識別情報に基づいて、該制御命令を転送するアグリゲータを選択するための選択部を更に含むことを特徴とする請求項１に記載のゲートウェイ装置。
  3. 前記アグリゲータは、
    受信された前記制御命令を保存する制御命令キューと、
    前記制御命令キューに最初の制御命令が保存されるときに、カウントを開始するタイマーとを更に含み、
    前記アグリゲータの前記集約部は、前記タイマーが所定のカウント値に達したときに、前記制御命令キューに保存されている制御命令を、一つの集約済み制御命に集約することを特徴とする請求項１または２に記載のゲートウェイ装置。
  4. 前記負荷情報は、前記コントローラの負荷を示す数値であり、
    前記トランスレータの前記判定部は、受信された前記制御命令が対象とする設備機器に対応するコントローラの前記負荷情報が示す数値と、第１の閾値及び該第１の閾値より大きい第２の閾値とを比較し、前記数値が、前記第２の閾値以下であり且つ前記第１の閾値より大きい場合に、前記制御命令を集約の対象にするものとし、前記数値が、前記第１の閾値以下である場合に、前記制御命令を集約の対象にしないものとし、前記数値が、前記第２の閾値より大きい場合に、前記制御命令を破棄するものとすることを特徴とする請求項１ないし３のいずれか１項に記載のゲートウェイ装置。
  5. 前記トランスレータは、前記数値が、前記第２の閾値より大きい場合に、エラーを示すメッセージを前記制御命令の送信元であるクライアントに通知するための通知部を更に含むことを特徴とする請求項４に記載のゲートウェイ装置。
  6. 前記トランスレータは、受信された前記制御命令に対して、該制御命令の優先度を示す優先度情報を付加する優先度情報付加部を更に含み、
    前記アグリゲータの前記集約部は、複数の前記制御命令に対してそれぞれ付加された前記優先度情報を加味して、複数の前記制御命令を、一つの集約済み制御命令に集約することを特徴とする請求項１ないし５のいずれか１項に記載のゲートウェイ装置。
  7. 前記制御命令は、該制御命令が対象とする設備機器に関係する設定値を含むものであり、
    前記アグリゲータは、前記トランスレータから受けた前記制御命令に含まれる前記設定値情報が許容範囲内か否かを判断する許容範囲判断部を更に含み、
    前記アグリゲータの前記集約部は、複数の前記制御命令のそれぞれに対する前記判断の結果を加味して、複数の前記制御命令を、一つの集約済み制御命令に集約することを特徴とする請求項１ないし６のいずれか１項に記載のゲートウェイ装置。
  8. 前記トランスレータは、前記制御命令が受信された場合に、該制御命令が対象とする設備機器が制御可能状態であるか否かを判断する状態判断部を更に含み、
    前記トランスレータの前記第１の転送部は、前記設備機器が制御可能状態でないと判断された場合にも、前記制御命令を、該制御命令に対応する前記アグリゲータに転送することを特徴とする請求項１ないし７のいずれか１項に記載のゲートウェイ装置。
  9. 前記トランスレータは、前記アグリゲータから受けた前記集約済み制御命令又は前記集約の対象にすると判定されなかった前記制御命令を、前記第１のネットワークを介して前記コントローラに送信するための制御命令送信部を更に含むことを特徴とする請求項１ないし８のいずれか１項に記載のゲートウェイ装置。
  10. 前記トランスレータは、前記アグリゲータから受けた前記集約済み制御命令又は前記集約の対象にすると判定されなかった前記制御命令を、前記制御命令送信部による前記コントローラへの送信に先立って、当該ゲートウェイ装置と前記コントローラとの間で使用されるプロトコルに従うものになるようにプロトコル変換するためのプロトコル変換部を更に含むことを特徴とする請求項９に記載のゲートウェイ装置。
  11. 前記トランスレータは、
    受信された前記制御命令に対して、当該制御命令の送信元であるクライアントを示す送信者情報を付加するための送信者情報付加部と、
    前記制御命令が前記コントローラへ送信された後に、該コントローラから該制御命令に対する制御結果の通知を受信するための制御結果通知受信部とを更に含み、
    前記アグリゲータの前記集約部は、複数の前記制御命令を、一つの集約済み制御命令に集約するにあたって、各々の前記制御命令に付加されている前記送信者情報をも集約し、
    前記トランスレータは、
    前記制御結果の通知が受信された場合に、前記集約済み制御命令に付加されている前記送信者情報を参照して、該集約済み制御命令に係る各制御命令の送信元であるクライアントへそれぞれ該制御結果を送信するための制御結果送信部を更に含むことを特徴とする請求項１ないし１０のいずれか１項に記載のゲートウェイ装置。
  12. 前記第１のネットワークは制御系ネットワークであり、第２のネットワークはＯＡ系ネットワークであることを特徴とする請求項１ないし１１のいずれか１項に記載のゲートウェイ装置。
  13. 一つ以上の設備機器に対する制御命令を実行するための一つ以上のコントローラが接続される第１のネットワークと、制御命令を送信する一つ以上のクライアントが接続される第２のネットワークとの境界に位置し、制御命令をプロトコル変換するためのトランスレータと、制御命令を集約するための一つ以上のアグリゲータとを備えたゲートウェイ装置の制御命令処理方法であって、
    前記トランスレータの備える収集部が、各々の前記コントローラについて、当該コントローラ内部の負荷状態に関する情報である負荷情報を収集するステップと、
    前記トランスレータの備える制御命令受信部が、前記第２のネットワークを介して前記クライアントから所望の設備機器に対する制御命令を受信するステップと、
    前記トランスレータの備える判定部が、前記制御命令が受信された場合に、該制御命令が対象とする設備機器に対応するコントローラの前記負荷情報に基づいて、該制御命令を集約の対象にするか否か判定するステップと、
    前記トランスレータの備える第１の集約対象制御命令令転送部が、集約の対象にすると判定された場合に、前記制御命令を、該制御命令に対応する前記アグリゲータに転送するステップと、
    前記アグリゲータの備える第２の集約対象制御命令令転送部が、前記トランスレータから前記制御命令の転送を受けるステップと、
    前記アグリゲータの備える集約部が、複数の前記制御命令を、一つの集約済み制御命令に集約するステップと、
    前記アグリゲータの備える第１の集約済み制御命令令転送部が、前記集約済み制御命令令を前記トランスレータに転送するステップと、
    前記トランスレータの備える第２の集約済み制御命令令転送部が、前記アグリゲータから集約済み制御命令の転送を受けるステップとを有することを特徴とする制御命令処理方法。
  14. 一つ以上の設備機器に対する制御命令を実行するための一つ以上のコントローラが接続される第１のネットワークと、制御命令を送信する一つ以上のクライアントが接続される第２のネットワークとの境界に位置し、制御命令をプロトコル変換するためのトランスレータと、制御命令を集約するための一つ以上のアグリゲータとを備えたゲートウェイ装置としてコンピュータを機能させるためのプログラムであって、
    各々の前記コントローラについて、当該コントローラ内部の負荷状態に関する情報である負荷情報を収集するための前記トランスレータの収集部と、
    前記第２のネットワークを介して前記クライアントから所望の設備機器に対する制御命令を受信するための制御命令受信部と、
    前記制御命令が受信された場合に、該制御命令が対象とする設備機器に対応するコントローラの前記負荷情報に基づいて、該制御命令を集約の対象にするか否か判定するための判定部と、
    集約の対象にすると判定された場合に、前記制御命令を、該制御命令に対応する前記アグリゲータに転送するための第１の転送部と、
    前記アグリゲータから集約済み制御命令の転送を受けるための第２の転送部とを含むトランスレータと
    前記トランスレータから前記制御命令の転送を受けるための第３の転送部と、
    複数の前記制御命令を、一つの集約済み制御命令に集約するための集約部と、
    前記集約済み制御命令令を前記トランスレータに転送するための第４の転送部とを含むアグリゲータとをコンピュータに機能させるためのプログラム。
JP2008081012A 2008-03-26 2008-03-26 ゲートウェイ装置、制御命令処理方法及びプログラム Expired - Fee Related JP5127528B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2008081012A JP5127528B2 (ja) 2008-03-26 2008-03-26 ゲートウェイ装置、制御命令処理方法及びプログラム
US12/407,855 US7984135B2 (en) 2008-03-26 2009-03-20 Gateway apparatus, control instruction processing method, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008081012A JP5127528B2 (ja) 2008-03-26 2008-03-26 ゲートウェイ装置、制御命令処理方法及びプログラム

Publications (2)

Publication Number Publication Date
JP2009239478A JP2009239478A (ja) 2009-10-15
JP5127528B2 true JP5127528B2 (ja) 2013-01-23

Family

ID=41118919

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008081012A Expired - Fee Related JP5127528B2 (ja) 2008-03-26 2008-03-26 ゲートウェイ装置、制御命令処理方法及びプログラム

Country Status (2)

Country Link
US (1) US7984135B2 (ja)
JP (1) JP5127528B2 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5072666B2 (ja) * 2008-03-13 2012-11-14 株式会社東芝 設備機器連携システム及び機器制御方法並びにエージェント装置
JP5214685B2 (ja) * 2010-09-08 2013-06-19 株式会社東芝 情報収集装置、情報収集プログラム、及びビル管理システム
JP5214686B2 (ja) * 2010-09-08 2013-06-19 株式会社東芝 情報収集装置、情報収集プログラム、及びビル管理システム
US8768493B2 (en) 2012-04-25 2014-07-01 Lumenpulse Lighting Inc. Power line light controller system and method
US9699862B2 (en) 2012-05-07 2017-07-04 Lumenpulse Lighting, Inc. Power line non-lighting application controller system and method
JP2014018044A (ja) * 2012-07-11 2014-01-30 Kyocera Corp 電力制御システム及び電力制御システムの制御方法
JP2017108291A (ja) * 2015-12-09 2017-06-15 株式会社東芝 ゲートウェイ、要求生成方法及びコンピュータプログラム
CN105721554A (zh) * 2016-01-25 2016-06-29 国网福建省电力有限公司 一种基于动词和名词的配电网业务消息流的生成方法
JP6874084B2 (ja) * 2019-10-02 2021-05-19 株式会社東芝 ゲートウェイ、要求生成方法及びコンピュータプログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020026533A1 (en) * 2000-01-14 2002-02-28 Dutta Prabal K. System and method for distributed control of unrelated devices and programs
JP4586280B2 (ja) * 2001-02-19 2010-11-24 ダイキン工業株式会社 設備機器の管理システム
CA2480551A1 (en) * 2002-03-28 2003-10-09 Robertshaw Controls Company Energy management system and method
FR2859341A1 (fr) * 2003-08-27 2005-03-04 Thomson Licensing Sa Methode de controle entre appareils connectes a un reseau heterogene et appareil implementant la methode
JP4534719B2 (ja) 2004-10-29 2010-09-01 株式会社富士通ゼネラル ゲートウェイ装置
JP4816039B2 (ja) * 2005-12-05 2011-11-16 東芝ライテック株式会社 照明制御システム

Also Published As

Publication number Publication date
US7984135B2 (en) 2011-07-19
JP2009239478A (ja) 2009-10-15
US20090249042A1 (en) 2009-10-01

Similar Documents

Publication Publication Date Title
JP5127528B2 (ja) ゲートウェイ装置、制御命令処理方法及びプログラム
US7516187B2 (en) Remote control system for home appliance network and method for operating the same
JP6378057B2 (ja) 接続制御装置、接続制御方法、接続制御システムおよびコンピュータプログラム
JP5002647B2 (ja) ネットワークを管理するシステム及び方法
US9973567B2 (en) System and method for terminal management in a home network using a virtual client
US7693934B2 (en) Network device, system and method for providing list of controlled devices
JP4456095B2 (ja) ホームネットワークで第３の装置のイベントを処理する方法及び装置
KR20070042771A (ko) 홈 네트워크에서 디바이스를 독점적으로 제어하기 위한방법 및 장치
EP2840741B1 (en) Method and apparatus for using service of home network device based on remote access
KR101761495B1 (ko) 다수의 서버-클라이언트 세션을 감소시키기 위한 방법 및 시스템
JP2004186717A (ja) 通信制御方法、サーバ機器、及びクライアント機器
KR20100128370A (ko) 원격 유저 인터페이스를 지원하는 홈 네트워크에서 이벤트 처리 방법 및 이를 위한 장치
JP5038956B2 (ja) ネットワークシステム
JP2009031898A (ja) 情報退避システム、サーバ、サーバプログラム、クライアント及びクライアントプログラム
JP7028025B2 (ja) 情報処理システム、エッジ装置、および情報処理方法
JP5394704B2 (ja) 情報通信システム、及びソフトウェア更新方法
KR20150085464A (ko) 서버 연결 장치 및 방법
JP2015111330A (ja) 端末装置、通信システム及び通信プログラム
JP5714067B2 (ja) 通信システム、サーバ装置、制御方法、およびプログラム
CN110636104B (zh) 一种资源请求方法、电子设备及存储介质
JP5940566B2 (ja) ネットワークシステム、常時接続方法、サーバ、電子機器、プログラム
KR101589385B1 (ko) 컨트롤러와 네트워크 장치 간 이벤트를 처리하는 방법
TWI479863B (zh) 通訊終端以及通訊方法
KR100637703B1 (ko) 홈 네트워크 환경에서 데이터 분배를 위한 서버,클라이언트, 데이터 분배 시스템 및 그 방법
CN109951361B (zh) 家电产品

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20101015

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120410

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120417

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120615

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20121002

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121030

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151109

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees