JP6109555B2 - エネルギー管理サーバ、エネルギー管理方法およびプログラム - Google Patents

Description

本発明の実施形態は、ビルや工場などの比較的大規模な建物におけるエネルギー管理に資するエネルギー管理サーバ、エネルギー管理方法およびプログラムに関する。

ビルや工場などの建物はエネルギーを多量に消費する。エネルギー消費量は民生業務部門において特に大きく、最終的なエネルギー消費量の２０％にも達すると言われることから、省エネルギー施策が継続して求められている。また、近年の電力需給のひっ迫を受けて、大口の需要家には使用電力の上限が課せられるようになってきている。このためピーク時間帯における消費エネルギーを削減するピークカット技術や、蓄エネルギー機器を活用したピークシフト技術のニーズが高まってきている。

また、太陽光発電（Photovoltaic：ＰＶ）システム、風力発電システム、太陽熱利用システムなどの新エネルギー機器の導入も、今後いっそう加速すると見込まれる。この種の創エネルギー機器を効果的に利用するための、蓄電池や蓄熱装置などの蓄エネルギー機器にも注目が集まっている。

多様化するエネルギー関連機器を上手に連携させ、運用コストなどを最小化するために、エネルギー消費機器、創エネルギー機器、および蓄エネルギー機器を有機的に組み合わせて運転スケジュールを立案することが重要である。既存の手法により立案される運転スケジュールは、ビルや工場など、建物や設備単体で省エネ、省コストを図ることを目指すものである。

特許第４３９６５５７号公報

エネルギー供給事業者から需要家にエネルギー消費の抑制を求める、デマンドレスポンス（ＤＲ）と称する技術がある。ビルや工場がデマンドレスポンス信号を受信すると、省エネ目標値や節電目標値を変更する必要が生じるので、運転スケジュールも変更を求められる。

しかしながら、デマンドレスポンス信号の受信から運転スケジュールを即座に変更することは難しい。運転スケジュールを作成するための演算には１時間、あるいは２時間といった時間を要することもある。このため運転スケジュールの実行までに、作成された運転スケジュールの良否を判断するための時間や必要な設定を完了させるための時間を十分に取ることができず、各機器を有利なシナリオのもとで稼動させることが難しい。

さらに、蓄熱槽や蓄電池に前もってエネルギーを蓄積しておけばエネルギーコストをさらに削減できることが、運転スケジュールの算出過程で判明することがある。しかしながら運転スケジュールの作成に時間がかかればかかるほど、エネルギーを前もって蓄積するための時間が短くなる。特に、熱エネルギーに係わる機器（蓄熱装置や冷凍機など）の立ち上がりは一般に遅いので、計画の作成に時間がかかればその分、なおさら不利になる。

以上述べたように既存の技術では、デマンドレスポンス信号を受信すると不利な運転を余儀なくされるケースが多い。このような不具合を解決可能な技術が要望されている。
目的は、有利な運転スケジュールに基づく制御をデマンドレスポンス信号の受信から即座に開始することの可能なエネルギー管理サーバ、エネルギー管理方法およびプログラムを提供することにある。

実施形態によれば、エネルギー管理サーバは、予測部と、条件設定部と、計算部と、受信部と、制御部とを具備する。予測部は、エネルギー消費機器と蓄エネルギー機器とを含む電気機器に係わるデータに基づいて、当該電気機器の設置される建物におけるエネルギー需要量を予測する。条件設定部は、複数のエネルギー消費量の抑制条件を設定する。計算部は、エネルギー需要量と抑制条件とに基づいて、建物におけるエネルギー収支を最適化可能な電気機器の運転スケジュールを計算する。受信部は、エネルギー消費量の抑制条件を含むデマンドレスポンス信号を受信する。制御部は、デマンドレスポンス信号に含まれる抑制条件に対応する抑制条件で計算された運転スケジュールに基づいて電気機器を制御する。

図１は、実施形態に係わるエネルギー管理システムの一例を示すシステム図である。 図２は、ビル１内におけるエネルギーの流れの一例を示す図である。 図３は、第１の実施形態に係わるエネルギー管理サーバ４の一例を示す機能ブロック図である。 図４は、図３に示される機能ブロック間でのデータフローを示す図である。 図５は、第１の実施形態に係るエネルギー管理サーバ４の処理手順を示すフローチャートである。 図６は、第２の実施形態に係わるエネルギー管理サーバ４の一例を示す機能ブロック図である。 図７は、図６に示される機能ブロック間でのデータフローを示す図である。 図８は、第２の実施形態に係るエネルギー管理サーバ４の処理手順を示すフローチャートである。 図９は、第２の実施形態においてディスプレイ４２に表示される、スケジュール選択画面の一例を示す図である。 図１０は、図３に示される機能ブロック間でのデータフローの他の例を示す図である。

