JP7540391B2 - Ｏｔａマスタ、更新制御方法、更新制御プログラム - Google Patents

Description

本開示は、複数の車載機器を含む車載ネットワークに接続されると共に、ＯＴＡセンタとネットワークを介して通信可能であり、当該車載機器のソフトウェアを更新するＯＴＡマスタに関する。

従来から、車両には、制御機能を実行するための複数の電子制御装置（「ＥＣＵ」と呼ばれる）が実装されている。当該ＥＣＵは、プロセッサと記憶部とを備え、プロセッサが記憶部に記憶されるソフトウェアを実行することによりＥＣＵの制御機能を実現する。また、各ＥＣＵが記憶するソフトウェアは更新可能である。具体的には、整備工場等において、車両に設けられたダイアグ用コネクタを介して接続した外部機器を用いて更新することができる。また、車載ネットワークが備える通信機器とインターネット等の通信ネットワークとを無線で接続し、無線通信を介して更新センタに設けられた配信サーバからダウンロードしたソフトウェアで更新することもできる（例えば特開２０２０－００４２４５号公報）。この無線通信を介した更新サービスは、ＯＴＡサービスと呼ばれる。

特開２０２０－００４２４５号公報

従来のＯＴＡサービスにおける更新処理においては、所定の車両に対する更新を開始する前に、当該車両の現状のソフトウェア構成を把握するために、車両に実装されている全てのＥＣＵに関するデータを車両からセンタに送信していた。センタでは、当該データに基づいて、更新の必要性等を判断していた。

しかし、近年では車両の多機能化に伴い、車両に含まれるＥＣＵの数も増大しており、例えば実装されるＥＣＵの数が５０近くある場合もあり得る。そのため、全てのＥＣＵのついてのデータを毎回センタに送るとすると、通信データ量も増大し、また、センタにおけるチェック処理の負荷も少なくないものとなっていた。

本開示は、上記課題を鑑みてなされたものであり、車両に実装されている全ＥＣＵについてのデータを送らずともＥＣＵのソフトウェアの更新処理が可能なＯＴＡマスタを提供することである。

上記課題を解決するために、本開示技術の一態様は、複数の車載機器を含む車載ネットワークに接続されると共に、ＯＴＡセンタとネットワークを介して通信可能であり、１以上の車載機器のソフトウェアを更新するＯＴＡマスタである。ＯＴＡマスタは、１以上の車載機器のソフトウェアの組み合わせからなるソフトウェアグループであって、当該ソフトウェアの組み合わせの構成に変化が発生したソフトウェアグループに関する構成情報を取得する構成情報取得部と、取得した構成情報をＯＴＡセンタに送信する送信部とを備える。

本開示のＯＴＡマスタによれば、更新処理におけるデータの通信量を削減でき、また、更新完了までの時間を短縮することができる。

本実施形態に係るシステムの全体構成を示すブロック図 センタ１の概略構成を示すブロック図 ＯＴＡマスタ３１の概略構成を示すブロック図 センタ１の機能ブロック図 ＯＴＡマスタ３１の機能ブロック図 センタ１の記憶部１６に記憶されるデータの一例を示すメモリマップ ＳＷＩＤデータベース１０２のデータ構成の一例 車両データベース１０３のデータ構成の一例 ＯＴＡマスタ３１の記憶部４７に記憶されるデータの一例を示すメモリマップ 実装ＳＷＩＤ定義データ１５２のデータ構成の一例 チェック用ＳＷＩＤハッシュ値１５３のデータ構成の一例 第１の実施例に係る処理の詳細を示すフローチャート 第１の実施例に係る処理の詳細を示すフローチャート 第２の実施例におけるＯＴＡマスタ３１の記憶部４７に記憶されるデータの一例を示すメモリマップ 第２の実施例に係る処理の詳細を示すフローチャート 第３の実施例に係る処理の詳細を示すフローチャート

以下、本開示技術の実施形態について、図面を参照しながら詳細に説明する。

従来は、ＯＴＡサービスにおいて、車載用の電子制御装置のソフトウェア（以下、ＥＣＵソフトと呼ぶ）を更新するための更新処理を行う際に、その車両に実装されている全てのＥＣＵソフトに関するデータがＯＴＡセンタ（以下、単にセンタと呼ぶ）に送信されていた。具体的には、全ＥＣＵソフトのシリアル番号（各ソフトを識別するための番号）と各ソフトのバージョンに基づいたハッシュ値（以下、総合ハッシュ値と呼ぶ）が生成され、センタに送信されていた。これに対して、本実施形態では、全てのＥＣＵソフトではなく、一部のＥＣＵソフトに係る構成情報、具体的にはハッシュ値が生成され、センタに送信される。そして、このハッシュ値に基づいて、所定のＥＣＵソフトについての更新処理の必要性の判断が行われ、必要があれば更新処理が行われる。これにより、本実施形態では、上記総合ハッシュ値を用いる場合に比べ、通信量を削減しつつ、更新処理の完了までにかかる時間の短縮を図ることができる。より具体的には、「ソフトウェアＩＤ」という概念を用いて、一部のＥＣＵソフトにかかるハッシュ値が生成・送信され、更新処理の必要性が判断される。

ここで、上記ソフトウェアＩＤ（以下、ＳＷＩＤと呼ぶ）について説明する。ＳＷＩＤとは、複数のＥＣＵの機能の組み合わせによって実現する所定の機能単位でグループ化したＥＣＵソフトのグループを示す概念である。換言すれば、ＳＷＩＤは、ある機能を実現するためのソフトウェアの構成を示す概念である。例えば、「自動運転機能」という機能があるとする。当該「自動運転機能」は、ハンドルを制御するＥＣＵソフト（以下、ハンドルＥＣＵ）と、アクセルを制御するＥＣＵソフト（以下、アクセルＥＣＵ）と、ブレーキを制御するＥＣＵソフト（以下、ブレーキＥＣＵ）との３つのＥＣＵソフトが協働することで実現されるとする。この場合、ＳＷＩＤの一例として、「自動運転機能 Ｖｅｒ１．０」や「自動運転機能 Ｖｅｒ２．０」というものが定義される。ここで、ＳＷＩＤは、各ＥＣＵソフトのバージョンも考慮したＥＣＵソフトの組み合わせを定義した概念となっている。上記の例で言うと、「自動運転機能 Ｖｅｒ１．０」は、「ハンドルＥＣＵ Ｖｅｒ１．０」と、「アクセルＥＣＵ Ｖｅｒ１．０」と、「ブレーキＥＣＵ Ｖｅｒ１．０」の組み合わせを示すものとする。また、「自動運転機能 Ｖｅｒ２．０」は、「ハンドルＥＣＵ Ｖｅｒ２．０」と、「アクセルＥＣＵ Ｖｅｒ２．０」と、「ブレーキＥＣＵ Ｖｅｒ２．０」の組み合わせを示すものとする。

