JP2023005718A - 車載通信システム，リプロポリシーメタデータのデータ構造及びダウンロードメタデータのデータ構造 - Google Patents

Abstract

【課題】電子制御装置のプラットフォームや配信方式等が多様化した場合でも柔軟に対応可能なデータフォーマットを用いて通信できる車載通信システムを提供する。【解決手段】ＯＴＡセンタ１は通信プロトコル及び通信先情報が格納される配信レイヤ、ＯＴＡマスタ３２のプラットフォームに関する情報が格納されるマスタレイヤ、及びターゲットＥＣＵ３３のプラットフォームに関する情報が格納されるターゲットレイヤからなる３層構造で、配信パッケージの構成情報を示すＲＰメタデータとしてＯＴＡマスタ３２に送信する。ＯＴＡマスタ３２はＲＰメタデータを解釈して自車両に適合した配信パッケージであると判断すると、各層に対応して必要となるデータを取得するための制御情報が格納されているＤＬメタデータをＯＴＡセンタ１に要求する。ＯＴＡセンタ１がＤＬメタデータをＯＴＡマスタ３２に送信すると、ＯＴＡマスタ３２はＤＬメタデータを解釈して必要なデータを取得しターゲットＥＣＵ３３のデータ更新制御を行う。【選択図】図１

Description

本発明は、センタ装置と車両に搭載されるマスタ装置及びターゲット装置との間で通信を行うシステム，及びそのシステムに使用されるデータのデータ構造に関する。

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

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

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

そのため、車両側に搭載されるＥＣＵについては、ストレージ方式，ストリーミング方式を採用するものが混在したり、ＣＰ，ＡＰタイプが混在するケースが想定される。加えて、将来的には、車載Ｌｉｎｕｘ（登録商標），例えばAutomotive Grade Linux；AGLに対応したものや、別途スマートホン等にデータをダウンロードすることも想定される。しかしながら、現状のＯＴＡでは、上記のような通信態様のバリエーションに対応することまでは想定されていない。

本発明は上記事情に鑑みてなされたものであり、その目的は、電子制御装置のプラットフォームや配信方式等が多様化した場合でも柔軟に対応可能なデータフォーマットを用いて通信を行うことができる車載通信システム，並びにそのシステムに使用されるリプロポリシーメタデータのデータ構造及びダウンロードメタデータのデータ構造を提供することにある。

請求項１記載の車載通信システムによれば、センタ装置は、通信プロトコル及び通信先情報が格納される配信レイヤ、マスタ装置のプラットフォームに関する情報が格納されるマスタレイヤ、及びターゲット装置のプラットフォームに関する情報が格納されるターゲットレイヤからなる３層構造を有し、配信パッケージの構成情報を示すリプロポリシーメタデータをマスタ装置に送信する。

マスタ装置は、リプロポリシーメタデータを解釈して自車両に適合した配信パッケージであると判断すると、３層のそれぞれに対応して必要となるデータを取得するための制御情報が格納されているダウンロードメタデータをセンタ装置に要求する。センタ装置がダウンロードメタデータをマスタ装置に送信すると、マスタ装置はダウンロードメタデータを解釈して必要なデータを取得し、ターゲット装置のデータ更新制御を行う。

配信パッケージの構成情報を示すリプロポリシーメタデータは、言い換えれば、パッケージの構成種別を表す情報を含んだ情報であり、車両側でそのデータの内容をチェックすることでパッケージの配信ミスを防止することを主眼とする情報である。また、データを取得するための制御情報が格納されているダウンロードメタデータは、言い換えれば、複数のターゲットとなるＥＣＵごとの更新データをダウンロードするための情報を，マスタ装置が把握できるようにするための内容を規定する情報である。これらのメタデータを、配信，マスタ及びターゲットの３層構造にすることで、転送方式やプラットフォームのタイプ、配信パッケージの種類が増大した場合でも、それらを柔軟に定義して対応することができ、ターゲット装置のデータ更新を行うことが可能になる。

請求項２記載の車載通信システムによれば、リプロポリシーメタデータは、マスタレイヤにおけるパラメータとして、マスタ装置のプラットフォーム種別情報及びプラットフォームの制御方式種別情報を含む。また、ターゲットレイヤにおけるパラメータとして、ターゲット装置のプラットフォーム種別情報並びにプラットフォームの制御方式種別情報、センタ装置からターゲット装置へのデータ転送方式種別情報を含む。そして、マスタ装置は上記の各情報を自身が管理する設計構成情報と比較することで、自車両に適合した配信パッケージか否かを判断する。

尚、設計構成情報は、マスタ装置及びターゲット装置が搭載されている車両に関する情報や、マスタ装置及びターゲット装置のハードウェア及びソフトウェアに関する情報である。すなわち、リプロポリシーメタデータのマスタ及びターゲットレイヤのパラメータに、上記の各種別情報を含むことで、マスタ装置がそれらの種別情報を解釈してターゲット装置へのデータ転送を行うことが可能になる。

請求項３記載の車載通信システムによれば、ダウンロードメタデータは、各レイヤそれぞれそのパラメータとして、データ取得先のＵＲＩ、データに付与したハッシュ値、ターゲット装置のＩＤ，センタ装置からのデータ転送方式種別情報を含む。また、マスタレイヤ及びターゲットレイヤにおけるパラメータとして、マスタ装置及びターゲット装置のプラットフォーム種別情報を含む。そして、マスタ装置は各情報に基づいて、各レイヤに対応して必要となるデータを必要となるタイミングで取得し、ターゲット装置のデータ更新制御を行う。

すなわち、ダウンロードメタデータの各レイヤのパラメータに、上記の各情報を含むことで、マスタ装置がそれらの情報を解釈して、ターゲット装置へのデータ転送をより具体的な手順で行うことが可能になる。

第１実施形態であり、車載通信システムにおけるＯＴＡセンタ側の構成を概略的に示す機能ブロック図 ＯＴＡマスタ側の構成を概略的に示す機能ブロック図 リプロポリシーメタデータの各データ項目の一例を示す図 ダウンロードメタデータの各データ項目の一例を示す図 マスタレイヤ，ターゲットレイヤに対応するデータパッケージの一例を示す図 車両側システム内のデータ転送の流れをイメージ的に示す図 ＯＴＡセンタ，セントラルＥＣＵ，ターゲットＥＣＵ間におけるデータ転送の流れをイメージ的に示す図 ＯＴＡセンタ側の処理を示すフローチャート ＯＴＡマスタ（セントラルＥＣＵがＡＰ）側の処理を示すフローチャート ＯＴＡマスタ（セントラルＥＣＵがＣＰ）側の処理を、図９の一部相当部分について示すフローチャート 第２実施形態であり、配信パッケージの転送にスマートホンを介在させる処理を示すシーケンス図（その１） 配信パッケージの転送にスマートホンを介在させる処理を示すシーケンス図（その２） ＯＴＡセンタ側の処理を示すフローチャート スマートホン側の処理を示すフローチャート ＯＴＡマスタ側の処理を示すフローチャート 第３実施形態であり、ＯＴＡセンタ，ＯＴＡマスタ，ターゲットＥＣＵ間の処理を示すシーケンス図 配信パッケージを複数のｚｉｐファイルに分割した状態を示す図 ＯＴＡセンタ側のパッケージ生成処理を示すフローチャート ＯＴＡセンタ側のパッケージ伝送処理を示すフローチャート ＯＴＡマスタ側の処理を示すフローチャート 第４実施形態であり、ＤＬメタデータの暗号化／署名処理に関する情報内容の一例を示す図 ＯＴＡセンタ，ＯＴＡマスタ，ターゲットＥＣＵ間の処理を示すシーケンス図 ＯＴＡセンタ側の処理を示すフローチャート ＯＴＡマスタ側の処理を示すフローチャート 図２０に示すシーケンスの変形例を示す図 第５実施形態であり、各装置間の処理の流れをイメージ的に示すと共に、各装置についてユーザが行う操作手順を示す図 ＯＴＡセンタ，ＯＴＡマスタ，ターゲットＥＣＵ間に、ＰＣアプリ、ナビ／ＵＳＢメモリが介在して行う処理を示すシーケンス図

