JP5316128B2 - 故障診断システム、電子制御ユニット、故障診断方法 - Google Patents

Description

本発明は、複数のＣＰＵコアを備えたマルチコアＣＰＵの故障診断システム等に関し、特に、各ＣＰＵコアを個別に故障診断する故障診断システム、電子制御ユニット及び故障診断方法に関する。

１つのシステムに複数のＬＳＩやマイコンが搭載されることを利用して、一方のＬＳＩ（マイコン）が他方のＬＳＩ（マイコン）から送受信されるウォッチドッグ信号を監視して、相互に、ＬＳＩやマイコンの異常を検出する異常検出が行われることがある。また、１つのマイコンが複数のＣＰＵコアを搭載したマルチコア型のプロセッサでは、複数のＣＰＵが同じ処理を実行してその処理結果を比較することで、異常を検出することが行われる場合がある。また、ＣＰＵが自己診断することで異常を検出する方法も考えられている（例えば、特許文献１参照。）。

図１４は、特許文献１において自己診断するプロセッサのブロック図である。命令コード生成部は命令固有コードを定められたルールに従って生成してコード比較部へ入力し、実行命令コード生成部は命令コード生成部とは逆のルールで命令固有コードを生成してコード比較部４入力する。コード比較部は、２つの命令固有コードを比較して、差異があればプロセッサに異常があったことを検出する。

しかしながら、複数のＣＰＵが同じ処理を実行したり、図１４のように異常検出のために何らかの命令を実行することは、そのマイコンやプロセッサのリソースを圧迫するため、本来そのプロセッサに要求される制御やデータ処理等の標準処理の実行速度に支障をきたすおそれがある。

ところで、マルチコア型のプロセッサには、ＳＭＰ（Symmetric Multi-Processing）と呼ばれる処理態様、ＡＭＰ（Asymmetric Multiprocessing）と呼ばれる処理態様、及び、ＳＭＰとＡＭＰを組み合わせたＢＭＰ（Bound Multiprocessing）と呼ばれる処理態様があることが知られている。そして、このＢＭＰとして構成されたプロセッサにおいて、いずれかのＣＰＵコアに異常が生じた場合、異常が発生したＣＰＵコアに割り当てられている処理を、他のＣＰＵコアに割り当てる技術が提案されている（例えば、特許文献２参照。）。特許文献２に開示されたオペレーティングシステムは、他のＣＰＵコアに処理を割り当てる際、優先順位の高い処理を正常なＣＰＵに割り当て、優先順位の低い処理を行わないようにすることによって、優先順位が高い処理を異常が検出される前と同じ効率で実行することを図っている。

特開平０７−２３０３９２号公報 特開２００８−１２３４３９号公報

しかしながら、特許文献２に記載されたオペレーティングシステムは、異常を検出する際、ＣＰＵコアにより「１＋１」の加算を行うなど、マイコンやプロセッサのリソースを圧迫するため、標準処理の実行速度に影響が生じるおそれがあるという点で特許文献１等と変わりはない。

本発明は、上記課題に鑑み、標準処理の実行速度に支障をきたすことなく複数のＣＰＵコアから異常の生じたＣＰＵコアを特定できる故障診断システム、電子制御ユニット及び故障診断方法を提供することを目的とする。

上記課題に鑑み、本発明は、Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−ＰｒｏｃｅｓｓｉｎｇモードからＡｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替え可能な複数のＣＰＵコアを搭載したマルチコアＣＰＵの故障診断システムにおいて、Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−ＰｒｏｃｅｓｓｉｎｇモードのマルチコアＣＰＵが標準処理を実行する際の処理負荷を予測する負荷予測手段と、前記処理負荷が閾値未満の場合、Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードで動作している２つ以上のＣＰＵコアの１つをＡｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替え、Ａｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り換えられない残りのＣＰＵコアに標準処理を継続させるモード切り替え手段と、Ａｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替えられたＣＰＵコアを故障診断する故障診断手段と、とを有し、前記モード切り替え手段は、前記故障診断手段により故障していないと判定されたＣＰＵコアをＳｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替える、ことを特徴とする。

標準処理の実行速度に支障をきたすことなく複数のＣＰＵコアから異常の生じたＣＰＵコアを特定できる故障診断システム、電子制御ユニット及び故障診断方法を提供することができる。

マイコンの故障診断を模式的に示す図の一例である。 マルチコアＣＰＵを搭載したマイコンのブロック図の一例である。 ＥＣＵのシステムレイヤの一例を示す図である。 データ制御部の構成図の一例を示す図である。 ＯＳが提供する機能ブロックの一例を示す図である。 負荷予測を模式的に説明する図の一例である。 モード切り替え部がモード制御部に制御信号を出力した直後のデータ制御部を示す図である。 ＣＰＵコア０が故障診断のテストデータ及び期待値を読み出す際のデータの流れを説明する図である。 ＣＰＵコア０が故障診断のテストデータを実行した後のデータの流れを説明する図である。 診断処理の終了時のデータ制御部を示す図である。 マイコンがＣＰＵコア毎に故障診断する手順を示すフローチャート図の一例である。 ４つのＣＰＵコア０〜３を有するマルチコアＣＰＵを搭載したマイコンのブロック図の一例である。 データ制御部に外部メモリを備えたマイコンのブロック図の一例である。 自己診断するプロセッサのブロック図である（従来図）。

以下、本発明を実施するための最良の形態について図面を参照しながら実施例を挙げて説明する。

