JP2023501665A - 車両のアップグレードパッケージを処理するための方法および装置 - Google Patents

Abstract

車両のアップグレードパッケージを処理するための方法および装置。方法は、第1の端末（121）がサーバ（11）から1つまたは複数の第1のデータブロックを受信し、第1のデータブロックが車両のアップグレード（S101）のために使用され、第1の端末（121）は第2の端末（122）から一つ以上の第2のデータブロックを取得し、第2のデータブロックは車両のアップグレードのために使用され、第2のデータブロックはサーバ（11）によって第2の端末（122）へ送信される（S102）こと、および第1の端末（121）は、第1のデータブロックおよび第2のデータブロックに基づいて車両のアップグレードパッケージを取得する（S103）ことを含む。具体的には、サーバ（11）は、車両のアップグレードパッケージを複数のデータブロックに分割し、次いで、複数のデータブロックを複数の端末に配信することができる。次いで、各端末は、端末によって受信されたデータブロックと、別の端末から端末によって取得されたデータブロックとに基づいて、ピアツーピア方式で車両のアップグレードパッケージを取得することができる。このプロセスでは、端末のいずれも、OTAサーバから車両の完全なアップグレードパッケージを取得する必要はない。したがって、OTAサーバの負荷を低減することができる。

Description

本願は、2019年11月14日に中国国家知識産権局に提出された、発明の名称を「車両のアップグレードパッケージを処理するための方法および装置」とする中国特許出願第2019111136671号の優先権を主張し、その全体が参照によりここに組み込まれる。

本願は通信技術に関し、特に、車両のアップグレードパッケージを処理するための方法および装置に関する。

車両のインターネット技術の発展に伴い、ますます多くの車両が、ソフトウェア関連のオペレーティングシステムを設けられている。ソフトウェアの更新中、車両は、無線（over the air、OTA）サーバから、OTA技術に基づいて、車両のアップグレードパッケージをダウンロードし、車両のアップグレードパッケージを使用することによりソフトウェアの更新を実施することができる。

通常、車両がアップグレード要求を送信するたびに、OTAサーバは車両のアップグレード要求に応答し、車両のアップグレードパッケージを車両に配信する必要がある。

しかしながら、OTAサーバが各車両に車両のアップグレードパッケージを与える必要があるため、OTAサーバの負荷は比較的大きい。

本願の実施形態は、OTAサーバの負荷を低減するために、車両のアップグレードパッケージを処理するための方法および装置を提供する。

第1の態様によれば、本願の実施形態は、車両のアップグレードパッケージを処理するための方法を提供する。方法は、第1の端末がサーバから1つまたは複数の第1のデータブロックを受信し、第1のデータブロックは車両のアップグレードのために使用され、第1の端末は第2の端末から1つまたは複数の第2のデータブロックを取得し、第2のデータブロックは車載システムをアップグレードするために使用され、第2のデータブロックがサーバによって第2の端末に送信され、第1の端末は、第1のデータブロックおよび第2のデータブロックに基づいて車両のアップグレードパッケージを取得することを含む。具体的には、サーバは、車両のアップグレードパッケージを複数のデータブロックに分割し、次いで、複数のデータブロックを複数の端末に配信することができる。次いで、各端末は、端末によって受信されたデータブロックと、別の端末から端末によって取得されたデータブロックとに基づいて、ピアツーピア（peer to peer、P2P）方式で車両のアップグレードパッケージを取得することができる。このプロセスでは、端末のいずれも、OTAサーバから車両の完全なアップグレードパッケージを取得する必要はない。したがって、OTAサーバの負荷を低減することができる。

可能な設計では、第1のデータブロックと第2のデータブロックの両方が暗号化されたデータブロックであり、第1のデータブロックのデータブロック長、および少なくとも1つの第2のデータブロックのデータブロック長はそれぞれ、暗号化アルゴリズムのパケットの長さの整数倍である。車両のアップグレードパケットを、その長さがパケットの長さの整数倍であるデータブロックに分割することによって、カプセル解除器が被暗号化パケットの処理中に解読におけるパケットの統合のための時間をさらに消費しないことを保証することができる。これは、タイミング攻撃に効果的に抵抗し、それによって被暗号化パケットの機密の保護および完全性の保護を保証する。

可能な設計では、第1の端末が、第1のデータブロックおよび少なくとも1つの第2のデータブロックに基づいて車両のアップグレードパッケージを取得することが、第1の端末が第1の時間に第1のデータブロックの解読を開始し、第1の端末が第2の時間に第2のデータブロックを受信することであって、第1の時間は第2の時間よりも早いこと、または第1の端末が第3の時間に第2のデータブロックの解読を開始し、第1の端末が第4の時間に第1のデータブロックを受信することであって、第3の時間は第4の時間よりも早いこと、を含む。本願のこの実施形態では、第1の端末は、データブロックを受信しながらデータブロックを解読する。したがって、すべてのデータブロックを受信した後に第1の端末がすべてのデータブロックを一緒に解読する方法と比較されると、本願のこの実施形態における方法は、解読効率を改善し、アップグレードパッケージのダウンロード時間を短縮することができる。

可能な設計では、第1のデータブロックおよび第2のデータブロックは各々、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名を含み、第1の端末が、第1の時間に第1のデータブロックの解読を開始することは、第1のデータブロック内の署名が、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名であることを第1の端末が確認したときに、第1の端末が第1の時間に第1のデータブロックの解読を開始することを含み、第1の端末が第3の時間に第2のデータブロックの解読を開始することは、第2のデータブロック内の署名が、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名であることを第1の端末が確認したときに、第1の端末が第3の時間に第2のデータブロックの解読を開始することを含む。この場合、第1のデータブロックおよび第2のデータブロックで搬送された署名がOTAサーバの署名ではない場合、第1のデータブロックおよび第2のデータブロックは破棄されてもよく、OTAサーバの署名を含む第1のデータブロックおよび第2のデータブロックが再取得され得る。このようにして、第1の端末は、別の装置によって送信された安全でないデータブロックを受信することが防止され、それによってデータブロック送信のセキュリティが向上する。

可能な設計では、サーバは、車両のアップグレードパッケージの分割によって取得されたデータブロックと、データブロックを受信する端末との間の対応関係を記憶するようにさらに構成される。第1の端末が第2の端末から1つまたは複数の第2のデータブロックを取得することは、第1の端末が、対応関係に基づいて第2の端末にデータブロック取得要求を送信すること、および第1の端末は、データブロック取得要求に応答して第2の端末によって返信された1つまたは複数の第2のデータブロックを受信することを含む。このようにして、第1の端末は、サーバによって提供された対応関係に基づいて、対応する第2の端末から第2のデータブロックを正確に取得することができる。

可能な設計では、サーバはプロキシサーバであり、車両のアップグレードパッケージは、プロキシサーバによって無線OTAサーバから取得され、第1の端末は車両である。この場合、プロキシサーバは、車両のアップグレードを支援することができ、それによってOTAサーバの負荷を低減することができる。

可能な設計では、第1の端末は充電パイルである。

可能な設計では、方法は、充電パイルが車両によって送信されたアップグレードパッケージ取得要求を受信すること、および車両が充電パイルの安全検証に成功した場合に、充電パイルが、アップグレードパッケージ取得要求に基づいて車両のアップグレードパッケージを車両に返信することをさらに含む。このようにして、車両は、充電中に車両のアップグレードパッケージをダウンロードすることができる。車両の充電中、車両は通常、静止状態にあるため、通常は比較的良好なネットワーク環境があり得ること、また車両が充電補助装置に接続されているため、車両の電力不足に起因する車両のアップグレードパッケージのダウンロード中断などの現象を回避することができることが理解できる。したがって、車両のアップグレードのユーザ体験が効果的に改善され得る。

可能な設計では、第1の端末がサーバから第1のデータブロックを受信することは、第1の端末がサーバとのセキュリティ認証に成功したときに、第1の端末によって、サーバから第1のデータブロックを受信する。第1の端末は、サーバとセキュリティ認証を行った後に第1のデータブロックを受信するので、第1の端末によって受信される第1のデータブロックのセキュリティを向上させることができる。

第2の態様によれば、本願の実施形態は、車両のアップグレードパッケージを処理するための方法を提供する。方法は、サーバが、車両のアップグレードパッケージを複数のデータブロックに分割すること、およびサーバが複数のデータブロックを少なくとも1つの端末に配信することであって、各端末は、端末によって受信されたデータブロックと、少なくとも1つの端末のうちの別の端末からのデータブロックとに基づいて、車両のアップグレードパッケージを取得するように構成されることを含む。

可能な設計では、サーバが車両のアップグレードパッケージを複数のデータブロックに分割することは、サーバが暗号化アルゴリズムに従って車両のアップグレードパッケージを暗号化し、車両の暗号化されたアップグレードパッケージを複数のデータブロックに分割することを含む。

可能な設計では、サーバはプロキシサーバであり、サーバが車両のアップグレードパッケージをブロックに分割する前に、方法は、プロキシサーバが、無線OTAサーバから車両のアップグレードパッケージを取得することをさらに含む。

可能な設計では、プロキシサーバが無線OTAサーバから車両のアップグレードパッケージを取得することは、プロキシサーバが、無線OTAサーバに車両のアップグレードパッケージ取得要求を送信することを含み、車両のアップグレードパッケージ取得要求は、オペレーティングシステムの種類および車両のバージョンを含み、プロキシサーバがOTAサーバとのセキュリティ検証に成功したとき、プロキシサーバは、OTAサーバによって送信された車両のアップグレードパッケージを受信し、車両のアップグレードパッケージは、オペレーティングシステムの種類および車両のバージョンに基づいてOTAサーバによって生成される。

可能な設計では、サーバが複数のデータブロックを少なくとも1つの端末に配信した後、方法は、サーバが、車両のアップグレードパッケージの分割によって取得されたデータブロックと、データブロックを受信する端末との間の対応関係を記録することをさらに含む。

第3の態様によれば、本願の実施形態は、第1の端末であって、サーバから1つまたは複数の第1のデータブロックを受信するように構成される受信モジュールであって、第1のデータブロックが車両のアップグレードのために使用される、受信モジュール、および処理モジュールであって、第1の端末によって、第2の端末から1つまたは複数の第2のデータブロックを取得し、第2のデータブロックが車載システムをアップグレードするために使用され、第2のデータブロックがサーバによって第2の端末に送信され、第1のデータブロックおよび第2のデータブロックに基づいて車両のアップグレードパッケージを取得するよう構成される、処理モジュールを含む、第1の端末を提供する。

可能な設計では、第1のデータブロックと第2のデータブロックの両方が暗号化されたデータブロックであり、第1のデータブロックのデータブロック長、および少なくとも1つの第2のデータブロックのデータブロック長はそれぞれ、暗号化アルゴリズムのパケットの長さの整数倍である。

可能な設計では、処理モジュールは、具体的には、第1の時間に第1のデータブロックの解読を開始し、第2の時間に第2のデータブロックを受信するように構成され、第1の時間は第2の時間よりも早いか、または、処理モジュールは、第3の時間に第2のデータブロックの解読を開始し、第4の時間に第1のデータブロックを受信するように構成され、第3の時間は第4の時間よりも早い。

可能な設計では、第1のデータブロックおよび第2のデータブロックは、各々、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名を含み、処理モジュールは、具体的には、第1のデータブロック内の署名が、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名であることを確認したときに、第1の時間に第1のデータブロックの解読を開始するようにさらに構成され、第2のデータブロック内の署名が、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名であることを確認したときに、第3の時間に第2のデータブロックの解読を開始するように構成される。

可能な設計では、サーバは、車両のアップグレードパッケージの分割によって取得されたデータブロックとデータブロックを受信する端末との間の対応関係を記憶し、処理モジュールは、具体的には、対応関係に基づいて、第2の端末にデータブロック取得要求を送信し、データブロック取得要求に応答して第2の端末によって返信された1つまたは複数の第2のデータブロックを受信するようにさらに構成される。

可能な設計では、サーバはプロキシサーバであり、車両のアップグレードパッケージは、プロキシサーバによって無線OTAサーバから取得され、第1の端末は車両である。

可能な設計では、第1の端末は充電パイルである。

可能な設計では、受信モジュールは、車両によって送信されたアップグレードパッケージ取得要求を受信するようにさらに構成され、また処理モジュールは、車両が充電パイルの安全検証に成功したときに、アップグレードパッケージ取得要求に基づいて車両のアップグレードパッケージを車両に返信するようにさらに構成される。

可能な設計では、受信モジュールは、具体的には、第1の端末がサーバとのセキュリティ認証に成功したときに、第1の端末によって、サーバから第1のデータブロックを受信するように構成される。

第4の態様によれば、本願の実施形態は、サーバであって、車両のアップグレードパッケージを複数のデータブロックに分割するように構成された処理モジュール、および複数のデータブロックを少なくとも1つの端末に配信するように構成された送信モジュールであって、各端末が、端末によって受信されたデータブロックと、少なくとも1つの端末のうちの別の端末からのデータブロックとに基づいて、車両のアップグレードパッケージを取得するように構成された、送信モジュールを含む、サーバを提供する。

可能な設計では、処理モジュールは、具体的には、暗号化アルゴリズムに従って車両のアップグレードパッケージを暗号化し、車両の暗号化されたアップグレードパッケージを複数のデータブロックに分割するように構成される。

可能な設計では、サーバはプロキシサーバであり、処理モジュールは、無線OTAサーバから車両のアップグレードパッケージを取得するようにさらに構成される。

可能な設計では、処理モジュールは、具体的には、車両のアップグレードパッケージ取得要求を無線OTAサーバに送信し、車両のアップグレードパッケージ取得要求は、オペレーティングシステムの種類および車両のバージョンを含み、プロキシサーバがOTAサーバとのセキュリティ検証に成功したときに、OTAサーバによって送信された車両のアップグレードパッケージを受信し、車両のアップグレードパッケージは、オペレーティングシステムの種類および車両のバージョンに基づいてOTAサーバによって生成されるように構成される。

可能な設計では、処理モジュールは、車両のアップグレードパッケージの分割によって取得されたデータブロックと、データブロックを受信する端末との間の対応関係を記録するようにさらに構成される。

第5の態様によれば、本願の実施形態は、車両のアップグレードパッケージを処理するための装置を提供する。車両のアップグレードパッケージを処理するための装置は、第1の端末内のチップまたはシステムオンチップであってもよく、プロセッサおよびインターフェイス回路を含む。インターフェイス回路は、コード命令を受信し、なおかつコード命令をプロセッサへ伝送するように構成される。プロセッサはコード命令を実行して第1の態様、または第1の態様の可能な設計のいずれか1つによる方法を実行するように構成される。

第6の態様によれば、本願の実施形態は、車両のアップグレードパッケージを処理するための装置を提供する。車両のアップグレードパッケージを処理するための装置は、サーバ内のチップまたはシステムオンチップであってもよく、プロセッサおよびインターフェイス回路を含む。インターフェイス回路は、コード命令を受信し、なおかつコード命令をプロセッサへ伝送するように構成される。プロセッサはコード命令を実行して第2の態様、または第2の態様の可能な設計のいずれか1つによる方法を実行するように構成される。

第7の態様によれば、本願の実施形態は、メモリとプロセッサを含む、車両のアップグレードパッケージを処理するための装置を提供する。プロセッサが、メモリ内のプログラム命令を実行して、第1の態様または第1の態様の可能な設計のうちのいずれか1つによる方法を実行する。

第8の態様によれば、本願の実施形態は、メモリとプロセッサを含む、車両のアップグレードパッケージを処理するための装置を提供する。プロセッサが、メモリ内のプログラム命令を実行して、第2の態様または第2の態様の可能な設計のうちのいずれか1つによる方法を実行する。

第9の態様によると、本願の実施形態は可読コンピュータ記憶媒体を提供する。可読コンピュータ記憶媒体は、コンピュータプログラムを記憶するように構成され、コンピュータプログラムは、第1の態様または第1の態様の可能な実施態様のいずれか1つによる方法を実行するために使用される。

第10の態様によると、本願の実施形態は可読コンピュータ記憶媒体を提供する。可読コンピュータ記憶媒体は、コンピュータプログラムを記憶するように構成され、コンピュータプログラムは、第2の態様または第2の態様の可能な実施態様のいずれか1つによる方法を実行するために使用される。

第11の態様によれば、本願の実施形態は、車両のアップグレードパッケージを処理するためのシステムを提供する。システムは、第3の態様の通信装置、および対応する実現可能な実装形態と、第4の態様の通信装置、および対応する実現可能な実装形態とを含む。

本願の第2の態様から第11の態様の技術的解決策は、本願の第1の態様の技術的解決策に対応し、各態様および対応する実行可能な実施態様によって得られる有益な効果は同様であり、再び詳細に説明されないことを理解されたい。

本願の実施形態による、車両のアップグレードパッケージを処理するための方法が適用されるネットワークシステムの概略図である。 本願の実施形態による、車両のアップグレードパッケージを処理するための方法の概略的な流れ図である。 本願の実施形態による、車両のアップグレードパッケージを処理するための方法が適用される別のネットワークシステムの概略図である。 本願の実施形態による、車両における車載装置の論理的枠組みの概略図である。 本願の実施形態による、車両のアップグレードパッケージを処理するための具体的な方法の概略的な流れ図である。 本願の実施形態による、車両のアップグレードパッケージを処理するための方法が適用されるさらに別のネットワークシステムの概略図である。 本願の実施形態による、車両のアップグレードパッケージを処理するための別の具体的な方法の概略的な流れ図である。 本願の実施形態による、第1の端末の構造の概略図である。 本願の実施形態による、サーバの構造の概略図である。 本願の実施形態による、車両のアップグレードパッケージを処理するための装置のハードウェア構造の概略図である。

これ以降は添付の図面を参照しながら実施形態の実装を詳しく説明する。

本願の実施形態で提供される車両のアップグレードパッケージを処理するための方法は、図1のネットワークシステムに適用され得る。システムは、サーバ11、第1の端末121、および第2の端末122を含んでもよい。1つまたは複数の第2の端末122が存在する場合がある。

