JP5925774B2 - インテリジェントコアエンジン - Google Patents

Description

先行出願の参照
本願は、２０１０年７月３０日に提出されたインド特許出願第２１７１／ＣＨＥ／２０１０号の出願日の利益を主張するものであり、その教示全体をこの参照によって引用したものとする。

１．発明の分野
本発明は、全般的に、産業ネットワークを管理するシステムおよび方法に関し、特に、電力グリッドを管理するために、電力グリッドの種々のセクションからのデータの収集、および／または種々のセクションへのデータのルーティングを行い、収集／ルーティングされたデータを分析するシステムおよび方法に関する。

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

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

電力会社は、「スマートグリッド」と呼ばれることもあるデジタル技術を使用して、電力グリッドの改良を試みてきた。例えば、よりインテリジェントな計器（「スマート計器」と呼ばれることもある）は、従来の計器よりも詳しく消費を特定する高度な計器の一種である。続いてスマート計器は、監視および請求のために、当該情報を何らかのネットワークを介して地域のユーティリティ（ｕｔｉｌｉｔｙ）へ伝達することができる（遠隔測定）。

電力グリッドがこうした進歩をとげていても、電力グリッドの解析および通信は複雑である。電力会社は、エネルギー管理システム（負荷分割を分析し、それに応じてコマンドを出すことができる）、供給停止管理システム（供給停止を分析し、それに応じてコマンドを出すことができる）、需要応答システム、請求システムなどの複数のシステムを有し得る。これらの複数のシステムは相互に作用することもあり、電力グリッドの管理を複雑化する。さらに、これらの複数のシステムは、電力グリッド内の様々なターゲットに対しコマンドを出す複数のソースとして機能し得る。複数のシステムは、多くの場合異なるフォーマットで通信し、通信を複雑化する。したがって、電力グリッド内の複数のシステムの解析および通信をよりよく管理する必要性が存在する。

電力ユーティリティシステムなどのシステムの中央管理局（ｃｅｎｔｒａｌ ｍａｎａｇｅｍｅｎｔ ａｕｔｈｏｒｉｔｙ）が開示される。中央管理局は、複数の計器データ管理システムおよび複数のヘッドエンドシステムと通信し、計器データ管理システムは、コマンドを生成し、ヘッドエンドシステムは、１つ以上の計器（１つ以上のスマート計器など）と通信する。中央管理局を含みスマートグリッドを管理し得るアーキテクチャの一例は、インテリジェントネットワークデータエンタープライズ（以下、ＩＮＤＥ（Ｉｎｔｅｌｌｉｇｅｎｔ Ｎｅｔｗｏｒｋ Ｄａｔａ Ｅｎｔｅｒｐｒｉｓｅ）と呼ぶ）参照アーキテクチャである。

中央管理局は、ゲートウェイレイヤおよびコアレイヤを含む。ゲートウェイレイヤは、複数の入力コネクタルーチン（ｉｎｐｕｔ ｃｏｎｎｅｃｔｏｒ ｒｏｕｔｉｎｅ）および複数の出力コネクタルーチン（ｏｕｔｐｕｔ ｃｏｎｎｅｃｔｏｒ ｒｏｕｔｉｎｅ）を含む。複数の入力コネクタルーチンは、中央管理局へデータを送信する複数のソースシステム（接続／切断コマンドを中央管理局から送信する計器データ管理システムなど）のそれぞれと通信するための独立した少なくとも１つの入力コネクタルーチンを含む。複数の出力コネクタルーチンは、中央管理局から送信されたデータを受信する複数のターゲットシステム（接続／切断コマンドを中央管理局から受信するヘッドエンドシステムなど）のそれぞれと通信するための独立した少なくとも１つの出力コネクタルーチンを含む。

中央管理局のコアレイヤは、複数のコアアダプタを含み、コアアダプタは、複数のヘッドエンドシステムに対するコマンドを生成する複数の計器データ管理システムからの通信の１対１変換を実行する。

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

上位ＩＮＤＥアーキテクチャの例を示した。 ＭＤＭ（Ｍｅｔｅｒ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ：計器データ管理）システム、ＩＮＤＥコア、およびヘッドエンドシステム間の上位フロー図を示す。 切断または再接続リクエストの詳細なフロー図の例である。 定期的な計器読み取りの詳細なフロー図の例である。 オンデマンド計器読み取りリクエストの詳細なフロー図の例である。 電力グリッドの全体的なアーキテクチャの一例のブロック図である。 電力グリッドの全体的なアーキテクチャの一例のブロック図である。 電力グリッドの全体的なアーキテクチャの一例のブロック図である。

概要として、以下に記載される好適な実施形態は、電力グリッドを管理する方法およびシステムに関する。特定の側面は電力グリッドの中央管理の構造上および／または機能上の能力に関する。米国特許出願第１２／３７８，１０２号（米国特許出願公開第２００９−０２８１６７４（Ａ１）号として公開）、米国特許出願第１２／３７８，０９１号（米国特許出願公開第２００９−０２８１６７３（Ａ１）号として公開）および国際出願ＰＣＴ／ＵＳ２００９／０００８８８号（国際公開第２００９／１３６９７５号として公開）に開示されているように、インテリジェントネットワークデータエンタープライズ（ＩＮＤＥ）は、スマートグリッド統合プラットフォームであり、ＩＮＤＥは、高度に拡張可能で構成可能なアプリケーション統合ソリューションを提供し、ユーティリティ企業によって広く使用され得る高度計測インフラストラクチャ、需要応答、故障＆供給停止インテリジェンス、変電所解析などの組み込みのコアスマートグリッドビジネスプロセスを有する。

ＩＮＤＥアーキテクチャは、コアレイヤおよびゲートウェイレイヤに分割され、ＩＮＤＥコアは、インテリジェントサービスルーティング、同期および非同期サービス呼び出し、データ変換ならびに監査能力などの特定のサービスを提供し、ＩＮＤＥゲートウェイは、広く使用されている産業通信プロトコルを用いて構築されるとよいアプリケーションコネクタサービスを提供する。例えば、ＩＮＤＥゲートウェイは、複数の入力コネクタルーチンおよび複数の出力コネクタルーチンを含むとよく、複数の入力コネクタルーチンは、複数の計器データ管理（ＭＤＭ）システムのそれぞれと通信するための独立した入力コネクタルーチンを含み、複数の出力コネクタルーチンは、複数のヘッドエンドシステムのそれぞれと通信するための独立した出力コネクタルーチンを含む。

