JP5652198B2 - 電子制御装置、起動制御方法 - Google Patents

Description

本発明は、複数のアプリの実行する電子制御装置に関し、特に、各アプリの異常を検出することができる電子制御装置に関する。

１つのマイコンが複数のアプリケーションを実行した場合、各アプリケーションにはまれに異常が生じることがある。アプリケーションの異常は、ＷＤＴ（Watch Dog Timer）などで検出されるが、異常を解消するにはマイコンをリセットすることが有効であることが知られている。

しかしながら、マイコンがリセットされると、異常を生じたアプリケーションが１つでも、リセットから再起動までの間、全てのアプリケーションが停止してしまう。ここで、アプリケーションには、例えば車載装置の制御に必要な優先度の高いもの以外にも、割込み待ちのようなアプリケーションなど優先度の低いものがあり、優先度の低いアプリケーションの異常に起因して優先度の高いアプリケーションが停止してしまうことは好ましくない。

障害発生時にアプリケーションの優先度の高低を考慮して、アプリケーションの実行を制御する技術が考案されている（例えば、特許文献１参照。）。特許文献１には、実行優先度の高いジョブの実行中に、ジョブを停止しなければならない障害が発生したことを検出してそのジョブを一時停止させると共に、その障害に影響を受けない実行優先度の低いジョブの実行を開始させる画像形成装置が開示されている。

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

しかしながら、特許文献１に開示された考案には、優先度の低いジョブの異常が検出された場合の処理について開示されていない。このため、画像形成装置が優先度の低いジョブの異常を検出した場合、マイコンをリセットしたとすると、優先度の高いジョブまで実行できなくなるという上記の課題が解決できない。

また、組み込み機器では定期的にアプリケーションを起動させることが多いが、一度、異常が生じたアプリケーションは、起動されても再度異常を生じさせるおそれが高いので、定期的な起動を禁止すべきである。しかし、従来、優先度の低いアプリケーションの異常が検出された場合に、優先度の高いアプリケーションは起動しながら、優先度の低いアプリケーションの起動を選択的に停止することは考慮されてこなかった。

本発明は、上記課題に鑑み、異常が検出されたアプリケーションの優先度に応じてアプリケーション毎に起動管理が可能な電子制御装置を提供することを目的とする。

上記課題に鑑み、本発明は、複数のアプリケーションを実行するプロセッサを備えたマイコン及びマイコンをリセットするリセット手段を備えた監視回路を有する車両用の電子制御装置であって、前記監視回路は、アプリケーション毎に定められた起動タイミングで前記マイコンに繰り返し各アプリケーションの起動要求を出力する起動要求手段と、各アプリケーション毎に異常を検出する異常検出手段と、を有し、前記異常検出手段が異常を検出したアプリケーションの優先度が閾値以下の場合、前記起動要求手段は該アプリケーションの起動要求を停止し、前記異常検出手段が異常を検出したアプリケーションの優先度が前記閾値より大きい場合にのみ、前記リセット手段がマイコンをリセットし、前記異常検出手段が、優先度が前記閾値以下の複数のアプリケーションの異常を検出した場合、前記リセット手段がマイコンをリセットする、ことを特徴とする。

異常が検出されたアプリケーションの優先度に応じてアプリケーション毎に起動管理が可能な電子制御装置を提供することができる。

電子制御装置を説明する図の一例である。 電子制御装置の概略構成図の一例である。 電子制御装置の動作を模式的に説明する図の一例である。 起動・監視回路が動作する手順を示すフローチャート図の一例である。 電子制御装置の別の一例を説明する図である。 電子制御装置を説明する図の一例である（実施例２）。 電子制御装置の概略構成図の一例である。 電子制御装置の動作を模式的に説明する図の一例である。 スケジュール手段の動作を説明するフローチャート図の一例である。 マイコンと起動・監視回路の動作手順を示すシーケンス図の一例である。 電子制御装置の別の一例を説明する図である。

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

図１は、本実施例の電子制御装置１００を説明する図の一例である。電子制御装置１００は、マイコンと起動・監視回路を有する。起動・監視回路はマイコンにアプリケーション（以下、単にアプリという）を実行させる起動制御という機能と、アプリの異常監視という機能を有する。従来、起動制御という機能はマイコン側が有していたが、マイコン外部の起動・監視回路が有することでアプリに異常が生じた場合に、異常が検出されたアプリの影響を受けずに他のアプリを起動制御することができる。

また、起動・監視回路はアプリＡがクリアするＷＤＴ（Watch Dog Timer）１、アプリＢがクリアするＷＤＴ２を有し、ＷＤＴ１又はＷＤＴ２がオーバーフローすることで対応するアプリＡ又はアプリＢの異常を監視している。起動・監視回路にとって、アプリＡ又はアプリＢのうち優先度の高いアプリがクリアするＷＤＴ１又は２は既知になっている。

以上の構成に基づき、起動・監視回路とリセット回路２１は以下のように動作する。
（１）起動・監視回路は定期的にアプリＡ、アプリＢをそれぞれ起動する。
（２）優先度の低いアプリＢがＷＤＴ２をオーバーフローさせた場合（図１左下）、起動回路はアプリＢのみ起動を停止する。この場合、リセット回路はマイコンをリセットしない。
（３）優先度の高いアプリＡがＷＤＴ１をオーバーフローさせた場合（図１右下）、リセット回路２１はマイコンをリセットする。

このように、優先度の低いアプリＢに異常が検出されても、リセット回路２１はマイコンをリセットしないので優先度の低いアプリＡが優先度の高いアプリＢの異常により停止してしまうことを防止できる。また、優先度の低いアプリＢに異常が検出された場合、起動回路がアプリＢを起動させないので、アプリＢに何度も異常が生じてアプリＡに異常が伝達することを防止できる。

〔電子制御装置の構成例〕
図２は、電子制御装置１００の概略構成図の一例を示す。電子制御装置（ＥＣＵ：Electronic Control Unit）１００は、例えばエンジン、駆動用モータ、ホイルシリンダ圧など、各種の車載装置を制御するために用いられる。

