JP2019191943A - 車載装置、プログラムの更新方法、プログラム更新システム - Google Patents

Abstract

【課題】バッテリ残量を考慮したプログラムの更新ができる。【解決手段】車載装置は、バッテリを備える車両に搭載され車両に搭載される他の装置のプログラムを更新する車載装置であって、バッテリの残容量の情報であるバッテリ残量を取得する電源管理部と、プログラムの更新に関する情報である更新情報を通信により取得する更新情報取得部と、更新情報およびバッテリ残量に基づき更新するプログラムを決定する更新プログラム決定部と、更新プログラム決定部の決定に基づきプログラムを更新する情報である更新本体を通信により取得する更新本体取得部と、更新本体を他の装置に送信しプログラムの更新を実行させる転送部とを備える。【選択図】図２

Description

本発明は、車載装置、プログラムの更新方法、およびプログラム更新システムに関する。

近年、車両内で実行される演算の複雑化が進み、車載装置のプログラムを更新する頻度が高くなっている。車載装置のプログラムは、従来はオペレータにより手作業で更新されたが、自動処理によりサーバと通信して更新することが求められている。特許文献１には、車両に搭載される車載プログラム更新装置であって、車載ネットワークシステムを構成する複数の電子制御装置について該電子制御装置毎に、実装されているプログラムが更新可能な車両負荷状態を個々に示す更新条件テーブルを記憶している記憶手段と、外部のセンタ装置との間で無線通信を行うことによって、該センタ装置から前記プログラムを更新するための更新ファイルを受信する更新ファイル受信手段と、前記更新ファイル受信手段により前記更新ファイルを受信する場合、前記記憶手段に記憶されている更新条件テーブルに基づき、現在の車両負荷状態が該更新ファイルに対応するプログラムを更新可能な低負荷状態であるか該プログラムを更新不能な高負荷状態であるかを判定する更新判定手段と、前記更新判定手段により前記低負荷状態であると判定した場合、前記更新ファイル受信手段により受信した更新ファイルを用いて、該更新ファイルに対応するプログラムを更新するプログラム更新手段と、前記更新判定手段により前記高負荷状態であると判定した場合、前記記憶手段に記憶されている更新条件テーブルに基づき、現在の車両負荷状態を前記低負荷状態に変更するための環境整備制御を実行する環境整備制御手段と、を備えることを特徴とする車載プログラム更新装置が開示されている。

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

特許文献１に記載されている発明では、バッテリ残量を考慮したプログラムの更新ができない。

本発明の第１の態様による車載装置は、バッテリを備える車両に搭載され前記車両に搭載される他の装置のプログラムを更新する車載装置であって、前記バッテリの残容量の情報であるバッテリ残量を取得する電源管理部と、プログラムの更新に関する情報である更新情報を通信により取得する更新情報取得部と、前記更新情報および前記バッテリ残量に基づき更新するプログラムを決定する更新プログラム決定部と、前記更新プログラム決定部の決定に基づきプログラムを更新する情報である更新本体を通信により取得する更新本体取得部と、前記更新本体を前記他の装置に送信しプログラムの更新を実行させる転送部とを備える。
本発明の第２の態様によるプログラムの更新方法は、バッテリを備える車両に搭載され前記車両に搭載される他の装置のプログラムを更新するプログラムの更新方法であって、前記バッテリの残容量の情報であるバッテリ残量を取得することと、プログラムの更新に関する情報である更新情報を通信により取得することと、前記更新情報および前記バッテリ残量に基づき更新するプログラムの決定を行うことと、前記決定に基づきプログラムを更新する情報である更新本体を取得することと、前記更新本体を前記他の装置に送信しプログラムの更新を実行させることとを含む。
本発明の第３の態様によるプログラム更新システムは、バッテリを備える車両に搭載され前記車両に搭載される他の装置のプログラムを更新する車載装置、および前記車載装置と通信可能なサーバを備えるプログラム更新システムであって、前記車載装置は、前記バッテリの残容量の情報であるバッテリ残量を取得する電源管理部と、前記他の装置に関する情報を現状情報として前記サーバに送信し、前記サーバからプログラムの更新に関する情報である更新情報を取得する更新情報取得部と、前記更新情報および前記バッテリ残量に基づき更新するプログラムを決定する更新プログラム決定部と、前記更新プログラム決定部の決定に基づきプログラムを更新する情報である更新本体を通信により取得する更新本体取得部と、前記更新本体を前記他の装置に送信しプログラムの更新を実行させる転送部とを備え、前記サーバは、受信した前記現状情報に基づき前記更新情報を作成し前記車載装置に送信する更新情報作成部を備える。

本発明によれば、バッテリ残量を考慮したプログラムの更新ができる。

プログラム更新システムＳのハードウエア構成図 ＴＣＵ１の機能ブロック図 更新情報１７１の一例を示す図 現状情報１７２の一例を示す図 受信強度表１７３の一例を示す図 ノイズレベル表１７４の一例を示す図 通過数表１７５の一例を示す図 取得コストの算出例を示す図 更新コストの算出例を示す図 取得プログラムおよび更新プログラムを決定する例を示す図 ＴＣＵ１の更新処理を表すフローチャート サーバ４の処理を表すフローチャート

