WO2023007577A1 - ソフトウェア更新装置、ソフトウェア更新システム、及びソフトウェア更新方法 - Google Patents

Abstract

車両（１）に搭載される車載制御装置（１４Ａ～１４Ｃ）のソフトウェアを更新するソフトウェア更新装置（１０）であって、車載制御装置（１４Ａ～１４Ｃ）のソフトウェアの更新に関する更新処理情報を取得する情報取得部（４１）と、ソフトウェアの更新を承諾するかをユーザに求める承諾要求情報を出力する出力部（４３）と、承諾要求情報に対するユーザの回答である回答情報に応じて、更新処理を実行する更新処理実行部（４５）と、更新に要する見積り時間内に更新が完了しない場合、更新前ソフトウェアに対応したプログラムを、車載制御装置（１４Ａ～１４Ｃ）に実行させ、見積り時間内に更新が完了した場合、更新済みソフトウェアに対応したプログラムを、車載制御装置（１４Ａ～１４Ｃ）に実行させる制御部（５０）を備えるソフトウェア更新装置（１０）。

Description

ソフトウェア更新装置、ソフトウェア更新システム、及びソフトウェア更新方法

　本発明は、ソフトウェア更新装置、ソフトウェア更新システム、及びソフトウェア更新方法に関するものである。

　従来より、ユーザの好みに応じたタイミングで、ソフトウェアを自動的に更新することができる情報処理端末が知られている（特許文献１）。この情報処理端末は、車両に搭載された車載端末としても用いることができる。

特開２０１６－３８６３４号公報

　ソフトウェアの更新に関する処理が実行されている間、車両を起動できないため、ユーザは車両を使用することができない。上記情報処理端末では、ソフトウェアの更新が終了しないエラーが発生した場合、車載制御装置の実行対象であるソフトウェアが定まらず、ユーザが車両を使用できない可能性がある、という問題がある。

　本発明が解決しようとする課題は、ソフトウェアの更新が終了しないエラーが発生した場合でも、ユーザが車両を使用できるソフトウェア更新装置、ソフトウェア更新システム、及びソフトウェア更新方法を提供することである。

　本発明は、車両の外部に設けられたサーバーから、車載制御装置のソフトウェアの更新に関する更新処理情報を取得し、ソフトウェアの更新を承諾するかをユーザに求める承諾要求情報を出力し、承諾要求情報に対するユーザの回答である回答情報に応じて、更新処理を実行し、更新に要する見積り時間内に更新が完了しない場合、更新前ソフトウェアに対応したプログラムを、車載制御装置に実行させ、見積り時間内に更新が完了した場合、更新済みソフトウェアに対応したプログラムを、車載制御装置に実行させることにより、上記課題を解決する。

　本発明によれば、ソフトウェアの更新が終了しないエラーが発生した場合でも、車載制御装置の実行対象であるプログラムを決定できるため、ユーザは車両を使用できる。

図１は、第１実施形態に係るソフトウェア更新装置を含むソフトウェア更新システムの一例を示すブロック図である。 図２は、ＯＴＡによるソフトウェア更新のフローを説明するための説明図である。 図３は、ＥＣＵのメモリ構成に応じた、ＯＴＡによるソフトウェア更新を説明するための説明図である。 図４は、図１に示すソフトウェア更新装置のコントローラが有する機能ブロックの一例である。 図５は、第１実施形態に係るソフトウェア更新方法のフローチャートである。 図６は、第２実施形態に係るソフトウェア更新装置のコントローラが有する機能ブロックの一例である。 図７は、第２実施形態に係るソフトウェア更新方法のフローチャートである。

　以下、本発明に係るソフトウェア更新装置、ソフトウェア更新システム、及びソフトウェア更新方法の実施の形態を図面に基づいて説明する。

