JP2014115950A - 車載電子制御装置 - Google Patents

Abstract

【課題】メモリチェックによりプログラム異常を判定したらＣＰＵ（マイコン）自らリセットするよう構成された車載電子制御装置において、プログラム異常が発生しても、電力の無駄な消費を抑えつつ適切な処理を行うことができるようにする。
【解決手段】ＣＰＵは、メモリチェックを定期的に行い、メモリの記憶内容が異常と判断した場合は、その異常と判断した回数（エラー回数）をエラー回数記憶レジスタ３２に書き込んで、自身をリセットする。ＣＰＵのリセット直後、最初にメモリチェックが行われる前に、比較器３４が、エラー回数記憶レジスタ３２に記憶されているエラー回数がエラー判定閾値以上か否かを判定する。エラー回数がエラー判定閾値以上だった場合、起動先判定器３６が、メモリ内の各プログラムのうち特定のエラー対応処理プログラムをＣＰＵに実行させる。
【選択図】図３

Description

本発明は、車載電子制御装置に関する。

車両に搭載される車載電子制御装置（以下「ＥＣＵ」という）は、各種プログラムが記憶されたメモリやＣＰＵなどからなるマイコンを備え、ＣＰＵが各種プログラムを実行することで車両の各部を制御する。メモリとしては、一般に、プログラムの書き換え（以下「リプログ」という）ができるよう、フラッシュメモリやＥＥＰＲＯＭなどの不揮発性メモリが用いられる。メモリのリプログは、各種プログラムの１つとして記憶されているリプログ用のプログラム（以下「リプログソフト」という）をＣＰＵが実行することにより行われることが一般的である（例えば、特許文献１参照。）。

メモリのリプログが行われる際に、例えばＥＣＵの電源遮断やリプログ処理の異常などの様々な要因によって、そのリプログが失敗するおそれがある。そのようなリプログの失敗を想定して、特許文献１には、次のような技術が記載されている。即ち、リプログソフトを、リプログ中はリプログ中である旨の識別ＩＤを設定し、リプログが正常に完了したらその旨の識別ＩＤを設定するよう構成する。そして、ＣＰＵは、起動時にまず上記識別ＩＤをみて、リプログが正常に完了した旨の識別ＩＤが設定されていれば通常の制御用プログラム（以下「ＥＣＵソフト」という）の実行に移り、リプログ中である旨の識別ＩＤが設定されたままならば再びリプログソフトを起動して再度のリプログ作業を待つ。

上記技術は、より具体的には、次のような構成で実現できる。即ち、メモリ内に、リプログソフトの他に識別ＩＤの記憶領域を設けると共に起動判定処理プログラムを格納し、リセットベクタにはその起動判定処理プログラムのアドレスを設定しておく。ＣＰＵは、リセット後まずリセットベクタに設定されているアドレスを取得してそのアドレスのプログラム（即ち起動判定処理プログラム）を実行する。起動判定処理は、識別ＩＤがリプログ中を示すものであるかそれともリプログ完了を示すものであるかを判断して、リプログ完了を示すものならば通常のＥＣＵソフトを起動させるが、リプログ中を示すものならばリプログソフトを起動させるという処理である。

このような技術により、仮にリプログに失敗してメモリのプログラムが異常な状態になったとしても、その後リセットされた際に起動判定処理によりリプログの成否が判定され、リプログが正常に完了していない場合は再びリプログ待ちに遷移させることができる。

ところで、メモリのプログラム異常は、上述したリプログの失敗により発生するケース以外にも、例えばノイズによるデータ化けやハードウェア故障などの様々な要因で発生し得る。つまり、リプログは正常に完了したとしても、その後のＥＣＵの使用状態や環境（特に電磁環境）などによって、メモリ内のプログラムが異常状態になる可能性がある。

そこで、一般的なＥＣＵのマイコンにおいては、起動直後（リプログの正常完了を確認後）、及びＥＣＵソフト実行中に定期的に、ソフトウェアによるメモリチェック（例えばＲＯＭサムチェック）を行い、異常と判断したら自身にリセットをかけるように構成されている。つまり、リプログの失敗への対応に加え、通常使用中に発生するプログラム異常にも適切に対応できるよう構成されている。

特許第４５７７０７５号公報

しかし、上記のように定期的にメモリチェックを行うよう構成されたマイコンでは、一旦メモリのプログラムが異常になると、メモリチェックにより異常と判断されてリセットされ、リセット直後のメモリチェックでまた異常と判断されてまたリセットされるという、リセットの永続的繰り返しが発生する。

このようにプログラム異常によりリセットが繰り返されると、その分、電力も無駄に消費されてしまうことになる。特に、近年のＥＣＵは、車両のエンジンが停止している間もマイコンは動作を継続（ただし一般的には間欠動作）して、車載バッテリの電力を消費し続けている。そのため、エンジン停止時にプログラム異常が発生すると、ＥＣＵソフトが正常に実行されないのはもちろん、それに加えて、リセットの繰り返しによってバッテリの電力は低下の一途を辿り、バッテリ上がりが発生するおそれがある。

