JP7639795B2 - サーバ、プログラムおよびソフトウェア更新方法 - Google Patents

Description

本開示は、サーバ、プログラムおよびソフトウェア更新方法に関する。

車両の制御装置（ＥＣＵ：Electronic Control Unit）に格納されたソフトウェア（車両の制御プログラム）を無線通信により更新するＯＴＡ（Over The Air）技術の研究開発が進められている。たとえば特開２０１７－１４９３２３号公報（特許文献１）は、ユーザの利便性を損なうことなく安全にソフトウェアを更新できる車両制御システムを開示する。携帯機は、車両の電子キーの所在位置が車内であると判定された場合に、更新用ソフトウェアのダウンロードを要求する信号をサーバに送信する。ＥＣＵは、サーバから送信された更新用ソフトウェアを携帯機を経由してダウンロードしてソフトウェアを更新する。

特開２０１７－１４９３２３号公報

パーソナルコンピュータ、スマートホン等の電気機器のソフトウェアを更新する場合、ユーザの許諾を条件とすることが一般的である。ＥＣＵのソフトウェアの更新においても同様に、事前にユーザの許諾を取得することが考えられる。複数のソフトウェアを更新する場合にはソフトウェアごとにユーザの許諾が取得され得る。

本発明者らは、ユーザの許諾を取得した後に実行されるソフトウェアの更新処理の途中でエラーが発生し得る点に着目した。エラーが発生した場合、ユーザの許諾を再度要求するかどうかが課題となり得る。毎回ユーザの許諾を再度要求すると、ユーザにとっては許諾作業が煩雑になり得る。一方、ユーザの許諾を一律に不要とすると、ソフトウェアの更新処理にユーザの意思が適切に反映されない可能性がある。

本開示は上記課題を解決するためになされたものであり、本開示の目的は、ソフトウェアの更新において、ユーザの意思を適切に反映しつつユーザの利便性を高めることである。

（１）本開示の一態様に係るサーバは、車両の制御装置のソフトウェアを無線通信により更新する。サーバは、ソフトウェアの更新に関するユーザの許諾を得るための処理を実行するプロセッサと、許諾を得るための要求を車両またはユーザ端末に向けて出力するインターフェイスとを備える。プロセッサは、第１および第２のソフトウェアの更新に関する許諾が得られた場合、第１および第２のソフトウェアの更新処理の開始を指令する。プロセッサは、第１のソフトウェアの更新処理においてエラーが発生した場合、第１および第２のソフトウェアの更新処理の再実行に先立ち、第１のソフトウェアについては、許諾を再度要求し、第２のソフトウェアについては、第１のソフトウェアと第２のソフトウェアとの予め定められた関連性に基づいて、許諾を選択的に要求する。

（２）第１のソフトウェアと第２のソフトウェアとが互いに関連付けられている場合、プロセッサは、第２のソフトウェアについて、許諾を再度要求することなく更新処理を再実行する。

（３）プロセッサは、エラーが予め分類された簡易なエラーである場合には、第１および第２のソフトウェアの両方について、許諾を再度要求することなく更新処理を再実行する。

（４）第１のソフトウェアと第２のソフトウェアとが互いに関連付けられていない場合、プロセッサは、第２のソフトウェアについても、許諾を再度要求する。

上記（１）～（４）の構成においては、第１のソフトウェアの更新処理においてエラーが発生した場合、第１のソフトウェアと第２のソフトウエアとの関連性に基づいて、ユーザの許諾を再度要求するかどうかが決定される。互いに関連付けられたソフトウェアについては１回の許諾しか要求されないので、ユーザにとっては許諾操作の手間が省け、ユーザの利便性を高めることができる。一方、互いに関連付けられていないソフトウェアについてはソフトウェアごとに再許諾が要求されるので、ユーザの意思を適切に反映させることができる。よって、上記（１）～（４）の構成によれば、ユーザの意思を適切に反映させつつユーザの利便性を高めることができる。さらに、簡易なエラーについてはソフトウェアの関連性によらずにユーザの許諾を不要とすることで、許諾操作の手間が更に省けるため、ユーザの利便性を一層高めることができる。