そして、本実施形態では、このようなＳＷＩＤ単位でハッシュ値が生成される。例えば、「自動運転機能 Ｖｅｒ１．０」として定義される各ＥＣＵソフト（以下、構成ＥＣＵと呼ぶ）のシリアル番号およびバージョン番号に基づいてハッシュ値が生成される。このハッシュ値は、いわば、ＳＷＩＤに係るＥＣＵソフトのソフトウェア的な構成を示す構成情報であるともいえる。そして、当該ハッシュ値がＯＴＡマスタからセンタに送信される。センタでは、自身に記憶されている、または、自身で算出可能な「自動運転機能 Ｖｅｒ１．０」に対応するハッシュ値と、ＯＴＡマスタから送信されたハッシュ値とを比較することによって、当該ＳＷＩＤに係る構成ＥＣＵの更新処理の必要性が判断される。より具体的には、上記ハッシュ値が一致すれば更新の必要なし、不一致の場合は、更新の必要性がある、と判断される。

（第１の実施例）
以下、上記のようなＳＷＩＤを用いる処理の適用例を説明する。第１の実施例として、次のようなケースを想定する。第１の実施例では、所定のＥＣＵの交換が発生した結果、あるＳＷＩＤとして定義されるＥＣＵソフトのバージョンの組み合わせと実際のＥＣＵソフトのバージョンの組み合わせとが不一致となった場合を想定する。具体的には、「自動運転機能 Ｖｅｒ２．０」が実装されている車両について、アクセル制御用のＥＣＵが交換された結果、アクセルＥＣＵのバージョンが「Ｖｅｒ２．０」から「Ｖｅｒ１．０」に変化した場合を想定する。この場合、「自動運転機能 Ｖｅｒ２．０」として定義されているＥＣＵソフトのバージョンの組み合わせについては、本来はアクセルＥＣＵ、ハンドルＥＣＵ、ブレーキＥＣＵの３つとも「Ｖｅｒ ２．０」であるべきだが、上記ＥＣＵの交換の結果、この組み合わせとは異なった状態となる（以下では、この状態のことを不一致状態と呼ぶこともある）。このような状態で車両を稼働させることは、安心・安全の観点から好ましくないと考えられるため、アクセルＥＣＵについて、「Ｖｅｒ １．０」から「Ｖｅｒ ２．０」に更新（バージョンアップ）する必要がある。

第１の実施例では、上記のような不一致状態が発生した場合、構成に変化が発生したＳＷＩＤが検出され、当該構成の変化が発生したＳＷＩＤに係るハッシュ値（以下、ＳＷＩＤハッシュ値と呼ぶ）が生成される。上記の例では「自動運転機能 Ｖｅｒ２．０」の構成ＥＣＵであるアクセルＥＣＵに変化が発生しているため、その時点における「ハンドルＥＣＵ」と、「アクセルＥＣＵ」と、「ブレーキＥＣＵ」のそれぞれのバージョンに基づいてＳＷＩＤハッシュ値が生成される。すなわち、「ハンドルＥＣＵ Ｖｅｒ２．０」と、（交換によってバージョンが変わった）「アクセルＥＣＵ Ｖｅｒ１．０」と、「ブレーキＥＣＵ Ｖｅｒ２．０」とに基づいたＳＷＩＤハッシュ値が生成される。そして、当該ＳＷＩＤハッシュ値をセンタに送信し、センタ側で更新の必要性を判断してもらい、必要であればアクセルＥＣＵについての更新処理を行う、という処理が実行される。以下、第１の実施例について、より詳細に説明する。

［第１の実施例のシステム全体の構成について］
図１は、第１の実施例における更新制御システムの全体構成を示すブロック図である。当該更新制御システムは、センタ１、車両３を備えている。

センタ１は、車両３に備えられる車載機器のソフトウェアの更新を管理するためのサーバである（より正確には、センタ１はこのようなサーバを含むセンタシステムであるが、以下では説明の便宜上、サーバとして説明する）。センタ１は、車両３（ＯＴＡマスタ３１）と通信可能である。

車両３は、車載ネットワークシステムを搭載している。当該車載ネットワークシステムは、センタ１と通信可能である。車載ネットワークシステムは、ＯＴＡマスタ（ソフトウェア更新装置）３１と、通信モジュール３２と、複数のＥＣＵ（電子制御装置）３３ａ～３３ｄとを少なくとも備える。

ＯＴＡマスタ３１は、バス３５を介して通信モジュール３２、ＥＣＵ３３ａ～３３ｄと接続されている。ＯＴＡマスタ３１は、通信モジュール３２を介してセンタ１と無線での通信が可能である。ＯＴＡマスタ３１は、センタ１との間で所定のデータの送受信を行いながら、各ＥＣＵ３３のソフトウェア更新処理の制御を実行する。すなわち、ＯＴＡマスタ３１は、ソフトウェア更新機能を有する。通信モジュール３２は、所定のネットワーク（電話網やインターネット網等）と接続する通信機器である。

ＥＣＵ３３ａ～３３ｄは、車両３の各部の動作を制御する。なお、図１におけるＥＣＵ３３の数は一例であることはいうまでもない。

［センタ１の構成について］
図２は、上記センタ１の概略構成を示すブロック図である。図２に示すように、センタ１は、プロセッサ１１と、ＲＡＭ１２と、記憶装置１３と、通信装置１４とを備える。記憶装置１３は、ハードディスクやＳＳＤ等の読み書き可能な記憶媒体を備え、本実施形態に係る処理に必要な各種のプログラムやデータを記憶する。センタ１において、プロセッサ１１は、記憶装置１３から読み出したプログラムを、ＲＡＭ１２を作業領域として用いて実行することにより、所定の制御処理を実行する。通信装置１４は、ネットワークを介して、車両３と通信を行う機器である。

［ＯＴＡマスタ３１の構成について］
図３は、上記ＯＴＡマスタ３１の概略構成を示すブロック図である。図３に示すように、ＯＴＡマスタ３１は、プロセッサ４１と、ＲＡＭ４２と、ＲＯＭ４３と、記憶装置４４とを備えるマイクロコンピュータ４５と、通信装置４６とを備える。ＯＴＡマスタ３１において、マイクロコンピュータ４５のプロセッサ４１は、ＲＯＭ４３から読み出したプログラムを、ＲＡＭ４２を作業領域として用いて実行することにより、所定の制御処理を実行する。通信装置４６は、図１に示したバス３５を介して、通信モジュール３２、ＥＣＵ３３ａ～３３ｄと通信を行う機器である。

