JP5218366B2 - 車両用プログラム更新装置 - Google Patents

Description

本発明は、車両用プログラム更新装置に関するものである。

従来、車両が有するプログラムの更新を行うシステムとして、センタから更新するプログラムをダウンロードし、ダウンロードしたプログラムに基づいて、車両が有するプログラムを更新するものが知られている（例えば、特許文献１参照）。特許文献１記載のシステムは、プログラムの更新に先立って、その更新の要否についての適切な判断材料をユーザに提示する。具体的には、更新を行うことによって得られる機能のデモ画像をユーザに提示して、更新の必要性をユーザが判断できるようにするものである。

特開平１１−２７７４９号公報

しかしながら、特許文献１記載の車両用プログラム更新装置にあっては、ユーザがプログラムの更新によって生じるリスクを把握することができないおそれがある。このため、ユーザがプログラムの更新の実行可否を判断することが困難な場合がある。

そこで、本発明はこのような技術課題を解決するためになされたものであって、プログラム更新の実行をユーザに適切に判断させることができる車両用プログラム更新装置を提供することを目的とする。

すなわち、本発明に係る車両用プログラム更新装置は、車両と通信可能に構成され、通信を介して前記車両のプログラムを更新する車両用プログラム更新装置であって、更新対象の前記プログラムの種類に基づいて、当該更新対象の前記プログラムの更新が正常に終了しない場合に利用不可となる車両機能に関するリスク情報を取得するリスク情報取得手段と、前記プログラムの更新前に前記リスク情報を前記車両へ提供するリスク情報提供手段と、を備えて構成される。

本発明に係る車両用プログラム更新装置では、リスク情報提供手段により、更新用のプログラムの提供前に、更新が正常に終了しない場合に利用不可となる車両機能に関するリスク情報が車両へ提供される。このため、更新に伴うリスクを更新前にユーザに認識させることができる。これにより、ユーザは、更新が正常に終了しない場合に利用不可となる車両機能を想定した上で、更新の実行可否を判断することが可能となる。このように、リスク情報を更新前に車両へ提供することで、プログラム更新の実行をユーザに適切に判断させることができる。

ここで、前記リスク情報取得手段は、前記更新対象プログラムの種類及び前記リスク情報が関連付けて記録されるデータベースを参照して前記リスク情報を取得することが好適である。このように構成することで、更新対象プログラムの種類に応じたリスク情報を取得することができる。

また、本発明に係る車両用プログラム更新装置は、車両と通信可能に構成され、通信を介して前記車両のプログラムを更新する車両用プログラム更新装置であって、更新対象の前記プログラムの種類に基づいて、当該更新対象の前記プログラムの更新が正常に終了しない場合に必要な対処に関する対処情報を取得する対処情報取得手段と、前記プログラムの更新前に前記対処情報を前記車両へ提供する対処情報提供手段と、を備えて構成される。

本発明に係る車両用プログラム更新装置では、対処情報提供手段により、更新用のプログラムの提供前に、更新が正常に終了しない場合に必要な対処に関する対処情報が車両へ提供される。このため、更新に伴うリスクに対する対処を更新前にユーザに認識させることができる。これにより、ユーザは、更新が正常に終了しない場合に必要な対処を想定した上で、更新の実行可否を判断することが可能となる。このように、対処情報を更新前に車両へ提供することで、プログラム更新の実行をユーザに適切に判断させることができる。

ここで、前記対処情報取得手段は、前記更新対象プログラムの種類及び前記対処情報が関連付けて記録されるデータベースを参照して前記対処情報を取得することが好適である。このように構成することで、更新対象プログラムの種類に応じた対処情報を取得することができる。

本発明によれば、プログラム更新の実行をユーザに適切に判断させることができる。

実施形態に係る車両用プログラム更新装置を含むプログラム更新システムの構成を示す概要図である。 図１に示すプログラム更新システムの動作を示すフローチャートである。 更新プログラム管理ＤＢに格納されるデータの一例である。 更新実績ＤＢに格納されるデータの一例である。 ユーザに提供する画面例である。 ユーザに提供する画面例である。

以下、添付図面を参照して本発明の実施形態について説明する。なお、各図において同一又は相当部分には同一の符号を付し、重複する説明を省略する。

