JP2011523545A - 電力グリッドを管理する方法およびシステム - Google Patents

Abstract

電力系統の管理を改善するスマートグリッドが提供される。本開示のスマートグリッドは、電力系統の様々な部分においてセンサーを使用すること、ならびに追加のバス構造などの通信およびコンピューティング技術を使用して電気電力グリッドを改良し、電気電力グリッドがより効率的かつ確実に動作し、消費者へのさらなるサービスをサポートできるようにすることを含む。スマートグリッドは、グリッドの種々のセクションにおいてデータを生成し、生成されたデータを分析し、電力グリッドの或るセクションの動作に自動的に変更を加えるデバイスを含む分散インテリジェンス（制御センターインテリジェンスとは別）を電力系統内に含むとよい。
【選択図】図１Ａ

Description

関連出願の参照
本願は、２００８年５月９日に提出された米国特許仮出願第６１／１２７２９４号の利益を主張し、さらに２００８年１２月１５日に提出された米国特許仮出願第６１／２０１８５６号の利益を主張するものであり、両出願の内容全体を参照によって本願明細書に引用したものとする。

１．発明の分野
本発明は、全般的に、電力グリッドを管理するシステムおよび方法に関し、特に、電力グリッドを管理するために、電力グリッドの種々のセクションにおいてデータを収集し、収集されたデータを分析するシステムおよび方法に関する。

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

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

電力会社は、「スマートグリッド」と呼ばれることもあるデジタル技術を使用して、電力グリッドの改良を試みてきた。例えば、よりインテリジェントな計器（「スマート計器」と呼ばれることもある）は、従来の計器よりも詳しく消費を特定する高度な計器の一種である。その結果スマート計器は、監視および請求のために、当該情報を何らかのネットワークを介して地域の電気会社（ｕｔｉｌｉｔｙ）に伝達することができる（遠隔測定）。このような、電力グリッドの改良における最近の進歩は有益であるが、さらなる進歩が必要である。米国だけで、発電容量の半分が未使用であり、長距離送電網容量の半分が未使用であり、さらにその地方の配電の３分の２が未使用であると報告されている。したがって、電力グリッドの管理を改善する必要があることは明らかである。

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

以下に開示されるスマートグリッドを管理することができる管理システムの一例は、インテリジェントネットワークデータエンタープライズ（以下、ＩＮＤＥ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｎｅｔｗｏｒｋ Ｄａｔａ Ｅｎｔｅｒｐｒｉｓｅ）と呼ぶ）参照アーキテクチャである。ＩＮＤＥ参照アーキテクチャは、インテリジェントまたはスマートグリッドを電気産業（またはその他のタイプの産業）に統合することを可能にする。さらに、電力グリッドの管理が、インテリジェントネットワークデータサービス（以下ＩＮＤＳ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｎｅｔｗｏｒｋ Ｄａｔａ Ｓｅｒｖｉｃｅｓ）と呼ぶ）を使用して改善され得る。下記の事項は、電気会社がスマートグリッドを開発するのを支援する一連のプロセスおよびアセットを開示する。この一連のアセットおよび方法は、ＩＮＤＥソリューションセットを含む。ＩＮＤＥは、エンタープライズ規模のスマートグリッドデータ、および解析管理、および統合の枠組を含むことができるＩＮＤＥ参照アーキテクチャと、高速スマートグリッド解析のための分散アーキテクチャおよび解析実装を含むことができるデータ取得・リアルタイム解析と、オープンスタンダードに基づくデータ管理ソリューション構成要素を含むことができるデータ搬送・記憶アーキテクチャアセットと、システムパフォーマンス、電力品質（ｐｏｗｅｒ ｑｕａｌｉｔｙ）、グリッドアセット利用およびグリッドアセット管理を含む広範な解析の実装を含むことができるエンドユーザトランザクション解析アプリケーションと、特定の電気会社の現在のグリッドを分析して、その特定の電気会社の現在のグリッドをスマートグリッドの１つ以上の側面を用いて改善するための提案を決定するための手順を含むことができるスマートグリッド開発プロセスとを含む。

ＩＮＤＥ参照アーキテクチャの様々な側面が、電力グリッドの構造および管理を改善し得る。例えば、ＩＮＤＥ参照アーキテクチャは、種々のタイプのデータを運ぶ複数のネットワークバスを含むとよく、これには、（ｉ）複数のバスが、運用／非運用データ、イベント処理データ、グリッド接続性データ、およびネットワーク位置データなど、別々のタイプのデータ専用とすることもできること、ならびに（ｉｉ）複数バス構造を使用して、データの複数宛先への配送を可能にすることが含まれる。複数バスは、単一バス内の種々のセグメントを含んでも、別々のバスを含んでもよい。複数バスは、様々なタイプのデータを、他のスマートグリッドプロセス（中央に位置するコントローラなどにある）に搬送するために使用されるとよい。あるいは、１つ以上のタイプのデータが、他のタイプのデータと同じバスを使用して送られてもよい（イベント処理データが運用／非運用データと同じバス上で送られるなど）。この場合、イベントデータは、イベント処理データ用の特定プロトコルを使用して送られるとよい。

別の例として、ＩＮＤＥ参照アーキテクチャは、（ｉ）グリッドの種々のセクションにおいてデータを生成するデバイス（変電所にある感知デバイス、顧客構内にある計器、ラインセンサーなど）、（ｉｉ）電力グリッドの種々のポイント、および／または制御センターにて分析を行えるよう、生成されたデータを分析するデバイス（変電所、送電線上などでのイベント処理、および制御センターでデータを分析して特定のイベントが発生したかどうかを決定することなど）、ならびに（ｉｉｉ）電力グリッドの或るセクションの動作を自動的に変更するデバイス（決定されたイベントに基づき変電所における動作を変更するなど）を含む、分散インテリジェンスを電力グリッド内に含むとよい。

例えば、電力グリッドの中央局（ｃｅｎｔｒａｌ ａｕｔｈｏｒｉｔｙ）から離れた電力グリッド内の個々のコンポーネントは、電力グリッドの状態分析（障害の分析など）および／または障害の自動修正を行うためにインテリジェンス（処理および記憶能力など）を含むとよい。そのような個々のコンポーネントの１つに、電力グリッド内の変電所が含まれるとよく、変電所は、センサー、少なくとも１つのプロセッサ、および少なくとも１つの記憶デバイスを含むとよい。変電所は、電力グリッドの或るセクションに関するデータを感知するセンサーを使用し、電力グリッドのそのセクションの状態を決定するために（電力グリッドのそのセクションにおいて障害があるかどうかを決定するなど）、感知されたデータを分析するプロセッサおよび記憶デバイスを使用するとよく、さらに／または決定された障害を自動的に修正してもよい。このように、変電所は、電力グリッドの中央局が、感知データを受け取ることを要求する前、および／または中央局が感知データを分析することを要求する前に、電力グリッドのセクションの少なくとも１つの制御面を自動的に変更することができる。

別の例として、電力グリッド内の個々のコンポーネント自体がインテリジェントであり、協働して電力グリッドの状態を分析および／または制御してもよい。複数バスを用いる追加の通信能力を使用して、電力グリッドの現場にあるコンポーネントが、電力グリッドから感知されたデータおよび／または分析により決定された障害（単数または複数）などの情報を交換するとよい。このようにして、電力グリッドの状態を決定するため、および電力グリッドの障害を修正するために、中央局を用いても用いなくても、現場のコンポーネントが連携するとよい。