［センタ１の機能ブロック図］
図４は、上記センタ１の機能ブロック図である。センタ１は、記憶部１６と通信部１７と制御部１８とを備える。通信部１７及び制御部１８は、図２に示したプロセッサ１１がＲＡＭ１２を用いて記憶装置１３に記憶されるプログラムを実行することにより実現され、記憶部１６は、図２に示した記憶装置１３により実現される。

記憶部１６は、本実施例に係る処理で使用するプログラムやデータを記憶する。

制御部１８は、通信部１７を用いて、ＯＴＡマスタ３１との間で所定のデータの送受信を行い、ソフトウェア更新処理を実行する。

［ＯＴＡマスタ３１の機能ブロック図］
図５は、図３に示したＯＴＡマスタ３１の機能ブロック図である。

ＯＴＡマスタ３１は、記憶部４７と、通信部４８と、制御部４９とを備える。記憶部４７は、図３に示した記憶装置４４によって実現され、通信部４８と、制御部４９とは、図３に示したプロセッサ４１がＲＡＭ４２を用いてＲＯＭ４３に記憶されるプログラムを実行することにより実現される。

記憶部４７は、ソフトウェア更新処理を実行するための各種プログラムや各種データを記憶する。

制御部４９は、通信部４８を介してセンタ１と通信を行い、ソフトウェア更新処理に関する各種の制御を実行する。具体的には、制御部４９は、上記例示したようなソフトウェア構成の変化発生の検出処理、変化が発生していた場合にＳＷＩＤハッシュ値を生成してセンタに送信する処理、そして、必要に応じて、所定のＥＣＵソフトを更新する処理を実行する。

以下、第１の実施例に係る処理の詳細について説明する。

［センタ１で用いられるデータについて］
まず、センタ１の処理で用いられるデータについて説明する。図６は、センタ１の記憶部１６に記憶されるデータの一例を示すメモリマップである。記憶部１６には、更新制御プログラム１０１、ＳＷＩＤデータベース１０２、車両データベース１０３が記憶される。また、図示は省略するが、その他、ＯＴＡサービスを実現するための各種プログラムやデータも記憶部１６に記憶される。

更新制御プログラム１０１は、本実施形態に係るソフトウェア更新の処理を制御するためのプログラムである。

ＳＷＩＤデータベース１０２は、上述したＳＷＩＤについて定義したデータベースである。また、当該ＳＷＩＤデータベース１０２では、車両に実装され得る全てのＳＷＩＤについて定義されている。図７は、当該ＳＷＩＤデータベース１０２のデータ構成の一例を示す図である。ＳＷＩＤデータベース１０２は、ＳＷＩＤ１１１と構成情報１１２との項目を少なくとも有するデータベースである。ＳＷＩＤ１１１は、上記「自動運転機能 Ｖｅｒ１．０」等のような、ＳＷＩＤを特定するためのデータである。構成情報１１２は、そのＳＷＩＤ（に対応する機能）を構成する上記構成ＥＣＵに関するデータである。具体的は、構成情報１１２は、構成ＥＣＵ１１３およびＶｅｒ情報１１４の項目を有するテーブル形式のデータである。構成ＥＣＵ１１３は、そのＳＷＩＤを構成するＥＣＵソフトを特定するためのデータである。Ｖｅｒ情報１１４は、各ＥＣＵソフトのバージョンを示すデータである。図７の例では、「自動運転機能 Ｖｅｒ１．０」というＳＷＩＤ１１１は、「アクセルＥＣＵ Ｖｅｒ１．０」と、「ブレーキＥＣＵ Ｖｅｒ１．０」と、「ハンドルＥＣＵ Ｖｅｒ１．０」との組み合わせから構成されることが定義されている。

図６に戻り、次に、車両データベース１０３は、ＯＴＡサービスの提供対象となる車両に関する情報を登録したデータベースである。図８は、車両データベース１０３のデータ構成の一例を示す図である。車両データベース１０３は、ＶＩＮ１２１と前回記憶情報１２２との項目を少なくとも有するデータベースである。ＶＩＮ１２１は、車両を一意に特定するための番号である。前回記憶情報１２２は、ＶＩＮ１２１で示される車両について直近の更新処理が完了した時点における、上記ＳＷＩＤに関する情報である。具体的には、前回記憶情報１２２は、ＳＷＩＤ１２３および前回ハッシュ値１２４とを含むテーブル形式のデータである。ＳＷＩＤ１２３は、その車両に実装されているＳＷＩＤ（に対応する機能）を示すデータである。そのため、その内容は車両によって異なり得る。前回ハッシュ値１２４は、そのＳＷＩＤに対応するＳＷＩＤハッシュ値である。本実施例では、当該値は、上記ＳＷＩＤデータベース１０２の情報に基づいて算出されるハッシュ値を同じ値となるものではあるが、当該算出に係る処理の手間を省くために、ハッシュ値自体を記憶しているものである。

［ＯＴＡマスタ３１で用いられるデータについて］
次に、ＯＴＡマスタ３１で用いられるデータについて説明する。図９は、ＯＴＡマスタ３１の記憶部４７に記憶されるデータの一例を示すメモリマップである。ＯＴＡマスタ３１の記憶部４７には、更新制御プログラム１５１、実装ＳＷＩＤ定義データ１５２、チェック用ＳＷＩＤハッシュ値１５３が少なくとも記憶されている。その他、図示は省略するが、ＯＴＡサービスを実現するための各種プログラムやデータも記憶部４７に記憶される。

更新制御プログラム１５１は、本実施例に係る処理をＯＴＡマスタ３１が実行するためのプログラムである。

実装ＳＷＩＤ定義データ１５２は、その車両に実装されているＳＷＩＤ（に対応する機能）に関するデータである。図１０は、当該実装ＳＷＩＤ定義データ１５２のデータ構成の一例を示す図である。実装ＳＷＩＤ定義データ１５２は、ＳＷＩＤ１６１および構成情報１６２との項目を少なくとも含むデータベースである。その基本的なデータ構成は、上記ＳＷＩＤデータベース１０２と同様であるため、詳細な説明は省略するが、当該実装ＳＷＩＤ定義データ１５２は、上記ＳＷＩＤデータベース１０２に含まれるデータのうち、その車両で現在実装されているＳＷＩＤに係るデータのみ抽出されたような内容となっている。また、当該実装ＳＷＩＤ定義データ１５２は、更新処理の際にその内容も更新され得る。例えば、ＯＴＡサービスによる更新処理の結果、「自動運転機能Ｖｅｒ１．０」が「自動運転機能Ｖｅｒ２．０」に更新された場合、当該実装ＳＷＩＤ定義データ１５２の内容も当該更新内容に応じて更新される。