本実施形態に係る車両用プログラム更新装置は、例えば車両のプログラムのリモート更新（リプログラミング）に好適に採用されるものである。

最初に、本実施形態に係る車両用プログラム更新装置を備えるプログラム更新システムについて説明する。図１は、実施形態に係る車両用プログラム更新装置１を有するプログラム更新システムの構成を示すブロック図である。図１に示すプログラム更新システムは、互いに通信可能な車両３及びサーバ２を備えている。車両３は、更新可能なソフトウェア（更新対象プログラム３６）を有しており、サーバ２によって通信を介して更新対象プログラム３６を更新可能に構成されている。

サーバ２の詳細について説明する。サーバ２は、ＣＰＵ、メモリ等を有する情報処理装置であって、車両３のプログラムを更新する車両用プログラム更新装置１を備えている。この車両用プログラム更新装置１は、装置側通信部１４及び更新処理部（リスク情報取得手段、対処情報取得手段、リスク情報提供手段、対処情報提供手段）１３を備えている。

装置側通信部１４は、車両３と相互に送受信可能に構成されている。装置側通信部１４は、例えば、インターネット接続機能を有し、ＶＰＮ（Virtual Private Network）等でセキュリティを考慮した外部接続が可能に構成されている。また、装置側通信部１４は、更新処理部１３と入出力可能に構成されている。

更新処理部１３は、装置側通信部１４と入出力可能に構成され、装置側通信部１４を介して車両３のプログラムを更新する機能を有している。更新処理部１３は、例えば、装置側通信部１４を介して更新用のプログラムデータ（不図示）を車両３へ送信して、車両３が有する機能と協働して車両３のプログラムを更新する機能を有している。更新の前に、更新処理部１３は、例えば、更新対象プログラム３６が利用している車両機能等に基づいて、更新対象プログラム３６の更新タイミング、及び更新対象プログラム３６の更新時の必須車両状態等を決定する機能を有している。そして、更新処理部１３は、決定した更新タイミング及び車両状態で更新対象プログラム３６の更新を行う機能を有している。

また、更新処理部１３は、サーバ２に備わる更新プログラム管理ＤＢ１０を参照可能に構成されている。更新プログラム管理ＤＢ１０は、更新対象のプログラムの要件（プログラム更新に関する情報）を格納したデータベースである。例えば、更新プログラム管理ＤＢ１０は、プログラムの種類と関連付けて当該プログラムの更新に関する情報を格納している。プログラムの種類は、例えば、ＥＣＵ（Electronic Control Unit））名（部位）、ハード品番（型番）及びソフトウェアのバージョンで識別される。すなわち、更新プログラム管理ＤＢ１０には、例えばＥＣＵ名、ハード品番及びソフトウェアバージョンと関連付けられて、容量、書換方式（全書換／差分書換）、更新の内容（趣旨）、更新トラブル時の想定現象、トラブル時の対処等に関する情報が格納されている。更新時の想定現象に関する情報には、例えば、更新対象プログラム３６の更新が正常に終了しない場合に利用不可となる車両機能に関するリスク情報が含まれている。利用不可とは、その可能性があるものを含んでもよい。また、車両機能とは、例えば、走行、旋回、停止等の車両の基本機能の他、車両装備に関する機能が含まれる。車両装備としては、例えば、運動性能を確保する装備（ＡＢＳ（Anti-lock Brake System）、ＶＤＩＭ(Vehicle Dynamics Integrated Management)等）、運転を支援する装備（ＬＫＡ(Lane-KeepingAssist)、ナビ、音楽再生機器等）、視認性を補助する装備（モニタ、歩行者探知機能付カメラ等）、衝突時の安全を確保する装備（プリクラッシュセーフティシステム等）等である。また、トラブル時の対処に関する情報は、プログラムの更新が正常に終了しなかった場合における対応（対策）に関する情報が含まれている。具体的には、エンジニアが派遣される、ディーラ（自動車の販売・整備を行う店舗）へ車を預ける、といった今後の対応の事例である。これらの対応は、更新トラブル時のリスクの大きさや、更新の緊急性に応じて事前に決定される。例えば、走行が不可能となるような重大な事態が想定される場合にはエンジニア派遣、万一失敗しても走行が可能な場合や失敗発生が非常に低いと考えられる場合にはディーラ入庫が採用される。また、更新処理部１３は、更新プログラム管理ＤＢ１０を参照し、更新対象プログラム３６の種類に基づいて、当該更新対象プログラム３６の更新に関する情報を取得する機能を有している。

