特許 7396216 サーバ、更新管理方法、更新管理プログラム及びソフトウェア更新装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-12-04

(45)【発行日】2023-12-12

(54)【発明の名称】サーバ、更新管理方法、更新管理プログラム及びソフトウェア更新装置

(51)【国際特許分類】

   G06F 8/65 20180101AFI20231205BHJP

   B60R 16/02 20060101ALI20231205BHJP

【ＦＩ】

G06F8/65

B60R16/02 660U

【請求項の数】 9

(21)【出願番号】P 2020110693

(22)【出願日】2020-06-26

(65)【公開番号】P2022007618

(43)【公開日】2022-01-13

【審査請求日】2022-05-23

【前置審査】

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】110001276

【氏名又は名称】弁理士法人小笠原特許事務所

(72)【発明者】

【氏名】高綱 雄介

【審査官】松平 英

(56)【参考文献】

【文献】特開２０１７－１３４５０６（ＪＰ，Ａ）

【文献】特開２０１９－０７４８００（ＪＰ，Ａ）

【文献】特開２０１８－１０６４６１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｂ６０Ｒ ９／００－１１／０６

１６／００－２１／１３

２１／３４－９９／００

Ｇ０６Ｆ ８／００－８／３８

８／６０－８／７７

９／４４－９／４４５

９／４５１

(57)【特許請求の範囲】

【請求項1】

車両に搭載された電子制御ユニットのソフトウェアの更新を実行する際に、前記車両が満たすべき２以上の前提条件を含む前提条件情報を記憶する第１記憶部と、
前記車両からの要求に基づいて、前記前提条件情報を前記車両に送信する通信部と、
前記第１記憶部とは異なる第２記憶部と、を備え、
前記通信部は、前記前提条件情報に含まれる前記２以上の前記前提条件のうち、前記車両が満たさないと判定された前提条件を含むエラー情報を前記車両から受信し、前記エラー情報を前記車両毎に前記第２記憶部に記憶させる、サーバ。

【請求項2】

前記エラー情報に基づいて、前記エラー情報に対応する車両の前提条件を設定する制御部を備える、請求項１に記載のサーバ。

【請求項3】

プロセッサと、メモリと、記憶装置とを備えるコンピュータが実行する更新管理方法であって、
車両に搭載された電子制御ユニットのソフトウェアの更新を実行する際に、前記車両が満たすべき２以上の前提条件を含む前提条件情報を前記記憶装置の第１記憶部に記憶させるステップと、
前記車両からの要求に基づいて、前記前提条件情報を前記車両に送信するステップと、
前記前提条件情報に含まれる前記２以上の前記前提条件のうち、前記車両が満たさないと判定された前提条件を含むエラー情報を前記車両から受信するステップと、
前記エラー情報を前記車両毎に前記記憶装置の第２記憶部に記憶させるステップとを含む、更新管理方法。

【請求項4】

プロセッサと、メモリと、記憶装置とを備えるコンピュータに実行させる更新管理プログラムであって、
車両に搭載された電子制御ユニットのソフトウェアの更新を実行する際に、前記車両が満たすべき２以上の前提条件を含む前提条件情報を前記記憶装置の第１記憶部に記憶させるステップと、
前記車両からの要求に基づいて、前記前提条件情報を前記車両に送信するステップと、
前記前提条件情報に含まれる前記２以上の前記前提条件のうち、前記車両が満たさないと判定された前提条件を含むエラー情報を前記車両から受信するステップと、
前記エラー情報を前記車両毎に前記記憶装置の第２記憶部に記憶させるステップとを含
む、更新管理プログラム。

【請求項5】

車両搭載された電子制御ユニットのソフトウェアの更新を実行する際に、前記車両が満たすべき２以上の前提条件を含む前提条件情報をサーバから受信する通信部と、
前記通信部が取得した前記前提条件情報に含まれる前記２以上の前記前提条件が満たされるか否かを判定し、全ての前記前提条件が満たされると判定すると、前記電子制御ユニットのソフトウェアの更新を実行する制御部とを備え、
前記通信部は、前記制御部が前記２以上の前記前提条件のうち少なくとも１つが満たされないと判定したとき、前記前提条件情報に含まれる前記２以上の前記前提条件のうち前記制御部が満たしていないと判定した前記前提条件を含むエラー情報を前記サーバへ送信する、ソフトウェア更新装置。

【請求項6】

前記制御部は、前記ソフトウェアの更新を開始した後に、全ての前記前提条件が満たされないと判定した場合、ソフトウェアの更新を中断する、請求項５に記載のソフトウェア更新装置。

【請求項7】

前記制御部は、全ての前記前提条件が満たされないと判定してから所定時間が経過する前に、全ての前記前提条件が満たされると判定した場合、前記ソフトウェアの更新を開始する、請求項５または６に記載のソフトウェア更新装置。

【請求項8】

車両に搭載された電子制御ユニットのソフトウェアの更新を実行する際に、前記車両が満たすべき２以上の前提条件を含む前提条件情報を記憶する第１記憶部と、
前記車両からの要求に基づいて、前記前提条件情報を前記車両に送信する通信部と、
前記第１記憶部とは異なる第２記憶部と、を備え、
前記通信部は、前記前提条件情報に含まれる前記２以上の前記前提条件のうち、前記車両が満たさないと判定された前提条件を含むエラー情報を前記車両から受信し、前記エラー情報を前記車両毎に前記第２記憶部に記憶させる、センタ。

【請求項9】