ＩＮＤＥコアとＩＮＤＥゲートウェイとの分離は、既知および未知のシステムに対するＩＮＤＥアーキテクチャのよりよい適応、よりよい拡張性およびよりよいセキュリティを含むがこれらに限定されない、いくつかの利点を提供する。上位アーキテクチャ５０の例が、図１に開示されている。図１に示されているように、ＩＮＤＥコア５０は、ＩＮＤＥゲートウェイ６０から独立している。さらに、ＩＮＤＥゲートウェイ６０は、ＩＮＤＥコア５０と、ソースシステム（ソースシステム１（６５）およびソースシステム２（７０）など）ならびにターゲットシステム（ターゲットシステム１（７５）およびターゲットシステム２（８０）など）とのインターフェースを提供する。図１は、２つのソースシステムおよび２つのターゲットシステムを示す。しかし、より少ないまたはより多いソースシステムおよびターゲットシステムが予想される。下記でさらに詳しく説明するように、ＩＮＤＥゲートウェイは、様々なソースおよびターゲットシステムを接続するコネクタレイヤを含む。

ソースシステムは、情報のリクエストまたはアクションのコマンドを送信し、ターゲットシステムは、情報のリクエストに応答するか、またはコマンドに基づいて動作する。コマンドの一例は、計器における切断／再接続アクションを含んでもよく、ＭＤＭシステムにより生成され得る。ＭＤＭシステムは、データ収集および通信システム（自動計器読み取り（ＡＭＲ：ａｕｔｏｍａｔｅｄ ｍｅｔｅｒ ｒｅａｄｉｎｇ）および高度計測インフラストラクチャ（ＡＭＩ：ａｄｖａｎｃｅｄ ｍｅｔｅｒｉｎｇ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を含む）、ならびに計器データ管理および関連のソフトウェアアプリケーションのうちの１つ以上に関する機能性を含むとよい。典型的なユーティリティシステムには、複数のＭＤＭシステムがあることもあり、その結果、いくつかの異なるＭＤＭシステムのうちの１つがソースシステムとして機能し得る。商業用のＭＤＭシステムの例には、ＬｏｄｅＳｔａｒおよびＩｔｒｏｎがある。さらに、異なるＭＤＭシステムが異なるベンダーから出ていて、異なるフォーマットに従うこともある。このため、コマンド内のデータは、同様の情報（スマート計器のＩＤ＃および接続／切断コマンドなど）を含むのに、異なるフォーマットであることもある。

例えば、コマンドは、ファイル転送プロトコル（ＦＴＰ：ｆｉｌｅ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）、ｊａｖａメッセージサービス（ＪＭＳ：ｊａｖａ ｍｅｓｓａｇｅ ｓｅｒｖｉｃｅ）およびハイパーテキスト転送プロトコル（ＨＴＴＰ：ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ）などの、いくつかの異なるネットワークプロトコルのうちの１つに基づき送信され得る。ＦＴＰは、ファイルを１つのホストから別のホストへ、インターネットなどのＴＣＰ／ＩＰベースのネットワーク上でコピーするために使用され得る標準ネットワークプロトコルである。ＦＴＰは、クライアントとサーバアプリケーションとの間に別々の制御およびデータ接続を利用するクライアント−サーバアーキテクチャ上に構築され、異なるエンドホスト構成（すなわちオペレーティングシステム、ファイル名）の問題が解決される。ＦＴＰは、ユーザベースのパスワード認証または匿名ユーザアクセスとともに使用される。ＪＭＳ ＡＰＩは、２つ以上のクライアント間でメッセージを送信するためのＪａｖａメッセージ指向ミドルウェア（ＭＯＭ：Ｍｅｓｓａｇｅ Ｏｒｉｅｎｔｅｄ Ｍｉｄｄｌｅｗａｒｅ）ＡＰＩである。ＪＭＳは、Ｊａｖａプラットフォームエンタープライズエディションの一部であり、ＪａｖａコミュニティプロセスのもとでＪＳＲ９１４として開発された仕様により定義されている。これは、Ｊａｖａ２プラットフォームエンタープライズエディション（Ｊ２ＥＥ：Ｊａｖａ ２ Ｐｌａｔｆｏｒｍ，Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）に基づくアプリケーションコンポーネントがメッセージを作成、送信、受信および読み取りできるようにするメッセージング標準である。分散したアプリケーションの種々のコンポーネント間の通信が、疎結合されること、信頼性を持つこと、および非同期となることを可能にする。最後に、ＨＴＴＰは、分散型、連携型のハイパーメディア情報システムのためのアプリケーションレイヤプロトコルである。

コマンド（種々のネットワークプロトコルのうちの任意の１つを介して送信される）は、ヘッドエンドシステムにルーティングされるとよく、ヘッドエンドシステムは、ホームエリアネットワーク（ＨＡＮ：ｈｏｍｅ ａｒｅａ ｎｅｔｗｏｒｋ）に設置された計器に切断／再接続アクションを伝送する。この場合もやはり、典型的なユーティリティシステムには、ＳｅｃｕｒｅまたはＣｕｒｒｅｎｔなどの複数のヘッドエンドシステムがあることもあり、その結果、いくつかの異なるヘッドエンドシステムのうちの１つがターゲットシステムとして機能し得る。

別々のヘッドエンドシステムは、別々のカテゴリの計器と通信し得る。例えば計器は、工業用計器、家庭用計器、住宅用計器、車両関係の計器などに基づきカテゴリ化され得る。別々のカテゴリの計器は、別々のヘッドエンドシステムにより処理され得る（工業用ヘッドエンドシステム、住宅用ヘッドエンドシステムおよび車両用ヘッドエンドシステムなど）。コマンドは、個々のヘッドエンドシステムへ送信され、次にヘッドエンドシステムが、接続／切断コマンドをスマート計器へ送信する。

様々なヘッドエンドシステムは、種々のフォーマット、管理される負荷の種々のタイプ（例えば、高密度ヘッドエンドシステム対低密度ヘッドエンドシステム）を含む、いくつかの点で異なり得る。下記でさらに詳しく説明するように、複数の出力接続が、使用される種々のヘッドエンドシステムを考慮するとよい。

計器コマンドは、図６Ａ〜Ｃにおいて開示されているバスのうちの１つなど、バス上へ発行され得る。例えば、コマンドには、１つの「パブリッシャ」および複数のサブスクライバがあってもよい。別の例として、複数のパブリッシャおよび複数のサブスクライバがあってもよい。本設計に基づき、特定の技術に関する制限はない。さらに本設計は、任意のパブリッシャまたはサブスクライバに合わせた調整を可能にする。図３に関して説明されるように、パブリッシャおよびサブスクライバが「共通フォーマット」を知っている必要はない。代わりにＩＮＤＥゲートウェイが、パブリッシャ／サブスクライバの各組み合わせに合わせて通信を調整し、少なくとも一部のタイプの共通フォーマットの必要性をなくすとよい。

