JP2013523019A - インテリジェントネットワーク - Google Patents

Abstract

ネットワークインテリジェンスシステムは、全体にわたって位置する複数のセンサーおよび産業システムを含むとよい。センサーは、産業ネットワークの様々な側面に関するデータを取得するとよい。ネットワークインテリジェンスシステムは、システムエンドポイントインテリジェンスおよびシステムインフラストラクチャインテリジェンスを含むとよい。システムエンドポイントおよびシステムインフラストラクチャインテリジェンスは、分散型インテリジェンスを提供して、システム動作および発生に応じ、それに基づいて産業システム内で局所的な意思決定が行われることを可能にするとよい。ネットワークインテリジェンスは、エンドポイントおよびインフラストラクチャインテリジェンスと通信するための集中型インテリジェンス部を含むとよい。集中型インテリジェンス部は、システムの局所的なレベルまたはシステム全体レベルで応答を提供するとよい。
【選択図】図２０

Description

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

１．発明の分野
本発明は、全般的に、産業ネットワークを管理するシステムおよび方法に関し、特に、産業ネットワークを管理するために、産業ネットワークの種々のセクションにおいてデータを収集し、収集されたデータを分析するシステムおよび方法に関する。

２．関連技術
様々な産業が、それに関連するネットワークを有する。産業には、ユーティリティ（ｕｔｉｌｉｔｙ）、電気通信、輸送手段運行（ｖｅｈｉｃｌｅ ｔｒａｖｅｌ）（航空運行、鉄道運行、自動車運行、バス運行など）およびエネルギー探鉱（油井、天然ガス井など）が含まれ得る。

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

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

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

もう１つの上記産業は、輸送手段運行産業である。輸送手段運行産業は、一般に、航空機、列車、自動車、バスなど、１つ以上のタイプの運送手段の移動を管理することに関係する。例えば、列車産業は、鉄道線路、鉄道線路上を走行する列車、中央制御、および鉄道線路／列車を制御するためのネットワークを含む。ネットワークには、鉄道線路の様々な部分を感知するセンサー、中央制御との通信を行う手段、および鉄道路線を制御する手段が含まれ得る。典型的には、鉄道産業のネットワークは原始的である。具体的には、使用されるセンサーのタイプ、中央制御との通信を行う手段、および鉄道線路を制御する能力が、ネットワークによって制限されている。したがって、鉄道線路の管理を改善する必要があることは明らかである。

産業システムの管理を改善するインテリジェントネットワークが提供される。インテリジェントネットワークは、カスタマイズ可能で、１つ以上の産業に適用されるとよい。例としては、ユーティリティ産業および輸送手段運行産業（航空運行ネットワーク、鉄道運行ネットワーク、自動車運行ネットワーク、バス運行ネットワークなど）への適用がある。さらに、インテリジェントネットワークは、カスタマイズされて電気通信ネットワークおよびエネルギー探鉱に適用されてもよい。

インテリジェントネットワークは、１つ以上のシステムエンドポイントを含むとよい。システムエンドポイントは、産業システムの様々な条件を監視してその条件を示すデータを生成する、１つ以上のエンドポイントセンサーを含むとよい。システムエンドポイントは、システムエンドポイントデータを処理してデータに基づき任意の適切な決定を生成する、エンドポイント解析を含むとよい。

インテリジェントネットワークは、産業システムインフラストラクチャの様々な条件を監視してその条件を示すデータを生成する、１つ以上のインフラストラクチャセンサーを含むシステムインフラストラクチャを含むとよい。システムインフラストラクチャは、データを処理してデータに基づき任意の適切な決定を生成する、インフラストラクチャ解析を含むとよい。システムインフラストラクチャはさらに、システムエンドポイントからデータを受信して、適切な決定を生成するとよい。

システムエンドポイントおよびシステムインフラストラクチャは、産業システム内の、対象となる発生（ｏｃｃｕｒｒｅｎｃｅ）を示すイベントデータを生成するとよい。システムエンドポイントおよびシステムインフラストラクチャはさらに、産業システムを示す運用および非運用データを生成するとよい。インテリジェントネットワークは、イベントデータおよび運用／非運用データをインテリジェントネットワークのネットワークコアに提供する１つ以上のバスを含むとよい。ネットワークコアは、受信されたデータを分析して、産業システムの中の局所的または全体的であるとよい決定を生成する、システム解析を含むとよい。ネットワークコアはさらに、受信されたデータを、後のレビューおよび分析のために読み出せるよう記憶するために使用される、データ収集を含んでもよい。ネットワークコアはさらに、システム産業の様々な側面を制御するために使用されるシステム制御を含むとよい。システム制御は、様々な決定が下された場合に実行されてよく、システムの操作を要求してもよい。インテリジェントネットワークはさらに、ネットワークコアと通信しているエンタープライズシステムを含んでもよい。

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

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

概要として、以下に記載される好適な実施形態は、産業ネットワークを管理する方法およびシステムに関する。出願人は、ユーティリティおよび輸送手段運行ネットワーク（航空運行ネットワーク、鉄道運行ネットワーク、自動車運行ネットワーク、バス運行ネットワークなど）などの様々な産業ネットワークに関する以下の例を提供する。なお、電気通信ネットワークおよびエネルギー探鉱ネットワーク（油井のネットワーク、天然ガス井のネットワークなど）を含む、他の産業ネットワークが使用されてもよい。

以下でさらに詳しく説明するように、一部の側面は、電力グリッド自体などのユーティリティネットワーク（送電および／または配電におけるハードウェアおよびソフトウェアを含む）、または輸送手段運行ネットワークに関する。さらに、一部の側面は、電力グリッドの中央管理などのユーティリティネットワークの中央管理、および輸送手段運行ネットワークの中央管理の機能的能力に関する。こうした機能的能力は、動作およびアプリケーションの２つのカテゴリにグループ化され得る。動作サービスは、ユーティリティが、ユーティリティネットワークインフラストラクチャ（アプリケーション、ネットワーク、サーバ、センサーなど）を監視および管理できるようにする。

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

以下、図２０を参照する。様々な産業の産業システムに適用され得る、例示のインテリジェントネットワークデータエンタープライズ（ＩＮＤＥ）アーキテクチャ２０００を示すブロック図が示されている。一例では、ＩＮＤＥアーキテクチャは、ネットワークコア２００２を含むとよい。ネットワークコア２００２は、特定の使用産業に基づく様々なタイプの情報および／またはデータを受信するとよい。特定の産業のデータおよび情報は、産業システムに関する様々なポイントを表すとよいシステムエンドポイント２００６にて生じるとよい。各システムエンドポイント２００６は、産業システムに関連する様々な条件を検出するとよいいくつかのエンドポイントセンサー２０１４を含むとよい。例えば、エンドポイントセンサー２０１４は、ユーティリティグリッドにおける送電線潮流、または航空会社の到着／出発問題の検出専用とされてもよい。各システムエンドポイント２００６は、１つ以上のプロセッサおよびメモリデバイスを含み、局所的な解析の実行を可能にするとよい。一例では、エンドポイント解析２０１６は、エンドポイントセンサー２００６から受信されたデータに基づき様々なイベントを判断するとよい。