（第１実施形態）
図１に示すように、車載通信システムのＯＴＡセンタ１は、ＰＫＧ生成サーバ２，配信サーバ３，ＰＫＧ生成ロジックＤＢ４及び設計構成情報ＤＢ５を備えている。尚、ＰＫＧは「パッケージ」、ＤＢは「データベース」である。また、ＰＫＧ生成サーバ２に係る各処理機能部を、外在化して示している。ＯＴＡセンタ１は、図２に示す車両側システム３１に、ターゲットＥＣＵ３３の制御プログラムを更新するための更新データを、配信パッケージに格納して送信する。その配信パッケージを送信するのに先立って、本実施形態では、必要な情報を格納したリプロポリシーメタデータ及びダウンロードメタデータを、車両側システム３１のＯＴＡマスタ３２に送信する。以下、リプロポリシーメタデータを「ＲＰメタデータ」と称し、ダウンロードメタデータを「ＤＬメタデータ」と称すことがある。

尚、本実施形態のサーバ、データベース、サーバ内の各種処理部は便宜上の表示であり、同様の機能を実現する別の態様も存在する。ＯＴＡマスタについても、各種処理部は説明の便宜上、分けているのであって、例えば、ソフトウェア又はハードウェアとしては一体でも良いし、複数に分かれても良い。

ＰＫＧ生成ロジックＤＢ４は、ＲＰメタデータ及びＤＬメタデータを生成するための各情報に対応するデータが格納されている。メタデータ特定処理部６は、ＲＰ及びＤＬメタデータの各項目とデータフォーマットとを特定する処理を行う。ＲＰメタデータ生成処理部７はＲＰメタデータを生成し、暗号化／署名処理部８は、生成されたＲＰメタデータを暗号化すると共に、デジタル署名を付与する。

ＤＬメタデータ生成処理部９はＤＬメタデータを生成する。計算処理部１０は、更新データのデータサイズを計算すると共に更新データのハッシュ値を計算する。暗号化／署名処理部１１は、生成されたＤＬメタデータを暗号化すると共に、デジタル署名を付与する。ＰＫＧ本体生成処理部１２は、更新データ等を含む配信パッケージの本体部分を生成する。

ＰＫＧ生成サーバ２は、上記の各処理部等により生成されたＲＰメタデータ，ＤＬメタデータ及び配信パッケージを配信サーバ３に転送する。配信サーバ３は、設計構成情報ＤＢ５にアクセスし、配信パッケージを送信する車両の構成情報を取得して配信パッケージに付与する。

図２に示すように、車両側システム３１は、ＯＴＡマスタ３２及びターゲットＥＣＵ３３を備えている。ＯＴＡマスタ３２は、図６に示すＤＣＭ（Data Communication Module）３２Ａ及びセントラルＥＣＵ３２Ｂで構成されている。ターゲットＥＣＵ３３は、実際には複数存在する。

ＲＰメタデータ解析処理部３４は、ＯＴＡマスタ３２が受信したＲＰメタデータを解析処理する。復号／署名検証処理部３５は、ＲＰメタデータに付与されているデジタル署名を用いて検証処理を行い、ＲＰメタデータを復号化する。

ＤＬメタデータ解析処理部３６は、ＯＴＡマスタ３２が受信したＤＬメタデータを解析処理する。計算処理部３７は、ＤＬメタデータのパラメータである、更新データのデータサイズを計算すると共に更新データのハッシュ値を計算する。復号／署名検証処理部３８は、ＤＬメタデータに付与されているデジタル署名を用いて検証処理を行い、ＤＬメタデータを復号化する。

ＰＫＧ本体取得処理部３９は、ＯＴＡマスタ３２が受信した配信パッケージの本体部分を取得する。取得された配信パッケージに含まれている更新データは、転送処理部４０によりターゲットＥＣＵ３３に転送される。解析処理部４１は、ＲＰ及びＤＬメタデータの各項目とデータフォーマットとを解析する処理を行う。

≪リプロポリシーメタデータ≫
図３に示すＲＰメタデータは、配信パッケージのダウンロードに先立って、ＯＴＡセンタ１よりＯＴＡマスタ３２に送信される。
＜ＲＰメタデータバージョン＞
ＲＰメタデータのバージョンであり、例えば「１．０．０」や「２．０．０」などのバージョン情報が格納される。

＜通信レイヤ＞
ＯＴＡセンタ１との通信に使用されるプロトコル，例えばＵｐｔａｎｅ（登録商標）やＯＭＡ－ＤＭ（Open Mobile Alliance-Device Management）等を示す情報や、通信手段がＯＴＡマスタ３２であることを示す「セルラー」や、その他後述するスマートホンやＵＳＢメモリであること等の情報が格納される。

＜マスタレイヤ＞
ＯＴＡマスタ３２について、そのプラットフォーム（ＰＦ）が、例えばＡＰ，ＣＰ，ＡＧＬ(Automotive Grade Linux)，Ａｎｄｒｏｉｄ（登録商標）であること等を示す情報が格納される。ＥＣＵのプラットフォームに応じた更新プログラムを配信するためのパッケージ構造について、一般社団法人ＪＡＳＰＡＲの仕様では、標準化団体ＡＵＴＯＳＡＲの静的ＯＳで動作するクラシックプラットフォーム（ＣＰ）に適用可能なデータ要件が規定されている。また、ＡＵＴＯＳＡＲでは、動的ＯＳで動作する新たなタイプのアダプティブプラットフォーム（ＡＰ）に適用可能なデータ要件が規定されている。ＡＧＬは、車載Ｌｉｎｕｘであり、Ａｎｄｒｏｉｄは、Android Automotive OSである。

加えて、制御方式については、特定のフォーマットに従い設定されたパラメータに応じて処理する「パラメータ」や、特定のフォーマットがなくより自由な記載形式で処理する「スクリプト」等の情報が格納される。