―実施の形態―
以下、図１〜図１２を参照して、本発明にかかるプログラム更新システムの実施の形態を説明する。本実施の形態では、装置ごとに更新するプログラムは１つのみとする。そのため本実施の形態では、更新対象のプログラムを特定することと、更新対象のプログラムが動作している装置を特定することは同じ意味である。

（ハードウエア構成）
図１はプログラム更新システムＳのハードウエア構成図である。プログラム更新システムＳは、車両５とサーバ４とから構成される。ただし図１では車両５は１台のみ記載しているがプログラム更新システムＳには複数の車両５が含まれてもよい。車両５は、ＴＣＵ１と、バッテリ２と、第１ＥＣＵ３１と、第２ＥＣＵ３２と、第３ＥＣＵ３３と、第４ＥＣＵ３４と、ゲートウェイＥＣＵ（以下、「ＧＷ」とも呼ぶ）３５とを備える。

ＴＣＵ１は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、無線通信部１４と、車内通信部１５と、バッテリセンサ１６と、フラッシュメモリ１７とを備える。ＣＰＵ１１は中央演算装置であり、ＲＯＭ１２に格納されるプログラムをＲＡＭ１３に展開して実行することにより後述する機能を実現する。無線通信部１４は、無線通信モジュールであり、たとえば３Ｇや４Ｇの通信規格に対応する。無線通信部１４は、最寄りの基地局を介してインターネットＸに接続し、インターネットＸを経由してサーバ４と通信する。

車内通信部１５は、車両５の内部に存在する他の装置と通信する通信モジュールであり、たとえばＩＥＥＥ８０２．３に対応する。車内通信部１５はＧＷ３５と接続され、ＧＷ３５を介して第１ＥＣＵ３１、第２ＥＣＵ３２、第３ＥＣＵ３３、および第４ＥＣＵ３４と通信する。バッテリセンサ１６は、バッテリ２の残容量を検出するセンサであり、たとえば電圧計である。バッテリ２は電圧と残容量の関係が既知なので、電圧を測定することにより残容量を推定できる。以下では、バッテリ２の残容量を示す情報を「バッテリ残量」と呼ぶ。フラッシュメモリ１７は、後述する情報を記憶する不揮発性の記憶装置である。ただしＴＣＵ１がフラッシュメモリ１７を備えず、ＲＯＭ１２に必要な情報を全て記憶してもよい。

バッテリ２は、不図示の電力供給線によりＴＣＵ１、第１ＥＣＵ３１、第２ＥＣＵ３２、第３ＥＣＵ３３、第４ＥＣＵ３４、およびＧＷ３５に電力を供給する。この電力の供給は車両５のイグニションスイッチの状態を問わずに行われるので、たとえばイグニッションスイッチがオフにされた後もＴＣＵ１などは動作可能である。バッテリ２は電圧と残容量の関係が既知である。

第１ＥＣＵ３１、第２ＥＣＵ３２、第３ＥＣＵ３３、および第４ＥＣＵ３４はいずれも、車両５に内蔵され車両５の動作に関する何らかの演算を行う電子制御装置（Electronic Control Unit）、すなわちＥＣＵである。以下では、第１ＥＣＵ３１、第２ＥＣＵ３２、第３ＥＣＵ３３、および第４ＥＣＵ３４をまとめてＥＣＵ３０と呼ぶ。ここではＥＣＵ３０が担う具体的な機能は説明しないが、それぞれのＥＣＵ３０はプログラムを実行することによりそれぞれの機能を実現する。

各ＥＣＵ３０が実行するプログラムにはバージョン番号が付与されており、新しいプログラム、すなわちより大きい番号のバージョン番号を有するプログラムがサーバ４で作成されることがある。そのような場合は、その新しいプログラムを実行するための情報（以下、「更新本体」と呼ぶ）がＴＣＵ１からＧＷ３５を介して各ＥＣＵ３０に送信される。各ＥＣＵ３０は、受信した更新本体を用いてプログラムを更新し、更新の完了をＴＣＵ１に伝達する。

なお更新本体は、新たなプログラムの全体でもよいし、現在のプログラムと新たなプログラムの差分でもよい。また更新本体は圧縮されていてもよいし、事前に取り決めた暗号化が施されていてもよい。さらに更新本体には、電子署名が付加されていてもよい。

またＴＣＵ１およびＧＷ３５もＥＣＵ３０と同様にプログラムを実行しており、これらのプログラムは同様の手順で更新される。以下では、ＴＣＵ１、ＥＣＵ３０、およびＧＷ３５をまとめて「更新可能機器」と呼ぶ。更新可能機器はプログラムを不揮発性の記憶装置に格納しており、プログラムは適宜書き換えられる。ただし装置ごとにこの記憶装置の特性が異なり、たとえば書き込み速度が異なる。それぞれの更新可能機器における記憶装置の書き込み速度は既知であり、ＴＣＵ１に格納されている。

