JP5452613B2 - 電力グリッドの供給停止および故障状況の管理 - Google Patents

Description

１．発明の分野
本発明は、全般的に、電力グリッドを管理するシステムおよび方法に関し、特に、電力グリッドにおいて供給停止および故障状況を管理するシステムおよび方法に関する。

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

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

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

本開示の一側面によれば、電力グリッドの供給停止管理システムが開示される。この供給停止管理システムは、電力グリッドの様々なデバイスおよび部分からイベントメッセージを受信するよう構成され１つ以上のプロセッサ上で実行可能な供給停止インテリジェンスアプリケーションを含むとよい。イベントメッセージは、電力グリッドの特定のデバイスまたは部分に関して供給停止状況が存在すると考えられる場合に、供給停止インテリジェンスアプリケーションが判断できるようにするとよい。供給停止インテリジェンスアプリケーションは、イベントメッセージを送る電力グリッドのデバイスおよび部分の１つ、いくつか、またはすべてに関して、動作状態を判断するとよい。供給停止インテリジェンスアプリケーションは、電力グリッドに関連する供給停止が存在することを示すイベントメッセージを受信すると、その確認を行うために、電力グリッドの現在の需要状況、および電力グリッドの物理的構成に関係するデータを受信するとよい。供給停止インテリジェンスアプリケーションは、供給停止の発生について、中央電力局（ｃｅｎｔｒａｌ ｐｏｗｅｒ ａｕｔｈｏｒｉｔｙ）に通知し、供給停止の位置特定および修正を可能にするとよい。供給停止インテリジェンスアプリケーションは、イベントメッセージの受信に基づき、電力グリッドのうち、供給停止状況が生じている部分から受信されたメッセージの処理を一時停止するとよく、当該の処理を、供給停止状況が存在しなくなったときに再開するとよい。

本開示の別の側面によれば、少なくとも１つのプロセッサ上で実行可能な故障インテリジェンスアプリケーションは、フェーザデータ（大きさおよび位相角）を受信して、電力グリッドにおける故障の故障状況の検出に基づいて故障タイプを特定するよう構成されているとよい。故障インテリジェンスアプリケーションは、一連の所定の基準をフェーザデータに適用するとよい。故障インテリジェンスアプリケーションは、様々なカテゴリの基準をフェーザデータに適用して、基準の適用に基づき、任意の故障タイプを規則的に考慮から除外するとよい。各カテゴリの基準が適用されるとき、基準に合致しない故障タイプは、故障タイプとしての考慮から除外されるとよい。各カテゴリの適用は、故障タイプの候補を減らすことにつながるとよく、最終的に、故障タイプとして特定される単一の故障タイプをもたらすとよい。故障インテリジェンスアプリケーションは、故障が、性質上単なる一時的なものではないと判断するための、連続読み取り（ｃｏｎｓｅｃｕｔｉｖｅ ｒｅａｄｉｎｇ）制約を実装するとよい。中央局（ｃｅｎｔｒａｌ ａｕｔｈｏｒｉｔｙ）に、後からの分析および修正のために故障の識別情報が提供されてもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＢＡＳＥプロセスは、スマートグリッド機能をサポートするシステム、ネットワーク、デバイスおよびアプリケーションの観点から電気会社の出発点を確立するとよい。プロセスの第１部分は、グリッドのシステムインベントリを開発することであり、これは、グリッド構造（発電、送電線、送電変電所、副送電線、配電変電所、配電フィーダ、電圧階級など）、グリッドデバイス（スイッチ、リクローザー、コンデンサー、調整器、電圧降下補償器、フィーダインタータイなど）、変電所オートメーション（ＩＥＤ、変電所ＬＡＮ、計測手段、ステーションＲＴＵ／コンピュータなど）、配電オートメーション（コンデンサーおよびスイッチの制御、故障隔離および負荷ロールオーバー制御（ｌｏａｄ ｒｏｌｌｏｖｅｒ ｃｏｎｔｒｏｌｓ）、ＬＴＣ調整システム、ＤＭＳ、需要応答管理システムなど）、ならびにグリッドセンサー（センサータイプ、量、用途、ならびに配電グリッド上、送電線上、変電所内の総数など）などを含むとよい。インベントリが完成すると、上位スマートグリッド準備モデルに照らして電力会社の評価が作成されるとよい。現状のデータフローモデルおよびシステム図も作成されるとよい。

アーキテクチャ構成（ＡＲＣ：ａｒｃｈｉｔｅｃｔｕｒｅ ｃｏｎｆｉｇｕｒａｔｉｏｎ）プロセスは、ＢＡＳＥプロセスからの情報、ＲＤＡＳプロセスおよびＩＮＤＥ参照アーキテクチャからの要件および制約を組み合わせて、電力会社の特定のニーズに合致し、適切なレガシーシステムを活用し、電気会社に存在する制約に従う技術アーキテクチャを生み出すことによって、電気会社の初期スマートグリッド技術アーキテクチャを開発するとよい。ＩＮＤＥ参照アーキテクチャの使用は、カスタムアーキテクチャを考案する必要を回避するとよく、蓄積された経験およびベストプラクティスが、確実にソリューションの開発に応用されるようにする。さらに、再利用可能なスマートグリッドアセットをソリューションが確実に最大限使用できるようにするとよい。

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

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

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

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

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

図１３に関して説明されたように、ＩＮＤＥ ＣＯＲＥ１２０は、電力グリッドの様々な部分の中での供給停止の発生を判断するよう構成されているとよく、さらに、供給停止の位置を判断するとよい。図２０〜２５は、電力グリッドの様々な部分およびデバイスに関連する供給停止に関する状況を管理および評価するよう構成された、供給停止インテリジェンスアプリケーションの例を提供する。図２０〜２５の例はそれぞれ、単一の供給停止インテリジェンスアプリケーションを使用して互いに相互作用してもよく、または、いくつかの供給停止インテリジェンスアプリケーションの間に分散していてもよい。各供給停止インテリジェンスアプリケーションは、ハードウェアベース、ソフトウェアベース、またはその任意の組み合わせであればよい。一例では、図１３に関して記載された供給停止インテリジェンスアプリケーションは、ＣＥＰサービス１４４をホストしているものなどのＣＥＰエンジン上、および、その他、ＣＥＰサービス１４４を動作させるものを含む任意のサーバ上の両方で実行され得る。さらに、供給停止インテリジェンスアプリケーションは、図２０〜２５に関して記載されるように、電力グリッドの様々な部分の供給停止の評価および管理を実行するときに、図１３に関して記載されたものなどのグリッドおよび接続性データを読み出すとよい。

図２０は、スマート計器１６３などの計器に関連する供給停止およびその他の状況を判断する例示動作フロー図である。一例では、イベント・メッセージは、電力グリッドに接続された各スマート計器１６３によって生成されるとよい。上記の通り、イベントメッセージは、特定のスマート計器１６３に関して生じている現在のイベントを記述するとよい。イベントメッセージは、コレクタ１６４から電気会社通信ネットワーク１６０を介してＩＮＤＥ ＣＯＲＥ１２０にルーティングされるとよい。イベントメッセージは、電気会社通信ネットワーク１６０から、セキュリティフレームワーク１１７およびルーティングデバイス１９０を介して渡されるとよい。ルーティングデバイス１９０は、イベントメッセージをイベント処理バス１４７にルーティングするとよい。イベント処理バス１４７は、供給停止インテリジェンスアプリケーションと通信して、供給停止インテリジェンスアプリケーションが、イベントメッセージを処理して、イベントメッセージに基づきスマート計器１６３の状態を判断できるようにするとよい。

