JPWO2011141992A1 - 故障診断装置及び故障診断方法 - Google Patents

Abstract

本発明は、複数のＣＰＵの故障診断を行う故障診断装置であって、複数のＣＰＵの処理に関連する車両情報に基づいて、複数のＣＰＵの全体としての処理負荷を予測又は検出し、該処理負荷の予測結果又は検出結果に応じて、故障診断の実行態様を変更することを特徴とする。複数のＣＰＵは、マルチコアプロセッサにおける複数のＣＰＵであってよい。複数のＣＰＵの全体としての処理負荷が所定基準よりも低いことが予測又は検出された場合に、故障診断を行うものであってよい。

Description

本発明は、複数のＣＰＵの故障診断を行う故障診断装置及び故障診断方法に関する。

従来から、幾つかの作業単位用プロセッサ装置と、それらを総合的に制御する総合制御用プロセッサ装置とが共通バスを介して接続されるマルチプロセッサ装置において、作業単位用プロセッサ装置の故障を調べる診断試験プログラムを、作業単位用プロセッサ装置毎に搭載するマルチプロセッサ装置が知られている（例えば、特許文献１参照）。この構成では、異常を検知した作業単位用プロセッサ装置は、自己に搭載されている診断試験プログラムによって故障の調査を行い、総合制御用プロセッサ装置の手を借りて故障の調査を行わないので、故障の調査をする度に共通バスを占有して他の処理を中断させたり、総合制御用プロセッサ装置に処理負担をかけたりすることがなくなる。

特開平７−３２５７３０号公報

ところで、車載マイコン（ＥＣＵ）のＣＰＵは、通常処理（例えば車両制御用の処理）に加えて故障診断処理を実施するため、故障診断処理を行うことにより通常処理に影響が出る場合がある。

そこで、本発明は、ＣＰＵの通常処理への影響が少なくとも低減される態様で故障診断処理を行うことが可能な故障診断装置及び故障診断方法の提供を目的とする。

上記目的を達成するため、本発明の一局面によれば、複数のＣＰＵの故障診断を行う故障診断装置であって、
前記複数のＣＰＵの処理に関連する車両情報に基づいて、前記複数のＣＰＵの全体としての処理負荷を予測又は検出し、該処理負荷の予測結果又は検出結果に応じて、故障診断の実行態様を変更することを特徴とする、故障診断装置が提供される。

本発明によれば、ＣＰＵの通常処理への影響が少なくとも低減される態様で故障診断処理を行うことが可能な故障診断装置及び故障診断方法が得られる。

本発明の一実施例（実施例１）による故障診断装置１のハードウェア構成を示す図である。 マルチコアＣＰＵ１２を内蔵したＳｏＣをハードウェアとしたときのシステムレイヤを示す図である。 ＯＳ内の故障診断テスト制御の一例を示すフローチャートである。 図１に示したマルチコアＣＰＵ１２の詳細構成の一例を示す図である。 ＣＰＵコア１０１の故障診断を開始する直前のマルチプレクサ２０１，２０２，２０５の接続状態の概要を示す図である。 故障診断テスト用のデータと期待値の読み込み状態を示す図である。 ＣＰＵコア１０１からのテスト結果の出力状態を示す図である。 ＣＰＵコア１０１の故障診断完了後のマルチプレクサ２０１，２０２，２０５の接続状態の概要を示す図である。 故障診断テスト制御のその他の一例を示すフローチャートである。 アプリ層に故障診断テスト制御を組み込んだ場合の構成を示す図である。 三角波比較ＰＷＭの概要を示す図である。 キャリア周波数の変化（車両駆動用電動モータの回転速度の変化）に伴うＣＰＵコアに割当てられる時間の変化を概略的に示す図である。 車速の変化に伴う周辺監視システムにおける必要な探索範囲の変化を概略的に示す図である。 本発明のその他の一実施例（実施例２）による故障診断装置２のハードウェア構成を示す図である。 処理負荷に応じてＣＰＵコアの故障診断の実行部分を可変する故障診断テスト制御の一例を示す。 処理負荷に応じてタスク調整を行いＣＰＵコアの故障診断の実行可能な機会を増加させる故障診断テスト制御の一例を示す。 テストモードの間に処理負荷が高くなった場合に故障診断の中断を行う故障診断テスト制御の一例を示す。

以下、図面を参照して、本発明を実施するための最良の形態の説明を行う。

図１は、本発明の一実施例（実施例１）による故障診断装置１のハードウェア構成を示す図である。故障診断装置１は、ＬＳＩ(large-scale integration) １０により構成される。ＬＳＩ１０は、マルチコアＣＰＵ１２、データアクセスコントローラ１３、メモリコントローラ１４及びタイマ１８等を含む。

マルチコアＣＰＵ１２は、複数のＣＰＵコア（本例では、２つのＣＰＵコア１０１，１０２）と、ＣＰＵコア１０１，１０２間のデータ連携を行うデータ制御部２００を含む。

データアクセスコントローラ１３は、ＣＰＵコア１０１，１０２の故障診断時に必要なデータを格納している記憶媒体１５へのアクセスを制御する。記憶媒体１５は、例えばメモリやＨＤＤなどにより構成される。データアクセスコントローラ１３とマルチコアＣＰＵ１２との間は、データバス２０により接続されている。

メモリコントローラ１４は、通常動作に必要なプログラムやデータを格納している記憶媒体１６へのアクセスを制御する。記憶媒体１６は、例えばメモリやＨＤＤなどにより構成される。メモリコントローラ１４とマルチコアＣＰＵ１２との間は、データバス２２により接続されている。

図２は、マルチコアＣＰＵ１２を内蔵したＳｏＣ（System-on-a-chip）をハードウェアとしたときのシステムレイヤを示す図である。ＯＳは、動作させるアプリから今後必要とされるＣＰＵ負荷を推定したり、各ＣＰＵコア１０１，１０２の動作状態の管理やタスク割り当てを行う。

図３は、ＯＳ内の故障診断テスト制御の一例を示すフローチャートである。

ステップ３００では、ＣＰＵコア１０１，１０２の処理負荷に関連する車両情報が入力される。車両情報は、ＣＰＵコア１０１，１０２の処理負荷の予測（又は検出）に利用できる情報であれば任意である。車両情報の具体例について後述する。

ステップ３０１では、上記ステップ３００で入力された車両情報に基づいて、ＣＰＵコア１０１，１０２の処理負荷（マルチコアＣＰＵ１２の処理負荷）が予測される。例えば、現時点から所定期間Ｔ（以下、負荷予測期間Ｔという）内のＣＰＵコア１０１，１０２の処理負荷が予測されてもよい。負荷予測期間Ｔは、後述の故障診断に要する時間（即ちステップ３１０からステップ３２８までの処理に要しうる時間の最大値）に対応してよい。また、ＣＰＵコア１０１，１０２の処理負荷は、現時点から負荷予測期間Ｔ内のＣＰＵコア１０１，１０２の処理負荷の平均値や最大値として予測されてもよい。尚、ここで予測されるＣＰＵコア１０１，１０２の処理負荷は、ＣＰＵコア１０１，１０２が現時点から通常動作を行った場合を想定したときの処理負荷であり、ＣＰＵコア１０１又は１０２が後述の故障診断を行った場合を想定したときの処理負荷ではない。