分散インテリジェンスはさらに、分散記憶装置を含むとよい。例えば、電力グリッド内のデバイス（変電所など）が、それに関連したデータ記憶装置を有するとよい。データ記憶装置は、変電所に近接しているとよい（変電所内のプロセッサに関連しているなど）。電力グリッド内のデバイスは、データ（センサーデータ、分析データなどを含む）をデータ記憶装置に記憶するとよい。電力グリッド内のデバイスは次に、データの記憶場所へのリンク（例えば、データ記憶装置内でデータを収容しているアドレスへのポインタ）を制御センターに送信するとよい。制御センターは、リンクを中央データ記憶装置（データベースなど）内に記憶するとよい。したがって、制御センターがデータを取得しようとするとき、中央制御は、中央データ記憶装置内のリンクにアクセスし、グリッドデバイス（変電所など）にリクエストを送信してリンクに関連するデータをリクエストし、リンクに関連するデータを含む応答をグリッドデバイスから受信するとよい。

さらに別の例として、ＩＮＤＳは、グリッド状態測定、非運用収集および記憶、イベント管理、需要減少シグナリング、供給停止インテリジェンス、障害インテリジェンス、リモートアセット監視（電力グリッド内の１つ以上のアセットの監視を含む）、電力品質監視（電流／電圧波形の純度など）、システムパフォーマンス測定（電力がオンかまたはオフかについての信頼性など）、作業命令開始、メタデータ管理、通知エージェント、計器データ収集、トランザクション解析、グリッド制御プロセス、およびリアルタイム解析を含むいくつかの側面で電力グリッドの管理を改善するとよい。

さらに別の例では、ＩＮＤＳは、ＩＮＤＥ参照アーキテクチャのモジュール式設計を活用することで、電力グリッドの管理を改善してもよい。これによって、現在使用されているのとは異なるビジネスモデルが可能になり（１つ以上の機能を外部委託することなどによる）、複数の電力グリッドの効率的な管理が可能になるとよい。さらに別の例では、特定の電力グリッドの動作を改良するためにＩＮＤＥ参照アーキテクチャまたはＩＮＤＳのどの側面を適用するかを決定するために、特定の電力グリッドが分析されるとよい。

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

電力グリッドの全体的なアーキテクチャの一例のブロック図である。 電力グリッドの全体的なアーキテクチャの一例のブロック図である。 電力グリッドの全体的なアーキテクチャの一例のブロック図である。 図１に示されたＩＮＤＥ ＣＯＲＥのブロック図である。 電力グリッドの全体的なアーキテクチャの別の例のブロック図である。 電力グリッドの全体的なアーキテクチャの別の例のブロック図である。 電力グリッドの全体的なアーキテクチャの別の例のブロック図である。 図１および図３に示されたＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮのブロック図である。 図１Ａ〜Ｃおよび図３Ａ〜Ｃに示されたＩＮＤＥ ＤＥＶＩＣＥのブロック図である。 図１Ａ〜Ｃおよび図３Ａ〜Ｃに示されたＩＮＤＥ ＤＥＶＩＣＥのブロック図である。 電力グリッドの全体的なアーキテクチャのさらに別の例のブロック図である。 電力グリッドの全体的なアーキテクチャのさらに別の例のブロック図である。 可観測性（ｏｂｓｅｒｖａｂｉｌｉｔｙ）プロセスのいくつかの例の列挙を含むブロック図である。 グリッド状態測定＆動作プロセスのフロー図を示す。 グリッド状態測定＆動作プロセスのフロー図を示す。 非運用データプロセスのフロー図を示す。 イベント管理プロセスのフロー図を示す。 需要応答（ＤＲ：Ｄｅｍａｎｄ Ｒｅｓｐｏｎｓｅ）シグナリングプロセスのフロー図を示す。 需要応答（ＤＲ）シグナリングプロセスのフロー図を示す。 需要応答（ＤＲ）シグナリングプロセスのフロー図を示す。 供給停止インテリジェンスプロセスのフロー図を示す。 供給停止インテリジェンスプロセスのフロー図を示す。 障害インテリジェンスプロセスのフロー図を示す。 障害インテリジェンスプロセスのフロー図を示す。 障害インテリジェンスプロセスのフロー図を示す。 メタデータ管理プロセスのフロー図を示す。 メタデータ管理プロセスのフロー図を示す。 通知エージェントプロセスのフロー図を示す。 計器データ収集（ｃｏｌｌｅｃｔｉｎｇ ｍｅｔｅｒ ｄａｔａ）（ＡＭＩ）プロセスのフロー図を示す。 ベースライン接続性データベースを表すために使用され得るエンティティ関係図の例である。 ベースライン接続性データベースを表すために使用され得るエンティティ関係図の例である。 ベースライン接続性データベースを表すために使用され得るエンティティ関係図の例である。 ベースライン接続性データベースを表すために使用され得るエンティティ関係図の例である。 詳細計画の進展フロー図の例を示す。 詳細計画の進展フロー図の例を示す。

概要として、以下に記載される好適な実施形態は、電力グリッドを管理する方法およびシステムに関する。以下でより詳しく説明するように、特定の側面は電力グリッド自体に関する（送電および／または配電におけるハードウェアおよびソフトウェアを含む）。さらに、特定の側面は電力グリッドの中央管理の機能に関する。こうした機能は、動作およびアプリケーションの２つのカテゴリにグループ化され得る。動作サービスは、電気会社が、スマートグリッドインフラストラクチャ（例えばアプリケーション、ネットワーク、サーバ、センサーなど）を監視および管理できるようにする。

以下でより詳しく説明するように、アプリケーション機能は、グリッド自体の測定および制御に関するとよい。特に、アプリケーションサービスは、スマートグリッドにとって重要と考えられる機能性を可能にするものであり、（１）データ収集プロセス、（２）データカテゴリ化および維持プロセス、および（３）可観測性プロセスが含まれ得る。以下でより詳しく説明するように、こうしたプロセスを使用することで、グリッドを「観測」し、データを分析してグリッドについての情報を抽出することができるようになる。

ＩＮＤＥハイレベルアーキテクチャの説明

全体的アーキテクチャ

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

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

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

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

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

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

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

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

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

ＩＮＤＥコンポーネントグループ

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

ＩＮＤＥ ＣＯＲＥ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ

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

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

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

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

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

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

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

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

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

ＩＮＤＥ ＤＥＶＩＣＥ

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

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

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

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

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

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

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

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

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

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

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

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

ＩＮＤＳの概念およびアーキテクチャ

アウトソースされるスマートグリッドデータ／解析サービスモデル

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

スマートグリッドサービスのＩＮＤＳアーキテクチャ

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

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

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

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

ＩＮＤＥ ＣＯＲＥにおける機能性の具体的な例

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

可観測性プロセス

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

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

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

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

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

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

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

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

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