さらに、本開示のパブリッシャ−サブスクライバモデルは、様々な方法で機能し得る。例えば、パブリッシャ−サブスクライバモデルは、「プッシュ」として動作し、パブリッシャがデータ（コマンドなど）を「プッシュ」して、サブスクライバがデータを「プル」してもよい。別の例としては、パブリッシャ−サブスクライバモデルは、パブリッシャおよびサブスクライバの両方に関して「プッシュ」および「プル」を可能にする。具体的には、ＩＮＤＥゲートウェイの１つ以上のコネクタが、データの「プル」および／またはデータの「プッシュ」を行うよう構成され得る。例えば、ＧＭＳコネクタ（またはＦＴＰコネクタ）が、ソースシステムからデータを「プル」するよう構成されてもよい。または、ソースシステムがウェブサービスを呼び出してデータをプッシュできるよう、ＩＮＤＥゲートウェイのコネクタの１つがウェブサービスとして構成されてもよい。さらに、入力コネクタおよび出力コネクタの両方が、プッシュおよびプル手順の両方を同時にサポートしてもよい。

コマンドの別の例には、オンデマンド計器読み取りが含まれ得る。ＬｏｄｅＳｔａｒ、ＩｔｒｏｎなどのＭＤＭシステムが、ＳｅｃｕｒｅまたはＣｕｒｒｅｎｔなどのいくつかの異なるヘッドエンドシステムのうちの１つに対して計器情報のリクエストを送信してもよい。

さらに、ソースシステムは、情報をターゲットシステムへ送信してもよい。この一例は、定期的な計器読み取りである。ＳｅｃｕｒｅまたはＣｕｒｒｅｎｔなどのヘッドエンドシステムは、計器データをいくつかのＭＤＭシステムのうちの１つへ送信してもよい。

このように、本設計は、コマンドのフォーマッティングおよびルーティングを複雑化する複数のソースシステムおよび複数のターゲットシステムに対処するとよい。ＩＮＤＥゲートウェイは、ＩＮＤＥコアからの分離および設計の両方の点から、複雑なルーティング／フォーマッティングを可能にし、異なるソースまたはターゲットシステムに合わせた調整を可能にする。ＩＮＤＥゲートウェイは、ソースシステムとして機能するＭＤＭシステムおよびターゲットシステムとして機能するヘッドエンドシステム向けに、コネクタ（複数のソースシステムのそれぞれと通信する入力コネクタおよび複数のターゲットシステムのそれぞれと通信する出力コネクタなど）を調整するとよい。そのためＩＮＤＥゲートウェイは、図３および５においてさらに詳しく説明するように、複数のＭＤＭシステムのそれぞれに対する複数の入力コネクタを含むことができ、複数のヘッドエンドシステムのそれぞれに対する複数の出力コネクタを含むことができる。ＩＮＤＥゲートウェイは、ソースシステムとして機能するヘッドエンドシステムおよびターゲットシステムとして機能するＭＤＭシステム向けに、コネクタ（複数のソースシステムのそれぞれと通信する入力コネクタおよび複数のターゲットシステムのそれぞれと通信する出力コネクタなど）を調整するとよい。そのためＩＮＤＥゲートウェイは、図４においてさらに詳しく説明するように、複数のヘッドエンドシステムのそれぞれに対する複数の入力コネクタを含むことができ、複数のＭＤＭシステムのそれぞれに対する複数の出力コネクタを含むことができる。さらに、ＭＤＭシステムが、一部の時間ソースシステムとして機能し、一部の時間ターゲットシステムとして機能し、ヘッドエンドシステムが、一部の時間ソースシステムとして機能し、一部の時間ターゲットシステムとして機能するシステムの場合、ＩＮＤＥゲートウェイは、図３および５で開示されるコネクタならびに図４で開示されるコネクタの両方のタイプを含むことができる。より具体的には、ＩＮＤＥゲートウェイは、複数のＭＤＭシステムのそれぞれに対する複数の入力コネクタおよび複数の出力コネクタを含むことができ、複数のヘッドエンドシステムのそれぞれに対する複数の入力コネクタおよび複数の出力コネクタを含むことができる。

以下でさらに詳しく説明するように、同じくＩＮＤＥコアも、そのコアアダプタを調整するなど、その動作を調整するとよい。例えば、ソースシステムとして機能するＭＤＭシステムおよびターゲットシステムとして機能するヘッドエンドシステムの場合、ＩＮＤＥコアは、ＭＤＭシステムのそれぞれからヘッドエンドシステムのそれぞれへの変換を行うコアアダプタを含むとよい。例として、第１のＭＤＭシステムおよび第２のＭＤＭシステム、ならびに第１のヘッドエンドシステムおよび第２のヘッドエンドシステムを備えるシステムでは、１対１変換を実行するために４つのコアアダプタがあるとよい。具体的には、以下のコアアダプタがあるとよい：第１のＭＤＭシステムから第１のヘッドエンドシステムへの変換；第１のＭＤＭシステムから第２のヘッドエンドシステムへの変換；第２のＭＤＭシステムから第１のヘッドエンドシステムへの変換；および第２のＭＤＭシステムから第２のヘッドエンドシステムへの変換。

別の例として、ソースシステムとして機能するヘッドエンドシステムおよびターゲットシステムとして機能するＭＤＭシステムの場合、ＩＮＤＥコアは、ヘッドエンドシステムのそれぞれからＭＤＭシステムのそれぞれへの変換を行うコアアダプタを含むとよい。例えば、第１のヘッドエンドシステムおよび第２のヘッドエンドシステム、ならびに第１のＭＤＭシステムおよび第２のＭＤＭシステムを備えるシステムでは、１対１変換を実行するために４つのコアアダプタがあるとよい。具体的には、以下のコアアダプタがあるとよい：第１のヘッドエンドシステムから第１のＭＤＭシステムへの変換；第１のヘッドエンドシステムから第２のＭＤＭシステムへの変換；第２のヘッドエンドシステムから第１のＭＤＭシステムへの変換：および第２のヘッドエンドシステムから第２のＭＤＭシステムへの変換。

さらに、ＭＤＭシステムが、一部の時間ソースシステムとして機能し、一部の時間ターゲットシステムとして機能し、ヘッドエンドシステムが、一部の時間ソースシステムとして機能し、一部の時間ターゲットシステムとして機能するシステムの場合、ＩＮＤＥコアは、図３および５で開示されているアダプタならびに図４で開示されているアダプタの両方のタイプを含むことができる。より具体的には、ＩＮＤＥコアは、複数のＭＤＭシステムのそれぞれから複数のヘッドエンドシステムのそれぞれへの１対１変換、および複数のヘッドエンドシステムのそれぞれから複数のＭＤＭシステムのそれぞれへの１対１変換の両方が可能である。

図２を参照する。切断または再接続リクエストに関係する上位フロー図が示されている。ＭＤＭシステムは、切断または再接続リクエストをＩＮＤＥコアへ送信する。ＩＮＤＥコアは、下記でさらに詳しく説明するように、リクエストを受信し、リクエストを変換し、変換されたリクエストをヘッドエンドシステムのうちの１つへ転送する。ヘッドエンドシステムは、変換されたリクエストを受信し、リクエストされたアクションを実行し、肯定応答をＩＮＤＥコアへ送信する。次にＩＮＤＥコアは、肯定応答を受信し、肯定応答を変換し、変換された肯定応答をＭＤＭシステムへ転送する。

