JP2014174983A - ターゲットシステムにおいて障害を特定する方法、該方法によりターゲットシステムを修復する手順、該方法を実行するコンピュータシステムおよびコンピュータプログラムならびに該プログラムを格納するコンピュータ可読媒体 - Google Patents

Abstract

【課題】ターゲットシステムにおいて障害を特定する方法を提供する。
【解決手段】ターゲットシステムの故障知識データベース５を提供するステップと、データレコードは故障モードおよび故障症状を特定し；特定のコンポーネントおよびレポートを受け取るステップと；故障知識データベースを参照し候補故障モードおよび症状データレコードを特定するステップと；候補データレコードの信頼値を算出するステップと；信頼値を比較するステップと；保守命令を生成するステップとを有し、さらに、故障知識データベースのサブセットに対し、故障症状の補正データベースを提供するステップを有し、代替コンポーネントと代替故障症状は故障モードおよび症状データレコードを有する。特定するステップは、補正データベースを使用して、代替コンポーネントおよび代替故障症状のデータレコードを含む候補故障モードおよび症状データレコードの数を拡張することを特徴とする。
【選択図】図１

Description

本発明は、ターゲットシステムにおいて障害を特定するための方法およびシステムに関する。

複雑なシステム（例えば鉄道車両）において障害を検知するには、高いレベルの知識および経験を有する障害検知責任者が必要となる。そのため、障害を検出する手順を手助けするための支援システムが開発された。このような支援システムは、知識ベースの内容に基づき、保守員やエンジニアといったユーザに対する指示を出す。無関係な故障モードをフィルタリングにより除外するために、支援システムはセンサや観察結果および／またはテスト結果を利用することができる。観察され、またはレポートされた故障症状を説明する故障モードが複数ある場合、故障モードにランキングを適用して、効率的な障害検知を支援することもできる。

しかしながら、特に最初のインシデントレポートを作成する人が障害検知のスペシャリストでない場合（特に鉄道車両のケースにおいて、最初のレポートはスペシャリストのエンジニアからではなく、電車の運転手から発せられる場合がある）、レポートが不正確な情報やミスリーディングな情報を含むかもしれないという問題がある。そのような場合、支援システムでは正しい故障モードをフィルタリングにより除外してしまい、または間違った故障モードや指示を提供してしまう可能性がある。センサデータやそれに続く複雑なシステムのテストにエラーがあった場合、似たような問題が生じる可能性がある。

本発明の目的は、インシデントレポートや他のデータに間違いがあるという可能性を考慮に入れた、ターゲットシステムにおいて障害を特定するための方法、およびその支援システムを提供することにある。

第一の特徴として、本発明はターゲットシステムにおける障害を特定する方法であって、
前記ターゲットシステムのために故障知識データベースを提供するステップと、ここで前記故障知識データベースは複数の故障モードおよび症状データレコードを特定し、各データレコードは（ｉ）ターゲットシステムのコンポーネント、（ｉｉ）そのコンポーネントの故障モード、および（ｉｉｉ）対応する故障症状、を特定し；
特定のコンポーネントおよびレポートされた故障症状を特定するインシデントレポートを受け取るステップと；
前記故障知識データベースを参照することにより、前記インシデントレポートを説明することのできる候補故障モードおよび症状データレコードを特定するステップと；
前記候補データレコードのそれぞれの信頼値を算出するステップと；
前記算出した信頼値を比較するステップと；
ターゲットシステムのための保守命令を生成するステップとを有し、ここで命令は少なくとも最も高い算出信頼値を有する候補データレコードに関するものであり；
前記方法はさらに、前記故障知識データベースのコンポーネントのサブセットの少なくとも各々に対し、レポートされた故障症状に対する一つまたは複数の可能性のある代替故障症状および／または一つまたは複数の代替コンポーネントを特定するインシデントレポート補正データベースを提供するステップを有し、前記代替コンポーネントと前記代替故障症状は前記故障知識データベース内の対応する故障モードおよび症状データレコードを有し；
前記特定するステップは、前記インシデントレポート補正データベースを使用して、前記インシデントレポートを説明することのできる代替コンポーネントおよび／または代替故障症状のデータレコードを含むように、特定された候補故障モードおよび症状データレコードの数を拡張することを特徴とする、障害を特定する方法を提供する。

このように候補故障モードの数と症状データレコードの数を拡張することにより、本発明の方法は、故障特定過程におけるエラーや不正確さや不確実性を系統立てて考慮に入れることができる。

障害特定のための系統的な方法の例として、インシデントレポート補正データベースは、ペアとなるデータレコードのそれぞれの故障モード間に機能的関係が存在する場合、前記故障知識データベースからデータレコードのペア間のリンクを特定する。この特定するステップにおいて、代替コンポーネントおよび／または前記代替故障症状のデータレコードは直接または間接にリンクされていることを特徴とする。

しかしながら、ペアとなったデータレコードの各故障モード間に機能的な関係が存在しない場合でも、インシデントレポート補正データベースは故障知識データベースからのデータレコードのペア間にリンクを特定する可能性がある。例えば、インシデントレポート内で、あるコンポーネントが別のコンポーネントとして誤って特定されている可能性を考慮に入れるため、対応するコンポーネント同士のデータレコード間にリンクを特定する可能性がある。このようなエラーは、複数の位置に類似のまたは同じコンポーネントが存在する場合に起こる可能性がある。同様に、ひとつのコンポーネントの故障症状が別のコンポーネントの故障症状として間違えられるとき、データレコード間にリンクが特定されることがある。このようなエラーは、故障症状がノイズであるがそのノイズ源が特定しにくいときに起こりうる。