図１は、実施形態に係わるエネルギー管理システムの一例を示すシステム図である。図１において、建物としてのビル１は、通信ネットワークとしてのLocal Area Network（ＬＡＮ）８を備える。監視装置５、ローカルコントローラ３およびエネルギー管理サーバ４がＬＡＮ８に接続される。ＬＡＮ８の上位層プロトコルには例えばＢＡＣｎｅｔ（登録商標）を利用可能である。このようにすればシステム内に異ベンダシステムを混在させることが可能になる。

ローカルコントローラ３にはそれぞれ通信回線を介して制御対象機器２が接続される。ローカルコントローラ３は、それぞれ接続される制御対象機器２を被監視装置として認識し、その状態をモニタしたり、各種の制御を与えたりする。監視装置５はローカルコントローラ３から通知されるモニタ結果を受けエネルギー管理システムを上位レベルで制御したり、ユーザに各種の情報を提供したりする。

制御対象機器２は、エネルギー消費機器、創エネルギー機器および蓄エネルギー機器を含むことが可能である。フロアごとの空調機器、照明機器、動力機器、熱源機器、蓄熱装置、冷凍機、ＰＶシステム、および蓄電池などの電気機器を、制御対象機器２の一例として挙げることが可能である。

エネルギー管理サーバ４は、主としてビル１のエネルギー管理に係わる処理を担う。エネルギー管理サーバ４は、例えば建物管理者（ユーザ）からの要求（ピークシフト目標など）に基づいて制御対象機器２の起動停止（以下、発停と称する）スケジュールを作成したり、蓄電レベル設定などの蓄電蓄熱スケジュールを作成するなどの、処理を担う。

エネルギー管理サーバ４はＩＰ（Internet Protocol）ネットワーク９に接続され、事業者サーバ６からデマンドレスポンス信号（以下、ＤＲ信号と称する）を受信したり、気象サーバ７から気象データ（天気予報、時間帯ごとの気温など）を取得したりする。なおＩＰネットワークに代えて専用線ネットワークなどを利用することも可能である。

図２は、ビル１内におけるエネルギーの流れの一例を示す図である。図２において、蓄電池２０、ＰＶシステム２１、空冷ヒートポンプ（ＨＰ）２２、水冷冷凍機２３、吸収式冷温水器２５、蓄熱層２６、太陽熱温水器２７、および熱電併給システム（Co-Generation System：ＣＧＳ）２８を制御対象機器２の一例として挙げ、これらの機器間でのエネルギー授受の関係を以下に説明する。ビル１には、エネルギー源として例えば電力（受電）、およびガスが供給される。これらをエネルギー源として電気、および冷熱がビル１内各所に供給される。

受電された電力は、蓄電池２０に供給されて蓄積されるか、またはエネルギー消費機器に供給されて消費される。ＰＶシステム２１およびＣＧＳ２８で発電された電力も同様に蓄電池２０に蓄積されるか、エネルギー消費機器に供給される。例えば空冷ＨＰ２２や水冷冷凍機２３に供給された電力は、冷熱製造に消費される。

供給されたガスは、ＣＧＳ２８に供給される。ＣＧＳ２８は電力および温熱を生成し、それぞれ電力ラインおよび温水ラインに供給する。吸収式冷温水器２５は、ＣＧＳ２８、および太陽熱温水器２７で発生した温熱を供給され、冷熱を製造する。空冷ＨＰ２２、水冷冷凍機２３、および、吸収式冷温水器２５で製造された冷熱は、蓄熱槽２６に蓄積するか、あるいは熱需要で消費される。

図３は、第１の実施形態に係わるエネルギー管理サーバ４の一例を示す機能ブロック図である。エネルギー管理サーバ４は、入力部４１、ディスプレイ４２、インタフェース部４３、記憶部４６、Central Processing Unit（ＣＰＵ）４４、およびプログラムメモリ４５を備える。すなわちエネルギー管理サーバ４は、プログラムメモリ４５に記憶されたプログラムをＣＰＵ４４が実行することで機能するコンピュータである。

入力部４１は、ビル１を管理するユーザなどが操作するためのヒューマンマシンインタフェース（操作パネルやスイッチなど）である。入力部４１およびディスプレイ４２は、Graphical User Interface（ＧＵＩ）環境を形成してユーザによる情報入力を受け付け、また、ユーザに情報を提供する。

インタフェース部１３２はＬＡＮ８およびＩＰネットワーク９に接続され、監視装置５、ローカルコントローラ３、制御対象機器２およびリモートサーバ（事業者サーバ６、気象サーバ７など）との通信機能を担う。