　≪第１実施形態≫
　本実施形態に係るソフトウェア更新装置１０は、図１に示すように、ソフトウェア更新システム１００の一部として実現される。図１は、本実施形態に係るソフトウェア更新システム１００の一例を示すブロック図である。ソフトウェア更新システム１００は、車両１の電子制御装置（以下、ＥＣＵ（Electronic Control Unit）と称する）が実行する、車両制御や診断等のソフトウェアを、ＯＴＡ(Over The Air）により更新可能なシステムである。このようなＯＴＡによりソフトウェアを更新することは、ＦＯＴＡ（Firmware Over The Air）とも称される。ＥＣＵのソフトウェアは、ＥＣＵが備えるマイコンがプログラムを実行することで、実現される。本実施形態では、無線によるＥＣＵのソフトウェア更新として、ＥＣＵのマイコンが実行するプログラムを無線により書き換える場合を例に挙げて説明するが、ソフトウェア更新システム１００は、例えば、車両１のナビゲーションシステムで使用される地図データ、ＥＣＵで使用される制御パラメータ等、各種ソフトウェアで使用されるデータを無線で書き換える場合にも適用することができる。またソフトウェア更新システム１００は、ＥＣＵにＦＰＧＡ（Field Programmable Gate Array）が用いられている場合、ＦＰＧＡの機能（ロジック）を無線で書き換える場合にも適用することができる。また図１では、車両１として一台の車両が図示されているが、ソフトウェア更新システム１００は、複数の車両１を対象にして、ソフトウェアの更新可能なシステムである。

　また本実施形態において、「ＥＣＵのソフトウェア更新」とは、ＥＣＵのソフトウェアのバージョンが新しいバージョンに変わること、すなわち、マイコンの実行対象であるプログラムが新しいバージョンに変わることを意味する。また無線によるソフトウェア更新は、新しいバージョンのプログラムそのものを車両１の外部から無線を介して取得して書き換えることに加えて、新しいバージョンのプログラムが実行される際に使用される各種データ、及び新しいバージョンのプログラムと古いバージョンのプログラムの差分データを、車両１の外部から無線を介して取得して書き換えることも含む。以降の説明では、新しいバージョンのプログラムや差分データ等、ソフトウェアの更新に必要なデータを「更新用データ」と称する。また、「新しいバージョンのプログラム」を「新プログラム」と称し、「古いバージョンのプログラム」を「旧プログラム」と称し、「新しいバージョンのプログラムと古いバージョンのプログラムの差分のデータ」を「差分データ」と称する。また本実施形態において、「処理の完了」とは、処理が正常終了したことを意味し、処理が異常終了したことは含まない。また本実施形態では、ソフトウェアの更新に関する手続きを行うユーザとして、車両１の室外にいるユーザを例に挙げて説明する。

　図１に示すように、ソフトウェア更新システム１００は、車両１と、サーバー２と、ユーザ端末３を含む。ソフトウェア更新システム１００に含まれる各構成は、無線通信回線網４を介して、情報の授受が可能になっている。無線通信回線網４は、例えば４Ｇ回線等による移動体通信ネットワーク、インターネット、Ｗｉｆｉ（Wireless Fidelity）（登録商標）等を含んで構成される。まず、ソフトウェア更新システム１００において、車両１、サーバー２、及びユーザ端末３それぞれの役割について説明する。

　車両１は、ソフトウェアを更新可能なＥＣＵを搭載する。車両１は、サーバー２との間で、ソフトウェア更新に関する各種情報の授受を行う。車両１からサーバー２には、車両１に搭載される各ＥＣＵに関する情報が送信される。ＥＣＵに関する情報としては、例えば、ソフトウェアの現在のバージョンが挙げられる。車両１が搭載する各ＥＣＵに関する情報は、所定の送信条件（例えば、所定の周期ごと）に基づき、車両１からサーバー２に送信される。

　またサーバー２から車両１には、ソフトウェア更新に関する情報が送信される。ソフトウェア更新に関する情報としては、例えば、キャンペーン情報、更新用データ、更新処理に要する時間の見積り、更新の重要度等が挙げられる。キャンペーンとは、サーバー２が配信パッケージを一又は複数の車両１に配信するイベントである。配信パッケージには、更新用データ、更新用データの認証処理に用いられる認証用データ等が含まれる。キャンペーン情報は、ユーザにソフトウェア更新の概要を提示するための情報である。キャンペーン情報の具体例、更新処理に要する時間の見積りについては後述する。更新処理に要する時間の見積りは、配信パッケージに含まれていてもよい。ソフトウェアの更新処理が開始されることに対してユーザが承諾した場合、車両１では、後述するソフトウェア更新装置１０により、ソフトウェアの更新処理が実行される。車両１で更新処理が開始されると、車両１からサーバー２には、更新処理の経過状況を表す情報が送信される。

　サーバー２は、ソフトウェア更新システム１００においてソフトウェア更新処理を統括し、ＯＴＡセンターとして機能するサーバーである。サーバー２は、車両１との間で上述したソフトウェア更新に関する各種情報の授受を行う。またサーバー２は、ユーザ端末３との間でも、各種情報の授受を行う。

　サーバー２は、更新用データを格納する格納機能、各ソフトウェアのバージョン、更新対象となる車両１の車両識別番号（ＶＩＮ：Vehicle Identification Number）、更新対象のＥＣＵ等を管理するデータ管理機能、キャンペーン情報の配信タイミング等のキャンペーンに関する情報を管理するキャンペーン管理機能、キャンペーン情報及び更新用データを配信する配信機能等を有している。サーバー２は、例えば、更新用データの提供事業者から、更新用データを含む各種情報を受信すると、更新用データを記憶装置に格納する。サーバー２は、提供事業者から受信した情報に基づき、更新用データの配信対象であるＶＩＮ及び更新対象のＥＣＵ（以降、更新対象ＥＣＵと称す）を特定する。サーバー２は、キャンペーン情報の配信タイミングを設定し、キャンペーン情報の配信タイミングになると、キャンペーン情報を車両１及び／又はユーザ端末３に送信する。配信パッケージが車両１に送信されることに対してユーザが承諾した場合、サーバー２は、車両１に配信パッケージを送信する。サーバー２による配信パッケージの送信が完了した後に、車両１で更新処理が開始されると、サーバー２は、車両１から更新処理の進捗状況を表す進捗情報を受信し、受信した進捗情報をユーザ端末３に送信する。

　ユーザ端末３は、ユーザからの操作入力を受け付ける機能や各種画面を表示する機能を有し、ユーザが携帯可能な端末である。ユーザ端末３としては、例えば、スマートフォンやタブレット等が挙げられる。ユーザ端末３は、サーバー２との間で、キャンペーン情報等の各種情報の授受を行う。ユーザ端末３は、サーバー２からキャンペーン情報を受信すると、キャンペーン情報をユーザに通知する。また配信パッケージが送信されることへの承諾を示す操作をユーザがユーザ端末３に行った場合、ユーザ端末３は、ユーザが承諾したことを表す承諾情報を、サーバー２に送信する。またユーザ端末３は、サーバー２を介して、車両１との間で、更新処理に関する情報の授受を行う。ユーザ端末３は、サーバー２から、更新処理開始の承諾をユーザに求めるための情報が入力された場合、ユーザに承諾を求めるための画像を表示する。またユーザ端末３は、更新処理開始の承諾を示す操作をユーザがユーザ端末３に行った場合、ユーザが承諾したことを表す承諾情報をサーバー２に送信する。車両１で更新処理が開始されると、ユーザ端末３は、サーバー２から進捗情報を受信し、受信した進捗情報をユーザに通知する。

　次に、車両１、サーバー２、及びユーザ端末３それぞれの構成について、図１を用いて説明する。まずサーバー２の構成について説明する。図１に示すように、サーバー２は、通信装置２１と、データベース２２と、制御装置２３を備える。

　通信装置２１は、無線通信回線網４を介して、車両１及びユーザ端末３との間でデータ通信を行う通信機能を有する。通信装置２１が車両１との間でデータの送受信を行うためには、車両１が無線通信回線網４の圏内に位置する必要がある。また通信装置２１がユーザ端末３との間でデータの送受信を行うためには、ユーザ端末３が無線通信回線網４の圏内に位置する必要がある。

　データベース２２は、車両１の登録情報、キャンペーン情報、更新用データ等を格納する。車両１の登録情報は、少なくとも、車両１のＶＩＮ、車両１が搭載するＥＣＵの数及び各ＥＣＵの種別、及び各ＥＣＵのソフトウェアのバージョンを含む。キャンペーン情報は、更新用データのデータサイズ、更新対象ＥＣＵを識別する情報（ＥＣＵ名、ＥＣＵのＩＤ等）、更新対象であるソフトウェアのバージョンの情報（バージョン名、バージョンのＩＤ等）、更新される機能の概要説明、配信パッケージのダウンロードが完了するまでの見積り時間（ダウンロード見積り時間）、及び、車両１での更新処理が完了するまでの見積り時間（更新処理見積り時間）等を含む。

　制御装置２３は、サーバー２の司令塔として機能する装置であって、例えば、コンピュータプログラムにより具体化された一又は複数の機能を実行するようにプログラムされたプロセッサとメモリとで構成される。制御装置２３は、上述した、データ管理機能、キャンペーン管理機能、配信機能等を有している。本実施形態では、制御装置２３の機能の一例として、更新処理見積り時間を算出する機能について説明する。

　制御装置２３は、更新用データのデータサイズに基づき、更新処理見積り時間を算出する。例えば、更新用データのデータサイズと更新処理見積り時間の関係を示すマップが予めデータベース２２に格納されている場合、制御装置２３は、当該マップを参照して、データサイズに応じた更新処理見積り時間を算出する。また例えば、制御装置２３は、更新用データのデータサイズが大きいほど、更新処理見積り時間を長く算出する。なお、更新用データのデータサイズは、新プログラムそのもののデータサイズ、又は差分データのデータサイズのいずれであってもよい。

　また制御装置２３は、更新用データのデータサイズに代えて、又はこれとともに、更新対象ＥＣＵの種別に基づき、更新処理見積り時間を算出してもよい。例えば、制御装置２３は、ＥＣＵが備えるマイコン及び／又はフラッシュメモリの仕様に基づき、更新処理見積り時間を算出する。例えば、制御装置２３は、更新対象ＥＣＵが備えるマイコンの動作周波数が所定の基準周波数よりも高い場合、当該マイコンの動作周波数が所定の基準周波数よりも低い場合に比べて、更新処理見積り時間を短く算出する。マイコンの動作周波数が高いほど、更新処理に要する時間は短くなるという観点に基づく。また例えば、制御装置２３は、更新対象ＥＣＵが備えるフラッシュメモリのメモリ容量が所定の基準容量よりも大きい場合、当該フラッシュメモリのメモリ容量が所定の基準容量よりも低い場合に比べて、更新処理に要する時間を長く算出する。フラッシュメモリのメモリ容量が大きいほど、プログラムのファイルサイズが大きくなり、更新処理に要する時間が長くなるという観点に基づく。また更新処理見積り時間の算出方法は一例であって、制御装置２３は、その他の算出方法を用いて更新処理見積り時間を算出してもよい。

　ユーザ端末３の構成について説明する。図１に示すように、ユーザ端末３は、端末通信装置３１と、端末ＨＭＩ（Human Machine Interface）３２と、端末制御装置３３を備える。

　端末通信装置３１は、無線通信回線網４を介して、サーバー２との間でデータ通信を行う機能を有する。端末ＨＭＩ３２は、ユーザの操作入力を受け付ける装置及びユーザに情報を知らせる装置のうち少なくとも何れか一方として機能する。端末ＨＭＩ３２としては、例えば、タッチパネルディスプレイ等が挙げられる。なお、端末ＨＭＩ３２は、情報を表示する装置に限られず、例えば、スピーカー等、情報を音声出力する装置であってもよい。なお、ユーザ端末３が、Bluetooth（登録商標）等を通じて車両１の車載装置と直接接続している場合にはユーザ端末３は、車両１の車載通信装置１１を介してサーバー２とデータ通信を行ってもよい。また、車載装置とユーザ端末３が直接接続している場合には、車載装置は、ユーザ端末３から無線通信回線網４を介してサーバー２と通信してもよい。

　端末制御装置３３は、ユーザ端末３の司令塔として機能する装置であって、例えば、コンピュータプログラムにより具体化された一又は複数の機能を実行するようにプログラムされたプロセッサとメモリとで構成される。端末制御装置３３は、車両１のＥＣＵのソフトウェア更新処理において、キャンペーン情報及び更新処理の進捗情報をユーザに通知するための処理を実行する。キャンペーン情報を例に挙げると、端末制御装置３３は、端末通信装置３１を介してサーバー２からキャンペーン情報を受信した場合、キャンペーン情報を端末ＨＭＩ３２に出力して、キャンペーン情報を端末ＨＭＩ３２に表示させる。また端末制御装置３３は、車両１のＥＣＵのソフトウェア更新処理において、ユーザに承諾を求めるための承諾要求処理を実行する。更新処理開始の承諾をユーザに求める場合を例に挙げると、端末制御装置３３は、更新処理開始の承諾をユーザに求めるための承諾要求画像を生成し、承諾要求画像を端末ＨＭＩ３２に出力して、承諾要求画像を端末ＨＭＩ３２に表示させる。

　車両１の室外にいるユーザは、ユーザ端末３が無線通信回線網４の圏内に位置する場合、ソフトウェア更新に関する各種情報をユーザ端末３により確認しながら操作入力を行い、ソフトウェア更新に関する手続きを行うことができる。なお、上述したユーザ端末３のブロック構成や機能は一例であって、ユーザ端末３を限定するものではない。また本実施形態では、ユーザがユーザ端末３を使用して更新処理に関する手続きを行う場合を例に挙げて説明するが、本発明に係るソフトウェア更新装置、ソフトウェア更新システム、及びソフトウェア更新方法は、ユーザが車載端末１２を使用して更新処理に関する手続きを行う場合にも適用することができる。

　次に、車両１の構成について説明する。図１に示すように、車両１は、ソフトウェア更新装置１０と、車載通信装置１１と、車載端末１２と、イグニッションスイッチ１３と、ボディ系ＥＣＵ１４Ａと、走行系ＥＣＵ１４Ｂと、マルチメディア系ＥＣＵ１４Ｃと、電源系ＥＣＵ１４Ｄを含む。車両１に含まれる各構成は、例えば、ＣＡＮ（Controller Area Network）、ＬＩＮ（Local Interconnect Network）等の車載ネットワークよって接続されている。

　車載通信装置１１は、無線通信回線網４を介して、サーバー２との間でデータ通信を行う機能を有する。車載通信装置１１としては、例えば、テレマティクスコントロールユニット（TCU：Telematics Control Unit）が挙げられる。

　車載端末１２は、車両１に乗車するユーザ（乗員）からの操作入力を受け付ける機能や各種画面を表示する機能を有する端末である。車載端末１２としては、例えば、タッチパネルディスプレイ等が挙げられる。車載端末１２には、ソフトウェア更新装置１０から、乗員に各種情報を知らせるための信号が入力される。車載端末１２は、例えば、ソフトウェア更新装置１０から、更新処理開始の承諾を乗員に求めるための情報が入力された場合、乗員に承諾を求めるための画像を表示する。また車載端末１２は、例えば、更新処理開始の承諾を示す操作を乗員が車載端末１２に行った場合、乗員が承諾したことを表す承諾情報をソフトウェア更新装置１０に出力する。車両１の室内にいるユーザは、車両１が無線通信回線網４の圏内に位置する場合、ソフトウェア更新に関する各種情報を車載端末１２により確認しながら操作入力を行い、ソフトウェア更新に関する手続きを行うことができる。なお、車載端末１２は、情報を表示する装置に限られず、例えば、スピーカー等、情報を音声出力する装置であってもよい。

　イグニッションスイッチ１３は、車両１の起動スイッチとして機能し、車両１のイグニッションをオン又はオフするためのスイッチである。イグニッションスイッチ１３は、例えば、乗員がイグニッションをオンからオフにする操作を行った場合、ユーザの操作内容を表す信号をソフトウェア更新装置１０に出力する。

　ボディ系ＥＣＵ１４Ａ、走行系ＥＣＵ１４Ｂ、及びマルチメディア系ＥＣＵ１４Ｃは、ソフトウェア更新装置１０により更新される対象のＥＣＵの一例である。各ＥＣＵは、機能ブロックとして、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、及びフラッシュメモリ（Flash Memory）から構成されるマイコンと、電源回路、データ転送回路等を有する。フラッシュメモリには、ＥＣＵのソフトウェアを実現するためのプログラムが格納されている。マイコンがフラッシュメモリに格納されたプログラムを実行して各種処理を行うことで、ＥＣＵのソフトウェアは実現される。

　ＥＣＵのフラッシュメモリは、メモリ構成に応じて、シングルバンクメモリとダブルバンクメモリに区分される。シングルバンクメモリは、プログラムの格納領域とマイコンによるプログラムの実行領域に区別がなく、マイコンがプログラムを実行中の間、シングルバンクメモリにプログラムを書き換えることはできない。一方、ダブルバンクメモリは、プログラムの格納領域として２面の領域を有しており、マイコンは、２面の格納領域のうちいずれか一方の格納領域のプログラムを実行する。このため、ダブルバンクメモリでは、マイコンがプログラムを実行中の間であっても、実行中のプログラムを格納しない他方の格納領域にプログラムを書き込むことができる。ダブルバンクメモリが有する２面のプログラム格納領域について、以降では、便宜上、第１メモリ及び第２メモリと称する。

　ボディ系ＥＣＵ１４Ａは、車両１のボディ系の制御を行うＥＣＵの総称である。ボディ系ＥＣＵ１４Ａとしては、例えば、車両１のドアのロック／アンロックを制御するドア制御用ＥＣＵ、車両１のメーター表示を制御するメーター制御用ＥＣＵ、車両１のエアコンの駆動を制御するエアコン制御用ＥＣＵ、車両１ウィンドウの開閉を制御するウィンドウ制御用ＥＣＵ等が挙げられる。走行系ＥＣＵ１４Ｂは、車両１の走行系の制御を行うＥＣＵの総称である。走行系ＥＣＵ１４Ｂとしては、例えば、車両１の駆動源を制御する駆動源制御用ＥＣＵ、車両１のブレーキの駆動を制御するブレーキ制御用ＥＣＵ、車両１のパワーステアリングの駆動を制御するパワーステアリング制御用ＥＣＵ等が挙げられる。マルチメディア系ＥＣＵ１４Ｃは、車両１のマルチメディア系の制御を行うＥＣＵの総称である。マルチメディア系ＥＣＵ１４Ｃとしては、例えば、車両１のナビゲーションシステムを制御するナビゲーション制御用ＥＣＵ、車両１のオーディオ機器を制御するオーディオ制御用ＥＣＵ等が挙げられる。

　ボディ系ＥＣＵ１４Ａ、走行系ＥＣＵ１４Ｂ、及びマルチメディア系ＥＣＵ１４Ｃには、ソフトウェア更新装置１０から更新処理の制御信号が入力され、各ＥＣＵではソフトウェアの更新処理が実行される。なお、図１では、各ＥＣＵが１つずつ示されているが、更新対象ＥＣＵの数は特に限定されず、ソフトウェア更新システム１００は、複数の更新対象ＥＣＵに対して、ソフトウェアを更新することができる。また図１に示すボディ系ＥＣＵ１４Ａ、走行系ＥＣＵ１４Ｂ、及びマルチメディア系ＥＣＵ１４Ｃは、車両１に搭載されるＥＣＵの一例であって、車両１に搭載されるＥＣＵの種別やＥＣＵの区別の仕方を限定するものではない。また車両１は、図１に示されるＥＣＵ以外のＥＣＵを搭載していてもよい。

　電源系ＥＣＵ１４Ｄは、車両１の電源系の制御を行うＥＣＵの総称である。電源系ＥＣＵ１４Ｄとしては、例えば、車両１に搭載されているＡＣＣ（アクセサリー）電源及びＩＧ（イグニッション）電源を制御する電源制御用ＥＣＵが挙げられる。電源系ＥＣＵ１４Ｄには、ソフトウェア更新装置１０から更新処理の制御信号が入力される。例えば、電源系ＥＣＵ１４Ｄは、車両１のイグニッションをオフさせる処理を実行する。

　ここで、ＯＴＡによるソフトウェア更新フローの概要とＥＣＵのメモリ構成との関係について、図２及び図３を用いて説明する。図２は、ＯＴＡによるソフトウェア更新のフローを説明するための説明図である。図２に示すように、ＯＴＡによるソフトウェア更新は、複数の段階を経て行われる。具体的に、ＯＴＡによるソフトウェア更新では、キャンペーン情報の通知（ステップＳ１）、ダウンロード（ステップＳ２）、インストール（ステップＳ３）、アクティベート（ステップＳ４）、更新完了確認（ステップＳ５）が順次行われる。

　ステップＳ１では、サーバー２から車両１及び／又はユーザ端末３にキャンペーン情報が送信され、車載端末１２及び／又はユーザ端末３を介して、ユーザにキャンペーン情報が通知される。ステップＳ２では、更新用データを含む配信パッケージがサーバー２から車両１に送信され、車両１では配信パッケージが格納される。ステップＳ３では、更新対象ＥＣＵに対して新プログラムの書き込み処理が行われる。ステップＳ４では、マイコンによる新プログラムの読込処理により、新プログラムが有効化される。ステップＳ５では、ソフトウェア更新の完了が車載端末１２及び／又はユーザ端末３を介してユーザに通知される。

　図３は、ＥＣＵのメモリ構成に応じた、ＯＴＡによるソフトウェア更新を説明するための説明図である。図３は、図２に示す複数のステップのうち、ダウンロード、インストール、アクティベート、及び更新完了確認の各ステップを「更新状態」として示している。また図３は、各更新状態における車両１の状態を「車両状態」として示し、更新対象ＥＣＵの動作を「対象ＥＣＵ」として示し、ユーザの状態を「ユーザ」として示している。図３（Ａ）は、ＥＣＵのメモリ構成がシングルバンクの場合でのソフトウェア更新フローの一例であり、図３（Ｂ）は、ＥＣＵのメモリ構成がダブルバンクの場合でのソフトウェア更新フローの一例である。

　図３（Ａ）に示すように、更新対象ＥＣＵのメモリ構成がシングルバンクの場合、車両１が走行可能な状態（イグニッションスイッチ１３がオン）で、車両１では配信パッケージの「ダウンロード」が行われる。ダウンロード完了後、車両１が停車した状態でイグニッションスイッチ１３がオンからオフに切り替わると、更新処理開始の承諾をユーザに求める「承諾要求」が行われる。本実施形態では、車両１の室外にいるユーザは、ソフトウェア更新に関する各種情報をユーザ端末３により確認しながら操作入力を行い、ソフトウェア更新に関する手続きを行う。

　サーバー２からのダウンロードが完了後、車両１の乗員（ドライバー）がイグニッションスイッチをオンからオフに切り替えると、例えば、ユーザ端末３には、更新処理開始の承諾を求める情報（例えば、「ソフトウェアを更新しますか？」の表示）と、ユーザが操作可能な２つのアイコンとして、承諾を示すアイコン（例えば、「今すぐ」の表示）及び拒否を示すアイコン（例えば、「後で」の表示）が表示される。ユーザが更新処理開始を承諾して「今すぐ」のアイコンを押した場合、車両１では更新用データを用いた「インストール」が行われる。具体的に、ＥＣＵのフラッシュメモリでは、旧プログラムの削除後に、新プログラムを書き込む書き換え処理が行われる。書き換え処理が完了すると、ＥＣＵのマイコンに新プログラムを読み込ませる「アクティベート」が行われる。その後、車両１の電源再起動処理（リブート処理）を経て、ソフトウェア更新が完了する。ソフトウェア更新が完了すると、ユーザ端末３には、更新が完了したことを示す更新完了通知が表示される（例えば、「ソフトウェア更新は完了しました」の表示）。また更新処理の完了後、車両１のイグニッションをオフにする処理が電源系ＥＣＵ１４Ｄにより実行される。一方、ユーザが更新処理開始を承諾せずに「後で」のアイコンを押した場合、車両１ではＥＣＵのソフトウェア更新処理が開始されることなく、車両１のイグニッションをオフにする処理が電源系ＥＣＵ１４Ｄにより実行される。またユーザ端末３には、更新処理の延期を示す更新処理延期通知が表示される（例えば、「次回へ延期します」の表示）。

　また図３（Ｂ）に示すように、ＥＣＵのメモリ構成がダブルバンクの場合、車両１が走行可能な状態で、車両１では配信パッケージの「ダウンロード」の他、更新用データを用いた「インストール」が行われる。ＥＣＵのマイコンが第１メモリに格納されたプログラム（旧プログラム）を実行している場合、第２メモリでは、新プログラムを書き込む書き込み処理が行われる。インストール完了後、車両１の乗員（ドライバー）がイグニッションスイッチ１３をオンからオフに切り替えると、更新処理開始の承諾をユーザに求める「承諾要求」が行われる。図３（Ａ）での例と同様に、ユーザ端末３には、例えば、更新処理開始の承諾を求める情報と、承諾を示すアイコン及び拒否を示すアイコンが表示される。ユーザが更新処理開始を承諾すると、マイコンの読込先のメモリを第１メモリから第２メモリに変更する「アクティベート」が行われる。その後、車両１の電源再起動処理を経て、ソフトウェア更新が完了する。

　このように、ＥＣＵのフラッシュメモリの構成に応じて、ソフトウェア更新処理の具体的な内容には、「インストール」及び「アクティベート」と「アクティベート」の違いがあるが、いずれの更新処理であっても、更新処理開始の承諾を乗員に求め、乗員が更新処理開始を承諾した操作を行った場合に、車両１では更新処理が実行される。また更新処理が完了した場合、ユーザは、ユーザ端末３に表示される更新完了通知を通じて、更新処理が完了したことを知ることができる。例えば、自宅にいる第１ユーザと車両１を使用する第２ユーザがいた場合、第２ユーザが自宅の駐車場に車両１を停車させてイグニッションスイッチをオンからオフに切り替え、第１ユーザがユーザ端末３を介してソフトウェアの更新手続きを行ったとする。その後、第１ユーザが車両１を使用して外出しようとする場合、更新完了通知を確認した第１ユーザは、ソフトウェアの更新処理が完了した状態の車両１を使用することができる。しかしながら、何らかの異常により更新処理の途中でループ処理等が発生し、更新処理が完了しない場合（更新処理が異常終了しない場合も含む）、ユーザ端末３には更新完了通知が表示されないため、第１ユーザは、車両１を使用できない可能性があるという問題がある。そこで、本実施形態に係るソフトウェア更新装置１０は、以下の構成及び方法によって、上記の問題の解決を図る。

　次に、ソフトウェア更新装置１０について説明する。図４に示すように、ソフトウェア更新装置１０は、コントローラ４０を備えている。図４は、ソフトウェア更新装置１０のコントローラ４０が有する機能ブロックの一例である。コントローラ４０は、ハードウェア及びソフトウェアを備えたコンピュータにより構成され、プログラムを格納したメモリと、このメモリに格納されたプログラムを実行するＣＰＵ等を有している。なお、動作回路としては、ＣＰＵに代えて又はこれとともに、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどを用いることができる。

　図４に示すように、コントローラ４０は、機能ブロックとして、情報取得部４１と、記憶部４２と、出力部４３と、開始判定部４４と、更新処理実行部４５と、制御部５０と、電源処理実行部５１を有している。コントローラ４０は、メモリに記憶されたソフトウェアによって、機能ブロックの各機能を実現する。

　情報取得部４１は、サーバー２から、車載通信装置１１を介して、ソフトウェア更新に関する更新処理情報を取得する。更新処理情報は、上述した、キャンペーン情報、及び配信パッケージを含む。また情報取得部４１は、イグニッションスイッチ１３から、イグニッションスイッチ１３のオン状態又はオフ状態を示す信号を取得する。また情報取得部４１は、車載端末１２から、ユーザの操作を示す信号を取得する。また情報取得部４１は、サーバー２を介して、ユーザ端末３でのユーザの操作を示す信号を取得する。例えば、ユーザがユーザ端末３に表示された承諾表示を押した場合、情報取得部４１は、ユーザ端末３から、サーバー２を経由して、承諾表示がユーザに押されたことを示す信号を取得する。また例えば、ユーザがユーザ端末３に表示された拒否表示を押した場合、情報取得部４１は、ユーザ端末３から、サーバー２を経由して、拒否表示がユーザに押されたことを示す信号を取得する。

　記憶部４２は、情報取得部４１により取得された情報のうち、サーバー２から取得した情報を記憶する記憶装置として機能する。記憶部４２としては、例えば、フラッシュメモリ等の不揮発性記録媒体が用いられる。記憶部４２は、サーバー２から取得されたキャンペーン情報及び配信パッケージを格納する。また記憶部４２は、車両１に搭載されるＥＣＵに関する情報（ＥＣＵのメモリ構成等）を記憶していてもよい。記憶部４２に記憶された各種情報は、更新処理実行部４５での処理に用いられる。

　出力部４３は、更新処理実行部４５による更新処理の開始を承諾するかをユーザに求める承諾要求情報を出力する。承諾要求情報としては、例えば、画像、音声などが挙げられるが、ユーザに承諾を求める方法は特に限定されない。例えば、上述したような「ソフトウェアを更新しますか？」の表示画像をメモリから読み出して、車載通信装置１１を介して、画像信号をサーバー２に送信する。また例えば、出力部４３は、画像信号とともに又はこれに代えて、更新処理開始を承諾するかをユーザに求める音声信号を、車載通信装置１１を介して、サーバー２に送信してもよい。車載通信装置１１から送信された承諾要求情報は、サーバー２で受信され、その後、サーバー２からユーザ端末３に送信される。

　また本実施形態では、出力部４３は、所定の出力条件を満たした場合、承諾要求情報を出力する。出力部４３は、情報取得部４１により取得された情報に基づき、イグニッションスイッチ１３が乗員によりオンからオフに操作されたか否かを判定する。出力部４３は、イグニッションスイッチ１３の状態を示す信号がオン状態からオフ状態に切り替わった場合、承諾要求情報を出力する。なお、出力部４３による出力条件は一例であって、出力条件はその他の条件であってもよい。

　開始判定部４４は、更新処理実行部４５による更新処理を開始するか否かを判定する。開始判定部４４は、出力部４３により出力された承諾要求情報に対してユーザが更新処理開始を承諾した場合、更新処理を開始すると判定し、承諾要求情報に対してユーザが更新処理開始を拒否した場合、更新処理を開始しないと判定する。例えば、更新処理開始の承諾を示す操作をユーザがユーザ端末３に行った場合、上述したように、情報取得部４１は、サーバー２から承諾情報を取得し、開始判定部４４は、更新処理を開始すると判定する。一方、例えば、更新処理開始の拒否を示す操作をユーザがユーザ端末３に行った場合、上述したように、情報取得部４１は、サーバー２から拒否情報を取得し、開始判定部４４は、更新処理を開始しないと判定する。

　更新処理実行部４５は、承諾要求情報に対するユーザの回答である回答情報に応じて、更新処理を実行する。更新処理実行部４５は、開始判定部４４により更新処理を開始すると判定された場合、更新処理を実行し、開始判定部４４により更新処理を開始しないと判定された場合、更新処理の実行を延期する。更新対象ＥＣＵでの更新処理が正常に終了した場合、更新処理実行部４５には、更新対象ＥＣＵから更新処理完了通知が入力され、更新処理実行部４５は、入力された通知を制御部５０に出力する。なお、開始判定部４４により更新処理を開始しないと判定された場合、更新処理の実行が延期されればよく、更新処理実行部４５は、その他の処理を実行してもよい。

　更新処理実行部４５は、更新処理を実行する機能ブロックとして、更新対象ＥＣＵメモリ構成に応じたインストール実行部及びアクティベート実行部を含む。図４に示すように、更新処理実行部４５は、メモリ構成がシングルバンクに対応した第１インストール実行部４６及び第１アクティベート実行部４７と、メモリ構成がダブルバンクに対応した第２インストール実行部４８及び第２アクティベート実行部４９とを含む。図３を用いて説明したように、ＥＣＵのメモリ構成がシングルバンクかダブルバンクかの違いによって、「インストール」及び「アクティベート」それぞれの処理内容に違いが生じる。このため、本実施形態では、複数のインストール実行部及び複数のアクティベート実行部が設けられている。更新対象ＥＣＵのメモリ構成がシングルバンクの場合、第１インストール実行部４６により新プログラムのインストールが行われ、第１アクティベート実行部４７により新プログラムのアクティベートが行われる。一方、更新対象ＥＣＵのメモリ構成がダブルバンクの場合、第２インストール実行部４８により新プログラムのインストールが行われ、第２アクティベート実行部４９により新プログラムのアクティベートが行われる。更新処理実行部４５は、記憶部４２に記憶された車両１に搭載されるＥＣＵに関する情報から、更新対象ＥＣＵのメモリ構成を判別する。

　第１インストール実行部４６は、フラッシュメモリに格納されている旧プログラムを削除した後に、新プログラムを書き込むインストール処理を実行する。第１アクティベート実行部４７は、フラッシュメモリに書き込まれた新プログラムを、更新対象ＥＣＵが備えるマイコンに読み込ませるアクティベート処理を実行する。

　フラッシュメモリの第１メモリ及び第２メモリのうち第１メモリに旧プログラムが格納され、マイコンが旧プログラムを読み込んでいる場合、第２インストール実行部４８は、旧プログラムが格納されていない第２メモリに、新プログラムを書き込むインストール処理を実行する。第２アクティベート実行部４９は、更新対象ＥＣＵが備えるマイコンによるプログラムの読込先を、第１メモリから第２メモリに切り替えるアクティベート処理を実行する。

　制御部５０は、更新処理に要する見積り時間に基づき、更新対象ＥＣＵが実行する対象プログラムを決定する。本実施形態では、更新処理に要する見積り時間は、サーバー２で算出された、更新処理見積り時間である。図３を用いて説明したように、更新処理の具体的内容は、更新対象ＥＣＵのメモリ構成に応じて、「インストール」及び「アクティベート」と「アクティベート」の違いがある。このため、サーバー２により算出される更新処理見積り時間の内訳は、更新対象ＥＣＵの仕様に応じて変わる。具体的に、更新対象ＥＣＵのメモリ構成がシングルバンクの場合、更新処理見積り時間は、インストール処理に要する時間とアクティベート処理に要する時間で構成される。更新対象ＥＣＵのメモリ構成がダブルバンクの場合、更新処理見積り時間は、アクティベートに要する時間で構成される。

　制御部５０は、更新処理見積り時間内に更新処理が完了しない場合、更新前ソフトウェアに対応した旧プログラムを、更新対象ＥＣＵに実行させる。一方、制御部５０は、更新処理見積り時間内に更新処理が完了した場合、更新済みソフトウェアに対応した新プログラムを、更新対象ＥＣＵに実行させる。

　例えば、制御部５０は、更新処理実行部４５により更新処理が開始されると、更新処理時間を計測するためのタイマーを起動させて、更新処理開始からの経過時間を計測し始める。制御部５０は、経過時間と更新処理見積り時間を比較しながら、更新処理実行部４５から更新処理完了通知が入力されるのを待機する。制御部５０は、更新処理見積り時間よりも短い経過時間で更新処理完了通知が入力された場合、新プログラムを、更新対象ＥＣＵが備えるマイコンに実行させる。一方、制御部５０は、経過時間が更新処理見積り時間を超えた場合、旧プログラムを、更新対象ＥＣＵが備えるマイコンに実行させる。

　経過時間が更新処理見積り時間を超えた場合の制御部５０の処理について、より詳細に説明する。経過時間が更新処理見積り時間を超えた場合、制御部５０は、更新対象ＥＣＵのメモリ構成に応じた異なる処理を実行する。メモリ構成がシングルバンクの場、制御部５０は、更新対象ＥＣＵに対してロールバック処理を実行する。ロールバックとは、更新処理を中断する場合に、プログラムのバージョンを元に戻す等、更新対象ＥＣＵのフラッシュメモリを所定状態に復帰させるための書き込み又は書き戻すことである。つまり、ロールバックとは、ユーザから見て更新対象ＥＣＵの状態を更新処理が開始される前の状態に戻すことである。制御部５０には、本願出願時に知られたロールバック処理を適用することができる。例えば、配信パッケージにロールバック用プログラムが含まれている場合、制御部５０は、ロールバック用プログラムを用いて、更新対象ＥＣＵに対してロールバック処理を実行する。

　メモリ構成がダブルバンクの場合、制御部５０は、新プログラムを更新対象ＥＣＵのフラッシュメモリに保存させる。例えば、旧プログラムの格納先が第１メモリ、新プログラムの書き込み先が第２メモリとすると、制御部５０は、第２メモリに書き込まれた新プログラムを保存させる。図３（Ｂ）の例のように、イグニッションスイッチ１３がオンの状態でインストールが行われ、第２メモリへの新プログラムの書き込みが完了している場合、制御部５０は、見積り経過時間内に更新処理が完了していなくても、第２プログラムを保存させる。

　電源処理実行部５１は、車両１のＩＧ電源である駆動用バッテリの出力電力をゼロにするための制御信号を電源系ＥＣＵ１４Ｄに出力し、車両１のイグニッションをオフさせる。

　次に、図５のフローチャートを参照しながら、本実施形態に係るソフトウェア更新方法の一例を説明する。図５に示すフローチャートは、図４に示すソフトウェア更新装置１０のコントローラ４０により実行される。なお、図５のフローチャートは、更新対象ＥＣＵのメモリ構成がシングルバンクの場合のフローチャートである。また図６のフローチャートは、図２に示す、ダウンロード（ステップＳ２）～更新完了の確認（ステップＳ５）のフローチャートである。

　ステップＳ１１では、コントローラ４０は、サーバー２から、車載通信装置１１を介して、配信パッケージを取得する（ダウンロード）。配信パッケージは、更新用データ、更新用データの認証処理に用いられる認証用データ、及び更新処理見積り時間を含む。ステップＳ１２では、コントローラ４０は、ステップＳ１１で取得した配信パッケージから更新処理見積り時間を取得する。

　ステップＳ１３では、コントローラ４０は、イグニッションスイッチ１３が乗員の操作によりオンからオフに切り替わったか否かを判定する。コントローラ４０は、イグニッションスイッチ１３から、乗員による操作を示す信号を取得する。乗員によりイグニッションスイッチ１３がオンからオフに切り替わった場合、ステップＳ１４に進み、イグニッションスイッチ１３がオンを維持する場合、乗員によりイグニッションスイッチがオンからオフに切り替わるまで、ステップＳ１３で待機する。

　ステップＳ１４では、コントローラ４０は、ソフトウェアの更新処理開始をユーザに承諾を求める承諾要求情報を出力する。本実施形態では、コントローラ４０は、車載通信装置１１を介して、承諾要求情報をサーバー２に送信する。その後、承諾要求情報は、サーバー２からユーザ端末３に送信される。

　ステップＳ１５では、コントローラ４０は、ステップＳ１４で出力した承諾要求情報に対してユーザが承諾したか否かを判定する。更新処理開始の承諾を示す操作をユーザがユーザ端末３に行った場合、ユーザ端末３からサーバー２には、承諾要求情報に対するユーザの回答情報として、承諾情報が送信される。コントローラ４０は、サーバー２から、承諾情報を取得し、更新処理を開始すると判定する。この場合、ステップＳ１６に進む。一方、更新処理開始の拒否を示す操作をユーザがユーザ端末３に行った場合、ユーザ端末３からサーバー２には、承諾要求情報に対するユーザの回答情報として、拒否情報が送信される。コントローラ４０は、サーバー２から、拒否情報を取得し、更新処理を開始しないと判定する。この場合、ステップＳ１９に進む。

　ステップＳ１５でユーザが承諾したと判定された場合、ステップＳ１６に進む。ステップＳ１６では、コントローラ４０は、更新対象ＥＣＵに対してソフトウェアの更新処理を開始させる。具体的には、ＥＣＵのメモリ構成がシングルバンクの場合、コントローラ４０は、図３（Ａ）の例で示すようなインストール処理及びアクティベート処理を実行する。各処理の具体的な内容については、既述の説明を援用する。また、このステップでは、コントローラ４０は、更新処理時間を計測するためのタイマーを起動させて、更新処理開始からの経過時間を計測し始める。

　ステップＳ１７では、コントローラ４０は、ステップＳ１６で開始された更新処理が正常終了したか否かを判定する。更新対象ＥＣＵから更新処理完了通知がコントローラ４０に入力された場合、コントローラ４０は、更新処理が正常終了したと判定する。この場合、ステップＳ１８に進む。一方、更新対象ＥＣＵから更新処理完了通知が入力されない場合、コントローラ４０は、更新処理が正常終了してないと判定する。この場合、ステップＳ２０に進む。

　ステップＳ１７で更新処理が正常終了したと判定された場合、ステップＳ１８に進む。ステップＳ１８では、コントローラ４０は、更新対象ＥＣＵが実行する対象プログラムを新プログラムに決定し、更新対象ＥＣＵに新プログラムを実行させる。ステップＳ１９では、コントローラ４０は、ステップＳ１３での乗員によるイグニッションスイッチへの操作に対応する処理として、車両１のイグニッションをオフする処理を実行する。具体的には、コントローラ４０は、車両１のイグニッションをオフさせる制御信号を、電源系ＥＣＵ１４Ｄに出力する。ステップＳ１９の処理が終了すると、図５に示すフローチャートでの処理が終了する。

　ステップＳ１７で更新処理が正常終了してないと判定された場合、ステップＳ２９に進む。ステップＳ２０では、コントローラ４０は、更新処理が異常終了したか否かを判定する。例えば、コントローラ４０は、更新対象ＥＣＵから異常終了通知が入力された場合、更新処理が異常終了したと判定する。この場合、ステップＳ２１に進む。一方、例えば、コントローラ４０は、更新対象ＥＣＵから異常終了通知が入力されない場合、更新処理が異常終了してないと判定する。この場合、ステップＳ２２に進む。

　ステップ２０で更新処理が異常終了したと判定された場合、ステップＳ２１に進む。ステップＳ２１では、コントローラ４０は、更新対象ＥＣＵが実行する対象プログラムを旧プログラムに決定し、更新対象ＥＣＵに旧プログラムを実行させる。例えば、コントローラ４０は、更新対象ＥＣＵに対してロールバック処理を行う。ステップＳ２１の処理が終了すると、ステップＳ１９に進み、コントローラ４０は、上述したステップＳ１９での処理を実行する。

　ステップＳ２０で更新処理が異常終了してないと判定された場合、ステップＳ２２に進む。ステップＳ２２では、コントローラ４０は、ステップＳ１６から計測し始めた経過時間が、ステップＳ１２で取得した更新処理見積り時間を超えたか否かを判定する。コントローラ４０により経過時間が更新処理見積り時間を超えたと判された場合、ステップＳ２１に進み、コントローラ４０は、上述したステップＳ２１での処理を実行する。一方、コントローラ４０により経過時間が更新処理見積り時間を超えていないと判定された場合、ステップＳ１７に戻り、以降、図５での処理が終了するまで、上述した各ステップでの処理が実行される。

　更新対象ＥＣＵのメモリ構成がダブルバンクの場合のフローチャートについて、図５を用いて、シングルバンクでの処理と異なるステップのみを説明する。メモリ構成がダブルバンクの場合、コントローラ４０は、ステップＳ１１の処理が終了すると、ステップＳ１２に進む前に、ステップＳ１１で取得した新プログラムを用いて、インストール処理を実行する。具体的には、ＥＣＵのメモリ構成がダブルバンクの場合、コントローラ４０は、図３（Ｂ）の例で示すようなインストール処理を実行する。処理の具体的な内容については、既述の説明を援用する。

　またステップＳ１２では、コントローラ４０は、更新処理見積り時間として、アクティベート処理の見積り時間を取得する。このため、ステップＳ２２での経過時間との比較対象は、アクティベート処理の見積り処理時間になる。またステップＳ１６では、コントローラ４０は、更新対象ＥＣＵに対するソフトウェアの更新処理として、アクティベート処理を実行する。ＥＣＵのメモリ構成がダブルバンクの場合、コントローラ４０は、図３（Ｂ）の例で示すようなアクティベート処理を実行する。処理の具体的な内容については、既述の説明を援用する。またステップＳ２１では、コントローラ４０は、メモリに書き込まれた新プログラムを保存し、ＥＣＵのマイコンの読込先を旧プログラムが格納されているメモリに切り替える。

　以上のように、本実施形態に係るソフトウェア更新装置１０は、車両１に搭載されるボディ系ＥＣＵ１４Ａ、走行系ＥＣＵ１４Ｂ、マルチメディア系ＥＣＵ１４Ｃのソフトウェアを更新するソフトウェア更新装置である。ソフトウェア更新装置１０は、出力部４３と、更新処理実行部４５と、制御部５０を備える。出力部４３は、サーバー２から、ソフトウェアの更新に関する更新処理情報を取得する。更新処理実行部４５は、承諾要求情報に対するユーザの回答である回答情報に応じて、更新処理を実行する。制御部５０は、更新処理見積り時間に基づき、更新対象ＥＣＵが実行する対象プログラムを決定する。また制御部５０は、更新処理見積時間内に更新処理が完了しない場合、旧プログラムを更新対象ＥＣＵに実行させ、更新処理見積り時間内にソフトウェアの更新が完了した場合、新プログラムを更新対象のＥＣＵに実行させる。

　ソフトウェアの更新処理が終了しないエラーが起きる原因としては、例えば、更新対象ＥＣＵの周辺環境等が考えられている。例えば、何らかの原因により更新対象ＥＣＵの周辺温度が上昇すると、更新対象ＥＣＵでは、温度センサの検出結果に基づく自己診断処理が実行され、マイコンの演算負荷が下がる。マイコンの演算負荷が下がると、マイコンでの処理速度が低下して、更新処理が終了しないエラーに繋がると考えられている。しかしながら、本実施形態に係るソフトウェア更新装置１０、ソフトウェア更新システム１００、及びソフトウェア更新方法によれば、そのような原因で更新処理が終了しないエラーが発生した場合であっても、更新対象ＥＣＵが実行する対象プログラムを決定できるため、車両１が使用可能な状態になり、ユーザは車両１を使用できる。

　また本実施形態では、情報取得部４１は、サーバー２から、更新処理見積り時間を取得する。これにより、ソフトウェア更新装置１０で更新処理見積りを算出することなく、更新対象ＥＣＵが実行する対象プログラムを決定できるため、ソフトウェア更新装置１０での演算負荷を低減することができる。

　また本実施形態では、更新対象ＥＣＵは、旧プログラムを格納するフラッシュメモリを有し、更新処理実行部４５は、第１インストール実行部４６と第１アクティベート実行部４７を含む。第１インストール実行部４６は、旧プログラムをフラッシュメモリから削除した後に、フラッシュメモリに新プログラムを書き込むインストール処理を実行する。第１アクティベート実行部４７は、フラッシュメモリに書き込まれた新プログラムをマイコンに読み込ませるアクティベート処理を実行する。制御部５０は、更新処理見積り時間内に更新処理が完了しない場合、更新対象ＥＣＵに対してロールバック処理を実行する。これにより、更新対象ＥＣＵのメモリ構成がシングルバンクの場合にも、更新処理が終了しないエラーの発生に対して、更新対象ＥＣＵが実行する対象プログラムを決定できる。

　また本実施形態では、更新対象ＥＣＵは、旧プログラムを格納する第１メモリと、第２メモリのダブルバンクで構成されるフラッシュメモリを有し、更新処理実行部４５は、第２インストール実行部４８と第２アクティベート実行部４９を含む。第２インストール実行部４８は、第２メモリに新プログラムを書き込む。第２アクティベート実行部４９は、マイコンのプログラムの読込先を、第１メモリから第２メモリに切り替えるアクティベート処理を実行する。制御部５０は、更新処理見積り時間内に更新処理が完了しない場合の処理として、第２メモリに書き込まれた新プログラムを保存させる。更新対象ＥＣＵの第２メモリに新プログラムを保存できるため、更新処理が再度行われる際に、インストールする必要がなくなり、ソフトウェア更新装置１０の演算負荷を低減することができる。

　また本実施形態に係るソフトウェア更新システム１００では、サーバー２は、更新用データのサイズ、及び更新対象ＥＣＵの種別のうち少なくとも何れか一方に基づき、更新処理見積り時間を算出する。これにより、ソフトウェア更新装置１０での演算負荷を低減することができる。

　なお、本実施形態では、ソフトウェア更新装置１０が、サーバー２から更新処理見積り時間を取得する構成を例に挙げて説明したが、更新処理見積り時間を算出する主体はサーバー２に限定されず、ソフトウェア更新装置１０が更新処理見積り時間を算出してもよい。

　本実施形態の変形例として、コントローラ４０は、機能ブロックとして、更新用データのデータサイズ及び更新対象ＥＣＵの種別のうち少なくとも何れか一方に基づき、更新処理見積り時間を算出する算出部を有していてもよい。例えば、更新用データのデータサイズと更新処理見積り時間の関係を示すマップが予め記憶部４２に格納されている場合、算出部は、当該マップを参照して、データサイズに応じた更新処理見積り時間を算出してもよい。また例えば、算出部は、更新用データのデータサイズが大きいほど、更新処理見積り時間を長く算出してもよい。また例えば、制御装置２３は、ＥＣＵが備えるマイコン及び／又はフラッシュメモリの仕様に基づき、更新処理見積り時間を算出してもよい。具体的な算出方法の例については、上述した制御装置２３での算出方法の例を援用する。変形例のように、ソフトウェア更新装置１０が更新処理見積り時間を算出することで、サーバー２での演算負荷を低減することができる。なお、コントローラ４０が更新処理見積り時間を算出するタイミングは、更新処理が開始される前であれば特に限定されないが、例えば、図５のフローチャートのステップＳ１２において、コントローラ４０は、更新処理見積り時間を取得する代わりに、更新処理見積り時間を算出する。

　≪第２実施形態≫
　次に、第２実施形態に係るソフトウェア更新装置について説明する。上述した第１実施形態では、図２に示すＯＴＰによるソフウェア更新の各ステップのうち、インストール（ステップＳ３)とアクティベート（ステップＳ４）を例に挙げて説明したが、本実施形態では、インストール及びアクティベートに加えて、ダウンロード（ステップＳ２）を含めた例について説明する。例えば、ステップＳ１でのキャンペーン情報の通知後に更新開始の承諾をユーザに求め、ユーザが承諾した場合に、その後、ユーザに承諾を求めることなく、ダウンロード～アクティベートが順次行われる場面が想定される。一例として、車両が自宅の駐車場に駐車中等、車両がユーザに使用されてない状況で、ＯＴＰによるソフトウェア更新が行われる場面が挙げられる。

