"各プレミスに対するプレミス情報に基づいて、ユーティリティプレミスのネットワーク内の前記プレミスをクラスタに集合させるステップと、各前記クラスタに対する応答推定関数を展開させるステップと、各前記クラスタに対する前記応答推定関数に基づいた前記クラスタの使用に基づいて、需要応答イベント要求を処理するステップとを含む方法。前記応答推定関数が、経験モデル、回帰技術、ベイズ技術、および人工知能の少なくとも1つから展開される、請求項1記載の方法。前記応答推定関数を更新するステップと、前記クラスタを周期的に更新するステップとをさらに含む、請求項1記載の方法。前記需要応答イベント要求を処理するステップが、前記応答推定関数を使用して、前記需要応答イベント要求に対する各前記クラスタの応答を推定するステップと、各前記クラスタの前記応答に基づいて、前記クラスタの1つまたは複数からの前記プレミスを送信グループに割り当てるステップと、前記需要応答イベント要求に応答するために前記送信グループを送信するステップとを含む、請求項1記載の方法。前記需要応答イベント要求に応答するために使用される各前記クラスタ内の前記プレミスのイベント応答を判断するステップと、前記イベント応答に基づいて、前記需要応答イベント要求を処理するために使用される各前記クラスタに対する前記応答推定関数を更新するステップとをさらに含む、請求項4記載の方法。前記応答を推定するステップが、サブセット内の各前記プレミスに対するほぼリアルタイムの利用情報を判断するために、各前記クラスタ内の前記プレミスの前記サブセットをサンプリングするステップと、前記対応するクラスタ全体に各前記クラスタ内の前記サブセットの前記ほぼリアルタイムの利用情報を割り当てるステップとを含む、請求項4記載の方法。前記需要応答イベント要求に応答するために使用される各前記クラスタ内の前記プレミスの前記イベント応答を判断するステップが、前記需要応答イベントに応答した各前記クラスタ内の各前記プレミスの前記イベント応答を、前記需要応答プログラムに参加していない前記クラスタ内のプレミスと比較するステップと、比較結果に基づいて、各前記クラスタ内の前記プレミスの前記イベント応答を判断するステップとを含む、請求項5記載の方法。プレミスをクラスタに集合させるステップが、各前記プレミスに対するイベント応答情報に基づいて、前記プレミスを応答クラスタに集合させるステップを含み、各前記プレミスに対する前記プレミス情報が、前記イベント応答情報を含む、請求項1記載の方法。プレミスをクラスタに集合させるステップが、各前記プレミスに対する前記プレミス情報に基づいて、前記プレミスを利用クラスタに集合させるステップと含む、請求項1記載の方法。各前記プレミスに対するイベント応答情報に基づいて、各前記利用クラスタ内の前記プレミスを応答クラスタに分割するステップと、各前記応答クラスタに対する応答推定関数を展開させるステップとをさらに含み、各前記プレミスに対する前記プレミス情報が、前記イベント応答情報を含む、請求項9記載の方法。上記図面は代替実施形態を記載しているが、説明において記されているように、本発明の他の実施形態も考えられる。全ての場合において、本開示は、本発明の図示された実施形態を、限定としてではなく代表として示している。当業者は、多くの他の修正形態および実施形態を考え出すことができ、これらは本発明の原理の範囲および精神に含まれるものである。本明細書に記載された実施形態は、ユーティリティが特定の期間中の需要応答または減少イベントの使用を最適化することを可能にするエネルギー管理システムおよび方法を対象としている。本発明の実施形態が、エネルギーまたは電気ユーティリティおよび送電線網作業の内容で記載されているが、当業者は、他の目的およびユーティリティにもこのシステムおよび方法を使用することができることが分かるだろう。本明細書で使用されているように、モジュールという用語は、ソフトウェア、ハードウェアまたはファームウェア、またはこれらのあらゆる組合せ、または本明細書に記載したプロセスを行なうまたは容易にするあらゆるシステム、プロセスまたは機能のことを言う。重要ピーク価格設定CPP、可変ピーク価格設定VPP、直接負荷制御DLC、および他の様々なインセンティブプログラムなどの需要応答プログラムは、いつ、どれだけの頻度で、およびどれだけの持続時間でユーティリティが参加プレミスに対する需要応答イベントを指定することができるかに関する、契約上の仕様を有する需要応答プログラムの例である。DRプログラムによる利点を最大限にするために、参加プレミスのサブセットに対する負荷の減少および反発を正確に推定することができる必要がある。正確な推定により、すなわち、特殊な負荷減少を達成するのに必要なプレミスの数を要求することのみによってユーティリティが利用可能なDR利点をより効率的に利用することが可能になり、また、反発影響プレまたはポストイベント期間にシフトされる負荷が、DR計画および発信プロセスにおいて説明されることが保証される。また、正確な推定により、ユーティリティまたは、集積業者、小売業者、または他の負荷サービス主体などの他の主体が、DR能力を卸売電力市場により積極的に提供することが可能になる。例えば、契約では、ユーティリティは毎年最大15イベントまで呼び出すことができ、各イベントは毎年最大合計60時間で、午後12時から午後6時の時間の間に起こることを規定することができる。本発明の実施形態によると、ユーティリティは、各プレミスに対して6時間ごとに10イベント、または4時間ごとに15イベント、または15イベント、60時間の制限内に収まるようなイベントおよび時間のあらゆる他のそうした組み合わせを使用することを選択することができる。この例では、ユーティリティは、需要応答プログラムに参加している100,000の顧客を有すると仮定する。加えて、ユーティリティは、参加顧客のサブセットを各イベントに含めるように指定することができる。ユーティリティが、DRイベントを呼び出すかどうか、およびどれだけのプレミスを含めるかを評価する場合、重要な要素は、DRイベントに参加するために選択されている場合に、プレミスの各セットが与える応答負荷変化を理解することである。毎年限られた数のイベントしかなく、より短い時間尺度数時間以下における負荷の変化の度合が高いので、DRイベントへの個別のプレミス応答の正確な推定を行なうことが極めて難しい。同様のプレミス挙動のグループ化に基づいて展開されたクラスタを利用することによって、サンプルサイズを大きくし、より正確な応答推定アルゴリズムを生成することが可能である。システムおよび方法の実施形態は、いくつかの基準に基づいて、ユーティリティプレミスをクラスタに集合させることによって作用する。非限定的な例として、プレミスは利用または消費特徴に基づいてクラスタ化することができ、同様の利用特徴を示すプレミスは、各プレミスに対する利用プロファイルに基づいて利用クラスタにクラスタ化される。利用プロファイルは、契約タイプ、プレミスサイトでの機器/負荷のタイプ、典型的な負荷利用または消費、使用回数、使用持続時間、地理的位置などに基づく可能性がある。他の非限定的および例示的な実施形態では、プレミスをイベント応答基準に基づいてクラスタ化することができ、同様のイベント応答挙動を示す顧客は、応答クラスタにクラスタ化される。プレミスのクラスタ化は、ユーティリティのパフォーマンス目標を達成するためのあらゆる適切な基準に基づくことができる。クラスタサイズは、システムのプレミス情報、アプリケーションおよび所望のパフォーマンスに左右される。加えて、様々なレベルのクラスタ化を使用して、応答推定の精度をさらに良くすることができる。利用に基づきプレミスをクラスタ化する非限定的な例をさらに詳しく説明すると、各利用クラスタをその後、需要応答イベントに対する同様の応答プロファイルに基づいて、需要応答または応答クラスタに分割することができる。例えば、利用クラスタ内のいくつかのプレミスは、任意の需要応答またはインセンティブプログラムに参加していない可能性がある。各利用クラスタ内のこれらのプレミスは、応答クラスタに集合させることができる。利用クラスタ内の一部のプレミスは、需要応答イベントに対する高速応答を有することができ、その他は需要応答イベントに対する低速応答を有することができる。需要応答イベントに対するプレミス応答は、かなり変化する。システムおよび方法の実施形態によると、需要応答イベントに対する同様の応答プロファイルを有するプレミスは共に、応答クラスタにグループ化することができる。利用クラスタサイズおよび応答クラスタサイズは、プレミス情報、アプリケーション、所望のパフォーマンスに左右され、ユーティリティまたはサービスプロバイダによって設定することができる。この非限定的例でプレミスを利用クラスタおよび応答クラスタにクラスタ化することによって、ユーティリティは、需要応答イベントに対する応答例えば、負荷と持続時間の減少を正確に評価または推定することができ、したがって、需要応答イベント要求に対する応答を最適化することができる。応答クラスタの応答が推定されると、需要応答イベントに応答するために選択された応答クラスタ内のプレミスは、送信グループにグループ化される。送信グループはその後、需要応答イベントに応答するために展開される。このような正確な推定により、ユーティリティがイベント毎のプレミスのサブセットを使用することが可能になるだけでなく、所要のシェッドおよびシェッドに対する正確に推定された応答に基づいて展開するようにプレミスの選択を最適化することができる。本発明の一実施形態による例示的なエネルギー管理システムが、図1に示されている。システム100は、エネルギー管理サーバ102、プレミスサイト104、およびユーティリティ108を含んでいる。本発明の実施形態の説明を容易にするために、単一のサーバ102および単一のユーティリティソース108が図1に示されている。しかし、本発明の実施形態はこれらの数に限定されるものではなく、ユーティリティネットワーク内にあらゆる数のエネルギー管理サーバ、プレミスサイト、サービスプロバイダ、および制御センタがある可能性があることを理解されたい。加えて、エネルギー管理サーバ102は、ユーティリティ108によって、および/またはあらゆる他のものによって配置および/またはホスティングすることができる。各プレミスサイト104は、プロセッサ112、メモリ114、およびユーザインターフェイス116を有するエネルギーマネージャ110を含んでいる。ユーザインターフェイス116は、例えば、ディスプレイと共にキーボードまたはタッチ画面を含むことができる。プロセッサ112は、負荷118、センサ120、再生可能エネルギー122、記憶装置124、およびプラグイン電気自動車PEVまたはプラグインハイブリッド電気自動車PHEV126などの様々なプレミスデバイスの動作を監視および制御するプログラムを実行する。センサ120は、メータ、サーモスタット、占有センサ、湿度計、およびこのような他のデバイスを備えている。再生可能エネルギーリソース122は、例えば太陽光および/または風力デバイスを含むことができる。プロセッサ112は、例えばZigbee、Zウェーブ、WiFiまたはホームプラグを含むいくつかのインターフェイスまたはプロトコルのいずれかを使用して、様々な構成部品を制御する。プレミスサイト104、サーバ102、およびユーティリティ108の間の通信は、例えば、WAN例えば、インターネット106、WiMAX、ブロードバンド、AMI、および/または電力線搬送を介して起こる。通信は、プライベートネットワークを介して起こることができる。あらゆる適切な通信手段を使用することができる。エネルギー管理サーバ102は、需要応答DRモジュール128、ネットワーク管理サービスNMSモジュール130、ユーザインターフェイスモジュール132、顧客データベースDB134、およびプログラムデータベースDB136を備えている。NMSモジュール130は、DRモジュール128、プレミス104、およびユーティリティ108に通信管理およびプロビジョニングを行なう。顧客データベース134は、ネットワーク内の顧客用プレミスプロファイルを記憶する。各プレミスプロファイルは、例えば、ネットワーク内の各プレミスに対する履歴データ、およびあらゆる需要応答プログラム内への参加に関する情報などのデータを含んでいる。履歴データは、例えば負荷タイプ、使用時間TOU、使用の持続時間、シェッドまたは需要応答イベントに関する情報を含むことができる。データベース134内に記憶されたプレミス利用情報は、24時間にわたる時間単位負荷および時間単位価格を含む負荷データ、天候情報例えば、温度、湿度、風速、加熱および冷却度などを含む環境データ、および曜日、季節などの日時情報で周期的に例えば、毎時間、毎日更新することができる。加えて、データベース134は、各プレミスに対するイベントデータを記憶する。より詳細には、データベース134は、プレミスが需要応答イベントに参加したかどうか、開始時間および終了時間、曜日、季節などに関する履歴情報を記憶する。加えて、負荷減少および反発の量は、データベース134内に記憶される。応答予測および予期将来利点計算に関するデータはまた、データベース134内に記憶することができる。プログラムデータベース136は、エネルギー管理サーバ102によって実施される様々なアプリケーションおよびプログラムを記憶する。ユーザインターフェイスモジュール132は、オペレータによる情報の交換を可能にする。本発明の一実施形態では、エネルギー管理サーバ102は、図2に示すように、1つまたは複数のユーティリティ制御センタ200に物理的および/または論理的に配置することができる。加えて、ユーティリティ制御センタ200は、ネットワークに対する負荷予測を実行し、生成および伝達システムのパフォーマンスを監視、制御および最適化する、エネルギー管理システムEMSモジュール202を備えることができる。監視制御およびデータ取得SCADAモジュール204は、グリッド内の異なる点でリアルタイム情報を与え、またローカル制御を行なう。供給停止管理システムOMSモジュール206は、ネットワーク内の顧客サイト104に対する負荷状態情報および供給停止回復情報を監視する。OMSモジュール206によって行なわれる機能のいくつかは、故障予測を含んでおり、供給停止および消費者への影響の範囲に関する情報を顧客に提供し、回復努力を優先させる。OMSモジュール206は、地理情報システムGISモジュール208によって生成および維持される分配システムの詳細ネットワークモデルに基づいて機能する。分配管理システムDMSモジュール210は、負荷状態および負荷応答に関する情報を提供することによって、悪いまたは不安定なネットワーク状態に対するリアルタイム応答を提供する。DMSモジュール210は、アラームおよび/またはイベントに対する応答を管理する。サービス契約情報、インセンティブおよび/または需要応答プログラムへの参加、および契約価格情報を含む顧客情報は、例えば、顧客情報システムCISモジュール212によって監視および制御される。直接負荷制御DLCモジュール214は、例えばサーモスタット-HVAC、温水器、プールポンプ、水洗機、乾燥機、食器洗い機、LCD/プラズマTV、プラグ負荷例えば、コンピュータ、コンピュータ周辺機器/付属品、ファックス機、電源装置、冷蔵庫、および照明器具などの顧客サイトデバイスを制御および管理する。オン/オフ、エコモード/通常モード、または多数の個別省電力モード例えば、減光照明を有する主に個別のタイプのデバイスがある。顧客課金は、課金モジュール216によって行なわれる。本発明の実施形態によると、DRモジュール128は、プレミス104、ユーティリティ108、ならびにデータベース134および136からの情報を利用して、例えば、需要応答イベントを呼び出すかどうか、関連する利用および/または応答クラスタにしたがった送信グループによる需要応答イベントへの応答の予測、どの顧客をイベントに含めるか、ならびにイベントの時間および持続時間を判断する。図3に示すように、DRモジュール128は、DRイベント要求に応答するためにプレミスの送信を行なうイベント送信モジュール127、送信グループへのプレミスの集合および分解を行なう集合/分解モジュール129を含んでいる。加えて、DRモジュール128はまた、各クラスタ内のプレミスの応答を推測するためにプレミス情報を利用する予測モジュール131を含んでいる。測定および検証モジュール133は、DRイベントへのプレミスの応答を測定および検証する。DRモジュール128の他の機能としては、例えば、偶発応答、および供給停止緩和が挙げられる。本発明の実施形態は、特定の基準によってプレミスをクラスタ化する。説明を容易にするために、非限定的例が利用クラスタに関して記載されている。本発明の実施形態は、ユーティリティが需要応答イベントに対する応答をより正確に推定することを可能にするために、利用挙動および応答挙動にしたがってプレミスをクラスタ化する。ネットワーク内のプレミスに対する応答挙動は、履歴データに基づいて展開される。需要応答プログラムが最初に開始された場合、または履歴データがない場合、応答クラスタは利用クラスタと同じである。十分な履歴応答が蓄積されると、またはシード、シミュレーション、またはいくつかの他のデータが履歴データとして使用される場合、利用クラスタは応答クラスタに分割される。プレミスが利用クラスタに集合され、その後、応答クラスタに分割されると、応答予測器が各利用および応答クラスタのために開発される。応答予測器はその後、対応する利用または応答クラスタ内の各プレミス用の需要応答イベント要求に対する応答を推定するために使用される。全てのプレミスが利用クラスタに最初に割り当てられるDRイベントに実際に参加するまで、応答データがないので、このような十分なデータが捕捉されて、応答クラスタの形成、および応答クラスタレベルでの推定の両方を行なうときまで、利用クラスタレベルで予測が行なわれる。応答推定アルゴリズムを開発する方法は、クラスタ化利用または応答の各レベルで適用することができる。応答クラスタ化は、各需要応答プログラムに対して行われる。同じクラスタ化を、特定の需要応答プログラムの各発生のために利用することができる。以下の例示的および非限定的な例では、クラスタ化を使用して需要応答イベントに対する需要応答を推定する際に使用される応答予測器を開発するための実証的方法が記載される。しかし、これに限らないが、回帰技術、ベイズ法、ならびにニューラルネットワーク、遺伝的アルゴリズム、およびサポートベクトル機SVMを含む人工知能を含む、様々な推定方法を使用することができる。本実施例では、各応答クラスタ内で、需要応答イベントが呼び出されない非参加負荷と、クラスタの各メンバに対してイベントが呼び出される参加負荷の間の差は、DRイベントに関連する期間にわたり、このクラスタに対する実際の負荷応答値を与える。これらの応答値は、クラスタに対する応答推定値を展開するために使用される。この推定値はその後、局所的に変わる天候またはメータ/デバイス状態などのリアルタイム情報に基づいて、推定値を調節する見込みで特定のクラスタ内の全てのプレミスに適用される。この概念は、図4に示されている。点線は、一日の基本または通常負荷を示している。破線は、需要応答イベント中の負荷を示している。需要応答ウィンドウ中の減少、および需要応答ウィンドウのすぐ周りのプレ反発およびポスト反発は、いくつかのエネルギー消費タスクを非需要応答期間まで移動させる典型的な顧客傾向を示していることに留意されたい。点―破線によって反映された、基本負荷と需要応答負荷の間の差は、プレミスのシェッド応答を示している。このような非限定的な例では、応答クラスタに対する通常の負荷は、履歴負荷データを見て、需要応答イベントが呼び出されない場合に現在の需要応答イベントを呼び出すための日と同様の日数すなわち、季節、曜日、時刻などから応答クラスタ内の各プレミスに対する負荷のいくつかの単純または加重平均をとり、応答クラスタに対する推定通常負荷に到達するようにこれらのプレミス値を平均化することによって予測される。同様に、需要応答負荷すなわち、仮に需要応答イベントが呼び出される場合の、応答クラスタの負荷を推定するために、需要応答イベントが実際に呼び出された同様の日数からの応答クラスタ内の各プレミスに対する負荷の同様の平均が判断され、これらのプレミス値は応答クラスタに対する推定需要応答負荷に到達するように平均化される。応答クラスタに対する推定または推測通常負荷と推定需要応答の間の差は、特定の応答クラスタに対する推定シェッド応答につながる。この例では、応答クラスタ全てに対して推定が行なわれる。しかし、あらゆる数の応答クラスタを使用することができる。使用する同様の日数は、ユーティリティによって判断することができる、または所望のパフォーマンスに対して自動的に判断することができる。ユーティリティでの1つまたは複数の需要応答またはインセンティブプログラムの実施の始めに、需要応答負荷を推定するための履歴データがない。様々な方法を使用して、プログラムが定位置になり、これに限らないが、同様の地理領域内の同様の層の役割を果たす他のユーティリティからの使用シード値、シミュレーションデータ、またはプロファイルデータを含む履歴データが生成されるまで、必要なデータを提供することができる。需要応答イベントが呼び出されると、プレミスに対する実際のデータは、履歴に収集され、最終的に、他のユーティリティから使用される初期プロファイルデータ、または初期に使用することができるあらゆるシードまたはシュミレーションデータを置換する。この非限定的な例では、上に記載したように、人口を応答クラスタに分割するのに十分なデータが存在するまで、推定が利用クラスタレベルで行なわれる。イベント日の間に参加と非参加プレミス負荷を比べることによって、DRイベント日での各プレミスの実際の応答を測定するために、利用クラスタがさらに使用される。例示的な例が図5に示されている。この非限定的な例では、他のユーティリティからのシェッド応答プロファイルを、ステップ502で示すように、いくつかの顧客タイプに対して生成することができる。ステップ504および506に示すように、目標ユーティリティで需要応答プログラムに参加する各プレミスは、適当なプロファイルにマッピングすることができ、そのプロファイルに対するシェッド応答を使用して初期応答を推定することができる。ステップ508では、需要応答イベントが呼び出されると、これに限らないが、温度、曜日、時刻、月、季節などの需要応答イベント日の特徴が特定される。ステップ510では、イベント内の顧客プレミスに対する履歴通常負荷データおよび需要応答データがあるかどうか判断される。答えがいいえである場合、その後、処理はステップ512に進み、ステップ506で記憶されたシェッド応答がステップ516で使用されて、需要応答イベントを処理する。答えがはいである場合、その後、通常負荷および需要応答負荷が推定され、ステップ514では同様の日に対して推定される。需要応答イベントに応答する顧客サイトまたはプレミスの実際の応答は、ステップ518および520に記憶される。いくつかの実施形態では、推定を改善し、予測の誤差を最小限に抑えるためにサンプリングが使用される。より詳細には、応答クラスタ内のいくつかのプレミスがリアルタイムサンプリングに使用される。非限定的な例として、リアルタイムに近いデータに対してメータをサンプリングすることができる。需要応答イベント要求が受信された場合に、推定パラメータがリアルタイムに近いデータで更新されるように、サンプリングを周期的に行なうことができる。サンプリングするメータの数は、ユーティリティによって、自動的に、またはいくつかの他の方法によって判断することができる。十分なメータデータが興味のある各クラスタ利用または応答で得られることを保証するために、サンプリング計画が作成される。これらのプレミスのメータは、クラスタ用の通常の負荷に対してリアルタイムに近いデータを得るためにサンプリングされる。応答推定値または推定シェッド応答はその後、予測される通常負荷に対するこのようなリアルタイムに近いデータに基づいて更新される。非限定的な例として、サンプリングされたメータ読み込みの平均は予測通常負荷として使用することができる。このようなサンプリングは、予測誤差を最小限に抑え、したがって、応答クラスタの推定シェッド応答を改善する。応答クラスタの1つまたは複数、または全てに対してサンプリングを行なうことができる。応答クラスタを使用して、需要応答イベントに応答するように送信グループを生成する。各送信グループは、異なる応答クラスタおよび異なる利用クラスタからのプレミスを含むことができる。送信グループのサイズは、ユーティリティに対する関連基準に基づいて、例えば許容変動に基づいて、ユーティリティによって判断することができる。送信グループは、減少プラスまたはマイナスある程度の許容マージン、すなわち許容変動の適度に正確な評価を可能にするサイズであるべきである。許容変動は、費用、顧客などのユーティリティに関連するいくつかの要因に基づくことができる。送信グループは、同じまたは異なるサイズであってもよい。送信グループはその後、需要応答イベント要求に応答するように展開される。送信グループが需要応答イベント要求に応答した後に、応答クラスタ、および応答クラスタの応答を推定するために使用される応答推定関数を更新するために、応答が判断される。送信グループ内のプレミスを有する応答クラスタの実際の応答を、様々な方法を使用して判断することができる。例示的な方法は、基準方法として知られている。各プレミスでは、最終日、例えば最後の3日間からのデータを使用して、需要応答イベントの時間中の応答グループ内の各プレミスに対して負荷消費がどうなるかの結論を出す。例えば、各プレミスに対する最後の3日間に対するデータの平均を負荷消費として使用することができる。その後、応答クラスタ内のこれらのプレミスの実際の応答を測定し、各応答クラスタの実際の応答を判断するために差を使用する。他の実施形態では、需要応答イベントに対する応答クラスタの実際の応答を判断する際の誤差を少なくするために、制御グループを使用することができる。より詳細に、需要応答イベントに参加していないプレミスは、関連する利用クラスタに送信された応答クラスタの応答を判断するために、各利用クラスタ内の制御グループとして使用することができる。制御グループの応答または挙動は、このグループでの各プレミスの応答を測定し、利用クラスタに対する基準または通常負荷に到達するようにこれらの値を平均化することによって判断される。各応答クラスタ内の送信/参加顧客の応答は、応答クラスタ内の各参加プレミスの実際の負荷を測定し、送信された各応答クラスタに対する応答負荷に到達するようにこれらの値を平均化することによって判断される。利用クラスタ内の各応答クラスタの実際の使用が、制御グループまたはクラスタの実際の使用と比較されて、対応する応答クラスタに対する応答を判断する。これは、送信グループ内に送信されたプレミスを有する応答クラスタの全てに対して行なわれる。これらの応答クラスタそれぞれに対する応答クラスタ情報が、その後に更新される。この場合、応答クラスタは単一のプレミスであってもよい。その結果、各プレミスが需要応答イベント要求に応じて負荷をどれだけ減少させたかを測定および検証する。図6は、本発明の実施形態による、需要応答イベント要求を処理するフロー図を示している。プロセス600はステップ602を含んでおり、DRモジュール128は、顧客プレミス104、ユーティリティ108からの情報、およびデータベース134および136内に記憶された情報を受信する。ステップ604では、DRモジュール128は、グループを特定する、またはプレミスをクラスタに集合させるためにこの情報を利用する。前に記したように、例えばユーティリティによって選択する、または自動的に選択することができるあらゆる適切な基準に基づいて、クラスタを形成することができる。いくつかの非限定的な例としては、利用クラスタ、DRイベント応答クラスタ、地理クラスタ、DRプログラムクラスタなどが挙げられる。クラスタ化のための情報としては、非限定的な例として、例えば契約状態、サイトでの負荷のタイプ、負荷利用、利用の時間および持続時間、および地理情報を挙げることができる。利用クラスタの数およびサイズは変わることができ、例えば、アプリケーションおよび所望のパフォーマンスに基づくことができる。ステップ606では、応答推定関数が、ステップ604で判断される各クラスタに対して展開される。応答推定関数は、これに限らないが、例えば経験法、回帰技術、ベイズ法、およびニューラルネットワーク、遺伝的アルゴリズム、SVMなどを含む人工知能を含むあらゆる適切な関数であってもよい。本明細書に記載された例示的な例では、応答推定関数および推定プロセスで経験法が使用されている。ステップ608では、需要応答イベント要求はクラスタに基づいて処理される。クラスタは、ステップ610で必要に応じて更新される。図7は、図6に示す処理ステップ608に対するフロー図を示している。ステップ702では、需要応答イベント要求および関連DRプログラムが特定される。ステップ704では、関連データはプレミス104、ユーティリティ108、およびデータベース134および136に記憶された情報から収集される。ステップ706では、応答推定関数は各クラスタに対して展開される。応答推定関数は、これに限らないが、例えば経験法、回帰技術、ベイズ法、およびニューラルネットワーク、遺伝的アルゴリズム、SVMなどを含む人工知能を含むあらゆる適切な関数であってもよい。ステップ708では、クラスタの1つまたは複数からのプレミスは、送信グループに割り当てられる。送信グループは、特定の需要応答イベントに応答するために展開することができるプレミスを示している。送信グループ内のプレミスは、異なるクラスタ、および多数のクラスタからの異なるプレミスに属することができる。例えば、送信グループ内のプレミスは、このグループを展開させることが最も効率的であるように、ユーティリティ分配ネットワークの特定のノードまたはセグメントに配置することができる。あらゆる適切な方法を使用して、送信グループを形成することができる。送信グループのサイズは、変動を最小限に抑えるために選択することができ、より大きな送信グループはより小さい変動を示す。ステップ710では、各送信グループの応答は、応答推定関数を使用して推定される。いくつかの実施形態では、推定は、送信グループ内の需要応答イベントに応答する各クラスタに対していくつかのメータをサンプリングすることを含んでいる。サンプリングにより、関連クラスタに予測通常負荷に対するリアルタイムに近い顧客挙動を与える。サンプリングにより、推定の予測誤差が最小限に抑えられる。ステップ712では、1つまたは複数の送信グループは、需要応答イベント要求を処理するために必要な応答量によって、需要応答イベント要求に応答するように展開される。需要応答イベント要求に対する応答は、ネットワークから利用可能なイベントデータから判断される。ステップ714は、送信グループ内で展開される各クラスタの応答が判断される。前に論じたように、制御グループを使用して、クラスタの応答をより正確に判断することができる。応答推定関数はその後、ステップ716で更新される。図8は、別の実施形態による、需要応答イベント要求を処理するフロー図を示している。プロセス800はステップ802を含んでおり、DRモジュール128は、顧客プレミス104、ユーティリティ108からの情報、およびデータベース134および136に記憶された情報を受信する。ステップ804では、DRモジュール128は、グループを特定する、またはプレミスを利用クラスタに集合させるためにこの情報を利用する。利用クラスタに対する基準としては、非限定的な例として、例えば契約状態、サイトでの負荷のタイプ、負荷利用、利用の時間および持続時間、および地理情報を挙げることができる。利用クラスタの数およびサイズは変わることができ、例えば、アプリケーションおよび所望のパフォーマンスに基づくことができる。加えて、ステップ806では、各利用クラスタに対して、DRモジュール128は、前に論じたように、需要応答イベント要求に応じて、類似性に基づき利用クラスを応答クラスタに分割する。例えば、利用クラスタ内のいくつかのプレミスは、需要応答プログラム要求の少なくともいくつかに対する高速応答を示すことができ、その他は低速応答を示すことができ、さらにその他はあらゆる需要応答またはインセンティブベースプログラムに参加していないので、全く応答しない可能性がある。高速応答でのプレミスは共に、応答クラスタにクラスタ化することができる、低い応答プレミスおよび応答がないプレミスに対しても当てはまる。いくつかの実施形態では、応答クラスタは、様々な需要応答プログラムそれぞれに対して生成することができる。他の実施形態では、応答クラスタは、様々な需要応答プログラムそれぞれに対して同じであってもよい。ステップ808では、応答推定関数は、各利用および応答クラスタに展開される。ステップ810では、需要応答イベント要求は、利用および応答クラスタに基づいて処理される。利用クラスタおよび/または応答クラスタは、ステップ812で必要に応じて更新される。図9は、図8に示す需要応答イベント要求810の処理をより詳細に示すフロー図である。ステップ902では、処理用の需要応答プログラムが特定される。ステップ904では、関連データおよび顧客データが集められる。これは、これに限らないが、例えば履歴利用データ、リアルタイムメータデータ、天候データ、機器データ、需要ビッド、ネットワーク状態、およびサイトエネルギー管理システムデータが挙げられる。ステップ906では、応答推定関数は、ステップ804、806で判断される各利用/応答クラスタに対して展開される。これが新しい需要応答プログラムであり、履歴データがない場合、いくつかの実施形態では、応答クラスタは利用クラスタと同じであり、他の実施形態では、シードデータ、シミュレーションデータまたは他の初期データを使用して、前に記載したように利用クラスタを応答クラスタに分割することができる。応答推定関数は、これに限らないが、例えば経験法、回帰技術、ベイズ法、およびニューラルネットワーク、遺伝的アルゴリズム、SVMなどを含む人工知能を含むあらゆる適切な関数であってもよい。本明細書に記載された例示的な例では、応答推定関数および推定プロセスで経験法が使用されている。ステップ908では、応答クラスタの1つまたは複数からのまたは、応答クラスタが利用クラスタである場合、利用クラスタの1つまたは複数からのプレミスが、送信グループに割り当てられる。送信グループは、特定の需要応答イベント要求に応答するために展開することができるプレミスを示している。送信グループ内のプレミスは、異なる応答および利用クラスタに属することができ、異なる利用クラスタからの多数の応答クラスタからのプレミスも、送信グループの一部となることができる。例えば、送信グループ内のプレミスは、このグループを展開させることが最も効率的であるように、ユーティリティ分配ネットワークの特定のノードまたはセグメントに配置することができる。あらゆる適切な方法を使用して、送信グループを形成することができる。送信グループのサイズは、変動を最小限に抑えるために選択することができ、より大きな送信グループはより小さい変動を示す。ステップ910では、各送信グループの応答は、応答推定関数を使用して推定される。いくつかの実施形態では、推定は、送信グループ内の需要応答イベントに応答する各応答クラスタに対していくつかのメータをサンプリングすることを含んでいる。サンプリングにより、関連応答クラスタに予測通常負荷に対するリアルタイムに近い顧客挙動を与える。サンプリングにより、推定の予測誤差が最小限に抑えられる。ステップ912では、1つまたは複数の送信グループは、需要応答イベント要求を処理するために必要な応答量によって、需要応答イベント要求に応答するように展開される。需要応答イベント要求に対する応答は、ネットワークから利用可能なイベントデータから判断される。ステップ914は、送信グループ内で展開される各クラスタの応答が判断される。前に論じたように、制御グループを使用して、応答クラスタの応答をより正確に判断することができる。応答推定関数はその後、ステップ916で更新される。本明細書に記載するように、本発明のシステムおよび方法により、ユーティリティが、パフォーマンスおよび/またはシステム要件によって、様々な所望の基準に基づいてプレミスをクラスタ化することによって、需要応答イベントに応答するのに必要なプレミスの数を正確に評価または推定することが可能になる。例えば、クラスタを、イベント応答挙動、利用挙動、地理データ、利用データの時間などに基づいて展開させることができる。需要応答要求はその後、各クラスタに対して展開される応答推定関数を使用して、クラスタレベルで処理することができる。いくつかの実施形態では、プレミスは利用クラスタにクラスタ化され、各利用クラスタは応答クラスタに分割される。応答クラスタは、新しい需要応答プログラムが導入された場合など、プレミスに対する履歴データが利用可能でない場合に、利用クラスタと同じであってもよい。他の実施形態では、他のユーティリティからのシードデータ、シミュレーションデータまたはプレミスプロファイルデータ、または他の初期データを使用して、利用クラスタを応答クラスタに最初に分割することができる。応答推定はその後、同様の利用および応答挙動を示すプレミスのクラスタ上で行なわれ、その結果、より正確な応答推定につながる。応答推定はより正確であるので、ユーティリティは、需要応答イベントに応答するためにどのプレミスまたはリソースを利用するべきかをより正確に判断することができる。本発明の実施形態を、単一の需要応答プログラムの処理に関して説明したが、本発明はこれに関して限定されるものではない。本発明の実施形態によるクラスタ化は、多数のプログラムで行なうことができる。本発明の特定の特性のみを本明細書で例示および記載したが、当業者は多くの修正形態および変更形態を思い付くだろう。したがって、添付の特許請求の範囲は、このような修正形態および変更形態全てを本発明の真の精神内にあるものとして含んでいることを意図していることを理解されたい。"