本発明は上記課題に鑑みなされたものであり、メモリチェックによりプログラム異常を判定したらＣＰＵ（マイコン）自らリセットするよう構成された車載電子制御装置において、プログラム異常が発生しても、電力の無駄な消費を抑えつつ適切な処理を行うことができるようにすることを目的とする。

上記課題を解決するためになされた本発明の車載電子制御装置は、メモリと、ＣＰＵと、異常回数記憶手段と、異常回数更新手段と、異常判定手段と、異常対応手段とを備える。

メモリは、車両を制御するための制御プログラムを含む複数のプログラムが記憶された不揮発性のメモリである。ＣＰＵは、メモリに記憶された複数のプログラムを実行するものであって、メモリの記憶内容が正常であるか否かのメモリチェックを定期的に行い、メモリチェックによりメモリの記憶内容が異常と判断した場合は自身をリセットするよう構成されている。異常回数記憶手段は、メモリチェックによってメモリの記憶内容が異常と判断された回数である異常回数が記憶される。異常回数更新手段は、メモリチェックによりメモリの記憶内容が異常と判断される毎に、ＣＰＵのリセット前に、異常回数記憶手段に記憶されている異常回数を更新する。異常判定手段は、ＣＰＵのリセット後、最初のメモリチェックが行われる前に、異常回数記憶手段に記憶されている異常回数が所定の異常判定閾値以上か否かを判定する。異常対応手段は、異常判定手段により異常回数が異常判定閾値以上と判定された場合に、複数のプログラムのうち特定のエラー対応処理プログラムをＣＰＵに実行させる。そしてＣＰＵは、エラー対応処理プログラムの実行中は、メモリチェック又はメモリチェックに基づくリセットは行わない。

このように構成された本発明の車載電子制御装置によれば、メモリチェックでプログラム異常と判断される毎に、ＣＰＵのリセット前に異常回数を記憶（更新）し、リセット後にその異常回数が異常判定閾値以上だった場合は、エラー対応処理プログラムが実行される。エラー対応処理プログラムが実行される際は、メモリチェックによるリセットは行われない。そのため、メモリの記憶内容の異常が発生しても、電力の無駄な消費を抑えつつ適切な処理を行うことができる。

本発明の車載電子制御装置において、異常回数記憶手段、異常判定手段及び異常対応手段は、メモリ及びＣＰＵとは別のハードウェアで構成することができる。これら各手段をメモリ及びＣＰＵとは別のハードウェアで構成することで、メモリチェックの異常回数の更新、及びその異常回数に基づくエラー対応処理プログラムの実行が、メモリの状態に依存せず高い信頼度で迅速に実現される。

なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本発明の技術的範囲を限定するものではない。

実施形態の車両制御システムの概略構成を表すブロック図である。 第１実施形態のフラッシュメモリのプログラム等配置を表す説明図である。 第１実施形態のエラー判定モジュールの概略構成を表すブロック図である。 第１実施形態のＣＰＵの動作を表すフローチャートである。 第２実施形態のフラッシュメモリのプログラム等配置を表す説明図である。 第２実施形態のエラー判定モジュールの概略構成を表すブロック図である。 第２実施形態のＣＰＵの動作を表すフローチャートである。

以下に、本発明の好適な実施形態を図面に基づいて説明する。なお、本発明は、下記の実施形態によって何ら限定して解釈されない。下記の実施形態の構成の一部を、課題を解決できる限りにおいて省略した態様も本発明の実施形態であり、下記の複数の実施形態を適宜組み合わせて構成される態様も本発明の実施形態である。

［第１実施形態］
（１）車両制御システム全体の概略構成
図１に示す本実施形態の車両制御システム１０は、車両に搭載され、車両の各部を制御するためのシステムであり、複数のＥＣＵ１１，１２，１３・・・が車載ネットワーク（例えばＣＡＮ）２０を介して相互にデータ通信できるよう構成されている。各ＥＣＵ１１，１２，１３としては、例えばエンジンＥＣＵ、ボデーＥＣＵ、ナビゲーションＥＣＵなどの各種のＥＣＵが挙げられる。

車載ネットワーク２０には、プログラム書換ツール１５を接続するためのコネクタ１４が接続されている。このコネクタ１４にプログラム書換ツール１５を接続することで、後述するようにプログラム書換ツール１５によるリプログを行うことができる。

各ＥＣＵ１１，１２，１３・・・はいずれも、マイコンを備え、マイコンが各種制御処理を実行することで車両の各部の制御が実現される。これらのうち特に、少なくとも１つのＥＣＵ１１は、エラー判定モジュール２６（詳細は後述）を備えた特徴的構成となっている。そこで、以下の説明では、このＥＣＵ１１についてその構成や機能等を詳しく説明する。