接続性データベースの構造１８００の一例は、図１８Ａ〜Ｄに示されている階層モデルから得られると考えられる。構造１８００は、４つのセクションに分割されており、図１８Ａは左上のセクション、図１８Ｂは右上のセクション、図１８Ｃは左下のセクション、さらに図１８Ｄは右下のセクションである。具体的には、図１８Ａ〜Ｄはエンティティ関係図の例であり、これはベースライン接続性データベースを表す抽象法である。図１８Ａ〜Ｄの階層モデルは、電力グリッドを表すメタデータを保持するとよく、グリッドの様々なコンポーネントおよびコンポーネント間の関係を表すとよい。

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

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

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

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

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

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

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

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

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

図１３Ａ〜Ｂは、供給停止インテリジェンスプロセスのフロー図１３００を示す。様々なデバイスおよびアプリケーションが、ブロック１３０２、１３０６、１３１０、１３１４、１３１８にて示されているように、電力供給停止通知を送信するとよい。ブロック１３２４にて示されているように、供給停止イベントはイベントバスにより収集され、ブロック１３２６にて示されているように、イベントバスは、複合イベント処理（ＣＥＰ）へ供給停止イベントを送信するとよい。さらに、様々なデバイスおよびアプリケーションが、ブロック１３０４、１３０８、１３１２、１３１６、１３２０にて示されているように、電力復旧ステータスを送信するとよい。ＣＥＰは、供給停止および復旧ステータスメッセージを受信し（ブロック１３３０）、イベントを処理し（ブロック１３３２）、イベントデータを送信するとよい（ブロック１３３４）。供給停止インテリジェンスアプリケーションは、イベントデータを受信して（ブロック１３３５）、グリッド状態および接続性データをリクエストするとよい（ブロック１３３８）。運用データバスは、グリッド状態および接続性データのリクエストを受信して（ブロック１３４４）、それを運用データストアおよびヒストリアンのうちの一方または両方へ転送するとよい。それに応答して、運用データストアおよびヒストリアンは、グリッド状態および接続性データを（ブロック１３５２、１３５４）、運用データバスを介して（ブロック１３４６）、供給停止インテリジェンスアプリケーションへ送信するとよい（ブロック１３４０）。ブロック１３４２にて示されているように、グリッド状態および接続性データが、これがモメンタリーであったかどうかを示すかどうかが決定される。そうであれば、そのモメンタリーが、運用データバスを介して（ブロック１３４８）、記憶用にモメンタリーデータベースへ送信される（ブロック１３５０）。そうでなければ、供給停止ケースが作成され（ブロック１３２８）、供給停止ケースデータが、供給停止管理システムにより記憶および処理される（ブロック１３２２）。

供給停止インテリジェンスプロセスは、供給停止を検出し、モメンタリーを分類してログをとり、供給停止の範囲を決定し、供給停止の主要因（単数または複数）を決定し、供給停止復旧を追跡し、供給停止イベントを発生させ、システムパフォーマンス指数を更新するとよい。

図１４Ａ〜Ｃは、障害インテリジェンスプロセスのフロー図１４００を示す。ブロック１４１６にて示されているように、複合イベント処理は、１つ以上のデバイスからのデータをリクエストするとよい。例えば、ブロック１４０４にて示されているように、グリッド状態および接続性は、リクエストに応答して、グリッド状態および接続性データを複合イベント処理へ送信するとよい。同様に、ブロック１４１０にて示されているように、ヒストリアンは、リクエストに応答してリアルタイムスイッチ状態を複合イベント処理へ送信するとよい。さらに、ブロック１４１８にて示されているように、複合イベント処理は、グリッド状態、接続性データ、およびスイッチ状態を受信するとよい。ブロック１４２８にて示されているように、変電所解析は障害データをリクエストするとよい。ブロック１４２２、１４２４にて示されているように、障害データは、ラインセンサーＲＴＵ、および変電所コンピュータなど、様々なデバイスにより送信されるとよい。様々な障害データ、グリッド状態、接続性データ、およびスイッチ状態が、ブロック１４３０にて示されているように、イベント検出および特徴付けのために変電所解析へ送信されるとよい。イベントバスはさらに、イベントメッセージを受信して（ブロック１４３４）、イベントメッセージを変電所解析へ送信するとよい（ブロック１４３６）。ブロック１４３２にて示されているように、変電所解析はイベントのタイプを決定するとよい。ブロック１４２６にて示されているように、保護および制御変更イベントに関しては、変電所コンピュータが障害イベントメッセージを受信するとよい。その他すべてのタイプのイベントに関しては、イベントがイベントバスにより受信され（ブロック１４３８）、複合イベント処理へ送信されるとよい（ブロック１４４０）。複合イベント処理は、さらなる処理用のイベントデータを受信するとよい（ブロック１４２０）。同じように、グリッド状態および接続性は、ブロック１４０６にて示されているように、グリッド状態データを複合イベント処理へ送信するとよい。さらに、ブロック１４１４にて示されているように、共通情報モデル（ＣＩＭ）ウェアハウスがメタデータを複合イベント処理へ送信するとよい。

複合イベント処理は、ブロック１４２０にて示されているように障害イベントメッセージを送信するとよい。イベントバスは、メッセージを受信して（ブロック１４４２）、イベントメッセージを障害インテリジェンスアプリケーションへ送信するとよい（ブロック１４４４）。障害インテリジェンスアプリケーションは、イベントデータを受信して（ブロック１４３２）、グリッド状態、接続性データ、およびスイッチ状態を、ブロック１４５６にてリクエストするとよい。リクエストに応答して、グリッド状態および接続性はグリッド状態および接続性データを送信し（ブロック１４０８）、ヒストリアンはスイッチ状態データを送信する（ブロック１４１２）。障害インテリジェンスは、データを受信して（ブロック１４５８）、データを分析し、イベントデータを送信する（ブロック１４６０）。イベントデータは、イベントバスにより受信され（ブロック１４４６）、障害ログファイルへ送信される（ブロック１４４８）。障害ログファイルは、イベントデータのログをとるとよい（ブロック１４０２）。イベントデータはさらに、運用データバスにより受信されるとよく（ブロック１４６２）、１つ以上のアプリケーションへ送信する（ブロック１４６４）。例えば、図１３Ａ〜Ｂに関して上記で説明した供給停止インテリジェンスアプリケーションが、イベントデータを受信するとよい（ブロック１４６６）。作業管理システムはさらに、ブロック１４６８にて示されているように、作業命令という形でイベントデータを受信するとよい。さらに、ブロック１４７０にて示されているように、他のリクエストしているアプリケーションが、イベントデータを受信するとよい。

障害インテリジェントプロセスは、グリッドデータを解釈して、グリッド内での現在の、および潜在的な障害についての情報を抽出することを担当するとよい。具体的には、障害は、障害インテリジェントプロセスを使用して検出されるとよい。障害は、典型的には、電気会社の機器が障害を起こしたとき、または例えば垂れ下がった電線など、電流フローの代替パスがつくられたときにもたらされる短絡である。このプロセスは、典型的な障害（典型的に従来の障害検出および保護機器であるリレー、ヒューズなどによって対処される）、ならびに障害電流を使用して容易に検出可能ではないグリッド内の高インピーダンス障害を検出するために使用されるとよい。

障害インテリジェンスプロセスはさらに、障害を分類およびカテゴリ化するとよい。これにより、障害が分類およびカテゴリ化されることが可能になる。現在、障害の体系的な編成および分類のための標準は存在しない。これに関して事実上の標準が確立され、実装されるとよい。障害インテリジェンスプロセスは障害をさらに特徴付けるとよい。

