JP2024510237A - オーバー・ザ・エア技術（ｏｔａ）に基づいた通信方法及び装置 - Google Patents

Abstract

本願の実施形態は、オーバー・ザ・エア技術ＯＴＡに基づいた通信方法及び装置を提供し、通信技術の分野に関係がある。方法は、第１情報及び第２情報を取得することであり、第１情報は第１ソフトウェアバージョン情報及び／又は第１識別番号を含み、第２情報は第１マッピングを含み、第１マッピングは第２ソフトウェアバージョン情報と第２識別番号との間の関連付け関係を含み、識別番号はソフトウェアバージョンのパーミッション情報を示す、ことと、第１情報及び第２情報に基づいて、第１ソフトウェアバージョン情報と第１マッピングに対応する第２ソフトウェアバージョン情報との間の一致を検証することとを含む。このようにして、車両ソフトウェアの正常なアップグレードがＯＴＡメンテナンス及びソフトウェアインストールプロセスで確保可能であり、更には、車両の安全性が保たれる。

Description

本願は、通信技術の分野に、特に、オーバー・ザ・エア技術ＯＴＡに基づいた通信方法及び装置に関係がある。

自動運転の発展とともに、人々は、車両の計算及び制御の能力に対する要求をますます高めている。ソフトウェアの形でユーザに提供される機能の数は増えている。従って、ソフトウェアにより定義された車両が、車両開発の重要なトレンドになりつつある。車両ソフトウェアがインストール又は更新される必要があるとき、オーバー・ザ・エア技術（ｏｖｅｒ－ｔｈｅ－ａｉｒ ｔｅｃｈｎｏｌｏｇｙ，ＯＴＡ）が、クラウドに接続して車両ソフトウェアをインストール又は更新するために使用されることがある。

しかし、ＯＴＡは、人々に利便性をもたらすと同時に、車両のアドミッションに対する課題ももたらす。アドミッションは、車両が市場に投入される前に、関連する標準規格の要求を満足するために、安全性、排気、などに対する一連のテストが実行されるプロセスとして理解され得る。具体的に、ＯＴＡを使用することによって車両ソフトウェアを更新することは、車両が市場に投入された後に車両のアドミッションパラメータを変更する可能性がある。例えば、車両のバッテリ管理ソフトウェアがＯＴＡを使用することによってアップグレードされた後、車両の耐久走行距離が増えることあり、車両の耐久走行距離は、アドミッション中に測定された耐久走行距離と一致しなくなる。更に、車両のアドミッション中にテストされたデータは無効になり、テストが再び行われる必要がある。従って、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンは、アドミッション中に使用されたソフトウェアバージョンと一致しないことがある。これは、ＯＴＡの開発に課題をもたらす。

本願の実施形態は、ＯＴＡメンテナンス及びソフトウェアインストールプロセスの正常なアップグレードを確保し、更には車両の安全性を保つように、オーバー・ザ・エア技術ＯＴＡに基づいた通信方法及び装置を提供する。

第１の態様に従って、ＯＴＡに基づいた通信方法を提供する。方法は、第１情報及び第２情報を取得することであり、第１情報は第１ソフトウェアバージョン情報及び／又は第１識別番号を含み、第２情報は第１マッピングを含み、第１マッピングは第２ソフトウェアバージョン情報と第２識別番号との間の関連付け関係を含み、識別番号はソフトウェアバージョンのパーミッション情報を示す、ことと、第１情報及び第２情報に基づいて、第１ソフトウェアバージョン情報と第１マッピングに対応する第２ソフトウェアバージョン情報との間の一致を検証することとを含む。

このようにして、第１情報と第２情報との間の一致は、第１情報及び第２情報のｅ識別番号及びソフトウェアバージョンの間のマッチング関係を使用することによって検証され得るので、ＯＴＡメンテナンス及びソフトウェアインストールプロセスにおいて、車両ソフトウェアの正常なアップグレードを確保し、車両の安全性を保つように、車両エンド及び／又はサーバ（又はクラウド若しくはクラウドデバイスと呼ばれる）におけるソフトウェアバージョンと識別番号との間の一貫性は保たれる。

第１の態様を参照して、可能な実施において、第１情報及び第２情報に基づいて、第１ソフトウェアバージョン情報と第１マッピングに対応する第２ソフトウェアバージョン情報との間の一致を検証することは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致せず、かつ／あるいは、第１識別番号が第２識別番号と一致しないとき、第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致しないと決定すること、又は第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致し、かつ／あるいは、第１識別番号が第２識別番号と一致するとき、第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致すると決定することを含む。

このようにして、第１ソフトウェアバージョン情報と第２ソフトウェアバージョン情報との間の一致は、クラウド又は車両エンドを使用することによって検証され得る。更に、ソフトウェアバージョン及び／又は識別番号が改ざんされることを防ぎ、かつ、ＯＴＡを使用することによってアップグレードされる車両ソフトウェアの正常なアップグレードを確保するように、車両エンド及び／又はクラウドのソフトウェアバージョン及び識別番号の間の一貫性は保たれ得る。

第１の態様を参照して、可能な実施において、方法は、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新すること、又は第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新することを更に含む。

このようにして、クラウド及び車両エンドは、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合を取り除き、かつ、車両ソフトウェアの正常なアップグレードを確保するように、識別番号とソフトウェアバージョンとの間のマッチング関係に基づいて、車両エンドのソフトウェアバージョン及び／又は識別番号の間の一貫性と、クラウドデバイスのマッピング関係とを保ち得る。

第１の態様を参照して、可能な実施において、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新することより前に、方法は、第１タスクを第１車両へ送信することを更に含み、第１タスクは第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するよう指示する。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１タスクは第１マッピングを含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１タスクは第２マッピングを含む。第２マッピングは、第３ソフトウェアバージョン情報と第３識別番号との間の関連付け関係を含む。第３ソフトウェアバージョン情報は、第２ソフトウェアバージョン情報とは異なり、かつ／あるいは、第３識別番号は、第２識別番号とは異なる。

このようにして、車両エンド及び／又はクラウドのソフトウェアバージョン及び識別番号の間の一貫性に基づいて、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合を取り除き、かつ、車両ソフトウェアの正常なアップグレードを確保するように、ソフトウェアバージョン情報と識別番号との間のマッチング関係は、ＯＴＡソフトウェアアップグレードプロセスにおいて確かにされ得る。

第１の態様を参照して、可能な実施において、方法は、第１ソフトウェアパッケージを第１車両へ送信することを更に含み、第１ソフトウェアパッケージは、第１車両に対応するソフトウェアバージョン情報を更新するために使用される。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアパッケージは第２識別番号を含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１ソフトウェアパッケージは第３識別番号を含む。

このようにして、車両エンド及び／又はクラウドのソフトウェアバージョン及び識別番号の間の一貫性に基づいて、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合を取り除き、かつ、車両ソフトウェアの正常なアップグレードを確保するように、ソフトウェアバージョン情報と識別番号との間のマッチング関係は、ＯＴＡソフトウェアアップグレードプロセスにおいて確かにされ得る。

第１の態様を参照して、可能な実施において、方法は、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアバージョン情報、第１識別番号、及び／又はアラーム情報をサーバ及び／又は第１車両の表示デバイスへ送信することを更に含み、アラーム情報は、第１車両の識別番号及び／又はソフトウェアバージョン情報がサーバのマッピング関係と一致しないことを示す。

このようにして、クラウドデバイス及び／又は第１車両の表示デバイスは、車両ソフトウェアの正常なアップグレードを更に確かにするように、車両エンドによって送信されたアラーム情報に基づいてタイムリーな処理を実行することができる。

第１の態様を参照して、可能な実施において、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新することは、サーバから第１タスクを受信することを含み、第１タスクは、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するよう指示す。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１タスクは第１マッピングを含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１タスクは第２マッピングを含む。第２マッピングは、第３ソフトウェアバージョン情報と第３識別番号との間の関連付け関係を含む。第３ソフトウェアバージョン情報は、第２ソフトウェアバージョン情報とは異なり、かつ／あるいは、第３識別番号は、第２識別番号とは異なる。

このようにして、車両エンド及び／又はクラウドのソフトウェアバージョン及び識別番号の間の一貫性に基づいて、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合を取り除き、かつ、車両ソフトウェアの正常なアップグレードを確保するように、ソフトウェアバージョン情報と識別番号との間のマッチング関係は、ＯＴＡソフトウェアアップグレードプロセスにおいて確かにされ得る。

第１の態様を参照して、可能な実施において、方法は、サーバから第１ソフトウェアパッケージを受信することを更に含み、第１ソフトウェアパッケージは、第１車両に対応するソフトウェアバージョン情報を更新するために使用される。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアパッケージは第２識別番号を含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１ソフトウェアパッケージは第３識別番号を含む。

このようにして、車両エンド及び／又はクラウドのソフトウェアバージョン及び識別番号の間の一貫性に基づいて、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合を取り除き、かつ、車両ソフトウェアの正常なアップグレードを確保するように、ソフトウェアバージョン情報と識別番号との間のマッチング関係は、ＯＴＡソフトウェアアップグレードプロセスにおいて確かにされ得る。

第１の態様を参照して、可能な実施において、第１車両は、第１ソフトウェアパッケージに関連した複数の電子制御ユニットを含む。第１ソフトウェアパッケージに基づいて第１車両のソフトウェアを更新することは、Ｎが正の整数であるとして、Ｎ個の電子制御ユニットへ各電子制御ユニットに対応する第１ソフトウェアパッケージを送信することと、Ｎ個の電子制御ユニットからＮ個のソフトウェアインストール結果を受信することと、Ｎ個のソフトウェアインストール結果により、Ｎ個のソフトウェアパッケージのうちのいずれか１つ以上がインストールに失敗したことが示されるとき、第１車両の車両ソフトウェアバージョン及び識別番号をロールバックすることとを含む。

このようにして、車両エンド及び／又はクラウドのソフトウェアバージョン及び識別番号の間の一貫性に基づいて、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合を取り除き、かつ、車両ソフトウェアの正常なアップグレードを確保するように、ソフトウェアバージョン情報と識別番号との間のマッチング関係は、ＯＴＡソフトウェアアップグレードプロセスにおいて確かにされ得る。

第１の態様を参照して、可能な実施において、第１車両からのアラーム情報が受信され、アラーム情報は表示される。

第１の態様を参照して、可能な実施において、識別番号は、第１法規関連ソフトウェア識別番号ＲＸＳＷＩＮを含む。このようにして、ＲＸＳＷＩＮとソフトウェアバージョンとの間のマッチング関係は、ＯＴＡメンテナンス及びソフトウェアインストールプロセスにおいてＲＸＳＷＩＮとソフトウェアバージョンとの間の一貫性を確かにし、かつ、車両ソフトウェアの正常なアップグレードを確保するために、使用され得る。

このようにして、システム内でソフトウェアバージョン情報と識別番号との間の不一致を示すアラーム情報は、ユーザインターフェース上でユーザに直感的に表示され得る。これは、ユーザがその後の処理をタイムリーに行うのを助け、更には、車両ソフトウェアの正常なアップグレードを確保する。

第２の態様に従って、本願の実施形態は、ＴＡに基づいた通信装置を提供する。通信ユニットは、第１情報及び第２情報を取得するよう構成され、第１情報は第１ソフトウェアバージョン情報及び／又は第１識別番号を含み、第２情報は第１マッピングを含み、第１マッピングは第２ソフトウェアバージョン情報と第２識別番号との間の関連付け関係を含み、識別番号はソフトウェアバージョンのパーミッション情報を示す。処理ユニットは、第１情報及び第２情報に基づいて、第１ソフトウェアバージョン情報と第１マッピングに対応する第２ソフトウェアバージョン情報との間の一致を検証するよう更に構成される。

第２の態様を参照して、可能な実施において、処理ユニットは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致せず、かつ／あるいは、第１識別番号が第２識別番号と一致しないとき、第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致しないと決定するよう、又は第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致し、かつ／あるいは、第１識別番号が第２識別番号と一致するとき、第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致すると決定するよう特に構成される。

第２の態様を参照して、可能な実施において、処理ユニットは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するよう、又は第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するよう更に構成される。

第２の態様を参照して、可能な実施において、通信ユニットは、第１タスクを第１車両へ送信するよう特に構成され、第１タスクは第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するよう指示する。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１タスクは第１マッピングを含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１タスクは第２マッピングを含む。第２マッピングは、第３ソフトウェアバージョン情報と第３識別番号との間の関連付け関係を含む。第３ソフトウェアバージョン情報は、第２ソフトウェアバージョン情報とは異なり、かつ／あるいは、第３識別番号は、第２識別番号とは異なる。

第２の態様を参照して、可能な実施において、通信ユニットは、第１ソフトウェアパッケージを第１車両へ送信するよう更に構成され、第１ソフトウェアパッケージは、第１車両に対応するソフトウェアバージョン情報を更新するために使用される。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアパッケージは第２識別番号を含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１ソフトウェアパッケージは第３識別番号を含む。

第２の態様を参照して、可能な実施において、通信ユニットは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアバージョン情報、第１識別番号、及び／又はアラーム情報をサーバ及び／又は第１車両の表示デバイスへ送信するよう更に構成され、アラーム情報は、第１車両の識別番号及び／又はソフトウェアバージョン情報がサーバのマッピング関係と一致しないことを示す。

第２の態様を参照して、可能な実施において、通信ユニットは、サーバから第１タスクを受信するよう特に構成され、第１タスクは、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するよう指示する。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１タスクは第１マッピングを含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１タスクは第２マッピングを含む。第３ソフトウェアバージョン情報は、第２ソフトウェアバージョン情報とは異なり、かつ／あるいは、第３識別番号は、第２識別番号とは異なる。

第２の態様を参照して、可能な実施において、通信ユニットは、サーバから第１ソフトウェアパッケージを受信するよう更に構成され、第１ソフトウェアパッケージは、第１車両に対応するソフトウェアバージョン情報を更新するために使用される。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアパッケージは第２識別番号を含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１ソフトウェアパッケージは第３識別番号を含む。

第２の態様を参照して、可能な実施において、通信ユニットは、Ｎが正の整数であるとして、Ｎ個の電子制御ユニットへＮ個の電子制御ユニットに対応する第１ソフトウェアパッケージを送信するよう特に構成される。通信ユニットは、Ｎ個の電子制御ユニットからＮ個のソフトウェアインストール結果を受信するよう特に構成される。処理ユニットは、Ｎ個のソフトウェアインストール結果により、Ｎ個のソフトウェアパッケージのうちのいずれか１つ以上がインストールに失敗したことが示されるとき、第１車両の車両ソフトウェアバージョン及び識別番号をロールバックするよう特に構成される。