本発明の方法はさらに、一つまたは複数の故障モードに関するセンサ測定値を収集するステップと；前記算出ステップの前に、前記収集したセンサ測定値と矛盾する故障モードを有する特定された候補故障モードと症状データレコードを除外することにより前記特定された候補故障モードと症状データレコードをフィルタリングするステップをさらに含むことを特徴とする。つまり、この方法によると、系統的な方法でセンサ測定値を考慮に入れることができる。さらには、前記方法は前記収集したセンサ測定値に対する修正可能性を特定するセンサ測定値修正データベースを提供するステップを有し、前記フィルタリングするステップは、前記センサ測定値修正データベースから得られた修正収集センサ特定値と矛盾する故障モードを有する特定された候補故障モードおよび症状データレコードを除外し、前記信頼値は前記フィルタリングされた候補データレコードに対して算出されることを特徴とする。このように、インシデントレポート補正データベースにより故障特定手段のエラーや不正確さや不確実性を考慮に入れることができるのと同様に、センサ測定値修正データベースはセンサ測定値におけるエラーや不正確さや不確実性を考慮に入れることができる。

より一般的には、本発明の第二実施例として、ターゲットシステムにおける障害を特定する方法であって、
前記ターゲットシステムのために故障知識データベースを提供するステップと、ここで前記故障知識データベースは複数の故障モードおよび症状データレコードを特定し、各データレコードは（ｉ）ターゲットシステムのコンポーネント、（ｉｉ）そのコンポーネントの故障モード、および（ｉｉｉ）対応する故障症状、を特定し；
特定のコンポーネントおよびレポートされた故障症状を特定するインシデントレポートを受け取るステップと；
一つまたは複数の故障モードに関連するセンサ測定値を収集するステップと；
前記故障知識データベースを参照することにより、前記インシデントレポートを説明することのできる候補故障モードおよび症状データレコードを特定するステップと；
前記収集したセンサ測定値と矛盾する故障モードを有する特定された候補故障モードおよび症状データレコードを除外することにより、前記特定された候補故障モードおよび症状データレコードをフィルタリングするステップと；
フィルタリングされた前記候補データレコードのそれぞれの信頼値を算出するステップと；
前記算出した信頼値を比較するステップと；
ターゲットシステムのための保守命令を生成するステップとを有し、ここで命令は少なくとも最も高い算出信頼値を有する候補データレコードに関するものであり；
前記方法はさらに、収集したセンサ測定値の修正可能性を特定するセンサ測定値修正データベースを提供するステップを有し、
前記フィルタリングするステップは、前記センサ測定値修正データベースから得られた修正収集センサ特定値と矛盾する故障モードを有する特定された候補故障モードおよび症状データレコードを除外することを特徴とする。

本発明の第三の特徴として、本発明はターゲットシステムを修復する手順を提供し、その手順は；
前記第一または第二の特徴による障害特定の方法を実行し、
前記生成した保守命令に基づいて前記ターゲットシステムの保守を行う
ことを特徴とする。

本発明の別の特徴によると、コンピュータ上で動作されたときに、本発明の第一または第二の特徴に基づく方法をコンピュータに実行させるコードを有するコンピュータプログラムや、コンピュータ上で動作されたときに、本発明の第一または第二の特徴に基づく方法をコンピュータに実行させるコードを有するコンピュータプログラムを格納するコンピュータ可読媒体や、前記第一または第二の特徴に基づく方法を実行するようプログラムされたコンピュータシステムを提供する。

例えば、（第一の特徴に基づく）コンピュータシステムは、ターゲットシステムにおいて障害を特定するために提供されることができ、そのシステムは、前記ターゲットシステムのために故障知識データベースを有し、ここで前記故障知識データベースは複数の故障モードおよび症状データレコードを特定し、各データレコードは（ｉ）ターゲットシステムのコンポーネント、（ｉｉ）そのコンポーネントの故障モード、および（ｉｉｉ）対応する故障症状、を特定し；
一つまたは複数のプロセッサは以下のステップを実行するよう構成される：
（ａ）特定のコンポーネントおよびレポートされた故障症状を特定するインシデントレポートを受け取り；
（ｂ）前記故障知識データベースを参照することにより、前記インシデントレポートを説明することのできる候補故障モードおよび症状データレコードを特定し；
（ｃ）前記候補データレコードのそれぞれの信頼値を算出し；
（ｄ）前記算出した信頼値を比較し；
（ｅ）ターゲットシステムのための保守命令を生成し、ここで命令は少なくとも最も高い算出信頼値を有する候補データレコードに関するものであり；
前記システムはさらに、前記故障知識データベースのコンポーネントのサブセットの少なくとも各々に対し、レポートされた故障症状に対する一つまたは複数の可能性のある代替故障症状および／または一つまたは複数の代替コンポーネントを特定するインシデントレポート補正データベースを有し、前記代替コンポーネントと前記代替故障症状は前記故障知識データベース内の対応する故障モードおよび症状データレコードを有し；
前記特定するステップは、前記インシデントレポート補正データベースを使用して、前記インシデントレポートを説明することのできる代替コンポーネントおよび／または代替故障症状のデータレコードを含むように、特定された候補故障モードおよび症状データレコードの数を拡張することを特徴とする。

