JP5283905B2 - 自動遠隔監視及び診断サービス方法とシステム - Google Patents

Description

本発明は、一般的に云えば、複合システムのサービスの分野に関するものであり、より具体的には、サービス・データを知識ベースに統合して、サービス提案(service recommendation)、サービス提案の優先順位付け、並びに、必要に応じて、システム・スナップショットによるシステム・データの作成及び処理について改善した定式化を行えるようにする手法に関するものである。

複合システムに対して遠隔及び現地サービスを提供するために様々な手法が開発されている。システムが遠隔接続のための設備を持たない場合、従来の手法はある種のセルフサービス手順を必要としていた。これらは典型的には幾分か限界があり、最終的には、機能不良又は異常状態を評価し、サービスを提案し、そして部品の交換、再構成などのような或る特定のサービスを遂行することのできる有資格のサービス技師の訪問を必要とすることがある。

また遠隔サービスのための他の様々な手法が開発されている。例えば、医学的診断の分野では、或るシステム、特により複雑で工学的なシステム（例えば、医学的診断用イメージング装置）は遠隔接続のための設備を持っていることがある。このようなシステムは、動作上のサービスについての要求をサービス提供者に、直接に又は組織的メッセージ伝送方式を介して送ることができる。或る手法では、遠隔の提供者は自動的に要求を処理すること、例えば、要求をサービス待ち行列に入れて、通知を発信元のサービス要求者に返送することができる。しかしながら、この分野での現在の技術は、一般に、サービス・システムから離れた場所にいるサービス技師が最終的にサービス要求に対処することに依存している。技師の知識と技師に利用できる資料とに基づいて、サービス提案を行うことができ、またサービス技術者を派遣することができ、又はその他の手順を続けることができる。

このような手法はサービス、特に遠隔サービスを提供するのに有用であるが、欠点がないわけではない。例えば、既存の巧妙なサービス手順は、最終的にはサービス技師又は関心のあるサービスを取り扱う他の技術者の知識及び経験に依存していることが多い。現在、サービス提供者に利用可能になったときに広範なデータを役立てるために、追加の情報にアクセスすることによってサービス要求を自動的に取り扱うことのできるシステムは、一般に入手可能ではない。

同様に、サービス要求及び応答の優先順位付けは一般に極めて受動的なものである。任意の優先順位付けが当該分野で実施される限りにおいて、これは一般に「先着順」処理に基づくものであり、関連要因に基づく再優先順位付けは殆ど無いか又は全くない。例えば、再優先順位付けは、単純に、電話、緊急メッセージなどによってサービス要求者からサービス提供者へ伝えられる緊急性に基づくものであることがある。

最後に、現在の手法は、一般にサービスの必要性の完全な評価のための基礎を提供していない。或るシステムは、エラー記録、特定のシステム・ファイルなど取ることができるが、一般に「スナップ・ショット」の形態のより完全な画像を提供していない。より詳しく述べると、現在の手法は一般に、サービス可能な事象の根本的原因であり得る装置構成の評価を考慮していない。
欧州特許公開ＥＰ１１９５６８１Ａ号

従って、システム・サービスの分野、特に複合システムの遠隔サービスの分野において更なる改善の必要性がある。

本発明は、このような必要性に対応するように設計された新規なシステム・サービス手法を提供する。本手法は広範囲の環境に適用できるが、特に遠隔のサービス提供者による複合システムの遠隔サービスによく適している。本手法を適用する関心のある特定の分野としては、医学的診断用装置、並びに信頼性及び動作可能時間が重要である他のシステムを挙げることができる。このようなシステムでは、多くのシステム因子の先行遠隔サービスが、システムの生産性を維持するための最も効率の良い方法であるかもしれず、本発明手法はこれに基づいてサービス要求に対処するためのツールを提供する。

被サービス・システム（サービスを受けるシステム）におけるサービス可能な事象(seviceable event)又は状態は、性能パラメータ、動作パラメータ、エラー記録などのようなインジケータ(indicator) を参照することによって検出することができる。それに応じて、サービス要求を自動的に生成することができる。サービス要求は、システム内の状態、典型的には、異常状態にサービスする必要があることをサービス提供者に効果的に知らせる。この要求に基づいて、サービス提供者は、サービス・データ、優先順位付けデータ、サービス提案データなどが記憶されている統合サービス知識ベース（ＩＳＫＢ）にアクセスすることができる。

また、サービス要求に応答して、優先順位付けをサービス提供者によって遂行することができる。このような優先順位付けは、単一のシステム内のサービス可能な状態に対する複数の異なる応答に優先順位を付けることができるが、またサービス提供者が複数の異なるシステムにサービスするときのように、複数のシステムの間でのサービス応答についての優先順位付けも含むことができる。優先順位付けは優先順位付けスコア(score) に基づいて定めることができ、またこれらはＩＳＫＢに記憶させることができる。

本発明手法はまた、サービス可能な状態又は事象の発生時にシステム・スナップショットを取得する段階を設ける。システム・スナップショットは、或る範囲のシステム・データを含むことができるが、有利な点として、システムからの他のデータと相関させ且つサービス可能な状態又は事象の評価のために使用することが可能であるハードウエア構成データを含む。現在考えられる実施形態では、ハードウエア構成データは、システム内に組み込まれた構成要素の表示と共に、サービス可能な状態、事象又は機能不良の根本的原因である可能性のある周辺装置又は他のハードウエアの表示を提供する。

本発明手法はまた、ＩＳＫＢを生成及び利用する。ＩＳＫＢは、広範囲のソース(source)からデータを集め、整理し且つ相関させることができ、また一般に１つ以上の種類及び構成の被サービス・システムに関係する。ＩＳＫＢは、典型的には、システムを識別するデータ、既知の異常状態又はサービス可能な事象を識別するデータ、システムにサービスするための可能性のある応答及び提案を表すデータなどを含む。ＩＳＫＢはまた、単一のシステムのため及び一連のシステム及び状況のためのサービス提案に優先順位を付けるために使用される優先順位付け情報を含むことができる。前に述べたように、ＩＳＫＢは、自動的にサービス要求に応答し且つそれらの応答に優先順位を付ける際に使用することができる。

本発明のこれらの及び他の特徴、側面及び利点は、添付の図面を参照して以下の詳しい説明を読むことによってより良く理解されよう。添付の図面では、図面全体にわたって同様な要素には同じ参照符号を付している。