（５）本開示の他の一態様に係るプログラムは、車両の制御装置のソフトウェアを無線通信により更新するためにコンピュータに実行させる。プログラムは、コンピュータにより実行された場合にコンピュータに、ソフトウェアの更新に関するユーザの許諾を得るための要求を車両またはユーザ端末に向けて出力するステップと、第１および第２のソフトウェアの更新に関する許諾が得られた場合、第１および第２のソフトウェアの更新処理の開始を指令するステップとを含む。出力するステップは、第１のソフトウェアの更新処理においてエラーが発生した場合、第１および第２のソフトウェアの更新処理の再実行に先立ち、第１のソフトウェアについては、許諾を再度要求し、第２のソフトウェアについては、第１のソフトウェアと第２のソフトウェアとの予め定められた関連性に基づいて、許諾を選択的に要求するステップを含む。

（６）本開示の更に他の一態様に係るソフトウェア更新方法は、車両の制御装置のソフトウェアを無線通信により更新する。ソフトウェア更新方法は、ソフトウェアの更新に関するユーザの許諾を得るための要求を車両またはユーザ端末に向けて出力するステップと、第１および第２のソフトウェアの更新に関する許諾が得られた場合、第１および第２のソフトウェアの更新処理の開始を指令するステップとを含む。出力するステップは、第１のソフトウェアの更新処理においてエラーが発生した場合、第１および第２のソフトウェアの更新処理の再実行に先立ち、第１のソフトウェアについては、許諾を再度要求し、第２のソフトウェアについては、第１のソフトウェアと第２のソフトウェアとの予め定められた関連性に基づいて、許諾を選択的に要求するステップを含む。

上記（５）のプログラムおよび上記（６）の方法によれば、上記（１）の構成と同様に、ユーザの意思を適切に反映させつつユーザの利便性を高めることができる。

本開示によれば、ソフトウェアの更新において、ユーザの意思を適切に反映しつつユーザの利便性を高めることができる。

本開示の実施の形態に係る情報処理システムの概略構成を示す図である。 ＯＴＡセンタの典型的な構成例を示すブロック図である。 車両の典型的な構成例を示すブロック図である。 ユーザ端末の典型的な構成例を示すブロック図である。 ソフトウェアの関連付けを説明するための図である。 ソフトウェアの更新に関する全体の処理手順全体を示すフローチャートである。 再更新処理の処理手順の第１例を示すフローチャートである。 再更新処理の処理手順の第２例を示すフローチャートである。

以下、本開示の実施の形態について、図面を参照しながら詳細に説明する。なお、図中同一または相当部分には同一符号を付して、その説明は繰り返さない。

［実施の形態］
＜システム構成＞
図１は、本開示の実施の形態に係る情報処理システムの概略構成を示す図である。情報処理システム１００は、ＯＴＡセンタ１と、車両２と、ユーザ端末３（ＵＥ：User Equipment）とを備える。ＯＴＡセンタ１は、ネットワークＮＷを介して車両２およびユーザ端末３と互いに通信可能に接続されている。

ＯＴＡセンタ１は、車両２に搭載されたＥＣＵ（図３参照）のソフトウェアを提供するサーバである。ＯＴＡセンタ１は、たとえば、車両本体（ＶＰ：Vehicle Platform）を製造する車両メーカにより管理される。ＯＴＡセンタ１の構成については図２にて説明する。