記憶部４６は、実施形態に係るデータとして運転データベース１０８を記憶する。
プログラムメモリ４５は、この実施形態に係わる処理機能に必要な命令を含むプログラムとしての、デマンド予測プログラム１０１Ｐ、ＤＲ受付プログラム１０２Ｐ、ＤＲ定式化プログラム１０３Ｐ、スケジューリングプログラム１０４Ｐ、条件設定プログラム１０５Ｐ、削減可能量指定プログラム１０６Ｐ、気象データ受信プログラム１０７Ｐ、制御プログラム１０９Ｐ、および、検索プログラム１１０Ｐを記憶する。これらのプログラムは、ＣＤ−ＲＯＭなどのリムーバブルメディア（記録媒体）に記録することも、通信回線（ＩＰネットワーク９を含む）を介してダウンロードすることも可能である。

ＣＰＵ４４はプログラムメモリ４５から各プログラムを読み出してハードウェアによる演算処理を行うもので、その処理機能として、デマンド予測部１０１、ＤＲ受付部１０２、ＤＲ定式化部１０３、スケジューリング部１０４、条件設定部１０５、削減可能量指定部１０６、気象データ受信部１０７、制御部１０９、および、検索部１１０を備える。

デマンド予測部１０１は、制御対象機器２に係わるデータに基づいて、制御対象機器２の設置されるビル１における、例えば１時間ごとのエネルギー需要量、およびエネルギー生産量を予測する。制御対象機器２に係わるデータとは、例えば各制御対象機器２の特性（消費電力など）、制御対象機器２の動作設定、操作設定、蓄電池２０の容量、ＰＶシステム２１の発電特性などの情報を含むことが可能である。

ＤＲ受付部１０２は、ＤＲ信号を受信する。ＤＲ信号は普通、事業者サーバ６からＩＰネットワーク９を介して定期的、または不定期に与えられる。ＤＲ信号は、そのＤＲ信号の種類、電力消費の抑制を求める時間帯、インセンティブ、および電力消費量のベースラインなどの情報を含む。実施形態ではＤＲ信号に含まれる情報を総称して、エネルギー消費量の抑制条件と称する。

ＤＲ定式化部１０３は、受信されたＤＲ信号に含まれる抑制条件を定式化して、演算処理に利用可能な式を作成する。例えば、ＰＴＲ（Peak Time Rebate）と称する種類のＤＲ信号は、或る一定の時間帯における受電量のベースラインからの削減量に対してインセンティブが支払われる、というルール（抑制条件）を伴う。このＤＲ信号に含まれる抑制条件は、時間帯別電力料金、時間帯別インセンティブ、および時間帯別ベースライン、により表現することが可能である。

スケジューリング部１０４は、エネルギー需要量、エネルギー生産量、および定式化された抑制条件に基づいて、ビル１におけるエネルギー収支を最適化可能な、制御対象機器２の運転スケジュールを計算する。運転スケジュールは、それぞれの制御対象機器２を稼働させる際の設定、稼動時間、稼動期間などの情報を含むことが可能である。最適化の観点には種々あるが、例えば省エネ、省コスト、あるいは排出ＣＯ２削減などの観点を考えることが可能である。

条件設定部１０５は、ＤＲ信号の到来前に、異なる複数のエネルギー消費量の抑制条件を設定する。設定された抑制条件はＤＲ定式化部１０３に与えられる。つまり条件設定部１０５はＤＲ信号を受信したか否かによらず、ＤＲ信号を模倣する情報（抑制条件）をＤＲ定式化部１０３に与える。

例えば順列組み合わせで、ありとあらゆるケースを想定する抑制条件を与えることが可能である。スケジューリング部１０４は、この模倣されたＤＲ信号に含まれる抑制条件に基づいて運転スケジュールを作成する。以下では、ＤＲ信号を模倣する信号を仮想ＤＲ信号と称し、仮想ＤＲ信号に含まれる抑制条件を仮想ＤＲ条件と称することにする。

ＤＲ定式化部１０３は、ＤＲ信号を受信したケースと同様に、仮想ＤＲ信号を与えられたケースにおいても、定式化処理を実行する。同様にスケジューリング部１０４も、定式化された抑制条件に基づいて運転スケジュールを作成する。多様な抑制条件に基づいて作成された複数の運転スケジュールは、運転データベース１０８に記憶される。

例えば省コストを狙いとする運転スケジュールは、次式（１）に示される目的関数Ｃを最小化することで作成することが可能である。

式（１）によれば、電気料金に加えてガス料金をも含めた、トータルでのコスト削減を図ることができる。

削減可能量指定部１０６は、エネルギー消費機器により消費されるエネルギーの削減可能量の指定を受け付けるためのインタフェースである。例えば、照明設備を自発的に消灯することで、エネルギー消費量を削減することができる。ビル１のエネルギー管理担当者（ユーザ）は、削減可能量指定部１０６を介して、消費電力の削減可能量を入力することが可能である。ビル１を工場とすれば、製造設備などにおける消費電力の削減可能量を入力してもよい。

消費電力削減可能量をＳｉと示し、時間帯別の消費電力（固定値）をＤｉとすると次式（２）の関係がある。インデックスｉは時間帯を示す。

