JP5188817B2 - 分散型資産管理システム及び方法 - Google Patents

Description

本発明は、データ処理を行う遠隔アプリケーションを管理する方法及びシステムに関する。

最近の組織の多くは、日常の業務を遂行するために、機械類、建物、コンピュータ、車両、及びその他の様々なタイプの機器を使用する。そのような資産は、資源を消費し、劣化を受け、保守及び交換コストを必要とする。

特に、ディスクリート型及びプロセス型製造業、輸送業、公益事業など資産集約的な産業では、資産管理が不十分だと、使い過ぎ、生産性の低下、浪費が起こる。自動化された企業資産管理ソリューションを採用する主な推進要因は、全体の収益性、資産利用率、資産実績、機器の保守及び稼働時間、予算管理／企画の改善、並びに在庫回転率の向上である。

多くの組織は、その法人資産内に元来あるまだ活用されていない価値を認識してはいるが、データを十分に利用しない手作業の処理に依存しているため、その価値にアクセスし取り出すことができていない。資産の多い会社は、その重要な資産を保守し、組織化し、維持するために、地理的に分散された設備、様々なインタフェースやプロトコルを有する生産設備、保有車両、及び伝統的な紙ベースの処理を使用するＩＴインフラストラクチャを有する。

資産管理の判断の質は、その判断の基準となるデータの質に依存する。資産の状態、利用率及び場所に関する不正確でアンタイムリーなデータは、意志決定を不適切なものとする。過去の予算に組み込まれた保守コスト、保証及びライセンスの遵守、設備や車両群の利用率など、重要な資産データポイントは、構造化されないでランダムに収集されることが多い。実際には、資産を多く抱えた組織のほとんどは、現在、その資産を管理し追跡するために紙ベースのシステムを使用している。

資産を適切に管理するには、その資産の状態を時間の経過と共に監視しなければならない。資産管理の判断は、正確な測定値とベンチマークを考慮して行なわれなければならない。今日のネットワーク接続された情報中心の世界では、実際には資産の使用状況を十分に測定することができ、動的（mobile）資産か静的（stationary）資産かに関係なく、ホストコンピューティング装置が、その日々の利用率と実績に関する貴重なデータを提供することができる。このデータは、資産管理プロセスの原料である。

様々なタイプの分散された資産には、断片的な資産管理ストラテジを適用すべきではない。それどころか、多様な資産は、互いに依存していることが多く、組織への収益面での影響を完全に理解できるように全体として管理しなければならない。

この全体論的手法の障害となっているのは、資産の本質的な性質とその資産が使用されている環境である。その理由は、多くの場合、各種資産は、異なるプロトコルでネットワーク接続され、遠隔地にあり、容易にアクセスできないからである。例えば、動的資産の場合には、資産は、ネットワークから切り離され、不特定の期間利用できなくなることが多い。また、そのような動的資産は、最小限の制御しか加えることができないことが多い物理的制約を受けている。

更に、資産が拡散していることは、そのような資産に関するデータも散らばり、分離され個々に独立したデータサイロ、即ちあらゆるタイプのデータベース、スプレッドシート、紙ベースの報告書に埋もれてしまうことを意味する。その結果、ほとんどの組織は、所有する資産を部分的、断片的、且つ不完全にしか把握できないことになる。分離された資産管理は、最適でない間違った分析の原因になり、生産性改善又は資産再利用、戦略的決定、改修、引退などの戦略的決定は言うまでもなく、資産管理、労働計画、部品調達、在庫管理に関する正しい決定を行なう組織の能力を著しく制限する。

資産管理の大部分は、非構造的な資産データから構造化された役立つ情報を導き出すことからなり、その結果、店舗フロアから最上階フロアまで、即ちセンサから役員室まで（Ｓ２Ｂ：sensor-to-boardroom）、組織のあらゆるレベルでの意思決定者は、業務割り当てから資産償却及び再投資計画まで複雑な意志決定を行うことができる。そのような意思決定者による資産データへのアクセスは、固有のフォーマットで特定の時間にされなければならない。資産管理者は、静的なスプレッドシートや紙ファイルで一杯のファイルキャビネットに依存していては、この種のデータの集約、正規化及び配布を組織に提供することはできない。

従って、貴重で役立つ情報へのアクセスは、組織内のデータサイロ間の障壁を破ることによってしか達成できない。この情報統合プロセスによって、新しい総合的な情報が作成され、それに基づいて最終的に資産管理決定が行われる。

情報統合プロセスは、資産管理プロセスにおいて顕著となる多数の要因によって困難になる。第１に、情報量の多さである。現在の研究では、ビジネス関連の情報は、約５０パーセントの平均伸び率で増えており、毎年約１〜２エクサバイト（１０¹⁸）の情報が発生していることが分かっている。

第２に、データの異質性のために、明確に定義されたリレーショナルデータベーステーブル（一般に構造化データと呼ばれる）にレコードが収まらなくなっている。組織はますます、テキスト（電子メールやウェブページ等）、音声（コールセンターログ）、ビデオ等の構造化されていないコンテンツに対処しなければならなくなってきている。

第３に、データのフェデレーションやディストリビューションは、（データウェアハウス内等の）データベースのセットに限定されなくなっており、様々な組織にまたがる可能性のある複数のコンピュータに分散される。更に、（データを所有し制御しそのデータにアクセスする者が形成する）フェデレーションは、一般に分散型データベース技術が対応していない新しい問題である。フェデレーションのシナリオでは、一般に、フルＳＱＬ（構造化照会言語）や他の標準ベース照会言語を前提とすることができない。

第４に、ビジネスインテリジェンスを生成するために、益々複雑な方法でデータを操作し、集約し、変換し、分析することが必要とされる。１９９０年代初頭から中頃のリレーショナルデータベースの成長の大部分は、複雑なＳＱＬクエリーによる決定支援から、オンライン分析処理（ＯＬＡＰ）、データマイニングに至るタスク内のビジネスインテリジェンスによって促進された。

第５に、発生するデータの量が幾何級数的に増加し、またデータソース間の不均衡も幾何級数的に拡大していることが、意思決定者が情報を厳密に調べそれに基づいて行動する能力を妨げている。これは、幾つかのアクションが自動化されるべきであることを示唆している。最終的には、自動化されたビジネスルールが、（全体的又は部分的に自動化することもできる）ビジネスプロセスのきっかけになる。

最近の技術発展と過去の資産管理の分析から得られた結論は、物理的資源から戦略的意思決定及びアクションまで、資産使用状況に関係するあらゆる問題に取り組む包括的で最適なソリューションが得られるパラダイムシフトを可能にする。

実際、低コストのマイクロプロセッサとメモリに高集積化された計算処理能力、無線通信、コンピュータアーキテクチャの絶え間ない改良、小型化の進行、及び制限された環境のためのハイレベルで動的な標準ベースのプログラミング言語の開発により、埋め込み装置はコンピューティング環境の不可欠な部分になってきている。事実、長い間、装置は、低レベルのセンシングやデータ中継に制限されてきており、装置自体ではあまり処理を行っていなかった。これが、ＳＣＡＤＡ（監視制御データ収集システム）アプリケーションの特徴であった。更に、ＳＣＡＤＡを実行するために使用される技術の性質によって、アプリケーションとそれが配備されるハードウェア間の結合が密になり、アプリケーションは、一般に、低レベルの装置固有の機能と強いつながりを持つ静的にコンパイルされた言語で設計されている。低いレベルの実行環境とハードウェアとの強い結合との組み合わせにより、ＳＣＡＤＡアプリケーションは、最小限の機能しかなく、保守しにくく、改良するのがほとんど不可能であった。

将来的には、装置は、データを処理してそのデータを不確定の期間ローカルに記憶できるようになるであろう。それは、ハイレベルで動的なプログラミング言語がアプリケーションとハードウェア間の抽象化層として働き、アプリケーションを装置から独立したものとするからである。その結果、アプリケーションは複雑になるが、新しい機能は、ソフトウェア更新の形で追加され、したがって、ハードウェアの交換や前記ハードウェアへの直接アクセスが不要になる。そのような状況では、大規模に分散された複数の装置に複数のアプリケーションを集約的に配備し維持する能力が必要になる。

装置の普及は、大部分、インターネットや成長著しい無線技術の出現によって最良の形で実現されるネットワーク技術の改善によって可能になる。無線ネットワークは、装置に埋め込まれた分散アプリケーションがどのように相互接続されるかに影響を及ぼすという特徴を有する。実際には、無線ネットワークは、断続的接続性（これは、特に、ある瞬間には無線ネットワークの環境内にあり別の瞬間には切断される動的資産のケースにあてはまる）と変化するトポロジ（特に移動装置のケースでは、無線ネットワーク内の装置が現われたり消えたりすることがある）に特徴がある。また、無線ネットワークのバンド幅は、（有線ネットワークにも影響を及ぼす）ネットワーク上のピアの数とネットワーク使用状況だけでなく、人間による管理が及ばない物理的制約（天候、地理的障害物など）によっても大きく変化することがある。更に、無線ネットワークはしばしば、（数フィートから数百フィートに）有効範囲が制限される。

