"インテリジェントユーティリティグリッドシステムにおける悪意のあるアクティビティを特徴評価する方法であって、前記方法は、少なくとも1つのプロセッサおよび少なくとも1つのメモリを有するコンピュータによって実行可能であり、前記少なくとも1つのプロセッサによって、情報技術IT関係アクティビティを含むITデータを前記インテリジェントグリッドシステムから受信するステップと、前記少なくとも1つのプロセッサによって、特定の位置に関するイベントデータを含む非ITデータを複数の電子ソースから受信するステップと、前記少なくとも1つのプロセッサによって、前記非ITデータを前処理するステップであって、複数のリスク関係イベントのうちの1つに対する関連性の所定のレベルに満たない前記非ITデータを無視することを含む、前記ステップと、望ましくないイベントを、前記IT関係アクティビティを参照して関連付け、前記望ましくないイベントが悪意のあるアクティビティを示す確率を判断するために、前記少なくとも1つのプロセッサによって、複数のルールを、前記前処理された非ITデータに適用するステップと、前記少なくとも1つのプロセッサによって、前記確率および前記IT関係アクティビティに基づき、前記望ましくないイベントにリスク特徴評価を適用するステップと、を含む方法。前記望ましくないイベントは、まだ発生していない、請求項1に記載の方法。前記リスク特徴評価は、エンジニアリングリスクまたはセキュリティリスクを含む、請求項1に記載の方法。前記複数のルールを適用するステップは、所定の基準と、複数の異なる確率レベルのうちの1つが生成される前記非ITデータとを比較するステップを含む、請求項1に記載の方法。前記確率レベルは、脅威と、前記IT関係または非ITデータにおいて発見され前記脅威による利用が可能な対応する脆弱性との共存に基づき生成される、請求項4に記載の方法。前記確率レベルは、1悪意のある特定の攻撃の発生の確率と、前記悪意のある特定の攻撃による利用が可能な脆弱性の存在の確率との積、および2予期しないハザードの発生の確率と、前記予期しないハザードに関連する脆弱性の存在の確率との積の和として生成される、請求項4に記載の方法。前記非ITデータは、イベントログと、前記インテリジェントユーティリティグリッドシステムの対応する部分に関連する地理上の位置と、運用データとから取得される過去データをさらに含み、前記複数のルールを適用するステップは、前記IT関係アクティビティと、前記過去データとを比較するステップを含む、請求項1に記載の方法。前記IT関係アクティビティの少なくとも一部は、スマート計器からのイベントメッセージを含み、前記リスク特徴評価を適用するステップは、前記インテリジェントユーティリティグリッドシステム内の、前記悪意のあるアクティビティが発生している領域を判断するステップを含む、請求項1に記載の方法。前記非ITデータは、フェーザー測定値を含むグリッドアナログ測定値と、高価値ターゲットおよび対応する地理的位置のリストとをさらに含む、請求項1に記載の方法。非ITデータの前記電子ソースは、以下の入力:天候フィード、障害レコーダフィード、デジタル故障レコーダフィード、調波レコーダフィード、電力品質監視フィード、デバイスステータス、接続性状態、制御限界、USCERTフィード、GPSフィード、電力管理ユニットPMUフィード、センサーフィード、負荷予測および再生可能発電予測のうちの1つまたは組み合わせを含む、請求項1に記載の方法。インテリジェントユーティリティグリッドシステムにおける悪意のあるアクティビティを特徴評価するシステムであって、複数のルールを含むデータベースを記憶するシステム記憶装置と、情報技術IT関係アクティビティを含むITデータを前記インテリジェントグリッドシステムから収集して前記システム記憶装置に記憶するよう動作可能なコレクタと、特定の位置に関するイベントデータを含む非ITデータを、複数の電子ソースから受信するよう動作可能な複合イベント処理CEPバスであって、複数のリスク関係イベントのうちの1つに対する関連性の所定のレベルに満たない前記非ITデータを無視するようさらに動作可能な、前記CEPバスと、望ましくないイベントを、前記IT関係アクティビティを参照して関連付け、前記望ましくないイベントが悪意のあるアクティビティを示す確率を判断するために、関連性のある前記非ITデータに前記複数のルールを適用するよう動作可能なプロセッサと、を含むシステムであって、前記プロセッサはさらに、前記確率および前記IT関係アクティビティに基づき、前記望ましくないイベントにリスク特徴評価を適用する、システム。非ITデータの以下の電子ソース:ウェブクローリングデバイス、検索エンジン対応コンピューティングデバイス、ウェブアクセスデバイス、GPSデバイス、ソーシャルメディアスレッド監視デバイス、温度計および緊急対応通報器のうちの1つまたは組み合わせと結合された前記CEPバスをさらに含む、請求項11に記載のシステム。前記望ましくないイベントは、まだ発生しておらず、前記リスク特徴評価は、エンジニアリングリスクまたはセキュリティリスクを含む、請求項11に記載のシステム。前記複数のルールを適用するために、前記プロセッサは、所定の基準と、複数の異なる確率レベルのうちの1つが生成される前記非ITデータとを比較する、請求項11に記載のシステム。前記確率レベルは、脅威と、前記IT関係または非ITデータにおいて発見され前記脅威による利用が可能な対応する脆弱性との共存に基づき生成される、請求項14に記載のシステム。前記非ITデータは、イベントログと、前記インテリジェントユーティリティグリッドシステムの対応する部分に関連する地理上の位置と、運用データとからの取得からの過去データをさらに含み、前記プロセッサは、前記IT関係アクティビティと、前記過去データとを比較することによって、前記複数のルールを適用する、請求項11に記載のシステム。前記IT関係アクティビティの少なくとも一部は、スマート計器からのイベントメッセージを含み、前記プロセッサは、前記インテリジェントユーティリティグリッドシステム内の、前記悪意のあるアクティビティが発生している領域を判断することによって、前記リスク特徴評価を適用する、請求項11に記載のシステム。前記非ITデータは、フェーザー測定値を含むグリッドアナログ測定値と、高価値ターゲットおよび対応する地理的位置のリストとをさらに含む、請求項11に記載のシステム。インテリジェントユーティリティグリッドシステムにおける悪意のあるアクティビティを特徴評価するための命令のセットを含むコンピュータ可読記憶媒体であって、前記命令のセットは、プロセッサおよびメモリを有するコンピュータによって実行可能であり、前記コンピュータ可読媒体は、情報技術IT関係アクティビティを含むITデータを前記インテリジェントグリッドシステムから受信する命令と、特定の位置に関するイベントデータを含む非ITデータを複数の電子ソースから受信する命令と、前記非ITデータを前処理する命令であって、複数のリスク関係イベントのうちの1つに対する関連性の所定のレベルに満たない前記非ITデータを無視することを含む、前記命令と、望ましくないイベントを、前記IT関係アクティビティを参照して関連付け、前記望ましくないイベントが悪意のあるアクティビティを示す確率を判断するために、複数のルールを、前記前処理された非ITデータに適用する命令と、前記確率および前記IT関係アクティビティに基づき、前記望ましくないイベントにリスク特徴評価を適用する命令と、を含むコンピュータ可読記憶媒体。前記IT関係アクティビティの少なくとも一部は、スマート計器からのイベントメッセージを含み、前記リスク特徴評価を適用するために、前記命令は、前記インテリジェントユーティリティグリッドシステム内の、前記悪意のあるアクティビティが発生している領域を判断する、請求項19に記載のコンピュータ可読記憶媒体。前記非ITデータは、イベントログと、前記インテリジェントユーティリティグリッドシステムの対応する部分に関連する地理上の位置と、運用データとから取得される過去データをさらに含み、前記複数のルールを適用するために、前記命令はさらに、前記IT関係アクティビティと、前記過去データとを比較する、請求項19に記載のコンピュータ可読記憶媒体。前記リスク特徴評価は、エンジニアリングリスクまたはセキュリティリスクを含む、請求項19に記載のコンピュータ可読記憶媒体。前記複数のルールを適用するために、前記命令はさらに、所定の基準と、複数の異なる確率レベルのうちの1つが生成される前記非ITデータとを比較し、前記基準は、温度、ドル、ソーシャルネットワーキング統計のうちの1つまたは組み合わせを含む、請求項19に記載のコンピュータ可読記憶媒体。前記確率レベルは、脅威と、前記IT関係または非ITデータにおいて発見され前記脅威による利用が可能な対応する脆弱性との共存に基づき生成される、請求項23に記載のコンピュータ可読記憶媒体。本開示の一側面によれば、インテリジェントユーティリティグリッドシステムにおける悪意のあるアクティビティを特徴評価するcharacterize方法は、情報技術IT関係アクティビティを含むITデータをインテリジェントグリッドシステムから受信するステップを含むとよい。本方法は、特定の位置に関するlocation-specificイベントデータを含む非ITデータを複数の電子ソースelectronicsourceから受信するステップをさらに含むとよい。後でさらに詳しく説明するように、非ITデータは、電力グリッドによって従来使用されていない情報技術関係情報またはデータ、ならびに過去データおよび高価値ターゲットhighvaluetargetのアドレスまたは位置などの情報を含む。本方法は、非ITデータを前処理するステップであって、複数のリスク関係イベントのうちの1つに対する関連性の所定のレベルに満たない非ITデータを無視することを含む、該ステップをさらに含むとよい。本方法は、望ましくないイベントを、IT関係アクティビティを参照して関連付け、望ましくないイベントが悪意のあるアクティビティを示す確率を判断するために、複数のルールを、前処理された非ITデータに適用するステップをさらに含むとよい。イベントは、既に発生していても、まだ発生していなくてもよい。本方法は、確率およびIT関係アクティビティに基づき、望ましくないイベントにリスク特徴評価riskcharacterizationを適用するステップをさらに含むとよい。本開示の別の側面によれば、インテリジェントユーティリティグリッドにおける悪意のあるアクティビティを特徴評価するシステムは、複数のルールを含むデータベースを記憶するシステム記憶装置を含むとよい。コレクタが、情報技術IT関係アクティビティを含むITデータをインテリジェントグリッドシステムから収集してシステム記憶装置に記憶するよう動作可能であるとよい。複合イベント処理CEP:complexeventprocessingバスが、特定の位置に関するイベントデータを含む非ITデータを複数の電子ソースから受信するよう動作可能であるとよく、CEPバスは、複数のリスク関係イベントのうちの1つに対する関連性の所定のレベルに満たない非ITデータを無視するようさらに動作可能である。プロセッサが、望ましくないイベントを、IT関係アクティビティを参照して関連付け、望ましくないイベントが悪意のあるアクティビティを示す確率を判断するために、関連性のある非ITデータに複数のルールを適用するよう動作可能であるとよい。プロセッサは、確率およびIT関係アクティビティに基づき、望ましくないイベントにリスク特徴評価を適用するようさらに動作可能であるとよい。リスク特徴評価は、例えば、保守チームが派遣されるとよいエンジニアリングリスクengineeringriskを含んでもよく、または法執行機関が通報を受けるセキュリティリスクであってもよい。以下の図面および詳細な説明を検討すると、当業者には、他のシステム、方法、特徴および利点が明らかであるか、または明らかとなるであろう。そのようなさらなるシステム、方法、特徴および利点はすべて、本記載の中に含まれ、本発明の範囲内にあり、添付の特許請求の範囲により保護されるものとする。概要として、以下に記載される好適な実施形態は、電力グリッドを管理する方法およびシステムに関する。以下でさらに詳しく説明するように、特定の側面は電力グリッド自体に関する送電および/または配電におけるハードウェアおよびソフトウェアを含む。さらに、特定の側面は電力グリッドの中央管理の機能的能力に関する。こうした機能的能力は、動作およびアプリケーションの2つのカテゴリにグループ化され得る。動作サービスは、ユーティリティが、スマートグリッドインフラストラクチャ例えばアプリケーション、ネットワーク、サーバ、センサーなどを監視および管理できるようにする。本願明細書で開示される方法およびシステムは、参照によって本願明細書にその内容全体を引用したものとする次の特許出願に関係する:米国特許出願第12/378,102号米国特許出願公開第2009/0281674A1号として公開されている、および米国特許出願第12/378,091号米国特許出願公開第2009/0281673A1号として公開されている。以下でさらに詳しく説明するように、アプリケーション能力は、グリッド自体の測定および制御に関するとよい。具体的には、アプリケーションサービスは、スマートグリッドに重要であると考えられる機能性を可能にするものであり、1データ収集プロセス、2データカテゴリ化および維持プロセス、ならびに3可観測性プロセスが含まれ得る。以下でさらに詳しく説明するように、こうしたプロセスを使用することで、グリッドを観測し、データを分析して、グリッドについての情報を得ることができるようになる。一実施形態では、ユーティリティシステムは、ユーティリティシステムのインテリジェンスに対する、望ましくない結果を引き起こす悪意のある攻撃を回避するための、インテリジェントセキュリティシステムを含むとよい。そのような悪意のある攻撃を回避するには、または少なくともそのような攻撃を迅速に検出するには、ユーティリティシステムは、望ましくないイベントを検出および特徴評価し、ひいてはそのようなイベントを有用な形でカテゴリ化できる必要がある。そのようなユーティリティシステムの1つは、電気スマートグリッドユーティリティシステムである。攻撃には、インターネットプロトコルIPおよび監視制御データ収集SCADAシステムに対する攻撃があり得、特定の目標があることもある。そのような目標には、グリッド上のワイヤレスノードの無線周波数RF妨害、鍵導出、不適当なエンティティからの匿名入力、物理的なハードウェア不正変更によってなど、1つ以上の弱点を利用してスマートグリッドの通常動作をバイパスすることが含まれ得る。こうした問題の多くには、SCADAセキュリティ制御、またはエンタープライズおよび運用セキュリティ制御のいずれかによって対処されるソリューションがある。残存リスクは、セキュリティ制御が適用された後の残りのリスクと見なされるとよい。スマートグリッドのサイバーセキュリティの課題に直面する場合、SCADA、エンタープライズIT、運用または物理的セキュリティ制御によって軽減される典型的なリスクの範囲を超えることもある、残存セキュリティリスクが残る。一実施形態では、インシデントイベントIは、望ましくないイベントの発生であるとよい。インシデントの確率PIは、インシデントの発生が、脅威の存在および脅威によって利用され得る脆弱性の存在に基づく可能性または見込みであるとよい。脅威イベントTは、悪意のある意図的な攻撃または予期しないハザードであるとよい。下記の式1は、悪意のある攻撃の発生の確率PA、および各攻撃に関する脆弱性の存在の積と、予期しないハザードの発生の確率PHプラス予期しないハザードそれぞれに関連する脆弱性の確率との和としての、インシデントの発生の確率に関する。式1は、例えば互いに独立した意図的な攻撃Aおよび予期しないハザードHなど、互いに独立したイベントによって生じるインシデントの確率である。式1PI=ΠiPAiΠjPHj式中、i、jは整数である。残存リスクRR:ResidualRiskは、悪意のある意図的な攻撃および予期しないハザードをセキュリティ制御が軽減しない、確率的な結果とされ得る。式2は、十分な保護の欠如制御ギャップにより意図的または意図的でないセキュリティインシデントが発生する残存リスクRR、すなわち独立した意図的な攻撃および予期しないハザードイベントの、防止、検出およびそれからの保護を、セキュリティ制御が行わないリスクである。式2RR=PIP制御ギャップ式1により、セキュリティインシデントの確率が、エンタープライズ、動作およびICSに関して得られるとよい。式4~6は、これらの式を示す。式3PIEnterpriseIT=ΠiPAi,EnterpriseITΠjPHjEnterpriseIT式4PIOperationIT=ΠiPAi,OperationITΠjPHj,OperationIT式5PISCADAIT=ΠiPAi,SCADAΠjPHj,SCADA式6RR=PIP制御ギャップ式7は、スマートグリッド上のインシデントの確率が、例えばエンタープライズ、運用、SCADAおよび残存など、別々の脅威イベントのソースの確率の和であることを示す。式7PISmartGrid=PIEnterprisePIOperationalPISCADAPIResidual式中、攻撃A、ハザードH、脆弱性Vおよび残存リスクRは、相互排他的である。式3~5の脆弱性は、従来の受動的なエンタープライズITセキュリティによって対処されることもあり、これは例えば、ヘッダまたはパケット検査を活用し、典型的には、CatalystスイッチドポートアナライザSPAN:SwitchedPortAnalyzerポートまたはミラーポート例えば、侵入検出システムIDS:IntrusionDetectionSystem、コンテンツフィルタ、アクティブシグネチャに基づく従来のITセキュリティ例えば、ファイアウォール、能動的および受動的なスマートグリッド運用ITセキュリティ例えば、強化された高度計測インフラストラクチャコンポーネント、IDSのスマートグリッド脅威定義ファイル、NERC-CIP準拠のための自動ポリシーマネージャならびにSCADAセキュリティを使用する。考慮される脆弱性の例には、以下が含まれ得る:ヘッダ情報パケットコンテンツSCADAの異常通信プロトコルソースターゲットIPアドレスソースターゲットTCPおよびUDPポート通信の開始の指示各種のトラフィックの量パケットフォーマットおよびコンテンツエンタープライズおよび運用の多層防御の階層的セキュリティ手法を、SCADAセキュリティに加えて実装すると、インシデントの確率がごくわずかになるかもしれない。結果として、式7は、以下のように式8に単純化され得る:式8PISmartGrid=PIResidualδI≪PISmartGridδIOperationalITδISCADAコンピュータ緊急対応チームCERT:ComputerEmergencyResponseTeamおよびその他のITセキュリティ監視組織は、制御システムに関する情報を収集するように設計されていないため、制御システムセキュリティは、その競争相手の制御システムセキュリティ監視データに関する組織的知識に依存しなければならない。セキュリティ侵害が公に知られることは、投資家の信頼および企業の評価に悪影響を与えると考えられるため、通常、このデータへのアクセスは共有されない。ホスト侵入検出システムHIDS:HostIntrusionDetectionSystemは、ホストにインストールされたソフトウェアエージェントを活用して、ホストの異常な挙動を監視する。残念ながら、その独自リアルタイムオペレーティングシステムOS:operatingsystemまたは組み込みOSが原因で、例えば電気的プロセスの測定、制御および監視を行うSCADAコンポーネントなど、すべてのスマートグリッドコンポーネントにHIDSをインストールすることはできない。したがって、残存リスクには、意図的でないイベントに関連する脆弱性に加えて、HIDSがもたらしたであろう可視性の欠如が含まれる。考慮されない脆弱性は、天災、容量の欠如、IDSおよびセキュリティ情報イベントマネージャSIEM:securityinformationandeventmanagerによって認識されない固有プロトコル例えばModbusTCP、DNP3、ODVAEthernet/IP、ICCP、偽陰性例えば、供給停止がセキュリティイベントと誤診されることがある、リモートノードRTURemoteTerminalUnit:リモート端末ユニットおよびPLCのアクセス制御、独自ノード上の完全性および異常チェック、独自リアルタイムOSまたは組み込みOSS、ならびに相互運用性によるフォレンジックの限界に関連する。一実施形態では、複合イベントプロセッサまたは処理CEPバスが、様々なソースからのデータをフィルタリング、処理および相関させ、エネルギーシステムの不具合または異常など、将来発生するかもしれない、または過去に起こったかもしれないイベントを抽出するとよい。残存リスクの確率を下げるために、CEPバスは、IDS、アンチウイルスまたはファイアウォールで認識されない異常を検出して除去するよう、電気ユーティリティルールなどのユーティリティルールにより調整されてもよい。システムへの入力は、グリッドの利用可能性、完全性および機密性に影響を及ぼすすべてのデータとするべきである。様々な電子ソースからの入力の例は、以下を含む:天候フィード障害レコーダデジタル故障レコーダオシログラフィ調波レコーダ電力品質監視デバイスステータス接続性状態制御限界USCERTフィード構成要素フィードGPSglobalpositioningsystem:グローバルポジショニングシステムRF干渉電力管理ユニットPMU:PowerManagementUnitセンサー負荷予測再生可能発電RenewableGeneration予測例えば、天候フィードは、使用中のサージによる供給停止および電圧低下を予想するために使用され得る例えば、空調ユニットの電力使用の増加につながる高い温度。さらに、CERTレポートおよびその他のエネルギー企業は、協働して、インシデントレポートデータベースを共有することができ、これは、誤用またはシステム侵害によって引き起こされる異常を特定するためにそれらのCEPバスに供給され得る。一実施形態では、SIEMをスマートグリッドシステムに実装して、CEPおよびSIEMが、情報技術ITログ例えば、Netflow、Syslog、Vflow、JFlow、SFlow、SNMPトラップ、LDAPデータ以外のデータに基づき、悪意のある攻撃を、望ましくないイベントの可能性の高い原因として特定できるようにすることによって、残存リスクに関連する望ましくないイベントの発生が検出および判断されるとよい。このデータは、非従来型であり通常は電力グリッドのセキュリティ制御に関連して分析されない何らかのITデータを含むとよい。例えば、これは、PMUからのフェーザー測定値phasormeasurementsなどのグリッドアナログ測定値gridanalogmeasurements、グローバルポジショニングシステムGPS座標、高価値ターゲットのアドレスもしくは地理的位置、または車両事故レポートを含んでもよい。INDE上位アーキテクチャの説明全体的アーキテクチャ図面を参照する。図面では、同じ参照数字は類似した構成要素を指し、図1はINDEの全体的なアーキテクチャの一例を示す。このアーキテクチャは、スマートグリッドデータのエンドツーエンド収集、搬送、記憶および管理を提供する参照モデルとしての機能を果たし得る。さらにこのアーキテクチャは、解析および解析管理、ならびに前述のもののユーティリティプロセスおよびシステムへの統合を提供し得る。したがって、このアーキテクチャはエンタープライズ規模のアーキテクチャと見なされるとよい。運用管理およびグリッド自体の各側面など、特定の構成要素については、下記でさらに詳しく説明する。図1に示されているアーキテクチャは、データおよび統合バスを最大4つまで含み得る:1高速センサーデータバス146運用および非運用データを含むとよい、2専用イベント処理バス147イベントデータを含むとよい、3動作サービスバス130スマートグリッドについての情報をユーティリティのバックオフィスアプリケーションに提供する役割を果たすとよいならびに4バックオフィスITシステム用のエンタープライズサービスバスエンタープライズIT115にサービス提供するエンタープライズ統合環境バス114として図1に示されている。個々のデータバスは、1つ以上の方法で実現され得る。例えば、高速センサーデータバス146およびイベント処理バス147など、データバスの2つ以上が、単一データバスの別々のセグメントであってもよい。具体的には、バスはセグメント化された構造またはプラットフォームを有してもよい。下記でさらに詳しく説明するように、データバスの別々のセグメント上にデータをルーティングするために、1つ以上のスイッチなどのハードウェアおよび/またはソフトウェアが使用され得る。別の例として、データバスの2つ以上は、データを別々のバス上で搬送するために必要なハードウェアに関して別々の物理的バスなど、別々のバス上にあってもよい。具体的には、バスはそれぞれ、互いに独立したケーブル配線を含んでもよい。さらに、別々のバスのうち、一部または全部が同じタイプであってもよい。例えば、バスの1つ以上が、非シールドより対線を介したEthernet登録商標およびWi-Fi登録商標などのローカルエリアネットワークLAN:localareanetworkを含んでもよい。下記でさらに詳しく説明するように、種々の物理的バスの中の1つのバス上へデータ上のデータをルーティングするために、ルータなどのハードウェアおよび/またはソフトウェアが使用され得る。さらに別の例として、バスの2つ以上が、単一バス構造の異なるセグメント上にあってもよく、1つ以上のバスが、別個の物理的バス上にあってもよい。具体的には、高速センサーデータバス146およびイベント処理バス147が、単一データバスの異なるセグメントであってもよく、エンタープライズ統合環境バス114が、物理的に別個のバス上にあってもよい。図1は、4つのバスを示すが、より少ない、または多い数のバスが、列挙された4タイプのデータを運ぶために使用され得る。例えば、後述するように、センサーデータおよびイベント処理データの伝達に、セグメント化されていない単一バスが使用されてもよいバスの総数は3になる。さらにシステムは、動作サービスバス130および/またはエンタープライズ統合環境バス114なしで動作することもできる。IT環境は、SOAServiceOrientedArchitecture:サービス指向アーキテクチャに準拠していてもよい。サービス指向アーキテクチャSOAは、サービスとしてパッケージ化されたビジネスプロセスのライフサイクル全体にわたる作成および使用に関する、コンピュータシステムアーキテクチャの様式である。SOAはさらに、種々のアプリケーションがデータを交換してビジネスプロセスに関与することを可能にするようITインフラストラクチャを定義し、供給する。ただし、SOAおよびエンタープライズサービスバスの使用は任意選択である。図面は、1INDECORE120、2INDESUBSTATION180および3INDEDEVICE188など、全体的なアーキテクチャ内の種々の構成要素を示す。全体的なアーキテクチャ内で構成要素をこのように分割しているのは、説明のためである。構成要素のこの他の分割が使用されてもよい。INDEアーキテクチャは、グリッドインテリジェンスに対する分散型および集中型どちらの手法をサポートするためにも使用されてよく、大型実装の規模に対応するメカニズムを提供するために使用されてもよい。イベント関係データの分散型分析および選別が、例えば電気計器などのグリッドのエッジに移されることは、グリッドベースの構造が、必要な処理タスクを実行するためのコンピューティング能力をグリッド内の当該ポイントに備える限り、可能である。INDE参照アーキテクチャは、実装され得る技術アーキテクチャの一例である。例えば、後述するように、INDE参照アーキテクチャは、ユーティリティソリューション毎に1つ、任意数の具体的技術アーキテクチャを開発するための開始点を提供するために使用される、メタアーキテクチャの例とすることもできる。したがって、特定のユーティリティ向けの具体的ソリューションは、INDE参照アーキテクチャ内の構成要素のうちの1つ、いくつかまたはすべてを含むとよい。さらに、INDE参照アーキテクチャは、ソリューション開発の標準化された開始点を提供するとよい。特定の電力グリッドに対する具体的な技術アーキテクチャを判断する手順については後述する。INDE参照アーキテクチャは、エンタープライズ規模のアーキテクチャであるとよい。その目的は、グリッドデータおよび解析のエンドツーエンド管理と、これらのユーティリティシステムおよびプロセスへの統合とのためのフレームワークを提供することであるとよい。スマートグリッド技術は、ユーティリティビジネスプロセスのあらゆる側面に影響することから、グリッド、動作および需要家構内レベルの影響のみではなく、バックオフィスおよびエンタープライズレベルの影響にも気を配らなければならない。したがって、INDE参照アーキテクチャは、例えばインターフェースのためにSOA環境をサポートするよう、エンタープライズレベルSOAを参照することができ、実際に参照する。これは、スマートグリッドを構築および使用するには、ユーティリティがその既存のIT環境をSOAに変更しなければならないと要求するものと見なされてはならない。エンタープライズサービスバスは、IT統合を促進する有益なメカニズムであるが、スマートグリッドソリューションの残りの部分を実装するために必須ではない。以下の説明は、INDEスマートグリッド構成要素の種々のコンポーネントに焦点を合わせる。INDEコンポーネントグループ上記のように、INDE参照アーキテクチャ内の種々のコンポーネントには、例えば1INDECORE120、2INDESUBSTATION180および3INDEDEVICE188が含まれ得る。以下の各セクションは、INDE参照アーキテクチャのこれら3つの例示の構成要素グループについて説明し、各グループのコンポーネントの説明を提供する。INDECORE図2は、図1に示されているように、INDE参照アーキテクチャのうち動作制御センターに存在するとよい部分である、INDECORE120を示す。INDECORE120は、グリッドデータを記憶するための統一データアーキテクチャと、そのデータに対して作用する解析の統合スキーマとを含むとよい。このデータアーキテクチャは、その最上位スキーマとして、国際電気標準会議IEC:InternationalElectrotechnicalCommission共通情報モデルCIM:CommonInformationModelを使用するとよい。IECCIMは、アプリケーションソフトウェアが電気ネットワークの構成およびステータスについての情報を交換できるようにすることを目標として、電気電力業界により開発されIECにより公式に採用された標準である。さらに、このデータアーキテクチャは、他のタイプのユーティリティデータ例えば計器データ、運用および過去データ、ログならびにイベントファイルなど、ならびに接続性およびメタデータファイルを、エンタープライズアプリケーションを含む上位アプリケーションによるアクセスのための単一エントリポイントを有するとよい単一データアーキテクチャに関連付けるために、連合ミドルウェア134を使用するとよい。さらに、リアルタイムシステムが、高速データバスを介して主要データストアにアクセスするとよく、いくつかのデータストアはリアルタイムデータを受信することができる。種々のタイプのデータが、スマートグリッド内の1つ以上のバス内で搬送されるとよい。INDESUBSTATION180のセクションにおいて以下で説明するように、変電所データは、変電所において収集されて、ローカルに記憶されるとよい。具体的には、変電所に関連し近接しているとよいデータベースが、変電所データを記憶するとよい。さらに、変電所レベルに関連する解析は、変電所のコンピュータにて実行され、変電所データベースに記憶されるとよく、そのデータの全部または一部が、制御センターへ搬送されるとよい。搬送されるデータのタイプは、動作および非運用データ、イベント、グリッド接続性データならびにネットワーク位置データを含むとよい。運用データは、次に限定はされないが、スイッチ状態、フィーダ状態、コンデンサ状態、セクション状態、計器状態、FCIfaultedcircuitindicator:故障回路インジケータ状態、ラインセンサー状態、電圧、電流、有効電力、無効電力などを含むとよい。非運用データは、次に限定はされないが、電力品質、電力信頼性、アセット正常性、ストレスデータなどを含むとよい。運用および非運用データは、運用/非運用データバス146を使用して搬送されるとよい。電力グリッドの送電および/または配電におけるデータ収集アプリケーションが、データの一部または全部を運用/非運用データバス146へ送信することを担当するとよい。こうして、情報を得るための登録をすること、またはこのデータを利用可能にできるサービスを呼び出すことにより、この情報を必要とするアプリケーションがデータを得られるとよい。イベントは、後述するように、スマートグリッドの一部である様々なデバイスおよびセンサーから生じるメッセージおよび/またはアラームを含むとよい。イベントは、スマートグリッドネットワーク上のデバイスおよびセンサーから直接生成されてもよく、さらに、こうしたセンサーおよびデバイスからの測定データに基づいて様々な解析アプリケーションにより生成されてもよい。イベントの例には、計器の停止、計器のアラーム、変圧器の停止などが含まれ得る。グリッドデバイスのようなグリッドコンポーネントデジタル処理能力のためにプログラム可能な組み込みプロセッサを備えるセンサーなどのスマート電力センサー、温度センサーなど、追加の組み込み処理を含む電力システムコンポーネントRTUなど、スマート計器ネットワーク計器の正常性、計器読み取りなどおよびモバイル現場要員用デバイス供給停止イベント、作業命令完了などが、イベントデータ、運用および非運用データを生成するとよい。スマートグリッド内で生成されたイベントデータは、イベントバス147を介して伝送されるとよい。グリッド接続性データは、ユーティリティグリッドの配置を定義するとよい。グリッドコンポーネント変電所、セグメント、フィーダ、変圧器、スイッチ、リクローザー、計器、センサー、電柱などの物理的配置、およびそれらの設備における相互接続性を定義する基本レイアウトがあるとよい。グリッド内のイベントコンポーネントの不具合、保守活動などに基づき、グリッド接続性は継続的に変化し得る。下記でさらに詳しく説明するように、データが記憶される構造ならびにデータの組み合わせにより、過去の様々な時点におけるグリッド配置の再現が可能となる。グリッド接続性データは、ユーティリティグリッドに対する変更が加えられ、この情報がGISGeographicInformationSystem:地理情報システムアプリケーションにおいて更新されるにつれて、定期的に地理情報システムGISから抽出されるとよい。ネットワーク位置データは、通信ネットワーク上のグリッドコンポーネントについての情報を含むとよい。この情報は、メッセージおよび情報を特定のグリッドコンポーネントへ送信するために使用されるとよい。ネットワーク位置データは、新たなスマートグリッドコンポーネントが設置されたときにスマートグリッドデータベースに手動で入力されてもよく、またはこの情報が外部で保たれる場合はアセット管理システムから抽出される。下記でさらに詳しく説明するように、データは、グリッド内の様々なコンポーネントから送信され得るINDESUBSTATION180および/またはINDEDEVICE188など。データは、無線、有線または両方の組み合わせでINDECORE120へ送信され得る。データは、ユーティリティ通信ネットワーク160によって受信されるとよく、ユーティリティ通信ネットワーク160は、データをルーティングデバイス190へ送信するとよい。ルーティングデバイス190は、バスのセグメント上バスがセグメント化されたバス構造を含む場合または独立したバス上へのデータのルーティングを管理するソフトウェアおよび/またはハードウェアを含むとよい。ルーティングデバイス190は、1つ以上のスイッチまたはルータを含んでもよい。ルーティングデバイス190は、ネットワーキングデバイスを含むとよく、そのソフトウェアおよびハードウェアが、バスの1つ以上へデータをルーティングおよび/または転送する。例えば、ルーティングデバイス190は、運用および非運用データを、運用/非運用データバス146へルーティングするとよい。ルータはさらに、イベントデータをイベントバス147へルーティングするとよい。ルーティングデバイス190は、データをどのようにルーティングするかを、1つ以上の方法に基づき判断するとよい。例えば、ルーティングデバイス190は、伝送されたデータ内の1つ以上のヘッダを検査して、データを運用/非運用データバス146のセグメントへルーティングするか、またはイベントバス147のセグメントへルーティングするかを判断してもよい。具体的には、データ内の1つ以上のヘッダが、データが動作/非運用データであるかその結果ルーティングデバイス190はデータを運用/非運用データバス146へルーティングするまたはデータがイベントデータであるかその結果ルーティングデバイス190はイベントバス147をルーティングするを示してもよい。あるいは、ルーティングデバイス190は、データのペイロードを検査して、データのタイプを判断してもよい例えば、ルーティングデバイス190は、データのフォーマットを検査して、データが運用/非運用データであるか、またはイベントデータであるかを判断してもよい。運用データを記憶する運用データウェアハウス137などのストアの1つが、真の分散型データベースとして実装されてもよい。ストアのもう1つ、ヒストリアン図1および2において過去データ136として特定されているが、分散型データベースとして実装されてもよい。これら2つのデータベースのもう一方のエンドは、INDESUBSTATION180グループ後述にあってもよい。さらに、イベントは、複合イベント処理バスを介していくつかのデータストアのいずれかに直接記憶されてもよい。具体的には、イベントは、イベントバス147へ発行したすべてのイベントのリポジトリとしてもよいイベントログ135に記憶されてもよい。イベントログは、イベントid、イベントタイプ、イベントソース、イベント優先度およびイベント生成時間のうちの1つ、いくつかまたはすべてを記憶するとよい。イベントバス147が、イベントを長期記憶してすべてのイベントの維持を提供する必要はない。データの記憶は、できるだけ、または実用的なだけ、データがソースに近くなるようになっているとよい。一実装では、これには例えば、変電所データがINDESUBSTATION180にて記憶されることが含まれてもよい。しかし、このデータは、非常に細かい粒度レベルでグリッドを考慮した各種決定を下すために、動作制御センターレベル116においても必要とされることもある。データベースリンクおよびデータサービスを適宜使用することによってソリューションのすべてのレベルにおけるデータの利用可能性を促進するよう、分散型データ手法が、分散型インテリジェンス手法とともに採用されるとよい。このように、過去データストア動作制御センターレベル116にてアクセス可能であるとよいに関するソリューションは、運用データストアのソリューションと類似しているとよい。データは、変電所においてローカルに記憶されてもよく、制御センターにおいてリポジトリインスタンス上で構成されているデータベースリンクが、個別の変電所にあるデータに対するアクセスを提供する。変電所解析は、変電所において、ローカルデータストアを使用してローカルで実行されるとよい。データベースリンクを使用してローカル変電所インスタンスのデータにアクセスすることによって、動作制御センターレベル116で過去/集合的解析が実行されてもよい。あるいは、データは、INDECORE120にて中央で記憶されてもよい。しかし、INDEDEVICE188から伝送される必要があると考えられるデータの量を考慮すると、INDEDEVICE188にてデータを記憶する方が好ましいこともある。具体的には、何千または何万もの変電所がある場合電力グリッドではあり得る、INDECORE120へ伝送される必要のあるデータ量により、通信ボトルネックがもたらされることもあり得る。最後に、INDECORE120は、電力グリッド内のINDESUBSTATION180またはINDEDEVICE188のうちの1つ、いくつかまたはすべてをプログラムまたは制御するとよい後述。例えば、INDECORE120は、プログラミングを変更してもよく更新されたプログラムをダウンロードするなど、またはINDESUBSTATION180もしくはINDEDEVICE188の任意の側面を制御する制御コマンドを提供してもよいセンサーまたは解析の制御など。図2に示されていない他の構成要素に、この論理アーキテクチャをサポートする様々な統合構成要素が含まれ得る。表1は、図2に示されたINDECORE120の特定の構成要素を記載する。表1:INDECORE構成要素表1で説明したように、リアルタイムデータバス146運用および非運用データを伝達するおよびリアルタイム複合イベント処理バス147イベント処理データを伝達するは単一バス346に組み合わされる。この例が、図3のブロック図300に示されている。図1に示されているように、バスは、パフォーマンスのために別々になっている。CEP処理の場合、非常に大きなメッセージバーストが起こりやすい特定の用途には、低遅延が重要であると考えられる。一方、グリッドデータフローの大部分はほぼ一定であり、デジタル故障レコーダファイルが例外であるが、これらは通常、制御された形で取得可能である。それに対し、イベントバーストは非同期且つランダムである。図1はさらに、INDECORE120とは別の、動作制御センター116内のさらなる構成要素を示す。具体的には、図1はさらに、計器との通信計器からデータを収集して収集したデータをユーティリティに提供するなどを担当するシステムである、計器データ収集ヘッドエンド単数または複数153を示す。需要応答管理システム154は、1つ以上の需要家構内にある、ユーティリティによる制御が可能な設備と通信するシステムである。供給停止管理システム155は、供給停止の位置を追跡すること、何が送られているかを管理すること、およびその修理方法によって、供給停止の管理においてユーティリティを支援するシステムである。エネルギー管理システム156は、送電グリッド上の変電所例えばのデバイスを制御する、送電システムレベルの制御システムである。配電管理システム157は、配電グリッドの変電所のデバイスおよびフィーダデバイス例えばを制御する、配電システムレベルの制御システムである。IPネットワークサービス158は、IP型通信DHCPおよびFTPFileTransferProtocol:ファイル転送プロトコルなどをサポートする1つ以上のサーバ上で動作するサービスの集合である。モバイルデータ送信システム159は、現場のモバイルデータ端末とメッセージを送受信するシステムである。回路負荷潮流分析、計画、雷分析およびグリッドシミュレーションツール152は、グリッドの設計、分析および計画においてユーティリティにより使用されるツールの集合である。IVRintegratedvoiceresponse:統合音声応答および呼管理151は、需要家からの電話を処理するシステムである自動または係により。供給停止に関する着信通話が、自動または手動で入力されて、供給停止管理システム155へ転送されるとよい。作業管理システム150は、作業命令を監視および管理するシステムである。地理情報システム149は、アセットが地理的にどこに位置し、各アセットがどのように接続されているかについての情報を含むデータベースである。環境がサービス指向アーキテクチャSOAを有する場合、動作SOAサポート148は、SOA環境をサポートするサービスの集合である。一実施形態では、INDEcore120に含まれるSIEM162は、残存リスクに関連する望ましくないイベントの発生を検出および判断し、当該の発生が、悪意のある攻撃の結果である可能性が高いかどうかを判断するために、CEP処理バス147とともに使用されるとよい。図20を参照する。様々なタイプのデータ2000が、CEPバス147によって受信され得る。以下の表2は、データ2000として使用され得る情報のタイプの例の包括的でないリストを提供する。このデータは、図1のINDEシステム内の電子ソース2001から生じるとよい。表2:データタイプ一実施形態では、データ2000は、非ITログデータまたは動的、環境特有、傾向データと見なされるとよい簡潔にするために本願明細書ではまとめて非ITデータと呼ばれる。したがって、非ITデータ2000は、次に限定はされないが、表2に示されているようにフェーザー測定値、接続性状態および他の地域における供給停止などの非従来型のIT情報、表2に示されているように特定の位置に関するイベントデータ、過去の傾向または通常の挙動を示すことができる過去データ、ならびに地理的位置データペンタゴン、連邦準備銀行、ホワイトハウス、陸軍基地、外国大使館などの有名または高価値ターゲットなど、特定の位置に関係するデータなどを含むとよい。データ2000は、INDE内のセンサーおよび検出器などの様々な電子ソース2001、ネットワークベースのデータ、インターネットベースのデータ、またはその他のタイプの適切なデータを通して受信されるとよい。非ITデータの電子ソース2001の包括的でないリストは、ウェブクローリングデバイス、検索エンジン対応コンピューティングデバイス、ウェブアクセスデバイス、GPSデバイス、ソーシャルメディアスレッド監視デバイス、温度計および緊急対応通報器emergencyresponsecommunicatorを含み得る。これらの電子ソース2001は、CEPバス147と結合されているとよい。本願明細書において、と結合されているという表現は、直接接続されていること、または1つ以上の中間コンポーネントを介して間接的に接続されていることを意味するものと定義される。そのような中間コンポーネントは、ハードウェアベースおよびソフトウェアベース両方のコンポーネントを含み得る。電子ソース2001によって、またはそれに関連していくつかのツールが使用できるものと理解されるとよく、次に限定はされないが、これには、位置に基づくディスカッション、ならびにユーザの位置を確認し、例えば自然災害またはテロ行為を含む望ましくないイベントの発生の可能性を示し得る情報を求めてツイート、フェイスブックの投稿、またはその他のソーシャルメディアストリームを探し回るソーシャルメディア対応デバイスが含まれる。RMSフィードも監視されてもよい。位置の確認は、ユーザによる宣言、ユーザの位置を投稿または共有するためにユーザから許可を獲得する例えば、フェイスブックアプリケーションのPlaces登録商標を介して、またはモバイルデバイスの位置にアクセスすることをユーザが認める別のアプリケーションを介してモバイル電話またはコンピューティングデバイスアプリケーション、許可されている場合は三角測量を含み得る。IPアドレス指定または経路探索も、ユーザ位置を判断するために実行され得る。ツールはさらに、インターネットのウェブページから情報を集めるウェブクローラを含む、ウェブ検索用ツールを含み得る。これらまたはその他多数の情報のソースから取得される位置がGPSベースであるか否かに関わらず、システムは、位置をGPS位置に変換するとよく、そのようなGPS位置と、インテリジェントユーティリティグリッドシステム上またはその近くの対応する位置とを相関させようとするとよい。そのような相関を用いて、本願明細書に開示されるシステムは、望ましくないイベントを、悪意があるか否か例えば、セキュリティリスクであるかエンジニアリングリスクであるか特徴評価することができるとよい。CEPバス147によってデータ2000が受信されると、データ2000は、フィルタモジュール2002によって前処理されるとよい。フィルタモジュール2002は、データ2000を前処理して、データ2000に含まれているデータのうち、関連性のあるデータを判断することを担当するとよい。例えば、CEPバス147は、他の地域/国の電力供給停止情報およびツイッタートレンド統計を受信してもよい。続いて、フィルタリングまたは前処理されたデータ2003は、ルールエンジンモジュール2004によって受信されるとよい。ルールエンジンモジュール2004は、様々な所定のルールまたは基準を含むとよく、それに基づいて、前処理されたデータを評価して、前処理されたデータが、残存リスクに関連する望ましくないイベントの1つ以上の発生を表すかどうかを判断する。これらのルールは、悪意のあるアクティビティにより望ましくないイベントが発生していることまたは発生するかもしれないことを示し得る、INDEに存在する条件を特定するために使用されるとよい。例えば、特定の位置における電力供給停止は、INDEに対する悪意のある攻撃が発生していたこと、または電力供給停止が、悪天候条件もしくは車両事故など、悪意のない原因によるものであることを示し得るであろう。ルールエンジンモジュール2004は、供給停止が発生したことを示す情報を、集中制御センターから受信してもよい。あるいは、センサー出力、計器データまたはその他適切な検出方法によって、供給停止またはその他の望ましくないイベントの判断が下されてもよい。一実施形態では、ルールエンジンモジュール2004は、データ2000によって伝えられる特定のデバイスの状態または条件例えば計器の停止を受信するとよい。様々な条件の状態の判断により、ルールエンジンモジュール2004は、判断された様々な状態に所定のルールを適用して、望ましくないイベントの発生に悪意のある原因が関与している可能性が高いかどうかを判断するとよい。ルールエンジンモジュール2004は、望ましくないイベントの発生が悪意のあるアクティビティによるものである見込みを伝えるために、確率レベルprobabilitylevelを生成するとよい。ルールエンジンモジュール104は、ルールエンジンによって下された判断に応じて、特定の定性的な確率レベル高、中または低を有するリスク確率を生成するとよい。例えば、ルールエンジンモジュール104は、データ2000内で受信された情報に基づく供給停止位置および天候条件に注目しながら、所定のルールを使用するとよい。別の例では、確率レベルは、より少ない、またはさらなる定性的レベル、百分率またはその他の適切な表現を使用して表現されればよい。ルールエンジンモジュール2004は、供給停止が特定の位置例えば郵便番号12345に存在し、郵便番号12345に竜巻が存在することを現在の天候情報が示せば、当該の供給停止が悪意によるものである確率は低く、そうではなく荒天などの他の原因による可能性が高いと判断するとよい。そのような場合には、ルールエンジンモジュール2004は、当該の発生が悪意のあるものである確率は、所定のレベルによれば低であると判断してもよい。各レベルが判断される閾値は、温度、位置、近くの交通事故、近くの火災、近くの発砲のレポート、ドル、いくつかのツイッター統計または任意の種類のソーシャルネットワーキング投稿または通信に関係する統計、PMU値、最近の嵐、国土安全保障脅威レベル、国防総省脅威レベル、国家脅威レベル、日時および同種のものなど、様々な基準に基づき得る。表3は、ルールエンジンモジュールによって実装されるルールが、INDEシステムに対する悪意のある攻撃が発生していると考えられる確率を示すためにどのように使用され得るかを示す、包括的でない例のリストを示す、他のいくつかの例を提供する。表3:例示のルール特定の望ましくないイベントが悪意を持って引き起こされていることの確率レベルが判断されると、ルールエンジンモジュール2004は、望ましくないイベントを、過去相関モジュール2006と相互参照するとよい。過去相関モジュール2006は、データ2000を参照して、そのような任意の条件が、以前に悪意のある攻撃の発生を示したことがあるか、またはそのような形で誤報を示したことがあるかを判断するとよい。過去相関モジュール2006は、例えば関連性のある過去データを獲得するために、イベントログ135、過去データ136、および運用データ137図1参照など、様々なソースから過去データを取得するとよい。例えば、供給停止が特定の領域例えば郵便番号12345に存在し、郵便番号12345に竜巻が存在することを現在の天候情報が示す、上記で与えられたシナリオでは、過去相関モジュール2006は、その領域では竜巻が記録されたことがないこと、またはその領域は一般に竜巻発生で知られていることを示す、郵便番号12345に関する過去情報を取得するとよい。そのような過去情報が取得された場合、ルールエンジンモジュール104は、竜巻を示す状態の発生は考え難いものである可能性が高いと判断してもよく、悪意のあるアクティビティの確率が高であると判断することになる。一方、過去情報が、竜巻または竜巻をもたらす条件が過去から存在していたことを示すと、ルールエンジンモジュール2004によって、以前の低確率の指示が保たれることになる。悪意のある攻撃が発生している可能性または発生した可能性が高いと判断されると、その指示が、ルールエンジンモジュール2004によって、図20に表されたSIEM162に、残存リスクイベントメッセージ2008としてCPEバス147を介して提供されてもよい。残存リスクイベントメッセージ2008は、供給停止などの分析された条件と、その条件の悪意のある原因の確率レベルの判断とを含むとよく、その判断のために非ITデータに依存するとよい。SIEM162はさらに、ルータ、スイッチ、ファイアウォール、侵入検出システムまたはウイルス保護などのITハードウェアまたはソフトウェアから情報技術ITイベントまたはアクティビティ2010を受信するとよい。ITイベント2010は、スイッチログに含まれるものなど、INDEのITインフラストラクチャに関する様々な情報を提供するとよい。ITイベント2010は、例えばデバイスログ、IDS/IPSアラート、WIDS/WIPSアラート、アンチウイルスアラートおよびデバイス構成などの情報を含むとよい。こうした一般的なタイプのITイベントの範囲に入らない任意のデータまたは情報は、その用語が本願明細書で言及されるとき、非ITデータと見なされる。残存リスクイベントメッセージ2008およびITイベント2010を受信すると、SIEM162は、悪意のあるアクティビティによって引き起こされたリスクのタイプを示すリスク特徴評価を判断するとよい。リスク特徴評価が判断されると、SIEM162は、システム管理者または望ましくないイベントの任意の発生に対応することを担当する他の個人/エンティティに提供されるとよい、リスク特徴評価メッセージ2012を生成するとよい。リスク特徴評価メッセージ2012は、特定のイベントの悪意の確率レベルを示すのみではなく、セキュリティ、エンジニアリング、通信などのリスクがある1つまたは複数の領域も特定するとよい。一例では、これは、意図的でないまたは予期しないハザードまたは悪意のある攻撃のいずれかの結果としてリスクが特徴評価されることによって実行されてもよい。残存リスクと、IT/ネットワーク情報との相関は、リスクのある領域の指摘を促進する。再び図1を参照する。動作制御センター116内にあり、INDECore120外にあるシステムのうちの1つ以上は、ユーティリティが有することもあり非ITデータを提供することもあるレガシー製品システムである。こうしたレガシー製品システムの例には、動作SOAサポート148、地理情報システム149、作業管理システム150、呼管理151、回路負荷潮流分析、計画、雷分析およびグリッドシミュレーションツール152、計器データ収集ヘッドエンド単数または複数153、需要応答管理システム154、供給停止管理システム155、エネルギー管理システム156、配電管理システム157、IPネットワークサービス158およびモバイルデータ送信システム159が含まれる。なお、こうしたレガシー製品システムは、スマートグリッドから受信されるデータを処理または操作することができなくてもよい。INDECore120は、スマートグリッドからデータを受信し、スマートグリッドからのデータを処理し、処理したデータを1つ以上のレガシー製品システムへ、レガシー製品システムが使用できる形レガシー製品システムに特有の特定のフォーマッティングなどで転送することができるとよい。このように、INDECore120はミドルウェアと見なされてもよい。INDECORE120を含む動作制御センター116は、エンタープライズIT115と通信するとよい。一般的に、エンタープライズIT115における機能性はバックオフィス業務を含む。具体的には、エンタープライズIT115は、ビジネスデータウェアハウス104、ビジネスインテリジェンスアプリケーション105、エンタープライズリソースプラニング106、様々な財務システム107、需要家情報システム108、人材システム109、アセット管理システム110、エンタープライズSOAサポート111、ネットワーク管理システム112およびエンタープライズメッセージサービス113を含むエンタープライズIT115内の様々なシステムへデータを送信するためにエンタープライズ統合環境バス114を使用するとよい。エンタープライズIT115はさらに、ファイアウォール102を介してインターネット101と通信するためのポータル103を含むとよい。INDESUBSTATION図4は、INDESUBSTATION180グループの上位アーキテクチャの例を示す。このグループは、変電所の電子装置およびシステムと同じ場所に位置する1つ以上のサーバ上で、変電所の制御所にて変電所170内で実際にホストされている構成要素を含むとよい。以下の表4は、特定のINDESUBSTATION180グループ構成要素を列挙し、説明する。データセキュリティサービス171は、変電所環境の一部であってもよい。あるいは、これらはINDESUBSTATION180グループに統合されてもよい。表4:INDESUBSTATION構成要素上記のように、スマートグリッド内の種々の構成要素に、追加の処理/分析能力およびデータベースリソースを含む追加の機能性が含まれ得る。スマートグリッドにおいて、様々な構成要素内でこうした追加の機能性を使用することで、アプリケーションおよびネットワークパフォーマンスの集中管理および監督を伴う分散型アーキテクチャが可能になる。機能、パフォーマンスおよび拡張性のために、何千から何万のINDESUBSTATION180および何万から何百万のグリッドデバイスを含むスマートグリッドが、分散型処理、データ管理およびプロセス通信を含むこともできる。INDESUBSTATION180は、1つ以上のプロセッサと、1つ以上のメモリデバイス変電所非運用データ181および変電所動作データ182などとを含むとよい。非運用データ181および変電所動作データ182は、INDESUBSTATION180内またはINDESUBSTATION180上に位置するなど、変電所に関連し近接しているとよい。INDESUBSTATION180はさらに、変電所レベルでのスマートグリッドの可観測性を担当する、スマートグリッドのコンポーネントを含んでもよい。INDESUBSTATION180コンポーネントは、運用データ入手および分散型運用データストアでの記憶、非運用データの入手およびヒストリアンでの記憶、ならびにリアルタイムサブ秒などでのローカル解析処理という3つの主要機能を提供するとよい。処理は、電圧および電流波形のデジタル信号処理と、イベントストリーム処理を含む検出および分類処理と、処理結果のローカルシステムおよびデバイス、ならびに動作制御センター116にあるシステムへの伝達とを含むとよい。INDESUBSTATION180と、グリッド内の他のデバイスとの通信は、有線、無線または有線と無線との組み合わせとしてよい。例えば、INDESUBSTATION180から動作制御センター116へのデータの伝送は有線であってもよい。INDESUBSTATION180は、動作/非運用データまたはイベントデータなどのデータを、動作制御センター116へ伝送するとよい。ルーティングデバイス190は、伝送されたデータを、運用/非運用データバス146またはイベントバス147のうちの1つへルーティングするとよい。配電損失管理のための需要応答最適化も、ここで実行されるとよい。このアーキテクチャは、前に説明した分散型アプリケーションアーキテクチャの原則に従う。例えば、接続性データは、変電所170および動作制御センター116にて複製され、その結果、動作制御センター116へのデータ通信ネットワークが有効でなくても変電所170が独立して動作できるようにするとよい。この情報接続性がローカルに記憶されていることで、動作制御センターへの通信リンクが動作不能であっても変電所解析がローカルで実行され得る。同様に、運用データは、動作制御センター116および変電所170にて複製されるとよい。特定の変電所に関連するセンサーおよびデバイスからのデータが収集され、最新の測定が、変電所にてこのデータストアに記憶されるとよい。運用データストアのデータ構造は同じであるとよく、したがって、データベースリンクを使用して、制御センターにある運用データストアのインスタンスを介した、変電所に存在するデータへのシームレスアクセスを提供することもできる。これは、データの複製を減らすこと、および時間依存がより大きい変電所データ解析が、ローカルで、変電所外の通信利用可能性に依存せずに行われるのを可能にすることを含む、いくつかの利点を提供する。動作制御センターレベル116でのデータ解析は、時間依存がより小さいと考えられ典型的には、動作制御センター116は、過去データを検査して、反応型というよりも予測型のパターンを識別すると考えられるため、ネットワークの問題があっても対処できると考えられる。最後に、過去データが変電所にてローカルに記憶され、データのコピーが制御センターにて記憶されてもよい。または、動作制御センター116にてリポジトリインスタンス上のデータベースリンクが構成され、個別の変電所にあるデータへのアクセスが動作制御センターに提供されてもよい。変電所解析は、変電所170において、ローカルデータストアを使用してローカルで実行されるとよい。具体的には、変電所にて追加のインテリジェンスおよび記憶能力を使用することで、変電所は、それ自体を分析して、中央局からの入力なしにそれ自体を修正することができる。あるいは、ローカル変電所インスタンスのデータにデータベースリンクを使用してアクセスすることによって、動作制御センターレベル116で、過去/集合的解析も実行されてもよい。INDEDEVICEINDEDEVICE188グループは、様々な配電グリッドデバイス189例えば、送電線上のラインセンサーなどのスマートグリッド内の様々なセンサー、需要家構内にある計器163などを含む、スマートグリッド内の任意の種類のデバイスを含み得る。INDEDEVICE188グループは、特定の機能性を備えグリッドに追加されるデバイスを含んでもよく専用プログラミングを含むスマートリモート端末ユニットRTUなど、または追加機能性を備えるグリッド内の既存デバイスを含んでもよい既にグリッド内に配置されており、スマートラインセンサーまたはスマートグリッドデバイスを作成するためにプログラム可能な、既存のオープンアーキテクチャ柱上RTUなど。INDEDEVICE188はさらに、1つ以上のプロセッサおよび1つ以上のメモリデバイスを含んでもよい。既存のグリッドデバイスは、ソフトウェアの観点からはオープンではないこともあり、現代のネットワーキングまたはソフトウェアサービスに関してはあまりサポートできないかもしれない。既存のグリッドデバイスは、ラップトップコンピュータなどの他の何らかのデバイスに時折オフロードするデータを入手および記憶するよう、または要求に応じてリモートホストへPSTNpublic-switchedtelephonenetwork:公衆交換電話ネットワーク線を介してバッチファイルを転送するよう設計されていることもある。こうしたデバイスは、リアルタイムデジタルネットワーク環境で動作するようには設計されていないこともある。このような場合には、グリッドデバイスデータは、既存の通信ネットワークがどのように設計されているかに応じて、変電所レベル170または動作制御センターレベル116で獲得されるとよい。計測ネットワークの場合、計器ネットワークが通常クローズドであり、計器が直接アドレス指定可能ではないことから、通常は計器データ収集エンジンからデータが獲得される。こうしたネットワークが進化するにつれて、計器および他のグリッドデバイスが個別にアドレス指定可能になると考えられ、その結果データが、必要とされるところへ直接搬送可能になる。データが必要とされる場所は、必ずしも動作制御センター116とは限らず、グリッド上のどこにでもなり得る。故障回路インジケータなどのデバイスは、適度な速度100kbpsなどの無線ネットワークを介した接続のために、無線ネットワークインターフェースカードと結合されてもよい。こうしたデバイスは、例外によりステータスをレポートして、事前にプログラムされた固定機能を実行してもよい。ローカルスマートRTUを使用することによって、多数のグリッドデバイスのインテリジェンスが増強され得る。固定機能のクローズドアーキテクチャデバイスとして設計されている柱上RTUの代わりに、サードパーティーによりプログラム可能でINDE参照アーキテクチャ内のINDEDEVICE188としての機能を果たすことができるオープンアーキテクチャデバイスとしてのRTUが使用されてもよい。さらに、需要家の構内にある計器がセンサーとして使用されてもよい。例えば、計器は、消費を測定してもよく請求のために、どのくらいのエネルギーが消費されているかなど、電圧を測定してもよい電圧/VAR最適化で用いるために。図5は、INDEDEVICE188グループの例示アーキテクチャを示す。表5は、特定のINDEDEVICE188構成要素を説明する。スマートグリッドデバイスは、組み込みプロセッサを含むとよく、したがって、DEVICEグループは専用リアルタイムDSPまたはマイクロプロセッサ上で実装されるため、処理構成要素は、SOAサービスよりもリアルタイムプログラムライブラリルーチンに似る。表5:INDEDEVICE構成要素図1はさらに、1つ以上のスマート計器163、家庭内ディスプレイ165、1つ以上のセンサー166および1つ以上の制御167を含むとよい需要家構内179を示す。実際には、センサー166は、需要家構内179にある1つ以上のデバイスにてデータを登録するとよい。例えば、センサー166は、暖房炉、温水ヒーター、空調装置などの、需要家構内179の中の様々な主要電化製品にてデータを登録するとよい。この1つ以上のセンサー166からのデータが、スマート計器163へ送信されるとよく、スマート計器163は、ユーティリティ通信ネットワーク160を介して動作制御センター116へ伝送するためにデータをパッケージ化するとよい。家庭内ディスプレイ165は、スマート計器163および1つ以上のセンサー166から収集されたデータをリアルタイムで閲覧するための出力デバイスを需要家構内において需要家に提供するとよい。さらに、需要家が動作制御センター116と通信できるよう、入力デバイスキーボードなどが家庭内ディスプレイ165に関連付けられてもよい。一実施形態では、家庭内ディスプレイ165は、需要家構内にあるコンピュータを含むとよい。需要家構内165はさらに、需要家構内179の1つ以上のデバイスを制御するとよい制御167を含むとよい。ヒーター、空調装置など、需要家構内179にある様々な電化製品が、動作制御センター116からのコマンドに応じて制御されるとよい。図1に示されているように、需要家構内169は、インターネット168、公衆交換電話ネットワークPSTN169を介して、または専用線を介してコレクタ164を介してなどなど、様々な方法で通信するとよい。列挙された通信チャネルのいずれかを介して、1つ以上の需要家構内179からのデータが送信されるとよい。図1に示されているように、1つ以上の需要家構内179が、ユーティリティ管理ネットワーク160を介して動作制御センター116へ伝送されるようコレクタ164へデータを送信する、スマート計器ネットワーク178複数のスマート計器163を含むを含むとよい。さらに、分散型エネルギー生成/貯蔵162ソーラーパネルなどの様々なソースが、ユーティリティ管理ネットワーク160を介した動作制御センター116との通信のために、監視制御161へデータを送信するとよい。上記のように、動作制御センター116外にある電力グリッドのデバイスは、処理および/または記憶能力を含むとよい。デバイスは、INDESUBSTATION180およびINDEDEVICE188を含むとよい。電力グリッド内の個別のデバイスが追加のインテリジェンスを含むことに加えて、個別のデバイスは、情報センサーデータおよび/または分析データイベントデータなどを含むを交換するため、電力グリッドの状態を分析するため故障の判断など、および電力グリッドの状態を変更するため故障の修正などに、電力グリッド内の他のデバイスと通信するとよい。具体的には、個別のデバイスは、1インテリジェンス処理能力など、2記憶装置上記の分散型記憶装置などおよび3通信上記の1つ以上のバスの使用などを使用するとよい。このようにして、電力グリッド内の個別のデバイスは、動作制御センター116からの監督なしに相互に通信および協働するとよい。例えば、上記で開示されたINDEアーキテクチャは、フィーダ回路上の少なくとも1つのパラメータを感知するデバイスを含むとよい。デバイスはさらに、フィーダ回路上で感知されたパラメータを監視し、感知されたパラメータを分析してフィーダ回路の状態を判断するプロセッサを含むとよい。例えば、感知パラメータの分析は、感知されたパラメータと、所定の閾値との比較を含んでもよく、さらに/または傾向分析を含んでもよい。上記の感知されるパラメータの1つには、波形の感知が含まれてもよく、上記の分析の1つには、感知された波形がフィーダ回路上の故障を示すかどうかを判断することが含まれてもよい。デバイスはさらに、1つ以上の変電所と通信するとよい。例えば、特定の変電所が、特定のフィーダ回路に電力を供給するとよい。デバイスは、その特定のフィーダ回路の状態を感知して、特定のフィーダ回路上に故障があるかどうかを判断するとよい。デバイスは、変電所と通信するとよい。変電所は、デバイスによって判断された故障を分析するとよく、故障に応じて修正措置を取るとよいフィーダ回路に供給される電力を削減するなど。デバイスが故障を示すデータを送信する波形の分析に基づき例では、変電所は、動作制御センター116からの入力なしに、フィーダ回路に供給される電力を変更するとよい。または変電所は、故障を示すデータと、他のセンサーからの情報とを組み合わせて、故障の分析をさらに精緻化してもよい。変電所はさらに、供給停止インテリジェンスアプリケーション説明される図13などおよび/または故障インテリジェンスアプリケーション図14で説明されるものなどなど、動作制御センター116と通信してもよい。したがって、動作制御センター116が、故障を判断してもよく、供給停止の範囲故障の影響を受ける戸数などを判断してもよい。このように、フィーダ回路の状態を感知するデバイスは、動作制御センター116の介入を要求するかしないかに関わらず、考えられる故障を修正するために変電所と協調動作するとよい。別の例として、処理および/またはメモリ能力を使用する追加のインテリジェンスを含むラインセンサーが、グリッドの一部分フィーダ回路などにおいてグリッド状態データを作り出してもよい。グリッド状態データは、動作制御センター116の需要応答管理システム155と共有されるとよい。需要応答管理システム155は、ラインセンサーからのグリッド状態データに応答して、フィーダ回路上の需要家サイトの1つ以上のデバイスを制御してもよい。具体的には、需要応答管理システム155は、ラインセンサーがフィーダ回路上の供給停止を示すのに応答して、フィーダ回路から電力を受ける需要家サイトにある電化製品をオフにすることによってフィーダ回路への負荷を軽減するよう、エネルギー管理システム156および/または配電管理システム157に命令してもよい。このように、ラインセンサーは需要応答管理システム155とともに、故障したフィーダ回路から自動的に負荷を移し、続いて故障を隔離するとよい。さらに別の例として、電力グリッド内の1つ以上のリレーが、それに関連するマイクロプロセッサを有するとよい。これらのリレーは、故障の判断、および/または電力グリッドの制御のために、電力グリッド内にある他のデバイスおよび/またはデータベースと通信するとよい。INDSIntelligentNetworkDataServices:インテリジェントネットワークデータサービスの概念およびアーキテクチャアウトソースされるスマートグリッドデータ/解析サービスモデルスマートグリッドアーキテクチャに対する1つの応用は、ユーティリティが、組織内に従来の制御システムおよび関係する運用システムを保ちながら、グリッドデータ管理および解析サービスを契約できるようにする。このモデルでは、ユーティリティはグリッドセンサーおよびデバイスを設置および所有するとよく上記のように、グリッドデータ搬送通信システムは、所有および運用しても、アウトソースしてもよい。グリッドデータは、ユーティリティからリモートのインテリジェントネットワークデータサービスINDSホスティングサイトへ流れるとよく、そこでデータが管理、記憶および分析されるとよい。その結果、ユーティリティは、適切なサービス財務モデルのもとでデータおよび解析サービスを契約することもできる。ユーティリティは、料金を払う代わりに、初期資本支出投資と、スマートグリッドデータ/解析インフラストラクチャの管理、サポートおよび改良の継続的な費用とを回避することができる。上記のINDE参照アーキテクチャは、本願明細書に記載されるアウトソース用の構成に適している。スマートグリッドサービスのINDSアーキテクチャINDSサービスモデルを実装するために、INDE参照アーキテクチャは、リモートでホストされるとよい構成要素のグループと、ユーティリティに残るとよいものとに区分されるとよい。図6は、INDECORE120がリモートにされるとユーティリティアーキテクチャがどのように見えると考えられるかを示す。サーバが、INDECORE120の一部として含まれるとよく、リモートシステムへのインターフェースとして機能するとよい。ユーティリティシステムには、これが仮想INDECORE602に見えるとよい。図6の全体的なブロック図600が示すように、INDESUBSTATION180およびINDEDEVICE188グループは、図1に示されたものから変化していない。さらに、複数バス構造も、ユーティリティにてやはり採用されるとよい。INDECORE120は、図7のブロック図700が示すようにリモートでホストされるとよい。ホスティングサイトでは、ユーティリティのINDS契約者をサポートするために、必要に応じINDECORE120が設置されるとよい北米INDSホスティングセンター702として示されている。各CORE120は、モジュラーシステムであり、その結果新たな契約者の追加は定型操作であるとよい。電気ユーティリティとは別の関係者が、INDECORE120の1つ、いくつかまたはすべてのソフトウェアと、INDSホスティングサイトから各ユーティリティのINDESUBSTATION180およびINDEDEVICE188にダウンロードされるアプリケーションとを管理およびサポートするとよい。通信を促進するために、契約ユーティリティの動作センターならびにINDSホスティングサイトに到達することができるネットワーク704例えばマルチプロトコルラベルスイッチングMPLS:Multi-ProtocolLabelSwitchingまたはその他のWANなどを介した高帯域低遅延通信サービスが使用されるとよい。図7に示されているように、カリフォルニア州、フロリダ州およびオハイオ州など、様々な領域にサービスが提供されるとよい。このような運用のモジュール性は、異なる様々なグリッドの効率的な管理を可能にするのみではなく、グリッド間のよりよい管理も可能にする。1つのグリッドの不具合が、周辺のグリッドの動作に影響を及ぼす恐れがある場合がある。例えば、オハイオ州のグリッドにおける不具合が、中部大西洋岸のグリッドなど、周辺のグリッドにおける動作に対しカスケード効果を有することもある。図7に示されているモジュール構造を使用することで、個別のグリッドの管理およびグリッド間動作の管理が可能になる。具体的には、全体的なINDSシステムプロセッサおよびメモリを含むが、様々なINDECORE120間の対話を管理するとよい。これは、1つのグリッドから別のグリッドへ波及する破局故障の可能性を軽減するとよい。例えば、オハイオ州のグリッドにおける不具合が、中部大西洋岸のグリッドなど、周辺のグリッドに波及することもある。オハイオ州のグリッドの管理専用のINDECORE120は、オハイオ州のグリッドにおける不具合の修正を試みるとよい。さらに、全体的なINDSシステムが、波及不具合が周辺グリッドで生じる可能性を軽減することを試みるとよい。INDECOREにおける機能性の具体的な例図1、6および7に示されているように、様々な機能性ブロックにより表されているがINDECORE120に含まれており、そのうち2つは、計器データ管理サービスMDMS:meterdatamanagementservices121ならびに計測解析およびサービス122である。アーキテクチャのモジュール性が理由で、MDMS121ならびに計測解析およびサービス122などの様々な機能性を組み込むことができる。可観測性プロセス上記のように、アプリケーションサービスの1つの機能性は、可観測性プロセスを含むとよい。可観測性プロセスは、ユーティリティがグリッドを観測できるようにするとよい。こうしたプロセスは、グリッド上のすべてのセンサーおよびデバイスから受信される生データを解釈して、それを実用的な情報へ変えることを担当するとよい。図8は、可観測性プロセスのいくつかの例の列挙を含む。図9は、グリッド状態測定動作プロセスのフロー図900を示す。ブロック902にて、データスキャナが計器データをリクエストするとよい。リクエストは、1つ以上のグリッドデバイス、変電所コンピュータおよびラインセンサーRTUへ送信されるとよい。リクエストに応答して、デバイスは、ブロック904、908、912にて示されているように、動作データを収集するとよく、ブロック906、910、914にて示されているように、データ電圧、電流、有効電力および無効電力データなどの運用データのうちの1つ、いくつかまたはすべてなどを送信するとよい。データスキャナは、ブロック926にて示されているように、運用データを収集するとよく、ブロック928にて示されているように、データを運用データストアへ送信するとよい。ブロック938にて示されているように、運用データストアは運用データを記憶するとよい。ブロック940にて示されているように、運用データストアはさらに、データのスナップショットをヒストリアンへ送信するとよく、ブロック942にて示されているように、ヒストリアンは、データのスナップショットを記憶するとよい。計器状態アプリケーションは、ブロック924に示されているように、計器データのリクエストを計器DCEdatacollectionengine:データ収集エンジンへ送信するとよく、その結果として計器DCEは、ブロック920にて示されているように、計器データ収集のリクエストを1つ以上の計器へ送信する。リクエストに応答して、この1つ以上の計器は、ブロック916にて示されているように、計器データを収集し、ブロック918にて示されているように、電圧データを計器DCEへ送信する。計器DCEは、ブロック922にて示されているように電圧データを収集して、ブロック928にて示されているようにデータをデータのリクエスタへ送信するとよい。計器状態アプリケーションは、ブロック930にて示されているように、計器データを受信し、ブロック932にて示されているように、それが単一値プロセスに関するか、電圧プロフィールグリッド状態に関するかを判断するとよい。単一値プロセスに関するものであれば、ブロック936にて示されているように、計器データはリクエストしているプロセスへ送信される。計器データが、後からグリッド状態を判断するために記憶されるものであれば、ブロック938にて示されているように、計器データは運用データストアに記憶される。ブロック940にて示されているように、運用データストアはさらに、データのスナップショットをヒストリアンへ送信して、ブロック942にて示されているように、ヒストリアンは、データのスナップショットを記憶する。図9はさらに、需要応答DRに関するアクションを示す。需要応答は、例えば電気の需要家にその消費を、緊急時、または市場価格に応じて削減させるなど、供給条件に応じて需要家の電気消費を管理するための動的需要メカニズムを指す。これは、実際に使用電力を削減することを伴っても、オンサイト発電を開始することによってもよく、オンサイト発電は、グリッドと並列接続されていても、されていなくてもよい。これは、同じタスクを実行するために継続的に、または当該タスクが実行されるときに必ず、より少ない電力を使用することを意味する、エネルギー効率とは異なると考えられる。需要応答では、1つ以上の制御システムを使用する需要家が、ユーティリティによるリクエストまたは市場価格条件に応じて負荷を制限するとよい。サービス明かり、機械、空調は、緊急の時間フレームの間、事前計画された負荷優先順位付けスキームに従って削減されるとよい。負荷制限の代替手段は、電力グリッドを補うための、電気のオンサイト発電である。逼迫した電気供給条件のもとでは、需要応答により、最高値および全般的な電気価格の変動が大幅に低減され得る。需要応答は、一般に、消費者が需要を減らすことを促し、それによって電気のピーク需要を減らすよう使用されるメカニズムを指すために使用される。電気システムは、一般に、ピーク需要それに加えてエラーおよび予期せぬイベントに備えた余裕に対応するような規模であり、ピーク需要が減れば、全体的な施設および資本コスト要件が緩和され得る。一方、発電容量の構成次第で、需要応答は、大量生産低需要のときに需要負荷を増やすためにも使用され得る。それによって、一部のシステムは、低需要および高需要または安値および高値の期間の間の裁定取引を行うためのエネルギー貯蔵を促すこともできる。システムにおいて、風力などの断続的な電力源の割合が増えるにつれて、需要応答は電気グリッドの効果的な管理にますます重要になると考えられる。ブロック954にて示されているように、DR状態アプリケーションは、DR利用可能容量をリクエストするとよい。続いて、ブロック948にて示されているように、DR管理システムは、1つ以上のDRホームデバイスからの利用可能容量をリクエストするとよい。この1つ以上のホームデバイスは、ブロック944にて示されているように、リクエストに応答して利用可能なDR容量を収集して、ブロック946にて示されているように、DR容量および応答データをDR管理システムへ送信するとよい。DR管理システムは、ブロック950にて示されているように、DR容量および応答データを収集して、ブロック952にて示されているように、DR容量および応答データをDR状態アプリケーションへ送信するとよい。DR状態アプリケーションは、ブロック956にて示されているように、DR容量および応答データを受信して、ブロック958にて示されているように、容量および応答データを運用データストアへ送信するとよい。ブロック938に示されているように、運用データストアはDR容量および応答データデータを記憶するとよい。ブロック940にて示されているように、運用データストアはさらに、データのスナップショットをヒストリアンへ送信するとよく、ブロック942にて示されているように、ヒストリアンは、データのスナップショットを記憶するとよい。ブロック974にて示されているように、変電所コンピュータは、変電所アプリケーションからのアプリケーションデータをリクエストするとよい。それに応答して、ブロック964にて示されているように、変電所アプリケーションは、変電所デバイスからのアプリケーションをリクエストするとよい。変電所デバイスは、ブロック960にて示されているように、アプリケーションデータを収集して、ブロック962にて示されているように、変電所デバイスにアプリケーションデータを送信するとよい電圧、電流、有効電力および無効電力データのうちの1つ、いくつかまたはすべてを含むとよい。変電所アプリケーションは、ブロック966にて示されているように、アプリケーションデータを収集して、ブロック968にて示されているように、アプリケーションデータをリクエスタ変電所コンピュータであってもよいへ送信するとよい。変電所コンピュータは、ブロック970にて示されているように、アプリケーションデータを受信して、ブロック972にて示されているように、アプリケーションデータを運用データストアへ送信するとよい。グリッド状態測定および運用データプロセスは、所定の時点でのグリッド状態およびグリッドトポロジを得ること、ならびにこの情報を他のシステムおよびデータストアに提供することを含み得る。サブプロセスは、1グリッド状態情報を測定および保存することこれは、前に説明した、グリッドに関連する運用データに関係する、2グリッド状態情報を他の解析アプリケーションへ送信することこれは、分析アプリケーションなどの他のアプリケーションがグリッド状態データにアクセスできるようにする、3グリッド状態スナップショットを接続性/運用データストアに維持することこれは、接続性/運用データストアのグリッド状態情報を適切なフォーマットで更新すること、ならびに或る時点でのグリッドトポロジを後の時点で得られるように、この情報を維持のためにヒストリアンへ転送することを可能にする、4デフォルトの接続性および現在のグリッド状態に基づき、或る時点でのグリッドトポロジを得ることこれは、下記でさらに詳しく説明するように、ヒストリアン内のグリッド状態の所定の時点でのスナップショットを、接続性データストア内のベース接続性に適用することによって、その時点でのグリッドトポロジを提供する、ならびに5リクエストに応じてグリッドトポロジ情報をアプリケーションに提供することを含むとよい。サブプロセス4に関しては、グリッドトポロジはリアルタイム、30秒前、1ヶ月前など、所定時間に関して得られるとよい。グリッドトポロジを再現するために、複数のデータベースが使用されてもよく、グリッドトポロジを再現するために複数のデータベース内のデータにアクセスするプログラム。1つのデータベースは、ベース接続性データを記憶するリレーショナルデータベースを含むとよい接続性データベース。接続性データベースは、ベースライン接続性モデルを判断するための、施工完了時のグリッドトポロジ情報を保持しているとよい。電力グリッド内の回路の追加または変更など例えば、電力グリッドに追加される追加のフィーダ回路、電力グリッドの改良に応じて、アセットおよびトポロジ情報が定期的にこのデータベースに対し更新されるとよい。接続性データベースは、変化しないことから静的と見なされてもよい。接続性データベースは、電力グリッドの構造に変更があれば変化するとよい。例えば、フィーダ回路の追加など、フィーダ回路に変更があれば接続性データベースが変化するとよい。接続性データベースの構造1800の一例は、図18A~Dに示されている階層モデルから得られるとよい。構造1800は、4つのセクションに分割されており、図18Aは左上のセクション、図18Bは右上のセクション、図18Cは左下のセクション、さらに図18Dは右下のセクションである。具体的には、図18A~Dは、ベースライン接続性データベースを表す抽象法である、エンティティ関係図の例である。図18A~Dの階層モデルは、電力グリッドを表すメタデータを保持するとよく、グリッドの様々なコンポーネントおよびコンポーネント間の関係を表すとよい。第2のデータベースは、動的データを記憶するために使用されるとよい。第2のデータベースは、非リレーショナルデータベースを含むとよい。非リレーショナルデータベースの一例は、時系列の非運用データならびに過去の運用データを記憶する、ヒストリアンデータベースを含み得る。ヒストリアンデータベースは、1タイムスタンプ、2デバイスID、3データ値および4デバイスステータスなどの一連のフラットレコードを記憶するとよい。さらに、記憶されるデータは圧縮されるとよい。このため、電力グリッド内の運用/非運用データが容易に記憶されるとよく、かなりの量のデータが利用可能であるにもかかわらず、管理可能であるとよい。例えば、5テラバイトオーダーのデータが、グリッドトポロジを再現するために用いられるよういつでもオンラインであってもよい。データは単純なフラットレコードで記憶されるため編成手法が用いられないなど、データの記憶における効率性が与えられる。下記でさらに詳しく説明するように、データは、タイムスタンプなどの特定のタグによりアクセスされてもよい。グリッドの様々な解析が、特定の時点のグリッドトポロジを入力として受信することを望み得る。例えば、電力品質、信頼性、アセット正常性などに関する解析が、グリッドトポロジを入力として使用し得る。グリッドトポロジを判断するために、接続性データベース内のデータにより定義されるベースライン接続性モデルがアクセスされるとよい。例えば、特定のフィーダ回路のトポロジが求められる場合、ベースライン接続性モデルは、電力グリッド内の特定のフィーダ回路内の様々なスイッチを定義するとよい。その後、特定のフィーダ回路内のスイッチの値を判断するために、ヒストリアンデータベースがアクセスされるとよい特定の時間に基づき。次に、特定時間の特定のフィーダ回路の表現を生成するために、プログラムが、ベースライン接続性モデルおよびヒストリアンデータベースからのデータを組み合わせるとよい。グリッドトポロジの判断のより複雑な例は、インタータイスイッチおよび区分スイッチを有する複数のフィーダ回路例えばフィーダ回路Aおよびフィーダ回路Bを含み得る。特定のスイッチインタータイスイッチおよび/または区分スイッチなどのスイッチ状態に応じて、フィーダ回路のセクションは、フィーダ回路Aまたはフィーダ回路Bに属し得る。グリッドトポロジを判断するプログラムは、特定の時間の接続性例えば、どの回路がフィーダ回路Aまたはフィーダ回路Bに属するかを判断するために、ベースライン接続性モデルおよびヒストリアンデータベース両方からのデータにアクセスするとよい。図10は、非運用データプロセスのフロー図1000を示す。ブロック1002にて示されているように、非運用抽出アプリケーションが、非運用データをリクエストするとよい。それに応答して、ブロック1004にて示されているように、データスキャナが非運用データを集めるとよく、それによって、ブロック1006、1008、1110にて示されているように、グリッドデバイス、変電所コンピュータおよびラインセンサーRTUなどの電力グリッド内の様々なデバイスが非運用データを収集するとよい。上記のように、非運用データは、温度、電力品質などを含むとよい。ブロック1012、1014、1116にて示されているように、グリッドデバイス、変電所コンピュータおよびラインセンサーRTUなど、電力グリッド内の様々なデバイスが、非運用データをデータスキャナへ送信するとよい。データスキャナは、ブロック1018にて示されているように、非運用データを収集して、ブロック1020にて示されているように、非運用データを非運用抽出アプリケーションへ送信するとよい。非運用抽出アプリケーションは、ブロック1022にて示されているように、非運用データを収集して、ブロック1024にて示されているように、収集した非運用データをヒストリアンへ送信するとよい。ヒストリアンは、ブロック1026にて示されているように、非運用データを受信し、ブロック1028にて示されているように、非運用データを記憶し、ブロック1030にて示されているように、非運用データを1つ以上の解析アプリケーションへ送信するとよい。図11は、イベント管理プロセスのフロー図1100を示す。データは、電力グリッド内の様々なイベントに基づき様々なデバイスから生成されて、イベントバス147を介して送信されるとよい。例えば、ブロック1102にて示されているように、計器データ収集エンジンは、電力供給停止/復旧通知情報をイベントバスへ送信するとよい。ブロック1104にて示されているように、ラインセンサーRTUは、故障メッセージを生成して、その故障メッセージをイベントバスへ送信するとよい。変電所は解析は、ブロック1106にて示されているように、故障および/または供給停止メッセージを生成するとよく、その故障および/または供給停止メッセージをイベントバスへ送信するとよい。ブロック1108にて示されているように、ヒストリアンは、信号挙動をイベントバスへ送信するとよい。さらに、様々なプロセスがイベントバス147を介してデータを送信するとよい。例えば、ブロック1110にて示されているように、図14にさらに詳しく説明されている故障インテリジェンスプロセスが、イベントバスを介して故障分析イベントを送信するとよい。ブロック1112にて示されているように、図13にさらに詳しく説明されている供給停止インテリジェンスプロセスが、イベントバスを介して供給停止イベントを送信するとよい。ブロック1114にて示されているように、イベントバスは様々なイベントを収集するとよい。さらに、複合イベント処理CEPサービスが、ブロック1120にて示されているように、イベントバスを介して送信されたイベントを処理するとよい。CEPサービスは、複数の同時の高速リアルタイムイベントメッセージストリームに対するクエリを処理するとよい。ブロック1118にて示されているように、CEPサービスによる処理の後、イベントデータはイベントバスを介して送信されるとよい。さらに、ブロック1116にて示されているように、ヒストリアンが、記憶用の1つ以上のイベントログを、イベントバスを介して受信するとよい。さらに、ブロック1122にて示されているように、イベントデータは、供給停止管理システムOMS、供給停止インテリジェンス、故障解析など、1つ以上のアプリケーションにより受信されるとよい。このように、イベントバスは、イベントデータをアプリケーションへ送信するとよく、それによって、データを他のデバイスまたは他のアプリケーションに利用可能にしないというサイロ問題を回避する。図12は、需要応答DRシグナリングプロセスのフロー図1200を示す。ブロック1244にて示されているように、DRが配電動作アプリケーションによりリクエストされるとよい。それに応答して、グリッド状態/接続性は、ブロック1202にて示されているように、DR利用可能性データを収集するとよく、ブロック1204にて示されているように、データを送信するとよい。配電動作アプリケーションは、ブロック1246にて示されているように、DR利用可能性最適化を、イベントバスを介してブロック12541つ以上のDR管理システムに配布するとよい。DR管理システムは、ブロック1272にて示されているように、DR情報および信号を1つ以上の需要家構内へ送信するとよい。この1つ以上の需要家構内は、ブロック1266にて示されているように、DR信号を受信し、ブロック1268にて示されているように、DR応答を送信するとよい。DR管理は、ブロック1274にて示されているように、DR応答を受信して、ブロック1276にて示されているように、動作データバス146、請求データベースおよびマーケティングデータベースのうちの1つ、いくつかまたはすべてにDR応答を送信するとよい。ブロック1284、1288にて示されているように、請求データベースおよびマーケティングデータベースは、応答を受信するとよい。動作データバス146も、ブロック1226にて示されているように、応答を受信して、ブロック1228にて示されているように、DR応答および利用可能容量をDRデータ収集へ送信するとよい。DRデータ収集は、ブロック1291にて示されているように、DR応答および利用可能容量を処理して、そのデータを、ブロック1294にて示されているように、動作データバスへ送信するとよい。ブロック1230にて示されているように、動作データバスは、DR利用可能性および応答を受信して、それをグリッド状態/接続性へ送信するとよい。ブロック1208にて示されているように、グリッド状態/接続性はデータを受信するとよい。受信されたデータは、グリッド状態データを判断するために使用されるとよく、それが動作データバスを介してブロック1220送信されるとよいブロック1206。ブロック1248にて示されているように、配電動作アプリケーションは、グリッド状態データDR最適化のためのイベントメッセージとしてを受信するとよい。ブロック1250にて示されているように、配電動作アプリケーションは、グリッド状態データならびにDR利用可能性および応答を使用して配電最適化を実行し、配電データを生成するとよい。配電データは、ブロック1222にて示されているように、動作データバスにより取得されるとよく、ブロック1240にて示されているように、接続性抽出アプリケーションへ送信されるとよい。運用データバスは、データを配電動作アプリケーションへ送信するとよくブロック1224、次に配電動作アプリケーションが、1つ以上のDR信号を1つ以上のDR管理システムへ送信するとよいブロック1252。イベントバスは、この1つ以上のDR管理システムそれぞれに関して信号を収集してブロック1260、DR信号を各DR管理システムへ送信するとよいブロック1262。次に、DR管理システムは上記のようにDR信号を処理するとよい。ブロック1214にて示されているように、通信動作ヒストリアンは、データをイベントバスへ送信するとよい。ブロック1212にて示されているように、通信動作ヒストリアンはさらに、生成ポートフォリオデータを送信するとよい。または、Ventyx登録商標などのアセット管理デバイスが、ブロック1232にて示されているように、仮想発電所VPP:virtualpowerplant情報をリクエストするとよい。動作データバスは、ブロック1216にて示されているように、VPPデータを収集して、ブロック1218にて示されているように、データをアセット管理デバイスへ送信するとよい。アセット管理デバイスは、ブロック1234にて示されているように、VPPデータを収集して、ブロック1236にて示されているように、システム最適化を実行して、ブロック1238にて示されているように、イベントバスへVPP信号を送信するとよい。イベントバスは、ブロック1256にて示されているように、VPP信号を受信して、ブロック1258にて示されているように、VPP信号を配電動作アプリケーションへ送信するとよい。その結果、配電動作アプリケーションは、上記のようにイベントメッセージを受信および処理するとよい。ブロック1278にて示されているように、接続抽出アプリケーションは、ブロック1290にて示されているようにマーケティングデータベースへ送信される新規需要家データを、抽出するとよい。ブロック1280にて示されているように、新規需要家データはグリッド状態/接続性へ送信されるとよく、その結果、ブロック1210にて示されているように、グリッド状態接続性は新たなDR接続性データを受信するとよい。オペレーターは、ブロック1242にて示されているように、適切な場合、1つ以上のオーバーライド信号を送信するとよい。オーバーライド信号は、配電動作アプリケーションへ送信されるとよい。オーバーライド信号は、ブロック1264にて示されているようにエネルギー管理システム、ブロック1282にて示されているように請求データベース、および/またはブロック1286にて示されているようにマーケティングデータベースへ送信されるとよい。図13は、供給停止インテリジェンスプロセスのフロー図1300を示す。様々なデバイスおよびアプリケーションが、ブロック1302、1306、1310、1314、1318にて示されているように、電力供給停止通知を送信し得る。ブロック1324にて示されているように、供給停止イベントはイベントバスにより収集され、ブロック1326にて示されているように、イベントバスは、複合イベント処理CEPへ供給停止イベントを送信するとよい。さらに、様々なデバイスおよびアプリケーションが、ブロック1304、1308、1312、1316、1320にて示されているように、電力復旧ステータスを送信し得る。CEPは、供給停止および復旧ステータスメッセージを受信しブロック1330、イベントを処理しブロック1332、イベントデータを送信するとよいブロック1334。供給停止インテリジェンスアプリケーションは、イベントデータを受信してブロック1335、グリッド状態および接続性データをリクエストするとよいブロック1338。運用データバスは、グリッド状態および接続性データのリクエストを受信してブロック1344、それを運用データストアおよびヒストリアンのうちの一方または両方へ転送するとよい。それに応答して、運用データストアおよびヒストリアンは、運用データバスを介してブロック1346供給停止インテリジェンスアプリケーションへブロック1340、グリッド状態および接続性データを送信するとよいブロック1352、1354。ブロック1342にて示されているように、グリッド状態および接続性データが、これが瞬時停電であったかどうかを示すかどうかが判断される。そうであれば、その瞬時停電が、運用データバスを介してブロック1348、記憶用に瞬時停電データベースへ送信されるブロック1350。そうでなければ、供給停止ケースが作成されブロック1328、供給停止ケースデータが、供給停止管理システムにより記憶および処理されるブロック1322。供給停止インテリジェンスプロセスは、供給停止を検出し、瞬時停電を分類してログを取り、供給停止の範囲を判断し、供給停止の主要因単数または複数を判断し、供給停止復旧を追跡し、供給停止イベントを発し、システムパフォーマンス指数を更新するとよい。図14は、故障インテリジェンスプロセスのフロー図1400を示す。ブロック1416にて示されているように、複合イベント処理は、1つ以上のデバイスからのデータをリクエストするとよい。例えば、ブロック1404にて示されているように、グリッド状態および接続性は、リクエストに応答して、グリッド状態および接続性データを複合イベント処理へ送信するとよい。同様に、ブロック1410にて示されているように、ヒストリアンは、リクエストに応答してリアルタイムスイッチ状態を複合イベント処理へ送信するとよい。さらに、ブロック1418にて示されているように、複合イベント処理は、グリッド状態、接続性データ、およびスイッチ状態を受信するとよい。ブロック1428にて示されているように、変電所解析は故障データをリクエストするとよい。ブロック1422、1424にて示されているように、故障データが、ラインセンサーRTU、および変電所コンピュータなど、様々なデバイスにより送信されるとよい。様々な故障データ、グリッド状態、接続性データ、およびスイッチ状態が、ブロック1430にて示されているように、イベント検出および特徴評価のために変電所解析へ送信されるとよい。イベントバスはさらに、イベントメッセージを受信してブロック1434、イベントメッセージを変電所解析へ送信するとよいブロック1436。ブロック1432にて示されているように、変電所解析はイベントのタイプを判断するとよい。ブロック1426にて示されているように、保護および制御変更イベントに関しては、変電所コンピュータが故障イベントメッセージを受信するとよい。その他すべてのタイプのイベントに関しては、イベントがイベントバスにより受信されブロック1438、複合イベント処理へ送信されるとよいブロック1440。複合イベント処理は、さらなる処理のためにイベントデータを受信するとよいブロック1420。同様に、グリッド状態および接続性は、ブロック1406にて示されているように、グリッド状態データを複合イベント処理へ送信するとよい。さらに、ブロック1414にて示されているように、共通情報モデルCIMウェアハウスがメタデータを複合イベント処理へ送信するとよい。複合イベント処理は、ブロック1420にて示されているように故障イベントメッセージを送信するとよい。イベントバスは、メッセージを受信してブロック1442、イベントメッセージを故障インテリジェンスアプリケーションへ送信するとよいブロック1444。故障インテリジェンスアプリケーションは、イベントデータを受信してブロック1432、ブロック1456にて示されているように、グリッド状態、接続性データ、およびスイッチ状態をリクエストするとよい。リクエストに応答して、故障インテリジェンスアプリケーションはグリッド状態および接続性データを送信するとよくブロック1408、ヒストリアンはスイッチ状態データを送信するとよいブロック1412。故障インテリジェンスは、データを受信してブロック1458、データを分析し、イベントデータを送信するブロック1460。イベントデータは、イベントバスにより受信されブロック1446、故障ログファイルへ送信されるとよいブロック1448。故障ログファイルは、イベントデータのログを取るとよいブロック1402。イベントデータはさらに、運用データバスにより受信されるとよくブロック1462、1つ以上のアプリケーションへ送信するブロック1464。例えば、図13に関して上記で説明した、供給停止インテリジェンスアプリケーションが、イベントデータを受信するとよいブロック1466。作業管理システムも、ブロック1468にて示されているように、作業命令という形でイベントデータを受信するとよい。さらに、ブロック1470にて示されているように、他のリクエストしているアプリケーションが、イベントデータを受信してもよい。故障インテリジェントプロセスは、グリッドデータを解釈して、グリッド内での現在の、および潜在的な故障についての情報を得ることを担当するとよい。具体的には、故障は、故障インテリジェントプロセスを使用して検出されるとよい。故障は、典型的には、ユーティリティの設備が機能しなくなったとき、または例えば垂れ下がった電線など、電流フローの代替パスがつくられたときにもたらされる短絡である。このプロセスは、典型的な故障典型的には従来の故障検出および保護設備であるリレー、ヒューズなどによって対処される、ならびに故障電流を使用して容易に検出することができないグリッド内の高インピーダンス故障を検出するために使用されるとよい。故障インテリジェンスプロセスはさらに、故障を分類およびカテゴリ化するとよい。これにより、故障が分類およびカテゴリ化されることが可能になる。現在、故障の体系的な編成および分類のための標準は存在しない。これに関して事実上の標準が確立され、実装されるとよい。故障インテリジェンスプロセスは故障をさらに特徴評価してもよい。故障インテリジェンスはさらに、故障の位置を判断するとよい。不平衡負荷、3相、2相および単相ラテラル、センサー/測定値の欠如、種々のタイプの故障、短絡の種々の原因、変化する負荷条件、複数のラテラルを備えた長いフィーダ、文書化されていないネットワーク構成など、配電システムの固有の特徴によりもたらされるその高い複雑性および困難性により、配電システムにおける故障の位置特定は難しいタスクであることもある。このプロセスにより、技術的に可能な限りの正確さで故障の位置を隔離するために、いくつかの技法を使用できるようになる。故障インテリジェンスはさらに、故障イベントを発するとよい。具体的には、このプロセスは、故障が検出、分類、カテゴリ化、特徴評価および隔離されると、故障イベントを作成してイベントバスへ発行するとよい。このプロセスはさらに、不具合がある中では典型的である、生イベントに基づく大量発生ではなく、個々の故障イベントを発するよう、故障の収集、フィルタリング、照合および重複除去を担当するとよい。最終的に、故障インテリジェンスは、イベントログデータベースに故障イベントのログを取るとよい。図15は、メタデータ管理プロセスのフロー図1500を示す。メタデータ管理プロセスは、ポイントリスト管理、通信接続性プロトコル管理、および構成要素命名翻訳、センサー較正係数管理、およびリアルタイムグリッドトポロジデータ管理を含むとよい。ブロック1502にて示されているように、ベース接続性抽出アプリケーションは、ベース接続性データをリクエストするとよい。地理情報システムGISは、リクエストを受信してブロック1510、データをベース接続性抽出アプリケーションへ送信するとよいブロック1512。ベース接続性抽出アプリケーションは、データを受信してブロック1504、データを抽出、変換およびロードしブロック1506、ベース接続性データを接続性データマートへ送信するとよいブロック1508。その後、ブロック1514にて示されているように、接続性データマートはデータを受信するとよい。接続性データマートは、グリッドのコンポーネントの電気的接続性情報を含むカスタムデータストアを含むとよい。図15に示されているように、この情報は、典型的には、グリッドを構成するコンポーネントの施工完了時の地理上の位置を保持する、ユーティリティの地理情報システムGISから得られるとよい。このデータストア内のデータは、グリッドのすべてのコンポーネント変電所、フィーダ、セクション、セグメント、ブランチ、tセクション、回路遮断器、リクローザー、スイッチなど、基本的にすべてのアセットについての階層情報を記述する。このデータストアは、施工完了時のアセットおよび接続性情報を有するとよい。メタデータ抽出アプリケーションは、ブロック1516にて示されているように、グリッドアセットに関するメタデータをリクエストするとよい。メタデータデータベースは、リクエストを受信してブロック1524、メタデータを送信するとよいブロック1526。メタデータ抽出アプリケーションは、メタデータを受信してブロック1518、メタデータを抽出、変換およびロードしブロック1520、メタデータをCIMデータウェアハウスへ送信するとよいブロック1522。次にCIM共通情報モデルデータウェアハウスは、ブロック1528にて示されているようにデータを記憶するとよい。CIMは、ユーティリティデータを表すためのユーティリティ標準フォーマットを規定するとよい。INDEスマートグリッドは、ユーティリティ標準フォーマットで、スマートグリッドからの情報の利用可能性を促進するとよい。さらに、CIMデータウェアハウスは、INDE特有のデータの、規定のユーティリティ標準フォーマットなど1つ以上のフォーマットへの変換を促進するとよい。ブロック1530にて示されているように、アセット抽出アプリケーションは、新たなアセットに関する情報をリクエストするとよい。アセットレジストリは、リクエストを受信してブロック1538、新たなアセットに関する情報を送信するとよいブロック1540。アセット抽出アプリケーションは、新たなアセットに関する情報を受信してブロック1532、データを抽出、変換およびロードしブロック1534、新たなアセットに関する情報をCIMデータウェアハウスへ送信するとよいブロック1536。ブロック1542にて示されているように、DR接続性抽出アプリケーションは、DR接続性データをリクエストするとよい。ブロック1548にて示されているように、運用データバスは、DR接続性データリクエストをマーケティングデータベースへ送信するとよい。マーケティングデータベースはリクエストを受信してブロック1554、DR接続性データを抽出、変換、ロードしブロック1556、DR接続性データを送信するとよいブロック1558。運用データバスは、DR接続性データをDR接続性抽出アプリケーションへ送信するとよいブロック1550。DR接続性抽出アプリケーションは、DR接続性データを受信してブロック1544、DR接続性データを、運用データバスを介してブロック1552グリッド状態および接続性DMへ送信するブロック1546とよく、グリッド状態および接続性DMはDR接続性データを記憶するブロック1560。図16は、通知エージェントプロセスのフロー図1600を示す。ブロック1602にて示されているように、通知契約者はウェブページにログインするとよい。通知契約者は、ブロック1604にて示されているように、シナリオ監視リストパラメータを作成/変更/削除するとよい。ブロック1608にて示されているように、ウェブページは作成/変更/削除されたシナリオ監視リストを記憶するとよく、ブロック1612にて示されているように、CIMデータウェアハウスがデータタグのリストを作成するとよい。名称翻訳サービスが、ヒストリアンのデータタグを翻訳してブロック1614、データタグを送信するとよいブロック1616。ウェブページは、運用データバスを介してデータタグリストを送信するとよくブロック1610、運用データバスがデータタグリストを受信してブロック1622、それを通知エージェントへ送信するブロック1624。通知エージェントは、リストを取得してブロック1626、リストを検証および統合しブロック1628、通知シナリオに関してヒストリアンをチェックするブロック1630。シナリオにマッチする例外が発見されるとブロック1632、通知が送信されるブロック1634。イベントバスは通知を受信しブロック1618、それを通知契約者へ送信するブロック1620。ブロック1606にて示されているように、通知契約者は、テキスト、電子メール、電話など、好みの媒体を介して通知を受信するとよい。図17は、計器データ収集AMIプロセスのフロー図1700を示す。電流コレクタは、ブロック1706にて示されているように、住居計器データをリクエストするとよい。1つ以上の住居計器が、リクエストに応答して住居計器データを収集しブロック1702、住居計器データを送信するとよいブロック1704。電流コレクタは、住居計器データを受信しブロック1708、それを運用データバスへ送信するとよいブロック1710。計器データ収集エンジンは、ブロック1722に示されているように、商業および工業用計器データをリクエストするとよい。1つ以上の商業および工業用計器が、リクエストに応答して商業および工業用計器データを収集しブロック1728、商業および工業用計器データを送信するとよいブロック1730。計器データ収集エンジンは、商業および工業用計器データを受信してブロック1724、それを運用データバスへ送信するとよいブロック1726。運用データバスは、住居、商業および工業用計器データを受信してブロック1712、データを送信するとよいブロック1714。データは、計器データリポジトリデータベースにより受信されてもブロック1716、または請求プロセッサにより受信されてもよくブロック1718、次に、CRMcustomerrelationshipmanagement:顧客関係管理システムなどの1つ以上のシステムへ送信されるとよいブロック1720。可観測性プロセスはさらに、リモートアセット監視プロセスを含むとよい。電力グリッド内のアセットの監視は、困難なものとなるかもしれない。電力グリッドには種々の部分があると考えられ、その一部は非常に高価である。例えば、変電所は電力変圧器100万ドル以上かかる、および回路遮断器を含むと考えられる。ユーティリティは、アセットの分析およびアセット使用の最大化の点では、ほとんど何もしないことが多い。代わりに、ユーティリティの焦点は、典型的には、需要家への電力が確実に保たれるようにすることであった。具体的には、ユーティリティの焦点は、定期点検典型的には所定の間隔で生じると考えられるまたはイベント駆動型の保守故障がグリッドの一部分で生じた場合に発生すると考えられるに合わせられていた。典型的な定期点検またはイベント駆動型の保守の代わりに、リモートアセット監視プロセスは、状態監視保守に焦点を合わせるとよい。具体的には、電力グリッドの一部または全部を評価できれば定期的または継続的になど、電力グリッドの正常性が改善され得る。上記のように、電力グリッドの様々な部分でデータが生成されて、中央局に伝送されるまたはそれによるアクセスが可能であるとよい。次にデータは、グリッドの正常性を判断するために、中央局によって使用されるとよい。グリッドの正常性の分析とは別に、中央局は利用監視を実行するとよい。典型的には、電力グリッド内の設備は、かなりの安全マージンを用いて動作させられている。この理由の1つは、ユーティリティ企業はもともと保守的であり、エラーの大きなマージンの中で需要家に対し電力を保とうとするということである。このもう1つの理由は、グリッドを監視するユーティリティ企業が、電力グリッド内の一設備が利用されている程度を認識していないこともあるということである。例えば、電力会社が特定のフィーダ回路によって送電している場合、電力会社は、送電された電力がフィーダ回路の限界に近い例えば、フィーダ回路が過熱するかもしれないかどうかを知る手段は有しないと考えられる。これが理由で、ユーティリティ企業は、電力グリッドの1つ以上の部分を十分に活用していない可能性がある。さらに、電力グリッドに対する負荷が増大してきている例えば消費電力量が増えてきているため、ユーティリティは典型的に、かなりの金額を費やして電力グリッドに容量を追加する。ユーティリティの無知が原因で、ユーティリティは不必要に電力グリッドを改良することになる。例えば、最大容量近くで動作してはいないフィーダ回路が、それにもかかわらず導体を取り替えること例えばより大きなワイヤがフィーダ回路に取り付けられるによって改良されることも、または追加のフィーダ回路が取り付けられることもある。この費用だけでも相当なものである。リモートアセット監視プロセスは、1グリッドの1つ以上の部分の現在のアセット正常性を分析する、2グリッドの1つ以上の部分の将来のアセット正常性を分析する、3グリッドの1つ以上の部分の利用を分析するなど、電力グリッドの様々な側面を監視するとよい。まず、1つ以上のセンサーが、グリッドの特定部分の現在の正常性を判断するために、測定を行ってリモートアセット監視プロセスへ伝送するとよい。例えば、電力変換に関するセンサーは、変圧器上の溶解ガスを測定することによってその正常性のインジケータを提供するとよい。リモートアセット監視プロセスは次に、分析ツールを使用して、グリッドの特定部分電力変換が正常か正常でないかなどを判断するとよい。グリッドの特定部分が正常でなければ、そのグリッドの特定部分が修理されるとよい。さらに、リモートアセット監視プロセスは、グリッドの各部分の将来のアセット正常性を予想するために、グリッドの各部分から生成されたデータを分析するとよい。電気コンポーネントに対するストレスをもたらすものは複数ある。ストレス要因は、必ずしも一定ではなく、断続的であることもある。センサーは、電力グリッドの特定部分に対するストレスのインジケータを提供するとよい。リモートアセット監視プロセスは、センサーデータにより示されるストレス測定値のログを取るとよく、電力グリッドのその部分の将来の正常性を予想するために、ストレス測定値を分析するとよい。例えば、リモートアセット監視プロセスは、グリッドの特定部分がいつ機能しなくなる可能性があるかを予想するために傾向分析を使用するとよく、グリッドの特定部分が機能しなくなる可能性がある時点より前またはそれと同時に、保守をスケジュールするとよい。このように、リモートアセット監視プロセスは、グリッドの特定部分の寿命を予想し、ひいてはグリッドの当該部分の寿命が短すぎるかどうか例えば、グリッドの当該部分の消耗が速すぎるかを判断するとよい。さらに、リモートアセット監視プロセスは、電力グリッドをよりよく管理するために、電力グリッドの一部の利用を分析するとよい。例えば、リモートアセット監視プロセスは、フィーダ回路の稼働容量を判断するためにフィーダ回路を分析するとよい。このフィーダ回路の例では、リモートアセット監視プロセスが、フィーダ回路は現在70で動作させられていると判断してもよい。リモートアセット監視プロセスはさらに、許容範囲の安全マージンをなお保ちながら、特定のフィーダ回路がより高い割合90などで動作できると勧めてもよい。したがって、リモートアセット監視プロセスは、単に利用を分析することによって、容量の効果的な増加を可能にし得る。特定の技術アーキテクチャを判断する手順INDE参照アーキテクチャの構成要素のうちの1つ、いくつかまたはすべてを使用するとよい特定の技術アーキテクチャを判断するには、様々な手順がある。手順は、複数のステップを含むとよい。第1に、ユーティリティの現状のドキュメンテーションの生成、およびスマートグリッドに移行するための準備評価のために、ベースラインステップが実行されるとよい。第2に、将来の状態、およびこの状態に達するための詳しい要件の定義を生成するために、要件定義ステップが実行されるとよい。第3に、測定、監視および制御を含むスマートグリッドを実現するソリューションアーキテクチャコンポーネントの定義を生成するために、ソリューション開発ステップが実行されるとよい。INDEアーキテクチャの場合、これには、測定デバイス、データをデバイスからINDECORE120アプリケーションへ渡す通信ネットワーク、データを維持しそれに反応するINDECORE120アプリケーション、データを解釈する分析アプリケーション、測定および解釈されたデータをモデル化するデータアーキテクチャ、データおよび情報をINDEおよびユーティリティシステムの間で交換するための統合アーキテクチャ、様々なアプリケーションおよびデータベースを実行する技術インフラストラクチャ、ならびに業界標準の移植可能且つ効率的なソリューションを可能にするために従うとよい標準が含まれ得る。第4に、主要パフォーマンスインジケータ、およびスマートグリッドと、システムパフォーマンスを測定して所望のパフォーマンス係数に照らして評価する能力の実装との成功要因の定義を生成するために、価値モデリングが実行されるとよい。上記の開示は、ステップ3のアーキテクチャ開発の側面に関係する。図19は、ブループリントの進展フロー図の例を示す。具体的には、図19は、スマートグリッドの要件を定義するために取り組まれるとよいステップ、およびスマートグリッドの実装のために実行されるとよいステップのプロセスフローを示す。スマートグリッド開発プロセスは、スマートグリッド構想開発から始まるとよく、これがプロジェクトの全体的な目的の概要を明らかにし、それがスマートグリッドロードマッププロセスにつながるとよい。ロードマッププロセスは、ブループリントおよび価値モデリングにつながるとよい。ブループリントは、ユーティリティの事業全体を背景として、スマートグリッドの定義に対し系統的手法を提供するとよい。ブループリントは、全体的なロードマップを含むとよく、これがベースラインおよびシステム評価BASE:baselineandsystemsevaluation、ならびに要件定義および解析選択RDAS:requirementsdefinitionandanalyticsselectionにつながるとよい。RDASプロセスは、ユーティリティの特定のスマートグリッドの詳細な定義を作成するとよい。BASEプロセスは、スマートグリッド能力をサポートするシステム、ネットワーク、デバイスおよびアプリケーションの観点からユーティリティの出発点を確立するとよい。プロセスの第1部分は、グリッドのシステムインベントリを開発することであり、これは、グリッド構造発電、送電線、送電変電所、副送電線、配電変電所、配電フィーダ、電圧階級など、グリッドデバイススイッチ、リクローザー、コンデンサ、調整器、電圧降下補償器、フィーダインタータイなど、変電所オートメーションIED、変電所LAN、計測手段、ステーションRTU/コンピュータなど、配電オートメーションコンデンサおよびスイッチの制御、故障隔離および負荷ロールオーバー制御、LTC調整システム、DMS、需要応答管理システムなど、ならびにグリッドセンサーセンサータイプ、量、用途、ならびに配電グリッド上、送電線上および変電所内の総数などなどを含むとよい。インベントリが完成すると、上位スマートグリッド準備モデルに照らしてユーティリティの評価が作成されるとよい。現状のデータフローモデルおよびシステム図も作成されるとよい。アーキテクチャ構成ARC:architectureconfigurationプロセスは、BASEプロセスからの情報、RDASプロセスおよびINDE参照アーキテクチャからの要件および制約を組み合わせて、ユーティリティの特定のニーズに合致し、適切なレガシーシステムを活用し、ユーティリティに存在する制約に従う技術アーキテクチャを作り出すことによって、ユーティリティの初期スマートグリッド技術アーキテクチャを開発するとよい。INDE参照アーキテクチャの使用は、カスタムアーキテクチャを考案する必要を回避するとよく、蓄積された経験およびベストプラクティスが、確実にソリューションの開発に応用されるようにする。さらに、再利用可能なスマートグリッドアセットをソリューションが確実に最大限使用できるようにするとよい。センサーネットワークアーキテクチャ構成SNARC:sensornetworkarchitectureconfigurationプロセスは、スマートグリッドサポートのための分散型センサーネットワークのアーキテクチャを定義する一連の決定を行うためのフレームワークを提供するとよい。フレームワークは、センサーネットワークアーキテクチャの特定の側面にそれぞれが向かう、一連の決定木として構築されるとよい。決定が下されると、センサーネットワークアーキテクチャ図が作成されるとよい。Tセクション再帰によるセンサー配分SATSECTR:sensorallocationviaT-sectionrecursionプロセスは、費用制約に従って、所定レベルの可観測性を獲得するために配電グリッド上にいくつのセンサーが配置されるべきかを判断するためのフレームワークを提供するとよい。このプロセスはさらに、センサーのタイプおよび位置を決定するとよい。ソリューション構成要素評価およびコンポーネントテンプレートSELECT:solutionelementevaluationandcomponentstemplateプロセスは、ソリューションコンポーネントタイプの評価のためのフレームワークを提供するとよく、各コンポーネントクラスの設計テンプレートを提供する。テンプレートは、ソリューション構成要素それぞれに関する仕様の参照モデルを含むとよい。こうしたテンプレートは、次に、ベンダーの見積もりをリクエストしてベンダー/製品評価をサポートするために使用されるとよい。アプリケーションおよびネットワークの改良計画UPLAN:upgradeplanningforapplicationsandnetworksプロセスは、既存のユーティリティシステム、アプリケーションおよびネットワークの、スマートグリッドソリューションに統合する準備を整えるための改良計画の開発を提供するとよい。リスク評価および管理計画RAMP:riskassessmentandmanagementplanningプロセスは、ARCプロセスにおいて作成されたスマートグリッドソリューションの特定の構成要素に関連するリスクの評価を提供するとよい。UPLANプロセスは、特定されたリスク要素のレベルまたはリスクを評価し、ユーティリティが増築に尽力する前にリスクを軽減するための行動計画を提供するとよい。変化分析および管理計画CHAMP:changeanalysisandmanagementplanningプロセスは、スマートグリッド投資の価値を実現するためにユーティリティに必要と考えられるプロセスおよび組織変更を分析するとよく、こうした変更をスマートグリッドの展開と同期した形で実行するための上位管理計画を提供するとよい。CHAMPプロセスは、ブループリントの生成をもたらすとよい。価値モデリングプロセスにおけるロードマップは、価値メトリクスを特定することにつながるとよく、これが費用および利益の推定につながるとよい。推定は、レートケースおよびビジネスケースなど1つ以上のケースの構築につながるとよく、これが次にケースクローズにつながるとよい。ブループリントおよび価値モデリングの出力は、承認を受けるためにユーティリティへ送信されるとよく、これが、ユーティリティシステムの改良ならびにスマートグリッドの展開およびリスク削減アクティビティにつながるとよい。この後、グリッドが設計、構築およびテストされ、続いて動作させられるとよい。図21は、電気ユーティリティシステムなどのユーティリティシステム用に構成された別の例示のスマートグリッドシステム2100を示すブロック図である。一実施形態では、スマートグリッドシステム2100は、電力、水道、天然ガスなどのユーティリティ使用に関するデータを測定および伝送するよう構成されているとよい複数の計器2102を含むとよい。グリッド2100は、ネットワーク2108にそれぞれ接続されたユーザステーション2104および管理者ステーション2106を含むとよい。ユーザステーション2104は、プロセッサおよびメモリを有するコンピュータを含み、データを取得するため、動作を制御するため許可を受けて、またはその他任意の情報もしくは制御アクティビティにおいてグリッド2100を使用するために、ユーザがグリッド2100と相互作用することを可能にするとよい。各管理者ステーション2106は、プロセッサおよびメモリを含むとよく、グリッド2100全体にわたり情報のフローを管理および保護するためにITの職務のグリッド管理者によって使用されるとよい。以下の表6は、スマートグリッド2100の様々な機能コンポーネントを説明する。表6:代わりのスマートグリッド構成コンポーネント図1に関して説明したように、CEPコンソール2190は、CEP処理バス147と同様に動作するとよい。一例では、CEPコンソール2190は、SIEM2194とともに動作して、SIEM194に提供されて残存特徴評価メッセージ2012の生成を可能にするとよい残存リスクイベントメッセージ2010を生成するよう構成されているとよい。図22は、図1に示されたものなどのスマートグリッドの運用フロー図である。複合イベント処理バス147は、非従来型のセキュリティデータを含むとよい非ITデータ2000を受信するとよい2200。受信されたデータ2000は、データフィルタモジュール2002によってフィルタリングまたは前処理されるとよい2202。前処理は、複数のリスク関係イベントのうちの1つに対する関連性の所定のレベルに満たない、CEPバス147内の非ITデータを、無視することを含むとよい。ルールエンジンモジュール2004は、フィルタリングされたデータ2003にルールの特定のセットを適用して、悪意のあるアクティビティによってイベントが引き起こされている確率レベルを判断するとよい2204。一実施形態において、ルールエンジン2004は、過去相関モジュール2006にアクセスして、当該のアクティビティが悪意のあるアクティビティ以外の原因による可能性が低いかどうかを検証するとよい2206。過去相関モジュール2006からの過去データに基づき、ルールエンジン2004は、残存リスクイベントメッセージ2008を生成して、それをSIEM162に提供するとよい2208。SIEM162は、ITイベントデータ2010も受信するとよい2210。SIEM162は、残存リスクイベントメッセージ2008およびITイベントデータ2010に基づいて、リスク特徴評価メッセージ2012を生成するとよく2212、これは、INDEまたはそのほか特定の構成を実装するスマートグリッドの、ネットワーク動作を監視するものによって、さらに検査されてもよい。この技術革新の様々な実施形態について記載してきたが、当業者には当然のことながら、さらに多くの実施形態および実装が、この技術革新の範囲内で可能である。したがって、この技術革新は、添付の特許請求の範囲およびその等価物に照らして以外には、制限されないものとする。"