ステップ３０２では、上記ステップ３０１で予測した処理負荷が所定レベルよりも高いか否かが判定される。所定レベルは、１つのＣＰＵコアで処理可能な処理負荷の最大レベルに対応してよい。この場合、所定レベルは、ＣＰＵコア１０１，１０２の個々の能力（性能）に応じて適合されてよい。尚、ＣＰＵコア１０１，１０２の性能は、一般的に、互いに同一である。上記ステップ３０１で予測した処理負荷が所定レベルよりも高い場合は、１つのＣＰＵコアで処理可能で無いと判断して、ステップ３０４に進み、上記ステップ３０１で予測した処理負荷が所定レベルよりも低い場合は、１つのＣＰＵコアで処理可能であると判断して、ステップ３１０に進む。

ステップ３０４では、ＣＰＵコア１０１，１０２を通常モードのまま動作させると共に、各ＣＰＵコア１０１，１０２への負荷分散を行う。即ち、各ＣＰＵコア１０１，１０２は、SMP（Symmetric Multi-processing）動作を行う。

ステップ３０６では、ＯＳによりスケジューリングされたタスクに基づいて、各ＣＰＵコア１０１，１０２がそれぞれのタスクを実行する。

ステップ３０８では、各ＣＰＵコア１０１，１０２の通常処理の実行時間（上記ステップ３０４から計時される実行時間）が負荷予測期間Ｔに達したか否かが判定される。各ＣＰＵコア１０１，１０２の通常処理の実行時間が負荷予測期間Ｔに達していない場合は、ステップ３０６に戻り、各ＣＰＵコア１０１，１０２の通常処理の実行時間が負荷予測期間Ｔに達した場合は、ステップ３００に戻る。

ステップ３１０では、故障診断対象のＣＰＵ番号が呼び出される。故障診断対象のＣＰＵ番号は、ＣＰＵコア１０１，１０２のいずれかを表す番号であり、所定の順序で交互に呼び出される。

ステップ３１２では、故障診断対象のＣＰＵコア（ＣＰＵコア１０１又は１０２）に、処理が完了していないタスク（処理途中のタスク）が存在するか否かが判定される。処理が完了していないタスクがある場合は、ステップ３１４に進み、処理が完了していないタスクが無い場合は、ステップ３１８に進む。

ステップ３１４では、処理が完了しないタスクが完了することを待機する。

ステップ３１６では、上記ステップ３１２と同様に、故障診断対象のＣＰＵコア（ＣＰＵコア１０１又は１０２）に、処理が完了していないタスクが存在するか否かが判定される。処理が完了していないタスクがある場合は、ステップ３１４に戻り、処理が完了していないタスクが無い場合は、ステップ３１８に進む。

ステップ３１８では、故障診断対象のＣＰＵコア（ＣＰＵコア１０１又は１０２）のモードを、通常モードからテストモードへ変更する。このようにして、各ＣＰＵコア１０１，１０２の動作は、SMPからAMP（Asymmetric Multiprocessing）に変更される。即ち、故障診断対象のＣＰＵコア１０１又は１０２は、テストモードで動作し、他方のＣＰＵコア（故障診断対象でないＣＰＵコア１０２又は１０１）は、ＯＳによりスケジューリングされたタスクを実行する。

ステップ３２０では、故障診断対象のＣＰＵコア（ＣＰＵコア１０１又は１０２）のテストモードが開始され、故障診断処理が開始される。具体的には、データアクセスコントローラ１３（図１参照）を通して、故障診断テスト用のデータとそれに対応する期待値の記憶媒体１５からの読み出しを開始する。そして、期待値とテスト結果とを照合した結果を記録媒体に書き込む。

このテストモードの間、ＯＳは、全てのタスクを他方のＣＰＵコア（故障診断対象でないＣＰＵコア１０２又は１０１）に割当てる。かかる場合でも、上記のステップ３０１，３０２での予測・判定が適切である限り、全てのタスクは上述の如く１つのＣＰＵでの処理可能なレベルの処理負荷であるので、全てのタスクを他方のＣＰＵコア単独で実行可能である。従って、この際に他方のＣＰＵコアに割当てられるタスクには、SMP動作時であれば（即ちテストモードに移行していなければ）故障診断対象のＣＰＵコアに割当てられていただろうタスクを含みうる。

本ステップ３２０における故障診断処理の内容は、自身の故障診断を適切に行うことができる処理である限りに任意である。例えば、自身のＣＰＵコアのＡＬＵの演算テスト等であってよい。故障診断処理の好ましい一例については後述する。

ステップ３２２では、故障診断処理が完了したか否かが判定される。故障診断処理が完了したと判定された場合には、ステップ３２６に進み、故障診断処理が完了していないと判定された場合は、ステップ３２４に進む。

ステップ３２４では、故障診断処理が継続される。故障診断テストを継続するために次の故障診断テスト用のデータとそれに対応する期待値をデータアクセスコントローラ１３を通して読み出す。そして、期待値とテスト結果とを照合した結果を記録媒体に書き込む。ステップ３２４の処理は、故障診断処理が完了するまで（全ての故障診断テスト用のデータのテストが終了するまで）継続される。

ステップ３２６では、故障診断対象のＣＰＵコアのモードをテストモードから通常モードに変更する。即ち、故障診断対象のＣＰＵコアを通常モードに復帰させる。

ステップ３２８では、マルチコアＣＰＵ１２内のデータ制御部２００が管理する次回の故障診断対象のＣＰＵ番号を更新する。

図４は、図１に示したマルチコアＣＰＵ１２の詳細構成の一例を示す図である。

マルチコアＣＰＵ１２のデータ制御部２００は、図４に示すように、マルチプレクサ（ＭＵＸ）２０１，２０２，２０５と、モード制御部２０３と、ＣＰＵ番号レジスタ２０４と、故障診断ブロック２１０とを含む。

マルチプレクサ２０１は、ＣＰＵコア１０１の入力／出力データの読み出し／書き込みを、データアクセスコントローラ１３（故障診断に必要なデータを格納した記憶媒体１５にアクセスするためのデータアクセスコントローラ１３）と行うか、若しくは、メモリコントローラ１４（通常動作に必要なデータを格納した記憶媒体１６にアクセスするためのメモリコントローラ１４）と行うかを制御する。

