JP7403730B2 - 車両用制御装置 - Google Patents

Description

本願は、車両用制御装置に関するものである。

近年、自動車業界では車両用制御装置のソフトウェア更新が採用され始めている。車両用制御装置が外部からソフトウェア更新のためのデータを受信して、そのソフトウェアを保管している記憶装置のソフトウェアの書き換えが実行される。

車両用制御装置のソフトウェア更新を、安定的に実施するための技術が提案されている。車両用制御装置に電源を供給するバッテリの電源残容量を確認し、ソフトウェア更新を実施することが可能かどうか判断した上で、ソフトウェア更新を実行するソフトウェアの更新方法について提案されている（例えば特許文献１）。

特許第５６９９８９３号公報

特許文献１に記載の技術によれば、車両用制御装置のソフトウェアの更新に際して、車両の動作電源（バッテリ）の残容量を取得する。電源残容量が、ソフトウェア更新に必要な消費電力より規定値より大きい場合にのみソフトウェア更新を実行する。このようにすることで、ソフトウェアの更新中に電源容量が不足して、ソフトウェア更新が中断することを防止することができる。その結果、安定した環境でソフトウェアの更新を実行することができる。

しかし、特許文献１に記載の技術では、ソフトウェア更新中に電源残容量が急減した場合に対応できない。また、電源残容量の算定は、バッテリ性能の劣化、車両による充電状態の変化などによって誤差が生じる。よって、ソフトウェア更新に十分な電源残容量が確保できている前提でソフトウェア更新を実行しても、ソフトウェアの更新が完了できない場合が想定される。

本願はかかる課題を解決するためになされたものである。車両に搭載された車両用制御装置のソフトウェアを更新する場合に、電源残容量を検出してソフトウェア更新電力よりも大きい場合にソフトウェア更新を開始し、ソフトウェア更新を開始後に電源残容量の低下量を検出してソフトウェアの更新継続が可能かどうかを判断して安定性の高いソフトウェアの更新を可能とする車両用制御装置を得ることを目的とする。

本願に係る車両用制御装置は、
ソフトウェアが書き込まれた記憶装置、
ソフトウェアを更新する更新ソフトウェアを受信する受信部、
バッテリの電源残容量を検出する電源残容量検出部、
バッテリの電源残容量の低下量を検出する電源残容量低下検出部、
更新ソフトウェアを記憶装置に書き込むためのソフトウェア更新電力を算出するソフトウェア更新電力算出部、
電源残容量検出部によって検出されたバッテリの残容量が、ソフトウェア更新電力算出部によって算出されたソフトウェア更新電力よりも大きい場合に、ソフトウェアの更新開始を許可するソフトウェア更新開始許可部、
バッテリの電源残容量の低下量が予め定められた低下判定値よりも小さい場合にソフトウェアの更新継続を許可するソフトウェア更新継続許可部、
ソフトウェア更新開始許可部によってソフトウェアの更新開始を許可された場合に更新ソフトウェアの記憶装置への書き込みを開始し、更新ソフトウェアの記憶装置への書き込み中にソフトウェア更新継続許可部によってソフトウェアの更新継続を許可された場合に更新ソフトウェアの記憶装置への書き込みを継続し、ソフトウェア更新開始許可部またはソフトウェア更新継続許可部の判定が不許可の場合は更新ソフトウェアの記憶装置への書き込みを中止するソフトウェア更新制御部、を備えたものである。

本願に係る車両用制御装置では、車両に搭載された車両用制御装置のソフトウェアを更新する場合に、バッテリ残容量を検出してソフトウェア更新電力よりも大きい場合にソフトウェア更新を開始し、ソフトウェア更新を開始後に電源残容量の低下量を検出してソフトウェアの更新継続が可能かどうかを判断して安定性の高いソフトウェアの更新が可能となる。

実施の形態１に係る車両用制御装置の構成図である。 実施の形態１に係る車両用制御装置のハードウェア構成図である。 実施の形態１に係る車両用制御装置のソフトウェア更新開始処理を示すフローチャートである。 実施の形態１に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。 実施の形態２に係る車両用制御装置のソフトウェア更新継続処理を示す第一のフローチャートである。 実施の形態２に係る車両用制御装置のソフトウェア更新継続処理を示す第二のフローチャートである。 実施の形態３に係る車両用制御装置のソフトウェア更新継続処理を示す第一のフローチャートである。 実施の形態４に係る車両用制御装置のソフトウェア更新継続処理を示す第一のフローチャートである。 実施の形態５に係る車両用制御装置のソフトウェア更新継続処理を示す第一のフローチャートである。 実施の形態６に係る車両用制御装置のソフトウェア更新継続処理を示す第三のフローチャートである。 実施の形態７に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。 実施の形態８に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。 実施の形態９に係る車両用制御装置のソフトウェア更新の第一のタイムチャートである。 実施の形態９に係る車両用制御装置のソフトウェア更新の第二のタイムチャートである。 実施の形態９に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。 実施の形態１０に係る車両用制御装置のソフトウェア更新開始前処理を示すフローチャートである。

以下、本願の実施の形態に係る車両用制御装置について、図面を参照して説明する。

１．実施の形態１
＜車両用制御装置の構成＞
図１は、実施の形態１に係る車両用制御装置１００の構成図である。車両に搭載された車両用制御装置１００は、通信部９９、ソフトウェア更新制御部１１、ソフトウェア更新電力算出部１２、ソフトウェア更新開始許可部１３、ソフトウェア更新継続許可部１４、電源残容量検出部１５、電源残容量低下検出部１６を有し、バッテリ２０に接続している。

車両用制御装置１００は、演算処理装置で実行するソフトウェアを格納する記憶装置９１を備える。ここで演算処理装置は、車両用制御装置１００の情報処理をすべて引き受けていてもよいが、エンジン制御、走行制御、ブレーキ制御などの特定の制御に特化してそれぞれ設けられていてもよい。

図１では、記憶装置９１は車両用制御装置１００の内部に備えられた例を示している。しかし、記憶装置９１は車両用制御装置１００の外部に設けられた独立した制御装置に備えられていてもよい。さらに、記憶装置９１は演算処理装置とともに複数設けられ、車両用制御装置１００と接続されていてもよい。

＜更新ソフトウェアの受信＞
車両用制御装置１００の通信部９９は、受信部１８と送信部１９を有し、外部と通信を行ってソフトウェア更新のためのデータを受信する。通信部９９が通信を行う対象は、車両内の別の制御装置、車両のダイアグノシスコネクタに一時的に接続された再プログラミング装置、広域通信網を介して相互通信可能とした車外のサーバであってもよい。

ここでは、車両用制御装置１００が、車外のサーバ（不図示）と通信する場合について説明する。サーバは、車両用制御装置１００の記憶装置９１に書き込まれたソフトウェアの更新ソフトウェアに関するデータを送信する。車両用制御装置１００の通信部９９の受信部１８で受信した更新ソフトウェアについて、ソフトウェア更新制御部１１が記憶装置９１への書き込みを制御する。

記憶装置９１に記憶されたソフトウェアを更新するに際して、ソフトウェアの書き換えを完了することが可能かどうか確認してから、書き換えを実行する。車両用制御装置１００が電力を供給されるバッテリ２０の電源残容量が枯渇している場合がある。そのような場合、ソフトウェアの書き換えの最中にバッテリ２０の電圧が低下して、車両用制御装置１００の動作が不安定になる事態も想定される。その場合、記憶装置９１の書き換え途中のソフトウェアが異常動作を引き起こすことも考えられる。

バッテリ２０の電源残容量が充分であると判断して、ソフトウェアの書き換えを開始した場合であっても、問題が発生する場合が想定できる。バッテリ２０の劣化、車両の電力消費の増大などの要因により、バッテリ２０の電源残容量が急減する場合がある。また、当初のバッテリ２０の電源残容量の検出または算出が不正確であって、実際の電源残容量が車両用制御装置１００の認識している電源残容量よりも少ない場合もありうる。

そこで、ソフトウェアの書き換えの最中に、バッテリ２０の残容量の低下量を検出しソフトウェアの更新を継続するべきかどうかを判断する。バッテリ２０の電源残容量が充分でないと判断した場合は、バッテリ２０の電圧が低下して車両用制御装置１００が機能不全となる前にソフトウェアの書き換えを中断し、ソフトウェアの更新を中止した旨、サーバへ通知することができる。

また、車両用制御装置１００での更新中のソフトウェアの実行を停止する、もしくはバックアップ記憶装置のソフトウェア実行に切り替えるなどの適切な対応をとることができる。このようにすることによって、バッテリ２０の電源残容量が復活した場合に、ソフトウェア更新を再実施することができ、それまでの車両用制御装置１００の異常動作を防止し、安定性の高いソフトウェアの更新が可能となる。

ソフトウェアの更新に際して、車両のイグニッションスイッチがオフされていることを前提条件としてもよい。車両が停止していて、車両の運動による電源電圧の変動、車両の周囲状況の変化によるノイズの発生などが抑制できる利点が考えられるからである。しかし、車両のイグニッションスイッチのオフを前提条件とせず、車両の走行中にソフトウェアを更新することを許可することとしてもよい。ソフトウェア更新の機会を拡大することができる利点がある。
＜ソフトウェア更新電力算出＞
車両用制御装置１００の受信部１８はサーバから更新用ソフトウェアを受信する。この更新用ソフトウェアに対し、ソフトウェア更新電力算出部１２にて記憶装置への書き換え実行に必要な出力であるソフトウェア更新電力ＥＰｒｖを算出する。ソフトウェア更新電力ＥＰｒｖを確保できなければ、更新ソフトウェアの書き換えが完了できない。

＜電源残容量の検出＞
車両に備えられたバッテリ２０は、車両用制御装置１００をはじめ、車内の様々な機器に電力を供給する。バッテリ２０に接続された電源残容量検出部１５は、バッテリの電源残容量ＥＰｒを検出する。

バッテリ２０の電源残容量の検出には、バッテリの初期電力容量が把握されている場合、満充電時にこの初期値の電力容量を有しているとして、電源線の電圧、電流を計測し、放電量（電力使用量）と充電量を積算して現在の電源残容量を算出することができる。また、このようにして算出した電源残容量を、電圧を計測して求めた電源電圧Ｖｂ、電源電圧低下量ΔＶｂ、計測器で求めたＣＣＡ（Cold Cranking Ampere）と初期値と比較したＣＣＡ比率、測定器で求めたバッテリ液比重ＳＧ（Specific Gravity）などの値によって補正してもよい。

