(57)【要約】【課題】故障解析結果において故障原因を特定するための故障時状態情報が不足している場合、不足している故障時状態情報を追加するように要求し得る保守システム及び保守方法を提案する。【解決手段】故障解析手法により得られる故障解析結果に基づいて、故障時の状態から故障原因を特定する保守システムにおいて、故障解析結果に含まれる故障原因と、故障時の状態を示す故障時状態情報とを抽出し、それぞれを関連付ける検査項目決定部と、抽出された故障時状態情報から故障原因を特定することができるか否かを判断する故障特定可否判定部と、抽出された故障時状態情報から故障原因を特定することができない場合、特定することができない故障原因に関連付けた新たな故障時状態情報を故障解析結果に追加するように要求する故障時状態入力部とを備えることを特徴とする。【選択図】図１
2016004279.tif 000002
【特許請求の範囲】
【請求項１】
故障解析手法により得られる故障解析結果に基づいて、故障時の状態から故障原因を特定する保守システムにおいて、
前記故障解析結果に含まれる故障原因と、故障時の状態を示す故障時状態情報とを抽出し、それぞれを関連付ける検査項目決定部と、
前記抽出された故障時状態情報から故障原因を特定することができるか否かを判断する故障特定可否判定部と、
前記抽出された故障時状態情報から故障原因を特定することができない場合、特定することができない故障原因に関連付けた新たな故障時状態情報を前記故障解析結果に追加するように要求する故障時状態入力部と
を備えることを特徴とする保守システム。
【請求項２】
前記故障特定可否判定部は、
前記抽出された故障原因に関連付けられた複数の故障時状態情報の組み合わせに基づいて、一意に故障原因を特定することができるか否かを判断することにより、故障時状態情報から故障原因を特定することができるか否かを判断する
ことを特徴とする請求項１に記載の保守システム。
【請求項３】
前記故障時状態情報は、
故障原因を特定するための検査項目と、検査項目の故障時の状態とを示す情報を含む
ことを特徴とする請求項１に記載の保守システム。
【請求項４】
前記故障時状態入力部により要求された新たな故障時状態情報が追加された後の故障解析結果に基づいて、故障時状態情報から故障原因を特定するための故障特定手順を作成する故障特定手順出力部を備える
ことを特徴とする請求項１に記載の保守システム。
【請求項５】
前記検査項目決定部は、
前記故障解析結果に含まれる故障頻度を抽出し、抽出した故障頻度を前記抽出した故障原因及び故障時状態情報に関連付ける処理を実行し、
前記故障特定手順出力部は、
前記故障頻度に基づいて、前記故障特定手順を作成する
ことを特徴とする請求項４に記載の保守システム。
【請求項６】
故障解析手法により得られる故障解析結果に基づいて、故障時の状態から故障原因を特定する保守システムにおいて、
前記故障解析結果に含まれる故障原因と、故障時の状態を示す故障時状態情報とを抽出し、それぞれを関連付ける検査項目決定部と、
前記抽出された故障時状態情報に含まれる検査項目が同一となるように、故障原因に関連付けた新たな故障時状態情報を一括して前記故障解析結果に追加するように要求する故障時状態一括追加部と
を備えることを特徴とする保守システム。
【請求項７】
前記故障時状態情報は、
故障原因を特定するための検査項目と、検査項目の故障時の状態とを示す情報を含む
ことを特徴とする請求項６に記載の保守システム。
【請求項８】
前記故障時状態一括追加部により要求された新たな故障時状態情報が一括して追加された後の故障解析結果に基づいて、故障時状態情報から故障原因を特定するための故障特定手順を作成する故障特定手順出力部を備える
ことを特徴とする請求項６に記載の保守システム。
【請求項９】
前記検査項目決定部は、
前記故障解析結果に含まれる故障頻度を抽出し、抽出した故障頻度を前記抽出した故障原因及び故障時状態情報に関連付ける処理を実行し、
前記故障特定手順出力部は、
前記故障頻度に基づいて、前記故障特定手順を作成する
ことを特徴とする請求項８に記載の保守システム。
【請求項１０】
故障解析手法により得られる故障解析結果に基づいて、故障時の状態から故障原因を特定する保守システムの保守方法において、
検査項目決定部が、前記故障解析結果に含まれる故障原因と、故障時の状態を示す故障時状態情報とを抽出し、それぞれを関連付ける第１のステップと、
故障特定可否判定部が、前記抽出された故障時状態報から故障原因を特定することができるか否かを判断する第２のステップと、
故障時状態入力部が、前記抽出された故障時状態情報から故障原因を特定することができない場合、特定することができない故障原因に関連付けた新たな故障時状態情報を前記故障解析結果に追加するように要求する第３のステップと
を備えることを特徴とする保守方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、保守システム及び保守方法に関し、特に故障原因と故障結果（故障時の状態）とが関連付けられた故障解析結果に基づいて、故障時の状態から故障原因を特定する保守システム及び保守方法に適用して好適なものである。
【背景技術】
【０００２】
一般に車両や列車の設計段階では、故障の木解析（FTA：Fault Tree Analysis）や故障モード影響解析（FMEA：Failure Model and Effect Analysis）等の故障解析手法を用いて、故障原因及び故障結果（故障時の状態）を解析することが行われる。例えばＦＭＥＡと呼ばれる故障解析手法を用いることにより、「部品１が断線」という故障原因と、「出力１が停止」という故障時の状態とを関連付けた故障解析結果を得ることができる。
【０００３】
設計段階ではこの故障解析結果を参考にすることにより、設計した製品に重大な故障原因が存在しないか、或いは、故障時の状態は安全であるか等を把握することができる。また重大な故障原因が存在する場合にはそれを解消するように再設計することができる。よって市場に流通する段階の製品について信頼性の向上を図ることができる。
【０００４】
ところでこの故障解析結果を利用して、市場に流通した製品が実際に故障した場合に故障時の状態から故障原因を特定する技術が開示されている。
【０００５】
特許文献１には、車両の各種故障症状を列挙表示する故障症状表示手段と、列挙表示される各種故障症状から特定の故障症状を選択する故障症状選択手段と、列挙表示される故障症状毎に関連したモニタ項目を記憶するモニタ項目記憶手段と、選択された特定の故障症状に関連したモニタ項目に基づいて、車両用制御装置のデータをモニタする車両モニタ手段とを備え、モニタ項目記憶手段には故障解析手法により予め決定されたモニタ項目が設定されることを特徴とする車両用電子システムの故障診断装置が開示されている。
【０００６】
この特許文献１によれば、車両用電子システムの故障に対し、ノウハウを持っていない者であっても、特定の故障症状（故障時の状態）を選択するだけで、故障原因の探索のために必要なモニタ項目（点検個所）が自動的に設定されるので、誤診による部品交換や故障の再発生を低減し、点検時間の短縮を図ることができるとしている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開平１０−７８３７６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしこの特許文献１に記載の故障診断装置では、故障時の状態の内容によっては故障原因を特定することができない場合がある。
【０００９】
例えばＦＭＥＡにより、「部品１が断線」と「出力１が停止」、「部品２が断線」と「出力１及び出力２の両方が停止」のように故障原因と故障時の状態とが関連付けられた故障解析結果を得ている場合、「出力１が停止」という故障時の状態を選択しても、「部品１が断線」しているのか、或いは、「部品２が断線」しているのかを区別することができず、故障原因を特定することができない。
【００１０】
ここで仮に、故障解析結果において「部品１が断線」と「出力１が停止」及び「出力２が正常」とが関連付けられていた場合、「出力１が停止」及び「出力２が正常」という故障時の状態を選択すれば、「部品１が断線」という故障原因を特定することができる。しかしＦＭＥＡは、上記したように故障原因と、故障原因が発生した場合に影響を受ける箇所の故障時の状態との関連性を解析する手法である。よってその手法の性質上、通常は故障原因が発生した場合に影響を受けない箇所の状態を故障原因に関連付けることはない。その結果、得られる故障解析結果においては故障原因を特定するための故障時の状態の情報（以下、故障時状態情報と呼ぶ）が不足している。
【００１１】
本発明は以上の点を考慮してなされたもので、故障解析結果において故障原因を特定するための故障時状態情報が不足している場合、不足している故障時状態情報を追加するように要求し得る保守システム及び保守方法を提案するものである。
【課題を解決するための手段】
【００１２】
かかる課題を解決するために、本発明においては、故障解析手法により得られる故障解析結果に基づいて、故障時の状態から故障原因を特定する保守システムにおいて、故障解析結果に含まれる故障原因と、故障時の状態を示す故障時状態情報とを抽出し、それぞれを関連付ける検査項目決定部と、抽出された故障時状態情報から故障原因を特定することができるか否かを判断する故障特定可否判定部と、抽出された故障時状態情報から故障原因を特定することができない場合、特定することができない故障原因に関連付けた新たな故障時状態情報を故障解析結果に追加するように要求する故障時状態入力部とを備えることを特徴とする。
【００１３】
またかかる課題を解決するために、本発明においては、故障解析手法により得られる故障解析結果に基づいて、故障時の状態から故障原因を特定する保守システムの保守方法において、検査項目決定部が、故障解析結果に含まれる故障原因と、故障時の状態を示す故障時状態情報とを抽出し、それぞれを関連付ける第１のステップと、故障特定可否判定部が、抽出された故障時状態報から故障原因を特定することができるか否かを判断する第２のステップと、故障時状態入力部が、抽出された故障時状態情報から故障原因を特定することができない場合、特定することができない故障原因に関連付けた新たな故障時状態情報を故障解析結果に追加するように要求する第３のステップとを備えることを特徴とする。
【発明の効果】
【００１４】
本発明によれば、故障解析結果において故障原因を特定するための故障時状態情報が不足している場合、不足している故障時状態情報を追加するように要求することができる。
【図面の簡単な説明】
【００１５】
【図１】本実施の形態における保守システムの全体構成図である。
【図２】一般的なＦＭＥＡ故障解析結果テーブルの論理構成図である。
【図３】不足項目を追加した後のＦＭＥＡ故障解析結果テーブルの論理構成図である。
【図４】故障特定手順を示す決定木である。
【図５】故障特定手順出力処理を示すフロー図である。
【図６】他の実施の形態における保守システムの全体構成図である。
【図７】不足項目を追加した後のＦＭＥＡ故障解析結果テーブルの論理構成図である。
【図８】故障特定手順出力処理を示すフロー図である。
【発明を実施するための形態】
【００１６】
以下図面について、本発明の一実施の形態を詳述する。
【００１７】
（１）保守システムの全体構成
図１は、本実施の形態における保守システム１の全体構成を示す。保守システム１は、一般的なコンピュータであり、Ｉ／Ｆ部１０、ＣＰＵ２０、記憶部３０及びメモリ４０等を備えて構成される。これらＩ／Ｆ部１０、ＣＰＵ２０、記憶部３０及びメモリ４０は、内部バス（図示省略）により互いに通信可能に接続される。
【００１８】
Ｉ／Ｆ部１０は、ＦＭＥＡ故障解析結果テーブルＴ１を入力するためのインタフェースである。ＦＭＥＡ故障解析結果テーブルＴ１について簡単に説明すると、故障モード影響解析（FMEA：Failure Model and Effect Analysis）と呼ばれる故障解析手法により、故障と故障結果（故障時の状態）との関連性が解析された故障解析結果が格納されたテーブルである。ＦＭＥＡ故障解析結果テーブルＴ１の詳細については後述する（図２、図３）。
【００１９】
なおＩ／Ｆ部１０は、ＦＭＥＡ故障解析結果テーブルＴ１を入力するインタフェースである他、キーボード及びマウス等のようにユーザからの入力を受け付けるインタフェースでもあり、またＬＣＤ（Liquid Crystal Display）等の表示画面のように文字、図形及び画像をユーザに提示するインタフェースでもある。
【００２０】
ＣＰＵ２０は、保守システム１の各部の動作を統括的に制御するプロセッサである。本実施の形態においては、特にＣＰＵ２０はメモリ４０に格納されている各種プログラムと協働して、ＦＭＥＡ故障解析結果テーブルＴ１に基づいて故障を特定するための手順を作成及び出力する処理を実行する。作成される手順及び実行される処理の詳細については後述する（図４、図５）。
【００２１】
記憶部３０は、例えばＨＤＤ（Hard Disk Drive）等の大容量記憶媒体であり、Ｉ／Ｆ部１０により入力されたＦＭＥＡ故障解析結果テーブルＴ１及びＣＰＵ２０により作成される故障特定手順を格納する。なお記憶部３０に格納されるデータはメモリ４０に格納されるとしてもよい。
【００２２】
メモリ４０は、例えばＲＡＭ（Random Access Memory）又はＲＯＭ（Read Only Memory）等の記憶媒体であり、ＣＰＵ２０により読み出される各種プログラムを備える。各種プログラムとしては、検査項目決定部４０１、故障特定可否判定部４０２、故障時状態入力部４０３及び故障特定手順出力部４０４がある。これら各種プログラムにより実行される処理の詳細については後述する（図５）。
【００２３】
（２）ＦＭＥＡ故障解析結果テーブルの構成
図２は、一般的なＦＭＥＡ故障解析結果テーブルＴ１の論理構成を示す。ＦＭＥＡ故障解析結果テーブルＴ１には、故障モード影響解析（ＦＭＥＡ）と呼ばれる故障解析手法により、故障原因と、故障時の状態との関連性が解析された解析結果が格納される。
【００２４】
具体的にＦＭＥＡ故障解析結果テーブルＴ１は、装置欄Ｔ１１、部品欄Ｔ１２、故障モード欄Ｔ１３、原因欄Ｔ１４、故障時状態欄Ｔ１５、Ｔ１６及び頻度欄Ｔ１７から構成される。Ｔ１１〜Ｔ１４には故障原因に関する情報が格納され、Ｔ１５及びＴ１６には故障時の状態に関する情報（故障時状態情報）が格納される。Ｔ１７には実績に基づく故障頻度が格納される。
【００２５】
故障原因に関する情報が格納されるＴ１１〜Ｔ１４について説明すると、装置欄Ｔ１１には装置の識別情報が格納され、部品欄Ｔ１２には装置を構成する部品の識別情報が格納される。また故障モード欄Ｔ１３には故障モードが格納され、原因欄Ｔ１４には故障原因のカテゴリが格納される。
【００２６】
また故障時状態情報が格納されるＴ１５及びＴ１６について説明すると、故障時状態欄Ｔ１５には、故障原因が発生した場合に影響を受ける箇所の単位をコンポーネント単位（装置単位）とした場合にコンポーネントの故障時の状態が格納される。また故障時状態欄Ｔ１６には、故障原因が発生した場合に影響を受ける箇所の単位をシステム単位とした場合にシステムの故障時の状態が格納される。
【００２７】
従って図２の場合、「装置１」は「部品１」〜「部品５」の５個の部品から構成されており、それぞれの部品の故障モードには「断線」及び「短絡」があり、またこれらの故障モードは「電気的破壊」に分類されていることが示されている。そしてこれら「装置１」、「部品１」〜「部品５」、「断線」、「短絡」及び「電気的破壊」等が故障原因に関する情報として格納されていることが示されている。
【００２８】
また図２の場合、コンポーネントとしては「出力１」〜「出力３」の３つがあり、それぞれのコンポーネントの故障時の状態としては「停止」又は「固渋」があることが示されている。またシステムとしては「制御対象１」及び「制御対象２」の２つがあり、それぞれのシステムの故障時の状態としては「上昇不可」、「異常上昇」、「下降不可」、「異常下降」又は「制御不可」があることが示されている。そしてこれらが故障時の状態に関する情報として格納されていることが示されている。
【００２９】
ここで、図２のＦＭＥＡ故障解析結果テーブルＴ１を参照して、故障時の状態から故障原因を特定することができるか否かについて説明する。判定に際しては故障頻度の高い順から行うものとする。よってここでは故障頻度が「４」の「部品３」から判定を始めて、「部品１」、「部品４」、「部品２」、「部品５」の順に判定する。
【００３０】
まず「部品３」について、システムの故障時の状態は「制御対象１制御不可」であるため、システムの状態だけをみて故障原因を特定することはできない。次にコンポーネントの故障時の状態をみると、「出力１及び出力２停止」と「出力１及び出力２固渋」とある。よって「出力１」又は「出力２」の何れかの状態をモニタ等により検査することで、コンポーネントの状態から故障原因を特定することができる。例えばコンポーネントの状態が「出力１停止」であった場合、「部品３断線」という故障原因を特定することができる。
【００３１】
次いで「部品１」についてみると、システムの故障時の状態は「制御対象１上昇不可」と「制御対象１異常上昇」とがある。「制御対象１上昇不可」というシステムの状態は、ここでは１つしかないため、システムの状態が「制御対象１上昇不可」であった場合、システムの状態から「部品１断線」という故障原因を特定することができる。
【００３２】
これに対し、システムの状態が「制御対象１異常上昇」であった場合、「制御対象１異常上昇」という故障時の状態は「部品１短絡」という故障原因に関連付けられている他、「部品４短絡」という故障原因にも関連付けられている。よって「制御対象１異常上昇」というシステムの状態だけをみて故障原因を特定することはできない。
【００３３】
またこの場合におけるコンポーネントの故障時の状態をみると、「部品１」及び「部品４」の何れにおいてもコンポーネントの状態は「出力１固渋」である。よってコンポーネントの状態をみても故障原因を特定することができない。
【００３４】
このように一般的なＦＭＥＡ故障解析結果テーブルＴ１においては、故障原因を特定するための故障時状態情報が不足している。その理由は上記したが、ＦＭＥＡは故障原因と、故障原因が発生した場合に影響を受ける箇所の故障時の状態との関連性を解析する手法であるという性質上、故障原因が発生した場合に影響を受けない箇所の状態についてはあえて関連付ける必要がないためである。
【００３５】
ところで「部品４」のコンポーネントの状態をみると、「出力２停止」が格納されていることから、仮に「部品１」のコンポーネントの状態に「出力２正常」という状態が格納されていれば、「出力２」の状態をモニタ等により検査することで、コンポーネントの状態から「部品１短絡」であるのか、或いは、「部品４短絡」であるのかを区別して故障原因を特定することができるようになる。
【００３６】
図３は、不足項目を追加した後のＦＭＥＡ故障解析結果テーブルＴ２の論理構成を示す。ＦＭＥＡ故障解析結果テーブルＴ２は、本実施の形態における処理（図５）を実行して、故障原因を特定するために不足している故障時状態情報をＦＭＥＡ故障解析結果テーブルＴ１（図２）に追加した後のテーブルである。
【００３７】
ここでのＦＭＥＡ故障解析結果テーブルＴ２は、「部品１」のコンポーネントの状態に「出力２正常」が追加されている点及び「部品２」のコンポーネントの状態に「出力１正常」が追加されている点で、ＦＭＥＡ故障解析結果テーブルＴ１と異なる。
【００３８】
図３の場合、「部品１」のコンポーネントの状態に「出力２正常」が追加されたことにより、「部品１」のコンポーネントの状態をみることで「部品１」と「部品４」とを区別することができるようになっている。具体的には「部品１」について、システムの状態が「制御対象１異常上昇」であり、かつ、コンポーネントの状態が「出力１固渋」及び「出力２正常」であった場合、「部品１短絡」という故障原因を特定することができる。
【００３９】
なお仮に「部品１短絡」という故障原因が発生した場合に「部品１」のコンポーネントの状態が「出力２停止」となる場合、この「出力２停止」が追加されても「部品１」と「部品４」とを区別することができない。この場合、他のコンポーネントの状態（例えば出力３の状態）や他の任意の故障時の状態を「部品１」と「部品４」との区別がつくまで追加するとしてもよい。
【００４０】
また図３の場合、「部品２」のコンポーネントの状態に「出力１正常」が追加されたことにより、「部品４」のコンポーネントの状態をみることで「部品４」と「部品２」とを区別することができるようになっている。具体的には「部品４」について、システムの状態が「制御対象１異常上昇」であり、かつ、コンポーネントの状態が「出力１停止」及び「出力２固渋」であった場合、「部品４短絡」という故障原因を特定することができる。
【００４１】
その他「部品２」及び「部品５」についてもシステム及びコンポーネントの状態から故障原因を特定することができることが示されている。
【００４２】
（３）故障特定手順を示す決定木の構成
図４は、故障特定手順を示す決定木ＤＰ１である。決定木ＤＰ１は、故障時の状態から故障原因を特定するためものであり、ＦＭＥＡ故障解析結果テーブルＴ２（図３）に基づいて作成される。また決定木ＤＰ１において故障原因を特定する順序は、ＦＭＥＡ故障解析結果テーブルＴ２の頻度欄Ｔ２７に格納されている故障頻度に基づいて決定される。
【００４３】
従って図４の場合、まずは故障頻度が最も高い「４」である「部品３」の故障時の状態について判断していることが示されている。また「制御対象１が制御不可」、かつ、「出力１が停止」の場合、「部品３断線」という故障原因が特定されることが示されている。
【００４４】
なおこの決定木ＤＰ１を用いて実際に故障時の状態から故障原因を特定しようとする場合、ＣＰＵ２０により決定木ＤＰ１が解釈され、Ｉ／Ｆ部１０により必要な情報が出力される。例えばＣＰＵ２０の処理により、「制御対象１が制御不可？」というメッセージが表示画面に表示されるとともに「はい」及び「いいえ」という押下可能なボタンが表示画面に表示される。
【００４５】
ユーザがマウス等を用いて「はい」をクリックすると、次に「出力１が停止？」というメッセージに切り替わり、ユーザが再び「はい」をクリックすると、「故障原因は、部品３が断線している可能性があります」という故障原因を示すメッセージが表示画面に表示される。
【００４６】
（４）フローチャート
図５は、故障特定手順出力処理の処理フローを示す。この処理はＩ／Ｆ部１０がＦＭＥＡ故障解析結果テーブルＴ１を入力したことを契機として、ＣＰＵ２０とメモリ４０に格納されている各種プログラムとの協働により実行される。以下説明の便宜上、処理主体を各種プログラムとして説明する。
【００４７】
まず検査項目決定部４０１は、Ｉ／Ｆ部１０によりＦＭＥＡ故障解析結果テーブルＴ１を入力すると（ＳＰ１）、入力したＦＭＥＡ故障解析結果テーブルＴ１を読み込んで、故障原因と、故障時の状態（故障時状態情報）と、故障頻度とを抽出してそれぞれを関連付ける（ＳＰ２）。
【００４８】
次いで故障特定可否判定部４０２は、ステップＳＰ２で抽出した故障頻度のうち、故障頻度の高い順からステップＳＰ３の処理を実行する。すなわち故障特定可否判定部４０２は、ステップＳＰ２で抽出した故障頻度のうち、最も高い故障頻度に関連付けられた故障時状態情報を選択する（ＳＰ３）。
【００４９】
例えばＦＭＥＡ故障解析結果テーブルＴ１（図２）を参照すると、最も高い故障頻度は「４」であり、この故障頻度に関連付けられている故障時の状態はシステム単位では「制御対象１制御不可」であり、コンポーネント単位では「出力１及び出力２停止」又は「出力１及び出力２固渋」であるから、「制御対象１制御不可」かつ「出力１及び出力２停止」又は「制御対象１制御不可」かつ「出力１及び出力２固渋」を選択する。
【００５０】
次いで故障特定可否判定部４０２は、ステップＳＰ３で選択した故障時状態情報から故障原因が特定可能か否かを判断する（ＳＰ４）。
【００５１】
故障特定可否判定部４０２は、ステップＳＰ４の判断で肯定結果を得ると、全ての故障時状態情報を選択したか否かを判断し（ＳＰ５）、全ての故障時状態情報を選択していない場合には次に高い故障頻度に関連付けられた故障時状態情報を選択して、上記の処理を繰り返す。一方で故障特定可否判定部４０２は、ステップＳＰ４の判断で否定結果を得ると、故障原因を特定するために不足している故障時状態情報を追加するように要求する（ＳＰ６）。
【００５２】
例えば故障特定可否判定部４０２は、ステップＳＰ３で選択した故障時状態情報が「出力１固渋」である場合、「出力１固渋」は「部品１短絡」又は「部品４短絡」という故障原因に関連付けられている。よってこのままでは「部品１短絡」と「部品４短絡」とを区別することができず、故障時状態情報から故障原因を特定することができない。
【００５３】
しかし「部品４短絡」には「出力１固渋」の他に「出力２停止」が関連付けられている。よって「部品１短絡」について、「出力１固渋」の他に「出力２」の状態が追加されれば、「部品１短絡」と「部品４短絡」とを区別することができるようになる。そこで故障特定可否判定部４０２は、例えば「出力２の状態を入力して下さい」のようなメッセージを表示画面に表示して、不足している故障時状態情報の追加を要求する。
【００５４】
次いで故障時状態入力部４０３は、ステップＳＰ６で要求した故障時状態情報が入力されると、入力を受け付けて、入力された故障時状態情報をＦＭＥＡ故障解析結果テーブルＴ１に追加する（ＳＰ７）。次いで故障特定可否判定部４０２は、ステップＳＰ５において上記の処理を行い、全ての故障時状態情報を選択した場合にステップＳＰ８に移行する。
【００５５】
故障特定手順出力部４０４は、故障原因を特定するために不足していた故障時状態情報が追加された後のＦＭＥＡ故障解析結果テーブルＴ２に基づいて、例えば決定木ＤＰ１（図４）に示される故障特定手順を作成する（ＳＰ８）。そして故障特定手順出力部４０４は、作成した故障特定手順を記憶部３０に格納し、または表示画面に表示する等の出力処理を実行して（ＳＰ９）、この故障特定手順出力処理を終了する。
【００５６】
（５）本実施の形態による効果
以上のように本実施の形態によれば、ＦＭＥＡ等の故障解析手法により得られる故障解析結果において、故障原因を特定するための故障時状態情報が不足している場合には追加すべき故障時状態情報を作業者に提示することができる。
【００５７】
そして提示した故障時状態情報が追加された場合、追加された後の故障解析結果を利用して、故障時の状態から故障原因を確実に特定することができるようになる。
【００５８】
また故障頻度の高い部品から順に故障原因の特定作業を行うことができるので、作業効率の向上を図ることができる。
【００５９】
（６）他の実施の形態
上記説明してきた実施の形態では、故障原因を特定するための故障時状態情報が不足している場合には不足していることを検知するたびに故障時状態情報の追加を要求するとしたが、必ずしもこれに限らず、故障時状態情報を一括して追加するとしてもよい。以下故障時状態情報を一括して追加する他の実施の形態の構成について説明する。
【００６０】
（７）保守システムの全体構成
図６は、他の実施の形態における保守システム１Ａの全体構成を示す。保守システム１Ａは、故障時状態一括追加部４０５をメモリ４０に備える点で、保守システム１（図１）とは異なる。故障時状態一括追加部４０５は、ＦＭＥＡ故障解析結果テーブルＴ１において故障原因を特定するために不足している故障時状態情報を一括して追加するためのプログラムである。故障時状態一括追加部４０５により追加された後のＦＭＥＡ故障解析結果テーブル及び追加処理については後述する（図７、図８）。
【００６１】
（８）ＦＭＥＡ故障解析結果テーブルの構成
図７は、不足項目を一括して追加した後のＦＭＥＡ故障解析結果テーブルＴ３の論理構成を示す。ＦＭＥＡ故障解析結果テーブルＴ３は、故障原因を特定するために不足している故障時状態情報をＦＭＥＡ故障解析結果テーブルＴ１（図２）に一括して追加した後のテーブルである。
【００６２】
ここでのＦＭＥＡ故障解析結果テーブルＴ３は、故障原因に関連付けられる故障時状態情報が全てにおいて共通している点で、ＦＭＥＡ故障解析結果テーブルＴ１と異なる。例えば「部品１断線」に関連付けられる故障時状態情報も、「部品２断線」に関連付けられる故障時状態情報も全てにおいて「出力１」〜「出力３」、「制御対象１」及び「制御対象２」で共通している。各故障時状態情報の内容（故障時の状態）については故障原因ごとに異なる。
【００６３】
（９）フローチャート
図８は、他の実施の形態における故障特定手順出力処理の処理フローを示す。この処理フローは、ステップＳＰ２の処理が実行された後、故障時状態一括追加部４０５が検故障時状態情報を一括して追加する（ＳＰ１１）点で、図５の故障特定手順出力処理とは異なる。
【００６４】
ステップＳＰ１１の処理の詳細について説明する。まず故障時状態一括追加部４０５は、ステップＳＰ２で関連付けされた故障時状態情報を参照して、故障時状態情報の全ての種類を抽出する。具体的には「出力１」〜「出力３」、「制御対象１」及び「制御対象２」を抽出する。そして故障時状態一括追加部４０５は、抽出した故障時状態情報のうち、ＦＭＥＡ故障解析結果テーブルＴ１に格納されていない故障時状態情報を追加する。
【００６５】
ここで、元々のＦＭＥＡ故障解析結果テーブルＴ１（図１）に格納されていない故障時状態情報は、格納する必要がない情報、すなわち故障原因が発生した場合に影響を受けずに正常動作する「正常」状態の情報か、或いは、完全に独立した箇所であるため全く影響を受けない「関連なし」状態の情報である。よって追加する故障時状態情報については「正常」又は「関連なし」を一括して追加するようにすればよい。
【００６６】
例えば故障時状態一括追加部４０５は、追加しようとする故障時状態情報を表示画面に表示するとともに、一括して追加可能なラジオボタンやチェックボックス等を表示画面に表示する。ステップＳＰ１１の処理の後は上記説明した処理（図５）が行われる。
【００６７】
（１０）他の実施の形態による効果
以上のように他の実施の形態によれば、故障時状態情報を予め一括して追加するようにしたので、故障原因の特定に不足している故障時状態情報を個別に追加する必要がなくなる。よって特に追加すべき故障時状態情報が膨大である場合には作業員の手間を大幅に削減することができる。
【符号の説明】
【００６８】
１、１Ａ  保守システム
１０      Ｉ／Ｆ部
２０      ＣＰＵ
３０      記憶部
４０      メモリ
４０１    検査項目決定部
４０２    故障特定可否判定部
４０３    故障時状態入力部
４０４    故障特定手順出力部
４０５    故障時状態一括追加部
【図１】
2016004279.tif 000003
【図２】
2016004279.tif 000004
【図３】
2016004279.tif 000005
【図４】
2016004279.tif 000006
【図５】
2016004279.tif 000007
【図６】
2016004279.tif 000008
【図７】
2016004279.tif 000009
【図８】
2016004279.tif 000010