JP2020129325A - 車両用電子制御装置 - Google Patents

Abstract

【課題】リプログラム時に、可能な限り書き換え前の記憶データを持ち越すことができ、故障への対処や学習値の消失による制御の遅れを抑制できる車両用電子制御装置を提供する。【解決手段】車両用電子制御装置３０は、外部から書き換え可能に設定され、車両１０の動作中に生じたデータを必要に応じて記憶する不揮発性メモリ３５を備える。この不揮発性メモリに、車両の制御に使用する複数のプログラム間で共通する前記データを予め定められたブロック構成で記憶する。そして、プログラムの書き換えでブロックサイズが変化するときは、書き換え前のプログラムによって記憶されたデータを、書き換え後のプログラムに対応するブロックサイズに変換して再配置する、ことを特徴とする。【選択図】図１

Description

本発明は、車両用電子制御装置に関し、例えばＥＣＭ（Engine Control Module）におけるリプログラミング時の異常情報や学習値の維持に関する。

ＥＣＭなどの車両用電子制御装置では、異常情報や学習値を不揮発性メモリに記憶している。そして、整備や点検のときには、作業者が診断用の外部ツールをＥＣＭに接続して不揮発性メモリから故障などの異常情報を読み出し、外部ツールのモニタに故障の状況を表示して確認するようになっている（例えば特許文献１及び特許文献２参照）。また、エンジンが常に最適な燃焼（空燃比）になるように、学習値を参考に燃焼マップを選択している。

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

ところで、この種の車両用電子制御装置では、プログラムやデータに更新、あるいは修正が必要になると、それらの書き換え、いわゆるリプログラミングが行われる。リプログラミングの前後では、プログラムの情報の形態が同一とは限らないため、リプログラミングする時に、記憶データを初期化（消去）するのが一般的であった。

また、特許文献３に記載されているように、リプログラミングする際に、記憶データの選択的な初期化も行われている。すなわち、不揮発性メモリ内に記憶されているデータの種類が異なる領域毎にバージョンチェックを行い、バージョンが一致する領域の記憶データは持ち越し、バージョンが不一致の領域の記憶データは初期化する。

しかしながら、リプログラミング対象の記憶領域は初期化されるため、更新されたプログラムを実行するときには、再度診断や学習を行わなければならず、故障への対処や学習値による制御の最適化が遅れる可能性があった。

本発明は上記のような事情に鑑みてなされたもので、その目的とするところは、リプログラム時に、可能な限り書き換え前の記憶データを持ち越すことができ、故障への対処や学習値の消失による制御の遅れを抑制できる車両用電子制御装置を提供することにある。

本発明の一態様に係る車両用電子制御装置は、外部から書き換え可能に設定され、車両の動作中に生じたデータを必要に応じて記憶する記憶装置を備えた車両用電子制御装置であって、前記記憶装置に、車両の制御に使用する複数のプログラム間で共通する前記データを予め定められたブロック構成で記憶し、前記プログラムの書き換えでブロックサイズが変化するときは、書き換え前のプログラムによって記憶されたデータを、書き換え後のプログラムに対応するブロックサイズに変換して再配置する、ことを特徴とする。

本発明では、異常情報や学習値などの記憶データが予め定められたブロック構成で保存されており、リプログラミング時に、そのブロック内のデータサイズが変更されるのみの場合には、書き換え前のプログラムによって記憶されたデータを、書き換え後のプログラムに対応するブロックサイズに変換して再配置する。これによって、書き換え前の記憶データを消去することなく持ち越すことが可能となり、更新したプログラムで異常情報や学習値などの記憶データを継続して使用できる。従って、故障への対処や学習値の消失による制御の遅れを抑制できる。

