JP2022133732A - センター装置及び車載電子制御装置 - Google Patents

Abstract

【課題】異なるタイプの電子制御装置が混在しているか否かに関わらず、全ての更新データを１つのパッケージで配信することができるセンター装置を提供する【解決手段】センター装置３の個車情報ＤＢ４１には複数のＥＣＵそれぞれに対する装置の識別及び当該装置のソフトウェアアーキテクチャに関する情報が車両の種別と共に記憶されている。ＰＫＧ構造ＤＢ４４には複数のＥＣＵそれぞれにつきデータを更新するために配信するパッケージの構造に関する情報が各ＥＣＵのタイプに応じて記憶されている。判断部３２は、個車情報ＤＢ４１及びＰＫＧ構造ＤＢ４４に記憶されている情報に基づき複数のＥＣＵのうちデータを更新する対象となる対象装置が搭載されている対象車両について配信するパッケージを特定し、ＰＫＧ生成部３３は特定されたパッケージについての前記構造を示す情報を含むパッケージを生成する。【選択図】図２

Description

本発明は、車両に搭載される複数の電子制御装置に書込むデータを管理するセンター装置，及び前記センター装置と通信を行う車載電子制御装置に関する。

近年、運転支援機能や自動運転機能等の車両制御の多様化に伴い、車両の電子制御装置（以下、ＥＣＵ（Electronic Control Unit）と称する）に搭載される車両制御や診断等のアプリプログラムの規模が増大している。また、機能改善等によるバージョンアップに伴い、ＥＣＵのアプリプログラムを書換える，所謂リプログを行う機会も増えつつある。一方、通信ネットワークの進展等に伴い、コネクッテッドカーの技術も普及している。このような事情から、例えば特許文献１には、サーバよりＥＣＵの更新プログラムをＯＴＡ（Over The Air）により車載装置に配信し、車両側で更新プログラムを書換える技術が開示されている。

特開２０２０－２７６２４号公報

上記の更新プログラムを書換える方式には、センター装置から更新プログラムの全てを車両側のメモリにダウンロードしてから更新を行うストレージ方式と、センター装置から更新プログラムを車両側にダウンロードしながら更新を行うストリーミング方式とがある。また、図１４に示すように、ＥＣＵのプラットフォームに応じた更新プログラムを配信するためのパッケージ構造について、一般社団法人ＪＡＳＰＡＲ（Japan Automotive Software Platform and Architecture）の仕様では、標準化団体ＡＵＴＯＳＡＲ (AUTomotive Open System ARchitecture)の静的ＯＳ（Operating System）で動作するクラシックプラットフォーム（ＣＰ）に適用可能なデータ要件が規定されている。また、ＡＵＴＯＳＡＲでは、動的ＯＳで動作する新たなタイプのアダプティブプラットフォーム（ＡＰ）に適用可能なデータ要件が規定されている。

しかしながら、従来技術では、車両側に搭載されているＥＣＵについて、ストレージ方式，ストリーミング方式を採用するものが混在している場合や、ＣＰ，ＡＰタイプが混在している場合は想定されていない。そのため、センター装置がそのような車両に対して、全ての更新プログラムを１つのパッケージで配信することができない。

本発明は上記事情に鑑みてなされたものであり、その目的は、異なるタイプの電子制御装置が混在しているか否かに関わらず、車両に搭載されている更新対象となる電子制御装置について、全ての更新データを１つのパッケージで配信することができるセンター装置，及び前記パッケージを受信して更新データを書き込むことができる車載電子制御装置を提供することにある。

請求項１記載のセンター装置によれば、車両情報記憶部には、複数の電子制御装置それぞれに対する装置の識別情報，及び当該装置のソフトウェアアーキテクチャに関する情報が車両の種別と共に記憶されている。パッケージ構造記憶部には、データを更新するために配信するパッケージの構造に関する情報が、複数の電子制御装置のうち、データの更新を行うための中継を行う中継装置のソフトウェアアーキテクチャ、複数の電子制御装置のうち、データを更新する対象となる対象装置のソフトウェアアーキテクチャ、及びデータの更新時における更新方式に関する情報に応じて記憶されている

判断処理部は、車両情報記憶部及び前記パッケージ構造記憶部に記憶されている情報に基づいて、複数の電子制御装置のうちデータを更新する対象となる対象装置が搭載されている対象車両についてパッケージの構造を特定し、パッケージ生成部は、特定されたパッケージについての前記構造を示す情報を含むパッケージを生成する。

このように構成すれば、パッケージ生成部は、対象車両に配信するパッケージについて、様々な種類の電子制御装置のうちから対象装置のソフトウェアアーキテクチャに対応した構造を備えたものを生成できる。したがって、異なるタイプの電子制御装置が混在しているか否かにかかわらず、全ての更新データを１つのパッケージで配信できる。

請求項２記載のセンター装置によれば、パッケージの構造を示す情報には、電子制御装置のソフトウェアアーキテクチャに関する情報として、ＡＵＴＯＳＡＲの仕様書で規定されている電子制御装置のタイプであるアダプティブプラットフォーム（ＡＰ）又はクラシックプラットフォーム（ＣＰ）の何れかであることを示す情報と、データの更新時における更新方式に関する情報として、データの更新を行う方式がストレージ方式又はストリーミング方式の何れかであることを示す情報とを含む。このように構成すれば、上記のプラットフォームタイプ及びデータの更新方式が異なる電子制御装置が混在している車両に対して、それぞれに対応した配信パッケージを生成できる。

請求項３記載のセンター装置によれば、パッケージ生成部は、対象装置がデータの更新を行うための中継を行う中継装置のタイプがＡＰである場合は、ＵＣＭマスタが処理できる構造のパッケージを生成し、中継装置のタイプがＣＰである場合は、ＯＴＡマスタが処理できる構造のパッケージを生成する。ここで、「ＵＣＭマスタが処理できる構造のパッケージ」とは、車両内におけるパッケージの配布に必要となる情報等を含む車両パッケージであり、「ＯＴＡマスタが処理できる構造のパッケージ」とは、ＯＴＡマスタがインストールを実行する際に必要となるパラメータの情報等を含む諸元データやファイル構成情報等を含むパッケージである。したがって、ＡＵＴＯＳＡＲのＡＰやＣＰで規定されている中継装置のタイプに応じて適切な配信パッケージを生成できる。

請求項４記載のセンター装置によれば、パッケージ生成部は、対象装置のタイプがＡＰである場合はＵＣＭが処理できる構造のパッケージを生成し、ＣＰである場合はインストーラが処理できる構造のパッケージを生成する。ここで、「ＵＣＭが処理できる構造のパッケージ」とは、インストール処理の単位である更新データ等を含むソフトウェアパッケージであり、「インストーラが処理できる構造のパッケージ」とは、上記の諸元データや更新データ,ファイル構成情報等を含むパッケージである。したがって、対象装置のタイプに応じて適切な配信パッケージを生成できる。