　第２実施形態に係るソフトウェア更新システムは、第１実施形態に係るソフトウェア更新システム１００に対して、サーバー２が算出する見積り時間と、ソフトウェア更新装置１０のコントローラ６０が備える機能ブロックが異なる以外は、第１実施形態に係るソフトウェア更新システム１００と同じ構成である。このため、第１実施形態と同じ構成については、既述の説明を援用する。

　本実施形態では、サーバー２は、配信パッケージのダウンロードが完了するまでのダウンロード見積り時間と、第１実施形態における更新処理見積り時間とを合わせて、ソフトウェアの更新が完了するまでの見積り時間（更新完了見積り時間）として算出する。サーバー２は、更新完了見積り時間を含むキャンペーン情報を一又は複数の車両１に配信する。

　サーバー２の制御装置２３は、配信パッケージのデータサイズに基づき、ダウンロード見積り時間を算出する。例えば、配信パッケージのデータサイズとダウンロード見積り時間の関係を示すマップが予めデータベース２２に格納されている場合、制御装置２３は、当該マップを参照して、データサイズに応じたダウンロード見積り時間を算出する。また例えば、制御装置２３は、配信パッケージのデータサイズが大きいほど、ダウンロード見積り時間を長く算出する。

　次に、本実施形態のコントローラ４０の機能ブロックについて説明する。図６は、本実施形態に係るソフトウェア更新装置１０のコントローラ６０が有する機能ブロックの一例である。本実施形態では、コントローラ６０は、第１実施形態での機能ブロックに加えて、通信状況取得部５２と、補正部５３と、通知部５４を有している。また本実施形態では、第１実施形態に対して、出力部４３の機能が一部異なる。コントローラ６０は、メモリに記憶されたソフトウェアによって、機能ブロックの各機能を実現する。なお、第１実施形態と同様の機能ブロックについては、第１実施形態での説明を援用する。