図９に戻り、チェック用ＳＷＩＤハッシュ値１５３は、ＯＴＡサービスに係る更新処理によるもの以外で車両のソフトウェア構成に変化が発生したか否かを判定するために用いられるデータである。本実施例では、整備工場でＥＣＵが物理的に交換される場合を想定して説明している。そのため、当該チェック用ＳＷＩＤハッシュ値１５３は、例えば整備員が交換作業前に所定の操作を行うことで生成されるものとする。具体的には、当該所定の操作に基づいて、その時点での（車両に実装されている）各ＳＷＩＤに係るＳＷＩＤハッシュ値が算出され、これらが記憶部４７に記憶されることで当該チェック用ＳＷＩＤハッシュ値１５３が生成されるものとする。図１１に、当該チェック用ＳＷＩＤハッシュ値１５３のデータ構成の一例を示す。チェック用ＳＷＩＤハッシュ値１５３は、ＳＷＩＤ１７１とチェック用ハッシュ値１７２との項目を有するテーブル形式のデータである。ＳＷＩＤ１７１は、その車両に実装されているＳＷＩＤを示すデータである。チェック用ハッシュ値１７２は、交換作業前におけるＳＷＩＤハッシュ値を記憶したデータである。

［第１実施例の処理フロー］
次に、第１の実施例の処理の流れについて説明する。図１２～図１３は、第１の実施例に係る更新制御処理の詳細を示すフローチャートである。なお、図１２および図１３では、図の左側にＯＴＡマスタ３１が実行する処理を示し、図の右側にセンタ１が実行する処理を示している。また、本実施例では、ＯＴＡマスタ３１側の処理については、車両のイグニッションがオンにされたときに実行が開始されるものとする。また、以下の説明では、上記チェック用ＳＷＩＤハッシュ値１５３については、上記のように整備員によって既に生成されている状態であるとする。

まず、ステップＳ１で、ＯＴＡマスタ３１の制御部４９は、自車に実装されているＥＣＵソフトについて、ソフトウェア構成の変化が発生したか否かを判定する。つまり、不一致状態となっているＳＷＩＤがあるか否かを判定する。当該判定手法はどのような手法でもよいが、本実施例では、ＥＣＵ交換作業の前後でＳＷＩＤハッシュ値を比較する手法を例示する。具体的には、上記のようなＥＣＵ交換作業の前に、整備員の操作に基づいて、その車両に実装されている全てのＳＷＩＤに係るＳＷＩＤハッシュを保存しておく。そして、制御部４９は、交換後のＳＷＩＤハッシュ値と当該保存したＳＷＩＤハッシュ値とがそれぞれ一致するか否かをＳＷＩＤ単位で見ることで、ソフトウェア構成の変化の発生を判断する。すなわち、制御部４９は、各ＳＷＩＤのＳＷＩＤハッシュ値を算出し、それぞれを上記チェック用ＳＷＩＤハッシュ値１５３の内容と比較する。そして、不一致のＳＷＩＤハッシュ値があれば、制御部４９は、そのＳＷＩＤに係るソフトウェア構成に変化が発生したと判定する。不一致のＳＷＩＤハッシュ値が無い場合は、制御部４９は、ソフトウェア構成の変化は発生していないと判定する。

なお、当該ステップＳ１の処理に関して、第１の実施例では、その車両に実装されている全てのＳＷＩＤに係るＳＷＩＤハッシュ値を保存し、全ＳＷＩＤをチェックすることで構成変化が発生したＳＷＩＤを検出する例を挙げた。他の実施例では、次のようにしてもよい。例えば、整備工場においては、交換作業の対象となるＥＣＵは事前に判別できると考えられる。そのため、交換作業の開始前に、当該交換対象ＥＣＵを構成ＥＣＵとしているＳＷＩＤを示すデータと、そのＳＷＩＤハッシュ値のみを上記チェック用ＳＷＩＤハッシュ値１５３として保存するようにしてもよい。そして、ステップＳ１の処理では、当該交換対象ＥＣＵに係るＳＷＩＤについてのみ、上記のような比較処理を行うようにしてもよい。これにより、処理の高速化を図ることが可能となる。

上記ステップＳ１の判定の結果、ソフトウェア構成に変化が発生していない場合は（ステップＳ１でＮＯ）、車両側の更新制御処理は終了する。一方、ソフトウェア構成に変化が発生している場合は（ステップＳ１でＹＥＳ）、ステップＳ２で、制御部４９は、ソフトウェア構成に変化が発生したＳＷＩＤに係るＳＷＩＤハッシュ値を算出する。そして、制御部４９は、更新の有無を問い合わせるためのデータである「更新問い合わせ」を生成してセンタ１に送信する。この際、制御部４９は、当該「更新問い合わせ」に自車を示すＶＩＮと、変化が発生したＳＷＩＤと、上記算出したＳＷＩＤハッシュとを含めて送信する。

次に、ステップＳ３で、センタ１の制御部１８は、所定の車両から上記ＳＷＩＤハッシュを含む「更新問い合わせ」が送信されてきたか否かを判定する。送信されてきていない場合は（ステップＳ３でＮＯ）、制御部１８は、ステップＳ３の処理を繰り返す（つまり、「更新問い合わせ」を待ち受ける）。送信されてきた場合は（ステップＳ３でＹＥＳ）、次に、ステップＳ４で、制御部１８は、当該「更新問い合わせ」を受信し、これに含まれるＳＷＩＤハッシュ値に基づくチェック処理を実行する。具体的には、制御部１８は、車両データベース１０３を参照し、当該「更新問い合わせ」の送信元の車両（ＯＴＡマスタ３１）を特定する。更に、制御部１８は、「更新問い合わせ」に含まれているＳＷＩＤに対応する前回ハッシュ値１２４を車両データベース１０３から取得する。そして、制御部１８は、前回ハッシュ値１２４と上記ＳＷＩＤハッシュとが一致する否かを判定する。当該判定の結果、ハッシュ値が一致する場合は（ステップＳ４でＹＥＳ）、ステップＳ５で、制御部１８は、更新処理は不要であることを示す更新不要通知をＯＴＡマスタ３１に送信する。その後、制御部１８は、ステップＳ３の処理に戻る。

一方、上記判定の結果、ハッシュ値が不一致の場合は（ステップＳ４でＮＯ）、ステップＳ６で、制御部１８は、該当するＳＷＩＤに係る詳細情報の送信要求をＯＴＡマスタ３１に送信する。この詳細情報とは、（ＳＷＩＤハッシュではなく）ＳＷＩＤの構成ＥＣＵそれぞれの具体的なソフトウェアのバージョンを示す情報である。当該送信要求を送信すれば、制御部１８は、ＯＴＡマスタ３１からのレスポンスを待ち受ける。

