JP2009194892A

JP2009194892A - ノードネットワークのためのフォールトトレランスフレームワーク

Info

Publication number: JP2009194892A
Application number: JP2008264511A
Authority: JP
Inventors: Sa De Souza Luciana Moreira; ルシアーナ・モレイラ・サ・デ・スーザ
Original assignee: SAP SE
Current assignee: SAP SE
Priority date: 2007-10-12
Filing date: 2008-10-10
Publication date: 2009-08-27
Anticipated expiration: 2028-10-10
Also published as: JP4991670B2; US8527622B2; KR20090037843A; EP2048819A1; US20090097397A1

Abstract

【課題】センサネットワークの複数に対して適用可能なフォーマットで、かつ、デバイスおよび/またはセンサネットワークの通信資源を圧倒したり枯渇させたりすることなく、フォールト関連データを収集する。
【解決手段】第1のメッセージハンドラは、第1の通信プロトコルを使用する第1のノードネットワークに関連した第1のネットワーク関連データを受け取る。第2のメッセージハンドラは、第2の通信プロトコルを使用する第2のノードネットワークに関連した第2のネットワーク関連データを受け取る。メッセージトランスポートシステムは、第1および第2のネットワーク関連データの経路指定を共通プロトコルで行う。フォールトマネージャは、共通プロトコルでネットワーク関連データを受け取り、第1および第2のノードネットワークの1つ以上のオペレーションに関連したフォールトを、共通プロトコルのネットワーク関連データに基づいて判断する。
【選択図】図１

Description

本記載は、ノードネットワークにおけるフォールトトレランスに関する。

企業またはその他の組織に様々なサービスを提供するソフトウェアシステムが存在する。このようなソフトウェアシステムは、非集中化の、手動による、誤りが発生する可能性が高いデータ収集に依存し、その一方で、収集したデータを、ビジネスロジックの実行も行われる集中化バックエンドシステムに記憶している。上記その他のソフトウェアシステムをスマートアイテム(スマートデバイスともいう)を使用することにより拡張することが可能である。スマートアイテムとは、ローカルに提供される、または埋め込まれるテクノロジーを追加し、または含めることによって、物理的なアイテム(例えば、商品、ツール、部屋、乗り物、人、または棚)を改良または強化するテクノロジーである。

例えば、無線周波数識別(RFID)システム、埋め込みシステム、センサモート、および/またはセンサネットワークを上記のやり方で使用して、現実のデータに高速でアクセスするビジネスソフトウェアアプリケーションを提供することができる。例えば、スマートアイテムテクノロジーを使って、RFIDタグの検出、読み取り、書き込みをサポートするとともに、無線センサネットワークおよび埋め込みシステムとの通信およびそれらの制御をサポートすることができる。多くの場合、スマートアイテムは、ローカル処理能力、メモリ、および/または通信能力を備えたデバイスであって、そのデバイスおよびプロパティに関するデータ、またはスマートアイテムデバイスの現在の状態または環境についての情報を提供することが可能なデバイスを含むことができ、あるいはそれらと関連付けることができる。したがって、バックエンドまたは基礎となるビジネスアプリケーションのサービスコンポーネントを実行するにあたり、このようなデバイスのいくつかを利用することができる。特に、例えば、ビジネスデータの収集、処理、または送信を行うためにモバイルアドホックネットワークを形成するなどによって、協同的なやり方で利用することができる。

スマートアイテムの例として、RFIDタグを挙げることができる。RFIDタグは、パッシブ型またはアクティブ型が可能であり、また、上述のように、物理的対象に付けて、製品を提供したりその対象に関連する情報を処理するのに利用することができる。スマートアイテムのその他の例としては、例えば、環境センサ(例えば、温度、湿度、または振動センサ)など、様々なセンサを挙げることができる。それらは、上述したように、通信を行って1つ以上のセンサネットワークを形成することが可能である。上記その他のタイプのスマートアイテムには、埋め込みシステムも含まれ得る。埋め込みシステムとは、一般に、専用プロセッサおよび/またはプログラムが含まれ、かつ/または制御されているデバイスに封入された、任意のシステムを指すことができる。

自動リアルタイムオブジェクト追跡、およびアプリケーションロジック(例えば、ビジネスロジック)のローカルな現場での実行を通して、スマートアイテムテクノロジーは、正確かつタイムリーなデータを提供することができ、また、関連オペレーションを合理化し自動化するのに役立つことができる。したがって、コスト削減やさらなるビジネス上の恩恵(例えば、資産のさらなる可視化、反応性の改良、およびビジネスチャンス拡大)を得ることができる。

実際には、スマートアイテムおよび関連テクノロジーには、多くの様々なタイプの欠陥やフォールトが伴いやすく、それによって、所望の挙動が損なわれたり、変えられたり、妨げられたりすることがある。このようなフォールトは、例えば、ノードがハードウェアまたはソフトウェアの障害を経験するなど、個々のノード自体のオペレーションにおける機能不全に関連することがある。フォールトはまた、ノードに悪影響を及ぼす可能性がある火事や洪水などの外部の力に関連することがある。フォールトはまた、例えば、ノード間のメッセージの経路指定などの間に、ネットワーク層において生じることもある。最後の例として、バックエンドアプリケーションが誤ったやり方でノードネットワークにデータを要求する場合など、バックエンドアプリケーションがノードネットワークから恩恵を得ようとすることに関連してフォールトが生じる場合もある。

このようなフォールトは、多くの理由により問題がある。例えば、必要なデータをノードから得ることができなかった場合、それによって、別のノードまたはバックエンドアプリケーションの機能不全が引き起こされることがある。フォールトが特定のノードのローカルなオペレーションを妨げなかったとしても、バックエンドアプリケーションに誤ったデータが報告されたならば、問題が生じることがある。さらに、ノードネットワークおよび関連するデータ収集/処理デバイス内で潜在的なフォールトが発生しているかどうかを判断することが難しいことがある。その結果、そのようなフォールトの検出、判断、修正ができなかったことにより、不要なはずのコスト、負債、またはその他の困難という結果に終わることがある。

このようなフォールトに関して、上述のように、ノードが互いに通信してローカルネットワーク、例えば、センサネットワークを形成できることを理解されよう。特定のセンサネットワークにおいて、このような通信は、各ネットワークノードによって理解されているが、その他のノードおよび/またはネットワークによっては理解されていないことがあるプロプライエタリ通信プロトコルを使って行うことができる。例えば、センサネットワークの通信プロトコルが、そのセンサネットワークで使用されている特定のハードウェアおよび/またはソフトウェアプラットフォーム独自のものであったり、あるいは、ノードの製造元独自のものであることがある。したがって、このようなセンサネットワークの複数に対して適用可能なフォーマットで、かつ、デバイスおよび/またはセンサネットワークの通信資源を圧倒したり枯渇させたりすることなく、このようなセンサネットワークに関してフォールト関連データをタイムリーなやり方で収集する(そして、それに対応する)ことは難しいことがある。

一般的な一態様では、第1のメッセージハンドラを、第1の通信プロトコルを使用する第1のノードネットワークに関連した、第1のネットワーク関連データを受け取るように構成することができる。第2のメッセージハンドラを、第2の通信プロトコルを使用する第2のノードネットワークに関連した、第2のネットワーク関連データを受け取るように構成することができる。メッセージトランスポートシステムを、第1のネットワーク関連データおよび第2のネットワーク関連データを受け取るように構成することができ、さらに、第1のネットワーク関連データおよび第2のネットワーク関連データを共通のプロトコルで経路指定するように構成することができる。また、フォールトマネージャを、その共通プロトコルでそれらのネットワーク関連データを受け取るように構成することができ、また、その共通プロトコルのネットワーク関連データに基づいて、第1のノードネットワークおよび第2のノードネットワークの1つまたは複数のオペレーションに関連したフォールトを判断するように構成することができる。

別の一般的な態様によれば、システムは、複数のノードネットワークと通信するように構成され、また、少なくとも1つのバックエンドアプリケーションと通信するように構成されたミドルウェア層を含むことが可能である。ミドルウェア層は、複数のノードネットワークから第1のネットワーク関連データおよび第2のネットワーク関連データを、それぞれ、第1の通信プロトコルおよび第2の通信プロトコルで受け取るように構成され、また、その第1のネットワーク関連データおよび第2のネットワーク関連データを共通プロトコルで提供するように構成されたプラットフォーム抽象化層と、その第1のネットワーク関連データおよび第2のネットワーク関連データをその共通プロトコルで受け取るように構成され、また、それらに基づいて、その複数のネットワークのオペレーションに関連したフォールトを判断するように構成されたフォールト管理層とを含むことが可能である。

別の一般的な態様によれば、方法が、複数のメッセージハンドラの1つにおいて、複数のノードネットワークに関連したネットワーク関連データを受け取る段階であって、前記複数のメッセージハンドラが、それぞれ、対応ノードネットワーク、および該対応ノードネットワークによって使用されている対応通信プロトコルに関連付けられている段階と、前記ネットワーク関連データを、前記対応通信プロトコルから共通通信プロトコルに翻訳する段階と、前記ネットワーク関連データを、前記共通通信プロトコルで、前記複数のノードネットワークに関連する状態情報を記述する状態モデルに提供する段階と、前記複数のノードネットワークのオペレーションに関連したフォールトを、前記状態モデルに基づいて診断する段階と、前記ノードネットワークのノードに、前記ノードによって使用されている前記対応通信プロトコルを使ってサービスを配備することによって、前記フォールトから回復させる段階と、を含む。

1つ以上の実装の詳細を、添付の図面および以下の記載において説明する。その他の特徴は、それらの記載と図面、および特許請求の範囲から明らかになろう。

