JP2006298261A - 自動車用制御ユニット - Google Patents

Abstract

【課題】 不揮発性メモリに対し、時間制約の厳しい小さなデータを効率よく記憶することができる不揮発性メモリ制御装置を提供する。
【解決手段】 フラッシュメモリ５内の消去単位となる主メモリブロック５ｆを複数のサブメモリブロック５ｍに区画する。サブメモリブロック５ｍは、未使用のものに限り初回の１回だけ書き込みを許し、一旦使用済みになったサブメモリブロック５ｍについては、主メモリブロック単位での消去を行うまではデータの追記を禁止する。
【選択図】 図２

Description

この発明は、自動車用制御ユニットに関する。

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

自動車には、各種機器（被制御要素）を制御するためにＥＣＵが搭載されている。ＥＣＵは、ＣＰＵからなる主制御部を有し、自動車上に搭載される電子機器の制御処理を予め定められた機能制御用ソフトウェア（アプリケーション）の実行に基づいて実施する。このアプリケーションは、バージョンアップやバグ修正等のために、内容を随時更新できるよう、フラッシュＲＯＭ（フラッシュメモリ）に記憶されることが多い（特許文献１〜３）。アプリケーションの更新処理は、車両持込にて販売店などで行われる場合がほとんどであるが、近年では無線通信による車両外部インフラ（例えば携帯電話網など）の普及により、ユーザー自身の手で実行させるシーンもありえる。

自動車のアプリケーション（機能制御用ソフトウェア）のバージョンアップ処理は、その機能制御用ソフトウェアとは別に用意された書換用のプログラム（ファームウェア）を用いて行なう必要がある。自動車に搭載されたＥＣＵの場合、パソコンのＯＳ等と異なり、搭載されたアプリケーションのバージョンアップに関しても、書換処理そのものにユーザーの関心が向けられるのは稀であり、当該書換処理を現実に実行するのも販売店側の担当員である場合がほとんどである。例えば、ＥＣＵをリセット後に再起動した時、アプリケーションの書き換えに関与する余計なルーチンが勝手に立ち上がるようになっていると、普段は普通に享受している自動車機能が作動しなくなるばかりか、わけのわからない書換処理の入力待ち状態に移行してしまい、ユーザーをうろたえさせることにもつながる。このようなわけで、ＥＣＵがリセット後に再起動するときは、図１５に示すように、必ずアプリケーションの本体部分（機能実現プログラム部分）が優先的に立ち上がり、書換用処理へ移行したい場合は、このアプリケーションからのコマンド入力により書き換えファームウェアを立ち上げるようにしている。具体的には、上記アプリケーションの実行ステップの一つにて、一般ユーザーが通常は操作しないメンテナンス用インターフェース（例えば専用コマンドにて呼び出すタッチパネル画面や、専用コネクタへの入力ツール接続にて実現される）からの入力により、書き換えファームウェアの起動コマンドを受け付ける。

ところで、フラッシュＲＯＭ内の旧バージョンプログラムを更新バージョンプログラムにより上書き（あるいは無効化）する形で書換処理を行った場合、その更新バージョンプログラムの書き込み処理中に、何らかの要因（例えば、ＥＣＵの電源遮断、通信途絶、書換処理のバグや暴走、ハードウェア異常、更新バージョンプログラムを搭載した専用の書き換えツールを車内ネットワークに接続して書き換えを行なう場合はコネクタ脱落など）でその書き込み処理に失敗してしまうことがある。この場合、更新バージョンプログラムはもちろんのこと、旧バージョンプログラムも使用不能あるいは機能不全を来たすこととなり、ユーザーへの機能提供に深刻な影響が及ぶので、当然のことながら、そのアプリケーションの書換処理を再度やり直す必要がある。

しかし、上記従来のＥＣＵのように、書き換えファームウェアの起動コマンドがアプリケーション側からの入力により受け付けられるようになっていると、そのアプリケーションの書換処理に一旦失敗してしまった場合、以降はアプリケーションの正常な起動は望むべくもなくなり、結果としてこれを修復するための書き換えファームウェアも起動できなくなって、書換処理の再実行が不能に陥ることになる。この場合、ＥＣＵを取り外して専用の装置に組み付け、アプリケーションを格納しているフラッシュＲＯＭの内容を書き直せばよいが、車体の奥まった位置にマウントされているＥＣＵの取り外しには非常に手間が係り、正常復帰に思わぬ時間と労力を浪費することにつながる。

本発明の課題は、不揮発性メモリに搭載されている制御用のソフトウェアの書換処理に万一失敗しても、その再書換処理を確実に行なうことができる機能を有した自動車用制御ユニットを提供することにある。

課題を解決するための手段及び発明の効果

上記の課題を解決するために、本発明の自動車用制御ユニットは、
自動車上に搭載される電子機器の制御処理を司る機能制御用ソフトウェアを格納するとともに、記憶内容が電気的に書換え可能であって、外部からのリセット信号を受けても記憶内容を保持する不揮発性メモリと、
該機能制御用ソフトウェアの実行メモリとなるＲＡＭと、機能制御用ソフトウェアの実行に基づいて電子機器の制御処理を行なうＣＰＵと、
不揮発性メモリに格納された機能制御用ソフトウェアの内容を書き換えるための書換用ファームウェアが格納された書換用ファームウェア記憶部と、
書換用ファームウェアによる機能制御用ソフトウェアの書換処理が正常に完了したかどうかを識別するための書換状態識別情報を書換え可能に記憶する書換状態識別情報記憶部と、
書換用ファームウェアによる書換処理の進行状態を管理し、該進行状態に応じて書換状態識別情報記憶部における書換状態識別情報の記憶内容を、書換処理が正常に完了したか否かが把握可能となるように書き換える識別情報書換手段と、
機能制御用ソフトウェアを起動する際に書換状態識別情報記憶部の記憶内容を参照し、記憶内容が、書換処理が正常に完了したことを示す内容になっている場合は機能制御用ソフトウェアを起動し、書換処理が不完全であることを示す内容になっている場合は機能制御用ソフトウェアに代えて書換用ファームウェアを再起動する処理を、機能制御用ソフトウェアとは独立に実行する起動制御手段と、を有してなることを特徴とする。