一例では、供給停止インテリジェンスアプリケーションによって受信される各イベントメッセージは、関連するスマート計器１６３が、通常サービスに従って動作していることを示してもよい。ブロック２０００にて、イベントメッセージに基づき、供給停止インテリジェンスアプリケーションは、特定のスマート計器１６３の状態が「通常サービス」のものであると判断するとよい。通常サービスの状態は、特定のスマート計器１６３が無事に動作しており、供給停止も、その他の特異な状況も、特定のスマート計器１６３によって検出されていないことを示すとよい。特定のスマート計器１６３の状態が通常サービスのものであると判断されると、供給停止インテリジェンスアプリケーションは、イベントメッセージを通常通り処理するとよく、これは、供給停止インテリジェンスアプリケーションが、特定のスマート計器１６３に関連するイベントメッセージを、いかなる最近の異常アクティビティを参照することもなく解釈することを指すとよい。特定のスマート計器１６３から「読み取り失敗イベント」状況２００２が発生すると、ブロック２００４にて供給停止インテリジェンスアプリケーションは、特定のスマート計器１６３の状態が「計器障害の疑い」であると判断するとよい。読み取り失敗イベントは、供給停止インテリジェンスアプリケーションが特定のスマート計器１６３からのイベントメッセージをフィルタリングできないようにする、任意の事象であればよい。読み取り失敗イベントは、供給停止インテリジェンスアプリケーションが、特定のスマート計器１６３などのデバイスからイベントメッセージを受信することを予期したが、そのイベントメッセージを受信しないときに発生し得る。読み取り失敗イベント状況２００２は、計器の不具合、供給停止状況、または特定のスマート計器１６３と、供給停止インテリジェンスアプリケーションとの間の通信の喪失が原因で、特定のスマート計器１６３に関して生じ得る。

一例では、計器障害の疑い状態は、特定のスマート計器１６３が障害を起こしたことを、読み取り失敗イベント状況２００２の発生に基づき示すとよい。計器障害の疑い状態では、供給停止インテリジェンスアプリケーションが、特定のスマート計器１６３の、即時の計器リモート電圧チェックのリクエストを出すとよい。計器リモート電圧チェックは、特定のスマート計器１６３から、そのスマート計器１６３の現在の電圧を示すメッセージを受信することのリクエストを送信することを含んでもよい。供給停止インテリジェンスアプリケーションが、特定の計器１６３によって送られ特定の計器１６３が正しく機能していることを示す「電圧チェック’ＯＫ’」メッセージ２００６を受信すると、供給停止インテリジェンスアプリケーションは、ブロック２０００の通常サービス状態に戻るとよい。

供給停止インテリジェンスアプリケーションは、電圧チェックが失敗したと判断することもあり、これは「電圧チェック失敗」状況２００８をもたらす。電圧チェック失敗状況は、特定のスマート計器１６３から電圧チェック「ＯＫ」メッセージ２００６が受信されなかったことに基づき判断されてもよい。供給停止インテリジェンスアプリケーションは、電圧チェック失敗状況２００８に基づき、特定のスマート計器１６３に関連する供給停止が生じたと判断するとよく、ブロック２０１０にて供給停止インテリジェンスアプリケーションは、特定のスマート計器が「供給停止確認済み」状態であると判断してもよい。供給停止確認済み状態は、持続的供給停止が生じたことを示すとよい。ブロック２０１０での供給停止確認済み状態の判断に移行するときに、「持続的供給停止イベント」メッセージ２０１２が、供給停止インテリジェンスアプリケーションによって生成されるとよい。持続的供給停止イベントメッセージ２０１２は、供給停止管理システム１５５に送られるとよく、これによって、持続的供給停止イベントの位置の判断が可能になるとよい。他の例では、持続的供給停止イベントメッセージ２０１２は、故障インテリジェンスアプリケーション（図１４参照）およびログファイルに送られてもよい。別の例では、メッセージ２０１２は、メッセージ２０１２を処理するよう構成された他のシステムおよびプロセスにルーティングされてもよい。

ブロック２０１０にて供給停止確認済み状態を判断する一方で、供給停止インテリジェンスアプリケーションは、特定のスマート計器１６３の電圧チェックの定期的リクエストを出してもよい。供給停止インテリジェンスアプリケーションが、特定のスマート計器１６３から電圧チェックＯＫメッセージ２００６を受信すれば、ブロック２０００にて供給停止インテリジェンスアプリケーションは、通常サービス状態を判断するとよい。

供給停止インテリジェンスアプリケーションが、供給停止確認済み状態の間に、「電力復旧通知（ＰＲＮ：ｐｏｗｅｒ ｒｅｓｔｏｒａｔｉｏｎ ｎｏｔｉｆｉｃａｔｉｏｎ）」メッセージ２０１３を受信すれば、ブロック２０００において供給停止インテリジェンスアプリケーションは、特定のスマート計器１６３が通常サービス状態であると判断するとよい。ＰＲＮメッセージ２０１３は、供給停止はもう存在しないということを示すとよい。ＰＲＮメッセージ２０１１は、特定の計器１６３から生じるとよい。「再開」メッセージ２０１５が、供給停止確認済み状態で生じてもよい。再開メッセージ２０１５は、セクション、フィーダ回路、データ管理システム（ＤＭＳ：ｄａｔａ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍｓ）などの、より上位のエンティティから生じてもよい。

ブロック２０００にて、供給停止インテリジェンスアプリケーションは、読み取り失敗イベントが発生していない特定のスマート計器１６３の電圧チェックをリクエストするとよい。電圧チェックは、定期的に実行されても、または電力グリッド全体の中、もしくは電力グリッドの事前に選択された部分の中での電力需要が特定の閾値未満であるときなど、特定の電力グリッド状況に基づき実行されてもよい。電圧チェック失敗状況２００８が存在すれば、供給停止インテリジェンスアプリケーションは、特定の計器１６３が供給停止確認済み状態２０１０であると判断するとよい。ブロック２０００における通常サービス状態の判断から、ブロック２０１０での供給停止確認済み状態に移行するときに、「持続的供給停止イベント」メッセージ２０１２が生成され、送られるとよい。

供給停止インテリジェンスアプリケーションは、ブロック２０００にて通常サービス状態を判断する一方で、特定のスマート計器１６３に関連する供給停止が生じた可能性があることを示す「電力供給停止通知（ＰＯＮ：ｐｏｗｅｒ ｏｕｔａｇｅ ｎｏｔｉｆｉｃａｔｉｏｎ）」メッセージ２０１４を受信してもよい。メッセージは、特定のスマート計器１６３、またはその他、特定のスマート計器１６３の上流のデバイスから受信されるとよい。ＰＯＮメッセージ２０１４を受信すると、ブロック２０１６にて供給停止インテリジェンスアプリケーションは、特定のスマート計器１６３が「供給停止感知」状態であると判断するとよい。供給停止感知状態では、供給停止インテリジェンスアプリケーションは、さらなるアクションを所定の期間一時停止するとよい。所定の期間が経過すると、「タイムアウト」状況２０１８が生じるとよく、結果として、ブロック２０１０にて供給停止インテリジェンスアプリケーションは、特定の計器が供給停止確認済み状態であると判断する。供給停止確認済み状態に移行する間、供給停止インテリジェンスアプリケーションは、持続的供給停止イベントメッセージ２０１２を生成するとよい。

供給停止インテリジェンスアプリケーションが、計器収集データエンジンから電力復旧通知（ＰＲＮ）メッセージ２０１３を、所定の期間の経過より前に受信すると、供給停止インテリジェンスアプリケーションは、「瞬時供給停止（ｍｏｍｅｎｔａｒｙ ｏｕｔａｇｅ）イベント」メッセージ２０２０を生成するとよく、これは、感知された供給停止は瞬時のものでしかなく、特定のスマート計器１６３は現在正しく機能しており、この特定のスマート計器１６３によって供給停止状態は示されていないということを示す。瞬時供給停止イベントメッセージ２０２０は、後からの分析のためにイベントログファイルに送られるとよい。ブロック２０００にて供給停止インテリジェンスアプリケーションはさらに、特定の計器が通常サービス状態であることを判断するとよい。

