JP2011022934A - 電子制御ユニット、異常検出方法 - Google Patents

Abstract

【課題】コストや車載スペースの増大をもたらすことなく監視マイコンを搭載可能にし、また、マイコンと監視マイコン間の通信時間を低減可能な電子制御ユニット及び異常検出方法を提供すること。
【解決手段】
車載装置に演算結果を提供する電子制御ユニット１００において、実在するＣＰＵ１１と、実在するＣＰＵ１１から仮想的なＣＰＵを構築する仮想ＣＰＵ構築手段１２、１４と、仮想的に構築された、第１の仮想ＣＰＵ（Ａ）１及び第２の仮想ＣＰＵ（Ａ）２と、を有し、演算結果を提供する前記第１の仮想ＣＰＵ（Ａ）１を、前記第２の仮想ＣＰＵ（Ａ）２が監視する、ことを特徴とする。
【選択図】図３

Description

本発明は、車両に搭載される車載装置に演算結果を提供する電子制御ユニット等に関し、特に、電子制御ユニットの異常を検出する電子制御ユニット及び異常検出方法に関する。

車両にはマイコンを実体とする種々の電子制御ユニットが搭載されているが、マイコン上で動作するアプリケーションはソフトウェアであるため、リソース不足、無限ループ、ノイズ等、特殊な状況の発生等により、マイコンが正常に動作することが困難になる場合がある。そこで、マイコンが異常検出プログラムを実行してマイコンが正常に動作していないことを検出する技術が考えられている（例えば、特許文献１参照。）。特許文献１には、オペレーティングシステムから取得したアプリケーションの動作情報（プロセスの動作状況、状態継続時間、コンテキストスイッチ回数）からアプリケーションの異常を検出する異常検出方法が開示されている。しかしながら、このような異常検出プログラムを用いた方法は、レジスタ操作等の具体的なタスクが実行されているか否かの確認が困難である。また、マイコンがアプリケーションと別に異常検出プログラムを実行するので、マイコンの負荷が大きいという問題がある。

また、マイコンを監視するための監視用の監視マイコンを設けることで、マイコンが正常に動作していないことを検出する技術が利用されている。
図１は、従来のマイコン監視システムの一例を示す図である。電子制御ユニット上にマイコンに接続された監視マイコンが配置されている。この監視マイコンはいわゆるウォッチドッグタイマと同様の態様でマイコンを監視する。マイコンは、定期的に監視マイコンのレジスタにフラグを立て、監視マイコンはフラグが立ってからの経過時間を計測する。監視マイコンは、経過時間が閾値を超えるとマイコンが正常に動作していないことを検出して、例えばマイコンをリセットする。

特開２００６−２７７１１５号公報

しかしながら、図１のように監視マイコンを設けると、適切なタイミングでマイコンをリセットすることが困難な場合があった。これは、マイコンと監視マイコンとが比較的低速なシリアル通信等を用いて通信していたため、監視マイコンがリセットしようとする際にある程度の時間がかかってしまっていたためである。

また、監視マイコンをマイコンとは別に搭載することは、コストや車載スペースの増大をもたらし、さらに監視マイコン用に搭載するソフトウェア開発に工数が発生するという問題があった。これは、マイコンと監視マイコンは設計が異なるため、マイコンとは別に監視マイコンのための開発環境を整備する必要があるためである。

本発明は、上記課題に鑑み、コストや車載スペースの増大をもたらすことなく監視マイコンを搭載可能にし、また、マイコンと監視マイコン間の通信時間を低減可能な電子制御ユニット及び異常検出方法を提供することを目的とする。

上記課題に鑑み、本発明は、車載装置に演算結果を提供する電子制御ユニットにおいて、実在するＣＰＵと、実在するＣＰＵから仮想的なＣＰＵを構築する仮想ＣＰＵ構築手段と、仮想的に構築された、第１の仮想ＣＰＵ及び第２の仮想ＣＰＵと、を有し、演算結果を提供する第１の仮想ＣＰＵを、第２の仮想ＣＰＵが監視する、ことを特徴とする。

コストや車載スペースの増大をもたらすことなく監視マイコンを搭載可能にし、また、マイコンと監視マイコン間の通信時間を低減可能な電子制御ユニット及び異常検出方法を提供することができる。

従来のマイコン監視システムの一例を示す図である。 電子制御ユニットの構造を概念的に説明する図の一例である。 ＥＣＵの概略構成図の一例である（実施例１）。 ＥＣＵが異常を検出する手順を示すフローチャート図の一例である（実施例１）。 異常検出システムの概略構成図の一例である（実施例２）。 ＥＣＵの機能ブロック図の一例である。 一方のEＣＵが他方のＥＣＵの異常を検出する手順を示すフローチャート図の一例である。 ３つの仮想ＣＰＵを有するＥＣＵの概略構成図の一例である（実施例３）。 ＥＣＵが論理積をロジックにして異常を検出する手順を示すフローチャート図の一例である（実施例３）。 ＥＣＵが論理和をロジックにして異常を検出する手順を示すフローチャート図の一例である（実施例４）。 多数決により異常を検出するＥＣＵの概略構成図の一例である（実施例４）。 ＷＤＴユニットにより異常を検出するＥＣＵを示す図の一例である（実施例５）。 、ＷＤＴユニットによりVCPU(A)1の異常を検出する手順を示すフローチャート図の一例を示す（実施例５）。 VCPU(A)1を監視する仮想ＣＰＵを周期的に切り替えるＥＣＵの概略構成図の一例である（実施例６）。 ＥＣＵが監視する仮想ＣＰＵを周期的に切り替える手順を示すフローチャート図の一例である（実施例６）。 ＥＣＵが監視する仮想ＣＰＵの役割を周期的に切り替える手順を示すフローチャート図の一例である（実施例６）。 VCPU(A)1を監視する仮想ＣＰＵを非周期的に切り替えるＥＣＵ１００の概略構成図の一例である（実施例７）。 ＥＣＵが監視する仮想ＣＰＵを非周期的に切り替える手順を示すフローチャート図の一例である（実施例７）。 ＥＣＵが監視する仮想ＣＰＵの役割を非周期的に切り替える手順を示すフローチャート図の一例である（実施例７）。 多数決により異常を検出するＥＣＵの概略構成図の一例である（実施例８）。 ３以上の仮想ＣＰＵの監視結果の多数決により異常を検出するＥＣＵの概略構成図の一例である（実施例８）。 異常検出システムの概略構成図の一例である（実施例９）。 異常検出システムの概略構成図の一例である（実施例１０）。 監視用の仮想ＣＰＵを更に監視する仮想ＣＰＵを搭載したＥＣＵの概略構成図の一例である（実施例１１）。 ＥＣＵが異常を検出する手順を示すフローチャート図の一例を示す（実施例１１）。 実在する監視マイコンによりVCPU(A)1及びVCPU(A)2の異常を検出するＥＣＵ１００の概略構成図の一例である（実施例１２）。

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

図２は、本実施形態の電子制御ユニットの構造を概念的に説明する図の一例である。電子制御ユニット（以下、ＥＣＵ（Electronic Control Unit）という）は、下層から順にハードウェアリソース１１、ＯＳ（Operating System）１５、アプリケーション１６という階層構造になっている。

ハードウェアリソース１１は、例えば、ＣＰＵ、Ｉ／Ｏ、ＲＡＭ、ＲＯＭ、ＡＳＩＣ（（Application Specific Integrated Circuit）、スイッチ素子、ＣＡＮ通信ユニット（ＣＯＭ１）等である。ＣＰＵはマルチコア型でもシングルコア型でもよい。

本実施形態では、ハードウェアリソースが仮想ＣＰＵモニタ１２を有する。仮想ＣＰＵモニタ１２は、複数のＯＳ１５に対して仮想的なハードウェアリソース１１を提供することで、ハードウェアリソース１１の競合が生じないようＯＳ１５からの使用要求を調停する。ＯＳ１５は仮想的なハードウェアリソース１１を物理的なハードウェアであると認識して動作する。

このような仮想ＣＰＵの実装方法としては、ハードウェア・マルチスレッド型の実行環境が知られている。ハードウェア・マルチスレッドとは、命令バッファ、レジスタファイルをそれぞれ複数備え、これらとＡＬＵ（Arithmetic Logic Unit)等との接続を切り変えて命令を実行する構造をいう。したがって、「仮想」ＣＰＵと称されても、物理的に存在する回路により演算結果を提供する。

一般的なＯＳ１５は、ハードウェアリソース（特にＣＰＵ）１１に自分のコードを最も高い特権モードで実行するよう要求し、また、アプリケーション１６は低い特権モードでコードを実行するよう要求する。仮想ＣＰＵモニタ１２は、ハードウェアリソース１１上で、ＯＳ１５が普段実行される最も高い特権モードよりも更に高い特権モードで実行される。仮想ＣＰＵモニタ１２がこのような特殊な特権モードで実行されると、仮想ＣＰＵモニタ１２はＯＳ１５に、ＯＳ１５を最も高い特権モードで実行していることを示す情報を送る。これにより、ＯＳ１５にとってはＯＳ１５が最も高い特権モードで実行されているように見える。

こうすることで、ＯＳ１５が実行要求した、ハードウェアリソース１１を直接制御するような特権命令を仮想ＣＰＵモニタ１２が受け取り、ＯＳ間の競合を回避できるようになる。したがって、ＯＳ１５にはハードウェアリソース１１を独占しているように見え、各ＯＳ１５にはそれぞれ仮想的なＣＰＵ（以下、仮想ＣＰＵ１３という）が存在していることと同等になる。仮想ＣＰＵ１３を、以下の実施例ではＶＣＰＵ（Virtual ＣＰＵ）と表記した。

このように複数の仮想ＣＰＵ１３はハードウェアリソース１１を共有できるので、複数のＯＳ１５を同時に実行することができる。図では２つしかＯＳ１５がないが、図２と同様の構造で３以上のＯＳ１５を実行することができる。

また、仮想ＣＰＵモニタ１２は、ＯＳ１５を適宜切り替えてハードウェアリソース１１で実行している。これは、ハードウェアリソース１１に制約がある場合（例えば、ＣＰＵが1つしかないような場合）、ある瞬間に動作しているＯＳ１５は１つのみとなるためである。

