JP2014519644A - データ分析システム - Google Patents

Abstract

複数の装置からのデータを分析するためのデータ分析システムが、様々な装置から収集したデータを格納するデータ記憶サブシステムを備えたデータベース・サービス・モジュールを備える。当該データは、当該データを分類するためのプリミティブを用いてメタ構造に格納される。分析エンジンが、当該データを分析して、当該メタ構造により定義された当該データが特定の基準を満たすかどうかを１組の格納されたルールに従って判定する。当該システムは、例えば、鉄道インフラにおける障害検出において有用である。

Description

本発明はデータ分析の分野に関し、特に、複数の装置から収集したデータの分析に関する。当該複数の装置は鉄道インフラにおけるように同一であっても別々であってもよい。

鉄道インフラは多種多様なシステムを使用している。それらの各々では、各々独自の診断機能を有する多種多様な装置タイプが展開されている。これらの機能が同一であることは稀であり、そのデータ提供方法が同一である可能性はさらに低い。しかし、テスト、診断、および保守の目的でこのデータを収集し、比較し、関連付けるニーズはある。現在、生成されたデータと当該データが提供される方法とを調和させることは、不可能であるかまたは非現実的である（各ゾーンにおける異なる軌道レイアウトのため、ゾーン・コントローラが有するデータ・セットは異なる）。

装置タイプごとの独立なデータ収集といった今日の技術は、全てのデータを相互比較の目的で集約するのに何らかの人手の作業が必要であるので、あまりにも面倒である。さらに、ＳＮＭＰのようなネットワーク・データ収集のための既存のソリューションは実用的ではない。なぜならば、ａ）当該ソリューションは実装可能でない可能性のある装置にプロトコルを強制し、ｂ）ＳＮＭＰプロトコルがイベント通知にのみ基づきしたがってデータ収集システムとして不適切であり、ｃ）データを生成した装置がネットワークおよびＮＭＳサーバへの接続を有することが前提であるが、これは常にそうであるわけではないからである。

ＳＣＡＤＡ（Ｓｕｐｅｒｖｉｓｏｒｙ Ｃｏｎｔｒｏｌ ａｎｄ データ Ａｃｑｕｉｓｉｔｉｏｎ）でさえも現実的なソリューションとは考えられていなかった。なぜならば、生成されたデータ・セットにより、ＳＣＡＤＡプロトコルのオーバヘッドが潜在的にシステム全体を動作不能にするおそれがあるからである。現在展開されているソリューションでは、ネットワーク装置（ＶＯＢＣ、ＺＣ）に任意の障害を中央システム（ＡＴＳ）へ報告させているが、これは十分ではない。なぜならば、現在ネットワーク上にある装置だけがデータを送信でき非ネットワーク装置からのデータが考慮されず、これらの非ネットワーク装置も、テストおよび診断の観点から望ましいデータを生成するからである。さらに、これらのネットワーク装置の信頼性要件は診断機能と調和しない傾向がある（信頼性を高めるための透明な投票およびデータ平滑化の概念は、定義によれば、予測可能な診断機能に必要なデータを破壊する）。

本発明によれば、様々な装置から収集したデータを格納するデータ記憶サブシステムを含むデータベース・サービス・モジュールであって、当該データは当該データを分類するためのプリミティブを用いてメタ構造に格納されるデータベース・サービス・モジュールと、データを分析して、当該メタ構造により定義されたデータが特定の基準を満たすかどうかを１組の格納されたルールに従って判定するための分析エンジンとを備える、複数の装置からのデータを分析するためのデータ分析システムが提供される。

本発明の基本的なアイデアは、どのようにデータが格納され、関連付けられ、分析されるかを、データがターゲット装置からエクスポートされる機構および方法から抽象化するオーバレイ・システムを設計し開発することである。これにより、ターゲット装置に物理的に接続する層を除いた全てのレベルの収集、記憶および分析システムで使用される、汎用化されたデータ構造を生成することができる。これは、ターゲット装置に如何なる要件も課さずユーザが全ての装置からの全てのデータを共通に扱うことができるという点で、
既存のソリューションから差別化される。

当該方法は、このように、全ての診断データをその「自然な」形態で収集し、データの分析と相互比較を可能とするように纏める。当該方法はまた、全ての装置が何キロメートルもの軌道にわたって広がりうる場合の、集約され自動化された記憶機構を提供する。当該方法はまた、システムの不可欠なまたは動作上の側面に影響を及ぼすことなく、全ての技術的要件を満たすように動作する。

本発明の諸実施形態により、診断データを生成できる任意の装置を診断システムに含めることができる。当該ソリューションはオーバレイとして動作するので、生成されるデータの点、またはデータをそれにより取り出す機構の点で、どの装置タイプにも要件が課されない。これにより、ＣＯＴＳ（Ｃｏｍｍｅｒｃｉａｌ Ｏｆｆ−ｔｈｅ−ｓｈｅｌｆ）または設計に何ら影響を及ぼさない他の任意のコンポーネントを診断システムに組み込むことができることが保証される。同様に、当該ソリューションでは、設計が影響を受けるおそれがあるコンポーネントから任意の要件が除去される。これらのケースで必要とされているものは、データを装置からエクスポートする物理機構または論理機構に関わらず、どのデータが診断値を有するかを定義することである。場合によっては、生成されるデータの種類とデータにアクセス可能な機構とが既知である限り、本発明を競合会社のシステムにオーバレイとして展開することさえも可能である。

本発明では、データ速度に関して仮定せず、何らの最低限の要件も課さないので、本発明を任意のシステムに展開することもでき、システムの制約事項に対してカスタマイズすることもできる（例えば、データ収集速度を調節して、利用可能な帯域幅が殆どないシステムでの動作を可能とすることができる）。本発明は、収集されたデータの価値は低下するかもしれないが、これらの条件下でも動作し続けるであろう。

本発明の別の態様では、様々な装置からのデータを進行中に収集するステップと、収集されたデータを、データベース・サービス・モジュールのデータ記憶サブシステムに、プリミティブを用いて当該データを分類するメタ構造で格納するステップと、当該データを分析して、当該メタ構造により定義された当該データが特定の基準を満たすかどうかを１組の格納されたルールに従って判定するステップとを含む、複数の装置からのデータを分析する方法を提供する。

次に、例としてのみ、添付図面を参照して本発明を詳細に説明することとする。

本発明の１実施形態に従うデータ分析システムの概要を示す図である。 データベース・サービス・モジュールのブロック図である。 分析エンジンのブロック図である。 データ・コレクタのブロック図である。 低い抽象化レベルでのシステムのブロック図である。 ルール同期を示す図である。 データ・ビューワ／アナライザのロジックを示す図である。 データ分析プロセスを示す図である。 データ収集サービスを示す図である。

まず、図１を参照して、最も高い抽象度でデータ分析システムを説明する。当該データ分析システムは、データベース・サービス・モジュール１０を備える。当該コンポーネントは、中央のデータ・リポジトリとして動作し、データを共通的に処理できる、全てのデータに適用されるメタ構造を定義する役割を担う。本発明の諸実施形態が、１つまたは複数のデータベース・サービスを有してもよく、各データベース・サービスはアクティブであり、他の任意のコンポーネントは任意の展開されたデータベース・サービスと通信することができる。

分析エンジン１１は、データベース・サービス１０により格納されたデータを関連付け比較する役割を担い、当該ソリューションの診断コンポーネントとして動作する。当該コンポーネントは、データが「良好」または「不良」であるかどうか、および、もしあれば「不良」なデータが検出されたときにどの措置を取るべきかを支配するルールの構造を定義する。本実施形態では、ルールはデータベース・サービスにより格納されるが、これは要件ではない。しかし、このようにルール記憶部を実装するのは良いプラクティスであると考えられる。なぜならば、当該ソリューションのデプロイメントにおいて分析エンジンがゼロまたは複数でありうるとき、ルール記憶部はルール・データに対して単一のリポジトリを提供するからである。

データ・コレクタ１２は、データをターゲット装置（複数可）から収集し、データベース・サービスにより使用されるメタ構造にそのデータを変換する役割を担う。本発明の１実施形態では、１つまたは複数のデータ・コレクタおよび各データ・コレクタが、データを１つまたは複数の装置または装置タイプから収集するする役割を担ってもよい。