可能な実施において、通信ユニットは、第１車両からアラーム情報を受信するよう特に構成され、表示ユニットは、アラーム情報を表示するよう特に構成される。

第２の態様を参照して、可能な実施において、識別番号は、第１法規関連ソフトウェア識別番号ＲＸＳＷＩＮを含む。

第３の態様に従って、本願の実施形態はコンピュータ可読記憶媒体を提供する。コンピュータ可読記憶媒体はコンピュータプログラム又は命令を記憶する。コンピュータプログラム又は命令がコンピュータで実行されると、コンピュータは、第１の態様又は第１の態様の可能な実施のうちのいずれか１つに従うＯＴＡに基づいた通信方法を実行することができる。

第４の態様に従って、本願の実施形態はＯＴＡに基づいた通信装置を提供する。装置はプロセッサ及びメモリを含む。メモリは命令を記憶する。命令がプロセッサによって実行されると、第１の態様又は第１の態様の可能な実施のうちのいずれか１つに従うＯＴＡに基づいた通信方法が実施される。

第５の態様に従って、本願は、チップ又はチップシステムを提供する。チップ又はチップシステムは、少なくとも１つのプロセッサ及び通信インターフェースを含む。通信インターフェース及び少なくとも１つのプロセッサは、ラインにより相互接続される。少なくとも１つのプロセッサは、コンピュータプログラム又は命令を実行して、第１の態様又は第１の態様の可能な実施のうちのいずれか１つに従うＯＴＡに基づいた通信方法を実施するよう構成される。チップの通信インターフェースは、入力／出力インターフェース、ピン、回路、などであってよい。

可能な実施において、本願で記載されるチップ又はチップシステムは、少なくとも１つのメモリを更に含み、少なくとも１つのメモリは命令を記憶する。メモリは、チップ内の記憶ユニット、例えば、レジスタ又はキャッシュであってよく、あるいは、チップの記憶ユニット（例えば、読み出し専用メモリ又はランダムアクセスメモリ）であってよい。

第６の態様に従って、本願の実施形態はコンピュータプログラム製品を提供する。コンピュータプログラム製品が１つ以上のプロセッサで実行されると、第１の態様又は第１の態様の可能な実施のうちのいずれか１つに従う方法が実行される。

本願の第２の態様から第６の態様の技術的解決法は、本願の第１の態様の技術的解決法に対応し、それら他の態様及び対応する実行可能な実施によって達成される有利な効果は、同様である。詳細は再び記載されない。

本願の実施形態に従う、ＲＸＳＷＩＮとソフトウェアバージョンとの間の対応の模式図である。 本願の実施形態に従う第１適用シナリオの模式図である。 本願の実施形態に従う車両ソフトウェア更新のためのシステムアーキテクチャの模式図である。 本願の実施形態に従う第２適用シナリオの模式図である。 本願の実施形態に従う第３適用シナリオの模式図である。 本願の実施形態に従うＯＴＡに基づいた通信方法の概略フローチャートである。 本願の実施形態に従う、クラウドによって識別番号とソフトウェアバージョン情報との間の一貫性を保つ概略フローチャートである。 本願の実施形態に従う、車両エンドにより識別番号とソフトウェアバージョン情報との間の一貫性を保つ概略フローチャートである。 本願の実施形態に従う、アラーム情報を表示するインターフェースの模式図である。 本願の実施形態に従う、クラウドによって一致決定を行う概略フローチャートである。 本願の実施形態に従うソフトウェア更新の概略フローチャートである。 本願の実施形態に従う、クラウドによって車両エンドへソフトウェアパッケージを配信する概略フローチャートである。 本願の実施形態に従う、車両エンドでソフトウェアパッケージをインストールする概略フローチャートである。 本願の実施形態に従う、車両エンドでソフトウェアパッケージをインストールする他の概略フローチャートである。 本願の実施形態に従うＯＴＡに基づいた通信装置の構造の模式図である。 本願の実施形態に従う制御デバイスのハードウェア構造の模式図である。 本願の実施形態に従うチップの構造の模式図である。

本願の実施形態における技術的解決法について明りょうに記載すべく、「第１」及び「第２」などの語が、基本的に同じ機能又は目的を有する同じアイテム又は類似したアイテムを区別するために本願の実施形態で使用されている。例えば、第１識別番号及び第２識別番号は、異なる識別番号を区別するために使用され、第１識別番号及び第２識別番号は制限されない。当業者であれば、「第１」及び「第２」などの用語が数量又は実行順序を限定するものではなく、「第１」及び「第２」などの用語が明確な差違を示すものではないことを理解し得る。

本願において、「例」又は「例えば」などの用語は、例、事例、又は実例を表すために使用されることが留意されるべきである。本願において「例」又は「例えば」と記載される任意の実施形態又は設計スキームは、他の実施形態又は設計スキームよりも好ましいもの又は有利なものであると解釈されるべきではない。まさに、「例」又は「例えば」などの用語の使用は、関連する概念を具体的に提示するよう意図される。

本願において、「少なくとも１つ」は１つ以上を意味し、「複数の～」は２つ以上を意味する。「及び／又は」は、関連するオブジェクトの間の関連付け関係を記載し、３つの関係が存在する可能性があることを表す。例えば、Ａ及びＢは、次の場合：Ａのみ存在、ＡとＢの両方が存在、及びＢのみ存在、を表し得る。ここで、Ａ及びＢのみは単数又は複数であってよい。「／」という文字は、一般に、関連するオブジェクトの間の“論理和”関係を示す。続くアイテム（片）の少なくとも１つ又はその類似した表現は、単一のアイテム（片）又は複数のアイテム（片）の任意の組み合わせを含むこれらのアイテムの任意の組み合わせを示すものである。例えば、ａ、ｂ、又はｃの少なくとも１つ（片）は：ａ、ｂ、ｃ、ａとｂ、ａとｃ、ｂとｃ、又はａとｂとｃを表すことができ、ここで、ａ、ｂ、及びｃは単数又は複数であってよい。

自動運転の発展とともに、人々は、車両の計算及び制御の能力に対する要求をますます高めている。ソフトウェアの形でユーザに提供される機能の数は増えている。従って、ソフトウェアにより定義された車両が、車両開発の重要なトレンドになりつつある。コンピュータ又はスマートフォンのような、ソフトウェアにより定義された車両は、ソフトウェアを容易にインストール及び更新することができる必要があるので、車両の様々な機能は頻繁に使用及び更新され得る。一般に、車両ソフトウェアが更新される必要があるとき、車両ソフトウェアを更新するために、ユーザは車両を４Ｓ店又は整備工場まで運転し、専門の技術者は専用装置を使用して車両ソフトウェアをリフレッシュする。車両ＯＴＡは、遠隔で車両ソフトウェアをアップグレードしたり又は車両ソフトウェアの欠陥を修正したりするための技術的手段を提供する。ユーザは、ＯＴＡ技術を使用してクラウドに接続し、ソフトウェアをダウンロード及びインストールし得る。ＯＴＡは、車両ソフトウェアのアップグレードにかかる時間及び空間の制限を軽減できる。このため、ＯＴＡは車両分野で広く使用されている。

しかし、ＯＴＡは、人々に利便性をもたらすと同時に、車両のアドミッションに対する課題ももたらす。アドミッションは、車両が市場に投入される前に、関連する標準規格の要求を満足するために、安全性、排気、などに対する一連のテストが実行されるプロセスとして理解され得る。具体的に、車両の欠陥により、人身及び財産に重大な損失が生じることがある。このため、車両は特別な製品である。市場に出す前に、車両はアドミッションテストを通過する必要がある。車両は、アドミッションテストを通過した後にのみ市場に投入できる。車両製品がアドミッションテストに申し込んで合格した後、車両の監督機関は、車両のアドミッション情報を記録し、社会に公表することがある。公表後、車両は販売可能になる。公表には、車両の車輪距離、重量、又は排気などの基本情報が含まれることがあり、更には、耐久走行距離又は最高車両速度などの技術的特徴パラメータ情報が含まれる場合がある。

アドミッション後の車両の製造一貫性を確かにすべく、監督部門は、定期的に、車両製品の関連するパラメータを抜き打ち検査し、それらのパラメータを公表情報と比較することがある。公表情報がアドミッションパラメータと一致しない場合には、製造一貫性は破られており、車両製造者は、訂正を行うよう求められ得るか、あるいは、車両製造者は、製造停止などの対策を実施するよう求められ得る。

車両が市場に投入された後、車両ソフトウェアは、ＯＴＡを使用することによって更新されることがある。しかし、更新プロセスにおいて、アドミッション中に測定されたソフトウェアのテストパラメータは変更される可能性がある。例えば、車両のバッテリ管理ソフトウェアがＯＴＡを使用することによってアップグレードされた後、車両の耐久走行距離が増えることあり、車両の耐久走行距離は、アドミッション中に測定された耐久走行距離と一致しなくなる。更に、車両のアドミッション中にテストされたデータは無効になり、テストが再び行われる必要がある。従って、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンは、アドミッション中に使用されたソフトウェアバージョンと一致しないことがある。これは、ＯＴＡの開発に課題をもたらす。これに基づいて、国際連合欧州経済委員会（Ｕｎｉｔｅｄ Ｎａｔｉｏｎｓ Ｅｃｏｎｏｍｉｃ Ｃｏｍｍｉｓｓｉｏｎ ｆｏｒ Ｅｕｒｏｐｅ，ＵＮＥＣＥ）の傘下にある自動車基準調和世界フォーラムは、ＯＴＡ作業部会を設立し、アドミッション監督システムへのＯＴＡの組み込みを議論している。車両のＯＴＡがアドミッションの一貫性に影響を与える可能性がある場合、ＯＴＡアップグレードを実行する前にアドミッション監督機関にアドミッションの変更を申請する必要があることが述べられている。そのような変更を監督すべく、法規関連ソフトウェア識別番号（ｒｘ ｓｏｆｔｗａｒｅ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｎｕｍｂｅｒ，ＲＸＳＷＩＮ）が提案されている。ＲＸＳＷＩＮは、ソフトウェアバージョンとアドミッションとの間の関係を記録することができる。ＲＸＳＷＩＮの機能は、アドミッション規制の観点から、アドミッションに影響を及ぼすソフトウェア及びソフトウェアアップグレードを記録及び追跡し、アドミッション監督機関が車両ソフトウェアのアップグレードを管理するのを助けることである。ＲＸＳＷＩＮの変更は、ソフトウェアのアップグレードによって引き起こされたアドミッションの変更を示すことができる。

例えば、図１は、本願の実施形態に従う、ＲＸＳＷＩＮとソフトウェアバージョンとの間の対応の模式図である。図１のａに示されるように、初期ＲＸＳＷＩＮ及び初期ＲＸＳＷＩＮに対応するソフトウェアバージョンは、アドミッション中に設定されてよい。例えば、初期ＲＸＳＷＩＮはＲ７９ １１０である。Ｒ７９ １１０に対応するソフトウェアバージョンには、パワーステアリング電子制御ユニット（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌ ｕｎｉｔ，ＥＣＵ）に対応するソフトウェアバージョンｖ１．０、車体安定化ＥＣＵに対応するソフトウェアバージョンｖ２．０、及び車両制御ＥＣＵに対応するソフトウェアバージョンｖ１．０が含まれ得る。

ソフトウェアがＯＴＡを使用することによってアップグレードされた後、アップグレードされたソフトウェアは、図１のｂに示されるように、アップグレードされたＲＸＳＷＩＮとソフトウェアバージョンとの間の対応の模式図で示され得る。この場合に、ＯＴＡを使用することによってアップグレードされたソフトウェアは、アドミッション中にソフトウェアに対応するテストデータを変更しない。従って、アドミッションに影響を及ぼさないソフトウェアがアップグレードされた後、ＲＸＳＷＩＮに関連したソフトウェアバージョン情報は変更され得るが、ＲＸＳＷＩＮは変更されないままである。この場合に、Ｒ７９ １１０に対応するソフトウェアバージョンには、パワーステアリングＥＣＵに対応するソフトウェアバージョンｖ１．１、車体安定化ＥＣＵに対応するソフトウェアバージョンｖ２．２、及び車両制御ＥＣＵに対応するソフトウェアバージョンｖ１．０が含まれ得る。

ソフトウェアがＯＴＡを使用することによって更にアップグレードされた後、アップグレードされたソフトウェアは、図１のｃに示されるように、アドミッションに影響を及ぼすアップグレードされたソフトウェアのＲＸＳＷＩＮとソフトウェアバージョンとの間のマッチング関係の模式図で示され得る。アドミッションに影響を及ぼすソフトウェアがアップグレードされた後、ＲＸＳＷＩＮに関連したソフトウェアバージョン情報は変更され、ＲＸＳＷＩＮは変更される。例えば、ＲＸＳＷＩＮはＲ７９ １１０からＲ７９ １１１に変更される。この場合に、Ｒ７９ １１１に対応するソフトウェアバージョンには、パワーステアリングＥＣＵに対応するソフトウェアバージョンｖ２．０、車体安定化ＥＣＵに対応するソフトウェアバージョンｖ２．２、及び車両制御ＥＣＵに対応するソフトウェアバージョンｖ１．０が含まれ得る。ＯＴＡアップグレードは、パワーステアリングＥＣＵに対応するソフトウェアバージョンが元のｖ１．１からｖ２．０にアップグレードされることを可能にする。パワーステアリングＥＣＵのアップグレードは、アドミッション中のソフトウェアに対応するテストパラメータの変更をもたらす。従って、ＲＸＳＷＩＮはＲ７９ １１０からＲ７９ １１１に変更され、ＲＸＳＷＩＮは、ＯＴＡアップグレードがアドミッションパラメータに影響を及ぼすことを特定する。

言い換えれば、図１に示されるように、ＲＸＳＷＩＮは、ＯＴＡに基づいたソフトウェアアップグレードに適用されてよく、ＲＸＳＷＩＮとソフトウェアバージョンとの間の対応を示す。しかし、ＯＴＡメンテナンス及びソフトウェアインストールプロセスにおいて、車両エンド及びクラウドでのＲＸＳＷＩＮとソフトウェアバージョンとの間の一貫性は確保され得ず、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合は、適切に排除され得ない。その結果、車両ソフトウェアの安全なアップグレードを維持することは難しい。現在、ＲＸＳＷＩＮを管理し、車両エンド及び／又はクラウドでＲＸＳＷＩＮとソフトウェアバージョンとの間の一貫性を保つための適切な方法は、存在しない。