マルチプレクサ２０２は、マルチプレクサ２０１と同様に、ＣＰＵコア１０２の入力／出力データの読み出し／書き込みを、データアクセスコントローラ１３と行うか、若しくは、メモリコントローラ１４と行うかを制御する。

モード制御部２０３は、各ＣＰＵコア１０１，１０２のモード（通常モード若しくは故障診断用のテストモード）を切り換える。

ＣＰＵ番号レジスタ２０４は、次の故障診断対象のＣＰＵコア（ＣＰＵコア１０１又は１０２）の番号（図３のステップ３１０，３２８参照）を格納するレジスタである。

マルチプレクサ２０５は、故障診断対象のＣＰＵコア（ＣＰＵコア１０１又は１０２）の出力データを選択する。

故障診断ブロック２１０は、故障診断対象のＣＰＵコア（ＣＰＵコア１０１又は１０２）の出力結果（処理結果）とテスト結果の期待値とを比較する機能を有する。故障診断ブロック２１０は、故障診断対象のＣＰＵコア（ＣＰＵコア１０１又は１０２）の出力結果を記憶する記憶部２１２と、テスト結果の期待値を記憶する記憶部２１４と、これらを比較する比較器２１６とを含む。

ここで、図３、図５乃至図８を参照して、ＣＰＵコア１０１が通常動作モードからテストモードに遷移し、ＣＰＵコア１０１のテストモード（故障診断処理）が完了するまでの動作を説明する。

尚、前提条件として、データ制御部２００のＣＰＵ番号レジスタ２０４には、値「０」が格納されているものとする。値「０」は、ＣＰＵコア１０１の番号に対応し、値「１」は、ＣＰＵコア１０２に対応するものとする。

先ず、車両情報を入力する（図３のステップ３００参照）。次いで、入力された車両情報からＣＰＵコア１０１，１０２の処理負荷（全体としての処理負荷）の推定（予測）を行う（図３のステップ３０１参照）。推定された処理負荷が１つのＣＰＵコアで処理できないレベルである場合は（図３のステップ３０２のＹＥＳ参照）、図３のステップ３０４乃至３０８が実行され、故障診断のテストは実行されない。

次の車両情報更新タイミングで、入力された車両情報からＣＰＵコア１０１，１０２の処理負荷の推定を行う（図３のステップ３０１参照）。推定された処理負荷が１つのＣＰＵコアで処理できるレベルである場合は（図３のステップ３０２のＮＯ参照）、故障診断用のテストモードに移行する準備として、データ制御部２００から故障診断対象のＣＰＵコアの番号を読み出す。このとき、ＣＰＵ番号レジスタ２０４には値「０」が格納されているので、ＣＰＵコア１０１が故障診断対象のＣＰＵコアとなる。

ＣＰＵコア１０１が故障診断対象のＣＰＵコアとして決定されたときに、ＣＰＵコア１０１が通常処理の実行途中である場合、モードを移行して故障診断処理を開始することはできない（故障診断処理を開始すると、通常動作の処理結果が異常となる）。このため、ＣＰＵコア１０１が実行途中のタスクの処理を完了するまで待機される（図３のステップ３１２乃至ステップ３１６参照）。

ＣＰＵコア１０１で処理されているタスクが無くなると（ＣＰＵコア１０１が実行途中のタスクの処理を完了すると）、ＣＰＵコア１０１のモードが、データ制御部２００内のモード制御部２０３により変更される（図３のステップ３１８参照）。即ち、ＣＰＵコア１０１のモードが、通常モードからテストモードに変更される。これと同時に、モード制御部２０３は、マルチプレクサ２０１，２０２，２０５に接続するバスをテスト系のバスとする。この状態での各マルチプレクサ２０１，２０２，２０５の内部接続イメージと各ＣＰＵコア１０１，１０２へのモード設定信号は、図５のように示される。

ＣＰＵコア１０１のモードをテストモードに変更して、テスト系のバスに接続すると、テスト用の記憶媒体１５からＣＰＵコア１０１へ故障診断テスト用のデータが入力されると共に、テスト用の記憶媒体１５から故障診断ブロック２１０の記憶部２１４に、対応する期待値が入力される。この状態が図６に示される。

ＣＰＵコア１０１は、故障診断テスト用のデータが入力されると随時それぞれのデータを処理して、結果を出力する。出力結果は、データ制御部２００内の故障診断ブロック２１０の記憶部２１２に格納される。この状態が図７に示される。

データ制御部２００は、ＣＰＵコア１０１の出力結果と記憶部２１４内の期待値との比較を随時行う（図３のステップ３２０乃至ステップ３２４参照）。

全ての故障診断テスト用のデータを用いた故障診断処理が完了し、各出力結果と各期待値との比較がエラー無く完了すると、ＣＰＵコア１０１のモードがテストモードから通常モードに変更される（図３のステップ３２６参照）。これと同時に、ＣＰＵ番号レジスタ２０４の値が「１」に変更される（図３のステップ３２８参照）。この状態が図８に示される。尚、故障診断の結果、故障が検出された場合（各出力結果と各期待値との不一致がある場合）は、外部に故障を知らせる信号を出力することとしてもよい。この信号が出力されると、ユーザ（運転者）にＥＣＵの故障のためにＥＣＵを交換又は検査するように促すメッセージが、ユーザ（運転者）に対して音声及び／又は表示により出力されてもよい。

尚、その後、ＣＰＵコア１０１，１０２の処理負荷の予測を行い、故障診断処理に必要な時間（負荷予測期間Ｔ）に１つのＣＰＵコアによる処理が可能なレベルの処理負荷が予測された場合には、同様に、ＣＰＵコア１０２の故障診断が実行される。

以上説明した本実施例の故障診断装置１によれば、とりわけ、以下のような優れた効果が奏される。

上述の如く、故障診断処理がＣＰＵコア１０１，１０２の全体としての処理負荷が低い場合に実行されるので、ＣＰＵコア１０１，１０２の通常処理に影響しない態様で、ＣＰＵコア１０１，１０２の故障診断を行うことができる。即ち、ＣＰＵコア１０１，１０２の処理負荷を車両情報から予測して、マルチコアＣＰＵ１２の動作モードをＳＭＰ動作からＡＭＰ動作に動的に切換ながら故障診断を行うことによって、マルチコアＣＰＵ１２の通常動作の性能に影響が出ない態様で、ＣＰＵコア１０１，１０２の故障診断を実現することができる。また、ＣＰＵコア１０１，１０２のそれぞれの故障診断が実行され、いずれかのＣＰＵコア１０１，１０２に故障が生じた場合には、当該故障を検出することができると共に、どのＣＰＵコア１０１，１０２に故障が生じているかを特定することができる。