ワークステーション１３は、ソリューションのユーザ・インタフェースの役割を担い、ユーザが収集されたデータを参照することができユーザが当該データを分析できるようにする。ワークステーションはまた、ルールを参照し、作成し、修正し、または削除することができる。本発明の１実施形態では、ゼロまたは複数のワークステーションがあってもよい。

当該ソリューションにわたって、メタ構造を全てのデータに対して使用する。当該構造により、元のデータの形態またはソースに関わらず纏めて格納し使用できるように、全く異なるデータを均一化することができる。当該メタ構造は、以下のプリミティブを使用してデータを分類する。

装置タイプ：装置タイプは、一連のデータのソースに対する、データ・コレクタが定義した分類である。例えば、ネットワーク・スイッチまたはコンピュータが各々装置タイプであってもよい。装置タイプには、それを定義したデータ・コレクタが関連付けられる。

装置インスタンス：各装置タイプは、１つまたは複数の装置インスタンスを有してもよい。装置インスタンスは、単純に、データがそこから収集される装置タイプのインスタンスである。例えば、「ネットワーク・スイッチ」の装置タイプが定義された場合、その装置タイプが装置インスタンス「Ｓｗｉｔｃｈ１」、「Ｓｗｉｔｃｈ２」等を有してもよい。

データ・タイプ：データ・タイプは、所与の装置タイプに対するデータ点の定義である。装置タイプが、複数の定義されたデータ・タイプを有してもよく、当該装置タイプの装置インスタンスごとに、当該装置タイプに対して定義されたデータ・タイプに対応するデータは当該装置インスタンスの各々から収集されるはずである。データ・タイプが定義されたとき、データ・タイプごとのデータの実際のタイプも定義される。例えば、装置タイプ「ネットワーク・スイッチ」に対するデータ・タイプ「アクティブ・ステータス」を整数として定義してもよく、同じ装置タイプに対するデータ・タイプ「バージョン」を文字列として定義してもよい。本発明は、データ・タイプが取りうるデータの種類には制限を設けないが、実際には一連のタイプを強制してもよい。例えば、鉄道信号設備に展開された装置からデータを収集するには、データ・タイプの種類を整数、単精度の浮動小数点数、または最大１００文字の文字列に限定するだけで十分であるかもしれない。データ記憶ソリューションのタイプのような他の実装因子により追加の制限を課してもよい。例えば、商用ＳＱＬデータベースをデータ記憶機構として使用する場合には、許容可能なデータ・タイプのリストを、当該ＳＱＬデータベースによりサポートされるプリミティブにより制限してもよい。

データベース・サービス１０が、図２でより詳細に示されており、データ・コレクタ１２から受信されたデータの受信機能、上で定義したメタ構造に基づく当該データの記憶とカタログ化の役割のみを担う。これらの機能を実施できる例示的な機構を説明するが、当業者が想到できる他の機構を使用してもよい。

データベース・サービス１０はデータ・コレクタ・インタフェース２０を備える。データ・コレクタ・インタフェース２０は、格納すべきデータを提供するデータ・コレクタ（複数可）１２と通信する役割を担う。このデータ・コレクタ・インタフェース２０は、データ・コレクタ（複数可）１２との通信を維持し、データ・コレクタ（複数可）１２により収集されたデータを受信し処理する役割を担う。このインタフェース２０はまた、これらのデータ・コレクタ１２が担当する装置タイプ、装置インスタンス、およびデータ・タイプをデータ・コレクタ（複数可）１２が定義し管理できるようにする役割を担う。次に、データ・コレクタ・インタフェース２０は受信した全てのデータをデータ管理プロセス２１に渡す役割を担う。当該データは、メモリ２４を備えたデータ記憶システム２３に格納することができる。

同様に、接続されたデータ・コレクタ１２が収集したデータのメタ構造を修正した場合には、データ管理プロセス２１がデータをデータ記憶システム２２に格納する方法を必要ならばデータ管理プロセス２１が更新できるように、これらの修正はデータ・コレクタ・インタフェース２０によりデータ管理プロセス２１に渡される。

データ・コレクタ・インタフェース２０はまた、オンデマンドでのデータ収集の通知をデータ管理プロセス２１から受信する役割を担う。かかる通知が受信された場合には、データ・コレクタ・インタフェース２０はこの要求をデータ・コレクタ１２に中継して処理する。

データ・コレクタ・インタフェース２０は、データ・コレクタ１２から受信したデータを前処理するか、または、単に当該データをデータ管理プロセス２１に渡してもよい。単にデータを渡すことは有利である。なぜならば、これにより全てのデータ処理がデータ管理プロセス２１に集約化され、本発明の保守と開発を支援できるからである。

同様に、存在するデータ・コレクタ・インタフェース２０の数は実装で定義されるものである。全てのデータ・コレクタ１２により使用される１つのデータ・コレクタ・インタフェース２０が存在するようにシステムを構築することができるが、好適な実装形態では、データベース・サービス１０と通信する各データ・コレクタ１２を担当する単一のデータ・コレクタ・インタフェース２０が設けられる。

ワークステーション・インタフェース２５は、ワークステーション（複数可）１３と通信して、当該ワークステーション（複数可）が使用するためのデータを提供し、ルールを取り出し修正するためのインタフェースを提供する役割を担う。ワークステーション・インタフェース２５は、どのデータがデータベース・サービス１０により格納されるかのステータスを受信し、ローカルで使用するためのデータをダウンロードするために、ワークステーション（複数可）１３により使用される。さらに、当該ワークステーション・インタフェースはまた、データベース・サービスが格納するルールのリストを取り出し、新たなルールを作成するかまたは既存のルールを修正もしくは削除するために、ワークステーション（複数可）により使用される。ワークステーション・インタフェース２５はまた、ワークステーション１３がデータをデータ・コレクタから直接収集した場合に、ワークステーション１３が当該データを格納できるようにする。データが格納のためにワークステーション・インタフェース２５に送信された場合には、ワークステーション・インタフェース２５は、あたかもデータがデータ・コレクタ・インタフェース２０から受信されたかのようにデータを扱うことができるよう当該データをデータ管理プロセス２１に渡す。

データ・コレクタ・インタフェース２０と同様に、ワークステーション・インタフェース２５はデータ管理プロセス２１に対するゲートウェイとして動作し、データ・コレクタ・インタフェース２０に適用可能な全ての実装上の事項はワークステーション・インタフェース２５にも適用される。

分析エンジン・インタフェース２６は、分析エンジン（複数可）１１と通信して、分析エンジン（複数可）１１が使用するためのデータとルールを提供する役割を担う。分析エンジン・インタフェース２６は単に、接続された分析エンジン１１に対して、データ管理プロセス２１を介して、分析エンジン１１が独自に処理するために要求した任意のデータとルールを提供する。分析エンジン・インタフェース２６はまた、要求された場合にどのデータとルールが利用可能であるかのリストを提供することもできる。分析エンジン・インタフェース２６はまた、オンデマンド・データ収集に対する任意の要求を分析エンジン（複数可）１１から受信する役割を担う。特定の装置タイプおよび装置インスタンスに対するオンデマンド・データ収集の要求が受信された場合には、分析エンジン・インタフェース２６は、その通知を適切なデータ・コレクタ・インタフェース２０に送信できるように、その通知をデータ管理プロセス２１に渡す役割を担う。

データ・コレクタ・インタフェースと同様に、分析エンジン・インタフェースは、データ管理プロセスに対するゲートウェイとして動作し、データ・コレクタ・インタフェースに適用可能な全ての実装上の事項は分析エンジン・インタフェースにも適用される。

データ管理プロセス２１は、データ記憶サブシステム２４の抽象化をデータベース・サービス０の他のコンポーネントに提供する役割を担い、データ記憶サブシステム２２の実際の実装を管理する役割を担う。データ管理プロセス２１は、データ記憶サブシステム２２を構造化して、本発明により課されるメタ構造に基づいてデータに容易にアクセスしデータを格納できるようにする。この構造化を物理的に行うか、データ記憶サブシステム２２により論理的に行うか、または単にデータ管理プロセスにより論理的に行うかは、データ管理プロセス２１の全てのユーザに対して、全てのデータがメタ構造を介してアクセスされ参照される限り、設計上の選択の問題である。