電子制御装置１００は、マイコン８０と起動・監視回路９０とを有する。マイコン８０は、システムバス１０に接続されたＣＰＵ１２、ＲＯＭ１４、ＲＡＭ１１、ＢＲＧ１６及びＩＮＴＣ（割込みコントローラ）１５を有する。

ＲＯＭ１４には、電子制御装置１００が制御のために実行するアプリ１７（区別する場合、アプリＡ、Ｂという）が記憶されている。この他、ＯＳ（例えば、OSEK OS、ITRONなど）、ドライバ、ＣＡＮプロトコルなどの通信ソフトが記憶されていてもよい。アプリＡ、Ｂは、アプリＡの方が優先度が高いとし、例えばＯＳは各アプリの優先度を管理している。なお、マイコン８０が３つ以上のアプリを実行する場合については後述する。

例えば、アプリＡは、エンジンやモータ、ブレーキ油圧の制御量を演算するプログラムであり、アプリＢは、レジスタチェック、フェールセーフ処理、又は、無限ループによる待ち状態等を提供するプログラムである。

ＣＰＵ１２はローカルＲＡＭ１２２を有し、これとＲＡＭ１１を作業メモリとして、時分割方式で複数のアプリ１７を実行する。ＣＰＵ１２は、複数のコア１２１を有するマルチコア型でもよいし、複数のＣＰＵ１２を有していてもよい。この場合、コア毎にアプリＡ，Ｂを割り当てることもできる。

ＩＮＴＣ１５は、アプリ１７の数と同じ数の制御線で起動回路２４と接続されている。ＩＮＴＣ１５は、起動回路２４や他の周辺機器（タイマ、センサ、他のＥＣＵ等）からの割込み要因を調停して、ＣＰＵ１２に割込み要求する。例えば、ＩＮＴＣ１５は起動回路２４からの割込みに対しアプリＡ又はアプリＢをＣＰＵ１２に実行させる。

ＢＲＧ１６は、Ｉ／Ｏバス９を介してＩ／Ｏ１６１と接続されている。ＢＲＧ１６は各種のＩ／Ｏ２３との間で相互にバス周波数や電圧値などを変換する。Ｉ／Ｏ１６１は電子制御装置１００と外部の機器を接続するインタフェースであり、例えば、各種のアクチュエータ、センサ、スイッチ等が接続される。

リセット端子１３は、リセット端子１３に入力する信号がＬｏｗ→Ｈｉｇｈになるとマイコン８０をリセットする端子である。

起動・監視回路９０は、リセット回路２１、ＷＤＴ（以下区別する場合ＷＤＴ１、ＷＤＴ２という）２２、及び、起動回路２４を有する。まず、ＷＤＴ１は、クロックジェネレータなど何らかのクロックソースに基づきカウントアップ又はカウントダウンするタイマーであり、ある一定値に到達した時又はカウンタがゼロになった時に（以下、いずれの場合も単に「オーバーフロー」という）、起動回路２４及びリセット回路２１に通知する。

ＣＰＵ１２とＷＤＴ１、２は制御線でそれぞれ接続されており、ＣＰＵ１２がアプリＡを実行することでＷＤＴ１を、アプリＢを実行することでＷＤＴ２をそれぞれオーバーフローする前にクリアするように設計されている。すなわち、アプリＡが暴走した場合、ＷＤＴ１がクリアされず、アプリＢが暴走した場合、ＷＤＴ２がクリアされないと仮定して、起動・監視回路９０はＷＤＴ１がオーバーフローしないことでアプリＡが正常であること、ＷＤＴ２がオーバーフローしないことでアプリＢが正常であることをそれぞれ検出している。

なお、ＷＤＴ２２は１つでもよい。この場合、ＷＤＴ２２は２つのタイマーを独立にカウントして、それぞれのカウント値のオーバーフローを監視する。

このように、起動回路２４は、ＷＤＴ１又は２からの通知により異常のあるアプリＡ又はアプリＢを検出している。起動回路２４は、ＷＤＴ１、２がオーバーフローしない場合には、ＩＮＴＣ１５に、アプリＡ及びＢの起動要求を定期的に出力している。アプリ１７には、サイクル時間毎に繰り返す処理や、サイクル時間毎に制御量を演算する処理など、定期的に起動されるものが少なくない。起動回路２４は、クロックソースに基づきアプリＡ又はアプリＢ毎に決まっている定期的な時間の経過をカウントし、起動要求を出力する。また、アプリ１７には、ほぼ定期的に入力される外部からの信号を契機に実行されるものがある。例えば、エンジン回転数は、クランク角が１５度変化する毎にＮＥセンサがマイコン８０に割込みして実行させるアプリが演算する。このようなアプリに対し起動回路２４は、外部からの定期的な割込みを検出して起動要求を出力する。

そして、起動回路２４は、ＷＤＴ２がオーバーフローするとアプリＢの起動要求を停止する。これにより、マイコン８０が、異常が検出されたアプリＢを再度、起動することを防止できる。また、起動回路２４は、ＷＤＴ１がオーバーフローすると、マイコン８０の再起動後にアプリＡとアプリＢの起動要求を再開する。こうすることでアプリＡに対しては常に復帰と再開が優先される。

リセット回路２１は、予め定められたＷＤＴ１又は２のいずれかがオーバーフローすると、リセット端子１３にＬｏｗ信号を出力する。予め定められたＷＤＴ２２は優先度の高いアプリＡがクリアするＷＤＴ２２である。

なお、図２では、起動・監視回路９０をハード的なＩＣ（例えば、ＡＳＩＣ等）で実現しているが、ＣＰＵがプログラムを実行することでソフト的に実現することもできる。

〔動作手順〕
図３は、電子制御装置１００の動作を模式的に説明する図の一例である。起動回路２４は、アプリＡの起動タイミングになると、アプリＡ起動要求（Ｈｉｇｈアクティブ）を起動手段３１に出力し、アプリＢの起動タイミングになると、アプリＢ起動要求（Ｈｉｇｈアクティブ）を起動手段３１に出力する。