次に、ステップＳ７で、ＯＴＡマスタ３１の制御部４９は、詳細情報の送信要求があるか否かを判定する。具体的には、制御部４９は、更新不要通知が送信されてきたか、詳細情報の送信要求が送信されてきたかを判定する。更新不要通知が送信されてきた場合は（ステップＳ７でＮＯ）、詳細情報の要求はされなかったとして、制御部４９は、車両側の更新制御処理を終了する。一方、詳細情報の送信要求が送信されてきた場合は（ステップＳ７でＹＥＳ）、次に、ステップＳ８で、制御部４９は、詳細情報を生成してセンタ１に送信する。具体的には、制御部４９は、上記送信要求において指定されているＳＷＩＤの構成ＥＣＵのそれぞれについて、そのソフトウェアバージョンの情報を取得する。そして、制御部４９は、これらの情報が含まれる詳細情報を生成して、センタ１に送信する。その後、制御部４９は、センタ１からの指示を待ち受ける。

次に、ステップＳ９で、センタ１の制御部１８は、上記送信された詳細情報を受信する。次に、ステップＳ１０で、制御部１８は、当該詳細情報に基づき、バージョンが不一致のＥＣＵソフトを特定する。具体的には、制御部１８は、詳細情報で示される各構成ＥＣＵのバージョンと、ＳＷＩＤデータベース１０２で定義されているＶｅｒ情報１１４とを比較していくことで、バージョンが不一致である構成ＥＣＵを特定する。以下、この構成ＥＣＵのことを不一致ＥＣＵと呼ぶ。

次に、図１３のステップＳ１１で、制御部１８は、不一致ＥＣＵについて、更新処理を行って不一致状態を解消する必要があるか否かを判定する。これは、原則的には不一致状態を解消すべきではあるが、ソフトウェアのバージョン次第では、不一致状態のままでも機能的には問題ない、というケースがあり得ることを考慮したものである。例えばアクセルＥＣＵのバージョンが２．０から２．１に上がった場合であって、その変更箇所が自動運転機能の実現に関して何ら影響を及ぼさないような変更である場合は、ＳＷＩＤデータベース１０２で定義されている内容とは一致しない場合であっても、更新不要と判定することもあり得る。これにより、必ずしも必要ではない更新処理を行わずに済ませることができ、通信量の削減を図ることもできる。なお、このような、不一致状態でも許容されるバージョンの情報については、図示は省略するが、センタ１の記憶部１６にその情報を示すデータが記憶されていてもよい。そして、この情報に基づき、制御部１８が更新処理の必要性を判定すればよい。

上記ステップＳ１１の判定の結果、不一致状態の解消の必要性がないと判定された場合は（ステップＳ１１でＮＯ）、ステップＳ１２で、制御部１８は、上記更新不要通知をＯＴＡマスタ３１に送信する。そして、制御部１８は、上記ステップＳ３に戻り、処理を繰り返す。

一方、上記ステップＳ１１の判定の結果、不一致状態の解消の必要性があると判定された場合は（ステップＳ１１でＹＥＳ）、更新処理が実行される。具体的には、まず、ステップＳ１３で、制御部１８は、更新開始指示をＯＴＡマスタ３１に送信する。次に、ステップＳ１４で、ＯＴＡマスタ３１の制御部４９は、更新開始指示が来たか否かを判定する。当該判定の結果、更新開始指示ではなく、更新不要通知が来ている場合は（ステップＳ１４でＮＯ）、制御部４９は、ＯＴＡマスタ３１側の更新制御処理を終了する。一方、更新開始指示が来ている場合は（ステップＳ１４でＹＥＳ）、ステップＳ１５およびステップＳ１６で、センタ１の制御部１８およびＯＴＡマスタ３１の制御部４９は、適宜協働しながら、不一致ＥＣＵに係る更新処理を実行する。具体的には、センタ１の制御部１８は、更新用のデータをＯＴＡマスタ３１に送信し、ＯＴＡマスタ３１の制御部４９は、当該更新用データに基づいて不一致ＥＣＵのソフトウェアを更新する処理を実行する。

次に、ステップＳ１７で、制御部４９は、更新処理が完了したか否かを判定する。まだ完了していなければ（ステップＳ１７でＮＯ）、上記ステップＳ１５に戻り、更新処理を継続する。更新処理が完了すれば（ステップＳ１７でＹＥＳ）、制御部４９は、更新完了通知をセンタ１に送信する。更に、ステップＳ１８で、制御部４９は、更新後のＳＷＩＤハッシュ値を生成し、センタ１に送信する。

一方、センタ１では、ステップＳ１９で、制御部１８は、ＯＴＡマスタ３１から上記更新完了通知を受信したか否かを判定し、受信していない場合はステップＳ１６に戻り、更新処理を継続する。更新完了通知を受信した場合は、ステップＳ２０で、制御部１８は、ＯＴＡマスタ３１から送信された上記更新後のＳＷＩＤハッシュ値を受信し、車両データベース１０３の前回ハッシュ値１２４として記録する。その後、制御部１８は、上記ステップＳ３に戻り、処理を繰り返す。

次に、ステップＳ２１で、ＯＴＡマスタ３１の制御部４９は、チェック用ＳＷＩＤハッシュ値１５３の内容を、上記更新後のＳＷＩＤハッシュ値の内容で更新する。これにより、次に上記ステップＳ１の判定が行われた際に、構成変化は発生していないと判定されることになる。つまり、ソフトウェア構成の不一致状態が解消されたということになる。以上で、第１の実施例に係る更新制御処理は終了する。

このように、第１の実施例では、ＥＣＵ交換によって、交換前後でＥＣＵのソフトウェア構成に変化が発生した場合、変化が発生したＳＷＩＤに係るＥＣＵの情報だけをセンタ１に送信して更新処理を実行できる。これにより、上記総合ハッシュ値を用いる場合に比べて通信量を削減でき、また、更新処理を完了させるまでの時間を短縮することが可能となる。

（第２の実施例）
次に、上記のようなＳＷＩＤを用いる処理の、第２の実施例について説明する。第２の実施例では、次のようなケースを想定する。第２の実施例では、所定のＥＣＵについて緊急更新を行いたい、という場合を想定する。ＯＴＡサービスでは、通常は、例えば２週間に１回のような頻度で、ＯＴＡマスタ３１からセンタ１に定期的に更新の有無の問い合わせを行い、そのタイミングで更新が存在すれば更新処理を行っている。しかし、時には緊急性の高い更新が発生するケースも考えられる。このような場合、第２の実施例として、以下のような処理が実行される。まず、センタ１から、ＯＴＡサービスで用いるネットワーク（インターネット網）とは異なる経路、例えばキャリア網のＳＭＳ（ショートメッセージサービス）やＶ２Ｘ等で、ＯＴＡマスタ３１にセンタ１への「更新問い合わせ」を行わせるためのコマンド（以下、センタコマンドと呼ぶ）を送信する。本実施例では、ＳＭＳで当該センタコマンドを送信する場合を例に挙げる。このセンタコマンドには、緊急更新対象となるＥＣＵが構成ＥＣＵとなっているＳＷＩＤを示す情報が含まれている。車両側では、制御部４９は、当該センタコマンドを受信すると、次回のイグニッションオンのタイミングで、当該センタコマンドで示されているＳＷＩＤに係るＳＷＩＤハッシュ値をセンタ１に送信する。センタ１では、制御部１８は、当該ＳＷＩＤハッシュ値に基づき、その車両に対する更新処理の必要性を判定する。そして、必要な場合は、緊急更新に係る処理が実行されることになる。