図１は、マイコン１００の故障診断を模式的に示す図の一例である。マイコン１００はＣＰＵコア０とＣＰＵコア１（両者を区別しない場合はＣＰＵコア１１といい、ＣＰＵコア０，１により構成される１つのシステムをマルチコアＣＰＵ１３と称す。）を有する。マイコン１００に搭載されたＯＳ２１は、ＣＰＵコア０とＣＰＵコア１をそれぞれ個別に、ＳＭＰ（Symmetric Multi-Processing）とＡＭＰ（Asymmetric Multiprocessing）の処理モードの、一方から他方に切り替えることができる（以下、ＳＭＰの処理モードを「ＳＭＰモード」、ＡＭＰの処理モードを「ＡＭＰモード」、という）。すなわち、ＯＳ２１及びＣＰＵコア１１は、完全なＢＭＰ（Bound Multiprocessing）でなく、ＳＭＰモードから動的に（故障診断する際一時的に）ＢＭＰの処理モードに切り替わることで、処理効率を向上させている。

なお、ＳＭＰモードは、一般には、１つのＯＳ２１がＣＰＵコア０とＣＰＵコア１及びメモリを共有し、ＯＳ２１が処理負荷の少ないＣＰＵコア１１にタスクを動的に割り当てる処理態様である。すなわち、タスクとＣＰＵコア１１との結びつきがなく、ＯＳ２１から見て各ＣＰＵコアは対等である。また、ＡＭＰモードは、一般には、ＣＰＵコア１１に割り当てるタスクが予め定められている処理態様である。いずれかのＣＰＵコア１１の処理負荷が少なくても、実行対象のタスクがそのＣＰＵコア１１に割り当てられたタスクでなければ、処理負荷が少ないＣＰＵコア１１が実行対象のタスクを実行することができない。また、ＢＭＰモードは、一つのＯＳ２１が特定のタスクを特定のＣＰＵコアに割り当て、その他のタスクを残りのＣＰＵコアに動的に割り当てる処理態様である。

Ｉ）図１では、当初、ＳＭＰモードでＣＰＵコア０とＣＰＵコア１が標準処理を実行している。標準処理は、乗員の操作、走行状況や車両状況に応じて、ＣＰＵコア１１に随時要求される制御やデータ処理等をいい、換言すると、故障検出のタスク以外の処理である。標準処理は、一般には複数の異なるタスクから構成されている。

II）そして、ＣＰＵコア０を故障診断するタイミングになると、ＯＳ２１は、ＣＰＵコア０をＳＭＰモードからＡＭＰモードに切り替える前に、ＣＰＵコア１のみで標準処理を実行しても標準処理の実行速度に支障がないこと（処理負荷）を確認する。こうすることで、故障診断時に、ＣＰＵコア０がＡＭＰモードになり故障診断のタスクのみを実行しても、標準処理が滞ることなく実行されることを保証できる。

III）ＯＳ２１は故障診断する対象のＣＰＵコア（ここではＣＰＵコア０）１１をＳＭＰモードからＡＭＰモードに切り替える。ＣＰＵコア０がＡＭＰモードで実行する特定のタスクは故障診断のタスクである。ＡＭＰモードのＣＰＵコア０は、故障診断のタスク以外のタスクは実行しない。これに対し、ＣＰＵコア１はＳＭＰモードのままなので、ＣＰＵコア１は標準処理を継続する。

IV)ＣＰＵコア０が故障診断のタスクを終了すると、ＯＳ２１はＣＰＵコア０をＡＭＰモードからＳＭＰモードに切り替える。同様の手順で、ＯＳ２１はＣＰＵコア１をＳＭＰモードからＡＭＰモードに切り替え、ＣＰＵコア１に故障診断のタスクを割り当てる。

ＳＭＰモードとＡＭＰモードを相互に切り替え可能なＯＳ２１とマルチコアＣＰＵ１３を搭載し、切り替え前に１つのＣＰＵコア１１で処理できる処理負荷か否かを確認することで、標準処理の実行速度に支障をきたすことなく、マルチコアＣＰＵ１３の各ＣＰＵコア１１を個別に故障診断することができる。

図２は、マルチコアＣＰＵ１３を搭載したマイコン１００のブロック図の一例を示す。マイコン１００は、マルチコアＣＰＵ１３、データアクセスコントローラ１４、メモリアクセスコントローラ１５及びデータバス１６、１７を有する。マルチコアＣＰＵ１３は、ＣＰＵコア０、ＣＰＵコア１及びデータ制御部１２を有し、データアクセスコントローラ１４は外部メモリ１８と、メモリアクセスコントローラ１５は外部メモリ１９とそれぞれ接続されている。なお、マイコン１００でなくＬＳＩにマルチコアＣＰＵ１３を搭載してもよい。

マイコン１００、外部メモリ１８及び外部メモリ１９とで、車両に搭載されるＥＣＵ（Electronic Control Unit）２００を実現できる。例えば、マルチメディア系のＥＣＵ２００では、ＧＰＳ受信機が検出した位置情報に基づき道路地図を表示装置に表示したり、目的地までの経路を検索するなどの処理、テレビやカメラ映像の映像処理、及び、ラジオやＣＤプレーヤの音声処理等が標準処理となる。また、エンジンＥＣＵでは、燃料噴射量、燃料噴射タイミング、吸排気弁の開放タイミング、スロットル開度、イグナイタの点火タイミング等を適切に制御する処理が標準処理となる。この他、ボディＥＣＵ、ブレーキＥＣＵ、運転支援用の各種のＥＣＵ２００にも搭載できる。本実施例では、これらの標準処理の実行速度に支障をきたすことなく故障診断するので、リアルタイム性が要求されるものを標準処理と定義してもよい。

データ制御部１２は、ＣＰＵコア０とＣＰＵコア１のＣＰＵ間通信を制御する。ＣＰＵ間通信の一般的な機能として、ＣＰＵコア１１の状態をサイクル時間毎に相互に通知したり、共有メモリを介してＣＰＵコア０とＣＰＵコア１の間でデータを送受信することができる。例えば、２つのＣＰＵコア１１が同じアプリケーションを実行し互いの処理結果を利用するような場合、データ制御部１２が処理結果の整合性を確保する。また、ＣＰＵコア１１が、用意されたＡＰＩ（Application Programming Interface）を利用してデータ制御部１２に要求することで、ＣＰＵコア０からＣＰＵコア１（又はその逆に）に割り込みすること可能になっている。