別の例において、（本発明の第二の特徴に係る）ターゲットシステムにおける障害を特定するコンピュータシステムが提供され、該システムは：
前記ターゲットシステムのために故障知識データベースを提供し、ここで前記故障知識データベースは複数の故障モードおよび症状データレコードを特定し、各データレコードは（ｉ）ターゲットシステムのコンポーネント、（ｉｉ）そのコンポーネントの故障モード、および（ｉｉｉ）対応する故障症状、を特定し；
一つまたは複数のプロセッサは、以下のステップを実行するよう構成され：
（ａ）特定のコンポーネントおよびレポートされた故障症状を特定するインシデントレポートを受け取り；
（ｂ）一つまたは複数の故障モードに関連するセンサ測定値を収集し；
（ｃ）前記故障知識データベースを参照することにより、前記インシデントレポートを説明することのできる候補故障モードおよび症状データレコードを特定し；
（ｄ）前記収集したセンサ測定値と矛盾する故障モードを有する特定された候補故障モードおよび症状データレコードを除外することにより、前記特定された候補故障モードおよび症状データレコードをフィルタリングし；
（ｅ）前記候補データレコードのそれぞれの信頼値を算出し；
（ｄ）前記算出した信頼値を比較し；
（ｅ）ターゲットシステムのための保守命令を生成し、ここで命令は少なくとも最も高い算出信頼値を有する候補データレコードに関するものであり；
前記システムはさらに、収集したセンサ測定値の修正可能性を特定するセンサ測定値修正データベースを提供し、
前記フィルタリングするステップは、前記センサ測定値修正データベースから得られた修正収集センサ特定値と矛盾する故障モードを有する特定された候補故障モードおよび症状データレコードを除外する
ことを特徴とする。

上記の例に記したいずれかのまたは両方のシステムにおけるデータベースは、コンピュータ可読媒体に格納することができる。いずれかのまたは両方のシステムは、さらに受け取ったインシデントレポート、故障モードおよび症状データレコード、算出した信頼値、生成された保守命令のうち一つ以上の情報を表示するための表示装置を有することができる。

本発明の付随的な特徴を以下に記す。これらは本発明のいずれの特徴にも単独でまたは組み合わせて適用可能である。
複数のデータベースは物理的に分けられたデータベースであってもよいし、単独の物理データベースに含まれてもよい。

本方法はさらに、各前記特定された候補故障モードおよび症状データレコードに関し（第二の特徴に基づく方法においては、各特定されおよびフィルタリングされたデータレコードに関し）、そのデータレコードに関して算出されたエラーの信頼値の感度を決定し、
高い感度が決定されたときに、各データレコードを特定して発生する保守命令に警告を含める
ことを特徴とする、請求項１または２に記載のターゲットシステムにおける障害を特定する方法。

本方法はさらに、前記比較するステップの後でかつ保守命令を生成するステップの前に、前記ターゲットシステムに対する診断命令を生成するステップと、ここで命令は、少なくとも最も高い算出信頼値を有する候補データに関連し、前記診断命令における各候補データレコードの故障モードの尤度を決定するため、前記ターゲットシステムに対して診断を行うステップと、前記決定した尤度に基づいて診断命令の各候補データレコードの算出した信頼値を調整するステップとを有することを特徴とする。このように、中間診断評価を使って算出信頼値を向上することができる。診断を行うステップは診断結果を作成し、その結果を保守命令に含めることができる。

本方法はさらに、前記ターゲットシステムの各故障モードに対する保守手順を特定する保守命令データベースを提供するステップを有する。前記生成した保守命令は、前記保守命令内の各候補データレコードの故障モードに対応する保守手順を前記保守命令データベースから得て提供することを特徴とする。
前記ターゲットシステムは、鉄道車両、鉄道インフラまたは鉄道運行システムのいずれかである。
本発明のさらなる特徴は、以下の記載から明らかとなろう。

図１は、ターゲットシステムにおいて障害を特定する支援システムの外観図である。 図２は、鉄道車両用の故障モード、効果（例えば症状）および因果性分析（ＦＭＥＣＡ）を示す図である。 図３は、あるＦＭＥＣＡレコードの例を示す図である。 図４は、ブロックにグループ分けされ、故障−原因リンクでつながれた複数の構造化ＦＭＥＣＡレコードの例を示す図である。 図５は、異なる複雑さおよび機能性レベルを有する複数の鉄道車両コンポーネントの構造化ＦＭＥＣＡレコードの例を示す図である。 図６は、ＦＭＥＣＡレコードの任意的な拡張を示し、各レコードがさらに検査命令へのリンクおよびセンサデータへの一つ以上のリンクを有する状態を示す図である。 図７は、障害特定手順の第一実施例を示すフローチャートである。 図８は、鉄道車両ドアに関するインシデントレポートの例を示す図である。 図９は、ユーザの特定した候補レコードを表示する鎖線のボックスと、直接的または間接的に機能的にリンクした複数の拡張候補レコードを示す点線のボックスとを、図４のリンク付レコードに示した図である。 図１０は、障害特定のための手順を示す第二の実施例のフローチャートである。 図１１は、直接的または間接的に機能的にリンクした複数の拡張候補レコードを示す点線のボックスと、拡張されたレコードからフィルタリングにより除外された候補レコードを示す一点鎖線のボックスとを、図９のリンク付レコードに示した図である。 図１２は、障害特定のための手順を示す第三の実施例のフローチャートである。