また、更新処理部１３は、サーバ２に備わるディーラ等情報管理ＤＢ１１を参照可能に構成されている。ディーラ等情報管理ＤＢ１１は、ディーラに関する位置情報、営業時間、サービスマンの対応可能時間等が格納されるデータベースである。ディーラ等情報管理ＤＢ１１には、整備工場の位置、営業時間、車両整備に関するエンジニアの予約状況等が格納されていてもよい。更新処理部１３は、ディーラ等情報管理ＤＢ１１を参照し、ディーラに関する情報やエンジニアに関する情報を取得する機能を有している。

また、更新処理部１３は、サーバ２に備わる更新実績管理ＤＢ１２を参照更新可能に構成されている。更新実績管理ＤＢ１２は、過去の更新の実績が格納されたデータベースである。例えば、更新実績管理ＤＢ１２には、車両を一意に識別するための車両ＩＤに関連付けて、ハード品番、ソフトウェアバージョン、更新の状態、更新所要時間、状態把握日等が格納される。更新処理部１３は、更新実績管理ＤＢ１２を参照し、更新実績情報を取得する機能、及び、更新実績情報を記録する機能を有している。

更新処理部１３は、上記の各ＤＢを参照して取得した情報を、プログラム更新の前にユーザに提示するために、プログラム更新の前に通信を介して車両３へ提供する機能を有している。例えば、更新処理部１３は、リスク情報、実績、正常終了しない場合の対応等をプログラム更新前に車両３へ装置側通信部１４を介して提供する機能を有している。また、更新処理部１３は、車両３から取得した情報に基づいて、ユーザに提示する情報を生成又は補正する機能を有している。さらに、更新処理部１３は、車両３から取得した情報に基づいて、更新用のプログラムデータの送信の要否を判定する機能を有している。

次に、車両３の詳細を説明する。車両３は、車両側通信部３０、情報管理部３１、場所・時刻取得部３２、ルート案内機能部３３、ユーザインターフェイス部３４、更新データ一時キャッシュ３５及び更新対象プログラム３６を備えている。

車両側通信部３０は、車両用プログラム更新装置１の装置側通信部１４と通信可能に構成されている。また、車両側通信部３０は、情報管理部３１に接続されている。そして、車両側通信部３０は、情報管理部３１が出力した情報を装置側通信部１４へ送信する機能、及び、装置側通信部１４から受信した情報を情報管理部３１へ出力する機能を有している。車両側通信部３０は、例えば、ＬＴＥ（Long Time Evolution）や３Ｇ等で実現される広域無線通信で通信可能に構成されている。なお、車両側通信部３０は、車両に固定されている通信機のみならず、ユーザにより車内に持ち込まれて車両に接続された携帯電話等であってもよい。

場所・時刻取得部３２は、例えばＧＰＳ（Global Positioning System）や車載センサ等を活用して、自車位置を推測したり、時刻を取得したりする機能を有している。また、場所・時刻取得部３２は、情報管理部３１に接続されており、推定又は取得した情報を情報管理部３１へ出力する機能を有している。

ルート案内機能部３３は、例えば、地図情報に基づいて目的地までの走行ルートを探索及び案内する機能を有している。また、ルート案内機能部３３は、情報管理部３１に接続されており、現在案内中のルートがある場合には、当該ルートに関する情報を情報管理部３１へ出力する機能を有している。

ユーザインターフェイス部３４は、情報管理部３１に接続されており、情報管理部３１が出力した情報に基づいてユーザに対して情報を出力したり、ユーザによる操作情報を入力して情報管理部３１へ出力したりする機能を有している。ユーザインターフェイス部３４としては、例えば、表示装置と入力装置とを組み合わせたタッチパネル等が用いられる。