尚、上述した実施例では、故障診断を行う毎に、記憶媒体１５から故障診断テスト用のデータ及び期待値をデータ制御部２００に読み込む構成であった。しかしながら、常に同じのテストパターンによりＣＰＵコア１０１，１０２の故障診断を行う構成であれば、期待値は一定である。従って、かかる構成であれば、データ制御部２００に内蔵のＲＯＭ若しくはＲＡＭなどの記憶領域を用意しておき、期待値を予め格納しておいてもよい。かかる構成によれば、データアクセスコントローラ１３を通したデータアクセスが不要となり、故障診断を行う際にバス能力の低下のリスクを避けることができる。

また、上述した実施例では、車両情報更新周期毎（例えば１秒毎）に図３の処理が実行されているが、実行周期は、故障診断の内容等に依存して、任意であってよい。例えば経年劣化に起因した故障発生のチェックは、間隔が短くても１日周期で実行すれば十分である。従って、前回の故障診断を行った時間を記憶しておき、一定時間以上故障診断が行われなかった場合のみ図３の処理が実行されるようにしてもよい。具体的には、図９に示すように、図３の故障診断テスト制御にステップ９００及び９０２の処理を追加してもよい。即ち、各ＣＰＵコア１０１，１０２の最終（前回）の故障診断時間と現在の時間を比較して一定時間以上（例えば一日以上）故障診断が行われなかった場合のみ図３の処理（ステップ３００からの処理）が実行される。尚、図９に示す故障診断テスト制御は、ＣＰＵコア１０１，１０２が車両の走行性能に関連しないシステム（即ち、ユーザの利便性や快適性を高めるためのシステムであり、例えば、ナビゲーションシステム）のＥＣＵを構成する場合に好適である。

また、上述した実施例では、故障診断テストの制御（図３参照）をＯＳにより実現しているが、アプリやミドル層で制御しても同様の効果を得ることが可能である。この場合、各アプリや故障診断テストの制御を処理するＣＰＵコアを事前に割り振っておく。例えば、図１０に示す例では、故障診断テスト制御をＣＰＵコア１０１に割当てた例が示される。尚、この場合は、ＣＰＵコア１０１，１０２は、ＡＭＰモードで動作する。

次に、車両情報からＣＰＵコア１０１，１０２の処理負荷を予測する方法の具体例について幾つか説明する。

第１の具体例は、車両情報として、車両駆動用電動モータの制御に用いるＰＷＭ信号のキャリア周波数を用いて、ＣＰＵコア１０１，１０２の処理負荷を予測する方法に関する。ここでは、ＣＰＵコア１０１，１０２は、車両駆動用電動モータの制御を実行する。即ち、ＣＰＵコア１０１，１０２は、ハイブリッドシステムのＥＣＵを構成する。

ハイブリッド車（及び電気自動車）では、車両駆動用電動モータを駆動して車両走行が制御される。この車両駆動用電動モータの制御には、一般的に、図１１に示すような三角波比較ＰＷＭが使用される。インバータの制御を滑らかに行うために同期ＰＷＭ制御（キャリア位相同期）が用いられる。この同期ＰＷＭ制御では、車両駆動用電動モータの回転速度に応じてキャリア周波数が変化する。即ち、同期ＰＷＭ制御では、車両駆動用電動モータの回転速度が速くなるにつれて、キャリア周波数が高くなる。キャリア周波数が高くなると、ＣＰＵコア１０１，１０２に要求される処理能力が高くなる。即ち、図１２に示すように、キャリア周波数が高くなると、サイン波の周期が短くなり、一定処理を行うためにＣＰＵコア１０１，１０２に割当てられた時間が短くなるので、ＣＰＵコア１０１，１０２の処理負荷が高くなる。このことから、同期ＰＷＭ制御にて車両駆動用電動モータの制御を行うシステムでは、キャリア周波数（及びキャリア周波数を制御するカウンタ）を車両情報として用いてＣＰＵコア１０１，１０２の処理負荷を予測することができる。この目的のため、第１の具体例では、タイマ１８（図４参照）としてキャリア周波数用タイマが使用される。また、図３に示すフローチャートでは、車両情報としてキャリア周波数制御カウンタが入力され（ステップ３００）、キャリア周波数からＣＰＵコア１０１，１０２の処理負荷が予測され（ステップ３０１）、予測した処理負荷が所定レベルよりも高いか否かが判定される（ステップ３０２）。尚、図３のステップ３０１及び３０２の処理として、キャリア周波数が所定閾値（所定周波数）よりも高いか否かが判定されてもよい。この場合も同様の考え方に基づいて、所定閾値は、１つのＣＰＵコアで処理可能な処理負荷の最大レベルに適合されてよい。例えば、ＣＰＵコア１０１，１０２の動作周波数を６４ＭＨｚとしたとき、ＰＷＭ信号のキャリア周波数が５ｋＨ未満の場合は、１つのＣＰＵコアで処理可能な処理負荷であると判定して、故障診断を行うこととし、ＰＷＭ信号のキャリア周波数が５ｋＨ以上の場合は、１つのＣＰＵコアで処理不能な処理負荷であると判定して、故障診断を行わないようにしてよい。

尚、この第１の具体例において、ＰＷＭ信号のキャリア周波数は、車両駆動用電動モータの他の制御情報（例えば、車両駆動用電動モータの回転数、トルク、回転方向等）に基づいて算出・推定されてもよい。

第２の具体例は、車両情報として、ナビゲーション（マルチメディア）システムにおけるユーザの操作情報（又はユーザの操作に基づく当該システムの制御状態の情報）を用いて、ＣＰＵコア１０１，１０２の処理負荷を予測する方法に関する。ここでは、ＣＰＵコア１０１，１０２は、ナビゲーションシステムの制御を実行する。即ち、ＣＰＵコア１０１，１０２は、ナビゲーションシステムのＥＣＵを構成する。

ナビゲーションシステムでは、ユーザによる操作（例えばタッチパネルに対する画面操作）により同時に動作させるアプリが分かるため、これに基づいてＣＰＵコア１０１，１０２の処理負荷を予測することができる。例えば、ナビゲーションシステムにおいて画面操作により同時動作が可能な複数のアプリとして、ナビゲーションのルーティング機能、ＣＤのリッピング、ＤＴＶ（デジタルテレビ）の受信と音声出力等がある。ここで、同時に動作するアプリの数が多くなるにつれて、ＣＰＵコア１０１，１０２の処理負荷が高くなる。このことから、ユーザによる操作により複数のアプリの同時動作が可能なナビゲーションシステムでは、ユーザによる操作情報（及びそれに基づいて同時動作するアプリ数）を車両情報として用いてＣＰＵコア１０１，１０２の処理負荷を予測することができる。この目的のため、第２の具体例では、マルチコアＣＰＵ１２には、ナビゲーションの操作情報が入力される。また、図３に示すフローチャートでは、車両情報として操作情報が入力され（ステップ３００）、操作情報からＣＰＵコア１０１，１０２の処理負荷として、同時動作するアプリ数が予測され（ステップ３０１）、予測した処理負荷が所定レベル（所定アプリ数）よりも高いか否かが判定される（ステップ３０２）。この場合も同様の考え方に基づいて、所定アプリ数は、１つのＣＰＵコアで処理可能な処理負荷の最大レベル（最大アプリ数）に適合されてよい。例えば、ＣＰＵコア１０１，１０２の動作周波数を４００ＭＨｚとしたとき、所定アプリ数は、２個であってよい。この場合、ユーザによる操作により例えばルーティングのみを処理する場合は、１つのＣＰＵコアで処理可能な処理負荷であると判定して、故障診断を行い、ユーザによる操作により例えばルーティングとリッピングを同時動作させる場合は、１つのＣＰＵコアで処理不能な処理負荷であると判定して、故障診断を行わない。

