JP2012118982A - 電力システムにおける需要応答を予測するシステムおよび方法 - Google Patents

Abstract

【課題】電力システムにおける需要応答を予測するシステムおよび方法を提供する。
【解決手段】様々なユーティリティＤＲプログラムに対する需要応答を推定するために、ユーティリティ顧客のネットワークで使用するシステムおよび方法。システム１００は最初に、各プレミス１０４に対する顧客情報に基づいて、プレミスをクラスタに集合させる。応答推定関数は、各クラスタに対して展開される。需要応答イベント要求はその後、クラスタおよび応答推定関数にしたがって処理される。
【選択図】図１

Description

本願発明は、電力システムにおける需要応答を予測するシステムおよび方法に関する。

需要応答とは、特定の期間中の集合的利用需要を少なくするために、個別の需要を削減またはシフトするようにユーティリティ消費者を促す／誘導するために使用される機構のことを言う。例えば、電気ユーティリティは、電力のピーク需要を減らすために需要応答プログラムを利用する。需要応答プログラムは典型的には、特定の期間中に需要を少なくすることに賛成するためのインセンティブを顧客に与える。これらのプログラムの多く（例えば、重要ピーク価格設定）は、ユーティリティが所与の期間にわたる限られた数の需要応答／減少イベント（例えば、毎年２０）のみを呼び出し、また、各特定のイベントに対して持続時間（例えば、数分、数時間）を制限することができることを規定している。さらに、各需要応答イベントは典型的には、需要応答プログラムに参加しているプレミスの全てを含んでいる。比較的わずかなプレミスが参加している場合は、全てのプレミスに対して需要応答（ＤＲ）イベントを呼び出すことで、十分である可能性が高い。しかし、参加者の数が増加すると、ユーティリティは毎回参加者のグループまたはサブセットに対してＤＲイベントを呼び出すことよって、改善された利点を達成することができる。これにより、ユーティリティが契約条件を越えることなくより頻繁にイベントを呼び出すことが可能になり、過剰な負荷減少および／または反発ピークが避けられる。

ＤＲプログラムが典型的には、負荷を減少させるための機会の数を制限している場合、ユーティリティは各機会／イベントに対する利点を最大限にしたい。これらの利点としては、生成／調達費用および供給停止を減少させることが挙げられる。

米国特許出願公開第２０１０／０１１４７９９号明細書

これらおよび他の理由で、本発明に対する需要がある。

需要応答要求を処理するために、ユーティリティプレミスのネットワークで使用するシステムおよび方法である。システムおよび方法は、各プレミスに対する顧客情報に基づいて、クラスタにプレミスを集める。応答予測関数は、各クラスタに対して展開され、需要応答イベント要求は、応答予測関数に基づいてクラスタを使用して処理される。

本発明の性質および様々な追加の特性は、図面に略図的に記載されている、本発明の例示的な実施形態を検討すればより完全に分かるだろう。同様の参照番号は、対応する部品を示している。

本発明の一実施形態によるユーティリティ管理システムを示す図である。 本発明の別の実施形態によるユーティリティ管理システムを示す図である。 例示的な実施形態による需要応答モジュールを示す図である。 需要応答イベントに対する例示的なプレミス応答のフローチャートである。 例示的な実施形態による推測方法を示す図である。 本発明の例示的な実施形態による、需要応答イベントを処理するクラスタ化方法のフロー図である。 例示的な実施形態による、図６に示した処理ステップのフロー図である。 図７に示すクラスタ化プロセスの非限定的な例示のフロー図である。 図８に示す例示的な処理ステップのフロー図である。

上記図面は代替実施形態を記載しているが、説明において記されているように、本発明の他の実施形態も考えられる。全ての場合において、本開示は、本発明の図示された実施形態を、限定としてではなく代表として示している。当業者は、多くの他の修正形態および実施形態を考え出すことができ、これらは本発明の原理の範囲および精神に含まれるものである。

本明細書に記載された実施形態は、ユーティリティが特定の期間中の需要応答または減少イベントの使用を最適化することを可能にするエネルギー管理システムおよび方法を対象としている。本発明の実施形態が、エネルギーまたは電気ユーティリティおよび送電線網作業の内容で記載されているが、当業者は、他の目的およびユーティリティにもこのシステムおよび方法を使用することができることが分かるだろう。

本明細書で使用されているように、「モジュール」という用語は、ソフトウェア、ハードウェアまたはファームウェア、またはこれらのあらゆる組合せ、または本明細書に記載したプロセスを行なうまたは容易にするあらゆるシステム、プロセスまたは機能のことを言う。

重要ピーク価格設定（ＣＰＰ）、可変ピーク価格設定（ＶＰＰ）、直接負荷制御（ＤＬＣ）、および他の様々なインセンティブプログラムなどの需要応答プログラムは、いつ、どれだけの頻度で、およびどれだけの持続時間でユーティリティが参加プレミスに対する需要応答イベントを指定することができるかに関する、契約上の仕様を有する需要応答プログラムの例である。ＤＲプログラムによる利点を最大限にするために、参加プレミスのサブセットに対する負荷の減少および反発を正確に推定することができる必要がある。正確な推定により、（すなわち、特殊な負荷減少を達成するのに必要なプレミスの数を要求することのみによって）ユーティリティが利用可能なＤＲ利点をより効率的に利用することが可能になり、また、反発影響（プレまたはポストイベント期間にシフトされる負荷）が、ＤＲ計画および発信プロセスにおいて説明されることが保証される。また、正確な推定により、ユーティリティ（または、集積業者、小売業者、または他の負荷サービス主体などの他の主体）が、ＤＲ能力を卸売電力市場により積極的に提供することが可能になる。

