JP2013520946A - ユーティリティグリッドコマンドフィルタシステム - Google Patents

Abstract

コマンドフィルタモジュールは、ユーティリティグリッド内の相互接続されたデバイスにより受信されるよう意図された複数のコマンドをフィルタリング、受信する。コマンドフィルタモジュールは、所定の一連のコマンドルールに基づき、複数のコマンドを個々のデバイスによる実行に関して許可するとよい。過去およびリアルタイムデータが、コマンドフィルタモジュールによって実装され、複数のコマンドに関して許可決定が実行されるとよい。許可されたコマンドは、個々のデバイスにより受信されるよう、コマンドフィルタモジュールによって伝送されるとよい。コマンドフィルタモジュールは、許可されないコマンドに対応する拒否メッセージを生成するとよい。拒否メッセージは、許可されないコマンドのソースへ伝送されるとよい。
【選択図】図１４

Description

１．発明の分野
本発明は、全般的に、電力グリッドを管理するシステムおよび方法に関し、特に、ユーティリティグリッド（ｕｔｉｌｉｔｙ ｇｒｉｄ）デバイスコマンドを、所定の基準に基づきフィルタリングするシステムに関する。

２．関連技術
電力グリッドは、発電、送電および配電のうちの１つまたはすべてを含み得る。電気は、石炭火力発電所、原子力発電所などの発電所を使用して生成され得る。生成された電力は、効率性のために、非常に高い電圧に昇圧されて（３４５Ｋボルトなど）送電線上で伝送される。送電線は、その卸売客に届くまで、州の境界を横断して、または国境を横断してなど、電力を長距離伝送することもあり、卸売客は、地域の配電ネットワークを所有する企業であることもある。送電線は、送電変電所で終わると考えられ、送電変電所が、非常に高い電圧を中間電圧（ｉｎｔｅｒｍｅｄｉａｔｅ ｖｏｌｔａｇｅ）（１３８Ｋボルトなど）に降圧することもある。送電変電所からは、より小さな送電線（副送電線など）が中間電圧を配電変電所へ伝送する。配電変電所において、中間電圧はさらに「中電圧（ｍｅｄｉｕｍ ｖｏｌｔａｇｅ）」（４Ｋボルト〜２３Ｋボルトなど）に降圧されることもある。１つ以上のフィーダ回路が、配電変電所から出ていることもある。例えば、４〜数十のフィーダ回路が、配電変電所から出ていることもある。フィーダ回路は、４つのワイヤを含む３相回路である（３相それぞれの３つのワイヤおよび中性の１つのワイヤ）。フィーダ回路は、地上（柱上）または地下のいずれかで配線され得る。フィーダ回路上の電圧は、配電変圧器を使用して定期的に取り出されることができ、配電変圧器が、「中電圧」から消費者電圧（２４０／１２０Ｖなど）に電圧を降圧する。その結果、消費者電圧が消費者により使用可能となる。

１つ以上の電力会社が、電力グリッドに関する故障、保守および改良の管理を含む、電力グリッドの管理を行うこともある。しかし、電力グリッドの管理は非効率的で高価であることが多い。例えば、地域の配電ネットワークを管理する電力会社は、フィーダ回路内、またはフィーダ回路から分岐するラテラル回路（ｌａｔｅｒａｌ ｃｉｒｃｕｉｔ）と呼ばれる回路上で生じ得る故障を管理することもある。地域の配電ネットワークの管理は、供給停止が生じたときの消費者からの電話に頼ること、または地域の配電ネットワークを分析する現場作業者に頼ることが多い。

電力会社は、「スマートグリッド」と呼ばれることもあるデジタル技術を使用して、電力グリッドの改良を試みてきた。例えば、よりインテリジェントな計器（「スマート計器」と呼ばれることもある）は、従来の計器よりも詳しく消費を特定する高度な計器の一種である。その結果スマート計器は、監視および請求のために、当該情報を何らかのネットワークを介して地域のユーティリティ（ｕｔｉｌｉｔｙ）へ伝達することができる（遠隔測定）。さらに、スマートグリッド内の他のデバイスは、リモート端末を介して制御され得る。デバイスがスマートグリッド内にあることで、住宅需要家の住居内の大型電化製品または工業需要家の大型工業設備などのデバイスの電子制御を、非常に確固とした基準でコマンドを介して行うことができるようになる。このような種類のコマンドそのものが、１つだけでスマートグリッドの全体的な正常性を脅かすことはないが、比較的短時間のうちにこうしたコマンドが多数実行されると、スマートグリッド内に悪影響を発生させかねない。

ユーティリティグリッド内でデバイスコマンドをフィルタリングする、コマンドフィルタシステムが提供される。コマンドフィルタシステムは、電力ユーティリティグリッドの管理を改善するために、スマートグリッドにおいて実装されるとよい。本開示のスマートグリッドは、現在の電気電力グリッドがより効率的かつ確実に動作し、消費者へのさらなるサービスをサポートできるように、電力ユーティリティグリッドの様々な部分においてセンサーを使用し、通信およびコンピューティング技術を使用して現在の電気電力グリッドを改良することを含む。本開示のスマートグリッドは、堅牢な双方向通信、高度なセンサーおよび分散型コンピュータ（送電および／または配電における追加のインテリジェンスを含む）を使用することなどによって、従来の送電・配電ネットワーク、すなわち「グリッド」を改良することができる。スマートグリッドはさらに、動作管理、故障検出および修正、リソース管理などのために、中央管理施設にさらなる機能性を含んでもよい。

スマートグリッド内の様々なデバイスを制御するために使用されるコマンドは、手動または自動で生成され得る。コマンドフィルタシステムが、スマートグリッド内に実装され、各デバイスコマンドを分析して、特定のデバイスによる実行に関してデバイスコマンドを許可するとよい。コマンドフィルタシステムは、スマートグリッド内の各デバイスコマンドを受信するとよい。コマンドフィルタシステムは、デバイスコマンドに一連のルールを適用するとよい。一連のルールの適用に基づき、コマンドフィルタシステムは、特定のデバイスによる実行に関してコマンドを許可するとよい。コマンドフィルタシステムはさらに、コマンドが特定のデバイスにより実行されるのを防ぐこともできる。実行を防がれた各コマンドに関して、コマンドフィルタシステムにより拒否メッセージが生成されるとよい。各拒否メッセージは、拒否されたコマンドの発信ソースへ、または後からの介入のために監視場所へ伝送されるとよい。

コマンドフィルタシステムは、様々な所定のルールを実装して、許可が与えられるべきかどうかを様々なコマンドに関して判断するとよい。コマンドフィルタシステムは、同時に、または所定の時間ウィンドウ内に受信されたコマンドを分析するとよい。所定のルールは、受信されたコマンドの数またはタイプを対象としてもよい。コマンドフィルタシステムは、分析で用いるために、スマートグリッドに関連する過去データ、ならびに現在の動作条件を読み出してもよい。コマンドフィルタシステムは、過去データに基づき、特定のコマンドまたはコマンドのグループに関する許可決定を実行するとよい。コマンドフィルタシステムは、現在の動作条件を過去データとともに使用して、許可が検討されている１つ以上のコマンドの実行の、スマートグリッドに対する影響を予測するとよい。予測された影響に所定のルールが適用されて、コマンドが許可されるべきか否かが判断されるとよい。

コマンドフィルタシステムは、様々な構成を有するスマートグリッドにおいて実装され得る。コマンドフィルタは、通信ネットワークバスまたはグリッドイベント認識バスなど、スマートグリッド内のソフトウェアバスによって実装されてもよい。コマンドフィルタは、許可されたコマンドを直接デバイスに中継しても、通信ネットワークおよびサブネットワークを経由してコマンドを中継してもよい。コマンドフィルタシステムは、スマートグリッド中を送られるデバイスコマンドを実質的にすべて受信するよう構成された、単一システムであってもよい。他の構成では、分散したコマンドフィルタシステムそれぞれが特定のタイプのデバイスに関連するコマンドの分析を担当するように、コマンドフィルタシステムは、スマートグリッド内に分散していてもよい。

以下の図面および詳細な説明を検討すると、当業者には、他のシステム、方法、特徴および利点が明らかであるか、または明らかとなるであろう。そのようなさらなるシステム、方法、特徴および利点はすべて、本記載に含まれ、本発明の範囲内にあり、添付の特許請求の範囲により保護されるものとする。

電力グリッドの全体的なアーキテクチャの一例のブロック図である。 電力グリッドの全体的なアーキテクチャの一例のブロック図である。 電力グリッドの全体的なアーキテクチャの一例のブロック図である。 図１に示されたＩＮＤＥ ＣＯＲＥのブロック図である。 電力グリッドの全体的なアーキテクチャの別の例のブロック図である。 電力グリッドの全体的なアーキテクチャの別の例のブロック図である。 電力グリッドの全体的なアーキテクチャの別の例のブロック図である。 図１および図３に示されたＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮのブロック図である。 図１および図３に示されたＩＮＤＥ ＤＥＶＩＣＥのブロック図である。 図１および図３に示されたＩＮＤＥ ＤＥＶＩＣＥのブロック図である。 電力グリッドの全体的なアーキテクチャのさらに別の例のブロック図である。 電力グリッドの全体的なアーキテクチャのさらに別の例のブロック図である。 電力グリッドの全体的なアーキテクチャのさらに別の例のブロック図である。 電力グリッドの全体的なアーキテクチャのさらに別の例のブロック図である。 可観測性（ｏｂｓｅｒｖａｂｉｌｉｔｙ）プロセスのいくつかの例の列挙を含むブロック図である。 グリッド状態測定＆動作プロセスのフロー図を示す。 グリッド状態測定＆動作プロセスのフロー図を示す。 非運用データプロセスのフロー図を示す。 イベント管理プロセスのフロー図を示す。 需要応答（ＤＲ：Ｄｅｍａｎｄ Ｒｅｓｐｏｎｓｅ）シグナリングプロセスのフロー図を示す。 需要応答（ＤＲ）シグナリングプロセスのフロー図を示す。 需要応答（ＤＲ）シグナリングプロセスのフロー図を示す。 コマンドフィルタモジュールの例のブロック図を示す。 ユーティリティグリッド上に実装された図１３のコマンドフィルタモジュールの例を示す。 別のユーティリティグリッド上に実装された図１３のコマンドフィルタモジュールの例を示す。 別のユーティリティグリッド上に実装された図１３のコマンドフィルタモジュールの例を示す。 別のユーティリティグリッド上に実装された図１３のコマンドフィルタモジュールの例を示す。 図１３のコマンドフィルタモジュールの例の、動作フロー図の例を示す。

概要として、以下に記載される好適な実施形態は、コマンドフィルタシステムに関する。コマンドフィルタシステムは、電力グリッド内の様々なデバイスの動作を制御することを目的としているコマンドを受信するとよい。コマンドフィルタは、コマンドに１つ以上のルールを適用して、受信するよう意図されているデバイスによる実行に関してコマンドが許可されるべきであるかどうかを判断するとよい。

ＩＮＤＥ上位アーキテクチャの説明
全体的アーキテクチャ
図面を参照する。図面では、同じ参照数字は類似した構成要素を指し、図１はＩＮＤＥの全体的なアーキテクチャの一例を示す。このアーキテクチャは、スマートグリッドデータのエンドツーエンド収集、搬送、記憶および管理を提供する参照モデルとなり得る。さらにこのアーキテクチャは、解析および解析管理、ならびに前述のもののユーティリティプロセスおよびシステムへの統合を提供し得る。したがって、これはエンタープライズ規模のアーキテクチャと見なされるとよい。運用管理、およびグリッド自体の各側面など、特定の要素については、下記でさらに詳しく説明する。

図１に示されているアーキテクチャは、データおよび統合バスを最大４つまで含み得る：（１）高速センサーデータバス１４６（運用および非運用データを含むとよい）、（２）専用イベント処理バス１４７（イベントデータを含むとよい）、（３）動作サービスバス１３０（スマートグリッドについての情報をユーティリティのバックオフィスアプリケーションに提供する役割を果たすとよい）、ならびに（４）バックオフィスＩＴシステム用のエンタープライズサービスバス（エンタープライズＩＴ１１５にサービス提供するエンタープライズ統合環境バス１１４として図１に示されている）。個々のデータバスは、１つ以上の方法で実現され得る。例えば、高速センサーデータバス１４６およびイベント処理バス１４７など、データバスの２つ以上は、単一データバスの異なるセグメントであってもよい。具体的には、バスはセグメント化された構造またはプラットフォームを有してもよい。以下でさらに詳しく説明するように、データバスの別々のセグメント上にデータをルーティングするために、１つ以上のスイッチなどのハードウェアおよび／またはソフトウェアが使用され得る。

別の例として、データバスの２つ以上は、データを別々のバス上で搬送するために必要なハードウェアに関して別々の物理的バスなど、別々のバス上にあってもよい。具体的には、バスはそれぞれ、互いに独立したケーブルを含んでもよい。さらに、別々のバスのうち、一部または全部が同じタイプであってもよい。例えば、バスの１つ以上が、非シールドより対線を介したイーサネット（登録商標）およびＷｉ−Ｆｉ（登録商標）などのローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）を含んでもよい。以下でさらに詳しく説明するように、ルータなどのハードウェアおよび／またはソフトウェアが、種々の物理的バスの中の１つのバス上へデータ上のデータをルーティングするために使用されてもよい。

さらに別の例として、バスの２つ以上が、単一バス構造の異なるセグメント上にあってもよく、１つ以上のバスが、別個の物理的バス上にあってもよい。具体的には、高速センサーデータバス１４６およびイベント処理バス１４７が、単一データバスの異なるセグメントであってもよく、エンタープライズ統合環境バス１１４が、物理的に別個のバス上にあってもよい。

図１は、４つのバスを示すが、より少ない、または多い数のバスが、列挙された４タイプのデータを運ぶために使用され得る。例えば、後述するように、センサーデータおよびイベント処理データの伝達に、セグメント化されていない単一バスが使用されてもよい（バスの総数は３になる）。さらにシステムは、動作サービスバス１３０および／またはエンタープライズ統合環境バス１１４なしで動作することもできる。

ＩＴ環境は、ＳＯＡ（Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ：サービス指向アーキテクチャ）に準拠していてもよい。サービス指向アーキテクチャ（ＳＯＡ）は、サービスとしてパッケージ化されたビジネスプロセスのライフサイクル全体にわたる作成および使用に関する、コンピュータシステムアーキテクチャの様式である。ＳＯＡはさらに、種々のアプリケーションがデータを交換してビジネスプロセスに関与することを可能にするようＩＴインフラストラクチャを定義し、供給する。とはいえ、ＳＯＡおよびエンタープライズサービスバスの使用は任意選択である。