データバス１７は、標準処理時にＣＰＵコア１１が使用するバスで、データバス１６は故障診断時にＣＰＵコア１１が使用するバスとなる。データ制御部１２は、故障診断時になると、ＣＰＵコア１１にデータバス１６を介して外部メモリ１８にアクセスさせる。例えばＣＰＵコア０が故障診断のタスクを実行していても、ＣＰＵコア１は標準処理しているので、標準処理時に使用するデータバス１７と故障診断時に使用するデータバス１６を、別々に設けることで、故障診断時にデータバス１７のバス負荷が増大して、標準処理の実行速度に支障をきたすことを防止できる。

データアクセスコントローラ１４は、故障診断時に、データ制御部１２からの要求に応じて外部メモリ１８にアクセスし、後述するテストデータ３７や期待値３８を読み込む。

外部メモリ１９は、標準処理に必要なアプリケーションプログラム、ＯＳ２１、ファイル等を記憶している、比較的大容量の記憶装置（例えば、ＨＤＤ、ＳＳＤ等）である。データ制御部１２は、標準処理を実行しているＣＰＵコア１１のアクセス要求を、データバス１７を介してメモリアクセスコントローラ１５に要求する。

なお、バス１０には不図示の各種のＩＰ（Intellectual Property）が接続されている。これらのＩＰは、例えば、電源回路，入出力インターフェイス回路，ＣＡＮ通信回路、モータ制御回路、等のＩＣである。マイコン１００をマルチメディア系のＥＣＵ２００に搭載する場合、ラジオチューナ、テレビチューナ、ＡＶデコーダ、音声認識／合成回路、Ｂｌｕｅｔｏｏｔｈ回路、タッチパネルセンサ回路、等のＩＣがＩＰになる。オーディオ系のＩＰは、アンプを介してスピーカに接続され、ビジュアル系のＩＰはディスプレイに接続されている。

図３は、ＥＣＵ２００のシステムレイヤの一例を示す図である。図３ではマイコン１００がマルチメディア系のＥＣＵ２００に搭載された場合のシステムレイヤである。マルチコアＣＰＵ１３に最も近いレイヤがＯＳ２１のレイヤとなる。ＯＳ２１のレイヤは、実際には、アクチュエータを制御するためのデバイスドライバ、仮想的な実行環境を提供したり、プロトコル処理やデータ圧縮・伸長などの特定の演算を実行するミドルウェアを含む。本実施例ではこのＯＳ２１が、ＣＰＵコア１１のＳＭＰモードからＡＭＰモードへの切り替えを制御する。

ＯＳ２１の上のレイヤには、ＵＩ制御アプリ２２及び機能ロジック２３のレイヤがある。ＵＩ制御アプリ２２はマルチメディア系のＥＣＵ２００がディスプレイに表示するＵＩ（User Interface）を制御する。図示するように最も上位のレイヤが、ユーザが目にするＵＩを制御する各種の機能毎のＵＩアプリ２９である。ナビ用ＨＭＩアプリ２５はナビゲーション機能に関するＵＩの生成やユーザが操作するためのメニューのＵＩを生成し、映像系ＨＭＩアプリ２６はＤＶＤやテレビ等の映像のＵＩやその機能をユーザが操作するためのメニューのＵＩを生成し、オーディオ系ＨＭＩ２７アプリはラジオやテレビ音声などのオーディオの機能に関するＵＩやユーザが操作するためのメニューのＵＩを生成し、車両連携用ＨＭＩアプリ２８は例えば位置情報を利用した車両制御に関する機能をユーザが操作するためのＵＩや警告やメッセージを表示するためのＵＩを生成する。

ＵＩ制御アプリ２２は、機能毎のＵＩアプリ２９が生成するＵＩの表示を制御することができる。例えば、所定の機能のＵＩだけを全画面でディスプレイに表示したり、全てのＵＩを分割してディスプレイに表示したり、所定の機能のＵＩだけを非表示にしたり、といった制御を実行する。

ＵＩ制御アプリ２２と機能毎のＵＩアプリ２９の間のレイヤであるＨＭＩ−ＡＰＩ２４は、機能毎のＵＩアプリ２９が機能ロジック２３を呼び出すためのＡＰＩを提供する。例えば、ユーザが所定のＵＩアプリ２９に対し操作を入力すると、操作されたＵＩアプリ２９が、ＨＭＩ−ＡＰＩ２４に対し操作に応じたＡＰＩをコールする。これにより、ＨＭＩ−ＡＰＩ２４は、コールされたＡＰＩに従い所定の機能ロジック２３を呼び出す。

機能ロジック２３は、ナビロジック２３ａ、映像系ロジック２３ｂ、オーディオ系ロジック２３ｃ、車両連携ロジック２３ｄである。ＥＣＵ２００の機能毎にロジックが用意されている。このように、機能毎のＵＩアプリ２９と機能ロジック２３を分離することで、機能ロジック２３はそのままにＵＩだけを変更するなど、開発に自由度が増す。

