JP2013533531A - 悪意のある攻撃の検出および分析 - Google Patents

Abstract

インテリジェントユーティリティグリッドシステムにおける悪意のあるアクティビティを特徴評価するシステムは、複数のルールを含むデータベースを記憶するシステム記憶装置を含む。コレクタが、情報技術（ＩＴ）関係アクティビティを含むＩＴデータをインテリジェントグリッドシステムから収集してシステム記憶装置に記憶するよう動作可能である。複合イベント処理（ＣＥＰ）バスが、特定の位置に関するイベントデータを含む非ＩＴデータを複数の電子ソースから受信するよう動作可能であり、ＣＥＰバスは、複数のリスク関係イベントのうちの１つに対する関連性の所定のレベルに満たない非ＩＴデータを無視するようさらに動作可能である。プロセッサが、望ましくないイベントを、ＩＴ関係アクティビティを参照して関連付け、望ましくないイベントが悪意のあるアクティビティを示す確率を判断するために、関連性のある非ＩＴデータに複数のルールを適用するよう動作可能である。プロセッサはさらに、確率およびＩＴ関係アクティビティに基づき、望ましくないイベントにリスク特徴評価を適用する。

Description

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

１．発明の分野
本発明は、全般的に、インテリジェントユーティリティグリッドシステムにおける望ましくないイベントを検出および特定するシステムおよび方法に関し、特に、インテリジェントユーティリティグリッドシステムに対する悪意のある攻撃を検出および特定するシステムおよび方法に関する。

２．関連技術
スマートグリッドに対するインターネットプロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、工業制御システム（ＩＣＳ：Ｉｎｄｕｓｔｒｉａｌ Ｃｏｎｔｒｏｌ Ｓｙｓｔｅｍ）、物理制御システムおよび監視制御データ収集（ＳＣＡＤＡ：Ｓｕｐｅｒｖｉｓｏｒｙ Ｃｏｎｔｒｏｌ ａｎｄ Ｄａｔａ Ａｃｑｕｉｓｉｔｉｏｎ）攻撃の目標は、１つ以上の弱点（例えば、グリッド上のワイヤレスノードの無線周波数（ＲＦ：Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）妨害、鍵導出、ファームウェアのフラッシング、不適当なエンティティからの匿名入力、物理的なハードウェア不正変更）を利用して、グリッドの通常動作をバイパスすることである。こうしたリスクの多くには、ＩＣＳ／ＳＣＡＤＡセキュリティ制御、物理的セキュリティ制御、またはエンタープライズ情報技術（ＩＴ：ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ）、運用もしくは物理的セキュリティ制御のいずれかによって対処される、明確なソリューションがある。残存リスクは、セキュリティ制御が適用された後の残りのリスクである。多くのシステムは、決して完全にセキュアになることはなく、残存リスクは常に残る。スマートグリッドのサイバーセキュリティの課題に直面する場合、ＳＣＡＤＡ、エンタープライズＩＴ、運用または物理的セキュリティ制御によって軽減される典型的なリスクの範囲を超えた、残存セキュリティリスクが残る。

本開示の一側面によれば、インテリジェントユーティリティグリッドシステムにおける悪意のあるアクティビティを特徴評価する（ｃｈａｒａｃｔｅｒｉｚｅ）方法は、情報技術（ＩＴ）関係アクティビティを含むＩＴデータをインテリジェントグリッドシステムから受信するステップを含むとよい。本方法は、特定の位置に関する（ｌｏｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ）イベントデータを含む非ＩＴデータを複数の電子ソース（ｅｌｅｃｔｒｏｎｉｃ ｓｏｕｒｃｅ）から受信するステップをさらに含むとよい。後でさらに詳しく説明するように、非ＩＴデータは、電力グリッドによって従来使用されていない情報技術関係情報（またはデータ）、ならびに過去データおよび高価値ターゲット（ｈｉｇｈ ｖａｌｕｅ ｔａｒｇｅｔ）のアドレスまたは位置などの情報を含む。本方法は、非ＩＴデータを前処理するステップであって、複数のリスク関係イベントのうちの１つに対する関連性の所定のレベルに満たない非ＩＴデータを無視することを含む、該ステップをさらに含むとよい。本方法は、望ましくないイベントを、ＩＴ関係アクティビティを参照して関連付け、望ましくないイベントが悪意のあるアクティビティを示す確率を判断するために、複数のルールを、前処理された非ＩＴデータに適用するステップをさらに含むとよい。イベントは、既に発生していても、まだ発生していなくてもよい。本方法は、確率およびＩＴ関係アクティビティに基づき、望ましくないイベントにリスク特徴評価（ｒｉｓｋ ｃｈａｒａｃｔｅｒｉｚａｔｉｏｎ）を適用するステップをさらに含むとよい。

本開示の別の側面によれば、インテリジェントユーティリティグリッドにおける悪意のあるアクティビティを特徴評価するシステムは、複数のルールを含むデータベースを記憶するシステム記憶装置を含むとよい。コレクタが、情報技術（ＩＴ）関係アクティビティを含むＩＴデータをインテリジェントグリッドシステムから収集してシステム記憶装置に記憶するよう動作可能であるとよい。複合イベント処理（ＣＥＰ：ｃｏｍｐｌｅｘ ｅｖｅｎｔ ｐｒｏｃｅｓｓｉｎｇ）バスが、特定の位置に関するイベントデータを含む非ＩＴデータを複数の電子ソースから受信するよう動作可能であるとよく、ＣＥＰバスは、複数のリスク関係イベントのうちの１つに対する関連性の所定のレベルに満たない非ＩＴデータを無視するようさらに動作可能である。プロセッサが、望ましくないイベントを、ＩＴ関係アクティビティを参照して関連付け、望ましくないイベントが悪意のあるアクティビティを示す確率を判断するために、関連性のある非ＩＴデータに複数のルールを適用するよう動作可能であるとよい。プロセッサは、確率およびＩＴ関係アクティビティに基づき、望ましくないイベントにリスク特徴評価を適用するようさらに動作可能であるとよい。リスク特徴評価は、例えば、保守チームが派遣されるとよいエンジニアリングリスク（ｅｎｇｉｎｅｅｒｉｎｇ ｒｉｓｋ）を含んでもよく、または法執行機関が通報を受けるセキュリティリスクであってもよい。

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

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

