JP6666281B2 - ソフトウェア更新システム、サーバ - Google Patents

Description

本発明は、ソフトウェア更新システムおよびサーバに関する。

近年、運転支援機能や自動運転技術の進展により、自動車用の電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）に搭載されるソフトウェアの規模が増大している。また、それに伴って、ＥＣＵのソフトウェア不具合に起因するリコールの回数や、リコール対象の自動車台数の規模が増加している。その一方で、通信ネットワークの進展に伴って、自動車が無線でセンタシステム等とつながるコネクッテッドカーも普及の兆しを見せている。

このような状況のなか、従来では携帯電話やテレビ等に使われていた無線での遠隔ソフトウェア更新技術（ＯＴＡ：Ｏｖｅｒ ｔｈｅ Ａｉｒ）を自動車に適用し、ＥＣＵ等の車載機器のソフトウェアを遠隔で更新する自動車向け遠隔ソフトウェア更新技術へのニーズが高まっている。特許文献１には、車載機器の一例としてテレマティクス車載端末のソフトウェアを遠隔で更新するシステムが開示されている。

特開２０１５−４１３３４号公報

特許文献１に開示されたシステムでは、ソフトウェアを更新すべき車載機器が同時に複数存在する場合に、適切なソフトウェアの更新管理を行うことができない。したがって、ユーザにとって利用しやすいＯＴＡによる車載機器のソフトウェアの更新を実現することができない。

本発明によるソフトウェア更新システムは、車両に搭載されたソフトウェア更新装置と、前記ソフトウェア更新装置とネットワークを介して通信を行うサーバとを備え、前記車両に搭載された制御装置のソフトウェアの更新を管理するものであって、前記車両には、異なる機能をそれぞれ有する複数の前記制御装置が搭載されており、前記サーバは、前記制御装置のソフトウェアを更新するための更新用ソフトウェアを前記ソフトウェア更新装置に配信する更新用ソフトウェア配信部と、前記制御装置のソフトウェア更新に対する優先度に基づいて、前記更新用ソフトウェア配信部が配信する前記更新用ソフトウェアを管理する更新案件管理部と、複数の前記制御装置に対応する複数の前記更新用ソフトウェアを記憶するサーバ側記憶装置と、を有し、前記ソフトウェア更新装置は、前記サーバから配信された前記更新用ソフトウェアを記憶する車両側記憶装置と、前記車両側記憶装置に記憶された前記更新用ソフトウェアを用いて前記制御装置のソフトウェアを更新するソフトウェア更新部と、を有し、前記更新案件管理部は、複数の前記制御装置がそれぞれ有する前記機能の重要度に基づいて前記優先度を設定し、複数の前記制御装置のうち少なくともいずれか一つの制御装置について、前記更新用ソフトウェアの配信に要する前記サーバの処理負荷を算出し、前記サーバの現在の処理負荷に応じた前記サーバの余力と、算出した前記サーバの処理負荷とを比較し、その比較結果に基づいて、複数の前記制御装置から少なくともいずれか一つを更新対象の制御装置として選択し、前記更新用ソフトウェア配信部は、前記更新案件管理部により選択された前記更新対象の制御装置に対応する前記更新用ソフトウェアを前記ソフトウェア更新装置に配信する。
本発明によるサーバは、車両に搭載された異なる機能をそれぞれ有する複数の制御装置のソフトウェアの更新を管理するものであって、前記制御装置のソフトウェアを更新するための更新用ソフトウェアを前記車両に配信する更新用ソフトウェア配信部と、前記制御装置のソフトウェア更新に対する優先度に基づいて、前記更新用ソフトウェア配信部が配信する前記更新用ソフトウェアを管理する更新案件管理部と、複数の前記制御装置に対応する複数の前記更新用ソフトウェアを記憶するサーバ側記憶装置と、を備え、前記更新案件管理部は、複数の前記制御装置がそれぞれ有する前記機能の重要度に基づいて前記優先度を設定し、複数の前記制御装置のうち少なくともいずれか一つの制御装置について、前記更新用ソフトウェアの配信に要する前記サーバの処理負荷を算出し、前記サーバの現在の処理負荷に応じた前記サーバの余力と、算出した前記サーバの処理負荷とを比較し、その比較結果に基づいて、複数の前記制御装置から少なくともいずれか一つを更新対象の制御装置として選択し、前記更新用ソフトウェア配信部は、前記更新案件管理部により選択された前記更新対象の制御装置に対応する前記更新用ソフトウェアを前記車両に配信する。

本発明によれば、ユーザにとって利用しやすいＯＴＡによる車載機器のソフトウェアの更新を実現することができる。

本発明の第１の実施形態に係るソフトウェア更新システムの構成例を示す図である。 本発明の第１の実施形態においてテレマティクスセンタのＤＢに格納されるデータの構造を表すテーブルの一例を示す図である。 本発明の第１の実施形態においてテレマティクスセンタのＤＢに格納されるデータの構造を表すテーブルの一例を示す図である。 本発明の第１の実施形態において実行される更新用ソフトウェアのダウンロード処理の流れを示す図である。 本発明の第１の実施形態において実行されるＥＣＵソフトウェア更新処理の流れを示す図である。 本発明の第１の実施形態において実行されるリカバリ処理の流れを示す図である。 本発明の第１の実施形態において実行されるリカバリ処理の流れを示す図である。 本発明の第１の実施形態においてテレマティクスセンタの入出力装置に表示される画面の一例を示す図である。 本発明の第１の実施形態において車両に搭載されたナビゲーション端末の入出力装置に表示される画面の一例を示す図である。 本発明の第２の実施形態において実行されるＥＣＵソフトウェア更新処理の流れを示す図である。 本発明の第３の実施形態において実行される更新案件確認処理の流れを示す図である。 本発明の第３の実施形態においてテレマティクスセンタの入出力装置に表示される画面の一例を示す図である。

以下では、図１〜図１２を参照しながら、本発明の実施形態を説明する。

（第１の実施形態）
図１は、本発明の第１の実施形態に係るソフトウェア更新システムの構成例を示す図である。図１に示すソフトウェア更新システムは、車両２００に搭載された各種ＥＣＵのソフトウェアの更新を管理するものであり、サーバであるテレマティクスセンタ１００と、車両２００に搭載されたソフトウェア更新装置２１０とを備える。テレマティクスセンタ１００とソフトウェア更新装置２１０とは、ネットワーク３００および車両２００に搭載された通信部２２０を介して互いに接続されている。この接続により、テレマティクスセンタ１００とソフトウェア更新装置２１０の間で通信が可能となっている。ネットワーク３００としては、例えば携帯電話網、インターネット網、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の近距離無線通信、あるいはそれら複数の組み合わせで構成されたものなどが挙げられる。なお、図１では、ソフトウェア更新装置２１０を搭載した車両２００を１台のみ図示しているが、こうした車両２００は１台に限定するものではなく、複数台の車両２００がソフトウェア更新装置２１０をそれぞれ搭載し、テレマティクスセンタ１００と接続されても良い。

テレマティクスセンタ１００は、ネットワーク３００を介して、車両２００に搭載されている様々な各種ＥＣＵのソフトウェアを更新するための更新ソフトウェアを車両２００に配信する。テレマティクスセンタ１００は、中央演算処理装置１１０と、記憶装置１２０と、入出力装置１３０と、通信部１４０とを備える。

中央演算処理装置１１０は、例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）やＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などから構成され、所定の動作プログラムを実行することで、テレマティクスセンタ１００の機能を実現する処理を行う。中央演算処理装置１１０は、その機能として、構成情報管理部１１１、更新案件管理部１１２、更新用ソフトウェア配信部１１３およびリカバリ用ソフトウェア配信部１１４を備える。

構成情報管理部１１１は、記憶装置１２０に格納されている後述の車両構成ＤＢ１２１、車種構成ＤＢ１２２、機能構成ＤＢ１２３の各情報を管理し、必要に応じて各情報の登録、変更、削除を行う。更新案件管理部１１２は、車両２００の各ＥＣＵに対するソフトウェアの更新内容を示す更新案件の管理を行う。更新用ソフトウェア配信部１１３は、車両２００からの要求に応じて、更新用ソフトウェアを車両２００に配信する。リカバリ用ソフトウェア配信部１１４は、車両２００に搭載されたいずれかのＥＣＵについてソフトウェアの更新に失敗した場合に、当該ＥＣＵのソフトウェアを更新前の状態に戻すためのリカバリ用ソフトウェアを車両２００に配信する。なお、これらの各構成の動作については、後で詳しく説明する。

記憶装置１２０は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、フラッシュメモリ、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）などから構成される。記憶装置１２０には、中央演算処理装置１１０が実行するプログラムや、プログラムの実行に必要なデータ群などが格納される。記憶装置１２０に格納されるデータ群には、車両構成ＤＢ１２１、車種構成ＤＢ１２２、機能構成ＤＢ１２３、更新案件管理ＤＢ１２４、進捗管理ＤＢ１２５などが含まれる。

車両構成ＤＢ１２１は、各車両２００に搭載されているＥＣＵとソフトウェアのバージョンを管理するための情報である車両構成情報を蓄積する。車種構成ＤＢ１２２は、各車両２００に搭載されているＥＣＵを車種単位で管理するための情報である車種構成情報を蓄積する。機能構成ＤＢ１２３は、各ＥＣＵが車両２００の運用にどの様な影響を及ぼすかを管理するための情報である機能構成情報を蓄積する。更新案件管理ＤＢ１２４は、ＥＣＵのソフトウェア更新案件を管理するための情報を蓄積する。なお、更新案件管理ＤＢ１２４は、ソフトウェア更新案件の情報だけでなく、各車両２００に配信するための更新用ソフトウェアも蓄積する。更新用ソフトウェアは、入出力装置１３０等を介して事前に登録されることで、更新案件管理ＤＢ１２４に蓄積される。進捗管理ＤＢ１２５は、実際に各車両２００への更新用ソフトウェアの配信を開始してから、どの車両において既に更新が完了したかを管理するための情報を蓄積する。

入出力装置１３０は、タッチパネルやキーボード、マウスなどの組み合わせから構成され、入力部および表示部として機能する。

通信部１４０は、ネットワーク３００で用いられる通信規格に準拠したネットワークカードなどから構成される。ネットワークカードは、有線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの有線通信や無線ＬＡＮなどの無線通信、あるいはその両方に必要な通信規格に準拠する。通信部１４０は、ネットワーク３００を介して、車両２００と各種プロトコルに基づきデータを送受信する。

車両２００は、ソフトウェア更新装置２１０と、通信部２２０と、ナビゲーション端末２３０と、エンジンＥＣＵ２４０と、ＡＢＳＥＣＵ２４１と、ステアリングＥＣＵ２４２と、サスペンションＥＣＵ２４３と、エアバックＥＣＵ２４４と、自動運転ＥＣＵ２４５と、キーレスエントリＥＣＵ２４６と、エアコン制御ＥＣＵ２４７と、オーディオＥＣＵ２４８とを備える。

エンジンＥＣＵ２４０は、車両２００のエンジン動作を管理する。ＡＢＳＥＣＵ２４１は、車両２００のＡＢＳ（Ａｎｔｉｌｏｃｋ Ｂｒａｋｅ Ｓｙｓｔｅｍ）を管理する。ステアリングＥＣＵ２４２は、車両２００のステアリング制御を管理する。サスペンションＥＣＵ２４３は、車両２００のサスペンション制御を管理する。エアバックＥＣＵ２４４は、車両２００のエアバックの動作制御を管理する。自動運転ＥＣＵ２４５は、車両２００の自動運転の動作制御を管理する。キーレスエントリＥＣＵ２４６は、車両２００のキーレスエントリの制御を管理する。エアコン制御ＥＣＵ２４７は、車両２００のエアコンを制御する。オーディオＥＣＵ２４８は、車両２００のオーディオ機器の動作を制御する。各機器は、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの車内ネットワークで接続される。また、図１に示す通り、上記の各ＥＣＵはその機能分担に応じてそれぞれ異なるバス型ＣＡＮネットワークに接続されている。ソフトウェア更新装置２１０は、これらのバス型ネットワークのハブ機能を有している。