図面は、（１）ＩＮＤＥ ＣＯＲＥ１２０、（２）ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０および（３）ＩＮＤＥ ＤＥＶＩＣＥ１８８など、全体的なアーキテクチャ内の種々の構成要素を示す。全体的なアーキテクチャ内で構成要素をこのように分割しているのは、説明のためである。この他の構成要素の分割が使用されてもよい。ＩＮＤＥアーキテクチャは、グリッドインテリジェンスに対する分散型および集中型両方の手法をサポートするため、および大型実装の規模に対応するメカニズムを提供するために使用され得る。

ＩＮＤＥ参照アーキテクチャは、実装され得る技術アーキテクチャの一例である。例えば、後述するように、ＩＮＤＥ参照アーキテクチャをメタアーキテクチャの例とし、これを、各ユーティリティソリューションに対し１つ、任意の数の具体的技術アーキテクチャを開発するための、開始点を提供するために使用することもできる。したがって、特定のユーティリティ向けの具体的なソリューションは、ＩＮＤＥ参照アーキテクチャの構成要素のうちの１つ、いくつかまたはすべてを含むとよい。さらに、ＩＮＤＥ参照アーキテクチャは、ソリューション開発の標準化された開始点を提供するとよい。特定の電力グリッドに対し具体的な技術アーキテクチャを決定する手順について後述する。

ＩＮＤＥ参照アーキテクチャは、エンタープライズ規模のアーキテクチャであるとよい。その目的は、グリッドデータおよび解析のエンドツーエンド管理と、これらのユーティリティシステムおよびプロセスへの統合とのためのフレームワークを提供することであるとよい。スマートグリッド技術は、ユーティリティビジネスプロセスのあらゆる側面に影響することから、グリッド、動作および需要家構内レベルの影響のみではなく、バックオフィスおよびエンタープライズレベルの影響にも気を配らなければならない。したがって、ＩＮＤＥ参照アーキテクチャは、例えばインターフェースのためにＳＯＡ環境をサポートするよう、エンタープライズレベルＳＯＡを参照することができ、実際に参照する。これは、スマートグリッドを構築および使用するには、ユーティリティがその既存のＩＴ環境をＳＯＡに変更しなければならないと要求するものと見なされてはならない。エンタープライズサービスバスは、ＩＴ統合を促進する有益なメカニズムであるが、スマートグリッドソリューションの残りの部分を実装するために必須ではない。以下の説明は、ＩＮＤＥスマートグリッド構成要素の種々のコンポーネントに焦点を合わせる。

ＩＮＤＥコンポーネントグループ
上記のように、ＩＮＤＥ参照アーキテクチャ内の種々のコンポーネントには、例えば（１）ＩＮＤＥ ＣＯＲＥ１２０、（２）ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０および（３）ＩＮＤＥ ＤＥＶＩＣＥ１８８が含まれ得る。以下の各セクションは、ＩＮＤＥ参照アーキテクチャのこれら３つの構成要素グループの例について説明し、各グループのコンポーネントの説明を提供する。

ＩＮＤＥ ＣＯＲＥ
図２は、図１に示されているように、ＩＮＤＥ参照アーキテクチャのうち、動作制御センターに存在するとよい部分である、ＩＮＤＥ ＣＯＲＥ１２０を示す。ＩＮＤＥ ＣＯＲＥ１２０は、グリッドデータを記憶するための統一データアーキテクチャと、そのデータに対して行われる解析の統合スキーマとを含むとよい。このデータアーキテクチャは、その最上位スキーマとして、国際電気標準会議（ＩＥＣ：Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｌｅｃｔｒｏｔｅｃｈｎｉｃａｌ Ｃｏｍｍｉｓｓｉｏｎ）共通情報モデル（ＣＩＭ：Ｃｏｍｍｏｎ Ｉｎｆｏｒｍａｔｉｏｎ Ｍｏｄｅｌ）を使用するとよい。ＩＥＣ ＣＩＭは、アプリケーションソフトウェアが電気ネットワークの構成およびステータスについての情報を交換できるようにすることを目標として、電気電力業界により開発されＩＥＣにより公式に採用された標準である。

さらに、このデータアーキテクチャは、他のタイプのユーティリティデータ（例えば計器データ、運用および過去データ、ログならびにイベントファイルなど）、ならびに接続性およびメタデータファイルを、エンタープライズアプリケーションを含む上位アプリケーションによるアクセスのための単一エントリポイントを有するとよい単一データアーキテクチャに関連付けるために、連合ミドルウェア１３４を使用するとよい。さらに、リアルタイムシステムが、高速データバスを介して主要データストアにアクセスするとよく、いくつかのデータストアがリアルタイムデータを受信することができる。種々のタイプのデータが、スマートグリッド内の１つ以上のバス内で搬送されるとよい。ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０のセクションにおいて以下で説明するように、変電所データは、変電所において収集されてローカルに記憶されるとよい。具体的には、変電所に関連し近接しているとよいデータベースが、変電所データを記憶するとよい。さらに、変電所レベルに関連する解析は、変電所のコンピュータにて実行され、変電所データベースに記憶されるとよく、そのデータの全部または一部が、制御センターへ搬送されるとよい。

搬送されるデータのタイプは、動作および非運用データ、イベント、グリッド接続性データならびにネットワーク位置データを含むとよい。運用データは、次に限定はされないが、スイッチ状態、フィーダ状態、コンデンサ状態、セクション状態、計器状態、ＦＣＩ（ｆａｕｌｔ ｃｉｒｃｕｉｔ ｉｎｄｉｃａｔｏｒ：故障回路インジケータ）状態、ラインセンサー状態、電圧、電流、有効電力、無効電力などを含むとよい。非運用データは、次に限定はされないが、電力品質、電力信頼性、アセット正常性（ａｓｓｅｔ ｈｅａｌｔｈ）、ストレスデータなどを含むとよい。運用および非運用データは、運用／非運用データバス１４６を使用して搬送されるとよい。電力グリッドの送電および／または配電におけるデータ収集アプリケーションが、データの一部または全部を運用／非運用データバス１４６へ送信することを担当するとよい。このように、情報を得るための登録をすること、またはこのデータを利用可能にできるサービスを呼び出すことにより、この情報を必要とするアプリケーションがデータを得られるとよい。

イベントは、後述するように、スマートグリッドの一部である様々なデバイスおよびセンサーから生じるメッセージおよび／またはアラームを含むとよい。イベントは、スマートグリッドネットワーク上のデバイスおよびセンサーから直接生成されてもよく、さらに、こうしたセンサーおよびデバイスからの測定データに基づいて様々な解析アプリケーションにより生成されてもよい。イベントの例には、計器の停止、計器のアラーム、変圧器の停止などが含まれ得る。グリッドデバイスのようなグリッドコンポーネント（スマート電力センサー（デジタル処理機能のためにプログラム可能な組み込みプロセッサを備えるセンサーなど）、温度センサーなど）、追加の組み込み処理を含む電力システムコンポーネント（ＲＴＵ（Ｒｅｍｏｔｅ Ｔｅｒｍｉｎａｌ Ｕｎｉｔ：リモート端末ユニット）など）、スマート計器ネットワーク（計器の正常性、計器読み取りなど）および移動式の現場要員用デバイス（供給停止イベント、作業命令完了など）が、イベントデータ、運用および非運用データを生成するとよい。スマートグリッド内で生成されたイベントデータは、イベントバス１４７を介して伝送されるとよい。

グリッド接続性データは、ユーティリティグリッドの配置を定義するとよい。グリッドコンポーネント（変電所、セグメント、フィーダ、変圧器、スイッチ、リクローザー、計器、センサー、電柱など）の物理的配置、およびそれらの設備における相互接続性を定義する基本レイアウトがあるとよい。グリッド内のイベント（コンポーネントの不具合、保守活動など）に基づき、グリッド接続性は継続的に変化し得る。下記でさらに詳しく説明するように、データが記憶される構造ならびにデータの組み合わせにより、過去の様々な時点における過去のグリッド配置の再現が可能となる。グリッド接続性データは、ユーティリティグリッドに対する変更が加えられ、この情報がＧＩＳ（Ｇｅｏｇｒａｐｈｉｃ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍ：地理情報システム）アプリケーションにおいて更新されるにつれて、定期的に地理情報システム（ＧＩＳ）から抽出されるとよい。

ネットワーク位置データは、通信ネットワーク上のグリッドコンポーネントについての情報を含むとよい。この情報は、メッセージおよび情報を特定のグリッドコンポーネントへ送信するために使用されるとよい。ネットワーク位置データは、新たなスマートグリッドコンポーネントが設置されたときにスマートグリッドデータベースに手動で入力されてもよく、またはこの情報が電子的に保持される場合はアセット管理システムから抽出される。

下記でさらに詳しく説明するように、データは、グリッド内の様々なコンポーネントから送信され得る（ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０および／またはＩＮＤＥ ＤＥＶＩＣＥ１８８など）。データは、無線、有線または両方の組み合わせでＩＮＤＥ ＣＯＲＥ１２０へ送信され得る。データは、ユーティリティ通信ネットワーク１６０によって受信されるとよく、ユーティリティ通信ネットワーク１６０は、データをルーティングデバイス１９０へ送信するとよい。ルーティングデバイス１９０は、バスのセグメント上（バスがセグメント化されたバス構造を含む場合）または独立したバス上へのデータのルーティングを管理するソフトウェアおよび／またはハードウェアを含むとよい。ルーティングデバイスは、１つ以上のスイッチまたはルータを含んでもよい。ルーティングデバイス１９０は、ネットワーキングデバイスを含むとよく、そのソフトウェアおよびハードウェアが、バスの１つ以上へデータをルーティングおよび／または転送する。例えば、ルーティングデバイス１９０は、運用および非運用データを、運用／非運用データバス１４６へルーティングするとよい。ルータはさらに、イベントデータをイベントバス１４７へルーティングするとよい。

ルーティングデバイス１９０は、データをどのようにルーティングするかを、１つ以上の方法に基づき判断するとよい。例えば、ルーティングデバイス１９０は、伝送されたデータ内の１つ以上のヘッダを検査して、データを運用／非運用データバス１４６のセグメントへルーティングするか、またはイベントバス１４７のセグメントへルーティングするかを判断してもよい。具体的には、データ内の１つ以上のヘッダが、データが動作／非運用データであるか（その結果ルーティングデバイス１９０はデータを運用／非運用データバス１４６へルーティングする）またはデータがイベントデータであるか（その結果ルーティングデバイス１９０はイベントバス１４７をルーティングする）を示してもよい。あるいは、ルーティングデバイス１９０は、データのソースまたはデータのペイロードを検査して、データのタイプを判断してもよい（例えば、ルーティングデバイス１９０は、データのフォーマットを検査して、データが運用／非運用データであるか、またはイベントデータであるかを判断してもよい）。

運用データを記憶する運用データウェアハウス１３７などのストアの１つが、真の分散型データベースとして実装されてもよい。ストアのもう１つ、ヒストリアン（図１および２において過去データ１３６として特定されている）が、分散型データベースとして実装されてもよい。これら２つのデータベースのもう一方の「エンド」は、ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０グループ（後述）にあってもよい。さらに、イベントは、複合イベント処理バスを介していくつかのデータストアのいずれかに直接記憶されてもよい。具体的には、イベントは、イベントバス１４７へ発行したすべてのイベントのリポジトリとしてもよいイベントログ１３５に記憶されてもよい。イベントログは、イベントｉｄ、イベントタイプ、イベントソース、イベント優先度およびイベント生成時間のうちの１つ、いくつか、またはすべてを記憶するとよい。イベントバス１４７が、イベントを長期記憶してすべてのイベントの維持を提供する必要はない。

データの記憶は、できるだけ、または実用的なだけ、データがソースに近くなるようになっているとよい。一実装では、これには例えば、変電所データがＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０にて記憶されることが含まれてもよい。しかし、このデータは、非常に細かい粒度レベルでグリッドを考慮した各種決定を下すために、動作制御センターレベル１１６においても必要とされることもある。データベースリンクおよびデータサービスを適宜使用することによってソリューションのすべてのレベルにおけるデータの利用可能性を促進するよう、分散型データ手法が、分散型インテリジェンス手法とともに採用されるとよい。このように、過去データストア（動作制御センターレベル１１６にてアクセス可能であるとよい）に関するソリューションは、運用データストアのソリューションと類似しているとよい。データは、変電所においてローカルに記憶されてもよく、制御センターにおいてリポジトリインスタンス上で構成されているデータベースリンクが、個別の変電所にあるデータに対するアクセスを提供する。変電所解析は、変電所において、ローカルデータストアを使用してローカルで実行されてもよい。データベースリンクを使用してローカル変電所インスタンスのデータにアクセスすることによって、動作制御センターレベル１１６で過去／集合的解析が実行されてもよい。あるいは、データは、ＩＮＤＥ ＣＯＲＥ１２０にて中央で記憶されてもよい。しかし、ＩＮＤＥ ＤＥＶＩＣＥ１８８から伝送される必要があると考えられるデータの量を考慮すると、ＩＮＤＥ ＤＥＶＩＣＥ１８８にてデータを記憶する方が好ましいこともある。具体的には、何千または何万もの変電所がある場合（電力グリッドではあり得る）、ＩＮＤＥ ＣＯＲＥ１２０へ伝送される必要のあるデータ量により、通信ボトルネックがもたらされることもあり得る。

最後に、ＩＮＤＥ ＣＯＲＥ１２０は、電力グリッド内のＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０またはＩＮＤＥ ＤＥＶＩＣＥ１８８のうちの１つ、いくつかまたはすべてをプログラムまたは制御するとよい（後述）。例えば、ＩＮＤＥ ＣＯＲＥ１２０は、プログラミングを変更してもよく（更新されたプログラムをダウンロードするなど）、またはＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０もしくはＩＮＤＥ ＤＥＶＩＣＥ１８８の任意の側面を制御する制御コマンドを提供してもよい（センサーまたは解析の制御など）。図２に示されていない他の構成要素に、この論理アーキテクチャをサポートする様々な統合構成要素が含まれ得る。

表１は、図２に示されたＩＮＤＥ ＣＯＲＥ１２０の特定の構成要素を記載する。

表１：ＩＮＤＥ ＣＯＲＥ構成要素

表１で説明したように、リアルタイムデータバス１４６（動作および非運用データを伝達する）およびリアルタイム複合イベント処理バス１４７（イベント処理データを伝達する）は単一バス３４６へ。この例が、図３のブロック図３００に示されている。

図１に示されているように、バスは、パフォーマンスのために別々になっている。ＣＥＰ処理の場合、非常に大きなメッセージバーストが起こりやすい特定の用途には、低遅延が重要であると考えられる。一方、グリッドデータフローの大部分はほぼ一定であり、デジタル故障レコーダファイルが例外であるが、これらは通常、制御された形で読み出し可能である。それに対し、イベントバーストは非同期かつランダムである。