図３を参照する。切断または再接続リクエストに関係する７レイヤの詳細なフロー図が示されている。切断／再接続リクエストの場合、ソースシステムはＭＤＭシステムである。上記のように、ＭＤＭシステムの商用例には、ＬｏｄｅＳｔａｒおよびＩｔｒｏｎがあるが、これらに限定はされない。同じく切断／再接続リクエストの場合、ターゲットシステムはヘッドエンドシステムである。上記のように、ユーティリティシステムは、ＳｅｃｕｒｅおよびＣｕｒｒｅｎｔなど、いくつかのタイプのヘッドエンドシステムのうちの１つを有するとよい。

エクスポート／インポートコネクタサービスレイヤは、１つ以上のソースシステムおよび１つ以上のターゲットシステムに接続するコネクタを含む。これらのコネクタは、ウェブサービスとの対話を規定する任意のタイプの実行可能な言語（ビジネスプロセス実行言語（ＢＰＥＬ：Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｅｘｅｃｕｔｉｏｎ Ｌａｎｇｕａｇｅ）など）を使用して作成され得る。

図３に示されているように、エクスポート／インポートコネクタサービスレイヤは、ソースおよびターゲットシステムそれぞれに対して、入力コネクタ（ＩＰＣｏｎｎｅｃｔｏｒ１〜ＩＰＣｏｎｎｅｃｔｏｒ６など）および出力コネクタ（ＯＰＣｏｎｎｅｃｔｏｒ１〜ＯＰＣｏｎｎｅｃｔｏｒ６など）を有する。ＩＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿ＬｏｄｅＳｔａｒ＿ＦＴＰ（ＩＰＣｏｎｎｅｃｔｏｒ１に示されている）は、ＬｏｄｅＳｔａｒシステムのＦＴＰロケーションからリクエストを受け取り、それをコネクタサービスインターフェース（ＩＮＤＥコア）へ送信するために使用され得る。ＩＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿ＬｏｄｅＳｔａｒ＿ＨＴＴＰ（ＩＰＣｏｎｎｅｃｔｏｒ３に示されている）は、ＬｏｄｅＳｔａｒシステムからＨＴＴＰプロトコル上でリクエストを受け取り、コネクタサービスインターフェース（ＩＮＤＥコア）を送信するために使用され得る。ＩＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿ＬｏｄｅＳｔａｒ＿ＪＭＳ（ＩＰＣｏｎｎｅｃｔｏｒ２に示されている）は、ＬｏｄｅＳｔａｒシステムのＪＭＳキューからリクエストを受け取り、それをコネクタサービスインターフェース（ＩＮＤＥコア）へ送信するために使用され得る。同様に、ＩＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｉｔｒｏｎ＿ＦＴＰ（ＩＰＣｏｎｎｅｃｔｏｒ４に示されている）は、ＩｔｒｏｎシステムのＦＴＰロケーションからリクエストを受け取り、それをコネクタサービスインターフェース（ＩＮＤＥコア）へ送信するために使用され得る。ＩＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｉｔｒｏｎ＿ＨＴＴＰ（ＩＰＣｏｎｎｅｃｔｏｒ６に示されている）は、ＩｔｒｏｎシステムからＨＴＴＰプロトコル上でリクエストを受け取り、それをコネクタサービスインターフェース（ＩＮＤＥコア）へ送信するために使用され得る。ＩＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｉｔｒｏｎ＿ＪＭＳ（ＩＰＣｏｎｎｅｃｔｏｒ５に示されている）は、ＩｔｒｏｎシステムのＪＭＳキューからリクエストを受け取り、それをコネクタサービスインターフェース（ＩＮＤＥコア）へ送信するために使用され得る。

ＯＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｓｅｃｕｒｅ＿ＦＴＰ（ＯＰＣｏｎｎｅｃｔｏｒ２に示されている）は、ＯＳＢコネクタサービスから切断／再接続リクエストデータを受信し、それを構成されたＦＴＰロケーションにてＳｅｃｕｒｅシステムへ送信する。ＯＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｓｅｃｕｒｅ＿ＨＴＴＰ（ＯＰＣｏｎｎｅｃｔｏｒ１に示されている）は、ＯＳＢコネクタサービスから切断／再接続リクエストを受信し、それをＨＴＴＰ上でＳｅｃｕｒｅシステムへ送信する。ＯＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｓｅｃｕｒｅ＿ＪＭＳ（ＯＰＣｏｎｎｅｃｔｏｒ３に示されている）は、ＯＳＢコネクタサービスから切断／再接続リクエストを受信し、それをＪＭＳキューにおいてＳｅｃｕｒｅシステムへ送信する。同じく、ＯＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｃｕｒｒｅｎｔ＿ＦＴＰ（ＯＰＣｏｎｎｅｃｔｏｒ５に示されている）は、ＯＳＢコネクタサービスから切断／再接続リクエストデータを受信し、それを構成されたＦＴＰロケーションにてＣｕｒｒｅｎｔシステムへ送信する。ＯＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｃｕｒｒｅｎｔ＿ＨＴＴＰ（ＯＰＣｏｎｎｅｃｔｏｒ４に示されている）は、ＯＳＢコネクタサービスから切断／再接続リクエストを受信し、それをＨＴＴＰ上でＣｕｒｒｅｎｔシステムへ送信する。ＯＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｃｕｒｒｅｎｔ＿ＪＭＳ（ＯＰＣｏｎｎｅｃｔｏｒ６に示されている）は、ＯＳＢコネクタサービスから切断／再接続リクエストを受信し、それをＪＭＳキューにおいてＣｕｒｒｅｎｔシステムへ送信する。

図３に示されているように、各エンドシステム（ソースおよびターゲットシステム両方を含む）に対して、エクスポート／インポートコネクタサービスレイヤは、複数のタイプのコネクタを提供するとよい。例えば図３は、エクスポート／インポートコネクタサービスレイヤが、異なる３つのプロトコル、すなわちＨＴＴＰ、ＦＴＰおよびＪＭＳをサポートする異なる３つのコネクタを含むことを示している。このインターフェースにおいて、ＭＤＭシステムは、いくつかの異なるプロトコルのうちの１つを介してファイルを送信するとよい。図３に示されている例では、ＭＤＭシステムは、ＦＴＰプロトコルを介してファイルを送信する。したがって、ほかの２つのコネクタは薄く示されている。さらに、図３に示されている例では、ターゲットシステム（ターゲットシステム１（Ｃｕｒｒｅｎｔ））は、ＨＴＴＰフォーマットのデータを予期している。したがって、Ｈｔｔｐを使用するＯＰＣｏｎｎｅｃｔｏｒ４が強調され、ほかのコネクタは薄く示されている。これらのコネクタは、受信された入力データのデータ構造をチェックできる。エラーがあると、エラーハンドラサービスを呼び出す。エクスポート／インポートコネクタサービスレイヤの機能性はＩＮＤＥゲートウェイに存在し、ＩＮＤＥコアからは独立しているため、エクスポート／インポートコネクタサービスレイヤは、クライアントの要件に応じて、いくつかの方法のうちの１つで構成または調整されるとよい。