上記本発明によると、機能制御用ソフトウェアの書換処理が実行される毎に、それが正常に完了したかどうかを書換状態識別情報としてその都度記憶する。そして、次に機能制御用ソフトウェアを起動しようとするとき、直ちに機能制御用ソフトウェアを起動するのではなく、まず、その書換状態識別情報の内容を参照する。そして、その結果、前回の書換処理が万一不完全であることが判明した場合は、該機能制御用ソフトウェアの代わりに書換用ファームウェアを再起動する。つまり、機能制御用ソフトウェアの内部にて書換用ファームウェアの起動コマンドが実行されるのではなく、機能制御用ソフトウェアからは独立した起動制御手段が、書換状態識別情報を参照した上で独自に書換用ファームウェアの再起動を行なうから、機能制御用ソフトウェアの書き換えに失敗した場合でもその再書換処理を確実に行なうことができる。

識別情報書換手段は、書換用ファームウェアの起動時に書換状態識別情報記憶部の該ファームウェア起動前の記憶状態を無効化し、その後、書換用ファームウェアが不揮発性メモリにおける機能制御用ソフトウェアの書換処理を正常に完了するに伴い、書換状態識別情報記憶部の記憶状態を、書換え正常完了を示す予め定められた書換え正常完了状態に設定するものであり、起動制御手段は、書換状態識別情報記憶部の記憶内容が書換え正常完了状態になっている場合にのみ機能制御用ソフトウェアを起動するものとして構成できる。機能制御用ソフトウェアの書き換え時に書換状態識別情報記憶部の内容を無効化し、書換処理が正常に完了した場合に、該書換状態識別情報記憶部の内容を書換え正常完了状態に設定しなおすことで、機能制御用ソフトウェアの書き換えに成功したかどうかを確実に判別することができ、結果として、不成功の場合の書換用ファームウェアによる再書換処理にもスムーズに移行することができる。

識別情報書換手段は、書換用ファームウェアによる機能制御用ソフトウェアの書換処理の開始に対応して、書換状態識別情報記憶部の記憶内容を、書換中を示す予め定められた書換中状態に設定するとともに、当該書換中状態を機能制御用ソフトウェアの書換処理が正常完了するまで維持するものであり、起動制御手段は、書換状態識別情報記憶部の記憶内容が書換中状態になっている場合に書換用ファームウェアを起動するものとすることができる。この構成にて、書換状態識別情報記憶部の記憶内容が書換中状態のまま残っているということは、前回の書換処理が途中で中断されてしまったことを意味するから、書換用ファームウェアを直ちに起動することにより、その修復処理に迅速に移行することができる。

書換用ファームウェアは、書き換えに使用する機能制御用ソフトウェアの更新バージョンプログラムを、自動車用制御ユニットにネットワーク接続されたデータ送信元装置から通信取得して書き換えを行なうものとすることができる。この場合、識別情報書換手段は、データ送信元装置から受信する書換中状態維持指令を受けることにより、書換状態識別情報記憶部の記憶内容を書換中状態に維持するものとすることができる。この方式によると、データ送信元装置と連携することで更新バージョンプログラムの転送・書き込みの状態把握をより確実に行なうことが可能となり、書換中状態の設定に係る信頼性も大幅に向上する。

この場合、識別情報書換手段は、機能制御用ソフトウェアの書換処理の開始から正常完了に至るまでの間に、データ送信元装置から書換中状態維持指令を定期的に受信するものであり、該書換中状態維持指令の受信継続に対応して書換状態識別情報記憶部の記憶内容を書換中状態に維持するものとすれば、上記効果をさらに高めることができる。例えば、書換用ファームウェアが、データ送信元装置から更新バージョンプログラムを複数ブロックに分割された形で順次受信するものとした場合、識別情報書換手段は、データ送信元装置からブロック毎に書換中状態維持指令を受けるものとすることができる。

次に、識別情報書換手段は、書換用ファームウェアがデータ送信元装置から受信した更新バージョンプログラムを不揮発性メモリに全て書き込み、さらに、データ送信元装置から受信したベリファイ用データに基づいて書き込まれた更新バージョンプログラムのベリファイを完了した場合に、書換状態識別情報記憶部の記憶状態を書換え正常完了状態に設定するものとすることができる。ベリファイ後に書換え正常完了状態が設定されるので、書き込まれた更新バージョンプログラムを使用に供する際の信頼性を高めることができる。この場合、識別情報書換手段を、書換用ファームウェアによる書換処理がベリファイの途中で中断した場合に、書換状態識別情報記憶部の記憶内容を、ベリファイ中の中断であることが特定可能な形で書換中状態に設定するものとして構成することができる。これに対応して、起動制御手段は、ベリファイ処理から書換処理が再開されるように書換用ファームウェアを再起動するものとすることができる。これにより、ベリファイ段階での中断に関しては、更新バージョンプログラムの書き込み処理まで遡らず、当該ベリファイ処理だけがやり直しになるので、再書換処理を大幅に簡略化することができる。

また、識別情報書換手段は、書換用ファームウェアが不揮発性メモリへの機能制御用ソフトウェアの書換処理が途中で中断した場合に、書換状態識別情報記憶部の記憶内容を、当該書換処理（不揮発性メモリへの書き込み処理の他、書き込まれたデータのベリファイ処理も概念に含む）の中断位置を特定可能な形で書換中状態に設定するものとして構成することができる。この場合、起動制御手段は、書換状態識別情報記憶部の記憶内容から中断位置を特定し、該中断位置から書換処理が再開されるように書換用ファームウェアを再起動するものとして構成することができる。この構成によると、書換処理が途中で中断した場合、その中断位置から書換用ファームウェアによる書換処理を再開できるので、再書換処理を大幅に簡略化することができる。

上記中断位置の特定は、原理的には更新バージョンプログラムデータを構成するビット単位にまでその分解能を高めることができるが、この場合、各ビットに書換状態識別情報を随伴させなければならず、結果として書換状態識別情報の合計サイズが非常に大きくなってしまい、メモリの無駄な消費につながる。例えば、書換用ファームウェアが、データ送信元装置から更新バージョンプログラムを複数のブロック（もちろん、複数ビットからなるものである）に分割された形で順次受信するものである場合、識別情報書換手段は、書換用ファームウェアが不揮発性メモリへの機能制御用ソフトウェアの書換処理が途中で中断した場合に、書換状態識別情報記憶部の記憶内容を、当該書換処理がどのブロックで中断されたかを特定可能な形で書換中状態に設定するものとすることができる。また、起動制御手段は、書換状態識別情報記憶部の記憶内容から処理中断されたブロックを特定し、該ブロックから書換処理が再開されるように書換用ファームウェアを再起動するものとすることができる。この方法であると、書換状態識別情報はブロック毎に随伴させるだけで済むようになり、その合計サイズの肥大を防止することができる。