一実施形態であり、車両側システムの構成を示す機能ブロック図 センター装置の構成を示す機能ブロック図 構成情報ＤＢに登録される情報を示す図 ＰＫＧ構造ＤＢに登録される情報を示す図 ソフトウェアパッケージ，バックエンドパッケージ及び車両パッケージを示す図 センター装置における車両モデルの登録処理及びパッケージ構造モデルの登録処理を示すフローチャート センター装置における車両構成情報の登録処理を示すフローチャート センター装置における配信パッケージの生成処理を示すフローチャート 統合パッケージを説明する図 センター装置における検証データ生成処理を示すフローチャート 車両側システムにおいてセントラルＥＣＵがＡＰである場合のリプログ処理を示すフローチャート（その１） 車両側システムにおいてセントラルＥＣＵがＣＰである場合のリプログ処理を示すフローチャート（その１） 車両側システムにおけるリプログ処理を示すフローチャート（その２） ＥＣＵのプラットフォームがＣＰ，ＡＰそれぞれのパッケージ構造を示す図 統合パッケージ構造及び統合パッケージの生成方法を例示する図

以下、一実施形態について図面を参照して説明する。車両用プログラム書換えシステムは、車両に搭載されているＥＣＵの車両制御や診断等のアプリプログラムをＯＴＡにより書換え可能なシステムである。図１に示すように、車両用プログラム書換えシステム１は、通信ネットワーク２側のセンター装置３と、車両側の車両側システム４と、表示端末５とを有する。通信ネットワーク２は、例えば４Ｇ回線等による移動体通信ネットワークやインターネットやＷｉＦｉ（Wireless Fidelity：登録商標）等を含んで構成される。

表示端末５は、ユーザからの操作入力を受付ける機能や各種画面を表示する機能を有する端末であり、例えばユーザが携帯可能なスマートフォンやタブレット等の携帯端末６、車室内に配置されているナビゲーション機能を兼用するディスプレイやメータディスプレイ等の車載ディスプレイ７である。携帯端末６は、移動体通信ネットワークの通信圏内であれば、通信ネットワーク２に接続可能である。車載ディスプレイ７は、車両側システム４に接続されている。

ユーザは、車室外であって移動体通信ネットワークの通信圏内であれば、アプリプログラムの書換えに関与する各種画面を携帯端末６で確認しながら操作入力を行い、アプリプログラムの書換えに関与する手続きを可能である。ユーザは、車室内では、アプリプログラムの書換えに関与する各種画面を車載ディスプレイ７で確認しながら操作入力を行い、アプリプログラムの書換えに関与する手続きを可能である。即ち、ユーザは、車室外と車室内で携帯端末６と車載ディスプレイ７を使い分け、アプリプログラムの書換えに関与する手続きを可能である。

センター装置３は、車両用プログラム書換えシステム１において通信ネットワーク２側のＯＴＡの機能を統括し、ＯＴＡセンターとして機能する。センター装置３は、ファイルサーバ８と、ウェブサーバ９と、管理サーバ１０とを有し、各サーバ８～１０が相互にデータ通信可能に構成されている。

ファイルサーバ８は、センター装置３から車両側システム４に送信されるアプリプログラムの管理機能を備え、アプリプログラムの提供事業者であるサプライヤ等から提供されるＥＣＵプログラム及びそれに付随する情報、ＯＥＭ（Original Equipment Manufacturer）から提供される配信諸元データ、車両側システム４から取得する車両状態等を管理するサーバである。ファイルサーバ８は、通信ネットワーク２を介して車両側システム４との間でデータ通信可能であり、配信パッケージのダウンロード要求が発生すると、リプログデータと配信諸元データをパッケージ化した配信パッケージを車両側システム４に送信する。または、配信パッケージのダウンロード要求が発生すると、配信諸元データをパッケージ化した配信パッケージと、リプログデータとを車両側システム４に送信する。ウェブサーバ９は、ウェブ情報を管理するサーバであり、携帯端末６に対し、アプリプログラムの書換えに関与する各種画面を提供する。管理サーバ１０は、アプリプログラムの書換えのサービスに登録しているユーザの個人情報等を管理し、車両毎のアプリプログラムの書換え履歴等を管理する。

車両側システム４は、マスタ装置１１を有する。マスタ装置１１は、ＤＣＭ（Data Communication Module）１２とセントラルＥＣＵ１３とを有し、ＤＣＭ１２とセントラルＥＣＵ１３が第１バス１４を介してデータ通信可能に接続されている。ＤＣＭ１２は、センター装置３との間で通信ネットワーク２を介してデータ通信を行う車載通信機であり、ファイルサーバ８から配信パッケージをダウンロードすると、その配信パッケージから書込みデータを抽出してセントラルＥＣＵ１３に転送する。または、ＤＣＭ１２は、ファイルサーバ８から配信パッケージをダウンロードすると、その配信パッケージをセントラルＥＣＵ１３に転送する。セントラルＥＣＵ１３は、配信パッケージから書込みデータを抽出する。

セントラルＥＣＵ１３は、データ中継機能を有する車両用ゲートウェイ装置であり、ＤＣＭ１２から書込みデータを取得すると、その書込みデータを、アプリプログラムを書換える書換え対象ＥＣＵに配信する。マスタ装置１１は、車両用プログラム書換えシステム１において車両側のＯＴＡの機能を統括し、ＯＴＡマスタとして機能する。尚、図１では、ＤＣＭ１２と車載ディスプレイ７が同一の第１バス１４に接続されている構成を例示しているが、ＤＣＭ１２と車載ディスプレイ７が別々のバスに接続されている構成でも良い。セントラルＥＣＵ１３は、本開示の中継装置に対応する。

セントラルＥＣＵ１３には、第１バス１４に加え、第２バス１５、第３バス１６、第４バス１７、第５バス１８が車内側のバスとして接続されており、バス１５～１７を介して各種ＥＣＵ１９が接続されていると共に、バス１８を介して電源管理ＥＣＵ２０が接続されている。

第２バス１５は、例えばボディ系ネットワークのバスである。第２バス１５に接続されているＥＣＵ１９は、例えばドアのロック／アンロックを制御するドアＥＣＵ、メータ表示を制御するメータＥＣＵ、エアコンの駆動を制御するエアコンＥＣＵ、ウィンドウの開閉を制御するウィンドウＥＣＵ等のボディ系の制御を行うＥＣＵである。第３バス１６は、例えば走行系ネットワークのバスである。第３バス１６に接続されているＥＣＵ１９は、例えばエンジンの駆動を制御するエンジンＥＣＵ、ブレーキの駆動を制御するブレーキＥＣＵ、自動変速機の駆動を制御するＥＣＴ（Electronic Controlled Transmission）ＥＣＵ、パワーステアリングの駆動を制御するパワーステアリングＥＣＵ等の走行系の制御を行うＥＣＵである。

第４バス１７は、例えばマルチメディア，いわゆるＭＭ系ネットワークのバスである。第４バス１７に接続されているＥＣＵ１９は、例えばナビゲーションシステムを制御するためのナビゲーションＥＣＵ、電子式料金収受システム，すなわちＥＴＣ（Electronic Toll Collection System：登録商標）システムを制御するＥＴＣＥＣＵ等のマルチメディア系の制御を行うＥＣＵである。バス１５～１７は、ボディ系ネットワークのバス、走行系ネットワークのバス、マルチメディア系ネットワークのバス以外の系統のバスであっても良い。また、バスの本数やＥＣＵ１９の個数は例示した構成に限らない。
電源管理ＥＣＵ２０は、ＤＣＭ１２、セントラルＥＣＵ１３、各種ＥＣＵ１９等の電源管理を行う機能を有するＥＣＵである。

