特許 7396229 ソフトウェア更新装置、更新制御方法、更新制御プログラム及びＯＴＡマスタ

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

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

(11)【特許番号】

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

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

(54)【発明の名称】ソフトウェア更新装置、更新制御方法、更新制御プログラム及びＯＴＡマスタ

(51)【国際特許分類】

   G06F 8/65 20180101AFI20231205BHJP

   B60R 16/02 20060101ALI20231205BHJP

   H04L 67/00 20220101ALI20231205BHJP

【ＦＩ】

G06F8/65

B60R16/02 660U

H04L67/00

【請求項の数】 5

(21)【出願番号】P 2020142008

(22)【出願日】2020-08-25

(65)【公開番号】P2022037729

(43)【公開日】2022-03-09

【審査請求日】2022-08-09

(73)【特許権者】

【識別番号】000003207

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

(74)【代理人】

【識別番号】110001276

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

(72)【発明者】

【氏名】高綱 雄介

【審査官】北川 純次

(56)【参考文献】

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

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

【文献】米国特許出願公開第２０１９／０２６８４２０（ＵＳ，Ａ１）

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

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

Ｇ０６Ｆ ８／６５

Ｂ６０Ｒ １６／０２

Ｈ０４Ｌ ６７／００

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

【請求項1】

車両に搭載された電子制御ユニットのソフトウェア更新を制御するソフトウェア更新装置であって、
サーバから前記電子制御ユニットの更新データをダウンロードするための互いに異なる第１ソフトウェア及び第２ソフトウェアを記憶する記憶部と、
前記第１ソフトウェア及び前記第２ソフトウェアのいずれかを実行することにより前記更新データを前記サーバからダウンロードする制御部と、
前記サーバにおいて前記更新データの配信に利用しているソフトウェアを特定するソフトウェア情報を前記サーバから受信する通信部とを備え、
前記制御部は、前記第１ソフトウェア及び前記第２ソフトウェアのうち、受信した前記ソフトウェア情報により特定される前記サーバのソフトウェアに対応するソフトウェアを実行する、ソフトウェア更新装置。

【請求項2】

前記サーバから前記更新データをダウンロード可能なソフトウェアが前記記憶部に記憶されていないと前記制御部が判定した場合、前記通信部は、前記ソフトウェア情報により特定される前記サーバのソフトウェアに対応するソフトウェアを前記サーバから受信する、請求項１に記載のソフトウェア更新装置。

【請求項3】

プロセッサと、メモリと、記憶装置とを備えるコンピュータが、車両に搭載された電子制御ユニットのソフトウェア更新を制御するために実行する更新制御方法であって、
サーバから前記電子制御ユニットの更新データをダウンロードするための互いに異なる第１ソフトウェア及び第２ソフトウェアを記憶するステップと、
前記サーバにおいて前記更新データの配信に利用しているソフトウェアを特定するソフトウェア情報を前記サーバから受信するステップと、
前記第１ソフトウェア及び前記第２ソフトウェアのうち、受信した前記ソフトウェア情報により特定される前記サーバのソフトウェアに対応するソフトウェアを実行することにより前記更新データを前記サーバからダウンロードするステップとを備える、更新制御方法。

【請求項4】

プロセッサと、メモリと、記憶装置とを備えるコンピュータが、車両に搭載された電子制御ユニットのソフトウェア更新を制御するために実行する更新制御プログラムであって、
サーバから前記電子制御ユニットの更新データをダウンロードするための互いに異なる第１ソフトウェア及び第２ソフトウェアを記憶するステップと、
前記サーバにおいて前記更新データの配信に利用しているソフトウェアを特定するソフトウェア情報を前記サーバから受信するステップと、
前記第１ソフトウェア及び前記第２ソフトウェアのうち、受信した前記ソフトウェア情報により特定される前記サーバのソフトウェアに対応するソフトウェアを実行することにより前記更新データを前記サーバからダウンロードするステップとを備える、更新制御プログラム。

【請求項5】