書換状態識別情報記憶部は、更新バージョンプログラムの各ブロックに対応して複数設けることができる。識別情報書換手段は、複数の書換状態識別情報記憶部の記憶状態を、書換処理の完了したものから順に書換え正常完了状態に設定するものであり、起動制御手段は、書換状態識別情報記憶部の記憶状態が書換え正常完了状態に設定されていないブロックから書換処理が再開されるように書換用ファームウェアを再起動するものとすることができる。このようにすると、書き換え順序の決められた各ブロックの書換状態識別情報記憶部の内容を順次確認することで、どのブロックまで書換処理が正常完了しているかを速やかにかつ適確に把握することができる。

以下、本発明の実施の形態を、図面を参照して説明する。
図１は、本発明の自動車用制御ユニットの概念が適用されるＥＣＵの電気的な構成図である。ＥＣＵ１は、ＣＰＵ３からなる主制御部を有し、自動車上に搭載される電子機器（制御対象機器：被制御要素）の制御処理を該主制御部による予め定められたアプリケーション（機能制御用ソフトウェア）の実行に基づいて実施するものであり、具体的には、ＣＰＵ３、ＲＯＭ５、ＲＡＭ４及び入出力部（Ｉ／Ｏポート）２がバス接続されたマイクロプロセッサからなる。ＥＣＵ１は、本実施形態では自動車のボデー系の制御を司るボデー系ＥＣＵとして構成される。各アプリケーション１８はＲＯＭ５に格納され、同じくＲＯＭ５に格納されたプラットフォーム５ｃ上で動作するものであり、ＲＡＭ４内に個別のワークエリア４ｄが確保されている。プラットフォーム５ｃは、ベースとなるハードウェアが相違する場合にも、各アプリケーションに共通の動作環境を与えるためのものであり、該アプリケーションに対する基本ソフト（ＯＳ）のほか、アプリケーションやハードウェアとの連携を図るインターフェースプログラムなどを含んで構成される。また、後述の起動制御手段の機能もこのプラットフォーム５ｃに組み込まれ、ＲＡＭ４内のワークエリア４ｃを利用してＣＰＵ３により実行されるものである。

アプリケーションは、車両利用者による車両各部の操作に係る機能であるボデー系機能を実現するものである。このボデー系機能とは、具体的には、ドア開閉に伴う制御、窓開閉に伴う制御、ライトスイッチのオン／オフに伴う制御、キーレスエントリ方式等に採用されるワイヤレスドアロック機構の制御、・・・といったものをいう。具体的には、以下のようなものを例示できる：
・運転席ドア、助手席ドア、後部右側座席ドア、後部左側座席ドア、ルーフなどのロック／ロック解除、パワーウィンドウ動作など。
・エアコン、カーオーディオ、カーナビゲーションシステムなどの電源動作など。
・ルームランプ、コックピットランプ、ヘッドライト、スモールランプ、ハザードランプ、テールランプなどのスイッチ点灯制御など。

ＥＣＵ１は、シリアル通信バス３０を介して他のＥＣＵと接続されており、シリアル通信バス３０と各ＥＣＵの内部バスとは、シリアル通信インターフェース６を介して接続されている。該シリアル通信バス３０を介したデータ送受信処理を司る通信用ファームウェア５ｂもＲＯＭ５に格納され、ＲＡＭ４内のワークエリア４ｂを利用してＣＰＵ３により実行される。

ソフトウェアが格納されているＲＯＭ５は、記憶内容が電気的に書換え可能であって、外部からのリセット信号を受けても前記記憶内容を保持する不揮発性メモリとして構成され、本実施形態では、フラッシュＲＯＭ（フラッシュメモリ）にて構成されている（以下、フラッシュＲＯＭ５ともいう）。フラッシュＲＯＭ５は、読み出し時の駆動電圧と書き込み消去時の駆動電圧が異なり、後者（例えば９Ｖ）が前者（例えば５Ｖ：リセット信号も同レベルのエッジトリガ信号である）よりも高く設定されている。つまり、書き込み／消去の信号電圧がリセット信号よりも電圧で制御されるため、リセット信号を受けてもフラッシュＲＯＭ５の記憶内容は保持される。フラッシュＲＯＭ（不揮発性メモリ）５は、その記憶領域が、複数の書き換え単位ブロックに分割されており、該書き換え単位ブロック１５を単位とする形で記憶内容の消去、書き込み及び書き換えが可能である。

また、フラッシュＲＯＭ５には、フラッシュＲＯＭ５に格納されたアプリケーション１８の内容を書き換えるための書換用ファームウェア５ａが格納されている（この格納領域が書換用ファームウェア記憶部である）。書換用ファームウェア５ａは、書き換え（バージョンアップ）の対象となるアプリケーションの更新バージョンプログラムのデータを、データ送信元装置よりシリアル通信バス３０を介して取得し、ＲＡＭ４の書換用ワークエリアをバッファ領域として、上記の書き換え単位ブロック毎にフラッシュＲＯＭ５に書き込むことで書換処理を行なう。データ送信元装置は、例えばコネクタ９を介してシリアル通信バス３０に接続されたプログラム書換ツール１０である。このプログラム書換ツール１０は、アプリケーションの更新バージョンプログラムのデータを記憶する固定記憶部を有したコンピュータ端末装置として構成される。なお、データ送信元装置は、更新バージョンプログラムデータを、外部の無線通信網から無線通信ユニット３１により受信する別のＥＣＵであってもよい。

図２は、フラッシュＲＯＭ５におけるアプリケーション１８の格納領域の構造を示すものである。ここには、書換用ファームウェア５ａによるアプリケーション１８の書換処理が正常に完了したかどうかを識別するための書換状態識別ＩＤ（書換状態識別情報：以下、単に「識別ＩＤ」ともいう）を書換え可能に記憶する書換状態識別ＩＤ記憶部（書換状態識別情報記憶部：以下、単に「識別ＩＤ記憶部」ともいう）１０１ａが形成されている。本実施形態においては、該格納領域の先頭に固定アドレス領域からなるヘッダ部１０１が形成され、これに続く形でプログラム本体格納部１０２が形成されている。ヘッダ部１０１には、アプリケーション名、プログラム本体の先頭アドレス及び末尾アドレスの各格納部と、前述の識別ＩＤ記憶部１０１ａが形成されている。識別ＩＤ記憶部１０１ａのアドレスもまた固定されている。