本発明の実施形態に係る車両用電子制御装置の概略構成を示すブロック図である。 図１に示した車両用電子制御装置のリプログラミングを行う場合のシステム概要図である。 図２に示したリプログラミングツールの構成例を示すブロック図である。 ＥＥＰＲＯＭのブロック構成例を示す図である。 ＥＥＰＲＯＭの固定アドレスと各ブロックの構成について説明するための図である。 フラッシュメモリにおけるソフトウェア領域の構成例を示す図である。 ソフトウェアのアップデート時の制約について説明するための図である。 ソフトウェアのアップデート時の他の制約について説明するための図である。 リプログラミングに際して、ＥＥＰＲＯＭに対して実行される処理の概要を示すフローチャートである。 図９に続く処理を示すフローチャートである。 ＥＥＰＲＯＭのブロック構成例を示す図である。 変形例１に係るＥＥＰＲＯＭのブロック構成例を示す図である。 変形例２に係るＥＥＰＲＯＭのブロック構成例を示す図である。 変形例３に係るＥＥＰＲＯＭのブロック構成例を示す図である。 変形例４に係るＥＥＰＲＯＭのブロック構成例を示す図である。 変形例５に係るＥＥＰＲＯＭのブロック構成例を示す図である。 ソフトウェアアップデートにおけるＥＥＰＲＯＭのブロック割り当ての変更例について説明するためのもので、変更前と変更後のメモリ構成を示す図である。 図１７に示した各ブロックの制御情報の設定を纏めて示す図である。

以下、本発明の実施形態について図面を参照して説明する。
図１は、本発明の実施形態に係る車両用電子制御装置の概略構成を示している。車両１０に搭載されたエンジン（内燃機関）２０には、各種のセンサ２１が設けられており、これらセンサ２１で検出された信号がＥＣＭ３０に入力される。センサ２１は、例えば吸入空気量センサ、クランク角センサ、アクセル開度センサ、水温センサ、カム角センサ、空燃比センサ、及び油温センサなどである。また、ＥＣＭ３０には、エンジン２０の運転及び停止のメインスイッチであるイグニッションスイッチ（図示せず）からの信号が入力されて制御される。

ＥＣＭ３０は、これら各種のセンサ２１及びイグニッションスイッチからの信号に基づいて、予め記憶された制御プログラムに従って演算処理を行う。詳しくは、例えば燃料噴射弁、ＶＴＣ（Valve Timing Control）機構及び点火モジュールなどの各種装置の操作量あるいは制御量を算出し、これらの装置や装置を駆動するアクチュエータ２２などに制御信号を出力して制御する。

このＥＣＭ３０は、ＣＰＵ（Central Processing Unit）などのプロセッサ３１と、揮発性メモリの一例としてのＲＡＭ（Random Access Memory）３２と、制御プログラム及び各種データを記憶する不揮発性メモリの一例としてのＲＯＭ（Read Only Memory）３３と、プロセッサ３１によって実行されるソフトウェア（エンジン制御用プログラム及びそのプログラムの実行時に参照されるデータ）を記憶する不揮発性メモリの一例としてのフラッシュメモリ３４と、車両情報（故障や異常の情報）及び学習値などを記憶する不揮発性メモリの他の一例としてのＥＥＰＲＯＭ（Electrically Erasable and Programmable Read Only Memory）３５と、入力と出力のインターフェースを行うための入出力インターフェース（入出力Ｉ／Ｆ）３７と、外部装置と通信を行うための外部通信インターフェース（外部通信Ｉ／Ｆ）３８と、バス３９とを備えている。

プロセッサ３１、ＲＡＭ３２、ＲＯＭ３３、フラッシュメモリ３４、ＥＥＰＲＯＭ３５、入出力Ｉ／Ｆ３７及び外部通信Ｉ／Ｆ３８は、バス３９によって相互に接続され、データの授受を行うようになっている。また、外部通信Ｉ／Ｆ３８は、ネットワークケーブル４０を着脱可能に接続するコネクタ３８ａを有する。このコネクタ３８ａには、外部からプログラムを書き換えるためのリプログラミングツール５０、あるいは故障発生時に整備や点検を行うための外部ツール６０がＣＡＮ（Controller Area Network）、シリアル通信、ＦｌｅｘＲａｙ（登録商標）及びＥｔｈｅｒｎｅｔ（登録商標）などのネットワークケーブル４０を介して接続される。

図２は、車両用電子制御装置のリプログラミングを行う場合のシステム構成を示している。リプログラミングの対象となるＥＣＭ３０は、ネットワークケーブル４０を介して、リプログラミングツール５０に着脱自在に接続される。この状態で、作業者がリプログラミングツール５０を操作して、ＥＣＭ３０のリプログラミング作業を行う。
なお、ＥＣＭ３０とリプログラミングツール５０とは、ネットワークケーブル４０とコネクタ３８ａ，５２ａを使用した有線接続に限らず、無線送受信機を使用した無線通信によって相互に接続されるように構成しても良い。

