特許 7582059 センタ、更新制御方法、更新制御プログラム、ＯＴＡマスタ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-11-05

(45)【発行日】2024-11-13

(54)【発明の名称】センタ、更新制御方法、更新制御プログラム、ＯＴＡマスタ

(51)【国際特許分類】

   G06F 8/65 20180101AFI20241106BHJP

【ＦＩ】

G06F8/65

【請求項の数】 5

(21)【出願番号】P 2021081819

(22)【出願日】2021-05-13

(65)【公開番号】P2022175440

(43)【公開日】2022-11-25

【審査請求日】2023-09-12

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】110001276

【氏名又は名称】弁理士法人小笠原特許事務所

(72)【発明者】

【氏名】長光 翔一

【審査官】西間木 祐紀

(56)【参考文献】

【文献】特開２００５－１３５１４７（ＪＰ，Ａ）

【文献】特開２００６－３４４２３０（ＪＰ，Ａ）

【文献】特開２０２１－０２２０１８（ＪＰ，Ａ）

【文献】特開２０２０－０２７６３９（ＪＰ，Ａ）

【文献】米国特許出願公開第２０２０／０４０１３９５（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ８／６５

(57)【特許請求の範囲】

【請求項1】

車両が備えるＯＴＡマスタとネットワークを介して通信可能なセンタであって、
ターゲットＥＣＵの更新ソフトウェアが１以上含まれているパッケージデータが１以上含まれているキャンペーンデータを前記ＯＴＡマスタに配信する配信部と、
所定の前記キャンペーンデータに含まれている所定の前記パッケージデータの内容について、当該キャンペーンデータの配信後に当該キャンペーンデータに基づく更新に伴う不具合が発見されたか否かを判定する不具合判定部と、
前記不具合が発見された場合、前記キャンペーンデータの適用に際して、当該不具合が発見されたパッケージデータの適用を行わないようにするための適用回避指示を当該キャンペーンデータの適用対象となる車両に所定のネットワークを介して送信する適用回避指示送信部と、を備える、センタ。

【請求項2】

前記センタは、前記不具合が発見されたパッケージデータと、当該パッケージデータが含まれている前記キャンペーンデータにおける他のパッケージデータとの関連度合いを判定する関連度判定部を更に備え、
前記適用回避指示送信部は、前記不具合が発見されたパッケージデータとその他のパッケージデータとの関連度合いが低いと判定された場合に、前記適用回避指示を送信する、請求項１に記載のセンタ。

【請求項3】

車両が備えるＯＴＡマスタとネットワークを介して通信可能なセンタのコンピュータが実行する更新制御方法であって、
ターゲットＥＣＵの更新ソフトウェアが１以上含まれているパッケージデータが１以上含まれているキャンペーンデータを前記ＯＴＡマスタに配信する配信ステップと、
所定の前記キャンペーンデータに含まれている所定の前記パッケージデータの内容について、当該キャンペーンデータの配信後に当該キャンペーンデータに基づく更新に伴う不具合が発見されたか否かを判定する不具合判定ステップと、
前記不具合が発見された場合、前記キャンペーンデータの適用に際して、当該不具合が発見されたパッケージデータの適用を行わないようにするため適用回避指示を当該キャンペーンデータの適用対象となる車両に所定のネットワークを介して送信する適用回避指示送信ステップとを備える、更新制御方法。

【請求項4】

プロセッサと、メモリとを少なくとも備え、車両が備えるＯＴＡマスタとネットワークを介して通信可能なセンタのコンピュータに実行させる更新制御プログラムであって、
ターゲットＥＣＵの更新ソフトウェアが１以上含まれているパッケージデータが１以上含まれているキャンペーンデータを前記ＯＴＡマスタに配信する配信ステップと、
所定の前記キャンペーンデータに含まれている所定の前記パッケージデータの内容について、当該キャンペーンデータの配信後に当該キャンペーンデータに基づく更新に伴う不具合が発見されたか否かを判定する不具合判定ステップと、
前記不具合が発見された場合、前記キャンペーンデータの適用に際して、当該不具合が発見されたパッケージデータの適用を行わないようにするための適用回避指示を当該キャンペーンデータの適用対象となる車両に所定のネットワークを介して送信する適用回避指示送信ステップと、を前記コンピュータに実行させる、更新制御プログラム。

【請求項5】

複数のＥＣＵを含む車載ネットワークに接続されると共に、センタとネットワークを介して通信可能であり、１以上の前記ＥＣＵのプログラムを更新するＯＴＡマスタであって、
ターゲットＥＣＵの更新ソフトウェアが１以上含まれているパッケージデータが１以上含まれているキャンペーンデータが存在するか否かの更新問い合わせを前記センタに送信する更新問い合わせ部と、
前記問い合わせの結果、前記キャンペーンデータがある場合、当該キャンペーンデータを前記センタから受信する第１受信部と、
前記センタから受信した前記キャンペーンデータに含まれる前記パッケージデータのうち、適用回避すべきパッケージがあるか否かの適用回避問い合わせを前記センタに送信する適用回避問い合わせ部と、
前記キャンペーンデータに含まれるパッケージデータを用いて前記ターゲットＥＣＵのソフトウェアを更新する更新処理部とを備え、
前記更新処理部は、前記適用回避問い合わせの結果、前記キャンペーンデータに含まれるパッケージデータの一部について適用を行わないことが示されている適用回避指示を前記センタから受信した場合は、当該適用回避指示で示されている所定のパッケージデータのみ適用しないようにして前記ターゲットＥＣＵのソフトウェアを更新する、ＯＴＡマスタ。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、車両が備えるＯＴＡマスタとネットワークを介して通信可能なセンタに関する。