＜ソフトウェア更新開始許可＞
ソフトウェア更新開始許可部１３は、電源残容量検出部１５によって検出された電源残容量ＥＰｒと、ソフトウェア更新電力算出部１２によって算出されたソフトウェア更新電力ＥＰｒｖを比較する。電源残容量ＥＰｒがソフトウェア更新電力ＥＰｒｖよりも大きい場合に、ソフトウェア更新開始許可部１３は、ソフトウェアの更新開始を許可する。

電源残容量ＥＰｒがソフトウェア更新電力ＥＰｒｖ以下の場合に、ソフトウェア更新開始許可部１３は、ソフトウェアの更新開始を許可しない。ソフトウェア更新開始許可部１３がソフトウェアの更新開始を許可しなければ、ソフトウェア更新制御部１１は、記憶装置９１のソフトウェアの書き換えを開始することができない。

＜電源残容量低下量の検出＞
バッテリ２０に接続された電源残容量低下検出部１６は、バッテリ２０の電源残容量低下量ΔＥＰｒを検出する。バッテリ２０は、経年劣化、電極への電界物質の付着、車両の電力消費の急増などの様々な要因によって容量が急減する場合がある。電源残容量低下検出部１６は、このような場合の電源残容量低下量ΔＥＰｒを検出することによって、バッテリ２０の状態の予想外の変化に対応を可能とする。

バッテリ２０の電源残容量低下量ΔＥＰｒは、放電量（電力使用量）と充電量を積算して求めた電源残容量の変動値から算出することができる。また電源残容量低下量ΔＥＰｒは、電圧を計測して求めた電源電圧Ｖｂ、電源電圧低下量ΔＶｂ、計測器で求めたＣＣＡ（Cold Cranking Ampere）と初期値と比較したＣＣＡ比率Ｒｃｃａ、ＣＣＡ比率の変動値であるＣＣＡ比率低下量ΔＲｃｃａ、測定器で求めたバッテリ液比重ＳＧ、バッテリ液比重低下量ΔＳＧなどの値によって求めてもよい。

＜ソフトウェア更新継続許可＞
ソフトウェア更新継続許可部１４は、電源残容量低下検出部１６によって検出された電源残容量低下量ΔＥＰｒをあらかじめ定められた低下判定値ΔＥＰｊと比較する。電源残容量低下量ΔＥＰｒが低下判定値ΔＥＰｊ以下であれば、ソフトウェア更新継続許可部１４はバッテリ２０の電源残容量がソフトウェア更新完了まで維持できると判断し、ソフトウェアの書き換え継続を許可する。

電源残容量低下量ΔＥＰｒが低下判定値ΔＥＰｊよりも大きければ、ソフトウェア更新継続許可部１４はバッテリ２０の電源残容量がソフトウェア更新を完了できない可能性があると判断し、ソフトウェアの書き換え継続を許可しない。ソフトウェア更新継続許可部１４がソフトウェアの更新継続を許可しなければ、ソフトウェア更新制御部１１は、記憶装置９１のソフトウェアの書き換えを継続することができない。

＜車両用制御装置のハードウェア構成＞
図２は、実施の形態１に係る車両用制御装置１００のハードウェア構成図である。車両用制御装置１００の各機能は、車両用制御装置１００が備えた処理回路により実現される。具体的には、車両用制御装置１００は、図２に示すように、処理回路として、ＣＰＵ（Central Processing Unit）などの演算処理装置９０（コンピュータ）、演算処理装置９０とデータのやり取りする記憶装置９１、演算処理装置９０に外部の信号を入力する入力回路９２、演算処理装置９０から外部に信号を出力する出力回路９３、及び通信路９８を介してデータを送受信する通信部９９などのインターフェースを備えている。

演算処理装置９０として、ＡＳＩＣ（Application Specific Integrated Circuit）、ＩＣ（Integrated Circuit）、ＤＳＰ（Digital Signal Processor）、ＦＰＧＡ（Field Programmable Gate Array）、各種の論理回路、及び各種の信号処理回路などが備えられてもよい。演算処理装置９０にはＳｏＣ（System on a Chip）技術が適用されてもよい。また、演算処理装置９０として、同じ種類のものまたは異なる種類のものが複数備えられ、各処理が分担して実行されてもよい。車両用制御装置１００には、記憶装置９１として、演算処理装置９０からデータを読み出し及び書き込みが可能に構成されたＲＡＭ（Random Access Memory）、演算処理装置９０からデータを読み出し可能に構成されたＲＯＭ（Read Only Memory）などが備えられている。記憶装置９１は、演算処理装置９０に内蔵されていてもよい。入力回路９２は、入力信号、センサ、スイッチが接続され、これら入力信号、センサ、スイッチの信号を演算処理装置９０に入力するＡ／Ｄ変換器などを備えている。出力回路９３は、スイッチング素子をオンオフ駆動するゲート駆動回路などの電気負荷が接続され、これら電気負荷に演算処理装置９０から制御信号を出力する駆動回路などを備えている。通信部９９は通信路９８を介して外部の制御装置などの外部装置とデータのやり取りを行うことができる。

車両用制御装置１００が備える各機能は、演算処理装置９０が、ＲＯＭなどの記憶装置９１に記憶されたソフトウェア（プログラム）を実行し、記憶装置９１、入力回路９２、及び出力回路９３などの車両用制御装置１００の他のハードウェアと協働することにより実現される。なお、車両用制御装置１００が用いる閾値、判定値などの設定データは、ソフトウェア（プログラム）の一部として、ＲＯＭなどの記憶装置９１に記憶されている。車両用制御装置１００の有する各機能は、それぞれソフトウェアのモジュールで構成されるものであってもよいが、ソフトウェアとハードウェアの組み合わせによって構成されるものであってもよい。

＜ソフトウェア更新開始処理＞
図３は、実施の形態１に係る車両用制御装置１００のソフトウェア更新開始処理を示すフローチャートである。図３のフローチャートでは、車両用制御装置１００の各機能ブロックが動作する流れについて説明する。

図３のフローチャートの処理は、所定時間ごとに実行される（例えば１０ｍｓごと）。図３のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、または車両用制御装置１００がサーバからデータを受信するたび、といったイベントごとに実行されることとしてもよい。

処理が開始され、ステップＳ１０１で、受信部１８がサーバから更新ソフトウェアを受信したかどうか判定する。更新ソフトウェアを受信していない場合（判定はＮＯ）は、処理を終了する。更新ソフトウェアを受信した場合（判定はＹＥＳ）は、ステップＳ１０２へ進む。

ステップＳ１０２では、ソフトウェア更新電力算出部１２にて更新用ソフトウェアに対し記憶装置への書き換え実行に必要なソフトウェア更新電力ＥＰｒｖを算出する。っして、ステップＳ１０３では、電源残容量検出部１５によって、バッテリの電源残容量ＥＰｒを検出する。

ステップＳ１０４では、ソフトウェア更新開始許可部１３によって電源残容量ＥＰｒがソフトウェア更新電力ＥＰｒｖよりも大きいかどうか判定される。電源残容量ＥＰｒがソフトウェア更新電力ＥＰｒｖ以下であれば（判定はＮＯ）ステップＳ１０７へ進む。電源残容量ＥＰｒがソフトウェア更新電力ＥＰｒｖよりも大きい場合（判定はＹＥＳ）は、ステップＳ１０５へ進む。ソフトウェア更新開始許可部１３によってソフトウェア更新開始が許可される場合である。

ステップＳ１０５では、ソフトウェア更新中フラグをセットする。ソフトウェア更新中フラグは現在ソフトウェアの記憶装置９１への書き換えを実行中であることを示すフラグである。ソフトウェア更新中フラグは、車両用制御装置の起動時などに初期設定としてクリアされるものとする。

ステップＳ１０６では、ソフトウェアの更新を開始する。ソフトウェア更新制御部１１は、記憶装置９１のソフトウェアの書き換えを開始する。その後処理を終了する。

ステップＳ１０７は、ソフトウェア更新開始許可部１３によってソフトウェア更新開始が許可されない場合であり、ソフトウェア更新中フラグをクリアする。その後処理を終了する。

＜ソフトウェア更新継続処理＞
図４は、実施の形態１に係る車両用制御装置１００のソフトウェア更新継続処理を示すフローチャートである。図４のフローチャートでは、ソフトウェア更新を実施中の車両用制御装置１００の各機能ブロックが動作する流れについて説明する。

図４のフローチャートの処理は、所定時間ごとに実行される（例えば１０ｍｓごと、３０秒ごとなど）。図４のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、といったイベントごとに実行されることとしてもよい。

処理が開始され、ステップＳ２０１で、ソフトウェア更新中フラグがセットされているかどうか判定する。ソフトウェア更新中フラグがセットされていない場合（判定はＮＯ）は、処理を終了する。ソフトウェア更新中フラグがセットされている場合（判定はＹＥＳ）は、ステップＳ２０２へ進む。

ステップＳ２０２では、電源残容量低下検出部１６によって電源残容量低下量ΔＥＰｒが検出される。そして、ステップＳ２０３にて、電源残容量低下検出部１６によって検出された電源残容量低下量ΔＥＰｒが予め定められた低下判定値ΔＥＰｊ以上かどうか判定される。電源残容量低下量ΔＥＰｒが低下判定値ΔＥＰｊ以上の場合（判定はＹＥＳ）は、ステップＳ２１２へ進む。ソフトウェア更新継続許可部１４がソフトウェアの更新継続を許可しない場合である。

ステップＳ２０３で、電源残容量低下量ΔＥＰｒが低下判定値ΔＥＰｊ未満の場合（判定はＮＯ）は、ステップＳ２０９へ進む。ソフトウェア更新継続許可部１４がソフトウェアの更新継続を許可する場合である。

ステップＳ２０９で、ソフトウェア更新制御部１１は、ソフトウェア更新が完了しているかどうか判定する。記憶装置９１への更新ソフトウェアの書き換えが完了しているかどうか判定する。ソフトウェア更新が完了していない場合（判定はＮＯ）処理を終了する。ソフトウェア更新中であり、そのままソフトウェア更新を継続することとなる。

ステップＳ２０９で、ソフトウェア更新が完了している場合（判定はＹＥＳ）は、ステップＳ２１０へ進む。ステップＳ２１０では、ソフトウェア更新フラグをクリアする。そして、ステップＳ２１１で、ソフトウェアの更新完了をサーバへ通知するように、送信部１９へ指示し、処理を終了する。

ステップＳ２１２では、ソフトウェア更新中フラグをクリアする。そして、ステップＳ２１３でソフトウェア更新制御部１１によるソフトウェア更新を中止する。ステップＳ２１４で、ソフトウェアの更新中止をサーバへ通知するように、送信部１９へ指示し、処理を終了する。

