JP2017228103A - 制御装置、プログラム配信方法、およびコンピュータプログラム - Google Patents

Abstract

【課題】配信期間中の通信状態を考慮して、更新プログラムをより確実に配信することができるプログラム更新システムを提供する。【解決手段】車両に搭載された対象機器を制御する車載制御装置であるＥＣＵの更新プログラムの配信する際に、当該配信を制御する制御装置として機能するゲートウェイ１０においては、更新プログラムを無線通信により受信する車両の無線通信部に関する、ダウンロード開始前の判定基準時点における通信状態と（Ｓ１０５）、ダウンロード開始前の判定基準時後の所定時点からダウンロード完了までのダウンロード期間中における通信状態と（Ｓ１０７）、が判定され、双方が良好である場合に更新プログラムのダウンロードが開始される（Ｓ１０９）。【選択図】図６

Description

この発明は制御装置、プログラム配信方法、およびコンピュータプログラムに関し、特に、車載制御装置の更新プログラムの配信を制御する制御装置、プログラム配信方法、およびコンピュータプログラムに関する。

近年、自動車の技術分野においては、車両の高機能化が進行しており、多種多様な車載機器が車両に搭載されている。従って、車両には、各車載機器を制御するための制御装置である、所謂ＥＣＵ（Electronic Control Unit）が多数搭載されている。
ＥＣＵの種類には、例えば、アクセル、ブレーキ、ハンドルの操作に対してエンジンやブレーキ、ＥＰＳ（Electric Power Steering）等の制御を行う走行系に関わるもの、乗員によるスイッチ操作に応じて車内照明やヘッドライトの点灯／消灯と警報器の吹鳴等の制御を行うボディ系ＥＣＵ、運転席近傍に配設されるメータ類の動作を制御するメータ系ＥＣＵなどがある。

一般的にＥＣＵは、マイクロコンピュータ等の演算処理装置によって構成されており、ＲＯＭ（Read Only Memory）に記憶した制御プログラムを読み出して実行することにより、車載機器の制御が実現される。
ＥＣＵの制御プログラムは、車両の仕向け地やグレードなど応じて異なることがあり、制御プログラムのバージョンアップに対応して、旧バージョンの制御プログラムを新バージョンの制御プログラムに書き換える必要がある。

たとえば、特許文献１には、車載通信機などのゲートウェイが管理サーバから更新プログラムを受信し、受信した更新プログラム用いてＥＣＵが制御プログラムを旧バージョンから新バージョンに書き換えることにより、車両の各ＥＣＵに対するプログラム更新を無線通信によって遠隔で実行する技術が開示されている。

特開２００７−６５８５６号公報

特許文献１の開示によれば、制御プログラムを更新するための更新プログラムは、車両側からの要求に応じてサーバから該当する車両に搭載されたゲートウェイに向けて配信される。そのため、通信回線における通信状態が良好ではないタイミング、たとえば電波が遮断されていたり不安定であったりする状態において更新プログラムの配信要求に応じて更新プログラムが送信されると、該プログラムがうまく受信されない場合がある。

さらに、車両が移動体であることを考慮すると、更新プログラムの配信中に車両が移動することで、通信状態が悪くなる場合もある。その場合、たとえ送信開始時に通信状態が良好であっても、更新プログラムの配信が中断するなどして、該プログラムがうまく受信されない場合がある。

通信状態が悪化して更新プログラムの配信が中断されると、通信状態が回復してから再度配信が行われるために、結果として通信時間が長くなり、通信回線を逼迫すると共に、通信コストも増加してしまう。また、更新プログラムの伝送に要する電力も増大することになる。

本発明のある局面における目的は、配信期間中の通信状態を考慮して、更新プログラムの配信の確実性を向上させることである。

ある実施の形態に従うと、制御装置は車両に搭載された対象機器を制御する車載制御装置の更新プログラムのダウンロードを制御する制御装置であって、更新プログラムを無線通信により受信する車両の無線通信部に関する下記の第１および第２通信状態を判定する判定部と、第１および第２通信状態の双方が良好である場合に、更新プログラムのダウンロードを開始する処理部と、を備える。
第１通信状態：ダウンロード開始前の判定基準時点における通信状態
第２通信状態：ダウンロード開始前の判定基準時後の所定時点からダウンロード完了までのダウンロード期間中における通信状態

他の実施の形態に従うと、プログラム配信方法は車両に搭載された対象機器を制御する車載制御装置の更新プログラムの配信方法であって、更新プログラムを無線通信により受信する車両の無線通信部に関する上記の第１および第２通信状態を判定するステップと、第１および第２通信状態の双方が良好である場合に、更新プログラムのダウンロードを開始するステップと、を備える。

他の実施の形態に従うと、コンピュータプログラムは車両に搭載された対象機器を制御する車載制御装置の更新プログラムのダウンロードを制御する制御装置としてコンピュータを機能させるためのコンピュータプログラムであって、コンピュータを、更新プログラムを無線通信により受信する車両の無線通信部に関する上記の第１および第２通信状態を判定する判定部、および、第１および第２通信状態の双方が良好である場合に、更新プログラムのダウンロードを開始する処理部、として機能させる。

この発明によると、配信期間中の通信状態を考慮して、更新プログラムをより確実に配信することができる。

本発明の実施形態に係るプログラム更新システムの全体構成図である。 ゲートウェイの内部構成を示すブロック図である。 ＥＣＵの内部構成を示すブロック図である。 管理サーバの内部構成を示すブロック図である。 ＥＣＵの制御プログラムの更新の一例を示すシーケンス図である。 図５のステップＳ３のタイミング判定処理の流れの一例を表したフローチャートである。 ゲートウェイの機能構成の具体例を示したブロック図である。 タイミング判定処理を説明するための図である。