次に図面について説明すると、先ず図１には、特に被サービス・システムとサービス提供者との間の遠隔の接続を介して、複合システムにサービスするためのシステム１０を図式的に例示する。当業者に理解されるように、このような複合システムは様々な種類のものであってよく、また多くのこのようなシステムは本発明手法によってサービスすることができる。例えば、模範的な具現例では、被サービス・システムは、公共施設、診療所、病院などに配置することのできる医学的診断用装置を含むものである。このような装置は、システムへ直接に接続することによって、或いは公共施設内のデータ管理システムのような中間手段を介して、又は中間データ交換提供者によって遠隔にサービスされることができる。例えば、中間データ交換提供者は、サービス要求、システム・データ、メッセージなどを記憶し、且つこのデータを、実際のサービスをシステムに提供するための最終的に責任のあるサービス提供者に伝送することができる。サービス提供者はまた、サービス要求に応答するためにこのような中間手段を利用することができる。

ここで、本書で用いられる用語「サービス要求」及びこのような要求に対する応答は、異常状態、機能不良などに応答したシステムの動作上のサービスに関するものであることに留意されたい。一般的な意味では、或る分野では、データについての「要求」はサービス要求と呼ぶことができる。このようなデータについての要求は、一般的な意味では、ウェブ・ページ、情報、画像ファイル等々についての要求を含むことができる。しかしながら、これらの要求は、異常な状態及び事象、又は機能不良、或いはこのような状態及び事象の評価又は修理を対象としていないので、本書では「サービス要求」とは見なされない。

図１の例では、システム１０は、ＩＳＫＢシステム１２及びＩＳＫＢに基づくサービス・システム１４を含む、２つの幾分別々であるが相互に依存するシステムを含むものと見なすことできる。本発明手法の特徴の全てが必ずしもＩＳＫＢを作成し又は参照することに依存しているわけではないが、ＩＳＫＢは、サービス提案、優先順位付け、及び本書で述べる他の特徴を提供するのに非常に有用である。ＩＳＫＢシステム１２は、被サービス・システムのサービスに関する或る範囲のソース及びデータを利用するＩＳＫＢ作成システム１６を含む。当業者に理解されるように、また後でより詳しく説明するように、ＩＳＫＢ作成システム１６は、典型的には、以下に述べるサービスを提供するために使用されるデータ相互間の相関、連結及び関係を設定するために、必要なデータを受け取り又は呼び出して、該データを処理することのできる１つ以上のプログラム済みコンピュータを含む。ＩＳＫＢ作成システムは、必要に応じて、ＩＳＫＢのための必要なデータを含むデータベースを利用することのできる単一のコンピュータを含むことができ、或いは処理を協調させた複数のコンピュータを含むことができる。ところで、ＩＳＫＢに含まれているデータの全てを、予め設定されているデータベース又は基準から呼び出すことは必要ではない。データの一部はＩＳＫＢの作成中に手動で入力することができ、また、以下に述べるようにＩＳＫＢの作成中に構造化し分析することができる。

ＩＳＫＢ作成システム１６は一般に、図１に参照数字１８によって表されるようなシステム・データと共に、問題解決策データ２０、関連した点検保守データ２２、インジケータ・データ２４などを利用する。一般的に云えば、システム・データ１８は、様々な種類のシステム、それらの既知の製造情報（例えば、製造場所、製造日付、商品番号、製造番号、構成要素の故障など）を識別することができる。

解決策データ２０は、様々なシステムについて知られている或る範囲の識別された問題及び解決策を含むことができる。例えば、解決策データ２０は、製造時又は最初の引渡し時にシステムにおいて識別された問題についての既知の「フィックス(fix) 」、並びにサービスの経験、現場サービス巡回などによるようなその後に識別された問題及び解決策を識別することができる。解決策データは、ハードウエア構成解決策、ソフトウエア構成解決策、提案された構成要素及び現場交換可能なユニットの交換、等々を含むことができる。

同様に、点検保守データ２２は、典型的には、特定の被サービス・システムについて実施し又は提案することのできる確立された点検保守手順に関する情報を含む。点検保守データ２２は、このような情報を後でサービス要求の受け取り時にシステムから取り出すことができるように、個々のシステム又はユーザに関係付ける必要はない。しかしながら、必要に応じて、このようなシステム固有の情報をＩＳＫＢに含めることができる。

インジケータ・データ２４は、典型的には、起こり得るシステムの機能不良、故障、或いは差し迫ったサービス可能な状態又は事象の観察可能な又は検出可能なインジケータを含む。可能な場合、このようなインジケータ・データは、構成要素相互間、サブシステム相互間のような様々な種類のサービス可能な事象、並びにサービス可能な事象及び状態の究極の根本原因を区別することができる。再び、インジケータ・データ２４は、典型的には、様々な被サービス・システムについての個々のシステムの種類、明細、定義、識別情報などに連結させるか又はそれらと相関可能である。

ここで、本書で用いる用語「インジケータ(indicator) 」又は「インジケータ・データ」は、潜在的にサービス可能な状態の任意の種類の表示を含む。インジケータは、パラメータ（例えば、電流、電圧、様々な信号）、これらのパラメータの組合せ等々であってよいことに留意されたい。或る種のシステムでは、インジケータは、監視又は制御アルゴリズム、傾向判定アルゴリズムなどによって設計し、生成し又は認識することができる。同様に、サービス可能な状態(serviceable condition) は、典型的には、ある種のシステム機能不良を含む。しかしながら、他の状態を検出して、本書で述べるような処理を生じさせることができ、例えば、他の状態には、様々な追跡、点検保守、及びマーケティング機能さえも含まれる。

ＩＳＫＢ作成システム１６によって利用される様々な種類のデータに加えて、様々な分析ルーチン２６を用いることができる。分析ルーチンは、ＩＳＫＢ作成システムを定義するコードの中に組み込むことができ、或いは必要なときにシステム・コードに連結するか又はそれによって利用することができる。例えば、ルーチンは、識別、分析、構造化、インデックス作成、分類、及び以下に述べるその他の処理を可能にすることができる。例えば、データが未構造化又は準構造化又は部分的構造化データ記録から呼び出される場合、ルーチンは、サービス要求に対する分析及び応答のために使用される記録データを構造化するために呼び出すことができる。分析ルーチンはまた、ＩＳＫＢ作成システム１６によって呼び出される様々な記録の中及び間のデータの相関、特にシステム・データと解決策データと点検保守データとインジケータ・データとの間の相関を可能にすることができる。例えば、ＩＳＫＢは、好ましくは、異なる種類のシステムと、一連の又は数世代のシステムと、システムについての既知の問題及び問題インジケータと、問題又はサービス可能な状態に対する既知の応答と、システムについての既知の又は提案された点検保守との間の相関を含む。