供給停止インテリジェンスアプリケーションが、電圧チェック「ＯＫ」メッセージ２００６をタイムアウト状況２０１８より前に受信すると、ブロック２０００にて供給停止インテリジェンスアプリケーションは、スマート計器１６３が通常サービス状態であると判断し、さらに瞬時供給停止イベントメッセージ２０２０を生成するとよい。ブロック２０００、２００４、２０１０および２０１８における状態それぞれにおいて供給停止インテリジェンスアプリケーションは、セクション、フィーダ回路、ＤＭＳなどの、より上位のエンティティから、特定の計器１６３の計器メッセージの処理を一時停止するための一時停止メッセージを受信してもよい。一時停止は、特定のスマート計器１６３に影響を及ぼし得る不正変更、デバイスの不具合、またはその他何らかの好ましくない状況が存在するという認識に基づくとよい。供給停止インテリジェンスアプリケーションがブロック２０００、２００４、２０１０および２０１８の状態のいずれかにある間に一時停止メッセージ２０２２があれば、ブロック２０２４にて供給停止インテリジェンスアプリケーションは即座に、特定のスマート計器１６３がフィルタ一時停止状態であると判断するとよい。フィルタ一時停止状態では、供給停止インテリジェンスアプリケーションは、この特定の計器１６３から生じるメッセージのフィルタリングを一時停止するとよい。供給停止インテリジェンスアプリケーションによって受信される再開メッセージ２０１５は、ブロック２０００にて供給停止インテリジェンスアプリケーションが通常サービス状態に戻ることを許可するとよい。再開メッセージ２０１５は、セクション、フィーダ回路、ＤＭＳなどによって生成されるとよい。図２０は、特定のスマート計器１６３に関して供給停止インテリジェンスアプリケーションを示しているが、供給停止インテリジェンスアプリケーションは、各電力グリッド内の所望の任意数の計器１６３からのイベントメッセージを同じように管理するよう構成されているとよい。

図２１は、電力グリッド内のラインセンサーに関連する供給停止状況を判断するよう構成された供給停止インテリジェンスアプリケーションの動作フロー図である。一例では、ラインセンサーは、さらに、ラインセンサーのアクティビティに関する情報を提供するよう、ラインセンサーに電気的に結合されたフィーダ計器を含むとよい。図２０と似て、供給停止インテリジェンスアプリケーションは、一度、いくつか、またはすべてのラインセンサーに関して様々な状態を判断し、各状態の判断に基づき様々なタスクを実行するとよい。ラインセンサーは、特定のラインセンサーの状態を判断するために供給停止インテリジェンスアプリケーションによって受信されるイベントメッセージを生成するよう構成された、ＲＴＵなどのデバイスを含んでもよい。ブロック２１００にて、供給停止インテリジェンスアプリケーションは、特定のラインセンサーが通常サービス状態であると判断するとよい。ブロック２１００の状態が判断されると、供給停止インテリジェンスアプリケーションは、関連する計器がいつ修理または交換される予定になっているかなどのサービスイベントを渡すとよい。そのような状況は、計器を切り離し、ＰＯＮを生成させると考えられる。しかし、供給停止も、その他の異常な状況も実際は存在しないため、このような場合には、供給停止インテリジェンスアプリケーションはイベントメッセージを渡すとよい。読み取り失敗イベント状況２１０２が生じると、ブロック２１０４にて供給停止インテリジェンスアプリケーションは、特定のラインセンサーのセンサー障害の疑い状態を判断するとよい。一例では、読み取り失敗イベント状況２１０２は、特定のラインセンサーが、予期されるときにイベントメッセージを生成しないことを示すとよい。

ブロック２１０４にて供給停止インテリジェンスアプリケーションが、特定のラインセンサーがセンサー障害状態であると判断する一方で、供給停止インテリジェンスアプリケーションは、センサー正常性チェックを出すとよい。ラインセンサーが障害を起こしていないことを示す「正常性チェック’ＯＫ’」メッセージ２１０６を特定のラインセンサーから受信すると、ブロック２１００にて供給停止インテリジェンスアプリケーションは、ラインセンサーが通常サービス状態であると判断するとよい。正常性チェック「ＯＫ」メッセージが受信されなければ、ブロック２１０４にて供給停止インテリジェンスアプリケーションは、特定のラインセンサーが障害を起こした可能性があるかどうかの判断を継続する。

ブロック２１００にて供給停止インテリジェンスアプリケーションが、特定のラインセンサーが通常サービス状態であるかどうかを判断する一方で、「電圧損失」状況２１０８が生じることもあり、これが原因で、供給停止インテリジェンスアプリケーションは、感知された供給停止に特定のラインセンサーが関与していることを示す供給停止感知状態を判断する。電圧損失状況２１０８は、特定のラインセンサーの電圧が所望のレベルであることを示す、予期されるイベントメッセージを、供給停止インテリジェンスアプリケーションが受信しないときに生じ得る。電圧損失状況２１０８は、特定のラインセンサーが、特定のラインセンサーに供給停止が生じていることを示す供給停止感知状況であると、ブロック２１１０にて供給停止インテリジェンスアプリケーションに判断させる。供給停止インテリジェンスアプリケーションは、特定のラインセンサーが供給停止感知状態であると判断する一方で、電圧障害状況２１０８が、瞬時供給停止を示すか、または持続的供給停止を示すかを判断するとよい。一例では、供給停止インテリジェンスアプリケーションは、所定の期間、さらなるアクションを一時停止するとよい。所定の期間が経過すれば、「タイムアウト」状況２１１２が生じるとよく、結果として、供給停止インテリジェンスアプリケーションは、持続的供給停止状況が起こったと判断し、ブロック２１１４にて供給停止インテリジェンスアプリケーションは、特定のラインセンサーが供給停止確認済み状態であると判断するとよい。供給停止確認済み状態の判断に移行する間、供給停止インテリジェンスアプリケーションは、「持続的供給停止イベント」メッセージ２１１６を生成するとよく、これは、位置および範囲に関して後から供給停止の分析をするために供給停止管理システム１５５に送られるとよい。供給停止インテリジェンスアプリケーションが、特定のラインセンサーが供給停止感知状態であると判断する間、ただし所定の時間の満了より前に、「電圧復旧」メッセージ２１１８を受信すれば、供給停止インテリジェンスアプリケーションは、供給停止が瞬時のものであると判断するとよく、ブロック２１００にて特定のラインセンサーが通常サービス状態であると判断するとよい。ブロック２１００の状態の判断に移行する間に、瞬時供給停止イベントメッセージ２１２０が、供給停止インテリジェンスアプリケーションによって生成され、供給停止管理システム１５５に送られるとよい。供給停止インテリジェンスアプリケーションが、特定のラインセンサーが供給停止確認済み状態であると判断する間に、電圧復旧メッセージ２１１８を受信すれば、ブロック２１００にて供給停止インテリジェンスアプリケーションは、特定のラインセンサーが通常サービス状態であると判断するとよい。

供給停止インテリジェンスアプリケーションが、「故障電流検出」メッセージ２１２２を受信すると、ブロック２１２４にて供給停止インテリジェンスアプリケーションは、特定のラインセンサーが故障感知状態であると判断するとよい。故障電流検出メッセージ２１２２が受信されると、供給停止インテリジェンスアプリケーションは、故障インテリジェンスアプリケーション（図１４参照）などの様々なアプリケーションによって受信される故障メッセージ２１２５を生成するとよい。ブロック２１２４にて、特定のラインセンサーが故障感知状態であると判断する一方で、供給停止インテリジェンスアプリケーションは、その故障が、特定のラインセンサーの位置を過ぎた位置など、特定のラインセンサーとは異なる電力グリッド内の位置で生じたと判断してもよい。供給停止インテリジェンスアプリケーションは、特定のラインセンサーが故障感知状態であるとブロック２１２４にて判断する一方で、特定のラインセンサーからの定期的な電圧チェックをリクエストしてもよい。供給停止インテリジェンスアプリケーションが、電圧復旧メッセージ２１１８を受信すると、ブロック２１００にて供給停止インテリジェンスアプリケーションは、特定のラインセンサーが通常サービス状態であると判断するとよい。図２１は、特定のラインセンサーに関して供給停止インテリジェンスアプリケーションを示しているが、供給停止インテリジェンスアプリケーションは、各電力グリッド内の所望の任意数のラインセンサーからのイベントメッセージを同じように管理するよう構成されているとよい。