また、ＥＣＵ１は、書換用ファームウェア５ａによる書換処理の進行状態を管理し、該進行状態に応じて識別ＩＤ記憶部１０１ａにおける識別ＩＤの記憶内容を、書換処理が正常に完了したか否かが把握可能となるように書き換える識別情報書換手段の機能を具備してなる。本実施形態においては、該識別情報書換手段の機能も書換用ファームウェア５ａが兼ねてなる（ただし、書換用ファームウェア５ａとは別のファームウェアとしてもよい）。また、アプリケーション１８を起動する際に識別ＩＤ記憶部１０１ａの記憶内容を参照し、該記憶内容が、書換処理が正常に完了したことを示す内容になっている場合はアプリケーション１８を起動し、書換処理が不完全であることを示す内容になっている場合はアプリケーション１８に代えて書換用ファームウェア５ａを再起動する処理を、アプリケーション１８とは独立に実行する、起動制御手段の機能も有している。この機能は、本実施形態においては、プラットフォーム５ｃに組み込まれている。

図４は、書換用ファームウェア５ａによる書換処理の、最も単純な場合の一例を概略的に示すものである。図２に示すように、ここでは、識別ＩＤを１ビットデータにて構成し、書換中を「０」に、書き換え完了を「１」に対応させ（もちろん、逆でもよい）、それ以外の状態は識別しないものとする。図１のコネクタ９に接続された書換ツール１０（データ送信元装置）から、図２に示すように書換開始通知を受けることにより書換用ファームウェア５ａは起動される。書換用ファームウェア５ａは、その起動に際して、図２の識別ＩＤ記憶部１０１ａの、該ファームウェア起動前の記憶状態を無効化する。この無効化の方法は種々考えられるが、本実施形態では書換中を示す「０」にリセットする処理とする。その結果、識別ＩＤ記憶部１０１ａは、その無効化された状態が、書換中を意味する内容と実質的に等価となる。換言すれば、ファームウェア起動前の記憶状態を無効化する処理が、当該記憶状態を、書換中を示す「０」にセットする処理にも兼用されているといえる。なお、識別ＩＤ記憶部無効化フラグを別途設け、無効化を意味するフラグ値を立てることにより、識別ＩＤ記憶部１０１ａの記憶内容とは無関係に、これを無効化することも可能である。この場合、識別ＩＤ記憶部１０１ａは該識別ＩＤ記憶部無効化フラグをリセットすることにより有効化され、その記憶内容に応じた書換状態を示すものとなる。

他方、書換ツール１０から書換終了通知を受け、さらに、フラッシュＲＯＭ５におけるアプリケーション１８の書換処理を正常に完了すると、書換用ファームウェア５ａは、識別ＩＤ記憶部１０１ａの記憶状態を、書換え正常完了を示す予め定められた書換え正常完了状態「１」に設定する。その後、ＥＣＵ１をリセットしてアプリケーション１８を再度立ち上げようとする場合、プラットフォーム５ｃは、識別ＩＤ記憶部１０１ａの記憶内容が書換え正常完了状態「１」になっている場合にのみ、アプリケーション１８の起動を許可する。

他方、書換用ファームウェア５ａは、識別ＩＤ記憶部１０１ａに設定された書換中状態「０」を、アプリケーション１８の書換処理が正常完了するまで維持する。もし、書換処理が途中で中断してしまった場合、識別ＩＤ記憶部１０１ａの記憶内容は書換中状態「０」のままである。そして、その後ＥＣＵ１をリセットしたときに、プラットフォーム５ｃは、該記憶内容が書換中状態「０」になっていることを確認し、不完全な書換状態になっているアプリケーション１８を起動せずに、書換用ファームウェア５ａを起動し、書換ツール１０より更新バージョンプログラムのデータを改めて取得するとともに、それを用いて再書換処理を行なう。

上記のごとく、書換用ファームウェア５ａは、書き換えに使用するアプリケーション１８の更新バージョンプログラムを、ＥＣＵ１（自動車用制御ユニット）にネットワーク接続されたプログラム書換ツール（データ送信元装置）１０から通信取得して書き換えを行なうものである。プログラム書換ツール１０は、上記書換処理中において書換用ファームウェア５ａに対し、書換中状態維持指令（すなわち、識別ＩＤの値として「０」を保持する指令）を継続的に出力する。書換用ファームウェア５ａは上記書換中状態維持指令を受け、識別ＩＤ記憶部１０１ａの記憶内容を書換中状態（「０」）に維持する。

具体的には、書換ツール１０は、更新バージョンプログラムをブロック１０２ｂに分割された形でＥＣＵ１の書換用ファームウェア５ａ側に順次送信するとともに、１ブロック送信するたびに、対応する書換中状態維持指令を発行・送信しつづける。書換用ファームウェア５ａは、受信したブロックをフラッシュＲＯＭ５に書き込むとともに、その都度送られてくる書換中状態維持指令を受けて、識別ＩＤの値を「０」に維持し続ける。なお、書換用ファームウェア５ａ側でデータブロックは受信したが、何らかの要因により書換中状態維持指令が途絶えてしまった場合は、エラーログを作成して処理を終了する。

また、書換用ファームウェア５ａが受信した更新バージョンプログラムをフラッシュＲＯＭ５に全て書き込むと、プログラム書換ツール１０は、次に、送信した更新バージョンプログラムデータをベリファイするためのベリファイデータの送信を開始する。ベリファイデータは、更新バージョンプログラムデータと同一であってもよいし、チェックサムなど、更新バージョンプログラムデータを加工して作成したエラーチェック用データであってもいずれでもよい。プログラム書換ツール１０は、このベリファイデータに関しても、ブロック毎に書換中状態維持指令を発行・送信し続ける。書換用ファームウェア５ａは上記のベリファイデータを受けて、既にフラッシュＲＯＭ５に書き込んだ更新バージョンプログラムデータのベリファイを行い、また、書換中状態維持指令を受けて識別ＩＤを書換中状態「０」に維持する。そして、更新バージョンプログラムのベリファイを全て完了すると、書換用ファームウェア５ａは、識別ＩＤを書換え正常完了状態、つまり「１」に書き換える。

図５は、書換ツール１０とＥＣＵ１側の書換用ファームウェア（以下、単に「ファームウェア」ともいう）５ａとによる上記書換処理の流れをより詳細に示すフローチャートである。書換ツール１０側のフローを左に、書換用ファームウェア側の流れを右に、各の実行ステップの時系列を概ね一致させた形で表示しており、書換ツール１０とＥＣＵ１との間での通信による情報の流れを破線にて示している。また、ステップ番号は書換ツール１０側を”Ｓ＃＃”、書換用ファームウェア５ａ側を”Ｔ＃＃”にて表示している。また、現在どちらのフローの説明を行っているかを把握しやすくするため、書換ツール側の説明とファームウェア側の説明とを別パラグラフとする。そして、書換ツール側で「送信」と称する場合の送信先は常にファームウェアを意味し、ファームウェア側で「送信」と称する場合の送信先は常に書換ツールを意味する。

