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

Abstract

【課題】デマンドレスポンス信号に対して精度の高い運転スケジュールを作成可能にすること。【解決手段】エネルギー管理サーバは、予測部、スケジューラ、取得部、監視部、受信部および設定部を具備する。予測部は、電気機器の設置される建物におけるエネルギーデマンドの予測値を計算する。スケジューラは、予測値に基づいて電気機器の運転スケジュールを作成する。取得部は、エネルギーデマンドの実績値を取得する。監視部は、予測値と実績値との誤差を監視する。受信部は、指定期間におけるエネルギー消費の抑制を促す情報を含むデマンドレスポンス信号を受信する。設定部は、デマンドレスポンス信号に関連する閾値を設定する。そして予測部は、誤差が既定の閾値以上になれば予測値を再計算する。スケジューラは、再計算された予測値に基づいて運転スケジュールを再作成する。【選択図】 図４

Description

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

ビルや工場はエネルギーを多量に消費する。民生業務部門のエネルギー消費量は特に多く全体の２０％にも達すると言われ、効果的な省エネルギー対策を求められる。また近年の電力需給のひっ迫を受け、大口の需要家には電力消費量力の上限が課せられるようになってきている。そこでエネルギー消費のピークカット技術やピークシフト技術をはじめとする、省エネルギー技術に注目が集まっている。

エネルギーを有効に利用するためには、多様化するエネルギー関連機器を連携させ、エネルギー消費機器、創エネルギー機器、および蓄エネルギー機器を有機的に稼動させるための運転スケジュールを作成することが重要である。例えば、蓄熱槽を有するエネルギー供給設備の所定期間における消費エネルギー、コスト、およびＣＯ２発生量を最小化する運転スケジュールを決定するための提案がある。あるいは太陽光発電（Photovoltaic：ＰＶ）システムや太陽熱温水器といった再生可能エネルギーを活用する機器と、蓄電池や蓄熱装置、既存の電気機器を連携させ、建物全体でエネルギー利用の効率化を図るための運転スケジュールを作成する提案も知られている。

特許第４３９６５５７号公報 特開２００５−１５７６８５号公報

エネルギーの供給者から需要家にエネルギー消費の抑制を求める、デマンドレスポンスと称する技術がある。ビルや工場がデマンドレスポンス信号（ＤＲ信号）を受信すると、省エネ目標値や節電目標値などの変更に伴って運転スケジュールも変更を求められる。現在、ビルや工場がデマンドレスポンス（ＤＲ）信号を受信した場合の対応については検討段階にあり、関連技術が特許出願されている（特願２０１２−０４０６５０号、特願２０１２−２４７９２８号、特願２０１２−２７０３４９号など）。

高精度な運転スケジュールをタイムリーに実行するためには、ＤＲ信号の受信直後に予測を見直したり、必要に応じて運転スケジュールを再計画することが望ましい。しかしながらこのような処理を具体的に実現可能とする技術はいまだ知られていない。

目的は、デマンドレスポンス信号に対して精度の高い運転スケジュールを作成可能なエネルギー管理サーバ、エネルギー管理方法およびプログラムを提供することにある。

実施形態によれば、エネルギー管理サーバは、予測部、スケジューラ、取得部、監視部、受信部および設定部を具備する。予測部は、電気機器の設置される建物におけるエネルギーデマンドの予測値を計算する。スケジューラは、予測値に基づいて電気機器の運転スケジュールを作成する。取得部は、エネルギーデマンドの実績値を取得する。監視部は、予測値と実績値との誤差を監視する。受信部は、指定期間におけるエネルギー消費の抑制を促す情報を含むデマンドレスポンス信号を受信する。設定部は、デマンドレスポンス信号に関連する閾値を設定する。そして予測部は、誤差が既定の閾値以上になれば予測値を再計算する。スケジューラは、再計算された予測値に基づいて運転スケジュールを再作成する。

図１は、実施形態に係わるエネルギー管理システムの一例を示すシステム図である。 図２は、ビル１内におけるエネルギーの流れの一例を示す図である。 図３は、エネルギー管理サーバ４の一例を示す機能ブロック図である。 図４は、図３に示される機能ブロック間の関係を説明するための図である。 図５は、エネルギー管理サーバ４における処理手順の一例を示すフローチャートである。 図６は、監視部１０２におけるプロセス間の関係の一例を示す図である。 図７は、監視部１０２におけるプロセス間の関係の一例を示す図である。 図８は、ＧＵＩ１１１に示される、予測誤差の判定閾値を設定するためのウインドウの一例を示す図である。 図９は、電力需要に対する再計画閾値と予測誤差との関係の一例を示す図である。 図１０は、受電量に対する再計画閾値と予測誤差との関係の一例を示す図である。 図１１は、予測部１０６におけるプロセス間の関係の一例を示す図である。 図１２は、再予測処理の効果を説明するための図である。 図１３は、ディスプレイ４２に表示される画面の一例を示す図である。

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