なお、車両２００に搭載される、ソフトウェア更新が可能なＥＣＵは、図１に示したものに限定されない。例えば、ブレーキ制御用のＥＣＵや電子ミラー制御用のＥＣＵなど、車両２００の制御や安全を支援する機能を持つＥＣＵが、図１に示した各ＥＣＵ以外に車両２００に搭載されていても良い。なお、各ＥＣＵには、自身を動作させるためのソフトウェアがそれぞれ内蔵されている。このソフトウェアは、各ＥＣＵが持つ記憶装置にそれぞれ格納されている。

ソフトウェア更新装置２１０は、中央演算処理装置２１１と、記憶装置２１５とを備える。

中央演算処理装置２１１は、例えばＣＰＵやＲＡＭなどから構成され、所定の動作プログラムを実行することで、ソフトウェア更新装置２１０の機能を実現する処理を行う。中央演算処理装置２１１は、その機能として、更新案件確認部２１２、更新用ソフトウェア要求部２１３およびＥＣＵソフトウェア更新部２１４を備える。

更新案件確認部２１２は、ソフトウェア更新が必要な案件があるか否かをテレマティクスセンタ１００に問い合わせる。更新用ソフトウェア要求部２１３は、ソフトウェア更新案件があった場合に、更新用ソフトウェアやアップデート実行要件を更新データとしてテレマティクスセンタに要求する。ＥＣＵソフトウェア更新部２１４は、受信したソフトウェアおよびアップデート実行要件に基づいてＥＣＵのソフトウェアを更新し、その実行結果をテレマティクスセンタ１００に送信する。

記憶装置２１５は、例えば、ＨＤＤ、ＳＳＤ、フラッシュメモリ、ＲＯＭなどから構成され、中央演算処理装置２１１が実行するプログラムや、プログラム実行に必要なデータ群などが格納される。さらに、記憶装置２１５には、テレマティクスセンタ１００から配信された更新用ソフトウェアや、いずれかのＥＣＵについてソフトウェアの更新に失敗した場合にテレマティクスセンタ１００から配信される前述のリカバリ用ソフトウェアなども格納される。

通信部２２０は、ネットワーク３００で用いられる通信規格に準拠したネットワークカードなどから構成される。ネットワークカードは、例えば、無線ＬＡＮなどの無線通信に準拠する。通信部２２０は、ネットワーク３００を介して、テレマティクスセンタ１００と各種プロトコルに基づきデータを送受信する。ここで、通信部２２０による通信は無線方式に限定される。そのため、例えば通信部２２０が携帯電話網を利用する場合には、車両２００が地下駐車場に駐車している等の理由から通信部２２０が通信圏外になり、テレマティクスセンタ１００と通信できない状況に陥る可能性がある。

ナビゲーション端末２３０は、中央演算処理装置２３１と、記憶装置２３３と、タッチパネルやキーボード、マウスなどの組み合わせからなる入出力装置２３４とを備える。

中央演算処理装置２３１は、例えばＣＰＵやＲＡＭなどから構成され、所定の動作プログラムを実行することで、ナビゲーション端末２３０の機能を実現する処理を行う。中央演算処理装置２３１は、その機能として、更新情報表示部２３２を備える。更新情報表示部２３２は、テレマティクスセンタ１００から送信された更新情報に基づく表示を入出力装置２３４に対して行う。そして、入出力装置２３４を用いてユーザからソフトウェア更新を許諾する旨の入力が行われると、許諾情報を取得し、テレマティクスセンタ１００に送信する。

記憶装置２３３は、例えば、ＨＤＤ、ＳＳＤ、フラッシュメモリ、ＲＯＭなどから構成され、中央演算処理装置２３１が実行するプログラムや、プログラム実行に必要なデータ群などが格納される。

なお、ソフトウェア更新装置２１０とナビゲーション端末２３０は同一の機器であっても良い。また、ナビゲーション端末２３０は車両２００に搭載されるものではなく、例えばスマートフォンなどの携帯端末をナビゲーション端末２３０として用いても良い。この場合、通信部２２０は携帯端末側に存在し、ソフトウェア更新装置２１０は例えばＯＢＤ（Ｏｎ Ｂｏａｒｄ Ｄｉａｇｎｏｓｔｉｃｓ）などのコネクタを用いることで、携帯端末と通信することが考えられる。

図２は、本発明の第１の実施形態において、テレマティクスセンタ１００の車両構成ＤＢ１２１、車種構成ＤＢ１２２、機能構成ＤＢ１２３にそれぞれ格納されるデータの構造を表すテーブルの一例を示す図である。

車両構成ＤＢ１２１には、ＶＩＮ（Ｖｅｈｉｃｌｅ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ Ｎｕｍｂｅｒ）４００、車種ＩＤ４０１、ＥＣＵ種別４０２、ＥＣＵＩＤ４０３、ソフトウェアバージョン４０４の各データが格納される。ＶＩＮ４００は、車両２００を一意に特定可能な識別子である。車種ＩＤ４０１は、そのＶＩＮ４００を持つ車両２００の車種を一意に特定可能な識別子である。ＥＣＵ種別４０２は、そのＶＩＮ４００を持つ車両２００に搭載されるＥＣＵの種別を一意に特定可能な識別子である。ＥＣＵＩＤ４０３は、そのＶＩＮ４００を持つ車両２００に搭載されるＥＣＵを一意に特定可能な識別子である。ソフトウェアバージョン４０４は、ＥＣＵＩＤ４０３により特定されるＥＣＵに搭載されているソフトウェアのバージョン情報を一意に特定可能な識別子である。

車種構成ＤＢ１２２には、車種ＩＤ４１０、ＥＣＵ種別４１１、ＥＣＵカテゴリ４１２、機能カテゴリ４１３、オフラインリカバリ機能４１４の各データが格納される。車種ＩＤ４１０は、車両構成ＤＢ１２１の車種ＩＤ４０１と共通のデータであり、各車両２００の車種を一意に特定可能な識別子である。ＥＣＵ種別４１１は、車両構成ＤＢ１２１のＥＣＵ種別４０２と共通のデータであり、各車両２００に搭載されるＥＣＵの種別を一意に特定可能な識別子である。ＥＣＵカテゴリ４１２は、ＥＣＵ種別４１１により特定されるＥＣＵが属するカテゴリを示す情報である。機能カテゴリ４１３は、そのＥＣＵが車両２００の制御において担う機能のカテゴリを示す情報である。オフラインリカバリ機能４１４は、そのＥＣＵがオフラインによるリカバリ方法をサポートしているか否かを示す情報である。

なお、車種構成ＤＢ１２２においてＥＣＵカテゴリ４１２は、図１に示したソフトウェア更新システムにおける車両２００内の各ＥＣＵのネットワーク構成を反映している。すなわち、車両２００に搭載されている各ＥＣＵは、前述のように、その機能分担に応じて互いに異なるバス型ＣＡＮネットワークに接続されており、ソフトウェア更新装置２１０がそのハブ機能を有している。ＥＣＵカテゴリ４１２が表す各ＥＣＵのカテゴリは、そのバス型ＣＡＮネットワーク単位で構成されている。一般的な車両では、ＥＣＵ間の接続はこのようなネットワーク構成を有しており、各ネットワークに対してパワートレイン系やシャーシ系、セーフティ系などの名称が与えられている。ＥＣＵカテゴリ４１２は、このネットワーク形態に即して、車両２００に搭載されているＥＣＵを複数のグループに分割して表している。

また、車種構成ＤＢ１２２において機能カテゴリ４１３は、各ＥＣＵが担う機能の重要度、すなわち各ＥＣＵの機能が車両２００の運用に対してどの程度の影響を与えているかを表すものである。例えば、エンジンＥＣＵ２４０が動作しなければ車両２００を発進させることはできないが、エアコン制御ＥＣＵ２４７が動作しなくても車両２００は通常どおり走行することが可能であり、車両２００の運用に対して直接的な影響はない。機能カテゴリ４１３は、このような車両２００の制御に対する各ＥＣＵの機能の違いを表すものであり、必ずしもＥＣＵカテゴリ４１２とは一致しない形で、車両２００に搭載されるＥＣＵを複数のグループに分割して表している。

なお、上記のＥＣＵカテゴリ４１２および機能カテゴリ４１３の分割方法は、図２に示したように５つのグループに分割するものに限らず、５つよりも少ない、あるいは多いグループに分割するものであっても良い。

機能構成ＤＢ１２３には、機能カテゴリ４２０、圏内移動可否４２１、速度制限４２２、機能制限４２３、ユーザ通知内容４２４の各データが格納される。機能カテゴリ４２０は、車種構成ＤＢ１２２の機能カテゴリ４１３と共通のデータであり、各ＥＣＵが担う機能の重要度を表している。圏内移動可否４２１は、機能カテゴリ４２０により特定されるカテゴリに属するＥＣＵが動作不能となった場合に、車両２００を移動させることができるか否かを示す情報である。速度制限４２２は、そのＥＣＵが動作不能となった時に車両２００の移動に速度制限を課すべきか否かを示す情報である。機能制限４２３は、そのＥＣＵが動作不能となった時に車両２００に対して機能制限を課すべきか否かを示す情報である。ユーザ通知内容４２４は、そのＥＣＵが動作不能となった時にユーザに特別な通知をする場合のメッセージを表す情報である。

記憶装置１２０では、各車両２００に対して、以上説明したような情報が車両構成ＤＢ１２１、車種構成ＤＢ１２２、機能構成ＤＢ１２３にそれぞれ格納されている。これらの情報は、構成情報管理部１１１において、更新用ソフトウェアの配信対象とするＥＣＵを特定するために用いられる。また前述のように、いずれかのＥＣＵについてソフトウェアの更新に失敗した場合の車両２００の運用への影響を示している。

図３は、本発明の第１の実施形態において、テレマティクスセンタ１００の更新案件管理ＤＢ１２４、進捗管理ＤＢ１２５にそれぞれ格納されるデータの構造を表すテーブルの一例を示す図である。

更新案件管理ＤＢ１２４には、更新案件ＩＤ５００、ＥＣＵＩＤ５０１、更新ファイル名５０２、適用バージョン５０３の各データが格納される。更新案件ＩＤ５００は、例えばリコールなど、複数の車両２００を対象としたソフトウェアアップデートを要する案件を一意に特定可能な識別子である。ＥＣＵＩＤ５０１は、更新案件ＩＤ５００により特定される更新案件がアップデート対象とするＥＣＵを一意に特定可能な識別子であり、車両構成ＤＢ１２１のＥＣＵＩＤ４０３に対応している。ファイル名５０２は、ＥＣＵＩＤ５０１により特定されるアップデート対象のＥＣＵに配布する更新用ソフトウェアのファイル名を示す情報である。適用バージョン５０３は、ファイル名５０２が示す更新用ソフトウェアを適用することでアップデートされた後のＥＣＵのソフトウェアバージョンを示す情報である。