ここで、後でより詳しく説明するように、ＩＳＫＢ作成システム１６はまた、個々の既知の及び検出可能なサービス可能な事象及び状態に応答するための優先順位付けを設定することができることに留意されたい。例えば、特定のインジケータにより、多少とも深刻な状態がシステム内で生じたかもしれないこと又は生じつつあるかもしれないとの結論を導くことができる。このようなインジケータと、このような問題によって課せられる課題の既知の履歴とに基づいて、優先順位付けスコアを、様々なインジケータ、サービス可能な状態及び事象、提案された応答などについて設定することができる。このような優先順位付けを設定する手順は、手動であってもよいが、現在考えられる実施形態では、ＩＳＫＢの設定中にＩＳＫＢ作成システム１６によってアクセスされる分析ルーチンにより自動化又は半自動化される。

ＩＳＫＢ作成システム１６によって呼び出されたデータと用いられるルーチンとに基づいて、ＩＳＫＢ作成システム１６は、参照数字２８によって表したＩＳＫＢを作成する。当業者に理解されるように、ＩＳＫＢ自体は、典型的には、永久的な記憶場所又は２つ以上の場所に記憶された１つ以上のデータベース内に関連したデータを含む。現在考えられる実施形態では、ＩＳＫＢは単一の記憶装置上に位置するが、複数の連結された記憶装置を用いることができることは勿論である。更に、ＩＳＫＢにはインターフェースが関連していて、これらのインターフェースは、有効性確認、検証、変更及び報告のためにＩＳＫＢの記憶されたデータ、優先順位付け及びその他の特徴にアクセスできるようにする。同様に、インターフェースは、サービス可能な事象又は状態に関する情報を自動及び／又は手動手段によってＩＳＫＢへ送るために設けることができる。サービス要求の自動伝送及び取扱いについては以下により詳しく説明する。

図１に更に示されているように、サービス応答システム３０が、ＩＳＫＢに基づくサービス・システム１４の一部を形成する。サービス応答システム３０は、典型的には、ＩＳＫＢ内の情報を利用し且つサービス可能なシステムからのサービス要求を取り扱うことのできる１つ又は複数のサービス・コンピュータを含む。例えば、地理的に異なるシステムにサービスするために複数のサービス・センタが設けられている場合、サービス応答システム３０は、ＩＳＫＢ２８に連結された又は連結可能であって、必要に応じて、互いに連結された一連のコンピュータを含むことができる。以下により詳しく説明するように、サービス応答システム３０は、サービス要求を受け取り、システム情報及びＩＳＫＢデータを利用し、且つサービス要求に応答し又はサービス要求に対する応答を提案するように構成されている。

一般に、サービス要求は任意の適当なソースから発信することができる。しかしながら、現在考えられる実施形態では、要求はユーザによって又は参照数字３２で示すようにユーザ・システムによって、或いは参照数字３４で示すように提供者によって生成することができる。ユーザ・サービス要求３２は、現在考えられる実施形態におけるように、機能不良、故障又は異常動作のような起こり得るサービス可能な状態又は事象のインジケータの検出時にサービス可能なシステムによって、自動的に生成することができる。提供者サービス要求３４は同様に自動的に又は手動で生成することができる。例えば、提供者サービス要求３４は、被サービス・システムにおける新しい又は以前に知られていない状態又は潜在的な問題の識別時に、或いは現場技師又はサービス技師によって、生成することができる。更に、提供者がシステム状態又は性能に関する情報にアクセスできるか又は該情報を供給される場合、提供者サービス要求３４は、提供者がサービス可能な事象又は状態のインジケータを検出したことに基づくことができる。

このようなサービス要求とＩＳＫＢ内の情報とに基づいて、サービス応答システム３０は、典型的には、参照数字３６で示されるような分析ルーチンにアクセスする。これらの分析ルーチンは、サービス要求と以下に説明するようなシステム・スナップショットような任意の付随するデータとを処理し、構造化し、分析すること等が行えるようにする。分析ルーチンはまた、サービス要求及び任意の付随するデータをＩＳＫＢ内の情報と比較して、サービス要求に対する可能な応答、及びそれらの応答についての優先順位付けを設定できるようにする。以下に述べる優先順位付け手順は、このような分析ルーチンを介して実行されると見なすことができる。それらの結果とＩＳＫＢデータと分析ルーチンとに基づいて、参照数字３８で示されるように１つ以上のサービス提案がサービス応答システムによって行われる。これらは、サービス・ワークステーションで表示されるメッセージ、リスト及びより詳細な情報、並びにサービス提供者で作成される報告書、被サービス・システムに送られる通知などの形態を取ることができる。このようなサービス提案はまた、部品、技術者、現場サービス技師のスケジュール作成及び発送・派遣、部品の発注、部品の輸送、又は様々な通常のサービス応答の内の任意の応答を含むことができる。必要に応じて、サービス提案はまた、被サービス・システムへサービス・パケット又はソフトウエアを送ること等によって、被サービス・システムで又はそこから遠隔で遂行することのできる実際のサービスを含むことができる。このようなパケットは、例えば、サービス・システムに組み込まれて動作可能であるソフトウエア、ファームウエア、及びハードウエアさえをも再構成し、リセットし、又はその他の操作を行うために使用することができる。

提案に続いて、典型的には、図１に参照数字１１６で示されるように、且つ以下に説明するように、ある種のサービスを遂行する。遂行されるサービスに基づいて、図１に参照数字１２４で示されるように、且つまた以下に説明するように、（システムの性質、提供されるサービスの状態及び種類に依存して）適切な態様で結果を測定すること等によって、サービス及び提案を評価することができる。ここで、図１に要約して表した機能の内の幾つかの結果として、図１でＩＳＫＢへ戻る矢印で示されるように、ＩＳＫＢを更新、さもなければ訂正又は補正することができることに留意されたい。この更新機能は、ＩＳＫＢに含まれているサービス情報の連続的な補強、訂正及び改善を行う。