サーバ11は、車両のアップグレードパッケージを配信するように構成されたOTAサーバであってもよく、またはOTAサーバから車両のアップグレードパッケージを取得した車両団サーバ、または任意の他の可能なサーバであってもよい。これは、本願の実施形態で具体的に限定されない。第1の端末121は任意の形態の車両であってもよく、第1の端末121は任意の形態の車両補助装置（例えば、車両充電パイル）であってもよく、第1の端末121は携帯端末（例えば、携帯電話、タブレットコンピュータ、またはウェアラブルデバイス）であってもよい。これは、本願の実施形態で具体的に限定されない。第2の端末122は任意の形態の車両であってもよく、第2の端末122は任意の形態の車両補助装置（例えば、車両充電パイル）であってもよく、第2の端末122は携帯端末（例えば、携帯電話、タブレットコンピュータ、またはウェアラブルデバイス）であってもよい。これは、本願の実施形態で具体的に限定されない。第1の端末121および第2の端末122は、同種の装置であってもよい。例えば、第1の端末121および第2の端末122は、いずれも車両、車両補助装置、または携帯端末などである。あるいは、第1の端末121および第2の端末122は、異なる種類の装置であってもよい。例えば、第1の端末121は車両であり、第2の端末122は車両補助装置または携帯端末などである。これは、本願の実施形態で具体的に限定されない。サーバ11、第1の端末121、および第2の端末122が様々な特定のデバイスである場合に、車両のアップグレードパッケージを処理する方法は、後続の実施形態で詳細に説明される。ここでは詳細は説明されない。

第1の端末121および第2の端末122は各々、サーバ11との通信接続を確立する。例えば、第1の端末121および第2の端末122は、ハイパーテキスト転送プロトコル（hypertext transfer protocol、HTTP）またはハイパーテキスト転送プロトコルオーバーセキュアソケットレイヤ（hyper text transfer trotocol over secure socket layer、HTTPS）などのプロトコルを用いることにより、サーバ11との通信接続を各々確立してもよい。これは、本願の実施形態において限定されない。

P2P通信は、任意の形態の通信接続を介して、第1の端末121と第2の端末122との間で実行され得る。例えば、第1の端末121と第2の端末122との間では、ブルートゥース（登録商標）（bluetooth）伝送、キャリアレス通信（ultra wide band，UWB）、赤外線伝送などの無線伝送によって、P2P通信が実行され得る。

あるいは、P2P通信は、有線伝送を介して、第1の端末121と第2の端末122との間で実行され得る。これは、本願の実施形態で具体的に限定されない。

あるいは、P2P通信は、インデックスサーバに基づいて、第1の端末121と第2の端末122との間で実行され得る。インデックスサーバは、サーバ11であっても、他の任意のサーバであってもよい。例えば、インデックスサーバは、リソースリストを記憶することができる。リソースリストは、第1の端末121と、第1の端末121におけるリソース識別子との対応関係、および、第2の端末122と、第2の端末122におけるリソース識別子との対応関係を含む。第1の端末121がリソースを取得することを期待するとき、第1の端末121はインデックスサーバから各端末のリソースリストを取得し、リソースリストから、リソースの識別子を含む端末が第2の端末122であると判定する。この場合、第1の端末121は、さらに、有線通信または無線通信により、第2の端末122からリソースを取得し得る。

図2は、本願の実施形態による車両のアップグレードパッケージを処理するための方法の概略的な流れ図である。図2に示されるように、方法は以下のステップを含む。

ステップS101：第1の端末がサーバから1つまたは複数の第1のデータブロックを受信し、第1のデータブロックは車両のアップグレードに使用される。

本願のこの実施形態では、サーバは、OTAサーバであっても、OTAサーバ以外のサーバであってもよい。サーバがOTAサーバである場合、サーバは、車両のアップグレードのためのアップグレードパッケージを生成することができる。サーバがOTAサーバ以外のサーバである場合、サーバはまず、OTAサーバから車両のアップグレードのためのアップグレードパッケージを取得することができる。

サーバは、車両のアップグレードのための完全なアップグレードパッケージを複数のデータブロックに分割することができる。アップグレードパッケージに具体的に対応する装置に基づいて、各アップグレードパッケージは、装置の番号およびアップグレードパッケージシーケンス番号に対応することができることが理解されよう。ブロックの分割中、サーバは、アップグレードパッケージ内のデータブロックの位置などに基づいてデータブロックを識別することができ、その結果、データブロックは、複数のデータブロックの識別子に基づいてその後統合されて、完全なアップグレードパッケージを再び取得することができる。データブロックの具体的な識別方法および識別内容は、本願のこの実施形態では具体的に限定されない。実施形態では、データブロックは完全なデータパケットであってもよい。

例えば、特定の実装形態では、ブロックの分割によって取得された各データブロックのヘッダは、アップグレードパッケージiにおけるデータブロックのバージョン番号、アップグレードパッケージシーケンス番号i、装置の番号j、およびシーケンス番号kのうちの1つまたは複数を含むことができる。例えば、乗用車対象の自動車用電子制御ユニット（electronic control unit、ECU）は、現在、25から100種類程度存在する。したがって、通常、256種類以下のアップグレードパッケージがある。これに対応して、アップグレードパッケージシーケンス番号iの総数は256を超えない。アップグレードパッケージシーケンス番号iがデータブロック内の1バイトを占有することが指定され得る。それに対応して、通常、256種類以下の車両がまた存在する。したがって、装置番号（例えば、車両のECU番号）jも1バイトを占有し得る。アップグレードパッケージi内のデータブロックのシーケンス番号kは、アップグレードパッケージのサイズおよびアップグレード方法に関連する。例えば、より大きいアップグレードパッケージが、より大きいシーケンス番号kを示す。または、差分アップグレード方式が使用される場合、kはより小さく、または完全なパッケージアップグレード方式が使用される場合、kはより大きい。例えば、kは1～3バイトを占有することができる。これは本願のこの実施形態で具体的に限定されない。

複数のデータブロックを取得した後、サーバは、複数のデータブロックを複数の端末に配信することができる。本願のこの実施形態では、複数の端末のうちの第1の端末が実行主体として使用され、複数の端末のうちの第1の端末以外の端末が第2の端末である例を用いて、説明が提示されている。第1の端末および第2の端末は、代替的に、複数の端末以外の端末であってもよい。第1の端末によって受信されるデータブロックは第1のデータブロックであり、1つまたは複数の第1のデータブロックが存在し得る。第2の端末によって受信されるデータブロックは第2のデータブロックであり、1つまたは複数の第2のデータブロックが存在し得る。すべての第1のデータブロックおよびすべての第2のデータブロックは、完全なアップグレードパッケージを形成することができる。確かに、例えば、冗長な情報関連のカプセル化が実行される場合があり得、また、完全なアップグレードパッケージは、いくつかのデータパケットが解析されるときに形成され得る。あるいは、本明細書での第1のデータブロックはデータブロックの1つのタイプであってもよく、第2のデータブロックは別のタイプのデータブロックである。異なる種類のデータブロックの伝送経路は異なっていてもよい。例えば、異なる種類のデータブロックは、異なる装置を通過した後に、宛先側に到達する。

任意選択で、特定の実施態様では、第1の端末は、アップグレード要求をサーバに送信することができる。アップグレード要求は、第1の端末の基本情報を含むことができ、基本情報は、ソフトウェアの情報および／またはハードウェアの情報または車両モデル（例えば、車両の固有の識別子（vehicle identification number，VIN））を含むことができる。アップグレード要求に応答して、サーバは、アップグレード要求における基本情報と一致する1つまたは複数の第1のデータブロックを第1の端末に送信することができる。アップグレード要求を送信する前に、第1の端末は、アップグレードの通知をさらに受信することができる。アップグレード要求の送信をトリガするための様々な条件があり得る。例えば、アップグレード要求の送信は、第1の端末で指定されたタイミングの瞬間に基づいてトリガされ、アップグレード要求の送信は、ユーザが第1の端末の車載インフォテインメント（in vehicle Infotainment，IVI）システムの画面上でアップグレードの制御をタップしたときにトリガされ、アップグレード要求の送信は、第1の端末と通信する携帯電話などのモバイル装置におけるアプリケーションを使用することによってトリガされるか、または、第1の端末のネットワーク環境がアップグレード要件（サイレントアップグレードとも呼ばれる）を満たすときに、アップグレードの要求が自動的に送信される。

任意選択で、ステップS101が行われる前に、セキュアな通信を確立するために第1の端末とサーバとの間で双方向認証が行われてもよい。例えば、公開鍵インフラストラクチャ（public key infrastructure、PKI）を使用することによって、第1の端末とサーバとの間で、双方向認証を実行することができる。例えば、第1の端末は、第1の端末によるサーバの認証を実施するために、PKIにおけるサーバのデジタル証明書をチェックすることができ、また、サーバは、サーバによる第1の端末に対する認証を実施するために、PKIにおいて第1の端末のデジタル証明書をチェックすることができる。双方向の認証は、実際の適用シナリオに基づいて別の方法で第1の端末とサーバとの間で代替的に実行されてもよいことが理解されよう。これは本願のこの実施形態で具体的に限定されない。

ステップS102：第1の端末は第2の端末から1つまたは複数の第2のデータブロックを取得し、第2のデータブロックは車両のアップグレードのために使用され、第2のデータブロックはサーバによって第2の端末に送信される。

本願のこの実施形態では、第1の端末は、上述した任意のP2P方式で、第2の端末から1つまたは複数の第2のデータブロックを取得することができる。1つまたは複数の第2の端末が存在する場合がある。本願のこの実施形態では、第2の端末の数は限定されない。例えば、1つの第2の端末がある場合、第1の端末は1つの第2の端末から1つまたは複数の第2のデータブロックを取得する。複数の第2の端末が存在する場合、第1の端末は、1つまたは複数の第2の端末から1つまたは複数の第2のデータブロックを取得する。

本願のこの実施形態では、ステップS102およびステップS101の間のシーケンスは逆であってもよいことに留意していただきたい。具体的には、第1の端末は、まず、1つまたは複数の第1のデータブロックを取得し、次いで、1つまたは複数の第2のデータブロックを取得することができるか、または、第1の端末は、まず1つまたは複数の第2のデータブロックを取得し、次いで1つまたは複数の第1のデータブロックを取得することができる。これは本願のこの実施形態で具体的に限定されない。

任意選択で、サーバがデータブロックを複数の端末に配信するとき、サーバは、各データブロックと、データブロックを受信する端末との間の対応関係を記憶する。ステップS102の具体的な実施態様は以下の通りであり得る。第1の端末は、対応関係に基づいて第2の端末にデータブロック取得要求を送信し、第1の端末は、データブロック取得要求に応答して第2の端末によって返信された、少なくとも1つの第2のデータブロックを受信する。

本願のこの実施形態では、各データブロックは、1つのデータブロック識別子に一意に対応することができ、データブロック識別子は、番号または名前などの識別子であってもよい。各端末は、1つの端末識別子に一意に対応することができ、端末識別子は、端末の装置シリアル番号または端末の通信アドレスなどの識別子であってもよい。当然ながら、異なる端末について、端末によって使用される端末識別子の具体的な形態は異なり得る。異なるデータブロックの場合、データブロックによって使用されるデータブロック識別子は異なり得る。各データブロックについて、サーバは、データブロックの識別子と、データブロックを受信する端末の識別子との間の対応関係を格納することができる。この場合、第1の端末は、対応関係に基づいて、第1の端末によって受信されたデータブロック（例えば、1つまたは複数の第1のデータブロック）、第1の端末についてまだ欠落しているデータブロック（例えば、1つまたは複数の第2のデータブロック）、および第1の端末について欠落しているデータブロックに関連付けられた第2の端末の識別子を判定することができる。さらに、第1の端末は、第2の端末の識別子に基づいて第2の端末にデータ取得要求を送信し、第2の端末によって返信された1つまたは複数の第2のデータブロックを受信することができる。例えば、複数の第2の端末が存在する場合、第1の端末は、対応関係に基づいて各第2の端末にデータブロック取得要求を送信し、第2の端末によって返信された1つまたは複数の第2のデータブロックを受信することができる。あるいは、サーバは、データブロックが欠落していないことを保証するために、またはデータブロックが通常のアップグレード条件を満たすことができることを保証するために、単純な技術的検証方法または別の検証方法を使用することができる。

任意選択で、ステップS102が実行される前に、セキュアな通信を確立するために第1の端末と第2の端末との間で双方向認証が行われてもよい。例えば、PKIを用いることにより第1の端末と第2の端末との間で双方向認証を行うことができる。例えば、第1の端末は、第1の端末による第2の端末に対する認証を実施するために、PKIにおいて第2の端末のデジタル証明書をチェックすることができ、第2の端末は、第2の端末による第1の端末に対する認証を実施するために、PKIにおいて第1の端末のデジタル証明書をチェックすることができる。双方向の認証は、実際の適用シナリオに基づいて別の方法で第1の端末と第2の端末との間で代替的に実行されてもよいことが理解されよう。これは本願のこの実施形態で具体的に限定されない。

ステップS103：第1の端末は、第1のデータブロックおよび第2のデータブロックに基づいて、車両のアップグレードパッケージを取得する。

本願のこの実施形態では、すべての第2のデータブロックを取得した後、第1の端末は、車両のアップグレードパッケージを取得するために、第2のデータブロックの識別子および第1のデータブロックの識別子に基づくデータブロック配置シーケンスなどに従って、第1のデータブロックおよび第2のデータブロックを統合することができる。

本願のこの実施形態では、車両のアップグレードパッケージは、車両の単一のコンポーネントのシステム（またはソフトウェア）をアップグレードするためのアップグレードパッケージであってもよく、または車両内の複数のコンポーネントまたはすべてのコンポーネントのシステム（またはソフトウェア）をアップグレードするためのアップグレードパッケージであってもよい。これは本願のこの実施形態で具体的に限定されない。

結論として、本願のこの実施形態では、サーバは、車両のアップグレードパケットを複数のデータブロックに分割し、次いで、複数のデータブロックを複数の端末に配信することができる。次いで、端末は、P2P方式で別の端末からデータブロックを取得し、端末によって受信されたデータブロックと、端末によって別の端末から取得されたデータブロックとに基づいて、車両のアップグレードパッケージを取得することができる。このプロセスでは、端末のいずれも、OTAサーバから車両の完全なアップグレードパッケージを取得する必要はない。したがって、OTAサーバの負荷を低減することができる。

任意選択で、第1のデータブロックと第2のデータブロックの両方は、暗号化されたデータブロックであってもよい。

本願のこの実施形態では、車両のアップグレードパッケージをブロックに分割するとき、サーバは、車両のアップグレードパッケージを最初に暗号化し、次いで、車両の暗号化されたアップグレードパッケージを、暗号化された第1のデータブロックと、暗号化された第2のデータブロックとに分割することができる。あるいは、車両のアップグレードパッケージをブロックに分割するとき、サーバは、まず、車両のアップグレードパッケージを1つまたは複数の第1のデータブロックおよび1つまたは複数の第2のデータブロックに分割し、次いで、各第1のデータブロックおよび各第2のデータブロックを暗号化することができる。暗号化の具体的な実装は、本願のこの実施形態では具体的に限定されない。データブロックの完全性を保証するために、第1のデータブロックおよび第2のデータブロックは、それぞれ端末に格納されてもよく、または端末、例えば第1の端末および／または第2の端末において、集中的に格納されてもよい。あるいは、第1のデータブロックおよび第2のデータブロックに含まれる情報は、それぞれ端末に格納されてもよく、または端末、例えば第1の端末および／または第2の端末に、集中的に格納されてもよい。

本願のこの実施形態では、暗号化されたデータブロックを取得するためにサーバによって使用される暗号化アルゴリズムは、対称的な暗号化アルゴリズムであってもよく、または非対称的な暗号化アルゴリズムまたは任意の他の暗号化アルゴリズムであってもよい。暗号化アルゴリズムは、本願のこの実施形態では具体的に限定されない。異なる暗号化方法を使用することによる暗号化によって取得されたデータブロックの場合、暗号化アルゴリズムの識別子は、データブロック内で搬送され得ることが理解され得る。解読中、暗号化アルゴリズムの識別子に基づいて、対応する解読アルゴリズムを使用することができる。これは本願のこの実施形態では具体的に限定されはしない。

本願のこの実施形態では、第1のデータブロックおよび第2のデータブロックを暗号化することによって、認可されていないユーザがアップグレードパケットを取得することを防止することができ、分割によって取得されたデータブロックの送信プロセスの機密性を保証することができる。これにより、OTAnアップグレードパケットの高速送信を保証しながら、OTAデータパケットの送信セキュリティをさらに保証することができる。

本願のこの実施形態の任意選択の実装形態では、第1のデータブロックのデータブロック長、および少なくとも1つの第2のデータブロックのデータブロック長、それぞれ、対称的な暗号化アルゴリズムのパケットの長さの整数倍である。

本願のこの実施形態では、対称的な暗号化アルゴリズムに入力される車両のアップグレードパケットの長さは、暗号化アルゴリズムのパケットの長さの整数倍であり得る。例えば、パケットの長さは、8バイト、16バイト、または128バイトであってもよい。しかしながら、車両のアップグレードパッケージの長さは通常ランダムであり、パケットの長さの整数倍でなくてもよい。したがって、車両のアップグレードパッケージの全長がパケットの長さの整数倍になるように、車両のアップグレードパッケージに、パディング部を追加することができる。さらに、車両のアップグレードパッケージは、長さが暗号化アルゴリズムのパケットの長さの整数倍である複数のデータブロックに分割される。例えば、パケットの長さが128バイトである場合、第1のデータブロックと第2のデータブロックの両方の長さは128＊nとすることができ、式中nは自然数である。

本願のこの実施形態では、車両のアップグレードパケットを、その長さがパケットの長さの整数倍であるデータブロックに分割することによって、カプセル解除器が被暗号化パケットの処理中に解読におけるパケットの統合のための時間をさらに消費しないことを保証することができる。これは、タイミング攻撃に効果的に抵抗し、それによって被暗号化パケットの機密の保護および完全性の保護を保証する。