（書換ツール）Ｓ１にて書換開始通知を送信する。
（ファームウェア）Ｔ１で書換開始通知を受信し、識別ＩＤを「０」に設定して前述の無効化（兼書込み中設定）を行い、Ｔ３でアクノリッジ信号ＡＣＫを返す。
（書換ツール）Ｓ２でアクノリッジ信号ＡＣＫを受け、Ｓ３で送信対象となるデータブロックを送信し、また、識別ＩＤを「０」に維持するための書換中状態維持指令を送信する。
（ファームウェア）Ｔ４でデータブロックを受信し、Ｔ５でフラッシュＲＯＭ５にそのデータを書き込むとともに、識別ＩＤを「０」に保持し、Ｔ６でアクノリッジ信号ＡＣＫを返す。

（書換ツール）Ｓ４でアクノリッジ信号ＡＣＫを受け、Ｓ５で次のデータブロックがあるかを確認し、あればＳ３及びＳ４の処理を繰り返す。他方、Ｓ５で次のデータブロックがなければＳ６に進み、ベリファイ開始通知を送信する。
（ファームウェア）Ｔ７で次のデータブロックを受信すればＴ４〜Ｔ６の処理を繰り返す。他方、Ｔ７で次のデータブロックがなければＴ８に進み、ベリファイ開始通知を受信して、Ｔ９でアクノリッジ信号ＡＣＫを返す。
（書換ツール）Ｓ７でアクノリッジ信号ＡＣＫを受け、Ｓ８で送信対象となるベリファイデータ（送信済みのデータブロックに対応するものが順次送信されることとなる）を送信し、また、識別ＩＤを「０」に維持するための書換中状態維持指令を送信する。ベリファイデータは、送信済みのデータブロックに対応するものが以降のステップで順次送信されることとなる。
（ファームウェア）Ｔ１０でベリファイデータを受信し、Ｔ１１でフラッシュＲＯＭ５に書き込まれた対応するデータブロックとの間で比較するとともに、Ｔ１２でその結果を送信する（この送信は、ベリファイデータ受信に対するアクノリッジを兼ねている）。

（書換ツール）Ｓ９で上記比較結果を受け、結果が一致であればＳ１０で次のベリファイデータがあるかを確認し、あればＳ８及びＳ９の処理を繰り返す。他方、Ｓ１０で次のベリファイデータがなければＳ１１に進み、書換終了通知を送信する。一方、Ｓ９で不一致である場合はＳ１３に進み、エラーログを作成して終了する。
（ファームウェア）Ｔ１３で、データブロックとベリファイデータとが一致していればＴ１４に進み、識別ＩＤを「０」に保持するとともに、Ｔ１５で次のベリファイデータがあればＴ１０〜Ｔ１４の処理を繰り返す。また、Ｔ１３で不一致である場合はＴ１９に進み、エラーログを作成して終了する。他方、Ｔ１５で次のベリファイデータがなければＴ１６に進み、書換終了通知を受信する。そして、Ｔ１７で識別ＩＤを「１」に設定し、Ｔ１８でアクノリッジ信号ＡＣＫを返す。なお、Ｔ４，Ｔ１０で、書換ツール側から必要なデータを正常に受信できなかった場合も、一定回数のリトライの後Ｔ１９に進み、エラーログを作成して終了する。
（書換ツール）Ｓ１２でアクノリッジ信号ＡＣＫを受信すれば処理を終了する。なお、Ｓ２，Ｓ４，Ｓ７及びＳ１２でアクノリッジ信号ＡＣＫがない場合、一定回数のリトライの後Ｔ１３に進み、エラーログを作成して終了する。

以上のようにして更新バージョンプログラムによる書換処理が完了すれば、プラットフォーム５ｃによる起動制御プログラムルーチンにより、次回からのリセット後の起動処理は図６に示すようなものとなる。まず、Ｔ５１では起動すべきアプリケーション名を特定する。書換ツール１０による初回の書き換えトライ時には、書き換えＩＤの内容が正常終了を示す「１」になっているはずであり、該書き換えＩＤの内容判定から書換処理に移行するロジックが成立しないため、まずＴ５２で、書換ツール１０（データ送信元装置）からの書換用ファームウェア起動に対する割り込み要求があるかどうかを調べる。割り込み要求がなければＴ５３に進み、フラッシュＲＯＭ５内にてアプリケーションに対応する識別ＩＤをリードする。識別ＩＤが「１」（正常完了）になっていればＴ５７に進み、アプリケーションを起動する。他方、識別ＩＤが「０」（書換中）になっていれば、前回の書換処理が正常完了していないことを意味するから、Ｔ５５に進んで書換用ファームウェア５ａを起動し、Ｔ５６で書換ツール側に書換処理プログラム（図５の左側のフローで示されるもの）の起動を要請する。一方、ずＴ５２で割り込み要求があればＴ５３〜Ｔ５５をスキップし、Ｔ５６に進んで書換ツール側に書換処理プログラムの起動を要請する。

上記の処理態様をベースとして、本発明は以下に説明するごとく、様々な変形態様が可能である。まず、書換用ファームウェア５ａは、書換処理がベリファイの途中で中断した場合に、識別ＩＤ記憶部１０１ａの記憶内容を、ベリファイ中の中断であることが特定可能な形で書換中状態に設定するものとして構成することができる。これに対応して、プラットフォーム５ｃは、ベリファイ処理から書換処理が再開されるように書換用ファームウェア５ａを再起動するものとすることができる。図３に、この場合の識別ＩＤの設定例を示している。３以上の書換状態を識別するために、識別ＩＤを複数ビット、ここでは２ビットとし、「００」を未書き換え（無効化にも兼用）、「０１」を書き換え済未ベリファイ、「１０」を書換え正常完了（書き換え／ベリファイ双方完了）に対応させている。

図７は、この場合の書換処理の流れを示すものである。図５と共通するステップが多いので、同一の処理内容となるステップには同じステップ番号を付与して詳細な説明は省略する。また、処理内容が相違するステップは、図５との対応関係を明確にするために、図７側の、内容が相違するステップ番号に「’」を付与している。以下、この「’」を付与したステップを中心に説明を行なう。