第３の具体例は、車両情報として車速を用いて、ＣＰＵコア１０１，１０２の処理負荷を予測する方法に関する。ここでは、ＣＰＵコア１０１，１０２は、車載周辺監視カメラを用いた周辺監視システムの制御を実行する。即ち、ＣＰＵコア１０１，１０２は、周辺監視システムのＥＣＵを構成する。周辺監視システムとは、典型的には、車載周辺監視カメラで取得した画像から所定の対象物（例えば白線等の道路標示、道路標識、周辺車両のような障害物等）を画像認識処理するシステムである。尚、画像認識結果は、例えば障害物等の存在等をユーザに報知する警報システムや障害物等と車両の位置関係等に応じて車両制御を行う車両制御システム等で利用されてもよい。

周辺監視システムでは、車速が速くなるにつれて、障害物等の対象物の探索範囲が広がり、ＣＰＵコア１０１，１０２の処理負荷が高くなる。即ち、車両の速度が高くなるにつれて、所定時間内に移動する車両の距離が長くなるので、その分だけ長い距離の範囲を監視する必要が生ずる。例えば図１３に概念的に示すように、低速時の探索範囲は１ｍ先から１０ｍ先の画像でよいのに対して、高速時の探索範囲は２０ｍ先の画像まで必要となる。このことから、車速に応じて画像処理範囲を変化させる周辺監視システムでは、車速情報を車両情報として用いてＣＰＵコア１０１，１０２の処理負荷を予測することができる。この目的のため、第３の具体例では、マルチコアＣＰＵ１２には、車速情報が入力される。車速情報は、車輪速センサからの車速情報であってもよいし、トランスミッションの出力軸の回転数等の車速に関連する情報が使用されてもよい。また、図３に示すフローチャートでは、車両情報として車速情報が入力され（ステップ３００）、車速情報からＣＰＵコア１０１，１０２の処理負荷として、対象物の探索範囲が予測され（ステップ３０１）、予測した処理負荷が所定レベル（所定探索範囲）よりも高いか否かが判定される（ステップ３０２）。この場合も同様の考え方に基づいて、所定探索範囲は、１つのＣＰＵコアで処理可能な処理負荷の最大レベル（最大探索範囲）に適合されてよい。或いは、図３のステップ３０１及び３０２の処理として、車速が所定閾値（所定車速）よりも高いか否かが判定されてもよい。この場合も同様の考え方に基づいて、所定車速は、１つのＣＰＵコアで処理可能な処理負荷の最大レベルに適合されてよい。例えば、車速が所定車速未満の低速領域である場合は、１つのＣＰＵコアで処理可能な処理負荷であると判定して、故障診断を行うこととし、車速が所定車速以上の中速領域又は高速領域である場合は、１つのＣＰＵコアで処理不能な処理負荷であると判定して、故障診断を行わないようにしてよい。

第４の具体例は、車両情報としてエンジン回転数を用いて、ＣＰＵコア１０１，１０２の処理負荷を予測する方法に関する。ここでは、ＣＰＵコア１０１，１０２は、エンジン制御システムの制御を実行する。即ち、ＣＰＵコア１０１，１０２は、ＥＦＩ・ＥＣＵを構成する。エンジン制御システムは、燃料噴射や点火等の各種エンジン制御を行うシステムである。

エンジン制御システムでは、エンジン回転数が高くなるにつれて、ＣＰＵコア１０１，１０２の処理負荷が高くなる。このことから、エンジン制御システムでは、エンジン回転数を車両情報として用いてＣＰＵコア１０１，１０２の処理負荷を予測することができる。この目的のため、第４の具体例では、マルチコアＣＰＵ１２には、エンジン回転数が入力される。また、図３に示すフローチャートでは、車両情報としてエンジン回転数が入力され（ステップ３００）、エンジン回転数からＣＰＵコア１０１，１０２の処理負荷が予測され（ステップ３０１）、予測した処理負荷が所定レベルよりも高いか否かが判定される（ステップ３０２）。尚、図３のステップ３０１及び３０２の処理として、エンジン回転数が所定閾値（所定回転数）よりも高いか否かが判定されてもよい。即ち、エンジン回転数が所定回転数未満である場合は、１つのＣＰＵコアで処理可能な処理負荷であると判定して、故障診断を行うこととし、エンジン回転数が所定回転数以上である場合は、１つのＣＰＵコアで処理不能な処理負荷であると判定して、故障診断を行わないようにしてよい。この場合も同様の考え方に基づいて、所定閾値（所定回転数）は、１つのＣＰＵコアで処理可能な処理負荷の最大レベルに基づいて適合されてよい。

図１４は、本発明のその他の一実施例（実施例２）による故障診断装置２のハードウェア構成を示す図である。

本実施例の故障診断装置２は、上述した実施例の故障診断装置１に対して、ＣＰＵコアの数が主に異なる。即ち、本実施例の故障診断装置２は、４つのＣＰＵコア１０１，１０２，１０３，１０４を有する。このようにマルチコアＣＰＵ１２においてＣＰＵコアの数は２以上の任意の数であってもよい。

本実施例においても、図３に示すフローチャートと同様の態様で故障診断テスト制御が実行されてよい。この場合、ステップ３０２の判定においては、所定レベルは、３つのＣＰＵコアで処理可能な処理負荷の最大レベルに対応してもよい。即ち、所定レベルは、１つのＣＰＵコアで故障診断を行い他の３つのＣＰＵコアで通常処理を行うことが可能な処理負荷の最大レベルに対応してもよい。従って、所定レベルは、同様に、ＣＰＵコア１０１，１０２，１０３，１０４の個々のＣＰＵコアの能力（性能）に応じて適合されてよい。尚、ＣＰＵコア１０１，１０２，１０３，１０４の能力は、一般的に、それぞれ同一である。ステップ３０２の判定において、予測された処理負荷が所定レベルよりも高い場合は、ステップ３０４に進み、同様に、４つのＣＰＵコア１０１，１０２，１０３，１０４がSMP動作を行う。他方、予測された処理負荷が所定レベルよりも高い場合は、ステップ３１０に進み、故障診断対象のＣＰＵ番号が呼び出される。本実施例では、ＣＰＵ番号レジスタ２０４におけるＣＰＵ番号の更新は、例えば「０」、「１」、「２」、「３」の順序で周期的に行われてよい。ＣＰＵ番号「０」、「１」、「２」、「３」は、ＣＰＵコア１０１，１０２，１０３，１０４にそれぞれ対応する。尚、ＣＰＵ番号の更新の順序は任意であり、例えばＣＰＵ番号「１」、「０」、「２」、「３」の順序で周期的に行われてもよい。