リプログラミングツール５０は、作業者がＥＣＭ３０のデータの書き換え作業を行う電子機器であって、例えば、パーソナルコンピュータなどから構成される。具体的には、リプログラミングツール５０は、図３に示すように、ＣＰＵなどのプロセッサ５１と、ネットワークに接続するための通信装置５２と、ハードディスク装置やＳＳＤ（Solid State Drive）などのストレージ５３と、作業者へのインターフェースとなる入出力装置５４と、バス５５とを備えている。プロセッサ５１、通信装置５２、ストレージ５３及び入出力装置５４は、バス５５によって相互に接続され、データの授受を行うようになっている。ここで、通信装置５２は、ネットワークケーブル４０を着脱可能に接続するコネクタ５２ａを有する。また、入出力装置５４は、ＬＣＤ（Liquid Crystal Display）などのディスプレイと、キーボードと、マウスなどのポインティングデバイスと、を含む。

なお、ストレージ５３は、例えば、図示しないネットワークに接続されたＮＡＳ（Network Attached Storage）やサーバのストレージなどであってもよい。
このストレージ５３には、ＥＣＭ３０のＥＥＰＲＯＭ３５を書き換えるための更新プログラムや更新データが格納されている。これらの更新プログラムや更新データは、例えばエンジン２０に搭載あるいは設置された各種機器を制御する制御プログラム、その制御プログラムで使用される定数やマップなどの制御パラメータなどを含む。

リプログラミング処理（データ書き換え処理）は、作業者がネットワークケーブル４０を介してＥＣＭ３０とリプログラミングツール５０とを接続した後、リプログラミングツール５０において、所定の操作を行ったときに実行される。ここでは、ＥＣＭ３０は、ネットワークケーブル４０を介してリプログラミングツール５０と接続されたときに、電力が供給されて起動することを前提とするが、別の電源ケーブルの接続により起動する形態であってもよい。

一方、外部ツール６０は、ＥＣＭ３０から出力される異常情報を受信し、異常情報に対応する故障などの状態をモニタに表示するもので、専用の診断ツールであっても良いし、リプログラミングツール５０と同様に、例えばパーソナルコンピュータなどから構成されても良い。また、外部ツール６０とＥＣＭ３０は、ネットワークケーブル４０を使用した有線接続に限らず、無線送受信機を使用した無線通信によって相互に接続されるような構成でも良い。ここでは、外部ツール６０には、周知の診断ツールを用いるものとして詳細な説明は省略する。

本発明の概要は、不揮発性メモリに継続的に保存する記憶データのメモリ配置が、不揮発性メモリを制御するソフトウェアの書き換えによって変化したとしても、書き換え前の記憶データを可能な限り持ち越しつつ、不揮発性メモリ上の記憶データのメモリ配置を更新するものである。
そのために、リプログラミングの対象となる不揮発性メモリ（フラッシュメモリ３４及びＥＥＰＲＯＭ３５）は、下記（１）〜（５）のように構成している。

（１）ＥＥＰＲＯＭ３５には、ソフトウェアの用途毎に種類の異なる複数のブロックを配置する。
（２）上記（１）のブロック長は用途によりサイズを可変とする。
（３）ＥＥＰＲＯＭ３５の固定のアドレスに、ブロック数と各ブロックの格納先アドレス及びブロック長を配置する。
（４）フラッシュメモリ３４におけるソフトウェアを配置する領域に、ブロック数と各ブロックの不揮発性メモリの格納先アドレス、転送先ＲＡＭアドレス、ブロック長、初期値、及び制御情報を配置する。
（５）上記（３）と（４）の情報はブロックＩＤ（ブロック０、ブロック１、ブロック２）毎に対応している。

上記のような構成において、車両用電子制御装置の起動時に、（３）と（４）の情報に応じてＥＥＰＲＯＭ３５内の記憶データの読み出しを行い、メモリ配置が変化している場合には再配置の書き込みを実施する。また、ＥＥＰＲＯＭ３５内の記憶データのブロック長が新しいソフトウェアのブロック長に対して不足している場合には、不足分のデータのみ初期値を設定する。すなわち、不足しているデータのみ部分的に書き込んで初期値を設定し、他の部分はＲＡＭ３２に転送した書き換え前の記憶データを新しい配置で書き込む。
このようにすることで、ＥＥＰＲＯＭ３５にデータを記憶する電子制御装置において、ソフトウェアの書き換え（アップデート）時に可能な限り書き換え前の記憶データを消去することなく持ち越すことが可能となる。