概要として、以下に記載される好適な実施形態は、電力グリッドを管理する方法およびシステムに関する。以下でさらに詳しく説明するように、特定の側面は電力グリッド自体に関する（送電および／または配電におけるハードウェアおよびソフトウェアを含む）。さらに、特定の側面は電力グリッドの中央管理の機能的能力に関する。こうした機能的能力は、動作およびアプリケーションの２つのカテゴリにグループ化され得る。動作サービスは、ユーティリティが、スマートグリッドインフラストラクチャ（例えばアプリケーション、ネットワーク、サーバ、センサーなど）を監視および管理できるようにする。本願明細書で開示される方法およびシステムは、参照によって本願明細書にその内容全体を引用したものとする次の特許出願に関係する：米国特許出願第１２／３７８，１０２号（米国特許出願公開第２００９／０２８１６７４（Ａ１）号として公開されている）、および米国特許出願第１２／３７８，０９１号（米国特許出願公開第２００９／０２８１６７３（Ａ１）号として公開されている）。

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

一実施形態では、ユーティリティシステムは、ユーティリティシステムのインテリジェンスに対する、望ましくない結果を引き起こす悪意のある攻撃を回避するための、インテリジェントセキュリティシステムを含むとよい。そのような悪意のある攻撃を回避するには、または少なくともそのような攻撃を迅速に検出するには、ユーティリティシステムは、望ましくないイベントを検出および特徴評価し、ひいてはそのようなイベントを有用な形でカテゴリ化できる必要がある。そのようなユーティリティシステムの１つは、電気スマートグリッドユーティリティシステムである。攻撃には、インターネットプロトコル（ＩＰ）および監視制御データ収集（ＳＣＡＤＡ）システムに対する攻撃があり得、特定の目標があることもある。そのような目標には、グリッド上のワイヤレスノードの無線周波数（ＲＦ）妨害、鍵導出、不適当なエンティティからの匿名入力、物理的なハードウェア不正変更によってなど、１つ以上の弱点を利用してスマートグリッドの通常動作をバイパスすることが含まれ得る。こうした問題の多くには、ＳＣＡＤＡセキュリティ制御、またはエンタープライズおよび運用セキュリティ制御のいずれかによって対処されるソリューションがある。「残存リスク」は、セキュリティ制御が適用された後の残りのリスクと見なされるとよい。スマートグリッドのサイバーセキュリティの課題に直面する場合、ＳＣＡＤＡ、エンタープライズＩＴ、運用または物理的セキュリティ制御によって軽減される典型的なリスクの範囲を超えることもある、残存セキュリティリスクが残る。

一実施形態では、インシデントイベント（Ｉ）は、望ましくないイベントの発生であるとよい。インシデントの確率（Ｐ（Ｉ））は、インシデントの発生が、脅威の存在および脅威によって利用され得る脆弱性の存在に基づく可能性または見込みであるとよい。脅威イベント（Ｔ）は、悪意のある意図的な攻撃または予期しないハザードであるとよい。下記の式１は、悪意のある攻撃の発生の確率（Ｐ（Ａ））、および各攻撃に関する脆弱性の存在の積と、予期しないハザードの発生の確率（Ｐ（Ｈ））プラス予期しないハザードそれぞれに関連する脆弱性の確率との和としての、インシデントの発生の確率に関する。式１は、例えば互いに独立した意図的な攻撃（Ａ）および予期しないハザード（Ｈ）など、互いに独立したイベントによって生じるインシデントの確率である。
式１ Ｐ（Ｉ）＝Π_ｉＰ（Ａ_ｉ）＊Π_ｊＰ（Ｈ_ｊ）
式中、ｉ、ｊは整数である。

残存リスク（ＲＲ：Ｒｅｓｉｄｕａｌ Ｒｉｓｋ）は、悪意のある意図的な攻撃および予期しないハザードをセキュリティ制御が軽減しない、確率的な結果とされ得る。式２は、十分な保護の欠如（「制御ギャップ」）により意図的または意図的でないセキュリティインシデントが発生する残存リスク（ＲＲ）、すなわち独立した意図的な攻撃および予期しないハザードイベントの、防止、検出およびそれからの保護を、セキュリティ制御が行わないリスクである。
式２ ＲＲ＝Ｐ（Ｉ）＊Ｐ（制御ギャップ）

式１により、セキュリティインシデントの確率が、エンタープライズ、動作およびＩＣＳに関して得られるとよい。式４〜６は、これらの式を示す。
式３ Ｐ（Ｉ_{ＥｎｔｅｒｐｒｉｓｅＩＴ}）＝Π_ｉＰ（Ａ_{ｉ，ＥｎｔｅｒｐｒｉｓｅＩＴ}）＊Π_ｊＰ（Ｈ_{ｊ ＥｎｔｅｒｐｒｉｓｅＩＴ}）
式４ Ｐ（Ｉ_{ＯｐｅｒａｔｉｏｎＩＴ}）＝Π_ｉＰ（Ａ_{ｉ，ＯｐｅｒａｔｉｏｎＩＴ}）＊Π_ｊＰ（Ｈ_{ｊ，ＯｐｅｒａｔｉｏｎＩＴ}）
式５ Ｐ（Ｉ_{ＳＣＡＤＡ ＩＴ}）＝Π_ｉＰ（Ａ_{ｉ，ＳＣＡＤＡ}）＊Π_ｊＰ（Ｈ_{ｊ，ＳＣＡＤＡ}）
式６ ＲＲ＝Ｐ（Ｉ）＊Ｐ（制御ギャップ）

