JP2017004212A

JP2017004212A - リプログラミングシステム

Info

Publication number: JP2017004212A
Application number: JP2015116707A
Authority: JP
Inventors: 裕介増田; Yusuke Masuda
Original assignee: Hitachi Automotive Systems Ltd
Current assignee: Hitachi Astemo Ltd
Priority date: 2015-06-09
Filing date: 2015-06-09
Publication date: 2017-01-05
Anticipated expiration: 2035-06-09
Also published as: JP6464038B2

Abstract

【課題】制御ソフトウェアを更新することにともなってバックアップデータ記憶領域上におけるバックアップデータの構成が変化した場合であっても、バックアップデータの同一性を維持して引き継ぐ技術を提供する。【解決手段】本発明に係るリプログラミングシステムは、バックアップデータ内の変数毎に更新前後の格納先アドレスに関する差分を特定し、その特定した差分毎に前記変数の格納先アドレスを更新する。【選択図】図１

Description

本発明は、車両の動作を制御する処理を記述した制御ソフトウェアを更新する技術に関する。

車両の動作を制御する車両制御装置は、電気的に記憶内容を書き換えることができるフラッシュメモリやＥＥＰＲＯＭ（ＥｌｅｃｔｒｉｃａｌｌｙＥｒａｓａｂｌｅＰｒｏｇｒａｍｍａｂｌｅＲｅａｄＯｎｌｙＭｅｍｏｒｙ）などのような不揮発性メモリを備え、同メモリ内に制御ソフトウェアを格納している。制御ソフトウェアは、エンジンや変速機などの車両が備える機器を制御する処理を実装している。下記特許文献１は、外部装置からの要求に応じて、制御ソフトウェアを書き換える技術について記載している。

車両制御装置は、制御ソフトウェアを実行することによって更新されるデータのうち、車両制御装置に対する電源供給が停止されても継続して保存すべきデータを、ＥＥＰＲＯＭなどの書き換え可能な不揮発性メモリ内に永続化して記憶する。例えば学習値や故障診断結果などのデータがこれに該当する。以下、このようなデータのことをバックアップデータと呼ぶ。

制御ソフトウェアを更新するとき、更新の前後においてバックアップデータの値を同一に維持するため、バックアップデータを格納する不揮発性メモリ上のアドレスは、一般に特定のアドレスに固定されている。例えば不揮発性メモリ上のあるアドレス範囲内はバックアップデータを格納する記憶領域として固定され、当該記憶領域にはその他データを格納しないようにしている。以下ではこの記憶領域のことをバックアップデータ記憶領域と呼ぶ。

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

制御ソフトウェアの更新にともない、機能が追加、変更、削除され、それにともないバックアップデータも追加、変更、削除される。制御ソフトウェアの更新後においても既存のバックアップデータ内の変数値を引き継ぐ場合（例えばこれまでの学習結果を記録した変数値を引き継ぐ場合など）、更新前の永続化データ内における変数が更新後においても同じ変数を参照するように配慮する必要がある。

バックアップデータの単純追加であれば、バックアップデータ記憶領域における既存バックアップデータの配置を変更せず、追加分のバックアップデータを未使用領域へ配置することにより、既存バックアップデータの変数値をそのまま引き継ぐことができる。これに対しバックアップデータを変更または削除した場合は、特定のアドレスに格納された変数が、変更前後において互いに異なる変数を指し示す可能性がある。このようなバックアップデータを更新後の制御ソフトウェアにおいて用いると、制御ソフトウェアが意図しない動作を発生させる可能性がある。

上記のような状況を回避するための手段として、制御ソフトウェアの更新前後においてバックアップデータの構成に差異がある場合、バックアップデータ記憶領域を初期化することが考えられる。しかし、バックアップデータは個々の車両制御装置固有の情報を蓄積しているので、可能な限り初期化せず更新前の値を引き継ぐことが望ましい。