＜ターゲットレイヤ＞
ターゲットＥＣＵ３３に対応した情報である。ＰＦ，転送方式，制御方式については、前述したものと同様である。ターゲットＩＤは、ターゲットＥＣＵ３３に対応したＩＤであるが、ここに格納するのはオプションである。

≪ダウンロードメタデータ≫
図４に示すＤＬメタデータは、ＲＰメタデータに続いてＯＴＡセンタ１よりＯＴＡマスタ３２に送信される。

＜配信レイヤ＞
例えば通信プロトコルがＵｐｔａｎｅであれば、Ｕｐｔａｎｅメタデータを取得するための情報であり、それに対応したＵＲＩ，データ名，データサイズ，ハッシュ値，ターゲットＩＤ,転送方式等が格納される。
＜マスタレイヤ＞
例えばＶｅｈｉｃｌｅ ＰＫＧを取得するための情報であり、各項目は配信レイヤと同様である。この情報は、複数の場合がある。

＜ターゲットレイヤ＞
例えばＳｏｆｔｗａｒｅ ＰＫＧを取得するための情報であり、各項目は配信レイヤと同様である。この情報も、複数の場合がある。尚、Ｖｅｈｉｃｌｅ ＰＫＧやＳｏｆｔｗａｒｅ ＰＫＧについては、例えば“Specification of Update Configuration Management AUTOSAR AP R20-11,Document ID No.706”のp50,52，53に掲載されており、当該文献の関連する記載を参照。

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

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

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

図５は、上述のＡＰに対応したパッケージ構成を、本実施形態において拡張した一例を示している。マスタレイヤの情報に従ってＶｅｈｉｃｌｅ ＰＫＧのＶｅｈｉｃｌｅ ＰＫＧ ｍａｎｉｆｅｓｔを取得すれば、どのＥＣＵに、どのパッケージを、どの順番で、いつ転送すれば良いかといった分配手順に関する情報が得られる。

また、ターゲットレイヤに対応した４つのＳｏｆｔｗａｒｅ ＰＫＧは、ＵＣＭ（Update Configuration Management）１～４の各プラットフォームタイプが、ＡＰ，ＣＰ，ＡＧＬ，Ａｎｄｒｏｉｄとそれぞれ異なっている。後者の２つは、ＡＵＴＯＳＡＲでは規定されていないプラットフォームタイプであるが、ＥＣＵがこれらのプラットフォームを採用した場合にも対応可能となる。尚、ＵＣＭについては、ＡＵＴＯＳＡＲにて説明されているので詳細は省略する。

図６において、ＤＣＭ３２Ａは、ＯＴＡセンタ１との間で通信ネットワークを介してデータ通信を行う車載通信機であり、配信サーバ３から配信パッケージをダウンロードすると、その配信パッケージから更新データを抽出してセントラルＥＣＵ３２Ｂに転送する。セントラルＥＣＵ３２Ｂは、データ中継機能を有する車両用ゲートウェイ装置であり、ＤＣＭ３２Ａから更新データを取得すると、その更新データを、アプリプログラムを書換える対象であるターゲットＥＣＵ３３に配信する。尚、セントラルＥＣＵを「Ｃ－ＥＣＵ」と表記することがある。

図６では、車両側システム３１内において、更新データが転送される流れをイメージ的に示している。セントラルＥＣＵ３２Ｂは、ストレージ方式でＶｅｈｉｃｌｅ ＰＫＧを取得すると、その情報に従い、各ターゲットＥＣＵ３３（１）～３（３）に対するＳｏｆｔｗａｒｅ ＰＫＧの配信制御を行う。ターゲットＥＣＵ３３（２）のＵＩはユーザインターフェイスであり、ＩＶＩは車載インフォティメントである。また、ターゲットＥＣＵ３３（３）のＡＤＡＳは、先進運転支援システムである。

また、図７は、セントラルＥＣＵ３２Ｂ及びターゲットＥＣＵ３３のＰＦ種別が何れもＡＰであり、ストリーミング方式で各データパッケージを転送する場合のシーケンスを概略的に示している。

次に、本実施形態の作用について説明する。図８に示すように、ＯＴＡセンタ１は、ＰＫＧ生成サーバ２において配信パッケージを生成する（Ｓ１）。続いて、ＰＫＧ生成サーバ２において、更新対象システム情報のセントラルＥＣＵ３２Ｂのソフトウェアバージョンをキーにして、ＰＫＧ生成ロジックＤＢ４を確認すると（Ｓ２）、ＰＫＧ生成サーバ２で生成すべきＤＬメタデータ，ＲＰメタデータのデータ項目構成を決定する（Ｓ３）。更新対象システム情報には、ターゲットＥＣＵ３３のＩＤや、ソフトウェア情報及びハードウェア情報が含まれている。この情報に基づいて、ＰＫＧ生成サーバ２は、更新対象システムを特定することが可能になる。

次に、ＰＫＧ生成サーバ２は、更新対象システム情報のセントラルＥＣＵ３２ＢのＰＦ種別（ＡＰ／ＣＰ）をキーにして、ＰＫＧ生成ロジックＤＢ４内を確認する（Ｓ４）。ＰＦ種別がＡＰであれば（Ｓ５；ＹＥＳ）、ＰＫＧ生成サーバ２は、ＪＳＯＮによりＤＬメタデータを生成し（Ｓ６）、更新対象システム情報からＲＰメタデータの項目を埋める（Ｓ７）。一方、ＰＦ種別がＣＰであれば（Ｓ５；ＮＯ）、ＰＫＧ生成サーバ２は、バイナリでＤＬメタデータを生成して（Ｓ８）ステップＳ７に移行する。

続いて、ＰＫＧ生成サーバ２は、計算処理部１０により、ＤＬメタデータのデータサイズ及びハッシュ値を計算して対応する項目を埋めると（Ｓ９）、更新対象システム情報からターゲットＩＤと転送方式の項目を埋める（Ｓ１０）。そして、ＤＬメタデータのファイル名を、リプロ設定ファイルから取得して設定する（Ｓ１１）。次に、暗号化／署名処理部８によりＲＰメタデータの暗号化／署名処理を行ない（Ｓ１２）、暗号化／署名処理部１１によりＤＬメタデータの暗号化／署名処理を行なうと（Ｓ１３）、パッケージ本体，ＲＰメタデータ及びＤＬメタデータを配信サーバ３に伝送する（Ｓ１４）。

図９は、セントラルＥＣＵ３２ＢのＰＦ種別がＡＰの場合に対応した処理である。ＯＴＡマスタ３２は、ＯＴＡセンタ１からＲＰメタデータを取得すると（Ｓ２１）、ＲＰメタデータの復号化／書名検証を行う（Ｓ２２）。検証結果がエラーになれば、エラーのステータス情報をＯＴＡセンタ１に返す（Ｓ２７）。検証結果が成功であれば、ＲＰメタデータのデータ項目をチェックし、各項目がＯＴＡマスタ３２が管理している情報と一致するか否かをチェックする（Ｓ２３）。不一致があれば、ステップＳ２７と同様にエラーのステータス情報をＯＴＡセンタ１に返す（Ｓ２８）。