【背景技術】

【0002】

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

【0003】

上記ＯＴＡサービスにおける更新処理では、更新対象となる所定のＥＣＵ（ターゲットＥＣＵと呼ばれる）のソフトウェアを更新するための更新ソフトウェアが１以上含まれているパッケージデータを、「キャンペーン」と呼ばれるイベント単位で配信している。パッケージデータの例を挙げると、例えば、「自動運転制御用のパッケージデータ」として、アクセルＥＣＵ用の更新ソフトウェア、ハンドルＥＣＵ用の更新ソフトウェア、ブレーキＥＣＵ用の更新ソフトウェアの３つの更新ソフトウェアが含まれる例がある。また、「ウィンドウ制御用のパッケージデータ」として、ウィンドウ制御ＥＣＵの更新ソフトウェアが含まれる例がある。そして、１つのキャンペーンには、複数のパッケージデータが含まれ得る。より具体的には、これらのパッケージデータを配信日時でまとめたものをキャンペーンデータとして生成し、当該キャンペーンデータを車両に配信している。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０２０－００４２４５号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

ここで、あるキャンペーンデータの配信後、そのキャンペーンデータに含まれるパッケージデータの一部に不具合が見つかった場合を想定する。このような場合、当該キャンペーンデータ自体の配信を停止していた。そのため、不具合はないが、重要度の高い更新ソフトウェアを含むパッケージデータがこのようなキャンペーンデータに含まれていた場合、当該キャンペーンデータ自体の配信停止によって、当該重要度の高い更新ソフトウェア（を含むパッケージデータ）の適用が遅れる虞があった。

【0006】

本開示は、上記課題を鑑みてなされたものであり、重要度の高い更新ソフトウェアを含むパッケージデータの適用を迅速に行うことが可能なセンタを提供することである。

【課題を解決するための手段】

【0007】

上記課題を解決するために、本開示技術の一態様は、車両が備えるＯＴＡマスタとネットワークを介して通信可能なセンタである。センタは、ターゲットＥＣＵの更新ソフトウェアが１以上含まれているパッケージデータが１以上含まれているキャンペーンデータをＯＴＡマスタに配信する配信部と、所定のキャンペーンデータに含まれている所定のパッケージデータの内容について、当該キャンペーンデータの配信後に更新に伴う不具合が発見されたか否かを判定する不具合判定部と、不具合が発見された場合、キャンペーンデータの適用に際して、当該不具合が発見されたパッケージデータの適用を行わないようにするため適用回避指示を当該キャンペーンデータの適用対象となる車両に所定のネットワークを介して送信する適用回避指示送信部と、を備える。

【発明の効果】

【0008】

本開示のセンタによれば、所定のキャンペーンデータに、不具合のあるパッケージデータと、不具合はないが重要度が高い更新ソフトウェアを含むパッケージとが含まれている場合であっても、不具合のあるパッケージの適用だけ回避しつつ、不具合がないパッケージについては適用できるため、重要度の高い更新ソフトウェアの適用を迅速に行うことができる。

【図面の簡単な説明】

【0009】

【図1】本実施形態に係るシステムの全体構成を示すブロック図

【図2】センタ１の概略構成を示すブロック図

【図3】ＯＴＡマスタ３１の概略構成を示すブロック図

【図4】センタ１の機能ブロック図

【図5】ＯＴＡマスタ３１の機能ブロック図

【図6】センタ１の記憶部１６に記憶されるデータの一例を示すメモリマップ

【図7】キャンペーン定義データ１０３のデータ構成の一例

【図8】キャンペーン内容１２２のデータ構成の一例

【図9】パッケージデータ１０６のデータ構成の一例

【図10】不具合データ１０７のデータ構成の一例

【図11】適用回避対象データ１０８のデータ構成の一例

【図12】ＯＴＡマスタ３１の記憶部４７に記憶されるデータの一例を示すメモリマップ

【図13】第１の実施例に係る不具合登録処理の詳細を示すフローチャート

【図14】第１の実施例に係る更新制御処理の詳細を示すフローチャート

【図15】第１の実施例におけるＯＴＡマスタ制御処理の詳細を示すフローチャート

【図16】第２の実施例に係るキャンペーン定義データ１０３のデータ構成の一例

【図17】第２の実施例に係る不具合登録処理の詳細を示すフローチャート

【図18】第２の実施例に係る更新制御処理の詳細を示すフローチャート