図１はさらに、ＩＮＤＥ ＣＯＲＥ１２０とは別の、動作制御センター１１６内のさらなる構成要素を示す。具体的には、図１はさらに、計器との通信（計器からデータを収集して収集したデータをユーティリティに提供するなど）を担当するシステムである、計器データ収集ヘッドエンド（Ｍｅｔｅｒ Ｄａｔａ Ｃｏｌｌｅｃｔｉｏｎ Ｈｅａｄ Ｅｎｄ）（単数または複数）１５３を示す。需要応答管理システム１５４は、１つ以上の需要家構内にありユーティリティによる制御が可能な設備と通信するシステムである。供給停止管理システム１５５は、供給停止の位置を追跡すること、何が送られているかを管理すること、およびその回復方法によって、供給停止の管理においてユーティリティを支援するシステムである。エネルギー管理システム１５６は、送電グリッド上の変電所（例えば）のデバイスを制御する、送電システムレベルの制御システムである。配電管理システム１５７は、配電グリッドの変電所のデバイスおよびフィーダデバイス（例えば）を制御する、配電システムレベルの制御システムである。ＩＰネットワークサービス１５８は、ＩＰ型通信（ＴＣＰ／ＩＰ、ＳＮＭＰ、ＤＨＣＰおよびＦＴＰなど）をサポートする１つ以上のサーバ上で動作するサービスの集合である。給電指令モバイルデータシステム１５９は、現場のモバイルデータ端末とメッセージを送受信するシステムである。回路＆負荷潮流分析、計画、雷分析およびグリッドシミュレーションツール１５２は、グリッドの設計、分析および計画においてユーティリティにより使用されるツールの集合である。ＩＶＲ（ｉｎｔｅｇｒａｔｅｄ ｖｏｉｃｅ ｒｅｓｐｏｎｓｅ：統合音声応答）および呼管理１５１は、需要家からの電話を処理するシステムである（自動または係により）。供給停止に関する着信通話が、自動または手動で入力されて、供給停止管理システム１５５へ転送されるとよい。作業管理システム１５０は、作業命令を監視および管理するシステムである。地理情報システム１４９は、アセットが地理的にどこに位置し、各アセットがどのように接続されているかについての情報を含むデータベースである。環境がサービス指向アーキテクチャ（ＳＯＡ）を有する場合、動作ＳＯＡサポート１４８は、ＳＯＡ環境をサポートするサービスの集合である。

動作制御センター１１６内にあり、ＩＮＤＥ ＣＯＲＥ１２０外にあるシステムのうちの１つ以上は、ユーティリティが有することもあるレガシー製品システムである。こうしたレガシー製品システムの例には、動作ＳＯＡサポート１４８、地理情報システム１４９、作業管理システム１５０、呼管理１５１、回路＆負荷潮流分析、計画、雷分析およびグリッドシミュレーションツール１５２、計器データ収集ヘッドエンド（単数または複数）１５３、需要応答管理システム１５４、供給停止管理システム１５５、エネルギー管理システム１５６、配電管理システム１５７、ＩＰネットワークサービス１５８、給電指令モバイルデータシステム１５９が含まれる。なお、こうしたレガシー製品システムは、スマートグリッドから受信されるデータを処理または操作することができなくてもよい。ＩＮＤＥ ＣＯＲＥ１２０は、スマートグリッドからデータを受信し、スマートグリッドからのデータを処理し、処理したデータを１つ以上のレガシー製品システムへ、レガシー製品システムが使用できる形（レガシー製品システムに特有の特定のフォーマッティングなど）で転送することができるとよい。このように、ＩＮＤＥ ＣＯＲＥ１２０はミドルウェアと見なされてもよい。

ＩＮＤＥ ＣＯＲＥ１２０を含む動作制御センター１１６は、エンタープライズＩＴ１１５と通信するとよい。一般的に、エンタープライズＩＴ１１５における機能性はバックオフィス業務を含む。具体的には、エンタープライズＩＴ１１５は、ビジネスデータウェアハウス１０４、ビジネスインテリジェンスアプリケーション１０５、エンタープライズリソースプラニング１０６、様々な財務システム１０７、需要家情報システム１０８、人材システム１０９、アセット管理システム１１０、エンタープライズＳＯＡサポート１１１、ネットワーク管理システム１１２およびエンタープライズメッセージサービス１１３を含むエンタープライズＩＴ１１５内の様々なシステムへデータを送信するためにエンタープライズ統合環境バス１１４を使用するとよい。エンタープライズＩＴ１１５はさらに、ファイアウォール１０２を介してインターネット１０１と通信するためのポータル１０３を含むとよい。

ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ
図４は、ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０グループの上位アーキテクチャの例を示す。このグループは、変電所の電子装置およびシステムと同一の場所に位置する１つ以上のサーバ上で、変電所の制御所にて変電所１７０内で実際にホストされている構成要素を含むとよい。

以下の表２は、特定のＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０グループ構成要素を列挙し、説明する。データセキュリティサービス１７１は、変電所環境の一部であってもよい。あるいは、これらはＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０グループに統合されてもよい。

表２：ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ構成要素

上記のように、スマートグリッド内の種々の構成要素に、追加の処理／分析機能およびデータベースリソースを含む追加の機能性が含まれるとよい。スマートグリッドにおいて、様々な構成要素内でこうした追加の機能性を使用することで、アプリケーションおよびネットワークパフォーマンスの集中管理および監督を伴う分散型アーキテクチャが可能になる。機能、パフォーマンスおよび拡張性のために、何千から何万のＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０および何万から何百万のグリッドデバイスを含むスマートグリッドが、分散型処理、データ管理およびプロセス通信を含むこともできる。

ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０は、１つ以上のプロセッサと、１つ以上のメモリデバイス（変電所非運用データ１８１および変電所動作データ１８２など）とを含むとよい。非運用データ１８１および変電所動作データ１８２は、ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０内、またはＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０上に位置するなど、変電所に関連し近接しているとよい。ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０はさらに、変電所レベルでのスマートグリッドの可観測性を担当する、スマートグリッドのコンポーネントを含んでもよい。ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０コンポーネントは、運用データ獲得および分散型運用データストアでの記憶、非運用データの獲得およびヒストリアンでの記憶、ならびにリアルタイム（サブ秒など）でのローカル解析処理という３つの主要機能を提供するとよい。処理は、電圧および電流波形のデジタル信号処理と、イベントストリーム処理を含む検出および分類処理と、処理結果のローカルシステムおよびデバイス、ならびに動作制御センター１１６にあるシステムへの伝達とを含むとよい。ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０と、グリッド内の他のデバイスとの通信は、有線、無線または有線と無線との組み合わせとしてよい。例えば、ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０から動作制御センター１１６へのデータの伝送は有線であってもよい。ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０は、動作／非運用データまたはイベントデータなどのデータを、動作制御センター１１６へ伝送するとよい。ルーティングデバイス１９０は、伝送されたデータを、運用／非運用データバス１４６またはイベントバス１４７のうちの１つへルーティングするとよい。

配電損失管理のための需要応答最適化も、ここで実行されるとよい。このアーキテクチャは、前に説明した分散型アプリケーションアーキテクチャの原則に従う。

例えば、接続性データは、変電所１７０および動作制御センター１１６にて複製され、その結果、動作制御センター１１６へのデータ通信ネットワークが有効でなくても変電所１７０が独立して動作できるようにするとよい。この情報（接続性）がローカルに記憶されていることで、動作制御センターへの通信リンクが動作不能であっても変電所解析がローカルで実行され得る。

同様に、運用データは、動作制御センター１１６および変電所１７０にて複製されるとよい。特定の変電所に関連するセンサーおよびデバイスからのデータが収集され、最新の測定値が、変電所にてこのデータストアに記憶されるとよい。運用データストアのデータ構造は同じであるとよく、したがって、データベースリンクを使用して、制御センターにある運用データストアのインスタンスを介した、変電所に存在するデータへのシームレスアクセスを提供することもできる。これは、データの複製を減らすこと、および時間依存がより大きい変電所データ解析が、ローカルで、変電所外の通信利用可能性に依存せずに行われるのを可能にすることを含む、いくつかの利点を提供する。動作制御センターレベル１１６でのデータ解析は、時間依存がより小さいと考えられ（典型的には、動作制御センター１１６は、過去データを検査して、反応型というよりも予測型のパターンを識別すると考えられるため）、ネットワークの問題があっても対処できると考えられる。

最後に、過去データが変電所にてローカルに記憶され、データのコピーが制御センターにて記憶されてもよい。または、動作制御センター１１６にてリポジトリインスタンス上のデータベースリンクが構成され、個別の変電所にあるデータへのアクセスが動作制御センターに提供されてもよい。変電所解析は、変電所１７０において、ローカルデータストアを使用してローカルで実行されてもよい。具体的には、変電所にて追加のインテリジェンスおよび記憶機能を使用することで、変電所は、それ自体を分析して、中央局からの入力なしにそれ自体を修正することができる。あるいは、ローカル変電所インスタンスのデータにデータベースリンクを使用してアクセスすることによって、動作制御センターレベル１１６で、過去／集合的解析も実行されてもよい。

ＩＮＤＥ ＤＥＶＩＣＥ
ＩＮＤＥ ＤＥＶＩＣＥ１８８グループは、様々な配電グリッドデバイス１８９（例えば、送電線上のラインセンサー）などのスマートグリッド内の様々なセンサー、需要家構内にある計器１６３などを含む、スマートグリッド内の任意の種類のデバイスを含み得る。ＩＮＤＥ ＤＥＶＩＣＥ１８８グループは、特定の機能性を備えグリッドに追加されるデバイスを含んでもよく（専用プログラミングを含むスマートリモート端末ユニット（ＲＴＵ）など）、または追加機能性を備えるグリッド内の既存デバイスを含んでもよい（既にグリッド内に配置されており、スマートラインセンサーまたはスマートグリッドデバイスを作成するためにプログラム可能な、既存のオープンアーキテクチャ柱上ＲＴＵなど）。ＩＮＤＥ ＤＥＶＩＣＥ１８８はさらに、１つ以上のプロセッサおよび１つ以上のメモリデバイスを含んでもよい。

既存のグリッドデバイスは、ソフトウェアの観点からはオープンではないこともあり、現代のネットワーキングまたはソフトウェアサービスに関してはあまりサポートできないかもしれない。既存のグリッドデバイスは、ラップトップコンピュータなどの他の何らかのデバイスに時折オフロードするデータを獲得および記憶するよう、または要求に応じてリモートホストへＰＳＴＮ（ｐｕｂｌｉｃ−ｓｗｉｔｃｈｅｄ ｔｅｌｅｐｈｏｎｅ ｎｅｔｗｏｒｋ：公衆交換電話ネットワーク）線を介してバッチファイルを転送するよう設計されていることもある。こうしたデバイスは、リアルタイムデジタルネットワーク環境で動作するようには設計されていないこともある。このような場合には、グリッドデバイスデータは、既存の通信ネットワークがどのように設計されているかに応じて、変電所レベル１７０または動作制御センターレベル１１６で取得されるとよい。計器ネットワークの場合、計器ネットワークが通常クローズドであり、計器が直接アドレス指定可能ではないことから、通常は計器データ収集エンジンからデータが取得される。こうしたネットワークが進化するにつれて、計器および他のグリッドデバイスが個別にアドレス指定可能になると考えられ、その結果データが、必要とされるところへ直接搬送可能になる。データが必要とされる場所は、必ずしも動作制御センター１１６とは限らず、グリッド上のどこでもあり得る。

故障回路インジケータなどのデバイスは、適度な速度（１００ｋｂｐｓなど）の無線ネットワークを介した接続のために、無線ネットワークインターフェースカードと結合されてもよい。こうしたデバイスは、例外によりステータスをレポートして、事前にプログラムされた固定機能を実行してもよい。ローカルスマートＲＴＵを使用することによって、多数のグリッドデバイスのインテリジェンスが増強され得る。固定機能のクローズドアーキテクチャデバイスとして設計されている柱上ＲＴＵの代わりに、サードパーティーによりプログラム可能でＩＮＤＥ参照アーキテクチャ内のＩＮＤＥ ＤＥＶＩＣＥ１８８としての機能を果たすことができるオープンアーキテクチャデバイスとしてのＲＴＵが使用されてもよい。さらに、需要家の構内にある計器がセンサーとして使用されてもよい。例えば、計器は、消費を測定してもよく（請求のために、どのくらいの量のエネルギーが消費されているかなど）、電圧を測定してもよい（電圧／ＶＡｒ最適化で用いるために）。

図５は、ＩＮＤＥ ＤＥＶＩＣＥ１８８グループのアーキテクチャの例を示す。表３は、特定のＩＮＤＥ ＤＥＶＩＣＥ１８８構成要素を説明する。スマートグリッドデバイスは、組み込みプロセッサを含むとよく、したがって、ＤＥＶＩＣＥグループは専用リアルタイムＤＳＰまたはマイクロプロセッサ上で実装されるため、処理構成要素は、ＳＯＡサービスよりもリアルタイムプログラムライブラリルーチンに似る。

表３：ＩＮＤＥ ＤＥＶＩＣＥ構成要素

図１はさらに、１つ以上のスマート計器１６３、家庭内ディスプレイ１６５、１つ以上のセンサー１６６および１つ以上の制御１６７を含むとよい需要家構内１７９を示す。実際には、センサー１６６は、需要家構内１７９にある１つ以上のデバイスにてデータを登録するとよい。例えば、センサー１６６は、暖房炉、温水ヒーター、空調装置などの、需要家構内１７９の中の様々な主要電化製品にてデータを登録するとよい。この１つ以上のセンサー１６６からのデータが、スマート計器１６３へ送信されるとよく、スマート計器１６３は、ユーティリティ通信ネットワーク１６０を介して動作制御センター１１６へ伝送するためにデータをパッケージ化するとよい。家庭内ディスプレイ１６５は、スマート計器１６３および１つ以上のセンサー１６６から収集されたデータをリアルタイムで閲覧するための出力デバイスを需要家構内において需要家に提供するとよい。さらに、需要家が動作制御センター１１６と通信できるよう、入力デバイス（キーボードなど）が家庭内ディスプレイ１６５に関連付けられてもよい。一実施形態では、家庭内ディスプレイ１６５は、需要家構内にあるコンピュータを含むとよい。

需要家構内１６５はさらに、需要家構内１７９の１つ以上のデバイスを制御するとよい制御１６７を含むとよい。ヒーター、空調装置など、需要家構内１７９にある様々な電化製品が、動作制御センター１１６からのコマンドに応じて制御されるとよい。

図１に示されているように、需要家構内１６９は、インターネット１６８、公衆交換電話ネットワーク（ＰＳＴＮ）１６９を介して、または専用線を介して（コレクタ１６４を介してなど）など、様々な方法で通信するとよい。列挙された通信チャネルのいずれかを介して、１つ以上の需要家構内１７９からのデータが送信されるとよい。図１に示されているように、１つ以上の需要家構内１７９が、ユーティリティ管理ネットワーク１６０を介して動作制御センター１１６へ伝送されるようコレクタ１６４へデータを送信する、スマート計器ネットワーク１７８（複数のスマート計器１６３を含む）を含むとよい。さらに、分散型エネルギー生成／貯蔵１６２（ソーラーパネルなど）の様々なソースが、ユーティリティ管理ネットワーク１６０を介した動作制御センター１１６との通信のために、監視制御１６１へデータを送信するとよい。