図２０に関して記載されたのと同じように、ブロック２１００、２１０６、２１１０、２１１４、および２１２４における状態それぞれにおいて供給停止インテリジェンスアプリケーションは、セクション、フィーダ回路、ＤＭＳなどの、より上位のエンティティから、ラインセンサーの計器メッセージの処理を一時停止するための一時停止メッセージを受信してもよい。一時停止は、特定のラインセンサーに影響を及ぼし得る不正変更、デバイスの不具合、またはその他何らかの好ましくない状況が存在するという認識に基づくとよい。供給停止インテリジェンスアプリケーションがブロック２１００、２１０６、２１１０、２１１４、および２１２４の状態のいずれかにある間に一時停止メッセージ２１２６があれば、ブロック２１２８にて供給停止インテリジェンスアプリケーションは即座に、特定のラインセンサーがフィルタ一時停止状態であると判断するとよい。フィルタ一時停止状態では、供給停止インテリジェンスアプリケーションは、この特定のラインセンサーから生じるメッセージの処理を一時停止するとよい。供給停止インテリジェンスアプリケーションによって受信される再開メッセージ２１３０は、ブロック２１００にて供給停止インテリジェンスアプリケーションが通常サービス状態に戻ることを許可するとよい。再開メッセージ２１３０は、セクション、フィーダ回路、ＤＭＳなどによって生成されるとよい。図２１は、特定のラインセンサーに関して供給停止インテリジェンスアプリケーションを示しているが、供給停止インテリジェンスアプリケーションは、各電力グリッド内の所望の任意数のラインセンサーからのイベントメッセージを同じように管理するよう構成されているとよい。

図２２は、１つ以上の故障回路インジケータ（ＦＣＩ）によって認識された故障を判断するよう構成された供給停止インテリジェンスアプリケーションの動作フロー図である。特定のＦＣＩは、電力グリッド内に位置するとよい。供給停止インテリジェンスアプリケーションは、ＦＣＩに含まれている監視デバイスからイベントメッセージを受信し、ブロック２２００にて、ＦＣＩが通常状態であると判断するとよい。特定のＦＣＩが通常状態であると判断する一方で、供給停止インテリジェンスアプリケーションは、その特定のＦＣＩからのイベントメッセージを処理するとよい。「下流ＦＣＩ故障」メッセージ２２０２を受信すると、ブロック２２０４にて供給停止インテリジェンスアプリケーションは、特定のＦＣＩがＦＣＩ不具合状態であると判断するとよい。ブロック２２０４にて、特定のＦＣＩがＦＣＩ不具合状態であると判断する一方で、供給停止インテリジェンスアプリケーションは、その特定のＦＣＩからのメッセージ処理を一時停止するとよい。供給停止インテリジェンスアプリケーションは、「下流ＦＣＩリセット」メッセージ２２０６が受信されるまで、ＦＣＩメッセージ処理を一時停止し続けるとよい。下流ＦＣＩ故障メッセージ２２０６を受信すると、ブロック２２００にて供給停止インテリジェンスアプリケーションは、そのＦＣＩが通常状態であると判断するとよい。

供給停止インテリジェンスアプリケーションが、「ローカルＦＣＩ故障」メッセージ２２０８を受信すれば、供給停止インテリジェンスアプリケーションは、特定のＦＣＩにて故障が生じたと判断するとよい。特定のＦＣＩ故障メッセージ２２０８を受信すると、ブロック２２１０にて、供給停止インテリジェンスアプリケーションは、特定のＦＣＩが、故障電流検出状態であると判断してもよい。供給停止インテリジェンスアプリケーションは、特定のＦＣＩが故障電流検出状態であるとの判断に移行する間に、故障インテリジェンスアプリケーションおよび上流のＦＣＩなどの様々なアプリケーションに対する故障メッセージ２２１１を生成するとよい。供給停止インテリジェンスアプリケーションは、この特定のＦＣＩからリセットメッセージ２２１２を受信すると、この特定のＦＣＩの上流のＦＣＩに対するリセットメッセージ２２１３を生成するとよく、ブロック２２００にて、特定のＦＣＩが通常状態であると判断するとよい。

供給停止インテリジェンスアプリケーションが、下流のＦＣＩから下流ＦＣＩ故障メッセージ２２１４を受信すれば、供給停止インテリジェンスアプリケーションは、特定のＦＣＩが下流故障状態２２１６であるかどうかを判断するとよい。下流故障があるかどうかを判断する一方で、供給停止インテリジェンスアプリケーションは、その特定のＦＣＩからのメッセージ処理を一時停止するとよい。下流ＦＣＩリセットメッセージ２２１８を下流のＦＣＩから受信すると、ブロック２１００にて供給停止インテリジェンスアプリケーションは、その特定のＦＣＩが通常状態であると判断するとよい。図２２は、特定のＦＣＩに関して供給停止インテリジェンスアプリケーションを示しているが、供給停止インテリジェンスアプリケーションは、各電力グリッド内の所望の任意数のＦＣＩからのイベントメッセージを同じように管理するよう構成されているとよい。

図２３は、相互接続した電力グリッドに関連する供給停止状況の間に、コンデンサーバンクを動作させるよう構成された供給停止インテリジェンスアプリケーションの動作フロー図である。一例では、供給停止インテリジェンスアプリケーションは、特定のコンデンサーバンクに関連する様々な状態を判断し、判断された状態それぞれに関連する特定のアクションを実行するとよい。ブロック２３００にて、供給停止インテリジェンスアプリケーションは、特定のコンデンサーバンクが、電力グリッドから切り離されているなどのオフライン状態であると判断するとよい。特定のコンデンサーバンクのオフ状態は、コンデンサーバンクのアクティビティに関するメッセージを生成するよう構成された１つ以上のデバイスによって送信されるイベントメッセージを介して、供給停止インテリジェンスアプリケーションに示されるとよい。

コンデンサーバンクが、定期保全または運用上の不具合によりサービス停止中であれば、供給停止インテリジェンスアプリケーションは、「サービス停止」メッセージ２３０２を受信するとよい。メッセージ２３０２を受信すると、ブロック２３０４にて供給停止インテリジェンスアプリケーションは、特定のコンデンサーバンクが「サービス停止」状態であると判断するとよい。供給停止インテリジェンスアプリケーションが、特定のコンデンサーバンクがサービス停止中であると判断する一方で、供給停止インテリジェンスアプリケーションは、特定のコンデンサーバンクに関するイベントメッセージの処理を一時停止するとよい。供給停止インテリジェンスアプリケーションは、特定のコンデンサーバンクがサービス提供可能であることを示す「サービス回復」メッセージ２３０６を特定のコンデンサーバンクから受信するとよく、ブロック２３００にて供給停止インテリジェンスアプリケーションは、特定のコンデンサーバンクがオフ状態であると判断できる。

特定のコンデンサーバンクは、「オン」コマンドを、そのコマンドを出す権限を有する電力グリッド内の任意のデバイスから受信することによって、何らかの時点でオンにされるとよい。供給停止インテリジェンスアプリケーションは、特定のコンデンサーバンクがオンにされたことを、「オンコマンド」メッセージ２３０８を介して通知されるとよい。ブロック２３１０にて供給停止インテリジェンスアプリケーションは、メッセージ２３０８に基づき、特定のコンデンサーバンクが「オン待ち」状態であると判断するとよい。オン待ち状態を判断するとき、供給停止インテリジェンスアプリケーションは、コンデンサーバンクがオンにされなかったことを示す運用有効性（ＯＥ：ｏｐｅｒａｔｉｏｎａｌ ｅｆｆｅｃｔｉｖｅｎｅｓｓ）障害メッセージ２３１２を受信してもよく、これは、ブロック２３００にて運用インテリジェンスアプリケーションに、コンデンサーバンクがオフ状態であると判断させる。運用有効性は、コンデンサーバンクなどの特定のデバイスが、「オン」コマンドなどの特定のコマンドを実行することの表れを指してもよい。供給停止インテリジェンスアプリケーションが、’ＯＥオン確認’メッセージ２３１４を受信すれば、供給停止インテリジェンスアプリケーションは、特定のコンデンサーバンクが、特定のコンデンサーバンクが電力グリッド内の特定のフィーダ回路に接続されていることを示す「コンデンサーバンクオン」状態２３１６であると判断するとよい。状態２３１６の判断に移行するときに、供給停止インテリジェンスは、「コンデンサーバンクオン」メッセージ２３１８を生成するとよく、これは、特定のコンデンサーバンクによって生成される電圧を使用する相互接続したフィーダ回路などの様々なデバイスによって受信されるとよい。