一方、各項目が一致すれば（ＹＥＳ）、ＲＰメタデータに基づきパッケージ構造を特定し（Ｓ２４）、ＯＴＡセンタ１からＤＬメタデータを取得する（Ｓ２５）。そして、ＤＬメタデータの復号化／書名検証を行う（Ｓ２６）。検証結果がエラーになれば、エラーのステータス情報をＯＴＡセンタ１に返す（Ｓ２９）。検証結果が成功であれば、ＤＬメタデータで指定されているＵＲＩから、マスタレイヤ，ターゲットレイヤのデータをそれぞれダウンロードする（Ｓ３０，Ｓ３１）。

そして、ターゲットＥＣＵ３３毎に更新プログラムを構成すると（Ｓ３２）、各パッケージ構造におけるターゲットＥＣＵ３３のプラットフォーム及びＯＴＡ方式毎に、プログラムの更新，リプログを実施する（Ｓ３３）。ここから、処理がステップＳ３４（１）～Ｓ３４（４）に分岐する。尚、セントラルＥＣＵ３２ＢがＣＰである場合は、図１０に示すステップＳ３４（５）～Ｓ３４（８）に分岐する。

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

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

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

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

以上のように本実施形態によれば、ＯＴＡセンタ１は、通信プロトコル及び通信先情報が格納される配信レイヤ、ＯＴＡマスタ３２のプラットフォームに関する情報が格納されるマスタレイヤ、及びターゲットＥＣＵ３３のプラットフォームに関する情報が格納されるターゲットレイヤからなる３層構造を有し、配信パッケージの構成情報を示すＲＰメタデータをＯＴＡマスタ３２に送信する。

ＯＴＡマスタ３２は、ＲＰメタデータを解釈して自車両に適合した配信パッケージであると判断すると、３層のそれぞれに対応して必要となるデータを取得するための制御情報が格納されているＤＬメタデータをＯＴＡセンタ１に要求する。ＯＴＡセンタ１がＤＬメタデータをＯＴＡマスタ３２に送信すると、ＯＴＡマスタ３２はＤＬメタデータを解釈して必要なデータを取得して、ターゲットＥＣＵ３３のデータ更新制御を行う。

ＲＰメタデータは、主にＯＴＡセンタ１がＯＴＡマスタ３２に送信する配信パッケージの内容を規定する情報であり、ＤＬメタデータは、主にＯＴＡマスタ３２がターゲットＥＣＵ３３に送信する更新データの内容を規定する情報である。これらのメタデータを、配信，マスタ及びターゲットの３層構造にすることで、転送方式やプラットフォームのタイプ、配信パッケージの種類が増大した場合でも、それらを柔軟に定義して対応することができ、ターゲットＥＣＵ３３のデータ更新を行うことが可能になる。

具体的には、ＲＰメタデータは、マスタレイヤにおけるパラメータとして、ＯＴＡマスタ３２のプラットフォーム種別情報及びプラットフォームの制御方式種別情報を含む。また、ターゲットレイヤにおけるパラメータとして、ターゲットＥＣＵ３３のプラットフォーム種別情報並びにプラットフォームの制御方式種別情報、ＯＴＡセンタ１からターゲットＥＣＵ３３へのデータ転送方式種別情報を含む。そして、ＯＴＡマスタ３２は上記の各情報を自身が管理する設計構成情報と比較することで、自車両に適合した配信パッケージか否かを判断する。

このように、ＲＰメタデータのマスタ及びターゲットレイヤのパラメータに、上記の各種別情報を含むことで、ＯＴＡマスタ３２がそれらの種別情報を解釈してターゲットＥＣＵ３３へのデータ転送を行うことが可能になる。

また、ＤＬメタデータは、各レイヤそれぞれそのパラメータとして、データ取得先のＵＲＩ、データに付与したハッシュ値、ターゲットＥＣＵ３３のＩＤ，ＯＴＡセンタ１からのデータ転送方式種別情報を含む。また、マスタレイヤ及びターゲットレイヤにおけるパラメータとして、ＯＴＡマスタ３２及びターゲットＥＣＵ３３のプラットフォーム種別情報を含む。そして、ＯＴＡマスタ３２は各情報に基づいて、各レイヤに対応して必要となるデータを必要となるタイミングで取得し、ターゲットＥＣＵ３３のデータ更新制御を行う。このように、ＤＬメタデータの各レイヤのパラメータに、上記の各情報を含むことで、ＯＴＡマスタ３２がそれらの情報を解釈して、ターゲットＥＣＵ３３へのデータ転送をより具体的な手順で行うことが可能になる。

（第２実施形態）
以下、第１実施形態と同一部分には同一符号を付して説明を省略し、異なる部分について説明する。図１１及び図１２に示すように、第２実施形態では、スマートホン４２を介在させて配信パッケージを転送する。尚、スマートホン４２は、例えばカーナビゲーション装置のような車載装置やＤＣＭ３２Ａ等とペアリングして通信しており、そのような装置を介してＯＴＡマスタ３２との通信が可能となっている。また、スマートホン４２に替わるパーソナルコンピュータ（ＰＣ）でも良い。尚、スマートホンを「スマホ」と表記する場合がある。

図１３において、ＯＴＡセンタ１の配信サーバ３は、ＯＴＡマスタ３２から車両構成情報を同期させるための通知を受け取ると（Ｓ４１）、ＯＴＡマスタ３２にキャペーン情報を通知する（Ｓ４２）。車両構成情報は、車両に搭載されるＥＣＵのハードウェア及びソフトウェアに関する識別情報であり、複数のＥＣＵから成るシステム構成の識別情報や、複数のシステムから成る車両構成の識別情報も含まれる。「同期させるための通知」とは、車両側に保持されている構成情報の内容と、ＯＴＡセンタ１側が保持している構成情報の内容とを一致させる、つまり同期させるために行われる通知である。また、キャンペーン情報、車両側システム３やスマートホン４２に表示させるプログラム更新に関する情報である。

ユーザは、スマートホン４２に表示されたキャンペーン情報を参照し、更新データサイズ確認した後、配信パッケージのダウンロード先を選択する。ダウンロード先は、ＯＴＡマスタ３２を意味する「セルラー」，スマートホン４２又はカーナビゲーション装置に接続されたＵＳＢメモリのような携帯型記憶端末である。配信サーバ３が、その選択結果を受信し（Ｓ４３）、スマートホン４２又はＵＳＢメモリが選択された場合（Ｓ４４；ＹＥＳ）、配信サーバ３はダウンロード先のリンク情報を、例えば電子メールなどによりスマートホン４２に通知する（Ｓ４５）。

ユーザが、上記の通知を元に、配信サーバ３から配信パッケージをダウンロードし、スマートホン４２又はＵＳＢメモリの指定したディレクトリに保存した後（Ｓ４６）、スマートホン４２からダウンロード完了通知を受信すると（Ｓ４７；ＹＥＳ）、配信サーバ３は、ステップＳ４１と同様に、再度ＯＴＡマスタ３２から「同期させるための通知」を受け取る（Ｓ４８）。ＰＫＧ生成サーバ２が、第１実施形態で示したようにＲＰメタデータ及びＤＬメタデータを生成すると（Ｓ４９）、配信サーバ３は、各メタデータをＯＴＡマスタ３２に送信する（Ｓ５０，Ｓ５１）。

