(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-14
(45)【発行日】2023-12-22
(54)【発明の名称】車両用制御装置
(51)【国際特許分類】
G06F 8/65 20180101AFI20231215BHJP
B60R 16/02 20060101ALI20231215BHJP
【FI】
G06F8/65
B60R16/02 660U
(21)【出願番号】P 2023561946
(86)(22)【出願日】2021-11-16
(86)【国際出願番号】 JP2021042001
(87)【国際公開番号】W WO2023089652
(87)【国際公開日】2023-05-25
【審査請求日】2023-10-13
【早期審査対象出願】
(73)【特許権者】
【識別番号】000006013
【氏名又は名称】三菱電機株式会社
(74)【代理人】
【識別番号】110002941
【氏名又は名称】弁理士法人ぱるも特許事務所
(72)【発明者】
【氏名】眞田 晃宏
(72)【発明者】
【氏名】山田 望未
(72)【発明者】
【氏名】河野 卓矢
【審査官】多賀 実
(56)【参考文献】
【文献】特開2019-036140(JP,A)
【文献】特開2019-073106(JP,A)
【文献】特開2017-134506(JP,A)
【文献】山本 達也,「携帯情報端末」,デンソー公開技報,株式会社デンソー 知的財産部,2006年04月15日,No. 151,pp. 13-13R (整理番号151-013),ISSN 1342-7970
(58)【調査した分野】(Int.Cl.,DB名)
G06F 1/26-1/3296
G06F 8/65-8/658
B60R 16/02
(57)【特許請求の範囲】
【請求項1】
ソフトウェアが書き込まれた記憶装置、
前記ソフトウェアを更新する更新ソフトウェアを受信する受信部、
バッテリの電源残容量を検出する電源残容量検出部、
バッテリの電源残容量の低下量を検出する電源残容量低下検出部、
前記更新ソフトウェアを前記記憶装置に書き込むためのソフトウェア更新電力を算出するソフトウェア更新電力算出部、
前記電源残容量検出部によって検出された前記バッテリの残容量が、前記ソフトウェア更新電力算出部によって算出された前記ソフトウェア更新電力よりも大きい場合に、前記ソフトウェアの更新開始を許可するソフトウェア更新開始許可部、
前記バッテリの電源残容量の低下量が予め定められた低下判定値よりも小さい場合に前記ソフトウェアの更新継続を許可するソフトウェア更新継続許可部、
前記ソフトウェア更新開始許可部によってソフトウェアの更新開始を許可された場合に前記更新ソフトウェアの前記記憶装置への書き込みを開始し、前記更新ソフトウェアの前記記憶装置への書き込み中に前記ソフトウェア更新継続許可部によってソフトウェアの更新継続を許可された場合に前記更新ソフトウェアの前記記憶装置への書き込みを継続し、前記ソフトウェア更新開始許可部または前記ソフトウェア更新継続許可部の判定が不許可の場合は前記更新ソフトウェアの前記記憶装置への書き込みを中止するソフトウェア更新制御部、を備えた車両用制御装置。
【請求項2】
前記電源残容量低下検出部は、前記バッテリの電源電圧、コールドクランキング電流またはバッテリ液の比重の少なくとも一つに応じて前記電源残容量の低下量を検出する請求項1に記載の車両用制御装置。
【請求項3】
前記更新ソフトウェアの前記記憶装置への書き込み中に、書き込み完了までに消費されるソフトウェア更新継続電力を算出するソフトウェア更新継続電力算出部を備え、
前記ソフトウェア更新継続許可部は、前記電源残容量の低下量が前記低下判定値よりも小さくかつ、予め定めた第二の低下判定値よりも大きい場合は前記ソフトウェア更新継続電力算出部によって求められた前記ソフトウェア更新継続電力をあらかじめ定めた低下時増大割合だけ増大させて要求電源残容量を算出し、前記電源残容量の低下量が第二の低下判定値以下の場合は前記電源残容量の低下量に応じて前記ソフトウェア更新継続電力を増大させて前記要求電源残容量を算出し、前記バッテリの残容量が前記要求電源残容量よりも大きい場合に前記更新ソフトウェアの更新継続を許可する請求項1または2に記載の車両用制御装置。
【請求項4】
前記電源残容量低下検出部は、前記バッテリの電源電圧に応じて前記電源残容量の低下量を検出し、
前記ソフトウェア更新継続許可部は、前記バッテリの電源電圧が11.5V未満の場合に前記ソフトウェア更新継続電力を100%増大させて前記要求電源残容量を算出し、前記バッテリの電源電圧が11.5V以上かつ12.5V未満の場合に、前記バッテリの電源電圧が12.5Vから0.1V低下するごとに前記ソフトウェア更新継続電力を5%ずつ増大させて前記要求電源残容量を算出する請求項3に記載の車両用制御装置。
【請求項5】
前記電源残容量低下検出部は、前記バッテリのコールドクランキング電流に応じて前記電源残容量の低下量を検出し、
前記ソフトウェア更新継続許可部は、前記コールドクランキング電流が初期値の70%未満の場合に前記ソフトウェア更新継続電力を100%増大させて前記要求電源残容量を算出し、前記コールドクランキング電流が初期値の70%以上かつ100%未満の場合に、前記コールドクランキング電流が100%から低下した割合だけ、前記ソフトウェア更新継続電力を増大させて前記要求電源残容量を算出する請求項3に記載の車両用制御装置。
【請求項6】
前記電源残容量低下検出部は、前記バッテリのバッテリ液の比重に応じて前記電源残容量の低下量を検出し、
前記ソフトウェア更新継続許可部は、前記バッテリ液の比重が1.21未満の場合に、前記ソフトウェア更新継続電力を100%増大させて前記要求電源残容量を算出し、前記バッテリ液の比重が1.21以上かつ1.28未満の場合に、前記バッテリ液の比重が1.28から0.01低下するごとにソフトウェア更新継続電力を7%ずつ増大させて前記要求電源残容量を算出する請求項3に記載の車両用制御装置。
【請求項7】
前記ソフトウェア更新継続許可部は、前記バッテリの使用可能年数を5年以上超えて使用している場合に、前記要求電源残容量を100%増大させて算出する請求項3から6のいずれか一項に記載の車両用制御装置。
【請求項8】
前記ソフトウェア更新継続許可部は、前記バッテリが2回以上のバッテリ上がりの履歴を有している場合に、前記要求電源残容量を100%増大させて算出する請求項3から7のいずれか一項に記載の車両用制御装置。
【請求項9】
前記ソフトウェア更新継続許可部は、車両が1カ月以上継続して停止している場合、または移動距離2km未満の走行を10回以上連続して実施している場合に、前記要求電源残容量を100%増大させて算出する請求項3から8のいずれか一項に記載の車両用制御装置。
【請求項10】
前記ソフトウェア更新制御部は、前記ソフトウェア更新開始許可部によってソフトウェアの更新開始可能と判定された場合に前記更新ソフトウェアの前記記憶装置への書き込みを開始し、前記更新ソフトウェアの前記記憶装置への書き込みが予め定めた書き込み完了時間以内に完了する場合は、前記ソフトウェア更新継続許可部の判定に拘らず前記更新ソフトウェアの前記記憶装置への書き込みを継続する請求項1から9のいずれか一項に記載の車両用制御装置。
【請求項11】
前記ソフトウェア更新制御部は、前記更新ソフトウェアの前記記憶装置への書き込みが2分以内に完了する場合は、前記ソフトウェア更新継続許可部の判定に拘らず前記更新ソフトウェアの前記記憶装置への書き込みを継続する請求項10に記載の車両用制御装置。
【請求項12】
前記ソフトウェア更新制御部は、前記ソフトウェア更新開始許可部によってソフトウェアの更新開始可能と判定された場合に前記更新ソフトウェアの前記記憶装置への書き込みを開始し、前記電源残容量検出部によって検出された前記バッテリの残容量が、前記ソフトウェア更新電力算出部によって算出された前記ソフトウェア更新電力と予め定めた過剰電力の和よりも大きい場合は、前記ソフトウェア更新継続許可部の判定に拘らず前記更新ソフトウェアの前記記憶装置への書き込みを継続する請求項1から11のいずれか一項に記載の車両用制御装置。
【請求項13】
前記ソフトウェア更新制御部は、前記電源残容量検出部によって検出された前記バッテリの残容量が、前記ソフトウェア更新電力算出部によって算出された前記ソフトウェア更新電力と前記バッテリの初期電力容量の20%の和よりも大きい場合は、前記ソフトウェア更新継続許可部の判定に拘らず前記更新ソフトウェアの前記記憶装置への書き込みを継続する請求項12に記載の車両用制御装置。
【請求項14】
前記電源残容量低下検出部は、予め定めたポーリング周期ごとに前記バッテリの電源残容量の低下量を検出し、
ソフトウェア更新継続許可部は、前記ポーリング周期と前記更新ソフトウェアの前記記憶装置への書き込み開始から完了までの予定時間との比である経過時間比率を算出し、前記ポーリング周期間の前記電源残容量の低下量が前記ソフトウェア更新電力と前記経過時間比率の積の予め定めた係数倍よりも大きい場合は、前記ソフトウェアの更新継続を不許可と判定する請求項1から13のいずれか一項に記載の車両用制御装置。
【請求項15】
ソフトウェア更新継続許可部は、前記ポーリング周期間の前記電源残容量の低下量が前記ソフトウェア更新電力と前記経過時間比率の積の2倍よりも大きい場合は、前記ソフトウェアの更新継続を不許可と判定する請求項14に記載の車両用制御装置。
【請求項16】
前記受信部は、前記更新ソフトウェアに関する情報である更新ソフトウェア情報を受信し、前記更新ソフトウェア情報に基づいて前記更新ソフトウェアの本体である更新ソフトウェアデータを受信するための更新ソフトウェア受信電力を算出し、前記更新ソフトウェア情報に基づいて前記ソフトウェア更新電力算出部によって算出された前記ソフトウェア更新電力と前記更新ソフトウェア受信電力との和であるソフトウェア受信更新電力を算出し、前記電源残容量検出部によって検出された前記バッテリの電源残容量が前記ソフトウェア受信更新電力より大きければ前記更新ソフトウェアデータを受信し、前記バッテリの電源残容量が前記ソフトウェア受信更新電力以下であれば前記更新ソフトウェアデータの受信を拒否する、請求項1から15のいずれか一項に記載の車両用制御装置。
【発明の詳細な説明】
【技術分野】
【0001】
本願は、車両用制御装置に関するものである。
【背景技術】
【0002】
近年、自動車業界では車両用制御装置のソフトウェア更新が採用され始めている。車両用制御装置が外部からソフトウェア更新のためのデータを受信して、そのソフトウェアを保管している記憶装置のソフトウェアの書き換えが実行される。
【0003】
車両用制御装置のソフトウェア更新を、安定的に実施するための技術が提案されている。車両用制御装置に電源を供給するバッテリの電源残容量を確認し、ソフトウェア更新を実施することが可能かどうか判断した上で、ソフトウェア更新を実行するソフトウェアの更新方法について提案されている(例えば特許文献1)。
【先行技術文献】
【特許文献】
【0004】
【発明の概要】
【発明が解決しようとする課題】
【0005】
特許文献1に記載の技術によれば、車両用制御装置のソフトウェアの更新に際して、車両の動作電源(バッテリ)の残容量を取得する。電源残容量が、ソフトウェア更新に必要な消費電力より規定値より大きい場合にのみソフトウェア更新を実行する。このようにすることで、ソフトウェアの更新中に電源容量が不足して、ソフトウェア更新が中断することを防止することができる。その結果、安定した環境でソフトウェアの更新を実行することができる。
【0006】
しかし、特許文献1に記載の技術では、ソフトウェア更新中に電源残容量が急減した場合に対応できない。また、電源残容量の算定は、バッテリ性能の劣化、車両による充電状態の変化などによって誤差が生じる。よって、ソフトウェア更新に十分な電源残容量が確保できている前提でソフトウェア更新を実行しても、ソフトウェアの更新が完了できない場合が想定される。
【0007】
本願はかかる課題を解決するためになされたものである。車両に搭載された車両用制御装置のソフトウェアを更新する場合に、電源残容量を検出してソフトウェア更新電力よりも大きい場合にソフトウェア更新を開始し、ソフトウェア更新を開始後に電源残容量の低下量を検出してソフトウェアの更新継続が可能かどうかを判断して安定性の高いソフトウェアの更新を可能とする車両用制御装置を得ることを目的とする。
【課題を解決するための手段】
【0008】
本願に係る車両用制御装置は、
ソフトウェアが書き込まれた記憶装置、
ソフトウェアを更新する更新ソフトウェアを受信する受信部、
バッテリの電源残容量を検出する電源残容量検出部、
バッテリの電源残容量の低下量を検出する電源残容量低下検出部、
更新ソフトウェアを記憶装置に書き込むためのソフトウェア更新電力を算出するソフトウェア更新電力算出部、
電源残容量検出部によって検出されたバッテリの残容量が、ソフトウェア更新電力算出部によって算出されたソフトウェア更新電力よりも大きい場合に、ソフトウェアの更新開始を許可するソフトウェア更新開始許可部、
バッテリの電源残容量の低下量が予め定められた低下判定値よりも小さい場合にソフトウェアの更新継続を許可するソフトウェア更新継続許可部、
ソフトウェア更新開始許可部によってソフトウェアの更新開始を許可された場合に更新ソフトウェアの記憶装置への書き込みを開始し、更新ソフトウェアの記憶装置への書き込み中にソフトウェア更新継続許可部によってソフトウェアの更新継続を許可された場合に更新ソフトウェアの記憶装置への書き込みを継続し、ソフトウェア更新開始許可部またはソフトウェア更新継続許可部の判定が不許可の場合は更新ソフトウェアの記憶装置への書き込みを中止するソフトウェア更新制御部、を備えたものである。
【発明の効果】
【0009】
本願に係る車両用制御装置では、車両に搭載された車両用制御装置のソフトウェアを更新する場合に、バッテリ残容量を検出してソフトウェア更新電力よりも大きい場合にソフトウェア更新を開始し、ソフトウェア更新を開始後に電源残容量の低下量を検出してソフトウェアの更新継続が可能かどうかを判断して安定性の高いソフトウェアの更新が可能となる。
【図面の簡単な説明】
【0010】
【
図1】実施の形態1に係る車両用制御装置の構成図である。
【
図2】実施の形態1に係る車両用制御装置のハードウェア構成図である。
【
図3】実施の形態1に係る車両用制御装置のソフトウェア更新開始処理を示すフローチャートである。
【
図4】実施の形態1に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。
【
図5】実施の形態2に係る車両用制御装置のソフトウェア更新継続処理を示す第一のフローチャートである。
【
図6】実施の形態2に係る車両用制御装置のソフトウェア更新継続処理を示す第二のフローチャートである。
【
図7】実施の形態3に係る車両用制御装置のソフトウェア更新継続処理を示す第一のフローチャートである。
【
図8】実施の形態4に係る車両用制御装置のソフトウェア更新継続処理を示す第一のフローチャートである。
【
図9】実施の形態5に係る車両用制御装置のソフトウェア更新継続処理を示す第一のフローチャートである。
【
図10】実施の形態6に係る車両用制御装置のソフトウェア更新継続処理を示す第三のフローチャートである。
【
図11】実施の形態7に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。
【
図12】実施の形態8に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。
【
図13】実施の形態9に係る車両用制御装置のソフトウェア更新の第一のタイムチャートである。
【
図14】実施の形態9に係る車両用制御装置のソフトウェア更新の第二のタイムチャートである。
【
図15】実施の形態9に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。
【
図16】実施の形態10に係る車両用制御装置のソフトウェア更新開始前処理を示すフローチャートである。
【発明を実施するための形態】
【0011】
以下、本願の実施の形態に係る車両用制御装置について、図面を参照して説明する。
【0012】
1.実施の形態1
<車両用制御装置の構成>
図1は、実施の形態1に係る車両用制御装置100の構成図である。車両に搭載された車両用制御装置100は、通信部99、ソフトウェア更新制御部11、ソフトウェア更新電力算出部12、ソフトウェア更新開始許可部13、ソフトウェア更新継続許可部14、電源残容量検出部15、電源残容量低下検出部16を有し、バッテリ20に接続している。
【0013】
車両用制御装置100は、演算処理装置で実行するソフトウェアを格納する記憶装置91を備える。ここで演算処理装置は、車両用制御装置100の情報処理をすべて引き受けていてもよいが、エンジン制御、走行制御、ブレーキ制御などの特定の制御に特化してそれぞれ設けられていてもよい。
【0014】
図1では、記憶装置91は車両用制御装置100の内部に備えられた例を示している。しかし、記憶装置91は車両用制御装置100の外部に設けられた独立した制御装置に備えられていてもよい。さらに、記憶装置91は演算処理装置とともに複数設けられ、車両用制御装置100と接続されていてもよい。
【0015】
<更新ソフトウェアの受信>
車両用制御装置100の通信部99は、受信部18と送信部19を有し、外部と通信を行ってソフトウェア更新のためのデータを受信する。通信部99が通信を行う対象は、車両内の別の制御装置、車両のダイアグノシスコネクタに一時的に接続された再プログラミング装置、広域通信網を介して相互通信可能とした車外のサーバであってもよい。
【0016】
ここでは、車両用制御装置100が、車外のサーバ(不図示)と通信する場合について説明する。サーバは、車両用制御装置100の記憶装置91に書き込まれたソフトウェアの更新ソフトウェアに関するデータを送信する。車両用制御装置100の通信部99の受信部18で受信した更新ソフトウェアについて、ソフトウェア更新制御部11が記憶装置91への書き込みを制御する。
【0017】
記憶装置91に記憶されたソフトウェアを更新するに際して、ソフトウェアの書き換えを完了することが可能かどうか確認してから、書き換えを実行する。車両用制御装置100が電力を供給されるバッテリ20の電源残容量が枯渇している場合がある。そのような場合、ソフトウェアの書き換えの最中にバッテリ20の電圧が低下して、車両用制御装置100の動作が不安定になる事態も想定される。その場合、記憶装置91の書き換え途中のソフトウェアが異常動作を引き起こすことも考えられる。
【0018】
バッテリ20の電源残容量が充分であると判断して、ソフトウェアの書き換えを開始した場合であっても、問題が発生する場合が想定できる。バッテリ20の劣化、車両の電力消費の増大などの要因により、バッテリ20の電源残容量が急減する場合がある。また、当初のバッテリ20の電源残容量の検出または算出が不正確であって、実際の電源残容量が車両用制御装置100の認識している電源残容量よりも少ない場合もありうる。
【0019】
そこで、ソフトウェアの書き換えの最中に、バッテリ20の残容量の低下量を検出しソフトウェアの更新を継続するべきかどうかを判断する。バッテリ20の電源残容量が充分でないと判断した場合は、バッテリ20の電圧が低下して車両用制御装置100が機能不全となる前にソフトウェアの書き換えを中断し、ソフトウェアの更新を中止した旨、サーバへ通知することができる。
【0020】
また、車両用制御装置100での更新中のソフトウェアの実行を停止する、もしくはバックアップ記憶装置のソフトウェア実行に切り替えるなどの適切な対応をとることができる。このようにすることによって、バッテリ20の電源残容量が復活した場合に、ソフトウェア更新を再実施することができ、それまでの車両用制御装置100の異常動作を防止し、安定性の高いソフトウェアの更新が可能となる。
【0021】
ソフトウェアの更新に際して、車両のイグニッションスイッチがオフされていることを前提条件としてもよい。車両が停止していて、車両の運動による電源電圧の変動、車両の周囲状況の変化によるノイズの発生などが抑制できる利点が考えられるからである。しかし、車両のイグニッションスイッチのオフを前提条件とせず、車両の走行中にソフトウェアを更新することを許可することとしてもよい。ソフトウェア更新の機会を拡大することができる利点がある。
<ソフトウェア更新電力算出>
車両用制御装置100の受信部18はサーバから更新用ソフトウェアを受信する。この更新用ソフトウェアに対し、ソフトウェア更新電力算出部12にて記憶装置への書き換え実行に必要な出力であるソフトウェア更新電力EPrvを算出する。ソフトウェア更新電力EPrvを確保できなければ、更新ソフトウェアの書き換えが完了できない。
【0022】
<電源残容量の検出>
車両に備えられたバッテリ20は、車両用制御装置100をはじめ、車内の様々な機器に電力を供給する。バッテリ20に接続された電源残容量検出部15は、バッテリの電源残容量EPrを検出する。
【0023】
バッテリ20の電源残容量の検出には、バッテリの初期電力容量が把握されている場合、満充電時にこの初期値の電力容量を有しているとして、電源線の電圧、電流を計測し、放電量(電力使用量)と充電量を積算して現在の電源残容量を算出することができる。また、このようにして算出した電源残容量を、電圧を計測して求めた電源電圧Vb、電源電圧低下量ΔVb、計測器で求めたCCA(Cold Cranking Ampere)と初期値と比較したCCA比率、測定器で求めたバッテリ液比重SG(Specific Gravity)などの値によって補正してもよい。
【0024】
<ソフトウェア更新開始許可>
ソフトウェア更新開始許可部13は、電源残容量検出部15によって検出された電源残容量EPrと、ソフトウェア更新電力算出部12によって算出されたソフトウェア更新電力EPrvを比較する。電源残容量EPrがソフトウェア更新電力EPrvよりも大きい場合に、ソフトウェア更新開始許可部13は、ソフトウェアの更新開始を許可する。
【0025】
電源残容量EPrがソフトウェア更新電力EPrv以下の場合に、ソフトウェア更新開始許可部13は、ソフトウェアの更新開始を許可しない。ソフトウェア更新開始許可部13がソフトウェアの更新開始を許可しなければ、ソフトウェア更新制御部11は、記憶装置91のソフトウェアの書き換えを開始することができない。
【0026】
<電源残容量低下量の検出>
バッテリ20に接続された電源残容量低下検出部16は、バッテリ20の電源残容量低下量ΔEPrを検出する。バッテリ20は、経年劣化、電極への電界物質の付着、車両の電力消費の急増などの様々な要因によって容量が急減する場合がある。電源残容量低下検出部16は、このような場合の電源残容量低下量ΔEPrを検出することによって、バッテリ20の状態の予想外の変化に対応を可能とする。
【0027】
バッテリ20の電源残容量低下量ΔEPrは、放電量(電力使用量)と充電量を積算して求めた電源残容量の変動値から算出することができる。また電源残容量低下量ΔEPrは、電圧を計測して求めた電源電圧Vb、電源電圧低下量ΔVb、計測器で求めたCCA(Cold Cranking Ampere)と初期値と比較したCCA比率Rcca、CCA比率の変動値であるCCA比率低下量ΔRcca、測定器で求めたバッテリ液比重SG、バッテリ液比重低下量ΔSGなどの値によって求めてもよい。
【0028】
<ソフトウェア更新継続許可>
ソフトウェア更新継続許可部14は、電源残容量低下検出部16によって検出された電源残容量低下量ΔEPrをあらかじめ定められた低下判定値ΔEPjと比較する。電源残容量低下量ΔEPrが低下判定値ΔEPj以下であれば、ソフトウェア更新継続許可部14はバッテリ20の電源残容量がソフトウェア更新完了まで維持できると判断し、ソフトウェアの書き換え継続を許可する。
【0029】
電源残容量低下量ΔEPrが低下判定値ΔEPjよりも大きければ、ソフトウェア更新継続許可部14はバッテリ20の電源残容量がソフトウェア更新を完了できない可能性があると判断し、ソフトウェアの書き換え継続を許可しない。ソフトウェア更新継続許可部14がソフトウェアの更新継続を許可しなければ、ソフトウェア更新制御部11は、記憶装置91のソフトウェアの書き換えを継続することができない。
【0030】
<車両用制御装置のハードウェア構成>
図2は、実施の形態1に係る車両用制御装置100のハードウェア構成図である。車両用制御装置100の各機能は、車両用制御装置100が備えた処理回路により実現される。具体的には、車両用制御装置100は、
図2に示すように、処理回路として、CPU(Central Processing Unit)などの演算処理装置90(コンピュータ)、演算処理装置90とデータのやり取りする記憶装置91、演算処理装置90に外部の信号を入力する入力回路92、演算処理装置90から外部に信号を出力する出力回路93、及び通信路98を介してデータを送受信する通信部99などのインターフェースを備えている。
【0031】
演算処理装置90として、ASIC(Application Specific Integrated Circuit)、IC(Integrated Circuit)、DSP(Digital Signal Processor)、FPGA(Field Programmable Gate Array)、各種の論理回路、及び各種の信号処理回路などが備えられてもよい。演算処理装置90にはSoC(System on a Chip)技術が適用されてもよい。また、演算処理装置90として、同じ種類のものまたは異なる種類のものが複数備えられ、各処理が分担して実行されてもよい。車両用制御装置100には、記憶装置91として、演算処理装置90からデータを読み出し及び書き込みが可能に構成されたRAM(Random Access Memory)、演算処理装置90からデータを読み出し可能に構成されたROM(Read Only Memory)などが備えられている。記憶装置91は、演算処理装置90に内蔵されていてもよい。入力回路92は、入力信号、センサ、スイッチが接続され、これら入力信号、センサ、スイッチの信号を演算処理装置90に入力するA/D変換器などを備えている。出力回路93は、スイッチング素子をオンオフ駆動するゲート駆動回路などの電気負荷が接続され、これら電気負荷に演算処理装置90から制御信号を出力する駆動回路などを備えている。通信部99は通信路98を介して外部の制御装置などの外部装置とデータのやり取りを行うことができる。
【0032】
車両用制御装置100が備える各機能は、演算処理装置90が、ROMなどの記憶装置91に記憶されたソフトウェア(プログラム)を実行し、記憶装置91、入力回路92、及び出力回路93などの車両用制御装置100の他のハードウェアと協働することにより実現される。なお、車両用制御装置100が用いる閾値、判定値などの設定データは、ソフトウェア(プログラム)の一部として、ROMなどの記憶装置91に記憶されている。車両用制御装置100の有する各機能は、それぞれソフトウェアのモジュールで構成されるものであってもよいが、ソフトウェアとハードウェアの組み合わせによって構成されるものであってもよい。
【0033】
<ソフトウェア更新開始処理>
図3は、実施の形態1に係る車両用制御装置100のソフトウェア更新開始処理を示すフローチャートである。
図3のフローチャートでは、車両用制御装置100の各機能ブロックが動作する流れについて説明する。
【0034】
図3のフローチャートの処理は、所定時間ごとに実行される(例えば10msごと)。
図3のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、または車両用制御装置100がサーバからデータを受信するたび、といったイベントごとに実行されることとしてもよい。
【0035】
処理が開始され、ステップS101で、受信部18がサーバから更新ソフトウェアを受信したかどうか判定する。更新ソフトウェアを受信していない場合(判定はNO)は、処理を終了する。更新ソフトウェアを受信した場合(判定はYES)は、ステップS102へ進む。
【0036】
ステップS102では、ソフトウェア更新電力算出部12にて更新用ソフトウェアに対し記憶装置への書き換え実行に必要なソフトウェア更新電力EPrvを算出する。っして、ステップS103では、電源残容量検出部15によって、バッテリの電源残容量EPrを検出する。
【0037】
ステップS104では、ソフトウェア更新開始許可部13によって電源残容量EPrがソフトウェア更新電力EPrvよりも大きいかどうか判定される。電源残容量EPrがソフトウェア更新電力EPrv以下であれば(判定はNO)ステップS107へ進む。電源残容量EPrがソフトウェア更新電力EPrvよりも大きい場合(判定はYES)は、ステップS105へ進む。ソフトウェア更新開始許可部13によってソフトウェア更新開始が許可される場合である。
【0038】
ステップS105では、ソフトウェア更新中フラグをセットする。ソフトウェア更新中フラグは現在ソフトウェアの記憶装置91への書き換えを実行中であることを示すフラグである。ソフトウェア更新中フラグは、車両用制御装置の起動時などに初期設定としてクリアされるものとする。
【0039】
ステップS106では、ソフトウェアの更新を開始する。ソフトウェア更新制御部11は、記憶装置91のソフトウェアの書き換えを開始する。その後処理を終了する。
【0040】
ステップS107は、ソフトウェア更新開始許可部13によってソフトウェア更新開始が許可されない場合であり、ソフトウェア更新中フラグをクリアする。その後処理を終了する。
【0041】
<ソフトウェア更新継続処理>
図4は、実施の形態1に係る車両用制御装置100のソフトウェア更新継続処理を示すフローチャートである。
図4のフローチャートでは、ソフトウェア更新を実施中の車両用制御装置100の各機能ブロックが動作する流れについて説明する。
【0042】
図4のフローチャートの処理は、所定時間ごとに実行される(例えば10msごと、30秒ごとなど)。
図4のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、といったイベントごとに実行されることとしてもよい。
【0043】
処理が開始され、ステップS201で、ソフトウェア更新中フラグがセットされているかどうか判定する。ソフトウェア更新中フラグがセットされていない場合(判定はNO)は、処理を終了する。ソフトウェア更新中フラグがセットされている場合(判定はYES)は、ステップS202へ進む。
【0044】
ステップS202では、電源残容量低下検出部16によって電源残容量低下量ΔEPrが検出される。そして、ステップS203にて、電源残容量低下検出部16によって検出された電源残容量低下量ΔEPrが予め定められた低下判定値ΔEPj以上かどうか判定される。電源残容量低下量ΔEPrが低下判定値ΔEPj以上の場合(判定はYES)は、ステップS212へ進む。ソフトウェア更新継続許可部14がソフトウェアの更新継続を許可しない場合である。
【0045】
ステップS203で、電源残容量低下量ΔEPrが低下判定値ΔEPj未満の場合(判定はNO)は、ステップS209へ進む。ソフトウェア更新継続許可部14がソフトウェアの更新継続を許可する場合である。
【0046】
ステップS209で、ソフトウェア更新制御部11は、ソフトウェア更新が完了しているかどうか判定する。記憶装置91への更新ソフトウェアの書き換えが完了しているかどうか判定する。ソフトウェア更新が完了していない場合(判定はNO)処理を終了する。ソフトウェア更新中であり、そのままソフトウェア更新を継続することとなる。
【0047】
ステップS209で、ソフトウェア更新が完了している場合(判定はYES)は、ステップS210へ進む。ステップS210では、ソフトウェア更新フラグをクリアする。そして、ステップS211で、ソフトウェアの更新完了をサーバへ通知するように、送信部19へ指示し、処理を終了する。
【0048】
ステップS212では、ソフトウェア更新中フラグをクリアする。そして、ステップS213でソフトウェア更新制御部11によるソフトウェア更新を中止する。ステップS214で、ソフトウェアの更新中止をサーバへ通知するように、送信部19へ指示し、処理を終了する。
【0049】
実施の形態1に係る車両用制御装置100は、上記のように構成したので、バッテリ20の経年劣化、電極への電界物質の付着、車両の電力消費の急増などの要因によって容量が急減する場合に対応することができる。このような場合の電源残容量低下量ΔEPrを検出することによって、バッテリ20の状態の予想外の変化に適切な対応を可能とする。これによって、車両用制御装置100の異常動作を防止し、安定性の高いソフトウェアの更新が可能となる。
【0050】
2.実施の形態2
実施の形態2に係る車両用制御装置は
図1、
図2に示す車両用制御装置100の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態2に係る車両用制御装置100を実現できるが、ハードウェアの変更を伴っていてもよい。
【0051】
実施の形態2に係る車両用制御装置100は、実施の形態1に対してソフトウェア更新継続処理において、ソフトウェア更新継続許可部14の判断がさらに追加されている部分が異なる。ソフトウェア更新電力算出部12は、未書き込みの部分のソフトウェアの書き込みに必要な電力であるソフトウェア更新継続電力EPcrvを算出する。そして、ソフトウェア更新継続許可部14は電源残容量低下量ΔEPrに応じてこれを補正して、電源残容量EPrと比較する。ソフトウェア更新継続許可部14は、電源残容量EPrが補正されたソフトウェア更新継続電力EPcrvよりも大きい場合にのみソフトウェア更新継続を許可する。
【0052】
<ソフトウェア更新継続許可>
ソフトウェア更新継続許可部14は、電源残容量低下検出部16によって検出された電源残容量低下量ΔEPrをあらかじめ定められた低下判定値ΔEPjと比較する。電源残容量低下量ΔEPrが低下判定値ΔEPjよりも大きければ、ソフトウェア更新継続許可部14はバッテリ20の電源残容量がソフトウェア更新を完了できない可能性があると判断し、ソフトウェアの書き換え継続を許可しない。
【0053】
さらに、ソフトウェア更新継続許可部14はソフトウェア更新継続電力EPcrvを算出する。そして、電源残容量低下量ΔEPrに応じて、ソフトウェア更新継続電力EPcrvを補正する。電源残容量低下量ΔEPrが0未満であれば(電源残容量が低下していなければ)ソフトウェア更新継続電力EPcrvは補正せずにそのまま使用する。
【0054】
電源残容量低下量ΔEPrが0以上の場合(電源残容量が低下している場合)電源残容量低下量ΔEPrを予め定められた低下判定値ΔEPjと比較する。電源残容量低下量ΔEPrが低下判定値ΔEPj以下であれば、電源残容量低下量ΔEPrに応じた関数でソフトウェア更新継続電力EPcrvを増大させる。電源残容量低下量ΔEPrが低下判定値ΔEPjより大きければ、ソフトウェア更新継続電力EPcrvを予め定めた電源残容量低下時増大割合GEP乗じて増大させる。
【0055】
そして、電源残容量EPrが補正されたまたは補正無しのソフトウェア更新継続電力EPcrvより大きければ、ソフトウェア更新継続許可部14はソフトウェアの書き換え継続を許可する。
【0056】
<ソフトウェア更新継続処理>
図5は、実施の形態2に係る車両用制御装置100のソフトウェア更新継続処理を示す第一のフローチャートである。
図6は、実施の形態2に係る車両用制御装置100のソフトウェア更新継続処理を示す第二のフローチャートである。
図6のフローチャートは
図5のフローチャートの続きを示している。
【0057】
実施の形態2に係る
図5、
図6に示したフローチャートは、実施の形態1に係る
図4のフローチャートに対し、ステップS202、ステップS203が、
図5のステップS222から
図6のステップS228に置換された部分が異なる。以下、異なる部分について説明する。
【0058】
ステップS222では、電源残容量低下量ΔEPrを検出し、電源残容量EPrを検出し、ソフトウェア更新継続電力EPcrvを算出する。そしてステップS223へ進み、電源残容量低下量ΔEPrが予め定められた低下判定値ΔEPj以上かどうか判定する。電源残容量低下量ΔEPrが低下判定値ΔEPj以上の場合(判定はYES)は、
図6のステップS212へ進んでソフトウェア更新中止の一連の処理を行う。ソフトウェア更新継続許可部14がソフトウェアの更新継続を許可しない場合である。
【0059】
ステップS223で、電源残容量低下量ΔEPrが低下判定値ΔEPj未満の場合(判定はNO)は、ステップS224へ進む。ステップS224では、電源残容量低下量ΔEPrが0より小さいかどうか判定する。電源残容量低下量ΔEPrが0より小さい場合(判定はYES)は、電源残容量がマイナスである(電源残容量が増加している)場合である。バッテリ20が充電されている場合がこれに相当する。この場合は、ソフトウェア更新継続電力EPcrvに補正を加えずに
図6のステップS228へ進む。
【0060】
ステップS224で、電源残容量低下量ΔEPrが0より小さくない場合(判定はNO)は、ステップS225へ進む。ステップS225では、電源残容量低下量ΔEPrが予め定めた第二の低下判定値ΔEPj2以下かどうか判定する。電源残容量低下量ΔEPrが第二の低下判定値ΔEPj2以下でない場合(判定はNO)は、ステップS227へ進む。
【0061】
ステップS227では、ソフトウェア更新継続電力EPcrvに予め定められた電源残容量低下時増大割合GEPを乗じて、増大補正を実施する。そして、
図6のステップS228へ進む。
【0062】
ステップS225で、電源残容量低下量ΔEPrが第二の低下判定値ΔEPj2以下である場合(判定はYES)は、ステップS226へ進む。ステップS226では、ソフトウェア更新継続電力EPcrvに電源残容量低下量ΔEPrに応じた関数を乗じて、増大補正を実施する。そして、
図6のステップS228へ進む。
【0063】
図6のステップS228では、電源残容量EPrがソフトウェア更新継続電力EPcrvより大きいかどうか判定する。電源残容量EPrがソフトウェア更新継続電力EPcrvより大きくない場合(判定はNO)は、ステップS212へ進んでソフトウェア更新中止の一連の処理を行う。
【0064】
図6のステップS228で電源残容量EPrがソフトウェア更新継続電力EPcrvより大きい場合(判定はYES)は、ステップS209へ進んでソフトウェア更新が完了しているかどうか判定する。
【0065】
実施の形態2に係る車両用制御装置100は、上記のように構成したので、電源残容量低下量ΔEPrに応じて、ソフトウェア更新継続電力EPcrvを補正し、ソフトウェア更新の継続が可能かどうかきめ細かく判断することができる。これによって、バッテリ20の状態の予想外の変化に適切な対応を可能とし、ソフトウェアの更新が可能な場合は、ソフトウェアの更新を継続することができる。これによって、車両用制御装置100の異常動作を防止し、安定性の高いソフトウェアの更新の機会を増やすことが可能となる。
【0066】
3.実施の形態3
実施の形態3に係る車両用制御装置は
図1、
図2に示す車両用制御装置100の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態3に係る車両用制御装置100を実現できるが、ハードウェアの変更を伴っていてもよい。
【0067】
<電源電圧、電源電圧低下量の検出>
実施の形態3に係る車両用制御装置100は、実施の形態2に対してソフトウェア更新継続処理において、電源残容量低下検出部16の検出をバッテリ20の電源電圧Vb、電源電圧低下量ΔVbに基づいて実施する。この場合について具体的に説明する。電源電圧低下量ΔVbは、ソフトウェア更新開始時点の電源電圧からの電圧低下量である。ここでは、バッテリ20の電源電圧低下量判定値ΔVbng、上側電圧Vbh、下側電圧Vblを予め定めておくこととする。
【0068】
電源電圧低下量判定値ΔVbngは、ソフトウェア更新開始時点の電源電圧Vbからの低下量判定値であり、例えば1.5Vと設定する。この判定値を超えて電源電圧が低下した場合は、ソフトウェアの更新を中止する。上側電圧Vbhは例えば12.5V、下側電圧Vblは例えば11.5Vと設定する。これらの具体的な値は上記に限定されず、実験等によって最適な値に決定してもよい。
【0069】
電源電圧Vbが上側電圧Vbh以上の場合は異常な電源電圧の低下はないとして、ソフトウェア更新継続電力EPcrvを増大補正しない。そして、ソフトウェア更新継続電力EPcrvをそのまま電源残容量EPrと比較する。
【0070】
電源電圧Vbが下側電圧Vbl以上で上側電圧Vbh未満の場合は、ソフトウェア更新開始時点の電源電圧Vbからの電源電圧低下量ΔVbに応じてソフトウェア更新継続電力EPcrvを増大補正する。例えば、電圧が0.1V降下する度にソフトウェア更新継続電力EPcrvを5%増大させる。増大補正後のソフトウェア更新継続電力EPcrvを電源残容量EPrと比較する。
【0071】
電源電圧Vbが下側電圧Vbl未満の場合は、ソフトウェア更新継続電力EPcrvを100%増大補正する。増大補正後のソフトウェア更新継続電力EPcrvを電源残容量EPrと比較する。
【0072】
そして、ソフトウェア更新継続電力EPcrvを電源残容量EPrと比較して、電源残容量EPrのほうが大きい場合にソフトウェア更新の許可をする。このようにすることによって、電源電圧Vb、電源電圧低下量ΔVbの検出によって、ソフトウェアの更新継続の可否を決定することができる。
【0073】
<ソフトウェア更新継続処理>
図7は、実施の形態3に係る車両用制御装置100のソフトウェア更新継続処理を示す第一のフローチャートである。
図7のフローチャートの続きは、実施の形態2に係る
図6のフローチャートをそのまま流用する。
【0074】
以下、
図7のフローチャートについて説明する。
図7のフローチャートは所定時間ごとに実行される(例えば10msごと、30秒ごとなど)。
図7のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、といったイベントごとに実行されることとしてもよい。
【0075】
処理が開始され、ステップS201で、ソフトウェア更新中フラグがセットされているかどうか判定する。ソフトウェア更新中フラグがセットされていない場合(判定はNO)は、処理を終了する。ソフトウェア更新中フラグがセットされている場合(判定はYES)は、ステップS232へ進む。
【0076】
ステップS232では、電源電圧Vb、電源電圧低下量ΔVbを検出する。そして、電源残容量低下量ΔEPrを検出し、電源残容量EPrを検出し、ソフトウェア更新継続電力EPcrvを算出する。
【0077】
そしてステップS233へ進み、電源電圧低下量ΔVbが電源電圧低下量判定値ΔVbng以上かどうか判定する。電源電圧低下量ΔVbが電源電圧低下量判定値ΔVbng以上の場合(判定はYES)は、
図6のステップS212へ進んでソフトウェア更新中止の一連の処理を行う。ソフトウェア更新継続許可部14がソフトウェアの更新継続を許可しない場合である。
【0078】
ステップS233で電源電圧低下量ΔVbが電源電圧低下量判定値ΔVbng未満の場合(判定はNO)は、ステップS234へ進む。ステップS234では、電源電圧Vbが上側電圧Vbh以上であるかどうか判定する。電源電圧Vbが上側電圧Vbh以上の場合(判定はYES)は、異常な電源電圧の低下はない場合である。この場合は、ソフトウェア更新継続電力EPcrvに補正を加えずに
図6のステップS228へ進む。
【0079】
ステップS234で、電源電圧Vbが上側電圧Vbh未満の場合(判定はNO)は、ステップS235へ進む。ステップS235では、電源電圧Vbが下側電圧Vbl未満かどうか判定する。電源電圧Vbが下側電圧Vbl未満の場合(判定はYES)は、ステップS237へ進む。
【0080】
ステップS237では、ソフトウェア更新継続電力EPcrvを100%増大する(二倍にする)増大補正を実施する。そして、
図6のステップS228へ進む。
【0081】
ステップS235で、電源電圧Vbが下側電圧Vbl以上である場合(判定はNO)は、ステップS236へ進む。ステップS236では、ソフトウェア更新継続電力EPcrvに電源電圧低下量ΔVbに対して0.1V低下の度に5%増大する増大補正を実施する。すなわち、(1+ΔVb×0.5)を乗ずる補正となる。そして、
図6のステップS228へ進む。
【0082】
実施の形態3に係る車両用制御装置100は、上記のように構成したので、電源電圧Vb、電源電圧低下量ΔVbの検出によって、ソフトウェアの更新継続の可否を決定することができる。電源電圧低下量ΔVbに応じて、ソフトウェア更新継続電力EPcrvを補正し、ソフトウェア更新の継続が可能かどうかきめ細かく判断することができる。簡単な手法で、車両用制御装置100の異常動作を防止し、安定性の高いソフトウェアの更新の機会を増やすことが可能となる。
【0083】
4.実施の形態4
実施の形態4に係る車両用制御装置は
図1、
図2に示す車両用制御装置100の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態4に係る車両用制御装置100を実現できるが、ハードウェアの変更を伴っていてもよい。
【0084】
<コールドクランキング電流の検出>
実施の形態4に係る車両用制御装置100は、実施の形態2に対してソフトウェア更新継続処理において、電源残容量低下検出部16の検出をバッテリ20のコールドクランキング電流であるCCAに基づいて実施する。この場合について具体的に説明する。
【0085】
CCAは、米国のバッテリに関する規格によって定められた評価基準である。-18℃の環境下で、30秒間定格電流を流した場合に7.2V以上の端子電圧を有することが規定されている。例えば、CCA630Aは、-18℃環境下で、630Aの電流を30秒流し続け、端子電圧7.2V以上を確保するバッテリの能力のことである。
【0086】
放電して電源残容量が減少したバッテリのCCAであるクランキング電流Iccと、製造されたばかりで満充電されたバッテリのCCAであるクランキング電流初期値Iccinの比率を、CCA比率Rccaと定義する(Rcca=Icc/Iccini)。CCA比率低下量ΔRccaを、ソフトウェア更新開始時点のCCA比率Rccastに対する現在のCCA比率Rccaとの差として、ΔRcca=Rccast-Rccaと定義することができる。(Icc、Iccini、Rccastは不図示)
【0087】
CCAを計測するためには、コンダクタンス法、インピーダンス法、レジスタンス法などが存在する。CCAは、CCA計測用のテスターによって簡便に確認することも可能である。
【0088】
実施の形態4に係る車両用制御装置100では、バッテリ20の電源残容量EPrを、コールドクランキング電流CCA、CCA比率Rcca、CCA比率低下量ΔRccaに基づいて確認する。ここでは、CCA低下量判定値ΔRccang、CCA上側比率Rccah、CCA下側比率Rccalを予め定めておくこととする。
【0089】
CCA低下量判定値ΔRccangは、ソフトウェア更新開始時点のCCA比率RccaからのCCA比率低下量ΔRccaの判定値であり、例えば35%と設定する。この判定値を超えてCCA比率低下量ΔRccaが増大した場合は、ソフトウェアの更新を中止する。CCA上側比率Rccahは例えば100%、CCA下側比率Rccalは例えば70%と設定する。これらの具体的な値は上記に限定されず、実験等によって最適な値に決定してもよい。
【0090】
CCA比率RccaがCCA上側比率Rccah以上の場合は異常な電源残容量の低下はないとして、ソフトウェア更新継続電力EPcrvを増大補正しない。そして、ソフトウェア更新継続電力EPcrvをそのまま電源残容量EPrと比較する。
【0091】
CCA比率RccaがCCA下側比率Rccal以上でCCA上側比率Rccah未満の場合は、ソフトウェア更新開始時点のCCA比率RccastからのCCA比率低下量ΔRccaに応じてソフトウェア更新継続電力EPcrvを増大補正する。例えば、CCA比率Rccaが低下する度にソフトウェア更新継続電力EPcrvをCCA比率低下量ΔRccaの低下した割合だけ増大させる。増大補正後のソフトウェア更新継続電力EPcrvを電源残容量EPrと比較する。
【0092】
CCA比率RccaがCCA下側比率Rccal未満の場合は、ソフトウェア更新継続電力EPcrvを100%増大補正する。増大補正後のソフトウェア更新継続電力EPcrvを電源残容量EPrと比較する。
【0093】
そして、ソフトウェア更新継続電力EPcrvを電源残容量EPrと比較して、電源残容量EPrのほうが大きい場合にソフトウェア更新の許可をする。このようにすることによって、CCA比率Rcca、CCA比率低下量ΔRccaの検出によって、ソフトウェアの更新継続の可否を決定することができる。
【0094】
<ソフトウェア更新継続処理>
図8は、実施の形態4に係る車両用制御装置100のソフトウェア更新継続処理を示す第一のフローチャートである。
図8のフローチャートの続きは、実施の形態2に係る
図6のフローチャートをそのまま流用する。
【0095】
以下、
図8のフローチャートについて説明する。
図8のフローチャートは所定時間ごとに実行される(例えば10msごと、30秒ごとなど)。
図8のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、といったイベントごとに実行されることとしてもよい。
【0096】
処理が開始され、ステップS201で、ソフトウェア更新中フラグがセットされているかどうか判定する。ソフトウェア更新中フラグがセットされていない場合(判定はNO)は、処理を終了する。ソフトウェア更新中フラグがセットされている場合(判定はYES)は、ステップS242へ進む。
【0097】
ステップS242では、CCA比率Rcca、CCA比率低下量ΔRccaを検出する。そして、電源残容量EPrを検出し、ソフトウェア更新継続電力EPcrvを算出する。
【0098】
そしてステップS243へ進み、CCA比率低下量ΔRccaがCCA低下量判定値ΔRccang以上かどうか判定する。CCA比率低下量ΔRccaがCCA低下量判定値ΔRccang以上の場合(判定はYES)は、
図6のステップS212へ進んでソフトウェア更新中止の一連の処理を行う。ソフトウェア更新継続許可部14がソフトウェアの更新継続を許可しない場合である。
【0099】
ステップS243でCCA比率低下量ΔRccaがCCA低下量判定値ΔRccang未満の場合(判定はNO)は、ステップS244へ進む。ステップS244では、CCA比率RccaがCCA上側比率Rccah以上であるかどうか判定する。CCA比率RccaがCCA上側比率Rccah以上の場合(判定はYES)は、異常な電源電圧の低下はない場合である。この場合は、ソフトウェア更新継続電力EPcrvに補正を加えずに
図6のステップS228へ進む。
【0100】
ステップS244で、CCA比率RccaがCCA上側比率Rccah未満の場合(判定はNO)は、ステップS245へ進む。ステップS245では、CCA比率RccaがCCA下側比率Rccal未満かどうか判定する。CCA比率RccaがCCA下側比率Rccal未満の場合(判定はYES)は、ステップS247へ進む。
【0101】
ステップS247では、ソフトウェア更新継続電力EPcrvを100%増大する(二倍にする)増大補正を実施する。そして、
図6のステップS228へ進む。
【0102】
ステップS245で、CCA比率RccaがCCA下側比率Rccal以上である場合(判定はNO)は、ステップS246へ進む。ステップS246では、ソフトウェア更新継続電力EPcrvにCCA比率低下量ΔRccaの低下割合分の増大補正を実施する。すなわち、(1+ΔRcca)を乗ずる補正となる。そして、
図6のステップS228へ進む。
【0103】
実施の形態4に係る車両用制御装置100は、上記のように構成したので、CCA比率Rcca、CCA比率低下量ΔRccaの検出によって、ソフトウェアの更新継続の可否を決定することができる。CCA比率低下量ΔRccaに応じて、ソフトウェア更新継続電力EPcrvを補正し、ソフトウェア更新の継続が可能かどうかきめ細かく判断することができる。車両用制御装置100の異常動作を防止し、安定性の高いソフトウェアの更新の機会を増やすことが可能となる。
【0104】
5.実施の形態5
実施の形態5に係る車両用制御装置は
図1、
図2に示す車両用制御装置100の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態5に係る車両用制御装置100を実現できるが、ハードウェアの変更を伴っていてもよい。
【0105】
<バッテリ液比重の検出>
実施の形態5に係る車両用制御装置100は、実施の形態2に対してソフトウェア更新継続処理において、電源残容量低下検出部16の検出をバッテリ20のバッテリ液比重SGに基づいて実施する。この場合について具体的に説明する。
【0106】
バッテリ液比重SGは、バッテリの充電状態と相関を有する。よってバッテリ液比重SGを検出することによって、電源残容量EPrの算出をすることが可能である。
【0107】
実施の形態5に係る車両用制御装置100では、バッテリ20の電源残容量EPrを、バッテリ液比重SG、バッテリ液比重低下量ΔSGに基づいて確認する。ここでは、バッテリ液比重低下量判定値ΔSGng、バッテリ液上側比重SGh、バッテリ液下側比重SGlを予め定めておくこととする。
【0108】
バッテリ液比重低下量判定値ΔSGngは、ソフトウェア更新開始時点のバッテリ液比重SGからのバッテリ液比重低下量ΔSGの判定値であり、例えば0.08と設定する。この判定値を超えてバッテリ液比重低下量ΔSGが増大した場合は、ソフトウェアの更新を中止する。バッテリ液上側比重SGhは例えば1.28、バッテリ液下側比重SGlは例えば1.21と設定する。これらの具体的な値は上記に限定されず、実験等によって最適な値に決定してもよい。
【0109】
バッテリ液比重SGがバッテリ液上側比重SGh以上の場合は異常な電源残容量の低下はないとして、ソフトウェア更新継続電力EPcrvを増大補正しない。そして、ソフトウェア更新継続電力EPcrvをそのまま電源残容量EPrと比較する。
【0110】
バッテリ液比重SGがバッテリ液下側比重SGl以上でバッテリ液上側比重SGh未満の場合は、ソフトウェア更新開始時点のバッテリ液比重SGからのバッテリ液比重低下量ΔSGに応じてソフトウェア更新継続電力EPcrvを増大補正する。例えば、バッテリ液比重SGが0.01低下する度にソフトウェア更新継続電力EPcrvを7%増大させる。増大補正後のソフトウェア更新継続電力EPcrvを電源残容量EPrと比較する。
【0111】
バッテリ液比重SGがバッテリ液下側比重SGl未満の場合は、ソフトウェア更新継続電力EPcrvを100%増大補正する。増大補正後のソフトウェア更新継続電力EPcrvを電源残容量EPrと比較する。
【0112】
そして、ソフトウェア更新継続電力EPcrvを電源残容量EPrと比較して、電源残容量EPrのほうが大きい場合にソフトウェア更新の許可をする。このようにすることによって、バッテリ液比重SG、バッテリ液比重低下量ΔSGの検出によって、ソフトウェアの更新継続の可否を決定することができる。
【0113】
<ソフトウェア更新継続処理>
図9は、実施の形態5に係る車両用制御装置100のソフトウェア更新継続処理を示す第一のフローチャートである。
図9のフローチャートの続きは、実施の形態2に係る
図6のフローチャートをそのまま流用する。
【0114】
以下、
図9のフローチャートについて説明する。
図9のフローチャートは所定時間ごとに実行される(例えば10msごと、30秒ごとなど)。
図9のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、といったイベントごとに実行されることとしてもよい。
【0115】
処理が開始され、ステップS201で、ソフトウェア更新中フラグがセットされているかどうか判定する。ソフトウェア更新中フラグがセットされていない場合(判定はNO)は、処理を終了する。ソフトウェア更新中フラグがセットされている場合(判定はYES)は、ステップS252へ進む。
【0116】
ステップS252では、バッテリ液比重SG、バッテリ液比重低下量ΔSGを検出する。そして、電源残容量EPrを検出し、ソフトウェア更新継続電力EPcrvを算出する。
【0117】
そしてステップS253へ進み、バッテリ液比重低下量ΔSGがバッテリ液比重低下量判定値ΔSGng以上かどうか判定する。バッテリ液比重低下量ΔSGがバッテリ液比重低下量判定値ΔSGng以上の場合(判定はYES)は、
図6のステップS212へ進んでソフトウェア更新中止の一連の処理を行う。ソフトウェア更新継続許可部14がソフトウェアの更新継続を許可しない場合である。
【0118】
ステップS253でバッテリ液比重低下量ΔSGがバッテリ液比重低下量判定値ΔSGng未満の場合(判定はNO)は、ステップS254へ進む。ステップS254では、バッテリ液比重SGがバッテリ液上側比重SGh以上であるかどうか判定する。バッテリ液比重SGがバッテリ液上側比重SGh以上の場合(判定はYES)は、異常な電源電圧の低下はない場合である。この場合は、ソフトウェア更新継続電力EPcrvに補正を加えずに
図6のステップS228へ進む。
【0119】
ステップS254で、バッテリ液比重SGがバッテリ液上側比重SGh未満の場合(判定はNO)は、ステップS255へ進む。ステップS245では、バッテリ液比重SGがバッテリ液下側比重SGl未満かどうか判定する。バッテリ液比重SGがバッテリ液下側比重SGl未満の場合(判定はYES)は、ステップS257へ進む。
【0120】
ステップS257では、ソフトウェア更新継続電力EPcrvを100%増大する(二倍にする)増大補正を実施する。そして、
図6のステップS228へ進む。
【0121】
ステップS255で、バッテリ液比重SGがバッテリ液下側比重SGl以上である場合(判定はNO)は、ステップS256へ進む。ステップS256では、ソフトウェア更新継続電力EPcrvにバッテリ液比重低下量ΔSGが0.01増えるごとにソフトウェア更新継続電力EPcrvを7%増大する補正を実施する。すなわち、(1+ΔSG×7)を乗ずる補正となる。そして、
図6のステップS228へ進む。
【0122】
実施の形態5に係る車両用制御装置100は、上記のように構成したので、バッテリ液比重SG、バッテリ液比重低下量ΔSGの検出によって、ソフトウェアの更新継続の可否を決定することができる。バッテリ液比重低下量ΔSGに応じて、ソフトウェア更新継続電力EPcrvを補正し、ソフトウェア更新の継続が可能かどうかきめ細かく判断することができる。車両用制御装置100の異常動作を防止し、安定性の高いソフトウェアの更新の機会を増やすことが可能となる。
【0123】
6.実施の形態6
実施の形態6に係る車両用制御装置100は
図1、
図2に示す車両用制御装置100の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態6に係る車両用制御装置100を実現できるが、ハードウェアの変更を伴っていてもよい。
【0124】
<バッテリの使用年数超過>
実施の形態6に係る車両用制御装置100は、実施の形態2に対してソフトウェア更新継続処理において、電源残容量低下検出部16の検出をバッテリの使用年数、バッテリ上がり履歴、走行状況に基づいて実施する。この場合について具体的に説明する。
【0125】
車両に搭載しているバッテリ20について、使用可能年数(製品の耐用年数)を5年以上超えて使用している場合がある。このような場合は、バッテリ20が劣化していることが想定できる。そして、ソフトウェアの更新時に電源残容量EPrの急激な低下が発生する可能性がある。
【0126】
ソフトウェア更新継続の判断において、ソフトウェア更新継続電力EPcrvを拡大補正することによって、電源残容量EPrとの比較時に余裕を持ってソフトウェア更新を進めることができる。このために、バッテリ使用可能年数を5年以上超過して使用している場合は、ソフトウェア更新継続電力EPcrvを100%増大補正することとする。
【0127】
<バッテリ上がり履歴>
車両用の鉛蓄電池に代表されるバッテリは、電源残容量が過小となって電圧低下を生じる程度まで放電すると、電池内部に不可逆的変化が発生して再充電しても当初の性能まで復帰できない場合がある。このような状況を考慮して、バッテリ上がりの履歴を2回以上有する場合はバッテリの劣化が想定できる。この場合も、ソフトウェアの更新時に電源残容量EPrの急激な低下が発生する可能性がある。
【0128】
ソフトウェア更新継続の判断において、ソフトウェア更新継続電力EPcrvを拡大補正することによって、電源残容量EPrとの比較時に余裕を持ってソフトウェア更新を進めることができる。このために、過去に2度以上のバッテリ上がり履歴を有する場合は、ソフトウェア更新継続電力EPcrvを100%増大補正することとする。
【0129】
<長期間停車、短距離走行の繰り返し>
車両の使用状況によって、バッテリ20の状態は大きく変化する。1か月以上車両を動かしていない場合は、車両の原動機によってバッテリ20を充電する機会がなく、電源残容量が大きく低下している場合が想定できる。また、車両を走行させている場合であっても、走行距離が2km以内の移動を連続10回以上行っている場合は、車両の原動機によってバッテリ20を充分に充電する機会がなく、同じく電源残容量が大きく低下している場合が想定できる。この場合も、ソフトウェアの更新時に電源残容量EPrの急激な低下が発生する可能性がある。
【0130】
ソフトウェア更新継続の判断において、ソフトウェア更新継続電力EPcrvを拡大補正することによって、電源残容量EPrとの比較時に余裕を持ってソフトウェア更新を進めることができる。このために、1か月以上車両を動かしていない場合、または走行距離が2km以内の移動を連続10回以上行っている場合は、ソフトウェア更新継続電力EPcrvを100%増大補正することとする。
【0131】
<ソフトウェア更新継続処理>
図10は、実施の形態6に係る車両用制御装置100のソフトウェア更新継続処理を示す第三のフローチャートである。
図10のフローチャートは、実施の形態2に係る
図6の第二のフローチャートのステップS228の手前に挿入される。
図10のフローチャートの前には
図5の第一のフローチャートが設けられており、
図10のフローチャートの後には
図6の第二のフローチャートが設けられている。
図5、
図10、
図6のフローチャートの順に処理が実行される。
図5、
図6はそのまま流用するので、ここでは
図10について説明する。
【0132】
図5の実施の形態2に係るソフトウェア更新継続処理を示す第一のフローチャートで、ソフトウェア更新継続電力EPcrvを算出し、必要に応じて拡大補正をする。その後、
図10のフローチャートのステップS261へ進む。
【0133】
ステップS261では、バッテリ20が車両に設置されてからの経過時間が、バッテリ20の使用可能年数(耐久年数)に5年を加えた期間以上であるかどうかを判定する。ステップS261で、バッテリ経過時間(経時)が耐久年数+5年未満の場合(判定はNO)は、そのままステップS263へ進む。
【0134】
ステップS261で、バッテリ経過時間(経時)が耐久年数+5年以上の場合(判定はYES)は、ステップS262へ進んでソフトウェア更新継続電力EPcrvを100%増大補正する。その後ステップS263へ進む。
【0135】
ステップS263では、バッテリ20がバッテリ上がり2回以上の履歴を有するかどうか判定する。バッテリ上がり2回以上の履歴を有さない場合(判定はNO)は、そのままステップS265へ進む。
【0136】
ステップS263で、バッテリ上がり2回以上の履歴を有する場合(判定はYES)は、ステップS264へ進んでソフトウェア更新継続電力EPcrvを100%増大補正する。その後、ステップS265へ進む。
【0137】
ステップS265では、車両の走行状態を判定する。車両が1カ月以上停車または、2km以下の走行を10回以上しているかどうか判定する。車両が1カ月以上停車しておらず、2km以下の走行を10回以上していない場合(判定はNO)は、そのまま
図6のステップS228へ進む。
【0138】
ステップS265で、車両が1カ月以上停車または、2km以下の走行を10回以上している場合(判定はYES)は、ステップS266へ進んでソフトウェア更新継続電力EPcrvを100%増大補正する。その後、
図6のステップS228へ進む。
【0139】
以上のように構成することで、実施の形態6に係る車両用制御装置100は、バッテリの使用年数超過、バッテリ上がり履歴、長期間停車、短距離走行の繰り返しなどの状況に際して、ソフトウェア更新継続電力EPcrvを補正し、ソフトウェア更新の継続が可能かどうかきめ細かく判断することができる。車両用制御装置100の異常動作を防止し、安定性の高いソフトウェアの更新の機会を増やすことが可能となる。
【0140】
なお、上記のバッテリの耐久年数を超過している判定時間の5年間、バッテリ上がりの履歴の判定回数の2回、停車判定期間の1カ月、短距離走行判定距離の2km、単距離走行判定回数の10回、は判定値の例であり、変更してもよい。さらに、ソフトウェア更新継続電力EPcrvの増大補正量である100%は、補正量の例であり変更してもよい。これらは、実験、シミュレーションによって最適な判定値を見つけて決定してもよい。また、ステップS261、ステップS263、ステップS265に記載した判定の一部を省略してもよい。
【0141】
7.実施の形態7
実施の形態7に係る車両用制御装置100は
図1、
図2に示す車両用制御装置100の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態7に係る車両用制御装置100を実現できるが、ハードウェアの変更を伴っていてもよい。
【0142】
<ソフトウェア更新時間>
実施の形態7に係る車両用制御装置100は、実施の形態1に対してソフトウェア更新継続処理において、ソフトウェア書き込み完了までの時間Trvを算出し、この時間Trvが予め定めた書き込み完了時間Tcmp以下で完了する場合は、ソフトウェア更新中のソフトウェア更新継続許可部14による、継続可否の判断を行わない。書き込み完了時間Tcmpは例えば2分に設定してもよい。書き込み完了時間Tcmpは、実験またはシミュレーションによって適切な値を設定してもよい。
【0143】
このように、不必要なソフトウェアの更新継続可否判断を省略することで、ソフトウェア更新作業を効率的に短時間で完了することができる。また、不必要な処理を省略することができるので、バッテリ20の電源残容量の無駄な消費を削減することができる。
【0144】
<ソフトウェア更新継続処理>
図11は、実施の形態7に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。実施の形態1に係る
図4のソフトウェア更新継続処理を示すフローチャートのステップS201とステップS202の間に、新たにステップS271とステップS272を追加した部分のみが異なる。追加した部分を説明する。
【0145】
図11のステップS201で、ソフトウェア更新中フラグがセットされている場合、ステップS271へ進む。ステップS271では、ソフトウェア更新のために記憶装置91の更新ソフトウェアの書き込み完了までの時間Trvを算出する。そしてステップS272へ進む。
【0146】
ステップS272では、書き込み完了までの時間Trvが予め定めた書き込み完了時間Tcmp以下であるかどうか判定する。書き込み完了までの時間Trvが書き込み完了時間Tcmp以下であれば、ステップS209へ進んでソフトウェア更新完了しているかどうか確認する。
【0147】
このように構成することで、更新ソフトウェアの書き込み完了までの時間Trvが書き込み完了時間Tcmp以下の場合は、電源残容量低下量ΔEPrの確認などのソフトウェアの更新継続可否判断を省略することができる。
【0148】
8.実施の形態8
実施の形態8に係る車両用制御装置100は
図1、
図2に示す車両用制御装置100の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態8に係る車両用制御装置100を実現できるが、ハードウェアの変更を伴っていてもよい。
【0149】
<過剰電力を有する場合>
実施の形態8に係る車両用制御装置100は、実施の形態1に対してソフトウェア更新継続処理において、ソフトウェア更新開始処理において算出したソフトウェア更新電力EPrvに予め定めた過剰電力EPexを加えた電力よりも、電源残容量EPrのほうが大きいかどうか判定する。電源残容量EPrが、ソフトウェア更新電力EPrvよりも充分余裕を持っていれば(過剰電力EPex分余裕を持つ)、ソフトウェア更新中のソフトウェア更新継続許可部14による、継続可否の判断を行わない。過剰電力EPexは例えばバッテリ20の完全充電時の電源残容量の20%に設定してもよい。過剰電力EPexは、実験またはシミュレーションによって適切な値を設定してもよい。
【0150】
このように、電源残容量EPrに過剰電力EPex分余裕を持つ場合は、ソフトウェアの更新継続可否判断を省略することで、ソフトウェア更新作業を効率的に短時間で完了することができる。また、不必要な処理を省略することができるので、バッテリ20の電源残容量の無駄な消費を削減することができる。
【0151】
<ソフトウェア更新継続処理>
図12は、実施の形態8に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。実施の形態1に係る
図4のソフトウェア更新継続処理を示すフローチャートのステップS201とステップS202の間に、新たにステップS281を追加した部分のみが異なる。追加した部分を説明する。
【0152】
図12のステップS201で、ソフトウェア更新中フラグがセットされている場合、ステップS281へ進む。ステップS281では、電源残容量EPrが、ソフトウェア更新電力EPrvと過剰電力EPexの和よりも大きいかどうか判定する。電源残容量EPrが、ソフトウェア更新電力EPrvと過剰電力EPexの和よりも大きくない場合(判定はNO)は、ステップS202へ進み、ソフトウェアの更新継続可否判断を実行する。
【0153】
ステップS281で、電源残容量EPrがソフトウェア更新電力EPrvと過剰電力EPexの和よりも大きい場合(判定はYES)は、ステップS209へ進んでソフトウェア更新完了しているかどうか確認する。
【0154】
このように構成することで、バッテリ20が過剰電力EPexを有する場合は、電源残容量低下量ΔEPrの確認などのソフトウェアの更新継続可否判断を省略することができる。
【0155】
9.実施の形態9
実施の形態9に係る車両用制御装置100は
図1、
図2に示す車両用制御装置100の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態9に係る車両用制御装置100を実現できるが、ハードウェアの変更を伴っていてもよい。
【0156】
<ポーリング区間の電源残容量低下>
実施の形態9に係る車両用制御装置100は、実施の形態1に係るソフトウェア更新継続処理において、ポーリング区間に基づいた電源残容量低下の監視を実行する場合を示す。ここでは、ポーリング周期Tpが30秒の場合にポーリングを実行して、ソフトウェア更新継続処理を実行する。
【0157】
図13は、実施の形態9に係る車両用制御装置100のソフトウェア更新の第一のタイムチャートである。
図13では、180秒間に30秒間隔でポーリングを実行している様子を示している。ソフトウェア更新電力EPrvが、例えばバッテリ20の完全充電時の電源残容量の30%相当と算出されている場合、ポーリング区間ごとに、5%前後ずつ電源残容量EPrが減少する状態が示されている。
【0158】
ここで、予想している電源残容量低下量ΔEPrは、ポーリング周期Tpごとに5%である。そこで、例えばこの2倍である10%を超える電源残容量低下量ΔEPrが発生するかどうか監視し、10%を超える電源残容量低下量ΔEPrが発生した場合にソフトウェア更新を中止することとしてもよい。
【0159】
図14は、実施の形態9に係る車両用制御装置100のソフトウェア更新の第二のタイムチャートである。
図14では、3回目のポーリングにおいて、電源残容量低下量ΔEPrが12%となっている。10%を超える電源残容量低下量ΔEPrが発生したので、ここで、ソフトウェアの更新を中止する。
【0160】
ここでは、ポーリング周期Tpごとのソフトウェア更新電力EPrvによる電源残容量低下量ΔEPrの予想値に対してこの2倍を超えた場合にソフトウェアの更新を中止したが、2倍である必要はない。予想値に係数Kを乗じた判定値を、実験、シミュレーションなどで求めてもよい。
【0161】
<ソフトウェア更新継続処理>
図15は、実施の形態9に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。実施の形態1に係る
図4のソフトウェア更新継続処理を示すフローチャートのステップS202とステップS203の間に、新たにステップS291からステップS293を追加した部分のみが異なる。追加した部分を中心に説明する。
【0162】
図15のステップS201で、ソフトウェア更新中フラグがセットされている場合、ステップS202へ進む。ステップS202では、電源残容量低下検出部16によって電源残容量低下量ΔEPrが検出される。ここでは、ポーリングのたびに求めた電源残容量EPrの前回検出値との差分を電源残容量低下量ΔEPrとする。
【0163】
ステップS291では、ソフトウェアの更新を開始してから完了するまでのソフトウェア更新時間Trpを算出する。そして、ステップS292では、経過時間比率RTbpを算出する。経過時間比率RTbpは、ポーリング周期Tpとソフトウェア更新時間Trpの比である。
【0164】
ステップS293では、ソフトウェア更新電力EPrvと経過時間比率RTbpの積に係数Kを乗じた値よりも電源残容量低下量ΔEPrが大きいかどうか判定する。電源残容量低下量ΔEPrが大きい場合(判定はYES)は、ポーリング区間の電源残容量低下量ΔEPrが予測値に係数Kを乗じた値より大きいことを示す。電源残容量低下量ΔEPrが、予想外に大きいとの判断で、ステップS212に進んで、ソフトウェア更新中止の処理を進める。
【0165】
ステップS293で、電源残容量低下量ΔEPrが大きくない場合(判定はNO)ステップS203へ進む。ステップS203では、電源残容量低下量ΔEPrが予め定められた低下判定値ΔEPj以上かどうか判定する。
【0166】
以上のようにポーリング区間ごとの電源残容量低下量ΔEPrが予測値に係数Kを乗じた値より大きいか否かによって、ソフトウェアの更新の継続可否を判定する。これによって、電源残容量低下量ΔEPrの増大を、固定値である低下判定値ΔEPjと比較するよりも精度よく判定することができる。そのため、車両用制御装置100の異常動作を防止し、安定性の高いソフトウェアの更新が可能となる。
【0167】
10.実施の形態10
実施の形態10に係る車両用制御装置100は
図1、
図2に示す車両用制御装置100の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態10に係る車両用制御装置100を実現できるが、ハードウェアの変更を伴っていてもよい。
【0168】
<ソフトウェア受信電力の算出>
実施の形態10に係る車両用制御装置100は、実施の形態1に係るソフトウェア更新開始処理の前処理として、ソフトウェア更新開始前処理を実施する。車両用制御装置100は、サーバから更新ソフトウェアのデータを受信する前に、更新ソフトウェアに関する情報である更新ソフトウェア情報を受信する。
【0169】
更新ソフトウェア情報には、更新ソフトウェアの容量などの情報が含まれている。車両用制御装置100は、更新ソフトウェア本体のデータを受信するために必要な更新ソフトウェア受信電力EPrcvを算出する。そして、更新ソフトウェアを記憶装置91に書き込むためのソフトウェア更新電力EPrvを算出する。
【0170】
更新ソフトウェア受信電力EPrcvとソフトウェア更新電力EPrvの和が、ソフトウェア受信更新電力EPrcv_rvである。車両用制御装置100は、サーバから受信した更新ソフトウェア情報から、ソフトウェア受信更新電力EPrcv_rvを算出し、電源残容量EPrがソフトウェア受信更新電力EPrcv_rvよりも大きい場合に、サーバからの更新ソフトウェアの受信を受け入れる。
【0171】
電源残容量EPrが小さい場合は、ソフトウェア更新が実施できないので、サーバに更新ソフトウェアのデータの受信拒否を回答する。このように、更新ソフトウェアのデータの受信前に電源残容量EPrでソフトウェア更新が可能か否か判断することができる。それによって、不要な更新ソフトウェアの受信を回避できる。これによって、バッテリ20の電源残容量EPrの消費を節約することができる。そして、安定性の高いソフトウェアの更新が可能となる。
【0172】
<ソフトウェア更新開始前処理>
図16は、実施の形態10に係る車両用制御装置のソフトウェア更新開始前処理を示すフローチャートである。実施の形態1に係る
図3のソフトウェア更新開始処理を示すフローチャートに先立って実行される処理である。
【0173】
図16のフローチャートの処理は、所定時間ごとに実行される(例えば10msごと)。
図16のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、または車両用制御装置100がサーバからデータを受信するたび、といったイベントごとに実行されることとしてもよい。
【0174】
処理が開始され、ステップS111で、受信部18がサーバから更新ソフトウェア情報を受信したかどうか判定する。更新ソフトウェアを受信していない場合(判定はNO)は、処理を終了する。更新ソフトウェアを受信した場合(判定はYES)は、ステップS112へ進む。
【0175】
ステップS112では、更新ソフトウェア情報に基づいて更新ソフトウェア本体のデータを受信するために必要な更新ソフトウェア受信電力EPrcvを算出する。ステップS113で、更新ソフトウェアを記憶装置91に書き込むためのソフトウェア更新電力EPrvを算出する。
【0176】
ステップS114で、更新ソフトウェア受信電力EPrcvとソフトウェア更新電力EPrvを加算して、ソフトウェア受信更新電力EPrcv_rvを算出する。ステップS115で、電源残容量EPrを検出する。
【0177】
ステップS116で、電源残容量EPrがソフトウェア受信更新電力EPrcv_rvより大きいか判定する。電源残容量EPrがソフトウェア受信更新電力EPrcv_rv以下である場合(判定はNO)は、ステップS118へ進む。ステップS118では、サーバへソフトウェア受信拒否の回答を送信する。その後処理を終了する。
【0178】
ステップS116で、電源残容量EPrがソフトウェア受信更新電力EPrcv_rvより大きい場合(判定はYES)は、ステップS117へ進む。ステップS117では、サーバへソフトウェア受信受入の回答を送信する。その後処理を終了する。
【0179】
サーバは車両用制御装置100からの受信受入れ回答を受信した後に、更新ソフトウェア本体のデータを車両用制御装置100へ送信開始する。車両用制御装置100は、更新ソフトウェアを受信した後、
図3にフローチャートを示したソフトウェア更新開始処理を開始する。
【0180】
本願は、様々な例示的な実施の形態及び実施例が記載されているが、1つ、または複数の実施の形態に記載された様々な特徴、態様、及び機能は特定の実施の形態の適用に限られるのではなく、単独で、または様々な組み合わせで実施の形態に適用可能である。従って、例示されていない無数の変形例が、本願明細書に開示される技術の範囲内において想定される。例えば、少なくとも1つの構成要素を変形する場合、追加する場合または省略する場合、さらには、少なくとも1つの構成要素を抽出し、他の実施の形態の構成要素と組み合わせる場合が含まれるものとする。
【符号の説明】
【0181】
11 ソフトウェア更新制御部、12 ソフトウェア更新電力算出部、13 ソフトウェア更新開始許可部、14 ソフトウェア更新継続許可部、15 電源残容量検出部、16 電源残容量低下検出部、18 受信部、20 バッテリ、91 記憶装置、100 車両用制御装置、EPcrv ソフトウェア更新継続電力、EPex 過剰電力、EPr 電源残容量、EPrcv 更新ソフトウェア受信電力、EPrcv_rv ソフトウェア受信更新電力、EPrv ソフトウェア更新電力、GEP 電源残容量低下時増大割合、K 係数、Rcca CCA比率、Rccah CCA上側比率、Rccal CCA下側比率、RTbp 経過時間比率、SG バッテリ液比重、SGh バッテリ液上側比重、SGl バッテリ液下側比重、Tcmp 書き込み完了時間、Tp ポーリング周期、Trp ソフトウェア更新時間、Trv 時間、Vb 電源電圧、Vbh 上側電圧、Vbl 下側電圧、ΔEPj 低下判定値、ΔEPj2 第二の低下判定値、ΔEPr 電源残容量低下量、ΔRcca CCA比率低下量、ΔRccang CCA低下量判定値、ΔSG バッテリ液比重低下量、ΔSGng バッテリ液比重低下量判定値、ΔVb 電源電圧低下量、ΔVbng 電源電圧低下量判定値