　本実施形態では、出力部４３は、更新処理実行部４５による更新処理のみならず、サーバー２からの配信パッケージのダウンロードも含めて、ソフトウェアの更新を承諾するか否かをユーザに求める承諾要求情報を出力する。承諾要求情報の具体例やユーザ端末３に送信されるまでの方法については、第１実施形態での説明を援用する。また本実施形態では、出力部４３は、情報取得部４１によりキャンペーン情報を取得してから、情報取得部４１が配信パッケージを取得するまでの間に、承諾要求情報を出力する。

　通信状況取得部５２は、サーバー２との間の通信状況に関する通信状況情報を取得する。通信状況取得部５２は、車載通信装置１１とサーバー２の通信装置２１との間に通信状態を検知し、検知した通信状態を通信状況情報として取得する。例えば、通信状況取得部５２は、車載通信装置１１と通信装置２１との間で通信が成立しない状態の場合、通信状態の異常と検知する。また通信状況取得部５２は、無線データ通信における遅延時間を算出してもよい。遅延時間は、車載通信装置１１の能力により決まる固定的な遅延時間と、無線通信回線網４にアクセスする通信装置の多さ、通信するデータサイズ（通信料）等により変動する遅延時間を含む。通信状況取得部５２には、本願出願時に知られた通信状況を取得する技術を適用することができる。