任意選択の実施態様では、第1の端末がOTAサーバに接続されているとき、第1の端末は、OTAサーバから、第1のデータブロックおよび第2のデータブロックのパケットの長さ、データブロックを暗号化するための鍵、ならびに鍵の有効時間を取得することができる。この場合、第1の端末は、鍵に基づいて鍵の有効時間内に第1のデータブロックおよび第2のデータブロックを解読することができる。

任意選択で、第1のデータブロックのデータブロック長、および少なくとも1つの第2のデータブロックのデータブロック長が、それぞれ暗号化アルゴリズムのパケットの長さの整数倍である場合、第1の端末によって第1のデータブロックおよび第2のデータブロックを解読する方法は、以下の通りであってもよい。

第1の端末がデータブロック（第1のデータブロックまたは第2のデータブロックを含む）を受信するたびに、第1の端末は受信されたデータブロックを直ちに解読する。この場合、第1の端末が最後のデータブロックを受信するとき、第1の端末は、以前に受信されたデータブロックの解読を完了している可能性がある。したがって、第1の端末は、すべてのデータブロックの解読を完了するために、最後のデータブロックを解読する時間待つ必要だけがある。言い換えれば、本願のこの実施形態では、第1の端末は、データブロックを受信しながらデータブロックを解読する。したがって、すべてのデータブロックを受信した後に第1の端末がすべてのデータブロックを一緒に解読する方法と比較されると、本願のこの実施形態における方法は、解読効率を改善し、アップグレードパッケージのダウンロード時間を短縮することができる。

第1の端末は、代替として、すべてのデータブロックを受信した後、すべてのデータブロック（第1のデータブロックまたは第2のデータブロックを含む）を一緒に解読してもよいことが理解され得る。これは本願のこの実施形態で具体的に限定されない。

任意選択で、第1のデータブロックおよび第2のデータブロックは各々、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名を含む。例えば、車両システムをアップグレードするために完全なアップグレードパッケージに対してブロックの分割を実行する前に、OTAサーバは、アップグレードパッケージに署名するか、または公開鍵暗号に基づいてアップグレードパッケージのコンテンツにデジタル署名することができる。署名は、OTAサーバに対応する識別子であってもよい。例えば、署名は、OTAサーバの装置識別子またはOTAサーバを操作するオペレータの識別子であってもよい。あるいは、署名は、車両提供者の識別子などを含んでもよい。加えて、ブロックの分割中に、署名が第1のデータブロックおよび第2のデータブロックに追加される。このようにして、第1のデータブロックおよび第2のデータブロックを取得するとき、第1の端末は、第1のデータブロックおよび第2のデータブロックで搬送された署名に基づいて、第1のデータブロックおよび第2のデータブロックが第1の端末によって許可されたOTAサーバによって送信されたかどうかを判定することができる。第1のデータブロックおよび第2のデータブロックで搬送された署名がOTAサーバの署名ではない場合、第1のデータブロックおよび第2のデータブロックは破棄されてもよく、OTAサーバの署名を含む第1のデータブロックおよび第2のデータブロックが再取得されてもよいことが理解されよう。このようにして、第1の端末は、別の装置によって送信された安全でないデータブロックを受信することが防止され、それによってデータブロック送信のセキュリティが向上する。

これに応じて、第1のデータブロックおよび第2のデータブロックは各々、車両のアップグレードのためのアップグレードパッケージを生成するサーバの署名を含む。第1の端末は、第1のデータブロック内の署名が車両のアップグレードパッケージをダウンロードするためのサーバの署名であることを第1の端末が確認したときに第1の時間に第1のデータブロックの解読を開始し、第2の時間に第2のデータブロックを受信し、第1の時間は第2の時間よりも早いか、または、第1の端末は、第2のデータブロック内の署名が車両のアップグレードパッケージをダウンロードするためのサーバの署名であることを第1の端末が確認したときに第3の時間に第2のデータブロックの解読を開始し、第4の時間に第1のデータブロックを受信し、第3の時間が第4の時間よりも早い。

例えば、図3は、本願の実施形態による、車両のアップグレードパッケージを処理するための方法が適用され得る具体的なアップグレードシステムを示す。図3に示すように、アップグレードシステムは、サーバ30と、第1の端末31と、第2の端末32とを含む。3個の第2の端末32があり、それぞれ第2の端末320、第2の端末321、および第2の端末322として番号付けされている。

本願のこの実施形態では、サーバ30はOTAサーバであり得る。あるいは、サーバ30はプロキシサーバであってもよい。例えば、プロキシサーバは、車両団にサービス提供するサーバであってもよい。サーバ30がプロキシサーバである場合、プロキシサーバは、最初に双方向認証を介してOTAサーバとのセキュアな通信を確立し、次いで、プロキシサーバは車両のハードウェアおよびソフトウェアの情報をOTAサーバに送信する。車両のアップグレードパッケージを生成した後、OTAサーバは、車両のアップグレードパッケージを、プロキシサーバに配信することができる。OTAサーバは、代替として、車両のアップグレードパッケージをブロックに分割し、ブロックを複数のプロキシサーバに配信し、また複数のプロキシサーバは、前述のP2P方式で車両のアップグレードパッケージを取得することができるということが理解されよう。これは本願のこの実施形態で具体的に限定されない。

本願のこの実施形態では、第1の端末と第2の端末の両方が車両であってもよい。図4は、車両における車載装置の論理的な枠組みの模式図である。図4の車載装置は、車両に含まれる車載装置の全部または一部であってもよいことが理解できる。これらの車載装置は、いくつかのドメインにグループ化されてもよく、各ドメインは1つ以上の車載装置を含み、各ドメインはドメインアドミニストレータを含み、ドメインアドミニストレータはまた、ドメインコントローラと呼ばれ得る。例えば、モバイルデータセンタ（mobile data center、MDC）、1つまたは複数のセンサ（sensor）、および全地球測位システム（global positioning system、GPS）はドメインに属し、MDCはドメイン内のドメインコントローラである。車両制御ユニット（vehicle control unit、VCU）、1つまたは複数の電子制御ユニット（electronic control unit、ECU）、無線電力伝送（wireless power transmission、WPT）装置などが、ドメインに属し、VCUはドメイン内のドメインコントローラである。ヒューマンマシンインターフェイス（human machine interface、HMI）および1つまたは複数のECUがドメインに属し、HMIはドメイン内のドメインコントローラである。車体制御モジュール（body control module、BCM）、1つまたは複数のECU、パッシブ・エントリ・パッシブ・スタート（passive entry passive start、PEPS）などがドメインに属し、BCMはドメイン内のドメインコントローラである。ドメインコントローラは、ゲートウェイ（gateway、GW）に接続され、ゲートウェイは、車載診断（on-board diagnostics、OBD）システム、車両のインターネットにおける車両通信端末（telematics box，T-Box）、および別の装置に接続される。例えば、ドメインコントローラは、ゲートウェイを介してT-Boxなどの装置と通信することができ、ドメイン内装置は、ドメインコントローラを介してゲートウェイなどの装置と通信することができる。

任意選択の実施態様では、車両は、T-Boxを使用することによって車両のアップグレードパッケージをダウンロードし、車両のアップグレードパッケージのソースを決定し、また、車両のアップグレードパッケージがOTAサーバによって配信されたと判定した後、車両は、アップグレードパッケージに対応する装置の番号に基づいて、車両のアップグレードパッケージを車両内の対応する車載装置に転送することができる。比較的強力なコンピューティングおよび記憶能力を有する車載装置（例えば、MDCまたはHMI）は、それ自体パッケージングを実行することができ、その結果、T-Boxの記憶リソースの消費を低減することができる。パッケージングを実行した後、車両内の車載コンポーネントは、アップグレードパッケージに対する署名の検証をさらに実行し、車両のアップグレードパッケージがOTAサーバによって配信されたと判定した後に、アップグレードインストールなどの動作を実行することができる。これにより、アップグレードパッケージの信頼性を向上させることができる。

本願のこの実施形態では、第1の端末が第1の車両であり、第2の端末が第2の車両である例が使用される。図5に示すように、車両のアップグレードパッケージを処理するための方法の任意選択の具体的な実行ステップは、以下の通りであり得る。

ステップS301：第1の車両はサーバから1つまたは複数の第1のデータブロックを取得し、第2の車両はサーバから1つまたは複数の第2のデータブロックを取得する。

ステップS302：第1の車両は、第2の車両から1つまたは複数の第2のデータブロックを取得する。

ステップS303：第1の車両は、取得された第1のデータブロックおよび取得された第2のデータブロックに基づいて、車両のアップグレードパッケージを取得する。

本願のこの実施形態では、サーバによって車両のアップグレードパッケージをブロックに分割する方法、および第1の車両によって第1のデータブロックおよび第2のデータブロックを取得する方法について、図2に対応する実施形態の説明を参照されたい。ここでは詳細は繰り返されない。

本願のこの実施形態における任意選択の適用シナリオでは、図3に示すように、サーバ30は、車両団サーバであり、車両団サーバは、OTAサーバから、車両団サーバによってサービス提供される車両団（例えば、第1の車両31、第2の車両320、第2の車両321、および第2の車両322を含む）によって使用される、車両のアップグレードパッケージを事前に取得する。さらに、車両団の定期的なメンテナンス中に、ワイヤレスフィデリティ（Wireless-Fidelity、Wi-Fi）ネットワーク接続などの場合、第1の車両31、第2の車両320、第2の車両321、および第2の車両322は、車両団サーバに接続される。アップグレードパッケージダウンロード通知を受信するとき、車両団サーバは、第1の車両31、第2の車両320、第2の車両321、および第2の車両322との双方向認証（例えば、PKIベースの認証方式）を実行し、また、認証に成功した後、アップグレードパッケージの暗号鍵kを暗号化し（車両の公開鍵を使用することによって、アップグレードパッケージの暗号鍵kを暗号化し）、次いで、暗号化された暗号鍵を第1の車両31、第2の車両320、第2の車両321、および第2の車両322に配信する。例えば、第1の車両31が車両のアップグレードパッケージの第1の部分をダウンロードし、第2の車両320が車両のアップグレードパッケージの第2の部分をダウンロードし、第2の車両321が車両のアップグレードパッケージの第3の部分をダウンロードした場合、第1の車両31は、第2の車両320から車両のアップグレードパッケージの第2の部分をダウンロードし、第2の車両321から車両のアップグレードパッケージの第3の部分をダウンロードし、鍵kを使用することによる解読を通じて車両の完全なアップグレードパッケージをさらに取得することができる。

第2の車両320はまた、第1の車両31および第2の車両321から車両の完全なアップグレードパッケージを取得してもよく、第2の車両321はまた、第1の車両31および第2の車両320から車両の完全なアップグレードパッケージを取得してもよいことが、理解されよう。

この場合、第1の車両31、第2の車両320、または第2の車両321が車両の完全なアップグレードパッケージを取得した後、第2の車両322は、第1の車両31、第2の車両320、または第2の車両321から車両のアップグレードパッケージを取得することができる。各車両が車両のアップグレードパッケージをダウンロードする具体的なプロセスは、本願のこの実施形態では限定されない。

本願のこの実施形態では、車両団サーバはプロキシサーバとして使用され、その結果、車両は、メンテナンスまたは別のプロセスの間に、便利な車両のアップグレードを実施することができる。

任意選択で、車両のアップグレードパッケージの安定性をさらに改善し、車両の誤ったアップグレードパッケージが複数の車両に配信されるのを防止するために、ステップS301が実行される前に、車両のアップグレードパッケージに対して性能試験が実行されてもよい。例えば、車両Aを使用することによって、サーバ30から車両のアップグレードパッケージを最初に取得することができ、次いで車両Aは車両のアップグレードパッケージに基づいて更新を実行する。更新が成功した場合、車両Aはサーバ30に更新成功メッセージを送信し、また、その後、ステップS301と後続のステップが、さらに実行される。このことが、車両のアップグレードに成功する確率を高めることができる。

例えば、図6は、本願の実施形態による、車両のアップグレードパッケージを処理するための方法が適用され得る具体的なアップグレードシステムを示す。図6に示すように、アップグレードシステムは、サーバ60と、第1の端末61と、第2の端末62とを備える。3個の第2の端末62があり、それぞれ第2の端末620、第2の端末621、および第2の端末622として番号付けされている。

本願のこの実施形態では、サーバ60はOTAサーバであり得る。あるいは、サーバ60はプロキシサーバであってもよい。サーバ60がプロキシサーバである場合、プロキシサーバは、双方向認証を介してOTAサーバとのセキュアな通信を最初に確立することができ、次いで、プロキシサーバは、車両補助装置によってサービス提供される車両のハードウェアおよびソフトウェアの情報を、OTAサーバに送信する。車両のアップグレードパッケージを生成した後、OTAサーバは、車両のアップグレードパッケージを、プロキシサーバに配信することができる。OTAサーバは、代替として、車両のアップグレードパッケージをブロックに分割し、ブロックを複数のプロキシサーバに配信し、また複数のプロキシサーバは、前述のP2P方式で車両のアップグレードパッケージを取得することができるということが理解されよう。これは本願のこの実施形態で具体的に限定されない。

本願のこの実施形態では、第1の端末が第1の車両補助装置であり、第2の端末が第2の車両補助装置である例が使用される。第2の車両補助装置は、車両充電用の装置（例えば、充電パイル）、携帯端末などであってもよい。図7に示すように、車両のアップグレードパッケージを処理するための方法の任意選択の具体的な実行ステップは、以下の通りであり得る。

ステップS701：第1の車両補助装置はサーバから1つまたは複数の第1のデータブロックを取得し、第2の車両補助装置はサーバから1つまたは複数の第2のデータブロックを取得する。

ステップS702：第1の車両補助装置は、第2の車両補助装置から1つまたは複数の第2のデータブロックを取得する。

ステップS703：第1の車両補助装置は、取得された第1のデータブロックおよび取得された第2のデータブロックに基づいて、車両のアップグレードパッケージを取得する。

本願のこの実施形態では、サーバによって車両のアップグレードパッケージをブロックに分割する方法、および第1の車両補助装置によって第1のデータブロックおよび第2のデータブロックを取得する方法について、図2に対応する実施形態の説明を参照されたい。ここでは詳細は繰り返されない。

本願のこの実施形態における任意選択の適用シナリオでは、図6に示すように、サーバ60はOTAサーバである。OTAサーバは、車両のアップグレードパッケージを生成し、車両のアップグレードパッケージがダウンロードされる必要があることを第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、および第2の車両補助装置622に、さらに通知する。OTAサーバは、第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、および第2の車両補助装置622と双方向認証（例えば、PKIベースの認証方式）を行い、また、認証に成功した後、鍵kを用いることによって暗号化されたデータブロックを、第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、および第2の車両補助装置622に配信する。例えば、第1の車両補助装置61が車両のアップグレードパッケージの第1の部分をダウンロードし、第2の車両補助装置620が車両のアップグレードパッケージの第2の部分をダウンロードし、第2の車両補助装置621が車両のアップグレードパッケージの第3の部分をダウンロードした場合、第1の車両補助装置61は、第2の車両補助装置620から車両のアップグレードパッケージの第2の部分をダウンロードし、第2の車両補助装置621から車両のアップグレードパッケージの第3の部分をダウンロードし、鍵kを使用することによる解読を通じて車両の完全なアップグレードパッケージをさらに取得することができる。

第2の車両補助装置620はまた、第1の車両補助装置61および第2の車両補助装置621から車両の完全なアップグレードパッケージを取得してもよく、第2の車両補助装置621はまた、第1の車両補助装置61および第2の車両補助装置620から車両の完全なアップグレードパッケージを取得してもよいことが、理解されよう。

この場合、第1の車両補助装置61、第2の車両補助装置620、または第2の車両補助装置621が車両の完全なアップグレードパッケージを取得した後、第2の車両補助装置622は、第1の車両補助装置61、第2の車両補助装置620、または第2の車両補助装置621から車両のアップグレードパッケージを取得することができる。各車両補助装置が車両のアップグレードパッケージをダウンロードする具体的なプロセスは、本願のこの実施形態では限定されない。

本願のこの実施形態では、例えば、アップグレードの通知を受信した後、車両63は、車両のアップグレードパッケージの暗号鍵kを取得するためにOTAサーバへの接続を確立することができる。第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、または第2の車両補助装置622を使用することによって車両63が充電されているとき、第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、または第2の車両補助装置622は、車両によって送信されたアップグレードパッケージ取得要求を受信し、車両との双方向認証を実行することができる。次いで、第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、または第2の車両補助装置622は、車両の暗号化されたアップグレードパッケージを車両に送信することができる。車両63は、鍵kを使用することによって車両の暗号化されたアップグレードパッケージを解読して、車両のアップグレードパッケージを取得する。このようにして、車両63は、充電中に車両のアップグレードパッケージをダウンロードすることができる。車両の充電中、車両は通常、静止状態にあるため、通常は比較的良好なネットワーク環境があり得ること、また車両が充電補助装置に接続されているため、車両の電力不足に起因する車両のアップグレードパッケージのダウンロード中断などの現象を回避することができることが理解できる。したがって、車両のアップグレードのユーザ体験が効果的に改善され得る。

任意選択で、車両のアップグレードパッケージの安定性をさらに改善し、車両の誤ったアップグレードパッケージが複数の車両に配信されるのを防止するために、ステップS701が実行される前に、車両のアップグレードパッケージに対して正当性試験が実行されてもよい。例えば、車両のアップグレードパッケージは、最初に、車両Aを使用することによって、第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、または第2の車両補助装置622から取得することができ、次いで、車両Aは、車両のアップグレードパッケージに基づいて更新を実行する。更新が成功した場合、車両Aは、第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、または第2の車両補助装置622に更新成功メッセージを送信し、その後、ステップS701と後続のステップがさらに実行される。これにより、車載システムのアップグレードに成功する確率を高めることができる。

