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

Description

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

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

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

上記情報処理端末では、ソフトウェア更新に対するユーザの承諾処理が考慮されてないため、更新処理の開始を承諾するかユーザに求めても、ユーザからの回答がない場合、更新処理を開始すべきか否かを判定するのが難しい、という問題がある。

本発明が解決しようとする課題は、ソフトウェアの更新処理の開始を承諾するかユーザに求め、ユーザからの回答がない場合であっても、更新処理を開始すべきか否かを判定できるソフトウェア更新装置、ソフトウェア更新システム、及びソフトウェア更新方法を提供することである。

本発明は、車両の外部に設けられたサーバーから、車載制御装置のソフトウェアの更新に関する更新処理情報を取得し、更新処理の開始を承諾するかをユーザに求める承諾要求情報を出力し、承諾要求情報に対するユーザの回答である回答情報に応じて、更新処理を実行し、承諾要求情報が出力された後、所定時間以上、回答情報が入力されない場合、更新処理に要する所要時間及びソフトウェアを更新することに対する重要度のうち少なくとも何れか一方に基づき、更新処理を開始するか否かを判定することにより、上記課題を解決する。

本発明によれば、ソフトウェアの更新処理の開始を承諾するかをユーザに求め、ユーザからの回答がない場合であっても、更新処理を開始すべきか否かを判定できる。

図１は、第１実施形態に係るソフトウェア更新装置を含むソフトウェア更新システムの一例を示すブロック図である。 図２は、ＯＴＡによるソフトウェア更新のフローを説明するための説明図である。 図３は、ＥＣＵのメモリ構成に応じた、ＯＴＡによるソフトウェア更新を説明するための説明図である。 図４は、更新処理開始の承諾をユーザに求める際に車載ＨＭＩに表示される画面の一例である。 図５は、図１に示すソフトウェア更新装置１０のコントローラ４０が有する機能ブロックの一例である。 図６は、第１実施形態に係るソフトウェア更新方法のフローチャートである。 図７は、第２実施形態に係るソフトウェア更新方法のフローチャートである。 図８は、第３実施形態に係るソフトウェア更新方法のフローチャートである。

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

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

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

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

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

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

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

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

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

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

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

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

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

制御装置２３は、更新用データのデータサイズに基づき、更新処理見積り時間を算出する。後述するように、更新対象ＥＣＵで更新処理が実行されている間（更新対象ＥＣＵが旧プログラムでの動作を停止してから、新プログラムで正常起動するまでの期間を含む）では、更新対象ＥＣＵはソフトウェアの機能を実行できない。このため、更新処理見積り時間は、車両１が備える機能を使用できない時間として、ダウンタイムとも称される。

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

また制御装置２３は、更新対象ＥＣＵの種別に基づき、更新の重要度を算出する。更新の重要度とは、車両１の走行及び車両１のセキュリティのうち少なくとも何れか一つの指標に基づく重要度である。車両１の走行の指標に基づく重要度としては、ＡＳＩＬ（Automotive Safety Integrity Level）が挙げられる。ＡＳＩＬとは、車両１の機能安全について規格されたＩＥＣ６１５０８／ＩＳＯ２６２６に規定されている、自動車の安全要求と安全対策を指定する指標である。ＡＳＩＬには４段階の安全性レベルが規定されており、安全性の基準が高い順に、ＡＳＩＬ－Ｄ、ＡＳＩＬ－Ｃ、ＡＳＩＬ－Ｂ、ＡＳＩＬ－Ａと定められている。車両１に搭載される一部又は全部のＥＣＵには、予めＡＳＩＬのランクが付されている。また車両１のセキュリティの指標に基づく重要度としては、セキュリティパッチの緊急度（優先度）が挙げられる。セキュリティパッチは、セキュリティ上何らかの問題を引き起す可能性がある脆弱性やセキュリティホールが見つかった場合に、それらを修正するためのファイルである。制御装置２３により算出される更新の重要度には、上述した、ＡＳＩＬのランク及びセキュリティパッチの緊急度が含まれる。なお、車両１に搭載されている一又は全部のＥＣＵに、ＡＳＩＬと同様に、規格化されたセキュリティのランクが付されている場合、制御装置２３は、更新の重要度として、規格化されたセキュリティのランクを用いてもよい。