コネクタサービスインターフェース（ＩＮＤＥコア）レイヤは、ＯＳＢサービスを呼び出すコアコンポーネントを含む。エラーがあると、エラー処理サービスを呼び出す。この設計（ＩＮＤＥコアコンポーネントがＩＮＤＥゲートウェイから独立している）により、コネクタサービスインターフェース（ＩＮＤＥコア）レイヤは、クライアント要件に基づき変更される必要がない。

ＯＳＢ（ＩＮＤＥコア）レイヤは、ｌｏｏｋｕｐ．ｃｏｎｆｉｇファイルを参照して、エンドシステムに基づき適切な変換を決定する。変換後、ＯＳＢ ＩＮＤＥコアレイヤは、データをディスパッチャへ送信する。ディスパッチャは、ターゲットシステムへ送信されるデータを非同期的に送る。エラーがあると、エラーハンドラサービスを呼び出す。

ＯＳＢ（ＩＮＤＥコア）レイヤは、ターゲットシステムのメッセージフォーマットに基づきデータの変換を実行するプロキシサービスを含んだＯＳＢコアコンポーネントを含む。ＰＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔは、コネクタサービスインターフェース（ＩＮＤＥコア）から入力を受領して、着信するリクエストの少なくとも１つのルーティングパラメータ（ルーティングヘッダなどを、‘Ｄｉｓｃｏｎｎｅｃｔ／Ｒｅｃｏｎｎｅｃｔ’に設定するプロキシサービスを含むとよい。リクエストの場合、ＰＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔはさらに、ルーティングパラメータをＰＳ＿Ｆｏｕｎｄａｔｉｏｎ＿ＴｒａｎｓｆｏｒｍＡｎｄＤｉｓｐａｔｃｈ＿Ｓｙｎｃに渡す。リクエストの場合、ＰＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔは、ルーティングパラメータをコネクタサービスインターフェース（ＩＮＤＥコア）に渡す。

ＰＳ＿Ｆｏｕｎｄａｔｉｏｎ＿ＴｒａｎｓｆｏｒｍＡｎｄＤｉｓｐａｔｃｈ＿Ｓｙｎｃは、ＰＳ＿ＡＭＩ＿ＣｏｎｎｅｃｔＤｉｓｃｏｎｎｅｃｔからリクエストを受信し、リクエストのルーティングヘッダおよびＡＭＩ＿Ｌｏｏｋｕｐ．ｃｏｎｆｉｇに基づき変換を実行する、プロキシサービスを含むとよい。例えば、変換には、ＬｏｄｅＳｔａｒからヘッドエンドへ、ヘッドエンドからＩｔｒｏｎへなどがあり得る。変換されたデータは、ＰＳ＿Ｆｏｕｎｄａｔｉｏｎ＿ＳｙｎｃｈｒｏｎｏｕｓＲｏｕｔｅｒのルータにおける動的なルーティングアクティビティのための２つのヘッダ、すなわち‘ｒｏｕｔｉｎｇｓｅｒｖｉｃｅ’および‘ｉｎｖｏｋｉｎｇｏｐｅｒａｔｉｏｎ’など、１つ以上のヘッダとともにＰＳ＿Ｆｏｕｎｄａｔｉｏｎ＿ＳｙｎｃｈｒｏｎｏｕｓＲｏｕｔｅｒへ送信されるとよい。

ＰＳ＿Ｆｏｕｎｄａｔｉｏｎ＿ＳｙｎｃｈｒｏｎｏｕｓＲｏｕｔｅｒは、ＰＳ＿Ｆｏｕｎｄａｔｉｏｎ＿ＴｒａｎｓｆｏｒｍＡｎｄＤｉｓｐａｔｃｈ＿Ｓｙｎｃにおいて設定されたユーザヘッダから‘ｒｏｕｔｉｎｇｓｅｒｖｉｃｅ’名および‘ｉｎｖｏｋｉｎｇｏｐｅｒａｔｉｏｎ’名を取得する。続いて、ＰＳ＿Ｆｏｕｎｄａｔｉｏｎ＿Ｓｙｎｃｈｒｏｎｏｕｓ＿Ｒｏｕｔｅｒは、ｒｏｕｔｉｎｇｓｅｒｖｉｃｅヘッダで指定されたビジネスサービスに動的にルーティングする。

ＯＳＢ（ＩＮＤＥコア）レイヤは、１つ以上のＩＮＤＥコアアダプタを含む。図３に示されているように、種々のソースシステムから種々のターゲットシステムへの変換のためのＩＮＤＥコアアダプタが列挙されている。具体的には、図３は、ソースシステム１からターゲットシステム１へのＸＱｕｅｒｙ変換をＳｒｃ１＿ｔｏ＿ｔｇｔ１．ｘｑとして示す。特定のＸＱｕｅｒｙ変換が、ＡＭＩ＿Ｌｏｏｋｕｐ．ｃｏｎｆｉｇに基づき選択される。例えば、ＬｏｄｅＳｔａｒ＿Ｔｏ＿Ｓｅｃｕｒｅ．ｘｑは、ＬｏｄｅＳｔａｒリクエストフォーマットからＳｅｃｕｒｅリクエストフォーマットへの変換である。Ｓｅｃｕｒｅ＿Ｔｏ＿ＬｏｄｅＳｔａｒ．ｘｑは、Ｓｅｃｕｒｅ応答フォーマットからＬｏｄｅＳｔａｒ応答フォーマットへの変換である。Ｉｔｒｏｎ＿Ｔｏ＿Ｓｅｃｕｒｅ．ｘｑは、ＩｔｒｏｎリクエストフォーマットからＳｅｃｕｒｅリクエストフォーマットへの変換である。Ｓｅｃｕｒｅ＿Ｔｏ＿Ｉｔｒｏｎ．ｘｑは、Ｓｅｃｕｒｅ応答フォーマットからＩｔｒｏｎ応答フォーマットへの変換である。ＬｏｄｅＳｔａｒ＿Ｔｏ＿Ｃｕｒｒｅｎｔは、ＬｏｄｅＳｔａｒリクエストフォーマットからＣｕｒｒｅｎｔリクエストフォーマットへの変換である。Ｃｕｒｒｅｎｔ＿Ｔｏ＿ＬｏｄｅＳｔａｒは、Ｃｕｒｒｅｎｔ応答フォーマットからＬｏｄｅＳｔａｒ応答フォーマットへの変換である。Ｉｔｒｏｎ＿Ｔｏ＿Ｃｕｒｒｅｎｔは、ＩｔｒｏｎリクエストフォーマットからＣｕｒｒｅｎｔリクエストフォーマットへの変換である。Ｃｕｒｒｅｎｔ＿Ｔｏ＿Ｉｔｒｏｎ．ｘｑは、Ｃｕｒｒｅｎｔ応答フォーマットからＩｔｒｏｎ応答フォーマットへの変換である。種々のソースシステムから種々のターゲットシステムへの変換に加えて、追加の変換のためのカスタムコアアダプタが、ＩＮＤＥコアとは別に含まれてもよい。例えば、ＣｕｓｔｏｍＸｑｕｅｒｙ＿Ｒｅｑ．ｘｑは、入力から出力への１対１マッピングを行うリクエストＸｑｕｅｒｙファイルを含むとよく、ＩＮＤＥ拡張レイヤ用に開発され得る。ＣｕｓｔｏｍＸｑｕｅｒｙ＿Ｒｅｓ．ｘｑは、入力から出力への１対１マッピングを行う応答Ｘｑｕｅｒｙファイルを含むとよく、ＩＮＤＥ拡張レイヤ用に開発され得る。