例えば、契約では、ユーティリティは毎年最大１５イベントまで呼び出すことができ、各イベントは毎年最大合計６０時間で、午後１２時から午後６時の時間の間に起こることを規定することができる。本発明の実施形態によると、ユーティリティは、各プレミスに対して６時間ごとに１０イベント、または４時間ごとに１５イベント、または１５イベント、６０時間の制限内に収まるようなイベントおよび時間のあらゆる他のそうした組み合わせを使用することを選択することができる。

この例では、ユーティリティは、需要応答プログラムに参加している１００，０００の顧客を有すると仮定する。加えて、ユーティリティは、参加顧客のサブセットを各イベントに含めるように指定することができる。ユーティリティが、ＤＲイベントを呼び出すかどうか、およびどれだけのプレミスを含めるかを評価する場合、重要な要素は、ＤＲイベントに参加するために選択されている場合に、プレミスの各セットが与える応答（負荷変化）を理解することである。毎年限られた数のイベントしかなく、より短い時間尺度（数時間以下）における負荷の変化の度合が高いので、ＤＲイベントへの個別のプレミス応答の正確な推定を行なうことが極めて難しい。同様のプレミス挙動のグループ化に基づいて展開されたクラスタを利用することによって、サンプルサイズを大きくし、より正確な応答推定アルゴリズムを生成することが可能である。

システムおよび方法の実施形態は、いくつかの基準に基づいて、ユーティリティプレミスをクラスタに集合させることによって作用する。非限定的な例として、プレミスは利用または消費特徴に基づいてクラスタ化することができ、同様の利用特徴を示すプレミスは、各プレミスに対する利用プロファイルに基づいて利用クラスタにクラスタ化される。利用プロファイルは、契約タイプ、プレミスサイトでの機器／負荷のタイプ、典型的な負荷利用または消費、使用回数、使用持続時間、地理的位置などに基づく可能性がある。他の非限定的および例示的な実施形態では、プレミスをイベント応答基準に基づいてクラスタ化することができ、同様のイベント応答挙動を示す顧客は、応答クラスタにクラスタ化される。プレミスのクラスタ化は、ユーティリティのパフォーマンス目標を達成するためのあらゆる適切な基準に基づくことができる。クラスタサイズは、システムのプレミス情報、アプリケーションおよび所望のパフォーマンスに左右される。

加えて、様々なレベルのクラスタ化を使用して、応答推定の精度をさらに良くすることができる。利用に基づきプレミスをクラスタ化する非限定的な例をさらに詳しく説明すると、各利用クラスタをその後、需要応答イベントに対する同様の応答プロファイルに基づいて、需要応答または応答クラスタに分割することができる。例えば、利用クラスタ内のいくつかのプレミスは、任意の需要応答またはインセンティブプログラムに参加していない可能性がある。各利用クラスタ内のこれらのプレミスは、応答クラスタに集合させることができる。利用クラスタ内の一部のプレミスは、需要応答イベントに対する高速応答を有することができ、その他は需要応答イベントに対する低速応答を有することができる。需要応答イベントに対するプレミス応答は、かなり変化する。システムおよび方法の実施形態によると、需要応答イベントに対する同様の応答プロファイルを有するプレミスは共に、応答クラスタにグループ化することができる。利用クラスタサイズおよび応答クラスタサイズは、プレミス情報、アプリケーション、所望のパフォーマンスに左右され、ユーティリティまたはサービスプロバイダによって設定することができる。この非限定的例でプレミスを利用クラスタおよび応答クラスタにクラスタ化することによって、ユーティリティは、需要応答イベントに対する応答（例えば、負荷と持続時間の減少）を正確に評価または推定することができ、したがって、需要応答イベント要求に対する応答を最適化することができる。応答クラスタの応答が推定されると、需要応答イベントに応答するために選択された応答クラスタ内のプレミスは、送信グループにグループ化される。送信グループはその後、需要応答イベントに応答するために展開される。このような正確な推定により、ユーティリティがイベント毎のプレミスのサブセットを使用することが可能になるだけでなく、所要のシェッドおよびシェッドに対する正確に推定された応答に基づいて展開するようにプレミスの選択を最適化することができる。

本発明の一実施形態による例示的なエネルギー管理システムが、図１に示されている。システム１００は、エネルギー管理サーバ１０２、プレミスサイト１０４、およびユーティリティ１０８を含んでいる。本発明の実施形態の説明を容易にするために、単一のサーバ１０２および単一のユーティリティソース１０８が図１に示されている。しかし、本発明の実施形態はこれらの数に限定されるものではなく、ユーティリティネットワーク内にあらゆる数のエネルギー管理サーバ、プレミスサイト、サービスプロバイダ、および制御センタがある可能性があることを理解されたい。加えて、エネルギー管理サーバ１０２は、ユーティリティ１０８によって、および／またはあらゆる他のものによって配置および／またはホスティングすることができる。