ローカルコントローラ３にはそれぞれ通信回線を介してノード２が接続される。ローカルコントローラ３は配下のノード２の状態をモニタしたり、各種の制御を与えたりする。ノード２は、エネルギー消費機器、創エネルギー機器および蓄エネルギー機器を含むことが可能である。例えばフロアごとの空調機器、照明機器、動力機器、熱源機器、蓄熱装置、冷凍機、ＰＶシステム、および蓄電池などがノード２に相当する。以下、これらの機器を電気機器と総称する。監視装置５は、ユーザ（ビル管理者など）とシステムとの情報伝達を仲介する、ヒューマンマシンインタフェース（ＨＭＩ）である。

エネルギー管理サーバ４はクラウドコンピューティングシステム（以下、クラウドと称する）９に接続され、クラウド９のデマンドレスポンス発行サーバ（ＤＲ発行サーバ）６からＤＲ信号を受信したり、気象サーバ７から気象データ（天気予報、時間帯ごとの気温など）を取得したりする。クラウド９は複数のサーバおよびデータベースをＩＰ（Internet Protocol）ネットワークや専用線ネットワークに接続した演算処理システムであり、データセンタなどの形態で実現される。

エネルギー管理サーバ４の主な機能は、ビル１のエネルギーを管理する機能である。実施形態ではエネルギー管理サーバ４の、電気機器の運転スケジュールを作成する機能について主に説明する。運転スケジュールは例えばユーザからの要求（ピークシフト目標など）に基づくノード２の起動／停止スケジュール（発停スケジュール）や、蓄電レベル設定に基づく蓄電蓄熱スケジュールなどである。

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

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

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

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

入力部４１は、操作パネルやスイッチなどのヒューマンマシンインタフェースである。入力部４１およびディスプレイ４２は、Graphical User Interface（ＧＵＩ）環境を形成してユーザによる情報入力を受け付け、また、ユーザに情報を提供する。インタフェース部４３はＬＡＮ８およびクラウド９に接続され、監視装置５、ローカルコントローラ３、ノード２およびリモートサーバ（ＤＲ発行サーバ６、気象サーバ７など）との通信機能を担う。

データベース部２０２は、エネルギー管理に係わる多種多様なデータに加え、実施形態に係るデータとしてデータベース２０２ａ、２０２ｂを記憶する。
プログラムメモリ４５は、この実施形態に係わる処理機能に必要な命令を含むプログラムとしての、ＤＲ受付プログラム１０１ｐ、監視プログラム１０２ｐ、ＤＲ定式化プログラム１０３ｐ、取得プログラム１０４ｐ、スケジューリングプログラム１０５ｐ、予測プログラム１０６ｐ、気象データ受信プログラム１０７ｐ、送信プログラム１０８ｐ、承認プログラム１０９ｐおよび判定プログラム１１０ｐを記憶する。これらのプログラムはＣＤ−ＲＯＭなどのリムーバブルメディア（記録媒体）に記録することも、通信回線（クラウド９を含む）を介してダウンロードすることも可能である。

ＣＰＵ４４はプログラムメモリ４５から各プログラムを読み出してハードウェアによる演算処理を行うもので、その処理機能として、ＤＲ受付部１０１、監視部１０２、ＤＲ定式化部１０３、取得部１０４、スケジューリング部１０５、予測部１０６、気象データ受信部１０７、送信部１０８、承認部１０９および判定部１１０を備える。

図４は、図３に示される機能ブロック間の関係を説明するための図である。取得部１０４は制御対象機器としてのノード２の受電量、電力需要、熱需要などの値を、例えば一定の周期（定周期）で収集する。これらの値はプロセス値と総称される現実の値（実績値）であり、取得部１０４から監視部１０２に入力される。