これを鑑み、本願の実施形態は、ＯＴＡメンテナンス及びソフトウェアインストールプロセスにおいて第１情報及び第２情報を取得し、第１情報及び第２情報における識別番号とソフトウェアバージョンとの間のマッチングを使用することによって、識別番号とソフトウェアバージョンとの間のマッチング関係に基づいて、第１情報と第２情報との間の一致を検証するように、ＯＴＡに基づいた通信方法及び装置を提供する。更に、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合は、車両ソフトウェアの正常なアップグレードを確保するように、車両エンド及び／又はクラウドでソフトウェアバージョンと識別番号との間の一貫性を保つことによって取り除かれ得る。

任意に、識別番号はＲＸＳＷＩＮであってよい。

本願の実施形態における方法をより良く理解すべく、以下は最初に、本願の実施形態が適用される適用シナリオについて記載する。

可能な実施において、本願の実施形態で提供されるＯＴＡに基づいた通信方法は、識別番号とソフトウェアバージョン情報との間の一貫性が車両エンドとクラウドデバイスとの間のデータ交換によって保たれるシナリオや、車両ソフトウェアがダウンロード又は更新されるシナリオなどの、様々なタイプの車両のＯＴＡメンテナンス及びアップグレードシナリオに適用されてもよい。１つ以上の車両エンド及び／又はクラウドデバイスが存在してもよい。

車両エンド（又は車両若しくは車両エンドデバイスと呼ばれる）は、ソフトウェアアップグレードを実行する任意の形態の車両、任意の形態の車両補助デバイス（例えば、車両充電パイル）、などであってよい。これは本願の実施形態で特に制限されない。

クラウド（又はクラウドデバイス若しくはサーバと呼ばれる）は、車両アップグレードパッケージを配信するよう構成されるＯＴＡサーバであってよく、あるいは、プロキシサーバであってもよい。例えば、プロキシサーバは、車両小隊にサービスを提供するサーバであってよい。クラウドデバイスがプロキシサーバであるとき、プロキシサーバは、最初に、双方向認証によりＯＴＡサーバとの安全な通信を確立してよい。次いで、プロキシサーバは、車両のハードウェア及びソフトウェア情報をＯＴＡサーバへ送信する。車両アップグレードパッケージを生成した後、ＯＴＡサーバは、車両アップグレードパッケージをプロキシサーバへ配信してよい。ＯＴＡサーバは、代替的に、車両アップグレードパッケージをブロックに分け、ブロックを複数のプロキシサーバへ配信してもよいことが理解され得る。

代替的に、クラウドは、ソフトウェアをアップグレードするよう構成されるソフトウェアクライアントサーバであってもよく、あるいは、ソフトウェアクライアントサーバからソフトウェアを取得及び更新した小隊サーバ又は任意の他の可能なサーバであってもよい。

代替的に、クラウドは、任意の形態の車両、任意の形態の車両補助デバイス（例えば、車両充電パイル）、又はモバイル端末（例えば、携帯電話機、タブレット、若しくはウェアラブルデバイス）であってもよい。これは本願の実施形態で特に制限されない。

車両及びクラウドデバイスは通信接続を確立してよい。例えば、車両及びクラウドデバイスは、ハイパーテキスト転送プロトコル（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ，ＨＴＴＰ）又はハイパーテキスト転送プロトコル・オーバー・セキュアソケットレイヤ（ｈｙｐｅｒｔｅｘｔ ｔｒａｎｓｆｅｒ ｐｒｏｔｏｃｏｌ ｏｖｅｒ ｓｅｃｕｒｅ ｓｏｃｋｅｔ ｌａｙｅｒ，ＨＴＴＰＳ）のようなプロトコルを使用することによって、通信接続を確立してもよい。これは本願の実施形態で制限されない。

図２は、本願の実施形態に従う第１適用シナリオの例の模式図である。図２に示されるように、シナリオは、車両２０１及びソフトウェアＯＴＡクラウドデバイス２０２を含み得る。車両２０１は、ソフトウェアＯＴＡクライアントがインストールされている任意の形態の車両である。ソフトウェアＯＴＡクラウドデバイス２０２は、ＯＴＡアップグレードを提供するサーバであり、ソフトウェアパッケージを記憶すること、識別番号（例えば、ＲＸＳＷＩＮ）とソフトウェアバージョンとの間のマッピング関係を記憶すること、などのために構成される。車両２０１のソフトウェアを更新するとき、ソフトウェアＯＴＡクラウドデバイス２０２は、車両２０１内のソフトウェアＯＴＡクライアント上の各ソフトウェアの識別番号及び／又はソフトウェアバージョン情報を取得し、識別番号及び／又はソフトウェアバージョン情報を、ソフトウェアＯＴＡクラウドデバイス２０２に記憶されている、識別番号とソフトウェアバージョンとの間のマッピング関係と比較してよい。車両２０１の各ソフトウェアの識別番号及び／又はソフトウェアバージョン情報がマッピング関係と一致するとき、ソフトウェアＯＴＡクラウドデバイス２０２は、車両２０１内のソフトウェアＯＴＡクライアントへソフトウェアパッケージを自動的に送信するか、又はソフトウェアＯＴＡクライアントのリクエストコマンドに従って送信してよく、このとき、ソフトウェアパッケージは識別番号を含む。車両２０１のソフトウェアＯＴＡクライアントは、ソフトウェアＯＴＡクラウドデバイス２０２からのソフトウェアパッケージに基づいてソフトウェア及び識別番号をアップグレードしてよい。

１つ以上の車両２０１及び１つ以上のソフトウェアＯＴＡクラウドデバイス２０２が存在してもよい。これは本願の実施形態で特に制限されない。

可能な実施において、ソフトウェアＯＴＡクラウドデバイスは、代替的に、車両製造者ＯＴＡクラウドデバイスであってもよい。この場合に、車両製造者ＯＴＡクラウドデバイスは、車両アップグレードパッケージを配信するよう構成されるＯＴＡサーバであってもよい。

以下は、車両においてソフトウェアＯＴＡクラウドデバイス及び車両製造者ＯＴＡクラウドデバイスを実装するプロセスについて記載する。例えば、図３は、本願の実施形態に従う、車両ソフトウェアを更新するシステムアーキテクチャの模式図である。図３に示されるように、システムは、車両製造者ＯＴＡクラウドデバイス３０１、ソフトウェアＯＴＡクラウドデバイス３０２、マスターＯＴＡクライアント３０３、及びソフトウェアＯＴＡクライアント３０４を含み得る。

車両製造者ＯＴＡクラウドデバイス３０１は、車両製造者又は車両ソフトウェアサービスプロバイダのサーバであってよく、車両ソフトウェアを管理し、ソフトウェアデータを記憶するよう構成される。車両ソフトウェアは、車体制御ソフトウェアなどを含んでもよい。ソフトウェアＯＴＡクラウドデバイス３０２は、ソフトウェアパッケージを記憶すること、識別番号とソフトウェアバージョン情報との間のマッピング関係を記憶すること、などのために構成されてよい。車両製造者ＯＴＡクラウドデバイス３０１は、ソフトウェアＯＴＡクラウドデバイス３０２と相互作用してもよい。車両製造者ＯＴＡクラウドデバイス３０１のソフトウェア情報はソフトウェアＯＴＡクラウドデバイス３０２からであり、あるいは、車両製造者ＯＴＡクラウドデバイス３０１がソフトウェア情報を決定してもよい。

車両でのＯＴＡアップグレードには２つのレベル：マスターノード及び下位ノードが含まれ得ることが留意されるべきである。図３に示されるように、マスターＯＴＡクライアント３０３はマスターノードに対応し、車両アップグレードパッケージを受信し、車両アップグレードパッケージを分割し、分割したアップグレードパッケージを、マスターＯＴＡクライアント３０３によって制御される複数の下位クライアントへ分配してよい。ソフトウェアＯＴＡクライアント３０４は下位ノードに対応し、マスターＯＴＡクライアント３０３によって制御される下位ＯＴＡクライアントであってよい。ソフトウェアＯＴＡクライアント３０４は、ソフトウェア更新を実行するために車両ＯＴＡアップグレードの部分として使用されてよい。

従って、システムアーキテクチャには２つの可能なソフトウェア更新方法が存在する。可能な実施において、ソフトウェアＯＴＡクラウドデバイス３０２は、ソフトウェアを更新するために、ソフトウェアＯＴＡクライアント３０４と相互作用する。具体的な実施プロセスは、図１に示される適用シナリオの記載と一致する。詳細はここで再び記載されない。

他の可能な実施において、車両製造者ＯＴＡクラウドデバイス３０１、マスターＯＴＡクライアント３０３、及びソフトウェアＯＴＡクライアント３０４は、ソフトウェアを更新するために、互いに相互作用する。例えば、車両製造者ＯＴＡクラウドデバイス３０１は、車両製造者ＯＴＡクラウドデバイス３０１に記憶されている、識別番号とソフトウェアバージョン情報との間のマッピング関係と、マスターＯＴＡクライアント３０３（若しくはソフトウェアＯＴＡクライアント３０４）から取得されたソフトウェアバージョン及び／又は識別番号の一貫性とに基づいて、車両アップグレードパッケージを使用することによってマスターＯＴＡクライアント３０２へ、更新される必要があるソフトウェアパッケージを送信してよい。マスターＯＴＡクライアント３０２は、車両アップグレードパッケージを受信及びダウンロードし、車両アップグレードパッケージを分割し、分割した車両アップグレードパッケージをソフトウェアＯＴＡクライアント３０４へ送信する。ソフトウェアＯＴＡクライアント３０４は、分割された車両アップグレードパッケージ内のソフトウェアパッケージに基づいてソフトウェア及び識別番号を更新する。

図４は、本願の実施形態に従う第２適用シナリオの例の模式図である。図４に示されるように、適用シナリオには、サーバ４０１、第１車両４０２、第２車両４０３、第２車両４０４、及び第２車両４０５が含まれ得る。

サーバ４０１は車両小隊サーバであってよい。車両小隊サーバは、前もってＯＴＡサーバから、車両小隊サーバによってサービスを提供される車両小隊（例えば、第１車両４０２、第２車両４０３、第２車両４０４、及び第２車両４０５を含む）によって必要とされる車両アップグレードパッケージを取得してよい。

車両小隊の定期メンテナンス中、ワイヤレス・フィデリティ（ｗｉｒｅｌｅｓｓ－ｆｉｄｅｌｉｔｙ，Ｗｉ－Ｆｉ）などのネットワーク接続の場合に、第１車両４０２、第２車両４０３、第２車両４０４、及び第２車両４０５は車両小隊サーバへ接続される。アップグレードパッケージダウンロード通知を受信すると、車両小隊サーバは、第１車両４０２、第２車両４０３、第２車両４０４、及び第２車両４０５と双方向認証（例えば、公開鍵インフラストラクチャに基づいた認証方法）を実行する。認証が成功した後、車両小隊サーバは、アップグレードパッケージの暗号鍵ｋを暗号化し（車両の公開鍵を使用することによって暗号化し）、暗号化された暗号鍵ｋを第１車両４０２、第２車両４０３、第２車両４０４、及び第２車両４０５へ配信する。

例えば、第１車両４０２、第２車両４０３、第２車両４０４、及び第２車両４０５は全て、鍵ｋを使用することによって鍵を暗号解読し、第１車両４０２、第２車両４０３、第２車両４０４、及び第２車両４０５によって必要とされている車両ソフトウェアパッケージをサーバからダウンロードしてよい。例えば、第１車両４０２は、完全な車両アップグレードパッケージに基づいてソフトウェア更新を完了してもよい。車両アップグレードパッケージは、識別番号を更新するために使用されるソフトウェアパッケージを含み得る。第１車両４０２は、ソフトウェアパッケージに基づいてソフトウェア及び識別番号を更新してもよい。

図５は、本願の実施形態に従う第３適用シナリオの例の模式図である。図５に示されるように、適用シナリオには、車両５０１及び車両補助デバイス５０２が含まれ得る。車両５０１は、任意の形態の車両であってよい。車両補助デバイス５０２は、車両充電パイル又は車両ＯＴＡ更新を支援する任意の他の端末デバイス（例えば、携帯電話機又はタブレット）であってよい。車両補助デバイス５０２は、車両５０１に対して、車両補助デバイス５０２に記憶されている、識別番号とソフトウェアバージョンとの間のマッピング関係と、車両５０１から取得されたソフトウェアバージョン及び／又は識別番号の一貫性とに基づいて、更新される必要があるソフトウェアパッケージを送信してよい。車両５０１は、受信したソフトウェアパッケージに基づいてソフトウェア及び識別番号を更新してよい。

本願の実施形態の理解を助けるべく、本願のいくつかの用語について最初に簡単に説明する。

１．車両ＯＴＡは、車両が車両のシステムを更新するためにネットワークを通じて遠隔サーバからソフトウェア更新パッケージをダウンロードするプロセスである。例えば、しかし制限なしに、車両ＯＴＡの夫々の更新は、１つの車両アップグレードパッケージ及び１つの車両バージョン番号に対応し、１つの車両アップグレードパッケージは、車両の複数のＥＣＵのソフトウェアを含む。

２．車両製造者ＯＴＡクラウドデバイスは、車両製造者又はサービスプロバイダによって提供されるクラウドサービスを指す。車両製造者ＯＴＡクラウドデバイスは、クラウド上でアップグレードタスク、ソフトウェアアップグレードパッケージ、識別番号、などに関する情報を管理することと、ＯＴＡ方式で、情報を、ソフトウェアがアップグレードされる必要がある車両へ配信することとに関与する。ＯＴＡ方式では、アクセスは、Ｗｉ－Ｆｉ、ロング・ターム・エボリューション（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ，ＬＴＥ）、第５世代（５ｔｈ ｇｅｎｅｒａｔｉｏｎ，５Ｇ）移動体通信システム又はニュー・ラジオ（ｎｅｗ ｒａｄｉｏ，ＮＲ）システム、衛星、などを使用することによって実行されてよい。

３．ソフトウェアＯＴＡクラウドデバイスは、ソフトウェア用のクラウドサービスを指す。ソフトウェアＯＴＡクラウドデバイスは、クラウド上で特定の車両ソフトウェア、識別番号、などに関する情報を管理することと、ＯＴＡ方式で、情報を、アップグレードを必要とするユーザ又はアップグレードされる必要がある車両へ配信することとに関与する。

本願の実施形態における車両製造者ＯＴＡクラウドデバイス又はソフトウェアＯＴＡクラウドデバイスは、ＯＴＡクラウドと総称されてもよく、ソフトウェア及び識別番号を更新するよう構成される。

４．マスターノード（更新マスター、略してマスターノード）は、車両のＥＣＵにデプロイされているソフトウェアである。マスターノードは、中央集権的に車両ＯＴＡのアップグレードを制御することと、ＯＴＡクラウドから車両アップグレードパッケージをダウンロードすることと、車両アップグレードパッケージを分割することと、分割したアップグレードパッケージを対応するＥＣＵに分配することとに関与する。

