JP6653153B2 - 電力需要調整計画管理装置 - Google Patents

Description

本発明は、電力需要調整計画管理装置および電力需要調整計画管理方法に関する。

日毎の電力需要には変動があり、ある時間帯に電力需要の高いピークがあると、そのピーク需要に応えるだけの設備投資や運用が電力会社側に必要となる。また、電力の需要と供給とに大きな差が生じると、電力系統の安定性や電力品質の観点で問題が生じる。

このような観点から、電力供給側が電力需要家側に対して電力使用の抑制または促進を要請することを、デマンドレスポンス(以下、適宜、「ＤＲ」と略する)と称する。

これまでは、電力の使用量を操作するＤＲは、電話など手動的な連絡手段を用いて実現されてきた。しかし、２０１３年前後に自動ＤＲの標準規格ＯｐｅｎＡＤＲ ２．０ｂが策定されたのを期に、自動ＤＲの普及が進みつつある（非特許文献１）。この標準規格は、通信部分について規定しており、ＤＲ計画策定は規定していない。
ＯｐｅｎＡＤＲ ２．０ｂのうち主要な機能の、ＥｉＥｖｅｎｔとＥｉＲｅｐｏｒｔを元に、日本国内のデマンドレスポンスの通信仕様がまとめられた（非特許文献２）。この仕様書は、ＯｐｅｎＡＤＲ ２．０ｂのサブセットである。

一方、ＤＲ計画策定とは、目標の調整量に対し、需要家の持つどの機器を、どの時間帯にどれくらい調整するかの計画を立てることである（特許文献１）。なお、特許文献１では、目標を達成しないＤＲ計画も許可している。特許文献１に記載のように、日本のＤＲは厳密でなく、目標を達成しなくても、やれるだけやればよいという状況であった。

特開２０１３−９５６５号公報

OpenADR Alliance著「OpenADR Alliance Releases 2.0b Profile Specification for Full Featured Demand Response Programs」、2013年７月、URL=http://www.openadr.org/index.php?option=com_content&view=article&id=84:openadr-alliance-releases-2-0b-profile-specification&catid=21:press-releases&Itemid=121 JSCA著「デマンドレスポンス・インターフェース仕様書 1.0版(案)」、2013年5月、URL=http://www.meti.go.jp/press/2013/05/20130515004/20130515004-7.pdf

目標を満たすＤＲ計画を立てられない場合、ＤＲ計画の策定者は、ＤＲ計画を策定可能にするため 次のいずれかを行った後で、再計画の策定を試みる。

第１に、ＤＲ計画の策定者は、ＤＲ計画への参加に際して需要家の希望する値を引き下げてもらうように、需要家に依頼する。例えばＤＲ計画の策定者は、最低限割当ててもらいたい調整量などの、需要家の希望値を引き下げてもらえないか依頼する。

第２に、ＤＲ計画の策定者は、ＤＲ計画への参加を依頼して不参加の回答をもらった需要家に対して、再度参加を依頼する。

なお、ＤＲ計画の策定者は、上記の依頼の際には、需要家側にメリットが生じるように、制限やインセンティブ等の依頼条件を見直す。

このように、目標を満たすためのＤＲ計画を策定可能とするための作業は、ＤＲ計画の策定者の経験に基づいて手動で行われており、効率が悪い。

そこで、本発明の目的は、電力需要調整計画を効率よく策定できるようにした電力需要調整計画管理装置および電力需要調整計画管理方法を提供することにある。

上記課題を解決すべく、本発明に従う電力需要調整計画管理装置は、電力需要を調整する計画を管理する電力需要調整計画管理装置であって、需要家側の機器を管理する複数の需要家端末と通信ネットワークを介して双方向通信する通信部と、予め設定される所定の制約条件と複数の需要家端末から通信部を介して取得する所定の需要家側情報とに基づいて、複数の需要家端末の中から選定される少なくとも一つの第１需要家端末に対して所定の時間区分ごとに割り当てる需要調整量を示す電力需要調整計画を作成する計画部と、計画部が電力需要調整計画を作成できた場合、計画部の作成した電力需要調整計画を第１需要家端末に送信して、電力需要調整計画の実行を指示する計画実行指示部と、計画部が電力需要調整計画を作成できない場合に、その原因の調査結果を含む調査結果情報を提供する提供部と、を備える。

本発明によれば、電力需要調整計画を作成できない場合に、その原因の調査結果を含む調査結果情報を提供することができるため、その調査結果情報を用いることで、電力需要調整計画を効率的に再作成することができる。

本実施形態の全体概要を示す説明図である。 ＤＲサーバを適用した電力需要管理システムを示すブロック図である。 ＤＲサーバおよびＤＲ需要家端末のシステム構成図である。 ＤＲサーバの記憶装置に格納されたテーブルを示す説明図である。 初期状態の需要家テーブルである。 ＤＲイベントをサーバから需要家端末へ通知するシーケンス図およびイベントテーブルの構成図である。 ＤＲ応答を需要家端末からサーバへ通知するシーケンス図およびＤＲ応答通知の構成図である。 ＤＲレポートを需要家端末からサーバへ通知するシーケンス図である。 ＤＲ計画の詳細を示す説明図である。 本計画に参加する需要家と補完計画に参加する需要家との関係を模式的に示す説明図である。 ＤＲ計画への参加可否を登録した後の需要家テーブルである。 第１レポート情報の例である。 第２レポート情報の例である。 さらに第１レポート情報を登録した後の需要家テーブルである。 調整可能量の定義を管理するテーブルである。 調整可能量を予測した後の需要家テーブルの一例である。 調整可能量を予測した後の需要家テーブルの他の例である。 ＤＲ計画を策定できた場合の出力結果を示す説明図である。 ＤＲ計画の策定に失敗した場合の出力結果を示す説明図である。 制約条件を管理するテーブルである。 ＤＲ計画の策定処理を示すフローチャートである。 第２実施例に係り、緩和対象の条件を管理するテーブルである。 ＤＲ計画の出力結果を示す説明図である。 ＤＲ計画の策定処理を示すフローチャートである。 第３実施例に係り、ＤＲ計画の出力結果を示すフローチャートである。 ＤＲ計画の策定処理を示すフローチャートである。 第４実施例に係り、インセンティブを上げて需要家端末に再度依頼する処理を示すフローチャートである。

以下、図面に基づいて、本発明の実施の形態を説明する。電力需要の抑制と電力需要の促進とで異なるのは、電気の使用量を減らすか、それとも増やすかという点である。従って、以下では、電力需要を抑制する場合を中心に説明し、電力需要を促進する場合を省略する。しかし、電力需要を促進する場合にも、本発明は適用可能である。

本実施形態では、電力供給者または、電力供給者から依頼を受けた電力アグリゲータ側にあるＤＲサーバ１から、需要家端末２１に対して、電力需要の調整を要請する電力需要調整計画管理システムを説明する。

本実施形態では、ＤＲサーバ１と需要家端末２１との間のＤＲ用の通信を、効率的な方法で実現する。例えば、ＤＲサーバ１は、ＤＲイベントを識別するイベントＩＤやイベントの日時を示すイベント日時を、参加の可能性のある需要家へ通知する機能を備える。このような機能の一例として、ＯｐｅｎＡＤＲ ２．０ｂのＥｉＥｖｅｎｔ機能を挙げることができる。また例えば、ＤＲサーバ１は、ＤＲに関するリソースの量や実績値を、ＤＲ依頼者とＤＲ実施者の間で、定期的または、要請のあるたびごとに送信する機能を有する。このような機能の一例として、ＯｐｅｎＡＤＲ ２．０ｂのＥｉＲｅｐｏｒｔ機能を挙げることができる。ＯｐｅｎＡＤＲ ２．０ｂの規定する上記の各機能は、本実施形態において好適に使用することができる。しかし、本実施形態は、ＯｐｅｎＡＤＲ ２．０ｂの規定する上記の各機能に限定されない。

ＤＲサーバ１は、例えば、イベント通知機能と、ＤＲ応答受信機能と、レポート受信機能と、調整可能量予測機能と、ＤＲ計画機能と、提供機能と、を有する。

イベント通知機能は、例えばＥｉＥｖｅｎｔ機能に規定されているように、電力需要量調整を要請するためのイベント（ＤＲイベントとも呼ぶ）を、需要家端末２１に対して通知する機能である。イベント通知機能は、例えば、図１に示すＤＲ計画実行指示部Ｆ１３、図３に示すイベント通知部Ｆ１３に対応する。図１のＤＲ計画実行指示部と図３のイベント通知部とは、同一の機能（イベントを通知する機能）を実現するものであるため、同一の符号を付す。

ＤＲ応答受信機能は、そのイベントに参加するか否かの応答を、例えばＥｉＥｖｅｎｔの規定されているように、需要家端末２１から受信する機能である。ＤＲ応答機能は、図３に示すＤＲ応答受信部Ｆ１４に対応する。

レポート受信機能は、将来需要家端末２１で調整可能な量についての申告値を、例えばＥｉＲｅｐｏｒｔに規定されているように、需要家端末２１から受け取る機能である。申告値には、例えば、最大調整可能量、希望する最低限の調整可能量を示す最小調整可能量、連続実行可能な最大期間を示す最大継続時間、ＤＲの割当があった場合に最低限実行したい期間を示す最小継続時間、ＤＲの休止が割当たった場合に最低限休止する必要のある期間を表す最小休止期間が含まれる。これらの申告値のうち、幾つかは需要家端末２１の希望する値（需要家端末２１の設置された需要家２が希望する値）であり、他の幾つかは実績値または、仕様で定まっている値である。レポート受信機能は、図３のレポート送受信部Ｆ１５に対応する。なお、図１では、ＤＲ応答受信部Ｆ１４およびレポート送受信部Ｆ１５を、説明の便宜上、通信部１１３の中に含めて示している。

調整可能量予測機能は、予測の基礎となる情報に基づいて、需要家端末２１が調整可能な量を予測する機能である。調整可能量予測機能は、予測した調整量と需要家端末２１から申告された値とを比較し、いずれか低い方をＤＲ計画の作成に使用すべき値として採用する。ＤＲ計画の作成に使用する調整量を、本実施形態では、最終的な調整可能量または最終的調整可能量の予測値と呼ぶ。予測の基礎となる情報としては、例えば、調整量の履歴、過去および将来の気象情報、過去および将来の日が平日か休日かを区別するためのカレンダ情報などがある。調整可能量予測機能は、図１および図３に示す調整可能量予測部Ｆ１２に対応する。

ここでＤＲサーバ１は、図３に示すように需要家テーブルＴ１１やイベントテーブルＴ１０などの各種の管理テーブルを記憶している。それらテーブルの詳細は後述するが、需要家テーブルＴ１１について簡単に説明すると、需要家テーブルＴ１１は、例えば、各需要家端末２１と通信するためのアドレス情報、イベントへの参加の可否を示す情報、上述の申告値、予測した調整可能量、最終的な調整可能量の予測値を記録する。

ＤＲ計画機能は、計画作成の基礎となる情報に基づいて、ＤＲ計画を作成する機能である。ＤＲ計画機能は、図１および図３に示すＤＲ計画部Ｆ１１に対応する。

詳しくは、ＤＲ計画機能は、予め設定される所定の制約条件と各需要家端末２１から取得する所定の需要家側情報とに基づいて、所定の時間区分ごとに、どの時間区分に、どの需要家端末２１に、どれだけの調整量を割り当てるかを含むＤＲ計画を作成する。ＤＲ計画機能は、ＤＲ計画の作成と同時に、そのＤＲ計画を補完する補完計画も作成することができる。