ＥＣＵ１１は、ＣＰＵ２１、ＲＡＭ２２、フラッシュメモリ２３、通信インタフェース（通信Ｉ／Ｆ）２４、タイマ２５及びエラー判定モジュール２６などを備えている。なお、これらＣＰＵ２１、ＲＡＭ２２、フラッシュメモリ２３、通信Ｉ／Ｆ２４、タイマ２５及びエラー判定モジュール２６は、本実施形態では１チップマイコンとして１つの半導体集積回路内に集積された構成となっている。ただし、１チップマイコンとしての構成に限定されるものではない。

ＣＰＵ２１は、フラッシュメモリ２３に記憶されている各種プログラムを実行することにより車両の各部の制御を実現する。ＣＰＵ２１は、図示しない各種レジスタやプログラムカウンタなどを備えた一般的な構成である。ただし、本実施形態のＣＰＵ２１は、リセット直後の起動開始時に、後述するようにエラー判定モジュール２６にエラー判定処理を実行させる。そして、エラー判定モジュール２６から指定されたフラッシュメモリ２３のアドレスにジャンプすることで、フラッシュメモリ２３の各種プログラムに基づく処理を開始する。

フラッシュメモリ２３は、記憶内容を電気的に書き換え可能な不揮発性のメモリである。フラッシュメモリ２３には、図２に示すように各種プログラム等が記憶されている。具体的には、フラッシュメモリ２３には、リセットベクタ、起動判定処理プログラム、リプログソフト、ＲＯＭサムチェック値、書換ステータス、ＯＳ（スケジューラ）、プログラムＡ、プログラムＢ、・・・プログラムｍ（フェールセーフ用ソフト）などが記憶されている。

リセットベクタは、一般的なマイコンにおいてメモリにセットされる、ＣＰＵが実行開始するプログラムの先頭アドレスである。なお、リセットベクタのメモリアドレスは０ｘ００００である。

起動判定処理プログラムは、前回実行されたリプログが正常に完了したか否かを書換ステータスに基づいて判定し、正常に完了している場合は通常ＥＣＵソフトを起動させ、正常に完了していない場合はリプログソフトを起動させるよう構成されたプログラムである。リセットベクタにはこの起動判定処理プログラムの先頭アドレスがセットされている。

なお、通常ＥＣＵソフトとは、ＯＳや各プログラムＡ、Ｂ・・・など、実質的に車両の制御を担う各プログラム等の総称である。通常ＥＣＵソフトの実行に移ると、まずＯＳが処理を開始し、初期化処理やＲＯＭサムチェックを経た上で、マイコンに入力される各種入力情報等を監視しながら、各プログラムＡ，Ｂ・・・のスケジューリングを行う。

リプログソフトは、フラッシュメモリ２３の各プログラム等をリプログするためのプログラムである。即ち、リプログソフトが実行されると、リプログ対象のプログラムの更新バージョンプログラムを車載ネットワーク２０を介して取得し、フラッシュメモリ２３に書き込むことで、リプログが行われる。更新バージョンプログラムは、例えば、コネクタ１４にプログラム書換ツール１５を接続してプログラム書換ツール１５から送信することができる。リプログソフトのより具体的な機能等については、特許文献１に詳しく記載されている。なお、リプログは、フラッシュメモリ２３全体を対象に一括して行うようにしてもよいし、プログラム単位或いはブロック単位で行うようにしてもよい。

リプログソフトは、リプログを開始すると、書換ステータスを「書換中」にセット（実際には「書換中」を示す二値データをセット）する。そして、リプログが正常に完了したら、書換ステータスを「書換完」にセットする。リプログ開始後、リプログが正常に完了しない限り、書換ステータスは「書換中」のままとなる。

ＲＯＭサムチェック値は、チェックサムによるメモリチェックを行う際のチェック用の符号（チェックコード）である。本実施形態のＲＯＭサムチェック値は、フラッシュメモリ２３の記憶内容全体を対象として設定される値である。ＲＯＭサムチェック値は、リプログが行われる度に、リプログ後の記憶内容に対応した値に更新される。

プログラムｍ（本発明のエラー対応処理プログラムの一例に相当）は、リセット直後のエラー判定モジュール２６によるエラー判定処理によってエラーが判定された場合に実行されるフェールセーフ用ソフトである。エラー判定モジュール２６によりエラーが判定されてフェールセーフ用ソフトが実行されると、通常ＥＣＵソフトは実行されず、フェールセーフ用ソフトに基づく各種のフェールセーフ処理が行われる。なお、フェールセーフ用ソフトのメモリアドレスは、０ｘＹＹＹＹである。