図１４に示すように、スマートホン４２がＯＴＡセンタ１からキャンペーン情報の通知を受信すると（Ｓ６１）、ユーザは配信パッケージのダウンロード先を選択し（Ｓ６２）、その選択結果をＯＴＡセンタ１に通知する（Ｓ６３）。スマートホン４２又はＵＳＢメモリを選択すれば（Ｓ６４；ＹＥＳ）、スマートホン４２は配信サーバ３から配信パッケージを受信する（Ｓ６５）。そして、ダウンロード完了通知をＯＴＡセンタ１に送信すると（Ｓ６６）、ＯＴＡマスタ３２に配信パッケージを転送する（Ｓ６７）。

図１５に示すように、ＯＴＡマスタ３２は、ＯＴＡセンタ１に車両構成情報を送信する（Ｓ７１）。ユーザが、配信パッケージのダウンロード先にスマートホン４２又はＵＳＢメモリを選択し（Ｓ７２；ＹＥＳ）、カーナビゲーション装置に表示された指示を実行すると（Ｓ７３；ＹＥＳ）、ＯＴＡマスタ３２は、ＯＴＡセンタ１からＲＰメタデータ及びＤＬメタデータを受信する（Ｓ７４）。そして、ＯＴＡマスタ３２は、ＯＴＡセンタ１から通知されたディレクトリに従い、スマートホン４２又はＵＳＢメモリから配信パッケージをダウンロードすると（Ｓ７５）、その配信パッケージに含まれている更新データをターゲットＥＣＵ３３に転送する（Ｓ７６）。

以上のように第２実施形態によれば、ＯＴＡセンタ１は、更新データの情報をスマートホン４２に通知し、ユーザがスマートホン４２を介して、更新データの送信先を前記スマートホン４２又はＵＳＢメモリに指定すると、ＯＴＡセンタ１は更新データをスマートホン４２又はＵＳＢメモリに送信する。そして、ＯＴＡセンタ１は、通信先情報をスマートホン４２又はＵＳＢメモリに設定すると、ＲＰメタデータ及びＤＬメタデータを順次ＯＴＡマスタ３２に送信し、ＯＴＡマスタ３２は、通信先情報に応じてスマートホン４２又はＵＳＢメモリより配信パッケージを受信する。

このように、ＯＴＡマスタ３２は、ＯＴＡセンタ１から送信される配信パッケージを、スマートホン４２又はＵＳＢメモリを介して受信し、更新データをターゲットＥＣＵ３３に転送することができる。したがって、より柔軟な形態でターゲットＥＣＵ３３のデータ更新を行うことが可能になる。

（第３実施形態）
従来、複数のターゲットＥＣＵに対してストレージ方式で更新データを配信する際には、それらに対応する複数のパッケージを１つのｚｉｐファイルに纏めて送信していた。図１６に示すように、第３実施形態では、複数のターゲットＥＣＵ３３に対してストレージ方式で更新データを配信する際に、配信パッケージを複数のｚｉｐファイルに分けて配信する。例えば、ターゲットＥＣＵ３３（１）に対する更新データ（１）及び（２）があり、ターゲットＥＣＵ３３（２）に対する更新データ（３）及び（４）があるとする。この場合、更新データ（１）及び（２）をｚｉｐファイルのパッケージ１とし、更新データ（３）及び（４）をｚｉｐファイルのパッケージ２とする。そして、これら２つのパッケージが同時に更新するべきデータを含んでいることを示す指示情報を、パッケージ１及び２の配信に先立ってＯＴＡマスタ３２に送信する。

尚、ダウンロードメタデータのマスタレイヤの情報を１セット（ＵＲＩ，データ名，データサイズ等）とすると、複数のターゲットＥＣＵに対してストレージ方式で更新データを配信する場合は、ダウンロードメタデータのマスタレイヤの情報が複数セット、言い換えると、ターゲットＥＣＵの数だけ記載される。また、ターゲットレイヤにはnull又はblankが設定される。

図１７に示すように、ＯＴＡセンタ１は、更新対象システム情報から更新データを収集し、データサイズを確認する（Ｓ１１１）。そして、ストレージ方式による配信パッケージの総データサイズが、セントラルＥＣＵ３２Ｂが有しているバッファメモリの容量を超えないかチェックする（Ｓ１１２）。前記容量を超えなければ（ＮＯ）更新データを１つのｚｉｐファイルに格納し（Ｓ１１６）、前記容量を超えていれば（ＹＥＳ）、更新データをＮ個ずつ、Ｍ個のｚｉｐファイルに分割して格納する（Ｓ１１４）。それから、ＤＬメタデータに、全てのパッケージの情報を格納する。以上のようにして配信パッケージを生成する。

図１８に示すように、ＯＴＡセンタ１は、ステップＳ４１，Ｓ５０，Ｓ５１を実行すると、配信サーバ２は、上述の指示情報を含むパッケージをＯＴＡマスタ３２に送信する（Ｓ５２）。それから、パッケージ１，２をＯＴＡマスタ３２に順次送信する（Ｓ５３）。

図１９に示すように、ＯＴＡマスタ３２は、ステップＳ７１，Ｓ７４（Ａ，Ｂ）を実行すると、配信サーバ２から指示情報を含むパッケージを受信する（Ｓ７７）。そのパッケージを解凍して、ターゲットＥＣＵ３３（１）及び３３（２）のデータ更新に関する依存関係を把握する（Ｓ７８）。次に、ＯＴＡマスタ３２は、更新データが複数のｚｉｐファイルに分割されているかどうかを確認し（Ｓ７９）、ＯＴＡセンタ１から配信パッケージを受信して解凍すると（Ｓ８０）、それらに含まれている更新データを対応するターゲットＥＣＵ３３に転送する（Ｓ８１）。

全てのターゲットＥＣＵ３３からインストール完了通知を受信すると（Ｓ８２，Ｓ８３；ＹＥＳ，Ｓ８４；ＹＥＳ）、何れもインストールが成功していれば（Ｓ８５；ＹＥＳ）、ターゲットＥＣＵ３３にアクティベートの実行を指示する（Ｓ８６）。一方、インストールに失敗があれば（Ｓ８５；ＮＯ）、その失敗したターゲットＥＣＵ３３，及びそのＥＣＵ３３と依存関係にあるターゲットＥＣＵ３３に対してロールバックの実行を指示する（Ｓ８７）。

以上のように第３実施形態によれば、ＯＴＡセンタ１からＯＴＡマスタ３２，ターゲットＥＣＵ３３にストレージ方式で更新データを配信する際に、対応する複数の配信パッケージを複数のｚｉｐファイルに分けて配信する。これにより、受信したｚｉｐファイルから解凍を行って、順次処理を進めることが可能になる。