本発明は、上記のような課題に鑑みてなされたものであり、制御ソフトウェアを更新することにともなってバックアップデータ記憶領域上におけるバックアップデータの構成が変化した場合であっても、バックアップデータの同一性を維持して引き継ぐ技術を提供することを目的とする。

本発明に係るリプログラミングシステムは、バックアップデータ内の変数毎に更新前後の格納先アドレスに関する差分を特定し、その特定した差分毎に前記変数の格納先アドレスを更新する。

本発明に係るリプログラミングシステムによれば、制御ソフトウェアの更新前後においてバックアップデータの構成が異なる場合であっても、更新前のバックアップデータを効率的に引き継ぐことができる。

リプログラミングシステム１００の構成図である。構成テーブル１４１のテーブル構成とデータ例を示す図である。従来のリプログラミングシステムが制御ソフトウェアを更新する処理を説明するフローチャートである。ＥＣＵ１１０が保持している制御ソフトウェア１５１をリプログラミングシステム１００が更新する処理を説明するフローチャートである。ステップＳ４０４の詳細を説明するフローチャートである。パラメータテーブル１４２のテーブル構成とデータ例を示す図である。ステップＳ５０６の詳細を説明するフローチャートである。

＜リプログラミングシステムの構成＞
図１は、本発明に係るリプログラミングシステム１００の構成図である。リプログラミングシステム１００は、車両制御装置（ＥｌｅｃｔｒｏｎｉｃＣｏｎｔｒｏｌＵｎｉｔ：ＥＣＵ）１１０が実行する制御ソフトウェアを更新するためのシステムであり、リプログラミング装置１３０、バックアップデータデータベース１４０、制御ソフトウェアデータベース１５０を備える。

ＥＣＵ１１０は、車両の動作を制御する処理を実装した制御ソフトウェアを実行することにより当該車両の動作を制御する装置である。ＥＣＵ１１０は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）１１１、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）１１２、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）１１３、ＥＥＰＲＯＭ１１４、通信回路１１５を備える。

ＣＰＵ１１１は、ＲＯＭ１１２が格納している制御ソフトウェアを実行する演算装置である。以下では記載の便宜上、ＣＰＵ１１１が実行するソフトウェアを動作主体として説明する場合があるが、実際にそれらソフトウェアを実行するのはＣＰＵ１１１である。ＲＡＭ１１３は、ＣＰＵ１１１が使用するデータを一時的に保存するメモリデバイスである。ＥＥＰＲＯＭ１１４は、バックアップデータを格納するバックアップデータ記憶領域を有し、同領域内にバックアップデータを格納している。通信回路１１５は、通信線１６０を介して他のＥＣＵ１１０と通信する。

ＣＰＵ１１１は、必要に応じて他のＥＣＵ１１０と通信してデータを取得し、制御ソフトウェアを実行することにより車両の動作を制御する。ＣＰＵ１１１は、制御ソフトウェアを実行する際に、ＥＥＰＲＯＭ１１４が格納しているバックアップデータをＲＡＭ１１３上へ読み出し、これを更新する。制御ソフトウェアを終了するとき（あるいはＥＣＵ１１０をシャットダウンするときなど適当なタイミング）、ＣＰＵ１１１はＲＡＭ１１３上のバックアップデータをＥＥＰＲＯＭ１１４へ書き戻す。ＥＥＰＲＯＭ１１４はＥＣＵ１１０に対する電源供給が遮断されてもデータを保持するので、バックアップデータは永続的に保存される。

リプログラミング装置１３０は、コネクタ１２０を介して当該車両に接続され、ＲＯＭ１１２が格納している制御ソフトウェアを更新するようＣＰＵ１１１に対して指示する。ＲＯＭ１１２は、制御ソフトウェアを更新する処理を記述した書き換えソフトウェアをさらに格納しており、ＣＰＵ１１１はリプログラミング装置１３０から更新指示および制御ソフトウェアの新版を受け取ると、書き換えソフトウェアを実行することによりＲＯＭ１１２上の制御ソフトウェアを更新する。