〔データ制御部１２〕
図４を参照して、データ制御部１２について詳細に説明する。データ制御部１２は、３つのＭＵＸ４１，４２、４５、モード制御部４３、ＣＰＵ番号レジスタ４４、及び、比較ブロック４６を有する。ＣＰＵコア０とＭＵＸ４１、ＣＰＵコア１とＭＵＸ４２がそれぞれ接続されている。ＭＵＸ４１はデータアクセスコントローラ１４とメモリアクセスコントローラ１５とそれぞれ接続されている。ＭＵＸ４２も、データアクセスコントローラ１４とメモリアクセスコントローラ１５とそれぞれ接続されている。モード制御部４３は、ＭＵＸ４１、ＭＵＸ４２、ＣＰＵコア０及びＣＰＵコア１とそれぞれ接続されている。ＭＵＸ４５は、ＣＰＵコア０及びＣＰＵコア１とそれぞれ接続されている。ＭＵＸ４５は、比較ブロック４６と接続されている。

モード制御部４３は、ＣＰＵコア０とＣＰＵコア１の処理モードを切り替える。すなわち、モード制御部４３は、ＣＰＵコア１をＳＭＰモードのまま、ＣＰＵコア０をＡＭＰモードに切り替え、ＣＰＵコア０をＳＭＰモードのまま、ＣＰＵコア１をＡＭＰモードに切り替える。具体的には、ＡＭＰモードに切り替えるＣＰＵコア１１に例えば「Ｈｉｇｈ」信号を入力する。こうすることで、ＡＭＰモードに切り替えられたＣＰＵコア１１は、内部のスイッチをオン／オフして故障診断専用の接続線やロジック回路を形成する。故障診断用のロジック回路は、例えば数クロックで故障診断の処理結果が得られるようになっているなど、故障診断を短時間で終了させることができる。

また、ＡＭＰモードに切り替えられたＣＰＵコア０は、処理結果をＭＵＸ４５に出力し、ＡＭＰモードに切り替えられたＣＰＵコア１は、処理結果をＭＵＸ４５に出力する。このように、ＭＵＸ４５には、ＡＭＰモードのＣＰＵコア１１のみから処理結果が入力されるようになっている。

また、モード制御部４３は、ＭＵＸ４１、４２の処理モードを切り替える。ＭＵＸ４１、４２は、ＳＭＰモードではメモリアクセスコントローラ１５にアクセス要求を出力し、ＡＭＰモードではデータアクセスコントローラ１４にアクセス要求を出力する。このため、ＣＰＵコア０をＡＭＰモードに切り替えた場合、モード制御部４３は、ＭＵＸ４１をＡＭＰモードに切り替え、ＭＵＸ４２をＳＭＰモードのままとする。具体的には、モード制御部４３は、ＭＵＸ４１に例えば「Ｈｉｇｈ」信号を入力する。同様に、ＣＰＵコア１をＡＭＰモードに切り替えた場合、モード制御部４３は、ＭＵＸ４２をＡＭＰモードに切り替え、ＭＵＸ４１をＳＭＰモードのままとする。具体的には、モード制御部４３は、ＭＵＸ４２に例えば「Ｈｉｇｈ」信号を入力する。

ＭＵＸ４５は、ＡＭＰモードのＣＰＵコア１１から入力された処理結果を比較ブロック４６に入力する。比較ブロック４６は、処理結果を記憶する処理結果記憶部４６ａ、比較器４６ｂ及び期待値記憶部４６ｃを有する。処理結果記憶部４６ａには、処理結果が記憶される。期待値記憶部４６ｃには、処理結果の期待値３８、すなわち正しい処理結果が記憶される。期待値３８は外部メモリ１８に予め記憶されており、ＯＳ２１がいずれかのＣＰＵコア１１をＡＭＰモードに切り替えると、ＯＳ２１が外部メモリ１８から期待値記憶部４６ｃに読み出すようになっている。なお、処理結果記憶部４６ａと期待値記憶部４６ｃは、例えば、ＤＲＡＭやレジスタで構成され、物理的に別体でなくてもよい。比較器４６ｂは、処理結果記憶部４６ａの処理結果と期待値記憶部４６ｂの期待値３８を比較して、一致するか否かを判定する。例えば、一致する場合に「Ｈｉｇｈ」信号を出す。また、処理結果と期待値３８とのずれが所定の閾値内か否かを判定してもよい。この判定結果が、故障診断結果となる。

ＣＰＵ番号レジスタ４４はＣＰＵコアの識別番号を記憶するレジスタである。例えば、モード制御部４３は、ＣＰＵ番号レジスタ４４に、次に故障診断すべきＣＰＵコア１１の識別番号を記憶する。モード制御部４３は、１つのＣＰＵコア１１の故障診断が終了する度にＣＰＵ番号レジスタ４４をインクリメントする。また、マルチコアＣＰＵ１３に搭載されたＣＰＵコア１１の「個数−１」に達すると、ＣＰＵレジスタ番号４４の記憶内容を「０」に戻す。こうすることで、同じＣＰＵコア１１だけを故障診断することなく、複数のＣＰＵコアを均一に故障診断することができる。

〔負荷予測〕
図５は、ＯＳ２１が提供する機能ブロックの一例を、図６は負荷予測を模式的に説明する図の一例をそれぞれ示す。ＯＳ２１（例えば、スケジューラ）は、ＣＰＵコア１１の処理負荷を参照しながらＣＰＵコア１１にタスクＡ〜Ｃを割り当てる。図５では、ＣＰＵコア０のタスクキュー３１にタスクＢ，Ａ、ＣＰＵコア１のタスクキュー３２にタスクＡ〜Ｃが登録されている。したがって、タスクキュー３１，３２を参照することで将来の処理負荷を予測可能となる。

負荷予測部３４は、タスクとＭＩＰＳ（Million Instructions Per Second）値を対応づけたテーブル３３を記憶している。例えば、タスクＡは、1秒間に１００万個の命令を出すプログラムなので、他のタスクＢ，Ｃに比べ処理負荷が高いことになる。ＣＰＵコア１１の処理負荷は、このＭＩＰＳ値が大きいタスクほど、大きい傾向になる。負荷予測部３４は、ＣＰＵコア１１の実行中のタスクとタスクキュー３１，３２のタスクを読み出し、テーブル３３からＭＩＰＳ値を読み出し、マルチコアＣＰＵ１３の処理負荷を予測する。図６（ａ）は、各ＣＰＵコア１１の処理負荷の時間的な変化の予測を示す図の一例である。組み込み系のシステムでは、アプリケーションが予め既知なのでアプリケーションのタスク毎にＭＩＰＳ値を特定しておくことができる。