ＩＮＤＥアーキテクチャ２０００はさらに、産業システム全体にわたってシステムエンドポイント２００６をサポートするとよいシステムインフラストラクチャ２００８を含むとよい。システムインフラストラクチャ２００８は、産業システムに関連する諸条件を検出するために産業システム全体にわたって分散したインフラストラクチャセンサー２０２２を含むとよい。一例では、システムインフラストラクチャ２００８は、インフラストラクチャ解析２０２０を含み、インフラストラクチャセンサー２０２２から受信されたデータをシステムインフラストラクチャが分析できるとよい。

ネットワークコア２００２は、システムエンドポイント２００６およびシステムインフラストラクチャ２００８から情報を受信するとよい。一例では、ＩＮＤＥアーキテクチャ２０００は、運用／非運用バス２０１０およびイベントバス２０１２などのいくつかのバスを含むとよい。運用／非運用バス２０１０は、運用および非運用データ両方を伝達するために使用されるとよい。一例では、運用データは、ＩＮＤＥアーキテクチャ２０００を実装している特定の産業システムの様々な動作に関連するデータを指すとよい。非運用データは、特定の産業システム自体に関する側面に関連した産業内のデータを指すとよい。イベントバス２０１２は、産業システムにおいて生じる様々なイベントに関するデータを受信するとよい。イベントは、産業システムにおける、対象となる任意の発生を指すとよい。したがって、イベントは、産業システムにおいて生じる、好ましくない条件または異常な条件を含むとよい。

ＩＮＤＥアーキテクチャ２０００は、アーキテクチャの様々なコンポーネントが、データを処理して適切な出力を判断するために使用され得るという点において、分散型のインテリジェンスを実装することもできる。一例では、エンドポイント解析２００６は、１つ以上のプロセッサ、メモリデバイスおよび通信モジュールを含み、エンドポイントセンサー２００６によって受信されるデータに基づき処理が実行されることを可能にするとよい。例えば、エンドポイント解析２０１６は、エンドポイントセンサー２０１４からイベントに関するデータを受信するとよく、そのデータに基づき、特定のイベントが生じていることを判断するとよい。エンドポイント解析２０１６は、イベントに基づき適切な応答を生成するとよい。

同じく、インフラストラクチャ解析２０２０は、１つ以上のプロセッサ、メモリデバイスおよび通信モジュールを含み、インフラストラクチャセンサー２０２２によって受信されるデータに基づき処理が実行されることを可能にするとよい。システムインフラストラクチャ２００８は、システムエンドポイント２００６と通信し、システムインフラストラクチャ２００８は、インフラストラクチャ解析２０２０を利用して、システムエンドポイント２０１４およびインフラストラクチャセンサー２０２２からのイベントデータならびに運用／非運用データを評価および処理できるとよい。

データはさらに、バス２０１０および２０１２によって提供されるネットワークコア２００２によって評価されてもよい。一例では、ネットワークコア２００２は、センサー解析２０２６およびイベント解析２０２８を含むシステム解析２０２４を含むとよい。解析２０２６および２０２８は、１つ以上のプロセッサおよびメモリデバイスを含み、イベントデータおよび運用／非運用データの分析を可能にするとよい。一例では、センサー解析２０２４は、エンドポイントセンサー２０１４およびインフラストラクチャセンサー２０２２からのセンサーデータを評価するとよい。イベント解析２０２８では、イベントデータを処理および評価するために使用されるとよい。

ネットワークコア２００２はさらに、データ収集２０３０を含むとよい。データ収集２０３０は、生データおよび処理されたデータを記憶するために使用される様々なデータウェアハウス２０３２を含み、これは、過去データが必要に応じて読み出されることを可能にし、将来行われる解析が過去データに基づくことを可能にするとよい。

ネットワークコア２００２は、システム制御２０３４も含むとよい。システム制御２０３４は、産業システム内で取られるアクションに関与するとよい。例えば、システム制御２００２は、イベントデータおよび／または運用／非運用データに基づき産業システムの様々な側面を自動的に制御する自動制御２０３６を含むとよい。ネットワークコア２００２はさらに、イベントデータおよび／または運用／非運用バスに基づいても基づかなくてもよい産業システムの人的制御を可能にするユーザ制御２０３８を含むとよい。

エンタープライズシステム２００４は、産業向けの様々な大規模ソフトウェアパッケージを含むとよい。エンタープライズシステム２００４は、情報技術（ＩＴ：ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ）などの当該機能または産業に関係する他の側面で用いるデータを、ネットワークコア２００２と送受信するとよい。他の例では、バス２０１０および２０１２は、単一バスに統合されても、追加のバスを含んでもよい。さらに、他の例は、様々なサブシステムを含むシステムインフラストラクチャ２００８を含んでもよい。

以下、図２９を参照する。ＩＮＤＥアーキテクチャ２０００の例示の運用図が示されている。一例では、システムエンドポイント（ＳＥ（ｓｙｓｔｅｍ ｅｎｄｐｏｉｎｔ）１）２００６が、イベントＥ（ｅｖｅｎｔ）１の発生を判断するとよい。別のシステムエンドポイント（ＳＥ２）２００６が、イベントＥ２の発生を判断するとよい。各システムエンドポイント２００６は、イベントデータによってシステムインフラストラクチャ２００８にイベントＥ１およびＥ２をレポートするとよい。システムインフラストラクチャ２００８は、イベントデータを分析して、決定Ｄ（ｄｅｃｉｓｉｏｎ）１を生成するとよく、これがシステムエンドポイントＳＥ１およびＳＥ２に伝送されて、システムエンドポイントが応答を実行できるようにするとよい。

別の例では、イベントＥ３が、システムエンドポイントＳＥ１によって判断されるとよい。イベントＥ３をレポートするイベントデータはネットワークコア２００２に伝送されて、ネットワークコア２００２が、システム制御２０３４を介して、システム解析２０２４を実行して決定Ｄ２を生成できるようにするとよい。決定Ｄ２は、システムエンドポイントＳＥ１に提供されるとよい。

