特許 6185789 車載ソフトウェア更新装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6185789

(24)【登録日】2017年8月4日

(45)【発行日】2017年8月23日

(54)【発明の名称】車載ソフトウェア更新装置

(51)【国際特許分類】

   G06F 11/00 20060101AFI20170814BHJP

   G06F 9/445 20060101ALI20170814BHJP

【ＦＩ】

   G06F9/06 630A

   G06F9/06 640A

【請求項の数】4

【全頁数】15

(21)【出願番号】特願2013-173296(P2013-173296)

(22)【出願日】2013年8月23日

(65)【公開番号】特開2015-41334(P2015-41334A)

(43)【公開日】2015年3月2日

【審査請求日】2016年7月19日

(73)【特許権者】

【識別番号】501418498

【氏名又は名称】矢崎エナジーシステム株式会社

(74)【代理人】

【識別番号】110002000

【氏名又は名称】特許業務法人栄光特許事務所

(74)【代理人】

【識別番号】100105474

【弁理士】

【氏名又は名称】本多 弘徳

(74)【代理人】

【識別番号】100177910

【弁理士】

【氏名又は名称】木津 正晴

(72)【発明者】

【氏名】中尾 照人

【審査官】 圓道 浩史

(56)【参考文献】

【文献】 特開２０００−２０７６８１（ＪＰ，Ａ）

【文献】 特開２００６−１６４０３０（ＪＰ，Ａ）

【文献】 特開２００６−１４３０４９（ＪＰ，Ａ）

【文献】 特開２００３−２０４３０７（ＪＰ，Ａ）

【文献】 特開２００９−０２７６６９（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／００

Ｇ０６Ｆ １１／００

Ｇ０６Ｆ ９／４４５

Ｂ６０Ｒ １６／０２

(57)【特許請求の範囲】

【請求項1】

データの集合及びプログラムの少なくとも一方を含むソフトウェアを情報として保持する、データ書き換えが可能なソフトウェア保持用メモリと、
車両外部の機器との間で無線通信が可能な無線通信モジュールと、
予め定めた条件を満たした時に、前記ソフトウェア保持用メモリが保持している第１のソフトウェアと関連がある第２のソフトウェアを前記無線通信モジュールを介してダウンロードし、前記ソフトウェア保持用メモリ上の前記第１のソフトウェアを前記第２のソフトウェアに置き換える更新処理を制御するソフトウェア更新制御部と、
を備え、
前記ソフトウェア更新制御部は、前記更新処理の最初の処理として、前記第２のソフトウェアの最初の一部分のダウンロードを実行すると共にこのダウンロードが正常に完了したか否かを判定し、
このダウンロードが正常に完了していないと判定した場合、前記更新処理を中止し、
このダウンロードが正常に完了したと判定した場合、前記更新処理の前記最初の処理に続く処理として、前記第１のソフトウェアの少なくとも一部分のデータを消去または無効化してメモリ空き領域を確保し、前記第２のソフトウェアの残りの部分のダウンロードを実行すると共にダウンロードした前記第２のソフトウェアを前記メモリ空き領域に書き込み、
前記ソフトウェア更新制御部は、前記更新処理が異常終了したことを検知した場合には、前記第１のソフトウェアを前記無線通信モジュールを介してダウンロードし、ダウンロードした前記第１のソフトウェアを前記メモリ空き領域に書き込む、
ことを特徴とする車載ソフトウェア更新装置。

【請求項2】

請求項１に記載の車載ソフトウェア更新装置であって、
自車両の現在位置を表す位置情報を取得する位置情報取得部と、
前記位置情報取得部が取得した位置情報に基づき自車両が事前に定めた領域の範囲内にあるか否かを識別すると共に、自車両の位置が前記範囲内に属している期間の長さに応じて自車両の入庫及び出庫の状態を識別する入庫出庫識別部と、
を更に備え、
前記ソフトウェア更新制御部は、前記入庫出庫識別部が、自車両の入庫状態を検出している場合に、前記更新処理を開始する、
ことを特徴とする車載ソフトウェア更新装置。

【請求項3】

請求項１又は請求項２に記載の車載ソフトウェア更新装置であって、
前記ソフトウェア更新制御部は、前記無線通信モジュールが利用する無線通信回線の通信環境が所定の条件を満たさない場合に、前記更新処理の開始を禁止する、
ことを特徴とする車載ソフトウェア更新装置。

【請求項4】

請求項１に記載の車載ソフトウェア更新装置であって、
前記ソフトウェア更新制御部は、前記更新処理において、前記第２のソフトウェアのダウンロードが完了しなかった場合であって該第２のソフトウェアをダウンロードした回数が規定回数未満のとき、前記第２のソフトウェアを再びダウンロードする、
ことを特徴とする車載ソフトウェア更新装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、車両に搭載された電子機器が無線通信機能を利用してソフトウェアを更新する更新処理に関し、特に、その更新処理を制御する車載ソフトウェア更新装置に関する。

【背景技術】

【0002】

