(57)【要約】【課題】  車両制御装置が制御機能を実行しない走行ルートを設定しなくても、車両走行中における制御プログラムの更新可否を適切に判定できるようにする。【解決手段】  本発明の一態様に係る装置は、車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する装置であって、車両走行時における前記車載制御装置の制御機能の利用パターンを取得する取得部と、取得した前記利用パターンに基づいて、前記車載制御装置についての前記制御プログラムの更新可否を決定する制御部と、を備えている。【選択図】      図５
2018069870.tif 000002
【特許請求の範囲】
【請求項１】
車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する装置であって、
車両走行時における前記車載制御装置の制御機能の利用パターンを取得する取得部と、
取得した前記利用パターンに基づいて、前記車載制御装置についての前記制御プログラムの更新可否を決定する制御部と、を備える制御装置。
【請求項２】
前記制御部は、取得した前記利用パターンに基づいて、車両走行中における前記車載制御装置の制御機能の利用可能性の多寡を判定し、この判定結果に応じて、前記制御プログラムの更新可否を決定する請求項１に記載の制御装置。
【請求項３】
前記制御部は、前記利用可能性が所定の閾値以下である場合に、前記制御プログラムの更新が可能であると判定する請求項２に記載の制御装置。
【請求項４】
前記利用パターンには、前記車両を運転し得るユーザの識別情報ごとに設定された利用パターンが含まれる請求項１から請求項３のいずれか１項に記載の制御装置。
【請求項５】
前記ユーザの識別情報には、前記車両が自動運転である場合の識別情報が含まれる請求項４に記載の制御装置。
【請求項６】
車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する方法であって、
車両走行時における前記車載制御装置の制御機能の利用パターンを取得するステップと、
取得した前記利用パターンに基づいて、前記制御プログラムの更新可否を判定するステップと、を含む制御方法。
【請求項７】
車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する制御装置として、コンピュータを機能させるためのコンピュータプログラムであって、前記コンピュータを、
車両走行時における前記車載制御装置の制御機能の利用パターンを取得する取得部、及び、
取得した前記利用パターンに基づいて、前記制御プログラムの更新可否を判定する制御部、として機能させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、制御装置、制御方法及びコンピュータプログラムに関する。
【背景技術】
【０００２】
近年、自動車の技術分野においては、車両の高機能化が進行しており、多種多様な車載
機器が車両に搭載されている。従って、車両には、各車載機器を制御するための制御装置
である、所謂ＥＣＵ（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）又はＲＳ２３２Ｃ等の規格に応じた通信ケーブルが接続されるコネクタを有し、通信ケーブルを介して接続された別の通信装置と有線通信を行う。
別の通信装置と管理サーバ５等の車外装置とが広域通信網２を通じた無線通信が可能である場合には、車外装置→別の通信装置→有線通信部→ゲートウェイ１０の通信経路により、車外装置とゲートウェイ１０が通信可能になる。
【００３５】
〔ＥＣＵの内部構成〕
図３は、ＥＣＵ３０の内部構成を示すブロック図である。
図３に示すように、ＥＣＵ３０は、ＣＰＵ３１、ＲＡＭ３２、記憶部３３、通信部３４などを備える。ＥＣＵ３０は、車両１に搭載された対象機器を個別に制御する車載制御装置である。ＥＣＵ３０の種類には、例えば、エンジン、ブレーキ及び操舵機能などに関する走行系ＥＣＵ、ヘッドライトやドアロックなどのボディ系制御ＥＣＵ、レーンキープアシストなどの自動走行系ＥＣＵなどがある。
【００３６】
ＣＰＵ３１は、記憶部３３に予め記憶された１又は複数のプログラムをＲＡＭ３２に読み出して実行することにより、自身が担当する対象機器の動作を制御する。ＣＰＵ３１は、１又は複数の大規模集積回路（ＬＳＩ）を含む。複数のＬＳＩを含むＣＰＵ３１では、複数のＬＳＩが協働してＣＰＵ３１の機能を実現する。
ＲＡＭ３２は、ＳＲＡＭ又はＤＲＡＭ等のメモリ素子で構成され、ＣＰＵ３１が実行するプログラム及び実行に必要なデータ等が一時的に記憶される。
【００３７】
記憶部３３は、フラッシュメモリ若しくはＥＥＰＲＯＭ等の不揮発性のメモリ素子、或いは、ハードディスクなどの磁気記憶装置等により構成されている。
記憶部３３が記憶する情報には、例えば、車内の制御対象である対象機器を制御するための情報処理をＣＰＵ３１に実行させるためのコンピュータプログラム（以下、「制御プログラム」という。）が含まれる。
【００３８】
通信部３４には、車両１に配設された車内通信線を介してゲートウェイ１０が接続されている。通信部３４は、例えばＣＡＮ、Ｅｔｈｅｒｎｅｔ、又はＭＯＳＴ等の規格に応じて、ゲートウェイ１０との通信を行う。
通信部３４は、ＣＰＵ３１から与えられた情報をゲートウェイ１０へ送信するとともに、ゲートウェイ１０から受信した情報をＣＰＵ３１に与える。通信部３４は、上記の通信規格だけなく、車載ネットワークに用いる他の通信規格によって通信してもよい。
【００３９】
ＥＣＵ３０のＣＰＵ３１には、当該ＣＰＵ３１による制御モードを、「通常モード」又は「リプログラミングモード」（以下、「リプロモード」ともいう。）のいずれかに切り替える起動部３５が含まれる。
ここで、通常モードとは、ＥＣＵ３０のＣＰＵ３１が、対象機器に対する本来的な制御（例えば、燃料エンジンに対するエンジン制御や、ドアロックモータに対するドアロック制御など）を実行する制御モードのことである。
【００４０】
リプログラミングモードとは、対象機器の制御に用いる制御プログラムを更新する制御モードである。
すなわち、リプログラミングモードは、ＣＰＵ３１が、記憶部３３のＲＯＭ領域に対して、制御プログラムの消去や書き換えを行う制御モードのことである。ＣＰＵ３１は、この制御モードのときにのみ、記憶部３３のＲＯＭ領域に格納された制御プログラムを新バージョンに更新することが可能となる。
【００４１】
リプロモードにおいてＣＰＵ３１が新バージョンの制御プログラムを記憶部３３に書き込むと、起動部３５は、ＥＣＵ３０をいったん再起動（リセット）させ、新バージョンの制御プログラムが書き込まれた記憶領域についてベリファイ処理を実行する。
起動部３５は、上記のベリファイ処理の完了後に、ＣＰＵ３１を更新後の制御プログラムによって動作させる。
【００４２】
〔管理サーバの内部構成〕
図４は、管理サーバ５の内部構成を示すブロック図である。
図４に示すように、管理サーバ５は、ＣＰＵ５１、ＲＯＭ５２、ＲＡＭ５３、記憶部５４、及び通信部５５などを備える。
【００４３】
ＣＰＵ５１は、ＲＯＭ５２に予め記憶された１又は複数のプログラムをＲＡＭ５３に読み出して実行することにより、各ハードウェアの動作を制御し、管理サーバ５をゲートウェイ１０と通信可能な車外装置として機能させる。ＣＰＵ５１は、１又は複数の大規模集積回路（ＬＳＩ）を含む。複数のＬＳＩを含むＣＰＵ５１では、複数のＬＳＩが協働してＣＰＵ５１の機能を実現する。
ＲＡＭ５３は、ＳＲＡＭ又はＤＲＡＭ等のメモリ素子で構成され、ＣＰＵ５１が実行するプログラム及び実行に必要なデータ等が一時的に記憶される。
【００４４】
記憶部５４は、フラッシュメモリ若しくはＥＥＰＲＯＭ等の不揮発性のメモリ素子、又は、ハードディスクなどの磁気記憶装置等により構成されている。
通信部５５は、所定の通信規格に則って通信処理を実行する通信装置よりなり、携帯電話網等の広域通信網２に接続されて当該通信処理を実行する。通信部５５は、ＣＰＵ５１から与えられた情報を、広域通信網２を介して外部装置に送信するとともに、広域通信網２を介して受信した情報をＣＰＵ５１に与える。
【００４５】
記憶部５４が記憶する情報には、登録会員であるユーザの個人情報や、車両１に搭載されたＥＣＵ３０が実行する制御プログラムのバージョン情報などを管理するためのサービス管理テーブル（図示せず）などが含まれる。
サービス管理テーブルは、例えば、登録会員が所有する車両１の車両識別番号（ＶＩＮ）と、車両識別番号ごとのＥＣＵ３０の種別と、各ＥＣＵ３０が実行する制御プログラムのバージョン情報の履歴とを纏めた参照テーブルよりなる。
【００４６】
ＤＬサーバ６には、すべての種別のＥＣＵ３０について、当該ＥＣＵ３０が実行する制御プログラムのバージョンごとの更新プログラムが格納されている。
ＤＬサーバ６が保持する更新プログラムは、当該ＥＣＵ３０にインストールさせる最新バージョンの制御プログラムそのものであってもよいし、旧バージョンの制御プログラムと新バージョンの制御プログラムとの差分プログラム（以下、差分プログラムよりなる更新プログラムを「Δ」と記載することがある。）であってもよい。
【００４７】
車両１のゲートウェイ１０は、自車両に搭載されたＥＣＵ３０が使用中の制御プログラムのバージョン情報と、自車両の車両識別番号とを含む通信パケットを、所定時間おきに管理サーバ５に送信している。
管理サーバ５のＣＰＵ５１は、ゲートウェイ１０から受信した通信パケットに含まれる制御プログラムのバージョン情報が最新バージョンであるか否かを、サービス管理テーブルを参照して判定する。
【００４８】
ＣＰＵ５１は、判定の結果、ゲートウェイ１０から通知された制御プログラムのバージョン情報が最新でない場合には、更新プログラムの保存先であるＤＬサーバ６のＵＲＬを含む通信パケットをゲートウェイ１０に送信する。
上記の通信パケットを受信したゲートウェイ１０は、管理サーバ５から通知されたＵＲＬと、リプログラミングを実行すべきＥＣＵ３０の種別とを含むダウンロード要求をＤＬサーバ６に送信する。
【００４９】
ダウンロード要求を受信したＤＬサーバ６は、ゲートウェイ１０から通知されたＥＣＵ３０の種別に対応する更新プログラムを、ダウンロード要求の送信元であるゲートウェイ１０に送信する。
更新プログラムを受信したゲートウェイ１０のＣＰＵ３１は、受信した更新プログラムをＥＣＵ３０に転送し、制御プログラムを最新バージョンに更新する処理をＥＣＵ３０に実行させる。
【００５０】
〔制御プログラムの更新シーケンス〕
図５は、本実施形態のプログラム更新システムにおいて実行される、対象ＥＣＵ３０Ａ〜３０Ｃに対する制御プログラムの更新の一例を示すシーケンス図である。
図５において、「対象ＥＣＵ」は、制御プログラムの更新対象のＥＣＵ３０のことである。「情報系ＥＣＵ」は、カーナビゲーション装置、同装置の液晶ディスプレイ（表示装置）及び入力デバイスなどの情報系の対象機器を制御するＥＣＵ３０のことである。
【００５１】
図５に示すように、ゲートウェイ１０は、自車両の対象ＥＣＵ３０Ａ〜３０Ｃの制御プログラムのバージョン情報と、自車両の車両識別番号（ＶＩＮ）などを含む通信パケットを管理サーバ５に送信する（ステップＳ１）。
管理サーバ５は、受信した通信パケットに含まれるバージョン情報と車両識別番号に基づいて、前述のサービス管理テーブルを探索することにより、対象ＥＣＵ３０Ａ〜３０Ｃに関する制御プログラムの更新の必要性を判定する。
【００５２】
ここでは、管理サーバ５が、車両１の対象ＥＣＵ３０Ａ〜３０Ｃについて更新の必要性ありと判定した場合を想定する。
この場合、管理サーバ５は、パケット送信元のゲートウェイ１０宛てに、対象ＥＣＵ３０Ａ〜３０Ｃの更新プログラムの保存先ＵＲＬ（ＤＬサーバ６における更新プログラム格納フォルダのＵＲＬ）を含むダウンロード要求を送信する（ステップＳ２）。
【００５３】
次に、ゲートウェイ１０は、保存先ＵＲＬにアクセスし、対象ＥＣＵ３０Ａ〜３０Ｃの更新プログラムΔを要求する通信パケットをＤＬサーバ６に送信し（ステップＳ３）、ＤＬサーバ６は、更新プログラムΔをゲートウェイ１０に転送する（ステップＳ４）。
更新プログラムのダウンロードが完了すると、ゲートウェイ１０は、更新プログラムを自装置の記憶部１３に一時的に格納して保存し、ダウンロード完了通知を管理サーバ５に送信する（ステップＳ５）。
【００５４】
本実施形態では、ゲートウェイ１０は、上記のダウンロード完了通知に、管理サーバ５が後述の「リプロ実行可否の判定処理」（ステップＳ６）に用いる、車両１の現時点の車両情報を含める。
現時点の車両情報には、例えば、ユーザＩＤ、運転状況（駐車／停車／走行のいずれか。）、現在位置、現在時刻、ＯＤ（Origin-Destination）情報（走行経路を含む。）、及びバッテリ残量などが含まれる。
【００５５】
ユーザＩＤは、車両１の運転者を識別できるように、車両識別情報とは別個に定義された識別情報である。同じ車両１を運転する複数のユーザのユーザＩＤは、スマートキー情報などを利用して定義することができる。
例えば、１台の車両１を３人のユーザ（車両１の所有者とその配偶者とその長男など）が共用する場合、１つの車両識別情報（ＶＩＮ）に対応する３つのスマートキー情報の値を各人のユーザＩＤとすればよい。
【００５６】
ダウンロード完了通知を受信した管理サーバ５は、「リプロ実行可否の判定処理」を実行する（ステップＳ６）。
この判定処理は、対象ＥＣＵ３０Ａ〜３０Ｃが担う制御機能の利用可能性に応じて、制御プログラムの更新可否を判定する処理である。対象ＥＣＵ３０Ａ〜３０Ｃの制御機能の利用可能性は、管理サーバ５が予め記憶する利用パターンに基づいて判定される。なお、利用パターンに基づくリプロ実行可否の判定処理（図６）の詳細については後述する。
【００５７】
ここでは、管理サーバ５によるリプロ実行可否の判定結果が肯定的である場合（リプロ実行可能である場合）を想定する。この場合、管理サーバ５は、制御プログラムの更新の実行要求をゲートウェイ１０に送信する（ステップＳ７）。
実行要求を受信したゲートウェイ１０は、更新プログラムΔを用いた制御プログラムの更新の実行要否をユーザに確認させるため、情報系ＥＣＵ３０Ｄに確認要求を送信する（ステップＳ８）。
【００５８】
確認要求を受信した情報系ＥＣＵ３０Ｄは、カーナビゲーション装置の液晶ディスプレイなどの表示装置に実行要否の確認画面を表示させる（ステップＳ９）。
この確認画面には、例えば、「対象ＥＣＵ３０Ａ〜３０Ｃの制御プログラムを更新しますか？」、「対象ＥＣＵ３０Ａ〜３０Ｃの制御プログラムを更新可能です。今すぐ実行？ 後で実行？」など、制御プログラムの更新を実行するか否かをユーザが選択可能な表示が含まれる。
【００５９】
ここでは、ユーザが、車両１の入力デバイスへの操作入力により、対象ＥＣＵ３０Ａ〜３０Ｃについての制御プログラムの更新の実行を選択する場合を想定する。
この場合、更新実行の入力信号が情報系ＥＣＵ３０Ｄに送信され、情報系ＥＣＵ３０Ｄがゲートウェイ１０に更新許可を送信する（ステップＳ１０）。更新許可を受信したゲートウェイ１０は、対象ＥＣＵ３０Ａ〜３０Ｃに制御プログラムの更新要求を送信するともに（ステップＳ１１）、対象ＥＣＵ３０Ａ〜３０Ｃに更新プログラムΔを転送する。
【００６０】
更新要求を受信した対象ＥＣＵ３０Ａ〜３０Ｃは、制御プログラムの更新処理を実行する（ステップＳ１２）。
具体的には、対象ＥＣＵ３０Ａ〜３０ＣのＣＰＵ３１の起動部３５が、自機の制御モードを通常モードからリプロモードに切り替え（図３参照）、受信した更新プログラムΔを展開して旧バージョンの制御プログラムに適用することにより、制御プログラムが旧バージョンから新バージョンに書き換えられる。
【００６１】
制御プログラムの更新処理が完了すると、対象ＥＣＵ３０Ａ〜３０Ｃは、自機の更新処理の完了通知をゲートウェイ１０にそれぞれ送信する（ステップＳ１３）。
上記の完了通知を受信すると、ゲートウェイ１０は、自車両の車両識別番号と、対象ＥＣＵ３０Ａ，３０Ｂの更新処理が完了した旨の完了通知を、管理サーバ５に送信する（ステップＳ１４）。
【００６２】
上記の完了通知を受信した管理サーバ５は、自装置が管理するサービス管理テーブルの内容をアップデートする。
具体的には、管理サーバ５は、ゲートウェイ１０から受信した完了通知に含まれる車両識別番号を探索し、当該識別番号に関連づけられた対象ＥＣＵ３０Ａ〜３０Ｃの制御プログラムのバーション情報を新バージョンに更新する。
【００６３】
〔リプロ実行可否の判定処理〕
図６は、管理サーバ５のＣＰＵ５１が実行する、リプロ実行可否の判定処理の一例を示すフローチャートである。
図６に示すように、管理サーバ５のＣＰＵ５１は、ゲートウェイ１０からダウンリンク完了通知を受信したか否かを継続的に判定している（ステップＳＴ１０）。
【００６４】
ダウンロード完了通知を受信したＣＰＵ５１は、当該完了通知から車両１の現時点の車両情報を抽出するとともに（ステップＳＴ１１）、自装置の記憶部５４から対象ＥＣＵ３０Ａ〜３０Ｃの制御機能の車両走行時における「利用パターン」を読み出す（ステップＳＴ１２）。
利用パターンとは、例えば、特定のユーザ又はユーザ全般が、どのような状況の場合にＥＣＵ３０の制御対象を利用するか或いは利用しないかなど、車両１のユーザによるＥＣＵ３０の制御対象の利用傾向のことを意味する。
【００６５】
次に、管理サーバ５のＣＰＵ５１は、車両１の現時点の車両情報と、自装置が記憶する車両走行時における利用パターンとに基づいて、車両走行時における対象ＥＣＵ３０Ａ〜３０Ｃの利用可能性が低いか否かを判定する（ステップＳＴ１３）。
具体的には、ＣＰＵ５１は、例えば、利用パターンに基づく対象ＥＣＵ３０Ａ〜３０Ｃの利用可能性が所定の閾値（例えば５％）以下の場合は、利用可能性が低いと判定し、所定の閾値を超える場合は、利用可能性が高いと判定する。
【００６６】
ステップＳＴ１３の判定結果が肯定的である場合は、ＣＰＵ５１は、ゲートウェイ１０に更新の実行要求を送信する（ステップＳＴ１４）。
上記の実行要求を受信したゲートウェイ１０は、前述の通り、自車両の情報系ＥＣＵ３０Ｄに確認要求を送信する（図５のステップＳ８）。これにより、車両１のユーザに、対象ＥＣＵ３０Ａ〜３０Ｃの実行要否が通知される（図５のステップＳ９）。
【００６７】
ステップＳＴ１３の判定結果が否定的である場合は、ＣＰＵ５１は、ゲートウェイ１０に更新の待機指令を送信する（ステップＳＴ１５）。
上記の待機指令は、例えば、所定時間（例えば、１時間〜１日程度）の経過後にダウンロード完了通知の再送を指令する通信パケットよりなる。従って、管理サーバ５のＣＰＵ５１は、所定時間経過後にゲートウェイ１０から受信するダウンロード完了通知を契機として、リプロ実行可否の判定処理（図６）を再度実行する。
【００６８】
次に、ステップＳＴ１３の判定方法の具体例１〜３について説明する。
（判定方法の具体例１）
判定方法の具体例１では、対象ＥＣＵ３０Ａが更新する制御機能が「オートライト」（照度に応じてヘッドライト等を点灯又は消灯する機能）である場合を想定する。
【００６９】
ここで、管理サーバ５が記憶する利用パターンが、「ユーザ１については、オートライトを利用する可能性は１％である。」とする。
この場合、管理サーバ５のＣＰＵ５１は、ゲートウェイ１０のダウンロード完了通知に含まれるユーザＩＤが「ユーザ１」である場合には、対象ＥＣＵ３０Ａの利用可能性が低いと判定し（ステップＳＴ１３でＹｅｓ）、対象ＥＣＵ３０Ａに関する更新の実行要求を送信する（ステップＳＴ１４）。
【００７０】
或いは、管理サーバ５が記憶する利用パターンが、「ユーザ１については、昼間（１２：００〜１５：００）にオートライトを利用する可能性は１％であり、その他の時間帯でオートライトを利用する可能性は１０％である。」とする。
この場合、管理サーバ５のＣＰＵ５１は、ゲートウェイ１０から通知されたユーザＩＤが「ユーザ１」であり、現在時刻が昼間以外の時間帯である場合には、対象ＥＣＵ３０Ａの利用可能性が高いと判定し（ステップＳＴ１３でＮｏ）、対象ＥＣＵ３０Ａに関する更新の待機要求を送信する（ステップＳＴ１５）。
【００７１】
或いは、管理サーバ５が記憶する利用パターンが、「ユーザ１については、トンネル通過時にオートライトを利用する可能性は２０％であり、その他の区間でオートライトを利用する可能性は１％である。」とする。
この場合、管理サーバ５のＣＰＵ５１は、ゲートウェイ１０から通知されたユーザＩＤが「ユーザ１」であり、現在時刻及びＯＤ情報からトンネル区間の走行が予想される場合には、対象ＥＣＵ３０Ａの利用可能性が高いと判定し（ステップＳＴ１３でＮｏ）、対象ＥＣＵ３０Ａに関する更新の待機要求を送信する（ステップＳＴ１５）。
【００７２】
（判定方法の具体例２）
判定方法の具体例２では、対象ＥＣＵ３０Ｂが更新する制御機能が「レーンキープアシスト」（車線をキープするように自動操舵する機能：以下、「ＬＫＡ」ともいう。）である場合を想定する。
【００７３】
ここで、管理サーバ５が記憶する利用パターンが、「ユーザ２については、高速道路における所定の道路区間においてＬＫＡを利用する可能性は１％である。」とする。
この場合、管理サーバ５のＣＰＵ５１は、ゲートウェイ１０のダウンロード完了通知に含まれるユーザＩＤが「ユーザ２」であり、現在時刻、現在位置及びＯＤ情報などから所定の道路区間の走行が予想される場合には、対象ＥＣＵ３０Ｂの利用可能性が低いと判定し（ステップＳＴ１３でＹｅｓ）、対象ＥＣＵ３０Ｂに関する更新の実行要求を送信する（ステップＳＴ１４）。
【００７４】
（判定方法の具体例３）
判定方法の具体例３では、対象ＥＣＵ３０Ｃが更新する制御機能が「ワイパー制御」である場合を想定する。
【００７５】
ここで、管理サーバ５が記憶する利用パターンが、「ユーザ３については、晴れの日の走行中にワイパーを利用する可能性が３０％である。」とする。
この場合、管理サーバ５のＣＰＵ５１は、ゲートウェイ１０のダウンロード完了通知に含まれるユーザＩＤが「ユーザ３」であり、現時点の天候が晴れの場合は、対象ＥＣＵ３０Ｃの利用可能性が高いと判定し（ステップＳＴ１３でＮｏ）、対象ＥＣＵ３０Ｃに関する更新の待機要求を送信する（ステップＳＴ１５）。
【００７６】
〔利用パターンの生成処理〕
図７は、管理サーバ５のＣＰＵ５１が実行する、利用パターンの生成処理の一例を示す説明図である。「利用パターンの生成処理」とは、車両１から取得する車両情報、及び管理サーバ５が車両１以外から取得可能な情報（天候、道路種別など）から、所定のＥＣＵ制御機能の利用パターン（利用傾向）を生成する処理である。
【００７７】
図７に示すように、管理サーバ５の記憶部５４には、車両情報データベース５６及び利用パターンデータベース５７が格納されている。
車両情報データベース５６には、複数の「車両情報管理テーブル」が含まれる。この管理テーブルに含める車両情報は、管理サーバ５が車両１のゲートウェイ１０から所定時間（例えば１〜５秒）ごとに受信する通信パケットから抽出される。
【００７８】
車両情報には、各車両１についての、車両識別情報（ＶＩＮ）、ユーザＩＤ、運転状況（駐車／停車／走行のいずれか。）、現在位置、現在時刻、ＯＤ（Origin-Destination）情報（走行経路を含む。）、及びＥＣＵ制御機能ごとの稼働状況（ＯＮ／ＯＦＦのいずれか。）などが含まれる。
１つの車両情報管理テーブルには、１つの車両識別番号に関するユーザＩＤごとの運転状況や現在位置などが含まれる。
【００７９】
管理サーバ５のＣＰＵ５１は、所定の車両識別番号を含む通信パケットをゲートウェイ１０から受信すると、対応する車両識別番号の車両情報管理テーブルに、受信した通信パケットに含まれるユーザＩＤ、運転状況、現在位置及び現在時刻などの情報を蓄積する。蓄積期間は、例えば数ヶ月から１年である。
管理サーバ５のＣＰＵ５１は、データベース５６に蓄積した車両情報に所定の統計処理を実行し、ユーザごとの利用パターンのデータベース５７を生成する。
【００８０】
例えば、ＣＰＵ５１は、車両情報データベース５６に含まれるユーザ１の車両情報管理テーブルから、所定の制御機能（例えば、オートライト）の稼働状況に影響する説明変数を抽出することにより、オートライトに関するユーザ１の利用パターン１を生成する。
【００８１】
また、ＣＰＵ５１は、車両情報データベース５６に含まれるユーザ２の車両情報管理テーブルから、所定の制御機能（例えば、ＬＫＡ）の稼働状況に影響する説明変数を抽出することにより、ＬＫＡに関するユーザ２の利用パターン２を生成する。
更に、ＣＰＵ５１は、車両情報データベース５６に含まれるユーザ３の車両情報管理テーブルから、所定の制御機能（例えば、ワイパー制御）の稼働状況に影響する説明変数を抽出することにより、ワイパー制御に関するユーザ３の利用パターン３を生成する。
【００８２】
〔本実施形態の効果〕
上述の通り、本実施形態の管理サーバ５によれば、記憶部５４が、車両走行時における対象ＥＣＵ３０Ａ〜３０Ｃの制御機能の利用パターンを取得しており、ＣＰＵ５１が、取得した利用パターンに基づいて、対象ＥＣＵ３０Ａ〜３０Ｃによる制御プログラムの更新可否を判定するので、対象ＥＣＵ３０Ａ〜３０Ｃが制御機能を実行しない走行ルートを設定しなくても、車両走行中における制御プログラムの更新可否を適切に判定することができる。
【００８３】
具体的には、ＣＰＵ５１は、取得した利用パターンに基づいて、車両走行中における対象ＥＣＵ３０Ａ〜３０Ｃの利用可能性の多寡を判定し（図６のステップＳＴ１２，ＳＴ１３）、この判定結果に応じて制御プログラムの更新可否を決定する（図６のステップＳＴ１４，ＳＴ１５）。
【００８４】
すなわち、ＣＰＵ５１は、車両走行中における対象ＥＣＵ３０Ａ〜３０Ｃの利用可能性が所定の閾値以下である場合に、制御プログラムの更新が可能であると判定する。
従って、ある制御機能（例えば、上述の「オートライト」、「ＬＫＡ」及び「ワイパー制御」など）をユーザが利用している最中に、当該制御機能に対応する対象ＥＣＵ３０Ａ〜３０Ｃの制御プログラムの更新を勧められることにより、ユーザが不便に感じるのを未然に防止することができる。
【００８５】
本実施形態の管理サーバ５によれば、記憶部５４が記憶する利用パターンに、車両１を運転し得るユーザの識別情報（ユーザ１〜３）ごとに設定された利用パターン１〜３が含まれる（図７参照）。
このため、ＣＰＵ５１が、対象ＥＣＵ３０Ａ〜３０Ｃの制御プログラムの更新可否の判定を、ユーザ１〜３ごとの利用パターン１〜３に基づいて実行できる。従って、各ユーザ１〜３が不便に感じない適切なタイミングで更新処理の実行要求（図５のステップＳ７）を送信することができる。
【００８６】
〔第１の変形例〕
上述の実施形態では、同じ車両１を運転する複数の運転者のユーザＩＤを、スマートキー情報などを利用して定義しているので、ユーザＩＤで識別するユーザは、車両１を実際に運転する人間に限られる。
しかし、ほぼ完全な自動運転が将来的に実用化され得ることを想定すると、ユーザＩＤには、車両１が自動運転である場合の識別情報が含まれていることが好ましい。
【００８７】
例えば、米国の国家道路交通安全局（ＮＨＴＳＡ）が定義する、レベル４の完全自動運転（乗員が行き先を決めるだけで、運転操作を行う必要のない自動運転）の場合には、当該自動運転モードにもユーザＩＤを割り当てることが好ましい。
このようにすれば、自動運転中の車両１についても、利用パターンに基づいてＥＣＵ３０Ａ〜３０Ｃについての制御プログラムの更新可否を決定できるようになる。
【００８８】
〔第２の変形例〕
上述の実施形態では、管理サーバ５は、制御プログラムを更新するか否かを車両１のユーザに問い合わせるために、実行要求を車両１のゲートウェイ１０に送信している（図５のステップＳ７）。
もっとも、タクシー会社やバス会社など、複数の業務用車両を有する企業体の業務用サーバが存在し、この業務用サーバが業務用車両の制御プログラムを一括管理している場合には、実行要求を業務用サーバに送信することにしてもよい。
【００８９】
〔第３の変形例〕
上述の実施形態では、利用パターンに基づいて対象ＥＣＵ３０Ａ〜３０Ｃについての制御プログラムの更新可否を決定する処理を、管理サーバ５のＣＰＵ５１が実行しているが、この処理をゲートウェイ１０のＣＰＵ１１が実行することにしてもよい。すなわち、更新可否の決定の実行主体は、ゲートウェイ１０であってもよい。
この場合、自車両のユーザに関するＥＣＵ３０の制御機能の利用パターンを、ゲートウェイ１０が自身で作成してもよいし、管理サーバ５から受信してもよい。
【００９０】
今回開示した実施形態はすべての点で例示であって制限的なものではない。本発明の権利範囲は、上述の実施形態に限定されるものではなく、特許請求の範囲に記載された構成と均等の範囲内でのすべての変更が含まれる。
【符号の説明】
【００９１】
１  車両
２  広域通信網
５  管理サーバ（制御装置）
６  ＤＬサーバ
１０  ゲートウェイ（制御装置）
１１  ＣＰＵ（制御部）
１２  ＲＡＭ
１３  記憶部（取得部）
１４  車内通信部
１５  無線通信部
３０  ＥＣＵ（車載制御装置）
３０Ａ  対象ＥＣＵ（車載制御装置）
３０Ｂ  対象ＥＣＵ（車載制御装置）
３０Ｃ  対象ＥＣＵ（車載制御装置）
３０Ｄ  情報系ＥＣＵ
３１  ＣＰＵ
３２  ＲＡＭ
３３  記憶部
３４  通信部
３５  起動部
５１  ＣＰＵ（制御部）
５２  ＲＯＭ
５３  ＲＡＭ
５４  記憶部（取得部）
５５  通信部
５６  車両情報データベース
５７  利用パターンデータベース
【図１】
2018069870.tif 000003
【図２】
2018069870.tif 000004
【図３】
2018069870.tif 000005
【図４】
2018069870.tif 000006
【図５】
2018069870.tif 000007
【図６】
2018069870.tif 000008
【図７】
2018069870.tif 000009