［実施の形態の説明］
本実施の形態には、少なくとも以下のものが含まれる。
すなわち、本実施の形態に含まれる制御装置は、車両に搭載された対象機器を制御する車載制御装置の更新プログラムのダウンロードを制御する制御装置であって、更新プログラムを無線通信により受信する車両の無線通信部に関する下記の第１および第２通信状態を判定する判定部と、第１および第２通信状態の双方が良好である場合に、更新プログラムのダウンロードを開始する処理部と、を備える。
第１通信状態：ダウンロード開始前の判定基準時点における通信状態
第２通信状態：ダウンロード開始前の判定基準時後の所定時点からダウンロード完了までのダウンロード期間中における通信状態
この構成によれば、処理部が上記第１および第２通信状態の双方が良好である場合に更新プログラムのダウンロードを開始するので、第１通信状態が良好なだけではダウンロードが開始されない。従って、ダウンロード期間中に通信状態が不良な地点を車両が通行することにより、更新プログラムを正常に受信できなくなるのを未然に防止できる。このため、更新プログラムの再送に伴う通信コストや消費電力の無駄を解消することができる。

好ましくは、制御装置は通信状態が不良な不感エリアを含むエリアマップを取得する取得部をさらに備え、判定部は、ダウンロード期間中に車両が通過する予定位置が、不感エリアに含まれるか否かにより、第２通信状態の良否を判定する。
この場合、判定部は、ダウンロード期間中に車両が通過する予定位置が不感エリアに含まれるか否かにより、第２通信状態の良否を判定することができる。

好ましくは、取得部は、車両に搭載または非搭載のナビゲーション装置が生成した車両の走行経路をさらに取得する。この場合、判定部は、取得された車両の走行経路に基づいて予定位置を特定することができる。

好ましくは、取得部は、車両の過去の走行履歴をさらに取得する。この場合、判定部は、取得された走行履歴から予測される予測経路に基づいて予定位置を特定することができる。

好ましくは、判定部は、判定基準時点における無線通信部の受信強度の測定値に基づいて、第１通信状態の良否を判定する。この場合、第１通信状態の良否の判定に無線通信部の受信強度の測定値が用いられるので、当該良否判定を正確に行うことができる。

好ましくは、判定部は、判定基準時点における車両位置が、不感エリアに含まれるか否かにより、第１通信状態の良否を判定する。この場合、第１通信状態の良否判定に不感エリアが用いられるので、無線通信部の受信強度を測定する必要がなく、当該良否判定を簡便に行うことができる。

本実施の形態に含まれるプログラム配信方法は車両に搭載された対象機器を制御する車載制御装置の更新プログラムの配信方法であって、更新プログラムを無線通信により受信する車両の無線通信部に関する上記の第１および第２通信状態を判定するステップと、第１および第２通信状態の双方が良好である場合に、更新プログラムのダウンロードを開始するステップと、を備える。
この構成によれば、上記第１および第２通信状態の双方が良好である場合に更新プログラムのダウンロードを開始するので、第１通信状態が良好なだけではダウンロードが開始されない。従って、ダウンロード期間中に通信状態が不良な地点を車両が通行することにより、更新プログラムを正常に受信できなくなるのを未然に防止できる。このため、更新プログラムの再送に伴う通信コストや消費電力の無駄を解消することができる。

本実施の形態に含まれるコンピュータプログラムは車両に搭載された対象機器を制御する車載制御装置の更新プログラムのダウンロードを制御する制御装置としてコンピュータを機能させるためのコンピュータプログラムであって、コンピュータを、更新プログラムを無線通信により受信する車両の無線通信部に関する上記の第１および第２通信状態を判定する判定部、および、第１および第２通信状態の双方が良好である場合に、更新プログラムのダウンロードを開始する処理部、として機能させる。
この構成によれば、処理部が上記第１および第２通信状態の双方が良好である場合に更新プログラムのダウンロードを開始するので、第１通信状態が良好なだけではダウンロードが開始されない。従って、ダウンロード期間中に通信状態が不良な地点を車両が通行することにより、更新プログラムを正常に受信できなくなるのを未然に防止できる。このため、更新プログラムの再送に伴う通信コストや消費電力の無駄を解消することができる。

［実施の形態の詳細］
以下に、図面を参照しつつ、好ましい実施の形態について説明する。以下の説明では、同一の部品および構成要素には同一の符号を付してある。それらの名称および機能も同じである。したがって、これらの説明は繰り返さない。

＜第１の実施の形態＞
〔システムの全体構成〕
図１は、本発明の実施形態にかかるプログラム更新システムの全体構成図である。
図１に示すように、本実施形態のプログラム更新システムは、広域通信網２を介して通信可能な車両１、管理サーバ５およびＤＬ（ダウンロード）サーバ６を含む。
管理サーバ５およびＤＬサーバ６は、たとえば、車両１のカーメーカーにより運営されており、予め会員登録されたユーザが所有する多数の車両１と通信可能である。

車両１には、ゲートウェイ１０と、無線通信部１５と、複数のＥＣＵ３０と、各ＥＣＵ３０によりそれぞれ制御される各種の車載機器（図示せず）とが搭載されている。
車両１には、共通の車内通信線にバス接続された複数のＥＣＵ３０による通信グループが存在し、ゲートウェイ１０は、通信グループ間の通信を中継している。このため、ゲートウェイ１０には、複数の車内通信線が接続されている。