車両に搭載された電子制御ユニットのソフトウェア更新を制御するＯＴＡマスタであって、
センタから前記電子制御ユニットの更新データをダウンロードするための互いに異なる第１ソフトウェア及び第２ソフトウェアを記憶するストレージと、
前記第１ソフトウェア及び前記第２ソフトウェアのいずれかを実行することにより前記更新データを前記センタからダウンロードする制御部と、
前記センタにおいて前記更新データの配信に利用しているソフトウェアを特定するソフトウェア情報を前記センタから受信する通信部とを備え、
前記制御部は、前記第１ソフトウェア及び前記第２ソフトウェアのうち、受信した前記ソフトウェア情報により特定される前記センタのソフトウェアに対応するソフトウェアを実行する、ＯＴＡマスタ。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、電子制御ユニットのソフトウェアの更新を制御するためのソフトウェア更新装置、更新制御方法、更新制御プログラム及びＯＴＡマスタに関する。

【背景技術】

【0002】

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

【0003】

ＥＣＵのソフトウェアを更新する技術として、車載ネットワークに接続された車載通信機器とインターネット等の通信ネットワークとを無線で接続し、無線通信を介してサーバからソフトウェアをダウンロードし、ダウンロードしたソフトウェアをインストールすることによりＥＣＵのプログラム更新や追加を行うＯＴＡ（Ｏｖｅｒ Ｔｈｅ Ａｉｒ）技術が知られている（例えば、特許文献１参照）。

【0004】

センタに設けられるサーバには、ＯＴＡ用ソフトウェアをインストールすることによりのソフトウェア配信機能が実装される。一方、車両に搭載されるソフトウェア更新装置は、サーバが実行するＯＴＡ用ソフトウェアに対応したクライアントソフトウェアを用いて、サーバに対する更新データの確認要求や更新データのダウンロードを行う。

【先行技術文献】

【特許文献】

【0005】

【文献】特開２００４－３２６６８９号公報

【発明の概要】

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

【0006】

車両の使用期間中にサーバで利用されるＯＴＡ用ソフトウェアが変更される可能性がある。サーバで利用されるＯＴＡ用ソフトウェアが変更され、サーバと車両とでＯＴＡ用ソフトウェアのベンダが異なった場合、ベンダ間にソフトウェアの互換性がなければ、ＯＴＡによるソフトウェア更新ができなくなる。

【0007】

それ故に、本開示は、サーバにおけるＯＴＡ用ソフトウェアが変更されても、ＯＴＡによるソフトウェア更新が可能なソフトウェア更新装置、更新制御方法、更新制御プログラム及びＯＴＡマスタを提供することを目的とする。

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

【0008】

本開示に係るソフトウェア更新装置は、サーバから電子制御ユニットの更新データをダウンロードするための互いに異なる第１ソフトウェア及び第２ソフトウェアを記憶する記憶部と、第１ソフトウェア及び第２ソフトウェアのいずれかを実行することにより更新データをサーバからダウンロードする制御部と、サーバにおいて更新データの配信に利用しているソフトウェアを特定するソフトウェア情報をサーバから受信する通信部とを備え、制御部は、第１ソフトウェア及び第２ソフトウェアのうち、受信したソフトウェア情報により特定されるサーバのソフトウェアに対応するソフトウェアを実行する。

【0009】

本開示に係る更新制御方法は、プロセッサと、メモリと、記憶装置とを備えるコンピュータが、車両に搭載された電子制御ユニットのソフトウェア更新を制御するために実行する方法であって、サーバから電子制御ユニットの更新データをダウンロードするための互いに異なる第１ソフトウェア及び第２ソフトウェアを記憶するステップと、サーバにおいて更新データの配信に利用しているソフトウェアを特定するソフトウェア情報をサーバから受信するステップと、第１ソフトウェア及び第２ソフトウェアのうち、受信したソフトウェア情報により特定されるサーバのソフトウェアに対応するソフトウェアを実行することにより更新データをサーバからダウンロードするステップとを備える。

【0010】

本開示に係る更新制御プログラムは、プロセッサと、メモリと、記憶装置とを備えるコンピュータが、車両に搭載された電子制御ユニットのソフトウェア更新を制御するために実行するプログラムであって、サーバから電子制御ユニットの更新データをダウンロードするための互いに異なる第１ソフトウェア及び第２ソフトウェアを記憶するステップと、サーバにおいて更新データの配信に利用しているソフトウェアを特定するソフトウェア情報をサーバから受信するステップと、第１ソフトウェア及び第２ソフトウェアのうち、受信したソフトウェア情報により特定されるサーバのソフトウェアに対応するソフトウェアを実行することにより更新データをサーバからダウンロードするステップとを備える。