車両２は、ユーザにより管理される。ユーザは、典型的には個人であるが、たとえば車両２を用いた事業を行う法人（交通事業者など）であってもよい。車両２は自動運転車両であってもよい。この場合、ＯＴＡセンタ１は、車両メーカに代えてまたは加えて、ＶＰに搭載される自動運転システム（ＡＤＳ：Autonomous Driving System）（図３参照）の製造メーカにより管理されてもよい。ただし、車両２は、自動運転に対応していない、手動運転のみが可能な車両であってもよい。車両２の構成については図３にて説明する。

ユーザ端末３は、車両２のユーザにより操作される端末である。ユーザ端末３は、モバイル端末であってもよいし、固定端末であってもよい。モバイル端末は、たとえば、スマートホン、タブレット、ノートブックＰＣ（Personal Computer）、ウェアラブルデバイス（スマートウォッチなど）を含む。固定端末は、たとえばデスクトップＰＣを含む。ユーザ端末３の構成については図４にて説明する。

なお、図１には紙面の都合上、１台の車両２のみが図示されているが、車両２の台数は任意である。通常、情報処理システム１００は多数の車両２を含む。ユーザ端末３についても同様である。

図２は、ＯＴＡセンタ１の典型的な構成例を示すブロック図である。ＯＴＡセンタ１は、サーバ１１と、入力装置１２と、ディスプレイ１３と、通信装置１４とを含む。サーバ１１は、プロセッサ１１１と、メモリ１１２と、ストレージ１１３と、ネットワークインターフェイス１１４とを含む。ＯＴＡセンタ１の構成要素は通信バスにより互いに接続されている。

ストレージ１１３は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリなどの書き換え可能な不揮発性メモリである。ストレージ１１３には、ＯＳ（Operating System）を含むシステムプログラム５１と、制御演算に必要なコンピュータ読み取り可能なコードを含む制御プログラム５２と、車両２の制御プログラムを更新するための更新プログラム５３と、更新プログラム５３のダウンロード、インストール等に関するユーザの許諾を得るための使用許諾情報５４（後述）とが格納されている。プロセッサ１１１は、たとえば、ＣＰＵ（Central Processing Unit）またはＭＰＵ（Micro-Processing Unit）である。プロセッサ１１１は、システムプログラム５１および制御プログラム５２を読み出してメモリ１１２に展開して実行することで様々な処理を実現する。ネットワークインターフェイス１１４は、サーバ１１と他の機器（車両２、ユーザ端末３など）との間の通信装置１４を介したデータ通信を制御する。詳細は後述するが、ソフトウェアの更新の許諾を得るための要求もネットワークインターフェイス１１４から車両２および／またはユーザ端末３に向けて出力される。

入力装置１２は、キーボード、マウスなどであって、サーバ１１の操作者の入力を受け付ける。ディスプレイ１３は、サーバ１１の操作者に対して各種情報を表示する。

なお、図２にはサーバ１１が１つのプロセッサ１１１を含む例を示すが、サーバ１１が複数のプロセッサを含んでもよい。すなわち、サーバ１１は１以上のプロセッサを含む。メモリ１１２およびストレージ１１３についても同様である。

本明細書において、「プロセッサ」は、ストアードプログラム方式で処理を実行する狭義のプロセッサに限られず、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）などのハードワイヤード回路を含み得る。そのため、「プロセッサ」との用語は、コンピュータ読み取り可能なコードおよび／またはハードワイヤード回路によって予め処理が定義されている、処理回路（processing circuitry）と読み替えることもできる。

図３は、車両２の典型的な構成例を示すブロック図である。車両２は、セントラルＥＣＵ２１と、複数の個別（discrete）ＥＣＵ２２と、先進運転支援システム（ＡＤＡＳ：Advanced Driver-Assistance Systems）２３と、ＡＤＳ２４と、センサ群２５と、入力装置２６と、ＭＩＤ２７と、ＤＣＭ（Data Communication Module）２８とを含む。個別ＥＣＵ２２とは、機能ごとに分割されたＥＣＵであって、たとえばブレーキＥＣＵ、ステアリングＥＣＵ、モータジェネレータＥＣＵ、ボディＥＣＵなどである。個別ＥＣＵ２２は、ＡＤＡＳ２３および／またはＡＤＳ２４の機能を実現するためのソフトウェアが格納されたコントローラであってもよい。車両２の構成要素は、ＣＡＮ（Controller Area Network）、車載イーサネット（Ethernet）（登録商標）などの有線の車載ネットワークにより互いに接続されている。