進捗管理ＤＢ１２５には、更新案件ＩＤ５１０、ＶＩＮ５１１、ステータス５１２、更新日時７１３、更新実行位置５１４の各データが格納される。更新案件ＩＤ５１０は、更新案件管理ＤＢ１２４の更新案件ＩＤ５００と共通のデータである。ＶＩＮ５１１は、更新案件ＩＤ５１０により特定される更新案件が対象とする車両２００を一意に特定可能な識別子であり、車両構成ＤＢ１２１のＶＩＮ４００に対応している。ステータス５１２は、更新案件ＩＤ５１０より特定される更新案件がＶＩＮ５１１により特定される車両２００においてどの程度の進捗状況であるかを表す情報である。ステータス５１２は、例えば、更新用ソフトウェアのダウンロードが完了したか、ユーザからインストールの許諾を得たか（インストール中か）、インストールが完了したかなどの状態により、更新案件の進捗状況を管理している。更新日時７１３は、その更新案件のアップデートが完了した場合のアップデート実行日時を示す情報である。更新実行位置５１４は、その更新案件のアップデートを実行した時の車両２００の位置情報を示す情報である。

なお、更新案件管理ＤＢ１２４の各データは、テレマティクスセンタ１００が車両２００に更新用ソフトウェアを配信する前に、テレマティクスセンタ１００の管理者等によって入出力装置１３０を介して入力される。管理者としては、例えばテレマティクスセンタ１００の運用者や、ＥＣＵの製造管理者などが考えられる。更新案件管理部１１２は、更新対象とするＥＣＵのＩＤや、アップデートに使用される更新用ソフトウェアのファイルおよびバージョン情報の入力を受け付けると、その更新案件に対するＩＤを新しく生成し、これらの入力情報に基づいて更新案件管理ＤＢ１２４に各データを蓄積する。その後、更新案件管理部１１２は、更新案件管理ＤＢ１２４のＥＣＵＩＤ５０１に蓄積されたのと同じ値のＥＣＵＩＤ４０３を持つ車両２００を車両構成ＤＢ１２１から検索し、該当する車両２００のＶＩＮ４００の値を、更新案件ＩＤ５００の値と共に、進捗管理ＤＢ１２５にＶＩＮ５１１、更新ＩＤ５１０としてそれぞれ蓄積する。

図４は、本発明の第１の実施形態において実行される更新用ソフトウェアのダウンロード処理の流れを示す図である。図４に示す処理は、車両２００に搭載されているソフトウェア更新装置２１０の更新案件確認部２１２および更新用ソフトウェア要求部２１３と、テレマティクスセンタ１００の更新案件管理部１１２および更新用ソフトウェア配信部１１３とにより行われる。

図４において、更新案件確認部２１２は、エンジンＥＣＵ２４０からの情報を用いて車両２００のエンジン始動を検知する（ステップＳ６００）。ステップＳ６００でエンジン始動を検知したら、更新案件確認部２１２は、まだ更新を完了していない更新案件が存在するか否かを確認するため、テレマティクスセンタ１００に対して更新案件の問い合わせを行う（ステップＳ６０１）。この時、更新案件確認部２１２は、ソフトウェア更新装置２１０に接続されている車両２００の全てのＥＣＵから、そのＩＤとソフトウェアバージョンの情報を収集する。そして、収集したこれらの情報と車両２００のＶＩＮとに基づいて現在の車両２００の構成を示す車両構成情報を生成し、テレマティクスセンタ１００への問い合わせに付与して、通信部２２０から送信する。

ステップＳ６０１で車両２００から送信された更新案件の問い合わせは、テレマティクスセンタ１００において、通信部１４０により受信される（ステップＳ６１０）。ステップＳ６１０で更新案件の問い合わせを受信したら、テレマティクスセンタ１００の更新案件管理部１１２は、まず始めに、問い合わせ元の車両２００に対応する車両構成情報を更新する（ステップＳ６１１）。ここでは、更新案件管理部１１２は、ステップＳ６１０で更新案件の問い合わせと共に受信した車両構成情報が表す車両２００のＶＩＮと同じ値のＶＩＮ４００を持つレコードを車両構成ＤＢ１２１から検索する。そして、検索されたレコードに含まれるＥＣＵＩＤ４０３に関して、受信した車両構成情報のソフトウェアバージョンとソフトウェアバージョン４０４の値を比較し、これらの値が異なる場合には、該当レコードのソフトウェアバージョン４０４の値を、受信した車両構成情報のソフトウェアバージョンで上書きする。この時、もし車両２００においてＥＣＵが追加されているのであれば、そのＥＣＵに対応するレコードを１つ追加しても良い。また、全てのレコードについて受信した車両構成情報のソフトウェアバージョンとソフトウェアバージョン４０４の値が一致する場合には、上書き処理を実行する必要はない。

更新案件管理部１１２は、次に、問い合わせ元の車両２００に対する更新案件の有無を確認する（ステップＳ６１２）。ここでは、更新案件管理部１１２は、ステップＳ６１０で更新案件の問い合わせと共に受信した車両構成情報が表す車両２００のＶＩＮが、進捗管理ＤＢ１２５のＶＩＮ５１１に登録されているか否かを確認することで、その車両２００に対する更新案件の有無を確認する。ステップＳ６１２で更新案件の有無を確認できたら、更新案件管理部１１２は、その確認結果を通信部１４０から問い合わせ元の車両２００に送信する（ステップＳ６１３）。

ステップＳ６１３でテレマティクスセンタ１００から送信された更新案件の確認結果は、車両２００のソフトウェア更新装置２１０において、通信部２２０により受信される（ステップＳ６０２）。ステップＳ６０２で更新案件の確認結果を受信したら、ソフトウェア更新装置２１０の更新案件確認部２１２は、その確認結果に基づき、更新案件の有無を判定する（ステップＳ６０３）。その結果、更新案件がないと判定した場合（Ｓ６０３：Ｎｏ）には、今回のエンジン始動に関してはダウンロードすべき更新用ソフトウェアは無いと判断し、図４の処理を終了する。

一方、更新案件があると判定した場合（Ｓ６０３：Ｙｅｓ）には、更新用ソフトウェア要求部２１３は、更新対象ＥＣＵに対する更新用ソフトウェアをテレマティクスセンタ１００に要求する（ステップＳ６０４）。

ステップＳ６０４で車両２００から送信された更新用ソフトウェアの要求は、テレマティクスセンタ１００において、通信部１４０により受信される（ステップＳ６１４）。ステップＳ６１４で更新用ソフトウェアの要求を受信したら、テレマティクスセンタ１００の更新用ソフトウェア配信部１１３は、対象とする更新案件の更新用ソフトウェアと、車両２００のＥＣＵ構成に応じた更新情報とを、通信部１４０から要求元の車両２００に送信する（ステップＳ６１５）。ここでは、更新用ソフトウェア配信部１１３は、ステップＳ６１２と同様に、要求元の車両２００のＶＩＮが進捗管理ＤＢ１２５のＶＩＮ５１１に登録されているか否かを再度確認し、該当レコードの更新案件ＩＤ５１０と同じ値が更新案件ＩＤ５００に記録されているレコードを更新案件管理ＤＢ１２４から検索することで、ソフトウェアのアップデートに必要な更新用ソフトウェアのファイル名を示す更新ファイル名５０２を抽出する。さらに、要求元の車両２００のＶＩＮと同じ値のＶＩＮ４００を持つレコードを車両構成ＤＢ１２１から検索し、該当レコードの車種ＩＤ４０１と同じ値が車種ＩＤ４１０に記録されているレコードを車種構成ＤＢ１２２から検索すると共に、車種構成ＤＢ１２２の該当レコードの機能カテゴリ４１３と同じ値が機能カテゴリ４２０に記憶されているレコードを機能構成ＤＢ１２３から検索する。そして、車種構成ＤＢ１２２および機能構成ＤＢ１２３においてそれぞれ検索されたレコードの各データを抽出することで、要求元の車両２００に対応する車種構成情報および機能構成情報を抽出し、これらをまとめることで、車両２００のＥＣＵ構成に応じた更新情報を生成する。この更新情報は、要求元の車両２００に搭載されている各ＥＣＵについて、ソフトウェアの更新に失敗した場合の車両２００の運用への影響を表すものである。こうして更新用ソフトウェアのファイル名を抽出すると共に車両２００のＥＣＵ構成に応じた更新情報を生成できたら、更新用ソフトウェア配信部１１３は、抽出したファイル名に対応する更新用ソフトウェアを更新案件管理ＤＢ１２４から抽出し、生成した更新情報と併せて、要求元の車両２００に送信する。

なお、上記ステップＳ６１４において、更新用ソフトウェア配信部１１３は、更新用ソフトウェアのみを車両２００に送信し、更新情報を送信しないようにしてもよい。その場合、車両２００のＥＣＵ構成に応じた更新情報は、予め車両２００においてソフトウェア更新装置２１０の記憶装置２１５に記憶されていても良い。また、図４に示す処理とは別に、定期的に、または必要に応じて、テレマティクスセンタ１００からソフトウェア更新装置２１０に更新情報を送信しても良い。

ステップＳ６１５でテレマティクスセンタ１００から送信された更新用ソフトウェアと更新情報は、車両２００のソフトウェア更新装置２１０において、通信部２２０により受信される（ステップＳ６０５）。ステップＳ６０５で更新用ソフトウェアと更新情報を受信したら、ソフトウェア更新装置２１０の更新用ソフトウェア要求部２１３は、これらのデータを記憶装置２１５に蓄積する（ステップＳ６０６）。その後、更新用ソフトウェア要求部２１３は、更新用ソフトウェアのダウンロードが完了したことをテレマティクスセンタ１００に通知する（ステップＳ６０７）。

ステップＳ６０７で車両２００から送信されたダウンロード完了の通知を受信したら、テレマティクスセンタ１００の更新案件管理部１１２は、通知元の車両２００のＶＩＮが登録されているレコードを進捗管理ＤＢ１２５から検索し、該当レコードのステータス５１２を更新する（ステップＳ６１６）。そして、通知元の車両２００に対して、インストールを開始する指令を送信する（ステップＳ６１７）。

ステップＳ６１７でテレマティクスセンタ１００から送信されたインストール開始指令は、車両２００のソフトウェア更新装置２１０において、通信部２２０により受信される（ステップＳ６０８）。ステップＳ６０８でインストール開始指令を受信したら、ソフトウェア更新装置２１０の更新案件確認部２１２は、図４の処理を終了し、車両２００のエンジンがオフ状態になるまで待機状態に入る。

以上説明した図４の処理により、テレマティクスセンタ１００から車両２００のソフトウェア更新装置２１０に対して、更新対象のＥＣＵのソフトウェアを更新するための更新用ソフトウェアと、そのＥＣＵのソフトウェアの更新に失敗した場合の車両２００の運用への影響に関する更新情報とが配信される。

図５は、本発明の第１の実施形態において実行されるＥＣＵソフトウェア更新処理の流れを示す図である。図５に示す処理は、車両２００に搭載されているソフトウェア更新装置２１０のＥＣＵソフトウェア更新部２１４およびナビゲーション端末２３０の更新情報表示部２３２と、テレマティクスセンタ１００の更新案件管理部１１２とによって行われる。

図５において、ＥＣＵソフトウェア更新部２１４は、エンジンＥＣＵ２４０からの情報を用いて車両２００のエンジン停止を検知する（ステップＳ７００）。ステップＳ７００でエンジン停止を検知したら、ＥＣＵソフトウェア更新部２１４は、図４の処理によって更新用ソフトウェアをダウンロード済みの更新案件のうち、まだ更新を完了していない更新案件が存在するか否かを確認する（ステップＳ７０１）。その結果、未完了の更新案件がないと判定した場合（Ｓ７０１：Ｎｏ）には、今回のエンジン停止では実行すべきＥＣＵソフトウェア更新処理が存在しないため、図５の処理を終了する。