本実施形態では、後述のように、ＤＲ計画を本計画と補完計画とに分けてそれぞれ策定する。本計画とは、ＤＲ計画の大元となる計画であり、補完計画とは需要家端末２１の急なオプトアウトによる影響を補うための計画である。本計画に参加する需要家端末２１は、「第１需要家端末」に該当する。補完計画に参加する需要家端末２１は、「第２需要家端末」に該当する。なお、以下では、計画を策定することを、計画を作成する、または計画を生成すると表現する場合がある。

所定の制約条件は、例えば、ＤＲ計画の目標調整量を達成するために満たすべき条件を含む。例えば、制約条件には、各需要家端末２１について予測した最終調整可能量の合計値が目標調整量以上であるか、などの条件が含まれる。所定の需要家側情報は、例えば、需要家端末２１から取得した申告値である。

ＤＲ計画機能は、目標調整量と、最終調整可能量の予測値と、申告値のうち最大調整可能量以外の値と、補完計画における目標調整量を本計画の目標調整量に対する割合で表現した補完調整量（補完調整量＝補完計画の目標調整量／本計画の目標調整量）とを、計画作成の基礎となる情報として用いる。

そして、ＤＲ計画機能は、計画作成の基礎となる情報を入力として、所定の時間区分ごとに、目標調整量についての制約条件、最終調整可能量の予測値についての制約条件、申告値のうち最大調整可能量以外の値についての制約条件を、満たすかどうかそれぞれ判定する。これにより、ＤＲ計画機能は、どの時間区分において、どの需要家端末２１に、どういった量の調整量を割当てるかを規定するＤＲ計画を策定する。以下、所定の時間区分を、ピリオドまたは時間帯と呼ぶ場合がある。

さらに本実施形態のＤＲサーバ１は、後述のように、ＤＲ計画機能がＤＲ計画の作成に失敗した場合に、再計画を支援するための機能も備える。再計画作成支援機能は、例えば、失敗原因を調査して提供する機能と、ＤＲ計画を自動的にまたは半自動的に再作成する機能とに大別できる。

ＤＲ計画を再作成する機能は、例えば、制約条件を緩和することで再計画の立案を支援する機能と、仮想的な需要家端末を導入することで再計画の立案を支援する機能との、少なくともいずれか一つを含むことができる。さらに、ＤＲ計画を再作成する機能は、立案した再計画を実現するために、需要家端末２１と自動的に交渉するための機能を備えることもできる。

ＤＲ計画を作成できない原因を調査し、その調査結果を提供する機能は、失敗原因を含む調査結果情報を、ＤＲ計画の立案者などに提供する。調査結果情報は、制約条件を満たす解の存在しないピリオドと、失敗原因となった制約条件と、失敗原因となった需要家端末とを、それぞれ特定する情報を含む。さらに調査結果情報は、需要家端末から取得した所定の需要家側情報に不適切な値が含まれている場合に、その不適切な値を特定して立案者に注意を促すための情報を含むこともできる。例えば、調査結果を提供する機能は、需要家端末２１の希望する最小調整可能量が、その需要家端末２１で実現可能な値であると予測された最終調整可能量を上回る場合、その最小調整可能量は不適切な値である。調査結果を提供する機能は、その不適切な値に関する需要家端末およびピリオドを検出し、立案者に警告することができる。

ここで、図１および図３との関係を示すと、失敗原因を調査して提供する機能は、図１および図３に示す詳細作成部Ｆ１１７に対応する。詳細作成部Ｆ１１７は、図３に示すレポート送受信部Ｆ１５およびユーザインターフェース部１１５と共同することで、図１９で後述する詳細結果情報をユーザへ通知する。

ＤＲ計画を自動的にまたは半自動的に再作成する機能は、図１および図３に示す制約条件緩和部Ｆ１１６に対応する。

ＤＲ計画を再作成する機能Ｆ１１６は、仮想的な需要家端末を導入することで再計画の立案を支援する機能Ｆ１１８を含むこともできる。立案した再計画を実現するために、需要家端末２１と自動的に交渉するための機能は、交渉部Ｆ１１９に対応する。

ＤＲ計画を作成できない原因を調査し、その調査結果を提供する機能Ｆ１１７は、失敗原因を含む調査結果情報を、ＤＲ計画の立案者などに提供する。調査結果情報は、制約条件を満たす解の存在しないピリオドと、失敗原因となった制約条件と、失敗原因となった需要家端末とを、それぞれ特定する情報を含む。さらに調査結果情報は、需要家端末から取得した所定の需要家側情報に不適切な値が含まれている場合に、その不適切な値を特定して立案者に注意を促すための情報を含むこともできる。例えば、調査結果を提供する機能は、需要家端末２１の希望する最小調整可能量が、その需要家端末２１で実現可能な値であると予測された最終調整可能量を上回る場合、その最小調整可能量は不適切な値である。調査結果を提供する機能Ｆ１１７は、その不適切な値に関する需要家端末およびピリオドを検出し、立案者に警告することができる。

需要家端末２１は、例えば、イベント受信機能と、ＤＲ応答送信機能と、レポート送信機能と、機器制御機能とを備える。イベント受信機能は、例えばＥｉＥｖｅｎｔ機能に規定されているように、電力需要量の調整を要請するためのイベントをＤＲサーバ１から受信する。イベント受信機能は、図３に示すイベント受信部Ｆ２１に対応する。

ＤＲ応答送信機能は、例えばＥｉＥｖｅｎｔ機能に規定されているように、イベントに参加するか否かの応答をＤＲサーバ１に送信する。ＤＲ応答送信機能は、図３に示すＤＲ応答送信部Ｆ２２に対応する。

レポート送信機能は、例えばＥｉＲｅｐｏｒｔ機能に規定されているように、ＤＲサーバ１に対して、将来調整可能な量についての申告値と、電力使用量の計測値とを、送信する。レポート送信機能は、図３に示すレポート送受信部Ｆ２３に対応する。なお、レポート送受信部Ｆ２３は、交渉部Ｆ１１９などから送られる情報などを受信してユーザインターフェース部２１５へ表示することもできる。

機器制御機能は、図２に示す制御対象機器２２の作動を制御する。機器制御機能は、図３に示す機器制御部Ｆ２４に対応する。

本実施形態によれば、ＤＲ計画を効率的に作成することができ、計画作成に要する時間や作業を低減することができ、ＤＲ計画を策定するアグリゲータなどにとっての使い勝手が向上する。さらに本実施形態によれば、ＤＲ計画を今までよりも短時間で作成できるため、計画作成時から計画実行時までの猶予期間の短いＤＲ計画にも対応できる。さらに本実施形態によれば、ＤＲ計画を今までよりも短時間で作成できるため、電力取引の機会損失を低減することができる。

以下、本明細書では次の用語を用いて説明する。
・ピリオド：ＤＲ計画を策定する際の最小単位時間である。一つの例として、ピリオドは３０分に設定される。
・オプトイン：ＤＲイベントへ需要家端末が参加することである。
・オプトアウト：ＤＲイベントから需要家端末が離脱すること（不参加になること）である。
・本計画：目標調整量を達成するために、各需要家端末へ調整量を配分する計画であり、 補完計画と対比して述べる際に、この用語を使う。
・補完計画：需要家端末の急なオプトアウトにより、本計画が目標調整量を実行できなくなる場合に備えた計画である。

続いて、本実施形態によるＤＲ計画の作成方法の例を説明する。ＤＲ計画の策定方法では、下記の手順１，２を実行する。これにより、本実施形態では、目標調整量に対して、どの需要家端末を、どの時間帯（ピリオド）に、どれくらい調整するかといった内容を含む計画（本計画）を立てる。また、同様の手順で、補完調整割合で決まる補完調整の目標値を満たす補完計画を決める。

（手順１）各ピリオドで次の制約条件を満たす。
（ａ）各需要家端末の調整量の合計が目標値以上であること。
（ｂ）各需要家端末の調整量が最小調整可能量以上であること。
（ｃ）各需要家端末の実行継続時間が、最大実行継続ピリオド数以下であること。
（ｄ）各需要家端末の実行継続時間が、最小実行継続ピリオド数以上であること。
（ｅ）各需要家端末の最小休止ピリオド数を満たすこと。

（手順２）優先順位付けで最良のものを解とする。

優先順位付けは、例えば、割当量と単価との積の全ピリオドでの合計値が 低い程優先するように設定する。

なお、計画作成に際して、各需要家端末のランプアップ、ランプダウンの能力を考慮しても良い。この場合、手順１に示す制約条件において、「ランプアップ、ランプダウンの能力の範囲内であること」という制約を追加すればよい。

図１〜図１５を用いて第１実施例を説明する。図１は、本実施形態の全体概要を示す説明図である。図１は、本発明の理解および実施に必要な程度で、実施形態の構成を説明するものであり、本発明の範囲は図１に示す例に限定されない。以下に述べる機能構成は、一つの例示であり、他の機能構成を採用することもできる。

ＤＲサーバ１は、例えば、ＤＲ計画部Ｆ１１と、調整可能量予測部Ｆ１２と、ＤＲ計画実行指示部Ｆ１３と、ＤＲ応答受信部Ｆ１４およびレポート送受信部Ｆ１５（図３参照）と、ユーザインターフェース部１１５と、通信部１１３とを、備える。

「計画部」としてのＤＲ計画部Ｆ１１は、例えば、作成対象計画選択部Ｆ１１１、計画案作成部Ｆ１１２、判定部Ｆ１１３、仕上げ部Ｆ１１４、出力部Ｆ１１５、制約条件緩和部Ｆ１１６、詳細作成部Ｆ１１７、仮想需要家端末追加部Ｆ１１８と、交渉部Ｆ１１９とを備える。

作成対象計画選択部Ｆ１１１は、本計画と補完計画の中から作成対象を選択する。本実施形態では、後述のように、先に補完計画に参加する需要家端末（第２需要家端末）を選択し、その次に本計画に参加する需要家端末（第１需要家端末）を選択する。これに限らず、先に本計画に参加する需要家端末を選択し、その次に補完計画に参加する需要家端末を選択してもよい。

計画案作成部Ｆ１１２は、作成対象の計画（ＤＲ計画）について計画案を算出する。調整可能量予測部Ｆ１２は、各需要家端末２１で調整可能な需要量を予測する。計画案作成部Ｆ１１２は、予測された調整可能量（最終調整可能量）や目標調整量などに基づいて、計画案を算出する。

判定部Ｆ１１３は、計画案作成部Ｆ１１２で作成された計画案が全ての制約条件を満たすか判定する。本実施形態では、制約条件を全て満たす計画案を「解」とも呼ぶ。

仕上げ部Ｆ１１４は、全ての制約条件を満たす計画案について、ピリオドごとに各需要家端末２１に分配する調整量を算出したり、各需要家のインセンティブ単価と調整量の積の合計に応じて優先順位を決定したりして、計画案を完成版に仕上げる。

出力部Ｆ１１５は、完成した計画を記憶領域へ保存すると共に、ＤＲ計画実行指示部Ｆ１３へ引き渡す。さらに、出力部Ｆ１１５は、ユーザインターフェース部１１５を介して、完成した計画を立案者（ＤＲサーバ１を操作するユーザ）に提示したり、後述する詳細情報を提示したりする。

ＤＲ計画実行指示部Ｆ１３は、図３ではイベント通知部Ｆ１３として説明する。ＤＲ計画実行指示部Ｆ１３は、ＤＲ計画の実行を指示するためのイベントを、通信部１１３から通信ネットワークＣＮ１を介して、計画に参加する各需要家端末２１へ送信する。

一方、判定部Ｆ１１３が、全ての制約条件を満たす計画案が一つも見つからないと判定した場合、つまり、作成した各計画案の全てがいずれか一つ以上の制約条件に反すると判定した場合、立案者（以下ユーザとも呼ぶ）は、詳細作成部Ｆ１１７の作成する計画結果詳細情報を参照することができる。