車両に搭載された電子制御ユニットのソフトウェアの更新を実行する際に、前記車両が満たすべき２以上の前提条件を含む前提条件情報をセンタから受信する通信部と、
前記通信部が取得した前記前提条件情報に含まれる前記２以上の前記前提条件を満たすか否かを判定し、全ての前記前提条件が満たすと判定すると、前記電子制御ユニットのソフトウェアの更新を開始する制御部とを備え、
前記通信部は、前記制御部が前記２以上の前記前提条件のうち少なくとも１つが満たされないと判定したとき、前記前提条件情報に含まれる前記２以上の前記前提条件のうち前記制御部が満たしていないと判定した前記前提条件を含むエラー情報を前記センタへ送信する、ＯＴＡマスタ。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、電子制御ユニットのソフトウェアを更新するためのサーバ、更新管理方法、更新管理プログラム及びソフトウェア更新装置に関する。

【背景技術】

【0002】

車両には、車両の動作を制御するための複数の電子制御ユニット（ＥＣＵ）が搭載されている。ＥＣＵは、プロセッサと、ＲＡＭのような一時的な記憶部と、フラッシュＲＯＭのような不揮発性の記憶部とを備え、プロセッサが不揮発性の記憶部に記憶されるソフトウェアを実行することによりＥＣＵの制御機能を実現する。各ＥＣＵが記憶するソフトウェアは書き換え可能であり、より新しいバージョンのソフトウェアに更新することにより、各ＥＣＵの機能を改善したり、新たな車両制御機能を追加したりすることができる。

【0003】

ＥＣＵのソフトウェアは、整備工場等において、車両に設けられたダイアグ用コネクタを介して接続した外部機器を用いて更新することができるが、この他に、車載ネットワークが備える通信機器とインターネット等の通信ネットワークとを無線で接続し、無線通信を介してセンタに設けられたサーバから車両に更新プログラムをダウンロードし、ダウンロードしたプログラムで更新を行う方法がある。

【0004】

例えば、特許文献１には、無線通信を介してセンタに設けられたプログラム提供装置から制御プログラムを取得し更新できるプログラム更新装置が記載されている。特許文献１に記載のプログラム更新装置は、車両の制御装置の制御プログラムの書き込みを行う前に、車両の制御装置に対してチェックを行い、制御プログラムの更新が正常に行えるかを事前に判定する。具体的なチェック項目としては、制御プログラムのバッテリの残量や、天候、停車位置、プログラム更新機能の正常性が例示されている。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２０２０－００４２４５号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

特許文献１に記載のプログラム更新装置は、車両のプログラムを更新する際に、バッテリ残量やカーナビゲーションシステムから取得した情報が予め定められた条件を満たすか否かに基づき、プログラムの更新処理を実行可能であるか否かを判定している。

【0007】

しかしながら、車両に搭載されるバッテリの容量やカーナビゲーションシステム等の装備の有無は、車種やグレード、オプションの選択状況等に応じて異なることが考えられる。車両の構成を加味せず、ソフトウェアの更新時に車両が満たすべき前提条件を一律に設定すると、設定した前提条件が車両の実際の構成と合わないことにより、ソフトウェアが適時に更新されないケースが生じる可能性がある。

【0008】

それ故に、本開示は、車両の構成等に応じてソフトウェア更新の実行を制御できるサーバ、更新管理方法、更新管理プログラム及びソフトウェア更新装置を提供することを目的とする。

【課題を解決するための手段】

【0009】

本開示に係るサーバは、車両に搭載された電子制御ユニットのソフトウェアの更新を実行する際に、車両が満たすべき２以上の前提条件を含む前提条件情報を記憶する第１記憶部と、車両からの要求に基づいて、前提条件情報を車両に送信する通信部と、第１記憶部とは異なる第２記憶部と、を備え、通信部は、前提条件情報に含まれる２以上の前提条件のうち、車両が満たさないと判定された前提条件を含むエラー情報を車両から受信し、エラー情報を車両毎に第２記憶部に記憶させる。

【0010】

本開示に係る更新管理方法は、プロセッサと、メモリと、記憶装置とを備えるコンピュータが実行する方法であって、車両に搭載された電子制御ユニットのソフトウェアの更新を実行する際に、車両が満たすべき２以上の前提条件を含む前提条件情報を記憶装置の第１記憶部に記憶するステップと、車両からの要求に基づいて、前提条件情報を車両に送信するステップと、前提条件情報に含まれる２以上の前提条件のうち、車両が満たさないと判定された前提条件を含むエラー情報を車両から受信するステップと、エラー情報を車両毎に記憶装置の第２記憶部に記憶させるステップとを含む。

【0011】

本開示に係る更新管理プログラムは、プロセッサと、メモリと、記憶装置とを備えるコンピュータに実行させる更新管理プログラムであって、車両に搭載された電子制御ユニットのソフトウェアの更新を実行する際に、車両が満たすべき２以上の前提条件を含む前提条件情報を記憶装置の第１記憶部に記憶するステップと、車両からの要求に基づいて、前提条件情報を車両に送信するステップと、前提条件情報に含まれる２以上の前提条件のうち、車両が満たさないと判定された前提条件を含むエラー情報を車両から受信するステップと、エラー情報を車両毎に記憶装置の第２記憶部に記憶させるステップとを含む。

【0012】

本開示に係るソフトウェア更新装置は、車両に搭載された電子制御ユニットのソフトウェアの更新を実行する際に、車両が満たすべき２以上の前提条件を含む前提条件情報をサーバから受信する通信部と、通信部が取得した前提条件情報に含まれる２以上の前提条件が満たされるか否かを判定し、全ての前提条件が満たされると判定すると、電子制御ユニットのソフトウェアの更新を実行する制御部とを備え、通信部は、制御部が２以上の前提条件のうち少なくとも１つが満たされないと判定したとき、前提条件情報に含まれる２以上の前提条件のうち制御部が満たしていないと判定した前提条件を含むエラー情報をサーバへ送信する。