障害インテリジェンスはさらに、障害の位置を決定するとよい。不平衡負荷、３相、２相、および単相ラテラル、センサー／測定の欠如、種々のタイプの障害、短絡の種々の原因、変化する負荷条件、複数のラテラルを備えた長いフィーダ、文書化されていないネットワーク構成など、配電システムの固有の特徴によりもたらされるその高い複雑性および困難が原因で、配電システムにおける障害の位置特定は難しいタスクであることもある。このプロセスは、技術が可能にする限りの正確さで障害の位置を隔離するためのいくつかの技法の使用を可能にする。

障害インテリジェンスはさらに、障害イベントを発生させるとよい。具体的には、このプロセスは、障害が検出、分類、カテゴリ化、特徴付け、および隔離されると、障害イベントを作成してイベントバスへ発行するとよい。このプロセスはさらに、障害中に典型的な生イベントに基づく大量発生ではなく個々の障害イベントが発生するよう、障害の収集、フィルタリング、照合、重複除去を担当するとよい。最終的に、障害インテリジェンスは、イベントログデータベースに障害イベントのログをとるとよい。

図１５Ａ〜Ｂは、メタデータ管理プロセスのフロー図１５００を示す。メタデータ管理プロセスは、ポイントリスト管理、通信接続性＆プロトコル管理、および構成要素命名＆翻訳、センサー較正係数管理、およびリアルタイムグリッドトポロジデータ管理を含むとよい。ブロック１５０２にて示されているように、ベース接続性抽出アプリケーションは、ベース接続性データをリクエストするとよい。地理情報システム（ＧＩＳ）は、リクエストを受信して（ブロック１５１０）、データをベース接続性抽出アプリケーションへ送信するとよい（ブロック１５１２）。ベース接続性抽出アプリケーションは、データを受信して（ブロック１５０４）、データを抽出、変換およびロードし（ブロック１５０６）、ベース接続性データを接続性データマートへ送信するとよい（ブロック１５０８）。接続性データマートは、その後、ブロック１５１４にて示されているようにデータを受信するとよい。

接続性データマートは、グリッドのコンポーネントの電気的接続性情報を含むカスタムデータストアを含むとよい。図１５Ａ〜Ｂに示されているように、この情報は典型的には、グリッドを構成するコンポーネントの施工完了時の地理的位置を保持する、電気会社の地理情報システム（ＧＩＳ）から抽出されるとよい。このデータストア内のデータは、グリッドのすべてのコンポーネント（変電所、フィーダ、セクション、セグメント、ブランチ、ｔセクション、回路遮断器、リクローザー、スイッチなど、基本的にすべてのアセット）についての階層情報を記述する。このデータストアは、施工完了時のアセットおよび接続性情報を有するとよい。

メタデータ抽出アプリケーションは、ブロック１５１６にて示されているように、グリッドアセットに関するメタデータをリクエストするとよい。メタデータデータベースは、リクエストを受信して（ブロック１５２４）、メタデータを送信するとよい（ブロック１５２６）。メタデータ抽出アプリケーションは、メタデータを受信して（ブロック１５１８）、メタデータを抽出、変換およびロードし（ブロック１５２０）、メタデータをＣＩＭデータウェアハウスへ送信するとよい（ブロック１５２２）。

次にＣＩＭ（共通情報モデル）データウェアハウスは、ブロック１５２８にて示されているようにデータを記憶するとよい。ＣＩＭは、電気会社データを表すための電気会社標準フォーマットを規定するとよい。ＩＮＤＥスマートグリッドは、電気会社標準フォーマットで、スマートグリッドからの情報の利用可能性を促進するとよい。さらに、ＣＩＭデータウェアハウスは、ＩＮＤＥ特有のデータの、規定の電気会社標準フォーマットなど１つ以上のフォーマットへの変換を促進するとよい。

ブロック１５３０にて示されているように、アセット抽出アプリケーションは、新たなアセットに関する情報をリクエストするとよい。アセットレジストリは、リクエストを受信して（ブロック１５３８）、新たなアセットに関する情報を送信するとよい（ブロック１５４０）。アセット抽出アプリケーションは、新たなアセットに関する情報を受信して（ブロック１５３２）、データを抽出、変換およびロードし（ブロック１５３４）、新たなアセットに関する情報をＣＩＭデータウェアハウスへ送信するとよい（ブロック１５３６）。

ブロック１５４２にて示されているように、ＤＲ接続性抽出アプリケーションは、ＤＲ接続性データをリクエストするとよい。ブロック１５４８にて示されているように、運用データバスは、ＤＲ接続性データリクエストをマーケティングデータベースへ送信するとよい。マーケティングデータベースはリクエストを受信して（ブロック１５５４）、ＤＲ接続性データを抽出、変換、ロードし（ブロック１５５６）、ＤＲ接続性データを送信するとよい（ブロック１５５８）。運用データバスは、ＤＲ接続性データをＤＲ接続性抽出アプリケーションへ送信するとよい（ブロック１５５０）。ＤＲ接続性抽出アプリケーションは、ＤＲ接続性データを受信して（ブロック１５４４）、ＤＲ接続性データを、運用データバスを介して（ブロック１５５２）グリッド状態および接続性ＤＭへ送信する（ブロック１５４６）とよく、グリッド状態および接続性ＤＭがＤＲ接続性データを記憶する（ブロック１５６０）。

図１６は、通知エージェントプロセスのフロー図１６００を示す。ブロック１６０２にて示されているように、通知契約者はウェブページにログインするとよい。通知契約者は、ブロック１６０４にて示されているように、シナリオ監視リストパラメータを作成／変更／削除するとよい。ブロック１６０８にて示されているように、ウェブページは作成／変更／削除されたシナリオ監視リストを記憶して、ブロック１６１２にて示されているように、ＣＩＭデータウェアハウスがデータタグのリストを作成するとよい。名称翻訳サービスが、ヒストリアンのデータタグを翻訳して（ブロック１６１４）、データタグを送信するとよい（ブロック１６１６）。ウェブページは、運用データバスを介してデータタグリストを送信するとよく（ブロック１６１０）、運用データバスがデータタグリストを受信して（ブロック１６２２）、それを通知エージェントへ送信する（ブロック１６２４）。通知エージェントは、リストを読み出して（ブロック１６２６）、リストを検証および結合し（ブロック１６２８）、通知シナリオに関してヒストリアンをチェックする（ブロック１６３０）。シナリオにマッチする例外が発見されると（ブロック１６３２）、通知が送信される（ブロック１６３４）。イベントバスは通知を受信し（ブロック１６１８）、それを通知契約者へ送信する（ブロック１６２０）。ブロック１６０６にて示されているように、通知契約者は、テキスト、電子メール、電話など、好適な媒体を介して通知を受信するとよい。