（第４実施形態）
従来、ＯＴＡセンタより車両側に送信する更新データについては、その全体を暗号化して署名を付していた。そのため、例えばデータサイズが２ＧＢであるとすると、２ＧＢのデータのダウンロードが完了しなければ、署名による検証ができなかった。しかしながら、ＯＴＡセンタが送信するデータは、その内容によっては、必ずしも暗号化や署名の付与が必要でないものもある。そこで、更新データのうち、例えば課金に関するデータ部分のように、重要なデータのみを暗号化して署名を付与できるようにすれば処理効率を向上させることが可能になる。

第４実施形態では、ＤＬメタデータのマスタレイヤ及びターゲットレイヤにおいて、図２０に示すように、暗号化及びデジタル署名に関連した情報項目を設ける。
・暗号化種別情報 ：（共通鍵）ＡＥＳ（Advanced Encryption Standard），
Ｔｒｉｐｌｅ－ＤＥＳ（Data Encryption Standard），
（公開鍵）ＲＳＡ（Rivest-Shamir-Adleman cryptosystem），
ＥＣＣ（Elliptic Curve Cryptography）
・署名種別情報 ：（共通鍵）ＣＢＣ－ＭＡＣ
（Message Authentication Code），ＣＭＡＣ（Common MAC）
（公開鍵）ＤＳＡ（Digital Signature Algorithm）,
ＥＣＤＳＡ（Elliptic Curve DSA）
・鍵ＩＤ情報 ：鍵の特定に使用
・暗号モード種別情報 ：Ｅｎｃ（Encrypt） ｔｈｅｎ ＭＡＣ，
ＭＡＣ ｔｈｅｎ，ＥＮＣ
・保護対象情報 ：特定のファイル又はデータを指定
・保護領域指定情報 ：上記ファイルの全体又は一部を指定
・オフセットサイズ情報：先頭より何Byte目から保護対象とするか指定
・保護データサイズ情報：何Byteを保護するか指定

ＯＴＡセンタ１及びＯＴＡマスタ３２は、上記の情報項目を用いて、配信パッケージ中の一部のファイル又はデータを暗号化及び署名付与したり、更に前記ファイル又はデータ一部について暗号化及び署名付与する。

次に、第４実施形態の作用について説明する。図２１及び図２２に示すように、ＯＴＡセンタ１のＰＫＧ生成サーバ２は、対象更新データのＤＬメタデータを参照し、暗号化対象に指定されているファイルや、そのファイルのオフセットサイズを確認する（Ｓ９１）。そして、ＤＬメタデータに書き込まれている各情報に従い、暗号化対象個所を暗号化してデジタル署名を付与する（Ｓ９２）。尚、暗号化されたデータ部分以外のデータを「平文」と称しているが、この「平文」については、例えばＰｒｏＧｕａｒｄやＤａｓｈＯ等のツールを用いて「難読化」する。

続いて、ＰＫＧ生成サーバ２は、暗号化／署名付与したデータと、難読化した平文とを配信サーバ３に転送し（Ｓ９３）、配信サーバ３は、それらのデータをＯＴＡマスタ３２に送信する（Ｓ９４）。尚、図２１では、ＯＴＡセンタ１とＯＴＡマスタ３２との間の通信を、ＴＬＳ（Transport Layer Security）により暗号化して行うことを示している。

図２３に示すように、ＯＴＡマスタ３２は、ＯＴＡセンタ１から上記のデータを受信すると（Ｓ１０１）、ＤＬメタデータの情報を元に、暗号化／署名付与されたデータを復号化／署名検証する（Ｓ１０２）。そして、復号化／署名検証した更新データをターゲットＥＣＵ３３に転送する（Ｓ１０３）。

尚、図２４は、上記の変形であり、ＯＴＡマスタ３２は、暗号化／署名付与されたデータをそのままターゲットＥＣＵ３３に転送し、ターゲットＥＣＵ３３が暗号化／署名付与されたデータを復号化／署名検証する例を示す。

以上のように第４実施形態によれば、ＯＴＡセンタ１からＯＴＡマスタ３２に送信する配信パッケージ中の一部のファイル又はデータだけを送信側で暗号化／署名付与し、受信側で復号化／署名検証する。これにより、暗号化，復号化等の処理に要する時間を短縮できる。

（第５実施形態）
図２５及び図２６に示すように、第５実施形態では、通信システムにカーナビゲーション装置４３，携帯型記憶端末の一例であるＵＳＢメモリ４４及びパーソナルコンピュータ４５を介在させる。以下、カーナビゲーション装置を「ナビ」、パーソナルコンピュータを「ＰＣ」と表記する。尚、ＵＳＢメモリ４４に替えて例えばＳＤカードを用いても良い。

（１）車両内において、ＵＳＢメモリ４４をナビ４３に接続した状態で、ユーザがナビ４３を操作して（２）ＵＳＢメモリ４４に車両構成情報を書き込む。この情報は、車両の秘密鍵を用いてデジタル署名を付与したものである。その後、（３）ＵＳＢメモリ４４をナビ４３から取り出す。

（４）次に、ＵＳＢメモリ４４をＰＣ４５に接続し、ユーザがＰＣ４５を操作して、対応するＰＣアプリを用いて車両構成情報をＯＴＡセンタ１に送信する。ＯＴＡセンタ１では、受信した車両構成情報をデジタル署名により検証し、検証結果がＯＫであればその情報に適用可能な配信パッケージを検索する。（５）ユーザは、ＰＣアプリによって前記配信パッケージをＰＣ４５にダウンロードして、ＵＳＢメモリ４４に書き込む。その際、配信パッケージに、車両モデル情報や、更新前の車両構成情報を書き加える。

（６）次に、車両内において、ＵＳＢメモリ４４を再びナビ４３に接続すると、（７）ユーザがナビ４３を操作して、（８）ＵＳＢメモリ４４に記憶されているＲＰメタデータ及びＤＬメタデータをＯＴＡマスタ３２に送信する。（９）ＯＴＡマスタ３２は、自車両に対応した配信パッケージかどうかを検証し、（１０）検証結果がＯＫであれば、更新データをターゲットＥＣＵ３３にダウンロードさせて、インストール，アクティベートを順次指示する。

以上のように第５実施形態によれば、ユーザがナビ４３やＰＣ４５を用いて、ＯＴＡセンタから取得した必要な情報や配信パッケージをＵＳＢメモリ４４に書き込み、そのＵＳＢメモリ４４からナビ４３を経由して、更にＯＴＡマスタ３２からターゲットＥＣＵ３３に更新データをダウンロードさせることが可能になる。

（その他の実施形態）
ＲＰメタデータ及びＤＬメタデータの内容は、個別の設計に応じて適宜変更すればよい。
携帯情報端末は、スマートホン４２や、ＰＣ４５に限らない。
携帯型記憶端末は、ＵＳＢメモリ４４やＳＤカードに限らない。

本開示は、実施例に準拠して記述されたが、本開示は当該実施例や構造に限定されるものではないと理解される。本開示は、様々な変形例や均等範囲内の変形をも包含する。加えて、様々な組み合わせや形態、さらには、それらに一要素のみ、それ以上、あるいはそれ以下、を含む他の組み合わせや形態をも、本開示の範疇や思想範囲に入るものである。