まず、Ｓ３’、Ｔ２’、Ｔ５’及びＴ１７’は、本質的な処理は図５の対応するステップと何も代わらず、ただ、書換中を示す識別ＩＤ「０」が未書き換え「００」に、書き換え完了を示す識別ＩＤが「１」から「１０」に変わるだけである。一方、ベリファイに係るＳ８’及びＴ１４’では、図５の処理では識別ＩＤを、書換中を示す「０」に維持する処理を行なうだけであったが、ここでは新たに書き換え済み未ベリファイを示す「０１」を設定する。その結果、更新バージョンプログラムの書き込み中に処理が中断された場合は識別ＩＤが「０」となり、ベリファイ中に中断された場合は「０１」となるから、この両者を互いに区別することができる。

図８は、この場合のリセット後起動処理の流れを示すものであり、Ｔ５１でアプリケーション名を特定した後、Ｔ５２で書換ツール１０（データ送信元装置）からの書換用ファームウェア起動に対する割り込み要求がなければＴ５３で識別ＩＤをリードする。その内容が「００」であれば、図７において、書換ツール及び書換用ファームウェアの双方のプログラムを先頭（Ａ及びＡ’位置）から起動し、更新バージョンプログラムの書き込み処理から再度やり直す（Ｔ６１，Ｔ６２）。他方、識別ＩＤの内容が「０１」であれば、図７において、書換ツール及び書換用ファームウェアの双方のプログラムを、ベリファイ処理ステップ（Ｂ及びＢ’位置）から起動し、ベリファイ処理だけをやり直す（Ｔ６３，Ｔ６４）。また、識別ＩＤの内容が「１０」であれば、アプリケーション（更新バージョンプログラム）を起動する。なお、Ｔ５２で割り込み要求があった場合はＴ６１へ進む。

次に、書換用ファームウェア５ａは、フラッシュＲＯＭ５へのアプリケーション１８の書換処理が途中で中断した場合に、識別ＩＤ記憶部１０１ａの記憶内容を、当該書換処理（フラッシュＲＯＭ５への書き込み処理の他、書き込まれたデータのベリファイ処理も概念に含む）の中断位置を特定可能な形で書換中状態に設定するものとして構成することもできる。この場合、プラットフォーム５ｃは、識別ＩＤ記憶部１０１ａの記憶内容から中断位置を特定し、該中断位置から書換処理が再開されるように書換用ファームウェア５ａを再起動する。具体的には、図９に示すように、識別ＩＤ記憶部１０１ａは、更新バージョンプログラムの各ブロック１０２ｂに対応して複数設けることができ、書換用ファームウェア５ａは、複数の識別ＩＤ記憶部１０１ａの記憶状態を、書換処理の完了したものから順に書換え正常完了状態（「１０」）に設定するものとできる。プラットフォーム５ｃは、識別ＩＤ記憶部１０１ａの記憶状態が書換え正常完了状態（「１０」）に設定されていないブロック１０２ｂから書換処理が再開されるように書換用ファームウェア５ａを再起動するものとする。

図９では、フラッシュＲＯＭ５のアプリケーション１８の格納領域には、各ブロック１０２ｂの格納領域における所定のアドレスに、個々のブロック１０２ｂの書換状態を識別するためのブロック別識別ＩＤ記憶部１０２ａが個別に形成されている。また、ブロック別識別ＩＤ記憶部１０２ａとは別に、更新バージョンプログラム全体の書換状態を統括的に識別するための主識別ＩＤ記憶部１０１ａも形成されている（図９では、ヘッダ１０１内）。このうち、主識別ＩＤは、プログラム全体からみたとき、書換中「０」（無効化に兼用）であるか書換え正常完了「１」であるか、の２状態だけを識別できるように設定されている（従って、１ビットデータである）。他方、ブロック別識別ＩＤは、個々のブロックが未書き換え「００」（無効化にも兼用）、書き換え済未ベリファイ「０１」、書換え正常完了「１０」の３状態を識別できるように設定されている（従って、２ビットデータである）。

図１０は、この場合の書換処理の流れを示すものである。図７と共通するステップが多いので、同一の処理内容となるステップには同じステップ番号を付与して詳細な説明は省略する。また、処理内容が相違するステップは、図７との対応関係を明確にするために、図１０側の、内容が相違するステップ番号に「”」を付与している。以下、この「”」を付与したステップを中心に説明を行なう。

ファームウェア側のＴ２”では、書換開始通知を受けると、主識別ＩＤを「０」に、全てのブロック別識別ＩＤを「００」にリセットし、前歴を無効化する。Ｓ３”、Ｓ８”、Ｔ５”、Ｔ１４”は、本質的な処理は図７の対応するステップとほぼ同じであるが、ブロックとは無関係な単一の識別ＩＤ記憶部ではなく、現在の処理に係るブロックの識別ＩＤ記憶部において、書き換え前であれば「００」を、書き換え済未ベリファイであれば「０１」を設定するようにする。ブロックの書き込み／ベリファイが進行する毎に、順次、対応するブロックの識別ＩＤ記憶部に該設定が行なわれて行く。そして、全てのブロックのベリファイが完了すれば、Ｔ１７”で、主識別ＩＤを書換え正常完了「１」に設定する。

図１１は、この場合のリセット後起動処理の流れを示すものであり、Ｔ１０１でアプリケーション名を特定した後、Ｔ１０２で書換ツール１０（データ送信元装置）からの書換用ファームウェア起動に対する割り込み要求がなければＴ１０３で主識別ＩＤをリードする。Ｔ１０４で、主識別ＩＤの内容が「１０」であれば、アプリケーション（更新バージョンプログラム）を起動する。このように、ブロック別識別ＩＤとは別に主識別ＩＤを使用することで、多数のブロック別識別ＩＤの内容を参照せずとも、書き換えが正常に完了したかどうかを直ちに判定することができ、アプリケーションの起動処理へ速やかに移行できる。

一方、Ｔ１０４で、主識別ＩＤの内容が「０」であれば、Ｔ１０５以下の、ブロック別識別ＩＤの解析処理に移る。基本的には、書き込み（及びベリファイ）の順にブロックをたどりながら、ブロック別識別ＩＤの内容がどのブロックで変化するかにより、書き込みないしベリファイの中断位置（中断ブロック）を特定する処理になっている。まず、Ｔ１０５でブロック番号ｉを初期化し、Ｔ１０６では番号ｉのブロック別識別ＩＤを読み出し、Ｔ１０７で内容を判定する。書き込み及びベリファイが、予め定められたブロック配列にて順次行われるロジックを考慮すれば、Ｔ１０７において、ブロック別識別ＩＤの内容が書換え正常完了「１０」の場合、以降のブロックは、少なくともベリファイまでは正常に完了しているはずだから、Ｔ１０８でブロック番号ｉをインクリメントしてＴ１０６に戻り、以下の処理を繰り返す。また、Ｔ１０９でｉがｎ（最終ブロック）であった場合は、全ブロックが書換え正常完了であることを意味するから、Ｔ１１５に進んでアプリケーションを起動する。さらに、Ｔ１０７において、ブロック別識別ＩＤの内容が未書き換え「００」の場合、該ブロックから書き換えが再開されるよう、ファームウェア及び書換ツールを起動する（Ｔ１１８、Ｔ１１９）。