詳細作成部Ｆ１１７は、計画の作成に成功した場合も失敗した場合もいずれの場合も、その計画の詳細を示す情報を作成できる。計画の作成に失敗した場合の計画結果詳細情報は、「調査結果情報」の一例に該当する。

制約条件緩和部Ｆ１１６は、制約条件の全てを満たす計画案を作成できない場合に、全ての制約条件のうち所定の制約条件を緩和して、計画案作成部Ｆ１１２に計画案の再作成を要求する。制約条件緩和部Ｆ１１６は、例えば、需要家端末２１の希望する最小調整可能量を減らしたり、需要家端末２１の希望する最小継続時間を短くしたりして、制約条件を緩和する。制約条件緩和部Ｆ１１６は、最小調整可能量や最小継続時間などの所定の条件を所定値ずつ段階的に緩和することで、制約条件を徐々に緩和する。制約条件をできるだけ緩和せずに、所期の目的達成に近い計画を作成するためである。

仮想需要家端末追加部Ｆ１１８は、所定の条件を限界まで緩和した場合であっても制約条件を全て満たす計画案を作成できない場合に、ＤＲ計画に参加する仮想的な需要家端末２１を追加して、計算上の解を得る。例えば、仮想的な需要家端末は、全ての制約条件を満たす解を得るために導入される仮想的な存在である。仮想的な需要家端末は、失敗した計画案に含まれる需要家端末２１だけでは満たすことのできなかった制約条件を満たすことのできる、便利な存在として規定される。仮想的な需要家端末と同一の役割を果たすことのできる需要家端末２１を見つけるだけで、全ての制約条件を満たす計画案を作成することができる。もしも、仮想的な需要家端末を計算に導入しない場合は、全ての需要家端末２１について計算を全てやり直す必要があり、計画作成時間が長くなる。

交渉部Ｆ１１９は、制約条件緩和部Ｆ１１６が緩和した制約条件に関わる需要家端末２１や、仮想需要家端末と同一の役割を果たすと見込まれる需要家端末２１に対して、交渉する。すなわち、交渉部Ｆ１１９は、制約条件の緩和について同意を得るべき需要家端末２１や、仮想的な需要家端末の代わりに計画への参加を依頼する需要家端末２１に対して、条件を通知し、回答を得る。

図２は、電力需要管理システムを示すブロック図である。ＤＲサーバ１は、第１通信ネットワークＣＮ１を介して、需要家２に設置された需要家端末２１と双方向通信可能に接続されている。図２では、需要家２および需要家端末２１を一つずつ示すが、実際には複数の需要家２と需要家端末２１が存在しており、各需要家端末２１はＤＲサーバ１に接続されている。

需要家２は、例えば、需要家端末２１と、少なくとも一つの制御対象機器２２と、電力メータ２３とを備えており、各制御対象機器２２と需要家端末２１とは第２通信ネットワークＣＮ２を介して双方向通信可能に接続されている。さらに需要家端末２１は、第２通信ネットワークＣＮ２を介して、メータ２３とも接続されている。

制御対象機器２２は、例えば、冷蔵庫、冷凍庫、空調設備、照明装置、電動モータ、昇降機、加工機などの電力を消費する機器である。制御対象機器２２は、電力系統３から供給される電力を消費して作動する。なお、制御対象機器として、例えば、太陽光発電装置や蓄電池などを含めることもできる。

メータ２３は、需要家２が電力系統３から購入した電力量を計測し、ＤＲサーバ１へ通知する。これに代えて、需要家２の電力消費量を、送配電業者のコンピュータシステムから取得する構成でもよい。

第１通信ネットワークＣＮ１は、データの送受信を主に行うためのものであり、通信事業者の提供する一般通信網でもよいし、独自の専用通信網でもよい。第２通信ネットワークＣＮ２は、機器の制御を主に行うためのものであり、一般通信網でもよいし、独自の専用通信網でもよい。各通信ネットワークＣＮ１，ＣＮ２は、その通信方式も問わず、有線または無線のいずれを用いても良い。

ＤＲサーバ１は、情報サーバ４と双方向通信可能に接続されている。ＤＲサーバ１と情報サーバ４とは、第１通信ネットワークＣＮ１を介して接続されてもよいし、図示せぬ他の通信ネットワークを介して接続されてもよい。情報サーバ４には、例えば、天気予報や過去の気象データを配信する気象情報サーバ、交通渋滞などの情報を配信する交通情報サーバ、コンサートなどの催し物についての情報を配信するサーバ、ニュースを配信するニュースサーバなどを挙げることができる。ＤＲサーバ１は、情報サーバ４から取得した情報を用いることで、各需要家端末２１で実現可能な調整量を予測する。

図３は、ＤＲサーバ１および需要家端末２１のシステム構成図である。本実施形態では、ＤＲ計画を策定するＤＲサーバ１が、需要家端末２１と直接通信する場合を例に挙げて説明する。しかし、ＤＲサーバ１を運用する電力供給者（または電力供給者の依頼を受けたアグリゲータ）と各需要家２との間に、各需要家２を取りまとめるサブアグリゲータが介在する場合もある。サブアグリゲータが、各需要家２の持つ需要家端末２１とＤＲサーバ１との間の通信を中継する場合にも、本発明は適用できる。図３では、情報サーバ４を省略する。

ＤＲ計画を策定するＤＲサーバ１は、第１通信ネットワークＣＮ１を介して、需要家２側の需要家端末２１と双方向通信可能に接続されている。上述のように、ＤＲサーバ１は、通常、複数の需要家端末２１に接続されるが、図３では一つの需要家端末２１を示している。

ＤＲサーバ１は、例えば、ＣＰＵ（Central Processing Unit）１１１、メモリ１１２、通信ポート１１３、記憶装置１１４、ユーザインターフェース部１１５を備える。制御部１１０は、ＣＰＵ１１１とメモリ１１２を含んで構成される。これら制御部１１０、記憶装置１１４およびユーザインターフェース部１１５は内部バスを通じて双方向通信可能に接続されている。記憶装置１１４とユーザインターフェース部１１５は、制御部１１０を介して、通信ポート１１３に接続することができる。通信ポート１１３は、図１に示す通信部１１３に対応するため、通信部１１３と同一の符号を付している。

ユーザインターフェース部１１５は、ユーザへ情報を提供するための情報出力装置と、ユーザからの指示や情報を受け取るための情報入力装置とを備える。情報出力装置としては、例えば、ディスプレイ、プリンタ、音声合成装置、電子メール送信機能などを挙げることができる。情報入力装置としては、例えば、キーボード、タッチパネル、音声入力装置、電子データ読取り装置などを挙げることができる。

記憶装置１１４は、後述する各機能を実現するための所定のコンピュータプログラムと、所定のテーブルを格納している。所定のコンピュータプログラムには、例えば、ＤＲ計画部Ｆ１１、調整可能量予測部Ｆ１２、イベント通知部Ｆ１３、ＤＲ応答受信部Ｆ１４、レポート送受信部Ｆ１５がある。所定のテーブルには、イベントテーブルＴ１０、需要家テーブルＴ１１、図４で後述する各テーブルＴ１２〜Ｔ１８がある。

ＤＲ計画部Ｆ１１は、後述のように、所定の制約条件と所定の需要家側情報とに基づいて、ＤＲ計画を作成する。調整可能量予測部Ｆ１２は、後述のように、各需要家端末２１で実現可能な調整量を予測し、需要家端末２１から申告された調整可能量と予測した調整可能量とのうちいずれか可能性の高い調整量を一つ選択する。

イベント通知部Ｆ１３は、ＤＲ計画の実行を需要家端末２１に要請するためのイベントを通知する。ＤＲ応答受信部Ｆ１４は、このイベントへの参加または不参加を示す回答（ＤＲ応答）を需要家端末２１から受信する。レポート送受信部Ｆ１５は、需要家２の電力使用量などを示す情報を需要家端末２１から受信する。さらに、レポート送受信部Ｆ１５は、計画結果の詳細を示す情報（計画結果テーブルおよび計画結果詳細テーブル）を、需要家端末２１に送信したり、ユーザインターフェース部１１５に表示したりする。レポート送受信部Ｆ１５は、計画結果などを示すレポートを電子メールとしてユーザに送信してもよい。

イベントテーブルＴ１０は、図６で後述するようにイベント情報を格納する。需要家テーブルＴ１１は、図５、図１１、図１４、図１６、図１７で説明するように、ＤＲ計画作成の進捗状況に合わせて、需要家情報を格納する。

需要家端末２１の構成例を説明する。需要家端末２１は、企業や家庭などの各種需要家２に設置されて、それら需要家２での消費電力を制御する。

需要家端末２１は、例えば、ＣＰＵ２１１、メモリ２１２、通信ポート２１３、記憶装置２１４、ユーザインターフェース部２１５を備える。制御部２１０は、例えばＣＰＵ２１１とメモリ２１２を含んで構成される。

記憶装置２１４は、例えば、イベント受信部Ｆ２１、ＤＲ応答送信部Ｆ２２、レポート送受信部Ｆ２３、機器制御部Ｆ２４をそれぞれ実現するためのコンピュータプログラムを格納している。

イベント受信部Ｆ２１は、ＤＲサーバ１のイベント通知部Ｆ１３と通信するための機能である。ＤＲ応答送信部Ｆ２２は、仮想サーバ１のＤＲ応答受信部Ｆ１４に対して、イベントへの参加または不参加を回答する機能である。レポート送受信部Ｆ２３は、電力消費量の実測値などをＤＲサーバ１へ送信するための機能である。レポート送受信部Ｆ２３は、ＤＲサーバ１から受領した情報をユーザインターフェース部２１５を介して表示することもできる。機器制御部Ｆ２４は、需要家端末２１の管理下にある制御対象機器２２の作動を制御する機能である。機器制御部Ｆ２４は、例えば、制御対象機器２２の起動および停止を制御したり、設定値を変更したりできる。

図４は、ＤＲサーバ１の記憶装置１１４に記憶されている他のテーブルＴ１２〜Ｔ１８の概略を示す。

ＤＲ計画部Ｆ１１は、例えば、計画結果テーブルＴ１０、計画結果詳細テーブルＴ１３、条件緩和ルールテーブルＴ１４、制約条件テーブルＴ１５を保持する。計画結果テーブルＴ１０は、ＤＲ計画の作成結果を格納する。計画結果詳細テーブルＴ１３は、ＤＲ計画の作成結果の詳細を格納する。条件緩和ルールテーブルＴ１４は、ＤＲ計画を再度作成する場合の、制約条件を緩和するルールを格納する。制約条件テーブルＴ１５は、ＤＲ計画が満たすべき制約条件を格納する。なお、全ての実施例において、全てのテーブルＴ１０〜Ｔ１８を使用する必要はない。例えば、第１実施例では、制約条件テーブルＴ１５および条件緩和ルールテーブルＴ１４は使用しない。それらのテーブルＴ１５，Ｔ１４は、第２実施例と第３実施例で使用する。

調整可能量予測部Ｆ１２は、例えば、調整量履歴テーブルＴ１６と、気象情報テーブルＴ１７と、カレンダ情報テーブルＴ１８を保持する。

調整量履歴テーブルＴ１６は、各需要家端末２１が過去に達成した調整量の履歴を、日付や時刻、または気象状態と対応付けて管理する。気象情報テーブルＴ１７は、過去の気象情報、現在の気象情報、将来の気象情報を取得して格納する。カレンダ情報テーブルＴ１８は、ＤＲ計画の実施日が平日であったか休日であったかなどを識別するために使用される。調整可能量予測部Ｆ１２は、これらのテーブルＴ１６〜Ｔ１８以外に、例えば、コンサートや国際会議などの各種イベント（ＤＲイベント以外のイベント）に関する情報を管理するテーブルを使用してもよい。