好ましくは、図１に示されるように、車両１には、さらに、ナビゲーション装置４０が搭載されて、車内通信線によってゲートウェイ１０に接続されている。または、ナビゲーション装置４０は車両１に搭載されたものではなく、スマートフォンなどのユーザの携帯通信端末によって実現されて、無線通信部１５と通信可能であってもよい。または、ナビゲーション装置４０はナビゲート情報を提供するサーバであって、広域通信網２を介してゲートウェイ１０と通信可能であってもよい。

無線通信部１５は、携帯電話網などの広域通信網２に通信可能に接続され、車内通信線によりゲートウェイ１０に接続されている。ゲートウェイ１０は、広域通信網２を通じて管理サーバ５およびＤＬサーバ６などの車外装置から無線通信部１５が受信した情報を、ＥＣＵ３０に送信する。
ゲートウェイ１０は、ＥＣＵ３０から取得した情報を無線通信部１５に送信し、無線通信部１５は、その情報を管理サーバ５などの車外装置に送信する。

車両１に搭載される無線通信部１５としては、たとえば、ユーザが所有する携帯電話機、スマートフォン、タブレット型端末、ノートＰＣ（Personal Computer）等の装置が考えられる。
図１では、ゲートウェイ１０が無線通信部１５を介して車外装置と通信を行う場合が例示されているが、ゲートウェイ１０が無線通信の機能を有する場合には、ゲートウェイ１０自身が管理サーバ５などの車外装置と無線通信を行う構成としてもよい。

また、図１のプログラム更新システムでは、管理サーバ５とＤＬサーバ６とが別個のサーバで構成されているが、これらのサーバ５，６を１つのサーバ装置で構成してもよい。

〔ゲートウェイの内部構成〕
図２は、ゲートウェイ１０の内部構成を示すブロック図である。
図２に示すように、ゲートウェイ１０は、ＣＰＵ（Central Processing Unit）１１、ＲＡＭ（Random Access Memory）１２、記憶部１３、および車内通信部１４などを備える。ゲートウェイ１０は、無線通信部１５と車内通信線とを介して接続されているが、これらは一つの装置で構成してもよい。

ＣＰＵ１１は、記憶部１３に記憶された一または複数のプログラムをＲＡＭ１２に読み出して実行することにより、ゲートウェイ１０を各種情報の中継装置として機能させる。
ＣＰＵ１１は、たとえば時分割で複数のプログラムを切り替えて実行することにより、複数のプログラムを並列的に実行可能である。ＲＡＭ１２は、ＳＲＡＭ（Static ＲＡＭ）またはＤＲＡＭ（Dynamic ＲＡＭ）等のメモリ素子で構成され、ＣＰＵ１１が実行するプログラムおよび実行に必要なデータ等が一時的に記憶される。

記憶部１３は、フラッシュメモリ若しくはＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）等の不揮発性のメモリ素子などにより構成されている。
記憶部１３は、ＣＰＵ１１が実行するプログラムおよび実行に必要なデータ等を記憶する記憶領域を有する。記憶部１３は、ＤＬサーバ６から受信した各ＥＣＵ３０の更新プログラムなども記憶する。

車内通信部１４には、車両１に配設された車内通信線を介して複数のＥＣＵ３０が接続されている。車内通信部１４は、たとえばＣＡＮ（Controller Area Network）、ＣＡＮＦＤ（ＣＡＮ with Flexible Data Rate）、ＬＩＮ（Local Interconnect Network）、Ｅｔｈｅｒｎｅｔ（登録商標）、またはＭＯＳＴ（Media Oriented Systems Transport：ＭＯＳＴは登録商標）等の規格に応じて、ＥＣＵ３０との通信を行う。車両１にナビゲーション装置４０が搭載されている場合には、車内通信部１４は、さらに、ナビゲーション装置４０との通信も行う。
車内通信部１４は、ＣＰＵ１１から与えられた情報を対象のＥＣＵ３０へ送信するとともに、ＥＣＵ３０から受信した情報をＣＰＵ１１に与える。車内通信部１４は、上記の通信規格だけでなく、車載ネットワークに用いる他の通信規格によって通信してもよい。

無線通信部１５は、アンテナと、アンテナからの無線信号の送受信を実行する通信回路とを含む無線通信機よりなる。無線通信部１５は、携帯電話網等の広域通信網２に接続されることにより車外装置との通信が可能である。
無線通信部１５は、図示しない基地局により形成される広域通信網２を介して、ＣＰＵ１１から与えられた情報を管理サーバ５等の車外装置に送信するとともに、車外装置から受信した情報をＣＰＵ１１に与える。

図２に示す無線通信部１５に代えて、車両１内の中継装置として機能する有線通信部を採用してもよい。この有線通信部は、ＵＳＢ（Universal Serial Bus）またはＲＳ２３２Ｃ等の規格に応じた通信ケーブルが接続されるコネクタを有し、通信ケーブルを介して接続された別の通信装置と有線通信を行う。
別の通信装置と管理サーバ５等の車外装置とが広域通信網２を通じた無線通信が可能である場合には、車外装置→別の通信装置→有線通信部→ゲートウェイ１０の通信経路により、車外装置とゲートウェイ１０とが通信可能になる。

〔ＥＣＵの内部構成〕
図３は、ＥＣＵ３０の内部構成を示すブロック図である。
図３に示すように、ＥＣＵ３０は、ＣＰＵ３１、ＲＡＭ３２、記憶部３３、および通信部３４などを備える。ＥＣＵ３０は、車両１に搭載された対象機器を個別に制御する車載制御装置である。ＥＣＵ３０の種類には、たとえば、エンジン制御ＥＣＵ、ステアリング制御ＥＣＵ、およびドアロック制御ＥＣＵなどがある。