セントラルＥＣＵ２１および個別ＥＣＵ２２の基本的な構成は、サーバ１１の構成と同様である。個別ＥＣＵ２２のストレージ２２３には、個別ＥＣＵ２２のプロセッサ２２１により実行されるソフトウェア（システムプログラム７１および制御プログラム７２）が格納されている。個別ＥＣＵ２２は、センサ群２５などからの信号に応じて車両２が所望の状態となるように、個別ＥＣＵ２２に対応するシステムを制御する。ここでのシステムは、いずれも図示しないが、ブレーキシステム、ステアリングシステム、パワートレーンシステム、ボディシステムなどを含み得る。

セントラルＥＣＵ２１のプロセッサ２１１は、個別ＥＣＵ２２のストレージ２２３に格納されたソフトウェアの更新処理を制御する。セントラルＥＣＵ２１は、ＯＴＡセンタ１からＤＣＭ２８経由でソフトウェアを受信（ダウンロード）し、ダウンロードしたソフトウェアを適切なタイミングで個別ＥＣＵ２２のストレージ２２３に格納（インストール）する。そして、セントラルＥＣＵ２１は、インストールされたソフトウェアを適切なタイミングで有効化（アクティベート）する。

ＡＤＡＳ２３は、たとえば、追従走行（ＡＣＣ：Adaptive Cruise Control）と、自動速度リミッタ（ＡＳＬ：Auto Speed Limiter）と、車線維持支援（ＬＫＡ：Lane Keeping Assist）と、衝突被害軽減ブレーキ（ＰＣＳ：Pre-Crash Safety）と、車線逸脱警報（ＬＤＡ：Lane Departure Alert）とを含む。ＡＤＳ２４は、車両２の自動運転を実行可能に構成されている。

センサ群２５は、車両２の外部状況を検出するように構成されたセンサを含む。センサ群２５は、さらに、車両２の走行状態に応じた情報ならびに操舵操作、アクセル操作およびブレーキ操作を検出するように構成されたセンサ（いずれも図示せず）を含む。具体的には、センサ群２５は、たとえば、カメラ２５１（図５参照）、レーダ、ライダ（ＬＩＤＡＲ：Laser Imaging Detection and Ranging）、車速センサ、加速度センサ、ヨーレートセンサ、ステアリングセンサ（いずれも図示せず）を含み得る。

入力装置２６は、たとえばマルチインフォメーションディスプレイ（ＭＩＤ：Multi Information Display）に設けられたタッチパネルである。入力装置２６は、物理的なスイッチまたはボタンであってもよい。ＭＩＤ２７は、たとえば、地図情報、車両管理情報等が表示されるタッチパネルディスプレイである。図示しないインストルメントパネルもＨＭＩ（Human Machine Interface）として使用される。ＤＣＭ２８は車載通信モジュールである。ＤＣＭ２８は、セントラルＥＣＵ２１とサーバ１１との双方向のデータ通信が可能に構成されている。

図４は、ユーザ端末３の典型的な構成例を示すブロック図である。ユーザ端末３は、演算処理装置３１と、入力装置３２と、ディスプレイ３３と、通信装置３４とを含む。入力装置３２とディスプレイ３３とは、たとえばタッチパネルディスプレイとして一体的に構成される。しかし、入力装置３２が入力専用機器（キーボード、マウスなど）であってもよく、ディスプレイ３３が据え置き型モニタであってもよい。ユーザ端末３の他の構成は、サーバ１１の構成（図２参照）と同様である。