次に、上述した（１）〜（５）のメモリ構成について、図４乃至図８により詳しく説明する。
図４及び図５はそれぞれ、リプログラミングの対象となるＥＥＰＲＯＭ３５のブロック構成例を示している。また、図６は、フラッシュメモリ３４におけるソフトウェア領域の構成例を示している。
図４に示すように、ＥＥＰＲＯＭ３５にソフトウェアの用途毎に種類の異なる複数のブロックBlock0、Block1、Block2、…を配置する。このブロック数は可変であり、各ブロックBlock0、Block1、Block2、…は消去単位の整数倍の記憶容量に設定されている。また、各ブロックBlock0、Block1、Block2、…のブロック長は、用途に応じてサイズが可変となっている。

このＥＥＰＲＯＭ３５には、図５に示すように、固定のアドレスにブロック数、各ブロック０〜２には格納先の不揮発性メモリのアドレスとブロック長を配置している。ここで、固定のアドレスは、すべてのソフトウェアバージョンで固定であり、各ブロック０〜２の格納情報のデータ長は同一、またブロックの追加／削除により全体のサイズは可変である。

更に、図６に示すように、フラッシュメモリ３４におけるソフトウェア領域には、ブロック数、各ブロック０〜２には格納先の不揮発性メモリのアドレス、転送先ＲＡＭアドレス、ブロック長、初期値格納先アドレス、及び制御情報を配置している。ここで、各ブロック０〜２の格納情報のデータ長は同一である。
このように、ＥＥＰＲＯＭ３５のブロック構成とフラッシュメモリ３４におけるソフトウェア領域の構成は対応した構成になっている。

図７及び図８はそれぞれ、ソフトウェアのアップデート時の制約について説明するための図である。例えば図７（ａ）に示すように、３つのブロックBlock0、Block1、Block2が配置されているＥＥＰＲＯＭ３５のブロック構成において、ソフトウェアのアップデートを行う場合に、図７（ｂ）に示すような終端へのブロックBlock3の追加や、図７（ｃ）に示すようなブロックBlock2の削除が可能である。しかし、中間にあるブロックの削除、及び中間へのブロック挿入は不可となっている。

また、ソフトウェアのアップデートにおいて、例えば図８（ａ）に示すように、３つのブロックBlock0、Block1、Block2が配置されている場合に、図８（ｂ）に示すように、１つのブロックBlock1の終端の領域拡張、または図８（ｃ）に示すように、１つのブロックBlock1の終端の領域縮小は可能である。しかし、１つのブロックの中間領域への挿入（拡張）と、中間領域の削除（縮小）は不可となっている。

次に、図９及び図１０により、上述したようなメモリ構成において、リプログラミングの手順について詳しく説明する。図９及び図１０はそれぞれ、リプログラミングに際して、不揮発性メモリ（フラッシュメモリ３４とＥＥＰＲＯＭ３５）に対して実行される処理の概要を示すフローチャートである。
車両用電子制御装置の起動時に、まず処理対象のブロックをBlock0に設定し（ステップＳ１）、ＥＥＰＲＯＭ３５の固定アドレスに格納されているブロック数分終了したか否かを判定する（ステップＳ２）。そして、終了していないと判定されると、各ブロックに対してステップＳ３〜Ｓ１０の処理をブロック数分繰り返す。

ステップＳ３では、ＥＥＰＲＯＭ３５のソフトウェア領域に、ブロック情報が格納されているか否かを判定する。ブロック情報が格納されていると判定されると、ブロックは「検証有効」か否かを判定する（ステップＳ４）。そして、「検証有効」と判定されると、ブロックの検証を実施し（ステップＳ５）、「検証無効」と判定されると、検証結果を正常とする（ステップＳ６）。ステップＳ３において、ＥＥＰＲＯＭ３５のソフトウェア領域に格納されているブロック数が、これから格納するブロックよりも多い場合、余分なブロックのデータは破棄する。