一方、未完了の更新案件が存在すると判定した場合（Ｓ７０１：Ｙｅｓ）には、更新情報表示部２３２は、入出力装置２３４を用いて、更新用ソフトウェアのインストールを開始する旨をユーザに通知する（ステップＳ７０２）。ここでは、更新情報表示部２３２は、図４のステップＳ６０５においてテレマティクスセンタ１００からダウンロードされて記憶装置２１５に記憶された更新用ソフトウェアを参照することで、更新内容を確認する。そして、確認した更新内容をナビゲーション端末２３０の入出力装置２３４に出力して画面表示させることにより、ユーザへの更新通知を行う。さらにこの時、更新を許諾するか否かの選択肢を併せて画面表示し、入出力装置２３４においていずれかの選択肢をユーザに選択させる。

ステップＳ７０２でユーザへの更新通知を行ったら、ＥＣＵソフトウェア更新部２１４は、入出力装置２３４に対するユーザの入力操作に基づき、更新の許諾が得られたか否かを判定する（ステップＳ７０３）。その結果、ユーザから更新の許諾が得られなかった場合（Ｓ７０３：Ｎｏ）には、ＥＣＵソフトウェア更新部２１４は、その旨をテレマティクスセンタ１００に通知し（ステップＳ７０６）、次に車両２００のエンジンがオフ状態になるまで待機状態に入る。この通知を車両２００から受信したら、テレマティクスセンタ１００の更新案件管理部１１２は、通知元の車両２００のＶＩＮが登録されているレコードを進捗管理ＤＢ１２５から検索し、該当レコードのステータス５１２を「ユーザ許諾取得待ち」に更新する（ステップＳ７１１）。これ以降では、ユーザから更新の許諾を得られるまで、図５の処理が繰り返される。

一方、ユーザから更新の許諾が得られた場合（Ｓ７０３：Ｙｅｓ）には、ＥＣＵソフトウェア更新部２１４は、テレマティクスセンタ１００に対して、ダウンロード済みの更新用ファイルを用いたＥＵＣソフトウェアのアップデートを開始することを通知する（ステップＳ７０４）。このアップデート開始通知を受信したら、テレマティクスセンタ１００の更新案件管理部１１２は、通知元の車両２００のＶＩＮが登録されているレコードを進捗管理ＤＢ１２５から検索し、該当レコードのステータス５１２を「アップデート開始」に更新する（ステップＳ７１０）。

ステップＳ７０４でアップデート開始通知を行ったら、ＥＣＵソフトウェア更新部２１４は、図４で説明した更新用ソフトウェアのダウンロード処理においてテレマティクスセンタ１００からダウンロードされて記憶装置２１５に記憶された更新用ソフトウェアを用いて、更新対象のＥＣＵソフトウェアのアップデートを実行する（ステップＳ７０５）。そして、アップデート実行結果をテレマティクスセンタ１００に通知し（ステップＳ７０６）、次に車両２００のエンジンがオフ状態になるまで待機状態に入る。この通知を車両２００から受信したら、テレマティクスセンタ１００の更新案件管理部１１２は、通知元の車両２００のＶＩＮが登録されているレコードを進捗管理ＤＢ１２５から検索し、該当レコードのステータス５１２を更新する（ステップＳ７１１）。この時、アップデート実行結果が正常である旨の通知を受けた場合には、該当レコードのステータス５１２を「アップデート正常完了」に更新し、そうでない場合には、該当レコードのステータス５１２を「アップデート失敗」に更新する。

以上説明した図５の処理により、ダウンロード済みの更新用ソフトウェアを用いて、更新対象のＥＣＵのソフトウェアが更新される。

なお、車両２００の状態によっては、前述のように通信部２２０が通信圏外となり、ソフトウェア更新装置２１０とテレマティクスセンタ１００の間で通信が不可能となる場合がある。このような場合には、テレマティクスセンタ１００において、ステップＳ７０４のアップデート開始通知や、ステップＳ７０６のアップデート実行結果の通知を、ソフトウェア更新装置２１０から受けることができない。その結果、テレマティクスセンタ１００の更新案件管理部１１２は、ステップＳ７１０やステップＳ７１１の処理を実行できない。したがって、ソフトウェア更新装置２１０からの通知が得られない場合には、更新案件管理部１１２は、車両２００が通信可能な状態となるまでステップＳ７１０やステップＳ７１１の処理を保留し、通信可能な状態となった時にこれらの処理を実行するようにしても良い。

次に、車両２００においてＥＣＵソフトウェアの更新に失敗した場合に実行されるリカバリ処理について説明する。図６および図７は、本発明の第１の実施形態において実行されるリカバリ処理の流れを示す図である。図６および図７に示す処理は、車両２００に搭載されているソフトウェア更新装置２１０のＥＣＵソフトウェア更新部２１４およびナビゲーション端末２３０の更新情報表示部２３２と、テレマティクスセンタ１００の更新案件管理部１１２およびリカバリ用ソフトウェア配信部１１４とにより行われる。

図６において、ＥＣＵソフトウェア更新部２１４は、エンジンＥＣＵ２４０からの情報を用いて車両２００のエンジン始動を検知する（ステップＳ８００）。ステップＳ８００でエンジン始動を検知したら、ＥＣＵソフトウェア更新部２１４は、前回（直前）の車両２００のエンジン停止時に、図５で説明したＥＣＵソフトウェア更新処理を実行したか否かを確認する（ステップＳ８０１）。その結果、ＥＣＵソフトウェア更新処理を実行していなかった場合（Ｓ８０１：Ｎｏ）には、図６および図７の処理を終了する。なお、この後に図４に示す処理を行っても良い。

一方、ＥＣＵソフトウェア更新処理を実行していた場合（Ｓ８０１：Ｙｅｓ）には、ＥＣＵソフトウェア更新部２１４は、その処理結果が失敗であったか否かを確認する（ステップＳ８０２）。その結果、前回のＥＣＵソフトウェア更新処理に失敗していた場合（Ｓ８０２：Ｙｅｓ）、すなわち、直前のエンジン停止時に更新対象のＥＣＵのソフトウェアを正常に更新できていなかった場合には、処理をステップＳ８０３に進める。一方、前回のＥＣＵソフトウェア更新処理に成功していた場合（Ｓ８０２：Ｎｏ）、すなわち、直前のエンジン停止時に更新対象のＥＣＵのソフトウェアを正常に更新できていた場合には、処理を図７のステップＳ９０５に進める。

ステップＳ８０３において、ＥＣＵソフトウェア更新部２１４は、ソフトウェアの更新に失敗したＥＣＵが自力でのリカバリを実行不可能なものであるか否かを判定する。ここでは、ＥＣＵソフトウェア更新部２１４は、図４のステップＳ６０５においてテレマティクスセンタ１００からダウンロードされて記憶装置２１５に記憶された更新情報に基づいて、ステップＳ８０３の判定を行う。具体的には、当該ＥＣＵのＥＣＵ種別を検索キーとして、更新情報に含まれる車種構成情報の中から、当該ＥＣＵに対応するオフラインリカバリ機能４１４を検索し、その内容を確認することで、当該ＥＣＵが自力でのリカバリを実行不可能なものであるか否かを判定する。その結果、当該ＥＣＵに対応するオフラインリカバリ機能４１４の内容が「Ｔｒｕｅ」である場合には、当該ＥＣＵは自力でのリカバリを実行可能であると判定し（ステップＳ８０３：Ｎｏ）、処理をステップＳ８０４に進める。一方、当該ＥＣＵに対応するオフラインリカバリ機能４１４の内容が「Ｆａｌｓｅ」である場合には、当該ＥＣＵは自力でのリカバリを実行できないと判定し（ステップＳ８０３：Ｙｅｓ）、処理をステップＳ８０５に進める。

ステップＳ８０４において、ＥＣＵソフトウェア更新部２１４は、当該ＥＣＵに対してオフラインでの自力によるリカバリを実行すると決定する。この決定の後、ＥＣＵソフトウェア更新部２１４は、処理を図７のステップＳ９０３に進める。

ステップＳ８０５において、ＥＣＵソフトウェア更新部２１４は、車両２００に搭載されている通信部２２０が通信圏外であるか否か、すなわちソフトウェア更新装置２１０とテレマティクスセンタ１００とが通信不可能な状態であるか否かを判定する。その結果、通信部２２０が通信圏内であり、ソフトウェア更新装置２１０とテレマティクスセンタ１００とが通信可能である場合（ステップＳ８０５：Ｎｏ）には、処理をステップＳ８０６に進める。一方、通信部２２０が通信圏外であり、ソフトウェア更新装置２１０とテレマティクスセンタ１００とが通信不可能な場合（ステップＳ８０５：Ｙｅｓ）には、処理をステップＳ８０７に進める。

ステップＳ８０６において、ＥＣＵソフトウェア更新部２１４は、当該ＥＣＵに対してオンラインでのリカバリを実行すると決定する。この決定の後、ＥＣＵソフトウェア更新部２１４は、処理を図７のステップＳ９０１に進める。

ステップＳ８０７において、ＥＣＵソフトウェア更新部２１４は、車両２００を通信圏内に移動させることで、ソフトウェアの更新に失敗したＥＣＵのオンラインでのリカバリが実行可能であるか否かを判定する。ここでは、ＥＣＵソフトウェア更新部２１４は、図４のステップＳ６０５においてテレマティクスセンタ１００からダウンロードされて記憶装置２１５に記憶された更新情報に基づいて、ステップＳ８０７の判定を行う。具体的には、当該ＥＣＵのＥＣＵ種別を検索キーとして、更新情報に含まれる車種構成情報の中から、当該ＥＣＵに対応する機能カテゴリ４１３を検索し、その内容を確認することで、当該ＥＣＵが属する機能カテゴリを特定する。そして、特定した機能カテゴリを検索キーとして、更新情報に含まれる機能構成情報の中から、当該ＥＣＵに対応する圏内移動可否４２１を検索し、その内容を確認することで、当該ＥＣＵを使用せずに車両２００を通信圏内に移動させることが可能か否かを判定する。その結果、当該ＥＣＵに対応する圏内移動可否４２１の内容が「Ｆａｌｓｅ」である場合には、当該ＥＣＵを使用せずに車両２００を通信圏内に移動させることは不可能であると判定し（ステップＳ８０７：Ｎｏ）、処理をステップＳ８０８に進める。一方、当該ＥＣＵに対応する圏内移動可否４２１の内容が「Ｔｒｕｅ」である場合には、当該ＥＣＵを使用せずに車両２００を通信圏内に移動させることが可能であると判定し（ステップＳ８０７：Ｙｅｓ）、処理をステップＳ８０９に進める。

ステップＳ８０８において、ＥＣＵソフトウェア更新部２１４は、車両２００が走行不可能であり、車両２００を通信圏内に移動させることができないため、当該ＥＣＵのリカバリを断念すると決定する。この決定の後、ＥＣＵソフトウェア更新部２１４は、処理を図７のステップＳ９０５に進める。