図３（ｂ）に示すように、アプリＡ起動要求及びアプリＢ起動要求が定期的に起動・監視回路９０からマイコン８０に出力される。図ではアプリＡとアプリＢの起動間隔は同程度だが、異なっていてもよい。また、実行頻度が異なっていてもよい。

マイコン８０の起動手段３１は、例えばＩＮＴＣ１５が起動要求に応じてＣＰＵ１２に割り込むことで実現される。ＩＮＴＣ１５は起動要求を割り込みの一種として受け付け、アプリの優先順位を調停する。例えば、アプリＡの実行中にアプリＢの起動要求がＩＮＴＣ１５に入力されても、ＩＮＴＣ１５はアプリＡが終了するまでＣＰＵ１２に割り込まない。逆に、アプリＢの実行中にアプリＡの起動要求が入力された場合、ＩＮＴＣ１５はＣＰＵ１２に割り込むので、ＣＰＵ１２はアプリＢの実行状態を退避してアプリＡを起動する。なお、このようなコンテキストスイッチが発生するかどうかは、アプリＡ、Ｂの起動サイクル及び実行時間に依存するので、オーバーヘッドが抑制されるようにアプリＡ、Ｂの起動サイクルを最適化することもできる。また、ＣＰＵ１２がマルチコアで各コアにアプリＡ，Ｂが割り当てられている場合、アプリＡ、Ｂの実行時間が重複しても、優先度の高低に応じたコンテキストスイッチは発生しない。

ＣＰＵ１２は、ＲＯＭ１４又はＲＡＭ１１に設定されているベクターテーブルからＩＮＴＣ１５が通知する割り込み番号に対応した割り込みベクター（アドレス）の命令を実行する。本実施例では、割り込みベクターに対応した割り込みハンドラがアプリＡ又はアプリＢを起動させる。

このようにして起動手段３１は、起動回路２４からのアプリＡ起動要求に対しアプリＡを起動し、起動回路２４からのアプリＢ起動要求に対しアプリＢを起動する。アプリＡ及びアプリＢはそれぞれ実行状態更新部３２（区別する場合、実行状態更新部Ａ，Ｂという）を有する。実行状態更新部ＡはアプリＡの実行状態を起動・監視回路９０に通知し、実行状態更新部ＢはアプリＢの実行状態を起動・監視回路９０に通知する。具体的には、図３（ｂ）に示すように、実行状態更新部Ａは、アプリＡが起動すると終了までの間にＷＤＴ１に１回以上、実行履歴を通知する。実行状態更新部Ｂについても同様である。実行履歴の通知は、ＷＤＴ１、２のリセットである。起動・監視回路９０はアプリＡ，Ｂに異常が生じたことを実行状態更新部Ａ，ＢがＷＤＴ１、２をリセットしないことで検出する。この場合、ＷＤＴ１，２は、実行間隔（アプリＡ、Ｂの最後の起動から次の起動まで）の時間よりも長い時間（例えば、実行間隔のｎ（＞１）倍）が経過すると、オーバーフローするように設定される。

また、起動・監視回路９０のＷＤＴ１，２のカウントを、アプリＡ、Ｂが停止・再開できる場合、実行状態更新部Ａ，Ｂは実行開始の通知でＷＤＴ１、２のカウントを開始し、実行終了の通知でリセットすることもできる。この場合、ＷＤＴ１，２は、実行時間（アプリＡ、Ｂの起動から終了まで）の時間よりも長い時間（例えば、実行時間のｎ（＞１）倍）が経過すると、オーバーフローするように設定される。なお、この場合、各アプリの実行時間を計測することができる。

図３（ｂ）に示すように、時刻ｔ４で起動したアプリＢの実行状態更新部Ｂは、実行履歴又は実行終了をＷＤＴ２に通知できなかった。これはアプリＢの異常を意味するので、ＷＤＴ２は起動回路２４とリセット回路２１にアプリＢの異常を通知する。これにより、起動回路２４はアプリＢ起動要求を起動手段３１に出力することを停止する。

次に、時刻ｔ６で起動したアプリＡの実行状態更新部Ａは、実行履歴又は実行終了をＷＤＴ１に通知できなかった。これはアプリＡの異常を意味するので、ＷＤＴ１は起動回路２４とリセット回路２１にアプリＡの異常を通知する。これにより、リセット回路２１はリセット端子１３にリセット信号を出力する（図では時刻ｔ７）。また、マイコンの再起動までの間、起動回路２４はアプリＡ起動要求を起動手段３１に出力することを停止する。

マイコン８０はリセットされるとＲＯＭ１４のリセットベクタをプログラムカウンタに設定するので起動用のプログラムが実行され、起動用のプログラムがマイコン８０だけでなく起動・監視回路９０を初期化して、起動回路２４、ＷＤＴ１，２も起動を開始する。これにより、時刻ｔ８に示すように、起動回路２４が異常の検出前と同様に、アプリアプリＡ起動要求及びアプリＢ起動要求の定期的な出力を再開する。よって、マイコン８０はアプリＡ及びアプリＢを再度、定期的に実行するようになる。

〔動作手順〕
図４は、本実施例の起動・監視回路９０が動作する手順を示すフローチャート図の一例である。図４の手順は、アプリＡ又はアプリＢの起動タイミングになると実行される。

まず、起動回路２４は、タイマーを参照する（Ｓ１０）。このタイマーは、アプリＡ又はアプリＢの起動タイミングを検出する時計であり、起動回路２４は、最後にアプリＡ起動要求及びアプリＢ起動要求を出力した時刻を記憶しておき、それからの経過時間を監視している。または、アプリＡ及びアプリＢの起動タイミング毎に、タイマがーＨｉｇｈ信号を起動回路２４に出力してもよい。

起動回路２４はアプリＡの起動タイミングか否かを判定する（Ｓ２０）。アプリＡの起動タイミングでない場合（Ｓ２０のＮｏ）、処理はステップＳ６０に進む。