【発明の効果】

【0013】

本開示によれば、車両の構成等に応じてソフトウェア更新の実行を制御できるサーバ、更新管理方法、更新管理プログラム及びソフトウェア更新装置を提供できる。

【図面の簡単な説明】

【0014】

【図1】実施形態に係るネットワークシステムの全体構成を示すブロック図

【図2】図１に示したサーバの概略構成を示すブロック図

【図3】図１に示したソフトウェア更新装置の概略構成を示すブロック図

【図4】図１に示したサーバの機能ブロック図

【図5A】図１に示したサーバが記憶する前提条件情報の一例を示す図

【図5B】図１に示したサーバが記憶する前提条件情報の他の一例を示す図

【図6】図１に示したサーバが記憶するエラー情報の一例を示す図

【図7】図１に示したソフトウェア更新装置の機能ブロック図

【図8】実施形態に係るサーバが実行する制御処理の一例を示すフローチャート

【図9】実施形態に係るソフトウェア更新装置が実行する制御処理の一例を示すフローチャート

【発明を実施するための形態】

【0015】

図１は、実施形態に係るネットワークシステムの全体構成を示すブロック図であり、図２は、図１に示したサーバの概略構成を示すブロック図であり、図３は、図１に示した更新制御装置の概略構成を示すブロック図である。

【0016】

図１に示すネットワークシステムは、車両に搭載された電子制御ユニット１３ａ～１３ｄのソフトウェアを更新するためのシステムであり、サーバ１（センタ）と、車両に搭載される車載ネットワーク２とを備える。

【0017】

サーバ１は、ネットワーク５を介して車両に搭載されたソフトウェア更新装置１１と通信可能であり、車両に搭載された電子制御ユニット１３ａ～１３ｄの更新データの有無や、ソフトウェア更新装置１１が行うソフトウェア更新処理に関する情報を管理する。

【0018】

図２に示すように、サーバ１は、ＣＰＵ２１と、ＲＡＭ２２と、記憶装置２３と、通信装置２４とを備える。記憶装置２３は、ハードディスクやＳＳＤ等の読み書き可能な記憶媒体を備え、ソフトウェアの更新管理を実行するためのソフトウェアや、後述する前提条件情報やエラー情報を記憶する。サーバ１において、ＣＰＵ２１は、記憶装置２３から読み出したソフトウェアを、ＲＡＭ２２を作業領域として用いて実行することにより、後述する制御処理を実行する。通信装置２４は、インターネット等のネットワーク５を介してソフトウェア更新装置１１と通信を行うための機器である。

【0019】

車載ネットワーク２は、ソフトウェア更新装置１１（ＯＴＡマスタ）と、通信モジュール１２と、複数の電子制御ユニット１３ａ～１３ｄと、表示装置１４とを備える。ソフトウェア更新装置１１は、バス１５ａを介して通信モジュール１２と接続され、バス１５ｂを介して電子制御ユニット１３ａ及び１３ｂと接続され、バス１５ｃを介して電子制御ユニット１３ｃ及び１３ｄと接続され、バス１５ｄを介して表示装置１４と接続されている。ソフトウェア更新装置１１は、通信モジュール１２及びネットワーク５を介してサーバ１と無線（On The Air）で通信可能であり、サーバ１から取得した更新データ及び後述する前提条件情報に基づいて、電子制御ユニット１３ａ～１３ｄのうちの更新対象の機器のソフトウェア更新を制御する。ソフトウェア更新装置１１は、セントラルゲートウェイと称される場合もある。通信モジュール１２は、車載ネットワーク２とセンタに設けられるサーバ１とを接続する通信装置である。電子制御ユニット１３ａ～１３ｄは、車両の各部の動作を制御するＥＣＵであり、ＣＰＵと、ＲＡＭと、フラッシュメモリやＥＥＰＲＯＭ等の不揮発性の記憶装置とを備え、ＣＰＵがＲＡＭを作業領域として用いて、記憶装置に記憶されたソフトウェアを実行することにより制御機能を実行する。表示装置１４（ＨＭＩ）は、電子制御ユニット１３ａ～１３ｄのソフトウェアの更新処理時に、更新データがあることの表示や、ユーザに対してソフトウェア更新の許諾要求を求める表示、更新結果の表示等の各種表示を行うために用いられる。表示装置１４としては、典型的にはカーナビゲーションシステムの表示装置を用いることができるが、ソフトウェアの更新処理時に必要な情報を表示可能なものであれば特に限定されない。尚、図１においては、４つの電子制御ユニット１３ａ～１３ｄを例示したが、電子制御ユニットの数は特に限定されない。また、図１に示すバス１５ｄには、表示装置１４以外の電子制御ユニットが更に接続されていても良い。

【0020】

図３に示すように、ソフトウェア更新装置１１は、ＣＰＵ３１と、ＲＡＭ３２と、ＲＯＭ３３と、記憶装置３４とを備えるマイクロコンピュータ３５と、通信装置３６とを備える。ソフトウェア更新装置１１において、マイクロコンピュータ３５のＣＰＵ３１は、ＲＯＭ３３から読み出したソフトウェアを、ＲＡＭ３２を作業領域として用いて実行することにより、後述する制御処理を実行する。通信装置３６は、図１に示したバス１５ａ～１５ｄを介して、通信モジュール１２、電子制御ユニット１３ａ～１３ｄ、表示装置１４と通信を行う機器である。