上記ステップＳ４，Ｓ５，Ｓ６では、リプログラミング対象のブロックについて、ＥＥＰＲＯＭ３５とフラッシュメモリ３４のソフトウェア領域の両方に情報が格納されており、且つソフトウェア領域の制御情報に「検証有効」としてデータが設定されている場合、ＥＥＰＲＯＭ３５内のデータを検証する。検証には、ＣＲＣ（Cyclic Redundancy Check）やチェックサム（Check Sum）などを用いる。そして、「検証無効」に設定されている場合には、検証結果を正常なものとして扱う。

次のステップＳ７では、検証結果が正常か否か判定し、正常であると判定されると、ＥＥＰＲＯＭ３５からＲＡＭ３２へデータを転送する（ステップＳ８）。これによって、リプログラミング対象ブロックの検証結果が正常であった場合には、ＥＥＰＲＯＭ３５の格納先アドレスから、フラッシュメモリ３４におけるソフトウェア領域の転送先ＲＡＭ３２のアドレスへデータが転送される。
この際、ＥＥＰＲＯＭ３５に格納されるブロック長がフラッシュメモリ３４のソフトウェア領域に格納されるブロック長よりも小さい場合、不足分のデータはソフトウェア領域に格納される初期値格納先アドレスから転送する（オフセット分を考慮して）。一方、ＥＥＰＲＯＭ３５に格納されるブロック長がソフトウェア領域に格納されるブロック長よりも大きい場合、ＥＥＰＲＯＭ３５に格納される余分なデータは破棄する。

上記ステップＳ７で検証結果が正常でないと判定されると（対象ブロックの検証結果が異常であった場合）、フラッシュメモリ３４のソフトウェア領域に格納される初期値格納先アドレスから転送先ＲＡＭ３２のアドレスへデータを転送する（ステップＳ９）。

続くステップＳ１０では、処理対象のブロックＩＤをインクリメントし、ステップＳ２に戻り、ＥＥＰＲＯＭ３５に格納されているブロック数分終了するまでステップＳ３〜Ｓ１０の処理を繰り返す。
そして、ステップＳ２でブロック数分終了と判定された場合、及びステップＳ３でフラッシュメモリ３４のソフトウェア領域にブロック情報が格納されていない、と判定された場合には、ステップＳ１１に移動する。

ステップＳ１１では、フラッシュメモリ３４のソフトウェア領域に格納されるブロック数分終了したか否か判定し、フラッシュメモリ３４の初期値格納先アドレスからＲＡＭ３２へデータを転送する（ステップＳ１２）。続いて、処理対象のブロックＩＤをインクリメントする（ステップＳ１３）。
これらのステップＳ１１〜Ｓ１３は、リプログラミングによってブロックアドレスが増加している場合の処理である。フラッシュメモリ３４のソフトウェア領域に格納されるブロック数がＥＥＰＲＯＭ３５に格納されるブロックよりも多い場合には、不足分のブロックについてはフラッシュメモリ３４のソフトウェア領域に格納される初期値格納先アドレスから転送先アドレスへデータを転送する。

ステップＳ１３で、処理対象のブロックＩＤをインクリメントした後、あるいはステップＳ１１でブロック数分終了したと判定された場合（ブロックアドレスが増加していない場合）には、すべてのブロックについてＥＥＰＲＯＭ３５の格納先アドレスまたはブロック長の変更があるか否か判定する（ステップＳ１４）。ＥＥＰＲＯＭ３５の格納先アドレスまたはブロック長の変更がある場合、またはブロック数に変更がある場合はＥＥＰＲＯＭ３５上のデータを再配置するための書き込みを実施して終了する（ステップＳ１５）。再配置は、フラッシュメモリ３４のソフトウェア領域に格納されるＥＥＰＲＯＭ３５の格納先アドレス及びブロック長に従い実施する。ステップＳ１４で変更がないと判定された場合には、再書き込みは行わずに終了する。

上述したようなリプログラミングの手順によれば、車両１０のＥＣＭ３０における制御プログラムの書き換え時、車両情報や学習値の記憶データが予め定められたブロック構成で保存され、そのブロック内のデータサイズが変更されるのみの場合に、簡易な処理により更新プログラムで継続使用できる。
従って、本発明によれば、プログラムの書き換えでブロックサイズが変化するときは、書き換え前のプログラムによって記憶されたデータを、書き換え後のプログラムに対応するブロックサイズに再配置するので、不揮発性メモリにデータを記憶する電子制御装置において、ソフトウェアの書き換え時に可能な限り書き換え前の記憶データを消去することなく持ち越すことが可能となる。これによって、故障への対処や学習値の消失による制御の遅れを抑制できる。