リプログラミング装置１３０は、制御ソフトウェアを更新する際に、ＥＥＰＲＯＭ１１４内のバックアップデータを、必要に応じて、更新後の制御ソフトウェアの仕様にしたがい更新する。

バックアップデータデータベース１４０は、ＥＥＰＲＯＭ１１４上におけるバックアップデータの配置と各バックアップデータの詳細に関する情報を保持するデータベースであり、構成テーブル１４１とパラメータテーブル１４２を格納している。

構成テーブル１４１は、バックアップデータのＥＥＰＲＯＭ１１４上における格納先アドレスを記述した構成データを、後述する構成ＩＤ毎に保持するデータテーブルである。構成テーブル１４１の詳細については後述の図２で改めて説明する。

パラメータテーブル１４２は、バックアップデータ内に含まれる各変数の属性パラメータを記述したパラメータデータを、後述する各変数のリビジョンごとに保持するデータテーブルである。パラメータテーブルの詳細については後述の図６で改めて説明する。

制御ソフトウェアデータベース１５０は、ＲＯＭ１１２へ書き込む制御ソフトウェア１５１を格納したデータベースである。制御ソフトウェア１５１は、バックアップデータのバージョン番号に相当する構成ＩＤ１５２を内部的に保持している。ＣＰＵ１１１は、制御ソフトウェア１５１をＲＯＭ１１２に対して書き込む際に、例えば構成ＩＤ１５２を特定のアドレス上に配置する。当該アドレスを読み出すことにより、ＥＣＵ１１０が保持している制御ソフトウェア１５１の現行の構成ＩＤ１５２を取得することができる。

図２は、構成テーブル１４１のテーブル構成とデータ例を示す図である。構成テーブル１４１は、バックアップデータ内の各変数のリビジョン（バージョン番号）毎に、ＥＥＰＲＯＭ１１４上における格納先アドレスを記述している。構成ＩＤ１５２が異なればバックアップデータ内に含まれる変数も異なる場合があるので、構成テーブル１４１は構成ＩＤ１５２毎（すなわち後述の構成ＩＤフィールド１４１１毎）に設けることができる。

構成テーブル１４１は、構成ＩＤフィールド１４１１、アドレスフィールド１４１２、変数ＩＤフィールド１４１３、変数リビジョンフィールド１４１４を有する。

構成ＩＤフィールド１４１１は、制御ソフトウェアデータベース１５０が格納している各制御ソフトウェア１５１の構成ＩＤ１５２を保持する。アドレスフィールド１４１２は、構成ＩＤフィールド１４１１によって特定されるバックアップデータ内に含まれる各変数がＥＥＰＲＯＭ１１４上において格納されるアドレスを保持する。変数ＩＤフィールド１４１３は、各変数を識別するＩＤである。変数リビジョンフィールド１４１４は、各変数のリビジョンを保持する。

＜従来技術における制御ソフトウェアの更新動作＞
図３は、従来のリプログラミングシステムが制御ソフトウェアを更新する処理を説明するフローチャートである。以下図３の各ステップについて説明する。

（図３：ステップＳ３０１）
書き換えソフトウェアは、リプログラミング装置１３０からの指示に従い、ＲＯＭ１１２に対して制御ソフトウェアを書き込む。

（図３：ステップＳ３０２）
リプログラミング装置１３０の使用者は、制御ソフトウェア１５１の更新前後それぞれに対応するバックアップデータが互換性を有するか否かを判断する。互換性が無いと判断した場合はステップＳ３０３へ進み、互換性があると判断した場合は本フローチャートを終了する。

（図３：ステップＳ３０３）
リプログラミング装置１３０の使用者は、バックアップデータを初期化する。ここでいう初期化とは、既存のバックアップデータが蓄積している変数値などを消去することを指す。すなわち、互換性の無いバックアップデータを制御ソフトウェアが参照することがないように、バックアップデータはすべて初期化される。