アプリＡの起動タイミングである場合（Ｓ２０のＹｅｓ）、起動回路２４は前回起動したアプリＡが正常に終了したか否かを判定する（Ｓ３０）。正常に終了したか否かはＷＤＴ１がオーバーフローしたか否かにより判定されるので、ＷＤＴ１がオーバーフローしていなければステップＳ３０の判定はＮｏになる。

前回起動したアプリＡが正常に終了した場合（Ｓ３０のＹｅｓ）、起動回路２４はアプリＡ起動要求をマイコン８０に出力する（Ｓ４０）。これにより、マイコン８０はアプリＡを起動することができる。

前回起動したアプリＡが正常に終了していない場合（Ｓ３０のＮｏ）、ＷＤＴ１がオーバーフローしたことになるので、リセット回路２１はリセット信号をマイコン８０に出力する（Ｓ５０）。これにより、マイコン８０はリセットされ、アプリＡ、アプリＢが再度実行される。

次に、ステップＳ６０において、起動回路２４はアプリＢの起動タイミングか否かを判定する（Ｓ６０）。アプリＢの起動タイミングでない場合（Ｓ２０のＮｏ）、図４の処理は終了する。

アプリＢの起動タイミングである場合（Ｓ６０のＹｅｓ）、起動回路２４は前回起動したアプリＢが正常に終了したか否かを判定する（Ｓ７０）。正常に終了したか否かはＷＤＴ２がオーバーフローしたか否かにより判定されるので、ＷＤＴ２がオーバーフローしていなければステップＳ７０の判定はＮｏになる。

前回起動したアプリＢが正常に終了した場合（Ｓ７０のＹｅｓ）、起動回路２４はアプリＢ起動要求をマイコン８０に出力する（Ｓ８０）。これにより、マイコン８０はアプリＢを起動することができる。

前回起動したアプリＢが正常に終了していない場合（Ｓ７０のＮｏ）、ＷＤＴ２がオーバーフローしたことになるので、アプリＢを再度起動しないように、起動回路２４はアプリＢ起動要求を出力しない。これにより、アプリＢの再起動を防止できる。なお、ＷＤＴ２から起動回路２４へのオーバーフローの通知は、1度のオーバーフローにつき1回だけなので、起動回路２４はＷＤＴ２がオーバーフローしたことをフラグなどで記憶しておく。これにより、次回の図４の手順が実行される際に、アプリＢの起動タイミングが到来しても（Ｓ６０のＹｅｓ）、起動回路２４がアプリＢ起動要求を出力することを防止できる。

〔３つ以上のアプリがある場合〕
マイコン８０が３つ以上のアプリを実行する場合も同様に軌道制御できる。

図５（ａ）は３つ以上のアプリを有する電子制御装置１００の一例を示す。図ではマイコン８０はｎ個のアプリを実行し、起動・監視回路９０はｎ個のＷＤＴ２２を有している。マイコン８０が３つ以上のアプリを実行する場合、１つのアプリに異常が生じた際に他のアプリを停止してでもマイコン８０をリセットすべきかどうかの観点から、設計者が３つ以上のアプリをある優先度（閾値）を基準に、低優先度アプリと高優先度アプリに分類しておく。

分類結果は、起動回路２４やリセット回路２１に記憶される。例えば、起動回路２４には、オーバーフローにより起動要求を停止すべきＷＤＴ２２の識別情報が起動時にレジスタなどに設定され、リセット回路２１には、オーバーフローによりリセットすべきＷＤＴ２２の識別情報が起動時にレジスタなどに設定される。

したがって、アプリが３つ以上でも、起動・監視回路９０はアプリが２つの場合と同様に、低優先度のアプリの異常に対しては該アプリの起動を停止して高優先度のアプリの実行を継続し、高優先度のアプリの異常に対してはマイコン８０をリセットすることができる。

また、起動・監視回路９０は、リセット対象外の低優先度のアプリでも２つ以上の異常が検出された場合、マイコン８０をリセットすることもできる。この場合、リセット回路２１は、オーバーフローしたＷＤＴ２２に対応したアプリを記憶しておき、予め定められた数の低優先度のアプリの異常が検出されると、リセット回路２１がマイコン８０をリセットする。

低優先度のアプリでも２つ以上のアプリが異常を生じることは、高優先度のアプリに異常が生じる可能性が少なくないおそれがあるので、早期にマイコン８０をリセットすることができる。

図５（ｂ）は、マイコン８０と起動・監視回路９０を別のＥＣＵ１，２に搭載したＥＣＵシステムの一例を示す図である。図５（ｂ）ではマイコン８０と起動・監視回路９０がいずれもＣＡＮ通信部３３を有し、ＣＡＮバス３４を介して通信することができる。なお、通信プロトコルはＦｌｅｘＲａｙなどどのようなものでもよい。

この場合、起動・監視回路９０にも通信のためのプログラムを実行するＣＰＵが搭載される。起動回路２４に相当する所定のプログラムはＣＡＮバス３４を介してアプリＡ起動要求及びアプリＢ起動要求をＥＣＵ１に送信する。ＣＡＮ通信部１の受信割り込みをＩＮＴＣ１５が処理することで、起動手段３１は上述と同様にアプリＡ及びアプリＢを起動することができる。

アプリＡの実行状態更新部ＡとアプリＢの実行状態更新部ＢはＣＡＮバス３４を介して実行履歴又は実行終了をＥＣＵ２に通知する。ＥＣＵ２の所定のプログラムは実行終了を受信するとＷＤＴ１、２をクリアする。よって、アプリＡ、Ｂに異常がなければＷＤＴ１、２がオーバーフローすることはない。

ＷＤＴ２がオーバーフローした場合、起動回路２４に相当するプログラムはアプリＢ起動要求の出力を停止する。また、ＷＤＴ１がオーバーフローした場合、リセット回路２１はリセット信号をリセット端子１３に出力する。これにより、ＥＣＵ１のマイコン８０はリセットされる。