上記のように、動作制御センター１１６外の電力グリッド内のデバイスは、処理および／または記憶機能を含むとよい。デバイスは、ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０およびＩＮＤＥ ＤＥＶＩＣＥ１８８を含むとよい。電力グリッド内の個別のデバイスが追加のインテリジェンスを含むことに加えて、個別のデバイスは、情報（センサーデータおよび／または分析データ（イベントデータなど）を含む）を交換するため、電力グリッドの状態を分析するため（故障の判断など）、および電力グリッドの状態を変更するため（故障の修正など）に、電力グリッド内の他のデバイスと通信するとよい。具体的には、個別のデバイスは、（１）インテリジェンス（処理機能など）、（２）記憶装置（上記の分散型記憶装置など）および（３）通信（上記の１つ以上のバスの使用など）を使用するとよい。このようにして、電力グリッド内の個別のデバイスは、動作制御センター１１６からの監督なしに相互に通信および協働するとよい。

例えば、上記で開示されたＩＮＤＥアーキテクチャは、フィーダ回路上の少なくとも１つのパラメータを感知するデバイスを含むとよい。デバイスはさらに、フィーダ回路上で感知されたパラメータを監視し、感知されたパラメータを分析してフィーダ回路の状態を判断するプロセッサを含むとよい。例えば、感知パラメータの分析は、感知されたパラメータと、所定の閾値との比較を含んでもよく、さらに／または傾向分析を含んでもよい。上記の感知されるパラメータの１つには、波形の感知が含まれてもよく、上記の分析の１つには、感知された波形がフィーダ回路上の故障を示すかどうかを判断することが含まれてもよい。デバイスはさらに、１つ以上の変電所と通信するとよい。例えば、特定の変電所が、特定のフィーダ回路に電力を供給するとよい。デバイスは、その特定のフィーダ回路の状態を感知して、特定のフィーダ回路上に故障があるかどうかを判断するとよい。デバイスは、変電所と通信するとよい。変電所は、デバイスによって判断された故障を分析するとよく、さらに、故障に応じて修正措置をとるとよい（フィーダ回路に供給される電力を削減するなど）。デバイスが故障を示すデータを送信する（波形の分析に基づき）例では、変電所は、動作制御センター１１６からの入力なしに、フィーダ回路に供給される電力を変更するとよい。または変電所は、故障を示すデータと、他のセンサーからの情報とを組み合わせて、故障の分析をさらに精緻化してもよい。変電所はさらに、供給停止インテリジェンスアプリケーションおよび／または故障インテリジェンスアプリケーションなど、動作制御センター１１６と通信してもよい。したがって、動作制御センター１１６が、故障を判断してもよく、供給停止の範囲（故障の影響を受ける戸数など）を判断してもよい。このように、フィーダ回路の状態を感知するデバイスは、動作制御センター１１６の介入を要求するかしないかに関わらず、考えられる故障を修正するために変電所と協調動作するとよい。

別の例として、処理および／またはメモリ機能を使用する追加のインテリジェンスを含むラインセンサーが、グリッドの一部（フィーダ回路など）においてグリッド状態データを作り出してもよい。グリッド状態データは、動作制御センター１１６の需要応答管理システム１５５と共有されるとよい。需要応答管理システム１５５は、ラインセンサーからのグリッド状態データに応答して、フィーダ回路上の需要家サイトの１つ以上のデバイスを制御してもよい。具体的には、需要応答管理システム１５５は、ラインセンサーがフィーダ回路上の供給停止を示すのに応答して、フィーダ回路から電力を受ける需要家サイトにある電化製品をオフにすることによって、フィーダ回路への負荷を軽減するために、エネルギー管理システム１５６および／または配電管理システム１５７に命令してもよい。このように、ラインセンサーは需要応答管理システム１５５とともに、故障したフィーダ回路から自動的に負荷を移し、続いて故障を隔離するとよい。

さらに別の例として、電力グリッド内の１つ以上のリレーが、それに関連するマイクロプロセッサを有するとよい。これらのリレーは、故障の判断、および／または電力グリッドの制御のために、電力グリッド内にある他のデバイスおよび／またはデータベースと通信するとよい。

ＩＮＤＳ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｎｅｔｗｏｒｋ Ｄａｔａ Ｓｅｒｖｉｃｅｓ：インテリジェントネットワークデータサービス）の概念およびアーキテクチャ
アウトソースされるスマートグリッドデータ／解析サービスモデル
スマートグリッドアーキテクチャの１つの応用は、ユーティリティが、組織内に従来の制御システムおよび関係する運用システムを保持しながら、グリッドデータ管理および解析サービスを契約できるようにする。このモデルでは、ユーティリティはグリッドセンサーおよびデバイスを設置および所有するとよく（上記のように）、グリッドデータ搬送通信システムは、所有および運用しても、アウトソースしてもよい。グリッドデータは、ユーティリティからリモートのインテリジェントネットワークデータサービス（ＩＮＤＳ）ホスティングサイトへ流れ、そこでデータが管理、記憶および分析されてもよい。その結果、ユーティリティは、適切なサービス財務モデルのもとでデータおよび解析サービスを契約することもできる。ユーティリティは、料金を払う代わりに、初期資本支出投資と、スマートグリッドデータ／解析インフラストラクチャの継続的な管理、サポートおよび改良費を回避することができる。上記のＩＮＤＥ参照アーキテクチャは、本願明細書に記載される構成をアウトソースするのに適している。

スマートグリッドサービスのＩＮＤＳアーキテクチャ
ＩＮＤＳサービスモデルを実装するために、ＩＮＤＥ参照アーキテクチャは、リモートでホストされるとよい構成要素のグループと、ユーティリティに残るとよいものとに区分されるとよい。図６は、ＩＮＤＥ ＣＯＲＥ１２０がリモートにされるとユーティリティアーキテクチャがどのように見えると考えられるかを示す。サーバが、ＩＮＤＥ ＣＯＲＥ１２０の一部として含まれるとよく、リモートシステムへのインターフェースとして機能するとよい。ユーティリティシステムには、これが仮想ＩＮＤＥ ＣＯＲＥ６０２に見えるとよい。

図６の全体的なブロック図６００が示すように、ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０およびＩＮＤＥ ＤＥＶＩＣＥ１８８グループは、図１に示されたものから変化していない。さらに、複数バス構造も、やはりユーティリティにて採用されるとよい。

ＩＮＤＥ ＣＯＲＥ１２０は、図７のブロック図７００が示すようにリモートでホストされるとよい。ホスティングサイトでは、ユーティリティのＩＮＤＳ契約者をサポートするために、必要に応じＩＮＤＥ ＣＯＲＥ１２０が設置されるとよい（北米ＩＮＤＳホスティングセンター７０２として示されている）。各ＣＯＲＥ１２０は、モジュラーシステムであり、その結果新たな契約者の追加は定型操作であるとよい。電気ユーティリティとは別の関係者が、ＩＮＤＥ ＣＯＲＥ１２０の１つ、いくつかまたはすべてのソフトウェアと、ＩＮＤＳホスティングサイトから各ユーティリティのＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０およびＩＮＤＥ ＤＥＶＩＣＥ１８８にダウンロードされるアプリケーションとを管理およびサポートするとよい。

通信を促進するために、契約ユーティリティの動作センターならびにＩＮＤＳホスティングサイトに到達することができるネットワーク７０４（例えばＭＰＬＳまたはその他のＷＡＮ）などを介した高帯域低遅延通信サービスが使用されるとよい。図７に示されているように、カリフォルニア州、フロリダ州およびオハイオ州など、様々なエリアにサービスが提供されるとよい。このような運用のモジュール性は、異なる様々なグリッドの効率的な管理を可能にするのみではなく、グリッド間のよりよい管理も可能にする。１つのグリッドにおける不具合が、周辺のグリッドにおける動作に影響を及ぼす恐れがある場合がある。例えば、オハイオ州のグリッドにおける不具合が、中部大西洋岸のグリッドなど、周辺のグリッドにおける動作に対しカスケード効果を有することもある。図７に示されているモジュール構造を使用することで、個別のグリッドの管理およびグリッド間動作の管理が可能になる。具体的には、全体的なＩＮＤＳシステム（プロセッサおよびメモリを含む）が、様々なＩＮＤＥ ＣＯＲＥ１２０間の対話を管理するとよい。これは、１つのグリッドから別のグリッドへ波及する破局故障の可能性を軽減するとよい。例えば、オハイオ州のグリッドにおける不具合が、中部大西洋岸のグリッドなど、周辺のグリッドに波及することもある。オハイオ州のグリッドの管理専用のＩＮＤＥ ＣＯＲＥ１２０は、オハイオ州のグリッドにおける不具合の修正を試みるとよい。さらに、全体的なＩＮＤＳシステムが、波及不具合が周辺グリッドで生じる可能性を軽減することを試みるとよい。

ＩＮＤＥ ＣＯＲＥにおける機能性の具体的な例
図１、６および７に示されているように、様々な機能性（ブロックにより表されている）がＩＮＤＥ ＣＯＲＥ１２０に含まれており、示されているもののうち２つは、計器データ管理サービス（ＭＤＭＳ：ｍｅｔｅｒ ｄａｔａ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｉｃｅｓ）１２１ならびに計測解析およびサービス１２２である。アーキテクチャのモジュール性が理由で、ＭＤＭＳ１２１ならびに計測解析およびサービス１２２などの様々な機能性を組み込むことができる。

可観測性プロセス
上記のように、アプリケーションサービスの１つの機能性は、可観測性プロセスを含むとよい。可観測性プロセスは、ユーティリティがグリッドを「観測」できるようにするとよい。こうしたプロセスは、グリッド上のすべてのセンサーおよびデバイスから受信される生データを解釈して、それを実用的な情報へ変えることを担当するとよい。図８は、可観測性プロセスのいくつかの例の列挙を含む。

図９は、グリッド状態測定＆動作プロセスのフロー図９００を示す。図のように、ブロック９０２にて示されているように、データスキャナが計器データをリクエストするとよい。リクエストは、１つ以上のグリッドデバイス、変電所コンピュータおよびラインセンサーＲＴＵへ送信されるとよい。デバイスは、ブロック９０４、９０８、９１２にて示されているように、リクエストに応答して動作データを収集するとよく、ブロック９０６、９１０、９１４にて示されているように、データ（電圧、電流、有効電力および無効電力データなどの運用データのうちの１つ、いくつかまたはすべてなど）を送信するとよい。データスキャナは、ブロック９２６にて示されているように、運用データを収集して、ブロック９２８にて示されているように、データを運用データストアへ送信するとよい。ブロック９３８にて示されているように、運用データストアは運用データを記憶するとよい。ブロック９４０にて示されているように、運用データストアはさらに、データのスナップショットをヒストリアンへ送信して、ブロック９４２にて示されているように、ヒストリアンは、データのスナップショットを記憶するとよい。

計器状態アプリケーションは、ブロック９２４に示されているように、計器データのリクエストを計器ＤＣＥ（ｄａｔａ ｃｏｌｌｅｃｔｉｏｎ ｅｎｇｉｎｅ：データ収集エンジン）へ送信するとよく、その結果として計器ＤＣＥは、ブロック９２０にて示されているように、計器データ収集のリクエストを１つ以上の計器へ送信する。この１つ以上の計器は、ブロック９１６にて示されているように、リクエストに応答して計器データを収集し、ブロック９１８にて示されているように、電圧データを計器ＤＣＥへ送信する。計器ＤＣＥは、ブロック９２２にて示されているように電圧データを収集して、ブロック９２８にて示されているようにデータをデータのリクエスタへ送信するとよい。計器状態アプリケーションは、ブロック９３０にて示されているように、計器データを受信し、ブロック９３２にて示されているように、それが単一値プロセス（ｓｉｎｇｌｅ ｖａｌｕｅ ｐｒｏｃｅｓｓ）に関するか、電圧プロフィールグリッド状態（ｖｏｌｔａｇｅ ｐｒｏｆｉｌｅ ｇｒｉｄ ｓｔａｔｅ）に関するかを判断するとよい。単一値プロセスに関するものであれば、ブロック９３６にて示されているように、計器データはリクエストしているプロセスへ送信される。計器データが、後からグリッド状態を判断するために記憶されるものであれば、ブロック９３８にて示されているように、計器データは運用データストアに記憶される。ブロック９４０にて示されているように、運用データストアはさらに、データのスナップショットをヒストリアンへ送信して、ブロック９４２にて示されているように、ヒストリアンは、データのスナップショットを記憶する。

図９はさらに、需要応答（ＤＲ）に関するアクションを示す。需要応答は、例えば電気の需要家にその消費を、緊急時、または市場価格に応じて削減させるなど、供給条件に応じて需要家の電気消費を管理するための動的需要メカニズムを指す。これは、実際に使用電力を削減することを伴っても、またはオンサイト発電を開始することによってもよく、オンサイト発電は、グリッドと並列接続されていても、されていなくてもよい。これは、同じタスクを実行するために継続的に、または当該タスクが実行されるときに必ず、より少ない電力を使用することを意味する、エネルギー効率とは異なると考えられる。需要応答では、１つ以上の制御システムを使用する需要家が、ユーティリティによるリクエストまたは市場価格条件に応じて負荷を減らすとよい。サービス（光、機械、空調）は、緊急の時間フレームの間、事前計画された負荷優先順位付けスキームに従って削減されるとよい。負荷制限の代替手段は、電力グリッドを補うための、電気のオンサイト発電である。電気供給が不足する状況のもとでは、需要応答により、最高値および全般的な電気価格の変動が大幅に低減され得る。

需要応答は、一般に、消費者が需要を減らすことを促し、それによって電気のピーク需要を減らすよう使用されるメカニズムを指すために使用される。電気システムは、一般に、ピーク需要（それに加えてエラーおよび予期せぬイベントに備えた余裕）に対応するような規模であり、ピーク需要が減れば、全体的な設備および資本コスト要件が緩和され得る。一方、発電容量の構成次第で、需要応答は、大量生産・低需要のときに需要（負荷）を増やすためにも使用され得る。それによって、一部のシステムは、低需要および高需要（または安値および高値）の期間の間の裁定取引を行うためのエネルギー貯蔵を促すこともできる。システムにおいて、風力などの断続的な電力源の割合が増えるにつれて、需要応答は電気グリッドの効果的な管理にますます重要になると考えられる。