どのくらいの将来まで負荷を予測するか（以下、負荷を予測する現時点からこの将来までの時間を「期間」という）は、少なくとも故障診断のタスクの実行に必要な時間である。なお、故障診断のタスクは、テストデータ３７又はテストデータ３７を実行することに相当する。故障診断のタスクの実行が終了するまでに、マルチコアＣＰＵ１３の処理負荷が標準処理を実行するＣＰＵコア１１の処理負荷を超えなければ、標準処理の実行速度に支障をきたすことなく、故障診断のタスクを実行したＣＰＵコア１１が標準処理に戻れるからである。期間は、長くても１秒程度であり、ＳＭＰモードからＡＭＰモードへの切り替えやテストデータ３７等の読み込みなどのオーバーヘッドを考慮しても１秒未満〜数秒で終了する。

図６（ａ）に示すように、各タスクの終了時間を考慮して、各ＣＰＵコア１１の処理負荷を重畳すれば、マルチコアＣＰＵ１３の処理負荷を予測する図６（ｂ）が得られる。一般的なＯＳ２１であればこのような処理負荷を定常的に監視して、タスクキュー３１、３２に空きがあるＣＰＵコア１１に優先的にタスクを割り当てる等の処理を実行しているので、負荷の予測により標準処理に支障をきたすことはないとしてよい。負荷の予測が仮にマルチコアＣＰＵ１３にとって付加的な処理だとしても、このような処理負荷の予測は、実行中のタスクとタスクキュー３１、３２からタスクを特定し、ＭＩＰＳ値を足し合わせるだけでよいので、処理負荷の予測は標準処理に支障をきたす負荷とはならない。

図６（ｂ）に示すように、時間とマルチコアＣＰＵ１３の処理負荷の関係が得られると、処理負荷予測部３４は引き続きＳＭＰモードのまま標準処理を実行するＣＰＵコア１１（ここではＣＰＵコア１）の処理能力を、期間の処理負荷が超えるか否かを判定する。ＣＰＵコア１１の処理能力は予め既知であり、これもＭＩＰＳ値で現すことができるので、容易に比較できる。

図６（ｂ）では、期間Ａの処理負荷がＣＰＵコア１の処理負荷を超えているが、期間Ｂの処理負荷はＣＰＵコア１の処理負荷を超えていないと判定される。したがって、ＣＰＵコア０の故障診断のタスクは、期間Ａが終了した時刻ｔ２（以下、「故障診断開始可能時」という）から実行される。なお、予測された処理負荷と比較されるＣＰＵコア１１の処理能力は、故障診断しない残りの全てのＣＰＵコア１１の処理能力の合計であるので、例えばＣＰＵコア１１の数が４つの場合、３つのＣＰＵコア１１の処理能力の合計が、予測された処理負荷に対する比較対象となる。

ところで、タスクキュー３１，３２にすでに割り当てられたタスクが存在する場合、それらのタスクを全て実行してから、故障診断することが考えられる。この場合、期間は故障診断の対象のＣＰＵコア１１のタスクが終了する時を起点とする。したがって、予測すべき処理負荷もこの期間の処理負荷となる。すなわち、ＣＰＵコア０を故障診断する場合、図６（ａ）に示すように、ＣＰＵコア０がタスクキュー３１の最後のタスクＡが終了した時が期間の起点となる。詳細には、起点から、「期間」経過した時毎に故障診断開始可能時となる可能性があることになる。処理負荷予測部３４は、タスクＡが終了した時から、他のＣＰＵコア１が実行するタスクＣ以降の処理負荷を予測する（図６（ｂ）ではタスクＣであるが、ＣＰＵコア１による各タスクの実行時間により、ＣＰＵコア０がタスクＡを終了した時にＣＰＵコア１が実行しているタスクは変わってくる。）。

なお、いったんタスクキュー３１に割り当てたタスクの再割り当てが可能であれば、処理負荷予測部３４が、マルチコア１３の処理負荷が処理能力を超えていない期間を見つけて、その期間にＣＰＵコア０に割り当てられているタスクを、故障診断の対象でないＣＰＵコア１に再割り当てしてもよい。

処理負荷予測部３４は、故障診断が可能な期間が見つかると、故障診断開始可能時をモード切り替え部３５に通知する。モード切り替え部３５（実体はＣＰＵコア１１）は、故障診断開始可能時になると、データ制御部１２のモード制御部４３に制御信号を出力する。こうすることで、上記のように、データ制御部１２が、故障診断のタスクの実行のために、ＣＰＵコア１１及びＭＵＸ４１，４２の処理モードを切り替える。

〔故障診断〕
モード制御部４３によりＡＭＰモードに切り替えられたＣＰＵコア１１は、故障診断のタスクを実行する。すなわち、ＣＰＵコア１１は、故障診断のタスクを実行することで故障診断部３６を実現する。図７〜１０は、ＣＰＵコア１１がＡＭＰモードに切り替えられた際のデータ制御部１２の挙動を説明する図の一例である。

図７は、モード切り替え部３５がモード制御部４３に制御信号を出力した直後のデータ制御部１２を示す。図７において図４と同一部には同一の符号を付しその説明は省略する。モード制御部４３は、ＣＰＵ番号レジスタ４４を参照して、「０」であることを検出すると、ＣＰＵコア０とＭＵＸ４１をＡＭＰモードに切り替える。これにより、ＭＵＸ４１はデータアクセスコントローラ１４にアクセス可能となり、ＣＰＵコア０はＭＵＸ４５にアクセス可能となる。