実施の形態１に係る車両用制御装置１００は、上記のように構成したので、バッテリ２０の経年劣化、電極への電界物質の付着、車両の電力消費の急増などの要因によって容量が急減する場合に対応することができる。このような場合の電源残容量低下量ΔＥＰｒを検出することによって、バッテリ２０の状態の予想外の変化に適切な対応を可能とする。これによって、車両用制御装置１００の異常動作を防止し、安定性の高いソフトウェアの更新が可能となる。

２．実施の形態２
実施の形態２に係る車両用制御装置は図１、図２に示す車両用制御装置１００の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態２に係る車両用制御装置１００を実現できるが、ハードウェアの変更を伴っていてもよい。

実施の形態２に係る車両用制御装置１００は、実施の形態１に対してソフトウェア更新継続処理において、ソフトウェア更新継続許可部１４の判断がさらに追加されている部分が異なる。ソフトウェア更新電力算出部１２は、未書き込みの部分のソフトウェアの書き込みに必要な電力であるソフトウェア更新継続電力ＥＰｃｒｖを算出する。そして、ソフトウェア更新継続許可部１４は電源残容量低下量ΔＥＰｒに応じてこれを補正して、電源残容量ＥＰｒと比較する。ソフトウェア更新継続許可部１４は、電源残容量ＥＰｒが補正されたソフトウェア更新継続電力ＥＰｃｒｖよりも大きい場合にのみソフトウェア更新継続を許可する。

＜ソフトウェア更新継続許可＞
ソフトウェア更新継続許可部１４は、電源残容量低下検出部１６によって検出された電源残容量低下量ΔＥＰｒをあらかじめ定められた低下判定値ΔＥＰｊと比較する。電源残容量低下量ΔＥＰｒが低下判定値ΔＥＰｊよりも大きければ、ソフトウェア更新継続許可部１４はバッテリ２０の電源残容量がソフトウェア更新を完了できない可能性があると判断し、ソフトウェアの書き換え継続を許可しない。

さらに、ソフトウェア更新継続許可部１４はソフトウェア更新継続電力ＥＰｃｒｖを算出する。そして、電源残容量低下量ΔＥＰｒに応じて、ソフトウェア更新継続電力ＥＰｃｒｖを補正する。電源残容量低下量ΔＥＰｒが０未満であれば（電源残容量が低下していなければ）ソフトウェア更新継続電力ＥＰｃｒｖは補正せずにそのまま使用する。

電源残容量低下量ΔＥＰｒが０以上の場合（電源残容量が低下している場合）電源残容量低下量ΔＥＰｒを予め定められた低下判定値ΔＥＰｊと比較する。電源残容量低下量ΔＥＰｒが低下判定値ΔＥＰｊ以下であれば、電源残容量低下量ΔＥＰｒに応じた関数でソフトウェア更新継続電力ＥＰｃｒｖを増大させる。電源残容量低下量ΔＥＰｒが低下判定値ΔＥＰｊより大きければ、ソフトウェア更新継続電力ＥＰｃｒｖを予め定めた電源残容量低下時増大割合ＧＥＰ乗じて増大させる。

そして、電源残容量ＥＰｒが補正されたまたは補正無しのソフトウェア更新継続電力ＥＰｃｒｖより大きければ、ソフトウェア更新継続許可部１４はソフトウェアの書き換え継続を許可する。

＜ソフトウェア更新継続処理＞
図５は、実施の形態２に係る車両用制御装置１００のソフトウェア更新継続処理を示す第一のフローチャートである。図６は、実施の形態２に係る車両用制御装置１００のソフトウェア更新継続処理を示す第二のフローチャートである。図６のフローチャートは図５のフローチャートの続きを示している。

実施の形態２に係る図５、図６に示したフローチャートは、実施の形態１に係る図４のフローチャートに対し、ステップＳ２０２、ステップＳ２０３が、図５のステップＳ２２２から図６のステップＳ２２８に置換された部分が異なる。以下、異なる部分について説明する。

ステップＳ２２２では、電源残容量低下量ΔＥＰｒを検出し、電源残容量ＥＰｒを検出し、ソフトウェア更新継続電力ＥＰｃｒｖを算出する。そしてステップＳ２２３へ進み、電源残容量低下量ΔＥＰｒが予め定められた低下判定値ΔＥＰｊ以上かどうか判定する。電源残容量低下量ΔＥＰｒが低下判定値ΔＥＰｊ以上の場合（判定はＹＥＳ）は、図６のステップＳ２１２へ進んでソフトウェア更新中止の一連の処理を行う。ソフトウェア更新継続許可部１４がソフトウェアの更新継続を許可しない場合である。

ステップＳ２２３で、電源残容量低下量ΔＥＰｒが低下判定値ΔＥＰｊ未満の場合（判定はＮＯ）は、ステップＳ２２４へ進む。ステップＳ２２４では、電源残容量低下量ΔＥＰｒが０より小さいかどうか判定する。電源残容量低下量ΔＥＰｒが０より小さい場合（判定はＹＥＳ）は、電源残容量がマイナスである（電源残容量が増加している）場合である。バッテリ２０が充電されている場合がこれに相当する。この場合は、ソフトウェア更新継続電力ＥＰｃｒｖに補正を加えずに図６のステップＳ２２８へ進む。

ステップＳ２２４で、電源残容量低下量ΔＥＰｒが０より小さくない場合（判定はＮＯ）は、ステップＳ２２５へ進む。ステップＳ２２５では、電源残容量低下量ΔＥＰｒが予め定めた第二の低下判定値ΔＥＰｊ２以下かどうか判定する。電源残容量低下量ΔＥＰｒが第二の低下判定値ΔＥＰｊ２以下でない場合（判定はＮＯ）は、ステップＳ２２７へ進む。

ステップＳ２２７では、ソフトウェア更新継続電力ＥＰｃｒｖに予め定められた電源残容量低下時増大割合ＧＥＰを乗じて、増大補正を実施する。そして、図６のステップＳ２２８へ進む。

ステップＳ２２５で、電源残容量低下量ΔＥＰｒが第二の低下判定値ΔＥＰｊ２以下である場合（判定はＹＥＳ）は、ステップＳ２２６へ進む。ステップＳ２２６では、ソフトウェア更新継続電力ＥＰｃｒｖに電源残容量低下量ΔＥＰｒに応じた関数を乗じて、増大補正を実施する。そして、図６のステップＳ２２８へ進む。

図６のステップＳ２２８では、電源残容量ＥＰｒがソフトウェア更新継続電力ＥＰｃｒｖより大きいかどうか判定する。電源残容量ＥＰｒがソフトウェア更新継続電力ＥＰｃｒｖより大きくない場合（判定はＮＯ）は、ステップＳ２１２へ進んでソフトウェア更新中止の一連の処理を行う。

図６のステップＳ２２８で電源残容量ＥＰｒがソフトウェア更新継続電力ＥＰｃｒｖより大きい場合（判定はＹＥＳ）は、ステップＳ２０９へ進んでソフトウェア更新が完了しているかどうか判定する。

実施の形態２に係る車両用制御装置１００は、上記のように構成したので、電源残容量低下量ΔＥＰｒに応じて、ソフトウェア更新継続電力ＥＰｃｒｖを補正し、ソフトウェア更新の継続が可能かどうかきめ細かく判断することができる。これによって、バッテリ２０の状態の予想外の変化に適切な対応を可能とし、ソフトウェアの更新が可能な場合は、ソフトウェアの更新を継続することができる。これによって、車両用制御装置１００の異常動作を防止し、安定性の高いソフトウェアの更新の機会を増やすことが可能となる。

３．実施の形態３
実施の形態３に係る車両用制御装置は図１、図２に示す車両用制御装置１００の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態３に係る車両用制御装置１００を実現できるが、ハードウェアの変更を伴っていてもよい。

＜電源電圧、電源電圧低下量の検出＞
実施の形態３に係る車両用制御装置１００は、実施の形態２に対してソフトウェア更新継続処理において、電源残容量低下検出部１６の検出をバッテリ２０の電源電圧Ｖｂ、電源電圧低下量ΔＶｂに基づいて実施する。この場合について具体的に説明する。電源電圧低下量ΔＶｂは、ソフトウェア更新開始時点の電源電圧からの電圧低下量である。ここでは、バッテリ２０の電源電圧低下量判定値ΔＶｂｎｇ、上側電圧Ｖｂｈ、下側電圧Ｖｂｌを予め定めておくこととする。

電源電圧低下量判定値ΔＶｂｎｇは、ソフトウェア更新開始時点の電源電圧Ｖｂからの低下量判定値であり、例えば１．５Ｖと設定する。この判定値を超えて電源電圧が低下した場合は、ソフトウェアの更新を中止する。上側電圧Ｖｂｈは例えば１２．５Ｖ、下側電圧Ｖｂｌは例えば１１．５Ｖと設定する。これらの具体的な値は上記に限定されず、実験等によって最適な値に決定してもよい。

電源電圧Ｖｂが上側電圧Ｖｂｈ以上の場合は異常な電源電圧の低下はないとして、ソフトウェア更新継続電力ＥＰｃｒｖを増大補正しない。そして、ソフトウェア更新継続電力ＥＰｃｒｖをそのまま電源残容量ＥＰｒと比較する。

電源電圧Ｖｂが下側電圧Ｖｂｌ以上で上側電圧Ｖｂｈ未満の場合は、ソフトウェア更新開始時点の電源電圧Ｖｂからの電源電圧低下量ΔＶｂに応じてソフトウェア更新継続電力ＥＰｃｒｖを増大補正する。例えば、電圧が０．１Ｖ降下する度にソフトウェア更新継続電力ＥＰｃｒｖを５％増大させる。増大補正後のソフトウェア更新継続電力ＥＰｃｒｖを電源残容量ＥＰｒと比較する。

電源電圧Ｖｂが下側電圧Ｖｂｌ未満の場合は、ソフトウェア更新継続電力ＥＰｃｒｖを１００％増大補正する。増大補正後のソフトウェア更新継続電力ＥＰｃｒｖを電源残容量ＥＰｒと比較する。

そして、ソフトウェア更新継続電力ＥＰｃｒｖを電源残容量ＥＰｒと比較して、電源残容量ＥＰｒのほうが大きい場合にソフトウェア更新の許可をする。このようにすることによって、電源電圧Ｖｂ、電源電圧低下量ΔＶｂの検出によって、ソフトウェアの更新継続の可否を決定することができる。