（２）エラー判定モジュールの概略構成
次に、ＣＰＵ２１のリセット直後にエラー判定処理を行うエラー判定モジュール２６の構成について、図３を用いて説明する。エラー判定モジュール２６は、ＣＰＵ２１やフラッシュメモリ２３とは別に独立して設けられたハードウェアにより構成されている。

ＣＰＵ２１がリセットすると、リセット直後にまずプログラムカウンタにエラー判定モジュール２６のアドレス（０ｘＸＸＸＸ）がセットされる。これに基づき、ＣＰＵ２１は、まずエラー判定モジュール２６を動作させる。つまり、従来のＣＰＵは、リセット後はまずプログラムカウンタにリセットベクタのメモリアドレスがセットされてリセットベクタにジャンプする構成が一般的であるが、本実施形態のＣＰＵ２１は、リセット後にまずエラー判定モジュール２６のアドレスがプログラムカウンタにセットされてエラー判定モジュール２６に処理を移す。

エラー判定モジュール２６は、エラー判定起動レジスタ３１と、エラー回数記憶レジスタ３２と、エラー判定閾値レジスタ３３と、比較器３４と、エラー判定時起動先レジスタ３５と、起動先判定器３６とを備える。

エラー判定起動レジスタ３１は、ＣＰＵ２１のリセット直後にＣＰＵ２１により所定のエラー判定起動フラグがセットされるレジスタである。エラー判定起動レジスタ３１は、ＣＰＵ２１によりエラー判定起動フラグがセットされると、比較器３４を起動させる。例えば、エラー判定起動フラグのクリア中は「０」を出力して比較器３４を停止させておき、エラー判定起動フラグがセットされたら「１」を出力して比較器３４を起動させる。

エラー回数記憶レジスタ３２は、ＣＰＵ２１が通常ＥＣＵソフトを起動した時に実行、及び通常ＥＣＵソフトの実行中に定期的に実行するＲＯＭサムチェックにおいて異常と判断される毎に、ＣＰＵ２１によりその異常と判断された回数であるエラー回数（本発明の異常回数の一例に相当）が累積記憶（更新）されるレジスタである。このエラー回数記憶レジスタ３２のエラー回数の初期値は０であり、ＲＯＭサムチェックにより異常と判断される毎にＣＰＵ２１によりエラー回数が１つずつインクリメントされていく。

エラー判定閾値レジスタ３３は、エラー判定閾値（本発明の異常判定閾値の一例に相当）が記憶されるレジスタである。エラー判定閾値は、フラッシュメモリ２３にエラーが発生しているか否かをエラー回数記憶レジスタ３２に記憶されているエラー回数に基づいて判定するための判定基準値である。エラー判定閾値は適宜決めることができるが、２以上の値とすることが望ましい。本実施形態では、エラー判定閾値は例えば１０に設定されている。

比較器３４は、エラー回数記憶レジスタ３２に記憶されているエラー回数とエラー判定閾値レジスタ３３に記憶されているエラー判定閾値とを比較し、その比較結果を示すエラー判定データを起動先判定器３６へ出力する。具体的には、エラー回数がエラー判定閾値未満の場合は、エラー判定データとしてエラー未発生を示す「０」を出力し、エラー回数がエラー判定閾値以上の場合は、エラー判定データとしてエラー発生を示す「１」を出力する。

起動先判定器３６は、比較器３４からのエラー判定データに基づき、フラッシュメモリ２３におけるＣＰＵ２１の起動先アドレスを設定し、ＣＰＵ２１へ出力する。具体的には、エラー判定データが「０」（エラー未発生）の場合は、リセットベクタアドレス（０ｘ００００）を起動先に設定してその起動先アドレスをＣＰＵ２１へ出力する。詳しくは、ＣＰＵ２１内のプログラムカウンタにその起動先アドレス（０ｘ００００）をセットする。エラー判定データが「１」（エラー発生）の場合は、エラー判定時起動先レジスタ３５に予め記憶されているエラー判定時起動先アドレス（本例では、フェールセーフ用ソフトの先頭アドレスである０ｘＹＹＹＹ）を起動先に設定してその起動先アドレスをＣＰＵ２１へ出力する。詳しくは、ＣＰＵ２１内のプログラムカウンタにその起動先アドレス（０ｘＹＹＹＹ）をセットする。

このようにして起動先判定器３６により起動先アドレスが出力され、ＣＰＵ２１のプログラムカウンタにセットされると、ＣＰＵ２１は、そのプログラムカウンタにセットされたアドレス（リセットベクタ又はフェールセーフ用ソフト）にジャンプして処理を開始することとなる。なお、エラー回数記憶レジスタ３２、エラー判定閾値レジスタ３３及びエラー判定時起動先レジスタ３５は、ＣＰＵ２１内の図示しないレジスタと異なり、マイコンがリセットされても記憶内容は維持される。