図１７は、計器データ収集（ＡＭＩ）プロセスのフロー図１７００を示す。電流コレクタは、ブロック１７０６にて示されているように、住居計器データをリクエストするとよい。１つ以上の住居計器が、リクエストに応答して住居計器データを収集し（ブロック１７０２）、住居計器データを送信するとよい（ブロック１７０４）。電流コレクタは、住居計器データを受信し（ブロック１７０８）、それを運用データバスへ送信するとよい（ブロック１７１０）。計器データ収集エンジンは、ブロック１７２２に示されているように、商業および工業用計器データをリクエストするとよい。１つ以上の商業および工業用計器が、リクエストに応答して商業および工業用計器データを収集し（ブロック１７２８）、商業および工業用計器データを送信するとよい（ブロック１７３０）。計器データ収集エンジンは、商業および工業用計器データを受信して（ブロック１７２４）、それを運用データバスへ送信するとよい（ブロック１７２６）。

運用データバスは、住居、商業、および工業用計器データを受信して（ブロック１７１２）、データを送信するとよい（ブロック１７１４）。データは、計器データリポジトリデータベースにより受信されても（ブロック１７１６）、または請求プロセッサにより受信されてもよく（ブロック１７１８）、これが次に、ＣＲＭ（ｃｕｓｔｏｍｅｒ ｒｅｌａｔｉｏｎｓｈｉｐ ｍａｎａｇｅｍｅｎｔ：顧客関係管理）システムなどの１つ以上のシステムへ送信される（ブロック１７２０）。

可観測性プロセスはさらに、リモートアセット監視プロセスを含むとよい。電力グリッド内のアセットの監視は、困難なものとなるかもしれない。電力グリッドには種々の部分があると考えられ、その一部は非常に高価である。例えば、変電所は電力変圧器（１００万ドル以上かかる）、および回路遮断器を含むと考えられる。電力会社は、アセットの分析およびアセット使用の最大化の点では、ほとんど何もしないことが多い。代わりに、電気会社の焦点は典型的には、消費者への電力が確実に保持されるようにすることであった。具体的には、電気会社の焦点は、定期点検（典型的には所定の間隔で生じると考えられる）または「イベント駆動型の」保全（障害がグリッドの或る部分で生じた場合に発生すると考えられる）に合わせられていた。

典型的な定期点検または「イベント駆動型の」保全の代わりに、リモートアセット監視プロセスは、状態基準保全に焦点を合わせるとよい。具体的には、電力グリッドの一部（または全部）が評価できれば（定期的または継続的になど）、電力グリッドの正常性が改善され得る。

上記のように、電力グリッドの様々な部分でデータが生成されて、中央局に送られる（またはそれによるアクセスが可能である）とよい。次にデータは、グリッドの正常性を決定するために、中央局によって使用されるとよい。グリッドの正常性の分析とは別に、中央局は利用監視を実行するとよい。典型的には、電力グリッド内の機器は、かなりの安全マージンを用いて動作させられている。この理由の１つは、電気会社はもともと保守的であり、エラーのマージンを大きくしてその中で消費者に対し電力を保持しようとするということである。このもう１つの理由は、グリッドを監視する電気会社が、電力グリッド内の一機器が利用されている程度を認識していないこともあるということである。例えば、電力会社が特定のフィーダ回路を介して送電している場合、電力会社は、送られた電力がフィーダ回路の限界に近いかどうか（例えば、フィーダ回路が過熱するかもしれない）を知る手段は有しないと考えられる。これが理由で、電気会社は、電力グリッドの１つ以上の部分を十分に活用していない可能性がある。

電力グリッドに対する負荷が増大してきているため（すなわち消費電力量が増えてきている）、電気会社はさらに、典型的にはかなりの金額を費やして電力グリッドに容量を追加する。電気会社の無知が原因で、電気会社は不必要に電力グリッドを改良することになる。例えば、フィーダ回路は、最大容量近くで動作していなくても、それにもかかわらず導体を取り替えること（すなわちフィーダ回路により大きなワイヤが取り付けられる）によって改良されることもあり、または追加のフィーダ回路が取り付けられることもある。この費用だけでも相当なものである。

リモートアセット監視プロセスは、（１）グリッドの１つ以上の部分の現在のアセット正常性を分析すること、（２）グリッドの１つ以上の部分の将来のアセット正常性を分析すること、および（３）グリッドの１つ以上の部分の利用を分析することなど、電力グリッドの様々な側面を監視するとよい。第１に、１つ以上のセンサーが、グリッドの特定部分の現在の正常性を決定するために、測定を行ってリモートアセット監視プロセスへ送るとよい。例えば、電力変換に関するセンサーは、変圧器上の溶解ガスを測定することによってその正常性のインジケータを提供するとよい。リモートアセット監視プロセスは次に、分析ツールを使用して、グリッドの特定部分が（電力変換が正常か正常でないかなど）を決定するとよい。グリッドの特定部分が正常でなければ、そのグリッドの特定部分が修理されるとよい。

さらに、リモートアセット監視プロセスは、グリッドの各部分の将来のアセット正常性を予測するために、グリッドの各部分から生成されたデータを分析するとよい。電気コンポーネントに対する圧迫をもたらすものが複数ある。圧迫要因は、必ずしも一定ではなく、断続的であることもある。センサーは、電力グリッドの特定部分に対する圧迫のインジケータを提供するとよい。リモートアセット監視プロセスは、センサーデータにより示される圧迫測定値のログをとるとよく、電力グリッドのその部分の将来の正常性を予測するために、圧迫測定値を分析するとよい。例えば、リモートアセット監視プロセスは、グリッドの特定部分がいつ障害を起こす可能性があるかを予測するために傾向分析を使用するとよく、グリッドの特定部分が障害を起こす可能性がある時点より前（またはそれと同時）に、保全をスケジュールするとよい。このように、リモートアセット監視プロセスは、グリッドの特定部分の寿命を予測し、したがって、グリッドの当該部分の寿命が短すぎるかどうか（すなわち、グリッドの当該部分の消耗が速すぎるか）を決定するとよい。

さらに、リモートアセット監視プロセスは、電力グリッドをよりよく管理するために、電力グリッドの或る部分の利用を分析するとよい。例えば、リモートアセット監視プロセスは、フィーダ回路の稼働容量を決定するためにフィーダ回路を分析するとよい。このフィーダ回路の例では、リモートアセット監視プロセスが、フィーダ回路が現在７０％で動作していると決定してもよい。リモートアセット監視プロセスはさらに、許容範囲の安全マージンをなお保持しながら、特定のフィーダ回路がより高い割合（９０％など）で動作できると勧めてもよい。したがって、リモートアセット監視プロセスは、単に利用を分析することによって、容量の効果的な増加を可能にするとよい。

特定の技術アーキテクチャを決定する手順

ＩＮＤＥ参照アーキテクチャの構成要素のうちの１つ、一部、または全部を使用するとよい特定の技術アーキテクチャを決定するには、様々な手順がある。手順は、複数のステップを含むとよい。第１に、電気会社の現状のドキュメントを生成し、およびスマートグリッドに移行するための準備評価を行う中で、ベースラインステップが実行されるとよい。第２に、将来の状態、およびこの状態に達するための詳しい要件の定義を生成する中で、要件定義ステップが実行されるとよい。