供給停止インテリジェンスアプリケーションは、ブロック２３１０にて特定のコンデンサーバンクがオン待ち状態であると判断する一方で、特定のコンデンサーバンクをオフにする権限を与えられた任意のデバイスからオフコマンドメッセージ２３２０を受信してもよく、これは、ブロック２３２２にて供給停止インテリジェンスアプリケーションに、特定のコンデンサーバンクが「オフ待ち」状態であると判断させる。ブロック２３１８にて、特定のコンデンサーバンクがオフ待ち状態であると判断する一方で、供給停止インテリジェンスアプリケーションは、オンコマンドメッセージ２４０８を受信してもよく、これは、ブロック２３１０にて供給停止インテリジェンスアプリケーションに、特定のコンデンサーバンクがオン待ち状態であると判断させる。ブロック２３１６にて供給停止インテリジェンスアプリケーションが、特定のコンデンサーバンクがコンデンサーバンクオン状態であると判断する間に、オフコマンドメッセージ２３２０を受信すれば、ブロック２３２２にて供給停止インテリジェンスは、特定のコンデンサーバンクがオフ待ち状態であると判断するとよい。

供給停止インテリジェンスアプリケーションは、特定のコンデンサーバンクがオフ待ち状態であるとブロック２３１８にて判断する一方で、ＯＥ確認のリクエストを出すとよい。それに応答して、供給停止インテリジェンスアプリケーションが、ＯＥ障害メッセージ２３１２を受信すれば、ブロック２３２２にて供給停止インテリジェンスアプリケーションは、特定のコンデンサーバンクがオフ待ち状態であると判断するとよい。

ブロック２３００にて、特定のバンクがコンデンサーバンクオフ状態であると判断する一方で、供給停止インテリジェンスアプリケーションは、メッセージ２３２４のＯＥ確認を受信してもよく、これは、ブロック２３２２にて供給停止インテリジェンスアプリケーションに、特定のコンデンサーバンクがオフ待ち状態であると判断させる。移行するときに、供給停止インテリジェンスアプリケーションは、特定のコンデンサーバンクに関する情報を求め得る任意のデバイスによって受信されるコンデンサーバンクオフメッセージ２３２６を生成するとよい。図２３は、特定のコンデンサーバンクに関して供給停止インテリジェンスアプリケーションを示しているが、供給停止インテリジェンスアプリケーションは、各電力グリッド内の所望の任意数のコンデンサーバンクからのイベントメッセージを同じように管理するよう構成されているとよい。

図２４は、電力グリッド内のフィーダ回路に関する供給停止状況の存在を判断するよう構成された供給停止インテリジェンスアプリケーションの動作フロー図である。一例では、供給停止インテリジェンスアプリケーションは、フィーダ回路の状況を監視するよう構成されフィーダ回路に含まれているデバイスから受信されるイベントメッセージに基づき、特定のフィーダ回路の現在の状態を判断するよう構成されているとよい。ブロック２４００にて供給停止インテリジェンスアプリケーションは、特定のフィーダ回路が通常状態で動作していると判断するとよく、これは、供給停止状況は存在していないことを示す。供給停止インテリジェンスアプリケーションが、フィーダ回路から「切り替え待ち」メッセージ２４０２を受信すれば、ブロック２４０４にて供給停止インテリジェンスアプリケーションは、フィーダ回路の「切り替え」状態を判断するとよく、これは、特定のフィーダ回路に関連する電流切り替えが実行されていることにより回路に異常な挙動が生じている可能性があることを示す。供給停止インテリジェンスアプリケーションは、特定のフィーダ回路が切り替え状態であると判断する一方で、そのことを示すフィーダ回路または他のデバイスから受信されるセクション供給停止メッセージを無視するとよい。供給停止インテリジェンスアプリケーションは、フィーダ回路が切り替え状態であるとのブロック２４０４での判断に移行する間に、１つ以上の「フィーダメッセージ一時停止」通知２４０８を生成するとよく、これは、従属するセクションおよびスマート計器１６３など、特定のフィーダ回路の切り替えによって影響を受ける様々なデバイスによって受信されるとよい。

供給停止インテリジェンスアプリケーションは、特定のフィーダ回路が切り替え状態であるとブロック２４０６にて判断する間に、「切り替え完了」メッセージ２４１０を特定のフィーダ回路から受信してもよい。切り替え完了メッセージ２４１０の受信は、供給停止インテリジェンスアプリケーションが、特定のフィーダ回路が通常動作状態であるかどうかをブロック２４００で判断することに再び移行することを可能にするとよい。特定のフィーダ回路が切り替え状態であるとの判断に移行する間に、供給停止インテリジェンスアプリケーションは、１つ以上の「フィーダメッセージ再開」通知２４１２を生成するとよく、これは、以前にフィーダメッセージ一時停止通知２４０８を受信していた様々なデバイスに送られるとよい。

供給停止状況が原因で、フィーダ回路が、相互接続した遮断器のトリップに基づいてロックアウトされてもよい。一例では、供給停止インテリジェンスアプリケーションは、特定のフィーダ回路が通常動作状態であるとブロック２４００にて判断する一方で、「遮断器トリップおよびロックアウト」メッセージ２４１４を受信してもよい。遮断器トリップおよびロックアウトメッセージ２４１４は、特定のフィーダ回路に相互接続した遮断器がトリップし、その特定のフィーダ回路に影響を及ぼしていることを示すとよい。メッセージ２４１４の受信は、ブロック２４１６にて供給停止インテリジェンスアプリケーションに、その特定のフィーダ回路が「フィーダロックアウト済み」状態であると判断させるとよい。供給停止インテリジェンスアプリケーションは、特定のフィーダ回路がフィーダロックアウト済み状態であるとの判断に移行するときに、フィーダメッセージ一時停止通知２４０８を生成するとよい。

供給停止インテリジェンスアプリケーションは、特定のフィーダ回路がフィーダロックアウト済み状態にあるとブロック２４１６にて判断する一方で、トリップした遮断器がリセットされたことを示すリセットメッセージ２４１８を受信してもよく、これにより、この特定のフィーダ回路が通常動作状況であると、ブロック２４００にて供給停止インテリジェンスアプリケーションが判断できる。

遮断器を手動で開放することなどによる、特定のフィーダ回路に影響を及ぼす強制的な供給停止も生じ得る。一例では、供給停止インテリジェンスアプリケーションは、特定のフィーダ回路が通常状態であるとブロック２４００にて判断する一方で、遮断器の状況を監視する遮断器内のデバイスから「手動遮断器開放」メッセージ２４２０を受信することもある。メッセージ２４２０の受信に基づき、供給停止インテリジェンスアプリケーションは、ブロック２４００における特定のフィーダ回路が通常動作状態であるとの判断から、ブロック２４２２における、この特定のフィーダ回路が強制的供給停止状態であるとの判断に移行するとよい。供給停止インテリジェンスアプリケーションは、ブロック２４２２における特定のフィーダ回路の状態の判断に移行する間に、１つ以上のフィーダメッセージ一時停止通知２４０８を生成するとよい。供給停止インテリジェンスアプリケーションは、特定のフィーダ回路が強制的供給停止状態であると判断する一方で、別の即時電圧チェックをリクエストしてもよく、これは、ラインセンサーまたはスマート計器１６３などの別のデータソースを使用するフィーダ電圧のチェックを提供し、これは逆流給電（ｂａｃｋｆｅｅｄ）などの当該状況を示すこともある。

供給停止インテリジェンスアプリケーションは、特定のフィーダ回路が強制的供給停止状態であると判断する一方で、リセットメッセージ２４１８を受信するとよい。リセットメッセージ２４１８は、遮断器が閉じられたことを示すとよく、これによって、ブロック２４００にて供給停止インテリジェンスアプリケーションは、特定のフィーダ回路が通常動作状態であると判断できる。ブロック２４２２から、ブロック２４００における状態の判断に移行する間に、供給停止インテリジェンスアプリケーションは、１つ以上のフィーダメッセージ再開通知２４１２を生成するとよい。図２４は、特定のフィーダ回路に関して供給停止インテリジェンスアプリケーションを示しているが、供給停止インテリジェンスアプリケーションは、各電力グリッド内の所望の任意数のフィーダ回路からのイベントメッセージを同じように管理するよう構成されているとよい。