したがって、マイコン８０と起動・監視回路９０が別のＥＣＵ１，２に搭載された場合でも、異常が検出されたアプリ１７の優先度に応じて、マイコン８０をリセットするかどうかを制御できる。図５（ｂ）のような形態では、複数のマイコン８０の起動・監視回路９０を１つのＥＣＵ２に集約可能な可能性があるので電子制御装置１００の製造コストを低減することが期待できる。

以上説明したように、本実施例の電子制御装置１００は、マイコン８０の外部の起動・監視回路９０がアプリの起動を制御することで、異常が検出されたアプリの影響を受けない外部からアプリ毎に起動するか否かを制御することができる。また、異常が検出されたアプリ１７の優先度に応じてマイコン８０をリセットするか否かを制御できる。

実施例１では、アプリ１７の数が増えるとマイコン８０と起動・監視回路９０の結線が増えてしまうおそれがある。そこで、本実施例ではマイコン８０と起動・監視回路９０の結線数を低減できる電子制御装置１００について説明する。

図６は、本実施例の電子制御装置１００を説明する図の一例である。図６の電子制御装置１００は、異常の生じたアプリ１７を切り離す処理を起動・監視回路９０からマイコン８０に残した電子制御装置１００である。

本実施例のマイコン８０はスケジュール手段３６及びＡＮＤ回路２０を有し、起動・監視回路９０は起動回路２４を有する。スケジュール手段３６は、アプリＡ、アプリＢの起動をスケジューリングする。ＡＮＤ回路２０は、アプリＡ、アプリＢの両方が実行終了通知をそれぞれフラグＦ１９（区別する場合、フラグＦａ、Ｆｂという）に出力することでオンとなる回路であり、ＷＤＴ２２をクリアしている。よって、アプリＡ又はアプリＢのいずれかに異常が生じると、ＷＤＴ２２はクリアされない。

図６（ｂ）に示すように、ＷＤＴ２２がオーバーフローすると、割り込み起動回路２４は割り込み起動要求をスケジュール手段３６に通知する。スケジュール手段３６は、割り込み起動要求により、ＷＤＴ２２がオーバーフローしたこと（アプリＡ又はアプリＢに異常が生じたこと）を検出する。なお、起動・監視回路９０は割り込み起動要求したことを記憶しておく。

図６（ｃ）に示すように、割り込み起動要求を取得したスケジュール手段３６は、アプリＡ又はアプリＢのうち異常が生じたアプリ（図ではアプリＢになっている）を推定し、当該アプリをスケジュール対象から除外する。これにより、異常の生じたアプリＢを切り離すことができる。また、スケジュール手段３６はアプリＢが起動しなくてもＡＮＤ回路２０をオンにするため、フラグＦｂに“１”を設定する。なお、異常が生じたと推定されたアプリがアプリＡであり優先度が高い場合、スケジュール手段３６はフラグＦａに“１”を設定しない。

図６（ｄ）に示すように、アプリＡに異常がある場合、フラグＦａに“１”が設定されないのでＷＤＴ２２は再度、オーバーフローする。この場合、起動・監視回路９０は、ＷＤＴ２２がオーバーフローした際にすでに割り込み起動要求を出力した記録があることを検出して、リセット回路２１によりマイコン８０をリセットする。

したがって、マイコン８０は優先度の低いアプリＢについてはスケジュール対象から除外してアプリＡを実行できるので、優先度の高いアプリＡがアプリＢの異常により停止することを抑制できる。また、マイコン８０と起動・監視回路９０の間の結線は、アプリの数に拘わらず図示する３本に抑制することができる。

〔電子制御装置の構成例〕
図７は、電子制御装置１００の概略構成図の一例を示す。図７において図２と同一部には同一の符号を付しその説明は省略する。

本実施例のマイコン８０は、上記のフラグ１９及びＡＮＤ回路２０を有する。フラグＦａはアプリＡが操作するフラグであり、フラグＦｂはアプリＢが操作するフラグである。また、フラグＦａ、Ｆｂはスケジュール手段３６により定期的にリセットされる。このタイミングは、例えば、アプリＡ，Ｂの実行の直前であり、アプリＡ、ＢがフラグＦａ、Ｆｂに“１”を設定することで、各アプリＡ，Ｂが正常であることが確認できる。

ＩＮＴＣ１５は、実施例１と異なり、起動回路２４から割込みに対しアプリＡ又はアプリＢをＣＰＵ１２に実行させるのでなく、スケジュール手段３６を実行させる。スケジュール手段３６は主にＯＳ１８により提供されるが、ＯＳ１８を利用することなくアプリの一種として実装することもできる。スケジュール手段３６については次述する。

起動・監視回路９０の構成は実施例１と同様であるが、本実施例ではＷＤＴ２２を１つしか有さない。ＷＤＴ２２は、ＡＮＤ回路２０がオンになるとクリアされ、ＡＮＤ回路２０がオンにならずオーバーフローすると、起動回路２４に通知する。なお、ＡＮＤ回路２０による実装は一例であって、何らかのソフト的な手段により置き換えてもよい。例えば、ソフト的な手段は、ＣＰＵ１２がアプリＡ、Ｂの最後の命令まで実行終了したことを検出してＷＤＴ２２をクリアする機能を有すればよい。

起動回路２４は、ＷＤＴ２２がオーバーフローするとマイコン８０がスケジュール手段３６を起動するように、ＩＮＴＣ１５に割り込み起動要求を出力する。また、起動回路２４は、割り込み起動要求したことをフラグなどで記憶しておく。こうすることで、次回、ＷＤＴ２２がオーバーフローした際に、２回目のオーバーフローであることを検出できる。２回目のオーバーフローに対し起動回路２４はリセット回路２１に対しリセットを要求する。リセット回路２１はリセット端子１３にＬｏｗを出力するので、マイコン８０をリセットすることができる。