【図19】第２の実施例に係るＯＴＡマスタ制御処理の詳細を示すフローチャート

【発明を実施するための形態】

【0010】

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

【0011】

（第１の実施例）
まず、第１の実施例について説明する。第１の実施例では、次のような処理が行われる。あるキャンペーンデータの配信開始後、当該キャンペーンデータに含まれる所定のパッケージデータ（以下、単にパッケージと呼ぶ）について不具合が見つかると、例えばＯＥＭメーカからＯＴＡセンタ（以下、単にセンタと呼ぶ）にその旨の連絡が行われる。センタでは、この不具合の情報が記憶される。そして、ＯＴＡマスタからセンタに対して、ソフトウェア更新の有無の問い合わせ（以下、更新問い合わせと呼ぶ）があった場合、更新があれば、１以上のパッケージが含まれるキャンペーンデータがセンタから配信される。この際に、当該不具合のあるパッケージ（以下、不具合パッケージと呼ぶ）の情報について、センタからＯＴＡマスタに伝えられる。ＯＴＡマスタは、当該情報に基づいて、不具合パッケージの適用を回避するようにして、所定のキャンペーンデータに含まれる各パッケージの適用を実行する。

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

制御部４９は、通信部４８を介してセンタ１と通信を行い、ソフトウェア更新処理に関する各種の制御を実行する。具体的には、制御部４９は、更新の有無の問い合わせを行い、ある場合はキャンペーンに係るデータをダウンロードする。また、不具合パッケージの有無の問い合わせもセンタ１に対して行い、その回答内容に応じて、不具合パッケージのみ適用を回避しながら更新処理を実行する。

【0026】

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

【0027】

［センタ１で用いられるデータについて］
まず、センタ１の処理で用いられるデータについて説明する。図６は、センタ１の記憶部１６に記憶されるデータの一例を示すメモリマップである。記憶部１６には、更新制御プログラム１０１、車両データベース１０２、キャンペーン定義データ１０３、キャンペーンデータ１０４、不具合データ１０７、適用回避対象データ１０８等が記憶される。また、図示は省略するが、その他、ＯＴＡサービスを実現するための各種プログラムやデータも記憶部１６に記憶される。

【0028】

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

【0029】

車両データベース１０２は、センタ１で管理する車両３のデータベースであり、具体的にはＯＴＡサービスの提供対象となる車両３に関する情報を登録したデータベースである。図示は省略するが、車両データベース１０２には、個々の車両３を識別するための車両識別番号（ＶＩＮ）や、更新履歴を示すデータ等が含まれている。

【0030】

キャンペーン定義データ１０３は、上述したキャンペーンの内容に関して定義したデータである。図７は、キャンペーン定義データ１０３のデータ構成の一例である。キャンペーン定義データ１０３は、キャンペーンＩＤ１２１、キャンペーン内容１２２、適用対象データ１２３の項目を少なくとも含むテーブル形式のデータである。キャンペーンＩＤ１２１は、上述したようなキャンペーンを一意に識別するためのＩＤである。キャンペーン内容１２２は、所定のキャンペーン（に対応するキャンペーンデータ１０４）に含まれるパッケージに関するデータである。例えば、キャンペーン内容１２２は、図８に示すようなデータ構成を有する。図８では、キャンペーン内容１２２は、パッケージＩＤ１３１およびパッケージ内容１３２という項目を含んでいる。パッケージＩＤ１３１は、各パッケージを識別するためのＩＤである。パッケージ内容１３２は、そのパッケージに含まれている更新ソフトウェアを特定するための更新ソフトウェアＩＤ１３３が１以上定義されているデータである。

【0031】

図７に戻り、適用対象データ１２３は、所定のキャンペーンが適用される対象について定義したデータである。例えば、適用対象データ１２３には、そのキャンペーンを適用すべき車種等の情報が定義される。

【0032】

図６に戻り、次に、キャンペーンデータ１０４は、上記キャンペーン定義データ１０３の定義内容に基づいて生成されるデータであり、キャンペーンとしてＯＴＡマスタ３１に配信されるデータである。図６では、説明の便宜上、キャンペーンデータ１０４を１つだけ例示しているが、キャンペーンの数に応じて複数のキャンペーンデータ１０４が記憶部１６に記憶され得る。１つのキャンペーンデータ１０４には、上記キャンペーン定義データ１０３の定義内容に従って、キャンペーンＩＤ１０５と、１以上のパッケージデータ１０６が含まれる。キャンペーンＩＤ１０５は、上記キャンペーン定義データ１０３のキャンペーンＩＤ１２１に対応するＩＤである。パッケージデータ１０６は、そのキャンペーンに含まれる上記パッケージの具体的なデータである。図９に、当該パッケージデータのデータ構成の一例を示す。各パッケージデータ１０６には、パッケージＩＤ１４１と、１以上の上記更新ソフトウェア１４２が含まれる。パッケージＩＤ１４１は、上記キャンペーン内容１２２のパッケージＩＤ１３１に対応するＩＤである。また、図示は省略するが、各更新ソフトウェア１４２には、上記キャンペーン内容１２２の更新ソフトウェアＩＤ１３３に対応する更新ソフトウェアＩＤと、ターゲットＥＣＵの更新ソフトウェアの本体となるデータが含まれている。