【0021】

図４は、図１に示したサーバの機能ブロック図であり、図５Ａ及び図５Ｂは、図１に示したサーバが記憶する前提条件情報の一例を示す図であり、図６は、図１に示したサーバが記憶するエラー情報の一例を示す図である。

【0022】

サーバ１は、第１記憶部２６と、第２記憶部２７と、通信部２８と、制御部２９とを備える。第１記憶部２６及び第２記憶部２７は、図２に示した記憶装置２３によって実現され、通信部２８及び制御部２９は、図２に示したＣＰＵ２１がＲＡＭ２２を用いて記憶装置２３に記憶されるソフトウェアを実行することにより実現される。

【0023】

第１記憶部２６は、前提条件情報を記憶する。前提条件情報は、車両において電子制御ユニット１３ａ～１３ｄのいずれかのソフトウェアを更新する際に車両が満たすべき前提条件を定義した情報である。前提条件情報の例を図５Ａ及び図５Ｂに示す。

【0024】

図５Ａに示す前提条件情報は、車両を識別する車両ＩＤと、当該車両ＩＤで特定される車両においてソフトウェア更新装置１１がソフトウェア更新処理を実行する際に、当該車両ＩＤで特定される車両が満たすべき前提条件を関連付けた情報である。車両ＩＤは、車両を一意に識別できる情報であれば良く、例えば、車両識別番号（ＶＩＮ）や車台番号である。１つの車両ＩＤに対して１以上の前提条件を設定することができる。図５Ａの例では、車両ＩＤ「ＶＩＤ＿１００１」に対して２つの前提条件が設定され、車両ＩＤ「ＶＩＤ＿２００１」に対して３つの前提条件が設定されている。車両ＩＤ毎に設定される前提条件の種類及び数は、当該車両ＩＤで特定される車両のグレードや装備、オプションの有無に応じて変更することができる。

【0025】

図５Ｂに示す前提条件情報は、車種を識別する車種ＩＤと、当該車種ＩＤで特定される車両においてソフトウェア更新装置１１がソフトウェア更新処理を実行する際に、当該車種ＩＤで特定される車両が満たすべき前提条件を関連付けた情報である。車種ＩＤは、典型的には、型式を示す情報であるが、車両の型式を一意に識別できる情報であれば良く、車両識別番号（ＶＩＮ）や車台番号に含まれる情報の一部または複数部分の組み合わせによって表しても良い。図５Ｂの例においても、車種ＩＤ毎に１以上の前提条件を設定することができる。

【0026】

ここで、ソフトウェア更新処理を実行する際に車両が満たすべき前提条件の具体例を説明する。前提条件の例としては、バッテリ残量、ＤＣ－ＤＣコンバータの動作状態、更新対象の電子制御ユニットにおけるエラーの発生状況、特定のセンサまたはアクセサリの搭載状況、更新対象の電子制御ユニットの機能の有効性、シフトレンジ、車速、ＧＰＳ座標等が挙げられる。バッテリ残量及びＤＣ－ＤＣコンバータの動作状態は、ソフトウェア更新処理の実行に必要な電力が確保されていることを要求する条件であり、ソフトウェア更新処理に必要な電力及び車両のその他の機能維持に必要な電力を供給可能なバッテリ残量の値や、駆動用バッテリから補記バッテリへと電力供給を行うＤＣ－ＤＣコンバータが動作中であることを条件として定義することができる。更新対象の電子制御ユニットにおけるエラーの発生状況は、更新対象の電子制御ユニットにおいてソフトウェア更新処理の実行の妨げとなるエラー（例えば、電子制御ユニット自体の動作不良、データ格納領域の容量不足やデータ格納領域へのアクセス不可）が生じていないことを要求する条件である。特定のセンサまたはアクセサリの搭載状況は、更新対象の電子制御ユニットが動作するために必要なセンサやアクセサリ等の機器が車両に搭載されていることを要求する条件である。更新対象の電子制御ユニットの機能の有効性は、ユーザにより、更新対象の電子制御ユニットの機能を利用することが設定されていることを要求する条件である。シフトレンジ、車速、ＧＰＳ座標は、ソフトウェア更新処理の実行時に、車両が安全な状態にあることを要求する条件であり、具体的には、シフトレンジがＰレンジであること、車速が０ｋｍ／ｈであること、現在のＧＰＳ座標が駐車場や停車可能エリアなどの公道上以外の座標範囲内であることを定義することができる。尚、説明した前提条件は例示であり、その他の前提条件を定義することも可能である。また、前提条件は、特定の閾値、数値範囲、条件を満足するか否かの二値等で表すことができる。

【0027】

図５Ａに示したように、車両毎に前提条件情報を定義する場合、車両毎の装備やユーザ設定等に応じてソフトウェア更新処理に必要な条件を細かく設定することができる。一方、図５Ｂに示したように、車種毎に前提条件情報を定義する場合、バッテリ容量や搭載されているセンサ類等の車種間の装備の差に応じて、ソフトウェア更新処理に必要な条件を車種毎に適した態様で設定することができる。

【0028】

第２記憶部２７は、エラー情報を記憶する。エラー情報は、ソフトウェア更新装置１１に送信された前提条件情報に含まれる前提情報のうち、ソフトウェア更新装置１１によるソフトウェア更新処理の開始前または実行中に更新制御装置によって満たされないと判定された前提条件を特定する情報である。エラー情報は、車両を識別する車両ＩＤと、ソフトウェア更新処理時にエラーとなった前提条件を関連付けた情報である。エラー情報は、前提条件を満たさないことによりエラーとなった日時の情報を含んでも良い。第２記憶部２７に記憶されるエラー情報は、ソフトウェア更新処理が正常に実行されなかった原因を特定したり、車両毎にソフトウェア更新処理に必要な個別の対応を行ったりするための情報として利用することができる。