様々なタイプのネットワークとネットワーキング条件は、設計時に用心しないとアプリケーションのポータビリティと挙動を妨げる可能性がある。更に、多くの点で、ハードウェアとソフトウェア両方の観点からのネットワーク接続性の改善は、アプリケーションの設計と配布に大きな影響を及ぼすことになる。監視制御データ収集（ＳＣＡＤＡ）アプリケーションは、クライアント−サーバモデルを中心に構築されており、集中型設備が、装置との通信リンクを介して取得した生データを記憶する。従って、前記データの処理は集中的に実行される。装置の数が増え、それらの装置から取得するデータの量が相当なレベルになると（よくあるケース）、集中型設備はすぐに壊滅的になる。集中型設備に処理能力を追加すると、追加のコストや管理問題などの更に多くの問題が生じる可能性がある。更に、集中型設備にあまり依存すると、埋め込みアプリケーションがネットワーク障害の影響を受けやすくなり、装置と中央設備の間の接続が断たれた場合に、最終的に貴重なデータが失われる可能性がある。

装置自体（処理能力、記憶容量、高級言語、及びＯＳに依存しない言語）の改良との組み合わせで、新しいネットワーク機能は、（ＳＣＡＤＡアプリケーションによって採用されている）クライアントサーバモデルからピアツーピアモデルへのシフトを可能にする。このシフトによって、アーキテクチャがきわめて分散的で広範囲になり、その結果、装置は、潜在的に多数のネットワークに断続的に接続する半自律的エンティティとして働いて、蓄積データを提供し（一時的に記憶し処理する）、ソフトウェアサービスを他の装置に提供し、例えば通信可能範囲が制限された場合に装置間の中継器として働くようになる。更に、装置の自律性は、非同期通信によって改善され、メッセージの受信者は、送信者にすぐ応答しなくてもよくなる。非同期モデルは送信者と受信者を切り離し、それにより、ネットワーク障害の場合の高い信頼性（ネットワークが使用可能になったときに応答を送ることができる）と、スケーラビリティが得られる（処理するのに十分な資源が得られるまで装置が要求をローカルに記憶することができる）。しかし、同期通信を使用することが望ましい場合や必要な場合もある（例えば、データストリーミングの場合）。

更に、一般に従来のＳＣＡＤＡシステムに見られるような静的アドレス指定の使用は、（参加者が必ずしも事前に分かっていない）アドホックネットワークの作成を許可せず、通信者を互いに結合する。現在では、分散型コンピューティングフレームワークは、静的アドレス指定を回避するメカニズムを提供している。このメカニズムは、しばしば、マルチキャスト、ネーミングサービス、又はいわゆる「ランデブー」に依存し、組み合わせて使用されることが多い。本発明は、ネットワーク参加者が、互いに前もって知ることなくネットワーク内に現れ且つ他のノードと動的に通信することを可能にする。

埋め込みアプリケーションの出現と装置の急増は、可能性をもたらすが、リモート管理のような新しい問題を引き起こす。アプリケーション管理は、アプリケーションのライフサイクルに関係する様々なタスクを含む。アプリケーションが提供されると、それを配備しなければならない。配備後に、（適切な動作を保証するために）そのアプリケーションを監視しなければならない。（特定の状態に応じて）人間の介在によって何らかのアクションをとらなければならないことがあり、これは、アプリケーションが最小限の管理インタフェースを提供しなければならないことを示唆している。最終的に、配備されたアプリケーションの新しいバージョンが使用可能にされ、その後で、従来のバージョンを更新しなければならない。個人用デスクトップコンピュータでは、アプリケーションの更新は重要でないように見える。しかし、そのタスクを複数のリモート装置上で実行しなければならないときは、適切なインフラストラクチャがないと実現できない。

先行技術
本発明は、ＳＣＡＤＡ（監視制御及びデータ収集）システムから得た教訓に基づく。ＳＣＡＤＡシステムの起源は、１９６０年代まで遡ることができる。その当時、このシステムは、１つのマスタ局と１つのリモート局間で入出力伝送を行った。マスタ局は、テレメトリネットワークを介してデータを受け取り、次にそのデータをメインフレームコンピュータ上に記憶した。ＳＣＡＤＡシステムは、最初の単純なアーキテクチャ（「局」を２つしか含まない）から、複数のリモートサイトを含むより分散したアーキテクチャに発展した。

現在、代表的なＳＣＡＤＡシステムは、マスタ端末ユニット（ＭＴＵ）、リモート端末ユニット（ＲＴＵ）、通信機器、及びＳＣＡＤＡソフトウェアの４つの主構成要素を含む。ＭＴＵは、人間と機械間のインタフェースを提供し、中央制御ポイントの役割をする。リモートサイトに配置されたＲＴＵは、現場にある装置からデータを収集し、ＭＴＵから出るコマンドを待つ。通信機器は、ＲＴＵとＭＴＵ間の通信リンクを可能にするために使用される。ＳＣＡＤＡの分野では、システムが全体として適切に機能するために、中断のない双方向ネットワーク通信が必要である。最終的に、ＳＣＡＤＡソフトウェアは、ＳＣＡＤＡシステムのアプリケーション全体を実行する。

ＳＣＡＤＡシステムのアーキテクチャは、高度に集中化されており、ＲＴＵは、それらがインストールされた資産を監視し事前に定義された間隔で状態データを送信する以外にはほとんど作業を行わない装置を制御する。ＲＴＵ自体は、そのＭＴＵにきわめて依存している。トポロジ全体は、ネットワーク障害の影響を受けやすいので、装置とＲＴＵ間或いはＲＴＵとＭＴＵ間の通信リンクが断たれると、システムは期待通りに動作することができない。

近年、ＳＣＡＤＡシステムは、ネットワークキングの進歩から恩恵を受けている。現在、通信リンクは、一般に、規格に基づくオープンプロトコル（ＴＣＰ／ＩＰ等）とデータ表現形式（ＸＭＬ）に従っている。また、無線ネットワークは、ＳＣＡＤＡシステムをより普及させた。第二世代のＳＣＡＤＡは、インターネット関連技術と無線技術を統合している。特許文献１（Howardらによる「Web-based data-mining and location data reporting and system」）は、そのようなシステムを、車両郡の管理の状況、すなわちリモート資産が、装置データが記憶されるデータベースを特徴とする無線対応の中央「ゲートウェイ」に接続する状況で説明している。このゲートウェイは、データを、ウェブページとして提供される「報告システム」によってユーザに提示する。報告システムは、資産ごとにレポートを作成する。このシステムは、ユーザやゲートウェイデータベースとの対話を管理するために、様々なインターネット及びデータベース技術（ＡＳＰ、ＸＭＬ、ＸＳＬ、ＤＨＴＭＬ等）を使用する。この特許は、情報統合の問題に取り組んでいない。即ち、ユーザにはゲートウェイデータベースに含まれる装置データが提供され、前記データを異種のデータソースからの情報と統合する簡潔なアーキテクチャついては述べていない。本質的には、このシステムは、第一世代ＳＣＡＤＡシステムの方針に沿って設計されている。その方針とは、リモート資産が単に生データの発信元として働く高度に集中されたアーキテクチャであり、処理作業の大部分が、中央「ゲートウェイ」によって実行されるものである。

別の特許、特許文献２（Hansenによる「Reporting the state of an apparatus to a remote computer」）は、「機器に埋め込まれたデバイス」とリモートコンピュータ間の通信を保証するために２つの特定のインターネット技術を使用するＳＣＡＤＡシステムについて述べている。その２つのインターネット技術とは、電子メールメッセージを送信するためにインターネット上で使用されるプロトコルであるＳＭＴＰ（簡易メール転送プロトコル）と、技術に依存しないメッセージ交換のために多くの産業全体にわたって広く採用されているオープンな汎用データ表現形式であるＸＭＬ（拡張可能マークアップ言語）である。この特許では、ＳＭＴＰは、資産（機器）とリモートコンピュータ間のメッセージ交換プロトコルとして使用される。メッセージ内容は、ＸＭＬを使ってエンコードされる。

前述の特許で述べられているシステムは、資産とリモートコンピュータ（ＳＣＡＤＡ用語ではＭＴＵ）間の直接通信リンクを間接リンクと置き換えている。その理由は、資産からリモートコンピュータへのメッセージがＳＭＴＰを使って送られるからある。ＳＭＴＰメールサーバが、メッセージを受信してそのメッセージが当事者によって受け取られるまで記憶するために使用される。これと同じことは、逆方向（リモートコンピュータから資産）に送られるメッセージにも当てはまる。この手法は、メッセージの送信者を受信者から切り離すという長所を有する。しかしながら、特許文献３で述べられているシステムは、情報統合の問題とその解決策についてはきちんと言及も検討もしていない。更に、この特許は、メールサーバが利用できなくなった場合の代替案について述べておらず、またそのような事象にシステムが全体としてどのように応答するかも述べていない。従って、その時点でデータが単純に失われたと仮定しなければならない。同じ理由で、この特許は、要求されていない電子メールメッセージをどのように扱うかを詳しく調べていない。最後に、このシステムは、あるレベルの分離を特徴とし、このアーキテクチャは全体として高度に集中されたままであり、資産での処理は、（電子メールメッセージの形の）状態データの生成に限られる。