式７は、スマートグリッド上のインシデントの確率が、例えばエンタープライズ、運用、ＳＣＡＤＡおよび残存など、別々の脅威イベントのソースの確率の和であることを示す。
式７ Ｐ（Ｉ_{Ｓｍａｒｔ Ｇｒｉｄ}）＝Ｐ（Ｉ_{Ｅｎｔｅｒｐｒｉｓｅ}）＋Ｐ（Ｉ_{Ｏｐｅｒａｔｉｏｎａｌ}）＋Ｐ（Ｉ_{ＳＣＡＤＡ}）＋Ｐ（Ｉ_{Ｒｅｓｉｄｕａｌ}）
式中、攻撃（Ａ）、ハザード（Ｈ）、脆弱性（Ｖ）および残存リスク（Ｒ）は、相互排他的である。

式３〜５の脆弱性は、従来の受動的なエンタープライズＩＴセキュリティによって対処されることもあり、これは例えば、ヘッダまたはパケット検査を活用し、典型的には、Ｃａｔａｌｙｓｔスイッチドポートアナライザ（ＳＰＡＮ：Ｓｗｉｔｃｈｅｄ Ｐｏｒｔ Ａｎａｌｙｚｅｒ）ポートまたはミラーポート（例えば、侵入検出システム（ＩＤＳ：Ｉｎｔｒｕｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ Ｓｙｓｔｅｍ）、コンテンツフィルタ）、アクティブシグネチャに基づく従来のＩＴセキュリティ（例えば、ファイアウォール）、能動的および受動的なスマートグリッド運用ＩＴセキュリティ（例えば、強化された高度計測インフラストラクチャコンポーネント、ＩＤＳのスマートグリッド脅威定義ファイル、ＮＥＲＣ−ＣＩＰ準拠のための自動ポリシーマネージャ）ならびにＳＣＡＤＡセキュリティを使用する。考慮される脆弱性の例には、以下が含まれ得る：
ヘッダ情報
パケットコンテンツ
ＳＣＡＤＡの異常
通信プロトコル
ソース＆ターゲットＩＰアドレス
ソース＆ターゲットＴＣＰおよびＵＤＰポート
通信の開始の指示
各種のトラフィックの量
パケットフォーマットおよびコンテンツ
エンタープライズおよび運用の多層防御の階層的セキュリティ手法を、ＳＣＡＤＡセキュリティに加えて実装すると、インシデントの確率がごくわずかになるかもしれない。結果として、式７は、以下のように式８に単純化され得る：
式８ Ｐ（Ｉ_{Ｓｍａｒｔ Ｇｒｉｄ}）＝Ｐ（Ｉ_{Ｒｅｓｉｄｕａｌ}）＋δ（Ｉ^＊）≪Ｐ（Ｉ_{Ｓｍａｒｔ Ｇｒｉｄ}）＋δ（Ｉ_{Ｏｐｅｒａｔｉｏｎａｌ ＩＴ}）＋δ（Ｉ_{ＳＣＡＤＡ}）

コンピュータ緊急対応チーム（ＣＥＲＴ：Ｃｏｍｐｕｔｅｒ Ｅｍｅｒｇｅｎｃｙ Ｒｅｓｐｏｎｓｅ Ｔｅａｍ）およびその他のＩＴセキュリティ監視組織は、制御システムに関する情報を収集するように設計されていないため、制御システムセキュリティは、その競争相手の制御システムセキュリティ監視データに関する組織的知識に依存しなければならない。セキュリティ侵害が公に知られることは、投資家の信頼および企業の評価に悪影響を与えると考えられるため、通常、このデータへのアクセスは共有されない。ホスト侵入検出システム（ＨＩＤＳ：Ｈｏｓｔ Ｉｎｔｒｕｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ Ｓｙｓｔｅｍ）は、ホストにインストールされたソフトウェアエージェントを活用して、ホストの異常な挙動を監視する。残念ながら、その独自リアルタイムオペレーティングシステム（ＯＳ：ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）または組み込みＯＳが原因で、例えば電気的プロセスの測定、制御および監視を行うＳＣＡＤＡコンポーネントなど、すべてのスマートグリッドコンポーネントにＨＩＤＳをインストールすることはできない。したがって、残存リスクには、意図的でないイベントに関連する脆弱性に加えて、ＨＩＤＳがもたらしたであろう可視性の欠如が含まれる。考慮されない脆弱性は、天災、容量の欠如、ＩＤＳおよびセキュリティ情報・イベントマネージャ（ＳＩＥＭ：ｓｅｃｕｒｉｔｙ ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ ｅｖｅｎｔ ｍａｎａｇｅｒ）によって認識されない固有プロトコル（例えばＭｏｄｂｕｓ ＴＣＰ、ＤＮＰ３、ＯＤＶＡ Ｅｔｈｅｒｎｅｔ／ＩＰ、ＩＣＣＰ）、偽陰性（例えば、供給停止がセキュリティイベントと誤診されることがある）、リモートノード（ＲＴＵ（Ｒｅｍｏｔｅ Ｔｅｒｍｉｎａｌ Ｕｎｉｔ：リモート端末ユニット）およびＰＬＣ）のアクセス制御、独自ノード上の完全性および異常チェック、独自リアルタイムＯＳまたは組み込みＯＳＳ、ならびに相互運用性によるフォレンジックの限界に関連する。