＜スケジュール手段＞
図８（ａ）は、電子制御装置１００の動作を模式的に説明する図の一例である。上記のように、起動回路２４が割り込み起動要求を起動手段３１に出力することで、マイコン８０はスケジュール手段３６を起動させる。マイコン８０の起動手段３１については実施例１と同様に、例えばＩＮＴＣ１５が割り込み起動要求に応じてＣＰＵ１２に割り込むことで実現される。ＩＮＴＣ１５は割り込み起動要求を割り込みの一種として受け付け、ＣＰＵ１２はベクターテーブルから割り込み起動要求に対応した割り込みベクター（アドレス）の命令を実行する。本実施例では、割り込みベクターに対応した割り込みハンドラがスケジュール手段３６を起動させる。

スケジュール手段３６は、スケジュールテーブル３７に従い、アプリＡ、Ｂを起動する（ＣＰＵ１２に割り当てる）。スケジュールテーブル３７には、アプリＡ，Ｂの優先度が実行時間を考慮して、アプリＡ、Ｂの起動タイミングが登録されている。実施例１のようにアプリＡ、Ｂを定期的に起動する場合、スケジュール手段３６はタイマーを監視しながら、それぞれの起動タイミングになるとアプリＡ又はアプリＢを起動させる。

また、スケジュール手段３６は、アプリＡ，Ｂの状態（実行可能、実行中、実行待ち等）に応じて、実行可能なアプリのうち優先度の高いものほど優先的にＣＰＵ１２に割り当てることもできる。アプリＡ，Ｂが相互に関連している場合（例えばアプリＢがアプリＡの処理結果を利用する場合、またはその逆等）、アプリＡ、Ｂが実行待ち状態になるので、スケジュール手段３６はアプリＡ，Ｂの状態遷移を監視して、優先度を考慮しながらＣＰＵ１２に割り当てるアプリＡ，Ｂをスケジューリングしていく。なお、スケジュール手段３６は、起動回路２４が割り込み起動要求を送信した場合だけでなく、アプリＡ又はＢが実行完了する毎や定期的に起動する。

図９はスケジュール手段３６の動作を説明するフローチャート図の一例である。

ます、マイコン８０が起動・監視回路９０から割り込み起動要求を取得してスケジュール手段３６が起動する（Ｓ１１０）。

スケジュール手段３６は、異常を生じさせたアプリがアプリＡ又はアプリＢのどちらなのかを推定する（Ｓ１２０）。推定方法はいくつかあるが、例えば、スケジュール手段３６の実行により退避したプログラムカウンタのアドレスがアプリＡ又はＢのどちらのアドレスに相当するかにより推定することができる。また、スケジュール手段３６がプロセス間通信の機能を有する場合、アプリＡ及びＢにメッセージを問い合わせその応答の有無から、異常のあるアプリを推定することもできる。また、スケジュール手段３６はアプリＡ、Ｂをスケジューリングしているので、直前にＣＰＵ１２に割り当てたアプリＡ又はＢに異常があると推定することもできる。

スケジュール手段３６は、異常が検出されたアプリを推定すると、そのアプリが停止してよい低い優先度が否かを判定する（Ｓ１３０）。各アプリＡ、Ｂの優先度はスケジュール手段３６にとって既知であるので、スケジュール手段３６は異常があると推定したアプリの優先度が閾値以下か否かに基づき停止可能か否かを判定する（アプリが２つの場合は高又は低のどちらであるかを判定する）。

アプリＢが停止してよい低い優先度の場合（Ｓ１３０のＹｅｓ）、スケジュール手段３６は異常を生じさせたアプリＢをスケジュールテーブル３７から削除する（Ｓ１４０）。これにより、アプリＢは強制的に終了され、アプリＢが占有していたローカルＲＡＭ１２２やＲＡＭ１１の領域が開放される。また、削除されたアプリＢはスケジュール手段３６に記録される。記録することで、再度アプリＢが生成されても実行を禁止したり、スケジュール手段３６がフラグＦｂの操作を替わって実行することができる。

そして、スケジュール手段３６はアプリＡの実行を再開する（Ｓ１５０）。こうすることで、優先度の低いアプリＢだけを停止し、優先度の高いアプリＡだけを継続することができる。なお、停止したアプリＢに変わってスケジュール手段３６はフラグＦｂを操作するがこの処理については後述する。

また、アプリＡが停止してよい低い優先度でない場合（Ｓ１３０のＮｏ）、スケジュール手段３６は異常を生じさせたアプリＡを停止することなく、アプリの実行を再開する（Ｓ１５０）。こうすることで、優先度の高いアプリＡに異常が生じていれば、再度、ＷＤＴ２２がオーバーフローするので、リセット回路２１がマイコン８０をリセットすることができる。

図８（ｂ）は、マイコン８０と起動・監視回路９０が出力する信号を模式的に説明する図の一例である。ＷＤＣ（Watch Dog timer Clear）パルスは、ＡＮＤ回路２０から出力されるパルスであり、１つのパルス毎にＷＤＴ２２をクリアする。したがって、WDCパルスが停止すると、ＷＤＴ２２がクリアされないので起動回路２４が割り込み起動要求をマイコン８０に出力する。

これにより、スケジュール手段３６が図９にて説明した処理を行うが、優先度の高いアプリＡに異常が生じている場合、割り込み起動要求が出力されても、図示するようにＷＤＣパルスは再開されないので、ＷＤＴ２２が再度オーバーフローする。これにより、リセット回路２１がリセット信号を出力する。

不図示であるが、優先度の低いアプリＢに異常が生じている場合、ＷＤＣパルスは割り込み起動要求の後、再開されるためリセット回路２１はリセット信号を出力しない。

〔動作手順〕
図１０は、マイコン８０と起動・監視回路９０の動作手順を示すシーケンス図の一例である。
アプリＡ、Ｂに異常が生じていなければ、スケジュール手段３６は定期的に起動してスケジュールに従ってアプリＡ、Ｂをそれぞれ起動する。

起動・監視回路９０から割り込み起動要求が出力されず、スケジュールが変更されていない場合（Ｓ２１０のＮｏ）、スケジュール手段３６は起動するアプリＡに対応したフラグＦａをクリアする（Ｓ２２０）。

次に、スケジュール手段３６はアプリＡを起動するので（Ｓ２３０）、実行状態更新部ＡがフラグＦａに“１”を設定する（Ｓ３１０）。