図５は、需要家テーブルＴ１１の初期状態を示す。需要家テーブルＴ１１（１）は、例えば、需要家端末ＩＤ Ｃ１１０と、需要家端末アドレスＣ１１１とを管理する。以下、３つの需要家端末２１を例に挙げて説明するが、これに限らずＤＲサーバ１は、４台以上の需要家端末２１を管理することもできるし、２台以下の需要家端末２１を管理することもできる。

需要家端末ＩＤ Ｃ１１０は、各需要家端末２１を電力需要調整計画管理システム内で一意に識別するための情報である。図５では、３台の需要家端末２１に、「ＣＳＴＭＲ１」「ＣＳＴＭＲ２」「ＣＳＴＭＲ３」といったＩＤを付与している。需要家端末アドレスＣ１１１は、各需要家端末２１と通信するためのネットワークアドレスである。

図６は、ＤＲイベントの通知処理を示すシーケンス図である。以下、ＤＲイベントとイベントと略記する場合がある。ＤＲサーバ１のイベント通知部Ｆ１３は、需要家端末２１のイベント受信部Ｆ２１に対して、イベントを通知する（Ｓ１１）。

需要家端末２１のイベント受信部Ｆ２１は、ＤＲサーバ１からイベントを受領すると、イベント通知部Ｆ１３に対して、受信成功を通知する（Ｓ１２）。

図６の下側に、ＤＲサーバ１から需要家端末２１へ通知されるイベント情報の一例を示すイベントテーブルＴ１０を示す。

イベントテーブルＴ１０は、例えば、イベントＩＤ Ｃ１００と、イベント日付Ｃ１０１と、イベント時間帯Ｃ１０２と、詳細Ｃ１０３とを対応付けて管理する。

イベントＩＤ Ｃ１００は、イベント一意に識別するための情報である。イベント日付Ｃ１０１は、イベントの対象日を示す情報である。イベント時間帯Ｃ１０２は、イベント対象日においてイベントを実施する時間帯を示す情報である。詳細Ｃ１０３は、イベントの詳細を示す情報である。

図６の例では、イベントＩＤ Ｃ１００は「Ｅｖｅｎｔ１」であり、イベント日付Ｃ１０１は「２０１５／１２／３１」であり、イベント時間帯Ｃ１０２は「０９：００−１０：３０」である。詳細Ｃ１０３には、例えば、インセンティブ料金の計算方法を記載したページのアドレス（ＵＲＬ：Uniform Resource Locator）等を記載する。

図７は、ＤＲ応答のシーケンス図である。需要家端末２１は、イベントに参加する場合、ＤＲ応答送信部Ｆ２２からＤＲサーバ１のＤＲ応答受信部Ｆ１４に対して、ＤＲ応答を通知する（Ｓ２１）。ＤＲサーバ１のＤＲ応答受信部Ｆ１４は、需要家端末２１からＤＲ応答を受信すると、需要家端末２１のＤＲ応答送信部Ｆ２２に対して、受信成功を通知する（Ｓ２２）。

図７の下側に、ＤＲ応答で通知される情報Ｔ２１の一例を示す。ＤＲ応答で通知される情報Ｔ２１は、例えば、需要家端末ＩＤ Ｃ２１０、イベントＩＤ Ｃ２１１、回答Ｃ２１２を含む。

需要家端末ＩＤ Ｃ２１０には、需要家テーブルＴ１１で使用する需要家端末ＩＤと同じ値が使用される。イベントＩＤ Ｃ２１１には、イベントテーブルＴ１０で使用するイベントＩＤと同じ値が使用される。回答Ｃ２１２は、需要家端末２１がイベントへ参加するか否かを示す情報を格納する。図７の例では、需要家端末ＩＤとして「ＣＳＴＭＲ１」、イベントＩＤとして「Ｅｖｅｎｔ１」、回答として「参加」が格納されている。

図８は、レポート情報を通知する処理のシーケンス図である。ここでは、需要家端末２１から、ＤＲサーバ１へレポート情報を通知する場合を説明するが、これとは逆に、ＤＲサーバ１から需要家端末２１へレポート情報を通知することもできる。

需要家端末２１のレポート送受信部Ｆ２３は、ＤＲサーバ１のレポート送受信部Ｆ１５に対して、レポート情報を通知する（Ｓ３１）。ＤＲサーバ１のレポート送受信部Ｆ１５は、レポート情報を受信すると、需要家端末２１のレポート送受信部Ｆ２３に対して、受信成功を通知する（Ｓ３２）。

需要家端末２１のレポート送受信部Ｆ２３は、定期的にレポート情報をＤＲサーバ１へ送るために、一定時間待機する（Ｓ３３）。一定時間経過すると、レポート送受信部Ｆ２３は、ステップＳ３１に戻り、上述したステップＳ３１〜Ｓ３３の処理を繰り返す。需要家端末２１からＤＲサーバ１へ送信するレポート情報Ｔ２１，Ｔ２２については、図１２，図１３で後述する。

図９を用いて、ＤＲ計画の例を説明する。ＤＲ計画は、所定の時間区分であるピリオドごとに、すなわち所定の時間帯ごとに、目標調整量を設定している。各ピリオドの目標調整量は、少なくとも一つの（通常は複数の）需要家端末２１により実現される。

図９の上側に、各ピリオドの目標調整量を示す。９時のピリオドの目標調整量は３０Ｗｈであり、９時半のピリオドの目標調整量は４０Ｗｈであり、１０時のピリオドの目標調整量は４０Ｗｈである。調整量の具体的数値と単位は理解のための例示である。以下に述べる他の例を含めて、本発明の範囲は、具体的数値および単位に限定されない。

図９の下側には、各ピリオドの目標調整量がどの需要家端末２１にどれだけ配分されたかをグラフ化して示す。このＤＲ計画には、３台の需要家端末２１（ＣＳＴＭＲ１，ＣＳＴＭＲ２，ＣＤＴＭＲ３）が参加している。図１８で後述する計画結果テーブルＴ１２および計画結果詳細テーブルＴ１３は、図９に示す例に基づいて作成されている。

図９中の太い点線は、目標調整量を示す。図９の太い一点鎖線は、補完計画の目標調整量を示す。補完計画の目標調整量は、図９に示す本計画の目標調整量よりも小さく設定される。図示は省略するが、補完計画は、本計画に参加していない他の需要家端末２１により実現される。補完計画は、補完計画の目標調整量と本計画の目標調整量との比率に合わせて、本計画よりもスケールダウンして作成される。

９時のピリオドでは、目標調整量３０Ｗｈのうち、需要家端末２１（ＣＳＴＭＲ２）に２０Ｗｈが割り当てられ、需要家端末２１（ＣＳＴＭＲ１）に１０Ｗｈが割り当てられている。需要家端末２１（ＣＳＴＭＲ３）は、調整量は割り当てられていない。

９時半のピリオドでは、目標調整量４０Ｗｈのうち、需要家端末２１（ＣＳＴＭＲ１）に１０Ｗｈが、需要家端末２１（ＣＳＴＭＲ２）に２０Ｗｈが、需要家端末２１（ＣＳＴＭＲ３）に１０Ｗｈが、それぞれ割り当てられている。

１０時のピリオドでは、目標調整量４０Ｗｈのうち、需要家端末２１（ＣＳＴＭＲ３）に２０Ｗｈが、需要家端末２１（ＣＳＴＭＲ２）に１０Ｗｈが、需要家端末２１（ＣＳＴＭＲ１）に１０Ｗｈが、それぞれ割り当てられている。

図１０は、本計画に参加する需要家端末２１と、補完計画に参加する需要家端末２１の関係を示す説明図である。ＤＲサーバ１の管理下にある需要家端末群のうち、まず最初に、補完計画に参加する需要家端末群（＃１〜＃６）が抽出される。その次に、残りの需要家群の中から、本計画に参加する需要家端末群（＃１１〜＃１８）が抽出される。

このように先に、補完計画に参加する需要家端末を決定し、その次に本計画に参加する需要家端末を決定する。補完計画の目標調整量は、本計画の目標調整量よりも小さく設定されるため（例えば数％〜十数％程度）、補完計画が必要とする需要家端末の数は、本計画で必要な需要家端末の数よりも少ない。一方、補完計画は、本計画に参加予定の需要家端末が急にオプトアウトした場合に備えて作成されるものであるため、補完計画には信頼性の高い需要家端末が参加すべきである。このような違いは、優先順位で並べ替える際に本計画と補完計画で異なる優先順位で並べ替えることで区別できる。例えば、本計画は、前述のとおり、全体の価格の安い優先順位とし、補完計画は、これまでの実績で離脱した需要家がより多く含まれる優先順位とする。また、補完計画に参加させる需要家と、本計画に参加させる需要家を区別し、それぞれの計画に専念させることでＤＲの実行についての信頼性を増す効果がある。この区別は、補完計画に参加させる需要家以外の中から、本計画に参加させる需要家を選ぶことで実現される。

そこで、本実施例では、管理下にある需要家端末群の中から、最初に補完計画に参加する需要家端末群を選択し、残りの需要家端末群の中から本計画に参加する需要家端末群を選択する。これにより、信頼性の高い補完計画を作成して、本計画の急な変更に備えることができる。さらに、後述の実施例のように、補完計画に参加予定の需要家端末の数を段階的に減らすことで、本計画の再作成を支援することもできる。図１０では、需要家端末２１（＃２）が補完計画から外されて、本計画に組み込まれる様子を点線で示す。

図１１は、イベントへの参加の可否を登録した後の需要家テーブルＴ１１（２）の例を示す。需要家テーブルＴ１１（２）は、図５に示す初期状態の需要家テーブルＴ１１（１）に比べて、イベントＩＤで特定されるイベントへの参加の可否を示す情報Ｃ１１２が追加されている。ＤＲサーバ１は、図７で述べた処理により、イベントに参加を希望する需要家端末２１からＤＲ応答Ｔ２１を受領すると、その参加の可否を需要家テーブルＴ１１へ登録する。

図１２は、第１レポート情報Ｔ２１の例である。第１レポート情報Ｔ２１は、図８で述べた処理により、需要家端末２１のレポート送受信部Ｆ２３からＤＲサーバ１のレポート送受信部Ｆ１５へ送られる。

第１レポート情報Ｔ２１は、ＤＲサーバ１がＤＲ計画を策定するために必要な情報を保持している。例えば、第１レポート情報Ｔ２１は、需要家端末ＩＤ Ｃ２１０、イベントＩＤ Ｃ２１１、最大継続時間Ｃ２１２、最小継続時間Ｃ２１３、最小休止時間Ｃ２１４、各ピリオドの最小調整可能量Ｃ２１５Ａ〜Ｃ２１５Ｃ、各ピリオドの最大調整可能量Ｃ２１６Ａ〜Ｃ２１６Ｃを備えている。

需要家端末ＩＤ Ｃ２１０およびイベントＩＤ Ｃ２１１については、上述した通りであるため、説明を省略する。

最大継続時間Ｃ２１２は、各需要家端末２１から申告される値である。最大継続時間は、需要家端末２１が需要調整を継続して実行可能な最大の時間である。最大継続時間は、需要家側の能力に依存する値である。ここでは、時間や期間の長さをピリオドの数で表示する。

最小継続時間Ｃ２１３は、各需要家端末２１から申告される値であり、需要調整に最低限参加を希望する時間である。つまり最小継続時間Ｃ２１３以上、需要調整に参加できないのであれば、ＤＲ計画に参加しないという需要家の条件を示す。一般に、需要調整に参加する時間が短くなるほど、需要家の得るインセンティブも減少するためである。