一実施形態では、複合イベントプロセッサ（または処理）（ＣＥＰ）バスが、様々なソースからのデータをフィルタリング、処理および相関させ、エネルギーシステムの不具合または異常など、将来発生するかもしれない、または過去に起こったかもしれないイベントを抽出するとよい。残存リスクの確率を下げるために、ＣＥＰバスは、ＩＤＳ、アンチウイルスまたはファイアウォールで認識されない異常を検出して除去するよう、電気ユーティリティルールなどのユーティリティルールにより調整されてもよい。システムへの入力は、グリッドの利用可能性、完全性および機密性に影響を及ぼすすべてのデータとするべきである。様々な電子ソースからの入力の例は、以下を含む：
天候フィード
障害レコーダ
デジタル故障レコーダ（オシログラフィ）
調波レコーダ
電力品質監視
デバイスステータス
接続性状態
制御限界
ＵＳ ＣＥＲＴフィード
構成要素フィード
ＧＰＳ（ｇｌｏｂａｌ ｐｏｓｉｔｉｏｎｉｎｇ ｓｙｓｔｅｍ：グローバルポジショニングシステム）
ＲＦ干渉
電力管理ユニット（ＰＭＵ：Ｐｏｗｅｒ Ｍａｎａｇｅｍｅｎｔ Ｕｎｉｔ）
センサー
負荷予測
再生可能発電（Ｒｅｎｅｗａｂｌｅ Ｇｅｎｅｒａｔｉｏｎ）予測

例えば、天候フィードは、使用中のサージによる供給停止および電圧低下を予想するために使用され得る（例えば、空調ユニットの電力使用の増加につながる高い温度）。さらに、ＣＥＲＴレポートおよびその他のエネルギー企業は、協働して、インシデントレポートデータベースを共有することができ、これは、誤用またはシステム侵害によって引き起こされる異常を特定するためにそれらのＣＥＰバスに供給され得る。

一実施形態では、ＳＩＥＭをスマートグリッドシステムに実装して、ＣＥＰおよびＳＩＥＭが、情報技術（ＩＴ）ログ（例えば、Ｎｅｔｆｌｏｗ、Ｓｙｓｌｏｇ、Ｖｆｌｏｗ、ＪＦｌｏｗ、ＳＦｌｏｗ、ＳＮＭＰトラップ、ＬＤＡＰデータ）以外のデータに基づき、悪意のある攻撃を、望ましくないイベントの可能性の高い原因として特定できるようにすることによって、残存リスクに関連する望ましくないイベントの発生が検出および判断されるとよい。このデータは、非従来型であり通常は電力グリッドのセキュリティ制御に関連して分析されない何らかのＩＴデータを含むとよい。例えば、これは、ＰＭＵからのフェーザー測定値（ｐｈａｓｏｒ ｍｅａｓｕｒｅｍｅｎｔｓ）などのグリッドアナログ測定値（ｇｒｉｄ ａｎａｌｏｇ ｍｅａｓｕｒｅｍｅｎｔｓ）、グローバルポジショニングシステム（ＧＰＳ）座標、高価値ターゲットのアドレスもしくは地理的位置、または車両事故レポートを含んでもよい。

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

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

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

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

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

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

図面は、（１）ＩＮＤＥ ＣＯＲＥ１２０、（２）ＩＮＤＥ ＳＵＢＳＴＡＴＩＯＮ１８０および（３）ＩＮＤＥ ＤＥＶＩＣＥ１８８など、全体的なアーキテクチャ内の種々の構成要素を示す。全体的なアーキテクチャ内で構成要素をこのように分割しているのは、説明のためである。構成要素のこの他の分割が使用されてもよい。ＩＮＤＥアーキテクチャは、グリッドインテリジェンスに対する分散型および集中型どちらの手法をサポートするためにも使用されてよく、大型実装の規模に対応するメカニズムを提供するために使用されてもよい。イベント関係データの分散型分析および選別が、例えば電気計器などのグリッドのエッジに移されることは、グリッドベースの構造が、必要な処理タスクを実行するためのコンピューティング能力をグリッド内の当該ポイントに備える限り、可能である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一実施形態では、ＩＮＤＥ ｃｏｒｅ１２０に含まれるＳＩＥＭ１６２は、残存リスクに関連する望ましくないイベントの発生を検出および判断し、当該の発生が、悪意のある攻撃の結果である可能性が高いかどうかを判断するために、ＣＥＰ処理バス１４７とともに使用されるとよい。図２０を参照する。様々なタイプのデータ２０００が、ＣＥＰバス１４７によって受信され得る。以下の表２は、データ２０００として使用され得る情報のタイプの例の包括的でないリストを提供する。このデータは、図１のＩＮＤＥシステム内の電子ソース２００１から生じるとよい。

表２：データタイプ

一実施形態では、データ２０００は、非ＩＴログデータまたは動的、環境特有、傾向データと見なされるとよい（簡潔にするために本願明細書ではまとめて「非ＩＴデータ」と呼ばれる）。したがって、非ＩＴデータ２０００は、次に限定はされないが、表２に示されているようにフェーザー測定値、接続性状態および他の地域における供給停止などの非従来型のＩＴ情報、表２に示されているように特定の位置に関するイベントデータ、過去の傾向または通常の挙動を示すことができる過去データ、ならびに地理的位置データ（ペンタゴン、連邦準備銀行、ホワイトハウス、陸軍基地、外国大使館などの有名または高価値ターゲットなど、特定の位置に関係するデータなど）を含むとよい。データ２０００は、ＩＮＤＥ内のセンサーおよび検出器などの様々な電子ソース２００１、ネットワークベースのデータ、インターネットベースのデータ、またはその他のタイプの適切なデータを通して受信されるとよい。非ＩＴデータの電子ソース２００１の包括的でないリストは、ウェブクローリングデバイス、検索エンジン対応コンピューティングデバイス、ウェブアクセスデバイス、ＧＰＳデバイス、ソーシャルメディアスレッド監視デバイス、温度計および緊急対応通報器（ｅｍｅｒｇｅｎｃｙ ｒｅｓｐｏｎｓｅ ｃｏｍｍｕｎｉｃａｔｏｒ）を含み得る。これらの電子ソース２００１は、ＣＥＰバス１４７と結合されているとよい。本願明細書において、「と結合されている」という表現は、直接接続されていること、または１つ以上の中間コンポーネントを介して間接的に接続されていることを意味するものと定義される。そのような中間コンポーネントは、ハードウェアベースおよびソフトウェアベース両方のコンポーネントを含み得る。