ＣＰＵ３１は、記憶部３３に予め記憶された一または複数のプログラムをＲＡＭ３２に読み出して実行することにより、自身が担当する対象機器の動作を制御する。
ＲＡＭ３２は、ＳＲＡＭまたはＤＲＡＭ等のメモリ素子で構成され、ＣＰＵ３１が実行するプログラムおよび実行に必要なデータ等が一時的に記憶される。

記憶部３３は、フラッシュメモリ若しくはＥＥＰＲＯＭ等の不揮発性のメモリ素子、或いは、ハードディスクなどの磁気記憶装置等により構成されている。
記憶部３３が記憶する情報には、たとえば、車内の制御対象である対象機器を制御するための情報処理をＣＰＵ３１に実行させるためのコンピュータプログラム（以下、「制御プログラム」という。）が含まれる。

通信部３４には、車両１に配設された車内通信線を介してゲートウェイ１０が接続されている。第１通信部３４は、たとえばＣＡＮ、Ｅｔｈｅｒｎｅｔ、またはＭＯＳＴ等の規格に応じて、ゲートウェイ１０との通信を行う。
通信部３４は、ＣＰＵ３１から与えられた情報をゲートウェイ１０へ送信するとともに、ゲートウェイ１０から受信した情報をＣＰＵ３１に与える。第１通信部３４は、上記の通信規格だけなく、車載ネットワークに用いる他の通信規格によって通信してもよい。

ＥＣＵ３０のＣＰＵ３１には、当該ＣＰＵ３１による制御モードを、「通常モード」または「リプログラミングモード」（以下、「リプロモード」ともいう。）のいずれかに切り替える起動部３５が含まれる。
ここで、通常モードとは、ＥＣＵ３０のＣＰＵ３１が、対象機器に対する本来的な制御（たとえば、燃料エンジンに対するエンジン制御や、ドアロックモータに対するドアロック制御など）を実行する制御モードのことである。

リプログラミングモードとは、対象機器の制御に用いる制御プログラムを更新する制御モードである。
すなわち、リプログラミングモードは、ＣＰＵ３１が、記憶部３３のＲＯＭ領域に対して、制御プログラムの消去や書き換えを行う制御モードのことである。ＣＰＵ３１は、この制御モードのときにのみ、記憶部３３のＲＯＭ領域に格納された制御プログラムを新バージョンに更新することが可能となる。

リプロモードにおいてＣＰＵ３１が新バージョンの制御プログラムを記憶部３３に書き込むと、起動部３５は、ＥＣＵ３０をいったん再起動（リセット）させ、新バージョンの制御プログラムが書き込まれた記憶領域についてベリファイ処理を実行する。
起動部３５は、上記のベリファイ処理の完了後に、ＣＰＵ３１を更新後の制御プログラムによって動作させる。

〔管理サーバの内部構成〕
図４は、管理サーバ５の内部構成を示すブロック図である。
図４に示すように、管理サーバ５は、ＣＰＵ５１、ＲＯＭ５２、ＲＡＭ５３、記憶部５４、および通信部５５などを備える。

ＣＰＵ５１は、ＲＯＭ５２に予め記憶された一または複数のプログラムをＲＡＭ５３に読み出して実行することにより、各ハードウェアの動作を制御し、管理サーバ５をゲートウェイ１０と通信可能な車外装置として機能させる。
ＲＡＭ５３は、ＳＲＡＭまたはＤＲＡＭ等のメモリ素子で構成され、ＣＰＵ５１が実行するプログラムおよび実行に必要なデータ等が一時的に記憶される。

記憶部５４は、フラッシュメモリ若しくはＥＥＰＲＯＭ等の不揮発性のメモリ素子、または、ハードディスクなどの磁気記憶装置等により構成されている。
通信部５５は、所定の通信規格に則って通信処理を実行する通信装置よりなり、携帯電話網等の広域通信網２に接続されて当該通信処理を実行する。通信部５５は、ＣＰＵ５１から与えられた情報を、広域通信網２を介して外部装置に送信するとともに、広域通信網２を介して受信した情報をＣＰＵ５１に与える。

〔制御プログラムの更新シーケンス〕
図５は、本実施形態のプログラム更新システムにおいて実行される、ＥＣＵに対する制御プログラムの更新の一例を示すシーケンス図である。一例として、管理サーバ５が、予め会員登録されたユーザが所有する車両１について、当該車両１のＥＣＵの制御プログラムを更新するタイミングを決定する。更新のタイミングは、たとえば、車両１のカーメーカーなどによって設定されてもよい。

好ましくは、管理サーバ５は、制御プログラムを更新するタイミングより前に、更新プログラムが格納されているＤＬサーバ５から、更新プログラムに関する情報である更新情報を取得する（ステップＳ１）。更新情報は、たとえば、更新プログラムのデータサイズに関する情報などである。

管理サーバ５は、該当する車両１のゲートウェイ１０にＥＣＵ３０の更新プログラムの存在を通知する（ステップＳ２）。ステップＳ２で管理サーバ５は、たとえば、更新プログラムの保存先ＵＲＬとダウンロード要求とを該当する車両１のゲートウェイ１０宛てに送信する。このとき、上記ステップＳ１で取得された更新情報が管理サーバ５からゲートウェイ１０に渡されてもよい。