＜ユーザ許諾＞
ＯＴＡセンタ１は、複数の個別ＥＣＵ２２のうちのいずれかのソフトウェアを更新する場合、ソフトウェアの更新処理の実行に先立ち、更新の許諾をユーザに要求する。２以上のソフトウェアを更新する場合、ソフトウェアごとに許諾がユーザに要求され得る。要求を受けたユーザがＭＩＤ２７またはユーザ端末３を操作して更新を許諾すると、ＯＴＡセンタ１は、ユーザから許諾を取得したソフトウェアについてソフトウェアの更新処理を実行する。

ソフトウェアの更新処理の途中でエラーが発生し得る。エラーが発生した場合、ユーザに許諾を再度要求するかどうかが課題となり得る。特に、多数のソフトウェアを更新するために多数の許諾を要求した場合、多数回の許諾操作はユーザにとって煩雑になり得る。その一方で、ユーザの許諾を一律に不要とすると、ユーザの意思が適切に反映されない可能性がある。

そこで、ＯＴＡセンタ１は、複数のソフトウェアの更新に際して更新処理の途中でエラーが発生した場合に、ユーザに許諾を再度要求するかどうかを複数のソフトウェア間の関連性に基づいて決定する。本実施の形態において、互いに関連し合うソフトウェアは事前に関連付けられている。以下、ソフトウェアの関連付けについて説明する。

＜ソフトウェアの関連付け＞
図５は、ソフトウェアの関連付けを説明するための概念図である。ここでは３つの個別ＥＣＵ２２のソフトウェアが更新される状況を例に説明する。図５に示すように、３つのソフトウェアとは、ＡＤＳ２４を制御するためのＡＤＳソフトウェア４１と、センサ群２５に含まれるカメラ（図示せず）を制御するためのカメラソフトウェア４２と、ＭＩＤ２７を制御するためのＭＩＤソフトウェア４３とである。

カメラ２５１により撮影された車両２の外部の状況がＡＤＳ２４による自動運転に用いられる。この例では、カメラソフトウェア４２の更新内容は、ＡＤＳ２４による自動運転に関連するものであるとする。したがって、ＡＤＳソフトウェア４１とカメラソフトウェア４２とは互いに関連付けられている。一方、ＡＤＳソフトウェア４１の更新内容は、ＭＩＤソフトウェア４３の更新内容とは直接的には関連し合わないとする。したがって、ＡＤＳソフトウェア４１とＭＩＤソフトウェア４３とは互いに関連付けられていない。同様に、カメラソフトウェア４２とＭＩＤソフトウェア４３とは互いに関連付けられていない。

複数のソフトウェアの各々には識別番号（プロダクトＩＤなどの品番）が割り当てられている。この識別番号を用いて２以上のソフトウェアを互いに関連付けてもよい。たとえば以下の２通りの手法を採用し得る。

第１に、ＯＴＡセンタ１の管理者（ソフトウェアの開発企業などであってもよい）は、更新対象の複数のソフトウェアの各々が自身に関連付けられた他のソフトウェアの識別番号を有するように、各ソフトウェアに情報を予め登録してもよい。図５の例では、ＡＤＳソフトウェア４１およびカメラソフトウェア４２の各々には識別番号が割り当てられている。その上で、ＡＤＳソフトウェア４１は、カメラソフトウェア４２の識別番号を有している。カメラソフトウェア４２は、ＡＤＳソフトウェア４１の識別番号を有している。ＯＴＡセンタ１は、ＡＤＳソフトウェア４１とカメラソフトウェア４２とが互いの識別番号を有していることを読み取ることで、両者が関連付けられていると判断できる。