また、本実施例においても、データ制御部２００は、図４に示した構成と同様であってよい。但し、図４のＣＰＵコア１０１，１０２に対して設けられるマルチプレクサ２０１，２０２と同様に、ＣＰＵコア１０３，１０４に対してそれぞれマルチプレクサが追加される。また、ＣＰＵ番号レジスタ２０４は、４つのＣＰＵコア１０１，１０２，１０３，１０４に対応するために２ビットにされる。また、マルチプレクサ２０５は、ＣＰＵコア１０１，１０２のみからの入力だけでなく、ＣＰＵコア１０３，１０４からの入力をも受け付けるように変更される。

尚、本実施例２では、４つのＣＰＵコア１０１，１０２，１０３，１０４が１つずつ故障診断を行うように構成されているが、４つのＣＰＵコア１０１，１０２，１０３，１０４のうちの１つ、２つ又は３つのＣＰＵコアが選択的に並列で故障診断を行うことが可能な構成であってもよい。例えば、予測された処理負荷が、１つのＣＰＵコアで処理可能なレベルである場合は、残りの３つのＣＰＵコアが並列で故障診断を行い、予測された処理負荷が、１つのＣＰＵコアで処理不能であるが２つのＣＰＵコアで処理可能なレベルである場合は、残りの２つのＣＰＵコアが並列で故障診断を行い、予測された処理負荷が、２つのＣＰＵコアでも処理不能であるが３つのＣＰＵコアならば処理可能なレベルである場合は、残りの１つのＣＰＵコアが並列で故障診断を行うこととしてもよい。この場合は、故障診断ブロック２１０（図４参照）が３つ用意されてよい。

以上、本発明の好ましい実施例について詳説したが、本発明は、上述した実施例に制限されることはなく、本発明の範囲を逸脱することなく、上述した実施例に種々の変形及び置換を加えることができる。

例えば、上述した実施例では、車両情報からＣＰＵコアの処理負荷を予測し、予測結果に基づいて故障診断を行うか否かを判定しているが、車両情報からＣＰＵコアの処理負荷を検出し、検出結果に基づいて故障診断を行うか否かを判定してもよい。例えば、故障診断処理に要する時間（図３のステップ３１０からステップ３２８までの処理に要しうる時間の最大値）が、ＣＰＵコアの処理負荷の変動が生ずる時間よりも有意に小さい場合には、リアルタイムに検出されるＣＰＵコアの処理負荷に応じて故障診断を行うか否かを判定してもよい。尚、マルチコアＣＰＵ１２の処理負荷を検出するために、車両情報として、ＰＷＭ信号のキャリア周波数（現在値）等の上述した情報の他、マルチコアＣＰＵ１２における現時点から所定時間前までの関数の呼び出し数等が使用されてもよい。

また、上述した実施例では、予測したマルチコアＣＰＵ１２の処理負荷が所定レベルより大きいか否かに応じて特定の１つの又は２つ以上のＣＰＵコアの故障診断を行うか否かを判定しているが、予測したマルチコアＣＰＵ１２の処理負荷に応じて、より多様な態様でＣＰＵコアの故障診断態様を変更してもよい。

例えば、予測したマルチコアＣＰＵ１２の処理負荷に応じて、特定の１つのＣＰＵコアの故障診断の実行部分を可変してもよい。例えば、故障診断が複数個の故障診断テスト用のデータからなる場合、予測したマルチコアＣＰＵ１２の処理負荷に応じて、特定の１つのＣＰＵコアの故障診断を実行する際における処理する故障診断テスト用のデータの数を調整してもよい。その場合、次の機会（複数の機会も可）で、特定の１つのＣＰＵコアの故障診断として、特定の１つのＣＰＵコアが残りの故障診断テスト用のデータを処理すればよい。

図１５は、処理負荷に応じてＣＰＵコアの故障診断の実行部分を可変する故障診断テスト制御の一例を示す。図１５に示すフローチャートでは、ステップ１５００にて車両情報が入力され（図３のステップ３００と同様）、ステップ１５０１にて車両情報からＣＰＵコア１０１，１０２の処理負荷が予測され（図３のステップ３０１と同様）、ステップ１５０２にて予測した処理負荷が所定レベルよりも高いか否かが判定される（図３のステップ３０２と同様）。予測した処理負荷が所定レベルよりも高い場合は、ステップ１５０４にて通常処理が実行される（図３のステップ３０４，３０６，３０８と同様）。他方、予測した処理負荷が所定レベルよりも小さい場合は、ステップ１５０６にて、予測した処理負荷と所定レベルとの差が小さいか否かが判定される。即ち、予測した処理負荷が、その後の短時間（負荷予測期間Ｔよりも短い時間）で、所定レベルよりも高くなりうるほど所定レベルに近接しているか否かが判定される。予測した処理負荷と所定レベルとの差が小さい場合は、その後の負荷予測期間Ｔよりも短い時間で所定レベルよりも高くなりうると判断し、ステップ１５１０に進み、予測した処理負荷と所定レベルとの差が大きい場合は、ステップ１５０８に進む。ステップ１５０８では、故障診断の全部が実行される。故障診断の全部の実行態様については、図３のステップ３１０乃至３２８と同様であってよい。他方、ステップ１５１０では、負荷予測期間Ｔよりも短い時間で故障診断が完了するように、故障診断の一部のみが実行される。故障診断の一部の実行態様については、図３のステップ３１０乃至３２８と同様であってよい。但し、この場合、ステップ３２８では、故障診断の残りの部分が実行されるまでＣＰＵ番号の更新が実行されない。故障診断の残りの部分は、その後再び予測処理負荷が所定レベルを下回る機会（複数の機会も可）にて実行されてよい。