セントラルＥＣＵ１３には、第６バス２１が車外側のバスとして接続されている。第６バス２１には、ツール２３が着脱可能に接続されるＤＬＣ（Data Link Coupler）コネクタ２２が接続されている。車内側のバス１４～１８及び車外側のバス２１は、例えばＣＡＮ（Controller Area Network：登録商標）バスにより構成されており、セントラルＥＣＵ１３は、ＣＡＮのデータ通信規格や診断通信規格（ＵＤＳ：ＩＳＯ１４２２９）にしたがってＤＣＭ１２、各種ＥＣＵ１９、ツール２３との間でデータ通信を行う。尚、ＤＣＭ１２とセントラルＥＣＵ１３がイーサネットにより接続されていても良いし、ＤＬＣコネクタ２２とセントラルＥＣＵ１３がイーサネットにより接続されても良い。

書換え対象ＥＣＵ１９は、セントラルＥＣＵ１３から書込みデータを受信すると、その書込みデータをフラッシュメモリに書込んでアプリプログラムを書換える。上記した構成では、セントラルＥＣＵ１３は、書換え対象ＥＣＵ１９から書込みデータの取得要求を受信すると、書込みデータを書換え対象ＥＣＵ１９に配信するリプログマスタとして機能する。書換え対象ＥＣＵ１９は、セントラルＥＣＵ１３から書込みデータを受信すると、その書込みデータをフラッシュメモリに書込んでアプリプログラムを書換えるリプログスレーブとして機能する。尚、「書換え対象ＥＣＵ」を「ターゲットＥＣＵ」と表記することがある。

アプリプログラムを書換える態様としては、有線で書換える態様と、無線で書換える態様とがある。アプリプログラムを有線で書換える態様では、ツール２３がＤＬＣコネクタ２２に接続されると、ツール２３は、書込みデータをセントラルＥＣＵ１３に転送する。セントラルＥＣＵ１３は、ツール２３から転送された書込みデータを書換え対象ＥＣＵ１９に中継又は配信する。アプリプログラムを無線で書換える態様では、上記したように、ＤＣＭ１２は、ファイルサーバ８から配信パッケージをダウンロードすると、その配信パッケージから書込みデータを抽出し、その書込みデータをセントラルＥＣＵ１３に転送する。

図２に示すように、パッケージ生成サーバでもあるセンター装置３は、制御部３０と、各データベース４１～４６とを備えている。尚、以下では「データベース」を「ＤＢ」と表記する。また、「パッケージ」を「ＰＫＧ」と表記することがある。また、「ソフトウェアパッケージ」を「ＳＷ ＰＫＧ」と表記することがある。制御部３０は、マイクロコンピュータとしてのハードウェア及びソフトウェアの機能により実現される情報記憶部３１,判断部３２,ＰＫＧ生成部３３及び検証データ生成部３４等の各機能ブロックを有している。

次に、各データベース４１～４６に登録されるデータの内容を説明する。個車情報ＤＢ４１には、主に個車毎の構成情報や、プログラム更新に対する個車のステータス情報が登録される。具体的には、各車両のＩＤである「ＶＩＮ」について、構成情報である「Ｖｅｈｉｃｌｅ ＳＷ ＩＤ」，「Ｓｙｓ ＩＤ」，「ＥＣＵ ＩＤ」，「ＥＣＵ ＳＷ ＩＤ」等である。これら構成情報についてのハッシュ値である「Ｄｉｇｅｓｔ」値も、センター装置３にて演算され、記憶される。「運用面」は、メモリ構成が２面である場合に、ＥＣＵ１９が現在運用しているプログラムが書き込まれている面であり、構成情報とともにアップロードされた値が登録される。各車両のＩＤは車両識別情報であって、ＶＩＮの代わりに車台番号でもよい。

ＥＣＵメタデータＤＢ４２には、一例として以下に示すＥＣＵ個別の諸元データが登録される。最新の「ＥＣＵ ＳＷ ＩＤ」について、更新データファイルのサイズ，ロールバックデータファイルのサイズ，ＥＣＵ１９が備えるフラッシュメモリが２面以上の構成である場合に、Ａ面，Ｂ面，Ｃ面等何れの面用のプログラムであるかを示す面情報，転送サイズ，プログラムファイルの読出し用アドレス等である。これらは更新データ関連情報の一例である。

また、ＥＣＵメタデータＤＢ４２には、ＥＣＵ１９の属性を示す属性情報も登録される。属性情報とは、ＥＣＵに関するハードウェア属性、及びソフトウェア属性を示す情報である。「転送サイズ」は、セントラルＥＣＵ１３からＥＣＵ１９へ書換えデータを分割して転送する際の転送サイズ、「鍵」は、セントラルＥＣＵ１３がＥＣＵ１９へセキュアにアクセスする際に用いる鍵である。これらは、ソフトウェア属性情報の一例である。また、「車両型式」及び「ＥＣＵ ＩＤ」について、ＥＣＵ１９が備えるフラッシュメモリ２８ｄのメモリ構成，ＥＣＵ１９が接続されているバス種別，ＥＣＵ１９に接続されている電源の種類なども含まれる。これらは、ハードウェア属性情報の一例である。
パッケージＤＢ４３には、配信パッケージのＩＤ，配信パッケージファイル及び配信パッケージの完全性検証用のデータが登録される。

図３に示すように、構成情報ＤＢ４５には、各車両モデルについて、セントラルＥＣＵ１３のプラットフォーム，ターゲットＥＣＵ１９のＩＤ，プラットフォーム及びリプログ時の更新方式が登録されている。構成情報ＤＢ４５は車両情報記憶部に相当する。以下では、プラットフォームを「ＰＦ」と表記することがある。「車両モデル」は、車種，発売年月日，グレードや仕向け地等に応じて特定される各車両のＩＤである。「車両モデル」は車両の種別に相当する。更新プログラムを配信するためのパッケージの構造には、ＡＵＴＯＳＡＲの仕様書で規定されている静的ＯＳで動作するＣＰに適用できるパッケージと、動的ＯＳで動作するＡＰに適用できるパッケージとがある。

ここで、ＡＰとＣＰとの違いについて説明する。ＡＰ及びＣＰはソフトウェアプラットフォームを表している。ソフトウェアプラットフォームは、ソフトウェアアーキテクチャとも呼ばれる。ＣＰは、AUTOSAR Classic Platformを表し、ＡＰはAUTOSAR Adaptive Platformを表す。さらに、ＣＰ仕様書に準拠して動作するＥＣＵをＣＰ ＥＣＵ又はＣＰのＥＣＵと表記し、ＡＰ仕様書に準拠して動作するＥＣＵをＡＰ ＥＣＵ又はＡＰのＥＣＵと表記することがある。