図２５は、電力グリッドのセクションに関連する供給停止状況を管理する動作フロー図である。一例では、ブロック２５００にて供給停止インテリジェンスアプリケーションは、特定のセクションの通常動作状態を判断するとよい。供給停止インテリジェンスアプリケーションは、特定のセクションに関連するフィーダ回路が機能停止しているか、または正常に機能していない可能性があることを示す、「フィーダ一時停止」メッセージ２５０２を受信するとよく、これが原因で、ブロック２５０４にて供給停止インテリジェンスアプリケーションは、特定のセクションが「フィーダ機能停止の疑い」状態であることを判断する。供給停止インテリジェンスアプリケーションは、特定のセクションがフィーダ機能停止の疑い状態であると判断する一方で、別の電圧チェックをリクエストしてもよく、これは、ラインセンサーまたはスマート計器１６３などの別のデータソースを使用するセクション電圧のチェックを提供する。

供給停止インテリジェンスアプリケーションはさらに、上流のセクションが一時停止されていることを示す「上流セクション一時停止」メッセージ２５０６を受信することもある。メッセージ２５０６は、上流のフィーダから受信されるとよい。メッセージ２５０６の受信は、ブロック２５０４にて供給停止インテリジェンスアプリケーションに、特定のセクションがフィーダ機能停止の疑い段階であると判断させるとよい。「別の電圧チェック失敗」状況２５０８は、ブロック２５１０にて供給停止インテリジェンスアプリケーションに、特定のセクションがセクション機能停止状態であると判断させ、これは、特定のセクションが電力を失ったことを示す。供給停止インテリジェンスアプリケーションは、特定のセクションがセクション機能停止状態であるとの判断に移行する一方で、セクション機能停止メッセージ２５１２を生成するとよく、これは下流のセクションによって受信されるとよく、スマート計器１６３、ラインセンサーなど、このセクションに関連する他のデバイスからのメッセージのフィルタリングを一時停止するとよい。

「別の電圧チェック’ＯＫ’」メッセージ２５１４が、供給停止インテリジェンスアプリケーションによって受信されることもあり、これはブロック２５１６にて供給停止インテリジェンスアプリケーションに、特定のセクションが逆流給電状態であると判断させ、これは、特定のセクションが電力グリッド内で動作している他のセクションによって逆流給電されている可能性があることを示す。供給停止インテリジェンスアプリケーションは、逆流給電状態を判断する一方で、「上流セクション再開」メッセージ２５１８を上流のセクションから受信することもあり、これによってブロック２５００にて供給停止インテリジェンスアプリケーションは、特定のセクションが通常動作状態であると判断できる。

供給停止インテリジェンスアプリケーションは、特定の状態が通常動作状態で動作していると判断する一方で、「センサー電圧損失イベント」メッセージ２５２０、「上流区分器（ｓｅｃｔｉｏｎａｌｉｚｅｒ）開放」メッセージ２５２２、および／または「計器機能停止」メッセージ２５２４を受信することもあり、それぞれの受信は、ブロック２５２６にて供給停止インテリジェンスアプリケーションに、特定のセクションが「セクション機能停止疑い」状態であると判断させてもよく、これは、特定のセクションがサービス停止中である可能性があるということを示す。供給停止インテリジェンスアプリケーションは、特定のセクションが「セクション機能停止の疑い」状態であるとブロック２５２６にて判断する一方で、別の電圧チェックをリクエストするとよい。供給停止インテリジェンスアプリケーションは、状態２５２６を判断する一方で、別の電圧チェック「ＯＫ」メッセージ２５１４を受信することもあり、これは、ブロック２５００にて供給停止インテリジェンスアプリケーションに、特定のセクションが通常動作状態であると判断させる。別の電圧チェック失敗メッセージ２５０８の受信は、ブロック２５１０にて供給停止インテリジェンスアプリケーションに、特定のセクションがセクション機能停止状態で動作していると判断させるとよく、セクション機能停止メッセージ２５１２を生成するとよい。

供給停止インテリジェンスアプリケーションは、セクション機能停止状態をブロック２５１０にて判断する一方で、セクションが通常通り動作していることを示す「電圧チェック’ＯＫ’」メッセージ２５２８を受信することもあり、これは、ブロック２５００にて供給停止インテリジェンスアプリケーションに、特定のセクションが通常状態で動作していると判断させる。さらに、供給停止インテリジェンスアプリケーションは、下流のセクションへの「セクション’ＯＫ’」メッセージ２５３０を生成してもよく、さらに、セクションデバイスメッセージのフィルタリングを再開してもよい。

供給停止インテリジェンスアプリケーションは、特定のセクションが通常動作状態であるとブロック２５００にて判断する一方で、「一時停止」メッセージ２５３２を受信することもあり、これは、供給停止インテリジェンスアプリケーションを、ブロック２５３４の、特定のセクションが一時停止状態であるとの判断に移行させる。供給停止インテリジェンスアプリケーションが一時停止状態であると判断する一方で、供給停止インテリジェンスアプリケーションは、特定のセクションからの供給停止メッセージの処理を一時停止するとよい。さらに、供給停止インテリジェンスアプリケーションは、特定のセクションに関連するデバイスによって処理される１つ以上の「デバイス一時停止」メッセージ２５３６を生成して、さらなるメッセージの生成を一時停止してもよい。

供給停止インテリジェンスアプリケーションは、特定のセクションが一時停止状態であると判断する一方で、「再開」メッセージ２５３７を特定のセクションから受信することもあり、これは、特定のセクションが通常通り動作していることを示し、したがって、ブロック２５００にて供給停止インテリジェンスアプリケーションに、特定のセクションが通常動作状態であると判断させる。さらに、供給停止インテリジェンスアプリケーションは、特定のセクションに関連するデバイスによって受信されて処理される１つ以上の「デバイス再開」メッセージ２５３８を生成して、メッセージの生成を再開してもよい。

特定のセクションが通常動作状態であるとブロック２５００にて判断する一方で、特定のセクションに関連しさらなるメッセージ生成を一時停止する、処理されるデバイスは、特定のセクションから、セクションが切り替えられようとしており通常動作とは異なるセクションの挙動が生じるかもしれないことを示す「切り替え待ち」メッセージ２５４０を受信することもある。供給停止インテリジェンスアプリケーションは、メッセージ２５４０を受信すると、１つ以上のデバイス一時停止メッセージ２３３６を生成し、特定のセクションが切り替え状態であるとブロック２５４２にて判断してもよい。供給停止インテリジェンスアプリケーションは、特定のセクションが切り替え状態であると判断する一方で、特定のセクションによって生成されるセクション供給停止メッセージを無視してもよい。供給停止インテリジェンスアプリケーションは、特定のセクションに関して切り替えが実行されたことを示す「切り替え完了」メッセージ２５４４を受信してもよく、これによって、ブロック２５００にて供給停止インテリジェンスアプリケーションは、特定のセクションが通常動作状態であると判断できる。さらに、供給停止インテリジェンスアプリケーションは、１つ以上のデバイス再開メッセージ２５３８を生成してもよい。図２５は、特定のセクションに関して供給停止インテリジェンスアプリケーションを示しているが、供給停止インテリジェンスアプリケーションは、各電力グリッド内の所望の任意数のセクションからのイベントメッセージを同じように管理するよう構成されているとよい。

電力グリッドの故障は、物理的短絡、開回路、障害を起こしたデバイスおよび過負荷など、回路素子が所望の形で機能することができないようにする物理的状況として定義され得る。事実上、ほとんどの故障は、何らかのタイプの短絡を伴い、「故障」という用語は、短絡と同義であることが多い。短絡は、適切な回路動作のために意図されたもの以外の何らかのパスに電流を流す、何らかの形の異常な接続であり得る。短絡故障は、非常に低いインピーダンスを有する（「ボルテッド故障（ｂｏｌｔｅｄ ｆａｕｌｔ）」としても既知である）ことも、または相当量の故障インピーダンスを有することもある。ほとんどの場合、ボルテッド故障の結果、電気保護デバイスが動作し、電気会社の一部の顧客に供給停止が生じる。電気保護デバイスの動作を防ぐのに十分なインピーダンスを有する故障は、高インピーダンス（高Ｚ）故障として既知である。そのような高インピーダンス故障は、供給停止にはつながらないかもしれないが、著しい電力品質問題を生じさせることもあり、電気会社の設備に深刻な損害をもたらすこともある。垂れ下がっているがまだ電圧が印加されている送電線の場合、高インピーダンス故障は安全上の問題ももたらし得る。