　補正部５３は、キャンペーン情報から更新完了見積り時間を取得し、通信状況取得部５２により取得された通信状況情報に基づき、更新完了見積り時間を補正する。更新完了見積り時間のうち、サーバー２で算出されたダウンロード見積り時間には実際の通信状況が考慮されてないため、ダウンロード見積り時間と実際のダウンロード時間とが相違する可能性がある。例えば、車載通信装置１１と通信装置２１との間の通信状態が良好のため、無線データ通信における遅延時間が短くなり、実際のダウンロード時間がダウンロード見積り時間よりも早まる場合がある。補正部５３は、無線データ通信における遅延時間に応じて、ダウンロード見積り時間を短縮させる。当然に、車載通信装置１１と通信装置２１との間の通信状態が悪いため、無線データ通信における遅延時間が長くなり、実際のダウンロード時間がダウンロード見積り時間より遅くなる場合もある。この場合、補正部５３は、通信状況情報に含まれる無線データ通信における遅延時間に応じて、ダウンロード見積り時間を延長させる。

　通知部５４は、補正部５３により補正されたダウンロード見積り時間（以降、補正後のダウンロード見積り時間と称す）と、更新処理見積り時間とが合算された更新見積り時間（以降、補正後の更新見積り時間と称す）の情報を出力する。本実施形態では、通知部５４は、車載通信装置１１を介して、補正後の更新見積り時間の情報を、サーバー２に送信する。車載通信装置１１から送信された補正後の更新見積り時間の情報は、サーバー２で受信され、その後、サーバー２からユーザ端末３に送信される。補正後の更新見積り時間の情報がユーザ端末３に表示されることで、ユーザには補正後の見積り時間が通知される。