ブロック９５４にて示されているように、ＤＲ状態アプリケーションは、ＤＲ利用可能容量をリクエストするとよい。続いて、ブロック９４８にて示されているように、ＤＲ管理システムは、１つ以上のＤＲホームデバイスからの利用可能容量をリクエストするとよい。この１つ以上のホームデバイスは、ブロック９４４にて示されているように、リクエストに応答して利用可能なＤＲ容量を収集して、ブロック９４６にて示されているように、ＤＲ容量および応答データをＤＲ管理システムへ送信するとよい。ＤＲ管理システムは、ブロック９５０にて示されているように、ＤＲ容量および応答データを収集して、ブロック９５２にて示されているように、ＤＲ容量および応答データをＤＲ状態アプリケーションへ送信するとよい。ＤＲ状態アプリケーションは、ブロック９５６にて示されているように、ＤＲ容量および応答データを受信して、ブロック９５８にて示されているように、容量および応答データを運用データストアへ送信するとよい。ブロック９３８にて示されているように、運用データストアはＤＲ容量および応答データデータを記憶するとよい。ブロック９４０に示されているように、運用データストアはさらに、データのスナップショットをヒストリアンへ送信して、ブロック９４２に示されているように、ヒストリアンは、データのスナップショットを記憶するとよい。

ブロック９７４にて示されているように、変電所コンピュータは、変電所アプリケーションからのアプリケーションデータをリクエストするとよい。それに応答して、ブロック９６４にて示されているように、変電所アプリケーションは、変電所デバイスからのアプリケーションをリクエストするとよい。変電所デバイスは、ブロック９６０にて示されているように、アプリケーションデータを収集して、ブロック９６２にて示されているように、変電所デバイスにアプリケーションデータを送信するとよい（電圧、電流、有効電力および無効電力データのうちの１つ、いくつかまたはすべてを含むとよい）。変電所アプリケーションは、ブロック９６６にて示されているように、アプリケーションデータを収集して、ブロック９６８にて示されているように、アプリケーションデータをリクエスタ（変電所コンピュータであってもよい）へ送信するとよい。変電所コンピュータは、ブロック９７０にて示されているように、アプリケーションデータを受信して、ブロック９７２にて示されているように、アプリケーションデータを運用データストアへ送信するとよい。

グリッド状態測定および運用データプロセスは、所定の時点でのグリッド状態およびグリッドトポロジを抽出すること、ならびにこの情報を他のシステムおよびデータストアに提供することを含み得る。サブプロセスは、（１）グリッド状態情報を測定および保存すること（これは、前に説明した、グリッドに関連する運用データに関係する）、（２）グリッド状態情報を他の解析アプリケーションへ送信すること（これは、分析アプリケーションなどの他のアプリケーションがグリッド状態データにアクセスできるようにする）、（３）グリッド状態スナップショットを接続性／運用データストアに維持すること（これは、接続性／運用データストアのグリッド状態情報を適切なフォーマットで更新すること、ならびに或る時点でのグリッドトポロジが後の時点で抽出可能なように、この情報を維持のためにヒストリアンへ転送することを可能にする）、（４）デフォルトの接続性および現在のグリッド状態に基づき、或る時点でのグリッドトポロジを抽出すること（これは、下記でさらに詳しく説明するように、ヒストリアン内のグリッド状態の所定の時点でのスナップショットを、接続性データストア内の基礎となる接続性に適用することによって、その時点でのグリッドトポロジを提供する）ならびに（５）リクエストに応じてグリッドトポロジ情報をアプリケーションに提供することを含むとよい。

サブプロセス（４）に関しては、グリッドトポロジはリアルタイム、３０秒前、１ヶ月前など、所定時間に関して抽出され得る。グリッドトポロジを再現するために、複数のデータベースが使用されてもよく、グリッドトポロジを再現するために複数のデータベース内のデータにアクセスするプログラム。１つのデータベースは、基礎となる接続性データを記憶するリレーショナルデータベースを含むとよい（「接続性データベース」）。接続性データベースは、ベースライン接続性モデルを判断するための、施工完了時のグリッドトポロジ情報を保持しているとよい。電力グリッド内の回路の追加または変更など（例えば、電力グリッドに追加される追加のフィーダ回路）、電力グリッドの改良に応じて、アセットおよびトポロジ情報が定期的にこのデータベースに対し更新されるとよい。接続性データベースは、変化しないことから「静的」と見なされてもよい。接続性データベースは、電力グリッドの構造に変更があれば変化するとよい。例えば、フィーダ回路の追加など、フィーダ回路に変更があれば接続性データベースが変化するとよい。

第２のデータベースは、「動的」データを記憶するために使用されるとよい。第２のデータベースは、非リレーショナルデータベースを含むとよい。非リレーショナルデータベースの一例は、時系列の非運用データおよび過去の運用データを記憶する、ヒストリアンデータベースを含み得る。ヒストリアンデータベースは、（１）タイムスタンプ、（２）デバイスＩＤ、（３）データ値および（４）デバイスステータスなどの一連の「フラット」レコードを記憶するとよい。さらに、記憶されるデータは圧縮されるとよい。このため、電力グリッド内の動作／非運用データが容易に記憶されるとよく、かなりの量のデータが利用可能であるにもかかわらず、管理可能であるとよい。例えば、５テラバイトオーダーのデータが、グリッドトポロジを再現するために用いられるよういつでもオンラインであってもよい。データは単純なフラットレコードで記憶されるため（編成手法が用いられないなど）、データの記憶における効率性が与えられる。下記でさらに詳しく説明するように、データは、データ要素識別子などの特定のタグによりアクセスされてもよい。

グリッドの様々な解析が、特定の時点のグリッドトポロジを入力として受信することを望み得る。例えば、電力品質、信頼性、アセット正常性などに関する解析が、グリッドトポロジを入力として使用し得る。グリッドトポロジを判断するために、接続性データベース内のデータにより定義されるベースライン接続性モデルがアクセスされるとよい。例えば、特定のフィーダ回路のトポロジが求められる場合、ベースライン接続性モデルは、電力グリッド内の特定のフィーダ回路内の様々なスイッチを定義するとよい。その後、特定のフィーダ回路内のスイッチの値を判断するために、ヒストリアンデータベースがアクセスされるとよい（特定の時間に基づき）。次に、特定の時間の特定のフィーダ回路の表現を生成するために、プログラムが、ベースライン接続性モデルおよびヒストリアンデータベースからのデータを結合するとよい。

グリッドトポロジの判断のより複雑な例は、インタータイスイッチ（ｉｎｔｅｒ−ｔｉｅ ｓｗｉｔｃｈ）および区分スイッチを有する複数のフィーダ回路（例えばフィーダ回路Ａおよびフィーダ回路Ｂ）を含み得る。特定のスイッチ（インタータイスイッチおよび／または区分スイッチなど）のスイッチ状態に応じて、フィーダ回路のセクションは、フィーダ回路Ａまたはフィーダ回路Ｂに属し得る。グリッドトポロジを判断するプログラムは、特定の時間の接続性（例えば、どの回路がフィーダ回路Ａまたはフィーダ回路Ｂに属するか）を判断するために、ベースライン接続性モデルおよびヒストリアンデータベース両方からのデータにアクセスするとよい。

図１０は、非運用データプロセスのフロー図１０００を示す。ブロック１００２にて示されているように、非運用抽出アプリケーションが、非運用データをリクエストするとよい。それに応答して、ブロック１００４にて示されているように、データスキャナが非運用データを集めるとよく、それによって、ブロック１００６、１００８、１１１０にて示されているように、グリッドデバイス、変電所コンピュータおよびラインセンサーＲＴＵなどの電力グリッド内の様々なデバイスが非運用データを収集するとよい。上記のように、非運用データは、温度、電力品質などを含むとよい。ブロック１０１２、１０１４、１１１６にて示されているように、グリッドデバイス、変電所コンピュータおよびラインセンサーＲＴＵなど、電力グリッド内の様々なデバイスが、非運用データをデータスキャナへ送信するとよい。データスキャナは、ブロック１０１８にて示されているように、非運用データを収集して、ブロック１０２０にて示されているように、非運用データを非運用抽出アプリケーションへ送信するとよい。非運用抽出アプリケーションは、ブロック１０２２にて示されているように、非運用データを収集して、ブロック１０２４にて示されているように、収集した非運用データをヒストリアンへ送信するとよい。ヒストリアンは、ブロック１０２６にて示されているように、非運用データを受信し、ブロック１０２８にて示されているように、非運用データを記憶し、ブロック１０３０にて示されているように、非運用データを１つ以上の解析アプリケーションへ送信するとよい。

図１１は、イベント管理プロセスのフロー図１１００を示す。データは、電力グリッド内の様々なイベントに基づき様々なデバイスから生成されて、イベントバス１４７を介して送信されるとよい。例えば、ブロック１１０２にて示されているように、計器データ収集エンジンは、電力供給停止／復旧通知情報をイベントバスへ送信するとよい。ブロック１１０４にて示されているように、ラインセンサーＲＴＵは、故障メッセージを生成して、その故障メッセージをイベントバスへ送信するとよい。変電所は解析は、ブロック１１０６にて示されているように、故障および／または供給停止メッセージを生成するとよく、その故障および／または供給停止メッセージをイベントバスへ送信するとよい。ブロック１１０８にて示されているように、ヒストリアンは、信号挙動をイベントバスへ送信するとよい。さらに、様々なプロセスがイベントバス１４７を介してデータを送信するとよい。例えば、ブロック１１１０にて示されているように、故障インテリジェンスプロセスが、イベントバスを介して故障分析イベントを送信するとよい。ブロック１１１４にて示されているように、イベントバスは様々なイベントを収集するとよい。さらに、ブロック１１２０にて示されているように、複合イベント処理（ＣＥＰ）サービスが、イベントバスを介して送信されたイベントを処理するとよい。ＣＥＰサービスは、同時に発生する複数の高速リアルタイムイベントメッセージストリームに対するクエリを処理するとよい。ブロック１１１８にて示されているように、ＣＥＰサービスによる処理の後、イベントデータはイベントバスを介して送信されるとよい。さらに、ブロック１１１６にて示されているように、ヒストリアンが、記憶のために１つ以上のイベントログを、イベントバスを介して受信するとよい。さらに、ブロック１１２２にて示されているように、イベントデータは、供給停止管理システム（ＯＭＳ）、供給停止インテリジェンス、故障解析など、１つ以上のアプリケーションにより受信されるとよい。このように、イベントバスは、イベントデータをアプリケーションへ送信するとよく、それによって、データを他のデバイスまたは他のアプリケーションに利用可能にしないという「サイロ」問題を回避する。

図１２は、需要応答（ＤＲ）シグナリングプロセスのフロー図１２００を示す。ブロック１２４４にて示されているように、ＤＲが配電動作アプリケーションによりリクエストされるとよい。それに応答して、グリッド状態／接続性は、ブロック１２０２にて示されているように、ＤＲ利用可能性データを収集するとよく、ブロック１２０４にて示されているように、データを送信するとよい。配電動作アプリケーションは、ブロック１２４６にて示されているように、ＤＲ利用可能性最適化を、イベントバスを介して（ブロック１２５４）１つ以上のＤＲ管理システムに配布するとよい。ＤＲ管理システムは、ブロック１２７２にて示されているように、ＤＲ情報および信号を１つ以上の需要家構内へ送信するとよい。この１つ以上の需要家構内は、ブロック１２６６にて示されているように、ＤＲ信号を受信し、ブロック１２６８にて示されているように、ＤＲ応答を送信するとよい。ＤＲ管理は、ブロック１２７４にて示されているように、ＤＲ応答を受信して、ブロック１２７６にて示されているように、動作データバス１４６、請求データベースおよびマーケティングデータベースのうちの１つ、いくつかまたはすべてにＤＲ応答を送信するとよい。ブロック１２８４、１２８８にて示されているように、請求データベースおよびマーケティングデータベースは、応答を受信するとよい。動作データバス１４６も、ブロック１２２６にて示されているように、応答を受信して、ブロック１２２８にて示されているように、ＤＲ応答および利用可能容量をＤＲデータ収集へ送信するとよい。ＤＲデータ収集は、ブロック１２９１にて示されているように、ＤＲ応答および利用可能容量を処理して、そのデータを、ブロック１２９４にて示されているように、動作データバスへ送信するとよい。ブロック１２３０にて示されているように、動作データバスは、ＤＲ利用可能性および応答を受信して、それをグリッド状態／接続性へ送信するとよい。ブロック１２０８にて示されているように、グリッド状態／接続性はデータを受信するとよい。受信されたデータは、グリッド状態データを判断するために使用されるとよく、それが動作データバスを介して（ブロック１２２０）送信されるとよい（ブロック１２０６）。ブロック１２４８にて示されているように、配電動作アプリケーションは、グリッド状態データ（ＤＲ最適化のためのイベントメッセージとして）を受信するとよい。ブロック１２５０にて示されているように、配電動作アプリケーションは、グリッド状態データならびにＤＲ利用可能性および応答を使用して配電最適化を実行し、配電データを生成するとよい。配電データは、ブロック１２２２にて示されているように、動作データバスにより読み出されるとよく、ブロック１２４０にて示されているように、接続性抽出アプリケーションへ送信されるとよい。運用データバスは、データを配電動作アプリケーションへ送信するとよく（ブロック１２２４）、次に配電動作アプリケーションが、１つ以上のＤＲ信号を１つ以上のＤＲ管理システムへ送信するとよい（ブロック１２５２）。イベントバスは、この１つ以上のＤＲ管理システムそれぞれに関して信号を収集して（ブロック１２６０）、ＤＲ信号を各ＤＲ管理システムへ送信するとよい（ブロック１２６２）。次に、ＤＲ管理システムは上記のようにＤＲ信号を処理するとよい。

ブロック１２１４にて示されているように、通信動作ヒストリアンは、データをイベントバスへ送信するとよい。ブロック１２１２にて示されているように、通信動作ヒストリアンはさらに、生成ポートフォリオデータ（ｇｅｎｅｒａｔｉｏｎ ｐｏｒｔｆｏｌｉｏ ｄａｔａ）を送信するとよい。または、Ｖｅｎｔｙｘ（登録商標）などのアプリケーションが、ブロック１２３２にて示されているように、仮想発電所（ＶＰＰ：ｖｉｒｔｕａｌ ｐｏｗｅｒ ｐｌａｎｔ）情報をリクエストするとよい。動作データバスは、ブロック１２１６にて示されているように、ＶＰＰデータを収集して、ブロック１２１８にて示されているように、データをアプリケーションへ送信するとよい。アプリケーションは、ブロック１２３４にて示されているように、ＶＰＰデータを収集して、ブロック１２３６にて示されているように、システム最適化を実行して、ブロック１２３８にて示されているように、イベントバスへＶＰＰ信号を送信するとよい。イベントバスは、ブロック１２５６にて示されているように、ＶＰＰ信号を受信して、ブロック１２５８にて示されているように、ＶＰＰ信号を配電動作アプリケーションへ送信するとよい。その結果、配電動作アプリケーションは、上記のようにイベントメッセージを受信および処理するとよい。

ブロック１２７８にて示されているように、接続抽出アプリケーションは、ブロック１２９０にて示されているようにマーケティングデータベースへ送信される新規需要家データを、抽出するとよい。ブロック１２８０にて示されているように、新規需要家データはグリッド状態／接続性へ送信されるとよく、その結果、ブロック１２１０にて示されているように、グリッド状態接続性は新たなＤＲ接続性データを受信するとよい。