図８は、ＣＰＵコア０が故障診断のテストデータ３７及び期待値３８を読み出す際のデータの流れを説明する図である。ＡＭＰモードに切り替えられたＣＰＵコア０は、ＭＵＸ４１を介して外部メモリ１８からテストデータ３７と期待値３８を読み出すように、データアクセスコントローラ１４に要求する。これにより、ＣＰＵコア０はテストデータ３７をキャッシュして、テストデータ３７のアドレスをレジスタにセットする。また、データアクセスコントローラ１４は、外部メモリ１８から直接、比較ブロック４６に期待値３８を読み出す（ＤＭＡ（Direct Memory Access））。

なお、故障診断部３６は標準処理と同じ命令を故障診断に用いるため、テストデータ３７は、マイコン１００に入力されうる適当なデータでよい。すなわち、正常なＣＰＵコア１１でテストデータ３７が実行された際の処理結果である期待値３８が分かっていれば、どのようなテストデータ３７を用いてもよい。好ましくは、必要最小限のテストデータ３７とすることで、故障診断に必要な時間（上記の期間）を最小限にすることができる。

また、命令を含むテストデータ３７を故障診断用に用意しておいてもよい。この場合のテストデータ３７は、ＣＰＵコア１１が正常か否かを判定するための、命令（オペコード）と必要最小限のパラメータ（オペランド）である。ＣＰＵコア１１が有するＡＬＵや拡張機能用の演算回路により処理される簡単な命令とパラメータを用意しておく。

図９は、ＣＰＵコア０が故障診断のテストデータ３７を実行した後のデータの流れを説明する図である。ＣＰＵコア０は、テストデータ３７を実行すると処理結果をＭＵＸ４５に出力する。ＭＵＸ４５は、処理結果を比較ブロック４６の処理結果記録部に記憶する。こうすることで、比較器に期待値３８と処理結果の入力が可能になり、比較器は両者を比較して比較結果を保持又はデータアクセスコントローラ１４に出力する。データアクセスコントローラ１４は比較結果を外部メモリ１８に記憶する。なお、期待値３８と処理結果を比較した比較結果は、比較結果が異なる場合にのみ外部メモリに１８に出力されてもよい。こうすることで、故障診断のタスクの実行時間を短くできる。

故障診断の間、ＣＰＵコア１は標準処理を実行しているが、データ制御部１２はデータバス１７を介して外部記憶１９やＩＰにアクセスするので、故障診断によるバス負荷の増大が標準処理の実行速度に支障をきたすことはない。

図１０は、診断処理の終了時のデータ制御部１２を示す。モード制御部４３は、ＣＰＵコア０の処理モードを切り替えた直後、ＣＰＵ番号レジスタ４４の値をインクリメントするので、ＣＰＵ番号レジスタ４４の値が「１」になっている。これにより、次回の故障診断のタスク（テストデータ３７）は、ＣＰＵコア１が実行する。

〔故障診断の手順〕
図１１は、マイコン１００がＣＰＵコア毎に故障診断する手順を示すフローチャート図の一例を示す。なお、図１１ではＣＰＵコア０を故障診断の対象として説明する。

故障診断はそれほど頻繁に実行する必要はない。例えば、経年劣化して故障発生する可能性が生じてきても、故障診断は1日1回程度の周期でおこなえば充分である。このため、ＯＳ２１は、最後に故障診断した日時情報を記憶しておく。そして、例えば、イグニッション・オン毎に、日時情報を参照し、最後に故障診断してから故障診断時間間隔（例えば１日）以上経過している場合に、図１１の手順を開始する。故障診断時間間隔を１日とした場合、車両を運転する際には最長でも１日毎に、故障診断することができる。なお、日時情報をＣＰＵコアに対応づけて外部メモリ１８に記憶しておき、ＣＰＵコア毎に診断間隔を定めておいてもよい。

イグニッション・オンになってＯＳ２１が起動すると、ＯＳ２１は日時情報と故障診断時間間隔を外部メモリ１８から読み出し、現在時刻までの経過時間と故障診断時間間隔を比較する（Ｓ１０）。そして、経過時間が故障診断時間間隔を超えている場合（Ｓ１０のＹｅｓ）、負荷予測部３４に処理負荷を予測させる（Ｓ２０）。

負荷予測部３４は、ＣＰＵ番号レジスタ４４の値から故障診断の対象のＣＰＵコア０を特定する。負荷予測部３４は、そのＣＰＵコア０のタスクキュー３１に割り当てられた最後のタスクの終了時刻を予測し、終了時刻から期間毎の処理負荷を予測する（Ｓ３０）。

そして、期間毎に、処理負荷がＣＰＵコア１の処理能力を超えているか否かを判定する（Ｓ４０）。

ＣＰＵコア１の処理能力を処理負荷が超えている場合（Ｓ４０のＮｏ）、標準処理の実行速度に支障をきたすおそれがあるので、モード切り替え部３５はＣＰＵコア０をＡＭＰモードに切り替えない。このため、ＯＳ２１はＳＭＰモードのまま全てのＣＰＵコア０とＣＰＵコア１で負荷分散して（Ｓ５０）、標準処理を継続する（Ｓ６０）。

負荷予測部３４は、処理負荷を予測した期間が経過するまで待機し（Ｓ７０）、期間が経過するとステップＳ１０に戻り再度、負荷予測する。

ステップＳ４０において、１つのＣＰＵコア１の処理能力が処理負荷より大きい場合（Ｓ４０のＹｅｓ）、モード切り替え部３５はＣＰＵ番号レジスタ４４の値から故障診断の対象のＣＰＵコア０を特定する（Ｓ８０）。なお、モード切り替え部３５は負荷予測部３４から故障診断開始可能時を受け取る。