＜ソフトウェア更新継続処理＞
図７は、実施の形態３に係る車両用制御装置１００のソフトウェア更新継続処理を示す第一のフローチャートである。図７のフローチャートの続きは、実施の形態２に係る図６のフローチャートをそのまま流用する。

以下、図７のフローチャートについて説明する。図７のフローチャートは所定時間ごとに実行される（例えば１０ｍｓごと、３０秒ごとなど）。図７のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、といったイベントごとに実行されることとしてもよい。

処理が開始され、ステップＳ２０１で、ソフトウェア更新中フラグがセットされているかどうか判定する。ソフトウェア更新中フラグがセットされていない場合（判定はＮＯ）は、処理を終了する。ソフトウェア更新中フラグがセットされている場合（判定はＹＥＳ）は、ステップＳ２３２へ進む。

ステップＳ２３２では、電源電圧Ｖｂ、電源電圧低下量ΔＶｂを検出する。そして、電源残容量低下量ΔＥＰｒを検出し、電源残容量ＥＰｒを検出し、ソフトウェア更新継続電力ＥＰｃｒｖを算出する。

そしてステップＳ２３３へ進み、電源電圧低下量ΔＶｂが電源電圧低下量判定値ΔＶｂｎｇ以上かどうか判定する。電源電圧低下量ΔＶｂが電源電圧低下量判定値ΔＶｂｎｇ以上の場合（判定はＹＥＳ）は、図６のステップＳ２１２へ進んでソフトウェア更新中止の一連の処理を行う。ソフトウェア更新継続許可部１４がソフトウェアの更新継続を許可しない場合である。

ステップＳ２３３で電源電圧低下量ΔＶｂが電源電圧低下量判定値ΔＶｂｎｇ未満の場合（判定はＮＯ）は、ステップＳ２３４へ進む。ステップＳ２３４では、電源電圧Ｖｂが上側電圧Ｖｂｈ以上であるかどうか判定する。電源電圧Ｖｂが上側電圧Ｖｂｈ以上の場合（判定はＹＥＳ）は、異常な電源電圧の低下はない場合である。この場合は、ソフトウェア更新継続電力ＥＰｃｒｖに補正を加えずに図６のステップＳ２２８へ進む。

ステップＳ２３４で、電源電圧Ｖｂが上側電圧Ｖｂｈ未満の場合（判定はＮＯ）は、ステップＳ２３５へ進む。ステップＳ２３５では、電源電圧Ｖｂが下側電圧Ｖｂｌ未満かどうか判定する。電源電圧Ｖｂが下側電圧Ｖｂｌ未満の場合（判定はＹＥＳ）は、ステップＳ２３７へ進む。

ステップＳ２３７では、ソフトウェア更新継続電力ＥＰｃｒｖを１００％増大する（二倍にする）増大補正を実施する。そして、図６のステップＳ２２８へ進む。

ステップＳ２３５で、電源電圧Ｖｂが下側電圧Ｖｂｌ以上である場合（判定はＮＯ）は、ステップＳ２３６へ進む。ステップＳ２３６では、ソフトウェア更新継続電力ＥＰｃｒｖに電源電圧低下量ΔＶｂに対して０．１Ｖ低下の度に５％増大する増大補正を実施する。すなわち、（１＋ΔＶｂ×０．５）を乗ずる補正となる。そして、図６のステップＳ２２８へ進む。

実施の形態３に係る車両用制御装置１００は、上記のように構成したので、電源電圧Ｖｂ、電源電圧低下量ΔＶｂの検出によって、ソフトウェアの更新継続の可否を決定することができる。電源電圧低下量ΔＶｂに応じて、ソフトウェア更新継続電力ＥＰｃｒｖを補正し、ソフトウェア更新の継続が可能かどうかきめ細かく判断することができる。簡単な手法で、車両用制御装置１００の異常動作を防止し、安定性の高いソフトウェアの更新の機会を増やすことが可能となる。

４．実施の形態４
実施の形態４に係る車両用制御装置は図１、図２に示す車両用制御装置１００の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態４に係る車両用制御装置１００を実現できるが、ハードウェアの変更を伴っていてもよい。

＜コールドクランキング電流の検出＞
実施の形態４に係る車両用制御装置１００は、実施の形態２に対してソフトウェア更新継続処理において、電源残容量低下検出部１６の検出をバッテリ２０のコールドクランキング電流であるＣＣＡに基づいて実施する。この場合について具体的に説明する。

ＣＣＡは、米国のバッテリに関する規格によって定められた評価基準である。－１８℃の環境下で、３０秒間定格電流を流した場合に７．２Ｖ以上の端子電圧を有することが規定されている。例えば、ＣＣＡ６３０Ａは、－１８℃環境下で、６３０Ａの電流を３０秒流し続け、端子電圧７．２Ｖ以上を確保するバッテリの能力のことである。

放電して電源残容量が減少したバッテリのＣＣＡであるクランキング電流Ｉｃｃと、製造されたばかりで満充電されたバッテリのＣＣＡであるクランキング電流初期値Ｉｃｃｉｎの比率を、ＣＣＡ比率Ｒｃｃａと定義する（Ｒｃｃａ＝Ｉｃｃ／Ｉｃｃｉｎｉ）。ＣＣＡ比率低下量ΔＲｃｃａを、ソフトウェア更新開始時点のＣＣＡ比率Ｒｃｃａｓｔに対する現在のＣＣＡ比率Ｒｃｃａとの差として、ΔＲｃｃａ＝Ｒｃｃａｓｔ－Ｒｃｃａと定義することができる。（Ｉｃｃ、Ｉｃｃｉｎｉ、Ｒｃｃａｓｔは不図示）

ＣＣＡを計測するためには、コンダクタンス法、インピーダンス法、レジスタンス法などが存在する。ＣＣＡは、ＣＣＡ計測用のテスターによって簡便に確認することも可能である。

実施の形態４に係る車両用制御装置１００では、バッテリ２０の電源残容量ＥＰｒを、コールドクランキング電流ＣＣＡ、ＣＣＡ比率Ｒｃｃａ、ＣＣＡ比率低下量ΔＲｃｃａに基づいて確認する。ここでは、ＣＣＡ低下量判定値ΔＲｃｃａｎｇ、ＣＣＡ上側比率Ｒｃｃａｈ、ＣＣＡ下側比率Ｒｃｃａｌを予め定めておくこととする。

ＣＣＡ低下量判定値ΔＲｃｃａｎｇは、ソフトウェア更新開始時点のＣＣＡ比率ＲｃｃａからのＣＣＡ比率低下量ΔＲｃｃａの判定値であり、例えば３５％と設定する。この判定値を超えてＣＣＡ比率低下量ΔＲｃｃａが増大した場合は、ソフトウェアの更新を中止する。ＣＣＡ上側比率Ｒｃｃａｈは例えば１００％、ＣＣＡ下側比率Ｒｃｃａｌは例えば７０％と設定する。これらの具体的な値は上記に限定されず、実験等によって最適な値に決定してもよい。

ＣＣＡ比率ＲｃｃａがＣＣＡ上側比率Ｒｃｃａｈ以上の場合は異常な電源残容量の低下はないとして、ソフトウェア更新継続電力ＥＰｃｒｖを増大補正しない。そして、ソフトウェア更新継続電力ＥＰｃｒｖをそのまま電源残容量ＥＰｒと比較する。

ＣＣＡ比率ＲｃｃａがＣＣＡ下側比率Ｒｃｃａｌ以上でＣＣＡ上側比率Ｒｃｃａｈ未満の場合は、ソフトウェア更新開始時点のＣＣＡ比率ＲｃｃａｓｔからのＣＣＡ比率低下量ΔＲｃｃａに応じてソフトウェア更新継続電力ＥＰｃｒｖを増大補正する。例えば、ＣＣＡ比率Ｒｃｃａが低下する度にソフトウェア更新継続電力ＥＰｃｒｖをＣＣＡ比率低下量ΔＲｃｃａの低下した割合だけ増大させる。増大補正後のソフトウェア更新継続電力ＥＰｃｒｖを電源残容量ＥＰｒと比較する。

ＣＣＡ比率ＲｃｃａがＣＣＡ下側比率Ｒｃｃａｌ未満の場合は、ソフトウェア更新継続電力ＥＰｃｒｖを１００％増大補正する。増大補正後のソフトウェア更新継続電力ＥＰｃｒｖを電源残容量ＥＰｒと比較する。

そして、ソフトウェア更新継続電力ＥＰｃｒｖを電源残容量ＥＰｒと比較して、電源残容量ＥＰｒのほうが大きい場合にソフトウェア更新の許可をする。このようにすることによって、ＣＣＡ比率Ｒｃｃａ、ＣＣＡ比率低下量ΔＲｃｃａの検出によって、ソフトウェアの更新継続の可否を決定することができる。

＜ソフトウェア更新継続処理＞
図８は、実施の形態４に係る車両用制御装置１００のソフトウェア更新継続処理を示す第一のフローチャートである。図８のフローチャートの続きは、実施の形態２に係る図６のフローチャートをそのまま流用する。

以下、図８のフローチャートについて説明する。図８のフローチャートは所定時間ごとに実行される（例えば１０ｍｓごと、３０秒ごとなど）。図８のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、といったイベントごとに実行されることとしてもよい。

処理が開始され、ステップＳ２０１で、ソフトウェア更新中フラグがセットされているかどうか判定する。ソフトウェア更新中フラグがセットされていない場合（判定はＮＯ）は、処理を終了する。ソフトウェア更新中フラグがセットされている場合（判定はＹＥＳ）は、ステップＳ２４２へ進む。

ステップＳ２４２では、ＣＣＡ比率Ｒｃｃａ、ＣＣＡ比率低下量ΔＲｃｃａを検出する。そして、電源残容量ＥＰｒを検出し、ソフトウェア更新継続電力ＥＰｃｒｖを算出する。

そしてステップＳ２４３へ進み、ＣＣＡ比率低下量ΔＲｃｃａがＣＣＡ低下量判定値ΔＲｃｃａｎｇ以上かどうか判定する。ＣＣＡ比率低下量ΔＲｃｃａがＣＣＡ低下量判定値ΔＲｃｃａｎｇ以上の場合（判定はＹＥＳ）は、図６のステップＳ２１２へ進んでソフトウェア更新中止の一連の処理を行う。ソフトウェア更新継続許可部１４がソフトウェアの更新継続を許可しない場合である。