電子ソース２００１によって、またはそれに関連していくつかのツールが使用できるものと理解されるとよく、次に限定はされないが、これには、位置に基づくディスカッション、ならびにユーザの位置を確認し、例えば自然災害またはテロ行為を含む望ましくないイベントの発生の可能性を示し得る情報を求めてツイート、フェイスブックの投稿、またはその他のソーシャルメディアストリームを探し回るソーシャルメディア対応デバイスが含まれる。ＲＭＳフィードも監視されてもよい。位置の確認は、ユーザによる宣言、ユーザの位置を投稿または共有するためにユーザから許可を獲得する（例えば、フェイスブックアプリケーションのＰｌａｃｅｓ（登録商標）を介して、またはモバイルデバイスの位置にアクセスすることをユーザが認める別のアプリケーションを介して）モバイル電話またはコンピューティングデバイスアプリケーション、許可されている場合は三角測量を含み得る。ＩＰアドレス指定または経路探索も、ユーザ位置を判断するために実行され得る。ツールはさらに、インターネットのウェブページから情報を集めるウェブクローラを含む、ウェブ検索用ツールを含み得る。これら（またはその他多数）の情報のソースから取得される位置がＧＰＳベースであるか否かに関わらず、システムは、位置をＧＰＳ位置に変換するとよく、そのようなＧＰＳ位置と、インテリジェントユーティリティグリッドシステム上またはその近くの対応する位置とを相関させようとするとよい。そのような相関を用いて、本願明細書に開示されるシステムは、望ましくないイベントを、悪意があるか否か（例えば、セキュリティリスクであるかエンジニアリングリスクであるか）特徴評価することができるとよい。

ＣＥＰバス１４７によってデータ２０００が受信されると、データ２０００は、フィルタモジュール２００２によって前処理されるとよい。フィルタモジュール２００２は、データ２０００を前処理して、データ２０００に含まれているデータのうち、関連性のあるデータを判断することを担当するとよい。例えば、ＣＥＰバス１４７は、他の地域／国の電力供給停止情報およびツイッタートレンド統計を受信してもよい。続いて、フィルタリング（または前処理）されたデータ２００３は、ルールエンジンモジュール２００４によって受信されるとよい。ルールエンジンモジュール２００４は、様々な所定のルールまたは基準を含むとよく、それに基づいて、前処理されたデータを評価して、前処理されたデータが、残存リスクに関連する望ましくないイベントの１つ以上の発生を表すかどうかを判断する。これらのルールは、悪意のあるアクティビティにより望ましくないイベントが発生していることまたは発生するかもしれないことを示し得る、ＩＮＤＥに存在する条件を特定するために使用されるとよい。例えば、特定の位置における電力供給停止は、ＩＮＤＥに対する悪意のある攻撃が発生していたこと、または電力供給停止が、悪天候条件もしくは車両事故など、悪意のない原因によるものであることを示し得るであろう。ルールエンジンモジュール２００４は、供給停止が発生したことを示す情報を、集中制御センターから受信してもよい。あるいは、センサー出力、計器データまたはその他適切な検出方法によって、供給停止またはその他の望ましくないイベントの判断が下されてもよい。

一実施形態では、ルールエンジンモジュール２００４は、データ２０００によって伝えられる特定のデバイスの状態または条件（例えば計器の停止）を受信するとよい。様々な条件の状態の判断により、ルールエンジンモジュール２００４は、判断された様々な状態に所定のルールを適用して、望ましくないイベントの発生に悪意のある原因が関与している可能性が高いかどうかを判断するとよい。ルールエンジンモジュール２００４は、望ましくないイベントの発生が悪意のあるアクティビティによるものである見込みを伝えるために、確率レベル（ｐｒｏｂａｂｉｌｉｔｙ ｌｅｖｅｌ）を生成するとよい。ルールエンジンモジュール１０４は、ルールエンジンによって下された判断に応じて、特定の定性的な確率レベル「高」、「中」または「低」を有するリスク確率を生成するとよい。例えば、ルールエンジンモジュール１０４は、データ２０００内で受信された情報に基づく供給停止位置および天候条件に注目しながら、所定のルールを使用するとよい。別の例では、確率レベルは、より少ない、またはさらなる定性的レベル、百分率またはその他の適切な表現を使用して表現されればよい。ルールエンジンモジュール２００４は、供給停止が特定の位置（例えば郵便番号１２３４５）に存在し、郵便番号１２３４５に竜巻が存在することを現在の天候情報が示せば、当該の供給停止が悪意によるものである確率は低く、そうではなく荒天などの他の原因による可能性が高いと判断するとよい。そのような場合には、ルールエンジンモジュール２００４は、当該の発生が悪意のあるものである確率は、所定のレベルによれば「低」であると判断してもよい。各レベルが判断される閾値は、温度、位置、近くの交通事故、近くの火災、近くの発砲のレポート、ドル、いくつかのツイッター統計または任意の種類のソーシャルネットワーキング投稿または通信に関係する統計、ＰＭＵ値、最近の嵐、国土安全保障脅威レベル、国防総省脅威レベル、国家脅威レベル、日時および同種のものなど、様々な基準に基づき得る。