【0029】

通信部２８は、ソフトウェア更新装置１１からの要求に基づき、当該ソフトウェア更新装置１１に適用される前提条件情報を第１記憶部２６から取得し、取得した前提情報をソフトウェア更新装置１１に送信する。また、通信部２８は、ソフトウェア更新装置１１に送信された前提条件情報に含まれる全ての前提情報のうち、ソフトウェア更新処理時に、ソフトウェア更新装置１１によって満たされないと判定された前提条件を含むエラー情報を、ソフトウェア更新装置１１から受信する。通信部２８は、受信したエラー情報を上述した第２記憶部２７に車両毎に記憶させる。また、通信部２８は、ソフトウェア更新装置１１から送信される種々の要求（後述するソフトウェアの更新確認要求や、前提条件情報の送信要求）を受け付ける。

【0030】

制御部２９は、ソフトウェア更新装置１１から受信したエラー情報に基づいて、エラー情報に対応する車両の前提条件を設定する。エラー情報に基づいて前提条件を設定する例として、一時的に車両が満たすべき前提条件の一部を緩和することが考えられる。例えば、ソフトウェアの更新時に車両が満たすべき前提条件としてバッテリ残量が設定されている場合を想定する。前提条件として設定されるバッテリ残量（ｒ１）は、ソフトウェア更新処理や車両の機能維持に必要な最低限の残量（ｒ０）に一定のマージンを加えた値に設定される。バッテリ残量の前提条件を満たさないことによってエラーとなりソフトウェア更新が行われなかった場合、前提条件とするバッテリ残量を、最低限の残量（ｒ０）より高く、かつ、当初設定されていたバッテリ残量（ｒ１）より低い値に設定することにより、エラーを解消しタイムリーにソフトウェア更新を行うことが可能となる。

【0031】

図７は、図１に示したソフトウェア更新装置の機能ブロック図である。

【0032】

ソフトウェア更新装置１１は、通信部３７と、記憶部３８と、制御部３９とを備える。通信部３７及び制御部３９は、図３に示したＣＰＵ３１がＲＡＭ３２を用いてＲＯＭ３３に記憶されるソフトウェアを実行することにより実現され、記憶部３８は、図３に示した記憶装置３４によって実現される。

【0033】

通信部３７は、車両の電源またはイグニッションがオンされた際等の所定のタイミングで、電子制御ユニット１３ａ～１３ｄのソフトウェアの更新データがあるか否かを確認するための確認要求をサーバ１に送信し、サーバ１における確認結果（更新データがあるか否かを示す情報）を受信する。また、通信部３７は、配信パッケージのダウンロード要求をサーバ１に送信し、サーバ１から送信される配信パッケージを受信する。サーバ１から送信される配信パッケージは、更新対象の１以上の電子制御ユニットのソフトウェア更新に用いる更新データと、上述した前提条件情報とを含む。配信パッケージは、更新データの真正性を検証するための検証用データや、更新データの数、インストール順、ソフトウェア更新時に用いる各種制御情報等を含んでいても良い。通信部３７は、受信した配信パッケージを記憶部３８に記憶させる。通信部３７は、受信した更新データの真正性を検証する。また、通信部３７は、後述する制御部３９によって生成されたエラー情報をサーバ１に送信する。

【0034】

記憶部３８は、通信部３７がサーバ１から受信した配信パッケージを記憶する。

【0035】

制御部３９は、ソフトウェア更新装置１１が搭載された車両における電子制御ユニット１３ａ～１３ｄのソフトウェア更新を制御する。

【0036】

制御部３９は、通信部３７がサーバ１から受信した配信パッケージに含まれる前提条件情報を参照し、前提条件情報に含まれる前提条件が満たされるか否かを判定する。制御部３９は、バス１５ｂ及び１５ｃを介して接続された電子制御ユニット１３ａ～１３ｄから、車両の状態に関する情報を取得し、取得した情報に基づいて前提条件情報に含まれる前提条件が満たされるか否かを判定する。車両の状態に関する情報としては、バッテリ残量、ＤＣ－ＤＣコンバータの動作状態、電子制御ユニット１３ａ～１３ｄのそれぞれで発生しているエラー、電子制御ユニット１３ａ～１３ｄに接続されているセンサやアクセサリ等の機器の有無や動作状態、シフトレンジ、車速、ＧＰＳ座標等が挙げられる。

【0037】

制御部３９は、前提条件情報に含まれる全ての前提条件が満たされると判定した場合、更新対象の電子制御ユニットのインストール及びアクティベートを実行する。尚、更新対象の電子制御ユニットは、配信パッケージに含まれる情報（更新データに関連付けられた電子制御ユニットの識別情報等）に基づいて特定することができる。

【0038】

ここで、ソフトウェア更新処理は、サーバ１から車両に更新データを送信するダウンロードと、ダウンロードした更新データを更新対象の電子制御ユニットに転送し、更新対象の電子制御ユニットの記憶領域に更新データを書き込むインストールと、更新対象の電子制御ユニットにおいてインストールした更新プログラムを有効化するアクティベートの３つのフェーズを含む。

【0039】