別の例では、システムエンドポイントＳＥ１が、イベントＥ４の発生を判断して、イベントデータによってイベントＥ４をネットワークコア２００２に通知するとよい。ネットワークコア２００２は、決定Ｄ３を生成して、それを、実行のためにシステムエンドポイントＳＥ１に提供するとよく、その一方で、決定Ｄ３に関する情報をエンタープライズシステム２００４に提供する。

別の例では、システムエンドポイントＳＥ１は、イベントＥ５の発生を判断するとよい。システムエンドポイントＳＥ１は、エンドポイント解析２０１６を実行して、決定Ｄ４を判断し、続いて実行するとよい。決定Ｄ４は、システムインフラストラクチャ２００８およびネットワークコア２００２に、通知および記憶のために提供されるとよい。図２９に関する例は、例示であり、他のイベント、運用データおよび非運用データが、ＩＮＤＥシステム２００２によって伝達され得る。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

別のＩＮＤＥ上位アーキテクチャの説明
一例では、モバイルおよび固定センサーの両方を含む産業に、全体的なＩＮＤＥアーキテクチャが適用されてもよい。ＩＮＤＥアーキテクチャは、センサーデータを受信して、それに応じて分散型および集中型両方のインテリジェンスによって応答するよう実装されるとよい。図２１〜２８は、様々な輸送手段運行産業において実装されたＩＮＤＥアーキテクチャの例を示す。

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

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

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

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

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

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

一般的な産業の例では、図面は、（１）ＩＮＤＥ ＣＯＲＥ２１２０および（２）ＩＮＤＥ ＤＥＶＩＣＥ２１８８など、全体的なアーキテクチャ内の種々の構成要素を示す。全体的なアーキテクチャ内で構成要素をこのように分割しているのは、説明のためである。構成要素のこのほかの分割が使用されてもよい。さらに、構成要素の分割は、種々の産業に関して異なってもよい。ＩＮＤＥアーキテクチャは、インテリジェンスに対する分散型および集中型どちらの手法をサポートするためにも使用されてよく、大型実装の規模に対応するメカニズムを提供するために使用されてもよい。

ＩＮＤＥ参照アーキテクチャは、実装され得る技術アーキテクチャの一例である。例えば、後述するように、ＩＮＤＥ参照アーキテクチャをメタアーキテクチャの例とし、これを、産業ソリューション毎に１つ（例えば、別々の産業に別々のソリューション）、または産業における適用毎に１つ（例えば、第１の輸送手段運行ネットワークに第１のソリューションおよび第２の輸送手段運行ネットワークに第２のソリューション）、任意数の具体的技術アーキテクチャを開発するための開始点を提供するために使用することもできる。したがって、特定の産業、または産業内の特定の適用（特定のユーティリティへの適用など）に対する具体的ソリューションは、ＩＮＤＥ参照アーキテクチャ内の構成要素の１つ、いくつかまたはすべてを含むとよい。さらに、ＩＮＤＥ参照アーキテクチャは、ソリューション開発の標準化された開始点を提供するとよい。特定の産業または産業内の特定の適用に対する具体的な技術アーキテクチャを判断する手順について後述する。

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

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

ＩＮＤＥ ＣＯＲＥ
図２２は、図２１Ａ〜Ｃに示されているように、ＩＮＤＥ参照アーキテクチャのうち、動作制御センターに存在するとよい部分である、ＩＮＤＥ ＣＯＲＥ２１２０を示す。ＩＮＤＥ ＣＯＲＥ２１２０は、データを記憶するための統一データアーキテクチャと、そのデータに対して作用する解析の統合スキーマとを含むとよい。

さらに、このデータアーキテクチャは、他のタイプのデータ（例えばセンサーデータ、運用および過去データ、ログならびにイベントファイルなど）、ならびに接続性およびメタデータファイルを、エンタープライズアプリケーションを含む上位アプリケーションによるアクセスのための単一エントリポイントを有するとよい単一データアーキテクチャに関連付けるために、連合ミドルウェア２１３４を使用するとよい。さらに、リアルタイムシステムが、高速データバスを介して主要データストアにアクセスするとよく、いくつかのデータストアがリアルタイムデータを受信することができる。種々のタイプのデータが、ＩＮＤＥアーキテクチャ内の１つ以上のバス内で搬送されるとよい。

搬送されるデータのタイプは、動作および非運用データ、イベント、ネットワーク接続性データならびにネットワーク位置データを含むとよい。運用および非運用データは、運用／非運用データバス２１４６を使用して搬送されるとよい。データ収集アプリケーションが、データの一部または全部を運用／非運用データバス２１４６へ送信することを担当するとよい。こうして、情報を得るための登録をすること、またはこのデータを利用可能にできるサービスを呼び出すことにより、この情報を必要とするアプリケーションがデータを得られるとよい。

イベントは、後述するように、産業ネットワークの一部である様々なデバイスおよびセンサーから生じるメッセージおよび／またはアラームを含むとよい。イベントは、上のデバイスおよびセンサーから直接生成されてもよく、さらに、こうしたセンサーおよびデバイスからの測定データに基づいて様々な解析アプリケーションにより生成されてもよい。

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

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

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

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

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

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

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

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

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

図２１はさらに、ＩＮＤＥ ＣＯＲＥ２１２０とは別の、動作制御センター２１１６内のさらなる構成要素を示す。具体的には、図２１はさらに、計器との通信（それらからデータを収集して収集したデータをユーティリティに提供するなど）を担当するシステムである、センサーデータ収集ヘッドエンド（単数または複数）２１５３を示す。ＩＰネットワークサービス２１５８は、ＩＰ型通信（ＤＨＣＰおよびＦＴＰなど）をサポートする１つ以上のサーバ上で動作するサービスの集合である。モバイルデータ送信システム２１５９は、現場のモバイルデータ端末とメッセージを送受信するシステムである。作業管理システム２１５０は、作業命令を監視および管理するシステムである。地理情報システム２１４９は、アセットが地理的にどこに位置し、各アセットがどのように接続されているかについての情報を含むデータベースである。環境がサービス指向アーキテクチャ（ＳＯＡ）を有する場合、動作ＳＯＡサポート２１４８は、ＳＯＡ環境をサポートするサービスの集合である。

動作制御センター２１１６内にありＩＮＤＥ Ｃｏｒｅ２１２０外にあるシステムのうちの１つ以上は、ユーティリティが有することもあるレガシー製品システムである。こうしたレガシー製品システムの例には、動作ＳＯＡサポート２１４８、センサーデータ収集ヘッドエンド（単数または複数）２１５３、ＩＰネットワークサービス２１５８およびモバイルデータ送信システム２１５９が含まれる。なお、こうしたレガシー製品システムは、スマートグリッドから受信されるデータを処理または操作することができなくてもよい。ＩＮＤＥ Ｃｏｒｅ２１２０は、スマートグリッドからデータを受信し、スマートグリッドからのデータを処理し、処理したデータを１つ以上のレガシー製品システムへ、レガシー製品システムが使用できる形（レガシー製品システムに特有の特定のフォーマッティングなど）で転送することができるとよい。このように、ＩＮＤＥ Ｃｏｒｅ２１２０はミドルウェアと見なされてもよい。

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