【0033】

図６に戻り、次に、不具合データ１０７は、上記不具合パッケージに関するデータである。例えば、不具合データ１０７は、ＯＥＭメーカから不具合パッケージの連絡を受けたことに応じてその内容が追加される。図１０は、当該不具合データ１０７のデータ構成の一例である。不具合データ１０７には、不具合パッケージを特定するための情報である不具合パッケージＩＤ１８１が記憶されている。

【0034】

適用回避対象データ１０８は、上記不具合データ１０７に基づいて生成され得るデータであり、キャンペーン単位で、更新の適用を回避すべき対象である不具合パッケージを特定するためのデータである。図１１は、当該適用回避対象データ１０８のデータ構成の一例を示す図である。適用回避対象データ１０８は、キャンペーンＩＤ１５１、および対象パッケージ１５２を少なくとも含むテーブル形式のデータである。キャンペーンＩＤ１５１はキャンペーンデータ１０４を特定するためのＩＤである。対象パッケージ１５２は、所定のキャンペーンデータ１０４に関して、不具合パッケージを特定するための情報（上記不具合パッケージＩＤ１８１）を示すデータである。また、適用を回避すべき不具合パッケージが複数ある場合は、これらを個々に特定するため、複数のパッケージそれぞれの情報について定義される。

【0035】

一部回避指示データ１０９は、所定の不具合パッケージの適用回避をＯＴＡマスタ３１に指示するためのデータである。当該一部回避指示データ１０９には、不具合パッケージを特定する情報（上記不具合パッケージＩＤ１８１）が含まれている。また、一部回避指示データ１０９は、個々のＯＴＡマスタ３１に送信されるものであるため、記憶部１６には、個々のＯＴＡマスタ３１に応じた複数の一部回避指示データ１０９が（一時的に）記憶され得る。

【0036】

［ＯＴＡマスタ３１で用いられるデータについて］
次に、ＯＴＡマスタ３１で用いられるデータについて説明する。図１２は、ＯＴＡマスタ３１の記憶部４７に記憶されるデータの一例を示すメモリマップである。ＯＴＡマスタ３１の記憶部４７には、更新制御プログラム１５１、ダウンロードデータ１６２が少なくとも記憶されている。その他、図示は省略するが、ＯＴＡサービスを実現するための各種プログラムやデータも記憶部４７に記憶される。

【0037】

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

【0038】

ダウンロードデータ１６２は、センタ１から配信された所定のキャンペーンデータ１０４を（一時的に）記憶したデータである。ＯＴＡマスタ３１は、当該ダウンロードデータ１６２に基づいて更新処理を実行する。

【0039】

その他、図示は省略するが、記憶部４７には、上記センタ１から送信された一部回避指示データ１０９等も記憶される。

【0040】

［第１実施例の処理フロー］
次に、第１の実施例の処理の流れについて説明する。まず、センタ１で実行される処理について説明し、その後、ＯＴＡマスタ３１で実行される処理について説明する。

【0041】

図１３は、センタ１で実行される不具合登録処理の詳細を示すフローチャートである。当該処理は、センタ１において、例えば所定のタイミングで繰り返し実行され得る。また、本実施例では、所定のパッケージに不具合が見つかった場合、そのパッケージの開発元であるＯＥＭのサーバから、当該不具合に関する情報がサーバ間通信でセンタ１に送信されてくる場合を例示する。図１３において、まず、ステップＳ１で、制御部１８は、所定のパッケージに関して新たな不具合が発見されたか否かを判定する。本実施例では、上記のようにＯＥＭのサーバから不具合に関する情報を受信したか否かで判定する。受信していた場合、制御部１８は、新たな不具合が見つかったと判定する。当該判定の結果、新たな不具合が見つかった場合は（ステップＳ１でＹＥＳ）、ステップＳ２で、制御部１８は、上記受信した情報に基づき、不具合データ１０７の内容を更新する。具体的には、制御部１８は、新たな不具合パッケージを特定する不具合パッケージＩＤ１８１を不具合データ１０７に登録する。更に、制御部１８は、キャンペーン定義データ１０３を参照して、新たに見つかった不具合パッケージを含むキャンペーンＩＤ１２１を抽出する。そして、当該抽出したキャンペーンＩＤ１２１と不具合データ１０７の内容に基づき、適用回避対象データ１０８の内容を更新する。すなわち、制御部１８は、抽出したキャンペーンＩＤ１２１を適用回避対象データ１０８のキャンペーンＩＤ１５１とし、新たに見つかった不具合パッケージＩＤ１８１を対象パッケージ１５２としたデータを適用回避対象データ１０８に追加する。その後、制御部１８は、当該不具合登録処理を終了する。

【0042】