最小休止時間Ｃ２１４は、各需要家端末２１から申告される値である。最小休止時間Ｃ２１４は、需要調整を行う前に休止すべき時間であり、需要家側の能力に依存する。例えば、夏場の昼間に空調設備を停止させて需要を調整した場合、その間に上昇した室温を下げる必要があるが、どの程度の時間だけ空調設備を作動させる必要があるかは、その空調設備の能力や家屋の断熱性能などに依存する。

各ピリオドの最小調整可能量Ｃ２１５Ａ〜Ｃ２１５Ｃは、各需要家端末２１から申告される値である。各需要家端末２１は、ピリオドごとにそれぞれ異なる値を、最小調整可能量としてＤＲサーバ１へ申告することができる。最小調整可能量は、需要家端末２１が最小限実行したい需要調整量である。一般に、実行した需要調整量が少ないと、需要家の得るインセンティブも減少するためである。

各ピリオドの最大調整可能量Ｃ２１６Ａ〜Ｃ２１６Ｃは、各需要家端末２１から申告される値である。各需要家端末２１は、ピリオドごとにそれぞれ異なる値を、最大調整可能量としてＤＲサーバ１へ申告できる。最大調整可能量は、需要家端末２１で実行可能な需要調整量の最大値であり、需要家側の能力に依存する。

図１３は、第２レポート情報Ｔ２２の例である。第２レポート情報Ｔ２２は、図８で述べた処理により、需要家端末２１からＤＲサーバ１へ定期的に送信される。

第２レポート情報Ｔ２２は、例えば、需要家端末ＩＤ Ｃ２２０、日付Ｃ２２１、時間帯Ｃ２２２、使用量Ｃ２２３を保持している。

日付Ｃ２２１は、第２レポート情報Ｔ２２の作成日である。時間帯Ｃ２２２は、電力使用量を計測した時間帯である。使用量Ｃ２２３は、需要家端末２１の管理下にある各制御対象機器２２で消費した電力量の合計である。

図１３は、需要家端末（ＣＳＴＭＲ１）からＤＲサーバ１へ「２０１５／１／１／０１：００」に送付されたレポートＴ２２であって、時間帯（００：３０−０１：００）で消費した電力量が１００Ｗｈであることを示している。

電力消費量（電気使用量）から、ベースライン量を差し引いた量が調整量の実績値であり、これを調整量履歴テーブルＴ１６へ登録する。ベースライン量は、需要調整の実績値を算出するための基礎となる値であり、例えば、「直近３ヶ月間の電力消費量」のように設定される。調整量履歴テーブルＴ１６は、図示は省略するが、調整量の実績値を、需要家端末ＩＤごと、および時間帯ごとに、格納したテーブルである。

各需要家端末２１からＤＲサーバ１へ第２レポート情報Ｔ２２を送信するタイミングは、任意である。需要家端末２１は、例えば一定時間が経過するたびに、第２レポート情報Ｔ２２をＤＲサーバ１へ送信してもよいし、需要家から指示された場合に第２レポート情報Ｔ２２をＤＲサーバ１へ送信してもよい。

図１４は、イベントへの参加可否と、第１レポート情報Ｔ２１の内容とを登録した後の需要家テーブルＴ１１（３）の例を示す。図１４に示す需要家テーブルＴ１１（３）は、図１１に示す需要家テーブルＴ１１（２）に比べて、第１レポート情報Ｔ２１の内容Ｃ１１３〜Ｃ１１７が追加されている。

詳しくは、需要家テーブルＴ１１（３）には、新たに、最大継続時間Ｃ１１３、最小継続時間Ｃ１１４、最小休止時間Ｃ１１５、最小調整可能量Ｃ１１６Ａ〜Ｃ１１６Ｃ、最大調整可能量Ｃ１１７Ａ〜Ｃ１１７Ｃが追加登録されている。各項目Ｃ１１３〜Ｃ１１７については上述の通りである。図中の説明を簡略化するために、最大継続時間（Ｄｕｍａｘ）、最小継続時間（Ｄｕｍｉｎ）、最小休止時間（Ｄｔｍｉｎ）、最小調整可能量（Ａｗｍｉｎ）、最大調整可能量（Ａｗｍａｘ）のように、略語を用いる場合がある。

図１５は、調整可能量予測部Ｆ１２で処理する調整可能量の例を示すテーブルＴ１９である。ここで図１５に示す調整可能量定義テーブルＴ１９は、調整可能量を説明するために用いるテーブルである。調整可能量予測部Ｆ１２は、調整可能量定義テーブルＴ１９を実際に保持する必要はない。

調整可能量には、項目Ｃ１９０〜Ｃ１９２に示すように、最大調整可能量（Ａｗｍａｘ）、予測調整可能量（Ａｗｐ）、最終予測調整可能量（Ａｗｆｐ）がある。

調整可能量予測部Ｆ１２は、例えばイベント日付と、イベント時間帯と、需要家端末ＩＤとに基づいて、 調整量履歴テーブルＴ１６と気象情報テーブルＴ１７とカレンダ情報テーブルＴ１８を参照することで、各需要家の実現可能な調整量を予測調整可能量として予測する。

さらに、調整可能量予測部Ｆ１２は、各需要家端末２１から申告された最大調整可能量と予測調整可能量のうち、いずれか低い方を採用する。最大調整可能量は需要家端末２１から申告される値であり、信頼性の高い値であるとは必ずしも言えないためである。

そこで、調整可能量予測部Ｆ１２は、ＤＲ計画の精度を高めて、ＤＲ計画が失敗するリスクを低減するために、申告値である最大調整可能量と予測値である予測調整可能量のうちいずれか低い方の値を、その需要家端末２１で実施可能な最終予測調整可能量として採用する。

図１６は、イベントへの参加可否と、第１レポート情報Ｔ２１の内容と、調整可能量予測部Ｆ１２の予測結果とを登録した後の需要家テーブルＴ１１（４）の例を示す。図１６の需要家テーブルＴ１１（４）は、図１４の需要家テーブルＴ１１（３）に比べて、項目Ｃ１１８Ａ〜Ｃ１１８Ｃと、項目Ｃ１１９Ａ〜Ｃ１１９Ｃとが追加されている。項目Ｃ１１８Ａ〜Ｃ１１８Ｃは、各ピリオドの予測調整可能量（Ａｗｐ）を示す。項目Ｃ１１９Ａ〜Ｃ１１９Ｃは、各ピリオドの最終予測調整可能量（Ａｗｆｐ）を示す。

ここで、需要家テーブルＴ１１（４）の右側に示すように、需要家端末２１（ＣＳＴＭＲ３）において、９時半のピリオドでの最小調整可能量（Ａｗｍｉｎ）は、他と比べて大きい値である「３１０」に設定されている。これは、需要家端末２１（ＣＳＴＭＲ３）が９時半のピリオドにおいて、最低３１０Ｗｈは需要を調整したいと望んでいることを意味している。しかし、需要家端末２１（ＣＳＴＭＲ３）の希望（０９：３０Ａｗｍｉｎ ３１０Ｗｈ）が妥当であるかは、この時点では不明である。

これに対し、需要家端末２１（ＣＳＴＭＲ３）の９時のピリオドでの最終予測調整可能量（Ａｗｆｐ）は、他と比べて小さい値である「０．０１」に設定されている。これは、需要家端末２１（ＣＳＴＭＲ３）の申告した最大調整可能量（Ａｗｍａｘ）と調整可能量予測部Ｆ１２の予測した予測調整可能量（Ａｗｐ）とのうち、いずれか小さい方の値が「０．０１」であったことを意味する。

図１７は、イベントへの参加可否と、第１レポート情報Ｔ２１の内容と、調整可能量予測部Ｆ１２の予測結果とを登録した後の需要家テーブルＴ１１（５）の例である。図１７に示す需要家テーブルＴ１１（５）は、図１６に示す需要家テーブルＴ１１（４）と項目Ｃ１１０〜Ｃ１１９は同一であるが、一部の値が異なる。

具体的には、需要家テーブルＴ１１（５）の右側に示すように、需要家端末２１（ＣＳＴＭＲ３）において、９時半のピリオドでの最小調整可能量（Ａｗｍｉｎ）は、図１６の「３１０」から「１０」に変更されている。

後述の実施例で説明するように、ＤＲサーバ１は、需要家端末２１から申告された値のうち、需要家端末側の希望で定められている値を段階的に緩和することで、全ての制約条件を満たすＤＲ計画を作成できるようにしている。

ここでＤＲ計画の作成に際して、ＤＲサーバ１は、以下の情報を得る必要がある。計画作成に必要な情報とは、例えば、目標調整量、最小継続時間、最大継続時間、最小休止時間、最小調整可能量、最終予測調整可能量、補完調整割合である。これらのうち目標調整量と補完調整割合を除く他の項目は、需要家端末２１ごとに設定すべき項目である。つまり、最小継続時間、最大継続時間、最小休止時間、最小調整可能量、最終予測調整可能量は、需要家端末２１ごとに設定する。目標調整量には、アグリゲータや電力供給者の希望する値が使用される。補完調整割合には、ユーザの希望する値が使用される。本計画の実行可能性を高めるために、ユーザは万が一の場合に補完計画が補う量を、高く設定することができる。

図１８は、ＤＲ計画の作成に成功した場合の、計画結果テーブルＴ１２および計画結果詳細テーブルＴ１３の例を示す。ＤＲサーバ１のＤＲ計画部Ｆ１１は、全ての制約条件を満たすＤＲ計画（本計画および補完計画を含む）に成功すると、図１８に示すテーブルＴ１２，Ｔ１３を出力する。ＤＲサーバ１は、それらテーブルＴ１２，Ｔ１３を、ユーザインターフェース部１１５を通じてユーザに提示することができる。契約内容等によっては、ＤＲサーバ１は、テーブルＴ１１，Ｔ１２の全部または一部を、そのＤＲ計画に参加する需要家端末２１へ送信することもできる。

ＤＲ計画の作成に成功した場合の計画結果テーブルＴ１２は、例えば、レコード番号Ｃ１２０、リクエストＩＤ Ｃ１２１、成否フラグＣ１２２を備える。

レコード番号Ｃ１２０は、レコードごとに一意に振られた識別情報である。リクエストＩＤ Ｃ１２１は、ＤＲ計画ごとに一意の値として与えられる。成否フラグＣ１２２は、リクエストＩＤで特定されるＤＲ計画の作成に成功したか否かを示す情報である。成功の場合は「１」が設定される。なお、図１９で後述するように、ＤＲ計画の作成に失敗した場合、成否フラグには「０」が設定される。

計画結果詳細テーブルＴ１３は、作成に成功したＤＲ計画の詳細を示す。計画結果詳細テーブルＴ１３は、例えば、リクエストＩＤ Ｃ１３０、調整対象ピリオドＣ１３１、ピリオドごとに各需要家端末に割り当てられた調整量Ｃ１３２、本計画フラグＣ１３３を備える。図１８に示す計画結果詳細テーブルＴ１３は、図９に示すＤＲ計画に基づいて作成されている。

調整対象ピリオドＣ１３１は、電力需要を調整する時間帯を示す。需要家端末ごとの調整量Ｃ１３２は、需要調整に参加する需要家端末２１のＩＤと、それら需要家端末２１に調整対象のピリオドごとに割り当てられた調整量を示す。本計画フラグＣ１３３は、本計画であるか補完計画であるかを示す。本計画の場合は「Ｔｒｕｅ」が設定され、補完計画の場合は「Ｆａｌｓｅ」が設定される。