次の説明は、本発明の好ましい実施形態を例示的に説明するものであり、本発明の範囲、適用性および構成を制限するものではない。以下に記す本発明の好ましい実施形態の説明に基づいて、当業者には、本発明の範囲を逸脱することなく本発明の好ましい実施例を実施し、また各要素の機能や配置を変更することが可能であろう。

本発明の実施例を十分に理解するための以下の記載には、詳細な説明が含まれる。しかしながら、当業者には理解されている通り、本発明の実施は下記の詳細な説明に基づくことなく実施可能である。例えば、本発明の内容を不明瞭にするのを避けるため、既知の回路、処理、アルゴリズム、構造および技術の説明は省いてある。

また、本発明の実施例は、フローチャート、フロー図、データフロー図、構造図またはブロック図として描かれるプロセスとして説明されることがある。フローチャートでは工程を逐次処理として表現するが、多くの工程は並行してまたは同時に実行可能である。加えて、工程の順番は変更可能である。全工程が完了したときに処理は終了するが、図に示されない追加ステップがあってもよい。処理は、方法、機能、過程、サブルーチン、サブプログラム等に対応する。処理が機能に対応する場合、その終了は機能を呼び出し機能またはメイン機能に戻すことに対応する。

詳細な説明に記すとおり、「コンピュータ可読媒体」とは、データを保存するための一つまたは複数のデバイスであり、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ＲＡＭ、コアメモリ、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリ装置および／または情報を記憶する他の装置可読媒体を含む。「コンピュータ可読媒体」は、携帯または固定の記憶装置、光学記憶装置、無線チャネルおよび指示および／またはデータを保持したり含んだり持ち歩くための多種の媒体を含むが、それらに限定されない。

さらに、本発明の実施例は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、およびそれらの組み合わせによって実施可能である。ソフトウェア、ファームウェア、ミドルウェアまたはマイクロコードによって実施される場合、必要なタスクを実行するためのプログラムコードやコードセグメントは、ストレージ媒体等の機械可読媒体に保存することができる。処理によって必要なタスクを実行することができる。コードセグメントは、手順、機能、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または指示、データ構造またはプログラムステートメントのいずれかの組み合わせを表すことができる。コードセグメントは、情報、データ、引数、パラメータまたはメモリ内容を送受信することにより、他のコードセグメントまたはハードウェア回路に連結することができる。情報、引数、パラメータ、データ等は、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク送信等の適切な手段により、パス、転送または送信することができる。

図１は、ターゲットシステムにおける障害を特定するための支援システム１００を示す外観図であり、ターゲットシステムは例えば、鉄道車両１、鉄道インフラ２または鉄道運行システム３である。該システムは、ターゲットシステムから得られたセンサ測定値を含むセンサデータベース４、故障モードおよび症状データ構造を含む故障知識データベース５、ターゲットシステムの故障モードに対する保守手順を含む保守命令データベース６、可能性のある故障候補の数を拡張するための代替ターゲットシステムコンポーネントおよび代替故障症状を特定するレポートデータ補正知識データベース７、およびセンサ測定値の修正可能性を特定するセンサデータ修正知識データベース８を含む複数のデータベースを有している。支援システムはさらに、故障候補ランキングユニット９、命令生成ユニット１０、およびユーザインタフェースユニット１２を含む処理装置を有する。これらのデータベースおよびユニットの役割について、下記に詳細を説明する。

支援システム１００は、ターゲットシステム内の障害特定に際して、ユーザに対して誤った情報が提供された可能性を系統立てて考慮に入れたアプローチをすることができる。システム１００の重要な要素は故障知識データベース５とレポート補正データベース７であり、それらは図２から７を参照する下記の部分に説明されたタイプの構造化レコードを有することができる。

図２は、鉄道車両用の故障モード、効果（例えば症状）および因果性分析（ＦＭＥＣＡ）の例を示すテーブルである。このテーブルは、コンポーネント（列１）、故障モード（列２）、故障原因（列３）、および故障症状（列４）を特定するためのそれぞれの列を有する。ＦＭＥＣＡテーブルの各行（１から１５の数字が付与されている）は鉄道車両の異なる部分における異なる故障原因を表しており、各故障原因に対して故障モード（例えば故障原因の観測可能な、測定可能な、もしくは検出可能な技術的結果）および故障症状を関連付ける。様々な故障原因およびモードに対して同じである可能性のある故障症状は、車両の運行に対する故障の影響である。より詳しくは、所定の故障症状と所定のコンポーネントの組み合わせにより、一つのＦＭＥＣＡレコードが作成される。そのため、ドアコンポーネントに関して「乗客の乗り降り不可」という故障症状が記載されるＦＭＥＣＡテーブルの１行目は、一つのＦＭＥＣＡレコードを構成し、ドアコンポーネントに関して「運転遅延」という故障症状が記載されるＦＭＥＣＡテーブルの２行目と３行目は別のＦＭＥＣＡレコードを構成する。

図３は、一つのＦＭＥＣＡレコードの説明図であり、所定のコンポーネント、故障症状、故障モードおよびその故障モードおよび症状を発生させる一つまたは複数の故障原因を、鎖線で囲んだボックスで示してある。しかし、点線で囲んだボックスに示す通り、所定のコンポーネントは、別のＦＭＥＣＡレコードの主要コンポーネントでもありうる。各コンポーネントはマルチパートコンポーネントでありうる。