各装置等が提供する手段および／または機能は、実体的なメモリ装置に記録されたソフトウェアおよびそれを実行するコンピュータ、ソフトウェアのみ、ハードウェアのみ、あるいはそれらの組合せによって提供することができる。例えば、制御装置がハードウェアである電子回路によって提供される場合、それは多数の論理回路を含むデジタル回路、またはアナログ回路によって提供することができる。

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

図面中、１はＯＴＡマスタ、２はＰＫＧ生成サーバ、３は配信サーバ、３１は車両側システム、３２はＯＴＡマスタ装置、３２ＡはＤＣＭ、３２ＢはセントラルＥＣＵ、３３はターゲットＥＣＵを示す。

Claims (21)

1. 車両に搭載されるターゲット装置である電子制御装置に、更新データを配信パッケージとして送信するセンタ装置（１）と、
   前記車両に搭載され、前記配信パッケージを受信して、前記ターゲット装置に更新データを転送するマスタ装置（３２）と、
   このマスタ装置より転送された更新データを記憶部に書き込む前記ターゲット装置（３３）とを備え、
   前記センタ装置は、通信プロトコル及び通信先情報が格納される配信レイヤ，前記マスタ装置のプラットフォームに関する情報が格納されるマスタレイヤ，及び前記ターゲット装置のプラットフォームに関する情報が格納されるターゲットレイヤからなる３層構造であり、前記配信パッケージの構成情報を示すリプロポリシーメタデータとして、前記マスタ装置に送信し、
   前記マスタ装置は、前記リプロポリシーメタデータを解釈して自車両に適合した配信パッケージであると判断すると、前記３層のそれぞれに対応して必要となるデータを取得するための制御情報が格納されているダウンロードメタデータを前記センタ装置に要求し、
   前記センタ装置が、前記ダウンロードメタデータを前記マスタ装置に送信すると、
   前記マスタ装置は、前記ダウンロードメタデータを解釈して必要なデータを取得すると、前記ターゲット装置のデータ更新制御を行う車載通信システム。
2. 前記リプロポリシーメタデータは、前記マスタレイヤにおけるパラメータとして、マスタ装置のプラットフォーム種別情報及びプラットフォームの制御方式種別情報を含み、
   前記ターゲットレイヤにおけるパラメータとして、ターゲット装置のプラットフォーム種別情報並びにプラットフォームの制御方式種別情報，前記センタ装置からターゲット装置へのデータ転送方式種別情報を含み、
   前記マスタ装置は、前記の各情報を自身が管理する設計構成情報と比較することで、自車両に適合した配信パッケージか否かを判断する請求項１記載の車載通信システム。
3. 前記ダウンロードメタデータは、前記各レイヤそれぞれそのパラメータとして、データ取得先のＵＲＩ（Uniform Resource Identifier），データに付与したハッシュ値，前記ターゲット装置のＩＤ，前記センタ装置からのデータ転送方式種別情報を含み、
   マスタレイヤ及びターゲットレイヤにおけるパラメータとして、マスタ装置及びターゲット装置のプラットフォーム種別情報を含み、
   前記マスタ装置は、前記の各情報に基づいて、各レイヤに対応して必要となるデータを必要となるタイミングで取得し、前記ターゲット装置のデータ更新制御を行う請求項２記載の車載通信システム。
4. 前記プラットフォーム種別情報は、前記マスタ装置及び前記ターゲット装置のソフトウェアアーキテクチャに関する情報として、ＡＵＴＯＳＡＲの仕様書において規定されている装置のタイプであるアダプティブプラットフォーム又はクラシックプラットフォームを含むソフトウェアアーキテクチャの何れかを示し、
   前記データ転送方式種別情報は、ストレージ方式又はストリーミング方式の何れかである請求項２又は３記載の車載通信システム。
5. 前記プラットフォーム種別情報は、更に車載Ｌｉｎｕｘ（登録商標），Ａｎｄｒｏｉｄ（登録商標）の何れかを含む請求項４記載の車載通信システム。
6. 前記センタ装置は、前記ダウンロードメタデータのマスタレイヤにおいて、データ転送方式種別情報をストレージ方式とする際に、配信パッケージを複数指定する請求項４又は５記載の車載通信システム。
7. 前記リプロポリシーメタデータの通信先情報として、携帯情報端末（４２）又は携帯記憶媒体を設定可能であり、
   前記マスタ装置は、前記通信先情報に応じて、前記センタ装置から送信される配信パッケージを、前記携帯情報端末又は前記携帯記憶媒体を介して取得可能である請求項１から６の何れか一項に記載の車載通信システム。
8. 前記センタ装置は、更新データの情報を前記携帯情報端末に通知し、
   ユーザが、前記携帯情報端末を介して、前記更新データの送信先を前記携帯情報端末又は前記携帯記憶媒体に指定すると、前記センタ装置は、前記更新データを前記携帯情報端末又は前記携帯記憶媒体に送信し、
   前記センタ装置は、前記通信先情報を前記携帯情報端末又は前記携帯記憶媒体に設定すると、前記リプロポリシーメタデータ及び前記ダウンロードメタデータを順次前記マスタ装置に送信し、
   前記マスタ装置は、前記通信先情報に応じて、前記携帯情報端末又は前記携帯記憶媒体より配信パッケージを受信する請求項７記載の車載通信システム。
9. 前記マスタ装置は、前記携帯記憶媒体が接続された車載装置（４３）を介して、前記携帯記憶媒体（４４）に自車両のデータ更新制御に必要な情報を書き込み、
   携帯情報端末（４５）により、前記携帯記憶媒体に書き込まれた情報に基づいて前記センタ装置にアクセスすることで取得した前記リプロポリシーメタデータ及び前記ダウンロードメタデータ並びに対応した配信パッケージを、前記携帯記憶媒体に書き込み、
   前記センタ装置は、前記リプロポリシーメタデータにおける前記通信先情報を前記携帯記憶媒体に設定しており、
   前記携帯記憶媒体が接続された車載装置より、前記マスタ装置に前記リプロポリシーメタデータ及び前記ダウンロードメタデータを転送すると、
   前記マスタ装置は、前記通信先情報に応じて、前記携帯記憶媒体より配信パッケージを受信する請求項７記載の車載通信システム。
10. 前記ダウンロードメタデータは、マスタレイヤ及びターゲットレイヤにおけるパラメータとして、暗号化種別情報，署名種別情報，暗号モード種別情報，暗号化／署名対象データ種別情報を含み、
    前記暗号化種別情報は、ＡＥＳ，Ｔｒｉｐｌｅ－ＤＥＳ，ＲＳＡ，ＥＣＣの何れかであり、
    前記署名種別情報は、ＣＢＣ-ＭＡＣ，ＣＭＡＣ,ＤＳＡ,ＥＣＤＳＡの何れかであり、
    前記暗号モード種別情報は、Ｅｎｃ ｔｈｅｎ ＭＡＣ，ＭＡＣ ｔｈｅｎ，ＥＮＣの何れかであり、
    前記センタ装置は、前記の各情報に応じて、前記暗号化／署名対象データの暗号化及び署名付与を行い、
    前記マスタ装置は、前記の各情報に応じて、前記暗号化／署名対象データの復号化を行う請求項１から９の何れか一項に記載の車載通信システム。