従来より、車両には様々な電子機器が車載器として搭載されている。近年の様々な車載器は、マイクロコンピュータの動作を決定するプログラムやデータなどを含むソフトウェアを搭載している。このようなソフトウェアについては、動作の不具合を修正するために、あるいは機能の変更や追加を行うために日常的にあるいは定期的に新しいバージョンのソフトウェアに更新されることがある。

【0003】

特許文献１は、車載器である地図データ利用装置またはナビゲーション装置において、ユーザにとってより必要性が高い範囲の地図データを、更新のタイミングをユーザに委ねることなく適時に更新するための技術を開示している。また、特許文献１の技術では、車載器を無線通信装置を介して情報配信センタと接続し、地図データを情報配信センタからダウンロードした新しいバージョンのデータに自動更新するように制御している。

【0004】

また、特許文献２は、車載器のための技術ではないが、アプリケーションプログラムを更新インストールする場合に、様々な問題が発生する可能性があることが示唆されている（段落０００３及び０００４）。

【0005】

また、特許文献３は、車両の入庫及び出庫を自動的に識別するための技術を開示している。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特開２００８−９００５７号公報

【特許文献2】特開２００７−２０００４０号公報

【特許文献3】特開２０１１−２２７５５２号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

ところで、車載器のソフトウェアを新たなものに更新する際には、更新の失敗に備えて、現行ソフトウェアを削除せずにそのまま保持しておく必要がある。そのため、新たなソフトウェアを書き込むために必要な記憶容量に比べて十分に余裕のある、比較的大容量の記憶装置（不揮発性メモリなど）を用意せねばならない。言い換えると、車載器を動かすために必要な特定のソフトウェアを保持するために必要なメモリ容量に比べて大きな容量の記憶装置が必要になる。これが車載器のコスト増に繋がる。近年、確かに記憶装置の容量あたりのコストは減る傾向にあるが、車載器の機能がますます複雑化しているため、該車載器に用いられるソフトウェアを保持するために必要なメモリ容量も増大する傾向にある。このため、記憶装置のコストの増大を抑制することは難しい。

【0008】

また、車載器のソフトウェアを新たなものに更新する際には、現行ソフトウェアを車載器の記憶装置上から削除して、空いている記憶領域を確保してから新たなソフトウェアをインストールすることも考えられる。その場合には、新旧の両方のソフトウェアを保持するための記憶領域を確保する必要がないため、記憶装置に必要とされる容量を大幅に減らすことができる。

【0009】

しかしながら、特に特許文献１のように無線通信を利用して新しいソフトウェアをダウンロードするような場合には、ダウンロードに失敗したり、データエラーの発生により新しいソフトウェアのインストールに失敗する可能性も高くなる。このような事態が発生すると、現行ソフトウェアが既に削除されているため、車載器が全く動作しなくなる可能性がある。その結果、特別な修復作業が必要になり、記憶装置のコスト増を抑制した以上の余分な修理コストが必要になる。また、修復を完了するまでは車載器を利用できないことは、特に業務用途の車載器の場合には大きな問題になる。

【0010】

本発明は、上述した事情に鑑みてなされたものであり、その目的は、車載器におけるソフトウェアの更新のために必要な記憶装置の容量の増大を抑制すると共に、ソフトウェアの更新の際に何らかの問題が生じた場合であっても、車載器を継続的に使用することが可能な車載ソフトウェア更新装置を提供することにある。

【課題を解決するための手段】

【0011】

前述した目的を達成するために、本発明に係る車載ソフトウェア更新装置は、下記（１）〜（４）を特徴としている。
（１） データの集合及びプログラムの少なくとも一方を含むソフトウェアを情報として保持する、データ書き換えが可能なソフトウェア保持用メモリと、
車両外部の機器との間で無線通信が可能な無線通信モジュールと、
予め定めた条件を満たした時に、前記ソフトウェア保持用メモリが保持している第１のソフトウェアと関連がある第２のソフトウェアを前記無線通信モジュールを介してダウンロードし、前記ソフトウェア保持用メモリ上の前記第１のソフトウェアを前記第２のソフトウェアに置き換える更新処理を制御するソフトウェア更新制御部と、
を備え、
前記ソフトウェア更新制御部は、前記更新処理の最初の処理として、前記第２のソフトウェアの最初の一部分のダウンロードを実行すると共にこのダウンロードが正常に完了したか否かを判定し、
このダウンロードが正常に完了していないと判定した場合、前記更新処理を中止し、
このダウンロードが正常に完了したと判定した場合、前記更新処理の前記最初の処理に続く処理として、前記第１のソフトウェアの少なくとも一部分のデータを消去または無効化してメモリ空き領域を確保し、前記第２のソフトウェアの残りの部分のダウンロードを実行すると共にダウンロードした前記第２のソフトウェアを前記メモリ空き領域に書き込み、
前記ソフトウェア更新制御部は、前記更新処理が異常終了したことを検知した場合には、前記第１のソフトウェアを前記無線通信モジュールを介してダウンロードし、ダウンロードした前記第１のソフトウェアを前記メモリ空き領域に書き込む、
こと。
（２） 上記（１）の構成の車載ソフトウェア更新装置であって、
自車両の現在位置を表す位置情報を取得する位置情報取得部と、
前記位置情報取得部が取得した位置情報に基づき自車両が事前に定めた領域の範囲内にあるか否かを識別すると共に、自車両の位置が前記範囲内に属している期間の長さに応じて自車両の入庫及び出庫の状態を識別する入庫出庫識別部と、
を更に備え、
前記ソフトウェア更新制御部は、前記入庫出庫識別部が、自車両の入庫状態を検出している場合に、前記更新処理を開始する、
こと。
（３） 上記（１）又は（２）の構成の車載ソフトウェア更新装置であって、
前記ソフトウェア更新制御部は、前記無線通信モジュールが利用する無線通信回線の通信環境が所定の条件を満たさない場合に、前記更新処理の開始を禁止する、
こと。
（４） 上記（１）の構成の車載ソフトウェア更新装置であって、
前記ソフトウェア更新制御部は、前記更新処理において、前記第２のソフトウェアのダウンロードが完了しなかった場合であって該第２のソフトウェアをダウンロードした回数が規定回数未満のとき、前記第２のソフトウェアを再びダウンロードする、
こと。