ＦＭＥＣＡレコードは、図４に示すとおり、各ブロックがそれぞれ別のコンポーネントに対応するようなブロックにグループ分けすることができ、それぞれのブロックは鎖線で囲んだボックスとして示される。さらに、図４に示す通り、レコードは故障−原因リンクを通じて他のレコードにリンクすることができる。故障−原因リンクは、二つのレコードのそれぞれの故障モードの間に機能的な関係がある場合に作成することができる。特に、より高い機能的レベルのレコードを有する故障原因を、リンクされた、より低い機能的レベルのレコードの故障症状と対応させることができる。このリンクによってレコードの階層化が行われ、上位レベルの機能をカバーするレコードは、最初は直接的に、その後間接的に、徐々に下位レベルの機能レコードにリンクされる。

機能レベルは典型的にはコンポーネントのサイズおよび／または複雑さに対応する。例えば、図５は複雑さの異なる複数の鉄道車両コンポーネントのＦＭＥＣＡレコードを示す。上位の機能性は、複数の構成要素を有するドアコンポーネントと関連している。中位の機能性は、上述した複数の構成要素、例えばドアレールおよびエアアクチュエータ、と関連している。下位の機能性は、中位のコンポーネントの構成要素と関連しており、エアアクチュエータの場合においては、ピストン、マウント、配管および調整バルブなどがある。

図６は、構造化されたＦＭＥＣＡレコードに対する任意の延長部を示し、ここで各レコードは、検査命令へのリンク、およびその検査により得られる可能性のあるセンサデータへの一つまたは複数のリンクを有する。センサデータは、センサデータベース４に格納することができる。

実施の観点から、故障知識データベース５は基本のＦＭＥＣＡレコードを提供する情報を格納することができ、レポート補正データベース７はレコード間の機能的リンクを提供する情報を格納することができる。

図７は、上述したタイプのＦＭＥＣＡレコードを使って障害特定を行う手順に関する第一実施例のフローチャートを示す。この方法の初期のステージでは、図８に示すタイプのインシデントレポートが作成される。図８に示すインシデントレポート２０は、鉄道車両のドアに関係する出来事であり、コンポーネント２１（つまり、特定の場所にあるドア）および故障症状２２を特定する。インシデントレポートにおいて、故障症状はフリーテキストとして、車両の運行に関する全体的な問題および／または具体的には故障モードに類似したものとして記録することができる。レポートはさらに、出来事の日時２３およびそれぞれの車両の資産ＩＤ２４を含む。レポートは、例えば車両のオペレータまたは保守エンジニアによって作成され、その後支援システム１００のユーザに送られ、表示スクリーン等に表示される。

ユーザは、故障知識データベース５を通してターゲットシステムのＦＭＥＣＡレコードにアクセスし、インシデントレポートに対応するように見える一つまたは複数のレコードを選択する。次に、ユーザはレポート補正データベース７にアクセスし、レコード数を拡張して、インシデントレポートを説明することのできる代替コンポーネントを有するレコードおよび／または代替故障症状を有するレコードをそこに含めることができる。この拡張は自動的な過程であってもよいし、ユーザが行う過程であってもよい。

例えば、図８に示すインシデントレポートは、ドアコンポーネント２１、およびドアが開くのに通常より長い時間がかかるという故障症状２２を特定する。図４と同じリンクされたレコードを示す図９に示す通り、ユーザはこのレポートに基づき、故障知識データベース５から故障を説明しそうな候補レコード（鎖線で囲んだボックスによって示す）を特定することができる。しかしながら、レポート補正データベース７は、第一レコードに直接または間接に機能的にリンクするすべての下位レコードを含むように候補レコードの数を拡張することができる。拡張された候補レコード数は、図９において点線で囲んだボックスで示す。

これらの機能的リンクを使って候補レコードの数を拡張するのに加え、レポート補正データベース７はさらに候補レコードの数を拡張するのに使われるレコード間の非機能性リンクを特定することができる。このさらなるリンクは、ターゲットシステムにおける障害検知経験に基づくことができる。例えば、そのような経験によると、あるインシデントレポートが個別のコンポーネント（図８のレポート２０において、位置Ａにある車両ドア）を特定するとき、レポートにおいて位置が誤って認定された可能性があるということを教示する。そのため、レポート補正データベース７はさらに、客車のすべての車両ドア（例えば位置ＡからＤにあるドア）間のリンクを特定し、候補レコードの拡張数が、位置Ａにあるドアだけでなく、位置Ｂ、ＣおよびＤにある車両ドアのレコード（さらに位置Ｂ、ＣおよびＤにあるドアの対応する機能的にリンクされたレコード）を含むようリンクを特定する。

別の例として、しばしば故障症状として異常機械雑音に関するものがある。しかしながら、音はターゲットシステム内のパスを伝播するものであり、その音を聞いた人は異なるコンポーネントからの音であると誤認する可能性がある。そのため、レポート補正データベース７は、あるコンポーネントの故障症状が、別のコンポーネントの故障症状として誤認されていると考える理由がある時、レコード間のリンクを特定する。