導体が切り離されているが短絡は引き起こさない欠相故障（ｏｐｅｎ ｐｈａｓｅ ｆａｕｌｔ）など、その他の故障のタイプが存在する。欠相故障は、切断につながる導体の不具合の結果であることも、または、側相（ｌａｔｅｒａｌ ｐｈａｓｅ）ヒューズが切れてその位相が事実上切り離されたままとなる、ボルテッド位相故障（ｂｏｌｔｅｄ ｐｈａｓｅ ｆａｕｌｔ）の副作用であることもある。上記の欠相故障は、顧客へのサービス喪失につながることもあるが、外見的には切り離されている位相線に、逆流給電と呼ばれるプロセスによってまだ電圧が印加されていることもあるため、安全上の問題ももたらし得る。欠相故障は、柱上スイッチにおける結線不具合の結果であることが多い。

いずれの故障も、物理的な不安定性によって、またはアーク放電、ワイヤの焼失、電磁力などの影響によって別の故障タイプへと変わることもある。そのような故障は、進展故障と呼ばれることもあり、進展プロセスおよび故障タイプの段階の検出は、電気会社の技術者の関心事である。

電力グリッドの運用において、故障の検出、さらに、インテリジェントグリッド計測手段が可能にする限り正確な故障の分類および故障の位置特定が望まれている。ボルテッド故障は、瞬時で自動解消するもの、または持続するもの（故障が現場要員によって解消されるまで電気保護デバイスによる電力の遮断が必要）として分類され得る。高インピーダンス故障に関しては、断続的なもの（繰り返し発生するが頻繁ではない）と、持続性のもの（ランダムに発生するがほとんど絶え間がない）とが区別されてもよい。故障はさらに、静的である、または進展している（多段故障（ｍｕｌｔｉ−ｓｔａｇｅ ｆａｕｌｔｓ）としても既知である）と認識されることもある。先述のように、進展故障は、１つのタイプとして始まることも、または１つの位相もしくは一対の位相を巻き込んで始まることもあり、続いて、時間がたつにつれて別のタイプに変化することも、またはさらに多くの位相を巻き込むこともある。進展故障の例は、ラインヒューズが切れる原因になる１線地絡（「ＳＬＧ：ｓｉｎｇｌｅ−ｌｉｎｅ−ｔｏ−ｇｒｏｕｎｄ」）故障である。プラズマが、上に設けてある線へと上昇すれば、最初のＳＬＧ故障から、続いて相間故障に進展することもある。

基本的な過電流検出および分析などの従来の故障検出は、変電所でほとんど行われた測定から実行され、一部のシステムでは、スマートスイッチおよびリクローザーなどの柱上デバイスを用いて実行される。しかし、高インピーダンス故障など、多くの故障は、特に変電所では特性波形が弱すぎるため、この方法で検出または分類することはできない。インテリジェントグリッドとの関連では、ＲＴＵを備えるラインセンサー、計器、および、変電所のマイクロプロセッサリレー（ならびにその関連する計器用変圧器および変流器）を含む、分散した一連のデータソースが利用可能であるとよい。こうすることで、フィーダ回路の様々なポイントにおけるセンサーからのデータを、他のフィーダー回路からのデータと、さらに必要であれば他の変電所からのデータとまで組み合わせて、高度なグリッド故障分析を実行する能力が得られる。

表４には、インテリジェント電力グリッドの、様々な故障タイプ、位相の関与、およびグリッド状態挙動（ｇｒｉｄ ｓｔａｔｅ ｂｅｈａｖｉｏｒ）が記載されている。

表４−故障タイプ

故障タイプおよび関連するグリッド状態挙動の明確な表現を規定することで、ＲＴＵ、変電所解析、制御センター解析データ獲得および処理に関する故障定義が可能になるとよい。一例では、３相システムなどの多相電力グリッドでは、故障解析に同期フェーザデータが利用され得る。特に、変電所レベルで生じている特定の故障タイプを特定するために、インターフェーザが分析されてもよい。

表５は、ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０でのイベントの特定につながり得る、３相電力グリッド内で特定され得る様々な故障を含む。ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０またはＩＮＤＥ ＣＯＲＥ１２０は、各故障タイプを、イベントコードを用いて分類するよう構成されているとよい。各イベントコードは、ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０などの変電所レベルで認識されるイベントタイプを表すとよい。各故障タイプは、Ａ、ＢおよびＣなど、各位相のフェーザ大きさおよびフェーザ角に関する複数の所定の質に基づき特定されてもよい。一例では、個々のフェーザ（大きさおよび角度）、ならびに、Ａ−Ｂ、Ｂ−Ｃ、およびＡ−Ｃなど、フェーザ間の相対的なフェーザ値を指すとよいインターフェーザが分析されるとよい。以下の表５に示されている様に、各位相のリアルタイムフェーザ値および公称フェーザ値が、故障発生および故障タイプを判断するために使用されるとよい。

表５−故障特定基準

図２６は、電力グリッド内での故障評価の例示動作フロー図である。一例では、故障評価は、故障の存在の特定および故障タイプの特定を含むとよい。図２６の動作フロー図は、故障インテリジェンスアプリケーション（図１４参照）によって実行されるとよい。一例では、故障タイプは、故障インテリジェンスアプリケーションによって、表５の故障特定基準分類に基づき判断されてもよい。電力グリッド内の各位相の同期フェーザデータが、フェーザ測定ユニット（ＰＭＵ：ｐｈａｓｏｒ ｍｅａｓｕｒｅｍｅｎｔ ｕｎｉｔ）データ収集ヘッドから取得されるとよく、ＰＭＵは、ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０グループ内に位置するか、または電力グリッドの中央局にて中央に位置するとよい。ＰＭＵは、各位相Ａ、Ｂ、およびＣに関して、フェーザ大きさおよびフェーザ角データなど、同期フェーザデータを含む位相情報を測定して、提供するとよく、これは、故障が存在するかどうかを判断し、故障タイプを判断するために生成および分析されるとよい。位相情報が、ブロック２６００にて、故障インテリジェンスアプリケーションによって受信されるとよい。ブロック２６０２にて、故障の疑いがあるかもしれないという判断が実行されるとよい。一例では、ブロック２６０２にて故障インテリジェンスアプリケーションは、分析されている各位相に関するフェーザ大きさおよびフェーザ角データに関連する閾値に基づき、判断を下すとよい。

１つ以上の故障状況の疑いがあると判断されると、ブロック２６０４にて、各位相のフェーザ角基準が適用されるとよい。ブロック２６０６にて、位相情報に基づき所定のフェーザ角基準に合致しない１つ、いくつか、またはすべての故障タイプが、故障タイプ候補としてのさらなる考慮から除外されるとよい。しかし、フェーザ角基準が特定の故障タイプに対し該当なしであれば（表５で「Ｎ／Ａ」と示されている）、故障タイプは、故障タイプ候補としての考慮に残るとよい。考慮されるのがすべての故障タイプではない場合、当該の故障タイプがブロック２６０８にて考慮から除外されるとよい。

ブロック２６１０にて、各位相の所定の相対的フェーザ大きさ変化基準が、位相情報に適用されるとよい。ブロック２６１２にて、所定の相対的フェーザ大きさ情報に合致しない１つ、いくつか、またはすべての故障タイプが除外される。しかし、相対的フェーザ大きさ変化に関して該当なしであるなど、まだ考慮中の故障タイプは除外されてはならない。ブロック２６１４にて、特定された故障タイプが除外されるとよい。ブロック２６１６にて、所定のインターフェーザ角基準が、位相情報に適用されるとよい。所定のインターフェーザ角基準の適用に基づき除外される、残りの任意の故障タイプ候補の判断が、所定のインターフェーザ角基準に基づきブロック２６１８にて実行されるとよい。任意の当該故障タイプが、ブロック２６２０にて考慮から除外されるとよい。インターフェーザ角が該当なしの、まだ考慮中の任意の故障タイプ候補は、除外するには不適当であると考えられる。

ブロック２６２２にて、所定の相対的インターフェーザ角変化基準が、考慮中の、残りの故障タイプ候補に適用されるとよい。ブロック２６２４にて、まだ考慮中の、残りの任意の故障タイプ候補が、所定の相対的インターフェーザ角変化基準に基づき、除外されるよう特定されるとよい。様々な基準の適用によって、ブロック２６２４にて、適用された所定の基準のすべてに合致するとして、単一の故障タイプ候補が生成されるとよい。