気象データ受信部１０７は、気象サーバ７から定期的あるいは不定期に気象データを取得する。取得された気象データは運転スケジュールの算出に利用可能である。
制御部１０９は、スケジューリング部１０４により作成された運転スケジュールに基づいて制御対象機器２を制御するための制御信号を生成する。この制御信号はＬＡＮ８およびローカルコントローラ３を介して制御対象機器２に与えられ、運転スケジュールに基づく稼動制御が実現される。

検索部１１０は、ＤＲ信号が到来すると、このＤＲ信号に含まれる抑制条件に対応する抑制条件で算出された運転スケジュールを、運転データベース１０８から読み出す。つまり検索部１１０は、受信したＤＲ信号に含まれる抑制条件をキーとして運転データベース１０８を検索し、ヒットした運転スケジュールを制御部１０９に渡す。制御部１０９は、この運転スケジュールに基づいて制御対象機器２を制御する。次に、上記構成による作用を説明する。

図４は、図３に示される機能ブロック間でのデータフローを示す図である。なお図４において２つのＤＲ定式化部１０３ａ，１０３ｂを示すが、いずれも図３に示されるＤＲ定式化部１０３と同様の機能を持つ機能オブジェクトである。例えば、ＤＲ定式化部１０３ａ，１０３ｂは、プログラムの進行中に生成される複数のスレッドとして理解することが可能である。

図４において、デマンド予測部１０１は、気象データ受信部１０７により取得された気象データ、および、制御対象機器２に係わるデータに基づいて、建物１のエネルギー需要量（例えば電力需要量、熱需要量など）を予測する。予測されたエネルギー需要量はスケジューリング部１０４に渡される。

一方、ＧＵＩを利用してユーザにより設定された仮想ＤＲ条件は、条件設定部１０５により仮想ＤＲ信号としてＤＲ定式化部１０３ｂに渡される。条件設定部１０５はＤＲ受付部１０２におけるＤＲ信号の受信の如何によらず、仮想ＤＲ条件を含む仮想ＤＲ信号をＤＲ定式化部１０３ｂに渡す。ＤＲ定式化部１０３ｂは仮想ＤＲ信号に含まれる抑制条件を定式化し、得られた数式をスケジューリング部１０４に渡す。
削減可能量指定部１０６は、ＧＵＩを利用してユーザにより入力された消費電力の削減可能量を、スケジューリング部１０４に渡す。

スケジューリング部１０４は、定式化された抑制条件およびエネルギー需要量に基づいて、建物１におけるエネルギー収支を最適化すべく、目的関数Ｃを最小化する最適化問題を解く。最適化問題を解くには例えば遺伝的アルゴリズムなどの、既知の手法を用いることが可能である。また、最適化問題を解くにあたっては、削減可能量指定部１０６に依存しない、時間帯別の消費電力Ｄｉを予め求めておくと良い。

スケジューリング部１０４により、仮想ＤＲ条件に基づく制御対象機器２の運転スケジュールが算出される。算出された運転スケジュールは運転データベース１０８に記憶される。この運転スケジュールをＧＵＩに表示してもよい。

さて、ＤＲ信号が到来すると、ＤＲ受付部１０２は、受信したＤＲ信号をＤＲ定式化部１０３ａに渡す。ＤＲ定式化部１０３ａは、ＤＲ信号に含まれる抑制条件を定式化し、得られた数式を検索部１１０に渡す。検索部１１０は、この数式に基づいて運転データベース１０８を検索し、この数式を反映する仮想ＤＲ条件のもとで算出された運転スケジュールを取得する。取得された運転スケジュールは制御部１０９に渡され、制御対象機器２を制御するために利用される。

図５は、第１の実施形態に係るエネルギー管理サーバ４の処理手順を示すフローチャートである。エネルギー管理サーバ４は、ユーザによる仮想ＤＲ条件の設定と、削減可能量の指定とを受け付ける（ステップＳ１、ステップＳ２）。これらの情報が与えられると、ＤＲ定式化部１０３ａ，１０３ｂは、それぞれＤＲ信号、仮想ＤＲ信号に含まれる抑制条件を数式に定式化してスケジューリング部１０４に与える（ステップＳ３）。

またエネルギー管理サーバ４は、受信した気象データ（ステップＳ４）をデマンド予測部１０１に与え、デマンド予測部１０１は、気象データおよび制御対象機器２のデータに基づいて電力需要量、および熱需要量を予測する（ステップＳ５）。この予測の結果はスケジューリング部１０４に入力され、スケジューリング部１０４は、制御対象機器２の運転スケジュールを作成する。

ここまでの手順で、仮想ＤＲ信号に基づく運転スケジュールが算出される。算出された運転スケジュールは運転データベース１０８に記憶される。なおステップＳ１〜ステップＳ６までの手順は、仮想ＤＲ条件を変更して何度でも繰り返すことが可能である。