図1は、ノードネットワークにおけるフォールトトレランスのためのシステム100のブロック図である。図1の例では、このようなノードネットワークにおけるフォールトを、すでにそのネットワーク内に送信されているデータ以外の追加データを必要とすることなく、また、ネットワーク内でのフォールト検出/診断を必要とすることなく、また、フォールトを明らかにし、あるいは軽減するための過度な量のノードの冗長性/複製を必要とすることなく、検出し、診断し、隔離し、修正することができる。さらに、ノードネットワークに関連付けることができるデバイス、ミドルウェア、ネットワーク、またはバックエンドアプリケーションで生じたかどうかとは無関係に、このようなフォールトを判断することができ、場合によっては修正することができる。いくつかの例示的実装においては、システム100は、少なくともソフトウェア関連のフォールトについては、システム100のマッピング機能を使って修正することができる。システム100のマッピング機能は、それによって、判断されたフォールトについて補正または修正を行うような方法で、サービス(例えば、実行可能コード)がノードネットワーク内において配備されるというものである。

さらに、ノードネットワークがそれぞれ異なる通信プロトコルを使っている場合でも、フォールトを判断することができ、場合によっては修正することができる。例えば、下記のように、システム100を使って、ネットワークプラットフォームの様々な異なるインスタンス、および互換性がないはずのネットワークプラットフォームのインスタンスに、フォールトトレランスを提供することができる。すなわち、例えば、複数の異なるネットワークのノードが、別個の異なる、かつ/またはプロプライエタリの通信プロトコルを使ってそれぞれのネットワーク内において互いに通信している場合であっても、システム100を、それらの複数の異なるネットワークにフォールトトレランスを提供するように構成することができる。

図1の例では、ネットワークは、センサネットワーク102および/または104を含む、あるいは指すことができる。この場合、センサネットワーク102および104は、異なる通信プロトコルを実装することができる。図1の例では、センサネットワーク102は、様々なスマートアイテムまたはスマートデバイス106、108、110を含み、一方、センサネットワーク104は、スマートアイテム112、114、116を含む。この状況では、「スマートアイテム」、「スマートデバイス」、「スマートアイテムデバイス」という用語、および同様の用語を様々な状況で、同様に、または交換可能に使用することが可能であることを理解されたい。例えば、「スマートアイテム」または「スマートデバイス」という用語は、ここで述べるように、ローカルな処理、記憶、および通信能力を有するデバイスを指すことができ、あるいは、そのようなデバイスとそのデバイスが付けられる物体の組み合わせ(例えば、販売用の商品を含むパレット)を指すことができる。

センサネットワーク102、104(および、図1には図示していないが、その他の/同様なネットワーク)の一部として、そのようなデバイス、および/または、デバイス/物体の組み合わせを、状況によっては「ノード」または「ネットワークノード」とも呼ぶことがある。本記載においては、「デバイス」という用語を、センサネットワーク102、104内において、説明した機能を有する、説明したデバイスを指すのに使っていることがある。しかし、ノードネットワークのためのフォールトトレランスに関してここで記載する概念は、実質的には、任意のこのような設定に関連することができることを理解されたい。それらの概念および技術は、例えば、ネットワークには、利用可能なエネルギー、メモリ、コンピュータ計算力、および帯域に関してノードが制約されている無線ネットワークを含めることができる、という、ここで説明している状況と同様の状況において特に役立つことがある。

このように、デバイス106〜116、および場合によってセンサネットワーク102、104内のその他のデバイス(およびその他のセンサネットワーク)は、タイムリーかつ正確なやり方で、1つ以上のビジネスデータ処理システム、アプリケーション、またはプロセスに現実のデータを提供することができる。例えば、図1の上部近くに示すように、システム100は、ビジネスアプリケーション118を含み、またはビジネスアプリケーション118と通信を行う。ビジネスアプリケーション118の例としては、例えば、在庫管理システム、供給チェーン管理システム、小売店管理システム、倉庫管理システム、製品ライフサイクル管理システム、および現実の対象に関してビジネスプロセスを実行するために使用することができるその他のシステムが挙げられる。現実の対象には、例えば、販売製品、パレット、またはその他の出荷要素、患者、または製造原料/機器が含まれ得る。このように、ビジネスプロセスを、ビジネスプロセスの、現実の対象のローカルレベルで配備され実行される部分を含めて、例えば、在庫レベルを判断し、価格付けレベルを設定し、マーケティング戦略を評価し、製造または生産テクノロジーを評価し、盗難を減らし、または安全を維持するために使用することができる。

図1では、デバイス110を中央処理装置(CPU)120、メモリ122を含むものとして示している。したがって、デバイス110を、例えば、感知したデータの処理または送信(デバイス110がセンサを含む場合、またはセンサに関連付けられている場合)を含め、様々なレベルのコンピューティング機能が可能なものとして理解すべきである。明快かつ簡略にするため図1には特に示していないが、デバイス106〜116は全て、同じ、追加、または選択コンピューティング能力を含むことができることを理解されたい。これには、例えば、図示のように、センサネットワーク102、104を形成し、それに参加するための通信機能が含まれ、これには、例えば、無線ネットワーク、および/またはピアツーピアネットワークが含まれ得る。すなわち、デバイス106〜116は、簡潔にするために図1には特に示していないが、例えば、(例えば無線)トランシーバやローカル電源/バッテリなど、その他の標準的な要素および特徴を含み得ることを理解されたい。

このように、センサネットワーク102、104を使って、関連ビジネスプロセスに役立ち得るデータを収集し、処理し、フィルタをかけ、集め、または送信することができる。より具体的には、センサネットワーク102、104を使って、ローカルな実行に最も適した(または、ローカルな実行から最も多くの恩恵を得る)、ビジネスプロセスの一部(例えば、ビジネスロジック)を実行することができる。具体的には、図1の例では、センサネットワーク102、104上に配備されたビジネスプロセス/ビジネスロジックの一部は、デバイス110上に配備されるサービス124を含み得る。

一般に、サービス124、およびここで論じているその他のサービスとは、定義済みの機能をサポートし、そのサービスを呼び出す通り道となる定義されたインタフェースを提供することができ、また、追加された、またはより多くの複雑な機能を取得/提供するために互いに結合され得るソフトウェアコンポーネント全般を指す。例えば、サービス124は、例えば、デバイス106、108、110のうちの2つ以上の間の協同を可能にする実現サービスを表すことがあり、あるいは、例えば、デバイス110の電力消費を管理する管理サービスを表すことがあり、あるいは、例えば、ビジネス特有のロジック(局所温度の判断、局所温度が定義済みの値を超えたかどうかの判断、および局所温度が定義済みの値を超えたことに対して何らかのアクションをとるべきかどうかの判断など)を実行する実際のビジネスサービスを表すことがある。

より具体的には、サービス124は、サービス貯蔵所126に記憶されたサービス(またはサービステンプレート)のインスタンスを表すことができる。このように、サービス貯蔵所126は、センサネットワーク102(および/またはセンサネットワーク104)内で使用するために配備することができるサービスを登録し、記憶し、またそのサービスにアクセスするための便利な場所を提供することができる。

サービス貯蔵所126には、サービス実行ファイル128およびサービスメタデータ130が記憶されている。サービス実行ファイル128は、例えば、関連したビジネスロジックを実際に実行するためにデバイス106、108、110(および/またはデバイス112〜116)上にインスタンスを作成することができるソフトウェアコードを表す。一方、サービスメタデータ130は、例えば、センサネットワーク102(および/またはセンサネットワーク104)の1つ以上のデバイス上でサービスを実行できるかどうか、またそのサービスをどのように実行できるかに関連する、様々なサービスの説明および/または要件を表し、または含み得る。

例えば、サービスメタデータ130には、サービスの挙動の説明、またはそのサービスの技術的な制約が含まれ得る。例えば、技術的な制約には、要求されたCPUのタイプまたは速度、必要とされる(空き)メモリの量、要求される、または好ましい接続のタイプまたは速度、オペレーティングシステムのバージョン/名称/説明、あるいはバッテリまたはその他のデバイス電源のタイプまたは状態が含まれ得る。サービスメタデータ130に関しては、ハードウェア要件など、静的サービス要件と動的サービス要件が区別される。例えば、利用可能なメモリ/処理/電力、および/またはサービスの実行時にそのサービスと一緒に共にデバイス上で同時に走らせることができるその他のサービスの数またはタイプなどの動的値とともに、総メモリまたは最大処理速度などの静的値が含まれ得る。

システム100は、サービスマッパ132を含む。サービスマッパ132は、例えば、サービス124の配備によって軽減または解決することができる特定のフォールトが判断されたことに応じて、図示のように、デバイス上でサービス124を配備するために、例えば、センサネットワーク102の複数のデバイス106、108、110から、選定されたデバイスとして少なくとも110を選択するように動作可能である。

次いで、サービスインジェクタ134を使って、サービス実行ファイル128などのサービス実行ファイルを、この場合はデバイス110上に配備することができる。これによって、例えばサービス124などのサービス(またはサービスインスタンス)が作成される。サービスマッパ132によって適切なサービスマッピングが行われると、サービスインジェクタ134を使って、マップされたサービス(例えば、サービス116)をデバイス110にインストールし、開始/起動することができる。サービスインジェクタ134は、より一般には、例えば、必要に応じてサービスを更新したりサービスを停止したりすることによって、サービスのライフサイクルを管理するために使用することもできる。

サービスをサービス貯蔵所126からデバイス106〜116の1つ以上の上にマッッピングすべきかどうか、またどのようにすべきかを決定する際に、サービスマッパ132は、フォールトマネージャ136と通信することができる。ここで説明するように、フォールトマネージャ136を、高レベルの拡張性および透明性をもって、システム100内の障害またはその他のフォールトに対する構造化管理を行うように構成することができる。図1では、スケーラブルかつ集中型のフォールトトレランスを提供するために、フォールトマネージャ136をネットワーク102、104から離れた位置にあるものとして示しているが、追加または代替実施形態においては、図示のように、ローカルフォールトマネージャ137を、デバイス110上など、ネットワーク102、104のデバイス上に配備できることを理解されたい。