オペレーターは、ブロック１２４２にて示されているように、適切な場合、１つ以上のオーバーライド信号を送信するとよい。オーバーライド信号は、配電動作アプリケーションへ送信されるとよい。オーバーライド信号は、ブロック１２６４にて示されているようにエネルギー管理システム、ブロック１２８２にて示されているように請求データベース、および／またはブロック１２８６にて示されているようにマーケティングデータベースへ送信されるとよい。

上記の通り、ユーティリティグリッド内の様々なデバイスが、ＩＮＤＥ ＣＯＲＥ１２０またはその他何らかのコマンドサイト（ｃｏｍｍａｎｄ ｓｉｔｅ）から生成されるコマンドを介して制御され得る。コマンドは、手動入力を介して生成されてもよく、または自動生成により生じてもよい。ユーティリティグリッド内のデバイスの１つ、いくつかまたはすべてが、特定の形での動作のために１つ以上の個別のコマンドを受信し得る。例えば、需要家構内１７９を監視しているスマート計器１６３は、関連する需要家構内に供給されている電力の切断、接続または調節のための個別のコマンドを受信し得る。センサー１６６および制御１６７などの需要家構内のデバイスが、大型電化製品などの特定のデバイスへの電力を削減するコマンドを受信してもよい。ユーティリティ需要家は、例えば経済的理由、または環境にやさしい負荷制御戦略の一環としてなど、様々な理由から、特定の大型電化製品または他の電動デバイスに関して、電力の削減に合意することもある。典型的には、各デバイスがより多くの電力またはより少ない電力を消費するよう個別に切断、循環または制御されるよう調節しても、ユーティリティグリッドの動作に大きな影響はもたらさない。しかし、十分に短い時間ウィンドウ内に十分な数のデバイスがそのように制御されると、同時に、または比較的近い時間に動作するデバイスすべての複合効果が、グリッドの不安定性を発生または増大させるなどの望ましくない影響をユーティリティグリッドにもたらすことがあり得る。例えば、比較的短い時間ウィンドウ内に、いくつかの需要家構内１７９にわたって、十分な数の需要家構内デバイスがオフにするよう命令されると、この電力の削減により広域停電が発生しかねない。この種の問題は、不注意または偶然によるコマンド入力によって、または悪意のある活動によって生じ得るであろう。

図１３は、ユーティリティグリッド内の様々なデバイスを制御するために生成されたコマンドをフィルタリングするよう構成されたコマンドフィルタモジュール１３００を含む、コマンドフィルタシステムの例である。コマンドフィルタモジュール１３００は、ユーティリティグリッド内のデバイスによって受信される一部または全部のコマンドを受信し、デバイスでの受信に先立って、コマンドの実行がユーティリティグリッド内に望ましくない影響をもたらすと考えられるかどうかを判断するとよい。コマンドフィルタモジュール１３００は、コマンドの一部または全部を実行に関して許可して、実行のために個々のデバイスによって受信されるよう、許可されたコマンドを伝送してもよく、または許可されないコマンドが実行のために個々のデバイスによって受信されるのを防いでもよい。

一例では、コマンドフィルタモジュール１３００は、メモリ１３０４と通信しているプロセッサ１３０２を有する１つ以上のコンピュータデバイス１３０１上で実行されてもよい。「モジュール」という用語は、１つまたは複数の実行可能モジュールを含むよう定義され得る。本願明細書に記載のように、モジュールは、プロセッサ１３０２によって実行可能なソフトウェア、ハードウェアまたはその何らかの組み合わせを含むよう定義される。ソフトウェアモジュールは、メモリ１３０４またはその他のメモリデバイスに記憶され、プロセッサ１３０２またはその他のプロセッサによって実行可能な命令を含むとよい。ハードウェアモジュールは、プロセッサ１３０２による実行のために実行可能であり、かつ／または指示され、かつ／または制御される様々なデバイス、コンポーネント、回路、ゲート、回路基板および同様のものを含むとよい。メモリ１３０４は、１つ以上のメモリを含むとよく、キャッシュ、バッファ、ＲＡＭ、取り外し可能媒体、ハードドライブまたはその他のコンピュータ可読記憶媒体などのコンピュータ可読記憶媒体またはメモリであればよい。コンピュータ可読記憶媒体は、様々なタイプの揮発性および不揮発性記憶媒体を含み得る。例えば多重処理、多重タスキング、並列処理および同様のものなど、様々な処理技術が、プロセッサ１３０２によって実装され得る。プロセッサ１３０２は、１つ以上のプロセッサを含むとよい。

一例では、コマンドフィルタモジュール１３００は、メモリ１３０４上に記憶されプロセッサ１３０２によって実行される１つ以上のソフトウェアモジュールであってもよい。コマンドフィルタモジュール１３００は、プロセッサ１３０２によって実行される様々なサブモジュールを含むとよい。プロセッサ１３０２は、ＩＮＤＥ ＣＯＲＥ１２０、またはユーティリティグリッド内の他の何らかのサイト内に位置するとよい。一例では、コマンドフィルタモジュール１３００は、イベントバス１４７上で動作するよう実行されてもよい。

コマンドフィルタモジュール１３００は、ユーティリティグリッド内のデバイスの動作を制御することを目的としたコマンド１３０６を受信するとよい。コマンド１３０６は、同時に、または或る所定の時間ウィンドウ内に、個々のデバイスによって実行されるよう意図されたコマンドを表すとよい。例えば、コマンド１３０６は、センサー１６６、制御１６７または家庭内ディスプレイ１６５に接続された、需要家構内１７９の中のデバイスにより受信されるよう意図されたものであってもよい。

以下、図１４を参照する。リアルタイム複合イベント処理バス１４７上で実行されるよう構成されたコマンドフィルタモジュール１３００の例が示されている。図１４の例は、図１〜６に関して記載されたＩＮＤＥアーキテクチャにおいて実装されるとよい。図１４に示されているように、ユーティリティグリッド内の様々なデバイスが、手動制御を介して実装され得る。例えば、スマート計器ネットワーク１７８内の様々なスマート計器１６３によって受信される、計器接続／切断コマンドなどの計器コマンド（「ＭＣ：ｍｅｔｅｒ ｃｏｍｍａｎｄ」）１４０４を伝送するために、グラフィカルユーザインターフェース（ＧＵＩ：ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅ）１４０２がオペレーターによって使用されてもよい。計器コマンド１４０４は、スマート計器１６３から受信された計器データ１４０５を伝送することができるデバイスを経由して伝達されてもよい。ＧＵＩ１４０２は、計器コマンド１４０４を計器データ管理システム１２１へ伝送するとよい。続いて、計器コマンド１４０４は、計器データ収集エンジン１４０６によって受信されるとよく、計器データ収集エンジン１４０６は、ユーティリティシステム内のスマート計器１６３に関するデータ、コマンド、イベントおよびその他任意のデータを収集するよう構成されたソフトウェアモジュール、ハードウェアモジュールまたは組み合わせであるとよい。一例では、計器データ収集エンジン１４０６は、計器データ収集ヘッドエンド（単数または複数）１５３上に存在するとよい。別の例では、計器データ収集エンジン１４０６は、ユーティリティグリッド内に複数の計器データ収集エンジン１４０６が存在するよう、分散していてもよい。計器データ収集エンジン１４０６によって収集されたデータは、運用／非運用データバス１４６上で伝達され、１つ以上の計器データリポジトリ１３３へ伝送されて、それにより記憶されるとよい。

計器コマンド１４０４は、イベントバス１４７およびコマンドフィルタモジュール１３００によって受信されるとよい。コマンドフィルタモジュール１３００は、計器コマンド１４０４を分析して、そのコマンドが、実行されると、ユーティリティグリッド内で望ましくない影響を発生させる可能性があるかどうかを判断するとよい。コマンドフィルタモジュール１３００は、個々のスマート計器１６３によって受信および実行されるよう、許可された計器コマンド（「ＡＭＣ：ａｕｔｈｏｒｉｚｅｄ ｍｅｔｅｒ ｃｏｍｍａｎｄ」）１４０７を伝送するとよい。許可された計器コマンド１４０７は、計器コマンドプロセッサ１４０８へ伝送されるとよい。計器コマンドプロセッサ１４０８は、許可された計器コマンド１４０７の内容および意図された受信先を判断するとよい。計器コマンドプロセッサ１４０８は、コマンドを計器通信ネットワーク１４１０へ伝送するとよい。計器通信ネットワーク１４１０は、計器データ、計器イベントおよび計器コマンドを、ユーティリティグリッド内でスマート計器ネットワーク１７８に結合された全部または一部のスマート計器１６３へ伝送するよう構成されているとよい。許可された計器コマンド１４０７は、接続またはユーティリティグリッドからの切断のために、需要家構内１７９のスマート計器１６３によって最終的に受信されるとよい。ＧＵＩ１４１１は、計器データ収集エンジン１４０６に直接伝送される計器コマンド１４０４を受信してもよい。

様々な需要家構内デバイスが、コマンドフィルタモジュール１３００によって許可されるＤＲコマンド（「ＤＲＣ：ＤＲ ｃｏｍｍａｎｄ」）１４１２を受信し得る。例えば、ＤＲコマンド１４１２を手動で入力するために、ＧＵＩ１４１４がオペレーターによって使用されてもよい。ＤＲコマンド１４１２は、ＶＰＰ給電指令システム１４１６によってＧＵＩ１４１４から受信されるとよい。ＤＲコマンド１４１２は、価格設定、環境要因および負荷制御など、考慮すべき様々な事項に基づくとよい。ＶＰＰ給電指令システム１４１６は、ＤＲコマンド１４１２を受信して、ＤＲコマンド１４１２に基づき制御される需要家構内デバイスを判断するよう構成されているとよい。ＤＲコマンド１４１２は、動作／非動作データバス１４６によって受信されるとよい。他の例では、ＤＲコマンド１４１２は、ＶＰＰ給電指令システム１４１６からイベントバス１４７へ伝送されてもよい。

ＤＲコマンド１４１２は、ＤＲ信号分配・ＤＲ応答データ収集エンジン（ＤＣＥ）システム１４１８によって、動作／非動作データバス１４６から受信されるとよい。ＤＲ信号分配・ＤＲ応答データ収集エンジン１４１８は、ＤＲ管理システム１５４内など、ＩＮＤＥ ＣＯＲＥ１２０内で、またはユーティリティグリッド内もしくはユーティリティグリッドから離れた他の何らかのサイトにて動作するよう構成され得る。ＤＲコマンド１４１２は、ＤＲ信号分配・ＤＲ応答ＤＣＥシステム１４１８によって分析されて、コマンドを受信する特定のデバイスの判断など、望まれる需要応答がどのように実行されるべきかが判断されるとよい。ＤＲ信号分配・ＤＲ応答ＤＣＥシステム１４１８は、ＤＲコマンド１４１２を、個別のデバイスまたは従属するデバイスグループ用に分割するとよい。

続いて、ＤＲコマンド１４１２は、イベントバス１４７およびコマンドフィルタモジュール１３００によって受信されて、ＤＲコマンド１４１２が、需要家構内１７９の中のデバイスによる実行を許可されるかどうかが判断されるとよい。ＤＲコマンド１４１２が、需要家構内１７９の中のデバイスによって実行される場合、許可されたＤＲコマンド（「ＡＤＲＣ：ａｕｔｈｏｒｉｚｅｄ ＤＲ ｃｏｍｍａｎｄ」）１４１７が、コマンドフィルタモジュール１３００によってＤＲコマンドプロセッサ１４２０へ伝送されるとよい。ＤＲコマンドプロセッサ１４２０は、許可されたＤＲコマンド１４１７の内容を判断して、許可されたＤＲコマンド１４１７を受信する、特定の需要家構内１７９および特定の需要家構内１７９の中のデバイスを特定するとよい。許可されたＤＲコマンド１４１７は、ユーティリティグリッド内の需要家構内１７９の全部または一部と相互接続されているとよいＤＲ通信ネットワーク１４２２に、ＤＲコマンドプロセッサ１４２０によって伝送されるとよい。許可されたＤＲコマンド１４１７は、各需要家構内１７９の中の意図されたデバイスによって受信されるとよく、ホームＤＲゲートウェイ１４２１によって分配されるとよい。

スイッチングコマンドなどの他のタイプのコマンドが、ユーティリティグリッドに手動で入力されてもよい。例えば、スイッチングコマンド（「ＳＣ：ｓｗｉｔｃｈｉｎｇ ｃｏｍｍａｎｄ」）１４２４が、オペレーターによってＧＵＩ１４２５を用いて入力されてもよい。一例では、スイッチングコマンド１４２４は、例えばセクショナライザー、リクローザーおよびインタータイなどのユーティリティグリッド内のスイッチングデバイス（ｓｗｉｔｃｈｉｎｇ ｄｅｖｉｃｅ）１４３６を接続または切断することを目的としてもよい。スイッチングコマンド１４２４は、セクショナライザー制御１４２６によって受信されるとよく、セクショナライザー制御１４２６は、スイッチングコマンド１４２４を処理して、スイッチングコマンドを実行するよう動作させられるとよいユーティリティグリッド内の特定のデバイスを判断するよう構成されているとよい。スイッチングコマンド１４２４は、イベントバス１４７によって受信されコマンドフィルタモジュール１３００によって処理されるとよい。許可されたスイッチングコマンド（「ＡＳＣ：Ａｕｔｈｏｒｉｚｅｄ ｓｗｉｔｃｈｉｎｇ ｃｏｍｍａｎｄ」）１４３０は、１つ以上の制御コマンドプロセッサ１４３４へ伝送されるとよい。制御コマンドプロセッサ１４３４は、許可されたスイッチングコマンド１４３０を、特定の許可されたスイッチングコマンド１４３０を受信するよう意図された個々のスイッチングデバイス１４３６へ伝送するとよい。

補償器コマンド（「ＣＣ：Ｃｏｍｐｅｎｓａｔｏｒ ｃｏｍｍａｎｄ」）１４２７が、オペレーターによってＧＵＩ１４２９を用いて入力されてもよい。補償器コマンド１４２７は、例えばコンデンサ、線路電圧降下補償器、負荷タップ切替器（ＬＴＣ：ｌｏａｄ ｔａｐ ｃｈａｎｇｅｒ）および電圧調整器など、ユーティリティグリッドの諸条件を補償するために使用されるデバイスによって受信されるよう意図されているとよい。補償器コマンド１４２７は、補償器制御１４３１によって受信されるとよく、補償器制御１４３１は、補償器コマンド１４２７の内容を判断し、補償器コマンド１４２７を受信するよう意図された特定の補償器デバイス（ｃｏｍｐｅｎｓａｔｏｒ ｄｅｖｉｃｅ）による受信のために補償器コマンド１４２７を整形するよう構成されている。補償器コマンド１４２７は、コマンドフィルタモジュール１３００により処理されるようイベントバス１４７へ、補償器制御１４３１によって伝送されるとよい。許可された補償器コマンド（「ＡＣＣ：Ａｕｔｈｏｒｉｚｅｄ ｃｏｍｐｅｎｓａｔｏｒ ｃｏｍｍａｎｄ」）１４３２は、制御コマンドプロセッサ１４３４へ伝送されるとよい。制御コマンドプロセッサ１４３４は、許可された補償器コマンド１４３２を、意図された補償器デバイス１４３８に提供するとよい。