次に、ＤＲ受付部１０２は、外部からのＤＲ信号の到来を待ち受ける（ステップＳ７、ステップＳ８）。ＤＲ信号の到来を確認できなければ（ステップＳ８でＮｏ）、既定時間の経過ののち再度、ＤＲ信号を確認する。ＤＲ信号の受信を確認できれば、エネルギー管理サーバ４は、受信したＤＲ信号に含まれる抑制条件に基づいて予め用意された運転スケジュールを実行する（ステップＳ９）。

このステップＳ９に至るまでには、到来したＤＲ信号に含まれる抑制条件に一致するか、あるいは近い抑制条件のもとで、運転スケジュールが既に算出されている。従ってエネルギー管理サーバ４は、ＤＲ信号を受信した直後に抑制条件に対応した運転スケジュールの実行を開始することが可能になる。

以上説明したように第１の実施形態では、ＤＲ信号が到来する前に、仮想的なＤＲ信号、つまり種々のエネルギー抑制条件を模擬する情報をエネルギー管理サーバ４に与え、複数の運転スケジュールを事前に作成するようにしている。これにより、あらゆるＤＲ信号を想定した複数のシナリオを予め設定、作成しておくことが可能になる。従って、実際の運転に用いられる運転スケジュールの良否を判断するための時間や、運転スケジュール作成に必要な設定を行う時間を確保することができる。

すなわち第１の実施形態によれば、ＤＲ信号が到来すると、既に算出済みの運転スケジュールに基づいて制御対象機器２を即座に制御することが可能になる。これにより、特に、熱エネルギー関連機器のように高速起動の難しい機器についても稼動開始までのリードタイムを短縮でき、ひいては、最大限に有利な条件のもとで稼動させることが可能になる。これらのことから第１の実施形態によれば、有利な運転スケジュールに基づく制御をデマンドレスポンス信号の受信から即座に開始することの可能なエネルギー管理サーバ、エネルギー管理方法およびプログラムを提供することが可能になる。

［第２の実施形態］
図６は、第２の実施形態に係わるエネルギー管理サーバ４の一例を示す機能ブロック図である。図６において図３と共通する部分には同じ符号を付して示し、ここでは異なる部分についてのみ説明する。

図６において、プログラムメモリ４５は、予測条件選択プログラム１１１Ｐおよび選択支援プログラム１１２Ｐを備える。これらのプログラムは、ＣＰＵ４４における予測条件選択部１１１および選択支援部１１２の機能を実現する。
予測条件選択部１１１は、複数のエネルギー需要予測のうちから所望の需要予測をユーザに選択させるためのインタフェースである。選択支援部１１２は、スケジューリング部１０４から出力された複数の運転スケジュールから、実行すべき一つの運転スケジュールをユーザに選択させるためのインタフェースである。

図７は、図６に示される機能ブロック間でのデータフローを示す図である。図７に示される複数のデマンド予測部１０１は、第１の実施形態と同じ機能を備える。
図７において、気象データ受信部１０７により受信された気象データはデマンド予測部１０１に渡される。デマンド予測部１０１は、気象データおよび制御対象機器２のデータに基づいて、異なる基準に基づく複数のエネルギー需要予測を算出する。例えばコンピュータの学習機能により需要予測を算出する技術を応用すれば、学習させるためのデータに異なるデータセットを用いることで、同じ気象データに対して異なる需要予測結果を得ることができる
異なるデータセットを用意するための基準として、空調制御に係わる快適性評価指標であるＰＭＶ（Predicted Mean Vote）を用いることが可能である。ＰＭＶはＩＳＯ７７３０に規定される量であり、温度、湿度、風速、着衣量、ふく射温度、および活動量から計算される。ＰＭＶの値が±０．５以内に収まっていれば、ほぼ９０％の人が快適と感じるとされる。ＰＭＶの値が大きいほど暑く感じられ、小さいほど寒く感じられる。

異なるデータセットとしてＰＭＶの異なる４種類のデータセットを仮定する。これらを［Ａ］、［Ｂ］、［Ｃ］、［Ｄ］で区別し、それぞれ例えば以下の範囲のＰＭＶを仮定する。
データセット［Ａ］：ＰＭＶ ０．４以下
データセット［Ｂ］：ＰＭＶ ０．４〜０．６
データセット［Ｃ］：ＰＭＶ ０．６〜１．０
データセット［Ｄ］：ＰＭＶ １．０以上
デマンド予測部１０１は、それぞれのデータセットについてエネルギー需要予測を算出する。これらの需要予測は予測条件選択部１１１に与えられる。

予測条件選択部１１１は、これらの複数の需要予測をメニュー形式などでＧＵＩに表示し、例えばクリック操作などの選択操作をユーザに促す。選択された少なくとも一つの需要予測はスケジューリング部１０４に渡され、第１の実施形態と同様にして運転スケジュールが算出される。なお、仮想ＤＲ信号を考慮した運転スケジュールと、ＤＲ信号を考慮しない運転スケジュールとの双方を算出するようにしても良い。算出された運転スケジュールは、運転データベース１０８に記憶される。