ステップＳ２４３でＣＣＡ比率低下量ΔＲｃｃａがＣＣＡ低下量判定値ΔＲｃｃａｎｇ未満の場合（判定はＮＯ）は、ステップＳ２４４へ進む。ステップＳ２４４では、ＣＣＡ比率ＲｃｃａがＣＣＡ上側比率Ｒｃｃａｈ以上であるかどうか判定する。ＣＣＡ比率ＲｃｃａがＣＣＡ上側比率Ｒｃｃａｈ以上の場合（判定はＹＥＳ）は、異常な電源電圧の低下はない場合である。この場合は、ソフトウェア更新継続電力ＥＰｃｒｖに補正を加えずに図６のステップＳ２２８へ進む。

ステップＳ２４４で、ＣＣＡ比率ＲｃｃａがＣＣＡ上側比率Ｒｃｃａｈ未満の場合（判定はＮＯ）は、ステップＳ２４５へ進む。ステップＳ２４５では、ＣＣＡ比率ＲｃｃａがＣＣＡ下側比率Ｒｃｃａｌ未満かどうか判定する。ＣＣＡ比率ＲｃｃａがＣＣＡ下側比率Ｒｃｃａｌ未満の場合（判定はＹＥＳ）は、ステップＳ２４７へ進む。

ステップＳ２４７では、ソフトウェア更新継続電力ＥＰｃｒｖを１００％増大する（二倍にする）増大補正を実施する。そして、図６のステップＳ２２８へ進む。

ステップＳ２４５で、ＣＣＡ比率ＲｃｃａがＣＣＡ下側比率Ｒｃｃａｌ以上である場合（判定はＮＯ）は、ステップＳ２４６へ進む。ステップＳ２４６では、ソフトウェア更新継続電力ＥＰｃｒｖにＣＣＡ比率低下量ΔＲｃｃａの低下割合分の増大補正を実施する。すなわち、（１＋ΔＲｃｃａ）を乗ずる補正となる。そして、図６のステップＳ２２８へ進む。

実施の形態４に係る車両用制御装置１００は、上記のように構成したので、ＣＣＡ比率Ｒｃｃａ、ＣＣＡ比率低下量ΔＲｃｃａの検出によって、ソフトウェアの更新継続の可否を決定することができる。ＣＣＡ比率低下量ΔＲｃｃａに応じて、ソフトウェア更新継続電力ＥＰｃｒｖを補正し、ソフトウェア更新の継続が可能かどうかきめ細かく判断することができる。車両用制御装置１００の異常動作を防止し、安定性の高いソフトウェアの更新の機会を増やすことが可能となる。

５．実施の形態５
実施の形態５に係る車両用制御装置は図１、図２に示す車両用制御装置１００の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態５に係る車両用制御装置１００を実現できるが、ハードウェアの変更を伴っていてもよい。

＜バッテリ液比重の検出＞
実施の形態５に係る車両用制御装置１００は、実施の形態２に対してソフトウェア更新継続処理において、電源残容量低下検出部１６の検出をバッテリ２０のバッテリ液比重ＳＧに基づいて実施する。この場合について具体的に説明する。

バッテリ液比重ＳＧは、バッテリの充電状態と相関を有する。よってバッテリ液比重ＳＧを検出することによって、電源残容量ＥＰｒの算出をすることが可能である。

実施の形態５に係る車両用制御装置１００では、バッテリ２０の電源残容量ＥＰｒを、バッテリ液比重ＳＧ、バッテリ液比重低下量ΔＳＧに基づいて確認する。ここでは、バッテリ液比重低下量判定値ΔＳＧｎｇ、バッテリ液上側比重ＳＧｈ、バッテリ液下側比重ＳＧｌを予め定めておくこととする。

バッテリ液比重低下量判定値ΔＳＧｎｇは、ソフトウェア更新開始時点のバッテリ液比重ＳＧからのバッテリ液比重低下量ΔＳＧの判定値であり、例えば０．０８と設定する。この判定値を超えてバッテリ液比重低下量ΔＳＧが増大した場合は、ソフトウェアの更新を中止する。バッテリ液上側比重ＳＧｈは例えば１．２８、バッテリ液下側比重ＳＧｌは例えば１．２１と設定する。これらの具体的な値は上記に限定されず、実験等によって最適な値に決定してもよい。

バッテリ液比重ＳＧがバッテリ液上側比重ＳＧｈ以上の場合は異常な電源残容量の低下はないとして、ソフトウェア更新継続電力ＥＰｃｒｖを増大補正しない。そして、ソフトウェア更新継続電力ＥＰｃｒｖをそのまま電源残容量ＥＰｒと比較する。

バッテリ液比重ＳＧがバッテリ液下側比重ＳＧｌ以上でバッテリ液上側比重ＳＧｈ未満の場合は、ソフトウェア更新開始時点のバッテリ液比重ＳＧからのバッテリ液比重低下量ΔＳＧに応じてソフトウェア更新継続電力ＥＰｃｒｖを増大補正する。例えば、バッテリ液比重ＳＧが０．０１低下する度にソフトウェア更新継続電力ＥＰｃｒｖを７％増大させる。増大補正後のソフトウェア更新継続電力ＥＰｃｒｖを電源残容量ＥＰｒと比較する。

バッテリ液比重ＳＧがバッテリ液下側比重ＳＧｌ未満の場合は、ソフトウェア更新継続電力ＥＰｃｒｖを１００％増大補正する。増大補正後のソフトウェア更新継続電力ＥＰｃｒｖを電源残容量ＥＰｒと比較する。

そして、ソフトウェア更新継続電力ＥＰｃｒｖを電源残容量ＥＰｒと比較して、電源残容量ＥＰｒのほうが大きい場合にソフトウェア更新の許可をする。このようにすることによって、バッテリ液比重ＳＧ、バッテリ液比重低下量ΔＳＧの検出によって、ソフトウェアの更新継続の可否を決定することができる。

＜ソフトウェア更新継続処理＞
図９は、実施の形態５に係る車両用制御装置１００のソフトウェア更新継続処理を示す第一のフローチャートである。図９のフローチャートの続きは、実施の形態２に係る図６のフローチャートをそのまま流用する。

以下、図９のフローチャートについて説明する。図９のフローチャートは所定時間ごとに実行される（例えば１０ｍｓごと、３０秒ごとなど）。図９のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、といったイベントごとに実行されることとしてもよい。

処理が開始され、ステップＳ２０１で、ソフトウェア更新中フラグがセットされているかどうか判定する。ソフトウェア更新中フラグがセットされていない場合（判定はＮＯ）は、処理を終了する。ソフトウェア更新中フラグがセットされている場合（判定はＹＥＳ）は、ステップＳ２５２へ進む。

ステップＳ２５２では、バッテリ液比重ＳＧ、バッテリ液比重低下量ΔＳＧを検出する。そして、電源残容量ＥＰｒを検出し、ソフトウェア更新継続電力ＥＰｃｒｖを算出する。

そしてステップＳ２５３へ進み、バッテリ液比重低下量ΔＳＧがバッテリ液比重低下量判定値ΔＳＧｎｇ以上かどうか判定する。バッテリ液比重低下量ΔＳＧがバッテリ液比重低下量判定値ΔＳＧｎｇ以上の場合（判定はＹＥＳ）は、図６のステップＳ２１２へ進んでソフトウェア更新中止の一連の処理を行う。ソフトウェア更新継続許可部１４がソフトウェアの更新継続を許可しない場合である。

ステップＳ２５３でバッテリ液比重低下量ΔＳＧがバッテリ液比重低下量判定値ΔＳＧｎｇ未満の場合（判定はＮＯ）は、ステップＳ２５４へ進む。ステップＳ２５４では、バッテリ液比重ＳＧがバッテリ液上側比重ＳＧｈ以上であるかどうか判定する。バッテリ液比重ＳＧがバッテリ液上側比重ＳＧｈ以上の場合（判定はＹＥＳ）は、異常な電源電圧の低下はない場合である。この場合は、ソフトウェア更新継続電力ＥＰｃｒｖに補正を加えずに図６のステップＳ２２８へ進む。

ステップＳ２５４で、バッテリ液比重ＳＧがバッテリ液上側比重ＳＧｈ未満の場合（判定はＮＯ）は、ステップＳ２５５へ進む。ステップＳ２４５では、バッテリ液比重ＳＧがバッテリ液下側比重ＳＧｌ未満かどうか判定する。バッテリ液比重ＳＧがバッテリ液下側比重ＳＧｌ未満の場合（判定はＹＥＳ）は、ステップＳ２５７へ進む。

ステップＳ２５７では、ソフトウェア更新継続電力ＥＰｃｒｖを１００％増大する（二倍にする）増大補正を実施する。そして、図６のステップＳ２２８へ進む。

ステップＳ２５５で、バッテリ液比重ＳＧがバッテリ液下側比重ＳＧｌ以上である場合（判定はＮＯ）は、ステップＳ２５６へ進む。ステップＳ２５６では、ソフトウェア更新継続電力ＥＰｃｒｖにバッテリ液比重低下量ΔＳＧが０．０１増えるごとにソフトウェア更新継続電力ＥＰｃｒｖを７％増大する補正を実施する。すなわち、（１＋ΔＳＧ×７）を乗ずる補正となる。そして、図６のステップＳ２２８へ進む。

実施の形態５に係る車両用制御装置１００は、上記のように構成したので、バッテリ液比重ＳＧ、バッテリ液比重低下量ΔＳＧの検出によって、ソフトウェアの更新継続の可否を決定することができる。バッテリ液比重低下量ΔＳＧに応じて、ソフトウェア更新継続電力ＥＰｃｒｖを補正し、ソフトウェア更新の継続が可能かどうかきめ細かく判断することができる。車両用制御装置１００の異常動作を防止し、安定性の高いソフトウェアの更新の機会を増やすことが可能となる。

６．実施の形態６
実施の形態６に係る車両用制御装置１００は図１、図２に示す車両用制御装置１００の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態６に係る車両用制御装置１００を実現できるが、ハードウェアの変更を伴っていてもよい。

＜バッテリの使用年数超過＞
実施の形態６に係る車両用制御装置１００は、実施の形態２に対してソフトウェア更新継続処理において、電源残容量低下検出部１６の検出をバッテリの使用年数、バッテリ上がり履歴、走行状況に基づいて実施する。この場合について具体的に説明する。

車両に搭載しているバッテリ２０について、使用可能年数（製品の耐用年数）を５年以上超えて使用している場合がある。このような場合は、バッテリ２０が劣化していることが想定できる。そして、ソフトウェアの更新時に電源残容量ＥＰｒの急激な低下が発生する可能性がある。