例えば、制御装置２３は、更新用データの提供事業者から、更新用データとともに、更新の緊急度を表す情報を受信した場合、更新の緊急度を表す情報を受信しない場合に比べて、更新の重要度を高く算出する。また例えば、制御装置２３は、更新対象ＥＣＵが車両１の走行に関与するＥＣＵの場合、更新対象ＥＣＵが車両１の走行に関与しないＥＣＵの場合に比べて、更新の重要度を高く算出する。車両１の走行に関与するＥＣＵとしては、一例として、図１に示す走行系ＥＣＵ１４Ｂが挙げられる。また車両１の走行に関与しないＥＣＵとしては、一例として、図１に示すボディ系ＥＣＵ１４Ａ及びマルチメディア系ＥＣＵ１４Ｃが挙げられる。また例えば、制御装置２３は、更新対象ＥＣＵに付されたＡＳＩＬのランクが所定の基準ランクよりも高い場合、更新対象ＥＣＵに付されたＡＳＩＬのランクが所定の基準ランクよりも低い場合に比べて、更新の重要度を高く算出する。なお、更新の重要度の算出方法は一例であって、制御装置２３は、その他の算出方法を用いて更新の重要度を算出してもよい。

ユーザ端末３の構成について説明する。図１に示すように、ユーザ端末３は、端末通信装置３１と、端末ＨＭＩ（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 (17)

1. 車両に搭載される車載制御装置のソフトウェアを更新するソフトウェア更新装置であって、
   前記車両の外部に設けられたサーバーから、前記ソフトウェアの更新に関する更新処理情報を取得する情報取得部と、
   前記ソフトウェアの更新処理の開始を承諾するかユーザに求める承諾要求情報を出力する出力部と、
   前記承諾要求情報に対する前記ユーザの回答である回答情報に応じて、前記更新処理を実行する実行部と、
   前記承諾要求情報が出力された後、所定時間以上、前記回答情報が入力されない場合、前記更新処理に要する所要時間及び前記ソフトウェアの更新に対する重要度のうち少なくとも何れか一方に基づき、前記更新処理を開始するか否かを判定する開始判定部を備えるソフトウェア更新装置。
2. 請求項１に記載のソフトウェア更新装置であって、
   前記実行部は、
   前記開始判定部により前記更新処理を開始すると判定された場合、前記更新処理を実行し、
   前記開始判定部により前記更新処理を開始しないと判定された場合、前記更新処理の実行を延期するソフトウェア更新装置。
3. 請求項２に記載のソフトウェア更新装置であって、
   前記開始判定部は、
   前記所要時間が所定の第１閾値未満の場合、前記更新処理を開始すると判定し、
   前記所要時間が前記第１閾値以上の場合、前記更新処理を開始しないと判定するソフトウェア更新装置。
4. 請求項２又は３に記載のソフトウェア更新装置であって、
   前記開始判定部は、
   前記重要度が所定の第２閾値以上の場合、前記更新処理を開始すると判定し、
   前記重要度が前記第２閾値未満の場合、前記更新処理を開始しないと判定するソフトウェア更新装置。
5. 請求項２に記載のソフトウェア更新装置であって、
   前記開始判定部は、前記重要度が所定の第２閾値以上の場合、前記所要時間が所定の第１閾値未満であるか否かにかかわらず、前記更新処理を開始すると判定するソフトウェア更新装置。
6. 請求項３に記載のソフトウェア更新装置であって、
   前記開始判定部は、前記重要度に応じて、前記第１閾値を設定するソフトウェア更新装置。