第３に、測定、監視および制御を含むスマートグリッドを可能にするソリューションアーキテクチャコンポーネントの定義を生成する中で、ソリューション開発ステップが実行されるとよい。ＩＮＤＥアーキテクチャの場合、これには、測定デバイス、データをデバイスからＩＮＤＥ ＣＯＲＥ１２０アプリケーションへ渡す通信ネットワーク、データを維持しそれに反応するＩＮＤＥ ＣＯＲＥ１２０アプリケーション、データを解釈する分析アプリケーション、測定および解釈されたデータをモデル化するデータアーキテクチャ、データおよび情報をＩＮＤＥおよび電気会社システムの間で交換するための統合アーキテクチャ、様々なアプリケーションおよびデータベースを実行する技術インフラストラクチャ、ならびに業界標準の移植可能かつ効率的なソリューションを可能にするために従うとよい標準が含まれ得る。

第４に、スマートグリッドの主要パフォーマンスインジケータおよび成功要因の定義を生成し、所望のパフォーマンス係数に照らしてシステムパフォーマンスを測定して評価する能力を実装する中で、バリューモデリングが実行さるとよい。上記の開示は、ステップ３のアーキテクチャ開発の側面に関係する。

図１９Ａ〜Ｂは、詳細計画の進展フロー図の例を示す。具体的には、図１９Ａ〜Ｂは、スマートグリッドの要件およびスマートグリッドの実装のために実行されるとよいステップを定義するために、取り組まれるとよいステップのプロセスフローを示す。スマートグリッド開発プロセスは、スマートグリッド構想開発から始まるとよく、これが、プロジェクトの全体的な目的の概要を明らかにし、スマートグリッドロードマッププロセスにつながるとよい。ロードマッププロセスは、詳細計画およびバリューモデリングにつながるとよい。

詳細計画は、電気会社の事業全体を背景として、スマートグリッドの定義に対し系統的手法を提供するとよい。詳細計画は、全体的なロードマップを含むとよく、これがベースラインおよびシステム評価（ＢＡＳＥ：ｂａｓｅｌｉｎｅ ａｎｄ ｓｙｓｔｅｍｓ ｅｖａｌｕａｔｉｏｎ）、ならびに要件定義および解析選択（ＲＤＡＳ：ｒｅｑｕｉｒｅｍｅｎｔｓ ｄｅｆｉｎｉｔｉｏｎ ａｎｄ ａｎａｌｙｔｉｃｓ ｓｅｌｅｃｔｉｏｎ）につながるとよい。ＲＤＡＳプロセスは、電気会社の特定のスマートグリッドの詳細な定義を作成するとよい。

ＢＡＳＥプロセスは、スマートグリッド機能をサポートするシステム、ネットワーク、デバイスおよびアプリケーションの観点から電気会社の出発点を確立するとよい。プロセスの第１部分は、グリッドのシステムインベントリを開発することであり、これは、グリッド構造（発電、送電線、送電変電所、副送電線、配電変電所、配電フィーダ、電圧階級など）、グリッドデバイス（スイッチ、リクローザー、蓄電器、調整器、電圧降下補償器、フィーダインタータイなど）、変電所オートメーション（ＩＥＤ、変電所ＬＡＮ、計測手段、ステーションＲＴＵ／コンピュータなど）、配電オートメーション（蓄電器およびスイッチの制御、障害隔離および負荷ロールオーバー制御（ｌｏａｄ ｒｏｌｌｏｖｅｒ ｃｏｎｔｒｏｌｓ）、ＬＴＣ調整システム、ＤＭＳ、需要応答管理システムなど）、ならびにグリッドセンサー（センサータイプ、量、用途、ならびにグリッド上、送電線上、変電所内の総数など）などを含むとよい。インベントリが完成すると、ハイレベルスマートグリッド準備モデルに照らして電力会社の評価が作成されるとよい。現状のデータフローモデルおよびシステム図も作成されるとよい。アーキテクチャ構成（ＡＲＣ：ａｒｃｈｉｔｅｃｔｕｒｅ ｃｏｎｆｉｇｕｒａｔｉｏｎ）プロセスは、ＢＡＳＥプロセスからの情報と、ＲＤＡＳプロセスおよびＩＮＤＥ参照アーキテクチャからの要件および制約とを組み合わせて、電力会社の特定のニーズに合い、適切なレガシーシステムを活用し、電力会社に存在する制約に従う技術アーキテクチャを生み出すことによって、電気会社の初期スマートグリッド技術アーキテクチャを開発するとよい。ＩＮＤＥ参照アーキテクチャの使用は、カスタムアーキテクチャを考案する必要を回避するとよく、蓄積された経験およびベストプラクティスが、確実にソリューションの開発に応用されるようにする。さらに、再利用可能なスマートグリッドアセットをソリューションが確実に最大限使用できるようにするとよい。

センサーネットワークアーキテクチャ構成（ＳＮＡＲＣ：ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ ａｒｃｈｉｔｅｃｔｕｒｅ ｃｏｎｆｉｇｕｒａｔｉｏｎ）プロセスは、スマートグリッドサポートのための分散センサーネットワークのアーキテクチャを定義する一連の決定を行うためのフレームワークを提供するとよい。フレームワークは、センサーネットワークアーキテクチャの特定の側面にそれぞれが向かう、一連の決定木として構築されるとよい。決定が下されると、センサーネットワークアーキテクチャ図が作成されるとよい。

Ｔセクション再帰によるセンサー配置（ＳＡＴＳＥＣＴＲ：ｓｅｎｓｏｒ ａｌｌｏｃａｔｉｏｎ ｖｉａ Ｔ−ｓｅｃｔｉｏｎ ｒｅｃｕｒｓｉｏｎ）プロセスは、費用制約条件に従って所定レベルの可観測性を得るために、配電グリッド上にいくつのセンサーが配置されるべきかを決定するためのフレームワークを提供するとよい。このプロセスはさらに、センサーのタイプおよび位置を決定するとよい。

ソリューション構成要素評価およびコンポーネントテンプレート（ＳＥＬＥＣＴ：ｓｏｌｕｔｉｏｎ ｅｌｅｍｅｎｔ ｅｖａｌｕａｔｉｏｎ ａｎｄ ｃｏｍｐｏｎｅｎｔｓ ｔｅｍｐｌａｔｅ）プロセスは、ソリューションコンポーネントタイプの評価のためのフレームワークを提供するとよく、各コンポーネントクラスの設計テンプレートを提供する。テンプレートは、ソリューション構成要素それぞれに関する仕様の参照モデルを含むとよい。こうしたテンプレートは、次に、ベンダーの見積もりをリクエストしてベンダー／製品評価をサポートするために使用されるとよい。

アプリケーションおよびネットワークの改良計画（ＵＰＬＡＮ：ｕｐｇｒａｄｅ ｐｌａｎｎｉｎｇ ｆｏｒ ａｐｐｌｉｃａｔｉｏｎｓ ａｎｄ ｎｅｔｗｏｒｋｓ）プロセスは、既存の電気会社システム、アプリケーション、およびネットワークをスマートグリッドソリューションに統合する準備を整えるための改良計画の開発を提供するとよい。リスク評価および管理計画（ＲＡＭＰ：ｒｉｓｋ ａｓｓｅｓｓｍｅｎｔ ａｎｄ ｍａｎａｇｅｍｅｎｔ ｐｌａｎｎｉｎｇ）プロセスは、ＡＲＣプロセスにおいて作成されたスマートグリッドソリューションの特定の構成要素に関連するリスクの評価を提供するとよい。ＵＰＬＡＮプロセスは、特定されたリスク要素のレベルまたはリスクを評価するとよく、電気会社が増築に尽力する前にリスクを軽減するための行動計画を提供する。変化分析および管理計画（ＣＨＡＭＰ：ｃｈａｎｇｅ ａｎａｌｙｓｉｓ ａｎｄ ｍａｎａｇｅｍｅｎｔ ｐｌａｎｎｉｎｇ）プロセスは、スマートグリッド投資の価値を実現するために電気会社に必要と考えられるプロセスおよび組織変化を分析して、こうした変更をスマートグリッドの展開と同期した形で実行するためのハイレベル管理計画を提供するとよい。ＣＨＡＭＰプロセスは、詳細計画の生成をもたらすとよい。