更に、メールサーバを使用すると、アドレス指定とネットワーク抽象化の問題が生じる。従って、第１に、所定の当事者にメッセージを送信するには、あらかじめそのアドレスを知らなければならない。現在、ロバスト分散型コンピューティングフレームワークは、実行時に指定される基準に基づくアドレスの動的発見を可能にする。従って、そのようなフレームワークの状況では、通信者達は、互いのアドレスをあらかじめ知るように適合されていない。第２に、固有のアドレスタイプ（このケースでは電子メールアドレス）の使用は、アプリケーションが特定の通信手段に束縛されてしまう弱点がある。このため、アプリケーションは、選択された通信技術の弱点、制限及び無能力に大きく左右されることになる。

この解決策に関して、ＩＢＭは、「Integrating monitoring and telemetry devices as part of enterprise information resources」と題する文書を作成している（２００２年３月）。この文書は、「徹底した業務統合」について詳しく記載されており、業務統合の範囲の一端を表わすものとして「テレメトリ装置」について述べている。前記特許の１つに記載されているものと同じように、記載された解決策は、公開（publish）／加入（subscribe）メッセージキューによってサポートされた非同期通信モデルに依存する。メッセージキューは、送信者（公開者）と加入者（受信者）の間の中央仲介者の役割をする。メッセージキューは、非同期メッセージ処理を専門に行うサーバソフトウェアであり、そのようなタスクを処理するにはメールサーバより良い選択である。その理由は、ほとんどのメッセージキューは、非要求メッセージに関する規定（一般にタイムアウトで処理する）と（追加の負荷に対応すると共にサーバクラッシュから保護するための）冗長性に対応しているからである。ＩＢＭによって提案された解決策では、メッセージは、現在至るところにあるＸＭＬではなく、ＩＢＭが特許権を持つＭＱＩｓｄｐプロトコルを使ってエンコードされる。

以上述べた全てのケースにおいて、まだ取り組まれていない幾つかの問題が残されている。第１に、いずれの解決策も多数の装置に遠隔的に分散されたアプリケーションの管理について言及していない。これは、大規模なＳＣＡＤＡソリューションの実現の大きな障害になっている。第２に、いずれの解決策も第一世代ＳＣＡＤＡシステムの計算モデルを無駄に使用しており、データ処理は主に、集中化されたサーバファームで行われる（装置は状態データを送信するだけである）。第３に、非同期通信に依存する解決策は、介在機構（メールサーバ又はメッセージキュー）、直接の二地点間リンクを禁止する手法、及び非同期リンクの使用を強制する。これは、制約が多すぎることを示している。最後に、いずれの解決策も、複雑な情報統合問題に（全くではないにしても）ほんのわずかしか取り組んでいない。

有効な資産管理ソリューションを提供するためには、全体として４つの大きな問題に取り組まなければならない。それは、１）様々なタイプの資産が分離され分散されていること、２）資産に関する正確で適時なデータの不足、３）資産管理において役員による視認性や関与が不適切であること、及び４）監視資産の数が増えたときの資産管理ソリューションの規模の拡大と維持の難しさである。

先行技術は、そのような全体的な解決策を提示していない。従って、現在の欠点を克服する資産管理システムが必要とされており、本発明は、複数の装置に遠隔的に分散されたアプリケーションを管理できるようにするという課題に取り組む。これは、大規模なＳＣＡＤＡソリューションの実現の大きな障害の１つになっている。更に、本発明は、様々なタイプのネットワークを介してあらゆる資産からありのままのタイムリーなデータ収集を行うことを特徴とする。更に、本発明は、リモート資産から取得したデータを多数の異種データソースからの他のデータと実時間で統合することを特徴とする。これにより、組織の資産使用状況を戦略的に把握することができる。
米国特許第６，７５７，７１４号 米国特許第６，７５７，７１４号 米国特許第６，７５７，７１４号

本発明は、装置内のデータを処理して、そのデータを異種の企業情報システム及びビジネスプロセスと統合するリモートアプリケーションを管理する方法及びシステムを提供する。

本発明の実施形態は、装置、埋め込みアプリケーション、通信手段、包括的分散データ処理システムを実現する中央データ処理及び情報統合ソフトウェアを含む。

このシステムは、装置内に埋め込まれたアプリケーションを遠隔的に配備し、実行し、監視し、更新することを可能にする。このアプリケーションは、資産に関するデータを取得し、記憶し、処理する。処理されたデータは、最終的に、中央データ処理インフラストラクチャに送信される。埋め込みアプリケーションは、ネットワーク抽象化層を介して中央処理インフラストラクチャと通信する。このネットワーク抽象化層は、アプリケーションをネットワーク固有の細部から隠す。また、ネットワーク抽象化層は、埋め込みアプリケーションと遠隔的に通信するために使用される。ネットワーク抽象化層は、基本的なメッセージングプリミティブを提供し最小共通項をサポートするアブストラクションの後ろにネットワークの細部を隠すことによって、ネットワークの制限と相違を考慮する。従って、アプリケーションは、装置間だけでなくネットワーク間で移植可能になる。

中央データ処理インフラストラクチャは、非同期メッセージングサーバソフトウェアを介して装置データを受け取る。本発明が使用される情況では、このデータは、データキャッシュに保存されてそこでドメインに固有の更なる処理を待つ。

更に、システムは、集約された合成情報を作成するために、キャッシュ内のデータを異種データソースから抽出したデータと実時間で統合するために使用される情報統合構成要素を含む。統合構成要素の使用は、ドメイン依存であり、アプリケーションにより異なる。

本発明は、また、データを処理しそのデータを異種企業情報システム及びビジネスプロセスと統合するリモートアプリケーションを管理する方法を対象とする。この方法は、装置内の埋め込みアプリケーションを配備し、実行し、監視し、更新することを含む。システム内のアプリケーション間の通信を保証するために抽象化層が使用される。埋め込みアプリケーションから受け取って組み合わせたデータを、異種データソースから取り出した情報と統合して、組織の資産を総合的に把握すると共に自動ビジネスプロセスを起動するために情報統合フレームワークが使用される。

本発明の目的は、大規模な分散されたリモートの資産の管理を可能にすることである。

本発明の別の目的は、資産管理ソリューションの信頼性を高めて、資産使用状況に関する正確で適時なデータを提供することである。

本発明の更に他の目的は、分離されたデータサイロ間の障壁を情報統合によって破壊することであり、資産から得られたデータは、組織の内外の多数の異種ソースから収集されたデータと一体化される。

本発明の別の目的は、最初に資産と関連した実測値を財務、会計、その他の運用データにリンクする総合的ビューを管理者に提示することによって、資産の使用に関連する意志決定を容易にすることである。

本発明の更に別の目的は、ピアツーピア方式に遠隔的にアクセス可能なアドホックソフトウェアサービスの公開を可能にすることである。

本発明は、従来のシステムと比べて多数の利点を提供する。第１に、装置自体での人間の介入なしに且つオペレーティングシステムプロセスを終了させることなく、装置上のアプリケーションを動的且つ遠隔的に監視し、管理し、更新することを可能にする。最終結果は、装置に物理的にアクセスする必要がないことであり、これは、装置が遠隔で及び/又は多数のときの必要条件である。

本発明の別の利点は、ネットワークの性能とタイプの点での最小共通項を尊重する共通のネットワーク抽象化によってネットワーク独立性が高められることである。これにより、アプリケーションが様々なネットワーク間で移植可能になる。

本発明の更に別の利点は、（より一般的なクライアントサーバモデルを使用するのではなく）ピアツーピアトポロジを促進して、ノード間の直接ネットワークリンクを可能にすることである。装置は、中央サーバ（或いは、ＭＴＵ又は「リモートコンピュータ」）や他の装置との間で要求を送受信することができる。

本発明の更に他の利点は、ハイレベルなプログラミング言語とマルチプラットホーム実行環境の使用によって、アプリケーションが配備されたハードウェアからのアプリケーションの独立性を高めることである。これにより、所定のアプリケーションが、複数のタイプの装置にデプロイ可能になる。

更に、本発明は、装置によって提供される処理能力と記憶容量の使用を最大にする。この手法は、ピアツーピアの利点と組み合わせて、スケーラビリティとネットワーク障害に対する回復力を高める。全体的な作業負荷は、装置と中央サーバ（或いは、ＭＴＵ又は「リモートコンピュータ」）の間で共有され、装置は、互いにサービスを提供することができ、また、ネットワーク接続が利用できないときに自律的に動作することができる。

本発明の更に別の利点は、装置で生成されたデータの異種情報システムとの統合を正式にサポートし、戦略的意志決定を容易にし、ビジネスプロセスを引き起こす合成情報が得られることである。

以下の詳細な説明は、例示によるものであり、本発明をその例示のみに限定することを意図するものではなく、添付図面と関連させることにより最もよく理解される。

本発明のシステム
本発明に基づくシステムは、まず、様々なタイプの資産に導入された（又は、その資産と通信する）装置から成る。これらの装置は、資産に関するデータを取得し、記憶し、処理する埋め込みアプリケーションのホストとなり、前記データを中央処理インフラストラクチャに送信する。中央処理インフラストラクチャは、データをキャッシュに入れ、そのデータを様々な異種の情報システムからのデータと実時間で統合できるようにする。また、統合された情報は、自動化されたアクションとビジネスプロセスを起動するために使用される。