ここでは、説明の便宜上、補完計画で調整する割合を０％とするため、本計画フラグＣ１３３には、全て「Ｔｒｕｅ」が設定される。ここでは、補完計画は省略する。しかし、補完計画は、本計画と同様に作成することができるため、いわゆる当業者であれば、本計画の作成についての記載に基づいて補完計画の作成方法を容易に理解することができ、本発明を実施することができる。

もしも、補完調整割合が正の値に設定されており、補完計画での調整量が割り当てられた需要家端末２１が存在する場合、本計画フラグに「Ｆａｌｓｅ」が設定されたレコードも計画結果詳細テーブルＴ１３に登録されることになる。

図１９は、ＤＲ計画の作成に失敗した場合の、計画結果テーブルＴ１２および計画結果詳細テーブルＴ１３の例を示す。ＤＲ計画部Ｆ１１が、いずれか一つでも制約条件を満たすことができない場合、ＤＲ計画（本計画および補完計画を含む）の作成に失敗したことになる。ＤＲ計画部Ｆ１１がＤＲ計画の作成に失敗すると、図１９に示すテーブルＴ１２，Ｔ１３を出力する。ＤＲサーバ１は、それらテーブルＴ１２，Ｔ１３を、ユーザインターフェース部１１５を通じてユーザに提示することができる。

ＤＲ計画の作成に失敗した場合の計画結果テーブルＴ１２は、レコード番号Ｃ１２０、リクエストＩＤ Ｃ１２１、成否フラグＣ１２２に加えて、さらに失敗ピリオド番号Ｃ１２３、失敗制約条件Ｃ１２４、失敗制約対象需要家Ｃ１２５を備える。すなわち、図１９に示す計画結果テーブルＴ１２は、ＤＲ計画の作成に失敗した原因の概要を示す。

失敗ピリオド番号Ｃ１２３は、ＤＲ計画の作成に失敗したと判明した場合のピリオドを特定する情報である。失敗制約条件Ｃ１２４は、ＤＲ計画の作成に失敗したと判明した場合の、満たされなかった制約条件を特定する情報である失敗需要家端末Ｃ１２５は、ＤＲ計画の作成に失敗したと判明した場合の、制約条件を満たさなかった需要家端末２１を特定する情報である。失敗需要家端末は、失敗した制約条件に関わる需要家端末であり、失敗制約対象需要家端末と呼ぶこともできる。

図１９の例では、２番目のピリオドにおいて、図２０で後述する５番目の制約条件について３番目の需要家で失敗したことを示す。

ここで、失敗需要家端末Ｃ１２５の値は、ＤＲ計画の作成において、需要家端末２１の情報を入力する際の順序を示す。例えば、端末ＩＤがＣＳＴＭＲ１、ＣＳＴＭＲ２、ＣＳＴＭＲ３の順で入力したとすると、失敗需要家端末Ｃ１２５に「３」が設定されている場合は、３番目に入力した端末ＩＤ（ＣＳＴＭＲ３）を持つ需要家端末２１で失敗したことを示す。

失敗需要家端末Ｃ１２５は、図２０で述べる制約条件テーブルＴ１５の需要家毎制約フラグがＣ１５２に「Ｔｒｕｅ」が格納されている場合のみ、設定する。

本実施例では、計画結果テーブルＴ１２の失敗ピリオド番号Ｃ１２３、失敗制約条件Ｃ１２４、失敗需要家端末Ｃ１２５をユーザインターフェース部１１５を介してユーザへ提供する。これにより、本実施例では、ユーザによる再計画の作成を支援する。

図１９の計画結果詳細テーブルＴ１３は、ＤＲ計画の作成に失敗した原因の詳細を示している。計画結果詳細テーブルＴ１３は、リクエストＩＤ Ｃ１３０、調整対象ピリオドＣ１３１、需要家端末ごとの評価Ｃ１３２Ａ、本計画フラグＣ１３３を備えている。

図１９の計画結果詳細テーブルＴ１３は、図１８の計画結果詳細テーブルＴ１３に比べて、需要家端末ごとの調整量Ｃ１３２に代えて、需要家端末ごとの評価Ｃ１３２Ａが設けられている。

評価Ｃ１３２は、そもそも良くない値を持つデータ（不十分データ）の存在を、ユーザにわかりやすく明示するための情報である。ＤＲ計画部Ｆ１１は、リクエストＩＤ Ｃ１３０に示すようにＤＲ計画（ＲＥＱ３）が失敗に終わったことが判明すると、評価Ｃ１３２Ａにおいて、計画作成に適していないデータ（不十分データ）をどの需要家端末２１が申告したのか特定する。

評価Ｃ１３２Ａには、以下の不十分条件１，２のいずれかを満たす場合に「−２」が設定され、不十分条件１，２のいずれも満たさない場合は「−１」が設定される。「−２」は「ＮＧ」を表し、「−１」は「ＯＫ」を表す。
（不十分条件１）：最終予測調整可能量に対し、 最小調整可能量が上回る。
（不十分条件２）：最終予測調整可能量が一定量（例えば１Ｗｈ）より少ない。

図１９の計画結果詳細テーブルＴ１３は、図１６に示す需要家テーブルＴ１１（４）の内容がＤＲサーバ１へ入力された場合の例を示す。図１６の需要家端末ＩＤ（ＣＳＴＭＲ３）に着目すると、９時半のピリオドでの最小調整可能量（Ａｗｍｉｎ）は「３１０」であり、同じピリオドでの最終予測調整可能量（Ａｗｆｐ）は「２０」である。従って、不十分条件１が成立する。そこで、需要家端末ＩＤ（ＣＳＴＭＲ３）の９時半のピリオドに、評価「−２」が設定される。

同様に図１６の需要家端末ＩＤ（ＣＳＴＭＲ３）に着目すると、９時のピリオドでの最終予測調整可能量（Ａｗｆｐ）は「０．０１」であり、一定量「１Ｗｈ」より少ない。従って、不十分条件１が成立する。そこで、需要家端末ＩＤ（ＣＳＴＭＲ３）の９時のピリオドに、評価「−２」が設定される。

需要家端末ＩＤ（ＣＳＴＭＲ３）の１０時のピリオドでは、不十分条件１，２のいずれも成立しないので、評価「−１」が設定される。需要家ＩＤ（ＣＳＴＭＲ１），（ＣＳＴＭＲ２）は、全てのピリオドにおいて不十分条件１，２のいずれも成立しないため、評価「−１」が設定される。

図２０は、制約条件テーブルを管理する制約条件テーブルＴ１５の例である。制約条件テーブルＴ１５は、例えば、条件番号Ｃ１５０、内容Ｃ１５１、需要家毎の制約フラグＣ１５２を備える。

条件番号Ｃ１５０は、制約条件を一意に指定する情報である。内容Ｃ１５１は、制約条件の内容を示す。需要家毎の制約フラグＣ１５２は、制約条件が需要家端末２１ごとに設定する内容であるか（Ｔｒｕｅ）、そうではなく全体に対して１つだけ設定する内容であるか（Ｆａｌｓｅ）を識別するフラグである。

本実施例では、下記のように５つの制約条件を例に挙げる。
（制約条件１）各需要家端末の調整量の上限値の合計が、目標値以上であること。
（制約条件２）各需要家端末の実行継続時間が、最大実行継続時間以下であること。
（制約条件３）各需要家端末の実行継続時間が、最小実行継続時間以上であること。
（制約条件４）各需要家端末の最小休止時間を満たすこと。
（制約条件５）各需要家端末に最小調整可能量以上の調整量を割り当てること。

図２１は、ＤＲ計画を作成する処理のフローチャートである。本処理は主にＤＲ計画部Ｆ１１により実行されるが、ここでは、動作の主体をＤＲサーバ１として説明する。

ＤＲサーバ１は、最初に、ピリオド毎の反復処理を実施する（Ｓ１０１）。そして、ＤＲサーバ１は、制約条件を満たす状態遷移を生成する（Ｓ１０２）。

ＤＲサーバ１は、各需要家端末２１について、需要調整の実行の有無の組合せを全て抽出し、それらの組合せのうち図２０に示す全ての制約条件を満たす組合せを生成する（Ｓ１０２）。図２１では、この組合せを状態遷移と呼んでいる。

ＤＲサーバ１は、制約条件を全て満たす組合せ（状態遷移）のうち、解があるか判定する（Ｓ１０３）。ＤＲサーバ１は、解がある場合（Ｓ１０３：ＹＥＳ）、ＤＲ計画に参加予定の各需要家端末に対して、調整量を配分する（Ｓ１０４）。

ここで、ＤＲサーバ１は、ＤＲ計画に参加予定の需要家端末に対して、少なくとも最小調整量以上の調整量が割り当たるように、調整量を配分する。さらに、ＤＲサーバ１は、ＤＲ計画に参加予定の各需要家端末に配分した調整量の合計が目標調整量となるように、調整量を配分する。ＤＲサーバ１は、需要家端末２１に優先度を設定し、優先度を考慮して調整量を配分してもよい。例えば、ＤＲ計画への参加実績などから需要家端末の信頼度を算出し、信頼度の高い順に調整量を配分してもよい。または、以前のＤＲ計画において不利な条件を承諾した需要家端末２１に対して、そのときの不利益を埋め合わせるべく高い優先度を設定し、優先度の高い順に調整量を割り当ててもよい。

ＤＲサーバ１は、ステップＳ１０４で調整量を配分した結果を、ピリオド毎に値を持つことが可能な内部変数に格納し、現在処理中のピリオド番号ごとに連結する。初回の処理では、連結ではなく新規生成とする。

ＤＲサーバ１は、ピリオド毎の反復処理を終えると（Ｓ１０６）、優先度順に並び替えて、最優先のものを最終的な解として決定する（Ｓ１０７）。ＤＲサーバ１は、例えば、割り当てる調整量と電力購入単価との積の合計が安い順に並べ替えて、最優先のものを解として選択する。

ＤＲサーバ１は、本計画、補完計画の両方を作成したか判定する（Ｓ１０８）。本計画および補完計画の両方を作成済みの場合（Ｓ１０８：ＹＥＳ）、本処理は終了する。本計画または補完計画のいずれかが作成されていない場合（Ｓ１０８：ＮＯ）、ＤＲサーバ１は、作成対象の計画を切り替えて（Ｓ１０９）、ステップＳ１０１へ戻る。先に補完計画から作成した場合は作成対象を本計画に切り替え、先に本計画から作成した場合は作成対象を補完計画に切り替える。

補完計画の作成に際しては、本計画の目標調整量と補完調整割合とから、補完計画の目標調整量を算出して使用する。

ＤＲサーバ１は、ステップＳ１０３で解が存在しないと判定すると（Ｓ１０３：ＮＯ）、解が存在しないことが判明したピリオド番号を特定する（Ｓ１１０）。さらに、ＤＲサーバ１は、解が存在しないことが判明した制約条件および需要家端末からなる制約条件情報を特定する（Ｓ１１１）。つまり、失敗制約条件と失敗需要家端末とを含む情報を特定する。上述の通り、制約条件が需要家端末ごとに設定するものである場合のみ、その制約条件を満たすことができない需要家端末を特定する。

ＤＲサーバ１は、ステップＳ１１１で特定した情報に基づいて、ＤＲ計画の作成に適していない不十分データが存在するか調査する（Ｓ１１２）。ＤＲサーバ１は、ステップＳ１１２の調査結果を、図１９で述べた調査結果テーブルＴ１２および調査結果詳細テーブルＴ１３として、ユーザに提示する。なお、失敗原因の調査結果は、図１９に示すテーブル構成以外の構成でユーザに提示することもできる。