【0012】

上記（１）の構成の車載ソフトウェア更新装置によれば、第１のソフトウェアを消去または無効化してメモリ空き領域を確保した後で前記第２のソフトウェアの本体をダウンロードするので、ソフトウェアの更新のために記憶装置の容量を大幅に増やす必要がない。しかも、無線通信環境の劣化などに伴って前記更新処理が異常終了した場合には、第１のソフトウェアがダウンロードされてソフトウェア保持用メモリに書き込まれるので、該当する車載器は更新前の状態でそのまま使用することができる。
上記（２）の構成の車載ソフトウェア更新装置によれば、無線通信環境が良好である可能性が高く、且つソフトウェア更新中に自車両が別の場所に移動する可能性が低い状態で、前記更新処理を開始することができる。したがって、ソフトウェアの更新に失敗する頻度を大幅に減らすことができる。
上記（３）の構成の車載ソフトウェア更新装置によれば、無線通信環境が良好でない時には更新処理を開始しないように制御できるので、ソフトウェアの更新に失敗する頻度を大幅に減らすことができる。
上記（４）の構成の車載ソフトウェア更新装置によれば、無線通信環境の一時的な悪化などによってダウンロードに失敗した場合であっても、規定回数未満であれば第２のソフトウェアのダウンロードを繰り返すので、第２のソフトウェアへの更新に成功する可能性を高めることができる。

【発明の効果】

【0013】

本発明の車載ソフトウェア更新装置によれば、車載器におけるソフトウェアの更新のために必要な記憶装置の容量の増大を抑制すると共に、ソフトウェアの更新の際に何らかの問題が生じた場合であっても、車載器を継続的に使用することが可能になる。

【0014】

以上、本発明について簡潔に説明した。更に、以下に説明される発明を実施するための形態（以下、「実施形態」という。）を添付の図面を参照して通読することにより、本発明の詳細は更に明確化されるであろう。

【図面の簡単な説明】

【0015】

【図1】図１は、本発明の実施形態のテレマティクス車載端末のソフトウェア更新制御部の処理を示すフローチャートである。

【図2】図２は、本発明の実施形態のテレマティクス車載端末の構成例を示すブロック図である。

【図3】図３は、入庫出庫識別部の処理を示すフローチャートである。

【図4】図４は、拠点に入庫した時の車両位置の具体例を示す斜視図である。

【発明を実施するための形態】

【0016】

本発明の車載ソフトウェア更新装置に関する具体的な実施形態について、各図を参照しながら以下に説明する。

【0017】

＜装置の概要の説明＞
本発明の車載ソフトウェア更新装置を搭載したテレマティクス車載端末１０の構成例を図２に示す。本実施形態のテレマティクス車載端末１０は、例えばタクシー、トラック、バスのように業務用で使用される車両に搭載した状態で使用することを想定している。

【0018】

したがって、このテレマティクス車載端末１０を搭載した業務用車両は、運行業務を行わない時には運送事業者の事務所等の拠点に配置された駐車場に入庫した状態にあり、運行業務を行う時に駐車場から出庫して移動し、毎日の運行業務が終了すると再び駐車場に戻って入庫状態になる。

【0019】

テレマティクス車載端末１０の基本的な機能は、車両上で収集した様々な情報を無線データ通信により車両外の所定のサーバに送信したり、車両外の所定のサーバから無線データ通信により受信したデータに基づいて様々な制御を実施することである。この機能の他に、テレマティクス車載端末１０は本発明の車載ソフトウェア更新装置の機能もソフトウェアとして搭載している。即ち、テレマティクス車載端末１０は、自身（テレマティクス車載端末１０）の機能を実現するために必要な各種のソフトウェア、またはテレマティクス車載端末１０に接続されている他の車載器の機能を実現するために必要な各種のソフトウェアを、自車両の外側に存在する所定のサーバから無線データ通信により取得する。そして、テレマティクス車載端末１０は、取得したソフトウェアを自身（テレマティクス車載端末１０）または他の車載器に自動的に更新する。

【0020】