仮想ＣＰＵモニタ１２は、例えば、時間毎又はＯＳ１５からの要求により一方のＯＳ(A)1から他方のＯＳ(A)2に、実行するＯＳ１５を切り替える場合、切り替える直前のＣＰＵのすべてのレジスタ値（プログラムカウンタ、命令ンレジスタ、汎用レジスタ等）を待避する（使用するレジスタファイルを切り替える）。保存するデータ構造が、仮想ＣＰＵ制御構造１４であり、ここにはＯＳ１５実行時のレジスタ値、仮想ＣＰＵモニタ１２実行時のレジスタ値、の記憶エリアがある。ＯＳ１５を切り替える際、仮想ＣＰＵモニタ１２は、一方のＯＳ(A)1のレジスタ値を仮想ＣＰＵ制御構造１４へ退避し、他方のＯＳ(A)2の仮想ＣＰＵ制御構造１４の内容のレジスタへの復帰する、一連の処理を実行する。

このレジスタの退避・復帰の処理はハード的に行われるので、１〜数クロックで終了する。したがって、従来、例えばＯＳ１５がコンテキストの切り替えを行うような場合と比べて極めて短時間で一方の仮想ＣＰＵ(A)1から他方の仮想ＣＰＵ(A)2へ切り替えが終了する。このため、外部からは複数の（仮想）ＣＰＵ又はＯＳ１５が同時に動作しているように見える。

ＯＳ１５は例えば、ＯＳＥＫ（Open system together with interfaces for automotive electronics）、μITRON、ＬＩＮＵＸ等、汎用的なＯＳでもよいし、独自に設計されたＯＳでもよい。また、ＯＳ１５上では各種のアプリケーション１６が稼働する。本実施形態では、アプリケーション１６が正常に動作していないことを検出するため、少なくとも１つのアプリケーション１６は監視プログラム(A)2になる。監視されるアプリケーション(A)1は例えば、エンジン制御、ブレーキ制御、トランスミッション制御、走行用モータ制御、ナビゲーション用のプログラムである。以下では両者を区別して、実処理を行うプログラムを単にアプリケーション(A)1といい、正常に動作していないことを検出するプログラムを監視プログラム(A)2という。また、正常に動作していないことを検出することを、単に「異常を検出する」という。

図３（ａ）は、ＥＣＵ１００の概略構成図の一例を示す。ＥＣＵ１００は、基板上に実装されたマイコンを実体とし、マイコンはＣＰＵ（Ａ）及びＣＯＭ１を有する。ＣＰＵ（Ａ）及びＣＯＭ１はハードウェアリソース１１を実体とする。ＲＡＭ、Ｉ／Ｏ等のハードウェアリソース１１は省略した。ＣＯＭ１は、ＣＡＮ（Controller Area Network）、FlexRay又はＬＩＮ（Local Interconnect Network）等の車載ＬＡＮ１７に接続され、他のＥＣＵ１００と通信する通信ユニットである。

ＣＰＵ（Ａ）上に記載されたVCPU(A)1とVCPU(A)2が仮想ＣＰＵ１３である。すなわち、VCPU(A)1とVCPU(A)2は、例えばＯＳ１５、アプリケーション(A)1又は監視プログラム(A)2から存在するように見える仮想的なＣＰＵである。図３（ａ）では、VCPU(A)1上でアプリケーション(A)1が、VCPU(A)2上で監視プログラム(A)2が実行されるものとする。

監視プログラム(A)2は、VCPU(A)1上で実行されているアプリケーション(A)1が、リソース不足や無限ループ、デッドロック等の何らかの要因で、正常な動作をしていない場合に、VCPU(A)1にリセット要求を出力する。リセット要求は、例えばVCPU(A)1のハードウェアリセット端子をアクティブにすることをいう。すなわち、ハード的にVCPU(A)1のみをリセットできる。正常に動作しているか否かは、VCPU(A)1が一定周期でVCPU(A)2のレジスタ（VCPU(A)2＿checkreg２１）にアクセスしている否かにより、VCPU(A)2が判定する。VCPU(A)1が一定周期でVCPU(A)2＿checkreg２１にアクセスしていない場合、VCPU(A)2はVCPU(A)1をリセットする。

図３（ｂ）は、ＥＣＵ１００の機能ブロック図の一例を示す。図３（ｂ）の機能ブロック図は、VCPU(A)1がアプリケーション(A)1を、VCPU(A)2が監視プログラム(A)2をそれぞれ実行することで実現される。

実処理部６１Ａはアプリケーション(A)1の本来の処理を実行するブロックである。書き込み部６２Ａは、VCPU(A)2のVCPU(A)2＿checkreg２１に所定値「ＦＦｈ」（ｈ：１６進数）を書き込む。書き込みは一定周期内に行われなければ異常が検出されてしまうので、書き込み部６２Ａは、一定周期毎に繰り返し、実処理部６１Ａから呼び出されて実行される。呼び出された書き込み部６２Ａは、VCPU(A)2＿checkreg２１に所定値「ＦＦｈ」を書き込むと、実処理部６１Ａに処理を戻す。したがって、実処理部６１Ａが正常に動作していれば、書き込み部６２ＡがVCPU(A)2＿checkreg２１に所定値「ＦＦｈ」を書き込むことができる。一方、実処理部６１Ａが正常に動作していない場合、書き込み部６２Ａが呼び出されないので、一定周期内にVCPU(A)2＿checkreg２１に所定値「ＦＦｈ」を書き込むことができない。

レジスタ値検出部６４Ａは、書き込み部６２ＡがVCPU(A)2＿checkreg２１に所定値「ＦＦｈ」を書き込んだ直後にVCPU(A)2＿checkreg２１の値を検出して、「ＦＦｈ」が書き込まれているか否かを判定する。書き込み部６２Ａが書き込んだ直後に、レジスタ値検出部６４ＡがVCPU(A)2＿checkreg２１の値を検出するため、レジスタ値検出部６４Ａは書き込み部６２Ａと同期をとる。そして、レジスタ値検出部６４Ａは書き込みのタイミングから少しだけ遅らせて、書き込みと同じ一定周期でVCPU(A)2＿checkreg２１の値を検出する。

VCPU(A)2＿checkreg２１に「ＦＦｈ」が書き込まれている場合、レジスタ値検出部６４Ａはレジスタ値初期化部６６ＡにVCPU(A)2＿checkreg２１の初期化を要求する。レジスタ値初期化部６６ＡはVCPU(A)2＿checkreg２１に「００ｈ」を書き込む。

また、レジスタ値検出部６４ＡがVCPU(A)2＿checkreg２１に「００ｈ」が書き込まれていることを検出した場合、レジスタ値検出部６４Ａはリセット部６５ＡにVCPU(A)1のリセットを要求する。リセット部６５ＡはVCPU(A)1にリセットをかける。リセットをかける方法は、上記のようにハードウェア的にリセットしてもよいし、ソフトウェアによるリセット（ソフトウェアリセットレジスタに値を書き込むことでVCPU(A)1のみリセットする）を用いてもよい。

図４は、本実施例のＥＣＵ１００が異常を検出する手順を示すフローチャート図の一例である。図４の手順は、例えばイグニッションがオンになるか又は電気自動車やハイブリッド車の場合はメインシステムがオンになると一定周期毎に繰り返しスタートされる。スタートのタイミングは以下の実施例に共通である。

まず、VCPU(A)1の書き込み部６２Ａは、一定周期毎にVCPU(A)2のVCPU(A)2＿checkreg２１に「ＦＦh」を書き込む（Ｓ１０）。

VCPU(A)2のレジスタ値検出部６４Ａは、VCPU(A)2＿checkreg２１に「ＦＦh」が書き込まれているか否かを判定する（Ｓ２０）。

VCPU(A)2＿checkreg２１に「ＦＦh」が書き込まれている場合（Ｓ２０のＹｅｓ）、一定周期毎にVCPU(A)1がVCPU(A)2＿checkreg２１にアクセスしていることになるので、VCPU(A)2のレジスタ値初期化部６６ＡはVCPU(A)2＿checkreg２１に「００ｈ」を書き込む（Ｓ３０）。その後、VCPU(A)2は一定周期の間、待機している（Ｓ４０）。

VCPU(A)2＿checkreg２１に「ＦＦh」が書き込まれていない場合（Ｓ２０のＮ０）、一定周期毎にVCPU(A)1がVCPU(A)2＿checkreg２１にアクセスしていないことになるので、VCPU(A)2のリセット部６５ＡがVCPU(A)1をリセットする（Ｓ５０）。これにより、VCPU(A)1が再起動する。以降は、図４の処理を繰り返す（Ｓ６０）。なお、一定周期が経過しても再起動中は、VCPU(A)2はVCPU(A)1をリセットしない。こうすることで、リセットが繰り返されることを防止する。

以上説明したように、本実施例のＥＣＵ１００は、物理的な監視マイコンを用いることなく、アプリケーション(A)1が正常に実行されているか否かを監視することができる。VCPU(A)1とVCPU(A)2は同じハードウェアリソース１１を実体とするので、機能上は複数のＣＰＵであっても、車載スペースの増大をもたらすことがない。また、監視側のみ仮想ＣＰＵ１３を用いてもよいが、VCPU(A)1とVCPU(A)2とは同じハードウェアリソース１１を実体とするので、監視される側と監視する側のＣＰＵをいずれも仮想ＣＰＵ１３とすることで、監視される側の物理的なＣＰＵを搭載する必要が無く車載スペースをより効率的に利用できる。

また、VCPU(A)1とVCPU(A)2は同じハードウェアリソース１１を共有するので、VCPU(A)2とVCPU(A)1の通信速度は高速になる。したがって、異常が検出されてから短い時間で、VCPU(A)2がVCPU(A)1をリセットすることができる。

図５は、本実施例の異常検出システム２００の概略構成図の一例を示す。図５において図３（ａ）と同一部には同一の符号を付しその説明は省略する。図５では、ＥＣＵ１００ＡとＥＣＵ１００ＢがＬＡＮ１を介して接続されている。このうち、ＥＣＵ１００Ａの構成は図３（ａ）と同様である。

ＥＣＵ１００Ｂは、基板上に実装されたマイコン２を実体とし、マイコン２はＣＰＵ（Ｂ）及びＣＯＭ２を有する。ＣＰＵ（Ｂ）上にあるVCPU(B)1とVCPU(B)2が仮想ＣＰＵ１３である。したがって、VCPU(B)1とVCPU(B)2は、例えばＯＳ１５、アプリケーション(A)1又は監視プログラム(A)2から存在するように見える仮想的なＣＰＵである。図５（ａ）と図５（ｂ）では、VCPU(B)1上でアプリケーション(A)1が、VCPU(B)2上で監視プログラム(A)2が実行されるものとする。