第２に、ＯＴＡセンタ１の管理者は、更新対象の複数のソフトウェアが同一のセット（グループ）に属するとのアセンブリ情報を予め生成してもよい。この例では、アセンブリ情報は、ＡＤＳソフトウェア４１の識別番号と、カメラソフトウェア４２の識別番号とを含む。ＯＴＡセンタ１は、アセンブリ情報を参照することで、ＡＤＳソフトウェア４１とカメラソフトウェア４２とが互いに関連付けられていると判断できる。

＜処理フロー＞
図６は、ソフトウェアの更新に関する全体の処理手順全体を示すフローチャートである。このフローチャートに含まれるステップは、予め定められた条件成立時（たとえば所定の周期ごと）に実行される。各ステップは、ＯＴＡセンタ１（サーバ１１のプロセッサ１１１）によるソフトウェア処理により実現されるが、ＯＴＡセンタ１１内に配置されたハードウェア（電気回路）により実現されてもよい。以下、ステップをＳと略す。ここでは複数のソフトウェアの更新に際して複数の許諾がユーザに要求されている状況を想定する。

Ｓ１において、ＯＴＡセンタ１は、全てのソフトウェアについて更新の許諾をユーザから取得したかどうかを判定する。全てのソフトウェアについて更新の許諾を取得した場合（Ｓ１においてＹＥＳ）、ＯＴＡセンタ１は、全てのソフトウェアの更新処理を開始する（Ｓ２）。全てのソフトウェアの更新処理が正常に終了した場合（Ｓ３においてＹＥＳ）、ＯＴＡセンタ１は、一連の処理を終了する。これに対し、少なくとも一部のソフトウェアの更新処理においてエラーが発生すると（Ｓ３においてＮＯ）、ＯＴＡセンタ１は、再更新処理を実行する（Ｓ４）。

≪第１例≫
図７は、再更新処理（図６におけるＳ４の処理）の処理手順の第１例を示すフローチャートである。Ｓ４１１において、ＯＴＡセンタ１は、更新処理においてエラーが発生したソフトウェア（以下「更新失敗ソフトウェア」と記載する）を特定する。

Ｓ４１２において、ＯＴＡセンタ１は、更新対象の複数のソフトウェア（更新失敗ソフトウェアを除く）ごとに、当該ソフトウェア（以下「他のソフトウェア」と記載する）が更新失敗ソフトウェアに関連付けられているかどうかを判定する。ソフトウェア間の関連付けの手法については図５にて説明したため、説明は繰り返さない。なお、更新失敗ソフトウェアは、本開示に係る「第１のソフトウェア」に相当する。他のソフトウェアは、本開示に係る「第２のソフトウェア」に相当する。

他のソフトウェアが更新失敗ソフトウェアに関連付けられている場合（Ｓ４１２においてＹＥＳ）、ＯＴＡセンタ１は、処理をＳ４１３に進め、更新失敗ソフトウェアの更新（図５の例では、たとえばＡＤＳソフトウェア４１）に関する許諾をユーザに再度要求する。一方、ＯＴＡセンタ１は、他のソフトウェア（たとえばカメラソフトウェア４２）の更新については許諾をユーザに要求しない（Ｓ４１４）。なお、Ｓ４１３，Ｓ４１４の処理の順序は入れ替え可能である。

これに対し、他のソフトウェアが更新失敗ソフトウェアに関連付けられていない場合（Ｓ４１２においてＮＯ）、ＯＴＡセンタ１は、処理をＳ４１５に進め、更新失敗ソフトウェアの更新（たとえばＡＤＳソフトウェア４１）に関する許諾をユーザに再度要求する。さらに、ＯＴＡセンタ１は、他のソフトウェア（たとえばＭＩＤソフトウェア４３）の更新についても許諾をユーザに再度要求する（Ｓ４１６）。Ｓ４１５，Ｓ４１６の処理の順序も入れ替え可能である。