本実施例によれば、ＤＲサーバ１は、ＤＲ計画の作成に失敗した場合にその原因を調査し、調査結果をテーブルＴ１２，Ｔ１３としてユーザへ提供する。したがって、ユーザはテーブルＴ１２，Ｔ１３を参照することで、失敗原因を把握することができ、新たなＤＲ計画を再び作成することができる。この結果、ＤＲ計画の作成に要する時間を短縮することができ、作成効率を向上できる。

さらに、本実施例では、ＤＲサーバ１は、ＤＲ計画の作成に失敗した場合に、ＤＲ計画の作成にそもそも適していない不十分データの有無を検査し、ユーザへ提示する。したがって、ユーザは、具体的にどこで失敗したのかを速やかに把握することができる。

本実施例では、需要家端末２１の申告する最大調整可能量と、過去の実績等に基づいて調整可能量予測部Ｆ１２で予測する予測調整可能量とのうち、いずれか低い方の値を採用する。従って、現実的なＤＲ計画を作成して、実行時の成功率を高めることができ、ＤＲサーバ１の信頼性が向上する。

図２２〜図２４を用いて第２実施例を説明する。本実施例を含む以下の各実施例は、第１実施例の変形例に相当するため、第１実施例との相違を中心に説明する。本実施例では、ＤＲ計画の作成に失敗した場合に、予め設定した所定の制約条件を段階的に緩和し、ＤＲ計画の再度の作成を試みる。

上述の通り、ＤＲ計画の作成に際して、ＤＲサーバ１は、目標調整量以外に、最小継続時間、最大継続時間、最小休止時間、最小調整可能量、最終予測調整可能量、補完調整割合などを取得する必要がある。

それらの情報のうち、最小継続時間、最小調整可能量、補完調整割合は、需要家またはユーザの希望に応じて設定される値（希望値）である。最大継続時間、最小休止時間、最終予測調整可能量は、需要家側の能力に依存する値（能力値）である。一般に、能力値は、希望値に比べて変更が難しい。希望値は、能力値よりも変更が容易である。

図２２は、ＤＲ計画を再度作成する場合に使用する条件緩和ルールテーブルＴ１４の例である。以下、ＤＲ計画の再作成を、再計画と呼ぶ場合がある。

条件緩和ルールテーブルＴ１４は、例えば、条件番号Ｃ１４０、緩和条件名Ｃ１４１、緩和順序Ｃ１４２、緩和値Ｃ１４３を備える。

条件番号Ｃ１４０は、緩和する条件を識別するための情報である。緩和条件名Ｃ１４１は、緩和する条件の内容を示す情報である。緩和順序Ｃ１４２は、緩和する条件が複数ある場合に、その実施順序を規定する情報である。緩和値Ｃ１４３は、緩和する条件について、一回毎に制約を緩める量である。

条件緩和ルールテーブルＴ１４は、ＤＲサーバ１の出荷時または設置時などに、ＤＲサーバ１のベンダーが設定してもよいし、ＤＲサーバ１のユーザが設定してもよい。例えば、ユーザは、希望値に関する条件を条件緩和ルールテーブルＴ１４へ登録する。希望値に関する条件は、能力値に関する条件よりも緩和が容易であり、再計画処理に適しているためである。ユーザは、緩和の順序や緩和値も、好みの値に設定できる。

図２２の例では、緩和可能な所定の条件として、補完調整割合、最小調整可能量、最小継続時間を挙げる。それらのうち最小調整可能量、最小継続時間、補完調整割合の順で高い優先度が設定されている。最小調整可能量や最小継続時間は、需要家側の能力に依存する値ではなく、需要家の希望する値であり、需要家の承諾（需要家端末２１からの承諾）により容易に変更できるためである。

補完調整割合も、ユーザの希望値であるため、その変更は容易である。しかし、補完調整割合は、補完計画が本計画を補うことのできる能力を規定する。従って、ＤＲ計画の信頼性を高く維持する観点から、最も低い順序が設定されている。しかし、どのような条件をどの順番でどのように緩和するかは、ユーザが個別具体的に判断して設定することができる。条件緩和ルールテーブルＴ１４は、ユーザが自由に設定できるため、ユーザの使い勝手が向上する。

図２３は、計画結果テーブルＴ１２Ａの例である。計画結果テーブルＴ１２Ａは、図１９で述べた計画結果テーブルＴ１２と同様に、レコード番号Ｃ１２０、リクエストＩＤ Ｃ１２１、成否フラグＣ１２２、失敗ピリオド番号Ｃ１２３、失敗制約条件Ｃ１２４、失敗需要家端末Ｃ１２５を備える。さらに本実施例の計画結果テーブルＴ１２Ａは、緩和条件フラグＣ１２６を備えている。

緩和条件フラグＣ１２６は、緩和対象の所定の条件（最小調整可能量、最小継続時間、補完調整割合等）のうち、実際に緩和したか否かを示す情報である。緩和した条件には「１」が設定され、緩和していない条件には「０」が設定される。

緩和条件フラグＣ１２６の形式は問わないが、本実施例では、行方向に需要家端末が配置され、列方向に緩和する所定条件が配置される行列形式で記載する。

図２３において、リクエストＩＤ「ＲＥＱ２」のレコードは、図１７に示す需要家テーブルＴ１１（５）の場合を示す。目標調整量は、図９で述べた例である。リクエストＩＤ「ＲＥＱ３」のレコードは、図１６に示す需要家テーブルＴ１１（４）のときの場合を示す。図１６の需要家テーブルＴ１１（４）に基づくＤＲ計画は、需要家端末ＩＤ（ＣＳＴＭＲ３）の９時半の最小調整可能量（Ａｗｍｉｎ）が「３１０」と大きいため、作成に失敗する。

そこで、ＤＲサーバ１は、図２２に示す条件緩和ルールテーブルＴ１４に従って、緩和順序の最も高い「最小調整可能量」を「３００Ｗｈ」減少させる。これにより、需要家端末ＩＤ（ＣＳＴＭＲ３）の９時半の最小調整可能量（Ａｗｍｉｎ）は「３１０」から「１０」へ低下する。この結果、ＤＲサーバ１は、図１７に示すように、条件を一つ緩和した後の需要家テーブルＴ１１（５）を得ることができる。従って、ＤＲサーバ１は、ＤＲ計画の作成に成功する。

「ＲＥＱ４」のレコードは、図１６に示す需要家テーブルＴ１１（４）の場合において、９時のピリオドにおける目標調整量が図９に示す目標調整量よりも１０Ｗｈ高い場合の例である。図９では、９時のピリオドの目標調整量が「３０Ｗｈ」に設定されていたが、図２３に示す例での目標調整量は「４０Ｗｈ」に設定されているものとする。ここで、図１６を参照すると、テーブルＴ１１（４）の下側に示すように、９時のピリオドにおける最終予測調整可能量（Ａｗｆｐ）は、需要家端末（ＣＳＴＭＲ１）が「１０Ｗｈ」、需要家端末（ＣＳＴＭＲ２）が「２０Ｗｈ」、需要家端末（ＣＳＴＭＲ３）が「０．０１Ｗｈ」である。従って、９時のピリオドでは、ＤＲ計画に参加する全ての需要家端末（ＣＳＴＭＲ１〜３）で調整可能な量を集めても、「３０．０１Ｗｈ」にしかならず、目標調整量「４０Ｗｈ」に達しない。

従って、「ＲＥＱ４」に示すＤＲ計画は、目標調整量を達成することができないため、失敗と判定される。この場合、図２２に示す緩和可能な条件の全てを限界まで緩和しても、目標調整量を実現することはできない。「ＲＥＱ４」のＤＲ計画において、緩和条件フラグの行列に全て「１」が設定されているのは、全ての緩和条件を限界まで緩和して再計画を試みたことを表している。なお、説明を簡単にするために、本実施例の補完調整割合は、０％に設定されているものとする。

図２４は、本実施例による計画作成処理のフローチャートである。本処理は、図２１で述べたステップＳ１０１〜Ｓ１１２を全て備える。さらに本処理では、ＤＲサーバ１が、ステップＳ１０２の結果の中に解が存在しないと判定すると（Ｓ１０３：ＮＯ）、制約条件を緩和できるか判定する（Ｓ１２０）。上述のように、ＤＲサーバ１は、予め設定した緩和可能な条件のうち少なくとも一つを緩和することで、その緩和した条件に対応する制約条件を緩和することができる。

ＤＲサーバ１は、制約条件を緩和可能であると判定すると（Ｓ１２０：ＹＥＳ）、所定の条件を緩和することで制約条件を緩和し（Ｓ１２１）、ステップＳ１０１へ戻る。これに対し、ＤＲサーバ１は、例えば、緩和可能な全ての条件を限界まで緩和しつくしたために、これ以上制約条件を緩和できないと判定すると（Ｓ１２０：ＮＯ）、ステップＳ１１０〜Ｓ１１２により計画結果詳細テーブルＴ１３を作成してユーザへ提示する。

このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施例では、制約条件を緩和するための所定の条件を段階的に緩和することで、制約条件を緩和させてＤＲ計画の再作成を試みることができる。従って、ユーザは、自動的または半自動的に、再計画の作成を実施することができ、第１実施例の場合よりもＤＲ計画作成のための時間を短縮でき、効率を向上できる。

図２５および図２６を用いて第３実施例を説明する。本実施例では、ＤＲ計画の再作成時に、解の存在しない状態を無くすことで、ＤＲ計画の作成処理が停止してしまうのを抑制する。

図２５は、本実施例の計画結果テーブルＴ１２Ｂと計画結果詳細テーブルＴ１３Ｂの例 を示す。図２５に示す計画結果テーブルＴ１２Ｂは、図１８に示す計画結果テーブルＴ１２と同様にレコード番号Ｃ１２０、リクエストＩＤ Ｃ１２１、成否フラグＣ１２２を備えるが、さらに緩和条件フラグＣ１２６と需要家端末追加フラグＣ１２７を備える。需要家端末追加フラグＣ１２７は、仮想的な需要家端末をＤＲ計画の作成に際して追加したか（Ｔｒｕｅ）、していないか（Ｆａｌｓｅ）を表す。

本実施例の計画結果詳細テーブルＴ１３Ｂは、図１８に示す計画結果詳細テーブルＴ１３に比べて、需要家端末ごとの調整量Ｃ１３２に、仮想的需要家端末（ＶＩＲＴＵＡＬ）が追加されている。

「ＲＥＱ５」で示すＤＲ計画は、図１６に示す需要家テーブルＴ１１（４）の場合において、９時のピリオドの目標調整量が図９に示す目標調整量よりも「１０Ｗｈ」だけ大きい場合の例である。ここで、需要家端末（ＣＳＴＭＲ３）は、９時のピリオドにおいて休止状態であること、すなわち調整量の割当てが０に決定されたと仮定している。

上述のように、９時のピリオドの目標調整量は「４０Ｗｈ」である。しかし、ＤＲ計画に参加予定の需要家端末（ＣＳＴＭＲ１）で可能な調整量は「１０Ｗｈ」であり、もう一つの需要家端末（ＣＳＴＭＲ２）で可能な調整量は「２０Ｗｈ」である。３番目の需要家端末（ＣＳＴＭＲ３）の調整可能量は「０．０１Ｗｈ」であるため、９時のピリオドでは調整量は割り当てられていない。

従って、９時のピリオドでは「１０Ｗｈ」だけ調整量が不足している。仮想的な需要家端末は、計画失敗の原因を解消することができる需要家端末として定義されているため、仮想的な需要家端末をＤＲ計画に導入するだけで、そのＤＲ計画の作成は成功する。

もっとも仮想的な需要家端末は、仮想的な存在に過ぎないため、このままでは実行可能なＤＲ計画を作成することはできない。そこで、ユーザは、仮想的な需要家端末の代わりとなる現実の需要家端末を探索する。仮想的な需要家端末の代わりにＤＲ計画に参加する現実の需要家端末を１つだけ見つけることができればよい。したがって、管理下にある全ての需要家端末２１を対象として再計画を作成する場合に比べて、短時間で再計画を作成することができる。