同じ条件がルールの記憶とアクセスに適用される。当該ルールが存在し、メタ構造により定義されるデータが「良好」であるか「不良」であるかを判定することができる。結果として、ルールがそれにより格納され参照される機構は選択の問題であるが、良い実装形態では、データ管理プロセス２１がルールを格納しルールに対するアクセスを提供する役割を担いルールがデータ記憶サブシステム２２に格納されることが規定されるであろう。

データ記憶サブシステム２２は、データ管理プロセス２１によって抽象化される任意の種類の物理的なデータ記憶抽出システムであってもよい。データ記憶システムの種々の例には、ＳＱＬデータベースから、単純なフラットなデータ・ファイルまたは一連のフラットなデータ・ファイルまで任意のものがあってもよい。データ記憶サブシステム２２の実際の実装は本発明の範囲外であるが、ソリューションを選択するときには以下のことを考慮すべきである。

ａ）大量のデータが非常に高速にデータベース・サービス１０へ送信されて格納されることが考えられるので、データ記憶サブシステム２２は高速な書込み時間を保証すべきである。書込み時間はデータの収集速度よりも長いべきであり、または、何らかのキャッシュおよびフラッシュ・システムを使用すべきである。
ｂ）データ記憶サブシステム２２はデータに対するランダム・アクセスを可能とすべきである。複数のデータ受信者（ワークステーション（複数可）および／または分析エンジン（複数可））が大量の異なるデータを同時に要求している可能性があるので、データ記憶システムは、システム性能への影響を最小限としつつ、これを実施できるようにすべきである。
ｃ）データ記憶サブシステム２２は、障害の場合にデータの完全性とシステムの信頼性を保証するために何らかの形の冗長性を提供すべきである。
ｄ）データ記憶サブシステム２２は、複数の同時アクセスを可能とすべきである。デプロイメントには複数のデータベース・サービスがありうるので、データ記憶サブシステム２２はデータベース・サービスの全てのインスタンスが単一のデータ・リポジトリにアクセスできるようにすべきである。データベース記憶サブシステムはまた、複数アクセスによりデータ完全性が破壊されないことを保証するための機構を実装すべきである。

データベース・サービス１０およびデータ・コレクタ（複数可）１２、ワークステーション（複数可）１３、および分析エンジン（複数可）１１の間の通信に使用されるプロトコル（複数可）の実装は以下を満たすべきである。

ａ）当該プロトコルは、データベース・サービス１０と他のパーティの両方が、データがアクティブに送信されていない場合であっても接続が失われたかどうかを判定できるように、接続指向であるべきである。障害の処理を可能とし、受信者がデータを受信していたという誤った前提のもとに送信データが失われないことを保証するために、これを行うべきである。
ｂ）共通プロトコルを全てのインタフェースに対して使用すべきである。本発明の要件ではないが、これにより開発、デバッグ、および保守が容易になる。
ｃ）当該プロトコルは、低オーバヘッドであるべきであり、データの収集速度よりも早い速度で送信構成を送受信可能であるべきである。
ｄ）当該プロトコルは、受信データの解析の際にデータベース・サービス１０により要求された送信の量を最小化するように、データを送信すべきである。データベース・サービス１０が大量のデータを大量のソースに対して同時に送受信する可能性がありうるので、データベース・サービス１０により要求された処理の量をメッセージごとに制限するのが有利である。

分析エンジン１１は、図３に詳細に示すように、データベース・サービス１０により格納されたデータを分析し、当該データが「良好」であるか「不良」であるかを判定する役割を担う。「不良」データが検出されている場合には、分析エンジン１１は応答動作をトリガする役割を担う。どのようにデータが分析されるか、どのように「良好」または「不良」の判定が行われるか、「不良」データの結果としてもしあればどのような措置を取るべきかに関する実際の機構は本発明の範囲外である。

データベース・サービス・インタフェース３０は、データベース・サービス１０の分析エンジン・インタフェース２６を介してデータベース・サービス１０と通信する役割を担う。結果として、当該コンポーネントに対する全ての機能および実装上の事項はデータベース・サービス１０の分析エンジン・インタフェース２６と同様である。分析エンジンの観点からは、当該コンポーネントは、データベース・サービス１０に格納された全てのデータをあたかもそれがローカルに存在するかのように扱えるよう分析エンジンに対してデータ・ソースを抽象化する役割を担う。分析エンジン１１のコンポーネントのその余に対しては、データベース・サービス・インタフェース３０はデータ自体に見えるべきである。本発明の諸実施形態では複数のデータベース・サービスのデプロイメントがありうるので、このコンポーネントは、データベース・サービス１０のどの具体的なインスタンスに接続すべきかを判定する役割を担い、現在のデータベース・サービス１０が利用不能になった場合に他の任意の利用可能なデータベース・サービス１０に接続する役割を担う。

このデータベース・サービス・インタフェース３０はまた、分析エンジン１１が使用したルールを「格納」する役割を担う。上述のように、好適な実装形態では、ルールはデータベース・サービス１０に格納される。このケースでは、当該コンポーネントは単純に、当該ルールを取り出すために当該インタフェースをデータベース・サービス１０に対して抽象化する。ルールが分析エンジン１１によりローカルに格納される場合には、当該コンポーネントは、データ・ソースの抽象化として動作する役割の一部として、ルール自体に対する格納位置としても動作する。このように、ルール記憶に関して選択した実装形態に関わらず、分析エンジン１１のコンポーネントのその余に対しては、ルールを取り出すインタフェースは一定のままである。

分析エンジン・マネージャ３１は、分析エンジン１１の現在のインスタンスにより取られている措置を調整する役割を担う。分析エンジン・マネージャ３１は、どのルールをどの順序で、どの装置タイプまたは装置インスタンスに対して実行すべきかを判定し、これらのルールを処理する頻度を判定する役割を担う。ルールの実際の構造と機能は実装で定義されるが、かかるルールは、存在し、実行可能であり、データが「良好」であるか「不良」であるかを判定できるべきである。

分析エンジン・マネージャ３１は、ルール処理の複数の「待ち行列」が存在できるようにし、「待ち行列」ごとに、分析待ち行列３２が当該「待ち行列」を処理するために生成される。例えば、分析マネージャ３１は、分析待ち行列３２を作成して、３０分ごとに１回実行される装置タイプ「ネットワーク・スイッチ」に対する全てのルールを処理することができ、同時に、別の分析待ち行列３２にルール「緊急ブレーキ障害検出」を１００ミリ秒ごとに実行させることができる。

存在しうる分析待ち行列３２または各々トップ・レベルの機能を有する分析待ち行列３２の数には制限（即ち、分析待ち行列に「クラス」もしくはルールのみを割り当てることができるかどうか、または、単一のルールを分析待ち行列に割り当てることができるかどうか、または、分析待ち行列に特定の装置インスタンスもしくは装置タイプに対する全てのルールを割り当てることができるかどうか等）はない。分析エンジン・マネージャ３１は義務を分析待ち行列に割り当てるべきであり、分析エンジン・マネージャは１つまたは複数の分析待ち行列を管理することができる。本発明により、分析待ち行列３２の数とその割り当てられたタスクの数を動的に割り当て、変更することもできるが、これは要件ではない。

分析エンジン・マネージャ３１がタスクを分析待ち行列に割り当てる方法は、実装上の詳細事項であると考えられる。例えば、分析待ち行列の数とそのタスクの数を定義する構成ファイルが使用されるかどうか、または、ユーザ入力がグラフィカル・ユーザ・インタフェースを介して求められるかどうか、割当てを分析待ち行列に行う実際の機構は、実装で定義される。

分析待ち行列３２は、分析エンジン・マネージャ３１により分析待ち行列３２に割り当てられたルールを処理する役割を担う。分析待ち行列３２はまた、「不良」データが検出されたときの措置を取る役割を担う。取られる実際の措置は、実装で定義されるものと考えられ、ルールで定義すべきであるが、システムは以下の機能を可能とすべきである。

