(57)【要約】【課題】リソースに制約がある場合にも、個別に実行中のアプリの異常を検出して、領域毎にＲＯＭチェック可能な電子制御装置を提供すること。【解決手段】複数のプログラムを記憶するプログラム記憶手段２４と、プログラムを順次読み出して実行する演算手段２３と、演算手段のプログラム実行処理に異常が生じているか否かを検出する異常検出手段２７と、演算手段が実行中の前記プログラムの識別情報を記憶する実行プログラム識別情報記憶手段Ｆ１と、異常検出手段がプログラム実行処理に異常が生じていることを検出した場合、記実行プログラム識別情報記憶手段に記憶されている識別情報の前記プログラムが記憶されている領域をメモリチェックし、前記実行プログラム識別情報記憶手段に実行中であることが記憶されていない前記プログラムが記憶されている領域をメモリチェックしないメモリチェック手段３９と、を有することを特徴とする電子制御装置１００を提供する。【選択図】図１
2013152563.tif 000002
【特許請求の範囲】
【請求項１】
複数のプログラムを記憶するプログラム記憶手段と、
前記プログラムを順次読み出して実行する演算手段と、
前記演算手段のプログラム実行処理に異常が生じているか否かを検出する異常検出手段と、
前記演算手段が実行中の前記プログラムの識別情報を記憶する実行プログラム識別情報記憶手段と、
前記異常検出手段がプログラム実行処理に異常が生じていることを検出した場合、前記実行プログラム識別情報記憶手段に記憶されている前記識別情報の前記プログラムが記憶されている領域をメモリチェックし、前記実行プログラム識別情報記憶手段に実行中であることが記憶されていない前記プログラムが記憶されている領域をメモリチェックしないメモリチェック手段と、
を有することを特徴とする電子制御装置。
【請求項２】
前記メモリチェック手段が前記領域のメモリ異常を検出した場合、前記実行プログラム識別情報記憶手段に記憶されている前記識別情報の前記プログラムに実行禁止フラグを設定する実行禁止フラグ設定手段と、
前記演算手段が前記プログラムを読み出して実行する際、前記実行禁止フラグが設定された前記プログラムの実行を禁止し、前記プログラム記憶手段にて、実行が禁止された前記プログラムの次に記憶されているプログラムを読み出して前記演算手段に実行させる実行制御手段と、
を有することを特徴とする請求項１記載の電子制御装置。
【請求項３】
前記メモリチェック手段が前記領域のメモリ異常を検出しない場合、前記実行プログラム識別情報記憶手段に記憶されている前記識別情報の前記プログラムに時間計測フラグを設定する時間計測フラグ設定手段と、
前記演算手段が前記プログラムを読み出して実行する際、前記時間計測フラグが設定された前記プログラムの実行前に、時間計測タイマに時間計測を開始させ、前記プログラムの実行終了後に前記時間計測タイマをクリアするタイマ操作手段と、
を有することを特徴とする請求項１記載の電子制御装置。
【請求項４】
前記タイマ操作手段が前記時間計測タイマをクリアする前に、前記時間計測タイマが所定時間の経過を計測した場合、
前記実行プログラム識別情報記憶手段に記憶されている前記識別情報の前記プログラムに実行禁止フラグを設定する実行禁止フラグ設定手段と、
前記演算手段が前記プログラムを読み出して実行する際、前記実行禁止フラグが設定された前記プログラムの実行を禁止し、前記プログラム記憶手段にて、実行が禁止された前記プログラムの次に記憶されているプログラムを読み出して前記演算手段に実行させる実行制御手段と、
を有することを特徴とする請求項３記載の電子制御装置。
【請求項５】
前記異常検出手段は、前記プログラム実行処理に異常が生じていることを検出した場合に前記演算手段をリセットするウォッチドッグタイマであり、
前記メモリチェック手段は、リセットにより前記演算手段が再起動した後、前記プログラムの実行を開始する前に、前記実行プログラム識別情報記憶手段に記憶されている前記識別情報の前記プログラムが記憶されている領域をメモリチェックする、
ことを特徴とする請求項１〜４いずれか１項記載の電子制御装置。
【請求項６】
複数のプログラムを記憶するプログラム記憶手段と、
前記プログラムを順次読み出して実行する演算手段と、
前記演算手段のプログラム実行処理に異常が生じているか否かを検出する異常検出手段と、を有する電子制御装置のメモリチェック方法であって、
前記演算手段が実行中の前記プログラムの識別情報を実行プログラム識別情報記憶手段に記憶するステップと、
前記異常検出手段がプログラム実行処理に異常が生じていることを検出した場合、メモリチェック手段は、前記実行プログラム識別情報記憶手段に実行中であることが記憶されていない前記プログラムが記憶されている領域をメモリチェックせず、
前記実行プログラム識別情報記憶手段に記憶されている前記識別情報の前記プログラムが記憶されている領域をメモリチェックするステップと、
を有することを特徴とするメモリチェック方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム実行処理に異常が生じているか否かを検出し、ＲＯＭチェックすることが可能な電子制御装置に関する。
【背景技術】
【０００２】
エンジンやブレーキなどの車載装置をマイコンなどで制御する電子化が進んでいる。このため、車両には種々の電子制御装置が搭載されており、各電子制御装置はそれぞれ制御対象のアクチュエータ等を制御する。電子制御装置はコンピュータの一態様であるため、ＣＰＵがフラッシュメモリなどの不揮発性の記憶装置に記憶されているプログラムを、必要であればパラメータを使用して実行することで車載装置を適切に制御する。
【０００３】
一般に、不揮発性の記憶装置の情報保持期間は十分に長いので、プログラムやパラメータが消失することはない。しかしながら、上記のプログラムは車両が駐車されていれば車両と共に駐車場などに放置される。また、無線通信装置によりネットワークに接続することも可能な車両も増えている。このため、第三者が故意にプログラムを書き換えたり、一部を消去したりする作為的な改竄が行われるおそれがある。また、電磁波の影響や何らかのプログラムの実行により記憶装置内のプログラムが書き換わる可能性がある。
【０００４】
従来から、プログラムやパラメータの書き換えを検出する技術が考えられている（例えば、特許文献１、２参照。）。特許文献１には、不揮発性メモリの記憶領域を複数のサブプログラムの実行順序に基づいて分割しておき、サブプログラムの実行順序に従って、順次、次に実行されるサブプログラムを記憶する一の分割領域のメモリチェックを実行する車両用制御装置が開示されている。また、特許文献２には、ウォッチドッグタイマがその時間内でリセットされず、ＭＰＵに割込がかけられた場合には、プログラム領域及びデータ領域に対しメモリエラーチェックを行う画像形成装置が開示されている。
【０００５】
また、電子制御装置の機能統合や高機能化などにより一台の電子制御装置に複数のアプリが搭載されることがある。電子制御装置のＣＰＵはアプリを順番に実行したり、割込みにより起床したタスクを優先度順に実行するなどしている。
【０００６】
このような実行中のアプリに対し、アプリの実行状態を個別に監視する技術が考えられている（例えば、特許文献３参照。）。特許文献３には、アプリの異常が確認された場合、シーケンス制御部が中断し、エラー処理の終了後に直近の後続のアプリを実行する一時的エラーの処理方法が開示されている。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−１２６４５１号公報
【特許文献２】特開２００７−１３６８６２号公報
【特許文献３】特開２００９−１２９４６３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
アプリの動作を保証するには、ＲＯＭなどの記憶装置に記憶されているアプリのチェックだけでなく、実行中のアプリの個別監視が行われることが好ましい。前者のＲＯＭチェックについて、特許文献１に記載された車両用制御装置は起動時に一度だけしかＲＯＭチェックしないので、実行中にＲＯＭチェックすることができない。例えば、定期的にＲＯＭチェックすることも考えられるが、こうすると処理負荷が増大してしまう。
【０００９】
特許文献１の不都合に対し、特許文献２に記載されているように、異常が生じた場合にＲＯＭチェックすることが考えられる。しかし、特許文献２では、異常が生じたアプリを特定することなくＲＯＭの全体をＲＯＭチェックしており、ＲＯＭチェックに時間がかかってしまう。
【００１０】
後者の実行中のアプリの個別監視について、特許文献３に記載された一時的エラーの処理方法では、実行中のアプリを個別に監視しているが、ＯＳ（Operating  System）などのリソースが必要になってしまう。車載される電子制御装置のマイコンにはＯＳが搭載されないローエンドなものもあり、ＯＳを前提とするアプリ監視方法では電子制御装置に搭載できないことがある。
【００１１】
本発明は、上記課題に鑑み、リソースに制約がある場合にも、個別に実行中のアプリの異常を検出して、領域毎にＲＯＭチェック可能な電子制御装置を提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明は、複数のプログラムを記憶するプログラム記憶手段と、前記プログラムを順次読み出して実行する演算手段と、前記演算手段のプログラム実行処理に異常が生じているか否かを検出する異常検出手段と、前記演算手段が実行中の前記プログラムの識別情報を記憶する実行プログラム識別情報記憶手段と、前記異常検出手段がプログラム実行処理に異常が生じていることを検出した場合、前記実行プログラム識別情報記憶手段に記憶されている前記識別情報の前記プログラムが記憶されている領域をメモリチェックし、前記実行プログラム識別情報記憶手段に実行中であることが記憶されていない前記プログラムが記憶されている領域をメモリチェックしないメモリチェック手段と、を有することを特徴とする電子制御装置を提供する。
【発明の効果】
【００１３】
リソースに制約がある場合にも、個別に実行中のアプリの異常を検出して、領域毎にＲＯＭチェック可能な電子制御装置を提供することができる。
【図面の簡単な説明】
【００１４】
【図１】ＲＯＭチェックの概要的な手順を説明する図の一例である。
【図２】電子制御装置のブロック図の一例である。
【図３】マイコンの機能ブロック図の一例である。
【図４】ＲＯＭに記憶された各アプリとその領域の一例を示す図である。
【図５】初期処理の動作手順の一例、実行フラグチェックの手順の一例、及び、異常検出タイマ割込みが生じた場合の処理の一例を、示す図である。
【図６】実行制御部により手順が制御されるメイン処理のフローチャート図の一例である。
【図７】ＲＯＭチェックの処理のフローチャート図の一例をそれぞれ示す。
【発明を実施するための形態】
【００１５】
以下、本発明を実施するための形態について図面を参照しながら説明する。
図１は、本実施形態のＲＯＭチェックの概要的な手順を説明する図の一例である。
【００１６】
Ｓ１）アプリに異常が生じてない初期状態では、電子制御装置は、ＷＤＴ（Ｗａｔｃｈ  Ｄｏｇ  Ｔｉｍｅｒ）２７により全アプリをまとめて監視している。電子制御装置は、ＡＡアプリ〜ＮＮアプリを順番に実行した後、ＷＤＴクリア部によりＷＤＴ２７をクリアしている。ＡＡアプリ〜ＮＮアプリに異常がなければ、オーバーフローする前にＷＤＴ２７がクリアされる。この場合、電子制御装置はＷＤＴ２７によりリセットされることなく、ＡＡアプリ〜ＮＮアプリ、ＷＤＴクリア部２７の実行を繰り返す。
【００１７】
Ｓ２）ＡＡアプリ〜ＮＮアプリの１つに異常が生じた場合、ＷＤＴ２７がオーバーフローするためＷＤＴ２７は電子制御装置をリセットする。
【００１８】
Ｓ３）電子制御装置は、フラグなどによりリセットを生じさせたアプリを特定し、該アプリが記憶されているＲＯＭの領域をＲＯＭチェックする。
【００１９】
Ｓ４）電子制御装置は、ＲＯＭチェックの結果に基づき、ＲＯＭが書き換えられているために特定のアプリに異常が生じたか否かを判定する。
【００２０】
Ｓ５）ＲＯＭチェックにより異常が検出された場合、電子制御装置はＲＯＭが書き換えられた特定のアプリの実行を禁止する。
【００２１】
Ｓ６）ＲＯＭチェックにより異常が検出されない場合、電子制御装置はＲＯＭチェックした領域のアプリの実行を許可するが、次回からアプリの実行時間を監視する。すなわち、ＲＯＭチェックでは異常を検出できないが、リセットを生じさせたアプリは、再度、異常が生じる可能性があるので、個別に実行時間を監視する。この結果、実行時間が基準時間よりオーバーすると、Ｓ５と同様にこの特定のアプリの実行を禁止する。以降、Ｓ２でＷＤＴ２７にリセットを生じさせたアプリは実行されないので、同じ原因（アプリ）によりリセットが発生することを防止できる。
【００２２】
このように、本実施形態の電子制御装置は、リセットが生じた場合にだけＲＯＭチェックするので、ＣＰＵ負荷の増大を抑制できる。また、ＲＯＭチェックにより異常が検出されたアプリを個別に実行禁止でき、次回以降、同じアプリでリセットが生じることを回避できる。ＲＯＭチェックにより異常が検出されない場合でも、アプリの実行時間を個別に監視し、実行時間が基準時間よりオーバーすると特定のアプリの実行を禁止することができる。したがって、この場合も、同じアプリでリセットが生じることを回避できる
このように、多くのリソースを必要とせざるを得ないＯＳ（Operating  System）などを使用せずに、アプリの異常を個別に検出し、異常のないアプリの実行を継続できる。
【００２３】
〔構成例〕
図２は、電子制御装置のブロック図の一例を示す。電子制御装置１００は、入力Ｉ／Ｆ１１、電源回路１４、マイクロコンピュータ１２（以下、マイコン１２という）、及び、出力Ｉ／Ｆ１３を有する。この他、ＣＡＮコントローラのような他の電子制御装置と通信するための通信装置等を有しているが、図示を省略した。
【００２４】
車載される電子制御装置１００には種々のものがある。例えば、ＨＶ−ＥＣＵ（Electronic  Control  Unit）、エンジンＥＣＵ、ブレーキＥＣＵ、ボディＥＣＵ、パワステＥＣＵ、ナビゲーションＥＣＵ（ＡＶ・情報処理ＥＣＵ）、ゲートウェイＥＣＵ等が知られている。本実施例の電子制御装置１００はこれら機能の違いに影響されることなく、アプリの異常を検出することが可能である。
【００２５】
電源回路１４はＩＧ−ＳＷ１５のＯＮ／ＯＦＦを検出する。ＩＧ−ＳＷ１５のＯＮを検出した場合、電源回路１４はバッテリ１６から供給される電力を必要に応じて降圧して、入力Ｉ／Ｆ１１、マイコン１２及び出力Ｉ／Ｆ１３に供給する。また、ＩＧ−ＳＷ１５のＯＦＦを検出した場合、電源回路１４は各回路への電力の供給を停止するが、例えば、ＲＡＭ２５にだけ電力を供給してパラメータを保持するとしてもよい。このようなＩＧ−ＯＦＦ時の省電力制御により、電子制御装置１００は、ＩＧ−ＯＮ時に演算した（学習した）パラメータを、次回のＩＧ−ＯＮ後に使用でき、操作性などを向上させることができる。
【００２６】
入力Ｉ／Ｆ１１には、各種のセンサが接続されている。入力Ｉ／Ｆ１１はマルチプレクサとして機能し、各センサの検出信号を時分割又は優先度に基づき読み出し、センサの識別情報と共にマイコン１２のＡ／Ｄ２１又はＩ／Ｏ２２に送信する。なお、マイコン１２はどのセンサからの入力かを、識別情報ではなく動作クロックにより識別してもよい。また、入力Ｉ／Ｆ１１は、ＣＰＵ２３からの指示によりセンサから検出信号を取得する場合と、指示がなくてもセンサから検出信号を取得する場合がある。
【００２７】
マイコン１２は、バスを介してＣＰＵ２３と接続されたＡ／Ｄ２１、Ｉ／Ｏ２２、フラッシュＲＯＭ２４、ＲＡＭ２５、Ｉ／Ｏ２６及びＷＤＴ２７を有する。Ｉ／Ｏ２２は、入力Ｉ／Ｆ１１から入力された検出信号を検出信号の種別と共に、割込みなどの仕組みを利用してＣＰＵ２３に通知する。また、Ａ／Ｄ２１はアナログの検出信号をデジタルの検出信号に変換する回路であり、変換後の検出信号を検出信号の種別と共に、割込みなどの仕組みを利用してＣＰＵ２３に通知する。
【００２８】
ＷＤＴ２７は、動作クロックをコントロールレジスタなどに設定されている分周比で分周して、時間の経過をカウントアップする回路である。そして、計測した時間が予め定められたリセット時間に達すると（オーバーフローすると）、マイコン１２をリセットするなどのフェールセーフ処理を行う。ＣＰＵ２３は、ＷＤＴ２７がオーバーフローする前に定期的に計測されている時間をクリアする。したがって、ＷＤＴ２７がマイコン１２をリセットしない間は、ＣＰＵ２３が各アプリを想定される時間内に実行していることが推定できる。なお、ＷＤＴ２７は、マイコン内でなくマイコン外の電子制御装置上に配置されていてもよい。
【００２９】
ＣＰＵ２３は、フラッシュＲＯＭ２４に記憶されているプログラムを実行して、検出信号の読み取り、演算、マップ引き、ＲＡＭ２５への書き込み又はＩ／Ｏ２６への出力を行う。これらの具体的な処理内容は電子制御装置１００の種類や、アプリによって異なる。フラッシュＲＯＭ２４に記憶されているアプリについては後述する。なお、フラッシュＲＯＭ２４は不揮発メモリであればよく、例えば、磁気抵抗RAM（MRAM)、強誘電体メモリ（FeRAM)、PCM（相変化メモリ）、ReRAM（抵抗変化型メモリ）などでもよい。
【００３０】
後段のＩ／Ｏ２６は、ＣＰＵ２３からの指示により、制御対象の識別情報やチップ選択線のアサートと共に演算結果を出力Ｉ／Ｆ１３に出力する。出力Ｉ／Ｆ１３は、各種のアクチュエータと接続されている。出力Ｉ／Ｆ１３は、例えばＤ／Ａ変換した電圧値等をアクチュエータに出力することでアクチュエータを制御する。また、出力Ｉ／Ｆ１３は例えば、スイッチ素子であり、ソレノイドに通電しリレーなどの開閉を制御する。また、出力Ｉ／Ｆ１３は例えば、ドライバ回路であり、直流電圧を交流電圧に変換してモータの回転数を制御する。
【００３１】
電子制御装置１００がＨＶ−ＥＣＵの場合、電子制御装置１００は、エンジン回転数及びモータ出力をそれぞれ決定する処理、バッテリ１６のＳＯＣを制御する処理、などを行う。入力Ｉ／Ｆ１１にはアクセル開度、車速、モータ回転角、エンジン回転数等が入力される。ＣＰＵ２３は、マップなどを参照して最適な燃費効率のエンジン回転数及びモータ出力をそれぞれ決定し、出力Ｉ／Ｆ１３からエンジンＥＣＵやモータＥＣＵに演算した出力を要求する。
【００３２】
電子制御装置１００がエンジンＥＣＵの場合、電子制御装置１００は、燃料噴射量の制御、点火時期制御、スロットル開度制御等を行う。入力Ｉ／Ｆ１１にはアクセル開度、車速、エンジン回転数等が入力される。ＣＰＵ２３は、燃料噴射量や点火タイミング、スロットル開度を決定し、出力Ｉ／Ｆ１３から各種のアクチュエータに制御信号を出力する。
【００３３】
また、電子制御装置１００がブレーキＥＣＵの場合、ブレーキＥＣＵは各車輪のホイルシリンダ圧を制御する。入力Ｉ／Ｆ１１には車速、減速度、ストップランプスイッチ等が入力される。ＣＰＵ２３は車速からスリップ等を検出するとブレーキアクチュエータの複数の電磁開閉弁の開閉状態を決定し、出力Ｉ／Ｆ１３からブレーキアクチュエータに制御信号を出力する。
【００３４】
図３は、マイコン１２の機能ブロック図の一例を示す。実行フラグＦ１は、各アプリ４３の実行中にＯＮとなるフラグである。すなわち、実行開始前にＯＮとなり、実行終了後、次のアプリの実行開始前にＯＦＦとなる。マイコン１２のリセット後、実行フラグＦ１がＯＮのアプリは、ＲＯＭチェックの対象となる。
【００３５】
時間計測フラグＦ３は、ＲＯＭチェックにより異常が認められないアプリに対しＯＮとなるフラグである。時間計測フラグＦ３がＯＮのアプリは、実行時に異常検出タイマ３１がセットされることで実行時間の監視対象となる。
【００３６】
異常フラグＦ２は、ＲＯＭチェックにより異常が認められたアプリ、又は、時間計測フラグＦ３により実行時間が計測され、基準時間をオーバーしたアプリに対しＯＮとなるフラグである。異常フラグＦ２がＯＮになったアプリは実行されない。
【００３７】
電子制御装置１００は、主に、アプリを順番に実行する実行制御部３５と、ＩＧ−ＯＮ又はリセット後に初期処理を行う初期処理部３６とを有している。実行制御部３５は、各種のフラグを参照しながらＡＡアプリ〜ＮＮアプリ、及び、ＷＤＴクリア部４４を順番に実行する。実行制御部３５は各アプリ４３の実行開始前に、異常フラグＦ２を参照して、異常フラグＦ２がＯＮのアプリの実行を禁止する。
【００３８】
アプリを実行する場合、実行制御部３５は実行フラグセット部３２を呼び出す。実行フラグセット部３２は実行するアプリに対応づけられた実行フラグＦ１をＯＮに設定する。アプリが終了すると、実行制御部３５は実行フラグセット部３２を呼び出す。実行フラグセット部３２はＯＮに設定した実行フラグＦ１をＯＦＦに設定する。ＣＰＵがシングルコアの場合、同時期にＯＮになっている実行フラグＦは１つである。よって、ＯＮになっていた実行フラグＦ１をＯＦＦにすればよい。ＣＰＵがマルチコアの場合、同時期にＯＮになっている実行フラグＦは複数あるので、実行フラグセット部３２は、実行が終了したアプリの実行フラグＦ１をＯＦＦに設定する。
【００３９】
また、実行制御部３５は、アプリの実行開始前に、時間計測フラグＦ３がＯＮか否かを判定する。時間計測フラグＦ３がＯＮとなっているアプリは複数、あり得る。時間計測フラグＦ３がＯＮの場合、実行制御部３５は異常検出タイマセット部３３を呼び出す。異常検出タイマセット部３３は異常検出タイマ３１に基準時間をセットする。アプリが終了すると、実行制御部３５は異常検出タイマクリア部３４を呼び出す。異常検出タイマクリア部３４は異常検出タイマ３１をクリアする。なお、基準時間はＷＤＴ２７がオーバーフローするリセット時間よりも短い時間（例えば、リセット時間／アプリ数）に設定されている。
【００４０】
異常検出タイマ３１は、実行時間が基準時間をオーバーすると、タイマ割込みを発生させ、ＣＰＵ２３に異常フラグセット部４１を実行させる。これにより、異常フラグセット部４１は異常フラグＦ２をＯＮに設定する。この後、処理は、タイマ割込みが発生する前のアドレスに戻る。この場合、このアドレスのアプリの実行が完了しないので、マイコン１２はリセットされる可能性が高い。
【００４１】
ＮＮアプリまで実行が完了すると、ＣＰＵ２３はＷＤＴクリア部４４を実行する。ＷＤＴクリア部４４はＷＤＴ２７をクリアする。実行制御部３５は、以上のような処理を繰り返す。
【００４２】
初期処理部３６は、ＩＧ−ＯＮ又リセットの直後、割込みチェック部３７を呼び出す。割込みチェック部３７は例えば、割込みの発生状況を検出する。
【００４３】
次に、初期処理部３６は、実行フラグチェック部３８を呼び出す。実行フラグチェック部３８は、実行フラグＦ１がＯＮとなっているアプリを検出する。すなわち、実行フラグＦ１がＯＮのアプリは、実行フラグＦ１がＯＦＦになる前に終了したアプリである。実行フラグＦ１がＯＮのアプリがある場合、初期処理部３６は、ＲＯＭチェック部３９に実行フラグＦ１がＯＮのアプリが記憶されているフラッシュＲＯＭ２４の領域のＲＯＭチェックを要求する。
【００４４】
ＲＯＭチェック部３９は、フラッシュＲＯＭ２４の領域を例えばＲＯＭＳＵＭ手法によりＲＯＭチェックして、アプリが記憶されたフラッシュＲＯＭ２４の領域に異常があるか否かを判定する。異常がある場合、ＲＯＭチェック部３９は異常フラグセット部４１を呼び出す。異常フラグセット部４１は異常フラグＦ２をＯＮに設定する。異常がない場合、ＲＯＭチェック部３９は時間計測フラグセット部４２を呼び出す。時間計測フラグセット部４２は時間計測フラグＦ３をＯＮに設定する。異常フラグＦ２と時間計測フラグＦ３により、実行制御部３５がアプリを実行制御できるようになる。なお、ＲＯＭチェックが終了したアプリの実行フラグはＯＦＦになる。
【００４５】
図４は、フラッシュＲＯＭ２４に記憶された各アプリ４３とその領域の一例を示す図である。フラッシュＲＯＭ２４にはアドレス順に、例えば初期処理部３６、実行制御部３５、ＡＡアプリ、ＢＢアプリ、…、ＮＮアプリ及びＷＤＴクリア部４４が記憶されている。ＣＰＵ２３はゼロ番地のアドレスから順番に実行していくので、初期処理部３６が実行完了するとＡＡアプリから順番にＷＤＴクリア部４４まで実行される（その間、分岐等があるにしても）。なお、ＷＤＴクリア部４４をアプリの末尾に記憶せずに、実行制御部３５に記憶するなどしてもよく、図示する記憶領域は一例である。本実施形態では、ＯＳのようなシステム部が記憶されていないことが特徴である。
【００４６】
実行制御部３５は例えばmain関数として実装されており、各アプリ４３の実行手順を制御する。実行制御部３５の機能（つまり、実行フラグＦ１，異常フラグＦ２、時間計測フラグＦ３に基づく制御）をアプリの一部として各アプリ内に実装してもよい。
【００４７】
各アプリ４３の領域は固定であり、各領域のアドレス範囲は予め初期処理部３６（より具体的にはＲＯＭチェック部）に登録されている。このため、初期処理部３６にはＲＯＭＳＵＭテーブル４５が登録されている。ＲＯＭＳＵＭテーブル４５には、各アプリ４３の開始番地と終了番地、及び、ＲＯＭＳＵＭ値が登録されている。後述するように、ＲＯＭチェック部３９は、各アプリ４３が記憶された領域を開始番地と終了番地から特定し、該領域のＲＯＭ値の合計を算出する。そして、ＲＯＭＳＵＭテーブル４５の値と比較することで、ＲＯＭチェックを行う。なお、終了番地でなく、プログラムサイズを登録しても、各アプリの領域を特定できる。
【００４８】
〔動作手順〕
図５（ａ）は、初期処理の動作手順の一例を、図５（ｂ）は実行フラグチェックの手順の一例を、図５（ｃ）は異常検出タイマの割込みが生じた場合の処理の一例を、それぞれ示す。また、図６は、実行制御部３５により手順が制御されるメイン処理のフローチャート図の一例を、図７はＲＯＭチェックの処理のフローチャート図の一例をそれぞれ示す。
【００４９】
ＩＧ−ＯＮ又はリセットにより図５（ａ）の初期処理の実行が開始される。ここでは、割込みチェック、実行フラグチェック、イニシャル処理が終了し、メイン処理の実行が開始されたものとする。
【００５０】
・メイン処理
実行制御部３５は、ＡＡアプリの異常フラグＦ２_ＡＡを参照して、ＡＡアプリに異常が検出されているか否かを判定する（Ｓ１００）。
【００５１】
ＡＡアプリに異常が検出されている場合（Ｓ１００のＹｅｓ）、実行制御部３５はＡＡアプリを実行せずに、異常フラグＦ２_ＢＢを参照してＢＢアプリに異常が検出されているか否かを判定する。このように、異常フラグＦ２がＯＦＦのアプリのみがＣＰＵ２３に割りあてられ実行される。
【００５２】
ＡＡアプリに異常が検出されていない場合（Ｓ１００のＮｏ）、実行フラグセット部３２が実行フラグＦ１_ＡＡをＯＮに設定する（Ｓ２００）。その他の実行フラグＦ１_ＢＢ〜Ｆ_ＮＮはＯＦＦのままである。
【００５３】
次に、実行制御部３５は時間計測フラグＦ３_ＡＡがＯＮに設定されているか否かを判定する（Ｓ３００）。時間計測フラグＦ３_ＡＡの初期状態はＯＦＦである。
【００５４】
時間計測フラグＦ３_ＡＡがＯＦＦの場合（Ｓ３００のＹｅｓ）、実行制御部３５はＡＡアプリの実行を開始する（Ｓ５００）。なお、実行フラグセット部３２はアプリの実行が完了すると実行フラグＦ１_ＡＡをＯＦＦに設定する。
【００５５】
以上の、Ｓ１００、Ｓ２００、Ｓ３００、及び、Ｓ５００を通過する処理手順が、アプリが正常な場合の正常実行パスである。
【００５６】
時間計測フラグＦ３_ＡＡがＯＮの場合（Ｓ３００のＹｅｓ）、異常検出タイマセット部３３が異常検出タイマ３１に基準時間をセットする（Ｓ４００）。時間計測フラグＦ３_ＡＡがＯＮとなるのは、ＡＡアプリのＲＯＭチェックが行われたが異常がなかった場合である。基準時間は、ＡＡアプリの実行完了に必要な充分な時間であるが、ＷＤＴ２７のリセット時間よりは短い。異常検出タイマ３１は、基準時間まで時間を計測するとタイマ割込みを発生させ、図５（ｃ）の手順が実行される。
【００５７】
次に、ＡＡアプリの実行が完了すると、異常検出タイマクリア部３４は異常検出タイマ３１をクリアする（Ｓ６００）。このように、ＡＡアプリが正常に動作する限り、異常検出タイマ３１はタイマ割込みしない。
【００５８】
各アプリ４３についてＳ１００〜Ｓ６００の処理が行われ、ＮＮアプリまで終了すると、ＷＤＴクリア部４４がＷＤＴ２７をクリアする（Ｓ１０００）。したがって、ＡＡアプリ〜ＮＮアプリのいずれかに異常が生じた場合、最初にＷＤＴ２７が異常を検出する。ＷＤＴ２７が異常を検出した場合の動作には、マイコンリセット、異常発生の記録、外部（例えば、他のＥＣＵ）への異常通知等があるが、本実施形態ではマイコン１２をリセットするものとする。
【００５９】
以上のように、アプリが正常な場合の正常実行パスではＲＯＭチェックされない。また、異常が検出されたアプリは個別に実行が禁止され、異常が検出されないアプリのみの実行を継続できる。
【００６０】
・初期処理
マイコン１２のリセットにより、図５（ａ）の初期処理が実行される。まず、割込みチェック部３７が割込みチェックを行う（Ｓ１０）。割込みチェックは、リセット前に発生した割込みを割込みレジスタなどで確認する処理である。これにより、タイマ割込みが発生した頻度などが確認できるが、本実施形態では説明を省略する。
【００６１】
次に、実行フラグチェック部３８が実行フラグＦ１をチェックする（Ｓ２０）。実行フラグＦ１のチェックは図５（ｂ）の手順にて説明する。
【００６２】
その後、初期処理部３６は周辺機器の応答確認など、予め定められたイニシャル処理を行う（Ｓ３０）。
【００６３】
・実行フラグチェック
図５（ｂ）に示すように、実行フラグチェック部３８は、初期処理が開始された要因がパワーＯＮか否かを判定する（Ｓ２１）。なお、パワーＯＮはエンジンのみを動力源とする車両のエンジン始動操作（ＩＧ−ＯＮ）、及び、ハイブリッド車（プラグインハイブリッド車を含む）や電気自動車のメインシステムの始動操作、が行われたことをいう。
【００６４】
パワーＯＮされたのか、リセットされたのかは、例えば、正常にシステムがＯＦＦされた場合にＯＮとなる正常フラグを参照することで判定する。すなわち、システムの初期処理開始時に正常フラグがＯＮであれば正常にシステムがＯＦＦされた後にパワーＯＮされたことによる初期処理と判定し、正常フラグがＯＦＦであればシステムのリセットによる初期処理であると判定する。
【００６５】
パワーＯＮであった場合（Ｓ２１のＹｅｓ）、ＷＤＴ２７によりリセットしたわけでないので実行フラグＦ１がＯＮに設定されていることはない。このため、図５（ｂ）の処理は終了される。
【００６６】
パワーＯＮでなかった場合（Ｓ２１のＮｏ）、実行フラグチェック部３８はＯＮになっている実行フラグＦ１があるか否かを判定する（Ｓ２２）。ＯＮになっている実行フラグＦ１がある場合は、実行フラグＦ１がＯＮのアプリを特定しておく。
【００６７】
ＯＮになっている実行フラグＦ１がある場合（Ｓ２２のＹｅｓ）、アプリに異常が生じている可能性があるので、ＲＯＭチェック部３９がＲＯＭチェックする（Ｓ２３）。ＲＯＭチェックの後は、メイン処理が実行される。
【００６８】
・ＲＯＭチェック
図７に示すように、実行フラグＦ１がＯＮになっているアプリの領域は、ＲＯＭチェックが行われる。
【００６９】
まず、ＲＯＭチェック部３９は、変数Ｘ、Ｙ、Ｚ、Ｂ、Ａを用意する（Ｓ２３１）。ＲＯＭチェック部３９は、ＲＯＭＳＵＭテーブル４５を参照し、実行フラグＦ１がＯＮであったアプリの開始番地と終了番地、及び、ＲＯＭＳＵＭ値を読み出す。変数Ｘには開始番地が、変数Ｙには終了番地が、変数ＺにはＲＯＭＳＵＭ値が、変数ＢにはＲＯＭ値の合計値が、変数Ａには開始番地が、それぞれ設定される。
【００７０】
ＲＯＭチェック部３９は、以下の計算を行う（Ｓ２３２）。
Ｂ＝Ｂ＋Ａ番地のＲＯＭ値
すなわち、変数Ｂにはアプリが記憶された領域のあるアドレスのＲＯＭ値（例えば、８bitの１，０）が加算される。１bit単位で計算してもよいし、ワード長単位で計算してもよい。
【００７１】
ＲＯＭチェック部３９は変数Ａ＝変数Ｙになったか否かを判定する（Ｓ２３３）。すなわち、実行フラグＦ１がＯＮであったアプリが記憶された領域の終了番地までＲＯＭ値を加算したか否かが判定される。
【００７２】
変数Ａ＝変数Ｙになっていない場合（Ｓ２３３のＮｏ）、ＲＯＭチェック部３９は変数Ａをインクリメントする（Ｓ２３６）。これにより、変数Ａには開始番地から終了番地までの数値が順番に設定される。
【００７３】
変数Ａ＝変数Ｙになった場合（Ｓ２３３のＹｅｓ）、ＲＯＭチェック部３９は変数Ｂの合計値がＲＯＭＳＵＭテーブル４５から読み出したＲＯＭＳＵＭ値と一致するか否かを判定する（Ｓ２３４）。
【００７４】
変数Ｂの合計値がＲＯＭＳＵＭ値と一致する場合（Ｓ２３４のＹｅｓ）、実行フラグＦ１がＯＮになったアプリが記憶されたフラッシュＲＯＭ２４の領域は書き換えられていないことになる。よって、時間計測フラグセット部４２は時間計測フラグＦ３をＯＮに設定する（Ｓ２３７）。これにより、ＲＯＭチェックで異常が検出されないアプリを実行時間の計測対象にすることができる。
【００７５】
変数Ｂの合計値がＲＯＭＳＵＭ値と一致しない場合（Ｓ２３４のＮｏ）、実行フラグＦ１がＯＮになったアプリが記憶されたフラッシュＲＯＭ２４の領域は書き換えられているので、異常フラグセット部４１は異常フラグＦ２をＯＮに設定する（Ｓ２３５）。これにより、ＲＯＭチェックで異常が検出されたアプリは実行対象外とすることができる。
【００７６】
このような処理により、以下の効果が得られる。再度、同じアプリで異常が生じＷＤＴ２７のリセットが発生すると、再度、ＲＯＭチェックが必要になってしまう。ＲＯＭチェックには時間がかかるので、フラッシュＲＯＭ２４に異常がない場合でもメイン処理の開始まで時間がかかってしまう。本実施形態では、異常フラグＦ２をＯＮにすることで、再度のＲＯＭチェックを防止することができる。また、時間計測フラグＦ３をＯＮに設定した場合においても、アプリのタイムアウトが検出されれば、次述の処理により該アプリを実行対象外とすることができ、再度のＲＯＭチェックを回避できる。
【００７７】
・異常検出タイマ割込みが発生した場合
メイン処理にて説明したように、時間計測フラグＦ３がＯＮの場合、異常検出タイマ３１がアプリの実行時間の計測を行う。仮に、ＲＯＭチェックで異常が検出されないアプリでも、実行時に異常が生じた場合、異常検出タイマ３１が計測する実行時間が基準時間をオーバーすることで、アプリの異常を個別に検出することができる。
【００７８】
図５（ｃ）に示すように、タイマ割込みにより異常フラグセット部４１が呼び出される。異常フラグセット部４１は、実行フラグＦ１を参照し、現在実行されているアプリの異常フラグＦ２をＯＮに設定する（Ｓ３００）。
【００７９】
図５（ｃ）の手順が終了すると、ＣＰＵ２３はタイマ割込み前のアドレスから実行を再開するので、処理はメイン処理のアプリの実行部（例えば、Ｓ５００）に戻る。この場合、以下の２つの状況が生じ得る。
（i)タイマ割込みが生じているためＷＤＴ２７もオーバーフローして、ＷＤＴ２７がマイコン１２をリセットする
（ii)ＷＤＴ２７がマイコン１２をリセットする前に次のアプリが実行される
（i)の場合、図５（ｂ）の実行フラグチェック処理により、図５（ｃ）で異常フラグＦ２がＯＮに設定されたアプリがもう一度だけＲＯＭチェックされる。しかし、異常フラグＦ２がＯＮなので、ステップＳ１００の判定により、メイン処理において異常検出タイマ３１に割込みを生じさせたアプリが実行されることはない。
【００８０】
（ii)の場合、再度のＲＯＭチェックもなく、次のメイン処理において、異常フラグＦ２がＯＮなので、ステップＳ１００の判定により、異常検出タイマ３１に割込みを生じさせたアプリが実行されることもない。
【００８１】
以上説明したように、本実施形態の電子制御装置１００は、ＷＤＴ２７がマイコン１２をリセットした場合にだけ、リセットの要因になったアプリの領域のみをＲＯＭチェックすることができる。よって、起動時間が長くなること及びＣＰＵ負荷が増大することを抑制できる。また、ステップＳ１００の判定に示すように、ＲＯＭチェックにより異常が検出されたアプリを個別に実行禁止できる。また、ステップＳ３００の判定に示すように、ＲＯＭチェックにより異常が検出されない場合、アプリの実行時間を個別に監視し、実行時間が基準時間よりオーバーすると、ＲＯＭチェックされたアプリの実行を禁止することができる。
【符号の説明】
【００８２】
１２    マイクロコンピュータ
２４    フラッシュＲＯＭ
２７    ＷＤＴ
３１    異常検出タイマ
３２    実行フラグセット部
３３    異常検出タイマセット部
３４    異常検出タイマクリア部
３５    実行制御部
３６    初期処理部
３９    ＲＯＭチェック部
Ｆ１    実行フラグ
Ｆ２    異常フラグ
Ｆ３    時間計測フラグ
【図１】
2013152563.tif 000003
【図２】
2013152563.tif 000004
【図３】
2013152563.tif 000005
【図４】
2013152563.tif 000006
【図５】
2013152563.tif 000007
【図６】
2013152563.tif 000008
【図７】
2013152563.tif 000009