図8は、本願の実施形態による第1の端末の構造の概略図である。第1の端末は、受信モジュール801および処理モジュール802を含む。受信モジュールは、サーバから1つまたは複数の第1のデータブロックを受信するように構成され、第1のデータブロックは車両のアップグレードのために使用される。処理モジュールは、第1の端末によって、第2の端末から1つまたは複数の第2のデータブロックを取得し、第2のデータブロックが車載システムをアップグレードするために使用され、第2のデータブロックがサーバによって第2の端末に送信され、また第1のデータブロックおよび第2のデータブロックに基づいて車両のアップグレードパッケージを取得するようにさらに構成される。

可能な設計では、第1のデータブロックと第2のデータブロックの両方が暗号化されたデータブロックであり、第1のデータブロックのデータブロック長、および少なくとも1つの第2のデータブロックのデータブロック長はそれぞれ、暗号化アルゴリズムのパケットの長さの整数倍である。

可能な設計では、処理モジュールは、具体的には、第1の時間に第1のデータブロックの解読を開始し、第2の時間に第2のデータブロックを受信するように構成され、第1の時間は第2の時間よりも早いか、または、第3の時間に第2のデータブロックの解読を開始し、第4の時間に第1のデータブロックを受信するように構成され、第3の時間は第4の時間よりも早い。

可能な設計では、第1のデータブロックおよび第2のデータブロックは各々、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名を含み、処理モジュールは、具体的には、第1のデータブロック内の署名が、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名であることを確認したときに、第1の時間に第1のデータブロックの解読を開始するようにさらに構成され、第2のデータブロック内の署名が、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名であることを確認したときに、第3の時間に第2のデータブロックの解読を開始するように構成される。

可能な設計では、サーバは、車両のアップグレードパッケージの分割によって取得されたデータブロックとデータブロックを受信する端末との間の対応関係を記憶し、処理モジュールは、具体的には、対応関係に基づいて、第2の端末にデータブロック取得要求を送信し、データブロック取得要求に応答して第2の端末によって返信された1つまたは複数の第2のデータブロックを受信するようにさらに構成される。

可能な設計では、サーバはプロキシサーバであり、車両のアップグレードパッケージは、プロキシサーバによって無線OTAサーバから取得され、第1の端末は車両である。

可能な設計では、第1の端末は充電パイルである。

可能な設計では、受信モジュールは、車両によって送信されたアップグレードパッケージ取得要求を受信するようにさらに構成され、また処理モジュールは、車両が充電パイルの安全検証に成功したときに、アップグレードパッケージ取得要求に基づいて車両のアップグレードパッケージを車両に返信するようにさらに構成される。

可能な設計では、受信モジュールは、具体的には、第1の端末がサーバとのセキュリティ認証に成功したときに、第1の端末によって、サーバから第1のデータブロックを受信するように構成される。

この実施形態の装置は、前述の方法の実施形態において第1の端末によって実行されるステップを実行するように、相応して構成され得る。実装の原理および装置の技術的効果は、前述の方法のものと同様であり、詳細はここでは再度説明されない。

図9は、本願の実施形態による第1の端末の構造の概略図である。第1の端末は、処理モジュール901および送信モジュール902を含む。処理モジュールは、車両のアップグレードパッケージを複数のデータブロックに分割するように構成される。送信モジュールは、複数のデータブロックを少なくとも1つの端末に配信するように構成され、各端末は、端末によって受信されたデータブロックと、少なくとも1つの端末の別の端末からのデータブロックとに基づいて、車両のアップグレードパッケージを取得するように構成される。

可能な設計では、処理モジュールは、具体的には、暗号化アルゴリズムに従って車両のアップグレードパッケージを暗号化し、車両の暗号化されたアップグレードパッケージを複数のデータブロックに分割するように構成される。

可能な設計では、サーバはプロキシサーバであり、処理モジュールは、無線OTAサーバから車両のアップグレードパッケージを取得するようにさらに構成される。

可能な設計では、処理モジュールは、具体的には、車両のアップグレードパッケージ取得要求を無線OTAサーバに送信し、車両のアップグレードパッケージ取得要求は、オペレーティングシステムの種類および車両のバージョンを含み、プロキシサーバがOTAサーバとのセキュリティ検証に成功したときに、OTAサーバによって送信された車両のアップグレードパッケージを受信し、車両のアップグレードパッケージは、オペレーティングシステムの種類および車両のバージョンに基づいてOTAサーバによって生成されるように構成される。

可能な設計では、処理モジュールは、車両のアップグレードパッケージの分割によって取得されたデータブロックと、データブロックを受信する端末との間の対応関係を記録するようにさらに構成される。

この実施形態の装置は、前述の方法の実施形態においてサーバによって実行されるステップを実行するように、相応して構成され得る。実装の原理および装置の技術的効果は、前述の方法のものと同様であり、詳細はここでは再度説明されない。

図10は、本願による車両のアップグレードパッケージを処理するための装置のハードウェア構造の概略図である。図10を参照されたい。車両のアップグレードパッケージを処理するための装置は、メモリ1001、プロセッサ1002、および通信インターフェイス1003を含む。メモリ1001、プロセッサ1002、および通信インターフェイス1003は、相互に通信できる。例えば、メモリ1001、プロセッサ1002、および通信インターフェイス1003は、通信バス1004を用いることによって、相互に通信できる。メモリ1001は、コンピュータプログラムを記憶するように構成される。プロセッサ1002は、コンピュータプログラムを実行して、前述の方法の実施形態において説明された方法を実行する。

任意選択で、通信インターフェイス1003は、送信機および／または受信機をさらに含んでもよい。

任意選択的に、プロセッサは、中央処理装置（central processing unit，CPU）であってもよく、または別の汎用プロセッサ、デジタル信号プロセッサ（digital signal processor，DSP）、特定用途向け集積回路（application specific integrated circuit，ASIC）などであってもよい。汎用プロセッサはマクロプロセッサであってよいし、このプロセッサは任意の従来のプロセッサなどであってよい。本願を参照して開示された方法のステップは、ハードウェアプロセッサによって直接実装されてもよく、またはハードウェアとプロセッサ内のソフトウェアモジュールの組み合わせによって実装されてもよい。

本願はコンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、コンピュータプログラムを記憶するように構成され、コンピュータプログラムは、上記の方法の実施形態において記載された方法を実施するために使用される。

本願は、図8に示す第1の端末および図9に示すサーバを含む通信システムをさらに提供する。

本願は、システムチップを提供する。システムチップは、本願の実施形態で説明される機能（例えば、第1の端末はサーバから1つまたは複数の第1のデータブロックを受信し、第1のデータブロックは車両のアップグレードに使用され、第1の端末は第2の端末から1つまたは複数の第2のデータブロックを取得し、第2のデータブロックは車載システムをアップグレードするために使用され、第2のデータブロックはサーバによって第2の端末に送信され、第1の端末は、第1のデータブロックおよび第2のデータブロックに基づいて車両のアップグレードパッケージを取得する）を実行する際に通信装置をサポートするように構成される。チップが、具体的には、チップシステムで使用され、チップシステムはチップを含み得るか、またはチップと、別の分離した装置とを含み得る。前述の方法が、第1の装置のチップを使用して実行される場合、チップは処理ユニットを含む。さらに、チップは、通信ユニットをさらに含んでもよい。処理ユニットは、例えばプロセッサであってもよい。チップが通信ユニットを含む場合、通信ユニットは、例えば入力／出力インターフェイス、ピン、または回路であってもよい。処理ユニットは、本願の実施形態における各処理モジュールによって実行されるすべてまたはいくつかの動作を実行し、通信ユニットは、対応する受信または送信動作を実行することができる。別の特定の実施形態では、本願における受信装置の処理モジュールはチップの処理ユニットであってもよく、制御装置の受信モジュールまたは送信モジュールはチップの通信ユニットである。

この出願の実施形態は、この出願の実施形態による方法、装置（システム）、およびコンピュータプログラム製品のフローチャートおよび／またはブロック図に関連して説明される。コンピュータプログラム命令は、流れ図および／またはブロック図における各手順および／または各ブロック、ならびに流れ図および／またはブロック図における手順および／またはブロックの組み合わせを実現するために使用することができることを理解すべきである。これらのコンピュータプログラム命令は、マシンを生成するために汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、または任意の他のプログラマブルデータ処理装置の処理ユニットに与えられてよく、これにより、コンピュータまたは任意の他のプログラマブルデータ処理装置の処理ユニットによって実行される命令は、フローチャートの1つ以上のプロセスおよび／またはブロック図の1つ以上のブロックにおける特定の機能を実現するための装置を生成する。

これらのコンピュータプログラム命令はまた、具体的な方式で動作するようにコンピュータまたは別のプログラマブルデータ処理装置に指示することができるコンピュータ可読メモリに記憶されてよく、その結果、コンピュータ可読メモリに記憶された命令は、命令装置を含む人工物を生成する。命令装置は、フローチャートの1または複数の手順の、および／またはブロック図の1または複数のブロックの、特定の機能を実現する。

これらのコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理装置にロードされてよく、これにより、一連の動作およびステップがコンピュータまたは別のプログラマブル装置上で行われ、それによってコンピュータ実装処理が生成される。したがって、コンピュータまたは別のプログラマブル装置上で実行される命令は、流れ図における1つもしくは複数の手順および／またはブロック図における1つもしくは複数のブロックにおける特定の機能を実現するためのステップを提供する。

本願で提供されたいくつかの実施形態では、開示の装置および方法が他の方式で実装され得ることを理解されたい。例えば、記載された装置の実施形態は例に過ぎない。例えば、部位の区分は論理的な機能の区分にすぎず、実際に実施する際には他の区分であってもよい。例えば、複数のユニットや構成要素が別のシステムに組み合わせられるまたは組み込まれてもよいし、あるいは一部の機能が無視されるまたは実行されなくてもよい。加えて、提示されたまたは述べられた相互結合または直接的な結合もしくは通信接続は、いくつかのインターフェイスを介して実現されてもよい。装置またはユニット間の間接的な結合または通信接続は、電子的な、機械的な、または他の形態で実現されてもよい。

別々の部分として記載されたユニットは、物理的に分離されていてもいなくてもよく、ユニットとして表示された部分は物理ユニットであってもなくてもよく、1つの場所に配置されてもよく、または複数のネットワークユニットに分散されてもよい。ユニットの一部またはすべてが、実施形態の解決策の目的を達成するために、実際の要件に基づいて選択されてもよい。

加えて、本願の実施形態における機能ユニットが、1つの処理ユニットに統合されてもよく、またはユニットの各々が、物理的に単独で存在してもよく、または2つ以上のユニットが1つのユニットに統合される。統合ユニットは、ハードウェアの形態で実装されてもよく、またはハードウェア、さらにソフトウェア機能ユニットの形態で実装されてもよい。

前述の統合ユニットがソフトウェア機能ユニットの形態で実装されるとき、統合ユニットはコンピュータ可読記憶媒体に記憶される場合がある。ソフトウェア機能ユニットは記憶媒体に格納されており、コンピュータ装置（パーソナルコンピュータ、サーバ、またはネットワーク装置とすることができる）またはプロセッサ（processor）に、本願の各実施形態に記載されている方法のステップの一部を実行するよう命令するためのいくつかの命令を含む。前述の記憶媒体は、USBフラッシュドライブ、リムーバブルハードディスク、読み取り専用メモリ（read-only memory、ROM）、ランダムアクセスメモリ（random access memory、RAM）、磁気ディスク、または光ディスクなどの、プログラムコードを記憶することができる任意の媒体を含む。

11 サーバ
30 サーバ
31 第1の端末、第1の車両
32 第2の端末
60 サーバ
61 第1の車両補助装置、第1の端末
62 第2の端末
63 車両
121 第1の端末
122 第2の端末
320 第2の端末、第2の車両
321 第2の端末、第2の車両
322 第2の車両、第2の端末
620 第2の車両補助装置、第2の端末
621 第2の車両補助装置、第2の端末
622 第2の車両補助装置、第2の端末
801 受信モジュール
802 処理モジュール
901 処理モジュール
902 送信モジュール
1001 メモリ
1002 プロセッサ
1003 通信インターフェイス
1004 通信バス

本願は通信技術に関し、特に、車両のアップグレードパッケージを処理するための方法および装置に関する。

車両のインターネット技術の発展に伴い、ますます多くの車両が、ソフトウェア関連のオペレーティングシステムを設けられている。ソフトウェアの更新中、車両は、無線（over the air、OTA）サーバから、OTA技術に基づいて、車両のアップグレードパッケージをダウンロードし、車両のアップグレードパッケージを使用することによりソフトウェアの更新を実施することができる。

通常、車両がアップグレード要求を送信するたびに、OTAサーバは車両のアップグレード要求に応答し、車両のアップグレードパッケージを車両に配信する必要がある。

しかしながら、OTAサーバが各車両に車両のアップグレードパッケージを与える必要があるため、OTAサーバの負荷は比較的大きい。

本願の実施形態は、OTAサーバの負荷を低減するために、車両のアップグレードパッケージを処理するための方法および装置を提供する。

第1の態様によれば、本願の実施形態は、車両のアップグレードパッケージを処理するための方法を提供する。方法は、第1の端末がサーバから1つまたは複数の第1のデータブロックを受信し、第1のデータブロックは車両のアップグレードのために使用され、第1の端末は第2の端末から1つまたは複数の第2のデータブロックを取得し、第2のデータブロックは車載システムをアップグレードするために使用され、第2のデータブロックがサーバによって第2の端末に送信され、第1の端末は、第1のデータブロックおよび第2のデータブロックに基づいて車両のアップグレードパッケージを取得することを含む。具体的には、サーバは、車両のアップグレードパッケージを複数のデータブロックに分割し、次いで、複数のデータブロックを複数の端末に配信することができる。次いで、各端末は、端末によって受信されたデータブロックと、別の端末から端末によって取得されたデータブロックとに基づいて、ピアツーピア（peer to peer、P2P）方式で車両のアップグレードパッケージを取得することができる。このプロセスでは、端末のいずれも、OTAサーバから車両の完全なアップグレードパッケージを取得する必要はない。したがって、OTAサーバの負荷を低減することができる。

可能な設計では、第1のデータブロックと第2のデータブロックの両方が暗号化されたデータブロックであり、第1のデータブロックのデータブロック長、および少なくとも1つの第2のデータブロックのデータブロック長はそれぞれ、暗号化アルゴリズムのパケットの長さの整数倍である。車両のアップグレードパケットを、その長さがパケットの長さの整数倍であるデータブロックに分割することによって、カプセル解除器が被暗号化パケットの処理中に解読におけるパケットの統合のための時間をさらに消費しないことを保証することができる。これは、タイミング攻撃に効果的に抵抗し、それによって被暗号化パケットの機密の保護および完全性の保護を保証する。

可能な設計では、第1の端末が、第1のデータブロックおよび少なくとも1つの第2のデータブロックに基づいて車両のアップグレードパッケージを取得することが、第1の端末が第1の時間に第1のデータブロックの解読を開始し、第1の端末が第2の時間に第2のデータブロックを受信することであって、第1の時間は第2の時間よりも早いこと、または第1の端末が第3の時間に第2のデータブロックの解読を開始し、第1の端末が第4の時間に第1のデータブロックを受信することであって、第3の時間は第4の時間よりも早いこと、を含む。本願のこの実施形態では、第1の端末は、データブロックを受信しながらデータブロックを解読する。したがって、すべてのデータブロックを受信した後に第1の端末がすべてのデータブロックを一緒に解読する方法と比較されると、本願のこの実施形態における方法は、解読効率を改善し、アップグレードパッケージのダウンロード時間を短縮することができる。

可能な設計では、第1のデータブロックおよび第2のデータブロックは各々、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名を含み、第1の端末が、第1の時間に第1のデータブロックの解読を開始することは、第1のデータブロック内の署名が、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名であることを第1の端末が確認したときに、第1の端末が第1の時間に第1のデータブロックの解読を開始することを含み、第1の端末が第3の時間に第2のデータブロックの解読を開始することは、第2のデータブロック内の署名が、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名であることを第1の端末が確認したときに、第1の端末が第3の時間に第2のデータブロックの解読を開始することを含む。この場合、第1のデータブロックおよび第2のデータブロックで搬送された署名がOTAサーバの署名ではない場合、第1のデータブロックおよび第2のデータブロックは破棄されてもよく、OTAサーバの署名を含む第1のデータブロックおよび第2のデータブロックが再取得され得る。このようにして、第1の端末は、別の装置によって送信された安全でないデータブロックを受信することが防止され、それによってデータブロック送信のセキュリティが向上する。

可能な設計では、サーバは、車両のアップグレードパッケージの分割によって取得されたデータブロックと、データブロックを受信する端末との間の対応関係を記憶するようにさらに構成される。第1の端末が第2の端末から1つまたは複数の第2のデータブロックを取得することは、第1の端末が、対応関係に基づいて第2の端末にデータブロック取得要求を送信すること、および第1の端末は、データブロック取得要求に応答して第2の端末によって返信された1つまたは複数の第2のデータブロックを受信することを含む。このようにして、第1の端末は、サーバによって提供された対応関係に基づいて、対応する第2の端末から第2のデータブロックを正確に取得することができる。

可能な設計では、サーバはプロキシサーバであり、車両のアップグレードパッケージは、プロキシサーバによって無線OTAサーバから取得され、第1の端末は車両である。この場合、プロキシサーバは、車両のアップグレードを支援することができ、それによってOTAサーバの負荷を低減することができる。

可能な設計では、第1の端末は充電パイルである。

可能な設計では、方法は、充電パイルが車両によって送信されたアップグレードパッケージ取得要求を受信すること、および車両が充電パイルの安全検証に成功した場合に、充電パイルが、アップグレードパッケージ取得要求に基づいて車両のアップグレードパッケージを車両に返信することをさらに含む。このようにして、車両は、充電中に車両のアップグレードパッケージをダウンロードすることができる。車両の充電中、車両は通常、静止状態にあるため、通常は比較的良好なネットワーク環境があり得ること、また車両が充電補助装置に接続されているため、車両の電力不足に起因する車両のアップグレードパッケージのダウンロード中断などの現象を回避することができることが理解できる。したがって、車両のアップグレードのユーザ体験が効果的に改善され得る。