同様に、スケジュール手段３６はアプリＢの起動タイミングになると、アプリＢに対応したフラグＦｂをクリアし（Ｓ２４０）、アプリＢを起動するので（Ｓ２５０）、実行状態更新部ＢがフラグＦｂに“１”を設定する（Ｓ３２０）。

これにより、ＡＮＤ回路２０がＷＤＣパルスをＷＤＴ２２に出力することができる（Ｓ３３０）。

そして、ステップＳ２１０〜２５０において、アプリＡ又はアプリＢに異常が生じると、ＡＮＤ回路２０がＷＤＣパルスを出力しないので、ＷＤＴ２２がオーバーフローする。 ＷＤＴ２２がオーバーフローした場合（Ｓ４１０のＹｅｓ）、起動回路２４がそれを検出し、すでに割り込み起動要求を出力したか否かを判定する（Ｓ４２０）。なお、ＷＤＴ２２がオーバーフローしていなければ（Ｓ４１０のＮｏ）、起動・監視回路９０は処理を行わない。

割り込み起動要求が出力されていない場合（Ｓ４２０のＮｏ）、マイコン８０のリセット後、最初のオーバーフローなので、起動回路２４は割り込み起動要求をマイコン８０に出力する（Ｓ４３０）。この際、起動回路２４は割り込み起動要求を出力したことをフラグなどで記録する。

スケジュール手段３６は割り込み起動要求を取得したことで図９の手順を実行し、優先度の低いアプリＢに異常が検出された場合にはスケジュールを変更し、優先度の高いアプリＡに異常が検出された場合にはスケジュールを変更しない。

例えば、スケジュールを変更した場合（Ｓ２１０のＹｅｓ）、同様に、スケジュール手段３６はアプリＡの起動タイミングになると、アプリＡに対応したフラグＦａをクリアし（Ｓ２６０）、アプリＢを起動するので（Ｓ２７０）、実行状態更新部ＡがフラグＦａに“１”を設定する（Ｓ３２０）。

しかし、スケジュールを変更した場合（Ｓ２１０のＹｅｓ）、スケジュール手段３６は、アプリＢの起動タイミングでアプリＢを起動せず、フラグＦｂに“１”を設定する（Ｓ２８０）。これにより、アプリＢが起動されなくても、ＡＮＤ回路２０がＷＤＣパルスをＷＤＴ２２に出力することができる（Ｓ３３０）。

一方、優先度の高いアプリＡに異常が検出された場合にはスケジュールが変更されないので（Ｓ２１０のＮｏ）、アプリＡが起動されるが、異常が検出されたアプリＡはフラグＦａに“１”を設定しないと考えられる。このため、ＷＤＴ２２が2回目のオーバーフローをする。

ＷＤＴ２２がオーバーフローした場合（Ｓ４１０のＹｅｓ）、起動回路２４がそれを検出し、すでに割り込み起動要求を出力したか否かを判定するが（Ｓ４２０）、起動回路２４はすでに割り込み起動要求を出力しているので、割り込み起動要求を出力することなくリセット回路２１にリセットを要求する（Ｓ４４０）。これにより、リセット回路２１がマイコン８０をリセットすることができる。なお、起動回路２４は割り込み起動要求の出力回数をカウントしておき、所定回数に到達した場合にリセット回路２１にリセットさせることもできる。

〔３つ以上のアプリがある場合〕
本実施例の電子制御装置１００は、実施例１と同様にマイコン８０が３つ以上のアプリを実行する場合も好適に適用できる。

図１１（ａ）は３つ以上のアプリを有する電子制御装置１００の一例を示す。マイコン８０はｎ個のアプリＡ〜ｎに対応してｎ個のフラグＦａ〜Ｆｎを有している。起動・監視回路９０には変更がない。

設計者は、異常が生じた際に他のアプリを停止してもマイコン８０をリセットすべきかどうかの観点から、３つ以上のアプリをある優先度（閾値）を基準に、低優先度アプリと高優先度アプリに分類してスケジュール手段３６に登録しておく。または、スケジュール手段３６に、閾値となる優先度を登録しておけば、異常があると推定したアプリ１７が高優先度か低優先度かを判定できる。

これにより、スケジュール手段３６は、異常があると推定したアプリ１７が高優先度の場合はスケジュールを変更しないのでマイコン８０をリセットすることができる。低優先度の場合は、スケジュールを変更してアプリ１７に対応するフラグＦに“１”を設定するので、高優先度のアプリ１７を停止することなく低優先度のアプリ１７のみ停止することができる。

また、スケジュール手段３６は、リセット対象外の低優先度のアプリでも２つ以上の異常が検出された場合、スケジュールの変更を停止し、マイコン８０をリセットするように誘導することができる。

図１１（ｂ）は、マイコン８０と起動・監視回路９０を別のＥＣＵ１，２に搭載したＥＣＵシステムの一例を示す図である。図１１（ｂ）ではマイコン８０と起動・監視回路９０がいずれもＣＡＮ通信部３３を有し、ＣＡＮバス３４を介して通信することができる。

この場合、ＡＮＤ回路２０のオンを検出した通信用アプリがＣＡＮバス３４を介してＥＣＵ２に通知するので、ＥＣＵ２も所定のプログラムによりＷＤＴ２２をクリアする。ＷＤＴ２２がオーバーフローした場合、起動回路２４に相当する所定のプログラムがＣＡＮバス３４を介して割り込み起動要求をＥＣＵ１に送信する。ＷＤＴ２２が再度オーバーフローした場合、リセット回路２１はリセット信号をリセット端子１３に出力する。これにより、ＥＣＵ１のマイコン８０はリセットされる。

したがって、マイコン８０と起動・監視回路９０が別のＥＣＵに搭載された場合でも、異常が検出されたアプリの優先度に応じて、マイコン８０をリセットするかどうかを制御できる。

以上説明したように、本実施例の電子制御装置１００は、実施例１と同様の効果に加え、マイコン８０がアプリ１７の起動制御をすることで、マイコン８０と外部の起動・監視回路９０の間の結線を少くすることができる。

