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

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 (10)

1. 車両に搭載された対象機器を制御する車載制御装置の、前記対象機器の制御のための制御プログラムの更新を制御する制御装置であって、
   前記車両の駐停車時間を予測し、予測時間である第１の時間を得る予測部と、
   前記第１の時間に基づいて前記制御プログラムの更新に関する処理を制御する更新制御部と、
   前記駐停車時間の予測用の情報として前記車両の状態を表す情報を取得する情報取得部と、を備え、
   前記予測部は、前記予測用の情報と、予め記憶している予測条件として前記車両の走行状態の蓄積に基づいて得られる走行モデルとを用いて前記第１の時間を得る、制御装置。
2. 前記予測用の情報は、前記車両の駐停車位置と駐停車時とのうちの少なくとも１つを含む、請求項１に記載の制御装置。
3. 前記情報取得部は、駐停車直前の前記車両の状態として予め規定されている停車前状態が検知されたタイミングで、前記車両の状態を表す情報を前記予測用の情報として取得する、請求項１または請求項２に記載の制御装置。
4. 前記車両の走行状態の蓄積に基づいて、前記走行モデルを生成するモデル生成部をさらに備える、請求項１〜請求項３のいずれか１項に記載の制御装置。
5. 前記更新制御部は、前記制御プログラムの更新に関する処理に要する時間である第２の時間と前記第１の時間との比較結果に基づいて前記制御プログラムの更新に関する処理を制御する、請求項１〜請求項４のいずれか一項に記載の制御装置。
6. 前記第２の時間を取得する更新時間取得部と、
   前記第１の時間と前記第２の時間とを比較することで、前記制御プログラムの更新に関する処理の実行の可否を判定する判定部と、をさらに備える、請求項５に記載の制御装置。
7. 前記判定部は、さらに、前記車両に搭載されている装置の状態に基づいて前記制御プログラムの更新に関する処理の実行の可否を判定する、請求項６に記載の制御装置。
8. 前記更新制御部は、前記制御プログラムの更新に関する処理として、前記制御プログラムの更新を通知する、請求項１〜請求項７のいずれか一項に記載の制御装置。
9. 車両に搭載された対象機器を制御する車載制御装置の、前記対象機器の制御のための制御プログラムの更新方法であって、
   前記車両の駐停車時間を予測し、予測時間である第１の時間を得るステップと、
   前記第１の時間に基づいて前記制御プログラムの更新に関する処理を制御するステップと、
   前記駐停車時間の予測用の情報として前記車両の状態を表す情報を取得するステップと、を備え、
   前記第１の時間を得るステップは、前記予測用の情報と、予め記憶している予測条件として前記車両の走行状態の蓄積に基づいて得られる走行モデルとを用いて前記第１の時間を得ることを含む、プログラム更新方法。
10. 車両に搭載された対象機器を制御する車載制御装置の、前記対象機器の制御のための制御プログラムの更新を制御する制御装置としてコンピュータを機能させるためのコンピュータプログラムであって、前記コンピュータを、
    前記車両の駐停車時間を予測し、予測時間である第１の時間を得る予測部と、
    前記第１の時間に基づいて前記制御プログラムの更新に関する処理を制御する更新制御部と、
    前記駐停車時間の予測用の情報として前記車両の状態を表す情報を取得する情報取得部、として機能させ、
    前記予測部は、前記予測用の情報と、予め記憶している予測条件として前記車両の走行状態の蓄積に基づいて得られる走行モデルとを用いて前記第１の時間を得る、コンピュータプログラム。

Images