監視部１０２は取得部１０４から渡されたプロセス値を監視し、その値に基づいて需要予測およびスケジューリングのためのトリガを例えば定周期で作成する。作成されたトリガは予測部１０６とスケジューリング部１０５に与えられる。
予測部１０６は、ビル１における例えば３０分ごとの電力需要（電力デマンド）、および熱需要（熱デマンド）を予測する。予測の対象になるこれらの値をエネルギーデマンドと総称する。予測部１０６による予測処理は定期的なルーチンのほか、監視部１０２からトリガを与えられることによっても実施される。

予測処理に際して予測部１０６は、気象データ受信部１０７で受信された気象データ（天気予報など）を利用する。気象データ受信部１０７は、天気予報会社の気象サーバ７から定期的あるいは不定期に気象データを取得する。

スケジューリング部１０５は、電力需要および熱需要の各予測値に基づいて、ビル１におけるエネルギー収支を最適化可能なノード２の運転スケジュールを作成する。作成された運転スケジュールはデータベース２０２ａに記憶される。運転スケジュールは各ノード２の運転時の設定、運転時間、運転期間などを含むことが可能である。最適化の観点には種々あるが、例えば省エネ、省コスト、あるいは排出ＣＯ２削減などの観点を考えることが可能である。

ＤＲ受付部１０１は、ＤＲ発行サーバ６から送信されたＤＲ信号を受信する。ＤＲ信号はそのＤＲ信号の種類、電力消費の抑制を求める時間帯、インセンティブ、および電力消費量のベースラインなどの情報を含む。判定部１１０は、ＤＲ受付部１０１の出力と現在時刻とに基づいて、現時点でＤＲ信号に対応すべきか否かを判定する。例えばＤＲ信号の受信直後において、ＤＲ信号に対応すべきことが判定されると、判定部１１０はＤＲトリガを出力する。このＤＲトリガは予測部１０６およびスケジューリング部１０５に与えられ、ＤＲ信号に対応する運転スケジュールを作成する契機となる。

ＤＲ定式化部１０３は、受信されたＤＲ信号に含まれる情報を、演算処理に利用可能な数式に定式化する。例えばＰＴＲ（Peak Time Rebate）と称されるタイプのＤＲ信号は、指定された期間における受電量のベースラインからの削減量に応じたインセンティブが支払われる、というルールを伴う。このＤＲ信号に含まれる情報は、時間帯別電力料金、時間帯別インセンティブおよび時間帯別ベースライン、により定式化することが可能である。

スケジューリング部１０５は、定式化された情報に基づいて一定の期間（例えば１日２４時間分）における各ノード２（電気機器）の運転スケジュールを作成する。作成された運転スケジュールはデータベース部２０２のデータベース２０２ｂに記憶される。つまりＤＲ信号を受信して作成された運転スケジュールはデータベース２０２ｂに格納されて、ＤＲ信号を考慮せず作成された運転スケジュール（データベース２０２ａに格納）とは別個に取り扱われる。

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

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

承認部１０９は、複数の運転スケジュールをＧＵＩ１１１に表示して、いずれかの運転スケジュールに対するユーザの承認を促す。承認を受けた運転スケジュールはデータベース２０２ａ、２０２ｂのいずれかから読み出されて送信部１０８に渡される。送信部１０８は承認部１０９から渡された運転スケジュールに基づく制御信号（機器指令値）を生成する。この制御信号はインタフェース部４３（図３）からＬＡＮ８およびローカルコントローラ３を介してノード２に与えられ、運転スケジュールに基づく稼動制御が実現される。

図５は、上記構成のエネルギー管理サーバにおける処理手順の一例を示すフローチャートである。取得部１０４は、ＤＲ信号の到来をモニタし（ステップＳ１）、各ノード２の受電量、電力需要量、熱需要量などのプロセス値を収集する（ステップＳ２）。監視部１０２はプロセス値と予測値との誤差（差分）を監視し、誤差が既定の閾値以上であればトリガ（ここでは監視トリガと称する）を作成する（ステップＳ３）。監視トリガが作成されなければ（ステップＳ４でＮｏ）処理手順はステップＳ１に戻る。

ステップＳ１でＤＲ信号の到来が検出される（Ｙｅｓ）と、ＤＲ受付部１０１によりＤＲ受付処理が実行され（ステップＳ１０）、受け付けられたＤＲ信号に対応するか否かが判定部１１０により判定される（ステップＳ１１）。このＤＲ信号に対応することが判定されると、判定部１１０はこのＤＲ信号に対応する運転スケジュールの作成のトリガ（図４のＤＲトリガ）を出力する。