かかる構成において、本実施例では、ＥＣＵ１００ＢがＥＣＵ１００Ａの異常を検出し、ＥＣＵ１００ＡがＥＣＵ１００Ｂの異常を検出する。
図６は、ＥＣＵ１００の機能ブロック図の一例を示す。なお、図６において図３（ｂ）と同一部には同一の符号を付しその説明は省略する。

VCPU(A)1の書き込み部６２Ａは、VCPU(B)2のVCPU(B)2＿checkreg２２に所定値「ＦＦｈ」を書き込む。書き込み部６２Ａの実装は実施例１と同じであるが、書き込み部６２ＡはＬＡＮ１経由で書き込むので、書き込み部６２Ａは書き込むための情報を格納したフレームをＣＯＭ１からＥＣＵ１００に送信する。実処理部６１Ａが正常に動作していれば、書き込み部６２ＡがVCPU(B)2＿checkreg２２に所定値「ＦＦｈ」を一定周期毎に書き込むことができる。実処理部６１Ａが正常に動作していない場合、書き込み部６２Ａは一定周期内にVCPU(B)2＿checkreg２２に所定値「ＦＦｈ」を書き込むことができない。

VCPU(B)2のレジスタ値検出部６４Ｂは、書き込み部６２ＡがVCPU(B)2＿checkreg２２に所定値「ＦＦｈ」を書き込んだ直後にVCPU(B)2＿checkreg２２の値を検出して、「ＦＦｈ」が書き込まれているか否かを判定する。レジスタ値検出部６４Ｂは、書き込みの直後にVCPU(B)2＿checkreg２２の値を検出するため、書き込み部６２Ａとの間で書き込みのタイミングを定めている。そして、レジスタ値検出部６４Ｂは、ＬＡＮ１を介した通信の時間に起因した遅延時間を想定し、定めたタイミングから少し遅れて一定周期でVCPU(B)2＿checkreg２２の値を検出する。

VCPU(B)2＿checkreg２２に「ＦＦｈ」が書き込まれている場合、レジスタ値検出部６４Ｂはレジスタ値初期化部６６ＢにVCPU(B)2＿checkreg２２の初期化を要求する。レジスタ値初期化部６６ＢはVCPU(B)2＿checkreg２２に「００ｈ」を書き込む。

レジスタ値検出部６４ＢがVCPU(B)2＿checkreg２２に「００ｈ」が書き込まれていることを検出した場合、レジスタ値検出部６４Ｂはリセット部６５ＢにVCPU(A)1のリセットを要求する。リセット部６５ＢはVCPU(A)1にリセットをかける。リセットをかける方法は、ハードウェア的なリセットでもよいが、ＬＡＮ１を経由しているので、ソフトウェアによるリセットを用いることが好適となる。

また、VCPU(B)１の書き込み部６２Ｂは一定周期毎に、VCPU(A)2のVCPU(A)2＿checkreg２１に所定値「ＦＦｈ」を書き込む。実処理部６１Ｂが正常に動作していれば、書き込み部６２ＢがVCPU(A)2＿checkreg２１に所定値「ＦＦｈ」を書き込むことができる。実処理部６１Ｂが正常に動作していない場合、書き込み部６２Ｂは一定周期内にVCPU(A)2＿checkreg２１に所定値「ＦＦｈ」を書き込むことができない。

レジスタ値検出部６４Ａは、書き込み部６２ＢがVCPU(A)2＿checkreg２１に所定値「ＦＦｈ」を書き込んだ直後にVCPU(A)2＿checkreg２１の値を検出して、「ＦＦｈ」が書き込まれているか否かを判定する。「書き込みの直後」のタイミングを決定する方法は、ＶＣＰＵ（Ｂ）２のレジスタ値検出部６４Ｂと同じである。

VCPU(A)2＿checkreg２１に「ＦＦｈ」が書き込まれている場合、レジスタ値検出部６４Ａはレジスタ値初期化部６６ＡにVCPU(A)2＿checkreg２１の初期化を要求する。レジスタ値初期化部６６ＡはVCPU(A)2＿checkreg２１に「００ｈ」を書き込む。レジスタ値検出部６４ＡがVCPU(A)2＿checkreg２１に「００ｈ」が書き込まれていることを検出した場合、レジスタ値検出部６４Ａはリセット部６５ＡにVCPU(Ｂ)１のリセットを要求する。リセット部６５ＡはVCPU(B)1にリセットをかける。リセットをかける方法は、ハードウェア的なリセットでもよいが、ＬＡＮ１を経由しているので、ソフトウェアによるリセットを用いることが好適となる。

このように、アプリケーション(A)1や監視プログラム(A)2が増大しても、仮想ＣＰＵ１３の場所や数が変わるだけで、アプリケーション(A)1や監視プログラム(A)2の構成は同じにすることができる。

図７（ａ）はＥＣＵ１００ＢがＥＣＵ１００Ａの異常を検出する手順を示すフローチャート図の一例である。まず、VCPU(A)1の書き込み部６２ＡはVCPU(B)2のVCPU(B)2＿checkreg22に一定周期毎に「ＦＦh」を書き込む（Ｓ１０）。VCPU(B)2のレジスタ値検出部６４Ｂは一定周期毎にVCPU(B)2＿checkreg22の値を検出して、「ＦＦh」が書き込まれているか否かを判定する（Ｓ２０）。

VCPU(B)2＿checkreg22に「ＦＦｈ」が書き込まれている場合（Ｓ２０のＹｅｓ）、VCPU(B)2のレジスタ値初期化部６６ＢはVCPU(B)2＿checkreg22に「００ｈ」を書き込む（Ｓ３０）。その後、VCPU(B)2は一定周期の間、待機している（Ｓ４０）。その後、VCPU(B)2は元の状態に戻る（リターン）。

VCPU(B)2＿checkreg22に「ＦＦｈ」が書き込まれていない場合（Ｓ２０のＮｏ）、VCPU(B)2のリセット部６５ＢはVCPU(A)1にリセットをかける（Ｓ５０）。VCPU(A)1が再起動するので、VCPU(A)1は元の状態に戻る（リターン）。以降は、図７（ａ）の処理を繰り返す（Ｓ６０）。

図７（ｂ）はＥＣＵ１００ＡがＥＣＵ１０Ｂの異常を検出する際の手順を示すフローチャート図の一例である。同様に、VCPU(B)1の書き込み部６２ＢはVCPU(A)2のVCPU(A)2＿checkreg２１に一定周期毎に「ＦＦh」を書き込む（Ｓ１０）。VCPU(A)2のレジスタ値検出部６４Ａは一定周期毎にVCPU(A)2＿checkreg２１の値を検出して、「ＦＦｈ」が書き込まれているか否かを判定する（Ｓ２０）。