更新対象のソフトウェアについては、車載器専用の制御用プログラム、オペレーティングシステム、アプリケーションプログラム、各種データベースなどが想定される。なお、本実施形態ではテレマティクス車載端末１０に車載ソフトウェア更新装置を搭載しているが、他の様々な車載器に車載ソフトウェア更新装置を搭載しても良い。

【0021】

＜装置の構成＞
図２に示すように、テレマティクス車載端末１０の本体は、制御部１１、無線通信モジュール１２、ＧＰＳモジュール１３、外部インタフェース（Ｉ／Ｆ）１４、表示部１５、不揮発性メモリ１６、操作インタフェース１７、操作部１８、デジタル５ｃｈ入力インタフェース１９、回転インタフェース２０、速度インタフェース２１、及び電源部２２を備えている。

【0022】

制御部１１は、マイクロコンピュータを主体とするハードウェアにより構成されている。制御部１１のマイクロコンピュータは、テレマティクス車載端末１０上に用意されているプログラムを実行することにより、テレマティクス車載端末１０の機能を実現するための制御を行うことができる。

【0023】

制御部１１のマイクロコンピュータが実行するプログラムの中には、車載ソフトウェア更新装置のプログラムも含まれている。車載ソフトウェア更新装置の機能として、ソフトウェア更新制御部１１ａ及び入庫出庫識別部１１ｂが制御部１１に備わっている。これらの機能は、制御部１１のマイクロコンピュータがプログラムを実行することにより実現する。

【0024】

無線通信モジュール１２は、通信アンテナ３１を介して、例えば移動体通信事業者等が提供する無線通信システムに含まれる所定の無線基地局との間で無線通信を行い、データ通信のために必要な無線通信回線を確保することができる。

【0025】

ＧＰＳモジュール１３は、ＧＰＳアンテナ３２を介して複数のＧＰＳ（Global Positioning System）からそれぞれ送信される電波を受信し、受信した信号のタイミングに基づいて自車両の現在位置（緯度／経度）を算出することができる。

【0026】

外部インタフェース１４は、外部機器３３としてテレマティクス車載端末１０に接続される車両上の様々な車載器との間でデータ通信を行うための接続機能を提供する。具体的な外部機器３３としては、カーナビゲーション装置、ドライブレコーダ、デジタルタコグラフ、ＥＴＣ車載器、メータユニット、タクシーメータ、電子制御装置（ＥＣＵ）などが想定される。

【0027】

表示部１５は、例えばテレマティクス車載端末１０の動作状態や、ユーザの行うべき操作などの情報をユーザに知らせるために、文字等の可視情報を必要に応じて画面上に表示することができる。

【0028】

不揮発性メモリ１６は、例えばフラッシュメモリのようにデータの読み出し及びデータの書き換えが可能なメモリにより構成されており、制御部１１のマイクロコンピュータが実行可能な各種のプログラムやデータなど（ソフトウェア）を保持している。

【0029】

不揮発性メモリ１６が保持する各種ソフトウェアの内容については、無線通信モジュール１２を介して所定のサーバからダウンロードすることにより新しいバージョンに随時更新することができる。この更新作業は、制御部１１に備わっている車載ソフトウェア更新装置の機能により自動的に行うことができる。

【0030】

操作部１８は、ユーザが操作可能な複数のボタンを備えている。これらのボタンは、テレマティクス車載端末１０に対してユーザが指示を与えるために使用される。操作部１８は、操作インタフェース１７を介して制御部１１と接続されている。つまり、ユーザが操作部１８のボタンを操作することにより、制御部１１のマイクロコンピュータに指示を与えることができる。

【0031】

デジタル５ｃｈ入力インタフェース１９は、車両側に備わっている各種センサ３４からそれぞれ出力される複数のデジタル信号を各々処理して、各信号の情報を制御部１１に与えることができる。

【0032】

回転インタフェース２０は、車両側に備わっているエンジン回転センサ３５から出力される回転パルス信号を、制御部１１のマイクロコンピュータの処理に適した信号に変換する。エンジン回転センサ３５は、エンジンの出力軸が所定量回転する毎にパルス信号を出力することができる。したがって、この回転パルス信号により、エンジンの回転速度を把握することができる。

【0033】

速度インタフェース２１は、車両側に備わっている速度センサ３６から出力される速度パルス信号を、制御部１１のマイクロコンピュータの処理に適した信号に変換する。速度センサ３６は、車両の変速機の出力軸が所定量回転する毎にパルス信号を出力することができる。したがって、この速度パルス信号のパルス数やパルス周期に基づいて、車両の移動量や移動速度を把握することができる。

【0034】

電源部２２は、車両側電源３７から供給される直流電力に基づいて、テレマティクス車載端末１０内の各回路が必要とする安定した直流電源電圧を生成する。車両側電源３７は、車載バッテリーや発電機（オルタネータ）などであり、イグニッションスイッチのオンオフと連動した信号も出力することができる。

【0035】

＜装置の動作＞
＜ソフトウェア更新制御部１１ａの処理＞
ソフトウェア更新制御部１１ａの処理の内容を図１に示す。テレマティクス車載端末１０を搭載した車両のイグニッションスイッチがオンになり、テレマティクス車載端末１０への電源電力の供給が開始されると、所定のタイミングで図１に示す処理が実行される。