図２は、ＩＳＫＢの作成のための模範的なプロセスを表す。全体的に参照数字４０で示した模範的な論理は、上述した種類のデータを受け取って処理するための一連の段階に分割される。図１に関して述べたように、ＩＳＫＢ作成システムは、典型的には、システム・データ、問題解決策データ、点検保守データ及びインジケータ・データを利用する。図２に示されているように、インジケータ・データ及び解決策データは更に様々な特定の種類の情報に分割することができ、これらの情報は既知のデータベースから、専門家の入力によって、点検保守記録の分析によって、等々により取得することができる。より詳しく述べると、図２に示されているように、直接的インジケータ・データ４２を、間接的インジケータ・データ４４の他に設けることができる。直接的インジケータ・データは、例えば、潜在的なサービス可能な状態、故障、機能不良、又はサービスを必要とするかもしれない進行中の状態を直接的に表す電圧、電流、表示灯又は警報作動などのような情報を含むことができる。間接的インジケータ・データ４４は、特定の種類の故障に直接的に相関していないが、典型的には、他の情報と組み合わせて、異常状態の表示、並びにそれらの場所及び原因を導き出すことのできるパラメータ情報を含むことができる。当業者に理解されるように、多数の異なる種類のインジケータは、被サービス・システムの性質及び動作に依存して識別することができる。一般に、インジケータは、サービス応答システムの資源に不必要に重い負担を掛ける虞のある過剰な冗長性を避けながら、サービス可能な状態及び事象の原因を識別し且つ突止めることを可能にする。

インジケータ・データに加えて、利用可能である場合は、推定原因データ４６を呼び出すことができる。このような推定原因データ４６は、実際の用途では、直接的インジケータ・データ及び間接的インジケータ・データに本質的に連結されて、このようなデータと組み合わせて、ソフトウエア及びハードウエアの両方における潜在的な機能不良の表示を提供することができる。必要に応じて、推定原因データは、機能不良の場所及び根本的原因に関して極めて特有なものとすることができ、或いは特別なプログラム、プログラム内のルーチン、現場交換可能なユニット、サブアセンブリなどに制限することができる。当業者に理解されるように、機能不良の究極の根本的原因の突止めの程度により、更なる追加のインジケータが必要とされることがある。システムの経済的なサービスは、サービスを行うために希望される根本的原因の突止めの程度を暗示していることがある。すなわち、例えば、たとえ究極の根本的原因がセンサやデータ収集及び分析に一層多くの投資をすることによって理論的に決定することが可能であるとしても、実際のサービス提案は、現場交換可能なユニットとして幾つかの構成要素を交換すること、或いは一ブロックのソフトウエアを再ロードし又は再構成することを含むことができる。

利用できる場合は、応答提案データ４８も考慮する。例えば、典型的なＩＳＫＢでは、ＩＳＫＢを満たすために既知の問題及び「フィックス(fix) 」が利用可能であり、時間の経過につれて追加の提案が利用可能になる。これらは特定の直接的又は間接的インジケータに、また可能な場合には機能不良の推定根本的原因に連結することができる。

前に述べたように、参照数字５０で包括的に表した様々な分析ルーチンは、呼び出したデータの処理のために利用することができる。分析ルーチンは、図２に要約して表した処理、並びに必要に応じてその他の処理を行えるようにする。

図２に要約して表したように、処理は、参照数字５２で示されるように、呼び出したデータの分析から始める。このような分析は、典型的には、呼び出したデータと個々のシステムとの又はシステムの種類との間の関連性の識別を含む。殆どの複合システムでは、多数の異なるパラメータを監視することができ、またそれらの値又は範囲を記憶することができる。分析はまた、呼び出した又は利用可能なデータの関連性を決定すること、例えば、利用可能である多数の異なる監視されたパラメータ値及び範囲の内のどれが、起こりうる機能不良のインジケータとして特に関心のあるものであり、またどれが、サービス要求に対処するために関連性が少なく且つ保持されないものであるかを決定することを含むことができる。希望により、呼び出したデータは、段階５４に示されているように、その後の呼び出し、比較、及びＩＳＫＢ内に記憶されている他のデータとの関連を容易にするために構造化することができる。段階５６で、データをマッピング及び分類して、例えば、データを個々のシステムと及びシステムの種類と、個々のインジケータと、インジケータ群と、可能性のある根本的原因及び問題と、更に応答及びサービス提案と関連させる。同様に、段階５８で示されているように、インジケータと原因と提案とを相関させる。これらの相関関係はリレーショナル・データベースを介して作られて、ＩＳＫＢを作り上げるデータ構造を形成する。

図２に段階６０で示されているように、且つ後でより詳しく説明するように、応答及び提案に優先順位を付けて、それらの優先順位付けをＩＳＫＢ内に優先順位付けスコアとして記憶させることができる。このような優先順位付けは、機能不良の根本的原因の厳しさ、機能不良又は修理の最終的なコスト、機能不良から生じる休止時間などに基づいて行うことができる。従って、幾つかの可能性のある根本的原因及び提案が存在する場合、このような優先順位付けスコアは提案について階層を設定し、この階層に従って、システムが自動的に、或いは、優先順位付けに基づいて、特定の順序でサービス要員の介在により動作する。

図２に段階６２で示されているように、有効性確認手順は、一般に、インジケータ、根本的原因の表示及び提案がサービス・システムにとって正しいことを検証するためである。有効性確認手順は、例えば、システムの専門家によって遂行することができる。有効性確認はまた、サービス応答及び提案の優先順位付けについての有効性確認も含むことができる。図２でブロック６２から出る矢印によって示されるように、この有効性確認の結果、ＩＳＫＢを作成するために使用される前述の段階の任意の１つが変更されることがある。このような変更は、例えば、パラメータ・インジケータの追加又は削除、提案及び応答の削除又は変更、及び優先順位付けスコアの変更を含むことができる。最終的に、段階６４で、ＩＳＫＢはサービスの関心事に対処する際に使用するために記憶される。