ＧＷ３５は、車内通信部１５とＥＣＵ３０との通信を中継する装置である。ＧＷ３５はたとえば、車内通信部１５とはＩＥＥＥ８０２．３の規格に則った通信を行い、ＥＣＵ３０とは別の通信規格、たとえばＣＡＮ（登録商標）に則った通信を行う。

サーバ４は、ＣＰＵ４１と、ＲＯＭ４２と、ＲＡＭ４３と、ＨＤＤ４４と、サーバ通信部４５とを備える。ＣＰＵ４１は中央演算装置であり、ＲＯＭ４２に格納されるプログラムをＲＡＭ４３に展開して実行することにより後述する機能を実現する。ＨＤＤ４４は不揮発性の記憶装置、たとえばハードディスクドライブである。ＨＤＤ４４にはデータベース（以下、「ＤＢ」）４４１、および様々なプログラムに対応する更新本体が格納される。ＤＢ４４１には、サーバ４に接続される様々な車両５に搭載される機器で動作しているプログラムの現在のバージョン番号、および各プログラムの最新バージョン番号が格納される。たとえば新しいバージョンのプログラムが作成されると、そのプログラムの更新本体がＨＤＤ４４に格納され、ＤＢ４４１に記載されるそのプログラムの最新バージョン番号が更新される。サーバ通信部４５は、インターネットＸを経由してＴＣＵ１と通信する。

（機能構成）
図２は、ＴＣＵ１が備える機能を示す機能ブロック図である。ただし図２にはフラッシュメモリ１７に格納される情報も示している。ＴＣＵ１はその機能として、電源管理部１１１と、更新情報取得部１１２と、更新プログラム決定部１１３と、更新本体取得部１１４と、転送部１１５と、監視部１１６とを備える。またフラッシュメモリ１７には、更新情報１７１と、現状情報１７２と、受信強度表１７３と、ノイズレベル表１７４と、通過数表１７５と、更新本体１７９とが格納される。ただし更新情報１７１、現状情報１７２、および更新本体１７９は必ずしも常にフラッシュメモリ１７に格納されていなくてもよい。

（更新情報１７１）
図３は更新情報１７１の一例を示す図である。更新情報１７１は、サーバ４により作成されＴＣＵ１に送信される。更新情報１７１には、更新可能機器のそれぞれについて、最新のプログラムのバージョン、更新の優先度、同時に更新すべきプログラムを示す関連情報、ダウンロードする更新本体のデータ容量（以下、「ＤＬサイズ」とも呼ぶ）などが含まれる。ただし図３に示す例ではＴＣＵ１の情報を記載していない。なお図３に示す例において第２ＥＣＵのＤＬサイズが記載されていないのは、第２ＥＣＵ３２ではすでに最新のバージョン６．０が動作しており、新たにダウンロードをする必要がないからである。

（現状情報１７２）
図４は現状情報１７２の一例を示す図である。現状情報１７２はＴＣＵ１が更新可能機器の情報を収集した情報であり、ＴＣＵ１からサーバ４に送信される。ただし図４に示す例ではＴＣＵ１の情報を記載していない。現状情報１７２にはＴＣＵ１を識別する情報、および更新可能機器に搭載されるプログラムのバージョン情報が含まれる。たとえば現状情報１７２は、ＴＣＵ１を識別する情報として識別番号、仕向、およびモデルの情報が含まれ、第１ＥＣＵ３１〜第４ＥＣＵ３４、およびＧＷ３５のプログラムのバージョンが含まれる。

（受信強度表１７３）
図５は受信強度表１７３の一例を示す図である。受信強度表１７３はフラッシュメモリ１７にあらかじめ格納される。受信強度表１７３は、無線通信部１４が受信する信号の強度、すなわち受信強度と、後の演算で使用する受信係数との関係を表している。受信強度は、最も良好な通信状態では「１００」であり、強度の低下により「１」まで減少して最後は「圏外」となる。図５に示すように受信強度が強いほど受信係数は小さく、受信強度が弱いほど受信係数は大きくなる。ただし圏外の場合は後述するように更新本体を取得しないので受信係数を「対象外」としている。

（ノイズレベル表１７４）
図６はノイズレベル表１７４の一例を示す図である。ノイズレベル表１７４はフラッシュメモリ１７にあらかじめ格納される。ノイズレベル表１７４は無線通信部１４が受信する信号のノイズレベルと、後の演算で使用するノイズ係数との関係を表している。ノイズレベルは、最も良好な通信状態では「１」であり、最も劣悪な通信状態では「１００」である。図６に示すようにノイズレベルが低いほどノイズ係数は小さく、ノイズレベルが高いほどノイズ係数は大きくなる。