ブロック２６２６にて、故障状況の候補の連続読み取り数と、所定の連続読み取り基準とが比較されるとよい。表５に示されている様に、特定の故障タイプが存在すると判断する前に、特定された故障状況の候補がいくつかの連続読み取りにわたって存在することが要求されるとよい。ブロック２６２６にて連続読み取りの数が満たされると、ブロック２６２８にて、故障インテリジェンスアプリケーションによって故障メッセージが生成されるとよく、これは、故障によって影響され得る電力グリッド内の他のデバイスに送られてもよく、または、特定の故障タイプについて関与する関係者に警告するために使用されてもよい。連続読み取りの数が満たされなければ、動作フロー図はブロック２６００に戻るとよい。

図２６における、ブロック２６０４、２６１０、２６１６、および２６２２での表５の様々な基準の適用は、図２６に関して記載された以外の順序で実行されてもよい。代替例では、図２６の動作フロー図は、図２６に関して記載されたよりも少ない、または追加のブロックを含んでもよい。例えば、表５の基準は、各位相のフェーザ大きさおよびフェーザ角を含む各位相のフェーザ情報に適用するために、並行した形で使用される。例えば、図２６のブロック２６０４、２６１０、２６１６、および２６２２に記載されている適用は、並行して実行されて、故障が存在すれば故障タイプが特定できるとよい。ブロック２６２６での連続読み取り判断は、表５の他の基準の適用の後で実行されても、またはそれと並行して実行されてもよい。

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

Claims (11)

1. 電力グリッドの少なくとも１つの部分に関連する供給停止状況を管理する方法であって、前記方法は少なくとも１つのプロセッサとメモリを有するコンピュータで実行可能であり、
   前記電力グリッドの前記少なくとも１つの部分に関連する状況をそれぞれ示す、複数のイベントメッセージを受信するステップと、
   前記少なくとも１つのプロセッサを使用して、前記複数のイベントメッセージのうちの少なくとも１つが、前記電力グリッドの前記少なくとも１つの部分に関連する供給停止状況を示すと判断するステップと、
   前記電力グリッドの現在の需要状況を表すグリッド状態データの少なくとも一部分を読み出すステップと、
   前記電力グリッドの物理的構成を表す接続性データの少なくとも一部分を読み出すステップと、
   前記少なくとも１つのプロセッサを使用して、前記グリッド状態データおよび接続性データに基づき、前記供給停止状況の存在を検証するステップと、
   前記少なくとも１つのプロセッサを使用して、前記供給停止状況を表す少なくとも１つのメッセージを生成するステップであって、前記メッセージは、前記供給停止状況の通知を提供するよう構成されている、前記ステップと、
   前記電力グリッドの前記少なくとも１つの部分における少なくとも１つのデバイスから、前記複数のイベントメッセージの処理を一時停止するための少なくとも１つの一時停止メッセージを受信するステップであって、前記一時停止メッセージは、前記少なくとも１つのデバイスの検出された不正変更を示すものである、前記ステップと、
   前記少なくとも１つの一時停止メッセージの受信に応答して、前記少なくとも１つのデバイスから受信した前記イベントメッセージの処理を一時停止するステップと、
   を含む前記方法。
2. 前記方法は、
   前記電力グリッドの前記少なくとも一部分に関連する第１の状態を、前記複数のイベントメッセージに基づき判断するステップであって、前記第１の状態は、前記供給停止状況の存在しない、前記電力グリッドの前記少なくとも１つの部分の動作を示す、前記ステップと、
   前記電力グリッドの前記少なくとも一部分に関連する第２の状態を、前記複数のイベントメッセージのうち、前記供給停止状況を示す前記少なくとも１つに基づき判断するステップと、
   をさらに含み、
   前記供給停止状況を表す前記少なくとも１つのメッセージを生成するステップは、前記第２の状態の判断を含む、
   請求項１に記載の方法。
3. 前記供給停止状況を示す前記複数のイベントメッセージを受信するステップは、前記電力グリッドの前記少なくとも１つの部分から電力供給停止通知メッセージを受信するステップを含み、前記電力供給停止通知メッセージは、前記供給停止状況の存在を示すよう構成されている、
   請求項１に記載の方法。
4. 前記供給停止状況が、前記電力グリッドの前記少なくとも一部分から除去されると、前記電力グリッドの前記少なくとも１つの部分から電力復旧通知メッセージを受信するステップをさらに含む、
   請求項３に記載の方法。
5. コンピュータの少なくとも１つのプロセッサによって実行可能な供給停止インテリジェンスアプリケーションを含む電力グリッド供給停止管理システムであって、前記供給停止インテリジェンスアプリケーションは、
   前記電力グリッドの少なくとも１つの部分に関連する動作状況を示す複数のイベントメッセージであって、前記複数のイベントメッセージのうちの少なくとも１つは、前記電力グリッドの前記少なくとも１つの部分に関連する供給停止状況を示す、前記複数のイベントメッセージを受信し、
   前記電力グリッドの現在の需要状況を表すグリッド状態データの少なくとも一部分を読み出し、
   前記電力グリッドの物理的構成を表す接続性データの少なくとも一部分を読み出し、
   前記複数のイベントメッセージのうちの前記少なくとも１つ、前記グリッド状態データ、および前記接続性データに基づき、前記電力グリッドの前記少なくとも１つの部分に関連する供給停止状況の存在を判断し、
   前記供給停止状況の前記存在を示し、前記供給停止状況の前記存在の通知を中央電力局に提供するよう構成されている、少なくとも１つのメッセージを生成し、
   前記電力グリッドの前記少なくとも１つの部分における少なくとも１つのデバイスから、前記複数のイベントメッセージの処理を一時停止するための少なくとも１つの一時停止メッセージを受信し、ここで前記一時停止メッセージは、前記少なくとも１つのデバイスの検出された不正変更を示すものであり、
   前記少なくとも１つの一時停止メッセージの受信に応答して、前記少なくとも１つのデバイスから受信した前記イベントメッセージの処理を一時停止するよう実行可能である、
   電力グリッド供給停止管理システム。
6. 前記供給停止インテリジェンスアプリケーションは、
   前記供給停止状況が存在している時間を判断し、
   前記時間と、所定の期間とを比較し、
   前記判断された時間が前記所定の時間より長ければ、前記供給停止状況は持続的供給停止状況であると判断し、
   前記供給停止状況は持続的供給停止状況であると、前記少なくとも１つのメッセージにおいて示すようさらに実行可能である、
   請求項５に記載の電力グリッド供給停止管理システム。
7. 前記供給停止インテリジェンスアプリケーションは、
   前記供給停止状況が存在している時間を判断し、
   前記時間と、所定の期間とを比較し、
   前記判断された時間が前記所定の時間より短ければ、前記供給停止状況は瞬時供給停止状況であると判断し、
   前記供給停止状況は瞬時供給停止状況であると、前記少なくとも１つのメッセージにおいて示すようさらに実行可能である、
   請求項５に記載の電力グリッド供給停止管理システム。
8. 前記供給停止インテリジェンスアプリケーションは、前記少なくとも１つのメッセージを、供給停止イベントログに送るようさらに実行可能である、
   請求項７に記載の電力グリッド供給停止管理システム。
9. 前記供給停止インテリジェンスアプリケーションは、
   前記複数のイベントメッセージの処理を再開するための少なくとも１つの再開メッセージを受信し、
   前記少なくとも１つの再開メッセージの受信に基づき、前記複数のイベントメッセージの処理を再開するようさらに実行可能である、
   請求項５に記載の電力グリッド供給停止管理システム。
10. 前記電力グリッドの前記少なくとも１つの部分は、フィーダ回路であり、前記供給停止インテリジェンスアプリケーションは、
    前記フィーダ回路内の前記供給停止状況の前記存在を示し、前記フィーダ回路内の前記供給停止状況の前記存在の通知を中央電力局に提供するよう構成されている、少なくとも１つのメッセージを生成するようさらに実行可能である、
    請求項５に記載の電力システム供給停止管理システム。
11. 前記供給停止インテリジェンスアプリケーションは、前記フィーダ回路内の前記供給停止状況の前記存在に基づき、前記フィーダ回路と相互接続した少なくとも１つのデバイスからのイベントメッセージの処理を一時停止するようさらに実行可能である、
    請求項１０に記載の電力システム供給停止管理システム。

Images