"産業ネットワークを管理する中央局との通信を促進する統合フレームワークであって、前記統合フレームワークは、前記産業ネットワークの少なくとも一部に関するリアルタイム測定値を含む運用データを前記中央局へ伝達する、バスの第1部分と、イベントデータを前記中央局へ伝達する、バスの第2部分であって、前記第2部分は、前記第1部分と別であり、前記イベントデータは、前記リアルタイム測定値とは異なり且つ前記リアルタイム測定値から得られ、前記イベントデータは、前記少なくとも1つのリアルタイム測定値に基づく少なくとも1つの分析判断を含む、前記第2部分と、を含み、前記運用データは、前記第1部分を介して伝達され、前記第2部分を介しては伝達されず、前記イベントデータは、前記第2部分を介して伝達され、前記第1部分を介しては伝達されない、統合フレームワーク。前記産業ネットワークは、輸送手段運行ネットワークを含む、請求項1に記載の統合フレームワーク。前記輸送手段運行ネットワークは、鉄道運行ネットワークを含む、請求項2に記載の統合フレームワーク。前記バスの前記第1部分は、第1セグメントを含み、前記バスの前記第2部分は、第2セグメントを含み、前記第1および第2セグメントは、同一バス上の別々のセグメントである、請求項1に記載の統合フレームワーク。受信されたデータの少なくとも一部を分析し、前記第1セグメントおよび前記第2セグメントのうちの1つへ前記データをルーティングする少なくとも1つのスイッチをさらに含む、請求項4に記載の統合フレームワーク。前記バスの前記第1部分は、前記運用データの伝達のみ専用の第1専用セグメントを含み、前記バスの前記第2部分は、前記イベントデータの伝達のみ専用の第2専用セグメントを含む、請求項4に記載の統合フレームワーク。前記バスの前記第1部分は、第1バスを含み、前記バスの前記第2部分は、第2バスを含み、前記第1バスは、前記第2バスと物理的に別である、請求項3に記載の統合フレームワーク。受信されたデータの少なくとも一部を分析し、前記第1バスおよび前記第2バスのうちの1つへ前記データをルーティングするルータをさらに含む、請求項7に記載の統合フレームワーク。前記ルータは、前記データを前記第1バスへルーティングするか、または前記第2バスへルーティングするかを判断するために、前記データ内の少なくとも1つのヘッダを分析する、請求項8に記載の統合フレームワーク。産業ネットワークと、前記ネットワークを管理する中央局とのためのデータ管理システムであって、前記ユーティリティネットワークは、前記産業ネットワーク内に複数のデバイスを含み、前記データ管理システムは、前記ネットワークの或るセクションに置かれたデバイスに関連するデータ記憶装置であって、前記データ記憶装置は、前記デバイスに近接しており、前記デバイスは、前記産業ネットワークの前記セクションにおけるパラメータを感知し、前記データ記憶装置は、前記感知されたパラメータを記憶する複数のメモリ位置を含む、前記データ記憶装置と、前記中央局に関連する中央データ記憶装置であって、前記データ記憶装置内の前記メモリ位置へのリンクを含む、前記中央データ記憶装置と、を含むデータ管理システム。前記産業ネットワークは、輸送手段運行ネットワークを含む、請求項10に記載のデータ管理システム。前記輸送手段運行ネットワークは、鉄道運行ネットワークを含む、請求項11に記載のデータ管理システム。産業システムのインテリジェントネットワークであって、前記産業システムに関する少なくとも1つの側面を検出して、前記少なくとも1つの側面を示すエンドポイントデータを生成するよう構成された複数のセンサー、および前記エンドポイントデータを受信して、前記エンドポイントデータに基づき応答を生成するよう構成された少なくとも1つのエンドポイント分析モジュールを含む少なくとも1つのシステムエンドポイントと、前記産業システムのインフラストラクチャに関する少なくとも1つの側面を検出して、前記少なくとも1つの側面を示すインフラストラクチャデータを生成するよう構成された複数のセンサー、および前記エンドポイントデータを受信して、前記エンドポイントデータに基づき応答を生成するよう構成された少なくとも1つのインフラストラクチャ分析モジュールを含むシステムインフラストラクチャと、1つ以上のデータバスと、前記データバスのうちの少なくとも1つ以上を通して前記エンドポイントデータおよび前記インフラストラクチャデータを受信して、前記エンドポイントデータおよび前記インフラストラクチャデータのうちの少なくとも1つに基づき応答を生成するよう構成されたネットワークコアと、を含むインテリジェントネットワーク。前記少なくとも1つのエンドポイント分析モジュールは、前記産業システム内で、前記エンドポイントデータに基づきイベントの発生を判断し、前記イベントに基づき少なくとも1つの応答を判断するよう構成されている、請求項13に記載のインテリジェントネットワーク。前記少なくとも1つのインフラストラクチャ分析モジュールは、前記産業システム内で、前記インフラストラクチャデータに基づきイベントの発生を判断し、前記イベントに基づき少なくとも1つの応答を判断するよう構成されている、請求項13に記載のインテリジェントネットワーク。前記少なくとも1つのインフラストラクチャモジュールは、前記エンドポイントセンサーデータを受信し、前記産業システム内で、前記エンドポイントデータに基づきイベントの発生を判断し、前記イベントに基づき少なくとも1つの応答を判断するよう構成されている、請求項13に記載のインテリジェントネットワーク。前記ネットワークコアは、前記エンドポイントデータおよび前記インフラストラクチャデータのうちの少なくとも1つに基づきイベントを判断し、前記エンドポイントデータおよび前記インフラストラクチャデータのうちの前記少なくとも1つに基づき応答を生成するよう構成されている、請求項13に記載のインテリジェントネットワーク。前記ネットワークコアと通信するよう構成されたエンタープライズシステムをさらに含む、請求項13に記載のインテリジェントネットワーク。前記産業システムは、鉄道路システムである、請求項13に記載のインテリジェントネットワーク。前記産業システムは、トラック輸送システムである、請求項13に記載のインテリジェントネットワーク。産業システムの管理を改善するインテリジェントネットワークが提供される。インテリジェントネットワークは、カスタマイズ可能で、1つ以上の産業に適用されるとよい。例としては、ユーティリティ産業および輸送手段運行産業航空運行ネットワーク、鉄道運行ネットワーク、自動車運行ネットワーク、バス運行ネットワークなどへの適用がある。さらに、インテリジェントネットワークは、カスタマイズされて電気通信ネットワークおよびエネルギー探鉱に適用されてもよい。インテリジェントネットワークは、1つ以上のシステムエンドポイントを含むとよい。システムエンドポイントは、産業システムの様々な条件を監視してその条件を示すデータを生成する、1つ以上のエンドポイントセンサーを含むとよい。システムエンドポイントは、システムエンドポイントデータを処理してデータに基づき任意の適切な決定を生成する、エンドポイント解析を含むとよい。インテリジェントネットワークは、産業システムインフラストラクチャの様々な条件を監視してその条件を示すデータを生成する、1つ以上のインフラストラクチャセンサーを含むシステムインフラストラクチャを含むとよい。システムインフラストラクチャは、データを処理してデータに基づき任意の適切な決定を生成する、インフラストラクチャ解析を含むとよい。システムインフラストラクチャはさらに、システムエンドポイントからデータを受信して、適切な決定を生成するとよい。システムエンドポイントおよびシステムインフラストラクチャは、産業システム内の、対象となる発生occurrenceを示すイベントデータを生成するとよい。システムエンドポイントおよびシステムインフラストラクチャはさらに、産業システムを示す運用および非運用データを生成するとよい。インテリジェントネットワークは、イベントデータおよび運用/非運用データをインテリジェントネットワークのネットワークコアに提供する1つ以上のバスを含むとよい。ネットワークコアは、受信されたデータを分析して、産業システムの中の局所的または全体的であるとよい決定を生成する、システム解析を含むとよい。ネットワークコアはさらに、受信されたデータを、後のレビューおよび分析のために読み出せるよう記憶するために使用される、データ収集を含んでもよい。ネットワークコアはさらに、システム産業の様々な側面を制御するために使用されるシステム制御を含むとよい。システム制御は、様々な決定が下された場合に実行されてよく、システムの操作を要求してもよい。インテリジェントネットワークはさらに、ネットワークコアと通信しているエンタープライズシステムを含んでもよい。以下の図面および詳細な説明を検討すると、当業者には、他のシステム、方法、特徴および利点が明らかであるか、または明らかとなるであろう。そのようなさらなるシステム、方法、特徴および利点はすべて、本記載に含まれ、本発明の範囲内にあり、添付の特許請求の範囲により保護されるものとする。概要として、以下に記載される好適な実施形態は、産業ネットワークを管理する方法およびシステムに関する。出願人は、ユーティリティおよび輸送手段運行ネットワーク航空運行ネットワーク、鉄道運行ネットワーク、自動車運行ネットワーク、バス運行ネットワークなどなどの様々な産業ネットワークに関する以下の例を提供する。なお、電気通信ネットワークおよびエネルギー探鉱ネットワーク油井のネットワーク、天然ガス井のネットワークなどを含む、他の産業ネットワークが使用されてもよい。以下でさらに詳しく説明するように、一部の側面は、電力グリッド自体などのユーティリティネットワーク送電および/または配電におけるハードウェアおよびソフトウェアを含む、または輸送手段運行ネットワークに関する。さらに、一部の側面は、電力グリッドの中央管理などのユーティリティネットワークの中央管理、および輸送手段運行ネットワークの中央管理の機能的能力に関する。こうした機能的能力は、動作およびアプリケーションの2つのカテゴリにグループ化され得る。動作サービスは、ユーティリティが、ユーティリティネットワークインフラストラクチャアプリケーション、ネットワーク、サーバ、センサーなどを監視および管理できるようにする。後述する例の1つでは、アプリケーションの能力は、ユーティリティネットワーク自体電力グリッドまたは輸送手段運行ネットワークなどの測定および制御に関するとよい。特に、アプリケーションサービスは、ユーティリティネットワークにとって重要と考えられる機能性を可能にするものであり、1データ収集プロセス、2データカテゴリ化および維持プロセス、ならびに3可観測性プロセスが含まれ得る。以下でさらに詳しく説明するように、こうしたプロセスを使用することで、ユーティリティネットワークを観測し、データを分析して、ユーティリティネットワークについての情報を得ることができるようになる。以下、図20を参照する。様々な産業の産業システムに適用され得る、例示のインテリジェントネットワークデータエンタープライズINDEアーキテクチャ2000を示すブロック図が示されている。一例では、INDEアーキテクチャは、ネットワークコア2002を含むとよい。ネットワークコア2002は、特定の使用産業に基づく様々なタイプの情報および/またはデータを受信するとよい。特定の産業のデータおよび情報は、産業システムに関する様々なポイントを表すとよいシステムエンドポイント2006にて生じるとよい。各システムエンドポイント2006は、産業システムに関連する様々な条件を検出するとよいいくつかのエンドポイントセンサー2014を含むとよい。例えば、エンドポイントセンサー2014は、ユーティリティグリッドにおける送電線潮流、または航空会社の到着/出発問題の検出専用とされてもよい。各システムエンドポイント2006は、1つ以上のプロセッサおよびメモリデバイスを含み、局所的な解析の実行を可能にするとよい。一例では、エンドポイント解析2016は、エンドポイントセンサー2006から受信されたデータに基づき様々なイベントを判断するとよい。INDEアーキテクチャ2000はさらに、産業システム全体にわたってシステムエンドポイント2006をサポートするとよいシステムインフラストラクチャ2008を含むとよい。システムインフラストラクチャ2008は、産業システムに関連する諸条件を検出するために産業システム全体にわたって分散したインフラストラクチャセンサー2022を含むとよい。一例では、システムインフラストラクチャ2008は、インフラストラクチャ解析2020を含み、インフラストラクチャセンサー2022から受信されたデータをシステムインフラストラクチャが分析できるとよい。ネットワークコア2002は、システムエンドポイント2006およびシステムインフラストラクチャ2008から情報を受信するとよい。一例では、INDEアーキテクチャ2000は、運用/非運用バス2010およびイベントバス2012などのいくつかのバスを含むとよい。運用/非運用バス2010は、運用および非運用データ両方を伝達するために使用されるとよい。一例では、運用データは、INDEアーキテクチャ2000を実装している特定の産業システムの様々な動作に関連するデータを指すとよい。非運用データは、特定の産業システム自体に関する側面に関連した産業内のデータを指すとよい。イベントバス2012は、産業システムにおいて生じる様々なイベントに関するデータを受信するとよい。イベントは、産業システムにおける、対象となる任意の発生を指すとよい。したがって、イベントは、産業システムにおいて生じる、好ましくない条件または異常な条件を含むとよい。INDEアーキテクチャ2000は、アーキテクチャの様々なコンポーネントが、データを処理して適切な出力を判断するために使用され得るという点において、分散型のインテリジェンスを実装することもできる。一例では、エンドポイント解析2006は、1つ以上のプロセッサ、メモリデバイスおよび通信モジュールを含み、エンドポイントセンサー2006によって受信されるデータに基づき処理が実行されることを可能にするとよい。例えば、エンドポイント解析2016は、エンドポイントセンサー2014からイベントに関するデータを受信するとよく、そのデータに基づき、特定のイベントが生じていることを判断するとよい。エンドポイント解析2016は、イベントに基づき適切な応答を生成するとよい。同じく、インフラストラクチャ解析2020は、1つ以上のプロセッサ、メモリデバイスおよび通信モジュールを含み、インフラストラクチャセンサー2022によって受信されるデータに基づき処理が実行されることを可能にするとよい。システムインフラストラクチャ2008は、システムエンドポイント2006と通信し、システムインフラストラクチャ2008は、インフラストラクチャ解析2020を利用して、システムエンドポイント2014およびインフラストラクチャセンサー2022からのイベントデータならびに運用/非運用データを評価および処理できるとよい。データはさらに、バス2010および2012によって提供されるネットワークコア2002によって評価されてもよい。一例では、ネットワークコア2002は、センサー解析2026およびイベント解析2028を含むシステム解析2024を含むとよい。解析2026および2028は、1つ以上のプロセッサおよびメモリデバイスを含み、イベントデータおよび運用/非運用データの分析を可能にするとよい。一例では、センサー解析2024は、エンドポイントセンサー2014およびインフラストラクチャセンサー2022からのセンサーデータを評価するとよい。イベント解析2028では、イベントデータを処理および評価するために使用されるとよい。ネットワークコア2002はさらに、データ収集2030を含むとよい。データ収集2030は、生データおよび処理されたデータを記憶するために使用される様々なデータウェアハウス2032を含み、これは、過去データが必要に応じて読み出されることを可能にし、将来行われる解析が過去データに基づくことを可能にするとよい。ネットワークコア2002は、システム制御2034も含むとよい。システム制御2034は、産業システム内で取られるアクションに関与するとよい。例えば、システム制御2002は、イベントデータおよび/または運用/非運用データに基づき産業システムの様々な側面を自動的に制御する自動制御2036を含むとよい。ネットワークコア2002はさらに、イベントデータおよび/または運用/非運用バスに基づいても基づかなくてもよい産業システムの人的制御を可能にするユーザ制御2038を含むとよい。エンタープライズシステム2004は、産業向けの様々な大規模ソフトウェアパッケージを含むとよい。エンタープライズシステム2004は、情報技術IT:informationtechnologyなどの当該機能または産業に関係する他の側面で用いるデータを、ネットワークコア2002と送受信するとよい。他の例では、バス2010および2012は、単一バスに統合されても、追加のバスを含んでもよい。さらに、他の例は、様々なサブシステムを含むシステムインフラストラクチャ2008を含んでもよい。以下、図29を参照する。INDEアーキテクチャ2000の例示の運用図が示されている。一例では、システムエンドポイントSEsystemendpoint12006が、イベントEevent1の発生を判断するとよい。別のシステムエンドポイントSE22006が、イベントE2の発生を判断するとよい。各システムエンドポイント2006は、イベントデータによってシステムインフラストラクチャ2008にイベントE1およびE2をレポートするとよい。システムインフラストラクチャ2008は、イベントデータを分析して、決定Ddecision1を生成するとよく、これがシステムエンドポイントSE1およびSE2に伝送されて、システムエンドポイントが応答を実行できるようにするとよい。別の例では、イベントE3が、システムエンドポイントSE1によって判断されるとよい。イベントE3をレポートするイベントデータはネットワークコア2002に伝送されて、ネットワークコア2002が、システム制御2034を介して、システム解析2024を実行して決定D2を生成できるようにするとよい。決定D2は、システムエンドポイントSE1に提供されるとよい。別の例では、システムエンドポイントSE1が、イベントE4の発生を判断して、イベントデータによってイベントE4をネットワークコア2002に通知するとよい。ネットワークコア2002は、決定D3を生成して、それを、実行のためにシステムエンドポイントSE1に提供するとよく、その一方で、決定D3に関する情報をエンタープライズシステム2004に提供する。別の例では、システムエンドポイントSE1は、イベントE5の発生を判断するとよい。システムエンドポイントSE1は、エンドポイント解析2016を実行して、決定D4を判断し、続いて実行するとよい。決定D4は、システムインフラストラクチャ2008およびネットワークコア2002に、通知および記憶のために提供されるとよい。図29に関する例は、例示であり、他のイベント、運用データおよび非運用データが、INDEシステム2002によって伝達され得る。INDE上位アーキテクチャの説明全体的アーキテクチャ図面を参照する。図面では、類似した参照数字は類似した構成要素を指し、図1A~CはINDEの全体的なアーキテクチャの一例を示す。このアーキテクチャは、ユーティリティネットワークデータスマートグリッドデータなどのエンドツーエンド収集、搬送、記憶および管理を提供する参照モデルとしての機能を果たし得る。さらにこのアーキテクチャは、解析および解析管理、ならびに前述のもののユーティリティプロセスおよびシステムへの統合を提供し得る。したがって、これはエンタープライズ規模のアーキテクチャと見なされるとよい。運用管理およびユーティリティネットワーク自体の各側面など、特定の要素については、下記でさらに詳しく説明する。図1A~Cに示されているアーキテクチャは、データおよび統合バスを最大4つまで含んでよい:1高速センサーデータバス146電力ユーティリティの例では運用および非運用データを含むとよい、2専用イベント処理バス147イベントデータを含むとよい、3動作サービスバス130電力ユーティリティの例ではスマートグリッドについての情報をユーティリティのバックオフィスアプリケーションに提供する役割を果たすとよい、ならびに4バックオフィスITシステム用のエンタープライズサービスバスエンタープライズIT115にサービス提供するエンタープライズ統合環境バス114として図1A~Cに示されている。個々のデータバスは、1つ以上の方法で実現され得る。例えば、高速センサーデータバス146およびイベント処理バス147など、データバスの2つ以上が、単一データバスの別々のセグメントであってもよい。具体的には、バスはセグメント化された構造またはプラットフォームを有してもよい。下記でさらに詳しく説明するように、データバスの別々のセグメント上にデータをルーティングするために、1つ以上のスイッチなどのハードウェアおよび/またはソフトウェアが使用され得る。別の例として、データバスの2つ以上は、データを別々のバス上で搬送するために必要なハードウェアに関して別々の物理的バスなど、別々のバス上にあってもよい。具体的には、バスはそれぞれ、互いに独立したケーブル配線を含んでもよい。さらに、別々のバスのうち、一部または全部が同じタイプであってもよい。例えば、バスの1つ以上が、非シールドより対線を介したイーサネット登録商標およびWi-Fi登録商標などのローカルエリアネットワークLAN:localareanetworkを含んでもよい。下記でさらに詳しく説明するように、種々の物理的バスの中の1つのバス上へデータ上のデータをルーティングするために、ルータなどのハードウェアおよび/またはソフトウェアが使用され得る。さらに別の例として、バスの2つ以上が、単一バス構造の異なるセグメント上にあってもよく、1つ以上のバスが、別個の物理的バス上にあってもよい。具体的には、高速センサーデータバス146およびイベント処理バス147が、単一データバスの異なるセグメントであってもよく、エンタープライズ統合環境バス114が、物理的に別個のバス上にあってもよい。図1A~Cは、4つのバスを示すが、より少ない、または多い数のバスが、列挙された4タイプのデータを運ぶために使用され得る。例えば、後述するように、センサーデータおよびイベント処理データの伝達に、セグメント化されていない単一バスが使用されてもよいバスの総数は3になる。さらにシステムは、動作サービスバス130および/またはエンタープライズ統合環境バス114なしで動作することもできる。IT環境は、SOAServiceOrientedArchitecture:サービス指向アーキテクチャに準拠していてもよい。サービス指向アーキテクチャSOAは、サービスとしてパッケージ化されたビジネスプロセスのライフサイクル全体にわたる作成および使用に関する、コンピュータシステムアーキテクチャの様式である。SOAはさらに、種々のアプリケーションがデータを交換してビジネスプロセスに関与することを可能にするようITインフラストラクチャを定義し、供給する。ただし、SOAおよびエンタープライズサービスバスの使用は任意選択である。電力グリッドの例では、図面は、1INDECORE120、2INDESUBSTATION180および3INDEDEVICE188など、全体的なアーキテクチャ内の種々の構成要素を示す。全体的なアーキテクチャ内で構成要素をこのように分割しているのは、説明のためである。構成要素のこのほかの分割が使用されてもよい。さらに、構成要素の分割は、種々の産業に関して異なってもよい。INDEアーキテクチャは、グリッドインテリジェンスに対する分散型および集中型どちらの手法をサポートするためにも使用されてよく、大型実装の規模に対応するメカニズムを提供するために使用されてもよい。INDE参照アーキテクチャは、実装され得る技術アーキテクチャの一例である。例えば、後述するように、INDE参照アーキテクチャをメタアーキテクチャの例とし、これを使用して、産業ソリューション毎に1つ例えば、別々の産業に別々のソリューション、または産業における適用毎に1つ例えば、第1のユーティリティ電力グリッドに第1のソリューションおよび第2のユーティリティ電力グリッドに第2のソリューション、任意数の具体的技術アーキテクチャを開発するための開始点を提供することもできる。したがって、特定の産業、または産業内の特定の適用特定のユーティリティへの適用などに対する具体的ソリューションは、INDE参照アーキテクチャ内の構成要素の1つ、いくつかまたはすべてを含むとよい。さらに、INDE参照アーキテクチャは、ソリューション開発の標準化された開始点を提供するとよい。特定の産業または産業内の特定の適用特定の電力グリッドなどに対する具体的な技術アーキテクチャを判断する手順について後述する。INDE参照アーキテクチャは、エンタープライズ規模のアーキテクチャであるとよい。その目的は、グリッドデータおよび解析のエンドツーエンド管理など、データおよび解析のエンドツーエンド管理と、これらのユーティリティシステムおよびプロセスへの統合とのためのフレームワークを提供することであるとよい。高度なネットワーク技術スマートグリッド技術などは、ユーティリティビジネスプロセスのあらゆる側面に影響することから、ネットワークレベルグリッドなど、動作および需要家構内レベルの影響のみではなく、バックオフィスおよびエンタープライズレベルの影響にも気を配らなければならない。したがって、INDE参照アーキテクチャは、例えば、インターフェースのためにSOA環境をサポートするよう、エンタープライズレベルSOAを参照することができ、実際に参照する。これは、スマートグリッドなどの高度なネットワークを構築および使用するには、ユーティリティなどの産業がその既存のIT環境をSOAに変更しなければならないと要求するものと見なされてはならない。エンタープライズサービスバスは、IT統合を促進する有益なメカニズムであるが、ソリューションの残りの部分を実装するために必須ではない。以下の説明は、ユーティリティソリューションに関するINDEスマートグリッド構成要素の種々のコンポーネントに焦点を合わせるが、INDEのコンポーネントの1つ、いくつかまたはすべてが、電気通信、輸送手段運行およびエネルギー探鉱などの種々の産業に適用され得る。INDEコンポーネントグループ上記のように、INDE参照アーキテクチャ内の種々のコンポーネントには、例えば1INDECORE120、2INDESUBSTATION180および3INDEDEVICE188が含まれ得る。以下の各セクションは、INDE参照アーキテクチャのこれら3つの例示の構成要素グループについて説明し、各グループのコンポーネントの説明を提供する。INDECORE図2は、図1A~Cに示されているように、INDE参照アーキテクチャのうち、動作制御センターに存在するとよい部分である、INDECORE120を示す。INDECORE120は、グリッドデータを記憶するための統一データアーキテクチャと、そのデータに対して作用する解析の統合スキーマとを含むとよい。このデータアーキテクチャは、その最上位スキーマとして、国際電気標準会議IEC:InternationalElectrotechnicalCommission共通情報モデルCIM:CommonInformationModelを使用するとよい。IECCIMは、アプリケーションソフトウェアが電気ネットワークの構成およびステータスについての情報を交換できるようにすることを目標として、電気電力業界により開発されIECにより公式に採用された標準である。さらに、このデータアーキテクチャは、他のタイプのユーティリティデータ例えば計器データ、運用および過去データ、ログならびにイベントファイルなど、ならびに接続性およびメタデータファイルを、エンタープライズアプリケーションを含む上位アプリケーションによるアクセスのための単一エントリポイントを有するとよい単一データアーキテクチャに関連付けるために、連合ミドルウェア134を使用するとよい。さらに、リアルタイムシステムが、高速データバスを介して主要データストアにアクセスするとよく、いくつかのデータストアはリアルタイムデータを受信することができる。種々のタイプのデータが、スマートグリッド内の1つ以上のバス内で搬送されるとよい。INDESUBSTATION180のセクションにおいて以下で説明するように、変電所データは、変電所において収集されて、ローカルに記憶されるとよい。具体的には、変電所に関連し近接しているとよいデータベースが、変電所データを記憶するとよい。さらに、変電所レベルに関連する解析は、変電所のコンピュータにて実行され、変電所データベースに記憶されるとよく、そのデータの全部または一部が、制御センターへ搬送されるとよい。搬送されるデータのタイプは、動作および非運用データ、イベント、グリッド接続性データならびにネットワーク位置データを含むとよい。運用データは、次に限定はされないが、スイッチ状態、フィーダ状態、コンデンサ状態、セクション状態、計器状態、FCIfaultedcircuitindicator:故障回路インジケータ状態、ラインセンサー状態、電圧、電流、有効電力、無効電力などを含むとよい。非運用データは、次に限定はされないが、電力品質、電力信頼性、アセット正常性、ストレスデータなどを含むとよい。運用および非運用データは、運用/非運用データバス146を使用して搬送されるとよい。電力グリッドの送電および/または配電におけるデータ収集アプリケーションが、データの一部または全部を運用/非運用データバス146へ送信することを担当するとよい。こうして、情報を得るための登録をすること、またはこのデータを利用可能にできるサービスを呼び出すことにより、この情報を必要とするアプリケーションがデータを得られるとよい。イベントは、後述するように、スマートグリッドの一部である様々なデバイスおよびセンサーから生じるメッセージおよび/またはアラームを含むとよい。イベントは、スマートグリッドネットワーク上のデバイスおよびセンサーから直接生成されてもよく、さらに、こうしたセンサーおよびデバイスからの測定データに基づいて様々な解析アプリケーションにより生成されてもよい。イベントの例には、計器の停止、計器のアラーム、変圧器の停止などが含まれ得る。グリッドデバイスのようなグリッドコンポーネントスマート電力センサーデジタル処理能力のためにプログラム可能な組み込みプロセッサを備えるセンサーなど、温度センサーなど、追加の組み込み処理を含む電力システムコンポーネントRTURemoteTerminalUnit:リモート端末ユニットなど、スマート計器ネットワーク計器の正常性、計器読み取りなどおよびモバイル現場要員用デバイス供給停止イベント、作業命令完了などが、イベントデータ、運用および非運用データを生成するとよい。スマートグリッド内で生成されたイベントデータは、イベントバス147を介して伝送されるとよい。グリッド接続性データは、ユーティリティグリッドの配置を定義するとよい。グリッドコンポーネント変電所、セグメント、フィーダ、変圧器、スイッチ、リクローザー、計器、センサー、電柱などの物理的配置、およびそれらの設備における相互接続性を定義する基本レイアウトがあるとよい。グリッド内のイベントコンポーネントの不具合、保守活動などに基づき、グリッド接続性は継続的に変化し得る。下記でさらに詳しく説明するように、データが記憶される構造ならびにデータの組み合わせにより、過去の様々な時点におけるグリッド配置の過去の再現が可能となる。グリッド接続性データは、ユーティリティグリッドに対する変更が加えられ、この情報がGISGeographicInformationSystem:地理情報システムアプリケーションにおいて更新されるにつれて、定期的に地理情報システムGISから抽出されるとよい。ネットワーク位置データは、通信ネットワーク上のグリッドコンポーネントについての情報を含むとよい。この情報は、メッセージおよび情報を特定のグリッドコンポーネントへ送信するために使用されるとよい。ネットワーク位置データは、新たなスマートグリッドコンポーネントが設置されたときにスマートグリッドデータベースに手動で入力されてもよく、またはこの情報が外部で保たれる場合はアセット管理システムから抽出される。下記でさらに詳しく説明するように、データは、グリッド内の様々なコンポーネントから送信され得るINDESUBSTATION180および/またはINDEDEVICE188など。データは、無線、有線または両方の組み合わせでINDECORE120へ送信され得る。データは、ユーティリティ通信ネットワーク160によって受信されるとよく、ユーティリティ通信ネットワーク160は、データをルーティングデバイス190へ送信するとよい。ルーティングデバイス190は、バスのセグメント上バスがセグメント化されたバス構造を含む場合または独立したバス上へのデータのルーティングを管理するソフトウェアおよび/またはハードウェアを含むとよい。ルーティングデバイスは、1つ以上のスイッチまたはルータを含んでもよい。ルーティングデバイス190は、ネットワーキングデバイスを含むとよく、そのソフトウェアおよびハードウェアが、バスの1つ以上へデータをルーティングおよび/または転送する。例えば、ルーティングデバイス190は、運用および非運用データを、運用/非運用データバス146へルーティングするとよい。ルータはさらに、イベントデータをイベントバス147へルーティングするとよい。ルーティングデバイス190は、データをどのようにルーティングするかを、1つ以上の方法に基づき判断するとよい。例えば、ルーティングデバイス190は、伝送されたデータ内の1つ以上のヘッダを検査して、データを運用/非運用データバス146のセグメントへルーティングするか、またはイベントバス147のセグメントへルーティングするかを判断してもよい。具体的には、データ内の1つ以上のヘッダが、データが動作/非運用データであるかその結果ルーティングデバイス190はデータを運用/非運用データバス146へルーティングするまたはデータがイベントデータであるかその結果ルーティングデバイス190はイベントバス147をルーティングするを示してもよい。あるいは、ルーティングデバイス190は、データのペイロードを検査して、データのタイプを判断してもよい例えば、ルーティングデバイス190は、データのフォーマットを検査して、データが運用/非運用データであるか、またはイベントデータであるかを判断してもよい。運用データを記憶する運用データウェアハウス137などのストアの1つが、真の分散型データベースとして実装されてもよい。ストアのもう1つ、ヒストリアン図1および2において過去データ136として特定されているが、分散型データベースとして実装されてもよい。これら2つのデータベースのもう一方のエンドは、INDESUBSTATION180グループ後述にあってもよい。さらに、イベントは、複合イベント処理バスを介していくつかのデータストアのいずれかに直接記憶されてもよい。具体的には、イベントは、イベントバス147へ発行したすべてのイベントのリポジトリとしてもよいイベントログ135に記憶されてもよい。イベントログは、イベントid、イベントタイプ、イベントソース、イベント優先度およびイベント生成時間のうちの1つ、いくつかまたはすべてを記憶するとよい。イベントバス147が、イベントを長期記憶してすべてのイベントの維持を提供する必要はない。データの記憶は、できるだけ、または実用的なだけ、データがソースに近くなるようになっているとよい。一実装では、これには例えば、変電所データがINDESUBSTATION180にて記憶されることが含まれてもよい。しかし、このデータは、非常に細かい粒度レベルでグリッドを考慮した各種決定を下すために、動作制御センターレベル116においても必要とされることもある。データベースリンクおよびデータサービスを適宜使用することによってソリューションのすべてのレベルにおけるデータの利用可能性を促進するよう、分散型データ手法が、分散型インテリジェンス手法とともに採用されるとよい。このように、過去データストア動作制御センターレベル116にてアクセス可能であるとよいに関するソリューションは、運用データストアのソリューションと類似しているとよい。データは、変電所においてローカルに記憶されてもよく、制御センターにおいてリポジトリインスタンス上で構成されているデータベースリンクが、個別の変電所にあるデータに対するアクセスを提供する。変電所解析は、変電所において、ローカルデータストアを使用してローカルで実行されるとよい。データベースリンクを使用してローカル変電所インスタンスのデータにアクセスすることによって、動作制御センターレベル116で過去/集合的解析が実行されてもよい。あるいは、データは、INDECORE120にて中央で記憶されてもよい。しかし、INDEDEVICE188から伝送される必要があると考えられるデータの量を考慮すると、INDEDEVICE188にてデータを記憶する方が好ましいこともある。具体的には、何千または何万もの変電所がある場合電力グリッドではあり得る、INDECORE120へ伝送される必要のあるデータ量により、通信ボトルネックがもたらされることもあり得る。最後に、INDECORE120は、電力グリッド内のINDESUBSTATION180またはINDEDEVICE188のうちの1つ、いくつかまたはすべてをプログラムまたは制御するとよい後述。例えば、INDECORE120は、プログラミングを変更してもよく更新されたプログラムをダウンロードするなど、またはINDESUBSTATION180もしくはINDEDEVICE188の任意の側面を制御する制御コマンドを提供してもよいセンサーまたは解析の制御など。図2に示されていない他の構成要素に、この論理アーキテクチャをサポートする様々な統合構成要素が含まれ得る。表1は、図2に示されたINDECORE120の特定の構成要素を記載する。表1:INDECORE構成要素表1で説明したように、リアルタイムデータバス146動作および非運用データを伝達するおよびリアルタイム複合イベント処理バス147イベント処理データを伝達するは単一バス346へ。この例が、図3A~Cのブロック図300に示されている。図1A~Cに示されているように、バスは、パフォーマンスのために別々になっている。CEP処理の場合、非常に大きなメッセージバーストが起こりやすい特定の用途には、低遅延が重要であると考えられる。一方、グリッドデータフローの大部分はほぼ一定であり、デジタル故障レコーダファイルが例外であるが、これらは通常、制御された形で読み出し可能である。それに対し、イベントバーストは非同期且つランダムである。図1はさらに、INDECORE120とは別の、動作制御センター116内のさらなる構成要素を示す。具体的には、図1はさらに、計器との通信計器からデータを収集して収集したデータをユーティリティに提供するなどを担当するシステムである、計器データ収集ヘッドエンド単数または複数153を示す。需要応答管理システム154は、1つ以上の需要家構内にある、ユーティリティによる制御が可能な設備と通信するシステムである。供給停止管理システム155は、供給停止の位置を追跡すること、何が送られているかを管理すること、およびその修理方法によって、供給停止の管理においてユーティリティを支援するシステムである。エネルギー管理システム156は、送電グリッド上の変電所例えばのデバイスを制御する、送電システムレベルの制御システムである。配電管理システム157は、配電グリッドの変電所のデバイスおよびフィーダデバイス例えばを制御する、配電システムレベルの制御システムである。IPネットワークサービス158は、IP型通信DHCPおよびFTPなどをサポートする1つ以上のサーバ上で動作するサービスの集合である。モバイルデータ送信システム159は、現場のモバイルデータ端末とメッセージを送受信するシステムである。回路負荷潮流分析、計画、雷分析およびグリッドシミュレーションツール152は、グリッドの設計、分析および計画においてユーティリティにより使用されるツールの集合である。IVRintegratedvoiceresponse:統合音声応答および呼管理151は、需要家からの電話を処理するシステムである自動または係により。供給停止に関する着信通話が、自動または手動で入力されて、供給停止管理システム155へ転送されるとよい。作業管理システム150は、作業命令を監視および管理するシステムである。地理情報システム149は、アセットが地理的にどこに位置し、各アセットがどのように接続されているかについての情報を含むデータベースである。環境がサービス指向アーキテクチャSOAを有する場合、動作SOAサポート148は、SOA環境をサポートするサービスの集合である。動作制御センター116内にありINDECore120外にあるシステムのうちの1つ以上は、ユーティリティが有することもあるレガシー製品システムである。こうしたレガシー製品システムの例には、動作SOAサポート148、地理情報システム149、作業管理システム150、呼管理151、回路負荷潮流分析、計画、雷分析およびグリッドシミュレーションツール152、計器データ収集ヘッドエンド単数または複数153、需要応答管理システム154、供給停止管理システム155、エネルギー管理システム156、配電管理システム157、IPネットワークサービス158およびモバイルデータ送信システム159が含まれる。なお、こうしたレガシー製品システムは、スマートグリッドから受信されるデータを処理または操作することができなくてもよい。INDECore120は、スマートグリッドからデータを受信し、スマートグリッドからのデータを処理し、処理したデータを1つ以上のレガシー製品システムへ、レガシー製品システムが使用できる形レガシー製品システムに特有の特定のフォーマッティングなどで転送することができるとよい。このように、INDECore120はミドルウェアと見なされてもよい。INDECORE120を含む動作制御センター116は、エンタープライズIT115と通信するとよい。一般的に、エンタープライズIT115における機能性はバックオフィス業務を含む。具体的には、エンタープライズIT115は、ビジネスデータウェアハウス104、ビジネスインテリジェンスアプリケーション105、エンタープライズリソースプラニング106、様々な財務システム107、需要家情報システム108、人材システム109、アセット管理システム110、エンタープライズSOAサポート111、ネットワーク管理システム112およびエンタープライズメッセージサービス113を含むエンタープライズIT115内の様々なシステムへデータを送信するためにエンタープライズ統合環境バス114を使用するとよい。エンタープライズIT115はさらに、ファイアウォール102を介してインターネット101と通信するためのポータル103を含むとよい。INDESUBSTATION図4は、INDESUBSTATION180グループの上位アーキテクチャの例を示す。このグループは、変電所の電子装置およびシステムと同じ場所に位置する1つ以上のサーバ上で、変電所の制御所にて変電所170内で実際にホストされている構成要素を含むとよい。以下の表2は、特定のINDESUBSTATION180グループ構成要素を列挙し、説明する。データセキュリティサービス171は、変電所環境の一部であってもよい。あるいは、これらはINDESUBSTATION180グループに統合されてもよい。表2:INDESUBSTATION構成要素上記のように、スマートグリッド内の種々の構成要素に、追加の処理/分析能力およびデータベースリソースを含む追加の機能性が含まれ得る。スマートグリッドにおいて、様々な構成要素内でこうした追加の機能性を使用することで、アプリケーションおよびネットワークパフォーマンスの集中管理および監督を伴う分散型アーキテクチャが可能になる。機能、パフォーマンスおよび拡張性のために、何千から何万のINDESUBSTATION180および何万から何百万のグリッドデバイスを含むスマートグリッドが、分散型処理、データ管理およびプロセス通信を含むこともできる。INDESUBSTATION180は、1つ以上のプロセッサと、1つ以上のメモリデバイス変電所非運用データ181および変電所動作データ182などとを含むとよい。非運用データ181および変電所動作データ182は、INDESUBSTATION180内またはINDESUBSTATION180上に位置するなど、変電所に関連し近接しているとよい。INDESUBSTATION180はさらに、変電所レベルでのスマートグリッドの可観測性を担当する、スマートグリッドのコンポーネントを含んでもよい。INDESUBSTATION180コンポーネントは、運用データ獲得および分散型運用データストアでの記憶、非運用データの獲得およびヒストリアンでの記憶、ならびにリアルタイムサブ秒などでのローカル解析処理という3つの主要機能を提供するとよい。処理は、電圧および電流波形のデジタル信号処理と、イベントストリーム処理を含む検出および分類処理と、処理結果のローカルシステムおよびデバイス、ならびに動作制御センター116にあるシステムへの伝達とを含むとよい。INDESUBSTATION180と、グリッド内の他のデバイスとの通信は、有線、無線、または有線と無線との組み合わせとしてよい。例えば、INDESUBSTATION180から動作制御センター116へのデータの伝送は有線であってもよい。INDESUBSTATION180は、動作/非運用データまたはイベントデータなどのデータを、動作制御センター116へ伝送するとよい。ルーティングデバイス190は、伝送されたデータを、運用/非運用データバス146またはイベントバス147のうちの1つへルーティングするとよい。配電損失管理のための需要応答最適化も、ここで実行されるとよい。このアーキテクチャは、前に説明した分散型アプリケーションアーキテクチャの原則に従う。例えば、接続性データは、変電所170および動作制御センター116にて複製され、その結果、動作制御センター116へのデータ通信ネットワークが有効でなくても変電所170が独立して動作できるようにするとよい。この情報接続性がローカルに記憶されていることで、動作制御センターへの通信リンクが動作不能であっても変電所解析がローカルで実行され得る。同様に、運用データは、動作制御センター116および変電所170にて複製されるとよい。特定の変電所に関連するセンサーおよびデバイスからのデータが収集され、最新の測定値が、変電所にてこのデータストアに記憶されるとよい。運用データストアのデータ構造は同じであるとよく、したがって、データベースリンクを使用して、制御センターにある運用データストアのインスタンスを介した、変電所に存在するデータへのシームレスアクセスを提供することもできる。これは、データの複製を減らすこと、および時間依存がより大きい変電所データ解析が、ローカルで、変電所外の通信利用可能性に依存せずに行われるのを可能にすることを含む、いくつかの利点を提供する。動作制御センターレベル116でのデータ解析は、時間依存がより小さいと考えられ典型的には、動作制御センター116は、過去データを検査して、反応型というよりも予測型のパターンを識別すると考えられるため、ネットワークの問題があっても対処できると考えられる。最後に、過去データが変電所にてローカルに記憶され、データのコピーが制御センターにて記憶されてもよい。または、動作制御センター116にてリポジトリインスタンス上のデータベースリンクが構成され、個別の変電所にあるデータへのアクセスが動作制御センターに提供されてもよい。変電所解析は、変電所170において、ローカルデータストアを使用してローカルで実行されるとよい。具体的には、変電所にて追加のインテリジェンスおよび記憶能力を使用することで、変電所は、それ自体を分析して、中央局からの入力なしにそれ自体を修正することができる。あるいは、ローカル変電所インスタンスのデータにデータベースリンクを使用してアクセスすることによって、動作制御センターレベル116で、過去/集合的解析も実行されてもよい。INDEDEVICEINDEDEVICE188グループは、様々な配電グリッドデバイス189例えば、送電線上のラインセンサーなどのスマートグリッド内の様々なセンサー、需要家構内にある計器163などを含む、スマートグリッド内の任意の種類のデバイスを含み得る。INDEDEVICE188グループは、特定の機能性を備えグリッドに追加されるデバイスを含んでもよく専用プログラミングを含むスマートリモート端末ユニットRTUなど、または追加機能性を備えるグリッド内の既存デバイスを含んでもよい既にグリッド内に配置されており、スマートラインセンサーまたはスマートグリッドデバイスを作成するためにプログラム可能な、既存のオープンアーキテクチャ柱上RTUなど。INDEDEVICE188はさらに、1つ以上のプロセッサおよび1つ以上のメモリデバイスを含んでもよい。既存のグリッドデバイスは、ソフトウェアの観点からはオープンではないこともあり、現代のネットワーキングまたはソフトウェアサービスに関してはあまりサポートできないかもしれない。既存のグリッドデバイスは、ラップトップコンピュータなどの他の何らかのデバイスに時折オフロードするデータを獲得および記憶するよう、または要求に応じてリモートホストへPSTNpublic-switchedtelephonenetwork:公衆交換電話ネットワーク線を介してバッチファイルを転送するよう設計されていることもある。こうしたデバイスは、リアルタイムデジタルネットワーク環境で動作するようには設計されていないこともある。このような場合には、グリッドデバイスデータは、既存の通信ネットワークがどのように設計されているかに応じて、変電所レベル170または動作制御センターレベル116で取得されるとよい。計器ネットワークの場合、計器ネットワークが通常クローズドであり、計器が直接アドレス指定可能ではないことから、通常は計器データ収集エンジンからデータが取得される。こうしたネットワークが進化するにつれて、計器および他のグリッドデバイスが個別にアドレス指定可能になると考えられ、その結果データが、必要とされるところへ直接搬送可能になる。データが必要とされる場所は、必ずしも動作制御センター116とは限らず、グリッド上のどこにでもなり得る。故障回路インジケータなどのデバイスは、適度な速度100kbpsなどの無線ネットワークを介した接続のために、無線ネットワークインターフェースカードと結合されてもよい。こうしたデバイスは、例外によりステータスをレポートして、事前にプログラムされた固定機能を実行してもよい。ローカルスマートRTUを使用することによって、多数のグリッドデバイスのインテリジェンスが増強され得る。固定機能のクローズドアーキテクチャデバイスとして設計されている柱上RTUの代わりに、サードパーティーによりプログラム可能でINDE参照アーキテクチャ内のINDEDEVICE188としての機能を果たすことができるオープンアーキテクチャデバイスとしてのRTUが使用されてもよい。さらに、需要家の構内にある計器がセンサーとして使用されてもよい。例えば、計器は、消費を測定してもよく請求のために、どのくらいのエネルギーが消費されているかなど、電圧を測定してもよい電圧/VAr最適化で用いるために。図5A~Bは、INDEDEVICE188グループの例示のアーキテクチャを示す。表3は、特定のINDEDEVICE188構成要素を説明する。スマートグリッドデバイスは、組み込みプロセッサを含むとよく、したがって、DEVICEグループは専用リアルタイムDSPまたはマイクロプロセッサ上で実装されるため、処理構成要素は、SOAサービスよりもリアルタイムプログラムライブラリルーチンに似る。表3:INDEDEVICE構成要素図1Aはさらに、1つ以上のスマート計器163、家庭内ディスプレイ165、1つ以上のセンサー166および1つ以上の制御167を含むとよい需要家構内179を示す。実際には、センサー166は、需要家構内179にある1つ以上のデバイスにてデータを登録するとよい。例えば、センサー166は、暖房炉、温水ヒーター、空調装置などの、需要家構内179の中の様々な主要電化製品にてデータを登録するとよい。この1つ以上のセンサー166からのデータが、スマート計器163へ送信されるとよく、スマート計器163は、ユーティリティ通信ネットワーク160を介して動作制御センター116へ伝送するためにデータをパッケージ化するとよい。家庭内ディスプレイ165は、スマート計器163および1つ以上のセンサー166から収集されたデータをリアルタイムで閲覧するための出力デバイスを需要家構内において需要家に提供するとよい。さらに、需要家が動作制御センター116と通信できるよう、入力デバイスキーボードなどが家庭内ディスプレイ165に関連付けられてもよい。一実施形態では、家庭内ディスプレイ165は、需要家構内にあるコンピュータを含むとよい。需要家構内165はさらに、需要家構内179の1つ以上のデバイスを制御するとよい制御167を含むとよい。ヒーター、空調装置など、需要家構内179にある様々な電化製品が、動作制御センター116からのコマンドに応じて制御されるとよい。図1Aに示されているように、需要家構内169は、インターネット168、公衆交換電話ネットワークPSTN169を介して、または専用線を介してコレクタ164を介してなどなど、様々な方法で通信するとよい。列挙された通信チャネルのいずれかを介して、1つ以上の需要家構内179からのデータが送信されるとよい。図1に示されているように、1つ以上の需要家構内179が、ユーティリティ管理ネットワーク160を介して動作制御センター116へ伝送されるようコレクタ164へデータを送信する、スマート計器ネットワーク178複数のスマート計器163を含むを含むとよい。さらに、分散型エネルギー生成/貯蔵162ソーラーパネルなどの様々なソースが、ユーティリティ管理ネットワーク160を介した動作制御センター116との通信のために、監視制御161へデータを送信するとよい。上記のように、動作制御センター116外の電力グリッド内のデバイスは、処理および/または記憶能力を含むとよい。デバイスは、INDESUBSTATION180およびINDEDEVICE188を含むとよい。電力グリッド内の個別のデバイスが追加のインテリジェンスを含むことに加えて、個別のデバイスは、情報センサーデータおよび/または分析データイベントデータなどを含むを交換するため、電力グリッドの状態を分析するため故障の判断など、および電力グリッドの状態を変更するため故障の修正などに、電力グリッド内の他のデバイスと通信するとよい。具体的には、個別のデバイスは、1インテリジェンス処理能力など、2記憶装置上記の分散型記憶装置などおよび3通信上記の1つ以上のバスの使用などを使用するとよい。このようにして、電力グリッド内の個別のデバイスは、動作制御センター116からの監督なしに相互に通信および協働するとよい。例えば、上記で開示されたINDEアーキテクチャは、フィーダ回路上の少なくとも1つのパラメータを感知するデバイスを含むとよい。デバイスはさらに、フィーダ回路上で感知されたパラメータを監視し、感知されたパラメータを分析してフィーダ回路の状態を判断するプロセッサを含むとよい。例えば、感知パラメータの分析は、感知されたパラメータと、所定の閾値との比較を含んでもよく、さらに/または傾向分析を含んでもよい。上記の感知されるパラメータの1つには、波形の感知が含まれてもよく、上記の分析の1つには、感知された波形がフィーダ回路上の故障を示すかどうかを判断することが含まれてもよい。デバイスはさらに、1つ以上の変電所と通信するとよい。例えば、特定の変電所が、特定のフィーダ回路に電力を供給するとよい。デバイスは、その特定のフィーダ回路の状態を感知して、特定のフィーダ回路上に故障があるかどうかを判断するとよい。デバイスは、変電所と通信するとよい。変電所は、デバイスによって判断された故障を分析するとよく、故障に応じて修正措置を取るとよいフィーダ回路に供給される電力を削減するなど。デバイスが故障を示すデータを送信する波形の分析に基づき例では、変電所は、動作制御センター116からの入力なしに、フィーダ回路に供給される電力を変更するとよい。または変電所は、故障を示すデータと、他のセンサーからの情報とを組み合わせて、故障の分析をさらに精緻化してもよい。変電所はさらに、供給停止インテリジェンスアプリケーション説明される図13A~Bでなどおよび/または故障インテリジェンスアプリケーション図14A~Cで説明されるものなどなど、動作制御センター116と通信してもよい。したがって、動作制御センター116が、故障を判断してもよく、供給停止の範囲故障の影響を受ける戸数などを判断してもよい。このように、フィーダ回路の状態を感知するデバイスは、動作制御センター116の介入を要求するかしないかに関わらず、考えられる故障を修正するために変電所と協調動作するとよい。別の例として、処理および/またはメモリ能力を使用する追加のインテリジェンスを含むラインセンサーが、グリッドの一部分フィーダ回路などにおいてグリッド状態データを作り出してもよい。グリッド状態データは、動作制御センター116の需要応答管理システム155と共有されるとよい。需要応答管理システム155は、ラインセンサーからのグリッド状態データに応答して、フィーダ回路上の需要家サイトの1つ以上のデバイスを制御してもよい。具体的には、需要応答管理システム155は、ラインセンサーがフィーダ回路上の供給停止を示すのに応答して、フィーダ回路から電力を受ける需要家サイトにある電化製品をオフにすることによってフィーダ回路への負荷を軽減するよう、エネルギー管理システム156および/または配電管理システム157に命令してもよい。このように、ラインセンサーは需要応答管理システム155とともに、故障したフィーダ回路から自動的に負荷を移し、続いて故障を隔離するとよい。さらに別の例として、電力グリッド内の1つ以上のリレーが、それに関連するマイクロプロセッサを有するとよい。これらのリレーは、故障の判断、および/または電力グリッドの制御のために、電力グリッド内にある他のデバイスおよび/またはデータベースと通信するとよい。INDSIntelligentNetworkDataServices:インテリジェントネットワークデータサービスの概念およびアーキテクチャアウトソースされるスマートグリッドデータ/解析サービスモデルスマートグリッドアーキテクチャに対する1つの応用は、ユーティリティが、組織内に従来の制御システムおよび関係する運用システムを保ちながら、グリッドデータ管理および解析サービスを契約できるようにする。このモデルでは、ユーティリティはグリッドセンサーおよびデバイスを設置および所有するとよく上記のように、グリッドデータ搬送通信システムは、所有および運用しても、アウトソースしてもよい。グリッドデータは、ユーティリティからリモートのインテリジェントネットワークデータサービスINDSホスティングサイトへ流れるとよく、そこでデータが管理、記憶および分析されるとよい。その結果、ユーティリティは、適切なサービス財務モデルのもとでデータおよび解析サービスを契約することもできる。ユーティリティは、料金を払う代わりに、初期資本支出投資と、スマートグリッドデータ/解析インフラストラクチャの管理、サポートおよび改良の継続的な費用とを回避することができる。上記のINDE参照アーキテクチャは、本願明細書に記載されるアウトソース用の構成に適している。スマートグリッドサービスのINDSアーキテクチャINDSサービスモデルを実装するために、INDE参照アーキテクチャは、リモートでホストされるとよい構成要素のグループと、ユーティリティに残るとよいものとに区分されるとよい。図6A~Cは、INDECORE120がリモートにされるとユーティリティアーキテクチャがどのように見えると考えられるかを示す。サーバが、INDECORE120の一部として含まれるとよく、リモートシステムへのインターフェースとして機能するとよい。ユーティリティシステムには、これが仮想INDECORE602に見えるとよい。図6A~Cの全体的なブロック図600が示すように、INDESUBSTATION180およびINDEDEVICE188グループは、図1A~Cに示されたものから変化していない。さらに、複数バス構造も、ユーティリティにてやはり採用されるとよい。INDECORE120は、図7のブロック図700が示すようにリモートでホストされるとよい。ホスティングサイトでは、ユーティリティのINDS契約者をサポートするために、必要に応じINDECORE120が設置されるとよい北米INDSホスティングセンター702として示されている。各CORE120は、モジュラーシステムであり、その結果新たな契約者の追加は定型操作であるとよい。電気ユーティリティとは別の関係者が、INDECORE120の1つ、いくつかまたはすべてのソフトウェアと、INDSホスティングサイトから各ユーティリティのINDESUBSTATION180およびINDEDEVICE188にダウンロードされるアプリケーションとを管理およびサポートするとよい。通信を促進するために、契約ユーティリティの動作センターならびにINDSホスティングサイトに到達することができるネットワーク704例えばMPLSまたはその他のWANなどを介した高帯域低遅延通信サービスが使用されるとよい。図7に示されているように、カリフォルニア州、フロリダ州およびオハイオ州など、様々なエリアにサービスが提供されるとよい。このような運用のモジュール性は、異なる様々なグリッドの効率的な管理を可能にするのみではなく、グリッド間のよりよい管理も可能にする。1つのグリッドの不具合が、周辺のグリッドの動作に影響を及ぼす恐れがある場合がある。例えば、オハイオ州のグリッドにおける不具合が、中部大西洋岸のグリッドなど、周辺のグリッドにおける動作に対しカスケード効果を有することもある。図7に示されているモジュール構造を使用することで、個別のグリッドの管理およびグリッド間動作の管理が可能になる。具体的には、全体的なINDSシステムプロセッサおよびメモリを含むが、様々なINDECORE120間の対話を管理するとよい。これは、1つのグリッドから別のグリッドへ波及する破局故障の可能性を軽減するとよい。例えば、オハイオ州のグリッドにおける不具合が、中部大西洋岸のグリッドなど、周辺のグリッドに波及することもある。オハイオ州のグリッドの管理専用のINDECORE120は、オハイオ州のグリッドにおける不具合の修正を試みるとよい。さらに、全体的なINDSシステムが、波及不具合が周辺グリッドで生じる可能性を軽減することを試みるとよい。INDECOREにおける機能性の具体的な例図1、6および7に示されているように、様々な機能性ブロックにより表されているがINDECORE120に含まれており、示されているもののうち2つは、計器データ管理サービスMDMS:meterdatamanagementservices121ならびに計測解析およびサービス122である。アーキテクチャのモジュール性が理由で、MDMS121ならびに計測解析およびサービス122などの様々な機能性を組み込むことができる。可観測性プロセス上記のように、アプリケーションサービスの1つの機能性は、可観測性プロセスを含むとよい。可観測性プロセスは、ユーティリティがグリッドを観測できるようにするとよい。こうしたプロセスは、グリッド上のすべてのセンサーおよびデバイスから受信される生データを解釈して、それを実用的な情報へ変えることを担当するとよい。図8は、可観測性プロセスのいくつかの例の列挙を含む。図9A~Bは、グリッド状態測定動作プロセスのフロー図900を示す。図のように、ブロック902にて示されているように、データスキャナが計器データをリクエストするとよい。リクエストは、1つ以上のグリッドデバイス、変電所コンピュータおよびラインセンサーRTUへ送信されるとよい。デバイスは、ブロック904、908、912にて示されているように、リクエストに応答して動作データを収集するとよく、ブロック906、910、914にて示されているように、データ電圧、電流、有効電力および無効電力データなどの運用データのうちの1つ、いくつかまたはすべてなどを送信するとよい。データスキャナは、ブロック926にて示されているように、運用データを収集するとよく、ブロック928にて示されているように、データを運用データストアへ送信するとよい。ブロック938にて示されているように、運用データストアは運用データを記憶するとよい。ブロック940にて示されているように、運用データストアはさらに、データのスナップショットをヒストリアンへ送信するとよく、ブロック942にて示されているように、ヒストリアンは、データのスナップショットを記憶するとよい。計器状態アプリケーションは、ブロック924に示されているように、計器データのリクエストを計器DCEdatacollectionengine:データ収集エンジンへ送信するとよく、その結果として計器DCEは、ブロック920にて示されているように、計器データ収集のリクエストを1つ以上の計器へ送信する。この1つ以上の計器は、リクエストに応答して、ブロック916にて示されているように、計器データを収集し、ブロック918にて示されているように、電圧データを計器DCEへ送信する。計器DCEは、ブロック922にて示されているように電圧データを収集して、ブロック928にて示されているようにデータをデータのリクエスタへ送信するとよい。計器状態アプリケーションは、ブロック930にて示されているように、計器データを受信し、ブロック932にて示されているように、それが単一値プロセスに関するか、電圧プロフィールグリッド状態に関するかを判断するとよい。単一値プロセスに関するものであれば、ブロック936にて示されているように、計器データはリクエストしているプロセスへ送信される。計器データが、後からグリッド状態を判断するために記憶されるものであれば、ブロック938にて示されているように、計器データは運用データストアに記憶される。ブロック940にて示されているように、運用データストアはさらに、データのスナップショットをヒストリアンへ送信して、ブロック942にて示されているように、ヒストリアンは、データのスナップショットを記憶する。図9A~Bはさらに、需要応答DRに関するアクションを示す。需要応答は、例えば電気の需要家にその消費を、緊急時、または市場価格に応じて削減させるなど、供給条件に応じて需要家の電気消費を管理するための動的需要メカニズムを指す。これは、実際に使用電力を削減することを伴っても、オンサイト発電を開始することによってもよく、オンサイト発電は、グリッドと並列接続されていても、されていなくてもよい。これは、同じタスクを実行するために継続的に、または当該タスクが実行されるときに必ず、より少ない電力を使用することを意味する、エネルギー効率とは異なると考えられる。需要応答では、1つ以上の制御システムを使用する需要家が、ユーティリティによるリクエストまたは市場価格条件に応じて負荷を制限するとよい。サービス明かり、機械、空調は、緊急の時間フレームの間、事前計画された負荷優先順位付けスキームに従って削減されるとよい。負荷制限の代替手段は、電力グリッドを補うための、電気のオンサイト発電である。逼迫した電気供給状況のもとでは、需要応答により、最高値および全般的な電気価格の変動が大幅に低減され得る。需要応答は、一般に、消費者が需要を減らすことを促し、それによって電気のピーク需要を減らすよう使用されるメカニズムを指すために使用される。電気システムは、一般に、ピーク需要それに加えてエラーおよび予期せぬイベントに備えた余裕に対応するような規模であり、ピーク需要が減れば、全体的な施設および資本コスト要件が緩和され得る。一方、発電容量の構成次第で、需要応答は、大量生産低需要のときに需要負荷を増やすためにも使用され得る。それによって、一部のシステムは、低需要および高需要または安値および高値の期間の間の裁定取引を行うためのエネルギー貯蔵を促すこともできる。システムにおいて、風力などの断続的な電力源の割合が増えるにつれて、需要応答は電気グリッドの効果的な管理にますます重要になると考えられる。ブロック954にて示されているように、DR状態アプリケーションは、DR利用可能容量をリクエストするとよい。続いて、ブロック948にて示されているように、DR管理システムは、1つ以上のDRホームデバイスからの利用可能容量をリクエストするとよい。この1つ以上のホームデバイスは、ブロック944にて示されているように、リクエストに応答して利用可能なDR容量を収集して、ブロック946にて示されているように、DR容量および応答データをDR管理システムへ送信するとよい。DR管理システムは、ブロック950にて示されているように、DR容量および応答データを収集して、ブロック952にて示されているように、DR容量および応答データをDR状態アプリケーションへ送信するとよい。DR状態アプリケーションは、ブロック956にて示されているように、DR容量および応答データを受信して、ブロック958にて示されているように、容量および応答データを運用データストアへ送信するとよい。ブロック938にて示されているように、運用データストアはDR容量および応答データを記憶するとよい。ブロック940にて示されているように、運用データストアはさらに、データのスナップショットをヒストリアンへ送信するとよく、ブロック942にて示されているように、ヒストリアンは、データのスナップショットを記憶するとよい。ブロック974にて示されているように、変電所コンピュータは、変電所アプリケーションからのアプリケーションデータをリクエストするとよい。それに応答して、ブロック964にて示されているように、変電所アプリケーションは、変電所デバイスからのアプリケーションをリクエストするとよい。変電所デバイスは、ブロック960にて示されているように、アプリケーションデータを収集して、ブロック962にて示されているように、変電所デバイスにアプリケーションデータを送信するとよい電圧、電流、有効電力および無効電力データのうちの1つ、いくつかまたはすべてを含むとよい。変電所アプリケーションは、ブロック966にて示されているように、アプリケーションデータを収集して、ブロック968にて示されているように、アプリケーションデータをリクエスタ変電所コンピュータであってもよいへ送信するとよい。変電所コンピュータは、ブロック970にて示されているように、アプリケーションデータを受信して、ブロック972にて示されているように、アプリケーションデータを運用データストアへ送信するとよい。グリッド状態測定および運用データプロセスは、所定の時点でのグリッド状態およびグリッドトポロジを得ること、ならびにこの情報を他のシステムおよびデータストアに提供することを含み得る。サブプロセスは、1グリッド状態情報を測定および保存することこれは、前に説明した、グリッドに関連する運用データに関係する、2グリッド状態情報を他の解析アプリケーションへ送信することこれは、分析アプリケーションなどの他のアプリケーションがグリッド状態データにアクセスできるようにする、3グリッド状態スナップショットを接続性/運用データストアに維持することこれは、接続性/運用データストアのグリッド状態情報を適切なフォーマットで更新すること、ならびに或る時点でのグリッドトポロジを後の時点で得られるように、この情報を維持のためにヒストリアンへ転送することを可能にする、4デフォルトの接続性および現在のグリッド状態に基づき、或る時点でのグリッドトポロジを得ることこれは、下記でさらに詳しく説明するように、ヒストリアン内のグリッド状態の所定の時点でのスナップショットを、接続性データストア内の基礎となる接続性に適用することによって、その時点でのグリッドトポロジを提供する、ならびに5リクエストに応じてグリッドトポロジ情報をアプリケーションに提供することを含むとよい。サブプロセス4に関しては、グリッドトポロジはリアルタイム、30秒前、1ヶ月前など、所定時間に関して得られるとよい。グリッドトポロジを再現するために、複数のデータベースが使用されてもよく、グリッドトポロジを再現するために複数のデータベース内のデータにアクセスするプログラム。1つのデータベースは、基礎となる接続性データを記憶するリレーショナルデータベースを含むとよい接続性データベース。接続性データベースは、ベースライン接続性モデルを判断するための、施工完了時のグリッドトポロジ情報を保持しているとよい。電力グリッド内の回路の追加または変更など例えば、電力グリッドに追加される追加のフィーダ回路、電力グリッドの改良に応じて、アセットおよびトポロジ情報が定期的にこのデータベースに対し更新されるとよい。接続性データベースは、変化しないことから静的と見なされてもよい。接続性データベースは、電力グリッドの構造に変更があれば変化するとよい。例えば、フィーダ回路の追加など、フィーダ回路に変更があれば接続性データベースが変化するとよい。接続性データベースの構造1800の一例は、図18A~Dに示されている階層モデルから得られるとよい。構造1800は、4つのセクションに分割されており、図18Aは左上のセクション、図18Bは右上のセクション、図18Cは左下のセクション、さらに図18Dは右下のセクションである。具体的には、図18A~Dは、ベースライン接続性データベースを表す抽象法である、エンティティ関係図の例である。図18A~Dの階層モデルは、電力グリッドを表すメタデータを保持するとよく、グリッドの様々なコンポーネントおよびコンポーネント間の関係を表すとよい。第2のデータベースは、動的データを記憶するために使用されるとよい。第2のデータベースは、非リレーショナルデータベースを含むとよい。非リレーショナルデータベースの一例は、時系列の非運用データおよび過去の運用データを記憶する、ヒストリアンデータベースを含み得る。ヒストリアンデータベースは、1タイムスタンプ、2デバイスID、3データ値および4デバイスステータスなどの一連のフラットレコードを記憶するとよい。さらに、記憶されるデータは圧縮されるとよい。このため、電力グリッド内の動作/非運用データが容易に記憶されるとよく、かなりの量のデータが利用可能であるにもかかわらず、管理可能であるとよい。例えば、5テラバイトオーダーのデータが、グリッドトポロジを再現するために用いられるよういつでもオンラインであってもよい。データは単純なフラットレコードで記憶されるため編成手法が用いられないなど、データの記憶における効率性が与えられる。下記でさらに詳しく説明するように、データは、タイムスタンプなどの特定のタグによりアクセスされてもよい。グリッドの様々な解析が、特定の時点のグリッドトポロジを入力として受信することを望み得る。例えば、電力品質、信頼性、アセット正常性などに関する解析が、グリッドトポロジを入力として使用し得る。グリッドトポロジを判断するために、接続性データベース内のデータにより定義されるベースライン接続性モデルがアクセスされるとよい。例えば、特定のフィーダ回路のトポロジが求められる場合、ベースライン接続性モデルは、電力グリッド内の特定のフィーダ回路内の様々なスイッチを定義するとよい。その後、特定のフィーダ回路内のスイッチの値を判断するために、ヒストリアンデータベースがアクセスされるとよい特定の時間に基づき。次に、特定時間の特定のフィーダ回路の表現を生成するために、プログラムが、ベースライン接続性モデルおよびヒストリアンデータベースからのデータを結合するとよい。グリッドトポロジの判断のより複雑な例は、インタータイスイッチおよび区分スイッチを有する複数のフィーダ回路例えばフィーダ回路Aおよびフィーダ回路Bを含み得る。特定のスイッチインタータイスイッチおよび/または区分スイッチなどのスイッチ状態に応じて、フィーダ回路のセクションは、フィーダ回路Aまたはフィーダ回路Bに属し得る。グリッドトポロジを判断するプログラムは、特定の時間の接続性例えば、どの回路がフィーダ回路Aまたはフィーダ回路Bに属するかを判断するために、ベースライン接続性モデルおよびヒストリアンデータベース両方からのデータにアクセスするとよい。図10は、非運用データプロセスのフロー図1000を示す。ブロック1002にて示されているように、非運用抽出アプリケーションが、非運用データをリクエストするとよい。それに応答して、ブロック1004にて示されているように、データスキャナが非運用データを集めるとよく、それによって、ブロック1006、1008、1110にて示されているように、グリッドデバイス、変電所コンピュータおよびラインセンサーRTUなどの電力グリッド内の様々なデバイスが非運用データを収集するとよい。上記のように、非運用データは、温度、電力品質などを含むとよい。ブロック1012、1014、1116にて示されているように、グリッドデバイス、変電所コンピュータおよびラインセンサーRTUなど、電力グリッド内の様々なデバイスが、非運用データをデータスキャナへ送信するとよい。データスキャナは、ブロック1018にて示されているように、非運用データを収集して、ブロック1020にて示されているように、非運用データを非運用抽出アプリケーションへ送信するとよい。非運用抽出アプリケーションは、ブロック1022にて示されているように、非運用データを収集して、ブロック1024にて示されているように、収集した非運用データをヒストリアンへ送信するとよい。ヒストリアンは、ブロック1026にて示されているように、非運用データを受信し、ブロック1028にて示されているように、非運用データを記憶し、ブロック1030にて示されているように、非運用データを1つ以上の解析アプリケーションへ送信するとよい。図11は、イベント管理プロセスのフロー図1100を示す。データは、電力グリッド内の様々なイベントに基づき様々なデバイスから生成されて、イベントバス147を介して送信されるとよい。例えば、ブロック1102にて示されているように、計器データ収集エンジンは、電力供給停止/復旧通知情報をイベントバスへ送信するとよい。ブロック1104にて示されているように、ラインセンサーRTUは、故障メッセージを生成して、その故障メッセージをイベントバスへ送信するとよい。変電所は解析は、ブロック1106にて示されているように、故障および/または供給停止メッセージを生成するとよく、その故障および/または供給停止メッセージをイベントバスへ送信するとよい。ブロック1108にて示されているように、ヒストリアンは、信号挙動をイベントバスへ送信するとよい。さらに、様々なプロセスがイベントバス147を介してデータを送信するとよい。例えば、ブロック1110にて示されているように、図14A~Cにさらに詳しく説明されている故障インテリジェンスプロセスが、イベントバスを介して故障分析イベントを送信するとよい。ブロック1112にて示されているように、図13A~Bにさらに詳しく説明されている供給停止インテリジェンスプロセスが、イベントバスを介して供給停止イベントを送信するとよい。ブロック1114にて示されているように、イベントバスは様々なイベントを収集するとよい。さらに、複合イベント処理CEPサービスが、ブロック1120にて示されているように、イベントバスを介して送信されたイベントを処理するとよい。CEPサービスは、複数の同時の高速リアルタイムイベントメッセージストリームに対するクエリを処理するとよい。ブロック1118にて示されているように、CEPサービスによる処理の後、イベントデータはイベントバスを介して送信されるとよい。さらに、ブロック1116にて示されているように、ヒストリアンが、記憶用の1つ以上のイベントログを、イベントバスを介して受信するとよい。さらに、ブロック1122にて示されているように、イベントデータは、供給停止管理システムOMS、供給停止インテリジェンス、故障解析など、1つ以上のアプリケーションにより受信されるとよい。このように、イベントバスは、イベントデータをアプリケーションへ送信するとよく、それによって、データを他のデバイスまたは他のアプリケーションに利用可能にしないというサイロ問題を回避する。図12A~Cは、需要応答DRシグナリングプロセスのフロー図1200を示す。ブロック1244にて示されているように、DRが配電動作アプリケーションによりリクエストされるとよい。それに応答して、グリッド状態/接続性は、ブロック1202にて示されているように、DR利用可能性データを収集するとよく、ブロック1204にて示されているように、データを送信するとよい。配電動作アプリケーションは、ブロック1246にて示されているように、DR利用可能性最適化を、イベントバスを介してブロック12541つ以上のDR管理システムに配布するとよい。DR管理システムは、ブロック1272にて示されているように、DR情報および信号を1つ以上の需要家構内へ送信するとよい。この1つ以上の需要家構内は、ブロック1266にて示されているように、DR信号を受信し、ブロック1268にて示されているように、DR応答を送信するとよい。DR管理は、ブロック1274にて示されているように、DR応答を受信して、ブロック1276にて示されているように、動作データバス146、請求データベースおよびマーケティングデータベースのうちの1つ、いくつかまたはすべてにDR応答を送信するとよい。ブロック1284、1288にて示されているように、請求データベースおよびマーケティングデータベースは、応答を受信するとよい。動作データバス146も、ブロック1226にて示されているように、応答を受信して、ブロック1228にて示されているように、DR応答および利用可能容量をDRデータ収集へ送信するとよい。DRデータ収集は、ブロック1291にて示されているように、DR応答および利用可能容量を処理して、そのデータを、ブロック1294にて示されているように、動作データバスへ送信するとよい。ブロック1230にて示されているように、動作データバスは、DR利用可能性および応答を受信して、それをグリッド状態/接続性へ送信するとよい。ブロック1208にて示されているように、グリッド状態/接続性はデータを受信するとよい。受信されたデータは、グリッド状態データを判断するために使用されるとよく、それが動作データバスを介してブロック1220送信されるとよいブロック1206。ブロック1248にて示されているように、配電動作アプリケーションは、グリッド状態データDR最適化のためのイベントメッセージとしてを受信するとよい。ブロック1250にて示されているように、配電動作アプリケーションは、グリッド状態データならびにDR利用可能性および応答を使用して配電最適化を実行し、配電データを生成するとよい。配電データは、ブロック1222にて示されているように、動作データバスにより読み出されるとよく、ブロック1240にて示されているように、接続性抽出アプリケーションへ送信されるとよい。運用データバスは、データを配電動作アプリケーションへ送信するとよくブロック1224、次に配電動作アプリケーションが、1つ以上のDR信号を1つ以上のDR管理システムへ送信するとよいブロック1252。イベントバスは、この1つ以上のDR管理システムそれぞれに関して信号を収集してブロック1260、DR信号を各DR管理システムへ送信するとよいブロック1262。次に、DR管理システムは上記のようにDR信号を処理するとよい。ブロック1214にて示されているように、通信動作ヒストリアンは、データをイベントバスへ送信するとよい。ブロック1212にて示されているように、通信動作ヒストリアンはさらに、生成ポートフォリオデータを送信するとよい。または、Ventyx登録商標などのアセット管理デバイスが、ブロック1232にて示されているように、仮想発電所VPP:virtualpowerplant情報をリクエストするとよい。動作データバスは、ブロック1216にて示されているように、VPPデータを収集して、ブロック1218にて示されているように、データをアセット管理デバイスへ送信するとよい。アセット管理デバイスは、ブロック1234にて示されているように、VPPデータを収集して、ブロック1236にて示されているように、システム最適化を実行して、ブロック1238にて示されているように、イベントバスへVPP信号を送信するとよい。イベントバスは、ブロック1256にて示されているように、VPP信号を受信して、ブロック1258にて示されているように、VPP信号を配電動作アプリケーションへ送信するとよい。その結果、配電動作アプリケーションは、上記のようにイベントメッセージを受信および処理するとよい。ブロック1278にて示されているように、接続抽出アプリケーションは、ブロック1290にて示されているようにマーケティングデータベースへ送信される新規需要家データを、抽出するとよい。ブロック1280にて示されているように、新規需要家データはグリッド状態/接続性へ送信されるとよく、その結果、ブロック1210にて示されているように、グリッド状態接続性は新たなDR接続性データを受信するとよい。オペレーターは、ブロック1242にて示されているように、適切な場合、1つ以上のオーバーライド信号を送信するとよい。オーバーライド信号は、配電動作アプリケーションへ送信されるとよい。オーバーライド信号は、ブロック1264にて示されているようにエネルギー管理システム、ブロック1282にて示されているように請求データベース、および/またはブロック1286にて示されているようにマーケティングデータベースへ送信されるとよい。図13A~Bは、供給停止インテリジェンスプロセスのフロー図1300を示す。様々なデバイスおよびアプリケーションが、ブロック1302、1306、1310、1314、1318にて示されているように、電力供給停止通知を送信し得る。ブロック1324にて示されているように、供給停止イベントはイベントバスにより収集され、ブロック1326にて示されているように、イベントバスは、複合イベント処理CEPへ供給停止イベントを送信するとよい。さらに、様々なデバイスおよびアプリケーションが、ブロック1304、1308、1312、1316、1320にて示されているように、電力復旧ステータスを送信し得る。CEPは、供給停止および復旧ステータスメッセージを受信しブロック1330、イベントを処理しブロック1332、イベントデータを送信するとよいブロック1334。供給停止インテリジェンスアプリケーションは、イベントデータを受信してブロック1335、グリッド状態および接続性データをリクエストするとよいブロック1338。運用データバスは、グリッド状態および接続性データのリクエストを受信してブロック1344、それを運用データストアおよびヒストリアンのうちの一方または両方へ転送するとよい。それに応答して、運用データストアおよびヒストリアンは、運用データバスを介してブロック1346供給停止インテリジェンスアプリケーションへブロック1340、グリッド状態および接続性データを送信するとよいブロック1352、1354。ブロック1342にて示されているように、グリッド状態および接続性データが、これが瞬時停電であったかどうかを示すかどうかが判断される。そうであれば、その瞬時停電が、運用データバスを介してブロック1348、記憶用に瞬時停電データベースへ送信されるブロック1350。そうでなければ、供給停止ケースが作成されブロック1328、供給停止ケースデータが、供給停止管理システムにより記憶および処理されるブロック1322。供給停止インテリジェンスプロセスは、供給停止を検出し、瞬時停電を分類してログを取り、供給停止の範囲を判断し、供給停止の主要因単数または複数を判断し、供給停止復旧を追跡し、供給停止イベントを発し、システムパフォーマンス指数を更新するとよい。図14A~Cは、故障インテリジェンスプロセスのフロー図1400を示す。ブロック1416にて示されているように、複合イベント処理は、1つ以上のデバイスからのデータをリクエストするとよい。例えば、ブロック1404にて示されているように、グリッド状態および接続性は、リクエストに応答して、グリッド状態および接続性データを複合イベント処理へ送信するとよい。同様に、ブロック1410にて示されているように、ヒストリアンは、リクエストに応答してリアルタイムスイッチ状態を複合イベント処理へ送信するとよい。さらに、ブロック1418にて示されているように、複合イベント処理は、グリッド状態、接続性データおよびスイッチ状態を受信するとよい。ブロック1428にて示されているように、変電所解析は故障データをリクエストするとよい。ブロック1422、1424にて示されているように、故障データが、ラインセンサーRTU、および変電所コンピュータなど、様々なデバイスにより送信されるとよい。様々な故障データ、グリッド状態、接続性データおよびスイッチ状態が、ブロック1430にて示されているように、イベント検出および特徴付けのために変電所解析へ送信されるとよい。イベントバスはさらに、イベントメッセージを受信してブロック1434、イベントメッセージを変電所解析へ送信するとよいブロック1436。ブロック1432にて示されているように、変電所解析はイベントのタイプを判断するとよい。ブロック1426にて示されているように、保護および制御変更イベントに関しては、変電所コンピュータが故障イベントメッセージを受信するとよい。その他すべてのタイプのイベントに関しては、イベントがイベントバスにより受信されブロック1438、複合イベント処理へ送信されるとよいブロック1440。複合イベント処理は、さらなる処理のためにイベントデータを受信するとよいブロック1420。同様に、グリッド状態および接続性は、ブロック1406にて示されているように、グリッド状態データを複合イベント処理へ送信するとよい。さらに、ブロック1414にて示されているように、共通情報モデルCIMウェアハウスがメタデータを複合イベント処理へ送信するとよい。複合イベント処理は、ブロック1420にて示されているように故障イベントメッセージを送信するとよい。イベントバスは、メッセージを受信してブロック1442、イベントメッセージを故障インテリジェンスアプリケーションへ送信するとよいブロック1444。故障インテリジェンスアプリケーションは、イベントデータを受信してブロック1432、ブロック1456にて示されているように、グリッド状態、接続性データおよびスイッチ状態をリクエストするとよい。リクエストに応答して、グリッド状態および接続性はグリッド状態および接続性データを送信しブロック1408、ヒストリアンはスイッチ状態データを送信するブロック1412。故障インテリジェンスは、データを受信してブロック1458、データを分析し、イベントデータを送信するブロック1460。イベントデータは、イベントバスにより受信されブロック1446、故障ログファイルへ送信されるとよいブロック1448。故障ログファイルは、イベントデータのログを取るとよいブロック1402。イベントデータはさらに、運用データバスにより受信されるとよくブロック1462、1つ以上のアプリケーションへ送信するブロック1464。例えば、図13A~Bに関して上記で説明した、供給停止インテリジェンスアプリケーションが、イベントデータを受信するとよいブロック1466。作業管理システムも、ブロック1468にて示されているように、作業命令という形でイベントデータを受信するとよい。さらに、ブロック1470にて示されているように、他のリクエストしているアプリケーションが、イベントデータを受信してもよい。故障インテリジェントプロセスは、グリッドデータを解釈して、グリッド内での現在の、および潜在的な故障についての情報を得ることを担当するとよい。具体的には、故障は、故障インテリジェントプロセスを使用して検出されるとよい。故障は、典型的には、ユーティリティの設備が機能しなくなったとき、または例えば垂れ下がった電線など、電流フローの代替パスがつくられたときにもたらされる短絡である。このプロセスは、典型的な故障典型的には従来の故障検出および保護設備であるリレー、ヒューズなどによって対処される、ならびに故障電流を使用して容易に検出することができないグリッド内の高インピーダンス故障を検出するために使用されるとよい。故障インテリジェンスプロセスはさらに、故障を分類およびカテゴリ化するとよい。これにより、故障が分類およびカテゴリ化されることが可能になる。現在、故障の体系的な編成および分類のための標準は存在しない。これに関して事実上の標準が確立され、実装されるとよい。故障インテリジェンスプロセスは故障をさらに特徴付けてもよい。故障インテリジェンスはさらに、故障の位置を判断するとよい。不平衡負荷、3相、2相および単相ラテラル、センサー/測定の欠如、種々のタイプの故障、短絡の種々の原因、変化する負荷条件、複数のラテラルを備えた長いフィーダ、文書化されていないネットワーク構成など、配電システムの固有の特徴によりもたらされるその高い複雑性および困難性が原因で、配電システムにおける故障の位置特定は難しいタスクであることもある。このプロセスは、技術的に可能な限りの正確さで故障の位置を隔離するためのいくつかの技法の使用を可能にする。故障インテリジェンスはさらに、故障イベントを発するとよい。具体的には、このプロセスは、故障が検出、分類、カテゴリ化、特徴付けおよび隔離されると、故障イベントを作成してイベントバスへ発行するとよい。このプロセスはさらに、不具合がある中では典型的である、生イベントに基づく大量発生ではなく、個々の故障イベントを発するよう、故障の収集、フィルタリング、照合および重複除去を担当するとよい。最終的に、故障インテリジェンスは、イベントログデータベースに故障イベントのログを取るとよい。図15A~Bは、メタデータ管理プロセスのフロー図1500を示す。メタデータ管理プロセスは、ポイントリスト管理、および通信接続性プロトコル管理、および構成要素命名翻訳、センサー較正係数管理、およびリアルタイムグリッドトポロジデータ管理を含むとよい。ブロック1502にて示されているように、ベース接続性抽出アプリケーションは、ベース接続性データをリクエストするとよい。地理情報システムGISは、リクエストを受信してブロック1510、データをベース接続性抽出アプリケーションへ送信するとよいブロック1512。ベース接続性抽出アプリケーションは、データを受信してブロック1504、データを抽出、変換およびロードしブロック1506、ベース接続性データを接続性データマートへ送信するとよいブロック1508。その後、ブロック1514にて示されているように、接続性データマートはデータを受信するとよい。接続性データマートは、グリッドのコンポーネントの電気的接続性情報を含むカスタムデータストアを含むとよい。図15A~Bに示されているように、この情報は、典型的には、グリッドを構成するコンポーネントの施工完了時の地理的位置を保持する、ユーティリティの地理情報システムGISから得られるとよい。このデータストア内のデータは、グリッドのすべてのコンポーネント変電所、フィーダ、セクション、セグメント、ブランチ、tセクション、回路遮断器、リクローザー、スイッチなど、基本的にすべてのアセットについての階層情報を記述する。このデータストアは、施工完了時のアセットおよび接続性情報を有するとよい。メタデータ抽出アプリケーションは、ブロック1516にて示されているように、グリッドアセットに関するメタデータをリクエストするとよい。メタデータデータベースは、リクエストを受信してブロック1524、メタデータを送信するとよいブロック1526。メタデータ抽出アプリケーションは、メタデータを受信してブロック1518、メタデータを抽出、変換およびロードしブロック1520、メタデータをCIMデータウェアハウスへ送信するとよいブロック1522。次に、CIM共通情報モデルデータウェアハウスは、ブロック1528にて示されているようにデータを記憶するとよい。CIMは、ユーティリティデータを表すためのユーティリティ標準フォーマットを規定するとよい。INDEスマートグリッドは、ユーティリティ標準フォーマットで、スマートグリッドからの情報の利用可能性を促進するとよい。さらに、CIMデータウェアハウスは、INDE特有のデータの、規定のユーティリティ標準フォーマットなど1つ以上のフォーマットへの変換を促進するとよい。ブロック1530にて示されているように、アセット抽出アプリケーションは、新たなアセットに関する情報をリクエストするとよい。アセットレジストリは、リクエストを受信してブロック1538、新たなアセットに関する情報を送信するとよいブロック1540。アセット抽出アプリケーションは、新たなアセットに関する情報を受信してブロック1532、データを抽出、変換およびロードしブロック1534、新たなアセットに関する情報をCIMデータウェアハウスへ送信するとよいブロック1536。ブロック1542にて示されているように、DR接続性抽出アプリケーションは、DR接続性データをリクエストするとよい。ブロック1548にて示されているように、運用データバスは、DR接続性データリクエストをマーケティングデータベースへ送信するとよい。マーケティングデータベースはリクエストを受信してブロック1554、DR接続性データを抽出、変換、ロードしブロック1556、DR接続性データを送信するとよいブロック1558。運用データバスは、DR接続性データをDR接続性抽出アプリケーションへ送信するとよいブロック1550。DR接続性抽出アプリケーションは、DR接続性データを受信してブロック1544、DR接続性データを、運用データバスを介してブロック1552グリッド状態および接続性DMへ送信するブロック1546とよく、グリッド状態および接続性DMはDR接続性データを記憶するブロック1560。図16は、通知エージェントプロセスのフロー図1600を示す。ブロック1602にて示されているように、通知契約者はウェブページにログインするとよい。通知契約者は、ブロック1604にて示されているように、シナリオ監視リストパラメータを作成/変更/削除するとよい。ブロック1608にて示されているように、ウェブページは作成/変更/削除されたシナリオ監視リストを記憶するとよく、ブロック1612にて示されているように、CIMデータウェアハウスがデータタグのリストを作成するとよい。名称翻訳サービスが、ヒストリアンのデータタグを翻訳してブロック1614、データタグを送信するとよいブロック1616。ウェブページは、運用データバスを介してデータタグリストを送信するとよくブロック1610、運用データバスがデータタグリストを受信してブロック1622、それを通知エージェントへ送信するブロック1624。通知エージェントは、リストを読み出してブロック1626、リストを検証および結合しブロック1628、通知シナリオに関してヒストリアンをチェックするブロック1630。シナリオにマッチする例外が発見されるとブロック1632、通知が送信されるブロック1634。イベントバスは通知を受信しブロック1618、それを通知契約者へ送信するブロック1620。ブロック1606にて示されているように、通知契約者は、テキスト、電子メール、電話など、好みの媒体を介して通知を受信するとよい。図17は、計器データ収集AMIプロセスのフロー図1700を示す。電流コレクタは、ブロック1706にて示されているように、住居計器データをリクエストするとよい。1つ以上の住居計器が、リクエストに応答して住居計器データを収集しブロック1702、住居計器データを送信するとよいブロック1704。電流コレクタは、住居計器データを受信しブロック1708、それを運用データバスへ送信するとよいブロック1710。計器データ収集エンジンは、ブロック1722に示されているように、商業および工業用計器データをリクエストするとよい。1つ以上の商業および工業用計器が、リクエストに応答して商業および工業用計器データを収集しブロック1728、商業および工業用計器データを送信するとよいブロック1730。計器データ収集エンジンは、商業および工業用計器データを受信してブロック1724、それを運用データバスへ送信するとよいブロック1726。運用データバスは、住居、商業および工業計器データを受信してブロック1712、データを送信するとよいブロック1714。データは、計器データリポジトリデータベースにより受信されてもブロック1716、または請求プロセッサにより受信されてもよくブロック1718、次に、CRMcustomerrelationshipmanagement:顧客関係管理システムなどの1つ以上のシステムへ送信されるとよいブロック1720。可観測性プロセスはさらに、リモートアセット監視プロセスを含むとよい。電力グリッド内のアセットの監視は、困難なものとなるかもしれない。電力グリッドには種々の部分があると考えられ、その一部は非常に高価である。例えば、変電所は電力変圧器100万ドル以上かかるおよび回路遮断器を含むと考えられる。ユーティリティは、アセットの分析およびアセット使用の最大化の点では、ほとんど何もしないことが多い。代わりに、ユーティリティの焦点は典型的には、需要家への電力が確実に保たれるようにすることであった。具体的には、ユーティリティの焦点は、定期点検典型的には所定の間隔で生じると考えられるまたはイベント駆動型の保守故障がグリッドの一部分で生じた場合に発生すると考えられるに合わせられていた。典型的な定期点検またはイベント駆動型の保守の代わりに、リモートアセット監視プロセスは、状態監視保守に焦点を合わせるとよい。具体的には、電力グリッドの一部または全部を評価できれば定期的または継続的になど、電力グリッドの正常性が改善され得る。上記のように、電力グリッドの様々な部分でデータが生成されて、中央局に伝送されるまたはそれによるアクセスが可能であるとよい。次にデータは、グリッドの正常性を判断するために、中央局によって使用されるとよい。グリッドの正常性の分析とは別に、中央局は利用監視を実行するとよい。典型的には、電力グリッド内の設備は、かなりの安全マージンを用いて動作させられている。この理由の1つは、ユーティリティ企業はもともと保守的であり、エラーの大きなマージンの中で需要家に対し電力を保とうとするということである。このもう1つの理由は、グリッドを監視するユーティリティ企業が、電力グリッド内の一設備が利用されている程度を認識していないこともあるということである。例えば、電力会社が特定のフィーダ回路によって送電している場合、電力会社は、送電された電力がフィーダ回路の限界に近い例えば、フィーダ回路が過熱するかもしれないかどうかを知る手段は有しないと考えられる。これが理由で、ユーティリティ企業は、電力グリッドの1つ以上の部分を十分に活用していない可能性がある。さらに、電力グリッドに対する負荷が増大してきているすなわち消費電力量が増えてきているため、ユーティリティは典型的に、かなりの金額を費やして電力グリッドに容量を追加する。ユーティリティの無知が原因で、ユーティリティは不必要に電力グリッドを改良することになる。例えば、最大容量近くで動作してはいないフィーダ回路が、それにもかかわらず導体を取り替えることすなわちより大きなワイヤがフィーダ回路に取り付けられるによって改良されることも、または追加のフィーダ回路が取り付けられることもある。この費用だけでも相当なものである。リモートアセット監視プロセスは、1グリッドの1つ以上の部分の現在のアセット正常性を分析すること、2グリッドの1つ以上の部分の将来のアセット正常性を分析すること、および3グリッドの1つ以上の部分の利用を分析することなど、電力グリッドの様々な側面を監視するとよい。まず、1つ以上のセンサーが、グリッドの特定部分の現在の正常性を判断するために、測定を行ってリモートアセット監視プロセスへ伝送するとよい。例えば、電力変換に関するセンサーは、変圧器上の溶解ガスを測定することによってその正常性のインジケータを提供するとよい。リモートアセット監視プロセスは次に、分析ツールを使用して、グリッドの特定部分電力変換が正常か正常でないかなどを判断するとよい。グリッドの特定部分が正常でなければ、そのグリッドの特定部分が修理されるとよい。さらに、リモートアセット監視プロセスは、グリッドの各部分の将来のアセット正常性を予測するために、グリッドの各部分から生成されたデータを分析するとよい。電気コンポーネントに対するストレスをもたらすものは複数ある。ストレス要因は、必ずしも一定ではなく、断続的であることもある。センサーは、電力グリッドの特定部分に対するストレスのインジケータを提供するとよい。リモートアセット監視プロセスは、センサーデータにより示されるストレス測定値のログを取るとよく、電力グリッドのその部分の将来の正常性を予測するために、ストレス測定値を分析するとよい。例えば、リモートアセット監視プロセスは、グリッドの特定部分がいつ機能しなくなる可能性があるかを予測するために傾向分析を使用するとよく、グリッドの特定部分が機能しなくなる可能性がある時点より前またはそれと同時に、保守をスケジュールするとよい。このように、リモートアセット監視プロセスは、グリッドの特定部分の寿命を予測し、ひいてはグリッドの当該部分の寿命が短すぎるかどうかすなわち、グリッドの当該部分の消耗が速すぎるかを判断するとよい。さらに、リモートアセット監視プロセスは、電力グリッドをよりよく管理するために、電力グリッドの一部の利用を分析するとよい。例えば、リモートアセット監視プロセスは、フィーダ回路の稼働容量を判断するためにフィーダ回路を分析するとよい。このフィーダ回路の例では、リモートアセット監視プロセスが、フィーダ回路が現在70で動作していると判断してもよい。リモートアセット監視プロセスはさらに、許容範囲の安全マージンをなお保ちながら、特定のフィーダ回路がより高い割合90などで動作できると勧めてもよい。したがって、リモートアセット監視プロセスは、単に利用を分析することによって、容量の効果的な増加を可能にするとよい。特定の技術アーキテクチャを判断する手順INDE参照アーキテクチャの構成要素のうちの1つ、いくつかまたはすべてを使用するとよい特定の技術アーキテクチャを判断するには、様々な手順がある。手順は、複数のステップを含むとよい。第1に、ユーティリティの現状のドキュメンテーションの生成、およびスマートグリッドに移行するための準備評価のために、ベースラインステップが実行されるとよい。第2に、将来の状態、およびこの状態に達するための詳しい要件の定義を生成するために、要件定義ステップが実行されるとよい。第3に、測定、監視および制御を含むスマートグリッドを実現するソリューションアーキテクチャコンポーネントの定義を生成するために、ソリューション開発ステップが実行されるとよい。INDEアーキテクチャの場合、これには、測定デバイス、データをデバイスからINDECORE120アプリケーションへ渡す通信ネットワーク、データを維持しそれに反応するINDECORE120アプリケーション、データを解釈する分析アプリケーション、測定および解釈されたデータをモデル化するデータアーキテクチャ、データおよび情報をINDEおよびユーティリティシステムの間で交換するための統合アーキテクチャ、様々なアプリケーションおよびデータベースを実行する技術インフラストラクチャ、ならびに業界標準の移植可能且つ効率的なソリューションを可能にするために従うとよい標準が含まれ得る。第4に、主要パフォーマンスインジケータの定義、およびスマートグリッドと、システムパフォーマンスを測定して所望のパフォーマンス係数に照らして評価する能力の実装との成功要因の定義を生成するために、価値モデリングが実行されるとよい。上記の開示は、ステップ3のアーキテクチャ開発の側面に関係する。図19A~Bは、ブループリントの進展フロー図の例を示す。具体的には、図19A~Bは、スマートグリッドの要件を定義するために取り組まれるとよいステップ、およびスマートグリッドの実装のために実行されるとよいステップのプロセスフローを示す。スマートグリッド開発プロセスは、スマートグリッド構想開発から始まるとよく、これがプロジェクトの全体的な目的の概要を明らかにし、それがスマートグリッドロードマッププロセスにつながるとよい。ロードマッププロセスは、ブループリントおよび価値モデリングにつながるとよい。ブループリントは、ユーティリティの事業全体を背景として、スマートグリッドの定義に対し系統的手法を提供するとよい。ブループリントは、全体的なロードマップを含むとよく、これがベースラインおよびシステム評価BASE:baselineandsystemsevaluation、ならびに要件定義および解析選択RDAS:requirementsdefinitionandanalyticsselectionにつながるとよい。RDASプロセスは、ユーティリティの特定のスマートグリッドの詳細な定義を作成するとよい。BASEプロセスは、スマートグリッド能力をサポートするシステム、ネットワーク、デバイスおよびアプリケーションの観点からユーティリティの出発点を確立するとよい。プロセスの第1部分は、グリッドのシステムインベントリを開発することであり、これは、グリッド構造発電、送電線、送電変電所、副送電線、配電変電所、配電フィーダ、電圧階級など、グリッドデバイススイッチ、リクローザー、コンデンサ、調整器、電圧降下補償器、フィーダインタータイなど、変電所オートメーションIED、変電所LAN、計測手段、ステーションRTU/コンピュータなど、配電オートメーションコンデンサおよびスイッチの制御、故障隔離および負荷ロールオーバー制御、LTC調整システム、DMS、需要応答管理システムなど、ならびにグリッドセンサーセンサータイプ、量、用途、ならびに配電グリッド上、送電線上および変電所内の総数などなどを含むとよい。インベントリが完成すると、上位スマートグリッド準備モデルに照らしてユーティリティの評価が作成されるとよい。現状のデータフローモデルおよびシステム図も作成されるとよい。アーキテクチャ構成ARC:architectureconfigurationプロセスは、BASEプロセスからの情報、RDASプロセスおよびINDE参照アーキテクチャからの要件および制約を組み合わせて、ユーティリティの特定のニーズに合致し、適切なレガシーシステムを活用し、ユーティリティに存在する制約に従う技術アーキテクチャを作り出すことによって、ユーティリティの初期スマートグリッド技術アーキテクチャを開発するとよい。INDE参照アーキテクチャの使用は、カスタムアーキテクチャを考案する必要を回避するとよく、蓄積された経験およびベストプラクティスが、確実にソリューションの開発に応用されるようにする。さらに、再利用可能なスマートグリッドアセットをソリューションが確実に最大限使用できるようにするとよい。センサーネットワークアーキテクチャ構成SNARC:sensornetworkarchitectureconfigurationプロセスは、スマートグリッドサポートのための分散型センサーネットワークのアーキテクチャを定義する一連の決定を行うためのフレームワークを提供するとよい。フレームワークは、センサーネットワークアーキテクチャの特定の側面にそれぞれが向かう、一連の決定木として構築されるとよい。決定が下されると、センサーネットワークアーキテクチャ図が作成されるとよい。Tセクション再帰によるセンサー配分SATSECTR:sensorallocationviaT-sectionrecursionプロセスは、費用制約に従って、所定レベルの可観測性を得るために配電グリッド上にいくつのセンサーが配置されるべきかを判断するためのフレームワークを提供するとよい。このプロセスはさらに、センサーのタイプおよび位置を決定するとよい。ソリューション構成要素評価およびコンポーネントテンプレートSELECT:solutionelementevaluationandcomponentstemplateプロセスは、ソリューションコンポーネントタイプの評価のためのフレームワークを提供するとよく、各コンポーネントクラスの設計テンプレートを提供する。テンプレートは、ソリューション構成要素それぞれに関する仕様の参照モデルを含むとよい。こうしたテンプレートは、次に、ベンダーの見積もりをリクエストしてベンダー/製品評価をサポートするために使用されるとよい。アプリケーションおよびネットワークの改良計画UPLAN:upgradeplanningforapplicationsandnetworksプロセスは、既存のユーティリティシステム、アプリケーションおよびネットワークの、スマートグリッドソリューションに統合する準備を整えるための改良計画の開発を提供するとよい。リスク評価および管理計画RAMP:riskassessmentandmanagementplanningプロセスは、ARCプロセスにおいて作成されたスマートグリッドソリューションの特定の構成要素に関連するリスクの評価を提供するとよい。UPLANプロセスは、特定されたリスク要素のレベルまたはリスクを評価し、ユーティリティが増築に尽力する前にリスクを軽減するための行動計画を提供するとよい。変化分析および管理計画CHAMP:changeanalysisandmanagementplanningプロセスは、スマートグリッド投資の価値を実現するためにユーティリティに必要と考えられるプロセスおよび組織変更を分析するとよく、こうした変更をスマートグリッドの展開と同期した形で実行するための上位管理計画を提供するとよい。CHAMPプロセスは、ブループリントの生成をもたらすとよい。価値モデリングプロセスにおけるロードマップは、価値メトリクスを特定することにつながるとよく、これが、費用および利益の推定につながるとよい。推定は、レートケースおよびビジネスケースなど1つ以上のケースの構築につながるとよく、これが次にケースクローズにつながるとよい。ブループリントおよび価値モデリングの出力は、承認を受けるためにユーティリティへ送信されるとよく、これが、ユーティリティシステムの改良ならびにスマートグリッドの展開およびリスク削減アクティビティにつながるとよい。この後、グリッドが設計、構築およびテストされ、続いて動作させられるとよい。別のINDE上位アーキテクチャの説明一例では、モバイルおよび固定センサーの両方を含む産業に、全体的なINDEアーキテクチャが適用されてもよい。INDEアーキテクチャは、センサーデータを受信して、それに応じて分散型および集中型両方のインテリジェンスによって応答するよう実装されるとよい。図21~28は、様々な輸送手段運行産業において実装されたINDEアーキテクチャの例を示す。全体的アーキテクチャ図面を参照する。図面では、類似した参照数字は類似した構成要素を指し、図21A~CはINDEの全体的なアーキテクチャの一例を示す。このアーキテクチャは、1つ以上の特定の産業に関係するネットワークデータのエンドツーエンド収集、搬送、記憶および管理を提供する参照モデルとしての機能を果たし得る。さらに、解析および解析管理、ならびに前述のもののプロセスおよびシステムへの統合を提供し得る。したがって、これはエンタープライズ規模のアーキテクチャと見なされるとよい。運用管理およびネットワーク自体の各側面など、特定の要素については、下記でさらに詳しく説明する。図21A~Cに示されているアーキテクチャは、データおよび統合バスを最大4つまで含んでよい:1高速センサーデータバス2146運用および非運用データを含むとよい、2専用イベント処理バス2147イベントデータを含むとよい、3動作サービスバス2130ネットワークバックオフィスアプリケーションについての情報を提供する役割を果たすとよい、ならびに4バックオフィスITシステム用のエンタープライズサービスバスエンタープライズIT2115にサービス提供するエンタープライズ統合環境バス2114として図1A~Cに示されている。個々のデータバスは、1つ以上の方法で実現され得る。例えば、高速センサーデータバス2146およびイベント処理バス2147など、データバスの2つ以上が、単一データバスの別々のセグメントであってもよい。具体的には、バスはセグメント化された構造またはプラットフォームを有してもよい。下記でさらに詳しく説明するように、データバスの別々のセグメント上にデータをルーティングするために、1つ以上のスイッチなどのハードウェアおよび/またはソフトウェアが使用され得る。別の例として、データバスの2つ以上は、データを別々のバス上で搬送するために必要なハードウェアに関して別々の物理的バスなど、別々のバス上にあってもよい。具体的には、バスはそれぞれ、互いに独立したケーブル配線を含んでもよい。さらに、別々のバスのうち、一部または全部が同じタイプであってもよい。例えば、バスの1つ以上が、非シールドより対線を介したイーサネット登録商標およびWi-FiなどのローカルエリアネットワークLANを含んでもよい。下記でさらに詳しく説明するように、種々の物理的バスの中の1つのバス上へデータをルーティングするために、ルータなどのハードウェアおよび/またはソフトウェアが使用され得る。さらに別の例として、バスの2つ以上が、単一バス構造の異なるセグメント上にあってもよく、1つ以上のバスが、別個の物理的バス上にあってもよい。具体的には、高速センサーデータバス2146およびイベント処理バス2147が、単一データバスの異なるセグメントであってもよく、エンタープライズ統合環境バス2114が、物理的に別個のバス上にあってもよい。図21A~Cは、4つのバスを示すが、より少ない、または多い数のバスが、列挙された4タイプのデータを運ぶために使用され得る。例えば、後述するように、センサーデータおよびイベント処理データの伝達に、セグメント化されていない単一バスが使用されてもよいバスの総数は3になる。さらにシステムは、動作サービスバス2130および/またはエンタープライズ統合環境バス2114なしで動作することもできる。IT環境は、SOAに準拠していてもよい。サービス指向アーキテクチャSOAは、サービスとしてパッケージ化されたビジネスプロセスのライフサイクル全体にわたる作成および使用に関する、コンピュータシステムアーキテクチャの様式である。SOAはさらに、種々のアプリケーションがデータを交換してビジネスプロセスに関与することを可能にするようITインフラストラクチャを定義し、供給する。ただし、SOAおよびエンタープライズサービスバスの使用は任意選択である。一般的な産業の例では、図面は、1INDECORE2120および2INDEDEVICE2188など、全体的なアーキテクチャ内の種々の構成要素を示す。全体的なアーキテクチャ内で構成要素をこのように分割しているのは、説明のためである。構成要素のこのほかの分割が使用されてもよい。さらに、構成要素の分割は、種々の産業に関して異なってもよい。INDEアーキテクチャは、インテリジェンスに対する分散型および集中型どちらの手法をサポートするためにも使用されてよく、大型実装の規模に対応するメカニズムを提供するために使用されてもよい。INDE参照アーキテクチャは、実装され得る技術アーキテクチャの一例である。例えば、後述するように、INDE参照アーキテクチャをメタアーキテクチャの例とし、これを、産業ソリューション毎に1つ例えば、別々の産業に別々のソリューション、または産業における適用毎に1つ例えば、第1の輸送手段運行ネットワークに第1のソリューションおよび第2の輸送手段運行ネットワークに第2のソリューション、任意数の具体的技術アーキテクチャを開発するための開始点を提供するために使用することもできる。したがって、特定の産業、または産業内の特定の適用特定のユーティリティへの適用などに対する具体的ソリューションは、INDE参照アーキテクチャ内の構成要素の1つ、いくつかまたはすべてを含むとよい。さらに、INDE参照アーキテクチャは、ソリューション開発の標準化された開始点を提供するとよい。特定の産業または産業内の特定の適用に対する具体的な技術アーキテクチャを判断する手順について後述する。INDE参照アーキテクチャは、エンタープライズ規模のアーキテクチャであるとよい。その目的は、データおよび解析のエンドツーエンド管理と、これらのシステムおよびプロセスへの統合とのためのフレームワークを提供することであるとよい。高度なネットワーク技術は、ビジネスプロセスのあらゆる側面に影響することから、ネットワークレベル、動作および顧客構内レベルの影響のみではなく、バックオフィスおよびエンタープライズレベルの影響にも気を配らなければならない。したがって、INDE参照アーキテクチャは、例えばインターフェースのためにSOA環境をサポートするよう、エンタープライズレベルSOAを参照することができ、実際に参照する。これは、高度なネットワークを構築および使用するには、などの産業がその既存のIT環境をSOAに変更しなければならないと要求するものと見なされてはならない。エンタープライズサービスバスは、IT統合を促進する有益なメカニズムであるが、ソリューションの残りの部分を実装するために必須ではない。以下の説明は、輸送手段運行に関するINDE構成要素の種々のコンポーネントに焦点を合わせるが、INDE構成要素のコンポーネントの1つ、いくつかまたはすべてが、電気通信およびエネルギー探鉱などの種々の産業に適用され得る。INDEコンポーネントグループ上記のように、INDE参照アーキテクチャ内の種々のコンポーネントには、例えば1INDECORE2120および2INDEDEVICE2188が含まれ得る。以下の各セクションは、INDE参照アーキテクチャのこれら例示の構成要素グループについて説明し、各グループのコンポーネントの説明を提供する。INDECORE図22は、図21A~Cに示されているように、INDE参照アーキテクチャのうち、動作制御センターに存在するとよい部分である、INDECORE2120を示す。INDECORE2120は、データを記憶するための統一データアーキテクチャと、そのデータに対して作用する解析の統合スキーマとを含むとよい。さらに、このデータアーキテクチャは、他のタイプのデータ例えばセンサーデータ、運用および過去データ、ログならびにイベントファイルなど、ならびに接続性およびメタデータファイルを、エンタープライズアプリケーションを含む上位アプリケーションによるアクセスのための単一エントリポイントを有するとよい単一データアーキテクチャに関連付けるために、連合ミドルウェア2134を使用するとよい。さらに、リアルタイムシステムが、高速データバスを介して主要データストアにアクセスするとよく、いくつかのデータストアがリアルタイムデータを受信することができる。種々のタイプのデータが、INDEアーキテクチャ内の1つ以上のバス内で搬送されるとよい。搬送されるデータのタイプは、動作および非運用データ、イベント、ネットワーク接続性データならびにネットワーク位置データを含むとよい。運用および非運用データは、運用/非運用データバス2146を使用して搬送されるとよい。データ収集アプリケーションが、データの一部または全部を運用/非運用データバス2146へ送信することを担当するとよい。こうして、情報を得るための登録をすること、またはこのデータを利用可能にできるサービスを呼び出すことにより、この情報を必要とするアプリケーションがデータを得られるとよい。イベントは、後述するように、産業ネットワークの一部である様々なデバイスおよびセンサーから生じるメッセージおよび/またはアラームを含むとよい。イベントは、上のデバイスおよびセンサーから直接生成されてもよく、さらに、こうしたセンサーおよびデバイスからの測定データに基づいて様々な解析アプリケーションにより生成されてもよい。下記でさらに詳しく説明するように、データは、内の様々なコンポーネントから送信され得るINDEDEVICE2188など。データは、無線、有線または両方の組み合わせでINDECORE2120へ送信され得る。データは、ユーティリティ通信ネットワーク2160によって受信されるとよく、ユーティリティ通信ネットワーク2160は、データをルーティングデバイス2189へ送信するとよい。ルーティングデバイス2189は、バスのセグメント上バスがセグメント化されたバス構造を含む場合または独立したバス上へのデータのルーティングを管理するソフトウェアおよび/またはハードウェアを含むとよい。ルーティングデバイスは、1つ以上のスイッチまたはルータを含んでもよい。ルーティングデバイス2189は、ネットワーキングデバイスを含むとよく、そのソフトウェアおよびハードウェアが、バスの1つ以上へ、データをルーティングおよび/または転送する。例えば、ルーティングデバイス2189は、運用および非運用データを、運用/非運用データバス2146へルーティングするとよい。ルーティングデバイス2189はさらに、イベントデータをイベントバス2147へルーティングするとよい。ルーティングデバイス2189は、データをどのようにルーティングするかを、1つ以上の方法に基づき判断するとよい。例えば、ルーティングデバイス2189は、伝送されたデータ内の1つ以上のヘッダを検査して、データを運用/非運用データバス2146のセグメントへルーティングするか、またはイベントバス2147のセグメントへルーティングするかを判断してもよい。具体的には、データ内の1つ以上のヘッダが、データが動作/非運用データであるかその結果ルーティングデバイス2189はデータを運用/非運用データバス2146へルーティングするまたはデータがイベントデータであるかその結果ルーティングデバイス2189はイベントバス2147をルーティングするを示してもよい。あるいは、ルーティングデバイス2189は、データのペイロードを検査して、データのタイプを判断してもよい例えば、ルーティングデバイス2189は、データのフォーマットを検査して、データが運用/非運用データであるか、またはイベントデータであるかを判断してもよい。運用データを記憶する運用データウェアハウス2137などのストアの1つが、真の分散型データベースとして実装されてもよい。ストアのもう1つ、ヒストリアン図21および22において過去データ2136として特定されているが、分散型データベースとして実装されてもよい。さらに、イベントは、複合イベント処理バスを介していくつかのデータストアのいずれかに直接記憶されてもよい。具体的には、イベントは、イベントバス2147へ発行したすべてのイベントのリポジトリとしてもよいイベントログ2135に記憶されてもよい。イベントログは、イベントid、イベントタイプ、イベントソース、イベント優先度およびイベント生成時間のうちの1つ、いくつかまたはすべてを記憶するとよい。イベントバス2147が、イベントを長期記憶してすべてのイベントの維持を提供する必要はない。データの記憶は、できるだけ、または実用的なだけ、データがソースに近くなるようになっているとよい。一実装では、これには例えば、変電所データがINDEDEVICE2188にて記憶されることが含まれてもよい。しかし、このデータは、非常に細かい粒度レベルでネットワークを考慮した各種決定を下すために、動作制御センターレベル2116においても必要とされることもある。データベースリンクおよびデータサービスを適宜使用することによってソリューションのすべてのレベルにおけるデータの利用可能性を促進するよう、分散型データ手法が、分散型インテリジェンス手法とともに採用されるとよい。このように、過去データストア動作制御センターレベル2116にてアクセス可能であるとよいに関するソリューションは、運用データストアのソリューションと類似しているとよい。INDEDEVICEレベルのデータにアクセスすることによって、動作制御センターレベル2116で過去/集合的解析が実行されてもよい。あるいは、データは、INDECORE2120にて中央で記憶されてもよい。しかし、INDEDEVICE2188間で伝送される必要があると考えられるデータの量を考慮すると、INDEDEVICE2188にてデータを記憶する方が好ましいこともある。具体的には、何千または何万ものセンサーがある場合、INDECORE2120へ伝送される必要のあるデータ量により、通信ボトルネックがもたらされることもあり得る。最後に、INDECORE2120は、ネットワーク内のINDEDEVICE2188のうちの1つ、いくつかまたはすべてをプログラムまたは制御するとよい。例えば、INDECORE2120は、プログラミングを変更してもよく更新されたプログラムをダウンロードするなど、またはINDEDEVICE2188の任意の側面を制御する制御コマンドを提供してもよいセンサーまたは解析の制御など。図2に示されていない他の構成要素に、この論理アーキテクチャをサポートする様々な統合構成要素が含まれ得る。表2は、図21に示されたINDECORE2120の特定の構成要素を記載する。表2:INDECORE構成要素表2で説明したように、リアルタイムデータバス2146動作および非運用データを伝達するおよびリアルタイム複合イベント処理バス2147イベント処理データを伝達するは単一バス2346へ。この例が、図23A~Cのブロック図2300に示されている。図21A~Cに示されているように、バスは、パフォーマンスのために別々になっている。CEP処理の場合、非常に大きなメッセージバーストが起こりやすい特定の用途には、低遅延が重要であると考えられる。一方、グリッドデータフローの大部分はほぼ一定であり、デジタル故障レコーダファイルが例外であるが、これらは通常、制御された形で読み出し可能である。それに対し、イベントバーストは非同期且つランダムである。図21はさらに、INDECORE2120とは別の、動作制御センター2116内のさらなる構成要素を示す。具体的には、図21はさらに、計器との通信それらからデータを収集して収集したデータをユーティリティに提供するなどを担当するシステムである、センサーデータ収集ヘッドエンド単数または複数2153を示す。IPネットワークサービス2158は、IP型通信DHCPおよびFTPなどをサポートする1つ以上のサーバ上で動作するサービスの集合である。モバイルデータ送信システム2159は、現場のモバイルデータ端末とメッセージを送受信するシステムである。作業管理システム2150は、作業命令を監視および管理するシステムである。地理情報システム2149は、アセットが地理的にどこに位置し、各アセットがどのように接続されているかについての情報を含むデータベースである。環境がサービス指向アーキテクチャSOAを有する場合、動作SOAサポート2148は、SOA環境をサポートするサービスの集合である。動作制御センター2116内にありINDECore2120外にあるシステムのうちの1つ以上は、ユーティリティが有することもあるレガシー製品システムである。こうしたレガシー製品システムの例には、動作SOAサポート2148、センサーデータ収集ヘッドエンド単数または複数2153、IPネットワークサービス2158およびモバイルデータ送信システム2159が含まれる。なお、こうしたレガシー製品システムは、スマートグリッドから受信されるデータを処理または操作することができなくてもよい。INDECore2120は、スマートグリッドからデータを受信し、スマートグリッドからのデータを処理し、処理したデータを1つ以上のレガシー製品システムへ、レガシー製品システムが使用できる形レガシー製品システムに特有の特定のフォーマッティングなどで転送することができるとよい。このように、INDECore2120はミドルウェアと見なされてもよい。INDECORE2120を含む動作制御センター2116は、エンタープライズIT2115と通信するとよい。一般的に、エンタープライズIT2115における機能性はバックオフィス業務を含む。具体的には、エンタープライズIT2115は、ビジネスデータウェアハウス2104、ビジネスインテリジェンスアプリケーション2105、エンタープライズリソースプラニング2106、様々な財務システム2107、顧客情報システム2108、人材システム2109、アセット管理システム2110、エンタープライズSOAサポート2111、ネットワーク管理システム2112およびエンタープライズメッセージサービス2113を含むエンタープライズIT2115内の様々なシステムへデータを送信するためにエンタープライズ統合環境バス2114を使用するとよい。エンタープライズIT2115はさらに、ファイアウォール2102を介してインターネット2101と通信するためのポータル2103を含むとよい。INDEDEVICEINDEDEVICE2188グループは、特定のデバイスに関連するデータを提供するために使用される任意の種類のデバイスを含み得る。一例では、デバイスグループ2188は、固定センサーユニット2190およびモバイルセンサーユニット2192を含むとよい。固定センサーユニット2190およびモバイルセンサーユニット2192はそれぞれ、センサーからの任意のデータの受信、ならびにその後の処理、および/または生のセンサーデータもしくは処理されたセンサーデータの伝送を可能にする、1つ以上のセンサー、プロセッサ、メモリデバイス、通信モジュールおよび/または電力モジュールを含むとよい。固定センサーユニット2190およびモバイルセンサーユニット2192からの生のセンサーデータまたは処理されたセンサーデータは、1つ以上のゲートウェイ2194によって処理されるとよい。一例では、各ゲートウェイ2194は、データを符号化して動作制御センター2116に伝送することができる1つ以上のデバイスであるとよい。固定センサーユニット2190およびモバイルセンサーユニット2192からの生のセンサーデータまたは処理されたセンサーデータはさらに、データコレクタ2196に提供されるとよい。データコレクタ2196は、1つ以上のプロセッサ、メモリデバイス、通信モジュールおよび電力モジュールを含むとよい。データコレクタ2196は、データを収集、記憶および伝送するよう構成されたメモリデバイスおよびプロセッサであるとよい。データコレクタ2196は、固定センサーユニット2190およびモバイルセンサーユニット2192と通信して、データを収集し、収集されたデータを1つ以上のゲートウェイ2194に伝送するとよい。一例では、固定センサーユニット2190は、モバイルセンサーユニット2192または他の固定センサーユニット2190のうちの1つ以上に関連する条件を検出してもよい。モバイルセンサーユニット2192は、固定センサーユニット2192に関連する条件を検出してもよく、または他のモバイルセンサーユニット2192に関連する他の条件を検出してもよい。動作中、イベントデータが、固定センサーユニット2190およびモバイルセンサーユニット2192によって生成されるとよい。イベントデータは、輸送手段運行ネットワークの異常条件または好ましくない条件を示すとよい。そのようなイベントデータは、固定センサーユニット2190およびモバイルセンサーユニット2192から、ゲートウェイ2194を通して中央局に伝送されるとよい。一例では、イベントデータは、ルーティングデバイス2189によって受信されるとよい。イベントデータは、ルーティングデバイス2189によってイベントバス2147に提供されるとよい。受信されたイベントデータは、適切な応答の生成を可能にするよう、動作制御センター2116によって処理されるとよい。図24A~24Cは、鉄道運行ネットワークとともに動作するINDEアーキテクチャのブロック図である。図24A~24BのINDEシステムは、図25に示されているように、固定センサーユニット2190および鉄道車両2400上に置かれたモバイルセンサーユニット2192からイベントデータを受信するとよい。一例では、固定センサーユニット2190およびモバイルセンサーユニット2192は、参照によって本願明細書に引用したものとする米国特許出願公開第2009/0173840号で開示されているものであってもよい。図25を参照する。一例では、貨物列車2500は、有蓋車、車掌車、石炭車、エンジン車および鉄道によって移送されるよう構成されたその他任意の車両など、様々なタイプの鉄道車両2400を含むとよい。エンジン車2502は、ディーゼルエンジン、バッテリー、フライホイール、燃料電池またはその任意の組み合わせによって電力を供給され得る。各鉄道車両2400は、1つ以上のモバイルセンサーユニット2192を含むとよい。モバイルセンサーユニット2192は、互いに通信し、同じ鉄道車両2400、または鉄道車両2400の同じ列に連結された異なる鉄道車両2400、または車両基地に位置するものなど列から分離された他の鉄道車両2400図示せずのモバイルセンサーユニット2192間の通信を可能にするとよい。各モバイルセンサーユニット2192は、固有のIDを有するとよく、特定の鉄道車両2400はそれぞれ、その特定の鉄道車両2400に関連する各モバイルセンサーユニット2192によって保持される固有のIDを有するとよい。IDは、例えばRFIDを介して提供されてもよい。一例では、固定センサーユニット2190Aは、鉄道車両の車輪、車軸などに関連する温度上昇を監視するよう構成された熱軸箱検出器として機能するよう構成されているとよい。熱軸箱という用語は、当該技術分野で周知のように、1つの鉄道車両の、1つ以上の車軸軸受および/または車輪をベースとする他のコンポーネントにおいて過熱が生じている鉄道車両を指すとよい。固定センサーユニット2190Aは、鉄道線路の軌道2501に沿って配置されるとよい。鉄道車両が特定の固定センサーユニット2190Aの感知ゾーンを通過するときに鉄道車両2400の軸受、車軸、車輪の温度上昇パターンを判断するために、各固定センサーユニット2190Aには1つ以上の赤外線IR:infraredセンサーが備えられているとよい。異常な温度上昇は、鉄道車両の荷重の不均衡、鉄道車両の構造上の問題、軌道の問題などの様々な問題を示すこともある。過熱した軸受が検出されると、一種のアラームがトリガされ、列車を停止して、持続させると列車の脱線を生じ得る潜在的に危険な状況を修正するよう、技術者に警報を出すことが可能である。熱軸箱検出器の例は、参照によって本願明細書に引用したものとする米国特許第4,659,043号において開示されている。固定センサーユニット2190Aは、IRセンサーデータを処理して、その後の処理のためにイベントバス2147によって受信されるように、イベントメッセージなど、アラームに基づくイベントデータを生成するよう構成されているとよい。固定センサーユニット2192Bはさらに、障害検出器としての機能を果たすとよい。障害検出器は、通過する列車における車軸および信号の問題を検出するために鉄道線路上で使用されるデバイスであるとよい。障害検出器は、鉄道軌道へと統合されることが可能であり、生じる可能性がある1つ以上の種類の問題を検出するセンサーを含むとよい。障害検出器によって、鉄道線路は、列車後部の車掌車、ならびに危険条件を発見するよう経路に沿って配備される様々な駅員を省くことができるようになる。障害検出器は、有線または無線の送信機と統合されるか、または関連しているとよい。障害検出器を列車が通過するとき、障害検出器は、鉄道線路名、距離標または位置、軌道番号該当する場合、通過した列車の車軸の数および列車で問題が検出されなかったことを示す指示障害なしを出力してもよい。さらに、その位置の周囲温度および列車速度が出力されてもよい。問題が検出されると、検出器は、アラーム指示、続いて問題の説明、および列車内での、問題が生じた車軸の場所を出力するとよい。固定センサーユニット2190Cはさらに、1つ以上の固定センサーユニット2190Aおよび2190Bによって受信された生のデータまたは処理されたデータを受信するよう構成された、当該技術分野で周知のシルバーボックスsilverboxesとして機能するよう構成されているとよい。固定センサーユニット2192Cは、例えば地理的位置などの様々な共通要素に基づく、固定センサーユニット2190Aの個々のグループからデータを受信するとよい。この関連で、固定知覚ユニット2190Cは、図21A~21Cに示されている、データコレクタ2196として機能するとよい。動作中、鉄道車両2400の列を有する列車2500は、鉄道軌道2502に沿って運行するとよい。列車2500が運行するとき、固定センサーユニット2190Aは、軸受温度など、各鉄道車両2400に関する情報を検出するとよい。各固定センサーユニット2190Aはさらに、各モバイルセンサーユニット2192と通信するとよい。通信によって、各固定センサーユニット2190Aが、各鉄道車両2400および関連するモバイルセンサーユニット2192の正常性チェックを実行できるとよい。特定の鉄道車両2400に関連する異常条件または好ましくない条件の任意の指示が、固定センサーユニット2190Cに中継されるとよい。検出される条件は、鉄道車両の構造、鉄道車両の環境例えば温度、鉄道車両の中身例えば重量、分布、量など、鉄道車両の動き、鉄道車両の場所、またはその他、鉄道車両2400に関する対象となる任意のパラメータに関するとよい。さらに、検出される条件はセキュリティに関係してもよい。例えば、鉄道車両のドアが開いている場合などであり、これは窃盗または破壊行為の試みを示すこともある。イベントデータ2508は、特定の鉄道車両を所有していることもある特定の組織に警報を出すために使用されてもよい。したがって、動作制御センター2116は、鉄道路ネットワーク全体を監視するとよいが、特定の企業によって所有される特定の鉄道車両単数または複数2400に関してイベントデータが伝送されると、個別の鉄道車両2400を所有している企業に対し警報が出されてもよい。警報メッセージは、インターフェース、契約サービス、電子メール、テキストメッセージおよび/またはその他、そうした警報を提供できる任意の通信方式によって提供されるとよい。一例では、エンジン2502など、鉄道車両2400のうちの1つが、現在の鉄道車両の列の鉄道車両2400に関連する各モバイル固定ユニット2192からデータを受信するマスターモバイルセンサーユニット2504としての機能を果たすモバイルセンサーユニット2192を有するとよい。鉄道車両2400が、特定の列車を形成するよう接続されるとき、各モバイルセンサーユニット2192は、マスターモバイルセンサーユニット2504に登録するとよい。マスターモバイルセンサーユニット2504は、モバイルセンサーユニット2192から、生のデータまたは処理されたデータの定期的または連続的なストリームを受信するとよい。これは、使用中、エンジニアが各鉄道車両2400の正常性を判断できるようにする。一例では、各モバイルセンサーユニット2190は、グローバルポジショニングシステムGPSモジュールを含み、個別のモバイルセンサーユニット2192それぞれが、個々の地理的位置を判断することができるとよい。各モバイルセンサーユニット2190は、GPS信号2506を受信して地理的位置を判断するとよい。この情報は、当該情報の伝送が可能な近距離内に特定の鉄道車両があるときに、固定センサーユニット2192Aに中継されるとよい。各モバイルセンサーユニット2192は、自動的に、またはリクエストがあると、地理的位置をマスターモバイルセンサーユニット2504に中継するとよく、これは続いて、車両内ゲートウェイ2194を通して動作制御センター2116に中継されるとよい。一例では、ゲートウェイ2194は、米国特許出願公開第2009/0173840号に記載されているものであってもよい。各モバイルセンサーユニット2192Aはさらに、GPS信号を無線で伝送して、各鉄道車両2400を個別に追跡可能にしてもよい。そのような構成は、列車がトンネル中を移動しているときなど、単一の鉄道車両のみがGPS衛星への確実なアクセスを有する場合に、列車全体が追跡されることを可能にするとよい。固定センサーユニット2190およびモバイルセンサーユニット2192はそれぞれ、センサーデータの少なくとも一部、イベントを生成するとよい。イベントは、異変なしno-incidentイベントまたは異変イベントを含むとよい。異変なしイベントは、レポートする異変がない故障がないなどことを示すとよい。異変イベントは、鉄道運行ネットワークのセクションで生じた、または生じている故障など、異変が生じた、または生じていることを示すとよい。固定センサーユニット2190およびモバイルセンサーユニット2192は、1異変があるかどうかを判断するインテリジェンス、および2異変があるかどうかの判断に基づき1つ以上のアクションを取る能力のうちの一方または両方を含むとよい。具体的には、固定センサーユニット2190およびモバイルセンサーユニット2192のうちの1つ以上のメモリは、1つ以上のセンサーによって生成されたデータに基づき種々のタイプの異変を判断するための1つ以上のルールを含むとよい。または、固定センサーユニット2190およびモバイルセンサーユニット2192のメモリは、1つ以上のセンサーによって生成されたデータに基づき種々のタイプの異変を判断するための1つ以上のルックアップテーブルを含んでもよい。さらに、固定センサーユニット2190およびモバイルセンサーユニット2192は、異変があるかどうかの判断に基づき1つ以上のアクションを取る能力を含んでもよい。鉄道運行ネットワーク内の電子構成要素は、単体で機能するだけでなく、鉄道運行ネットワークの分散型インテリジェンスの一部として協働するとよい。例えば、固定センサーユニット2190およびモバイルセンサーユニット2192は、データを共有するかまたは処理能力を共有し、異変があるかどうかを共同で判断し、異変があるかどうかの判断に基づき1つ以上のアクションを取ってもよい。アクションは、次に限定はされないが、1異変の判断をイベントバス2147上で送信すること、2異変の判断を推奨されるアクションとともにイベントバス2147上で送信すること、および3鉄道運行ネットワークの1つ以上のセクションまたは鉄道運行ネットワーク上を運行している1つ以上の輸送手段の状態を変更するためにアクションを取ることを含む。例えば、固定センサーユニット2190は、鉄道運行ネットワークのセクション内の1つ以上のスイッチを制御してもよい別の鉄道線路へ通行方向を変える、種々の方向への運行のためにレーンを開くなど。または、固定センサーユニット2190は、鉄道運行ネットワークのセクション内の1つ以上のセンサーのパラメータを変更してもよい読み取りの感度を上げるようセンサーに命令する、より頻繁な読み取りを生成するようセンサーに命令するなど。さらに別の例として、固定センサーユニット2190およびモバイルセンサーユニット2192は、鉄道運行ネットワーク上を運行している1つ以上の輸送手段を制御してもよい。例えば、機関車は、リモートコマンド制御能力を含んでもよく、それによって機関車は、無線で伝送されたコマンドを受信して、機関車の1つ以上の側面を制御できてもよい。コマンドが制御する1つ以上の側面は、次に限定はされないが、機関車の速度、警笛または他のタイプの音の生成、および明かりまたは他のタイプの可視指示の生成を含んでもよい。機関車の受信機が、コマンドを受信するとよく、機関車のプロセッサが、コマンドに基づき機関車の1つ以上の側面を制御するとよいエンジンの動作を変更するなど。鉄道運行ネットワークは、分散型インテリジェンスを含むとよい。上記のように、鉄道運行ネットワーク内の種々の固定センサーユニット2190およびモバイルセンサーユニット2192は、追加の処理/分析能力およびデータベースリソースを含む追加の機能性を含んでもよい。鉄道運行ネットワークにおいて、様々な固定センサーユニット2190およびモバイルセンサーユニット2192内でこの追加の機能性を使用することで、アプリケーションおよびネットワークパフォーマンスの集中管理および監督を伴う分散型アーキテクチャが可能になる。機能、パフォーマンスおよび拡張性のために、何千もの固定センサーユニット2190およびモバイルセンサーユニット2192を含む鉄道運行ネットワークが、分散型処理、データ管理およびプロセス通信を含むこともできる。非運用データおよび運用データは、固定センサーユニット2190およびモバイルセンサーユニット2192に関連し近接しているとよい。固定センサーユニット2190およびモバイルセンサーユニット2192は、様々なセクションでの鉄道運行ネットワークの可観測性に関与する、鉄道運行ネットワークのコンポーネントをさらに含んでもよい。固定センサーユニット2190およびモバイルセンサーユニット2192は、運用データ獲得および分散型運用データストアでの記憶、非運用データの獲得およびヒストリアンでの記憶、ならびにリアルタイムサブ秒などでのローカル解析処理という3つの主要機能を提供するとよい。処理は、デジタル信号処理と、イベントストリーム処理を含む検出および分類処理と、処理結果のローカルシステムおよびデバイス、ならびに動作制御センター2116にあるシステムへの伝達とを含むとよい。鉄道運行ネットワーク内の固定センサーユニット2190およびモバイルセンサーユニット2192ならびに他のデバイス間の通信は、有線、無線、または有線と無線との組み合わせとしてもよい。電子構成要素は、動作/非運用データまたはイベントデータなどのデータを、動作制御センター2116へ伝送するとよい。ルーティングデバイスは、伝送されたデータを、運用/非運用データバスまたはイベントバスのうちの1つへルーティングするとよい。1つ以上のタイプのデータが、電子構成要素および動作制御センター2116にて複製され、その結果、動作制御センター2116へのデータ通信ネットワークが有効でなくても電子構成要素が独立して動作できるようにするとよい。この情報接続性がローカルに記憶されていることで、動作制御センター2116への通信リンクが動作不能であっても解析がローカルで実行され得る。同様に、運用データは、動作制御センター2116および電子構成要素にて複製されるとよい。特定の電子構成要素に関連するセンサーおよびデバイスからのデータが収集され、最新の測定値が、電子構成要素にてこのデータストアに記憶されるとよい。運用データストアのデータ構造は同じであるとよく、したがって、データベースリンクを使用して、動作制御センター2116にある運用データストアのインスタンスを介した、電子構成要素に存在するデータへのシームレスアクセスを提供することもできる。これは、データの複製を減らすこと、および時間依存がより大きいデータ解析が、ローカルで、電子構成要素外の通信利用可能性に依存せずに行われるのを可能にすることを含む、いくつかの利点を提供する。動作制御センター2116レベルでのデータ解析は、時間依存がより小さいと考えられ典型的には、動作制御センター2116は、過去データを検査して、反応型というよりも予測型のパターンを識別すると考えられるため、ネットワークの問題があっても対処できると考えられる。最後に、過去データが電子構成要素にてローカルに記憶され、データのコピーが動作制御センター2116にて記憶されてもよい。または、動作制御センター2116にてリポジトリインスタンス上のデータベースリンクが構成され、個別の電子構成要素にあるデータへのアクセスが動作制御センターに提供されてもよい。電子構成要素解析は、電子構成要素において、ローカルデータストアを使用してローカルで実行されるとよい。具体的には、電子構成要素にて追加のインテリジェンスおよび記憶能力を使用することで、電子構成要素は、それ自体を分析して、中央局からの入力なしにそれ自体を修正することができる。あるいは、ローカル電子構成要素インスタンスのデータにデータベースリンクを使用してアクセスすることによって、動作制御センター2116レベルで、過去/集合的解析も実行されてもよい。さらに、様々な解析が、データおよび/またはイベントの分析に使用されてもよい。1つのタイプの解析は、空間的可視化を含んでもよい。空間的可視化能力すなわち視覚空間能力は、2次元および3次元の図表を操作する能力である。空間的可視化は、1つ以上の電子構成要素を使用して実行されてもよく、または中央局によって実行されてもよい。さらに、空間的可視化は、ユーティリティネットワークおよび輸送手段運行ネットワークを含む、様々な産業ネットワークに使用されてもよい。一例では、動作中、イベントデータ2508は、各モバイルセンサーユニット2192によって作り出されるとよい。イベントデータ2508は、マスターモバイルセンサーユニット2504に伝送されるとよい。マスターモバイルセンサーユニット2504は、ゲートウェイ2194を介して、処理のためにイベントデータをゲートウェイから動作制御センター2116へ無線で伝送するとよい。他の例では、各鉄道車両2400は、データを鉄道車両2400のモバイルセンサーユニットから直接伝送可能なように、個々のゲートウェイ2194を含んでもよい。これは、車両基地に格納されている鉄道車両など、鉄道車両2400が、エンジン2502と繋がっていないときに通信を行い、動作制御センター2116によって受信されるべきイベントデータ2508を伝達できるようにする。その他の代わりの例では、各車両基地は、1つ以上の固定センサーユニット2190およびゲートウェイ2194を有し、格納された鉄道車両2400と通信して任意のイベントデータ2508を伝送するとよい。同様の形で、固定センサーユニット2190Aおよび2190Bは、固定センサーへのセンサーデータおよびイベントデータを、当該情報を動作制御センター2116に中継する同様のゲートウェイ単数または複数2194を通して伝送するとよい。上記のように、図24A~4Cのネットワークはさらに、イベントデータ2508が固定センサーユニット2190Aおよび2190Bならびにマスターモバイルセンサーモジュール2504にて処理されるように、分散型分析を可能にしてもよい。そのような処理は、任意の問題が分析されることを可能にし、ソリューションまたは一連のアクションを提供するとよい。そのような問題ソリューションは、送られてもよく、列車2500が許可するよう構成されている任意の能力内で列車2500を自動的に制御するために使用されてもよく、またはそれに応じて列車2500を制御するよう人的オペレーターに警報を出してもよい。ソリューションはさらに、動作制御センター2116に送られて、動作制御センター2116が、問題ソリューションを確認してそれに応じてソリューションを実装するためにリモートでアクションを実行できるようにしてもよい。図26A~26Cは、通勤列車などの電車ネットワークに関するINDEアーキテクチャの実装のブロック図である。電車ネットワークは、電力を供給された架空電線路または第三軌条であるとよい、1つ以上の電車を含むとよい。一例では、電車2600は、1つ以上の車両2602を含むとよい。各車両は、外部ソース例えば第三軌条または架空線路または内部ソース例えばバッテリーまたは燃料電池によって個別に電力を供給されてもよい。各車両は、1つ以上のモバイルセンサーユニット2192を含むとよい。各モバイルセンサーユニット2192は、列車2600の様々な所定のパラメータに関連する様々な条件を検出するとよい。図26A~26Cに示されている例では、電車2600は、第三軌条2604によって電力を供給されているとよい。第三軌条2604は、第三軌条2604を流れる電力を監視するとよい1つ以上の固定センサーモジュール2192に接続されているとよい。固定センサーモジュール2190は、鉄道システムの正常性を判断して、異常な、好ましくない、またはステータスチェックに関係する任意のイベントを、イベントメッセージの形式で伝送するとよい。イベントメッセージは、動作制御センター2116によって受信されるよう、ゲートウェイ2194によって伝送されるとよい。各電気鉄道車両2602は、1つ以上のモバイルセンサーユニット2192を含むとよい。モバイルセンサーユニット2192のうちの1つは、マスターモバイルセンサーユニット2504などのマスターモバイルセンサーユニットとしての機能を果たすとよい。モバイルセンサーユニット2192は、図25A~5Bに関して説明されたのと類似した形で、個々の鉄道車両に関する情報を蓄積するとよい。電車2600のマスターモバイルセンサーユニットは、他のモバイルセンサーユニット2192によって生成されたイベントメッセージを、ゲートウェイ2120を介して中央局に伝送してもよい。図27A~27Cは、トラック輸送産業で使用されるものなど、道路を基盤とした貨物搬送ネットワークに適用されたINDEアーキテクチャの実装のブロック図である。一例では、1つ以上のモバイルセンサーユニット2192が、ディーゼルエンジントラック2704によって牽引されるものなどの貨物コンテナ2700内に含まれるとよい。各モバイルセンサーユニット2192は、図25A~26Cに関して説明されたモバイルセンサーユニット2192と類似しているとよい。各モバイルセンサーユニット2192は、貨物コンテナ2700の様々な条件を検出して、それらを、車両内ゲートウェイ2194を介して動作制御センター2116に中継するとよい。固定センサーユニット2190は、複数の顧客施設に分散され、固定センサーユニット2190およびモバイルセンサーユニット2192間の通信を使用して貨物がチェックされることを可能にしてもよい。モバイルセンサーユニット2192は、貨物追跡、貨物コンテナ環境、窃盗/破壊行為の検出、およびその他、図24A~25に関して記載された任意の適切な用途に使用されてもよい。図28A~28Cは、ガソリン燃料、電気、ハイブリッド燃料、バイオ燃料、またはその他任意の適切な燃料方式による自動車のネットワークに適用された、全体的なINDEアーキテクチャの実装のブロック図である。一例では、輸送手段2800は、輸送手段2800の様々な条件の監視を可能にする1つ以上のモバイルセンサーユニット2192を含むとよい。各輸送手段は、ゲートウェイ2194を含むか、または外部ゲートウェイ2194を通して通信して、イベントデータを直接INDEcore120または他のモバイルセンサーユニット2192に伝達するとよい。説明済みの他の例と同様に、モバイルセンサーユニット2192は、輸送手段に関与する解析を実行するとよい分散型インテリジェンスを含んでもよく、またはINDEcore2120との対話によってそれを行ってもよい。モバイルセンサーユニット2192と通信するために固定センサーユニット2190が使用されてもよく、これにより、固定センサーユニット190と通信する近接したモバイルセンサーユニット2192を有する輸送手段800の評価を行うことができる。固定センサーユニット2190は、イベントデータがINDECORE2120に伝送されることを可能にするゲートウェイ194を含むか、もしくは共有してもよく、またはそれを直接INDECORE120に伝送してもよい。固定センサーユニット2190は、輸送手段2800の条件および/または位置に関連するイベントデータを受信するために、貸自動車企業、自動車販売場または個人所有者によって実装されてもよい。図30は、ブロック図が示すように、リモートでホストされ得るINDEシステム2000の例を示す。ホスティングサイト3000では、特定の産業のINDS契約者をサポートするために、必要に応じネットワークコア2002が設置されるとよい。一例では、契約者3002として、鉄道、トラック輸送および航空会社などの様々な産業の使用を要求してもよい。INDEシステム2000は、モジュール方式であり、より多くの産業タイプの追加、または別の例では新たな契約者の追加が可能であるとよい。電気ユーティリティとは別の関係者が、INDEシステム2000のうちの1つ、いくつかまたはすべてのソフトウェア、ならびにシステムエンドポイント2006およびシステムインフラストラクチャ2008に使用される、INDSホスティングサイトからダウンロードされるアプリケーションを管理およびサポートするとよい。通信を促進するために、契約ユーティリティの動作センターならびにINDSホスティングサイトに到達することができるネットワーク3004例えばMPLSまたはその他のWANなどを介した高帯域低遅延通信サービスが使用されるとよい。本発明は、好適な実施形態に関連して示され記載されてきたが、本発明の基本的特徴から、上記のものに加えて特定の変更および改変が行われてよいということは明らかである。さらに、本発明の実践に利用され得る異なるタイプのコンピュータソフトウェアおよびハードウェアは多数あり、本発明は上述の例に制限されない。本発明は、1つ以上の電子デバイスにより実行される機能、および動作の記号表現を参照して記載された。よって、当然のことながら、そのような機能および動作は、構造化形式でデータを表現する電気信号の、電子デバイスの処理ユニットによる操作を含む。この操作は、データを変換するか、または電子デバイスのメモリシステムの各位置にデータを保ち、これが、当業者には十分理解される形で電子デバイスの動作を再構成、または他の形で変更する。データが保たれるデータ構造は、データのフォーマットにより定義される特定の特性を有するメモリの物理的位置である。本発明は前述の文脈において記載されているが、記載された機能および動作がハードウェアに実装されることも可能であることは当業者には当然であるため、制限的なものとして意図されてはいない。したがって、本発明の有効な範囲内の変形および改変すべてを保護することが出願人の意図である。本発明は、すべての等価物を含め、添付の特許請求の範囲によって定義されるものとする。"