（通過数表１７５）
図７は通過数表１７５の一例を示す図である。通過数表１７５はフラッシュメモリ１７にあらかじめ格納される。通過数表１７５はＴＣＵ１を起点として更新対象のＥＣＵに至るまでに通過する他のＥＣＵの数と、後の演算で使用する通過係数との関係を表している。すなわち更新対象のＥＣＵがＴＣＵ１自身の場合は通過するＥＣＵが「１」なので通過係数が「１．０」、更新対象のＥＣＵがＧＷ３５の場合は通過するＥＣＵが「２」なので通過係数が「２．０」、更新対象のＥＣＵがＥＣＵ３０の場合は通過するＥＣＵが「３」なので通過係数が「３．０」である。なお図７に示す例では、「通過ＥＣＵ個数」のフィールドと「対象ＥＣＵ」のフィールドを備えたが、いずれか一方だけを備えてもよい。

電源管理部１１１は、ＣＰＵ１１において実行されるプログラムおよびバッテリセンサ１６により実現される。電源管理部１１１は、バッテリ２の電圧を測定し既知の関係式によりバッテリ残量を算出する。そして車両５の次回の起動に必要な既知の電力量を除いたバッテリ残量でＴＣＵ１、ＥＣＵ３０およびＧＷ３５が動作可能な時間を算出する。たとえば測定したバッテリ２の電圧が１１．５Ｖの場合に既知の関係式からバッテリ残量が１０ｗｈと算出し、次回の起動に必要な電力量であるたとえば４ｗｈを除いた６ｗｈを使用可能と判断する。そしてたとえばＴＣＵ１、ＥＣＵ３０およびＧＷ３５の消費電力が合計で１０ｗの場合は、動作可能な時間は０．６時間、すなわち３６分または２１６０秒と算出する。

更新情報取得部１１２は、ＣＰＵ１１において実行されるプログラムおよび無線通信部１４により実現される。更新情報取得部１１２は、現状情報１７２を作成してサーバ４に送信し、サーバ４から更新情報１７１を取得する。更新プログラム決定部１１３はＣＰＵ１１において実行されるプログラムにより実現される。更新プログラム決定部１１３は、更新情報１７１およびバッテリ残量に基づき更新するプログラムを決定する。可能ならば全てのプログラムを更新したいがバッテリ残量には限りがあるので、更新プログラム決定部１１３は後述する手法により優先度が高いプログラムを優先して選択する。

更新本体取得部１１４は、ＣＰＵ１１において実行されるプログラムおよび無線通信部１４により実現される。更新本体取得部１１４は、更新プログラム決定部１１３が更新を決定したプログラムの更新本体１７９をサーバ４から取得しフラッシュメモリ１７に保存する。ただし更新本体取得部１１４は、取得した更新本体１７９をＲＡＭ１３に保存してもよい。

転送部１１５は、ＣＰＵ１１において実行されるプログラムおよび車内通信部１５により実現される。転送部１１５は、フラッシュメモリ１７に保存された更新本体１７９を対応するＥＣＵに転送し、それぞれのＥＣＵにおいてプログラムの更新を実行させる。また転送部１１５は、各ＥＣＵから更新完了通知を受信するとサーバ４にその旨を伝達する。監視部１１６は、ＣＰＵ１１において実行されるプログラムおよび無線通信部１４により実現される。監視部１１６は無線通信部１４の通信状態、すなわちノイズレベルおよび電波強度を監視する。監視部１１６は監視結果を更新プログラム決定部１１３に出力する。

（更新プログラムの決定）
更新プログラム決定部１１３による更新プログラムの決定を説明する。更新プログラム決定部１１３は、まず、更新が必要なプログラムごとに、優先度が高いプログラムから順番に、更新本体の取得に要する電力のコスト（以下、「取得コスト」と呼ぶ）、および更新に要する電力のコスト（以下、「更新コスト」と呼ぶ）を算出する。更新プログラム決定部１１３は次に、利用可能な消費電力から優先度が最も高いプログラムの取得コストおよび更新コストを差し引き、利用可能な消費電力の残余が正であれば次に優先度が高いプログラムの取得コストおよび更新コストを差し引く。更新プログラム決定部１１３は、このように利用可能な消費電力から各プログラムの取得コストおよび更新コストを順番に差し引き、利用可能な消費電力が負になる直前までのプログラムを取得対象および更新対象として決定する。ただし本実施の形態では、消費電力やコストを装置を稼働可能な時間で代替する。

更新プログラム決定部１１３は、各プログラムの取得コストを以下の式１のように算出する。
取得コスト＝（ＤＬサイズ÷標準速度）×受信係数×ノイズ係数×通過係数・・・（式１）

ただしＤＬサイズとは前述のとおりダウンロードする更新本体のデータ容量である。標準速度とは、既知である無線通信部１４の標準的なダウンロード速度である。なお無線通信部１４の通信速度は通信環境により変動するが、その変動分は受信係数およびノイズ係数に反映されるので、標準速度は通信環境にかかわらず一定である。受信係数は、受信強度表１７３および監視部１１６が監視した無線通信部１４の受信強度から特定される。ノイズ係数は、ノイズレベル表１７４および監視部１１６が監視した無線通信部１４のノイズレベルから特定される。通過係数は、通過数表１７５および各プログラムが実行される装置から特定される。