（３）ＣＰＵの動作
次に、ＣＰＵ２１の動作の基本的流れを図４を用いて説明する。ＣＰＵ２１は、リセット後、既述のようにエラー判定モジュール２６を動作させて、エラー判定結果を待つ。即ち、比較器３４によりエラー回数記憶レジスタ３２のエラー回数がエラー判定閾値レジスタ３３のエラー判定閾値以上か否か判断する（Ｓ１１０）。

エラー回数がエラー判定閾値未満の場合は、起動先判定器３６が、リセットベクタのアドレス（０ｘ００００）をＣＰＵ２１のプログラムカウンタにセットする（Ｓ１２０）。エラー回数がエラー判定閾値以上の場合は、起動先判定器３６が、エラー判定時起動先レジスタ３５に記憶されているエラー判定時起動先アドレス（本例では０ｘＹＹＹＹ）をＣＰＵ２１のプログラムカウンタにセットする（Ｓ１３０）。

Ｓ１１０〜Ｓ１３０は、ＣＰＵ２１が直接実行する処理ではなく、ＣＰＵ２１からの指令によって動作するエラー判定モジュール２６の処理であり、広義には、ＣＰＵ２１が間接的に実行する処理であると捉えることもできる。そのため、図４では、エラー判定モジュール２６の処理もＣＰＵ２１の処理に含めて図示している。

Ｓ１２０でリセットベクタのアドレスがプログラムカウンタにセットされた場合は、ＣＰＵ２１は、Ｓ１４０でフラッシュメモリ２３のリセットベクタにジャンプする。Ｓ１３０でエラー判定時起動先アドレスがプログラムカウンタにセットされた場合は、ＣＰＵ２１は、Ｓ１５０でエラー判定時起動先アドレス（即ちフラッシュメモリ２３のアドレス０ｘＹＹＹＹのフェールセーフ用ソフト）にジャンプする。

Ｓ１１０〜Ｓ１５０の処理は、ＣＰＵ２１がフラッシュメモリ２３のプログラムに基づいて各種処理を行う前に、ＣＰＵ２１及びエラー判定モジュール２６によるハードウェア処理として実現される処理である。つまり、ＣＰＵ２１は、プログラムに基づくソフトウェア処理を行うのに先立って、ハードウェア処理によりエラー判定やジャンプ先アドレスの設定等を行う。そして、そのハードウェア処理により設定されたジャンプ先アドレスにジャンプした後は、Ｓ１６０以降又はＳ２８０のソフトウェア処理に移行する。

Ｓ１６０では、リセットベクタに設定されているアドレスのプログラム、即ち起動判定処理を実行する。Ｓ１７０では、起動判定処理において書換ステータスが「書換完」であると判定されたか否か判断し、「書換完」と判定されなかった場合（即ち「書換中」のままの場合）はＳ２６０に進む。Ｓ２６０では、リプログソフトを起動し、プログラム書換ツール１５の接続を待ち、接続されたら更新バージョンプログラムによる既存プログラムの書き換えを行う。

Ｓ１７０で書換ステータスが「書換完」と判定された場合は、Ｓ１８０でＯＳによる初期化処理を開始することにより通常ＥＣＵソフトを起動し、Ｓ１９０で、ＯＳの機能としてのＲＯＭサムチェック（本発明のメモリチェックの一例に相当）を実行する。Ｓ２００では、Ｓ１９０のＲＯＭサムチェックの結果がＯＫ（正常）か否か判断し、ＯＫならばＳ２１０で通常ＥＣＵソフトをそのまま実行する。

通常ＥＣＵソフトの実行中も、Ｓ２２０〜Ｓ２４０に示すように定期的にＲＯＭサムチェックを行う。即ち、ＲＯＭサムチェックの実行タイミングが到来したら、Ｓ２２０でＲＯＭサムチェックを実行し、Ｓ２３０で、Ｓ２２０のＲＯＭサムチェックの結果がＯＫか否か判断する。Ｓ２３０でＯＫと判断した場合は、Ｓ２４０で引き続き通常ＥＣＵソフトを実行（継続）し、再びＲＯＭサムチェックの実行タイミングが到来したらＳ２２０に戻ってＲＯＭサムチェックを実行する。

Ｓ２００又はＳ２３０で、ＲＯＭサムチェックの結果が異常と判断した場合は、Ｓ２５０で、エラー判定モジュール２６内のエラー回数記憶レジスタ３２にエラー回数を書き込む。即ち、現在記憶されているエラー回数を更新（１つインクリメント）する。エラー回数の書き込み後は、ＣＰＵ２１自ら、ＣＰＵ２１をリセット（即ちマイコンをリセット）する。

起動先としてエラー判定時起動先アドレスが設定された場合は（Ｓ１５０）、Ｓ２８０で、フェールセーフ処理を行う。即ち、エラー判定時起動先アドレスである０ｘＹＹＹＹに記憶されているフェールセーフ用ソフトを実行する。