表３は、ルールエンジンモジュールによって実装されるルールが、ＩＮＤＥシステムに対する悪意のある攻撃が発生していると考えられる確率を示すためにどのように使用され得るかを示す、包括的でない例のリストを示す、他のいくつかの例を提供する。

表３：例示のルール

特定の望ましくないイベントが悪意を持って引き起こされていることの確率レベルが判断されると、ルールエンジンモジュール２００４は、望ましくないイベントを、過去相関モジュール２００６と相互参照するとよい。過去相関モジュール２００６は、データ２０００を参照して、そのような任意の条件が、以前に悪意のある攻撃の発生を示したことがあるか、またはそのような形で誤報を示したことがあるかを判断するとよい。過去相関モジュール２００６は、例えば関連性のある過去データを獲得するために、イベントログ１３５、過去データ１３６、および運用データ１３７（図１参照）など、様々なソースから過去データを取得するとよい。例えば、供給停止が特定の領域（例えば郵便番号１２３４５）に存在し、郵便番号１２３４５に竜巻が存在することを現在の天候情報が示す、上記で与えられたシナリオでは、過去相関モジュール２００６は、その領域では竜巻が記録されたことがないこと、またはその領域は一般に竜巻発生で知られていることを示す、郵便番号１２３４５に関する過去情報を取得するとよい。そのような過去情報が取得された場合、ルールエンジンモジュール１０４は、竜巻を示す状態の発生は考え難いものである可能性が高いと判断してもよく、悪意のあるアクティビティの確率が「高」であると判断することになる。一方、過去情報が、竜巻または竜巻をもたらす条件が過去から存在していたことを示すと、ルールエンジンモジュール２００４によって、以前の「低」確率の指示が保たれることになる。

悪意のある攻撃が発生している可能性または発生した可能性が高いと判断されると、その指示が、ルールエンジンモジュール２００４によって、図２０に表されたＳＩＥＭ１６２に、残存リスクイベントメッセージ２００８としてＣＰＥバス１４７を介して提供されてもよい。残存リスクイベントメッセージ２００８は、供給停止などの分析された条件と、その条件の悪意のある原因の確率レベルの判断とを含むとよく、その判断のために非ＩＴデータに依存するとよい。ＳＩＥＭ１６２はさらに、ルータ、スイッチ、ファイアウォール、侵入検出システムまたはウイルス保護などのＩＴハードウェアまたはソフトウェアから情報技術（ＩＴ）イベント（またはアクティビティ）２０１０を受信するとよい。ＩＴイベント２０１０は、スイッチログに含まれるものなど、ＩＮＤＥのＩＴインフラストラクチャに関する様々な情報を提供するとよい。ＩＴイベント２０１０は、例えばデバイスログ、ＩＤＳ／ＩＰＳアラート、ＷＩＤＳ／ＷＩＰＳアラート、アンチウイルスアラートおよびデバイス構成などの情報を含むとよい。こうした一般的なタイプのＩＴイベントの範囲に入らない任意のデータまたは情報は、その用語が本願明細書で言及されるとき、非ＩＴデータと見なされる。残存リスクイベントメッセージ２００８およびＩＴイベント２０１０を受信すると、ＳＩＥＭ１６２は、悪意のあるアクティビティによって引き起こされたリスクのタイプを示すリスク特徴評価を判断するとよい。リスク特徴評価が判断されると、ＳＩＥＭ１６２は、システム管理者または望ましくないイベントの任意の発生に対応することを担当する他の個人／エンティティに提供されるとよい、リスク特徴評価メッセージ２０１２を生成するとよい。リスク特徴評価メッセージ２０１２は、特定のイベントの悪意の確率レベルを示すのみではなく、セキュリティ、エンジニアリング、通信などのリスクがある１つまたは複数の領域も特定するとよい。一例では、これは、意図的でない（または予期しない）ハザードまたは悪意のある攻撃のいずれかの結果としてリスクが特徴評価されることによって実行されてもよい。残存リスクと、ＩＴ／ネットワーク情報との相関は、リスクのある領域の指摘を促進する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図２１は、電気ユーティリティシステムなどのユーティリティシステム用に構成された別の例示のスマートグリッドシステム２１００を示すブロック図である。一実施形態では、スマートグリッドシステム２１００は、電力、水道、天然ガスなどのユーティリティ使用に関するデータを測定および伝送するよう構成されているとよい複数の計器２１０２を含むとよい。グリッド２１００は、ネットワーク２１０８にそれぞれ接続されたユーザステーション２１０４および管理者ステーション２１０６を含むとよい。ユーザステーション２１０４は、プロセッサおよびメモリを有するコンピュータを含み、データを取得するため、動作を制御するため（許可を受けて）、またはその他任意の情報もしくは制御アクティビティにおいてグリッド２１００を使用するために、ユーザがグリッド２１００と相互作用することを可能にするとよい。各管理者ステーション２１０６は、プロセッサおよびメモリを含むとよく、グリッド２１００全体にわたり情報のフローを管理および保護するためにＩＴの職務のグリッド管理者によって使用されるとよい。

以下の表６は、スマートグリッド２１００の様々な機能コンポーネントを説明する。

表６：代わりのスマートグリッド構成コンポーネント

図１に関して説明したように、ＣＥＰコンソール２１９０は、ＣＥＰ処理バス１４７と同様に動作するとよい。一例では、ＣＥＰコンソール２１９０は、ＳＩＥＭ２１９４とともに動作して、ＳＩＥＭ１９４に提供されて残存特徴評価メッセージ２０１２の生成を可能にするとよい残存リスクイベントメッセージ２０１０を生成するよう構成されているとよい。