なお、本発明は上述した実施形態に限定されるものではなく、要旨を逸脱しない範囲で種々変形して実施可能である。
＜変形例１＞
上記構成（１）について、各ブロックのデータの堅固性向上のため冗長化する構成を採用しても良い。図１１は、冗長化しない場合のＥＥＰＲＯＭ３５のブロック構成を示しており、図１２は、冗長化した場合のＥＥＰＲＯＭ３５のブロック構成を示している。図１１と図１２を対比すれば明らかなように、冗長化した場合には、各ブロックBlock0(base)とBlock0(mirror)、Block1(base)とBlock1(mirror)、Block2(base)とBlock2(mirror)、…が一対ずつ配置される。
この場合には、フラッシュメモリ３４のソフトウェア領域に格納する制御情報にて冗長化の有無を設定し（不変）、ＥＥＰＲＯＭ３５に格納されるブロック長から冗長化した分のブロックの格納先アドレスを自動的に計算できる構成とすればよい。

＜変形例２＞
上記構成（１）について、各ブロックのＥＥＰＲＯＭ３５の劣化の緩和のため、書き込み毎に格納先アドレスを移動する多バンク構成にしてもよい。図１３は、各ブロックBlock0、Block1、Block2、…がそれぞれ３つのバンクで構成された例を示しており、Block0(bank0)，Block0(bank1)，Block0(bank2)，Block1(bank0)，Block1(bank1)，Block1(bank2)，Block2(bank0)，Block2(bank1)，Block2(bank2)，…が配置されている。
この場合には、ＥＥＰＲＯＭ３５とフラッシュメモリ３４の各ブロック情報に「バンク数」のデータを追加し、各バンクの格納先アドレスは、ＥＥＰＲＯＭ３５に格納されるブロック長から自動的に計算できる構成とする。また、最新のバンクを識別するためのロジックも追加する（シーケンス番号など）。

＜変形例３＞
上記構成（１）について、変形例１と変形例２を組み合わせた構成にしてもよい。図１４は、各ブロックBlock0、Block1、Block2、…がそれぞれ３つのバンクで構成され、且つ冗長化した例を示しておりBlock0(bank0)(base)，Block0(bank1)(base)，Block0(bank2)(base)，Block0(bank0)(mirror)，Block0(bank1)(mirror)，Block0(bank2)(mirror)，Block1(bank0)(base)，Block1(bank1)(base)，Block1(bank2)(base)，Block1(bank0)(mirror)，Block1(bank1)(mirror)，Block1(bank2)(mirror)，Block2(bank0)(base)，Block2(bank1)(base)，Block2(bank2)(base)，Block2(bank0)(mirror)，Block2(bank1)(mirror)，Block2(bank2)(mirror)，…が配置されている。

＜変形例４＞
ＥＥＰＲＯＭ３５に格納する上記構成（３）のデータは、図１５に示すように検証用データ（ＣＲＣなど）を終端（終端ブロックの後）に持つ構成を採用することもできる。
検証用データを持つ構成の場合、データ故障を検出した際はＥＥＰＲＯＭ３５を初期状態（格納データ無し）として扱う。

＜変形例５＞
上記変形例４の構成を採用する場合、図１６に示すように上記構成（３）のデータを冗長化する構成にしてもよい。
冗長化する構成の場合、どちらか一方が正常であれば正常側を採用し、両方とも異常の場合のみＥＥＰＲＯＭ３５を初期状態（格納データ無し）として扱う。また、どちらか一方が異常の場合は、正常側のデータを異常側へ書き直す。

＜変形例６＞
上記構成（３）の各データは、読み出し時にデータの正当性を検証する構成にすることもできる。
検証は、例えば格納先のＥＥＰＲＯＭ３５のアドレスが正常範囲であるかどうかなどについて実行する。

＜変形例７＞
上記図９に示したステップＳ７，Ｓ８の処理において、ブロック長更新時の処理をソフトウェア領域に格納される制御情報に設定する構成にしてもよい。この場合、ブロック長更新時に初期値格納先アドレスからブロックの全領域分を転送するか、拡張部分のみ更新するかを選択できる。
上記制御情報の構成例としては、下記のようなものが考えられる。
Bit 0：ブロック検証有効フラグ（１：検証有効、０：検証無効）
Bit 1：ブロック初期値選択フラグ（１：ブロック毎の初期値を設定、０：全領域０を設定）
Bit 2：ブロック長更新時初期化選択フラグ（１：全領域初期化、０：拡張分のみ初期化）
Bit 3：ブロック冗長化有効フラグ（１：冗長化あり、０：冗長化無し）