ステップＳ８０９において、ＥＣＵソフトウェア更新部２１４は、車両２００を通信圏内に移動させるようにユーザに促す。ここでは、ＥＣＵソフトウェア更新部２１４は、ナビゲーション端末２３０の更新情報表示部２３２および入出力装置２３４を用いて、ユーザへの通知を行う。具体的には、更新情報表示部２３２の制御に応じた入出力装置２３４の画像表示や音声により、ソフトウェア更新装置２１０がテレマティクスセンタ１００と通信可能な位置まで車両２００を移動すべき旨のメッセージを出力することで、車両２００の通信圏内への移動をユーザに促す。さらにこの時、ＥＣＵソフトウェア更新部２１４は、図４のステップＳ６０５においてテレマティクスセンタ１００からダウンロードされて記憶装置２１５に記憶された更新情報に基づいて、移動中の車両２００の運用に対する制限の有無を判断し、制限があると判断した場合はその内容をユーザに通知する。具体的には、ステップＳ８０７において特定した機能カテゴリを検索キーとして、更新情報に含まれる機能構成情報の中から、当該ＥＣＵに対応する速度制限４２２、機能制限４２３およびユーザ通知内容４２４を検索する。そして、検索されたこれらのデータ内容に基づいて、移動中の車両２００の運用に対する速度制限や機能制限の有無を確認すると共に、ユーザへの通知内容を確認し、更新情報表示部２３２の制御に応じた入出力装置２３４の画像表示や音声により、ユーザへの通知を行う。これらの通知を行ったら、ＥＣＵソフトウェア更新部２１４は、車両２００が通信圏内に移動されるまで待機し、処理を図７のステップＳ９００に進める。

図７のステップＳ９００において、ＥＣＵソフトウェア更新部２１４は、車両２００に搭載されている通信部２２０が通信圏内になったか否かを定期的に確認する。

通信部２２０が通信圏内になった場合（Ｓ９００：Ｙｅｓ）、または、図６のステップＳ８０６においてオンラインでのリカバリを実行すると決定した場合には、ＥＣＵソフトウェア更新部２１４は、対象ＥＣＵのソフトウェアをリカバリするためのリカバリ用ソフトウェアをテレマティクスセンタ１００に要求する（ステップＳ９０１）。この要求を受信したら、テレマティクスセンタ１００の更新案件管理部１１２は、通知元の車両２００のＶＩＮが登録されているレコードを進捗管理ＤＢ１２５から検索し、該当レコードのステータス５１２を「リカバリ中」に更新する（ステップＳ９１０）。そして、更新案件管理ＤＢ１２４からアップデート前のソフトウェアデータなど、当該ＥＣＵのソフトウェアを更新前の状態に戻すためのデータを抽出し、それをリカバリ用ソフトウェアとして車両２００に送信する（ステップＳ９１１）。

ステップＳ９１１でテレマティクスセンタ１００から送信されたリカバリ用ソフトウェアは、車両２００のソフトウェア更新装置２１０において、通信部２２０により受信される（ステップＳ９０２）。ステップＳ９０２でリカバリ用ソフトウェアを受信したら、ソフトウェア更新装置２１０のＥＣＵソフトウェア更新部２１４は、受信したリカバリ用ソフトウェアを用いて、ソフトウェアの更新に失敗したＥＣＵのリカバリ処理を実行する（ステップＳ９０３）。そして、そのリカバリ結果をテレマティクスセンタ１００に通知する（ステップＳ９０４）。

車両２００のソフトウェア更新装置２１０からリカバリ結果の通知を受信したら、テレマティクスセンタ１００の更新案件管理部１１２は、通知元の車両２００のＶＩＮが登録されているレコードを進捗管理ＤＢ１２５から検索し、該当レコードのステータス５１２を「リカバリ完了」に更新する（ステップＳ９１２）。

ステップＳ９０４でリカバリ結果の通知を行ったら、ＥＣＵソフトウェア更新部２１４は、ナビゲーション端末２３０の更新情報表示部２３２および入出力装置２３４を用いて、そのリカバリ結果をユーザに通知するための画面表示を行う（ステップＳ９０５）。ここでは、ステップＳ９０３で実行したリカバリ処理の結果が成功または失敗のいずれであったかを示す画面が、入出力装置２３４において表示される。なお、リカバリ結果が失敗であった場合、車両２００が速度制限あるいは機能制限の下でしか移動できない状態が続き、車両２００の運用に対して制約が生じる。したがって、このような場合には、ユーザが最寄りの車両２００のディーラーにおいて根本的なリカバリ処理を施すことができるように、例えばディーラーの連絡先や、ディーラーまでのルートを入出力装置２３４に表示しても良い。また、図６および図７に示すリカバリ処理の終了後に、図４で説明した更新用ソフトウェアのダウンロード処理を実行することで、テレマティクスセンタ１００に車両構成情報を送信して更新案件の確認を行っても良い。

なお、図６のステップＳ８０８においてリカバリを断念すると決定した場合には、ステップＳ９０５において、ＥＣＵソフトウェア更新部２１４は、リカバリを断念したことをユーザに通知するための画面表示を行う。この場合、車両２００は走行不能であり、ユーザが車両２００を利用できない状態が続いてしまうことから、ユーザが最寄りの車両２００のディーラーに連絡して根本的なリカバリ処理を施すことができるように、例えばディーラーの連絡先を入出力装置２３４に表示しても良い。

なお、図６のステップＳ８０４においてオフラインでの自力によるリカバリを実行すると決定した場合には、ステップＳ９０３において、ＥＣＵソフトウェア更新部２１４は、リカバリ用ファイルを用いずに、オフラインでステップＳ９０３のリカバリ処理を実行する。このリカバリ処理に失敗した場合には、図６のステップＳ８０５に戻って通信部２２０が通信圏外であるか否かを確認することで、オンラインでのリカバリの実行可否を確認し、実行可能であればステップＳ８０６以降の処理を実行するようにしても良い。

また、図７のステップＳ９００において、一定時間以上経過しても通信部２２０が通信圏内にならない場合には、ＥＣＵソフトウェア更新部２１４は、図６および図７に示す処理を終了しても良い。その場合、処理終了前に、上記のリカバリ結果が失敗であった場合と同様に、ユーザが最寄りの車両２００のディーラーにおいて根本的なリカバリ処理を施すことができるように、例えばディーラーの連絡先や、ディーラーまでのルートを入出力装置２３４に表示しても良い。

以上説明した図６および図７の処理により、車両２００においてＥＣＵソフトウェアの更新に失敗した場合には、テレマティクスセンタ１００からダウンロードされて記憶装置２１５に記憶された更新情報に基づいて、リカバリ処理の内容が決定される。これにより、リカバリ処理におけるＥＣＵソフトウェア更新部２１４の動作が制御される。

図８は、本発明の第１の実施形態においてテレマティクスセンタ１００の入出力装置１３０に表示される画面の一例を示す図である。入出力装置１３０には、車両２００に搭載された複数のＥＣＵがそれぞれ属する機能カテゴリを示す画面として、例えば図８に示すような画面が表示される。

図８の画面は、符号１０００、１０１０、１０２０にそれぞれ示す画面領域により構成されている。画面領域１０００は、車種構成ＤＢ１２２の情報を可視化して示したものである。画面領域１０００では、車種構成ＤＢ１２２における車種ＩＤ４１０、ＥＣＵ種別４１１およびＥＣＵカテゴリ４１２の各情報に基づいて、車両２００に搭載された全てのＥＣＵの種別とカテゴリがツリー形状の図を用いて車種単位で表されている。画面領域１０１０、１０２０は、画面領域１０００で選択されたいずれかのＥＣＵ（図８の例では、自動運転ＥＣＵ２４５）について、車種構成ＤＢ１２２、機能構成ＤＢ１２３にそれぞれ記録された情報を可視化して示したものである。画面領域１０１０では、当該ＥＣＵに対応する車種構成ＤＢ１２２のＥＣＵ種別４１１、ＥＣＵカテゴリ４１２、機能カテゴリ４１３およびオフラインリカバリ機能４１４の各情報の内容が表されている。画面領域１０２０では、当該ＥＣＵに対応する機能構成ＤＢ１２３の機能カテゴリ４２０、圏内移動可否４２１、速度制限４２２、機能制限４２３、ユーザ通知内容４２４の各情報の内容が表されている。なお、画面領域１０１０、１０２０では、テレマティクスセンタ１００の管理者が入出力装置１３０を介して任意の情報を上書きすることで、車種構成ＤＢ１２２や機能構成ＤＢ１２３の内容を変更することもできる。

図９は、本発明の第１の実施形態において車両２００に搭載されたナビゲーション端末２３０の入出力装置２３４に表示される画面の一例を示す図である。

図９において、画面１１００は、図６のステップＳ８０９において、車両２００を通信圏内に移動させるようにユーザを促すために、入出力装置２３４に表示される画面の一例である。画面１１００は、符号１１０１、１１０２、１１０３にそれぞれ示す画面領域により構成されている。画面領域１１０１は、通信部２２０が現在通信圏外であり、オンラインでのＥＣＵソフトウェアのリカバリを行うためには車両２００を通信圏内に移動させることが必要である旨を示す領域である。画面領域１１０２は、通信部２２０の電波状況を示す領域である。画面領域１１０３は、車両２００の機能制限の状態を示す領域である。画面１１００では、これらの画面領域により、例えば自動運転ＥＣＵ２４５がソフトウェア更新に失敗し、車両２００は通信圏外のエリアにいる状況を示している。この場合、自動運転ＥＣＵ２４５のソフトウェア更新に失敗したため、車両２００において自動運転機能が強制的にオフとなるが、手動による運転には影響が無い。そのため、画面１１００を表示することで、ユーザに手動で車両２００を通信圏内エリアに移動するように促している。

図９において、画面１１１０は、図７のステップＳ９００において通信部２２０が通信圏内になったことを検知した際に、入出力装置２３４に表示される画面の一例である。画面１１１０では、テレマティクスセンタ１００と通信を行うことで、オンラインでの自動運転ＥＣＵ２４５のソフトウェアのリカバリを開始することをユーザに通知するメッセージが表示されている。

図９において、画面１１２０は、ＥＣＵソフトウェアのリカバリに成功した際に、図７のステップＳ９０５において入出力装置２３４に表示される画面の一例である。画面１１２０では、自動運転ＥＣＵ２４５のソフトウェアのリカバリに成功したことをユーザに通知するメッセージが表示されている。

なお、図９に示した画面例では、自動運転ＥＣＵ２４５のソフトウェアをリカバリする場合の例を示しているが、リカバリ対象とするＥＣＵに応じて画面の表示内容を変化させてもよい。

以上説明した本発明の第１の実施形態によれば、以下の作用効果を奏する。

（１）本実施形態のソフトウェア更新システムは、車両２００に搭載された車載機器であるＥＣＵのソフトウェアの更新を管理するものであり、車両２００に搭載されたソフトウェア更新装置２１０と、ソフトウェア更新装置２１０とネットワーク３００を介して通信を行うテレマティクスセンタ１００とを備える。テレマティクスセンタ１００は、ＥＣＵのソフトウェアを更新するための更新用ソフトウェアをソフトウェア更新装置２１０に配信する更新用ソフトウェア配信部１１３を有する。ソフトウェア更新装置２１０は、テレマティクスセンタ１００から配信された更新用ソフトウェアを記憶すると共に、ＥＣＵのソフトウェアの更新に失敗した場合の車両２００の運用への影響に関する更新情報を記憶する記憶装置２１５と、記憶装置２１５に記憶された更新用ソフトウェアを用いてＥＣＵのソフトウェアを更新するＥＣＵソフトウェア更新部２１４と、を有し、記憶装置２１５に記憶された更新情報に基づいてＥＣＵソフトウェア更新部２１４の動作を制御する。このようにしたので、ユーザにとって利用しやすいＯＴＡによる車載機器のソフトウェアの更新を実現することができる。

（２）ソフトウェア更新装置２１０のＥＣＵソフトウェア更新部２１４は、更新情報に基づいて、ＥＣＵのソフトウェアの更新に失敗した場合に行うリカバリ処理の内容を決定する（ステップＳ８０３〜８０９）。このようにしたので、リカバリ処理の内容を適切に決定することができる。