（４）第１実施形態の効果等
以上説明した本実施形態のＥＣＵ１１によれば、ＲＯＭサムチェックで異常と判断される毎に、ＣＰＵ２１のリセット前にエラー回数を更新し（Ｓ２５０）、リセット後にそのエラー回数がエラー判定閾値以上だった場合は、フェールセーフ処理ソフトが実行される（Ｓ２８０）。フェールセーフ処理ソフトは、リセットベクタへのジャンプに始まる通常の処理の流れとは独立して実行され、フェールセーフ処理ソフトの実行中はＲＯＭサムチェックは行われない。つまり、ＲＯＭサムチェックの異常によるマイコンリセットが繰り返し永続的に行われることはない。そのため、フラッシュメモリ２３の記憶内容に異常が発生しても、電力の無駄な消費を抑えつつ適切な処理（本実施形態ではフェールセーフ処理）を行うことができる。

なお、エラー判定時にフェールセーフ処理ソフトを実行するのはあくまでも一例であり、エラー判定時に具体的にどのような処理を実行するかについては適宜決めることができる。例えば、リプログソフトを起動してリプログ待ちに遷移してもよい。また例えば、所定のフェールセーフ処理の実行に加えてユーザ（車両の運転者等）に対して何らかの方法で故障発生を通知するようにしてもよい。

また、本実施形態では、ＲＯＭサムチェックで異常と判断されても、１回の異常判断だけですぐにフェールセーフ処理に移行せず、異常と判断された回数（エラー回数）がエラー判定閾値以上となった場合にフェールセーフ処理に移行するようにしている。そのため、エラー判定の精度を高めることができる。しかも、エラー回数の記憶・更新は、ＲＡＭ２２でもフラッシュメモリ２３でもなく、これらとは別に設けたエラー回数記憶レジスタ３２を用いて行うようにしている。そのため、ＲＡＭ２２やフラッシュメモリ２３の状態にかかわらずエラー回数を確実に記憶させておくことができ、これによりエラー判定の精度をより一層高めることができる。

また、本実施形態では、ＣＰＵ２１のリセット直後のエラー判定を、ソフトウェア処理ではなく、エラー判定モジュール２６によるハードウェア処理により実現している。そのため、エラー判定を迅速且つ高い信頼度で行うことができる。また、仮にエラー判定をソフトウェア処理で実現しようとすると、その分、フラッシュメモリ２３の記憶領域が必要となってコスト高を招くおそれがあるが、本実施形態のようにハードウェア処理で実現することで、そういった課題を抑制することができる。

［第２実施形態］
第２実施形態のＥＣＵについて、図１に示した第１実施形態のＥＣＵ１１と異なる部分に絞って説明する。本実施形態のＥＣＵ（図示略）が第１実施形態のＥＣＵ１１と異なる主な部分は、フラッシュメモリの記憶内容とエラー判定モジュールの構成である。

本実施形態のフラッシュメモリにおいては、図５に示すように、記憶領域が複数のブロックに分割され、ブロックごとにＲＯＭサムチェック用のチェックコード（即ちＲＯＭサムチェック値）が設定されている。なお、フラッシュメモリ２３を具体的にどのようにブロック分けするかについては適宜決めることができる。

本実施形態のエラー判定モジュール４０は、図６に示す通りであり、図３に示した第１実施形態のエラー判定モジュール２６と比較して明らかなように、エラー回数記憶レジスタ３２とエラー判定閾値レジスタ３３の構成が異なっている。また、本実施形態では比較器３４と起動先判定器３６との間に新たにエラー発生ブロックレジスタ４１が設けられている 。

本実施形態のエラー回数記憶レジスタ３２は、フラッシュメモリのブロック毎に個別に設けられている。即ち、ブロック０対応のエラー回数記憶レジスタ３２Ａ、ブロック１対応のエラー回数記憶レジスタ３２Ｂ、ブロック２対応のエラー回数記憶レジスタ３２Ｃ、・・・というように、ブロック毎の複数のエラー回数記憶レジスタが設けられている。

これと全く同じように、エラー判定閾値レジスタ３３についても、フラッシュメモリのブロック毎に個別に設けられている。即ち、ブロック０対応のエラー判定閾値レジスタ３３Ａ、ブロック１対応のエラー判定閾値レジスタ３３Ｂ、ブロック２対応のエラー判定閾値レジスタ３３Ｃ、・・・というように、ブロック毎の複数のエラー判定閾値レジスタが設けられている。

比較器３４による、エラー回数とエラー判定閾値との比較も、ブロック毎に個別に行われる。例えば、ブロック０についてはブロック０対応のエラー回数記憶レジスタ３２Ａに記憶されているエラー回数とブロック０対応のエラー判定閾値レジスタ３３Ａに記憶されているエラー判定閾値とを比較する。

