(57)【特許請求の範囲】
【請求項１】
検出されたエラーの原因となる事象を特定する故障診断部を備え、
前記故障診断部は、
前記エラーの原因となる事象の特定に費やすことができる診断可能時間を算出するとともに、
検出される各エラーについて、当該エラーの原因となる各事象が発生している確率である事後確率と、前記各事象が前記当該エラーの原因であると特定するために要する診断時間と、前記診断可能時間とに基づいて、前記エラーの原因となる前記事象を特定する
制御装置。
【請求項２】
前記故障診断部は、前記エラーの原因となる前記事象の組み合わせのうち、前記診断時間の合計が前記診断可能時間に収まるものの中から、前記事後確率の総和が最も高いものを診断対象とする事象のセットとし、前記セットの中で前記事後確率が高い順に診断を行う
請求項１に記載の制御装置。
【請求項３】
前記故障診断部は、前記事後確率が高い順に診断を行い、前記各事象の診断を開始する前に、これから診断を開始しようとする事象の診断を行うと前記診断可能時間を超過するか否かを判定し、超過する場合には、診断を終了する
請求項１に記載の制御装置。
【請求項４】
前記故障診断部は、前記診断時間の逆数と前記事後確率との積から、前記診断時間当たりの原因特定確率の期待値を算出し、前記原因特定確率の期待値が高い順に診断を行う
請求項３に記載の制御装置。
【請求項５】
前記故障診断部は、前記エラーの原因となる事象に対応する演算部の次の動作モードに係る機能の高さを示す機能レベルと前記事後確率との積から、前記機能レベルの期待値を算出し、前記機能レベルの期待値が高い順に診断を行う
請求項３に記載の制御装置。
【請求項６】
前記制御装置の主機能である制御演算を行うとともに、前記故障診断部からの通知に応じた動作モードに遷移する演算部をさらに備え、
前記故障診断部は、前記エラーの原因となる前記事象が特定された場合および前記エラーの原因となる事象が特定されなかった場合の前記演算部における次の動作モードを記憶し、診断結果に基づいて、前記演算部の動作モードを選択して前記演算部に通知する
請求項１から請求項５までのいずれか１項に記載の制御装置。
【請求項７】
前記故障診断部は、前記エラーの原因となる事象が前記演算部における次の動作モードに影響を与えるもののみを、診断の対象にする
請求項６に記載の制御装置。
【請求項８】
前記故障診断部は、前記事後確率をあらかじめ記憶し、エラーが検出された場合に、記憶した前記事後確率を呼び出して前記エラーの原因となる事象を特定する
請求項１から請求項７までのいずれか１項に記載の制御装置。
【請求項９】
前記故障診断部は、複数のエラーが同時に検出された場合に、前記複数のエラーの発生後に、前記複数のエラーの集合に対する原因となる事象毎の事後確率を算出する
請求項１から請求項８までのいずれか１項に記載の制御装置。
【請求項１０】
検出されたエラーの原因となる事象を特定する故障診断部を備えた制御装置で実行される故障時処理方法であって、
前記故障診断部により、
前記エラーの原因となる事象の特定に費やすことができる診断可能時間を算出するステップと、
検出される各エラーについて、当該エラーの原因となる各事象が発生している確率である事後確率と、前記各事象が前記当該エラーの原因であると特定するために要する診断時間と、前記診断可能時間とに基づいて、前記エラーの原因となる前記事象を特定するステップと、
を有する制御装置の故障時処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、エラー検出機能が設けられた制御装置、およびこの制御装置の故障時処理方法に関する。
【背景技術】
【０００２】
信頼性が求められる制御装置には、一般的に、制御装置内の故障や異常を検出するエラー検出機能が設けられている。なお、エラーの原因となる事象は、複数考えられることから、必ずしもエラー検出機能により原因となる事象を特定できるとは限らない。【０００３】
そこで、検出されたエラーに対して、例えば故障分析手法であるＦＴＡ（フォルトツリー解析：Ｆａｕｌｔ  Ｔｒｅｅ  Ａｎａｌｙｓｉｓ）を用いて原因となり得る基本事象を列挙し、基本事象の中からエラーの原因となる事象を解析する方法がある。【０００４】
ここで、この方法を応用し、事前の観察データに基づいて算出した各事象が発生する確率である事前確率と、ある事象が検出されたエラーを発生させる確率である尤度値とに基づいて、ベイズ法により原因となる事象の事後確率を算出し、事後確率が高い順に原因究明のための診断を行う設備診断装置が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平４−８４２２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に記載された設備診断装置では、原因となる事象の特定に要する時間が考慮されていないため、この装置が適用されるシステムを停止した状態で診断を行う必要がある。そのため、特許文献１に記載された設備診断装置を、エラー検出時も縮退動作等による動作の継続が求められるシステムに適用することができないという問題がある。【０００７】
この発明は、上記のような課題を解決するためになされたものであり、エラー検出時も適用されるシステムの動作を可能な限り停止させることなく、機能縮退等により動作の継続を可能にするとともに、エラーの原因となる事象を特定することができる制御装置および制御装置の故障時処理方法を得ることを目的とする。
【課題を解決するための手段】
【０００８】
この発明に係る制御装置は、検出されたエラーの原因となる事象を特定する故障診断部を備え、故障診断部は、エラーの原因となる事象の特定に費やすことができる診断可能時間を算出するとともに、検出される各エラーについて、当該エラーの原因となる各事象が発生している確率である事後確率と、各事象が当該エラーの原因であると特定するために要する診断時間と、診断可能時間とに基づいて、エラーの原因となる事象を特定するものである。
【０００９】
また、この発明に係る制御装置の故障時処理方法は、検出されたエラーの原因となる事象を特定する故障診断部を備えた制御装置で実行される故障時処理方法であって、故障診断部により、エラーの原因となる事象の特定に費やすことができる診断可能時間を算出するステップと、検出される各エラーについて、当該エラーの原因となる各事象が発生している確率である事後確率と、各事象が当該エラーの原因であると特定するために要する診断時間と、診断可能時間とに基づいて、エラーの原因となる事象を特定するステップと、を有するものである。
【発明の効果】
【００１０】
この発明に係る制御装置および制御装置の故障時処理方法によれば、故障診断部は、エラーの原因となる事象の特定に費やすことができる診断可能時間を算出するとともに、エラー検出部で検出される各エラーについて、当該エラーの原因となる各事象が発生している確率である事後確率と、各事象がエラーの原因であると特定するために要する診断時間と、診断可能時間とに基づいて、エラーの原因となる事象を特定する。
そのため、エラー検出時も適用されるシステムの動作を可能な限り停止させることなく、機能縮退等により動作の継続を可能にするとともに、エラーの原因となる事象を特定することができる。
【図面の簡単な説明】
【００１１】
【図１】この発明の実施の形態１に係る制御装置を示すブロック構成図である。
【図２】この発明の実施の形態１に係る制御装置を示すハードウェア構成図である。
【図３】この発明の実施の形態１に係る制御装置を自動車の自動運転システム用コントローラに適用した状態を示す構成図である。
【図４】この発明の実施の形態１に係る制御装置の故障診断マイコンにおけるＲＯＭに保存されたテーブルを示す説明図である。
【図５】この発明の実施の形態１に係る制御装置の事後故障確率テーブルを示す説明図である。
【図６】この発明の実施の形態１に係る制御装置の診断時間テーブルを示す説明図である。
【図７】この発明の実施の形態１に係る制御装置の動作モード判定テーブルを示す説明図である。
【図８】この発明の実施の形態１に係る制御装置の演算部における処理を示すフローチャートである。
【図９】この発明の実施の形態１に係る制御装置の故障診断部における処理を示すフローチャートである。
【図１０】この発明の実施の形態１に係る制御装置における診断可能時間を示す説明図である。
【図１１】この発明の実施の形態２に係る制御装置の故障診断マイコンにおけるＲＯＭに保存されたテーブルを示す説明図である。
【図１２】この発明の実施の形態２に係る制御装置の事前故障確率テーブルを示す説明図である。
【図１３】この発明の実施の形態２に係る制御装置の尤度値テーブルを示す説明図である。
【図１４】この発明の実施の形態２に係る制御装置の故障診断部における処理を示すフローチャートである。
【図１５】この発明の実施の形態３に係る制御装置の故障診断部における処理を示すフローチャートである。
【図１６】この発明の実施の形態４に係る制御装置の故障診断部における処理を示すフローチャートである。
【図１７】この発明の実施の形態５に係る制御装置の動作モード判定テーブルを示す説明図である。
【図１８】この発明の実施の形態５に係る制御装置の故障診断部における処理を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、この発明に係る制御装置および制御装置の故障時処理方法の好適な実施の形態につき図面を用いて説明するが、各図において同一、または相当する部分については、同一符号を付して説明する。
【００１３】
実施の形態１．
図１は、この発明の実施の形態１に係る制御装置を示すブロック構成図である。図１において、制御装置１は、制御装置１の主機能である制御演算を行う演算部１１と、エラーの原因となる事象を特定する故障診断部１２と、制御装置１内で発生したエラーを検出するエラー検出部１３とを備えている。
【００１４】
エラー検出部１３は、制御装置１内で発生したエラーを検出すると、故障診断部１２にエラーを通知する。故障診断部１２は、エラーの原因となる事象を特定すると、その事象に応じた次の動作モードを演算部１１に通知する。
【００１５】
図２は、この発明の実施の形態１に係る制御装置を示すハードウェア構成図である。図２において、制御装置１は、制御演算マイコン２０と故障診断マイコン３０とを備えている。制御演算マイコン２０は、制御装置１の主機能である制御演算を行うマイコンを想定し、故障診断マイコン３０は、エラー検出時に原因となる事象を特定するマイコンを想定している。以下、ハードウェアを、Ｈ／Ｗと表記することもある。
【００１６】
制御演算マイコン２０は、ＣＰＵ２１、ＲＯＭ２２、エラー検出器２３、ＲＡＭ２４、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）コントローラ２５および予備ＣＡＮコントローラ２６を有している。エラー検出器２３は、マイコン内で発生したエラーを検出するモジュールである。故障診断マイコン３０は、ＣＰＵ３１、ＲＯＭ３２およびＲＡＭ３３を有している。制御演算マイコン２０と故障診断マイコン３０とは、バスブリッジ４０で互いに接続されている。
【００１７】
また、制御装置１は、制御演算マイコン２０の外にＣＡＮトランシーバ５０および予備ＣＡＮトランシーバ６０を備え、ＣＡＮトランシーバ５０および予備ＣＡＮトランシーバ６０を介してＣＡＮネットワークに接続されている。すなわち、通常時は、ＣＡＮコントローラ２５およびＣＡＮトランシーバ５０によりＣＡＮ通信を行い、これらの装置が故障した場合には、予備ＣＡＮコントローラ２６および予備ＣＡＮトランシーバ６０によりＣＡＮ通信を行う。
【００１８】
ここで、図１に示した演算部１１は、制御演算マイコン２０からエラー検出器２３を除いた部分と、ＣＡＮトランシーバ５０および予備ＣＡＮトランシーバ６０とに相当する。また、図１に示した故障診断部１２は、故障診断マイコン３０に相当する。また、図１に示したエラー検出部１３は、エラー検出器２３に相当する。
【００１９】
なお、制御演算マイコン２０と故障診断マイコン３０とは、互いに独立しており、制御演算マイコン２０にエラーが発生した場合であっても、故障診断マイコン３０は、影響を受けずに動作可能となるよう設計されているものとする。また、故障診断マイコン３０は、ＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）として実装されていてもよい。
【００２０】
図３は、この発明の実施の形態１に係る制御装置を自動車の自動運転システム用コントローラに適用した状態を示す構成図である。図３において、カーナビ２、ＧＰＳ（Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）３、センサ４といった、車外と接続する装置が接続されたネットワークと、ＥＰＳ  ＥＣＵ（Ｅｌｅｃｔｒｉｃ  Ｐｏｗｅｒ  Ｓｔｅｅｒｉｎｇ  Ｅｎｇｉｎｅ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ）５、ブレーキＥＣＵ６といった、車内の制御ＥＣＵが接続されたネットワークとが、車載ゲートウェイ７で互いに接続されている。
【００２１】
ここで、制御装置１は、後者のネットワークに接続され、ＧＰＳ３やセンサ４の情報を受けとり、ＥＰＳ  ＥＣＵ５、ブレーキＥＣＵ６の制御指令値を演算し、各ＥＣＵに出力する。ただし、この発明の実施の形態１に係る制御装置は、自動運転システム用コントローラへの適用に限定されるものではなく、種々のシステムに適用可能である。
【００２２】
図４は、この発明の実施の形態１に係る制御装置の故障診断マイコンにおけるＲＯＭに保存されたテーブルを示す説明図である。図４において、ＲＯＭ３２は、事後故障確率テーブル３２１、診断時間テーブル３２２および動作モード判定テーブル３２３を有している。
【００２３】
図５は、この発明の実施の形態１に係る制御装置の事後故障確率テーブルを示す説明図である。図５において、事後故障確率テーブル３２１は、エラーの原因となり得る事象と、発生し得るエラーとを示すマトリクス表である。
【００２４】
ここで、事象フィールドに登録すべき事象は、その事象が発生しているか否かが、システムの次の動作の選択に影響を与えるものに限る。また、事象フィールドに登録すべき事象は、故障モード単位であってもよいし、ハードウェアモジュール単位であってもよいし、ある機能モジュール単位であってもよい。
【００２５】
例えば、ＣＡＮの通信ＣＲＣ（巡回冗長検査：Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）エラーが発生した場合、原因となる事象として、ハードウェアモジュール単位では、通信路、ＣＡＮコントローラ、ＣＡＮトランシーバ、送受信データを保存するメモリ等の故障が考えられる。
【００２６】
このうち、通信路およびメモリについては、故障モードに応じて次の動作が変わる。すなわち、通信路について、一時的なノイズで故障した場合には、データ再送により通信が復旧する可能性が高いが、断線している場合には、ＣＡＮ通信機能を切り離して縮退動作を行う必要がある。
【００２７】
また、メモリについて、放射線によるビット反転であれば、正しい値を書き込むことで通信が復旧可能であるが、ビットの固着やカップリング故障のようなハードウェアの故障であれば、当該ＲＡＭ領域を用いた通信の復旧は難しいため、データ保存アドレスの変更や、冗長系を組んでいるならば待機系への移行等が考えられる。
【００２８】
一方、上述したハードウェアモジュールのうち、ＣＡＮコントローラおよびＣＡＮトランシーバの故障の場合には、ＣＡＮ通信の復旧は難しいため、ＣＡＮ通信機能を切り離して縮退動作を行う必要がある。
【００２９】
以上から、上記の例において、通信路やメモリに関する事象については、事象フィールドに故障モードを登録し、ＣＡＮトランシーバやＣＡＮコントローラに関する事象については、事象フィールドにＣＡＮ  ハードウェアモジュール故障として登録しておく。
【００３０】
また、事後故障確率テーブル３２１の各要素には、エラーが検出されたという条件のもと、各事象が発生する条件付き確率を、事後確率として保存する。以下、事後確率の求め方について説明する。まず、エラーＥiが検出された場合の原因となる事象Ｍjの事後確率Ｐ（Ｍj｜Ｅi）は、ベイズ法により次式（１）で表される。
【００３１】
【数１】
0006741353.tif 000002
【００３２】
式（１）において、Ｐ（Ｍj）は事象Ｍjが発生する事前確率、Ｐ（Ｅi｜Ｍj）はエラーＥiが検出された場合に事象Ｍjが発生する確率、つまり尤度値である。また、Ｐ（Ｅi）は、次式（２）で表される。
【００３３】
【数２】
0006741353.tif 000003
【００３４】
これは、すべてのエラーの原因となる事象について共通である。この発明の実施の形態１では、エラーの原因となる事象の事後確率を比較評価することが目的であるため、事後確率Ｐ（Ｍj｜Ｅi）を次式（３）で表す。
【００３５】
【数３】
0006741353.tif 000004
【００３６】
ここで、事前確率Ｐ（Ｍj）は、すべての事象の発生回数に対する、当該事象が発生する回数の割合である。また、事前確率の算出方法は、例えば、ハードウェアベンダ等から提供される故障率を各事象の発生率とし、各事象の発生率の総和に対する、当該事象の発生率の割合として求めてもよい。また、別の例として、過去の同一製品、同一部品の故障回数データに基づき、すべての事象の発生回数の合計に対する、当該事象の発生回数として求めてもよい。
【００３７】
また、尤度値Ｐ（Ｅi｜Ｍj）は、理論的に求めてもよいし、事前の観察データに基づいて求めてもよい。理論的に求める方法について、例えば、メモリのソフトエラーに対応する通信ＣＲＣエラーの尤度値Ｐ（Ｅi｜Ｍj）は、メモリの容量に対する通信バッファサイズで算出する方法が考えられる。
【００３８】
また、事前の観察データに基づいて求める方法について、例えば、ビット反転を模擬して故障を注入し、システムを稼働させてエラーが検出される確率を求める方法が考えられる。以上が事象の事後確率の求め方であり、事後故障確率テーブル３２１には、式（３）で求めた各事象の事後確率を保存しておく。
【００３９】
図６は、この発明の実施の形態１に係る制御装置の診断時間テーブルを示す説明図である。図６において、診断時間テーブル３２２は、エラーの原因となる事象と、各事象がエラーの原因であると特定するための診断時間とをフィールドにもつ。
【００４０】
診断時間の求め方について、例えばＲＡＭのソフトエラーであれば、エラーが発生したアドレスのビットに特定の値を書き込み、再度値を読み出して、書き込んだ値と同一の値が読めるかどうかで診断する方法が考えられる。ここで、診断時間には、診断の結果当該事象がエラーの原因であると特定できた場合に、その後の動作モードに遷移するまでに要する時間を含めてもよい。
【００４１】
例えば、ＣＡＮ  ハードウェアモジュール故障が発生した場合に、予備のＣＡＮ  ハードウェアモジュールで制御処理を行う動作モードに遷移するシステムとしたとき、必要なハードウェアの初期化、他の装置への通知等を実施し、予備ＣＡＮ  ハードウェアモジュール制御処理プログラムが保存されたアドレスへジャンプするまでの時間が、その後の動作モードに遷移するまでに要する時間にあたる。
【００４２】
図７は、この発明の実施の形態１に係る制御装置の動作モード判定テーブルを示す説明図である。図７において、動作モード判定テーブル３２３は、動作モードと、動作モードに対応した事象とをフィールドに持つ。この発明の実施の形態１では、エラーの原因となる事象が特定された後、その事象に対応した動作モードに遷移する。
【００４３】
ただし、システムが許容できる機能停止時間である機能停止許容時間内にすべての事象を診断することができない可能性があるため、エラーの原因となる事象が特定できない場合がある。そこで、動作モード判定テーブル３２３には、その場合に備えて、エラーの原因となる事象が特定できなかったときの動作モードとして、あらかじめ定義した安全状態への移行を持たせておく。
【００４４】
図７では、冗長系を組んでおき、エラーの原因となる事象が特定できなかった場合、待機系に移行することを例示している。この例は、故障時も必ず動作の継続が求められる自動運転システム用コントローラを想定しており、エラーの原因となる事象が特定できなかった場合には、待機系に移行してしばらく制御装置１の動作を継続し、その間にドライバに運転動作権限を委譲するためのオーバーライド要求を出す、という動作モードを登録している。
【００４５】
この場合、待機系は十分に高信頼で、かつ他のどの事象、すなわち故障が発生しても、その影響を受けない、つまり従属故障が起きないよう設計されるべきである。ただし、重大な故障の発生時に動作停止が許容される場合には、エラーの原因となる事象が特定できなかったときに動作を停止するとする、緊急停止モードを動作モード判定テーブルに定義してもよい。
【００４６】
図８は、この発明の実施の形態１に係る制御装置の演算部における処理を示すフローチャートである。図８の処理は、演算部１１によって周期的に起動されることを想定しているが、イベントをきっかけとして動作が開始されてもよい。
【００４７】
図８において、演算部１１が起動されると、まず、演算部１１は、故障診断部１２から動作モードの遷移通知があるか否かを判定する（ステップＳ１０１）。
【００４８】
ステップＳ１０１において、遷移通知がない（すなわち、Ｎｏ）と判定された場合には、演算部１１は、前回起動時と同一の動作モードで演算処理を行い（ステップＳ１０２）、図８の処理を終了する。
【００４９】
一方、ステップＳ１０１において、遷移通知がある（すなわち、Ｙｅｓ）と判定された場合には、演算部１１は、指定された動作モードにモード遷移し（ステップＳ１０３）、遷移した動作モードで演算処理を行い（ステップＳ１０４）、図８の処理を終了する。
【００５０】
図９は、この発明の実施の形態１に係る制御装置の故障診断部における処理を示すフローチャートである。図９の処理は、エラー検出部１３がエラーを検出した際に故障診断部１２で起動される。
【００５１】
図９において、故障診断部１２が起動されると、まず、故障診断部１２は、診断可能時間を算出する（ステップＳ２０１）。ここで、診断可能時間は、Ｓ２０１の時点の時刻から、システムが危険状態に陥るまでの時間である。なお、診断可能時間は、システムの仕様により様々である。
【００５２】
例えば、主機能たる演算部１１の制御処理が周期処理であった場合、現在時刻から、次のデッドラインまでの時間を診断可能時間としてもよい。この場合の診断可能時間を図１０に例示する。
【００５３】
図１０において、演算部１１は、正常動作時には、周期的に起動されて制御値を出力する。また、演算部１１は、エラー検出時、後述するように故障診断部１２により決定された次の動作モードにより制御値を出力する。
【００５４】
このとき、現在時刻ｔ１、次のデッドラインの時刻をｔ２、次の動作モードによる１周期あたりの処理時間をΔｔとすると、診断可能時間は、次式で表される。
【００５５】
【数４】
0006741353.tif 000005
【００５６】
この場合、各動作モードの１周期あたりの処理時間Δｔをあらかじめ定義しておく必要があり、例えば、動作モード判定テーブル３２３のフィールドとして追加しておく。ただし、診断可能時間は、必ずしも制御周期に等しい必要はない。
【００５７】
すなわち、演算部１１の周期抜け、つまり出力なしが起きた際は、前回値を採用する等により、数回の演算部１１の周期抜けを許容可能なシステムにおいては、許容される周期抜け回数を考慮して診断可能時間を設定する。また、冗長系を組み、１つの系でエラーが検出された際に、他の系で一定時間動作可能なシステムにおいては、診断可能時間は、制御周期とは無関係にシステムの仕様から設定される。
【００５８】
図９に戻って、故障診断部１２は、事後故障確率テーブル３２１に保存されている各事象の事後確率、ステップＳ２０１で求めた診断可能時間および診断時間テーブル３２２に保存されている各事象の診断時間に基づいて、診断対象とする事象のセットを決定する（ステップＳ２０２）。
【００５９】
具体的には、故障診断部１２は、診断時間の合計が診断可能時間に収まる事象の組み合わせのうち、事象の事後確率の総和が最も高い組み合わせを、診断対象とする事象のセットに決定する。
【００６０】
続いて、故障診断部１２は、診断対象とする事象のセットを決定した後、そのセットの中で事象の事後確率が高い順に診断を行う（ステップＳ２０３、Ｓ２０４、Ｓ２０５）。
【００６１】
すなわち、故障診断部１２は、まず、すべての事象を診断したか否かを判定する（ステップＳ２０３）。
【００６２】
ステップＳ２０３において、すべての事象を診断していない（すなわち、Ｎｏ）と判定された場合には、故障診断部１２は、未診断の事象のうち、事後確率が最も高いものを診断し（ステップＳ２０４）、原因となる事象を特定したか否かを判定する（ステップＳ２０５）。
【００６３】
ステップＳ２０５において、原因となる事象を特定していない（すなわち、Ｎｏ）と判定された場合には、ステップＳ２０３に移行して、故障診断部１２は、再びすべての事象を診断したか否かを判定する
【００６４】
一方、ステップＳ２０３において、すべての事象を診断した（すなわち、Ｙｅｓ）と判定された場合、またはステップＳ２０５において、原因となる事象を特定した（すなわち、Ｙｅｓ）と判定された場合には、故障診断部１２は、動作モード判定テーブル３２３を参照し、次の動作モードを決定する（ステップＳ２０６）。
【００６５】
すなわち、故障診断部１２は、すべての事象を診断した結果、エラーの原因となる事象が特定できなかった場合には、動作モード判定テーブル３２３に従い、事象を特定できなかったときの動作モードを選択する。
【００６６】
次に、故障診断部１２は、演算部１１に対して、選択した動作モードに移行することを通知し（ステップＳ２０７）、図９の処理を終了する。
【００６７】
これらの処理をまとめると、エラー検出時に検出されたエラーを受け取り、原因となる事象毎の事後確率を求めたうえで、システムが許容できる機能停止時間である機能停止許容時間を求める。一方、あらかじめ各事象に対する診断時間を求めておく。
【００６８】
その後、診断時間に基づき、事象の診断に要する時間が機能停止許容時間内に収まる事象のセットのうち、事後確率の総和が最も高いセットを選択する。また、選択したセットの中から、事後確率が高い順に故障診断を行う。
【００６９】
このように、診断可能時間内に診断可能な事象の組み合わせのうち、事後確率の総和が最大になるものを診断対象とする事象のセットとし、事象のセットの中で事後確率が高い順に診断することで、診断可能時間内にエラーの原因となる事象の診断が可能になる。
【００７０】
これにより、エラー発生時に可能な限りシステムの動作を停止させることなく、エラーの原因となる事象を特定し、その事象に応じた動作モードを選択することができ、システムの動作を継続することができる。
【００７１】
ここで、故障時も動作継続する方法として、多重化によるアプローチがある。大規模プラント管理システム等では、例えば同一の演算を行う３重系システムの多数決により故障系を判断し、正常な系のみで動作継続する方式等がある。
【００７２】
一方、自動運転システム用コントローラやＦＡ（Ｆａｃｔｏｒｙ  Ａｕｔｏｍａｔｉｏｎ）用コントローラ等の制御装置においては、コストやスペースの制約が厳しく、必ずしも多重系の構成を実現できるとは限らない。
【００７３】
この発明の実施の形態１に係る制御装置１は、エラーの原因となる事象を特定し、その事象に応じた動作モードを選択することにより、可能な限り単一系で動作を継続することができる。そのため、コストやスペースの制約が厳しい制御装置において特に有効な手段である。
【００７４】
また、診断対象とする事象を次の動作モードの選択に影響を与える事象のみとすることにより、診断可能時間内に診断できる事象が増え、結果として動作継続可能性が増加するという効果も有する。
【００７５】
なお、サーバ系システムや情報系システムに比べ、自動運転システム用コントローラやＦＡ用コントローラ等の制御系システムは、時間的制約が厳しく、診断可能時間も短いと考えられる。よって、時間的制約が厳しいシステムにおいては、この発明の実施の形態１に係る制御装置１の、診断可能時間内に診断できる事象が増えるという効果は特に有効である。
【００７６】
以上のように、実施の形態１によれば、故障診断部は、エラーの原因となる事象の特定に費やすことができる診断可能時間を算出するとともに、エラー検出部で検出される各エラーについて、当該エラーの原因となる各事象が発生する確率である事後確率と、各事象がエラーの原因であると特定するために要する診断時間と、診断可能時間とに基づいて、エラーの原因となる事象を特定する。
そのため、エラー検出時も適用されるシステムの動作を可能な限り停止させることなく、機能縮退等により動作の継続を可能にするとともに、エラーの原因となる事象を特定することができる。
【００７７】
実施の形態２．
上記実施の形態１では、各事象に関する各エラーの事後確率が、システム動作前にあらかじめ求められていた。ただし、複数のエラーが同時に検出し得る場合を想定し、故障診断部１２が、エラー検出時に事後確率を求める構成としてもよい。
【００７８】
図１１は、この発明の実施の形態２に係る制御装置の故障診断マイコンにおけるＲＯＭに保存されたテーブルを示す説明図である。図１１において、ＲＯＭ３２Ａの構成は、上記実施の形態１で示した図４におけるＲＯＭ３２の構成と、以下の点で異なる。
【００７９】
すなわち、図１１において、この発明の実施の形態２に係るＲＯＭ３２Ａには、図４に示した実施の形態１に係るＲＯＭ３２の事後故障確率テーブル３２１に代えて、事前故障確率テーブル３２４および尤度値テーブル３２５が設けられている。また、図１１に示された他の構成要素については、上記実施の形態１と同一なので、説明を省略する。
【００８０】
図１２は、この発明の実施の形態２に係る制御装置の事前故障確率テーブルを示す説明図である。図１２において、事前故障確率テーブル３２４は、エラーの原因となり得る事象と、各事象が発生する確率である事前確率とをフィールドにもつ。なお、各事象の事前確率の求め方は、上記実施の形態１の方法と同様である。
【００８１】
図１３は、この発明の実施の形態２に係る制御装置の尤度値テーブルを示す説明図である。図１３において、尤度値テーブル３２５は、検出されるエラーと、エラーの原因となる事象とを示すマトリクス表である。なお、各尤度値の求め方は、上記実施の形態１の方法と同様である。
【００８２】
図１４は、この発明の実施の形態２に係る制御装置の故障診断部における処理を示すフローチャートである。図１４において、故障診断部１２の処理は、上記実施の形態１で示した図９における処理と、以下の点で異なる。
【００８３】
すなわち、図１４において、故障診断部１２が起動されると、まず、故障診断部１２は、事象毎の事後確率を算出する（ステップＳ３０１）。
【００８４】
この発明の実施の形態２では、上述したように、複数のエラーが同時に検出し得る場合を想定している。ここで、検出されたすべてのエラーの集合をＥとすると、単一のエラーＥiが検出された場合の原因となる事象Ｍjの事後確率Ｐ（Ｍj｜Ｅi）は、ベイズ法により次式（４）で表すことができる。
【００８５】
【数５】
0006741353.tif 000006
【００８６】
上記実施の形態１の式（１）におけるベイズ法の分母の項は、実施の形態１で述べた理由と同様の理由により省略することができる。また、式（４）から、エラーＥが検出された場合の原因となる事象Ｍjの事後確率Ｐ（Ｍj｜Ｅ）は、次式（５）で表される。
【００８７】
【数６】
0006741353.tif 000007
【００８８】
なお、図１４において、ステップＳ３０１以外の処理については、上記実施の形態１で示した処理と同一なので、説明を省略する。
【００８９】
以上のように、実施の形態２によれば、エラーの原因となる事象の事後確率をエラー検出後に算出することにより、エラーが複数同時に検出された場合も、すべてのエラーが検出されたことを条件とする事象の事後確率を求めることが可能になる。
【００９０】
実施の形態３．
上記実施の形態１では、図９に示したように、ステップＳ２０２において、故障診断部１２が、診断対象とする事象のセットを決定した。ここで、診断対象とする事象のセットを決定する処理に時間がかかる場合には、このステップを行わず、故障診断部１２が、事象に対する診断毎に、次の診断を行ったときに診断可能時間を超過するか否かを判定してもよい。
【００９１】
図１５は、この発明の実施の形態３に係る制御装置の故障診断部における処理を示すフローチャートである。図１５において、故障診断部１２の処理は、上記実施の形態１で示した図９における処理と、以下の点で異なる。
【００９２】
すなわち、図１５において、故障診断部１２は、診断可能時間を算出した後（ステップＳ２０１）、診断対象とする事象のセットは決定せず（図９のステップＳ２０２）、事象の事後確率が高い順に診断を行う（ステップＳ２０３、Ｓ２０４、Ｓ２０５）。
【００９３】
ただし、故障診断部１２は、各事象の診断を開始する前に、次の事象に対する診断を行うと診断可能時間を超過するか否かを判定する（ステップＳ４０１）。
【００９４】
ステップＳ４０１において、次の事象に対する診断を行うと診断可能時間を超過する（すなわち、Ｙｅｓ）と判定された場合には、故障診断部１２は、事象を特定できなかったときの動作モードを選択する（ステップＳ２０６）。
【００９５】
なお、図１５において、その他の処理については、上記実施の形態１で示した処理と同一なので、説明を省略する。
【００９６】
以上のように、実施の形態３によれば、事象に対する診断毎に、次の診断を行ったときに診断可能時間を超過するか否かを判定することにより、診断対象とする事象のセットを決定する処理を省略することができる。
【００９７】
実施の形態４．
上記実施の形態１では、図９に示したように、ステップＳ２０２において、故障診断部１２が、診断対象とする事象のセットを決定した。ここで、故障診断部１２は、診断時間の逆数の期待値の順に診断を行ってもよい。
【００９８】
図１６は、この発明の実施の形態４に係る制御装置の故障診断部における処理を示すフローチャートである。図１６において、故障診断部１２の処理は、他の実施の形態で示した処理と、以下の点で異なる。
【００９９】
すなわち、図１６において、故障診断部１２は、診断可能時間を算出した後（ステップＳ２０１）、エラーの原因となる各事象における、診断時間の逆数の期待値を算出する（ステップＳ５０１）。
【０１００】
ここで、診断時間の逆数の期待値は、診断時間テーブル３２２に保存されている各事象の診断時間の逆数と、事後故障確率テーブル３２１に保存されている各事象の事後確率との積である。また、診断時間の逆数の期待値は、あらかじめ算出しておき、ＲＯＭ３２に保存しておいてもよい。
【０１０１】
続いて、故障診断部１２は、各事象の診断を開始する前に、次の事象に対する診断を行うと診断可能時間を超過するか否かを判定し（ステップＳ４０１）、超過しない場合に、未診断の事象のうち、診断時間の逆数の期待値が最も高いものから順に診断する（ステップＳ５０２）。
【０１０２】
なお、図１６において、その他の処理については、上記実施の形態１〜３で示した処理と同一なので、説明を省略する。
【０１０３】
以上のように、実施の形態４によれば、診断時間の逆数の期待値の順に診断を行うことで、診断に要する時間を短くすることを最優先にして診断することができる。
【０１０４】
すなわち、上記実施の形態１〜３では、診断可能時間内に事象が特定できる確率を最大にすることを主眼としている。これは、診断可能時間内であれば、診断に要する時間の大小は、システムの価値に影響を与えないというシステムに適している。
【０１０５】
一方、この発明の実施の形態４では、必ずしも診断可能時間内に事象が特定できる確率を最大にできるわけではないが、事象を特定するまでに要する時間の期待値を最小にすることができる。この発明の実施の形態４は、ソフトリアルタイムシステムのように、処理を完了するまでの時間とともに、システムの価値が徐々に低下していくシステムにおいて効果的である。
【０１０６】
実施の形態５．
上記実施の形態１では、図９に示したように、ステップＳ２０２において、故障診断部１２が、診断対象とする事象のセットを決定した。ここで、動作モードに機能レベルをつけ、故障診断部１２が、機能レベルの期待値の順に診断を行ってもよい。
【０１０７】
図１７は、この発明の実施の形態５に係る制御装置の動作モード判定テーブルを示す説明図である。図１７において、動作モード判定テーブル３２３Ａは、図７に示した実施の形態１に係る動作モード判定テーブル３２３に加えて、機能レベルフィールドを持つ。この例は、機能レベルの値が高い方が、より高機能であることを示している。
【０１０８】
図１８は、この発明の実施の形態５に係る制御装置の故障診断部における処理を示すフローチャートである。図１８において、故障診断部１２の処理は、他の実施の形態で示した処理と、以下の点で異なる。
【０１０９】
すなわち、図１８において、故障診断部１２は、診断可能時間を算出した後（ステップＳ２０１）、機能レベルの期待値を算出する（ステップＳ６０１）。
【０１１０】
ここで、機能レベルの期待値は、動作モード判定テーブル３２３Ａにおける機能レベルと、事後故障確率テーブル３２１に保存されている各事象の事後確率との積である。また、機能レベルの期待値は、あらかじめ算出しておき、ＲＯＭ３２に保存しておいてもよい。
【０１１１】
続いて、故障診断部１２は、各事象の診断を開始する前に、次の事象に対する診断を行うと診断可能時間を超過するか否か判定し（ステップＳ４０１）、超過しない場合に、未診断の事象のうち、機能レベルの期待値が最も高いものから順に診断する（ステップＳ６０２）。
【０１１２】
なお、図１８において、その他の処理については、上記実施の形態１〜３で示した処理と同一なので、説明を省略する。
【０１１３】
以上のように、実施の形態４によれば、機能レベルの期待値の順に診断を行うことにより、高機能な動作モードへ遷移する可能性を高めることができる。
【符号の説明】
【０１１４】
１  制御装置、１１  演算部、１２  故障診断部、１３  エラー検出部。
【図１】
0006741353.tif 000008
【図２】
0006741353.tif 000009
【図３】
0006741353.tif 000010
【図４】
0006741353.tif 000011
【図５】
0006741353.tif 000012
【図６】
0006741353.tif 000013
【図７】
0006741353.tif 000014
【図８】
0006741353.tif 000015
【図９】
0006741353.tif 000016
【図１０】
0006741353.tif 000017
【図１１】
0006741353.tif 000018
【図１２】
0006741353.tif 000019
【図１３】
0006741353.tif 000020
【図１４】
0006741353.tif 000021
【図１５】
0006741353.tif 000022
【図１６】
0006741353.tif 000023
【図１７】
0006741353.tif 000024
【図１８】
0006741353.tif 000025