モード切り替え部３５は、故障診断開始可能時まで待機する（Ｓ９０）。故障診断開始可能時になるまで、故障診断の対象のＣＰＵコア０はＳＭＰモードのまま、タスクキュー３１に割り当てられたタスクを実行する（Ｓ１００）。なお、故障診断開始可能時の直前に、再度、処理負荷を予測してもよい。

そして、故障診断開始可能時になると、モード切り替え部３５はデータ制御部１２にＣＰＵコア０の処理モードの切り替えを要求する（Ｓ１１０）。これにより、データ制御部１２のモード制御部４３は、ＣＰＵコア０をＳＭＰモードからＡＭＰモードに切り替え、ＭＵＸ４１の処理モードをＳＭＰモードからＡＭＰモードに切り替える。

こうすることで、ＡＭＰモードに切り替えられたＣＰＵコア０は、故障診断を開始する（Ｓ１２０）。上記のように、ＣＰＵコア０はテストデータ３７を外部メモリ１８から読み出し、故障診断部３６を実現し、データアクセスコントローラ１４は外部メモリ１８から期待値を期待値記憶部４６ｃに読み出す。

故障診断部３６は診断が終了したか否かを判定する（Ｓ１３０）。終了したか否かは、例えば、テストデータ３７の最後まで実行したこと、又は、比較器が比較結果を出力したこと、から判定される。故障診断が終了していない場合（Ｓ１３０のＮｏ）、故障診断部３６は引き続きＡＭＰモードのままテストデータ３７を実行する（Ｓ１４０）。

そして、故障診断が終了すると場合（Ｓ１３０のＹｅｓ）、故障診断部３６はモード切り替え部３５に処理モードの切り替えを要求する。これにより、モード切り替え部３５は、データ制御部１２にＣＰＵコア０の処理モードの切り替えを要求し、データ制御部１２のモード制御部４３は、ＣＰＵコア０をＡＭＰモードからＳＭＰモードに切り替え、ＭＵＸ４１の処理モードをＡＭＰモードからＳＭＰモードに切り替える（Ｓ１５０）。

また、モード制御部４３は、ＣＰＵ番号レジスタ４４の値をインクリメントする（Ｓ１６０）。これにより、ＣＰＵ番号レジスタ４４には次に故障診断するべきＣＰＵコアの番号「１」が設定される。

以上で、１つのＣＰＵコア０の故障診断が終了したので、ステップＳ３０に戻り、ＯＳ２１はＣＰＵコア１の故障診断を実行する。これを、マルチコアＣＰＵ１３のＣＰＵコアの数だけ繰り返すことで、例えば、イグニッション・オン毎に全てのＣＰＵコア１１の故障診断を実行することができる。

なお、ＣＰＵコア１１の故障が検出された場合、マルチコアＣＰＵ１３はそのＣＰＵコア１１をマルチコアＣＰＵ１３から切り離し、残りのＣＰＵコア１１のみで標準処理を実行することができる。こうすることで、処理能力は低下しても、標準処理の処理結果を保証した上で、標準処理を継続することができる。この場合、優先度の高い重要なタスクを定めておき、標準処理のうち定められたタスクのみを実行することが好ましい。マイコン１００のフェイルセーフが可能となり、マイコンの耐故障性が向上する。

〔適用例１〕
これまで説明した故障診断を適用したマイコン１００について説明する。
図１２は、４つのＣＰＵコア０〜３を有するマルチコアＣＰＵ１３を搭載したマイコン１００のブロック図の一例を示す。図１２において図２と同一部には同一の符号を付しその説明は省略する。

２つのＣＰＵコア０、１の一方を故障診断すると、他方のＣＰＵコア１１に大きな負荷がかかるので、予測された処理負荷が１つのＣＰＵコア１１の処理能力を超えない期間が短くなる場合があり、その場合、故障診断に必要な時間を取ることができない（ＣＰＵコアが４つの場合は能力を超えない期間が比較的長いため、故障診断できることが多い。）。これに対し、４つのＣＰＵコア０〜３のうち１つのＣＰＵコア１１を故障診断しても、３つのＣＰＵコア１１がＳＭＰモードのままＯＳ２１が負荷分散するので、期間を検出することが容易になる。このように、本実施形態の故障診断は、ＣＰＵコア１１の数に関わらずマルチコアＣＰＵ１３に適用できる。

図１２のように、マルチコアＣＰＵ１３が４つのＣＰＵコア１１を有する場合、データ制御部１２のＣＰＵ番号レジスタ４４を２ビットにして、４つのＣＰＵコア１１に対応可能とする。また、データ制御部１２のデータアクセスコントローラ１４側に４つのＭＵＸを設け、それぞれをＣＰＵコア０〜３と接続する。また、ＭＵＸ４５とＣＰＵコア０〜３をそれぞれ接続する。モード制御部４３は、ＣＰＵコア０〜３のいずれかと４つのＭＵＸのいずれかを、択一的にＳＭＰモードからＡＭＰモードに切り替えることで、ＯＳ２１は各ＣＰＵコア１１の故障診断を実行できる。

故障診断の手順は図１１と同様であり、ＣＰＵコア１１の数だけステップＳ１０〜Ｓ１６０を繰り返せばよい。

〔適用例２〕
図２では、外部メモリ１８をマイコン１００に外付けしたが、外部メモリ１８をマイコン１００内に設けてもよい。
図１３は、データ制御部１２に外部メモリ１８を備えたマイコン１００のブロック図の一例を示す。図１３において図２と同一部には同一の符号を付しその説明は省略する。テストデータ３７は経過年数に関係なく同じとしてよく、また、テストデータ３７に変更がなければ期待値も同じである。