ＩＮＤＥ ＤＥＶＩＣＥ
ＩＮＤＥ ＤＥＶＩＣＥ２１８８グループは、特定のデバイスに関連するデータを提供するために使用される任意の種類のデバイスを含み得る。一例では、デバイスグループ２１８８は、固定センサーユニット２１９０およびモバイルセンサーユニット２１９２を含むとよい。固定センサーユニット２１９０およびモバイルセンサーユニット２１９２はそれぞれ、センサーからの任意のデータの受信、ならびにその後の処理、および／または生のセンサーデータもしくは処理されたセンサーデータの伝送を可能にする、１つ以上のセンサー、プロセッサ、メモリデバイス、通信モジュールおよび／または電力モジュールを含むとよい。固定センサーユニット２１９０およびモバイルセンサーユニット２１９２からの生のセンサーデータまたは処理されたセンサーデータは、１つ以上のゲートウェイ２１９４によって処理されるとよい。一例では、各ゲートウェイ２１９４は、データを符号化して動作制御センター２１１６に伝送することができる１つ以上のデバイスであるとよい。固定センサーユニット２１９０およびモバイルセンサーユニット２１９２からの生のセンサーデータまたは処理されたセンサーデータはさらに、データコレクタ２１９６に提供されるとよい。データコレクタ２１９６は、１つ以上のプロセッサ、メモリデバイス、通信モジュールおよび電力モジュールを含むとよい。データコレクタ２１９６は、データを収集、記憶および伝送するよう構成されたメモリデバイスおよびプロセッサであるとよい。データコレクタ２１９６は、固定センサーユニット２１９０およびモバイルセンサーユニット２１９２と通信して、データを収集し、収集されたデータを１つ以上のゲートウェイ２１９４に伝送するとよい。

一例では、固定センサーユニット２１９０は、モバイルセンサーユニット２１９２または他の固定センサーユニット２１９０のうちの１つ以上に関連する条件を検出してもよい。モバイルセンサーユニット２１９２は、固定センサーユニット２１９２に関連する条件を検出してもよく、または他のモバイルセンサーユニット２１９２に関連する他の条件を検出してもよい。動作中、イベントデータが、固定センサーユニット２１９０およびモバイルセンサーユニット２１９２によって生成されるとよい。イベントデータは、輸送手段運行ネットワークの異常条件または好ましくない条件を示すとよい。そのようなイベントデータは、固定センサーユニット２１９０およびモバイルセンサーユニット２１９２から、ゲートウェイ２１９４を通して中央局に伝送されるとよい。一例では、イベントデータは、ルーティングデバイス２１８９によって受信されるとよい。イベントデータは、ルーティングデバイス２１８９によってイベントバス２１４７に提供されるとよい。受信されたイベントデータは、適切な応答の生成を可能にするよう、動作制御センター２１１６によって処理されるとよい。

図２４Ａ〜２４Ｃは、鉄道運行ネットワークとともに動作するＩＮＤＥアーキテクチャのブロック図である。図２４Ａ〜２４ＢのＩＮＤＥシステムは、図２５に示されているように、固定センサーユニット２１９０および鉄道車両２４００上に置かれたモバイルセンサーユニット２１９２からイベントデータを受信するとよい。一例では、固定センサーユニット２１９０およびモバイルセンサーユニット２１９２は、参照によって本願明細書に引用したものとする米国特許出願公開第２００９／０１７３８４０号で開示されているものであってもよい。

図２５を参照する。一例では、貨物列車２５００は、有蓋車、車掌車、石炭車、エンジン車および鉄道によって移送されるよう構成されたその他任意の車両など、様々なタイプの鉄道車両２４００を含むとよい。エンジン車２５０２は、ディーゼルエンジン、バッテリー、フライホイール、燃料電池またはその任意の組み合わせによって電力を供給され得る。各鉄道車両２４００は、１つ以上のモバイルセンサーユニット２１９２を含むとよい。モバイルセンサーユニット２１９２は、互いに通信し、同じ鉄道車両２４００、または鉄道車両２４００の同じ列に連結された異なる鉄道車両２４００、または車両基地に位置するものなど列から分離された他の鉄道車両２４００（図示せず）のモバイルセンサーユニット２１９２間の通信を可能にするとよい。各モバイルセンサーユニット２１９２は、固有のＩＤを有するとよく、特定の鉄道車両２４００はそれぞれ、その特定の鉄道車両２４００に関連する各モバイルセンサーユニット２１９２によって保持される固有のＩＤを有するとよい。ＩＤは、例えばＲＦＩＤを介して提供されてもよい。

一例では、固定センサーユニット２１９０Ａは、鉄道車両の車輪、車軸などに関連する温度上昇を監視するよう構成された「熱軸箱」検出器として機能するよう構成されているとよい。「熱軸箱」という用語は、当該技術分野で周知のように、１つの鉄道車両の、１つ以上の車軸軸受および／または車輪をベースとする他のコンポーネントにおいて過熱が生じている鉄道車両を指すとよい。固定センサーユニット２１９０Ａは、鉄道線路の軌道２５０１に沿って配置されるとよい。鉄道車両が特定の固定センサーユニット２１９０Ａの感知ゾーンを通過するときに鉄道車両２４００の軸受、車軸、車輪の温度上昇パターンを判断するために、各固定センサーユニット２１９０Ａには１つ以上の赤外線（ＩＲ：ｉｎｆｒａｒｅｄ）センサーが備えられているとよい。異常な温度上昇は、鉄道車両の荷重の不均衡、鉄道車両の構造上の問題、軌道の問題などの様々な問題を示すこともある。過熱した軸受が検出されると、一種のアラームがトリガされ、列車を停止して、持続させると列車の脱線を生じ得る潜在的に危険な状況を修正するよう、技術者に警報を出すことが可能である。熱軸箱検出器の例は、参照によって本願明細書に引用したものとする米国特許第４，６５９，０４３号において開示されている。固定センサーユニット２１９０Ａは、ＩＲセンサーデータを処理して、その後の処理のためにイベントバス２１４７によって受信されるように、イベントメッセージなど、アラームに基づくイベントデータを生成するよう構成されているとよい。