監視トリガまたはＤＲトリガが発生すると、予測部１０６は電力デマンドおよび熱デマンドの予測処理を実行する（ステップＳ５）。予測された各デマンドはスケジューリング部１０５に渡され、一定期間における運転スケジュールが作成される（ステップＳ６）。運転スケジュールは承認部１０９に渡され、承認を受けると（ステップＳ７）送信部１０８に渡される。送信部１０８は運転スケジュールに基づき機器指令値を生成し、制御対象に向け送信する（ステップＳ８）。以上の手順は終了を判定されるまで（ステップＳ９でＹｅｓ）繰り返される。図５に示されるフローチャートによれば、ＤＲ信号を受信した直後に、このＤＲ信号に対応する運転スケジュールを実行することが可能になる。

図６および図７は、監視部１０２におけるプロセス間の関係の一例を示す図である。図６はＤＲ信号の無いケースに対応する。図６において閾値抽出プロセス１０２１は、プロセス値と予測値との誤差と比較するための閾値（通常時）の現在時刻における値をデータベース部２０２から取得する。つまり閾値は時刻によって変わる量であり、例えばユーザにより設定される。その詳細については図８を用いて説明する。

誤差計算プロセス１０２２は、電力需要の実績値と予測値との誤差（需要誤差）を計算する。誤差計算プロセス１０２３は、受電量の実績値と予測値との誤差（受電量誤差）を計算する。需要誤差および受電量誤差は選択プロセス１０２４に渡され、いずれかの誤差が判定対象として選択されて比較プロセス１０２５に渡される。比較プロセス１０２５は選択された誤差と現在閾値とを比較し、その大小関係を示す判定結果をデータベース部２０２に記憶する。

図７はＤＲ信号の有るケースに対応する。図７において閾値抽出プロセス１０２１は、閾値（通常時）の現在時刻における値に加え、閾値（ＤＲ時）の現在時刻における値と、ＤＲ信号の受信中であることを示すＤＲ受信中フラグをデータベース部２０２から取得する。閾値抽出プロセス１０２１は、ＤＲ受信中においては閾値（ＤＲ時）を出力する。

図８は、ＧＵＩ１１１に示される、予測誤差の判定閾値を設定するためのウインドウの一例を示す図である。すなわちＧＵＩ１１１は、閾値を設定するための設定部として機能する。図８において、例えばウインドウの上段に通常時の閾値の入力欄が表示され、中段にＤＲ信号有りの場合の閾値の入力欄が表示される。各閾値は例えば３０分毎に設定可能になっている。閾値の設定値は経験に基づいて決定することができる。ウインドウの下段には判定対象として受電量または需要（電力、熱）のいずれかを指定するためのラジオボタンが表示される。各時刻における値を入力し設定ボタンがクリックされると、閾値が設定されてデータベース部２０２に記憶される。

図９は、電力需要に対する再計画閾値と予測誤差との関係の一例を示す図である。図９に示される一点鎖線は図８のウインドウを用いて設定された再計画閾値Ｔの、時間に対する変化を示す。再計画閾値Ｔは、１１：００から３０分間において他の時間帯よりも大幅に低い値に設定されている。この時間帯において、予測値と実績値との差分である誤差を示すカーブが閾値Ｔを上回るので、監視部１０２は予測トリガを発生させる。この予測トリガは予測部１０６とスケジューリング部１０５に入力され、これにより電力需要、または受電量の再予測処理と、これに伴う再計画処理が実行される。尚、図９においては、予測トリガの発生を説明するためのものであり、前日までに予測された１日分の予測値と当日の実績値を描画しているが、本来１１：００以降の予測値は再予測処理が行われることにより、１１:００時点で予測値と実績値の誤差がゼロになる新たな予測値となる。

図１０は、受電量に対する再計画閾値と予測誤差との関係の一例を示す図である。図１０においてはＤＲ信号のある状態が想定され、１２：００から１５：００までをＤＲ対象時間帯とする。再計画閾値Ｔは１１：００〜１１：３０で最低値に、１１：３０〜１６：００でその次に低い値に設定され、他の時間帯はこれよりも高い値に設定される。

誤差のカーブは６：００頃から上昇し、その一方で閾値Ｔが１１：００に最低になるので両者の大小が逆転し、再予測処理および再計画処理が起動する。これにより誤差は０になる。その後ＤＲ時間帯が到来し、デマンドレスポンスに応じた電力削減運転が開始されて受電量が減る。ＤＲ期間においても誤差は変化し１５：００において誤差が閾値を超えると、この時点においても再予測処理、再計画処理が起動される。