可能な設計では、第1の端末がサーバから第1のデータブロックを受信することは、第1の端末がサーバとのセキュリティ認証に成功したときに、第1の端末によって、サーバから第1のデータブロックを受信する。第1の端末は、サーバとセキュリティ認証を行った後に第1のデータブロックを受信するので、第1の端末によって受信される第1のデータブロックのセキュリティを向上させることができる。

第2の態様によれば、本願の実施形態は、車両のアップグレードパッケージを処理するための方法を提供する。方法は、サーバが、車両のアップグレードパッケージを複数のデータブロックに分割すること、およびサーバが複数のデータブロックを少なくとも1つの端末に配信することであって、各端末は、端末によって受信されたデータブロックと、少なくとも1つの端末のうちの別の端末からのデータブロックとに基づいて、車両のアップグレードパッケージを取得するように構成されることを含む。

可能な設計では、サーバが車両のアップグレードパッケージを複数のデータブロックに分割することは、サーバが暗号化アルゴリズムに従って車両のアップグレードパッケージを暗号化し、車両の暗号化されたアップグレードパッケージを複数のデータブロックに分割することを含む。

可能な設計では、サーバはプロキシサーバであり、サーバが車両のアップグレードパッケージをブロックに分割する前に、方法は、プロキシサーバが、無線OTAサーバから車両のアップグレードパッケージを取得することをさらに含む。

可能な設計では、プロキシサーバが無線OTAサーバから車両のアップグレードパッケージを取得することは、プロキシサーバが、無線OTAサーバに車両のアップグレードパッケージ取得要求を送信することを含み、車両のアップグレードパッケージ取得要求は、オペレーティングシステムの種類および車両のバージョンを含み、プロキシサーバがOTAサーバとのセキュリティ検証に成功したとき、プロキシサーバは、OTAサーバによって送信された車両のアップグレードパッケージを受信し、車両のアップグレードパッケージは、オペレーティングシステムの種類および車両のバージョンに基づいてOTAサーバによって生成される。

可能な設計では、サーバが複数のデータブロックを少なくとも1つの端末に配信した後、方法は、サーバが、車両のアップグレードパッケージの分割によって取得されたデータブロックと、データブロックを受信する端末との間の対応関係を記録することをさらに含む。

第3の態様によれば、本願の実施形態は、第1の端末であって、サーバから1つまたは複数の第1のデータブロックを受信するように構成される受信モジュールであって、第1のデータブロックが車両のアップグレードのために使用される、受信モジュール、および処理モジュールであって、第1の端末によって、第2の端末から1つまたは複数の第2のデータブロックを取得し、第2のデータブロックが車載システムをアップグレードするために使用され、第2のデータブロックがサーバによって第2の端末に送信され、第1のデータブロックおよび第2のデータブロックに基づいて車両のアップグレードパッケージを取得するよう構成される、処理モジュールを含む、第1の端末を提供する。

可能な設計では、第1のデータブロックと第2のデータブロックの両方が暗号化されたデータブロックであり、第1のデータブロックのデータブロック長、および少なくとも1つの第2のデータブロックのデータブロック長はそれぞれ、暗号化アルゴリズムのパケットの長さの整数倍である。

可能な設計では、処理モジュールは、具体的には、第1の時間に第1のデータブロックの解読を開始し、第2の時間に第2のデータブロックを受信するように構成され、第1の時間は第2の時間よりも早いか、または、処理モジュールは、第3の時間に第2のデータブロックの解読を開始し、第4の時間に第1のデータブロックを受信するように構成され、第3の時間は第4の時間よりも早い。

可能な設計では、第1のデータブロックおよび第2のデータブロックは、各々、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名を含み、処理モジュールは、具体的には、第1のデータブロック内の署名が、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名であることを確認したときに、第1の時間に第1のデータブロックの解読を開始するようにさらに構成され、第2のデータブロック内の署名が、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名であることを確認したときに、第3の時間に第2のデータブロックの解読を開始するように構成される。

可能な設計では、サーバは、車両のアップグレードパッケージの分割によって取得されたデータブロックとデータブロックを受信する端末との間の対応関係を記憶し、処理モジュールは、具体的には、対応関係に基づいて、第2の端末にデータブロック取得要求を送信し、データブロック取得要求に応答して第2の端末によって返信された1つまたは複数の第2のデータブロックを受信するようにさらに構成される。

可能な設計では、サーバはプロキシサーバであり、車両のアップグレードパッケージは、プロキシサーバによって無線OTAサーバから取得され、第1の端末は車両である。

可能な設計では、第1の端末は充電パイルである。

可能な設計では、受信モジュールは、車両によって送信されたアップグレードパッケージ取得要求を受信するようにさらに構成され、また処理モジュールは、車両が充電パイルの安全検証に成功したときに、アップグレードパッケージ取得要求に基づいて車両のアップグレードパッケージを車両に返信するようにさらに構成される。

可能な設計では、受信モジュールは、具体的には、第1の端末がサーバとのセキュリティ認証に成功したときに、第1の端末によって、サーバから第1のデータブロックを受信するように構成される。

第4の態様によれば、本願の実施形態は、サーバであって、車両のアップグレードパッケージを複数のデータブロックに分割するように構成された処理モジュール、および複数のデータブロックを少なくとも1つの端末に配信するように構成された送信モジュールであって、各端末が、端末によって受信されたデータブロックと、少なくとも1つの端末のうちの別の端末からのデータブロックとに基づいて、車両のアップグレードパッケージを取得するように構成された、送信モジュールを含む、サーバを提供する。

可能な設計では、処理モジュールは、具体的には、暗号化アルゴリズムに従って車両のアップグレードパッケージを暗号化し、車両の暗号化されたアップグレードパッケージを複数のデータブロックに分割するように構成される。

可能な設計では、サーバはプロキシサーバであり、処理モジュールは、無線OTAサーバから車両のアップグレードパッケージを取得するようにさらに構成される。

可能な設計では、処理モジュールは、具体的には、車両のアップグレードパッケージ取得要求を無線OTAサーバに送信し、車両のアップグレードパッケージ取得要求は、オペレーティングシステムの種類および車両のバージョンを含み、プロキシサーバがOTAサーバとのセキュリティ検証に成功したときに、OTAサーバによって送信された車両のアップグレードパッケージを受信し、車両のアップグレードパッケージは、オペレーティングシステムの種類および車両のバージョンに基づいてOTAサーバによって生成されるように構成される。

可能な設計では、処理モジュールは、車両のアップグレードパッケージの分割によって取得されたデータブロックと、データブロックを受信する端末との間の対応関係を記録するようにさらに構成される。

第5の態様によれば、本願の実施形態は、車両のアップグレードパッケージを処理するための装置を提供する。車両のアップグレードパッケージを処理するための装置は、第1の端末内のチップまたはシステムオンチップであってもよく、プロセッサおよびインターフェイス回路を含む。インターフェイス回路は、コード命令を受信し、なおかつコード命令をプロセッサへ伝送するように構成される。プロセッサはコード命令を実行して第1の態様、または第1の態様の可能な設計のいずれか1つによる方法を実行するように構成される。

第6の態様によれば、本願の実施形態は、車両のアップグレードパッケージを処理するための装置を提供する。車両のアップグレードパッケージを処理するための装置は、サーバ内のチップまたはシステムオンチップであってもよく、プロセッサおよびインターフェイス回路を含む。インターフェイス回路は、コード命令を受信し、なおかつコード命令をプロセッサへ伝送するように構成される。プロセッサはコード命令を実行して第2の態様、または第2の態様の可能な設計のいずれか1つによる方法を実行するように構成される。

第7の態様によれば、本願の実施形態は、メモリとプロセッサを含む、車両のアップグレードパッケージを処理するための装置を提供する。プロセッサが、メモリ内のプログラム命令を実行して、第1の態様または第1の態様の可能な設計のうちのいずれか1つによる方法を実行する。

第8の態様によれば、本願の実施形態は、メモリとプロセッサを含む、車両のアップグレードパッケージを処理するための装置を提供する。プロセッサが、メモリ内のプログラム命令を実行して、第2の態様または第2の態様の可能な設計のうちのいずれか1つによる方法を実行する。

第9の態様によると、本願の実施形態は可読コンピュータ記憶媒体を提供する。可読コンピュータ記憶媒体は、コンピュータプログラムを記憶するように構成され、コンピュータプログラムは、第1の態様または第1の態様の可能な実施態様のいずれか1つによる方法を実行するために使用される。

第10の態様によると、本願の実施形態は可読コンピュータ記憶媒体を提供する。可読コンピュータ記憶媒体は、コンピュータプログラムを記憶するように構成され、コンピュータプログラムは、第2の態様または第2の態様の可能な実施態様のいずれか1つによる方法を実行するために使用される。

第11の態様によれば、本願の実施形態は、車両のアップグレードパッケージを処理するためのシステムを提供する。システムは、第3の態様の通信装置、および対応する実現可能な実装形態と、第4の態様の通信装置、および対応する実現可能な実装形態とを含む。

本願の第2の態様から第11の態様の技術的解決策は、本願の第1の態様の技術的解決策に対応し、各態様および対応する実行可能な実施態様によって得られる有益な効果は同様であり、再び詳細に説明されないことを理解されたい。

本願の実施形態による、車両のアップグレードパッケージを処理するための方法が適用されるネットワークシステムの概略図である。 本願の実施形態による、車両のアップグレードパッケージを処理するための方法の概略的な流れ図である。 本願の実施形態による、車両のアップグレードパッケージを処理するための方法が適用される別のネットワークシステムの概略図である。 本願の実施形態による、車両における車載装置の論理的枠組みの概略図である。 本願の実施形態による、車両のアップグレードパッケージを処理するための具体的な方法の概略的な流れ図である。 本願の実施形態による、車両のアップグレードパッケージを処理するための方法が適用されるさらに別のネットワークシステムの概略図である。 本願の実施形態による、車両のアップグレードパッケージを処理するための別の具体的な方法の概略的な流れ図である。 本願の実施形態による、第1の端末の構造の概略図である。 本願の実施形態による、サーバの構造の概略図である。 本願の実施形態による、車両のアップグレードパッケージを処理するための装置のハードウェア構造の概略図である。

これ以降は添付の図面を参照しながら実施形態の実装を詳しく説明する。

本願の実施形態で提供される車両のアップグレードパッケージを処理するための方法は、図1のネットワークシステムに適用され得る。システムは、サーバ11、第1の端末121、および第2の端末122を含んでもよい。1つまたは複数の第2の端末122が存在する場合がある。

サーバ11は、車両のアップグレードパッケージを配信するように構成されたOTAサーバであってもよく、またはOTAサーバから車両のアップグレードパッケージを取得した車両団サーバ、または任意の他の可能なサーバであってもよい。これは、本願の実施形態で具体的に限定されない。第1の端末121は任意の形態の車両であってもよく、第1の端末121は任意の形態の車両補助装置（例えば、車両充電パイル）であってもよく、第1の端末121は携帯端末（例えば、携帯電話、タブレットコンピュータ、またはウェアラブルデバイス）であってもよい。これは、本願の実施形態で具体的に限定されない。第2の端末122は任意の形態の車両であってもよく、第2の端末122は任意の形態の車両補助装置（例えば、車両充電パイル）であってもよく、第2の端末122は携帯端末（例えば、携帯電話、タブレットコンピュータ、またはウェアラブルデバイス）であってもよい。これは、本願の実施形態で具体的に限定されない。第1の端末121および第2の端末122は、同種の装置であってもよい。例えば、第1の端末121および第2の端末122は、いずれも車両、車両補助装置、または携帯端末などである。あるいは、第1の端末121および第2の端末122は、異なる種類の装置であってもよい。例えば、第1の端末121は車両であり、第2の端末122は車両補助装置または携帯端末などである。これは、本願の実施形態で具体的に限定されない。サーバ11、第1の端末121、および第2の端末122が様々な特定のデバイスである場合に、車両のアップグレードパッケージを処理する方法は、後続の実施形態で詳細に説明される。ここでは詳細は説明されない。

第1の端末121および第2の端末122は各々、サーバ11との通信接続を確立する。例えば、第1の端末121および第2の端末122は、ハイパーテキスト転送プロトコル（hypertext transfer protocol、HTTP）またはハイパーテキスト転送プロトコルオーバーセキュアソケットレイヤ（hyper text transfer trotocol over secure socket layer、HTTPS）などのプロトコルを用いることにより、サーバ11との通信接続を各々確立してもよい。これは、本願の実施形態において限定されない。

P2P通信は、任意の形態の通信接続を介して、第1の端末121と第2の端末122との間で実行され得る。例えば、第1の端末121と第2の端末122との間では、ブルートゥース（登録商標）（bluetooth）伝送、キャリアレス通信（ultra wide band，UWB）、赤外線伝送などの無線伝送によって、P2P通信が実行され得る。

あるいは、P2P通信は、有線伝送を介して、第1の端末121と第2の端末122との間で実行され得る。これは、本願の実施形態で具体的に限定されない。

あるいは、P2P通信は、インデックスサーバに基づいて、第1の端末121と第2の端末122との間で実行され得る。インデックスサーバは、サーバ11であっても、他の任意のサーバであってもよい。例えば、インデックスサーバは、リソースリストを記憶することができる。リソースリストは、第1の端末121と、第1の端末121におけるリソース識別子との対応関係、および、第2の端末122と、第2の端末122におけるリソース識別子との対応関係を含む。第1の端末121がリソースを取得することを期待するとき、第1の端末121はインデックスサーバから各端末のリソースリストを取得し、リソースリストから、リソースの識別子を含む端末が第2の端末122であると判定する。この場合、第1の端末121は、さらに、有線通信または無線通信により、第2の端末122からリソースを取得し得る。

図2は、本願の実施形態による車両のアップグレードパッケージを処理するための方法の概略的な流れ図である。図2に示されるように、方法は以下のステップを含む。

ステップS101：第1の端末がサーバから1つまたは複数の第1のデータブロックを受信し、第1のデータブロックは車両のアップグレードに使用される。

本願のこの実施形態では、サーバは、OTAサーバであっても、OTAサーバ以外のサーバであってもよい。サーバがOTAサーバである場合、サーバは、車両のアップグレードのためのアップグレードパッケージを生成することができる。サーバがOTAサーバ以外のサーバである場合、サーバはまず、OTAサーバから車両のアップグレードのためのアップグレードパッケージを取得することができる。

サーバは、車両のアップグレードのための完全なアップグレードパッケージを複数のデータブロックに分割することができる。アップグレードパッケージに具体的に対応する装置に基づいて、各アップグレードパッケージは、装置の番号およびアップグレードパッケージシーケンス番号に対応することができることが理解されよう。ブロックの分割中、サーバは、アップグレードパッケージ内のデータブロックの位置などに基づいてデータブロックを識別することができ、その結果、データブロックは、複数のデータブロックの識別子に基づいてその後統合されて、完全なアップグレードパッケージを再び取得することができる。データブロックの具体的な識別方法および識別内容は、本願のこの実施形態では具体的に限定されない。実施形態では、データブロックは完全なデータパケットであってもよい。

例えば、特定の実装形態では、ブロックの分割によって取得された各データブロックのヘッダは、アップグレードパッケージiにおけるデータブロックのバージョン番号、アップグレードパッケージシーケンス番号i、装置の番号j、およびシーケンス番号kのうちの1つまたは複数を含むことができる。例えば、乗用車対象の自動車用電子制御ユニット（electronic control unit、ECU）は、現在、25から100種類程度存在する。したがって、通常、256種類以下のアップグレードパッケージがある。これに対応して、アップグレードパッケージシーケンス番号iの総数は256を超えない。アップグレードパッケージシーケンス番号iがデータブロック内の1バイトを占有することが指定され得る。それに対応して、通常、256種類以下の車両がまた存在する。したがって、装置番号（例えば、車両のECU番号）jも1バイトを占有し得る。アップグレードパッケージi内のデータブロックのシーケンス番号kは、アップグレードパッケージのサイズおよびアップグレード方法に関連する。例えば、より大きいアップグレードパッケージが、より大きいシーケンス番号kを示す。または、差分アップグレード方式が使用される場合、kはより小さく、または完全なパッケージアップグレード方式が使用される場合、kはより大きい。例えば、kは1～3バイトを占有することができる。これは本願のこの実施形態で具体的に限定されない。

複数のデータブロックを取得した後、サーバは、複数のデータブロックを複数の端末に配信することができる。本願のこの実施形態では、複数の端末のうちの第1の端末が実行主体として使用され、複数の端末のうちの第1の端末以外の端末が第2の端末である例を用いて、説明が提示されている。第1の端末および第2の端末は、代替的に、複数の端末以外の端末であってもよい。第1の端末によって受信されるデータブロックは第1のデータブロックであり、1つまたは複数の第1のデータブロックが存在し得る。第2の端末によって受信されるデータブロックは第2のデータブロックであり、1つまたは複数の第2のデータブロックが存在し得る。すべての第1のデータブロックおよびすべての第2のデータブロックは、完全なアップグレードパッケージを形成することができる。確かに、例えば、冗長な情報関連のカプセル化が実行される場合があり得、また、完全なアップグレードパッケージは、いくつかのデータパケットが解析されるときに形成され得る。あるいは、本明細書での第1のデータブロックはデータブロックの1つのタイプであってもよく、第2のデータブロックは別のタイプのデータブロックである。異なる種類のデータブロックの伝送経路は異なっていてもよい。例えば、異なる種類のデータブロックは、異なる装置を通過した後に、宛先側に到達する。