固定センサーユニット２１９２Ｂはさらに、障害検出器としての機能を果たすとよい。障害検出器は、通過する列車における車軸および信号の問題を検出するために鉄道線路上で使用されるデバイスであるとよい。障害検出器は、鉄道軌道へと統合されることが可能であり、生じる可能性がある１つ以上の種類の問題を検出するセンサーを含むとよい。障害検出器によって、鉄道線路は、列車後部の車掌車、ならびに危険条件を発見するよう経路に沿って配備される様々な駅員を省くことができるようになる。障害検出器は、有線または無線の送信機と統合されるか、または関連しているとよい。障害検出器を列車が通過するとき、障害検出器は、鉄道線路名、距離標または位置、軌道番号（該当する場合）、通過した列車の車軸の数および列車で問題が検出されなかったことを示す指示「障害なし」を出力してもよい。さらに、その位置の周囲温度および列車速度が出力されてもよい。問題が検出されると、検出器は、アラーム指示、続いて問題の説明、および列車内での、問題が生じた車軸の場所を出力するとよい。

固定センサーユニット２１９０Ｃはさらに、１つ以上の固定センサーユニット２１９０Ａおよび２１９０Ｂによって受信された生のデータまたは処理されたデータを受信するよう構成された、当該技術分野で周知の「シルバーボックス（ｓｉｌｖｅｒ ｂｏｘｅｓ）」として機能するよう構成されているとよい。固定センサーユニット２１９２Ｃは、例えば地理的位置などの様々な共通要素に基づく、固定センサーユニット２１９０Ａの個々のグループからデータを受信するとよい。この関連で、固定知覚ユニット２１９０Ｃは、図２１Ａ〜２１Ｃに示されている、データコレクタ２１９６として機能するとよい。

動作中、鉄道車両２４００の列を有する列車２５００は、鉄道軌道２５０２に沿って運行するとよい。列車２５００が運行するとき、固定センサーユニット２１９０Ａは、軸受温度など、各鉄道車両２４００に関する情報を検出するとよい。各固定センサーユニット２１９０Ａはさらに、各モバイルセンサーユニット２１９２と通信するとよい。通信によって、各固定センサーユニット２１９０Ａが、各鉄道車両２４００および関連するモバイルセンサーユニット２１９２の正常性チェックを実行できるとよい。特定の鉄道車両２４００に関連する異常条件または好ましくない条件の任意の指示が、固定センサーユニット２１９０Ｃに中継されるとよい。検出される条件は、鉄道車両の構造、鉄道車両の環境（例えば温度）、鉄道車両の中身（例えば重量、分布、量など）、鉄道車両の動き、鉄道車両の場所、またはその他、鉄道車両２４００に関する対象となる任意のパラメータに関するとよい。さらに、検出される条件はセキュリティに関係してもよい。例えば、鉄道車両のドアが開いている場合などであり、これは窃盗または破壊行為の試みを示すこともある。イベントデータ２５０８は、特定の鉄道車両を所有していることもある特定の組織に警報を出すために使用されてもよい。したがって、動作制御センター２１１６は、鉄道路ネットワーク全体を監視するとよいが、特定の企業によって所有される特定の鉄道車両（単数または複数）２４００に関してイベントデータが伝送されると、個別の鉄道車両２４００を所有している企業に対し警報が出されてもよい。警報メッセージは、インターフェース、契約サービス、電子メール、テキストメッセージおよび／またはその他、そうした警報を提供できる任意の通信方式によって提供されるとよい。

一例では、エンジン２５０２など、鉄道車両２４００のうちの１つが、現在の鉄道車両の列の鉄道車両２４００に関連する各モバイル固定ユニット２１９２からデータを受信するマスターモバイルセンサーユニット２５０４としての機能を果たすモバイルセンサーユニット２１９２を有するとよい。鉄道車両２４００が、特定の列車を形成するよう接続されるとき、各モバイルセンサーユニット２１９２は、マスターモバイルセンサーユニット２５０４に登録するとよい。マスターモバイルセンサーユニット２５０４は、モバイルセンサーユニット２１９２から、生のデータまたは処理されたデータの定期的または連続的なストリームを受信するとよい。これは、使用中、エンジニアが各鉄道車両２４００の正常性を判断できるようにする。

一例では、各モバイルセンサーユニット２１９０は、グローバルポジショニングシステム（ＧＰＳ）モジュールを含み、個別のモバイルセンサーユニット２１９２それぞれが、個々の地理的位置を判断することができるとよい。各モバイルセンサーユニット２１９０は、ＧＰＳ信号２５０６を受信して地理的位置を判断するとよい。この情報は、当該情報の伝送が可能な近距離内に特定の鉄道車両があるときに、固定センサーユニット２１９２Ａに中継されるとよい。各モバイルセンサーユニット２１９２は、自動的に、またはリクエストがあると、地理的位置をマスターモバイルセンサーユニット２５０４に中継するとよく、これは続いて、車両内ゲートウェイ２１９４を通して動作制御センター２１１６に中継されるとよい。一例では、ゲートウェイ２１９４は、米国特許出願公開第２００９／０１７３８４０号に記載されているものであってもよい。各モバイルセンサーユニット２１９２Ａはさらに、ＧＰＳ信号を無線で伝送して、各鉄道車両２４００を個別に追跡可能にしてもよい。そのような構成は、列車がトンネル中を移動しているときなど、単一の鉄道車両のみがＧＰＳ衛星への確実なアクセスを有する場合に、列車全体が追跡されることを可能にするとよい。

固定センサーユニット２１９０およびモバイルセンサーユニット２１９２はそれぞれ、センサーデータの少なくとも一部、「イベント」を生成するとよい。イベントは、異変なし（ｎｏ−ｉｎｃｉｄｅｎｔ）イベントまたは異変イベントを含むとよい。異変なしイベントは、レポートする異変がない（故障がないなど）ことを示すとよい。異変イベントは、鉄道運行ネットワークのセクションで生じた、または生じている故障など、異変が生じた、または生じていることを示すとよい。

固定センサーユニット２１９０およびモバイルセンサーユニット２１９２は、（１）異変があるかどうかを判断するインテリジェンス、および（２）異変があるかどうかの判断に基づき１つ以上のアクションを取る能力のうちの一方または両方を含むとよい。具体的には、固定センサーユニット２１９０およびモバイルセンサーユニット２１９２のうちの１つ以上のメモリは、１つ以上のセンサーによって生成されたデータに基づき種々のタイプの異変を判断するための１つ以上のルールを含むとよい。または、固定センサーユニット２１９０およびモバイルセンサーユニット２１９２のメモリは、１つ以上のセンサーによって生成されたデータに基づき種々のタイプの異変を判断するための１つ以上のルックアップテーブルを含んでもよい。さらに、固定センサーユニット２１９０およびモバイルセンサーユニット２１９２は、異変があるかどうかの判断に基づき１つ以上のアクションを取る能力を含んでもよい。