フォールトマネージャ136は、システム100内のフォールトを検出し、判断するように構成することができるフォールト診断マネージャ138を含むことができる。ここで説明するように、このようなフォールトは、例えば、ネットワーク102、104の(デバイスの)1つの中で発生することがある。または、ネットワーク102、104内での、および/またはネットワーク102、104からビジネスアプリケーション118へのメッセージの経路指定の間に発生することがある。または、システム100内のどこか他の箇所で発生することがある。例えば、ここでより詳細に説明するように、フォールト診断マネージャ138が、潜在的な障害の発生の時間、ネットワーク102、104のデバイスに関連するハードウェア情報、ネットワーク102、104のデバイスから受け取ったセンサの読み取り示度、またはその他の潜在的にフォールトに関連する情報を分析することができる。

フォールト回復マネージャ139を、フォールト診断マネージャ138によって検出されたフォールトの軽減、解決、または回復を行うように構成することができる。例えば、デバイス110でフォールトが発生したとフォールト診断マネージャ138が診断した場合(例えば、火事またはその他の外的な要因によってデバイス110が破壊された場合)、サービス124または同様のサービスを配備または再配備しながら、フォールト回復がネットワーク102の別のデバイスに進むことができる(例えば、サービスマッパ132および関連機能を使って)。このように、例えば、ネットワーク102の利用可能性および信頼性を、全体として高めることができる。

フォールトマネージャ136を、例えば、いくつかのノード/デバイスネットワーク(図1にはセンサネットワーク102、104として示すが、その他の数またはその他のタイプのネットワークを含むことも可能である)を連続的に走らせ、監視するサーバコンポーネントとして実装することができる。それらのネットワーク上では、デバイス同士が互いに無線で通信することが可能である。それを行うに当たって、フォールトマネージャ136は、例えば、フォールトの出現によってゆがめられなかった情報に対してビジネスアプリケーション118が確実に動作するように、ビジネスアプリケーション118と通信することができる。または、ビジネスアプリケーション118と通信して、そのフォールトがそこで発生した可能性があるかどうかを判断することができる。

図1の例では、フォールトマネージャ136がセンサネットワーク102、104からメッセージを受け取り、状態モデル140を構築し、それを維持する。状態モデル140とは、例えば、システム100内のイベント/メッセージの記載および関連状態情報などである。状態モデル140内に記憶されているこれらのイベント/メッセージを、デバイスマネージャ141に関連した情報によって補い、または強化することができる。デバイスマネージャ141は、ネットワーク102、104のデバイスに関連した、ハードウェアまたはその他のデバイスの特性に関する情報を記憶している。状態モデル140および/またはデバイスマネージャ141は、例えば、ある特定のオントロジーおよび/またはスキーマを使ったデータ構造を含むことができ、またはそのようなデータ構造と通信することができる。例えば、デバイスマネージャ141は、例えば、定義済みのXMLスキーマによる、拡張マークアップ言語(XML)ベースの言語で提供される、デバイス106〜116の様々な技術的能力の記載を構成または提供することができる。もちろん、その他のフォーマット、言語、構造、および/またはプロトコルも使用することができる。

より一般には、デバイスマネージャ141によって記憶されるデータには、例えば、ネットワーク102、104中の各デバイスの番号および/または識別子、デバイスのバッテリ残量、最近読み込まれたセンサ値、通信チャネル上の現在の誤り率、各デバイスに現在インストールされているサービスのリスト、または特定のデバイスに以前記憶されたデータが含まれ得る。さらなる例として、デバイスマネージャ141および/または状態モデル140は、デバイスの説明、ソフトウェアの説明、ハードウェアの説明、またはデバイス状態も含み得る。例えば、デバイスの説明は、デバイス名、識別子、または型を含むことができ、あるいは、ベンダ名またはベンダのウェブサイトを含むベンダ情報を含み得る。ソフトウェアの説明は、バージョンおよび/またはベンダを含むオペレーティングシステムの説明を含み得る。あるいは、デバイスプラットフォーム上で走る、または走ることが許可されているサービスの説明を含み得る。ハードウェアの説明は、CPU120(例えば、名称または速度)、メモリ122(例えば、型およびメモリの総量)、またはデバイスの接続能力(例えば、接続速度または接続タイプ)の属性情報に関する情報を含み得る。デバイス状態は、デバイスのロケーション、現在のCPU利用率、またはメモリ残量を含む、より揮発性の高い情報を含み得る。デバイスが、一定期間の後、フォールトマネージャ136との通信、またはフォールトマネージャ136への報告ができなかった場合、そのデバイスのデバイス状態を切断に変更することができる。明らかにわかるように、その他のデバイスまたはサービスの情報は、デバイスマネージャ141および/または状態モデル140に含めることができ、あるいは、デバイスマネージャ141および/または状態モデル140によってアクセス可能である。このような情報は全て、用語、デバイスメタデータ、デバイス特性、および/またはデバイス能力と呼ぶことができ、あるいは用語、デバイスメタデータ、デバイス特性、および/またはデバイス能力を含み得る。

上述のように、状態モデル140は、イベントに関する情報(例えば、デバイス110からのセンサの読み取り示度)、またはその他のメッセージ(例えば、デバイス110の利用可能性またはその他のデバイス106、108の利用性に関する、デバイス110からのメッセージ)を記憶することができる。状態モデル140はまた、ネットワークメタデータを表すこと、または含むこともできる。ネットワークメタデータは、例えば、様々なネットワークパラメータを含み得る。その場合、特に、そのようなパラメータは動的であって、必ずしも任意の単一デバイスについての情報からは見分けられない。このようなネットワークメタデータの一例として、センサネットワーク102(または104)の利用可能な帯域幅を挙げることができる。その他の例として、ロケーション情報、ネットワークの全体としての移動性特性、およびネットワーク接続の信頼性を挙げることができる。

図1の例では、状態モデル140をフォールトマネージャ136のコンポーネントとして示し、デバイスマネージャ141を別個のものとして示している。しかし、この例は例示のためにすぎず、デバイスマネージャ141をフォールトマネージャ136のコンポーネントとして実装することができ、あるいは、逆に、状態モデル140をフォールトマネージャ136とは無関係に構築することもできることを理解されよう(ただし、その場合、フォールトマネージャ136と通信して、フォールトマネージャ136が望む情報を提供する)。

上記のように、フォールトマネージャ136を、サーバコンポーネントとして実装することができる。このサーバコンポーネントは、標準の発見可能なインタフェース142を、例えば、ビジネスアプリケーション118および/またはサービスマッパ132にわかるようにすることができる。例えば、図1に示すように、ビジネスアプリケーション118は、実際には、上述のものやその他のものなど、多くの様々なビジネスアプリケーションを含み得る。

したがって、例えば、インタフェース142をウェブサービス(および関連ウェブサービスインタフェース)として実装することができる。すなわち、ウェブサービスは、一般に、ウェブサービスと、この場合、ビジネスアプリケーション118との間の相互作用を管理し定義する定義済みインタフェースにしたがって、機能およびデータを提供するソフトウェアアプリケーションを指す。このようなウェブサービスを、ビジネスアプリケーション118が、サービスディレクトリを通して発見することができる。サービスディレクトリとは、例えば、ユニバーサルディスクリプション、ディスカバリ&インテグレーション(UDDI)ディレクトリがある。これは、当事者がネットワーク上の特定のサービス/機能を見つけられるように設計された配布ディレクトリまたはレジストリである。UDDIは、ウェブサービス記述言語(WSDL)として知られる言語を使用している。これは、ビジネスアプリケーション118にそれらの機能をうまく利用するよう要求できるような方法で、ウェブサービスの機能を記述するために設計された、XMLフォーマットの言語である。このようなウェブサービスへの/からのメッセージは、シンプルオブジェクトアクセスプロトコル(SOAP)エンベロープで包み、ハイパーテキスト転送プロトコル(HTTP)を使って送ることができる。もちろん、例えば、共通オブジェクトリクエストブローカアーキテクチャ(CORBA)、および/または、アプリケーション間通信および/またはサービス指向通信のための、その他のアプリケーションプログラムインタフェース(API)を定義または実装するための技術など、その他のタイプのインタフェースを使用することができる。

上述のように、図1では、センサネットワーク102、104は、それぞれデバイス106〜110、112〜116がそれぞれのネットワーク内で互いに通信するために使用する、それぞれ異なる通信プロトコルを実装することができる。例えば、センサネットワーク102、104は、例えば、ConCom(AwareCon)、Zigbee、データ収集プロトコル(DCP)、ユニバーサルプラグアンドプレイ(UPnP)、および/または様々なその他のプロトコルなど、1つ以上の通信プロトコルを使用することができる。さらに、例えば、センサネットワーク102は、特定のプラットフォーム、例えば、Java(登録商標)プラットフォーム(例えば、Java(登録商標)2 Micro Edition (J2ME))という状況において、サービスを実装することができる。したがって、センサネットワーク102の通信プロトコルは、プラットフォームに依存することがあり、例えば、C/C++ベースのプラットフォームであり得るセンサネットワーク104のプラットフォームと(完全には)相互運用可能ではないことがある。

状態モデル140を現在の最新フォームで維持するために、フォールトマネージャ136は、例えば、デバイス106〜110から発生する状態情報(例えば、イベント/メッセージ)を使うことがある。上述のように、例えば、フォールトマネージャ136が、センサネットワーク102の通信プロトコルを理解できないために、デバイス106〜110のうちのいずれかと直接、通信できない場合がある。したがって、プロトコルの翻訳を、例えば、ここで説明するように、実装することができる。

例えば、メッセージブリッジ143を使って、センサネットワーク102へ/からメッセージを、そのプロプライエタリのプラットフォームに依存するフォーマットで送信および受信できるようにすることが可能である。以下に、メッセージブリッジ143のオペレーションについてより詳細に説明する。しかし、一般的に言えば、メッセージを、センサネットワーク102のプロプライエタリのプラットフォーム依存プロトコルで、ネイティブメッセージハンドラ144と共用される標準インタフェースおよび/または接続と互換性のあるフォーマットにカプセル化するように、メッセージブリッジ143を構成することができる。例えば、メッセージブリッジ143およびネイティブメッセージハンドラ144はイーサネット(登録商標)またはシリアル接続を共用することができる。