このため、データ制御部１２に内蔵しておくことができ、こうすることで、データアクセスコントローラ１４が外部メモリ１８からテストデータ３７と期待値を読み出す必要がなくなり、故障診断の時間を短縮できる。データ制御部１２に内蔵された外部メモリ１８は、ＲＯＭ、ＲＡＭ、ＥＥＰＲＯＭ等を実体とする。なお、ＲＡＭを内蔵する場合、マイコン１００の起動時に、例えば外部メモリ１９から読み出してＲＡＭに記憶しておく。

以上説明したように、本実施形態のマイコン１００は、故障診断の対象以外のＣＰＵコア１１で標準処理を支障なく実行できる場合にのみ、故障診断の対象のＣＰＵコア１１をＳＭＰモードからＡＭＰモードに切り替えることで、標準処理に支障をきたすことなく、マルチコアＣＰＵ１３の各ＣＰＵコア１１を個別に故障診断することができる。

１１ ＣＰＵコア
１２ データ制御部
１３ マルチコアＣＰＵ
３７ テストデータ
３８ 期待値
４１，４２，４５ ＭＵＸ
４３ モード制御部
４４ ＣＰＵ番号レジスタ
１００ マイコン
２００ ＥＣＵ

Claims (11)

1. Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−ＰｒｏｃｅｓｓｉｎｇモードからＡｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替え可能な複数のＣＰＵコアを搭載したマルチコアＣＰＵの故障診断システムにおいて、
   Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−ＰｒｏｃｅｓｓｉｎｇモードのマルチコアＣＰＵが標準処理を実行する際の処理負荷を予測する負荷予測手段と、
   前記処理負荷が閾値未満の場合、Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードで動作している２つ以上のＣＰＵコアの１つをＡｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替え、Ａｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り換えられない残りのＣＰＵコアに標準処理を継続させるモード切り替え手段と、
   Ａｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替えられたＣＰＵコアを故障診断する故障診断手段と、とを有し、
   前記モード切り替え手段は、前記故障診断手段により故障していないと判定されたＣＰＵコアをＳｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替える、
   ことを特徴とする故障診断システム。
2. 前記負荷予測手段は、前記故障診断手段が故障診断に要する期間の処理負荷を予測する、
   ことを特徴とする請求項１記載の故障診断システム。
3. 前記負荷予測手段は、Ａｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替えられるＣＰＵコアが実行するタスクが途切れる時刻を起点に前記期間を定める、
   ことを特徴とする請求項２記載の故障診断システム。
4. Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−ＰｒｏｃｅｓｓｉｎｇモードのＣＰＵコアに専用の第１のデータバスと、
   Ａｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−ＰｒｏｃｅｓｓｉｎｇモードのＣＰＵコアに専用の第２のデータバスと、
   Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−ＰｒｏｃｅｓｓｉｎｇモードのＣＰＵコアを前記第１のデータバスに接続し、Ａｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−ＰｒｏｃｅｓｓｉｎｇモードのＣＰＵコアを前記第２のデータバスに接続するデータ制御手段と、
   を有することを特徴とする請求項１〜３いずれか１項記載の故障診断システム。
5. 前記データ制御手段は、複数のＣＰＵコアとそれぞれ接続された複数のマルチプレクサ部を有し、
   前記データ制御手段は、Ａｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替えられた、ＣＰＵコアに接続されたマルチプレクサ部の接続先を、前記第１のデータバスから前記第２のデータバスに切り替える、
   ことを特徴とする請求項４記載の故障診断システム。
6. 前記故障診断手段は、故障診断用のテストデータの処理結果と、予め記憶している期待値とを比較して、比較結果が一致するか否かに応じて、Ａｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替えられたＣＰＵコアを故障診断する、
   ことを特徴とする請求項４記載の故障診断システム。
7. 前記テストデータ及び前記期待値を記憶した外部メモリを有し、
   前記故障診断手段は、前記第２のデータバスを介して前記テストデータ及び前記期待値を読み出す、
   ことを特徴とする請求項６記載の故障診断システム。
8. 前記データ制御手段は、前記テストデータ及び前記期待値を記憶している、
   ことを特徴とする請求項６記載の故障診断システム。
9. 前記故障診断手段が、ＣＰＵコアの故障を検出した場合、
   ＣＰＵコアをマルチコアＣＰＵから切り離し、故障していないと診断された残りのＣＰＵコアのみにタスクを分散する、
   ことを特徴とする請求項１記載の故障診断システム。
10. 請求項１〜９いずれか１項記載の故障診断システムと、
    ナビゲーション手段と、
    映像出力手段と、
    音声出力手段と、
    を有することを特徴とする車両用電子制御ユニット。
11. Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−ＰｒｏｃｅｓｓｉｎｇモードからＡｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替え可能な複数のＣＰＵコアを搭載したマルチコアＣＰＵによる故障診断方法において、
    マルチコアＣＰＵにより実現される負荷予測手段が、Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−ＰｒｏｃｅｓｓｉｎｇモードのマルチコアＣＰＵが標準処理を実行する際の処理負荷を予測するステップと、
    マルチコアＣＰＵにより実現されるモード切り替え手段が、前記処理負荷が閾値未満の場合、Ｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードで動作している２つ以上のＣＰＵコアの１つをＡｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替え、Ａｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り換えられない残りのＣＰＵコアに標準処理を継続させるステップと、
    故障診断中のＣＰＵコアにより実現される故障診断手段が、Ａｓｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替えられたＣＰＵコアを故障診断するステップと、
    前記モード切り替え手段は、前記故障診断手段により故障していないと判定されたＣＰＵコアをＳｙｍｍｅｔｒｉｃ Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇモードに切り替えるステップと、
    を有することを特徴とする故障診断方法。