各プレミスサイト１０４は、プロセッサ１１２、メモリ１１４、およびユーザインターフェイス１１６を有するエネルギーマネージャ１１０を含んでいる。ユーザインターフェイス１１６は、例えば、ディスプレイと共にキーボードまたはタッチ画面を含むことができる。プロセッサ１１２は、負荷１１８、センサ１２０、再生可能エネルギー１２２、記憶装置１２４、およびプラグイン電気自動車（ＰＥＶ）またはプラグインハイブリッド電気自動車（ＰＨＥＶ）１２６などの様々なプレミスデバイスの動作を監視および制御するプログラムを実行する。センサ１２０は、メータ、サーモスタット、占有センサ、湿度計、およびこのような他のデバイスを備えている。再生可能エネルギーリソース１２２は、例えば太陽光および／または風力デバイスを含むことができる。プロセッサ１１２は、例えばＺｉgｂｅｅ、Ｚウェーブ、ＷｉＦｉまたはホームプラグを含むいくつかのインターフェイスまたはプロトコルのいずれかを使用して、様々な構成部品を制御する。プレミスサイト１０４、サーバ１０２、およびユーティリティ１０８の間の通信は、例えば、ＷＡＮ（例えば、インターネット）１０６、ＷｉＭＡＸ、ブロードバンド、ＡＭＩ、および／または電力線搬送を介して起こる。通信は、プライベートネットワークを介して起こることができる。あらゆる適切な通信手段を使用することができる。

エネルギー管理サーバ１０２は、需要応答（ＤＲ）モジュール１２８、ネットワーク管理サービス（ＮＭＳ）モジュール１３０、ユーザインターフェイスモジュール１３２、顧客データベース（ＤＢ）１３４、およびプログラムデータベース（ＤＢ）１３６を備えている。ＮＭＳモジュール１３０は、ＤＲモジュール１２８、プレミス１０４、およびユーティリティ１０８に通信管理およびプロビジョニングを行なう。顧客データベース１３４は、ネットワーク内の顧客用プレミスプロファイルを記憶する。各プレミスプロファイルは、例えば、ネットワーク内の各プレミスに対する履歴データ、およびあらゆる需要応答プログラム内への参加に関する情報などのデータを含んでいる。履歴データは、例えば負荷タイプ、使用時間（ＴＯＵ）、使用の持続時間、シェッドまたは需要応答イベントに関する情報を含むことができる。データベース１３４内に記憶されたプレミス利用情報は、２４時間にわたる時間単位負荷および時間単位価格を含む負荷データ、天候情報（例えば、温度、湿度、風速、加熱および冷却度など）を含む環境データ、および曜日、季節などの日時情報で周期的に（例えば、毎時間、毎日）更新することができる。加えて、データベース１３４は、各プレミスに対するイベントデータを記憶する。より詳細には、データベース１３４は、プレミスが需要応答イベントに参加したかどうか、開始時間および終了時間、曜日、季節などに関する履歴情報を記憶する。加えて、負荷減少および反発の量は、データベース１３４内に記憶される。応答予測および予期将来利点計算に関するデータはまた、データベース１３４内に記憶することができる。プログラムデータベース１３６は、エネルギー管理サーバ１０２によって実施される様々なアプリケーションおよびプログラムを記憶する。ユーザインターフェイスモジュール１３２は、オペレータによる情報の交換を可能にする。

本発明の一実施形態では、エネルギー管理サーバ１０２は、図２に示すように、１つまたは複数のユーティリティ制御センタ２００に物理的および／または論理的に配置することができる。加えて、ユーティリティ制御センタ２００は、ネットワークに対する負荷予測を実行し、生成および伝達システムのパフォーマンスを監視、制御および最適化する、エネルギー管理システム（ＥＭＳ）モジュール２０２を備えることができる。監視制御およびデータ取得（ＳＣＡＤＡ）モジュール２０４は、グリッド内の異なる点でリアルタイム情報を与え、またローカル制御を行なう。供給停止管理システム（ＯＭＳ）モジュール２０６は、ネットワーク内の顧客サイト１０４に対する負荷状態情報および供給停止回復情報を監視する。ＯＭＳモジュール２０６によって行なわれる機能のいくつかは、故障予測を含んでおり、供給停止および消費者への影響の範囲に関する情報を顧客に提供し、回復努力を優先させる。ＯＭＳモジュール２０６は、地理情報システム（ＧＩＳ）モジュール２０８によって生成および維持される分配システムの詳細ネットワークモデルに基づいて機能する。分配管理システム（ＤＭＳ）モジュール２１０は、負荷状態および負荷応答に関する情報を提供することによって、悪いまたは不安定なネットワーク状態に対するリアルタイム応答を提供する。ＤＭＳモジュール２１０は、アラームおよび／またはイベントに対する応答を管理する。サービス契約情報、インセンティブおよび／または需要応答プログラムへの参加、および契約価格情報を含む顧客情報は、例えば、顧客情報システム（ＣＩＳ）モジュール２１２によって監視および制御される。直接負荷制御（ＤＬＣ）モジュール２１４は、例えばサーモスタット−ＨＶＡＣ、温水器、プールポンプ、水洗機、乾燥機、食器洗い機、ＬＣＤ／プラズマＴＶ、プラグ負荷（例えば、コンピュータ、コンピュータ周辺機器／付属品、ファックス機、電源装置）、冷蔵庫、および照明器具などの顧客サイトデバイスを制御および管理する。オン／オフ、エコモード／通常モード、または多数の個別省電力モード（例えば、減光照明）を有する主に個別のタイプのデバイスがある。顧客課金は、課金モジュール２１６によって行なわれる。