ＯＳＢコネクタサービス（ＩＮＤＥゲートウェイ）レイヤは、ＯＳＢビジネスサービスを含む。このレイヤは、ディスパッチャからデータを受信し、それを出力コネクタ（ＯＰＣｏｎｎｅｃｔｏｒ１〜ＯＰＣｏｎｎｅｃｔｏｒ６など）へ送信する。図３に示されているように、出力コネクタ毎に１つのビジネスサービスがある。例えば、ＯＳＢコネクタサービス（ＩＮＤＥゲートウェイ）は、ＢＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｓｅｃｕｒｅ＿ＦＴＰを含み、これは、ディスパッチャからコールを受信し（メッセージヘッダに応じて）、ＯＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｓｅｃｕｒｅ＿ＦＴＰ（エクスポート／インポートコネクタサービス（ＩＮＤＥゲートウェイ）に示されている）を呼び出す、ビジネスサービスを含むとよい。ＢＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｓｅｃｕｒｅ＿ＨＴＴＰは、ディスパッチャからコールを受信し（メッセージヘッダに応じて）、ＯＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｓｅｃｕｒｅ＿ＨＴＴＰ（エクスポート／インポートコネクタサービス（ＩＮＤＥゲートウェイ）に示されている）を呼び出す、ビジネスサービスを含むとよい。ＢＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｓｅｃｕｒｅ＿ＪＭＳは、ディスパッチャからコールを受信し（メッセージヘッダに応じて）、ＯＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｓｅｃｕｒｅ＿ＪＭＳ（エクスポート／インポートコネクタサービス（ＩＮＤＥゲートウェイ）に示されている）を呼び出す、ビジネスサービスである。ＢＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｃｕｒｒｅｎｔ＿ＦＴＰは、ディスパッチャからコールを受信し（メッセージヘッダに応じて）、ＯＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｃｕｒｒｅｎｔ＿ＦＴＰ（エクスポート／インポートコネクタサービス（ＩＮＤＥゲートウェイ）に示されている）を呼び出す、ビジネスサービスである。ＢＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｃｕｒｒｅｎｔ＿ＨＴＴＰは、ディスパッチャからコールを受信し（メッセージヘッダに応じて）、ＯＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｃｕｒｒｅｎｔ＿ＨＴＴＰ（エクスポート／インポートコネクタサービス（ＩＮＤＥゲートウェイ）に示されている）を呼び出す、ビジネスサービスである。ＢＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｃｕｒｒｅｎｔ＿ＪＭＳは、ディスパッチャからコールを受信し（メッセージヘッダに応じて）、ＯＰＣ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｃｕｒｒｅｎｔ＿ＪＭＳ（エクスポート／インポートコネクタサービス（ＩＮＤＥゲートウェイ）に示されている）を呼び出す、ビジネスサービスである。最後に、ＢＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｅｘｔｎは、拡張レイヤデータベースとされ得るリモートデータベース（ＤＢ：Ｄａｔａｂａｓｅ）の出力コネクタ（ＯＰＣｏｎｎｅｃｔｏｒ４など）を呼び出すとよい呼び出すとよい。

ＯＳＢ（ＩＮＤＥ拡張）レイヤは、未知のメッセージフォーマットを用いるエンドシステムに対しカスタム変換を提供する。この能力は、図３に示されているように、リモートデータベースに接続してもよい。ＰＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｅｘｔｎは、ＯＳＢ（ＩＮＤＥ拡張）レイヤからのプロキシサービスを含むとよい。ＰＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｅｘｔｎは、ＸＭＬデータの集合にクエリを行うよう設計されている、２つのカスタムＸｑｕｅｒｙなどの複数のクエリを適用してもよい。２つのカスタムＸｑｕｅｒｙは、リクエスト用および応答用であってもよい。例えば、リクエストＸｑｕｅｒｙを適用することにより、ＰＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｅｘｔｎは、変換されたリクエストを、拡張レイヤのビジネスサービス、例えばＢＳ＿ＡＭＩ＿ＤｉｓｃｏｎｎｅｃｔＲｅｃｏｎｎｅｃｔ＿Ｅｘｔｎへ送信するとよい。

エラーハンドラサービスは、様々な例外を処理するために種々のレイヤ内のほかのプロセスにより呼び出されることが可能な、独立したプロセスを含むとよい。

図３は、フローの例を示す。ステップ１にて、エクスポート／インポートコネクタサービス（ＩＮＤＥゲートウェイ）が、ＦＴＰプロトコルを介して、ソースシステム１またはソースシステム２などのＭＤＭシステムから切断または再接続リクエストを受信する。ステップ２にて、リクエストがＩＰＣｏｎｎｅｃｔｏｒによってコネクタサービスインターフェース（ＩＮＤＥコア）へ転送される。ステップ３にて、コネクタサービスインターフェース（ＩＮＤＥコア）がＯＳＢ（ＩＮＤＥコア）を呼び出す。ステップ４にて、ＯＳＢ（ＩＮＤＥコア）がルックアップを実行する。ステップ５にて、ＯＳＢ（ＩＮＤＥコア）が、ＩＮＤＥコアアダプタを使用して、ターゲットヘッドエンドシステムに応じて変換を行う。それを、ステップ６にてＯＳＢ（ＩＮＤＥコア）が、ＯＳＢコネクタサービス（ＩＮＤＥゲートウェイ）に送る。ステップ７にて、ＯＳＢコネクタサービスが、その通信をエクスポート／インポートコネクタサービス（ＩＮＤＥゲートウェイ）へ送信する。それを、ステップ８にてエクスポート／インポートコネクタサービス（ＩＮＤＥゲートウェイ）が、アクション（切断または再接続など）の実行のためにＳｅｃｕｒｅまたはＣｕｒｒｅｎｔなどのヘッドエンドシステムへ送信する。切断／再接続が成功した後、応答が、上述のプロセスすべてを介して逆向き（ステップ７〜ステップ１）にＭＤＭシステムへ送信される。