ステップＳ３０２におけるバックアップデータの互換性の判断は、リプログラミング装置１３０の使用者によってマニュアル操作により実施される。したがって、本来バックアップデータを初期化すべきところ、これが実施されず、制御ソフトウェアが意図しない動作を起こす可能性がある。

また従来のリプログラミングシステムは、バックアップデータの構成要素（バックアップデータ内に含まれる各変数など）のうちどの部分が互換性を有しているかを判断していない。したがって、更新前後に係るバックアップデータのうち一部のみが互換性を有していない場合であっても、その全体を初期化する必要がある。したがって、それまでの動作過程において蓄積した当該車両制御装置固有のバックアップデータは、制御ソフトウェアの更新によって初期化され、引き継がれない。

そこで本発明は、バックアップデータの互換性を判断するとともに、互換性を有していない部分については更新後のバックアップデータの仕様に応じて変換を施すことにより、更新前のバックアップデータの変数値を引き継ぐ技術を提供する。

＜本発明における制御ソフトウェアの更新動作＞
図４は、ＥＣＵ１１０が保持している制御ソフトウェア１５１をリプログラミングシステム１００が更新する処理を説明するフローチャートである。以下図４の各ステップについて説明する。

（図４：ステップＳ４０１）
リプログラミング装置１３０は、ＥＣＵ１１０が保持している制御ソフトウェア１５１の構成ＩＤ１５２を取得するとともに、更新版の制御ソフトウェア１５１（これからＥＥＰＲＯＭ１１４に対して書き込もうとしている制御ソフトウェア１５１）の構成ＩＤ１５２を取得する。

（図４：ステップＳ４０２）
リプログラミング装置１３０は、ステップＳ４０１において取得した新旧それぞれの構成ＩＤ１５２を比較する。両構成ＩＤ１５２が同一である場合はステップＳ４０６へスキップし、同一でない場合はステップＳ４０３へ進む。

（図４：ステップＳ４０２：補足）
構成ＩＤ１５２が同一である場合、更新後の制御ソフトウェア１５１に対応するバックアップデータの構成は変更されないとみなすことができるので、現行のバックアップデータを更新後の制御ソフトウェア１５１がそのまま引き継ぐことができる。ここでいうバックアップデータの引き継ぎとは、更新前の制御ソフトウェア１５１が参照していた各変数およびその格納先アドレスを、更新後の制御ソフトウェア１５１がそのまま用いることを指す。

（図４：ステップＳ４０３）
リプログラミング装置１３０は、更新前後それぞれの制御ソフトウェア１５１に対応する構成ＩＤ１５２が登録されているか否かを、バックアップデータデータベース１４０に対して問い合わせる。いずれも登録されている場合はステップＳ４０４へ進み、少なくともいずれかが登録されていない場合はステップＳ４０５へ進む。

（図４：ステップＳ４０４）
リプログラミング装置１３０は、後述の図５で説明するフローチャートにしたがって、現行のバックアップデータの構成を、更新後の制御ソフトウェア１５１の仕様に応じて変換する。

（図４：ステップＳ４０５）
更新前後いずれかの構成ＩＤ１５２がバックアップデータデータベース１４０内に登録されていない場合、その構成ＩＤ１５２に対応するバックアップデータはリプログラミングシステム１００が想定していない未知のものであると考えられる。したがってリプログラミング装置１３０は、ＥＥＰＲＯＭ１１４が格納している現行のバックアップデータを初期化し、更新後の構成ＩＤ１５２に対応するバックアップデータを用いる。

（図４：ステップＳ４０３〜Ｓ４０５：補足その１）
本ステップにおいて、新旧それぞれの構成ＩＤ１５２を比較することにより、バックアップデータの構成が変更されるか否かを確実に判別することができる。また、バックアップデータを初期化するのは、バックアップデータデータベース１４０が保持していない未知の構成ＩＤ１５２が指定された場合のみに限られるので、できる限り既存のバックアップデータの変数値を引き継ぐことができる。