当該通知を受けたゲートウェイ１０は、タイミング判定処理を実行する（ステップＳ３）。ステップＳ３でゲートウェイ１０は、無線通信部１５の、当該更新プログラムのダウンロード完了までにおける通信状態に基づいて、更新プログラムをＤＬサーバ６からダウンロードするタイミングを決定する。更新プログラムをダウンロードするタイミングと決定された場合、ゲートウェイ１０は、ＥＣＵ３０のための更新プログラムをＤＬサーバ６からダウンロードする（ステップＳ４）。

更新プログラムがダウンロードされると、ゲートウェイ１０では、ダウンロードしてメモリに保存した更新プログラムを用いて制御プログラムを更新させるべく、更新処理を実行する（ステップＳ５）。ステップＳ５の更新処理では、一例として、ゲートウェイ１０は、該当するＥＣＵ３０に制御プログラムの更新を要求する。これにより、当該ＥＣＵ３０の制御モードが通常モードからリプロモードに切り替わり、当該ＥＣＵは制御プログラムの更新処理が可能な状態となる。ＥＣＵ３０は、ゲートウェイ１０から受信した更新プログラムを展開して旧バージョンの制御プログラムに適用することにより、制御プログラムを旧バージョンから新バージョンに書き換える。

［タイミング判定処理］
図６は、図５のステップＳ３のタイミング判定処理の具体的な内容を表したフローチャートである。図６のフローチャートに表された処理は、ゲートウェイ１０のＣＰＵ１１が記憶部１３に記憶されたプログラムをＲＡＭ１２上に読み出して実行することによって、主にＣＰＵ１１により実現される。

図６を参照して、ゲートウェイ１０のＣＰＵ１１は、はじめに、更新プログラムのダウンロードに要する時間であるＤＬ時間を取得する（ステップＳ１０１）。ＤＬ時間とは、ＤＬサーバ６からゲートウェイ１０までの伝送路において更新プログラムの伝送が開始されてからゲートウェイ１０での受信が完了するまでの時間を指す。

ＤＬ時間は、一例として、ＣＰＵ１１において、上記の更新情報と、予め記憶しているＤＬサーバ６との間の通信速度とを用いて計算される。または、ＤＬ時間は、管理サーバ５やＤＬサーバ６において計算され、ゲートウェイ１０に渡されてもよい。これらいずれの場合も、ＣＰＵ１１におけるＤＬ時間の取得に含まれる。

次に、ＣＰＵ１１は、タイミング判定に用いるための情報である判定用情報を取得する（ステップＳ１０３）。
ダウンロード完了までの無線通信部１５の通信状態は、ダウンロード開始前の判定基準時点ｔ０における通信状態である第１通信状態と、判定基準時ｔ０からデータ受信に必要な遅延時間ΔＴ後のダウンロード開始時点ｔ１からダウンロード完了時点ｔ２までの期間中における通信状態である第２通信状態とからなる。ダウンロード開始時点ｔ１からダウンロード完了時点ｔ２までの期間をダウンロード（ＤＬ）期間と称する。判定用情報は、第１通信状態と第２通信状態とそれぞれの良否を判定するために用いる情報であって、第１通信状態が良好と判定するための第１の判定条件、および、第２通信状態が良好と判定するための第２の判定条件を含む。通信状態が良好とは、たとえば無線通信部１５の電波強度が所定強度以上あって、ＤＬサーバ６からのデータ受信が遮断されたり不安定であったりしない状態を指す。

ＣＰＵ１１は、第１通信状態が第１の判定条件を満たし、かつ、第２通信状態が第２の判定条件を満たす場合（ステップＳ１０５でＹＥＳ、かつ、Ｓ１０７でＹＥＳ）、ＣＰＵ１１は、図５のステップＳ４の転送、つまり、更新プログラムの転送をＤＬサーバ６へ要求する（ステップＳ１０９）。

一方、第１通信状態が上記第１の判定条件を満たさない場合（ステップＳ１０５でＮＯ）、または、第２通信状態が上記第２の判定条件を満たさない場合（ステップＳ１０５でＹＥＳ、かつ、Ｓ１０７でＮＯ）、つまり、判定基準時点ｔ０からダウンロード完了時点ｔ２までの期間であるダウンロード完了までの期間中の少なくとも一部において無線通信部１５の通信状態が良好ではないと判定される場合、ＣＰＵ１１は、ＤＬサーバ６へ更新プログラムの転送を要求しない。つまり、この場合、当該プログラム更新システムでは、更新プログラムのダウンロードが開始されない。この場合、ＣＰＵ１１は所定時間の後、上記ステップＳ１０３からの動作を繰り返す。所定時間は、通信状態が変化する可能性のある時間程度であればよく、たとえば１分程度であってよい。

タイミング判定処理が実行されることによって、ダウンロード完了までの期間中、無線通信部１５の通信状態が良好と判定されて始めて更新プログラムのダウンロードが開始される。

［ゲートウェイの機能構成］
図７は、上記のタイミング判定処理を行うための、ゲートウェイ１０の機能構成の具体例を示したブロック図である。図７の各機能は、ゲートウェイ１０のＣＰＵ１１が記憶部１３に記憶されたプログラムをＲＡＭ１２上に読み出して実行することによって、主にＣＰＵ１１により実現される。

詳しくは、図７を参照して、ゲートウェイ１０のＣＰＵ１１は、更新情報を取得するための更新情報取得部１１１と、無線通信部１５の上記第１通信状態および第２通信状態を判定する判定部１１２と、更新プログラムのダウンロードを開始する処理を実行するＤＬ制御部１１３とを含む。