メッセージブリッジ143を、センサネットワーク102に物理的に近い場所(例えば、送信範囲内および/またはデバイス106〜110の定義された距離内)に、1つのハードウェア(例えば、基地局)として実装することができる。例えば、メッセージブリッジ143を、シリアルポートを使って、または標準無線接続(例えば、無線ローカルエリアネットワーク(WLAN))を使って、パーソナルコンピュータ(PC)に付けることができ、そのPCを使って、例えば有線LANを介して、ネイティブメッセージハンドラ144にメッセージを同報通信することができる。

ネイティブメッセージハンドラ144を、例えば、コンピュータ145などのパーソナルコンピュータ(PC)上に実装することができる。図1では、コンピュータ145を、ビジネスアプリケーション118による、センサネットワーク102、104間の通信、センサネットワーク102、104の監視、センサネットワーク102、104の使用を容易にするための、ミドルウェアシステムのほぼ全体を走らせるものとして示している。もちろん、このような例は単に概念化または例示にすぎず、コンピュータ145の要素のいくつかまたは全てを異なるコンピュータ上で実行することができ、異なるコンピュータには、サーバコンピュータ、ワークステーション、デスクトップコンピュータ、ラップトップコンピュータ、パーソナルディジタルアシスタント(PDA)、または携帯電話が含まれ得ることを理解されたい。例えば、今述べたように、メッセージブリッジ143は、カプセル化したパケットをセンサネットワーク102からネイティブメッセージハンドラ144に転送することができる。また、メッセージブリッジ143は、コンピュータ145自体の上で走ることができ、または、コンピュータ145と通信して、その上で走っているネイティブメッセージハンドラ144とメッセージを交換することができる。

一方、センサネットワーク104をサービスゲートウェイ146に関連付けることができる。サービスゲートウェイ146を、デバイス112〜116それぞれ、および/またはデバイス112〜116それぞれの上で走っている各サービスにプロキシを提供するように構成することができる。サービスゲートウェイ146を、デバイス112〜116に関連したネットワーク関連データを提供するためにこのような各プロキシを提供するよう構成することができる。したがって、例えば、サービスゲートウェイ146のプロキシからネットワーク関連データを判断することにより(ネイティブメッセージハンドラ144およびメッセージブリッジ142が行うように、デバイス112〜116およびそれぞれのサービス自体に照会するのではなく)、標準フォームのそのネットワーク関連データをフォールトマネージャ136に提供するよう、ゲートウェイメッセージハンドラ148を容易に構成することができる。

ネイティブメッセージハンドラ144およびメッセージブリッジ143の実装およびインスタンスをこのように構築して、センサネットワークが様々なプロプライエタリプラットフォーム依存プロトコルを使用し、センサネットワーク102、104、またはその他のネットワークを統合するための解決策が他に存在しないかもしれない状況のそれぞれについて使用することができる。対照的に、サービスゲートウェイ146およびゲートウェイメッセージハンドラ148については、サービスゲートウェイ146を提供する任意のプラットフォームにとって、たった1つだけのゲートウェイメッセージハンドラ148が必要である場合がある。例えば、第2のサービスゲートウェイを別のセンサネットワーク(図1には図示せず)に関連付けることができ、その第2のサービスゲートウェイが、ゲートウェイメッセージハンドラ148のインタフェースを使って、サービスゲートウェイ146と同じサービス指向の方法でゲートウェイメッセージハンドラ148にプロキシをわかるようにすることができる。

したがって、メッセージハンドラ144、148は、それらのそれぞれのセンサネットワーク102、104のハードウェアに抽象化の層を提供する。したがって、メッセージハンドラ144、148と通信する任意のサービスまたはコンポーネントは、単一(のタイプ)のインタフェース、すなわちメッセージハンドラ144、148のインタフェースに気付く必要があるだけの場合があり、共通または標準プロトコルを使ってメッセージハンドラ144、148と通信することができる。このように、例えば、フォールトマネージャ136は、多数のセンサネットワークと、たとえそれらのセンサネットワークが多くの異なるハードウェアおよび/またはソフトウェア環境を使っているとしても、相互作用することができ、また、共通または標準通信プロトコルおよび関連インタフェースを知る必要があるだけの場合がある。

例えば、第1のセンサネットワーク102を、センサネットワーク102に関連したネットワーク関連データの高速データ送信を可能にするプラットフォームに関連付けることができる。しかし、このようなプラットフォームは、すぐにバッテリ/電源が枯渇する場合がある。一方、センサネットワーク104は、最低限の電力で動作するように構成することができるが、高度の移動性が得られるように構成することはできない(例えば、デバイス112〜116またはその他のデバイスの追加や除去が簡単には行えない)。言い換えれば、あらゆる所望の機能または能力を所望のアプリケーションに提供することができるネットワークプラットフォームというものは存在せず、また、実装されることもない場合があるかもしれない、ということだ。したがって、特に、センサネットワーク102、104の典型的な資源制約環境の場合には、異なるネットワークプラットフォームが必要とされる場合があるかもしれない。このように、例えば、メッセージハンドラ144、148(および関連したメッセージブリッジ143およびサービスゲートウェイ146)は、本質的に、フォールトマネージャ136が、例えば、フォールトの診断、フォールトからの回復に関して、あたかもたった1つの通信プロトコル(およびネットワークプラットフォーム)しか存在しないかのように動作できるようにする。これは、図示のように、たとえネイティブメッセージハンドラ144が実際には複数のネイティブメッセージハンドラを、すなわち、多くのセンサネットワークが実装することができる異なる通信プロトコルそれぞれについて1つのネイティブメッセージハンドラを表す場合でも当てはまる。

今述べたように、システム100の構造は、あたかもそれらの異なるセンサネットワークが全て、フォールトマネージャ136の実際的な目的のために、同じハードウェアおよびソフトウェアプラットフォーム上で同じ通信プロトコルを走らせているかのように、フォールトマネージャ136が、多くの異なるセンサネットワーク(センサネットワーク102、104を含むが、それらに限られるものではない)と通信すること、例えば、それらから更新を照会すること、受け取ることを可能にする。

メッセージトランスポートシステム150を、メッセージハンドラ144、148のそれぞれからメッセージおよび/またはイベントを適切なシステムモニタ136にトランスポートするように構成することができる。また、メッセージ(例えば、呼び出し)を1つ以上のシステムモニタ136からセンサネットワーク102、104のうち指定された1つ(またはそれ以上)にトランスポートするように構成する。例えば、メッセージトランスポートシステム150を、メッセージの内容に基づきメッセージを分析してその発信元および/または宛先を判断するように構成された内容ベースのメッセージングシステムとして実装することができる。また、メッセージトランスポートシステム150は、上述の共通または標準通信プロトコルを使って動作することができる。

例えば、ビジネスアプリケーション118のうちいくつかが、センサネットワーク102、104のうち1つ以上によって検出される温度測定に関与していることがある。例えば、ビジネスアプリケーションの1つ以上が食の安全性、または危険性物質/化学薬品の安全性に関連付けられていることがあり、サービス124が温度検出サービスであることがある。その場合ネイティブメッセージハンドラ144がメッセージブリッジ143からメッセージを受け取ると、ネイティブメッセージハンドラ144は、適切なインタフェースを介してメッセージトランスポートシステム150に転送するために、そのメッセージをカプセル化することができる。メッセージトランスポートシステム150は、メッセージの内容を分析して、例えば、摂氏度による測定(または、その他の温度関連のパラメータ)が含まれていると判断することがある。メッセージトランスポートシステム150は、そのメッセージをフォールトマネージャ136に転送することができ、フォールトマネージャ136は、フォールトが温度測定に関連しているかどうか(例えば、温度測定が何らかの物理的に可能な範囲を超えているかどうか)を、また、フォールト回復が行われるかどうか、それがどのように行われるか(例えば、該当するデバイスに新しい温度測定サービスを配備することによって、など)を判断するための様々なアルゴリズムを実装することができる。

図2は、図1のシステム100の追加または代替実装を説明する、システム200のブロック図である。図2の例では、図1のシステム100の例示的実装を、デバイス層202、ミドルウェア層204、アプリケーション層206を含むものとして示している。図示のように、ミドルウェア層204は、プラットフォーム抽象化層204aおよびフォールト管理層204bを含むことができる。これらは、上記の図1の説明から、また以下の説明から理解できるように、システム200内で使用することができるハードウェアプラットフォームの多様性にもかかわらず、フォールトトレランスのための異なる技術の実装を可能にするものである。また、図1の例は、特に上述の層を含むものとして示してはいないが、システム100が、上記のように類似したハードウェア/ソフトウェアを使って、層202〜206、または同様の層を実装することもできることを理解されよう。

図2のデバイス層202では、上述のように、異なるセンサネットワーク102、104は、対応するプラットフォーム(対応通信プロトコルを有する)を実装することができ、また、センサの読み取り示度やビジネスアプリケーション118に関連するイベントなど、実質的に一定の情報を提供するよう動作することができる。アプリケーション層206において、ここで説明するように、ビジネスアプリケーション118a、118b、118cは、ネットワーク102、104によって提供されるデータおよびその他の機能を利用することができるアプリケーションを表す。

上記のように、ミドルウェア層204は、プラットフォーム抽象化層204aおよびフォールト管理層204bを含む副層を含むことがある。図2では、層204aが、異種の複数ネットワークをアプリケーション層206と結合するためのメカニズムを提供し、フォールト管理層204bがネットワーク102、104に関連した(しかし必ずしもそこで発生しているわけではない)障害を検出し、診断し、回復する。上記のインタフェース142の説明からわかるように、フォールト診断マネージャ138およびフォールト回復マネージャ139は、潜在的にはミドルウェア層204中の全てのその他のコンポーネントまたはサブコンポーネントと同様、システム200の透明性および拡張性を確かなものにするために、ウェブサービスインタフェースを提供し、または含むことができる。