7. 請求項１～６の何れかに記載のソフトウェア更新装置であって、
   前記車載制御装置は、古いバージョンの前記ソフトウェアを実現するための第１プログラムを格納する第１メモリを有し、
   前記実行部は、
   前記第１プログラムを前記第１メモリから削除した後に、前記第１メモリに、新しいバージョンの前記ソフトウェアを実現するための第２プログラムを書き込むインストール処理を実行するインストール実行部と、
   前記第１メモリに書き込まれた前記第２プログラムを読み込ませるアクティベート処理を実行するアクティベート実行部を含み、
   前記更新処理は、前記インストール処理及び前記アクティベート処理であるソフトウェア更新装置。
8. 請求項１～６の何れかに記載のソフトウェア更新装置であって、
   前記車載制御装置は、古いバージョンの前記ソフトウェアを実現するための第１プログラムを格納する第１メモリと、第２メモリを有し、
   前記実行部は、
   前記第２メモリに、新しいバージョンの前記ソフトウェアを実現するための第２プログラムを書き込むインストール実行部と、
   プログラムの読込先を、前記第１メモリから前記第２メモリに切り替えるアクティベート処理を実行するアクティベート実行部を含み、
   前記更新処理は、前記アクティベート処理であるソフトウェア更新装置。
9. 請求項１～８の何れかに記載のソフトウェア更新装置であって、
   前記情報取得部は、前記車両の起動スイッチから、前記起動スイッチのオン状態又はオフ状態を示す信号を取得し、
   前記出力部は、前記ユーザにより前記起動スイッチがオンからオフに操作された場合、前記承諾要求情報を出力するソフトウェア更新装置。
10. 請求項１～９の何れかに記載のソフトウェア更新装置であって、
    前記情報取得部は、前記車両の現在地を検出する検出装置から、前記車両の位置情報を取得し、
    前記実行部は、前記回答情報及び前記車両の停車地点に応じて、前記更新処理を実行するソフトウェア更新装置。
11. 請求項１～１０の何れかに記載のソフトウェア更新装置であって、
    前記情報取得部は、前記サーバーから、前記所要時間及び前記重要度のうち少なくとも何れか一方を取得するソフトウェア更新装置。
12. 請求項１～１１の何れかに記載のソフトウェア更新装置であって、
    前記ソフトウェアを更新するために用いるデータのサイズに基づき、前記所要時間を算出する算出部を備えるソフトウェア更新装置。
13. 請求項１～１２の何れかに記載のソフトウェア更新装置であって、
    前記車載制御装置の種別に基づき、前記重要度を算出する重要度算出部を備えるソフトウェア更新装置。
14. 請求項１３に記載のソフトウェア更新装置であって、
    前記重要度算出部は、前記車載制御装置が前記車両の走行に関与する制御装置の場合、前記車載制御装置が前記車両の走行に関与しない制御装置の場合に比べて、前記重要度を高く算出するソフトウェア更新装置。
15. 請求項１～１４の何れかに記載のソフトウェア更新装置であって、
    前記重要度は、前記車両の走行及び前記車両のセキュリティのうち少なくとも何れか一つの指標に基づく重要度であるソフトウェア更新装置。
16. 請求項１～１５の何れかに記載のソフトウェア更新装置と、前記サーバーを含むソフトウェア更新システム。
17. コントローラが、車両に搭載される車載制御装置のソフトウェアを更新するソフトウェア更新方法であって、
    前記車両の外部に設けられたサーバーから、前記ソフトウェアの更新に関する更新処理情報を取得し、
    前記ソフトウェアの更新処理の開始を承諾するかユーザに求める承諾要求情報を出力し、
    前記承諾要求情報に対する前記ユーザの回答である回答情報に応じて、前記更新処理を実行し、
    前記承諾要求情報が出力された後、所定時間以上、前記回答情報が入力されない場合、前記更新処理に要する所要時間及び前記ソフトウェアの更新に対する重要度のうち少なくとも何れか一方に基づき、前記更新処理を開始するか否かを判定するソフトウェア更新方法。