ＤＲ期間が到来すると、例えばＣＧＳ２８（図２）を起動することで受電量を削減することができる。吸収式冷温水機２５により冷熱を製造して空冷ＨＰ２２の必要電力量を削減することでも、受電量を減らすことができる。しかし図１０において１４：００頃から誤差が大きくなり始め、１５：００に再計画閾値Ｔを越えた。よってＤＲ期間中においても再予測処理、再計画処理が起動され、誤差は再び０になる。このようにＤＲ期間に他の時間帯よりも再計画閾値Ｔを低く設定しておくことで、ＤＲ時間帯おいても再予測、再計画を実施することができ、ＤＲ期間中は、より厳しい条件で再計画を行うことが可能になる。

図１１は、予測部１０６におけるプロセス間の関係の一例を示す図である。誤差計算プロセス１０６１は、電力需要（受電量も同様）の実績値および予測値をデータベース部２０２から取得し、現在時刻における誤差を計算する。この誤差は展開プロセス１０６２により、時刻毎の値に展開される。展開された誤差列として、例えば現在時刻の誤差を同じ値で並べた配列を考えることができるが、これに限られるものではない。

加算プロセス１０６３は誤差列を展開プロセス１０６２から取得し、予測値をデータベース部２０２から取得する。加算プロセス１０６３は予測値に誤差列を加算した値を、予測修正結果としてデータベース部２０２に記憶させる。

図１２は、再予測処理の効果を説明するための図である。図１２に示されるグラフは１日における電力需要の予測と実績とを示す。予測Ｐｐ０に対して実績Ｐａは誤差を持ち、誤差が再計画閾値を上回ると再計画が実行される。現在時刻１１：００の誤差をΔＰ１１とすると、式（２）により新たな予測値Ｐｐ１を求めることができる。

再計画処理により１１：００時点における予測誤差は０となる。

図１３は、ディスプレイ４２に表示される画面の一例を示す図である。この画面は図５のステップＳ７で、運転スケジュールの承認をユーザに促すためにディスプレイ４２に表示される。例えばウインドウの右および左にそれぞれ異なる運転スケジュールが表示される。左の運転スケジュールには運転ボタン３０１が、右の運転スケジュールには運転ボタン３０２が表示される。

左側はデータベース２０２ｂに格納される運転スケジュールを示し、右側はデータベース２０２ａに格納される運転スケジュールを示す。すなわち左側に表示されるスケジュールが、ＤＲ受信時においてスケジューリング部１０５により作成された運転スケジュールである。

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

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

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

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

以上述べたように実施形態によれば、実績値と予測値との誤差を算出し、この誤差が予め設定された閾値以上になるとトリガを発生させてデマンドの再予測と運転スケジュールの再計画とを実行する。誤差は図８のようなインタフェースを用いてユーザが任意に設定することができる。所望の時間帯の誤差を小さい値に設定しておくことで予測プロセスおよび計画プロセスの感度を高めることができ、高精度な運転スケジュールを前もって準備することができる。また、デマンドレスポンス信号の有無によってもトリガを発生させ、ＤＲ期間の中でも閾値を可変設定しているので、デマンドレスポンス信号に含まれる情報や要求に対して高度に追従し、有利な運転スケジュールを作成することが可能になる。

つまり実施形態によれば、デマンドレスポンス（ＤＲ）信号を受信したことに応じて運転スケジュールを速やかに見直すことが可能になる。運転スケジュールを即座に再計算することでＤＲ信号受信直後の誤差（電力需要や受電量）に応じた予測の見直し、再計画を行うことが可能になるので、精度の高い運転スケジュールを素早く実行できる。

これらのことから、デマンドレスポンス信号に対して精度の高い運転スケジュールを作成可能なエネルギー管理サーバ、エネルギー管理方法およびプログラムを提供することが可能になる。

なお、本発明は上記実施の形態に限定されるものではない。例えばＤＲ受付部１０１、監視部１０２、ＤＲ定式化部１０３、取得部１０４、スケジューリング部１０５、予測部１０６、気象データ受信部１０７、送信部１０８、承認部１０９および判定部１１０の少なくともいずれかを、クラウド９側の機能としてインプリメントすることも可能である。これらの機能ブロックの機能を実現するプログラムは、単体のコンピュータに実装されてもよいし、複数のコンピュータに分散して実装されてもよい。これらの機能オブジェクトを如何にしてシステムにインプリメントするかは、当業者によれば容易に理解されるであろう。

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