判定部１１２は、第１通信状態を判定する第１判定部１１２Ａと、第２通信状態を判定する第２判定部１１２Ｂとを含む。第１判定部１１２Ａは、一例として、判定基準時点ｔ０における無線通信部１５の受信強度の測定値に基づいて第１通信状態の良否を判定する。この場合、第１判定部１１２Ａは第１の判定条件として受信強度の閾値を記憶している。通信強度の閾値は、たとえば−８０［ｄＢｍ］である。無線通信部１５の受信強度の測定値が閾値以上である場合に第１判定部１１２Ａは第１通信状態が良好であると判定し、閾値に達しない場合に良好でないと判定する。第１通信状態の判定に無線通信部１５の受信強度の測定値が用いられることによって、第１通信状態が良好であるか否かの判定精度を向上させることができる。

第２判定部１１２Ｂは、通信状態が不良な不感エリアを含むエリアマップと、ＤＬ期間中に車両が通過する予定の予定位置とに基づいて第２通信状態を判定する。そこで、ＣＰＵ１１は、第２判定部１１２Ｂが第２通信状態を判定するために用いる判定用情報を取得するための取得部１１４をさらに含む。判定用情報は、エリアマップと、上記予定位置を特定するための情報と含む。

取得部１１４は、エリアマップを取得する。エリアマップは、たとえば、山間部は−１００［ｄＢｍ］、トンネルや地下は−１２０［ｄＢｍ］、などのように、位置または範囲ごとに、当該位置または範囲における通信強度を示す情報である。エリアマップは、たとえば、無線通信部１５の行う無線通信を管理する通信会社などによって生成されて、ウェブサイトなどで提供されることが想定される。取得部１１４は当該ウェブサイトのＵＲＬを予め記憶しておき、当該ウェブサイトからエリアマップを取得することができる。または、エリアマップは、車両ごとのプローブカーデータなどとも呼ばれる移動軌跡情報を集約して生成された交通情報から必要な情報を取得して生成されてもよい。交通情報や交通情報から生成されるエリアマップは、カーメーカーやナビゲーションサービス業者などによってウェブサイトなどで提供されることが想定される。取得部１１４は当該ウェブサイトのＵＲＬを予め記憶しておき、当該ウェブサイトからエリアマップを取得することができる。または、取得部１１４は当該ウェブサイトから交通情報を取得して、エリアマップを生成してもよい。第２判定部１１２Ｂは、通信会社から提供されたエリアマップまたは交通情報から生成されるエリアマップ、あるいはこれらの組み合わせを用いる。

また、取得部１１４は、予定位置を特定するための情報を取得する。予定位置を特定するための情報は、たとえばナビゲーション装置４０が生成した走行経路を含む。ナビゲーション装置４０は、車両１の走行速度を取得して走行経路上の各位置を通過するまでの時間を予測する。ナビゲーション装置４０が生成した走行経路は、走行経路と各位置を通過するまでの時間とを含む。走行経路は、車両１が走行する予定の走行経路であると想定される。取得部１１４は、車内通信部１４でナビゲーション装置４０と通信することによって、ナビゲーション装置４０から走行経路を取得する。

予定位置を特定するための情報は、他の例として、車両１の走行履歴から予測される当該車両１の予測経路を含む。走行履歴は、たとえば、曜日、時間などの所定期間ごとの車両１の走行位置（たとえば緯度経度）を統計処理したもので、所定期間ごとの走行パターンのモデルと言える。一例として、ＣＰＵ１１は、車両１の走行履歴を生成する学習部１１５を含む。学習部１１５は、車内通信部１４で該当するＥＣＵ３０やカーナビゲーション装置４０などと通信することによって、車両１の走行状態を示す情報を所定期間、収集する。車両１の走行状態を示す情報は、たとえばエンジンのＯＮ／ＯＦＦ状態、稼働状況や、電源のＯＮ／ＯＦＦ状態などを含む。また、車両１の走行位置を取得し、蓄積する。そして、蓄積された走行位置に対して、時間帯や曜日や季節などの所定期間ごとに統計処理を施す。統計処理は、一例として、所定期間ごとに走行している可能性の最も高い位置を特定して当該期間の走行位置と決定する処理である。たとえば、月曜日から金曜日まで出勤に車両１が使用されている場合、通勤時間帯（たとえば朝８時から８時３０分まで）の走行履歴は自宅から会社までの走行経路を示す。また、夜間（たとえば夜９時から翌朝８時まで）の走行履歴は自宅に駐車中（自宅から動かない）という走行経路になる。統計処理の方法は特定方法に限定されず、あらゆる方法が採用され得る。生成された走行履歴は記憶部１３の走行履歴記憶部１３１に記憶される。なお、車両１ごとの走行履歴が管理サーバ５などの他の装置によって生成され記憶されていてもよい。取得部１１４は、走行履歴記憶部１３１または管理サーバ５などの他の装置の記憶部から走行履歴を読み出す。

第２判定部１１２Ｂは、走行履歴に基づいて車両１の走行経路を予測する。たとえば、第２判定部１１２Ｂは、現在日時に対応した期間の走行履歴（たとえば自宅から会社までの走行経路や、自宅から動かないという走行経路、など）を読み出して、予測経路とする。現在日時に対応した期間の走行履歴は、車両１が走行する経路であると予測される。

予定位置を特定するための情報は、さらに、判定基準時点ｔ０における車両１の位置Ｐ１を含む。取得部１１４は、たとえば、ナビゲーション装置４０と通信したりＧＰＳ（Global Positioning System）と通信したりすることで、車両１の位置Ｐ１を取得する。