より正確には、本発明に基づくシステムは、最初に、様々な資産内に設けられるか又はそのような資産と通信する装置内に遠隔的に配備される埋め込みアプリケーションから成る。本発明の情況では、この装置は、計算能力、記憶容量及びネットワーク機能を特徴とする自律装置である。アプリケーション自体は、仮想マシン（ＶＭ）内で実行されるドメイン固有コンピュータプログラムである。ＶＭは、プログラム命令をネイティブコードに変換することによってハードウェア（主に、ＣＰＵ、メモリ、入出力）とオペレーティングシステム固有の細部からアプリケーションを分離するものである。ネイティブコードは、ＣＰＵによって直接実行されるコマンドから成り、これにより、アプリケーションがハードウェアやオペレーティングシステムに依存しないものとなる。各装置は、１つのオペレーティングシステムと１つのＶＭを備え、ＶＭのインスタンスは、オペレーティングシステムプロセス内で実行される。ＶＭインスタンスは、プロセスの始動と停止でそれぞれ始まり終了する。

このアーキテクチャは、多数の埋め込みアプリケーションのうちの１つのライフサイクルを管理する基本ソフトウェアエージェントであるマイクロカーネルを提供し、マイクロカーネル内で前記アプリケーションはホットデプロイ（hot-deploy）される。装置が配備される前に、各装置に１つのマイクロカーネルが物理的に導入される。マイクロカーネルは、装置始動時にＶＭプロセス（又はインスタンス）内で始まり、装置停止時に終了する（図１と図２を参照）。

リモートアプリケーションの更新は、静的コンパイルを必要としない動的でハイレベルなマルチプラットホーム言語の出現によって可能になった。リモート管理の視点からは、そのような言語は、ソフトウェアプロセスを実際に終了することなくアプリケーションを動的に更新することを可能にし、この機能はしばしば「ホットデプロイメント（hot deployment）」と呼ばれる。これは、静的にコンパイルされた言語が使用されホットデプロイメントを禁止する従来の手法と大きく異なる。そのような環境では、アプリケーションを更新しなければならない場合、装置自体において人間が介入しなければならない。これは、当然ながら、アプリケーションが遠隔的に大規模に配備される状態では管理しにくくなる。

マイクロカーネルは、アプリケーションのドメインに関しては寛容なままである。マイクロカーネルとその埋め込みアプリケーションは、事前定義された契約によって拘束され、アプリケーションは、マイクロカーネルが対話するライフサイクルインタフェースを提供する。ライフサイクルは、アプリケーションのデプロイメントとアンデプロイメントならびに始動と停止に関係する。同様に、マイクロカーネルは、埋め込みアプリケーションがそれらの実行中に使用できるインタフェースを有する。このインタフェースは、アプリケーションが、マイクロカーネル内で起きている特定のイベント（例えば、他のアプリケーションが配備された）に基づいて通知され、そのようなイベントに基づいて動作することを可能にする（所定の埋め込みアプリケーションは、別の埋め込みアプリケーションのサービスを必要とすることがある）。更に、幾つかのアプリケーションは、マイクロカーネルの拡張機構として設計されることがあり、その場合、アプリケーションは、低レベルのマイクロカーネル機能にアクセスする必要がある

埋め込みアプリケーション並びに本発明の情況における他のタイプの特定のアプリケーションは、「サービス」と呼ばれる機能的インタフェースによって、他のエンティティがその機能を使用できるようにする。所定のサービスには多数のインプリメンテーションが存在する。（サービスを使用する）クライアントソフトウェアは、サービスインタフェースだけを処理し、従ってサービスのインプリメンテーションの詳細を知らない。また、クライアントソフトウェアは、サービスを実施することができ、したがって他のクライアントソフトウェアによっても使用できる。本発明は、サービスをネットワーク上で公開することを可能にし、従ってそのようなサービスは遠隔的にアクセス可能になる。

更に、本発明のシステムは、リモート装置内のマイクロカーネルとアプリケーションを制御するために使用される管理インフラストラクチャから成る。リモート管理は、ユーザとプログラミングインタフェースの形でそれぞれ必要なアクセス権を有するユーザとアプリケーションに使用可能になる。マイクロカーネルは、リモート管理インフラストラクチャを介してアクセス可能な管理インタフェースを提供し、埋め込みアプリケーションのデプロイメントとアンデプロイメントを可能し、またマイクロカーネルインスタンスをその実行中に監視することを可能にする。更に、アプリケーション自体は、ドメイン固有管理インタフェースを提供することができる。リモート管理インフラストラクチャは、複数のマイクロカーネル又はアプリケーション上で同時に分散管理動作を実行することを可能にする。

管理インフラストラクチャの一部として、新しい埋め込みアプリケーション又は既存の埋め込みアプリケーションの新バージョンを公開することができるアプリケーション更新モジュールが提供される。この更新モジュールは、埋め込みアプリケーションのデプロイメントと更新を遠隔的に制御することを可能にし、大規模なデプロイメントを可能にするための重要な要素である。第１に、アプリケーション更新モジュールは、サーバ部分（更新サーバ）を含み、このサーバ部分は、実際には、１組のウェブページとして提供されたウェブアプリケーションと、新しいアプリケーションとアプリケーション更新を記憶するために使用されるデータベースと対話する１組のプログラム命令からなり、新しいアプリケーション及びアプリケーション更新自体は、埋め込みアプリケーションインスタンスを作成するために必要な全てのリソース（ファイルと実行可能コード）を保持するアーカイブファイルからなる。第２に、更新モジュールは、マイクロカーネルが装置に導入されたときにマイクロカーネル内に配備される埋め込みアプリケーションによって実施されるクライアント部分（更新クライアント）を含む。更新クライアントは、新しいアプリケーション又はアプリケーション更新を検出するために更新サーバを断続的にポーリングするように設計されている。これはまた、新しいアプリケーション又は更新に対応するアーカイブファイルをマイクロカーネル下にダウンロードする役割を持つ。ダウンロードが完了した後で、マイクロカーネルに通知され、新しいアプリケーション又は更新の有効なホットデプロイメントが実行される（図３を参照）。

更に、本発明のシステムは、データ処理インフラストラクチャを含む。最初に、データ処理インフラストラクチャは、装置が生成したデータを事前定義された手順でデータベースに記憶し取り出す分散アプリケーションと共に１つのデータベース又は１組のデータベースを含むデータキャッシュからなる。処理インフラストラクチャは、また、データキャッシュからのデータを複数の異種情報システムからのデータと統合することを可能にする情報統合フレームワークを利用する（図４を参照）。

情報統合フレームワークは、ＸＭＬとＸＱｕｅｒｙに依存する。このフレームワークの情況では、異種データソースもデータキャッシュも、ＸＭＬ文書のソース及び／又はＸＱｕｅｒｙ対応データソースとして表わされる。そのようなソースは、それぞれＸＭＬソースとＸＱｕｅｒｙソースと名付けられる。ＸＭＬソースの実施形態は、ネイティブデータソースを直接抽出することもでき、或いは他のＸＭＬ、ＸＱｕｅｒｙ及びネイティブデータソースの仮想構成物でもよい。この手法は、Ｗ３ＣのＸＱｕｅｒｙ言語を使用した基礎（underlying）データソースの照会をサポートするＸＱｕｅｒｙソースの実施形態にも当てはまる。情報統合フレームワークは、特定のソフトウェアによって使用することができ、このソフトウェアは、ドメイン固有タスクを実行すると共に、ＸＭＬ及びＸＱｕｅｒｙソースと対話して必要なデータを抽出するプログラム命令を含む。そのようなソフトウェアアプリケーションは、主に、スコアカード、ダッシュボード及びレポートの形で合成情報をエンドユーザに提示するように意図されている。更に、フレームワークは、複雑な自動化又は部分自動化されたビジネスプロセスの一部としてその実行を配置できるウェブサービスの開発を可能にする（図５を参照）。

相互運用の視点から見ると、システムの構成要素は、ネットワーキングの細部を単一で共通の同期と非同期両方のネットワーク抽象化の後ろに隠す通信インフラストラクチャによって互いに関連づけられる。このネットワーク抽象化層（又は、ＮＡＬ）は、他の構成要素との通信を必要とするシステムの全ての構成要素によって直接扱われる。ＮＡＬは、また、アプリケーションサービスの公開（publishing）、発見（discovery）及び探索（lookup）をサポートし、公開は、ネットワーク上の所定のサービスインスタンスの存在を同報通信することからなり（これは、一般にサービス開始時に行われる）、発見は、新しいサービス同報通信をリッスンするアクションであり、探索は、所定のサービスを要求することから成る。公開、発見及び探索は、最終的にクライアントアプリケーションとサービスインスタンスの間の同期通信を可能にするために使用され、クライアントアプリケーションが首尾よくサービスを探索したら、そのサービス機能を使用することができる（図６を参照）。

ＮＡＬの特定の実施形態は、非同期通信に対応していなければならない。そのような実施形態は、メッセージを受け取るサーバソフトウェアの形とすることができ、各メッセージを当事者に送るか、又は当事者が関心のあるメッセージを取り出すまでメッセージを記憶する。別の実施形態は、サーバソフトウェアの仲介のない２つの当事者間の直接非同期通信リンクの形である。メッセージは、メタ情報と生コンテンツ（raw content）から成る。メタ情報は、特に、メッセージが送られる当事者の識別子を含む。生コンテンツは、本質的に、受信者が期待するデータである。ＮＡＬインプリメンテーションによって提供される非同期通信は、その通信が、専用のメッセージキューによって仲介されるかどうかに関係なく、メッセージを適切な届け先にルーティングする役割をする（ピアツーピアの場合）。

