複数のデバイスコマンドルールを記憶するよう構成されたメモリと、前記メモリ上に記憶されたコマンドフィルタモジュールと、を含むユーティリティグリッドコマンドフィルタシステムであって、前記コマンドフィルタモジュールは、個々の発信デバイスからそれぞれ受信される複数のコマンドであって、ユーティリティグリッドに電気的に結合された個々のデバイスに対してコマンドを提供するようそれぞれ構成されている、前記複数のコマンドを受信し、前記複数のデバイスコマンドルールから少なくとも1つのデバイスコマンドルールを読み出し、前記少なくとも1つのデバイスコマンドルールに基づき、前記複数のコマンドのうちの少なくとも1つのコマンドが前記個々のデバイスによる実行に関して許可される場合を判断し、前記少なくとも1つのコマンドが前記個々のデバイスによる実行に関して許可されると判断されると、前記個々のデバイスによって受信されるよう前記少なくとも1つのコマンドを伝送するよう、プロセッサによって実行可能である、ユーティリティグリッドコマンドフィルタシステム。前記コマンドフィルタモジュールは、前記少なくとも1つのコマンドが前記個々のデバイスによる実行に関して許可されないと判断されると、前記個々の発信デバイスによって受信されるよう構成された拒否メッセージを生成するようさらに実行可能であり、前記拒否メッセージは、前記少なくとも1つのコマンドが前記個々のデバイスによる実行に関して許可されないことを示す、請求項1に記載のユーティリティグリッドコマンドフィルタシステム。前記コマンドフィルタモジュールは、前記少なくとも1つのコマンド個々に対するデバイスの動作に対応するユーティリティグリッド過去データを読み出し、前記ユーティリティグリッド過去データに前記基づくことにより、前記複数のコマンドのうちの少なくとも1つのコマンドが実行に関して許可される場合を判断するよう、さらに実行可能である、請求項1に記載のユーティリティグリッドコマンドフィルタシステム。前記コマンドフィルタモジュールは、前記ユーティリティグリッドの現在の動作条件に対応するユーティリティグリッド接続性データを読み出し、前記ユーティリティグリッド接続性データに基づき、前記複数のコマンドのうちの少なくとも1つのコマンドが前記デバイスによる実行に関して許可される場合を判断するよう、さらに実行可能である、請求項3に記載のユーティリティグリッドコマンドフィルタシステム。前記コマンドフィルタモジュールは、前記ユーティリティグリッド過去データおよび前記ユーティリティグリッド接続性データに基づき、前記少なくとも1つのコマンドの許可からの、予測される少なくとも1つのユーティリティグリッド影響を判断し、前記予測される少なくとも1つの影響に基づき、前記複数のコマンドのうちの少なくとも1つのコマンドが前記デバイスによる実行に関して許可される場合を判断するよう、さらに実行可能である、請求項4に記載のユーティリティグリッドコマンドフィルタシステム。前記少なくとも1つのデバイスコマンドルールは、最小ユーティリティグリッド障害閾値であり、前記コマンドフィルタモジュールは、前記予測される影響が前記最小ユーティリティグリッド障害閾値未満であれば、前記複数のコマンドのうちの前記少なくとも1つのコマンドが前記デバイスによる実行に関して許可される場合であると判断するよう、さらに実行可能である、請求項5に記載のユーティリティグリッドコマンドフィルタシステム。前記少なくとも1つのデバイスコマンドルールは、デバイス接続を、所定の時間内に所定のデバイス数に制限することを含む、請求項1に記載のユーティリティグリッドコマンドフィルタシステム。前記少なくとも1つのデバイスコマンドルールは、デバイスの再起動を、所定の時間内に所定の回数に制限することを含む、請求項1に記載のユーティリティグリッドコマンドフィルタシステム。電気的に結合された複数のデバイスと、個々の発信デバイスからそれぞれ受信される複数のコマンドであって、前記複数のデバイスのうちの個々のデバイスにコマンドを提供するようそれぞれ構成されている、前記複数のコマンドを受信し、複数のデバイスコマンドルールから少なくとも1つのデバイスコマンドルールを読み出し、前記少なくとも1つのデバイスコマンドルールに基づき、前記複数のコマンドのうちの少なくとも1つのコマンドが前記個々のデバイスによる実行に関して許可される場合を判断し、前記少なくとも1つのコマンドが前記個々のデバイスによる実行に関して許可されると判断されると、前記個々のデバイスによって受信されるよう前記少なくとも1つのコマンドを伝送するよう構成されたコマンドフィルタシステムと、前記少なくとも1つのコマンドを、前記コマンドフィルタシステムから前記個々のデバイスへ中継するよう構成された通信ネットワークと、を含むユーティリティグリッド。前記ユーティリティグリッドは、前記コマンドフィルタシステムを実行するよう構成されたイベントバスをさらに含み、前記複数のデバイスは、前記ユーティリティグリッド内で第1の所定の機能を有する第1のデバイスと、前記ユーティリティグリッド内で第2の所定の機能を有する第2のデバイスとを含み、前記第2の所定の機能は、前記第1の所定の機能と異なり、前記少なくとも1つのコマンドは、第1のコマンドおよび第2のコマンドを含み、前記第1のコマンドは、前記第1のデバイスに対応し、前記第2のコマンドは、前記第2のデバイスに対応し、前記通信ネットワークは、第1の通信サブネットワークおよび第2の通信サブネットワークを含み、前記コマンドフィルタシステムは、前記少なくとも1つのデバイスコマンドルールに基づき、前記第1のコマンドが前記第1のデバイスによる実行に関して許可される場合を判断し、前記少なくとも1つのデバイスコマンドルールに基づき、前記第2のコマンドが前記個々のデバイスによる実行に関して許可される場合を判断するよう構成されており、前記第1の通信サブネットワークは、前記第1のコマンドが実行に関して許可されると、前記第1のデバイスコマンドを前記第1のデバイスへ中継するよう構成されており、前記第2の通信サブネットワークは、前記第2のコマンドが実行に関して許可されると、前記第2のコマンドを前記第2のデバイスへ中継するよう構成されている、請求項9に記載のユーティリティグリッド。前記複数のデバイスは、前記ユーティリティグリッド内で第1の所定の機能を有する第1のデバイスと、前記ユーティリティグリッド内で第2の所定の機能を有する第2のデバイスとを含み、前記第2の所定の機能は、前記第1の所定の機能と異なり、前記少なくとも1つのコマンドは、第1のコマンドおよび第2のコマンドを含み、前記第1のコマンドは、前記第1のデバイスに対応し、前記第2のコマンドは、前記第2のデバイスに対応し、前記コマンドフィルタシステムは、前記少なくとも1つのデバイスコマンドルールに基づき、前記第1のコマンドが前記第1のデバイスによる実行に関して許可される場合を判断し、前記少なくとも1つのデバイスコマンドルールに基づき、前記第2のコマンドが前記個々のデバイスによる実行に関して許可される場合を判断するよう構成されており、前記通信ネットワークは、通信ネットワークバスを含み、前記コマンドフィルタシステムは、前記通信ネットワークバス上で実行されるよう構成されており、前記通信ネットワークバスは、前記第1のコマンドが実行に関して許可されると、前記第1のデバイスコマンドを前記第1のデバイスへ中継するよう構成されており、前記通信ネットワークバスは、前記第2のコマンドが実行に関して許可されると、前記第2のコマンドを前記第2のデバイスへ中継するよう構成されている、請求項9に記載のユーティリティグリッド。前記ユーティリティグリッドは、前記コマンドフィルタシステムを実行するよう構成されたイベントバスをさらに含み、前記複数のデバイスは、前記ユーティリティグリッド内で第1の所定の機能を有する第1のデバイスと、前記ユーティリティグリッド内で第2の所定の機能を有する第2のデバイスとを含み、前記第2の所定の機能は、前記第1の所定の機能と異なり、前記少なくとも1つのコマンドは、第1のコマンドおよび第2のコマンドを含み、前記第1のコマンドは、前記第1のデバイスに対応し、前記第2のコマンドは、前記第2のデバイスに対応し、前記コマンドフィルタシステムは、前記少なくとも1つのデバイスコマンドルールに基づき、前記第1のコマンドが前記第1のデバイスによる実行に関して許可される場合を判断し、前記少なくとも1つのデバイスコマンドルールに基づき、前記第2のコマンドが前記個々のデバイスによる実行に関して許可される場合を判断するよう構成されており、前記通信ネットワークは、前記第1のコマンドが実行に関して許可されると、前記イベントバスから、前記第1のデバイスへの前記第1のデバイスコマンドを受信し、前記第2のコマンドが実行に関して許可されると、前記イベントバスから、前記第2のデバイスへの前記第2のコマンドを受信し、前記受信された第1のコマンドを前記第1のデバイスへ、前記受信された第2のコマンドを前記第2のデバイスへ中継するよう構成された通信バスを含む、請求項9に記載のユーティリティグリッド。前記ユーティリティグリッドは、第1のイベントバスおよび第2のイベントバスをさらに含み、前記コマンドフィルタシステムは、第1のコマンドフィルタシステムおよび第2のコマンドフィルタシステムを含み、前記第1のコマンドフィルタシステムは、前記第1のイベントバス上で実行されるよう構成されており、前記第2のコマンドフィルタシステムは、前記第2のイベントバス上で実行されるよう構成されており、前記複数のデバイスは、前記ユーティリティグリッド内で第1の所定の機能を有する第1のデバイスと、前記ユーティリティグリッド内で第2の所定の機能を有する第2のデバイスとを含み、前記第2の所定の機能は、前記第1の所定の機能と異なり、前記少なくとも1つのコマンドは、第1のコマンドおよび第2のコマンドを含み、前記第1のコマンドは、前記第1のデバイスに対応し、前記第2のコマンドは、前記第2のデバイスに対応し、前記第1のコマンドフィルタシステムは、前記少なくとも1つのデバイスコマンドルールに基づき、前記第1のコマンドが前記第1のデバイスによる実行に関して許可される場合を判断するよう構成されており、前記第2のコマンドフィルタシステムは、前記少なくとも1つのデバイスコマンドルールに基づき、前記第2のコマンドが前記個々のデバイスによる実行に関して許可される場合を判断するよう構成されており、前記通信ネットワークは、第1の通信サブネットワークおよび第2の通信サブネットワークを含み、前記第1の通信サブネットワークは、前記第1のコマンドが実行に関して許可されると、前記第1のデバイスコマンドを、前記第1のコマンドフィルタシステムから受信し、前記受信された第1のデバイスコマンドを、前記第1のデバイスへ中継するよう構成されており、前記第2の通信サブネットワークは、前記第2のコマンドが実行に関して許可されると、前記第2のデバイスコマンドを、前記第2のコマンドフィルタシステムから受信し、前記受信された第2のデバイスコマンドを、前記第2のデバイスへ中継するよう構成されている、請求項9に記載のユーティリティグリッド。プロセッサにより実行可能な複数の命令を含むコンピュータ可読媒体であって、ユーティリティグリッドに相互接続された複数のデバイスのうちの個々のデバイスによって実行されるようそれぞれ構成されている複数のデバイスコマンドを受信する命令と、一連のコマンドルールを読み出す命令と、前記複数のデバイスコマンドが前記個々のデバイスによる実行に関して許可される場合を判断するために、前記一連のコマンドルールを前記複数のデバイスコマンドに適用する命令と、前記複数のデバイスコマンドが前記一連のコマンドルールに適合すれば、前記個々のデバイスにより実行されるよう前記複数のデバイスコマンドそれぞれを伝送する命令と、前記複数のデバイスコマンドが前記一連のコマンドルールのうちの少なくとも1つのコマンドルールに適合しなければ、前記複数のデバイスコマンドそれぞれが前記個々のデバイスにより実行されるのを防ぐ命令と、を含むコンピュータ可読媒体。前記複数のデバイスコマンドの第1の部分を、前記個々のデバイスにより実行されるよう伝送する命令であって、前記複数のデバイスコマンドの前記部分は、前記一連のコマンドルールに適合する、前記命令と、前記個々のデバイスによる実行に関して前記複数のデバイスコマンドの第2の部分を防ぐ指令であって、前記複数のデバイスコマンドの前記第2の部分は、前記一連のコマンドルールに適合しない、前記指令と、をさらに含む、請求項14に記載のコンピュータ可読媒体。前記複数のデバイスコマンドの第1の部分が、所定のコマンド数閾値未満であれば、前記個々のデバイスにより実行されるよう前記複数のデバイスコマンドの前記第1の部分を伝送する命令をさらに含む、請求項14に記載のコンピュータ可読媒体。前記複数のコマンドの許可による前記ユーティリティグリッドに対する影響を予測する命令と、前記予測された影響に基づき、前記複数のデバイスコマンドそれぞれを前記個々のデバイスにより実行されるよう伝送する命令と、をさらに含む、請求項14に記載のコンピュータ可読媒体。手動入力されるコマンドを受領するよう構成された1つ以上のグラフィカルユーザインターフェースから、前記複数のデバイスコマンドを受信する命令をさらに含む、請求項14に記載のコンピュータ可読媒体。複数のデバイスコマンドを受信する前記命令は、前記複数のデバイスコマンドを受信する指令を含み、前記複数のデバイスコマンドのうちの少なくとも1つは、スマート計器、需要家構内デバイス、スイッチングデバイスまたは補償器デバイスにより実行されるよう構成されている、請求項14に記載のコンピュータ可読媒体。ユーティリティグリッド内でデバイスコマンドをフィルタリングする、コマンドフィルタシステムが提供される。コマンドフィルタシステムは、電力ユーティリティグリッドの管理を改善するために、スマートグリッドにおいて実装されるとよい。本開示のスマートグリッドは、現在の電気電力グリッドがより効率的かつ確実に動作し、消費者へのさらなるサービスをサポートできるように、電力ユーティリティグリッドの様々な部分においてセンサーを使用し、通信およびコンピューティング技術を使用して現在の電気電力グリッドを改良することを含む。本開示のスマートグリッドは、堅牢な双方向通信、高度なセンサーおよび分散型コンピュータ送電および/または配電における追加のインテリジェンスを含むを使用することなどによって、従来の送電配電ネットワーク、すなわちグリッドを改良することができる。スマートグリッドはさらに、動作管理、故障検出および修正、リソース管理などのために、中央管理施設にさらなる機能性を含んでもよい。スマートグリッド内の様々なデバイスを制御するために使用されるコマンドは、手動または自動で生成され得る。コマンドフィルタシステムが、スマートグリッド内に実装され、各デバイスコマンドを分析して、特定のデバイスによる実行に関してデバイスコマンドを許可するとよい。コマンドフィルタシステムは、スマートグリッド内の各デバイスコマンドを受信するとよい。コマンドフィルタシステムは、デバイスコマンドに一連のルールを適用するとよい。一連のルールの適用に基づき、コマンドフィルタシステムは、特定のデバイスによる実行に関してコマンドを許可するとよい。コマンドフィルタシステムはさらに、コマンドが特定のデバイスにより実行されるのを防ぐこともできる。実行を防がれた各コマンドに関して、コマンドフィルタシステムにより拒否メッセージが生成されるとよい。各拒否メッセージは、拒否されたコマンドの発信ソースへ、または後からの介入のために監視場所へ伝送されるとよい。コマンドフィルタシステムは、様々な所定のルールを実装して、許可が与えられるべきかどうかを様々なコマンドに関して判断するとよい。コマンドフィルタシステムは、同時に、または所定の時間ウィンドウ内に受信されたコマンドを分析するとよい。所定のルールは、受信されたコマンドの数またはタイプを対象としてもよい。コマンドフィルタシステムは、分析で用いるために、スマートグリッドに関連する過去データ、ならびに現在の動作条件を読み出してもよい。コマンドフィルタシステムは、過去データに基づき、特定のコマンドまたはコマンドのグループに関する許可決定を実行するとよい。コマンドフィルタシステムは、現在の動作条件を過去データとともに使用して、許可が検討されている1つ以上のコマンドの実行の、スマートグリッドに対する影響を予測するとよい。予測された影響に所定のルールが適用されて、コマンドが許可されるべきか否かが判断されるとよい。コマンドフィルタシステムは、様々な構成を有するスマートグリッドにおいて実装され得る。コマンドフィルタは、通信ネットワークバスまたはグリッドイベント認識バスなど、スマートグリッド内のソフトウェアバスによって実装されてもよい。コマンドフィルタは、許可されたコマンドを直接デバイスに中継しても、通信ネットワークおよびサブネットワークを経由してコマンドを中継してもよい。コマンドフィルタシステムは、スマートグリッド中を送られるデバイスコマンドを実質的にすべて受信するよう構成された、単一システムであってもよい。他の構成では、分散したコマンドフィルタシステムそれぞれが特定のタイプのデバイスに関連するコマンドの分析を担当するように、コマンドフィルタシステムは、スマートグリッド内に分散していてもよい。以下の図面および詳細な説明を検討すると、当業者には、他のシステム、方法、特徴および利点が明らかであるか、または明らかとなるであろう。そのようなさらなるシステム、方法、特徴および利点はすべて、本記載に含まれ、本発明の範囲内にあり、添付の特許請求の範囲により保護されるものとする。概要として、以下に記載される好適な実施形態は、コマンドフィルタシステムに関する。コマンドフィルタシステムは、電力グリッド内の様々なデバイスの動作を制御することを目的としているコマンドを受信するとよい。コマンドフィルタは、コマンドに1つ以上のルールを適用して、受信するよう意図されているデバイスによる実行に関してコマンドが許可されるべきであるかどうかを判断するとよい。INDE上位アーキテクチャの説明全体的アーキテクチャ図面を参照する。図面では、同じ参照数字は類似した構成要素を指し、図1はINDEの全体的なアーキテクチャの一例を示す。このアーキテクチャは、スマートグリッドデータのエンドツーエンド収集、搬送、記憶および管理を提供する参照モデルとなり得る。さらにこのアーキテクチャは、解析および解析管理、ならびに前述のもののユーティリティプロセスおよびシステムへの統合を提供し得る。したがって、これはエンタープライズ規模のアーキテクチャと見なされるとよい。運用管理、およびグリッド自体の各側面など、特定の要素については、下記でさらに詳しく説明する。図1に示されているアーキテクチャは、データおよび統合バスを最大4つまで含み得る:1高速センサーデータバス146運用および非運用データを含むとよい、2専用イベント処理バス147イベントデータを含むとよい、3動作サービスバス130スマートグリッドについての情報をユーティリティのバックオフィスアプリケーションに提供する役割を果たすとよい、ならびに4バックオフィスITシステム用のエンタープライズサービスバスエンタープライズIT115にサービス提供するエンタープライズ統合環境バス114として図1に示されている。個々のデータバスは、1つ以上の方法で実現され得る。例えば、高速センサーデータバス146およびイベント処理バス147など、データバスの2つ以上は、単一データバスの異なるセグメントであってもよい。具体的には、バスはセグメント化された構造またはプラットフォームを有してもよい。以下でさらに詳しく説明するように、データバスの別々のセグメント上にデータをルーティングするために、1つ以上のスイッチなどのハードウェアおよび/またはソフトウェアが使用され得る。別の例として、データバスの2つ以上は、データを別々のバス上で搬送するために必要なハードウェアに関して別々の物理的バスなど、別々のバス上にあってもよい。具体的には、バスはそれぞれ、互いに独立したケーブルを含んでもよい。さらに、別々のバスのうち、一部または全部が同じタイプであってもよい。例えば、バスの1つ以上が、非シールドより対線を介したイーサネット登録商標およびWi-Fi登録商標などのローカルエリアネットワークLAN:localareanetworkを含んでもよい。以下でさらに詳しく説明するように、ルータなどのハードウェアおよび/またはソフトウェアが、種々の物理的バスの中の1つのバス上へデータ上のデータをルーティングするために使用されてもよい。さらに別の例として、バスの2つ以上が、単一バス構造の異なるセグメント上にあってもよく、1つ以上のバスが、別個の物理的バス上にあってもよい。具体的には、高速センサーデータバス146およびイベント処理バス147が、単一データバスの異なるセグメントであってもよく、エンタープライズ統合環境バス114が、物理的に別個のバス上にあってもよい。図1は、4つのバスを示すが、より少ない、または多い数のバスが、列挙された4タイプのデータを運ぶために使用され得る。例えば、後述するように、センサーデータおよびイベント処理データの伝達に、セグメント化されていない単一バスが使用されてもよいバスの総数は3になる。さらにシステムは、動作サービスバス130および/またはエンタープライズ統合環境バス114なしで動作することもできる。IT環境は、SOAServiceOrientedArchitecture:サービス指向アーキテクチャに準拠していてもよい。サービス指向アーキテクチャSOAは、サービスとしてパッケージ化されたビジネスプロセスのライフサイクル全体にわたる作成および使用に関する、コンピュータシステムアーキテクチャの様式である。SOAはさらに、種々のアプリケーションがデータを交換してビジネスプロセスに関与することを可能にするようITインフラストラクチャを定義し、供給する。とはいえ、SOAおよびエンタープライズサービスバスの使用は任意選択である。図面は、1INDECORE120、2INDESUBSTATION180および3INDEDEVICE188など、全体的なアーキテクチャ内の種々の構成要素を示す。全体的なアーキテクチャ内で構成要素をこのように分割しているのは、説明のためである。この他の構成要素の分割が使用されてもよい。INDEアーキテクチャは、グリッドインテリジェンスに対する分散型および集中型両方の手法をサポートするため、および大型実装の規模に対応するメカニズムを提供するために使用され得る。INDE参照アーキテクチャは、実装され得る技術アーキテクチャの一例である。例えば、後述するように、INDE参照アーキテクチャをメタアーキテクチャの例とし、これを、各ユーティリティソリューションに対し1つ、任意の数の具体的技術アーキテクチャを開発するための、開始点を提供するために使用することもできる。したがって、特定のユーティリティ向けの具体的なソリューションは、INDE参照アーキテクチャの構成要素のうちの1つ、いくつかまたはすべてを含むとよい。さらに、INDE参照アーキテクチャは、ソリューション開発の標準化された開始点を提供するとよい。特定の電力グリッドに対し具体的な技術アーキテクチャを決定する手順について後述する。INDE参照アーキテクチャは、エンタープライズ規模のアーキテクチャであるとよい。その目的は、グリッドデータおよび解析のエンドツーエンド管理と、これらのユーティリティシステムおよびプロセスへの統合とのためのフレームワークを提供することであるとよい。スマートグリッド技術は、ユーティリティビジネスプロセスのあらゆる側面に影響することから、グリッド、動作および需要家構内レベルの影響のみではなく、バックオフィスおよびエンタープライズレベルの影響にも気を配らなければならない。したがって、INDE参照アーキテクチャは、例えばインターフェースのためにSOA環境をサポートするよう、エンタープライズレベルSOAを参照することができ、実際に参照する。これは、スマートグリッドを構築および使用するには、ユーティリティがその既存のIT環境をSOAに変更しなければならないと要求するものと見なされてはならない。エンタープライズサービスバスは、IT統合を促進する有益なメカニズムであるが、スマートグリッドソリューションの残りの部分を実装するために必須ではない。以下の説明は、INDEスマートグリッド構成要素の種々のコンポーネントに焦点を合わせる。INDEコンポーネントグループ上記のように、INDE参照アーキテクチャ内の種々のコンポーネントには、例えば1INDECORE120、2INDESUBSTATION180および3INDEDEVICE188が含まれ得る。以下の各セクションは、INDE参照アーキテクチャのこれら3つの構成要素グループの例について説明し、各グループのコンポーネントの説明を提供する。INDECORE図2は、図1に示されているように、INDE参照アーキテクチャのうち、動作制御センターに存在するとよい部分である、INDECORE120を示す。INDECORE120は、グリッドデータを記憶するための統一データアーキテクチャと、そのデータに対して行われる解析の統合スキーマとを含むとよい。このデータアーキテクチャは、その最上位スキーマとして、国際電気標準会議IEC:InternationalElectrotechnicalCommission共通情報モデルCIM:CommonInformationModelを使用するとよい。IECCIMは、アプリケーションソフトウェアが電気ネットワークの構成およびステータスについての情報を交換できるようにすることを目標として、電気電力業界により開発されIECにより公式に採用された標準である。さらに、このデータアーキテクチャは、他のタイプのユーティリティデータ例えば計器データ、運用および過去データ、ログならびにイベントファイルなど、ならびに接続性およびメタデータファイルを、エンタープライズアプリケーションを含む上位アプリケーションによるアクセスのための単一エントリポイントを有するとよい単一データアーキテクチャに関連付けるために、連合ミドルウェア134を使用するとよい。さらに、リアルタイムシステムが、高速データバスを介して主要データストアにアクセスするとよく、いくつかのデータストアがリアルタイムデータを受信することができる。種々のタイプのデータが、スマートグリッド内の1つ以上のバス内で搬送されるとよい。INDESUBSTATION180のセクションにおいて以下で説明するように、変電所データは、変電所において収集されてローカルに記憶されるとよい。具体的には、変電所に関連し近接しているとよいデータベースが、変電所データを記憶するとよい。さらに、変電所レベルに関連する解析は、変電所のコンピュータにて実行され、変電所データベースに記憶されるとよく、そのデータの全部または一部が、制御センターへ搬送されるとよい。搬送されるデータのタイプは、動作および非運用データ、イベント、グリッド接続性データならびにネットワーク位置データを含むとよい。運用データは、次に限定はされないが、スイッチ状態、フィーダ状態、コンデンサ状態、セクション状態、計器状態、FCIfaultcircuitindicator:故障回路インジケータ状態、ラインセンサー状態、電圧、電流、有効電力、無効電力などを含むとよい。非運用データは、次に限定はされないが、電力品質、電力信頼性、アセット正常性assethealth、ストレスデータなどを含むとよい。運用および非運用データは、運用/非運用データバス146を使用して搬送されるとよい。電力グリッドの送電および/または配電におけるデータ収集アプリケーションが、データの一部または全部を運用/非運用データバス146へ送信することを担当するとよい。このように、情報を得るための登録をすること、またはこのデータを利用可能にできるサービスを呼び出すことにより、この情報を必要とするアプリケーションがデータを得られるとよい。イベントは、後述するように、スマートグリッドの一部である様々なデバイスおよびセンサーから生じるメッセージおよび/またはアラームを含むとよい。イベントは、スマートグリッドネットワーク上のデバイスおよびセンサーから直接生成されてもよく、さらに、こうしたセンサーおよびデバイスからの測定データに基づいて様々な解析アプリケーションにより生成されてもよい。イベントの例には、計器の停止、計器のアラーム、変圧器の停止などが含まれ得る。グリッドデバイスのようなグリッドコンポーネントスマート電力センサーデジタル処理機能のためにプログラム可能な組み込みプロセッサを備えるセンサーなど、温度センサーなど、追加の組み込み処理を含む電力システムコンポーネントRTURemoteTerminalUnit:リモート端末ユニットなど、スマート計器ネットワーク計器の正常性、計器読み取りなどおよび移動式の現場要員用デバイス供給停止イベント、作業命令完了などが、イベントデータ、運用および非運用データを生成するとよい。スマートグリッド内で生成されたイベントデータは、イベントバス147を介して伝送されるとよい。グリッド接続性データは、ユーティリティグリッドの配置を定義するとよい。グリッドコンポーネント変電所、セグメント、フィーダ、変圧器、スイッチ、リクローザー、計器、センサー、電柱などの物理的配置、およびそれらの設備における相互接続性を定義する基本レイアウトがあるとよい。グリッド内のイベントコンポーネントの不具合、保守活動などに基づき、グリッド接続性は継続的に変化し得る。下記でさらに詳しく説明するように、データが記憶される構造ならびにデータの組み合わせにより、過去の様々な時点における過去のグリッド配置の再現が可能となる。グリッド接続性データは、ユーティリティグリッドに対する変更が加えられ、この情報がGISGeographicInformationSystem:地理情報システムアプリケーションにおいて更新されるにつれて、定期的に地理情報システムGISから抽出されるとよい。ネットワーク位置データは、通信ネットワーク上のグリッドコンポーネントについての情報を含むとよい。この情報は、メッセージおよび情報を特定のグリッドコンポーネントへ送信するために使用されるとよい。ネットワーク位置データは、新たなスマートグリッドコンポーネントが設置されたときにスマートグリッドデータベースに手動で入力されてもよく、またはこの情報が電子的に保持される場合はアセット管理システムから抽出される。下記でさらに詳しく説明するように、データは、グリッド内の様々なコンポーネントから送信され得るINDESUBSTATION180および/またはINDEDEVICE188など。データは、無線、有線または両方の組み合わせでINDECORE120へ送信され得る。データは、ユーティリティ通信ネットワーク160によって受信されるとよく、ユーティリティ通信ネットワーク160は、データをルーティングデバイス190へ送信するとよい。ルーティングデバイス190は、バスのセグメント上バスがセグメント化されたバス構造を含む場合または独立したバス上へのデータのルーティングを管理するソフトウェアおよび/またはハードウェアを含むとよい。ルーティングデバイスは、1つ以上のスイッチまたはルータを含んでもよい。ルーティングデバイス190は、ネットワーキングデバイスを含むとよく、そのソフトウェアおよびハードウェアが、バスの1つ以上へデータをルーティングおよび/または転送する。例えば、ルーティングデバイス190は、運用および非運用データを、運用/非運用データバス146へルーティングするとよい。ルータはさらに、イベントデータをイベントバス147へルーティングするとよい。ルーティングデバイス190は、データをどのようにルーティングするかを、1つ以上の方法に基づき判断するとよい。例えば、ルーティングデバイス190は、伝送されたデータ内の1つ以上のヘッダを検査して、データを運用/非運用データバス146のセグメントへルーティングするか、またはイベントバス147のセグメントへルーティングするかを判断してもよい。具体的には、データ内の1つ以上のヘッダが、データが動作/非運用データであるかその結果ルーティングデバイス190はデータを運用/非運用データバス146へルーティングするまたはデータがイベントデータであるかその結果ルーティングデバイス190はイベントバス147をルーティングするを示してもよい。あるいは、ルーティングデバイス190は、データのソースまたはデータのペイロードを検査して、データのタイプを判断してもよい例えば、ルーティングデバイス190は、データのフォーマットを検査して、データが運用/非運用データであるか、またはイベントデータであるかを判断してもよい。運用データを記憶する運用データウェアハウス137などのストアの1つが、真の分散型データベースとして実装されてもよい。ストアのもう1つ、ヒストリアン図1および2において過去データ136として特定されているが、分散型データベースとして実装されてもよい。これら2つのデータベースのもう一方のエンドは、INDESUBSTATION180グループ後述にあってもよい。さらに、イベントは、複合イベント処理バスを介していくつかのデータストアのいずれかに直接記憶されてもよい。具体的には、イベントは、イベントバス147へ発行したすべてのイベントのリポジトリとしてもよいイベントログ135に記憶されてもよい。イベントログは、イベントid、イベントタイプ、イベントソース、イベント優先度およびイベント生成時間のうちの1つ、いくつか、またはすべてを記憶するとよい。イベントバス147が、イベントを長期記憶してすべてのイベントの維持を提供する必要はない。データの記憶は、できるだけ、または実用的なだけ、データがソースに近くなるようになっているとよい。一実装では、これには例えば、変電所データがINDESUBSTATION180にて記憶されることが含まれてもよい。しかし、このデータは、非常に細かい粒度レベルでグリッドを考慮した各種決定を下すために、動作制御センターレベル116においても必要とされることもある。データベースリンクおよびデータサービスを適宜使用することによってソリューションのすべてのレベルにおけるデータの利用可能性を促進するよう、分散型データ手法が、分散型インテリジェンス手法とともに採用されるとよい。このように、過去データストア動作制御センターレベル116にてアクセス可能であるとよいに関するソリューションは、運用データストアのソリューションと類似しているとよい。データは、変電所においてローカルに記憶されてもよく、制御センターにおいてリポジトリインスタンス上で構成されているデータベースリンクが、個別の変電所にあるデータに対するアクセスを提供する。変電所解析は、変電所において、ローカルデータストアを使用してローカルで実行されてもよい。データベースリンクを使用してローカル変電所インスタンスのデータにアクセスすることによって、動作制御センターレベル116で過去/集合的解析が実行されてもよい。あるいは、データは、INDECORE120にて中央で記憶されてもよい。しかし、INDEDEVICE188から伝送される必要があると考えられるデータの量を考慮すると、INDEDEVICE188にてデータを記憶する方が好ましいこともある。具体的には、何千または何万もの変電所がある場合電力グリッドではあり得る、INDECORE120へ伝送される必要のあるデータ量により、通信ボトルネックがもたらされることもあり得る。最後に、INDECORE120は、電力グリッド内のINDESUBSTATION180またはINDEDEVICE188のうちの1つ、いくつかまたはすべてをプログラムまたは制御するとよい後述。例えば、INDECORE120は、プログラミングを変更してもよく更新されたプログラムをダウンロードするなど、またはINDESUBSTATION180もしくはINDEDEVICE188の任意の側面を制御する制御コマンドを提供してもよいセンサーまたは解析の制御など。図2に示されていない他の構成要素に、この論理アーキテクチャをサポートする様々な統合構成要素が含まれ得る。表1は、図2に示されたINDECORE120の特定の構成要素を記載する。表1:INDECORE構成要素表1で説明したように、リアルタイムデータバス146動作および非運用データを伝達するおよびリアルタイム複合イベント処理バス147イベント処理データを伝達するは単一バス346へ。この例が、図3のブロック図300に示されている。図1に示されているように、バスは、パフォーマンスのために別々になっている。CEP処理の場合、非常に大きなメッセージバーストが起こりやすい特定の用途には、低遅延が重要であると考えられる。一方、グリッドデータフローの大部分はほぼ一定であり、デジタル故障レコーダファイルが例外であるが、これらは通常、制御された形で読み出し可能である。それに対し、イベントバーストは非同期かつランダムである。図1はさらに、INDECORE120とは別の、動作制御センター116内のさらなる構成要素を示す。具体的には、図1はさらに、計器との通信計器からデータを収集して収集したデータをユーティリティに提供するなどを担当するシステムである、計器データ収集ヘッドエンドMeterDataCollectionHeadEnd単数または複数153を示す。需要応答管理システム154は、1つ以上の需要家構内にありユーティリティによる制御が可能な設備と通信するシステムである。供給停止管理システム155は、供給停止の位置を追跡すること、何が送られているかを管理すること、およびその回復方法によって、供給停止の管理においてユーティリティを支援するシステムである。エネルギー管理システム156は、送電グリッド上の変電所例えばのデバイスを制御する、送電システムレベルの制御システムである。配電管理システム157は、配電グリッドの変電所のデバイスおよびフィーダデバイス例えばを制御する、配電システムレベルの制御システムである。IPネットワークサービス158は、IP型通信TCP/IP、SNMP、DHCPおよびFTPなどをサポートする1つ以上のサーバ上で動作するサービスの集合である。給電指令モバイルデータシステム159は、現場のモバイルデータ端末とメッセージを送受信するシステムである。回路負荷潮流分析、計画、雷分析およびグリッドシミュレーションツール152は、グリッドの設計、分析および計画においてユーティリティにより使用されるツールの集合である。IVRintegratedvoiceresponse:統合音声応答および呼管理151は、需要家からの電話を処理するシステムである自動または係により。供給停止に関する着信通話が、自動または手動で入力されて、供給停止管理システム155へ転送されるとよい。作業管理システム150は、作業命令を監視および管理するシステムである。地理情報システム149は、アセットが地理的にどこに位置し、各アセットがどのように接続されているかについての情報を含むデータベースである。環境がサービス指向アーキテクチャSOAを有する場合、動作SOAサポート148は、SOA環境をサポートするサービスの集合である。動作制御センター116内にあり、INDECORE120外にあるシステムのうちの1つ以上は、ユーティリティが有することもあるレガシー製品システムである。こうしたレガシー製品システムの例には、動作SOAサポート148、地理情報システム149、作業管理システム150、呼管理151、回路負荷潮流分析、計画、雷分析およびグリッドシミュレーションツール152、計器データ収集ヘッドエンド単数または複数153、需要応答管理システム154、供給停止管理システム155、エネルギー管理システム156、配電管理システム157、IPネットワークサービス158、給電指令モバイルデータシステム159が含まれる。なお、こうしたレガシー製品システムは、スマートグリッドから受信されるデータを処理または操作することができなくてもよい。INDECORE120は、スマートグリッドからデータを受信し、スマートグリッドからのデータを処理し、処理したデータを1つ以上のレガシー製品システムへ、レガシー製品システムが使用できる形レガシー製品システムに特有の特定のフォーマッティングなどで転送することができるとよい。このように、INDECORE120はミドルウェアと見なされてもよい。INDECORE120を含む動作制御センター116は、エンタープライズIT115と通信するとよい。一般的に、エンタープライズIT115における機能性はバックオフィス業務を含む。具体的には、エンタープライズIT115は、ビジネスデータウェアハウス104、ビジネスインテリジェンスアプリケーション105、エンタープライズリソースプラニング106、様々な財務システム107、需要家情報システム108、人材システム109、アセット管理システム110、エンタープライズSOAサポート111、ネットワーク管理システム112およびエンタープライズメッセージサービス113を含むエンタープライズIT115内の様々なシステムへデータを送信するためにエンタープライズ統合環境バス114を使用するとよい。エンタープライズIT115はさらに、ファイアウォール102を介してインターネット101と通信するためのポータル103を含むとよい。INDESUBSTATION図4は、INDESUBSTATION180グループの上位アーキテクチャの例を示す。このグループは、変電所の電子装置およびシステムと同一の場所に位置する1つ以上のサーバ上で、変電所の制御所にて変電所170内で実際にホストされている構成要素を含むとよい。以下の表2は、特定のINDESUBSTATION180グループ構成要素を列挙し、説明する。データセキュリティサービス171は、変電所環境の一部であってもよい。あるいは、これらはINDESUBSTATION180グループに統合されてもよい。表2:INDESUBSTATION構成要素上記のように、スマートグリッド内の種々の構成要素に、追加の処理/分析機能およびデータベースリソースを含む追加の機能性が含まれるとよい。スマートグリッドにおいて、様々な構成要素内でこうした追加の機能性を使用することで、アプリケーションおよびネットワークパフォーマンスの集中管理および監督を伴う分散型アーキテクチャが可能になる。機能、パフォーマンスおよび拡張性のために、何千から何万のINDESUBSTATION180および何万から何百万のグリッドデバイスを含むスマートグリッドが、分散型処理、データ管理およびプロセス通信を含むこともできる。INDESUBSTATION180は、1つ以上のプロセッサと、1つ以上のメモリデバイス変電所非運用データ181および変電所動作データ182などとを含むとよい。非運用データ181および変電所動作データ182は、INDESUBSTATION180内、またはINDESUBSTATION180上に位置するなど、変電所に関連し近接しているとよい。INDESUBSTATION180はさらに、変電所レベルでのスマートグリッドの可観測性を担当する、スマートグリッドのコンポーネントを含んでもよい。INDESUBSTATION180コンポーネントは、運用データ獲得および分散型運用データストアでの記憶、非運用データの獲得およびヒストリアンでの記憶、ならびにリアルタイムサブ秒などでのローカル解析処理という3つの主要機能を提供するとよい。処理は、電圧および電流波形のデジタル信号処理と、イベントストリーム処理を含む検出および分類処理と、処理結果のローカルシステムおよびデバイス、ならびに動作制御センター116にあるシステムへの伝達とを含むとよい。INDESUBSTATION180と、グリッド内の他のデバイスとの通信は、有線、無線または有線と無線との組み合わせとしてよい。例えば、INDESUBSTATION180から動作制御センター116へのデータの伝送は有線であってもよい。INDESUBSTATION180は、動作/非運用データまたはイベントデータなどのデータを、動作制御センター116へ伝送するとよい。ルーティングデバイス190は、伝送されたデータを、運用/非運用データバス146またはイベントバス147のうちの1つへルーティングするとよい。配電損失管理のための需要応答最適化も、ここで実行されるとよい。このアーキテクチャは、前に説明した分散型アプリケーションアーキテクチャの原則に従う。例えば、接続性データは、変電所170および動作制御センター116にて複製され、その結果、動作制御センター116へのデータ通信ネットワークが有効でなくても変電所170が独立して動作できるようにするとよい。この情報接続性がローカルに記憶されていることで、動作制御センターへの通信リンクが動作不能であっても変電所解析がローカルで実行され得る。同様に、運用データは、動作制御センター116および変電所170にて複製されるとよい。特定の変電所に関連するセンサーおよびデバイスからのデータが収集され、最新の測定値が、変電所にてこのデータストアに記憶されるとよい。運用データストアのデータ構造は同じであるとよく、したがって、データベースリンクを使用して、制御センターにある運用データストアのインスタンスを介した、変電所に存在するデータへのシームレスアクセスを提供することもできる。これは、データの複製を減らすこと、および時間依存がより大きい変電所データ解析が、ローカルで、変電所外の通信利用可能性に依存せずに行われるのを可能にすることを含む、いくつかの利点を提供する。動作制御センターレベル116でのデータ解析は、時間依存がより小さいと考えられ典型的には、動作制御センター116は、過去データを検査して、反応型というよりも予測型のパターンを識別すると考えられるため、ネットワークの問題があっても対処できると考えられる。最後に、過去データが変電所にてローカルに記憶され、データのコピーが制御センターにて記憶されてもよい。または、動作制御センター116にてリポジトリインスタンス上のデータベースリンクが構成され、個別の変電所にあるデータへのアクセスが動作制御センターに提供されてもよい。変電所解析は、変電所170において、ローカルデータストアを使用してローカルで実行されてもよい。具体的には、変電所にて追加のインテリジェンスおよび記憶機能を使用することで、変電所は、それ自体を分析して、中央局からの入力なしにそれ自体を修正することができる。あるいは、ローカル変電所インスタンスのデータにデータベースリンクを使用してアクセスすることによって、動作制御センターレベル116で、過去/集合的解析も実行されてもよい。INDEDEVICEINDEDEVICE188グループは、様々な配電グリッドデバイス189例えば、送電線上のラインセンサーなどのスマートグリッド内の様々なセンサー、需要家構内にある計器163などを含む、スマートグリッド内の任意の種類のデバイスを含み得る。INDEDEVICE188グループは、特定の機能性を備えグリッドに追加されるデバイスを含んでもよく専用プログラミングを含むスマートリモート端末ユニットRTUなど、または追加機能性を備えるグリッド内の既存デバイスを含んでもよい既にグリッド内に配置されており、スマートラインセンサーまたはスマートグリッドデバイスを作成するためにプログラム可能な、既存のオープンアーキテクチャ柱上RTUなど。INDEDEVICE188はさらに、1つ以上のプロセッサおよび1つ以上のメモリデバイスを含んでもよい。既存のグリッドデバイスは、ソフトウェアの観点からはオープンではないこともあり、現代のネットワーキングまたはソフトウェアサービスに関してはあまりサポートできないかもしれない。既存のグリッドデバイスは、ラップトップコンピュータなどの他の何らかのデバイスに時折オフロードするデータを獲得および記憶するよう、または要求に応じてリモートホストへPSTNpublic-switchedtelephonenetwork:公衆交換電話ネットワーク線を介してバッチファイルを転送するよう設計されていることもある。こうしたデバイスは、リアルタイムデジタルネットワーク環境で動作するようには設計されていないこともある。このような場合には、グリッドデバイスデータは、既存の通信ネットワークがどのように設計されているかに応じて、変電所レベル170または動作制御センターレベル116で取得されるとよい。計器ネットワークの場合、計器ネットワークが通常クローズドであり、計器が直接アドレス指定可能ではないことから、通常は計器データ収集エンジンからデータが取得される。こうしたネットワークが進化するにつれて、計器および他のグリッドデバイスが個別にアドレス指定可能になると考えられ、その結果データが、必要とされるところへ直接搬送可能になる。データが必要とされる場所は、必ずしも動作制御センター116とは限らず、グリッド上のどこでもあり得る。故障回路インジケータなどのデバイスは、適度な速度100kbpsなどの無線ネットワークを介した接続のために、無線ネットワークインターフェースカードと結合されてもよい。こうしたデバイスは、例外によりステータスをレポートして、事前にプログラムされた固定機能を実行してもよい。ローカルスマートRTUを使用することによって、多数のグリッドデバイスのインテリジェンスが増強され得る。固定機能のクローズドアーキテクチャデバイスとして設計されている柱上RTUの代わりに、サードパーティーによりプログラム可能でINDE参照アーキテクチャ内のINDEDEVICE188としての機能を果たすことができるオープンアーキテクチャデバイスとしてのRTUが使用されてもよい。さらに、需要家の構内にある計器がセンサーとして使用されてもよい。例えば、計器は、消費を測定してもよく請求のために、どのくらいの量のエネルギーが消費されているかなど、電圧を測定してもよい電圧/VAr最適化で用いるために。図5は、INDEDEVICE188グループのアーキテクチャの例を示す。表3は、特定のINDEDEVICE188構成要素を説明する。スマートグリッドデバイスは、組み込みプロセッサを含むとよく、したがって、DEVICEグループは専用リアルタイムDSPまたはマイクロプロセッサ上で実装されるため、処理構成要素は、SOAサービスよりもリアルタイムプログラムライブラリルーチンに似る。表3:INDEDEVICE構成要素図1はさらに、1つ以上のスマート計器163、家庭内ディスプレイ165、1つ以上のセンサー166および1つ以上の制御167を含むとよい需要家構内179を示す。実際には、センサー166は、需要家構内179にある1つ以上のデバイスにてデータを登録するとよい。例えば、センサー166は、暖房炉、温水ヒーター、空調装置などの、需要家構内179の中の様々な主要電化製品にてデータを登録するとよい。この1つ以上のセンサー166からのデータが、スマート計器163へ送信されるとよく、スマート計器163は、ユーティリティ通信ネットワーク160を介して動作制御センター116へ伝送するためにデータをパッケージ化するとよい。家庭内ディスプレイ165は、スマート計器163および1つ以上のセンサー166から収集されたデータをリアルタイムで閲覧するための出力デバイスを需要家構内において需要家に提供するとよい。さらに、需要家が動作制御センター116と通信できるよう、入力デバイスキーボードなどが家庭内ディスプレイ165に関連付けられてもよい。一実施形態では、家庭内ディスプレイ165は、需要家構内にあるコンピュータを含むとよい。需要家構内165はさらに、需要家構内179の1つ以上のデバイスを制御するとよい制御167を含むとよい。ヒーター、空調装置など、需要家構内179にある様々な電化製品が、動作制御センター116からのコマンドに応じて制御されるとよい。図1に示されているように、需要家構内169は、インターネット168、公衆交換電話ネットワークPSTN169を介して、または専用線を介してコレクタ164を介してなどなど、様々な方法で通信するとよい。列挙された通信チャネルのいずれかを介して、1つ以上の需要家構内179からのデータが送信されるとよい。図1に示されているように、1つ以上の需要家構内179が、ユーティリティ管理ネットワーク160を介して動作制御センター116へ伝送されるようコレクタ164へデータを送信する、スマート計器ネットワーク178複数のスマート計器163を含むを含むとよい。さらに、分散型エネルギー生成/貯蔵162ソーラーパネルなどの様々なソースが、ユーティリティ管理ネットワーク160を介した動作制御センター116との通信のために、監視制御161へデータを送信するとよい。上記のように、動作制御センター116外の電力グリッド内のデバイスは、処理および/または記憶機能を含むとよい。デバイスは、INDESUBSTATION180およびINDEDEVICE188を含むとよい。電力グリッド内の個別のデバイスが追加のインテリジェンスを含むことに加えて、個別のデバイスは、情報センサーデータおよび/または分析データイベントデータなどを含むを交換するため、電力グリッドの状態を分析するため故障の判断など、および電力グリッドの状態を変更するため故障の修正などに、電力グリッド内の他のデバイスと通信するとよい。具体的には、個別のデバイスは、1インテリジェンス処理機能など、2記憶装置上記の分散型記憶装置などおよび3通信上記の1つ以上のバスの使用などを使用するとよい。このようにして、電力グリッド内の個別のデバイスは、動作制御センター116からの監督なしに相互に通信および協働するとよい。例えば、上記で開示されたINDEアーキテクチャは、フィーダ回路上の少なくとも1つのパラメータを感知するデバイスを含むとよい。デバイスはさらに、フィーダ回路上で感知されたパラメータを監視し、感知されたパラメータを分析してフィーダ回路の状態を判断するプロセッサを含むとよい。例えば、感知パラメータの分析は、感知されたパラメータと、所定の閾値との比較を含んでもよく、さらに/または傾向分析を含んでもよい。上記の感知されるパラメータの1つには、波形の感知が含まれてもよく、上記の分析の1つには、感知された波形がフィーダ回路上の故障を示すかどうかを判断することが含まれてもよい。デバイスはさらに、1つ以上の変電所と通信するとよい。例えば、特定の変電所が、特定のフィーダ回路に電力を供給するとよい。デバイスは、その特定のフィーダ回路の状態を感知して、特定のフィーダ回路上に故障があるかどうかを判断するとよい。デバイスは、変電所と通信するとよい。変電所は、デバイスによって判断された故障を分析するとよく、さらに、故障に応じて修正措置をとるとよいフィーダ回路に供給される電力を削減するなど。デバイスが故障を示すデータを送信する波形の分析に基づき例では、変電所は、動作制御センター116からの入力なしに、フィーダ回路に供給される電力を変更するとよい。または変電所は、故障を示すデータと、他のセンサーからの情報とを組み合わせて、故障の分析をさらに精緻化してもよい。変電所はさらに、供給停止インテリジェンスアプリケーションおよび/または故障インテリジェンスアプリケーションなど、動作制御センター116と通信してもよい。したがって、動作制御センター116が、故障を判断してもよく、供給停止の範囲故障の影響を受ける戸数などを判断してもよい。このように、フィーダ回路の状態を感知するデバイスは、動作制御センター116の介入を要求するかしないかに関わらず、考えられる故障を修正するために変電所と協調動作するとよい。別の例として、処理および/またはメモリ機能を使用する追加のインテリジェンスを含むラインセンサーが、グリッドの一部フィーダ回路などにおいてグリッド状態データを作り出してもよい。グリッド状態データは、動作制御センター116の需要応答管理システム155と共有されるとよい。需要応答管理システム155は、ラインセンサーからのグリッド状態データに応答して、フィーダ回路上の需要家サイトの1つ以上のデバイスを制御してもよい。具体的には、需要応答管理システム155は、ラインセンサーがフィーダ回路上の供給停止を示すのに応答して、フィーダ回路から電力を受ける需要家サイトにある電化製品をオフにすることによって、フィーダ回路への負荷を軽減するために、エネルギー管理システム156および/または配電管理システム157に命令してもよい。このように、ラインセンサーは需要応答管理システム155とともに、故障したフィーダ回路から自動的に負荷を移し、続いて故障を隔離するとよい。さらに別の例として、電力グリッド内の1つ以上のリレーが、それに関連するマイクロプロセッサを有するとよい。これらのリレーは、故障の判断、および/または電力グリッドの制御のために、電力グリッド内にある他のデバイスおよび/またはデータベースと通信するとよい。INDSIntelligentNetworkDataServices:インテリジェントネットワークデータサービスの概念およびアーキテクチャアウトソースされるスマートグリッドデータ/解析サービスモデルスマートグリッドアーキテクチャの1つの応用は、ユーティリティが、組織内に従来の制御システムおよび関係する運用システムを保持しながら、グリッドデータ管理および解析サービスを契約できるようにする。このモデルでは、ユーティリティはグリッドセンサーおよびデバイスを設置および所有するとよく上記のように、グリッドデータ搬送通信システムは、所有および運用しても、アウトソースしてもよい。グリッドデータは、ユーティリティからリモートのインテリジェントネットワークデータサービスINDSホスティングサイトへ流れ、そこでデータが管理、記憶および分析されてもよい。その結果、ユーティリティは、適切なサービス財務モデルのもとでデータおよび解析サービスを契約することもできる。ユーティリティは、料金を払う代わりに、初期資本支出投資と、スマートグリッドデータ/解析インフラストラクチャの継続的な管理、サポートおよび改良費を回避することができる。上記のINDE参照アーキテクチャは、本願明細書に記載される構成をアウトソースするのに適している。スマートグリッドサービスのINDSアーキテクチャINDSサービスモデルを実装するために、INDE参照アーキテクチャは、リモートでホストされるとよい構成要素のグループと、ユーティリティに残るとよいものとに区分されるとよい。図6は、INDECORE120がリモートにされるとユーティリティアーキテクチャがどのように見えると考えられるかを示す。サーバが、INDECORE120の一部として含まれるとよく、リモートシステムへのインターフェースとして機能するとよい。ユーティリティシステムには、これが仮想INDECORE602に見えるとよい。図6の全体的なブロック図600が示すように、INDESUBSTATION180およびINDEDEVICE188グループは、図1に示されたものから変化していない。さらに、複数バス構造も、やはりユーティリティにて採用されるとよい。INDECORE120は、図7のブロック図700が示すようにリモートでホストされるとよい。ホスティングサイトでは、ユーティリティのINDS契約者をサポートするために、必要に応じINDECORE120が設置されるとよい北米INDSホスティングセンター702として示されている。各CORE120は、モジュラーシステムであり、その結果新たな契約者の追加は定型操作であるとよい。電気ユーティリティとは別の関係者が、INDECORE120の1つ、いくつかまたはすべてのソフトウェアと、INDSホスティングサイトから各ユーティリティのINDESUBSTATION180およびINDEDEVICE188にダウンロードされるアプリケーションとを管理およびサポートするとよい。通信を促進するために、契約ユーティリティの動作センターならびにINDSホスティングサイトに到達することができるネットワーク704例えばMPLSまたはその他のWANなどを介した高帯域低遅延通信サービスが使用されるとよい。図7に示されているように、カリフォルニア州、フロリダ州およびオハイオ州など、様々なエリアにサービスが提供されるとよい。このような運用のモジュール性は、異なる様々なグリッドの効率的な管理を可能にするのみではなく、グリッド間のよりよい管理も可能にする。1つのグリッドにおける不具合が、周辺のグリッドにおける動作に影響を及ぼす恐れがある場合がある。例えば、オハイオ州のグリッドにおける不具合が、中部大西洋岸のグリッドなど、周辺のグリッドにおける動作に対しカスケード効果を有することもある。図7に示されているモジュール構造を使用することで、個別のグリッドの管理およびグリッド間動作の管理が可能になる。具体的には、全体的なINDSシステムプロセッサおよびメモリを含むが、様々なINDECORE120間の対話を管理するとよい。これは、1つのグリッドから別のグリッドへ波及する破局故障の可能性を軽減するとよい。例えば、オハイオ州のグリッドにおける不具合が、中部大西洋岸のグリッドなど、周辺のグリッドに波及することもある。オハイオ州のグリッドの管理専用のINDECORE120は、オハイオ州のグリッドにおける不具合の修正を試みるとよい。さらに、全体的なINDSシステムが、波及不具合が周辺グリッドで生じる可能性を軽減することを試みるとよい。INDECOREにおける機能性の具体的な例図1、6および7に示されているように、様々な機能性ブロックにより表されているがINDECORE120に含まれており、示されているもののうち2つは、計器データ管理サービスMDMS:meterdatamanagementservices121ならびに計測解析およびサービス122である。アーキテクチャのモジュール性が理由で、MDMS121ならびに計測解析およびサービス122などの様々な機能性を組み込むことができる。可観測性プロセス上記のように、アプリケーションサービスの1つの機能性は、可観測性プロセスを含むとよい。可観測性プロセスは、ユーティリティがグリッドを観測できるようにするとよい。こうしたプロセスは、グリッド上のすべてのセンサーおよびデバイスから受信される生データを解釈して、それを実用的な情報へ変えることを担当するとよい。図8は、可観測性プロセスのいくつかの例の列挙を含む。図9は、グリッド状態測定動作プロセスのフロー図900を示す。図のように、ブロック902にて示されているように、データスキャナが計器データをリクエストするとよい。リクエストは、1つ以上のグリッドデバイス、変電所コンピュータおよびラインセンサーRTUへ送信されるとよい。デバイスは、ブロック904、908、912にて示されているように、リクエストに応答して動作データを収集するとよく、ブロック906、910、914にて示されているように、データ電圧、電流、有効電力および無効電力データなどの運用データのうちの1つ、いくつかまたはすべてなどを送信するとよい。データスキャナは、ブロック926にて示されているように、運用データを収集して、ブロック928にて示されているように、データを運用データストアへ送信するとよい。ブロック938にて示されているように、運用データストアは運用データを記憶するとよい。ブロック940にて示されているように、運用データストアはさらに、データのスナップショットをヒストリアンへ送信して、ブロック942にて示されているように、ヒストリアンは、データのスナップショットを記憶するとよい。計器状態アプリケーションは、ブロック924に示されているように、計器データのリクエストを計器DCEdatacollectionengine:データ収集エンジンへ送信するとよく、その結果として計器DCEは、ブロック920にて示されているように、計器データ収集のリクエストを1つ以上の計器へ送信する。この1つ以上の計器は、ブロック916にて示されているように、リクエストに応答して計器データを収集し、ブロック918にて示されているように、電圧データを計器DCEへ送信する。計器DCEは、ブロック922にて示されているように電圧データを収集して、ブロック928にて示されているようにデータをデータのリクエスタへ送信するとよい。計器状態アプリケーションは、ブロック930にて示されているように、計器データを受信し、ブロック932にて示されているように、それが単一値プロセスsinglevalueprocessに関するか、電圧プロフィールグリッド状態voltageprofilegridstateに関するかを判断するとよい。単一値プロセスに関するものであれば、ブロック936にて示されているように、計器データはリクエストしているプロセスへ送信される。計器データが、後からグリッド状態を判断するために記憶されるものであれば、ブロック938にて示されているように、計器データは運用データストアに記憶される。ブロック940にて示されているように、運用データストアはさらに、データのスナップショットをヒストリアンへ送信して、ブロック942にて示されているように、ヒストリアンは、データのスナップショットを記憶する。図9はさらに、需要応答DRに関するアクションを示す。需要応答は、例えば電気の需要家にその消費を、緊急時、または市場価格に応じて削減させるなど、供給条件に応じて需要家の電気消費を管理するための動的需要メカニズムを指す。これは、実際に使用電力を削減することを伴っても、またはオンサイト発電を開始することによってもよく、オンサイト発電は、グリッドと並列接続されていても、されていなくてもよい。これは、同じタスクを実行するために継続的に、または当該タスクが実行されるときに必ず、より少ない電力を使用することを意味する、エネルギー効率とは異なると考えられる。需要応答では、1つ以上の制御システムを使用する需要家が、ユーティリティによるリクエストまたは市場価格条件に応じて負荷を減らすとよい。サービス光、機械、空調は、緊急の時間フレームの間、事前計画された負荷優先順位付けスキームに従って削減されるとよい。負荷制限の代替手段は、電力グリッドを補うための、電気のオンサイト発電である。電気供給が不足する状況のもとでは、需要応答により、最高値および全般的な電気価格の変動が大幅に低減され得る。需要応答は、一般に、消費者が需要を減らすことを促し、それによって電気のピーク需要を減らすよう使用されるメカニズムを指すために使用される。電気システムは、一般に、ピーク需要それに加えてエラーおよび予期せぬイベントに備えた余裕に対応するような規模であり、ピーク需要が減れば、全体的な設備および資本コスト要件が緩和され得る。一方、発電容量の構成次第で、需要応答は、大量生産低需要のときに需要負荷を増やすためにも使用され得る。それによって、一部のシステムは、低需要および高需要または安値および高値の期間の間の裁定取引を行うためのエネルギー貯蔵を促すこともできる。システムにおいて、風力などの断続的な電力源の割合が増えるにつれて、需要応答は電気グリッドの効果的な管理にますます重要になると考えられる。ブロック954にて示されているように、DR状態アプリケーションは、DR利用可能容量をリクエストするとよい。続いて、ブロック948にて示されているように、DR管理システムは、1つ以上のDRホームデバイスからの利用可能容量をリクエストするとよい。この1つ以上のホームデバイスは、ブロック944にて示されているように、リクエストに応答して利用可能なDR容量を収集して、ブロック946にて示されているように、DR容量および応答データをDR管理システムへ送信するとよい。DR管理システムは、ブロック950にて示されているように、DR容量および応答データを収集して、ブロック952にて示されているように、DR容量および応答データをDR状態アプリケーションへ送信するとよい。DR状態アプリケーションは、ブロック956にて示されているように、DR容量および応答データを受信して、ブロック958にて示されているように、容量および応答データを運用データストアへ送信するとよい。ブロック938にて示されているように、運用データストアはDR容量および応答データデータを記憶するとよい。ブロック940に示されているように、運用データストアはさらに、データのスナップショットをヒストリアンへ送信して、ブロック942に示されているように、ヒストリアンは、データのスナップショットを記憶するとよい。ブロック974にて示されているように、変電所コンピュータは、変電所アプリケーションからのアプリケーションデータをリクエストするとよい。それに応答して、ブロック964にて示されているように、変電所アプリケーションは、変電所デバイスからのアプリケーションをリクエストするとよい。変電所デバイスは、ブロック960にて示されているように、アプリケーションデータを収集して、ブロック962にて示されているように、変電所デバイスにアプリケーションデータを送信するとよい電圧、電流、有効電力および無効電力データのうちの1つ、いくつかまたはすべてを含むとよい。変電所アプリケーションは、ブロック966にて示されているように、アプリケーションデータを収集して、ブロック968にて示されているように、アプリケーションデータをリクエスタ変電所コンピュータであってもよいへ送信するとよい。変電所コンピュータは、ブロック970にて示されているように、アプリケーションデータを受信して、ブロック972にて示されているように、アプリケーションデータを運用データストアへ送信するとよい。グリッド状態測定および運用データプロセスは、所定の時点でのグリッド状態およびグリッドトポロジを抽出すること、ならびにこの情報を他のシステムおよびデータストアに提供することを含み得る。サブプロセスは、1グリッド状態情報を測定および保存することこれは、前に説明した、グリッドに関連する運用データに関係する、2グリッド状態情報を他の解析アプリケーションへ送信することこれは、分析アプリケーションなどの他のアプリケーションがグリッド状態データにアクセスできるようにする、3グリッド状態スナップショットを接続性/運用データストアに維持することこれは、接続性/運用データストアのグリッド状態情報を適切なフォーマットで更新すること、ならびに或る時点でのグリッドトポロジが後の時点で抽出可能なように、この情報を維持のためにヒストリアンへ転送することを可能にする、4デフォルトの接続性および現在のグリッド状態に基づき、或る時点でのグリッドトポロジを抽出することこれは、下記でさらに詳しく説明するように、ヒストリアン内のグリッド状態の所定の時点でのスナップショットを、接続性データストア内の基礎となる接続性に適用することによって、その時点でのグリッドトポロジを提供するならびに5リクエストに応じてグリッドトポロジ情報をアプリケーションに提供することを含むとよい。サブプロセス4に関しては、グリッドトポロジはリアルタイム、30秒前、1ヶ月前など、所定時間に関して抽出され得る。グリッドトポロジを再現するために、複数のデータベースが使用されてもよく、グリッドトポロジを再現するために複数のデータベース内のデータにアクセスするプログラム。1つのデータベースは、基礎となる接続性データを記憶するリレーショナルデータベースを含むとよい接続性データベース。接続性データベースは、ベースライン接続性モデルを判断するための、施工完了時のグリッドトポロジ情報を保持しているとよい。電力グリッド内の回路の追加または変更など例えば、電力グリッドに追加される追加のフィーダ回路、電力グリッドの改良に応じて、アセットおよびトポロジ情報が定期的にこのデータベースに対し更新されるとよい。接続性データベースは、変化しないことから静的と見なされてもよい。接続性データベースは、電力グリッドの構造に変更があれば変化するとよい。例えば、フィーダ回路の追加など、フィーダ回路に変更があれば接続性データベースが変化するとよい。第2のデータベースは、動的データを記憶するために使用されるとよい。第2のデータベースは、非リレーショナルデータベースを含むとよい。非リレーショナルデータベースの一例は、時系列の非運用データおよび過去の運用データを記憶する、ヒストリアンデータベースを含み得る。ヒストリアンデータベースは、1タイムスタンプ、2デバイスID、3データ値および4デバイスステータスなどの一連のフラットレコードを記憶するとよい。さらに、記憶されるデータは圧縮されるとよい。このため、電力グリッド内の動作/非運用データが容易に記憶されるとよく、かなりの量のデータが利用可能であるにもかかわらず、管理可能であるとよい。例えば、5テラバイトオーダーのデータが、グリッドトポロジを再現するために用いられるよういつでもオンラインであってもよい。データは単純なフラットレコードで記憶されるため編成手法が用いられないなど、データの記憶における効率性が与えられる。下記でさらに詳しく説明するように、データは、データ要素識別子などの特定のタグによりアクセスされてもよい。グリッドの様々な解析が、特定の時点のグリッドトポロジを入力として受信することを望み得る。例えば、電力品質、信頼性、アセット正常性などに関する解析が、グリッドトポロジを入力として使用し得る。グリッドトポロジを判断するために、接続性データベース内のデータにより定義されるベースライン接続性モデルがアクセスされるとよい。例えば、特定のフィーダ回路のトポロジが求められる場合、ベースライン接続性モデルは、電力グリッド内の特定のフィーダ回路内の様々なスイッチを定義するとよい。その後、特定のフィーダ回路内のスイッチの値を判断するために、ヒストリアンデータベースがアクセスされるとよい特定の時間に基づき。次に、特定の時間の特定のフィーダ回路の表現を生成するために、プログラムが、ベースライン接続性モデルおよびヒストリアンデータベースからのデータを結合するとよい。グリッドトポロジの判断のより複雑な例は、インタータイスイッチinter-tieswitchおよび区分スイッチを有する複数のフィーダ回路例えばフィーダ回路Aおよびフィーダ回路Bを含み得る。特定のスイッチインタータイスイッチおよび/または区分スイッチなどのスイッチ状態に応じて、フィーダ回路のセクションは、フィーダ回路Aまたはフィーダ回路Bに属し得る。グリッドトポロジを判断するプログラムは、特定の時間の接続性例えば、どの回路がフィーダ回路Aまたはフィーダ回路Bに属するかを判断するために、ベースライン接続性モデルおよびヒストリアンデータベース両方からのデータにアクセスするとよい。図10は、非運用データプロセスのフロー図1000を示す。ブロック1002にて示されているように、非運用抽出アプリケーションが、非運用データをリクエストするとよい。それに応答して、ブロック1004にて示されているように、データスキャナが非運用データを集めるとよく、それによって、ブロック1006、1008、1110にて示されているように、グリッドデバイス、変電所コンピュータおよびラインセンサーRTUなどの電力グリッド内の様々なデバイスが非運用データを収集するとよい。上記のように、非運用データは、温度、電力品質などを含むとよい。ブロック1012、1014、1116にて示されているように、グリッドデバイス、変電所コンピュータおよびラインセンサーRTUなど、電力グリッド内の様々なデバイスが、非運用データをデータスキャナへ送信するとよい。データスキャナは、ブロック1018にて示されているように、非運用データを収集して、ブロック1020にて示されているように、非運用データを非運用抽出アプリケーションへ送信するとよい。非運用抽出アプリケーションは、ブロック1022にて示されているように、非運用データを収集して、ブロック1024にて示されているように、収集した非運用データをヒストリアンへ送信するとよい。ヒストリアンは、ブロック1026にて示されているように、非運用データを受信し、ブロック1028にて示されているように、非運用データを記憶し、ブロック1030にて示されているように、非運用データを1つ以上の解析アプリケーションへ送信するとよい。図11は、イベント管理プロセスのフロー図1100を示す。データは、電力グリッド内の様々なイベントに基づき様々なデバイスから生成されて、イベントバス147を介して送信されるとよい。例えば、ブロック1102にて示されているように、計器データ収集エンジンは、電力供給停止/復旧通知情報をイベントバスへ送信するとよい。ブロック1104にて示されているように、ラインセンサーRTUは、故障メッセージを生成して、その故障メッセージをイベントバスへ送信するとよい。変電所は解析は、ブロック1106にて示されているように、故障および/または供給停止メッセージを生成するとよく、その故障および/または供給停止メッセージをイベントバスへ送信するとよい。ブロック1108にて示されているように、ヒストリアンは、信号挙動をイベントバスへ送信するとよい。さらに、様々なプロセスがイベントバス147を介してデータを送信するとよい。例えば、ブロック1110にて示されているように、故障インテリジェンスプロセスが、イベントバスを介して故障分析イベントを送信するとよい。ブロック1114にて示されているように、イベントバスは様々なイベントを収集するとよい。さらに、ブロック1120にて示されているように、複合イベント処理CEPサービスが、イベントバスを介して送信されたイベントを処理するとよい。CEPサービスは、同時に発生する複数の高速リアルタイムイベントメッセージストリームに対するクエリを処理するとよい。ブロック1118にて示されているように、CEPサービスによる処理の後、イベントデータはイベントバスを介して送信されるとよい。さらに、ブロック1116にて示されているように、ヒストリアンが、記憶のために1つ以上のイベントログを、イベントバスを介して受信するとよい。さらに、ブロック1122にて示されているように、イベントデータは、供給停止管理システムOMS、供給停止インテリジェンス、故障解析など、1つ以上のアプリケーションにより受信されるとよい。このように、イベントバスは、イベントデータをアプリケーションへ送信するとよく、それによって、データを他のデバイスまたは他のアプリケーションに利用可能にしないというサイロ問題を回避する。図12は、需要応答DRシグナリングプロセスのフロー図1200を示す。ブロック1244にて示されているように、DRが配電動作アプリケーションによりリクエストされるとよい。それに応答して、グリッド状態/接続性は、ブロック1202にて示されているように、DR利用可能性データを収集するとよく、ブロック1204にて示されているように、データを送信するとよい。配電動作アプリケーションは、ブロック1246にて示されているように、DR利用可能性最適化を、イベントバスを介してブロック12541つ以上のDR管理システムに配布するとよい。DR管理システムは、ブロック1272にて示されているように、DR情報および信号を1つ以上の需要家構内へ送信するとよい。この1つ以上の需要家構内は、ブロック1266にて示されているように、DR信号を受信し、ブロック1268にて示されているように、DR応答を送信するとよい。DR管理は、ブロック1274にて示されているように、DR応答を受信して、ブロック1276にて示されているように、動作データバス146、請求データベースおよびマーケティングデータベースのうちの1つ、いくつかまたはすべてにDR応答を送信するとよい。ブロック1284、1288にて示されているように、請求データベースおよびマーケティングデータベースは、応答を受信するとよい。動作データバス146も、ブロック1226にて示されているように、応答を受信して、ブロック1228にて示されているように、DR応答および利用可能容量をDRデータ収集へ送信するとよい。DRデータ収集は、ブロック1291にて示されているように、DR応答および利用可能容量を処理して、そのデータを、ブロック1294にて示されているように、動作データバスへ送信するとよい。ブロック1230にて示されているように、動作データバスは、DR利用可能性および応答を受信して、それをグリッド状態/接続性へ送信するとよい。ブロック1208にて示されているように、グリッド状態/接続性はデータを受信するとよい。受信されたデータは、グリッド状態データを判断するために使用されるとよく、それが動作データバスを介してブロック1220送信されるとよいブロック1206。ブロック1248にて示されているように、配電動作アプリケーションは、グリッド状態データDR最適化のためのイベントメッセージとしてを受信するとよい。ブロック1250にて示されているように、配電動作アプリケーションは、グリッド状態データならびにDR利用可能性および応答を使用して配電最適化を実行し、配電データを生成するとよい。配電データは、ブロック1222にて示されているように、動作データバスにより読み出されるとよく、ブロック1240にて示されているように、接続性抽出アプリケーションへ送信されるとよい。運用データバスは、データを配電動作アプリケーションへ送信するとよくブロック1224、次に配電動作アプリケーションが、1つ以上のDR信号を1つ以上のDR管理システムへ送信するとよいブロック1252。イベントバスは、この1つ以上のDR管理システムそれぞれに関して信号を収集してブロック1260、DR信号を各DR管理システムへ送信するとよいブロック1262。次に、DR管理システムは上記のようにDR信号を処理するとよい。ブロック1214にて示されているように、通信動作ヒストリアンは、データをイベントバスへ送信するとよい。ブロック1212にて示されているように、通信動作ヒストリアンはさらに、生成ポートフォリオデータgenerationportfoliodataを送信するとよい。または、Ventyx登録商標などのアプリケーションが、ブロック1232にて示されているように、仮想発電所VPP:virtualpowerplant情報をリクエストするとよい。動作データバスは、ブロック1216にて示されているように、VPPデータを収集して、ブロック1218にて示されているように、データをアプリケーションへ送信するとよい。アプリケーションは、ブロック1234にて示されているように、VPPデータを収集して、ブロック1236にて示されているように、システム最適化を実行して、ブロック1238にて示されているように、イベントバスへVPP信号を送信するとよい。イベントバスは、ブロック1256にて示されているように、VPP信号を受信して、ブロック1258にて示されているように、VPP信号を配電動作アプリケーションへ送信するとよい。その結果、配電動作アプリケーションは、上記のようにイベントメッセージを受信および処理するとよい。ブロック1278にて示されているように、接続抽出アプリケーションは、ブロック1290にて示されているようにマーケティングデータベースへ送信される新規需要家データを、抽出するとよい。ブロック1280にて示されているように、新規需要家データはグリッド状態/接続性へ送信されるとよく、その結果、ブロック1210にて示されているように、グリッド状態接続性は新たなDR接続性データを受信するとよい。オペレーターは、ブロック1242にて示されているように、適切な場合、1つ以上のオーバーライド信号を送信するとよい。オーバーライド信号は、配電動作アプリケーションへ送信されるとよい。オーバーライド信号は、ブロック1264にて示されているようにエネルギー管理システム、ブロック1282にて示されているように請求データベース、および/またはブロック1286にて示されているようにマーケティングデータベースへ送信されるとよい。上記の通り、ユーティリティグリッド内の様々なデバイスが、INDECORE120またはその他何らかのコマンドサイトcommandsiteから生成されるコマンドを介して制御され得る。コマンドは、手動入力を介して生成されてもよく、または自動生成により生じてもよい。ユーティリティグリッド内のデバイスの1つ、いくつかまたはすべてが、特定の形での動作のために1つ以上の個別のコマンドを受信し得る。例えば、需要家構内179を監視しているスマート計器163は、関連する需要家構内に供給されている電力の切断、接続または調節のための個別のコマンドを受信し得る。センサー166および制御167などの需要家構内のデバイスが、大型電化製品などの特定のデバイスへの電力を削減するコマンドを受信してもよい。ユーティリティ需要家は、例えば経済的理由、または環境にやさしい負荷制御戦略の一環としてなど、様々な理由から、特定の大型電化製品または他の電動デバイスに関して、電力の削減に合意することもある。典型的には、各デバイスがより多くの電力またはより少ない電力を消費するよう個別に切断、循環または制御されるよう調節しても、ユーティリティグリッドの動作に大きな影響はもたらさない。しかし、十分に短い時間ウィンドウ内に十分な数のデバイスがそのように制御されると、同時に、または比較的近い時間に動作するデバイスすべての複合効果が、グリッドの不安定性を発生または増大させるなどの望ましくない影響をユーティリティグリッドにもたらすことがあり得る。例えば、比較的短い時間ウィンドウ内に、いくつかの需要家構内179にわたって、十分な数の需要家構内デバイスがオフにするよう命令されると、この電力の削減により広域停電が発生しかねない。この種の問題は、不注意または偶然によるコマンド入力によって、または悪意のある活動によって生じ得るであろう。図13は、ユーティリティグリッド内の様々なデバイスを制御するために生成されたコマンドをフィルタリングするよう構成されたコマンドフィルタモジュール1300を含む、コマンドフィルタシステムの例である。コマンドフィルタモジュール1300は、ユーティリティグリッド内のデバイスによって受信される一部または全部のコマンドを受信し、デバイスでの受信に先立って、コマンドの実行がユーティリティグリッド内に望ましくない影響をもたらすと考えられるかどうかを判断するとよい。コマンドフィルタモジュール1300は、コマンドの一部または全部を実行に関して許可して、実行のために個々のデバイスによって受信されるよう、許可されたコマンドを伝送してもよく、または許可されないコマンドが実行のために個々のデバイスによって受信されるのを防いでもよい。一例では、コマンドフィルタモジュール1300は、メモリ1304と通信しているプロセッサ1302を有する1つ以上のコンピュータデバイス1301上で実行されてもよい。モジュールという用語は、1つまたは複数の実行可能モジュールを含むよう定義され得る。本願明細書に記載のように、モジュールは、プロセッサ1302によって実行可能なソフトウェア、ハードウェアまたはその何らかの組み合わせを含むよう定義される。ソフトウェアモジュールは、メモリ1304またはその他のメモリデバイスに記憶され、プロセッサ1302またはその他のプロセッサによって実行可能な命令を含むとよい。ハードウェアモジュールは、プロセッサ1302による実行のために実行可能であり、かつ/または指示され、かつ/または制御される様々なデバイス、コンポーネント、回路、ゲート、回路基板および同様のものを含むとよい。メモリ1304は、1つ以上のメモリを含むとよく、キャッシュ、バッファ、RAM、取り外し可能媒体、ハードドライブまたはその他のコンピュータ可読記憶媒体などのコンピュータ可読記憶媒体またはメモリであればよい。コンピュータ可読記憶媒体は、様々なタイプの揮発性および不揮発性記憶媒体を含み得る。例えば多重処理、多重タスキング、並列処理および同様のものなど、様々な処理技術が、プロセッサ1302によって実装され得る。プロセッサ1302は、1つ以上のプロセッサを含むとよい。一例では、コマンドフィルタモジュール1300は、メモリ1304上に記憶されプロセッサ1302によって実行される1つ以上のソフトウェアモジュールであってもよい。コマンドフィルタモジュール1300は、プロセッサ1302によって実行される様々なサブモジュールを含むとよい。プロセッサ1302は、INDECORE120、またはユーティリティグリッド内の他の何らかのサイト内に位置するとよい。一例では、コマンドフィルタモジュール1300は、イベントバス147上で動作するよう実行されてもよい。コマンドフィルタモジュール1300は、ユーティリティグリッド内のデバイスの動作を制御することを目的としたコマンド1306を受信するとよい。コマンド1306は、同時に、または或る所定の時間ウィンドウ内に、個々のデバイスによって実行されるよう意図されたコマンドを表すとよい。例えば、コマンド1306は、センサー166、制御167または家庭内ディスプレイ165に接続された、需要家構内179の中のデバイスにより受信されるよう意図されたものであってもよい。以下、図14を参照する。リアルタイム複合イベント処理バス147上で実行されるよう構成されたコマンドフィルタモジュール1300の例が示されている。図14の例は、図1~6に関して記載されたINDEアーキテクチャにおいて実装されるとよい。図14に示されているように、ユーティリティグリッド内の様々なデバイスが、手動制御を介して実装され得る。例えば、スマート計器ネットワーク178内の様々なスマート計器163によって受信される、計器接続/切断コマンドなどの計器コマンドMC:metercommand1404を伝送するために、グラフィカルユーザインターフェースGUI:graphicaluserinterface1402がオペレーターによって使用されてもよい。計器コマンド1404は、スマート計器163から受信された計器データ1405を伝送することができるデバイスを経由して伝達されてもよい。GUI1402は、計器コマンド1404を計器データ管理システム121へ伝送するとよい。続いて、計器コマンド1404は、計器データ収集エンジン1406によって受信されるとよく、計器データ収集エンジン1406は、ユーティリティシステム内のスマート計器163に関するデータ、コマンド、イベントおよびその他任意のデータを収集するよう構成されたソフトウェアモジュール、ハードウェアモジュールまたは組み合わせであるとよい。一例では、計器データ収集エンジン1406は、計器データ収集ヘッドエンド単数または複数153上に存在するとよい。別の例では、計器データ収集エンジン1406は、ユーティリティグリッド内に複数の計器データ収集エンジン1406が存在するよう、分散していてもよい。計器データ収集エンジン1406によって収集されたデータは、運用/非運用データバス146上で伝達され、1つ以上の計器データリポジトリ133へ伝送されて、それにより記憶されるとよい。計器コマンド1404は、イベントバス147およびコマンドフィルタモジュール1300によって受信されるとよい。コマンドフィルタモジュール1300は、計器コマンド1404を分析して、そのコマンドが、実行されると、ユーティリティグリッド内で望ましくない影響を発生させる可能性があるかどうかを判断するとよい。コマンドフィルタモジュール1300は、個々のスマート計器163によって受信および実行されるよう、許可された計器コマンドAMC:authorizedmetercommand1407を伝送するとよい。許可された計器コマンド1407は、計器コマンドプロセッサ1408へ伝送されるとよい。計器コマンドプロセッサ1408は、許可された計器コマンド1407の内容および意図された受信先を判断するとよい。計器コマンドプロセッサ1408は、コマンドを計器通信ネットワーク1410へ伝送するとよい。計器通信ネットワーク1410は、計器データ、計器イベントおよび計器コマンドを、ユーティリティグリッド内でスマート計器ネットワーク178に結合された全部または一部のスマート計器163へ伝送するよう構成されているとよい。許可された計器コマンド1407は、接続またはユーティリティグリッドからの切断のために、需要家構内179のスマート計器163によって最終的に受信されるとよい。GUI1411は、計器データ収集エンジン1406に直接伝送される計器コマンド1404を受信してもよい。様々な需要家構内デバイスが、コマンドフィルタモジュール1300によって許可されるDRコマンドDRC:DRcommand1412を受信し得る。例えば、DRコマンド1412を手動で入力するために、GUI1414がオペレーターによって使用されてもよい。DRコマンド1412は、VPP給電指令システム1416によってGUI1414から受信されるとよい。DRコマンド1412は、価格設定、環境要因および負荷制御など、考慮すべき様々な事項に基づくとよい。VPP給電指令システム1416は、DRコマンド1412を受信して、DRコマンド1412に基づき制御される需要家構内デバイスを判断するよう構成されているとよい。DRコマンド1412は、動作/非動作データバス146によって受信されるとよい。他の例では、DRコマンド1412は、VPP給電指令システム1416からイベントバス147へ伝送されてもよい。DRコマンド1412は、DR信号分配DR応答データ収集エンジンDCEシステム1418によって、動作/非動作データバス146から受信されるとよい。DR信号分配DR応答データ収集エンジン1418は、DR管理システム154内など、INDECORE120内で、またはユーティリティグリッド内もしくはユーティリティグリッドから離れた他の何らかのサイトにて動作するよう構成され得る。DRコマンド1412は、DR信号分配DR応答DCEシステム1418によって分析されて、コマンドを受信する特定のデバイスの判断など、望まれる需要応答がどのように実行されるべきかが判断されるとよい。DR信号分配DR応答DCEシステム1418は、DRコマンド1412を、個別のデバイスまたは従属するデバイスグループ用に分割するとよい。続いて、DRコマンド1412は、イベントバス147およびコマンドフィルタモジュール1300によって受信されて、DRコマンド1412が、需要家構内179の中のデバイスによる実行を許可されるかどうかが判断されるとよい。DRコマンド1412が、需要家構内179の中のデバイスによって実行される場合、許可されたDRコマンドADRC:authorizedDRcommand1417が、コマンドフィルタモジュール1300によってDRコマンドプロセッサ1420へ伝送されるとよい。DRコマンドプロセッサ1420は、許可されたDRコマンド1417の内容を判断して、許可されたDRコマンド1417を受信する、特定の需要家構内179および特定の需要家構内179の中のデバイスを特定するとよい。許可されたDRコマンド1417は、ユーティリティグリッド内の需要家構内179の全部または一部と相互接続されているとよいDR通信ネットワーク1422に、DRコマンドプロセッサ1420によって伝送されるとよい。許可されたDRコマンド1417は、各需要家構内179の中の意図されたデバイスによって受信されるとよく、ホームDRゲートウェイ1421によって分配されるとよい。スイッチングコマンドなどの他のタイプのコマンドが、ユーティリティグリッドに手動で入力されてもよい。例えば、スイッチングコマンドSC:switchingcommand1424が、オペレーターによってGUI1425を用いて入力されてもよい。一例では、スイッチングコマンド1424は、例えばセクショナライザー、リクローザーおよびインタータイなどのユーティリティグリッド内のスイッチングデバイスswitchingdevice1436を接続または切断することを目的としてもよい。スイッチングコマンド1424は、セクショナライザー制御1426によって受信されるとよく、セクショナライザー制御1426は、スイッチングコマンド1424を処理して、スイッチングコマンドを実行するよう動作させられるとよいユーティリティグリッド内の特定のデバイスを判断するよう構成されているとよい。スイッチングコマンド1424は、イベントバス147によって受信されコマンドフィルタモジュール1300によって処理されるとよい。許可されたスイッチングコマンドASC:Authorizedswitchingcommand1430は、1つ以上の制御コマンドプロセッサ1434へ伝送されるとよい。制御コマンドプロセッサ1434は、許可されたスイッチングコマンド1430を、特定の許可されたスイッチングコマンド1430を受信するよう意図された個々のスイッチングデバイス1436へ伝送するとよい。補償器コマンドCC:Compensatorcommand1427が、オペレーターによってGUI1429を用いて入力されてもよい。補償器コマンド1427は、例えばコンデンサ、線路電圧降下補償器、負荷タップ切替器LTC:loadtapchangerおよび電圧調整器など、ユーティリティグリッドの諸条件を補償するために使用されるデバイスによって受信されるよう意図されているとよい。補償器コマンド1427は、補償器制御1431によって受信されるとよく、補償器制御1431は、補償器コマンド1427の内容を判断し、補償器コマンド1427を受信するよう意図された特定の補償器デバイスcompensatordeviceによる受信のために補償器コマンド1427を整形するよう構成されている。補償器コマンド1427は、コマンドフィルタモジュール1300により処理されるようイベントバス147へ、補償器制御1431によって伝送されるとよい。許可された補償器コマンドACC:Authorizedcompensatorcommand1432は、制御コマンドプロセッサ1434へ伝送されるとよい。制御コマンドプロセッサ1434は、許可された補償器コマンド1432を、意図された補償器デバイス1438に提供するとよい。再び図13を参照する。コマンドフィルタモジュール1300の詳細な動作についてさらに説明することができる。コマンド1306は、計器コマンド1404、DRコマンド1416、スイッチングコマンド1424および補償器コマンド1427などのデバイスコマンドを含むとよい。コマンド1306は、コマンドフィルタモジュール1300によって受信されると、コマンド受信モジュール1308によって受信されるとよい。コマンド受信モジュール1308は、コマンド1306を処理して、コマンド1306それぞれの望まれる受信先の内容を判断するとよい。コマンド受信モジュール1308は、処理されたコマンド1310をルール適用モジュール1312に提供するとよい。処理されたコマンド1310は、コマンド受信モジュール1308によって実行された処理、コマンド1306の再フォーマッティングまたは両方に関する追加データを含むとよい。処理されたコマンド1310を受信すると、ルール適用モジュール1312は、所定の一連のルールを、処理されたコマンド1310に適用して、実行されるべきコマンド1306があればそれを許可するとよい。ルール適用モジュール1312は、処理されたコマンド1310に適用される1つ以上のルールを含むルールデータセット1314を読み出すとよい。ルールの適用に基づき、ルール適用モジュール1312は、処理されたコマンド1310のうちのどのコマンド1306が、実行に関して許可されるかを判断するとよい。ルール適用モジュール1312は、処理されたコマンド1310の一部を実行に関して許可してもよく、またはルール適用モジュール1312によって分析されているコマンドのすべてがまとめて許可または拒否されるよう、処理されたコマンド1310の許可を一括で行ってもよい。許可の後、ルール適用モジュール1312は、ルール適用モジュール1312の許可決定とともにコマンド1306を含む許可データセット1316を生成するとよい。許可データセット1316は、コマンド伝送モジュール1318によって受信されるとよい。コマンド伝送モジュール1318は、個々のデバイスによる実行に関して許可されたコマンドの1つ、いくつか、またはすべてを特定するとよい。特定すると、コマンド伝送モジュール1318は、意図されたデバイスに最終的に受信されるよう、許可されたコマンド1320を伝送するとよい。実行の許可をされないコマンドに関して、コマンド伝送モジュール1318は、GUI1402、1411、1414および1425のうちの1つなど、許可されないコマンドが生じたところへ通知のために返送される、許可されないコマンドそれぞれの拒否メッセージ1321を生成するとよい。一例では、コマンドフィルタモジュール1300は、イベントバス147上で実行されてもよく、これによりコマンドフィルタモジュール1300は、許可されたコマンド1320を伝送すること、またはイベントバス147が伝送を実行することを可能にすることができる。ルールデータセット1314に含まれるルールは、静的な性質であってもよく、またはユーティリティグリッド内のリアルタイム条件に基づき動的であってもよい。静的ルールは、現在のユーティリティグリッドの例と関係なく不変であってもよい。例えば、スマート計器163、需要家構内179の中のデバイス、スイッチングデバイス1436もしくは補償器デバイス1438または任意の組み合わせなど、所定の時間ウィンドウ内に接続または切断されてよいデバイスの数を制限する、静的ルールが存在してもよい。一例では、ルールは、1時間当たり6の起動など、需要家構内デバイス例えば工業用ポンプが起動されてよいインスタンスの数を制限することを対象にしてもよい。別の例では、ルールは、所定の時間内にオンまたはオフにしてよいスマート計器163の数を制限することを対象にしてもよい。デバイスが接続または切断されるよう命令されてよい期間に関する他のルールが適用されてもよい。ルール適用モジュール1312はさらに、ルールデータセット1314のルールを、ユーティリティグリッドの動的な性質に配慮して適用するよう構成されてもよい。ルール適用モジュール1312は、ユーティリティグリッドの過去の動作データを調べるよう構成されてもよい。一例では、ルール適用モジュール1312は、過去データ136から情報を読み出すよう構成されてもよい。ルール適用モジュール1312は、過去データ136を相互参照しながら、ルールデータセット1314からのルールを、処理されたコマンド1310に適用してもよい。例えば、ルールデータセット1314は、特定のデバイスに関係なくデバイス切断/接続の数に基づくルールを含んでもよい。例えば、関与するデバイスに関係なく、所定のデバイス数のみが、所定の時間内に切断または接続されることが認められてもよい。コマンド1306が、デバイス数閾値よりも多くのデバイスを切断または接続することを対象にしていれば、コマンドフィルタモジュール1300は、過去データ136を分析して、コマンド1306のパターンなどの以前のコマンドパターンが、ユーティリティグリッド内で望ましくない影響をもたらしたかどうかを判断してもよい。過去データに基づき、コマンドが対応する特定のデバイスの接続または切断が、以前にユーティリティグリッドにおいて不都合な問題を発生させていなければ、コマンドは実行に関して許可されるとよい。動的条件を使用するルール適用構成では、ルール適用モジュール1312はさらに、ルールの適用中、接続性データマート131から接続性データ1313を読み出すとよい。過去データ136、接続性データ131およびルールデータセット1314に基づき、ルール適用モジュール1312は、実行に関してコマンド1306が許可されてはならないほどの望ましくない影響を現在のユーティリティグリッド条件が受けるかどうかを判断するとよい。一例では、ルール適用モジュール1312は、過去データ136、接続性データ1313およびルールデータセット1314に基づきコマンドの許可を判断するために、予測モジュール1322を含んでもよい。予測モジュール1322は、コマンドの一部または全部の許可によるユーティリティグリッドへの影響を予測するとよい。予測モジュール1322は、コマンド1306の組み合わせの様々な順列に基づき、ユーティリティグリッドの挙動に関して予測される影響を生成するとよい。一例では、予測モジュール1322は、実行される最多数のコマンド1306として特定されるコマンド1306の組み合わせを、許可のために選択してもよい。他の例では、予測モジュール1306は、グリッド障害閾値に最も近く、かつそれ未満であるなどの他の考慮事項に基づいて、コマンド1306を特定してもよい。グリッド障害閾値は、コマンド1306などのデバイスコマンドを実行するときに、ユーティリティグリッドに対し許容される最小の障害を表してもよい。別の構成では、静的または動的な種々の条件が監視されて、コマンド1306に関して許可決定が実行されてもよい。例えば、電圧条件、電流条件または両方が、ユーティリティグリッドの戦略上重要な部分で監視されてもよい。周囲温度などの環境条件も監視されてもよい。構成済みユーティリティグリッドは、スマートデバイスが後付けされるとき、種々の通信アクセスポイントを有することもある。構成済みユーティリティグリッドはさらに、図14に関して記載されたものとは異なる確立した通信ネットワークを含むこともある。図15~17は、代わりの通信ネットワーク構成を有するユーティリティグリッドの例を示す。図15~17では、コマンドフィルタモジュール1300は、例えば接続/切断コマンドを受信するよう構成されたデバイスに対してユーティリティグリッド内の種々の部分で実行され得る。図15では、図1の構成に似たユーティリティグリッド1500が、DR通信ネットワークおよび計器通信ネットワークなどの分散型通信ネットワークの代わりに、単一の通信ネットワークバス1502を用いて構成されるとよい。図15では、コマンドフィルタモジュール1300は、通信ネットワークバス1502上で動作するよう実行されるとよい。図15の構成は、初期のコマンドが、コマンドフィルタモジュール1300への到達前は同様に処理されてよいという点で、図13に類似している。しかし、コマンドモジュール1300は、許可判断を提供すると、許可された計器コマンド1407を直接特定のスマート計器163へ、許可されたDRコマンド1417を需要家構内179のデバイスへ、許可されたスイッチングコマンド1430をスイッチングデバイス1436へ、さらに許可された補償器コマンド1432を補償器デバイス1438へ伝送するとよい。通信ネットワークバス1502は、コマンドフィルタモジュール1300を実行するためのみではなく、許可されたコマンドを実行されるよう個々のデバイスに向けて送るために、コマンドフィルタモジュール1300と対話するよう構成されているとよい。図16は、ユーティリティグリッド1600の略図である。ユーティリティグリッド1600内に、単一の通信ネットワークバス1602が実装されるとよい。通信ネットワークバス1602は、サードパーティプロバイダによって実装されても、ユーティリティグリッド1600に含まれてもよい。イベントバス147は、通信ネットワークバス1602と通信するとよい。イベントバス147は、コマンドフィルタモジュール1300を実行して、コマンド1404、1412、1424および1427を受信するとよい。許可されたコマンド1407、1417、1430および1432が、通信ネットワークバス1602によって、様々なデバイスコマンドを受信するよう意図された様々なデバイスに分配されるとよい。通信ネットワークバス1602は、許可されたコマンドの意図される受信先を認識し、それに応じて、許可されたコマンドを伝送するとよい。図17は、ユーティリティグリッド1700の略図である。ユーティリティグリッド1700では、分散型イベントバスが使用される。分散型イベントバスは、イベントバス1702、1704および1706を含むとよく、これらはそれぞれ、イベントバス147に関して記載したのと類似した形で機能するとよい。1つの違いは、分散型イベントバス1702、1704および1706は、互いに通信していないということである。図17では、イベントバス1702は、計器コマンド1404およびDRコマンド1412に対してコマンドフィルタモジュール1300を実行するよう構成されている。計器コマンド1404は、図13に関して記載されたような形で、コマンドフィルタモジュール1300によって処理されるとよい。許可された計器コマンド1407は、計器データ収集エンジン1406へ伝送されるとよく、計器データ収集エンジン1406は、コマンドを計器通信ネットワーク1410へ伝送するとよい。許可された計器コマンド1407は、計器通信ネットワーク1410によって、意図されたスマート計器163へ伝送されるとよい。同様に、イベントバス1704も、GUI1411から計器コマンド1404を受信するとよい。イベントバス1704のコマンドフィルタモジュール1300は、計器コマンド1404を許可して、許可された計器コマンド1407を、計器データ収集エンジン1406へ伝送するとよい。許可されたDRコマンド1417は、DR信号分配DR応答DCE1418へ伝送されるとよい。DR信号分配DR応答DCE1418は、許可されたDRコマンド1417を、結果としてホームDRゲートウェイ1421を介し関連した需要家構内デバイスへ伝送されるよう、DR通信ネットワーク1422へ伝送するとよい。スイッチングコマンド1424および補償器コマンド1427は、イベントバス1706によって受信されコマンドフィルタモジュール1300によってフィルタリングされるとよい。許可されたスイッチングコマンド1430および許可された補償器コマンド1432は、制御コマンドプロセッサ1427へ伝送され、続いて、関連したデバイスへルーティングされるとよい。図18は、コマンドフィルタモジュール1300の動作フローの例である。コマンドフィルタモジュール1300は、コマンド1306などのデバイスコマンドを受信するとよいブロック1800。コマンドフィルタモジュール1300は、受信されたコマンドが無効かどうかを判断するとよいブロック1802。コマンド1306のうちの1つ以上が無効であれば、コマンドフィルタモジュール1300は、後のデバイスコマンドの受信のために監視を行うとよい。別の例では、コマンドフィルタモジュール1300は、無効と見なされたコマンド1306の各コマンドに関して、無効メッセージを生成するとよい。無効メッセージは、コマンドを入力するために使用されたGUIなど、コマンドのソースへ、コマンドフィルタモジュール1300によって伝送されるとよい。コマンド受信モジュール1308など、コマンドフィルタモジュール1300のサブモジュールが、無効メッセージを生成するとよい。コマンドフィルタモジュール1300は、有効コマンド1306それぞれの内容を判断するとよいブロック1804。判断は、コマンド受信モジュール1308によって実行されてもよい。有効コマンド1306の内容が判断されると、コマンドフィルタモジュール1300は、関連した過去データを、過去データ136から読み出すとよいブロック1806。コマンドフィルタモジュール1300はさらに、関連した接続性データ1313を、接続性データデータマート131から読み出すとよいブロック1808。接続性データ1313を受信すると、ルール適用モジュール1312は、コマンド1306の実行による起こり得る影響を判断するために、予測モジュール1322を実行するとよいブロック1810。ルール適用モジュール1312は、予測された結果がルールのいずれかに違反するかどうかを判断するために、ルールデータセット1314からの関連したルールを適用するとよいブロック1812。すべてのコマンド1306を許可する決定ブロック1814が、ルール適用モジュール1312によって実行されてもよい。すべてのコマンド1306が許可されれば、コマンド1306は、個々のデバイスによって受信されるようコマンド伝送モジュール1318によって伝送されるとよいブロック1816。すべてのコマンド1306が許可されなければ、コマンドの一部が許可されるかどうかを判断するために、決定が下されるとよいブロック1818。コマンド1306がいずれも許可されなければ、拒否メッセージ1321が、コマンド伝送モジュール1320によって生成されブロック1820、個々のコマンド1306の発信ソースへ伝送されるとよい。コマンド1306の一部が許可される場合、許可されないコマンド1306に関して拒否メッセージ1321がコマンド伝送モジュール1318によって伝送されるとよくブロック1822、許可されたコマンドが、個々のデバイスによって受信されるよう伝送されるとよい。本発明は、好適な実施形態に関連して示され記載されてきたが、上記のものに加えて、本発明の基本的特徴から、特定の変更および改変が行われてよいということは明らかである。さらに、本発明の実践に利用され得る異なるタイプのコンピュータソフトウェアおよびハードウェアは多数あり、本発明は上述の例に制限されない。本発明は、1つ以上の電子デバイスにより実行される機能、および動作の記号表現を参照して記載された。よって、当然のことながら、そのような機能および動作は、構造化形式でデータを表現する電気信号の、電子デバイスの処理ユニットによる操作を含む。この操作は、データを変換するか、または電子デバイスのメモリシステムの各位置にデータを保持し、これが、当業者には十分理解される形で電子デバイスの動作を再構成、または他の形で変更する。データが保持されるデータ構造は、データのフォーマットにより定義される特定の特性を有するメモリの物理的位置である。本発明は前述の文脈において記載されているが、当業者には当然のことながら、記載された機能および動作はハードウェアに実装されることも可能であるため、制限的なものとして意図されてはいない。したがって、本発明の有効な範囲内の変形および変更すべてを保護することが出願人の意図である。本発明は、以下の特許請求の範囲によって定義され、すべての等価物を含むものとする。