本発明の実施形態によると、ＤＲモジュール１２８は、プレミス１０４、ユーティリティ１０８、ならびにデータベース１３４および１３６からの情報を利用して、例えば、需要応答イベントを呼び出すかどうか、関連する利用および／または応答クラスタにしたがった送信グループによる需要応答イベントへの応答の予測、どの顧客をイベントに含めるか、ならびにイベントの時間および持続時間を判断する。図３に示すように、ＤＲモジュール１２８は、ＤＲイベント要求に応答するためにプレミスの送信を行なうイベント送信モジュール１２７、送信グループへのプレミスの集合および分解を行なう集合／分解モジュール１２９を含んでいる。加えて、ＤＲモジュール１２８はまた、各クラスタ内のプレミスの応答を推測するためにプレミス情報を利用する予測モジュール１３１を含んでいる。測定および検証モジュール１３３は、ＤＲイベントへのプレミスの応答を測定および検証する。ＤＲモジュール１２８の他の機能としては、例えば、偶発応答、および供給停止緩和が挙げられる。

本発明の実施形態は、特定の基準によってプレミスをクラスタ化する。説明を容易にするために、非限定的例が利用クラスタに関して記載されている。本発明の実施形態は、ユーティリティが需要応答イベントに対する応答をより正確に推定することを可能にするために、利用挙動および応答挙動にしたがってプレミスをクラスタ化する。ネットワーク内のプレミスに対する応答挙動は、履歴データに基づいて展開される。需要応答プログラムが最初に開始された場合、または履歴データがない場合、応答クラスタは利用クラスタと同じである。十分な履歴応答が蓄積されると、またはシード、シミュレーション、またはいくつかの他のデータが履歴データとして使用される場合、利用クラスタは応答クラスタに分割される。プレミスが利用クラスタに集合され、その後、応答クラスタに分割されると、応答予測器が各利用および応答クラスタのために開発される。応答予測器はその後、対応する利用または応答クラスタ内の各プレミス用の需要応答イベント要求に対する応答を推定するために使用される。全てのプレミスが利用クラスタに最初に割り当てられる（ＤＲイベントに実際に参加するまで、応答データがない）ので、このような十分なデータが捕捉されて、応答クラスタの形成、および応答クラスタレベルでの推定の両方を行なうときまで、利用クラスタレベルで予測が行なわれる。

応答推定アルゴリズムを開発する方法は、クラスタ化（利用または応答）の各レベルで適用することができる。応答クラスタ化は、各需要応答プログラムに対して行われる。同じクラスタ化を、特定の需要応答プログラムの各発生のために利用することができる。以下の例示的および非限定的な例では、クラスタ化を使用して需要応答イベントに対する需要応答を推定する際に使用される応答予測器を開発するための実証的方法が記載される。しかし、これに限らないが、回帰技術、ベイズ法、ならびにニューラルネットワーク、遺伝的アルゴリズム、およびサポートベクトル機（ＳＶＭ）を含む人工知能を含む、様々な推定方法を使用することができる。

本実施例では、各応答クラスタ内で、需要応答イベントが呼び出されない非参加負荷と、クラスタの各メンバに対してイベントが呼び出される参加負荷の間の差は、ＤＲイベントに関連する期間にわたり、このクラスタに対する実際の負荷応答値を与える。これらの応答値は、クラスタに対する応答推定値を展開するために使用される。この推定値はその後、（局所的に変わる天候またはメータ／デバイス状態などのリアルタイム情報に基づいて、推定値を調節する見込みで）特定のクラスタ内の全てのプレミスに適用される。この概念は、図４に示されている。点線は、一日の基本または通常負荷を示している。破線は、需要応答イベント中の負荷を示している。需要応答ウィンドウ中の減少、および需要応答ウィンドウのすぐ周りのプレ反発およびポスト反発は、いくつかのエネルギー消費タスクを非需要応答期間まで移動させる典型的な顧客傾向を示していることに留意されたい。点―破線によって反映された、基本負荷と需要応答負荷の間の差は、プレミスのシェッド応答を示している。

このような非限定的な例では、応答クラスタに対する通常の負荷は、履歴負荷データを見て、需要応答イベントが呼び出されない場合に現在の需要応答イベントを呼び出すための日と同様の日数（すなわち、季節、曜日、時刻など）から応答クラスタ内の各プレミスに対する負荷のいくつかの単純または加重平均をとり、応答クラスタに対する推定通常負荷に到達するようにこれらのプレミス値を平均化することによって予測される。同様に、需要応答負荷（すなわち、仮に需要応答イベントが呼び出される場合の、応答クラスタの負荷）を推定するために、需要応答イベントが実際に呼び出された同様の日数からの応答クラスタ内の各プレミスに対する負荷の同様の平均が判断され、これらのプレミス値は応答クラスタに対する推定需要応答負荷に到達するように平均化される。応答クラスタに対する推定または推測通常負荷と推定需要応答の間の差は、特定の応答クラスタに対する推定シェッド応答につながる。この例では、応答クラスタ全てに対して推定が行なわれる。しかし、あらゆる数の応答クラスタを使用することができる。使用する同様の日数は、ユーティリティによって判断することができる、または所望のパフォーマンスに対して自動的に判断することができる。