【0036】

最初のステップＳ１１では、制御部１１は自車両の状態が入庫状態か否かを識別する。即ち、入庫出庫識別部１１ｂの識別結果により、自車両の状態を把握する。入庫状態であることを検出すると次のステップＳ１２に進む。

【0037】

ステップＳ１２では、制御部１１は、無線通信モジュール１２及び通信アンテナ３１を用いて無線通信回線を確保し、例えば所定のデータセンターあるいは事務所等に配置されているサーバとテレマティクス車載端末１０とがデータ通信できるように無線通信回線を経由して接続する。更に、制御部１１はサーバ上に使用可能な新しいソフトウェアが登録されているか否かを識別し、該当するソフトウェアが登録されている場合には、当該ソフトウェアのダウンロードを開始するための最初の処理を実行する。具体的には、当該ソフトウェアの最初の１ブロックに関する送信要求をテレマティクス車載端末１０からサーバに送り、この要求に応答してサーバが送信する最初の１ブロックのデータを、テレマティクス車載端末１０の制御部１１が受信する。

【0038】

なお、伝送するデータのブロックについては、使用する通信回線等の通信仕様等に応じて事前に決定される最小限の大きさのデータのかたまりを意味している。例えば、伝送するデータのサイズがサイズ上限値（例えば５００バイト）を超えると、無線通信回線を提供する事業者のシステム側で自動的にデータを複数に分割するような通信仕様である場合がある。この場合には、テレマティクス車載端末１０側が予期していない箇所で勝手にデータの分割が生じるのを未然に防止する必要があるため、前記サイズ上限値よりも小さい、例えば４００バイト以下のサイズのブロック毎にテレマティクス車載端末１０がデータを分割してからブロック単位でデータを送信する。したがって、伝送するデータのブロックのサイズについては、必要に応じて変更される。

【0039】

また、図１において、「新ソフトウェア」は、「現行ソフトウェア」と同じ種類に属し且つある程度の互換性を有するソフトウェアを意味し、「新ソフトウェア」は、相対的に「現行ソフトウェア」よりも新しいソフトウェアを意味する。代表例としては、「新ソフトウェア」のプログラムは、「現行ソフトウェア」のプログラムと互換性を有する、より新しいバージョンのソフトウェアである。

【0040】

ステップＳ１３では、制御部１１は、ステップＳ１２で伝送開始した最初の１ブロックのデータについて、ダウンロードを正常に完了したか否かを識別する。ダウンロードを正常に完了した場合はステップＳ１５に進み、正常に完了してなければステップＳ１４に進む。

【0041】

例えば、無線通信モジュール１２と無線基地局との間の無線通信環境が悪化しているような場合には、１ブロックのデータを伝送する間に、データエラーが発生したり、一時的に或いは継続的にデータ通信ができない状況が発生する可能性がある。そして、例えば所定時間が経過するまでの間に１ブロックのデータ全体のダウンロードが完了しないと、ステップＳ１３からステップＳ１４に進む。つまり、一時的な無線通信環境の悪化が原因であったとしても、ダウンロード対象のソフトウェアの一部分である最初の１ブロックのダウンロードに失敗することは、該当するソフトウェア全体の正常なダウンロードが困難な状況であることを意味し、ダウンロードを中止することが望ましい。

【0042】

ステップＳ１４では、制御部１１は、テレマティクス車載端末１０が該当するソフトウェアのダウンロードを中止することを表す情報を無線通信モジュール１２を経由してサーバへ通知する。また、ダウンロードを中止する理由が無線通信環境の悪化等であることを意味する情報を同時にサーバに通知する。

【0043】

ステップＳ１５では、制御部１１は、不揮発性メモリ１６上に保持されている更新対象の「現行ソフトウェア」の全体を、不揮発性メモリ１６上から消去する。これにより、該当する「現行ソフトウェア」が占有していた不揮発性メモリ１６上の記憶領域が開放されて新たな空き領域になるため、「新ソフトウェア」を保存するための記憶領域を容易に確保可能になる。つまり、過去に「現行ソフトウェア」が占有していた記憶領域を、「新ソフトウェア」を保存するための記憶領域として確保することができる。

【0044】

ステップＳ１６では、制御部１１は、ステップＳ１２でダウンロード対象とした特定のソフトウェアの２番目のブロックから最終ブロックまでのデータについて、ダウンロードのための処理を続行するようにサーバに対して要求する。

【0045】

この要求に応答して、サーバは該当するソフトウェアの２番目以降のブロックのデータをブロック単位で順次に送信する。テレマティクス車載端末１０の制御部１１は、サーバから送信された「新ソフトウェア」の各ブロックを受信し、この受信データをステップＳ１５で確保した不揮発性メモリ１６上の空き領域に順次に保存する。

【0046】

ステップＳ１７では、制御部１１は、「新ソフトウェア」の２番目のブロック以降、最終ブロックまでの全てのデータを正常な状態でダウンロード完了したか否かを識別する。正常にダウンロード完了した場合はステップＳ１８に進み、何らかの異常が発生した場合はステップＳ１９に進む。