図２２は、図１に示されたものなどのスマートグリッドの運用フロー図である。複合イベント処理バス１４７は、非従来型のセキュリティデータを含むとよい非ＩＴデータ２０００を受信するとよい（２２００）。受信されたデータ２０００は、データフィルタモジュール２００２によってフィルタリングまたは前処理されるとよい（２２０２）。前処理は、複数のリスク関係イベントのうちの１つに対する関連性の所定のレベルに満たない、ＣＥＰバス１４７内の非ＩＴデータを、無視することを含むとよい。ルールエンジンモジュール２００４は、フィルタリングされたデータ２００３にルールの特定のセットを適用して、悪意のあるアクティビティによってイベントが引き起こされている確率レベルを判断するとよい（２２０４）。一実施形態において、ルールエンジン２００４は、過去相関モジュール２００６にアクセスして、当該のアクティビティが悪意のあるアクティビティ以外の原因による可能性が低いかどうかを検証するとよい（２２０６）。過去相関モジュール２００６からの過去データに基づき、ルールエンジン２００４は、残存リスクイベントメッセージ２００８を生成して、それをＳＩＥＭ１６２に提供するとよい（２２０８）。ＳＩＥＭ１６２は、ＩＴイベントデータ２０１０も受信するとよい（２２１０）。ＳＩＥＭ１６２は、残存リスクイベントメッセージ２００８およびＩＴイベントデータ２０１０に基づいて、リスク特徴評価メッセージ２０１２を生成するとよく（２２１２）、これは、ＩＮＤＥまたはそのほか特定の構成を実装するスマートグリッドの、ネットワーク動作を監視するものによって、さらに検査されてもよい。

この技術革新の様々な実施形態について記載してきたが、当業者には当然のことながら、さらに多くの実施形態および実装が、この技術革新の範囲内で可能である。したがって、この技術革新は、添付の特許請求の範囲およびその等価物に照らして以外には、制限されないものとする。

Claims (24)

1. インテリジェントユーティリティグリッドシステムにおける悪意のあるアクティビティを特徴評価する方法であって、前記方法は、少なくとも１つのプロセッサおよび少なくとも１つのメモリを有するコンピュータによって実行可能であり、
   前記少なくとも１つのプロセッサによって、情報技術（ＩＴ）関係アクティビティを含むＩＴデータを前記インテリジェントグリッドシステムから受信するステップと、
   前記少なくとも１つのプロセッサによって、特定の位置に関するイベントデータを含む非ＩＴデータを複数の電子ソースから受信するステップと、
   前記少なくとも１つのプロセッサによって、前記非ＩＴデータを前処理するステップであって、複数のリスク関係イベントのうちの１つに対する関連性の所定のレベルに満たない前記非ＩＴデータを無視することを含む、前記ステップと、
   望ましくないイベントを、前記ＩＴ関係アクティビティを参照して関連付け、
   前記望ましくないイベントが悪意のあるアクティビティを示す確率を判断するために、
   前記少なくとも１つのプロセッサによって、複数のルールを、前記前処理された非ＩＴデータに適用するステップと、
   前記少なくとも１つのプロセッサによって、前記確率および前記ＩＴ関係アクティビティに基づき、前記望ましくないイベントにリスク特徴評価を適用するステップと、
   を含む方法。
2. 前記望ましくないイベントは、まだ発生していない、請求項１に記載の方法。
3. 前記リスク特徴評価は、エンジニアリングリスクまたはセキュリティリスクを含む、請求項１に記載の方法。
4. 前記複数のルールを適用するステップは、所定の基準と、複数の異なる確率レベルのうちの１つが生成される前記非ＩＴデータとを比較するステップを含む、請求項１に記載の方法。
5. 前記確率レベルは、脅威と、前記ＩＴ関係または非ＩＴデータにおいて発見され前記脅威による利用が可能な対応する脆弱性との共存に基づき生成される、請求項４に記載の方法。
6. 前記確率レベルは、（１）悪意のある特定の攻撃の発生の確率と、前記悪意のある特定の攻撃による利用が可能な脆弱性の存在の確率との積、および（２）予期しないハザードの発生の確率と、前記予期しないハザードに関連する脆弱性の存在の確率との積の和として生成される、請求項４に記載の方法。
7. 前記非ＩＴデータは、イベントログと、前記インテリジェントユーティリティグリッドシステムの対応する部分に関連する地理上の位置と、運用データとから取得される過去データをさらに含み、前記複数のルールを適用するステップは、前記ＩＴ関係アクティビティと、前記過去データとを比較するステップを含む、請求項１に記載の方法。
8. 前記ＩＴ関係アクティビティの少なくとも一部は、スマート計器からのイベントメッセージを含み、前記リスク特徴評価を適用するステップは、前記インテリジェントユーティリティグリッドシステム内の、前記悪意のあるアクティビティが発生している領域を判断するステップを含む、請求項１に記載の方法。
9. 前記非ＩＴデータは、フェーザー測定値を含むグリッドアナログ測定値と、高価値ターゲットおよび対応する地理的位置のリストとをさらに含む、請求項１に記載の方法。
10. 非ＩＴデータの前記電子ソースは、以下の入力：天候フィード、障害レコーダフィード、デジタル故障レコーダフィード、調波レコーダフィード、電力品質監視フィード、デバイスステータス、接続性状態、制御限界、ＵＳ ＣＥＲＴフィード、ＧＰＳフィード、電力管理ユニット（ＰＭＵ）フィード、センサーフィード、負荷予測および再生可能発電予測のうちの１つまたは組み合わせを含む、請求項１に記載の方法。
11. インテリジェントユーティリティグリッドシステムにおける悪意のあるアクティビティを特徴評価するシステムであって、
    複数のルールを含むデータベースを記憶するシステム記憶装置と、
    情報技術（ＩＴ）関係アクティビティを含むＩＴデータを前記インテリジェントグリッドシステムから収集して前記システム記憶装置に記憶するよう動作可能なコレクタと、
    特定の位置に関するイベントデータを含む非ＩＴデータを、複数の電子ソースから受信するよう動作可能な複合イベント処理（ＣＥＰ）バスであって、複数のリスク関係イベントのうちの１つに対する関連性の所定のレベルに満たない前記非ＩＴデータを無視するようさらに動作可能な、前記ＣＥＰバスと、
    望ましくないイベントを、前記ＩＴ関係アクティビティを参照して関連付け、前記望ましくないイベントが悪意のあるアクティビティを示す確率を判断するために、関連性のある前記非ＩＴデータに前記複数のルールを適用するよう動作可能なプロセッサと、
    を含むシステムであって、
    前記プロセッサはさらに、前記確率および前記ＩＴ関係アクティビティに基づき、前記望ましくないイベントにリスク特徴評価を適用する、
    システム。