（３）テレマティクスセンタ１００は、ＥＣＵのソフトウェアを更新前の状態に戻すためのリカバリ用ソフトウェアをソフトウェア更新装置２１０に配信するリカバリ用ソフトウェア配信部１１４を有する。ソフトウェア更新装置２１０のＥＣＵソフトウェア更新部２１４は、ソフトウェア更新装置２１０がテレマティクスセンタ１００と通信可能である場合（ステップＳ８０５：Ｎｏ）には、リカバリ処理において、テレマティクスセンタ１００にリカバリ用ソフトウェアの配信を要求する（ステップＳ９０１）。一方、ソフトウェア更新装置２１０がテレマティクスセンタ１００と通信不可能である場合（ステップＳ８０５：Ｙｅｓ）には、リカバリ処理において、更新情報に基づいて車両２００の移動可否を判定する（ステップＳ８０７）。その結果、車両２００の移動が可能であれば、ソフトウェア更新装置２１０がテレマティクスセンタ１００と通信可能な位置まで車両２００を移動するようユーザに促して（ステップＳ８０９）、ソフトウェア更新装置２１０がテレマティクスセンタ１００と通信可能になったら（ステップＳ９００：Ｙｅｓ）、テレマティクスセンタ１００にリカバリ用ソフトウェアの配信を要求する（ステップＳ９０１）。このようにしたので、車両２００の位置が原因で、ソフトウェア更新装置２１０がテレマティクスセンタ１００と通信可能ではない場合であっても、ユーザに車両２００を移動させてオンラインでのリカバリ処理を実現することができる。

（４）ＥＣＵソフトウェア更新部２１４は、ステップＳ８０９において車両２００の移動をユーザに促す際に、更新情報に基づいて車両２００の運用に対する制限の有無を判断し、制限があると判断した場合は、図９の画面１１００に例示したように、その内容をユーザに通知する。このようにしたので、リカバリ対象のＥＣＵを使用できないために車両２００の運用に対して制限がある場合でも、ユーザに車両２００を安全に移動させることができる。

（５）テレマティクスセンタ１００の更新用ソフトウェア配信部１１３は、更新用ソフトウェアと共に更新情報をソフトウェア更新装置２１０に配信する（ステップＳ６１５）。ソフトウェア更新装置２１０の記憶装置２１５は、テレマティクスセンタ１００から配信された更新用ソフトウェアおよび更新情報を記憶する（ステップＳ６０６）。このようにしたので、車両２００のＥＣＵ構成に応じた更新情報を記憶装置２１５に記憶させることができる。

（６）車両２００に搭載された複数のＥＣＵは、車両２００の運用への影響度合いに応じて、例えば機能カテゴリＣ１〜Ｃ５のように、複数の機能カテゴリにグループ分けされている。更新情報は、車両２００に搭載された複数のＥＣＵがそれぞれ複数の機能カテゴリのいずれに属するかを表す情報である、機能カテゴリ４１３の情報を含む。このようにしたので、更新情報において各ＥＣＵの車両２００の運用への影響度合いを分かりやすく示すことができる。

（７）テレマティクスセンタ１００は、車両２００に搭載された複数のＥＣＵがそれぞれ属する機能カテゴリを画面表示する表示装置として、図８に例示したような画面を表示する入出力装置１３０を有する。このようにしたので、各ＥＣＵの機能をテレマティクスセンタ１００の管理者に分かりやすく提示することができる。

（第２の実施形態）
第１の実施形態では、車両２００のエンジンが停止している状態、すなわち車両２００が利用されていない状態で、更新対象とするＥＣＵのソフトウェアを更新する例を説明した。これに対して、第２の実施形態では、車両２００が走行中であっても、可能であれば更新対象とするＥＣＵのソフトウェアを更新する例を説明する。なお、第２の実施形態におけるソフトウェア更新システムの構成や、更新用ソフトウェアのダウンロード処理に関しては、第１の実施形態において図１〜図４で説明したものと同様である。そのため、以下ではこれらに関する説明は省略する。

図１０は、本発明の第２の実施形態において実行されるＥＣＵソフトウェア更新処理の流れを示す図である。図１０に示す処理は、車両２００に搭載されているソフトウェア更新装置２１０のＥＣＵソフトウェア更新部２１４およびナビゲーション端末２３０の更新情報表示部２３２と、テレマティクスセンタ１００の更新案件管理部１１２とによって行われる。なお、本実施形態では、第１の実施形態において図５で説明した処理の代わりに、図１０の処理が実行される。

図１０において、ＥＣＵソフトウェア更新部２１４は、テレマティクスセンタ１００からインストール開始指令を受領したら、車両２００のエンジンが停止されるまで待機せずに、即座にステップＳ１２００の判定を行う。ステップＳ１２００では、ＥＣＵソフトウェア更新部２１４は、更新対象のＥＣＵソフトウェアが車両２００の走行中に更新可能であるか否かを判定する。この判定は、第１の実施形態で説明した図６のステップＳ８０７と同様の方法により行うことができる。すなわち、更新情報に含まれる機能構成情報のうち、当該ＥＣＵが属する機能カテゴリの圏内移動可否４２１の内容を確認することで、当該ＥＣＵを使用せずに車両２００を走行させることが可能か否かを判定する。その結果、当該ＥＣＵに対応する圏内移動可否４２１の内容が「Ｆａｌｓｅ」である場合には、当該ＥＣＵを使用せずに車両２００を走行させることは不可能であると判定し（ステップＳ１２００：Ｎｏ）、図１０の処理を終了する。この場合、第１の実施形態と同様に、エンジン停止後に当該ＥＣＵのソフトウェア更新を試みる。一方、当該ＥＣＵに対応する圏内移動可否４２１の内容が「Ｔｒｕｅ」である場合には、当該ＥＣＵを使用せずに車両２００を走行させることが可能であると判定し（ステップＳ１２００：Ｙｅｓ）、処理をステップＳ１２０１に進める。

ステップＳ１２０１において、更新情報表示部２３２は、入出力装置２３４を用いて、更新用ソフトウェアのインストールを開始する旨をユーザに通知する。さらにこの時、更新情報表示部２３２は、第１の実施形態で説明した図６のステップＳ８０９と同様に、記憶装置２１５に記憶された更新情報に基づいて、走行中の車両２００の運用に対する制限の有無を判断し、制限があると判断した場合はその内容をユーザに通知する。すなわち、更新情報に含まれる機能構成情報のうち、当該ＥＣＵに対応する速度制限４２２、機能制限４２３およびユーザ通知内容４２４の内容に基づいて、走行中の車両２００の運用に対する速度制限や機能制限の有無を確認すると共に、ユーザへの通知内容を確認し、更新情報表示部２３２の制御に応じた入出力装置２３４の画像表示や音声により、ユーザへの通知を行う。また、図７のステップＳ７０２と同様に、更新を許諾するか否かの選択肢を併せて画面表示し、入出力装置２３４においていずれかの選択肢をユーザに選択させる。

ステップＳ１２０１でユーザへの更新通知を行ったら、ＥＣＵソフトウェア更新部２１４は、入出力装置２３４に対するユーザの入力操作に基づき、更新の許諾が得られたか否かを判定する（ステップＳ１２０２）。その結果、ユーザから更新の許諾が得られなかった場合（Ｓ１２０２：Ｎｏ）には、ＥＣＵソフトウェア更新部２１４は、その旨をテレマティクスセンタ１００に通知し（ステップＳ１２０５）、次に車両２００のエンジンがオフ状態になるまで待機状態に入る。この通知を車両２００から受信したら、テレマティクスセンタ１００の更新案件管理部１１２は、通知元の車両２００のＶＩＮが登録されているレコードを進捗管理ＤＢ１２５から検索し、該当レコードのステータス５１２を「ユーザ許諾取得待ち」に更新する（ステップＳ１２１１）。これ以降では、ユーザから更新の許諾を得られるまで、図１０の処理が繰り返される。

一方、ユーザから更新の許諾が得られた場合（Ｓ１２０２：Ｙｅｓ）には、ＥＣＵソフトウェア更新部２１４は、テレマティクスセンタ１００に対して、ダウンロード済みの更新用ファイルを用いたＥＵＣソフトウェアのアップデートを開始することを通知する（ステップＳ１２０３。このアップデート開始通知を受信したら、テレマティクスセンタ１００の更新案件管理部１１２は、通知元の車両２００のＶＩＮが登録されているレコードを進捗管理ＤＢ１２５から検索し、該当レコードのステータス５１２を「アップデート開始」に更新する（ステップＳ１２１０）。

ステップＳ１２０３でアップデート開始通知を行ったら、ＥＣＵソフトウェア更新部２１４は、テレマティクスセンタ１００からダウンロードされて記憶装置２１５に記憶された更新用ソフトウェアを用いて、更新対象のＥＣＵソフトウェアのアップデートを実行する（ステップＳ１２０４）。この時、車両２００が走行中であるか否かに関わらず、ステップＳ１２０４のアップデート処理を実行する。そして、アップデート実行結果をテレマティクスセンタ１００に通知する（ステップＳ１２０５）。この通知を車両２００から受信したら、テレマティクスセンタ１００の更新案件管理部１１２は、通知元の車両２００のＶＩＮが登録されているレコードを進捗管理ＤＢ１２５から検索し、該当レコードのステータス５１２を更新する（ステップＳ１２１１）。この時、アップデート実行結果が正常である旨の通知を受けた場合には、該当レコードのステータス５１２を「アップデート正常完了」に更新し、そうでない場合には、該当レコードのステータス５１２を「アップデート失敗」に更新する。なお、アップデートに失敗した場合には、第１の実施形態において図６および図７で説明したリカバリ処理を実行しても良い。

以上説明した図１０の処理により、車両２００が走行中であっても、更新対象のＥＣＵソフトウェアが車両２００の走行に対して影響のないものであれば、ユーザの承諾を得た上で、ダウンロード済みの更新用ソフトウェアを用いて当該ＥＣＵソフトウェアの更新を実行することができる。

以上説明した本発明の第２の実施形態によれば、ソフトウェア更新装置２１０のＥＣＵソフトウェア更新部２１４は、記憶装置２１５に記憶されている更新情報に基づいて、ＥＣＵのソフトウェアの更新中に車両２００が移動可能であるか否かを判定する（ステップＳ１２００）。その結果、車両２００の移動が可能であると判定した場合（ステップＳ１２００：Ｙｅｓ）は、車両２００の走行中にＥＣＵのソフトウェアを更新する（ステップＳ１２０４）。このようにしたので、車両２００の走行中にＥＣＵのソフトウェアを更新することができる。

（第３の実施形態）
第１の実施形態では、車両２００からの問い合わせに応じて、車両２００のＶＩＮが進捗管理ＤＢ１２５のＶＩＮ５１１に登録されているか否かを確認し、その確認結果を車両２００に通知することで、テレマティクスセンタ１００の処理負荷を考慮せずに更新案件の有無を通知する例を説明した。これに対して、第３の実施形態では、テレマティクスセンタ１００の処理負荷を考慮して、更新案件の有無を通知する例を説明する。なお、第３の実施形態におけるソフトウェア更新システムの構成に関しては、第１の実施形態において図１〜図３で説明したものと同様である。そのため、以下ではこれらに関する説明は省略する。

図１１は、本発明の第３の実施形態において実行される更新案件確認処理の流れを示す図である。図１１に示す処理は、テレマティクスセンタ１００の更新案件管理部１１２によって行われる。なお、本実施形態では、第１の実施形態で説明した更新用ソフトウェアのダウンロード処理において、図４のステップＳ６１２の処理の代わりに、図１１の処理が実行される。

図１１において、更新案件管理部１１２は、図４のステップＳ６１２と同様の方法により、問い合わせ元の車両２００に対する更新案件の有無を確認する（ステップＳ１３０１）。次に、更新案件管理部１１２は、ステップＳ１３０１の確認結果に基づき、更新案件が存在したか否かを判定する（ステップＳ１３０２）。その結果、更新案件が存在しない場合（Ｓ１３０２：Ｎｏ）には、処理をステップＳ１３１０に進める。