ソフトウェア更新継続の判断において、ソフトウェア更新継続電力ＥＰｃｒｖを拡大補正することによって、電源残容量ＥＰｒとの比較時に余裕を持ってソフトウェア更新を進めることができる。このために、バッテリ使用可能年数を５年以上超過して使用している場合は、ソフトウェア更新継続電力ＥＰｃｒｖを１００％増大補正することとする。

＜バッテリ上がり履歴＞
車両用の鉛蓄電池に代表されるバッテリは、電源残容量が過小となって電圧低下を生じる程度まで放電すると、電池内部に不可逆的変化が発生して再充電しても当初の性能まで復帰できない場合がある。このような状況を考慮して、バッテリ上がりの履歴を２回以上有する場合はバッテリの劣化が想定できる。この場合も、ソフトウェアの更新時に電源残容量ＥＰｒの急激な低下が発生する可能性がある。

ソフトウェア更新継続の判断において、ソフトウェア更新継続電力ＥＰｃｒｖを拡大補正することによって、電源残容量ＥＰｒとの比較時に余裕を持ってソフトウェア更新を進めることができる。このために、過去に２度以上のバッテリ上がり履歴を有する場合は、ソフトウェア更新継続電力ＥＰｃｒｖを１００％増大補正することとする。

＜長期間停車、短距離走行の繰り返し＞
車両の使用状況によって、バッテリ２０の状態は大きく変化する。１か月以上車両を動かしていない場合は、車両の原動機によってバッテリ２０を充電する機会がなく、電源残容量が大きく低下している場合が想定できる。また、車両を走行させている場合であっても、走行距離が２ｋｍ以内の移動を連続１０回以上行っている場合は、車両の原動機によってバッテリ２０を充分に充電する機会がなく、同じく電源残容量が大きく低下している場合が想定できる。この場合も、ソフトウェアの更新時に電源残容量ＥＰｒの急激な低下が発生する可能性がある。

ソフトウェア更新継続の判断において、ソフトウェア更新継続電力ＥＰｃｒｖを拡大補正することによって、電源残容量ＥＰｒとの比較時に余裕を持ってソフトウェア更新を進めることができる。このために、１か月以上車両を動かしていない場合、または走行距離が２ｋｍ以内の移動を連続１０回以上行っている場合は、ソフトウェア更新継続電力ＥＰｃｒｖを１００％増大補正することとする。

＜ソフトウェア更新継続処理＞
図１０は、実施の形態６に係る車両用制御装置１００のソフトウェア更新継続処理を示す第三のフローチャートである。図１０のフローチャートは、実施の形態２に係る図６の第二のフローチャートのステップＳ２２８の手前に挿入される。図１０のフローチャートの前には図５の第一のフローチャートが設けられており、図１０のフローチャートの後には図６の第二のフローチャートが設けられている。図５、図１０、図６のフローチャートの順に処理が実行される。図５、図６はそのまま流用するので、ここでは図１０について説明する。

図５の実施の形態２に係るソフトウェア更新継続処理を示す第一のフローチャートで、ソフトウェア更新継続電力ＥＰｃｒｖを算出し、必要に応じて拡大補正をする。その後、図１０のフローチャートのステップＳ２６１へ進む。

ステップＳ２６１では、バッテリ２０が車両に設置されてからの経過時間が、バッテリ２０の使用可能年数（耐久年数）に５年を加えた期間以上であるかどうかを判定する。ステップＳ２６１で、バッテリ経過時間（経時）が耐久年数＋5年未満の場合（判定はＮＯ）は、そのままステップＳ２６３へ進む。

ステップＳ２６１で、バッテリ経過時間（経時）が耐久年数＋5年以上の場合（判定はＹＥＳ）は、ステップＳ２６２へ進んでソフトウェア更新継続電力ＥＰｃｒｖを１００％増大補正する。その後ステップＳ２６３へ進む。

ステップＳ２６３では、バッテリ２０がバッテリ上がり２回以上の履歴を有するかどうか判定する。バッテリ上がり２回以上の履歴を有さない場合（判定はＮＯ）は、そのままステップＳ２６５へ進む。

ステップＳ２６３で、バッテリ上がり２回以上の履歴を有する場合（判定はＹＥＳ）は、ステップＳ２６４へ進んでソフトウェア更新継続電力ＥＰｃｒｖを１００％増大補正する。その後、ステップＳ２６５へ進む。

ステップＳ２６５では、車両の走行状態を判定する。車両が１カ月以上停車または、２ｋｍ以下の走行を１０回以上しているかどうか判定する。車両が１カ月以上停車しておらず、２ｋｍ以下の走行を１０回以上していない場合（判定はＮＯ）は、そのまま図６のステップＳ２２８へ進む。

ステップＳ２６５で、車両が１カ月以上停車または、２ｋｍ以下の走行を１０回以上している場合（判定はＹＥＳ）は、ステップＳ２６６へ進んでソフトウェア更新継続電力ＥＰｃｒｖを１００％増大補正する。その後、図６のステップＳ２２８へ進む。

以上のように構成することで、実施の形態６に係る車両用制御装置１００は、バッテリの使用年数超過、バッテリ上がり履歴、長期間停車、短距離走行の繰り返しなどの状況に際して、ソフトウェア更新継続電力ＥＰｃｒｖを補正し、ソフトウェア更新の継続が可能かどうかきめ細かく判断することができる。車両用制御装置１００の異常動作を防止し、安定性の高いソフトウェアの更新の機会を増やすことが可能となる。

なお、上記のバッテリの耐久年数を超過している判定時間の５年間、バッテリ上がりの履歴の判定回数の２回、停車判定期間の１カ月、短距離走行判定距離の２ｋｍ、単距離走行判定回数の１０回、は判定値の例であり、変更してもよい。さらに、ソフトウェア更新継続電力ＥＰｃｒｖの増大補正量である１００％は、補正量の例であり変更してもよい。これらは、実験、シミュレーションによって最適な判定値を見つけて決定してもよい。また、ステップＳ２６１、ステップＳ２６３、ステップＳ２６５に記載した判定の一部を省略してもよい。

７．実施の形態７
実施の形態７に係る車両用制御装置１００は図１、図２に示す車両用制御装置１００の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態７に係る車両用制御装置１００を実現できるが、ハードウェアの変更を伴っていてもよい。

＜ソフトウェア更新時間＞
実施の形態７に係る車両用制御装置１００は、実施の形態１に対してソフトウェア更新継続処理において、ソフトウェア書き込み完了までの時間Ｔｒｖを算出し、この時間Ｔｒｖが予め定めた書き込み完了時間Ｔｃｍｐ以下で完了する場合は、ソフトウェア更新中のソフトウェア更新継続許可部１４による、継続可否の判断を行わない。書き込み完了時間Ｔｃｍｐは例えば２分に設定してもよい。書き込み完了時間Ｔｃｍｐは、実験またはシミュレーションによって適切な値を設定してもよい。

このように、不必要なソフトウェアの更新継続可否判断を省略することで、ソフトウェア更新作業を効率的に短時間で完了することができる。また、不必要な処理を省略することができるので、バッテリ２０の電源残容量の無駄な消費を削減することができる。

＜ソフトウェア更新継続処理＞
図１１は、実施の形態７に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。実施の形態１に係る図４のソフトウェア更新継続処理を示すフローチャートのステップＳ２０１とステップＳ２０２の間に、新たにステップＳ２７１とステップＳ２７２を追加した部分のみが異なる。追加した部分を説明する。

図１１のステップＳ２０１で、ソフトウェア更新中フラグがセットされている場合、ステップＳ２７１へ進む。ステップＳ２７１では、ソフトウェア更新のために記憶装置９１の更新ソフトウェアの書き込み完了までの時間Ｔｒｖを算出する。そしてステップＳ２７２へ進む。

ステップＳ２７２では、書き込み完了までの時間Ｔｒｖが予め定めた書き込み完了時間Ｔｃｍｐ以下であるかどうか判定する。書き込み完了までの時間Ｔｒｖが書き込み完了時間Ｔｃｍｐ以下であれば、ステップＳ２０９へ進んでソフトウェア更新完了しているかどうか確認する。

このように構成することで、更新ソフトウェアの書き込み完了までの時間Ｔｒｖが書き込み完了時間Ｔｃｍｐ以下の場合は、電源残容量低下量ΔＥＰｒの確認などのソフトウェアの更新継続可否判断を省略することができる。

８．実施の形態８
実施の形態８に係る車両用制御装置１００は図１、図２に示す車両用制御装置１００の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態８に係る車両用制御装置１００を実現できるが、ハードウェアの変更を伴っていてもよい。

＜過剰電力を有する場合＞
実施の形態８に係る車両用制御装置１００は、実施の形態１に対してソフトウェア更新継続処理において、ソフトウェア更新開始処理において算出したソフトウェア更新電力ＥＰｒｖに予め定めた過剰電力ＥＰｅｘを加えた電力よりも、電源残容量ＥＰｒのほうが大きいかどうか判定する。電源残容量ＥＰｒが、ソフトウェア更新電力ＥＰｒｖよりも充分余裕を持っていれば（過剰電力ＥＰｅｘ分余裕を持つ）、ソフトウェア更新中のソフトウェア更新継続許可部１４による、継続可否の判断を行わない。過剰電力ＥＰｅｘは例えばバッテリ２０の完全充電時の電源残容量の２０％に設定してもよい。過剰電力ＥＰｅｘは、実験またはシミュレーションによって適切な値を設定してもよい。

このように、電源残容量ＥＰｒに過剰電力ＥＰｅｘ分余裕を持つ場合は、ソフトウェアの更新継続可否判断を省略することで、ソフトウェア更新作業を効率的に短時間で完了することができる。また、不必要な処理を省略することができるので、バッテリ２０の電源残容量の無駄な消費を削減することができる。

＜ソフトウェア更新継続処理＞
図１２は、実施の形態８に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。実施の形態１に係る図４のソフトウェア更新継続処理を示すフローチャートのステップＳ２０１とステップＳ２０２の間に、新たにステップＳ２８１を追加した部分のみが異なる。追加した部分を説明する。

図１２のステップＳ２０１で、ソフトウェア更新中フラグがセットされている場合、ステップＳ２８１へ進む。ステップＳ２８１では、電源残容量ＥＰｒが、ソフトウェア更新電力ＥＰｒｖと過剰電力ＥＰｅｘの和よりも大きいかどうか判定する。電源残容量ＥＰｒが、ソフトウェア更新電力ＥＰｒｖと過剰電力ＥＰｅｘの和よりも大きくない場合(判定はＮＯ)は、ステップＳ２０２へ進み、ソフトウェアの更新継続可否判断を実行する。