ＡＰ及びＣＰにおいては、使用されるオペレーティングシステム，いわゆるＯＳや開発言語が異なる。ＣＰ ＥＣＵとＡＰ ＥＣＵは、受信できるパッケージの構造が異なる。 これらのパッケージの構造の違いは、主にＥＣＵの処理性能の違いに起因するものであり、一般的にＣＰのＥＣＵの処理性能は低いため、パッケージに含まれる諸元データなどもバイナリデータで記載されており、処理性能の低いＥＣＵでも解釈・処理しやすいパッケージデータ構造となっている。

一方、ＡＰのＥＣＵは処理性能が高いものが用いられるため、何らかの言語で記述された構造的な文字データを解析してプログラムで扱えるデータ構造に変換するパーサー機能を搭載することが可能であり、データ構造には単純なバイナリデータではなく、例えばＪＳＯＮ（JavaScript Object Notation）のようなオブジェクト指向のデータ形式を採用できるため、柔軟なパッケージデータ構造となっている。

更新方式については、センター装置３から更新プログラムの全てを車両側のメモリにダウンロードしてから更新を行うストレージ方式と、センター装置３から更新プログラムを車両側にダウンロードしながら更新を行うストリーミング方式とがある。

図３に示す例では、車両モデルＡのセントラルＥＣＵ１３はＡＰ，ターゲットＥＣＵ１９のＩＤは「１～４」であり、それらのＰＦはＡＰ，ＣＰが混在している。更新方式については、ＩＤ１及びＩＤ２がストリーミング方式，ＩＤ３及びＩＤ４がストレージ方式である。車両モデルＢのセントラルＥＣＵ１３はＣＰ，ターゲットＥＣＵ１９のＩＤは「５～８」であり、ＰＦは同様にＡＰ，ＣＰが混在している。更新方式については、ＩＤ５及びＩＤ６がストリーミング方式，ＩＤ７及びＩＤ８がストレージ方式である。尚、上記の更新方式をＯＴＡ方式と表記することがある。

構成情報ＤＢ４５には、車両の生産又は販売時点で初期値が登録され、登録された情報は、その後何れか１つ以上のＥＣＵのアプリプログラムのバージョンが更新されるのに伴い更新される。すなわち、構成情報ＤＢ４５は、各車両型式について、市場で正規に存在する構成情報を示す。

図４に示すように、ＰＫＧ構造ＤＢ４４には、パッケージ構造として８つのタイプ；Ｎｏ.１～８が登録されている。ＰＫＧ構造ＤＢ４４は、アプリプログラムを書換える際にセンター装置３から車両側システム４に配信されるパッケージの構成、及びパッケージに含まれずに配信されるファイルを規定する。Ｎｏ.１～４はセントラルＥＣＵ１３のＰＦがＡＰであり、Ｎｏ.５～８はセントラルＥＣＵ１３のＰＦがＣＰである。Ｎｏ.１，２，５，６はターゲットＥＣＵ１９のＰＦがＡＰであり、Ｎｏ. ３，４，７，８はターゲットＥＣＵ１９のＰＦがＣＰである。Ｎｏ.１，３，５，７はＯＴＡ方式が「ストレージ」であり、Ｎｏ. ２，４，６，８はＯＴＡ方式が「ストリーミング」である。

パッケージの構成及びパッケージに含まれずに配信されるファイルは、セントラルＥＣＵ１３のＰＦ、ターゲットＥＣＵ１９のＰＦ、及びセントラルＥＣＵ１３からターゲットＥＣＵ１９へのＯＴＡ方式に基づいて決定する。セントラルＥＣＵ１３のＰＦには、上述のように、セントラルＥＣＵ１３がＡＰ ＥＣＵである場合とＣＰ ＥＣＵである場合が含まれる。また、ターゲットＥＣＵ１９のＰＦも同様に、ターゲットＥＣＵ１９がＡＰ ＥＣＵである場合とＣＰ ＥＣＵである場合とが含まれる。

セントラルＥＣＵ１３のＰＦがＡＰの場合は、セントラルＥＣＵ１３内のＵＣＭマスタが解釈できるようにVehicle PKGが含まれる。一方、セントラルＥＣＵ１３のＰＦがＣＰの場合は、セントラルＥＣＵ１３内のＯＴＡマスタが解釈できるように諸元データ、ファイル構成情報、検証データが含まれる。
また、ターゲットＥＣＵ１９のＰＦがＡＰの場合は、ターゲットＥＣＵ１９内のＵＣＭが解釈できるようにソフトウェアパッケージ（Software PKG、SW PKGとも表記）が含まれる。ターゲットＥＣＵ１９のＰＦがＣＰの場合は、インストーラが解釈できるように、諸元データ、ファイル構成情報、検証データが含まれる。なお、ＵＣＭマスタ及びＵＣＭはＡＵＴＯＳＡＲにて説明されているので詳細は省略する。また、ＯＴＡマスタ及びインストーラは、ＪＡＳＰＡＲの規格文書にて説明されているので詳細は省略する。

また、ＯＴＡ方式がストリーミングである場合は、更新データをパッケージに含めない。一方、ＯＴＡ方式がストレージである場合は、更新データをパッケージに含める。
ＰＫＧ構造ＤＢ４４は、ターゲットＥＣＵ１３毎に該ターゲットＥＣＵ１３のアプリプログラムを更新する際に必要なデータの形式，つまりパッケージの構成、及びパッケージに含まれずに配信されるファイル等を表している。

ここで、各車両に配信されるパッケージは、統合パッケージと、統合パッケージに含まれない付属ファイルとで構成される。セントラルＥＣＵ１３がＡＰであるＮｏ.１～４では、統合パッケージに図中に「Vehicle PKG」と表記している車両パッケージが含まれる。ターゲットＥＣＵ１９がＡＰであるＮｏ.１，２，５，６では、図中に「SW PKG」と表記しているソフトウェアパッケージが含まれる。但し、ＯＴＡ方式がストレージであるＮｏ.１，５では、ソフトウェアパッケージが統合パッケージに含まれるが、Ｎｏ.２，６では、統合パッケージに含まれず別ファイルとなる。統合パッケージは圧縮されたファイルとして車両システム４に配信され、付属ファイルは圧縮されずに車両システム４に配信される。

ソフトウェアパッケージは、ＥＣＵが行うインストール処理の単位であり、例えばＡＰ上で展開される１個以上のアプリの実行ファイルや、ＯＳやファームウェアの更新ファイル，コンフィグレーションデータやキャリブレーションデータなどが含まれる。パッケージ毎に、パッケージ名やバージョン情報，従属関係，パッケージ処理に必要なベンダ固有の情報等であるメタデータを供給するマニフェスト情報が含まれている。ターゲットＥＣＵ１９に搭載されるソフトウェアモジュールであるＵＣＭ（Update Configuration Management）は、メタデータに基づいてベンダ固有のソフトウェアパッケージを処理する。尚、図中に示す「SW PKG A,B」は、一例として２つのパッケージを示しており、１つのパッケージであっても良いし、３つ以上のパッケージを含むこともある。