更新データ一時キャッシュ３５は、更新用のプログラムに関するデータを一時的に保存する領域である。更新データ一時キャッシュ３５は、情報管理部３１から参照更新可能に構成されている。更新対象プログラム３６は、例えば、更新対象のＥＣＵ（ナビＥＣＵ、エンジンＥＣＵ等）により利用されるプログラムである。

情報管理部３１は、車両３のプログラムの更新に関する情報処理を統括する機能を有している。例えば、情報管理部３１は、車両側通信部３０を介してサーバ２から取得した更新用のプログラムデータを更新データ一時キャッシュ３５に格納してデータの整合性を確認する機能を有している。情報管理部３１は、取得したプログラムデータの整合性が正しい場合には、更新対象プログラム３６を利用するＥＣＵに対して、更新データ一時キャッシュ３５に格納されたデータを用いてプログラム更新するように指令を出力する機能を有している。また、情報管理部３１は、場所・時刻取得部３２から取得した場所情報や時間情報、ルート案内機能部３３から取得したルート情報、ユーザインターフェイス部３４から取得したユーザ入力情報等を車両側通信部３０へ出力する機能を有している。

次に、実施形態に係る車両用プログラム更新装置１を有するプログラム更新システムの動作について説明する。図２は、プログラム更新システムの動作を示すフローチャートである。本実施形態に係る車両用プログラム更新装置１の動作は、図２に示すサーバ側処理となる。図２に示す制御処理は、例えば、サーバ２の電源ＯＮ及び車両３のイグニッションＯＮのタイミングから所定の間隔で繰り返し実行される。なお、サーバ２の有する更新プログラム管理ＤＢ１０には、図３に示すプログラム管理情報が格納されているものとする。また、サーバ２の有する更新実績管理ＤＢ１２には、図４に示す実績情報が格納されているものとする。

図２に示すように、サーバ２は情報入力処理から開始する（Ｓ１０）。Ｓ１０の処理では、サーバ２が更新用のプログラムデータを入力する。例えば、サーバ２は、外部媒体等から更新用のプログラムデータを入力する。さらに、サーバ２は、プログラムデータの種類を特定するために、「ＥＣＵ名、型番、バージョン」を取得する。例えば、「エンジンＥＣＵ、ＡＡＡ−ＡＷＷＡ−ＡＡＡ、３．０」のプログラムデータを入力する。Ｓ１０の処理が終了すると、対象車両特定処理へ移行する（Ｓ１２）。

Ｓ１２の処理では、サーバ２がＳ１０の処理で入力した更新用のプログラムデータを適用する対象の車両３を特定する。例えば、サーバ２は、車両と当該車両が有するプログラムとが関連付けされて記録されているデータベース等を参照し、Ｓ１０の処理で入力した更新用のプログラムデータに基づいて、更新用のプログラムデータを適用する対象の車両３を特定する。Ｓ１２の処理が終了すると、問い合わせ処理へ移行する（Ｓ１４）。

Ｓ１４の処理では、Ｓ１２の処理で特定した車両３に対して、更新処理部１３が装置側通信部１４を介して車両３に問い合わせを行う処理である。例えば、更新処理部１３は、遠隔更新を行うか否かを車両３に問い合わせする。この問い合わせの例を、図５（ａ）を用いて説明する。図５（ａ）は、車両３のユーザインターフェイス部３４の表示例である。更新処理部１３は、Ｓ１０の処理で取得したＥＣＵ名を図中の○○で示す箇所に代入する。これにより、実行する処理が具体的にどの部位に関するものであるのかを、更新前にユーザに提示することができる。そして、図５（ａ）に示すように、更新処理部１３は、「遠隔更新をすることができる旨」、「遠隔更新は失敗する可能性がある旨」、「ディーラへ持ち込んで更新することができる旨」を車両３のユーザに対して提示し、希望する処理をユーザに選択させる。例えば、「遠隔更新」、「ディーラへ行く」、「保留」の各選択ボタンを表示してユーザに選択させる。車両３側では、遠隔更新するのか、ディーラへ行くのか、又は何ら処理することなく保留とするのかがユーザによって選択される（Ｓ２４）。