図３は、本発明手法の様々な面に従ってサービス要求を処理するための模範的な論理を例示する。全体を参照数字６６で表した処理論理は、段階６８でサービス要求を受け取ることから始まる。サービス要求は、典型的には、電子的メッセージなどによるような電子的形態で送られる。サービス要求は、システム識別情報のような情報と、システムで遭遇することのある問題についての関連情報とを含むことができる。更に、現在考えられる実施形態では、サービス要求は、多数の追加の構成要素及び支持情報、例えば、要求の名称又は指定、要求の生成源、要求頻度の表示（例えば、同様な要求を行った回数）、顧客識別情報、ユーザ識別情報、現場サービス技術者の連絡先などのような、多数の追加の構成要素及び支持情報を含むことができる。この基本的な情報に加えて、要求は、サービス可能な状態又は事象及び機能不良の根本的原因を識別する際に役立ち且つサービス応答を提案する際に役立つことのできる実際のログ(log) データ及びファイル・データを含むことができる。このような情報は、例えば、ログ・ファイル、画像ファイル、オーディオ・ファイル、ビデオ・ファイル、テキスト・ファイル、及び、その他のファイル、すなわち、、サービス要求に対処するのに役に立つインジケータとして作用することのできる監視パラメータを表すファイルを含むことができる。

本発明手法の特定の面によれば、サービス要求はまた構成データを含むことができる。現在考えられている実施形態では、このようなデータは、影響を受ける装置を識別し、且つシステム又は特定の影響を受ける装置の任意の利用可能なサービス履歴を識別することができる。構成データはソフトウエア構成データとハードウエア構成データも含むことができる。ハードウエア構成データは、問題の根本的原因を識別する際に、且つハードウエア又は構成要素が組み込まれていないか又は動作可能にされていない場合に根本的原因を除外する際に特に役立つ。ハードウエア及びソフトウエア構成情報は、以下に述べるように「スナップショット」で取得して、システムのログ・ファイルに又はシステムから遠隔に記憶させることができる。この情報及びサービス要求を含むことにより、サービス要求に対する適切な応答を決定すること、並びに幾つかの応答が可能である場合にそれらの応答の優先順位付けが容易になる。前に述べたように、情報はまた、異なるシステムについて行うべきサービスの間の優先順位をサービス提供者において設定するのに役立つことができる。

図３のプロセスは、参照数字７０で示されるようにサービス要求の分析に続く。このような分析は構文解析又は構造化を含む。段階７２で、サービス要求に優先順序を付けることができる。以下により詳しく説明するように、このような優先順位付けは、ＩＳＫＢに記憶されている優先順位付けスコアに基づいて、或いはサービス契約に基づく因子及びその他の因子を含むＩＳＫＢ以外で考慮される因子に基づいて行うことができる。

段階７４で、１つ以上のサービス応答が提案される。幾つかの異なる種類のサービス応答が現在考えられる。これらは、参照数字１１６で示されるように、一般にグループ分けされる。例えば、参照数字７６で示されるように、サービス応答は、システム要員に対する、並びにサービス提供者、現場技師などに対する、出来事の簡単な報告を含むことができる。特に、サービス要求を自動的に生成することのできる特定のシステムの場合、システム監督者、管理者、所有者、又は他の責任者が出来事に又はサービスが必要なことに気付かないことさえ起こり得る。段階７６で作成された報告は、このような情報を提供する。更に、報告は、現場技師を派遣するため、またサービス要求の発生を技術者に通知するため等の有用な情報を提供する。

更に、１つの応答は、参照数字７８で示されるように追加のデータを要求することを含むことがある。このような追加のデータは、満足のいく提案が行えるようにするために又は可能性のある複数の根本的原因又は提案を差別化するために利用できる又は提示されたデータが不十分であることを識別するサービス応答システムから生じさせることができる。このような追加のデータは、自動的に、又はユーザの介在により、或いはサービス技術者又は他のサービス要員によって要求することができる。

最後に、参照数字８０で示されるように、特定の動作を遂行することができる。これらは、サービス技術者の比較的通常の派遣を含むことができるが、高度に自動化された応答も含むことができる。例えば、必要に応じて、遠隔の接続部及びリンクを介して、被サービス・システムについての特定の設定を、該システムへのサービス・パケットの送付などによって自動的に変更することができる。同様に、特定の構成要素を再構成するため又はリセット（例えば、再較正）するために、構成データをシステムへ送ることができる。適切な応答はまた、特定の部品又は構成要素を発注すること、或いはシステムにおける可能性のある交換のために特定の部品又は構成要素を出荷することを含むことができる。

このようなサービス応答の内のいずれか１つに基づいて、ＩＳＫＢは、参照数字１２８で示されるように、また以下により詳しく説明するように、改善のために更新することができる。

サービス要求、提案及びサービス活動は本発明手法の様々な面に従って優先順位を付けることができ、そのために、根本的原因、インジケータ、提案された応答などについて固有の優先順位付けスコアを記憶する。現在考えられる実施形態では、これらの優先順位付けスコアはＩＳＫＢが構築されるにつれて生成される。ＩＳＫＢ作成システムによって具現化される分析ルーチンの一部として、図４に示されているような優先順位付けエンジン８２を呼び出すことができる。優先順位付けエンジン８２は、優先順位付け論理に基づいて、ＩＳＫＢを設定するコンピュータ（１つ又は複数）によって具現化されるソフトウエアによって本質的に構成することができる。このような論理は、典型的には、システムン性質、システムの役割などに基づいて変化する。優先順位付け論理は改変することができ、特にシステムの種類に合わせて設計することができる。特定のＩＳＫＢの設計者は典型的には論理を設定し、その符号化は、熟練した有能なプログラマーの権限内にあると考えられ、過度の実験を必要としない。