（図４：ステップＳ４０３〜Ｓ４０５：補足その２）
バックアップデータの構成が変更されるか否かを判別するために、制御ソフトウェア１５１のバージョンを一意に識別するバージョン番号などを用いることも考えられる。しかし、制御ソフトウェア１５１が更新された場合であってもバックアップデータの構成が必ずしも変更されるとは限らない。したがって、バックアップデータそのものの構成を識別する構成ＩＤ１５２を用いる方が、より効果的であると考えられる。

（図４：ステップＳ４０６）
リプログラミング装置１３０は、更新版の制御ソフトウェア１５１をＲＯＭ１１２に対して書き込む。

図５は、ステップＳ４０４の詳細を説明するフローチャートである。以下図５の各ステップについて説明する。

（図５：ステップＳ５０１）
リプログラミング装置１３０は、制御ソフトウェア１５１の更新前後それぞれに対応する構成ＩＤ１５２をキーにして、構成テーブル１４０の対応するレコードを読み出す。

（図５：ステップＳ５０２）
リプログラミング装置１３０は、ステップＳ５０１において読み出した各レコードについて、変数ＩＤフィールド１４１３の構成および各変数ＩＤフィールド１４１３に対応する変数リビジョンフィールド１４１４が同一であるか否かを判定する。すなわち、バックアップデータ内に含まれる変数およびそのリビジョンが、制御ソフトウェア１５１の更新にともなって変更されるか否かを判定する。変数ＩＤフィールド１４１３および対応する変数リビジョンフィールド１４１４がいずれも同一である場合はステップＳ５０３へ進み、いずれかが異なる場合はステップＳ５０５へ進む。

（図５：ステップＳ５０３〜Ｓ５０４）
リプログラミング装置１３０は、ステップＳ５０１において読み出した各レコードについて、アドレスフィールド１４１２が同一であるか否かを判定する。制御ソフトウェア１５１の更新前後に対応するアドレスフィールド１４１２が互いに異なる場合、リプログラミング装置１３０は現行のバックアップデータの各変数の格納先アドレスを、更新後の制御ソフトウェア１５１に対応するアドレスフィールド１４１２が指定するアドレスに変更する。アドレスフィールド１４１２が同一である場合は現行のバックアップデータをそのまま引き継ぐことができるので、本フローチャートを終了する。

（図５：ステップＳ５０３〜Ｓ５０４：補足その１）
変数ＩＤフィールド１４１３と変数リビジョンフィールド１４１４が同一であり、アドレスフィールド１４１２のみが異なる場合、その変数の内容は同一であるが、格納先アドレスのみが移動されていることになる。したがって本ステップにおいて、格納先アドレスのみを更新することとした。これにより、バックアップデータ内の変数のアドレスが変更された場合であっても、更新前の変数値を引き継ぐことができる。

（図５：ステップＳ５０３〜Ｓ５０４：補足その２）
リプログラミング装置１３０は、現行のバックアップデータのアドレスを変換する際には、例えば更新前の変数が格納されているアドレスから現行の変数値を読み取り、その値を更新後の変数の格納先アドレスに対して再格納する。

（図５：ステップＳ５０５）
リプログラミング装置１３０は、ステップＳ５０１において読み出した各レコードについて、変数ＩＤフィールド１４１３の構成が同一であるか否かを判定する。すなわち、変数ＩＤフィールド１４１３の構成が同一であって変数リビジョンフィールド１４１４のみが異なるのか否かを判定する。変数ＩＤフィールド１４１３の構成が同一である場合はステップＳ５０６へ進み、同一でない場合はステップＳ５０７へ進む。

