特許 7548069 センタ、更新制御方法、更新制御プログラム、ＯＴＡマスタ、ソフトウェア更新システム

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

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

(11)【特許番号】

(24)【登録日】2024-09-02

(45)【発行日】2024-09-10

(54)【発明の名称】センタ、更新制御方法、更新制御プログラム、ＯＴＡマスタ、ソフトウェア更新システム

(51)【国際特許分類】

   G06F 8/65 20180101AFI20240903BHJP

   G06F 11/07 20060101ALI20240903BHJP

   B60R 16/02 20060101ALI20240903BHJP

【ＦＩ】

G06F8/65

G06F11/07 166

B60R16/02 660U

【請求項の数】 5

(21)【出願番号】P 2021035142

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

(65)【公開番号】P2022135377

(43)【公開日】2022-09-15

【審査請求日】2023-03-23

(73)【特許権者】

【識別番号】000003207

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

(74)【代理人】

【識別番号】110001276

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

(72)【発明者】

【氏名】長光 翔一

【審査官】田中 幸雄

(56)【参考文献】

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

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

Ｇ０６Ｆ ８／６５

Ｇ０６Ｆ １１／０７

Ｂ６０Ｒ １６／０２

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

【請求項1】

車両が備えるＯＴＡマスタとネットワークを介して通信可能であり、かつ、故障が発生した車両から送信される故障情報コードと当該車両を特定する情報とを対応づけた故障発生情報を記憶する故障発生情報記憶部を少なくとも備える故障管理サーバとネットワークを介して通信可能なセンタであって、
前記故障管理サーバから送信される前記故障発生情報を受信する故障情報受信部と、
前記故障管理サーバから受信した前記故障発生情報を記憶する故障情報記憶部と、
前記ＯＴＡマスタから、電子制御装置のソフトウェアの更新有無の問い合わせを受信する問い合わせ受信部と、
前記問い合わせを受信したとき、前記故障発生情報に基づいて、当該問い合わせの送信元である前記車両が故障状態であるか否かを判定する故障状態判定部と、
前記問い合わせの送信元である前記車両が故障状態であると判定された場合、当該車両にかかる前記ソフトウェアの更新処理の実行を制限する更新制限部と、
を備え、
前記故障管理サーバに新たな故障発生情報が登録された場合に、当該故障管理サーバから前記故障発生情報が前記センタに送信される、センタ。

【請求項2】

前記センタは、前記問い合わせの送信元の車両が故障していると判定された場合、故障していることを示す情報を当該車両に送信する、請求項１に記載のセンタ。

【請求項3】

プロセッサと、メモリと、車両が備えるＯＴＡマスタとネットワークを介して通信可能であり、かつ、故障が発生した車両から送信される故障情報コードと当該車両を特定する情報とを対応づけた故障発生情報を記憶する故障発生情報記憶部を少なくとも備える故障管理サーバとネットワークを介して通信可能なセンタのコンピュータが実行する更新制御方法であって、
前記故障管理サーバから送信される故障発生情報を受信する故障情報受信ステップと、
前記故障管理サーバから受信した故障発生情報を記憶する故障情報記憶ステップと、
前記ＯＴＡマスタから、電子制御装置のソフトウェアの更新有無の問い合わせを受信する問い合わせ受信ステップと、
前記問い合わせを受信したとき、前記故障発生情報に基づいて、当該問い合わせの送信元である車両が故障状態であるか否かを判定する故障状態判定ステップと、
前記問い合わせの送信元の車両が故障状態であると判定された場合、当該車両にかかる前記ソフトウェアの更新処理の実行を制限する更新制限ステップと、
を備え、
前記故障管理サーバに新たな故障発生情報が登録された場合に、当該故障管理サーバから前記故障発生情報が前記センタに送信される、更新制御方法。

【請求項4】

プロセッサと、メモリと、車両が備えるＯＴＡマスタとネットワークを介して通信可能であり、かつ、故障が発生した車両から送信される故障情報コードと当該車両を特定する情報とを対応づけた故障発生情報を記憶する故障発生情報記憶部を少なくとも備える故障管理サーバとネットワークを介して通信可能なセンタのコンピュータに実行させる更新制御プログラムであって、
前記故障管理サーバから送信される故障発生情報を受信する故障情報受信ステップと、
前記故障管理サーバから受信した故障発生情報を記憶する故障情報記憶ステップと、
前記ＯＴＡマスタから、電子制御装置のソフトウェアの更新有無の問い合わせを受信する問い合わせ受信ステップと、
前記問い合わせを受信したとき、前記故障発生情報に基づいて、当該問い合わせの送信元である車両が故障状態であるか否かを判定する故障状態判定ステップと、
前記問い合わせの送信元の車両が故障状態であると判定された場合、当該車両にかかる前記ソフトウェアの更新処理の実行を制限する更新制限ステップとを前記コンピュータに
実行させ、
前記故障管理サーバに新たな故障発生情報が登録された場合に、当該故障管理サーバから前記故障発生情報が前記センタに送信される、更新制御プログラム。