Ｓ４１７において、ＯＴＡセンタ１は、必要な許諾をユーザから再度取得したかどうかを判定する。許諾を再度取得した場合（Ｓ４１７においてＹＥＳ）、ＯＴＡセンタ１は、許諾を取得したソフトウェアの更新処理を再度実行する（Ｓ４１８）。その後、処理は図６のＳ３に戻される。一方、今回は許諾を取得できなかった場合（Ｓ４１７においてＮＯ）、ＯＴＡセンタ１は、更新処理を再度実行することなく処理を終了する。

以上のように、本実施の形態においては、ソフトウェアの更新処理の途中でエラーが発生した場合に、ソフトウエア間の関連性に基づいて、ユーザの再許諾が選択的に要求される。互いに関連付けられたソフトウェアについては１回の再許諾しか要求されないので、ユーザにとっては許諾操作の手間が省け、ユーザの利便性を高めることができる。一方、互いに関連付けられていないソフトウェアについてはソフトウェアごとに再許諾が要求されるので、ユーザの意思を適切に反映させることができる。よって、本実施の形態によれば、ユーザの意思を適切に反映させつつユーザの利便性を高めることができる。

≪第２例≫
図８は、再更新処理の処理手順の第２例を示すフローチャートである。このフローチャートは、Ｓ４３０～Ｓ４３３の処理を更に含む点において、第１例のフローチャート（図７参照）と異なる。それ以外のＳ４２１～Ｓ４２８の処理は、第１例におけるＳ４１１～Ｓ４１８の処理と同様であるため、詳細な説明は繰り返さない。

更新失敗ソフトウェアを特定したＯＴＡセンタ１は、発生したエラーが簡易エラーであるかどうかを判定する。簡易エラーは、たとえば、不安定な通信接続のために発生したエラー、車両２の内部（たとえばＥＣＵ間）でのソフトウェアの転送が電源障害などにより中断したことに伴うエラーなどを含み得る。簡易エラーは、フェータルエラー（車両２のシステム再起動が要求されるエラーなど）とは区別される。発生したエラーが簡易エラーでない場合（Ｓ４３０においてＮＯ）、ＯＴＡセンタ１は、処理をＳ４２２に進める。Ｓ４２２以降の処理は、図７にて説明した処理と同様である。

これに対し、発生したエラーが簡易エラーである場合（Ｓ４３０においてＹＥＳ）、ＯＴＡセンタ１は、処理をＳ４３１に進め、更新失敗ソフトウェアの更新に関する再許諾をユーザに要求しない。また、ＯＴＡセンタ１は、他のソフトウェアの更新についても、そのソフトウエアが更新処理ソフトウェアと関連付けられているか否かに拘わらず、再許諾をユーザに要求しない（Ｓ４３２）。そして、ＯＴＡセンタ１は、全てのソフトウェアの更新処理を再度実行する（Ｓ４３３）。その後、処理は図６のＳ３に戻される。

以上のように、発生したエラーが簡易エラーに留まる場合には、ソフトウェア間の関連性によらずにユーザの再許諾を不要とする。これにより、許諾操作の手間が更に省けるため、ユーザの利便性を一層高めることができる。

今回開示された実施の形態は、すべての点で例示であって制限的なものではないと考えられるべきである。本開示の範囲は、上記した実施の形態の説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ ＯＴＡセンタ、１１ サーバ、１１１ プロセッサ、１１２ メモリ、１１３ ストレージ、１１４ ネットワークインターフェイス、１２ 入力装置、１３ ディスプレイ、１４ 通信装置、２ 車両、２１ セントラルＥＣＵ、２２ 個別ＥＣＵ、２１１，２２１ プロセッサ、２１２，２２２ メモリ、２１３，２２３ ストレージ、２１４，２２４ ネットワークインターフェイス、２３ ＡＤＡＳ、２４ ＡＤＳ、２５ センサ群、２６ 入力装置、２７ ＭＩＤ、３ ユーザ端末、３１ 演算処理装置、３１１ プロセッサ、３１２ メモリ、３１３ ストレージ、３１４ ネットワークインターフェイス、３２ 入力装置、３３ ディスプレイ、３４ 通信装置、４１ ＡＤＳソフトウェア、４２ カメラソフトウェア、４３ ＭＩＤソフトウェア、５１，６１，７１ システムプログラム、５２，６２，７２ 制御プログラム、５３ 更新プログラム、５４ 使用許諾情報、８１ ヘッダ、８２ ボディ、１００ 情報処理システム。