12. 非ＩＴデータの以下の電子ソース：ウェブクローリングデバイス、検索エンジン対応コンピューティングデバイス、ウェブアクセスデバイス、ＧＰＳデバイス、ソーシャルメディアスレッド監視デバイス、温度計および緊急対応通報器のうちの１つまたは組み合わせと結合された前記ＣＥＰバスをさらに含む、請求項１１に記載のシステム。
13. 前記望ましくないイベントは、まだ発生しておらず、前記リスク特徴評価は、エンジニアリングリスクまたはセキュリティリスクを含む、請求項１１に記載のシステム。
14. 前記複数のルールを適用するために、前記プロセッサは、所定の基準と、複数の異なる確率レベルのうちの１つが生成される前記非ＩＴデータとを比較する、請求項１１に記載のシステム。
15. 前記確率レベルは、脅威と、前記ＩＴ関係または非ＩＴデータにおいて発見され前記脅威による利用が可能な対応する脆弱性との共存に基づき生成される、請求項１４に記載のシステム。
16. 前記非ＩＴデータは、イベントログと、前記インテリジェントユーティリティグリッドシステムの対応する部分に関連する地理上の位置と、運用データとからの取得からの過去データをさらに含み、前記プロセッサは、前記ＩＴ関係アクティビティと、前記過去データとを比較することによって、前記複数のルールを適用する、請求項１１に記載のシステム。
17. 前記ＩＴ関係アクティビティの少なくとも一部は、スマート計器からのイベントメッセージを含み、前記プロセッサは、前記インテリジェントユーティリティグリッドシステム内の、前記悪意のあるアクティビティが発生している領域を判断することによって、前記リスク特徴評価を適用する、請求項１１に記載のシステム。
18. 前記非ＩＴデータは、フェーザー測定値を含むグリッドアナログ測定値と、高価値ターゲットおよび対応する地理的位置のリストとをさらに含む、請求項１１に記載のシステム。
19. インテリジェントユーティリティグリッドシステムにおける悪意のあるアクティビティを特徴評価するための命令のセットを含むコンピュータ可読記憶媒体であって、前記命令のセットは、プロセッサおよびメモリを有するコンピュータによって実行可能であり、前記コンピュータ可読媒体は、
    情報技術（ＩＴ）関係アクティビティを含むＩＴデータを前記インテリジェントグリッドシステムから受信する命令と、
    特定の位置に関するイベントデータを含む非ＩＴデータを複数の電子ソースから受信する命令と、
    前記非ＩＴデータを前処理する命令であって、複数のリスク関係イベントのうちの１つに対する関連性の所定のレベルに満たない前記非ＩＴデータを無視することを含む、前記命令と、
    望ましくないイベントを、前記ＩＴ関係アクティビティを参照して関連付け、
    前記望ましくないイベントが悪意のあるアクティビティを示す確率を判断するために、
    複数のルールを、前記前処理された非ＩＴデータに適用する命令と、
    前記確率および前記ＩＴ関係アクティビティに基づき、前記望ましくないイベントにリスク特徴評価を適用する命令と、
    を含むコンピュータ可読記憶媒体。
20. 前記ＩＴ関係アクティビティの少なくとも一部は、スマート計器からのイベントメッセージを含み、前記リスク特徴評価を適用するために、前記命令は、前記インテリジェントユーティリティグリッドシステム内の、前記悪意のあるアクティビティが発生している領域を判断する、請求項１９に記載のコンピュータ可読記憶媒体。
21. 前記非ＩＴデータは、イベントログと、前記インテリジェントユーティリティグリッドシステムの対応する部分に関連する地理上の位置と、運用データとから取得される過去データをさらに含み、前記複数のルールを適用するために、前記命令はさらに、前記ＩＴ関係アクティビティと、前記過去データとを比較する、請求項１９に記載のコンピュータ可読記憶媒体。
22. 前記リスク特徴評価は、エンジニアリングリスクまたはセキュリティリスクを含む、請求項１９に記載のコンピュータ可読記憶媒体。
23. 前記複数のルールを適用するために、前記命令はさらに、所定の基準と、複数の異なる確率レベルのうちの１つが生成される前記非ＩＴデータとを比較し、前記基準は、温度、ドル、ソーシャルネットワーキング統計のうちの１つまたは組み合わせを含む、請求項１９に記載のコンピュータ可読記憶媒体。
24. 前記確率レベルは、脅威と、前記ＩＴ関係または非ＩＴデータにおいて発見され前記脅威による利用が可能な対応する脆弱性との共存に基づき生成される、請求項２３に記載のコンピュータ可読記憶媒体。

Images