図７に戻り、インシデントレポートを説明することのできる候補故障モードおよび症状データレコードの拡張リストを特定した後、それらを拡張故障レポートに統合することができる。例えば、図８のレポートは、位置Ａ、Ｂ、ＣまたはＤのドアに障害がある可能性を表示するよう拡張することができる。下位の機能的リンクレコードについては、故障知識データベース５に規定されていることから、拡張レポートに表示する必要はない。

次に、支援システム１００の故障候補ランキングユニット９を使用して、候補データレコードの信頼値を算出することができる。これらの値は様々な要因を考慮することができ、それらをスコア化し組み合わせることにより（例えば加算したり乗算したりすることにより）、最終の信頼値を算出する。例えば、要因は以下のものを含むことができる。

・オリジナルのインシデントレポートそのものであって、候補レコードからの用語が（例えば、レコードのコンポーネント、症状、原因またはモードの一部として）レポート内に含まれる場合、レコードには高いスコアがつけられる。高スコアのレコードに機能的にリンクされる下位レコードもまた高いスコアが付けられる。

・もし特定のレコードが支援システム１００のユーザによって事前に特定された場合、そのレコードおよび下位の機能的にリンクされたレコードに対して高スコアが与えられる。

・もしセンサデータに基づいて特定のコンポーネントに障害があると示された場合、そのレコードおよび下位の機能的にリンクされたレコードに対して高いスコアを与えることができる。

・もし候補レコードの異なるコンポーネントに対して障害確率があるというデータが存在する場合、それらに基づいて対応するスコアを与えることができる（高位レベルレコードに対する確率に基づくスコアは、機能的にリンクされた下位レコードのスコアを合計することによって得ることができる）。

・これに関連して、下位レコードに対して多数の機能的リンクを有する故障モードのある候補レコードには高いスコアを与えることができる。なぜならば、対応するコンポーネントが検査され、障害はないと発見された場合、それによって多数の下位候補レコードを排除することができるからである。例えば、ドアの開閉機能をチェックすることにより、多くのドア開閉関連コンポーネントの障害可能性を排除することができる。

・同様に、より高いレベルの候補レコードに対して多数の関連を有する候補レコードには高スコアを与えることができる。なぜならば、それは多数の可能性のある故障モードに対して共通の原因であるからである。

さらに故障候補ランキングユニット９を使用することにより、例えば信頼値の高い順にランキングされた候補レコードのリストの形で、算出された信頼値を比較することができる。

次に、支援システム１００の命令生成ユニット１０は、生成されたターゲットシステムに対する保守命令を生成することができる。保守命令は一番高い信頼値を有する候補データレコードのみに関連するものであってもよいし、候補レコードのランキングリストのすべてまたは一部に関するものであってもよい。命令は、保守命令データベース６から抽出された関連する故障モードのための保守手順を含んでもよい。

支援システム１００のユーザインタフェースユニット１２は上述した障害特定の手順に必要なデータを入力するためのＧＵＩやプロンプトを提供し、またその手順等のデータ構造、レポート、中間および最終結果を表示するためのＧＵＩを提供することができる。

図１０は、第二実施例にかかる、障害特定の拡張手順のフローチャートを示す。拡張手順は、センサデータを受け取るステージ（拡張故障レポートを生成するステージの後に示されるが、それより前でもよい）を含む。例えば、センサデータは、図６に示されるように、故障知識データベース５の構造化されたＦＭＥＣＡレコードにリンクされた基礎検査命令から得ることができ、センサデータベース４に格納される。

センサデータは候補故障モードおよび症状データレコードをフィルタリングする（例えば、数を減らす）のに使用することができる。例えば、図９の候補レコードの拡張数を点線のボックスで表示する図１１に示す通り、もしセンサデータに基づいてエアアクチュエータのエアフローが正常であると表示されると、一点鎖線のボックスに表示されるレコードを候補から外すことができる。

しかしながら、フィルタリングを実施する前に、センサデータ修正知識データベース８に特定されたセンサデータのエラー可能性をさらに考慮に入れる可能性がある。例えば、図１１を参照して、エアアクチュエータ内のエアフローが正常かどうかを表示するため、エア圧力センサから測定値を取り出すことができる。しかしながら、もしセンサが作動温度範囲内のみでしか信頼性のある測定値を提供することができないと分かっている場合、センサデータ修正知識データベースは、一点鎖線のボックスに示されるレコードをフィルタリングすることができるのは、エア圧力センサが通常の圧力を表示し、かつ別の温度センサ測定値によると周囲の温度が作動温度範囲内であると表示されるときだけであると特定することができる。こうして、圧力測定値は補足的な温度測定によって修正される。より簡易な例によると、もし特定のセンサに障害があるかまたは特定のセンサからの通信線に問題があると分かっているまたは疑われる場合、センサデータ修正知識データベースは、そのセンサからのセンサデータは候補故障モードや症状データレコードをフィルタリングするのに使用することができないと特定することができる。

図７や図１０には示されないものの、候補レコードの信頼値を算出した後か、または保守命令が生成され（さらに）センサデータが得られた後、ターゲットシステムの検査を実行することができる。オリジナルセンサデータと共にこのさらなるデータを使って、フィルタリングされた故障レポートを生成または（場合によっては）再生成することができ、信頼値を再算出することができる。つまり、センサデータが新たに取得できたときに、手順をループバックすることができる。