図５に示すように、ソフトウェアパッケージは、様々なサプライヤによってＯＥＭに供給される。ＯＥＭサーバにおいては、各パッケージに対応してバックエンドパッケージが生成される。バックエンドパッケージはソフトウェアパッケージを包含するが、マニフェスト情報には、パッケージの配布先となるＵＣＭのダイアグアドレスやＩＤ等の情報が追加される。そして、複数のバックエンドパッケージから、車両パッケージが生成される。各車両に必要な複数のソフトウェアパッケージが統合されるが、車両パッケージには、各ソフトウェアパッケージのマニフェストに、車両パッケージマニフェストが加えられる。

車両パッケージマニフェストには、データ更新の用意がある旨の通知として車両に配信されるキャンペーンの統制や配布に必要な情報，例えば従属関係やターゲット車両，安全ポリシーやドライバ通知設定等の情報が含まれる。セントラルＥＣＵ１３に搭載されるソフトウェアモジュールであるＵＣＭマスタは、車両パッケージを解釈することでデータの更新内容を把握すると、どのソフトウェアパッケージをどのＵＣＭに、どのような順序で転送するかを制御する。そして、ＵＣＭは、ＵＣＭマスタから渡されるソフトウェアパッケージを解釈して、ターゲットＥＣＵ１９のインストール処理を実行する。

尚、図５に示す図面は、“Specification of Update Configuration Management AUTOSAR AP R20-11,Document ID No.706”のp50,52，53に掲載されているものを引用している。また、図１４に示すＡＰ用のパッケージ構造の図についても同様である。

図４において、ターゲットＥＣＵ１９がＣＰであるＮｏ. ３，４，７，８では、統合パッケージに諸元データやファイル構成情報，必要に応じて各種の検証データ等が含まれる。また、更新データと更新前データとの差分である差分データは、ＯＴＡ方式がストレージであるＮｏ.３，７では統合パッケージに含まれるが、ＯＴＡ方式がストリーミングであるＮｏ.４，８では統合パッケージに含まれず別ファイルとなる。

ファイル構成情報（ＤＣＭ諸元）は、ファイル名（FILE）とその役割（TYPE）や、ターゲットＥＣＵ１９（ECU-ID）とを紐づける情報，どのデータがどのバイナリファイル名（xxxxxxxx.bin）となっているかを特定できる情報等である。車両側のＯＴＡマスタは、ファイル構成情報を解釈することで、どのバイナリファイルがどの役割（例えば諸元データ等）を果たすのかや、それをどのターゲットＥＣＵ１９に転送すれば良いか等を判断する。

ＥＣＵリプロデータＤＢ４６には、一例として以下のプログラムやデータが登録される。更新対象ＥＣＵ１９の最新の「ＥＣＵ ＳＷ ＩＤ」について、ＥＣＵの旧プログラム及び新プログラムファイル，新プログラムの完全性検証データ，新プログラムと旧プログラムとの差分データである更新データファイル，更新データの完全性検証データ，同じく差分データであるロールバックデータファイル，ロールバックデータの完全性検証データ等が登録される。完全性検証データは、データ値にハッシュ関数を適用して得られるハッシュ値である。

次に、本実施形態の作用について説明する。図６に示すように、センター装置３の情報記憶部３１は、車両モデルの登録を開始すると、新しい車両モデルに搭載されている各ＥＣＵのＰＦについて、ソフトウェアアーキテクチャに関する情報を構成情報ＤＢ４５に登録する（Ｓ１）。また、情報記憶部３１は、パッケージ構造モデルの登録を開始すると、新しいＰＦが存在する場合には、そのＰＦに対応するパッケージ構造をＰＫＧ構造ＤＢ４４に登録する（Ｓ２）。

さらに、情報記憶部３１は、図７に示すように、販売済みの車両について車両情報の収集を行った際に、その車両に新しいハードウェアデバイス，例えばＬiＤＡＲ（Light Detection And Ranging）等が追加されたことを検出すると（Ｓ３；Ｙｅｓ）、そのデバイスの情報を構成情報ＤＢ４５に登録して情報を同期させる（Ｓ４）。

図８に示すように、判断部３２は、パッケージの生成処理を開始すると、配信対象車両の情報を取得する（Ｓ１１）。配信対象車両については、個車情報ＤＢ４１と構成情報ＤＢ４５とにそれぞれ登録されている各車両の情報を比較することで得られる。例えば、図３に示す車両モデルＢについて、ＩＤ＝５,６のターゲットＥＣＵ１９についてソフトウェアに更新があるものとする。

次に、判断部３２は、構成情報ＤＢ４５を検索して、更新対象車両モデルのソフトウェアアーキテクチャを特定する（Ｓ１２）。例えば、上述の車両モデルＢであれば、ＩＤ＝５,６のターゲットＥＣＵ１９のソフトウェアアーキテクチャを、それぞれＮｏ.６，８であると特定する。続いて、ＰＫＧ構造ＤＢ４４を検索し、更新対象車両モデルについて生成すべきパッケージ構造を特定する（Ｓ１３）。それから判断部３２は、ＰＫＧ生成部３３に、構造Ｎｏ.６，８に対応するパッケージの生成を指示する。

ＰＫＧ生成部３３は、パッケージ生成の処理要求を受信すると、特定されたパッケージの構造から統合パッケージを生成する（Ｓ１４）。ここで、「統合パッケージ」及び「統合パッケージ」の構築方法について図９を参照して説明する。尚、図９の構造Ｎｏ．６，８は図４のパッケージ構造Ｎｏ．６，８に対応している。

図３に示す車両モデルＢについて、ＩＤ＝５，６のターゲットＥＣＵ１９についてソフトウェアに更新がある場合、ＩＤ＝５及びＩＤ＝６のターゲットＥＣＵ１９に対する情報は１つの統合パッケージとしてセンター装置３から車両側システム４に配信される必要がある。なお、ストレージ方式では、新プログラムと旧プログラムとの差分データである更新データファイルやソフトウェアパッケージも統合パッケージに含まれる。ストリーミング方式では、新プログラムと旧プログラムとの差分データである更新データファイルやソフトウェアパッケージも統合パッケージに含まれない。

図９では、上段に示す構造Ｎｏ.６，８に対応するそれぞれのパッケージ構造を、下段に示すように１つのパッケージ構造に統合する。これを統合パッケージ構造と称する。構造Ｎｏ.６，８のそれぞれに存在するデータ項目，例えば、諸元データについては、重複している種類のデータはまとめて１つとする。また、この統合パッケージが構造Ｎｏ６，８を統合したものであることを示すフラグを、諸元データ中に付加する。この場合、ＯＴＡ方式が何れもストリーミングであるから、ソフトウェアパッケージＡ及びＢ並びに差分データ１及び２は、何れも統合パッケージに含まれないファイルとなる。

再び、図８を参照する。次にＰＫＧ生成部３３は、パッケージの生成に必要な情報を、ＥＣＵリプロデータＤＢ４６及びＥＣＵメタデータＤＢ４２から取得する（Ｓ１５）。ここで「必要な情報」とは、例えば諸元生成用データやマニフェスト生成用データ、設計構成情報やパッケージ生成条件、差分データや検証データ等である。それから、更新ソフトウェアのパッケージを１つにまとめて生成する（Ｓ１６）。