【発明の効果】

【0011】

本開示によれば、サーバにおけるＯＴＡ用ソフトウェアが変更されても、ＯＴＡによるソフトウェア更新が可能なソフトウェア更新装置、更新制御方法、更新制御プログラム及びＯＴＡマスタを提供できる。

【図面の簡単な説明】

【0012】

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

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

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

【図4】第１の実施形態に係るサーバの機能ブロック図

【図5】第１の実施形態に係るソフトウェア更新装置の機能ブロック図

【図6A】第１の実施形態におけるソフトウェア切替の概略を示す模式図

【図6B】第１の実施形態におけるソフトウェア切替の概略を示す模式図

【図6C】第１の実施形態におけるソフトウェア切替の概略を示す模式図

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

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

【図9】第２の実施形態に係るサーバの機能ブロック図

【図10】第２の実施形態に係るソフトウェア更新装置の機能ブロック図

【図11A】第２の実施形態におけるソフトウェア選択の概略を示す模式図

【図11B】第２の実施形態におけるソフトウェア選択の概略を示す模式図

【図12A】第２の実施形態におけるソフトウェア追加の概略を示す模式図

【図12B】第２の実施形態におけるソフトウェア追加の概略を示す模式図

【図12C】第２の実施形態におけるソフトウェア追加の概略を示す模式図

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

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

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

【0013】

（第１及び第２の実施形態に共通の構成）
図１は、実施形態に係るネットワークシステムの全体構成を示すブロック図であり、図２は、図１に示したサーバの概略構成を示すブロック図であり、図３は、図１に示したソフトウェア更新装置の概略構成を示すブロック図である。

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

電子制御ユニット１３ａ～１３ｄは、ＣＰＵと、ＲＡＭと、不揮発性メモリ（ストレージ）と、通信装置とを備える。ＣＰＵは、不揮発性メモリから読み出したソフトウェア（プログラム）を、ＲＡＭを作業領域として用いて実行することにより、各電子制御ユニットの機能を実現する。ここで、電子制御ユニットには、ソフトウェアを格納するための１つのデータ格納領域（バンク）を有するものと、ソフトウェアを格納するための２つのデータ格納領域（バンク）を有するものとがある。電子制御ユニットのデータ格納領域には、電子制御ユニットの機能を実現するためのソフトウェアの他に、バージョン情報やパラメータデータ、起動用のブートプログラム、ソフトウェア更新用のプログラム等が格納される場合がある。１つのデータ格納領域を持つ電子制御ユニットにおいては、データ格納領域に更新データをインストールすることにより、電子制御ユニットのソフトウェアに影響が生じる。一方、２つのデータ格納領域を持つ電子ユニットにおいては、２つのデータ格納領域のうち、いずれか一方を読み出し対象の格納領域（運用面）とし、読み出し対象の格納領域に格納されるソフトウェアを実行する。読み出し対象でない他方の格納領域（非運用面）には、読み出し対象の格納領域（運用面）のプログラムの実行中に、バックグラウンドで更新データを書き込み可能である。ソフトウェア更新処理におけるアクティベート時には、ＣＰＵ４１によるプログラムの読み出し対象の格納領域を切り替えることにより、更新版のソフトウェアを有効化することができる。

【0019】

尚、本開示において、２つのデータ格納領域を有する電子制御ユニットには、不揮発性メモリが有する１面のデータ格納領域を擬似的に２面に区画し、一方の面のプログラムを実行中に他方の面にプログラムを書き込み可能にした「１面サスペンドメモリ」と呼ばれる構成のメモリを備えた電子制御ユニットと、１面のデータ格納領域を有する不揮発性メモリに加え、１面のデータ格納領域を有する拡張不揮発性メモリを備え、これら２つの不揮発性メモリを運用面及び非運用面として使用可能な電子制御ユニットも含まれる。

【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】

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

【0078】

ステップＳ６において、第２通信部２９は、ソフトウェア情報の送信要求を送信した車両に対して、ソフトウェア情報を送信する。その後、処理はステップＳ７に進む。

【0079】

ステップＳ７において、第２通信部２９は、ＯＴＡ用ソフトウェア（クライアント側）の送信要求を受信したか否かを判定する。ステップＳ７の判定がＹＥＳの場合処理はステップＳ８に進み、それ以外はステップＳ５に進む。