（図５：ステップＳ５０６）
リプログラミング装置１３０は、後述の図７で説明するフローチャートにしたがって、現行のバックアップデータ内に含まれる変数を、更新後の制御ソフトウェア１５１の仕様に応じて変換する。

（図５：ステップＳ５０７）
更新前後それぞれの変数ＩＤフィールド１４１３と変数リビジョンフィールド１４１４がいずれも一致しない場合、当該変数は新たに設けられたものであり、現行の変数値を引き継ぐことはできないと考えられる。したがってリプログラミング装置１３０は、当該変数値として後述の図６で説明する初期値をセットし、ＥＥＰＲＯＭ１１４に格納する。

（図５：ステップＳ５０２〜Ｓ５０７：補足その１）
更新前後少なくともいずれかのバックアップデータが２以上の変数を含む場合（すなわち、当該バックアップデータの構成ＩＤ１５２に対応する構成テーブル１４１（図２）の構成データ内に２以上の行が含まれる場合）、ステップＳ５０２〜Ｓ５０７をその変数の個数に応じて実施する必要がある。例えばステップＳ５０２については、更新後バックアップデータ内の１つ目の変数ＩＤフィールド１４１３／変数リビジョンフィールド１４１４と合致するものが存在するか否かを、更新前バックアップデータ内の全変数を対象として検索する必要がある。合致するものがある場合は、その合致した変数についてステップＳ５０３を実施する。変数ＩＤフィールド１４１３のみが合致する変数が更新前バックアップデータ内に存在する場合は、ステップＳ５０６を実施する。

（図５：ステップＳ５０２〜Ｓ５０７：補足その２）
以上のステップにおいて、変数ＩＤフィールド１４１３と変数リビジョンフィールド１４１４が合致するか否かを判定することにより、更新前後に係る変数間の差分を特定し、その差分のみを更新後バックアップデータの仕様に準じて変換することができる。この変換処理は、後述の図６〜図７で説明するように、現行の変数値そのものを引き継ぎつつ、制御ソフトウェア上における取り扱いのみを変更するものであるので、現行の変数値を初期化することなく引き継ぐことができる。

（図５：ステップＳ５０２〜Ｓ５０７：補足その３）
以上のステップにおいて、変数ＩＤフィールド１４１３と変数リビジョンフィールド１４１４がいずれも合致しない変数については、新たに設けられた変数であるとみなして初期値をセットする。これにより、パラメータの設定漏れなどに起因する不具合を抑制することができる。

図６は、パラメータテーブル１４２のテーブル構成とデータ例を示す図である。パラメータテーブル１４２は、バックアップデータ内の各変数のリビジョン毎に、当該変数の属性パラメータを記述している。パラメータテーブル１４２は、構成テーブル１４１と同様に構成ＩＤ毎に設けることもできる。

パラメータテーブル１４２は、ＩＤフィールド１４２１、リビジョンフィールド１４２２、名称フィールド１４２３、データ型フィールド１４２４、ビットレートフィールド１４２５、オフセットフィールド１４２６、初期値フィールド１４２７を有する。

ＩＤフィールド１４２１は、変数ＩＤフィールド１４１３に対応し、バックアップデータ内の各変数を一意に識別するＩＤを保持する。リビジョンフィールド１４２２は、変数リビジョンフィールド１４１４に対応し、当該変数のリビジョンを保持する。名称フィールド１４２３は、制御ソフトウェア１５１内における当該変数の変数名を保持する。データ型フィールド１４２４は、制御ソフトウェア１５１内における当該変数のデータ型を保持する。ビットレートフィールド１４２５とオフセットフィールド１４２６は、制御ソフトウェア１５１内において当該変数値を制御演算上における物理値に変換する際に用いる乗数およびオフセット値である。詳細は図７で改めて説明する。初期値フィールド１４２７は、ステップＳ５０７においてセットされる初期値である。