更新プログラム決定部１１３は、各プログラムの更新コストを以下の式２のように算出する。
更新コスト＝ＤＬサイズ÷書き込み速度・・・（式２）

ただしＤＬサイズとは前述のとおりダウンロードする更新本体のデータ容量である。また書き込み速度とは、それぞれの更新可能機器におけるプログラムが格納される記憶装置の書き込み速度である。書き込み速度は機器ごとに異なり、それぞれの書き込み速度は既知である。

このように更新プログラム決定部１１３は、各プログラムの取得コストおよび更新コストを処理に要する時間、すなわち秒数として見積もる。

（取得コストの算出例）
図８は取得コストの算出例を示す図である。図８に示す例は、図３に示した更新情報１７１、図５に示した受信強度表１７３、図６に示したノイズレベル表１７４、および図７に示した通過数表１７５を用いて作成した。ただし第２ＥＣＵ３２は更新が不要なため図８には記載していない。図８に示す例において、たとえば受信強度は９０であったために受信係数は「１．０」となっており、ノイズレベルが３０であったためにノイズ係数は「２．０」となっている。受信係数およびノイズ係数は全ての更新可能機器に共通する値である。

図８において通過係数は、図１に示す物理的な配置により、第１ＥＣＵ３１、第３ＥＣＵ３３、および第４ＥＣＵ３４が「３．０」、ＧＷ３５が「２．０」となっている。図８に示す例では式１の標準速度を１ＭＢ／ｓとしたので、たとえば第１ＥＣＵの取得コストは以下の式３に示すように計算される。
第１ＥＣＵの取得コスト＝（１２０÷１）×１．０×２．０×３．０＝７２０・・・（式３）

このような計算によりそれぞれの取得コストが算出される。次に更新プログラム決定部１１３が取得対象を決定する具体例を続けて説明する。図８に示す例では優先度は上から「緊急」、「低」、「低」、「中」と設定されているが、優先度が「低」である第３ＥＣＵ３３は優先度が「緊急」である第１ＥＣＵ３１に関連する。そのため第３ＥＣＵ３３の更新は第１ＥＣＵ３１と同様に優先される。そして次に優先度が「中」であるＧＷ３５が検討され、最後に優先度が「低」の第４ＥＣＵ３４が検討される。

（更新コストの算出例）
図９は更新コストの算出例を示す図である。図９に示す更新可能機器の書き込み速度は、ＴＣＵ１にあらかじめ格納されている情報である。第１ＥＣＵの更新コストは以下の式４に示すように算出される。
第１ＥＣＵの更新コスト＝１２０÷１０＝１２・・・（式４）

このような計算によりそれぞれの更新コストが算出される。次に更新プログラム決定部１１３が取得対象および更新対象を決定する具体例を続けて説明する。

図１０は、取得プログラムおよび更新プログラムを決定する例を示す図である。図１０は、図８および図９を抜粋し、検討すべき順に並べ替えたものである。そして右端の累計の欄は、検討順における取得コストおよび更新コストの累計が示されている。たとえば最上段の第１ＥＣＵの累計は、第１ＥＣＵの取得コストと更新コストの和である。次の第３ＥＣＵの累計は、第１ＥＣＵの取得コストと更新コストに、第３ＥＣＵの取得コストと更新コストを追加したものである。同様にＧＷと第４ＥＣＵの累計も算出された。動作可能な時間が２１６０秒の場合は、第１ＥＣＵ，第３ＥＣＵ，およびＧＷが取得プログラムおよび更新プログラムとして決定される。

（ＴＣＵ１のフローチャート）
図１１は、ＴＣＵ１の更新処理を表すフローチャートである。以下に説明する各ステップの実行主体はＴＣＵ１のＣＰＵ１１である。ＴＣＵ１は、車両５のイグニションスイッチがオフにされると図１１に示す動作を開始する。すなわち以下に説明する処理が実行されている間は、車両５は停止している。

車両５のイグニションスイッチがオフにされるとＴＣＵ１は、まずＳ６０１において無線通信部１４からノイズレベルおよび電波強度を取得する。続くＳ６０２ではＴＣＵ１は、Ｓ６０１において取得した電波強度から圏外であるか否か、換言するとサーバ４との通信が不可能な状態であるか否かを判断する。ＴＣＵ１は、圏外であると判断する場合は図１１に示す処理を終了し、圏外ではないと判断する場合はＳ６０３に進む。Ｓ６０３ではＴＣＵ１は、更新情報取得部１１２がサーバ４と通信を行い更新情報１７１を取得する。詳述すると更新情報取得部１１２は、現状情報１７２を作成してサーバ４に送信し、サーバ４が現状情報１７２に対応して作成した更新情報１７１を受信する。

