以下では、図1〜図12を参照しながら、本発明の実施形態を説明する。
(第1の実施形態)
図1は、本発明の第1の実施形態に係るソフトウェア更新システムの構成例を示す図である。図1に示すソフトウェア更新システムは、車両200に搭載された各種ECUのソフトウェアの更新を管理するものであり、サーバであるテレマティクスセンタ100と、車両200に搭載されたソフトウェア更新装置210とを備える。テレマティクスセンタ100とソフトウェア更新装置210とは、ネットワーク300および車両200に搭載された通信部220を介して互いに接続されている。この接続により、テレマティクスセンタ100とソフトウェア更新装置210の間で通信が可能となっている。ネットワーク300としては、例えば携帯電話網、インターネット網、無線LAN(Local Area Network)等の近距離無線通信、あるいはそれら複数の組み合わせで構成されたものなどが挙げられる。なお、図1では、ソフトウェア更新装置210を搭載した車両200を1台のみ図示しているが、こうした車両200は1台に限定するものではなく、複数台の車両200がソフトウェア更新装置210をそれぞれ搭載し、テレマティクスセンタ100と接続されても良い。
テレマティクスセンタ100は、ネットワーク300を介して、車両200に搭載されている様々な各種ECUのソフトウェアを更新するための更新ソフトウェアを車両200に配信する。テレマティクスセンタ100は、中央演算処理装置110と、記憶装置120と、入出力装置130と、通信部140とを備える。
中央演算処理装置110は、例えばCPU(Central Processing Unit)やRAM(Random Access Memory)などから構成され、所定の動作プログラムを実行することで、テレマティクスセンタ100の機能を実現する処理を行う。中央演算処理装置110は、その機能として、構成情報管理部111、更新案件管理部112、更新用ソフトウェア配信部113およびリカバリ用ソフトウェア配信部114を備える。
構成情報管理部111は、記憶装置120に格納されている後述の車両構成DB121、車種構成DB122、機能構成DB123の各情報を管理し、必要に応じて各情報の登録、変更、削除を行う。更新案件管理部112は、車両200の各ECUに対するソフトウェアの更新内容を示す更新案件の管理を行う。更新用ソフトウェア配信部113は、車両200からの要求に応じて、更新用ソフトウェアを車両200に配信する。リカバリ用ソフトウェア配信部114は、車両200に搭載されたいずれかのECUについてソフトウェアの更新に失敗した場合に、当該ECUのソフトウェアを更新前の状態に戻すためのリカバリ用ソフトウェアを車両200に配信する。なお、これらの各構成の動作については、後で詳しく説明する。
記憶装置120は、例えば、HDD(Hard Disk Drive)、SSD(Solid State Drive)、フラッシュメモリ、ROM(Read Only Memory)などから構成される。記憶装置120には、中央演算処理装置110が実行するプログラムや、プログラムの実行に必要なデータ群などが格納される。記憶装置120に格納されるデータ群には、車両構成DB121、車種構成DB122、機能構成DB123、更新案件管理DB124、進捗管理DB125などが含まれる。
車両構成DB121は、各車両200に搭載されているECUとソフトウェアのバージョンを管理するための情報である車両構成情報を蓄積する。車種構成DB122は、各車両200に搭載されているECUを車種単位で管理するための情報である車種構成情報を蓄積する。機能構成DB123は、各ECUが車両200の運用にどの様な影響を及ぼすかを管理するための情報である機能構成情報を蓄積する。更新案件管理DB124は、ECUのソフトウェア更新案件を管理するための情報を蓄積する。なお、更新案件管理DB124は、ソフトウェア更新案件の情報だけでなく、各車両200に配信するための更新用ソフトウェアも蓄積する。更新用ソフトウェアは、入出力装置130等を介して事前に登録されることで、更新案件管理DB124に蓄積される。進捗管理DB125は、実際に各車両200への更新用ソフトウェアの配信を開始してから、どの車両において既に更新が完了したかを管理するための情報を蓄積する。
入出力装置130は、タッチパネルやキーボード、マウスなどの組み合わせから構成され、入力部および表示部として機能する。
通信部140は、ネットワーク300で用いられる通信規格に準拠したネットワークカードなどから構成される。ネットワークカードは、有線LAN(Local Area Network)などの有線通信や無線LANなどの無線通信、あるいはその両方に必要な通信規格に準拠する。通信部140は、ネットワーク300を介して、車両200と各種プロトコルに基づきデータを送受信する。
車両200は、ソフトウェア更新装置210と、通信部220と、ナビゲーション端末230と、エンジンECU240と、ABSECU241と、ステアリングECU242と、サスペンションECU243と、エアバックECU244と、自動運転ECU245と、キーレスエントリECU246と、エアコン制御ECU247と、オーディオECU248とを備える。
エンジンECU240は、車両200のエンジン動作を管理する。ABSECU241は、車両200のABS(Antilock Brake System)を管理する。ステアリングECU242は、車両200のステアリング制御を管理する。サスペンションECU243は、車両200のサスペンション制御を管理する。エアバックECU244は、車両200のエアバックの動作制御を管理する。自動運転ECU245は、車両200の自動運転の動作制御を管理する。キーレスエントリECU246は、車両200のキーレスエントリの制御を管理する。エアコン制御ECU247は、車両200のエアコンを制御する。オーディオECU248は、車両200のオーディオ機器の動作を制御する。各機器は、CAN(Controller Area Network)などの車内ネットワークで接続される。また、図1に示す通り、上記の各ECUはその機能分担に応じてそれぞれ異なるバス型CANネットワークに接続されている。ソフトウェア更新装置210は、これらのバス型ネットワークのハブ機能を有している。
なお、車両200に搭載される、ソフトウェア更新が可能なECUは、図1に示したものに限定されない。例えば、ブレーキ制御用のECUや電子ミラー制御用のECUなど、車両200の制御や安全を支援する機能を持つECUが、図1に示した各ECU以外に車両200に搭載されていても良い。なお、各ECUには、自身を動作させるためのソフトウェアがそれぞれ内蔵されている。このソフトウェアは、各ECUが持つ記憶装置にそれぞれ格納されている。
ソフトウェア更新装置210は、中央演算処理装置211と、記憶装置215とを備える。
中央演算処理装置211は、例えばCPUやRAMなどから構成され、所定の動作プログラムを実行することで、ソフトウェア更新装置210の機能を実現する処理を行う。中央演算処理装置211は、その機能として、更新案件確認部212、更新用ソフトウェア要求部213およびECUソフトウェア更新部214を備える。
更新案件確認部212は、ソフトウェア更新が必要な案件があるか否かをテレマティクスセンタ100に問い合わせる。更新用ソフトウェア要求部213は、ソフトウェア更新案件があった場合に、更新用ソフトウェアやアップデート実行要件を更新データとしてテレマティクスセンタに要求する。ECUソフトウェア更新部214は、受信したソフトウェアおよびアップデート実行要件に基づいてECUのソフトウェアを更新し、その実行結果をテレマティクスセンタ100に送信する。
記憶装置215は、例えば、HDD、SSD、フラッシュメモリ、ROMなどから構成され、中央演算処理装置211が実行するプログラムや、プログラム実行に必要なデータ群などが格納される。さらに、記憶装置215には、テレマティクスセンタ100から配信された更新用ソフトウェアや、いずれかのECUについてソフトウェアの更新に失敗した場合にテレマティクスセンタ100から配信される前述のリカバリ用ソフトウェアなども格納される。
通信部220は、ネットワーク300で用いられる通信規格に準拠したネットワークカードなどから構成される。ネットワークカードは、例えば、無線LANなどの無線通信に準拠する。通信部220は、ネットワーク300を介して、テレマティクスセンタ100と各種プロトコルに基づきデータを送受信する。ここで、通信部220による通信は無線方式に限定される。そのため、例えば通信部220が携帯電話網を利用する場合には、車両200が地下駐車場に駐車している等の理由から通信部220が通信圏外になり、テレマティクスセンタ100と通信できない状況に陥る可能性がある。
ナビゲーション端末230は、中央演算処理装置231と、記憶装置233と、タッチパネルやキーボード、マウスなどの組み合わせからなる入出力装置234とを備える。
中央演算処理装置231は、例えばCPUやRAMなどから構成され、所定の動作プログラムを実行することで、ナビゲーション端末230の機能を実現する処理を行う。中央演算処理装置231は、その機能として、更新情報表示部232を備える。更新情報表示部232は、テレマティクスセンタ100から送信された更新情報に基づく表示を入出力装置234に対して行う。そして、入出力装置234を用いてユーザからソフトウェア更新を許諾する旨の入力が行われると、許諾情報を取得し、テレマティクスセンタ100に送信する。
記憶装置233は、例えば、HDD、SSD、フラッシュメモリ、ROMなどから構成され、中央演算処理装置231が実行するプログラムや、プログラム実行に必要なデータ群などが格納される。
なお、ソフトウェア更新装置210とナビゲーション端末230は同一の機器であっても良い。また、ナビゲーション端末230は車両200に搭載されるものではなく、例えばスマートフォンなどの携帯端末をナビゲーション端末230として用いても良い。この場合、通信部220は携帯端末側に存在し、ソフトウェア更新装置210は例えばOBD(On Board Diagnostics)などのコネクタを用いることで、携帯端末と通信することが考えられる。
図2は、本発明の第1の実施形態において、テレマティクスセンタ100の車両構成DB121、車種構成DB122、機能構成DB123にそれぞれ格納されるデータの構造を表すテーブルの一例を示す図である。
車両構成DB121には、VIN(Vehicle Identification Number)400、車種ID401、ECU種別402、ECUID403、ソフトウェアバージョン404の各データが格納される。VIN400は、車両200を一意に特定可能な識別子である。車種ID401は、そのVIN400を持つ車両200の車種を一意に特定可能な識別子である。ECU種別402は、そのVIN400を持つ車両200に搭載されるECUの種別を一意に特定可能な識別子である。ECUID403は、そのVIN400を持つ車両200に搭載されるECUを一意に特定可能な識別子である。ソフトウェアバージョン404は、ECUID403により特定されるECUに搭載されているソフトウェアのバージョン情報を一意に特定可能な識別子である。
車種構成DB122には、車種ID410、ECU種別411、ECUカテゴリ412、機能カテゴリ413、オフラインリカバリ機能414の各データが格納される。車種ID410は、車両構成DB121の車種ID401と共通のデータであり、各車両200の車種を一意に特定可能な識別子である。ECU種別411は、車両構成DB121のECU種別402と共通のデータであり、各車両200に搭載されるECUの種別を一意に特定可能な識別子である。ECUカテゴリ412は、ECU種別411により特定されるECUが属するカテゴリを示す情報である。機能カテゴリ413は、そのECUが車両200の制御において担う機能のカテゴリを示す情報である。オフラインリカバリ機能414は、そのECUがオフラインによるリカバリ方法をサポートしているか否かを示す情報である。
なお、車種構成DB122においてECUカテゴリ412は、図1に示したソフトウェア更新システムにおける車両200内の各ECUのネットワーク構成を反映している。すなわち、車両200に搭載されている各ECUは、前述のように、その機能分担に応じて互いに異なるバス型CANネットワークに接続されており、ソフトウェア更新装置210がそのハブ機能を有している。ECUカテゴリ412が表す各ECUのカテゴリは、そのバス型CANネットワーク単位で構成されている。一般的な車両では、ECU間の接続はこのようなネットワーク構成を有しており、各ネットワークに対してパワートレイン系やシャーシ系、セーフティ系などの名称が与えられている。ECUカテゴリ412は、このネットワーク形態に即して、車両200に搭載されているECUを複数のグループに分割して表している。
また、車種構成DB122において機能カテゴリ413は、各ECUが担う機能の重要度、すなわち各ECUの機能が車両200の運用に対してどの程度の影響を与えているかを表すものである。例えば、エンジンECU240が動作しなければ車両200を発進させることはできないが、エアコン制御ECU247が動作しなくても車両200は通常どおり走行することが可能であり、車両200の運用に対して直接的な影響はない。機能カテゴリ413は、このような車両200の制御に対する各ECUの機能の違いを表すものであり、必ずしもECUカテゴリ412とは一致しない形で、車両200に搭載されるECUを複数のグループに分割して表している。
なお、上記のECUカテゴリ412および機能カテゴリ413の分割方法は、図2に示したように5つのグループに分割するものに限らず、5つよりも少ない、あるいは多いグループに分割するものであっても良い。
機能構成DB123には、機能カテゴリ420、圏内移動可否421、速度制限422、機能制限423、ユーザ通知内容424の各データが格納される。機能カテゴリ420は、車種構成DB122の機能カテゴリ413と共通のデータであり、各ECUが担う機能の重要度を表している。圏内移動可否421は、機能カテゴリ420により特定されるカテゴリに属するECUが動作不能となった場合に、車両200を移動させることができるか否かを示す情報である。速度制限422は、そのECUが動作不能となった時に車両200の移動に速度制限を課すべきか否かを示す情報である。機能制限423は、そのECUが動作不能となった時に車両200に対して機能制限を課すべきか否かを示す情報である。ユーザ通知内容424は、そのECUが動作不能となった時にユーザに特別な通知をする場合のメッセージを表す情報である。
記憶装置120では、各車両200に対して、以上説明したような情報が車両構成DB121、車種構成DB122、機能構成DB123にそれぞれ格納されている。これらの情報は、構成情報管理部111において、更新用ソフトウェアの配信対象とするECUを特定するために用いられる。また前述のように、いずれかのECUについてソフトウェアの更新に失敗した場合の車両200の運用への影響を示している。
図3は、本発明の第1の実施形態において、テレマティクスセンタ100の更新案件管理DB124、進捗管理DB125にそれぞれ格納されるデータの構造を表すテーブルの一例を示す図である。
更新案件管理DB124には、更新案件ID500、ECUID501、更新ファイル名502、適用バージョン503の各データが格納される。更新案件ID500は、例えばリコールなど、複数の車両200を対象としたソフトウェアアップデートを要する案件を一意に特定可能な識別子である。ECUID501は、更新案件ID500により特定される更新案件がアップデート対象とするECUを一意に特定可能な識別子であり、車両構成DB121のECUID403に対応している。ファイル名502は、ECUID501により特定されるアップデート対象のECUに配布する更新用ソフトウェアのファイル名を示す情報である。適用バージョン503は、ファイル名502が示す更新用ソフトウェアを適用することでアップデートされた後のECUのソフトウェアバージョンを示す情報である。
進捗管理DB125には、更新案件ID510、VIN511、ステータス512、更新日時713、更新実行位置514の各データが格納される。更新案件ID510は、更新案件管理DB124の更新案件ID500と共通のデータである。VIN511は、更新案件ID510により特定される更新案件が対象とする車両200を一意に特定可能な識別子であり、車両構成DB121のVIN400に対応している。ステータス512は、更新案件ID510より特定される更新案件がVIN511により特定される車両200においてどの程度の進捗状況であるかを表す情報である。ステータス512は、例えば、更新用ソフトウェアのダウンロードが完了したか、ユーザからインストールの許諾を得たか(インストール中か)、インストールが完了したかなどの状態により、更新案件の進捗状況を管理している。更新日時713は、その更新案件のアップデートが完了した場合のアップデート実行日時を示す情報である。更新実行位置514は、その更新案件のアップデートを実行した時の車両200の位置情報を示す情報である。
なお、更新案件管理DB124の各データは、テレマティクスセンタ100が車両200に更新用ソフトウェアを配信する前に、テレマティクスセンタ100の管理者等によって入出力装置130を介して入力される。管理者としては、例えばテレマティクスセンタ100の運用者や、ECUの製造管理者などが考えられる。更新案件管理部112は、更新対象とするECUのIDや、アップデートに使用される更新用ソフトウェアのファイルおよびバージョン情報の入力を受け付けると、その更新案件に対するIDを新しく生成し、これらの入力情報に基づいて更新案件管理DB124に各データを蓄積する。その後、更新案件管理部112は、更新案件管理DB124のECUID501に蓄積されたのと同じ値のECUID403を持つ車両200を車両構成DB121から検索し、該当する車両200のVIN400の値を、更新案件ID500の値と共に、進捗管理DB125にVIN511、更新ID510としてそれぞれ蓄積する。
図4は、本発明の第1の実施形態において実行される更新用ソフトウェアのダウンロード処理の流れを示す図である。図4に示す処理は、車両200に搭載されているソフトウェア更新装置210の更新案件確認部212および更新用ソフトウェア要求部213と、テレマティクスセンタ100の更新案件管理部112および更新用ソフトウェア配信部113とにより行われる。
図4において、更新案件確認部212は、エンジンECU240からの情報を用いて車両200のエンジン始動を検知する(ステップS600)。ステップS600でエンジン始動を検知したら、更新案件確認部212は、まだ更新を完了していない更新案件が存在するか否かを確認するため、テレマティクスセンタ100に対して更新案件の問い合わせを行う(ステップS601)。この時、更新案件確認部212は、ソフトウェア更新装置210に接続されている車両200の全てのECUから、そのIDとソフトウェアバージョンの情報を収集する。そして、収集したこれらの情報と車両200のVINとに基づいて現在の車両200の構成を示す車両構成情報を生成し、テレマティクスセンタ100への問い合わせに付与して、通信部220から送信する。
ステップS601で車両200から送信された更新案件の問い合わせは、テレマティクスセンタ100において、通信部140により受信される(ステップS610)。ステップS610で更新案件の問い合わせを受信したら、テレマティクスセンタ100の更新案件管理部112は、まず始めに、問い合わせ元の車両200に対応する車両構成情報を更新する(ステップS611)。ここでは、更新案件管理部112は、ステップS610で更新案件の問い合わせと共に受信した車両構成情報が表す車両200のVINと同じ値のVIN400を持つレコードを車両構成DB121から検索する。そして、検索されたレコードに含まれるECUID403に関して、受信した車両構成情報のソフトウェアバージョンとソフトウェアバージョン404の値を比較し、これらの値が異なる場合には、該当レコードのソフトウェアバージョン404の値を、受信した車両構成情報のソフトウェアバージョンで上書きする。この時、もし車両200においてECUが追加されているのであれば、そのECUに対応するレコードを1つ追加しても良い。また、全てのレコードについて受信した車両構成情報のソフトウェアバージョンとソフトウェアバージョン404の値が一致する場合には、上書き処理を実行する必要はない。
更新案件管理部112は、次に、問い合わせ元の車両200に対する更新案件の有無を確認する(ステップS612)。ここでは、更新案件管理部112は、ステップS610で更新案件の問い合わせと共に受信した車両構成情報が表す車両200のVINが、進捗管理DB125のVIN511に登録されているか否かを確認することで、その車両200に対する更新案件の有無を確認する。ステップS612で更新案件の有無を確認できたら、更新案件管理部112は、その確認結果を通信部140から問い合わせ元の車両200に送信する(ステップS613)。
ステップS613でテレマティクスセンタ100から送信された更新案件の確認結果は、車両200のソフトウェア更新装置210において、通信部220により受信される(ステップS602)。ステップS602で更新案件の確認結果を受信したら、ソフトウェア更新装置210の更新案件確認部212は、その確認結果に基づき、更新案件の有無を判定する(ステップS603)。その結果、更新案件がないと判定した場合(S603:No)には、今回のエンジン始動に関してはダウンロードすべき更新用ソフトウェアは無いと判断し、図4の処理を終了する。
一方、更新案件があると判定した場合(S603:Yes)には、更新用ソフトウェア要求部213は、更新対象ECUに対する更新用ソフトウェアをテレマティクスセンタ100に要求する(ステップS604)。
ステップS604で車両200から送信された更新用ソフトウェアの要求は、テレマティクスセンタ100において、通信部140により受信される(ステップS614)。ステップS614で更新用ソフトウェアの要求を受信したら、テレマティクスセンタ100の更新用ソフトウェア配信部113は、対象とする更新案件の更新用ソフトウェアと、車両200のECU構成に応じた更新情報とを、通信部140から要求元の車両200に送信する(ステップS615)。ここでは、更新用ソフトウェア配信部113は、ステップS612と同様に、要求元の車両200のVINが進捗管理DB125のVIN511に登録されているか否かを再度確認し、該当レコードの更新案件ID510と同じ値が更新案件ID500に記録されているレコードを更新案件管理DB124から検索することで、ソフトウェアのアップデートに必要な更新用ソフトウェアのファイル名を示す更新ファイル名502を抽出する。さらに、要求元の車両200のVINと同じ値のVIN400を持つレコードを車両構成DB121から検索し、該当レコードの車種ID401と同じ値が車種ID410に記録されているレコードを車種構成DB122から検索すると共に、車種構成DB122の該当レコードの機能カテゴリ413と同じ値が機能カテゴリ420に記憶されているレコードを機能構成DB123から検索する。そして、車種構成DB122および機能構成DB123においてそれぞれ検索されたレコードの各データを抽出することで、要求元の車両200に対応する車種構成情報および機能構成情報を抽出し、これらをまとめることで、車両200のECU構成に応じた更新情報を生成する。この更新情報は、要求元の車両200に搭載されている各ECUについて、ソフトウェアの更新に失敗した場合の車両200の運用への影響を表すものである。こうして更新用ソフトウェアのファイル名を抽出すると共に車両200のECU構成に応じた更新情報を生成できたら、更新用ソフトウェア配信部113は、抽出したファイル名に対応する更新用ソフトウェアを更新案件管理DB124から抽出し、生成した更新情報と併せて、要求元の車両200に送信する。
なお、上記ステップS614において、更新用ソフトウェア配信部113は、更新用ソフトウェアのみを車両200に送信し、更新情報を送信しないようにしてもよい。その場合、車両200のECU構成に応じた更新情報は、予め車両200においてソフトウェア更新装置210の記憶装置215に記憶されていても良い。また、図4に示す処理とは別に、定期的に、または必要に応じて、テレマティクスセンタ100からソフトウェア更新装置210に更新情報を送信しても良い。
ステップS615でテレマティクスセンタ100から送信された更新用ソフトウェアと更新情報は、車両200のソフトウェア更新装置210において、通信部220により受信される(ステップS605)。ステップS605で更新用ソフトウェアと更新情報を受信したら、ソフトウェア更新装置210の更新用ソフトウェア要求部213は、これらのデータを記憶装置215に蓄積する(ステップS606)。その後、更新用ソフトウェア要求部213は、更新用ソフトウェアのダウンロードが完了したことをテレマティクスセンタ100に通知する(ステップS607)。
ステップS607で車両200から送信されたダウンロード完了の通知を受信したら、テレマティクスセンタ100の更新案件管理部112は、通知元の車両200のVINが登録されているレコードを進捗管理DB125から検索し、該当レコードのステータス512を更新する(ステップS616)。そして、通知元の車両200に対して、インストールを開始する指令を送信する(ステップS617)。
ステップS617でテレマティクスセンタ100から送信されたインストール開始指令は、車両200のソフトウェア更新装置210において、通信部220により受信される(ステップS608)。ステップS608でインストール開始指令を受信したら、ソフトウェア更新装置210の更新案件確認部212は、図4の処理を終了し、車両200のエンジンがオフ状態になるまで待機状態に入る。
以上説明した図4の処理により、テレマティクスセンタ100から車両200のソフトウェア更新装置210に対して、更新対象のECUのソフトウェアを更新するための更新用ソフトウェアと、そのECUのソフトウェアの更新に失敗した場合の車両200の運用への影響に関する更新情報とが配信される。
図5は、本発明の第1の実施形態において実行されるECUソフトウェア更新処理の流れを示す図である。図5に示す処理は、車両200に搭載されているソフトウェア更新装置210のECUソフトウェア更新部214およびナビゲーション端末230の更新情報表示部232と、テレマティクスセンタ100の更新案件管理部112とによって行われる。
図5において、ECUソフトウェア更新部214は、エンジンECU240からの情報を用いて車両200のエンジン停止を検知する(ステップS700)。ステップS700でエンジン停止を検知したら、ECUソフトウェア更新部214は、図4の処理によって更新用ソフトウェアをダウンロード済みの更新案件のうち、まだ更新を完了していない更新案件が存在するか否かを確認する(ステップS701)。その結果、未完了の更新案件がないと判定した場合(S701:No)には、今回のエンジン停止では実行すべきECUソフトウェア更新処理が存在しないため、図5の処理を終了する。
一方、未完了の更新案件が存在すると判定した場合(S701:Yes)には、更新情報表示部232は、入出力装置234を用いて、更新用ソフトウェアのインストールを開始する旨をユーザに通知する(ステップS702)。ここでは、更新情報表示部232は、図4のステップS605においてテレマティクスセンタ100からダウンロードされて記憶装置215に記憶された更新用ソフトウェアを参照することで、更新内容を確認する。そして、確認した更新内容をナビゲーション端末230の入出力装置234に出力して画面表示させることにより、ユーザへの更新通知を行う。さらにこの時、更新を許諾するか否かの選択肢を併せて画面表示し、入出力装置234においていずれかの選択肢をユーザに選択させる。
ステップS702でユーザへの更新通知を行ったら、ECUソフトウェア更新部214は、入出力装置234に対するユーザの入力操作に基づき、更新の許諾が得られたか否かを判定する(ステップS703)。その結果、ユーザから更新の許諾が得られなかった場合(S703:No)には、ECUソフトウェア更新部214は、その旨をテレマティクスセンタ100に通知し(ステップS706)、次に車両200のエンジンがオフ状態になるまで待機状態に入る。この通知を車両200から受信したら、テレマティクスセンタ100の更新案件管理部112は、通知元の車両200のVINが登録されているレコードを進捗管理DB125から検索し、該当レコードのステータス512を「ユーザ許諾取得待ち」に更新する(ステップS711)。これ以降では、ユーザから更新の許諾を得られるまで、図5の処理が繰り返される。
一方、ユーザから更新の許諾が得られた場合(S703:Yes)には、ECUソフトウェア更新部214は、テレマティクスセンタ100に対して、ダウンロード済みの更新用ファイルを用いたEUCソフトウェアのアップデートを開始することを通知する(ステップS704)。このアップデート開始通知を受信したら、テレマティクスセンタ100の更新案件管理部112は、通知元の車両200のVINが登録されているレコードを進捗管理DB125から検索し、該当レコードのステータス512を「アップデート開始」に更新する(ステップS710)。
ステップS704でアップデート開始通知を行ったら、ECUソフトウェア更新部214は、図4で説明した更新用ソフトウェアのダウンロード処理においてテレマティクスセンタ100からダウンロードされて記憶装置215に記憶された更新用ソフトウェアを用いて、更新対象のECUソフトウェアのアップデートを実行する(ステップS705)。そして、アップデート実行結果をテレマティクスセンタ100に通知し(ステップS706)、次に車両200のエンジンがオフ状態になるまで待機状態に入る。この通知を車両200から受信したら、テレマティクスセンタ100の更新案件管理部112は、通知元の車両200のVINが登録されているレコードを進捗管理DB125から検索し、該当レコードのステータス512を更新する(ステップS711)。この時、アップデート実行結果が正常である旨の通知を受けた場合には、該当レコードのステータス512を「アップデート正常完了」に更新し、そうでない場合には、該当レコードのステータス512を「アップデート失敗」に更新する。
以上説明した図5の処理により、ダウンロード済みの更新用ソフトウェアを用いて、更新対象のECUのソフトウェアが更新される。
なお、車両200の状態によっては、前述のように通信部220が通信圏外となり、ソフトウェア更新装置210とテレマティクスセンタ100の間で通信が不可能となる場合がある。このような場合には、テレマティクスセンタ100において、ステップS704のアップデート開始通知や、ステップS706のアップデート実行結果の通知を、ソフトウェア更新装置210から受けることができない。その結果、テレマティクスセンタ100の更新案件管理部112は、ステップS710やステップS711の処理を実行できない。したがって、ソフトウェア更新装置210からの通知が得られない場合には、更新案件管理部112は、車両200が通信可能な状態となるまでステップS710やステップS711の処理を保留し、通信可能な状態となった時にこれらの処理を実行するようにしても良い。
次に、車両200においてECUソフトウェアの更新に失敗した場合に実行されるリカバリ処理について説明する。図6および図7は、本発明の第1の実施形態において実行されるリカバリ処理の流れを示す図である。図6および図7に示す処理は、車両200に搭載されているソフトウェア更新装置210のECUソフトウェア更新部214およびナビゲーション端末230の更新情報表示部232と、テレマティクスセンタ100の更新案件管理部112およびリカバリ用ソフトウェア配信部114とにより行われる。
図6において、ECUソフトウェア更新部214は、エンジンECU240からの情報を用いて車両200のエンジン始動を検知する(ステップS800)。ステップS800でエンジン始動を検知したら、ECUソフトウェア更新部214は、前回(直前)の車両200のエンジン停止時に、図5で説明したECUソフトウェア更新処理を実行したか否かを確認する(ステップS801)。その結果、ECUソフトウェア更新処理を実行していなかった場合(S801:No)には、図6および図7の処理を終了する。なお、この後に図4に示す処理を行っても良い。
一方、ECUソフトウェア更新処理を実行していた場合(S801:Yes)には、ECUソフトウェア更新部214は、その処理結果が失敗であったか否かを確認する(ステップS802)。その結果、前回のECUソフトウェア更新処理に失敗していた場合(S802:Yes)、すなわち、直前のエンジン停止時に更新対象のECUのソフトウェアを正常に更新できていなかった場合には、処理をステップS803に進める。一方、前回のECUソフトウェア更新処理に成功していた場合(S802:No)、すなわち、直前のエンジン停止時に更新対象のECUのソフトウェアを正常に更新できていた場合には、処理を図7のステップS905に進める。
ステップS803において、ECUソフトウェア更新部214は、ソフトウェアの更新に失敗したECUが自力でのリカバリを実行不可能なものであるか否かを判定する。ここでは、ECUソフトウェア更新部214は、図4のステップS605においてテレマティクスセンタ100からダウンロードされて記憶装置215に記憶された更新情報に基づいて、ステップS803の判定を行う。具体的には、当該ECUのECU種別を検索キーとして、更新情報に含まれる車種構成情報の中から、当該ECUに対応するオフラインリカバリ機能414を検索し、その内容を確認することで、当該ECUが自力でのリカバリを実行不可能なものであるか否かを判定する。その結果、当該ECUに対応するオフラインリカバリ機能414の内容が「True」である場合には、当該ECUは自力でのリカバリを実行可能であると判定し(ステップS803:No)、処理をステップS804に進める。一方、当該ECUに対応するオフラインリカバリ機能414の内容が「False」である場合には、当該ECUは自力でのリカバリを実行できないと判定し(ステップS803:Yes)、処理をステップS805に進める。
ステップS804において、ECUソフトウェア更新部214は、当該ECUに対してオフラインでの自力によるリカバリを実行すると決定する。この決定の後、ECUソフトウェア更新部214は、処理を図7のステップS903に進める。
ステップS805において、ECUソフトウェア更新部214は、車両200に搭載されている通信部220が通信圏外であるか否か、すなわちソフトウェア更新装置210とテレマティクスセンタ100とが通信不可能な状態であるか否かを判定する。その結果、通信部220が通信圏内であり、ソフトウェア更新装置210とテレマティクスセンタ100とが通信可能である場合(ステップS805:No)には、処理をステップS806に進める。一方、通信部220が通信圏外であり、ソフトウェア更新装置210とテレマティクスセンタ100とが通信不可能な場合(ステップS805:Yes)には、処理をステップS807に進める。
ステップS806において、ECUソフトウェア更新部214は、当該ECUに対してオンラインでのリカバリを実行すると決定する。この決定の後、ECUソフトウェア更新部214は、処理を図7のステップS901に進める。
ステップS807において、ECUソフトウェア更新部214は、車両200を通信圏内に移動させることで、ソフトウェアの更新に失敗したECUのオンラインでのリカバリが実行可能であるか否かを判定する。ここでは、ECUソフトウェア更新部214は、図4のステップS605においてテレマティクスセンタ100からダウンロードされて記憶装置215に記憶された更新情報に基づいて、ステップS807の判定を行う。具体的には、当該ECUのECU種別を検索キーとして、更新情報に含まれる車種構成情報の中から、当該ECUに対応する機能カテゴリ413を検索し、その内容を確認することで、当該ECUが属する機能カテゴリを特定する。そして、特定した機能カテゴリを検索キーとして、更新情報に含まれる機能構成情報の中から、当該ECUに対応する圏内移動可否421を検索し、その内容を確認することで、当該ECUを使用せずに車両200を通信圏内に移動させることが可能か否かを判定する。その結果、当該ECUに対応する圏内移動可否421の内容が「False」である場合には、当該ECUを使用せずに車両200を通信圏内に移動させることは不可能であると判定し(ステップS807:No)、処理をステップS808に進める。一方、当該ECUに対応する圏内移動可否421の内容が「True」である場合には、当該ECUを使用せずに車両200を通信圏内に移動させることが可能であると判定し(ステップS807:Yes)、処理をステップS809に進める。
ステップS808において、ECUソフトウェア更新部214は、車両200が走行不可能であり、車両200を通信圏内に移動させることができないため、当該ECUのリカバリを断念すると決定する。この決定の後、ECUソフトウェア更新部214は、処理を図7のステップS905に進める。
ステップS809において、ECUソフトウェア更新部214は、車両200を通信圏内に移動させるようにユーザに促す。ここでは、ECUソフトウェア更新部214は、ナビゲーション端末230の更新情報表示部232および入出力装置234を用いて、ユーザへの通知を行う。具体的には、更新情報表示部232の制御に応じた入出力装置234の画像表示や音声により、ソフトウェア更新装置210がテレマティクスセンタ100と通信可能な位置まで車両200を移動すべき旨のメッセージを出力することで、車両200の通信圏内への移動をユーザに促す。さらにこの時、ECUソフトウェア更新部214は、図4のステップS605においてテレマティクスセンタ100からダウンロードされて記憶装置215に記憶された更新情報に基づいて、移動中の車両200の運用に対する制限の有無を判断し、制限があると判断した場合はその内容をユーザに通知する。具体的には、ステップS807において特定した機能カテゴリを検索キーとして、更新情報に含まれる機能構成情報の中から、当該ECUに対応する速度制限422、機能制限423およびユーザ通知内容424を検索する。そして、検索されたこれらのデータ内容に基づいて、移動中の車両200の運用に対する速度制限や機能制限の有無を確認すると共に、ユーザへの通知内容を確認し、更新情報表示部232の制御に応じた入出力装置234の画像表示や音声により、ユーザへの通知を行う。これらの通知を行ったら、ECUソフトウェア更新部214は、車両200が通信圏内に移動されるまで待機し、処理を図7のステップS900に進める。
図7のステップS900において、ECUソフトウェア更新部214は、車両200に搭載されている通信部220が通信圏内になったか否かを定期的に確認する。
通信部220が通信圏内になった場合(S900:Yes)、または、図6のステップS806においてオンラインでのリカバリを実行すると決定した場合には、ECUソフトウェア更新部214は、対象ECUのソフトウェアをリカバリするためのリカバリ用ソフトウェアをテレマティクスセンタ100に要求する(ステップS901)。この要求を受信したら、テレマティクスセンタ100の更新案件管理部112は、通知元の車両200のVINが登録されているレコードを進捗管理DB125から検索し、該当レコードのステータス512を「リカバリ中」に更新する(ステップS910)。そして、更新案件管理DB124からアップデート前のソフトウェアデータなど、当該ECUのソフトウェアを更新前の状態に戻すためのデータを抽出し、それをリカバリ用ソフトウェアとして車両200に送信する(ステップS911)。
ステップS911でテレマティクスセンタ100から送信されたリカバリ用ソフトウェアは、車両200のソフトウェア更新装置210において、通信部220により受信される(ステップS902)。ステップS902でリカバリ用ソフトウェアを受信したら、ソフトウェア更新装置210のECUソフトウェア更新部214は、受信したリカバリ用ソフトウェアを用いて、ソフトウェアの更新に失敗したECUのリカバリ処理を実行する(ステップS903)。そして、そのリカバリ結果をテレマティクスセンタ100に通知する(ステップS904)。
車両200のソフトウェア更新装置210からリカバリ結果の通知を受信したら、テレマティクスセンタ100の更新案件管理部112は、通知元の車両200のVINが登録されているレコードを進捗管理DB125から検索し、該当レコードのステータス512を「リカバリ完了」に更新する(ステップS912)。
ステップS904でリカバリ結果の通知を行ったら、ECUソフトウェア更新部214は、ナビゲーション端末230の更新情報表示部232および入出力装置234を用いて、そのリカバリ結果をユーザに通知するための画面表示を行う(ステップS905)。ここでは、ステップS903で実行したリカバリ処理の結果が成功または失敗のいずれであったかを示す画面が、入出力装置234において表示される。なお、リカバリ結果が失敗であった場合、車両200が速度制限あるいは機能制限の下でしか移動できない状態が続き、車両200の運用に対して制約が生じる。したがって、このような場合には、ユーザが最寄りの車両200のディーラーにおいて根本的なリカバリ処理を施すことができるように、例えばディーラーの連絡先や、ディーラーまでのルートを入出力装置234に表示しても良い。また、図6および図7に示すリカバリ処理の終了後に、図4で説明した更新用ソフトウェアのダウンロード処理を実行することで、テレマティクスセンタ100に車両構成情報を送信して更新案件の確認を行っても良い。
なお、図6のステップS808においてリカバリを断念すると決定した場合には、ステップS905において、ECUソフトウェア更新部214は、リカバリを断念したことをユーザに通知するための画面表示を行う。この場合、車両200は走行不能であり、ユーザが車両200を利用できない状態が続いてしまうことから、ユーザが最寄りの車両200のディーラーに連絡して根本的なリカバリ処理を施すことができるように、例えばディーラーの連絡先を入出力装置234に表示しても良い。
なお、図6のステップS804においてオフラインでの自力によるリカバリを実行すると決定した場合には、ステップS903において、ECUソフトウェア更新部214は、リカバリ用ファイルを用いずに、オフラインでステップS903のリカバリ処理を実行する。このリカバリ処理に失敗した場合には、図6のステップS805に戻って通信部220が通信圏外であるか否かを確認することで、オンラインでのリカバリの実行可否を確認し、実行可能であればステップS806以降の処理を実行するようにしても良い。
また、図7のステップS900において、一定時間以上経過しても通信部220が通信圏内にならない場合には、ECUソフトウェア更新部214は、図6および図7に示す処理を終了しても良い。その場合、処理終了前に、上記のリカバリ結果が失敗であった場合と同様に、ユーザが最寄りの車両200のディーラーにおいて根本的なリカバリ処理を施すことができるように、例えばディーラーの連絡先や、ディーラーまでのルートを入出力装置234に表示しても良い。
以上説明した図6および図7の処理により、車両200においてECUソフトウェアの更新に失敗した場合には、テレマティクスセンタ100からダウンロードされて記憶装置215に記憶された更新情報に基づいて、リカバリ処理の内容が決定される。これにより、リカバリ処理におけるECUソフトウェア更新部214の動作が制御される。
図8は、本発明の第1の実施形態においてテレマティクスセンタ100の入出力装置130に表示される画面の一例を示す図である。入出力装置130には、車両200に搭載された複数のECUがそれぞれ属する機能カテゴリを示す画面として、例えば図8に示すような画面が表示される。
図8の画面は、符号1000、1010、1020にそれぞれ示す画面領域により構成されている。画面領域1000は、車種構成DB122の情報を可視化して示したものである。画面領域1000では、車種構成DB122における車種ID410、ECU種別411およびECUカテゴリ412の各情報に基づいて、車両200に搭載された全てのECUの種別とカテゴリがツリー形状の図を用いて車種単位で表されている。画面領域1010、1020は、画面領域1000で選択されたいずれかのECU(図8の例では、自動運転ECU245)について、車種構成DB122、機能構成DB123にそれぞれ記録された情報を可視化して示したものである。画面領域1010では、当該ECUに対応する車種構成DB122のECU種別411、ECUカテゴリ412、機能カテゴリ413およびオフラインリカバリ機能414の各情報の内容が表されている。画面領域1020では、当該ECUに対応する機能構成DB123の機能カテゴリ420、圏内移動可否421、速度制限422、機能制限423、ユーザ通知内容424の各情報の内容が表されている。なお、画面領域1010、1020では、テレマティクスセンタ100の管理者が入出力装置130を介して任意の情報を上書きすることで、車種構成DB122や機能構成DB123の内容を変更することもできる。
図9は、本発明の第1の実施形態において車両200に搭載されたナビゲーション端末230の入出力装置234に表示される画面の一例を示す図である。
図9において、画面1100は、図6のステップS809において、車両200を通信圏内に移動させるようにユーザを促すために、入出力装置234に表示される画面の一例である。画面1100は、符号1101、1102、1103にそれぞれ示す画面領域により構成されている。画面領域1101は、通信部220が現在通信圏外であり、オンラインでのECUソフトウェアのリカバリを行うためには車両200を通信圏内に移動させることが必要である旨を示す領域である。画面領域1102は、通信部220の電波状況を示す領域である。画面領域1103は、車両200の機能制限の状態を示す領域である。画面1100では、これらの画面領域により、例えば自動運転ECU245がソフトウェア更新に失敗し、車両200は通信圏外のエリアにいる状況を示している。この場合、自動運転ECU245のソフトウェア更新に失敗したため、車両200において自動運転機能が強制的にオフとなるが、手動による運転には影響が無い。そのため、画面1100を表示することで、ユーザに手動で車両200を通信圏内エリアに移動するように促している。
図9において、画面1110は、図7のステップS900において通信部220が通信圏内になったことを検知した際に、入出力装置234に表示される画面の一例である。画面1110では、テレマティクスセンタ100と通信を行うことで、オンラインでの自動運転ECU245のソフトウェアのリカバリを開始することをユーザに通知するメッセージが表示されている。
図9において、画面1120は、ECUソフトウェアのリカバリに成功した際に、図7のステップS905において入出力装置234に表示される画面の一例である。画面1120では、自動運転ECU245のソフトウェアのリカバリに成功したことをユーザに通知するメッセージが表示されている。
なお、図9に示した画面例では、自動運転ECU245のソフトウェアをリカバリする場合の例を示しているが、リカバリ対象とするECUに応じて画面の表示内容を変化させてもよい。
以上説明した本発明の第1の実施形態によれば、以下の作用効果を奏する。
(1)本実施形態のソフトウェア更新システムは、車両200に搭載された車載機器であるECUのソフトウェアの更新を管理するものであり、車両200に搭載されたソフトウェア更新装置210と、ソフトウェア更新装置210とネットワーク300を介して通信を行うテレマティクスセンタ100とを備える。テレマティクスセンタ100は、ECUのソフトウェアを更新するための更新用ソフトウェアをソフトウェア更新装置210に配信する更新用ソフトウェア配信部113を有する。ソフトウェア更新装置210は、テレマティクスセンタ100から配信された更新用ソフトウェアを記憶すると共に、ECUのソフトウェアの更新に失敗した場合の車両200の運用への影響に関する更新情報を記憶する記憶装置215と、記憶装置215に記憶された更新用ソフトウェアを用いてECUのソフトウェアを更新するECUソフトウェア更新部214と、を有し、記憶装置215に記憶された更新情報に基づいてECUソフトウェア更新部214の動作を制御する。このようにしたので、ユーザにとって利用しやすいOTAによる車載機器のソフトウェアの更新を実現することができる。
(2)ソフトウェア更新装置210のECUソフトウェア更新部214は、更新情報に基づいて、ECUのソフトウェアの更新に失敗した場合に行うリカバリ処理の内容を決定する(ステップS803〜809)。このようにしたので、リカバリ処理の内容を適切に決定することができる。
(3)テレマティクスセンタ100は、ECUのソフトウェアを更新前の状態に戻すためのリカバリ用ソフトウェアをソフトウェア更新装置210に配信するリカバリ用ソフトウェア配信部114を有する。ソフトウェア更新装置210のECUソフトウェア更新部214は、ソフトウェア更新装置210がテレマティクスセンタ100と通信可能である場合(ステップS805:No)には、リカバリ処理において、テレマティクスセンタ100にリカバリ用ソフトウェアの配信を要求する(ステップS901)。一方、ソフトウェア更新装置210がテレマティクスセンタ100と通信不可能である場合(ステップS805:Yes)には、リカバリ処理において、更新情報に基づいて車両200の移動可否を判定する(ステップS807)。その結果、車両200の移動が可能であれば、ソフトウェア更新装置210がテレマティクスセンタ100と通信可能な位置まで車両200を移動するようユーザに促して(ステップS809)、ソフトウェア更新装置210がテレマティクスセンタ100と通信可能になったら(ステップS900:Yes)、テレマティクスセンタ100にリカバリ用ソフトウェアの配信を要求する(ステップS901)。このようにしたので、車両200の位置が原因で、ソフトウェア更新装置210がテレマティクスセンタ100と通信可能ではない場合であっても、ユーザに車両200を移動させてオンラインでのリカバリ処理を実現することができる。
(4)ECUソフトウェア更新部214は、ステップS809において車両200の移動をユーザに促す際に、更新情報に基づいて車両200の運用に対する制限の有無を判断し、制限があると判断した場合は、図9の画面1100に例示したように、その内容をユーザに通知する。このようにしたので、リカバリ対象のECUを使用できないために車両200の運用に対して制限がある場合でも、ユーザに車両200を安全に移動させることができる。
(5)テレマティクスセンタ100の更新用ソフトウェア配信部113は、更新用ソフトウェアと共に更新情報をソフトウェア更新装置210に配信する(ステップS615)。ソフトウェア更新装置210の記憶装置215は、テレマティクスセンタ100から配信された更新用ソフトウェアおよび更新情報を記憶する(ステップS606)。このようにしたので、車両200のECU構成に応じた更新情報を記憶装置215に記憶させることができる。
(6)車両200に搭載された複数のECUは、車両200の運用への影響度合いに応じて、例えば機能カテゴリC1〜C5のように、複数の機能カテゴリにグループ分けされている。更新情報は、車両200に搭載された複数のECUがそれぞれ複数の機能カテゴリのいずれに属するかを表す情報である、機能カテゴリ413の情報を含む。このようにしたので、更新情報において各ECUの車両200の運用への影響度合いを分かりやすく示すことができる。
(7)テレマティクスセンタ100は、車両200に搭載された複数のECUがそれぞれ属する機能カテゴリを画面表示する表示装置として、図8に例示したような画面を表示する入出力装置130を有する。このようにしたので、各ECUの機能をテレマティクスセンタ100の管理者に分かりやすく提示することができる。
(第2の実施形態)
第1の実施形態では、車両200のエンジンが停止している状態、すなわち車両200が利用されていない状態で、更新対象とするECUのソフトウェアを更新する例を説明した。これに対して、第2の実施形態では、車両200が走行中であっても、可能であれば更新対象とするECUのソフトウェアを更新する例を説明する。なお、第2の実施形態におけるソフトウェア更新システムの構成や、更新用ソフトウェアのダウンロード処理に関しては、第1の実施形態において図1〜図4で説明したものと同様である。そのため、以下ではこれらに関する説明は省略する。
図10は、本発明の第2の実施形態において実行されるECUソフトウェア更新処理の流れを示す図である。図10に示す処理は、車両200に搭載されているソフトウェア更新装置210のECUソフトウェア更新部214およびナビゲーション端末230の更新情報表示部232と、テレマティクスセンタ100の更新案件管理部112とによって行われる。なお、本実施形態では、第1の実施形態において図5で説明した処理の代わりに、図10の処理が実行される。
図10において、ECUソフトウェア更新部214は、テレマティクスセンタ100からインストール開始指令を受領したら、車両200のエンジンが停止されるまで待機せずに、即座にステップS1200の判定を行う。ステップS1200では、ECUソフトウェア更新部214は、更新対象のECUソフトウェアが車両200の走行中に更新可能であるか否かを判定する。この判定は、第1の実施形態で説明した図6のステップS807と同様の方法により行うことができる。すなわち、更新情報に含まれる機能構成情報のうち、当該ECUが属する機能カテゴリの圏内移動可否421の内容を確認することで、当該ECUを使用せずに車両200を走行させることが可能か否かを判定する。その結果、当該ECUに対応する圏内移動可否421の内容が「False」である場合には、当該ECUを使用せずに車両200を走行させることは不可能であると判定し(ステップS1200:No)、図10の処理を終了する。この場合、第1の実施形態と同様に、エンジン停止後に当該ECUのソフトウェア更新を試みる。一方、当該ECUに対応する圏内移動可否421の内容が「True」である場合には、当該ECUを使用せずに車両200を走行させることが可能であると判定し(ステップS1200:Yes)、処理をステップS1201に進める。
ステップS1201において、更新情報表示部232は、入出力装置234を用いて、更新用ソフトウェアのインストールを開始する旨をユーザに通知する。さらにこの時、更新情報表示部232は、第1の実施形態で説明した図6のステップS809と同様に、記憶装置215に記憶された更新情報に基づいて、走行中の車両200の運用に対する制限の有無を判断し、制限があると判断した場合はその内容をユーザに通知する。すなわち、更新情報に含まれる機能構成情報のうち、当該ECUに対応する速度制限422、機能制限423およびユーザ通知内容424の内容に基づいて、走行中の車両200の運用に対する速度制限や機能制限の有無を確認すると共に、ユーザへの通知内容を確認し、更新情報表示部232の制御に応じた入出力装置234の画像表示や音声により、ユーザへの通知を行う。また、図7のステップS702と同様に、更新を許諾するか否かの選択肢を併せて画面表示し、入出力装置234においていずれかの選択肢をユーザに選択させる。
ステップS1201でユーザへの更新通知を行ったら、ECUソフトウェア更新部214は、入出力装置234に対するユーザの入力操作に基づき、更新の許諾が得られたか否かを判定する(ステップS1202)。その結果、ユーザから更新の許諾が得られなかった場合(S1202:No)には、ECUソフトウェア更新部214は、その旨をテレマティクスセンタ100に通知し(ステップS1205)、次に車両200のエンジンがオフ状態になるまで待機状態に入る。この通知を車両200から受信したら、テレマティクスセンタ100の更新案件管理部112は、通知元の車両200のVINが登録されているレコードを進捗管理DB125から検索し、該当レコードのステータス512を「ユーザ許諾取得待ち」に更新する(ステップS1211)。これ以降では、ユーザから更新の許諾を得られるまで、図10の処理が繰り返される。
一方、ユーザから更新の許諾が得られた場合(S1202:Yes)には、ECUソフトウェア更新部214は、テレマティクスセンタ100に対して、ダウンロード済みの更新用ファイルを用いたEUCソフトウェアのアップデートを開始することを通知する(ステップS1203。このアップデート開始通知を受信したら、テレマティクスセンタ100の更新案件管理部112は、通知元の車両200のVINが登録されているレコードを進捗管理DB125から検索し、該当レコードのステータス512を「アップデート開始」に更新する(ステップS1210)。
ステップS1203でアップデート開始通知を行ったら、ECUソフトウェア更新部214は、テレマティクスセンタ100からダウンロードされて記憶装置215に記憶された更新用ソフトウェアを用いて、更新対象のECUソフトウェアのアップデートを実行する(ステップS1204)。この時、車両200が走行中であるか否かに関わらず、ステップS1204のアップデート処理を実行する。そして、アップデート実行結果をテレマティクスセンタ100に通知する(ステップS1205)。この通知を車両200から受信したら、テレマティクスセンタ100の更新案件管理部112は、通知元の車両200のVINが登録されているレコードを進捗管理DB125から検索し、該当レコードのステータス512を更新する(ステップS1211)。この時、アップデート実行結果が正常である旨の通知を受けた場合には、該当レコードのステータス512を「アップデート正常完了」に更新し、そうでない場合には、該当レコードのステータス512を「アップデート失敗」に更新する。なお、アップデートに失敗した場合には、第1の実施形態において図6および図7で説明したリカバリ処理を実行しても良い。
以上説明した図10の処理により、車両200が走行中であっても、更新対象のECUソフトウェアが車両200の走行に対して影響のないものであれば、ユーザの承諾を得た上で、ダウンロード済みの更新用ソフトウェアを用いて当該ECUソフトウェアの更新を実行することができる。
以上説明した本発明の第2の実施形態によれば、ソフトウェア更新装置210のECUソフトウェア更新部214は、記憶装置215に記憶されている更新情報に基づいて、ECUのソフトウェアの更新中に車両200が移動可能であるか否かを判定する(ステップS1200)。その結果、車両200の移動が可能であると判定した場合(ステップS1200:Yes)は、車両200の走行中にECUのソフトウェアを更新する(ステップS1204)。このようにしたので、車両200の走行中にECUのソフトウェアを更新することができる。
(第3の実施形態)
第1の実施形態では、車両200からの問い合わせに応じて、車両200のVINが進捗管理DB125のVIN511に登録されているか否かを確認し、その確認結果を車両200に通知することで、テレマティクスセンタ100の処理負荷を考慮せずに更新案件の有無を通知する例を説明した。これに対して、第3の実施形態では、テレマティクスセンタ100の処理負荷を考慮して、更新案件の有無を通知する例を説明する。なお、第3の実施形態におけるソフトウェア更新システムの構成に関しては、第1の実施形態において図1〜図3で説明したものと同様である。そのため、以下ではこれらに関する説明は省略する。
図11は、本発明の第3の実施形態において実行される更新案件確認処理の流れを示す図である。図11に示す処理は、テレマティクスセンタ100の更新案件管理部112によって行われる。なお、本実施形態では、第1の実施形態で説明した更新用ソフトウェアのダウンロード処理において、図4のステップS612の処理の代わりに、図11の処理が実行される。
図11において、更新案件管理部112は、図4のステップS612と同様の方法により、問い合わせ元の車両200に対する更新案件の有無を確認する(ステップS1301)。次に、更新案件管理部112は、ステップS1301の確認結果に基づき、更新案件が存在したか否かを判定する(ステップS1302)。その結果、更新案件が存在しない場合(S1302:No)には、処理をステップS1310に進める。
一方、更新案件が存在する場合(S1302:Yes)には、更新案件管理部112は、更新情報に含まれる車種構成情報のうち、その更新案件で更新対象とされるECUに対応する機能カテゴリ413の内容に基づいて、当該ECUの機能カテゴリを確認する(ステップS1303)。なお以降では、ステップS1303で確認された当該ECUの機能カテゴリを、機能カテゴリCxと表記する。すなわち、図2で示した車種構成DB122および機能構成DB123の例では、機能カテゴリCxにおけるxの値は、1〜5のいずれかである。本実施形態では、この機能カテゴリCxにおけるxの値を当該ECUのソフトウェア更新の優先度と見なして、以降の処理を実行する。すなわち、図2の例では、例えば機能カテゴリがC1であるエンジンECU240やステアリングECU242については、ソフトウェア更新の優先度が1であり、機能カテゴリがC5であるオーディオECU248については、ソフトウェア更新の優先度が5であると見なす。このようにして、車両200に搭載された複数のECUがそれぞれ属する機能カテゴリに基づいて、各ECUのソフトウェアの更新に対する優先度を設定することができる。この場合、優先度の数値が小さいほど、当該ECUのソフトウェア更新の優先度が高いことを示している。
次に、更新案件管理部112は、進捗管理DB125に登録されている全ての車両200について、ステータス512を検索し、進捗状況がダウンロード未完了である更新案件のレコード、すなわちステータス512が「ダウンロード完了」やそれ以降の状態ではないレコードを抽出する(ステップS1304)。そして、抽出した各レコードの更新案件ID510から、更新案件管理DB124、車両構成DB121、車種構成DB122の順に検索して機能カテゴリ413を抽出することで、ダウンロード未完了の更新案件に対応する各ECUの機能カテゴリを求める。こうして求めた各ECUの機能カテゴリに基づき、機能カテゴリC1〜C5のそれぞれについてダウンロード未完了の更新案件の数をカウントする(ステップS1305)。そして、ダウンロード未完了の更新案件の全数に対して機能カテゴリC1〜C5の各カウント数が占める割合をそれぞれ算出する(ステップS1306)。こうして算出された機能カテゴリごとのカウント数の割合は、当該機能カテゴリに属する各ECUの更新用ソフトウェアの配信に要するテレマティクスセンタ100の処理負荷に相当するものである。すなわち、更新案件管理部112において上記ステップS1304〜S1306の処理を実行することで、更新用ソフトウェアの配信に要するテレマティクスセンタ100の処理負荷を、ECUの機能カテゴリごとに算出することができる。
続いて、更新案件管理部112は、ステップS1306で算出した各機能カテゴリのカウント数の割合に基づき、ステップS1303で抽出した更新対象のECUが属する機能カテゴリCxと同じか、それより高い優先度を有する機能カテゴリのカウント数の合計割合(A%)を算出する(ステップS1307)。ここでは例えば、ステップS1306で算出したカウント数の割合が、C1からC5の順に、24%、12%、28%、20%、16%であり、更新対象のECUの機能カテゴリがC3であった場合は、C1、C2、C3のカウント数の割合を合計することで、A=24+12+28=64%と計算される。これにより、進捗管理DB125に登録されている全ての車両200に搭載されている各ECUの優先度すなわち機能カテゴリに基づいて、ステップS1301で確認した更新案件で対象とされたECUと、更新用ソフトウェアのダウンロードが未完了で当該優先度と同じかより高い優先度を有するECUとを、テレマティクスセンタ100の処理負荷の算出対象として特定することができる。そして、特定したこれらのECUについて、更新用ソフトウェアの配信に要するテレマティクスセンタ100の処理負荷を算出することができる。
ステップS1307で上記の合計割合A%を算出したら、更新案件管理部112は、現在のテレマティクスセンタ100の余力が、算出したA%以上であるかを確認する(ステップS1308)。その結果、余力がA%以上であれば(S1308:Yes)処理をステップS1309に進め、A%未満であれば(S1308:No)処理をステップS1310に進める。なお、ここで記述するテレマティクスセンタ100の余力とは、テレマティクスセンタ100が有する処理能力に対して現在の処理負荷がどの程度であるかを示す指標であり、例えば、テレマティクスセンタ100を構成する中央演算処理装置110のCPUの使用率を100%から引いた値などが考えられる。なお、CPUの使用率ではなく、例えば記憶装置120の使用率、通信部140の使用率などからテレマティクスセンタ100の処理負荷の余力を算出しても良いし、これらを複数組み合わせて算出しても良い。また、テレマティクスセンタ100がクラウドサーバ上に構築されている場合には、そのクラウドサーバの利用料などを考慮しても良い。
例えば、テレマティクスセンタ100の余力が80%であり、前述のようにA=64%である場合には、余力がA%以上であるため、ステップS1308が肯定判定されてステップS1309に進む。この場合、更新案件管理部112は、ステップS1301で確認した更新案件、すなわち機能カテゴリCx(今回の例ではC3)のECUに対する更新案件を処理する余裕がテレマティクスセンタ100にあると判断する。そのため、問い合わせ元の車両200に対して、「対象案件あり」と結果を送信するよう決定する(ステップS1309)。
一方、テレマティクスセンタ100の余力が50%であり、前述のようにA=64%である場合には、余力がA%未満であるため、ステップS1308が否定判定されてステップS1310に進む。この場合、更新案件管理部112は、ステップS1301で確認した更新案件、すなわち機能カテゴリCx(今回の例ではC3)のECUに対する更新案件よりも優先すべき更新案件が他に存在し、テレマティクスセンタ100の余力を残しておくべきと判断する。そのため、問い合わせ元の車両200に対して、実際には対象案件が存在するにも関わらず、「対象案件なし」と結果を送信するよう決定する(ステップS1310)。なお、ステップS1302で更新案件が存在しないと判定された場合も同様に、ステップS1310において、「対象案件なし」と結果を送信するよう決定する。
更新案件管理部112は、ステップS1301で確認した更新案件で対象とされた各ECUについて、以上説明したような処理をそれぞれ実行する。その結果、テレマティクスセンタ100の現在の処理負荷に応じた余力の範囲内で、実際に更新用ソフトウェアを配信してソフトウェアの更新対象とするECUが優先度順に選択される。更新案件における全てのECUについてステップS1309またはS1310の処理を実行したら、更新案件管理部112は、処理を図4のステップS613に進め、ステップS1309またはS1310で決定した結果を車両200に送信する。
以上説明した図11の処理により、更新案件管理部112は、テレマティクスセンタ100の処理負荷と、テレマティクスセンタ100において記憶された前述の車両200の更新情報に相当する情報、すなわち車種構成DB122における更新案件に対応する機能カテゴリ413の情報とに基づいて、更新用ソフトウェア配信部113が配信する更新用ソフトウェアを管理することができる。換言すると、ある車両200に対して更新案件が存在した場合であっても、各更新案件が対象とするECUの機能の重要度を軸に、テレマティクスセンタ100の余力を考慮して、更新を先延ばしにするか否かを判断することができる。これにより、更新案件がテレマティクスセンタ100に複数登録されている状況において、テレマティクスセンタ100の処理負荷を考慮した上で、更新案件を複数跨いだ上で、更新対象とするECUの機能重要度に応じて優先的に更新用ソフトウェアを配信することができる。したがって、優先度の低い更新案件が多数登録された場合でも、それらの配信優先度を低下させることで、テレマティクスセンタ100のインフラ増強を必要とせず、ソフトウェア更新システムを維持することができる。
なお、図11の更新案件確認処理において、優先度は機能カテゴリで決定するのではなく、他の方法で決定しても良い。例えば、各更新案件に対して、更新案件管理DB124の更新案件ID500に紐付く形で、別途優先度情報を付与することで対処しても良い。また、機能カテゴリではなく、車両構成DB121の車種ID401や、更新用ソフトウェアのファイルサイズなど、他の情報を基に優先度を自動的に決定する仕組みを導入しても良い。
さらに、図11に示す処理は、図4のステップS612において車両200からの問い合わせがある度に実行するのではなく、テレマティクスセンタ100が定期的に実行しても良い。その場合、ステップS1309またはS1310で決定した結果を記憶装置120に保存しておき、車両200からの問い合わせに応じてその結果をテレマティクスセンタ100から車両200に送信しても良いし、テレマティクスセンタ100から定期的に送信した結果を車両200において記憶装置215に保存しておいても良い。
さらに、本実施形態では、図11に示した更新案件確認処理を図4のステップS612において実行することで、更新案件の有無を制御する方式として利用する例を説明した。しかし、その他にも例えば、図4のステップS615において図11の更新案件確認処理を実行することで、テレマティクスセンタの処理負荷に応じて更新用ソフトウェアの配信を一時的に拒否したり、ダウンロードの通信帯域を狭めたりする方法として利用しても良い。また、第1の実施形態では、図5のステップS702において、入出力装置234を介してユーザからの許諾を取得する例を説明したが、ユーザが所有する携帯端末にメール等の手段で通知し、この通知に対する応答によりユーザからの許諾を取得することもできる。このようにした場合には、ユーザへの通知順序を決定する際に図11で説明した方式を利用することで、機能カテゴリに基づく優先度が高い更新案件から優先的に通知するようにしても良い。
図12は、本発明の第3の実施形態においてテレマティクスセンタ100の入出力装置130に表示される画面の一例を示す図である。
図12において、画面1400に表示されているグラフは、横軸に時刻を示し、縦軸に、テレマティクスセンタ100全体の処理負荷と、それに対する機能カテゴリ毎の処理負荷の割合とを示している。なお、機能カテゴリ毎の処理負荷の割合は、図11のステップS1306で算出される各機能カテゴリのカウント数の割合に相当するものである。この画面1400では、テレマティクスセンタ100が一定の時間間隔、例えば1分毎に図11に基づく更新案件確認処理を実行し、その計算結果を入出力装置130に表示した場合を想定している。
画面1400において、例えば時刻T3では、機能カテゴリC1、C2の処理負荷の割合の合計が50%程度であるのに対して、テレマティクスセンタ100全体の処理負荷は65%程度であり、テレマティクスセンタ100の余力は35%である。このため、図11に基づく処理では、時刻T3においては、更新対象のECUの機能カテゴリがC1である場合にのみ、ステップS1308においてYesに分岐し、それ以外のC2〜C5の場合にはNoに分岐することになる。なお、図12では、ステップS1308の判定結果がNoとなる更新対象のECUの機能カテゴリを網掛けで示している。すなわち、例えば時刻T3では、機能カテゴリC1のみが網掛けされておらず、機能カテゴリC2〜C5は網掛けで示されている。
以上説明した本発明の第3の実施形態によれば、テレマティクスセンタ100の更新案件管理部112は、テレマティクスセンタ100の処理負荷と、テレマティクスセンタ100に記憶された更新情報とに基づいて、更新用ソフトウェア配信部113が配信する更新用ソフトウェアを管理する(ステップS1303〜S1310)。このようにしたので、テレマティクスセンタ100の処理負荷を考慮して、テレマティクスセンタ100から車両200への更新用ソフトウェアの配信管理を行うことができる。
また、以上説明した本発明の第3の実施形態によれば、以下の作用効果を奏する。
(1)本実施形態のソフトウェア更新システムは、車両200に搭載された車載機器であるECUのソフトウェアの更新を管理するものであり、車両200に搭載されたソフトウェア更新装置210と、ソフトウェア更新装置210とネットワーク300を介して通信を行うテレマティクスセンタ100とを備える。テレマティクスセンタ100は、ECUのソフトウェアを更新するための更新用ソフトウェアをソフトウェア更新装置210に配信する更新用ソフトウェア配信部113と、ECUのソフトウェア更新に対する優先度に基づいて、更新用ソフトウェア配信部113が配信する更新用ソフトウェアを管理する更新案件管理部112と、を有する。ソフトウェア更新装置210は、テレマティクスセンタ100から配信された更新用ソフトウェアを記憶する記憶装置215と、記憶装置215に記憶された更新用ソフトウェアを用いてECUのソフトウェアを更新するECUソフトウェア更新部214と、を有する。このようにしたので、ユーザにとって利用しやすいOTAによる車載機器のソフトウェアの更新を実現することができる。
(2)車両200には、異なる機能をそれぞれ有する複数のECU、すなわちエンジンECU240、ABSECU241、ステアリングECU242、サスペンションECU243、エアバックECU244、自動運転ECU245、キーレスエントリECU246、エアコン制御ECU247、およびオーディオECU248が搭載されている。更新案件管理部112は、これら複数のECUがそれぞれ属する機能の重要度に基づいて優先度を設定する。具体的には、車両200に搭載された複数のECUは、車両200の運用への影響度合いに応じて、例えば機能カテゴリC1〜C5のように、複数の機能カテゴリにグループ分けされている。更新案件管理部112は、車両200に搭載された複数のECUがそれぞれ属する機能カテゴリに基づいて優先度を設定する(ステップS1303)。このようにしたので、各ECUの優先度を適切に設定することができる。
(3)テレマティクスセンタ100は、車両200に搭載された複数のECUに対応する複数の更新用ソフトウェアを記憶する記憶装置120を有する。更新案件管理部112は、テレマティクスセンタ100の処理負荷およびECUのソフトウェア更新に対する優先度に基づいて、複数のECUから少なくともいずれか一つを更新対象のECUとして選択する(ステップS1303〜S1310)。具体的には、更新案件管理部112は、車両200に搭載された複数のECUのうち少なくともいずれか一つのECUについて、更新用ソフトウェアの配信に要するテレマティクスセンタ100の処理負荷を算出する(ステップS1304〜S1307)。そして、テレマティクスセンタ100の現在の処理負荷に応じたサーバの余力と、算出したテレマティクスセンタ100の処理負荷とを比較し(ステップS1308)、その比較結果に基づいて更新対象のECUを決定する(ステップS1309、S1310)。更新用ソフトウェア配信部113は、ステップS615において、更新案件管理部112により選択された更新対象のECUに対応する更新用ソフトウェアをソフトウェア更新装置210に配信する。このようにしたので、テレマティクスセンタ100の処理負荷を考慮して、ソフトウェアを更新するECUを適切に選択することができる。
(4)更新案件管理部112は、ステップS1307において、テレマティクスセンタ100の処理負荷の算出対象とするECUを優先度に基づいて特定する。このようにしたので、テレマティクスセンタ100の処理負荷を適切に算出することができる。
(5)テレマティクスセンタ100は、ソフトウェア更新装置210をそれぞれ搭載した複数の車両200とネットワーク300を介して通信可能である。更新案件管理部112は、ステップS1307において、複数の車両200にそれぞれ搭載されたECUの中から、テレマティクスセンタ100の処理負荷の算出対象とするECUを特定する。このようにしたので、多様な車種が存在する複数の車両200に搭載されている様々なECUの中から、処理負荷の算出対象とするECUを適切に特定することができる。
以上説明した実施形態や各種の変形例はあくまで一例であり、発明の特徴が損なわれない限り、本発明はこれらの内容に限定されるものではない。また、上記では種々の実施形態を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。