一方、上記ステップＳ１の判定の結果、新たな不具合が見つかっていない場合は（ステップＳ１でＮＯ）、制御部１８は、上記ステップＳ２の処理をスキップして、当該不具合登録処理を終了する。

【0043】

なお、上記不具合登録処理に関して、本実施例では所定のＯＥＭサーバからセンタ１に不具合情報が送信される例を挙げた。これに限らず、他の実施例では、オペレータ等の手操作で上記不具合データ１０７およひ適用回避対象データ１０８の内容を更新するような処理としてもよい。

【0044】

次に、図１４は、センタ１で実行される更新制御処理の詳細を示すフローチャートである。図１４において、まず、ステップＳ１１で、制御部１８は、所定のＯＴＡマスタ３１から更新問い合わせを受信したか否かを判定する。受信していない場合は（ステップＳ１１でＮＯ）、制御部１８は、ステップＳ１１の処理を繰り返すことで、更新問い合わせの待ち受けを継続する。一方、更新問い合わせを受信した場合は（ステップＳ１１でＹＥＳ）、ステップＳ１２で、制御部１８は、更新問い合わせの送信元の車両３（以下、更新問い合わせ元車両）に関して、更新があるか否かを判定する、具体的には、制御部１８は、配信可能なキャンペーンデータ１０４があるか否かを、車両データベース１０２およびキャンペーン定義データ１０３に基づいて判定する。例えば、制御部１８は、当該更新問い合わせ元車両の更新履歴に基づいて、更新の有無を判定する。当該判定の結果、更新が無い、すなわち、配信可能なキャンペーンデータ１０４が無い場合は（ステップＳ１２でＮＯ）、ステップＳ１４で、制御部１８は、更新は無い旨の通知を更新問い合わせ元車両のＯＴＡマスタ３１に送信する。その後、制御部１８は、上記ステップＳ１１に戻り、処理を繰り返す。

【0045】

一方、ステップＳ１２の判定の結果、配信可能なキャンペーンデータ１０４がある場合は（ステップＳ１２でＹＥＳ）、ステップＳ１３で、制御部１８は、当該キャンペーンデータ１０４を更新問い合わせ元車両のＯＴＡマスタ３１に配信する。

【0046】

次に、ステップＳ１５で、上記キャンペーンデータ１０４を配信したＯＴＡマスタ３１から、適用回避対象の有無の問い合わせ（以下、適用回避問い合わせ）を受信したか否かを判定する。当該適用回避問い合わせは、配信されたキャンペーンデータ１０４について、適用を回避すべき不具合パッケージがあるか否かを問い合わせる旨の内容である。当該適用回避問い合わせには、問い合わせ対象となるキャンペーンＩＤ１５１等の情報が含まれていてもよい。当該判定の結果、適用回避問い合わせを受信していない場合は（ステップＳ１５でＮＯ）、制御部１８は、当該適用回避問い合わせの受信の待ち受けを継続する。一方、適用回避問い合わせを受信した場合は（ステップＳ１５でＹＥＳ）、ステップＳ１６で、制御部１８は、適用回避対象データ１０８を参照して、当該適用回避問い合わせに係るキャンペーンＩＤ１５１に関して、不具合パッケージがあるか否かを判定する。当該判定の結果、不具合パッケージが無い場合は（ステップＳ１６でＮＯ）、ステップＳ１８で、制御部１８は、不具合パッケージは無い旨の通知を、適用回避問い合わせの送信元の車両３（以下、回避問い合わせ元車両）のＯＴＡマスタ３１に送信する。その後、制御部１８は、上記ステップＳ１１に戻り、処理を繰り返す。

【0047】

一方、ステップＳ１６の判定の結果、不具合パッケージがある場合は（ステップＳ１６でＹＥＳ）、ステップＳ１７で、制御部１８は、適用回避対象データ１０８に基づき、当該不具合パッケージを示す情報が含まれる一部回避指示データ１０９を生成する。そして、制御部１８は、当該一部回避指示データ１０９を回避問い合わせ元車両のＯＴＡマスタ３１に送信する。その後、制御部１８は、上記ステップＳ１１に戻り、処理を繰り返す。

【0048】

以上で、センタ１で実行される処理の説明を終了する。

【0049】

次に、ＯＴＡマスタ３１で実行される処理について説明する。図１５は、ＯＴＡマスタ３１で実行されるＯＴＡマスタ制御処理の詳細を示すフローチャートである。当該処理は、例えば２週間に１回の頻度で、イグニッションオンのタイミングで実行される処理である。図１５において、まず、ステップＳ３１で、ＯＴＡマスタ３１の制御部４９は、更新問い合わせを生成してセンタ１に送信する。

【0050】

次に、ステップＳ３２で、制御部４９は、センタ１から送信されてきた、当該更新問い合わせに対する回答データを受信し、更新があるか否か、すなわち、配信されるキャンペーンデータ１０４があるか否かを判定する。当該判定の結果、更新が無い場合は（ステップＳ３２でＮＯ）、制御部４９は、当該ＯＴＡマスタ制御処理を終了する。

【0051】