ＮＡＬは、可能性のある実施形態が必要とする基本（underlying）ネットワークプロトコルのタイプを制限しない。更に、ＮＡＬの実施形態は、（クライアントアプリケーションとサービスインスタンス間の）同期通信と同様に、サービスの公開、発見及び探索をサポートしなければならない。

ＮＡＬの特定のインプリメンテーションは、インプリメンテーションに固有の初期設定パラメータをＮＡＬ「ファクトリ」に渡すことによって、実行時に取得される。ファクトリは、指定されたパラメータに従ってＮＡＬ実施態様を作成する。従って、クライアントアプリケーションは、所定のＮＡＬインプリメンテーションに静的に結合されることは無く（コンパイル時）、どのインプリメンテーションが使用されるかは、一般にクライアント構成の一部として提供される指定パラメータに従って実行時に決定される。

ＮＡＬを使用することにより、任意のタイプのアプリケーションをネットワーク内の任意のノードに自由に接続することができる。より正確には、ＮＡＬは、データ処理インフラストラクチャと埋め込みアプリケーション間、或いは埋め込みアプリケーション間の通信に使用しなければならいことはない。例えば、所定のドメイン固有クライアントアプリケーションは、埋め込みアプリケーションに接続してその機能を直接利用することができる。そのような１つの共用使用は、埋め込みアプリケーションがデータベースにローカルに記憶するデータを読み出すことである。

本発明の方法
本発明によれば、実施形態は、一般に、現場で配備された資産に導入された装置から成る。マイクロカーネルが、各装置に導入され、埋め込みアプリケーションをホストするように設計されており、この埋め込みアプリケーションが、対応する資産に関するデータを収集し、処理し、記憶する。一方、ある設備内では、埋め込みアプリケーションから出されたデータを受け取るためにメッセージサーバソフトウェアが設けられる。データは、ＮＡＬによって抽象化された電気通信リンクによって受け取られ、データベースに保存される。設備内で、コンピュータには、データベースから資産データを抽出し、その資産データを異種の情報システムからの他のデータと統合して集約情報を作成する情報統合アプリケーションが設けられる。集約情報がどのように提示されどのように使用されるかは、アプリケーション固有である。従って、ウェブブラウザと他のアプリケーションは、情報をウェブサービスの形で使用することができる。他のそのようなアプリケーションは、それらが使用できる情報に基づいてビジネスプロセスを自動的に実行することができる。

より具体的には、本発明の実施形態は、最初に、現場の所定の資産に装置を導入することから成る。装置を導入する前に、各装置に、マイクロカーネルと共に仮想マシンが導入される。マイクロカーネルソフトウェアは、そのインスタンスが装置始動時に自動的に起動するように構成される。更に、マイクロカーネルは、デフォルトで更新クライアントアプリケーションにフィックスされる。各マイクロカーネルには一連の文字の形の識別子が与えられる。識別子は、名前によって識別された事前定義された論理装置ドメインの範囲内で一意でなければならない。装置ドメインは、管理しやすいようにグループ化された１組の装置である。従って、識別子は、本質的に、所定の論理ドメイン内にあるマイクロカーネルを識別するだけでなく装置も識別する。

マイクロカーネルは、アプリケーションのための容器としての役割を厳密に果たさなければならない。これらのアプリケーションは、マイクロカーネルに静的に結合されるのではなく、実行時にマイクロカーネルに配備される。マイクロカーネルにアプリケーションを配備する段階は、そのようなアプリケーションをネットワークによってマイクロカーネルにアップロードする段階から成る。従って、そのようなデプロイメントを遠隔的に実行するには、ネットワーク接続が必要である。アプリケーションデプロイメントがマイクロカーネルに達すると、そのマイクロカーネルがインプロセスで対応するアプリケーションを開始する。

マイクロカーネルは、構成ファイルによって構成される。ファイルの内容は、マイクロカーネル始動時に処理される。構成パラメータは、ＮＡＬファクトリに渡されるネットワーク関連パラメータの他に、マイクロカーネルの割り当てられた固有の識別子とドメイン名からなる。ファクトリは、特定のＮＡＬインプリメンテーションの形で、ネットワーク接続性を得るためにマイクロカーネルによって使用される。マイクロカーネルは、ＮＡＬを使用してその存在をネットワークに公開する。更に、マイクロカーネルはＮＡＬに加入して、ネットワーク内の他のノードから同報通信を受け取る。このように、全てのマイクロカーネルは、ドメイン内の他のマイクロカーネルの存在を互いに知ることが可能となっている（図７を参照）。

そのような同報通信は、やはりＮＡＬインプリメンテーションを使用して、現れたマイクロカーネル（従って、装置）を検出するために、管理インフラストラクチャによって同じように使用される。管理インフラストラクチャは、装置をドメイン単位で編成する。マイクロカーネル（及び埋め込みアプリケーション）は、ネットワークに接続された後で、管理インフラストラクチャの一部として提供されるユーザインタフェースによって遠隔的に管理することができる。

管理ユーザインタフェース（又は、管理コンソール）は、リモートデプロイメント専用の部分を有する。コンソールのこの部分は、各マイクロカーネル内の更新クライアントアプリケーションと対話を可能にする。従って、コンソールのその部分により、管理者は、全て又は所定のマイクロカーネルインスタンス内に新しいアプリケーションを遠隔的に配備することができる。

新しいアプリケーション又はアプリケーション更新を配備するために、管理インフラストラクチャの一部である更新サーバ内に、対応するアーカイブファイルをアップロードしなければならない。これも管理コンソールを介して行われる。アプリケーションアーカイブには、アプリケーション名とバージョン番号が割り当てられる。この情報は、やはりアーカイブファイルの一部である「周知」のファイル内に含まれる。更新サーバ内で、アーカイブファイルは、論理名によって組織化され、各論理アプリケーション名の下にバージョン番号によって順序付けされる。更新サーバ内にアプリケーションアーカイブをアップロードした後、既存のマイクロカーネルに対する管理者は、それを仲間に入れる。

デプロイメント手順の残りの部分は、図８に示したような「デプロイメントプロトコル」から成る。アプリケーションアーカイブとマイクロカーネルマッピングの作成と確認が終わった後、更新サーバは、目標とするマイクロカーネルに対応する全ての更新クライアントに、新しいアプリケーションや既存のアプリケーションの新バージョンがいつでもダウンロードできる状態になっていることを通知する（図８を参照）。

そのような通知が行われたときに幾つかの更新クライアントがネットワークから切り離されている可能性もある。この問題を回避する方法として、更新クライアントは、ネットワークに接続したときに使用可能なアプリケーションダウンロードを照会するように要求される。また、新しいダウンロードをチェックする間隔を更新クライアントに設定することもできる。

新しいアプリケーションダウンロードが使用可能になったことを通知されるか或いは検出したとき、更新クライアントは、更新サーバから実際のアーカイブをダウンロードする責任がある。デプロイメントプロトコルの一部として、更新クライアントは、デプロイメント手順の成功又は失敗を更新サーバに通知するために後で使用される固有のデプロイメント識別子を与えられる。更新クライアントは、デプロイメントアーカイブを受け取ると、それをマイクロカーネル下の事前定義されたディレクトリにコピーする。ダウンロードが完了したら、更新クライアントは、それが埋め込まれているマイクロカーネルと対話してデプロイメント手順を完了する。手順の残りの部分は、最初に、更新クライアントアプリケーションが新しいダウンロードをマイクロカーネルに通知することから成る。次に、マイクロカーネルは、ダウンロードしたアーカイブの内容を確認し、（バージョン番号とアプリケーション名を比較することによって）そのアーカイブが新バージョンからなるか、配備済みのアプリケーションの新しいバージョンからなるか、配備済みのアプリケーションの前又は現在のバージョンに対応しているかどうかを判定する。第１のケースでは、新しいアプリケーションは、マイクロカーネル内に単純に配備され、第２のケースでは、既存のアプリケーションが終了されてその場所に新バージョンが配備され、第３のケースでは、配備が中止されエラーが生成される。手順のこの部分が完了したら、制御は更新クライアントに戻り、なんらかの理由で配備を行うことができなかった場合には、対応するエラーが更新クライアントに戻される。デプロイメントプロトコルの最後の段階として、更新クライアントは、更新サーバに、配備が失敗したか成功したかを通知する（マイクロカーネル識別子とドメイン名、並びにデプロイメント識別子と、ある場合には生成されたエラーに関する情報をサーバに提供する）。

埋め込みアプリケーションは、一般に、導入される資産に関するデータを収集するように設計されている。次に、そのようなデータは、中央データ処理インフラストラクチャに中継される。本発明の情況では、埋め込みアプリケーションは、処理能力、メモリ、記憶容量等、それらがインストールされる装置のリソースを活用する。埋め込みアプリケーションは、データ処理インフラストラクチャの負担を軽減するためにそのようなリソースの使用量を最大にし、埋め込みアプリケーションは、ネットワークによって生データを絶え間なく送るのではなく、前記データをローカルに処理し、その記憶容量を使用して、そのデータをデータ処理インフラストラクチャに送信できるようになるまで処理段階から得たデータを保存する。従って、本発明の情況で開発された埋め込みアプリケーションは、長い期間にわたって（ネットワークから切り離されて）自律的に動作することができる。更に、埋め込みアプリケーションは、ＮＡＬを介してネットワーク上で公開することができる特定のサービスを実施することができる。また、埋め込みアプリケーションは、他のそのようなサービスをそれを実行する情況で利用することができる。