続くＳ６０４ではＴＣＵ１は、Ｓ６０３において取得した更新情報１７１を参照し、更新可能なプログラムが存在するか否かを判断する。たとえばＴＣＵ１は、更新情報１７１に記載された各機器の最新バージョンと現状情報１７２に記載のバージョン番号の一致によりこの判断を行ってもよいし、更新情報１７１に記載されたＤＬサイズの有無により判断してもよい。更新可能なプログラムが存在すると判断する場合はＳ６１０に進み、更新可能なプログラムが存在しない、すなわち全てのプログラムがすでに最新であると判断する場合は図１１に示す処理を終了する。

Ｓ６１０では更新プログラム決定部１１３は、Ｓ６０３において取得した更新情報１７１を参照して、前述のように各装置の取得コストおよび更新コストを算出する。続くＳ６１１では更新プログラム決定部１１３は、前述のように電源管理部１１１が算出した動作可能な時間を考慮して取得対象および更新対象のプログラムを決定する。続くＳ６１２では更新本体取得部１１４は、Ｓ６１１において更新プログラム決定部１１３が決定したプログラムの更新本体をサーバ４から取得、すなわちダウンロードの実行を行いフラッシュメモリ１７に格納する。

続くＳ６１６では転送部１１５は、更新可能と判断された装置に更新本体を送信する。続くＳ６１８ではＴＣＵ１は、所定時間以内に更新成功の通知を受信したか否かを判断する。ＴＣＵ１は、受信したと判断する場合はＳ６１９に進みサーバ４に更新完了を通知し、Ｓ６２０でスリープ状態に移行して図１１に示す処理を終了する。Ｓ６１８において否定判断をするとＴＣＵ１はＳ６２５に進み、更新成功を所定時間以内に送信しなかった装置にロールバック指令、すなわち更新前のプログラムに書き戻すように指令して図１１に示す処理を終了する。

（サーバ４のフローチャート）
図１２は、サーバ４の処理を表すフローチャートである。サーバ４は、ＴＣＵ１から現状情報１７２を受信すると図１２に示す処理を開始する。以下に説明する各ステップの実行主体は、サーバ４のＣＰＵ４１である。

サーバ４は現状情報１７２を受信するとまずＳ７０１において、ＤＢ４４１を参照して現状情報１７２に基づき更新情報１７１を作成してＴＣＵ１に送信する。具体的にはサーバ４は、現状情報１７２に記載された機器ごとにＤＢ４４からプログラムの最新のバージョン番号、優先度、関連情報、およびＤＬサイズを取得して更新情報１７１とする。ただし現状情報１７２に記載されたバージョン番号が最新のバージョン番号の場合は、そのプログラムのＤＬサイズは記載しない。続くＳ７０２ではサーバ４は、更新情報１７１の送信から所定時間以内にデータ要求を受けたか否かを判断する。サーバ４は、データ要求を受けたと判断する場合はＳ７０３に進んで要求されたデータを配信してＳ７０４に進む。サーバ４は、Ｓ７０２において否定判断すると図１２に示す処理を終了する。

Ｓ７０４ではサーバ４は、更新完了通知を受信したか否かを判断する。サーバ４はＳ７０４において肯定判断をするまでＳ７０４に留まる。サーバ４はＳ７０４において肯定判断をすると、すなわち受信したと判断するとＳ７０５に進みＤＢ４４１を更新して図１２に示す処理を終了する。なおＳ７０５におけるＤＢ４４１の更新は、Ｓ７０３において配信した更新本体により送信先の装置のプログラムのバージョン番号が最新に書き換えられたことの記録である。

上述した実施の形態によれば、次の作用効果が得られる。
（１）ＴＣＵ１は、バッテリ２を備える車両５に搭載され、車両５に搭載されるＥＣＵ３０やＧＷ３５のプログラムを更新する。ＴＣＵ１は、バッテリ２の残容量の情報であるバッテリ残量を取得する電源管理部１１１と、プログラムの更新に関する情報である更新情報１７１を通信により取得する更新情報取得部１１２と、更新情報１１２およびバッテリ残量に基づき更新するプログラムを決定する更新プログラム決定部１１３と、更新プログラム決定部１１３の決定に基づき更新本体１７９を取得する更新本体取得部１１４と、更新本体１７９を他の装置に送信しプログラムの更新を実行させる転送部１１５とを備える。そのためバッテリ残量に応じて更新するプログラムを適切に選択するので、バッテリ残量を考慮したプログラムの更新ができる。

（２）更新プログラム決定部は、更新情報に含まれるプログラムごとの優先度に基づき更新するプログラムを決定する。そのため重要な更新を優先的に実行できる。

（３）更新情報１７１には同時に更新すべきプログラムを示す関連情報が含まれ、更新プログラム決定部１１３は、関連情報に基づき更新するプログラムを決定する。そのため複数のプログラムを矛盾なく更新することができる。

（４）更新プログラム決定部１１３は、更新本体１７９を取得する消費電力に基づき更新するプログラムを決定する。そのため更新本体１７９をダウンロードしている最中に電力が不足し、ダウンロードを中断することを避けられる。