一方、更新がある場合は（ステップＳ３２でＹＥＳ）、ステップＳ３３で、制御部４９は、キャンペーンデータ１０４をセンタ１から受信（ダウンロード）する。当該キャンペーンデータ１０４の受信が終われば、次に、ステップＳ３４で、制御部４９は、上記適用回避問い合わせを生成する。そして、制御部４９は、当該適用回避問い合わせをセンタ１に送信する。

【0052】

次に、ステップＳ３５で、制御部４９は、センタ１から一部回避指示データ１０９を受信したか否かを判定する。当該判定の結果、一部回避指示データ１０９を受信していない場合は（この場合は、不具合パッケージは無い旨をセンタ１から受信していることになる）、ステップＳ３７で、制御部４９は、上記ステップＳ３３で受信したキャンペーンデータ１０４に含まれる全てのパッケージを適用する更新処理を実行する。そして、当該更新処理が完了すれば、制御部４９は、ＯＴＡマスタ制御処理を終了する。

【0053】

一方、ステップＳ３５の判定の結果、一部回避指示データ１０９を受信していた場合は（ステップＳ３５でＹＥＳ）、ステップＳ３６で、制御部４９は、受信した一部回避指示データ１０９を記憶部４７に記憶する。次に、制御部４９は、一部回避指示データ１０９において指定されている不具合パッケージについては適用しないようにして、その他のパッケージを適用するための更新処理を実行する。例えば、制御部４９は、一部回避指示データ１０９に含まれている不具合パッケージＩＤ１８１に基づいて、ダウンロードデータ１６２の中から適用回避すべきパッケージを識別し、当該パッケージを適用する処理をスキップする制御を行ってもよい。そして、当該更新処理が完了すれば、制御部４９は、ＯＴＡマスタ制御処理を終了する。

【0054】

以上で、ＯＴＡマスタ３１で実行される処理の説明を終了する。

【0055】

このように、第１の実施例では、不具合パッケージの情報をセンタ１に記憶しておき、所定のキャンペーンに係る更新を適用する際に、不具合パッケージの情報をＯＴＡマスタ３１に送信している。そして、ＯＴＡマスタ３１では、この情報に基づいて不具合パッケージについては適用しないようにして更新処理を実行している。これにより、所定のキャンペーンデータ１０４に、不具合はないが重要度の高い更新ソフトウェアを含むパッケージと、不具合パッケージとの双方が含まれているような場合であっても、キャンペーンデータ１０４全体の適用を中止することなく、当該重要度の高い更新ソフトウェアを含むパッケージを適用することが可能となる。

【0056】

（第２の実施例）
次に、第２の実施例について説明する。上記第１の実施例では、単純に、不具合パッケージだけ適用しないような処理が行われていた。これに対して、第２の実施例では、あるキャンペーンデータ１０４に含まれているパッケージ同士の関連度の高さを考慮して、適用回避の判定を行う。例えば、あるキャンペーンデータ１０４について、パッケージＡとパッケージＢとパッケージＣとが含まれているとする。そして、このうちパッケージＢに関して不具合が見つかった場合を想定する。更に、このような場合において、パッケージＡとパッケージＢとの関連度が高い場合を想定する。関連度が高いとは、例えば、パッケージＡに係る機能を実現するために、パッケージＢに含まれるソフトウェアの一部の機能を利用したり、パッケージＢに係るソフトウェアの処理結果を利用したりする場合等、パッケージ同士の依存関係がある程度高いといえるような場合である。以下、関連度の高いパッケージ同士の関係を「密結合」と呼び、関連度が低い場合の関係を「疎結合」と呼ぶ。また、本実施例では、原則的には各パッケージ同士は「疎結合」であるが、例外的に「密結合」となるパッケージが存在する、というような場合を想定する。

【0057】

上記のように、パッケージＡとパッケージＢとが「密結合」の場合、第１の実施例では、不具合パッケージであるパッケージＢの適用だけ回避することになる。この場合、パッケージＡのほうは更新されることになるが、「密結合」であるパッケージＢの更新はなされていない状態となる。そのため、パッケージＢの機能を利用あるいはこの機能に依存する（更新後の）パッケージＡで想定しているパフォーマンスが発揮されない可能性がある。また、パッケージＢの不具合が修正された結果、パッケージＡのほうにも更に修正が必要となるケースもあり得る。この場合、再度パッケージＡの更新が必要となり、更新の２度手間にもなり得る。つまり、「密結合」にあるパッケージの一方のみが更新適用されたとしても、それ単体では十分に機能しなかったり、再度の更新が必要になる等で、更新処理の効率性の観点から、改善の余地があるといえる。そこで、第２の実施例では、あるキャンペーンデータ１０４に含まれる不具合パッケージとその他のパッケージとの関連度の高さを判定する。そして、不具合パッケージが他のパッケージに対して「疎結合」の場合だけ、当該不具合パッケージの適用を回避するという処理を行う。例えば、上記の例でパッケージＢが不具合パッケージである場合、パッケージＡおよびＣのいずれとも「疎結合」であれば、パッケージＢのみ適用を回避する処理が行われる。一方、パッケージＢがパッケージＡと「密結合」である場合は、キャンペーン全体の適用を行わない（適用を中止する）、という処理を行う。