　また通知部５４は、補正後の更新見積り時間の情報を出力する出力条件として、補正後の更新見積り時間が、サーバー２で算出された更新見積り時間（以降、補正前の更新見積り時間と称す）よりも所定の閾値時間以上長い場合、補正後の更新見積り時間を出力してもよい。所定の閾値時間としては、例えば、５分等の分単位の時間であって、予め定められた時間が挙げられる。実際の更新時間が見積り時間よりも大幅に遅れることが予想される場合、更新を承諾するか否かのユーザの判断に影響を与える可能性が高いため、配信パッケージがダウンロードされる前にユーザに補正後の更新時間を通知する。一方、通知部５４は、補正後の更新見積り時間が補正前の更新見積り時間よりも短い場合、補正後の見積り時間を出力しなくてもよい。実際の更新時間が見積り時間よりも早まることが予想される場合、更新を承諾するか否かのユーザの判断に影響を与える可能性は低いため、配信パッケージがダウンロードされる前に補正後の更新時間をユーザに通知しない。

　次に、図７のフローチャートを参照しながら、本実施形態に係るソフトウェア更新方法の一例を説明する。図７に示すフローチャートは、図６に示すソフトウェア更新装置１０のコントローラ６０により実行される。なお、図７のフローチャートは、更新対象ＥＣＵのメモリ構成がシングルバンクの場合のフローチャートである。また図７のフローチャートは、図２に示す、キャンペーン情報の通知（ステップＳ１）～更新完了の確認（ステップＳ５）のフローチャートである。また図７のフローチャートは、図６のフローチャートと同じステップを一部含む。図６と同じステップには、図６のステップと同じ符号が付されており、図６と同じステップについては、既述の説明を援用する。図７のフローチャートでは、イグニッションスイッチ１３はオフされているものとし、図６に示すステップＳ１９が省略されている。なお、図７のフローチャートにおいて、図６に示すステップＳ１９での処理が行われてもよい。