続いて、検証データ生成部３４は、ＯＴＡ方式がストリーミングであるパッケージが含まれているか否かを判断し（Ｓ１７）、含まれていれば（Ｙｅｓ）ＭＡＣ（Message Authentication Code）署名処理を行い（Ｓ１８）、含まれていなければ（Ｎｏ）更新データのデジタル署名を計算してパッケージに付与する（Ｓ１９）。そして、生成したパッケージをパッケージＤＢ４３に登録する（Ｓ２０）。

図１０に示すように、検証データ生成部３４は、ＭＡＣ署名処理を開始すると、ストリーミングデータに検証データを付与することが必要であれば（Ｓ２１；Ｙｅｓ）、ストリーミングに使用される中継バッファのサイズを確認し（Ｓ２２）、そのサイズ毎にＭＡＣ署名を計算し（Ｓ２３）、中継バッファのサイズ毎にＭＡＣ署名を付与する（Ｓ２４）。例えば、中継バッファのサイズが１０ｋＢで、ＭＡＣ署名の共通鍵暗号方式としてＡＥＳ（Advanced Encryption Standard）１２６ｂｉｔを採用する場合、１０ｋＢ毎に１６ｂｙｔｅの署名データを付与する。

次に、配信されたパッケージによってリプログを行う車両側システム４側の処理について説明する。図１１に示すセントラルＥＣＵ１３がＡＰである場合の処理と、図１２に示すセントラルＥＣＵ１３がＣＰである場合の処理とは、ステップＳ３１～Ｓ３５は略共通である。センター装置３より配信パッケージを受信すると（Ｓ３１）、諸元データに格納されているパッケージ構造のフラグ情報を読み込む（Ｓ３２）。ただし、セントラルＥＣＵ１３がＡＰである場合は、諸元データに相当する情報がソフトウェアパッケージ及び車両パッケージのそれぞれに含まれているマニフェストに含まれている。

続いて、フラグ情報に基づいてパッケージ構造を特定すると（Ｓ３４）、各パッケージ構造におけるターゲットＥＣＵ１９のプラットフォーム及びＯＴＡ方式毎に、プログラムの更新，リプログを実施する（Ｓ３５）。ここから、セントラルＥＣＵ１３がＡＰである場合はパッケージ構造Ｎｏ.１～４に応じて処理がステップＳ３６（１）～Ｓ３６（４）に分岐し、ＣＰである場合はパッケージ構造Ｎｏ.５～８に応じて処理がステップＳ３６（５）～Ｓ３６（８）に分岐する。

ステップＳ３６（１）では、セントラル－ターゲットＥＣＵの組み合わせがＡＰ－ＡＰであり、ターゲットＥＣＵ１９のＯＴＡ方式がストレージである場合の書き換えとなる。この場合は、ＡＵＴＯＳＡＲのSpecification（SWS）に記載の手順に従い、ＵＣＭマスタ／ＵＣＭによって更新を行う（Ｓ３７（１））。ステップＳ３６（２）では、組み合わせがＡＰ－ＡＰであり、ＯＴＡ方式がストリーミングである場合の書き換えとなり、後述する図１３に示すステップＳ３８～Ｓ４５を実行する。

ステップＳ３６（３）では、組み合わせがＡＰ－ＣＰであり、ＯＴＡ方式がストレージである場合の書き換えとなる。この場合は、ＡＵＴＯＳＡＲのSpecification（SWS）に記載の手順に従い、ＵＣＭマスタとフラッシングアダプタとによって更新を行う（Ｓ３７（３））。ステップＳ３６（４）では、組み合わせがＡＰ－ＣＰであり、ＯＴＡ方式がストリーミングである場合の書き換えとなり、この場合もステップＳ３７（３）に移行する。

図１２に示すステップＳ３６（５）では、組み合わせがＣＰ－ＡＰであり、ＯＴＡ方式がストレージである場合の書き換えとなる。この場合は、ＡＵＴＯＳＡＲのSpecification（SWS）に記載の手順に従い、ＵＣＭによって更新を行う（Ｓ３７（５））。ステップＳ３６（６）では、組み合わせがＣＰ－ＡＰであり、ＯＴＡ方式がストリーミングである場合の書き換えとなり、ステップＳ３８～Ｓ４５を実行する。

ステップＳ３６（７）では、組み合わせがＣＰ－ＣＰであり、ＯＴＡ方式がストレージである場合の書き換えとなる。この場合は、特開２０２０―２７６３３号公報における段落［０３８１］～［０４００］，図１１５～図１１８に記載の手順に従い、ＯＴＡマスタによって更新を行う（Ｓ３７（７））。ステップＳ３６（８）では、組み合わせがＣＰ－ＣＰであり、ＯＴＡ方式がストリーミングである場合の書き換えとなり、ステップＳ３８～Ｓ４５を実行する。

図１３に示すステップＳ３８において、ストリーミングデータの検証データが必要であれば（Ｙｅｓ）、ストリーミングの署名に用いる共通鍵Ａをセンター装置３と鍵交換して受信する（Ｓ３９）。そして、ストリーミングデータを中継バッファのサイズ分だけ受信すると（Ｓ４０）、バッファのサイズ毎に共通鍵Ａを用いてＭＡＣ署名を検証する（Ｓ４１）。

検証に成功すれば（Ｙｅｓ）、ターゲットＥＣＵ１９にストリーミングデータを転送する（Ｓ４３）。そして、リプロデータを全て受信するまでは（Ｓ４４；Ｎｏ）ステップＳ４０に戻って処理を繰り返す。ステップＳ４２で検証が失敗すると（Ｎｏ）、センター装置３にエラーを返す（Ｓ４５）。

以上のように本実施形態によれば、センター装置３の個車情報ＤＢ４１には、複数のＥＣＵ１９それぞれに対する装置の識別及び当該装置のソフトウェアアーキテクチャに関する情報が車両の種別と共に記憶されている。ＰＫＧ構造ＤＢ４４には、複数のＥＣＵ１９それぞれについて、データを更新するために配信するパッケージの構造に関する情報が各ＥＣＵ１９のタイプに応じて記憶されている。

判断部３２は、個車情報ＤＢ４１及びＰＫＧ構造ＤＢ４４に記憶されている情報に基づいて、複数のＥＣＵ１９のうちデータを更新する対象となる対象装置が搭載されている対象車両について配信するパッケージを特定し、ＰＫＧ生成部３３は、特定されたパッケージについての前記構造を示す情報を含むパッケージを生成する。

このように構成すれば、ＰＫＧ生成部３３は、対象車両に配信するパッケージについて、様々な種類のＥＣＵ１９のうちから対象装置のソフトウェアアーキテクチャに対応した構造を備えたものを生成できる。したがって、異なるタイプのＥＣＵ１９が混在している車両についても、全ての更新データを１つのパッケージで配信できる。

そして、パッケージの構造を示す情報には、ＡＵＴＯＳＡＲの仕様書で規定されているＥＣＵ１９のプラットフォームタイプであるＡＰ又はＣＰの何れかであることを示す情報と、データの更新を行うＯＴＡ方式がストレージ方式又はストリーミング方式の何れかであることを示す情報とを含む。このように構成すれば、上記のプラットフォームタイプ及びデータの更新方式が異なるＥＣＵ１９が混在している車両に対して、それぞれに対応した配信パッケージを生成できる。