ユーティリティでの１つまたは複数の需要応答またはインセンティブプログラムの実施の始めに、需要応答負荷を推定するための履歴データがない。様々な方法を使用して、プログラムが定位置になり、これに限らないが、同様の地理領域内の同様の層の役割を果たす他のユーティリティからの使用シード値、シミュレーションデータ、またはプロファイルデータを含む履歴データが生成されるまで、必要なデータを提供することができる。需要応答イベントが呼び出されると、プレミスに対する実際のデータは、履歴に収集され、最終的に、他のユーティリティから使用される初期プロファイルデータ、または初期に使用することができるあらゆるシードまたはシュミレーションデータを置換する。この非限定的な例では、上に記載したように、人口を応答クラスタに分割するのに十分なデータが存在するまで、推定が利用クラスタレベルで行なわれる。イベント日の間に参加と非参加プレミス負荷を比べることによって、ＤＲイベント日での各プレミスの実際の応答を測定するために、利用クラスタがさらに使用される。

例示的な例が図５に示されている。この非限定的な例では、他のユーティリティからのシェッド応答プロファイルを、ステップ５０２で示すように、いくつかの顧客タイプに対して生成することができる。ステップ５０４および５０６に示すように、目標ユーティリティで需要応答プログラムに参加する各プレミスは、適当なプロファイルにマッピングすることができ、そのプロファイルに対するシェッド応答を使用して初期応答を推定することができる。ステップ５０８では、需要応答イベントが呼び出されると、これに限らないが、温度、曜日、時刻、月、季節などの需要応答イベント日の特徴が特定される。ステップ５１０では、イベント内の顧客プレミスに対する履歴通常負荷データおよび需要応答データがあるかどうか判断される。答えがいいえである場合、その後、処理はステップ５１２に進み、ステップ５０６で記憶されたシェッド応答がステップ５１６で使用されて、需要応答イベントを処理する。答えがはいである場合、その後、通常負荷および需要応答負荷が推定され、ステップ５１４では同様の日に対して推定される。需要応答イベントに応答する顧客サイトまたはプレミスの実際の応答は、ステップ５１８および５２０に記憶される。

いくつかの実施形態では、推定を改善し、予測の誤差を最小限に抑えるためにサンプリングが使用される。より詳細には、応答クラスタ内のいくつかのプレミスがリアルタイムサンプリングに使用される。非限定的な例として、リアルタイムに近いデータに対してメータをサンプリングすることができる。需要応答イベント要求が受信された場合に、推定パラメータがリアルタイムに近いデータで更新されるように、サンプリングを周期的に行なうことができる。サンプリングするメータの数は、ユーティリティによって、自動的に、またはいくつかの他の方法によって判断することができる。十分なメータデータが興味のある各クラスタ（利用または応答）で得られることを保証するために、サンプリング計画が作成される。これらのプレミスのメータは、クラスタ用の通常の負荷に対してリアルタイムに近いデータを得るためにサンプリングされる。応答推定値または推定シェッド応答はその後、予測される通常負荷に対するこのようなリアルタイムに近いデータに基づいて更新される。非限定的な例として、サンプリングされたメータ読み込みの平均は予測通常負荷として使用することができる。このようなサンプリングは、予測誤差を最小限に抑え、したがって、応答クラスタの推定シェッド応答を改善する。応答クラスタの１つまたは複数、または全てに対してサンプリングを行なうことができる。応答クラスタを使用して、需要応答イベントに応答するように送信グループを生成する。各送信グループは、異なる応答クラスタおよび異なる利用クラスタからのプレミスを含むことができる。送信グループのサイズは、ユーティリティに対する関連基準に基づいて、例えば許容変動に基づいて、ユーティリティによって判断することができる。送信グループは、減少プラスまたはマイナスある程度の許容マージン、すなわち許容変動の適度に正確な評価を可能にするサイズであるべきである。許容変動は、費用、顧客などのユーティリティに関連するいくつかの要因に基づくことができる。送信グループは、同じまたは異なるサイズであってもよい。送信グループはその後、需要応答イベント要求に応答するように展開される。

送信グループが需要応答イベント要求に応答した後に、応答クラスタ、および応答クラスタの応答を推定するために使用される応答推定関数を更新するために、応答が判断される。送信グループ内のプレミスを有する応答クラスタの実際の応答を、様々な方法を使用して判断することができる。例示的な方法は、基準方法として知られている。各プレミスでは、最終日、例えば最後の３日間からのデータを使用して、需要応答イベントの時間中の応答グループ内の各プレミスに対して負荷消費がどうなるかの結論を出す。例えば、各プレミスに対する最後の３日間に対するデータの平均を負荷消費として使用することができる。その後、応答クラスタ内のこれらのプレミスの実際の応答を測定し、各応答クラスタの実際の応答を判断するために差を使用する。

