以下、本発明の各実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。また、本明細書及び図面において用いる用語のうち、「自動運転機能」及び「運転支援機能」については、それぞれ以下に示すレベルを実現するための機能を指すものとする。
「自動運転機能」:
・車両の運転操作及び周辺監視を全て実行するレベル
・機能限界になった場合のみ、運転者が自ら運転操作を行うが、その以外の場合は、車両の運転操作及び周辺監視を全て実行するレベル
「運転支援機能」:
・運転者は安全運行の責任を持つが、操舵、制動、加速全ての運転支援を実行するレベル
・操舵、制動又は加速の運転支援を実行するが、操舵、制動、加速の全ての運転支援までは実行しないレベル
・運転者が車両の操舵・制動・加速のための運転操作を行うが、前方衝突警告などの、操舵、制動、加速以外の支援を実行するレベル
なお、ACC(Adaptive Cruise Control)、LKA(Lane Keeping Assist System)、IPA(Intelligent Parking Assist)等の機能は、「運転支援機能」に含まれるものとする。
[第1の実施形態]
<1.車両用のソフトウェア管理システムの全体構成>
はじめに、車両用のソフトウェア管理システムの全体構成について説明する。図1は、車両用のソフトウェア管理システムの全体構成の一例を示す図である。図1に示すように、車両用のソフトウェア管理システム100は、管理サーバ110と、車両120と、携帯端末140とを有する。本実施形態において、管理サーバ110と車両120とは、ネットワーク150を介して通信可能に接続される。また、管理サーバ110と携帯端末140とは、ネットワーク150を介して通信可能に接続される。
管理サーバ110には、ソフトウェア管理プログラム及びユーザ管理プログラムがインストールされており、これらのプログラムが実行されることで、管理サーバ110は、ソフトウェア管理部111及びユーザ管理部112として機能する。
ソフトウェア管理部111は、車両120に搭載された自動運転または運転支援システム132にインストールされている、自動運転機能または運転支援機能に関するソフトウェアを管理する。なお、自動運転機能または運転支援機能に関するソフトウェアは、最新バージョンのソフトウェアへの更新に際して、原則として、ユーザによる許可が必要なソフトウェアである。しかしながら、将来的には、ユーザによる許可が必要でなくなる可能性もある。そこで、以下では、自動運転機能または運転支援機能に関するソフトウェアを更新するための最新バージョンのソフトウェアには、ユーザによる許可が必要なソフトウェアと、ユーザによる許可が不要なソフトウェアとが含まれることを前提として説明を行う。
具体的には、ソフトウェア管理部111は、自動運転または運転支援システム132にインストールされているソフトウェアについて、最新バージョンのソフトウェアを新たに取得したか否かを監視する。ソフトウェア管理部111では、最新バージョンのソフトウェアを新たに取得すると、ソフトウェアDB113に格納するとともに、該最新バージョンのソフトウェアによる更新が必要と判定し、該最新バージョンのソフトウェアを車両120に送信する。これにより、自動運転または運転支援システム132にインストールされているソフトウェアが更新される。
また、ソフトウェア管理部111は、自動運転または運転支援システム132にインストールされているソフトウェアの更新状況に応じて、自動運転機能または運転支援機能の一部または全部の作動を制限すべく、車両120に対して機能制限を指示する。
更に、ソフトウェア管理部111は、自動運転または運転支援システム132にインストールされているソフトウェアについての更新状況を、ユーザ情報DB114に格納する。
ユーザ管理部112は解析手段の一例であり、ユーザ情報DB114を参照し、自動運転または運転支援システム132にインストールされているソフトウェアの更新状況をユーザごとに解析する。
車両120は、DCM(Data Communication Module)131と、自動運転システムまたは運転支援システム132とを有する。DCM131は通信装置であり、ネットワーク150を介して、管理サーバ110に接続する。
自動運転または運転支援システム132は、インストールされている、自動運転機能または運転支援機能に関するソフトウェアを実行することで、自動運転機能または運転支援機能を実現する。また、自動運転または運転支援システム132では、インストールされている自動運転機能または運転支援機能に関するソフトウェアを、管理サーバ110から送信された最新バージョンのソフトウェアを用いて更新する。更に、自動運転または運転支援システム132では、自動運転機能または運転支援機能の一部または全部の作動を、管理サーバ110からの機能制限の指示に従って制限する。
携帯端末140には、更新許可プログラムがインストールされており、当該プログラムが携帯端末140において実行されることで、携帯端末140は、更新許可部141として機能する。
更新許可部141は、管理サーバ110と通信し、ソフトウェアDB113に新たに格納された最新バージョンのソフトウェアが、ユーザによる許可が必要なソフトウェアであった場合に、ユーザによる更新許可の入力を受け付ける。管理サーバ110と車両120とが通信可能に接続されていない場合、管理サーバ110では、ソフトウェアの更新許否を携帯端末140に問い合わせる。このため、更新許可部141では、管理サーバ110から更新許否の問い合わせがあった場合に、ユーザからの更新許可の入力を受け付けて管理サーバ110に送信する。
このように、携帯端末140を介して、事前に更新許可の入力ができるようにしたことで、車両120のユーザは、車両120を運転操作するタイミングとは異なるタイミングで更新許可を入力することができる。この結果、車両120のユーザにとっては、ソフトウェアの更新が許可しやすくなる。また、車両120が管理サーバ110と通信可能に接続された場合に(例えば、IG−ON状態になった時に)、ユーザに対して更新許否の問い合わせを行うことなく、直ちに、ソフトウェアの更新を実行することができる。
<2.管理サーバのハードウェア構成>
次に、管理サーバ110のハードウェア構成について説明する。図2は、管理サーバのハードウェア構成の一例を示す図である。
図2に示すように、管理サーバ110は、CPU(Central Processing Unit)201、ROM(Read Only Memory)202、RAM(Random Access Memory)203、補助記憶部204、ユーザインタフェース部205、通信部206を備える。なお、管理サーバ110の各部は、バス207を介して相互に接続されている。
CPU201は、RAM203を作業領域として、ROM202及び補助記憶部204に格納されたプログラム(ソフトウェア管理プログラム、ユーザ管理プログラム等)を実行するコンピュータである。
ユーザインタフェース部205は、CPU201がプログラムを実行する際に必要な情報を入力したり、CPU201がプログラムを実行したことで生成された情報を出力する。
通信部206は、ネットワーク150と接続し、ネットワーク150を介して車両120のDCM131や携帯端末140との間で通信を行う。
<3.自動運転または運転支援システムの構成>
次に、車両120の自動運転または運転支援システム132のシステム構成及び該システムに含まれる自動運転用または運転支援用ECU(Electronic Control Unit)のハードウェア構成について説明する。図3(a)は、自動運転または運転支援システム132のシステム構成の一例を示す図であり、図3(b)は、当該システムに含まれる自動運転用ECUまたは運転支援用ECUのハードウェア構成を示す図である。
図3(a)に示すように、自動運転または運転支援システム132は、自動運転用または運転支援用ECU300を有する。また、自動運転スイッチ301、GPS(Global Positioning System)302、車速センサ303、ヨーレートセンサ304、カメラ305、ミリ波データ306、ライダ307を有する。更に、アクセルペダルセンサ308、ブレーキペダルセンサ309、操舵角センサ310、スロットルアクチュエータ311、ブレーキアクチュエータ312、ステアリングアクチュエータ313、表示装置314、自動運転情報DB315を有する。
自動運転用または運転支援用ECU300は、自動運転または運転支援ソフトウェア格納部322にインストールされた自動運転機能に関するソフトウェアまたは運転支援機能に関するソフトウェアを実行することで、自動運転機能または運転支援機能を実現する。自動運転用または運転支援用ECU300は、自動運転スイッチ301〜ライダ307、アクセルペダルセンサ308〜自動運転情報DB315との間で情報を送受信しながら、自動運転機能または運転支援機能を実現する。なお、自動運転用または運転支援用ECU300により実現される自動運転機能または運転支援機能の説明は、ここでは省略する。
自動運転用または運転支援用ECU300には、更にバージョン管理プログラムがインストールされている。自動運転用または運転支援用ECU300は、当該バージョン管理プログラムを実行することで、バージョン管理部321としても機能する。
バージョン管理部321は、管理サーバ110より最新バージョンのソフトウェアを受信した場合に、既にインストールされているソフトウェアを、当該受信した最新バージョンのソフトウェアを用いて更新する。また、バージョン管理部321は、管理サーバ110から機能制限の指示を受けると、最新バージョンのソフトウェアによる更新が完了するまでの間の所定のタイミングで、自動運転機能または運転支援機能の一部または全部の作動を制限する処理を開始する。所定のタイミングとは、例えば、車両120が機能制限の指示を受けた後の次のIG−ON状態のタイミングである。自動運転機能または運転支援機能の一部または全部の作動を制限する処理は、最新バージョンのソフトウェアによる更新が完了するまで継続し、更新が完了することで制限が解除される。なお、バージョン管理部321による当該機能の詳細は後述する。
図3(b)に示すように、バージョン管理部321として機能する自動運転用または運転支援用ECU300は、CPU331、RAM332、接続部333、ROM334を有する。本実施形態において、バージョン管理プログラムはROM334に格納されている。また、バージョン管理プログラムは、RAM332等を作業領域としてCPU331により実行されることで、接続部333を介して接続されたDCM131との間で情報を送受信しながら、バージョン管理部321としての機能を実現する。
なお、以下では説明の簡略化のため、車両120には運転支援システム132が搭載されているものとし、運転支援用ECU300の運転支援ソフトウェア格納部322にインストールされている運転支援機能に関するソフトウェアを更新する場合について説明する。ただし、自動運転システムが搭載されている場合(自動運転用ECUの自動運転ソフトウェア格納部にインストールされている自動運転機能に関するソフトウェアを更新する場合)も同様である。
<4.管理サーバに格納される情報>
次に、管理サーバ110のソフトウェアDB113及びユーザ情報DB114にそれぞれ格納される情報について説明する。図4は、ソフトウェアDBに格納されるソフトウェア情報及びユーザ情報DBに格納されるユーザ情報の一例を示す図である。
図4(a)に示すように、ソフトウェアDB113に格納されるソフトウェア情報400には情報の項目として、"ソフトウェアID"、"ソフトウェア名"、"作成者"、"作成日時"、"Ver"、"許可要否"が含まれる。
"ソフトウェアID"には、運転支援機能に関するソフトウェアを識別する識別子が格納される。"ソフトウェア名"には、ソフトウェアIDにより特定されるソフトウェアの名称が格納される。"作成者"には、ソフトウェアIDにより特定されるソフトウェアの作成者に関する情報が格納される。"作成日時"には、ソフトウェアIDにより特定されるソフトウェアの作成日時が格納される。
"Ver"には、ソフトウェアIDにより特定されるソフトウェアのバージョン情報が格納される。"許可要否"には、ソフトウェアIDにより特定されるソフトウェアが、更新に際して、ユーザによる許可が必要なソフトウェアであるか否かを示す情報が格納される。
図4(b)に示すように、ユーザ情報DB114に格納されるユーザ情報410には情報の項目として、"車両ID"、"車両番号漂"、"DCM"、"ユーザ属性"、"携帯端末"、"ソフトウェアの更新状況"、"機能制限"が含まれる。
"車両ID"には、車両を識別する識別子が格納される。"車両番号漂"には、車両IDにより特定される車両のナンバープレートの情報が格納される。"DCM"には、車両IDにより特定される車両に搭載されたDCMの種類が格納される。
"ユーザ属性"には、車両IDにより特定される車両を所有するユーザの属性に関する情報が格納される。"ユーザ属性"には、"名前"、"性別"、年齢"、"住所"等の小項目が含まれる。"携帯端末"には、車両IDにより特定される車両を所有するユーザが所持する携帯端末を識別するための情報が含まれる。
"ソフトウェアの更新状況"には、ソフトウェアDB113に格納されたソフトウェアについての各車両における更新状況に関する情報が格納される。更新状況に関する情報は、ソフトウェアごとに分けて管理される。このため、"ソフトウェアの更新状況"には、更に、小項目として、"S/W101"、"S/W203"、"S/W301"・・・が含まれる。
また、更新状況に関する情報には、それぞれの車両の運転支援システム132にインストールされているソフトウェアのバージョン情報と、最新のソフトウェアにより更新が完了されるまでの各状況を示す情報(未許可、許可済み、完了)が含まれる。
更新状況に関する情報が"未許可"とは、更新に際してユーザによる許可が必要なソフトウェアであるが、未だユーザにより更新が許可されていない状況にあることを示している。また、更新状況に関する情報が"許可済み"とは、更新に際してユーザによる許可が必要なソフトウェアがユーザにより更新が許可された状況にあるが、ソフトウェアの更新までは完了していない状況にあることを示している。更に、更新状況に関する情報が"完了"とは、更新に際してユーザによる許可が必要なソフトウェアについて、既にユーザにより更新が許可され、ソフトウェアの更新が完了した状況にあることを示している。なお、更新に際してユーザによる許可が不要で、既にソフトウェアの更新が完了している場合についても、更新状況に関する情報は"完了"となる。
"機能制限"には、最新バージョンのソフトウェアであって、ユーザによる許可が必要なソフトウェアがソフトウェアDB113に新たに格納され、各車両に機能制限フラグのON指示が送信された場合に、指示中であることを示す情報が格納される。機能制限フラグとは、運転支援機能の一部または全部の作動を制限することを可能にする制御フラグである。指示中であることを示す情報は、ユーザによる許可が必要なソフトウェアについて、ユーザにより更新許可が入力され、かつ、更新が完了した場合に削除される。図4(b)の例では、車両ID="C2"の車両の運転支援ソフトウェア格納部にインストールされているソフトウェアID="S/W101"のソフトウェアが最新バージョンではなく、Ver="1.3.1"への更新が必要な状況にある。しかしながら、車両ID="C2"の車両のユーザにより更新が許可されていないため、図4(b)の例では、"機能制限"には、指示中であることを示す情報が格納されている。
<5.運転支援用ECUに格納される運転支援ソフトウェア情報>
次に、運転支援用ECU300の運転支援ソフトウェア格納部322にインストールされているソフトウェアに関する情報を示す運転支援ソフトウェア情報について説明する。運転支援ソフトウェア情報は、運転支援ソフトウェア格納部322に格納されている。運転支援ソフトウェア情報は、運転支援ソフトウェア格納部322にインストールされている運転支援機能に関するソフトウェアが、管理サーバ110から送信されたソフトウェアにより更新されることで書き換えられる。また、運転支援ソフトウェア情報は、運転支援機能に関するソフトウェアにより実現される運転支援機能の一部または全部の作動が、管理サーバ110からの指示に基づいて制限された場合に書き換えられる。更には、当該制限が解除された場合にも書き換えられる。
図5は、運転支援ソフトウェア情報の一例を示す図である。このうち、図5(a)は、車両ID="C1"の車両の運転支援ソフトウェア格納部に格納された運転支援ソフトウェア情報を、図5(b)は、車両ID="C2"の車両の運転支援ソフトウェア格納部に格納された運転支援ソフトウェア情報をそれぞれ示している。更に、図5(c)は、車両ID=C3の車両の運転支援ソフトウェア格納部に格納された運転支援ソフトウェア情報を示している。
図5に示すように、各運転支援ソフトウェア情報には、情報の項目として、"ソフトウェアID"、"ソフトウェア名"、"作成者"、"作成日時"、"Ver"、"機能制限フラグ"が含まれる。
"ソフトウェアID"には、運転支援ソフトウェア格納部322にインストールされているソフトウェアを識別するための識別子が格納される。"ソフトウェア名、"作成者"、作成日時"、"Ver"には、ソフトウェアIDにより識別されるソフトウェアの名称、作成者に関する情報、作成日時、バージョン情報がそれぞれ格納される。
"機能制限フラグ"には、ソフトウェアIDにより識別されるソフトウェアについて、管理サーバ110から機能制限フラグのON指示があった場合に"ON"が格納され、機能制限が解除された場合に"OFF"が格納される。
図5(a)の例は、車両ID="C1"の車両の運転支援システム132に、ソフトウェアID="S/W101"により識別されるソフトウェアがインストールされていることを示している。また、図5(a)の例は、当該ソフトウェアがVer="1.3.1"のソフトウェアであり、最新バージョンへの更新が完了しているため、"機能制限フラグ"に"OFF"が格納されていることを示している。
図5(b)の例は、車両ID="C2"の車両の運転支援システム132に、ソフトウェアID="S/W101"、"S/W203"により識別されるソフトウェアがインストールされていることを示している。また、図5(b)の例は、ソフトウェアID="S/W101"により識別されるソフトウェアがVer="1.3.0"のソフトウェアであり、最新バージョンでないことを示している。このため、"機能制限フラグ"に"ON"が格納されている。
また、図5(b)の例は、ソフトウェアID="S/W203"により識別されるソフトウェアがVer="2.1"のソフトウェアであり、最新バージョンへの更新が完了しているため、"機能制限フラグ"に"OFF"が格納されていることを示している。
図5(c)の例は、車両ID="C3"の車両の運転支援システム132に、ソフトウェアID="S/W203"、"S/W301"により識別されるソフトウェアがインストールされていることを示している。また、図5(c)の例は、ソフトウェアID="S/W203"により識別されるソフトウェアがVer="2.0"のソフトウェアであり、最新バージョンでないことを示している。ただし、図4(b)で示したように、最新バージョンのソフトウェアについては、既に、更新が許可されており、管理サーバ110からは機能制限フラグのON指示が送信されないため、"機能制限フラグ"に"OFF"が格納されている。
また、図5(c)の例は、ソフトウェアID="S/W301"により識別されるソフトウェアが、ユーザによる許可が不要なソフトウェアであるため、"機能制限フラグ"に"ON"、"OFF"が格納されることはないことを示している。
<6.管理サーバの機能構成の詳細>
次に、管理サーバ110のソフトウェア管理部111及びユーザ管理部112の機能構成の詳細について説明する。図6は、管理サーバのソフトウェア管理部及びユーザ管理部の機能構成の一例を示す図である。
図6に示すように、ソフトウェア管理部111は、接続状態管理部601、ソフトウェア取得部602、ソフトウェア種類判定部603、機能制限フラグ制御部604、告知指示部605、更新指示部606を有する。
接続状態管理部601は、管理サーバ110による管理対象の車両が、管理サーバ110に対して、通信可能に接続された状態にあるか否かを管理する。また、接続状態管理部601は、管理サーバ110による管理対象の車両のユーザが所持する携帯端末が、管理サーバ110に対して、通信可能に接続された状態にあるか否かを管理する。
ソフトウェア取得部602は、運転支援用ECU300にインストールされているソフトウェアを更新するための最新バージョンのソフトウェアを取得し、ソフトウェアDB113に格納する。ソフトウェア取得部602は、当該最新バージョンのソフトウェアを新たに取得しソフトウェアDB113に格納した場合に、運転支援用ECU300にインストールされているソフトウェアについて更新が必要と判定する。つまり、ソフトウェア取得部602は、運転支援用ECU300にインストールされているソフトウェアについて更新の要否を判定する更新要否判定手段として機能する。
ソフトウェア種類判定部603は、ソフトウェア取得部602により新たに取得され、ソフトウェアDB113に格納された最新バージョンのソフトウェア(更新が必要と判定されたソフトウェア)が、更新に際して、ユーザによる許可が必要なソフトウェアであるか否かを判定する。
ソフトウェア種類判定部603は、ユーザによる許可が必要なソフトウェアであると判定した場合には、判定結果を、機能制限フラグ制御部604及び告知指示部605に通知する。また、ソフトウェア種類判定部603は、ユーザによる許可が不要なソフトウェアであると判定した場合には、判定結果を、更新指示部606に通知する。
機能制限フラグ制御部604は制御手段の一例である。機能制限フラグ制御部604は、ソフトウェア種類判定部603から判定結果を受信した場合に、対象車両に対して、機能制限フラグのON指示を送信する。機能制限フラグ制御部604は、機能制限フラグのON指示を送信した場合に、ユーザ情報410の"機能制限"に指示中であることを示す情報を格納する。
告知指示部605は、ソフトウェア種類判定部603から判定結果を受信した場合に、対象車両に対して、ユーザによる許可が必要なソフトウェアについての更新の許可要請を行うよう指示する。また、告知指示部605は、更新の許可要請の指示に応じて、対象車両のユーザにより更新許可の入力が行われたことを示す情報が対象車両より送信されたか否かを判定し、送信されたと判定した場合に、更新指示部606に更新が許可されたことを通知する。
更新指示部606は受信手段の一例である。更新指示部606は、ソフトウェア種類判定部603から判定結果を受信した場合、または、告知指示部605から更新が許可された旨の通知を受信した場合に、対象車両に対して、最新バージョンのソフトウェアを送信し、更新を指示する。更新指示部606による更新の指示に応じて、対象車両より、ソフトウェアの更新完了通知を受信した場合、更新指示部606では、ユーザ情報DB114のユーザ情報410の"ソフトウェアの更新状況"を書き換え、"機能制限"に格納された情報を削除する。
<7.運転支援用ECUの機能構成の詳細>
次に、運転支援用ECU300のバージョン管理部321の機能構成の詳細について説明する。図7は、運転支援用ECUのバージョン管理部の機能構成の一例を示す図である。
図7に示すように、バージョン管理部321は、告知部701、インストール実行部702、制限部703を有する。
告知部701は、管理サーバ110の告知指示部605より、更新の許可要請の指示を受信した場合に、車両120のユーザに対して、最新バージョンのソフトウェアによる更新許否を問い合わせる許可要請画面を表示する。また、告知部701は、許可要請画面を表示することで、ユーザからの更新許可の入力を受け付ける。告知部701では、ユーザから、更新許可の入力を受け付けた場合に更新が許可されたと判定し、管理サーバ110に対して、更新許可の入力が行われたことを示す情報を送信する。
インストール実行部702は更新手段の一例である。インストール実行部702は、管理サーバ110より、最新バージョンのソフトウェアを受信した場合に、最新バージョンのソフトウェアを用いて、運転支援ソフトウェア格納部322に既にインストールされているソフトウェアを更新する。また、インストール実行部702は、最新バージョンのソフトウェアによる更新が完了した場合に、更新完了通知を、管理サーバ110に送信するとともに、制限部703に送信する。
制限部703は制限手段の一例である。制限部703は、管理サーバ110より、機能制限フラグのON指示を受信した場合に、運転支援ソフトウェア格納部322に格納された運転支援ソフトウェア情報510の"機能制限フラグ"に"ON"を格納する。
また、制限部703は、車両がIG−ON状態になった時に、運転支援ソフトウェア格納部322に格納された運転支援ソフトウェア情報510を参照し、機能制限フラグがON状態になっているか否かを判定する。制限部703は、機能制限フラグがON状態になっていると判定した場合に、当該ソフトウェアに関連する運転支援機能の一部または全部の作動を制限する(機能制限を実施する)。
また、制限部703は、インストール実行部702より、更新完了通知を受信した場合に、運転支援ソフトウェア格納部322に格納された運転支援ソフトウェア情報510の"機能制限フラグ"にOFFを格納する。また、更新完了通知を受信した時点で既に機能制限を実施している場合にあっては、制限部703は、機能制限を解除する。
<8.管理サーバにおいて実行される処理の説明>
次に、管理サーバ110において実行される処理(対象車両のIG−ON状態管理処理、対象携帯端末の接続状態管理処理、バージョン管理処理)について説明する。
(1)対象車両のIG−ON状態管理処理及び対象携帯端末の接続状態管理処理
図8(a)、(b)は、管理サーバにおける対象車両のIG−ON状態管理処理及び対象携帯端末の接続状態管理処理の流れをそれぞれ示すフローチャートである。
図8(a)に示すように、ステップS801において、接続状態管理部601は、対象車両のIG−ON信号を受信したか否かを判定する。ステップS801において、対象車両のIG−ON信号を受信していないと判定した場合には、ステップS804に進む。
一方、ステップS801において、対象車両のIG−ON信号を受信したと判定した場合には、ステップS802に進む。ステップS802において、接続状態管理部601は、対象車両がIG−ON状態であると判定する。
ステップS803において、接続状態管理部601は、対象車両のIG−OFF信号を受信したか否かを判定する。ステップS803において、対象車両のIG−OFF信号を受信していないと判定した場合には、ステップS802に戻る。
一方、ステップS803において、対象車両のIG−OFF信号を受信したと判定した場合には、ステップS804に進む。ステップS804において、接続状態管理部601は、対象車両がIG−OFF状態であると判定する。
ステップS805において、接続状態管理部601は、対象車両が管理対象外となったか否かを判定する。管理対象外になっていないと判定した場合には、ステップS801に戻る。一方、管理対象外になったと判定した場合には、当該対象車両についてのIG−ON状態管理処理を終了する。
図8(b)に示すように、ステップS811において、接続状態管理部601は、対象携帯端末の接続要求を受信したか否かを判定する。ステップS811において、対象携帯端末の接続要求を受信していないと判定した場合には、ステップS814に進む。
一方、ステップS811において、対象携帯端末の接続要求を受信したと判定した場合には、ステップS812に進む。ステップS812において、接続状態管理部601は、対象携帯端末が接続状態であると判定する。
ステップS813において、接続状態管理部601は、対象携帯端末の切断要求を受信したか否かを判定する。ステップS813において、対象携帯端末の切断要求を受信していないと判定した場合には、ステップS812に戻る。
一方、ステップS813において、対象携帯端末の切断要求を受信したと判定した場合には、ステップS814に進む。ステップS814において、接続状態管理部601は、対象携帯端末が非接続状態であると判定する。
ステップS815において、接続状態管理部601は、対象携帯端末が管理対象外になったか否かを判定する。管理対象外になっていないと判定した場合には、ステップS811に戻る。一方、管理対象外になったと判定した場合には、当該対象携帯端末についての接続状態管理処理を終了する。
(2)バージョン管理処理の流れ
図9及び図10は、管理サーバにおけるバージョン管理処理の流れを示すフローチャートである。図9に示すように、ステップS901において、ソフトウェア取得部602は、最新バージョンのソフトウェアを新たに取得し、ソフトウェアDB113に格納したか否かを判定する。
ステップS901において、最新バージョンのソフトウェアを新たに取得していないと判定した場合には、ソフトウェア取得部602では、最新バージョンのソフトウェアへの更新が不要と判定し、ステップS902に進む。ステップS902において、接続状態管理部601は、対象車両からIG−ON信号を受信したか否かを判定する。ステップS902においてIG−ON信号を受信していないと判定した場合には、ステップS915に進む。
一方、ステップS902において、IG−ON信号を受信したと判定した場合には、ステップS903に進む。ステップS903において、更新指示部606は、対象車両のユーザにより既に更新が許可されたソフトウェアがあるか否かを判定する。
ステップS903において、既に更新が許可されたソフトウェアがあると判定した場合には、ステップS904に進む。ステップS904において、更新指示部606は、既に更新が許可されたソフトウェアを対象車両に送信し、ユーザ情報DB114のユーザ情報410の"ソフトウェアの更新状況"を書き換えた後、ステップS905に進む。一方、ステップS903において、更新が許可されたソフトウェアがないと判定した場合には、直接、ステップS905に進む。
ステップS905において、ソフトウェア種類判定部603は、対象車両の運転支援ソフトウェア格納部322にインストールされている各ソフトウェアのバージョン情報を、対象車両より取得する。
ステップS906において、ソフトウェア種類判定部603は、ステップS905において取得したバージョン情報に基づいて、対象車両の運転支援ソフトウェア格納部322にインストールされている各ソフトウェアが、最新バージョンであるか否かを判定する。
ステップS906において、最新バージョンであると判定した場合には、ステップS915に進む。一方、最新バージョンでないと判定した場合には、ステップS907に進む。
ステップS907において、ソフトウェア種類判定部603は、最新バージョンでないと判定したソフトウェアの中に、更新に際してユーザによる許可が不要なソフトウェアがあるか否かを判定する。
ステップS907において、ユーザによる許可が不要なソフトウェアがあると判定した場合には、ステップS908に進む。ステップS908において、更新指示部606は、最新バージョンのソフトウェアであって、ユーザによる許可が不要なソフトウェアについて、対象車両に送信する。更に、更新指示部606は、ユーザ情報DB114のユーザ情報410の"ソフトウェアの更新状況"を書き換えた後、ステップS909に進む。
一方、ステップS907において、ユーザによる許可が不要なソフトウェアがないと判定した場合には、直接、ステップS909に進む。
ステップS909において、ソフトウェア種類判定部603は、最新バージョンでないと判定したソフトウェアの中に、更新に際してユーザによる許可が必要なソフトウェアがあるか否かを判定する。
ステップS909において、ユーザによる許可が必要なソフトウェアがないと判定した場合には、ステップS915に進む。一方、ステップS909において、ユーザによる許可が必要なソフトウェアがあると判定した場合には、ステップS910に進む。
ステップS910において、機能制限フラグ制御部604は、ユーザによる許可が必要なソフトウェアについて、既に、機能制限フラグのON指示を送信しているか否かを判定する。ステップS910において、機能制限フラグのON指示を送信していないと判定した場合には、ステップS911に進む。
ステップS911において、機能制限フラグ制御部604は、ユーザによる許可が必要なソフトウェアについて、対象車両に対して、機能制限フラグのON指示を送信し、ステップS912に進む。一方、ステップS910において、機能制限フラグのON指示を送信済みであると判定した場合には、直接、ステップS912に進む。
ステップS912において、告知指示部605は、ユーザによる許可が必要なソフトウェアについて、対象車両に対して、更新の許可要請を行うよう指示する。
更新の許可要請の指示に応じて対象車両にて許可要請が行われると、ステップS913において、告知指示部605は、対象車両のユーザにより更新許可の入力が行われたことを示す情報を、対象車両より受信したか否かを判定する。ステップS913において、更新許可の入力が行われたことを示す情報を、対象車両より受信したと判定した場合には、ステップS914に進む。
ステップS914において、更新指示部606は、最新バージョンのソフトウェア(ユーザにより更新が許可されたソフトウェア)を、対象車両に送信する。また、更新指示部606は、ユーザ情報DB114のユーザ情報410の"ソフトウェアの更新状況"を書き換えた後、ステップS915に進む。
一方、ステップS913において、更新許可の入力が行われたことを示す情報を、対象車両より受信していないと判定した場合には、直接、ステップS915に進む。
ステップS915において、接続状態管理部601は、対象車両からIG−OFF信号を受信したか否かを判定する。ステップS915において、対象車両からIG−OFF信号を受信していないと判定した場合には、ステップS901に戻る。このように、管理サーバ110におけるバージョン管理処理は、対象車両よりIG−OFF信号を受信するまで継続する。
一方、ステップS901において、最新バージョンのソフトウェアを新たに取得し、ソフトウェアDB113に格納したと判定した場合、ソフトウェア取得部602では、該最新バージョンのソフトウェアへの更新が必要と判定し、図10のステップ1001に進む。
ステップS1001において、接続状態管理部601は、対象車両がIG−ON状態にあるか否かを判定する。ステップS1001において、対象車両がIG−ON状態にあると判定した場合には、ステップS1002に進む。
ステップS1002において、ソフトウェア種類判定部603は、新たに格納した最新バージョンのソフトウェアが、ユーザによる許可が必要なソフトウェアであるか否かを判定する。ステップS1002において、ユーザによる許可が不要なソフトウェアであると判定した場合には、ステップS1006に進む。
一方、ステップS1002において、ユーザによる許可が必要なソフトウェアであると判定した場合には、ステップS1003に進む。
ステップS1003において、機能制限フラグ制御部604は、ユーザによる許可が必要であると判定したソフトウェアに関連する運転支援機能の一部または全部の作動を制限するための機能制限フラグのON指示を対象車両に送信する。その後、ステップS1004に進む。
ステップS1004において、告知指示部605は、ユーザによる許可が必要であると判定したソフトウェアについて、対象車両に対して、更新の許可要請を行うよう指示する。
更新の許可要請の指示に応じて対象車両において許可要請が行われると、ステップS1005において、告知指示部605は、対象車両より更新許可の入力が行われたことを示す情報を受信したか否かを判定する。ステップS1005において、更新許可の入力が行われたことを示す情報を受信したと判定した場合には、ステップS1006に進む。
ステップS1006において、更新指示部606は、最新バージョンのソフトウェア(ユーザにより更新が許可されたソフトウェア)を、対象車両に送信する。また、更新指示部606は、ユーザ情報DB114のユーザ情報410の"ソフトウェアの更新状況"を書き換えた後、図9のステップS902に戻る。
一方、ステップS1005において、更新許可の入力が行われたことを示す情報を受信していないと判定した場合には、直接、図9のステップS902に戻る。
一方、ステップS1001において、対象車両がIG−ON状態にないと判定した場合には、ステップS1011に進む。ステップS1011において、告知指示部605は、新たに格納した最新バージョンのソフトウェアが、ユーザによる許可が必要なソフトウェアであるか否かを判定する。ステップS1011において、ユーザによる許可が不要なソフトウェアであると判定した場合には、図9のステップS902に戻る。
一方、ステップS1011において、ユーザによる許可が必要なソフトウェアであると判定した場合には、ステップS1012に進む。ステップS1012において、接続状態管理部601は、対象車両に対応付けて登録されている携帯端末が接続状態か否かを判定する。
ステップS1012において、非接続状態であると判定した場合には、図9のステップS902に戻る。一方、ステップS1012において、接続状態であると判定した場合には、ステップS1013に進む。
ステップS1013において、告知指示部605は、ユーザによる許可が必要であると判定されたソフトウェアについて、対象携帯端末に対して、更新の許可要請を行うよう指示する。
更新の許可要請の指示に応じて対象携帯端末において許可要請が行われると、ステップS1014において、告知指示部605は、対象携帯端末より、更新許可の入力が行われたことを示す情報を受信したか否かを判定する。ステップS1014において、更新許可の入力が行われたことを示す情報を受信したと判定した場合には、ステップS1015に進む。
ステップS1015において、告知指示部605は、ユーザによる許可が必要であると判定したソフトウェアについて、既に、ユーザにより更新が許可されていると認識し、ユーザ情報410の"ソフトウェアの更新状況"を書き換えた後、ステップS902に戻る。
<9.車両において実行される処理の説明>
次に、車両120において実行される処理(最新化処理)の流れについて説明する。図11及び図12は、車両における最新化処理の流れを示すフローチャートである。図11及び図12に示すフローチャートは、車両がIG−ON状態になることで処理が開始される。
図11に示すように、ステップS1101において、制限部703は、運転支援ソフトウェア情報510を参照し、機能制限フラグがON状態のソフトウェアがあるか否かを判定する。ステップS1101において、機能制限フラグがON状態のソフトウェアがあると判定した場合には、ステップS1102に進む。一方、機能制限フラグがON状態のソフトウェアがないと判定した場合には、ステップS1103に進む。
ステップS1102において、制限部703は、機能制限フラグがON状態のソフトウェアに関連する運転支援機能の一部または全部の作動を制限する、機能制限を実施する。
ステップS1103において、DCM131は、IG−ON信号を管理サーバ110に送信する。
ステップS1104において、インストール実行部702は、管理サーバ110から更新が許可されたソフトウェアを受信したか否かを判定する。携帯端末140を介してユーザにより更新が許可されたソフトウェアがあった場合、管理サーバ110から、更新が許可されたソフトウェアが送信される。このため、インストール実行部702では、管理サーバ110から更新が許可されたソフトウェアを受信したと判定した場合には、ステップS1105に進む。
ステップS1105において、インストール実行部702は、運転支援ソフトウェア格納部322に既にインストールされているソフトウェアを、更新が許可されたソフトウェアにより更新した後、ステップS1106に進む。
一方、ステップS1104において、管理サーバ110から更新が許可されたソフトウェアを受信していないと判定した場合には、直接、ステップS1106に進む。
ステップS1106において、インストール実行部702は、運転支援ソフトウェア格納部322にインストールされている各ソフトウェアのバージョン情報を取得し、管理サーバ110に送信する。
ステップS1107において、インストール実行部702は、管理サーバ110より、ユーザによる許可が不要なソフトウェアを受信したか否かを判定する。ステップS1107において、ユーザによる許可が不要なソフトウェアを受信したと判定した場合には、ステップS1108に進む。
ステップS1108において、インストール実行部702は、運転支援ソフトウェア格納部322に既にインストールされているソフトウェアを、ユーザによる許可が不要なソフトウェアを用いて更新した後、ステップS1109に進む。
一方、ステップS1107において、ユーザによる許可が不要なソフトウェアを受信していないと判定した場合には、直接、ステップS1109に進む。
ステップS1109において、制限部703は、管理サーバ110より機能制限フラグのON指示を受信したか否かを判定する。ステップS1109において、機能制限フラグのON指示を受信したと判定した場合には、ステップS1110に進む。
ステップS1110において、制限部703は、管理サーバ110からのON指示に基づいて、運転支援ソフトウェア情報510の"機能制限フラグ"に"ON"を格納した後、ステップS1111に進む。
一方、ステップS1109において、機能制限フラグのON指示を受信していないと判定した場合には、直接、ステップS1111に進む。
ステップS1111において、告知部701は、管理サーバ110より、更新の許可要請の指示を受信したか否かを判定する。ステップS1111において、更新の許可要請の指示を受信したと判定した場合には、ステップS1112に進む。
ステップS1112において、告知部701は、管理サーバ110より更新の許可要請が指示されたソフトウェアについて、許可要請画面を表示した後、図12のステップS1201に進む。
一方、ステップS1111において、更新の許可要請の指示を受信していないと判定した場合には、図12のステップS1221に進む。
ステップS1201において、告知部701は、許可要請画面において、ユーザにより、更新許可の入力が行われたか否かを判定する。ステップS1201において、許可要請画面が表示されてから所定時間内に、ユーザにより更新許可の入力が行われたと判定した場合には、ステップS1202に進む。
ステップS1202において、告知部701は、ユーザにより更新許可の入力が行われたことを示す情報を、管理サーバ110に送信する。ステップS1203において、インストール実行部702は、ユーザにより更新が許可されたソフトウェアを、管理サーバ110より受信する。
ステップS1204において、インストール実行部702は、管理サーバ110より受信したソフトウェアを用いて、運転支援ソフトウェア格納部322に既にインストールされているソフトウェアを更新する。
インストール実行部702による更新が完了すると、ステップS1205において、制限部703は、更新が完了したソフトウェアについて、運転支援ソフトウェア情報510の"機能制限フラグ"にOFFを格納する。また、既に機能制限が実施されている場合には、制限部703が、更新が完了したソフトウェアに関連する運転支援機能についての機能制限を解除する(つまり、機能制限は、機能制限フラグがOFF状態になったタイミングで解除される)。
ステップS1206において、インストール実行部702は、更新が完了したことを示す更新完了通知を管理サーバ110に送信した後、ステップS1221に進む。
一方、ステップS1201において、許可要請画面が表示されてから所定時間内に、ユーザにより更新許可の入力が行われなかったと判定した場合には、ステップS1211に進む。ステップS1211において、制限部703は、機能制限を実施中であるか否かを判定する。
ステップS1211において、機能制限を実施中でないと判定した場合には、ステップS1212に進む。ステップS1212において、告知部701は、次にIG−ON状態になった時に、許可要請されたソフトウェアについての機能制限が実施されることを、ユーザに告知した後、ステップS1221に進む。
一方、ステップS1211において、機能制限を実施中であると判定した場合には、直接、ステップS1221に進む。ステップS1221において、制限部703は、車両がIG−OFF状態になったか否かを判定する。ステップS1221において、IG−OFF状態になっていないと判定した場合には、ステップS1107に戻る。一方、IG−OFF状態になったと判定した場合には、最新化処理を終了する。
<10.携帯端末において実行される処理の説明>
次に、携帯端末140において実行される処理(更新許可処理)の流れについて説明する。図13は、携帯端末における更新許可処理の流れを示すフローチャートである。図13に示すフローチャートは、携帯端末140において、更新許可プログラムが起動されることで処理が開始される。
ステップS1301において、更新許可部141は、管理サーバ110に接続する。ステップS1302において、更新許可部141は、管理サーバ110より、更新の許可要請の指示を受信したか否かを判定する。
ステップS1302において、更新の許可要請の指示を受信していないと判定した場合には、ステップS1307に進む。
一方、ステップS1302において、更新の許可要請の指示を受信したと判定した場合には、ステップS1303に進む。ステップS1303において、更新許可部141は、許可要請画面を表示する。
ステップS1304において、更新許可部141は、許可要請画面において、ユーザにより更新許可の入力が行われたか否かを判定する。許可要請画面が表示されてから所定時間内に、ユーザにより更新許可の入力が行われたと判定した場合には、ステップS1305に進む。ステップS1305において、更新許可部141は、ユーザにより更新許可の入力が行われたことを示す情報を、管理サーバ110に送信した後、ステップS1306に進む。
一方、ステップS1304において、許可要請画面が表示されてから所定時間内に更新許可の入力が行われなかったと判定した場合には、直接、ステップS1306に進む。
ステップS1306において、更新許可部141は、更新許可プログラムを終了する旨の指示が入力されたか否かを判定する。ステップS1307において、更新許可プログラムを終了する旨の指示が入力されていないと判定した場合には、ステップS1302に戻る。
一方、ステップS1306において、更新許可プログラムを終了する旨の指示が入力されたと判定した場合には、ステップS1307に進む。ステップS1307において、更新許可部141は、管理サーバ110との接続を遮断し、更新許可処理を終了する。
<11.車両用のソフトウェア管理システムにおける実施例>
次に、車両用のソフトウェア管理システム100における各実施例について、図9〜図13を参照しながら説明する。なお、以下では、対象車両における1回目のIG−ON状態において、対象車両にインストールされているソフトウェアのバージョン情報を確認し、2回目のIG−ON状態において、機能制限を実施するものとする。
<11.1 実施例1>
実施例1では、1回目のIG−ON状態において、ソフトウェアDB113に複数の最新バージョンのソフトウェアが新たに格納されたが、対象車両にて更新が許可されず、2回目のIG−ON状態において、機能制限が実施されるシーンについて説明する。なお、複数のソフトウェアには、ユーザによる許可が不要なソフトウェアと、ユーザによる許可が必要なソフトウェアとが含まれているものとする。
(1)実施例1の場合の管理サーバ110における処理(1回目のIG−ON状態)
実施例1の場合、ソフトウェアDB113に複数の最新バージョンのソフトウェアが新たに格納される前に、接続状態管理部601が、対象車両からIG−ON信号を受信する(ステップS901(No)→S902(Yes))。
この時点では、更新が許可されたソフトウェアはない(ステップS903(No))。また、対象車両からは、運転支援ソフトウェア格納部322にインストールされている各ソフトウェアのバージョン情報が送信されるため、ソフトウェア種類判定部603では、これを取得する(ステップS905)。
この時点で、対象車両の運転支援ソフトウェア格納部322には、最新バージョンのソフトウェアがインストールされている。このため、管理サーバ110では、最新バージョンのソフトウェアが新たに取得され、ソフトウェアDB113に格納されるまで待機することになる(ステップS906(Yes)→S915(No)→S901)。
ここで、複数の最新バージョンのソフトウェア(更新に際してユーザによる許可が不要なソフトウェアと、必要なソフトウェア)が新たに取得され、ソフトウェアDB113に格納されたとする(ステップS901(Yes))。なお、この時点では、既に対象車両はIG−ON状態にある(ステップS1001(Yes)。
したがって、最新バージョンのソフトウェアのうち、ユーザによる許可が不要なソフトウェアについては、更新指示部606が対象車両に送信するとともに、ユーザ情報DB114を書き換える(ステップS1002(No)→S1006)。一方、ユーザによる許可が必要なソフトウェアについては、機能制限フラグ制御部604が、対象車両に対して機能制限フラグのON指示を送信する(ステップS1002(Yes)→ステップS1003)。また、告知指示部605が、対象車両に対して更新の許可要請を行うよう指示する(ステップS1004)。
ここで、対象車両のユーザが、更新許可の入力を行わなかったとする。この場合、対象車両より、更新許可の入力が行われたことを示す情報が送信されることはない(ステップS1005(No))。このため、更新指示部606が、ユーザによる許可が必要なソフトウェアを対象車両に送信することはない。その後、対象車両から、IG−OFF信号を受信すると、管理サーバ110では、バージョン管理処理を終了する(ステップS902(No)→ステップS915(Yes))。
(2)実施例1の場合の車両120における処理(1回目のIG−ON状態)
車両120が1回目にIG−ON状態になった時点では、機能制限フラグはいずれもOFF状態であることから、機能制限は実施されず、DCM131では、管理サーバ110にIG−ON信号を送信する(ステップS1101(No)→S1103)。また、1回目にIG−ON状態になった時点で、管理サーバ110から更新が許可されたソフトウェアが送信されることもない(ステップS1104(No))。
そこで、インストール実行部702では、運転支援ソフトウェア格納部322にインストールされている各ソフトウェアのバージョン情報を読み出し、管理サーバ110に送信する(ステップS1106)。
この時点では、運転支援ソフトウェア格納部322にインストールされている各ソフトウェアのバージョン情報は最新である。このため、管理サーバ110から、ユーザによる許可が不要なソフトウェアが送信されることも、機能制限フラグのON指示が送信されることもない(ステップS1107(No)→S1109(No))。また、管理サーバ110から更新の許可要請の指示が送信されることもない(ステップS1111(No)→S1221(No)→S1107)。
ここで、管理サーバ110により複数の最新バージョンのソフトウェア(更新に際してユーザによる許可が不要なソフトウェアと、ユーザによる許可が必要なソフトウェア)が新たに取得され、ソフトウェアDB113に格納されたとする。
この場合、管理サーバ110から、ユーザによる許可が不要なソフトウェアが送信される。このため、インストール実行部702では、これを受信し、運転支援ソフトウェア格納部322に既にインストールされているソフトウェアを更新する(ステップS1107(Yes)→S1108)。また、管理サーバ110から、機能制限フラグのON指示が送信されるため、制限部703では、これを受信し、機能制限フラグをONにする(ステップS1109(Yes)→S1110)。
更に、管理サーバ110から、更新の許可要請の指示が送信されるため、告知部701では、これを受信して許可要請画面を表示する(ステップS1111(Yes)→S1112)。
ここで、車両120のユーザが、更新許可の入力を行わなかったとする。この場合、告知部701では、ユーザにより更新許可の入力が行われなかったと判定する(ステップS1201(No))。なお、この時点では、未だ機能制限を実施していないことから、制限部703では、ユーザに対して、次にIG−ON状態になった時に機能制限を実施することを告知する(ステップS1211(No)→S1212)。その後、車両120がIG−OFF状態になると、最新化処理を終了する(ステップS1221(Yes))。
(3)実施例1の場合の管理サーバ110における処理(2回目のIG−ON状態)
1回目のIG−ON状態において、複数の最新バージョンのソフトウェアが新たに取得されソフトウェアDB113に格納されて以降、2回目にIG−ON状態になるまでの間に、更なる最新バージョンのソフトウェアが取得されることはなかったものとして説明する。
この場合、ソフトウェアDB113に更なる最新バージョンのソフトウェアが格納されることなく、対象車両より2回目のIG−ON信号を受信する(ステップS901(No)→S902(Yes))。
この時点では、更新が許可されたソフトウェアはない。また、対象車両からは、運転支援ソフトウェア格納部322にインストールされている各ソフトウェアのバージョン情報が送信される(ステップS903(No)→S905)。
管理サーバ110では、1回目のIG−ON状態において、ユーザによる許可が必要なソフトウェアを対象車両に送信していない。このため、対象車両より取得するバージョン情報のうち、ユーザによる許可が必要なソフトウェアについては、バージョン情報が最新のものではない(ステップS906(No)→S907(No)→S909(Yes))。
また、管理サーバ110では、1回目のIG−ON状態において、当該ソフトウェアについて既に対象車両に対して機能制限フラグのON指示を送信しているため、ここでは機能制限フラグのON指示は送信しない(ステップS910(Yes))。一方、告知部701では、再度、更新の許可要請を行うよう指示する(ステップS912)。
なお、2回目のIG−ON状態において、ユーザが、更新許可の入力を行った場合には、更新許可された当該ソフトウェアを送信し、ユーザ情報DB114を書き換える(ステップS913(Yes)→S914)。一方、2回目のIG−ON状態においても、ユーザが、更新許可の入力を行わなかった場合には、当該ソフトウェアを送信することも、ユーザ情報DB114を書き換えることもない(ステップS913(No))。
その後、2回目のIG−OFF信号を受信した場合には、対象車両についてのバージョン管理処理を終了する(ステップS915(Yes))。
(4)実施例1の場合の車両120における処理(2回目のIG−ON状態)
車両120が2回目にIG−ON状態になった時点で、ユーザによる許可が必要なソフトウェアについての機能制限フラグはON状態になっている。このため、2回目にIG−ON状態になると、制限部703では、機能制限を実施する(ステップS1101(Yes)→S1102)。その後、DCM131が、管理サーバ110にIG−ON信号を送信する(ステップS1103)。なお、この時点で、管理サーバ110から更新が許可されたソフトウェアが送信されることはない(ステップS1104(No))。
インストール実行部702では、運転支援ソフトウェア格納部322にインストールされている各ソフトウェアのバージョン情報を読み出し、管理サーバ110に送信する(ステップS1106)。
管理サーバ110に送信したバージョン情報のうち、1回目のIG−ON状態において更新許可の入力が行われなかったソフトウェアについては、バージョン情報が最新ではない。このため、管理サーバ110からは、更新の許可要請の指示が送信される。なお、当該ソフトウェアについての機能制限フラグのON指示は、1回目のIG−ON状態において既に管理サーバ110より送信済みであるため、ここでは送信されない(ステップS1107(No)→S1109(No)→S1111(Yes))。
更新の許可要請の指示を受信した告知部701では、更新の許可要請画面を表示し、ユーザによる更新許可の入力を受け付ける。
ここで、告知部701では、ユーザから更新許可の入力を受け付けたとする。この場合、告知部701では、更新許可の入力が行われたことを示す情報を管理サーバ110に送信する(ステップS1201(Yes)→S1202)。また、インストール実行部702では、更新が許可されたソフトウェアを管理サーバ110から受信し、運転支援ソフトウェア格納部322に既にインストールされているソフトウェアを更新する(ステップS1203→S1204)。更に、制限部703では、実施中の機能制限を解除するとともに、機能制限フラグをOFF状態にし、インストール実行部702では、更新完了通知を管理サーバ110に送信する(ステップS1205→S1206)。その後、車両120がIG−OFF状態になると、最新化処理を終了する(ステップS1221(Yes))。
なお、2回目のIG−ON状態においても、ユーザが更新許可の入力を行わなかった場合には、車両120がIG−OFF状態になるまで機能制限を継続する(ステップS1201(No)→S1211(Yes)→S1221(Yes))。
<11.2 実施例2>
実施例2では、IG−OFF状態において、複数の最新バージョンのソフトウェアが新たに取得されソフトウェアDB113に格納されたが、1回目のIG−ON状態で更新が許可されず、2回目のIG−ON状態で機能制限が実施されるシーンについて説明する。なお、実施例1と同様に、複数の最新バージョンのソフトウェアには、ユーザによる許可が不要なソフトウェアと、必要なソフトウェアとが含まれているものとする。
(1)実施例2の場合の管理サーバ110における処理(1回目のIG−ON状態)
実施例2の場合、対象車両が1回目のIG−ON状態になる前に、複数の最新バージョンのソフトウェアが新たに取得されソフトウェアDB113に格納される(ステップS901(Yes))。この場合、接続状態管理部601では、対象車両がIG−ON状態であるか否かを判定する(ステップS1001)。
この時点では、対象車両がIG−ON状態ではないため、接続状態管理部601では、携帯端末が接続状態か否かを判定する(ステップS1001(No)→S1011(Yes)→S1012)。接続状態管理部601では、携帯端末が非接続状態であれば、対象車両からIG−ON信号が送信されるのを待つ(ステップS1012(No)→S902)。
ここで、対象車両が1回目のIG−ON状態になると、接続状態管理部601では、IG−ON信号を受信する(ステップS902(Yes))。この時点では、更新が許可されたソフトウェアはない。また、対象車両からは、運転支援ソフトウェア格納部322にインストールされている各ソフトウェアのバージョン情報が送信される(ステップS903(No)→S905)。
ここで、ソフトウェアDB113には、既に複数の最新バージョンのソフトウェアが格納されていることから、ソフトウェア種類判定部603では、取得したバージョン情報が最新ではないと判定する(ステップS906(No))。
ソフトウェアDB113に既に格納されている複数の最新バージョンのソフトウェアのうち、ユーザによる許可が不要なソフトウェアについては、更新指示部606が対象車両に送信する。また、更新指示部606が、ユーザ情報DB114を書き換える(ステップS907(Yes)→S908)。
また、ユーザによる許可が必要なソフトウェアについては、未だ機能制限フラグのON指示を送信していない。このため、機能制限フラグ制御部604では、当該ソフトウェアについて、対象車両に対して機能制限フラグのON指示を送信する(ステップS909(Yes)→S910(No)→S911)。また、告知指示部605では、当該ソフトウェアについて、対象車両に対して更新の許可要請を行うよう指示する(ステップS912)。
ここで、告知部701が、対象車両より、更新許可の入力が行われたことを示す情報を受信しなかったとする(ステップS913(No))。
この場合、更新指示部606では、ユーザによる許可が必要なソフトウェアを対象車両に送信することはない。その後、対象車両から、IG−OFF信号を受信すると、管理サーバ110では、バージョン管理処理を終了する(ステップS915(Yes))。
(2)実施例2の場合の車両120における処理(1回目のIG−ON状態)
車両120が1回目にIG−ON状態になった時点では、機能制限フラグはいずれもOFF状態であることから、機能制限は実施されず、DCM131では、管理サーバ110にIG−ON信号を送信する(ステップS1101(No)→S1103)。また、1回目のIG−ON状態の時点で、管理サーバ110から更新が許可されたソフトウェアが送信されることはない(ステップS1104(No))。
そこで、インストール実行部702では、運転支援ソフトウェア格納部322にインストールされている各ソフトウェアのバージョン情報を読み出し、管理サーバ110に送信する(ステップS1106)。
この時点では、既に、管理サーバ110のソフトウェアDB113には、複数の最新バージョンのソフトウェアが格納されている。したがって、管理サーバ110からは、ユーザによる許可が不要なソフトウェアが送信されるとともに、ユーザによる許可が必要なソフトウェアについて、機能制限フラグのON指示が送信される。このため、インストール実行部702では、ユーザによる許可が不要なソフトウェアについては更新する。また、ユーザによる許可が必要なソフトウェアについては機能制限フラグをON状態にする(ステップS1107(Yes)→S1108→S1109(Yes)→S1110)。
更に、管理サーバ110からは、ユーザによる許可が必要なソフトウェアについての更新の許可要請の指示が送信されるため、告知部701では、許可要請画面を表示する(ステップS1111(Yes)→S1112)。
ここで、ユーザが、更新許可の入力を行わなかったとする。この時点では、未だ機能制限を実施していないため、告知部701では、次にIG−ON状態になった時に機能制限を実施することをユーザに告知する(ステップS1201(No)→S1211(No)→S1212)。その後、車両120がIG−OFF状態になると、最新化処理を終了する(ステップS1221(Yes))。
なお、実施例2の場合の管理サーバ110における処理(2回目のIG−ON状態)及び車両120における処理(2回目のIG−ON状態)については、上記実施例1と同じであるため、ここでは説明を省略する。
<11.3 実施例3>
実施例3では、IG−OFF状態において、ソフトウェアDB113に複数の最新バージョンのソフトウェアが新たに格納され、ユーザが携帯端末140にて更新許可の入力を行い、IG−ON状態になった時にソフトウェアを更新するシーンについて説明する。
(1)実施例3の場合の管理サーバ110における処理
実施例3の場合、対象車両がIG−ON状態になる前に、複数の最新バージョンのソフトウェアが新たに取得されソフトウェアDB113に格納される。このため、接続状態管理部601では、対象車両がIG−ON状態であるか否かを判定する(ステップS901(Yes)→S1001)。
この時点では、対象車両がIG−ON状態ではないため、接続状態管理部601では、携帯端末140が接続状態か否かを判定する(ステップS1001(No)→S1011(Yes)→S1012)。
ここで、携帯端末140が接続状態であったとする。この場合、告知指示部605では、携帯端末に対して、最新バージョンのソフトウェアのうち、ユーザによる許可が必要なソフトウェアについて、更新の許可要請を行うよう指示する(ステップS1012(Yes)→S1013)。
ここで、告知指示部605が、携帯端末より、更新許可の入力が行われたことを示す情報を受信したとする(ステップS1014(Yes))。この場合、更新指示部606では、ユーザによる許可が必要なソフトウェアについて、既に、ユーザにより更新が許可されたと認識する(ステップS1015)。
その後、対象車両がIG−ON状態になると、接続状態管理部601では、対象車両よりIG−ON信号を受信する(ステップS902(Yes))。この時点で、携帯端末140を介して既に更新が許可されたソフトウェアがあるため、更新指示部606では、更新が許可されたと認識したソフトウェアを、対象車両に送信する。また、更新指示部606では、ユーザ情報DB114のユーザ情報410を書き換える(ステップS903(Yes)→S904)。
また、更新指示部606では、対象車両より、運転支援ソフトウェア格納部322にインストールされている各ソフトウェアのバージョン情報を取得する(ステップS905)。この時点では、ユーザによる許可が必要なソフトウェアについては車両120に送信済みであるため、ユーザによる許可が必要なソフトウェアについてのバージョン情報は最新である。一方、ユーザによる許可が不要なソフトウェアについては、まだ車両120に送信していないため、ユーザによる許可が不要なソフトウェアについてのバージョン情報は最新ではない(ステップS906(No))。
このため、更新指示部606では、ユーザによる許可が不要なソフトウェアを対象車両に送信するとともに、ユーザ情報DB114を書き換える(ステップS907(Yes)→S908)。なお、この時点では、ユーザによる許可が必要なソフトウェアは送信済みであるため(ステップS909(No))、対象車両からIG−OFF信号を受信すると、対象車両についてのバージョン管理処理を終了する(ステップS915(Yes))。
(2)実施例3の場合の車両120における処理(1回目のIG−ON)
車両120が1回目にIG−ON状態になった時点では、機能制限フラグはいずれもOFF状態であることから、機能制限は実施されず、DCM131では、管理サーバ110にIG−ON信号を送信する(ステップS1101(No)→S1103)。
ここで、実施例3の場合、IG−ON状態になった時点で、管理サーバ110から更新が許可されたソフトウェアが送信される。したがって、インストール実行部702では、更新が許可されたソフトウェアを受信すると、運転支援ソフトウェア格納部322に既にインストールされているソフトウェアを更新する(ステップS1104(Yes)→S1105)。
その後、インストール実行部702では、運転支援ソフトウェア格納部322にインストールされている各ソフトウェアのバージョン情報を管理サーバ110に送信する(ステップS1106)。この時点では、ユーザによる許可が必要なソフトウェアについては最新バージョンに更新されているが、ユーザによる許可が不要なソフトウェアについては最新バージョンに更新されていない。
したがって、管理サーバ110からは、ユーザによる許可が不要なソフトウェアが送信される。インストール実行部702では、ユーザによる許可が不要なソフトウェアを受信すると、運転支援ソフトウェア格納部322に既にインストールされているソフトウェアを更新する(ステップS1107(Yes)→S1108)。
なお、管理サーバ110から、機能制限フラグのON指示、及び、ユーザによる許可が必要なソフトウェアについての更新の許可要請の指示は送信されない(ステップS1109(No)→S1111(No)→S1221)。
その後、車両120がIG−OFF状態になると、最新化処理を終了する(ステップS1221(Yes))。
(3)実施例3の場合の携帯端末140における処理
実施例3の場合、携帯端末140の更新許可部141が管理サーバ110に接続した後、管理サーバ110より、ユーザによる許可が必要なソフトウェアについての更新の許可要請の指示が送信される(ステップS1301→S1302(Yes))。
更新許可部141では、更新の許可要請の指示を受信すると、許可要請画面を表示し、ユーザによる更新許可の入力を受け付ける(ステップS1303)。ユーザが更新許可を入力した場合、更新許可部141では、管理サーバ110に対して、更新許可の入力が行われたことを示す情報を送信する(ステップS1304(Yes)→S1305)。
その後、ユーザにより、更新許可プログラムの停止指示が入力されると、更新許可部141では、管理サーバ110との接続を遮断し、更新許可処理を終了する(ステップS1306(Yes)→S1307)。
<12.管理サーバにおいて実行されるその他の処理の説明>
次に、管理サーバ110において実行されるその他の処理(ユーザ管理部112によるユーザ管理処理)について説明する。
図14は、管理サーバ110のユーザ管理部112により実行されるユーザ管理処理の流れを示すフローチャートである。図14に示すフローチャートは、対象車両のIG−ON状態管理処理、対象携帯端末の接続状態管理処理、バージョン管理処理と並行して実行される。
ステップS1401において、ユーザ管理部112は、告知指示部605が対象車両に対して、更新の許可要請を行うよう指示したか否かを判定する。ステップS1401において、指示していないと判定した場合には、ステップS1405に進む。
一方、指示したと判定した場合には、ステップS1402に進む。ステップS1402において、ユーザ管理部112は、告知指示部605が更新の許可要請を行うよう指示したソフトウェアについて、ユーザにより更新許可の入力が行われるまでの時間の管理を開始する。また、ユーザ管理部112は、告知指示部605が更新の許可要請を行うよう指示した回数の管理を開始する。
ステップS1403において、ユーザ管理部112は、告知指示部605により、更新の許可要請を行うよう指示したソフトウェアについて、ユーザにより更新許可の入力が行われたか否かを判定する。
ステップS1403において、更新許可の入力が行われていないと判定した場合には、更新許可の入力が行われるまで待機する。一方、更新許可の入力が行われたと判定された場合には、ステップS1404に進む。
ステップS1404において、ユーザ管理部112は、ユーザにより更新許可の入力が行われるまでにかかった時間及びその間に告知指示部605が更新の許可要請を行うよう指示した回数を集計する。
ステップS1405において、ユーザ管理部112は、対象車両が管理対象外となったか否かを判定する。管理対象外になっていないと判定した場合には、ステップS1401に戻る。一方、管理対象外になったと判定した場合には、当該対象車両についてのユーザ管理処理を終了する。
<13.まとめ>
以上の説明から明らかなように、本実施形態にかかる車両用のソフトウェア管理システムでは、
・自動運転または運転支援システムにインストールされているソフトウェアについての最新バージョンのソフトウェアを管理サーバが取得しソフトウェアDBに格納した場合に、更新が必要と判定する構成とした。
・更新が必要と判定した場合に、新たに取得した最新バージョンのソフトウェアが、更新に際してユーザによる許可が必要なソフトウェアであるか否かを判定する構成とした。
・ユーザによる許可が必要なソフトウェアであると判定した場合に、車両に対して、当該ソフトウェアに関連する自動運転機能または運転支援機能の一部または全部の作動を制限するための機能制限フラグのON指示を送信する構成とした。
・機能制限フラグがON状態になった後であって、次にIG−ON状態になった時に、当該ソフトウェアに関連する自動運転機能または運転支援機能の一部または全部の作動を制限する処理を開始する構成とした。
・車両のユーザが、当該ソフトウェアについて更新許可の入力を行い、当該ソフトウェアによる更新が完了することで、機能制限を解除する構成とした。
上記構成によれば、ユーザは、更新許可の入力を積極的に行うことで、自動運転機能または運転支援機能の一部または全部の作動が制限されるといった事態を回避できる(あるいは制限される時間を短くすることができる)というインセンティブを得ることができる。これにより、ユーザは、更新許可の入力を積極的に行うようになる。この結果、本実施形態に係る車両用のソフトウェア管理システムによれば、更新に際してユーザによる許可が必要なソフトウェアについての早期更新を実現できる。
[第2の実施形態]
上記第1の実施形態では、ユーザによる許可が必要なソフトウェアがソフトウェアDB113に格納され、更新が必要と判定した場合に、管理サーバ110が、車両に対して、機能制限フラグのON指示を送信する構成とした。また、管理サーバ110から機能制限フラグのON指示を受けた場合に、車両120において、機能制限フラグをON状態にする構成とした。
これに対して、第2の実施形態では、管理サーバ110から車両120への機能制限フラグのON指示は行わない。一方で、第2の実施形態では、ユーザによる許可が必要なソフトウェアについて、ユーザが更新許可の入力を行わなかったと判定した場合に、車両120が機能制限フラグをON状態にする。以下、第2の実施形態について、第1の実施形態との相違点を中心に説明する。
<1.管理サーバにおいて実行される処理の説明>
はじめに、管理サーバ110において実行される処理のうち、バージョン管理処理について説明する。
図15及び図16は、バージョン管理処理の流れを示すフローチャートである。図15に示すフローチャートにおいて、図9に示すフローチャートとの相違点は、図15の場合、ステップS910、S911の処理がない点である。同様に、図16に示すフローチャートにおいて、図10に示すフローチャートとの相違点は、図16の場合、ステップS1003の処理がない点である。本実施形態では、管理サーバ110から車両120に対して機能制限フラグのON指示を行わないためである。
<2.車両において実行される処理の説明>
次に、車両120において実行される処理(最新化処理)について説明する。図17及び図18は、車両における最新化処理の流れを示すフローチャートである。
図17に示すフローチャートにおいて、図11に示すフローチャートとの相違点は、図17の場合、ステップS1109、S1110の処理がない点である。本実施形態では、管理サーバ110から車両120に対して機能制限フラグのON指示を行わないためである。
また、図18に示すフローチャートにおいて、図12に示すフローチャートとの相違点は、図18の場合、ステップS1801において、機能制限フラグをONにする点である。本実施形態では、管理サーバ110から更新の許可要請の指示を受信し、告知部701が許可要請画面を表示した状態で、ユーザにより更新許可の入力が行われなかったと判定した場合に、制限部703が機能制限フラグをON状態にする。
このように、本実施形態では、車両120において、ユーザによる更新許可の入力が行われたか否かに応じて、車両120側で機能制限フラグのONまたはOFFを制御する。
<3.まとめ>
以上の説明から明らかなように、本実施形態にかかる車両用のソフトウェア管理システムでは、
・自動運転または運転支援システムにインストールされているソフトウェアについての最新バージョンのソフトウェアを管理サーバが取得しソフトウェアDBに格納した場合に、更新が必要と判定する構成とした。
・更新が必要と判定した場合に、新たに取得した最新バージョンのソフトウェアが、更新に際してユーザによる許可が必要なソフトウェアであるか否かを判定する構成とした。
・ユーザによる許可が必要なソフトウェアについて、ユーザにより更新が許可されなかったと判定した場合に、当該ソフトウェアに関連する自動運転機能または運転支援機能の一部または全部の作動を制限するための機能制限フラグをON状態にする構成とした。
・機能制限フラグがON状態になった後であって、次にIG−ON状態になった時に、当該ソフトウェアに関連する自動運転機能または運転支援機能の一部または全部の作動を制限する処理を開始する構成とした。
・車両のユーザが、当該ソフトウェアについて更新許可の入力を行い、当該ソフトウェアによる更新が完了することで、機能制限を解除する構成とした。
上記構成によれば、ユーザは、更新許可の入力を積極的に行うことで、自動運転機能または運転支援機能の一部または全部の作動が制限されるといった事態を回避できる(あるいは制限される時間を短くすることができる)というインセンティブを得ることができる。これにより、ユーザは、更新許可の入力を積極的に行うようになる。この結果、本実施形態に係る車両用のソフトウェア管理システムによれば、更新に際してユーザによる許可が必要なソフトウェアについての早期更新を実現できる。
[第3の実施形態]
上記第1及び第2の実施形態では、ユーザによる許可が不要なソフトウェアについては、車両がIG−ON状態になったことをトリガに車両に送信する構成とした。また、ユーザによる許可が必要なソフトウェアについては、ユーザによる更新許可の入力が行われたことをトリガに車両に送信する構成とした。
これに対して、第3の実施形態では、車両の状態が、更新に適した状態になったか否かを判定し、更新に適した状態になったと判定した場合に、管理サーバから車両に対して最新バージョンのソフトウェアを送信する構成とする。これにより、車両の通信負荷を分散させることが可能となる。以下、第3の実施形態について、上記第1の実施形態との相違点を中心に説明する。
<1.管理サーバにおいて実行される処理の説明>
はじめに、管理サーバ110において実行される処理(バージョン管理処理、ソフトウェア送信処理)の流れについて説明する。
(1)バージョン管理処理
図19及び図20は、バージョン管理処理の流れを示すフローチャートである。図19に示すフローチャートにおいて、図9に示すフローチャートとの相違点は、図19の場合、ステップS1901、S1902、S1903の処理内容が、図9のステップS904、S908、S914の処理内容とは異なる点である。なお、本実施形態では、運転支援ソフトウェア情報510に、ソフトウェアの"更新フラグ"が格納されるものとする。更新フラグとは、運転支援システム132にインストールされているソフトウェアを更新することが可能な状態であることを示すフラグである。運転支援ソフトウェア情報510に格納される"更新フラグ"は、管理サーバ110より、更新フラグのON指示を受信するとON状態となり、対応するソフトウェアが最新バージョンに更新されると、OFF状態になるものとする。
ステップS1901において、更新指示部606は、対象車両に対して、更新が許可されたソフトウェアの更新フラグのON指示を送信する。
ステップS1902において、更新指示部606は、対象車両に対して、ユーザによる許可が不要なソフトウェアについての更新フラグのON指示を送信する。
ステップS1903において、更新指示部606は、対象車両に対して、ユーザによる許可が必要なソフトウェアについての更新フラグのON指示を送信する。
同様に、図20に示すフローチャートにおいて、図10に示すフローチャートとの相違点は、図20の場合、ステップS2001の処理内容が、図10のステップS1006の処理内容とは異なる点である。
ステップS2001において、更新指示部606は、対象車両に対して、ユーザによる許可が必要なソフトウェアについての更新フラグのON指示を送信する。
このように、本実施形態では、管理サーバ110が、対象車両に対してソフトウェアの送信が可能な状態になったとしても、直ちにソフトウェアを送信せずに、対象車両に対して、当該ソフトウェアについての更新フラグのON指示を送信する。
これにより、対象車両では、車両120において更新に適した状態になったと判定した場合に、更新フラグがON状態のソフトウェアについて、管理サーバ110に送信要求を行うことが可能になる。
つまり、車両120において、受信及び更新に適した状態になった場合に、ソフトウェアの受信及び更新を実行することが可能になる。
(2)ソフトウェア送信処理
図21は、管理サーバ110のソフトウェア管理部111によるソフトウェア送信処理の流れを示すフローチャートである。図21に示すソフトウェア送信処理は、バージョン管理処理と並行して実行される。
ステップS2101において、更新指示部606は、対象車両より、ソフトウェアの送信要求があったか否かを判定する。ステップS2101において、ソフトウェアの送信要求があったと判定した場合には、ステップS2102に進む。
ステップS2102において、更新指示部606は、送信要求があったソフトウェアについて、対象車両に送信するとともに、ユーザ情報DB114を書き換える。
<2.車両において実行される処理の説明>
次に、車両120において実行される処理(最新化準備処理、最新化処理)について説明する。
(1)最新化準備処理
図22及び図23は、車両120における最新化準備処理の流れを示すフローチャートである。
図22のフローチャートにおいて、図11のフローチャートとの相違点は、図22の場合、ステップS2201〜S2205の処理内容が、図11のステップS1101、1104、S1105、S1107、S1108の処理内容とは異なっている点である。
ステップS2201において、制限部703は、運転支援ソフトウェア情報510を参照し、機能制限フラグがON状態で、かつ、更新フラグがOFF状態のソフトウェアがあるか否かを判定する。
ステップS2201において、機能制限フラグがON状態で、かつ、更新フラグがOFF状態のソフトウェアがあると判定した場合には、ステップS1102に進む。一方、ステップS2201において、機能制限フラグがON状態で、かつ、更新フラグがOFF状態のソフトウェアがないと判定した場合には、ステップS1103に進む。
機能制限フラグがON状態で、更新フラグがOFF状態のソフトウェアとは、ユーザによる許可が必要なソフトウェアであると判定されて、機能制限フラグがON状態となったが、ユーザにより、更新許可の入力が行われていないソフトウェアである。
なお、機能制限フラグがON状態で、更新フラグがON状態のソフトウェアとは、ユーザによる許可が必要なソフトウェアであると判定されて、機能制限フラグがON状態となったが、ユーザによる更新許可の入力が行われたソフトウェアである。ユーザにより更新許可の入力が行われることで、更新フラグはON状態となるが、更新に適した状態になるまで更新されないため、機能制限フラグはON状態のままとなる。この場合には、機能制限は実施されない。
ステップS2202において、インストール実行部702は、更新が許可されたソフトウェアについての更新フラグのON指示を受信したか否かを判定する。ステップS2202において、受信したと判定した場合、ステップS2203において、インストール実行部702は、更新が許可されたソフトウェアについての更新フラグをON状態にする。
ステップS2204において、インストール実行部702は、ユーザによる許可が不要なソフトウェアについての更新フラグのON指示を受信したか否かを判定する。ステップS2204において、受信したと判定した場合、ステップS2205において、インストール実行部702は、ユーザによる許可が不要なソフトウェアについての更新フラグをON状態にする。
同様に、図23に示すフローチャートにおいて、図12に示すフローチャートとの相違点は、図23の場合、ステップS2301、S2302の処理内容が、図12のステップS1203、S1204の処理内容とは異なっている点である。また、図23の場合、図12のステップS1205、S1206の処理がない点である。
ステップS2301において、インストール実行部702は、更新が許可されたソフトウェアについての更新フラグのON指示を、管理サーバ110より受信したか否かを判定する。
ステップS2301において、受信したと判定した場合には、ステップS2302において、インストール実行部702は、更新が許可されたソフトウェアについての更新フラグをON状態にする。
(2)最新化処理
図24は、車両120における最新化処理の流れを示すフローチャートである。図24に示す最新化処理は、最新化準備処理(図22、図23)と並行して実行される。ただし、最新化準備処理は、車両120がIG−ON状態になったことを条件に実行開始するのに対して、最新化処理は、車両がIG−ON状態でなくてもよく、管理サーバ110と通信可能な状態であればよい。
ステップS2401において、インストール実行部702は、車両120が、更新に適した状態にあるか否かを判定する。ステップS2401において、更新に適した状態にあると判定した場合、ステップS2402に進む。なお、更新に適した状態とは、例えば、車両120が停止している状態や、駐車場等に駐車している状態、あるいは、車両120が電気自動車の場合にあっては、充電中の状態等が挙げられる。
ステップS2402において、インストール実行部702は、更新フラグがON状態のソフトウェアがあるか否かを判定する。ステップS2402において、更新フラグがON状態のソフトウェアがあると判定した場合には、ステップS2403に進む。
ステップS2403において、インストール実行部702は、更新フラグがON状態のソフトウェアについて、管理サーバ110に最新バージョンの送信要求を行う。ステップS2404において、インストール実行部702は、送信要求に応じて管理サーバ110より、最新バージョンのソフトウェアが送信された場合に、これを受信する。更に、インストール実行部702は、受信したソフトウェアを用いて、運転支援ソフトウェア格納部322に既にインストールされているソフトウェアを更新する。
ステップS2405において、制限部703は、機能制限フラグをOFF状態にする。なお、既に機能制限が実施されている場合にあっては、機能制限を解除する(つまり、機能制限は、機能制限フラグがOFF状態になったタイミングで解除される)。
ステップS2406において、インストール実行部702は、更新完了通知を、管理サーバ110に送信する。
<3.まとめ>
以上の説明から明らかなように、本実施形態にかかる車両用のソフトウェア管理システムでは、
・自動運転または運転支援システムにインストールされているソフトウェアについての最新バージョンのソフトウェアを管理サーバが取得しソフトウェアDBに格納した場合に、更新が必要と判定する構成とした。
・更新が必要と判定した場合に、新たに取得した最新バージョンのソフトウェアが、更新に際してユーザによる許可が必要なソフトウェアであるか否かを判定する構成とした。
・ユーザによる許可が必要なソフトウェアであると判定した場合に、車両に対して、当該ソフトウェアに関連する自動運転機能または運転支援機能の一部または全部の作動を制限するための機能制限フラグのON指示を送信する構成とした。
・機能制限フラグがON状態になった後であって、次にIG−ON状態になった時に、当該ソフトウェアに関連する自動運転機能または運転支援機能の一部または全部の作動を制限する処理を開始する構成とした。
・車両のユーザが、当該ソフトウェアについて更新許可の入力を行い、当該ソフトウェアによる更新が完了することで、機能制限を解除する構成とした。
・新たに取得した最新バージョンのソフトウェアのうち、ユーザによる許可が不要なソフトウェアについては、車両がIG−ON状態になった場合に、車両に対して更新フラグのON指示を送信する構成とした。また、ユーザによる許可が必要なソフトウェアについては、ユーザによる更新許可の入力が行われた場合に、車両に対して更新フラグのON指示を送信する構成とした。
・車両において、更新に適した状態になったと判定した場合に、更新フラグがON状態のソフトウェアについて、管理サーバより最新バージョンのソフトウェアを受信し、更新する構成とした。
上記構成によれば、ユーザは、更新許可の入力を積極的に行うことで、自動運転機能または運転支援機能の一部または全部の作動が制限されるといった事態を回避できる(あるいは制限される時間を短くすることができる)というインセンティブを得ることができる。これにより、ユーザは、更新許可の入力を積極的に行うようになる。この結果、本実施形態に係る車両用のソフトウェア管理システムによれば、更新に際してユーザによる許可が必要なソフトウェアについての早期更新を実現できる。
加えて、上記構成によれば、自動運転機能または運転支援機能に関するソフトウェアを、車両が更新に適した状態になった場合に実行することができる。これにより、本実施形態に係る車両用のソフトウェア管理システムによれば、車両の通信負荷を分散させることが可能となる。
[変形例]
上記第1乃至第3の実施形態では、今回のIG−ON状態において機能制限フラグがON状態になった場合には、次のIG−ON状態において機能制限を実施する構成とした。しかしながら、機能制限を実施するタイミングは、これに限定されない。例えば、今回のIG−ON状態において機能制限フラグがON状態になったタイミングで機能制限を実施するようにしてもよいし、機能制限フラグがON状態になった後に、最初に車両120が停止したタイミングで機能制限を実施するようにしてもよい。いずれにしても、機能制限フラグがON状態になった後の所定のタイミングで、機能制限が開始されればよい。
また、上記第1乃至第3の実施形態では、ソフトウェア取得部602が最新バージョンのソフトウェアを新たに取得しソフトウェアDB113に格納したタイミングで、ソフトウェア種類判定部603が判定を行う構成とした。しかしながら、ソフトウェア種類判定部603が判定を行うタイミングはこれに限定されず、予め定められた日時に判定を行うようにしてもよい。あるいは、対象車両がIG−ON状態にある場合、または、通信可能な状態にある場合に、判定を行うようにしてもよい。
また、上記第1乃至第3の実施形態では、管理サーバ110のソフトウェア取得部602が更新要否判定手段として機能するものとして説明した。しかしながら、更新要否判定手段としての機能は、車両120側に配してもよい。ただし、この場合、管理サーバ110のソフトウェア取得部602では、最新バージョンのソフトウェアを取得するたびに、最新バージョンのソフトウェアを取得したことを示す情報を車両120に送信するものとする。あるいは、管理サーバ110のソフトウェア取得部602では、最新バージョンのソフトウェアを取得するたびに、取得したソフトウェアのバージョン情報を車両120に送信するものとする。
これにより、車両120側に配された更新要否判定手段では、ソフトウェア取得部602から送信された情報に基づいて、運転支援用ECU300にインストールされているソフトウェアについて更新の要否を判定することができる。
なお、この場合、管理サーバ110のソフトウェア種類判定部603では、当該ソフトウェアの"許可要否"に関する情報を車両120に送信するものとする。そして、運転支援用ECU300のバージョン管理部321の告知部701及び制限部703は、更新要否判定手段による判定結果及び送信された"許可要否"に関する情報に基づいて動作することになる。つまり、更新及び許可が必要であった場合、告知部701では、更新の許可要請画面を表示し、更新許可の入力を受け付け、制限部703では、機能制限フラグをON状態にする。なお、制限部703の動作はこれに限られず、上記第2の実施形態のように、許可要請画面において更新許可の入力がなされなかった場合に、機能制限フラグをON状態にするようにしてもよい。
また、上記第1乃至第3の実施形態では、ソフトウェアDB113に新たに格納される最新バージョンのソフトウェアに、ユーザによる許可が必要なソフトウェアと、ユーザによる許可が不要なソフトウェアとが含まれるものとして説明した。しかしながら、ソフトウェアDB113に新たに格納される最新バージョンのソフトウェアは、いずれも、ユーザによる許可が必要なソフトウェアであってもよい。その場合、ソフトウェア種類判定部603の機能は不要となり、機能制限フラグ制御部604では、ソフトウェア取得部602により最新バージョンのソフトウェアが取得されソフトウェアDB113に格納されると、対象車両に対して、機能制限フラグのON指示を送信することになる。
また、上記第1乃至第3の実施形態では、車両120のインストール実行部702がソフトウェアの更新を完了した場合に、制限部703が機能制限フラグをOFF状態にする構成とした。しかしながら、制限部703は、管理サーバ110からの指示に基づいて、機能制限フラグをOFF状態にするように構成してもよい。具体的には、管理サーバ110の更新指示部606が車両120より更新完了通知を受信した場合に、機能制限フラグ制御部604が機能制限フラグのOFF指示を車両120に送信するように構成してもよい。これにより、車両120における機能制限フラグのON及びOFFは、管理サーバ110によって制御されることになる。
また、上記第1乃至第3の実施形態では、機能制限フラグのON状態とOFF状態とを制御する場合について説明したが、自動運転機能または運転支援機能の一部または全部の作動を制限するにあたっては、機能制限フラグを用いなくてもよい。
例えば、自動運転機能または運転支援機能に関するソフトウェアについて更新が必要と判定された場合であって、予め定められた複数の条件が同時に成立した場合に、自動運転機能または運転支援機能の一部または全部の作動を制限するようにしてもよい。予め定められた複数の条件には、例えば、ユーザにより更新が許可されなかったことが含まれていてもよい。なお、このとき、自動運転機能または運転支援機能に関するソフトウェアについての更新の要否の判定は、管理サーバ110側で行われても、車両120側で行われてもよい。同様に、予め定められた複数の条件が同時に成立したか否かの判定は、管理サーバ110側で行われても、車両120側で行われてもよい。
あるいは、自動運転機能または運転支援機能に関するソフトウェアについて更新が必要と判定され、管理サーバ110から車両120に対して機能制限の指示が送信された場合であって、車両120にて機能制限を開始すると判断した場合に、自動運転機能または運転支援機能の一部または全部の作動を制限するようにしてもよい。つまり、更新の要否の判定は、管理サーバ110側で行い、予め定められた複数の条件が同時に成立したか否かの判定は、管理サーバ110側で行われてもよい。
なお、上記実施形態に挙げた構成等に、その他の要素との組み合わせなど、ここで示した構成に本発明が限定されるものではない。これらの点に関しては、本発明の趣旨を逸脱しない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。