遠隔情報収集装置およびプログラム
【課題】遠隔からビル内部の設備情報を収集する情報収集装置と、それと通信してビル設備情報を返送するビル側通信装置の双方にかかる通信負荷を平準化する。
【解決手段】ビル設備情報保持部１０１は、各プロセスデータのデータサイズを記憶する。スケジュール作成部１０３は、時間的に連続する複数の単位期間を含む収集期間において、各前記ビル側通信装置から前記単位期間当たりに受信する合計データ量を表す第1通信負荷と、前記ビル側通信装置によりそれぞれ前記単位期間当たりに送信されるデータ量を表す第2通信負荷とを前記単位期間間で平準化するように、各前記ビル側通信装置からの各前記プロセスデータの収集スケジュールを作成する。ネットワーク通信部１０５は、前記収集スケジュールにしたがって、前記プロセスデータの取得要求を前記ビル側通信装置に送信する。
【解決手段】ビル設備情報保持部１０１は、各プロセスデータのデータサイズを記憶する。スケジュール作成部１０３は、時間的に連続する複数の単位期間を含む収集期間において、各前記ビル側通信装置から前記単位期間当たりに受信する合計データ量を表す第1通信負荷と、前記ビル側通信装置によりそれぞれ前記単位期間当たりに送信されるデータ量を表す第2通信負荷とを前記単位期間間で平準化するように、各前記ビル側通信装置からの各前記プロセスデータの収集スケジュールを作成する。ネットワーク通信部１０５は、前記収集スケジュールにしたがって、前記プロセスデータの取得要求を前記ビル側通信装置に送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを経由して遠隔地にある多数のビル設備情報を収集する遠隔情報収集装置およびプログラムに関する。
【背景技術】
【０００２】
ビルの内部には照明や空調、防災設備といった種々の設備が設置されている。これらの設備をビル内部あるいは外部から制御したり、異常が発生していないか監視したりといったことを実現するために、ビル設備の稼動情報(プロセスデータ)をネットワーク越しに遠隔収集する装置やシステムが提案されている。そのようなシステムでは、収集対象とするビル設備に接続されたビル側通信装置と情報収集装置がネットワークを通じて通信することで、プロセスデータが転送される。また、データの利用のしやすさの観点から、そのようなシステムではプロセスデータをある定められた時間周期で収集することが一般的である。
【０００３】
情報収集対象とするビル設備が多くなると、それらを管理するビル側通信装置と情報収集装置との間の通信トラフィックが増加する。通信トラフィックが通信帯域幅に迫るほど大きくなると、ネットワーク上で通信されるデータが欠損したり、プロセスデータ取得にかかる遅延が大きくなるなどの問題が生じる。そのため、通信帯域幅や設備情報の重要度に応じてプロセスデータの取得周期を決定する方法が提案されている。例えば、通信帯域幅の小さいビル側通信装置については、取得周期を長く設定する。
【０００４】
この方法によれば、取得周期を調整することによって、平均的な通信トラフィック量を所定の値以下に制限することができる。しかし、この方法では、プロセスデータ取得のタイミングを制御していないため、情報収集装置またはビル側通信装置に対して瞬間的に大きな通信負荷が発生する可能性がある。例えば、プロセスデータの取得周期を十分に大きくした場合であっても、多数のビル設備から同時にデータを取得しようとすれば、情報収集装置の通信帯域幅や処理能力を超えるほどの通信負荷が瞬間的に発生し得る。
【０００５】
この問題に対処するために、通信を行うタイミングをあらかじめビル側通信装置ごとに決めるという方法が提案されている。この方法では、プロセスデータの取得周期はある単位期間ごとに分割される。ビル側通信装置と情報収集装置との間の通信タイミングは、この単位期間ごとに決定される。このような方法をとれば、単位期間内に通信するビル側通信装置の数に上限を設けることができるため、情報収集装置に対する瞬間的なトラフィック集中を防ぐことができる。
【０００６】
しかし、この方法ではビル側通信装置にかかる通信負荷を管理していない。そのため、情報収集装置における通信負荷の集中を防ぐことができても、ビル側通信装置にとって過剰な通信負荷が瞬間的に発生する可能性は依然として残っている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開2004-104753号公報
【特許文献２】特開2009-16889号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
以上で述べたように、一定周期でプロセスデータを収集しようとする場合、情報収集装置またはビル側通信装置に対して過剰に大きな通信負荷が集中する可能性がある。また情報収集装置のみにかかる通信負荷の集中を防ぐことはできるが、情報収集装置及びビル側通信装置への通信負荷集中をともに防ぐことのできる装置やシステムは存在しない。
【０００９】
本発明は、上記事由を鑑みて為されたものであり、その目的は、遠隔情報収集装置及び各ビル側通信装置双方に対する通信負荷の瞬間的な集中を防ぎつつ、所定の取得周期通りにプロセスデータを遠隔収集することのできる遠隔情報収集装置およびプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
本発明の一態様としての遠隔情報収集装置は、複数のビル側通信装置からそれぞれ１つ以上のプロセスデータを順次収集する遠隔情報収集装置であって、ビル設備情報保持部、スケジュール作成部、およびネットワーク通信部を備える。
【００１１】
前記ビル設備情報保持部は、各前記ビル側通信装置から収集するプロセスデータのデータサイズを記憶する。
【００１２】
前記スケジュール作成部は、時間的に連続する複数の単位期間を含む収集期間において、各前記ビル側通信装置から前記単位期間当たりに受信する合計データ量を表す第1通信負荷と、各前記ビル側通信装置によりそれぞれ前記単位期間当たりに送信されるデータ量を表す第2通信負荷とを前記単位期間間で平準化するように、各前記ビル側通信装置からの各前記プロセスデータの収集スケジュールを作成する。
【００１３】
前記ネットワーク通信部は、前記収集スケジュールにしたがって、各前記ビル側通信装置から前記プロセスデータを収集する。
【図面の簡単な説明】
【００１４】
【図１】遠隔情報収集システム全体の構成概要図。
【図２】本発明の第1の実施形態における情報収集装置の内部構成図。
【図３】本発明の第1の実施形態におけるビル設備情報保持部に格納されるビル設備情報テーブル。
【図４】本発明の第1の実施形態における情報収集装置についての通信スケジュール保持部に格納される通信スケジュールテーブル。
【図５】本発明の第1の実施形態における各ビル側通信装置についての通信スケジュール保持部に格納される通信スケジュールテーブル。
【図６】本発明の第1の実施形態におけるデータ要求送信スケジュール保持部に格納されるデータ要求送信スケジュール。
【図７】本発明の第1の実施形態において、新たなビル設備をスケジュールに追加する際の情報収集装置の動作を説明するためのフローチャート。
【図８】本発明の第1の実施形態において、ビル設備をスケジュールから削除する際の情報収集装置の動作を説明するためのフローチャート。
【図９】本発明の第1の実施形態において、収集スケジュールに従ってネットワーク通信部がプロセスデータを収集する動作を説明するためのフローチャート。
【図１０】本発明の第2の実施形態における情報収集装置の内部構成図。
【図１１】本発明の第2の実施形態におけるビル設備情報保持部に格納されるビル設備情報テーブル。
【図１２】本発明の第2の実施形態におけるビル設備チェーン保持部に格納されるビル設備チェーンテーブル。
【図１３】本発明の第2の実施形態において、新たなビル設備チェーンを構成するビル設備群をスケジュールに追加する際の情報収集装置の動作を説明するためのフローチャート。
【図１４】本発明の第2の実施形態において、ビル設備をスケジュールから削除する際の情報収集装置の動作を説明するためのフローチャート。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態を図面に基づいて説明する。
【００１６】
(第1の実施形態)
図1は、本発明の第1の実施形態における遠隔情報収集システムの概略を示した図である。このシステムでは、情報収集装置1がネットワーク2を通じて、監視対象とするビル3内部にあるビル設備32の持つプロセスデータを収集する。ビル3内部には一つまたは複数のビル側通信装置31が存在し、情報収集装置1とネットワーク2を通じて直接通信する。ビル側通信装置31はそれぞれいくつかのビル設備32を管理している。ビル設備32はビル側通信装置31に直接接続されている場合もあるし、一つまたは複数のビル設備中間管理装置33を介してビル側通信装置31に接続されている場合もある。ビル側通信装置31は、自身の管理するビル設備32のプロセスデータ要求を情報収集装置1から受け取ると、当該プロセスデータを情報収集装置1へ返送する。ビル側通信装置31が送信するプロセスデータは、情報収集装置1からプロセスデータ要求を受け取った後にビル設備32へ直接問い合わせて取得してもよいし、ビル側通信装置31が内部に持つデータベースにあらかじめ記憶しておいたプロセスデータを用いてもよい。
【００１７】
図2に、情報収集装置1の内部構成を示す。情報収集装置1は、ビル設備情報保持部101、スケジュール周期調整部102、スケジュール作成部103、データ要求送信タイミング決定部104、ネットワーク通信部105、スケジュール周期保持部106、ビル側通信装置通信スケジュール保持部107、情報収集装置通信スケジュール保持部108、データ要求送信スケジュール保持部109、プロセスデータベース110、タイマ111を持つ。情報収集装置1や各ビル側通信装置31に過度の通信負荷がかかることを防ぐために、情報収集装置1はまず各ビル設備32のプロセスデータをいつ収集（受信）するかを記述した収集スケジュールを作成する。情報収集装置1は作成した収集スケジュールに従ってデータ要求をビル側通信装置31へ送信し、プロセスデータを受信する。
【００１８】
ビル設備情報保持部101は、収集対象とするビル設備32に関する情報を格納する。プロセスデータ収集スケジュールを作成するために必要な情報は全てビル設備情報保持部101が持っている。図3はビル設備情報保持部101に格納される情報の例を示している。収集対象とするビル設備32のプロセスデータには一意のデータ識別子が付与されている。図3に示すように、プロセスデータごとに、当該ビル設備32を管理するビル側通信装置31の一意な識別子、プロセスデータのサイズ、プロセスデータの取得周期、プロセスデータの問い合わせに対するビル側通信装置31の応答時間といった情報がビル設備情報保持部101に記憶される。これらの情報は、スケジュール周期調整部102やスケジュール作成部103が収集スケジュールを作成する際や、ネットワーク通信部105がビル側通信装置31と通信する際などに参照される。
【００１９】
スケジュール周期保持部106は、スケジュール周期を格納する。スケジュール周期とは、情報収集装置1が作る収集スケジュールの時間周期である。収集スケジュールにはスケジュール周期の範囲内で各プロセスデータを取得する時刻が記述される。ネットワーク通信部105が実際に収集を行う際は、収集スケジュールに記述されたプロセスデータ取得処理が、スケジュール周期ごとに繰り返される。スケジュール周期毎の各期間は、それぞれ収集期間に対応する。
【００２０】
スケジュール周期調整部102は、ビル設備情報保持部101に格納された各プロセスデータの取得周期を参照し、スケジュール周期保持部106に格納されたスケジュール周期を調整する。具体的には、スケジュール周期が全てのプロセスデータ取得周期の公倍数となるように設定を行う。例えば、ビル設備情報保持部101に格納されたプロセスデータの取得周期が、2分、3分、5分の3通りであった場合、スケジュール周期は30分の倍数として調整される。このようにすることで、任意の取得周期を持つプロセスデータがビル設備情報保持部101に入っている場合でも、それを収容可能なスケジュールを作成することができる。
【００２１】
ビル側通信装置通信スケジュール保持部107は情報収集の対象とするビル側通信装置31ごとに用意され、各ビル側通信装置31で収集されるプロセスデータの集合、それによって発生すると予想される通信負荷、及び許容される最大の通信負荷の情報を、各時刻ごとに格納する。また、情報収集装置通信スケジュール保持部108は情報収集装置1について同様の情報を格納する。ビル側通信装置通信スケジュール保持部107と情報収集装置通信スケジュール保持部108に格納されるデータの形式は共通している。
【００２２】
ビル側通信装置通信スケジュール保持部107に格納されている情報の例を図5に示す。図5の表において、各行は収集スケジュール内のある時間帯を表す。例えば、図5の表の第2行は、スケジュール周期開始直後(0分)から1分後までの時間帯を意味する。ここで、図5の表の開始時刻と終了時刻の列で示されている時刻は、収集スケジュールの周期の開始時刻を起点とした相対時刻を表している。本実施形態では、収集スケジュールの周期の絶対的な開始時刻は任意の時刻でよいとしており、収集スケジュール周期内部で各プロセスデータの収集タイミングが決定される。図5の表の他の列としては、その時間帯で収集するプロセスデータの識別子リスト、プロセスデータ収集で発生する通信負荷、その時間帯で許容される最大の通信負荷の情報がある。なお、この例では通信負荷は、プロセスデータのバイト数の合計として表現されている。許容通信負荷（第２許容通信負荷に相当）は、ビル側通信装置32から単位期間当たり（ここでは１分間）に送信することを許容される最大のデータ量である。許容通信負荷は事前に設定されている。
【００２３】
情報収集装置通信スケジュール保持部108に格納されている情報の例を図4に示す。当該情報収集装置1が収集する全てのプロセスデータのスケジュールと情報収集装置1にかかる通信負荷が格納される。一方、ビル側通信装置通信スケジュール保持部107には、当該ビル側通信装置31が管理するプロセスデータのスケジュールと、当該ビル側通信装置31にかかる通信負荷のみが格納される。許容通信負荷（第1許容通信負荷に相当）は、各ビル側通信装置から単位期間当たり（ここでは１分間）に受信することを許容される最大の合計データ量である。許容通信負荷は事前に設定されている。
【００２４】
スケジュール作成部103は、ビル側通信装置通信スケジュール保持部107及び情報収集装置通信スケジュール保持部108に格納された情報を参照し、ビル設備情報保持部101に格納された各ビル設備32のプロセスデータ取得タイミングを決定する。その際、スケジュール作成部103は、各ビル側通信装置31と情報収集装置1にかかる通信負荷が時間的に平準化され、設定された許容通信負荷を超えないようにプロセスデータの取得タイミングを設定する。つまり、情報収集装置1が単位期間（ここでは１分間）に受信する合計データ量（第1通信負荷）と、各ビル側通信装置31が単位期間当たりに送信するデータ量（第2通信負荷）を単位期間間で平準化するように、プロセスデータの取得タイミングを設定する。
【００２５】
これにより、ビル側通信装置31と情報収集装置1の両方に対して、特定の時間帯に通信負荷が集中することを防ぎ、それぞれの装置に許容不可能なほどの通信負荷がかかってしまうことを防ぐ。設定された許容通信負荷を超えないような取得タイミングがどうしても見つからない場合、スケジュール作成部103はスケジュール作成処理を中断し、情報収集装置1の管理者にエラーを報告する。プロセスデータの取得タイミングが決定されると、スケジュール作成部103は情報収集装置通信スケジュール保持部108及び当該プロセスデータを管理するビル側通信装置通信スケジュール保持部107に当該プロセスデータの識別子を追加する。
【００２６】
データ要求送信スケジュール保持部109は、データ要求送信スケジュールを格納する。データ要求送信スケジュールとは、スケジュール周期内のどの時刻にどのプロセスデータの問い合わせを送信するかを記述した情報である。図6に、データ要求送信スケジュールの例を示す。図6の表では、各行が一つの送信時刻を示しており、各送信時刻で問い合わせるプロセスデータの識別子のリストが各行に記憶される。図6の表の送信時刻の列で示される時刻は、収集スケジュール周期の開始時刻を起点とした相対時刻を表している。
【００２７】
データ要求送信タイミング決定部104は、情報収集装置通信スケジュール保持部108に格納されたプロセスデータ収集スケジュールを参照し、データ要求送信スケジュールを作成し、それをデータ要求送信スケジュール保持部109に格納する。図4に示すように、収集スケジュールには各プロセスデータを受信すべき時間帯が記述されている。しかし、情報収集装置1がプロセスデータの要求パケットを送信してから、実際に当該プロセスデータを受信するまでにかかる応答時間は、ビル側通信装置31やビル設備32ごとに異なる。そのため、データ要求送信タイミング決定部104は、ビル設備情報保持部101に格納された各プロセスデータの応答時間情報を参照し、収集スケジュールからデータ要求送信スケジュールを逆算する。本実施形態では、応答時間情報は応答時間そのものを示すが、応答時間を特定できる情報であれば、これに限定されるものでなく、たとえば応答時間の半分の値でもよい。
【００２８】
ネットワーク通信部105は、タイマ111から得られる時刻情報を参照しながら、データ要求送信スケジュールに従ってプロセスデータの要求パケットを適切なビル側通信装置31へ送信する。プロセスデータの要求パケットの送信先は、要求するプロセスデータの識別子を用いてビル設備情報保持部101を参照することで導き出す。ビル側通信装置31からプロセスデータを受信すると、ネットワーク通信部105はそのデータをプロセスデータベース110に保存する。
【００２９】
プロセスデータベース110は、ビル側通信装置31からネットワーク通信部105が受信したプロセスデータを格納する。本実施形態では、プロセスデータベース110は情報収集装置1に含まれるとしているが、プロセスデータベース110が情報収集装置1とは異なる装置に含まれる構成をとってもよい。
【００３０】
タイマ111は、ネットワーク通信部105に対して正確な現在時刻の情報を提供する。タイマ111はネットワーク通信部105からの指示に応じてリセットされ、最後にリセットされた時刻からの経過時間をネットワーク通信部105へ通知する。
【００３１】
次に、本実施形態における情報収集装置1の動作について、図7のフローチャートを用いて説明する。このフローチャートは、既に収集対象としているビルに新たなビル設備32が増設され、そのプロセスデータを収集スケジュールに追加する際の動作を示したものである。
【００３２】
まず、増設された新たなビル設備32に関する情報が、ビル設備情報保持部101に追加登録される(ステップS101)。ここで登録される情報は、当該ビル3の管理者から提供されるか、当該ビル3の管理者の協力のもとで情報収集装置1の管理者が計測することによって獲得される。
【００３３】
次に、スケジュール周期調整部102が、追加されるビル設備情報とスケジュール周期を参照し、スケジュール周期が新たに収集するプロセスデータの取得周期の倍数であるか調べる(ステップS102)。
【００３４】
スケジュール周期が追加プロセスデータ取得周期の倍数ではない場合、スケジュール周期調整部102はスケジュール周期の調整を行い、スケジュール周期が追加プロセスデータ取得周期の倍数となるようにする(ステップS103)。これは例えば、新たなスケジュール周期を、追加プロセスデータ取得周期とこれまでのスケジュール周期の最小公倍数として設定すればよい。スケジュール周期を調整する際、ビル側通信装置通信スケジュール保持部107及び情報収集装置通信スケジュール保持部108に保存された収集スケジュールを拡張し、新たなスケジュール周期での収集スケジュールを表すようにする。例えば、これまでのスケジュール周期が3分で、追加プロセスデータ取得周期が2分の場合、新たなスケジュール周期は6分に変更され、これまでの収集スケジュールの長さは2倍に拡張される。
【００３５】
スケジュール周期の調整が終わると、スケジュール作成部103が仮タイミングを決定する(ステップS104)。仮タイミングとは、仮に設定されたプロセスデータ取得タイミングである。ここで設定される仮タイミングの初期値は、当該プロセスデータの取得周期内の時刻からランダムに選ばれると良い。
【００３６】
本実施形態におけるスケジュール作成部103は、仮タイミングを変化させながら、その仮タイミングにプロセスデータをスケジュールした際にビル側通信装置31及び情報収集装置1にかかる通信負荷を評価する。検証済みの仮タイミングのうち、高い評価値を与えるものは候補タイミングとして記憶される。ステップS105では、与えられた仮タイミングにおける通信負荷の評価値が候補タイミングの評価値よりも高いかどうかを検証する。仮タイミングの評価値の方が高い場合、候補タイミングは現在の仮タイミングで更新される(ステップS106)。なお、与えられた仮タイミングにおける通信負荷がビル側通信装置31または情報収集装置1いずれかの許容通信負荷を超えてしまう場合、評価値は未定義となり、たとえ候補タイミングが存在しない状況であっても、その仮タイミングが候補タイミングとして受け入れられることはない。
【００３７】
プロセスデータ取得タイミングの評価値の算出法には様々なやり方が考えられる。例えば、仮タイミングにプロセスデータをスケジュールした場合に、情報収集装置1及び当該プロセスデータを管理するビル側通信装置31にかかる通信負荷の最大値がどれだけ増加するか、その増分の和を算出する方法がある。この場合、通信負荷最大値の増分和が小さいほど、その仮タイミングの評価値が高いとする。この方法は、情報収集装置1にかかる通信負荷（第1通信負荷）の最大値と、各ビル側通信装置31にかかる通信負荷（第２通信負荷）の最大値との重み付け合計をできるだけ小さくする（最小もしくは閾値以下にする）ことに相当する。情報収集装置１およびビル側通信装置31に対する重みは等しく１としてもよいし、装置に応じて重みを変えても良い。
【００３８】
別の算出法としては、情報収集装置1及びビル側通信装置31の持つ通信余力、つまり許容通信負荷と現在の通信負荷の差分に基づいて評価値を算出する方法がある。この場合、通信余力が大きいほど評価値が高いとする。この方法は、情報収集装置の許容通信負荷（第1許容通信負荷）と上記第1通信負荷との差分の最小値と、ビル側通信装置31の許容通信負荷（第２許容通信負荷）と上記第2通信負荷との差分の最小値との重み付け合計を、最大もしくは閾値以上にすることに相当する。
【００３９】
ステップS106で候補タイミングが更新された場合、その候補タイミングがタイミング決定アルゴリズムの終了条件を満たしているかどうか検証する(ステップS107)。終了条件は例えば、その候補タイミングにおける通信負荷の評価値が理論的に最高のものである場合に満足される。あるいは、情報収集装置1の計算リソースが限られている場合は、仮タイミングの探索回数がある上限に達した場合に終了条件を満たしたものとして探索を中断してもよい。終了条件が満たされた場合、これ以上の仮タイミングの探索は行われない。これにより、スケジューリングに必要な計算量を削減することができる。
【００４０】
ステップS105において仮タイミングの評価値が候補タイミングの評価値を上回らなかった場合や、ステップS107において候補タイミングが終了条件を満たさなかった場合、プロセスデータ取得周期内の全ての仮タイミングについて評価を行ったかどうかが判断される(ステップS108)。まだ評価されていないタイミングが存在する場合、それらの中から一つが仮タイミングとして選ばれ(ステップS109)、その仮タイミングの評価が行われる(ステップS105へ戻る)。ステップS109において次の仮タイミングを定める方法はいくつかある。例えば、未検証の仮タイミングを逐次昇順に選択したり、あるいはそれらの中からランダムに一つを選んだりすればよい。
【００４１】
ステップS108にて、全ての仮タイミングの評価が終了したと判断された場合、候補タイミングが存在するかどうかが検証される(ステップS110)。候補タイミングが存在しない場合というのは、いずれの仮タイミングにおいても、当該プロセスデータをスケジュールした際に情報収集装置1もしくはビル側通信装置31にかかる通信負荷が許容通信負荷を超えてしまった場合である。この場合、当該プロセスデータをスケジュールに組み込むことができず、何らかの対応が必要となる(ステップS111)。この時の対応には様々な方法が考えられる。例えば、情報収集装置1がその管理者にエラーを報告し、管理者に判断を促すといったことが行われる。また、これまでのスケジューリングは既存の収集スケジュールを変更しないように行われてきたが、ステップS111に到達した時点で既存の収集スケジュールを破棄し、ビル設備情報保持部101に格納された全てのビル設備32について収集スケジュールの再作成を試みてもよい。いずれにせよ、情報収集装置1がどのような試みをしても、情報収集装置1やビル側通信装置31の許容通信負荷を満足するスケジュールの作成が不可能な場合、管理者に対してエラーが報告される。この場合、情報収集装置1の管理者は収集対象とするビル設備32の取捨選択を行ったり、情報収集装置1の増設を行ったり、ビル側通信装置31の管理者やビル3の管理者らと対応を協議したりすることになる。
【００４２】
ステップS107で候補タイミングが終了条件を満たした場合や、ステップS110で候補タイミングが存在している場合、この候補タイミングを採用して、プロセスデータをスケジュールに組み込む(ステップS112)。この際、当該プロセスデータを管理するビル側通信装置通信スケジュール保持部107及び情報収集装置通信スケジュール保持部108に格納されている図5および図4の表において、候補タイミング及び候補タイミングからプロセスデータ取得周期の整数倍の時間離れたタイミングに対応する行が更新される。具体的には、これらの行におけるデータ識別子リストの列に当該プロセスデータの識別子が追加され、通信負荷の列に当該プロセスデータのデータサイズが加算される。
【００４３】
ビル側通信装置通信スケジュール保持部107と情報収集装置通信スケジュール保持部108に格納された収集スケジュール情報が更新されると、データ要求送信タイミング決定部104がデータ要求送信スケジュール保持部109に格納されたデータ要求送信スケジュールを更新する(ステップS113)。データ要求送信タイミング決定部104は、ビル設備情報保持部101を参照して追加されたプロセスデータの応答時間を取り出し、収集スケジュールに追加されたプロセスデータの取得タイミングから応答時間を減算することで、データ要求の適切な送信時刻を算出する。図6の表において、算出された送信時刻に対応する行に当該プロセスデータの識別子が追加されることで、データ要求送信スケジュールの更新が行われる。
【００４４】
以上では、新たなビル設備32をスケジュールに追加する際の動作を説明した。図8は、スケジュール済みのビル設備32をスケジュールから削除する際の動作の流れを表したフローチャートである。
【００４５】
ビル設備32をスケジュールから削除する場合、まず、当該ビル設備32をデータ要求送信スケジュール保持部109から削除する(ステップS201)。これは、図6の表から当該ビル設備32のデータ識別子を削除することで行われる。
【００４６】
次に、当該ビル設備32を情報収集装置通信スケジュール保持部108から削除する(ステップS202)。これは、図4の表から、当該ビル設備32のデータ識別子を削除することで行われる。この際、図4の表において、データ識別子が削除された行の通信負荷の列も更新される。同様に、当該ビル設備32はビル側通信装置通信スケジュール保持部107からも削除される(ステップS203)。これは、図5の表から、当該ビル設備32のデータ識別子を削除することで行われる。この際、図5の表において、データ識別子が削除された行の通信負荷の列も更新される。
【００４７】
最後に、当該ビル設備32をビル設備情報保持部101から削除する(ステップS204)。これは、当該ビル設備32のデータ識別子に対応する行を破棄することで行われる。
【００４８】
スケジュール済みのビル設備32の情報を変更したい場合、図3の表のうち、どのビル設備情報を更新するかで動作が異なる。応答時間の変更を行う場合、ビル設備情報保持部101を更新し、図7のステップS113で示した処理によってデータ要求送信スケジュールを更新すればよい。
【００４９】
スケジュール済みのビル設備32のデータサイズを変化させる場合、ビル設備情報保持部101を更新後、ビル側通信装置通信スケジュール保持部107と情報収集装置通信スケジュール保持部108に変更を加え、当該プロセスデータを収集する時間帯における通信負荷の値を適切に更新する。その際、更新後の通信負荷が許容通信負荷を超える場合は、データサイズの更新は失敗となる。その場合は、当該ビル設備32を一旦スケジュールから削除し、データサイズを更新した状態で再度スケジュールに追加するとよい。それでもスケジューリングに失敗する場合、データサイズを変更するのは不可能である。
【００５０】
スケジュール済みのビル設備32の取得周期を変更する場合、既存のスケジュールを維持して更新を行うのは難しい。そのため、ビル設備32を一旦スケジュールから削除し、取得周期を更新して再度スケジュールに追加するとよい。
【００５１】
以上、収集スケジュールにおけるビル設備32の追加、削除、変更といった操作について説明した。これらの操作によって作成されたデータ要求送信スケジュールはネットワーク通信部105に参照され、実際にデータ要求パケットの送信が行われる。図9は、ネットワーク通信部105が行うプロセスデータ収集の動作を示したフローチャートである。
【００５２】
ネットワーク通信部105は、起動するとまずタイマ111をリセットする(ステップS301)。タイマ111は、最後にリセットされた時刻からの経過時間を、現在時刻としてネットワーク通信部105に提供する。
【００５３】
次に、ネットワーク通信部105はデータ要求送信スケジュール保持部109からデータ要求送信スケジュールを読み込む(ステップS302)。読み込んだスケジュールはネットワーク通信部105の内部に一時保存される。
【００５４】
ネットワーク通信部105は、ステップS302で読み込んだデータ要求送信スケジュールとタイマ111を参照し、現在時刻が次にプロセスデータを要求すべき時刻になるか、または現在時刻が収集スケジュール周期の終端に到達するまで待機する(ステップS303)。
【００５５】
現在時刻が収集スケジュール周期の終端に到達していない場合(ステップS304)、ネットワーク通信部105が動作を起こすのは、次のプロセスデータを要求すべき時刻に到達した時である(ステップS305)。この時、ネットワーク通信部105は、読み込み済みのデータ要求送信スケジュールを参照し、現在時刻において要求すべきプロセスデータ識別子のリストを取得する。また、ネットワーク通信部105は、ビル設備情報保持部101にアクセスして、プロセスデータ要求パケットを送信すべきビル側通信装置31の識別子を取得する。その後、ネットワーク通信部105はこれらのビル側通信装置31へ適切なプロセスデータ要求パケットを送信する(ステップS306)。送信が完了すると、ネットワーク通信部105は再び待機する(ステップS303に戻る)。
【００５６】
プロセスデータ要求時刻を待っている際に現在時刻が収集スケジュール周期の終端に到達した場合(ステップS304)、ネットワーク通信部105はタイマ111をリセットする(ステップS307)。これにより、新しい収集周期のプロセスデータ収集が開始される。また、タイマをリセットすると同時に、ネットワーク通信部105はデータ要求送信スケジュール保持部109から再びデータ要求送信スケジュールを読み込む(ステップS308)。プロセスデータ収集中にデータ要求送信スケジュール保持部109に対して行われた更新は、このタイミングでネットワーク通信部105に反映される。
【００５７】
ビル側通信装置31がネットワーク通信部105からデータ要求パケットを受信すると、要求されたビル設備32のプロセスデータを情報収集装置1へ返送する。この時返送するプロセスデータは、ビル側通信装置31がデータ要求パケットを受信した時点で当該ビル設備32に問い合わせて取得してもよいし、ビル側通信装置31があらかじめ記憶していたものを使ってもよい。ネットワーク通信部105はビル側通信装置31からプロセスデータを受信すると、そのデータをプロセスデータベース110へ追加する。
【００５８】
本実施形態では、通信負荷はデータサイズに基づいていたが、本実施形態の変形例として、プロセスデータの個数を用いてもよい。
【００５９】
この場合、ビル側通信装置から単位期間当たりに受信するプロセスデータの合計数（第３通信負荷）と、ビル側通信装置が単位期間当たりに送信するプロセスデータ数（第４通信負荷）とを単位期間間で平準化するように、ビル側通信装置からのプロセスデータの収集スケジュールを作成すればよい。たとえば、当該第３通信負荷の最大値と、各ビル側通信装置毎の当該第４通信負荷の最大値との重み付け合計を最小化もしくは閾値以下にするように、収集スケジュールを作成する。情報収集装置１およびビル側通信装置31に対する重みは、等しく１としてもよいし、装置に応じて重みを変えても良い。
【００６０】
また、本変形例の場合、ビル側通信装置３１の許容通信負荷（第３許容通信負荷）は、ビル側通信装置が単位期間当たりに送信することを許容されたプロセスデータの最大数を表し、情報収集装置１の許容通信負荷（第４許容通信負荷）は、ビル側通信装置３２全体から単位期間当たりに受信することを許容されたプロセスデータの最大数を表すこととなる。これら第３および第４許容通信負荷を用いたスケジューリング方法では、第３許容通信負荷と上記第３通信負荷との差分の最小値と、第４許容通信負荷と上記第４通信負荷との差分の最小値との重み付け合計を、最大もしくは閾値以上にするように、収集スケジュールを作成することが可能である。
【００６１】
本変形例は、通信負荷の内容が、データ量がデータ個数に変わった点以外は、これまで述べて来た実施形態と同様であり、前述した内容がそのまま適用可能である。
【００６２】
以上、本実施形態によれば、情報収集装置および各ビル側通信装置全てにかかる通信負荷を時間的に平準化し、特定の時間に通信負荷が集中することを防ぐことができる。
【００６３】
また、ビル設備ごとに要求されるプロセスデータ取得周期が異なる場合であっても、それらを満たすスケジュールを作成することができる。
【００６４】
また、ビル設備ごとに要求されるプロセスデータ取得周期が異なる場合であっても、それに適応してスケジュール周期を動的に変更することができる。このため、プロセスデータ取得周期が前もって明らかになっていない場合であっても、ビル設備をスケジュールすることができる。
【００６５】
また、収集スケジュールを作成する際に、情報収集装置や各ビル側通信装置の通信負荷の許容最大値を設定できる。これにより、いずれの装置においても所定の通信負荷を超えないような収集スケジュールを作成することができる。また、所定の通信負荷を超えないような収集スケジュールの作成が不可能な場合、情報収集装置の管理者にエラーを報告し、情報収集装置の増設や収集対象とするビル数の再検討などを促すことができる。
【００６６】
なお、本実施形態では１つのプロセスデータは１つの単位期間（１分）以内に収集される例を示したが、１つのプロセスデータが２つ以上の単位期間にわたって収集されてもよい。
【００６７】
(第2の実施形態)
本発明の第1の実施形態では、各ビル設備32のプロセスデータ収集タイミングはそれぞれ独立に決定されていた。しかし、実際には、複数の関連するビル設備32のプロセスデータを、特定の相対タイミングで収集しなければならない場合がある。例えば、ビル設備中間管理装置33には、ビル側通信装置31からのアクセス頻度に上限を設けているものがある。このような制限を満足するためには、当該ビル設備中間管理装置33に接続されているビル設備32のプロセスデータ取得タイミングについて制限を与えた上でスケジューリングを行わなければならない。また、もう一つの例としては、複数のビル設備32のプロセスデータを同じタイミングで取得したい場合が挙げられる。これは例えば、空調設備を制御する都合上、同じフロアにある温度センサの計測値は同時に取得したいといった場合である。このような時にも、複数のビル設備32の間の相対的なプロセスデータ取得タイミングを定義する必要がある。
【００６８】
情報収集装置1に対する以上の要求を鑑みて、本実施形態では、複数のプロセスデータの間の相対的な取得タイミングを設定し、それを満たした収集スケジュールの作成を可能とする。本実施形態における遠隔情報収集システム全体の構成は図1と同じであるため、図示及び説明を省略する。ただし、本実施形態では、図1の情報収集装置1は情報収集装置1aに置き換わる。
【００６９】
図10に、本実施形態における情報収集装置1aの内部構成図を示す。本実施形態では、図2に示した第1の実施形態の構成に比べ、ビル設備チェーン作成部112とビル設備チェーン保持部113が追加され、ビル設備情報保持部101がビル設備情報保持部101aに、スケジュール周期調整部102がスケジュール周期調整部102aに、スケジュール作成部103がスケジュール作成部103aに置き換わっている。それ以外の要素については、本実施形態と第1の実施形態で共通しているため、説明を省略する。
【００７０】
ビル設備情報保持部101aは、第1の実施形態で格納していたビル設備情報に加え、ビル設備32相互のプロセスデータ取得タイミングに関する制約条件の情報を格納する。図11に、ビル設備情報保持部101aに格納されるビル設備情報の例を示す。図11の表の、依存先データ識別子の列と相対時間の列の情報によって、プロセスデータ相互の取得タイミングに関する制約条件を記述している。例えば、図11においてデータ識別子2番のプロセスデータは、データ識別子1番のプロセスデータに対して取得タイミングが依存している。この例の場合、データ識別子2番のプロセスデータは、データ識別子1番のプロセスデータを取得した1分後に取得しなければならない。同様に、データ識別子4番のプロセスデータは、データ識別子2番のプロセスデータと同時に取得しなければならず、従って、データ識別子1番のプロセスデータの1分後に取得しなければならない。なお、データ識別子1番自身は依存先のプロセスデータを持たないため、依存先データ識別子の列にはそのことを示す"NULL"が記載されている。この場合でも、他のプロセスデータ(例えば、データ識別子2番のデータ)から依存されることによって、プロセスデータ間の取得タイミング制約が発生し得る。
【００７１】
ビル設備チェーン作成部112は、ビル設備情報保持部101aを参照し、ビル設備チェーンというデータ構造を作成する。ビル設備チェーンとは、相対的な取得タイミングについて制約条件を持つビル設備32を時間軸上に並べて管理したデータ構造である。本実施形態においては、取得タイミングはプロセスデータごとに決定されるのではなく、ビル設備チェーンごとに決定される。ビル設備チェーンに含まれるビル設備32のプロセスデータ取得タイミングは、そのビル設備チェーンの取得開始タイミングに対し、制約条件によって相対的に定められている。そのため、ビル設備チェーンの取得開始タイミングが決定されれば、それに含まれる全てのビル設備32のプロセスデータ取得タイミングが決定される。このように、ビル設備相互のプロセスデータ取得タイミングの制約条件をあらかじめ満たす形でビル設備チェーンを構築することで、それらの制約条件を満たしたスケジューリングが可能となる。なお、プロセスデータ取得タイミングについて他のビル設備32と全く制約条件を持たないビル設備32については、そのビル設備32のみを含むビル設備チェーンが作成される。
【００７２】
ビル設備チェーン保持部113は、ビル設備チェーン作成部112によって作成されたビル設備チェーンを格納する。図12は、ビル設備チェーン保持部113に格納された情報の例を示したものであり、図11に記載のビル設備情報を元に作成されたものである。図12の表において、ビル設備チェーン識別子の列はビル設備チェーンを一意に区別する識別子を表し、ビル設備チェーン周期の列はそのビル設備チェーン全体を取得する周期を表す。残るデータ識別子と相対取得タイミングの列に、ビル設備チェーンに含まれるビル設備32のデータ識別子とその相対的な取得タイミングが格納される。図11では、データ識別子1番, 2番, 4番のプロセスデータの取得タイミングに制約条件が課せられていた。そのため、ビル設備チェーン作成部112によってこれらのプロセスデータを含むビル設備チェーンが作成され、ビル設備チェーン識別子1番としてビル設備チェーン保持部113に格納されている。相対取得タイミングは、ビル設備チェーンの取得開始タイミングを起点とした相対的な取得タイミングであり、その起点をいつとして設定するかについては任意性がある。図12の例では、ビル設備チェーンに含まれるビル設備32のうち、もっともプロセスデータ取得タイミングの早いものを起点として相対取得タイミングの値を設定している。なお、同じビル設備チェーンに入るビル設備32のプロセスデータ取得周期は等しくなければならない。そうでなければ、取得タイミングの相対時刻を定義することができないからである。
【００７３】
第1の実施形態におけるスケジュール周期調整部102はプロセスデータの取得周期に応じてスケジュール周期の調整を行っていた。それに対し、本実施形態におけるスケジュール周期調整部102aは、ビル設備チェーン保持部113に格納されたビル設備チェーンの取得周期に応じてスケジュール周期の調整を行う。調整の方法は第1の実施形態と本実施形態で同じである。
【００７４】
本実施形態におけるスケジュール作成部103aは、ビル設備チェーン保持部113に格納されたビル設備チェーンの取得開始タイミングを決定する。タイミングの決定法は第1の実施形態におけるスケジュール作成部103とほぼ同様であり、ビル設備チェーンをスケジュールに追加した際に、情報収集装置1a及びビル側通信装置31にかかる通信負荷が平準化されるような取得開始タイミングを選択する。情報収集装置1aまたはビル側通信装置31にかかる通信負荷がどのようにしても許容される通信負荷を超えてしまう場合、スケジュール作成部103aはスケジュール作成処理を中断し、情報収集装置1aの管理者にエラーを報告する。ビル設備チェーンの取得開始タイミングが決定されると、スケジュール作成部103aはそのビル設備チェーンに含まれるビル設備32のプロセスデータ取得タイミングを計算する。プロセスデータ取得タイミングは、ビル設備チェーンの取得開始タイミングに図12の相対取得タイミングの値を加算したものとして計算される。個々のプロセスデータ取得タイミングが計算されると、ビル設備チェーン内のビル設備32は、第1の実施形態と同様にビル側通信装置通信スケジュール保持部107と情報収集装置通信スケジュール保持部108へ追加される。
【００７５】
次に、本実施形態における情報収集装置1aの動作について、図13のフローチャートを用いて説明する。このフローチャートでは、既に収集対象としているビルに対して、新たなビル設備チェーンを構成する複数のビル設備32が増設され、それらのプロセスデータを収集スケジュールに追加する際の動作を示したものである。この動作の流れは、第1の実施形態にて図7を用いて説明した、ビル設備32を増設する際の動作の流れとほぼ同じである。よって、以降では、本実施形態と第1の実施形態との差分を中心に説明し、それ以外については適宜説明を省略する。
【００７６】
まず、増設された新たなビル設備32群の情報が、ビル設備情報保持部101aに登録される(ステップS101a)。ここで登録される情報には、図11にある依存先データ識別子や相対時間の情報が含まれる。
【００７７】
ビル設備情報保持部101aに登録されたビル設備32群の情報を参照し、ビル設備チェーン作成部112がビル設備チェーンを作る(ステップS114)。新たに作成されたビル設備チェーンは、ビル設備チェーン保持部113に追加される。ここでは、新たに作成されたビル設備チェーンは一つとする。複数のビル設備チェーンが作成された場合、以降のステップはビル設備チェーンごとに繰り返される。
【００７８】
スケジュール周期調整部102aが、追加されるビル設備チェーンの取得周期とスケジュール周期を参照し、スケジュール周期が新たに収集するビル設備チェーンの取得周期の倍数であるか調べる(ステップS102a)。倍数でない場合、第1の実施形態と同様の処理によって、スケジュール周期の調整を行う(ステップS103)。
【００７９】
スケジュール周期の調整が終わると、スケジュール作成部103aによってビル設備チェーンの取得開始タイミングを決定する処理が行われる。第1の実施形態におけるスケジュール作成部103の動作と同様、ビル設備チェーンの取得開始タイミングを仮に設定し、その仮タイミングにおける情報収集装置1a及び関連するビル側通信装置31にかかる通信負荷の評価を行う。仮タイミングを変化させながら通信負荷の評価を行い、評価値が最高になるものを候補タイミングとして記憶する(ステップS104〜ステップS110)。
【００８０】
ステップS105aにおいて、スケジュール作成部103aは仮タイミングの評価を行う。ここで、ビル設備チェーンに含まれるビル設備32群は、それぞれを管理しているビル側通信装置31が互いに異なっている可能性がある。その場合、それらのビル側通信装置31全ての通信負荷を考慮するような評価値の算出法が必要となる。これは例えば、情報収集装置1a及び当該ビル設備チェーンに関わるビル側通信装置31全ての通信負荷最大値の増分を足し合わせたり、あるいはそれらの通信余力を足し合わせたりするなどして評価値を算出すればよい。
【００８１】
仮タイミングの探索が終了した時点で候補タイミングが存在している場合、その候補タイミングでビル設備チェーンがスケジュールに追加される(ステップS112a)。ビル設備チェーンをスケジュールに追加するには、そのビル設備チェーンに含まれるビル設備32を一つずつスケジュールに追加すればよい。その際、追加するビル設備32のプロセスデータ取得タイミングは、図12の表の相対取得タイミングの値に候補タイミングの値を加算した値が用いられる。
【００８２】
ビル設備チェーンがスケジュールに追加され、ビル側通信装置通信スケジュール保持部107と情報収集装置通信スケジュール保持部108が更新されると、それらの情報を参照してデータ要求送信タイミング決定部104がデータ要求送信スケジュールの更新を行う(ステップS113)。この処理は第1の実施形態で示したものと同一である。
【００８３】
以上では、ビル設備32群を追加する際の動作について説明した。ビル設備32をスケジュールから削除する際の動作の流れを図14に示す。この動作は、その多くが第1の実施形態で説明したもの(図8)と同じである。本実施形態と第1の実施形態との間で異なる点は、本実施形態では、ビル設備情報保持部101aを更新する前に、ビル設備チェーン保持部113から当該ビル設備32を削除する(ステップS205)ことである。この際、図12の表の、当該ビル設備32のデータ識別子を含む行が削除される。
【００８４】
スケジュール済みのビル設備32の情報を変更する場合、変更対象が応答時間やデータサイズであれば第1の実施形態と同様の手続きで変更が可能である。変更対象が図11の表の取得周期、依存先データ識別子、相対時間のいずれかである場合、当該ビル設備32を含むビル設備チェーンに含まれるビル設備32群を全て削除して、それらを再度スケジュールへ追加するとよい。また、ビル設備32の依存先を切り替える場合、新たに依存先とするビル設備を含むビル設備チェーンも再スケジュールする必要がある。
【００８５】
以上で説明した各種操作によって、データ要求送信スケジュールが作成される。ネットワーク通信部105は、作成されたデータ要求送信スケジュールに基づいてビル側通信装置31と通信し、プロセスデータを収集する。その動作の流れは第1の実施形態と同一である(図9)。
【００８６】
以上、本実施形態によれば、異なるビル設備のプロセスデータ取得タイミングの間に制約条件がある場合であっても、それを満足したプロセスデータ収集が可能となる。
【符号の説明】
【００８７】
1、1a…情報収集装置
2…ネットワーク
3…ビル
31…ビル側通信装置
32…ビル設備
33…ビル設備中間管理装置
101、101a…ビル設備情報保持部
102、102a…スケジュール周期調整部
103、103a…スケジュール作成部
104…データ要求送信タイミング決定部
105…ネットワーク通信部
106…スケジュール周期保持部
107…ビル側通信装置通信スケジュール保持部
108…情報収集装置通信スケジュール保持部
109…データ要求送信スケジュール保持部
110…プロセスデータベース
111…タイマ
112…ビル設備チェーン作成部
113…ビル設備チェーン保持部
【技術分野】
【０００１】
本発明は、ネットワークを経由して遠隔地にある多数のビル設備情報を収集する遠隔情報収集装置およびプログラムに関する。
【背景技術】
【０００２】
ビルの内部には照明や空調、防災設備といった種々の設備が設置されている。これらの設備をビル内部あるいは外部から制御したり、異常が発生していないか監視したりといったことを実現するために、ビル設備の稼動情報(プロセスデータ)をネットワーク越しに遠隔収集する装置やシステムが提案されている。そのようなシステムでは、収集対象とするビル設備に接続されたビル側通信装置と情報収集装置がネットワークを通じて通信することで、プロセスデータが転送される。また、データの利用のしやすさの観点から、そのようなシステムではプロセスデータをある定められた時間周期で収集することが一般的である。
【０００３】
情報収集対象とするビル設備が多くなると、それらを管理するビル側通信装置と情報収集装置との間の通信トラフィックが増加する。通信トラフィックが通信帯域幅に迫るほど大きくなると、ネットワーク上で通信されるデータが欠損したり、プロセスデータ取得にかかる遅延が大きくなるなどの問題が生じる。そのため、通信帯域幅や設備情報の重要度に応じてプロセスデータの取得周期を決定する方法が提案されている。例えば、通信帯域幅の小さいビル側通信装置については、取得周期を長く設定する。
【０００４】
この方法によれば、取得周期を調整することによって、平均的な通信トラフィック量を所定の値以下に制限することができる。しかし、この方法では、プロセスデータ取得のタイミングを制御していないため、情報収集装置またはビル側通信装置に対して瞬間的に大きな通信負荷が発生する可能性がある。例えば、プロセスデータの取得周期を十分に大きくした場合であっても、多数のビル設備から同時にデータを取得しようとすれば、情報収集装置の通信帯域幅や処理能力を超えるほどの通信負荷が瞬間的に発生し得る。
【０００５】
この問題に対処するために、通信を行うタイミングをあらかじめビル側通信装置ごとに決めるという方法が提案されている。この方法では、プロセスデータの取得周期はある単位期間ごとに分割される。ビル側通信装置と情報収集装置との間の通信タイミングは、この単位期間ごとに決定される。このような方法をとれば、単位期間内に通信するビル側通信装置の数に上限を設けることができるため、情報収集装置に対する瞬間的なトラフィック集中を防ぐことができる。
【０００６】
しかし、この方法ではビル側通信装置にかかる通信負荷を管理していない。そのため、情報収集装置における通信負荷の集中を防ぐことができても、ビル側通信装置にとって過剰な通信負荷が瞬間的に発生する可能性は依然として残っている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開2004-104753号公報
【特許文献２】特開2009-16889号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
以上で述べたように、一定周期でプロセスデータを収集しようとする場合、情報収集装置またはビル側通信装置に対して過剰に大きな通信負荷が集中する可能性がある。また情報収集装置のみにかかる通信負荷の集中を防ぐことはできるが、情報収集装置及びビル側通信装置への通信負荷集中をともに防ぐことのできる装置やシステムは存在しない。
【０００９】
本発明は、上記事由を鑑みて為されたものであり、その目的は、遠隔情報収集装置及び各ビル側通信装置双方に対する通信負荷の瞬間的な集中を防ぎつつ、所定の取得周期通りにプロセスデータを遠隔収集することのできる遠隔情報収集装置およびプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
本発明の一態様としての遠隔情報収集装置は、複数のビル側通信装置からそれぞれ１つ以上のプロセスデータを順次収集する遠隔情報収集装置であって、ビル設備情報保持部、スケジュール作成部、およびネットワーク通信部を備える。
【００１１】
前記ビル設備情報保持部は、各前記ビル側通信装置から収集するプロセスデータのデータサイズを記憶する。
【００１２】
前記スケジュール作成部は、時間的に連続する複数の単位期間を含む収集期間において、各前記ビル側通信装置から前記単位期間当たりに受信する合計データ量を表す第1通信負荷と、各前記ビル側通信装置によりそれぞれ前記単位期間当たりに送信されるデータ量を表す第2通信負荷とを前記単位期間間で平準化するように、各前記ビル側通信装置からの各前記プロセスデータの収集スケジュールを作成する。
【００１３】
前記ネットワーク通信部は、前記収集スケジュールにしたがって、各前記ビル側通信装置から前記プロセスデータを収集する。
【図面の簡単な説明】
【００１４】
【図１】遠隔情報収集システム全体の構成概要図。
【図２】本発明の第1の実施形態における情報収集装置の内部構成図。
【図３】本発明の第1の実施形態におけるビル設備情報保持部に格納されるビル設備情報テーブル。
【図４】本発明の第1の実施形態における情報収集装置についての通信スケジュール保持部に格納される通信スケジュールテーブル。
【図５】本発明の第1の実施形態における各ビル側通信装置についての通信スケジュール保持部に格納される通信スケジュールテーブル。
【図６】本発明の第1の実施形態におけるデータ要求送信スケジュール保持部に格納されるデータ要求送信スケジュール。
【図７】本発明の第1の実施形態において、新たなビル設備をスケジュールに追加する際の情報収集装置の動作を説明するためのフローチャート。
【図８】本発明の第1の実施形態において、ビル設備をスケジュールから削除する際の情報収集装置の動作を説明するためのフローチャート。
【図９】本発明の第1の実施形態において、収集スケジュールに従ってネットワーク通信部がプロセスデータを収集する動作を説明するためのフローチャート。
【図１０】本発明の第2の実施形態における情報収集装置の内部構成図。
【図１１】本発明の第2の実施形態におけるビル設備情報保持部に格納されるビル設備情報テーブル。
【図１２】本発明の第2の実施形態におけるビル設備チェーン保持部に格納されるビル設備チェーンテーブル。
【図１３】本発明の第2の実施形態において、新たなビル設備チェーンを構成するビル設備群をスケジュールに追加する際の情報収集装置の動作を説明するためのフローチャート。
【図１４】本発明の第2の実施形態において、ビル設備をスケジュールから削除する際の情報収集装置の動作を説明するためのフローチャート。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態を図面に基づいて説明する。
【００１６】
(第1の実施形態)
図1は、本発明の第1の実施形態における遠隔情報収集システムの概略を示した図である。このシステムでは、情報収集装置1がネットワーク2を通じて、監視対象とするビル3内部にあるビル設備32の持つプロセスデータを収集する。ビル3内部には一つまたは複数のビル側通信装置31が存在し、情報収集装置1とネットワーク2を通じて直接通信する。ビル側通信装置31はそれぞれいくつかのビル設備32を管理している。ビル設備32はビル側通信装置31に直接接続されている場合もあるし、一つまたは複数のビル設備中間管理装置33を介してビル側通信装置31に接続されている場合もある。ビル側通信装置31は、自身の管理するビル設備32のプロセスデータ要求を情報収集装置1から受け取ると、当該プロセスデータを情報収集装置1へ返送する。ビル側通信装置31が送信するプロセスデータは、情報収集装置1からプロセスデータ要求を受け取った後にビル設備32へ直接問い合わせて取得してもよいし、ビル側通信装置31が内部に持つデータベースにあらかじめ記憶しておいたプロセスデータを用いてもよい。
【００１７】
図2に、情報収集装置1の内部構成を示す。情報収集装置1は、ビル設備情報保持部101、スケジュール周期調整部102、スケジュール作成部103、データ要求送信タイミング決定部104、ネットワーク通信部105、スケジュール周期保持部106、ビル側通信装置通信スケジュール保持部107、情報収集装置通信スケジュール保持部108、データ要求送信スケジュール保持部109、プロセスデータベース110、タイマ111を持つ。情報収集装置1や各ビル側通信装置31に過度の通信負荷がかかることを防ぐために、情報収集装置1はまず各ビル設備32のプロセスデータをいつ収集（受信）するかを記述した収集スケジュールを作成する。情報収集装置1は作成した収集スケジュールに従ってデータ要求をビル側通信装置31へ送信し、プロセスデータを受信する。
【００１８】
ビル設備情報保持部101は、収集対象とするビル設備32に関する情報を格納する。プロセスデータ収集スケジュールを作成するために必要な情報は全てビル設備情報保持部101が持っている。図3はビル設備情報保持部101に格納される情報の例を示している。収集対象とするビル設備32のプロセスデータには一意のデータ識別子が付与されている。図3に示すように、プロセスデータごとに、当該ビル設備32を管理するビル側通信装置31の一意な識別子、プロセスデータのサイズ、プロセスデータの取得周期、プロセスデータの問い合わせに対するビル側通信装置31の応答時間といった情報がビル設備情報保持部101に記憶される。これらの情報は、スケジュール周期調整部102やスケジュール作成部103が収集スケジュールを作成する際や、ネットワーク通信部105がビル側通信装置31と通信する際などに参照される。
【００１９】
スケジュール周期保持部106は、スケジュール周期を格納する。スケジュール周期とは、情報収集装置1が作る収集スケジュールの時間周期である。収集スケジュールにはスケジュール周期の範囲内で各プロセスデータを取得する時刻が記述される。ネットワーク通信部105が実際に収集を行う際は、収集スケジュールに記述されたプロセスデータ取得処理が、スケジュール周期ごとに繰り返される。スケジュール周期毎の各期間は、それぞれ収集期間に対応する。
【００２０】
スケジュール周期調整部102は、ビル設備情報保持部101に格納された各プロセスデータの取得周期を参照し、スケジュール周期保持部106に格納されたスケジュール周期を調整する。具体的には、スケジュール周期が全てのプロセスデータ取得周期の公倍数となるように設定を行う。例えば、ビル設備情報保持部101に格納されたプロセスデータの取得周期が、2分、3分、5分の3通りであった場合、スケジュール周期は30分の倍数として調整される。このようにすることで、任意の取得周期を持つプロセスデータがビル設備情報保持部101に入っている場合でも、それを収容可能なスケジュールを作成することができる。
【００２１】
ビル側通信装置通信スケジュール保持部107は情報収集の対象とするビル側通信装置31ごとに用意され、各ビル側通信装置31で収集されるプロセスデータの集合、それによって発生すると予想される通信負荷、及び許容される最大の通信負荷の情報を、各時刻ごとに格納する。また、情報収集装置通信スケジュール保持部108は情報収集装置1について同様の情報を格納する。ビル側通信装置通信スケジュール保持部107と情報収集装置通信スケジュール保持部108に格納されるデータの形式は共通している。
【００２２】
ビル側通信装置通信スケジュール保持部107に格納されている情報の例を図5に示す。図5の表において、各行は収集スケジュール内のある時間帯を表す。例えば、図5の表の第2行は、スケジュール周期開始直後(0分)から1分後までの時間帯を意味する。ここで、図5の表の開始時刻と終了時刻の列で示されている時刻は、収集スケジュールの周期の開始時刻を起点とした相対時刻を表している。本実施形態では、収集スケジュールの周期の絶対的な開始時刻は任意の時刻でよいとしており、収集スケジュール周期内部で各プロセスデータの収集タイミングが決定される。図5の表の他の列としては、その時間帯で収集するプロセスデータの識別子リスト、プロセスデータ収集で発生する通信負荷、その時間帯で許容される最大の通信負荷の情報がある。なお、この例では通信負荷は、プロセスデータのバイト数の合計として表現されている。許容通信負荷（第２許容通信負荷に相当）は、ビル側通信装置32から単位期間当たり（ここでは１分間）に送信することを許容される最大のデータ量である。許容通信負荷は事前に設定されている。
【００２３】
情報収集装置通信スケジュール保持部108に格納されている情報の例を図4に示す。当該情報収集装置1が収集する全てのプロセスデータのスケジュールと情報収集装置1にかかる通信負荷が格納される。一方、ビル側通信装置通信スケジュール保持部107には、当該ビル側通信装置31が管理するプロセスデータのスケジュールと、当該ビル側通信装置31にかかる通信負荷のみが格納される。許容通信負荷（第1許容通信負荷に相当）は、各ビル側通信装置から単位期間当たり（ここでは１分間）に受信することを許容される最大の合計データ量である。許容通信負荷は事前に設定されている。
【００２４】
スケジュール作成部103は、ビル側通信装置通信スケジュール保持部107及び情報収集装置通信スケジュール保持部108に格納された情報を参照し、ビル設備情報保持部101に格納された各ビル設備32のプロセスデータ取得タイミングを決定する。その際、スケジュール作成部103は、各ビル側通信装置31と情報収集装置1にかかる通信負荷が時間的に平準化され、設定された許容通信負荷を超えないようにプロセスデータの取得タイミングを設定する。つまり、情報収集装置1が単位期間（ここでは１分間）に受信する合計データ量（第1通信負荷）と、各ビル側通信装置31が単位期間当たりに送信するデータ量（第2通信負荷）を単位期間間で平準化するように、プロセスデータの取得タイミングを設定する。
【００２５】
これにより、ビル側通信装置31と情報収集装置1の両方に対して、特定の時間帯に通信負荷が集中することを防ぎ、それぞれの装置に許容不可能なほどの通信負荷がかかってしまうことを防ぐ。設定された許容通信負荷を超えないような取得タイミングがどうしても見つからない場合、スケジュール作成部103はスケジュール作成処理を中断し、情報収集装置1の管理者にエラーを報告する。プロセスデータの取得タイミングが決定されると、スケジュール作成部103は情報収集装置通信スケジュール保持部108及び当該プロセスデータを管理するビル側通信装置通信スケジュール保持部107に当該プロセスデータの識別子を追加する。
【００２６】
データ要求送信スケジュール保持部109は、データ要求送信スケジュールを格納する。データ要求送信スケジュールとは、スケジュール周期内のどの時刻にどのプロセスデータの問い合わせを送信するかを記述した情報である。図6に、データ要求送信スケジュールの例を示す。図6の表では、各行が一つの送信時刻を示しており、各送信時刻で問い合わせるプロセスデータの識別子のリストが各行に記憶される。図6の表の送信時刻の列で示される時刻は、収集スケジュール周期の開始時刻を起点とした相対時刻を表している。
【００２７】
データ要求送信タイミング決定部104は、情報収集装置通信スケジュール保持部108に格納されたプロセスデータ収集スケジュールを参照し、データ要求送信スケジュールを作成し、それをデータ要求送信スケジュール保持部109に格納する。図4に示すように、収集スケジュールには各プロセスデータを受信すべき時間帯が記述されている。しかし、情報収集装置1がプロセスデータの要求パケットを送信してから、実際に当該プロセスデータを受信するまでにかかる応答時間は、ビル側通信装置31やビル設備32ごとに異なる。そのため、データ要求送信タイミング決定部104は、ビル設備情報保持部101に格納された各プロセスデータの応答時間情報を参照し、収集スケジュールからデータ要求送信スケジュールを逆算する。本実施形態では、応答時間情報は応答時間そのものを示すが、応答時間を特定できる情報であれば、これに限定されるものでなく、たとえば応答時間の半分の値でもよい。
【００２８】
ネットワーク通信部105は、タイマ111から得られる時刻情報を参照しながら、データ要求送信スケジュールに従ってプロセスデータの要求パケットを適切なビル側通信装置31へ送信する。プロセスデータの要求パケットの送信先は、要求するプロセスデータの識別子を用いてビル設備情報保持部101を参照することで導き出す。ビル側通信装置31からプロセスデータを受信すると、ネットワーク通信部105はそのデータをプロセスデータベース110に保存する。
【００２９】
プロセスデータベース110は、ビル側通信装置31からネットワーク通信部105が受信したプロセスデータを格納する。本実施形態では、プロセスデータベース110は情報収集装置1に含まれるとしているが、プロセスデータベース110が情報収集装置1とは異なる装置に含まれる構成をとってもよい。
【００３０】
タイマ111は、ネットワーク通信部105に対して正確な現在時刻の情報を提供する。タイマ111はネットワーク通信部105からの指示に応じてリセットされ、最後にリセットされた時刻からの経過時間をネットワーク通信部105へ通知する。
【００３１】
次に、本実施形態における情報収集装置1の動作について、図7のフローチャートを用いて説明する。このフローチャートは、既に収集対象としているビルに新たなビル設備32が増設され、そのプロセスデータを収集スケジュールに追加する際の動作を示したものである。
【００３２】
まず、増設された新たなビル設備32に関する情報が、ビル設備情報保持部101に追加登録される(ステップS101)。ここで登録される情報は、当該ビル3の管理者から提供されるか、当該ビル3の管理者の協力のもとで情報収集装置1の管理者が計測することによって獲得される。
【００３３】
次に、スケジュール周期調整部102が、追加されるビル設備情報とスケジュール周期を参照し、スケジュール周期が新たに収集するプロセスデータの取得周期の倍数であるか調べる(ステップS102)。
【００３４】
スケジュール周期が追加プロセスデータ取得周期の倍数ではない場合、スケジュール周期調整部102はスケジュール周期の調整を行い、スケジュール周期が追加プロセスデータ取得周期の倍数となるようにする(ステップS103)。これは例えば、新たなスケジュール周期を、追加プロセスデータ取得周期とこれまでのスケジュール周期の最小公倍数として設定すればよい。スケジュール周期を調整する際、ビル側通信装置通信スケジュール保持部107及び情報収集装置通信スケジュール保持部108に保存された収集スケジュールを拡張し、新たなスケジュール周期での収集スケジュールを表すようにする。例えば、これまでのスケジュール周期が3分で、追加プロセスデータ取得周期が2分の場合、新たなスケジュール周期は6分に変更され、これまでの収集スケジュールの長さは2倍に拡張される。
【００３５】
スケジュール周期の調整が終わると、スケジュール作成部103が仮タイミングを決定する(ステップS104)。仮タイミングとは、仮に設定されたプロセスデータ取得タイミングである。ここで設定される仮タイミングの初期値は、当該プロセスデータの取得周期内の時刻からランダムに選ばれると良い。
【００３６】
本実施形態におけるスケジュール作成部103は、仮タイミングを変化させながら、その仮タイミングにプロセスデータをスケジュールした際にビル側通信装置31及び情報収集装置1にかかる通信負荷を評価する。検証済みの仮タイミングのうち、高い評価値を与えるものは候補タイミングとして記憶される。ステップS105では、与えられた仮タイミングにおける通信負荷の評価値が候補タイミングの評価値よりも高いかどうかを検証する。仮タイミングの評価値の方が高い場合、候補タイミングは現在の仮タイミングで更新される(ステップS106)。なお、与えられた仮タイミングにおける通信負荷がビル側通信装置31または情報収集装置1いずれかの許容通信負荷を超えてしまう場合、評価値は未定義となり、たとえ候補タイミングが存在しない状況であっても、その仮タイミングが候補タイミングとして受け入れられることはない。
【００３７】
プロセスデータ取得タイミングの評価値の算出法には様々なやり方が考えられる。例えば、仮タイミングにプロセスデータをスケジュールした場合に、情報収集装置1及び当該プロセスデータを管理するビル側通信装置31にかかる通信負荷の最大値がどれだけ増加するか、その増分の和を算出する方法がある。この場合、通信負荷最大値の増分和が小さいほど、その仮タイミングの評価値が高いとする。この方法は、情報収集装置1にかかる通信負荷（第1通信負荷）の最大値と、各ビル側通信装置31にかかる通信負荷（第２通信負荷）の最大値との重み付け合計をできるだけ小さくする（最小もしくは閾値以下にする）ことに相当する。情報収集装置１およびビル側通信装置31に対する重みは等しく１としてもよいし、装置に応じて重みを変えても良い。
【００３８】
別の算出法としては、情報収集装置1及びビル側通信装置31の持つ通信余力、つまり許容通信負荷と現在の通信負荷の差分に基づいて評価値を算出する方法がある。この場合、通信余力が大きいほど評価値が高いとする。この方法は、情報収集装置の許容通信負荷（第1許容通信負荷）と上記第1通信負荷との差分の最小値と、ビル側通信装置31の許容通信負荷（第２許容通信負荷）と上記第2通信負荷との差分の最小値との重み付け合計を、最大もしくは閾値以上にすることに相当する。
【００３９】
ステップS106で候補タイミングが更新された場合、その候補タイミングがタイミング決定アルゴリズムの終了条件を満たしているかどうか検証する(ステップS107)。終了条件は例えば、その候補タイミングにおける通信負荷の評価値が理論的に最高のものである場合に満足される。あるいは、情報収集装置1の計算リソースが限られている場合は、仮タイミングの探索回数がある上限に達した場合に終了条件を満たしたものとして探索を中断してもよい。終了条件が満たされた場合、これ以上の仮タイミングの探索は行われない。これにより、スケジューリングに必要な計算量を削減することができる。
【００４０】
ステップS105において仮タイミングの評価値が候補タイミングの評価値を上回らなかった場合や、ステップS107において候補タイミングが終了条件を満たさなかった場合、プロセスデータ取得周期内の全ての仮タイミングについて評価を行ったかどうかが判断される(ステップS108)。まだ評価されていないタイミングが存在する場合、それらの中から一つが仮タイミングとして選ばれ(ステップS109)、その仮タイミングの評価が行われる(ステップS105へ戻る)。ステップS109において次の仮タイミングを定める方法はいくつかある。例えば、未検証の仮タイミングを逐次昇順に選択したり、あるいはそれらの中からランダムに一つを選んだりすればよい。
【００４１】
ステップS108にて、全ての仮タイミングの評価が終了したと判断された場合、候補タイミングが存在するかどうかが検証される(ステップS110)。候補タイミングが存在しない場合というのは、いずれの仮タイミングにおいても、当該プロセスデータをスケジュールした際に情報収集装置1もしくはビル側通信装置31にかかる通信負荷が許容通信負荷を超えてしまった場合である。この場合、当該プロセスデータをスケジュールに組み込むことができず、何らかの対応が必要となる(ステップS111)。この時の対応には様々な方法が考えられる。例えば、情報収集装置1がその管理者にエラーを報告し、管理者に判断を促すといったことが行われる。また、これまでのスケジューリングは既存の収集スケジュールを変更しないように行われてきたが、ステップS111に到達した時点で既存の収集スケジュールを破棄し、ビル設備情報保持部101に格納された全てのビル設備32について収集スケジュールの再作成を試みてもよい。いずれにせよ、情報収集装置1がどのような試みをしても、情報収集装置1やビル側通信装置31の許容通信負荷を満足するスケジュールの作成が不可能な場合、管理者に対してエラーが報告される。この場合、情報収集装置1の管理者は収集対象とするビル設備32の取捨選択を行ったり、情報収集装置1の増設を行ったり、ビル側通信装置31の管理者やビル3の管理者らと対応を協議したりすることになる。
【００４２】
ステップS107で候補タイミングが終了条件を満たした場合や、ステップS110で候補タイミングが存在している場合、この候補タイミングを採用して、プロセスデータをスケジュールに組み込む(ステップS112)。この際、当該プロセスデータを管理するビル側通信装置通信スケジュール保持部107及び情報収集装置通信スケジュール保持部108に格納されている図5および図4の表において、候補タイミング及び候補タイミングからプロセスデータ取得周期の整数倍の時間離れたタイミングに対応する行が更新される。具体的には、これらの行におけるデータ識別子リストの列に当該プロセスデータの識別子が追加され、通信負荷の列に当該プロセスデータのデータサイズが加算される。
【００４３】
ビル側通信装置通信スケジュール保持部107と情報収集装置通信スケジュール保持部108に格納された収集スケジュール情報が更新されると、データ要求送信タイミング決定部104がデータ要求送信スケジュール保持部109に格納されたデータ要求送信スケジュールを更新する(ステップS113)。データ要求送信タイミング決定部104は、ビル設備情報保持部101を参照して追加されたプロセスデータの応答時間を取り出し、収集スケジュールに追加されたプロセスデータの取得タイミングから応答時間を減算することで、データ要求の適切な送信時刻を算出する。図6の表において、算出された送信時刻に対応する行に当該プロセスデータの識別子が追加されることで、データ要求送信スケジュールの更新が行われる。
【００４４】
以上では、新たなビル設備32をスケジュールに追加する際の動作を説明した。図8は、スケジュール済みのビル設備32をスケジュールから削除する際の動作の流れを表したフローチャートである。
【００４５】
ビル設備32をスケジュールから削除する場合、まず、当該ビル設備32をデータ要求送信スケジュール保持部109から削除する(ステップS201)。これは、図6の表から当該ビル設備32のデータ識別子を削除することで行われる。
【００４６】
次に、当該ビル設備32を情報収集装置通信スケジュール保持部108から削除する(ステップS202)。これは、図4の表から、当該ビル設備32のデータ識別子を削除することで行われる。この際、図4の表において、データ識別子が削除された行の通信負荷の列も更新される。同様に、当該ビル設備32はビル側通信装置通信スケジュール保持部107からも削除される(ステップS203)。これは、図5の表から、当該ビル設備32のデータ識別子を削除することで行われる。この際、図5の表において、データ識別子が削除された行の通信負荷の列も更新される。
【００４７】
最後に、当該ビル設備32をビル設備情報保持部101から削除する(ステップS204)。これは、当該ビル設備32のデータ識別子に対応する行を破棄することで行われる。
【００４８】
スケジュール済みのビル設備32の情報を変更したい場合、図3の表のうち、どのビル設備情報を更新するかで動作が異なる。応答時間の変更を行う場合、ビル設備情報保持部101を更新し、図7のステップS113で示した処理によってデータ要求送信スケジュールを更新すればよい。
【００４９】
スケジュール済みのビル設備32のデータサイズを変化させる場合、ビル設備情報保持部101を更新後、ビル側通信装置通信スケジュール保持部107と情報収集装置通信スケジュール保持部108に変更を加え、当該プロセスデータを収集する時間帯における通信負荷の値を適切に更新する。その際、更新後の通信負荷が許容通信負荷を超える場合は、データサイズの更新は失敗となる。その場合は、当該ビル設備32を一旦スケジュールから削除し、データサイズを更新した状態で再度スケジュールに追加するとよい。それでもスケジューリングに失敗する場合、データサイズを変更するのは不可能である。
【００５０】
スケジュール済みのビル設備32の取得周期を変更する場合、既存のスケジュールを維持して更新を行うのは難しい。そのため、ビル設備32を一旦スケジュールから削除し、取得周期を更新して再度スケジュールに追加するとよい。
【００５１】
以上、収集スケジュールにおけるビル設備32の追加、削除、変更といった操作について説明した。これらの操作によって作成されたデータ要求送信スケジュールはネットワーク通信部105に参照され、実際にデータ要求パケットの送信が行われる。図9は、ネットワーク通信部105が行うプロセスデータ収集の動作を示したフローチャートである。
【００５２】
ネットワーク通信部105は、起動するとまずタイマ111をリセットする(ステップS301)。タイマ111は、最後にリセットされた時刻からの経過時間を、現在時刻としてネットワーク通信部105に提供する。
【００５３】
次に、ネットワーク通信部105はデータ要求送信スケジュール保持部109からデータ要求送信スケジュールを読み込む(ステップS302)。読み込んだスケジュールはネットワーク通信部105の内部に一時保存される。
【００５４】
ネットワーク通信部105は、ステップS302で読み込んだデータ要求送信スケジュールとタイマ111を参照し、現在時刻が次にプロセスデータを要求すべき時刻になるか、または現在時刻が収集スケジュール周期の終端に到達するまで待機する(ステップS303)。
【００５５】
現在時刻が収集スケジュール周期の終端に到達していない場合(ステップS304)、ネットワーク通信部105が動作を起こすのは、次のプロセスデータを要求すべき時刻に到達した時である(ステップS305)。この時、ネットワーク通信部105は、読み込み済みのデータ要求送信スケジュールを参照し、現在時刻において要求すべきプロセスデータ識別子のリストを取得する。また、ネットワーク通信部105は、ビル設備情報保持部101にアクセスして、プロセスデータ要求パケットを送信すべきビル側通信装置31の識別子を取得する。その後、ネットワーク通信部105はこれらのビル側通信装置31へ適切なプロセスデータ要求パケットを送信する(ステップS306)。送信が完了すると、ネットワーク通信部105は再び待機する(ステップS303に戻る)。
【００５６】
プロセスデータ要求時刻を待っている際に現在時刻が収集スケジュール周期の終端に到達した場合(ステップS304)、ネットワーク通信部105はタイマ111をリセットする(ステップS307)。これにより、新しい収集周期のプロセスデータ収集が開始される。また、タイマをリセットすると同時に、ネットワーク通信部105はデータ要求送信スケジュール保持部109から再びデータ要求送信スケジュールを読み込む(ステップS308)。プロセスデータ収集中にデータ要求送信スケジュール保持部109に対して行われた更新は、このタイミングでネットワーク通信部105に反映される。
【００５７】
ビル側通信装置31がネットワーク通信部105からデータ要求パケットを受信すると、要求されたビル設備32のプロセスデータを情報収集装置1へ返送する。この時返送するプロセスデータは、ビル側通信装置31がデータ要求パケットを受信した時点で当該ビル設備32に問い合わせて取得してもよいし、ビル側通信装置31があらかじめ記憶していたものを使ってもよい。ネットワーク通信部105はビル側通信装置31からプロセスデータを受信すると、そのデータをプロセスデータベース110へ追加する。
【００５８】
本実施形態では、通信負荷はデータサイズに基づいていたが、本実施形態の変形例として、プロセスデータの個数を用いてもよい。
【００５９】
この場合、ビル側通信装置から単位期間当たりに受信するプロセスデータの合計数（第３通信負荷）と、ビル側通信装置が単位期間当たりに送信するプロセスデータ数（第４通信負荷）とを単位期間間で平準化するように、ビル側通信装置からのプロセスデータの収集スケジュールを作成すればよい。たとえば、当該第３通信負荷の最大値と、各ビル側通信装置毎の当該第４通信負荷の最大値との重み付け合計を最小化もしくは閾値以下にするように、収集スケジュールを作成する。情報収集装置１およびビル側通信装置31に対する重みは、等しく１としてもよいし、装置に応じて重みを変えても良い。
【００６０】
また、本変形例の場合、ビル側通信装置３１の許容通信負荷（第３許容通信負荷）は、ビル側通信装置が単位期間当たりに送信することを許容されたプロセスデータの最大数を表し、情報収集装置１の許容通信負荷（第４許容通信負荷）は、ビル側通信装置３２全体から単位期間当たりに受信することを許容されたプロセスデータの最大数を表すこととなる。これら第３および第４許容通信負荷を用いたスケジューリング方法では、第３許容通信負荷と上記第３通信負荷との差分の最小値と、第４許容通信負荷と上記第４通信負荷との差分の最小値との重み付け合計を、最大もしくは閾値以上にするように、収集スケジュールを作成することが可能である。
【００６１】
本変形例は、通信負荷の内容が、データ量がデータ個数に変わった点以外は、これまで述べて来た実施形態と同様であり、前述した内容がそのまま適用可能である。
【００６２】
以上、本実施形態によれば、情報収集装置および各ビル側通信装置全てにかかる通信負荷を時間的に平準化し、特定の時間に通信負荷が集中することを防ぐことができる。
【００６３】
また、ビル設備ごとに要求されるプロセスデータ取得周期が異なる場合であっても、それらを満たすスケジュールを作成することができる。
【００６４】
また、ビル設備ごとに要求されるプロセスデータ取得周期が異なる場合であっても、それに適応してスケジュール周期を動的に変更することができる。このため、プロセスデータ取得周期が前もって明らかになっていない場合であっても、ビル設備をスケジュールすることができる。
【００６５】
また、収集スケジュールを作成する際に、情報収集装置や各ビル側通信装置の通信負荷の許容最大値を設定できる。これにより、いずれの装置においても所定の通信負荷を超えないような収集スケジュールを作成することができる。また、所定の通信負荷を超えないような収集スケジュールの作成が不可能な場合、情報収集装置の管理者にエラーを報告し、情報収集装置の増設や収集対象とするビル数の再検討などを促すことができる。
【００６６】
なお、本実施形態では１つのプロセスデータは１つの単位期間（１分）以内に収集される例を示したが、１つのプロセスデータが２つ以上の単位期間にわたって収集されてもよい。
【００６７】
(第2の実施形態)
本発明の第1の実施形態では、各ビル設備32のプロセスデータ収集タイミングはそれぞれ独立に決定されていた。しかし、実際には、複数の関連するビル設備32のプロセスデータを、特定の相対タイミングで収集しなければならない場合がある。例えば、ビル設備中間管理装置33には、ビル側通信装置31からのアクセス頻度に上限を設けているものがある。このような制限を満足するためには、当該ビル設備中間管理装置33に接続されているビル設備32のプロセスデータ取得タイミングについて制限を与えた上でスケジューリングを行わなければならない。また、もう一つの例としては、複数のビル設備32のプロセスデータを同じタイミングで取得したい場合が挙げられる。これは例えば、空調設備を制御する都合上、同じフロアにある温度センサの計測値は同時に取得したいといった場合である。このような時にも、複数のビル設備32の間の相対的なプロセスデータ取得タイミングを定義する必要がある。
【００６８】
情報収集装置1に対する以上の要求を鑑みて、本実施形態では、複数のプロセスデータの間の相対的な取得タイミングを設定し、それを満たした収集スケジュールの作成を可能とする。本実施形態における遠隔情報収集システム全体の構成は図1と同じであるため、図示及び説明を省略する。ただし、本実施形態では、図1の情報収集装置1は情報収集装置1aに置き換わる。
【００６９】
図10に、本実施形態における情報収集装置1aの内部構成図を示す。本実施形態では、図2に示した第1の実施形態の構成に比べ、ビル設備チェーン作成部112とビル設備チェーン保持部113が追加され、ビル設備情報保持部101がビル設備情報保持部101aに、スケジュール周期調整部102がスケジュール周期調整部102aに、スケジュール作成部103がスケジュール作成部103aに置き換わっている。それ以外の要素については、本実施形態と第1の実施形態で共通しているため、説明を省略する。
【００７０】
ビル設備情報保持部101aは、第1の実施形態で格納していたビル設備情報に加え、ビル設備32相互のプロセスデータ取得タイミングに関する制約条件の情報を格納する。図11に、ビル設備情報保持部101aに格納されるビル設備情報の例を示す。図11の表の、依存先データ識別子の列と相対時間の列の情報によって、プロセスデータ相互の取得タイミングに関する制約条件を記述している。例えば、図11においてデータ識別子2番のプロセスデータは、データ識別子1番のプロセスデータに対して取得タイミングが依存している。この例の場合、データ識別子2番のプロセスデータは、データ識別子1番のプロセスデータを取得した1分後に取得しなければならない。同様に、データ識別子4番のプロセスデータは、データ識別子2番のプロセスデータと同時に取得しなければならず、従って、データ識別子1番のプロセスデータの1分後に取得しなければならない。なお、データ識別子1番自身は依存先のプロセスデータを持たないため、依存先データ識別子の列にはそのことを示す"NULL"が記載されている。この場合でも、他のプロセスデータ(例えば、データ識別子2番のデータ)から依存されることによって、プロセスデータ間の取得タイミング制約が発生し得る。
【００７１】
ビル設備チェーン作成部112は、ビル設備情報保持部101aを参照し、ビル設備チェーンというデータ構造を作成する。ビル設備チェーンとは、相対的な取得タイミングについて制約条件を持つビル設備32を時間軸上に並べて管理したデータ構造である。本実施形態においては、取得タイミングはプロセスデータごとに決定されるのではなく、ビル設備チェーンごとに決定される。ビル設備チェーンに含まれるビル設備32のプロセスデータ取得タイミングは、そのビル設備チェーンの取得開始タイミングに対し、制約条件によって相対的に定められている。そのため、ビル設備チェーンの取得開始タイミングが決定されれば、それに含まれる全てのビル設備32のプロセスデータ取得タイミングが決定される。このように、ビル設備相互のプロセスデータ取得タイミングの制約条件をあらかじめ満たす形でビル設備チェーンを構築することで、それらの制約条件を満たしたスケジューリングが可能となる。なお、プロセスデータ取得タイミングについて他のビル設備32と全く制約条件を持たないビル設備32については、そのビル設備32のみを含むビル設備チェーンが作成される。
【００７２】
ビル設備チェーン保持部113は、ビル設備チェーン作成部112によって作成されたビル設備チェーンを格納する。図12は、ビル設備チェーン保持部113に格納された情報の例を示したものであり、図11に記載のビル設備情報を元に作成されたものである。図12の表において、ビル設備チェーン識別子の列はビル設備チェーンを一意に区別する識別子を表し、ビル設備チェーン周期の列はそのビル設備チェーン全体を取得する周期を表す。残るデータ識別子と相対取得タイミングの列に、ビル設備チェーンに含まれるビル設備32のデータ識別子とその相対的な取得タイミングが格納される。図11では、データ識別子1番, 2番, 4番のプロセスデータの取得タイミングに制約条件が課せられていた。そのため、ビル設備チェーン作成部112によってこれらのプロセスデータを含むビル設備チェーンが作成され、ビル設備チェーン識別子1番としてビル設備チェーン保持部113に格納されている。相対取得タイミングは、ビル設備チェーンの取得開始タイミングを起点とした相対的な取得タイミングであり、その起点をいつとして設定するかについては任意性がある。図12の例では、ビル設備チェーンに含まれるビル設備32のうち、もっともプロセスデータ取得タイミングの早いものを起点として相対取得タイミングの値を設定している。なお、同じビル設備チェーンに入るビル設備32のプロセスデータ取得周期は等しくなければならない。そうでなければ、取得タイミングの相対時刻を定義することができないからである。
【００７３】
第1の実施形態におけるスケジュール周期調整部102はプロセスデータの取得周期に応じてスケジュール周期の調整を行っていた。それに対し、本実施形態におけるスケジュール周期調整部102aは、ビル設備チェーン保持部113に格納されたビル設備チェーンの取得周期に応じてスケジュール周期の調整を行う。調整の方法は第1の実施形態と本実施形態で同じである。
【００７４】
本実施形態におけるスケジュール作成部103aは、ビル設備チェーン保持部113に格納されたビル設備チェーンの取得開始タイミングを決定する。タイミングの決定法は第1の実施形態におけるスケジュール作成部103とほぼ同様であり、ビル設備チェーンをスケジュールに追加した際に、情報収集装置1a及びビル側通信装置31にかかる通信負荷が平準化されるような取得開始タイミングを選択する。情報収集装置1aまたはビル側通信装置31にかかる通信負荷がどのようにしても許容される通信負荷を超えてしまう場合、スケジュール作成部103aはスケジュール作成処理を中断し、情報収集装置1aの管理者にエラーを報告する。ビル設備チェーンの取得開始タイミングが決定されると、スケジュール作成部103aはそのビル設備チェーンに含まれるビル設備32のプロセスデータ取得タイミングを計算する。プロセスデータ取得タイミングは、ビル設備チェーンの取得開始タイミングに図12の相対取得タイミングの値を加算したものとして計算される。個々のプロセスデータ取得タイミングが計算されると、ビル設備チェーン内のビル設備32は、第1の実施形態と同様にビル側通信装置通信スケジュール保持部107と情報収集装置通信スケジュール保持部108へ追加される。
【００７５】
次に、本実施形態における情報収集装置1aの動作について、図13のフローチャートを用いて説明する。このフローチャートでは、既に収集対象としているビルに対して、新たなビル設備チェーンを構成する複数のビル設備32が増設され、それらのプロセスデータを収集スケジュールに追加する際の動作を示したものである。この動作の流れは、第1の実施形態にて図7を用いて説明した、ビル設備32を増設する際の動作の流れとほぼ同じである。よって、以降では、本実施形態と第1の実施形態との差分を中心に説明し、それ以外については適宜説明を省略する。
【００７６】
まず、増設された新たなビル設備32群の情報が、ビル設備情報保持部101aに登録される(ステップS101a)。ここで登録される情報には、図11にある依存先データ識別子や相対時間の情報が含まれる。
【００７７】
ビル設備情報保持部101aに登録されたビル設備32群の情報を参照し、ビル設備チェーン作成部112がビル設備チェーンを作る(ステップS114)。新たに作成されたビル設備チェーンは、ビル設備チェーン保持部113に追加される。ここでは、新たに作成されたビル設備チェーンは一つとする。複数のビル設備チェーンが作成された場合、以降のステップはビル設備チェーンごとに繰り返される。
【００７８】
スケジュール周期調整部102aが、追加されるビル設備チェーンの取得周期とスケジュール周期を参照し、スケジュール周期が新たに収集するビル設備チェーンの取得周期の倍数であるか調べる(ステップS102a)。倍数でない場合、第1の実施形態と同様の処理によって、スケジュール周期の調整を行う(ステップS103)。
【００７９】
スケジュール周期の調整が終わると、スケジュール作成部103aによってビル設備チェーンの取得開始タイミングを決定する処理が行われる。第1の実施形態におけるスケジュール作成部103の動作と同様、ビル設備チェーンの取得開始タイミングを仮に設定し、その仮タイミングにおける情報収集装置1a及び関連するビル側通信装置31にかかる通信負荷の評価を行う。仮タイミングを変化させながら通信負荷の評価を行い、評価値が最高になるものを候補タイミングとして記憶する(ステップS104〜ステップS110)。
【００８０】
ステップS105aにおいて、スケジュール作成部103aは仮タイミングの評価を行う。ここで、ビル設備チェーンに含まれるビル設備32群は、それぞれを管理しているビル側通信装置31が互いに異なっている可能性がある。その場合、それらのビル側通信装置31全ての通信負荷を考慮するような評価値の算出法が必要となる。これは例えば、情報収集装置1a及び当該ビル設備チェーンに関わるビル側通信装置31全ての通信負荷最大値の増分を足し合わせたり、あるいはそれらの通信余力を足し合わせたりするなどして評価値を算出すればよい。
【００８１】
仮タイミングの探索が終了した時点で候補タイミングが存在している場合、その候補タイミングでビル設備チェーンがスケジュールに追加される(ステップS112a)。ビル設備チェーンをスケジュールに追加するには、そのビル設備チェーンに含まれるビル設備32を一つずつスケジュールに追加すればよい。その際、追加するビル設備32のプロセスデータ取得タイミングは、図12の表の相対取得タイミングの値に候補タイミングの値を加算した値が用いられる。
【００８２】
ビル設備チェーンがスケジュールに追加され、ビル側通信装置通信スケジュール保持部107と情報収集装置通信スケジュール保持部108が更新されると、それらの情報を参照してデータ要求送信タイミング決定部104がデータ要求送信スケジュールの更新を行う(ステップS113)。この処理は第1の実施形態で示したものと同一である。
【００８３】
以上では、ビル設備32群を追加する際の動作について説明した。ビル設備32をスケジュールから削除する際の動作の流れを図14に示す。この動作は、その多くが第1の実施形態で説明したもの(図8)と同じである。本実施形態と第1の実施形態との間で異なる点は、本実施形態では、ビル設備情報保持部101aを更新する前に、ビル設備チェーン保持部113から当該ビル設備32を削除する(ステップS205)ことである。この際、図12の表の、当該ビル設備32のデータ識別子を含む行が削除される。
【００８４】
スケジュール済みのビル設備32の情報を変更する場合、変更対象が応答時間やデータサイズであれば第1の実施形態と同様の手続きで変更が可能である。変更対象が図11の表の取得周期、依存先データ識別子、相対時間のいずれかである場合、当該ビル設備32を含むビル設備チェーンに含まれるビル設備32群を全て削除して、それらを再度スケジュールへ追加するとよい。また、ビル設備32の依存先を切り替える場合、新たに依存先とするビル設備を含むビル設備チェーンも再スケジュールする必要がある。
【００８５】
以上で説明した各種操作によって、データ要求送信スケジュールが作成される。ネットワーク通信部105は、作成されたデータ要求送信スケジュールに基づいてビル側通信装置31と通信し、プロセスデータを収集する。その動作の流れは第1の実施形態と同一である(図9)。
【００８６】
以上、本実施形態によれば、異なるビル設備のプロセスデータ取得タイミングの間に制約条件がある場合であっても、それを満足したプロセスデータ収集が可能となる。
【符号の説明】
【００８７】
1、1a…情報収集装置
2…ネットワーク
3…ビル
31…ビル側通信装置
32…ビル設備
33…ビル設備中間管理装置
101、101a…ビル設備情報保持部
102、102a…スケジュール周期調整部
103、103a…スケジュール作成部
104…データ要求送信タイミング決定部
105…ネットワーク通信部
106…スケジュール周期保持部
107…ビル側通信装置通信スケジュール保持部
108…情報収集装置通信スケジュール保持部
109…データ要求送信スケジュール保持部
110…プロセスデータベース
111…タイマ
112…ビル設備チェーン作成部
113…ビル設備チェーン保持部
【特許請求の範囲】
【請求項１】
複数のビル側通信装置からそれぞれ１つ以上のプロセスデータを順次収集する遠隔情報収集装置であって、
各前記ビル側通信装置から収集するプロセスデータのデータサイズを記憶するビル設備情報保持部と、
時間的に連続する複数の単位期間を含む収集期間において、各前記ビル側通信装置から前記単位期間当たりに受信する合計データ量を表す第1通信負荷と、各前記ビル側通信装置によりそれぞれ前記単位期間当たりに送信されるデータ量を表す第2通信負荷とを前記単位期間間で平準化するように、各前記ビル側通信装置からの各前記プロセスデータの収集スケジュールを作成するスケジュール作成部と、
前記収集スケジュールにしたがって、各前記ビル側通信装置から前記プロセスデータを収集するネットワーク通信部と、
を備えた遠隔情報収集装置。
【請求項２】
タイミング決定部をさらに備え、
前記ビル設備情報保持部は、前記プロセスデータ毎に前記ビル側通信装置に前記プロセスデータの取得要求を送信してから前記プロセスデータの受信までに要する応答時間を特定するための情報を記憶し、
前記タイミング決定部は、前記情報と前記収集スケジュールに従って、前記プロセスデータの取得要求の送信タイミングを決定し、
前記ネットワーク通信部は、前記タイミング決定部で決定されたタイミングで前記取得要求を送信し、前記ビル側通信装置から前記プロセスデータを受信する
ことを特徴とする請求項１に記載の遠隔情報収集装置。
【請求項３】
前記スケジュール作成部は、
前記第1通信負荷が第1許容通信負荷以下になるように、かつ、前記第２通信負荷が第2許容通信負荷以下になるように、前記収集スケジュールを作成する
ことを特徴とする請求項1または２に記載の遠隔情報収集装置。
【請求項４】
前記スケジュール作成部は、前記第1通信負荷の最大値と、前記第2通信負荷の最大値との重み付け合計を、最小もしくは閾値以下にするように、前記収集スケジュールを作成する
ことを特徴とする請求項１ないし３のいずれか一項に記載の遠隔情報収集装置。
【請求項５】
前記スケジュール作成部は、前記第1許容通信負荷と前記第1通信負荷との差分の最小値と、前記第2許容通信負荷と前記第2通信負荷との差分の最小値との重み付け合計を、最大もしくは閾値以上にするように、前記収集スケジュールを作成する
ことを特徴とする請求項３に記載の遠隔情報収集装置。
【請求項６】
前記ビル設備情報保持部は、各前記プロセスデータの取得周期の情報を含み、
前記収集期間は、各前記プロセスデータの取得周期の公倍数であり、
前記収集期間ごとに、前記収集スケジュールが実行される
ことを特徴とする請求項1ないし５のいずれか一項に記載の遠隔情報収集装置。
【請求項７】
前記ビル設備情報保持部は、前記プロセスデータ間の取得タイミングに関する制約条件を含み、
前記スケジュール作成部は、前記制約条件を満たすように、前記収集スケジュールを作成する
ことを特徴とする請求項1ないし６のいずれか一項に記載の遠隔情報収集装置。
【請求項８】
１つのプロセスデータは、１つの単位期間内で収集される
ことを特徴とする請求項１ないし７のいずれか一項に記載の遠隔情報収集装置。
【請求項９】
複数のビル側通信装置からそれぞれ１つ以上のプロセスデータを順次収集する遠隔情報収集装置であって、
時間的に連続する複数の単位期間を含む収集期間において、各前記ビル側通信装置から前記単位期間当たりに受信する合計プロセスデータ数を表す第３通信負荷と、各前記ビル側通信装置によりそれぞれ前記単位期間当たりに送信されるプロセスデータ数を表す第４通信負荷とを前記単位期間間で平準化するように、各前記ビル側通信装置からの各前記プロセスデータの収集スケジュールを作成するスケジュール作成部と、
前記収集スケジュールにしたがって、各前記ビル側通信装置から前記プロセスデータを収集するネットワーク通信部と、
を備えた遠隔情報収集装置。
【請求項１０】
タイミング決定部をさらに備え、
前記ビル設備情報保持部は、前記プロセスデータ毎に前記ビル側通信装置に前記プロセスデータの取得要求を送信してから前記プロセスデータの受信までに要する応答時間を特定するための情報を記憶し、
前記タイミング決定部は、前記情報と前記収集スケジュールに従って、前記プロセスデータの取得要求の送信タイミングを決定し、
前記ネットワーク通信部は、前記タイミング決定されたタイミングで前記取得要求を送信し、前記ビル側通信装置から前記プロセスデータを受信する
ことを特徴とする請求項９に記載の遠隔情報収集装置。
【請求項１１】
前記スケジュール作成部は、前記第３通信負荷が第３許容通信負荷以下になるように、かつ、前記第４通信負荷が第４許容通信負荷以下になるように、前記収集スケジュールを作成する
ことを特徴とする請求項９または１０に記載の遠隔情報収集装置。
【請求項１２】
前記スケジュール作成部は、前記第３通信負荷の最大値と、前記第４通信負荷の最大値との重み付け合計を、最小もしくは閾値以下にするように、前記収集スケジュールを作成する
ことを特徴とする請求項９ないし１１のいずれか一項に記載の遠隔情報収集装置。
【請求項１３】
前記スケジュール作成部は、前記第３許容通信負荷と前記第３通信負荷との差分の最小値と、前記第４許容通信負荷と前記第４通信負荷との差分の最小値との重み付け合計を、最大もしくは閾値以上にするように、前記収集スケジュールを作成する
ことを特徴とする請求項１１に記載の遠隔情報収集装置。
【請求項１４】
前記ビル設備情報保持部は、各前記プロセスデータの取得周期の情報を含み、
前記収集期間は、各前記プロセスデータの取得周期の公倍数であり、
前記収集期間ごとに、前記収集スケジュールが実行される
ことを特徴とする請求項９ないし１３のいずれか一項に記載の遠隔情報収集装置。
【請求項１５】
前記ビル設備情報保持部は、前記プロセスデータ間の取得タイミングに関する制約条件を含み、
前記スケジュール作成部は、前記制約条件を満たすように、前記収集スケジュールを作成する
ことを特徴とする請求項９ないし１４のいずれか一項に記載の遠隔情報収集装置。
【請求項１６】
１つのプロセスデータは、１つの単位期間内で収集される
ことを特徴とする請求項９ないし１５のいずれか一項に記載の遠隔情報収集装置。
【請求項１７】
複数のビル側通信装置からそれぞれ１つ以上のプロセスデータを順次収集するためのプログラムであって、
コンピュータに、
各前記ビル側通信装置から収集するプロセスデータのデータサイズを記憶するビル設備情報保持部にアクセスするステップと、
時間的に連続する複数の単位期間を含む収集期間において、各前記ビル側通信装置から前記単位期間当たりに受信する合計データ量を表す第1通信負荷と、各前記ビル側通信装置によりそれぞれ前記単位期間当たりに送信されるデータ量を表す第2通信負荷とを前記単位期間間で平準化するように、各前記ビル側通信装置からの各前記プロセスデータの収集スケジュールを作成するスケジュール作成ステップと、
前記収集スケジュールにしたがって、各前記ビル側通信装置から前記プロセスデータを収集する通信ステップと、
を実行させるためのプログラム。
【請求項１８】
複数のビル側通信装置からそれぞれ１つ以上のプロセスデータを順次収集するためのプログラムであって、
コンピュータに、
時間的に連続する複数の単位期間を含む収集期間において、各前記ビル側通信装置から前記単位期間当たりに受信する合計プロセスデータ数を表す第３通信負荷と、各前記ビル側通信装置によりそれぞれ前記単位期間当たりに送信されるプロセスデータ数を表す第４通信負荷とを前記単位期間間で平準化するように、各前記ビル側通信装置からの各前記プロセスデータの収集スケジュールを作成するスケジュール作成ステップと、
前記収集スケジュールにしたがって、各前記ビル側通信装置から前記プロセスデータを収集する通信ステップと、
を実行させるためのプログラム。
【請求項１】
複数のビル側通信装置からそれぞれ１つ以上のプロセスデータを順次収集する遠隔情報収集装置であって、
各前記ビル側通信装置から収集するプロセスデータのデータサイズを記憶するビル設備情報保持部と、
時間的に連続する複数の単位期間を含む収集期間において、各前記ビル側通信装置から前記単位期間当たりに受信する合計データ量を表す第1通信負荷と、各前記ビル側通信装置によりそれぞれ前記単位期間当たりに送信されるデータ量を表す第2通信負荷とを前記単位期間間で平準化するように、各前記ビル側通信装置からの各前記プロセスデータの収集スケジュールを作成するスケジュール作成部と、
前記収集スケジュールにしたがって、各前記ビル側通信装置から前記プロセスデータを収集するネットワーク通信部と、
を備えた遠隔情報収集装置。
【請求項２】
タイミング決定部をさらに備え、
前記ビル設備情報保持部は、前記プロセスデータ毎に前記ビル側通信装置に前記プロセスデータの取得要求を送信してから前記プロセスデータの受信までに要する応答時間を特定するための情報を記憶し、
前記タイミング決定部は、前記情報と前記収集スケジュールに従って、前記プロセスデータの取得要求の送信タイミングを決定し、
前記ネットワーク通信部は、前記タイミング決定部で決定されたタイミングで前記取得要求を送信し、前記ビル側通信装置から前記プロセスデータを受信する
ことを特徴とする請求項１に記載の遠隔情報収集装置。
【請求項３】
前記スケジュール作成部は、
前記第1通信負荷が第1許容通信負荷以下になるように、かつ、前記第２通信負荷が第2許容通信負荷以下になるように、前記収集スケジュールを作成する
ことを特徴とする請求項1または２に記載の遠隔情報収集装置。
【請求項４】
前記スケジュール作成部は、前記第1通信負荷の最大値と、前記第2通信負荷の最大値との重み付け合計を、最小もしくは閾値以下にするように、前記収集スケジュールを作成する
ことを特徴とする請求項１ないし３のいずれか一項に記載の遠隔情報収集装置。
【請求項５】
前記スケジュール作成部は、前記第1許容通信負荷と前記第1通信負荷との差分の最小値と、前記第2許容通信負荷と前記第2通信負荷との差分の最小値との重み付け合計を、最大もしくは閾値以上にするように、前記収集スケジュールを作成する
ことを特徴とする請求項３に記載の遠隔情報収集装置。
【請求項６】
前記ビル設備情報保持部は、各前記プロセスデータの取得周期の情報を含み、
前記収集期間は、各前記プロセスデータの取得周期の公倍数であり、
前記収集期間ごとに、前記収集スケジュールが実行される
ことを特徴とする請求項1ないし５のいずれか一項に記載の遠隔情報収集装置。
【請求項７】
前記ビル設備情報保持部は、前記プロセスデータ間の取得タイミングに関する制約条件を含み、
前記スケジュール作成部は、前記制約条件を満たすように、前記収集スケジュールを作成する
ことを特徴とする請求項1ないし６のいずれか一項に記載の遠隔情報収集装置。
【請求項８】
１つのプロセスデータは、１つの単位期間内で収集される
ことを特徴とする請求項１ないし７のいずれか一項に記載の遠隔情報収集装置。
【請求項９】
複数のビル側通信装置からそれぞれ１つ以上のプロセスデータを順次収集する遠隔情報収集装置であって、
時間的に連続する複数の単位期間を含む収集期間において、各前記ビル側通信装置から前記単位期間当たりに受信する合計プロセスデータ数を表す第３通信負荷と、各前記ビル側通信装置によりそれぞれ前記単位期間当たりに送信されるプロセスデータ数を表す第４通信負荷とを前記単位期間間で平準化するように、各前記ビル側通信装置からの各前記プロセスデータの収集スケジュールを作成するスケジュール作成部と、
前記収集スケジュールにしたがって、各前記ビル側通信装置から前記プロセスデータを収集するネットワーク通信部と、
を備えた遠隔情報収集装置。
【請求項１０】
タイミング決定部をさらに備え、
前記ビル設備情報保持部は、前記プロセスデータ毎に前記ビル側通信装置に前記プロセスデータの取得要求を送信してから前記プロセスデータの受信までに要する応答時間を特定するための情報を記憶し、
前記タイミング決定部は、前記情報と前記収集スケジュールに従って、前記プロセスデータの取得要求の送信タイミングを決定し、
前記ネットワーク通信部は、前記タイミング決定されたタイミングで前記取得要求を送信し、前記ビル側通信装置から前記プロセスデータを受信する
ことを特徴とする請求項９に記載の遠隔情報収集装置。
【請求項１１】
前記スケジュール作成部は、前記第３通信負荷が第３許容通信負荷以下になるように、かつ、前記第４通信負荷が第４許容通信負荷以下になるように、前記収集スケジュールを作成する
ことを特徴とする請求項９または１０に記載の遠隔情報収集装置。
【請求項１２】
前記スケジュール作成部は、前記第３通信負荷の最大値と、前記第４通信負荷の最大値との重み付け合計を、最小もしくは閾値以下にするように、前記収集スケジュールを作成する
ことを特徴とする請求項９ないし１１のいずれか一項に記載の遠隔情報収集装置。
【請求項１３】
前記スケジュール作成部は、前記第３許容通信負荷と前記第３通信負荷との差分の最小値と、前記第４許容通信負荷と前記第４通信負荷との差分の最小値との重み付け合計を、最大もしくは閾値以上にするように、前記収集スケジュールを作成する
ことを特徴とする請求項１１に記載の遠隔情報収集装置。
【請求項１４】
前記ビル設備情報保持部は、各前記プロセスデータの取得周期の情報を含み、
前記収集期間は、各前記プロセスデータの取得周期の公倍数であり、
前記収集期間ごとに、前記収集スケジュールが実行される
ことを特徴とする請求項９ないし１３のいずれか一項に記載の遠隔情報収集装置。
【請求項１５】
前記ビル設備情報保持部は、前記プロセスデータ間の取得タイミングに関する制約条件を含み、
前記スケジュール作成部は、前記制約条件を満たすように、前記収集スケジュールを作成する
ことを特徴とする請求項９ないし１４のいずれか一項に記載の遠隔情報収集装置。
【請求項１６】
１つのプロセスデータは、１つの単位期間内で収集される
ことを特徴とする請求項９ないし１５のいずれか一項に記載の遠隔情報収集装置。
【請求項１７】
複数のビル側通信装置からそれぞれ１つ以上のプロセスデータを順次収集するためのプログラムであって、
コンピュータに、
各前記ビル側通信装置から収集するプロセスデータのデータサイズを記憶するビル設備情報保持部にアクセスするステップと、
時間的に連続する複数の単位期間を含む収集期間において、各前記ビル側通信装置から前記単位期間当たりに受信する合計データ量を表す第1通信負荷と、各前記ビル側通信装置によりそれぞれ前記単位期間当たりに送信されるデータ量を表す第2通信負荷とを前記単位期間間で平準化するように、各前記ビル側通信装置からの各前記プロセスデータの収集スケジュールを作成するスケジュール作成ステップと、
前記収集スケジュールにしたがって、各前記ビル側通信装置から前記プロセスデータを収集する通信ステップと、
を実行させるためのプログラム。
【請求項１８】
複数のビル側通信装置からそれぞれ１つ以上のプロセスデータを順次収集するためのプログラムであって、
コンピュータに、
時間的に連続する複数の単位期間を含む収集期間において、各前記ビル側通信装置から前記単位期間当たりに受信する合計プロセスデータ数を表す第３通信負荷と、各前記ビル側通信装置によりそれぞれ前記単位期間当たりに送信されるプロセスデータ数を表す第４通信負荷とを前記単位期間間で平準化するように、各前記ビル側通信装置からの各前記プロセスデータの収集スケジュールを作成するスケジュール作成ステップと、
前記収集スケジュールにしたがって、各前記ビル側通信装置から前記プロセスデータを収集する通信ステップと、
を実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１２−２０５２７８（Ｐ２０１２−２０５２７８Ａ）
【公開日】平成２４年１０月２２日（２０１２．１０．２２）
【国際特許分類】
【出願番号】特願２０１１−７０７７１（Ｐ２０１１−７０７７１）
【出願日】平成２３年３月２８日（２０１１．３．２８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２４年１０月２２日（２０１２．１０．２２）
【国際特許分類】
【出願日】平成２３年３月２８日（２０１１．３．２８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]