【0047】

ステップＳ１８では、制御部１１は、今回のダウンロードが全て成功し、「新ソフトウェア」への更新が完了したことを表す状況を意味する終了状態情報を不揮発性メモリ１６上に記憶する。また、この終了状態情報をＳ２６で無線通信モジュール１２を経由してサーバに通知する。

【0048】

ステップＳ１９では、制御部１１は、テレマティクス車載端末１０自身が該当する「新ソフトウェア」のダウンロードを繰り返した回数Ｃｎを把握し、この回数Ｃｎを事前に定めた規定回数Ｃｍａｘと比較する。「Ｃｎ＞Ｃｍａｘ」の場合はステップＳ２１に進み、「Ｃｎ≦Ｃｍａｘ」の場合はステップＳ２０に進む。

【0049】

ステップＳ２０では、制御部１１は、ステップＳ１２でダウンロード対象とした特定のソフトウェアを再びダウンロード対象に指定し、該当するソフトウェアの最初の１ブロックのデータを送信するように、サーバに対して要求する。また、ダウンロードの回数Ｃｎを把握するためのカウンタをカウントアップする。

【0050】

ステップＳ２１では、制御部１１は、ステップＳ１２でダウンロード対象とした特定のソフトウェアと対応関係にある「現行ソフトウェア」をダウンロード対象に指定し、該当するソフトウェアの１番目のブロックから最終ブロックまでの全体のデータを送信するように、サーバに対して要求する。また、「現行ソフトウェア」ダウンロードの回数Ｃ０ｎを把握するためのカウンタをカウントアップする。

【0051】

上記のテレマティクス車載端末１０の要求に応答して、サーバは該当する「現行ソフトウェア」の全てのブロックのデータをブロック単位で順次に送信する。テレマティクス車載端末１０の制御部１１は、サーバから送信された「現行ソフトウェア」の各ブロックを受信し、この受信データをステップＳ１５で確保した不揮発性メモリ１６上の空き領域に順次に保存する。

【0052】

ステップＳ２２では、制御部１１は、「現行ソフトウェア」の１番目のブロックから最終ブロックまでの全てのデータを正常な状態でダウンロード完了したか否かを識別する。正常にダウンロード完了した場合はステップｐＳ２３に進み、何らかの異常が発生した場合はステップＳ２４に進む。

【0053】

ステップＳ２３では、制御部１１は、「新ソフトウェア」のダウンロードが失敗したため「現行ソフトウェア」へ戻してから更新処理を終了したことを表す終了状態情報を不揮発性メモリ１６上に記憶する。また、この終了状態情報をステップＳ２６で無線通信モジュール１２を経由してサーバに通知する。

【0054】

ステップＳ２４では、制御部１１は、テレマティクス車載端末１０自身が該当する「現行ソフトウェア」のダウンロードを繰り返した回数Ｃ０ｎを把握し、この回数Ｃ０ｎを事前に定めた規定回数Ｃ０ｍａｘと比較する。「Ｃ０ｎ＞Ｃ０ｍａｘ」の場合はステップＳ２５に進み、「Ｃ０ｎ≦Ｃ０ｍａｘ」の場合はステップＳ２１に戻って処理を繰り返す。

【0055】

ステップＳ２５では、制御部１１は、「新ソフトウェア」のダウンロードが失敗し、且つ「現行ソフトウェア」も消去してしまったことを表す終了状態情報を不揮発性メモリ１６上に記憶する。また、この終了状態情報をステップＳ２６で無線通信モジュール１２を経由してサーバに通知する。

【0056】

＜入庫出庫識別部１１ｂの処理＞
入庫出庫識別部１１ｂの処理の内容を図３に示す。また、拠点に入庫した時の車両位置の具体例を図４に示す。

【0057】

本実施形態においては、管理対象の車両が運行していない時に通常駐車している場所を拠点とし、この拠点位置（緯度経度）Ｐ０を事前にテレマティクス車載端末１０に登録してある。また、車両の入庫／出庫を区別するために定める拠点範囲は、図４に示すように拠点位置Ｐ０を中心とし、半径Ｒの円の内側とする。そして、出庫状態の車両が前記拠点範囲の内側に長時間停車していることを検知した場合に、この車両が入庫したとみなす。

【0058】

テレマティクス車載端末１０の運用を開始すると、制御部１１は図３のステップＳ３１から処理を実行する。ステップＳ３１では、制御部１１は、現在の自車両の状態が入庫か出庫かを区別するための情報を保持している車両状態メモリＭｃの内容を参照し、入庫／出庫を識別する。出庫状態の場合はステップＳ３２に進み、入庫状態の場合はステップＳ３７に進む。

【0059】

ステップＳ３２では、制御部１１は、自車両の滞在時間を管理している滞在時間メモリの値を０にクリアする。

【0060】

ステップＳ３３では、制御部１１は、自車両の現在位置Ｐｐの情報をＧＰＳモジュール１３から取得し、この現在位置Ｐｐが事前に決定した拠点範囲内か拠点範囲外かを識別する。即ち、現在位置Ｐｐと拠点位置Ｐ０との距離が半径Ｒ以内であれば拠点範囲内とみなしてステップＳ３４に進み、距離が半径Ｒを超える場合は拠点範囲外とみなしてステップＳ３２に戻る。