ａ）分析待ち行列３２は、分析マネージャがデータベース・サービス・インタフェースを介してデータベース・サービスにログインできるように、障害および全ての利用可能な詳細事項を分析マネージャに通知すべきである。
ｂ）複数レベルの動作を定義してもよい。例えば、何らかの障害により、「警告」条件をトリガし、他の障害により「アラーム」をトリガしてもよい。「警告」条件により、「警告」条件がトリガされなければ正常に処理されないはずである特定のルールが処理される（このように、ルールの正常な処理をより高いレベルで行ってもよい。すると、特定のケースでのみ、問題の正確な原因を発見するために特定のデータ点がチェックされるはずである）。
ｃ）分析待ち行列３２は、オンデマンド・データ収集を可能とするように分析エンジン・マネージャに通知することができる。当該分析エンジン・マネージャは、データベース・サービス・インタフェースを介してデータベース・サービスに対して当該通知を中継するはずである。このように、分析待ち行列は、現在利用可能であるかもしれないより新しいデータを用いて疑わしいルールを処理し続けることができる。
ｄ）分析待ち行列３２は、その割り当てられた処理頻度を一時的に増加させることができる。例えば、境界条件が検出された場合には、分析待ち行列はオンデマンド・データ収集をトリガすることができ、割り当てられた速度よりも早い速度で疑わしいルールを処理して、実際に障害が発生したかどうかを判断し、境界条件がもはや存在しないかまたは一定時間制限が経過したら、処理を割り当てられた頻度に戻す。時間制限の経過自体を、独自に定義された動作を用いて障害として解釈してもよいことに留意されたい。
ｅ）分析待ち行列３２は、外部インタフェース（複数可）を介してアラームを外部インタフェースに対して生成してもよい。例えば、鉄道信号システムでは、分析待ち行列が、障害が検出されたときアラームを中央制御センタに対してトリガしてもよく、または、電子メールを保守担当員に対して生成してもよい。

外部インタフェース（複数可）３３は実装により定義される。外部インタフェース（複数可）３３は、分析エンジン・マネージャ３１および分析待ち行列３２が外部システムと通信できるようにする。当該通信機構とその正確な目的は実装により定義されるが、種々の例には、アラームを外部システムに中継すること、メッセージを生成して保守作業をトリガすること、追加の情報を取り出すこと（当該追加の情報を使用することは可能であるが、推奨はされない。なぜならば、診断値を有する任意のデータを、分析エンジンによって直接ではなくデータ・コレクタにより収集すべきであるからである）、外部システムに対して、ソリューションの全てのコンポーネントが機能していることを通知すること（「ハートビート」メッセージ）、および分析エンジン１１の複数のインスタンス間の調整、が含まれる。

上述のように、ソリューションのデプロイメントが分析エンジン１１の複数のインスタンスをデプロイしてもよく、当該ソリューションにより各インスタンスが独立に動作することができる。特定の実装形態では、分析エンジン１１の全てのインスタンスにその作業を調整させることが有利であるかもしれない。したがって、本発明ではこれを可能とするが、それを外部インタフェースとして扱う。なぜならば、本発明には当該機能は必要ないからである。

データ・コレクタ（複数可）１２は、図４でより詳細に図示され、データをデータ・ソースから収集し、当該データを格納しさらに分析するためにデータベース・サービス１０に渡す役割を担う。当該コンポーネントは、収集されているデータのネイティブ・フォーマットと当該データを収集する物理的な方法とを理解する役割を担う。

データ・コレクタ１２は、データベース１０とインタフェースするためのデータベース・サービス・インタフェース４０と、様々な装置とインタフェースするための装置インタフェース４１と、データベース・サービス・モジュール１０に転送する前にデータをステージングするためのデータ・ステージング・モジュール４２と、データの様々な装置からの収集を管理しデータをデータベース・サービス・モジュール１０に転送するためのデータ収集マネージャとを備える。

ワークステーション１３は、エンドユーザ・インタフェースを表す。当該ユーザ・インタフェースとして、ワークステーション１３の機能の大多数が実装により定義される。実際、本発明では上で列挙した制約以外、当該ワークステーションに関して何ら構造を強制しない。ワークステーション１３で実装すべき機能には、データベース・サービスにより格納されたデータをユーザが参照できるようにすること、分析エンジンにより使用されるルールをユーザが参照し、修正し、生成し、または削除できるようにすること、データベース・サービスにより格納されたデータに対してユーザがルールを実行できるようにすることが含まれる。処理されているこれらのルールの結果がアラームを生成するかどうかは実装に固有であるが、これらの結果を報告させないことに利点がある。このように、ユーザは生のデータに対して新たなルールを「テスト」することができる。

当該ワークステーションは、追加の保守機能を取り込むべきである。これらの機能はデプロイメントの観点からはソリューションの一部ではないが、全ての保守動作に対して集約されたツールを設けるのが有利である。

ワークステーションはまた、全ての機能を実行するためのユーザ・ログインおよびアクセス・レベルを利用すべきである。これにより、ワークステーションを使用して１組の中心的なルールの修正のような機能を実施することができるが、この機能が特定のユーザに対してしか拡張されないことが保証される。

最後に、ワークステーションは、データをターゲットから直接収集し、当該データがあたかもデータ・コレクタから来たかのように当該データをデータベース・サービスに中継する機能をサポートすべきである。この理由は、データ・コレクタがもはや自動的にデータをターゲットから収集できない場合にデータを収集し分析できることが保証されるからである。

ソフトウェアコンポーネントのより詳細な図を図５に示す。データ収集サービス１２を使用して、監視されている装置からデータを取り出し、当該データをフォーマットし、当該データを診断データベース・サービスに格納する。任意数のデータ・コレクタ・サービスが存在してもよく、各データ・コレクタ・サービスがデータを任意数の装置から収集してもよい。各データ・コレクタ・サービスは診断サーバにインストールされるが、複数のデータ・コレクタを同一の診断サーバにインストールしてもよい。

これらのデータ・コレクタ・サービス１２は、そのパーミッションで実行されているオペレーティング・システムのサービスの形態を取る。各データ・コレクタ・サービスは、次のコンポーネント、即ち、ターゲット・データ収集プロセス６２、データベース・サーバ・インタフェース６０、およびオンデマンド・データ収集プロセス５９を実装しサポートする。

当該データ収集プロセスは、監視されている装置（複数可）からデータを受信し、当該データをデータ・コレクタ・サービスに固有なローカル記憶部に配置する役割を担う。どのようにターゲット装置（複数化）と通信し診断情報をそこから取り出すかを知るのは、このコンポーネントの役割である。例えば、データ収集プロセスは、ＳＮＭＰサーバの形態を取ってもよく、ＳＮＭＰプロトコルを用いて診断情報をルータおよびＡＰから受信してもよい。

監視されている装置タイプに応じて、データ収集プロセスはリモート・データ収集／連結装置（ＤＣＣＤ）の使用を要求してもよい。当該装置は基本的に、診断情報をリモートに収集しデータ収集プロセスに送信するために使用される小型のサブシステムである。これが必要となるはずである例は、無人列車で使用されるＶＯＢＣ（Ｖｅｒｙ ｉｎｔｅｌｌｉｇｅｎｔ Ｏｎ−ｂａｏｒｄ ｃｏｎｔｒｏｌｌｅｒ）から情報を収集することである。ＶＯＢＣは、診断情報を生成できるが当該送信情報を送信できない多数のコンポーネントを有する。このケースでは、ＤＣＣＤはＶＯＢＣとともに存在し、診断プロトコルを使用して情報をＭＰＵ、ＰＩＣＣ、ＥＣＡＮ、およびＣＤＵから収集し、当該データをデータ収集プロセスに送信する前に当該データを連結して圧縮するはずである。ＤＣＣＤはまた、通信障害が発生した場合にデータを手動で取り出せるように、送信されているデータのローカル・バックアップを取外し可能記憶部上で保持する。このため、ＤＣＣＤを利用する各データ・コレクタ・サービスはまた、あたかもデータが直接ＤＣＣＤから取り出されたかのように、データを取外し可能記憶部から取り出して処理するための機構を有する。ＤＣＣＤが独立の物理装置であってもよいが、アーキテクチャの観点からは、ＤＣＣＤはデータ・コレクタ・サービスのデータ収集プロセスの一部であると考える。