任意選択で、特定の実施態様では、第1の端末は、アップグレード要求をサーバに送信することができる。アップグレード要求は、第1の端末の基本情報を含むことができ、基本情報は、ソフトウェアの情報および／またはハードウェアの情報または車両モデル（例えば、車両の固有の識別子（vehicle identification number，VIN））を含むことができる。アップグレード要求に応答して、サーバは、アップグレード要求における基本情報と一致する1つまたは複数の第1のデータブロックを第1の端末に送信することができる。アップグレード要求を送信する前に、第1の端末は、アップグレードの通知をさらに受信することができる。アップグレード要求の送信をトリガするための様々な条件があり得る。例えば、アップグレード要求の送信は、第1の端末で指定されたタイミングの瞬間に基づいてトリガされ、アップグレード要求の送信は、ユーザが第1の端末の車載インフォテインメント（in vehicle Infotainment，IVI）システムの画面上でアップグレードの制御をタップしたときにトリガされ、アップグレード要求の送信は、第1の端末と通信する携帯電話などのモバイル装置におけるアプリケーションを使用することによってトリガされるか、または、第1の端末のネットワーク環境がアップグレード要件（サイレントアップグレードとも呼ばれる）を満たすときに、アップグレードの要求が自動的に送信される。

任意選択で、ステップS101が行われる前に、セキュアな通信を確立するために第1の端末とサーバとの間で双方向認証が行われてもよい。例えば、公開鍵インフラストラクチャ（public key infrastructure、PKI）を使用することによって、第1の端末とサーバとの間で、双方向認証を実行することができる。例えば、第1の端末は、第1の端末によるサーバの認証を実施するために、PKIにおけるサーバのデジタル証明書をチェックすることができ、また、サーバは、サーバによる第1の端末に対する認証を実施するために、PKIにおいて第1の端末のデジタル証明書をチェックすることができる。双方向の認証は、実際の適用シナリオに基づいて別の方法で第1の端末とサーバとの間で代替的に実行されてもよいことが理解されよう。これは本願のこの実施形態で具体的に限定されない。

ステップS102：第1の端末は第2の端末から1つまたは複数の第2のデータブロックを取得し、第2のデータブロックは車両のアップグレードのために使用され、第2のデータブロックはサーバによって第2の端末に送信される。

本願のこの実施形態では、第1の端末は、上述した任意のP2P方式で、第2の端末から1つまたは複数の第2のデータブロックを取得することができる。1つまたは複数の第2の端末が存在する場合がある。本願のこの実施形態では、第2の端末の数は限定されない。例えば、1つの第2の端末がある場合、第1の端末は1つの第2の端末から1つまたは複数の第2のデータブロックを取得する。複数の第2の端末が存在する場合、第1の端末は、1つまたは複数の第2の端末から1つまたは複数の第2のデータブロックを取得する。

本願のこの実施形態では、ステップS102およびステップS101の間のシーケンスは逆であってもよいことに留意していただきたい。具体的には、第1の端末は、まず、1つまたは複数の第1のデータブロックを取得し、次いで、1つまたは複数の第2のデータブロックを取得することができるか、または、第1の端末は、まず1つまたは複数の第2のデータブロックを取得し、次いで1つまたは複数の第1のデータブロックを取得することができる。これは本願のこの実施形態で具体的に限定されない。

任意選択で、サーバがデータブロックを複数の端末に配信するとき、サーバは、各データブロックと、データブロックを受信する端末との間の対応関係を記憶する。ステップS102の具体的な実施態様は以下の通りであり得る。第1の端末は、対応関係に基づいて第2の端末にデータブロック取得要求を送信し、第1の端末は、データブロック取得要求に応答して第2の端末によって返信された、少なくとも1つの第2のデータブロックを受信する。

本願のこの実施形態では、各データブロックは、1つのデータブロック識別子に一意に対応することができ、データブロック識別子は、番号または名前などの識別子であってもよい。各端末は、1つの端末識別子に一意に対応することができ、端末識別子は、端末の装置シリアル番号または端末の通信アドレスなどの識別子であってもよい。当然ながら、異なる端末について、端末によって使用される端末識別子の具体的な形態は異なり得る。異なるデータブロックの場合、データブロックによって使用されるデータブロック識別子は異なり得る。各データブロックについて、サーバは、データブロックの識別子と、データブロックを受信する端末の識別子との間の対応関係を格納することができる。この場合、第1の端末は、対応関係に基づいて、第1の端末によって受信されたデータブロック（例えば、1つまたは複数の第1のデータブロック）、第1の端末についてまだ欠落しているデータブロック（例えば、1つまたは複数の第2のデータブロック）、および第1の端末について欠落しているデータブロックに関連付けられた第2の端末の識別子を判定することができる。さらに、第1の端末は、第2の端末の識別子に基づいて第2の端末にデータ取得要求を送信し、第2の端末によって返信された1つまたは複数の第2のデータブロックを受信することができる。例えば、複数の第2の端末が存在する場合、第1の端末は、対応関係に基づいて各第2の端末にデータブロック取得要求を送信し、第2の端末によって返信された1つまたは複数の第2のデータブロックを受信することができる。あるいは、サーバは、データブロックが欠落していないことを保証するために、またはデータブロックが通常のアップグレード条件を満たすことができることを保証するために、単純な技術的検証方法または別の検証方法を使用することができる。

任意選択で、ステップS102が実行される前に、セキュアな通信を確立するために第1の端末と第2の端末との間で双方向認証が行われてもよい。例えば、PKIを用いることにより第1の端末と第2の端末との間で双方向認証を行うことができる。例えば、第1の端末は、第1の端末による第2の端末に対する認証を実施するために、PKIにおいて第2の端末のデジタル証明書をチェックすることができ、第2の端末は、第2の端末による第1の端末に対する認証を実施するために、PKIにおいて第1の端末のデジタル証明書をチェックすることができる。双方向の認証は、実際の適用シナリオに基づいて別の方法で第1の端末と第2の端末との間で代替的に実行されてもよいことが理解されよう。これは本願のこの実施形態で具体的に限定されない。

ステップS103：第1の端末は、第1のデータブロックおよび第2のデータブロックに基づいて、車両のアップグレードパッケージを取得する。

本願のこの実施形態では、すべての第2のデータブロックを取得した後、第1の端末は、車両のアップグレードパッケージを取得するために、第2のデータブロックの識別子および第1のデータブロックの識別子に基づくデータブロック配置シーケンスなどに従って、第1のデータブロックおよび第2のデータブロックを統合することができる。

本願のこの実施形態では、車両のアップグレードパッケージは、車両の単一のコンポーネントのシステム（またはソフトウェア）をアップグレードするためのアップグレードパッケージであってもよく、または車両内の複数のコンポーネントまたはすべてのコンポーネントのシステム（またはソフトウェア）をアップグレードするためのアップグレードパッケージであってもよい。これは本願のこの実施形態で具体的に限定されない。

結論として、本願のこの実施形態では、サーバは、車両のアップグレードパケットを複数のデータブロックに分割し、次いで、複数のデータブロックを複数の端末に配信することができる。次いで、端末は、P2P方式で別の端末からデータブロックを取得し、端末によって受信されたデータブロックと、端末によって別の端末から取得されたデータブロックとに基づいて、車両のアップグレードパッケージを取得することができる。このプロセスでは、端末のいずれも、OTAサーバから車両の完全なアップグレードパッケージを取得する必要はない。したがって、OTAサーバの負荷を低減することができる。

任意選択で、第1のデータブロックと第2のデータブロックの両方は、暗号化されたデータブロックであってもよい。

本願のこの実施形態では、車両のアップグレードパッケージをブロックに分割するとき、サーバは、車両のアップグレードパッケージを最初に暗号化し、次いで、車両の暗号化されたアップグレードパッケージを、暗号化された第1のデータブロックと、暗号化された第2のデータブロックとに分割することができる。あるいは、車両のアップグレードパッケージをブロックに分割するとき、サーバは、まず、車両のアップグレードパッケージを1つまたは複数の第1のデータブロックおよび1つまたは複数の第2のデータブロックに分割し、次いで、各第1のデータブロックおよび各第2のデータブロックを暗号化することができる。暗号化の具体的な実装は、本願のこの実施形態では具体的に限定されない。データブロックの完全性を保証するために、第1のデータブロックおよび第2のデータブロックは、それぞれ端末に格納されてもよく、または端末、例えば第1の端末および／または第2の端末において、集中的に格納されてもよい。あるいは、第1のデータブロックおよび第2のデータブロックに含まれる情報は、それぞれ端末に格納されてもよく、または端末、例えば第1の端末および／または第2の端末に、集中的に格納されてもよい。

本願のこの実施形態では、暗号化されたデータブロックを取得するためにサーバによって使用される暗号化アルゴリズムは、対称的な暗号化アルゴリズムであってもよく、または非対称的な暗号化アルゴリズムまたは任意の他の暗号化アルゴリズムであってもよい。暗号化アルゴリズムは、本願のこの実施形態では具体的に限定されない。異なる暗号化方法を使用することによる暗号化によって取得されたデータブロックの場合、暗号化アルゴリズムの識別子は、データブロック内で搬送され得ることが理解され得る。解読中、暗号化アルゴリズムの識別子に基づいて、対応する解読アルゴリズムを使用することができる。これは本願のこの実施形態では具体的に限定されはしない。

本願のこの実施形態では、第1のデータブロックおよび第2のデータブロックを暗号化することによって、認可されていないユーザがアップグレードパケットを取得することを防止することができ、分割によって取得されたデータブロックの送信プロセスの機密性を保証することができる。これにより、OTAnアップグレードパケットの高速送信を保証しながら、OTAデータパケットの送信セキュリティをさらに保証することができる。

本願のこの実施形態の任意選択の実装形態では、第1のデータブロックのデータブロック長、および少なくとも1つの第2のデータブロックのデータブロック長、それぞれ、対称的な暗号化アルゴリズムのパケットの長さの整数倍である。

本願のこの実施形態では、対称的な暗号化アルゴリズムに入力される車両のアップグレードパケットの長さは、暗号化アルゴリズムのパケットの長さの整数倍であり得る。例えば、パケットの長さは、8バイト、16バイト、または128バイトであってもよい。しかしながら、車両のアップグレードパッケージの長さは通常ランダムであり、パケットの長さの整数倍でなくてもよい。したがって、車両のアップグレードパッケージの全長がパケットの長さの整数倍になるように、車両のアップグレードパッケージに、パディング部を追加することができる。さらに、車両のアップグレードパッケージは、長さが暗号化アルゴリズムのパケットの長さの整数倍である複数のデータブロックに分割される。例えば、パケットの長さが128バイトである場合、第1のデータブロックと第2のデータブロックの両方の長さは128＊nとすることができ、式中nは自然数である。

本願のこの実施形態では、車両のアップグレードパケットを、その長さがパケットの長さの整数倍であるデータブロックに分割することによって、カプセル解除器が被暗号化パケットの処理中に解読におけるパケットの統合のための時間をさらに消費しないことを保証することができる。これは、タイミング攻撃に効果的に抵抗し、それによって被暗号化パケットの機密の保護および完全性の保護を保証する。

任意選択の実施態様では、第1の端末がOTAサーバに接続されているとき、第1の端末は、OTAサーバから、第1のデータブロックおよび第2のデータブロックのパケットの長さ、データブロックを暗号化するための鍵、ならびに鍵の有効時間を取得することができる。この場合、第1の端末は、鍵に基づいて鍵の有効時間内に第1のデータブロックおよび第2のデータブロックを解読することができる。

任意選択で、第1のデータブロックのデータブロック長、および少なくとも1つの第2のデータブロックのデータブロック長が、それぞれ暗号化アルゴリズムのパケットの長さの整数倍である場合、第1の端末によって第1のデータブロックおよび第2のデータブロックを解読する方法は、以下の通りであってもよい。

第1の端末がデータブロック（第1のデータブロックまたは第2のデータブロックを含む）を受信するたびに、第1の端末は受信されたデータブロックを直ちに解読する。この場合、第1の端末が最後のデータブロックを受信するとき、第1の端末は、以前に受信されたデータブロックの解読を完了している可能性がある。したがって、第1の端末は、すべてのデータブロックの解読を完了するために、最後のデータブロックを解読する時間待つ必要だけがある。言い換えれば、本願のこの実施形態では、第1の端末は、データブロックを受信しながらデータブロックを解読する。したがって、すべてのデータブロックを受信した後に第1の端末がすべてのデータブロックを一緒に解読する方法と比較されると、本願のこの実施形態における方法は、解読効率を改善し、アップグレードパッケージのダウンロード時間を短縮することができる。

第1の端末は、代替として、すべてのデータブロックを受信した後、すべてのデータブロック（第1のデータブロックまたは第2のデータブロックを含む）を一緒に解読してもよいことが理解され得る。これは本願のこの実施形態で具体的に限定されない。

任意選択で、第1のデータブロックおよび第2のデータブロックは各々、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名を含む。例えば、車両システムをアップグレードするために完全なアップグレードパッケージに対してブロックの分割を実行する前に、OTAサーバは、アップグレードパッケージに署名するか、または公開鍵暗号に基づいてアップグレードパッケージのコンテンツにデジタル署名することができる。署名は、OTAサーバに対応する識別子であってもよい。例えば、署名は、OTAサーバの装置識別子またはOTAサーバを操作するオペレータの識別子であってもよい。あるいは、署名は、車両提供者の識別子などを含んでもよい。加えて、ブロックの分割中に、署名が第1のデータブロックおよび第2のデータブロックに追加される。このようにして、第1のデータブロックおよび第2のデータブロックを取得するとき、第1の端末は、第1のデータブロックおよび第2のデータブロックで搬送された署名に基づいて、第1のデータブロックおよび第2のデータブロックが第1の端末によって許可されたOTAサーバによって送信されたかどうかを判定することができる。第1のデータブロックおよび第2のデータブロックで搬送された署名がOTAサーバの署名ではない場合、第1のデータブロックおよび第2のデータブロックは破棄されてもよく、OTAサーバの署名を含む第1のデータブロックおよび第2のデータブロックが再取得されてもよいことが理解されよう。このようにして、第1の端末は、別の装置によって送信された安全でないデータブロックを受信することが防止され、それによってデータブロック送信のセキュリティが向上する。

これに応じて、第1のデータブロックおよび第2のデータブロックは各々、車両のアップグレードのためのアップグレードパッケージを生成するサーバの署名を含む。第1の端末は、第1のデータブロック内の署名が車両のアップグレードパッケージをダウンロードするためのサーバの署名であることを第1の端末が確認したときに第1の時間に第1のデータブロックの解読を開始し、第2の時間に第2のデータブロックを受信し、第1の時間は第2の時間よりも早いか、または、第1の端末は、第2のデータブロック内の署名が車両のアップグレードパッケージをダウンロードするためのサーバの署名であることを第1の端末が確認したときに第3の時間に第2のデータブロックの解読を開始し、第4の時間に第1のデータブロックを受信し、第3の時間が第4の時間よりも早い。

例えば、図3は、本願の実施形態による、車両のアップグレードパッケージを処理するための方法が適用され得る具体的なアップグレードシステムを示す。図3に示すように、アップグレードシステムは、サーバ30と、第1の端末31と、第2の端末32とを含む。3個の第2の端末32があり、それぞれ第2の端末320、第2の端末321、および第2の端末322として番号付けされている。

本願のこの実施形態では、サーバ30はOTAサーバであり得る。あるいは、サーバ30はプロキシサーバであってもよい。例えば、プロキシサーバは、車両団にサービス提供するサーバであってもよい。サーバ30がプロキシサーバである場合、プロキシサーバは、最初に双方向認証を介してOTAサーバとのセキュアな通信を確立し、次いで、プロキシサーバは車両のハードウェアおよびソフトウェアの情報をOTAサーバに送信する。車両のアップグレードパッケージを生成した後、OTAサーバは、車両のアップグレードパッケージを、プロキシサーバに配信することができる。OTAサーバは、代替として、車両のアップグレードパッケージをブロックに分割し、ブロックを複数のプロキシサーバに配信し、また複数のプロキシサーバは、前述のP2P方式で車両のアップグレードパッケージを取得することができるということが理解されよう。これは本願のこの実施形態で具体的に限定されない。

本願のこの実施形態では、第1の端末と第2の端末の両方が車両であってもよい。図4は、車両における車載装置の論理的な枠組みの模式図である。図4の車載装置は、車両に含まれる車載装置の全部または一部であってもよいことが理解できる。これらの車載装置は、いくつかのドメインにグループ化されてもよく、各ドメインは1つ以上の車載装置を含み、各ドメインはドメインアドミニストレータを含み、ドメインアドミニストレータはまた、ドメインコントローラと呼ばれ得る。例えば、モバイルデータセンタ（mobile data center、MDC）、1つまたは複数のセンサ（sensor）、および全地球測位システム（global positioning system、GPS）はドメインに属し、MDCはドメイン内のドメインコントローラである。車両制御ユニット（vehicle control unit、VCU）、1つまたは複数の電子制御ユニット（electronic control unit、ECU）、無線電力伝送（wireless power transmission、WPT）装置などが、ドメインに属し、VCUはドメイン内のドメインコントローラである。ヒューマンマシンインターフェイス（human machine interface、HMI）および1つまたは複数のECUがドメインに属し、HMIはドメイン内のドメインコントローラである。車体制御モジュール（body control module、BCM）、1つまたは複数のECU、パッシブ・エントリ・パッシブ・スタート（passive entry passive start、PEPS）などがドメインに属し、BCMはドメイン内のドメインコントローラである。ドメインコントローラは、ゲートウェイ（gateway、GW）に接続され、ゲートウェイは、車載診断（on-board diagnostics、OBD）システム、車両のインターネットにおける車両通信端末（telematics box，T-Box）、および別の装置に接続される。例えば、ドメインコントローラは、ゲートウェイを介してT-Boxなどの装置と通信することができ、ドメイン内装置は、ドメインコントローラを介してゲートウェイなどの装置と通信することができる。

任意選択の実施態様では、車両は、T-Boxを使用することによって車両のアップグレードパッケージをダウンロードし、車両のアップグレードパッケージのソースを決定し、また、車両のアップグレードパッケージがOTAサーバによって配信されたと判定した後、車両は、アップグレードパッケージに対応する装置の番号に基づいて、車両のアップグレードパッケージを車両内の対応する車載装置に転送することができる。比較的強力なコンピューティングおよび記憶能力を有する車載装置（例えば、MDCまたはHMI）は、それ自体パッケージングを実行することができ、その結果、T-Boxの記憶リソースの消費を低減することができる。パッケージングを実行した後、車両内の車載コンポーネントは、アップグレードパッケージに対する署名の検証をさらに実行し、車両のアップグレードパッケージがOTAサーバによって配信されたと判定した後に、アップグレードインストールなどの動作を実行することができる。これにより、アップグレードパッケージの信頼性を向上させることができる。