再び図１３を参照する。コマンドフィルタモジュール１３００の詳細な動作についてさらに説明することができる。コマンド１３０６は、計器コマンド１４０４、ＤＲコマンド１４１６、スイッチングコマンド１４２４および補償器コマンド１４２７などのデバイスコマンドを含むとよい。コマンド１３０６は、コマンドフィルタモジュール１３００によって受信されると、コマンド受信モジュール１３０８によって受信されるとよい。コマンド受信モジュール１３０８は、コマンド１３０６を処理して、コマンド１３０６それぞれの望まれる受信先の内容を判断するとよい。コマンド受信モジュール１３０８は、処理されたコマンド１３１０をルール適用モジュール１３１２に提供するとよい。処理されたコマンド１３１０は、コマンド受信モジュール１３０８によって実行された処理、コマンド１３０６の再フォーマッティングまたは両方に関する追加データを含むとよい。

処理されたコマンド１３１０を受信すると、ルール適用モジュール１３１２は、所定の一連のルールを、処理されたコマンド１３１０に適用して、実行されるべきコマンド１３０６があればそれを許可するとよい。ルール適用モジュール１３１２は、処理されたコマンド１３１０に適用される１つ以上のルールを含むルールデータセット１３１４を読み出すとよい。ルールの適用に基づき、ルール適用モジュール１３１２は、処理されたコマンド１３１０のうちのどのコマンド１３０６が、実行に関して許可されるかを判断するとよい。ルール適用モジュール１３１２は、処理されたコマンド１３１０の一部を実行に関して許可してもよく、またはルール適用モジュール１３１２によって分析されているコマンドのすべてがまとめて許可または拒否されるよう、処理されたコマンド１３１０の許可を一括で行ってもよい。

許可の後、ルール適用モジュール１３１２は、ルール適用モジュール１３１２の許可決定とともにコマンド１３０６を含む許可データセット１３１６を生成するとよい。許可データセット１３１６は、コマンド伝送モジュール１３１８によって受信されるとよい。コマンド伝送モジュール１３１８は、個々のデバイスによる実行に関して許可されたコマンドの１つ、いくつか、またはすべてを特定するとよい。特定すると、コマンド伝送モジュール１３１８は、意図されたデバイスに最終的に受信されるよう、許可されたコマンド１３２０を伝送するとよい。実行の許可をされないコマンドに関して、コマンド伝送モジュール１３１８は、ＧＵＩ１４０２、１４１１、１４１４および１４２５のうちの１つなど、許可されないコマンドが生じたところへ通知のために返送される、許可されないコマンドそれぞれの拒否メッセージ１３２１を生成するとよい。一例では、コマンドフィルタモジュール１３００は、イベントバス１４７上で実行されてもよく、これによりコマンドフィルタモジュール１３００は、許可されたコマンド１３２０を伝送すること、またはイベントバス１４７が伝送を実行することを可能にすることができる。

ルールデータセット１３１４に含まれるルールは、静的な性質であってもよく、またはユーティリティグリッド内のリアルタイム条件に基づき動的であってもよい。静的ルールは、現在のユーティリティグリッドの例と関係なく不変であってもよい。例えば、スマート計器１６３、需要家構内１７９の中のデバイス、スイッチングデバイス１４３６もしくは補償器デバイス１４３８または任意の組み合わせなど、所定の時間ウィンドウ内に接続または切断されてよいデバイスの数を制限する、静的ルールが存在してもよい。一例では、ルールは、１時間当たり６の起動など、需要家構内デバイス（例えば工業用ポンプ）が起動されてよいインスタンスの数を制限することを対象にしてもよい。別の例では、ルールは、所定の時間内にオンまたはオフにしてよいスマート計器１６３の数を制限することを対象にしてもよい。デバイスが接続または切断されるよう命令されてよい期間に関する他のルールが適用されてもよい。

ルール適用モジュール１３１２はさらに、ルールデータセット１３１４のルールを、ユーティリティグリッドの動的な性質に配慮して適用するよう構成されてもよい。ルール適用モジュール１３１２は、ユーティリティグリッドの過去の動作データを調べるよう構成されてもよい。一例では、ルール適用モジュール１３１２は、過去データ１３６から情報を読み出すよう構成されてもよい。ルール適用モジュール１３１２は、過去データ１３６を相互参照しながら、ルールデータセット１３１４からのルールを、処理されたコマンド１３１０に適用してもよい。例えば、ルールデータセット１３１４は、特定のデバイスに関係なくデバイス切断／接続の数に基づくルールを含んでもよい。例えば、関与するデバイスに関係なく、所定のデバイス数のみが、所定の時間内に切断または接続されることが認められてもよい。コマンド１３０６が、デバイス数閾値よりも多くのデバイスを切断または接続することを対象にしていれば、コマンドフィルタモジュール１３００は、過去データ１３６を分析して、コマンド１３０６のパターンなどの以前のコマンドパターンが、ユーティリティグリッド内で望ましくない影響をもたらしたかどうかを判断してもよい。過去データに基づき、コマンドが対応する特定のデバイスの接続または切断が、以前にユーティリティグリッドにおいて不都合な問題を発生させていなければ、コマンドは実行に関して許可されるとよい。

動的条件を使用するルール適用構成では、ルール適用モジュール１３１２はさらに、ルールの適用中、接続性データマート１３１から接続性データ１３１３を読み出すとよい。過去データ１３６、接続性データ１３１およびルールデータセット１３１４に基づき、ルール適用モジュール１３１２は、実行に関してコマンド１３０６が許可されてはならないほどの望ましくない影響を現在のユーティリティグリッド条件が受けるかどうかを判断するとよい。一例では、ルール適用モジュール１３１２は、過去データ１３６、接続性データ１３１３およびルールデータセット１３１４に基づきコマンドの許可を判断するために、予測モジュール１３２２を含んでもよい。予測モジュール１３２２は、コマンドの一部または全部の許可によるユーティリティグリッドへの影響を予測するとよい。予測モジュール１３２２は、コマンド１３０６の組み合わせの様々な順列に基づき、ユーティリティグリッドの挙動に関して予測される影響を生成するとよい。一例では、予測モジュール１３２２は、実行される最多数のコマンド１３０６として特定されるコマンド１３０６の組み合わせを、許可のために選択してもよい。他の例では、予測モジュール１３０６は、グリッド障害閾値に最も近く、かつそれ未満であるなどの他の考慮事項に基づいて、コマンド１３０６を特定してもよい。グリッド障害閾値は、コマンド１３０６などのデバイスコマンドを実行するときに、ユーティリティグリッドに対し許容される最小の障害を表してもよい。別の構成では、静的または動的な種々の条件が監視されて、コマンド１３０６に関して許可決定が実行されてもよい。例えば、電圧条件、電流条件または両方が、ユーティリティグリッドの戦略上重要な部分で監視されてもよい。周囲温度などの環境条件も監視されてもよい。

構成済みユーティリティグリッドは、スマートデバイスが後付けされるとき、種々の通信アクセスポイントを有することもある。構成済みユーティリティグリッドはさらに、図１４に関して記載されたものとは異なる確立した通信ネットワークを含むこともある。図１５〜１７は、代わりの通信ネットワーク構成を有するユーティリティグリッドの例を示す。図１５〜１７では、コマンドフィルタモジュール１３００は、例えば接続／切断コマンドを受信するよう構成されたデバイスに対してユーティリティグリッド内の種々の部分で実行され得る。図１５では、図１の構成に似たユーティリティグリッド１５００が、ＤＲ通信ネットワークおよび計器通信ネットワークなどの分散型通信ネットワークの代わりに、単一の通信ネットワークバス１５０２を用いて構成されるとよい。図１５では、コマンドフィルタモジュール１３００は、通信ネットワークバス１５０２上で動作するよう実行されるとよい。図１５の構成は、初期のコマンドが、コマンドフィルタモジュール１３００への到達前は同様に処理されてよいという点で、図１３に類似している。しかし、コマンドモジュール１３００は、許可判断を提供すると、許可された計器コマンド１４０７を直接特定のスマート計器１６３へ、許可されたＤＲコマンド１４１７を需要家構内１７９のデバイスへ、許可されたスイッチングコマンド１４３０をスイッチングデバイス１４３６へ、さらに許可された補償器コマンド１４３２を補償器デバイス１４３８へ伝送するとよい。通信ネットワークバス１５０２は、コマンドフィルタモジュール１３００を実行するためのみではなく、許可されたコマンドを実行されるよう個々のデバイスに向けて送るために、コマンドフィルタモジュール１３００と対話するよう構成されているとよい。

図１６は、ユーティリティグリッド１６００の略図である。ユーティリティグリッド１６００内に、単一の通信ネットワークバス１６０２が実装されるとよい。通信ネットワークバス１６０２は、サードパーティプロバイダによって実装されても、ユーティリティグリッド１６００に含まれてもよい。イベントバス１４７は、通信ネットワークバス１６０２と通信するとよい。イベントバス１４７は、コマンドフィルタモジュール１３００を実行して、コマンド１４０４、１４１２、１４２４および１４２７を受信するとよい。許可されたコマンド１４０７、１４１７、１４３０および１４３２が、通信ネットワークバス１６０２によって、様々なデバイスコマンドを受信するよう意図された様々なデバイスに分配されるとよい。通信ネットワークバス１６０２は、許可されたコマンドの意図される受信先を認識し、それに応じて、許可されたコマンドを伝送するとよい。

図１７は、ユーティリティグリッド１７００の略図である。ユーティリティグリッド１７００では、分散型イベントバスが使用される。分散型イベントバスは、イベントバス１７０２、１７０４および１７０６を含むとよく、これらはそれぞれ、イベントバス１４７に関して記載したのと類似した形で機能するとよい。１つの違いは、分散型イベントバス１７０２、１７０４および１７０６は、互いに通信していないということである。図１７では、イベントバス１７０２は、計器コマンド１４０４およびＤＲコマンド１４１２に対してコマンドフィルタモジュール１３００を実行するよう構成されている。計器コマンド１４０４は、図１３に関して記載されたような形で、コマンドフィルタモジュール１３００によって処理されるとよい。許可された計器コマンド１４０７は、計器データ収集エンジン１４０６へ伝送されるとよく、計器データ収集エンジン１４０６は、コマンドを計器通信ネットワーク１４１０へ伝送するとよい。許可された計器コマンド１４０７は、計器通信ネットワーク１４１０によって、意図されたスマート計器１６３へ伝送されるとよい。同様に、イベントバス１７０４も、ＧＵＩ１４１１から計器コマンド１４０４を受信するとよい。イベントバス１７０４のコマンドフィルタモジュール１３００は、計器コマンド１４０４を許可して、許可された計器コマンド１４０７を、計器データ収集エンジン１４０６へ伝送するとよい。

許可されたＤＲコマンド１４１７は、ＤＲ信号分配・ＤＲ応答ＤＣＥ１４１８へ伝送されるとよい。ＤＲ信号分配・ＤＲ応答ＤＣＥ１４１８は、許可されたＤＲコマンド１４１７を、結果としてホームＤＲゲートウェイ１４２１を介し関連した需要家構内デバイスへ伝送されるよう、ＤＲ通信ネットワーク１４２２へ伝送するとよい。スイッチングコマンド１４２４および補償器コマンド１４２７は、イベントバス１７０６によって受信されコマンドフィルタモジュール１３００によってフィルタリングされるとよい。許可されたスイッチングコマンド１４３０および許可された補償器コマンド１４３２は、制御コマンドプロセッサ１４２７へ伝送され、続いて、関連したデバイスへルーティングされるとよい。

図１８は、コマンドフィルタモジュール１３００の動作フローの例である。コマンドフィルタモジュール１３００は、コマンド１３０６などのデバイスコマンドを受信するとよい（ブロック１８００）。コマンドフィルタモジュール１３００は、受信されたコマンドが無効かどうかを判断するとよい（ブロック１８０２）。コマンド１３０６のうちの１つ以上が無効であれば、コマンドフィルタモジュール１３００は、後のデバイスコマンドの受信のために監視を行うとよい。別の例では、コマンドフィルタモジュール１３００は、無効と見なされたコマンド１３０６の各コマンドに関して、無効メッセージを生成するとよい。無効メッセージは、コマンドを入力するために使用されたＧＵＩなど、コマンドのソースへ、コマンドフィルタモジュール１３００によって伝送されるとよい。コマンド受信モジュール１３０８など、コマンドフィルタモジュール１３００のサブモジュールが、無効メッセージを生成するとよい。

コマンドフィルタモジュール１３００は、有効コマンド１３０６それぞれの内容を判断するとよい（ブロック１８０４）。判断は、コマンド受信モジュール１３０８によって実行されてもよい。有効コマンド１３０６の内容が判断されると、コマンドフィルタモジュール１３００は、関連した過去データを、過去データ１３６から読み出すとよい（ブロック１８０６）。コマンドフィルタモジュール１３００はさらに、関連した接続性データ１３１３を、接続性データデータマート１３１から読み出すとよい（ブロック１８０８）。接続性データ１３１３を受信すると、ルール適用モジュール１３１２は、コマンド１３０６の実行による起こり得る影響を判断するために、予測モジュール１３２２を実行するとよい（ブロック１８１０）。

ルール適用モジュール１３１２は、予測された結果がルールのいずれかに違反するかどうかを判断するために、ルールデータセット１３１４からの関連したルールを適用するとよい（ブロック１８１２）。すべてのコマンド１３０６を許可する決定（ブロック１８１４）が、ルール適用モジュール１３１２によって実行されてもよい。すべてのコマンド１３０６が許可されれば、コマンド１３０６は、個々のデバイスによって受信されるようコマンド伝送モジュール１３１８によって伝送されるとよい（ブロック１８１６）。すべてのコマンド１３０６が許可されなければ、コマンドの一部が許可されるかどうかを判断するために、決定が下されるとよい（ブロック１８１８）。コマンド１３０６がいずれも許可されなければ、拒否メッセージ１３２１が、コマンド伝送モジュール１３２０によって生成され（ブロック１８２０）、個々のコマンド１３０６の発信ソースへ伝送されるとよい。コマンド１３０６の一部が許可される場合、許可されないコマンド１３０６に関して拒否メッセージ１３２１がコマンド伝送モジュール１３１８によって伝送されるとよく（ブロック１８２２）、許可されたコマンドが、個々のデバイスによって受信されるよう伝送されるとよい。