データベース・サーバ・インタフェースは、データをデータ・コレクタ・サービスの内部記憶部から取り出して、当該データを診断データベース・サービス１０に送信するためにフォーマットする役割を担う。当該プロセスは、データ収集プロセスにより受信された生のデータを、診断データベース・サービスが要求する標準化されたフォーマットに変換する必要がある。当該方法により、処理されたデータと診断データと明確に分離することができ、したがって、監視されている装置から受信した診断情報にはどのような制約も課されない。

データ収集プロセスとデータベース・サービス・インタフェースの間の中間体として動作する内部データ・ステージング／記憶部は、２つの役割を果たす。第１に、内部データ・ステージング／記憶部により、データをフォーマットし格納するのに要する時間に関して制限のないデータをデータ収集プロセスが取り出すことができ、第２に、受信した生のデータの物理記憶部が存在することができる。この第２の点は、生の診断情報の格納とアーカイブを可能とするので重要である。これは、仮に、取り出された診断データのうち８５％だけが実際にデータベースに格納される（例えば、一部のデータが異質であり分析値を有さない）ケースにおいて有用である。当該データをバックアップすることにより、将来残りの１５％のデータが価値あるものとなった場合に、当該データが依然として収集され履歴データは失われていないであろう。

オンデマンド・データ収集プロセス５９は、帯域外でターゲット装置を問い合わせる役割を担う。当該データ収集プロセスは、常にデータを取り出しているが、それを何らかのスケジュールで行う（例えば、データをそこから収集する必要がある２０個のＶＯＢＣが存在する場合には、何らかのラウンド・ロビン式のポーリングを使用するか、または、ネットワーク帯域幅の制限によりビット速度の制限、したがって、収集速度の制限を設けてもよいと解するのは考えられないわけではない）。直近の診断データが必要なとき、オンデマンド・データ収集プロセスが使用される。分析エンジン・サービス（後述）が直近の診断データが必要であるとその障害検出の過程で判定した場合には、関連するデータ・コレクタ・サービスのオンデマンド・データ収集プロセスを（診断データベース・サービスを介して）要求して即時にデータを指定のダーゲット装置から収集して処理してもよい。当該データは上述のデータ・コレクタ・サービスの標準的な機構を介して取得されるが、オンデマンド・データ収集プロセスにより、オンデマンド・データ収集プロセスが、オンデマンドの収集がもはや必要でないとの通知を診断データベース・サービスから受け取る時まで、当該データ収集プロセスが使用する標準的なスケジュールに関わらず要求データが継続的に収集されることを保証してもよい。

診断データベース・サービス１０は、全ての収集された診断データを格納し、管理し、保護する役割を担う。デプロイメントでは、任意数の診断データベース・サービスを存在させてもよく、その各々を互いと独立に実行することができる。

診断データベース・サービスは、そのパーミッションで実行されるオペレーティング・システムのサービスの形態を取る。当該診断データベース・サービスは、以下のソフトウェアコンポーネント、即ち、ワークステーション・インタフェース５８、データ・コレクタ・インタフェース５６、分析エンジン・インタフェース５５、接続マネージャ・プロセス５７およびデータ管理プロセス５４を含む。

データ管理プロセス５４は、データが容易に分析され効率的に格納されるようにデータをＳＱＬデータベース内で保持する役割を担う。このプロセスは構成可能なスケジュールで実行され、古いデータをアーカイブする役割を担う。データ・コレクタ・インタフェース（および程度の差はあるが、ワークステーション・インタフェース）によりＳＱＬデータベース７０に格納されたデータは、構成可能なスライドするウィンドウに対して保持される。ウィンドウ外にあるＳＱＬデータベース内に見つかったデータは、ファイルにダンプされ、データベースからは除去される。そのコンセプトは、データは設定された時間だけ診断値を有するというものである。当該時間の後は、当該データは古すぎて任意の直近の値を提供することができない。当該データ管理プロセスはまた、ダンプされたデータをＳＱＬデータベースに再投入する役割を担う。当該機能は、必要ならば履歴データを再分析できるように、履歴データを再投入できるようにするために提供される。再投入されているデータはデフォルトでは構成可能なスライドするウィンドウの外部に存在するので、当該データは、データ管理プロセスの次の実行時には再び除去される可能性が高い。

接続マネージャ・プロセス５７は、診断データベース・サービスが提供する様々なインタフェースの動作を監督する役割を担う。当該コンポーネントは、冗長な接続を検出して除去し、或る接続が別の接続の動作を危険に晒さず当該動作に干渉しないことを保証する役割を担う。当該コンポーネントはまた、別のインタフェースに影響を及ぼすインタフェースの何れかにより受信された要求を処理する役割を担う。例えば、分析エンジン・インタフェース１１が、オンデマンド・データ収集の要求を分析エンジン・サービスから受信した場合には、もしあれば、そのように要求したデータ・コレクタ・インタフェースのうちどれに送るべきかを判定する役割を担うのは接続マネージャ・プロセス５７である。

当該データ・コレクタ・インタフェースは、診断データベース・サービスと任意数のデータ・コレクタ・サービスの間の通信を維持する役割を担う。当該コンポーネントは、データ・コレクタ・サービスと実際の物理データ記憶（ＳＱＬデータベース）の間の分離レベルを提供するために存在する。当該コンポーネントは、データ・コレクタ・サービスが行った記憶に対する全ての要求を検証して、データ・コレクタ・サービスが担当するデータのみが記憶されることを保証する役割を担う。これは、複数のデータ・コレクタ・サービスが不用意にそれぞれの他のデータを破壊しないことを保証するために行われる。当該インタフェースはまた、データ・コレクタ・サービスによる任意の要求を検証して、新たな装置タイプ、装置インスタンス、またはデータ・タイプを定義する役割を担う。当該インタフェースはまた、分析エンジン・インタフェースがオンデマンド・データ収集の要求を受信するたびにデータ・コレクタ・サービスへの通知を処理する。

分析エンジン・インタフェース５５は、診断データベース・サービスと任意数の分析エンジン・サービスとの間の通信を維持する役割を担う。当該コンポーネントは、分析エンジン・サービスと実際の物理データ記憶（ＳＱＬデータベース）の間の分離レベルを提供するために存在する。当該コンポーネントは、分析エンジンが生成したルールおよびデータに対する全ての要求を検証し、これらの要求を適切であるとしてサービスする役割を担う。さらに、当該インタフェースは、オンデマンド・データ収集の通知を受信し、当該通知を接続マネージャ・プロセスに渡して処理し、障害の通知を、それをＳＱＬデータベースに記録できるように受信する役割を担う。

ワークステーション・インタフェース５８は、診断データベース・サービスと任意数の診断ワークステーションの間の通信を維持する役割を担う。当該コンポーネントは、診断データベース・サービスが保持するデータが診断ワークステーションにより偶然に危険に晒されないことを保証するために存在する。当該コンポーネントは、診断ワークステーションにより当該コンポーネントに送信された要求を実行の過程において実行する。これらの要求は以下から成る。
・データ・セットを、ワークステーションで分析し参照するために、診断データベース・サービスから取り出すこと
・ルールを診断ワークステーションのローカル記憶部にアップロードすること（ワークステーションのルールを、診断データベース・サービスにより格納されたルールと同期すること）
・新たなルールを診断ワークステーションから診断データベース・サービスにダウンロードすること
・新たな保守記録を格納のためにアップロードし、診断データベース・サービス上にアーカイブすること
・アーカイブされた保守記録を参照のために取り出すこと
・診断ワークステーションにより直接収集されたデータを診断データベース・サーバにアップロードすること

ルールを扱う要求は、１組の「コア」ルールが診断データベース・サービス上に存在でき、各診断ワークステーションが（メイン・ルールと再同期できる）１組のその独自のルールを有することができるようにするために存在する。このように、分析エンジン・サービスにより実施されるオンライン・データ分析の完全性が維持され、保守者が診断ワークステーションを用いて新たなルールをオフラインで作成しテストすることができる。