第２判定部１１２Ｂは、走行経路または走行履歴から予測される予測経路に基づいて、予定位置を特定する。なお、予定位置の特定に、走行経路と予測経路との両方が用いられてもよい。たとえば、走行経路と予測経路との一致が確認されてもよいし、予測経路が得られなかった場合や位置Ｐ１が予測経路上になかった場合に走行経路が用いられてもよい。

予定位置は、走行経路または予測経路上の位置であって、位置Ｐ１からダウンロード完了時点ｔ２までの走行経路または予測経路上の位置Ｐ２である。つまり、第２判定部１１２Ｂは、走行経路または予測経路上の位置Ｐ１から位置Ｐ２までの経路上の任意の点を予定位置とする。

第２判定部１１２Ｂは、エリアマップに示される不感エリアに予定位置が含まれるか否かにより、第２通信状態の良否を判定する。予定位置が不感エリアに含まれる場合、つまり、位置Ｐ１から位置Ｐ２までの経路が不感エリアを通過しない場合に、第２判定部１１２Ｂは第２通信状態が良好であると判定する。そうでない場合、第２判定部１１２Ｂは第２通信状態が良好であると判定しない。

予定位置を特定するための情報は、他の例として、上記位置Ｐ１、車両１の現在の走行状態、および地図を含んでもよい。走行状態は走行速度を含み、さらに走行方向（方角、垂直方向の角度）を含んでもよい。取得部１１４は、車両１に搭載されている各ＥＣＵ３０と通信したり、図示しないスマートフォンなどのユーザの携帯通信端末と通信したり、ヨーレートセンサなどの各種センサの値を参照したりすることなどによって走行状態を取得できる。地図情報は、記憶部１３に予め記憶されている場合には記憶部１３から読み出すことによって得られる。または、ナビゲーション装置やナビゲーション装置として機能するスマートフォンなどのユーザの携帯通信端末との通信や、地図情報を提供する図示しないサーバとの通信によって得られてもよい。

車両１が高速道路や橋などの分岐のない道路を走行中の場合、第２判定部１１２Ｂは、位置Ｐ１、車両１の現在の走行状態、および地図に基づいて車両１の走行経路を予測してもよい。つまり、この場合、第２判定部１１２Ｂは、上記道路を車両１の走行経路を予測して、位置Ｐ１から位置Ｐ２までの該道路上の任意の点を予定位置としてもよい。

なお、第１判定部１１２Ａも第１通信状態の判定に、第２判定部１１２Ｂと同様にエリアマップを用いてもよい。すなわち、第１判定部１１２Ａは、位置Ｐ１がエリアマップに示される不感エリアに含まれるか否かによって第１通信状態の良否を判定してもよい。

ＤＬ制御部１１３は、第１判定部１１２Ａにおいて第１通信状態が良好と判定され、かつ、第２判定部１１２Ｂにおいて第２通信状態が良好であると判定された場合に、更新プログラムのダウンロードを開始する。少なくとも一方の通信状態が良好であると判定されなかった場合には、ダウンロードは開始しない。

図８は、タイミング判定を説明するための図である。図８は、判定基準時点ｔ０において同じ位置Ｐ１にいる車両Ａ，Ｂそれぞれについて、タイミング判定を行う例を示している。車両Ａの走行経路または予測経路はルートＡと取得され、車両Ｂの走行経路または予測経路はルートＡと異なるルートＢと取得されたものとする。車両Ａは位置Ｐ１からルートＡを走行し、ダウンロード完了時点ｔ２で位置Ｐ２Ａに達する。車両Ｂは位置Ｐ１からルートＢを走行し、ダウンロード完了時点ｔ２で位置Ｐ２Ｂに達する。従って、車両Ａの予定位置はルートＡ上の位置Ｐ１から位置Ｐ２Ａまでの任意の点であり、車両Ｂの予定位置はルートＢ上の位置Ｐ１から位置Ｐ２Ｂまでの任意の点である。

位置Ｐ１においては、車両Ａ，Ｂいずれの無線通信部１５の通信状態が良好であったとする。つまり、車両Ａ，Ｂのいずれも、第１通信状態は良好と判定されたものとする。

ルートＡは不感エリアを通過せず、ルートＢが不感エリアを通過するものとする。そのため、車両Ａについては、第２通信状態は良好と判定される。一方、車両Ｂについては、第２通信状態は良好と判定されない。

図８の例の場合、車両Ａは、第１通信状態および第２通信状態の双方が良好と判定される。そのため、ＤＬ制御部１１３は、車両Ａに対してはダウンロードを開始する。一方、車両Ｂは、第１通信状態は良好と判定されるものの第２通信状態は良好と判定されない。そのため、ＤＬ制御部１１３は、車両Ｂに対してはダウンロードを開始しない。

［第１の実施の形態の効果］
第１の実施の形態にかかるプログラム更新システムによれば、ＥＣＵの更新プログラムのダウンロードを、ゲートウェイ１０の無線通信部１５の、判定基準時点ｔ０の通信状態とＤＬ期間中における通信状態とに基づいたタイミングに開始することができる。すなわち、ＤＬ期間中、無線通信部１５の通信状態が良好である状態が維持されない場合には更新プログラムのダウンロードが開始されず、ＤＬ期間中通信状態が良好である状態が維持される場合にダウンロードが開始される。これによって、ＤＬ期間中に通信状態が不良な地点を車両が通行することにより、更新プログラムを正常に受信できなくなるという事態を未然に防止できる。このため、更新プログラムの再送に伴う通信費や電力の無駄を解消することができる。