（５）更新本体取得部１１４の通信状態を監視する監視部１１６を備える。更新プログラム決定部は１１３、監視部１１６の監視結果である受信強度およびノイズレベル、受信係数が記載された受信強度表１７３、ならびにノイズ係数が記載されたノイズレベル表１７４に基づき消費電力を補正する。具体的には式１に示したように、更新本体１７９のダウンロードに要すると見込まれる時間に受信係数およびノイズ係数をかけ合わせて取得コストを算出する。そのためＴＣＵ１は、通信状態を考慮して更新本体１７９の取得コストを算出できる。

（６）更新本体取得部１１４は、車両５のイグニションスイッチがオフの際に更新本体１７９を取得する。そのためＴＣＵ１は、通信による情報の取得など車両５の稼働を阻害することなく更新本体１７９をサーバ４から取得できる。

（７）転送部１１５は、車両５のイグニションスイッチがオフの際に更新本体１７９を他の装置に送信しプログラムの更新を実行させる。そのためＴＣＵ１は、車両５の稼働を阻害することなくプログラムを更新できる。詳述すると、プログラムの更新にはプログラムの動作を一時停止することがあるので、イグニッションスイッチがオンの際に更新を実行すると不都合が生じる可能性がある。しかしイグニションスイッチがオフの際にはそのような問題が生じない。

（変形例１）
上述した実施の形態では、取得データの決定に取得コストと更新コストの両方を考慮した。しかし取得データの決定には取得コストのみを考慮し、その後に更新コストを考慮してプログラムごとに更新の可否を判断してもよい。

（変形例２）
上述した実施の形態では、ＴＣＵ１は車両５のイグニションスイッチがオフにされると図１１のＳ６０１の処理を開始した。しかしＴＣＵ１は、Ｓ６０１を実行する前に取得済みであるがまだ転送していない更新本体１７９がフラッシュメモリ１７に存在するか否かを判断し、そのような更新本体１７９が存在する場合には以下のように処理してもよい。すなわちＴＣＵ１は、サーバ４から新たに更新情報１７１を取得することなくＳ６１６に進み、転送部１１５にフラッシュメモリ１７に格納されている更新本体１７９を送信させる。なお転送していない更新本体１７９の優先度を確認し、優先度がＡの場合のみＳ６１３に進み、優先度がＡ以外の場合はＳ６０１から処理を開始してもよい。

（変形例３）
図１１のＳ６０２において肯定判断がされた場合に、取得済みであるがまだ転送していない更新本体１７９がフラッシュメモリ１７に存在するか否かを判断し、そのような更新本体１７９が存在する場合には、Ｓ６１３に進んでもよい。

（変形例４）
監視部１１６は、サーバ４との通信の混雑度を加味してもよい。たとえばサーバ４が他の装置との間で大量にデータ伝送を行っている場合やサーバ４の周辺のネットワークが混雑している場合には、無線通信部１４の通信が良好であっても更新本体１７９のダウンロードは低速になる。監視部１１６はたとえばtracerouteコマンド、またはtracertコマンドによりサーバ４までの通信経路および各経路間の応答時間を取得し、この応答時間によって混雑度を評価できる。評価した混雑度は、たとえば混雑係数として式１の右辺に追加して取得コストに反映できる。この変形例４によれば、通信ネットワークの混雑度を考慮することができる。

（変形例５）
上述した実施の形態では、サーバ４は１つの物理的な装置であった。しかしサーバ４が有する機能を複数の物理的な装置で分担してもよい。たとえばサーバ４の機能を２つの異なる装置に分担させ、一方は要求に応じて更新本体１７９を提供する機能を有し、他方はその余の機能を有してもよい。この変形例５によれば、サーバ４を様々な形態で実現でき、容易にスケールアウトが可能である。

（変形例６）
ＴＣＵ１とＥＣＵ３０との接続形態は上述した実施の形態に示した例に限定されない。すなわち上述した実施の形態では、ＥＣＵ３０はＧＷ３５を介してＴＣＵ１と接続されたが、ＧＷ３５を介さずにＴＣＵ１と直接に接続されてもよい。またＧＷ３５以外に１または複数の装置を介してＴＣＵ１と接続されてもよい。

（変形例７）
上述した実施の形態では、ＴＣＵ１、ＥＣＵ３０、およびＧＷ３５を更新可能機器とした。しかしいずれかの機器がプログラムを更新可能であればよい。特にＴＣＵ１がＴＣＵ１のプログラムを更新しなくてもよい。

（変形例８）
上述した実施の形態では、それぞれの更新可能機器は１つのプログラムのみを更新対象とした。しかし１つの更新可能機器が複数のプログラムを更新可能であってもよい。この場合は、更新可能機器ごとに、更新情報１７１および現状情報１７２においてプログラムが識別可能に記載されればよい。

（変形例９）
上述した実施の形態では、消費電力やコストを装置を稼働可能な時間で代替した。しかし時間以外で代替してもよいし、電力そのものを用いて演算を行ってもよい。