より一般には、システム200のフレームワークは、フォールトトレランスのための多くの利点を提供する。例えば、上記のフレームワークの拡張性は、新しい技術およびアプローチを簡単に統合できるようにする。プラットフォーム抽象化層204aおよびフォールト管理層204bによって提供される透明性は、ビジネスアプリケーション118が、使用されているフォールトトレランス技術、またはハードウェアプラットフォームの多様性のレベルと無関係でいられるようにしてくれる。同様に、すでに説明したように、フレームワークは、異なるハードウェアプラットフォームの容易かつ信頼できる統合(例えば、一人の顧客が異なるベンダから異なるデバイスまたはセンサネットワークを購入するときに行われることがある)をサポートしてくれる。システム200のフレームワークはまた、センサネットワーク102、104内の追加ネットワークトラフィック(および関連した資源の消費)を必要としないやり方で、クラッシュ、必要なデータの脱落、任意の障害を含む、フォールトの識別も可能にしてくれる。

さらなる利点は、ここで説明するように、システム200のフォールトを隔離する能力、例えば、単に障害が発生したことを判断するだけでなく、自動的にそれらの障害の原因を識別する能力に関する(例えば、ネットワーク102からデータを受け取れなかったことについては、フォールト隔離によって、そのフォールトの原因が、送信側デバイスのハードウェアの障害、送信側デバイス上に配備されたサービスのソフトウェアの障害、または送信側デバイスからの所望のデータの送信に関連した経路指定の障害のうちの1つ以上であるかもしれないことを判断することができる)。このようにフォールトの原因を判断することにより、例えば、サービスを機能不全のデバイスまたは近くのデバイスに再配備することによって、自動的にフォールトから回復させることが可能になり得る。

システム200では、図1のメッセージハンドラ144、148をプラットフォーム抽象化層204a中に含まれるものとして示しており、それらは、図示のように、「プラットフォームA」を有するセンサネットワーク102、または「プラットフォームB」を有するセンサネットワーク104のいずれかからメッセージまたはその他のイベントを受け取ることができる。ローカルデバイス208aおよび208bは、それぞれ、センサネットワーク102、104からのデータのローカルシンクとして機能することができ、また、ネットワーク102、104からの、またはそれらについてのメッセージを該当するメッセージハンドラ144、148に転送する責任を有することがある。

メッセージを受け取り、その後、メッセージを共通通信プロトコルに翻訳すると、メッセージハンドラ144、148は、そのメッセージを、例えば、図1のメッセージトランスポートシステム150の一部としての通知ブローカ210に転送することができる。通知ブローカ210は、ウェブサービスの仕様、WSBrokeredNotificationにしたがったものであり得、そのようなイベントおよび/またはメッセージを受け取るように、また、例えば、メッセージの内容、およびシステム200のその他のコンポーネントの購読プロファイルに基づき、メッセージを転送(例えば、発行)するように構成することができる。例えば、メッセージは、状態モデル140、フォールト診断マネージャ138、および/またはビジネスアプリケーション118の購読に関連したトピックに関するもののことがある。

例えば、上記のように、通知ブローカ210を、メッセージトランスポートシステム150のコンポーネントと考えることができる。通知ブローカ210は、通知メッセージを、共通通信プロトコルを使った一般的なイベントフォーマットで、例えば、そのメッセージの原因となったイベント、および/またはメッセージがその一部であるトピックに関連する、メッセージの内容に基づいて、該当する宛先に転送することができる。例えば、上記の例と同様に、センサネットワーク102は温度検出メッセージを生成することができ(例えば、温度が所望の最大値を超えたという情報を提供する)、また、最終的に、(ネイティブ)メッセージハンドラ144に、次いで通知ブローカ210に転送されるメッセージを生成することができる。

イベントの内容に基づいて、通知ブローカ210は、そのイベントに関連したトピックの1またはそれ以上の購読者を判断する。例えば、状態モデル140は、「温度関連イベント」というトピックまたは「センサネットワーク102からの全てのメッセージ」というトピックを購読することができ、したがって、それに応じて状態モデル140の更新の際に使用する関連メッセージを受け取ることができる。

フォールト管理層204bは、主としてフォールトを診断し、そのフォールトの原因を判断し、可能であればそのフォールトから回復させる役目を果たすことができる。それを行うに当たって、フォールト診断マネージャ138は、状態モデル140と通信し、そこからフォールトを検出あるいは判断するよう構成されたフォールト検出器212を含むことができる。フォールト隔離器214は、上述のように、該当するセンサネットワークに関連したフォールトの理由または原因を隔離あるいは判断するように構成することができる。

例えば、フォールト検出器212はセンサノードから外れ値の読み取り示度を識別することができる。次いで、フォールト隔離器214は、この情報、および可能には追加入力(例えば、デバイスマネージャ141からの)に基づいて、センサの対応するノードへの接続がゆるいと判断することがある。

フォールト隔離器214の結果は、フォールト回復マネージャ139、例えば、最終決定ロジック216に転送することができる。最終決定ロジック216は、障害から回復させるのにどのアクションが必要か―そのような動作がある場合―を評価する責任を担うことができる。いくつかの例示的実装においては、最終決定ロジック216が、問題のあるハードウェアコンポーネントを修理または交換するために技術者を現場に送るなど、手動オペレーションを表し、または含む場合がある、ワークフローを開始させることができる。その他の例示的実装においては、最終決定ロジックが、センサネットワーク102、104とビジネスアプリケーション118の中の、またはそれらの間の、メッセージの経路指定の再構成を行わせることができる。

上記その他の回復技術が可能であるが、図2は、センサ値融合ブロック220およびマッピングロジック222を含む回復モジュール218を示す。センサ値融合ブロック220は、単一の動作していないセンサの影響を最小限にするために、同じまたは同様のセンサの同様の出力を融合または結合(例えば、平均化)することによって、フォールトから回復させる役割を果たすことができる。マッピングロジック222は、フォールト診断マネージャ138によって判断された欠陥のある機能を引き継ぐことができるいずれかその他のノードが存在しているかどうかを判断し、もし存在する場合には、そのようなノードが、現在、判断されたフォールトを軽減または補正するために選択される取替/回復サービスを受け取るように構成されているかどうか、また、受け取る能力があるかどうかを判断するマッピング機能を実行することができる。次いで、コード配布マネージャ224は、決定された実行ファイルをサービス貯蔵所126から得る責任を担うことができる。

したがって、マッピングロジック222およびコード配布マネージャ224を、図1のサービスマッパ132の一部としてみることができる。図2では、図示のように、異なる層204b、204aに含まれるものとして示すため、それらのそれぞれの機能を別個のものとしている。すなわち、コード配布マネージャ224は、サービスインジェクタ134のうち適切な1つを選択し、それと通信する責任を担うことができ、各サービスインジェクタ134は、共通プロトコルから、所望のサービスを配備/注入する先のセンサネットワークが使用しているプロトコルへの送信を翻訳する責任を担うことができる。すなわち、本質的にメッセージハンドラ144、148のオペレーションとは反対のオペレーションにおいて、サービスインジェクタ134は、それぞれがセンサネットワーク102、104の少なくとも1つが使用しているプロトコルに関連付けられ、それぞれがペイロードをセンサネットワーク102、104のうち対応する1つに転送する責任を有することができる、複数のサービスインジェクタを表すことができる。したがって、この場合も、センサネットワーク102、104との通信を行う際に、アプリケーション層206について透明性が維持される。

図1を参照して述べたように、ローカルフォールトマネージャ137は、フォールトマネージャ136と同様の、または同じ機能のいくつかまたは全てを実装することができるが、ただし、それはセンサネットワーク102、104の1つ以上のデバイスという状況においてのことである。例えば、ネットワーク内フォールト検出アルゴリズムを、例えば、グループフォールト検出器226によって適用することができる。この場合、グループフォールト検出器226は、センサネットワーク102のノード間の協同という考え方を用いて、例えば、外れ値の読み取り示度および/またはクラッシュ障害を識別することができる。さらに、ノードは、例えば、自己診断モジュール228を使って自己診断を行って、有り得ない読み取り示度(例えば、100%以上の湿度)や差し迫ったバッテリ障害など、可能性がある障害を識別することができる。その場合、デバイス層において、センサ融合技術、または問題のデバイス/ノードのグループの新たなリーダの選択など、フォールト回復技術を適用することができる。

いくつかの実装においては、ローカルフォールトマネージャ137が、フォールト関連メッセージを、対応するメッセージハンドラに、したがって、通知ブローカ210に転送することができる。この場合、すでにデバイス層202においてフォールト検出がなされているので、その後メッセージを、直接、フォールト隔離器214に転送することができる。

図2において、最後に、要求プロセッサ226を、例えば、センサネットワーク102、104の1つ以上のデバイスのアプリケーション層206から、またはフォールト管理層204bからの要求を容易にするように構成することができる。例えば、アプリケーション118bは、温度の読み取り頻度を上げる要求をすることができ、その要求を、要求プロセッサ226が、翻訳、および必要なセンサネットワークおよびそのネットワークの所望のデバイスへの転送のために、適切なメッセージハンドラに転送することができる。いくつかの実装においては、要求プロセッサ226が、非同期呼び出しを容易にすることができる、1つ以上のバッファを含むことができる。これは、例えば、ある期間、センサネットワーク102、104のノードの1つ以上が連絡がつかない場合(例えば、送信範囲外の場合)に役立つことがある。