Claims (6)

1. 車両の制御装置のソフトウェアを無線通信により更新するサーバであって、
   前記ソフトウェアの更新に関するユーザの許諾を得るための処理を実行するプロセッサと、
   前記許諾を得るための要求を前記車両またはユーザ端末に向けて出力するインターフェイスとを備え、
   前記プロセッサは、
   第１および第２のソフトウェアの更新に関する前記許諾が得られた場合、前記第１および第２のソフトウェアの更新処理の開始を指令し、
   前記第１のソフトウェアの更新処理においてエラーが発生した場合、前記第１および第２のソフトウェアの更新処理の再実行に先立ち、
   前記第１のソフトウェアについては、前記許諾を再度要求し、
   前記第２のソフトウェアについては、前記第１のソフトウェアと前記第２のソフトウェアとの予め定められた関連性に基づいて、前記許諾を選択的に要求する、サーバ。
2. 前記第１のソフトウェアと前記第２のソフトウェアとが互いに関連付けられている場合、前記プロセッサは、前記第２のソフトウェアについて、前記許諾を再度要求することなく更新処理を再実行する、請求項１に記載のサーバ。
3. 前記プロセッサは、前記エラーが予め分類された簡易なエラーである場合には、前記第１および第２のソフトウェアの両方について、前記許諾を再度要求することなく更新処理を再実行する、請求項２に記載のサーバ。
4. 前記第１のソフトウェアと前記第２のソフトウェアとが互いに関連付けられていない場合、前記プロセッサは、前記第２のソフトウェアについても、前記許諾を再度要求する、請求項１～３のいずれか１項に記載のサーバ。
5. 車両の制御装置のソフトウェアを無線通信により更新するためにコンピュータに実行させるプログラムであって、
   前記コンピュータにより実行された場合に前記コンピュータに、前記ソフトウェアの更新に関するユーザの許諾を得るための要求を前記車両またはユーザ端末に向けて出力するステップと、
   第１および第２のソフトウェアの更新に関する前記許諾が得られた場合、前記第１および第２のソフトウェアの更新処理の開始を指令するステップとを含み、
   前記出力するステップは、前記第１のソフトウェアの更新処理においてエラーが発生した場合、前記第１および第２のソフトウェアの更新処理の再実行に先立ち、
   前記第１のソフトウェアについては、前記許諾を再度要求し、
   前記第２のソフトウェアについては、前記第１のソフトウェアと前記第２のソフトウェアとの予め定められた関連性に基づいて、前記許諾を選択的に要求するステップを含む、プログラム。
6. 車両の制御装置のソフトウェアを無線通信により更新するソフトウェア更新方法であって、
   前記ソフトウェアの更新に関するユーザの許諾を得るための要求を前記車両またはユーザ端末に向けて出力するステップと、
   第１および第２のソフトウェアの更新に関する前記許諾が得られた場合、前記第１および第２のソフトウェアの更新処理の開始を指令するステップとを含み、
   前記出力するステップは、前記第１のソフトウェアの更新処理においてエラーが発生した場合、前記第１および第２のソフトウェアの更新処理の再実行に先立ち、
   前記第１のソフトウェアについては、前記許諾を再度要求し、
   前記第２のソフトウェアについては、前記第１のソフトウェアと前記第２のソフトウェアとの予め定められた関連性に基づいて、前記許諾を選択的に要求するステップを含む、ソフトウェア更新方法。
   

Images