代替的に、マスターノードは、車両に独立して存在するモジュールユニットであってもよい。これは本願の実施形態で制限されない。

５．電子制御ユニットは、自動運転コントローラ、コックピットコントローラ、テレマティクスボックス（ｔｅｌｅｍａｔｉｃｓ ｂｏｘ，Ｔ－Ｂｏｘ）、ゲートウェイ、などを含む。ＥＣＵのソフトウェアアップグレードのために、ソフトウェアアップグレードパッケージがＯＴＡクラウドからダウンロードされ、アップグレードを実行するようインストールされてよい。代替的に、マスターノードの中央集権的な制御及び協調の下で、マスターノードは、車両アップグレードパッケージを分割し、分割した車両アップグレードパッケージを分配して、アップグレードのためのソフトウェアアップグレードパッケージを取得する。

以下は、具体的な実施形態を使用することによって、本願の技術的解決法と、本願の技術的解決法を使用することによって前述の技術的課題をどのように解決するかとについて詳細に記載する。続くいくつかの具体的な実施形態は、独立して又は互いに組み合わせて実施されてよく、同じ又は類似した概念又はプロセスは、いくつかの実施形態では繰り返して記載されないことがある。

図６は、本願の実施形態に従うＯＴＡに基づいた通信方法の概略フローチャートである。図６に示されるように、方法は、次のステップを含み得る。

Ｓ６０１：第１情報及び第２情報を取得する。

本願のこの実施形態で、第１情報及び第２情報は、ソフトウェアバージョン情報と識別番号との間の一貫性を検証するために車両エンド及び／又はクラウドで使用される情報であってよい。例えば、第１情報は第１ソフトウェアバージョン情報及び／又は第１識別番号を含んでよく、第２情報は第１マッピングを含んでよい。第１マッピングは、第２ソフトウェアバージョン情報と第２識別番号との間の関連付け関係を含む。第１情報は車両エンドからであってよく、第２情報はクラウドからであってよい。

本願のこの実施形態で、識別番号は、ソフトウェアバージョンのパーミッション情報を示してもよい。パーミッションは、車両のアドミッションを許可することに対する制限と理解されてもよい。

例えば、識別番号は、ＲＸＳＷＩＮなどの他の識別子であってもよい。ソフトウェアバージョン情報は、異なるソフトウェアバージョンを識別するために使用される情報であってよい。例えば、ソフトウェアバージョン情報は、ソフトウェアバージョン番号などに関する他の情報であってもよい。

識別番号及びソフトウェアバージョン情報は、実際のシナリオに基づいて他の内容を含んでもよいことが理解され得る。これは本願のこの実施形態で制限されない。

例えば、第１情報及び第２情報を取得する主体は、クラウド又は車両エンドであってよい。実行主体がクラウドであるとき、車両エンドは、第１情報をクラウドへ報告してよく、次いで、クラウドは、車両エンドによって報告された第１情報を受信し、クラウドに記憶されている第２情報を取得してよく、更には、第１情報と第２情報との間の一致を検証してよい。代替的に、実行主体が車両エンドであるとき、クラウドは、第２情報を車両へ配信してよく、次いで、車両は、クラウドによって配信された第２情報を受信し、車両エンドに記憶されている第１情報を取得してよく、更には、第１情報と第２情報との間の一致を検証してよい。

Ｓ６０２：第１情報及び第２情報に基づいて、第１ソフトウェアバージョン情報と第１マッピングに対応する第２ソフトウェアバージョン情報との間の一致を検証する。

本願のこの実施形態で、第１ソフトウェアバージョン情報と第１マッピングに対応する第２ソフトウェアバージョン情報との間の一致には、次の場合が含まれ得る：第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致するか、又は第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致しない。

例えば、第１情報及び第２情報に基づいて、第１ソフトウェアバージョン情報と第１マッピングに対応する第２ソフトウェアバージョン情報との間の一致を検証するための２つの主体：クラウド又は車両エンド、が存在し得る。第１ソフトウェアバージョン情報と第１マッピングに対応する第２ソフトウェアバージョン情報との間の一致を検証する実行主体は、本願のこの実施形態で制限されないことが理解され得る。

まとめると、本願の実施形態は、ＯＴＡメンテナンス及びソフトウェアインストールプロセスにおいて車両からの第１情報及びクラウドからの第２情報を取得し、第１情報及び第２情報における識別番号及びソフトウェアバージョンの間のマッチング関係を使用することによって第１情報と第２情報との間の一致を検証するように、ＯＴＡに基づいた通信方法及び装置を提供する。更に、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合は、車両ソフトウェアの正常なアップグレードを確保するために、車両エンド及び／又はクラウドでソフトウェアバージョンと識別番号との間の一貫性を保つことによって取り除かれ得る。

図６に対応する実施形態に基づいて、可能な実施において、Ｓ６０１及びＳ６０２で示されるステップで、第１ソフトウェアバージョン情報と第１マッピングに対応する第２ソフトウェアバージョン情報との間の一致を検証する実行主体は、クラウド又は車両エンドであってよい。

例えば、方法１で、クラウドが、第１ソフトウェアバージョン情報と第１マッピングに対応する第２ソフトウェアバージョン情報との間の一致を検証するために使用される（図７に対応する実施形態で示される）。

方法２で、車両エンドが、第１ソフトウェアバージョン情報と第１マッピングに対応する第２ソフトウェアバージョン情報との間の一致を検証するために使用される（図８に対応する実施形態で示される）。

方法１：クラウドが、第１ソフトウェアバージョン情報と第２ソフトウェアバージョン情報との間の一致を検証するために使用される。

例えば、図７は、本願の実施形態に従う、クラウドによって識別番号とソフトウェアバージョンとの間の一貫性を保つ概略フローチャートである。図７に対応する実施形態で、クラウドが第１情報及び第２情報に基づいて第１ソフトウェアバージョン情報と第２ソフトウェアバージョン情報との間の一致を検証することは、クラウドがＯＴＡクラウドであり、車両エンドがマスターノード、ＥＣＵ１、及びＥＣＵ２を含み、識別番号がＲＸＳＷＩＮであり、第１マッピングがＲＸＳＷＩＮマッピング（ＲＸＳＷＩＮとソフトウェアバージョン情報との間の関連付け関係を含む）である例を使用することによって、記載される。この例は、本願のこの実施形態に対する制限を構成するものではない。

図７に示されるように、クラウドが識別番号とソフトウェアバージョン情報との間の一貫性を保つプロセスは、次のステップを含み得る。

Ｓ７０１：マスターノードは、各ＥＣＵ（ＥＣＵ１及びＥＣＵ２を含む）に関するソフトウェアバージョン情報を収集する。

例えば、マスターノードは、各ＥＣＵに関するソフトウェアバージョン情報を周期的に収集してよい。例えば、各ＥＣＵに関するソフトウェアバージョン情報は週に１回収集されることがセットされる。

Ｓ７０２：マスターノードは、車両エンドのソフトウェアバージョン情報をＯＴＡクラウドに報告する。

順応して、ＯＴＡクラウドは、車両エンドによって報告されたソフトウェアバージョン情報を受信する。

任意に、車両エンドがＲＸＳＷＩＮ識別子を記憶している場合に、車両エンドは、Ｓ７０２で示されるステップを実行してもよい。

Ｓ７０３：マスターノードは、車両エンドのＲＸＳＷＩＮ識別子をＯＴＡクラウドに報告する。

順応して、ＯＴＡクラウドは、車両エンドによって報告されたＲＸＳＷＩＮを受信する。

Ｓ７０４：ＯＴＡクラウドは、ＲＸＳＷＩＮ関連ソフトウェアバージョン情報の一貫性をチェックし、不一致の場合には、ソフトウェアアップグレードを実行する。

例えば、ＯＴＡクラウドは、Ｓ７０２に示されるステップで報告されたソフトウェアバージョン情報を、ＯＴＡクラウドに記憶されているＲＸＳＷＩＮマッピングテーブルと比較する。マスターノードによって報告されたソフトウェアバージョン情報がＲＸＳＷＩＮマッピングテーブル内のソフトウェアバージョン情報と一致しないとき、それは、アドミッション関連ソフトウェアが不適法に変更されていることを示し得る。この場合、ＯＴＡクラウドは、ＯＴＡを使用することによってソフトウェアをアップグレードし、車両エンドのソフトウェアを変更して、車両エンドのソフトウェアバージョン情報とＯＴＡクラウドに記憶されているＲＸＳＷＩＮマッピングテーブルとの間の一貫性を確かにし得る。

任意に、車両エンドがＲＸＳＷＩＮ識別子をクラウドに報告する場合に、クラウドは、Ｓ７０５に示されるステップを実行してもよい。

Ｓ７０５：ＯＴＡクラウドは、ＲＸＳＷＩＮ一致をチェックし、不一致の場合に、ＲＸＳＷＩＮを更新する。

例えば、ＯＴＡクラウドは、Ｓ７０３に示されるステップで報告されたＲＸＳＷＩＮ識別子を、ＯＴＡクラウドに記憶されているＲＸＳＷＩＮマッピングテーブルと比較する、車両エンドによって報告されたＲＸＳＷＩＮ識別子がＲＸＳＷＩＮマッピングテーブル内のＲＸＳＷＩＮ識別子と一致しないとき、それは、車両エンドのＲＸＳＷＩＮが改ざんされていることを示し得る。この場合に、ＯＴＡクラウドは、車両エンドのＲＸＳＷＩＮ識別子を更新するよう命令を配信して、車両エンドのＲＸＳＷＩＮ識別子とＯＴＡクラウドに記憶されているＲＸＳＷＩＮマッピングテーブルとの間の一貫性を確かにし得る。

ＯＴＡクラウドは、Ｓ７０４に示されるステップで、車両エンドのソフトウェアバージョン情報とクラウドのそれとの間の一致の決定に基づいて、ソフトウェアアップグレードを実行してもよく、Ｓ７０５に示されるステップで、車両エンドのＲＸＳＷＩＮとクラウドのそれとの間の一致の決定に基づいて、ソフトウェアアップグレードを実行してもよく、あるいは、Ｓ７０４及びＳ７０５に示されるステップで、車両エンドのソフトウェアバージョン情報とクラウドのそれとの間の一致と、車両エンドのＲＸＳＷＩＮとクラウドのそれとの間の一致とに基づいて、ソフトウェアアップグレードを実行すべきかどうかを決定してもよい、ことが理解され得る。

方法２：車両エンドが、第１ソフトウェアバージョン情報と第２ソフトウェアバージョン情報との間の一致を検証するために使用される。

例えば、図８は、本願の実施形態に従う、車両エンドによって識別番号とソフトウェアバージョンとの間の一貫性を保つ概略フローチャートである。図８に対応する実施形態で、車両エンドが第１情報及び第２情報に基づいて第１ソフトウェアバージョン情報と第２ソフトウェアバージョン情報との間の一致を検証することは、クラウドがＯＴＡクラウドであり、車両エンドがマスターノード、ＥＣＵ１、及びＥＣＵ２を含み、識別番号がＲＸＳＷＩＮであり、第１マッピングがＲＸＳＷＩＮマッピング（ＲＸＳＷＩＮとソフトウェアバージョン情報との間の関連付け関係を含む）である例を使用することによって、記載される。この例は、本願のこの実施形態に対する制限を構成するものではない。

図８に示されるように、車両エンドが識別番号とソフトウェアバージョン情報との間の一貫性を保つプロセスは、次のステップを含み得る。

Ｓ８０１：ＯＴＡクラウドは、ＲＸＳＷＩＮ及びＲＸＳＷＩＮマッピングテーブルをマスターノードへ配信する。

順応して、マスターノードは、ＯＴＡクラウドによって配信されたＲＸＳＷＩＮ及びＲＸＳＷＩＮマッピングテーブルを受信する。

例えば、ＯＴＡクラウドに記憶されているＲＸＳＷＩＮマッピングテーブル内のＲＸＳＷＩＮ識別子又は任意のソフトウェアバージョン情報が変更されるとき、ＯＴＡクラウドは、変更されたＲＸＳＷＩＮマッピングテーブルをマスターノードへ配信してよい。

Ｓ８０２：マスターノードは、各ＥＣＵ（ＥＣＵ１及びＥＣＵ２を含む）に関するソフトウェアバージョン情報を収集する。

Ｓ８０３：マスターノードは、ＲＸＳＷＩＮ関連ソフトウェアバージョン情報の一貫性をチェックする。

Ｓ８０４：ＲＸＳＷＩＮ関連ソフトウェアバージョン情報に一貫性がないとマスターノードが決定する場合に、マスターノードは、ＯＴＡクラウドへのアラームを生成し、一貫性がないソフトウェアバージョン情報を報告してよい。

例えば、Ｓ８０２に示されるステップで各ＥＣＵによって報告されたソフトウェアバージョン情報がＯＴＡクラウドによって配信されたＲＸＳＷＩＮマッピングテーブル内のソフトウェアバージョン情報と一致しないとマスターノードが決定する場合に、それは、車両エンドのアドミッション関連ソフトウェアが不適法な方法で変更されていることを示し得る。この場合に、マスターノードは、不一致メッセージをＯＴＡクラウドに報告してよい。

これに基づいて、第１ソフトウェアバージョン情報と第２ソフトウェアバージョン情報との間の一致は、クラウド又は車両エンドを使用することによって検証される。更に、ソフトウェアバージョン及び／又はＲＸＳＷＩＮが改ざんされることを防ぎ、かつ、ＯＴＡを使用することによってアップグレードされた車両ソフトウェアの正常なアップグレードを確保するように、車両エンド及び／又はクラウドでのソフトウェアバージョンとＲＸＳＷＩＮとの間の一貫性は保たれ得る。

図６に対応する実施形態に基づいて、可能な実施において、方法は、次のステップを更に含む。

Ｓ６０３（図示せず）：第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１車両は、第１ソフトウェアバージョン情報、第１識別番号、及び／又はアラーム情報をクラウド及び／又は第１車両の表示デバイスへ送信する。

順応して、表示デバイスは、第１車両から第１ソフトウェアバージョン情報、第１識別番号、及び／又はアラーム情報を受信してよい。本願のこの実施形態で記載される車両エンドには、第１車両が含まれ得る。

本願のこの実施形態で、アラーム情報は、車両の識別番号及びソフトウェアバージョン情報がサーバのマッピング関係と一致しないことを示す。表示デバイスは、第１車両の中央制御ディスプレイ、第１車両のダッシュボードディスプレイ、又は車両に接続されている他の表示デバイス、例えば、携帯電話機であってよい。本願のこの実施形態で、表示デバイスは、実際のシナリオに基づいて他の内容を含んでもよい。これは本願のこの実施形態で制限されない。