本発明は、好適な実施形態に関連して示され記載されてきたが、上記のものに加えて、本発明の基本的特徴から、特定の変更および改変が行われてよいということは明らかである。さらに、本発明の実践に利用され得る異なるタイプのコンピュータソフトウェアおよびハードウェアは多数あり、本発明は上述の例に制限されない。本発明は、１つ以上の電子デバイスにより実行される機能、および動作の記号表現を参照して記載された。よって、当然のことながら、そのような機能および動作は、構造化形式でデータを表現する電気信号の、電子デバイスの処理ユニットによる操作を含む。この操作は、データを変換するか、または電子デバイスのメモリシステムの各位置にデータを保持し、これが、当業者には十分理解される形で電子デバイスの動作を再構成、または他の形で変更する。データが保持されるデータ構造は、データのフォーマットにより定義される特定の特性を有するメモリの物理的位置である。本発明は前述の文脈において記載されているが、当業者には当然のことながら、記載された機能および動作はハードウェアに実装されることも可能であるため、制限的なものとして意図されてはいない。したがって、本発明の有効な範囲内の変形および変更すべてを保護することが出願人の意図である。本発明は、以下の特許請求の範囲によって定義され、すべての等価物を含むものとする。

Claims (19)

1. 複数のデバイスコマンドルールを記憶するよう構成されたメモリと、
   前記メモリ上に記憶されたコマンドフィルタモジュールと、
   を含むユーティリティグリッドコマンドフィルタシステムであって、前記コマンドフィルタモジュールは、
   個々の発信デバイスからそれぞれ受信される複数のコマンドであって、ユーティリティグリッドに電気的に結合された個々のデバイスに対してコマンドを提供するようそれぞれ構成されている、前記複数のコマンドを受信し、
   前記複数のデバイスコマンドルールから少なくとも１つのデバイスコマンドルールを読み出し、
   前記少なくとも１つのデバイスコマンドルールに基づき、前記複数のコマンドのうちの少なくとも１つのコマンドが前記個々のデバイスによる実行に関して許可される場合を判断し、
   前記少なくとも１つのコマンドが前記個々のデバイスによる実行に関して許可されると判断されると、前記個々のデバイスによって受信されるよう前記少なくとも１つのコマンドを伝送するよう、
   プロセッサによって実行可能である、ユーティリティグリッドコマンドフィルタシステム。
2. 前記コマンドフィルタモジュールは、前記少なくとも１つのコマンドが前記個々のデバイスによる実行に関して許可されないと判断されると、前記個々の発信デバイスによって受信されるよう構成された拒否メッセージを生成するようさらに実行可能であり、前記拒否メッセージは、前記少なくとも１つのコマンドが前記個々のデバイスによる実行に関して許可されないことを示す、請求項１に記載のユーティリティグリッドコマンドフィルタシステム。
3. 前記コマンドフィルタモジュールは、
   前記少なくとも１つのコマンド個々に対するデバイスの動作に対応するユーティリティグリッド過去データを読み出し、
   前記ユーティリティグリッド過去データに前記基づくことにより、前記複数のコマンドのうちの少なくとも１つのコマンドが実行に関して許可される場合を判断するよう、さらに実行可能である、請求項１に記載のユーティリティグリッドコマンドフィルタシステム。
4. 前記コマンドフィルタモジュールは、
   前記ユーティリティグリッドの現在の動作条件に対応するユーティリティグリッド接続性データを読み出し、
   前記ユーティリティグリッド接続性データに基づき、前記複数のコマンドのうちの少なくとも１つのコマンドが前記デバイスによる実行に関して許可される場合を判断するよう、さらに実行可能である、請求項３に記載のユーティリティグリッドコマンドフィルタシステム。
5. 前記コマンドフィルタモジュールは、
   前記ユーティリティグリッド過去データおよび前記ユーティリティグリッド接続性データに基づき、前記少なくとも１つのコマンドの許可からの、予測される少なくとも１つのユーティリティグリッド影響を判断し、
   前記予測される少なくとも１つの影響に基づき、前記複数のコマンドのうちの少なくとも１つのコマンドが前記デバイスによる実行に関して許可される場合を判断するよう、さらに実行可能である、請求項４に記載のユーティリティグリッドコマンドフィルタシステム。
6. 前記少なくとも１つのデバイスコマンドルールは、最小ユーティリティグリッド障害閾値であり、前記コマンドフィルタモジュールは、前記予測される影響が前記最小ユーティリティグリッド障害閾値未満であれば、前記複数のコマンドのうちの前記少なくとも１つのコマンドが前記デバイスによる実行に関して許可される場合であると判断するよう、さらに実行可能である、請求項５に記載のユーティリティグリッドコマンドフィルタシステム。
7. 前記少なくとも１つのデバイスコマンドルールは、デバイス接続を、所定の時間内に所定のデバイス数に制限することを含む、請求項１に記載のユーティリティグリッドコマンドフィルタシステム。
8. 前記少なくとも１つのデバイスコマンドルールは、デバイスの再起動を、所定の時間内に所定の回数に制限することを含む、請求項１に記載のユーティリティグリッドコマンドフィルタシステム。
9. 電気的に結合された複数のデバイスと、
   個々の発信デバイスからそれぞれ受信される複数のコマンドであって、前記複数のデバイスのうちの個々のデバイスにコマンドを提供するようそれぞれ構成されている、前記複数のコマンドを受信し、
   複数のデバイスコマンドルールから少なくとも１つのデバイスコマンドルールを読み出し、
   前記少なくとも１つのデバイスコマンドルールに基づき、前記複数のコマンドのうちの少なくとも１つのコマンドが前記個々のデバイスによる実行に関して許可される場合を判断し、
   前記少なくとも１つのコマンドが前記個々のデバイスによる実行に関して許可されると判断されると、前記個々のデバイスによって受信されるよう前記少なくとも１つのコマンドを伝送するよう構成されたコマンドフィルタシステムと、
   前記少なくとも１つのコマンドを、前記コマンドフィルタシステムから前記個々のデバイスへ中継するよう構成された通信ネットワークと、
   を含むユーティリティグリッド。
10. 前記ユーティリティグリッドは、
    前記コマンドフィルタシステムを実行するよう構成されたイベントバス
    をさらに含み、
    前記複数のデバイスは、前記ユーティリティグリッド内で第１の所定の機能を有する第１のデバイスと、前記ユーティリティグリッド内で第２の所定の機能を有する第２のデバイスとを含み、前記第２の所定の機能は、前記第１の所定の機能と異なり、
    前記少なくとも１つのコマンドは、第１のコマンドおよび第２のコマンドを含み、前記第１のコマンドは、前記第１のデバイスに対応し、前記第２のコマンドは、前記第２のデバイスに対応し、
    前記通信ネットワークは、第１の通信サブネットワークおよび第２の通信サブネットワークを含み、
    前記コマンドフィルタシステムは、
    前記少なくとも１つのデバイスコマンドルールに基づき、前記第１のコマンドが前記第１のデバイスによる実行に関して許可される場合を判断し、
    前記少なくとも１つのデバイスコマンドルールに基づき、前記第２のコマンドが前記個々のデバイスによる実行に関して許可される場合を判断するよう構成されており、
    前記第１の通信サブネットワークは、前記第１のコマンドが実行に関して許可されると、前記第１のデバイスコマンドを前記第１のデバイスへ中継するよう構成されており、
    前記第２の通信サブネットワークは、前記第２のコマンドが実行に関して許可されると、前記第２のコマンドを前記第２のデバイスへ中継するよう構成されている、
    請求項９に記載のユーティリティグリッド。
11. 前記複数のデバイスは、前記ユーティリティグリッド内で第１の所定の機能を有する第１のデバイスと、前記ユーティリティグリッド内で第２の所定の機能を有する第２のデバイスとを含み、前記第２の所定の機能は、前記第１の所定の機能と異なり、
    前記少なくとも１つのコマンドは、第１のコマンドおよび第２のコマンドを含み、前記第１のコマンドは、前記第１のデバイスに対応し、前記第２のコマンドは、前記第２のデバイスに対応し、
    前記コマンドフィルタシステムは、
    前記少なくとも１つのデバイスコマンドルールに基づき、前記第１のコマンドが前記第１のデバイスによる実行に関して許可される場合を判断し、
    前記少なくとも１つのデバイスコマンドルールに基づき、前記第２のコマンドが前記個々のデバイスによる実行に関して許可される場合を判断するよう構成されており、
    前記通信ネットワークは、通信ネットワークバスを含み、前記コマンドフィルタシステムは、前記通信ネットワークバス上で実行されるよう構成されており、
    前記通信ネットワークバスは、前記第１のコマンドが実行に関して許可されると、前記第１のデバイスコマンドを前記第１のデバイスへ中継するよう構成されており、
    前記通信ネットワークバスは、前記第２のコマンドが実行に関して許可されると、前記第２のコマンドを前記第２のデバイスへ中継するよう構成されている、
    請求項９に記載のユーティリティグリッド。
12. 前記ユーティリティグリッドは、
    前記コマンドフィルタシステムを実行するよう構成されたイベントバス
    をさらに含み、
    前記複数のデバイスは、前記ユーティリティグリッド内で第１の所定の機能を有する第１のデバイスと、前記ユーティリティグリッド内で第２の所定の機能を有する第２のデバイスとを含み、前記第２の所定の機能は、前記第１の所定の機能と異なり、
    前記少なくとも１つのコマンドは、第１のコマンドおよび第２のコマンドを含み、前記第１のコマンドは、前記第１のデバイスに対応し、前記第２のコマンドは、前記第２のデバイスに対応し、
    前記コマンドフィルタシステムは、
    前記少なくとも１つのデバイスコマンドルールに基づき、前記第１のコマンドが前記第１のデバイスによる実行に関して許可される場合を判断し、
    前記少なくとも１つのデバイスコマンドルールに基づき、前記第２のコマンドが前記個々のデバイスによる実行に関して許可される場合を判断するよう構成されており、
    前記通信ネットワークは、
    前記第１のコマンドが実行に関して許可されると、前記イベントバスから、前記第１のデバイスへの前記第１のデバイスコマンドを受信し、
    前記第２のコマンドが実行に関して許可されると、前記イベントバスから、前記第２のデバイスへの前記第２のコマンドを受信し、
    前記受信された第１のコマンドを前記第１のデバイスへ、前記受信された第２のコマンドを前記第２のデバイスへ中継するよう構成された通信バスを含む、
    請求項９に記載のユーティリティグリッド。
13. 前記ユーティリティグリッドは、
    第１のイベントバスおよび第２のイベントバス
    をさらに含み、
    前記コマンドフィルタシステムは、第１のコマンドフィルタシステムおよび第２のコマンドフィルタシステムを含み、前記第１のコマンドフィルタシステムは、前記第１のイベントバス上で実行されるよう構成されており、前記第２のコマンドフィルタシステムは、前記第２のイベントバス上で実行されるよう構成されており、
    前記複数のデバイスは、前記ユーティリティグリッド内で第１の所定の機能を有する第１のデバイスと、前記ユーティリティグリッド内で第２の所定の機能を有する第２のデバイスとを含み、前記第２の所定の機能は、前記第１の所定の機能と異なり、
    前記少なくとも１つのコマンドは、第１のコマンドおよび第２のコマンドを含み、前記第１のコマンドは、前記第１のデバイスに対応し、前記第２のコマンドは、前記第２のデバイスに対応し、
    前記第１のコマンドフィルタシステムは、前記少なくとも１つのデバイスコマンドルールに基づき、前記第１のコマンドが前記第１のデバイスによる実行に関して許可される場合を判断するよう構成されており、
    前記第２のコマンドフィルタシステムは、前記少なくとも１つのデバイスコマンドルールに基づき、前記第２のコマンドが前記個々のデバイスによる実行に関して許可される場合を判断するよう構成されており、
    前記通信ネットワークは、第１の通信サブネットワークおよび第２の通信サブネットワークを含み、前記第１の通信サブネットワークは、
    前記第１のコマンドが実行に関して許可されると、前記第１のデバイスコマンドを、前記第１のコマンドフィルタシステムから受信し、
    前記受信された第１のデバイスコマンドを、前記第１のデバイスへ中継するよう構成されており、
    前記第２の通信サブネットワークは、
    前記第２のコマンドが実行に関して許可されると、前記第２のデバイスコマンドを、前記第２のコマンドフィルタシステムから受信し、
    前記受信された第２のデバイスコマンドを、前記第２のデバイスへ中継するよう構成されている、請求項９に記載のユーティリティグリッド。
14. プロセッサにより実行可能な複数の命令を含むコンピュータ可読媒体であって、
    ユーティリティグリッドに相互接続された複数のデバイスのうちの個々のデバイスによって実行されるようそれぞれ構成されている複数のデバイスコマンドを受信する命令と、
    一連のコマンドルールを読み出す命令と、
    前記複数のデバイスコマンドが前記個々のデバイスによる実行に関して許可される場合を判断するために、前記一連のコマンドルールを前記複数のデバイスコマンドに適用する命令と、
    前記複数のデバイスコマンドが前記一連のコマンドルールに適合すれば、前記個々のデバイスにより実行されるよう前記複数のデバイスコマンドそれぞれを伝送する命令と、
    前記複数のデバイスコマンドが前記一連のコマンドルールのうちの少なくとも１つのコマンドルールに適合しなければ、前記複数のデバイスコマンドそれぞれが前記個々のデバイスにより実行されるのを防ぐ命令と、
    を含むコンピュータ可読媒体。
15. 前記複数のデバイスコマンドの第１の部分を、前記個々のデバイスにより実行されるよう伝送する命令であって、前記複数のデバイスコマンドの前記部分は、前記一連のコマンドルールに適合する、前記命令と、
    前記個々のデバイスによる実行に関して前記複数のデバイスコマンドの第２の部分を防ぐ指令であって、前記複数のデバイスコマンドの前記第２の部分は、前記一連のコマンドルールに適合しない、前記指令と、
    をさらに含む、請求項１４に記載のコンピュータ可読媒体。
16. 前記複数のデバイスコマンドの第１の部分が、所定のコマンド数閾値未満であれば、前記個々のデバイスにより実行されるよう前記複数のデバイスコマンドの前記第１の部分を伝送する命令
    をさらに含む、請求項１４に記載のコンピュータ可読媒体。
17. 前記複数のコマンドの許可による前記ユーティリティグリッドに対する影響を予測する命令と、
    前記予測された影響に基づき、前記複数のデバイスコマンドそれぞれを前記個々のデバイスにより実行されるよう伝送する命令と、
    をさらに含む、請求項１４に記載のコンピュータ可読媒体。
18. 手動入力されるコマンドを受領するよう構成された１つ以上のグラフィカルユーザインターフェースから、前記複数のデバイスコマンドを受信する命令をさらに含む、請求項１４に記載のコンピュータ可読媒体。
19. 複数のデバイスコマンドを受信する前記命令は、前記複数のデバイスコマンドを受信する指令を含み、前記複数のデバイスコマンドのうちの少なくとも１つは、スマート計器、需要家構内デバイス、スイッチングデバイスまたは補償器デバイスにより実行されるよう構成されている、請求項１４に記載のコンピュータ可読媒体。

Images