図２６は、本実施例による計画作成処理のフローチャートである。本処理は図２４で述べた処理のステップＳ１０１〜Ｓ１０８とステップＳ１２０，Ｓ１２１を有する。本処理は、図２４に示すステップＳ１１０〜Ｓ１１２を備えていない。本処理では、計算上、ＤＲ計画の作成に失敗しないためである。

さらに本処理は、新規なステップＳ１３０，Ｓ１３１，Ｓ１３２を備える。ＤＲサーバ１は、制約条件を緩和できないと判定すると（Ｓ１２０：ＮＯ）、仮想的な需要家端末をＤＲ計画に追加済みであるか判定する（Ｓ１３０）。

ＤＲサーバ１は、ＤＲ計画に仮想的な需要家端末を未だ追加していない場合（Ｓ１３０：ＮＯ）、図２５に示すように、仮想的な需要家端末（ＶＩＲＴＵＡＬ）をＤＲ計画に追加する（Ｓ１３１）。

そして、ＤＲサーバ１は、仮想的な需要家端末が持つべきデータを設定し（Ｓ１３２）、ステップＳ１０１へ戻る。仮想的な需要家端末が持つべきデータとは、計画失敗の原因を解消するためのデータである。例えば、上述のように、最終予測調整可能量に不足が生じているピリオドがある場合、仮想的な需要家端末によってその不足分を埋める。

この後、ユーザは、仮想的な需要家端末の代わりとなる需要家端末２１を、ＤＲサーバ１の管理下にある需要家端末群の中から一つ発見する。ユーザは、例えば、インセンティブを特別に高く設定したりするなどして、仮想的な需要家端末の代わりとなる需要家端末を見つけることができる。

このように構成される本実施例も第１、第２実施例と同様の作用効果を奏する。さらに本実施例では、解が存在しないと判定された場合に（Ｓ１０３：ＮＯ）、緩和条件を限界まで緩和した後で（Ｓ１２０：ＮＯ）、ＤＲ計画を計算上成立させるための仮想的な需要家端末を導入する。従って、本実施例では、全ての需要家端末を対象にしてＤＲ計画を作り直すよりも、短時間でＤＲ計画を作成することができる。ユーザは、仮想的な需要家端末の代わりとなる需要家端末を一つ見つけるだけでよいためである。

仮想的な需要家端末の数は１つに限定しない。例えば、調整量の不足しているピリオドが複数ある場合は、それらのピリオドごとに仮想的な需要家端末を導入してもよい。または、複数のピリオドでの調整量不足を計算上解消するための仮想的な需要家端末を１つだけ導入してもよい。

図２７を用いて第４実施例を説明する。本実施例では、第２実施例で条件を緩和する対象となった需要家端末や、第３実施例で仮想的な需要家端末の代わりとなる需要家端末に対して、自動的に承諾を求める依頼を送信し、その回答を得る。このような依頼は、ＯｐｅｎＡＤＲに基づく通信で実現できる。以下、制約条件の緩和対象の需要家端末あるいは仮想的な需要家端末の代わりとなる需要家端末を、依頼対象の需要家端末と呼ぶ。

一例として制約条件を緩和する場合を説明する。ＤＲサーバ１のイベント通知部Ｆ１３から、依頼対象の需要家端末２１のイベント受信部Ｆ２１へ依頼通知Ｔ３１を送る（Ｓ１４１）。依頼を受けた需要家端末２１は、その依頼に回答する（Ｓ１４２）。

ＤＲサーバ１は、依頼対象の需要家端末２１から回答を受信すると、回答内容と依頼内容とを比較する（Ｓ１４３）。ＤＲサーバ１は、回答内容が依頼内容と同一の場合、すなわち依頼対象の需要家端末２１がＤＲサーバ１からの依頼をそのまま承諾した場合、制約条件を緩和したＤＲ計画を採用する（Ｓ１４４）。これに対し、ＤＲサーバ１は、依頼対象の需要家端末２１から、依頼内容を上回る回答を得た場合、その回答内容に基づいてＤＲ計画を再修正する（Ｓ１４４）。

なお、依頼対象の需要家端末２１から所定時間内に回答がなかった場合や、回答内容が依頼内容を満足しない場合（依頼を拒否した場合）は、他の需要家端末を対象として、依頼通知を送信すればよい。または、複数の需要家端末２１に対して一斉に依頼し、もっとも早く承諾した需要家端末を選択してもよい。

依頼通知Ｔ３１は、例えば、イベントＩＤ Ｃ３１０、イベント日付Ｃ３１１、イベント時間帯Ｃ３１２、依頼内容Ｃ３１３、インセンティブＣ３１４を備える。

依頼内容Ｃ３１３は、依頼する内容を示す。依頼内容としては、例えば前記事前に申告を受けていた最小調整可能量などの項目について希望する変更後の値を明示する。事前に４００Ｗｈで申告されていた値を、１００Ｗｈへと下げてもらいたいときなどを想定している。前記図２３でいうと、ＲＥＱ３のＣＳＴＭＲ３の需要家が、最小調整可能量を、３００Ｗｈ下げることに対して承諾をもらうといったことに相当する。インセンティブＣ３１４は、依頼を承諾した場合に得られるインセンティブを示す。

第３実施例で述べた仮想的な需要家端末の代わりとなる需要家端末に依頼する場合も、図２７で述べたと同様の方法を用いることができる。

本実施例も第１、第２、第３実施例と同様の作用効果を奏する。さらに、本実施例では、制約条件の緩和対象の需要家端末あるいは仮想的な需要家端末の代わりとなる需要家端末に対して、ＤＲサーバ１は自動的に依頼して回答を求めるため、ＤＲ計画の作成に要する手間と時間をより一層低減することができ、使い勝手も向上する。

添付図面２７ではイベント通知部、イベント受信部間で送受信するように記述したが、２つのレポート送受信部間で送受信しても構わない。
なお、本発明は、上述した実施形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。上述の実施形態において、添付図面に図示した構成例に限定されない。本発明の目的を達成する範囲内で、実施形態の構成や処理方法は適宜変更することが可能である。

また、本発明の各構成要素は、任意に取捨選択することができ、取捨選択した構成を具備する発明も本発明に含まれる。さらに特許請求の範囲に記載された構成は、特許請求の範囲で明示している組合せ以外にも組み合わせることができる。

１：ＤＲサーバ、２：需要家、３：電力系統、２１：需要家端末、２２：制御対象機器、２３：メータ、１１０；制御部、１１１：マイクロプロセッサ、１１２：メモリ、１１３：通信ポート、１１４：記憶装置、１１５：ユーザインターフェース部、Ｆ１１：ＤＲ計画部、Ｆ１２：調整可能量予測部、Ｆ１３：イベント通知部、Ｆ１４：ＤＲ応答受信部、Ｆ１５：レポート送受信部

Claims (12)

1. 電力需要を調整する計画を管理する電力需要調整計画管理装置であって、
   需要家側の機器を管理する複数の需要家端末と通信ネットワークを介して双方向通信する通信部と、
   予め設定される所定の制約条件と前記複数の需要家端末から前記通信部を介して取得する所定の需要家側情報とに基づいて、前記複数の需要家端末の中から選定される少なくとも一つの第１需要家端末に対して所定の時間区分ごとに割り当てる需要調整量を示す電力需要調整計画を作成する計画部と、
   前記計画部が前記電力需要調整計画を作成できた場合、前記計画部の作成した前記電力需要調整計画を前記第１需要家端末に送信して、前記電力需要調整計画の実行を指示する計画実行指示部と、
   前記計画部が前記電力需要調整計画を作成できない場合に、その原因の調査結果を含む調査結果情報を提供する提供部と、
   を備え、
   前記計画部は、前記計画部が前記電力需要調整計画を複数作成できた場合、予め用意される指標に従って設定される優先順位に基づいて、前記複数の電力需要調整計画の中から最良の電力需要調整計画を選択し、前記第１需要家端末に含まれる少なくとも一つの第１需要家端末が前記電力需要調整計画から離脱した場合に生じる変動を軽減する補完計画を、前記電力需要調整計画とは異なる優先順位に基づき、作成する、
   電力需要調整計画管理装置。
2. 前記計画部は、前記所定の制約条件に関する少なくとも一つの所定の条件を緩和する制約条件緩和部をさらに備え、
   前記制約条件緩和部は、前記計画部が前記電力需要調整計画を作成できないと判定した場合に、前記所定の条件を緩和して、前記計画部による電力需要調整計画の再作成を要求する、
   請求項１に記載の電力需要調整計画管理装置。
3. 前記計画部は、前記需要家端末で実行可能な需要調整量を予測する調整可能量予測部をさらに備えており、
   前記調整可能量予測部は、前記所定の需要家側情報に含まれている前記需要家端末で実行可能な需要調整量の自己申告値と、需要調整量の履歴と、気象情報およびカレンダ情報とに基づいて、前記需要家端末で実行可能な需要調整量を予測する、
   請求項１に記載の電力需要調整計画管理装置。
4. 前記提供部は、前記計画部が前記電力需要調整計画を作成できない原因となった、時間区分を特定する情報を、前記調査結果情報に含める、
   請求項１に記載の電力需要調整計画管理装置。
5. 前記提供部は、前記調査結果情報に、前記所定の需要家側情報に含まれる情報のうち、前記計画部が前記電力需要調整計画を作成できない原因となった所定の情報を含める、
   請求項４に記載の電力需要調整計画管理装置。
6. 前記所定の条件には、前記複数の需要家端末のうち前記補完計画に参加する第２需要家端末の数を減ずるという条件が含まれており、
   前記制約条件緩和部は、前記第２需要家の数を所定の緩和値ずつ緩和させる、
   請求項２に記載の電力需要調整計画管理装置。
7. 前記複数の需要家端末の中から前記第１需要家端末が先に選択され、残った複数の需要家端末の中から前記第２需要家端末が選択される、
   請求項６に記載の電力需要調整計画管理装置。
8. 前記計画部は、前記所定の制約条件を満たすための仮想的な第１需要家端末を追加する仮想需要家端末追加部をさらに備え、
   前記仮想需要家端末追加部は、前記制約条件緩和部による前記所定の条件を緩和する余地がなくなった場合に、前記仮想的な第１需要家端末を前記第１需要家端末に追加して、前記計画部による前記電力需要調整計画の再作成を要求する、
   請求項２に記載の電力需要調整計画管理装置。
9. 前記提供部は、前記計画部が前記電力需要調整計画を作成できない原因となった、需要家端末を特定する情報と制約条件を特定する情報とを、追加で、前記調査結果情報に含める、
   請求項８に記載の電力需要調整計画管理装置。
10. 前記制約条件緩和部は、前記所定の条件について、それぞれの優先順序および緩和値を予め設定しており、前記優先順序に従って前記緩和値だけ段階的に緩和することで前記所定の条件を緩和する、
    請求項２に記載の電力需要調整計画管理装置。
11. 前記制約条件緩和部は、前記複数の需要家端末のうち、前記所定の条件の緩和に関連する需要家端末に対して、前記所定の条件の緩和に関する情報を送信し、送信対象の前記需要家端末からの回答を自動的に取得する、
    請求項２に記載の電力需要調整計画管理装置。
12. 前記仮想需要家端末追加部は、前記仮想的な第１需要家端末の代わりとなりえる需要家端末に対し、参加条件を示して前記電力需要調整計画への参加を要請し、参加を要請した需要家端末からの回答を受領する、
    請求項８に記載の電力需要調整計画管理装置。
    

Images