(57)【特許請求の範囲】
【請求項１】
クラウド上に複数の電力会社毎に割り当てられる第１のＶＭ(Virtual Machine)と、複数のアグリゲータ毎に割り当てられる第２のＶＭとから構成された電力需給調整システムであって、
前記第１のＶＭは、電力会社向けＤＲ（デマンドレスポンス）機能群を有し、
前記第２のＶＭは、アグリゲータ向けＤＲ機能群と複数の需要家向けＤＲ機能群を有し、
前記電力会社向けＤＲ機能群はイベント送信機能により、需要家へ需給調整を促すためのイベントを前記アグリゲータ向けＤＲ機能群へ送信し、
前記アグリゲータ向けＤＲ機能群はイベント受信機能により前記イベントを受信して一旦ＤＢ（データベース）へ格納し、前記ＤＢに格納されたイベントをイベント送信機能により前記複数の需要家向けＤＲ機能群へ送信し、
前記複数の需要家向けＤＲ機能群はイベント受信機能により前記アグリゲータ向けＤＲ機能群から送信されたイベントを受信し、受諾可否送信機能により受諾可否情報を前記アグリゲータ向けＤＲ機能群へ送信し、
前記アグリゲータ向けＤＲ機能群は受諾可否受信機能により前記受諾可否情報を受信し、受諾可否送信機能により前記受諾可否情報を前記電力会社向けＤＲ機能群へ送信し、
前記電力会社向けＤＲ機能群は受諾可否受信機能により前記受諾可否情報を受信することを特徴とする電力需給調整システム。
【請求項２】
前記第２のＶＭがサブアグリゲータ向けＤＲ機能群を更に有し、当該サブアグリゲータ向けＤＲ機能群は、前記アグリゲータ向けＤＲ機能群と前記需要家向けＤＲ機能群との間の情報を仲介することを特徴とする請求項１に記載の電力需給調整システム。
【請求項３】
クラウド上に複数の電力会社毎に割り当てられる第１のＶＭ(Virtual Machine)と、複数のアグリゲータ毎に割り当てられる第２のＶＭとから構成され、前記第１のＶＭは電力会社向けＤＲ（デマンドレスポンス）機能群を有し、前記第２のＶＭはアグリゲータ向けＤＲ機能群と複数の需要家向けＤＲ機能群を有する電力需給調整システムで用いられる電力需給調整方法であって、
前記電力会社向けＤＲ機能群が、イベント送信機能により、需要家へ需給調整を促すためのイベントを前記アグリゲータ向けＤＲ機能群へ送信し、
前記アグリゲータ向けＤＲ機能群が、イベント受信機能により前記イベントを受信して一旦ＤＢ（データベース）へ格納し、前記ＤＢに格納されたイベントをイベント送信機能により前記複数の需要家向けＤＲ機能群へ送信し、
前記複数の需要家向けＤＲ機能群が、イベント受信機能により前記アグリゲータ向けＤＲ機能群から送信されたイベントを受信し、受諾可否送信機能により受諾可否情報を前記アグリゲータ向けＤＲ機能群へ送信し、
前記アグリゲータ向けＤＲ機能群が、受諾可否受信機能により前記受諾可否情報を受信し、受諾可否送信機能により前記受諾可否情報を前記電力会社向けＤＲ機能群へ送信し、
前記電力会社向けＤＲ機能群が、受諾可否受信機能により前記受諾可否情報を受信することを特徴とする電力需給調整方法。
【請求項４】
前記第２のＶＭがサブアグリゲータ向けＤＲ機能群を更に有する場合に、当該サブアグリゲータ向けＤＲ機能群は、前記アグリゲータ向けＤＲ機能群と前記需要家向けＤＲ機能群との間の情報を仲介することを特徴とする請求項３に記載の電力需給調整方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＤＲサービスプラットフォーム及びＤＲサービス提供方法に関する。
【背景技術】
【０００２】
温室効果ガス（CO2）削減や電力の安定供給を目的として、エネルギー使用の効率化および電力需要の抑制を図ることにより無理のない節電を進め、電力消費量の削減を図ることが社会的要請として求められている。また、経済産業省のエネルギー管理システム導入促進事業として、デマンドレスポンス（DR）の実現が求められており、電力の需給調整を行うデマンドレスポンス（DR）事業が商用ベースで開始されている。
【０００３】
このような背景のもと、エネルギー管理システム導入促進事業で定められるDRの要件を満たすシステム（プラットフォーム）を開発し、電力会社及びアグリゲータが簡易に、且つ、精度よく電力消費状況管理・制御ができるようにすることが求められている。
【０００４】
DRでは、特許文献１、２に記載の通り、時間帯ごとの異なる電気料金体系設定、電力需要が高まる時に電力消費の削減要請に応じた需要家へのインセンティブ支払いなどによる需給調整が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開2012-226538号公報
【特許文献２】特開2006-174654号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら現状では、電力会社／アグリゲータ／需要家間の情報流通や需給調整のネゴシエーションは人手による電子メールや電話連絡を使っているため、電力会社／アグリゲータ等のオペレータの稼働が増大するという問題がある。
本発明は上記の問題に鑑みてなされたものであり、本発明が解決しようとする課題は、ＤＲにおける情報流通を簡易化し、オペレータの稼働を削減することができるＤＲサービスプラットフォーム及びＤＲサービス提供方法を提供することにある。
【課題を解決するための手段】
【０００７】
上記目的を達成するために本発明に係る電力需給調整システムは、クラウド上に複数の電力会社毎に割り当てられる第１のＶＭ(Virtual Machine)と、複数のアグリゲータ毎に割り当てられる第２のＶＭとから構成された電力需給調整システムであって、前記第１のＶＭは、電力会社向けＤＲ（デマンドレスポンス）機能群を有し、前記第２のＶＭは、アグリゲータ向けＤＲ機能群と複数の需要家向けＤＲ機能群を有し、前記電力会社向けＤＲ機能群はイベント送信機能により、需要家へ需給調整を促すためのイベントを前記アグリゲータ向けＤＲ機能群へ送信し、前記アグリゲータ向けＤＲ機能群はイベント受信機能により前記イベントを受信して一旦ＤＢ（データベース）へ格納し、前記ＤＢに格納されたイベントをイベント送信機能により前記複数の需要家向けＤＲ機能群へ送信し、前記複数の需要家向けＤＲ機能群はイベント受信機能により前記アグリゲータ向けＤＲ機能群から送信されたイベントを受信し、受諾可否送信機能により受諾可否情報を前記アグリゲータ向けＤＲ機能群へ送信し、前記アグリゲータ向けＤＲ機能群は受諾可否受信機能により前記受諾可否情報を受信し、受諾可否送信機能により前記受諾可否情報を前記電力会社向けＤＲ機能群へ送信し、前記電力会社向けＤＲ機能群は受諾可否受信機能により前記受諾可否情報を受信するようにしたものである。
【０００８】
このように構成すると、ＤＲにおける情報流通を簡易化し、オペレータの稼働を削減することができる。また、アクタ間の通信回線を自前で用意する必要はなく、それぞれのアクタは１箇所のＤＲサービスプラットフォームのＧＵＩにアクセスするだけで、他のアクタとの通信を行いＤＲを実現することが可能である。
【００１０】
このように構成すると、電力会社と需要家の間にアグリゲータを介在することにより、アグリゲータの考えにより、需要家から収集した各種生活データに基づいて、個々の需要家に最適なイベント（ＤＲの内容）を自由に、きめ細かく提案することができる。また、電力会社は個々の需要家にどんなＤＲを送るかを考える必要はなく、アグリゲータの方だけを見て電力抑制依頼をかけることができるので、需給計画立案の負担を軽減することが可能となる。
【００１１】
さらに、上記目的を達成するために本発明に係る電力需給調整システムは、前記第２のＶＭがサブアグリゲータ向けＤＲ機能群を更に有し、当該サブアグリゲータ向けＤＲ機能群は、前記アグリゲータ向けＤＲ機能群と前記需要家向けＤＲ機能群との間の情報を仲介する。
【００１２】
このように構成すると、電力会社と需要家とアグリゲータとの間にサブアクリゲータを介在することにより、アクリゲータの負担を軽減できる。
また、本発明に係るＤＲサービスプラットフォームの一観点は以下のような態様を備える。
第１の態様は、各機能の送受信は、クラウド上において各機能相互間通信により行われる。
【００１３】
このように構成すると、別途に専用の通信回線を設けることなく、クラウド上でＤＲを行うことができる。
第２の態様は、イベントは、需要家に対する需要抑制依頼である。
このように構成すると、ＤＲサービスプラットフォーム上を流れるイベントの内容を工夫するだけで、様々なＤＲ（ＣＰＰ：緊急ピーク時課金、ＴＯＵ：時間帯別料金、ＰＴＲ：ピーク時リベート）に適用可能である。
【００１４】
第３の態様は、需要家から電力会社へ送信されるレポートは、イベントの適用期間における電力消費量である。
このように構成すると、電力会社は需要家の電力消費量を把握できる。
【発明の効果】
【００１５】
本発明に係るＤＲサービスプラットフォーム、ＤＲサービス提供方法によれば、ＤＲにおける情報流通を簡易化し、オペレータの稼働を削減することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態における電力需給調整システムの概略構成図。
【図２】本実施形態において、電力会社と、アグリゲータと、サブアグリゲータと、需要家との接続構成を示す図。
【図３】本実施形態において、アクタの論理構成を示す図。
【図４】本実施形態において、電力会社向けＤＲ機能群のＤＢに登録される送信イベントの一例を示す図。
【図５】本実施形態において、アグリゲータ向けＤＲ機能群のＤＢに登録される送信イベント及び受信イベントの一例を示す図。
【図６】本実施形態において、同じくアグリゲータ向けＤＲ機能群のＤＢに登録される送信イベント及び受信イベントの一例を示す図。
【図７】本実施形態において、サブアグリゲータ向けＤＲ機能群のＤＢに登録される送信イベント及び受信イベントの一例を示す図。
【図８】本実施形態において、同じくサブアグリゲータ向けＤＲ機能群のＤＢに登録される送信イベント及び受信イベントの一例を示す図。
【図９】本実施形態において、需要家向けＤＲ機能群のＤＢに登録される受信イベントの一例を示す図。
【図１０】本実施形態において、同じく需要家向けＤＲ機能群のＤＢに登録される受信イベントの一例を示す図。
【図１１】本実施形態において、同じく需要家向けＤＲ機能群のＤＢに登録される受信イベントの一例を示す図。
【図１２】本実施形態において、同じく需要家向けＤＲ機能群のＤＢに登録される受信イベントの一例を示す図。
【図１３】本実施形態において、同じく需要家向けＤＲ機能群のＤＢに登録される受信イベントの一例を示す図。
【図１４】本実施形態において、同じく需要家向けＤＲ機能群のＤＢに登録される受信イベントの一例を示す図。
【図１５】本実施形態において、同じく需要家向けＤＲ機能群のＤＢに登録される受信イベントの一例を示す図。
【図１６】本実施形態において、同じく需要家向けＤＲ機能群のＤＢに登録される受信イベントの一例を示す図。
【図１７】本実施形態において、同じく需要家向けＤＲ機能群のＤＢに登録される受信イベントの一例を示す図。
【図１８】本実施形態において、同じく需要家向けＤＲ機能群のＤＢに登録される受信イベントの一例を示す図。
【図１９】本実施形態において、同じく需要家向けＤＲ機能群のＤＢに登録される受信イベントの一例を示す図。
【図２０】本実施形態において、イベント送信機能の動作を説明するために示すシーケンス図。
【図２１】本実施形態において、イベント受信機能の動作を説明するために示すシーケンス図。
【図２２】本実施形態において、受諾可否送信機能の動作を説明するために示すシーケンス図。
【図２３】本実施形態において、受諾可否受信機能の動作を説明するために示すシーケンス図。
【図２４】本実施形態において、レポート送信機能の動作を説明するために示すシーケンス図。
【図２５】本実施形態において、レポート受信機能の動作を説明するために示すシーケンス図。
【発明を実施するための形態】
【００１７】
本発明に係るＤＲサービスプラットフォームは、クラウド上に構築され、電力会社に対しては、イベント送信機能、受諾可否受信機能、レポート送信機能、レポート受信機能を提供し、アグリゲータとサブアグリゲータに対しては、イベント送信機能、イベント受信機能、受諾可否送信機能、受諾可否受信機能、レポート送信機能、レポート受信機能を提供し、需要家に対しては、イベント受信機能、受諾可否送信機能、レポート送信機能、レポート受信機能を提供する。
【００１８】
以下に、本発明の実施の形態について説明する。
図１は、本発明の一実施形態を説明する図である。図１において、クラウド１上に構築される各機能群３がインターネット２を介して各アクタ４へ提供される。
クラウド１上に構築される各機能群３は、それぞれ各アクタ４に対応しており、各アクタ４では、オペレータがインターネット２を介して各機能群３のGraphical User Interface（ＧＵＩ）５（図１では例えば５１〜５４のみ図示）にアクセスすることにより各機能群３の運用を行う。
【００１９】
アクタ４とは、ＤＲサービスの提供客体であり、各アクタ４（電力会社４１、アグリゲータ４２、サブアグリゲータ４３、需要家４４）はクラウド１上のＤＲサービスプラットフォームからサービスの提供を受けて電力需給調整システムを構成する。需給調整は、あるアクタ４から他のアクタ４へイベントを送信し、イベント受信側が応答することに行われるが、イベント送信において対向する２つのアクタ４のうち、イベント送信側のアクタ４を上位アクタ、イベント受信側のアクタ４を下位アクタという。
【００２０】
イベントは電力需給調整を目的とするものであるから、電力会社４１は常に上位アクタである。その配下のアグリゲータ４２は、さらに配下のサブアグリゲータ４３や需要家４４にイベント送信する場合は上位アクタとなるが、電力会社４１との関係ではイベントを受信するため下位アクタとなる。
【００２１】
また、クラウド１上にはＰＦ(Plat Form)事業者６が接続される。ＰＦ事業者６は、各アクタ４からの要求に応じて、ＤＲサービスプラットフォームに各機能群３を構築し、各アクタ４に各機能群３を提供し、各機能群３の使用に関する料金等の管理をする。
【００２２】
ＤＲサービスプラットフォームは、複数のＶＭ(Virtual Machine)を有し、ＶＭを電力会社４１毎に割り当て、アグリゲータ４２毎に割り当てる。電力会社４１毎に割り当てられるＶＭには、電力会社向けＤＲ機能群３１が構築される。アグリゲータ４２毎に割り当てられるＶＭには、アグリゲータ向けＤＲ機能群３２、サブアグリゲータＤＲ機能群３３及び需要家向けＤＲ機能群３４が構築される。
【００２３】
さらに、クラウド１上のＤＲサービスプラットフォームには、ＮＴＰサーバＳＶ１及びＳＭＴＰサーバＳＶ２が接続される。ＮＴＰサーバＳＶ１は、ＶＭ間の時刻を標準時刻に合わせるためのサーバである。ＳＭＴＰサーバＳＶ２は、ＶＭ間で電子メールの送信を行わせるためのサーバである。
【００２４】
図２は、電力会社４１と、アグリゲータ４２と、サブアグリゲータ４３と、需要家４４との接続構成を示す図である。
図２の通り、電力会社４１は１以上のアグリゲータ４２を配下に持つことができ、また１以上の需要家４４を直接配下に持つこともできる。アグリゲータ４２は１以上のサブアグリゲータ４３を持つことができ、また１以上の需要家４４を直接配下に持つこともできる。サブアグリゲータ４３は、１以上の需要家４４を配下に持つことができる。
【００２５】
電力会社４１は、ＤＲサービスプラットフォームを利用してアグリゲータ４２（サブアグリゲータ４３、需要家４４）へイベントを送信し、それに対する応答である受諾可否とレポートをイベント送信先のアクタ４から収集する。アグリゲータ４２は、電力会社４１と需要家４４との仲介を行う機関であり、電力会社４１からのイベント送信を受けて、さらに需要家４４へイベント送信を行い、需要家４４からの受諾可否とレポートを収集して電力会社４１へ提供する。サブアグリゲータ４３は、アグリゲータ４２と同様の機関であり、アグリゲータ４２の下位アクタである。なお、需要家４４は電力網７を介して、電力会社４１から電力供給を受けている。各需要家４４には、ＢＥＭＳ／ＭＥＭＳ（図２中ではＢで示す）を介して各施設等における電力消費量を計測するスマートメータが接続される。なお、ＢＥＭＳ／ＭＥＭＳは、需要家４４の内部に設けられてもよく、外部に設けられてもよい。そして、各需要家４４は、電力会社４１からの要求またはあるイベントの適用期間に、スマートメータにより計測された電力消費量をレポートとして電力会社４１に直接またはアグリゲータ４２またはサブアグリゲータ４３を介して通知する。
【００２６】
さらに、電力会社４１はＩＦ４を介してＶＭにより構築される電力会社外部システムに接続される。アグリゲータ４２はＩＦ４を介してＶＭにより構築されるアグリゲータ外部システムに接続される。
電力会社向けＤＲ機能群３１は、電力会社４１に対して、イベント送信機能、受諾可否受信機能、レポート受信機能を提供する。
【００２７】
アグリゲータ向けＤＲ機能群３２は、アグリゲータ４２に対して、イベント送信機能、イベント受信機能、受諾可否送信機能、受諾可否受信機能、レポート送信機能、レポート受信機能を提供する。
サブアグリゲータ向けＤＲ機能群３３は、サブアグリゲータ４３に対して、イベント送信機能、イベント受信機能、受諾可否送信機能、受諾可否受信機能、レポート送信機能、レポート受信機能を提供する。
【００２８】
需要家向けＤＲ機能群３４は、需要家４４に対して、イベント受信機能、受諾可否送信機能、レポート送信機能を提供する。
各機能群３はそれぞれ、ＧＵＩ５（図１では例えば５１〜５４のみ図示）とデータベース（ＤＢ）８（図１では例えば８１〜８４のみ図示）とを備えており、ＤＢ８はＤＲやレポートの送受信等の情報を格納し、ＧＵＩ５はＤＲやレポートの送受信の指示を行うための各アクタ４とのインターフェースである。
【００２９】
各機能群３間のＤＲ、受諾可否、レポートの送受信は、全てクラウド１上で行われる。例えば、電力会社４１からアグリゲータ４２へのイベント送信は、電力会社４１とアグリゲータ４２との間の直接通信により行われるのではなく、クラウド１上に実装される電力会社向けＤＲ機能群３１とアグリゲータ向けＤＲ機能群３２との間で、クラウド１上に構築される通信回線により行われる。また、需要家４４からアグリゲータ４２への受諾可否送信機能は、需要家４４とアグリゲータ４２との間の直接通信により行われるのではなく、クラウド１上に実装される需要家向けＤＲ機能群３４とアグリゲータ向けＤＲ機能群３２との間で、クラウド１上に構築される通信回線により行われる。この他の機能についても同様である。
【００３０】
以下、各機能群３の内容について説明する。各機能群３は、表１に示すように、電力会社４１、アグリゲータ４２、サブアグリゲータ４３、需要家４４にそれぞれ割り当てられる。
【表１】
0005841976.tif 000002
【００３１】
１．イベント送信機能（電力会社向けＤＲ機能群３１、アグリゲータ向けＤＲ機能群３２、サブアグリゲータ向けＤＲ機能群３３）
スケジュール管理部より定期的に起動され、配信時刻が現在時刻より前のイベントを下位アクタに送信する。下位アクタにイベント通知後、下位アクタの管理者に対してメールを送信する。
【００３２】
２．イベント受信機能（アグリゲータ向けＤＲ機能群３２、サブアグリゲータ向けＤＲ機能群３３、需要家向けＤＲ機能群３４）
上位アクタより送信されたイベントを受信し、ＤＢ８に格納する。
３．受諾可否送信機能（アグリゲータ向けＤＲ機能群３２、サブアグリゲータ向けＤＲ機能群３３、需要家向けＤＲ機能群３４）
スケジュール管理部より定期的に起動され、上位アクタから受信したイベントに対して受諾/拒否結果を送信する。
【００３３】
４．受諾可否受信機能（電力会社向けＤＲ機能群３１、アグリゲータ向けＤＲ機能群３２、サブアグリゲータ向けＤＲ機能群３３）
下位アクタから送信された受諾/拒否結果を受信し、ＤＢ８に格納する。
５．レポート送信機能（アグリゲータ向けＤＲ機能群３２、サブアグリゲータ向けＤＲ機能群３３、需要家向けＤＲ機能群３４）
スケジュール管理部より定期的に起動され、未送信レポートをＤＢ８より取得し、上位アクタに送信する。
【００３４】
６．レポート受信機能（電力会社向けＤＲ機能群３１、アグリゲータ向けＤＲ機能群３２、サブアグリゲータ向けＤＲ機能群３３）
下位アクタより送信されたレポートを受信し、受信レポート情報を更新する。
上記各機能は、各アクタ４のオペレータがＧＵＩ５を通して各機能群３のＤＢ８へ投入したデータ（ＣＳＶファイル）に基づいて動作する。
【００３５】
例えば、電力会社４１からイベント送信を行う場合には、オペレータは電力会社向けＤＲ機能群３１のＧＵＩ５１へアクセスし、イベント送信に必要なデータをＤＢ８１へ投入する。
以下、電力会社４１がアグリゲータ４２、サブアグリゲータ４３を介して、又は直接に需要家４４へイベント送受信、受諾可否送受信、レポート送受信を行う運用例を説明する。
【００３６】
この例におけるアクタ４の論理構成は図３の通りである。ここで、電力会社向けＤＲ機能群３１のＤＢ８１には、図４に示す送信イベントが登録される。この送信イベントは、イベント送信元アクタＩＤと、イベント送信元を識別するＤＲイベントＩＤと、「Emergency」といった緊急の電力削減依頼等を示すイベント種別と、有効期間開始日時と、有効期間終了日時と、通知先を識別するため通知先アクタＩＤと、通知先の種類を示す通知先アクタ種別と、イベント配布日時とにより構成される。電力会社４１は、アグリゲータ（ＡＧＲ−１００１），（ＡＧＲ−１００２）４２、需要家（ＵＳＲ−１０１０），（ＵＳＲ−１０１１）４４に対しイベントを送信する。
【００３７】
アグリゲータ（ＡＧＲ−１００１）４２に対応するアグリゲータ向けＤＲ機能群３２のＤＢ８２には、図５（ａ）に示す受信イベントと、図５（ｂ）に示す送信イベントとが登録される。アグリゲータ（ＡＧＲ−１００２）４２に対応するアグリゲータ向けＤＲ機能群３２のＤＢ８２には、図６（ａ）に示す受信イベントと、図６（ｂ）に示す送信イベントとが登録される。
【００３８】
サブアグリゲータ（ＳＡＧ−１００１）４３に対応するサブアグリゲータ向けＤＲ機能群３３のＤＢ８３には、図７（ａ）に示す受信イベントと、図７（ｂ）に示す送信イベントとが登録される。サブアグリゲータ（ＳＡＧ−１００２）４３に対応するアグリゲータ向けＤＲ機能群３３のＤＢ８３には、図８（ａ）に示す受信イベントと、図８（ｂ）に示す送信イベントとが登録される。
【００３９】
各需要家（ＵＳＲ−１００１）〜（ＵＳＲ−１０１１）４４に対応する需要家向けＤＲ機能群３４のＤＢ８４には、図９〜図１９に示す受信イベントが登録される。
次に、イベント送信機能、イベント受信機能、受諾可否送信機能、受諾可否受信機能、レポート送信機能及びレポート受信機能について、図２０〜図２５のシーケンスの例を参照して説明する。なお、図２０〜図２５中のＶＴＮ（Virtual Top Node）はＤＲイベントを送信する側となる上位アクタを示し、ＶＥＮ(Virtual End Node)はＤＲイベントを受信して応答を返す側となる下位アクタを示す。
【００４０】
＜１．イベント送信、２．イベント受信＞
（ａ１）イベント登録（電力会社４１）
電力会社４１は、電力需給状況の予測から需給調整が必要と判断した場合に、対象の時間帯を指定した需要家４４へ需給調整を促すためのイベントを作成する（図２０（１））。作成したイベントはオペレータにより、ＧＵＩ５１を通して電力会社向けＤＲ機能群３１のＤＢ８１へ投入されるが、ＤＢ８１への投入は図４のようにＣＳＶ形式のファイルを登録することにより行う。このとき、電力会社向けＤＲ機能群３１のＧＵＩ制御部３１１は、ＤＢインターフェース３１２に対しイベント登録要求を送信し（図２０（２））、このイベント登録要求に対しＤＢインターフェース３１２からイベント登録応答が返送された場合に（図２０（３））、イベントがＤＢ８１に登録される。
【００４１】
（ａ２）イベント送信（電力会社４１）
スケジュール管理部より定期的に起動され（図２０（４））、ＤＢ８１を参照し、配信時刻が現在時刻より前のイベントをそれぞれ該当する下位機能群３へ送信する。この場合、電力会社向けＤＲ機能群３１のＤＲ制御部３１４は、まず送信待ちイベント情報取得要求をＤＢインターフェース３１２に送信し（図２０（５））、ＤＢインターフェース３１２から送信待ちイベント情報取得応答を受信すると（図２０（６））、送信イベント情報取得要求をＤＢインターフェース３１２に送信し（図２０（７））、ＤＢインターフェース３１２から送信イベント情報取得応答を受信すると（図２０（８））、送信イベント通知先情報取得要求をＤＢインターフェース３１２に送信し（図２０（９））、ＤＢインターフェース３１２から送信イベント通知先情報取得応答を受信する（図２０（８））。続いて、ＤＲ制御部３１４は、自アクタ情報取得要求をＤＢインターフェース３１２に送信し（図２０（１１））、ＤＢインターフェース３１２から自アクタ情報取得応答を受信すると（図２０（１２））、対向アクタ情報取得要求をＤＢインターフェース３１２に送信し（図２０（１３））、ＤＢインターフェース３１２から対向アクタ情報取得応答を受信すると（図２０（１４））、送信イベント受諾状態取得要求をＤＢインターフェース３１２に送信し（図２０（１５））、ＤＢインターフェース３１２から送信イベント受諾状態取得応答を受信した後に（図２０（１６））、各通知先に対しイベントを送信する（図２０（１７））。
【００４２】
下位機能群３にイベント通知後、下位アクタ４の管理者に対してメールを送信する（図２０（１８））。
（ａ３）イベント受信（下位アクタ４）
下位機能群３、例えばアグリゲータ４２に対応するアグリゲータ向け機能群３２は、電力会社向けＤＲ機能群３１から受信したイベントをＤＢ８２に格納する。それぞれの機能群３が受信したイベントは図５〜図１９の通りである。
【００４３】
ここで、アグリゲータ向け機能群３２のＤＲフレームワークミドル部３２１は、電力会社向けＤＲ機能群３１からイベントを受信すると（図２１（１））、電力会社向けＤＲ機能群３１に対しＤＲイベント送信応答を返送する（図２１（２））。以後、アグリゲータ向け機能群３２のＤＲ制御部３２２は、受信イベント情報登録要求をＤＢインターフェース３２３に送信し（図２１（３））、ＤＢインターフェース３２３から受信イベント情報登録応答を受信する（図２１（４））。
【００４４】
（ａ４）イベント取得（下位アクタ４）
下位アクタ４のオペレータがそれぞれの機能群３のＧＵＩ５にアクセスしてＤＢ８からイベントを取得する。
（ａ５）イベント登録（アグリゲータ４２、サブアグリゲータ４３）
アグリゲータ４３、サブアグリゲータ４３では、上位アクタ４から受けたイベントを取得すると、受信イベントの内容を分析し、配下のアクタ４へのイベントを作成する。ここでも作成したイベント（図５（ｂ）、図６（ｂ）、図７（ｂ）、図８（ｂ））はオペレータにより、ＣＳＶ形式のファイルによりＧＵＩ５２，５３を通してＤＢ８２、８３へ投入される。
【００４５】
（ａ６）イベント送信（アグリゲータ４２、サブアグリゲータ４３）
スケジュール管理部より定期的に起動され、ＤＢ８（図５（ｂ）、図６（ｂ）、図７（ｂ）、図８（ｂ））を参照し、配信時刻が現在時刻より前のイベントをそれぞれ該当する下位機能群３へ送信する。下位機能群３にイベント通知後、下位アクタ４の管理者に対してメールを送信する。
【００４６】
（ａ７）イベント受信（アグリゲータ４２、サブアグリゲータ４３の下位アクタ４）
下位機能群３は、アグリゲータ向けＤＲ機能群３２、サブアグリゲータ向けＤＲ機能群３３から受信したイベントをＤＢ８４に格納する。それぞれの機能群３が受信したイベントは図９〜図１９の通りである。
【００４７】
（ａ８）イベント取得（需要家４４）
需要家４４のオペレータが需要家向けＤＲ機能群３４のＧＵＩ５４にアクセスしてＤＢ８４からイベントを取得する。それぞれの機能群３が受信したイベントは図９〜図１９の通りである。
アグリゲータ４２、サブアグリゲータ４３は、イベント送信にあたって電力会社４１と需要家４４とを仲介する役割を持つ。しかしながら、これにとどまらず、電力会社４１や上位のアグリゲータ４２から受信したイベントの内容を分析し、配下の需要家４４の属性情報も考慮したうえで、どのようなイベントを配信すれば上位アクタの要求に応えることができるかを検討し、配下の需要家４４へ送信するイベントを考案し作成することが求められる。上位アクタ４から受信したイベントがそのまま下位アクタ４へ自動転送されるのではなく、一度受信したイベントをアクタ４が取得し、改めて下位アクタ４へ送信するイベントをＤＢへ登録する構成とした意義はここにある。
【００４８】
このため、最終的に、需要家４４へイベントが到達し、需要家４４ではイベントの内容に基づく節電行動が期待されることとなるが、電力会社４１が最初に作成したイベントとは内容が異なることは十分にあり得る。
この例では、電力会社４１を発端としたイベント送信としたが、電力会社４１からのイベント発出がないときでも、アグリゲータ４２、サブアグリゲータ４３の自主的な判断で下位のサブアグリゲータ４３や需要家４４に対してイベントを送信することも可能である。
【００４９】
図４〜図１９では、イベント種別を「Emergency」としている。これは、時間帯を指定した緊急の電力削減依頼であり、需要家４４がこれを通知されることで電力需給逼迫を認識し、自主的な消費電力削減を行うことを期待するものである。
＜３．受諾可否送信、４．受諾可否受信＞
（ｂ１）受諾可否登録（需要家４４）
イベント取得後、需要家４４はそのイベントを受諾するかどうかを判断する。受諾／拒否はオペレータにより、ＧＵＩ５４を通して需要家向けＤＲ機能群３４へ投入される。ＤＢ投入の形式はイベント登録と同様である。ここで、需要家向けＤＲ機能群３４のＧＵＩ制御部３４１は、オペレータから受諾可否設定要求を受信すると（図２２（１））、ＤＲ制御部３４２へ受諾可否設定要求を送信する（図２２（２））。ＤＲ制御部３４２はＤＢインターフェース３４３にイベント情報更新要求を送信し（図２２（３））、イベント情報更新要求に対しＤＢインターフェース３４３からイベント情報更新応答を受信すると（図２２（４））、ＧＵＩ制御部３４１を介してオペレータへ受諾可否設定応答を送信する（図２２（５））。
【００５０】
（ｂ２）受諾可否送信（需要家４４）
スケジュール管理部３４４より定期的に起動され（図２２（５−１））、ＤＢ８４を参照し、受諾可否を上位機能群３へ送信する。このとき、ＤＲ制御部３４２は、まず受諾可否送信待ちイベント情報取得要求をＤＢインターフェース３４３に送信し（図２２（６））、ＤＢインターフェース３４３から受諾可否送信待ちイベント情報取得応答を受信すると（図２２（７））、受信イベント情報取得要求をＤＢインターフェース３４３に送信し（図２２（８））、ＤＢインターフェース３４３から受信イベント情報取得応答を受信すると（図２２（９））、受信イベント応答先情報取得要求をＤＢインターフェース３４３に送信し（図２２（１０））、ＤＢインターフェース３４３から受信イベント応答先情報取得応答を受信した後（図２２（１１））、受諾可否を上位機能群３へ送信する（図２２（１２））。
【００５１】
（ｂ３）受諾可否受信（上位アクタ４）
上位機能群３は、需要家向けＤＲ機能群３４から受信した受諾可否をＤＢ８に格納する（図２３（１）、（２））。
（ｂ４）受諾可否取得（上位アクタ４）
上位アクタ４のオペレータがそれぞれの機能群３のＧＵＩ５にアクセスしてＤＢ８から受諾可否を取得する（図２３（３）、（４）、（５））。
【００５２】
（ｂ５）受諾可否登録（アグリゲータ４２、サブアグリゲータ４３）
アグリゲータ４３、サブアグリゲータ４３では、各下位アクタ４から受けた受諾可否を取得すると、受信した受諾可否の内容を分析し、上位アクタ４への受諾可否を作成する。ここでも作成した受諾可否はオペレータにより、ＣＳＶ形式のファイルによりＧＵＩ５２，５３を通してＤＢ８２、８３へ投入される。
【００５３】
（ｂ６）受諾可否送信（アグリゲータ４２、サブアグリゲータ４３）
スケジュール管理部より定期的に起動され、ＤＢ８２，８３を参照し、受諾可否を上位機能群３へ送信する。
（ｂ７）受諾可否受信（アグリゲータ４２、サブアグリゲータ４３の上位アクタ４）
上位機能群３は、アグリゲータ向けＤＲ機能群３２、サブアグリゲータ向けＤＲ機能群３３から受信した受諾可否をＤＢ８に格納する。
【００５４】
（ｂ８）受諾可否取得（電力会社４１）
電力会社４１のオペレータが電力会社向けＤＲ機能群３１のＧＵＩ５１にアクセスしてＤＢ８１から受諾可否を取得する。
電力会社４１と需要家４４との間にアグリゲータ４２、サブアグリゲータ４３が介在する場合には、アグリゲータ４２、サブアグリゲータ４３が、どのような受諾可否を、いつ返信（ＤＢ登録）するかはアグリゲータ４３、サブアグリゲータ４３に委ねられる。すなわち、配下のサブアグリゲータ４３や需要家４４からの受諾可否の送信を待たずとも上位アクタ４に対して受諾可否を返信（ＤＢ登録）することも可能である。
【００５５】
また、アグリゲータ４２、サブアグリゲータ４３は、予め特定したイベントについては下位アクタ４へのイベント送信を行うまでもなくその受諾可否を返信するという運用も可能である。
この例では、電力会社４１を発端としたイベント送信に対する受諾可否の返信としているが、アグリゲータ４２、サブアグリゲータ４３を発端としたイベントに対する受諾可否でも同様な運用が可能である。
【００５６】
＜５．レポート送信、６．レポート受信＞
（ｃ１）レポート登録（需要家４４）
需要家４４は、受諾したイベントの有効期間中の電力消費量についてレポートを作成する（図２４（１））。作成したレポートはオペレータにより、ＧＵＩ５４を通して需要家向けＤＲ機能群３４へ投入される。ＤＢ投入の形式はイベント登録と同様にＣＳＶ形式である。このとき、需要家向けＤＲ機能群３４のＣＳＶ入出力制御部３４５は、ＤＢインターフェース３４３に対しレポート内容登録要求を送信し（図２４（２））、このレポート内容登録要求に対しＤＢインターフェース３４３からレポート内容登録応答が返送された場合に（図２４（３））、レポートがＤＢ８４に登録される。
【００５７】
（ｃ２）レポート送信（需要家４４）
スケジュール管理部３４４より定期的に起動され（図２４（５））、未送信レポートをＤＢ８４より取得し、上位機能群３へ送信する。この場合、需要家向けＤＲ機能群３４のＤＲ制御部３４２は、まず送信待ちレポート情報取得要求をＤＢインターフェース３４３に送信し（図２４（６））、ＤＢインターフェース３４３から送信待ちレポート情報取得応答を受信すると（図２４（７））、送信レポート情報取得要求をＤＢインターフェース３４３に送信し（図２４（８））、ＤＢインターフェース３４３から送信レポート情報取得応答を受信すると（図２４（９））、送信レポート通知先情報取得要求をＤＢインターフェース３４３に送信し（図２４（１０））、ＤＢインターフェース３４３から送信レポート通知先情報取得応答を受信する（図２４（１１））。続いて、ＤＲ制御部３４２は、対向アクタ情報取得要求をＤＢインターフェース３４３に送信し（図２４（１２））、ＤＢインターフェース３４３から対向アクタ取得応答を受信すると（図２４（１３））、レポート内容取得要求をＤＢインターフェース３４３に送信し（図２４（１４））、ＤＢインターフェース３４３からレポート内容取得応答を受信すると（図２４（１５））、未送信レポートをＤＢ８４より取得し、上位機能群３へ送信する（図２４（１６）、（１７）、（１８））。
【００５８】
（ｃ３）レポート受信（上位アクタ４）
上位機能群３は、需要家向けＤＲ機能群３４から受信したレポートをＤＢ８に格納する。
（ｃ４）レポート取得（上位アクタ４）
上位アクタ４のオペレータがそれぞれの機能群３のＧＵＩ５にアクセスしてＤＢ８からレポートを取得する。
【００５９】
（ｃ５）レポート登録（アグリゲータ４２、サブアグリゲータ４３）
アグリゲータ４３、サブアグリゲータ４３では、各下位アクタ４から受けたレポートを取得すると（図２５（１）、（２））、受信したレポートの内容を分析し、上位アクタ４へのレポートを作成する。ここでも作成したレポートはオペレータにより、ＣＳＶ形式のファイルによりＧＵＩ５２，５３を通して各機能群３のＤＢ８２，８３へ投入される（図２５（３）、（４）、（５））。
【００６０】
（ｃ６）レポート送信（アグリゲータ４２、サブアグリゲータ４３）
スケジュール管理部より定期的に起動され、未送信レポートをＤＢ８２、８３より取得し、上位機能群３へ送信する。
（ｃ７）レポート受信（アグリゲータ４２、サブアグリゲータ４３の上位アクタ４）
上位機能群３は、アグリゲータ向けＤＲ機能群３２、サブアグリゲータ向けＤＲ機能群３３から受信したレポートをＤＢ８に格納する。
【００６１】
（ｃ８）レポート取得（電力会社４１）
電力会社４１のオペレータが電力会社向けＤＲ機能群３１のＧＵＩ５１にアクセスしてＤＢ８１からレポートを取得する。
この例では、電力会社４１を発端としたイベント送信に対する受諾可否の返信としているが、アグリゲータ４２、サブアグリゲータ４３を発端としたイベントに対する受諾可否でも同様な運用が可能である。
【００６２】
以上のように上記実施形態によれば、ＤＲにおける情報流通を簡易化し、各アクタ４のオペレータの稼働を削減することができる。また、アクタ４間の通信回線を自前で用意する必要はなく、それぞれのアクタ４はクラウド１上の１箇所のＤＲサービスプラットフォームのＧＵＩ５にアクセスするだけで、他のアクタ４との通信を行いＤＲを実現することが可能である。
【００６３】
また、上記実施形態によれば、電力会社４１と需要家４４との間にアグリゲータ４２を介在することにより、アグリゲータ４２の考えにより、需要家４４から収集した各種生活データに基づいて、個々の需要家４４に最適なイベント（ＤＲの内容）を自由に、きめ細かく提案することができる。また、電力会社４１は個々の需要家４４にどんなＤＲを送るかを考える必要はなく、アグリゲータ４２の方だけを見て電力抑制依頼をかけることができるので、需給計画立案の負担を軽減することが可能となる。さらに、サブアグリゲータ４３を介在することにより、需給計画立案の負担をさらに軽減することが可能となる。
【００６４】
また、上記実施形態によれば、クラウド１上のＤＲサービスプラットフォーム上を流れるイベントの内容を工夫するだけで、様々なＤＲ（ＣＰＰ：緊急ピーク時課金、ＴＯＵ：時間帯別料金、ＰＴＲ：ピーク時リベート）に適用可能である。
さらに、上記実施形態によれば、需要家４４から直接、又はアグリゲータ４２若しくはサブアグリゲータ４３を介して電力会社４１へ送信されるレポートは、イベントの適用期間における電力消費量であるので、電力会社４１は需要家４４の電力消費量を把握できる。
【００６５】
以下に、本発明によって生じる効果について説明する。
DRにおける情報流通を簡易化し、オペレータの稼働を削減することができる。 
アクタ間の通信回線を自前で用意する必要はなく、それぞれのアクタは１箇所のプラットフォームのＧＵＩにアクセスするだけで、他のアクタとの通信を行いＤＲを実現することが可能である。
【００６６】
電力会社と需要家の間にアグリゲータ（サブアグリゲータ）を介在することにより、アグリゲータの考えにより、需要家から収集した各種生活データに基づいて、個々の需要家に最適なイベント（ＤＲの内容）を自由に、きめ細かく提案することができる。
電力会社は個々の需要家にどんなＤＲを送るかを考える必要はなく、アグリゲータの方だけを見て電力抑制依頼をかけることができるので、需給計画立案の負担を軽減することが可能となる。
【００６７】
プラットフォーム上を流れる「イベント」の内容を工夫するだけで、様々なＤＲ（ＣＰＰ：緊急ピーク時課金、ＴＯＵ：時間帯別料金、ＰＴＲ：ピーク時リベート）に適用可能である。
要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
【符号の説明】
【００６８】
１…クラウド、２…インターネット、３…機能群、４…アクタ、５（５１〜５４）…ＧＵＩ、６…ＰＦ事業者、７…電力網、８（８１〜８４）…ＤＢ（データベース）、３１…電力会社向けＤＲ機能群、３２…アグリゲータ向けＤＲ機能群、３３…サブアグリゲータ向けＤＲ機能、３４…需要家向けＤＲ機能群、４１…電力会社、４２…アグリゲータ、４３…サブアグリゲータ、４４…需要家、ＳＶ１…ＮＴＰサーバ、ＳＶ２…ＳＭＴＰサーバ。
【図１】
0005841976.tif 000003
【図２】
0005841976.tif 000004
【図３】
0005841976.tif 000005
【図４】
0005841976.tif 000006
【図５】
0005841976.tif 000007
【図６】
0005841976.tif 000008
【図７】
0005841976.tif 000009
【図８】
0005841976.tif 000010
【図９】
0005841976.tif 000011
【図１０】
0005841976.tif 000012
【図１１】
0005841976.tif 000013
【図１２】
0005841976.tif 000014
【図１３】
0005841976.tif 000015
【図１４】
0005841976.tif 000016
【図１５】
0005841976.tif 000017
【図１６】
0005841976.tif 000018
【図１７】
0005841976.tif 000019
【図１８】
0005841976.tif 000020
【図１９】
0005841976.tif 000021
【図２０】
0005841976.tif 000022
【図２１】
0005841976.tif 000023
【図２２】
0005841976.tif 000024
【図２３】
0005841976.tif 000025
【図２４】
0005841976.tif 000026
【図２５】
0005841976.tif 000027