埋め込みアプリケーションは、蓄積されあらかじめ処理されたデータを送信する準備ができると、ＮＡＬに接続し、そのデータをデータ処理インフラストラクチャに非同期的に送信する。送信されるメッセージは、送信するデータ、並びにデータが生じる装置に対応する識別子と及びドメイン名を保持する。データが送信される形式はアプリケーション固有であり、本発明は、データ形式を想定しない。更に、データが大量にある状況では、送信手順もアプリケーションに任される（図９を参照）。

処理インフラストラクチャにデータを送信するとき、通信は、非同期メッセージング中間物（メッセージキュー等）によって仲介される。埋め込みアプリケーションとデータ処理インフラストラクチャ間を結合するそのような中間物を回避できるため、埋め込みアプリケーションは、そのデータを、データを受け取る受信者を想定せずに送信する。更に、そのようなデータがアプリケーション固有なので、（埋め込みアプリケーションに対して）統合範囲（spectrum）の他端を表わすデータ処理アプリケーションはデータ処理インフラストラクチャを使用しなければならない。従来のＳＣＡＤＡアーキテクチャでは、データ処理ソフトウェアは、一般に、埋め込みアプリケーションから送られる生データを受け取り、それをデータベースに入れる。このデータベース内で、生データは更なる処理を待つ。その処理は、通常、非同期的に行われ、この処理によって他のデータもデータベースに入れられ、このデータベース内において、該他のデータが組織内のアプリケーションに使用可能とされる。

本発明の情況では、データ処理アプリケーションは、受信データが処理済みであるため、その仕事量が大幅に減少する。これにより、データ処理フローの段階全体がなくなり、複雑さ、リソース消費（処理能力、記憶空間、バンド幅）、及び最終的にはコストと保守が減少する。

場合によっては、いくつかの装置（テレセンシングの場合によく遭遇する装置など）は、本発明の一部として言及されている仮想マシンや全てのインフラストラクチャ（マイクロカーネル、埋め込みアプリケーション）の導入を許可しないことがある。そのような場合は、「ハブ」が、そのような「マイクロデバイス」と（本発明の一部として詳述されているような）アーキテクチャの他の構成要素間の中間物の役割をする。ハブの設置は、最初に、ＶＭとマイクロカーネルが導入されハブを具体化する装置を設けることから成る。マイクロカーネルは、やはりハブ装置に導入されたプロキシサーバと通信するアプリケーションを埋め込む。プロキシサーバは、特定の組のマイクロデバイスと、前記マイクロデバイスが使用する固有のプロトコルで通信し、そのような装置とハブの埋め込みアプリケーション間のブリッジとして働く。この構成は、従来のＳＣＡＤＡシステムのＲＴＵを思い出させるが、ハブは、限られた性能しかなく、本発明によって述べられているようなソフトウェアインフラストラクチャをサポートしていない装置とのリモート通信を可能にする（図１０を参照）

装置によって生成されたデータが処理されデータベースに記憶されると、（情報統合フレームワークを使用する）情報統合アプリケーションがアクセルすることができる。そのようなアプリケーションは、ドメイン固有であり、一般に、処理段階で得られたデータを組織内又は組織外の異種ソースからの他のデータと相互参照し統合する。情報統合フレームワークは、データベースを実質的に作成することを可能にする（即ち、様々なデータソースは、データをデータウェアハウス内などの中央レポジトリ内に物理的にインポートしなくてもよい）。

そのような仮想的な統合は、最初に、全てのデータソースを、それらがＸＭＬ文書のソースとして見えるようにカプセル化することを含む。各ソースが作成する文書のタイプを指定しなければならない（ＸＭＬスキーマ、ＤＴＤ、ＲＤＦ定義、或いは様々な他のＸＭＬ関連モデリング形式によって）。更に、各ソースがサポートする特定の要求も文書化されなければならない。特定の事前定義された基準を遵守する文書の取得が必要なことがあり、情報統合フレームワークは、特定の文書を選択するためにＸＱｕｅｒｙの使用をサポートしている。

より正確には、所定のデータソースをＸＭＬ文書のソースとして見えるようにするには、実際に所定のデータソースの出力をＸＭＬ文書に変換する必要がある。各仮想ＸＭＬソース自体は、更に、別の仮想ソースの一部として統合することができる。その理由は、ＸＭＬが集約技術に適しており、ＸＭＬ文書がマージされて新しい文書が生成されるからである。従って、所定のＸＭＬソースを他のＸＭＬソース上で実施するだけで仮想的な集約ＸＭＬコンテンツを作成することができる。

本発明は、また、ＸＱｕｅｒｙを使用する規格ベースの共通形式でのデータソースの照会が可能である。ＸＱｕｅｒｙは、その名前が示す通り照会言語である。ＸＱｕｅｒｙは、特定のＸＭＬマークアップを使用してＸＭＬリポジトリ及び文書を照会できるように設計されている。出力「ｘｑｕｅｒｙ」自体は、再び照会することができるか仮想ＸＭＬソースの一部として統合することができるＸＭＬ文書である。現在、リレーショナルデータベースを含む様々なタイプのリポジトリを照会することができるＸＱｕｅｒｙ言語のインプリメンテーションが存在する。

従って、情報統合フレームワークの状況では、ＸＭＬとＸＱｕｅｒｙは、ＸＱｕｅｒｙを使用して照会されＸＭＬ文書を作成するＸＭＬ指向仮想データベースを作成することによって、異種リポジトリを統合するために使用される。仮想データベースは、実行するクエリーの名前と、クエリーに渡す基準を指定することによって照会される。その結果、所定の照会に合致する１組のＸＭＬ文書が得られ、そのデータは、基礎となる統合データソースから実時間で収集される。

情報統合アプリケーションは、情報統合フレームワークを使用してエンドユーザや他のアプリケーションに特定の機能を提供する。例えば、情報統合アプリケーションの実施形態は、ＸＭＬ及びＸＱｕｅｒｙソースにアクセスし、得たＸＭＬ文書を、ウェブブラウザに表示するために、ＸＳＬを使用してＨＴＭＬに変換することができる。

本発明の目的の１つは、統合情報にアクセスしその情報をアプリケーション固有の指示に従って処理するウェブサービスの開発を可能にすることである。そのようなウェブサービスは、ＢＰＥＬ（ビジネスプロセス実行言語）等のハイレベルなウェブサービス向きプロセス定義言語による統合のためのものである。ウェブサービスを統合するアプリケーションは、ビジネスプロセス管理（ＢＰＭ）の分野に分類され、ウェブサービスは、ビジネスプロセスにおける段階として処理される。

ウェブサービスインプリメンテーションは、情報統合フレームワークを使用して、ＸＭＬ及びＸＱｕｅｒｙソースの上に機能的フロントエンドを提供する。このフロントエンドは、その目的又はドメインに従ってグループ化される様々なウェブサービスコールから成る。各コールは、一連のパラメータを入力として取得し、それらのパラメータ（及び、任意の追加のパラメータ）を下にあるＸＭＬ／ＸＱｕｅｒｙ層に渡す。ＸＭＬ／ＸＱｕｅｒｙ層は、所定のパラメータに対応する１組のＸＭＬ文書をウェブサービスインプリメンテーションに戻す。このインプリメンテーションは、その１組の文書を発信者に求められた形式で中継する。

次に、そのような分離され切り離されたウェブサービスは、特定のアプリケーションを構築するために自由に統合される。本発明は、所定のビジネスプロセスの一部として様々なウェブサービスを呼び出す方法としてＢＰＥＬを利用する。ＢＰＥＬを使用するウェブサービスの統合は、ＢＰＥＬ表記を守るプログラム命令の形をとる。次に、ファイル内に維持されたそのようなプログラム命令は、（ＢＰＥＬ指示ファイルが提供される）ＢＰＥＬエンジンによって実行される。

実施形態の例
情況
本発明によって示されるシステム及び方法は、例えば、配送サプライチェーンにおける輸送品のコストを決定するソリューションを実現するために使用することができる。そのようなソリューションは、車両に関するデータ、配達される前に所定の期間倉庫に保管される品物に関するデータ、及び配達商品を取り巻く全てのアクティビティに関するデータを組み合わせる。このソリューションの目的は、輸送品のコストの決定を支援することであるが、車両使用の状況やドライバの生産性等に関する様々な他のデータの導出を支援することもできる。

そのソリューションは、所定の品物を倉庫から特定の届け先に運ぶために、自社又は公共の車両群による特に集荷と配達の情況で使用される車両群管理ソリューションによって実現される。このソリューションは、主に、ソフトウェア、個人及びビジネスプロセスからなるディスパッチングインフラストラクチャに依存する。ディスパッチングインフラストラクチャの役割は、配達行程（或いは「ルート（route）」とも呼ばれる）を使用可能な車両に割り当てることである。