ＩＤフィールド１４２１（変数ＩＤフィールド１４１３）は、バックアップデータ内の各変数の意味を一意に識別するＩＤである。したがって例えば、ＩＤフィールド１４２１＝１２が当該車両の走行距離を格納する変数であれば、データ型やビットレートなどその他属性が変化したとしても、当該変数が走行距離を格納することは変わらない。同一のＩＤフィールド１４２１のデータ型やビットレートなどその他属性を変更する場合は、リビジョンフィールド１４２２を変更して新たな属性をセットすればよい。

図７は、ステップＳ５０６の詳細を説明するフローチャートである。以下図７の各ステップについて説明する。

（図７：ステップＳ７０１）
リプログラミング装置１３０は、更新前後それぞれの変数およびそのリビジョンをキーにして、パラメータテーブル１４２の対応するレコードを取得する。

（図７：ステップＳ７０２）
リプログラミング装置１３０は、更新前の変数値に対して更新前のビットレートフィールド１４２５を乗算し、さらにその結果に対して更新前のオフセットフィールド１４２６を加算する。これにより、更新前の変数値が制御演算上における物理値へ変換される。

（図７：ステップＳ７０３）
リプログラミング装置１３０は、ステップＳ７０２の結果から更新後のオフセットフィールド１４２６を減算し、さらにその結果を更新後のビットレートフィールド１４２５によって除算する。これにより、更新前の物理値が更新後の変数値へ変換される。

（図７：ステップＳ７０４）
リプログラミング装置１３０は、更新前の変数値のデータ型を更新後のデータ型へ変換する。このとき、変数値が更新後のデータ型の上下限値の範囲内に収まるように、変数値を丸めるなどの必要な処理を適宜実施する。

（図７：ステップＳ７０１〜Ｓ７０４：補足）
以上のステップによれば、バックアップデータの属性パラメータ（変数名、ビットレート、オフセット、初期値など）が制御ソフトウェア１５１の更新によって変更されたとしても、構成ＩＤフィールド１４１１、変数ＩＤフィールド１４１３、変数リビジョンフィールド１４１４によって各変数の意味を一意に識別することができる。これにより、更新前後に係る変数属性の差分を更新後のバックアップデータの仕様に応じて変換し、更新前の変数値を引き継ぐことができる。したがって、学習値や故障診断結果などの車両制御装置固有のデータを引き継ぎ、サービス性を向上させることができる。

＜本発明の変形例について＞
本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換える事が可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について他の構成の追加・削除・置換をすることができる。

以上の実施形態において、構成ＩＤ１５２は制御ソフトウェア１５１内ではなく、バックアップデータ記憶領域内に格納してもよい。バックアップデータデータベース１４０と制御ソフトウェアデータベース１５０は、リプログラミング装置１３０内部に設けることもできるし、リプログラミング装置１３０外に設けることもできる。後者の場合、リプログラミング装置１３０、バックアップデータデータベース１４０、および制御ソフトウェアデータベース１５０は、有線または無線で接続することができる。あるいはインターネットなど外部ネットワークを介して接続することもできる。

以上の実施形態において、変数ＩＤフィールド１４１３と変数リビジョンフィールド１４１４を分けて管理しているが、これらを統合して単一のＩＤにより一意に管理することもできる。アドレスフィールド１４１２、変数ＩＤフィールド１４１３、変数リビジョンフィールド１４１４のうち少なくともいずれかは、構成テーブル１４１とは別のテーブルに分割して管理することもできる。パラメータテーブル１４２におけるＩＤフィールド１４２１とリビジョンフィールド１４２２についても同様である。

以上の実施形態において、名称フィールド１４２３、データ型フィールド１４２４、ビットレートフィールド１４２５、オフセットフィールド１４２６、初期値フィールド１４２７のうち少なくともいずれかは、パラメータテーブル１４２とは別のテーブルに分割して管理することもできる。これらのフィールドに代えて、変数の変換方法自体をパラメータとして保持することもできる。