図3は、図1および/または2のシステムにおいて生じることがあるフォールト伝播の例を示すブロック図300である。図3は、フォールト伝播の道筋に沿って定義することができる4つの層302、304、306、308を示す。例えば、ノードまたはデバイスレベルにおける層302は、バッテリ312またはその他の電源、すでに説明したCPU120およびメモリ122の他に、デバイスのためのエンクロージャ(例えば、ケーシングまたはカバー)を、また、測定値を収集するための実際のセンサ314、およびネットワーク層304と通信するために必要なネットワークインタフェースを含むことができる。一方、ソフトウェア317は、経路指定情報318、例えば、メッセージをネットワーク層に転送するための経路指定ツリー、および対応ノードの媒体アクセス制御(MAC)アドレスに関する情報を含むことができ、また、センサ314とともに、感知されたデータを収集するよう作動するデータ取得モデル322も含むことができる。

ネットワーク層304は、ノード層302からシンク層306へのメッセージの経路指定に関連した、リンク326およびパス324を含む。例えば、デバイス108からのメッセージは、まずデバイス110に、次いでメッセージブリッジ143(例えば、図2のシンク208a)に経路指定され得る。ネットワーク層304は、例えば、ノード層302の経路指定情報318に従って、デバイス間のリンクを管理し、パスを定義する。

次に、シンク層306では、ハードウェアコンポーネントは、例えば、センサネットワークノードまたはバックエンド層308と通信するための無線センサネットワークインタフェース332およびバックエンドネットワークインタフェース334とともに、CPU328、メモリ330、電源326を含むことができる。シンクでのソフトウェアは、例えば、シンク204aとセンサネットワーク102の各デバイスの間のクロックを調整するためのクロックシンクロナイザ336を含むことができる。集合器338は、センサネットワークのノード/デバイスの複数から読み取り示度を集めることができ、また、例えば、対象となるデバイスの現在のロケーションまたはステータスに関する問い合わせをネットワーク102、104に転送するための、問い合わせモジュール340を含むことができる。図3において、最後に、バックエンド層308は、例えば、グラフィカルユーザインタフェースを介して、収集されたデータを監視し、ユーザに提示するためのアプリケーションを表すことがあるアプリケーション344、またはその他のバックエンドアプリケーション(ビジネスアプリケーション118を含む)、およびバックエンドとセンサネットワークデバイスの間のエンドツーエンド接続を含むことができる。

したがって、図3から、フォールトが事実上システム300のどの層においても発生することがあり、一般的には、その後、バックエンド層308に向かって伝播することがあることが理解されよう。例えば、無線センサネットワークは、過酷な環境で配備されることが多い。そのため、様々なハードウェア303およびソフトウェア317のコンポーネントが、それぞれに応じたタイプのフォールトを発生させる可能性がある。例えば、エンクロージャ310が機械的ストレスを受けることがある。あるいは、水や火に接触したり、アンテナなど、風雨にさらされる電子部品を含むことがある。さらに、ノードが期待通りに挙動しなくなる原因となるような、ソフトウェアのバグやその他の機能不全、あるいはバッテリの低下によるセンサの誤った読み取りが発生する場合がある。

ネットワーク層304では、経路指定関係のフォールトによって、メッセージの欠落や誤った宛先への送付、メッセージの衝突、または許容できない遅延が生じることがある。しかし、その他の状況では、ノードのリンク接続が適切でありながら、それでも、パスの誤りのためにメッセージが宛先に送付されないことがある。特に、経路指定層におけるソフトウェアのバグによって、環状パスや、誤った宛先へのメッセージの送付が生じることがある。別の例として、ノードがある程度の移動性を有するシナリオでは、ノードが範囲外の領域に行ってしまうことがある。

シンク層306では、バックエンドに伝播するためにネットワークからデータを収集するデバイス(シンク)(例えば、デバイス208a、208b)は、上述のコンポーネントなど、そのデバイスのコンポーネントのフォールトの影響を受けやすい。例えば、電源326を見ると、無停電電源装置が全く存在しないエリアにシンクを配備させることができる。このようなアプリケーションでは、太陽電池とともにバッテリを使って必要なエネルギー量を提供する。これらのアプリケーションでは、例えば、動力セルを覆った雪などの自然物質のために、シンクがバッテリ障害の影響を受けやすい。また、悪天候やその他の自然現象の結果として、連絡が取れなくなることがある。

図3において、最後に、バックエンド層308でフォールトが生じた場合、例えば、ソフトウェアの機能不全やハードウェアの障害のためにアプリケーション344でフォールトが生じた場合、システム全体がフォールトありとみなされることがある。例えば、たとえ全てのセンサデータが正しく収集されて送信されたとしても、アプリケーション344がこの収集されたデータを正しく提示できなかったならば、ユーザ(図3に図示せず)に関する限り、そのシステムは意図した目的には不適切ということになり得る。

したがって、次のことを理解されたい。図1、図2のフレームワークは、障害がシステムの上位層に伝播される脅威を減じる。低レベルでの障害は、そのような伝播が生じる前に、検出し、隔離し、かつ修正することができるからである。さらに、発生し、より上位の層に伝播した誤りについても、図1、図2のフレームワークは、この同じ誤りが頻繁に発生する機会を減じる役目をすることができる。

図4は、図1〜2のシステムの第1の例示的オペレーションを示すフローチャート400である。図4の例では、複数のノードネットワークに関連したネットワーク関連データを、複数のメッセージハンドラのうち1つで受け取ることができる(402)。複数のメッセージハンドラを、それぞれ、対応ノードネットワーク、および対応ノードネットワークが使用している対応通信プロトコルに関連付けることができる。例えば、図1を参照して説明し、示したように、メッセージハンドラ144、148は、それぞれ、センサネットワーク102、104からメッセージを受け取ることができる。

ネットワーク関連データを、対応通信プロトコルから共通通信プロトコルに翻訳することができる(404)。例えば、メッセージハンドラ144、148は、それぞれ、第1および第2の通信プロトコルから、メッセージトランスポートシステム150(例えば、通知ブローカ210)が理解する共通通信プロトコルに、メッセージを翻訳することができる。

共通通信プロトコルのネットワーク関連データを、複数のノードネットワークに関連する状態情報を記述する状態モデルに提供することができる(406)。例えば、通知ブローカは、メッセージハンドラ144、148から受け取ったメッセージを状態モデル140に発行することができる。

複数のノードネットワークのオペレーションに関連したフォールトを、状態モデルに基づいて診断することができる(408)。例えば、フォールト診断マネージャ138は、状態モデル140(および、可能には、デバイスマネージャ141またはその他のコンポーネント)に問い合わせるか、あるいは通信することで、フォールトが発生したかどうか(例えば、期待していたものと反対の誤った温度読み取り示度が得られたこと)を判断するための十分な情報を得ることができる。より具体的には、フォールト検出器212は、状態モデル中のメッセージ/イベントを分析してフォールトの存在を検出することができ、一方、フォールト隔離器214は、次いで、そのフォールトの原因または開始点を隔離することができる。

ノードネットワークのノードに、そのノードが使用している対応通信プロトコルを使ってサービスを配備することによって、フォールトから回復させることができる(410)。例えば、サービスマッパ132、および/またはマッピングロジック222とコード配布マネージャ224は、サービス貯蔵所126から、システム100/200中のフォールトの源として診断され隔離された配備サービスを取り替えるのに適した、サービス実行ファイルを決定することができる。次いで、サービスインジェクタ134は、その判断されたサービスを配備するのに適しているとマッピングロジック222が判断した1つ以上のノードに、このサービス実行ファイルを注入することができる。

図5は、図1〜2のシステムの第2の例示的オペレーションを示すフローチャート500である。図5の例では、ノードネットワークに関連したメッセージやその他のイベントなどのネットワーク関連データを、1つ以上のメッセージハンドラにおいて受け取ることができる(502)。メッセージハンドラは、受け取ったメッセージを、通知ブローカ210に転送するために、共通通信プロトコルに翻訳することができる(504)。次いで、通知ブローカ210は、そのメッセージを状態モデル140に転送(発行)することができる(506)。

フォールト検出を行うべきかについての決定を行うことができる(508)。例えば、いくつかのフォールト検出アルゴリズムを、定期的に実装されるようにスケジュールすることができる。その他の例では、予期せぬ値や、予期せぬ時に受信されたメッセージなど、状態モデル中のメッセージの何らかの特性によって、フォールト検出を開始させることができる。フォールト検出が行われない場合、メッセージハンドラは、単に、さらなるネットワーク関連データを受け取り続けることができる(502)。

フォールト検出が行われる場合(508)、検出すべき、可能性あるフォールのタイプを決定することができる(510)。例えば、異なるフォールトタイプを定期的に調べることができる。その他の例では、特定のタイプのフォールトを調べるために、状態モデル中の情報がフォールト検出器212を開始させることができる。

次いで、フォールト検出器212は、状態モデル140に情報を要求する(512)。すなわち、上述のように、またここで述べているように、無線センサネットワークは、これらのメッセージ/イベントをメッセージハンドラ144、148に伝播することができる。これらのメッセージのフォーマットは、ハードウェアプラットフォームに依存することがあるが、一般に、検出されたセンサの読み取り示度、送信ノード/デバイスの識別子、および各メッセージ/イベントのタイムスタンプを含み得る。もちろん、ノード上を走っているアプリケーションに応じて、追加の情報も得られることがある。その後購読しているコンポーネント(例えば、状態モデル140)への発行のために通知ブローカ210に転送されるとき、それらのメッセージは、センサの読み取り示度、ノードの識別子、タイムスタンプ、および発信側センサネットワークのハードウェアプラットフォームに関する情報を含み得る。したがって、少なくともこの情報は、フォールト検出器212で利用可能である。

したがって、フォールト検出器212は、分析されている障害のタイプに応じて、種々のデータを状態モデルに要求することができる。例えば、タイムアウトクラッシュの障害(512a)については、フォールト検出器212は、該当するノードまたはノードグループによって送られてきた最後のイベントのタイムスタンプを要求することができる。リンクの障害(512b)については、フォールト検出器212は、各ノードによって送られてきたメッセージ間の時間の差を要求することができる。センサ値の障害(512c)については、分析された期間内のノードからのセンサの読み取り示度およびタイムスタンプを受け取ることができる。