　ステップＳ３１では、コントローラ６０は、サーバー２から、車載通信装置１１を介して、キャンペーン情報を取得する（ダウンロード）。キャンペーン情報は、更新用データのデータサイズ、更新対象ＥＣＵを識別する情報、更新対象であるソフトウェアのバージョンの情報、更新される機能の概要説明、ダウンロード見積り時間、及び、更新処理見積り時間等を含む。ステップＳ３２では、コントローラ６０は、ステップＳ３１で取得したキャンペーン情報から、ダウンロード見積り時間と更新処理見積り時間が合算された更新見積り時間を取得する。

　ステップＳ３３では、コントローラ６０は、サーバー２との間の通信状況に関する通信状況情報に基づき、ステップＳ３２で取得した更新見積り時間のうち、ダウンロード見積り時間を補正する。コントローラ６０は、補正されたダウンロード見積り時間とステップＳ３１で取得した更新処理見積り時間とが合算された補正後の更新見積り時間を出力する。本実施形態では、コントローラ６０は、車載通信装置１１及びサーバー２を介して、補正後の更新見積り時間をユーザ端末３に送信する。

　ステップＳ３４では、コントローラ６０は、ソフトウェアの更新をユーザに承諾を求める承諾要求情報を出力する。本実施形態では、コントローラ６０は、車載通信装置１１及びサーバー２を介して、承諾要求情報をユーザ端末３に送信する。

　ステップＳ３５では、コントローラ６０は、ステップＳ３４で出力した承諾要求情報に対してユーザが承諾したか否かを判定する。ソフトウェアの更新の承諾を示す操作をユーザがユーザ端末３に行った場合、ユーザ端末３からサーバー２には、承諾要求情報に対するユーザの回答情報として、承諾情報が送信される。コントローラ６０は、サーバー２から、承諾情報を取得し、ソフトウェアの更新を開始すると判定する。また本実施形態では、ユーザが承諾したと判定された場合、コントローラ６０は、配信パッケージのダウンロード時間及び更新処理時間を計測するためのタイマーを起動させて、配信パッケージのダウンロードからの経過時間を計測し始める。

　一方、更新処理開始の拒否を示す操作をユーザがユーザ端末３に行った場合、ユーザ端末３からサーバー２には、承諾要求情報に対するユーザの回答情報として、拒否情報が送信される。コントローラ６０は、サーバー２から、拒否情報を取得し、図７に示すフローチャートでの処理が終了する。

　ステップＳ３５でユーザが承諾したと判定された場合、ステップＳ１１に進み、第１実施形態と同様に、コントローラ６０による配信パッケージのダウンロードが開始される。配信パッケージのダウンロードが完了した後、ステップＳ１６に進み、第１実施形態と同様に、コントローラ６０による更新処理が開始される。

　ステップＳ３７は、図６に示すステップＳ２２に対応したステップである。ステップＳ３７では、コントローラ６０は、ステップＳ３５でユーザが承諾した場合に計測し始めた計測時間と、ステップＳ３３で補正した補正後の更新見積り時間とを比較し、経過時間が補正後の更新見積り時間を超えたか否かを判定する。経過時間の起算タイミングと経過時間の比較対象が異なる以外は、ステップＳ２２と同様のため、既述の説明を援用する。

　以上のように、本実施形態に係るソフトウェア更新装置１０は、通信状況取得部５２と、補正部５３と、通知部５４を備える。通信状況取得部５２は、サーバー２との間の通信状況に関する通信状況情報を取得する。補正部５３は、通信状況情報に基づき、更新見積り時間を補正する。通知部５４は、補正後の更新見積り時間の情報を出力する。これにより、ダウンロード見積り時間の精度を向上させることができる。またダウンロード見積り時間を含む更新見積り時間をユーザに通知できるため、ユーザは、ダウンロードを含めてソフトウェアの更新に要する見積り時間を認識することができる。

　また本実施形態では、通知部５４は、補正後の更新見積り時間が補正前の更新見積り時間よりも、予め設定された所定の閾値時間以上長い場合、補正後の更新見積り時間の情報を出力する。これにより、例えば、車載通信装置１１と通信装置２１との間の通信状態が悪いため、実際のダウンロード時間がダウンロード見積り時間より遅くなる場合であっても、ユーザは、実際の通信状況が考慮された見積り時間を認識することができる。

　また本実施形態では、通知部５４は、補正後の更新見積り時間が補正前の更新見積り時間よりも短い場合、補正後の更新見積り時間の情報を出力しない。これにより、例えば、車載通信装置１１と通信装置２１との間の通信状態が良好なため、実際のダウンロード時間がダウンロード見積り時間より早まる場合には、ユーザに見積り時間を通知する処理を省略することができる。その結果、ＯＴＰによるソフトウェア更新フロー全体に要する時間の短縮化を図ることができる。

　なお、以上に説明した実施形態は、本発明の理解を容易にするために記載されたものであって、本発明を限定するために記載されたものではない。したがって、上記の実施形態に開示された各要素は、本発明の技術的範囲に属する全ての設計変更や均等物をも含む趣旨である。