VCPU(A)2＿checkreg２１に「ＦＦｈ」が書き込まれている場合（Ｓ２０のＹｅｓ）、VCPU(A)2のレジスタ値初期化部６６ＡはVCPU(A)2＿checkreg２１に「００ｈ」を書き込む（Ｓ３０）。その後、VCPU(A)2は一定周期の間、待機している（Ｓ４０）。その後、VCPU(A）2は元の状態に戻る（リターン）。

VCPU(A)2＿checkreg２１に「ＦＦｈ」が書き込まれていない場合（Ｓ２０のＮｏ）、VCPU(A)2のリセット部６５ＡはVCPU(B)1にリセットをかける（Ｓ５０）。VCPU(B)1が再起動するので、VCPU(B)1は元の状態に戻る（リターン）。以降は、図７（ｂ）の処理を繰り返す（Ｓ６０）。

本実施例によれば、実施例１の効果に加え、ＬＡＮ１を介して接続された２つのＥＣＵ１００ＡとＥＣＵ１００Ａ間で異常を検出することができる。ノイズにより一方のＥＣＵ１００Ａに異常が生じ、アプリケーション(A)1だけでなく監視プログラム(A)2にも異常が生じても、他方のＥＣＵ１００Ｂの監視プログラム(A)2によりアプリケーション(A)1の異常を検出できるので、信頼性を向上できる。

本実施例では、２つの仮想ＣＰＵ１３により１つの仮想ＣＰＵ１３の異常を検出するＥＣＵ１００について説明する。

図８（ａ）、図8（ｂ）は、３つの仮想ＣＰＵ１３を有するＥＣＵ１００の概略構成図の一例を示す。図８では、VCPU(A)1がアプリケーション(A)1を実行し、VCPU(A)2とVCPU(A)3とがそれぞれ監視プログラム(A)2を実行する。そして、ＥＣＵ１００は以下のいずれかのロジックで、異常を検出する。
（１）論理積
（２）論理和

〔論理積〕
図８（ａ）は論理積により異常を検出するＥＣＵ１００を示す図である。VCPU(A)2はＡＮＤ回路２３と接続されており、VCPU(A)3もＡＮＤ回路２３と接続されている。そして、ＡＮＤ回路２３とVCPU(A)1が接続されている。

まず、VCPU(A)1はVCPU(A)2のVCPU(A)2＿checkreg２１に一定周期毎に「ＦＦh」を書き込む。また、VCPU(A)1はVCPU(A)3のVCPU(A)3＿checkreg２４に一定周期毎に「ＦＦh」を書き込む。

VCPU(A)2は一定周期毎にVCPU(A)2＿checkreg２１の値を検出して、「ＦＦｈ」が書き込まれているか否かを判定する。「ＦＦh」が書き込まれていない場合、VCPU(A)2はリセット要求(A)2をＡＮＤ回路２３に入力する。同様に、VCPU(A)3は一定周期毎にVCPU(A)3＿checkreg２４の値を検出して、「ＦＦｈ」が書き込まれているか否かを判定する。「ＦＦh」が書き込まれていない場合、VCPU(A)3はリセット要求(A)3をＡＮＤ回路２３に入力する。

ＡＮＤ回路２３は、リセット要求(A)2とリセット要求(A)3の両方が入力されるとリセット要求をVCPU(A)1に出力する。したがって、図8（ａ）のＥＣＵ１００Ａは、論理積を異常の検出ロジックにすることができる。

ＡＮＤ回路２３はハードウェアリソース１１に含まれている。また、ＡＮＤ回路２３を、VCPU(A)2又はVCPU(A)3がソフトウェア的に実装してもよい。この場合、VCPU(A)2又はVCPU(A)3の監視プログラム(A)2が例えば２つのフラグを監視して、両方ともオンになるとリセット要求をVCPU(A)1に出力する。

図９は、ＥＣＵ１００Ａが論理積をロジックにして異常を検出する手順を示すフローチャート図の一例である。

まず、VCPU(A)1がVCPU(A)2のVCPU(A)2＿checkreg２１に一定周期毎に「ＦＦh」を書き込む（Ｓ１０Ａ）。VCPU(A)1がVCPU(A)2のVCPU(A)2＿checkreg２１に「ＦＦh」を書き込んだ直後、VCPU(A)2がVCPU(A)2＿checkreg２１に「ＦＦh」が書き込まれているか否か判定する（Ｓ２０Ａ）。

「ＦＦh」がVCPU(A)2＿checkreg２１に書き込まれている場合（Ｓ２０ＡのＹｅｓ）、VCPU(A)2がVCPU(A)2＿checkreg２１に「００ｈ」を書き込む（Ｓ３０Ａ）。「ＦＦh」がVCPU(A)2＿checkreg２１に書き込まれていない場合（Ｓ２０ＡのＮｏ）、VCPU(A)2がリセット要求(A)2をＡＮＤ回路２３に出力する（Ｓ４０Ａ）。

また、VCPU(A)1はVCPU(A)3のVCPU(A)3＿checkreg２４に一定周期毎に「ＦＦh」を書き込む（Ｓ１０Ｂ）。VCPU(A)1がVCPU(A)2＿checkre２１ とVCPU(A)3＿checkreg２４に「ＦＦh」を書き込むタイミングは、好ましくは同時であるが、少なくとも一定周期以上ずれないように調整されている。VCPU(A)2はVCPU(A)2＿checkreg２１の値が「ＦＦh」でなければ一定周期毎にリセット要求(A)2を、VCPU(A)3はVCPU(A)3＿checkreg２４の値が「ＦＦh」でなければ一定周期毎にリセット要求(A)3を、出力するので、論理積をロジックに採用しても一定周期内に異常を検出できる。

VCPU(A)1がVCPU(A)3のVCPU(A)3＿checkreg２４に「ＦＦh」を書き込んだ直後、VCPU(A)3がVCPU(A)3＿checkreg２４に「ＦＦh」が書き込まれているか否か判定する（Ｓ２０Ｂ）。

「ＦＦh」がVCPU(A)3＿checkreg２４に書き込まれている場合（Ｓ２０ＢのＹｅｓ）、VCPU(A)3がVCPU(A)3＿checkreg２４に「００ｈ」を書き込む（Ｓ３０Ｂ）。「ＦＦh」がVCPU(A)3＿checkreg２４に書き込まれていない場合（Ｓ２０ＢのＮｏ）、VCPU(A)3がリセット要求(A)3をＡＮＤ回路２３に出力する（Ｓ４０Ｂ）。

これらの結果、ＡＮＤ回路２３がオンになると（Ｓ５０のＹｅｓ）、ＡＮＤ回路はVCPU(A)1にリセット要求を出力するので、VCPU(A)1は再起動する（Ｓ６０）。ＡＮＤ回路２３がオンにならなければ（Ｓ５０のＮｏ）、VCPU(A)1にリセット要求が出力されない。この場合、VCPU(A)1，VCPU(A)2及びVCPU(A)3は一定周期の間、待機している（Ｓ７０）。VCPU(A)1が再起動することで（Ｓ６０）、VCPU(A)1は元の状態に戻る（リターン）。また、一定周期の間、待機した後（Ｓ７０）、VCPU(A)1，VCPU(A)2及びVCPU(A)3は元の状態に戻る（リターン）。

このように、論理積を異常検出のロジックに採用することで、異常が生じている可能性が高い場合にのみVCPU(A)1をリセットすることができる。例えば、急な再起動が好ましくない制御を実行するＥＣＵ１００Ａをリセットするロジックに好適となる。すなわち、明らかに異常がある場合のみＥＣＵ１００Ａを再起動するので、ＥＣＵ１００の可用性を向上できる。

〔論理和〕
図８（ｂ）は論理和により異常を検出するＥＣＵ１００を示す図である。なお、図8（ｂ）において図8（ａ）と同一部には同一の符号を付しその説明は省略する。VCPU(A)2はＯＲ回路２５と接続されており、VCPU(A)3もＯＲ回路２５と接続されている。そして、ＯＲ回路２５とVCPU(A)1が接続されている。

まず、VCPU(A)1はVCPU(A)2のVCPU(A)2＿checkreg２１に一定周期毎に「ＦＦh」を書き込む。また、VCPU(A)1はVCPU(A)3のVCPU(A)3＿checkreg２４に一定周期毎に「ＦＦh」を書き込む。

ＯＲ回路２５は、リセット要求(A)2とリセット要求(A)3のいずれか又は両方が入力されるとリセット要求をVCPU(A)1に出力する。したがって、図8（ｂ）のＥＣＵ１００Ａは、論理和を異常の検出ロジックにすることができる。

なお、ＯＲ回路２５は、ハードウェアリソース１１に含まれている。また、ＯＲ回路２５を、VCPU(A)2又はVCPU(A)3がソフトウェア的に実装してもよい。この場合、VCPU(A)2又はVCPU(A)3の監視プログラム(A)2が例えば２つのフラグを監視して、いずれか又は両方がオンになるとリセット要求をVCPU(A)1に出力する。

図１０は、ＥＣＵ１００が論理和をロジックにして異常を検出する手順を示すフローチャート図の一例である。なお、図１０において図９と同じステップの説明は省略する。ステップＳ１０Ａ、Ｓ１０Ｂ〜Ｓ４０Ａ、Ｓ４０Ｂまでの処理は図１０と同じである。

Ｓ４０までの処理の結果、ＯＲ回路２５がオンになると（Ｓ５０のＹｅｓ）、VCPU(A)1にリセット要求が出力され、VCPU(A)1が再起動する（Ｓ６０）。なお、VCPU(A)1が再起動している間は、VCPU(A)2がリセット要求(A)2を出力することはなく、VCPU(A)3がリセット要求(A)3を出力することはない。

ＯＲ回路２５がオンにならなければ（Ｓ５０のＮｏ）、VCPU(A)1にリセット要求が出力されない。この場合、VCPU(A)1，VCPU(A)2及びVCPU(A)3は一定周期の間、待機している（Ｓ７０）。VCPU(A)1が再起動することで（Ｓ６０）、VCPU(A)1は元の状態に戻る（リターン）。また、一定周期の間、待機した後（Ｓ７０）、VCPU(A)1，VCPU(A)2及びVCPU(A)3は元の状態に戻る（リターン）。

このように、論理和を異常検出のロジックに採用することで、例えば、急に再起動してもよい制御を実行するＥＣＵ１００のＶＣＰＵ(A)1を早期にリセットできる。すなわち、異常の可能性がある場合にはＥＣＵ１００を再起動するので、ＥＣＵ１００の信頼性を向上できる。

実施例３では、２つのVCPU(A)2とVCPU(A)3の出力の論理積又は論理和で異常を検出したが、３以上の仮想ＣＰＵ（VCPU(A)2、VCPU(A)3、…、VCPU(A)n）１３の出力に、論理積又は論理和のロジックを適用して、VCPU(A)1の異常を検出し、以上が検出された場合にはVCPU(A)1をリセットしてもよい。この場合は、ＡＮＤ回路２３又はＯＲ回路２５と各仮想ＣＰＵ１３を接続するだけでよい。

また、ＥＣＵ１００は、VCPU(A)2〜VCPU(A)nのように多数の仮想ＣＰＵ１３がVCPU(A)1を関している場合、VCPU(A)2〜VCPU(A)nの出力の多数決から、異常を検出することができる。

図１１は、多数決により異常を検出するＥＣＵ１００を示す図の一例である。なお、図１１において図８（ａ）と同一部には同一の符号を付しその説明は省略する。VCPU(A)2、VCPU(A)3、…、VCPU(A)nは多数決回路２７と接続されている。

多数決回路２７は、一定周期内に入力されたリセット要求(A)2、リセット要求Ａ（３）、…リセット要求(A)nの数（以下、リセット要求数という）をカウントする。リセット要求数が所定値（例えば、VCPU(A)2等の数の半分）以上の場合、多数決回路２７は、リセット要求をVCPU(A)1に出力する。所定値は多数決回路２７に予め記憶されている。多数決回路２７は、一定周期内に入力されるリセット要求数をカウントして所定値との比較結果を出力し、所定値未満の場合は、カウントしたリセット要求数をクリアする処理を繰り返す。こうすることで、多数決回路２７は、一定周期毎に、多数決によりＶＣＰＵ(A)1をリセットするか否かを決定できる。なお、多数決回路２７も、ハードウェアリソース１１に含まれている。多数決回路２７をソフトウェア的に実装してもよい。

なお、フローチャート図は図９又は図１０において、ステップＳ５０の処理が「多数決が成立した？」となるだけなので省略した。

本実施例のＥＣＵ１００によれば、ｎ個のＶＣＰＵ（Ａ）の出力による多数決により異常を検出するので、異常があるか否かを正確に判定することができる。また、所定値を変えることで、VCPU(A)1をリセットしやすくして信頼性を向上したり、リセットしにくくして可用性を向上させるなどを調整できる。

これまで説明した異常の検出方法はウォッチドッグタイマ（ＷＤＴ）と親和性がある。そこで、本実施例ではＷＤＴユニット１８がVCPU(A)1をリセットするように構成することで、ＷＤＴを実現するＥＣＵ１００について説明する。

図１２は、ＷＤＴユニット１８により異常を検出するＥＣＵ１００を示す図の一例である。図１２のＷＤＴユニット１８は、WDT_reg２８とリセット要求をVCPU(A)1に出力するリセット回路（不図示）を有する。ＷＤＴユニット１８にはこれまでの実施例で説明した一定周期に対応するタイマ値が記憶されている。ＷＤＴユニット１８は、時間の計測を常に継続しているが、WDT_reg２８に「ＦＦh」が書き込まれると、計測した時間をいったんゼロにして時間の計測を再開する。WDT_reg２８に「ＦＦh」が書き込まれる前に、計測した時間がタイマ値を超えると、ＷＤＴユニット１８はVCPU(A)1にリセット信号を出力する。

図１２では、VCPU(A)2にＷＤＴユニット１８を配置した。ＷＤＴユニット１８はＩＣなど独立したハードウェアなので、実体はハードウェアリソース１１に含まれる。また、一般的なＥＣＵ１００では、ＷＤＴユニット１８はマイコン内になく、複数のＩＣを統合した統合ＩＣに実装されていることが多い。

図１３は、ＷＤＴユニット１８によりVCPU(A)1の異常を検出する手順を示すフローチャート図の一例を示す。

VCPU(A)1は、一定周期毎にＷＤＴユニット１８のWDT_reg２８に「ＦＦh」を書き込む（Ｓ１０）。ＷＤＴユニット１８は、に「ＦＦh」が書き込まれているか否かを判定する（Ｓ２０）。

WDT_reg２８に「ＦＦh」が書き込まれている場合（Ｓ２０のＹｅｓ）、ＷＤＴユニット１８はそれまで計測した時間をゼロに戻す（Ｓ３０）。

ついで、ＷＤＴユニット１８は計測時間がタイマ値（一定周期）以上か否かを判定する（Ｓ４０）。計測時間がタイマ値以上の場合（Ｓ４０のＹｅｓ）、ＷＤＴユニット１８がVCPU(A)1をリセットする（Ｓ５０）。これにより、VCPU(A)1が再起動する（Ｓ６０）。VCPU(A)1が再起動することで（Ｓ６０）、VCPU(A)1は元の状態に戻る（リターン）。

計測時間がタイマ値以上でない場合（Ｓ４０のＮｏ）、VCPU(Ｂ)2はステップＳ２０からの処理を繰り返す（リターン）。

本実施例によれば、広く利用されているＷＤＴユニット１８を仮想ＣＰＵ１３により実現することができる。

本実施例では、周期的にVCPU(A)1を監視する仮想ＣＰＵ１３を切り替えるＥＣＵ１００について説明する。一般に、同じＣＰＵに同じ処理を固定することは特定の回路に負荷が集中するため監視上好ましくないとされている。そこで、監視する仮想ＣＰＵ１３を切り替えることで、負荷が集中することを防止する。

図１４（ａ）は、VCPU(A)1を監視する仮想ＣＰＵ１３を切り替えるＥＣＵ１００の概略構成図の一例を示す。なお、図１４（ａ）において図８（ｂ）と同一部には同一の符号を付しその説明は省略する。ＥＣＵ１００は、監視用にVCPU(A)2とVCPU(A)3を有しているが、どちらか一方のみがアクティブで、他方が非アクティブになっている。アクティブとは、その仮想ＣＰＵ１３が、VCPU(A)2＿checkreg２１の監視、「００ｈ」の書き込み、リセット要求の出力、の一連の処理を実行していることをいう。

VCPU(A)2とVCPU(A)3を切り替えるにはいくつか方法があるが、例えばタイマ割込みを利用する。タイマは、切り替え時間毎に、タイマ割り込みをVCPU(A)1、VCPU(A)2及びVCPU(A)3それぞれに発生させる。VCPU(A)2がアクティブだった場合、タイマ割込みを検出したVCPU(A)1は「ＦＦh」の書き込み先をVCPU(A)2からVCPU(A)3に切り替える。また、タイマ割込みを検出したVCPU(A)2は監視プログラム(A)2の実行を中断する。また、タイマ割込みを検出したVCPU(A)3は監視プログラム(A)2の実行を開始する。すなわち、VCPU(A)2の監視プログラム(A)2とVCPU(A)3の監視プログラム(A)2を、例えばタスクスケジューリングにおける待機状態と実行状態に遷移させることで、VCPU(A)2とVCPU(A)3の一方のみをアクティブにすることができる。このような切り替えは、一般には仮想ＣＰＵモニタ１２のスケジューラの機能を利用することで実現できる。

図１５は、ＥＣＵ１００が監視する仮想ＣＰＵ１３を切り替える手順を示すフローチャート図の一例を示す。タイマ割込みが発生するまで、VCPU(A)1はアプリケーション(A)1を、VCPU(A)2は監視プログラム(A)2を実行している。

タイマがタイマ割込みを発生させると（Ｓ１０）、VCPU(A)1は「ＦＦh」の書き込み先をVCPU(A)2からVCPU(A)3に切り替える（Ｓ２０）。その後、VCPU(A)1はこの処理を繰り返し、「ＦＦh」の書き込み先をVCPU(A)３からVCPU(A)２に切り替える（リターン→Ｓ２０）。

また、タイマがタイマ割込みを発生させると（Ｓ１０）、VCPU(A)2は監視プログラム(A)2の実行を中断する（Ｓ３０）。その後、VCPU(A)2は監視プログラム(A)2の実行を再開する（リターン→Ｓ３０）。

また、VCPU(A)3は監視プログラム(A)2の実行を再開する（Ｓ４０）。その後、VCPU(A)３は監視プログラム(A)2の実行を再開する（リターン→Ｓ４０）。

こうすることで、周期的にＶＣＰＵ(A)1を監視する仮想ＣＰＵを切り替え、負荷を分散させることができる。

図１４（ｂ）は、ＥＣＵ１００の概略構成図の一例を示す。図１４（ｂ）のＥＣＵ１００は、VCPU(A)2とVCPU(A)3の役割を入れ替えながら、VCPU(A)1を監視している。

例えば、図１４（ｂ）の左図では、VCPU(A)1はVCPU(A)2のVCPU(A)2＿checkreg２１及びVCPU(A)3のVCPU(A)3＿checkreg２４に「ＦＦh」を書き込む。VCPU(A)2は、VCPU(A)2＿checkreg２１の値を読み出し「ＦＦh」が書き込まれているか否かを判定する。そして、VCPU(A)3も、VCPU(A)3＿checkreg２４の値を読み出し「ＦＦh」が書き込まれているか否かを判定する。

実施例１と同様に、VCPU(A)2＿checkreg２１に「ＦＦh」が書き込まれていない場合、VCPU(A)2はVCPU(A)1をリセットする。これに対し、VCPU(A)3は、VCPU(A)3＿checkreg２４に「ＦＦh」が書き込まれていない場合、VCPU(A)2にイベントの発生に伴う処理を要求する（以下、単にイベント要求という）。このイベント要求は、VCPU(A)1のリセットを要求するものである。このため、イベント要求を受信したVCPU(A)2はVCPU(A)1をリセットする。すなわち、VCPU(A)2とVCPU(A)3が多重にVCPU(A)1を監視していることになる。

図１４（ｂ）のＥＣＵ１００はこの役割分担を時間毎に切り替る。図１４（ｂ）の右図は役割を切り替えた後のＥＣＵ１００の一例を示している。すなわち、VCPU(A)1はVCPU(A)2のVCPU(A)2＿checkreg２１及びVCPU(A)3のVCPU(A)3＿checkreg２４にそれぞれ「ＦＦh」を書き込む。VCPU(A)3は、VCPU(A)3＿checkreg２４の値を読み出し「ＦＦh」が書き込まれているか否かを判定する。そして、VCPU(A)3＿checkreg２４に「ＦＦh」が書き込まれていない場合、VCPU(A)3はVCPU(A)1をリセットする。また、VCPU(A)2は、VCPU(A)2＿checkreg２１の値を読み出し「ＦＦh」が書き込まれているか否かを判定する。そして、VCPU(A)2＿checkreg２１に「ＦＦh」が書き込まれていない場合、VCPU(A)2はVCPU(A)3にイベントを要求する。イベント要求を受信したVCPU(A)3はVCPU(A)1をリセットする。なお、イベント要求は例えば割り込みの一種である。

このような役割の切り替えも、例えばタイマ割り込みを利用することで実現できる。タイマ割込みを検出したVCPU(A)1の処理に変化はない。これに対し、タイマ割込みを検出したVCPU(A)2はVCPU(A)2＿checkreg２１に「ＦＦh」が書き込まれていない場合の処理を、VCPU(A)1をリセットする処理から、イベント要求をVCPU(A)3に出力する処理に切り替える。

また、タイマ割込みを検出したVCPU(A)3は、VCPU(A)3＿checkreg２４に「ＦＦh」が書き込まれていない場合の処理を、VCPU(A)2にイベント要求を出力する処理から、VCPU(A)1をリセットする処理に切り替える。このような役割の切り替えは、例えばスケジューラが、タイマ割込みによりVCPU(A)2とVCPU(A)3が実行する監視プログラム(A)2の処理（タスク）を切り替えることで実現できる。

図１６は、ＥＣＵ１００が監視する仮想ＣＰＵ１３の役割を周期的に切り替える手順を示すフローチャート図の一例を示す。なお、図１６において図１５と同一ステップの説明は省略する。

タイマがタイマ割込みを発生させると（Ｓ１０）、VCPU(A)2はVCPU(A)2＿checkreg２１に「ＦＦh」が書き込まれていない場合の処理を、VCPU(A)1をリセットする処理から、イベント要求をVCPU(A)3に出力する処理に切り替える（Ｓ３０）。その後、VCPU(A)1はタイマからの割り込みをVCPU(A)３とVCPU(A)２に通知する（リターン）。VCPU(A)２は、VCPU(A)1から通知の度に、イベント要求をVCPU(A)3に出力する処理からVCPU(A)1をリセットする処理に切り替える（リターン→Ｓ３０）。

また、VCPU(A)3は、VCPU(A)3＿checkreg２４に「ＦＦh」が書き込まれていない場合の処理を、VCPU(A)2にイベント要求を出力する処理から、VCPU(A)1をリセットする処理に切り替える（Ｓ４０）。VCPU(A)２は、VCPU(A)1から通知の度に、VCPU(A)1をリセットする処理からVCPU(A)2にイベント要求を出力する処理に切り替える（リターン→Ｓ４０）。
こうすることで、周期的に、多重的な監視の手順を切り替え、負荷を分散させることができる。

本実施例のＥＣＵ１００によれば、VCPU(A)1を監視する仮想ＣＰＵ１３又は役割を周期的に切り替えることで、負荷を分散させることができる。また、VCPU(A)1を多重に監視していることになるので信頼性が向上する。

本実施例では、実施例６と同様の切り替えを、非周期的に実行するＥＣＵ１００について説明する。

図１７（ａ）は、VCPU(A)1を監視する仮想ＣＰＵを非周期的に切り替えるＥＣＵ１００の概略構成図の一例を示す。なお、図１７（ａ）において図１４（ａ）と同一部には同一の符号を付しその説明は省略する。構成上の違いはないが、図１７（ａ）では、アクティブな仮想ＣＰＵ１３を切り替えるトリガが図１６（ａ）と異なる。すなわち、実施例６では周期的に（例えばタイマ割り込みで）アクティブな仮想ＣＰＵ１３を切り替えたが、本実施例では何らかのイベントにより、アクティブな仮想ＣＰＵ１３を切り替える。

イベントには種々あるが、例えば、ハードウェア割り込み、例外の発生、フックの検出（ソフトウェアが指定した特定の事象が検出されること）等である。

このようなイベントを検出した、仮想ＣＰＵ１３、ＯＳ１５、又は、アプリケーション１６は、VCPU(A)1、VCPU(A)2及びVCPU(A)3にそれぞれに割り込みを発生させる。イベントが発生した後の処理は実施例６と同様である。

図１８は、ＥＣＵ１００が監視する仮想ＣＰＵ１３を非周期的に切り替える手順を示すフローチャート図の一例を示す。イベントが発生するまで、VCPU(A)1はアプリケーション(A)1を、VCPU(A)2及びVCPU(A)３は監視プログラム(A)2を実行している。

ハードウェアリソース１１、アプリケーション(A)1又はＯＳ１５はイベントの発生を検出し、VCPU(A)1、VCPU(A)2及びVCPU(A)3にそれぞれ割り込みを発生させる（Ｓ１０）。これにより、VCPU(A)1は「ＦＦh」の書き込み先をVCPU(A)2からVCPU(A)3に切り替える（Ｓ２０）。その後、VCPU(A)1はこの処理を繰り返し、「ＦＦh」の書き込み先をVCPU(A)3からVCPU(A)２に切り替える（リターン→Ｓ２０）。

また、VCPU(A)2は監視プログラム(A)2の実行を中断する（Ｓ３０）。その後、VCPU(A)2は監視プログラム(A)2の実行を再開する（リターン→Ｓ３０）。

また、VCPU(A)3は監視プログラム(A)2の実行を再開する（Ｓ４０）。その後、VCPU(A)３は監視プログラム(A)2の実行を再開する（リターン→Ｓ４０）。こうすることで、非周期的にＶＣＰＵ(A)1を監視する仮想ＣＰＵを切り替え、負荷を分散させることができる。

図１７（ｂ）は、監視する仮想ＣＰＵの役割を非周期的に切り替えるＥＣＵ１００の概略構成図の一例を示す。なお、図１７（ｂ）において図１４（ｂ）と同一部には同一の符号を付しその説明は省略する。図１７（ｂ）のＥＣＵ１００は、図１７（ａ）のＥＣＵ１００と同様にイベントの発生により、VCPU(A)2とVCPU(A)3の役割を切り替える。イベント発生後の処理は実施例６と同様である。

図１９は、ＥＣＵ１００が監視する仮想ＣＰＵ１３の役割を非周期的に切り替える手順を示すフローチャート図の一例を示す。

ハードウェアリソース１１、アプリケーション(A)1又はＯＳ１５はイベントの発生を検出し、VCPU(A)1、VCPU(A)2及びVCPU(A)3にそれぞれ割り込みを発生させる（Ｓ１０）。

VCPU(A)2はVCPU(A)2＿checkreg２１に「ＦＦh」が書き込まれていない場合の処理を、VCPU(A)1をリセットする処理から、イベント要求をVCPU(A)3に出力する処理に切り替える（Ｓ３０）。その後、VCPU(A)1はタイマからの割り込みをVCPU(A)３とVCPU(A)２に通知する（リターン）。VCPU(A)２は、VCPU(A)1から通知の度に、イベント要求をVCPU(A)3に出力する処理からVCPU(A)1をリセットする処理に切り替える（リターン→Ｓ３０）。

また、VCPU(A)3は、VCPU(A)3＿checkreg２４に「ＦＦh」が書き込まれていない場合の処理を、VCPU(A)2にイベント要求を出力する処理から、VCPU(A)1をリセットする処理に切り替える（Ｓ４０）。VCPU(A)２は、VCPU(A)1から通知の度に、VCPU(A)1をリセットする処理からVCPU(A)2にイベント要求を出力する処理に切り替える（リターン→Ｓ４０）。

こうすることで、非周期的に、多重的な監視の手順を切り替え、負荷を分散させることができる。

本実施例のＥＣＵ１００によれば、イベントの発生毎にVCPU(A)1を監視する仮想ＣＰＵ１３又は役割を切り替えることで、負荷を分散させることができる。また、VCPU(A)1を多重に監視していることになるので信頼性が向上する。なお、実施例６と本実施例を組み合わせ、周期的かつ非周期的にVCPU(A)1を監視する仮想ＣＰＵ１３を切り替えてもよいし、又は、多重的な監視の手順を切り替えてもよい。

実施例６又は７のように、仮想ＣＰＵ１３を切り替える構成を、３以上の仮想ＣＰＵ１３に対し適用することもできる。

図２０（ａ）は、多数決により異常を検出するＥＣＵ１００の概略構成図の一例である。なお、図２０（ａ）において図１１と同一部には同一の符号を付しその説明は省略する。図示するVCPU(A)2、VCPU(A)3、…、VCPU(A)nのうち、必ず1以上の仮想ＣＰＵ１３がアクティブであるが、必ず1以上の仮想ＣＰＵ１３はアクティブでない。例えば、図ではVCPU(A)n以外をアクティブな仮想ＣＰＵ１３とした。

そして、このＥＣＵ１００は、周期的又は非周期的にアクティブな仮想ＣＰＵ１３を繰り替える。例えば、切り替え時間が経過すると、図２０（ｂ）に示すように、ＥＣＵ１００はVCPU(A)nをアクティブにして、VCPU(A)2を非アクティブにする。こうすることで、負荷を分散しながら、常に一定数の仮想ＣＰＵ１３によりVCPU(A)1を監視することができる。

なお、周期的又は非周期的にアクティブとなるか非アクティブとなるかは、例えば次のように各仮想ＣＰＵ１３が決定する。タイマ割込みやイベントの発生による割り込みの回数を各仮想ＣＰＵ１３がカウントしておき、各仮想ＣＰＵ１３は、回数に応じてアクティブとなるか非アクティブを決定する。例えば、回数を仮想ＣＰＵ１３の数ｎで割って、その余りが０ならVCPU(A)1が、１ならVCPU(A)2が、…という規則に仮想ＣＰＵ１３が従うことで、仮想ＣＰＵ１３はアクティブとなるか非アクティブとなるかを決定できる。

また、図２０（ａ）の多数決定回路２７を用いずに、多数決でVCPU(A)1をリセットするか否かを決定することもできる。

図２１（ａ）は、３以上の仮想ＣＰＵ１３の監視結果の多数決により異常を検出するＥＣＵ１００の概略構成図の一例である。図２１（ａ）のＥＣＵ１００では、VCPU(A)1が、一定周期毎にVCPU(A)2、VCPU(A)3、…、VCPU(A)nにそれぞれ「ＦＦh」を書き込む。VCPU(A)2はVCPU(A)2＿checkreg２１に「ＦＦh」が書き込まれているか否かを判定し、書き込まれていなければイベント要求を記憶する。一方、VCPU(A)3はVCPU(A)3＿checkreg２４に「ＦＦh」が書き込まれているか否かを判定し、書き込まれていなければイベント要求をVCPU(A)2に出力する。VCPU(A)nはVCPU(A)n＿checkreg２６に「ＦＦh」が書き込まれているか否かを判定し、書き込まれていなければイベント要求をVCPU(A)2に出力する。

そして、VCPU(A)2は、一定周期内に入力されたリセット要求数をカウントする。リセット要求数が所定値以上の場合、VCPU(A)2は、リセット要求をVCPU(A)1に出力する。すなわち、VCPU(A)2はマスタＶＣＰＵとして多数決の判定処理を実行する。このように、多重的に各仮想ＣＰＵ１３がVCPU(A)1を監視して、多数決によりマスタＶＣＰＵとなるＶＣＰＵ(A)2が、リセットするか否かを決定できる。マスタＶＣＰＵとなった仮想ＣＰＵ１３の処理は監視プログラム(A)2に記述されている。

そして、ＥＣＵ１００は、マスタＶＣＰＵのＶＣＰＵ(A)2を別の仮想ＣＰＵ１３に切り替えることができる。切り替え方は図２０にて説明したＥＣＵ１００の切り替え方法と同様に、予め決定しておくことができる。各仮想ＣＰＵ１３は、タイマ割込みやイベントの発生による割り込みの回数を仮想ＣＰＵ１３の数ｎで割った、その余りに基づき、マスターとなるかならないかを決定する。

図２１（ｂ）は、マスタＶＣＰＵをVCPU(A)2からVCPU(A)3に切り替えたＥＣＵ１００の一例を示す図である。図示するように、マスタＶＣＰＵがＶＣＰＵ(A)2からＶＣＰＵ(A)3に変わっている。こうすることで、特定の仮想ＣＰＵ１３が多数決したり、ＶＣＰＵ(A)1をリセットするという同じ処理負荷が集中することを、分散させることができる。また、各ＣＰＵ１３が多重的にVCPU(A)1を監視するので、ＥＣＵ１００の信頼性を向上させることができる。

以上のように、本実施例のＥＣＵ１００は、実施例６又は実施例７の効果に加え、さらにＥＣＵ１００の信頼性を向上できる。

実施例２では、ＬＡＮ１に接続されたＥＣＵ１００ＡがＥＣＵ１００Ｂを、ＥＣＵ１００ＢがＥＣＵ１００Ａを、それぞれ監視する異常検出システム２００を説明した。

本実施例では、更に、階層的に形成されたＬＡＮ１とＬＡＮ２を介して、ＥＣＵ１００ＡがＥＣＵ１００Ｂを、ＥＣＵ１００ＢがＥＣＵ１００Ａを、それぞれ監視する異常検出システム２００について説明する。

図２２は、本実施例の異常検出システム２００の概略構成図の一例を示す。図２２において図５と同一部には同一の符号を付しその説明は省略する。図２２では、ＥＣＵ１００ＡはＬＡＮ１に、ＥＣＵ１００ＢはＬＡＮ２に、それぞれ接続されている。そして、ＬＡＮ１とＬＡＮ２は、Ｇ／Ｗ（ＧａｔｅＷａｙ）装置１９を介して接続されている。

Ｇ／Ｗ装置１９は、ＬＡＮ１とＬＡＮ２のプロトコルが異なる場合に、一方のＬＡＮ１（ＬＡＮ２）のプロトコルに従ったフォーマットの通信データを他方のＬＡＮ２（ＬＡＮ１）のプロトコルに従ったフォーマットの通信データに変換する。車載ＬＡＮ１７には、例えば、ＣＡＮ、FlexRay、ＬＩＮ等の種々のものがあるが、これらはフォーマットに互換性があるとは限らない。Ｇ／Ｗ装置１９は、異なるプロトコルのＬＡＮ１のＥＣＵ１００ＡがＬＡＮ２のＥＣＵ１００Ｂを監視すること（又はその逆）を可能にする。

また、同じプロトコルであっても、両者で通信速度がことなる場合がある。この場合にもＧ／Ｗ装置１９は速度の違いを吸収して、ＬＡＮ１のＥＣＵ１００ＡがＬＡＮ２のＥＣＵ１００Ｂを監視すること（又はその逆）を可能にする。具体的には、Ｇ／Ｗ装置１９にバッファを設け、ＬＡＮ１から送信された通信データをいったん記憶してから他方のＬＡＮ２に送信することで、通信速度の違いを吸収する。

なお、図２２のようにＬＡＮ１とＬＡＮ２を階層的に接続する場合だけでなく、Ｇ／Ｗ装置１９を中心にＥＣＵ１００Ａ、１００Ｂを複数接続したスター型、複数のＥＣＵ１００Ａ、１００Ｂを同じＬＡＮに接続したスター型においても、ＥＣＵ１００ＡがＥＣＵ１００Ｂを監視すること（又はその逆）ができる。ＬＡＮ１が複数のケーブルで多重化されていてもよい。

また、特殊な例としてFlexRayでは、通信データを送信した時刻情報が通信データに含まれる。これにより、例えばＥＣＵ１００ＡがＥＣＵ１００ＢのVCPU(B)2＿checkreg２２に「ＦＦh」を書き込む際に、時刻情報を一緒に書き込むことができる。したがって、この時刻情報を参照すれば、最後にＥＣＵ１００ＡがVCPU(B)2＿checkreg２２に「ＦＦh」を書き込んでから経過した時間を、ＥＣＵ１００Ｂが検出することができる。ＥＣＵ１００Ｂが「ＦＦh」だけでなく時刻情報を参照してＶＣＰＵ（Ａ）１をリセットすれこととすれば、より的確なタイミングでＶＣＰＵ（Ａ）１をリセットすることができる。ＥＣＵ１００Ａの信頼性や可用性を向上させることができる。

本実施例のＥＣＵ１００によれば、階層的に構築されたネットワークを介して、ＥＣＵ１００ＡがＥＣＵ１００Ｂの異常を、ＥＣＵ１００ＢがＥＣＵ１００Ａの異常を、それぞれ検出できる。

実施例９のように種々のプロトコルや通信速度のＬＡＮ１、２が混在した車載ＬＡＮ１７を介して、一方のＥＣＵ１００Ａが他方のＥＣＵ１００Ｂを監視できることで、特に車両では仮想ＣＰＵ１３を用いた異常の検出の有効性が向上する。

図２３は、本実施例の異常検出システム２００の概略構成図の一例を示す。車両ではＬＡＮ１とＬＡＮ２に故障耐性要求レベルの異なるＥＣＵ１００Ａ、１００Ｂが接続されることが多い。例えば、パワートレーン系のＥＣＵ１００は同じ１つのＬＡＮ１に接続され、ブレーキ系のＥＣＵ１００は同じ１つのＬＡＮ１に接続され、ボディ系のＥＣＵ１００は同じ１つのＬＡＮ２に接続され、マルチメディア系のＥＣＵ１００は同じ１つのＬＡＮ２に接続される。そして、各ＬＡＮ１，２はＧ／Ｗ装置１９を介して接続されている。

マルチメディア系のＥＣＵ１００は、例え故障しても走行に影響を与えることは少ないが、パワートレーン系のＥＣＵ１００が故障すると最悪の場合、走行できなくおそれがある。ＥＣＵ１００は要求される、故障に対する耐性の高さに応じて設計されている。すなわち、マルチメディア系のＥＣＵ１００は故障耐性要求レベルが低く、パワートレーン系のＥＣＵ１００は故障耐性要求レベルが高い。

従来の物理的なＣＰＵを有する監視マイコンでは、柔軟に構成を変えることができなかったので、ＥＣＵの異常を検出する場合、監視マイコンはＬＡＮ毎に配置する必要があった。

しかしながら、本実施例の仮想ＣＰＵ１３を有するＥＣＵ１００はどのＬＡＮ１，２に配置されても、複数の仮想ＣＰＵ１３が異常を検出する基準（例えば、論理積、論理和、多数決、一定周期等）を適宜設定することができる。また、上記のように、ＥＣＵ１００は、種々のプロトコルや通信速度のＬＡＮが混在した車載ＬＡＮ１７を介して通信することができる。

このため、１つの監視用のＥＣＵ１００が異なる故障耐性要求レベルのＥＣＵ１００の異常を検出できる。また、本実施例の異常検出システム２００は、故障耐性要求レベルの異なるＥＣＵ１００Ａ、１００Ｂを種々の車載ＬＡＮ１７を介して監視することができるので、故障耐性要求レベルの異なるＥＣＵ１００Ａ、１００Ｂを同じＬＡＮ内で監視する必要がない。この結果、異常を検出するＥＣＵ１００を配置するＬＡＮ１又はＬＡＮ２を柔軟に決定することができる。

本実施例では、監視用の仮想ＣＰＵ１３を更に監視する仮想ＣＰＵ１３を搭載したＥＣＵ１００について説明する。

図２４は、監視用の仮想ＣＰＵ１３を更に監視する仮想ＣＰＵ１３を搭載したＥＣＵ１００の概略構成図の一例を示す。VCPU(A)2がVCPU(A)1を監視しているのはこれまでの実施例と同じである。これに対し、VCPU(A)3はVCPU(A)2及びVCPU(A)1を監視している。

VCPU(A)1は、一定周期毎に、VCPU(B)2のVCPU(B)2＿checkreg２２に所定値「ＦＦh」を書き込む。実施例１等と同様に、VCPU(A)2はVCPU(B)2＿checkreg２２に「ＦＦｈ」が記載されているか否かを監視する。

また、VCPU(A)1は、一定周期毎にVCPU(A)3のVCPU(A)3＿checkreg２４に所定値「Ｆ０ｈ」を書き込む。VCPU(A)2は、一定周期毎に、VCPU(A)3のVCPU(A)3＿checkreg２４に所定値「Ｆｈ」を書き込む（「０Ｆｈ」でなく「Ｆｈ」）。すなわち、VCPU(A)3＿checkreg２４の下位１バイトのみを全て「１」にする。このような書き込みの結果、VCPU(A)3＿checkreg２４は次のような状態を取る。
・VCPU(A)1とVCPU(A)2が共に正常に動作している場合
VCPU(A)3＿checkreg＝「ＦＦｈ」
・VCPU(A)1だけが正常に動作している場合
VCPU(A)3＿checkreg＝「Ｆ０ｈ」
・VCPU(A)2だけが正常に動作している場合
VCPU(A)3＿checkreg＝「０Ｆｈ」
VCPU(A)3は、VCPU(A)3＿checkreg２４に所定値「ＦＦｈ」「Ｆ０ｈ」「０Ｆｈ」のいずれが書き込まれているか否かを判定し、「ＦＦｈ」が書き込まれている場合は、VCPU(A)3＿checkreg２４に所定値「００ｈ」を書き込む。
そして、VCPU(A)3は以下のようにリセット要求をリセット判定回路３０に出力する。
（１）VCPU(A)3＿checkreg２４が「０Ｆｈ」だった場合
VCPU(A)1に異常が生じているおそれがあるので、VCPU(A)3はVCPU(A)1に対するリセット要求（３→１）をリセット判定回路３０に出力する。したがって、VCPU(A)3はVCPU(A)2とは別にVCPU(A)1の故障を検出することができる。
（２）VCPU(A)3＿checkreg２４が「Ｆ０ｈ」だった場合
VCPU(A)2に異常が生じているおそれがあるので、VCPU(A)3はVCPU(A)2に対するリセット要求（３→２）をリセット判定回路３０に出力する。すなわち、VCPU(A)2の異常を検出して、VCPU(A)2に異常が生じても検出することができる。
（３）VCPU(B)2＿checkreg２２が「００ｈ」だった場合
VCPU(A)1に異常が生じているおそれがあるので、VCPU(B)2はVCPU(A)1に対するリセット要求（２→１）をリセット判定回路３０に出力する。

すなわち、ＶＣＰＵ（Ａ）３は、ＶＣＰＵ(A)1とＶＣＰＵ(A)2のいずれの異常も検出することができる。リセット判定回路３０は、これらのリセット要求からリセットすべきVCPU(A)1及びVCPU(A)2を決定する。なお、リセット要求（３→１）とリセット要求（３→２）をＶＣＰＵ(A)1が区別できれば、リセット要求（３→１）とリセット要求（３→２）のいずれを受信したかでリセット対象を変えるなどが可能となる。しかし、本実施例では、リセット要求（３→１）とリセット要求（３→２）を単にＶＣＰＵ（Ａ）３からのリセット要求として扱う。

・リセット要求（３→１）又はリセット要求（３→２）を受信した場合、リセット判定回路３０はVCPU(B)1及びVCPU(B)2をリセットする。
・リセット要求（２→１）を受信した場合、リセット判定回路３０はVCPU(A)1及びVCPU(B)2をリセットする。
・リセット要求（３→１）とリセット要求（２→１）、又は、リセット要求（３→２）とリセット要求（２→１）を一定周期内に受信した場合、リセット判定回路３０はVCPU(A)3をリセットする。なお、VCPU(A)3をリセットするのは、リセットの優先順位をVCPU(A)3＞VCPU(A)2としているためである。

このようにリセット要求（２→１）、（３→１）、（３→２）のいずれかがリセット判定回路３０に入力されると、仮想的に構築されたVCPU(A)1、VCPU(B)2及びVCPU(A)３を維持したまま、ＥＣＵ全体をリセットすることができる。また、リセット判定回路３０は、リセット要求（２→１）、（３→１）、（３→２）を調停して、VCPU(A)1、VCPU(B)2又はVCPU(A)３からリセットする対象を決定できる。

図２５は、ＥＣＵ１００が異常を検出する手順を示すフローチャート図の一例を示す。
VCPU(A)2は、一定周期毎に、VCPU(B)2＿checkreg２２に所定値「ＦＦｈ」を書き込む（Ｓ１０）。また、VCPU(A)2は、一定周期毎にVCPU(A)3＿checkreg２４に所定値「Ｆ０ｈ」を書き込む（Ｓ２０）。

また、VCPU(A)2は、一定周期毎に、VCPU(A)3＿checkreg２４に所定値「Ｆｈ」を書き込む（Ｓ３０）。そして、VCPU(A)2は、VCPU(B)2＿checkreg２２に「ＦＦｈ」が書き込まれているか否かを判定する（Ｓ４０）。VCPU(B)2＿checkreg２２に「ＦＦｈ」が書き込まれていない場合（Ｓ４０のＮｏ）、VCPU(A)2はリセット要求（２→１）をリセット回路に送信する（Ｓ５０）。VCPU(B)2＿checkreg２２に「ＦＦｈ」が書き込まれている場合（Ｓ４０のＹｅｓ）、VCPU(A)2はVCPU(B)2＿checkreg２２に「００ｈ」を書き込む（Ｓ６０）。

また、VCPU(A)3は、VCPU(Ｂ)３＿checkregに「ＦＦｈ」が書き込まれているか否か判定する（Ｓ７０）。VCPU(Ｂ)３＿checkregに「ＦＦｈ」が書き込まれている場合（Ｓ７０のＹｅｓ）、VCPU(A)3はVCPU(Ｂ)３＿checkregに「００ｈ」を書き込む（Ｓ８０）。

また、VCPU(Ｂ)３＿checkregに「ＦＦｈ」でなく「０Ｆｈ」が書き込まれている場合、VCPU(A)3はリセット要求（３→１）をリセット判定回路３０に送信する（Ｓ９０）。また、VCPU(Ｂ)３＿checkregに「ＦＦｈ」でなく「Ｆ０ｈ」が書き込まれている場合、VCPU(A)3はリセット要求（３→２）をリセット判定回路３０に送信する（Ｓ１００）。

そして、リセット判定回路３０は、リセット要求に応じてリセットする仮想ＣＰＵ１３を決定する（Ｓ１１０）。

本実施例のＥＣＵ１００によれば、VCPU(A)1の異常をVCPU(A)2とVCPU(A)3で検出でき、さらにVCPU(A)2の異常をVCPU(A)3で検出できるので、VCPU(A)1の異常を多重に異常を検出できＥＣＵ１００の信頼性を向上させることができる。

実施例１１では、仮想ＣＰＵ１３であるVCPU(A)3により、VCPU(A)1及びVCPU(A)2の異常を検出したが、本実施例では、実在する監視マイコン４０によりVCPU(A)1及びVCPU(A)2の異常を検出するＥＣＵ１００について説明する。

図２６は、実在する監視マイコン４０によりVCPU(A)1及びVCPU(A)2の異常を検出するＥＣＵ１００の概略構成図の一例を示す。図２６において図２４と同一部には同一の符号を付しその説明は省略する。図２６では、VCPU(A)3の代わりに物理的に実在する監視マイコン４０を有する。

VCPU(A)2がVCPU(A)1を監視している。監視マイコン４０はVCPU(A)2及びVCPU(A)1を監視している。

VCPU(A)1は、一定周期毎に、VCPU(B)2のVCPU(B)2＿checkreg２２に所定値「ＦＦｈ」を書き込む。実施例１等と同様に、VCPU(A)2はVCPU(B)2＿checkreg２２に「ＦＦｈ」が記載されているか否かを監視する。

また、VCPU(A)1は、一定周期毎に監視マイコン４０のＣPU(Ｂ)＿checkreg４１に所定値「Ｆ０ｈ」を書き込む。VCPU(A)2は、一定周期毎に、監視マイコン４０のＣPU(Ｂ)＿checkreg４１に所定値「Ｆｈ」を書き込む（「０Ｆｈ」でなく「Ｆｈ」）。また、監視マイコン４０はＣPU(Ｂ)＿checkreg４１に所定値「ＦＦｈ」が書き込まれているか否かを判定し、書き込まれている場合は、ＣPU(Ｂ)＿checkreg４１に所定値「００ｈ」を書き込む。

したがって、監視マイコン４０は実施例１１のVCPU(A)3と同様に、VCPU(A)2及びVCPU(A)1の異常を検出することができる。

本実施例のＥＣＵ１００によれば、実施例１１の効果に加え、VCPU(A)3を監視マイコン４０で構成することで、マイコン自体に何らかの不具合が生じ仮想ＣＰＵ１３に異常が生じた際でも、VCPU(A)1の異常を確実に検出することができる。

以上説明したように、本実施形態のＥＣＵ１００は、コストや車載スペースの増大をもたらすことなくＥＣＵ１００の異常を検出することができる。異常が検出されてから短い時間で、VCPU(A)2がVCPU(A)1をリセットすることができる。VCPU(A)1を監視する仮想ＣＰＵ１３を切り替えることで、処理負荷を分散できる。ＥＣＵ１００Ａが車載ＬＡＮ１７を経由してＥＣＵ１００Ｂの異常を検出することができるので、ＥＣＵ１００Ａ又はＥＣＵ１００Ｂの配置を柔軟に設計できる。また、監視用に複数の仮想ＣＰＵ１３を構築することで、VCPU(A)1を多重に監視することができる。また、監視用の仮想ＣＰＵ１３を監視する仮想ＣＰＵ１３を配置できるので、信頼性を向上させることができる。

１１ ハードウェアリソース
１３ 仮想ＣＰＵ
１５ ＯＳ
１６(A)1 アプリケーション
１６(A)2 監視プログラム
１７ 車載ＬＡＮ
１８ ＷＤＴユニット
１９ Ｇ／Ｗ装置
２３ ＡＮＤ回路
２５ ＯＲ回路
２７ 多数決回路
３０ リセット判定回路
４０ 監視マイコン
１００ ＥＣＵ（電子制御ユニット）
２００ 異常検出システム

Claims (13)

1. 車載装置に演算結果を提供する電子制御ユニットにおいて、
   実在するＣＰＵと、
   実在するＣＰＵから仮想的なＣＰＵを構築する仮想ＣＰＵ構築手段と、
   仮想的に構築された、第１の仮想ＣＰＵ及び第２の仮想ＣＰＵと、を有し、
   前記演算結果を提供する前記第１の仮想ＣＰＵを、前記第２の仮想ＣＰＵが監視する、
   ことを特徴とする電子制御ユニット。
2. 前記第２の仮想ＣＰＵは、車載ネットワークを介して前記第１の仮想ＣＰＵを監視する、
   ことを特徴とする請求項１記載の電子制御ユニット。
3. 前記第２の仮想ＣＰＵは、ゲートウェイを介して接続された第１の車載ネットワークと第２の車載ネットワークを介して、前記第１の仮想ＣＰＵを監視する、
   ことを特徴とする請求項１記載の電子制御ユニット。
4. 前記第１の仮想ＣＰＵは、前記第２の仮想ＣＰＵのレジスタに周期的に所定値を書き込む書き込み手段を有し、
   前記第２の仮想ＣＰＵは、前記レジスタに前記所定値が記憶されているか否かを判定する判定手段と、
   前記レジスタに前記所定値が記憶されていない場合に前記第１の仮想ＣＰＵをリセットするリセット手段と、を有する、
   ことを特徴とする請求項１〜３いずれか１項記載の電子制御ユニット。
5. 構築された複数の前記第２の仮想ＣＰＵと、
   複数の前記第２の仮想ＣＰＵが出力した監視結果が入力される論理演算手段と、を有し、
   前記論理演算手段による論理演算の結果に応じて前記第１の仮想ＣＰＵをリセットする、
   ことを特徴とする請求項１〜４いずれか１項記載の電子制御ユニット。
6. 前記第２の仮想ＣＰＵは、ウォッチドッグタイマである、
   ことを特徴とする請求項１〜５いずれか１項記載の電子制御ユニット。
7. ２つの前記第２の仮想ＣＰＵ１及び前記第２の仮想ＣＰＵ２が構築された場合、
   前記第１の仮想ＣＰＵを監視する前記第２の仮想ＣＰＵを、前記第２の仮想ＣＰＵ１から前記第２の仮想ＣＰＵ２に切り替える、
   ことを特徴とする請求項１〜６いずれか１項記載の電子制御ユニット。
8. タイマ割り込み又は所定のイベントの発生に伴う割り込みが発生する毎に、
   前記第２の仮想ＣＰＵ１は前記第１の仮想ＣＰＵの監視を中断し、前記第２の仮想ＣＰＵ２は前記第１の仮想ＣＰＵの監視を再開する、
   ことを特徴とする請求項７記載の電子制御ユニット。
9. 構築された２つの前記第２の仮想ＣＰＵのうち、一方は前記第１の仮想ＣＰＵの監視結果を他方の前記第２の仮想ＣＰＵに出力し、
   他方の前記第２の仮想ＣＰＵは、前記第１の仮想ＣＰＵの監視結果又は一方の前記第２の仮想ＣＰＵによる監視結果に基づき、前記第１の仮想ＣＰＵを監視する場合、
   タイマ割り込み又は所定のイベントの発生に伴う割り込みが発生する毎に、
   一方の前記第２の仮想ＣＰＵと他方の前記第２の仮想ＣＰＵの役割を切り替える、
   ことを特徴とする請求項７項記載の電子制御ユニット。
10. 前記論理演算手段は、
    複数の前記第２の仮想ＣＰＵが出力した否定的又は肯定的な監視結果の数と、所定値とを比較した比較結果に応じて前記第１の仮想ＣＰＵをリセットする、
    ことを特徴とする請求項５項記載の電子制御ユニット。
11. 前記第１の仮想ＣＰＵ及び前記第２の仮想ＣＰＵを監視する第３の仮想ＣＰＵと、
    前記第２の仮想ＣＰＵの監視結果と前記第３の仮想ＣＰＵの監視結果が入力される監視判定手段と、を有し、
    前記監視判定手段は、前記第２の仮想ＣＰＵの監視結果と前記第３の仮想ＣＰＵの監視結果のいずれか一方が入力されると、前記第１の仮想ＣＰＵをリセットする、
    ことを特徴とする請求項１記載の電子制御ユニット。
12. 前記第３の仮想ＣＰＵは、
    仮想的に構築されたＣＰＵでなく、実在するＣＰＵである、
    ことを特徴とする請求項１１記載の電子制御ユニット。
13. 車載装置に演算結果を提供する電子制御ユニットの異常検出方法において、
    仮想ＣＰＵ構築手段が、実在するＣＰＵから仮想的な第１の仮想ＣＰＵ及び第２の仮想ＣＰＵを構築するステップと、
    前記演算結果を提供する前記第１の仮想ＣＰＵを、前記第２の仮想ＣＰＵが監視するステップと、
    を有することを特徴とする異常検出方法。

Images