【0061】

ステップＳ３４では、制御部１１は、自車両の滞在時間を管理している滞在時間メモリの値を経過時間に応じてカウントアップする。

【0062】

ステップＳ３５では、制御部１１は、滞在時間メモリが保持している現在の値（現在までの滞在時間）Ｔｐを事前に定めた入庫判定時間Ｔ０と比較する。「Ｔｐ≧Ｔ０」の場合はステップＳ３６に進み、「Ｔｐ＜Ｔ０」の場合はステップＳ３３に戻る。

【0063】

ステップＳ３６では、制御部１１は、自車両の現在の状態を入庫とみなし、この状態に合わせて車両状態メモリＭｃの内容を更新する。したがって、この場合は車両状態メモリＭｃが「入庫状態」の情報を保持する。

【0064】

ステップＳ３７では、制御部１１は、自車両の現在位置Ｐｐの情報をＧＰＳモジュール１３から取得し、この現在位置Ｐｐが事前に決定した拠点範囲内か拠点範囲外かを識別する。即ち、現在位置Ｐｐと拠点位置Ｐ０との距離が半径Ｒ以内であれば拠点範囲内とみなしてステップＳ３７を繰り返し、距離が半径Ｒを超える場合は拠点範囲外に移動したとみなしてステップＳ３８に進む。

【0065】

ステップＳ３８では、制御部１１は、自車両の現在の状態を出庫とみなし、この状態に合わせて車両状態メモリＭｃの内容を更新する。したがって、この場合は車両状態メモリＭｃが「出庫状態」の情報を保持する。

【0066】

＜特徴的な動作の説明＞
＜更新処理のタイミング＞
本実施形態では、ソフトウェア更新制御部１１ａは、自車両が入庫状態であることを検出している場合に限り、ソフトウェアの更新処理を開始する（ステップＳ１１）。業務用車両が出庫状態から入庫状態になった場合には、業務終了時であるため、車両の位置が長時間に渡って変化しない可能性が高く、しかも次に車両を運行開始するまでの時間的な余裕も十分にある。

【0067】

車両の位置が変化しない時には、無線通信環境が急激に変化する可能性が小さくなる。このため、テレマティクス車載端末１０がソフトウェアをサーバからダウンロードする際に、無線通信環境の悪化によりダウンロードに失敗するような状況が生じにくくなる。

【0068】

また、次に車両を運行開始するまでに時間的な余裕がある。このため、テレマティクス車載端末１０がソフトウェアをサーバからダウンロードしている途中で、車両の運行開始によってダウンロードが中断されるような状況も生じにくい。また、ダウンロードや更新処理の途中で一部のソフトウェアが消去されてテレマティクス車載端末１０上に存在しない状況になった場合でも、次に車両の運行が開始されるまでの間に正常な状態に戻すことができれば、問題は生じない。

【0069】

＜必要なメモリ容量の削減＞
図１に示した処理のように、ソフトウェアを更新する際には、ステップＳ１５で「現行ソフトウェア」を消去して「新ソフトウェア」を保存するための記憶領域を確保する。このため、テレマティクス車載端末１０上に「現行ソフトウェア」と「新ソフトウェア」の両方を同時に保存する必要がない。したがって、ソフトウェアの更新のために必要なメモリ容量が大幅に削減される。

【0070】

＜更新処理に伴う安全性の確保＞
図１に示した処理のように、ステップＳ１５で「現行ソフトウェア」を消去する前に、ステップＳ１２で「新ソフトウェア」の一部分だけのダウンロードを実行し、このダウンロードが正常に完了したことをステップＳ１３で確認している。したがって、実際の無線通信環境が悪化しているような状況では、「現行ソフトウェア」を消去する前にその処理を自動的に中断することができる。つまり、ソフトウェアの更新における失敗の発生に伴って、「現行ソフトウェア」及び「新ソフトウェア」のいずれも使用できない状況が発生するのを未然に防止できる。

【0071】

図１に示した処理のように、「新ソフトウェア」のダウンロードに失敗したことをステップＳ１７で検知した場合には、規定回数以下であればダウンロードの処理を繰り返し実行することができる。したがって、一時的に無線通信環境が悪化したような場合には、「新ソフトウェア」を確実にダウンロードしてテレマティクス車載端末１０にインストールすることができる。

【0072】

図１に示した処理のように、「新ソフトウェア」のダウンロードに繰り返し失敗したことをステップＳ１９で検知した場合には、ステップＳ２１で「現行ソフトウェア」をサーバからダウンロードする。したがって、ステップＳ１５で「現行ソフトウェア」を消去し、その後で「新ソフトウェア」のインストールに失敗した場合であっても、更新処理を開始する前の「現行ソフトウェア」を使用できる状態に自動的に復旧させることができる。

【0073】

また、「現行ソフトウェア」のダウンロードに失敗したことをステップＳ２２で検知した場合には、規定回数以下であればダウンロードの処理を繰り返し実行することができる。したがって、一時的に無線通信環境が悪化したような場合には、「現行ソフトウェア」を確実にダウンロードしてテレマティクス車載端末１０に再インストールすることができる。