ダウンロードは、サーバ１から送信された、電子制御ユニットのソフトウェアを更新するための更新データを受信して記憶する処理である。ダウンロードのフェーズでは、更新データの受信だけでなく、ダウンロードの実行可否判断、更新データの検証等、ダウンロードに関する一連の処理の制御を含む。インストールは、ダウンロードした更新データに基づいて、更新対象の電子制御ユニットに車載機器の記憶部に更新版のプログラム（更新ソフトウェア）を書き込む処理である。インストールのフェーズでは、インストール実行だけでなく、インストールの実行可否判断、更新データの転送および更新版のプログラムの検証等、インストールに関する一連の処理の制御を含む。アクティベートは、インストールした更新版のプログラムを有効化（アクティベート）する処理である。アクティベートする制御は、アクティベート実行だけでなく、アクティベートの実行可否判断、実行結果の検証等、アクティベートに関する一連の制御を含む。

【0040】

サーバ１からソフトウェア更新装置１１に送信される更新データは、電子制御ユニットの更新ソフトウェア、更新ソフトウェアを圧縮した圧縮データ、更新ソフトウェアまたは圧縮データを分割した分割データのいずれを含んでいても良い。また、更新データは、更新対象の電子制御ユニットを識別する識別子（ＥＣＵ ＩＤ）と、更新前のソフトウェアを識別する識別子（ＥＣＵ ソフトウェア ＩＤ）を含んでいても良い。更新データは、上述した配信パッケージとしてダウンロードされるが、配信パッケージには、単一または複数の電子制御ユニットの更新データが含まれる。

【0041】

更新データが更新ソフトウェアそのものを含む場合は、インストールのフェーズにおいて、ソフトウェア更新装置が更新データ（更新ソフトウェア）を更新対象の電子制御ユニットに転送する。また、更新データが更新ソフトウェアの圧縮データ、差分データあるいは分割データを含む場合、ソフトウェア更新装置１１が更新対象の電子制御ユニットに更新データを転送し、更新対象の電子制御ユニットが更新データから更新ソフトウェアを生成しても良いし、ソフトウェア更新装置１１が更新データから更新ソフトウェアを生成してから、更新ソフトウェアを更新対象の電子制御ユニットに転送しても良い。ここで、更新ソフトウェアの生成は、圧縮データの解凍、差分データまたは分割データの組み付けにより行うことができる。

【0042】

更新ソフトウェアのインストールは、ソフトウェア更新装置１１からのインストール要求に基づき、更新対象の電子制御ユニットが行うことができる。あるいは、更新データを受信した更新対象の電子制御ユニットが、ソフトウェア更新装置１１からの明示の指示を受けることなく、自律的にインストールを行っても良い。

【0043】

更新ソフトウェアのアクティベートは、ソフトウェア更新装置１１からのアクティベート要求に基づき、更新対象の電子制御ユニットが行うことができる。あるいは、更新データを受信した更新対象の電子制御ユニットが、ソフトウェア更新装置１１からの明示の指示を受けることなく、自律的にアクティベートを行っても良い。

【0044】

尚、ソフトウェアの更新処理は、複数の電子制御ユニットのそれぞれに対して、連続的あるいは並列的に行うことができる。

【0045】

制御部３９は、前提条件情報に含まれる全ての前提条件が満たされると判定すると、制御部３９は、受信した１以上の更新データを更新対象の電子制御ユニットに転送し、更新対象の電子制御ユニットが更新データのインストールを行う。インストールが完了すると、制御部３９は、更新対象の電子制御ユニットに対して、更新後のソフトウェアのアクティベートを要求し、更新対象の電子制御ユニットがアクティベートを行う。尚、電子制御ユニットの記憶装置に設けられたソフトウェアの格納領域が１つだけの場合は、インストールとアクティベートとが一続きに行われる。制御部３９が以上の制御処理を行うことにより、更新対象の電子制御ユニットのソフトウェア更新が完了する。

【0046】

尚、本明細書における「ソフトウェア更新処理」は、ダウンロード・インストール・アクティベートの全てを連続して行う処理だけでなく、ダウンロード・インストール・アクティベートの一部のみを行う処理も含む。

【0047】

以下、サーバ１及びソフトウェア更新装置１１が実行する制御処理を説明する。

【0048】

図８は、実施形態に係る更新管理サーバが実行する制御処理の一例を示すフローチャートである。図８に示す制御処理は、サーバ１において、例えば、所定の時間間隔で繰り返し実行される。

【0049】

ステップＳ１において、通信部２８は、ソフトウェア更新装置１１から更新データの有無の確認要求を受け付けたか否かを判定する。ステップＳ１の判定がＹＥＳの場合、処理はステップＳ２に進み、それ以外の場合、処理はステップＳ３に進む。

【0050】

ステップＳ２において、通信部２８は、確認要求を送信したソフトウェア更新装置１１が搭載された車両の更新データがあるか否かを判定し、更新データの有無を示す情報をソフトウェア更新装置１１に送信する。更新データの有無は、記憶装置２３またはサーバ１に接続される他のサーバに格納される管理情報に基づいて判定することができる。その後、処理はステップＳ３に進む。

【0051】

ステップＳ３において、通信部２８は、配信パッケージのダウンロード要求をソフトウェア更新装置１１から受信したか否かを判定する。ステップＳ３の判定がＹＥＳの場合、処理はステップＳ４に進み、それ以外の場合、処理はステップＳ５に進む。

【0052】

ステップＳ４において、通信部２８は、ダウンロード要求を送信した車両の電子制御ユニットのソフトウェアを更新するための更新データと、当該車両に対応する前提条件情報を含む配信パッケージ生成し、生成した配信パッケージをソフトウェア更新装置１１に送信する。その後、処理はステップＳ５に進む。