次いで、フォールト検出器212は、フォールトが発生したと判断することがある(514)(そうでない場合、ネットワーク関連データの受信が続くことが可能である(502))。その場合、フォールト検出器212は、その障害の原因を判断するために、フォールトメッセージをフォールト隔離器214に転送することができる(516)。このフォールトメッセージは、フォールトが出現した時間、フォールトのタイプ、ノード識別子、関連ハードウェアプラットフォームに関連する情報を含むことがある。

例えば、種々のフォールト検出信号の内容に応じて、フォールト隔離器214は、例えば、二分決定木または規則を含む隔離技術を適用して、フォールトの理由を表すことができる(518)。理由が隔離されると、フォールト隔離器214は、そのフォールトの原因に関連するメッセージを、フォールト回復マネージャ139、例えば、最終決定ロジック216に転送することができる(520)。このメッセージは、障害のタイプ、障害の理由、障害の場所、障害が出現した時間を含み得る。

最終決定ロジック216は、フォールト隔離器214からメッセージを受け取ることができ、また、回復モジュール218に転送するためのフォールト回復プロシージャを決定することができる(522)。ここで述べるように、回復モジュール218が回復を実行するために複数のオプションが可能である。例えば、センサまたはその他のデバイスハードウェアを修正または修理するために手動ワークフローを開始させることができる。または、潜在的なセンサ値の誤りを軽減するために、センサ値の融合が行われることがある。図5の例では、検出され、隔離されたフォールトを、ノードネットワーク内の配備されたサービスに関連付けることができ、その時、最終決定ロジック216は、特定の回復技術、障害の源の識別子(例えば、1つ以上のノード、またはそのハードウェア/ソフトウェア)、および回復ターゲット(例えば、所望のセンサ読み取り示度)、およびセンサネットワーク102、104に(再)配備することができるサービスのサービス名を含み得るメッセージを、回復モジュール218に(例えば、マッピングロジック222に)転送できることを前提とすることがある。

マッピングロジック222は、前もって診断されたフォールトを軽減または除去するような方法で動作すると判断できる新しいサービスを配備すべき、新しいノードを決定することができる(場合によりデバイスマネージャ141を使って)(524)。この技術は、ネットワーク内で走っているサービスの多くのインスタンスを維持しようとすることができる。ノードが選択されると、マッピングロジック222は、ターゲットノードの識別子の情報、関連センサネットワークが使用する関連ハードウェアプラットフォームおよび関連した通信プロトコル、および配備すべきサービスに関連したサービス識別子を含めて、この情報をコード配布マネージャ224に送ることができる。

次いで、コード配布マネージャ224は、所望のサービスのサービス識別子に基づいて、また、問題のネットワークの関連ハードウェアプラットフォームに関する情報に基づいて、その所望のサービス実行ファイルを決定して、サービス貯蔵所126に要求することができる(526)。図5において、最後に、コード配布マネージャ224は、正しいサービスインジェクタ134を選択して、各ノードにどのサービスを配備すべきかを表す(対応するメッセージで)ことができる。このメッセージは、例えば、ノード識別子、関連ハードウェアプラットフォーム、サービス識別子、配布方法、および実行可能サービス(またはそれについての記載)を含み得る。このように、サービス実行ファイルを無線センサネットワーク内で配布することができる。メッセージのフォーマットおよび内容は、ハードウェアプラットフォームおよび選択した方法に依存することがある。

図5を参照して説明したこのようなフォールトの検出は、フォールト検出器212を通じたバックエンドの援助で、および/またはデバイス層202の中で行われることを理解されよう。無線センサネットワーク自体は、例えば、ここで説明するようにローカルフォールトマネージャ137を使って、ノードの状態を監視することができ、ローカルフォールトマネージャ137は、次いで、フォールト検出イベントをミドルウェア層204に送ることができる。これらのメッセージ/イベントは、検出されたフォールトのタイプ、ノード識別子、およびフォールトが出現した時間を含み得る。これらの例では、メッセージハンドラがメッセージを受け取り、対応するハードウェア情報を追加し、また、そのメッセージを通知ブローカ210に転送することができる。ローカルフォールトマネージャ137でフォールト検出がすでになされている場合、通知ブローカ210は、メッセージを直接、フォールト隔離器214に転送することができる。

ここで提供した例の多くはビジネスアプリケーションまたは設定に関するものであるが、これらの例は例示のためにすぎず、本説明が多種多様の設定において適用可能であることを理解されよう。例えば、説明した特徴は、科学的研究(例えば、環境条件を研究するために配備するセンサネットワーク)という状況において実装することができ、あるいは、個人または政府の使用目的で実装することができる。その他の実装および使用が可能であることも明らかになろう。

ここで説明した様々な技術の実装は、ディジタル電子回路、あるいはコンピュータのハードウェア、ファームウェア、ソフトウェア、またはその組合せで実装することができる。実装はコンピュータプログラム製品として行うことができる。コンピュータプログラム製品とは、すなわち、情報担体において、例えば、マシン読み取り可能な記憶装置において、あるいは、データ処理装置、例えば、プログラマブルプロセッサ、コンピュータ、または複数のコンピュータによって実行されるために、またはそのようなデータ処理装置のオペレーションを制御するために伝播される信号において、具体的に具現化されるコンピュータプログラムである。上記のコンピュータプログラムなどのコンピュータプログラム製品は、コンパイル型言語またはインタプリタ型言語を含み、任意の形態のプログラミング言語で書くことができ、スタンドアローンプログラムとしてでも、あるいはモジュール、コンポーネント、サブルーチン、またはコンピューティング環境で使用するのに適したその他のユニットとしてでも、任意の形態で配備することができる。コンピュータプログラムは、1つの場所において1台のコンピュータまたは複数のコンピュータで実行されるように配備することができ、あるいは、複数の場所に配布して、通信ネットワークによって相互接続することもできる。

方法のステップは、1つ以上のプログラマブルプロセッサが、コンピュータプログラムを実行して、入力データを処理し出力を生成することにより機能を実行することによって、実行することができる。方法のステップはまた、専用のロジック回路、例えば、FPGA(フィールドプログラマブルゲートアレイ)またはASIC(特定用途向け集積回路)によって実行することができ、また装置を、そのような専用ロジック回路として実装することができる。

コンピュータプログラムの実行に適したプロセッサには、一例として、汎用および専用マイクロプロセッサの両方、および任意の種類のディジタルコンピュータの任意の1つ以上のプロセッサが含まれる。一般に、プロセッサは、リードオンリメモリまたはランダムアクセスメモリまたはその両方から命令およびデータを受け取る。コンピュータの要素には、命令を実行するための少なくとも1つのプロセッサ、および命令およびデータを記憶するための1つ以上のメモリデバイスが含まれ得る。一般に、コンピュータはまた、データを記憶するための1つ以上の大容量記憶装置、例えば、磁気、光磁気ディスク、または光ディスクを含むことができ、あるいは、それからデータを受け取るために、またはそれにデータを転送するために、あるいはその両方のために、それらに動作可能に結合され得る。コンピュータプログラム命令およびデータを具現化するのに適した情報担体には、あらゆる形態の不揮発性メモリが含まれる。これには、一例として、例えばEPROM、EEPROM、フラッシュメモリデバイスなどの半導体メモリデバイス、例えば内部ハードディスクやリムーバブルディスクなどの磁気ディスク、光磁気ディスク、CD-ROMおよびDVD-ROMディスクが含まれる。プロセッサおよびメモリを専用ロジック回路で補強したり、専用ロジック回路に組み込んだりすることができる。

ユーザとの相互作用ができるように、ユーザに情報を表示するためのディスプレイデバイス、例えば、陰極線管(CRT)または液晶ディスプレイ(LCD)モニタ、および、それによってユーザがコンピュータに入力できる、キーボードおよびポインティングデバイス、例えば、マウスやトラックボールを有するコンピュータ上で実装を行うことができる。ユーザとの相互作用のためにその他の種類のデバイスを使うこともできる。例えば、ユーザに提供されるフィードバックは、任意の形態の感覚フィードバック、例えば、視覚的フィードバック、聴覚的フィードバック、または感触的フィードバックが可能である。また、ユーザからの入力は、任意の形態で受け取ることができる。これには、音響、音声、または感触入力が含まれる。

例えば、データサーバとしてのバックエンドコンポーネントを含む、または、ミドルウェアコンポーネント、例えば、アプリケーションサーバを含む、または、フロントエンドコンポーネント、例えば、ユーザがそれを通じて実装と相互作用できる、グラフィカルユーザインタフェースまたはウェブブラウザを有するクライアントコンピュータ、またはこのようなバックエンド、ミドルウェア、またはフロントエンドコンポーネントの任意の組合せを含むコンピューティングシステムに、実装を行うことができる。コンポーネントは、ディジタルデータ通信の任意の形態または媒体、例えば、通信ネットワークによって相互接続することができる。通信ネットワークの例には、ローカルエリアネットワーク(LAN)および広域ネットワーク(WAN)、例えば、インターネットが含まれる。

記載の実装の特定の特徴を、ここで説明しているように示してきたが、当業者は、今や、多くの修正、代替、変更、同等のものを思いつくであろう。したがって、添付の「特許請求の範囲」は、実施形態の精神の範囲内に入る全てのこのような修正および変更を含むよう意図したものであることを理解されたい。

ノードネットワークにおけるフォールトトレランスのためのシステムのブロック図である。図1のシステムを実装するための多層フォールトトレランスフレームワークを説明するブロック図である。図1および/または図2のシステムにおいて発生することがある、フォールトの伝播の例を説明するブロック図である。図1〜3のシステムの第1の例示的オペレーションを説明するフローチャートである。図1〜3のシステムの第2の例示的オペレーションを説明するフローチャートである。

符号の説明