【0058】

以下、第２の実施例の詳細について説明する。まず、第２の実施例におけるハードウェア構成（センタ１およびＯＴＡマスタ３１）については、基本的には、上記第１の実施例と同様のため、詳細な説明は割愛する。

【0059】

次に、第２の実施例において使用するデータについて説明する。基本的には、第２の実施例でも第１の実施例と同様のデータが用いられるが、センタ１の記憶部１６に記憶されるキャンペーン定義データ１０３のデータ構成に一部相違がある。具体的には、図１６に示すように、関連度データ１２４がキャンペーン定義データ１０３に含まれる構成となる。

【0060】

関連度データ１２４は、所定のキャンペーンデータ１０４に含まれるパッケージのうち、「密結合」であるパッケージを定義したデータである。具体的には、「密結合」の関係にあるパッケージのパッケージＩＤ１４１が定義される。また、「密結合」のパッケージの組み合わせが複数ある場合は、それぞれの組み合わせが識別可能なように定義される。

【0061】

次に、第２の実施例に係る処理の流れについて説明する。図１７は、第２の実施例に係る不具合登録処理の詳細を示すフローチャートである。図１７において、まず、ステップＳ５１で、制御部１８は、所定のパッケージに関して新たな不具合が発見されたか否かを判定する。この処理は、上記ステップＳ１と同様の処理である。当該判定の結果、新たな不具合が見つかっていない場合は（ステップＳ５１でＮＯ）、制御部１８は、不具合登録処理を終了する。一方、新たな不具合が見つかった場合は（ステップＳ５１でＹＥＳ）、ステップＳ５２で、制御部１８は、新たに見つかった不具合パッケージの情報を不具合データ１０７に追加することで、不具合データ１０７を更新する。

【0062】

次に、ステップＳ５３で、制御部１８は、キャンペーン定義データ１０３を参照し、不具合パッケージを含むキャンペーンＩＤ１２１について抽出する。

【0063】

次に、ステップＳ５４で、制御部１８は、抽出したキャンペーンＩＤ１２１に対応するキャンペーンデータ１０４について、不具合パッケージが他のパッケージと「疎結合」であるか否かを、上記関連度データ１２４に基づいて判定する。当該判定の結果、不具合パッケージが「疎結合」である場合は（ステップＳ５４でＹＥＳ）、制御部１８は、当該不具合パッケージを含むキャンペーンデータ１０４に関して、この不具合パッケージのみを適用回避対象に指定した内容のデータを適用回避対象データ１０８に追加する。

【0064】

一方、不具合パッケージが「疎結合」ではない、すなわち、いずれかのパッケージと「密結合」である場合は（ステップＳ５４でＮＯ）、ステップＳ５６で、制御部１８は、不具合パッケージを適用回避対象として指定すると共に、当該不具合パッケージが「密結合」であることを示す内容のデータを、上記適用回避対象データ１０８に追加する。当該データは、例えば「密結合」か「疎結合」かを２値で示すフラグ等であってもよい。以上で、第２の実施例に係る不具合登録処理は終了する。

【0065】

なお、上記ステップＳ５５およびＳ５６の処理については、上記のような処理に限らず、「疎結合」の場合は、指定された不具合パッケージの適用を回避する旨の指示内容を適用回避対象データ１０８とし、「密結合」の場合は、キャンペーン全体の適用の中止する指示内容を適用回避対象データ１０８として記憶するような処理としてもよい。そして、この場合、ＯＴＡマスタ３１では、適用回避対象データ１０８に含まれる指示に基づいて更新処理が制御されてもよい。

【0066】

また、上記第１の実施例と同様に、第２の実施例においても、オペレータなどの手操作で上記不具合データ１０７およひ適用回避対象データ１０８の内容を更新するような処理としてもよい。

【0067】

次に、第２の実施例においてセンタ１で実行される更新制御処理について説明する。図１８は、第２の実施例に係る更新制御処理の詳細を示すフローチャートである。当該フローチャートにおいて、ステップＳ１１～Ｓ１８に係る処理は図１４を用いて上述した処理を同様であるため、ここでは説明は割愛し、主にこれら以外の処理（ステップＳ６１～Ｓ６２）について説明する。

【0068】

図１８のステップＳ１６の判定の結果、不具合パッケージがある場合は（ステップＳ１６でＹＥＳ）、ステップＳ６１で、制御部１８は、適用回避対象データ１０８を参照して、当該不具合パッケージが他のパッケージに対して「疎結合」であるか否かを判定する。具体的には、当該不具合パッケージが「密結合」であることを示す内容が適用回避対象データ１０８で示されている場合、制御部１８は、「疎結合」ではないと判定する。「密結合」であることを示す内容ではない場合は、制御部１８は、「疎結合」であると判定する。当該判定の結果、「疎結合」の場合は（ステップＳ６１でＹＥＳ）、制御部１８は、上記ステップＳ１７の処理を実行する（一部回避指示データ１０９の送信）。一方、「疎結合」ではない場合は（ステップＳ６１でＮＯ）、ステップＳ６２で、制御部１８は、キャンペーン全体の適用を中止するための適用中止指示をＯＴＡマスタ３１に送信する。