ＤＲ信号が到来すると、このＤＲ信号に含まれる抑制条件を示す数式が検索部１１０に渡される。検索部１１０は、この数式に基づいて運転データベース１０８を検索し、この数式を反映する仮想ＤＲ条件のもとで算出された運転スケジュールを、複数の予測条件ごとに取得する。取得された予測条件ごとの運転スケジュールは選択支援部１１２に渡される。

選択支援部１１２は、予測条件ごとの運転スケジュールをＧＵＩに表示する。ユーザにより選択された運転スケジュールは制御部１０９に渡される。制御部１０９は、ユーザの希望するスケジュールに沿って制御対象機器２を制御する。

図８は、第２の実施形態に係るエネルギー管理サーバ４の処理手順を示すフローチャートである。図８において図５と共通する手順には同じ符号を付し、ここでは異なる手順についてのみ説明する。ステップＳ５において需要予測が複数、算出されると、予測条件選択部１１１はＧＵＩに算出した需要予測を表示し、ユーザの選択を待つ（ステップＳ１０）。１つの需要予測が選択されると、選択された需要予測に基づいて運転スケジュールが算出される（ステップＳ６）。ステップＳ５、Ｓ１０、Ｓ６の手順はユーザの選択操作が完了するまで、つまり全ケースの完了が指示されるまで（ステップＳ１１でＹｅｓ）繰り返される。

選ばれた需要予測の数にわたる運転スケジュールが算出されたのち、ＤＲ信号が到来すると、当該ＤＲ信号に対応する運転スケジュールが選択支援部１１２に渡される。選択支援部１１２は、複数の運転スケジュールをＧＵＩに表示し、いずれかの運転スケジュールの選択をユーザに促す（ステップＳ１２）。そして、選択された運転スケジュールに基づく制御が開始される（ステップＳ９）。

図９は、第２の実施形態においてＧＵＩに表示される、スケジュール選択画面の一例を示す図である。この画面は図８のステップＳ１２でディスプレイ４２に表示される。画面右および左に、２種類の運転スケジュールが表示される。各運転スケジュールに対応付けて、符号の異なる運転ボタン２０１、２０２が表示される。

運転ボタン２０１に対応するスケジュールはＤＲ信号を考慮したもので、運転ボタン２０２に対応するスケジュールはＤＲ信号を考慮しないものである。なお、ＤＲ信号を考慮したスケジュールは複数の需要予測に対応して複数表示されるケースもあるが、図９では１つのスケジュールだけを示す。

運転スケジュールごとに、インセンティブ、コスト、トータルコスト、およびピーク電力を併せて表示する。運転スケジュールは、蓄熱および放熱のエネルギー量と、受電量との関係を示す。

図中左のスケジュールでは、蓄熱および放熱を行うことで、インセンティブが１５千円受領できるが、コストが１３３千円かかり、トータルコストが１１８千円になることが示される。右のスケジュールでは、ＤＲに伴う蓄熱、放熱が実施されず、トータルコストは１２３千円であることがわかる。

コスト削減を優先するユーザは左のスケジュールを選択し、運転ボタン２０１をクリックすることで自らの意思をシステムに伝える。これにより、ＤＲを考慮した運転スケジュールに基づく制御が開始される。

なお、スケジュールごとの受電量のピークも併せて示される。左のスケジュールのピーク電力は６２０ｋＷ、右のスケジュールのピーク電力は９００ｋＷである。受電量に制限がある場合にはこの数値を参考にすることができる。なお、ここに表示されるコスト、ピーク電力は運転スケジュールを実行した場合の想定値であり、スケジューリング部１０４で計算された計算値である。

第２の実施形態によれば、複数の運転スケジュールが算出され、ユーザに提示される。複数の運転スケジュールは、ＤＲ信号を想定しない通常運転時におけるスケジュールと、ＤＲ信号の到来を想定したスケジュールとを含むことができる。また、複数の基準に基づく複数のエネルギー需要予測に対応する複数のスケジュールも含めることができる。ユーザは提示された運転スケジュールのうち一つを選択可能であり、従って、制御対象機器２の制御にユーザの意思を反映させることが可能になる。

なお、本発明は上記実施の形態に限定されるものではない。
図１０は、図３に示される機能ブロック間でのデータフローの他の例を示す図である。図１０においては、図４でＤＲ定式化部１０３ａ，１０３ｂとして示されるＤＲ定式化部１０３を、一つのオブジェクト（スレッド）として示す。このＤＲ定式化部１０３は、現実のＤＲ信号に含まれる抑制条件の定式化と、仮想ＤＲ信号に含まれる抑制条件の定式化との２つの処理を担うことになる。そこで、現実のＤＲ信号と仮想ＤＲ信号とを、例えばフラグにより区別するようにすれば良い。