優先順位付けエンジン及び論理は、インジケータと根本的原因とサービス要求に対する可能性のある応答との間で優先順位を設定するために任意の範囲の因子を要求することができる。図４に示されている実施形態では、これらの因子の幾分かは、参照数字８４で示されるように、要求不依存性であると見なすことができ、また、他の因子は、参照数字８６で示されるように、要求依存性であると見なすことができる。要求不依存性因子は、起こり得る故障に関連した危険因子（例えば、休止時間については、機械及び環境等に対する危険因子）としての故障又は休止時間の確率、問題又は故障についての可能性のある厳しさ、及び問題、故障又は休止時間に関連したコストのような因子、並びに任意のその他の因子を含むことができる。これらの因子は、必ずしも要求自体に関係していず、むしろシステムに依存し且つシステムにおけるサービス可能な事象の発生を原因とする結果に依存するので、要求不依存性としてグループ化することができる。要求依存性因子は、要求を行う顧客、その要求又は同様な要求を行った頻度、顧客が経験している又は経験する虞のある休止時間、サービス要求に応答させた際に顧客が経験した又は経験する虞のある待ち時間、及び影響を受ける装置又は他の因子のような因子を含むことができる。このような因子は要求自体又は要求のソース又は性質により多く関係している。このような因子に基づいて、優先順位付けスコアは様々な既知のインジケータ、根本的原因及び応答に割り当てることができる。

図５は、受け取ったサービス要求に優先順位を付けるための模範的な論理を幾分かより詳細に例示する。全体的に参照数字８８で示した論理は、要求３２，３３自身及びＩＳＫＢ２８をインターフェース９０によって呼び出すことから始まる。前に述べたように、インターフェースは、典型的には、電子的伝送などによって自動的に要求を受け取り、且つ局所的に又は遠隔接続を介してＩＳＫＢにアクセスするように装備されている。要求及びＩＳＫＢからの情報は、段階９２に示されるように構造化することができる。前に述べたように、ＩＳＫＢは、典型的には、それが含んでいるデータを参照しやすくするように予め構造化される。その上、要求もまた構造化することができるが、要求は構造化していない又は部分的に構造化したデータを含むことができ、それらのデータは、サービス要求の評価及びそれとＩＳＫＢ内の情報との比較を可能にするために、段階９２で構造化することができる。

段階９４で、サービス要求の詳細が抽出される。これらの詳細は、サービス要求に含むことのできる前に述べたコンテンツの全てを含むことができ、その中には、システム識別情報、サービス可能な事象又は状態の識別情報、場所情報、サービス履歴情報、ログ・ファイル、ハードウエア構成などが含まれる。段階９６で、この情報はＩＳＫＢへマッピングされる。このマッピングは個々のフィールド又はデータ構造の単純な比較を伴うことができ、或いはより詳細な論理を含むことができる。この論理は、例えば、特定のインジケータを評価し且つこのようなインジケータを潜在的な根本的原因及びサービス提案と相関させることに基づくものとすることができる。段階９８で、システムは、サービス要求で充分な情報を受け取ったかどうか評価することができる。もし受け取った情報が不充分であるなら、段階１００で示されるように追加の情報を要求することができる。このような追加の情報は、例えば、前に述べたハードウエア構成情報、エラー・ファイル、ログ・ファイル、或いはサービス可能な状態又は事象の性質及び可能性のある根本的原因及び提案された解決策のインジケータとして作用することのできる任意のパラメータ・データを含むことができる。

２つ以上の可能性のある応答が利用可能である場合、これは段階１０２で評価することができる。２つ以上の応答が利用可能でない場合、処理は継続することができ、以下に述べるように単一の利用可能な提案を行うことができる。しかしながら、２つ以上の応答が利用可能である場合、これらは段階１０４で調整することができる。複数の利用可能な応答の調整は、或る特定の応答の除去、或る特定の応答の包含などを含むことができる。このような調整は、ＩＳＫＢ内に含まれている規則に基づいて自動的に遂行することができ、或いはサービス応答システムによって実施することができる。このような調整はまた、サービス技術者、専門家などからの入力に基づいて遂行することができる。

段階１０６で、複数の可能性のある応答の中で優先順位を設定することができる。前に述べたように、この優先順位は単一のサービス可能な状態に対する複数の可能性のある応答の間で存在し、又は単一のシステム内の複数の起こり得るサービス可能な状態の間で存在し、或いは複数のシステムの間で存在することができる。すなわち、サービス提供者が多数の異なるシステム又は顧客にサービスを提供している場合、サービス要求と複数の可能性のある応答との間での優先順位が、特定の要求を緊急性の高さに基づいた順序で対処することを要求することができるように、特定のサービス可能な状態は他のものに先行することができる。従って、段階１０６で設定される優先順位は、ＩＳＫＢ内に記憶されている又は処理中に導き出された優先順位付けスコアに基づいて比較的客観的に設定することができる。段階１０８で、これら優先順位を調節することができる。優先順位の調節は、手動で又は自動化した規則に基づいて行うことができる。例えば、優先順位は、顧客識別情報、システム識別情報に基づいて、又はより広義にはサービス契約に基づいて調節することができる。一例として、幾つかのレベルのサービス契約が提示されている場合、サービス提供者は特定の種類の高級なサービス契約に高い優先順位を与えて、他のサービス契約には通常のレベルの優先順位を割り当てることができる。このような情報へのアクセスは、図５に段階１１０で示されているように、調節プロセスのために行うことができる。

優先順位付けに基づいて、又は単一の提案を行うべきである場合に、段階１１２で示されているように、提案が出力される。前に述べたように、提案はサービス要求に対して任意の範囲の可能性のある応答を含むことができる。しかしながら、一般に、システム又はシステム所有者は、段階１１４で示されているように通知を受け取る。この通知はまた、サービス提供者、顧客及びサービス提供者における責任者、現場技師及び技術者等にも送られる。最後に、段階１１６で、一種のサービス活動が一般に適切に行われる。前にも述べたように、このサービスはシステムへの実際の現場訪問又はシステムとの連絡、或いはサービス不可能な状態に対処するための自動的な「フィックス」を含むことができる。他の応答及びサービスは、定期的に又は特別にスケジュール決定されたサービスなどを含む任意の通常の種類の応答に従うことができる。また、通知１１４は、ＩＳＫＢ内のデータの更新及び改善を容易にするために、図５のブロック１１４に隣接したブロック９２で示されるように構造化することができる。