一般に、車両群管理ソリューションは、他の情報システムとは別に動作し、車両使用状況とドライバ活動状態に重点を置いている。このソリューションを組織内の他のシステムと更に統合することにより、戦略的に重要な興味深い情報を得ることができる。

この例では、本発明に基づくシステムの利点を示す。この例は、中央倉庫を持つ食料雑貨店のチェーンから成り、その倉庫の品物は、チェーン内の様々な店に配達されるまで保管される。会社は、肉が倉庫内の冷蔵庫から店に届くまでの正確なコストを決定することによって肉サプライチェーンを最適化したいと考えている。

プロセス
倉庫（図１１、項目８）は、毎日一回肉の出荷を受け取る。倉庫内の冷蔵庫に入るすべての肉片にＲＦＩＤタグが付けられている。入庫する肉片は、その情報（コード、種類、卸値、重量等）が、倉庫内に維持されている肉在庫データベースに登録される。肉片が冷蔵庫から出るたびに、そのＲＦＩＤが、ＲＦＩＤリーダ（図１１、項目５ｃ）によって読み取られる。

倉庫は、環境内の様々なアプリケーションにネットワーク接続を提供する無線ローカルエリアネットワーク（ＷＬＡＮ）を装備している。冷蔵庫の近くのコンピュータには、冷蔵庫の使用状況に関する多種多様なデータを収集するために、ハブ機構（本発明によって説明されているようなもの。図１１、項目５）が導入される。例えば、冷蔵庫内のＲＦＩＤリーダによって取り込まれたデータは、そのデータに応じて埋め込まれた肉在庫データベースを調整する（ハブ内の）埋め込みアプリケーションによって追跡される（肉片が冷蔵庫に入ったときに肉片の識別子を保持するレコードがデータベース内に作成され、「入庫済み」フラグがレコードにセットされる。）更に、冷蔵庫は、重要なコストとなる特定量の電気を消費する。消費電力を測定するために、冷蔵庫の電源にセンサ（図１１、項目５ｂ）が取り付けられる。センサは、ハブの一部として導入された埋め込みアプリケーションによって遠隔的にアクセスされる。このアプリケーションは、消費電力データ（時間、金額、量）をハブ上の埋め込みデータベースに記憶する。

倉庫から各店に毎日配達される肉の量と種類は、運用管理ユニット（図１１，項目Ｂ）の一部であるディスパッチングソフトウェアによって割り当てられる。このソフトウェアには、店自体から来る電子注文が自動的に送られる。店は、コールセンターや顧客サービスユニット（図１１，項目Ａ）を介して注文を出すこともできる。発送者として知られる人には、ソフトウェアから注文が入っていることが通知される。発送者は、各注文を確認し、指定されたルートを承認する。ルートは、所定期間の間のトラック、ドライバ及び届け先リストの組み合わせである。次に、注文は倉庫に送られ、そこで管理者はその注文を受け取る。管理者は、注文を実行する役割をし、適切な量と種類の肉が、冷蔵庫から取り出され、ディスパッチングソフトウェアと発送者によって選択され承認されたトラックに積み込まれる。肉片が冷蔵庫から出るとき、そのＲＦＩＤが検出され、それに従って埋め込まれた肉片在庫アプリケーションがその在庫を調整する（所定の肉片に対応するレコードに「出庫済み」フラグをセットすることによって）。アプリケーションは、定期的に、その状態を、運用管理ユニットの一部である中央在庫アプリケーションと同期させる。同期は、埋め込みデータベース内の「入庫済み」状態と「出庫済み」状態の両方のフラグが立てられた肉片と、エラーがある場合にはそのエラー状態を検出することから成る（「出庫済み」状態は、「入庫済み」状態なしでは存在することができず、また、所定の肉片については、肉が特定の賞味期限を過ぎたことを示す所定の長さの時間の後では「入庫済み」状態のフラグのみが立っていることはない）。エラー状態は、同期手順の一部として報告される。倉庫に入り出た肉は、それに従ってフラグが立てられた対応するレコードを中央在庫データベース内に有する。

各トラック（図１１，項目９）は、ハブ機構（本発明によって説明されているような。図１１，項目７）の状況でマイクロカーネルが導入されたオンボードコンピュータを装備している。マイクロカーネルは、トラックの識別子としての役割もする識別子を備える。更に、各トラックは、また、トラックに入ったり出たりするすべての品物のＲＦＩＤを検出するＲＦＩＤリーダ（図１１，項目７ｃ）を備える。そのようなイベントが起きたとき、埋め込み在庫同期アプリケーション（マイクロカーネル内に配備された）は通知を受け、そのようなイベントに対応するデータをローカルデータベースに記憶する。倉庫内の在庫同期アプリケーションと同じように、トラックに入ったり出たりする品物は、データベース内で作成され更新される対応するレコードを有する。品物に対応するレコードは、内容により「入庫済み」状態と「出庫済み」状態のフラグが立てられる。

車両の一般的な状態を監視する別のアプリケーションが配備される。この状態は、ドライバ入力／出力システム（図１１，項目７ｂ）によって取り込まれる速度、ＲＰＭ（毎分回転数）、変速機状態、及び他の機械的パラメータから成る。アプリケーションは、データを取得するためにドライバ入出力システムと通信し、全ての原始的なデータを保持するのではなく、事前定義された間隔で全ての監視パラメータに関して、状態の変化を判定するために使用される差分を計算する。それぞれの状態の変化は、アプリケーションによって管理されるローカルデータベースに保持される。車両内のアプリケーションによって保持される全てのデータは、時間的及び地理的に参照付けされ、これは、アプリケーションが、車両のＧＰＳ（図１１，項目７ａ）と結合された別の埋め込みアプリケーションと通信するために可能である。その目的は、車両の現在位置を提供することだけである。

１台の所定のトラックが、肉を複数の届け先に配達することがある。各届け先で、対応する積荷が下ろされる。品物が下ろされるたびに、ＲＦＩＤ通知が行われる（前述のように）。イベントに関するデータ（時間、ＲＦＩＤ、及び場所）は、在庫同期アプリケーションによって管理された埋め込みデータベースに維持される。配達完了時、ドライバ（図１１，項目１０）は請求書発行に取りかかり、店にいる人が、ドライバのハンドヘルドコンピュータと結合された電子パッドを介して電子請求書に署名する。ハンドヘルドコンピュータ自体は、無線リンクによって、会計請求ユニット（図１１，項目Ｄ）と結合されている。ハンドヘルドコンピュータ内の請求書発行アプリケーションは、ネットワーク抽象化層（ＮＡＬ）を利用してそのデータを送信する。その時にネットワーク接続が使用できない場合は、確認は、最終的に転送できるまでハンドヘルドコンピュータ上のデータベースに記憶される。同じように、請求書発行アプリケーションは、配達が完了したメッセージを運用管理ユニットに送信する。両方のメッセージ（請求と配達確認）は、対応するトラックの識別子を含む。

ルートの過程で、トラックには様々なイベントが起きる。最初に、トラックは倉庫を出発する。これは、ルートの始まりを示し、このイベントは、ドライバがそのハンドヘルドコンピュータを使用して記録される。運用管理ユニットには、ドライバがルートを出発したことが通知され、それによりどのトラックがまだ倉庫内にあり、どのトラックが道路にいるかが分かる。そのルートの過程では、品物を配達する他に、トラックが燃料を補給したり、ドライバが昼休みのために止まったりする可能性がある。そのようなイベントが起きたときは、ドライバはその情報を自分のハンドヘルドコンピュータに記録し、それにより最終的にそれらのイベントを説明することができる。更に、ドライバは至急便を受け取る可能性がある。これは、トラックが倉庫に戻って追加の品物を受け取り、次にその行程を再開することを伴う。この動作は、また、全体的なコスト評価で考慮されるコストを伴う。

トラックとＲＦＩＤリーダ内の埋め込みアプリケーション、入出力システム及びＧＰＳ間の全ての通信は、ネットワーク抽象化層（ＮＡＬ）を介して行われる。

トラックは、そのルートを完了した後で倉庫に戻る。ルートを完了したドライバは、自分のハンドヘルドコンピュータを使用してルートの完了を運用管理ユニットに知らせる。ハンドヘルドコンピュータは、ＮＡＬ（図１１，項目４）を使用して、完了メッセージをデータ処理インフラストラクチャ（図１１，項目３）に送信することを試みる。次に、メッセージは、ディスパッチングソフトウェアに送られる。これと同じ理由で、ハンドヘルドコンピュータは、そのログを保守管理ユニット（図１１，項目Ｃ）に送り、ログは、ルートの間のドライバの活動状態、即ち燃料の補給や昼休み等に関係する全てイベントを含む。

次に、（トラック内の）埋め込みアプリケーションは、ネットワーク接続により、そのデータを会社内の対応するアプリケーションに送信することができる。また、ＲＰＭ、速度及び送信位置に関係するデータは、ＮＡＬ及びデータ処理インフラストラクチャを介して、保守管理ユニット（図１１，項目Ｃ）に間接的に送信される。

埋め込み在庫同期アプリケーションの場合、埋め込み在庫同期アプリケーションは、全ての荷物の積み降ろしに関係する情報を、ＮＡＬによってデータ処理インフラストラクチャに単純に送信する。埋め込みアプリケーションは、更に、そのトラック識別子を送る。運用管理ユニットの一部である中央在庫アプリケーションは、最終的に情報を回復する。その時点で、配達が確認された肉片は、適切に更新されたデータベース内にその対応するレコードを有する。

