"電力グリッドの少なくとも一部を管理し、複数の計器データ管理システムおよび複数のヘッドエンドシステムと通信する、中央電力グリッド局であって、前記計器データ管理システムは、コマンドを生成し、前記ヘッドエンドシステムは、1つ以上の計器と通信し、前記中央電力グリッド局は、複数の入力コネクタルーチンおよび複数の出力コネクタルーチンを含むゲートウェイレイヤであって、前記複数の入力コネクタルーチンは、前記中央電力グリッド局へデータを送信する複数のソースシステムのそれぞれと通信するための独立した少なくとも1つの入力コネクタルーチンを含み、前記ソースシステムは、前記中央電力グリッド局へデータを送信する前記複数の計器データ管理システムまたは前記複数のヘッドエンドシステムを含み、前記複数の出力コネクタルーチンは、複数のターゲットシステムのそれぞれと通信するための独立した少なくとも1つの出力コネクタルーチンを含み、前記ターゲットシステムは、前記中央電力グリッド局からデータを受信する前記複数の計器データ管理システムまたは前記複数のヘッドエンドシステムを含む、前記ゲートウェイレイヤと、前記ゲートウェイレイヤと通信するコアレイヤであって、前記複数のソースシステムから前記複数のターゲットシステムへの通信の1対1変換を実行する複数のコアアダプタを含む、前記コアレイヤと、を含む中央電力グリッド局。前記ソースシステムは、前記複数の計器データ管理システムを含み、前記ターゲットシステムは、前記複数のヘッドエンドシステムを含む、請求項1に記載の中央電力グリッド局。前記中央電力グリッド局へ送信される前記データは、前記複数の計器データ管理システムにより送信される接続/切断コマンドを含む、請求項2に記載の中央電力グリッド局。前記中央電力グリッド局へ送信される前記データは、前記複数の計器データ管理システムにより送信されるオンデマンド計器読み取りコマンドを含む、請求項2に記載の中央電力グリッド局。前記複数の入力コネクタルーチンは、前記複数の計器データ管理システムと通信するための独立した複数の入力コネクタルーチンを含み、前記複数の出力コネクタルーチンは、前記複数のヘッドエンドシステムと通信するための独立した複数の出力コネクタルーチンを含む、請求項2に記載の中央電力グリッド局。前記計器データ管理システムのそれぞれは、独立した複数の入力コネクタルーチンに関連し、前記ヘッドエンドシステムのそれぞれは、独立した複数の出力コネクタルーチンに関連する、請求項5に記載の中央電力グリッド局。前記計器データ管理システムのそれぞれに関連する前記独立した複数の入力コネクタルーチンは、異なるネットワークプロトコルを含む、請求項6に記載の中央電力グリッド局。前記異なるネットワークプロトコルは、ファイル転送プロトコルFTP、javaメッセージサービスJMSおよびハイパーテキスト転送プロトコルHTTPから成る群から選択される、請求項7に記載の中央電力グリッド局。前記複数の入力コネクタルーチンは、前記複数のヘッドエンドシステムのそれぞれと通信するための独立した少なくとも1つの入力コネクタルーチンをさらに含み、前記複数の出力コネクタルーチンは、前記複数の計器データ管理システムのそれぞれと通信するための少なくとも1つの出力コネクタルーチンをさらに含む、請求項5に記載の中央電力グリッド局。前記ヘッドエンドシステムのそれぞれは、独立した複数の入力コネクタルーチンに関連し、前記計器データ管理システムのそれぞれは、独立した複数の出力コネクタルーチンに関連する、請求項9に記載の中央電力グリッド局。前記ソースシステムは、前記複数のヘッドエンドシステムを含み、前記ターゲットシステムは、前記複数の計器データ管理システムを含む、請求項1に記載の中央電力グリッド局。前記中央電力グリッド局へ送信される前記データは、前記複数のヘッドエンドシステムにより送信される定期的な計器読み取りを含む、請求項11に記載の中央電力グリッド局。前記複数の入力コネクタルーチンは、前記複数のヘッドエンドシステムと通信するための独立した複数の入力コネクタルーチンを含み、前記複数の出力コネクタルーチンは、前記複数の計器データ管理システムと通信するための独立した複数の出力コネクタルーチンを含む、請求項11に記載の中央電力グリッド局。前記中央電力グリッド局は、前記ゲートウェイレイヤと前記コアレイヤとの間をインターフェース接続するコネクタサービスインターフェースレイヤをさらに含み、前記コネクタサービスインターフェースレイヤは、前記ゲートウェイレイヤによる通信の受信に応答して、前記コアレイヤを呼び出す、請求項1に記載の中央電力グリッド局。前記コアアダプタは、前記複数の前記ソースシステムのそれぞれから前記複数のターゲットシステムのそれぞれへの通信の1対1変換を実行するようさらに構成されている、請求項1に記載の中央電力グリッド局。前記ソースシステムは、前記複数の計器データ管理システムを含み、前記ターゲットシステムは、前記複数のヘッドエンドシステムを含み、前記コアアダプタは、前記複数の前記計器データ管理システムのそれぞれから前記複数のヘッドエンドシステムのそれぞれへの通信の1対1変換を実行するよう構成されている、請求項15に記載の中央電力グリッド局。前記コアアダプタは、前記複数の前記ヘッドエンドシステムのそれぞれから前記複数の計器データ管理システムのそれぞれへの通信の1対1変換を実行するようさらに構成されている、請求項16に記載の中央電力グリッド局。実質的に、添付の図面に関して記載され示されたとおりのシステムおよび方法。電力ユーティリティシステムなどのシステムの中央管理局centralmanagementauthorityが開示される。中央管理局は、複数の計器データ管理システムおよび複数のヘッドエンドシステムと通信し、計器データ管理システムは、コマンドを生成し、ヘッドエンドシステムは、1つ以上の計器1つ以上のスマート計器などと通信する。中央管理局を含みスマートグリッドを管理し得るアーキテクチャの一例は、インテリジェントネットワークデータエンタープライズ以下、INDEIntelligentNetworkDataEnterpriseと呼ぶ参照アーキテクチャである。中央管理局は、ゲートウェイレイヤおよびコアレイヤを含む。ゲートウェイレイヤは、複数の入力コネクタルーチンinputconnectorroutineおよび複数の出力コネクタルーチンoutputconnectorroutineを含む。複数の入力コネクタルーチンは、中央管理局へデータを送信する複数のソースシステム接続/切断コマンドを中央管理局から送信する計器データ管理システムなどのそれぞれと通信するための独立した少なくとも1つの入力コネクタルーチンを含む。複数の出力コネクタルーチンは、中央管理局から送信されたデータを受信する複数のターゲットシステム接続/切断コマンドを中央管理局から受信するヘッドエンドシステムなどのそれぞれと通信するための独立した少なくとも1つの出力コネクタルーチンを含む。中央管理局のコアレイヤは、複数のコアアダプタを含み、コアアダプタは、複数のヘッドエンドシステムに対するコマンドを生成する複数の計器データ管理システムからの通信の1対1変換を実行する。以下の図面および詳細な説明を検討すると、当業者には、ほかのシステム、方法、特徴および利点が明らかであるか、または明らかとなるであろう。そのようなさらなるシステム、方法、特徴および利点はすべて、本記載の中に含まれ、本発明の範囲内にあり、添付の特許請求の範囲により保護されるものとする。概要として、以下に記載される好適な実施形態は、電力グリッドを管理する方法およびシステムに関する。特定の側面は電力グリッドの中央管理の構造上および/または機能上の能力に関する。米国特許出願第12/378,102号米国特許出願公開第2009-0281674A1号として公開、米国特許出願第12/378,091号米国特許出願公開第2009-0281673A1号として公開および国際出願PCT/US2009/000888号国際公開第2009/136975号として公開に開示されているように、インテリジェントネットワークデータエンタープライズINDEは、スマートグリッド統合プラットフォームであり、INDEは、高度に拡張可能で構成可能なアプリケーション統合ソリューションを提供し、ユーティリティ企業によって広く使用され得る高度計測インフラストラクチャ、需要応答、故障供給停止インテリジェンス、変電所解析などの組み込みのコアスマートグリッドビジネスプロセスを有する。INDEアーキテクチャは、コアレイヤおよびゲートウェイレイヤに分割され、INDEコアは、インテリジェントサービスルーティング、同期および非同期サービス呼び出し、データ変換ならびに監査能力などの特定のサービスを提供し、INDEゲートウェイは、広く使用されている産業通信プロトコルを用いて構築されるとよいアプリケーションコネクタサービスを提供する。例えば、INDEゲートウェイは、複数の入力コネクタルーチンおよび複数の出力コネクタルーチンを含むとよく、複数の入力コネクタルーチンは、複数の計器データ管理MDMシステムのそれぞれと通信するための独立した入力コネクタルーチンを含み、複数の出力コネクタルーチンは、複数のヘッドエンドシステムのそれぞれと通信するための独立した出力コネクタルーチンを含む。INDEコアとINDEゲートウェイとの分離は、既知および未知のシステムに対するINDEアーキテクチャのよりよい適応、よりよい拡張性およびよりよいセキュリティを含むがこれらに限定されない、いくつかの利点を提供する。上位アーキテクチャ50の例が、図1に開示されている。図1に示されているように、INDEコア50は、INDEゲートウェイ60から独立している。さらに、INDEゲートウェイ60は、INDEコア50と、ソースシステムソースシステム165およびソースシステム270などならびにターゲットシステムターゲットシステム175およびターゲットシステム280などとのインターフェースを提供する。図1は、2つのソースシステムおよび2つのターゲットシステムを示す。しかし、より少ないまたはより多いソースシステムおよびターゲットシステムが予想される。下記でさらに詳しく説明するように、INDEゲートウェイは、様々なソースおよびターゲットシステムを接続するコネクタレイヤを含む。ソースシステムは、情報のリクエストまたはアクションのコマンドを送信し、ターゲットシステムは、情報のリクエストに応答するか、またはコマンドに基づいて動作する。コマンドの一例は、計器における切断/再接続アクションを含んでもよく、MDMシステムにより生成され得る。MDMシステムは、データ収集および通信システム自動計器読み取りAMR:automatedmeterreadingおよび高度計測インフラストラクチャAMI:advancedmeteringinfrastructureを含む、ならびに計器データ管理および関連のソフトウェアアプリケーションのうちの1つ以上に関する機能性を含むとよい。典型的なユーティリティシステムには、複数のMDMシステムがあることもあり、その結果、いくつかの異なるMDMシステムのうちの1つがソースシステムとして機能し得る。商業用のMDMシステムの例には、LodeStarおよびItronがある。さらに、異なるMDMシステムが異なるベンダーから出ていて、異なるフォーマットに従うこともある。このため、コマンド内のデータは、同様の情報スマート計器のIDおよび接続/切断コマンドなどを含むのに、異なるフォーマットであることもある。例えば、コマンドは、ファイル転送プロトコルFTP:filetransferprotocol、javaメッセージサービスJMS:javamessageserviceおよびハイパーテキスト転送プロトコルHTTP:hypertexttransferprotocolなどの、いくつかの異なるネットワークプロトコルのうちの1つに基づき送信され得る。FTPは、ファイルを1つのホストから別のホストへ、インターネットなどのTCP/IPベースのネットワーク上でコピーするために使用され得る標準ネットワークプロトコルである。FTPは、クライアントとサーバアプリケーションとの間に別々の制御およびデータ接続を利用するクライアント-サーバアーキテクチャ上に構築され、異なるエンドホスト構成すなわちオペレーティングシステム、ファイル名の問題が解決される。FTPは、ユーザベースのパスワード認証または匿名ユーザアクセスとともに使用される。JMSAPIは、2つ以上のクライアント間でメッセージを送信するためのJavaメッセージ指向ミドルウェアMOM:MessageOrientedMiddlewareAPIである。JMSは、Javaプラットフォームエンタープライズエディションの一部であり、JavaコミュニティプロセスのもとでJSR914として開発された仕様により定義されている。これは、Java2プラットフォームエンタープライズエディションJ2EE:Java2Platform,EnterpriseEditionに基づくアプリケーションコンポーネントがメッセージを作成、送信、受信および読み取りできるようにするメッセージング標準である。分散したアプリケーションの種々のコンポーネント間の通信が、疎結合されること、信頼性を持つこと、および非同期となることを可能にする。最後に、HTTPは、分散型、連携型のハイパーメディア情報システムのためのアプリケーションレイヤプロトコルである。コマンド種々のネットワークプロトコルのうちの任意の1つを介して送信されるは、ヘッドエンドシステムにルーティングされるとよく、ヘッドエンドシステムは、ホームエリアネットワークHAN:homeareanetworkに設置された計器に切断/再接続アクションを伝送する。この場合もやはり、典型的なユーティリティシステムには、SecureまたはCurrentなどの複数のヘッドエンドシステムがあることもあり、その結果、いくつかの異なるヘッドエンドシステムのうちの1つがターゲットシステムとして機能し得る。別々のヘッドエンドシステムは、別々のカテゴリの計器と通信し得る。例えば計器は、工業用計器、家庭用計器、住宅用計器、車両関係の計器などに基づきカテゴリ化され得る。別々のカテゴリの計器は、別々のヘッドエンドシステムにより処理され得る工業用ヘッドエンドシステム、住宅用ヘッドエンドシステムおよび車両用ヘッドエンドシステムなど。コマンドは、個々のヘッドエンドシステムへ送信され、次にヘッドエンドシステムが、接続/切断コマンドをスマート計器へ送信する。様々なヘッドエンドシステムは、種々のフォーマット、管理される負荷の種々のタイプ例えば、高密度ヘッドエンドシステム対低密度ヘッドエンドシステムを含む、いくつかの点で異なり得る。下記でさらに詳しく説明するように、複数の出力接続が、使用される種々のヘッドエンドシステムを考慮するとよい。計器コマンドは、図6A~Cにおいて開示されているバスのうちの1つなど、バス上へ発行され得る。例えば、コマンドには、1つのパブリッシャおよび複数のサブスクライバがあってもよい。別の例として、複数のパブリッシャおよび複数のサブスクライバがあってもよい。本設計に基づき、特定の技術に関する制限はない。さらに本設計は、任意のパブリッシャまたはサブスクライバに合わせた調整を可能にする。図3に関して説明されるように、パブリッシャおよびサブスクライバが共通フォーマットを知っている必要はない。代わりにINDEゲートウェイが、パブリッシャ/サブスクライバの各組み合わせに合わせて通信を調整し、少なくとも一部のタイプの共通フォーマットの必要性をなくすとよい。さらに、本開示のパブリッシャ-サブスクライバモデルは、様々な方法で機能し得る。例えば、パブリッシャ-サブスクライバモデルは、プッシュとして動作し、パブリッシャがデータコマンドなどをプッシュして、サブスクライバがデータをプルしてもよい。別の例としては、パブリッシャ-サブスクライバモデルは、パブリッシャおよびサブスクライバの両方に関してプッシュおよびプルを可能にする。具体的には、INDEゲートウェイの1つ以上のコネクタが、データのプルおよび/またはデータのプッシュを行うよう構成され得る。例えば、GMSコネクタまたはFTPコネクタが、ソースシステムからデータをプルするよう構成されてもよい。または、ソースシステムがウェブサービスを呼び出してデータをプッシュできるよう、INDEゲートウェイのコネクタの1つがウェブサービスとして構成されてもよい。さらに、入力コネクタおよび出力コネクタの両方が、プッシュおよびプル手順の両方を同時にサポートしてもよい。コマンドの別の例には、オンデマンド計器読み取りが含まれ得る。LodeStar、ItronなどのMDMシステムが、SecureまたはCurrentなどのいくつかの異なるヘッドエンドシステムのうちの1つに対して計器情報のリクエストを送信してもよい。さらに、ソースシステムは、情報をターゲットシステムへ送信してもよい。この一例は、定期的な計器読み取りである。SecureまたはCurrentなどのヘッドエンドシステムは、計器データをいくつかのMDMシステムのうちの1つへ送信してもよい。このように、本設計は、コマンドのフォーマッティングおよびルーティングを複雑化する複数のソースシステムおよび複数のターゲットシステムに対処するとよい。INDEゲートウェイは、INDEコアからの分離および設計の両方の点から、複雑なルーティング/フォーマッティングを可能にし、異なるソースまたはターゲットシステムに合わせた調整を可能にする。INDEゲートウェイは、ソースシステムとして機能するMDMシステムおよびターゲットシステムとして機能するヘッドエンドシステム向けに、コネクタ複数のソースシステムのそれぞれと通信する入力コネクタおよび複数のターゲットシステムのそれぞれと通信する出力コネクタなどを調整するとよい。そのためINDEゲートウェイは、図3および5においてさらに詳しく説明するように、複数のMDMシステムのそれぞれに対する複数の入力コネクタを含むことができ、複数のヘッドエンドシステムのそれぞれに対する複数の出力コネクタを含むことができる。INDEゲートウェイは、ソースシステムとして機能するヘッドエンドシステムおよびターゲットシステムとして機能するMDMシステム向けに、コネクタ複数のソースシステムのそれぞれと通信する入力コネクタおよび複数のターゲットシステムのそれぞれと通信する出力コネクタなどを調整するとよい。そのためINDEゲートウェイは、図4においてさらに詳しく説明するように、複数のヘッドエンドシステムのそれぞれに対する複数の入力コネクタを含むことができ、複数のMDMシステムのそれぞれに対する複数の出力コネクタを含むことができる。さらに、MDMシステムが、一部の時間ソースシステムとして機能し、一部の時間ターゲットシステムとして機能し、ヘッドエンドシステムが、一部の時間ソースシステムとして機能し、一部の時間ターゲットシステムとして機能するシステムの場合、INDEゲートウェイは、図3および5で開示されるコネクタならびに図4で開示されるコネクタの両方のタイプを含むことができる。より具体的には、INDEゲートウェイは、複数のMDMシステムのそれぞれに対する複数の入力コネクタおよび複数の出力コネクタを含むことができ、複数のヘッドエンドシステムのそれぞれに対する複数の入力コネクタおよび複数の出力コネクタを含むことができる。以下でさらに詳しく説明するように、同じくINDEコアも、そのコアアダプタを調整するなど、その動作を調整するとよい。例えば、ソースシステムとして機能するMDMシステムおよびターゲットシステムとして機能するヘッドエンドシステムの場合、INDEコアは、MDMシステムのそれぞれからヘッドエンドシステムのそれぞれへの変換を行うコアアダプタを含むとよい。例として、第1のMDMシステムおよび第2のMDMシステム、ならびに第1のヘッドエンドシステムおよび第2のヘッドエンドシステムを備えるシステムでは、1対1変換を実行するために4つのコアアダプタがあるとよい。具体的には、以下のコアアダプタがあるとよい:第1のMDMシステムから第1のヘッドエンドシステムへの変換;第1のMDMシステムから第2のヘッドエンドシステムへの変換;第2のMDMシステムから第1のヘッドエンドシステムへの変換;および第2のMDMシステムから第2のヘッドエンドシステムへの変換。別の例として、ソースシステムとして機能するヘッドエンドシステムおよびターゲットシステムとして機能するMDMシステムの場合、INDEコアは、ヘッドエンドシステムのそれぞれからMDMシステムのそれぞれへの変換を行うコアアダプタを含むとよい。例えば、第1のヘッドエンドシステムおよび第2のヘッドエンドシステム、ならびに第1のMDMシステムおよび第2のMDMシステムを備えるシステムでは、1対1変換を実行するために4つのコアアダプタがあるとよい。具体的には、以下のコアアダプタがあるとよい:第1のヘッドエンドシステムから第1のMDMシステムへの変換;第1のヘッドエンドシステムから第2のMDMシステムへの変換;第2のヘッドエンドシステムから第1のMDMシステムへの変換:および第2のヘッドエンドシステムから第2のMDMシステムへの変換。さらに、MDMシステムが、一部の時間ソースシステムとして機能し、一部の時間ターゲットシステムとして機能し、ヘッドエンドシステムが、一部の時間ソースシステムとして機能し、一部の時間ターゲットシステムとして機能するシステムの場合、INDEコアは、図3および5で開示されているアダプタならびに図4で開示されているアダプタの両方のタイプを含むことができる。より具体的には、INDEコアは、複数のMDMシステムのそれぞれから複数のヘッドエンドシステムのそれぞれへの1対1変換、および複数のヘッドエンドシステムのそれぞれから複数のMDMシステムのそれぞれへの1対1変換の両方が可能である。図2を参照する。切断または再接続リクエストに関係する上位フロー図が示されている。MDMシステムは、切断または再接続リクエストをINDEコアへ送信する。INDEコアは、下記でさらに詳しく説明するように、リクエストを受信し、リクエストを変換し、変換されたリクエストをヘッドエンドシステムのうちの1つへ転送する。ヘッドエンドシステムは、変換されたリクエストを受信し、リクエストされたアクションを実行し、肯定応答をINDEコアへ送信する。次にINDEコアは、肯定応答を受信し、肯定応答を変換し、変換された肯定応答をMDMシステムへ転送する。図3を参照する。切断または再接続リクエストに関係する7レイヤの詳細なフロー図が示されている。切断/再接続リクエストの場合、ソースシステムはMDMシステムである。上記のように、MDMシステムの商用例には、LodeStarおよびItronがあるが、これらに限定はされない。同じく切断/再接続リクエストの場合、ターゲットシステムはヘッドエンドシステムである。上記のように、ユーティリティシステムは、SecureおよびCurrentなど、いくつかのタイプのヘッドエンドシステムのうちの1つを有するとよい。エクスポート/インポートコネクタサービスレイヤは、1つ以上のソースシステムおよび1つ以上のターゲットシステムに接続するコネクタを含む。これらのコネクタは、ウェブサービスとの対話を規定する任意のタイプの実行可能な言語ビジネスプロセス実行言語BPEL:BusinessProcessExecutionLanguageなどを使用して作成され得る。図3に示されているように、エクスポート/インポートコネクタサービスレイヤは、ソースおよびターゲットシステムそれぞれに対して、入力コネクタIPConnector1~IPConnector6などおよび出力コネクタOPConnector1~OPConnector6などを有する。IPC_DisconnectReconnect_LodeStar_FTPIPConnector1に示されているは、LodeStarシステムのFTPロケーションからリクエストを受け取り、それをコネクタサービスインターフェースINDEコアへ送信するために使用され得る。IPC_DisconnectReconnect_LodeStar_HTTPIPConnector3に示されているは、LodeStarシステムからHTTPプロトコル上でリクエストを受け取り、コネクタサービスインターフェースINDEコアを送信するために使用され得る。IPC_DisconnectReconnect_LodeStar_JMSIPConnector2に示されているは、LodeStarシステムのJMSキューからリクエストを受け取り、それをコネクタサービスインターフェースINDEコアへ送信するために使用され得る。同様に、IPC_DisconnectReconnect_Itron_FTPIPConnector4に示されているは、ItronシステムのFTPロケーションからリクエストを受け取り、それをコネクタサービスインターフェースINDEコアへ送信するために使用され得る。IPC_DisconnectReconnect_Itron_HTTPIPConnector6に示されているは、ItronシステムからHTTPプロトコル上でリクエストを受け取り、それをコネクタサービスインターフェースINDEコアへ送信するために使用され得る。IPC_DisconnectReconnect_Itron_JMSIPConnector5に示されているは、ItronシステムのJMSキューからリクエストを受け取り、それをコネクタサービスインターフェースINDEコアへ送信するために使用され得る。OPC_DisconnectReconnect_Secure_FTPOPConnector2に示されているは、OSBコネクタサービスから切断/再接続リクエストデータを受信し、それを構成されたFTPロケーションにてSecureシステムへ送信する。OPC_DisconnectReconnect_Secure_HTTPOPConnector1に示されているは、OSBコネクタサービスから切断/再接続リクエストを受信し、それをHTTP上でSecureシステムへ送信する。OPC_DisconnectReconnect_Secure_JMSOPConnector3に示されているは、OSBコネクタサービスから切断/再接続リクエストを受信し、それをJMSキューにおいてSecureシステムへ送信する。同じく、OPC_DisconnectReconnect_Current_FTPOPConnector5に示されているは、OSBコネクタサービスから切断/再接続リクエストデータを受信し、それを構成されたFTPロケーションにてCurrentシステムへ送信する。OPC_DisconnectReconnect_Current_HTTPOPConnector4に示されているは、OSBコネクタサービスから切断/再接続リクエストを受信し、それをHTTP上でCurrentシステムへ送信する。OPC_DisconnectReconnect_Current_JMSOPConnector6に示されているは、OSBコネクタサービスから切断/再接続リクエストを受信し、それをJMSキューにおいてCurrentシステムへ送信する。図3に示されているように、各エンドシステムソースおよびターゲットシステム両方を含むに対して、エクスポート/インポートコネクタサービスレイヤは、複数のタイプのコネクタを提供するとよい。例えば図3は、エクスポート/インポートコネクタサービスレイヤが、異なる3つのプロトコル、すなわちHTTP、FTPおよびJMSをサポートする異なる3つのコネクタを含むことを示している。このインターフェースにおいて、MDMシステムは、いくつかの異なるプロトコルのうちの1つを介してファイルを送信するとよい。図3に示されている例では、MDMシステムは、FTPプロトコルを介してファイルを送信する。したがって、ほかの2つのコネクタは薄く示されている。さらに、図3に示されている例では、ターゲットシステムターゲットシステム1Currentは、HTTPフォーマットのデータを予期している。したがって、Httpを使用するOPConnector4が強調され、ほかのコネクタは薄く示されている。これらのコネクタは、受信された入力データのデータ構造をチェックできる。エラーがあると、エラーハンドラサービスを呼び出す。エクスポート/インポートコネクタサービスレイヤの機能性はINDEゲートウェイに存在し、INDEコアからは独立しているため、エクスポート/インポートコネクタサービスレイヤは、クライアントの要件に応じて、いくつかの方法のうちの1つで構成または調整されるとよい。コネクタサービスインターフェースINDEコアレイヤは、OSBサービスを呼び出すコアコンポーネントを含む。エラーがあると、エラー処理サービスを呼び出す。この設計INDEコアコンポーネントがINDEゲートウェイから独立しているにより、コネクタサービスインターフェースINDEコアレイヤは、クライアント要件に基づき変更される必要がない。OSBINDEコアレイヤは、lookup.configファイルを参照して、エンドシステムに基づき適切な変換を決定する。変換後、OSBINDEコアレイヤは、データをディスパッチャへ送信する。ディスパッチャは、ターゲットシステムへ送信されるデータを非同期的に送る。エラーがあると、エラーハンドラサービスを呼び出す。OSBINDEコアレイヤは、ターゲットシステムのメッセージフォーマットに基づきデータの変換を実行するプロキシサービスを含んだOSBコアコンポーネントを含む。PS_AMI_DisconnectReconnectは、コネクタサービスインターフェースINDEコアから入力を受領して、着信するリクエストの少なくとも1つのルーティングパラメータルーティングヘッダなどを、‘Disconnect/Reconnect’に設定するプロキシサービスを含むとよい。リクエストの場合、PS_AMI_DisconnectReconnectはさらに、ルーティングパラメータをPS_Foundation_TransformAndDispatch_Syncに渡す。リクエストの場合、PS_AMI_DisconnectReconnectは、ルーティングパラメータをコネクタサービスインターフェースINDEコアに渡す。PS_Foundation_TransformAndDispatch_Syncは、PS_AMI_ConnectDisconnectからリクエストを受信し、リクエストのルーティングヘッダおよびAMI_Lookup.configに基づき変換を実行する、プロキシサービスを含むとよい。例えば、変換には、LodeStarからヘッドエンドへ、ヘッドエンドからItronへなどがあり得る。変換されたデータは、PS_Foundation_SynchronousRouterのルータにおける動的なルーティングアクティビティのための2つのヘッダ、すなわち‘routingservice’および‘invokingoperation’など、1つ以上のヘッダとともにPS_Foundation_SynchronousRouterへ送信されるとよい。PS_Foundation_SynchronousRouterは、PS_Foundation_TransformAndDispatch_Syncにおいて設定されたユーザヘッダから‘routingservice’名および‘invokingoperation’名を取得する。続いて、PS_Foundation_Synchronous_Routerは、routingserviceヘッダで指定されたビジネスサービスに動的にルーティングする。OSBINDEコアレイヤは、1つ以上のINDEコアアダプタを含む。図3に示されているように、種々のソースシステムから種々のターゲットシステムへの変換のためのINDEコアアダプタが列挙されている。具体的には、図3は、ソースシステム1からターゲットシステム1へのXQuery変換をSrc1_to_tgt1.xqとして示す。特定のXQuery変換が、AMI_Lookup.configに基づき選択される。例えば、LodeStar_To_Secure.xqは、LodeStarリクエストフォーマットからSecureリクエストフォーマットへの変換である。Secure_To_LodeStar.xqは、Secure応答フォーマットからLodeStar応答フォーマットへの変換である。Itron_To_Secure.xqは、ItronリクエストフォーマットからSecureリクエストフォーマットへの変換である。Secure_To_Itron.xqは、Secure応答フォーマットからItron応答フォーマットへの変換である。LodeStar_To_Currentは、LodeStarリクエストフォーマットからCurrentリクエストフォーマットへの変換である。Current_To_LodeStarは、Current応答フォーマットからLodeStar応答フォーマットへの変換である。Itron_To_Currentは、ItronリクエストフォーマットからCurrentリクエストフォーマットへの変換である。Current_To_Itron.xqは、Current応答フォーマットからItron応答フォーマットへの変換である。種々のソースシステムから種々のターゲットシステムへの変換に加えて、追加の変換のためのカスタムコアアダプタが、INDEコアとは別に含まれてもよい。例えば、CustomXquery_Req.xqは、入力から出力への1対1マッピングを行うリクエストXqueryファイルを含むとよく、INDE拡張レイヤ用に開発され得る。CustomXquery_Res.xqは、入力から出力への1対1マッピングを行う応答Xqueryファイルを含むとよく、INDE拡張レイヤ用に開発され得る。OSBコネクタサービスINDEゲートウェイレイヤは、OSBビジネスサービスを含む。このレイヤは、ディスパッチャからデータを受信し、それを出力コネクタOPConnector1~OPConnector6などへ送信する。図3に示されているように、出力コネクタ毎に1つのビジネスサービスがある。例えば、OSBコネクタサービスINDEゲートウェイは、BS_AMI_DisconnectReconnect_Secure_FTPを含み、これは、ディスパッチャからコールを受信しメッセージヘッダに応じて、OPC_DisconnectReconnect_Secure_FTPエクスポート/インポートコネクタサービスINDEゲートウェイに示されているを呼び出す、ビジネスサービスを含むとよい。BS_AMI_DisconnectReconnect_Secure_HTTPは、ディスパッチャからコールを受信しメッセージヘッダに応じて、OPC_DisconnectReconnect_Secure_HTTPエクスポート/インポートコネクタサービスINDEゲートウェイに示されているを呼び出す、ビジネスサービスを含むとよい。BS_AMI_DisconnectReconnect_Secure_JMSは、ディスパッチャからコールを受信しメッセージヘッダに応じて、OPC_DisconnectReconnect_Secure_JMSエクスポート/インポートコネクタサービスINDEゲートウェイに示されているを呼び出す、ビジネスサービスである。BS_AMI_DisconnectReconnect_Current_FTPは、ディスパッチャからコールを受信しメッセージヘッダに応じて、OPC_DisconnectReconnect_Current_FTPエクスポート/インポートコネクタサービスINDEゲートウェイに示されているを呼び出す、ビジネスサービスである。BS_AMI_DisconnectReconnect_Current_HTTPは、ディスパッチャからコールを受信しメッセージヘッダに応じて、OPC_DisconnectReconnect_Current_HTTPエクスポート/インポートコネクタサービスINDEゲートウェイに示されているを呼び出す、ビジネスサービスである。BS_AMI_DisconnectReconnect_Current_JMSは、ディスパッチャからコールを受信しメッセージヘッダに応じて、OPC_DisconnectReconnect_Current_JMSエクスポート/インポートコネクタサービスINDEゲートウェイに示されているを呼び出す、ビジネスサービスである。最後に、BS_AMI_DisconnectReconnect_Extnは、拡張レイヤデータベースとされ得るリモートデータベースDB:Databaseの出力コネクタOPConnector4などを呼び出すとよい呼び出すとよい。OSBINDE拡張レイヤは、未知のメッセージフォーマットを用いるエンドシステムに対しカスタム変換を提供する。この能力は、図3に示されているように、リモートデータベースに接続してもよい。PS_AMI_DisconnectReconnect_Extnは、OSBINDE拡張レイヤからのプロキシサービスを含むとよい。PS_AMI_DisconnectReconnect_Extnは、XMLデータの集合にクエリを行うよう設計されている、2つのカスタムXqueryなどの複数のクエリを適用してもよい。2つのカスタムXqueryは、リクエスト用および応答用であってもよい。例えば、リクエストXqueryを適用することにより、PS_AMI_DisconnectReconnect_Extnは、変換されたリクエストを、拡張レイヤのビジネスサービス、例えばBS_AMI_DisconnectReconnect_Extnへ送信するとよい。エラーハンドラサービスは、様々な例外を処理するために種々のレイヤ内のほかのプロセスにより呼び出されることが可能な、独立したプロセスを含むとよい。図3は、フローの例を示す。ステップ1にて、エクスポート/インポートコネクタサービスINDEゲートウェイが、FTPプロトコルを介して、ソースシステム1またはソースシステム2などのMDMシステムから切断または再接続リクエストを受信する。ステップ2にて、リクエストがIPConnectorによってコネクタサービスインターフェースINDEコアへ転送される。ステップ3にて、コネクタサービスインターフェースINDEコアがOSBINDEコアを呼び出す。ステップ4にて、OSBINDEコアがルックアップを実行する。ステップ5にて、OSBINDEコアが、INDEコアアダプタを使用して、ターゲットヘッドエンドシステムに応じて変換を行う。それを、ステップ6にてOSBINDEコアが、OSBコネクタサービスINDEゲートウェイに送る。ステップ7にて、OSBコネクタサービスが、その通信をエクスポート/インポートコネクタサービスINDEゲートウェイへ送信する。それを、ステップ8にてエクスポート/インポートコネクタサービスINDEゲートウェイが、アクション切断または再接続などの実行のためにSecureまたはCurrentなどのヘッドエンドシステムへ送信する。切断/再接続が成功した後、応答が、上述のプロセスすべてを介して逆向きステップ7~ステップ1にMDMシステムへ送信される。図4は、定期的な計器読み取りに関係する詳細なフロー図を示す。この場合、ソースシステムは、CurrentまたはSecureなど、ヘッドエンドシステムの1つを含み、ターゲットシステムは、LodeStarまたはItronなど、MDMシステムの1つを含む。図3と同様に、エクスポート/インポートコネクタサービスINDEゲートウェイレイヤは、IPC_PeriodicMeterRead_Secure_Http、IPC_PeriodicMeterRead_Secure_JMS、IPC_PeriodicMeterRead_Secure_FTP、IPC_PeriodicMeterRead_Current_Http、IPC_PeriodicMeterRead_Current_JMSおよびIPC_PeriodicMeterRead_Current_FTPなど、種々のタイプのソースシステムおよび種々のフォーマットに対する入力側の種々のルーチンを含む。さらに、エクスポート/インポートコネクタサービスINDEゲートウェイレイヤは、OPC_PeriodicMeterRead_LodeStar_Http、OPC_PeriodicMeterRead_LodeStar_JMS、OPC_PeriodicMeterRead_LodeStar_FTP、OPC_PeriodicMeterRead_Itron_Http、OPC_PeriodicMeterRead_Itron_JMSおよびOPC_PeriodicMeterRead_Itron_FTPなど、種々のタイプのターゲットシステムおよび種々のフォーマットに対する出力側の種々のルーチンを含む。接続サービスインターフェースINDEコアレイヤは、エクスポート/インポートコネクタサービスINDEゲートウェイレイヤから入力を受信し、OSBINDEコアを呼び出す。具体的には、BP_AMI_PeriodicMeterReadは、OSBを呼び出し、同期フラグがあるかどうかチェックする。あれば、重複するデバイスIDがあるかどうかが判断される。存在しなければ、デバイスIDをINDEデータベースDBに挿入することによってINDEDBが更新される。図4のOSBINDEコアレイヤおよびOSBコネクタサービスINDEゲートウェイは、図3で説明したOSBINDEコアレイヤおよびOSBコネクタサービスINDEゲートウェイと同じように動作する。図5は、オンデマンド計器読み取りに関係する詳細なフロー図を示す。この場合、ソースシステムは、LodeStarまたはItronなど、MDMシステムの1つを含み、ターゲットシステムは、CurrentまたはSecureなど、ヘッドエンドシステムの1つを含む。図6A~Cは、電力グリッドの全体的なアーキテクチャの一例のブロック図である。INDEコア55をINDEゲートウェイ60とともに含むアーキテクチャは、スマートグリッドに重要であると考えられる機能性を可能にし、1データ収集プロセス、2データカテゴリ化および維持プロセス、ならびに3可観測性プロセスが含まれ得る。以下でさらに詳しく説明するように、こうしたプロセスを使用することで、グリッドを観測し、データを分析して、グリッドについての情報を得ることができるようになる。図6A~Cに示されているアーキテクチャは、単に説明を目的としており、スマートグリッドデータのエンドツーエンド収集、搬送、記憶および管理を提供する参照モデルとしての機能を果たし得る。さらにこのアーキテクチャは、解析および解析管理、ならびに前述のもののユーティリティプロセスおよびシステムへの統合を提供し得る。したがって、これはエンタープライズ規模のアーキテクチャと見なされるとよい。運用管理およびグリッド自体の各側面など、特定の構成要素については、下記でさらに詳しく説明する。図6A~Cに示されているアーキテクチャは、データおよび統合バスを最大4つまで含み得る:1高速センサーデータバス146運用および非運用データを含むとよい、2専用イベント処理バス147イベントデータを含むとよい、3動作サービスバス130スマートグリッドについての情報をユーティリティのバックオフィスアプリケーションに提供する役割を果たすとよい、ならびに4バックオフィスITシステム用のエンタープライズサービスバスエンタープライズIT115にサービス提供するエンタープライズ統合環境バス114として図6A~Cに示されている。個々のデータバスは、1つ以上の方法で実現され得る。例えば、高速センサーデータバス146およびイベント処理バス147など、データバスの2つ以上が、単一データバスの別々のセグメントであってもよい。具体的には、バスはセグメント化された構造またはプラットフォームを有してもよい。下記でさらに詳しく説明するように、データバスの別々のセグメント上にデータをルーティングするために、1つ以上のスイッチなどのハードウェアおよび/またはソフトウェアが使用され得る。別の例として、データバスの2つ以上は、データを別々のバス上で搬送するために必要なハードウェアの面で別々である物理的バスなど、別々のバス上にあってもよい。具体的には、バスはそれぞれ、互いに独立したケーブル配線を含んでもよい。さらに、別々のバスのうち、一部または全部が同じタイプであってもよい。例えば、バスの1つ以上が、非シールドより対線を介したイーサネット登録商標およびWi-Fi登録商標などのローカルエリアネットワークLAN:localareanetworkを含んでもよい。下記でさらに詳しく説明するように、種々の物理的バスの中の1つのバス上へデータ上のデータをルーティングするために、ルータなどのハードウェアおよび/またはソフトウェアが使用され得る。さらに別の例として、バスの2つ以上が、単一バス構造の別々のセグメント上にあってもよく、1つ以上のバスが、独立した物理的バス上にあってもよい。具体的には、高速センサーデータバス146およびイベント処理バス147が、単一データバスの別々のセグメントであってもよく、エンタープライズ統合環境バス114が、物理的に独立したバス上にあってもよい。図6A~Cは、4つのバスを示すが、より少ない、または多い数のバスが、列挙された4タイプのデータを運ぶために使用され得る。例えば、後述するように、センサーデータおよびイベント処理データの伝達に、セグメント化されていない単一バスが使用されてもよいバスの総数は3になる。さらにシステムは、動作サービスバス130および/またはエンタープライズ統合環境バス114なしで動作することもできる。IT環境は、SOAServiceOrientedArchitecture:サービス指向アーキテクチャに準拠していてもよい。サービス指向アーキテクチャSOAは、サービスとしてパッケージ化されたビジネスプロセスのライフサイクル全体にわたる作成および使用に関する、コンピュータシステムアーキテクチャの様式である。SOAはさらに、種々のアプリケーションがデータを交換してビジネスプロセスに関与することを可能にするようITインフラストラクチャを定義し、供給する。ただし、SOAおよびエンタープライズサービスバスの使用は任意選択である。図面は、1INDEコア55、2INDE変電所180および3INDEデバイス188など、全体的なアーキテクチャ内の種々の構成要素を示す。全体的なアーキテクチャ内で構成要素をこのように分割しているのは、説明のためである。構成要素のこれ以外の分割が使用されてもよい。INDEアーキテクチャは、グリッドインテリジェンスに対する分散型および集中型どちらの手法をサポートするためにも使用されてよく、大型実装の規模に対応するメカニズムを提供するために使用されてもよい。INDE参照アーキテクチャは、実装され得る技術アーキテクチャの一例である。例えば、後述するように、INDE参照アーキテクチャは、ユーティリティソリューション毎に1つ、任意数の具体的技術アーキテクチャを開発するための開始点を提供するために使用される、メタアーキテクチャの例とすることもできる。したがって、特定のユーティリティ向けの具体的ソリューションは、INDE参照アーキテクチャ内の構成要素のうちの1つ、いくつかまたはすべてを含むとよい。さらに、INDE参照アーキテクチャは、ソリューション開発の標準化された開始点を提供することもできる。特定の電力グリッドに対する具体的な技術アーキテクチャを判断する手順について以下に述べる。INDE参照アーキテクチャは、エンタープライズ規模のアーキテクチャであるとよい。その目的は、グリッドデータおよび解析のエンドツーエンド管理と、これらのユーティリティシステムおよびプロセスへの統合とのためのフレームワークを提供することであるとよい。スマートグリッド技術は、ユーティリティビジネスプロセスのあらゆる側面に影響することから、グリッド、動作および需要家構内レベルの影響のみではなく、バックオフィスおよびエンタープライズレベルの影響にも気を配らなければならない。したがって、INDE参照アーキテクチャは、例えばインターフェースのためにSOA環境をサポートするべく、エンタープライズレベルSOAを参照することができ、実際に参照する。これは、スマートグリッドを構築および使用するには、ユーティリティがその既存のIT環境をSOAに変更しなければならないと要求するものと見なされてはならない。エンタープライズサービスバスは、IT統合を促進する有益なメカニズムであるが、スマートグリッドソリューションの残りの部分を実装するために必須ではない。以下の説明は、INDEスマートグリッド構成要素の種々のコンポーネントに焦点を合わせる。INDEコンポーネントグループ上記のように、INDE参照アーキテクチャ内の種々のコンポーネントには、例えば1INDEコア55、2INDE変電所180および3INDEデバイス188が含まれ得る。図6A~Cに示されているように、INDEコア55は、INDE参照アーキテクチャのうち、動作制御センターに存在するとよい部分である。INDEコア55は、グリッドデータを記憶するための統一データアーキテクチャと、そのデータに対して作用する解析の統合スキーマとを含むとよい。このデータアーキテクチャは、その最上位スキーマとして、国際電気標準会議IEC:InternationalElectrotechnicalCommission共通情報モデルCIM:CommonInformationModelを使用するとよい。IECCIMは、アプリケーションソフトウェアが電気ネットワークの構成およびステータスについての情報を交換できるようにすることを目標として、電気電力業界により開発されIECにより公式に採用された標準である。さらに、このデータアーキテクチャは、ほかのタイプのユーティリティデータ例えば計器データ、運用および過去データ、ログならびにイベントファイルなど、ならびに接続性およびメタデータファイルを、エンタープライズアプリケーションを含む上位アプリケーションによるアクセスのための単一エントリポイントを有するとよい単一データアーキテクチャに関連付けるために、連合ミドルウェア134を使用するとよい。さらに、リアルタイムシステムが、高速データバスを介して主要データストアにアクセスするとよく、いくつかのデータストアはリアルタイムデータを受信することができる。種々のタイプのデータが、スマートグリッド内の1つ以上のバス内で搬送されるとよい。INDE変電所180のセクションにおいて以下で説明するように、変電所データは、変電所において収集されて、ローカルに記憶されるとよい。具体的には、変電所に関連し近接しているとよいデータベースが、変電所データを記憶するとよい。さらに、変電所レベルに関連する解析は、変電所のコンピュータにて実行され、変電所データベースに記憶されるとよく、そのデータの全部または一部が、制御センターへ搬送されるとよい。搬送されるデータのタイプは、動作および非運用データ、イベント、グリッド接続性データならびにネットワーク位置データを含むとよい。運用データは、次に限定はされないが、スイッチ状態、フィーダ状態、コンデンサ状態、セクション状態、計器状態、FCIfaultedcircuitindicator:故障回路インジケータ状態、ラインセンサー状態、電圧、電流、有効電力、無効電力などを含むとよい。非運用データは、次に限定はされないが、電力品質、電力信頼性、アセット正常性、ストレスデータなどを含むとよい。運用および非運用データは、運用/非運用データバス146を使用して搬送されるとよい。電力グリッドの送電および/または配電におけるデータ収集アプリケーションが、データの一部または全部を運用/非運用データバス146へ送信することを担当するとよい。こうして、情報を得るための登録をすること、またはこのデータを利用可能にできるサービスを呼び出すことにより、この情報を必要とするアプリケーションがデータを得られるとよい。イベントは、後述するように、スマートグリッドの一部である様々なデバイスおよびセンサーから生じるメッセージおよび/またはアラームを含むとよい。イベントは、スマートグリッドネットワーク上のデバイスおよびセンサーから直接生成されてもよく、さらに、こうしたセンサーおよびデバイスからの測定データに基づいて様々な解析アプリケーションにより生成されてもよい。イベントの例には、計器の停止、計器のアラーム、変圧器の停止などが含まれ得る。グリッドデバイスのようなグリッドコンポーネントスマート電力センサーデジタル処理能力のためにプログラム可能な組み込みプロセッサを備えるセンサーなど、温度センサーなど、追加の組み込み処理を含む電力システムコンポーネントRTURemoteTerminalUnit:リモート端末ユニットなど、スマート計器ネットワーク計器の正常性、計器読み取りなどおよびモバイル現場要員用デバイス供給停止イベント、作業命令完了などが、イベントデータ、運用および非運用データを生成するとよい。スマートグリッド内で生成されたイベントデータは、イベントバス147を介して伝送されるとよい。グリッド接続性データは、ユーティリティグリッドの配置を定義するとよい。グリッドコンポーネント変電所、セグメント、フィーダ、変圧器、スイッチ、リクローザー、計器、センサー、電柱などの物理的配置、およびそれらの設備における相互接続性を定義する基本レイアウトがあるとよい。グリッド内のイベントコンポーネントの不具合、保守活動などに基づき、グリッド接続性は継続的に変化し得る。下記でさらに詳しく説明するように、データが記憶される構造ならびにデータの組み合わせにより、過去の様々な時点におけるグリッド配置の履歴の再現が可能となる。グリッド接続性データは、ユーティリティグリッドに対する変更が加えられ、この情報がGISGeographicInformationSystem:地理情報システムアプリケーションにおいて更新されるにつれて、定期的に地理情報システムGISから抽出されるとよい。ネットワーク位置データは、通信ネットワーク上のグリッドコンポーネントについての情報を含むとよい。この情報は、メッセージおよび情報を特定のグリッドコンポーネントへ送信するために使用されるとよい。ネットワーク位置データは、新たなスマートグリッドコンポーネントが設置されたときにスマートグリッドデータベースに手動で入力されてもよく、またはこの情報が外部で保たれる場合はアセット管理システムから抽出される。データは、グリッド内の様々なコンポーネントから送信され得るINDE変電所180および/またはINDEデバイス188など。データは、無線、有線または両方の組み合わせでINDEコア55へ送信され得る。データは、ユーティリティ通信ネットワーク160によって受信されるとよく、ユーティリティ通信ネットワーク160は、データをルーティングデバイス190へ送信するとよい。ルーティングデバイス190は、バスのセグメント上バスがセグメント化されたバス構造を含む場合または独立したバス上へのデータのルーティングを管理するソフトウェアおよび/またはハードウェアを含むとよい。ルーティングデバイスは、1つ以上のスイッチまたはルータを含んでもよい。ルーティングデバイス190は、ネットワーキングデバイスを含むとよく、そのソフトウェアおよびハードウェアが、バスの1つ以上へデータをルーティングおよび/または転送する。例えば、ルーティングデバイス190は、運用および非運用データを、運用/非運用データバス146へルーティングするとよい。ルータはさらに、イベントデータをイベントバス147へルーティングするとよい。ルーティングデバイス190は、データをどのようにルーティングするかを、1つ以上の方法に基づき判断するとよい。例えば、ルーティングデバイス190は、伝送されたデータ内の1つ以上のヘッダを検査して、データを運用/非運用データバス146のセグメントへルーティングするか、またはイベントバス147のセグメントへルーティングするかを判断してもよい。具体的には、データ内の1つ以上のヘッダが、データが動作/非運用データであるかその結果、ルーティングデバイス190はデータを運用/非運用データバス146へルーティングするまたはデータがイベントデータであるかその結果、ルーティングデバイス190はイベントバス147をルーティングするを示してもよい。あるいは、ルーティングデバイス190は、データのペイロードを検査して、データのタイプを判断してもよい例えば、ルーティングデバイス190は、データのフォーマットを検査して、データが運用/非運用データであるか、またはイベントデータであるかを判断してもよい。運用データを記憶する運用データウェアハウス図6A~Cには示されていないなどのストアの1つが、真の分散型データベースとして実装されてもよい。ストアのもう1つ、ヒストリアンが、分散型データベースとして実装されてもよい。これら2つのデータベースのもう一方のエンドは、INDE変電所180グループにあってもよい。さらに、イベントは、複合イベント処理バスを介していくつかのデータストアのいずれかに直接記憶されてもよい。具体的には、イベントは、イベントバス147へ発行したすべてのイベントのリポジトリとしてもよいイベントログに記憶されてもよい。イベントログは、イベントid、イベントタイプ、イベントソース、イベント優先度およびイベント生成時間のうちの1つ、いくつかまたはすべてを記憶するとよい。イベントバス147が、イベントを長期記憶してすべてのイベントの維持を提供する必要はない。データの記憶は、できるだけ、または実用的なだけ、データがソースに近くなるようになっているとよい。一実装では、これには例えば、変電所データがINDE変電所180にて記憶されることが含まれてもよい。しかし、このデータは、非常に細かい粒度レベルでグリッドを考慮した各種決定を下すために、動作制御センターレベル116においても必要とされることもある。データベースリンクおよびデータサービスを適宜使用することによってソリューションのすべてのレベルにおけるデータの利用可能性を促進するよう、分散型データ手法が、分散型インテリジェンス手法とともに採用されるとよい。この点、過去データストア動作制御センターレベル116にてアクセス可能であるとよいに関するソリューションは、運用データストアのソリューションと類似しているとよい。データは、変電所においてローカルに記憶されてもよく、制御センターのリポジトリインスタンス上で構成されているデータベースリンクが、個別の変電所にあるデータに対するアクセスを提供する。変電所解析は、変電所において、ローカルデータストアを使用してローカルで実行されるとよい。データベースリンクを使用してローカル変電所インスタンスのデータにアクセスすることによって、動作制御センターレベル116で過去/集合的解析が実行されてもよい。あるいは、データは、INDEコア55にて中央で記憶されてもよい。しかし、INDEデバイス188から伝送される必要があると考えられるデータの量を考慮すると、INDEデバイス188にてデータを記憶する方が好ましいこともある。具体的には、何千または何万もの変電所がある場合電力グリッドではあり得る、INDEコア55へ伝送される必要のあるデータ量により、通信ボトルネックがもたらされることもあり得る。最後に、INDEコア55は、電力グリッド内のINDE変電所180またはINDEデバイス188のうちの1つ、いくつかまたはすべてをプログラムまたは制御するとよい。例えばINDEコア55は、プログラミングを変更してもよく更新されたプログラムをダウンロードするなど、またはINDE変電所180もしくはINDEデバイス188の任意の側面を制御する制御コマンドを提供してもよいセンサーまたは解析の制御など。INDEコア55のほかの構成要素には、この論理アーキテクチャをサポートする様々な統合構成要素が含まれ得る。表1は、INDEコア55の特定の構成要素を記載する。表1:INDEコア構成要素表1で説明したように、リアルタイムデータバス146動作および非運用データを伝達するおよびリアルタイム複合イベント処理バス147イベント処理データを伝達するは単一バス346に組み合わされ得る。図6A~Cに示されているように、各バスは、パフォーマンスのために独立している。CEP処理の場合、非常に大きなメッセージバーストが起こりやすい特定の用途には、低遅延が重要であると考えられる。一方、グリッドデータフローの大部分はほぼ一定であり、デジタル故障レコーダファイルが例外であるが、これらは通常、制御された形で取得可能である。それに対し、イベントバーストは非同期且つランダムである。図6A~Cはさらに、INDEコア55とは独立した、動作制御センター116内のさらなる構成要素を示す。具体的には、図6A~Cはさらに、計器との通信計器からデータを収集して収集したデータをユーティリティに提供するなどを担当するシステムである、計器データ収集ヘッドエンド単数または複数153を示す。需要応答管理システム154は、1つ以上の需要家構内にある、ユーティリティによる制御が可能な設備と通信するシステムである。供給停止管理システム155は、供給停止の位置を追跡すること、何が送られているかを管理すること、およびその修理方法によって、供給停止の管理においてユーティリティを支援するシステムである。エネルギー管理システム156は、送電グリッド上の変電所例えばのデバイスを制御する、送電システムレベルの制御システムである。配電管理システム157は、配電グリッドの変電所のデバイスおよびフィーダデバイス例えばを制御する、配電システムレベルの制御システムである。IPネットワークサービス158は、IP型通信DHCPおよびFTPなどをサポートする1つ以上のサーバ上で動作するサービスの集合である。モバイルデータ送信システム159は、現場のモバイルデータ端末とメッセージを送受信するシステムである。回路負荷潮流分析、計画、雷分析およびグリッドシミュレーションツール152は、グリッドの設計、分析および計画においてユーティリティにより使用されるツールの集合である。IVRintegratedvoiceresponse:統合音声応答および呼管理151は、需要家からの電話を処理するシステムである自動または係による。供給停止に関する着信通話が、自動または手動で入力されて、供給停止管理システム155へ転送されるとよい。作業管理システム150は、作業命令を監視および管理するシステムである。地理情報システム149は、アセットが地理的にどこに位置し、各アセットがどのように接続されているかについての情報を含むデータベースである。環境がサービス指向アーキテクチャSOAを有する場合、動作SOAサポート148は、SOA環境をサポートするサービスの集合である。動作制御センター116内にありINDEコア55外にあるシステムのうちの1つ以上は、ユーティリティが有することもあるレガシー製品システムである。こうしたレガシー製品システムの例には、動作SOAサポート148、地理情報システム149、作業管理システム150、呼管理151、回路負荷潮流分析、計画、雷分析およびグリッドシミュレーションツール152、計器データ収集ヘッドエンド単数または複数153、需要応答管理システム154、供給停止管理システム155、エネルギー管理システム156、配電管理システム157、IPネットワークサービス158ならびにモバイルデータ送信システム159が含まれる。なお、こうしたレガシー製品システムは、スマートグリッドから受信されるデータを処理または操作することができなくてもよい。INDEコア55は、スマートグリッドからデータを受信し、スマートグリッドからのデータを処理し、処理したデータを1つ以上のレガシー製品システムへ、レガシー製品システムが使用できる形レガシー製品システムに特有の特定のフォーマッティングなどで転送することができるとよい。この点、INDEコア55はミドルウェアと見なされてもよい。INDEコア55を含む動作制御センター116は、エンタープライズIT115と通信するとよい。一般的に、エンタープライズIT115における機能性はバックオフィス業務を含む。具体的には、エンタープライズIT115は、ビジネスデータウェアハウス104、ビジネスインテリジェンスアプリケーション105、エンタープライズリソースプラニング106、様々な財務システム107、需要家情報システム108、人材システム109、アセット管理システム110、エンタープライズSOAサポート111、ネットワーク管理システム112およびエンタープライズメッセージサービス113を含むエンタープライズIT115内の様々なシステムへデータを送信するためにエンタープライズ統合環境バス114を使用するとよい。エンタープライズIT115はさらに、ファイアウォール102を介してインターネット101と通信するためのポータル103を含むとよい。INDEコアにおける機能性の具体的な例図6A~Cに示されているように、様々な機能性ブロックにより表されているがINDEコア55に含まれており、そのうち2つとして、計器データ管理サービスならびに計測解析およびサービスが含まれ得る。アーキテクチャのモジュール性が理由で、計器データ管理サービスならびに計測解析およびサービスなどの様々な機能性を組み込むことができる。INDE変電所INDE変電所180は、変電所の電子装置およびシステムと同一の場所に位置する1つ以上のサーバ上で、変電所の制御所にて変電所170内で実際にホストされている構成要素を含むとよい。以下の表2は、特定のINDE変電所180グループ構成要素を列挙し、記載する。データセキュリティサービス171は、変電所環境の一部であってもよい。あるいは、これらはINDE変電所180グループに統合されてもよい。表2INDE変電所構成要素上記のように、スマートグリッド内の種々の構成要素に、追加の処理/分析能力およびデータベースリソースを含む追加の機能性が含まれ得る。スマートグリッドにおいて、様々な構成要素内でこうした追加の機能性を使用することで、アプリケーションおよびネットワークパフォーマンスの集中管理および監督を伴う分散型アーキテクチャが可能になる。機能、パフォーマンスおよび拡張性のために、何千から何万のINDE変電所180および何万から何百万のグリッドデバイスを含むスマートグリッドが、分散型処理、データ管理およびプロセス通信を含むこともできる。INDE変電所180は、1つ以上のプロセッサと、1つ以上のメモリデバイス変電所非運用データ181および変電所動作データ182などとを含むとよい。非運用データ181および変電所動作データ182は、INDE変電所180内またはINDE変電所180上に位置するなど、変電所に関連し近接しているとよい。INDE変電所180はさらに、変電所レベルでのスマートグリッドの可観測性を担当する、スマートグリッドのコンポーネントを含んでもよい。INDE変電所180コンポーネントは、運用データ入手および分散型運用データストアでの記憶、非運用データの入手およびヒストリアンでの記憶、ならびにリアルタイムサブ秒などでのローカル解析処理という3つの主要機能を提供するとよい。処理は、電圧および電流波形のデジタル信号処理と、イベントストリーム処理を含む検出および分類処理と、処理結果のローカルシステムおよびデバイス、ならびに動作制御センター116にあるシステムへの伝達とを含むとよい。INDE変電所180と、グリッド内のほかのデバイスとの通信は、有線、無線または有線と無線との組み合わせとしてよい。例えば、INDE変電所180から動作制御センター116へのデータの伝送は有線であってもよい。INDE変電所180は、動作/非運用データまたはイベントデータなどのデータを、動作制御センター116へ伝送するとよい。ルーティングデバイス190は、伝送されたデータを、運用/非運用データバス146またはイベントバス147のうちの1つへルーティングするとよい。配電損失管理のための需要応答最適化も、ここで実行されるとよい。このアーキテクチャは、前に説明した分散型アプリケーションアーキテクチャの原則に従う。例えば、接続性データは、変電所170および動作制御センター116にて複製され、その結果、動作制御センター116へのデータ通信ネットワークが有効でなくても変電所170が独立して動作できるようにするとよい。この情報接続性がローカルに記憶されていることで、動作制御センターへの通信リンクが動作不能であっても変電所解析がローカルで実行され得る。同様に、運用データは、動作制御センター116および変電所170にて複製されるとよい。特定の変電所に関連するセンサーおよびデバイスからのデータが収集され、最新の測定が、変電所にてこのデータストアに記憶されるとよい。運用データストアのデータ構造は同じであるとよく、したがって、データベースリンクを使用して、制御センターにある運用データストアのインスタンスを介した、変電所に存在するデータへのシームレスアクセスを提供することもできる。これは、データの複製を減らすこと、および時間依存がより大きい変電所データ解析が、ローカルで、変電所外の通信利用可能性に依存せずに行われるのを可能にすることを含む、いくつかの利点を提供する。動作制御センターレベル116でのデータ解析は、時間依存がより小さいと考えられ典型的には、動作制御センター116は、過去データを検査して、反応というよりも予測のためのパターンを識別すると考えられるため、ネットワークの問題があっても対処できると考えられる。最後に、過去データが変電所にてローカルに記憶され、データのコピーが制御センターにて記憶されてもよい。または、動作制御センター116にてリポジトリインスタンス上のデータベースリンクが構成され、個別の変電所にあるデータへのアクセスが動作制御センターに提供されてもよい。変電所解析は、変電所170において、ローカルデータストアを使用してローカルで実行されるとよい。具体的には、変電所にて追加のインテリジェンスおよび記憶能力を使用することで、変電所は、それ自体を分析して、中央局からの入力なしにそれ自体を修正することができる。あるいは、ローカル変電所インスタンスのデータにデータベースリンクを使用してアクセスすることによって、動作制御センターレベル116で、過去/集合的解析も実行されてもよい。INDEデバイスINDEデバイス188は、様々な配電グリッドデバイス189例えば、送電線上のラインセンサーなどのスマートグリッド内の様々なセンサー、需要家構内にある計器163などを含む、スマートグリッド内の任意の種類のデバイスを含み得る。INDEデバイス188は、特定の機能性を備えグリッドに追加されるデバイスを含んでもよく専用プログラミングを含むスマートリモート端末ユニットRTUなど、または追加機能性を備えるグリッド内の既存デバイスを含んでもよい既にグリッド内に配置されており、スマートラインセンサーまたはスマートグリッドデバイスを作成するためにプログラム可能な、既存のオープンアーキテクチャ柱上RTUなど。INDEデバイス188はさらに、1つ以上のプロセッサおよび1つ以上のメモリデバイスを含んでもよい。既存のグリッドデバイスは、ソフトウェアの観点からはオープンではないこともあり、現代のネットワーキングまたはソフトウェアサービスに関してはあまりサポートできないかもしれない。既存のグリッドデバイスは、ラップトップコンピュータなどのほかの何らかのデバイスに時折オフロードするデータを入手および記憶するよう、または要求に応じてリモートホストへPSTNpublic-switchedtelephonenetwork:公衆交換電話ネットワーク線を介してバッチファイルを転送するよう設計されていることもある。こうしたデバイスは、リアルタイムデジタルネットワーク環境で動作するようには設計されていないこともある。このような場合には、グリッドデバイスデータは、既存の通信ネットワークがどのように設計されているかに応じて、変電所レベル170または動作制御センターレベル116で獲得されるとよい。計器ネットワークの場合、計器ネットワークが通常クローズドであり、計器が直接アドレス指定可能ではないことから、通常は計器データ収集エンジンからデータが獲得される。こうしたネットワークが進化するにつれて、計器およびその他のグリッドデバイスが個別にアドレス指定可能になると考えられ、その結果、データが、必要とされるところへ直接搬送可能になる。データが必要とされるのは、必ずしも動作制御センター116とは限らず、グリッド上のどこでもあり得る。故障回路インジケータなどのデバイスは、適度な速度100kbpsなどの無線ネットワークを介した接続のために、無線ネットワークインターフェースカードと結合されてもよい。こうしたデバイスは、例外によりステータスをレポートして、事前にプログラムされた固定機能を実行してもよい。ローカルスマートRTUを使用することによって、多数のグリッドデバイスのインテリジェンスが増強され得る。固定機能のクローズドアーキテクチャデバイスとして設計されている柱上RTUの代わりに、RTUは、サードパーティーによりプログラム可能でINDE参照アーキテクチャ内のINDEデバイス188としての機能を果たすことができるオープンアーキテクチャデバイスとして使用されてもよい。さらに、需要家の構内にある計器がセンサーとして使用され得る。例えば、計器は、消費を測定してもよく請求のために、どのくらいのエネルギーが消費されているかなど、電圧を測定してもよい電圧/VAr最適化で用いるために。図6A~Cはさらに、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からのコマンドに応じて制御されるとよい。図6A~Cに示されているように、需要家構内169は、インターネット168、公衆交換電話ネットワークPSTN169を介して、または専用線を介してコレクタ164を介してなどなど、様々な方法で通信するとよい。列挙された通信チャネルのいずれかを介して、1つ以上の需要家構内179からのデータが送信されるとよい。図6A~Cに示されているように、1つ以上の需要家構内179が、ユーティリティ管理ネットワーク160を介して動作制御センター116へ伝送されるようコレクタ164へデータを送信する、スマート計器ネットワーク178複数のスマート計器163を含むを含むとよい。さらに、分散型エネルギー生成/貯蔵162ソーラーパネルなどの様々なソースが、ユーティリティ管理ネットワーク160を介した動作制御センター116との通信のために、監視制御161へデータを送信するとよい。上記のように、動作制御センター116外にある電力グリッドのデバイスは、処理および/または記憶能力を含むとよい。そのデバイスには、INDE変電所180およびINDEデバイス188が含まれるとよい。電力グリッド内の個別のデバイスが追加のインテリジェンスを含むことに加えて、個別のデバイスは、情報センサーデータおよび/または分析データイベントデータなどを含むを交換するため、電力グリッドの状態を分析するため故障の判断など、および電力グリッドの状態を変更するため故障の修正などに、電力グリッド内のほかのデバイスと通信するとよい。具体的には、個別のデバイスは、1インテリジェンス処理能力など、2記憶装置上記の分散型記憶装置などおよび3通信上記の1つ以上のバスの使用などを使用するとよい。このようにして、電力グリッド内の個別のデバイスは、動作制御センター116からの監督なしに相互に通信および協働するとよい。例えば、上記で開示されたINDEアーキテクチャは、フィーダ回路上の少なくとも1つのパラメータを感知するデバイスを含むとよい。デバイスはさらに、フィーダ回路上で感知されたパラメータを監視し、感知されたパラメータを分析してフィーダ回路の状態を判断するプロセッサを含むとよい。例えば、感知パラメータの分析は、感知されたパラメータと、所定の閾値との比較を含んでもよく、さらに/または傾向分析を含んでもよい。上記の感知されるパラメータの1つには、波形の感知が含まれてもよく、上記の分析の1つには、感知された波形がフィーダ回路上の故障を示すかどうかを判断することが含まれてもよい。デバイスはさらに、1つ以上の変電所と通信するとよい。例えば、特定の変電所が、特定のフィーダ回路に電力を供給するとよい。デバイスは、その特定のフィーダ回路の状態を感知して、特定のフィーダ回路上に故障があるかどうかを判断するとよい。デバイスは、変電所と通信するとよい。変電所は、デバイスによって判断された故障を分析するとよく、故障に応じて修正措置を取るとよいフィーダ回路に供給される電力を削減するなど。デバイスが故障を示すデータを送信する波形の分析に基づき例では、変電所は、動作制御センター116からの入力なしに、フィーダ回路に供給される電力を変更するとよい。または変電所は、故障を示すデータと、ほかのセンサーからの情報とを組み合わせて、故障の分析をさらに精緻化してもよい。変電所はさらに、供給停止インテリジェンスアプリケーションおよび/または故障インテリジェンスアプリケーションなど、動作制御センター116と通信してもよい。したがって、動作制御センター116が、故障を判断してもよく、供給停止の範囲故障の影響を受ける戸数などを判断してもよい。このように、フィーダ回路の状態を感知するデバイスは、動作制御センター116の介入を要求するかしないかに関わらず、考えられる故障を修正するために変電所と協調動作するとよい。別の例として、処理および/またはメモリ能力を使用する追加のインテリジェンスを含むラインセンサーが、グリッドの一部分フィーダ回路などにおいてグリッド状態データを作り出してもよい。グリッド状態データは、動作制御センター116の需要応答管理システム155と共有されるとよい。需要応答管理システム155は、ラインセンサーからのグリッド状態データに応答して、フィーダ回路上の需要家サイトの1つ以上のデバイスを制御してもよい。具体的には、需要応答管理システム155は、ラインセンサーがフィーダ回路上の供給停止を示すのに応答して、フィーダ回路から電力を受ける需要家サイトにある電化製品をオフにすることによりフィーダ回路への負荷を軽減するよう、エネルギー管理システム156および/または配電管理システム157に命令してもよい。このように、ラインセンサーは需要応答管理システム155とともに、故障したフィーダ回路から自動的に負荷を移し、その結果、故障を隔離するとよい。さらに別の例として、電力グリッド内の1つ以上のリレーが、それに関連するマイクロプロセッサを有するとよい。これらのリレーは、故障の判断、および/または電力グリッドの制御のために、電力グリッド内にあるほかのデバイスおよび/またはデータベースと通信するとよい。前述の例は、電力ユーティリティへの応用に焦点を合わせた。開示されたINDEアーキテクチャは、ほかの産業にも応用され得る。例えば、開示されたINDEアーキテクチャは、カスタマイズ可能であり、輸送手段運行産業航空運行ネットワーク、鉄道運行ネットワーク、自動車運行ネットワーク、バス運行ネットワークなど、電気通信ネットワークおよびエネルギー探鉱油井のネットワーク、天然ガス井のネットワークなどを含むがこれらに限定されない、1つ以上の産業に応用され得る。本発明は、好適な実施形態に関連して示され記載されてきたが、本発明の基本的特徴から、上記のものに加えてある程度の変更および改変が行われてよいということは明らかである。さらに、本発明の実践に利用され得る異なるタイプのコンピュータソフトウェアおよびハードウェアは多数あり、本発明は上述の例に制限されない。本発明は、1つ以上の電子デバイスにより実行される機能、および動作の記号表現を参照して記載された。よって、当然のことながら、そのような機能および動作には、構造化形式でデータを表現する電気信号の、電子デバイスの処理ユニットによる操作が含まれる。この操作は、データを変換するか、または電子デバイスのメモリシステムの各位置にデータを保ち、これが、当業者には十分理解される形で電子デバイスの動作を再構成するか、またはほかの形で変更する。データが保たれるデータ構造は、データのフォーマットにより定義される特定の特性を有するメモリの物理的位置である。本発明は前述の文脈において記載されているが、記載された機能および動作がハードウェアに実装されることも可能であることは当業者には当然であるため、制限的なものとして意図されてはいない。したがって、本発明の有効な範囲内の変形および改変すべてを保護することが出願人の意図である。本発明は、すべての等価物を含め、添付の特許請求の範囲によって定義されるものとする。"