【0074】

また、図１に示した処理のように、テレマティクス車載端末１０は更新処理の結果をステップＳ２６でサーバに通知するので、多数の車両を管理する企業の管理者は、サーバが管理している情報を参照することにより、各車両における実際のソフトウェアの更新状況を容易に把握することができる。

【0075】

＜変形の可能性＞
上記の実施形態では本発明の車載ソフトウェア更新装置の機能をテレマティクス車載端末１０に内蔵しているが、車載ソフトウェア更新装置は、テレマティクス車載端末１０に限らず様々な車載器にを搭載することができる。また、テレマティクス車載端末１０以外の車載器に車載ソフトウェア更新装置を搭載する場合には、ソフトウェアのダウンロードのために必要な無線通信回線を確保するために、テレマティクス車載端末１０を利用しても良い。この場合、例えば比較的狭い範囲で通信が可能な無線ＬＡＮ装置、または様々な広域無線通信網と接続可能な広域無線通信装置を利用しても良い。

【0076】

上記の実施形態では本発明の車載ソフトウェア更新装置が、自身（テレマティクス車載端末１０）のソフトウェアを更新する場合を想定している。この形態以外に、テレマティクス車載端末１０が、テレマティクス車載端末１０に接続可能な様々な車載器のソフトウェアを、テレマティクス車載端末１０を経由して自動的に更新するように制御することもできる。

【0077】

ここで、上述した本発明に係る車載ソフトウェア更新装置の実施形態の特徴をそれぞれ以下［１］〜［４］に簡潔に纏めて列記する。
［１］ データの集合及びプログラムの少なくとも一方を含むソフトウェアを情報として保持する、データ書き換えが可能なソフトウェア保持用メモリ（不揮発性メモリ１６）と、
車両外部の機器との間で無線通信が可能な無線通信モジュール（１２）と、
予め定めた条件を満たした時に、前記ソフトウェア保持用メモリが保持している第１のソフトウェアと関連がある第２のソフトウェアを前記無線通信モジュール（１２）を介してダウンロードし、前記ソフトウェア保持用メモリ上の前記第１のソフトウェアを前記第２のソフトウェアに置き換える更新処理を制御するソフトウェア更新制御部（制御部１１のソフトウェア更新制御部１１ａ）と、
を備え、
前記ソフトウェア更新制御部は、前記第１のソフトウェアの少なくとも一部分のデータを消去または無効化して確保したメモリ空き領域に、ダウンロードした前記第２のソフトウェアを書き込み、
前記ソフトウェア更新制御部は、前記更新処理が異常終了したことを検知した場合には、前記第１のソフトウェアを前記無線通信モジュール（１２）を介してダウンロードし、ダウンロードした前記第１のソフトウェアを前記メモリ空き領域に書き込む、
ことを特徴とする車載ソフトウェア更新装置。
［２］ ［１］に記載の車載ソフトウェア更新装置であって、
自車両の現在位置を表す位置情報を取得する位置情報取得部（ＧＰＳモジュール１３）と、
前記位置情報取得部が取得した位置情報に基づき自車両が事前に定めた領域の範囲内にあるか否かを識別すると共に、自車両の位置が前記範囲内に属している期間の長さに応じて自車両の入庫及び出庫の状態を識別する入庫出庫識別部（制御部１１）
を更に備え、
前記ソフトウェア更新制御部は、前記入庫出庫識別部が、自車両の入庫状態を検出している場合に、前記更新処理を開始する、
ことを特徴とする車載ソフトウェア更新装置。
［３］ ［１］又は［２］に記載の車載ソフトウェア更新装置であって、
前記ソフトウェア更新制御部は、前記無線通信モジュール（１２）が利用する無線通信回線の通信環境が所定の条件を満たさない場合に、前記更新処理の開始を禁止する、
ことを特徴とする車載ソフトウェア更新装置。
［４］ ［１］に記載の車載ソフトウェア更新装置であって、
前記ソフトウェア更新制御部は、前記更新処理において、前記第２のソフトウェアのダウンロードが完了しなかった場合であって該第２のソフトウェアをダウンロードした回数が規定回数未満のとき、前記第２のソフトウェアを再びダウンロードする、
ことを特徴とする車載ソフトウェア更新装置。

【符号の説明】

【0078】

１０ テレマティクス車載端末
１１ 制御部
１１ａ ソフトウェア更新制御部
１１ｂ 入庫出庫識別部
１２ 無線通信モジュール
１３ ＧＰＳモジュール
１４ 外部インタフェース
１５ 表示部
１６ 不揮発性メモリ
１７ 操作インタフェース
１８ 操作部
１９ デジタル５ｃｈ入力インタフェース
２０ 回転インタフェース
２１ 速度インタフェース
２２ 電源部
３１ 通信アンテナ
３２ ＧＰＳアンテナ
３３ 外部機器
３４ 車両側各種センサ
３５ エンジン回転センサ
３６ 速度センサ
３７ 車両側電源

【図1】

【図2】

【図3】

【図4】