バリューモデリングプロセスにおけるロードマップは、バリューメトリクスを特定することにつながるとよく、これが費用および利益の推定につながるとよい。推定は、レートケースおよびビジネスケースなど１つ以上のケースの構築につながるとよく、これが次にケースクローズにつながるとよい。詳細計画およびバリューモデリングの出力は、承認を受けるために電気会社へ送信されるとよく、これが、電気会社システムの改良およびスマートグリッドの展開およびリスク削減アクティビティにつながるとよい。この後、グリッドが設計、構築およびテストされ、続いて動作させられるとよい。

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

Claims (39)

1. 電力グリッドを管理する中央電力グリッドとの通信を促進する統合フレームワークであって、
   前記中央電力グリッド局へ運用データを伝達する、バスの第１部分であって、前記運用データは、前記電力グリッドの少なくとも一部の電圧、電流、有効電力、または無効電力の少なくとも１つのリアルタイム測定値を含む、前記第１部分と、
   前記中央電力グリッド局へイベントデータを伝達する、バスの第２部分であって、前記第２部分は、前記第１部分とは別であり、前記イベントデータは、前記リアルタイム測定値とは異なるものであり、前記リアルタイム測定値から抽出され、前記少なくとも１つのリアルタイム測定値に基づき前記電力グリッドの動作に関する少なくとも１つの分析決定を含む、前記第２部分と、
   を含む、前記統合フレームワークであって、
   前記運用データは、前記第１部分を介して伝達され、前記第２部分を介しては伝達されず、
   前記イベントデータは、前記第２部分を介して伝達され、前記第１部分を介しては伝達されない、統合フレームワーク。
2. 前記バスの前記第１部分は、第１セグメントを含み、前記バスの前記第２部分は、第２セグメントを含み、前記第１および第２セグメントは、同一バス上の別々のセグメントである、請求項１に記載の統合フレームワーク。
3. 受信されたデータの少なくとも一部を分析し、前記データを前記第１セグメントおよび前記第２セグメントのうちの１つへルーティングする少なくとも１つのスイッチをさらに含む、請求項２に記載の統合フレームワーク。
4. 前記バスの前記第１部分は、前記運用データの伝達のみ専用の第１専用セグメントを含み、
   前記バスの前記第２部分は、前記イベントデータの伝達のみ専用の第２専用セグメントを含む、
   請求項２に記載の統合フレームワーク。
5. 前記バスの前記第１部分は、第１バスを含み、前記バスの前記第２部分は、第２バスを含み、
   前記第１バスは、前記第２バスとは物理的に別である、請求項１に記載の統合フレームワーク。
6. 受信されたデータの少なくとも一部を分析し、前記第１バスおよび前記第２バスのうちの１つへ前記データをルーティングするルータをさらに含む、請求項５に記載の統合フレームワーク。
7. 前記ルータは、前記データを前記第１バスへルーティングするか、または前記第２バスへルーティングするかを決定するために、前記データ内の少なくとも１つのヘッダを分析する、請求項６に記載の統合フレームワーク。
8. 前記ルータは、前記中央電力グリッド局にある、請求項６に記載の統合フレームワーク。
9. 前記バスの前記第１部分は、非運用データをさらに伝達し、前記非運用データは、電力品質、電力信頼性、アセット正常性、および圧迫データのうちの少なくとも１つを含む、請求項１に記載の統合フレームワーク。
10. 前記統合フレームワークは、前記中央電力グリッド局と、請求システムとの間の伝達用の第３バスをさらに含み、前記第３バスは、前記バスの前記第１部分および前記バスの前記第２部分とは別である、請求項９に記載の統合フレームワーク。
11. 前記バスの前記第１部分は、運用データ記憶データベースと、供給停止管理システム、エネルギー管理システム、および配電管理システムのうちの少なくとも１つとに、動作可能なように接続されている、請求項１に記載の統合フレームワーク。
12. 前記バスの前記第１部分は、前記運用データ記憶データベースと、前記供給停止管理システム、前記エネルギー管理システムと、前記配電管理システムとに、動作可能なように接続されている、請求項１１に記載の統合フレームワーク。
13. 前記バスの前記第２部分は、イベントログ記憶データベースと、供給停止管理システム、エネルギー管理システムのうちの少なくとも１つと、配電管理システムとに、動作可能なように接続されている、請求項１に記載の統合フレームワーク。
14. 前記第２バスは、前記イベントログ記憶データベースと、前記供給停止管理システム、前記エネルギー管理システムと、前記配電管理システムとに、動作可能なように接続されている、請求項１０に記載の統合フレームワーク。
15. 電力グリッドを管理する中央電力グリッドへデータを伝達する方法であって、
    バスの第１部分で前記中央電力グリッド局へ運用データを伝達するステップであって、前記運用データは、前記電力グリッドの少なくとも一部の電圧、電流、有効電力、または無効電力の少なくとも１つのリアルタイム測定値を含む、前記ステップと、
    バスの第２部分で前記中央電力グリッド局へイベントデータを伝達するステップであって、前記第２部分は、前記第１部分とは別であり、前記イベントデータは、前記リアルタイム測定値とは異なるものであり、前記リアルタイム測定値から抽出され、前記少なくとも１つのリアルタイム測定値に基づき前記電力グリッドの動作に関する少なくとも１つの分析決定を含む、前記ステップと、
    を含む、前記方法であって、
    前記運用データは、前記第１部分を介して伝達され、前記第２部分を介しては伝達されず、
    前記イベントデータは、前記第２部分を介して伝達され、前記第１部分を介しては伝達されない、方法。
16. 前記バスの前記第１部分は、第１セグメントを含み、前記バスの前記第２部分は、第２セグメントを含み、前記第１および第２セグメントは、同一バス上の別々のセグメントである、請求項１５に記載の方法。
17. 前記バスの前記第１部分は、前記運用データの伝達のみ専用の第１専用セグメントを含み、
    前記バスの前記第２部分は、前記イベントデータの伝達のみ専用の第２専用セグメントを含む、
    請求項１６に記載の方法。
18. 前記バスの前記第１部分は、第１バスを含み、前記バスの前記第２部分は、第２バスを含み、
    前記第１バスは、前記第２バスとは物理的に別である、請求項１５に記載の方法。
19. 受信されたデータの少なくとも一部を分析するステップと、
    前記第１バスおよび前記第２バスのうちの１つへ前記データをルーティングするステップと、
    をさらに含む、請求項１８に記載の方法。