また、Ｔ１０６で読み込んだブロック別識別ＩＤの内容が書き換え済未ベリファイ「０１」の場合、書換え正常完了「１０」となっているブロックの存在は既に確認済みだから、そのブロックがもし先頭ブロックでないなら（Ｔ１１１でＹｅｓ）先のブロックは書換え正常完了であり、現在のブロックから先は全て書き換え済未ベリファイである。従って、Ｔ１１２及びＴ１１３に進み、当該ブロックからベリファイが再開されるよう、ファームウェア及び書換ツールを起動する。

他方、Ｔ１１１で書き換え済未ベリファイ「０１」となっている該ブロックが先頭ブロックであった場合はＴ１１４に進み、以降のどのブロックで未書き換え「００」に切り替わるかを調べ（Ｔ１１５）、最後のブロックｎまで書き換え済未ベリファイ「０１」であった場合は、最初のブロックからベリファイが再開されるよう、ファームウェア及び書換ツールを起動する（Ｔ１１６、Ｔ１１７→Ｔ１１２）。他方、Ｔ１１５で途中のブロックから未書き換え「００」になっていることが判明した場合はＴ１１８に進み、該ブロックから書き換えが再開されるよう、ファームウェア及び書換ツールを起動する（Ｔ１１８、Ｔ１１９）。

なお、図１２に示すように、ブロック別識別ＩＤ記憶部を、各ブロックの格納領域から切り離して別テーブルの形で形成してもよい。図１２では、ヘッダ部１０１の中に主識別ＩＤとともに、全てのブロック別識別ＩＤ記憶部を集合形成している。また、ブロック別に識別ＩＤを設けず、図１３に示すように、現在処理中のブロックを特定する情報と、その処理状態を示す情報とを組み合わせて書換状態識別情報を形成してもよい。図１３の例では、次のブロックの処理に進む毎にインクリメントされるブロックカウンタＮと、状態ＩＤとを組み合わせている。識別ＩＤは、ブロックカウンタＮが示すブロックの状態を示すものであり、未書き換え「００」（無効化にも兼用）、書き換え済未ベリファイ「０１」、書換え正常完了「１０」の３状態を識別できるように設定されている。

図１４は、この場合の書換処理の流れを示すものである。図１０と共通するステップには同じステップ番号を付与して詳細な説明は省略する。また、処理内容が相違するステップは、図１０との対応関係を明確にするために、図１４側の、内容が相違するステップ番号に「”’」を付与している。以下、この「”’」を付与したステップを中心に説明を行なう。

ファームウェア側のＴ２”’では、書換開始通知を受けると、主識別ＩＤを「０」に、ブロックカウンタＮを「１」に、状態ＩＤを「００」にそれぞれ設定し、前歴を無効化する。Ｓ３”’、Ｓ８””、Ｔ５”’、Ｔ１４”’は、本質的な処理は図１０の対応するステップとほぼ同じであるが、ブロックとは無関係な単一の識別ＩＤが用いられ、先のブロックの処理に移るに従い、ブロックカウンタＮが示すブロックの状態値を更新しつつ書き込んでゆく。ここでの処理では、あるブロックの書き込みが終了したら、引き続いてそのブロックのベリファイ処理も行なうようにしている。つまり、ブロックカウンタＮの値を固定した状態で、書き込み→ベリファイと進むに従い、識別ＩＤの値を「０１」→「１０」と書き換える。そして、Ｔ２０で、次のブロックの処理に移る際にはブロックカウンタＮをインクリメントし、識別ＩＤの値を再度無効化する（「００」）。そして、最後のブロックのベリファイが終わればＴ１７”’に進み、主識別ＩＤを「１」に設定する。

この場合のリセット後起動処理では、主識別ＩＤがもし「０」（書換中）であった場合、ブロックカウンタＮと識別ＩＤの値を読み出すことで、どのブロックでどの状態まで処理が進んでいたかを直ちに把握できる。例えば図１３ではＮが（１０進法で）５４であり、状態ＩＤが「０１」であるから、第５４ブロックの書き換えまでで処理が中断したことを示している。従って、その後続処理、すなわち、第５４ブロックのベリファイから処理を再開すればよい。

本発明の自動車用制御ユニットとして構成されたＥＣＵの第一例を示すブロック図。 フラッシュＲＯＭのアプリケーション格納領域の構造説明図。 識別ＩＤの別設定例を示す説明図。 本発明による書換処理の概念図。 本発明による書換処理の詳細に係る第一例を示すフローチャート。 図５の書換処理に対応する起動制御処理の流れを示すフローチャート。 本発明による書換処理の詳細に係る第二例を示すフローチャート。 図７の書換処理に対応する起動制御処理の流れを示すフローチャート。 アプリケーション格納領域において、各ブロックの格納領域にブロック別識別ＩＤ記憶部を形成する例を示す説明図。 本発明による書換処理の詳細に係る第三例を示すフローチャート。 図１０の書換処理に対応する起動制御処理の流れを示すフローチャート。 アプリケーション格納領域において、各ブロックのブロック別識別ＩＤ記憶部を、ブロック格納領域の外にまとめて形成する例を示す説明図。 ブロックカウンタと識別ＩＤとを組み合わせた書き換え識別情報の例を示す図。 本発明による書換処理の詳細に係る第四例を示すフローチャート。 従来のＥＣＵにおけるプログラム書換処理を示すフローチャート。

符号の説明

１ ＥＣＵ（自動車用制御ユニット）
３ ＣＰＵ
４ ＲＡＭ
５ フラッシュＲＯＭ（不揮発性メモリ、書換用ファームウェア記憶部）
５ａ 書換用ファームウェア（識別情報書換手段）
５ｃ プラットフォーム（起動制御手段）
１０ 書換ツール（データ送信元装置）
１０１ａ 書換状態識別ＩＤ記憶部（書換状態識別情報記憶部）

Claims (11)