１…ビル、８…ＬＡＮ、５…監視装置、３…ローカルコントローラ、４…エネルギー管理サーバ、２…ノード、９…クラウドコンピューティングシステム、６…ＤＲ発行サーバ、７…気象サーバ、２０…蓄電池、２１…ＰＶシステム、２２…空冷ヒートポンプ（ＨＰ）、２３…水冷冷凍機、２５…吸収式冷温水器、２６…蓄熱層、２７…太陽熱温水器、２８…ＣＧＳ、４１…入力部、４２…ディスプレイ、４３…インタフェース部、２０２…データベース部、４４…Central Processing Unit（ＣＰＵ）、４５…プログラムメモリ、２０２ａ，２０２ｂ…データベース、４５…プログラムメモリ、１０１ｐ…ＤＲ受付プログラム、１０２ｐ…監視プログラム、１０３ｐ…ＤＲ定式化プログラム、１０４ｐ…取得プログラム、１０５ｐ…スケジューリングプログラム、１０６ｐ…予測プログラム、１０７ｐ…気象データ受信プログラム、１０８ｐ…送信プログラム、１０９ｐ…承認プログラム、１１０ｐ…判定プログラム、１０１…ＤＲ受付部、１０２…監視部、１０３…ＤＲ定式化部、１０４…取得部、１０５…スケジューリング部、１０６…予測部、１０７…気象データ受信部、１０８…送信部、１０９…承認部、１１０…判定部、１１１…ＧＵＩ

Claims (11)

1. 電気機器の設置される建物におけるエネルギーデマンドの予測値を計算する予測部と、
   前記予測値に基づいて前記電気機器の運転スケジュールを作成するスケジューラと、
   前記エネルギーデマンドの実績値を取得する取得部と、
   前記予測値と前記実績値との誤差を監視する監視部と、
   指定期間におけるエネルギー消費の抑制を促す情報を含むデマンドレスポンス信号を受信する受信部と、
   前記デマンドレスポンス信号に関連する閾値を設定するための設定部とを具備し、
   前記予測部は、前記誤差が前記閾値以上になれば前記予測値を再計算し、
   前記スケジューラは、前記再計算された予測値に基づいて前記運転スケジュールを再作成する、エネルギー管理サーバ。
2. 前記閾値は、時間に対して可変設定される、請求項１に記載のエネルギー管理サーバ。
3. 前記閾値は、前記指定期間において他の期間よりも低く設定される、請求項１に記載のエネルギー管理サーバ。
4. さらに、電力デマンドおよび受電量のいずれかを前記エネルギーデマンドとして選択する選択部を具備する、請求項１に記載のエネルギー管理サーバ。
5. さらに、前記デマンドレスポンス信号への対応の可否を判定する判定部を具備する、請求項１に記載のエネルギー管理サーバ。
6. 電気機器の設置される建物のエネルギーを管理するサーバに適用可能なエネルギー管理方法であって、
   前記サーバが、
   前記建物におけるエネルギーデマンドの予測値を計算し、
   前記予測値に基づいて前記電気機器の運転スケジュールを作成し、
   前記エネルギーデマンドの実績値を取得し、
   前記予測値と前記実績値との誤差を監視し、
   前記予測することは、前記誤差が、指定期間におけるエネルギー消費の抑制を促す情報を含むデマンドレスポンス信号に関連して設定される閾値以上になれば前記予測値を再計算し、
   前記作成することは、前記再計算された予測値に基づいて前記運転スケジュールを再作成する、エネルギー管理方法。
7. 前記閾値は、時間に対して可変設定される、請求項６に記載のエネルギー管理方法。
8. 前記閾値は、前記指定期間において他の期間よりも低く設定される、請求項６に記載のエネルギー管理方法。
9. 前記サーバは、さらに、電力デマンドおよび受電量のいずれかを前記エネルギーデマンドとして選択する、請求項６に記載のエネルギー管理方法。
10. 前記サーバは、さらに、前記デマンドレスポンス信号への対応の可否を判定する、請求項６に記載のエネルギー管理方法。
11. 請求項６乃至１０のいずれか１項に記載の方法をコンピュータに実行させるための命令を含む、プログラム。

Images