１１ ＲＡＭ
１２ ＣＰＵ
１３ リセット端子
１４ ＲＯＭ
１５ ＩＮＴＣ
２１ リセット回路
２２ ＷＤＴ
２３ Ｉ／Ｏ
２４ 起動回路
８０ マイコン
９０ 起動・監視回路
１００ 電子制御装置

Claims (8)

1. 複数のアプリケーションを実行するプロセッサを備えたマイコン及びマイコンをリセットするリセット手段を備えた監視回路を有する車両用の電子制御装置であって、
   前記監視回路は、アプリケーション毎に定められた起動タイミングで前記マイコンに繰り返し各アプリケーションの起動要求を出力する起動要求手段と、
   各アプリケーション毎に異常を検出する異常検出手段と、を有し、
   前記異常検出手段が異常を検出したアプリケーションの優先度が閾値以下の場合、前記起動要求手段は該アプリケーションの起動要求を停止し、
   前記異常検出手段が異常を検出したアプリケーションの優先度が前記閾値より大きい場合にのみ、前記リセット手段がマイコンをリセットし、
   前記異常検出手段が、優先度が前記閾値以下の複数のアプリケーションの異常を検出した場合、前記リセット手段がマイコンをリセットする、
   ことを特徴とする電子制御装置。
2. 複数のアプリケーションを実行するプロセッサを備えたマイコン及びマイコンをリセットするリセット手段を備えた監視回路を有する電子制御装置であって、
   前記マイコンは、スケジュールにしたがって各アプリケーションを繰り返し起動させるスケジュール制御手段と、
   複数のアプリケーションのそれぞれに対応して設けられたフラグと、
   複数の前記フラグのそれぞれに接続され、各アプリケーションが正常に動作している場合に対応する前記フラグをＯＮにして、全ての前記フラグがＯＮになると前記監視回路に正常通知を出力する正常通知手段と、を有し、
   前記監視回路は、前記正常通知を送信するための線で前記正常通知手段と接続され、前記正常通知の有無によりいずれかのアプリケーションの異常を検出する１つの異常検出手段と、
   前記異常検出手段がアプリケーションの異常を検出したことを前記マイコンに通知する異常通知手段と、を有し、
   前記スケジュール制御手段は異常が生じたアプリケーションを、異常が検出された際に実行していたアプリケーションに基づき推定し、該アプリケーションの優先度が閾値以下の場合、該アプリケーションを起動対象から除外すると共に、該アプリケーションに対応した前記フラグをＯＮにし、前記正常通知手段は、前記監視回路に正常通知を出力する、
   ことを特徴とする電子制御装置。
3. 異常が生じたアプリケーションの優先度が閾値以下でない場合、前記スケジュール制御手段は該アプリケーションを起動対象から除外せず、
   前記リセット手段は、前記異常通知手段が前記マイコンにアプリケーションの異常を検出したことを通知した後、再度、前記異常検出手段がアプリケーションの異常を検出した場合、マイコンをリセットする、ことを特徴とする請求項２記載の電子制御装置。
4. 前記スケジュール制御手段は異常が生じたと推定したアプリケーションの優先度が閾値以下の場合、該アプリケーションを強制的に終了する、
   ことを特徴とする請求項２又は３記載の電子制御装置。
5. 前記スケジュール制御手段が、異常があると推定した優先度が閾値以下のアプリケーションの数が所定数以上になった場合、異常があると推定されたアプリケーションに対応する前記フラグをＯＮにすることなく、前記正常通知手段は前記監視回路に正常通知を出力しない、ことを特徴とする請求項２記載の電子制御装置。
6. 前記異常検出手段はウォッチドッグタイマである、ことを特徴とする請求項１又は２記載の電子制御装置。
7. 複数のアプリケーションを実行するプロセッサを備えたマイコン及びマイコンをリセットするリセット手段を備えた監視回路を有する車両用の電子制御装置の起動制御方法であって、
   前記監視回路が、アプリケーション毎に定められた起動タイミングで前記マイコンに繰り返し各アプリケーションの起動要求を出力するステップと、
   異常検出手段が各アプリケーション毎に異常を検出するステップと、
   前記異常検出手段が異常を検出したアプリケーションの優先度が閾値以下の場合、起動要求手段は該アプリケーションの起動要求を停止するステップと、
   前記異常検出手段が異常を検出したアプリケーションの優先度が前記閾値より大きい場合にのみ、前記リセット手段がマイコンをリセットするステップと、
   前記異常検出手段が、優先度が前記閾値以下の複数のアプリケーションの異常を検出した場合、前記リセット手段がマイコンをリセットするステップと、
   を有することを特徴とする起動制御方法。
8. 複数のアプリケーションを実行するプロセッサを備えたマイコン及びマイコンをリセットするリセット手段を備えた監視回路を有する電子制御装置の起動制御方法であって、
   前記マイコンのスケジュール制御手段が、スケジュールにしたがって各アプリケーションを繰り返し起動させるステップと、
   各アプリケーションが、正常に動作している場合にアプリケーションのそれぞれに対応して設けられたフラグをＯＮにするステップと、
   アプリケーションの全てが正常に動作して前記フラグが全てＯＮになると、正常通知手段が、接続された線を介して前記監視回路に正常通知を出力するステップと、
   前記監視回路の１つの異常検出手段が、前記正常通知の有無によりいずれかのアプリケーションの異常を検出するステップと、
   異常通知手段が、前記異常検出手段がアプリケーションの異常を検出したことを前記マイコンに通知するステップと、
   前記スケジュール制御手段が、異常が生じたアプリケーションを、異常が検出された際に実行してたアプリケーションに基づき推定するステップと、
   推定されたアプリケーションの優先度が閾値以下の場合、該アプリケーションを起動対象から除外すると共に、該アプリケーションに対応した前記フラグをＯＮにするステップと、
   前記正常通知手段が、前記監視回路に正常通知を出力するステップと、
   を有することを特徴とする起動制御方法。

Images