　例えば、上述した第１実施形態では、車両１が走行可能な状態で、配信パッケージのダウンロードが行われるフローを例に挙げて説明したが、第１実施形態における「更新処理見積り時間」を、第２実施形態における「ダウンロード見積り時間と更新処理見積り時間とが合算された更新見積り時間」に置き換えることができる。例えば、第１実施形態の変形例では、コントローラ４０が更新処理見積り時間を算出する算出部を有する構成を例に挙げて説明したが、第２実施形態に係るコントローラ６０は、更新見積り時間のうち、ダウンロード見積り時間を算出する算出部を有していてもよい。車両１が走行経路に沿って走行する場合、情報取得部４１は、車両１のナビゲーションシステム（図示しない）から車両１の走行経路の情報を取得する。算出部は、通信状況取得部５２により取得された通信状況情報と、情報取得部４１により取得された車両１の走行経路に基づき、ダウンロード見積り時間を算出する。例えば、算出部は、通信事業者が提供する、無線通信回線網４の通信状況を示す通信マップから、走行経路上の複数の地点での無線通信回線網４の通信状況情報を取得する。算出部は、車両１の走行経路上での通信状況情報に基づき、車両１が走行経路に沿って走行した場合のダウンロード見積り時間を算出する。車両１の走行可能な状態で、配信パッケージをダウンロードする場合のダウンロード見積り時間の精度を向上させることができる。

　また例えば、上述した第２実施形態において、更新見積り時間を補正する構成を例に挙げて説明したが、更新見積り時間を補正する構成に限定されない。コントローラ６０は、補正前の更新見積り時間を用いて、更新対象ＥＣＵの実行対象プログラムを決定してもよい。

　また例えば、上述した第２実施形態では、図２に示すダウンロード（ステップＳ２）～更新完了の通知（ステップＳ５）までの間、ユーザへの承諾要求がないフローを例に挙げて説明したが、コントローラ６０は、各ステップの処理開始前に、処理開始を承諾するかをユーザに求める承諾要求情報を出力してもよい。またコントローラ６０は、メモリ構成がダブルバンクの場合であって、経過時間が更新見積り時間（補正した場合も含む）を超えた場合の処理として、更新対象ＥＣＵに対してロールバック処理を実行してもよい。例えば、図７のフローチャートにおいて、実際のダウンロード時間がダウンロード見積り時間よりも長くなり、インストール処理を実行中に、経過時間が補正後の更新見積り時間を超えたと判定されたとする（ステップＳ３６でＹｅｓと判定）。この場合、第２メモリへの新プログラムの書き込みが完了していないため、コントローラ６０は、更新対象ＥＣＵに対してロールバック処理を実行する。更新対象ＥＣＵのメモリ構成がダブルバンクであって、新プログラムの書き込みが完了してない場合であっても、更新対象ＥＣＵが実行する対象プログラムを決定できるため、車両１が使用可能な状態になり、ユーザは車両１を使用できる。

　また例えば、コントローラ６０は、更新処理が開始してから完了するまでに要した実際の所要時間を計測する計測部を備えていてもよい。出力部４３は、計測部による計測が完了すると、車載通信装置１１を介して、更新処理に要した実際の所要時間の情報を、サーバー２に送信する。これにより、ソフトウェアの更新が済んでいない他の車両１への更新処理見積り時間に反映させることができ、更新処理見積り時間の精度を向上させることができる。

１００…ソフトウェア更新システム
　１…車両
　　１０…ソフトウェア更新装置
　　　４０…コントローラ
　　　　４１…情報取得部
　　　　４２…記憶部
　　　　４３…出力部
　　　　４４…開始判定部
　　　　４５…更新処理実行部
　　　　　４６…第１インストール実行部
　　　　　４７…第１アクティベート実行部
　　　　　４８…第２インストール実行部
　　　　　４９…第２アクティベート実行部
　　　　５０…制御部
　　　　５１…電源処理実行部
　　１１…車載通信装置
　　１２…車載端末
　　１３…イグニッションスイッチ
　　１４Ａ…ボディ系ＥＣＵ
　　１４Ｂ…走行系ＥＣＵ
　　１４Ｃ…マルチメディア系ＥＣＵ
　　１４Ｄ…電源系ＥＣＵ
　２…サーバー
　　２１…通信装置
　　２２…データベース
　　２３…制御装置
　３…ユーザ端末
　　３１…端末通信装置
　　３２…端末ＨＭＩ
　　３３…端末制御装置

Claims (14)

1. 　車両に搭載される車載制御装置のソフトウェアを更新するソフトウェア更新装置であって、
   　前記車両の外部に設けられたサーバーから、前記ソフトウェアの更新に関する更新処理情報を取得する情報取得部と、
   　前記ソフトウェアの更新を承諾するかユーザに求める承諾要求情報を出力する出力部と、
   　前記承諾要求情報に対する前記ユーザの回答である回答情報に応じて、前記ソフトウェアの更新処理を実行する実行部と、
   　前記更新に要する見積り時間に基づき、前記車載制御装置が実行する対象プログラムを決定する制御部を備え、
   前記制御部は、
   　前記見積り時間内に前記更新が完了しない場合、更新前ソフトウェアに対応したプログラムを、前記車載制御装置に実行させ、
   　前記見積り時間内に前記更新が完了した場合、更新済みソフトウェアに対応したプログラムを、前記車載制御装置に実行させるソフトウェア更新装置。
2. 　請求項１に記載のソフトウェア更新装置であって、
   前記情報取得部は、前記サーバーから、前記見積り時間を取得するソフトウェア更新装置。
3. 　請求項１に記載のソフトウェア更新装置であって、
   　前記ソフトウェアを更新するために用いるデータのサイズ、及び前記車載制御装置の種別のうち少なくとも何れか一方に基づき、前記見積り時間を算出する算出部を備えるソフトウェア更新装置。
4. 　請求項１～３の何れかに記載のソフトウェア更新装置であって、
   　前記サーバーとの間の通信状況に関する通信状況情報を取得する通信状況取得部と、
   　前記通信状況情報に基づき、前記見積り時間を補正する補正部と、
   　前記補正された見積り時間の情報を出力する通知部を備えるソフトウェア更新装置。
5. 　請求項４に記載のソフトウェア更新装置であって、
   前記通知部は、前記補正された見積り時間が前記見積り時間よりも所定の閾値時間以上長い場合、前記補正された見積り時間の情報を出力するソフトウェア更新装置。
6. 　請求項４又は５に記載のソフトウェア更新装置であって、
   前記通知部は、前記補正された見積り時間が前記見積り時間よりも短い場合、前記補正された見積り時間の情報を出力しないソフトウェア更新装置。
7. 　請求項１又は２に記載のソフトウェア更新装置であって、
   　前記サーバーとの間の通信状況を示す通信情報を取得する通信状況取得部と、
   　前記見積り時間を算出する算出部を備え、
   前記情報取得部は、前記車両の走行経路の情報を取得し、
   前記算出部は、前記車両の走行経路及び前記通信状況に基づき、前記見積り時間を算出するソフトウェア更新装置。
8. 　請求項１～７の何れかに記載のソフトウェア更新装置であって、
   前記車載制御装置は、古いバージョンの前記ソフトウェアを実現するための第１プログラムを格納する第１メモリを有し、
   前記実行部は、
   　前記第１プログラムを前記第１メモリから削除した後に、前記第１メモリに、新しいバージョンの前記ソフトウェアを実現するための第２プログラムを書き込むインストール処理を実行するインストール実行部と、
   　前記第１メモリに書き込まれた前記第２プログラムを読み込ませるアクティベート処理を実行するアクティベート実行部を含み、
   前記制御部は、前記見積り時間内に前記更新処理が完了しない場合、前記車載制御装置に対してロールバック処理を実行するソフトウェア更新装置。
9. 　請求項１～７の何れかに記載のソフトウェア更新装置であって、
   前記車載制御装置は、古いバージョンの前記ソフトウェアを実現するための第１プログラムを格納する第１メモリと、第２メモリを有し、
   前記実行部は、
   　前記第２メモリに、新しいバージョンの前記ソフトウェアを実現するための第２プログラムを書き込むインストール実行部と、
   　プログラムの読込先を、前記第１メモリから前記第２メモリに切り替えるアクティベート処理を実行するアクティベート実行部を含み、
   前記制御部は、前記見積り時間内に前記更新処理が完了しない場合の処理として、前記第２メモリに書き込まれた前記第２プログラムを保存させるソフトウェア更新装置。
10. 　請求項９に記載のソフトウェア更新装置であって、
    前記制御部は、前記見積り時間内に前記更新が完了しない場合の処理として、前記車載制御装置に対してロールバック処理を実行するソフトウェア更新装置。
11. 　請求項１～７の何れかに記載のソフトウェア更新装置であって、
    　前記更新処理が開始してから完了するまでに要した実際の所要時間を計測する計測部を備え、
    前記出力部は、前記実際の所要時間の情報を、前記サーバーに出力するソフトウェア更新装置。
12. 　請求項１～１１の何れかに記載のソフトウェア更新装置と、前記サーバーを含むソフトウェア更新システム。
13. 　請求項１２に記載のソフトウェア更新システムであって、
    　前記サーバーは、前記ソフトウェアを更新するために用いるデータのサイズ、及び前記車載制御装置の種別のうち少なくとも何れか一方に基づき、前記見積り時間を算出するソフトウェア更新システム。
14. 　コントローラが、車両に搭載される車載制御装置のソフトウェアを更新するソフトウェア更新方法であって、
    　前記車両の外部に設けられたサーバーから、前記ソフトウェアの更新に関する更新処理情報を取得し、
    　前記ソフトウェアの更新を承諾するかユーザに求める承諾要求情報を出力し、
    　前記承諾要求情報に対する前記ユーザの回答である回答情報に応じて、前記ソフトウェアの更新処理を実行し、
    　前記更新に要する見積り時間内に前記更新が完了しない場合、更新前ソフトウェアに対応したプログラムを、前記車載制御装置に実行させ、
    　前記見積り時間内に前記更新が完了した場合、更新済みソフトウェアに対応したプログラムを、前記車載制御装置に実行させるソフトウェア更新方法。

Images