Ｓ２４の処理において、「遠隔更新」が選択された場合には、その旨がサーバ２へ送信される。そして、更新処理部１３は、ユーザへ提示するためのリスク情報等を取得する。更新処理部１３は、更新プログラム管理ＤＢ１０を参照し、Ｓ１０の処理で入力した更新用のプログラムデータの種類又は更新対象プログラム３６の種類に基づいて、更新に伴うリスク情報等を取得する。ここで、Ｓ１０の処理において、「エンジンＥＣＵ、ＡＡＡ−ＡＷＷＡ−ＡＡＡ、３．０」のプログラムデータを入力したとする。そして、更新対象プログラム３６は「エンジンＥＣＵ、ＡＡＡ−ＡＷＷＡ−ＡＡＡ、２．０」であるとする。この場合、更新処理部１３は、図３に示す更新プログラム管理ＤＢ１０の情報を参照し、ＥＣＵ名、型番、ソフトウェアバージョンに基づいて、番号１のレコードに示す情報を、プログラムの更新に関する情報として取得する。具体的には、容量が「０．９５ＭＢ」、書換方式が「全書換」、内容（更新趣旨）が「ノッキング防止」、正常終了しない時の想定現象が「エンジン始動不可」、修復への対処方法が「エンジニア派遣」というプログラムに関する情報を取得する。

また、更新処理部１３は、取得した更新用のプログラムデータの容量に基づいて、更新に必要な所要時間を算出する。この時、車両３のＣＰＵ性能やメモリの種類等を勘案して所要時間を修正してもよい。あるいは、更新処理部１３は、更新実績管理ＤＢ１２を参照して、同一のプログラムの種類の更新実績が存在する場合には、当該データを参考に所要時間を生成してもよい。例えば、更新用のプログラムデータが「エンジンＥＣＵ、ＡＡＡ−ＡＷＷＡ−ＡＡＡ、３．０」であるとする。この場合、更新処理部１３は、図４に示す更新実績管理ＤＢ１２の情報を参照し、番号１のレコードに示す情報を更新用のプログラムに関する実績情報として取得する。具体的には、車両ＩＤが「Ａ００００１０１」、ソフトウェアＶｅｒ．が「２．０」から「３．０」へ変更、状態が「実施済み」、所要時間が「１３分」、状態把握日が「２０１２年４月１日」といった更新用のプログラムに関する実績情報を取得する。そして、更新処理部１３は、更新用のプログラムと同一の種類であって、状態が「実施済み」である実績データを複数取得することができた場合には、これらのデータの所要時間の平均を更新に必要な所要時間とする。また、更新処理部１３は、更新用のプログラムと同一の種類の実績データを複数取得することができた場合には、同一種類の実績データ数の中で状態が「失敗」である実績データ数が占める割合（失敗率）を算出してもよい。

また、更新処理部１３は、修復への対処方法が「エンジニア派遣」の場合には、車両３の現在地点を、装置側通信部１４を介して車両３から取得するとともに、ディーラ等情報管理ＤＢ１１を参照して、車両３の現在地点に近い場所に滞在するエンジニアを特定する。あるいは、更新処理部１３は、車両３のルート情報を、装置側通信部１４を介して車両３から取得するとともに、ディーラ等情報管理ＤＢ１１を参照して、車両３の走行ルートに近い場所に滞在するエンジニアを特定する。そして、更新処理部１３は、ディーラ等情報管理ＤＢ１１を参照して、当該エンジニアの予約状況を取得し、「エンジニア派遣までに要する時間」を算出する。