また、ＰＫＧ生成部３３は、ターゲットＥＣＵ１９がデータの更新を行うための中継を行うセントラルＥＣＵ１３のタイプがＡＰである場合は、ＵＣＭマスタが処理できる構造のパッケージを生成し、セントラルＥＣＵ１３のタイプがＣＰである場合は、ＯＴＡマスタが処理できる構造のパッケージを生成する。したがって、ＡＵＴＯＳＡＲで規定されているセントラルＥＣＵ１３のタイプに応じて適切な配信パッケージを生成できる。

更に、ＰＫＧ生成部３３は、ターゲットＥＣＵ１９のタイプがＡＰである場合は、ＵＣＭが処理できる構造のパッケージを生成し、ＣＰである場合はインストーラが処理できる構造のパッケージを生成する。したがって、ターゲットＥＣＵ１９のタイプに応じて適切な配信パッケージを生成できる。

また、ＰＫＧ生成部３３は、ＯＴＡ方式がストレージ方式である場合は更新データを含む統合パッケージを生成し、ストリーミング方式である場合は更新データを含まない統合パッケージを生成する。したがって、ターゲットＥＣＵ１９それぞれのＯＴＡ方式に対応して適切な配信パッケージを生成できる。加えて、ＯＴＡ方式がストリーミング方式である際に、データの正当性を検証するため、共通鍵暗号方式でＭＡＣ署名した検証データを付与するので、車両側においてデータの正当性検証を確実に行うことができる。

一方、車両側システム４のセントラルＥＣＵ１３は、センター装置３より受信した配信パッケージに含まれている情報から、各ＥＣＵのプラットフォームがＡＰ又はＣＰの何れかであるかと、ＯＴＡ方式がストレージ方式又記ストリーミング方式の何れであるかを識別して、配信パッケージの処理を切り替える。したがって、配信パッケージに含まれている情報に応じて、各ターゲットＥＣＵ１９等のリプログを行うことができる。

また、セントラルＥＣＵ１３は、ＯＴＡ方式がストリーミング方式であれば、センター装置３より共通鍵を取得し、受信したデータについて共通鍵暗号を用いてＭＡＣ署名により正当性を検証する。更に、セントラルＥＣＵ１３は、車両に新たなハードウェアデバイスが追加されると、当該デバイスの情報をセンター装置３に送信し、センター装置３は、個車情報ＤＢ４１の対応する車両の情報に、前記デバイスの情報を追加するので、アフターマーケットにおいてハードウェアデバイスが追加された場合に対応して、個車情報ＤＢ４１の情報を更新できる。

（その他の実施形態）
ＥＣＵのＰＦはＡＰ，ＣＰに限ることなく、その他のＰＦに対応するものでも良い。
共通鍵暗号を用いたＭＡＣ署名による検証は、必要に応じて行えば良い。
署名はＭＡＣ署名に限らない。
図７に示す、車両に新しいハードウェアデバイス等が追加されたことを検出した際に、そのデバイスの情報を構成情報ＤＢ４５に登録する処理も必要に応じて行えば良い。

統合パッケージは次のように生成しても良い。ＰＫＧ生成部３３は、判断部３２が特定したパッケージの構造を解析し、ＰＫＧ構造ＤＢ４４に記憶されるパッケージ構造と異なる場合は、複数のパッケージ構造の少なくとも１つのパッケージ構造にて含まれるデータ項目を含む統合パッケージ構造を生成し、そして、生成した統合パッケージ構造に基づいて、複数の対象装置に対して１つに統合されたパッケージを生成してもよい。

図１５は、統合パッケージ構造および統合パッケージの生成方法を例示する。
まず、Ｓ１１で、上述のように、配信対象車両の情報を取得する。更新対象となるターゲットＥＣＵ１９が特定される。
Ｓ５１では、更新対象となるターゲットＥＣＵ１９は複数か否か判定される。ターゲットＥＣＵ１９が複数ではない場合（Ｓ５１でＮｏ）、統合パッケージは構築されない。
ターゲットＥＣＵ１９が複数あると判定される場合（Ｓ５１でＹｅｓ）と、Ｓ５２で、ターゲットＥＣＵ１９のＩＤに基づいて、ターゲットＥＣＵ１９のＰＦ、更新方式、セントラルＥＣＵ１３のＰＦを特定する。判断部３２は、構成情報ＤＢ４５を検索して、更新対象車両モデルのソフトウェアアーキテクチャを特定する。

Ｓ５３では、ＰＫＧ構造ＤＢ４４を参照し、ターゲットＥＣＵ１９のＰＦ、更新方式、セントラルＥＣＵ１３のＰＦに基づいて、対応するパッケージ構造、つまりＰＫＧ構造Ｎｏ．を特定する。複数のターゲットＥＣＵ１９それぞれについて、アプリプログラムの更新のために、セントラルＥＣＵ１３およびターゲットＥＣＵ１９が要求するパッケージ構造が特定される。

Ｓ５４では、パッケージ構造が複数あるか否かを判定する。複数のターゲットＥＣＵ１９を更新するがパッケージ構造が1種類の場合（Ｓ５４でＮｏ）、Ｓ５５に進む。この場合は、ＰＫＧ構造ＤＢ４４に記憶されているパッケージ構造が統合パッケージ構造となる。

Ｓ５５では、各データがどのターゲットＥＣＵ１９に使用されるデータであるか車両側システム４が判別できるように、データにフラグを付加し統合パッケージとする。例えば、２つのターゲットＥＣＵ１９に対応するパッケージ構造が構造Ｎｏ．６であるとする。この場合、第1のターゲットＥＣＵ１９のアプリプログラムの更新のための諸元データと、第２のターゲットＥＣＵ１９のアプリプログラムの更新のための諸元データが存在する。諸元データそれぞれにフラグを付加する。

パッケージ構造が複数ある場合（Ｓ５４でＹｅｓ）、Ｓ５６に進み、統合パッケージ構造を生成する。統合パッケージ構造は、例えば、図９の下段に示すパッケージ構造である。統合パッケージ構造は、図４に示すＰＫＧ構造ＤＢ４４にはないパッケージ構造である。統合パッケージ構造は、ターゲットＥＣＵ１９が複数あり、且つ、ターゲットＥＣＵ１９に対するパッケージ構造が異なる場合に生成される。

Ｓ５６では、統合すべき複数のパッケージ構造について、パッケージ構造を構成するデータ項目を抽出する。図４で示した例では、Vehicle PKG、ＳＷ ＰＫＧ、諸元データ、ファイル構成情報、検証データ、差分データなどがデータ項目に相当する。図９で示した例では、ＳＷパッケージマニフェスト、ＳＷパッケージマニフェスト検証データ、諸元データ、諸元データ検証データ、ファイル構成情報、ファイル構成情報検証データ、更新前ＲＸＳＷＩＮ、更新前ＲＸＳＷＩＮ検証データ、更新後ＲＸＳＷＩＮ、更新後ＲＸＳＷＩＮ検証データ、差分データ検証データなどがデータ項目に相当する。