Ｓ６０４（図示せず）：表示デバイスはアラーム情報を表示する。

例えば、図９は、本願の実施形態に従う、アラーム情報を表示するインターフェースの模式図である。図９に示されるように、インターフェースは、第１車両の中央制御ディスプレイ９００に表示されるインターフェースであってよい。中央制御ディスプレイ９００に表示されるインターフェースは、ソフトウェアバージョン更新指示メッセージ９０１、システムプロンプトメッセージ９０２、停止コントロール９０３、及び継続コントロール９０４などの内容を含んでよい。指示メッセージ９０１は、「パワーステアリングソフトウェアＶ２．０（Ｒ７９ ９０）を更新中」と表示する。Ｖ２．０は、パワーステアリングソフトウェアのソフトウェアバージョン情報であってよく、Ｒ７９ ９０は、パワーステアリングソフトウェアのソフトウェアバージョンに対応する識別番号であってよい。

ソフトウェア更新が実行される前に、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないことを検出すると、第１車両は、アラーム情報を中央制御ディスプレイ９００へ送信してよく、このとき、アラーム情報は、中央制御ディスプレイ９００に表示されるシステムプロンプトメッセージ９０２であってよい。システムプロンプトメッセージ９０２は、「車両ソフトウェアは違法に改ざんされている可能性があります。可能な限り直ぐにこの問題に対処ください！」と表示する。その後に、プロンプトメッセージを送信すると、ユーザは、ソフトウェア更新を一時中断するよう停止コントロール９０３をトリガしてよく、あるいは、ユーザは、処理のために車両を４Ｓ店まで運転してもよい。

これに基づいて、システム内でソフトウェアバージョン情報と識別番号との間の不一致を示すアラーム情報は、ユーザインターフェース上でユーザに直感的に表示され得る。これは、ユーザがその後の処理をタイムリーに行うのを助け、更には、車両ソフトウェアの正常なアップグレードを確保する。

図６に対応する実施形態に基づいて、可能な実施において、Ｓ６０２は、次を含んでもよい。

実施において、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致せず、かつ／あるいは、第１識別番号が第２識別番号と一致しないとき、第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致しないと決定される。

次のように理解され得る：第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないか、第１識別番号が第２識別番号と一致しないか、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致せずかつ第１識別番号が第２識別番号と一致しないとき、第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致しないと決定される。

第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとは、次のように理解され得る：この場合に、第１識別番号は第２識別番号と一致している場合があり、あるいは、第１識別番号は第２識別番号と一致していない場合がある。第１識別番号が第２識別番号と一致しないとは、次のように理解され得る：この場合に、第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致している場合があり、あるいは、第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致していない場合がある。

他の実施において、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致し、かつ／あるいは、第１識別番号が第２識別番号と一致するとき、第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致すると決定される。

次のように理解され得る：第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するか、第１識別番号が第２識別番号と一致するか、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しかつ第１識別番号が第２識別番号と一致するとき、第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致すると決定される。

これに基づいて、クラウドが第１タスクを配信するシナリオにおいて、第１ソフトウェアバージョン情報及び／又は第１識別番号が第１マッピングと一致するとき、一貫性チェックに基づいて、ＯＴＡを使用することによってアップグレードされた車両ソフトウェアが正常にアップグレードされることは、更に確かにされ得る。クラウド及び／又は車両エンドが識別番号とソフトウェアバージョンとの間の一貫性を周期的にチェックするシナリオにおいて、第１ソフトウェアバージョン情報及び／又は第１識別番号が第１マッピングと一致しないとき、識別番号及び／又はソフトウェアバージョン情報が改ざんされることを防ぎ、かつ、ＯＴＡを使用することによってアップグレードされた車両ソフトウェアが正常にアップグレードされることを確かにするように、不一致により発生した不適法リスクはタイムリーに検出され得る。

図6に対応する実施形態に基づいて、可能な実施において、方法は、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新すること、又は第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新することを更に含んでもよい。

実施において、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないシナリオは次の通りであり得る：車両エンドの第１ソフトウェアバージョン情報及び／又は第１識別番号が改ざんされているために、車両エンドの第１ソフトウェアバージョン情報はクラウドの第２ソフトウェアバージョン情報と一致しない。更に、クラウドのソフトウェアバージョン情報と車両エンドのそれとの間の一致、及びクラウドの識別番号と車両エンドのそれとの間の一致を確かにするよう、クラウドは、クラウドに記憶されているソフトウェアバージョン情報及び／又は識別番号を車両エンドへ配信してもよい。クラウドによって配信されたソフトウェアバージョン情報及び／又は識別番号は、ソフトウェアバージョン情報及び／又は識別番号が改ざんされる前に車両エンドに記憶されていたソフトウェアバージョン情報及び／又は識別番号と一致していることがある。このシナリオでは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致する場合に、更新プロセスは、第１ソフトウェアバージョン情報及び／又は第１識別番号に対して実行され得ない。

例えば、不一致に基づいて第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するプロセスは、図７及び図８に対応する実施形態で説明されているようなものであってよい。詳細はここで再び記載されない。

他の実施において、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するシナリオは次の通りであり得る：クラウドは第１タスク（又は更新タスクと呼ばれる）を配信する。クラウドが、車両エンドによって報告された第１ソフトウェアバージョン情報及び／又は第１識別番号がクラウドに記憶されている第２ソフトウェアバージョン情報と一致すると決定するとき、クラウドは、一貫性保証に基づいて、第１タスクで運ばれるソフトウェアバージョン情報及び／又は識別番号を車両エンドに配信してよい。このシナリオでは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しない場合に、更新プロセスは、第１ソフトウェアバージョン情報及び／又は第１識別番号に対して実行され得ない。

例えば、図１０は、本願の実施形態に従う、クラウドによって一致決定を実行する概略フローチャートである。図１０に対応する実施形態で、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するときに第１ソフトウェアバージョン情報及び／又は第１識別番号を更新することは、クラウドがＯＴＡクラウドであり、車両エンドがマスターノードを含み、第１マッピングがＲＸＳＷＩＮマッピングであり、識別番号がＲＸＳＷＩＮである例を使用することによって、記載される。この例は、本願のこの実施形態に対する制限を構成するものではない。

図１０に示されるように、クラウドが一致決定を実行するプロセスは、次のステップを含み得る。

Ｓ１００１：ＯＴＡクラウドは、マスターノードに関するＲＸＳＷＩＮ識別子を収集する。

Ｓ１００２：ＯＴＡクラウドは、ＲＸＳＷＩＮ一致をチェックする。

例えば、ＯＴＡクラウドが、車両エンドのＲＸＳＷＩＮ識別子が第１マッピング内のＲＸＳＷＩＮ識別子と一致しないと決定する場合に、ＯＴＡクラウドは、ＯＴＡを実行しないと決定してもよい。

ＯＴＡクラウドが、車両エンドのＲＸＳＷＩＮ識別子が第１マッピング内のＲＸＳＷＩＮ識別子と一致すると決定する場合に、ＯＴＡクラウドは、更新タスクをマスターノードへ配信してよく、このとき、更新タスクは、新しいＲＸＳＷＩＮ識別子及びＲＸＳＷＩＮマッピングテーブルを運び得る。

Ｓ１００３：マスターノードは、新しいＲＸＳＷＩＮ識別子及びＲＸＳＷＩＮマッピングテーブルを記憶する。

これに基づいて、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合を取り除き、かつ、車両ソフトウェアの正常なアップグレードを確保するように、クラウド及び車両エンドは、識別番号とソフトウェアバージョンとの間のマッチング関係に基づいて、車両エンドのソフトウェアバージョン情報及び／又は識別番号とクラウドのマッピング関係との間の一貫性を保ち得る。

以上は、車両エンド及び／又はクラウドがソフトウェアバージョン情報と識別番号との間の一貫性を保つプロセスである。以下は、ＯＴＡを使用することによって車両ソフトウェアをアップグレードする過程でソフトウェアバージョン情報と識別番号との間の一貫性が確かにされるプロセスについて記載する。

例えば、図１１は、本願の実施形態に従う、ソフトウェアを更新する概略フローチャートである。図１１に示されるように、ソフトウェアを更新する主体には、クラウド及び第１車両が含まれ得る。第１車両は、マスターノード及び１つ以上のＥＣＵを含み得る。

図１１に示されるように、ソフトウェアを更新するプロセスは、次のステップを含み得る。

Ｓ１１０１：クラウドは第１タスクを第１車両へ送信する。

順応して、第１車両は第１タスクを受信し、第１タスクに基づいて第１ソフトウェアバージョン情報及び／又は第１識別番号を更新し得る。第１タスクを受信する主体は、第１車両のマスターノードであって。

本願のこの実施形態で、第１タスクは、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するよう指示する。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１タスクは第１マッピングを含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１タスクは第２マッピングを含む。第２マッピングは、第３ソフトウェアバージョン情報と第３識別番号との間の関連付け関係を含む。第３ソフトウェアバージョン情報は、第２ソフトウェアバージョン情報とは異なり、かつ／あるいは、第３識別番号は、第２識別番号とは異なる。

例えば、クラウドが、第１車両の第１ソフトウェアバージョン情報がクラウドの第２ソフトウェアバージョン情報と一致しないと決定するとき、この場合に、第１車両のソフトウェアバージョン及び／又は識別番号は改ざんされている可能性があることが理解され得る。この場合に、クラウドは、第１マッピングを含む第１タスクを送信してよい。第１マッピングは、第１車両のソフトウェアバージョン及び／又は識別番号が改ざんされる前にクラウドに記憶されている、ソフトウェアバージョンと識別番号との間の関連付け関係として理解され得る。

例えば、クラウドが、第１車両の第１ソフトウェアバージョン情報がクラウドの第２ソフトウェアバージョン情報と一致すると決定するとき、この場合に、第１車両デバイス及びクラウドは、ＯＴＡを使用することによってソフトウェアをアップグレードする前に実行された一致決定を通過したと理解され得る。この場合に、クラウドは、第２マッピングを含む第１タスクを送信してよい。第２マッピングは、新しいソフトウェアバージョン情報及び新しい識別番号を含む、ＯＴＡによってトリガされるマッピング関係として理解され得る。

ＯＴＡを使用することによってソフトウェアを更新することが、アドミッション中のソフトウェアに対応するテストパラメータを変更するには不十分であるとき、第２マッピング内の第３識別番号は、第１車両に記憶されている第１識別番号と一致し得ることが理解され得る。例えば、第１車両のバッテリ管理システムがＶ１．０である場合に、第１車両のシステムは５００ｋｍの耐久走行距離をサポートし得る。ソフトウェアアップグレードがＯＴＡを使用することによってバッテリ管理システムに対して実行されるとき、第１車両のバッテリ管理システムはＶ１．１に更新され、第１車両のシステムは５００ｋｍの耐久走行距離をサポートし得る。この場合に、バッテリ管理システムの更新は、アドミッション中の耐久走行距離の特定のパラメータを変更しない。従って、この場合に、第１車両がＯＴＡを使用することによってソフトウェアアップグレードを実行するとき、クラウドによって配信された第２マッピング内の第３ソフトウェアバージョン情報は、第１車両に記憶されている第１ソフトウェアバージョン情報と一致せず、第２マッピング内の第３識別番号は、第１車両に記憶されていると一致し得る。

Ｓ１１０２：クラウドは第１ソフトウェアパッケージを第１車両へ送信する。

順応して、第１車両は第１ソフトウェアパッケージを受信し、第１ソフトウェアパッケージに基づいて車両のソフトウェアを更新してよい。ソフトウェアパッケージは、ソフトウェア及びソフトウェアに対応するソフトウェアバージョン情報を含み得る。

本願のこの実施形態で、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアパッケージは第２識別番号を含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１ソフトウェアパッケージは第３識別番号を含む。

例えば、クラウドが、第１車両の第１ソフトウェアバージョン情報がクラウドの第２ソフトウェアバージョン情報と一致しないと決定するとき、この場合に、第１車両のソフトウェアバージョン及び／又は識別番号は改ざんされている可能性があることが理解され得る。この場合に、クラウドは、第２識別番号を含む第１ソフトウェアパッケージを送信してよい。第１ソフトウェアパッケージは、第１車両のソフトウェアバージョン及び／又は識別番号が改ざんされる前にクラウドに記憶されているソフトウェアパッケージとして理解され得る。クラウドに記憶されているソフトウェアパッケージは、第１車両のソフトウェアバージョン及び／又は識別番号が改ざんされる前に記憶されていた第１車両のソフトウェア及び識別番号を記憶し得る。

例えば、クラウドが、第１車両の第１ソフトウェアバージョン情報がクラウドの第２ソフトウェアバージョン情報と一致すると決定するとき、この場合に、第１車両デバイス及びクラウドは、ＯＴＡを使用することによってソフトウェアをアップグレードする前に実行された一致決定を通過したと理解され得る。この場合に、クラウドは、第３識別番号を含む第１ソフトウェアパッケージを送信してよい。第１ソフトウェアパッケージは、ＯＴＡによってトリガされたソフトウェアパッケージとして理解され得る。

ＯＴＡを使用することによってソフトウェアを更新することが、アドミッション中のパラメータを変更するには不十分であるとき、第３識別番号は第１識別番号と一致し得る。その具体的なプロセスについては再び記載しない。

Ｓ１１０３：第１車両は、ＥＣＵへ、ＥＣＵに対応する第１ソフトウェアパッケージを送信する。

順応して、各ＥＣＵは第１ソフトウェアパッケージを受信する。１つ以上のＥＣＵが存在してもよい。例えば、Ｎ個のＥＣＵが存在する場合に、第１車両は、Ｎ個のＥＣＵへ、Ｎ個のＥＣＵに対応する第１ソフトウェアパッケージを送信ししてもよく、Ｎは正の整数である。

例えば、第１車両がマスターノードを含む場合に、マスターノードが、クラウドによって送信された第１ソフトウェアパッケージを受信し、第１ソフトウェアパッケージを対応するＥＣＵに分配してもよい。

Ｓ１１０４：ＥＣＵに第１ソフトウェアパッケージをインストールし、識別番号を更新する。

本願のこの実施形態で、識別番号は、第２識別番号又は第３識別番号であってよい。

例えば、ＥＣＵで第１ソフトウェアパッケージをインストールする過程で例外が発生するとき、ＥＣＵは、インストール前に存在しているソフトウェアにロールバックし、第１識別番号をリストアし得る。ＥＣＵがインストール前に存在しているソフトウェアにロールバックすることは、ＥＣＵが第１ソフトウェアバージョン情報をリストアすることを示し得る。