他の実施形態では、需要応答イベントに対する応答クラスタの実際の応答を判断する際の誤差を少なくするために、制御グループを使用することができる。より詳細に、需要応答イベントに参加していないプレミスは、関連する利用クラスタに送信された応答クラスタの応答を判断するために、各利用クラスタ内の制御グループとして使用することができる。制御グループの応答または挙動は、このグループでの各プレミスの応答を測定し、利用クラスタに対する基準または通常負荷に到達するようにこれらの値を平均化することによって判断される。各応答クラスタ内の送信／参加顧客の応答は、応答クラスタ内の各参加プレミスの実際の負荷を測定し、送信された各応答クラスタに対する応答負荷に到達するようにこれらの値を平均化することによって判断される。利用クラスタ内の各応答クラスタの実際の使用が、制御グループまたはクラスタの実際の使用と比較されて、対応する応答クラスタに対する応答を判断する。これは、送信グループ内に送信されたプレミスを有する応答クラスタの全てに対して行なわれる。これらの応答クラスタそれぞれに対する応答クラスタ情報が、その後に更新される。この場合、応答クラスタは単一のプレミスであってもよい。その結果、各プレミスが需要応答イベント要求に応じて負荷をどれだけ減少させたかを測定および検証する。

図６は、本発明の実施形態による、需要応答イベント要求を処理するフロー図を示している。プロセス６００はステップ６０２を含んでおり、ＤＲモジュール１２８は、顧客プレミス１０４、ユーティリティ１０８からの情報、およびデータベース１３４および１３６内に記憶された情報を受信する。ステップ６０４では、ＤＲモジュール１２８は、グループを特定する、またはプレミスをクラスタに集合させるためにこの情報を利用する。前に記したように、例えばユーティリティによって選択する、または自動的に選択することができるあらゆる適切な基準に基づいて、クラスタを形成することができる。いくつかの非限定的な例としては、利用クラスタ、ＤＲイベント応答クラスタ、地理クラスタ、ＤＲプログラムクラスタなどが挙げられる。クラスタ化のための情報としては、非限定的な例として、例えば契約状態、サイトでの負荷のタイプ、負荷利用、利用の時間および持続時間、および地理情報を挙げることができる。利用クラスタの数およびサイズは変わることができ、例えば、アプリケーションおよび所望のパフォーマンスに基づくことができる。ステップ６０６では、応答推定関数が、ステップ６０４で判断される各クラスタに対して展開される。応答推定関数は、これに限らないが、例えば経験法、回帰技術、ベイズ法、およびニューラルネットワーク、遺伝的アルゴリズム、ＳＶＭなどを含む人工知能を含むあらゆる適切な関数であってもよい。本明細書に記載された例示的な例では、応答推定関数および推定プロセスで経験法が使用されている。ステップ６０８では、需要応答イベント要求はクラスタに基づいて処理される。クラスタは、ステップ６１０で必要に応じて更新される。

図７は、図６に示す処理ステップ６０８に対するフロー図を示している。ステップ７０２では、需要応答イベント要求および関連ＤＲプログラムが特定される。ステップ７０４では、関連データはプレミス１０４、ユーティリティ１０８、およびデータベース１３４および１３６に記憶された情報から収集される。ステップ７０６では、応答推定関数は各クラスタに対して展開される。応答推定関数は、これに限らないが、例えば経験法、回帰技術、ベイズ法、およびニューラルネットワーク、遺伝的アルゴリズム、ＳＶＭなどを含む人工知能を含むあらゆる適切な関数であってもよい。ステップ７０８では、クラスタの１つまたは複数からのプレミスは、送信グループに割り当てられる。送信グループは、特定の需要応答イベントに応答するために展開することができるプレミスを示している。送信グループ内のプレミスは、異なるクラスタ、および多数のクラスタからの異なるプレミスに属することができる。例えば、送信グループ内のプレミスは、このグループを展開させることが最も効率的であるように、ユーティリティ分配ネットワークの特定のノードまたはセグメントに配置することができる。あらゆる適切な方法を使用して、送信グループを形成することができる。送信グループのサイズは、変動を最小限に抑えるために選択することができ、より大きな送信グループはより小さい変動を示す。ステップ７１０では、各送信グループの応答は、応答推定関数を使用して推定される。いくつかの実施形態では、推定は、送信グループ内の需要応答イベントに応答する各クラスタに対していくつかのメータをサンプリングすることを含んでいる。サンプリングにより、関連クラスタに予測通常負荷に対するリアルタイムに近い顧客挙動を与える。サンプリングにより、推定の予測誤差が最小限に抑えられる。ステップ７１２では、１つまたは複数の送信グループは、需要応答イベント要求を処理するために必要な応答量によって、需要応答イベント要求に応答するように展開される。需要応答イベント要求に対する応答は、ネットワークから利用可能なイベントデータから判断される。ステップ７１４は、送信グループ内で展開される各クラスタの応答が判断される。前に論じたように、制御グループを使用して、クラスタの応答をより正確に判断することができる。応答推定関数はその後、ステップ７１６で更新される。