図４は、定期的な計器読み取りに関係する詳細なフロー図を示す。この場合、ソースシステムは、ＣｕｒｒｅｎｔまたはＳｅｃｕｒｅなど、ヘッドエンドシステムの１つを含み、ターゲットシステムは、ＬｏｄｅＳｔａｒまたはＩｔｒｏｎなど、ＭＤＭシステムの１つを含む。

図３と同様に、エクスポート／インポートコネクタサービス（ＩＮＤＥゲートウェイ）レイヤは、ＩＰＣ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄ＿Ｓｅｃｕｒｅ＿Ｈｔｔｐ、ＩＰＣ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄ＿Ｓｅｃｕｒｅ＿ＪＭＳ、ＩＰＣ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄ＿Ｓｅｃｕｒｅ＿ＦＴＰ、ＩＰＣ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄ＿Ｃｕｒｒｅｎｔ＿Ｈｔｔｐ、ＩＰＣ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄ＿Ｃｕｒｒｅｎｔ＿ＪＭＳおよびＩＰＣ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄ＿Ｃｕｒｒｅｎｔ＿ＦＴＰなど、種々のタイプのソースシステムおよび種々のフォーマットに対する入力側の種々のルーチンを含む。さらに、エクスポート／インポートコネクタサービス（ＩＮＤＥゲートウェイ）レイヤは、ＯＰＣ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄ＿ＬｏｄｅＳｔａｒ＿Ｈｔｔｐ、ＯＰＣ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄ＿ＬｏｄｅＳｔａｒ＿ＪＭＳ、ＯＰＣ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄ＿ＬｏｄｅＳｔａｒ＿ＦＴＰ、ＯＰＣ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄ＿Ｉｔｒｏｎ＿Ｈｔｔｐ、ＯＰＣ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄ＿Ｉｔｒｏｎ＿ＪＭＳおよびＯＰＣ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄ＿Ｉｔｒｏｎ＿ＦＴＰなど、種々のタイプのターゲットシステムおよび種々のフォーマットに対する出力側の種々のルーチンを含む。

接続サービスインターフェース（ＩＮＤＥコア）レイヤは、エクスポート／インポートコネクタサービス（ＩＮＤＥゲートウェイ）レイヤから入力を受信し、ＯＳＢ（ＩＮＤＥコア）を呼び出す。具体的には、ＢＰ＿ＡＭＩ＿ＰｅｒｉｏｄｉｃＭｅｔｅｒＲｅａｄは、ＯＳＢを呼び出し、同期フラグがあるかどうかチェックする。あれば、重複するデバイスＩＤがあるかどうかが判断される。存在しなければ、デバイスＩＤをＩＮＤＥデータベース（ＤＢ）に挿入することによってＩＮＤＥ ＤＢが更新される。

図４のＯＳＢ（ＩＮＤＥコア）レイヤおよびＯＳＢコネクタサービス（ＩＮＤＥゲートウェイ）は、図３で説明したＯＳＢ（ＩＮＤＥコア）レイヤおよびＯＳＢコネクタサービス（ＩＮＤＥゲートウェイ）と同じように動作する。

図５は、オンデマンド計器読み取りに関係する詳細なフロー図を示す。この場合、ソースシステムは、ＬｏｄｅＳｔａｒまたはＩｔｒｏｎなど、ＭＤＭシステムの１つを含み、ターゲットシステムは、ＣｕｒｒｅｎｔまたはＳｅｃｕｒｅなど、ヘッドエンドシステムの１つを含む。

図６Ａ〜Ｃは、電力グリッドの全体的なアーキテクチャの一例のブロック図である。ＩＮＤＥコア５５をＩＮＤＥゲートウェイ６０とともに含むアーキテクチャは、スマートグリッドに重要であると考えられる機能性を可能にし、（１）データ収集プロセス、（２）データカテゴリ化および維持プロセス、ならびに（３）可観測性プロセスが含まれ得る。以下でさらに詳しく説明するように、こうしたプロセスを使用することで、グリッドを「観測」し、データを分析して、グリッドについての情報を得ることができるようになる。

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

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

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

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

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

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

図面は、（１）ＩＮＤＥコア５５、（２）ＩＮＤＥ変電所１８０および（３）ＩＮＤＥデバイス１８８など、全体的なアーキテクチャ内の種々の構成要素を示す。全体的なアーキテクチャ内で構成要素をこのように分割しているのは、説明のためである。構成要素のこれ以外の分割が使用されてもよい。ＩＮＤＥアーキテクチャは、グリッドインテリジェンスに対する分散型および集中型どちらの手法をサポートするためにも使用されてよく、大型実装の規模に対応するメカニズムを提供するために使用されてもよい。

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

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

ＩＮＤＥコンポーネントグループ
上記のように、ＩＮＤＥ参照アーキテクチャ内の種々のコンポーネントには、例えば（１）ＩＮＤＥコア５５、（２）ＩＮＤＥ変電所１８０および（３）ＩＮＤＥデバイス１８８が含まれ得る。

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

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

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

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

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

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

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

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

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

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

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

表１は、ＩＮＤＥコア５５の特定の構成要素を記載する。

表１：ＩＮＤＥコア構成要素

表１で説明したように、リアルタイムデータバス１４６（動作および非運用データを伝達する）およびリアルタイム複合イベント処理バス１４７（イベント処理データを伝達する）は単一バス３４６に組み合わされ得る。

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

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

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

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

ＩＮＤＥコアにおける機能性の具体的な例
図６Ａ〜Ｃに示されているように、様々な機能性（ブロックにより表されている）がＩＮＤＥコア５５に含まれており、そのうち２つとして、計器データ管理サービスならびに計測解析およびサービスが含まれ得る。アーキテクチャのモジュール性が理由で、計器データ管理サービスならびに計測解析およびサービスなどの様々な機能性を組み込むことができる。

ＩＮＤＥ変電所
ＩＮＤＥ変電所１８０は、変電所の電子装置およびシステムと同一の場所に位置する１つ以上のサーバ上で、変電所の制御所にて変電所１７０内で実際にホストされている構成要素を含むとよい。

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

表２ ＩＮＤＥ変電所構成要素

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前述の例は、電力ユーティリティへの応用に焦点を合わせた。開示されたＩＮＤＥアーキテクチャは、ほかの産業にも応用され得る。例えば、開示されたＩＮＤＥアーキテクチャは、カスタマイズ可能であり、輸送手段運行産業（航空運行ネットワーク、鉄道運行ネットワーク、自動車運行ネットワーク、バス運行ネットワークなど）、電気通信ネットワークおよびエネルギー探鉱（油井のネットワーク、天然ガス井のネットワークなど）を含むがこれらに限定されない、１つ以上の産業に応用され得る。

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

Claims (16)