一方、更新案件が存在する場合（Ｓ１３０２：Ｙｅｓ）には、更新案件管理部１１２は、更新情報に含まれる車種構成情報のうち、その更新案件で更新対象とされるＥＣＵに対応する機能カテゴリ４１３の内容に基づいて、当該ＥＣＵの機能カテゴリを確認する（ステップＳ１３０３）。なお以降では、ステップＳ１３０３で確認された当該ＥＣＵの機能カテゴリを、機能カテゴリＣｘと表記する。すなわち、図２で示した車種構成ＤＢ１２２および機能構成ＤＢ１２３の例では、機能カテゴリＣｘにおけるｘの値は、１〜５のいずれかである。本実施形態では、この機能カテゴリＣｘにおけるｘの値を当該ＥＣＵのソフトウェア更新の優先度と見なして、以降の処理を実行する。すなわち、図２の例では、例えば機能カテゴリがＣ１であるエンジンＥＣＵ２４０やステアリングＥＣＵ２４２については、ソフトウェア更新の優先度が１であり、機能カテゴリがＣ５であるオーディオＥＣＵ２４８については、ソフトウェア更新の優先度が５であると見なす。このようにして、車両２００に搭載された複数のＥＣＵがそれぞれ属する機能カテゴリに基づいて、各ＥＣＵのソフトウェアの更新に対する優先度を設定することができる。この場合、優先度の数値が小さいほど、当該ＥＣＵのソフトウェア更新の優先度が高いことを示している。

次に、更新案件管理部１１２は、進捗管理ＤＢ１２５に登録されている全ての車両２００について、ステータス５１２を検索し、進捗状況がダウンロード未完了である更新案件のレコード、すなわちステータス５１２が「ダウンロード完了」やそれ以降の状態ではないレコードを抽出する（ステップＳ１３０４）。そして、抽出した各レコードの更新案件ＩＤ５１０から、更新案件管理ＤＢ１２４、車両構成ＤＢ１２１、車種構成ＤＢ１２２の順に検索して機能カテゴリ４１３を抽出することで、ダウンロード未完了の更新案件に対応する各ＥＣＵの機能カテゴリを求める。こうして求めた各ＥＣＵの機能カテゴリに基づき、機能カテゴリＣ１〜Ｃ５のそれぞれについてダウンロード未完了の更新案件の数をカウントする（ステップＳ１３０５）。そして、ダウンロード未完了の更新案件の全数に対して機能カテゴリＣ１〜Ｃ５の各カウント数が占める割合をそれぞれ算出する（ステップＳ１３０６）。こうして算出された機能カテゴリごとのカウント数の割合は、当該機能カテゴリに属する各ＥＣＵの更新用ソフトウェアの配信に要するテレマティクスセンタ１００の処理負荷に相当するものである。すなわち、更新案件管理部１１２において上記ステップＳ１３０４〜Ｓ１３０６の処理を実行することで、更新用ソフトウェアの配信に要するテレマティクスセンタ１００の処理負荷を、ＥＣＵの機能カテゴリごとに算出することができる。

続いて、更新案件管理部１１２は、ステップＳ１３０６で算出した各機能カテゴリのカウント数の割合に基づき、ステップＳ１３０３で抽出した更新対象のＥＣＵが属する機能カテゴリＣｘと同じか、それより高い優先度を有する機能カテゴリのカウント数の合計割合（Ａ％）を算出する（ステップＳ１３０７）。ここでは例えば、ステップＳ１３０６で算出したカウント数の割合が、Ｃ１からＣ５の順に、２４％、１２％、２８％、２０％、１６％であり、更新対象のＥＣＵの機能カテゴリがＣ３であった場合は、Ｃ１、Ｃ２、Ｃ３のカウント数の割合を合計することで、Ａ＝２４＋１２＋２８＝６４％と計算される。これにより、進捗管理ＤＢ１２５に登録されている全ての車両２００に搭載されている各ＥＣＵの優先度すなわち機能カテゴリに基づいて、ステップＳ１３０１で確認した更新案件で対象とされたＥＣＵと、更新用ソフトウェアのダウンロードが未完了で当該優先度と同じかより高い優先度を有するＥＣＵとを、テレマティクスセンタ１００の処理負荷の算出対象として特定することができる。そして、特定したこれらのＥＣＵについて、更新用ソフトウェアの配信に要するテレマティクスセンタ１００の処理負荷を算出することができる。

ステップＳ１３０７で上記の合計割合Ａ％を算出したら、更新案件管理部１１２は、現在のテレマティクスセンタ１００の余力が、算出したＡ％以上であるかを確認する（ステップＳ１３０８）。その結果、余力がＡ％以上であれば（Ｓ１３０８：Ｙｅｓ）処理をステップＳ１３０９に進め、Ａ％未満であれば（Ｓ１３０８：Ｎｏ）処理をステップＳ１３１０に進める。なお、ここで記述するテレマティクスセンタ１００の余力とは、テレマティクスセンタ１００が有する処理能力に対して現在の処理負荷がどの程度であるかを示す指標であり、例えば、テレマティクスセンタ１００を構成する中央演算処理装置１１０のＣＰＵの使用率を１００％から引いた値などが考えられる。なお、ＣＰＵの使用率ではなく、例えば記憶装置１２０の使用率、通信部１４０の使用率などからテレマティクスセンタ１００の処理負荷の余力を算出しても良いし、これらを複数組み合わせて算出しても良い。また、テレマティクスセンタ１００がクラウドサーバ上に構築されている場合には、そのクラウドサーバの利用料などを考慮しても良い。

例えば、テレマティクスセンタ１００の余力が８０％であり、前述のようにＡ＝６４％である場合には、余力がＡ％以上であるため、ステップＳ１３０８が肯定判定されてステップＳ１３０９に進む。この場合、更新案件管理部１１２は、ステップＳ１３０１で確認した更新案件、すなわち機能カテゴリＣｘ（今回の例ではＣ３）のＥＣＵに対する更新案件を処理する余裕がテレマティクスセンタ１００にあると判断する。そのため、問い合わせ元の車両２００に対して、「対象案件あり」と結果を送信するよう決定する（ステップＳ１３０９）。

一方、テレマティクスセンタ１００の余力が５０％であり、前述のようにＡ＝６４％である場合には、余力がＡ％未満であるため、ステップＳ１３０８が否定判定されてステップＳ１３１０に進む。この場合、更新案件管理部１１２は、ステップＳ１３０１で確認した更新案件、すなわち機能カテゴリＣｘ（今回の例ではＣ３）のＥＣＵに対する更新案件よりも優先すべき更新案件が他に存在し、テレマティクスセンタ１００の余力を残しておくべきと判断する。そのため、問い合わせ元の車両２００に対して、実際には対象案件が存在するにも関わらず、「対象案件なし」と結果を送信するよう決定する（ステップＳ１３１０）。なお、ステップＳ１３０２で更新案件が存在しないと判定された場合も同様に、ステップＳ１３１０において、「対象案件なし」と結果を送信するよう決定する。

更新案件管理部１１２は、ステップＳ１３０１で確認した更新案件で対象とされた各ＥＣＵについて、以上説明したような処理をそれぞれ実行する。その結果、テレマティクスセンタ１００の現在の処理負荷に応じた余力の範囲内で、実際に更新用ソフトウェアを配信してソフトウェアの更新対象とするＥＣＵが優先度順に選択される。更新案件における全てのＥＣＵについてステップＳ１３０９またはＳ１３１０の処理を実行したら、更新案件管理部１１２は、処理を図４のステップＳ６１３に進め、ステップＳ１３０９またはＳ１３１０で決定した結果を車両２００に送信する。

以上説明した図１１の処理により、更新案件管理部１１２は、テレマティクスセンタ１００の処理負荷と、テレマティクスセンタ１００において記憶された前述の車両２００の更新情報に相当する情報、すなわち車種構成ＤＢ１２２における更新案件に対応する機能カテゴリ４１３の情報とに基づいて、更新用ソフトウェア配信部１１３が配信する更新用ソフトウェアを管理することができる。換言すると、ある車両２００に対して更新案件が存在した場合であっても、各更新案件が対象とするＥＣＵの機能の重要度を軸に、テレマティクスセンタ１００の余力を考慮して、更新を先延ばしにするか否かを判断することができる。これにより、更新案件がテレマティクスセンタ１００に複数登録されている状況において、テレマティクスセンタ１００の処理負荷を考慮した上で、更新案件を複数跨いだ上で、更新対象とするＥＣＵの機能重要度に応じて優先的に更新用ソフトウェアを配信することができる。したがって、優先度の低い更新案件が多数登録された場合でも、それらの配信優先度を低下させることで、テレマティクスセンタ１００のインフラ増強を必要とせず、ソフトウェア更新システムを維持することができる。

なお、図１１の更新案件確認処理において、優先度は機能カテゴリで決定するのではなく、他の方法で決定しても良い。例えば、各更新案件に対して、更新案件管理ＤＢ１２４の更新案件ＩＤ５００に紐付く形で、別途優先度情報を付与することで対処しても良い。また、機能カテゴリではなく、車両構成ＤＢ１２１の車種ＩＤ４０１や、更新用ソフトウェアのファイルサイズなど、他の情報を基に優先度を自動的に決定する仕組みを導入しても良い。

さらに、図１１に示す処理は、図４のステップＳ６１２において車両２００からの問い合わせがある度に実行するのではなく、テレマティクスセンタ１００が定期的に実行しても良い。その場合、ステップＳ１３０９またはＳ１３１０で決定した結果を記憶装置１２０に保存しておき、車両２００からの問い合わせに応じてその結果をテレマティクスセンタ１００から車両２００に送信しても良いし、テレマティクスセンタ１００から定期的に送信した結果を車両２００において記憶装置２１５に保存しておいても良い。

さらに、本実施形態では、図１１に示した更新案件確認処理を図４のステップＳ６１２において実行することで、更新案件の有無を制御する方式として利用する例を説明した。しかし、その他にも例えば、図４のステップＳ６１５において図１１の更新案件確認処理を実行することで、テレマティクスセンタの処理負荷に応じて更新用ソフトウェアの配信を一時的に拒否したり、ダウンロードの通信帯域を狭めたりする方法として利用しても良い。また、第１の実施形態では、図５のステップＳ７０２において、入出力装置２３４を介してユーザからの許諾を取得する例を説明したが、ユーザが所有する携帯端末にメール等の手段で通知し、この通知に対する応答によりユーザからの許諾を取得することもできる。このようにした場合には、ユーザへの通知順序を決定する際に図１１で説明した方式を利用することで、機能カテゴリに基づく優先度が高い更新案件から優先的に通知するようにしても良い。

図１２は、本発明の第３の実施形態においてテレマティクスセンタ１００の入出力装置１３０に表示される画面の一例を示す図である。

図１２において、画面１４００に表示されているグラフは、横軸に時刻を示し、縦軸に、テレマティクスセンタ１００全体の処理負荷と、それに対する機能カテゴリ毎の処理負荷の割合とを示している。なお、機能カテゴリ毎の処理負荷の割合は、図１１のステップＳ１３０６で算出される各機能カテゴリのカウント数の割合に相当するものである。この画面１４００では、テレマティクスセンタ１００が一定の時間間隔、例えば１分毎に図１１に基づく更新案件確認処理を実行し、その計算結果を入出力装置１３０に表示した場合を想定している。