分析値を有する新たなルールが見つかった場合には、当該ルールを診断データベース・サービスに送信して、メイン・ルールとオンライン・データ分析に含めることができ、他の診断ワークステーションが同期を行うことにより当該ルールを取得することができる。新たなルールが診断データベース・サービスにアップロードされるたびに、バックアップ・コピーが既存のルールから作成され、修正がＳＱＬデータベースに記録される。

分析エンジン・サービス１１を使用して、診断データベース・サービスにより格納されたデータを分析し、障害または潜在的な障害を検出し、システムのユーザにその旨を通知する。当該診断システムは、任意数の診断サーバにインストールした任意数の分析エンジン・サービスをサポートすることができる。

分析エンジン・サービスは、３つのコンポーネント、即ち、データベース・サーバ・インタフェース５０、分析プロセス（複数可）５１、および分析スレッド管理プロセス５３を有する。

データベース・サーバ・インタフェース５０は、診断データベース・サーバとの通信を確立し維持する役割を担う。当該コンポーネントは、分析エンジン・サービスの他のコンポーネントからの全てのデータ要求を処理し、これらの要求をフォーマットして診断データベース・サーバに送信する役割を担う。同様に、当該コンポーネントは、診断データベース・サーバに対する応答を、要求を開始したコンポーネントに戻す役割を担う。データベース・サーバ・インタフェースは、これらの要求が別の装置に対して行われているという事実を抽象化しつつこれらの機能を提供する役割を担い、分析エンジン・サービスの他のコンポーネントに対しては、データ要求があたかもローカルに処理されたかのように見える。

分析スレッド管理プロセス５３は、分析プロセス（複数可）の動作と同期の役割を担う。当該コンポーネントは、現在分析エンジン・サービス内部で実行されている全ての分析プロセスを開始し維持する役割を担う。当該コンポーネントは、分析プロセスを作成するとき、当該プロセスが実行されるべきルールおよびデータ・セットの待ち行列を、当該プロセスに提供する。ルールおよびデータ・セットの待ち行列全体をタイムリに分析することを保証し、これを行うための十分な分析プロセスとシステム・リソースが存在することを保証するのは、分析スレッド管理プロセスの役割である。

分析プロセス５３は、データをルールに対して実際に分析する役割を担う。当該コンポーネントは、データおよびルールを必要に応じてデータベース・サーバ・インタフェースに要求し、分析スレッド管理プロセスにより当該コンポーネントに与えられたミッションを遂行する。しかし、分析プロセス５３は、当該コンポーネントがどのようにミッションを実行するかを自律的に制御する。閾値に達したことを分析プロセスが検出した場合、または、オンデマンド・データ収集が必要な場合には、必要に応じてそのミッションを修正しかつ／またはオンデマンド・データ収集を要求するのは自由である。障害が発生したことを分析プロセスが検出した場合には、当該分析プロセスは、ＡＴＳに対してアラームをトリガし、データベース・サーバ・インタフェースを介して当該アラームを記録する役割を担う。

診断ワークステーション１３は、保守および学術上の目的で診断データベース・サービスで収集したデータを参照し分析するために使用される。診断システムは、任意数の診断ワークステーションのインスタンスをサポートできるが、インストールされる診断ワークステーションはどの１つの物理ＰＣでも１つだけである。診断ワークステーションを、診断サーバにインストールし、これらのＰＣにインストールされた他の任意のソフトウェアを診断サーバにインストールしてもよい。

これらの診断ワークステーションは、５つのコンポーネント、即ち、データベース・サーバ・インタフェース６３、保守ログ・ビューワ６４、ルール・エディタ６６、データ・ビューワ／アナライザ６８、およびターゲット装置インタフェース６９を有する。

データベース・サーバ・インタフェース６３は、診断データベース・サーバとの通信を確立し維持する役割を担う。当該コンポーネントは、診断ワークステーションの他のコンポーネントからの全てのデータ要求またはアップロードを処理し、これらの要求をフォーマットして診断データベース・サーバに送信する役割を担う。同様に、当該コンポーネントは、診断データベース・サーバに対する応答を、要求を開始したコンポーネントに戻す役割を担う。データベース・サーバ・インタフェースは、これらの要求が別の装置に対して行われているという事実を抽象化しつつこれらの機能を提供する役割を担い、診断ワークステーションの他のコンポーネントに対しては、データ要求があたかもローカルに処理されたかのように見える。

保守ログ・ビューワ・コンポーネント６４は、診断データベース・サービスに格納するための保守記録をユーザが作成し更新できるようにするために使用される。保守記録は、診断データベース・サービスに格納され、装置と関連付けられる。保守ログ・ビューワを使用して、特定の装置に関する保守記録の履歴を、参照のために診断データベース・サービスから取り出すこともできる。

診断ワークステーションのルール・エディタコンポーネント６６により、ユーザはワークステーションのルール・ローカル記憶部を、診断データベース・サービスが格納した中央ルール・リポジトリと同期することができる。診断ワークステーションは２つの異なる組のルールを有する。即ち、過去にローカルにしか存在しなかったルールと、ローカルの、ユーザが修正可能な、中央に格納されたルールのコピーとである。同期動作により、中央に格納されたルールのローカル・コピーのみがマージされ、当該動作が完了したときには、中央に格納されたルールのローカル・コピーが、診断データベース・サービスに格納されたルールと一致している。当該コンポーネントを使用して、中央記憶部から受信したルールのローカル・コピーを含む、診断ワークステーションにローカルに格納されたルールを参照し修正することもできる。当該コンポーネントを使用して、新たなルールを、ローカルのみのルール記憶部かまたは中央ルールのローカル・コピー（この場合、中央との同期のために当該ルールに対してフラグを立てる）の何れかに作成することができる。

データ・ビューワ／アナライザ・コンポーネント６８は、診断データベース・サービスにより格納されたデータまたは診断データベース・サービスによりファイルにダンプされたデータを参照するために使用される。ルール・ローカル記憶部からルールを適用することによってデータを分析してもいが、このように検出された任意のアラームまたはエラー条件はＡＴＳには送信されない。これを行うことにより、ユーザは誤ったアラームまたは疑わしいアラームをトリガすることなく新たなルールをテストすることができる。診断データベース・サービス上のデータを単純に、ユーザがデータのトレンドをグラフィカルに参照できるようにするためのトレンディング・グラフとして参照してもよい。システムのどのコンポーネントがより頻繁にまたはより低い頻度で使用されるかを分析することにより、ユーザが予防的な保守戦略を練ることができるように当該機能を設計する。その１例は、どのスイッチがより頻繁に動くかを判定し、あまり使用されない切替装置と比べて、それらの切替装置を保守の対象とするものであろう。当該コンポーネントにより、ユーザは、分析エンジン・サービスにより診断データベース・サービスに格納されている任意のアラームを参照することもできる。これらのアラーム通知から、ユーザはアラームをトリガした特定のデータ・セットを参照することができる。

ターゲット装置インタフェース６９は、データ・コレクタ・サービスが装置からデータを取り出すことができない場合に、当該装置からデータを収集する役割を担う。当該コンポーネントは、様々な装置タイプからのデータ収集を可能とするためのプラグイン・アーキテクチャを用いて設計される。当該プラグインは、特定の装置タイプに対するデータ・コレクタ・サービスの一部として開発されるはずである。なぜならば、当該プラグインは、データ・コレクタ・サービス自体が行う同一の変換機能の大部分を実施しなければならないはずであるからである。当該コンポーネントは、あたかもデータが直接データ・コレクタ・サービスから来たかのように、接続されたものからデータを収集し、当該データを診断データベース・サービスに送信するためにフォーマットする。データ収集サービスがＤＣＣＤを使用するケースでは、ターゲット装置インタフェースが装置に直接接続するのではなく、ＤＣＣＤに接続することが可能である。

ルール・エディタ６６は、２つの主要な機能、即ち、診断ワークステーションのルール・ローカル記憶部内のルールを診断データベース・サービス上の主ルール記憶と同期すること、および、ローカル・ルールをオフラインで生成し修正することを提供する。