尚、図１５に示した故障診断テスト制御では、実質的に、２つの閾値で予測した処理負荷を評価している。即ち、予測した処理負荷が第１の閾値（所定レベル）よりも高い場合は、故障診断を行わず、予測した処理負荷が第１の閾値（所定レベル）よりも低いが第２の閾値（第２の所定レベル）よりも高い場合は、故障診断の一部のみを実行し、予測した処理負荷が第２の閾値よりも低い場合は、故障診断の全部（１つのＣＰＵコアに対して全部）を実行している。しかしながら、３つ以上の閾値でより細分化してもよい。或いは、図３に示した故障診断テスト制御の変形例として、予測した処理負荷が所定レベルよりも高い場合でも、可能な範囲の故障診断（故障診断の一部）のみを実行することとしてもよい。

また、予測したマルチコアＣＰＵ１２の処理負荷に応じて、故障診断処理が実行可能となるようにタスク調整を行ってもよい。例えば図３に示す故障診断テスト制御では、テストモード中に、ＡＭＰ動作に切り替わることでＣＰＵコア１０１，１０２間のタスク調整が実質的に実現されている。かかるタスク調整に加えて、予測したマルチコアＣＰＵ１２の処理負荷が所定レベルよりも高くなった場合に、タスク調整を行って、故障診断処理が実行可能となるようにしてもよい。

図１６は、処理負荷に応じてタスク調整を行いＣＰＵコアの故障診断の実行可能な機会を増加させる故障診断テスト制御の一例を示す。

図１６に示すフローチャートでは、ステップ１６００にて車両情報が入力され（図３のステップ３００と同様）、ステップ１６０１にて車両情報からＣＰＵコア１０１，１０２の処理負荷が予測され（図３のステップ３０１と同様）、ステップ１６０２にて予測した処理負荷が所定レベルよりも高いか否かが判定される（図３のステップ３０２と同様）。予測した処理負荷が所定レベルよりも高い場合は、ステップ１６０４にてタスク調整が実行される。このタスク調整では、例えば優先度の低いタスクが負荷予測期間Ｔよりも後に実行されるようにタスク調整が行われてもよい（即ち、優先度の低いタスクが後回しされる）。ステップ１６０６では、ステップ１６０４でのタスク調整を反映させてＣＰＵコア１０１，１０２の処理負荷が再度予測され（図３のステップ３０１と同様）、予測した処理負荷が所定レベルよりも高いか否かが再度判定される（図３のステップ３０２と同様）。予測した処理負荷が依然として所定レベルよりも高い場合は、ステップ１６０８にて通常処理が実行される（図３のステップ３０４，３０６，３０８と同様）。但し、この場合は、ステップ１６０４にて行ったタスク調整をキャンセルすることとしてよい。他方、予測した処理負荷が所定レベルよりも小さい場合は、ステップ１６１０にて故障診断が実行される（図３のステップ３１０乃至３２８と同様）。

また、予測したマルチコアＣＰＵ１２の処理負荷に対して、実際のマルチコアＣＰＵ１２の処理負荷が異なる場合も有りうる。そこで、テストモードの間に、故障診断対象でないＣＰＵコア１０２又は１０１により処理できないほど処理負荷が高くなった場合には、故障診断対象のＣＰＵコアのテストモードが中止されてもよい。

図１７は、テストモードの間に処理負荷が高くなった場合に故障診断の中断を行う故障診断テスト制御の一例を示す。

図１７に示すフローチャートは、ステップ１７２３とステップ１７２５の処理が図３の故障診断テスト制御に追加された点が主に異なる。ステップ１７２３では、テストモードの間に、新たにが入力された最新の車両情報に基づいて再度ＣＰＵコア１０１，１０２の処理負荷が予測／検出され、予測／検出された処理負荷が所定レベルよりも高い場合は、ステップ１７２５に進み、故障診断対象のＣＰＵコアのテストモードが中止・中断される。この場合、故障診断対象のＣＰＵコアのモードはテストモードから通常モードに変更され、ステップ３０４の処理に移行する。尚、その後、再びステップ３０２にて予測される処理負荷が所定レベルよりも低くなった場合には、ステップ３２０からの処理にて故障診断対象のＣＰＵコアの故障診断が再開（最初から再開又は途中から再開）される。

また、上述した実施例は、マルチコアＣＰＵ１２に関するものであるが、複数のマイコンからなるマルチプロセッサシステムにも拡張して適用することができる。即ち、複数のマイコンのそれぞれのＣＰＵを、上述の実施例におけるＣＰＵコア１０１，１０２（又はＣＰＵコア１０１，１０２，１０３，１０４）と同様に扱ってもよい。この場合、複数のマイコン間には、データ制御部２００（図４等参照）に相当する構成（複数のマイコン間のデータ連携を行う部）が設けられる。また、複数のマイコン間では、故障診断時に必要なタスクの調整が実行される。

最後に、以上の説明に関して更に以下の付記を開示する。
（付記１）
マルチコアプロセッサにおける複数のＣＰＵの故障診断を行う故障診断装置であって、
前記複数のＣＰＵの処理に関連する車両情報に基づいて、前記複数のＣＰＵの全体として処理負荷を予測又は検出し、該処理負荷の予測結果又は検出結果に応じて、前記複数のＣＰＵの動作モードをＳＭＰとＡＭＰとの間で動的に切換え、ＡＭＰに切り換えたときに、前記複数のＣＰＵのうちの特定のＣＰＵが自身の故障診断を行うことを特徴とする、故障診断装置。
（付記２）
前記予測又は検出した処理負荷が所定基準よりも低い場合に、ＳＭＰからＡＭＰに切り換える、付記１に記載の故障診断装置。
（付記３）
ＡＭＰの動作モードでは、前記複数のＣＰＵのうちの特定のＣＰＵ以外のＣＰＵは、通常処理を実行する、付記１又は２に記載の故障診断装置。
（付記４）
前記予測又は検出した処理負荷が所定基準よりも高い場合は、ＳＭＰに動作モードが維持される、付記１〜３のうちのいずれかに記載の故障診断装置。
（付記５）
前記予測又は検出した処理負荷に応じて、前記特定のＣＰＵが行うべき故障診断の処理内容（例えば、故障診断テスト用のデータの処理個数や処理範囲）を可変する、付記１〜４のうちのいずれかに記載の故障診断装置。
（付記６）
前記特定のＣＰＵは、１つのＣＰＵ又は２つ以上のＣＰＵである、付記１〜５のうちのいずれかに記載の故障診断装置。
（付記７）
複数のＣＰＵの故障診断を行う故障診断装置であって、
前記複数のＣＰＵの処理に関連する車両情報に基づいて、前記複数のＣＰＵの全体としての処理負荷を予測又は検出し、該処理負荷の予測結果又は検出結果に応じて、故障診断の実行態様を変更することを特徴とする、故障診断装置。
（付記８）
前記複数のＣＰＵは、マルチコアプロセッサにおける複数のＣＰＵである、付記７に記載の故障診断装置。
（付記９）
前記複数のＣＰＵの全体としての処理負荷が所定基準よりも低いことが予測又は検出された場合に、故障診断を行う、付記７又は８に記載の故障診断装置。
（付記１０）
前記複数のＣＰＵの全体としての処理負荷が所定基準よりも高いことが予測又は検出された場合に、少なくとも一部の故障診断を行わない（即ち、一部のみを実施する又は全部実施しない）、付記７〜８のうちのいずれかに記載の故障診断装置。
（付記１１）
故障診断を行っている間に、前記複数のＣＰＵの全体としての処理負荷が所定基準よりも高くなった場合に、故障診断の少なくとも一部を中止する、付記１〜１０のうちのいずれかに記載の故障診断装置。
（付記１２）
前記複数のＣＰＵは、ＣＰＵ毎に自身の故障診断を行う、付記１〜１１のうちのいずれかに記載の故障診断装置。
（付記１３）
故障診断を行う場合、前記複数のＣＰＵ間でタスクの調整を行う、付記１〜１２のうちのいずれかに記載の故障診断装置。
（付記１４）
前記複数のＣＰＵは、駆動モータの制御を行うＣＰＵであり、
前記車両情報は、前記駆動モータの回転数である、付記１〜１３のうちのいずれかに記載の故障診断装置。
（付記１５）
前記複数のＣＰＵは、エンジン制御を行うＣＰＵであり、
前記車両情報は、エンジン回転数である、付記１〜１４のうちのいずれかに記載の故障診断装置。
（付記１６）
前記車両情報は、車速である、付記１〜１５のうちのいずれかに記載の故障診断装置。
（付記１７）
前記複数のＣＰＵは、周辺監視システムの制御を行うＣＰＵであり、
前記車両情報は、車速である、付記１〜１５のうちのいずれかに記載の故障診断装置。
（付記１８）
前記複数のＣＰＵは、ナビゲーションシステムの制御を行うＣＰＵであり、
前記車両情報は、ナビゲーションシステムに対するユーザの操作情報である、付記１〜１７のうちのいずれかに記載の故障診断装置。
（付記１９）
前記複数のＣＰＵは、複数のマイコンにそれぞれ含まれるＣＰＵから構成される、付記７、９〜１８のうちのいずれかに記載の故障診断装置。