仮想ＤＲ信号を示すフラグの無いＤＲ信号は、現実のＤＲ信号として取り扱われ、その抑制条件を示す数式は検索部１１０に渡される。仮想ＤＲ信号を示すフラグの有るＤＲ信号は仮想ＤＲ信号として取り扱われ、その抑制条件を示す数式はスケジューリング部１０４に渡される。このようにしても第１の実施形態と同様の作用を実現することが可能である。

また、デマンド予測部１０１、ＤＲ受付部１０２、ＤＲ定式化部１０３、スケジューリング部１０４、条件設定部１０５、削減可能量指定部１０６、気象データ受信部１０７、運転データベース１０８、制御部１０９、検索部１１０、条件選択部１１１、および選択支援部１１２の少なくともいずれかを、クラウドコンピューティングシステムにインプリメントすることも可能である。これらの機能ブロックの機能を実現するプログラムは、単体のコンピュータに実装されてもよいし、複数のコンピュータに分散して実装されてもよい。これらの機能オブジェクトを如何にしてシステムにインプリメントするかは、当業者によれば容易に理解されるであろう。

本発明のいくつかの実施形態を説明したが、これらの実施形態は例として提示するものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…ビル、８…ＬＡＮ、５…監視装置、３…ローカルコントローラ、４…エネルギー管理サーバ、２…制御対象機器、９…ＩＰネットワーク、６…事業者サーバ、７…気象サーバ、２０…蓄電池、２１…ＰＶシステム、２２…空冷ＨＰ、２３…水冷冷凍機、２５…吸収式冷温水器、２６…蓄熱層、２７…太陽熱温水器、２８…ＣＧＳ、４１…入力部、４２…ディスプレイ、４３…インタフェース部、４６…記憶部、４４…ＣＰＵ、４５…プログラムメモリ、１０８…運転データベース、１０１Ｐ…デマンド予測プログラム、１０２Ｐ…ＤＲ受付プログラム、１０３Ｐ…ＤＲ定式化プログラム、１０４Ｐ…スケジューリングプログラム、１０５Ｐ…条件設定プログラム、１０６Ｐ…削減可能量指定プログラム、１０７Ｐ…気象データ受信プログラム、１０９Ｐ…制御プログラム、１１０Ｐ…検索プログラム、１１１Ｐ…条件選択プログラム、１１２Ｐ…選択支援プログラム、１０１…デマンド予測部、１０２…ＤＲ受付部、１０３（１０３ａ，１０３ｂ）…ＤＲ定式化部、１０４…スケジューリング部、１０５…条件設定部、１０６…削減可能量指定部、１０７…気象データ受信部、１０８…運転データベース、１０９…制御部、１１０…検索部、１１１…条件選択部、１１２…選択支援部、２０１，２０２…運転ボタン

Claims (20)

1. エネルギー消費機器と蓄エネルギー機器とを含む電気機器に係わるデータに基づいて、当該電気機器の設置される建物におけるエネルギー需要量を予測する予測部と、
   デマンドレスポンス信号を模倣する情報を複数設定可能な条件設定部と、
   前記エネルギー需要量に基づいて、前記建物におけるエネルギー収支を最適化可能な前記電気機器の運転スケジュールを、前記設定された情報ごとに、前記デマンドレスポンス信号の受信前に計算する計算部と、
   前記設定された情報ごとに計算された運転スケジュールを記憶するデータベースと、
   前記デマンドレスポンス信号を受信する受信部と、
   前記受信されたデマンドレスポンス信号に含まれる、電力消費の抑制を求める時間帯、インセンティブ、または時間帯別電力料金の少なくともいずれかに対応する前記情報に基づいて計算された運転スケジュールを前記データベースから読み出す検索部と、
   前記読み出された運転スケジュールに基づいて前記電気機器を制御する制御部とを具備するエネルギー管理サーバ。
2. 前記電気機器は、エネルギー生産機器を含み、
   前記予測部は、前記エネルギー生産機器によるエネルギー生産量を予測し、
   前記計算部は、前記エネルギー生産量に基づいて前記運転スケジュールを計算する、請求項１に記載のエネルギー管理サーバ。
3. さらに、前記エネルギー消費機器により消費されるエネルギーの削減可能量の指定を受け付ける指定部を具備し、
   前記計算部は、前記指定された削減可能量に基づいて前記運転スケジュールを計算する、請求項１に記載のエネルギー管理サーバ。
4. さらに、気象データを受信する気象データ受信部を具備し、
   前記計算部は、前記気象データに基づいて前記運転スケジュールを計算する、請求項１に記載のエネルギー管理サーバ。
5. 前記予測部は、異なる基準に基づいて複数のエネルギー需要量を予測し、
   前記計算部は、前記予測された複数のエネルギー需要量に基づいて複数の運転スケジュールを計算する、請求項１に記載のエネルギー管理サーバ。