【請求項5】

ＯＴＡマスタを備える車両と、
前記ＯＴＡマスタとネットワークを介して通信可能なセンタと、
前記センタおよびＯＴＡマスタのそれぞれとネットワークを介して通信可能な故障情報管理サーバとを備えるソフトウェア更新システムであって、
前記車両は、当該車両に発生した故障を検知し、当該車両を特定する情報および当該故障に関する故障情報コードを少なくとも含む故障発生情報を故障管理サーバに送信する故障検知部を備え、
前記故障管理サーバは、
前記車両から送信される故障発生情報を受信する第１受信部と、
前記故障発生情報を前記センタに送信する故障情報送信部とを備え、
前記センタは、
前記故障管理サーバから送信されてきた前記故障発生情報を記憶する故障情報記憶部と、
前記ＯＴＡマスタからソフトウェア更新の有無の問い合わせを受信する問い合わせ受信部と、
前記問い合わせを受信したとき、前記故障情報記憶部に記憶されている前記故障発生情報に基づいて、当該問い合わせのあった車両が故障状態であるか否かを判定する故障状態判定部と、
故障していると判定された場合、前記ソフトウェアの更新処理の実行を制限する更新処理制限部とを備え、
前記故障管理サーバに新たな故障発生情報が登録された場合に、当該故障管理サーバから前記故障発生情報が前記センタに送信される、ソフトウェア更新システム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

上記ＯＴＡサービスにおいては、車両が故障している状態（故障状態）であるにも関わらず、ソフトウェアを更新する虞があった。故障状態の車両に対してソフトウェア更新を行うと、適切な更新ができない可能性があり、車両が故障状態のときは、ソフトウェア更新は行わないようにすることが望ましい。ここで、ＯＴＡサービスによるソフトウェア更新の実行に際しては、車両とセンタとでコネクションを確立するところ、常に車両側からコネクションを開始する、つまり、車両側が接続開始のトリガとなるような設計となっている。そのため、車両からのアクションがない限り、車両とのコネクションが確立できず、センタは車両の故障状態が把握することできない。

【0005】

上記の点に鑑みて、コネクションの確立後、ソフトウェア更新のためにセンタから車両に故障情報をその都度問い合わせるようにすることも考えられる。しかし、この場合、故障情報の問い合わせの分、センタおよび車両間の通信量が増えてしまい、通信コストが大きくなってしまうという問題もある。

【0006】

ところで、車両で故障が発生した場合、通常は、車両はその故障情報を故障管理サーバに送信する。故障管理サーバとは、車両の故障状態を（ほぼリアルタイムに）把握・管理するための故障管理システムが有するサーバである。仮に、上記のようにソフトウェア更新のためにセンタから車両に故障情報をその都度問い合わせるようにした場合、車両側からすれば、すでに故障管理サーバに報告済みのものを再度センタに伝えることになり、いわば二度手間となってしまう。そのため、このような観点でも余計な通信コストがかかるとも言える。

【0007】

本開示は、上記課題を鑑みてなされたものであり、車両に故障情報を問い合わせることなく、車両故障状態に応じたソフトウェア更新の制御が可能なセンタを提供することである。

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

【0008】

上記課題を解決するために、本開示技術の一態様は、車両が備えるＯＴＡマスタとネットワークを介して通信可能であり、かつ、故障が発生した車両から送信される故障情報コードと当該車両を特定する情報とを対応づけた故障発生情報を記憶する故障発生情報記憶部を少なくとも備える故障管理サーバとネットワークを介して通信可能なセンタである。センタは、故障管理サーバから送信される故障発生情報を受信する故障情報受信部と、故障管理サーバから受信した故障発生情報を記憶する故障情報記憶部と、ＯＴＡマスタから、電子制御装置のソフトウェアの更新有無の問い合わせを受信する問い合わせ受信部と、当該問い合わせを受信したとき、故障発生情報に基づいて、当該問い合わせの送信元である車両が故障状態であるか否かを判定する故障状態判定部と、問い合わせの送信元の車両が故障状態であると判定された場合、当該車両にかかるソフトウェアの更新処理の実行を制限する更新制限部とを備える。

【発明の効果】

【0009】

本開示のセンタによれば、センタは、ソフトウェア更新のために車両に故障情報を問い合わせることなく、車両故障状態に応じたソフトウェア更新制御ができる。

【図面の簡単な説明】

【0010】

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

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

【図3】故障管理サーバ２の概略構成を示すブロック図

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

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

【図6】故障管理サーバ２の機能ブロック図

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

【図8】故障管理サーバ２の記憶部２６に記憶されるデータの一例を示すメモリマップ

【図9】故障状況データ５２のデータ構成の一例

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

【図11】故障状況データ６２のデータ構成の一例

【図12】故障管理処理の詳細を示すフローチャート

【図13】故障情報更新処理の詳細を示すフローチャート

【図14】更新制御処理の詳細を示すフローチャート

【図15】ソフトウェア更新処理の詳細を示すフローチャート

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

【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】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】