【0053】

ステップＳ５において、通信部２８は、ソフトウェア更新装置１１からエラー情報を受信したか否かを判定する。ステップＳ５の判定がＹＥＳの場合、処理はステップＳ６に進み、それ以外の場合、処理はステップＳ７に進む。

【0054】

ステップＳ６において、通信部２８は、受信したエラー情報を第２記憶部２７に記憶させる。その後、処理はステップＳ７に進む。

【0055】

ステップＳ７において、制御部２９は、第２記憶部２７に記憶されているエラー情報に基づいて、第１記憶部２６に記憶される前提条件情報を設定（更新）する。尚、図８の例では、エラー情報に基づく前提条件情報の設定を所定のサイクルで定期的に実行しているが、センタのオペレータや販売店の整備士等から指示された時に、エラー情報に基づいて前提条件情報の設定処理を行っても良い。その後、処理はステップＳ１に進む。

【0056】

図９は、実施形態に係るソフトウェア更新装置が実行する制御処理の一例を示すフローチャートである。図９に示す制御処理は、例えば、車両の電源またはイグニッションがＯＮされたことを契機として開始される処理である。

【0057】

ステップＳ１１において、通信部３７は、ソフトウェア更新装置１１に接続された電子制御ユニット１３ａ～１３ｄの更新データがあるか否かの確認を要求する確認要求をサーバ１に送信する。その後、処理はステップＳ１２に進む。

【0058】

ステップＳ１２において、通信部３７は、サーバ１から取得した確認結果を受信する。その後、処理はステップＳ１３に進む。

【0059】

ステップＳ１３において、制御部３９は、サーバ１から取得した確認結果に基づいて、更新データがあるか否かを判定する。ステップＳ１３の処理がＹＥＳの場合、処理はステップＳ１４に進み、それ以外の場合、処理を終了する。

【0060】

ステップＳ１４において、通信部３７は、ダウンロード処理を実行する。より詳細には、通信部３７は、サーバ１に配信パッケージのダウンロード要求を送信し、ダウンロード要求に応答して送信される配信パッケージを受信し、受信した配信パッケージを記憶部３８に格納する。通信部３７は、受信した配信パッケージに含まれる更新データの真正性を検証する。ステップＳ１４において、ダウンロードの実行可否の判定や、サーバ１に対してダウンロードが完了したことの通知を行っても良い。その後、処理はステップＳ１５に進む。

【0061】

ステップＳ１５において、制御部３９は、サーバ１から取得した前提条件情報に含まれる全ての前提条件が満たされるか否かを判定する。ステップＳ１５において、全ての前提条件が満たされると判定された場合、処理はステップＳ１６に進み、それ以外の場合、ステップＳ１８に進む。

【0062】

ステップＳ１６において、制御部３９は、更新対象の電子制御ユニットに対してインストール処理及びアクティベート処理を実行する。ステップＳ１６のインストール処理は、ユーザにインストールの承諾を要求し、承諾の入力を受け付ける処理、ソフトウェア更新装置１１から更新対象の電子制御ユニットへの更新データの転送、更新対象の電子制御ユニットへのインストール要求、更新対象の電子制御ユニットへのインストールの検証要求等を含む。更新対象の電子制御ユニットは、ソフトウェア更新装置１１から受信した更新データを用いて更新版のソフトウェアを格納領域にインストールする。アクティベート処理は、ユーザにアクティベートの承諾を要求し、承諾の入力を受け付ける処理、更新対象の電子制御ユニットへのアクティベート要求等を含む。更新対象の電子制御ユニットは、実行対象のソフトウェアを更新板のソフトウェアに切り替えることにより、更新版のソフトウェアを有効化して起動する。その後、処理はステップＳ１７に進む。

【0063】

ステップＳ１７において、制御部３９は、ソフトウェア更新処理が完了したか否かを判定する。ステップＳ１７の判定がＹＥＳの場合、処理を終了し、それ以外の場合、処理はステップＳ１９に進む。

【0064】

ステップＳ１８において、制御部３９は、ステップＳ１５の判定を最初に行った時点から、所定時間が経過したか否かを判定する。ステップＳ１５の判定時に全ての前提条件が満たされなかった場合でも、満たされなかった前提条件が事後的に満たされる場合が考えられる。例えば、ステップＳ１５の判定時に、「シフトレンジがＰレンジである」という１つの前提条件が満たされなかったが、すぐにユーザがシフトレンジをＰレンジに切り替えた場合を想定する。この場合、ステップＳ１５の判定に基づき、エラーである（すなわち、全ての前提条件が満たされなかったためインストール及びアクティベートが実行できない）として処理せずに、全ての前提条件が満たされた時点でインストール及びアクティベートを実行することが、ユーザの利便性に適うと考えられる。そこで、本実施形態では、ステップＳ１８を設け、ステップＳ１５の最初の判定から所定時間が経過していない間は、ステップＳ１５の前提条件の判定を繰り返し行う。ステップＳ１８の判定がＹＥＳの場合、処理はステップＳ２１に進み、それ以外の場合、処理はステップＳ１５に進む。尚、ステップＳ１８の判定がＮＯの場合、ステップＳ１５に進む前に所定のインターバル時間だけ待機しても良い。

【0065】

ステップＳ１９において、制御部３９は、サーバ１から取得した前提条件情報に含まれる全ての前提条件が満たされるか否かを判定する。ステップＳ１９の判定処理は、ステップＳ１６でインストール及びアクティベートが開始された後、全ての前提条件が継続して満たされていることを確認するための処理である。ステップＳ１９において、全ての前提条件が満たされないと判定された場合、処理はステップＳ２０に進み、それ以外の場合、処理はステップＳ１７に進む。