１，２ 故障診断装置
１２ マルチコアＣＰＵ
１３ データアクセスコントローラ
１４ メモリコントローラ
１５ 記憶媒体
１６ 記憶媒体
１８ タイマ
２０ データバス
２２ データバス
１０１，１０２，１０３，１０４ ＣＰＵコア
２００ データ制御部
２０１ マルチプレクサ
２０２ マルチプレクサ
２０３ モード制御部
２０４ ＣＰＵ番号レジスタ
２０５ マルチプレクサ
２１０ 故障診断ブロック
２１２，２１４ 記憶部
２１６ 比較器

【０００２】
課題を解決するための手段
［０００６］
上記目的を達成するため、本発明の一局面によれば、複数のＣＰＵの故障診断を行う故障診断装置であって、
前記複数のＣＰＵの処理に関連する車両情報に基づいて、前記複数のＣＰＵの全体としての処理負荷を予測し、該処理負荷の予測結果に応じて、故障診断の実行態様を変更することを特徴とする、故障診断装置が提供される。
発明の効果
［０００７］
本発明によれば、ＣＰＵの通常処理への影響が少なくとも低減される態様で故障診断処理を行うことが可能な故障診断装置及び故障診断方法が得られる。
図面の簡単な説明
［０００８］
［図１］本発明の一実施例（実施例１）による故障診断装置１のハードウェア構成を示す図である。
［図２］マルチコアＣＰＵ１２を内蔵したＳｏＣをハードウェアとしたときのシステムレイヤを示す図である。
［図３］ＯＳ内の故障診断テスト制御の一例を示すフローチャートである。
［図４］図１に示したマルチコアＣＰＵ１２の詳細構成の一例を示す図である。
［図５］ＣＰＵコア１０１の故障診断を開始する直前のマルチプレクサ２０１，２０２，２０５の接続状態の概要を示す図である。
［図６］故障診断テスト用のデータと期待値の読み込み状態を示す図である。
［図７］ＣＰＵコア１０１からのテスト結果の出力状態を示す図である。
［図８］ＣＰＵコア１０１の故障診断完了後のマルチプレクサ２０１，２０２，２０５の接続状態の概要を示す図である。
［図９］故障診断テスト制御のその他の一例を示すフローチャートである。
［図１０］アプリ層に故障診断テスト制御を組み込んだ場合の構成を示す図である。
［図１１］三角波比較ＰＷＭの概要を示す図である。

Claims (11)

1. 複数のＣＰＵの故障診断を行う故障診断装置であって、
   前記複数のＣＰＵの処理に関連する車両情報に基づいて、前記複数のＣＰＵの全体としての処理負荷を予測又は検出し、該処理負荷の予測結果又は検出結果に応じて、故障診断の実行態様を変更することを特徴とする、故障診断装置。
2. 前記複数のＣＰＵは、マルチコアプロセッサにおける複数のＣＰＵである、請求項１に記載の故障診断装置。
3. 前記複数のＣＰＵの全体としての処理負荷が所定基準よりも低いことが予測又は検出された場合に、故障診断を行う、請求項１に記載の故障診断装置。
4. 前記複数のＣＰＵの全体としての処理負荷が所定基準よりも高いことが予測又は検出された場合に、少なくとも一部の故障診断を行わない、請求項１に記載の故障診断装置。
5. 故障診断を行っている間に、前記複数のＣＰＵの全体としての処理負荷が所定基準よりも高くなった場合に、故障診断の少なくとも一部を中止する、請求項１に記載の故障診断装置。
6. 前記複数のＣＰＵは、ＣＰＵ毎に自身の故障診断を行う、請求項１に記載の故障診断装置。
7. 故障診断を行う場合、前記複数のＣＰＵ間でタスクの調整を行う、請求項１に記載の故障診断装置。
8. 前記複数のＣＰＵは、駆動モータの制御を行うＣＰＵであり、
   前記車両情報は、前記駆動モータの回転数である、請求項１に記載の故障診断装置。
9. 前記複数のＣＰＵは、エンジン制御を行うＣＰＵであり、
   前記車両情報は、エンジン回転数である、請求項１に記載の故障診断装置。
10. 前記車両情報は、車速である、請求項１に記載の故障診断装置。
11. マルチコアプロセッサにおける複数のＣＰＵの故障診断を行う故障診断方法であって、
    前記複数のＣＰＵの処理に関連する車両情報を入力するステップと、
    前記車両情報に基づいて、前記複数のＣＰＵの全体としての処理負荷を予測又は検出する予測ステップと、
    前記予測ステップにおける処理負荷の予測結果又は検出結果に応じて、故障診断の実行態様を変更するステップとを含むことを特徴とする、故障診断方法。

Images