さらに、Ｓ５６では、統合パッケージ構造のデータ項目を設定する。統合パッケージ構造に含まれるデータ項目とは、複数のパッケージ構造のうち、少なくとも１つのパッケージ構造に含まれるデータ項目である。これにより、統合パッケージ構造が生成される。
Ｓ５７では、データ項目ごとに複数のパッケージから対応するデータを抽出し、統合パッケージを生成する。ＰＫＧ生成部３３は、パッケージの生成に必要な情報を、ＥＣＵリプロデータＤＢ４６及びＥＣＵメタデータＤＢ４２から取得する。データがいずれのパッケージあるいはいずれのターゲットＥＣＵ１９宛のデータであるかが車両側システム４で判別できるようにフラグが付加される。

以上のステップにより、複数のターゲットＥＣＵ１９に対する複数のパッケージは、それらのパッケージの構造が同一でも異なっていたとしても、１つのパッケージとして生成される。Ｓ５７以降の処理は、図８のＳ１７以降の処理と同様なので記載を省略する。

各装置等が提供する手段および／または機能は、実体的なメモリ装置に記録されたソフトウェアおよびそれを実行するコンピュータ、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの組合せによって提供することができる。例えば、制御装置がハードウェアである電子回路によって提供される場合、それは多数の論理回路を含むデジタル回路、またはアナログ回路によって提供することができる。
本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリーを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリーと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。

図面中、１は車両用プログラム書換えシステム、３はセンター装置、４は車両側システム、１１はマスタ装置、１２はＤＣＭ、１３はセントラルＥＣＵ、１９はＥＣＵ、３０は制御部、３１は情報記憶部、３２は判断部、３３はＰＫＧ生成部、３４は検証データ生成部、４１は個車情報ＤＢ、４２はＥＣＵメタデータＤＢ、４３はパッケージＤＢ、４５は構成情報ＤＢを示す。

Claims (11)

1. 車両に搭載される複数の電子制御装置（１３,１９）に書込むデータを管理するセンター装置（３）であって、
   前記車両に搭載される前記複数の電子制御装置それぞれに対する装置の識別情報，当該装置のソフトウェアアーキテクチャに関する情報，及びデータの更新時における更新方式に関する情報が、前記車両の種別と共に記憶されている車両情報記憶部（４５）と、
   データを更新するために配信するパッケージの構造に関する情報が、前記複数の電子制御装置のうち、データの更新を行うための中継を行う中継装置（１３）のソフトウェアアーキテクチャ、前記複数の電子制御装置のうち、データを更新する対象となる対象装置（１９）のソフトウェアアーキテクチャ、及び、データの更新時における更新方式に関する情報に応じて記憶されているパッケージ構造記憶部（４４）と、
   前記車両情報記憶部及び前記パッケージ構造記憶部に記憶されている情報に基づいて、前記複数の電子制御装置のうち、データを更新する対象となる対象装置が搭載されている対象車両について、パッケージの構造を特定する判断処理部（３２）と、
   この判断処理部によって特定されたパッケージについての前記構造を示す情報を含むパッケージを生成するパッケージ生成部（３３）と
   を備えるセンター装置。
2. 前記構造を示す情報には、前記電子制御装置のソフトウェアアーキテクチャに関する情報として、ＡＵＴＯＳＡＲの仕様書において規定されている電子制御装置のタイプであるアダプティブプラットフォーム又はクラシックプラットフォームの何れかであることを示す情報と、
   データの更新時における更新方式に関する情報として、データの更新を行う方式が、ストレージ方式又はストリーミング方式の何れかであることを示す情報とを含む請求項１記載のセンター装置。
3. 前記複数の電子制御装置の１つは、前記対象装置がデータの更新を行うための中継を行う中継装置（１３）であり、
   前記パッケージ生成部は、前記中継装置のタイプが前記アダプティブプラットフォームである場合は、ＵＣＭ（Update Configuration Management）マスタが処理できる構造のパッケージを生成し、
   前記中継装置のタイプが前記クラッシックプラットフォームである場合は、ＯＴＡ（On The Air）マスタが処理できる構造のパッケージを生成する請求項２記載のセンター装置。
4. 前記パッケージ生成部は、前記対象装置（１９）のタイプが前記アダプティブプラットフォームである場合は、ＵＣＭ（Update Configuration Management）が処理できる構造のパッケージを生成し、
   前記対象装置のタイプが前記クラッシックプラットフォームである場合は、インストーラが処理できる構造のパッケージを生成する請求項２又は３記載のセンター装置。
5. 前記パッケージ生成部は、データの更新を行う方式が前記ストレージ方式である場合は更新データを含む統合パッケージを生成し、前記ストリーミング方式である場合は更新データを含まない統合パッケージを生成する請求項２から４の何れか一項に記載のセンター装置。
6. 前記パッケージ生成部は、前記データの更新を行う方式がストリーミング方式である際に、前記データの正当性を検証するため、共通鍵暗号方式でＭＡＣ（Message Authentication Code）署名した検証データを付与する請求項２から５の何れか一項に記載のセンター装置。
7. 前記パッケージ生成部は、前記判断処理部が特定した前記パッケージの構造を解析し、前記パッケージ構造記憶部に記憶される前記パッケージ構造と異なる場合は、複数のパッケージ構造の少なくとも１つのパッケージ構造にて含まれるデータ項目を含む統合パッケージ構造を生成し、
   前記パッケージ生成部は、生成した統合パッケージ構造に基づいて、複数の対象装置に対して１つに統合されたパッケージを生成する請求項１から６の何れか一項に記載のセンター装置。
8. 車両に搭載され、請求項２から５の何れか一項に記載のセンター装置と通信を行う電子制御装置であって、受信したパッケージに含まれている情報から、前記アダプティブプラットフォーム又は前記クラッシックプラットフォームの何れかであるかと、前記ストレージ方式又は前記ストリーミング方式の何れであるかを識別して、前記パッケージの処理を切り替えるパッケージ処理部（１３）を備える車載電子制御装置。
9. 車両に搭載され、請求項６記載のセンター装置と通信を行う電子制御装置であって、受信したパッケージに含まれている情報から、前記アダプティブプラットフォーム又は前記クラッシックプラットフォームの何れかであるかと、前記ストレージ方式又は前記ストリーミング方式の何れであるかを識別して、前記パッケージの処理を切り替えるパッケージ処理部を備える車載電子制御装置。
10. 前記ストリーミング方式を採用している際に、前記センター装置より共通鍵を取得し、受信したデータについて共通鍵暗号を用いて前記ＭＡＣ署名により正当性を検証する請求項９記載の車載電子制御装置。
11. 請求項１から７の何れか一項に記載のセンター装置（３）と、請求項８から１０の何れか一項に記載の車載電子制御装置（４）とを備えるパッケージ配信システムにおいて、
    前記車載電子制御装置は、車両に新たなハードウェアデバイスが追加されると、当該デバイスの情報を前記センター装置に送信し、
    前記センター装置は、前記車両情報記憶部の対応する車両の情報に、前記デバイスの情報を追加するパッケージ配信システム。

Images