図６は、実際のサービス及びフィードバックに基づいてＩＳＫＢを更新するための模範的な論理を表す。図６の論理は、参照数字１１８で示されているように、相関可能であるサービス可能な事象又は状態がＩＳＫＢ内に存在するかどうか決定することから始めることができる。前に述べたように、ＩＳＫＢは被サービス・システムについての既存の情報及び知識に基づくものであってよい。しかしながら、新しいサービス可能な状態を認識し、これらの新しく認識された状態に基づいてサービス要求に対処するためのインジケータ及び応答を提案し且つ作ることが可能であり、その可能性は高くさえもある。状態又は事象がＩＳＫＢに含まれていない場合、参照数字１２０で示されるように、ＩＳＫＢが優先順位付けスコアを含んでいる場合、これらに優先順位を割り当てることができ、その情報を、同様な性質の将来の要求に対処するために追加することができる。前と同様に、このようなデータがＩＳＫＢに含め易くするために構造化を必要としている場合、これを段階９２で遂行し、次いで段階１２８でＩＳＫＢを更新する。

状態又は事象が既にＩＳＫＢに含まれている場合、前に示し且つ図６に段階１０６，１０８で表すように、サービス要求又は応答に優先順位を割り当て、且つ優先順位を調節することができる。また前に述べたように、これらの提案に基づいて、図６に段階１１６で示されているように、サービスを最終的に提供する。

この提供されたサービスに基づいて、段階１２２に示されているように、フィードバックを、システム自身、顧客又は責任のあるグループ、或いは現場技師又は技術者などから得ることができる。実用性を最大にするために、フィードバックを評価して、段階１２４に示されているように、サービスの結果がＩＳＫＢ内の情報に基づいて期待していた通りのものであったかを決定する。フィードバックが正である（すなわち、サービスが期待した結果を生じた）場合、参照数字１２６で示されるように、これについての記録をＩＳＫＢ内に作ることができる。このような正のフィードバックは、ＩＳＫＢ内の情報を強化し、且つこのような応答について優先順位付けスコアを増大させることさえもするように作用することができる。他方、期待した結果が得られなかった場合には、段階１２８に示されているように、ＩＳＫＢを更新することができる。このような更新の結果として、逆に、実際に具現化された提案についての優先順位付けスコアが低くされる。一般に、段階１３０で、更新が行われたこと又は更新を行うべきであることをＩＳＫＢのマネージャに示す一種の通知すなわちフラグを設定することができる。

本発明手法の特に有用な一面は、システム・スナップショットの生成に関する。前に述べたように、システム・スナップショットは、サービス可能な事象又は状態の発生時における被サービス・システムの状態に関するある範囲の情報を含むことができる。サービス可能な事象又は状態の１つ又は複数のインジケータが検出されたとき、システム・スナップショットを生成することができる。図７に例示されているように、参照数字１３２で大まかに表したシステム・スナップショットは、システムにそのとき存在するある範囲の情報及びデータを含むことができる。最も有用なことは、システム・スナップショットがサービス可能な状態又は事象のインジケータの検出と同時に又は検出の直ぐ後に生成されることである。

ここで、スナップショットはインジケータの検出の前に、検出中に、及び検出の後に実際に収集されたデータを含むことができることに留意されたい。しかしながら、一般に、スナップショットは、インジケータの検出の時間に基づいて決定された時間又は時間帯又は窓において収集されたデータを含む。例えば、インジケータが状態の発生又は開始のより早い時間を示唆している場合、スナップショットはそのより早い時間におけるシステム構成に対応するデータを含むことができる。状態の進展又は傾向に関心がある場合、より早い及びより後のデータを収集することができる。またここで、スナップショットの収集、及び収集されるデータの期間が、使用回数、サイクルなどの時間以外のパラメータに基づくようにすることができることに留意されたい。本目的のために、これらはまたインジケータの検出又はインジケータの発生の「時間」に基づくものと見なすべきである。

システム・スナップショットは、例えば、参照数字１３４、１３６、１３８、１４０及び１４１でそれぞれ示されるように、インジケータの発生又は検出、特定の装置データ、任意のログ・データ及びエラー・データ、場所データ及び顧客データの項目を含むことができる。時間データ１３４は、典型的には、日付、時及び分の表示、或いはインジケータが検出された秒の表示さえも含む。装置データ１３６は、ソフトウエア構成情報、履歴パラメータ、システム上に存在する画像及び他のファイル、並びにシステム上にそのとき存在する一連のパラメータ及びそれらの値を含むことができる。

本実施形態で特に関心のあるものはハードウエア及びソフトウエア構成情報である。このようなハードウエア構成情報は、例えば、システム内に組み込まれて動作する構成要素、システム内に組み込まれて動作する周辺装置、部品、設定、発生時に確立されている接続などを含むことができる。エラー・データ及びログ情報１３８は、例えば、エラー名称、エラー頻度、期待又は許容範囲の外側の監視されるパラメータなどを含むことができる。場所情報１４０は、そこからインジケータが発生したシステム、サブシステム、或いは構成要素又は現場交換可能なユニット、並びにシステムの識別情報、システムの場所、顧客などのような情報を含むことができる。顧客データ１４１は、顧客及びシステムの番号又は表示のような情報、販売又は供給の顧客又は状態に関する情報などを含むことができる。

図８は、システム・スナップショットを生成する際の模範的な諸段階を表す。大まかに参照数字１４２で表したスナップショット生成論理は、ブロック１４４に示されるように問題の検出から始まる。実際には、システム・スナップショットは、関心のある任意のインジケータの検出時に、特に問題の根本的原因を識別し、起こり得るサービス可能な事象又は状態を識別し、或いは該事象に対する複数の可能性のある応答を識別するために使用することのできるインジケータを検出した時に取得することができる。更に、スナップショットは、サービス可能な事象及び状態又はそれらに対する応答に優先順位を付けるのを助けるために使用することのできる任意のインジケータを検出した時に取得することができる。更に、参照数字１４６で示されるように、このようなスナップショットはオペレータからのような要求時に取得することができる。ここで、オペレータは被サービス・システムの在る場所に居ても、該システムから離れていても良いことに留意されたい。従って、システム・スナップショットは、システムに異常状態が疑われたときのように、人手の介入時に開始することができる。これは、現地での要求に応答するものでも、遠隔のサービス提供者又は任意の他のオペレータからの要求に応答するものであってよい。

段階１４８でシステム・スナップショットが取得される。図７に関して前に述べたように、システム・スナップショットは特定のファイル及びデータにアクセスすることによって取得され、そしてスナップショットは段階１５０で示すようにログ・ファイルに記憶される。システム・スナップショットに記憶すべき特定の項目は、被サービス・システム内で規定して記憶することができる。当業者に理解されるように、このような情報及びシステム・スナップショットを開始するための命令は、ＩＳＫＢにおいて規定して、その生成のために必要とされる命令を規定するためのシステムへダウンロードすることができる。これらの命令はまた、収集されたデータ又はファイルについて遂行すべき特定の処理を含むことができる。

