(57)【特許請求の範囲】
【請求項１】
ａ）システムデータを受信し、健全管理分析用に前記システムデータをフォーマットするデータサービスと、
ｂ）前記フォーマットされたシステムデータを受け取り、前記フォーマットされたシステムデータを検査して車両システムの故障の徴候を合成する徴候検出サービスと、
ｃ）前記車両システムの故障の徴候を検査して前記徴候から可能性のある、少なくとも１つの診断を決定する診断サービスとを備え、
前記徴候検出サービスは検出オブジェクト収集を有し、前記検出オブジェクト収集の各々は前記フォーマットされたシステムデータから徴候の検出を行う方法を有し、前記検出オブジェクト収集は、異なる検出機構を有する少なくとも２つの検出オブジェクトを含み、
前記診断サービスは推論オブジェクト収集を備え、前記推論オブジェクト収集の各々は前記徴候から診断の推論を行う方法を有し、前記推論オブジェクト収集は、異なる推論機構を有する少なくとも２つの推論オブジェクトを含む、
車両健全管理装置。
【請求項２】
前記データサービスは、前記システムデータを受け取るデータソース・インタフェースを備え、前記データソース・インタフェースは複数のソースの１つから前記システムデータを受け取る、請求項１に記載の装置。
【請求項３】
前記データサービスは、データソース・オブジェクトを有し、前記データソース・オブジェクトは前記システムデータを含むデータストリームに加入する加入方法と、前記データサービスへ前記データストリームのデータ転送を開始するデータ転送開始方法を有し、前記データサービスは、データサービス・マネージャを有し、前記データサービス・マネージャは前記データサービスの動作を制御する、請求項１に記載の装置。
【請求項４】
前記徴候検出サービスは、データ供給インタフェースを備え、前記データ供給インタフェースは前記データサービスから前記フォーマットされたシステムデータを受け取る方法を有し、前記検出オブジェクト収集は複数の検出機構をサポートし、前記検出機構は、診断テスト、トレンド解析アルゴリズム、及びニューラルネットワークを有する、請求項１に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は診断システムに関し、特に車両健全性管理システムに関する。
【背景技術】
【０００２】
現代の車両はますます複雑化して、高機能の指示制御システムを必要としている。この種の車両は、機器に発生した動作の異常や故障に直面した際、故障を識別し、その影響を緩和する能力がさらに求められる。車両健全性管理（ＶＨＭ）システムは、故障や異常に対する対応を促進することで指示制御システムを補完し、指示制御システムが正常（健全な）状態で有効に動作するようにする。ＶＨＭシステムは車両システムの健全性を管理し、故障状態を識別し、車両が正常状態に復帰するように故障の影響の軽減に努める。以下の説明では、主として、健全性管理の第１の側面である、診断、故障の検出、故障原因の分離を中心に説明する。
【０００３】
車両健全性管理システムがかかえる１つの問題はシステム機能性の更新が困難な点である。既存のＶＨＭシステムはシステムの変更や更新の能力が抑制されるような形態で一体不可分に統合されている。例えば、ＶＨＭシステムは、代表的な構成の場合、試験や解析のためにデータソースを新たに追加することが困難である。新たなデータソースを追加して機能性を更新するには、典型的にＶＨＭシステム全体の動作を再度、評価し直す必要がある。このため、機能性のアップグレードには問題が多く、ＶＨＭの柔軟性は制限される。また、従来のＶＨＭ設計は、グランドフライトや実験／車両プラットフォーム間の移行など、プラットフォーム間の「可搬性」に欠けるという問題がある。多くの場合、この種の移行を実現するにはシステムを設計し直す必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
したがって、求められているものは改良されたシステムであり、車両システムの健全性管理おいて柔軟性と性能を改善することである。
【課題を解決するための手段】
【０００５】
本発明は柔軟性と性能を改善した車両健全性管理（ＶＨＭ）システム及び方法を提供する。本車両健全性管理システム及び方法では、モジュール設計手法によりＶＨＭシステムを明確なインタフェースによって分離される下位の論理のサブ要素に分割する。このモジュール手法により新たな特徴や機能性をＶＨＭに付加するのが容易になり、システムの柔軟性と性能を向上させることができる。
【０００６】
車両健全性管理システムはデータサービス、徴候検出サービス、及び診断サービスを備える。データサービスは複数のソースからシステムデータを受け取り、フォーマットした後、徴候検出サービスにフォーマットされたデータを引き渡す。徴候検出サービスはフォーマットされたデータを解析してシステム故障の徴候を検索する。データのなかで、システム故障を示す部分は診断サービスに渡される。診断サービスは故障に係るデータ部分を検査して可能性のある診断を下す。その後、診断結果は評価のためにオペレータまたは使用者に渡される。
【０００７】
本発明の前記及びその他の目的、特徴、効果は添付図面に示した発明の実施形態についてなされる以下の詳細な説明から明らかにされる。
【発明を実施するための最良の形態】
【０００８】
本発明は柔軟性と性能を改善したモジュール式車両健全性管理（ＶＨＳ）システム及び方法を提供する。このモジュール式車両健全性管理システム及び方法では、モジュール手法によりＶＨＭシステムを明確なインタフェースで分離される下位の論理サブ要素に分割する。このモジュール設計手法により新たな特徴や機能性をＶＨＭに付加するのが容易になり、システムの柔軟性と性能を向上させることが可能になる。車両健全性管理システムはデータサービス、徴候検出サービス、及び診断サービスを備える。データサービスは複数のソースからシステムデータを受け取り、フォーマットした後、徴候検出サービスに供給する。徴候検出サービスはフォーマットされたデータを解析してシステム故障の徴候を検索する。データのうち、システム故障を示す部分は診断サービスに渡される。診断サービスは故障に係るデータ部分を検査して可能性のある診断を下す。その後、診断結果は評価のためにオペレータまたは顧客に渡される。
【０００９】
車両健全性管理システムの柔軟性と性能の改善を促進するため、データサービス、診断検出サービス、及び診断サービスを明確なインタフェースにより実現する。データサービス、徴候検出サービス、及び診断サービスへのデータ伝送及び通信はそれぞれのインタフェースを介して行われる。このように、車両健全性管理システムをモジュール設計することで、ＶＨＭに新たな特徴や機能性を追加するのが容易になり、システムの柔軟性と性能が向上する。さらには、ＶＨＭシステムが、テストベットやオペレーションシステムなどの広範囲のシステムに容易に適応可能になる。
【００１０】
モジュールＶＨＭは多くの異なる車両の健全性監視に適用可能である。車両としては、航空機、スペースシャトルや宇宙ステーションなどの宇宙船、自動車などが含まれる。
図１にコンピュータシステム１００を例示する。コンピュータシステム１００はコンピュータシステムの一般的特徴を示したもので、本発明はこれを使用して実現可能である。勿論、図示の特徴は単なる例示であり、他の特徴、あるいは異なる特徴を備えた別種のハードウェアにより本発明を実現することができる。また、コンピュータシステムは多くの異なる環境で実施可能であり、例えば、車両に搭載して車内診断をする、あるいは地上から遠隔で診断を行うことができる。例示のコンピュータシステム１００は、プロセッサ１１０、記憶装置インタフェース１３０、端末インタフェース１４０、ネットワークインタフェース１５０、記憶装置１９０、バス１７０、及びメモリ１８０を備える。本発明の実施形態に基づいて、メモリシステム１８０はモジュール車両健全性管理プログラムを備える。
【００１１】
プロセッサ１１０はシステム１００の情報処理と制御の機能を実行する。プロセッサ１１０は任意の種類のプロセッサであってよく、例えばマイクロプロセッサのような単一の集積回路により、あるいは任意の適当な個数の集積回路／回路基板の協同動作によって処理ユニットの機能を実現可能である。また、プロセッサ１１０は別個のコンピュータシステム上に実装した複数のプロセッサであってよく、例えば、モジュール車両健全性管理システムの一部を、プロセッサを備えた車両搭載システムコンピュータ内に配置するとともに、一部を別のプロセッサを備えた地上の制御コンピュータ内に配置したようなシステム構成が可能である。動作の際にプロセッサ１１０はメモリ１８０内にあるプログラムを実行して、コンピュータシステム１００全体のオペレーションを制御する。
【００１２】
メモリ１８０は任意の種類の適当なメモリであってよく、例えば、ＳＤＲＡＭなどの各種ダイナミックＲＡＭ（ＤＲＡＭ）、各種スタティックＲＡＭ（ＳＲＡＭ）、各種不揮発性メモリ（ＰＲＯＭ、ＥＰＲＯＭ、フラッシュ）などが挙げられる。また、メモリ１８０は一種類のメモリで構成してもよいし、多数の異なる種類のメモリで構成してもよい。また、メモリ１８０とプロセッサ１１０は、全体がシステム１００を構成する、複数の異なるコンピュータ間に分散配置されてよい。例えば、メモリ１８０の一部を車両搭載システムコンピュータ上に配置し、他の部分を地上制御コンピュータ上に配置してよい。
【００１３】
バス１７０はシステム１００の各種構成要素間でプログラム、データ、ステータス、その他の情報または信号を伝送する。バス１７０はコンピュータシステムと構成要素を接続する任意の適当な物理的手段または論理的手段であってよく、限定する意味でないが、ハードワイアドによる直接接続、光ファイバ、赤外線、無線などのバス技術が含まれる。
【００１４】
端末インタフェース１４０はユーザとシステム１００との通信を可能にするもので、任意の適当な方法及び装置で実現される。ネットワークインタフェース１５０はコンピュータシステム１００と他のシステムとの通信を可能にするもので、任意の適当な方法及び装置で実現される。記憶装置インタフェース１３０は記憶装置とコンピュータシステム間のインタフェースをとる任意の方式でよい。記憶装置１９０は任意の適当な種類の記憶装置であってよく、例えば、ハードディスクドライブ、フロッピー（登録商標）ディスクドライブ、光ディスクドライブなどの直接アクセス記憶装置が含まれる。また、図１に示すように、記憶装置１９０はデータを記憶する光ディスク１９５を使用するＣＤタイプの装置であってよい。
【００１５】
本発明の実施形態に基づいて、コンピュータシステム１００はモジュール車両健全性管理プログラムを備える。オペレーションの際、車両健全性管理プログラムはメモリ１８０に記憶され、プロセッサ１１０により実行される。プロセッサ１１０による実行中、車両健全性管理プログラムは車両システムの健全性を管理し、故障状態を識別し、車両を正常状態に復帰させるべく、故障の影響の軽減を図る。
【００１６】
なお、本発明は、完全に機能するコンピュータシステムに則して説明されるが、当業者には明らかなように、本発明の機構は各種形態のプログラム製品として頒布可能であり、頒布を実施するための信号担体の種類によらず、等しく適用可能である。信号担体としては、フロッピー（登録商標）ディスク、ハードドライブ、メモリカード、光ディスク（例えばディスク１９５）などの記録可能媒体や、例えば無線通信リンクなどのデジタル、アナログ通信リンクのような伝送媒体がある。
【００１７】
図２にモジュールＶＨＭ２００の詳細を模式的に示す。モジュールＶＨＭ２００はデータサービス、徴候検出サービス、及び診断サービスを備える。データサービスは複数のソースからシステムデータを受け取り、フォーマットした後、徴候検出サービスに引き渡す。徴候検出サービスはフォーマットされたデータを解析してシステム故障の徴候を検索する。データのなかで、システム故障を示す部分は診断サービスに渡される。診断サービスは故障に係るデータ部分を検査して可能性のある診断を下す。その後、診断結果は評価のためにシステムのユーザに渡される。データサービス、徴候検出サービス、診断サービスは相俟ってＶＨＭシステムを構成し、このＶＨＭシステムは車両の健全性を管理し、故障状態を識別し、故障の影響の軽減に努める。
【００１８】
車両健全性管理システムの柔軟性と性能の改善を促進するため、データサービス、診断検出サービス、及び診断サービスは明確なインタフェースにより実現される。データサービス、徴候検出サービス、及び診断サービスとの通信及びデータ伝送はそれぞれのインタフェースを介して行われる。データサービス、徴候検出サービス、診断サービスは、車両健全性管理システムにおける他の下位要素の内部実装にアクセスすることはないので、データサービス、徴候検出サービス、診断サービスの内部実装が、他要素との相互作用に影響を及ぼすことなしに変更可能となる。このモジュール設計の車両健全性管理システムにより、ＶＨＭに新たな特徴や機能性を付加するのが容易になり、システムの柔軟性と性能が向上する。さらに、ＶＨＭシステムは、テストベットやオペレーションシステムなどの広範囲のシステムに容易に適応可能である。
【００１９】
図３、４、５にデータサービス、徴候検出サービス、診断サービスの一実装例を示す。このような実装はオブジェクト指向プログラミング技術を用いて実現される。一般に、オブジェクト指向プログラミングは、プログラム実装手法の一種であり、プログラムをオブジェクトの協働的な収集として編成し、クラスのインスタンスを各オブジェクトで表現し、継承関係を介して統合されるクラス階層の全メンバをクラスとする手法である。オブジェクト指向プログラミングは、コンピュータプログラムを作成する際の基本的なビルディングブロックとしてアルゴリズムではなくオブジェクトを使用する点で標準的な手続きプログラミングと異なる。
【００２０】
オブジェクト指向設計の眼目は、問題を自律実体のセットとして位置づけ、自律実体間の協働によって解を得る点にある。オブジェクト指向プログラミングにおける自律実体は勿論オブジェクトである。オブジェクト指向プログラミングは手続き型手法とは大きく異なり、問題をコンピュータプログラムまたは手続きにおける階層化したネストではなく、協働オブジェクトのセットに分解する。
【００２１】
したがって、オブジェクト指向プログラムはオブジェクトと呼ばれるコード実体で構成される。各オブジェクトは、クライアントからの要求に応じて１以上のサービスを提供する、識別可能な、コード及びデータのカプセルピースである。概念として、オブジェクトは２つの部分、すなわち外部オブジェクトインタフェースと内部オブジェクト実装部からなる。全てのオブジェクト実装ファンクションはオブジェクトインタフェースによりカプセル化されるので、他のオブジェクトがあるオブジェクトと通信するには、そのオブジェクトインタフェースを介して行わざるを得ない。オブジェクトに対する、検索、プロセス、その他のオペレーションはオブジェクトに定義された方法でしか行えない。これによりオブジェクトの内部データ部は外部からの改ざんに対して、保護される。また、外部のオブジェクトが内部実装部にアクセスする可能性はないので、プログラムの他の側面に影響を及ぼすことなく内部実装部の変更が可能になる。
【００２２】
このように、オブジェクト指向プログラミングは明確に制限されたカプセル化インタフェースによりサービスリクエスタとサービスプロバイダとを分離する。標準的オブジェクトモードの場合、クライアントオブジェクトは所期のファンクションを実現するためにサーバオブジェクトに要求メッセージを送る。要求メッセージはサーバオブジェクトが実行すべき特定の方法を識別するとともに、必要なパラメータを供給する。サーバオブジェクトはメッセージを受け取り、解釈した後、実行すべきサービスを決定する。
【００２３】
オブジェクト指向プログラミングの中核をなすもう１つの概念は「クラス」である。クラスはオブジェクトの種類を定義するテンプレートまたはプロトタイプである。クラスはそのクラスに属するオブジェクトの構成のアウトラインを示す。例えば、クラスはそのクラスの各オブジェクトが使用できる方法や、オブジェクト内にカプセル化されるデータ構造を定義可能である。クラスを定義することで、新たなオブジェクトを生成する毎に、オブジェクトの全定義を改めてしなくても、クラスに属するオブジェクトが生成可能になる。このようなオブジェクト指向プログラミングの特徴は既存定義の再利用を促進し、プログラムコードの効率的な利用を促進するものである。
【００２４】
図３に、データサービスの実装例を表すクラス図３００を示す。この実装例はデータサービスを実装するのに使用可能な、多くの異なるシステムの一例にすぎない。この実装例において、データサービスはデータサービス・マネージャ（DataService Manager）クラスとデータソース（DataSource）クラスで構成される。データサービス・マネージャは車両データを受け取り、フォーマットするというデータサービスの機能性を提供する。データソースはＶＨＭが行う処理のためにデータサービスに供給される種々のデータソースとのインタフェースを提供する。
【００２５】
データサービス・マネージャ（DataService Manager）は、一般マネージャ機能性を提供するサービスマネージャクラスを継承する。一般マネージャ機能性はデータサービス・マネージャの初期化、開始、停止、及びアンインストールの各方法を備える。各方法は、呼び出された際に、呼び出しが指定した状態にデータサービス・マネージャを移して、データサービス・マネージャの基本動作を制御する。さらに、サービスマネージャクラスは、データサービス・マネージャのエラー処理を行うための、初期化エラー（initialze_error）、ランエラー（run_error）、停止エラー（stop_error）の各方法を備える。
【００２６】
データソース（DataSource）クラスはＶＨＭが処理することになる各種データソースに対するインタフェースを提供する。図示の具体例の場合、データソースクラスは図に示すように３例のデータソースに関する抽象化を提供する。データソースの１番目の例はＶＨＭの動作を試験するのに使用するデータ試験ファイルである。データソースの２番目の例は車両からデータを受け取り、ＶＨＭサービスを地上で行うようにしたグランド遠隔測定システムである。データソースの３番目の例は車両搭載システムと直接インタフェースをとるためのＣＤ＆Ｈシステムである。したがってＣＤ＆Ｈシステムは車両搭載ＶＨＭサービスで使用可能なデータソースである。
【００２７】
このために、データソース（DataSource）は異なるデータソース毎にインスタント化される特定のサブクラスに継承される。図示の例の場合、データソースクラスは、ＶＨＭ動作試験用のデータを提供する試験ファイルとインタフェースをとるための試験データ（TestData）クラスに継承される。同様に、データソースクラスは、車両と通信してＶＨＭにデータを供給する遠隔測定システムとインタフェースをとるためのグランド遠隔測定（GroundTelemetry）クラスに継承される。最後に、データソースクラスは、車両搭載システムとインタフェースをとって、車内診断のためにＶＨＭにデータを供給するためのＣＤ＆Ｈデータクラスに継承される。このように、データソースクラスは、ＶＨＭが困難を伴わずに、フォーマットの異なる各種データソースからデータを受け取る能力を与える。
【００２８】
試験データ（TestData）クラスは、試験データファイルを作成するためのビルド・テストセット（build_testset）法と、データサービス・マネージャに試験データファイルデータを供給するためのデータ転送開始（intiate_data_transfer）法を備える。試験データクラスはＶＨＭ用試験データファイルを設定するためのテストケース（TestCases）クラスとインタフェースをとる。具体的には、テストケースクラスはテストケースを設定、構築する設定法を備える。設定されたテストケースは試験データを生成するのに使用される。このように、試験データクラスとテストケースクラスは相俟って、試験ファイルデータを受け取りそれに基づいて行動する能力をＶＨＭに与える。
【００２９】
同様に、グランド遠隔測定（GroundTelemetry）クラスは遠隔測定データストリームに加入する加入（subscribe）法と、データ転送を開始させるデータ転送開始（intiate_data_transfer）法を備える。グランド遠隔測定クラスは遠隔測定システムから地上のＶＨＭへデータストリームを供給するのに使用されるデータ要素辞書を設定するための方法を備えたデータ辞書（DataDictionary）クラスとインタフェースをとる。このように、グランド遠隔測定クラスとデータ辞書クラスは相俟って、車両から遠隔測定データを受け取り、それに応じて行動する能力をＶＨＭに与える。
【００３０】
最後に、ＣＤ＆ＨデータクラスはＣＤ＆Ｈデータストリームに加入する加入（subscribe）法と、データ転送を開始するためのデータ転送開始（intiate_data_transfer）法を備える。ＣＤ＆Ｈデータクラスは、車両搭載システムのどのデータ要素がデータソース抽象化を介してＶＨＭシステムに供給されるかを特定する方法を備えるデータバス仕様（DataBus Spec）クラスとインタフェースをとる。このように、ＣＤ＆Ｈデータクラスとデータバス仕様クラスは相俟って、車両搭載システムと直接インタフェースをとって車内ＶＨＭサービスを提供する能力をＶＨＭに与える。
【００３１】
図４に、徴候検出サービス実装例を表すクラス図４００を示す。この実装例は徴候検出サービスを実装するのに使用可能な、様々なシステムの一例にすぎない。この実装例の場合、徴候検出サービスは徴候検出マネージャ（SymptomDetector Manager）クラス、検出部（Detectors）集合体クラス、及び検出部（aDetector）集合体クラスを備える。徴候検出マネージャはサービスの一般機能性を提供し、個々の検出部の動作を管理、制御する。
【００３２】
データサービス・マネージャと同様に、徴候検出マネージャ（SymptomDetector Manager）は一般マネージャ機能性を提供するサービスマネージャ（aService Manager）クラスを継承する。この一般マネージャ機能性は徴候検出マネージャを初期化、開始、停止、及びアンインストールする各方法を備えるとともに、エラー処理を行う方法を備える。
【００３３】
さらに、徴候検出マネージャ（SymptomDetector Manager）クラスは、データ供給インタフェース（DataSupply IF）を継承する。データ供給インタフェースは徴候検出サービスにインタフェースを提供する。図示の例の場合、データ供給インタフェースは、データサービスから呼び出されてフォーマットされたＶＨＭデータを徴候検出サービスに供給するnew_vhm_data法を備える。そして、このnew_vhm_data法呼び出しが指定したデータは、徴候検出サービスがシステム問題として検出する徴候について検査される。
【００３４】
徴候検出マネージャ（SymptomDetector Manager）は徴候の検索に使用される複数の検出部を使用し、制御する能力を備える。これを促進するため、徴候検出マネージャは１以上の検出（aDetector）オブジェクトの動作を制御する検出（aDetector）集合体クラスを管理する。インスタント化の際、各検出オブジェクトは、データサービスにより特定されて供給されたデータを処理する実行法を備える。
【００３５】
検出部（aDetector）抽象は、様々な検出機構を使用するものを含めて、各種検出部の多くの異なるタイプと実装を表すことができる。図示の例の場合、検出部（aDetector）の例として、診断テスト、トレンド解析アルゴリズム、ニューラルネットワークの実装例が示される。具体的には、適切な検出（aDetector）オブジェクトをインスタント化して検出部集合体に追加することにより、各種タイプについて新たな検出部（aDetector）を徴候検出サービスに付加することができる。勿論、図示のものは、徴候の検出のために実装されて使用が可能な検出部の３つのタイプ例にすぎない。このように徴候検出サービスは単一の明確なインタフェースを介して広範囲の検出タイプ及びサービスを提供する能力を備える。これにより解の柔軟性と頑強性が改善される。
【００３６】
図５に、診断サービス実装例を表すクラス図５００を示す。この実装例は診断サービスの実装に使用可能な、様々なシステムの単なる一例にすぎない。この実装例の場合、診断サービスは診断サービス・マネージャ（DiagnosticService Manager）、推論部（Reasoners）集合体クラス、及び本サービスにおける推論毎の推論部（aReasoner）を備える。診断推論マネージャ（DiagnosticReasoner Manager）はサービスの一般機能性を提供し、個々の推論部の動作を管理、制御する。
【００３７】
データサービス・マネージャや徴候検出マネージャと同様に、診断サービス・マネージャ（DiagnosticService Manager）は一般マネージャ機能性を提供するサービス・マネージャ（aServiceManeger）クラスを継承する。この一般マネージャ機能性は診断サービス・マネージャの初期化、開始、停止、及びアンインストールの各方法とともに、エラー処理の方法を備える。
【００３８】
さらに、診断サービス・マネージャ（DiagnosticService Manager）は徴候検出インタフェース（SymptomDetection IF）を承継する。徴候検出インタフェースは診断サービスにインタフェースを提供する。図示の例の場合、徴候検出インタフェースクラスは、徴候検出サービスから呼び出されて同サービスに検出された徴候を提供する新徴候（new_symptoms）法を備える。このnew_symptoms法呼び出しの指定したデータは検査され、検出された徴候の原因と考えられる、可能性のある診断が下される。
【００３９】
さらに診断サービスは診断インタフェース（Diagnostic IF）クラスを備える。診断インタフェースクラスはインタフェースを提供し、診断サービスはこのインタフェースを介して、同サービスのオペレータ、その他の顧客と通信する。診断サービスの診断結果を取得するために、オペレータ、その他の顧客は診断インタフェースを継承し、加入して診断結果を取得する。このように診断サービスは困難を伴うことなしに様々なオペレータに診断結果を提供する能力を備える。
【００４０】
診断サービス・マネージャ（DiagnosticService Manager）は複数の推論部を利用、制御して可能性のある診断を下す能力を有する。これを促進するために、診断サービス・マネージャは１以上のインスタント化推論部（aReasoner）の動作を制御する推論部（Reasoners）集合体クラスを管理する。各インスタント化推論部は特定の徴候を引き渡すsymptoms_in法と、特定の徴候を処理して可能性のある診断を検索する診断実行部（perform_diagnosis）を備える。
【００４１】
推論部（aReasoners）抽象化は、異なる推論機構を有するものを含めて、特別の検出部の多くの異なるタイプや実装を表すことができる。図示の例の場合、推論部（aReasoners
）としてＣＯＴＳツール、診断アルゴリズム、及びルックアップテーブルが備えられる。このようなそして他の複数の推論部を実装するために、適切な推論（aReasoner）オブジェクトをインスタント化し、推論部（Reasoner）収集に追加することにより、前記及びその他の各種推論オブジェクトを診断サービスに追加することができる。勿論、ＣＯＴＳツール、診断アルゴリズム、ルックアップテーブルは、徴候検出として実装されて使用が可能なタイプの推論部（aReasoners）の３つの具体例にすぎない。このように推論部（aReasoner）クラスは、単一の明確なインタフェースを介して広範囲の診断ツール、サービスを提供する能力を備える。これにより解の柔軟性と頑強性が向上する。
【００４２】
図６に、図３、４、５のモジューラＶＨＭ実装例で使用される、主方法呼び出しの概略フローチャートを示す。具体的には、図６はモジューラＶＨＭの実装で使用されるインスタント化オブジェクトからなされる呼び出しを示したものである。まず、new_data法により車両データをデータサービスに供給する。この車両データは、この場合も、複数の異なるデータソース、例えばデータテストファイル、グランド遠隔測定、あるいはＣＤ＆Ｈなどの車両搭載システムなどから提供される。データサービスはこのデータをフォーマットし、構文解析した後、new_vhm_data法呼び出しにより徴候検出サービスに供給する。これに対し、徴候検出サービスは各種インスタント化検出部（aDetector）を使用してデータを解析する。徴候検出サービスで検出された徴候はnew_symptoms法呼び出しにより診断サービスに渡される。ここで診断サービスは任意の各種インスタント化推論部（aReasoner）を使用して徴候を解析する。そして可能性として下された診断結果はnew_diagnosis法によりオペレータ、その他の顧客に渡される。
【００４３】
図７、８、９、１０、１１、１２に、ＶＨＭシステムの動作、及びモジュールＶＨＭ実装で行われる呼び出し方法の詳細なフローチャートを示す。図７、８、９は、３種類の異なるソース、すなわち、試験データファイル、グランド遠隔測定システム、Ｃ＆ＤＨデータシステムからデータサービスにデータを設定、供給する３つの例を示したものである。これらのデータソースは、代表的な３種類の設定、すなわち、それぞれオフライン、オンライン、及びオンボードにおけるデータ供給選択肢を表す。図１０、１１、１２は、ＶＨＭシステムの正常動作とともに、データサービス、徴候検出サービス、診断サービス間でなされる他の方法呼び出しを示したものである。
【００４４】
図７において、オフライン設定時にデータが試験データファイルからデータサービスに供給される際、テストケースと試験データオブジェクトが使用される。最初のステップは設定（configure）呼び出しであり、この呼び出しによりテストケースオブジェクトは試験シナリオで使用するテストケースを合成する。次に、試験データオブジェクトは、データサービスに送られることになる原試験データを生成するbuild_testset法を受け取る。データサービスは、試験ファイルデータを受け取る準備が整うと、試験データオブジェクトに対してデータ転送開始（initiate_data_transfer）法を呼び出す。これに応じて試験データオブジェクトはデータサービスに対してnew_data法を呼び出して、設定した試験ファイルデータのポインタを渡す。これによりデータサービスオブジェクトは試験ファイルデータを受け取って、徴候検出と診断推論のためのデータ処理が可能になる。
図８において、オンライン設定時にグランド遠隔測定システムからデータサービスにデータが供給される際、データ辞書とグランド遠隔測定オブジェクトが使用される。ここでも最初のステップは設定（configure）呼び出しであり、この呼び出しによりデータ辞書オブジェクトが設定（configure）され、オンラインシナリオで必要になる遠隔測定データ要素が選択される。次に、データ辞書オブジェクトはグランド遠隔測定データストリームに加入するためにsubscribe法を呼び出す。このsubscribe法は、代表的に、加入したデータストリームの詳細を特定するパラメータを含む。データサービスは、グランド遠隔測定システムからデータを受け取る準備が整うと、グランド遠隔測定オブジェクトに対してinitiate_data_transfer法を呼び出す。これに応じ、グランド遠隔測定オブジェクトはデータサービスに対してnew_data法を呼び出し、設定したグランド遠隔測定データのポインタを渡す。これにより、データサービスオブジェクトはグランド遠隔測定データを受け取って、徴候検出と診断推論のためのデータ処理が可能になる。
【００４５】
図９において、オンボード設定時に車内搭載システムからデータサービスにデータが供給される際、データバス仕様とＣ＆ＤＨデータのオブジェクトが使用される。最初のステップはこの場合もconfigure呼び出しであり、この呼び出しにより、車内設定で必要になるＤ＆ＤＨデータ要素がデータバス仕様オブジェクトに設定される。次に、データバス仕様オブジェクトはオンボードＣ＆ＤＨデータストリームに加入するためにsubscribe法を呼び出す。このsubscribe法は代表的に、加入データストリームの詳細を特定するパラメータを含む。データサービスは、車両搭載システムからデータを受け取る準備が整うと、Ｃ＆ＤＨデータオブジェクトに対してinitiate_data_transfer法を呼び出す。Ｃ＆ＤＨデータオブジェクトは、これに応じ、データサービスに対してnew_data法を呼び出し、設定した車両搭載システムデータのポインタを渡す。これにより、データサービスオブジェクトは車両搭載システムデータを受け取って、徴候検出と診断推論のためのデータ処理が可能になる。
【００４６】
図１０において、データはnew_data法によりデータサービスに供給される。図７、８、９の場合と同様に、このデータは、各種データソース、例えば、データ試験ファイル、グランド遠隔測定、またはＣＤ＆Ｈのような車両搭載システムなどから供給可能である。ここでデータサービスは自身に対しprocess_data法を呼び出してデータを処理する。この処理は、代表的に、データをフィルタリングしてＶＨＭアプリケーションに適したフォーマットにする処理を含む。データは処理された後、new_vhm_data法により徴候検出サービスに送られる。
【００４７】
図１１において、new_vhm_data法は徴候検出マネージャ（SymptomDetector Manager）に受け取られる。ここで徴候検出マネージャは検出部（aDetector）に対しexecute法を呼び出す。ここに前記検出部（aDetector）はそのデータから徴候を検出しようとしている検出部であり、execute法は、個々の検出部（aDetector）、例えば、診断テスト、トレンド解析アルゴリズム、ニューラルネットワークなどの検出部が解析で使用するデータセットを特定する。これにより、徴候検出サービスは任意の組合せのインスタント化検出部を使用して任意の特定データセットを解析可能になる。次に検出部は検出した徴候をaSymptom呼び出しにより徴候検出マネージャに返す。ここで徴候は処理され、処理結果はnew_symptoms法呼び出しにより診断サービスに渡される。
【００４８】
図１２において、new_symptoms法呼び出しは診断推論マネージャ（Diagnostic  Reasoner Manager）に受け取られる。そこで診断推論マネージャは、そのデータの徴候を診断しようとしている推論部（aReasoner）に対しsymptoms_in法を呼び出す。これにより、診断サービスは、任意の組合せのインスタント化推論部を使用して任意の特定の徴候セットが解析可能になる。推論部は、自身に対しperform_diagnosisを呼び出して徴候の診断を行う。次に推論部は検出した診断をdiagnosis呼び出しにより診断推論マネージャに返す。ここで診断は処理され、処理結果はnew_diagnosis法呼び出しによりオペレータに渡される。
【００４９】
前述したように、図３〜１２に図示し、説明したモジュールＶＨＭに関する特定のオブジェクト指向実現例は、本発明の実施形態で使用可能なタイプのモジュールＶＨＭの単なる例にすぎない。一般的な変更例として、分散化実現により物理的境界（車内、地上）を超えて要素の実現が可能である。また、階層的実現により各種サービス自体を相互にリンクさせた各種コンポーネントサービスの階層で実現して３つのキーサービス（データサービス、徴候検出サービス、診断サービス）を構成、構築してよい。
【００５０】
このように本発明は柔軟性と性能を改善した車両健全性管理システムを提供する。このモジュール式車両健全性管理システム及び方法では、モジューラ手法によりＶＨＭシステムを明確なインタフェースで分離される下位の論理サブ要素に分割する。このモジュール手法により新たな特徴や機能性をＶＨＭに付加するのが容易になり、システムの柔軟性と性能を向上させることができる。車両健全性管理システムはデータサービス、徴候検出サービス、及び診断サービスを備える。データサービスは複数のソースからシステムデータを受け取り、フォーマットした後、徴候検出サービスにフォーマットされたデータを供給する。徴候検出サービスはフォーマットされたデータを解析してシステム故障の徴候を検索する。データのなかで、システム故障を示す部分は診断サービスに渡される。診断サービスは故障に係るデータ部分を検査して可能性のある診断を下す。その後、診断結果は評価のためにオペレータまたは顧客に渡される。
【００５１】
本書に記載した実施形態及び例は、本発明及びその応用を十分に説明し、それによって当業者による本発明の実施を可能とするためになされたものである。しかしながら、当業者には明らかなように、前記説明及び具体例は専ら例示を目的としてなされたものである。前記記載は包括的でなく、また本発明を開示した形態に限定するものでもない。特許請求の範囲の趣旨から逸脱することなく前記開示に照らして様々な変更、変形が可能である。
【図面の簡単な説明】
【００５２】
【図１】モジュールＶＨＭを備えたコンピュータシステムの模式図である。
【図２】モジュールＶＨＭのブロック図である。
【図３】データサービス実現例のクラス図である。
【図４】徴候検出サービス実現例のクラス図である。
【図５】診断サービス実装例のクラス図である。
【図６】モジュールＶＨＭの具体的な処理の流れを示す処理フローチャートである。
【図７】モジュールＶＨＭの具体的な処理の流れを示す処理フローチャートである。
【図８】モジュールＶＨＭの具体的な処理の流れを示す処理フローチャートである。
【図９】モジュールＶＨＭの具体的な処理の流れを示す処理フローチャートである。
【図１０】モジュールＶＨＭの具体的な処理の流れを示す処理フローチャートである。
【図１１】モジュールＶＨＭの具体的な処理の流れを示す処理フローチャートである。
【図１２】モジュールＶＨＭの具体的な処理の流れを示す処理フローチャートである。
【図１】
0004467564.tif 000002
【図２】
0004467564.tif 000003
【図３】
0004467564.tif 000004
【図４】
0004467564.tif 000005
【図５】
0004467564.tif 000006
【図６】
0004467564.tif 000007
【図７】
0004467564.tif 000008
【図８】
0004467564.tif 000009
【図９】
0004467564.tif 000010
【図１０】
0004467564.tif 000011
【図１１】
0004467564.tif 000012
【図１２】
0004467564.tif 000013