【0066】

ステップＳ２０において、制御部３９は、インストール及びアクティベートを中断する。その後、処理はステップＳ２１に進む。

【0067】

ステップＳ２１において、通信部３７は、ステップＳ１９において満たされていないと制御部３９が判定した前提条件を含むエラー情報を生成し、生成したエラー情報をサーバ１に送信する。その後、処理を終了する。

【0068】

以上説明したように、本実施形態に係るサーバ１は、ソフトウェア更新時に車両が満たすべき前提条件を保持し、ソフトウェア更新装置１１からの要求に応じて前提条件を送信する。したがって、ソフトウェア更新時に車両が満たすべき前提条件を車両の構成に応じて設定することが可能となる。具体例として、相対的にバッテリ容量が大きい型式Ａの車両と、相対的にバッテリ容量が小さい型式Ｂの車両とがあり、ソフトウェア更新の前提条件として、同じＳＯＣ値（バッテリ残量）を設定した場合を想定する。この場合、型式Ａの車両はバッテリ容量が大きいため、ＳＯＣ値が前提条件として設定されたＳＯＣ値を下回っていても、実際にはバッテリにソフトウェア更新処理を実行するのに十分な電力が残っているケースがあり得る。この場合、型式Ａ及び型式Ｂで一律の前提条件を設定したことによって、型式Ａのソフトウェア更新処理が適時に行われないことが考えられる。本実施形態では、サーバ１において車両毎あるいは型式毎にソフトウェア更新処理の前提条件を設定することができ、ソフトウェア更新装置１１からのダウンロード要求に応じて前提条件情報を送信するので、更新管理サーバ側でソフトウェア更新処理に必要な前提条件を一括して管理でき、前提条件を適宜変更することも可能となる。

【0069】

また、サーバ１は、ソフトウェア更新処理の際に、ソフトウェア更新装置１１が満たさないことを判定した前提条件をエラー情報として車両毎に蓄積できるので、各車両におけるソフトウェア更新時のエラーの発生状況をサーバ１において管理することができ、エラー情報に基づいて、車両毎に個別の対応（個別のソフトウェア更新処理）を行うことも可能となる。

【0070】

また、本実施形態に係るソフトウェア更新装置１１は、ソフトウェア更新処理の際に満たすべき前提条件をサーバ１から取得し、取得した前提条件を満たす場合にソフトウェア更新処理を行う。したがって、ソフトウェア更新の際に車両が満たすべき前提条件を車両の構成に応じて、サーバ１において設定可能となる。

【0071】

また、ソフトウェア更新装置１１は、ソフトウェア更新処理の際に満たされないと判定された前提条件をエラー情報としてサーバに送信することができるので、車両におけるソフトウェア更新処理の際のエラー状況をサーバ１に集約することが可能となる。

【0072】

また、ソフトウェア更新装置１１は、ソフトウェア更新処理の開始後に何れかの前提条件を満たさなくなった場合、ソフトウェア更新を中断するため、ソフトウェア更新処理が不適切な条件下で継続されることを防止できる。

【0073】

また、ソフトウェア更新装置１１は、ソフトウェア更新処理の際に必要な全ての前提条件を満たさないと判定した場合でも、所定時間が経過する前に前提条件を満たようになった場合はソフトウェア更新を開始するので、ソフトウェア更新が可能となる機会を十分に確保できる。

【0074】

実施形態として例示したサーバ１の機能は、プロセッサ（ＣＰＵ）とメモリと記憶装置とを備えるコンピュータが実行する更新管理方法、あるいは、当該コンピュータに実行させる更新管理プログラム、更新管理プログラムを記憶したコンピュータ読み取り可能な非一時的記憶媒体として実現することも可能である。同様に、実施形態として例示したソフトウェア更新装置１１の機能は、プロセッサ（ＣＰＵ）とメモリと記憶装置とを備える、車載されたコンピュータが実行する更新制御方法、あるいは、当該車載されたコンピュータに実行させる更新制御プログラム、更新制御プログラムを記憶したコンピュータ読み取り可能な非一時的記憶媒体として実現することも可能である。

【0075】

上記の実施形態では、車両側において、車載ネットワークに設けられたソフトウェア更新装置１１が、マスタ装置として、全ての電子制御ユニット１３ａ～１３ｂのソフトウェア更新を制御する例を説明したが、ソフトウェア更新装置１１を設ける代わりに、電子制御ユニット１３ａ～１３ｄのいずれか１つが図９Ａ～図１０に示した更新制御機能を有しており、他の電子制御ユニットのソフトウェア更新を制御しても良い。また、ソフトウェア更新装置１１を設ける代わりに、図９Ａ～図１０に示した更新制御機能を車載ネットワーク２に有線で接続可能な外部機器に設け、この外部機器を用いて電子制御ユニット１３ａ～１３ｄのソフトウェア更新処理を行うことも可能である。

【産業上の利用可能性】

【0076】

本開示技術は、電子制御ユニットのソフトウェアを更新するためのネットワークシステムに利用できる。

【符号の説明】

【0077】

１ サーバ
２ 車載ネットワーク
５ ネットワーク
１１ ソフトウェア更新装置
１３ａ～１３ｄ 電子制御ユニット
２６ 第１記憶部
２７ 第２記憶部
２８ 通信部
２９ 制御部
３７ 通信部
３８ 記憶部
３９ 制御部

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図6】

【図7】

【図8】

【図9】