図８は、別の実施形態による、需要応答イベント要求を処理するフロー図を示している。プロセス８００はステップ８０２を含んでおり、ＤＲモジュール１２８は、顧客プレミス１０４、ユーティリティ１０８からの情報、およびデータベース１３４および１３６に記憶された情報を受信する。ステップ８０４では、ＤＲモジュール１２８は、グループを特定する、またはプレミスを利用クラスタに集合させるためにこの情報を利用する。利用クラスタに対する基準としては、非限定的な例として、例えば契約状態、サイトでの負荷のタイプ、負荷利用、利用の時間および持続時間、および地理情報を挙げることができる。利用クラスタの数およびサイズは変わることができ、例えば、アプリケーションおよび所望のパフォーマンスに基づくことができる。加えて、ステップ８０６では、各利用クラスタに対して、ＤＲモジュール１２８は、前に論じたように、需要応答イベント要求に応じて、類似性に基づき利用クラスを応答クラスタに分割する。例えば、利用クラスタ内のいくつかのプレミスは、需要応答プログラム要求の少なくともいくつかに対する高速応答を示すことができ、その他は低速応答を示すことができ、さらにその他はあらゆる需要応答またはインセンティブベースプログラムに参加していないので、全く応答しない可能性がある。高速応答でのプレミスは共に、応答クラスタにクラスタ化することができる、低い応答プレミスおよび応答がないプレミスに対しても当てはまる。いくつかの実施形態では、応答クラスタは、様々な需要応答プログラムそれぞれに対して生成することができる。他の実施形態では、応答クラスタは、様々な需要応答プログラムそれぞれに対して同じであってもよい。ステップ８０８では、応答推定関数は、各利用および応答クラスタに展開される。ステップ８１０では、需要応答イベント要求は、利用および応答クラスタに基づいて処理される。利用クラスタおよび／または応答クラスタは、ステップ８１２で必要に応じて更新される。

図９は、図８に示す需要応答イベント要求８１０の処理をより詳細に示すフロー図である。ステップ９０２では、処理用の需要応答プログラムが特定される。ステップ９０４では、関連データおよび顧客データが集められる。これは、これに限らないが、例えば履歴利用データ、リアルタイムメータデータ、天候データ、機器データ、需要ビッド、ネットワーク状態、およびサイトエネルギー管理システムデータが挙げられる。ステップ９０６では、応答推定関数は、ステップ８０４、８０６で判断される各利用／応答クラスタに対して展開される。これが新しい需要応答プログラムであり、履歴データがない場合、いくつかの実施形態では、応答クラスタは利用クラスタと同じであり、他の実施形態では、シードデータ、シミュレーションデータまたは他の初期データを使用して、前に記載したように利用クラスタを応答クラスタに分割することができる。応答推定関数は、これに限らないが、例えば経験法、回帰技術、ベイズ法、およびニューラルネットワーク、遺伝的アルゴリズム、ＳＶＭなどを含む人工知能を含むあらゆる適切な関数であってもよい。本明細書に記載された例示的な例では、応答推定関数および推定プロセスで経験法が使用されている。

ステップ９０８では、応答クラスタの１つまたは複数からの（または、応答クラスタが利用クラスタである場合、利用クラスタの１つまたは複数からの）プレミスが、送信グループに割り当てられる。送信グループは、特定の需要応答イベント要求に応答するために展開することができるプレミスを示している。送信グループ内のプレミスは、異なる応答および利用クラスタに属することができ、異なる利用クラスタからの多数の応答クラスタからのプレミスも、送信グループの一部となることができる。例えば、送信グループ内のプレミスは、このグループを展開させることが最も効率的であるように、ユーティリティ分配ネットワークの特定のノードまたはセグメントに配置することができる。あらゆる適切な方法を使用して、送信グループを形成することができる。送信グループのサイズは、変動を最小限に抑えるために選択することができ、より大きな送信グループはより小さい変動を示す。

ステップ９１０では、各送信グループの応答は、応答推定関数を使用して推定される。いくつかの実施形態では、推定は、送信グループ内の需要応答イベントに応答する各応答クラスタに対していくつかのメータをサンプリングすることを含んでいる。サンプリングにより、関連応答クラスタに予測通常負荷に対するリアルタイムに近い顧客挙動を与える。サンプリングにより、推定の予測誤差が最小限に抑えられる。ステップ９１２では、１つまたは複数の送信グループは、需要応答イベント要求を処理するために必要な応答量によって、需要応答イベント要求に応答するように展開される。需要応答イベント要求に対する応答は、ネットワークから利用可能なイベントデータから判断される。ステップ９１４は、送信グループ内で展開される各クラスタの応答が判断される。前に論じたように、制御グループを使用して、応答クラスタの応答をより正確に判断することができる。応答推定関数はその後、ステップ９１６で更新される。

本明細書に記載するように、本発明のシステムおよび方法により、ユーティリティが、パフォーマンスおよび／またはシステム要件によって、様々な所望の基準に基づいてプレミスをクラスタ化することによって、需要応答イベントに応答するのに必要なプレミスの数を正確に評価または推定することが可能になる。例えば、クラスタを、イベント応答挙動、利用挙動、地理データ、利用データの時間などに基づいて展開させることができる。需要応答要求はその後、各クラスタに対して展開される応答推定関数を使用して、クラスタレベルで処理することができる。