100 システム
102 ノードネットワーク
104 ノードネットワーク
106 デバイス
108 デバイス
110 デバイス
112 デバイス
114 デバイス
116 デバイス
118 ビジネスアプリケーション
118a ビジネスアプリケーション
118b ビジネスアプリケーション
118c ビジネスアプリケーション
120 CPU
122 メモリ
124 サービス
126 サービス貯蔵所
128 サービス実行ファイル
130 サービスメタデータ
132 サービスマッパ
134 サービスインジェクタ
136 フォールトマネージャ
137 ローカルフォールトマネージャ
138 フォールト診断マネージャ
139 フォールト回復マネージャ
140 状態モデル
141 デバイスマネージャ
142 インタフェース
143 メッセージブリッジ
144 ネイティブメッセージハンドラ、メッセージハンドラ
145 コンピュータ
146 サービスゲートウェイ
148 ゲートウェイメッセージハンドラ
150 メッセージトランスポートシステム
202 デバイス層
204 ミドルウェア層
204a プラットフォーム抽象化層
204b フォールト管理層
206 アプリケーション層
210 通知ブローカ
212 フォールト検出器
214 フォールト隔離器
216 最終決定ロジック
218 回復モジュール
220 センサ値融合
222 マッピングロジック
224 コード配布マネージャ
226 要求プロセッサ
226 グループフォールト検出器
228 自己診断モジュール
302 ノード層
303 ハードウェア
304 ネットワーク層
306 シンク層
308 バックエンド層
310 エンクロージャ
312 バッテリ
314 センサ
316 ネットワークインタフェース
317 ソフトウェア
318 経路指定情報
322 データ取得モデル
324 パス
326 電源
326 リンク
330 メモリ
332 無線センサネットワークインタフェース
334 バックエンドネットワークインタフェース
336 クロックシンクロナイザ
338 集合器
340 問い合わせモジュール
344 アプリケーション

Claims

第1の通信プロトコルを使用する第1のノードネットワークに関連した第1のネットワーク関連データを受け取るように構成された第1のメッセージハンドラと、
第2の通信プロトコルを使用する第2のノードネットワークに関連した第2のネットワーク関連データを受け取るように構成された第2のメッセージハンドラと、
前記第1のネットワーク関連データおよび前記第2のネットワーク関連データとを受け取るように構成され、さらに、前記第1のネットワーク関連データおよび前記第2のネットワーク関連データの経路指定を共通プロトコルで行うように構成されたメッセージトランスポートシステムと、
前記ネットワーク関連データを前記共通プロトコルで受け取るように構成され、また、前記共通プロトコルの前記ネットワーク関連データに基づいて、前記第1のノードネットワークおよび前記第2のノードネットワークのうちの1つ以上のオペレーションに関連したフォールトを判断するように構成されたフォールトマネージャと、を含むシステム。
前記第1のメッセージハンドラは、
前記第1のネットワーク関連データを受け取るためにメッセージブリッジと通信を行うネイティブメッセージハンドラであって、前記メッセージブリッジが、前記第1の通信プロトコルを使って前記第1のノードネットワークの少なくとも1つのデバイスと通信を行うネイティブメッセージハンドラを含み、
前記ネイティブメッセージハンドラは、前記第1のネットワーク関連データを前記第1の通信プロトコルから前記共通通信プロトコルに翻訳するように構成された、請求項1に記載のシステム。
前記第2のメッセージハンドラは、
前記第2のネットワーク関連データを受け取るためにサービスゲートウェイと通信を行うゲートウェイメッセージハンドラであって、前記サービスゲートウェイが前記第2のノードネットワークの少なくとも1つのデバイスと通信を行い、また、前記第2の通信プロトコルと互換性があるゲートウェイメッセージハンドラを含み、
前記ゲートウェイメッセージハンドラは、前記メッセージトランスポートシステムに転送するために、前記サービスゲートウェイから、前記第2のネットワーク関連データを前記共通通信プロトコルで受け取るように構成された、請求項1に記載のシステム。
前記メッセージトランスポートシステムは、前記共通プロトコルを使って、前記第1のネットワーク関連データおよび/または前記第2のネットワーク関連データの少なくともいくつかを、それらに基づいた前記フォールトの判断のために発行するように構成された通知ブローカを含む、請求項1に記載のシステム。
前記メッセージトランスポートシステムは、
追加ネットワーク関連データの要求を受け取り、
前記要求の内容に基づいて、前記第1のネットワークを、前記追加ネットワーク関連データを提供するように構成されているものとして選択し、
前記要求を前記第1のメッセージハンドラに転送するように構成された要求プロセッサを含む、請求項1に記載のシステム。
前記フォールトマネージャは、前記第1のノードネットワークおよび前記第2のノードネットワークで発生しているイベントを記憶するように構成された状態モデルを含む、請求項1に記載のシステム。
前記フォールトマネージャは、少なくとも前記第1のノードネットワークに関連したイベントが前記フォールトに関連していることを判断するように構成されたフォールト診断マネージャを含む、請求項1に記載のシステム。
前記フォールト診断マネージャは、
フォールトのタイプ、および該フォールトのタイプに関連したフォールト検出アルゴリズムを判断するように、また、前記フォールト検出アルゴリズムおよび前記イベントに基づいて前記フォールトを検出するように構成されたフォールト検出器を含む、請求項7に記載のシステム。
前記フォールト診断マネージャは、
前記フォールト検出器から前記検出されたフォールトを受け取るように構成され、また、前記ノードネットワークに関して前記フォールトの原因を判断するように構成されたフォールト隔離器を含む、請求項8に記載のシステム。
前記フォールトマネージャは、
前記フォールトにもかかわらず前記ノードネットワークのオペレーションを回復するための回復方法を決定するように構成されたフォールト回復マネージャを含む、請求項1に記載のシステム。
前記フォールト回復マネージャは、
ワークフローを開始させる段階、センサ値融合を行う段階、前記ノードネットワークのノード内にサービスを配備する段階のうち1つ以上を含む複数の回復方法の中から、前記回復方法を決定するように構成された最終決定ロジックと、
前記決定された回復方法を実装するように構成された回復モジュールと、を含む、請求項10に記載のシステム。
前記第1のノードネットワーク内のターゲットノード、およびサービスを配備するためのサービス実行ファイルを、前記フォールトに応じて、また、前記フォールト回復マネージャによる前記ターゲットノードへの前記サービスのマッピングに基づいて決定するように構成されたコード配布マネージャと、
前記サービス実行ファイルを前記ターゲットノードに配備するように構成されたサービスインジェクタであって、前記第1の通信プロトコルと互換性があるものとして複数のサービスインジェクタの中から選択されたサービスインジェクタと、を含む、請求項10に記載のシステム。
複数のノードネットワークと通信するように構成され、また、少なくとも1つのバックエンドアプリケーションと通信するように構成されたミドルウェア層であって、
前記複数のノードネットワークから、第1のネットワーク関連データおよび第2のネットワーク関連データを、それぞれ、第1の通信プロトコルおよび第2の通信プロトコルで受け取るように構成され、また、前記第1のネットワーク関連データおよび前記第2のネットワーク関連データを共通プロトコルで提供するように構成されたプラットフォーム抽象化層と、
前記第1のネットワーク関連データおよび前記第2のネットワーク関連データを前記共通プロトコルで受け取るように構成され、また、前記複数のネットワークのオペレーションに関連したフォールトを判断するように構成されたフォールト管理層と、を含むミドルウェア層を含むシステム。
前記プラットフォーム抽象化層は複数のメッセージハンドラを含み、それぞれのメッセージハンドラが少なくとも前記第1の通信プロトコルおよび前記第2の通信プロトコルの対応する1つを前記共通プロトコルに翻訳する、請求項13に記載のシステム。
前記プラットフォーム抽象化層は複数のサービスインジェクタを含み、それぞれのサービスインジェクタが、前記第1の通信プロトコルおよび前記第2の通信プロトコルのうち対応する1つを使って、前記ノードネットワークの対応する1つにサービス実行ファイルを配備するように構成された、請求項13に記載のシステム。
前記フォールト管理層は、
前記ノードネットワークのオペレーションに関連したイベントが前記フォールトに関連していることを判断するように構成され、また、前記フォールトの原因を判断するように構成されたフォールト診断マネージャを含む、請求項13に記載のシステム。
前記フォールト管理層は、
前記フォールト診断マネージャから、前記イベント、前記フォールト、前記原因に関連するフォールト関連メッセージを受け取るように構成され、また、前記フォールトに対処するための回復方法を決定するように構成されたフォールト回復マネージャを含む、請求項16に記載のシステム。
複数のメッセージハンドラの1つにおいて、複数のノードネットワークに関連したネットワーク関連データを受け取る段階であって、前記複数のメッセージハンドラが、それぞれ、対応ノードネットワーク、および該対応ネットワークによって使用されている対応通信プロトコルに関連付けられている段階と、
前記ネットワーク関連データを、前記対応通信プロトコルから共通通信プロトコルに翻訳する段階と、
前記ネットワーク関連データを、前記共通通信プロトコルで、前記複数のノードネットワークに関連する状態情報を記述する状態モデルに提供する段階と、
前記複数のノードネットワークのオペレーションに関連したフォールトを、前記状態モデルに基づいて診断する段階と、
前記ノードネットワークのノードに、該ノードによって使用されている前記対応通信プロトコルを使ってサービスを配備することによって、前記フォールトから回復させる段階と、を含む方法。
前記ネットワーク関連データを前記共通通信プロトコルで提供する段階は、
前記ネットワーク関連データの内容、および前記状態モデルによる該内容の購読とに基づいて、前記ネットワーク関連データの通知を前記状態モデルに発行する段階とを含む、請求項18に記載の方法。
前記フォールトを診断する段階は、前記状態モデルから、前記ノードネットワークに関連したイベントを判断する段階と、
フォールトタイプを判断する段階と、
前記イベントが前記フォールトタイプに関連していることを判断する段階と、を含む、請求項18に記載の方法。