更新処理部１３は、上記の処理により取得した「ＥＣＵ名」「内容」「想定現象」「対処」、及び生成した「所要時間」「エンジニア派遣までに要する時間」等を、プログラムの更新前に車両３へ提供する。そして、プログラムの更新前に車両３のユーザインターフェイス部３４に表示させる。この表示例を、図５（ｂ）を用いて説明する。図５（ｂ）は、車両３のユーザインターフェイス部３４の雛形例である。更新処理部１３は、図５（ｂ）に示す雛形に、図中Ａ〜Ｅに生成あるいは取得した情報を代入することで、遠隔更新に関する説明文章を完成させる。説明文章が提供されることで、ユーザは、どの部位に関する更新なのか、何のために行う更新なのか、どれくらい時間がかかるものなのか、正常終了しない場合にはどのような現象が起こるのか、正常終了しない場合にはどのような対処が考えられるのかを理解することができる。図６（ａ）〜（ｃ）に、実際に値を代入した車両３のユーザインターフェイス部３４の他の表示例を示す。図６（ａ）は、「エンジンＥＣＵ、ＡＡＡ−ＡＷＷＡ−ＡＡＡ、３．０」（番号１）に関する表示例、図６（ｂ）は、「ＶＤＩＭ ＥＣＵ、ＤＣＡ−ＡＡＷＡ−ＡＱＲＡ、１．５」（番号６）に関する表示例、図６（ｃ）は、「ナビＥＣＵ、ＢＢＢ−ＡＥＥＡ−ＢＡＤＣ、１．５」（番号４）に関する表示例である。なお、図６（ａ）には、エンジニア派遣に要する時間を「○○○」で表示している。そして、更新処理部１３は、「はい」「いいえ」の各選択ボタンを表示して遠隔更新の可否をユーザに選択させる（Ｓ２４）。ここで、ユーザにより「はい」が選択された場合において、更新処理部１３は、遠隔更新が失敗する可能性が高いと判定した場合には、さらに注意喚起を行う。更新処理部１３は、例えば、上述した「失敗率」に基づいて、遠隔更新が失敗する可能性が高いか否かを判定する。そして、更新処理部１３は、図５（ｃ）に示すように、遠隔更新が失敗する可能性が高い旨をユーザへ提示して、「はい」「いいえ」の各選択ボタンを表示して遠隔更新の可否をユーザに再度選択させる（Ｓ２４）。車両３は、ユーザにより遠隔更新の実行指示がなされた場合には、受信データ確認処理へ移行する（Ｓ２６）。また、サーバ２は、Ｓ２４の処理が終了すると、遠隔更新指示判定処理へ移行する（Ｓ１６）。

Ｓ１６の処理では、更新処理部１３が、車両３からの通知の内容が遠隔更新の指示であるか否かを判定する。例えば、更新処理部１３は、「遠隔更新」が選択され、リスクに関する情報提示に「はい」を選択して同意したと判断した場合には、遠隔更新の指示がなされたと判定する。Ｓ１６の処理で遠隔更新の指示がなされたと判定した場合には、更新タイミング設定処理へ移行する（Ｓ１８）。

Ｓ１８の処理では、更新処理部１３が更新タイミングの設定を行う。例えば、更新処理部１３は、ユーザが予め設定した希望時刻を車両３から取得する。そして、更新処理部１３は、希望時刻、更新所要時間等を考慮して更新タイミングを設定する。さらに、更新処理部１３は、更新対象プログラム３６の車載機能等に基づいて、更新時の必須車両状態を取得する。Ｓ１８の処理が終了すると、更新プログラムの送信処理へ移行する（Ｓ２０）。

Ｓ２０の処理では、装置側通信部１４が、更新用のプログラムデータを車両３へ送信する。サーバ２が更新用のプログラムデータを車両３へ送信すると、車両３では、車両側通信部３０が更新用のプログラムデータを受信する。そして、情報管理部３１が受信データの整合性を確認する（Ｓ２６）。Ｓ２６の処理が終了すると、更新可能確認処理へ移行する（Ｓ２８）。

Ｓ２８の処理では、情報管理部３１が更新対象プログラム３６を更新可能な状態であるか否かを確認する。例えば、情報管理部３１は、センサ情報等に基づいて、Ｓ１８の処理で設定された更新タイミングにおいて乗車中であるか否かを判定し、乗車中でないと判定した場合には、更新対象プログラム３６を更新可能な状態であると判定する。また、Ｓ１８の処理で設定された更新タイミングにおいて乗車中であると判定した場合であっても、例えばサーバ２から送信された更新時の必須車両状態に基づいて、更新対象プログラム３６が走行時に更新可能（書換可能）なプログラムであると判定した場合には、更新対象プログラム３６を更新可能な状態であると判定する。情報管理部３１は、更新可能であると判定できない場合には、所定の間隔でＳ２８の処理を繰り返し実行する。Ｓ２８の処理において、更新可能な状態が確認された場合には、プログラム更新処理へ移行する（Ｓ３０）。