本願のこの実施形態では、第1の端末が第1の車両であり、第2の端末が第2の車両である例が使用される。図5に示すように、車両のアップグレードパッケージを処理するための方法の任意選択の具体的な実行ステップは、以下の通りであり得る。

ステップS301：第1の車両はサーバから1つまたは複数の第1のデータブロックを取得し、第2の車両はサーバから1つまたは複数の第2のデータブロックを取得する。

ステップS302：第1の車両は、第2の車両から1つまたは複数の第2のデータブロックを取得する。

ステップS303：第1の車両は、取得された第1のデータブロックおよび取得された第2のデータブロックに基づいて、車両のアップグレードパッケージを取得する。

本願のこの実施形態では、サーバによって車両のアップグレードパッケージをブロックに分割する方法、および第1の車両によって第1のデータブロックおよび第2のデータブロックを取得する方法について、図2に対応する実施形態の説明を参照されたい。ここでは詳細は繰り返されない。

本願のこの実施形態における任意選択の適用シナリオでは、図3に示すように、サーバ30は、車両団サーバであり、車両団サーバは、OTAサーバから、車両団サーバによってサービス提供される車両団（例えば、第1の車両31、第2の車両320、第2の車両321、および第2の車両322を含む）によって使用される、車両のアップグレードパッケージを事前に取得する。さらに、車両団の定期的なメンテナンス中に、ワイヤレスフィデリティ（Wireless-Fidelity、Wi-Fi）ネットワーク接続などの場合、第1の車両31、第2の車両320、第2の車両321、および第2の車両322は、車両団サーバに接続される。アップグレードパッケージダウンロード通知を受信するとき、車両団サーバは、第1の車両31、第2の車両320、第2の車両321、および第2の車両322との双方向認証（例えば、PKIベースの認証方式）を実行し、また、認証に成功した後、アップグレードパッケージの暗号鍵kを暗号化し（車両の公開鍵を使用することによって、アップグレードパッケージの暗号鍵kを暗号化し）、次いで、暗号化された暗号鍵を第1の車両31、第2の車両320、第2の車両321、および第2の車両322に配信する。例えば、第1の車両31が車両のアップグレードパッケージの第1の部分をダウンロードし、第2の車両320が車両のアップグレードパッケージの第2の部分をダウンロードし、第2の車両321が車両のアップグレードパッケージの第3の部分をダウンロードした場合、第1の車両31は、第2の車両320から車両のアップグレードパッケージの第2の部分をダウンロードし、第2の車両321から車両のアップグレードパッケージの第3の部分をダウンロードし、鍵kを使用することによる解読を通じて車両の完全なアップグレードパッケージをさらに取得することができる。

第2の車両320はまた、第1の車両31および第2の車両321から車両の完全なアップグレードパッケージを取得してもよく、第2の車両321はまた、第1の車両31および第2の車両320から車両の完全なアップグレードパッケージを取得してもよいことが、理解されよう。

この場合、第1の車両31、第2の車両320、または第2の車両321が車両の完全なアップグレードパッケージを取得した後、第2の車両322は、第1の車両31、第2の車両320、または第2の車両321から車両のアップグレードパッケージを取得することができる。各車両が車両のアップグレードパッケージをダウンロードする具体的なプロセスは、本願のこの実施形態では限定されない。

本願のこの実施形態では、車両団サーバはプロキシサーバとして使用され、その結果、車両は、メンテナンスまたは別のプロセスの間に、便利な車両のアップグレードを実施することができる。

任意選択で、車両のアップグレードパッケージの安定性をさらに改善し、車両の誤ったアップグレードパッケージが複数の車両に配信されるのを防止するために、ステップS301が実行される前に、車両のアップグレードパッケージに対して性能試験が実行されてもよい。例えば、車両Aを使用することによって、サーバ30から車両のアップグレードパッケージを最初に取得することができ、次いで車両Aは車両のアップグレードパッケージに基づいて更新を実行する。更新が成功した場合、車両Aはサーバ30に更新成功メッセージを送信し、また、その後、ステップS301と後続のステップが、さらに実行される。このことが、車両のアップグレードに成功する確率を高めることができる。

例えば、図6は、本願の実施形態による、車両のアップグレードパッケージを処理するための方法が適用され得る具体的なアップグレードシステムを示す。図6に示すように、アップグレードシステムは、サーバ60と、第1の端末61と、第2の端末62とを備える。3個の第2の端末62があり、それぞれ第2の端末620、第2の端末621、および第2の端末622として番号付けされている。

本願のこの実施形態では、サーバ60はOTAサーバであり得る。あるいは、サーバ60はプロキシサーバであってもよい。サーバ60がプロキシサーバである場合、プロキシサーバは、双方向認証を介してOTAサーバとのセキュアな通信を最初に確立することができ、次いで、プロキシサーバは、車両補助装置によってサービス提供される車両のハードウェアおよびソフトウェアの情報を、OTAサーバに送信する。車両のアップグレードパッケージを生成した後、OTAサーバは、車両のアップグレードパッケージを、プロキシサーバに配信することができる。OTAサーバは、代替として、車両のアップグレードパッケージをブロックに分割し、ブロックを複数のプロキシサーバに配信し、また複数のプロキシサーバは、前述のP2P方式で車両のアップグレードパッケージを取得することができるということが理解されよう。これは本願のこの実施形態で具体的に限定されない。

本願のこの実施形態では、第1の端末が第1の車両補助装置であり、第2の端末が第2の車両補助装置である例が使用される。第2の車両補助装置は、車両充電用の装置（例えば、充電パイル）、携帯端末などであってもよい。図7に示すように、車両のアップグレードパッケージを処理するための方法の任意選択の具体的な実行ステップは、以下の通りであり得る。

ステップS701：第1の車両補助装置はサーバから1つまたは複数の第1のデータブロックを取得し、第2の車両補助装置はサーバから1つまたは複数の第2のデータブロックを取得する。

ステップS702：第1の車両補助装置は、第2の車両補助装置から1つまたは複数の第2のデータブロックを取得する。

ステップS703：第1の車両補助装置は、取得された第1のデータブロックおよび取得された第2のデータブロックに基づいて、車両のアップグレードパッケージを取得する。

本願のこの実施形態では、サーバによって車両のアップグレードパッケージをブロックに分割する方法、および第1の車両補助装置によって第1のデータブロックおよび第2のデータブロックを取得する方法について、図2に対応する実施形態の説明を参照されたい。ここでは詳細は繰り返されない。

本願のこの実施形態における任意選択の適用シナリオでは、図6に示すように、サーバ60はOTAサーバである。OTAサーバは、車両のアップグレードパッケージを生成し、車両のアップグレードパッケージがダウンロードされる必要があることを第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、および第2の車両補助装置622に、さらに通知する。OTAサーバは、第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、および第2の車両補助装置622と双方向認証（例えば、PKIベースの認証方式）を行い、また、認証に成功した後、鍵kを用いることによって暗号化されたデータブロックを、第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、および第2の車両補助装置622に配信する。例えば、第1の車両補助装置61が車両のアップグレードパッケージの第1の部分をダウンロードし、第2の車両補助装置620が車両のアップグレードパッケージの第2の部分をダウンロードし、第2の車両補助装置621が車両のアップグレードパッケージの第3の部分をダウンロードした場合、第1の車両補助装置61は、第2の車両補助装置620から車両のアップグレードパッケージの第2の部分をダウンロードし、第2の車両補助装置621から車両のアップグレードパッケージの第3の部分をダウンロードし、鍵kを使用することによる解読を通じて車両の完全なアップグレードパッケージをさらに取得することができる。

第2の車両補助装置620はまた、第1の車両補助装置61および第2の車両補助装置621から車両の完全なアップグレードパッケージを取得してもよく、第2の車両補助装置621はまた、第1の車両補助装置61および第2の車両補助装置620から車両の完全なアップグレードパッケージを取得してもよいことが、理解されよう。

この場合、第1の車両補助装置61、第2の車両補助装置620、または第2の車両補助装置621が車両の完全なアップグレードパッケージを取得した後、第2の車両補助装置622は、第1の車両補助装置61、第2の車両補助装置620、または第2の車両補助装置621から車両のアップグレードパッケージを取得することができる。各車両補助装置が車両のアップグレードパッケージをダウンロードする具体的なプロセスは、本願のこの実施形態では限定されない。

本願のこの実施形態では、例えば、アップグレードの通知を受信した後、車両63は、車両のアップグレードパッケージの暗号鍵kを取得するためにOTAサーバへの接続を確立することができる。第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、または第2の車両補助装置622を使用することによって車両63が充電されているとき、第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、または第2の車両補助装置622は、車両によって送信されたアップグレードパッケージ取得要求を受信し、車両との双方向認証を実行することができる。次いで、第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、または第2の車両補助装置622は、車両の暗号化されたアップグレードパッケージを車両に送信することができる。車両63は、鍵kを使用することによって車両の暗号化されたアップグレードパッケージを解読して、車両のアップグレードパッケージを取得する。このようにして、車両63は、充電中に車両のアップグレードパッケージをダウンロードすることができる。車両の充電中、車両は通常、静止状態にあるため、通常は比較的良好なネットワーク環境があり得ること、また車両が充電補助装置に接続されているため、車両の電力不足に起因する車両のアップグレードパッケージのダウンロード中断などの現象を回避することができることが理解できる。したがって、車両のアップグレードのユーザ体験が効果的に改善され得る。

任意選択で、車両のアップグレードパッケージの安定性をさらに改善し、車両の誤ったアップグレードパッケージが複数の車両に配信されるのを防止するために、ステップS701が実行される前に、車両のアップグレードパッケージに対して正当性試験が実行されてもよい。例えば、車両のアップグレードパッケージは、最初に、車両Aを使用することによって、第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、または第2の車両補助装置622から取得することができ、次いで、車両Aは、車両のアップグレードパッケージに基づいて更新を実行する。更新が成功した場合、車両Aは、第1の車両補助装置61、第2の車両補助装置620、第2の車両補助装置621、または第2の車両補助装置622に更新成功メッセージを送信し、その後、ステップS701と後続のステップがさらに実行される。これにより、車載システムのアップグレードに成功する確率を高めることができる。

図8は、本願の実施形態による第1の端末の構造の概略図である。第1の端末は、受信モジュール801および処理モジュール802を含む。受信モジュールは、サーバから1つまたは複数の第1のデータブロックを受信するように構成され、第1のデータブロックは車両のアップグレードのために使用される。処理モジュールは、第1の端末によって、第2の端末から1つまたは複数の第2のデータブロックを取得し、第2のデータブロックが車載システムをアップグレードするために使用され、第2のデータブロックがサーバによって第2の端末に送信され、また第1のデータブロックおよび第2のデータブロックに基づいて車両のアップグレードパッケージを取得するようにさらに構成される。

可能な設計では、第1のデータブロックと第2のデータブロックの両方が暗号化されたデータブロックであり、第1のデータブロックのデータブロック長、および少なくとも1つの第2のデータブロックのデータブロック長はそれぞれ、暗号化アルゴリズムのパケットの長さの整数倍である。

可能な設計では、処理モジュールは、具体的には、第1の時間に第1のデータブロックの解読を開始し、第2の時間に第2のデータブロックを受信するように構成され、第1の時間は第2の時間よりも早いか、または、第3の時間に第2のデータブロックの解読を開始し、第4の時間に第1のデータブロックを受信するように構成され、第3の時間は第4の時間よりも早い。

可能な設計では、第1のデータブロックおよび第2のデータブロックは各々、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名を含み、処理モジュールは、具体的には、第1のデータブロック内の署名が、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名であることを確認したときに、第1の時間に第1のデータブロックの解読を開始するようにさらに構成され、第2のデータブロック内の署名が、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名であることを確認したときに、第3の時間に第2のデータブロックの解読を開始するように構成される。

可能な設計では、サーバは、車両のアップグレードパッケージの分割によって取得されたデータブロックとデータブロックを受信する端末との間の対応関係を記憶し、処理モジュールは、具体的には、対応関係に基づいて、第2の端末にデータブロック取得要求を送信し、データブロック取得要求に応答して第2の端末によって返信された1つまたは複数の第2のデータブロックを受信するようにさらに構成される。

可能な設計では、サーバはプロキシサーバであり、車両のアップグレードパッケージは、プロキシサーバによって無線OTAサーバから取得され、第1の端末は車両である。

可能な設計では、第1の端末は充電パイルである。

可能な設計では、受信モジュールは、車両によって送信されたアップグレードパッケージ取得要求を受信するようにさらに構成され、また処理モジュールは、車両が充電パイルの安全検証に成功したときに、アップグレードパッケージ取得要求に基づいて車両のアップグレードパッケージを車両に返信するようにさらに構成される。

可能な設計では、受信モジュールは、具体的には、第1の端末がサーバとのセキュリティ認証に成功したときに、第1の端末によって、サーバから第1のデータブロックを受信するように構成される。

この実施形態の装置は、前述の方法の実施形態において第1の端末によって実行されるステップを実行するように、相応して構成され得る。実装の原理および装置の技術的効果は、前述の方法のものと同様であり、詳細はここでは再度説明されない。

図9は、本願の実施形態による第1の端末の構造の概略図である。第1の端末は、処理モジュール901および送信モジュール902を含む。処理モジュールは、車両のアップグレードパッケージを複数のデータブロックに分割するように構成される。送信モジュールは、複数のデータブロックを少なくとも1つの端末に配信するように構成され、各端末は、端末によって受信されたデータブロックと、少なくとも1つの端末の別の端末からのデータブロックとに基づいて、車両のアップグレードパッケージを取得するように構成される。

可能な設計では、処理モジュールは、具体的には、暗号化アルゴリズムに従って車両のアップグレードパッケージを暗号化し、車両の暗号化されたアップグレードパッケージを複数のデータブロックに分割するように構成される。

可能な設計では、サーバはプロキシサーバであり、処理モジュールは、無線OTAサーバから車両のアップグレードパッケージを取得するようにさらに構成される。

可能な設計では、処理モジュールは、具体的には、車両のアップグレードパッケージ取得要求を無線OTAサーバに送信し、車両のアップグレードパッケージ取得要求は、オペレーティングシステムの種類および車両のバージョンを含み、プロキシサーバがOTAサーバとのセキュリティ検証に成功したときに、OTAサーバによって送信された車両のアップグレードパッケージを受信し、車両のアップグレードパッケージは、オペレーティングシステムの種類および車両のバージョンに基づいてOTAサーバによって生成されるように構成される。

可能な設計では、処理モジュールは、車両のアップグレードパッケージの分割によって取得されたデータブロックと、データブロックを受信する端末との間の対応関係を記録するようにさらに構成される。

この実施形態の装置は、前述の方法の実施形態においてサーバによって実行されるステップを実行するように、相応して構成され得る。実装の原理および装置の技術的効果は、前述の方法のものと同様であり、詳細はここでは再度説明されない。

図10は、本願による車両のアップグレードパッケージを処理するための装置のハードウェア構造の概略図である。図10を参照されたい。車両のアップグレードパッケージを処理するための装置は、メモリ1001、プロセッサ1002、および通信インターフェイス1003を含む。メモリ1001、プロセッサ1002、および通信インターフェイス1003は、相互に通信できる。例えば、メモリ1001、プロセッサ1002、および通信インターフェイス1003は、通信バス1004を用いることによって、相互に通信できる。メモリ1001は、コンピュータプログラムを記憶するように構成される。プロセッサ1002は、コンピュータプログラムを実行して、前述の方法の実施形態において説明された方法を実行する。

任意選択で、通信インターフェイス1003は、送信機および／または受信機をさらに含んでもよい。

任意選択的に、プロセッサは、中央処理装置（central processing unit，CPU）であってもよく、または別の汎用プロセッサ、デジタル信号プロセッサ（digital signal processor，DSP）、特定用途向け集積回路（application specific integrated circuit，ASIC）などであってもよい。汎用プロセッサはマクロプロセッサであってよいし、このプロセッサは任意の従来のプロセッサなどであってよい。本願を参照して開示された方法のステップは、ハードウェアプロセッサによって直接実装されてもよく、またはハードウェアとプロセッサ内のソフトウェアモジュールの組み合わせによって実装されてもよい。

本願はコンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体は、コンピュータプログラムを記憶するように構成され、コンピュータプログラムは、上記の方法の実施形態において記載された方法を実施するために使用される。

本願は、図8に示す第1の端末および図9に示すサーバを含む通信システムをさらに提供する。

本願は、システムチップを提供する。システムチップは、本願の実施形態で説明される機能（例えば、第1の端末はサーバから1つまたは複数の第1のデータブロックを受信し、第1のデータブロックは車両のアップグレードに使用され、第1の端末は第2の端末から1つまたは複数の第2のデータブロックを取得し、第2のデータブロックは車載システムをアップグレードするために使用され、第2のデータブロックはサーバによって第2の端末に送信され、第1の端末は、第1のデータブロックおよび第2のデータブロックに基づいて車両のアップグレードパッケージを取得する）を実行する際に通信装置をサポートするように構成される。チップが、具体的には、チップシステムで使用され、チップシステムはチップを含み得るか、またはチップと、別の分離した装置とを含み得る。前述の方法が、第1の装置のチップを使用して実行される場合、チップは処理ユニットを含む。さらに、チップは、通信ユニットをさらに含んでもよい。処理ユニットは、例えばプロセッサであってもよい。チップが通信ユニットを含む場合、通信ユニットは、例えば入力／出力インターフェイス、ピン、または回路であってもよい。処理ユニットは、本願の実施形態における各処理モジュールによって実行されるすべてまたはいくつかの動作を実行し、通信ユニットは、対応する受信または送信動作を実行することができる。別の特定の実施形態では、本願における受信装置の処理モジュールはチップの処理ユニットであってもよく、制御装置の受信モジュールまたは送信モジュールはチップの通信ユニットである。