図６は、ルール同期イベントの間に発生するイベントのシーケンスを示す。ユーザ通知またはスケジュールにより、ルール・エディタが全てのルールのリストとその階層を、データベース・サーバ・インタフェースを介して診断データベース・サービスに要求する。当該ルール・エディタは次に、中央に格納したルールとその階層のローカル・コピーを取り出す。当該ルール・エディタは次に、両方の組のルールを分析して、ルールごとに、どちらの組のルールがより直近のものかを判定する。次に、各組からの変更をマージして、ルールのローカル・コピーと中央のコピーの両方を更新する。これは重要な相違点である。中央のルールは必ずしもルールのローカルな１組のルールを上書きせず、ローカルな１組のルールも中央のルールを上書きしない。マージ動作を実施して、何れかの場所からの最も直近の変更が保存されることを保証する。ルールの中央のコピーとローカル・コピーとの間で衝突が検出されたときは、中央のルールがルールのローカル・コピーを上書きする。

データ・ビューワ／アナライザ６８は、２つの機能、即ち、診断データベース・サービスに格納されたデータのグラフィカルな表示と、同一データのオフライン分析とを提供する。

図７は、データ・ビューワ／アナライザを使用する際に発生するイベントのシーケンスを示す。ユーザの選択に応じてまたはスケジュールに基づいて、データ・ビューワ／アナライザはデータベース・サーバ・インタフェースを介して診断データベース・サービスを問い合せて利用可能なデータ・セットのリストを取り出す。当該情報が返されると、データ・ビューワ／アナライザは利用可能なデータ・セットをそのローカル・データ記憶部に格納する。ユーザは次に、ローカル・データ記憶部に格納された情報に基づいて、参照するデータ・セットのリストを選択してもよい。ユーザが選択を行うと、要求されたデータ・セットがデータベース・サーバ・インタフェースを介して診断データベース・サービスから取り出される。選択されたデータが取り出されると、当該データもローカル・データ記憶部に格納される。この設計上の決定の背後にあるロジックは、ローカル・リソースを用いるとデータ操作がより速くなり、このデータを存在させることで、ユーザが将来当該データを参照したい場合に、当該データを再び診断データベース・サーバから転送する必要がないということである。

ユーザが選択したデータがローカル・データ記憶部に挿入されると、データ・ビューワ／アナライザは当該データを取り出して、ユーザの選択に基づいてデータのリストまたはグラフの何れかとして当該データを表示する。データ・ビューワ／アナライザにより、ユーザはデータ・セットに対して実行すべき１つまたは複数のルールを選択することもできる。ユーザに提示されるルールのリストは、現在ローカル・ルール記憶部に存在しているルールに基づく。ユーザが１組のルールを選択すると、選択されたデータ・セットに対してこれらのルールが実行され、その分析結果がユーザに提示される。

分析エンジン・サービスは、障害を検出しこれらの障害を報告するために、格納された診断情報をオンラインで分析する役割を担う。図８に示す分析スレッド管理プロセスは、その構成されたルール処理割当ての待ち行列を通じて絶えず反復し、全ての待ち行列が分析プロセスに割り当てられ実行されていることを保証する。ルール待ち行列がアクティブなプロセスに割り当てられない場合には、分析スレッド管理プロセスは新たな分析プロセスをインスタンス化してその待ち行列を当該分析プロセスに割り当てる。

新たに作成された分析プロセスは、次に、与えられた当該待ち行列を分析し、当該待ち行列内の次のルールを処理するのにどのルールとデータ・セットが必要かを判定する。当該分析プロセスは次に、関連データを取り出すようにデータベース・サーバ・インタフェースに通知する。当該データが分析プロセスに返されると、分析プロセスはルールを実行して、当該データが当該ルールを渡したかどうかを判定する。この時点で、分析プロセスには辿ることができる多数の分岐がある。当該データが当該ルールを渡した場合には、分析プロセスは単純に、実行すべき次のルールを決定し、当該次のルールに対して取った最新の措置を繰り返す。データ・セットが当該ルールを渡すことができなかった場合には、３つの事項のうち１つが発生しうる。障害により子ルールの処理がトリガされるとルールが規定する場合には、分析プロセスは単純に子ルールのパスを実行し始める。ルールがオンデマンドのデータ収集をトリガする場合には、分析プロセスはその要求をデータベース・サーバ・インタフェースに対して生成する。データベース・サーバ・インタフェースは次にこの要求を診断データベース・サービスに中継する。分析プロセスは次に、別の反応がトリガされるように、ルールが渡されるかまたはルールが失敗するかの何れかであるまで、任意の新たに利用可能なデータを用いて当該ルールを常に再分析する。障害がアラームを生じさせなければならないとルールが規定する場合には、分析プロセスはアラームをＡＴＳに対して生成し、データベース・サーバ・インタフェースを介して当該アラームとその全ての詳細を診断データベース・サービスに記録する。

分析プロセスは、分析スレッド管理プロセスが停止するように命令するかまたは分析スレッド管理プロセスに割り当てられた待ち行列が停止すべきと指定するまで、そのルールの待ち行列を常に実行する。

データ・コレクタ・サービスは、監視されている装置からデータを取り出し、当該データを診断データベース・サービスに格納するために使用される。当該インタフェースの記述では、表示されるデータ・コレクタ・サービスがデータ収集／連結装置を使用することを前提としているが、イベントのシーケンスは、そのようなリモート・データ収集が必要でないインスタンスにおけるものと同様であるはずである。図９に示すターゲット・データ収集プロセスおよびデータベース・サービス・インタフェースはそれぞれ、外部の影響を受けずに独自の内部スケジュールを実行する。データベース・サーバ・インタフェースは、内部データ・ステージング／記憶部を定期的にチェックして、何らかのデータがフォーマットに利用できるかどうかを確認する。データが見つかった場合には、データベース・サービス・インタフェースは当該データを処理して、診断データベース・サービスに送信するためにフォーマットする。データ・セットが送信されると、データベース・サービス・インタフェースは、処理されたとしてソース・データにフラグを立て、アーカイブするためにマークする。

ターゲット・データ収集プロセスは、監視されている装置からデータを取り出すために使用される内部スケジュールを実行する。当該スケジュールは、データ・コレクタ・サービスの各実装に固有である。何らかの時点で、ターゲット・データ収集プロセスは特定の装置に診断情報を問い合わせる時であると判定する。その時点で、ターゲット・データ収集プロセスは、監視されている装置から診断情報を取り出す。上の図では、データ収集／連結装置を介してこれを行う。最終的には、ターゲット・データ収集プロセスが診断データを取り出し、データベース・サービス・インタフェースが取得するために当該診断データを内部データ・ステージング／記憶部に格納する。

診断データベース・サーバは、その独自の内部処理の過程で、データベース・サービス・インタフェースを介してオンデマンド・データ収集通知をデータ・コレクタ・サービスに中継してもよい。これを行うとき、データベース・サービス・インタフェースは当該通知をオンデマンド・データ収集プロセスに中継する。当該オンデマンド・データ収集プロセスは、ターゲット・データ収集プロセスに対して、その内部スケジュールを一時停止して診断データを指定の装置から取り出し始めるように通知する。これは、データベース・サービス・インタフェースが診断データベース・サービスからオンデマンド・データ収集を停止する通知を受信する時まで続く。

本明細書のどのブロック図も、本発明の原理を具体化する例示的な回路の概念図を表すことは当業者には理解されよう。本発明をプロセッサ上で実装してもよい。当該プロセッサを、専用ハードウェアならびに適切なソフトウェアと関連してソフトウェアを実行できるハードウェアを使用することにより提供してもよい。プロセッサにより提供するときは、諸機能を、単一の専用プロセッサによって、単一の共有プロセッサによって、またはそのうち幾つかを共有できる複数の個々のプロセッサによって提供してもよい。さらに、「プロセッサ」という用語を明示的に使用することが、ソフトウェアを実行できるハードウェアを排他的に指すと解釈すべきではなく、限定ではなく、ＤＳＰ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）ハードウェア、ネットワークプロセッサ、ＡＳＩＣ（ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）、ＦＰＧＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ソフトウェアを格納するためのＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、および不揮発性記憶部を暗示的に含んでもよい。従来型および／またはカスタムの他のハードウェアを含めてもよい。回路という用語は、本明細書では、実際にソフトウェアで実装できる機能ブロックを包含するように使用される。