より詳細には、保守命令データベース６はターゲットシステムの故障モードのための保守手順に加えて、診断命令を有することができる。命令生成ユニット１０は、例えば最高の算出信頼値の候補データレコードに関して、ターゲットシステムのための診断命令を生成することができる。（さらなる）センサデータの形の診断結果を、フィルタされた故障レポートとして生成または再生成し、信頼値を再算出するのに使用することができる。診断結果を最終保守命令に含めることができる。

図１２は、第三実施例にかかる、障害特定のさらなる拡張手順のフローチャートを示す。第一および第二実施例に関して、さらなる拡張手順は、間違った情報が信頼値の算出に使用されるリスクを評価するステージを含む。言い換えると、候補データレコードに関するエラーに対して算出された信頼値の感度を判断することができる。

一つの候補レコードに対する信頼値の変更は、以下のように定義することができる。
Ｃ（ｉ、ｍ）＝（Ｘ＿ｍｏｄ−Ｘ＿ｏｒｇ）／Ｘ＿ｏｒｇ
ここで、ｉは候補レコード番号であり、ｍは情報修正パターンであり、Ｘ＿ｏｒｇはｉ番目のレコードのオリジナルの信頼値であり、Ｘ＿ｏｒｇはｍ番目の情報修正パターンにおけるｉ番目のレコードの修正信頼値である。信頼値を算出するのに使用されるスコアを変更することにより、異なる情報パターンをテストすることができる。例えば、もしセンサが所定のコンポーネントの障害確率が高いと示す測定値を出した場合、そのコンポーネントはその信頼値算出において、対応する高スコアを有することができる。情報修正パターンのうちの一つによって、そのセンサ測定値のスコアを下げたり除外したりすることにより、その測定値の誤りの感度をテストする。

所定の変更情報修正パターンに対して、パターンに関連する合計の感度を以下のように定義することができる。
Ｔ（ｍ）＝（Σ（Ｃ（ｉ、ｍ））^２）^１／２
ここでΣはｉレコードに対する総和を示す。もしΣ（Ｃ（ｉ、ｍ））がマイナスである場合、手順は感度を評価する目的で特定の情報修正パターンを無視することができる。なぜならば修正されたパターンは矛盾を含んでいる可能性が高いからである。

もしＴ（ｍ）が大きい場合、その情報修正パターンにある変更情報がターゲットシステムの調査のために重要であるということが分かる。なぜならば、もし情報が間違いだとすると、それが全検査／保守処理に影響を与える可能性があるからである。このように、リスク評価ステージにより、ターゲットシステムのクリティカルな要素に関するそれ以降に生成された保守命令や診断命令に、警告を含ませることができる。

もし最大のＸ＿ｏｒｇを有するレコードのＸ＿ｍｏｄの値がそのレコードのＸ＿ｏｒｇの値よりも大きい場合、障害特定分析が誤った情報（例えば、それぞれの情報修正パターンから除外される誤ったセンサ測定値）に基づいて行われた可能性があるということを表す。適切なメッセージまたは警告を保守命令に加えることができる。

１：鉄道車両
２：鉄道インフラストラクチャ
３：鉄道運行システム
４：センサＤＢ
５：障害知識ＤＢ
６：保守命令ＤＢ
７：レポートデータ補正知識ＤＢ
８：センサデータ修正知識ＤＢ
９：故障候補ランキングユニット
１０：命令生成ユニット

Claims (15)

1. ターゲットシステム（１、２、３）における障害を特定する方法であって、
   前記ターゲットシステムのために故障知識データベース（５）を提供するステップと、ここで前記故障知識データベースは複数の故障モードおよび症状データレコードを特定し、各データレコードは（ｉ）ターゲットシステムのコンポーネント、（ｉｉ）そのコンポーネントの故障モード、および（ｉｉｉ）対応する故障症状を特定し；
   特定のコンポーネントおよびレポートされた故障症状を特定するインシデントレポートを受け取るステップと；
   前記故障知識データベースを参照することにより、前記インシデントレポートを説明することのできる候補故障モードおよび症状データレコードを特定するステップと；
   前記候補データレコードのそれぞれの信頼値を算出するステップと；
   前記算出した信頼値を比較するステップと；
   ターゲットシステムのための保守命令を生成するステップとを有し、ここで命令は少なくとも最も高い算出信頼値を有する候補データレコードに関するものであり；
   前記方法はさらに、前記故障知識データベースのコンポーネントのサブセットの少なくとも各々に対し、レポートされた故障症状の原因としての可能性がある一つまたは複数の代替コンポーネントおよび／または一つまたは複数の代替故障症状を特定するインシデントレポート補正データベース（７）を提供するステップを有し、前記代替コンポーネントと前記代替故障症状は前記故障知識データベース内の対応する故障モードおよび症状データレコードを有し；
   前記特定するステップは、前記インシデントレポート補正データベースを使用して、前記インシデントレポートを説明することのできる代替コンポーネントおよび／または代替故障症状のデータレコードを含むように、特定された候補故障モードおよび症状データレコードの数を拡張することを特徴とする、障害を特定する方法。
2. 前記インシデントレポート補正データベースは、ペアとなるデータレコードのそれぞれの故障モード間に機能的関係が存在する場合、前記故障知識データベースからデータレコードのペア間のリンクを特定し；
   前記特定するステップにおいて、代替コンポーネントおよび／または前記代替故障症状のデータレコードは直接または間接にリンクされていることを特徴とする、請求項１に記載のターゲットシステムにおける障害を特定する方法。