画面１４００において、例えば時刻Ｔ３では、機能カテゴリＣ１、Ｃ２の処理負荷の割合の合計が５０％程度であるのに対して、テレマティクスセンタ１００全体の処理負荷は６５％程度であり、テレマティクスセンタ１００の余力は３５％である。このため、図１１に基づく処理では、時刻Ｔ３においては、更新対象のＥＣＵの機能カテゴリがＣ１である場合にのみ、ステップＳ１３０８においてＹｅｓに分岐し、それ以外のＣ２〜Ｃ５の場合にはＮｏに分岐することになる。なお、図１２では、ステップＳ１３０８の判定結果がＮｏとなる更新対象のＥＣＵの機能カテゴリを網掛けで示している。すなわち、例えば時刻Ｔ３では、機能カテゴリＣ１のみが網掛けされておらず、機能カテゴリＣ２〜Ｃ５は網掛けで示されている。

以上説明した本発明の第３の実施形態によれば、テレマティクスセンタ１００の更新案件管理部１１２は、テレマティクスセンタ１００の処理負荷と、テレマティクスセンタ１００に記憶された更新情報とに基づいて、更新用ソフトウェア配信部１１３が配信する更新用ソフトウェアを管理する（ステップＳ１３０３〜Ｓ１３１０）。このようにしたので、テレマティクスセンタ１００の処理負荷を考慮して、テレマティクスセンタ１００から車両２００への更新用ソフトウェアの配信管理を行うことができる。

また、以上説明した本発明の第３の実施形態によれば、以下の作用効果を奏する。

（１）本実施形態のソフトウェア更新システムは、車両２００に搭載された車載機器であるＥＣＵのソフトウェアの更新を管理するものであり、車両２００に搭載されたソフトウェア更新装置２１０と、ソフトウェア更新装置２１０とネットワーク３００を介して通信を行うテレマティクスセンタ１００とを備える。テレマティクスセンタ１００は、ＥＣＵのソフトウェアを更新するための更新用ソフトウェアをソフトウェア更新装置２１０に配信する更新用ソフトウェア配信部１１３と、ＥＣＵのソフトウェア更新に対する優先度に基づいて、更新用ソフトウェア配信部１１３が配信する更新用ソフトウェアを管理する更新案件管理部１１２と、を有する。ソフトウェア更新装置２１０は、テレマティクスセンタ１００から配信された更新用ソフトウェアを記憶する記憶装置２１５と、記憶装置２１５に記憶された更新用ソフトウェアを用いてＥＣＵのソフトウェアを更新するＥＣＵソフトウェア更新部２１４と、を有する。このようにしたので、ユーザにとって利用しやすいＯＴＡによる車載機器のソフトウェアの更新を実現することができる。

（２）車両２００には、異なる機能をそれぞれ有する複数のＥＣＵ、すなわちエンジンＥＣＵ２４０、ＡＢＳＥＣＵ２４１、ステアリングＥＣＵ２４２、サスペンションＥＣＵ２４３、エアバックＥＣＵ２４４、自動運転ＥＣＵ２４５、キーレスエントリＥＣＵ２４６、エアコン制御ＥＣＵ２４７、およびオーディオＥＣＵ２４８が搭載されている。更新案件管理部１１２は、これら複数のＥＣＵがそれぞれ属する機能の重要度に基づいて優先度を設定する。具体的には、車両２００に搭載された複数のＥＣＵは、車両２００の運用への影響度合いに応じて、例えば機能カテゴリＣ１〜Ｃ５のように、複数の機能カテゴリにグループ分けされている。更新案件管理部１１２は、車両２００に搭載された複数のＥＣＵがそれぞれ属する機能カテゴリに基づいて優先度を設定する（ステップＳ１３０３）。このようにしたので、各ＥＣＵの優先度を適切に設定することができる。

（３）テレマティクスセンタ１００は、車両２００に搭載された複数のＥＣＵに対応する複数の更新用ソフトウェアを記憶する記憶装置１２０を有する。更新案件管理部１１２は、テレマティクスセンタ１００の処理負荷およびＥＣＵのソフトウェア更新に対する優先度に基づいて、複数のＥＣＵから少なくともいずれか一つを更新対象のＥＣＵとして選択する（ステップＳ１３０３〜Ｓ１３１０）。具体的には、更新案件管理部１１２は、車両２００に搭載された複数のＥＣＵのうち少なくともいずれか一つのＥＣＵについて、更新用ソフトウェアの配信に要するテレマティクスセンタ１００の処理負荷を算出する（ステップＳ１３０４〜Ｓ１３０７）。そして、テレマティクスセンタ１００の現在の処理負荷に応じたサーバの余力と、算出したテレマティクスセンタ１００の処理負荷とを比較し（ステップＳ１３０８）、その比較結果に基づいて更新対象のＥＣＵを決定する（ステップＳ１３０９、Ｓ１３１０）。更新用ソフトウェア配信部１１３は、ステップＳ６１５において、更新案件管理部１１２により選択された更新対象のＥＣＵに対応する更新用ソフトウェアをソフトウェア更新装置２１０に配信する。このようにしたので、テレマティクスセンタ１００の処理負荷を考慮して、ソフトウェアを更新するＥＣＵを適切に選択することができる。

（４）更新案件管理部１１２は、ステップＳ１３０７において、テレマティクスセンタ１００の処理負荷の算出対象とするＥＣＵを優先度に基づいて特定する。このようにしたので、テレマティクスセンタ１００の処理負荷を適切に算出することができる。

（５）テレマティクスセンタ１００は、ソフトウェア更新装置２１０をそれぞれ搭載した複数の車両２００とネットワーク３００を介して通信可能である。更新案件管理部１１２は、ステップＳ１３０７において、複数の車両２００にそれぞれ搭載されたＥＣＵの中から、テレマティクスセンタ１００の処理負荷の算出対象とするＥＣＵを特定する。このようにしたので、多様な車種が存在する複数の車両２００に搭載されている様々なＥＣＵの中から、処理負荷の算出対象とするＥＣＵを適切に特定することができる。

以上説明した実施形態や各種の変形例はあくまで一例であり、発明の特徴が損なわれない限り、本発明はこれらの内容に限定されるものではない。また、上記では種々の実施形態を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

１００：テレマティクスセンタ
１１０：中央演算処理装置
１１１：構成情報管理部
１１２：更新案件管理部
１１３：更新用ソフトウェア配信部
１１４：リカバリ用ソフトウェア配信部
１２０：記憶装置
１２１：車両構成ＤＢ
１２２：車種構成ＤＢ
１２３：機能構成ＤＢ
１２４：更新案件管理ＤＢ
１２５：進捗管理ＤＢ
１３０：入出力装置
１４０：通信部
２００：車両
２１０：ソフトウェア更新装置
２１１：中央演算処理装置
２１２：更新案件確認部
２１３：更新用ソフトウェア要求部
２１４：ＥＣＵソフトウェア更新部
２１５：記憶装置
２２０：通信部
２３０：ナビゲーション端末
２３１：中央演算処理装置
２３２：更新情報表示部
２３３：記憶装置
２３４：入出力装置
２４０：エンジンＥＣＵ
２４１：ＡＢＳＥＣＵ
２４２：ステアリングＥＣＵ
２４３：サスペンションＥＣＵ
２４４：エアバックＥＣＵ
２４５：自動運転ＥＣＵ
２４６：キーレスエントリＥＣＵ
２４７：エアコン制御ＥＣＵ
２４８：オーディオＥＣＵ

Claims (6)

1. 車両に搭載されたソフトウェア更新装置と、前記ソフトウェア更新装置とネットワークを介して通信を行うサーバとを備え、前記車両に搭載された制御装置のソフトウェアの更新を管理するソフトウェア更新システムであって、
   前記車両には、異なる機能をそれぞれ有する複数の前記制御装置が搭載されており、
   前記サーバは、
   前記制御装置のソフトウェアを更新するための更新用ソフトウェアを前記ソフトウェア更新装置に配信する更新用ソフトウェア配信部と、
   前記制御装置のソフトウェア更新に対する優先度に基づいて、前記更新用ソフトウェア配信部が配信する前記更新用ソフトウェアを管理する更新案件管理部と、
   複数の前記制御装置に対応する複数の前記更新用ソフトウェアを記憶するサーバ側記憶装置と、を有し、
   前記ソフトウェア更新装置は、
   前記サーバから配信された前記更新用ソフトウェアを記憶する車両側記憶装置と、
   前記車両側記憶装置に記憶された前記更新用ソフトウェアを用いて前記制御装置のソフトウェアを更新するソフトウェア更新部と、を有し、
   前記更新案件管理部は、
   複数の前記制御装置がそれぞれ有する前記機能の重要度に基づいて前記優先度を設定し、
   複数の前記制御装置のうち少なくともいずれか一つの制御装置について、前記更新用ソフトウェアの配信に要する前記サーバの処理負荷を算出し、
   前記サーバの現在の処理負荷に応じた前記サーバの余力と、算出した前記サーバの処理負荷とを比較し、その比較結果に基づいて、複数の前記制御装置から少なくともいずれか一つを更新対象の制御装置として選択し、
   前記更新用ソフトウェア配信部は、前記更新案件管理部により選択された前記更新対象の制御装置に対応する前記更新用ソフトウェアを前記ソフトウェア更新装置に配信するソフトウェア更新システム。
2. 請求項１に記載のソフトウェア更新システムにおいて、
   前記更新案件管理部は、前記サーバの処理負荷の算出対象とする制御装置を前記優先度に基づいて特定するソフトウェア更新システム。
3. 請求項１または２に記載のソフトウェア更新システムにおいて、
   前記サーバは、前記ソフトウェア更新装置をそれぞれ搭載した複数の前記車両と前記ネットワークを介して通信可能であり、
   前記更新案件管理部は、複数の前記車両にそれぞれ搭載された前記制御装置の中から、前記サーバの処理負荷の算出対象とする制御装置を特定するソフトウェア更新システム。
4. 請求項１から請求項３のいずれか一項に記載のソフトウェア更新システムにおいて、
   複数の前記制御装置は、前記車両の運用への影響度合いに応じて、予め複数の機能カテゴリにグループ分けされており、
   前記更新案件管理部は、複数の前記制御装置がそれぞれ属する前記機能カテゴリに基づいて前記優先度を設定するソフトウェア更新システム。
5. 請求項４に記載のソフトウェア更新システムにおいて、
   前記サーバは、複数の前記制御装置がそれぞれ属する前記機能カテゴリを画面表示する表示装置を有するソフトウェア更新システム。
6. 車両に搭載された異なる機能をそれぞれ有する複数の制御装置のソフトウェアの更新を管理するサーバであって、
   前記制御装置のソフトウェアを更新するための更新用ソフトウェアを前記車両に配信する更新用ソフトウェア配信部と、
   前記制御装置のソフトウェア更新に対する優先度に基づいて、前記更新用ソフトウェア配信部が配信する前記更新用ソフトウェアを管理する更新案件管理部と、
   複数の前記制御装置に対応する複数の前記更新用ソフトウェアを記憶するサーバ側記憶装置と、を備え、
   前記更新案件管理部は、
   複数の前記制御装置がそれぞれ有する前記機能の重要度に基づいて前記優先度を設定し、
   複数の前記制御装置のうち少なくともいずれか一つの制御装置について、前記更新用ソフトウェアの配信に要する前記サーバの処理負荷を算出し、
   前記サーバの現在の処理負荷に応じた前記サーバの余力と、算出した前記サーバの処理負荷とを比較し、その比較結果に基づいて、複数の前記制御装置から少なくともいずれか一つを更新対象の制御装置として選択し、
   前記更新用ソフトウェア配信部は、前記更新案件管理部により選択された前記更新対象の制御装置に対応する前記更新用ソフトウェアを前記車両に配信するサーバ。

Images