例えば、ＥＣＵでの第１ソフトウェアパッケージのインストールに成功すると、ＥＣＵは、第１識別番号及び第１ソフトウェアバージョン情報を更新し得る。

Ｓ１１０５：ＥＣＵはインストール結果を第１車両へ送信する。

順応して、第１車両はインストール結果を受信する。インストール結果は、インストールが成功したこと、又はいずれか１つ以上のＥＣＵでのインストールが失敗したことであってよい。

Ｓ１１０６：ソフトウェアインストール結果がいずれか１つ以上のＥＣＵでのインストールが失敗したことであるとき、第１車両の車両ソフトウェアバージョン及び識別番号にロールバックする。

任意に、ソフトウェアインストール結果が、インストールが成功したことであるとき、車両ソフトウェアバージョン及び／又は識別番号は更新され得る。例えば、ソフトウェアインストール結果が、インストールが成功したことであり、更新されたソフトウェアが車両ソフトウェアバージョンを変更するには不十分であるとき、車両ソフトウェアバージョンは変更され得ない。

これに基づいて、車両エンド及び／又はクラウドのソフトウェアバージョン及び識別番号の間の一貫性に基づいて、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合を取り除き、かつ、車両ソフトウェアの正常なアップグレードを確保するように、ソフトウェアバージョン情報と識別番号との間のマッチング関係は、ＯＴＡソフトウェアアップグレードプロセスにおいて確かにされ得る。

前述の実施形態で記載されている内容に基づいて、本願の実施形態をより良く理解すべく、以下は、車両エンドでソフトウェアを更新するプロセス全体について別途記載する。具体的に、プロセスには、クラウドがソフトウェアパッケージを車両エンドへ配信すること（図１２に対応する実施形態に示される）、車両エンドでのソフトウェアパッケージのインストールが成功すること（図１３に対応する実施形態に示される）、及び車両エンドでのソフトウェアパッケージのインストールが失敗すること（図１４に対応する実施形態に示される）が含まれ得る。

図１２は、本願の実施形態に従う、クラウドによってソフトウェアパッケージを車両エンドへ配信する概略フローチャートである。図１２に対応する実施形態で、クラウドがソフトウェアパッケージを車両エンドへ配信するプロセスは、クラウドがＯＴＡクラウドであり、車両エンドがマスターノード、ＥＣＵ１、及びＥＣＵ２を含み、識別番号がＲＸＳＷＩＮであり、第１マッピングがＲＸＳＷＩＮマッピングである例を使用することによって、記載される。この例は、本願のこの実施形態に対する制限を更新するものではない。

図１２に示されるように、クラウドがソフトウェアパッケージを配信するプロセスは、次のステップを含み得る。

Ｓ１２０１：ＯＴＡクラウドは、ソフトウェアパッケージをマスターノードへ配信する。

順応して、マスターノードは、ＯＴＡクラウドによって配信されたソフトウェアパッケージを受信する。ソフトウェアパッケージは、関連するＲＸＳＷＩＮ識別子を運ぶ。

Ｓ１２０２：マスターノードは、ソフトウェアパッケージをＥＣＵ１及びＥＣＵ２へ分配する。

順応して、ＥＣＵ１及びＥＣＵ２は、マスターノードによって送信されたソフトウェアパッケージを受信する。ＥＣＵ１及びＥＣＵ２は、ソフトウェアパッケージに対応するＥＣＵであってよい。

Ｓ１２０３：ＥＣＵ１及びＥＣＵ２は、ソフトウェアパッケージを受信し、ＲＸＳＷＩＮ識別子を記録する。

これに基づいて、車両エンド及び／又はクラウドのソフトウェアバージョン及び識別番号の間の一貫性に基づいて、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合を取り除き、かつ、車両ソフトウェアの正常なアップグレードを確保するように、ソフトウェアバージョン情報と識別番号との間のマッチング関係は、ＯＴＡソフトウェアアップグレードプロセスにおいて確かにされ得る。

以上は、クラウドがソフトウェアパッケージを車両エンドへ配信するプロセスである。以下は、車両エンドでのソフトウェアパッケージのインストールが成功するプロセスについて記載する。

例えば、図１３は、本願の実施形態に従う、車両エンドでソフトウェアパッケージをインストールする概略フローチャートである。図１３に対応する実施形態で、車両エンドでのソフトウェアパッケージのインストールが成功するプロセスは、クラウドがＯＴＡクラウドであり、車両エンドがマスターノード、ＥＣＵ１、及びＥＣＵ２を含み、識別番号がＲＸＳＷＩＮであり、第１マッピングがＲＸＳＷＩＮマッピングである例を使用することによって、記載される。この例は、本願のこの実施形態に対する制限を更新するものではない。

図１３に示されるように、ソフトウェアパッケージがＥＣＵでインストールされるプロセスは、次のステップを含み得る。

Ｓ１３０１：ＥＣＵ１及びＥＣＵ２でソフトウェアをインストールする。

例えば、マスターノードがソフトウェアパッケージをＥＣＵ１及びＥＣＵ２に分配した後、ソフトウェアパッケージに基づいてソフトウェアがＥＣＵ１及びＥＣＵ２にインストールされ得る。

Ｓ１３０２：ソフトウェアがＥＣＵ１及びＥＣＵ２で成功裏にインストールされると、関連するＲＸＳＷＩＮを更新する。

Ｓ１３０３：ＥＣＵ１及びＥＣＵ２は、インストール結果をマスターノードへ送信する。

Ｓ１３０４：マスターノードは、車両ソフトウェアバージョンを更新し、かつ／あるいは、ＲＸＳＷＩＮを更新する。

代替的に、車両ソフトウェアは変更され得ない。詳細はここで再び記載されない。

これに基づいて、車両エンド及び／又はクラウドのソフトウェアバージョン及び識別番号の間の一貫性に基づいて、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合を取り除き、かつ、車両ソフトウェアの正常なアップグレードを確保するように、ソフトウェアバージョン情報と識別番号との間のマッチング関係は、ＯＴＡソフトウェアアップグレードプロセスにおいて確かにされ得る。

以上は、車両エンドでのソフトウェアパッケージのインストールが成功するプロセスである。可能な実施において、ソフトウェアパッケージが車両エンドでインストールされる場合に例外が起こることがある。以下は、車両エンドでのソフトウェアパッケージのインストールが失敗するプロセスについて記載する。

例えば、図１４は、本願の実施形態に従う、車両エンドでソフトウェアパッケージをインストールする他の概略フローチャートである。図１４に対応する実施形態で、車両エンドでのソフトウェアパッケージのインストールが失敗するプロセスは、クラウドがＯＴＡクラウドであり、車両エンドがマスターノード、ＥＣＵ１、及びＥＣＵ２を含み、識別番号がＲＸＳＷＩＮであり、第１マッピングがＲＸＳＷＩＮマッピングである例を使用することによって、記載される。この例は、本願のこの実施形態に対する制限を更新するものではない。

図１４に示されるように、ソフトウェアパッケージがＥＣＵでインストールされるプロセスは、次のステップを含み得る。

Ｓ１４０１：ＥＣＵ１及びＥＣＵ２でソフトウェアをインストールし、関連するＲＸＳＷＩＮを更新する。

Ｓ１４０２：ＥＣＵ１及びＥＣＵ２にソフトウェアをインストールする過程で例外が発生する場合に、ソフトウェアをロールバックする。

ＥＣＵ１及びＥＣＵ２は、ソフトウェアパッケージがインストールされる前に存在しているソフトウェアを記憶している。ＥＣＵ１及びＥＣＵ２でソフトウェアをインストールする過程で例外が発生する場合に、ＥＣＵ１及びＥＣＵ２は、ソフトウェアパッケージがインストールされる前に存在しているソフトウェアにロールバックしてよい。

Ｓ１４０３：ＥＣＵ１及びＥＣＵ２は古いＲＸＳＷＩＮをリストアする。

ＥＣＵ１及びＥＣＵ２は、ソフトウェアパッケージがインストールされる前に存在しているＲＸＳＷＩＮを記憶している。ＥＣＵ１及びＥＣＵ２でソフトウェアをインストールする過程で例外が発生する場合に、ＥＣＵ１及びＥＣＵ２は、ソフトウェアパッケージがインストールされる前に存在しているＲＸＳＷＩＮにロールバックしてよい。

Ｓ１４０４：ＥＣＵ１及びＥＣＵ２はマスターノードに例外を通知する。

Ｓ１４０５：マスターノードは、関連する古いＲＸＳＷＩＮをリストアする。

これに基づいて、車両エンド及び／又はクラウドのソフトウェアバージョン及び識別番号の間の一貫性に基づいて、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンがアドミッション中に使用されたソフトウェアバージョンと一致しない場合を取り除き、かつ、車両ソフトウェアの正常なアップグレードを確保するように、ソフトウェアバージョン情報と識別番号との間のマッチング関係は、ＯＴＡソフトウェアアップグレードプロセスにおいて確かにされ得る。

以上は、図６から図１４を参照して、本願の実施形態で提供される方法について記載してきた。以下は、本願の実施形態で提供される、前述の方法を実行する装置について記載する。

例えば、図１５は、本願の実施形態に従うＯＴＡに基づいた通信装置の構造の模式図である。図８に示されるように、ＯＴＡに基づいた通信装置１５０は、通信デバイス、回路、ハードウェア部品、又はチップで使用されてよい。ＯＴＡに基づいた通信装置は、表示ユニット１５０１、処理ユニット１５０２、及び通信ユニット１５０３を含む。表示ユニット１５０１は、ネットワーク設定方法で実行される表示ステップをサポートするよう構成される。処理ユニット１５０２は、ＯＴＡに基づいた通信装置が情報処理ステップを実行するのをサポートするよう構成される。通信ユニット１５０３は、ＯＴＡに基づいた通信装置がデータ送信又は受信しステップを実行するのをサポートするよう構成される。

具体的に、本願の実施形態はＯＴＡに基づいた通信装置を提供する。通信ユニット１５０３は、第１情報及び第２情報を取得するよう構成され、第１情報は第１ソフトウェアバージョン情報及び／又は第１識別番号を含み、第２情報は第１マッピングを含み、第１マッピングは、第２ソフトウェアバージョン情報と第２識別番号との間の関連付け関係を含み、識別番号は、ソフトウェアバージョンのパーミッション情報を示す。処理ユニット１５０２は、第１情報及び第２情報に基づいて、第１ソフトウェアバージョン情報と第２ソフトウェアバージョン情報との間の一致を検証するよう更に構成される。

可能な実施において、処理ユニット１５０２は、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致せず、かつ／あるいは、第１識別番号が第２識別番号と一致しないとき、第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致しないと決定するよう、又は第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致し、かつ／あるいは、第１識別番号が第２識別番号と一致するとき、第１ソフトウェアバージョン情報は第２ソフトウェアバージョン情報と一致すると決定するよう特に構成される。

可能な実施において、処理ユニット１５０２は、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するよう、又は第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するよう更に構成される。

可能な実施において、通信ユニット１５０３は、第１タスクを第１車両へ送信するよう構成され、第１タスクは第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するよう指示する。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１タスクは第１マッピングを含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１タスクは第２マッピングを含む。第２マッピングは、第３ソフトウェアバージョン情報と第３識別番号との間の関連付け関係を含む。

可能な実施において、通信ユニット１５０３は、第１ソフトウェアパッケージを第１車両へ送信するよう更に構成され、第１ソフトウェアパッケージは、第１車両に対応するソフトウェアバージョン情報を更新するために使用される。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアパッケージは第２識別番号を含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１ソフトウェアパッケージは第３識別番号を含む。

可能な実施において、通信ユニット１５０３は、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアバージョン情報、第１識別番号、及び／又はアラーム情報をサーバ及び／又は第１車両の表示デバイスへ送信するよう更に構成され、アラーム情報は、第１車両の識別番号及び／又はソフトウェアバージョン情報がサーバのマッピング関係と一致しないことを示す。

可能な実施において、通信ユニット１５０３は、サーバから第１タスクを受信するよう特に構成され、第１タスクは、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するよう指示する。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１タスクは第１マッピングを含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１タスクは第２マッピングを含む。第２マッピングは、第３ソフトウェアバージョン情報と第３識別番号との間の関連付け関係を含む。

可能な実施において、通信ユニット１５０３は、サーバから第１ソフトウェアパッケージを受信するよう更に構成され、第１ソフトウェアパッケージは、第１車両に対応するソフトウェアバージョン情報を更新するために使用される。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１ソフトウェアパッケージは第２識別番号を含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１ソフトウェアパッケージは第３識別番号を含む。

可能な実施において、識別番号は、第１法規関連ソフトウェア識別番号ＲＸＳＷＩＮを含む。

可能な実施において、ＯＴＡに基づいた通信装置は、記憶ユニット１５０４を更に含んでもよい。処理ユニット１５０２及び記憶ユニット１５０４は、ラインを通じて接続される。

記憶ユニット１５０４は１つ以上のメモリを含んでよい。メモリは、プログラム又はデータを記憶するよう構成され、１つ以上のデバイス又は回路ないにあるコンポーネントであってよい。

記憶ユニット１５０４は独立して存在してよく、通信ラインを通じてＯＴＡに基づいた通信装置の処理ユニット１５０２へ接続される。代替的に、記憶ユニット１５０４は、処理ユニット１５０２と一体化されていることがある。

通信ユニット１５０３は、入力／出力インターフェース、ピン、回路などであってよい。例えば、記憶ユニット１５０４は、レーダ又は対象デバイスの方法のコンピュータ実行可能命令を記憶し得るので、処理ユニット１５０２は、前述の実施形態におけるレーダ又は対象デバイスの方法を実行する。記憶ユニット１５０４は、レジスタ、キャッシュ、ＲＡＭ、などであってよい。記憶ユニット１５０４は、処理ユニット１５０２と一体化されてもよい。記憶ユニット１５０４は、ＲＯＭ又は、静的な情報及び命令を記憶することができる他のタイプの静的な記憶デバイスであってよい。記憶ユニット１５０４は、処理ユニット１５０２から独立していてもよい。

図１６は、本願の実施形態に係る制御デバイスのハードウェア構造の模式図である。図１６に示されるように、制御デバイスは、プロセッサ１６０１、通信ライン１６０４、及び少なくとも１つの通信インターフェース（通信インターフェース１６０３が、説明のために図１６では例として使用される）を含む。

プロセッサ１６０１は、汎用の中央演算処理装置（ｃｅｎｔｒａｌ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ，ＣＰＵ）、マイクロプロセッサ、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ，ＡＳＩＣ）、本願の解決法のプログラム実行を制御するよう構成された１つ以上の集積回路であってよい。