鉄道運行ネットワーク内の電子構成要素は、単体で機能するだけでなく、鉄道運行ネットワークの分散型インテリジェンスの一部として協働するとよい。例えば、固定センサーユニット２１９０およびモバイルセンサーユニット２１９２は、データを共有するかまたは処理能力を共有し、異変があるかどうかを共同で判断し、異変があるかどうかの判断に基づき１つ以上のアクションを取ってもよい。

アクションは、次に限定はされないが、（１）異変の判断をイベントバス２１４７上で送信すること、（２）異変の判断を推奨されるアクションとともにイベントバス２１４７上で送信すること、および（３）鉄道運行ネットワークの１つ以上のセクションまたは鉄道運行ネットワーク上を運行している１つ以上の輸送手段の状態を変更するためにアクションを取ることを含む。例えば、固定センサーユニット２１９０は、鉄道運行ネットワークのセクション内の１つ以上のスイッチを制御してもよい（別の鉄道線路へ通行方向を変える、種々の方向への運行のためにレーンを開くなど）。または、固定センサーユニット２１９０は、鉄道運行ネットワークのセクション内の１つ以上のセンサーのパラメータを変更してもよい（読み取りの感度を上げるようセンサーに命令する、より頻繁な読み取りを生成するようセンサーに命令するなど）。さらに別の例として、固定センサーユニット２１９０およびモバイルセンサーユニット２１９２は、鉄道運行ネットワーク上を運行している１つ以上の輸送手段を制御してもよい。例えば、機関車は、リモートコマンド制御能力を含んでもよく、それによって機関車は、無線で伝送されたコマンドを受信して、機関車の１つ以上の側面を制御できてもよい。コマンドが制御する１つ以上の側面は、次に限定はされないが、機関車の速度、警笛（または他のタイプの音）の生成、および明かり（または他のタイプの可視指示）の生成を含んでもよい。機関車の受信機が、コマンドを受信するとよく、機関車のプロセッサが、コマンドに基づき機関車の１つ以上の側面を制御するとよい（エンジンの動作を変更するなど）。

鉄道運行ネットワークは、分散型インテリジェンスを含むとよい。上記のように、鉄道運行ネットワーク内の種々の固定センサーユニット２１９０およびモバイルセンサーユニット２１９２は、追加の処理／分析能力およびデータベースリソースを含む追加の機能性を含んでもよい。鉄道運行ネットワークにおいて、様々な固定センサーユニット２１９０およびモバイルセンサーユニット２１９２内でこの追加の機能性を使用することで、アプリケーションおよびネットワークパフォーマンスの集中管理および監督を伴う分散型アーキテクチャが可能になる。機能、パフォーマンスおよび拡張性のために、何千もの固定センサーユニット２１９０およびモバイルセンサーユニット２１９２を含む鉄道運行ネットワークが、分散型処理、データ管理およびプロセス通信を含むこともできる。

非運用データおよび運用データは、固定センサーユニット２１９０およびモバイルセンサーユニット２１９２に関連し近接しているとよい。固定センサーユニット２１９０およびモバイルセンサーユニット２１９２は、様々なセクションでの鉄道運行ネットワークの可観測性に関与する、鉄道運行ネットワークのコンポーネントをさらに含んでもよい。固定センサーユニット２１９０およびモバイルセンサーユニット２１９２は、運用データ獲得および分散型運用データストアでの記憶、非運用データの獲得およびヒストリアンでの記憶、ならびにリアルタイム（サブ秒など）でのローカル解析処理という３つの主要機能を提供するとよい。処理は、デジタル信号処理と、イベントストリーム処理を含む検出および分類処理と、処理結果のローカルシステムおよびデバイス、ならびに動作制御センター２１１６にあるシステムへの伝達とを含むとよい。鉄道運行ネットワーク内の固定センサーユニット２１９０およびモバイルセンサーユニット２１９２ならびに他のデバイス間の通信は、有線、無線、または有線と無線との組み合わせとしてもよい。電子構成要素は、動作／非運用データまたはイベントデータなどのデータを、動作制御センター２１１６へ伝送するとよい。ルーティングデバイスは、伝送されたデータを、運用／非運用データバスまたはイベントバスのうちの１つへルーティングするとよい。

１つ以上のタイプのデータが、電子構成要素および動作制御センター２１１６にて複製され、その結果、動作制御センター２１１６へのデータ通信ネットワークが有効でなくても電子構成要素が独立して動作できるようにするとよい。この情報（接続性）がローカルに記憶されていることで、動作制御センター２１１６への通信リンクが動作不能であっても解析がローカルで実行され得る。

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

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

あるいは、ローカル電子構成要素インスタンスのデータにデータベースリンクを使用してアクセスすることによって、動作制御センター２１１６レベルで、過去／集合的解析も実行されてもよい。

さらに、様々な解析が、データおよび／またはイベントの分析に使用されてもよい。１つのタイプの解析は、空間的可視化を含んでもよい。空間的可視化能力すなわち視覚空間能力は、２次元および３次元の図表を操作する能力である。空間的可視化は、１つ以上の電子構成要素を使用して実行されてもよく、または中央局によって実行されてもよい。さらに、空間的可視化は、ユーティリティネットワークおよび輸送手段運行ネットワークを含む、様々な産業ネットワークに使用されてもよい。

一例では、動作中、イベントデータ２５０８は、各モバイルセンサーユニット２１９２によって作り出されるとよい。イベントデータ２５０８は、マスターモバイルセンサーユニット２５０４に伝送されるとよい。マスターモバイルセンサーユニット２５０４は、ゲートウェイ２１９４を介して、処理のためにイベントデータをゲートウェイから動作制御センター２１１６へ無線で伝送するとよい。他の例では、各鉄道車両２４００は、データを鉄道車両２４００のモバイルセンサーユニットから直接伝送可能なように、個々のゲートウェイ２１９４を含んでもよい。これは、車両基地に格納されている鉄道車両など、鉄道車両２４００が、エンジン２５０２と繋がっていないときに通信を行い、動作制御センター２１１６によって受信されるべきイベントデータ２５０８を伝達できるようにする。その他の代わりの例では、各車両基地は、１つ以上の固定センサーユニット２１９０およびゲートウェイ２１９４を有し、格納された鉄道車両２４００と通信して任意のイベントデータ２５０８を伝送するとよい。同様の形で、固定センサーユニット２１９０Ａおよび２１９０Ｂは、固定センサーへのセンサーデータおよびイベントデータを、当該情報を動作制御センター２１１６に中継する同様のゲートウェイ（単数または複数）２１９４を通して伝送するとよい。