１０ データベース・サービス
１１ 分析エンジン
１２ データ・コレクタ
１３ ワークステーション
２０ データ・コレクタ・インタフェース
２１ データ管理プロセス
２２ データ記憶サブシステム
２４ メモリ
２５ ワークステーション・インタフェース
２６ 分析エンジン・インタフェース

Claims (32)

1. 複数の装置からのデータを分析するためのデータ分析システムであって、
   様々な装置から収集したデータを格納するデータ記憶サブシステムを備えたデータベース・サービス・モジュールであって、前記データは前記データを分類するためのプリミティブを用いてメタ構造に格納されるデータベース・サービス・モジュールと、
   前記データを分析して、前記メタ構造により定義された前記データが特定の基準を満たすかどうかを１組の格納されたルールに従って判定するための分析エンジンと、
   を備える、データ分析システム。
2. 前記プリミティブは装置タイプ、装置インスタンス、およびデータ・タイプを含み、装置タイプは、前記データのソースである装置のタイプを決定し、装置インスタンスは、前記データのソースである装置タイプにおける特定の装置を特定し、データ・タイプは格納されたデータの性質を示す、請求項１に記載のデータ分析システム。
3. 前記装置タイプは前記データのソースを構成する前記装置のステータスを含む、請求項２に記載のデータ分析システム。
4. 前記ルールは、前記データベース・サービス・モジュールの一部を形成するデータベースに格納される、請求項１乃至３の何れか１項に記載のデータ分析システム。
5. 前記データベース・サービス・モジュールはさらに、データ・コレクタ・インタフェースと、前記データ・コレクタを介して複数の装置からデータを受信し、前記メタ構造に従って前記データを前記データ記憶サブシステムに格納するためのデータ管理処理モジュールとをさらに備える、請求項１乃至４の何れか１項に記載のデータ分析システム。
6. 前記データ記憶サブシステムはＳＱＬデータベースである、請求項１乃至５の何れか１項に記載のデータ分析システム。
7. 前記分析エンジンは、どのルールがどの順序でどの種類の装置または装置インスタンスに対して実行されるかを判定し、前記ルールが処理される頻度を判定するための分析エンジン・マネージャを備える、請求項１乃至６の何れか１項に記載のデータ分析システム。
8. 前記分析エンジン・マネージャはさらに、前記分析エンジン・マネージャにより分析待ち行列モジュールに割り当てられたルールを処理するための前記分析待ち行列モジュールをさらに備える、請求項７に記載のデータ分析システム。
9. 前記分析待ち行列モジュールは、処理されたデータが特定の基準を満たすことに対して警告通知を発するように構成される、請求項８に記載のデータ分析システム。
10. 前記分析待ち行列モジュールは、処理されたデータが特定の基準を満たすことに応答して他のルールの処理をトリガするように構成される、請求項９に記載のデータ分析システム。
11. 前記分析待ち行列モジュールは、特定の基準を満たす特定のルールの下で前記データが処理されたことに応答して、オンデマンド・データ収集をトリガするように構成される、請求項９に記載のデータ分析システム。
12. 前記待ち行列分析モジュールは、前記オンデマンドのデータの処理を、前記特定のルールの下で処理されたデータよりも高い頻度でトリガするように構成される、請求項１１に記載のデータ分析システム。
13. 装置インタフェースを介した複数の装置からのデータ収集を管理し、データベース・サービス・インタフェースを介して前記データベース・サービス・モジュールと通信するためのデータ収集マネージャを備えたデータ収集サービス・モジュールをさらに備える、請求項５に記載のデータ分析システム。
14. 前記データ収集サービス・モジュールは、前記データベース・サービス・モジュールに転送する前に一時的にデータをステージングするためのデータ・ステージング・モジュールを備える、請求項１３に記載のデータ分析システム。
15. ユーザが前記データベース・サービス・モジュールに格納されたデータを参照でき前記分析エンジンにより使用されるようにルールを構成できるようにするワークステーション・モジュールをさらに備える、請求項１３に記載のデータ分析システム。
16. 前記ワークステーションは、ユーザが前記データベース・サービス・モジュールにより格納された特定のデータに対して特定のルールを実行できるようにするように構成される、請求項１乃至１６の何れか１項に記載のデータ分析システム。
17. 複数の装置からのデータを分析する方法であって、
    様々な装置からのデータを進行中に収集するステップと、
    データベース・サービス・モジュールのデータ記憶サブシステムにおいて収集したデータを、プリミティブを用いて前記データを分類するメタ構造に格納するステップと、
    前記データを分析して、前記メタ構造により定義された前記データが特定の基準を満たすかどうかを１組の格納されたルールに従って判定するステップと、
    を含む、方法。
18. 前記プリミティブは、装置タイプ、装置インスタンス、およびデータ・タイプを含み、装置タイプは前記データのソースである装置のタイプを決定し、装置インスタンスは前記データのソースである装置タイプにおける特定の装置を特定し、データ・タイプは格納されたデータの性質を特定する、請求項１７に記載の方法。
19. 前記装置タイプは、前記データのソースを構成する装置のステータスを含む、請求項１７または１８に記載の方法。
20. 前記データベース・サービス・モジュールの一部を形成するデータベースに前記ルールを格納するステップをさらに含む、請求項１７乃至１９の何れか１項に記載の方法。
21. 前記分析エンジンは、どのルールがどの順序でどの種類の装置または装置インスタンスに対して実行されるかを判定し、前記ルールが処理される頻度を判定する、請求項１７乃至２０の何れか１項に記載の方法。
22. 前記分析エンジンは、処理されたデータが特定の基準を満たすことに対して警告通知を発する、請求項２１に記載の方法。
23. 前記分析エンジンは、処理されたデータが特定の基準を満たすことに応答して他のルールの処理をトリガする、請求項２２に記載の方法。
24. 前記分析エンジンは、特定の基準を満たす特定のルールの下で前記データが処理されたことに応答して、オンデマンド・データ収集をトリガする請求項２２に記載の方法。
25. 前記分析エンジンは、前記オンデマンドのデータの処理を、前記特定のルールの下で処理されたデータよりも高い頻度でトリガする、請求項２４に記載の方法。
26. 収集されたデータは、前記データベース・サービス・モジュールに転送する前に一時的にステージングされる、請求項１７乃至２５の何れか１項に記載の方法。
27. 前記データベース・サービス・モジュールに格納された前記データをユーザが参照するために供給するステップをさらに含む、請求項１７乃至１９の何れか１項に記載の方法。
28. ユーザ・インタフェースを介して前記分析エンジンにより使用するようにルールを構成するステップをさらに含む、請求項１７乃至２７の何れか１項に記載の方法。
29. ユーザ・インタフェースを介して前記データベース・サービス・モジュールにより格納された特定のデータに対して、特定のルールの実行を指令するステップをさらに含む、請求項２８に記載の方法。
30. 複数の装置からのデータを分析するためのデータ分析システムであって、
    進行中に様々な装置からデータを収集するためのデータ・コレクタと、
    様々な装置から収集したデータを格納するデータ記憶サブシステムであって、前記データは前記データを分類するためのプリミティブを用いてメタ構造に格納されるデータ記憶サブシステムを備えた、データベース・サービス・モジュールと、
    前記データを分析して、前記メタ構造により定義された前記データが特定の基準を満たすかどうかを１組の格納されたルールに従って判定するための分析エンジンと、
    前記システムの動作を制御するためのユーザ・インタフェースを提供するワークステーションと、
    を備える、データ分析システム。
31. 前記ワークステーションは、前記ユーザが格納された１組のルールを生成し修正できるようにするように構成される、請求項３０に記載のデータ分析システム。
32. 前記ワークステーションは、前記ユーザが前記システムに格納された特定のルールを実行できるようにするように構成される、請求項３０または３１に記載のデータ分析システム。

Images