11. 前記ダウンロードメタデータは、マスタレイヤ及びターゲットレイヤにおけるパラメータとして保護対象情報を含み、
    前記保護対象情報は、暗号化する対象及びデジタル署名を付与する対象を、配信パッケージの全体とするか、一部とするかを指定する情報であり、
    前記センタ装置は、前記保護対象情報に応じて、前記暗号化／署名対象データの暗号化及び署名付与を行い、
    前記マスタ装置は、前記保護対象情報に応じて、前記暗号化／署名対象データの復号化を行う請求項１から１０の何れか一項に記載の車載通信システム。
12. 車両に搭載されるターゲット装置である電子制御装置に、更新データを配信パッケージとして送信するセンタ装置（１）が備えるコンピュータと、
    前記車両に搭載され、前記配信パッケージを受信して、前記ターゲット装置に更新データを転送するマスタ装置（３２）が備えるコンピュータとにより用いられる配信パッケージの構成情報を示すリプロポリシーメタデータのデータ構造であって、
    前記リプロポリシーメタデータは、通信プロトコル及び通信先情報が格納される配信レイヤ，前記マスタ装置のプラットフォームに関する情報が格納されるマスタレイヤ，及び前記ターゲット装置のプラットフォームに関する情報が格納されるターゲットレイヤからなる３層構造であり、
    前記センタ装置が、前記リプロポリシーメタデータを前記マスタ装置に送信すると、
    前記マスタ装置が、前記リプロポリシーメタデータを解釈して、自車両に適合した配信パッケージであると判断すると、前記３層のそれぞれに対応して必要となるデータを取得するための制御情報が格納されているダウンロードメタデータを前記センタ装置に要求する処理に用いられるリプロポリシーメタデータのデータ構造。
13. 前記マスタレイヤにおけるパラメータとして、マスタ装置のプラットフォーム種別情報及びプラットフォームの制御方式種別情報を含み、
    前記ターゲットレイヤにおけるパラメータとして、ターゲット装置のプラットフォーム種別情報並びにプラットフォームの制御方式種別情報，前記センタ装置からターゲット装置へのデータ転送方式種別情報を含み、
    前記マスタ装置が、前記の各情報を自身が管理する設計構成情報と比較して、自車両に適合した配信パッケージか否かを判断する処理に用いられる請求項１２記載のリプロポリシーメタデータのデータ構造。
14. 前記プラットフォーム種別情報は、前記マスタ装置及び前記ターゲット装置のソフトウェアアーキテクチャに関する情報として、ＡＵＴＯＳＡＲの仕様書において規定されている装置のタイプであるアダプティブプラットフォーム又はクラシックプラットフォームの何れかであり、
    前記データ転送方式種別情報は、ストレージ方式又はストリーミング方式の何れかである請求項１３記載のリプロポリシーメタデータのデータ構造。
15. 前記プラットフォーム種別情報は、更に車載Ｌｉｎｕｘ，Ａｎｄｒｏｉｄ（登録商標）の何れかを含む請求項１４記載のリプロポリシーメタデータのデータ構造。
16. 前記通信先情報に、携帯情報端末又は携帯記憶媒体を設定可能であり、
    前記マスタ装置が前記通信先情報に応じて、前記センタ装置から送信される配信パッケージを、前記携帯情報端末又は前記携帯記憶媒体を介して取得する処理に用いられる請求項１２から１５の何れか一項に記載のリプロポリシーメタデータのデータ構造。
17. 請求項１２から１６の何れか一項に記載のリプロポリシーメタデータのデータ構造を用いることで、前記マスタ装置が前記センタ装置に要求するダウンロードメタデータのデータ構造であって、
    前記配信，マスタ及びターゲットの各レイヤそれぞれそのパラメータとして、データ取得先のＵＲＩ（Uniform Resource Identifier），データに付与したハッシュ値，前記ターゲット装置のＩＤ，前記センタ装置からのデータ転送方式種別情報を含み、
    マスタレイヤ及びターゲットレイヤにおけるパラメータとして、マスタ装置及びターゲット装置のプラットフォーム種別情報を含み、
    前記マスタ装置が、前記の各情報に基づいて、各レイヤに対応して必要となるデータを必要となるタイミングで取得し、前記ターゲット装置のデータ更新制御を行う処理に用いられるダウンロードメタデータのデータ構造。
18. 前記プラットフォーム種別情報は、前記マスタ装置及び前記ターゲット装置のソフトウェアアーキテクチャに関する情報として、ＡＵＴＯＳＡＲの仕様書において規定されている装置のタイプであるアダプティブプラットフォーム又はクラシックプラットフォーム，車載Ｌｉｎｕｘ（登録商標），Ａｎｄｌｏｉｄ（登録商標）の何れかであり、
    前記データ転送方式種別情報は、ストレージ方式又はストリーミング方式の何れかである請求項１７記載のダウンロードメタデータのデータ構造。
19. 前記マスタレイヤにおいて、前記データ転送方式種別情報をストレージ方式とする際に、配信パッケージを複数指定可能である請求項１８記載のダウンロードメタデータのデータ構造。
20. 前記マスタレイヤ及びターゲットレイヤにおけるパラメータとして、暗号化種別情報，署名種別情報，暗号モード種別情報，暗号化／署名対象データ種別情報を含み、
    前記暗号化種別情報は、ＡＥＳ，Ｔｒｉｐｌｅ－ＤＥＳ，ＲＳＡ，ＥＣＣの何れかであり、
    前記署名種別情報は、ＣＢＣ-ＭＡＣ，ＣＭＡＣ,ＤＳＡ,ＥＣＤＳＡの何れかであり、
    前記暗号モード種別情報は、Ｅｎｃ ｔｈｅｎ ＭＡＣ，ＭＡＣ ｔｈｅｎ，ＥＮＣの何れかであり、
    前記センタ装置が、前記の各情報に応じて、前記暗号化／署名対象データの暗号化及び署名付与を行い、
    前記マスタ装置が、前記の各情報に応じて、前記暗号化／署名対象データの復号化を行う処理に用いられる請求項１７から１９の何れか一項に記載のダウンロードメタデータのデータ構造。
21. 前記マスタレイヤ及びターゲットレイヤにおけるパラメータとして保護対象情報を含み、
    前記保護対象情報は、暗号化する対象及びデジタル署名を付与する対象を、配信パッケージの全体とするか、一部とするかを指定する情報であり、
    前記センタ装置が、前記保護対象情報に応じて、前記暗号化／署名対象データの暗号化及び署名付与を行い、
    前記マスタ装置が、前記保護対象情報に応じて、前記暗号化／署名対象データの復号化を行う処理に用いられる請求項１７から２０の何れか一項に記載のダウンロードメタデータのデータ構造。
    

Images