この出願の実施形態は、この出願の実施形態による方法、装置（システム）、およびコンピュータプログラム製品のフローチャートおよび／またはブロック図に関連して説明される。コンピュータプログラム命令は、流れ図および／またはブロック図における各手順および／または各ブロック、ならびに流れ図および／またはブロック図における手順および／またはブロックの組み合わせを実現するために使用することができることを理解すべきである。これらのコンピュータプログラム命令は、マシンを生成するために汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、または任意の他のプログラマブルデータ処理装置の処理ユニットに与えられてよく、これにより、コンピュータまたは任意の他のプログラマブルデータ処理装置の処理ユニットによって実行される命令は、フローチャートの1つ以上のプロセスおよび／またはブロック図の1つ以上のブロックにおける特定の機能を実現するための装置を生成する。

これらのコンピュータプログラム命令はまた、具体的な方式で動作するようにコンピュータまたは別のプログラマブルデータ処理装置に指示することができるコンピュータ可読メモリに記憶されてよく、その結果、コンピュータ可読メモリに記憶された命令は、命令装置を含む人工物を生成する。命令装置は、フローチャートの1または複数の手順の、および／またはブロック図の1または複数のブロックの、特定の機能を実現する。

これらのコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理装置にロードされてよく、これにより、一連の動作およびステップがコンピュータまたは別のプログラマブル装置上で行われ、それによってコンピュータ実装処理が生成される。したがって、コンピュータまたは別のプログラマブル装置上で実行される命令は、流れ図における1つもしくは複数の手順および／またはブロック図における1つもしくは複数のブロックにおける特定の機能を実現するためのステップを提供する。

本願で提供されたいくつかの実施形態では、開示の装置および方法が他の方式で実装され得ることを理解されたい。例えば、記載された装置の実施形態は例に過ぎない。例えば、部位の区分は論理的な機能の区分にすぎず、実際に実施する際には他の区分であってもよい。例えば、複数のユニットや構成要素が別のシステムに組み合わせられるまたは組み込まれてもよいし、あるいは一部の機能が無視されるまたは実行されなくてもよい。加えて、提示されたまたは述べられた相互結合または直接的な結合もしくは通信接続は、いくつかのインターフェイスを介して実現されてもよい。装置またはユニット間の間接的な結合または通信接続は、電子的な、機械的な、または他の形態で実現されてもよい。

別々の部分として記載されたユニットは、物理的に分離されていてもいなくてもよく、ユニットとして表示された部分は物理ユニットであってもなくてもよく、1つの場所に配置されてもよく、または複数のネットワークユニットに分散されてもよい。ユニットの一部またはすべてが、実施形態の解決策の目的を達成するために、実際の要件に基づいて選択されてもよい。

加えて、本願の実施形態における機能ユニットが、1つの処理ユニットに統合されてもよく、またはユニットの各々が、物理的に単独で存在してもよく、または2つ以上のユニットが1つのユニットに統合される。統合ユニットは、ハードウェアの形態で実装されてもよく、またはハードウェア、さらにソフトウェア機能ユニットの形態で実装されてもよい。

前述の統合ユニットがソフトウェア機能ユニットの形態で実装されるとき、統合ユニットはコンピュータ可読記憶媒体に記憶される場合がある。ソフトウェア機能ユニットは記憶媒体に格納されており、コンピュータ装置（パーソナルコンピュータ、サーバ、またはネットワーク装置とすることができる）またはプロセッサ（processor）に、本願の各実施形態に記載されている方法のステップの一部を実行するよう命令するためのいくつかの命令を含む。前述の記憶媒体は、USBフラッシュドライブ、リムーバブルハードディスク、読み取り専用メモリ（read-only memory、ROM）、ランダムアクセスメモリ（random access memory、RAM）、磁気ディスク、または光ディスクなどの、プログラムコードを記憶することができる任意の媒体を含む。

11 サーバ
30 サーバ
31 第1の端末、第1の車両
32 第2の端末
60 サーバ
61 第1の車両補助装置、第1の端末
62 第2の端末
63 車両
121 第1の端末
122 第2の端末
320 第2の端末、第2の車両
321 第2の端末、第2の車両
322 第2の車両、第2の端末
620 第2の車両補助装置、第2の端末
621 第2の車両補助装置、第2の端末
622 第2の車両補助装置、第2の端末
801 受信モジュール
802 処理モジュール
901 処理モジュール
902 送信モジュール
1001 メモリ
1002 プロセッサ
1003 通信インターフェイス
1004 通信バス

Claims (35)

1. 車両のアップグレードパッケージを処理するための方法であって、
   第1の端末によって、サーバから第1のデータブロックを受信するステップであって、前記第1のデータブロックが前記車両をアップグレードするために使用される、ステップと、
   前記第1の端末によって、第2の端末から第2のデータブロックを取得するステップであって、前記第2のデータブロックが車載システムをアップグレードするために使用され、前記第2のデータブロックが前記サーバによって前記第2の端末に送信される、ステップと、
   前記第1の端末によって、前記第1のデータブロックおよび前記第2のデータブロックに基づいて前記車両の前記アップグレードパッケージを取得するステップと、
   を含む、方法。
2. 前記第1のデータブロックと前記第2のデータブロックの両方が、暗号化されたデータブロックであり、前記第1のデータブロックの長さおよび前記第2のデータブロックの長さの各々が、暗号化アルゴリズムのパケットの長さの整数倍である、請求項1に記載の方法。
3. 前記第1の端末によって、前記第1のデータブロックおよび前記第2のデータブロックに基づいて前記車両の前記アップグレードパッケージを取得する前記ステップが、
   前記第1の端末によって、第1の時間に前記第1のデータブロックの解読を開始し、前記第1の端末によって、第2の時間に前記第2のデータブロックを受信するステップであって、前記第1の時間は前記第2の時間よりも早い、ステップ、または
   前記第1の端末によって、第3の時間に前記第2のデータブロックの解読を開始し、前記第1の端末によって、第4の時間に前記第1のデータブロックを受信するステップであって、前記第3の時間は前記第4の時間よりも早い、ステップ、
   を含む、請求項2に記載の方法。
4. 前記第1のデータブロックおよび前記第2のデータブロックは各々、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名を含み、
   前記第1の端末によって、第1の時間に前記第1のデータブロックの解読を開始することは、
   前記第1のデータブロック内の署名が、前記車両システムをアップグレードするための前記アップグレードパッケージを生成する前記サーバの前記署名であることを前記第1の端末が確認したときに、前記第1の端末によって、前記第1の時間に前記第1のデータブロックの解読を開始することを含み、
   前記第1の端末によって、第3の時間に前記第2のデータブロックの解読を開始することは、
   前記第2のデータブロック内の署名が、前記車両システムをアップグレードするための前記アップグレードパッケージを生成する前記サーバの前記署名であることを前記第1の端末が確認したときに、前記第1の端末によって、前記第3の時間に前記第2のデータブロックの解読を開始することを含む、請求項3に記載の方法。
5. 前記サーバが、前記車両の前記アップグレードパッケージの分割によって取得されたデータブロックと、前記データブロックを受信する端末との間の対応関係を記憶し、前記第1の端末によって、第2の端末から第2のデータブロックを取得する前記ステップが、
   前記第1の端末によって、前記対応関係に基づいて前記第2の端末にデータブロック取得要求を送信するステップと、
   前記第1の端末によって、前記データブロック取得要求に応答して前記第2の端末によって返信された前記第2のデータブロックを受信するステップと、
   を含む、請求項1に記載の方法。
6. 前記サーバがプロキシサーバであり、前記車両の前記アップグレードパッケージが、前記プロキシサーバによって、無線OTAサーバから取得され、前記第1の端末が車両である、請求項1から5のいずれか一項に記載の方法。
7. 前記第1の端末は充電パイルである、請求項1から5のいずれか一項に記載の方法。
8. 前記方法は、
   前記充電パイルによって、車両によって送信されたアップグレードパッケージ取得要求を受信するステップと、
   前記車両が前記充電パイルの安全検証に成功したときに、前記充電パイルにより、前記アップグレードパッケージ取得要求に基づいて前記車両の前記アップグレードパッケージを前記車両に返信するステップと、
   をさらに含む、請求項7に記載の方法。
9. 第1の端末によって、サーバから第1のデータブロックを受信する前記ステップが、
   前記第1の端末が前記サーバとのセキュリティ認証に成功したときに、前記第1の端末によって、前記サーバから前記第1のデータブロックを受信するステップを含む、請求項1から5のいずれか一項に記載の方法。
10. 車両のアップグレードパッケージを処理するための方法であって、
    サーバによって、前記車両の前記アップグレードパッケージを複数のデータブロックに分割するステップと、
    前記サーバによって、前記複数のデータブロックを少なくとも1つの端末に配信するステップであって、各端末は、前記端末によって受信されたデータブロックと、前記少なくとも1つの端末のうちの別の端末からのデータブロックとに基づいて、前記車両の前記アップグレードパッケージを取得するように構成された、ステップと、
    を含む、方法。
11. サーバによって、前記車両の前記アップグレードパッケージを複数のデータブロックに分割する前記ステップが、
    前記サーバによって、暗号化アルゴリズムに従って前記車両の前記アップグレードパッケージを暗号化し、前記車両の前記暗号化されたアップグレードパッケージを前記複数のデータブロックに分割するステップを含む、請求項10に記載の方法。
12. 前記サーバがプロキシサーバであり、サーバによって、前記車両の前記アップグレードパッケージをブロックに分割する前記ステップの前に、前記方法は、
    前記プロキシサーバによって、無線OTAサーバから前記車両の前記アップグレードパッケージを取得するステップをさらに含む、請求項10または11に記載の方法。
13. 前記プロキシサーバによって、無線OTAサーバから前記車両の前記アップグレードパッケージを取得する前記ステップは、
    前記プロキシサーバによって、前記無線OTAサーバに車両アップグレードパッケージ取得要求を送信するステップであって、前記車両アップグレードパッケージ取得要求が、前記車両のオペレーティングシステムの種類および前記車両のバージョンを含む、ステップと、
    前記プロキシサーバが前記OTAサーバとのセキュリティ検証に成功したときに、前記プロキシサーバによって、前記OTAサーバによって送信された前記車両の前記アップグレードパッケージを受信するステップであって、前記車両の前記アップグレードパッケージは、前記車両の前記オペレーティングシステムの種類および前記車両の前記バージョンに基づいて前記OTAサーバによって生成される、ステップと、
    を含む、請求項12に記載の方法。
14. 前記サーバによって、前記複数のデータブロックを少なくとも1つの端末に配信する前記ステップの後に、前記方法が、
    前記サーバによって、前記車両の前記アップグレードパッケージの分割によって取得されたデータブロックと、前記データブロックを受信する端末との間の対応関係を記録するステップをさらに含む、請求項10から13のいずれか一項に記載の方法。
15. 第1の端末であって、
    サーバから第1のデータブロックを受信するように構成された受信モジュールであって、前記第1のデータブロックが車両をアップグレードするために使用される、受信モジュールと、
    前記第1の端末によって、第2の端末から第2のデータブロックを取得するように構成された処理モジュールであって、前記第2のデータブロックが車載システムをアップグレードするために使用され、前記第2のデータブロックが前記サーバによって前記第2の端末に送信され、
    前記処理モジュールが、前記第1のデータブロックおよび前記第2のデータブロックに基づいて前記車両のアップグレードパッケージを取得するように構成された、処理モジュールと、
    を含む、第1の端末。
16. 前記第1のデータブロックと前記第2のデータブロックの両方が、暗号化されたデータブロックであり、前記第1のデータブロックの長さおよび前記第2のデータブロックの長さのそれぞれが、暗号化アルゴリズムのパケットの長さの整数倍である、請求項15に記載の第1の端末。
17. 前記処理モジュールは、第1の時間に前記第1のデータブロックの解読を開始し、第2の時間に前記第2のデータブロックを受信するように構成され、前記第1の時間は前記第2の時間よりも早いか、または、
    前記処理モジュールは、第3の時間に前記第2のデータブロックの解読を開始し、第4の時間に前記第1のデータブロックを受信するように構成され、前記第3の時間は前記第4の時間よりも早い、請求項16に記載の第1の端末。
18. 前記第1のデータブロックおよび前記第2のデータブロックは、各々、車両システムをアップグレードするためのアップグレードパッケージを生成するサーバの署名を含み、前記処理モジュールは、
    前記第1のデータブロック内の署名が、前記車両システムをアップグレードするための前記アップグレードパッケージを生成する前記サーバの前記署名であることを確認したときに、前記第1の時間に前記第1のデータブロックの解読を開始し、
    前記第2のデータブロック内の署名が、前記車両システムをアップグレードするための前記アップグレードパッケージを生成する前記サーバの前記署名であることを確認したときに、前記第3の時間に前記第2のデータブロックの解読を開始するようにさらに構成された、請求項17に記載の第1の端末。
19. 前記サーバは、前記車両の前記アップグレードパッケージの分割によって取得されたデータブロックと前記データブロックを受信する端末との間の対応関係を記憶し、前記処理モジュールは、
    前記対応関係に基づいて、前記第2の端末にデータブロック取得要求を送信し、
    前記データブロック取得要求に応答して前記第2の端末によって返信された前記第2のデータブロックを受信するようにさらに構成された、請求項15に記載の第1の端末。
20. 前記サーバがプロキシサーバであり、前記車両の前記アップグレードパッケージが、前記プロキシサーバによって、無線OTAサーバから取得され、前記第1の端末が車両である、請求項15から19のいずれか一項に記載の第1の端末。
21. 前記第1の端末は充電パイルである、請求項15から19のいずれか一項に記載の第1の端末。
22. 前記受信モジュールは、車両によって送信されたアップグレードパッケージ取得要求を受信するようにさらに構成され、
    前記処理モジュールは、前記車両が前記充電パイルの安全検証に成功したときに、前記アップグレードパッケージ取得要求に基づいて前記車両の前記アップグレードパッケージを前記車両に返信するようにさらに構成された、
    ことをさらに備える、請求項21に記載の第1の端末。
23. 前記受信モジュールが、前記第1の端末が前記サーバとのセキュリティ認証に成功したときに、前記第1の端末によって、前記サーバから前記第1のデータブロックを受信するように構成された、請求項15から19のいずれか一項に記載の第1の端末。
24. サーバであって、
    車両のアップグレードパッケージを複数のデータブロックに分割するように構成された処理モジュールと、
    前記複数のデータブロックを少なくとも1つの端末に配信するように構成された送信モジュールであって、各端末が、前記端末によって受信されたデータブロックと、前記少なくとも1つの端末のうちの別の端末からのデータブロックとに基づいて、前記車両の前記アップグレードパッケージを取得するように構成された、送信モジュールと、
    を含む、サーバ。
25. 前記処理モジュールは、暗号化アルゴリズムに従って前記車両の前記アップグレードパッケージを暗号化し、前記車両の前記暗号化されたアップグレードパッケージを前記複数のデータブロックに分割するように構成された、請求項24に記載のサーバ。
26. 前記サーバはプロキシサーバであり、前記処理モジュールは、無線OTAサーバから前記車両の前記アップグレードパッケージを取得するようにさらに構成された、請求項24または25に記載のサーバ。
27. 前記処理モジュールは、車両アップグレードパッケージ取得要求を前記無線OTAサーバに送信するように構成され、前記車両アップグレードパッケージ取得要求は、前記車両のオペレーティングシステムの種類および前記車両のバージョンを含み、
    前記処理モジュールは、前記プロキシサーバが前記OTAサーバとのセキュリティ検証に成功したときに、前記OTAサーバによって送信された前記車両の前記アップグレードパッケージを受信するように構成され、前記車両の前記アップグレードパッケージは、前記車両の前記オペレーティングシステムの種類および前記車両の前記バージョンに基づいて前記OTAサーバによって生成される、請求項26に記載のサーバ。
28. 前記処理モジュールが、前記車両の前記アップグレードパッケージの分割によって取得されたデータブロックと、前記データブロックを受信する端末との間の対応関係を記録するようにさらに構成された、請求項24から27のいずれか一項に記載のサーバ。
29. プロセッサとインターフェイス回路とを備える、車両のアップグレードパッケージを処理するための装置であって、前記インターフェイス回路は、コード命令を受信し、前記コード命令を前記プロセッサに送信するように構成され、前記プロセッサは、前記コード命令を実行して、請求項1から9のいずれか一項に記載の方法を実行するように構成された、装置。
30. プロセッサとインターフェイス回路とを備える、車両のアップグレードパッケージを処理するための装置であって、前記インターフェイス回路は、コード命令を受信し、前記コード命令を前記プロセッサに送信するように構成され、前記プロセッサは、前記コード命令を実行して、請求項10から14のいずれか一項に記載の方法を実行するように構成された、装置。
31. メモリとプロセッサとを備える、車両のアップグレードパッケージを処理するための装置であって、前記プロセッサは、前記メモリ内のプログラム命令を実行して、請求項1から9のいずれか一項に記載の方法を実行する、装置。
32. メモリとプロセッサとを備える、車両のアップグレードパッケージを処理するための装置であって、前記プロセッサは、前記メモリ内のプログラム命令を実行して、請求項10から14のいずれか一項に記載の方法を実行する、装置。
33. 可読コンピュータ記憶媒体であって、前記可読コンピュータ記憶媒体がコンピュータプログラムを記憶するよう構成され、前記コンピュータプログラムが、請求項1から9のいずれか一項に記載の方法を実行するために使用される、可読コンピュータ記憶媒体。
34. 可読コンピュータ記憶媒体であって、前記可読コンピュータ記憶媒体がコンピュータプログラムを記憶するよう構成され、前記コンピュータプログラムが、請求項10から14のいずれか一項に記載の方法を実行するために使用される、可読コンピュータ記憶媒体。
35. 請求項15から23のいずれか一項に記載の第1の端末と、請求項24から28のいずれか一項に記載のサーバとを備える、車両のアップグレードパッケージを処理するためのシステム。

Images