図８内の段階１５２で、潜在的にサービス可能な事象又は状態のインジケータが検出されたことを示すエラー・メッセージを、必要に応じて、表示することができる。エラー・メッセージのこのような表示は、人間のオペレータがある種の行動を取ることができるシステムでは特に望ましい。医学的診断用においては、複合システムは臨床医、技術者、放射線技師、及び他の専門家によって制御することができる。段階１５２でのエラー・メッセージの表示は、システム・スナップショットが取得されたこと、及びサービス要求を開始又は伝送するようなある行動が保証され得ることをオペレータに知らせる。

段階１５４で、スナップショット又はサービス要求、或いはその両方を、潜在的にサービス可能な状態又は事象に対処するためにサービス提供者へ送るように、オペレータに催促することができる。オペレータの選択に基づいて、参照数字１５６で示されるように、報告を送ることができる。本実施形態では、報告を送るか否かに拘わらず、システム・スナップショットをログ・ファイル１５８に記憶させる。ある事象はシステムの継続した動作を又は正常な動作さえも直ちに妨害することがないので、段階１５８で示されるようにシステム・スナップショットをログ・ファイルに自動的に記憶させることは、システムの健全さのその後の評価、システムのサービスなどを非常に容易にすることができる。例えば、ファイルに、サービス要員によって、或いはシステムのルーチン検査又はサービス中に遠隔からでもアクセスすることができる。

本書では本発明の特定の特徴のみを例示し説明したが、当業者には多くの修正及び変更を行えよう。従って、特許請求の範囲は、本発明の真の精神の範囲内にあるこのような全ての修正及び変更を包含するものであることを理解されたい。

本発明手法の様々な面に従った、ＩＳＫＢ作成システム及びＩＳＫＢに基づくサービス・システムを含むサービス・システムの概要図である。 ＩＳＫＢの作成の際の模範的な論理を例示する流れ図である。 サービス要求を処理する際の模範的な論理を例示する流れ図である。 サービス要求とこのような要求に対して行うことのできる提案又は応答との間で優先順位付けを設定する際に考慮することのできる特定の種類の因子を表す概略図である。 サービス要求及び提案の処理及び優先順位付けを例示する流れ図である。 提供されたサービスに基づいてＩＳＫＢを更新する際に有用である特定の論理を表す概略図である。 本発明手法の様々な面に従った、システム・スナップショットに含むことのできる因子及び構成要素を表す概要図である。 サービス要求又はこのような要求に応答したサービスについての提案で考慮するためのシステム・スナップショットを取得するために使用される模範的な処理を例示する流れ図である。

符号の説明

１０ システム
１２ ＩＳＫＢシステム
１４ ＩＳＫＢに基づくサービス・システム
４０ ＩＳＫＢの作成の際の模範的な論理
６６ サービス要求を処理する際の模範的な論理
８８ 優先順位を付けるための論理
１４２ スナップショット作成論理

Claims (8)

1. システムに動作上サービスするための方法であって、
   被サービス・医療システムにおけるサービス可能な状態の動作性能パラメータを検出する段階と、
   前記被サービス・医療システムにおける前記サービス可能な状態についてのサービス要求を、サービス可能な状態の前記動作性能パラメータの検出に応じてコンピュータが自動的に生成する段階と、
   複数の被サービス・医療システムのシステムの種類を規定するシステム・データと、各システムの種類に対応して、各サービス・医療システムについての既知のサービス可能な状態、及び前記動作性能パラメータに基づいた潜在的な機能不良のインジケータを規定するインジケータ・データと、前記インジケータ・データと連結することにより機能不良の原因を特定することができる推定原因データとを含んでいる知識ベースにコンピュータがアクセスする段階と、
   前記インジケータ・データ及び前記推定原因データに基づいて前記サービス要求に対する応答をコンピュータが自動的に生成する段階と、
   を含み、
   前記応答を自動的に生成する前記段階が、
   前記知識ベースに含まれる複数の規則に基づいて、前記被サービス・医療システムについての前記サービス可能な状態にサービスするための可能性のある複数の応答をコンピュータが調整して、前記複数の応答の内の一部の応答をコンピュータが除去する段階と、
   前記知識ベースに記憶されている前記サービス要求に対する優先順位付けスコアに基づいて、前記被サービス・医療システムについての前記サービス可能な状態にサービスするための調整された複数の応答をコンピュータが優先順位付けする段階と、
   を含み、
   前記優先順位付けする前記段階が、
   顧客識別情報又はシステム識別情報に基づいて特定されるサービス契約のレベルに応じて、前記優先順位付けされた複数の応答の優先順位をコンピュータが調節する段階を含む、
   方法。
2. 更に、提供されたサービスに対するフィードバックに基づいてコンピュータが前記知識ベースを更新する段階を含んでいる請求項１記載の方法。
3. 前記優先順位付けスコアは、前記被サービス・医療システムについての異なる潜在的なサービス可能な状態に対する複数の応答の間での優先順位付けを表している、請求項１記載の方法。
4. 前記優先順位付けスコアは、異なるサービス可能なシステムに対する応答の間での優先順位付けを表している、請求項１記載の方法。
5. 前記優先順位付けスコアは、特定のサービス可能な状態の確率、又は潜在的なサービス可能な状態のコストに基づいて生成される、請求項１記載の方法。
6. 前記応答は、前記被サービス・医療システムに対して追加の動作データの提供を自動的に要求することを含んでいる、請求項１記載の方法。
7. 前記応答は、前記被サービス・医療システムにソフトウエア・サービス・パケットを自動的に送ることを含んでおり、
   前記ソフトウエア・サービス・パケットは、前記被サービス・医療システムの再構成のためのコードを含んでいる、請求項１記載の方法。
8. システムに動作上サービスするためのコンピュータ・プログラムであって、
   少なくとも１つの機械読取り可能な媒体に記憶されているコンピュータ・コードであって、コンピュータに請求項１乃至７のいずれかに記載の方法を実行させるためのコードを含んでいる、コンピュータ・コードを有するコンピュータ・プログラム。
   

Images