上記のように、図２４Ａ〜４Ｃのネットワークはさらに、イベントデータ２５０８が固定センサーユニット２１９０Ａおよび２１９０Ｂならびにマスターモバイルセンサーモジュール２５０４にて処理されるように、分散型分析を可能にしてもよい。そのような処理は、任意の問題が分析されることを可能にし、ソリューションまたは一連のアクションを提供するとよい。そのような問題ソリューションは、送られてもよく、列車２５００が許可するよう構成されている任意の能力内で列車２５００を自動的に制御するために使用されてもよく、またはそれに応じて列車２５００を制御するよう人的オペレーターに警報を出してもよい。ソリューションはさらに、動作制御センター２１１６に送られて、動作制御センター２１１６が、問題ソリューションを確認してそれに応じてソリューションを実装するためにリモートでアクションを実行できるようにしてもよい。

図２６Ａ〜２６Ｃは、通勤列車などの電車ネットワークに関するＩＮＤＥアーキテクチャの実装のブロック図である。電車ネットワークは、電力を供給された架空電線路または第三軌条であるとよい、１つ以上の電車を含むとよい。一例では、電車２６００は、１つ以上の車両２６０２を含むとよい。各車両は、外部ソース（例えば第三軌条または架空線路）または内部ソース（例えばバッテリーまたは燃料電池）によって個別に電力を供給されてもよい。各車両は、１つ以上のモバイルセンサーユニット２１９２を含むとよい。各モバイルセンサーユニット２１９２は、列車２６００の様々な所定のパラメータに関連する様々な条件を検出するとよい。

図２６Ａ〜２６Ｃに示されている例では、電車２６００は、第三軌条２６０４によって電力を供給されているとよい。第三軌条２６０４は、第三軌条２６０４を流れる電力を監視するとよい１つ以上の固定センサーモジュール２１９２に接続されているとよい。固定センサーモジュール２１９０は、鉄道システムの正常性を判断して、異常な、好ましくない、またはステータスチェックに関係する任意のイベントを、イベントメッセージの形式で伝送するとよい。イベントメッセージは、動作制御センター２１１６によって受信されるよう、ゲートウェイ２１９４によって伝送されるとよい。

各電気鉄道車両２６０２は、１つ以上のモバイルセンサーユニット２１９２を含むとよい。モバイルセンサーユニット２１９２のうちの１つは、マスターモバイルセンサーユニット２５０４などのマスターモバイルセンサーユニットとしての機能を果たすとよい。モバイルセンサーユニット２１９２は、図２５Ａ〜５Ｂに関して説明されたのと類似した形で、個々の鉄道車両に関する情報を蓄積するとよい。電車２６００のマスターモバイルセンサーユニットは、他のモバイルセンサーユニット２１９２によって生成されたイベントメッセージを、ゲートウェイ２１２０を介して中央局に伝送してもよい。

図２７Ａ〜２７Ｃは、トラック輸送産業で使用されるものなど、道路を基盤とした貨物搬送ネットワークに適用されたＩＮＤＥアーキテクチャの実装のブロック図である。一例では、１つ以上のモバイルセンサーユニット２１９２が、ディーゼルエンジントラック２７０４によって牽引されるものなどの貨物コンテナ２７００内に含まれるとよい。各モバイルセンサーユニット２１９２は、図２５Ａ〜２６Ｃに関して説明されたモバイルセンサーユニット２１９２と類似しているとよい。各モバイルセンサーユニット２１９２は、貨物コンテナ２７００の様々な条件を検出して、それらを、車両内ゲートウェイ２１９４を介して動作制御センター２１１６に中継するとよい。固定センサーユニット２１９０は、複数の顧客施設に分散され、固定センサーユニット２１９０およびモバイルセンサーユニット２１９２間の通信を使用して貨物がチェックされることを可能にしてもよい。モバイルセンサーユニット２１９２は、貨物追跡、貨物コンテナ環境、窃盗／破壊行為の検出、およびその他、図２４Ａ〜２５に関して記載された任意の適切な用途に使用されてもよい。

図２８Ａ〜２８Ｃは、ガソリン燃料、電気、ハイブリッド燃料、バイオ燃料、またはその他任意の適切な燃料方式による自動車のネットワークに適用された、全体的なＩＮＤＥアーキテクチャの実装のブロック図である。一例では、輸送手段２８００は、輸送手段２８００の様々な条件の監視を可能にする１つ以上のモバイルセンサーユニット２１９２を含むとよい。各輸送手段は、ゲートウェイ２１９４を含むか、または外部ゲートウェイ２１９４を通して通信して、イベントデータを直接ＩＮＤＥ ｃｏｒｅ１２０または他のモバイルセンサーユニット２１９２に伝達するとよい。説明済みの他の例と同様に、モバイルセンサーユニット２１９２は、輸送手段に関与する解析を実行するとよい分散型インテリジェンスを含んでもよく、またはＩＮＤＥ ｃｏｒｅ２１２０との対話によってそれを行ってもよい。モバイルセンサーユニット２１９２と通信するために固定センサーユニット２１９０が使用されてもよく、これにより、固定センサーユニット１９０と通信する近接したモバイルセンサーユニット２１９２を有する輸送手段８００の評価を行うことができる。固定センサーユニット２１９０は、イベントデータがＩＮＤＥ ＣＯＲＥ２１２０に伝送されることを可能にするゲートウェイ１９４を含むか、もしくは共有してもよく、またはそれを直接ＩＮＤＥ ＣＯＲＥ１２０に伝送してもよい。固定センサーユニット２１９０は、輸送手段２８００の条件および／または位置に関連するイベントデータを受信するために、貸自動車企業、自動車販売場または個人所有者によって実装されてもよい。

図３０は、ブロック図が示すように、リモートでホストされ得るＩＮＤＥシステム２０００の例を示す。ホスティングサイト３０００では、特定の産業のＩＮＤＳ契約者をサポートするために、必要に応じネットワークコア２００２が設置されるとよい。一例では、契約者３００２として、鉄道、トラック輸送および航空会社などの様々な産業の使用を要求してもよい。ＩＮＤＥシステム２０００は、モジュール方式であり、より多くの産業タイプの追加、または別の例では新たな契約者の追加が可能であるとよい。電気ユーティリティとは別の関係者が、ＩＮＤＥシステム２０００のうちの１つ、いくつかまたはすべてのソフトウェア、ならびにシステムエンドポイント２００６およびシステムインフラストラクチャ２００８に使用される、ＩＮＤＳホスティングサイトからダウンロードされるアプリケーションを管理およびサポートするとよい。通信を促進するために、契約ユーティリティの動作センターならびにＩＮＤＳホスティングサイトに到達することができるネットワーク３００４（例えばＭＰＬＳまたはその他のＷＡＮ）などを介した高帯域低遅延通信サービスが使用されるとよい。

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