6. さらに、前記複数の運転スケジュールのうちいずれかの指定をユーザに促すインタフェース部を具備し、
   前記制御部は、前記インタフェース部を介して指定された運転スケジュールに基づいて前記電気機器を制御する、請求項５に記載のエネルギー管理サーバ。
7. 前記インタフェース部は、前記複数の運転スケジュールと、各運転スケジュールに対応する前記時間帯または前記インセンティブの少なくともいずれかとを視覚的に表示する、請求項６に記載のエネルギー管理サーバ。
8. 前記インタフェース部は、前記複数の運転スケジュールと、各運転スケジュールに対応する受電量のピーク値とを視覚的に表示する、請求項６に記載のエネルギー管理サーバ。
9. エネルギー消費機器と蓄エネルギー機器とを含む電気機器に係わるデータに基づいて、当該電気機器の設置される建物におけるエネルギー需要量を予測し、
   デマンドレスポンス信号を模倣する情報を複数設定し、
   前記エネルギー需要量に基づいて、前記建物におけるエネルギー収支を最適化可能な前記電気機器の運転スケジュールを、前記設定された情報ごとに、前記デマンドレスポンス信号の受信前に計算し、
   前記設定された情報ごとに計算された運転スケジュールをデータベースに記憶し、
   前記デマンドレスポンス信号を受信し、
   前記受信されたデマンドレスポンス信号に含まれる、電力消費の抑制を求める時間帯、インセンティブ、または時間帯別電力料金の少なくともいずれかに対応する前記情報に基づいて計算された前記運転スケジュールを前記データベースから読み出し、
   前記読み出された運転スケジュールに基づいて前記電気機器を制御するエネルギー管理方法。
10. 前記電気機器は、エネルギー生産機器を含み、
    前記エネルギー生産機器によるエネルギー生産量を予測し、
    前記エネルギー生産量に基づいて前記運転スケジュールを計算する、請求項９に記載のエネルギー管理方法。
11. さらに、前記エネルギー消費機器により消費されるエネルギーの削減可能量の指定を受け、
    前記指定された削減可能量に基づいて前記運転スケジュールを計算する、請求項９に記載のエネルギー管理方法。
12. さらに、気象データを受信し、
    前記気象データに基づいて前記運転スケジュールを計算する、請求項９に記載のエネルギー管理方法。
13. 異なる基準に基づいて複数のエネルギー需要量を予測し、
    前記予測された複数のエネルギー需要量に基づいて複数の運転スケジュールを計算する、請求項９に記載のエネルギー管理方法。
14. さらに、前記複数の運転スケジュールのうちいずれかの指定をユーザに促し、
    前記指定された運転スケジュールに基づいて前記電気機器を制御する、請求項１３に記載のエネルギー管理方法。
15. コンピュータにより実行されるプログラムであって、
    前記プログラムは、
    エネルギー消費機器と蓄エネルギー機器とを含む電気機器に係わるデータに基づいて、当該電気機器の設置される建物におけるエネルギー需要量を予測し、
    デマンドレスポンス信号を模倣する情報を複数設定し、
    前記エネルギー需要量に基づいて、前記建物におけるエネルギー収支を最適化可能な前記電気機器の運転スケジュールを、前記設定された情報ごとに、前記デマンドレスポンス信号の受信前に計算し、
    前記設定された情報ごとに計算された運転スケジュールをデータベースに記憶し、
    前記デマンドレスポンス信号を受信し、
    前記受信されたデマンドレスポンス信号に含まれる、電力消費の抑制を求める時間帯、インセンティブ、または時間帯別電力料金の少なくともいずれかに対応する前記情報に基づいて計算された前記運転スケジュールを前記データベースから読み出し、
    前記読み出された運転スケジュールに基づいて前記電気機器を制御するプログラム。
16. 前記電気機器は、エネルギー生産機器を含み、
    前記エネルギー生産機器によるエネルギー生産量を予測し、
    前記エネルギー生産量に基づいて前記運転スケジュールを計算する、請求項１５に記載のプログラム。
17. さらに、前記エネルギー消費機器により消費されるエネルギーの削減可能量の指定を受け、
    前記指定された削減可能量に基づいて前記運転スケジュールを計算する、請求項１５に記載のプログラム。
18. さらに、気象データを受信し、
    前記気象データに基づいて前記運転スケジュールを計算する、請求項１５に記載のプログラム。
19. 異なる基準に基づいて複数のエネルギー需要量を予測し、
    前記予測された複数のエネルギー需要量に基づいて複数の運転スケジュールを計算する、請求項１５に記載のプログラム。
20. さらに、前記複数の運転スケジュールのうちいずれかの指定をユーザに促し、
    前記指定された運転スケジュールに基づいて前記電気機器を制御する、請求項１９に記載のプログラム。

Images