比較器３４は、各ブロック０〜ｎについてそれぞれ個別に上記比較を行い、エラーが発生しているブロック（即ちエラー回数がエラー判定閾値以上のブロック）があった場合は、エラー発生ブロックレジスタ４１における当該エラー発生ブロックのフラグをセットする。

エラー発生ブロックレジスタ４１は、エラーが発生しているか否かを示すフラグがブロック毎に設定されるものである。あるブロックについて比較器３４によりエラーが発生していると判断されると、エラー発生ブロックレジスタ４１における該当ブロックのフラグが比較器３４によりセットされる。つまり、エラー発生ブロックレジスタ４１を参照すればどのブロックが正常でどのブロックがエラー発生しているかを知ることができる。

エラー発生ブロックレジスタ４１は、何れのブロックも正常である間は、エラー判定データとしてエラー未発生を示す「０」を起動先判定器３６へ出力するが、何れか１つのブロックのフラグがセットされると（つまり各ブロックのうち何れか１つでもエラーと判定されると）、エラー判定データとしてエラー発生を示す「１」を起動先判定器３６へ出力する。

このように構成された本実施形態のＥＣＵにおけるＣＰＵの動作について、図７を用いて概略説明する。本実施形態のＣＰＵは、リセット後、エラー判定モジュール４０を動作させて、エラー判定結果を待つ。即ち、比較器３４によりブロック毎にエラー回数とエラー判定閾値の比較が行われる（Ｓ３１０）。その比較の結果、エラー回数がエラー判定閾値以上のブロックがない場合はＳ３２０に進み、何れか１つでもエラー回数がエラー判定閾値以上のブロックがあれば、Ｓ３２５に進む。

Ｓ３２５では、エラー発生ブロックレジスタ４１に対してエラー発生ブロックを示すフラグをセットする。Ｓ３３０，Ｓ３５０の処理はそれぞれ図４のＳ１３０，Ｓ１５０の処理と同じである。Ｓ４８０のフェールセーフ処理は、図４のＳ２８０のフェールセーフ処理と若干異なる。即ち、本実施形態のフェールセーフ処理（Ｓ４８０）では、適宜、１又は複数の他のブロックのプログラムにアクセス（参照）して実行する。ただし、エラー発生ブロックレジスタ４１の設定値を読み出して、エラー発生ブロックについてはそのブロック内のプログラムにはアクセスしない。

Ｓ３２０〜Ｓ３８０，Ｓ４００，Ｓ４１０，Ｓ４３０，Ｓ４４０，Ｓ４６０の各処理はそれぞれ図４のＳ１２０〜Ｓ１８０，Ｓ２００，Ｓ２１０，Ｓ２３０，Ｓ２４０，Ｓ２６０の各処理と同じである。

Ｓ３９０及びＳ４２０のＲＯＭサムチェックは、ブロック毎に個別に実行する点で、第１実施形態と異なる。Ｓ４５０のエラー回数記憶レジスタ３２へのエラー回数書き込み（インクリメント）についても、ブロック毎に、ＲＯＭサムチェックで異常と判断されたブロックに対応したエラー回数をインクリメントする点で、第１実施形態と異なる。

上記のように構成された本実施形態のＥＣＵによれば、ブロック毎にエラー判定が行われ、何れか１つでもエラー判定されたブロックがあればフェールセーフ処理に移行するため、エラー判定の精度をより高めることができ、エラー発生に対して適切な対応（フェールセーフ処理）をより迅速にとることができる。また、エラーが発生しているブロックとエラーが発生していないブロックを区別することができるため、フェールセーフ処理においてアクセスできないブロックを必要最小限に抑えることができ、フェールセーフ処理の機能低下を抑えることができる。

［変形例］
以上、本発明の実施の形態について説明したが、本発明の実施の形態は、上記実施形態に何ら限定されるものではなく、本発明の技術的範囲に属する限り種々の形態を採り得ることはいうまでもない。

例えば、上記実施形態では、リセット直後のエラー判定を、エラー判定モジュール（図３，図６参照）によるハードウェア処理で実現するようにしたが、エラー判定モジュールの機能をソフトウェア処理で実現するようにしてもよい。ただし、処理速度やコストを考慮すると、上記実施形態のようにハードウェア処理で実現する構成が好ましい。

また、上記実施形態では、フラッシュメモリ２３の記憶内容のチェック方法として、ＲＯＭサムチェックを用いたが、これはあくまでも一例であり、他の各種の方法（例えばＣＲＣ）を用いてメモリチェックを行うようにしてもよい。

また、上記第２実施形態では、比較器３４において、全てのブロックについてそれぞれエラー回数とエラー判定閾値との比較を行うようにしたが、何れか１つ又は所定数（複数）（本発明のエラー対応基準ブロック数の一例に相当）のブロックについてエラー判定（エラー回数≧エラー判定閾値）されたら、その時点で比較をやめて、それらエラー判定ブロックについてエラー発生ブロックレジスタ４１のフラグをセットするようにしてもよい。