さらに、ナビゲーション装置で生成された走行経路または当該車両の走行履歴から予測される予測経路を取得することによって、車両が通過する予定位置を特定することができる。これにより、第２通信状態が良好であるか否かの判定精度を向上させることができる。

また、第１通信状態の判定に無線通信部１５の受信強度の測定値が用いられることによって、第１通信状態が良好であるか否かの判定精度を向上させることができる。

または、第１通信状態の判定にエリアマップが用いられることによって、無線通信部１５の受信強度の測定が不要になる。これにより、第１通信状態が良好であるか否かの判定を簡便に行うことができる。

＜第２の実施の形態＞
第１の実施の形態にかかるプログラム更新システムでは、更新プログラムのダウンロードを制御する制御装置であるゲートウェイ１０においてタイミング判定処理が実行される。ここで、図５に示された例では、管理サーバ５からの更新プログラムの通知（ダウンロード要求およびダウンロード先のＵＲＬの通知）に応じてＤＬサーバ６から更新プログラムがダウンロードされている。そのため、管理サーバ５も上記の制御装置であると言える。そこで、タイミング判定処理は管理サーバ５において行われてもよい。

この場合、管理サーバ５のＣＰＵ５１がＲＯＭ５２に記憶されているプログラムをＲＡＭ５３上に読み出して実行することによって図７の各機能が実現される。管理サーバ５は、車両１のカーメーカーに設定されるなどによって更新プログラムのダウンロードが可能になると上記のタイミング判定処理を実行する。そして、管理サーバ５は、ダウンロード期間中の広域通信網２の通信状態に基づいて判定されたタイミングでゲートウェイ１０に対してダウンロードを通知する。

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１ 車両
２ 広域通信網
５ 管理サーバ（制御装置）
６ ＤＬサーバ
１０ ゲートウェイ（制御装置）
１１ ＣＰＵ
１２ ＲＡＭ
１３ 記憶部
１４ 車内通信部
１５ 無線通信部
３０ ＥＣＵ（車載制御装置）
３１ ＣＰＵ
３２ ＲＡＭ
３３ 記憶部
３４ 通信部
３５ 起動部
５１ ＣＰＵ
５２ ＲＯＭ
５３ ＲＡＭ
５４ 記憶部
５５ 通信部
１１１ 更新情報取得部
１１２ 判定部
１１２Ａ 第１判定部
１１２Ｂ 第２判定部
１１３ ＤＬ制御部（処理部）
１１４ 取得部
１１５ 学習部
１３１ 走行履歴記憶部

Claims (8)

1. 車両に搭載された対象機器を制御する車載制御装置の更新プログラムのダウンロードを制御する制御装置であって、
   前記更新プログラムを無線通信により受信する前記車両の無線通信部に関する下記の第１および第２通信状態を判定する判定部と、
   前記第１および第２通信状態の双方が良好である場合に、前記更新プログラムのダウンロードを開始する処理部と、を備える、制御装置。
   第１通信状態：ダウンロード開始前の判定基準時点における通信状態
   第２通信状態：ダウンロード開始前の判定基準時後の所定時点からダウンロード完了までのダウンロード期間中における通信状態
2. 前記通信状態が不良な不感エリアを含むエリアマップを取得する取得部をさらに備え、
   前記判定部は、前記ダウンロード期間中に前記車両が通過する予定位置が、前記不感エリアに含まれるか否かにより、前記第２通信状態の良否を判定する、請求項１に記載の制御装置。
3. 前記取得部は、前記車両に搭載または非搭載のナビゲーション装置が生成した前記車両の走行経路をさらに取得し、
   前記判定部は、取得された前記車両の走行経路に基づいて、前記予定位置を特定する、請求項２に記載の制御装置。
4. 前記取得部は、前記車両の過去の走行履歴をさらに取得し、
   前記判定部は、取得された前記車両の走行履歴から予測される予測経路に基づいて、前記予定位置を特定する、請求項２または３に記載の制御装置。
5. 前記判定部は、前記判定基準時点における前記無線通信部の受信強度の測定値に基づいて、前記第１通信状態の良否を判定する、請求項１〜請求項４のいずれか一項に記載の制御装置。
6. 前記判定部は、前記判定基準時点における車両位置が、前記不感エリアに含まれるか否かにより、前記第１通信状態の良否を判定する、請求項２〜請求項４のいずれか一項に記載の制御装置。
7. 車両に搭載された対象機器を制御する車載制御装置の更新プログラムの配信方法であって、
   前記更新プログラムを無線通信により受信する前記車両の無線通信部に関する下記の第１および第２通信状態を判定するステップと、
   前記第１および第２通信状態の双方が良好である場合に、前記更新プログラムのダウンロードを開始するステップと、を備える、プログラム配信方法。
   第１通信状態：ダウンロード開始前の判定基準時点における通信状態
   第２通信状態：ダウンロード開始前の判定基準時後の所定時点からダウンロード完了までのダウンロード期間中における通信状態
8. 車両に搭載された対象機器を制御する車載制御装置の更新プログラムのダウンロードを制御する制御装置としてコンピュータを機能させるためのコンピュータプログラムであって、前記コンピュータを、
   前記更新プログラムを無線通信により受信する前記車両の無線通信部に関する下記の第１および第２通信状態を判定する判定部、および、
   前記第１および第２通信状態の双方が良好である場合に、前記更新プログラムのダウンロードを開始する処理部、として機能させる、コンピュータプログラム。
   第１通信状態：ダウンロード開始前の判定基準時点における通信状態
   第２通信状態：ダウンロード開始前の判定基準時後の所定時点からダウンロード完了までのダウンロード期間中における通信状態

Images