Ｓ３０の処理では、更新対象のＥＣＵが更新データ一時キャッシュ３５に格納された更新用のプログラムデータを用いて更新対象プログラム３６の更新を実行する。例えば、ＥＣＵは、サーバ２の更新処理部１３及び車両３の情報管理部３１から出力された情報及び指令に基づいて、Ｓ１８の処理で設定された更新タイミングで更新対象プログラム３６の更新を実行する。指令を受けたＥＣＵは、管理下の機器類の動作が正常であることを確認した後、プログラムの書込を実行する。ＥＣＵは、書込み完了後ベリファイを実行して正常終了を確認する。そして、プログラムを旧Ｖｅｒ．から新Ｖｅｒ．へ切替える。Ｓ３０の処理が終了すると、実施結果送信処理へ移行する（Ｓ３２）。

Ｓ３２の処理では、車両側通信部３０が実施結果をサーバ２へ送信する。例えば、車両ＩＤ、ＥＣＵ名、書込み成功可否、更新時間、日付等を送信する。Ｓ３２の処理が終了すると、車両３側の制御処理を終了する。

車両側通信部３０が実施結果をサーバ２へ送信すると、サーバ２側では、実績情報記録処理が行われる（Ｓ２２）。Ｓ２２の処理では、装置側通信部１４が、車両側通信部３０から送信された実施結果を受信して、更新処理部１３へ出力する。更新処理部１３は、実施結果を更新実績管理ＤＢ１２へ格納する。Ｓ２２の処理が終了すると、サーバ２側の制御処理を終了する。

一方、Ｓ２４の処理において、問い合わせ画面（図５（ａ））においてユーザが「遠隔更新」を選択せず、「ディーラへ行く」、「保留」の何れかを選択した場合には、車両３側の制御処理を終了する。また、Ｓ２４の処理において、サーバ２からの問い合わせ画面（）においてユーザが「遠隔更新」を選択したものの、後のリスク情報の提供画面（図５（ｂ），（ｃ））において「いいえ」を選択した場合には、問い合わせ画面（図５（ａ））を再度提示して、「遠隔更新」、「ディーラへ行く」、「保留」の何れかをユーザに選択させる。また、Ｓ１６の処理において、ユーザが遠隔更新を選択しなかった場合には、サーバ２側の制御処理を終了する。

以上で図２に示す制御処理を終了する。図２に示す制御処理を実行することにより、更新に先立って、更新の部位や内容、更新時間、万が一更新が失敗した時の想定トラブル内容、その復旧に係る時間等をユーザに対してお知らせすることができる。これにより、例えば、修復時の対応として、エンジニア派遣とされた場合には、ディーラや整備工場の近くに移動した時にプログラムの遠隔更新をした方が良い等の判断をユーザが行うことができる。このように、万が一遠隔更新に失敗した場合であっても、車両機能が使えなくなる時間をできるだけ短くするようにユーザが判断することができる。また、プログラム更新が正常に終了しないときに利用不可となる車両機能を想定することができるので、更新に伴うリスクをユーザが判断することが可能となる。例えば、リスクの大きさとディーラへ赴く手間との兼ね合いを考慮して、遠隔更新とするか否かをユーザに適切に判断させることができる。さらに、ユーザが実行要否を選択することができるので、ユーザの要望を反映したプログラム更新をすることができる。また、サーバ２は、更新実績管理ＤＢ１２に格納されたデータをメンテナンス情報として活用することができる。これにより、顧客へ更新のフォローが可能となる。

上述したように、本実施形態に係る車両用プログラム更新装置１によれば、更新処理部により、更新用のプログラムデータの提供前に、更新が正常に終了しない場合に利用不可となる車両機能に関するリスク情報、及びトラブル発生時の対応が車両３へ提供される。このため、更新に伴うリスク及びトラブル発生時の対応を更新前にユーザに認識させることができる。これにより、ユーザは、更新が正常に終了しない場合に利用不可となる車両機能及びトラブル発生時の対応を想定した上で、更新の実行可否を判断することが可能となる。このように、リスク情報及びトラブル発生時の対応を更新前に車両へ提供することで、プログラム更新の実行をユーザに適切に判断させることができる。