上述した各実施の形態および変形例において、プログラムはＲＯＭ１２に格納されるとしたが、プログラムはフラッシュメモリ１７に格納されていてもよい。また、ＴＣＵ１が不図示の入出力インタフェースを備え、必要なときに入出力インタフェースとＴＣＵ１が利用可能な媒体を介して、他の装置からプログラムが読み込まれてもよい。ここで媒体とは、例えば入出力インタフェースに着脱可能な記憶媒体、または通信媒体、すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号、を指す。また、プログラムにより実現される機能の一部または全部がハードウエア回路やＦＰＧＡにより実現されてもよい。

上述した各実施の形態および変形例は、それぞれ組み合わせてもよい。上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

１…ＴＣＵ
２…バッテリ
４…サーバ
５…車両
１４…無線通信部
１７…フラッシュメモリ
１１１…電源管理部
１１２…更新情報取得部
１１３…更新プログラム決定部
１１４…更新本体取得部
１１５…転送部
１１６…監視部
１７１…更新情報
１７２…現状情報
１７３…受信強度表
１７４…ノイズレベル表
１７５…通過数表
１７６…優先度表
１７９…更新本体

Claims (10)

1. バッテリを備える車両に搭載され前記車両に搭載される他の装置のプログラムを更新する車載装置であって、
   前記バッテリの残容量の情報であるバッテリ残量を取得する電源管理部と、
   プログラムの更新に関する情報である更新情報を通信により取得する更新情報取得部と、
   前記更新情報および前記バッテリ残量に基づき更新するプログラムを決定する更新プログラム決定部と、
   前記更新プログラム決定部の決定に基づきプログラムを更新する情報である更新本体を通信により取得する更新本体取得部と、
   前記更新本体を前記他の装置に送信しプログラムの更新を実行させる転送部とを備える車載装置。
2. 請求項１に記載の車載装置において、
   前記更新プログラム決定部は、前記更新情報に含まれるプログラムごとの優先度に基づき更新するプログラムを決定する車載装置。
3. 請求項１または請求項２に記載の車載装置において、
   前記更新情報には同時に更新すべきプログラムを示す関連情報が含まれ、
   前記更新プログラム決定部は、前記関連情報に基づき更新するプログラムを決定する車載装置。
4. 請求項１から請求項３までのいずれか一項に記載の車載装置において、
   前記更新プログラム決定部は、プログラムを取得する消費電力に基づき更新するプログラムを決定する車載装置。
5. 請求項４に記載の車載装置において、
   前記更新本体取得部の通信状態を監視する監視部をさらに備え、
   前記更新プログラム決定部は、前記監視部の監視結果に基づき前記消費電力を補正する車載装置。
6. 請求項１から請求項５までのいずれか一項に記載の車載装置において、
   前記更新本体を格納する格納部をさらに備え、
   前記更新情報取得部は、前記格納部に前記更新本体が格納されている場合は、新たに前記更新情報を取得することなく前記転送部に前記格納部に格納されている前記更新本体を送信させる車載装置。
7. 請求項１から請求項６までのいずれか一項に記載の車載装置において、
   前記更新本体取得部は、前記車両のイグニションスイッチがオフの際に前記更新本体を取得する車載装置。
8. 請求項１から請求項７までのいずれか一項に記載の車載装置において、
   前記転送部は、前記車両のイグニションスイッチがオフの際に前記更新本体を前記他の装置に送信しプログラムの更新を実行させる車載装置。
9. バッテリを備える車両に搭載され前記車両に搭載される他の装置のプログラムを更新するプログラムの更新方法であって、
   前記バッテリの残容量の情報であるバッテリ残量を取得することと、
   プログラムの更新に関する情報である更新情報を通信により取得することと、
   前記更新情報および前記バッテリ残量に基づき更新するプログラムの決定を行うことと、
   前記決定に基づきプログラムを更新する情報である更新本体を通信により取得することと、
   前記更新本体を前記他の装置に送信しプログラムの更新を実行させることとを含むプログラムの更新方法。
10. バッテリを備える車両に搭載され前記車両に搭載される他の装置のプログラムを更新する車載装置、および前記車載装置と通信可能なサーバを備えるプログラム更新システムであって、
    前記車載装置は、
    前記バッテリの残容量の情報であるバッテリ残量を取得する電源管理部と、
    前記他の装置に関する情報を現状情報として前記サーバに送信し、前記サーバからプログラムの更新に関する情報である更新情報を取得する更新情報取得部と、
    前記更新情報および前記バッテリ残量に基づき更新するプログラムを決定する更新プログラム決定部と、
    前記更新プログラム決定部の決定に基づきプログラムを更新する情報である更新本体を通信により取得する更新本体取得部と、
    前記更新本体を前記他の装置に送信しプログラムの更新を実行させる転送部とを備え、
    前記サーバは、
    受信した前記現状情報に基づき前記更新情報を作成し前記車載装置に送信する更新情報作成部を備えるプログラム更新システム。
    

Images