1. 自動車上に搭載される電子機器の制御処理を司る機能制御用ソフトウェアを格納するとともに、記憶内容が電気的に書換え可能であって、外部からのリセット信号を受けても前記記憶内容を保持する不揮発性メモリと、
   該機能制御用ソフトウェアの実行メモリとなるＲＡＭと、前記機能制御用ソフトウェアの実行に基づいて前記電子機器の制御処理を行なうＣＰＵと、
   前記不揮発性メモリに格納された前記機能制御用ソフトウェアの内容を書き換えるための書換用ファームウェアが格納された書換用ファームウェア記憶部と、
   前記書換用ファームウェアによる前記機能制御用ソフトウェアの書換処理が正常に完了したかどうかを識別するための書換状態識別情報を書換え可能に記憶する書換状態識別情報記憶部と、
   前記書換用ファームウェアによる前記書換処理の進行状態を管理し、該進行状態に応じて前記書換状態識別情報記憶部における前記書換状態識別情報の記憶内容を、前記書換処理が正常に完了したか否かが把握可能となるように書き換える識別情報書換手段と、
   前記機能制御用ソフトウェアを起動する際に前記書換状態識別情報記憶部の記憶内容を参照し、前記記憶内容が、前記書換処理が正常に完了したことを示す内容になっている場合は前記機能制御用ソフトウェアを起動し、前記書換処理が不完全であることを示す内容になっている場合は前記機能制御用ソフトウェアに代えて前記書換用ファームウェアを再起動する処理を、前記機能制御用ソフトウェアとは独立に実行する起動制御手段と、
   を有してなることを特徴とする自動車用制御ユニット。
2. 前記識別情報書換手段は、前記書換用ファームウェアの起動時に前記書換状態識別情報記憶部の該ファームウェア起動前の記憶状態を無効化し、その後、前記書換用ファームウェアが前記不揮発性メモリにおける前記機能制御用ソフトウェアの書換処理を正常に完了するに伴い、前記書換状態識別情報記憶部の記憶状態を、書換え正常完了を示す予め定められた書換え正常完了状態に設定するものであり、
   前記起動制御手段は、前記書換状態識別情報記憶部の記憶内容が前記書換え正常完了状態になっている場合にのみ前記機能制御用ソフトウェアを起動する請求項１記載の自動車用制御ユニット。
3. 前記識別情報書換手段は、前記書換用ファームウェアによる前記機能制御用ソフトウェアの書換処理の開始に対応して、前記書換状態識別情報記憶部の記憶内容を、書換中を示す予め定められた書換中状態に設定するとともに、当該書換中状態を前記機能制御用ソフトウェアの書換処理が正常完了するまで維持するものであり、
   前記起動制御手段は、前記書換状態識別情報記憶部の記憶内容が前記書換中状態になっている場合に前記書換用ファームウェアを起動する請求項２記載の自動車用制御ユニット。
4. 前記書換用ファームウェアは、前記書き換えに使用する前記機能制御用ソフトウェアの更新バージョンプログラムを、前記自動車用制御ユニットにネットワーク接続されたデータ送信元装置から通信取得して前記書き換えを行なうものであり、
   前記識別情報書換手段は、前記データ送信元装置から受信する書換中状態維持指令を受けることにより、前記書換状態識別情報記憶部の記憶内容を前記書換中状態に維持するものである請求項３記載の自動車用制御ユニット。
5. 前記識別情報書換手段は、前記機能制御用ソフトウェアの書換処理の開始から正常完了に至るまでの間に、前記データ送信元装置から前記書換中状態維持指令を定期的に受信するものであり、該書換中状態維持指令の受信継続に対応して書換状態識別情報記憶部の記憶内容を前記書換中状態に維持するものである請求項４記載の自動車用制御ユニット。
6. 前記書換用ファームウェアは、前記データ送信元装置から前記更新バージョンプログラムを複数ブロックに分割された形で順次受信するものであり、
   前記識別情報書換手段は、前記データ送信元装置から前記ブロック毎に前記書換中状態維持指令を受けるものである請求項５記載の自動車用制御ユニット。
7. 前記識別情報書換手段は、前記書換用ファームウェアが前記データ送信元装置から受信した前記更新バージョンプログラムを不揮発性メモリに全て書き込み、さらに、前記データ送信元装置から受信したベリファイ用データに基づいて書き込まれた前記更新バージョンプログラムのベリファイを完了した場合に、前記書換状態識別情報記憶部の記憶状態を前記書換え正常完了状態に設定する請求項４ないし請求項６のいずれか１項に記載の自動車用制御ユニット。
8. 前記識別情報書換手段は、前記書換用ファームウェアによる前記書換処理が前記ベリファイの途中で中断した場合に、前記書換状態識別情報記憶部の記憶内容を、前記ベリファイ中の中断であることが特定可能な形で前記書換中状態に設定するものであり、
   前記起動制御手段は、前記ベリファイ処理から前記書換処理が再開されるように前記書換用ファームウェアを再起動する請求項７記載の自動車用制御ユニット。
9. 前記識別情報書換手段は、前記書換用ファームウェアが前記不揮発性メモリへの前記機能制御用ソフトウェアの書換処理が途中で中断した場合に、前記書換状態識別情報記憶部の記憶内容を、当該書換処理の中断位置を特定可能な形で前記書換中状態に設定するものであり、
   前記起動制御手段は、前記書換状態識別情報記憶部の記憶内容から前記中断位置を特定し、前記中断位置から前記書換処理が再開されるように前記書換用ファームウェアを再起動する請求項２ないし請求項８のいずれか１項に記載の自動車用制御ユニット。
10. 前記書換用ファームウェアは、前記データ送信元装置から前記更新バージョンプログラムを複数のブロックに分割された形で順次受信するものであり、
    前記識別情報書換手段は、前記書換用ファームウェアが前記不揮発性メモリへの前記機能制御用ソフトウェアの書換処理が途中で中断した場合に、前記書換状態識別情報記憶部の記憶内容を、当該書換処理がどのブロックで中断されたかを特定可能な形で前記書換中状態に設定するものであり、
    前記起動制御手段は、前記書換状態識別情報記憶部の記憶内容から処理中断されたブロックを特定し、該ブロックから前記書換処理が再開されるように前記書換用ファームウェアを再起動する請求項９記載の自動車用制御ユニット。
11. 前記書換状態識別情報記憶部は、前記更新バージョンプログラムの前記各ブロックに対応して複数設けられ、前記識別情報書換手段は、前記複数の書換状態識別情報記憶部の記憶状態を、前記書換処理の完了したものから順に前記書換え正常完了状態に設定するものであり、
    前記起動制御手段は、前記書換状態識別情報記憶部の記憶状態が前記書換え正常完了状態に設定されていないブロックから前記書換処理が再開されるように前記書換用ファームウェアを再起動する請求項１０記載の自動車用制御ユニット。

Images