ステップＳ２８１で、電源残容量ＥＰｒがソフトウェア更新電力ＥＰｒｖと過剰電力ＥＰｅｘの和よりも大きい場合（判定はＹＥＳ）は、ステップＳ２０９へ進んでソフトウェア更新完了しているかどうか確認する。

このように構成することで、バッテリ２０が過剰電力ＥＰｅｘを有する場合は、電源残容量低下量ΔＥＰｒの確認などのソフトウェアの更新継続可否判断を省略することができる。

９．実施の形態９
実施の形態９に係る車両用制御装置１００は図１、図２に示す車両用制御装置１００の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態９に係る車両用制御装置１００を実現できるが、ハードウェアの変更を伴っていてもよい。

＜ポーリング区間の電源残容量低下＞
実施の形態９に係る車両用制御装置１００は、実施の形態１に係るソフトウェア更新継続処理において、ポーリング区間に基づいた電源残容量低下の監視を実行する場合を示す。ここでは、ポーリング周期Ｔｐが３０秒の場合にポーリングを実行して、ソフトウェア更新継続処理を実行する。

図１３は、実施の形態９に係る車両用制御装置１００のソフトウェア更新の第一のタイムチャートである。図１３では、１８０秒間に３０秒間隔でポーリングを実行している様子を示している。ソフトウェア更新電力ＥＰｒｖが、例えばバッテリ２０の完全充電時の電源残容量の３０％相当と算出されている場合、ポーリング区間ごとに、５％前後ずつ電源残容量ＥＰｒが減少する状態が示されている。

ここで、予想している電源残容量低下量ΔＥＰｒは、ポーリング周期Ｔｐごとに５％である。そこで、例えばこの２倍である１０％を超える電源残容量低下量ΔＥＰｒが発生するかどうか監視し、１０％を超える電源残容量低下量ΔＥＰｒが発生した場合にソフトウェア更新を中止することとしてもよい。

図１４は、実施の形態９に係る車両用制御装置１００のソフトウェア更新の第二のタイムチャートである。図１４では、３回目のポーリングにおいて、電源残容量低下量ΔＥＰｒが１２％となっている。１０％を超える電源残容量低下量ΔＥＰｒが発生したので、ここで、ソフトウェアの更新を中止する。

ここでは、ポーリング周期Ｔｐごとのソフトウェア更新電力ＥＰｒｖによる電源残容量低下量ΔＥＰｒの予想値に対してこの２倍を超えた場合にソフトウェアの更新を中止したが、２倍である必要はない。予想値に係数Ｋを乗じた判定値を、実験、シミュレーションなどで求めてもよい。

＜ソフトウェア更新継続処理＞
図１５は、実施の形態９に係る車両用制御装置のソフトウェア更新継続処理を示すフローチャートである。実施の形態１に係る図４のソフトウェア更新継続処理を示すフローチャートのステップＳ２０２とステップＳ２０３の間に、新たにステップＳ２９１からステップＳ２９３を追加した部分のみが異なる。追加した部分を中心に説明する。

図１５のステップＳ２０１で、ソフトウェア更新中フラグがセットされている場合、ステップＳ２０２へ進む。ステップＳ２０２では、電源残容量低下検出部１６によって電源残容量低下量ΔＥＰｒが検出される。ここでは、ポーリングのたびに求めた電源残容量ＥＰｒの前回検出値との差分を電源残容量低下量ΔＥＰｒとする。

ステップＳ２９１では、ソフトウェアの更新を開始してから完了するまでのソフトウェア更新時間Ｔｒｐを算出する。そして、ステップＳ２９２では、経過時間比率ＲＴｂｐを算出する。経過時間比率ＲＴｂｐは、ポーリング周期Ｔｐとソフトウェア更新時間Ｔｒｐの比である。

ステップＳ２９３では、ソフトウェア更新電力ＥＰｒｖと経過時間比率ＲＴｂｐの積に係数Ｋを乗じた値よりも電源残容量低下量ΔＥＰｒが大きいかどうか判定する。電源残容量低下量ΔＥＰｒが大きい場合（判定はＹＥＳ）は、ポーリング区間の電源残容量低下量ΔＥＰｒが予測値に係数Ｋを乗じた値より大きいことを示す。電源残容量低下量ΔＥＰｒが、予想外に大きいとの判断で、ステップＳ２１２に進んで、ソフトウェア更新中止の処理を進める。

ステップＳ２９３で、電源残容量低下量ΔＥＰｒが大きくない場合（判定はＮＯ）ステップＳ２０３へ進む。ステップＳ２０３では、電源残容量低下量ΔＥＰｒが予め定められた低下判定値ΔＥＰｊ以上かどうか判定する。

以上のようにポーリング区間ごとの電源残容量低下量ΔＥＰｒが予測値に係数Ｋを乗じた値より大きいか否かによって、ソフトウェアの更新の継続可否を判定する。これによって、電源残容量低下量ΔＥＰｒの増大を、固定値である低下判定値ΔＥＰｊと比較するよりも精度よく判定することができる。そのため、車両用制御装置１００の異常動作を防止し、安定性の高いソフトウェアの更新が可能となる。

１０．実施の形態１０
実施の形態１０に係る車両用制御装置１００は図１、図２に示す車両用制御装置１００の構成をそのまま適用できるので、符号をそのまま使用して説明する。ソフトウェアの変更のみによって、実施の形態１０に係る車両用制御装置１００を実現できるが、ハードウェアの変更を伴っていてもよい。

＜ソフトウェア受信電力の算出＞
実施の形態１０に係る車両用制御装置１００は、実施の形態１に係るソフトウェア更新開始処理の前処理として、ソフトウェア更新開始前処理を実施する。車両用制御装置１００は、サーバから更新ソフトウェアのデータを受信する前に、更新ソフトウェアに関する情報である更新ソフトウェア情報を受信する。

更新ソフトウェア情報には、更新ソフトウェアの容量などの情報が含まれている。車両用制御装置１００は、更新ソフトウェア本体のデータを受信するために必要な更新ソフトウェア受信電力ＥＰｒｃｖを算出する。そして、更新ソフトウェアを記憶装置９１に書き込むためのソフトウェア更新電力ＥＰｒｖを算出する。

更新ソフトウェア受信電力ＥＰｒｃｖとソフトウェア更新電力ＥＰｒｖの和が、ソフトウェア受信更新電力ＥＰｒｃｖ＿ｒｖである。車両用制御装置１００は、サーバから受信した更新ソフトウェア情報から、ソフトウェア受信更新電力ＥＰｒｃｖ＿ｒｖを算出し、電源残容量ＥＰｒがソフトウェア受信更新電力ＥＰｒｃｖ＿ｒｖよりも大きい場合に、サーバからの更新ソフトウェアの受信を受け入れる。

電源残容量ＥＰｒが小さい場合は、ソフトウェア更新が実施できないので、サーバに更新ソフトウェアのデータの受信拒否を回答する。このように、更新ソフトウェアのデータの受信前に電源残容量ＥＰｒでソフトウェア更新が可能か否か判断することができる。それによって、不要な更新ソフトウェアの受信を回避できる。これによって、バッテリ２０の電源残容量ＥＰｒの消費を節約することができる。そして、安定性の高いソフトウェアの更新が可能となる。

＜ソフトウェア更新開始前処理＞
図１６は、実施の形態１０に係る車両用制御装置のソフトウェア更新開始前処理を示すフローチャートである。実施の形態１に係る図３のソフトウェア更新開始処理を示すフローチャートに先立って実行される処理である。

図１６のフローチャートの処理は、所定時間ごとに実行される（例えば１０ｍｓごと）。図１６のフローチャートの処理は、所定時間ごとではなく、車両が所定距離走行するごと、または車両用制御装置１００がサーバからデータを受信するたび、といったイベントごとに実行されることとしてもよい。

処理が開始され、ステップＳ１１１で、受信部１８がサーバから更新ソフトウェア情報を受信したかどうか判定する。更新ソフトウェアを受信していない場合（判定はＮＯ）は、処理を終了する。更新ソフトウェアを受信した場合（判定はＹＥＳ）は、ステップＳ１１２へ進む。

ステップＳ１１２では、更新ソフトウェア情報に基づいて更新ソフトウェア本体のデータを受信するために必要な更新ソフトウェア受信電力ＥＰｒｃｖを算出する。ステップＳ１１３で、更新ソフトウェアを記憶装置９１に書き込むためのソフトウェア更新電力ＥＰｒｖを算出する。

ステップＳ１１４で、更新ソフトウェア受信電力ＥＰｒｃｖとソフトウェア更新電力ＥＰｒｖを加算して、ソフトウェア受信更新電力ＥＰｒｃｖ＿ｒｖを算出する。ステップＳ１１５で、電源残容量ＥＰｒを検出する。

ステップＳ１１６で、電源残容量ＥＰｒがソフトウェア受信更新電力ＥＰｒｃｖ＿ｒｖより大きいか判定する。電源残容量ＥＰｒがソフトウェア受信更新電力ＥＰｒｃｖ＿ｒｖ以下である場合（判定はＮＯ）は、ステップＳ１１８へ進む。ステップＳ１１８では、サーバへソフトウェア受信拒否の回答を送信する。その後処理を終了する。

ステップＳ１１６で、電源残容量ＥＰｒがソフトウェア受信更新電力ＥＰｒｃｖ＿ｒｖより大きい場合（判定はＹＥＳ）は、ステップＳ１１７へ進む。ステップＳ１１７では、サーバへソフトウェア受信受入の回答を送信する。その後処理を終了する。

サーバは車両用制御装置１００からの受信受入れ回答を受信した後に、更新ソフトウェア本体のデータを車両用制御装置１００へ送信開始する。車両用制御装置１００は、更新ソフトウェアを受信した後、図３にフローチャートを示したソフトウェア更新開始処理を開始する。

本願は、様々な例示的な実施の形態及び実施例が記載されているが、１つ、または複数の実施の形態に記載された様々な特徴、態様、及び機能は特定の実施の形態の適用に限られるのではなく、単独で、または様々な組み合わせで実施の形態に適用可能である。従って、例示されていない無数の変形例が、本願明細書に開示される技術の範囲内において想定される。例えば、少なくとも１つの構成要素を変形する場合、追加する場合または省略する場合、さらには、少なくとも１つの構成要素を抽出し、他の実施の形態の構成要素と組み合わせる場合が含まれるものとする。