3. 一つまたは複数の故障モードに関するセンサ測定値を収集するステップと；
   前記算出ステップの前に、前記収集したセンサ測定値と矛盾する故障モードを有する特定された候補故障モードと症状データレコードを除外することにより前記特定された候補故障モードと症状データレコードをフィルタリングするステップをさらに含むことを特徴とする、請求項１または２に記載のターゲットシステムにおける障害を特定する方法。
4. 前記方法はさらに、前記収集したセンサ測定値に対する修正可能性を特定するセンサ測定値修正データベース（８）を提供するステップを有し、
   前記フィルタリングするステップは、前記センサ測定値修正データベースから得られた修正収集センサ特定値と矛盾する故障モードを有する特定された候補故障モードおよび症状データレコードを除外し、
   前記信頼値は前記フィルタリングされた候補データレコードに対して算出されることを特徴とする、請求項３に記載のターゲットシステムにおける障害を特定する方法。
5. ターゲットシステムにおける障害を特定する方法であって、
   前記ターゲットシステムのために故障知識データベース（５）を提供するステップと、ここで前記故障知識データベースは複数の故障モードおよび症状データレコードを特定し、各データレコードは（ｉ）ターゲットシステムのコンポーネント、（ｉｉ）そのコンポーネントの故障モード、および（ｉｉｉ）対応する故障症状を特定し；
   特定のコンポーネントおよびレポートされた故障症状を特定するインシデントレポートを受け取るステップと；
   一つまたは複数の故障モードに関連するセンサ測定値を収集するステップと；
   前記故障知識データベースを参照することにより、前記インシデントレポートを説明することのできる候補故障モードおよび症状データレコードを特定するステップと；
   前記収集したセンサ測定値と矛盾する故障モードを有する特定された候補故障モードおよび症状データレコードを除外することにより、前記特定された候補故障モードおよび症状データレコードをフィルタリングするステップと；
   前記フィルタリングされた候補データレコードのそれぞれの信頼値を算出するステップと；
   前記算出した信頼値を比較するステップと；
   ターゲットシステムのための保守命令を生成するステップとを有し、ここで命令は少なくとも最も高い算出信頼値を有する候補データレコードに関するものであり；
   前記方法はさらに、収集したセンサ測定値の修正可能性を特定するセンサ測定値修正データベース（８）を提供するステップを有し、
   前記フィルタリングするステップは、前記センサ測定値修正データベースから得られた修正収集センサ特定値と矛盾する故障モードを有する特定された候補故障モードおよび症状データレコードを除外する
   ことを特徴とする、障害を特定する方法。
6. 前記特定された各候補故障モードおよび症状データレコードに関し、そのデータレコードに関して算出されたエラーの信頼値の感度を決定し、
   高い感度が決定されたときに、各データレコードを特定して発生する保守命令に警告を含める
   ことを特徴とする、請求項１または２に記載のターゲットシステムにおける障害を特定する方法。
7. 前記フィルタリングされた各候補故障モードおよび症状データレコードに関し、そのデータレコードに関して算出されたエラーの信頼値の感度を決定し、
   高い感度が決定されたときに、各データレコードを特定して発生する保守命令に警告を含める
   ことを特徴とする、請求項３から５のいずれかに記載のターゲットシステムにおける障害を特定する方法。
8. 前記方法はさらに、前記比較するステップの後でかつ保守命令を生成するステップの前に、
   前記ターゲットシステムに対する診断命令を生成するステップと、ここで命令は、少なくとも最も高い算出信頼値を有する候補データに関連するものであり；
   前記診断命令における各候補データレコードの故障モードの尤度を決定するため、前記ターゲットシステムに対して診断を行うステップと；
   前記決定した尤度に基づいて診断命令の各候補データレコードの算出した信頼値を調整するステップとを有する
   ことを特徴とする、前記各請求項のいずれかに記載のターゲットシステムにおける障害を特定する方法。
9. 前記診断を行うステップは、診断結果を算出し、前記発生した保守命令は前記診断結果を含む
   ことを特徴とする、前記請求項８に記載のターゲットシステムにおける障害を特定する方法。
10. 前記方法は、前記ターゲットシステムの各故障モードに対する保守手順を特定する保守命令データベース（６）を提供するステップをさらに有し、
    前記生成した保守命令は、前記保守命令内の各候補データレコードの故障モードに対応する保守手順を前記保守命令データベースから得て提供する
    ことを特徴とする、前記各請求項のいずれかに記載のターゲットシステムにおける障害を特定する方法。
11. 前記ターゲットシステムは、鉄道車両、鉄道インフラストラクチャまたは鉄道運行システムのいずれかである
    ことを特徴とする、前記各請求項のいずれかに記載のターゲットシステムにおける障害を特定する方法。
12. 前記各請求項のいずれかに記載の障害を特定する方法を実行し；
    前記生成した保守命令に基づいて前記ターゲットシステムの保守を行う
    ことを特徴とする、ターゲットシステムを修復する手順。
13. 前記請求項１から１１のいずれかに記載の方法を実行するためにプログラムされた、コンピュータシステム（１００）。
14. コンピュータ上で動作されたときに、前記請求項１から１１のいずれかに記載の方法をコンピュータに実行させるコードを有する、コンピュータプログラム。
15. 前記請求項１４のコンピュータプログラムを格納する、コンピュータ可読媒体。