ホーム > 特許ランキング > 日立Ａｓｔｅｍｏ株式会社
知財求人 - 知財ポータルサイト「IP Force」
特開2022-144814ソフトウェア更新装置、ソフトウェア更新システム及びソフトウェア更新方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022144814
(43)【公開日】2022-10-03
(54)【発明の名称】ソフトウェア更新装置、ソフトウェア更新システム及びソフトウェア更新方法
(51)【国際特許分類】
G06F 13/00 20060101AFI20220926BHJP
G06F 8/65 20180101ALI20220926BHJP
B60R 16/02 20060101ALI20220926BHJP
【ＦＩ】
G06F13/00 530B
G06F8/65
B60R16/02 660U
【審査請求】未請求
【請求項の数】9
【出願形態】ＯＬ
(21)【出願番号】P 2021045987
(22)【出願日】2021-03-19
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
２．ＵＮＩＸ
(71)【出願人】
【識別番号】509186579
【氏名又は名称】日立Ａｓｔｅｍｏ株式会社
(74)【代理人】
【識別番号】110002365
【氏名又は名称】特許業務法人サンネクスト国際特許事務所
(72)【発明者】
【氏名】寺岡 秀敏
(72)【発明者】
【氏名】矢野 正
【テーマコード（参考）】
5B084
5B376
【Ｆターム（参考）】
5B084AA03
5B084AA12
5B084AB16
5B084AB31
5B084BA09
5B084BB17
5B084DB02
5B084DB08
5B084DC02
5B376CA04
5B376CA05
5B376CA43
5B376CA45
5B376CA46
(57)【要約】 （修正有）
【課題】複数のプラットフォームで構成される車両システムのソフトウェアを柔軟に更新するソフトウェア更新システム、更新装置及び更新方法を提供する。
【解決手段】ソフトウェア更新システムにおいて、ソフトウェア更新装置１０は、車両の第１のソフトウェアユニットのソフトウェア更新を行う第１更新制御部１４０と第２のソフトウェアユニットのソフトウェア更新を行う第２更新制御部１５０と、を備える。第１更新制御部は、第１プラットフォーム向けの制御命令を送信する第１シーケンス制御部１４１を有する。第２更新制御部は、第２のソフトウェアユニットを第１プラットフォーム上のソフトウェアユニットとして模擬し、第１プラットフォーム上に模擬された第２のソフトウェアユニットに対する制御命令の受信に基づいて、第２のソフトウェアユニットのソフトウェア更新を制御する疑似更新実行部１５１を有する。
【選択図】図６
【解決手段】ソフトウェア更新システムにおいて、ソフトウェア更新装置１０は、車両の第１のソフトウェアユニットのソフトウェア更新を行う第１更新制御部１４０と第２のソフトウェアユニットのソフトウェア更新を行う第２更新制御部１５０と、を備える。第１更新制御部は、第１プラットフォーム向けの制御命令を送信する第１シーケンス制御部１４１を有する。第２更新制御部は、第２のソフトウェアユニットを第１プラットフォーム上のソフトウェアユニットとして模擬し、第１プラットフォーム上に模擬された第２のソフトウェアユニットに対する制御命令の受信に基づいて、第２のソフトウェアユニットのソフトウェア更新を制御する疑似更新実行部１５１を有する。
【選択図】図６
【特許請求の範囲】
【請求項1】
第１プラットフォームで構成される第１のソフトウェアユニットと、前記第１プラットフォームとは異なる第２プラットフォームで構成される第２のソフトウェアユニットと、を含む複数のソフトウェアユニットに接続されるソフトウェア更新装置であって、
前記第１のソフトウェアユニットのソフトウェア更新を行う第１更新制御部と、
前記第２のソフトウェアユニットのソフトウェア更新を行う第２更新制御部と、
を備え、
前記第１更新制御部は、前記第１プラットフォーム向けの制御命令を送信する第１シーケンス制御部を有し、
前記第２更新制御部は、前記第２のソフトウェアユニットを前記第１プラットフォーム上のソフトウェアユニットとして模擬し、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対する前記制御命令の受信に基づいて、前記第２のソフトウェアユニットのソフトウェア更新を制御する疑似更新実行部を有する
ことを特徴とするソフトウェア更新装置。
前記第１のソフトウェアユニットのソフトウェア更新を行う第１更新制御部と、
前記第２のソフトウェアユニットのソフトウェア更新を行う第２更新制御部と、
を備え、
前記第１更新制御部は、前記第１プラットフォーム向けの制御命令を送信する第１シーケンス制御部を有し、
前記第２更新制御部は、前記第２のソフトウェアユニットを前記第１プラットフォーム上のソフトウェアユニットとして模擬し、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対する前記制御命令の受信に基づいて、前記第２のソフトウェアユニットのソフトウェア更新を制御する疑似更新実行部を有する
ことを特徴とするソフトウェア更新装置。
【請求項2】
前記第２更新制御部は、
前記制御命令の変換時に参照される変換情報を管理する変換情報管理部をさらに有し、
前記疑似更新実行部は、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対する前記第１プラットフォーム向けの制御命令を前記第１シーケンス制御部から受信すると、前記変換情報に基づいて、当該制御命令を前記第２プラットフォーム向けの制御命令に変換し、変換後の制御命令を前記第２のソフトウェアユニットに送信する
ことを特徴とする請求項１に記載のソフトウェア更新装置。
前記制御命令の変換時に参照される変換情報を管理する変換情報管理部をさらに有し、
前記疑似更新実行部は、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対する前記第１プラットフォーム向けの制御命令を前記第１シーケンス制御部から受信すると、前記変換情報に基づいて、当該制御命令を前記第２プラットフォーム向けの制御命令に変換し、変換後の制御命令を前記第２のソフトウェアユニットに送信する
ことを特徴とする請求項１に記載のソフトウェア更新装置。
【請求項3】
前記変換情報管理部は、前記変換情報の１つとして、
前記第２プラットフォームで構成される前記第２のソフトウェアユニットのそれぞれについて、前記第１プラットフォーム上に模擬したときの識別情報と前記第２プラットフォーム上における識別情報との対応関係を示す第１の変換情報を保持する
ことを特徴とする請求項２に記載のソフトウェア更新装置。
前記第２プラットフォームで構成される前記第２のソフトウェアユニットのそれぞれについて、前記第１プラットフォーム上に模擬したときの識別情報と前記第２プラットフォーム上における識別情報との対応関係を示す第１の変換情報を保持する
ことを特徴とする請求項２に記載のソフトウェア更新装置。
【請求項4】
前記変換情報管理部は、前記変換情報の１つとして、
前記第１プラットフォーム向けの制御命令と、前記第２プラットフォーム向けの制御命令との対応関係を示す第２の変換情報を保持する
ことを特徴とする請求項２に記載のソフトウェア更新装置。
前記第１プラットフォーム向けの制御命令と、前記第２プラットフォーム向けの制御命令との対応関係を示す第２の変換情報を保持する
ことを特徴とする請求項２に記載のソフトウェア更新装置。
【請求項5】
前記第２の変換情報には、ソフトウェアの書き換えの可否に関して前記第２プラットフォームにおいて前記第２のソフトウェアユニットが依存する依存条件が設定され、
前記疑似更新実行部は、前記第１シーケンス制御部からの前記第１プラットフォーム向けの制御命令によって前記第２のソフトウェアユニットのソフトウェア更新が要求されたとき、前記第２の変換情報を参照し、前記依存条件を満たす場合にはソフトウェアを更新し、前記依存条件を満たさない場合にはソフトウェアを更新しない
ことを特徴とする請求項４に記載のソフトウェア更新装置。
前記疑似更新実行部は、前記第１シーケンス制御部からの前記第１プラットフォーム向けの制御命令によって前記第２のソフトウェアユニットのソフトウェア更新が要求されたとき、前記第２の変換情報を参照し、前記依存条件を満たす場合にはソフトウェアを更新し、前記依存条件を満たさない場合にはソフトウェアを更新しない
ことを特徴とする請求項４に記載のソフトウェア更新装置。
【請求項6】
ネットワークを介して接続された配信サーバから前記第２のソフトウェアユニットの更新プログラムが配信された場合、
前記第１シーケンス制御部は、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対して前記更新プログラムのデータ転送を要求する制御命令を送信し、
当該制御命令を受信した前記疑似更新実行部は、前記変換情報に基づいて、所定条件が成立するまでの間、前記更新プログラムを前記第２のソフトウェアユニットに転送することなく一時的に蓄積する
ことを特徴とする請求項２に記載のソフトウェア更新装置。
前記第１シーケンス制御部は、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対して前記更新プログラムのデータ転送を要求する制御命令を送信し、
当該制御命令を受信した前記疑似更新実行部は、前記変換情報に基づいて、所定条件が成立するまでの間、前記更新プログラムを前記第２のソフトウェアユニットに転送することなく一時的に蓄積する
ことを特徴とする請求項２に記載のソフトウェア更新装置。
【請求項7】
前記配信サーバから配信された前記第２のソフトウェアユニットの前記更新プログラムについてアクティベートの許可が得られた場合、
前記第１シーケンス制御部は、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対して前記更新プログラムの有効化を要求する制御命令を送信し、
当該制御命令を受信した前記疑似更新実行部は、前記第２のソフトウェアユニットへの前記更新プログラムの転送が終了した後に、前記第２のソフトウェアユニットに対して前記更新プログラムの有効化を指示する制御命令を送信する
ことを特徴とする請求項６に記載のソフトウェア更新装置。
前記第１シーケンス制御部は、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対して前記更新プログラムの有効化を要求する制御命令を送信し、
当該制御命令を受信した前記疑似更新実行部は、前記第２のソフトウェアユニットへの前記更新プログラムの転送が終了した後に、前記第２のソフトウェアユニットに対して前記更新プログラムの有効化を指示する制御命令を送信する
ことを特徴とする請求項６に記載のソフトウェア更新装置。
【請求項8】
更新プログラムを配信する配信サーバと車両システムとがネットワークで接続されたソフトウェア更新システムであって、
前記車両システムは、
第１プラットフォームで構成される第１のソフトウェアユニット、及び前記第１プラットフォームとは異なる第２プラットフォームで構成される第２のソフトウェアユニットを含む複数のソフトウェアユニットと、
前記第１のソフトウェアユニット及び前記第２のソフトウェアユニットに接続されるソフトウェア更新装置と、
を備え、
前記ソフトウェア更新装置は、
前記第１のソフトウェアユニットのソフトウェア更新を行う第１更新制御部と、
前記第２のソフトウェアユニットのソフトウェア更新を行う第２更新制御部と、
を有し、
前記第１更新制御部は、前記第１プラットフォーム向けの制御命令を送信する第１シーケンス制御部を有し、
前記第２更新制御部は、前記第２のソフトウェアユニットを前記第１プラットフォーム上のソフトウェアユニットとして模擬し、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対する前記制御命令の受信に基づいて、前記第２のソフトウェアユニットのソフトウェア更新を制御する疑似更新実行部を有する
ことを特徴とするソフトウェア更新システム。
前記車両システムは、
第１プラットフォームで構成される第１のソフトウェアユニット、及び前記第１プラットフォームとは異なる第２プラットフォームで構成される第２のソフトウェアユニットを含む複数のソフトウェアユニットと、
前記第１のソフトウェアユニット及び前記第２のソフトウェアユニットに接続されるソフトウェア更新装置と、
を備え、
前記ソフトウェア更新装置は、
前記第１のソフトウェアユニットのソフトウェア更新を行う第１更新制御部と、
前記第２のソフトウェアユニットのソフトウェア更新を行う第２更新制御部と、
を有し、
前記第１更新制御部は、前記第１プラットフォーム向けの制御命令を送信する第１シーケンス制御部を有し、
前記第２更新制御部は、前記第２のソフトウェアユニットを前記第１プラットフォーム上のソフトウェアユニットとして模擬し、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対する前記制御命令の受信に基づいて、前記第２のソフトウェアユニットのソフトウェア更新を制御する疑似更新実行部を有する
ことを特徴とするソフトウェア更新システム。
【請求項9】
第１プラットフォームで構成される第１のソフトウェアユニットと、前記第１プラットフォームとは異なる第２プラットフォームで構成される第２のソフトウェアユニットと、を含む複数のソフトウェアユニットに接続されるソフトウェア更新装置によるソフトウェア更新方法であって、
前記ソフトウェア更新装置は、
前記第１プラットフォーム向けの制御命令を送信し、前記第１のソフトウェアユニットのソフトウェア更新を行う第１更新制御部と、
前記第２のソフトウェアユニットを前記第１プラットフォーム上のソフトウェアユニットとして模擬し、前記第２のソフトウェアユニットのソフトウェア更新を行う第２更新制御部と、
を有し、
前記第１更新制御部が、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対する前記制御命令を送信する第１ステップと、
前記制御命令を受信した前記第２更新制御部が、当該制御命令を前記第２プラットフォーム向けの制御命令に変換し、変換後の制御命令によって前記第２のソフトウェアユニットのソフトウェア更新を制御する第２ステップと、
を備えることを特徴とするソフトウェア更新方法。
前記ソフトウェア更新装置は、
前記第１プラットフォーム向けの制御命令を送信し、前記第１のソフトウェアユニットのソフトウェア更新を行う第１更新制御部と、
前記第２のソフトウェアユニットを前記第１プラットフォーム上のソフトウェアユニットとして模擬し、前記第２のソフトウェアユニットのソフトウェア更新を行う第２更新制御部と、
を有し、
前記第１更新制御部が、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対する前記制御命令を送信する第１ステップと、
前記制御命令を受信した前記第２更新制御部が、当該制御命令を前記第２プラットフォーム向けの制御命令に変換し、変換後の制御命令によって前記第２のソフトウェアユニットのソフトウェア更新を制御する第２ステップと、
を備えることを特徴とするソフトウェア更新方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ソフトウェア更新装置、ソフトウェア更新システム及びソフトウェア更新方法に関し、配信サーバから配信される更新プログラムによってソフトウェアユニット（ＥＣＵ）のソフトウェア更新を行うソフトウェア更新装置、ソフトウェア更新システム及びソフトウェア更新方法に適用して好適なものである。
【背景技術】
【0002】
近年、自動車のＥ（Electric）／Ｅ（Electronic）アーキテクチャが分散型から集中型に変化しており、ハードウェアとソフトウェアとが独立して開発される方向に進んでいる。例えばソフトウェアの開発では、ＡＵＴＯＳＡＲ（AUTomotive Open System Architecture） Ａｄａｐｔｉｖｅ Ｐｌａｔｆｏｒｍによる、自動車のソフトウェア更新技術の標準化（具体的には例えば、ソフトウェア更新を制御するマスタ機能の定義等）が推進されている。また、自動車のソフトウェアユニット（ＥＣＵ：Electronic Control Unit）を構成するアーキテクチャはＡＵＴＯＳＡＲだけではないため、様々なプラットフォーム（ＰＦ）が混在する車両システムへの移行が想定されている。
【0003】
例えば特許文献１には、複数のプラットフォームで構成された車両システムにおいて、１以上の他のソフトウェア更新装置及びサーバとネットワークを介して接続されるソフトウェア更新装置が、更新契機に記述されているすべての条件が満たされたと判断するとソフトウェアの更新を実行するソフトウェア更新システムが開示されている。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２０１８－１０６４６１号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかし、特許文献１に開示されたソフトウェア更新システムは、各プラットフォームで各ソフトウェア更新装置が独立してソフトウェアを更新し、最後に更新トリガによってソフトウェア更新装置間の調停を行うものであるため、１つのソフトウェアユニットで複数プラットフォームに対応することが困難であるという課題があった。また、プラットフォームや更新方法が増えるたびに、ソフトウェア更新を制御する制御部を追加する必要があり、調停が複雑化することが想定されるため、スケーラビリティの点で課題があった。
【0006】
本発明は以上の点を考慮してなされたもので、複数のプラットフォームで構成される車両システムのソフトウェアを柔軟に更新可能なソフトウェア更新装置、ソフトウェア更新システム及びソフトウェア更新方法を提案しようとするものである。
【課題を解決するための手段】
【0007】
かかる課題を解決するため本発明においては、第１プラットフォームで構成される第１のソフトウェアユニットと、前記第１プラットフォームとは異なる第２プラットフォームで構成される第２のソフトウェアユニットと、を含む複数のソフトウェアユニットに接続されるソフトウェア更新装置であって、前記第１のソフトウェアユニットのソフトウェア更新を行う第１更新制御部と、前記第２のソフトウェアユニットのソフトウェア更新を行う第２更新制御部と、を備え、前記第１更新制御部は、前記第１プラットフォーム向けの制御命令を送信する第１シーケンス制御部を有し、前記第２更新制御部は、前記第２のソフトウェアユニットを前記第１プラットフォーム上のソフトウェアユニットとして模擬し、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対する前記制御命令の受信に基づいて、前記第２のソフトウェアユニットのソフトウェア更新を制御する疑似更新実行部を有する、ソフトウェア更新装置が提供される。
【0008】
また、かかる課題を解決するため本発明においては、更新プログラムを配信する配信サーバと車両システムとがネットワークで接続されたソフトウェア更新システムであって、前記車両システムは、第１プラットフォームで構成される第１のソフトウェアユニット、及び前記第１プラットフォームとは異なる第２プラットフォームで構成される第２のソフトウェアユニットと、を含む複数のソフトウェアユニットと、前記第１のソフトウェアユニット及び前記第２のソフトウェアユニットに接続されるソフトウェア更新装置と、を備え、前記ソフトウェア更新装置は、前記第１のソフトウェアユニットのソフトウェア更新を行う第１更新制御部と、前記第２のソフトウェアユニットのソフトウェア更新を行う第２更新制御部と、を有し、前記第１更新制御部は、前記第１プラットフォーム向けの制御命令を送信する第１シーケンス制御部を有し、前記第２更新制御部は、前記第２のソフトウェアユニットを前記第１プラットフォーム上のソフトウェアユニットとして模擬し、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対する前記制御命令の受信に基づいて、前記第２のソフトウェアユニットのソフトウェア更新を制御する疑似更新実行部を有する、ソフトウェア更新システムが提供される。
【0009】
また、かかる課題を解決するため本発明においては、第１プラットフォームで構成される第１のソフトウェアユニットと、前記第１プラットフォームとは異なる第２プラットフォームで構成される第２のソフトウェアユニットと、を含む複数のソフトウェアユニットに接続されるソフトウェア更新装置によるソフトウェア更新方法であって、前記ソフトウェア更新装置は、前記第１プラットフォーム向けの制御命令を送信し、前記第１のソフトウェアユニットのソフトウェア更新を行う第１更新制御部と、前記第２のソフトウェアユニットを前記第１プラットフォーム上のソフトウェアユニットとして模擬し、前記第２のソフトウェアユニットのソフトウェア更新を行う第２更新制御部と、を有し、前記第１更新制御部が、前記第１プラットフォーム上に模擬された前記第２のソフトウェアユニットに対する前記制御命令を送信する第１ステップと、前記制御命令を受信した前記第２更新制御部が、当該制御命令を前記第２プラットフォーム向けの制御命令に変換し、変換後の制御命令によって前記第２のソフトウェアユニットのソフトウェア更新を制御する第２ステップと、を備えるソフトウェア更新方法が提供される。
【発明の効果】
【0010】
本発明によれば、複数のプラットフォームで構成される車両システムのソフトウェアを柔軟に更新することができる。
【図面の簡単な説明】
【0011】
【図1】本発明の第１の実施形態に係るソフトウェア更新装置（ゲートウェイ）１０を利用したソフトウェア更新システム１の全体構成例を示すブロック図である。
【図2】ゲートウェイ１０のハードウェア構成例を示すブロック図である。
【図3】ＥＣＵ＿Ａ１３及びＥＣＵ＿Ｂ１６のハードウェア構成例を示すブロック図である。
【図4】ＥＣＵ＿Ｃ１７のハードウェア構成例を示すブロック図である。
【図5】ＥＣＵ＿Ｄ１８のハードウェア構成例を示すブロック図である。
【図6】ゲートウェイ１０の機能構成例を示すブロック図である。
【図7】シャシー統合ＥＣＵ１６の内部構成例を示すブロック図である。
【図8】疑似ＥＣＵ対応管理テーブルの一例である。
【図9】インタフェース変換テーブルの一例である。
【図10】ソフトウェアパッケージの構成例を示す図（その１）である。
【図11】ソフトウェアパッケージの構成例を示す図（その２）である。
【図12】配信パッケージの構成例を示す図である。
【図13】車両２におけるシステム起動時動作の手順例を示すシーケンス図である。
【図14】制御命令変換処理の手順例を示すフローチャートである。
【図15】構成情報の収集から車両パッケージの受信に関する手順例を示すシーケンス図である。
【図16】ＥＣＵを更新するソフトウェアパッケージのインストール及びアクティベートにおける手順例を示すシーケンス図（その１）である。
【図17】ＥＣＵを更新するソフトウェアパッケージのインストール及びアクティベートにおける手順例を示すシーケンス図（その２）である。
【図18】終了処理における手順例を示すシーケンス図である。
【図19】車両状態管理部１３０による車両状態の判定処理の処理手順例を示すフローチャートである。
【図20】配信パッケージ生成処理の処理手順例を示すフローチャートである。
【図21】本発明の第２の実施形態に係るソフトウェア更新装置（ゲートウェイ）１０Ａの機能構成例を示すブロック図である。
【図22】第２の実施形態における車両２におけるシステム起動時動作の手順例を示すシーケンス図である。
【図23】第２の実施形態における構成情報の収集から車両パッケージの受信に関する手順例を示すシーケンス図である。
【図24】第２の実施形態におけるＥＣＵを更新するソフトウェアパッケージのインストール手順例を示すシーケンス図である。
【図25】第２の実施形態におけるＥＣＵを更新するソフトウェアパッケージのアクティベート手順例を示すシーケンス図である。
【発明を実施するための形態】
【0012】
以下、図面を参照して、本発明の実施形態を詳述する。
【0013】
【0014】
図１に示すように、ソフトウェア更新システム１は、車両２と配信サーバ３とが、無線のネットワーク５を介して通信可能に接続されて構成される。また、ソフトウェア更新システム１は、車両２に対して故障診断やソフトウェア更新を行うツールの役割を有する診断装置６を備えてもよい。
【0015】
配信サーバ３は、ＯＥＭにおいて自社で開発した、またはサプライヤから収集したソフトウェアパッケージに基づいて、車両２に配信するパッケージ（配信パッケージ）を生成、管理、及び配信するシステムであり、例えばＯＴＡ（On The Air）サーバである。配信サーバ３は、上記収集したソフトウェアパッケージに基づいて配信パッケージを生成する配信パッケージ生成部３１と、上記ソフトウェアパッケージ及び配信パッケージ生成部３１で生成された配信パッケージを管理する配信パッケージ管理部３２と、上記ソフトウェアパッケージ及び上記配信パッケージをネットワーク５を介して車両２に向けて配信する配信部３３と、を備えて構成される。なお、配信サーバ３で生成、管理、及び配信される配信パッケージについて、後述する図１２ではそのデータ構成例が示される。
【0016】
なお、図１では、配信サーバ３に対するソフトウェアパッケージの供給元の例として、サプライヤが保有するソフトウェア管理システム４（個別には４Ａ，４Ｂ，４Ｘ）が示されている。例えばソフトウェア管理システム４Ａは、サプライヤＡが保有するシステムであって、ソフトウェアパッケージを生成するソフトウェアパッケージ生成部４１と、ソフトウェアパッケージ生成部４１で生成されたソフトウェアパッケージを管理するソフトウェアパッケージ管理部４２と、を備えて構成される。なお、ソフトウェア管理システム４で生成及び管理されるソフトウェアパッケージについて、後述する図１０及び図１１ではその構成例が示される。また、以下の説明では、配信サーバ３から車両２に対して、ソフトウェアパッケージ及び配信パッケージが別々に配信される（ダウンロードされる）形態を例とするが、本実施形態はこれに限定されるものではなく、例えば、ソフトウェアパッケージ及び配信パッケージが１つのアーカイブにまとめられて配信される形態等であってもよい。
【0017】
次に、車両２の構成について説明する。図１に示すソフトウェア更新システム１は、車両２内において、複数種類のプラットフォーム（ＰＦ）が１台の車両２に共存する構成となっており、本実施形態に係るソフトウェア更新装置１０がゲートウェイとして、これら複数種類のプラットフォームによるＥＣＵ同士の通信データの中継等を行う。
【0018】
本実施形態では、車両２に共存する複数種類のプラットフォームの一例として、ＡＵＴＯＳＡＲ ＡＰ（AUTOSAR Adaptive Platform）を第１プラットフォーム（第１ＰＦ）と称し、ＡＵＴＯＳＡＲ ＣＰ（AUTOSAR Classic Platform）を第２プラットフォーム（第２ＰＦ）と称し、その他のプラットフォーム（例えばＡＧＬ（AUTOMOTIVE Grade Linux）を第３プラットフォーム（第３ＰＦ）と称して説明を行う。
【0019】
図１に示すように、車両２は、ソフトウェア更新装置（ゲートウェイ）１０、通信モジュール１２、運転支援統合ＥＣＵ１３、カメラＥＣＵ１４、センサＥＣＵ１５、シャシー統合ＥＣＵ１６、エンジン制御ＥＣＵ１７、トランスミッション制御ＥＣＵ１８、エアバッグＥＣＵ１９、ＨＶＡＣＥＣＵ２０、車体管理ＥＣＵ２１、及びＩＶＩ２２を備え、これらが車内ネットワーク１１で接続されて構成される。上記の各ＥＣＵのうち、図１においてゲートウェイ１０の右側に示されている各ＥＣＵが、ゲートウェイ１０の配下ＥＣＵに相当する。なお、統合ＥＣＵは、所定の複数の機能を統合して動作するＥＣＵである。
【0020】
車内ネットワーク１１は、既知の通信規格、例えばＣＡＮ（Control Area Network（登録商標））、ＣＡＮ－ＦＤ（CAN with Flexible Data rate）、ＬＩＮ（Local Interconnect Network）、ＦｌｅｘＲａｙ、またはＥｔｈｅｒｎｅｔ（登録商標）の何れかを採用する。本例では、車内ネットワークＡをＣＡＮ等とし、車内ネットワークＢをＥｔｈｅｒｎｅｔとするが、車内ネットワークＡ，Ｂに同一の通信規格を採用してもよい。また、図１では図示を省略しているが、各種ＥＣＵ等の車両２内の各構成要素は、電力線で蓄電池に接続され、電力供給を受けている。
【0021】
ゲートウェイ１０は、配下ＥＣＵ同士の通信データの中継、配下ＥＣＵのソフトウェア更新、及び配下ＥＣＵに搭載されるソフトウェアの整合性確認を行う機能を有する。ゲートウェイ１０は、ＡＵＴＯＳＡＲ ＣＰ（第２ＰＦ）などのレガシープラットフォーム上に構成される。なお、ゲートウェイ１０の内部構成については、図２及び図６で詳述する。
【0022】
通信モジュール１２は、ゲートウェイ１０、配下ＥＣＵ、及びＩＶＩ２２と、配信サーバ３との通信を中継する機能を有するソフトウェアモジュールである。
【0023】
運転支援統合ＥＣＵ１３、カメラＥＣＵ１４、及びセンサＥＣＵ１５は、車両２の運転支援に関連して動作するＥＣＵであって、運転支援ドメインネットワーク（例えばＥｔｈｅｒｎｅｔ）に接続される。このうち、運転支援統合ＥＣＵ１３は、車両２の運転支援機能（ＡＤＡＳ：Advanced Driver-Assistance Systems）を統合制御するＥＣＵである。以下の説明では、簡略のため、運転支援統合ＥＣＵを「ＥＣＵ＿Ａ」と称することがある。カメラＥＣＵ１４は、車両２に搭載されたカメラを制御するＥＣＵであり、センサＥＣＵは、車両２に搭載されたセンサを制御するＥＣＵである。
【0024】
シャシー統合制御ＥＣＵ１６は、車両２におけるシャシー系機能（ブレーキやステアリング等）を統合制御するＥＣＵであって、シャシードメインネットワーク（例えばＥｔｈｅｒｎｅｔ）に接続される。以下の説明では、簡略のため、シャシー統合制御ＥＣＵを「ＥＣＵ＿Ｂ」と称することがある。
【0025】
エンジン制御ＥＣＵ１７及びトランスミッション制御ＥＣＵ１８は、車両２の駆動系の動作を制御するＥＣＵであって、パワートレインドメインネットワーク（例えばＣＡＮ－ＦＤ）に接続される。このうち、エンジン制御ＥＣＵ１７は、エンジンを制御するＥＣＵであり、トランスミッション制御ＥＣＵ１８は、トランスミッションを制御するＥＣＵである。以下の説明では、簡略のため、エンジン制御ＥＣＵを「ＥＣＵ＿Ｃ」と称することがある。
【0026】
エアバッグＥＣＵ１９、ＨＶＡＣＥＣＵ２０、及び車体管理ＥＣＵ２１は、車両２の各種設備や状態を管理するＥＣＵであって、ボディドメインネットワーク（例えばＣＡＮ／ＬＩＮ）に接続される。このうち、エアバッグＥＣＵ１９は、エアバッグを制御するＥＣＵであり、ＨＶＡＣＥＣＵ２０は、空調システム（ＨＶＡＣ：Heating, Ventilation, and Air Conditioning）を制御するＥＣＵであり、車体管理ＥＣＵ２１は、車体の状態を管理するＥＣＵである。以下の説明では、簡略のため、エアバッグＥＣＵを「ＥＣＵ＿Ｄ」と称することがある。
【0027】
ＩＶＩ２２は、車両２の乗員であるユーザへの情報提示やユーザからの入力を受け付けるＩＶＩ（In-Vehicle Infotainment）のＥＣＵであって、情報系ネットワーク（例えばＥｔｈｅｒｎｅｔ）に接続される。以下の説明では、簡略のため、ＩＶＩを「ＥＣＵ＿Ｅ」と称することがある。
【0028】
以上のように、車両２には、様々なＥＣＵが搭載されており、これらのＥＣＵを構成するプラットフォームのタイプも様々である。具体的には例えば、運転支援統合ＥＣＵ（ＥＣＵ＿Ａ）１３及びシャシー制御ＥＣＵ（ＥＣＵ＿Ｂ）１６は第１ＰＦ上に構成され、エンジン制御ＥＣＵ（ＥＣＵ＿Ｃ）１７及びエアバッグＥＣＵ（ＥＣＵ＿Ｄ）１９は第２ＰＦ上に構成され、ＩＶＩ（ＥＣＵ＿Ｅ）２２は第３ＰＦ上に構成される。また、これらのＥＣＵは、車両２の走行中にソフトウェアを書き換え可能か否かについても、仕様が異なることがある。例えば、ＥＣＵ＿Ａ１３、ＥＣＵ＿Ｂ１６、ＥＣＵ＿Ｃ１７、及びＥＣＵ＿Ｅ２２は走行中の書き換えが可能であるのに対し、ＥＣＵ＿Ｄ１８は走行中の書き換えができない。
【0029】
図２は、ゲートウェイ１０のハードウェア構成例を示すブロック図である。図２に示すように、ゲートウェイ（ソフトウェア更新装置）１０は、スイッチ５０、ＳｏＣ５１、マイコン５２、不揮発メモリ５３、及びＲＯＭ（Read Only Memory）５４を備える。スイッチ５０は、例えばＥｔｈｅｒｎｅｔスイッチである。ＳｏＣ５１は、負荷の高い処理等を搭載したＳｏＣ（System on a Chip）であり、内部にＣＰＵ（Central Processing Unit）５５を有する。マイコン５２は、安全に関する機能等を搭載したマイクロコントローラであり、内部にＣＰＵ５６、ＲＡＭ（Random Access Memory）５７、ＲＯＭ５８、及び通信制御部５９を有する。
【0030】
図３は、ＥＣＵ＿Ａ１３及びＥＣＵ＿Ｂ１６のハードウェア構成例を示すブロック図である。図３に示すように、ＥＣＵ＿Ａ１３及びＥＣＵ＿Ｂ１６は、ＳｏＣ６１、マイコン６２、不揮発メモリ６３、及びＲＡＭ６４を備える。そして、ＳｏＣ６１はＣＰＵ６５を有し、マイコン６２は、ＣＰＵ６６、ＲＡＭ６７、ＲＯＭ６８、及び通信制御部６９を有する。ＥＣＵ＿Ａ１３及びＥＣＵ＿Ｂ１６は、図２に示したゲートウェイ１０と同様に、それぞれにプロセッサ（ＣＰＵ）を有するＳｏＣとマイコンとを備えることにより、統合ＥＣＵとして複数機能を搭載することができる構成となっている。例えば、運転支援統合ＥＣＵ（ＥＣＵ＿Ａ）１３の場合、ＳｏＣ６１に認識機能が搭載され、マイコン６２に制御機能が搭載される。また、ＥＣＵ＿Ａ１３及びＥＣＵ＿Ｂ１６は、ＲＯＭ６８が２バンク（第１バンク７０，第２バンク７１）になっているため、車両２の走行中でもＲＯＭ６８に格納されているソフトウェアの書き換えができる構成となっている。
【0031】
図４は、ＥＣＵ＿Ｃ１７のハードウェア構成例を示すブロック図である。図４に示すように、ＥＣＵ＿Ｃ１７は、１つのマイコン８１を備える。そしてマイコン８１は、図３に示したマイコン６２と同様に、内部にＣＰＵ８２、ＲＡＭ８３、ＲＯＭ８４、及び通信制御部８５を有する。マイコン８１のＲＯＭ８４は、図３のＲＯＭ６８と同様に、２バンク（第１バンク８６，第２バンク８７）になっているため、車両２の走行中でもＲＯＭ８４に格納されているソフトウェアの書き換えができる構成となっている。
【0032】
図５は、ＥＣＵ＿Ｄ１８のハードウェア構成例を示すブロック図である。図５に示すように、ＥＣＵ＿Ｄ１８は、図４に示したＥＣＵ＿１７と同様に、１つのマイコン９１を備え、マイコン９１は、内部にＣＰＵ９２、ＲＡＭ９３、ＲＯＭ９４、及び通信制御部９５を有する。但し、図４に示したＥＣＵ＿１７とは異なる点として、マイコン９１のＲＯＭ９４は１バンクになっているため、車両２の走行中にはＲＯＭ９４に格納されているソフトウェアの書き換えができない構成となっている。
【0033】
図６は、ゲートウェイ１０の機能構成例を示すブロック図である。図６に示すように、ゲートウェイ（ソフトウェア更新装置）１０は、サーバ接続部１１０、ＨＭＩ制御部１２０、車両状態管理部１３０、第１更新制御部１４０、第２更新制御部１５０、及び通信部１６０を備えて構成される。
【0034】
サーバ接続部１１０は、通信モジュール１２を介した車両２から配信サーバ３への接続を担う。具体的には例えば、サーバ接続部１１０は、配信サーバ３との間で、車両２に搭載されたソフトウェア及びハードウェアの構成情報のアップロードや、キャンペーン情報及び配信パッケージのダウンロードを行う。
【0035】
ＨＭＩ制御部１２０は、車両２内のＨＭＩ機能（例えばＩＶＩやメータ）を通信を介して制御し、ソフトウェア更新に必要な表示（例えば更新内容や結果の表示）及びユーザからの操作結果（例えば許諾やキャンセル）の取得を行う。
【0036】
車両状態管理部１３０は、車両２の各種状態（例えば、イグニッションの点火状態や、走行中/駐車中といった走行状態等）を、他のＥＣＵ等から取得して管理する。
【0037】
第１更新制御部１４０は、第１ＰＦを前提としたＥＣＵのソフトウェア更新制御を実施する。第１更新制御部１４０は、第１シーケンス制御部１４１、依存関係管理部１４２、及び機器情報管理部１４３から構成される。
【0038】
第１シーケンス制御部１４１は、第１ＰＦにおけるソフトウェア更新のシーケンスを制御する。第１シーケンス制御部１４１は、直接制御可能な第１ＰＦ上のＥＣＵだけでなく、第１ＰＦ以外のプラットフォーム上のＥＣＵを第１ＰＦ上のＥＣＵとして疑似的に扱うことにより、車両２のシステム内に存在するＥＣＵを全体的に制御する。依存関係管理部１４２は、第１ＰＦに規定されたフォーマットの依存関係情報を利用して、ソフトウェア間の依存関係をチェックする。機器情報管理部１４３は、車両２内のソフトウェア情報を収集して、車両２の構成情報を管理する。
【0039】
第２更新制御部１５０は、第１ＰＦ以外のプラットフォーム（第２ＰＦ，第３ＰＦ）におけるＥＣＵのソフトウェア更新制御を実施する。第２更新制御部１５０は、疑似更新実行部１５１、依存関係管理部１５２、変換情報管理部１５３、及び第２シーケンス制御部１５４から構成され、変換情報管理部１５３は、疑似ＥＣＵ管理部１５５とインタフェース管理部１５６とを有する。
【0040】
疑似更新実行部１５１は、第１ＰＦ以外のＥＣＵについて、第１ＰＦに模擬した動作によってソフトウェア更新を実行する。依存関係管理部１５２は、第１ＰＦ以外のＥＣＵについて、各ＥＣＵの依存関係を管理する。
【0041】
変換情報管理部１５３は、第１ＰＦと第１ＰＦ以外のプラットフォームとの間における情報の対応関係を管理する。変換情報管理部１５３が有する疑似ＥＣＵ管理部１５５は、第１ＰＦで管理されるＥＣＵやソフトウェアの識別情報と、第１ＰＦ以外のプラットフォームで管理されるＥＣＵやソフトウェアの識別情報との対応関係を管理するものであり、例えば、上記対応関係を記載した疑似ＥＣＵ対応管理テーブル（図８参照）を保持する。また、変換情報管理部１５３が有するインタフェース管理部１５６は、第１ＰＦにおけるコマンドやＡＰＩ（Application Programming Interface）と、第１ＰＦ以外のプラットフォームにおけるコマンドやＡＰＩとの対応関係を管理するものであり、例えば、上記対応関係を記載したインタフェース変換テーブル（図９参照）を保持する。なお、疑似ＥＣＵ対応管理テーブルやインタフェース変換テーブルは、予め作成されて保持されているとしてよいが、他にも例えば、車両システムにおけるＥＣＵの接続等に応じて、内容を自動生成するようにしてもよい。
【0042】
第２シーケンス制御部１５４は、第２ＰＦにおけるソフトウェア更新のシーケンスを制御する。なお、第２更新制御部１５０は、第１ＰＦ以外のプラットフォームについて、プラットフォームごとに当該プラットフォームにおけるソフトウェア更新のシーケンスを制御するシーケンス制御部を備えるものであり、これらを総称して第Ｎシーケンス制御部と称する。すなわち、図４に示した第２シーケンス制御部１５４は第Ｎシーケンス制御部の一例であり、以後は、第Ｎシーケンス制御部に対しても符号１５４を付して説明する。
【0043】
通信部１６０は、ゲートウェイ１０の外部との通信を制御する。通信部１６０は、サービス管理部１６１、通信Ｉ／Ｆ１６２、第１通信部１６３、第２通信部１６４、及び第３通信部１６５から構成される。
【0044】
サービス管理部１６１は、第１ＰＦにおけるサービスを管理する。通信Ｉ／Ｆ１６２は、第１ＰＦにおけるアプリケーション間通信のインタフェースであり、例えば、第１ＰＦのＡＲＡ：：ＣＯＭ等である。第１通信部１６３は、第１ＰＦにおけるＥＣＵ間通信のインタフェース処理部である。第１通信部１６３は、例えば、ＳＯＭＥ／ＩＰ（Scalable service-Oriented MiddlewarE over IP）やＤＤＳ（Data Distribution Service for Real-time Systems）等の、第１ＰＦで標準とされる通信プロトコルを処理するブロックである。第２通信部１６４は、第２ＰＦにおけるＥＣＵ間通信のインタフェース処理部である。第２通信部１６４は、例えば、ＩＳＯ１４２２９－１（ＵＤＳ）等の、第２ＰＦで標準とされる通信プロトコルを処理するブロックである。第３通信部１６５は、第１ＰＦ及び第２ＰＦ以外のプラットフォームにおけるＥＣＵ間通信のインタフェース処理部である。第３通信部１６５は、例えば、自動車メーカ独自の通信プロトコルを処理するブロックである。第１通信部１６３、第２通信部１６４、及び第３通信部１６５は、何れかのプラットフォームにおけるＥＣＵ間通信のインタフェース処理部であり、これらは第Ｎ通信部とも称する。
【0045】
図７は、シャシー統合ＥＣＵ１６の内部構成例を示すブロック図である。シャシー統合ＥＣＵ１６は、シャシー系（ブレーキ、ステアリングなど）のＥＣＵの機能を１つのＥＣＵに統合したＥＣＵであって、ＦｕｎｃＡ１７０、ＦｕｎｃＢ１８０、及びハイパーバイザ１９０を備えて構成される。このうち、ＦｕｎｃＡ１７０及びＦｕｎｃＢ１８０が、統合ＥＣＵとしてシャシー統合ＥＣＵ１６が有する複数の機能にそれぞれ相当する。
【0046】
ＦｕｎｃＡ１７０は、例えば、ブレーキ、ステアリング等の、安全への要求が高い機能を制御する。ＦｕｎｃＡは、第１ＡＰＰ１７１、第２ＰＦ＿ＭＷ１７２及びＲＴＯＳ１７３を有する。第１ＡＰＰ１７１は、ブレーキ制御用のソフトウェアモジュールである。第２ＰＦ＿ＭＷ１７２は、第２ＰＦ（ＡＵＴＯＳＡＲ ＣＰ）の機能を提供するミドルウェア群である。ＲＴＯＳ１７３は、リアルタイムＯＳ（Operating System）である。
【0047】
ＦｕｎｃＢ１８０は、例えば、診断通信機能やコネクテッド機能等の、走行の安全に直接関与しない機能を制御する。ＦｕｎｃＢ１８０は、第３ＡＰＰ１８１、第４ＡＰＰ１８２、第１ＰＦ＿ＭＷ１８３、及びＰＯＳＩＸ＿ＯＳ１８４を有する。第３ＡＰＰ１８１は、ＦｕｎｃＢ１８０に搭載されるアプリケーションの１つであって、例えば診断機能に関するアプリケーションソフトウェアである。第４ＡＰＰ１８２は、ＦｕｎｃＢ１８０に搭載される第３ＡＰＰ１８１とは別のアプリケーションの１つであって、例えばコネクテッド機能に関するアプリケーションソフトウェアである。第１ＰＦ＿ＭＷ１８３は、第１ＰＦ（ＡＵＴＯＳＡＲ ＡＰ）の機能を提供するミドルウェア群であり、当該機能に含まれる各機能を司るソフトウェアモジュールの一例として、第１ＰＦ＿ＳＷ１８５，１８６を有する。具体的には例えば、第１ＰＦ＿ＳＷ１８５は、更新管理部の機能を提供するソフトウェアモジュールであり、第１ＰＦ＿ＳＷ１８６は、ネットワーク管理部の機能を提供するソフトウェアモジュールである。ＰＯＳＩＸ＿ＯＳ１８４は、ＰＯＳＩＸ（Portable Operating System Interface for UNIX）のＯＳである。
【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】
次に、サーバ接続部１１０は、受信したキャンペーン情報から、ダウンロードすべき車両パッケージ（更新パッケージ）の一覧の読出しを第１シーケンス制御部１４１に要求する（ステップＳ３２０）。第１シーケンス制御部１４１がダウンロードすべき更新パッケージの一覧を読み出す詳細な方法については説明を省略するが、例えば、第１シーケンス制御部１４１は、例えばＨＭＩ制御部１２０によってキャンペーンの一覧をＨＭＩに表示させて、ユーザからダウンロードしたい車両パッケージ（更新パッケージ）を選択させるようにしてもよい。そして、第１シーケンス制御部１４１は、ダウンロードすべき更新パッケージの一覧をサーバ接続部１１０に応答する（ステップＳ３２１）。そしてサーバ接続部１１０は、応答された更新パッケージの一覧に基づいて、更新パッケージの提供を配信サーバ３に要求する（ステップＳ３２２）。
【0098】
次に、配信サーバ３は、ステップＳ３２２で要求された更新パッケージを、サーバ接続部１１０に送信する（ステップＳ３２３）。なお、ステップＳ３２２で複数の更新パッケージが要求された場合、ステップＳ３２３では各更新パッケージが、一斉にあるいは順次送信されることになるが、図１５では、簡便のため、１つの更新パッケージ（第１パッケージ）の送信を例示している。
【0099】
配信サーバ３から更新パッケージを受信したサーバ接続部１１０は、第１シーケンス制御部１４１に、更新パッケージ（第１パッケージ）の転送開始を要求し、許可が得られると、第１シーケンス制御部１４１に第１パッケージを転送する（ステップＳ３２４～Ｓ３２５）。そして、サーバ接続部１１０は、第１パッケージの転送が終了すると、第１シーケンス制御部１４１に第１パッケージの転送完了を通知する（ステップＳ３２６）。
【0100】
そして、第１パッケージの転送完了の通知を受け取ると、第１シーケンス制御部１４１は、受信した第１パッケージを検証する（第１パッケージ検証）。検証の具体的な内容としては例えば、パッケージに含まれるデジタル署名を検証し、正規の更新パッケージであることを確認する等が挙げられる。
【0101】
以上のステップＳ３１７～Ｓ３２６の処理によって、第１シーケンス制御部１４１は、システム内の更新可能なソフトウェアに関する情報（キャンペーン情報）を取得し、キャンペーンから選択した任意の車両パッケージ（更新パッケージ）を配信サーバ３からダウンロードすることができる。
【0102】
（１－３－４）インストール及びアクティベート
図１６及び図１７は、ＥＣＵを更新するソフトウェアパッケージのインストール及びアクティベートにおける手順例を示すシーケンス図（その１，その２）である。図１６及び図１７に示す処理の前提として、図１５に示した処理によって第１シーケンス制御部１４１が配信サーバ３からダウンロードした更新パッケージには、ＥＣＵ＿Ａ１３，ＥＣＵ＿Ｃ１７，ＥＣＵ＿Ｄ１９を更新するための情報が含まれていると想定する。そして、図１６及び図１７では、各ＥＣＵを更新するソフトウェアパッケージ（ＳＰ１～ＳＰ３）を配信サーバ３からダウンロードし、各ＥＣＵにインストール（データ転送）し、ドライバからアクティベート実行の許諾を得た場合に、更新されたＥＣＵの機能をアクティベート（有効化）する処理の手順例を示す。なお、詳細は後述するが、ＥＣＵへのデータ転送のタイミングはアクティベート実行の許諾を得た後でも可能である。
図１６及び図１７は、ＥＣＵを更新するソフトウェアパッケージのインストール及びアクティベートにおける手順例を示すシーケンス図（その１，その２）である。図１６及び図１７に示す処理の前提として、図１５に示した処理によって第１シーケンス制御部１４１が配信サーバ３からダウンロードした更新パッケージには、ＥＣＵ＿Ａ１３，ＥＣＵ＿Ｃ１７，ＥＣＵ＿Ｄ１９を更新するための情報が含まれていると想定する。そして、図１６及び図１７では、各ＥＣＵを更新するソフトウェアパッケージ（ＳＰ１～ＳＰ３）を配信サーバ３からダウンロードし、各ＥＣＵにインストール（データ転送）し、ドライバからアクティベート実行の許諾を得た場合に、更新されたＥＣＵの機能をアクティベート（有効化）する処理の手順例を示す。なお、詳細は後述するが、ＥＣＵへのデータ転送のタイミングはアクティベート実行の許諾を得た後でも可能である。
【0103】
まず、図１６によれば、第１シーケンス制御部１４１が、車両状態管理部１３０に車両状態取得要求を行うことにより、車両状態管理部１３０が車両２の状態に関する情報（車両状態）を読み出して第１シーケンス制御部１４１に送信する（ステップＳ４０１～Ｓ４０２）。車両状態管理部１３０は、厳密にはサービスインタフェースを経由して車両状態を読み出すが、図１６ではその記載を省略する。
【0104】
次に、車両状態管理部１３０から第１シーケンス制御部１４１に対して、車両２の状態が通知され、第１シーケンス制御部１４１は、取得した車両状態に基づいて、インストール処理を開始して良いか否かを判定する（不図示）。そして第１シーケンス制御部１４１は、インストール処理を開始して良いと判定した場合には、以下に説明するＥＣＵ更新用のソフトウェアパッケージ（ＳＰ）のダウンロードを開始する。
【0105】
ＥＣＵ更新用のソフトウェアパッケージをダウンロードする処理手順は、対象のＥＣＵが第１ＰＦ上のＥＣＵであるか否かによって異なる。すなわち、図１６では、ＥＣＵ＿Ａ１３用のＥＣＵパッケージ（ＳＰ１）のダウンロードと、ＥＣＵ＿Ｃ１７用のＥＣＵパッケージ（ＳＰ２）またはＥＣＵ＿Ｄ１９用のＥＣＵパッケージ（ＳＰ２）のダウンロードとで、処理手順が異なる。
【0106】
ＥＣＵ＿Ａ１３用のＥＣＵパッケージ（ＳＰ１）をダウンロードする処理では、まず、第１シーケンス制御部１４１がサーバ接続部１１０にＳＰ１の取得を要求する（ステップＳ４０３）。当該要求を受けたサーバ接続部１１０は、配信サーバ３にＳＰ１の取得を要求することで、配信サーバ３からＳＰ１を受信する（ステップＳ４０４～Ｓ４０５）。
【0107】
次に、サーバ接続部１１０は、ＳＰ１のデータ転送の開始を通知する。具体的には、サーバ接続部１１０から第１シーケンス制御部１４１にＳＰ１の転送開始が通知され、第１シーケンス制御部１４１が、通信Ｉ／Ｆ１６２及び第１通信部１６３を介して、第１ＰＦ上のＥＣＵ＿Ａ１３の更新管理部に転送開始を通知する（ステップＳ４０６～Ｓ４０９）。そしてこの転送開始の通知に対する応答が、ＥＣＵ＿Ａ１３から第１通信部１６３、通信Ｉ／Ｆ１６２、第１シーケンス制御部１４１を経由してサーバ接続部１１０に送信される（ステップＳ４１０～Ｓ４１３）。
【0108】
次に、サーバ接続部１１０は、ＳＰ１のデータをＥＣＵ＿Ａ１３に転送する。具体的には、サーバ接続部１１０から第１シーケンス制御部１４１にＳＰ１が送信され、第１シーケンス制御部１４１が、通信Ｉ／Ｆ１６２及び第１通信部１６３を介して、第１ＰＦ上のＥＣＵ＿Ａ１３の更新管理部にＳＰ１を転送する（ステップＳ４１４～Ｓ４１７）。そしてこのデータ転送に対する応答が、ＥＣＵ＿Ａ１３から第１通信部１６３、通信Ｉ／Ｆ１６２、第１シーケンス制御部１４１を経由してサーバ接続部１１０に送信される（ステップＳ４１８～Ｓ４２１）。
【0109】
そして、ＳＰ１のデータ転送が終了すると、サーバ接続部１１０は、ＳＰ１のデータ転送の終了を通知する。当該通知は、データ転送開始の通知の場合と同様に、第１シーケンス制御部１４１、通信Ｉ／Ｆ１６２、第１通信部１６３を経てＥＣＵ＿Ａ１３の更新管理部に転送され（ステップＳ４２２～Ｓ４２５）、その応答がサーバ接続部１１０に送信される（ステップＳ４２６～Ｓ４２９）。
【0110】
以上のように、第１ＰＦ上のＥＣＵ＿Ａ１３用のＥＣＵパッケージ（ＳＰ１）のダウンロードは、全ての処理を第１ＰＦ上で実行可能であり、ＥＣＵ＿Ａ１３の更新管理部は受信したＳＰ１をインストールすることができる。
【0111】
一方、第１ＰＦ以外のプラットフォーム上のＥＣＵ用のＥＣＵパッケージのダウンロードにおいては、ダウンロードしたソフトウェアパッケージは、即座に対象のＥＣＵに転送されるのではなく、所定条件を満たすまで（図１７で説明するパッケージ処理要求またはアクティベート要求が発行されるまで）、一旦、ゲートウェイ１０内（疑似更新実行部１５１）に蓄積される。このような処理手順の一例として、以下、ＥＣＵ＿Ｃ１７用のＥＣＵパッケージ（ＳＰ２）をダウンロードする処理手順を説明する。
【0112】
ＥＣＵ＿Ｃ１７用のＥＣＵパッケージ（ＳＰ２）をダウンロードする処理では、まず、第１シーケンス制御部１４１がサーバ接続部１１０にＳＰ２の取得を要求する（ステップＳ４３１）。当該要求を受けたサーバ接続部１１０は、配信サーバ３にＳＰ１の取得を要求することで、配信サーバ３からＳＰ１を受信する（ステップＳ４３２～Ｓ４３３）。
【0113】
次に、サーバ接続部１１０は、ＳＰ２のデータ転送の開始を通知する。具体的には、サーバ接続部１１０から第１シーケンス制御部１４１にＳＰ２の転送開始が通知され、第１シーケンス制御部１４１が、通信Ｉ／Ｆ１６２を介して、第１ＰＦ上でＥＣＵ＿Ｃ１７の疑似的な更新管理部（疑似更新管理部）として認識される疑似更新実行部１５１に、転送開始を通知する（ステップＳ４３４～Ｓ４３６）。なお、ステップＳ４３６においてＳＰ２の転送開始の通知を受信した疑似更新実行部１５１は、図１５のステップＳ３１０においてＥＣＵ＿Ｃ１７のＳＷ情報の取得要求を受信したときと同様の処理を行って、ＳＰ２のデータ転送に関するＥＣＵ識別情報、ＰＦ情報、及び変換後Ｉ／Ｆを取得する。その後、転送開始の通知に対する応答が、疑似更新実行部１５１から通信Ｉ／Ｆ１６２、第１シーケンス制御部１４１を経由してサーバ接続部１１０に送信される（ステップＳ４３７～Ｓ４３９）。
【0114】
次に、サーバ接続部１１０は、データ転送の処理として、ＳＰ２を第１シーケンス制御部１４１に送信し、第１シーケンス制御部１４１は、通信Ｉ／Ｆ１６２を介して、ＥＣＵ＿Ｃ１７の第１ＰＦ上における疑似更新管理部である疑似更新実行部１５１に、ＳＰ２を転送する（ステップＳ４４０～Ｓ４４２）。このとき、疑似更新実行部１５１は、ステップＳ４４２で受信したＳＰ２を自身で保持し、データ転送に対する応答を、通信Ｉ／Ｆ１６２、第１シーケンス制御部１４１を経由してサーバ接続部１１０に送信する（ステップＳ４４３～Ｓ４４５）。
【0115】
そして、ＳＰ２のデータ転送が終了すると、サーバ接続部１１０は、ＳＰ２のデータ転送の終了を第１シーケンス制御部１４１に通知し、第１シーケンス制御部１４１は、通信Ｉ／Ｆ１６２を介して、ＥＣＵ＿Ｃ１７の第１ＰＦ上における疑似更新管理部である疑似更新実行部１５１に、当該通知を転送する（ステップＳ４４６～Ｓ４４８）。そして当該通知への応答が、通信Ｉ／Ｆ１６２、第１シーケンス制御部１４１を経由してサーバ接続部１１０に送信される（ステップＳ４４９～Ｓ４５１）。ステップＳ４４２で述べたように、疑似更新実行部１５１は、データ転送時に受信したＳＰ２を自身で保持することから、ＳＰ２のデータ転送終了時には、ＳＰ２のデータ全体が疑似更新実行部１５１に蓄積される。
【0116】
また、図１６では、ステップＳ４５１の後に、第２ＰＦ上のＥＣＵ＿Ｄ１９用のＥＣＵパッケージ（ＳＰ３）をダウンロードする処理が簡略して示されているが、この一連の処理は、ＥＣＵ＿Ｃ１７用のＥＣＵパッケージ（ＳＰ２）をダウンロードする処理（ステップＳ４３１～Ｓ４５１）と同様であるため、説明を省略する。
【0117】
上述したように、第１ＰＦ以外のプラットフォーム上のＥＣＵ（疑似ＥＣＵ）を対象とするソフトウェアパッケージは、ダウンロード後に一時的に疑似更新実行部１５１に蓄積される。この時点では、各ソフトウェアパッケージは対象のＥＣＵにデータ転送及びインストールされていない。これらのソフトウェアパッケージに対するその後の処理として、本実施形態では、様々なタイミングで対象のＥＣＵにデータ転送しインストールすることができる。データ転送のタイミングは、図９のインタフェース変換テーブル２２０に設定することができる。具体例として図１７では、ＥＣＵ＿Ｃ１７用のＥＣＵパッケージについては、第１シーケンス制御部１４１によるパッケージ処理要求の発行を契機として実行されるとし、ＥＣＵ＿Ｄ１９用のＥＣＵパッケージについては、アクティベートの確認後に発行されるアクティベート要求を契機として実行されるとしている。
【0118】
【0119】
図１７によれば、まず、第１シーケンス制御部１４１が、ＥＣＵ＿Ｃ１７に向けて、第１ＰＦにおけるパッケージ処理要求を行う。具体的には、第１シーケンス制御部１４１は、通信Ｉ／Ｆ１６２にＥＣＵ＿Ｃ１７向けのパッケージ処理要求を送信し（ステップＳ５０１）、通信Ｉ／Ｆ１６２は、当該要求がＥＣＵ＿Ｃ１７向けであることから、疑似更新実行部１５１に当該要求を転送する（ステップＳ５０２）。
【0120】
次に、第１ＰＦにおけるパッケージ処理要求を受信した疑似更新実行部１５１は、インタフェース変換テーブルを参照して、受信した要求を第２ＰＦにおける要求に変換する（ＡＰＩ変換）。ここで、ＥＣＵ＿Ｃ１７を走行中の書き換えが可能なＥＣＵであるとすると、図９のインタフェース変換テーブル２２０を用いた場合、「パッケージ処理要求」の第１ＰＦ制御命令２２１に対応する第２ＰＦにおける変換後インタフェース２２３は、「［走行中書換可ＥＣＵの場合］データ転送要求」となる。したがって、パッケージ処理要求を受信した疑似更新実行部１５１は、ＡＰＩ変換を行うことにより、第２シーケンス制御部１５４にＥＣＵ＿Ｃ１７への「データ転送要求」を行う（ステップＳ５０３）。ステップＳ５０３において、疑似更新実行部１５１は例えば、自身に蓄積したソフトウェアパッケージ（ＳＰ２）から更新データを抽出し、データ転送要求に添えて第２シーケンス制御部１５４に送信する。
【0121】
そして、第２シーケンス制御部１５４は、ステップＳ５０３のデータ転送要求への応答を疑似更新実行部１５１に返した後（ステップＳ５０４）、第２通信部１６４を介してＥＣＵ＿Ｃ１７にＳＰ２のデータ転送の開始を要求する（ステップＳ５０５～Ｓ５０６）。
【0122】
そして、第２シーケンス制御部１５４は、データ転送の開始要求に応答が得られると（ステップＳ５０７～Ｓ５０８）、第２通信部１６４を介してＥＣＵ＿Ｃ１７の更新管理部にＳＰ２のデータを転送する（ステップＳ５０９～Ｓ５１０）。また、データ転送時は、データ転送に対するＥＣＵ＿Ｃ１７の応答が、第２通信部１６４を介して第２シーケンス制御部１５４に送信される（ステップＳ５１１～Ｓ５１２）。
【0123】
そして、ＳＰ２のデータ転送が終了すると、第２シーケンス制御部１５４は、ＳＰ２のデータ転送の終了を通知する。当該通知は、データ転送開始の通知の場合と同様に、第２通信部１６４を経てＥＣＵ＿Ｃ１７の更新管理部に転送され（ステップＳ５１３～Ｓ５１４）、その応答が第２シーケンス制御部１５４に送信される（ステップＳ５１５～Ｓ５１６）。
【0124】
次に、ステップＳ５１６でデータ転送終了の応答を受信した第２シーケンス制御部１５４は、疑似更新実行部１５１に、ステップＳ５０３のデータ転送要求の結果を回答する（ステップＳ５１７）。そして、疑似更新実行部１５１は、通信Ｉ／Ｆ１６２を介して第１シーケンス制御部１４１に、ステップＳ５０１～Ｓ５０２のパッケージ処理要求の結果を回答する（ステップＳ５１８～Ｓ５１９）。
【0125】
以上のステップＳ５０１～Ｓ５１９の処理によって、配信サーバ３からダウンロードされて疑似更新実行部１５１に蓄積されていたＥＣＵ＿Ｃ１７用のＥＣＵパッケージ（ＳＰ２）は、対象のＥＣＵ＿Ｃ１７に転送され、インストールすることができる。その後、第１シーケンス制御部１４１は、インストールした更新パッケージのアクティベートを確認するタイミングを把握するために、車両状態管理部１３０に、アクティベート可能な状態となったら通知を行うよう、車両状態の通知要求を送信する（ステップＳ５２０）。
【0126】
次に、図１７のステップＳ５２１以降の処理を説明する。ステップＳ５２１以降の処理は、更新パッケージのアクティベートに関する処理である。具体的には、ステップＳ５２１～Ｓ５２３は、アクティベートの確認に関する処理であり、ステップＳ５２４～Ｓ５４２は、ＥＣＵ＿Ｄ１９用の更新プログラム（ＥＣＵパッケージ，ＳＰ３）のデータ転送及びアクティベートに関する処理であり、ステップＳ５４３～Ｓ５４８は、ＥＣＵ＿Ａ１３用の更新プログラム（ＥＣＵパッケージ，ＳＰ１）のアクティベートに関する処理であり、ステップＳ５４９～Ｓ５５７は、ＥＣＵ＿Ｃ１７用の更新プログラム（ＥＣＵパッケージ，ＳＰ２）のアクティベートに関する処理である。
【0127】
アクティベートの確認の契機として、例えばイグニッションがＯＦＦになったとき、車両状態管理部１３０は、車両状態がアクティベート可能な状態になったことを第１シーケンス制御部１４１に通知する（ステップＳ５２１）。当該通知を受けた第１シーケンス制御部１４１は、ＨＭＩ制御部１２０に、ドライバにアクティベート実行の可否を確認する確認画面の表示を要求する（ステップＳ５２２）。確認画面においてドライバからアクティベート実行の許諾を得ると、ＨＭＩ制御部１２０が、第１シーケンス制御部１４１にアクティベート確認の結果を返答する（ステップＳ５２３）。確認画面の表示形態は特に限定しないが、例えば、アクティベート待ちのソフトウェアパッケージの一覧を表示してドライバが許諾対象を選択できるようにしてもよいし、ドライバがアクティベートを一括して許諾できるようにしてもよい。また、更新ソフトウェアの種別によっては、ドライバによるアクティベートの許諾を不要とするものがあってもよい。
【0128】
以後は、ステップＳ５２１～Ｓ５２３の処理により、ＳＰ１～ＳＰ３の全てのソフトウェアパッケージについてアクティベートの許諾が得られたとして、説明を続ける。
【0129】
ＥＣＵ＿Ｄ１９用の更新プログラムについて、第１シーケンス制御部１４１は、アクティベートの許諾が得られたことから、通信Ｉ／Ｆ１６２を介して疑似更新実行部１５１にＥＣＵ＿Ｄ１９の更新プログラムのアクティベートを要求する（ステップＳ５２４～Ｓ５２５）。第１シーケンス制御部１４１からのアクティベート要求は第１ＰＦにおける要求として行われるため、当該要求を受信した疑似更新実行部１５１は、ステップＳ５０２で第１ＰＦにおけるパッケージ処理要求を受信したときと同様にＡＰＩ変換を行って、受信したアクティベート要求を第２ＰＦにおける要求に変換する。具体的には、図９のインタフェース変換テーブル２２０において「アクティベート要求」の第１ＰＦ制御命令２２１に対応する第２ＰＦにおける変換後インタフェース２２３は、「第２通信部 ［走行中書換不可ＥＣＵの場合］データ転送要求」となっている。
【0130】
ここで、図５で説明したようにＥＣＵ＿Ｄ１９は走行中書換不可のＥＣＵであるため、疑似更新実行部１５１は、第２シーケンス制御部１５４にデータ転送要求を送信し、第２シーケンス制御部１５４が、第２通信部１６４を介してＥＣＵ＿Ｄ１９に、ダウンロードされたソフトウェアパッケージ（ＳＰ３）のデータ転送要求を行う（ステップＳ５２６～Ｓ５２７）。
【0131】
なお、疑似更新実行部１５１からデータ転送要求を受信した後の、第２シーケンス制御部１５４からＥＣＵ＿Ｄ１９に対するデータ転送の一連の処理手順は、ＥＣＵ＿Ｃ１７に対するデータ転送について前述したステップＳ５０５～Ｓ５１７の処理で転送先のＥＣＵを変更したものと同様であるため、詳細な処理を省略する（ステップＳ５２８～Ｓ５４０）。
【0132】
そしてステップＳ５４０において第２シーケンス制御部１５４から疑似更新実行部１５１にデータ転送要求の結果が回答されると、疑似更新実行部１５１は、通信Ｉ／Ｆ１６２を介して第１シーケンス制御部１４１に、ステップＳ５２４～Ｓ５２５のアクティベート要求の結果を回答する（ステップＳ５４１～Ｓ５４２）。
【0133】
以上のステップＳ５２４～Ｓ５４２の処理によって、ＥＣＵ＿Ｄ１９用の更新プログラム（ＥＣＵパッケージ，ＳＰ３）を、疑似更新実行部１５１からＥＣＵ＿Ｄ１９に転送し、インストールした後にアクティベートすることができる。
【0134】
次に、ＥＣＵ＿Ａ１３用の更新プログラムについて、第１シーケンス制御部１４１は、アクティベートの許諾が得られたことから、通信Ｉ／Ｆ１６２及び第１通信部１６３を介して、ＥＣＵ＿Ａ１３にアクティベート要求を行う。ＥＣＵ＿Ａ１３は第１ＰＦ上にあるＥＣＵであるため、前述のＥＣＵ＿Ｄ１９のように疑似更新実行部１５１を介した処理は必要なく、ＥＣＵ＿Ａ１３からはアクティベート実行後に、応答が第１シーケンス制御部１４１に送られて、ＥＣＵ＿Ａ１３用の更新プログラムのアクティベートが完了する（ステップＳ５４３～Ｓ５４８）。
【0135】
次に、ＥＣＵ＿Ｃ１７用の更新プログラムについて、第１シーケンス制御部１４１は、アクティベートの許諾が得られたことから、通信Ｉ／Ｆ１６２を介して疑似更新実行部１５１にＥＣＵ＿Ｃ１７の更新プログラムのアクティベートを要求する（ステップＳ５４９～Ｓ５５０）。当該要求を受信した疑似更新実行部１５１は、ＡＰＩ変換を行って、受信したアクティベート要求を第２ＰＦにおける要求に変換する。なお、ＥＣＵ＿Ｃ１７は走行中書換可能なＥＣＵであり、対象の更新プログラムはステップＳ５０３～Ｓ５１７の処理によって既にＥＣＵ＿Ｃ１７に転送されてインストール済みであるため、データ転送は必要なく、アクティベート要求をＥＣＵ＿Ｃ１７に転送すればよい。このことは、図９のインタフェース変換テーブル２２０において、「アクティベート要求」の第１ＰＦ制御命令２２１に対応する第２ＰＦにおける変換後インタフェース２２３が、「第２通信部 ［走行中書換可ＥＣＵの場合］アクティベート要求」となっていることからも確かめられる。
【0136】
したがって、疑似更新実行部１５１は、第２シーケンス制御部１５４にアクティベート要求を送信し、第２シーケンス制御部１５４が第２通信部１６４を介してＥＣＵ＿Ｃ１７に、アクティベート要求を転送する（ステップＳ５５１～Ｓ５５４）。そして、ＥＣＵ＿Ｃ１７で更新プログラム（ＳＰ２）が有効化された後、ＥＣＵ＿Ｃ１７から第２通信部１６４を介して第２シーケンス制御部１５４に結果が送信され（ステップＳ５５５～Ｓ５５６）、さらに、第２シーケンス制御部１５４は、疑似更新実行部１５１にステップＳ５５１～Ｓ５５２のアクティベート要求の結果を回答する（ステップＳ５５７）。なお、図１７では記載を省略しているが、さらにその後、疑似更新実行部１５１が、通信Ｉ／Ｆ１６２を介して第１シーケンス制御部１４１に、ステップＳ５４９～Ｓ５５０のアクティベート要求の結果を回答する。
【0137】
以上のステップＳ５４９～Ｓ５５７等の処理によって、ＥＣＵ＿Ｃ１７用の更新プログラム（ＥＣＵパッケージ，ＳＰ２）についても、ＥＣＵ＿Ｃ１７において有効化（アクティベート）することができる。
【0138】
（１－３－５）終了処理
図１８は、終了処理における手順例を示すシーケンス図である。図１８には、第１ＰＦ上で扱われる各ＥＣＵを終了させるときの手順例が示されている。この終了処理の手順は、対象が第１ＰＦのＥＣＵであるか、第１ＰＦ上に模擬された疑似ＥＣＵであるかによって異なる。
図１８は、終了処理における手順例を示すシーケンス図である。図１８には、第１ＰＦ上で扱われる各ＥＣＵを終了させるときの手順例が示されている。この終了処理の手順は、対象が第１ＰＦのＥＣＵであるか、第１ＰＦ上に模擬された疑似ＥＣＵであるかによって異なる。
【0139】
第１ＰＦ上のＥＣＵ＿Ａ１３の終了処理では、第１シーケンス制御部１４１は、通信Ｉ／Ｆ１６２及び第１通信部１６３を介して、第１ＰＦ上のＥＣＵ＿Ａ１３にＥＣＵ＿Ａ１３の終了処理を要求する（ステップＳ６０１～Ｓ６０３）。そしてＥＣＵ＿Ａ１３からは、終了処理の完了時に応答が第１シーケンス制御部１４１に送られる（ステップＳ６０４～Ｓ６０６）。
【0140】
一方、第１ＰＦ上に模擬されたＥＣＵ＿Ｃ１７の終了処理では、第１シーケンス制御部１４１は、通信Ｉ／Ｆ１６２を介して、第１ＰＦ上におけるＥＣＵ＿Ｃ１７の疑似更新管理部である疑似更新実行部１５１に、終了処理を要求する（ステップＳ６０７～Ｓ６０８）。そして、終了処理要求を受信した疑似更新実行部１５１は、受信した要求に基づいてＥＣＵ識別情報、ＰＦ情報、及び変換後Ｉ／Ｆを取得し（図１５参照）、第１ＰＦ上に模擬したＥＣＵ＿Ｃ１７の疑似更新管理部を終了した後、終了処理要求への応答を、通信Ｉ／Ｆ１６２を介して第１シーケンス制御部１４１に送信する（ステップＳ６０９～Ｓ６１０）。
【0141】
また、第１ＰＦ上に模擬されたＥＣＵ＿Ｄ１９の終了処理も、上述したＥＣＵ＿Ｃ１７の終了処理と同様である（ステップＳ６１１～Ｓ６１４）。
【0142】
以上のように、ステップＳ６０１～Ｓ６１４の処理が行われることにより、第１シーケンス制御部１４１は、第１ＰＦ上で制御するシステム内の各ＥＣＵの終了処理を実行することができる。
【0143】
（１－３－６）実行条件に基づく車両状態の判定処理
図１９は、車両状態管理部１３０による車両状態の判定処理の処理手順例を示すフローチャートである。図１９に示す処理は、配信パッケージ２５０に含まれる車両全体更新制御情報２５１中の実行条件２５６に基づいて、第１更新制御部１４０（特に第１シーケンス制御部１４１）がソフトウェア更新の各プロセスを実行可能なタイミングを把握するための処理であって、図１７のステップＳ５２０～Ｓ５２１の詳細な処理に相当する。
図１９は、車両状態管理部１３０による車両状態の判定処理の処理手順例を示すフローチャートである。図１９に示す処理は、配信パッケージ２５０に含まれる車両全体更新制御情報２５１中の実行条件２５６に基づいて、第１更新制御部１４０（特に第１シーケンス制御部１４１）がソフトウェア更新の各プロセスを実行可能なタイミングを把握するための処理であって、図１７のステップＳ５２０～Ｓ５２１の詳細な処理に相当する。
【0144】
図１９によればまず、第１更新制御部１４０の第１シーケンス制御部１４１が、配信パッケージ２５０に含まれる車両全体更新制御情報２５１中の実行条件２５１（具体的には例えば、イグニッションＯＦＦ）を車両状態通知要求のパラメータに設定して、車両状態管理部１３０に送信する（ステップＳ５２０１）。
【0145】
次に、車両状態管理部１３０は、車両状態通知要求を受信する（ステップＳ５２０２）と、現在の車両状態が受信した車両状態通知要求に含まれる実行条件に合致するか否かを確認する（ステップＳ５２０３）。実行条件に合致する場合（ステップＳ５２０３のＹＥＳ）、車両状態管理部１３０は、車両状態が実行条件に合致したことを第１更新制御部１４０（第１シーケンス制御部１４１）に通知する（ステップＳ５２１）。
【0146】
一方、ステップＳ５２０３において現在の車両状態が実行条件に合致しない場合（ステップＳ５２０３のＮＯ）、車両状態管理部１３０は、車両状態が受信した車両状態通知要求の実行条件に合致するまで状態を監視し（ステップＳ５２０４）、合致を確認すると、車両状態が実行条件に合致したことを第１更新制御部１４０（第１シーケンス制御部１４１）に通知する（ステップＳ５２１）。
【0147】
上記ステップＳ５２０１～Ｓ５２１の処理を実行することにより、ソフトウェア更新装置１０は、実行条件２５６に基づいて、車両の状態を確認してから更新プロセスを実行することができるため、安全にソフトウェア更新を実施することができる。また、実行条件を配信パッケージ２５０に含めて送信することで、更新内容に応じて柔軟に安全条件を設定することができる。
【0148】
（１－３－７）配信パッケージ生成処理
図２０は、配信パッケージ生成処理の処理手順例を示すフローチャートである。図２０に示す配信パッケージ生成処理は、配信サーバ３の配信パッケージ生成部３１が配信パッケージ２５０を生成する処理である。
図２０は、配信パッケージ生成処理の処理手順例を示すフローチャートである。図２０に示す配信パッケージ生成処理は、配信サーバ３の配信パッケージ生成部３１が配信パッケージ２５０を生成する処理である。
【0149】
図２０によればまず、配信パッケージ生成部３１は、ソフトウェア管理システム４のソフトウェアパッケージ管理部４２からソフトウェアパッケージを読み出す（ステップＳ１００１）。
【0150】
次に、配信パッケージ生成部３１は、ステップＳ１００１で読み出したソフトウェアパッケージが第１ＰＦ向けのパッケージであるか、第２ＰＦ向けのパッケージであるかを判定する（ステップＳ１００２）。第１ＰＦ向けソフトウェアパッケージであると判定した場合（ステップＳ１００２の第１ＰＦ）、配信パッケージ生成部３１は、ソフトウェアパッケージ２３０（図１０参照）から更新対象ソフトウェア情報２６１を抽出する（ステップＳ１００３）。一方、第２ＰＦ向けソフトウェアパッケージであると判定した場合（ステップＳ１００２の第２ＰＦ）、配信パッケージ生成部３１は、ソフトウェアパッケージ２４０（図１１（Ａ）参照）の更新対象ソフトウェア情報２４３から、ソフトウェアパッケージ２４０向けの更新対象ソフトウェア情報２６１を生成する（ステップＳ１００４）。
【0151】
そして、配信パッケージ生成部３１は、ステップＳ１００１～Ｓ１００４の処理を繰り返して、読み出したソフトウェアパッケージのすべてについて更新対象ソフトウェア情報２６１を抽出または生成すると、次に車両全体更新制御情報２５１を生成する（ステップＳ１００５）。
【0152】
そして最後に、配信パッケージ生成部３１は、ステップＳ１００３～Ｓ１００５で生成した車両全体更新制御情報２５１及び更新対象ソフトウェア情報２６１から、デジタル署名２７１を生成する（ステップＳ１００６）。
【0153】
以上のようにステップＳ１００１～Ｓ１００６の処理を実行することにより、配信パッケージ生成部３１は、ソフトウェアパッケージ管理部４２から読み出したソフトウェアパッケージが第２ＰＦ用のパッケージだった場合には、第１ＰＦ用のパッケージに合わせた更新対象ソフトウェア情報２６１を生成することで、第１ＰＦでも処理可能な配信パッケージ２５０を生成することができる。
【0154】
以上、各図面を参照しながら詳述したように、本実施形態に係るソフトウェア更新装置１０によれば、車両システムが複数種類のプラットフォームで構成される場合でも、各プラットフォーム上のソフトウェアユニット（ＥＣＵ）やＥＣＵ内のソフトウェアを、第１プラットフォーム上で管理及び制御することができる。詳しくは、第２更新制御部１５０において、第１プラットフォームとの間における識別情報の対応関係（疑似ＥＣＵ対応管理テーブル）やインタフェースの対応関係（インタフェース変換テーブル）を保持し、疑似更新実行部１５１がプラットフォーム間の変換を行って、第１プラットフォーム以外のプラットフォーム上のＥＣＵを第１プラットフォーム上の疑似的なＥＣＵとすることにより、第１プラットフォームの制御部（第１更新制御部１４０）が、各ＥＣＵに対する制御命令やソフトウェア処理を、第１プラットフォーム上で統括して制御することができる。
【0155】
また、本実施形態に係るソフトウェア更新装置１０は、車両２の外部の配信サーバ３から提供されるソフトウェアパッケージについて、対象のＥＣＵが存在するプラットフォームに依存することなく、第１プラットフォームの制御部（第１更新制御部１４０）で受信することができ、さらに、対象のＥＣＵに対するインストールやアクティベート等の要求を、第１プラットフォーム上で指示することができる。また、各ＥＣＵのソフトウェアに対する更新等の処理を第１プラットフォーム上で統一的に指示することもできる。すなわち、本実施形態に係るソフトウェア更新装置１０は、複数のプラットフォームで構成される車両システムのソフトウェアを柔軟に更新することができる。
【0156】
また、本実施形態に係るソフトウェア更新装置１０は、上述したように、プラットフォーム間の対応関係を示す管理情報を利用して、複数のプラットフォーム上のＥＣＵを１つのプラットフォーム上で取り扱い可能とするため、車両システムにおけるプラットフォームの構成が変化したり、ＥＣＵの追加等が行われたりした場合であっても、上記管理情報を変更するだけで、大きな設計変更等を行うことなく対応することができることから、スケーラブルな仕組みによって拡張対応を可能とする。
【0157】
（２）第２の実施形態
第１の実施形態では、第１ＰＦの更新制御機能に対して、第２ＰＦの制御機能が第１ＰＦを模擬することにより、複数のＰＦのソフトウェア更新を実現できることを示した。これに対し、第２の実施形態では、第２ＰＦの更新機能が第１ＰＦの更新制御機能を制御して複数のＰＦのソフトウェア更新を実現できることを示す。なお、第２の実施形態の説明では、第１の実施形態と同様の構成及び処理については、説明を省略する。
第１の実施形態では、第１ＰＦの更新制御機能に対して、第２ＰＦの制御機能が第１ＰＦを模擬することにより、複数のＰＦのソフトウェア更新を実現できることを示した。これに対し、第２の実施形態では、第２ＰＦの更新機能が第１ＰＦの更新制御機能を制御して複数のＰＦのソフトウェア更新を実現できることを示す。なお、第２の実施形態の説明では、第１の実施形態と同様の構成及び処理については、説明を省略する。
【0158】
（２－１）ゲートウェイのソフトウェア構成
図２１は、本発明の第２の実施形態に係るソフトウェア更新装置（ゲートウェイ）１０Ａの機能構成例を示すブロック図である。第２の実施形態では、第１の実施形態におけるゲートウェイ１０に替えて、ゲートウェイ１０Ａが用いられる。なお、図２１において、図６と同一の番号が付された構成要素については、その説明を省略する。
図２１は、本発明の第２の実施形態に係るソフトウェア更新装置（ゲートウェイ）１０Ａの機能構成例を示すブロック図である。第２の実施形態では、第１の実施形態におけるゲートウェイ１０に替えて、ゲートウェイ１０Ａが用いられる。なお、図２１において、図６と同一の番号が付された構成要素については、その説明を省略する。
【0159】
図２１に示すように、ゲートウェイ（ソフトウェア更新装置）１０Ａは、第３更新制御部３４０、第４更新制御部３５０、及び通信部１６０を備えて構成される。
【0160】
第３更新制御部３４０は、第２ＰＦを基本としたＥＣＵのソフトウェア更新制御を実施する。第３更新制御部３４０は、第３シーケンス制御部３４１、第３機器情報管理部３４３、サーバ接続部１１０、ＨＭＩ制御部１２０、車両状態管理部１３０、及び第Ｎシーケンス制御部３４４から構成される。第Ｎシーケンス制御部３４４は、図６に第２シーケンス制御部を例示した第Ｎシーケンス制御部１５４と同様に、プラットフォームごとに当該プラットフォームにおけるソフトウェア更新のシーケンスを制御する。すなわち、本実施形態の第Ｎシーケンス制御部３４４には、第１ＰＦの更新シーケンスを制御する制御部が含まれる。
【0161】
第３シーケンス制御部３４１は、ソフトウェア更新のシーケンス全体を制御する。第３シーケンス制御部３４１は、第Ｎシーケンス制御部３４４を介して、車両２のシステム内に存在する第２ＰＦのＥＣＵ及び第１ＰＦのソフトウェア更新を全体的に制御する。第３シーケンス制御部３４１は、第１ＰＦのソフトウェアを更新する際は、第１ＰＦにて定義されたインタフェース仕様に従って第４更新制御部３５０に制御指示を行い、ソフトウェア更新を制御する。第３機器情報管理部３４３は、図６に示した機器情報管理部１４３と同様、車両２内のソフトウェア情報を収集して、車両２の構成情報を管理する。
【0162】
第４更新制御部３５０は、第３更新制御部３４０の指示により、第１ＰＦのソフトウェア更新制御を実施する。第４更新制御部３５０は、第４シーケンス制御部３５１、依存関係管理部１４２、及び機器情報管理部１４３から構成される。第４シーケンス制御部３５１は、第１ＰＦにおけるソフトウェア更新のシーケンスを制御する。
【0163】
以上のようにゲートウェイ１０Ａを構成することで、第２の実施形態では、第２ＰＦの更新制御機能に、第１ＰＦ用の第Ｎシーケンス制御部３４４を追加すれば、第１ＰＦのソフトウェア更新を行うことが可能になる。
【0164】
（２－２）処理
以下では、第２の実施形態に係るソフトウェア更新システムで実行される各種の動作または処理について、第１の実施形態と相違する部分を中心に、詳しく説明する。
（２－２－１）起動時動作
図２２は、第２の実施形態における車両２におけるシステム起動時動作の手順例を示すシーケンス図である。車両２におけるシステムは、例えば車両２の電源ＯＮ等を契機として起動し、このときゲートウェイ（ソフトウェア更新装置）１０Ａは、図２２に示す起動時動作を開始する。
以下では、第２の実施形態に係るソフトウェア更新システムで実行される各種の動作または処理について、第１の実施形態と相違する部分を中心に、詳しく説明する。
（２－２－１）起動時動作
図２２は、第２の実施形態における車両２におけるシステム起動時動作の手順例を示すシーケンス図である。車両２におけるシステムは、例えば車両２の電源ＯＮ等を契機として起動し、このときゲートウェイ（ソフトウェア更新装置）１０Ａは、図２２に示す起動時動作を開始する。
【0165】
図２２によればまず、第４更新制御部３５０の第４シーケンス制御部３５１が、通信部１６０のサービス管理部１６１に対して、車両２のシステム内に存在するサービスの検索を要求する更新対象検索要求を送信する（ステップＳ１１０１）。
【0166】
そして、ステップＳ１１０１の更新対象検索要求を受信したサービス管理部１６１は、第１通信部１６３を介してシステム内に探索要求を発行し、その探索結果の通知を受け取る（ステップＳ１１０２～Ｓ１１０５）。より具体的には、第１通信部１６３から受けた探索要求に応じて、各ＥＣＵのソフトウェアが、自身のサービスの存在を示すサービス通知を発行する。図２２のステップＳ１１０２～Ｓ１１０７による探索要求・サービスの登録の動作については、図１３のステップＳ１０２～Ｓ１０７と同様のため説明を省略する。
【0167】
次に、第４シーケンス制御部３５１は、自らをサービスとしてサービス管理部１６１に登録する（ステップＳ１１０９、第４シーケンス制御登録）。
【0168】
また、上記処理と並行して、第３シーケンス制御部３４１は、第Ｎシーケンス制御部３４４に第１ＰＦ更新準備要求を行う（ステップＳ１１１０）。前記要求を受信すると、第Ｎシーケンス制御部３４４は、サービス管理部１６１に第４シーケンス制御部探索要求を出してアクセス情報を取得し（ステップＳ１１１１）、当該情報に基づいて第４シーケンス制御部３５１に車両状態確認（ステップＳ１１１２）及びユーザＩＦ確認（ステップＳ１１１３）を要求する。これらの要求を発行することによって第Ｎシーケンス制御部３４４は、第４シーケンス制御部３５１に、車両状態確認が必要な場合には車両状態要求通知の発行先を、ユーザ確認が必要な場合にはユーザ確認要求通知の発行先を通知する。これにより、第４シーケンス制御部３５１は、適切な通知先に対して、車両状態要求通知及びユーザ確認要求通知を発行することができる。
【0169】
以上のように、図２２に示した起動時動作が行われることにより、ゲートウェイ１０Ａでは、車両２のシステム起動時にシステム内に存在するサービスを、サービス管理部１６１の管理情報に登録することができ、第Ｎシーケンス制御部３４４は第４シーケンス制御部３５１のアクセス情報を取得してアクセスが可能になり、第４シーケンス制御部３５１は車両状態要求通知及びユーザ確認要求通知の発行先を把握することが可能になる。なお、第１ＰＦ更新準備は、起動時ではなく、更新が必要になったときに実施してもよい。
【0170】
（２－２－２）構成情報の収集～車両パッケージの受信
図２３は、第２の実施形態における構成情報の収集から車両パッケージの受信に関する手順例を示すシーケンス図である。より詳しくは、図２３では、第３シーケンス制御部３４１が、システム内のソフトウェア情報を収集し、サーバ接続部１１０が構成情報として配信サーバ３に送信して同期をとり、第３シーケンス制御部３４１が配信サーバ３から提供されるキャンペーン情報に基づいてダウンロードすべき車両パッケージ（配信パッケージやソフトウェアパッケージ）の一覧を決定し、各車両パッケージを受信する処理の手順例が示されている。
図２３は、第２の実施形態における構成情報の収集から車両パッケージの受信に関する手順例を示すシーケンス図である。より詳しくは、図２３では、第３シーケンス制御部３４１が、システム内のソフトウェア情報を収集し、サーバ接続部１１０が構成情報として配信サーバ３に送信して同期をとり、第３シーケンス制御部３４１が配信サーバ３から提供されるキャンペーン情報に基づいてダウンロードすべき車両パッケージ（配信パッケージやソフトウェアパッケージ）の一覧を決定し、各車両パッケージを受信する処理の手順例が示されている。
【0171】
図２３によればまず、第３シーケンス制御部３４１が、第Ｎシーケンス制御部３４４にＳＷ情報の取得を要求する（ステップＳ１２０１）。第Ｎシーケンス制御部３４４は、前記要求を受けると第２通信部１６４を介してＥＣＵ＿Ｃ１７のＳＷ情報を取得する（ステップＳ３１１２～Ｓ３１３２）。次に、第Ｎシーケンス制御部３４４は、第４シーケンス制御部３５１に、第２ＰＦのＳＷ情報取得を要求する（ステップＳ１２０５）。前記要求を受けると第４シーケンス制御部３５１は、ＥＣＵ＿Ａ１３のＳＷ情報を取得する（ステップＳ３０３～Ｓ３０８）。図２３では、ＥＣＵ＿Ｂ１６のＳＷ情報取得の図示は省略する。第１ＰＦのＥＣＵのＳＷ情報の収集が完了すると、第４シーケンス制御部３５１は、第Ｎシーケンス制御部３４４に収集したＳＷ情報を送信する（ステップＳ１２１２）。
【0172】
そして、第Ｎシーケンス制御部３４４を介しての車両２のＳＷ情報の収集が完了する（ステップＳ１２１３）と、第３シーケンス制御部３４１は、サーバ接続部１１０にサーバへのＳＷ情報の通知を要求し（ステップＳ１２１４）、サーバ接続部１１０は受信したこれらのソフトウェア情報を構成情報として配信サーバ３に通知する（ステップＳ３１８）。
【0173】
次に、配信サーバ３は、ステップＳ３１８で受信した構成情報を基に、アップデート可能なソフトウェアの有無を確認し、アップデート（車両２からみるとダウンロード）可能なソフトウェアが存在する場合には、その更新を行うためのキャンペーン情報をサーバ接続部１１０に応答する（ステップＳ３１９）。
【0174】
次に、サーバ接続部１１０は、サーバの応答結果をキャンペーン情報を第３シーケンス制御部３４１に通知する（ステップＳ１２１５）。第３シーケンス制御部３４１がダウンロードすべき更新パッケージの一覧を読み出す詳細な方法については説明を省略するが、例えば、第３シーケンス制御部３４１は、例えばＨＭＩ制御部１２０によってキャンペーンの一覧をＨＭＩに表示させて、ユーザからダウンロードしたい車両パッケージ（更新パッケージ）を選択させるようにしてもよい。そして、第３シーケンス制御部３４１は、第１パッケージ取得要求をサーバ接続部１１０に通知する（ステップＳ１２１６）。
【0175】
次に、サーバ接続部１１０は、第１パッケージの提供を配信サーバ３に要求する（ステップＳ１２０６）。配信サーバ３から更新パッケージを受信（ステップＳ１２０７）したサーバ接続部１１０は、前記受信したパッケージを一旦蓄積し、取得が完了した旨を第３シーケンス制御部３４１に通知する（ステップＳ１２１７）。
【0176】
そして、第３シーケンス制御部３４１は、第Ｎシーケンス制御部３４４を介して第４シーケンス制御部３５１に、更新パッケージ（第１パッケージ）の転送開始を要求し（ステップＳ１２１８）、第Ｎシーケンス制御部３４４は、第４シーケンス制御部３５１に第１パッケージを転送する（ステップＳ３２４～Ｓ３２５）。そして、第Ｎシーケンス制御部３４４は、第１パッケージの転送が終了すると、第３シーケンス制御部３４１に第１パッケージの転送完了を通知する（ステップＳ１２１９）。
【0177】
以上のステップＳ１２０１～Ｓ１２１９の処理によって、第３シーケンス制御部３４１は、システム内の更新可能なソフトウェアに関する情報（キャンペーン情報）を取得し、キャンペーンから選択した任意の車両パッケージ（更新パッケージ）を配信サーバ３からダウンロードすることができる。
【0178】
（２－２－３）インストール
図２４は、第２の実施形態におけるＥＣＵを更新するソフトウェアパッケージのインストール手順例を示すシーケンス図である。図２４に示す処理の前提として、図２３に示した処理によって第４シーケンス制御部３５１が配信サーバ３から取得したキャンペーン情報に第２のＰＦのソフトウェアを更新するための情報が含まれ、ダウンロードした更新パッケージには、第１ＰＦのソフトウェアを更新するための情報が含まれていると想定する。そして、図２４では、各ＥＣＵを更新するソフトウェアパッケージ（ＳＰ１～ＳＰ３）を配信サーバ３からダウンロードし、各ＥＣＵにインストール（データ転送）する処理の手順例を示す。なお、詳細は省略するが、第１の実施形態と同様、ＥＣＵへのデータ転送のタイミングはアクティベート実行の許諾を得た後でも可能である。また、インストール可否確認のための車両状態の確認も本図では省略する。
図２４は、第２の実施形態におけるＥＣＵを更新するソフトウェアパッケージのインストール手順例を示すシーケンス図である。図２４に示す処理の前提として、図２３に示した処理によって第４シーケンス制御部３５１が配信サーバ３から取得したキャンペーン情報に第２のＰＦのソフトウェアを更新するための情報が含まれ、ダウンロードした更新パッケージには、第１ＰＦのソフトウェアを更新するための情報が含まれていると想定する。そして、図２４では、各ＥＣＵを更新するソフトウェアパッケージ（ＳＰ１～ＳＰ３）を配信サーバ３からダウンロードし、各ＥＣＵにインストール（データ転送）する処理の手順例を示す。なお、詳細は省略するが、第１の実施形態と同様、ＥＣＵへのデータ転送のタイミングはアクティベート実行の許諾を得た後でも可能である。また、インストール可否確認のための車両状態の確認も本図では省略する。
【0179】
図２４において、第３シーケンス制御部３４１は、車両状態管理部１３０が取得する車両状態に基づきインストール処理を開始して良いか否かを判定する（不図示）したのち、インストール処理を開始して良いと判定した場合に、以下に説明するＥＣＵ更新用のソフトウェアパッケージ（ＳＰ）のダウンロードを開始する。
【0180】
なお、ＥＣＵ更新用のソフトウェアパッケージをダウンロードする処理手順は、対象のＥＣＵが第１ＰＦ上のＥＣＵであるか否かによって異なる。すなわち、図２４では、ＥＣＵ＿Ａ１３用のＥＣＵパッケージ（ＳＰ１）をダウンロードする場合と、ＥＣＵ＿Ｃ１７用のＥＣＵパッケージ（ＳＰ２）またはＥＣＵ＿Ｄ１９用のＥＣＵパッケージ（ＳＰ２）をダウンロードする場合とで、処理手順が異なる。
【0181】
ＥＣＵ＿Ａ１３用のＥＣＵパッケージ（ＳＰ１）をダウンロードする処理では、まず、第３シーケンス制御部３４１が、サーバ接続部１１０にＳＰ１の取得を要求する（ステップＳ１３０１）。当該要求を受けたサーバ接続部１１０は、配信サーバ３にＳＰ１の取得を要求することで、配信サーバ３からＳＰ１を受信する（ステップＳ４０４～Ｓ４０５）。
【0182】
次に、サーバ接続部１１０は、ＳＰ１のデータ転送の開始を応答する（ステップＳ１３０１１）。データ転送開始の応答を受信すると、第３シーケンス制御部３４１は、第Ｎシーケンス制御部３４４を介して第４シーケンス制御部３５１にデータ転送開始を要求する（ステップＳ１３０２）。具体的には、第Ｎシーケンス制御部３４４から第４シーケンス制御部３５１にＳＰ１の転送開始が通知され、第４シーケンス制御部３５１が、通信Ｉ／Ｆ１６２及び第１通信部１６３を介して、第１ＰＦ上のＥＣＵ＿Ａ１３の更新管理部に転送開始を通知する（ステップＳ４０６～Ｓ４０９）。そしてこの転送開始の通知に対する応答が、ＥＣＵ＿Ａ１３から第１通信部１６３、通信Ｉ／Ｆ１６２、第１シーケンス制御部１４１を経由してサーバ接続部１１０に送信される（ステップＳ４１０～Ｓ４１３）。
【0183】
次に、第Ｎシーケンス制御部３４４は、ＳＰ１のデータをＥＣＵ＿Ａ１３に転送する。具体的には、第Ｎシーケンス制御部３４４から第４シーケンス制御部３５１にＳＰ１が送信され、第４シーケンス制御部３５１が、通信Ｉ／Ｆ１６２及び第１通信部１６３を介して、第１ＰＦ上のＥＣＵ＿Ａ１３の更新管理部にＳＰ１を転送する（ステップＳ４１４～Ｓ４１７）。そしてこのデータ転送に対する応答が、ＥＣＵ＿Ａ１３から第１通信部１６３、通信Ｉ／Ｆ１６２、第４シーケンス制御部３５１を経由してサーバ接続部１１０に送信される（ステップＳ４１８～Ｓ４２１）。
【0184】
そして、ＳＰ１のデータ転送が終了すると、第Ｎシーケンス制御部３４４は、ＳＰ１のデータ転送の終了を通知する。当該通知は、データ転送開始の通知の場合と同様に、第４シーケンス制御部３５１、通信Ｉ／Ｆ１６２、第１通信部１６３を経てＥＣＵ＿Ａ１３の更新管理部に転送され（ステップＳ４２２～Ｓ４２５）、その応答がサーバ接続部１１０に送信される（ステップＳ４２６～Ｓ４２９）。
【0185】
以上のようにして、ゲートウェイ１０Ａは、第３シーケンス制御部３４１と第Ｎシーケンス制御部３４４を介して、配信サーバ３からのソフトウェアパッケージ（この場合はＳＰ１）を直接、ＥＣＵ＿Ａに送信することができ、ＥＣＵ＿Ａ１３の更新管理部は、受信したＳＰ１をインストールすることができる。
【0186】
一方、第２ＰＦのＥＣＵ用のＥＣＵパッケージのダウンロードにおいては、ダウンロードしたソフトウェアパッケージは、即座に対象のＥＣＵに転送されるのではなく、一旦、ゲートウェイ１０Ａ内（第３シーケンス制御部３４１）に蓄積される。このような処理手順の一例として、以下、ＥＣＵ＿Ｃ１７用のＥＣＵパッケージ（ＳＰ２）をダウンロードする処理手順を説明する。
【0187】
ＥＣＵ＿Ｃ１７用のＥＣＵパッケージ（ＳＰ２）をダウンロードする処理では、まず、第３シーケンス制御部３４１が、サーバ接続部１１０にＳＰ２の取得を要求する（ステップＳ１３０４）。当該要求を受けたサーバ接続部１１０は、配信サーバ３にＳＰ１の取得を要求することで、配信サーバ３からＳＰ１を受信し（ステップＳ４３２～Ｓ４３３）、ＳＰ２の蓄積が完了すると第３シーケンス制御部３４１にその旨を通知する（ステップＳ１３０５）。
次に、第３シーケンス制御部３４１は、ＳＰ２のデータ転送の開始を通知する。具体的には、第３シーケンス制御部３４１から第Ｎシーケンス制御部３４４にＳＰ２の転送開始が通知され、第Ｎシーケンス制御部３４４が、第２通信部１６４を介して、ＥＣＵ＿Ｃ１７に転送開始を通知する（ステップＳ５０５～Ｓ５０８）。次に、第Ｎシーケンス制御部３４４は、データ転送の処理として、ＳＰ２をＥＣＵ＿Ｃ１７に送信する（ステップＳ５０９～Ｓ５１２）。そして、ＳＰ２のデータ転送が終了すると、第Ｎシーケンス制御部３４４は、ＳＰ２のデータ転送の終了をＥＣＵ＿Ｃ１７に通知する（ステップＳ５１３～Ｓ５１６）。
次に、第３シーケンス制御部３４１は、ＳＰ２のデータ転送の開始を通知する。具体的には、第３シーケンス制御部３４１から第Ｎシーケンス制御部３４４にＳＰ２の転送開始が通知され、第Ｎシーケンス制御部３４４が、第２通信部１６４を介して、ＥＣＵ＿Ｃ１７に転送開始を通知する（ステップＳ５０５～Ｓ５０８）。次に、第Ｎシーケンス制御部３４４は、データ転送の処理として、ＳＰ２をＥＣＵ＿Ｃ１７に送信する（ステップＳ５０９～Ｓ５１２）。そして、ＳＰ２のデータ転送が終了すると、第Ｎシーケンス制御部３４４は、ＳＰ２のデータ転送の終了をＥＣＵ＿Ｃ１７に通知する（ステップＳ５１３～Ｓ５１６）。
【0188】
以上のようにして、ゲートウェイ１０Ａは、第２ＰＦの第３シーケンス制御部３４１によって、配信サーバ３からのソフトウェアパッケージのダウンロード及びインストールを制御することができる。
【0189】
（２－２－４）アクティベート
図２５は、第２の実施形態におけるＥＣＵを更新するソフトウェアパッケージのアクティベート手順例を示すシーケンス図である。
図２５は、第２の実施形態におけるＥＣＵを更新するソフトウェアパッケージのアクティベート手順例を示すシーケンス図である。
【0190】
図２５によればまず、第４シーケンス制御部３５１が、インストールした更新パッケージのアクティベートを確認するタイミングを把握するために、第Ｎシーケンス制御部３４４と第３シーケンス制御部３４１を介して車両状態管理部１３０に、アクティベート可能な状態となったら通知を行うよう、車両状態の通知要求を送信する（ステップＳ１４０１～Ｓ１４０３）。
【0191】
アクティベートの確認の契機として、例えばイグニッションがＯＦＦ（ＩＧ－ＯＦＦ）になったとき、車両状態管理部１３０は、車両状態がアクティベート可能な状態になったことを第３シーケンス制御部３４１及び第Ｎシーケンス制御部３４４を介して第４シーケンス制御部３５１に通知する（ステップＳ１４０４～１４０６）。
【0192】
当該通知を受けた第４シーケンス制御部３５１は、第Ｎシーケンス制御部３４４と第３シーケンス制御部３４１を介してＨＭＩ制御部１２０に、ドライバにアクティベート実行の可否を確認する確認画面の表示を要求する（ステップＳ１４０７～Ｓ１４１０）。確認画面においてドライバからアクティベート実行の許諾を得ると、ＨＭＩ制御部１２０が、第３シーケンス制御部３４１に確認結果を通知する（ステップＳ１４１１）。第３シーケンス制御部３４１は、結果を受信すると、第Ｎシーケンス制御部３４４にアクティベートの実行を要求する（ステップＳ１４１３）。確認画面の表示形態は特に限定しないが、例えば、アクティベート待ちのソフトウェアパッケージの一覧を表示してドライバが許諾対象を選択できるようにしてもよいし、ドライバがアクティベートを一括して許諾できるようにしてもよい。また、更新ソフトウェアの種別によっては、ドライバによるアクティベートの許諾を不要とするものがあってもよい。
【0193】
アクティベート要求を受信すると、第Ｎシーケンス制御部３４４は、最初に、第４シーケンス制御部３５１に対してユーザ確認結果通知及びアクティベート開始を要求し、第４シーケンス制御部３５１は、通信ＩＦ１６２を介してＥＣＵ＿Ａ１３にアクティベートを要求する（ステップＳ５４３～Ｓ５４８）。次に、第Ｎシーケンス制御部３４４は、第２通信部１６４を介してＥＣＵ＿Ｃ１７にアクティベートを要求する（ステップＳ５５２～Ｓ５５７）。
【0194】
そして、それぞれのＥＣＵにおいて更新対象ＥＣＵのアクティベートが完了すると、第Ｎシーケンス制御部３４４は、第３シーケンス制御部３４１にその結果を通知する（ステップＳ１４１４）。
【0195】
その後、第３シーケンス制御部３４１は、第Ｎシーケンス制御部３４４に終了処理を要求し（ステップＳ１４１５）、第Ｎシーケンス制御部３４４は、通信ＩＦ１６２を介してＥＣＵ＿Ａ１３に終了処理を要求する（ステップＳ６０２～Ｓ６０５）。そして、更新対象ＥＣＵの終了処理が完了すると、第Ｎシーケンス制御部３４４は、第３シーケンス制御部３４１にその結果を通知し（ステップＳ１４１６）、アクティベート処理が終了する。
【0196】
以上のようにして、ゲートウェイ１０Ａは、第２ＰＦの第３シーケンス制御部３４１によって、更新対象のＥＣＵにインストール済みのソフトウェアパッケージのアクティベートを制御することができる。
【0197】
以上に説明したように、第２の実施形態に係るソフトウェア更新装置１０Ａによれば、第２ＰＦの更新機能が第１ＰＦの更新制御機能を制御して複数のＰＦのソフトウェア更新を実現することができる。したがって、車両システムが複数種類のプラットフォームで構成される場合でも、各プラットフォーム上のソフトウェアユニット（ＥＣＵ）やＥＣＵ内のソフトウェアを、第２プラットフォーム上で管理及び制御することができる。すなわち、第２の実施形態に係るソフトウェア更新装置１０Ａは、第１の実施形態に係るソフトウェア更新装置１０と同様に、複数のプラットフォームで構成される車両システムのソフトウェアを柔軟に更新することができる。
【0198】
なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【0199】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【0200】
また、図面において制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【0201】
１ ソフトウェア更新システム
２ 車両
３ 配信サーバ
４（４Ａ，４Ｂ，４Ｘ） ソフトウェア管理システム
５ ネットワーク
６ 診断装置
１０，１０Ａ ゲートウェイ（ソフトウェア更新装置）
１１ 車内ネットワーク
１２ 通信モジュール
１３ 運転支援統合ＥＣＵ（ＥＣＵ＿Ａ）
１４ カメラＥＣＵ
１５ センサＥＣＵ
１６ シャシー統合ＥＣＵ（ＥＣＵ＿Ｂ）
１７ エンジン制御ＥＣＵ（ＥＣＵ＿Ｃ）
１８ トランスミッション制御ＥＣＵ
１９ エアバッグＥＣＵ（ＥＣＵ＿Ｄ）
２０ ＨＶＡＣＥＣＵ
２１ 車体管理ＥＣＵ
２２ ＩＶＩ（ＥＣＵ＿Ｅ）
３１ 配信パッケージ生成部
３２ 配信パッケージ管理部
３３ 配信部
４１ ソフトウェアパッケージ生成部
４２ ソフトウェアパッケージ管理部
５０ スイッチ
５１，６１ ＳｏＣ
５２，６２，８１，９１ マイコン
５３，６３ 不揮発メモリ
５４，５８，６８，８４，９４ ＲＯＭ
５５，５６，６５，６６，８２，９２ ＣＰＵ
５７，６４，６７，８３，９３ ＲＡＭ
５９，６９，８５，９５ 通信制御部
７０，８６ 第１バンク
７１，８７ 第２バンク
１１０ サーバ接続部
１２０ ＨＭＩ制御部
１３０ 車両状態管理部
１４０ 第１更新制御部
１４１ 第１シーケンス制御部
１４２ 依存関係管理部
１４３ 機器情報管理部
１５０ 第２更新制御部
１５１ 疑似更新実行部
１５２ 依存関係管理部
１５３ 変換情報管理部
１５４ 第Ｎシーケンス制御部（第２シーケンス制御部）
１５５ 疑似ＥＣＵ管理部
１５６ インタフェース管理部
１６０ 通信部
１６１ サービス管理部
１６２ 通信Ｉ／Ｆ
１６３ 第１通信部
１６４ 第２通信部
１６５ 第３通信部
１７０ ＦｕｎｃＡ
１７１ 第１ＡＰＰ
１７２ 第２ＰＦ＿ＭＷ
１７３ ＲＴＯＳ
１８０ ＦｕｎｃＢ
１８１ 第３ＡＰＰ
１８２ 第４ＡＰＰ
１８３ 第１ＰＦ＿ＭＷ
１８４ ＰＯＳＩＸ＿ＯＳ１８４
１８５，１８６ 第１ＰＦ＿ＳＷ
１９０ ハイパーバイザ
２１０ 疑似ＥＣＵ対応管理テーブル
２２０ インタフェース変換テーブル
２３０，２４０ ソフトウェアパッケージ
２５０ 配信パッケージ
３４０ 第３更新制御部
３４１ 第３シーケンス制御部
３４３ 第３機器情報管理部
３４４ 第Ｎシーケンス制御部
３５０ 第４更新制御部
３５１ 第４シーケンス制御部
２ 車両
３ 配信サーバ
４（４Ａ，４Ｂ，４Ｘ） ソフトウェア管理システム
５ ネットワーク
６ 診断装置
１０，１０Ａ ゲートウェイ（ソフトウェア更新装置）
１１ 車内ネットワーク
１２ 通信モジュール
１３ 運転支援統合ＥＣＵ（ＥＣＵ＿Ａ）
１４ カメラＥＣＵ
１５ センサＥＣＵ
１６ シャシー統合ＥＣＵ（ＥＣＵ＿Ｂ）
１７ エンジン制御ＥＣＵ（ＥＣＵ＿Ｃ）
１８ トランスミッション制御ＥＣＵ
１９ エアバッグＥＣＵ（ＥＣＵ＿Ｄ）
２０ ＨＶＡＣＥＣＵ
２１ 車体管理ＥＣＵ
２２ ＩＶＩ（ＥＣＵ＿Ｅ）
３１ 配信パッケージ生成部
３２ 配信パッケージ管理部
３３ 配信部
４１ ソフトウェアパッケージ生成部
４２ ソフトウェアパッケージ管理部
５０ スイッチ
５１，６１ ＳｏＣ
５２，６２，８１，９１ マイコン
５３，６３ 不揮発メモリ
５４，５８，６８，８４，９４ ＲＯＭ
５５，５６，６５，６６，８２，９２ ＣＰＵ
５７，６４，６７，８３，９３ ＲＡＭ
５９，６９，８５，９５ 通信制御部
７０，８６ 第１バンク
７１，８７ 第２バンク
１１０ サーバ接続部
１２０ ＨＭＩ制御部
１３０ 車両状態管理部
１４０ 第１更新制御部
１４１ 第１シーケンス制御部
１４２ 依存関係管理部
１４３ 機器情報管理部
１５０ 第２更新制御部
１５１ 疑似更新実行部
１５２ 依存関係管理部
１５３ 変換情報管理部
１５４ 第Ｎシーケンス制御部（第２シーケンス制御部）
１５５ 疑似ＥＣＵ管理部
１５６ インタフェース管理部
１６０ 通信部
１６１ サービス管理部
１６２ 通信Ｉ／Ｆ
１６３ 第１通信部
１６４ 第２通信部
１６５ 第３通信部
１７０ ＦｕｎｃＡ
１７１ 第１ＡＰＰ
１７２ 第２ＰＦ＿ＭＷ
１７３ ＲＴＯＳ
１８０ ＦｕｎｃＢ
１８１ 第３ＡＰＰ
１８２ 第４ＡＰＰ
１８３ 第１ＰＦ＿ＭＷ
１８４ ＰＯＳＩＸ＿ＯＳ１８４
１８５，１８６ 第１ＰＦ＿ＳＷ
１９０ ハイパーバイザ
２１０ 疑似ＥＣＵ対応管理テーブル
２２０ インタフェース変換テーブル
２３０，２４０ ソフトウェアパッケージ
２５０ 配信パッケージ
３４０ 第３更新制御部
３４１ 第３シーケンス制御部
３４３ 第３機器情報管理部
３４４ 第Ｎシーケンス制御部
３５０ 第４更新制御部
３５１ 第４シーケンス制御部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】