以下、第２の実施例の詳細について説明する。まず、第２の実施例におけるハードウェア構成（センタ１およびＯＴＡマスタ３１）については、基本的には、上記第１の実施例と同様のため、詳細な説明は割愛するが、第２の実施例では、車両３の通信モジュール３２は、上記センタコマンドを受信するセンタコマンド受信部としての機能も果たす。

次に、第２の実施例において使用するデータについては、基本的には、第１の実施例と同様のデータが用いられるが、ＯＴＡマスタ３１の記憶部４７に記憶されるデータに一部相違がある。図１４は、第２の実施例におけるＯＴＡマスタ３１の記憶部４７に記憶されるデータの一例を示すメモリマップである。ＯＴＡマスタ３１の記憶部４７には、更新制御プログラム１５１、実装ＳＷＩＤ定義データ１５２、センタコマンドデータ１８１が少なくとも記憶されている。このうち、更新制御プログラム１５１、実装ＳＷＩＤ定義データ１５２については、第１の実施例と同様のものであるため、説明は割愛する。

センタコマンドデータ１８１は、上記通信モジュール３２で受信されたセンタコマンドを記憶したものである。本実施例では、イグニッションオンのタイミングで、当該センタコマンドデータ１８１の有無が判定され、有る場合は、当該センタコマンドデータ１８１の内容に基づいた処理が実行される。なお、本実施例では、上記のような緊急更新を行うためのコマンド、具体的には、緊急更新の対象に係るＳＷＩＤをセンタ１に送信するような指示がセンタコマンドに定義されているとする。

次に、第２の実施例に係る処理の流れについて説明する。図１５は、第２の実施例に係る更新制御処理の詳細を示すフローチャートである。図１５では、図の左側にＯＴＡマスタ３１が実行する処理を示し、図の右側にセンタ１が実行する処理を示している。また、本実施例では、ＯＴＡマスタ３１側の処理については、車両のイグニッションがオンにされたときに実行が開始されるものとする。また、上記センタコマンドについては、既にセンタ１からＳＭＳで送信されてきており、センタコマンドデータ１８１に記憶されている状態であるとする。

まず、ステップＳ３１で、ＯＴＡマスタの制御部４９は、センタコマンドを受信しているか否かを判定する。具体的には、制御部４９は、センタコマンドデータ１８１を参照して、センタコマンドが記憶されていればセンタコマンドを受信していると判定し、記憶されていない場合はセンタコマンドは受信していないと判定する。当該判定の結果、センタコマンドを受信していない場合は（ステップＳ３１でＮＯ）、制御部４９は、第２の実施例に係る更新制御処理を終了する。一方、センタコマンドを受信している場合は（ステップＳ３１でＹＥＳ）、次に、ステップＳ３２で、制御部４９は、センタコマンドにおいて示されているＳＷＩＤに係るＳＷＩＤハッシュ値を算出する。そして、制御部４９は、当該ＳＷＩＤを示す情報、およびＳＷＩＤハッシュ値を含む「更新問い合わせ」を生成して、センタ１に送信する。

次に、ステップＳ３３で、センタ１の制御部１８は、所定の車両から、上記センタコマンドに基づく「更新問い合わせ」を受信したか否かを判定する。センタコマンドに基づいた「更新問い合わせ」であるか否かは、例えば、上記「更新問い合わせ」のヘッダ部分にセンタコマンドに基づく「更新問い合わせ」であることを示すデータを含めておき、制御部１８がこのデータに基づいて判定するようにすればよい。当該判定の結果、センタコマンドに基づく「更新問い合わせ」を受信していない場合は（ステップＳ３３でＮＯ）、ステップＳ３３の処理を繰り返す。すなわち、制御部１８は、センタコマンドに基づく「更新問い合わせ」の待ち受けを継続する。

一方、センタコマンドに基づく「更新問い合わせ」を受信した場合は（ステップＳ３３でＹＥＳ）、次に、ステップＳ３４で、制御部１８は、受信した「更新問い合わせ」に含まれるＳＷＩＤハッシュ値に基づき、更新処理の必要があるか否かを判定する。具体的には、制御部１８は、上記「更新問い合わせ」に含まれているＳＷＩＤハッシュ値が、今回の緊急更新の対象となるＳＷＩＤのハッシュ値と一致するか否かを判定する。そして、一致すれば、制御部１８は、更新の必要は無いと判定し、一致しない場合は更新の必要性ありと判定する。なお、このような緊急更新の必要が無い場合としては、上記緊急更新に係るセンタコマンドの受信前に、例えば整備工場において当該緊急更新と同内容の更新処理が既に行われている場合等が考えられる。

上記ステップＳ３４の判定の結果、更新の必要が無い場合は（ステップＳ３４でＮＯ）、ステップＳ３５で、制御部１８は、更新不要通知をＯＴＡマスタに送信する。一方、更新の必要がある場合は（ステップＳ３４でＹＥＳ）、ステップＳ３６で、制御部１８は、更新開始指示をＯＴＡマスタ３１に送信する。次に、ステップＳ３７で、ＯＴＡマスタ３１の制御部４９は、更新開始指示が来たか否かを判定する。当該判定の結果、更新開始指示ではなく、更新不要通知が来ている場合は（ステップＳ３７でＮＯ）、制御部４９は、更新制御処理を終了する。一方、更新開始指示が来ている場合は（ステップＳ３７でＹＥＳ）、ステップＳ３８およびステップＳ３９で、センタ１の制御部１８およびＯＴＡマスタ３１の制御部４９は、適宜協働しながら更新処理を実行する。具体的には、制御部４９は、上記第１の実施例において示したような詳細情報をセンタ１に送信する。センタ１の制御部１８は、更新が必要なＥＣＵソフトを特定し、更新用のデータをＯＴＡマスタ３１に送信する。そして、ＯＴＡマスタ３１の制御部４９は、当該更新用データに基づいて、緊急更新の対象となるＥＣＵソフトを更新する処理を実行する。

次に、ステップＳ４０で、制御部４９は、更新処理が完了したか否かを判定する。まだ完了していなければ（ステップＳ４０でＮＯ）、上記ステップＳ３８に戻り、更新処理を継続する。更新処理が完了すれば（ステップＳ４０でＹＥＳ）、制御部４９は、更新完了通知をセンタ１に送信する。