同期手順の一部として、各トラック内に埋め込まれ（マイクロカーネルに統合された）更新クライアントは、更新サーバに接続して、まだ完了してないソフトウェア更新を検出しダウンロードする。例えば、そのような更新は、ビジネスルールの変更によって必要なことがある。更に、埋め込みアプリケーションは、リモート管理インフラストラクチャを介して送信されたリモート管理コマンドを受け取り、対応する応答を送り返す。

ソリューション
肉を管理する全体的なコストを決定するために、会社は、様々なデータベースと情報システムに蓄積された分散データに依存しなければならない。

１．各肉片は、在庫データベース（運用管理ユニット内）で説明される。

２．肉在庫データベースは、最終的には、それぞれ個々の肉片の届け先への到着に関する情報も含む。この情報を使用して、コストを届け先ごとに評価することができる。

３．ディスパッチングソフトウェア（運用管理ユニット内）は、ルートの開始と完了に関係する情報を含む。このデータを在庫データベース内で関連づけて、コストを適切に分散させるめに、どのルートのどの場所に肉片を配達したかを実際に決定することができる。

４．更に、各肉片は、所定の期間冷蔵庫内に保管され、主に消費電力に関係するコストを発生させる。これらのコストに関する情報は、消費電力データベースから収集される。これを肉片が冷蔵庫内に保管されていた時間の長さと関連付けて、エネルギー消費コストを適切に分散させることができる。

５．燃料補給、昼休み、労働時間等に関する運用管理ユニット内に維持される情報を車輌の地理的データと関連付けて、届け先ごとに対応するコストを評価することができる。

従って、コスト評価は、一般に、ばらばらのサイロ内に維持されているデータの相互参照を必要とする。一般に、そのようなタスクを実行するために、（本発明の一部として提供された）情報統合フレームワークが、以下のように使用される。

ａ）ばらばらの各データベースが、ＸＭＬ文書のソースとして抽象化される。

ｂ）ＸＱｕｅｒｙ言語を使用して、ＸＭＬ文書の仮想ソースを正確な基準で照会することができる。

ｃ）ＸＱｕｅｒｙは、各ソースから来るデータを後処理するために使用できる数学関数を提供する。更に、取得した文書を更に集約、変換、照会して、完全に合成された情報を作成することができる。

ｄ）この例の情況では、最終結果は、肉管理コストを表すレポートの形で提示される。

より具体的には、コスト評価ルーチンは、所定の肉に関して以下のデータを考慮する。

全体コスト見積プロセスは、図１２のデータ流れ図に詳細に示されている。簡略化するため、示したプロセスには、届け先ごとのコスト評価は含まれていない（従って、コストは全ての届け先に等しく分散されている）。データの流れは次の通りである。

１．１．主プロセスは、所定期間にわたるコスト評価レポートを作成することから成る。

１．１．１．レポートを作成するために必要なデータソースから適切なデータを収集する。

１．１．２．各トラックレコードごとに、所定のトラックに対応するルートを選択する（所定の期間のトラック、ドライバ及び１組の届け先に対応するルート）。更に、肉在庫データベースを調べて各トラックがどの肉を配達したかを見つける。

１．１．３．次に、消費電力アプリケーションを調べて、対象期間に消費されたエネルギーの全コストを求める。次に、コストは、適切な肉片全体に均一に分散される（前の段階で求めたように）。

１．１．４．次の段階は、ドライバに関係するコスト（報酬と経費から成る）を計算する段階から成る。

１．１．５．同様に、配達した車両に関係する（対象期間の）保守総合コストも計算する。

１．２．配達した肉片に関するデータと総合コスト（ドライバ、保守、エネルギー消費）により、肉の平均コスト（保管と輸送に関係する）を計算することができる。最終的に、これを請求データ（会計請求ユニット内）を関連付けて、価格がコストを賄うことができるかを判断することができる。

利点
以上述べたアーキテクチャは、（従来の解決策と比べて）次のような多くの点で本発明の特徴から利益を得ることができる。

ａ）動的資産か静的資産かに関係なく、全てのアプリケーションを遠隔的に配備し、更新し、管理することができる。

ｂ）所定の資産に複数のアプリケーションを配備するこができる。

ｃ）アプリケーションがネットワークに断続的に接続することができ、自律式にタスクを実行する。従って、永久接続は必要なく、データ損失が起きない。

ｄ）アプリケーションは、その処理能力と記憶容量の利用を最大にするように設計され、ＬＡＮ内のアプリケーションは、膨大な量のデータを処理しなくてもよくなる。この設計は、アプリケーションの自律性も強化する。

ｅ）情報統合フレームワークは、異種のデータソースを統合して、戦略的意思決定を可能にする情報を作成するために使用される。元々分散され関連付けられていなかったデータが有効な情報になる。

図面、明細及び例において、本発明の典型的な好ましい実施形態を開示した。特定の用語を使用してきたが、それらは、一般的な説明の意味で使用され、限定のために使用されておらず、本発明の範囲は、添付の特許請求の範囲に記載されている。

マイクロカーネルと装置の関係を示す概略図である。 埋め込みアプリケーションと装置の関係を示す概略図である。 資産管理インフラストラクチャの概略図である。 本発明の装置及びデータ処理インフラストラクチャの概略図である。 本発明の情報統合フレームワークの概略図である。 本発明のシステム及び方法を使用するクライアントアプリケーションの概略図である。 マイクロカーネル管理システムの概略図である。 本発明のデプロイメントシーケンスの概略図である。 本発明の装置及びデータ処理システムの概略図である。 本発明のハブの概略図である。 特定の分散サプライチェーンの状況における本発明の実施形態の概略図である。 特定の分散サプライチェーンの状況における本発明の実施形態のデータ流れ図である。

Claims (8)

1. 多数のリモート装置と、中央データ処理及び管理インフラストラクチャとから成る分散型資産管理システムであって、
   ａ）前記リモート装置が、多数の分散型資産の一つと対応していると共に、プロセッサ、メモリ及び当該リモート装置が対応している資産関連データを取得するための少なくとも一つのセンサを備えており、かつ当該プロセッサは、少なくとも一つのセンサによって取得されたデータを受信してローカルに処理し、当該処理されたデータをメモリに保存した上、送信するように設定された、１以上のアプリケーションを実行するように構成されており、かつ当該リモート装置は、当該埋め込みアプリケーションを管理するマイクロカーネルを含み、
   ｂ）前記中央データ処理インフラストラクチャが、多数のリモート装置から処理されたデータを受信し、
   ｃ）前記管理インフラストラクチャが更新サーバを含み、リモート装置上でソフトウェアプロセスを終了することなく、マイクロカーネル下の更新クライアントが、埋め込みアプリケーションを動的に更新するため、ソフトウェア更新プログラムを前記更新サーバからダウンロードすることを特徴とする分散型資産管理システム。
2. 前記埋め込みアプリケーションが、１以上のマイクロデバイスと通信するプロキシサーバと通信するように構成されたハブアプリケーションであり、前記マイクロデバイスが、マイクロカーネルの導入を許可しない請求項１記載のシステム。
3. 前記中央データ処理インフラストラクチャが、非同期性のメッセージサーバーソフトウェア、データキャッシュ及びデータ処理アプリケーションから成る請求項１又は２記載のシステム。
4. 前記リモート装置の少なくとも一つのセンサが、ＧＰＳ受信機から成る請求項１〜３のいずれか１項に記載のシステム。
5. 前記リモート装置の少なくとも一つのセンサが、ＲＦＩＤセンサから成る請求項１〜４のいずれか１項に記載のシステム。
6. コンピュータにより、分散型資産を管理する方法であって、
   ａ）埋め込みアプリケーションを更新するマイクロカーネルを備えているリモート装置の少なくとも一つのセンサが取得したデータを、
   中央データ処理インフラストラクチャに遠隔的に送信するために、当該リモート装置が監視する資産に関連付けて当該埋め込みアプリケーションに導入する段階と、
   ｂ）当該導入された資産関連データを、当該埋め込みアプリケーションによって、ローカルに処理する段階と、
   ｃ）当該処理されたデータを、埋め込みアプリケーションによって、当該リモート装置のメモリに保存する段階と、
   ｄ）当該処理されたデータを、埋め込みアプリケーションによって、中央データ処理インフラストラクチャに送信する段階と、
   ｅ）リモート装置上でソフトウェアプロセスを終了することなく、更新クライアントにソフトウェア更新プログラムをダウンロードすることによって、マイクロカーネル下の更新クライアントを使用するリモート装置上の埋め込みアプリケーションを更新する段階とを、含むことを特徴とする分散型資産管理方法。
7. 更に、前記リモート装置によって取得された全てのデータを、埋め込みアプリケーションによって、ＸＭＬ文書に変換する段階を含む請求項６記載の方法。
8. 更に、前記リモート装置を、中央データ処理インフラストラクチャとマイクロカーネルを具備しないマイクロデバイス間の中間物として機能するハブ装置に転換するために、当該リモート装置にプロキシサーバを導入する段階を含む請求項６記載の方法。

Images