１１ ソフトウェア更新制御部、１２ ソフトウェア更新電力算出部、１３ ソフトウェア更新開始許可部、１４ ソフトウェア更新継続許可部、１５ 電源残容量検出部、１６ 電源残容量低下検出部、１８ 受信部、２０ バッテリ、９１ 記憶装置、１００ 車両用制御装置、ＥＰｃｒｖ ソフトウェア更新継続電力、ＥＰｅｘ 過剰電力、ＥＰｒ 電源残容量、ＥＰｒｃｖ 更新ソフトウェア受信電力、ＥＰｒｃｖ＿ｒｖ ソフトウェア受信更新電力、ＥＰｒｖ ソフトウェア更新電力、ＧＥＰ 電源残容量低下時増大割合、Ｋ 係数、Ｒｃｃａ ＣＣＡ比率、Ｒｃｃａｈ ＣＣＡ上側比率、Ｒｃｃａｌ ＣＣＡ下側比率、ＲＴｂｐ 経過時間比率、ＳＧ バッテリ液比重、ＳＧｈ バッテリ液上側比重、ＳＧｌ バッテリ液下側比重、Ｔｃｍｐ 書き込み完了時間、Ｔｐ ポーリング周期、Ｔｒｐ ソフトウェア更新時間、Ｔｒｖ 時間、Ｖｂ 電源電圧、Ｖｂｈ 上側電圧、Ｖｂｌ 下側電圧、ΔＥＰｊ 低下判定値、ΔＥＰｊ２ 第二の低下判定値、ΔＥＰｒ 電源残容量低下量、ΔＲｃｃａ ＣＣＡ比率低下量、ΔＲｃｃａｎｇ ＣＣＡ低下量判定値、ΔＳＧ バッテリ液比重低下量、ΔＳＧｎｇ バッテリ液比重低下量判定値、ΔＶｂ 電源電圧低下量、ΔＶｂｎｇ 電源電圧低下量判定値

Claims (16)

1. ソフトウェアが書き込まれた記憶装置、
   前記ソフトウェアを更新する更新ソフトウェアを受信する受信部、
   バッテリの電源残容量を検出する電源残容量検出部、
   バッテリの電源残容量の低下量を検出する電源残容量低下検出部、
   前記更新ソフトウェアを前記記憶装置に書き込むためのソフトウェア更新電力を算出するソフトウェア更新電力算出部、
   前記電源残容量検出部によって検出された前記バッテリの残容量が、前記ソフトウェア更新電力算出部によって算出された前記ソフトウェア更新電力よりも大きい場合に、前記ソフトウェアの更新開始を許可するソフトウェア更新開始許可部、
   前記バッテリの電源残容量の低下量が予め定められた低下判定値よりも小さい場合に前記ソフトウェアの更新継続を許可するソフトウェア更新継続許可部、
   前記ソフトウェア更新開始許可部によってソフトウェアの更新開始を許可された場合に前記更新ソフトウェアの前記記憶装置への書き込みを開始し、前記更新ソフトウェアの前記記憶装置への書き込み中に前記ソフトウェア更新継続許可部によってソフトウェアの更新継続を許可された場合に前記更新ソフトウェアの前記記憶装置への書き込みを継続し、前記ソフトウェア更新開始許可部または前記ソフトウェア更新継続許可部の判定が不許可の場合は前記更新ソフトウェアの前記記憶装置への書き込みを中止するソフトウェア更新制御部、を備えた車両用制御装置。
2. 前記電源残容量低下検出部は、前記バッテリの電源電圧、コールドクランキング電流またはバッテリ液の比重の少なくとも一つに応じて前記電源残容量の低下量を検出する請求項１に記載の車両用制御装置。
3. 前記更新ソフトウェアの前記記憶装置への書き込み中に、書き込み完了までに消費されるソフトウェア更新継続電力を算出するソフトウェア更新継続電力算出部を備え、
   前記ソフトウェア更新継続許可部は、前記電源残容量の低下量が前記低下判定値よりも小さくかつ、予め定めた第二の低下判定値よりも大きい場合は前記ソフトウェア更新継続電力算出部によって求められた前記ソフトウェア更新継続電力をあらかじめ定めた低下時増大割合だけ増大させて要求電源残容量を算出し、前記電源残容量の低下量が第二の低下判定値以下の場合は前記電源残容量の低下量に応じて前記ソフトウェア更新継続電力を増大させて前記要求電源残容量を算出し、前記バッテリの残容量が前記要求電源残容量よりも大きい場合に前記更新ソフトウェアの更新継続を許可する請求項１または２に記載の車両用制御装置。
4. 前記電源残容量低下検出部は、前記バッテリの電源電圧に応じて前記電源残容量の低下量を検出し、
   前記ソフトウェア更新継続許可部は、前記バッテリの電源電圧が１１．５Ｖ未満の場合に前記ソフトウェア更新継続電力を１００%増大させて前記要求電源残容量を算出し、前記バッテリの電源電圧が１１．５Ｖ以上かつ１２．５Ｖ未満の場合に、前記バッテリの電源電圧が１２．５Ｖから０．１Ｖ低下するごとに前記ソフトウェア更新継続電力を５％ずつ増大させて前記要求電源残容量を算出する請求項３に記載の車両用制御装置。
5. 前記電源残容量低下検出部は、前記バッテリのコールドクランキング電流に応じて前記電源残容量の低下量を検出し、
   前記ソフトウェア更新継続許可部は、前記コールドクランキング電流が初期値の７０％未満の場合に前記ソフトウェア更新継続電力を１００％増大させて前記要求電源残容量を算出し、前記コールドクランキング電流が初期値の７０％以上かつ１００％未満の場合に、前記コールドクランキング電流が１００％から低下した割合だけ、前記ソフトウェア更新継続電力を増大させて前記要求電源残容量を算出する請求項３に記載の車両用制御装置。
6. 前記電源残容量低下検出部は、前記バッテリのバッテリ液の比重に応じて前記電源残容量の低下量を検出し、
   前記ソフトウェア更新継続許可部は、前記バッテリ液の比重が１．２１未満の場合に、前記ソフトウェア更新継続電力を１００％増大させて前記要求電源残容量を算出し、前記バッテリ液の比重が１．２１以上かつ１．２８未満の場合に、前記バッテリ液の比重が１．２８から０．０１低下するごとにソフトウェア更新継続電力を７％ずつ増大させて前記要求電源残容量を算出する請求項３に記載の車両用制御装置。
7. 前記ソフトウェア更新継続許可部は、前記バッテリの使用可能年数を５年以上超えて使用している場合に、前記要求電源残容量を１００％増大させて算出する請求項３から６のいずれか一項に記載の車両用制御装置。
8. 前記ソフトウェア更新継続許可部は、前記バッテリが２回以上のバッテリ上がりの履歴を有している場合に、前記要求電源残容量を１００％増大させて算出する請求項３から７のいずれか一項に記載の車両用制御装置。
9. 前記ソフトウェア更新継続許可部は、車両が１カ月以上継続して停止している場合、または移動距離２ｋｍ未満の走行を１０回以上連続して実施している場合に、前記要求電源残容量を１００％増大させて算出する請求項３から８のいずれか一項に記載の車両用制御装置。
10. 前記ソフトウェア更新制御部は、前記ソフトウェア更新開始許可部によってソフトウェアの更新開始可能と判定された場合に前記更新ソフトウェアの前記記憶装置への書き込みを開始し、前記更新ソフトウェアの前記記憶装置への書き込みが予め定めた書き込み完了時間以内に完了する場合は、前記ソフトウェア更新継続許可部の判定に拘らず前記更新ソフトウェアの前記記憶装置への書き込みを継続する請求項１から９のいずれか一項に記載の車両用制御装置。
11. 前記ソフトウェア更新制御部は、前記更新ソフトウェアの前記記憶装置への書き込みが２分以内に完了する場合は、前記ソフトウェア更新継続許可部の判定に拘らず前記更新ソフトウェアの前記記憶装置への書き込みを継続する請求項１０に記載の車両用制御装置。
12. 前記ソフトウェア更新制御部は、前記ソフトウェア更新開始許可部によってソフトウェアの更新開始可能と判定された場合に前記更新ソフトウェアの前記記憶装置への書き込みを開始し、前記電源残容量検出部によって検出された前記バッテリの残容量が、前記ソフトウェア更新電力算出部によって算出された前記ソフトウェア更新電力と予め定めた過剰電力の和よりも大きい場合は、前記ソフトウェア更新継続許可部の判定に拘らず前記更新ソフトウェアの前記記憶装置への書き込みを継続する請求項１から１１のいずれか一項に記載の車両用制御装置。
13. 前記ソフトウェア更新制御部は、前記電源残容量検出部によって検出された前記バッテリの残容量が、前記ソフトウェア更新電力算出部によって算出された前記ソフトウェア更新電力と前記バッテリの初期電力容量の２０％の和よりも大きい場合は、前記ソフトウェア更新継続許可部の判定に拘らず前記更新ソフトウェアの前記記憶装置への書き込みを継続する請求項１２に記載の車両用制御装置。
14. 前記電源残容量低下検出部は、予め定めたポーリング周期ごとに前記バッテリの電源残容量の低下量を検出し、
    ソフトウェア更新継続許可部は、前記ポーリング周期と前記更新ソフトウェアの前記記憶装置への書き込み開始から完了までの予定時間との比である経過時間比率を算出し、前記ポーリング周期間の前記電源残容量の低下量が前記ソフトウェア更新電力と前記経過時間比率の積の予め定めた係数倍よりも大きい場合は、前記ソフトウェアの更新継続を不許可と判定する請求項１から１３のいずれか一項に記載の車両用制御装置。
15. ソフトウェア更新継続許可部は、前記ポーリング周期間の前記電源残容量の低下量が前記ソフトウェア更新電力と前記経過時間比率の積の２倍よりも大きい場合は、前記ソフトウェアの更新継続を不許可と判定する請求項１４に記載の車両用制御装置。
16. 前記受信部は、前記更新ソフトウェアに関する情報である更新ソフトウェア情報を受信し、前記更新ソフトウェア情報に基づいて前記更新ソフトウェアの本体である更新ソフトウェアデータを受信するための更新ソフトウェア受信電力を算出し、前記更新ソフトウェア情報に基づいて前記ソフトウェア更新電力算出部によって算出された前記ソフトウェア更新電力と前記更新ソフトウェア受信電力との和であるソフトウェア受信更新電力を算出し、前記電源残容量検出部によって検出された前記バッテリの電源残容量が前記ソフトウェア受信更新電力より大きければ前記更新ソフトウェアデータを受信し、前記バッテリの電源残容量が前記ソフトウェア受信更新電力以下であれば前記更新ソフトウェアデータの受信を拒否する、請求項１から１５のいずれか一項に記載の車両用制御装置。

Images