いくつかの実施形態では、プレミスは利用クラスタにクラスタ化され、各利用クラスタは応答クラスタに分割される。応答クラスタは、新しい需要応答プログラムが導入された場合など、プレミスに対する履歴データが利用可能でない場合に、利用クラスタと同じであってもよい。他の実施形態では、他のユーティリティからのシードデータ、シミュレーションデータまたはプレミスプロファイルデータ、または他の初期データを使用して、利用クラスタを応答クラスタに最初に分割することができる。応答推定はその後、同様の利用および応答挙動を示すプレミスのクラスタ上で行なわれ、その結果、より正確な応答推定につながる。応答推定はより正確であるので、ユーティリティは、需要応答イベントに応答するためにどのプレミスまたはリソースを利用するべきかをより正確に判断することができる。

本発明の実施形態を、単一の需要応答プログラムの処理に関して説明したが、本発明はこれに関して限定されるものではない。本発明の実施形態によるクラスタ化は、多数のプログラムで行なうことができる。

本発明の特定の特性のみを本明細書で例示および記載したが、当業者は多くの修正形態および変更形態を思い付くだろう。したがって、添付の特許請求の範囲は、このような修正形態および変更形態全てを本発明の真の精神内にあるものとして含んでいることを意図していることを理解されたい。

１００ エネルギー管理システム
１０２ エネルギー管理サーバ
１０４ 顧客プレミス
１０６ ワイドエリアネットワーク
１０８ ユーティリティ
１１０ エネルギーマネージャ
１１２ プロセッサ
１１４ メモリ
１１６ ユーザインターフェイス
１１８ 負荷
１２０ センサ
１２２ 再生可能エネルギー
１２４ 記憶装置
１２６ ＰＥＶ／ＰＨＥＶ
１２７ イベント送信モジュール
１２８ 需要応答モジュール
１２９ 集合／分解モジュール
１３０ ネットワーク管理サービスモジュール
１３１ 推定モジュール
１３２ ユーザインターフェイスモジュール
１３３ 管理および検証モジュール
１３４ 顧客データベース
１３６ プログラムデータベース
２００ ユーティリティ制御センタ
２０２ エネルギー管理システムモジュール
２０４ 監視制御およびデータ取得モジュール
２０６ 供給停止管理システムモジュール
２０８ 地理情報システムモジュール
２１０ 分配管理システムモジュール
２１２ 顧客情報システムモジュール
２１４ 直接負荷制御モジュール
２１６ 課金モジュール

Claims (10)

1. 各プレミスに対するプレミス情報に基づいて、ユーティリティプレミスのネットワーク内の前記プレミスをクラスタに集合させるステップと、
   各前記クラスタに対する応答推定関数を展開させるステップと、
   各前記クラスタに対する前記応答推定関数に基づいた前記クラスタの使用に基づいて、需要応答イベント要求を処理するステップとを含む方法。
2. 前記応答推定関数が、経験モデル、回帰技術、ベイズ技術、および人工知能の少なくとも１つから展開される、請求項１記載の方法。
3. 前記応答推定関数を更新するステップと、
   前記クラスタを周期的に更新するステップとをさらに含む、請求項１記載の方法。
4. 前記需要応答イベント要求を処理するステップが、
   前記応答推定関数を使用して、前記需要応答イベント要求に対する各前記クラスタの応答を推定するステップと、
   各前記クラスタの前記応答に基づいて、前記クラスタの１つまたは複数からの前記プレミスを送信グループに割り当てるステップと、
   前記需要応答イベント要求に応答するために前記送信グループを送信するステップとを含む、請求項１記載の方法。
5. 前記需要応答イベント要求に応答するために使用される各前記クラスタ内の前記プレミスのイベント応答を判断するステップと、
   前記イベント応答に基づいて、前記需要応答イベント要求を処理するために使用される各前記クラスタに対する前記応答推定関数を更新するステップとをさらに含む、請求項４記載の方法。
6. 前記応答を推定するステップが、
   サブセット内の各前記プレミスに対するほぼリアルタイムの利用情報を判断するために、各前記クラスタ内の前記プレミスの前記サブセットをサンプリングするステップと、
   前記対応するクラスタ全体に各前記クラスタ内の前記サブセットの前記ほぼリアルタイムの利用情報を割り当てるステップとを含む、請求項４記載の方法。
7. 前記需要応答イベント要求に応答するために使用される各前記クラスタ内の前記プレミスの前記イベント応答を判断するステップが、
   前記需要応答イベントに応答した各前記クラスタ内の各前記プレミスの前記イベント応答を、前記需要応答プログラムに参加していない前記クラスタ内のプレミスと比較するステップと、
   比較結果に基づいて、各前記クラスタ内の前記プレミスの前記イベント応答を判断するステップとを含む、請求項５記載の方法。
8. プレミスをクラスタに集合させるステップが、
   各前記プレミスに対するイベント応答情報に基づいて、前記プレミスを応答クラスタに集合させるステップを含み、
   各前記プレミスに対する前記プレミス情報が、前記イベント応答情報を含む、請求項１記載の方法。
9. プレミスをクラスタに集合させるステップが、
   各前記プレミスに対する前記プレミス情報に基づいて、前記プレミスを利用クラスタに集合させるステップと含む、請求項１記載の方法。
10. 各前記プレミスに対するイベント応答情報に基づいて、各前記利用クラスタ内の前記プレミスを応答クラスタに分割するステップと、
    各前記応答クラスタに対する応答推定関数を展開させるステップとをさらに含み、
    各前記プレミスに対する前記プレミス情報が、前記イベント応答情報を含む、請求項９記載の方法。

Images