20. 前記バスの前記第１部分は、非運用データをさらに伝達し、前記非運用データは、電力品質、電力信頼性、アセット正常性、および圧迫データのうちの少なくとも１つを含む、請求項１５に記載の方法。
21. 電力グリッドのデータ管理システムであって、前記電力グリッドは、前記電力グリッドを管理する中央電力グリッド局と、前記電力グリッド内の複数のデバイスとを含み、前記データ管理システムは、
    前記グリッドのセクションに配置されたデバイスに関連するデータ記憶装置であって、前記データ記憶装置は、前記デバイスに近接しており、前記デバイスは、前記グリッドの前記セクションにおいて電気パラメータを感知し、前記データ記憶装置は、前記感知された電気パラメータを記憶する複数のメモリ位置を含む、前記データ記憶装置と、
    前記中央電力グリッド局に関連する中央データ記憶装置であって、前記データ記憶装置内の前記メモリ位置へのリンクを含む、前記中央データ記憶装置と、
    を含む、データ管理システム。
22. 前記電力グリッド内の前記デバイスは、変電所を含む、請求項２１に記載のデータ管理システム。
23. 前記変電所に関連する前記データ記憶装置は、前記変電所内または前記変電所上にあるメモリを含む、請求項２２に記載のデータ管理システム。
24. 前記変電所は、前記リンクを前記中央電力グリッド局へ送信し、
    前記中央電力グリッド局は、前記リンクを前記中央データ記憶装置に記憶する、請求項２２に記載のデータ管理システム。
25. 前記中央電力グリッド局は、前記中央データ記憶装置内の前記リンクにアクセスし、
    前記中央電力グリッド局は、前記変電所へリクエストを送信して、前記リンクに関連するデータをリクエストし、
    前記中央電力グリッド局は、前記リンクに関連する前記データを含むレスポンスを前記変電所から受信する、請求項２４に記載のデータ管理システム。
26. 前記変電所は、前記リンクに関連する少なくとも１つのヘッダをさらに送信し、
    前記中央電力グリッド局は、
    前記中央電力グリッド局へ運用データを伝達する、バスの第１部分であって、前記運用データは、前記電力グリッドの少なくとも一部の電圧、電流、有効電力、または無効電力の少なくとも１つのリアルタイム測定値を含む、前記第１部分と、
    前記中央電力グリッド局へイベントデータを伝達する、バスの第２部分であって、前記第２部分は、前記第１部分とは別であり、前記イベントデータは、前記リアルタイム測定値とは異なるものであり、前記リアルタイム測定値から抽出され、前記少なくとも１つのリアルタイム測定値に基づき前記電力グリッドの動作に関する少なくとも１つの分析決定を含む、前記第２部分と、
    を含み、
    前記運用データは、前記第１部分を介して伝達され、前記第２部分を介しては伝達されず、
    前記イベントデータは、前記第２部分を介して伝達され、前記第１部分を介しては伝達されない、請求項２４に記載のデータ管理システム。
27. データが前記データ記憶装置内の前記メモリ位置に記憶され、
    前記中央データ記憶装置は、前記データ記憶装置内の前記メモリ位置への前記リンクを記憶し、前記メモリ位置に記憶されている前記データは記憶しない、請求項２１に記載のデータ管理システム。
28. 前記電力グリッド内の前記複数のデバイスのうちの前記少なくとも１つは、顧客構内にある計器を含む、請求項２１に記載のデータ管理システム。
29. 電力グリッドを管理する電力グリッド管理システムであって、前記電力グリッドは、複数のグリッドデバイスを含み、前記電力グリッド管理システムは、
    前記電力グリッドを管理する中央電力グリッド局と、
    前記グリッドの第１セクションに配置された第１グリッドデバイスであって、
    前記グリッドの前記第１セクションにおいて電気パラメータを感知する第１センサー、および
    前記グリッドの前記第１セクションにおいて前記感知された電気パラメータを分析して、前記感知された電気パラメータに基づきイベントを決定する第１プロセッサ
    を含む、前記第１グリッドデバイスと、
    前記グリッドの第２セクションに配置された第２グリッドデバイスであって、
    前記第１グリッドデバイスにより決定された前記イベントを受信し、前記第２セクションを含む前記グリッドの少なくとも或るセクションに、前記イベントに基づき変更を加え、前記グリッドの前記少なくとも或るセクションの前記変更を示す情報を、前記中央電力グリッド局へ送る、第２プロセッサ
    を含む、前記第２グリッドデバイスと、
    を含む、電力グリッド管理システム。
30. 前記第２グリッドデバイスは、前記中央電力グリッド局の介入なしに、前記電力グリッドの前記セクションに変更を加える、請求項２９に記載の電力グリッド管理システム。
31. 前記第２グリッドデバイスは、変電所を含む、請求項２９に記載の電力グリッド管理システム。
32. 少なくとも１つのフィーダ回路が前記変電所から出ており、
    前記第１グリッドデバイスの前記第１センサーは、前記フィーダ回路の少なくとも一部の前記電気パラメータを感知する、請求項３１に記載の電力グリッド管理システム。
33. 前記第２グリッドデバイスは、前記グリッドの前記第２セクションにおいて電気パラメータを感知する第２センサーをさらに含み、
    前記第２プロセッサは、前記グリッドの前記少なくとも或るセクションに変更を加えるために、前記第１グリッドデバイスにより決定された前記イベントと、前記グリッドの前記第２セクションにおいて前記感知された電気パラメータとを分析する、請求項３２に記載の電力グリッド管理システム。
34. 前記変電所は、前記変電所に関連し近接しているデータ記憶装置をさらに含み、前記データ記憶装置は、前記グリッドの前記第２セクションおいて前記感知された電気パラメータを記憶する複数のメモリ位置を含む、請求項３３に記載の電力グリッド管理システム。
35. 電力グリッドのデータ管理システムのための方法であって、前記電力グリッドは、前記電力グリッドを管理する中央電力グリッド局と、前記電力グリッド内の複数のデバイスとを含み、前記方法は、
    前記グリッドのセクションに配置された電気デバイスを使用して、前記グリッドの前記セクションにおいて電気パラメータを感知するステップと、
    前記感知された電気パラメータを、データ記憶デバイスのメモリ位置に記憶するステップであって、前記データ記憶デバイスは、前記電気デバイスに関連し前記デバイスに近接している、前記ステップと、
    前記データ記憶デバイスの前記メモリ位置を、前記中央電力グリッド局に関連する中央データ記憶装置へ送信するステップと、
    を含む方法。
36. 前記電力グリッド内の前記デバイスは、変電所を含む、請求項３５に記載の方法。
37. 前記変電所に関連する前記データ記憶装置は、前記変電所内または前記変電所上にあるメモリを含む、請求項３６に記載の方法。
38. 前記変電所は、前記リンクを前記中央電力グリッド局へ送信し、
    前記中央電力グリッド局は、前記リンクを前記中央データ記憶装置に記憶する、請求項３６に記載の方法。
39. 前記中央電力グリッド局は、前記中央データ記憶装置内の前記リンクにアクセスし、
    前記中央電力グリッド局は、前記変電所へリクエストを送信して、前記リンクに関連するデータをリクエストし、
    前記中央電力グリッド局は、前記リンクに関連する前記データを含むレスポンスを前記変電所から受信する、請求項３８に記載の方法。

Images