1. 電力グリッドの少なくとも一部を管理し、複数の計器データ管理システムおよび複数のヘッドエンドシステムと通信する、中央電力グリッドシステムであって、前記計器データ管理システムは、コマンドを生成し、前記ヘッドエンドシステムは、１つ以上の計器と通信し、前記中央電力グリッドシステムは、
   プロセッサとメモリを含むコンピューティング・デバイスであって、
   複数の入力コネクタルーチンおよび複数の出力コネクタルーチンを含むゲートウェイレイヤであって、前記複数の入力コネクタルーチンは、前記中央電力グリッドシステムへデータを送信する複数のソースシステムのそれぞれと通信するための独立した複数の入力コネクタルーチンを含み、前記ソースシステムは、前記中央電力グリッドシステムへデータを送信する前記複数の計器データ管理システムを含み、前記複数の出力コネクタルーチンは、複数のターゲットシステムのそれぞれと通信するための独立した複数の出力コネクタルーチンを含み、前記ターゲットシステムは、前記中央電力グリッドシステムからデータを受信する前記複数のヘッドエンドシステムを含む、前記ゲートウェイレイヤと、
   前記ゲートウェイレイヤとは通信するが、前記ソースシステムおよび前記ターゲットシステムとは通信しないコアレイヤであって、前記ゲートウェイレイヤにより前記複数のソースシステムから受信した通信が前記複数のターゲットシステムによる受信に適合するように、１対１変換を実行するように構成された複数のコアアダプタを含む、前記コアレイヤと、
   を実行させるように構成された、前記コンピューティング・デバイス
   を含む中央電力グリッドシステム。
2. 前記中央電力グリッドシステムへ送信される前記データは、前記複数の計器データ管理システムにより送信される接続／切断コマンドを含む、請求項１に記載の中央電力グリッドシステム。
3. 前記中央電力グリッドシステムへ送信される前記データは、前記複数の計器データ管理システムにより送信されるオンデマンド計器読み取りコマンドを含む、請求項１に記載の中央電力グリッドシステム。
4. 前記計器データ管理システムのそれぞれは、独立した複数の入力コネクタルーチンに関連し、
   前記ヘッドエンドシステムのそれぞれは、独立した複数の出力コネクタルーチンに関連する、請求項１に記載の中央電力グリッドシステム。
5. 前記計器データ管理システムのそれぞれに関連する前記独立した複数の入力コネクタルーチンは、異なるネットワークプロトコルを含む、請求項４に記載の中央電力グリッドシステム。
6. 前記異なるネットワークプロトコルは、ファイル転送プロトコル（ＦＴＰ）、ｊａｖａメッセージサービス（ＪＭＳ）およびハイパーテキスト転送プロトコル（ＨＴＴＰ）から成る群から選択される、請求項５に記載の中央電力グリッドシステム。
7. 前記複数の入力コネクタルーチンは、前記複数のヘッドエンドシステムのそれぞれと通信するための独立した少なくとも１つの入力コネクタルーチンをさらに含み、
   前記複数の出力コネクタルーチンは、前記複数の計器データ管理システムのそれぞれと通信するための少なくとも１つの出力コネクタルーチンをさらに含む、請求項１に記載の中央電力グリッドシステム。
8. 前記ヘッドエンドシステムのそれぞれは、独立した入力コネクタルーチンに関連し、
   前記計器データ管理システムのそれぞれは、独立した出力コネクタルーチンに関連する、請求項７に記載の中央電力グリッドシステム。
9. 前記中央電力グリッドシステムは、前記ゲートウェイレイヤと前記コアレイヤとの間をインターフェース接続するコネクタサービスインターフェースレイヤをさらに含み、前記コネクタサービスインターフェースレイヤは、前記ゲートウェイレイヤによる通信の受信に応答して、前記コアレイヤを呼び出す、請求項１に記載の中央電力グリッドシステム。
10. 前記コアアダプタは、前記複数の前記ソースシステムのそれぞれから前記複数のターゲットシステムのそれぞれへの通信の１対１変換を実行するようさらに構成されている、請求項１に記載の中央電力グリッドシステム。
11. 前記コアアダプタは、前記複数の前記計器データ管理システムのそれぞれから前記複数のヘッドエンドシステムのそれぞれへの通信の１対１変換を実行するよう構成されている、請求項１０に記載の中央電力グリッドシステム。
12. 前記コアアダプタは、前記複数の前記ヘッドエンドシステムのそれぞれから前記複数の計器データ管理システムのそれぞれへの通信の１対１変換を実行するようさらに構成されている、請求項１１に記載の中央電力グリッドシステム。
13. 電力グリッドの少なくとも一部を管理し、複数の計器データ管理システムおよび複数のヘッドエンドシステムと通信する、中央電力グリッドシステムであって、前記計器データ管理システムは、コマンドを生成し、前記ヘッドエンドシステムは、１つ以上の計器と通信し、前記中央電力グリッドシステムは、
    プロセッサとメモリを含むコンピューティング・デバイスであって、
    複数の入力コネクタルーチンおよび複数の出力コネクタルーチンを含むゲートウェイレイヤであって、前記複数の入力コネクタルーチンは、前記中央電力グリッドシステムへデータを送信する複数のソースシステムのそれぞれと通信するための独立した複数の入力コネクタルーチンを含み、前記ソースシステムは、前記中央電力グリッドシステムへデータを送信する前記複数のヘッドエンドシステムを含み、前記複数の出力コネクタルーチンは、複数のターゲットシステムのそれぞれと通信するための独立した複数の出力コネクタルーチンを含み、前記ターゲットシステムは、前記中央電力グリッドシステムからデータを受信する前記複数の計器データ管理システムを含む、前記ゲートウェイレイヤと、
    前記ゲートウェイレイヤとは通信するが、前記ソースシステムおよび前記ターゲットシステムとは通信しないコアレイヤであって、前記ゲートウェイレイヤにより前記複数のソースシステムから受信した通信が前記複数のターゲットシステムによる受信に適合するように、１対１変換を実行するように構成された複数のコアアダプタを含む、前記コアレイヤと、
    を実行させるように構成された、前記コンピューティング・デバイス
    を含む中央電力グリッドシステム。
14. 前記ゲートウェイレイヤと前記コアレイヤとの間をインターフェース接続するコネクタサービスインターフェースレイヤをさらに含み、前記コネクタサービスインターフェースレイヤは、前記ゲートウェイレイヤによる通信の受信に応答して、前記コアレイヤを呼び出す、請求項１３に記載の中央電力グリッドシステム。
15. 前記コアアダプタは、前記複数の前記ソースシステムのそれぞれから前記複数のターゲットシステムのそれぞれへの通信の１対１変換を実行するようさらに構成されている、請求項１３に記載の中央電力グリッドシステム。
16. 前記中央電力グリッドシステムへ送信される前記データは、前記複数のヘッドエンドシステムにより送信される定期的な計器読み取りを含む、請求項１３に記載の中央電力グリッドシステム。

Images