Ｓ３９０やＳ４２０のＲＯＭサムチェックについても、全てのブロックについてＲＯＭサムチェックを行ってからＳ４５０に進むのではなく、ブロックごとに順次ＲＯＭサムチェックを行っていく過程の中で何れか１つ又は所定数（複数）（本発明のリセット基準ブロック数の一例に相当）のブロックについてＲＯＭサムチェックで異常が判断されたら、その時点でＲＯＭサムチェックをやめてＳ４５０に進むようにしてもよい。

１０…車両制御システム、１１，１２，１３…ＥＣＵ、１４…コネクタ、１５…プログラム書換ツール、２０…車載ネットワーク、２１…ＣＰＵ、２２…ＲＡＭ、２３…フラッシュメモリ、２４…通信Ｉ／Ｆ、２５…タイマ、２６，４０…エラー判定モジュール、３１…エラー判定起動レジスタ、３２（３２Ａ，３２Ｂ，３２Ｃ）…エラー回数記憶レジスタ、３３（３３Ａ，３３Ｂ，３３Ｃ）…エラー判定閾値レジスタ、３４…比較器、３５…エラー判定時起動先レジスタ、３６…起動先判定器、４１…エラー発生ブロックレジスタ

Claims (5)

1. 車両を制御するための制御プログラムを含む複数のプログラムが記憶された不揮発性のメモリ（２３）と、
   前記複数のプログラムを実行するＣＰＵであって、前記メモリの記憶内容が正常であるか否かのメモリチェックを定期的に行い、前記メモリチェックにより前記メモリの記憶内容が異常と判断した場合は自身をリセットするよう構成されたＣＰＵ（２１）と、
   前記メモリチェックによって前記メモリの記憶内容が異常と判断された回数である異常回数が記憶される異常回数記憶手段（３２）と、
   前記メモリチェックにより前記メモリの記憶内容が異常と判断される毎に、前記ＣＰＵのリセット前に、前記異常回数記憶手段に記憶されている前記異常回数を更新する異常回数更新手段（２１、Ｓ２５０）と、
   前記ＣＰＵのリセット後、最初の前記メモリチェックが行われる前に、前記異常回数記憶手段に記憶されている前記異常回数が所定の異常判定閾値以上か否かを判定する異常判定手段（３４）と、
   前記異常判定手段により前記異常回数が前記異常判定閾値以上と判定された場合に、前記複数のプログラムのうち特定のエラー対応処理プログラムを前記ＣＰＵに実行させる異常対応手段（３６）と、
   を備え、
   前記ＣＰＵは、前記エラー対応処理プログラムの実行中は、前記メモリチェック又は前記メモリチェックに基づく前記リセットは行わない
   ことを特徴とする車載電子制御装置。
2. 請求項１に記載の車載電子制御装置であって、
   前記異常回数記憶手段、前記異常判定手段及び前記異常対応手段は、前記メモリ及び前記ＣＰＵとは別のハードウェアで構成されている
   ことを特徴とする車載電子制御装置。
3. 請求項２に記載の車載電子制御装置であって、
   前記異常対応手段は、前記ＣＰＵが有するプログラムカウンタに前記メモリにおける前記エラー対応処理プログラムのアドレスを格納することによって、前記エラー対応処理プログラムを前記ＣＰＵに実行させる
   ことを特徴とする車載電子制御装置。
4. 請求項１〜請求項３の何れか１項に記載の車載電子制御装置であって、
   前記ＣＰＵは、前記メモリチェックを所定のブロック単位で実行し、１又は複数の所定のリセット基準ブロック数以上の前記ブロックについて記憶内容が正常ではないと判断した場合にリセットするよう構成されており、
   前記異常回数記憶手段（３２Ａ，３２Ｂ，３２Ｃ，・・・）は、前記ブロック毎に前記異常回数が記憶され、
   前記異常回数更新手段（２１、Ｓ４５０）は、前記ブロック毎に前記異常回数を更新し、
   前記異常判定手段は、前記ブロック毎に前記異常回数が前記異常判定閾値以上か否かを判定し、
   前記異常対応手段は、前記異常判定手段により１又は複数の所定のエラー対応基準ブロック数以上の前記ブロックについて前記異常回数が前記異常判定閾値以上と判定された場合に、前記エラー対応処理プログラムをＣＰＵに実行させる
   ことを特徴とする車載電子制御装置。
5. 請求項４に記載の車載電子制御装置であって、
   前記エラー対応処理プログラムは、当該エラー対応処理プログラムが記憶されている前記ブロック以外の他の少なくとも１つの前記ブロックを参照するよう構成されていると共に、その参照先の前記ブロックが前記異常判定手段により前記異常回数が前記異常判定閾値以上と判定されたブロックである場合はそのブロックは参照しないよう構成されている
   ことを特徴とする車載電子制御装置。

Images