【0069】

次に、第２の実施例におけるＯＴＡマスタ制御処理について説明する。図１９は、第２の実施例に係るＯＴＡマスタ制御処理の詳細を示すフローチャートである。図１９において、ステップＳ３１～Ｓ３４、Ｓ３６～Ｓ３７の処理については、図１５を用いて上述した処理と同様であるため、ここでは説明を割愛し、主にその他の処理（ステップＳ７１～Ｓ７３）について説明する。

【0070】

図１９のステップＳ３４で適用回避問い合わせをセンタ１に送信した後、ステップＳ７１で、制御部４９は、センタ１から受信したデータに基づいて、不具合パッケージがあるか否かを判定する。具体的には、制御部４９は、センタ１から不具合パッケージは無い旨を受信したか否かを判定し、この旨を受信していれば、不具合パッケージは無いと判定する。一方、不具合パッケージは無い旨を受信していない場合は、制御部４９は、不具合パッケージがあると判定する。

【0071】

上記判定の結果、不具合パッケージが無い場合は（ステップＳ７１でＮＯ）、上記ステップＳ３７の処理に進み、制御部４９は、キャンペーンデータ１０４に含まれる全てのパッケージを適用する。一方、不具合パッケージがある場合は（ステップＳ７１でＹＥＳ）、ステップＳ７２で、制御部４９は、センタ１から受信した内容が一部回避指示か否かを判定する。当該判定の結果、一部回避指示である場合は（ステップＳ７２でＹＥＳ）、上記ステップＳ３６の処理に進み、制御部４９は、回避指示されている不具合パッケージだけ適用しないようにして更新処理を実行する。一方、一部回避指示では無い場合は（ステップＳ７２でＮＯ）、センタ１から、上記適用中止指示を受信していることになるため、ステップＳ７３で、制御部４９は、キャンペーン全体の適用を中止すための処理を実行する。例えば、制御部４９は、更新処理を中止し、上記ダウンロードデータ１６２を破棄する。

【0072】

以上で、第２の実施例に係る処理の詳細説明を終了する。

【0073】

このように、第２の実施例では、センタ１において、所定のキャンペーンに含まれるパッケージ同士の関連性を考慮して、適用回避対象データ１０８が生成される。そして、不具合パッケージがある場合、当該不具合パッケージが他のパッケージとは「疎結合」である場合に、その不具合パッケージの適用だけ回避するための一部回避指示データ１０９をＯＴＡマスタ３１に送信している。これにより、ＯＴＡマスタ３１では、ある不具合パッケージが「疎結合」である場合に、その不具合パッケージのみを適用回避し、その他のパッケージについては更新を適用するように更新処理を実行できる。また、不具合パッケージが「疎結合」ではない場合は、キャンペーン全体の適用を中止する制御を行っている。これにより、効率的な更新処理を実行することができる。

【0074】

［変形例］
なお、上記第２の実施例では、不具合パッケージが他のパッケージと「密結合」の場合は、キャンペーン全体の適用を中止していた。他の実施例では、このような場合、不具合パッケージおよびこれと「密結合」の関係であるパッケージについてのみ適用を回避するような制御を行ってもよい。例えば、あるキャンペーンにパッケージＡ、Ｂ、Ｃが含まれており、パッケージＡとＢが「密結合」であるとする。そして、パッケージＢに不具合が見つかった場合を想定する。この場合に、キャンペーン全体の適用を中止するのではなく、パッケージＡおよびＢの適用だけ回避し、パッケージＣについては更新を適用するような制御を行ってもよい。

【0075】

また、上記各実施例では、適用回避問い合わせを、キャンペーンデータ１０４を受信した後に行う例を挙げた。これに限らず、他の実施例では、キャンペーンデータ１０４の受信を開始する前に適用回避問い合わせを行うようにしてもよい。更にこの場合、適用回避対象のパッケージに係るパッケージデータ１０６についてはセンタ１から送信しないような制御を行ってもよい。これにより、通信量を削減し、効率的な通信を行うことも可能となる。

【0076】

また、上記適用回避指示データに関しては、ＯＴＡサービスで用いるネットワークとは別のネットワークで通知するような構成としてもよい。例えばＯＴＡサービスをインターネット網で利用し、適用回避指示データについてはキャリア網のＳＭＳやＶ２Ｘ等で通知するような構成としてもよい。そして、ＯＴＡマスタ３１では、キャンペーンを適用する際にこのような適用回避指示データを受信していれば、当該適用回避指示データに基づいて不具合パッケージの適用を回避するように更新処理を行ってもよい。

【0077】

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

【産業上の利用可能性】

【0078】

本開示技術は、車両が備えるＯＴＡマスタとネットワークを介して通信可能なセンタに利用できる。

【符号の説明】

【0079】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】