次に、ソフトウェアアップデートにおけるＥＥＰＲＯＭ３５の割り当ての変更例について説明する。ここでは、システムの変更内容として、システムから機能Ａを削除して、機能Ｂを追加する場合を例に取る。機能Ａと機能Ｂはそれぞれ異なる学習データを持ち、不揮発性メモリへ記憶する必要があるものとする。
図１７に示すように、変更前にはブロック数が３であり、ブロック０に診断情報、ブロック１にシステム動作履歴情報、ブロック２に機能Ａの学習データが書き込まれているものとする。変更後には、ソフトウェアのアップデートに伴い、診断情報のブロック０を拡張している。ここでは、ブロック長が２５６bytesから３２０bytesになっている。ブロック１は変更がない。機能Ａの削除に伴い、機能Ａ学習データのブロック２を縮小する。ブロックの削除はできないため、ブロック長を６４bytesから０bytesに設定している。更に、機能Ｂの追加に伴い、機能Ｂの学習データのブロック３を追加して、ブロック数が４に増加している。本例では、ブロック長を９６bytesに設定している。

図１８は、図１７に示した各ブロックの制御情報の設定を纏めて示している。ブロック検証有効フラグ（Bit0）は、診断情報（ブロック０）、システム動作履歴情報（ブロック１）、機能Ａ学習データ（ブロック２）、機能Ｂ学習データ（ブロック３）の何れも１であり、検証有効である。ブロック初期値選択フラグ（Bit1）は、ブロック０〜３の全てが１であり、ブロック毎の初期値を設定している。ブロック長更新時初期化選択フラグ（Bit2）は、診断情報（ブロック０）が１で全領域初期化である。これによって、アップデート時に、ブロック内のデータ構成を変更可としている。また、システム動作履歴情報（ブロック１）は０であり、拡張分のみ初期化する。情報が追加された場合も既存データは保持する。機能Ａ学習データ（ブロック２）と機能Ｂ学習データ（ブロック３）は共に１であり、学習値の整合のため、更新時は全初期化する。ブロック冗長化有効フラグ（Bit3）は、ブロック０〜３の全てが１であり、冗長化ありになっている。

なお、上述した実施形態と変形例では、ＥＣＭを例に取って説明したが、プログラムやデータがリプログラミングされる電子制御装置一般に適用できるのは勿論である。
また、ＥＣＭが燃料噴射弁、ＶＴＣ機構及び点火モジュールなどを制御する例について説明したが、車両に搭載された各種の機器、例えば変速機、電動ブレーキシステム、ＡＢＳ（Antilock Brake System）、及びブラシレスモータなどを制御する電子制御装置にも同様に適用できる。

１０…車両、２０…エンジン、３０…ＥＣＭ（車両用電子制御装置）、２１…センサ、２２…アクチュエータ、３１…プロセッサ、３２…ＲＡＭ、３３…ＲＯＭ、３４…フラッシュメモリ、３５…ＥＥＰＲＯＭ（記憶装置）、３７…入出力インターフェース、３８…外部通信インターフェース、３９…バス、４０…ネットワークケーブル、５０…リプログラミングツール、６０…外部ツール

Claims (3)

1. 外部から書き換え可能に設定され、車両の動作中に生じたデータを必要に応じて記憶する不揮発性記憶装置を備えた車両用電子制御装置であって、
   前記不揮発性記憶装置に、車両の制御に使用する複数のプログラム間で共通する前記データを予め定められたブロック構成で記憶し、前記プログラムの書き換えでブロックサイズが変化するときは、書き換え前のプログラムによって記憶されたデータを、書き換え後のプログラムに対応するブロックサイズに変換して再配置する、ことを特徴とする車両用電子制御装置。
2. データを記憶するブロックの順序は不変とし、ブロックサイズのみ変更する、ことを特徴とする請求項１に記載の車両用電子制御装置。
3. 前記書き換え後のプログラムで追加されたブロックには、該当データの初期値を記憶する、ことを特徴とする請求項１又は２に記載の車両用電子制御装置。