一方、センタ１では、ステップＳ４１で、制御部１８は、上記更新完了通知を受信したか否かを判定し、受信していない場合は（ステップＳ４１でＮＯ）、ステップＳ３９に戻り、更新処理を継続する。更新完了通知を受信した場合は（ステップＳ４１でＹＥＳ）、制御部１８は、上記ステップＳ３３に戻り、処理を繰り返す。

次に、ステップＳ４２で、ＯＴＡマスタの制御部４９は、センタコマンドデータ１８１をクリアする。これにより、新たなセンタコマンドを受信しない限り、上記ステップＳ３１の判定でセンタコマンドを受信していないと判定されることになる。

以上で、第２の実施例に係る更新制御処理は終了する。

このように、第２の実施例では、緊急更新がある場合、その更新対象のＥＣＵが事前に判別できるため、上記センタコマンドにおいて、更新対象ＥＣＵに係るＳＷＩＤだけを送信するような指示を含めている。そのため、全ＥＣＵにかかる処理を行うことなく、緊急更新対象のＥＣＵに関係するＳＷＩＤ単位で、更新の必要性を判定できる。これにより、緊急更新にかかる処理をより速やかに完了させることが可能となる。

（第３の実施例）
次に、第３の実施例について説明する。第３の実施例は、上述した第１の実施例および第２の実施例を組み合わせた処理の例示である。具体的には、上記センタコマンドを受信した場合に、ソフトウェア構成の変化が発生していれば、その構成変化に係るＳＷＩＤのＳＷＩＤハッシュ値も送信し、センタコマンドによる処理の実行開始前に、不一致状態を解消しておくという処理である。換言すれば、センタコマンドが送られてきたことをトリガとして、ソフトウェア構成に変化が発生したＳＷＩＤをセンタに送信し、必要であれば不一致状態を解消するという処理である。

図１６は、第３の実施例に係る処理の流れを示すフローチャートである。なお、図１６では、ＯＴＡマスタ３１が実行する処理のみについて示している。図１６において、まず、ステップＳ５１で、制御部４９は、センタコマンドを受信しているか否かを判定する。この処理は、上記ステップＳ３１と同様の処理である。当該判定の結果、センタコマンドを受信している場合は（ステップＳ５１でＹＥＳ）、次に、ステップＳ５２で、制御部４９は、自車に実装されているＥＣＵソフトについて、ソフトウェア構成の変化が発生したか否かを判定する。この処理は、上記図１２で示したステップＳ１と同様の処理が行われる。当該判定の結果、ソフトウェア構成に変化が発生していない場合は（ステップＳ５２でＮＯ）、後述のステップＳ５５に処理が進められる。

一方、ソフトウェア構成に変化が発生している場合は（ステップＳ５２でＹＥＳ）、ステップＳ５３で、制御部４９は、ソフトウェア構成に変化が発生したＳＷＩＤ（に対応するＥＣＵソフト）が、上記センタコマンドにおいて示されている更新対象に含まれているか否かを判定する。当該判定の結果、ソフトウェア構成の変化があったＳＷＩＤがセンタコマンドで示される更新対象に含まれていれば、センタコマンドに基づく更新処理で対処し、当該更新対象に含まれていない場合は別途不一致状態の解消処理を実行するという制御が行われる。具体的には、ソフトウェア構成に変化が発生したＳＷＩＤがセンタコマンドにおいて示されている更新対象に含まれていない場合は（ステップＳ５３でＮＯ）、ステップＳ５４で、制御部４９は、不一致状態を解消するための処理を実行する。すなわち、制御部４９は、第１の実施例として上述したような処理を行うことで、不一致状態の解消を行う。その後、ステップＳ５５に処理が進められる。

一方、上記ステップＳ５３の判定の結果、ソフトウェア構成に変化が発生したＳＷＩＤが、上記センタコマンドにおいて示されている更新対象に含まれている場合は（ステップＳ５３でＹＥＳ）、ステップＳ５５で、制御部４９は、センタコマンドに基づく更新処理を実行する。すなわち、制御部４９は、第２の実施例として上述したような処理を実行し、センタコマンドにおいて示されている更新対象のＥＣＵソフトを更新する。その後、制御部４９は、第３の実施例に係る更新制御処理を終了する。

一方、上記ステップＳ５１の判定の結果、センタコマンドを受信していない場合は（ステップＳ５１でＮＯ）、ステップＳ５６で、制御部４９は、自車に実装されているＥＣＵソフトについて、ソフトウェア構成の変化が発生したか否かを判定する。この処理は、上記ステップＳ３１と同様の処理である。当該判定の結果、ソフトウェア構成に変化が発生している場合は（ステップＳ５６でＹＥＳ）、ステップＳ５７で、制御部４９は、不一致状態を解消するための処理を実行する。すなわち、上記ステップＳ５４の処理と同様に、制御部４９は、第１の実施例として上述したような処理を行うことで、不一致状態の解消を行う。

一方、ソフトウェア構成に変化が発生していない場合は（ステップＳ５６でＮＯ）、制御部４９は、第３の実施例に係る更新制御処理を終了する。

このように、第３の実施例では、センタコマンドを受信した場合に、ソフトウェア構成に変化が発生していれば、当該変化が発生したＳＷＩＤに関する情報をセンタに送信している。そのため、センタコマンドによる処理を実行する際に、不一致状態の解消処理も併せて実行することができる。これにより、処理が二度手間にならないように済ませることができ、また、不一致状態を速やかに解消できる。

［変形例］
なお、上記第２の実施例として、緊急更新の場合にセンタコマンドをＳＭＳ等で送信する例を挙げたが、このような場合に限らず、緊急更新対応以外の内容のセンタコマンドを送信してもよい。例えば、他の実施例では、ソフトウェア構成に変化があったＳＷＩＤの情報のみをセンタ１に送信する旨の指示が含まれるセンタコマンドを送信するようにしてもよい。この場合、ＯＴＡマスタ３１の制御部４９は、センタコマンドの指示に従って、構成に変化が発生したＳＷＩＤに係るＳＷＩＤハッシュを算出してセンタ１に送信すればよい。つまり、上記第１の実施例で示したような不一致箇所を解消する処理を開始させるためにセンタコマンドを送信する構成としてもよい。