通信ライン１６０４は、前述のコンポーネント間で情報を伝送するための回路を含んでもよい。

通信インターフェース１６０３は、トランシーバなどの任意の装置であり、他のデバイス又は、Ｅｔｈｅｒｎｅｔ若しくは無線ローカルエリアネットワーク（ｗｉｒｅｌｅｓｓ ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ，ＷＬＡＮ）などの通信ネットワークと通信するよう構成される。

場合により、制御デバイスは、メモリ１６０２を更に含んでもよい。

メモリ１６０２は、読み出し専用メモリ（ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ，ＲＯＭ）若しくは、静的な情報及び命令を記憶することができる他のタイプの静的な記憶デバイス、又は、ランダムアクセスメモリ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ，ＲＡＭ）若しくは、情報及び命令を記憶することができる他のタイプの動的な記憶デバイスであってよく、あるいは、電気的消去可能なプログラム可能読み出し専用メモリ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ，ＥＥＰＲＯＭ）、コンパクトディスク読み出し専用メモリ（ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ，ＣＤ－ＲＯＭ）若しくは他のコンパクトディスクストレージ、光ディスクストレージ（コンパクト光ディスク、レーザーディスク、光ディスク、デジタルバーサタイルディスク、ブルーレイディスク、などを含む）、磁気ディスク記憶媒体若しくは他の磁気記憶デバイス、又は期待されるプログラムコードを命令構造若しくはデータ構造の形で搬送又は記憶するために使用でき、コンピュータがアクセスすることができる任意の他の媒体であってよい。しかし、これはそのように制限されない。メモリは独立して存在してよく、通信ライン１６０４を通じてプロセッサへ接続される。代替的に、メモリはプロセッサと一体化されていてもよい。

メモリ１６０２は、本願の解決法を実行するためのコンピュータ実行可能命令を記憶するよう構成され、プロセッサ１６０１は、コンピュータ実行可能命令の実行を制御する。プロセッサ１６０１は、メモリ１６０２に記憶されているコンピュータ実行可能命令を実行して、本願の実施形態で提供されるＯＴＡに基づいた通信方法を実施するよう構成される。

場合により、本願のこの実施形態のコンピュータ実行可能命令は、アプリケーションプログラムコードとも呼ばれ得る。これは、本願のこの実施形態で特に制限されない。

具体的な実施中、実施形態で、プロセッサ１６０１は、１つ以上のＣＰＵ，例えば、図１６のＣＰＵ０及びＣＰＵ１を含んでよい。

具体的な実施中、実施形態で、制御デバイスは、複数のプロセッサ、例えば、図１６のプロセッサ１６０１及びプロセッサ１６０５を含んでもよい。プロセッサの夫々は、シングルコア（ｓｉｎｇｌｅ－ＣＰＵ）プロセッサであってよく、あるいは、マルチコア（ｍｕｌｔｉ－ＣＰＵ）プロセッサであってよい。ここでのプロセッサは、データ（例えば、コンピュータプログラム命令）を処理するよう構成される１つ以上のデバイス、回路、及び／又はプロセッシングコアであってよい。

例えば、図１７は、本願の実施形態に係るチップの構造の模式図である。チップ１７０は、１つ以上（２つを含む）のプロセッサ１７２０及び通信インターフェース１７３０を含む。

いくつかの実施において、メモリ１７４０は、次の要素：実行可能モジュール若しくはデータ構造、それらのサブセット、又はそれらの拡張セットを記憶する。

本願のこの実施形態で、メモリ１７４０は、読み出し専用メモリ及びランダムアクセスメモリを含み、命令及びデータをプロセッサ１７２０へ供給し得る。メモリ１７４０の一部には、不揮発性ランダムアクセスメモリ（ｎｏｎ－ｖｏｌａｔｉｌｅ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ，ＮＶＲＡＭ）が更に含まれてもよい。

本願のこの実施形態で、メモリ１７４０、通信インターフェース１７３０、及びメモリ１７４０は、バスシステム２０２０を通じて結合されている。データバスに加えて、バスシステム２０２０は、電力バス、制御バス、ステータス信号バス、などを更に含んでもよい。記載を簡単にするために、図１７では様々なタイプのバスがバスシステム２０２０としてマークされている。

本願の前述の実施形態で記載されている方法は、プロセッサ１７２０に適用されてよく、あるいは、プロセッサ１７２０によって実施されてよい。プロセッサ１７２０は、集積回路チップであってよく、信号処理能力を備えている。実施プロセスにおいて、前述の方法のステップは、プロセッサ１７２０内のハードウェア回路の集積ロジック回路を使用することによって、又はソフトウェアの形をとる命令を使用することによって、完了されてもよい。プロセッサ１７２０は、汎用プロセッサ（例えば、マイクロプロセッサ若しくは従来のプロセッサ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ，ＤＳＰ）、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ，ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ，ＦＰＧＡ）若しくは他のプログラム可能ロジックデバイス、ディスクリートゲート、トランジスタロジックデバイス、又はディスクリートハードウェア部品であってもよい。プロセッサ１７２０は、本発明の実施形態で開示される方法、ステップ、及び論理ブロック図を実施又は実行し得る。

本願の実施形態を参照して開示されている方法のステップは、ハードウェア復号化プロセッサを使用することによって直接実行及び完了されてよく、あるいは、復号化プロセッサ内のハードウェア及びソフトウェアモジュールの組み合わせを使用することによって実行及び完了されてもよい。ソフトウェアモジュールは、当該技術における成熟した記憶媒体、例えば、ランダムアクセスメモリ、読み出し専用メモリ、プログラム可能読み出し専用メモリ、又は電気的消去可能なプログラム可能読み出し専用メモリ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ，ＥＥＰＲＯＭ）に位置してもよい。記憶媒体はメモリ１７４０に位置している。プロセッサ１７２０は、メモリ１７４０内の情報を読み出し、プロセッサ１７２０のハードウェアと組み合わせて前述の方法のステップを完了する。

前述の実施形態で、メモリに記憶されており、プロセッサによって実行されるべき命令は、コンピュータプログラム製品の形で実施されてもよい。コンピュータプログラム製品は、前もってメモリに書き込まれてもよく、あるいは、ソフトウェアの形でダウンロードされてメモリにインストールされてもよい。

コンピュータプログラム製品は１つ以上のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータにロードされて実行される場合に、本願の実施形態に係るプロシージャ又は機能の全て又は一部は生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、又は他のプログラム可能な装置であってよい。コンピュータ命令は、コンピュータ可読記憶媒体に記憶されてよく、あるいは、コンピュータ可読記憶媒体から他のコンピュータ可読記憶媒体へ送信されてもよい。例えば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバ、又はデータセンターから他のウェブサイト、コンピュータ、サーバ、又はデータセンターへ有線方式（例えば、同軸ケーブル、光ファイバ、若しくはデジタル加入者回線（ｄｉｇｉｔａｌ ｓｕｂｓｃｒｉｂｅｒ ｌｉｎｅ，ＤＳＬ））又は無線方式（例えば、赤外線、電波、若しくはマイクロ波）で送信されてもよい。コンピュータ可読記憶媒体は、コンピュータがアクセス可能な任意の使用可能な媒体又は、１つ以上の使用可能な媒体を含む、例えばサーバ若しくはデータセンターなどの、データ記憶デバイスであってよい。例えば、使用可能な媒体には、磁気媒体（例えば、フロッピーディスク、ハードディスク、若しくは磁気テープ）、光学媒体（例えば、デジタルバーサタイルディスク（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｃ，ＤＶＤ））、半導体媒体（例えば、ソリッドステートディスク（ｓｏｌｉｄ ｓｔａｔｅ ｄｉｓｋ，ＳＳＤ））、などが含まれ得る。

本願の実施形態はコンピュータ可読記憶媒体を更に提供する。前述の実施形態で記載される方法の全て又は一部は、ソフトウェア、ハードウェア、ファームウェア、又はそれらの任意の組み合わせによって実施されてよい。コンピュータ可読媒体には、コンピュータ記憶媒体及び通信媒体が含まれてもよく、更には、１つの場所から他の場所へコンピュータプログラムを転送することができる任意の媒体が含まれてもよい。記憶媒体は、コンピュータによってアクセスできる任意のターゲット媒体であってもよい。

可能な設計では、コンピュータ可読媒体には、コンパクトディスク読み出し専用メモリ（ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ、ＣＤ－ＲＯＭ）、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、又は他の光ディスクメモリが含まれ得る。コンピュータ可読媒体には、磁気ディスクメモリ又は他の磁気ディスク記憶デバイスが含まれ得る。更に、如何なる接続線も、適切に、コンピュータ可読媒体と呼ばれることがある。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイステッドペア、ＤＳＬ、又はラジオ技術（例えば、赤外線、電波、及びマイクロ波）を使用することによってウェブサイト、サーバ、又は他の遠隔ソースから送信される場合に、同軸ケーブル、光ファイバケーブル、ツイステッドペア、ＤＳＬ、又は赤外線、電波、及びマイクロ波などのラジオ技術は、媒体の定義に含まれる。本明細書で使用される磁気ディスク及び光ディスクには、コンパクトディスク（ＣＤ）、レーザーディスク、光ディスク、デジタルバーサタイルディスク（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｃ，ＤＶＤ）、フロッピーディスク、及びブルーレイディスクが含まれる。磁気ディスクは、通常、データを磁気的に再生し、光ディスクは、レーザ光を使用することによってデータを光学的に再生する。

前述の組み合わせも、コンピュータ可読媒体の範囲に含まれる必要がある。前述の記載は、本発明の具体的な実施にすぎず、本発明の保護範囲を制限する意図はない。本発明で開示される技術範囲内で当業者によって容易に考え出される如何なる変形又は置換も、本発明の保護範囲内に入るべきである。従って、本発明の保護範囲は、特許請求の範囲の保護範囲に従うべきである。

本願は、通信技術の分野に、特に、オーバー・ザ・エア技術（ＯＴＡ）に基づいた通信方法及び装置に関係がある。

本願の実施形態は、ＯＴＡメンテナンス及びソフトウェアインストールプロセスの正常なアップグレードを確保し、更には車両の安全性を保つように、オーバー・ザ・エア技術（ＯＴＡ）に基づいた通信方法及び装置を提供する。

第１の態様を参照して、可能な実施において、識別番号は、第１法規関連ソフトウェア識別番号（ｒｅｇｕｌａｔｉｏｎ－ｒｅｌａｔｅｄ ｓｏｆｔｗａｒｅ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｎｕｍｂｅｒ，ＲＸＳＷＩＮ）を含む。このようにして、ＲＸＳＷＩＮとソフトウェアバージョンとの間のマッチング関係は、ＯＴＡメンテナンス及びソフトウェアインストールプロセスにおいてＲＸＳＷＩＮとソフトウェアバージョンとの間の一貫性を確かにし、かつ、車両ソフトウェアの正常なアップグレードを確保するために、使用され得る。

第２の態様を参照して、可能な実施において、通信ユニットは、サーバから第１タスクを受信するよう特に構成され、第１タスクは、第１ソフトウェアバージョン情報及び／又は第１識別番号を更新するよう指示する。第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致しないとき、第１タスクは第１マッピングを含み、あるいは、第１ソフトウェアバージョン情報が第２ソフトウェアバージョン情報と一致するとき、第１タスクは第２マッピングを含む。第２マッピングは、第３ソフトウェアバージョン情報と第３識別番号との間の関連付け関係を含む。第３ソフトウェアバージョン情報は、第２ソフトウェアバージョン情報とは異なり、かつ／あるいは、第３識別番号は、第２識別番号とは異なる。

第２の態様を参照して、可能な実施において、識別番号は、第１法規関連ソフトウェア識別番号（ＲＸＳＷＩＮ）を含む。

車両が市場に投入された後、車両ソフトウェアは、ＯＴＡを使用することによって更新されることがある。しかし、更新プロセスにおいて、アドミッション中に測定されたソフトウェアのテストパラメータは変更される可能性がある。例えば、車両のバッテリ管理ソフトウェアがＯＴＡを使用することによってアップグレードされた後、車両の耐久走行距離が増えることあり、車両の耐久走行距離は、アドミッション中に測定された耐久走行距離と一致しなくなる。更に、車両のアドミッション中にテストされたデータは無効になり、テストが再び行われる必要がある。従って、ＯＴＡを使用することによってアップグレードされたソフトウェアバージョンは、アドミッション中に使用されたソフトウェアバージョンと一致しないことがある。これは、ＯＴＡの開発に課題をもたらす。これに基づいて、国際連合欧州経済委員会（Ｕｎｉｔｅｄ Ｎａｔｉｏｎｓ Ｅｃｏｎｏｍｉｃ Ｃｏｍｍｉｓｓｉｏｎ ｆｏｒ Ｅｕｒｏｐｅ，ＵＮＥＣＥ）の傘下にある自動車基準調和世界フォーラムは、ＯＴＡ作業部会を設立し、アドミッション監督システムへのＯＴＡの組み込みを議論している。車両のＯＴＡがアドミッションの一貫性に影響を与える可能性がある場合、ＯＴＡアップグレードを実行する前にアドミッション監督機関にアドミッションの変更を申請する必要があることが述べられている。そのような変更を監督すべく、法規関連ソフトウェア識別番号（ＲＸＳＷＩＮ）が提案されている。ＲＸＳＷＩＮは、ソフトウェアバージョンとアドミッションとの間の関係を記録することができる。ＲＸＳＷＩＮの機能は、アドミッション規制の観点から、アドミッションに影響を及ぼすソフトウェア及びソフトウェアアップグレードを記録及び追跡し、アドミッション監督機関が車両ソフトウェアのアップグレードを管理するのを助けることである。ＲＸＳＷＩＮの変更は、ソフトウェアのアップグレードによって引き起こされたアドミッションの変更を示すことができる。

他の可能な実施において、車両製造者ＯＴＡクラウドデバイス３０１、マスターＯＴＡクライアント３０３、及びソフトウェアＯＴＡクライアント３０４は、ソフトウェアを更新するために、互いに相互作用する。例えば、車両製造者ＯＴＡクラウドデバイス３０１は、車両製造者ＯＴＡクラウドデバイス３０１に記憶されている、識別番号とソフトウェアバージョン情報との間のマッピング関係と、マスターＯＴＡクライアント３０３（若しくはソフトウェアＯＴＡクライアント３０４）から取得されたソフトウェアバージョン及び／又は識別番号の一貫性とに基づいて、車両アップグレードパッケージを使用することによってマスターＯＴＡクライアント３０３へ、更新される必要があるソフトウェアパッケージを送信してよい。マスターＯＴＡクライアント３０３は、車両アップグレードパッケージを受信及びダウンロードし、車両アップグレードパッケージを分割し、分割した車両アップグレードパッケージをソフトウェアＯＴＡクライアント３０４へ送信する。ソフトウェアＯＴＡクライアント３０４は、分割された車両アップグレードパッケージ内のソフトウェアパッケージに基づいてソフトウェア及び識別番号を更新する。