１００：リプログラミングシステム、１１０：ＥＣＵ、１１１：ＣＰＵ、１１２：ＲＯＭ、１１３：ＲＡＭ、１１４：ＥＥＰＲＯＭ、１１５：通信回路、１３０：リプログラミング装置、１４０：バックアップデータデータベース、１４１：構成テーブル、１４２：パラメータテーブル、１５０：制御ソフトウェアデータベース、１５１：制御ソフトウェア、１５２：構成ＩＤ。

Claims

車両の動作を制御する処理を記述した制御ソフトウェアを実行する車両制御装置の前記制御ソフトウェアを更新するリプログラミングシステムであって、
前記車両制御装置は、
前記車両制御装置が前記制御ソフトウェアを実行することにより更新するデータのうち前記車両制御装置に対する電源供給が途絶えても保持すべき永続化データを格納する不揮発性メモリを備え、
前記リプログラミングシステムは、
前記制御ソフトウェアの更新版に対応する前記永続化データの更新版を前記不揮発性メモリに対して書き込むリプログラミング装置、
前記永続化データの前記不揮発性メモリ上における格納先アドレスを前記永続化データ内に含まれる１以上の変数毎に記述した構成テーブル、
を有し、
前記リプログラミング装置は、
前記構成テーブルの記述にしたがって、前記格納先アドレスについての前記制御ソフトウェアの更新前後に係る前記変数間の差分を特定し、
更新前の前記永続化データ内に含まれる前記変数の前記格納先アドレスを、特定した前記差分毎に、更新後の前記永続化データに対応する前記格納先アドレスへ更新する
ことを特徴とするリプログラミングシステム。
前記構成テーブルはさらに、
前記変数の１以上のバージョンとそのバージョン番号を、前記永続化データのバージョン番号毎に保持しており、
前記リプログラミング装置は、
更新前後それぞれの前記永続化データのバージョン番号をキーにして、更新前後それぞれの前記永続化データに対応する前記変数とそのバージョン番号を前記構成テーブルから取得し、
更新前後において前記変数とそのバージョン番号が同一であり前記格納先アドレスが異なる場合は、前記格納先アドレスを更新後の前記永続化データに対応する前記格納先アドレスに変換した上で、前記変数を前記不揮発性メモリに対して書き込む
ことを特徴とする請求項１記載のリプログラミングシステム。
前記リプログラミングシステムはさらに、
前記変数の初期値を前記変数のバージョン毎に記述したパラメータテーブルを有し、
前記リプログラミング装置は、
更新前後において前記変数とそのバージョン番号がともに異なる場合は、更新後の前記永続化データに対応する前記変数の初期値を前記不揮発性メモリに対して書き込む
ことを特徴とする請求項２記載のリプログラミングシステム。
前記リプログラミング装置は、
更新前後において前記変数が同一でありそのバージョン番号が異なる場合は、前記変数を更新後の前記永続化データに対応するバージョンに変換した上で、前記変数を前記不揮発性メモリに対して書き込む
ことを特徴とする請求項２記載のリプログラミングシステム。
前記リプログラミングシステムはさらに、
前記制御ソフトウェア内部における前記変数のデータ型、
前記変数を前記制御における物理値に変換する際に前記変数に対して乗算する乗数、
前記変数を前記制御における物理値に変換する際に前記変数に対して加算するオフセット値、
を前記変数のバージョン毎に記述したパラメータテーブルを有し、
前記リプログラミング装置は、前記変数を更新後の前記永続化データに対応するバージョンに変換する際に、前記パラメータテーブルの記述にしたがって、
更新前の前記永続化データに対応する前記乗数および前記オフセット値を用いて前記変数を前記物理値に変換した後、更新後の前記永続化データに対応する前記乗数および前記オフセット値を用いて前記物理値を前記変数に再変換し、
前記再変換後の前記変数のデータ型を更新後の前記永続化データに対応する前記変数のデータ型に変換する
ことを特徴とする請求項４記載のリプログラミングシステム。