なお、上述した実施形態は本発明に係る車両用プログラム更新装置の一例を示すものである。本発明に係る車両用プログラム更新装置は、実施形態に係る車両用プログラム更新装置に限られるものではなく、各請求項に記載した要旨を変更しない範囲で、実施形態に係る車両用プログラム更新装置を変形し、又は他のものに適用したものであってもよい。

例えば、上述した実施形態では、ユーザインターフェイス部３４としてタッチパネルを採用する例を説明したが、車両に接続された携帯電話の画面、参照可能なＷｅｂページ、操作ボタン等をユーザインターフェイス部３４として機能させてもよい。また、ユーザインターフェイス部３４へのユーザからの入力方法は、音声であってもよい。

また、上述した実施形態では、視覚を通してユーザにリスク情報を提示する例を説明したが、音声や振動等を用いてもよい。

また、上述した実施形態では、更新トラブル時の対応として「ディーラ入庫」を表示する例を説明したが、「ディーラ入庫」の表示とともに、車両３の現在地点又はルート情報に基づいて、最も立ち寄り易いディーラの位置情報を表示してもよい。

また、上述した実施形態では、図５、図６において表示画面の一例を示したが、画面の文章は適宜変更可能である。例えば、車両３の現在地点やディーラの位置情報を文面に反映させてもよい。

また、上述した実施形態では、ユーザに遠隔更新の要否を判定させる例を説明したが、緊急度の高い更新は自動更新とし、ある程度の緊急度のものについてのみユーザに遠隔更新の要否を判定させる構成としてもよい。

また、上述した実施形態では、更新用のプログラムに基づいて、更新対象の車両３を特定する例を説明したが（図２のＳ１０）、更新用のプログラムを入力する際に、更新用のプログラムを適用する対象の車両（車種）を入力してもよい。

また、上述した実施形態では、更新処理部１３が、車両３側のプログラム更新タイミングや必須車両状態を取得し、情報管理部３１と協働して更新指令をＥＣＵへ出力する例を説明したが、更新処理部１３が全て遠隔操作でプログラム更新を実行してもよい。また、更新処理部１３は更新用のプログラムデータを車両３へ送信するだけで、車両３が受信したプログラムデータを用いてプログラム更新の全てを実行する場合であってもよい。

１…車両用プログラム更新装置、２…サーバ、３…車両、１０…更新プログラム管理ＤＢ、１１…ディーラ等情報管理ＤＢ、１２…更新実績管理ＤＢ、１３…更新処理部（リスク情報取得手段、対処情報取得手段、リスク情報提供手段、対処情報提供手段）、１４…装置側通信部、３０…車両側通信部、３１…情報管理部、３２…場所・時刻取得部、３３…ルート案内機能部、３４…ユーザインターフェイス部、３５…更新データ一時キャッシュ、３６…更新対象プログラム。

Claims (4)

1. 車両と通信可能に構成され、通信を介して前記車両のプログラムを更新する車両用プログラム更新装置であって、
   更新対象の前記プログラムの種類に基づいて、当該更新対象の前記プログラムの更新が正常に終了しない場合に利用不可となる車両機能に関するリスク情報を取得するリスク情報取得手段と、
   前記プログラムの更新前に前記リスク情報を前記車両へ提供するリスク情報提供手段と、
   を備えることを特徴とする車両用プログラム更新装置。
2. 前記リスク情報取得手段は、前記更新対象プログラムの種類及び前記リスク情報が関連付けて記録されるデータベースを参照して前記リスク情報を取得する請求項１に記載の車両用プログラム更新装置。
3. 車両と通信可能に構成され、通信を介して前記車両のプログラムを更新する車両用プログラム更新装置であって、
   更新対象の前記プログラムの種類に基づいて、当該更新対象の前記プログラムの更新が正常に終了しない場合に必要な対処に関する対処情報を取得する対処情報取得手段と、
   前記プログラムの更新前に前記対処情報を前記車両へ提供する対処情報提供手段と、
   を備えることを特徴とする車両用プログラム更新装置。
4. 前記対処情報取得手段は、前記更新対象プログラムの種類及び前記対処情報が関連付けて記録されるデータベースを参照して前記対処情報を取得する請求項３に記載の車両用プログラム更新装置。

Images