例えば、図１５は、本願の実施形態に従うＯＴＡに基づいた通信装置の構造の模式図である。図１５に示されるように、ＯＴＡに基づいた通信装置１５０は、通信デバイス、回路、ハードウェア部品、又はチップで使用されてよい。ＯＴＡに基づいた通信装置は、表示ユニット１５０１、処理ユニット１５０２、及び通信ユニット１５０３を含む。表示ユニット１５０１は、ネットワーク設定方法で実行される表示ステップをサポートするよう構成される。処理ユニット１５０２は、ＯＴＡに基づいた通信装置が情報処理ステップを実行するのをサポートするよう構成される。通信ユニット１５０３は、ＯＴＡに基づいた通信装置がデータ送信又は受信しステップを実行するのをサポートするよう構成される。

可能な実施において、識別番号は、第１法規関連ソフトウェア識別番号（ＲＸＳＷＩＮ）を含む。

通信ユニット１５０３は、入力／出力インターフェース、ピン、回路などであってよい。例えば、記憶ユニット１５０４は、ＯＴＡに基づいた通信方法のコンピュータ実行可能命令を記憶し得るので、処理ユニット１５０２は、前述の実施形態におけるＯＴＡに基づいた通信方法を実行する。記憶ユニット１５０４は、レジスタ、キャッシュ、ＲＡＭ、などであってよい。記憶ユニット１５０４は、処理ユニット１５０２と一体化されてもよい。記憶ユニット１５０４は、ＲＯＭ又は、静的な情報及び命令を記憶することができる他のタイプの静的な記憶デバイスであってよい。記憶ユニット１５０４は、処理ユニット１５０２から独立していてもよい。

例えば、図１７は、本願の実施形態に係るチップの構造の模式図である。チップ１７０は、１つ以上（２つを含む）のプロセッサ１７１０及び通信インターフェース１７３０を含む。

本願のこの実施形態で、メモリ１７４０は、読み出し専用メモリ及びランダムアクセスメモリを含み、命令及びデータをプロセッサ１７１０へ供給し得る。メモリ１７４０の一部には、不揮発性ランダムアクセスメモリ（ｎｏｎ－ｖｏｌａｔｉｌｅ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ，ＮＶＲＡＭ）が更に含まれてもよい。

本願のこの実施形態で、プロセッサ１７１０、通信インターフェース１７３０、及びメモリ１７４０は、バスシステム１７２０を通じて結合されている。データバスに加えて、バスシステム１７２０は、電力バス、制御バス、ステータス信号バス、などを更に含んでもよい。記載を簡単にするために、図１７では様々なタイプのバスがバスシステム１７２０としてマークされている。

本願の前述の実施形態で記載されている方法は、プロセッサ１７１０に適用されてよく、あるいは、プロセッサ１７１０によって実施されてよい。プロセッサ１７１０は、集積回路チップであってよく、信号処理能力を備えている。実施プロセスにおいて、前述の方法のステップは、プロセッサ１７１０内のハードウェア回路の集積ロジック回路を使用することによって、又はソフトウェアの形をとる命令を使用することによって、完了されてもよい。プロセッサ１７１０は、汎用プロセッサ（例えば、マイクロプロセッサ若しくは従来のプロセッサ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ，ＤＳＰ）、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ，ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ，ＦＰＧＡ）若しくは他のプログラム可能ロジックデバイス、ディスクリートゲート、トランジスタロジックデバイス、又はディスクリートハードウェア部品であってもよい。プロセッサ１７１０は、本発明の実施形態で開示される方法、ステップ、及び論理ブロック図を実施又は実行し得る。

本願の実施形態を参照して開示されている方法のステップは、ハードウェア復号化プロセッサを使用することによって直接実行及び完了されてよく、あるいは、復号化プロセッサ内のハードウェア及びソフトウェアモジュールの組み合わせを使用することによって実行及び完了されてもよい。ソフトウェアモジュールは、当該技術における成熟した記憶媒体、例えば、ランダムアクセスメモリ、読み出し専用メモリ、プログラム可能読み出し専用メモリ、又は電気的消去可能なプログラム可能読み出し専用メモリ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ，ＥＥＰＲＯＭ）に位置してもよい。記憶媒体はメモリ１７４０に位置している。プロセッサ１７１０は、メモリ１７４０内の情報を読み出し、プロセッサ１７１０のハードウェアと組み合わせて前述の方法のステップを完了する。

Claims (23)

1. オーバー・ザ・エア技術ＯＴＡに基づいた通信方法であって、
   第１情報及び第２情報を取得することであり、前記第１情報は第１ソフトウェアバージョン情報及び／又は第１識別番号を含み、前記第２情報は第１マッピングを含み、前記第１マッピングは第２ソフトウェアバージョン情報と第２識別番号との間の関連付け関係を含み、前記識別番号はソフトウェアバージョンのパーミッション情報を示す、前記取得することと、
   前記第１情報及び前記第２情報に基づいて、前記第１ソフトウェアバージョン情報と前記第１マッピングに対応する前記第２ソフトウェアバージョン情報との間の一致を検証することと
   を有する方法。
2. 前記第１情報及び前記第２情報に基づいて、前記第１ソフトウェアバージョン情報と前記第１マッピングに対応する前記第２ソフトウェアバージョン情報との間の一致を検証することは、
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致せず、かつ／あるいは、前記第１識別番号が前記第２識別番号と一致しないとき、前記第１ソフトウェアバージョン情報は前記第２ソフトウェアバージョン情報と一致しないと決定すること、又は
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致し、かつ／あるいは、前記第１識別番号が前記第２識別番号と一致するとき、前記第１ソフトウェアバージョン情報は前記第２ソフトウェアバージョン情報と一致すると決定すること
   を有する、
   請求項１に記載の方法。
3. 当該方法は、
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致しないとき、前記第１ソフトウェアバージョン情報及び／又は前記第１識別番号を更新すること、又は
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致するとき、前記第１ソフトウェアバージョン情報及び／又は前記第１識別番号を更新すること
   を更に有する、
   請求項１又は２に記載の方法。
4. 前記第１ソフトウェアバージョン情報及び／又は前記第１識別番号を更新することより前に、当該方法は、
   第１タスクを第１車両へ送信することを更に有し、前記第１タスクは前記第１ソフトウェアバージョン情報及び／又は前記第１識別番号を更新するよう指示し、
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致しないとき、前記第１タスクは前記第１マッピングを含み、あるいは、
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致するとき、前記第１タスクは第２マッピングを含み、前記第２マッピングは第３ソフトウェアバージョン情報と第３識別番号との間の関連付け関係を含む、
   請求項３に記載の方法。
5. 当該方法は、
   第１ソフトウェアパッケージを前記第１車両へ送信することを有し、前記第１ソフトウェアパッケージは、前記第１車両に対応するソフトウェアバージョン情報を更新するために使用され、
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致しないとき、前記第１ソフトウェアパッケージは前記第２識別番号を含み、あるいは、
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致するとき、前記第１ソフトウェアパッケージは前記第３識別番号を含む、
   請求項３又は４に記載の方法。
6. 当該方法は、
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致しないとき、前記第１ソフトウェアバージョン情報、前記第１識別番号、及び／又はアラーム情報をサーバ及び／又は第１車両の表示デバイスへ送信することを更に有し、前記アラーム情報は、前記第１車両の識別番号及び／又はソフトウェアバージョン情報が前記サーバのマッピング関係と一致しないことを示す、
   請求項１乃至３のうちいずれか一項に記載の方法。
7. 前記第１ソフトウェアバージョン情報及び／又は前記第１識別番号を更新することは、
   サーバから第１タスクを受信することを有し、前記第１タスクは、前記第１ソフトウェアバージョン情報及び／又は前記第１識別番号を更新するよう指示し、
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致しないとき、前記第１タスクは前記第１マッピングを含み、あるいは、
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致するとき、前記第１タスクは第２マッピングを含み、前記第２マッピングは第３ソフトウェアバージョン情報と第３識別番号との間の関連付け関係を含む、
   請求項３に記載の方法。
8. 当該方法は、
   前記サーバから第１ソフトウェアパッケージを受信することを更に有し、前記第１ソフトウェアパッケージは、前記第１車両に対応するソフトウェアバージョン情報を更新するために使用され、
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致しないとき、前記第１ソフトウェアパッケージは前記第２識別番号を含み、あるいは、
   前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致するとき、前記第１ソフトウェアパッケージは前記第３識別番号を含む、
   請求項７に記載の方法。
9. 前記識別番号は、第１法規関連ソフトウェア識別番号ＲＸＳＷＩＮを含む、
   請求項１乃至８のうちいずれか一項に記載の方法。
10. オーバー・ザ・エア技術ＯＴＡに基づいた通信装置であって、
    第１情報及び第２情報を取得するよう構成される通信ユニットであり、前記第１情報は第１ソフトウェアバージョン情報及び／又は第１識別番号を含み、前記第２情報は第１マッピングを含み、前記第１マッピングは第２ソフトウェアバージョン情報と第２識別番号との間の関連付け関係を含み、前記識別番号はソフトウェアバージョンのパーミッション情報を示す、前記通信ユニットと、
    前記第１情報及び前記第２情報に基づいて、前記第１ソフトウェアバージョン情報と前記第１マッピングに対応する前記第２ソフトウェアバージョン情報との間の一致を検証するよう更に構成される処理ユニットと
    を有する装置。
11. 前記処理ユニットは、
    前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致せず、かつ／あるいは、前記第１識別番号が前記第２識別番号と一致しないとき、前記第１ソフトウェアバージョン情報は前記第２ソフトウェアバージョン情報と一致しないと決定するよう、又は
    前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致し、かつ／あるいは、前記第１識別番号が前記第２識別番号と一致するとき、前記第１ソフトウェアバージョン情報は前記第２ソフトウェアバージョン情報と一致すると決定するよう
    特に構成される、
    請求項１０に記載の装置。
12. 前記処理ユニットは、
    前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致しないとき、前記第１ソフトウェアバージョン情報及び／又は前記第１識別番号を更新するよう、又は
    前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致するとき、前記第１ソフトウェアバージョン情報及び／又は前記第１識別番号を更新するよう
    更に構成される、
    請求項１０又は１１に記載の装置。
13. 前記通信ユニットは、第１タスクを第１車両へ送信するよう特に構成され、前記第１タスクは前記第１ソフトウェアバージョン情報及び／又は前記第１識別番号を更新するよう指示し、
    前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致しないとき、前記第１タスクは前記第１マッピングを含み、あるいは、
    前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致するとき、前記第１タスクは第２マッピングを含み、前記第２マッピングは第３ソフトウェアバージョン情報と第３識別番号との間の関連付け関係を含む、
    請求項１２に記載の装置。
14. 前記通信ユニットは、第１ソフトウェアパッケージを前記第１車両へ送信するよう更に構成され、前記第１ソフトウェアパッケージは、前記第１車両に対応するソフトウェアバージョン情報を更新するために使用され、
    前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致しないとき、前記第１ソフトウェアパッケージは前記第２識別番号を含み、あるいは、
    前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致するとき、前記第１ソフトウェアパッケージは前記第３識別番号を含む、
    請求項１２又は１３に記載の装置。
15. 前記通信ユニットは、前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致しないとき、前記第１ソフトウェアバージョン情報、前記第１識別番号、及び／又はアラーム情報をサーバ及び／又は第１車両の表示デバイスへ送信するよう更に構成され、
    前記アラーム情報は、前記第１車両の識別番号及び／又はソフトウェアバージョン情報が前記サーバのマッピング関係と一致しないことを示す、
    請求項１０乃至１２のうちいずれか一項に記載の装置。
16. 前記通信ユニットは、サーバから第１タスクを受信するよう特に構成され、前記第１タスクは、前記第１ソフトウェアバージョン情報及び／又は前記第１識別番号を更新するよう指示し、
    前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致しないとき、前記第１タスクは前記第１マッピングを含み、あるいは、
    前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致するとき、前記第１タスクは第２マッピングを含み、前記第２マッピングは第３ソフトウェアバージョン情報と第３識別番号との間の関連付け関係を含む、
    請求項１２に記載の装置。
17. 前記通信ユニットは、前記サーバから第１ソフトウェアパッケージを受信するよう更に構成され、前記第１ソフトウェアパッケージは、前記第１車両に対応するソフトウェアバージョン情報を更新するために使用され、
    前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致しないとき、前記第１ソフトウェアパッケージは前記第２識別番号を含み、あるいは、
    前記第１ソフトウェアバージョン情報が前記第２ソフトウェアバージョン情報と一致するとき、前記第１ソフトウェアパッケージは前記第３識別番号を含む、
    請求項１６に記載の装置。
18. 前記識別番号は、第１法規関連ソフトウェア識別番号ＲＸＳＷＩＮを含む、
    請求項１０乃至１７のうちいずれか一項に記載の装置。
19. メモリ内のプログラムを呼び出して、請求項１乃至９のうちいずれか一項に記載の方法を実行するよう構成される少なくとも１つのプロセッサを有する、
    ＯＴＡに基づいた通信装置。
20. 少なくとも１つのプロセッサ及びインターフェース回路を有し、
    前記インターフェース回路は、前記少なくとも１つのプロセッサに対する情報入力及び／又は情報出力を提供するよう構成され、
    前記少なくとも１つのプロセッサは、請求項１乃至９のうちいずれか一項に記載の方法を実行するよう構成される、
    ＯＴＡに基づいた通信装置。
21. 少なくとも１つのプロセッサ及びインターフェースを有し、
    前記インターフェースは、前記少なくとも１つのプロセッサに対してプログラム命令又はデータを供給するよう構成され、
    前記少なくとも１つのプロセッサは、前記プログラム命令を実行して、請求項１乃至９のうちいずれか一項に記載の方法を実施するよう構成される、
    チップ。
22. 命令を記憶するコンピュータ可読記憶媒体であって、
    前記命令が実行されると、コンピュータは、請求項１乃至９のうちいずれか一項に記載の方法を実行することができる、
    コンピュータ可読記憶媒体。
23. コンピュータプログラムを有するコンピュータプログラム製品であって、
    前記コンピュータプログラムが実行されると、コンピュータは、請求項１乃至９のうちいずれか一項に記載の方法を実行することができる、
    コンピュータプログラム製品。

Images