Claims (20)

1. 産業ネットワークを管理する中央局との通信を促進する統合フレームワークであって、前記統合フレームワークは、
   前記産業ネットワークの少なくとも一部に関するリアルタイム測定値を含む運用データを前記中央局へ伝達する、バスの第１部分と、
   イベントデータを前記中央局へ伝達する、バスの第２部分であって、前記第２部分は、前記第１部分と別であり、前記イベントデータは、前記リアルタイム測定値とは異なり且つ前記リアルタイム測定値から得られ、前記イベントデータは、前記少なくとも１つのリアルタイム測定値に基づく少なくとも１つの分析判断を含む、前記第２部分と、
   を含み、
   前記運用データは、前記第１部分を介して伝達され、前記第２部分を介しては伝達されず、
   前記イベントデータは、前記第２部分を介して伝達され、前記第１部分を介しては伝達されない、統合フレームワーク。
2. 前記産業ネットワークは、輸送手段運行ネットワークを含む、請求項１に記載の統合フレームワーク。
3. 前記輸送手段運行ネットワークは、鉄道運行ネットワークを含む、請求項２に記載の統合フレームワーク。
4. 前記バスの前記第１部分は、第１セグメントを含み、前記バスの前記第２部分は、第２セグメントを含み、前記第１および第２セグメントは、同一バス上の別々のセグメントである、請求項１に記載の統合フレームワーク。
5. 受信されたデータの少なくとも一部を分析し、前記第１セグメントおよび前記第２セグメントのうちの１つへ前記データをルーティングする少なくとも１つのスイッチをさらに含む、請求項４に記載の統合フレームワーク。
6. 前記バスの前記第１部分は、前記運用データの伝達のみ専用の第１専用セグメントを含み、
   前記バスの前記第２部分は、前記イベントデータの伝達のみ専用の第２専用セグメントを含む、
   請求項４に記載の統合フレームワーク。
7. 前記バスの前記第１部分は、第１バスを含み、前記バスの前記第２部分は、第２バスを含み、
   前記第１バスは、前記第２バスと物理的に別である、
   請求項３に記載の統合フレームワーク。
8. 受信されたデータの少なくとも一部を分析し、前記第１バスおよび前記第２バスのうちの１つへ前記データをルーティングするルータをさらに含む、請求項７に記載の統合フレームワーク。
9. 前記ルータは、前記データを前記第１バスへルーティングするか、または前記第２バスへルーティングするかを判断するために、前記データ内の少なくとも１つのヘッダを分析する、請求項８に記載の統合フレームワーク。
10. 産業ネットワークと、前記ネットワークを管理する中央局とのためのデータ管理システムであって、前記ユーティリティネットワークは、前記産業ネットワーク内に複数のデバイスを含み、前記データ管理システムは、
    前記ネットワークの或るセクションに置かれたデバイスに関連するデータ記憶装置であって、前記データ記憶装置は、前記デバイスに近接しており、前記デバイスは、前記産業ネットワークの前記セクションにおけるパラメータを感知し、前記データ記憶装置は、前記感知されたパラメータを記憶する複数のメモリ位置を含む、前記データ記憶装置と、
    前記中央局に関連する中央データ記憶装置であって、前記データ記憶装置内の前記メモリ位置へのリンクを含む、前記中央データ記憶装置と、
    を含むデータ管理システム。
11. 前記産業ネットワークは、輸送手段運行ネットワークを含む、請求項１０に記載のデータ管理システム。
12. 前記輸送手段運行ネットワークは、鉄道運行ネットワークを含む、請求項１１に記載のデータ管理システム。
13. 産業システムのインテリジェントネットワークであって、
    前記産業システムに関する少なくとも１つの側面を検出して、前記少なくとも１つの側面を示すエンドポイントデータを生成するよう構成された複数のセンサー、および
    前記エンドポイントデータを受信して、前記エンドポイントデータに基づき応答を生成するよう構成された少なくとも１つのエンドポイント分析モジュール
    を含む少なくとも１つのシステムエンドポイントと、
    前記産業システムのインフラストラクチャに関する少なくとも１つの側面を検出して、前記少なくとも１つの側面を示すインフラストラクチャデータを生成するよう構成された複数のセンサー、および
    前記エンドポイントデータを受信して、前記エンドポイントデータに基づき応答を生成するよう構成された少なくとも１つのインフラストラクチャ分析モジュール
    を含むシステムインフラストラクチャと、
    １つ以上のデータバスと、
    前記データバスのうちの少なくとも１つ以上を通して前記エンドポイントデータおよび前記インフラストラクチャデータを受信して、前記エンドポイントデータおよび前記インフラストラクチャデータのうちの少なくとも１つに基づき応答を生成するよう構成されたネットワークコアと、
    を含むインテリジェントネットワーク。
14. 前記少なくとも１つのエンドポイント分析モジュールは、前記産業システム内で、前記エンドポイントデータに基づきイベントの発生を判断し、前記イベントに基づき少なくとも１つの応答を判断するよう構成されている、請求項１３に記載のインテリジェントネットワーク。
15. 前記少なくとも１つのインフラストラクチャ分析モジュールは、前記産業システム内で、前記インフラストラクチャデータに基づきイベントの発生を判断し、前記イベントに基づき少なくとも１つの応答を判断するよう構成されている、請求項１３に記載のインテリジェントネットワーク。
16. 前記少なくとも１つのインフラストラクチャモジュールは、
    前記エンドポイントセンサーデータを受信し、
    前記産業システム内で、前記エンドポイントデータに基づきイベントの発生を判断し、
    前記イベントに基づき少なくとも１つの応答を判断するよう構成されている、請求項１３に記載のインテリジェントネットワーク。
17. 前記ネットワークコアは、前記エンドポイントデータおよび前記インフラストラクチャデータのうちの少なくとも１つに基づきイベントを判断し、前記エンドポイントデータおよび前記インフラストラクチャデータのうちの前記少なくとも１つに基づき応答を生成するよう構成されている、請求項１３に記載のインテリジェントネットワーク。
18. 前記ネットワークコアと通信するよう構成されたエンタープライズシステムをさらに含む、請求項１３に記載のインテリジェントネットワーク。
19. 前記産業システムは、鉄道路システムである、請求項１３に記載のインテリジェントネットワーク。
20. 前記産業システムは、トラック輸送システムである、請求項１３に記載のインテリジェントネットワーク。

Images