また、センタコマンドに関しては、その他、次のような場合にも、上記のようなソフトウェア構成に変化があったＳＷＩＤの情報のみをセンタ１に送信する旨のセンタコマンドを送信するようにしてもよい。例えば、車両側でＥＣＵ交換が行われた結果、所定のＳＷＩＤについてソフトウェア構成に変化が発生しており、ＯＴＡマスタ３１側では何らかの事情でこの変化を把握できていないが、センタ１側ではこの変化を把握できている、という場合を想定する。センタ１側でこのような変化を把握する手法としては、例えばＥＣＵ交換作業の完了時に整備工場からセンタ１に交換作業内容に関する情報が送信された場合等が考えられる。このような場合に、センタ１側では、当該交換作業が行われた車両について、変化が発生した（または、発生している可能性がある）ＳＷＩＤを特定することが可能である。そこで、このような場合に上記第１の実施例で示したような処理を実行するため、交換されたＥＣＵに対応するＳＷＩＤに係る情報をセンタ１に送信する旨の指示を、センタコマンドに含めてＯＴＡマスタ３１に送信するようにしてもよい。

また、上記第１の実施例では、ソフトウェア構成に変化が発生した場合に、その変化に係るＳＷＩＤハッシュ値をセンタ１に送信していた。また、第２および第３の実施例では、センタコマンドを受信したことをトリガーとしてセンタ１に所定のＳＷＩＤハッシュ値を送信していた。このようなＳＷＩＤの送信について、他の実施例では、以下のような処理を行ってもよい。すなわち、ＯＴＡサービスにおける通常の更新処理の問い合わせのタイミングで、上記のＳＷＩＤハッシュ値をセンタ１に送信するような構成としてもよい。ＯＴＡサービスにおける更新処理では、例えば、２週間に１度のような頻度で定期的に、センタ１に更新有無の問い合わせを行っている。当該問い合わせの際、従来は上記総合ハッシュ値を送信し、総合ハッシュ値について不一致と判定された場合、全ＥＣＵソフトのバージョン情報を要求している。このような、総合ハッシュ値の代わりに、所定の車両に実装されている分のＳＷＩＤハッシュ値をセンタ１に送信するようにしてもよい。そして、センタ１では、ＳＷＩＤ単位でチェック処理を行い、更新が必要なＳＷＩＤについてのみ、上述した詳細情報を要求するような構成としてもよい。この場合も、更新処理が完了するまでの時間の短縮を図ることが可能となる。

以上、本開示技術の一実施形態を説明したが、本開示は、ＯＴＡマスタだけでなく、プロセッサと、メモリとを少なくとも備え、ＯＴＡセンタとネットワークを介して通信可能なＯＴＡマスタのコンピュータが実行する更新制御方法、その方法の制御プログラム、その制御プログラムを記憶したコンピューター読み取り可能な非一時的な記録媒体、等として捉えることが可能である。

本開示技術は、ソフトウェア更新機能を制御するＯＴＡマスタに利用できる。

１ センタ
３ 車両
１１ プロセッサ
１２ ＲＡＭ
１３ 記憶装置
１４ 通信装置
３１ ＯＴＡマスタ
３２ 通信モジュール
３３ 電子制御装置
３５ バス
４１ プロセッサ
４２ ＲＡＭ
４３ ＲＯＭ
４４ 記憶装置
４６ 通信装置

Claims (6)

1. 複数の車載機器を含む車載ネットワークに接続されると共に、ＯＴＡセンタとネットワークを介して通信可能であり、１以上の前記車載機器のソフトウェアを更新するＯＴＡマスタであって、
   １以上の車載機器のソフトウェアの組み合わせによってグループ化される複数のソフトウェアグループについて、前記ソフトウェアのバージョンに変化が発生した前記ソフトウェアグループである更新対象ソフトウェアグループを判定する判定部と、
   前記判定部が判定した前記更新対象ソフトウェアグループのハッシュ値を生成する生成部と、
   前記生成部が生成した前記更新対象ソフトウェアグループのハッシュ値を、前記ＯＴＡセンタに送信する送信部と、
   前記更新対象ソフトウェアグループの詳細内容に関する要求を、前記ＯＴＡセンタから受信する受信部と、を備え、
   前記送信部は、前記受信部が前記要求を受信した場合に、前記更新対象ソフトウェアグループに含まれる全ての前記車載機器に関する情報を、前記ＯＴＡセンタに送信する、ＯＴＡマスタ。
2. 前記判定部は、所定のタイミングの前後において前記更新対象ソフトウェアグループの有無を判定する、請求項１に記載のＯＴＡマスタ。
3. 前記受信部は、所定の前記ソフトウェアグループに関する情報の送信を指示するコマンドが含まれているセンタコマンドをさらに受信し、
   前記送信部は、前記受信部が前記センタコマンドを受信した場合に、前記更新対象ソフトウェアグループの前記ハッシュ値を前記ＯＴＡセンタに送信する、請求項１に記載のＯＴＡマスタ。
4. 前記センタコマンドには、前記更新対象ソフトウェアグループの前記ハッシュ値の送信を指示するコマンドが少なくとも含まれている、請求項３に記載のＯＴＡマスタ。
5. プロセッサと、メモリとを少なくとも備え、ＯＴＡセンタとネットワークを介して通信可能なＯＴＡマスタのコンピュータが実行する更新制御方法であって、
   １以上の車載機器のソフトウェアの組み合わせによってグループ化される複数のソフトウェアグループについて、前記ソフトウェアのバージョンに変化が発生した前記ソフトウェアグループである更新対象ソフトウェアグループを判定するステップと、
   前記判定した前記更新対象ソフトウェアグループのハッシュ値を生成するステップと、
   前記生成した前記更新対象ソフトウェアグループのハッシュ値を、前記ＯＴＡセンタに送信するステップと、
   前記更新対象ソフトウェアグループの詳細内容に関する要求を、前記ＯＴＡセンタから受信するステップと、
   前記要求を受信した場合に、前記更新対象ソフトウェアグループに含まれる全ての前記車載機器に関する情報を、前記ＯＴＡセンタに送信するステップと、を備える、更新制御方法。
6. プロセッサと、メモリとを少なくとも備え、ＯＴＡセンタとネットワークを介して通信可能なＯＴＡマスタのコンピュータに実行させる更新制御プログラムであって、
   １以上の車載機器のソフトウェアの組み合わせによってグループ化される複数のソフトウェアグループについて、前記ソフトウェアのバージョンに変化が発生した前記ソフトウェアグループである更新対象ソフトウェアグループを判定するステップと、
   前記変化が発生したと判定した前記ソフトウェアグループのハッシュ値を生成するステップと、
   前記判定した前記更新対象ソフトウェアグループのハッシュ値を生成するステップと、
   前記生成した前記更新対象ソフトウェアグループのハッシュ値を、前記ＯＴＡセンタに送信するステップと、
   前記更新対象ソフトウェアグループの詳細内容に関する要求を、前記ＯＴＡセンタから受信するステップと、
   前記要求を受信した場合に、前記更新対象ソフトウェアグループに含まれる全ての前記車載機器に関する情報を、前記ＯＴＡセンタに送信するステップと、を前記コンピュータに実行させる、更新制御プログラム。

Images