【0080】

ステップＳ８において、第２通信部２９は、ＯＴＡ用ソフトウェアの送信要求を送信した車両に対して、ＯＴＡ用ソフトウェア（クライアント側）を送信する。その後処理はステップＳ５に進む。

【0081】

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

【0082】

ステップＳ２０において、通信部３９は、ソフトウェア情報の送信要求をサーバ１に送信する。その後、処理はステップＳ２１に進む。

【0083】

ステップＳ２１において、通信部３９は、ソフトウェア情報をサーバ１から受信する。その後、処理はステップＳ２２に進む。

【0084】

ステップＳ２２において、制御部３８は、受信したソフトウェア情報により特定されるサーバ側ソフトウェアに対応するソフトウェアが記憶部３７に格納されているか否かを判定する。ステップＳ２２の判定がＹＥＳの場合、処理はステップＳ２３に進み、それ以外の場合、処理はステップＳ２４に進む。

【0085】

ステップ２３において、制御部３８は、ソフトウェア情報により特定されるサーバ側ソフトウェアに対応するソフトウェアを実行し、電子制御ユニットのソフトウェアの更新データがあるか否かの確認をサーバ１に要求する。その後、処理はステップＳ１５に進む。

【0086】

ステップＳ２４において、通信部３９は、ソフトウェア情報により特定されるサーバ側ソフトウェアに対応するクライアント側ソフトウェアの送信要求をサーバ１に送信する。その後、処理はステップＳ２５に進む。

【0087】

ステップＳ２５において、通信部３９は、ソフトウェア情報により特定されるサーバ側ソフトウェアに対応するクライアント側ソフトウェアをサーバ１から受信し、受信したソフトウェアを記憶部３７に格納する。その後、処理はステップＳ２３に進む。尚、ステップＳ２５において、通信部３９がサーバ１からＯＴＡ用ソフトウェアを受信した場合、ステップ２３において、制御部３８は、ステップＳ２５で受信したソフトウェアを実行する。

【0088】

尚、図１４に示すステップＳ１５～Ｓ１９の処理は、図８で説明したものと同じであるため、繰り返しの説明を省略する。

【0089】

また、ステップＳ２０及びＳ２１におけるソフトウェア情報の送信要求及び受信、ステップＳ２４及びＳ２５におけるＯＴＡ用ソフトウェアの送信要求及び受信は、ＯＴＡ用ソフトウェアを介さずに実行可能な処理である。

【0090】

本実施形態に係るソフトウェア更新装置１１は、ＯＴＡ用ソフトウェアとして、互いに異なる第１ソフトウェア及び第２ソフトウェアを記憶部３７に有し、サーバ１から受信したソフトウェア情報に基づいて、サーバ側ソフトウェアに対応するソフトウェアを選択して実行する。サーバ１で稼働するＯＴＡ用ソフトウェアが変更された場合でも、サーバ側に対応したソフトウェアを実行し更新データのダウンロードが可能となる。

【0091】

また、サーバ側ソフトウェアに対応するソフトウェアがない場合、サーバ１からソフトウェアをダウンロードできるため、ダウンロードしたソフトウェアを用いて更新データのダウンロードを行うことが可能となる。

【0092】

上記の第２の実施形態においては、ソフトウェア情報は、サーバ１で稼働しているＯＴＡ用ソフトウェアを特定する情報とした例を説明したが、ソフトウェア情報は、ソフトウェア更新装置１１において実行すべきＯＴＡ用ソフトウェアを指定する情報であっても良い。

【0093】

上記の第２の実施形態において、ソフトウェア情報の送信要求及び受信と、ＯＴＡ用ソフトウェアの送信要求及び受信を、記憶部３７に記憶されるＯＴＡ用ソフトウェアの機能を介さずに行う例を説明したが、ソフトウェア情報の送信要求及び受信と、ＯＴＡ用ソフトウェアの送信要求及び受信に関する手順を共通化して、全てのＯＴＡ用ソフトウェア（サーバ側及びクライアント側）に実装しても良い。

【0094】

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

【0095】

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

【産業上の利用可能性】

【0096】

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

【符号の説明】

【0097】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図6C】

【図7】

【図8】

【図9】

【図10】

【図11A】

【図11B】

【図12A】

【図12B】

【図12C】

【図13】

【図14】