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

Abstract

車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する制御装置であって、前記制御プログラムの更新のためのメンテナンス予定を取得する取得部と、前記メンテナンスの開始時に基づいて前記制御プログラムの更新用プログラムのダウンロードの開始時を決定する決定部と、前記更新用プログラムのダウンロードを制御する制御部と、を備え、前記制御部は、前記決定部によって決定された開始時に前記更新用プログラムのダウンロードを開始する、制御装置。

Description

この発明は制御装置、プログラム更新方法、およびコンピュータプログラムに関する。
本出願は、２０１７年２月１日出願の日本出願第２０１７−０１６５４５号に基づく優先権を主張し、前記日本出願に記載された全ての記載内容を援用するものである。

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

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

たとえば、特許文献１には、外部センターからダウンロードした更新用プログラムを車両に搭載されている中継装置に蓄積しておき、所定の指令に基づいて車両の各ＥＣＵに対するプログラム更新が実行される技術が開示されている。

国際公開第２０１５／１９４６５２号公報

ある実施の形態に従うと、制御装置は車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する制御装置であって、制御プログラムの更新のためのメンテナンス予定を取得する取得部と、メンテナンスの開始時に基づいて制御プログラムの更新用プログラムのダウンロードの開始時を決定する決定部と、更新用プログラムのダウンロードを制御する制御部と、を備え、制御部は、決定部によって決定された開始時に更新用プログラムのダウンロードを開始する。

他の実施の形態に従うと、プログラム更新方法は車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新方法であって、制御プログラムの更新のためのメンテナンス予定を取得するステップと、メンテナンスの開始時に基づいて制御プログラムの更新用プログラムのダウンロードの開始時を決定するステップと、更新用プログラムのダウンロードを制御するステップと、を備え、ダウンロードを制御するステップは、ダウンロードの開始時を決定するステップによって決定された開始時に更新用プログラムのダウンロードを開始することを含む。

他の実施の形態に従うと、コンピュータプログラムは車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する制御装置としてコンピュータを機能させるためのコンピュータプログラムであって、コンピュータを、制御プログラムの更新のためのメンテナンス予定を取得する取得部、メンテナンスの開始時に基づいて制御プログラムの更新用プログラムのダウンロードの開始時を決定する決定部、および、更新用プログラムのダウンロードを制御する制御部、として機能させ、制御部は、決定部によって決定された開始時に更新用プログラムのダウンロードを開始する。

図１は、実施形態に係るプログラム更新システムの全体構成図である。 図２は、ゲートウェイの内部構成を示すブロック図である。 図３は、ＥＣＵの内部構成を示すブロック図である。 図４は、管理サーバの内部構成を示すブロック図である。 図５は、第１の実施形態のプログラム更新システムにおいて実行される、制御プログラムの更新の一例を示すシーケンス図である。 図６は、図５のステップＳ２のスケジュール決定処理の具体的な内容を表したフローチャートである。 図７は、第１の実施の形態にかかるプログラム更新システムでの、制御プログラムの更新の時間関係の一例（Ａ）と、比較例としての制御プログラムの更新の時間関係の一例（Ｂ）と、を表した図である。 図８は、第２の実施の形態にかかるプログラム更新システムにおいて実行される、制御プログラムの更新の一例を示すシーケンス図である。 図９は、第３の実施の形態でのスケジュール決定処理の一例を表したフローチャートである。

＜本開示が解決しようとする課題＞
プログラムの更新を実行させる所定の指令の一例として、ディーラーにおけるメンテナンス時に入力される書き換え開始の指令が挙げられる。この場合、ディーラーでのメンテナンスの開始後に更新用プログラムのダウンロードが開始されると、ディーラーでのメンテナンス時間が長くなり、ユーザによっては不便を感じることがある。一方で、メンテナンスの開始よりも長期間以前に更新用プログラムをダウンロードしておくと、更新用プログラムが中継装置に長期間蓄積されるために、メモリが圧迫されてしまう。

本開示のある局面における目的は、ディーラーでのメンテナンスの開始時を考慮して適切なタイミングに制御プログラムの更新用プログラムをダウンロードすることができる制御装置、プログラム更新方法、およびコンピュータプログラムを提供することである。

＜本開示の効果＞
この開示によると、ディーラーでのメンテナンスの開始時を考慮して適切なタイミングに制御プログラムの更新用プログラムをダウンロードすることができる。

［実施の形態の説明］
本実施の形態には、少なくとも以下のものが含まれる。
すなわち、本実施の形態に含まれる制御装置は車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する制御装置であって、制御プログラムの更新のためのメンテナンス予定を取得する取得部と、メンテナンスの開始時に基づいて制御プログラムの更新用プログラムのダウンロードの開始時を決定する決定部と、更新用プログラムのダウンロードを制御する制御部と、を備え、制御部は、決定部によって決定された開始時に更新用プログラムのダウンロードを開始する。
メンテナンスの開始時に基づいて更新用プログラムのダウンロードの開始時が決定されるため、サーバから更新用プログラムのダウンロードが要求された場合であっても、メンテナンスの開始時に基づいたタイミングで更新用プログラムがダウンロードされる。そのため、この構成によれば、メンテナンスの開始時を考慮して適切なタイミングに制御プログラムの更新用プログラムをダウンロードすることができる。

好ましくは、決定部は、少なくともメンテナンスの開始前に更新用プログラムのダウンロードを開始するように更新用プログラムのダウンロードの開始時を決定する。
これにより、メンテナンスの開始後に更新用プログラムのダウンロードを開始する場合と比較してメンテナンスの総時間を短縮化できる。

好ましくは、取得部は、更新用プログラムのダウンロード所要時間をさらに取得し、決定部は、メンテナンスの開始前に更新用プログラムのダウンロードが完了するように更新用プログラムのダウンロードの開始時を決定する。
これにより、メンテナンスの開始時にはすでに更新用プログラムのダウンロードが完了しており、メンテナンスの開始後に更新用プログラムのダウンロードを行う時間が不要となる。そのため、メンテナンス中に更新用プログラムをダウンロードする場合と比較してメンテナンスの総時間を短縮化できる。

好ましくは、決定部は、更新用プログラムのダウンロードの完了からメンテナンスの開始までの期間が規定時間以下となるように更新用プログラムのダウンロードの開始時を決定する。
これにより、ダウンロードの完了からメンテナンスの開始までの、更新用プログラムがメモリに保管される期間を短くすることができる。そのため、メモリの長期間の圧迫を回避できる。

好ましくは、決定部は、更新用プログラムのダウンロード期間に他の制御プログラムの更新のためのメンテナンスの開始時が含まれる場合、更新用プログラムのダウンロードを待機する。
これにより、メンテナンス中に他の更新用プログラムのダウンロードが行われることがない。そのため、当該他の更新用プログラムのダウンロードによってメンテナンス用のメモリまで圧迫されることが回避され、メンテナンスに生じ得る支障を回避できる。

好ましくは、更新用プログラムを記憶するためのメモリをさらに含み、決定部は、更新用プログラムのダウンロード期間に他の制御プログラムの更新のためのメンテナンスの開始時が含まれ、かつ、メモリの空き容量が予め規定された容量未満である場合に、更新用プログラムのダウンロードを待機する。
これにより、メモリの空き容量が予め規定された容量以上である場合には、必要に応じて他の更新用プログラムのダウンロードが行われる。そのため、当該他の更新用プログラムを用いた制御プログラムの更新のためのメンテナンスの総時間を短縮化することができる。

好ましくは、車載制御装置にバックアップ用メモリが含まれる場合、制御部は、更新用プログラムのバックアップ用メモリへの書き込みを制御し、決定部は、メンテナンスの開始前に更新用プログラムのダウンロードが完了し、かつ更新用プログラムのバックアップ用メモリへの書き込みが完了するように更新用プログラムのダウンロードの開始時を決定する。
これにより、メンテナンスの開始時には車載制御装置のバックアップ用メモリに更新用プログラムの書き込みが完了している。そのため、制御プログラムの更新のためのメンテナンスは再起動してバックアップ用メモリと動作用メモリとを切り替える作業のみでよく、バックアップ用メモリに更新用プログラムを書き込む作業を行う場合と比較して制御プログラムの更新のためのメンテナンスの総時間をより短縮化することができる。

本実施の形態に含まれるプログラム更新方法は車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新方法であって、制御プログラムの更新のためのメンテナンス予定を取得するステップと、メンテナンスの開始時に基づいて制御プログラムの更新用プログラムのダウンロードの開始時を決定するステップと、更新用プログラムのダウンロードを制御するステップと、を備え、ダウンロードを制御するステップは、ダウンロードの開始時を決定するステップによって決定された開始時に更新用プログラムのダウンロードを開始することを含む。
メンテナンスの開始時に基づいて更新用プログラムのダウンロードの開始時が決定されるため、サーバから更新用プログラムのダウンロードが要求された場合であっても、メンテナンスの開始時に基づいたタイミングで更新用プログラムがダウンロードされる。そのため、この構成によれば、メンテナンスの開始時を考慮して適切なタイミングに制御プログラムの更新用プログラムをダウンロードすることができる。

本実施の形態に含まれるコンピュータプログラムは車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する制御装置としてコンピュータを機能させるためのコンピュータプログラムであって、コンピュータを、制御プログラムの更新のためのメンテナンス予定を取得する取得部、メンテナンスの開始時に基づいて制御プログラムの更新用プログラムのダウンロードの開始時を決定する決定部、および、更新用プログラムのダウンロードを制御する制御部、として機能させ、制御部は、決定部によって決定された開始時に更新用プログラムのダウンロードを開始する。
メンテナンスの開始時に基づいて更新用プログラムのダウンロードの開始時が決定されるため、サーバから更新用プログラムのダウンロードが要求された場合であっても、メンテナンスの開始時に基づいたタイミングで更新用プログラムがダウンロードされる。そのため、この構成によれば、メンテナンスの開始時を考慮して適切なタイミングに制御プログラムの更新用プログラムをダウンロードすることができる。

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

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

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

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

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

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

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

ＣＰＵ１１が実現するコンピュータプログラムは、ＣＤ−ＲＯＭまたはＤＶＤ−ＲＯＭなどの周知の記録媒体に記録した状態で譲渡することもできるし、サーバコンピュータなどのコンピュータ装置からの情報伝送（ダウンロード）によって譲渡することもできる。
この点は、後述のＥＣＵ３０のＣＰＵ３１（図３参照）が実行するコンピュータプログラム、および、後述の管理サーバ５のＣＰＵ５１（図４参照）が実行するコンピュータプログラムについても同様である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＥＣＵの制御プログラムを更新するタイミングに達すると、管理サーバ５は、該当する車両１のゲートウェイ１０宛てに、ＥＣＵ３０の更新用プログラムの保存先ＵＲＬとダウンロード要求とを送信する（ステップＳ１）。

管理サーバ５から更新要求を受信したゲートウェイ１０は、当該制御プログラムの更新のための更新用プログラムをダウンロードするスケジュールを決定する処理を実行する（ステップＳ２）。ステップＳ２でゲートウェイ１０は、ディーラーに入庫して当該制御プログラムの更新のためのメンテナンスを開始する予定時刻（以下、メンテナンス予定とも称する）に基づいて更新用プログラムをダウンロードするスケジュール（開始時刻）を決定する。メンテナンス予定は、車両１のディーラーへの入庫日時であってもよい。当該処理の詳細は、後述する。そして、ゲートウェイ１０は、当該スケジュールに規定されたタイミングでＥＣＵ３０のための更新用プログラムをＤＬサーバ６からダウンロードする（ステップＳ３，４）。ゲートウェイ１０は、受信した更新用プログラムを自装置の記憶部１３に格納して保存する（ステップＳ５）。

ゲートウェイ１０は、更新用プログラムのダウンロードが完了し、ステップＳ５で記憶部１３に格納すると、ダウンロードの完了を管理サーバ５に通知する（ステップＳ６）。これにより、管理サーバ５は、当該制御プログラムの車両１に対する更新用プログラムの配信を管理することができる。また、ステップＳ１から所定期間のうちのダウンロードの完了が通知されない場合、管理サーバ５は、再度、当該更新用プログラムを車両１に配信する。

ステップＳ４のダウンロードが開始した後、車両１はディーラーに入庫し、メンテナンスが開始する。ディーラーでのメンテナンスにおいて、ゲートウェイ１０には、携帯端末などの図示しない装置が接続されて当該装置がゲートウェイ１０と直接、または無線通信部１５を介して通信を行い、ゲートウェイ１０に対して更新開始の指令を渡す。

当該指令を受けたゲートウェイ１０は、対象のＥＣＵ３０に更新用プログラムを渡して制御プログラムの更新を要求する（ステップＳ７）。当該要求に従って、ＥＣＵ３０では制御プログラムの更新が行われる（ステップＳ８）。上記ステップＳ４，５ですでに更新用プログラムのダウンロードが完了し、ゲートウェイ１０の記憶部１３に格納されているため、ステップＳ８では当該更新用プログラムを用いて更新処理を行うのみでよく、ダウンロードから開始する場合に比べて短期に制御プログラムの更新を完了することができる。

なお、上記ステップＳ６のダウンロード完了の通知に替えて、または該通知に加えて、更新の完了が管理サーバ５に通知されてもよい。これにより、管理サーバ５は、車両１における制御プログラムの更新を管理することができる。また、ステップＳ１から所定期間のうちの更新の完了が通知されない場合、管理サーバ５は、再度、当該更新用プログラムを車両１に配信することで、車両１において当該制御プログラムの更新を確実に行うことができる。

〔ゲートウェイの機能構成〕
ゲートウェイ１０のＣＰＵ１１は、更新用プログラムをダウンロードするスケジュールを決定し、該スケジュールに従ってダウンロードを実行するための機能として、図２において取得部１１１、決定部１１２、および制御部１１３と表された機能を含む。これら機能は、ＣＰＵ１１が記憶部１３に記憶されている１つまたは複数のプログラムを読み出して実行することによって、ＣＰＵ１１において実現される機能である。しかしながら、少なくとも一部機能が、電子回路などのハードウェアによって実現されてもよい。

取得部１１１で表されたＣＰＵ１１の機能（以下、取得部１１１）は、当該車両１のメンテナンス予定を取得する。車両１についてのメンテナンス予定は、該車両１のユーザが管理サーバ５に登録しておくものであってもよい。この場合、取得部１１１は管理サーバ５からメンテナンス予定を取得する。

メンテナンス予定は、ユーザに問い合わせてもよい。この場合、一例として取得部１１１はユーザの携帯電話機、スマートフォン、タブレット型端末、ノートＰＣなどと通信し、ユーザにメンテナンス予定の入力を促してもよい。取得部１１１は携帯電話機などからユーザの入力を受け付けることによって、メンテナンス予定を取得する。

また、取得部１１１は、更新用プログラムのダウンロードに要する時間（以下、ＤＬ所要時間と称する）Ｔｄを取得する。ＤＬ所要時間Ｔｄは、管理サーバ５から取得してもよい。一例として、上記ステップＳ１で管理サーバ５から更新用プログラムのダウンロードが要求される際に、ダウンロードに必要な情報としてＤＬ所要時間Ｔｄがゲートウェイ１０に渡されてもよい。または、取得部１１１が、管理サーバ５から更新用プログラムのダウンロードに必要な情報として渡されたデータサイズの情報を用いて、ＤＬ所要時間Ｔｄを算出してもよい。

決定部１１２で表されたＣＰＵ１１の機能（以下、決定部１１２）は、取得部１１１によって取得されたメンテナンス予定とＤＬ所要時間Ｔｄとに基づいて、更新用プログラムのダウンロードの開始時刻を決定する。このとき、決定部１１２は、少なくともメンテナンス開始よりも以前にダウンロードが開始するようにダウンロードの開始時刻を決定する。これにより、メンテナンス開始後にダウンロードに要する時間を抑えることができ、メンテナンス時間全体を短縮化することができるためである。

好ましくは、決定部１１２は、メンテナンス開始よりも以前にダウンロードが完了するようにダウンロードの開始時を決定する。ダウンロードの開始時は、たとえば、ダウンロードの開始時刻である。その他、開始日時、予め規定されたイベントまたはタイミングからの経過時間などの開始のタイミング、などであってもよい。これにより、メンテナンス開始時にすでに制御プログラムのダウンロードが完了しているためにメンテナンス開始後にダウンロードする時間を不要とすることができる。そのため、メンテナンス時間全体をより短縮化することができるためである。

より好ましくは、決定部１１２は、ダウンロードの完了後、記憶部１３に格納されてメンテナンス開始時まで保管される期間（以下、保管期間と称する）Ｔｓが、予め規定された時間Ｔｈよりも短くなるよう（Ｔｓ≦Ｔｈ）にダウンロードの開始時刻を決定する。たとえば、保管期間Ｔｓが規定時間Ｔｈ（Ｔｓ＝Ｔｈ）となるようにダウンロードの開始時刻を決定する。規定時間Ｔｈは、たとえば数分〜数１０分程度である。これにより、メンテナンス時間全体をより短縮化することができるとともに、メンテナンス開始までのメモリの圧迫を短期間に抑えることができる。

制御部１１３で表されたＣＰＵ１１の機能（以下、制御部１１３）は、決定部１１２によって決定されたタイミングで更新用プログラムのダウンロードを開始するように制御する。具体的には、制御部１１３は、決定部１１２によって決定されたタイミングでＤＬサーバ６に対して更新用プログラムを要求する。そして、ダウンロードされた更新用プログラムを記憶部１３に格納する。

〔スケジュール決定処理〕
図６は、図５のステップＳ２のスケジュール決定処理の具体的な内容を表したフローチャートである。図６のフローチャートに表された処理は、当該ゲートウェイ１０のＣＰＵ１１が記憶部１３に記憶された１つまたは複数のプログラムをＲＡＭ１２上に読み出して実行することによって、主にＣＰＵ１１により実現される。図６の処理は、上記ステップＳ１で管理サーバ５から制御プログラムの更新が要求されると開始する。

図６を参照して、はじめに、ゲートウェイ１０のＣＰＵ１１はメンテナンス予定を取得する（ステップＳ１０１）。また、ＣＰＵ１１は、要求された制御プログラムの更新に用いる更新用プログラムのＤＬ所要時間Ｔｄを取得する（ステップＳ１０３）。そして、ＣＰＵ１１は、メンテナンス予定とＤＬ所要時間Ｔｄとに基づいて、当該更新用プログラムのダウンロードのスケジュールを決定する（ステップＳ１０５）。ステップＳ１０５では、一例として、メンテナンスの開始時刻よりも規定時間Ｔｈ前にダウンロードが完了するように、メンテナンスの開始時刻の規定時間ＴｈおよびＤＬ所要時間Ｔｄの期間、以前に当該更新用プログラムのダウンロードを開始するとスケジュールを決定する。

その後、ＣＰＵ１１は、決定したダウンロードの開始時刻になるまで待機し、当該時刻になると（ステップＳ１０７でＹＥＳ）、ダウンロードを開始する（ステップＳ１０９）。

〔第１の実施の形態の効果〕
第１の実施の形態にかかるプログラム更新システムでは、少なくともメンテナンスの開始時刻よりも前に制御プログラムの更新に必要な更新用プログラムのダウンロードが開始される。そのため、メンテナンスが開始してから更新用プログラムのダウンロードを開始するよりもメンテナンス開始後のダウンロード時間を抑えることができる。その結果、メンテナンスの総時間を抑えることができる。

好ましくは、第１の実施の形態にかかるプログラム更新システムでは、少なくともメンテナンスの開始時刻よりも前に更新用プログラムのダウンロードが完了する。そのため、メンテナンスが開始してから更新用プログラムのダウンロードが行われることなく、直ちに制御プログラムの更新を実行することができる。その結果、メンテナンスの総時間をより抑えることができる。

より好ましくは、第１の実施の形態にかかるプログラム更新システムでは、メンテナンスの開始時刻よりも前であって、ダウンロード完了後からメンテナンス開始までの保管期間が規定時間以下となるタイミングで更新用プログラムのダウンロードが完了する。そのため、メンテナンスが開始してから更新用プログラムのダウンロードが行われることなく、直ちに制御プログラムの更新を実行することができる。また、ダウンロード完了後、メンテナンスの開始までの期間が規定時間以下となり、保管期間を短くすることができる。その結果、メンテナンスの総時間をより抑えることができるとともに、メモリを圧迫する期間を抑えることもできる。

図７（Ａ）は、第１の実施の形態にかかるプログラム更新システムでの、制御プログラムの更新の時間関係の一例を表した図である。図７（Ａ）を参照して、本実施の形態にかかるプログラム更新システムでは、一例として、メンテナンス開始時刻Ｔ３よりも前の時刻Ｔｓ１に更新用プログラムのダウンロードが完了するように、メンテナンス開始時刻Ｔ３から保管期間Ｔｓ１およびＤＬ所要時間Ｔｄ前の時刻Ｔ２に更新用プログラムのダウンロードを開始する。言い換えると、ダウンロードの開始のタイミングが図７（Ａ）の場合、管理サーバ５から更新用プログラムのダウンロードを要求された時刻Ｔ１の後、時刻Ｔ２に達するまで更新用プログラムをダウンロードせず、時刻Ｔ２でダウンロードを開始する。そして、その後の時刻Ｔ３にメンテナンスが開始する。これにより、メンテナンス開始後にダウンロードが開始する場合に比べてメンテナンスの総時間を抑えることができる。

これに対して、図７（Ｂ）は比較例として、メンテナンス開始時刻Ｔ３の直後の時刻Ｔ４に更新用プログラムのダウンロードを開始する場合の時間関係の一例を表した図である。図７（Ｂ）を参照して、ダウンロードの開始のタイミングが図７（Ｂ）の場合、メンテナンス開始時刻Ｔ３よりも以前にダウンロードは完了するため、図７（Ａ）の例と同様に、メンテナンス開始後にダウンロードが開始する場合に比べてメンテナンスの総時間を抑えることができる。しかしながら、ダウンロード完了後に更新用プログラムが記憶部１３に格納されている保管期間Ｔｓ２が、図７（Ａ）の場合の保管期間Ｔｓ１と比較して大幅に長くなる。そのため、図７（Ｂ）の例では、当該更新用プログラムによってゲートウェイ１０のメモリが圧迫される期間が長くなってしまう。従って、図７（Ａ）のようなタイミングで更新用プログラムをダウンロードすることによって、更新用プログラムによってゲートウェイ１０のメモリが圧迫される期間を抑えることができる。

＜第２の実施の形態＞
図３に点線で表されたように、ＥＣＵ３０の記憶部３３に、プログラムを格納するための領域である機能用メモリ３３１と、プログラムのバックアップ用の保管用メモリ３３２とが含まれてもよい。

この場合、ＥＣＵ３０における制御プログラムの更新は、旧プログラムに更新用プログラムを適用することで生成された新プログラムを保管用メモリ３３２に書き込む処理、および、ＥＣＵ３０を再起動することによって旧プログラムを保持している機能用メモリ３３１と新プログラムが書き込まれた保管用メモリ３３２との機能を入れ替える処理、からなる。そして、第２の実施の形態にかかるプログラム更新システムでは、ディーラーでのメンテナンスの際に更新の指令を受け付けて、上記の再起動が行われ、機能用メモリ３３１と保管用メモリ３３２とが入れ替えられる。

図８は、第２の実施の形態にかかるプログラム更新システムにおいて実行される、制御プログラムの更新の一例を示すシーケンス図である。図８において、図５に示されたシーケンスと同じ動作については同じステップ番号が付加されている。ここでは、図５に示されたシーケンスと同じ動作については説明を繰り返さない。

図８を参照して、第２の実施の形態にかかるプログラム更新システムでは、管理サーバ５から更新要求を受信したゲートウェイ１０は、ステップＳ２のスケジュールを決定する処理において、さらに、ＥＣＵ３０での更新用プログラムの保管用メモリ３３２への書き込みの所要時間を特定して、メンテナンスの開始時刻までに更新用プログラムのダウンロードが完了し、かつ、当該更新用プログラムのＥＣＵ３０での書き込みが完了するようにダウンロードするスケジュール（開始時刻）を決定する。好ましくは、ゲートウェイ１０は、ステップＳ２の処理において、該更新用プログラムのＥＣＵ３０での書き込みの完了からメンテナンスの開始時刻までの保管期間が規定時間Ｔｈよりも短くなるようにダウンロードするスケジュールを決定する。

ゲートウェイ１０は、当該スケジュールに規定されたタイミングでＥＣＵ３０のための更新用プログラムをＤＬサーバ６からダウンロードする（ステップＳ３，４）。更新用プログラムのダウンロードが完了すると、ゲートウェイ１０は対象のＥＣＵ３０に対して更新用プログラムを渡して当該更新用プログラムの書き込みを要求する（ステップＳ１５）。当該要求に従って、対象のＥＣＵ３０では、受け取った更新用プログラムに基づいた新プログラムが保管用メモリ３３２に書き込まれる（ステップＳ１６）。

第２の実施の形態にかかるプログラム更新システムでは、新プログラムが保管用メモリ３３２に書き込まれた後に、ディーラーでのメンテナンスが開始する。そして、メンテナンスにおいてゲートウェイ１０に対して更新の指令が渡され、ゲートウェイ１０は、対象のＥＣＵ３０に更新用プログラムを渡して制御プログラムの更新を要求する（ステップＳ７）。第２の実施の形態にかかるプログラム更新システムでは、当該要求に従って、ＥＣＵ３０が再起動し（ステップＳ１７）、旧プログラムを保持している機能用メモリ３３１と新プログラムが書き込まれた保管用メモリ３３２との機能を入れ替える。

〔第２の実施の形態の効果〕
第２の実施の形態にかかるプログラム更新システムでは、ＥＣＵ３０が記憶部３３に保管用メモリ３３２を有する。そのため、ディーラーでのメンテナンス開始よりも前に、新プログラムの保管用メモリ３３２への書き込みまで完了させておく。これにより、メンテナンス開始後に新プログラムの保管用メモリ３３２への書き込みを行うことなく、再起動のみによって制御プログラムの更新が完了する。その結果、メンテナンスの総時間をより抑えることができる。

＜第３の実施の形態＞
第３の実施の形態にかかるプログラム更新システムにおいて、ゲートウェイ１０は、上記ステップＳ２のスケジュール決定処理において、さらに、異なる制御プログラムの更新のためのメンテナンス予定に基づいて、ダウンロードが当該メンテナンス期間と重複しないようにダウンロードの開始を決定してもよい。ディーラーにおいてある制御プログラムの更新のためのメンテナンスを行っているときに、他の制御プログラムの更新用プログラムがダウンロードされることによってメンテナンス用のメモリまで圧迫され、メンテナンスに支障が生じることを回避するためである。

図９は、第３の実施の形態でのスケジュール決定処理を表したフローチャートである。図９において、図６のフローチャートと同じステップ番号が付された処理は、第１の実施の形態でのスケジュール決定処理での当該ステップ番号が付された処理と同じである。そのため、ここでの説明は繰り返さない。

第３の実施の形態にかかるゲートウェイ１０のＣＰＵ１１は、管理サーバ５から更新を要求された制御プログラムとは異なる制御プログラムの更新のためのメンテナンス予定を取得する。そして、ＣＰＵ１１は、第１の実施の形態と同様の処理を行って更新用プログラムのダウンロードのタイミングを決定した後（ステップＳ１０１〜Ｓ１０５）、当該タイミングに開始したダウンロード期間中に他の制御プログラムの更新のためのメンテナンス開始時刻が含まれるか否かを確認する。

ダウンロード期間中に他の制御プログラムの更新のためのメンテナンスが開始される場合（ステップＳ２０１でＹＥＳ）、当該更新用プログラムのダウンロードの開始時刻となっても、当該他のメンテナンスの完了までダウンロードを開始せずに待機する（ステップＳ２０５でＮＯ）。そして、当該他のメンテナンスが完了すると（ステップＳ２０５でＹＥＳ）、当該更新用プログラムのダウンロードを開始する（ステップＳ１０９）。

第３の実施の形態にかかるプログラム更新システムでは、更新用プログラムのダウンロードが管理サーバ５から要求されても、当該更新用プログラムのダウンロード期間がメンテナンス期間と重複する場合には、少なくともメンテナンス期間よりも後に当該更新用プログラムのダウンロードが開始される。そのため、メンテナンス中にダウンロードが行われることなく、メンテナンスにダウンロードによる支障が生じることを回避できる。

なお、第３の実施の形態において、ゲートウェイ１０のメモリに余裕がある場合には、メンテナンス中に他の更新用プログラムがダウンロードされてもメンテナンスに支障が生じない場合もある。そこで、好ましくは、図９を参照して、ゲートウェイ１０のＣＰＵ１１は、ダウンロード期間中に他の制御プログラムの更新のためのメンテナンスが開始される場合であっても（ステップＳ２０１でＹＥＳ）、ゲートウェイ１０のメモリの空き容量が予め規定された容量以上である場合には（ステップＳ２０３でＹＥＳ）、決定されたスケジュールに従って更新用プログラムのダウンロードを開始してもよい（ステップＳ１０９）。言い換えると、ダウンロード期間中に他の制御プログラムの更新のためのメンテナンスが開始され（ステップＳ２０１でＹＥＳ）、かつ、ゲートウェイ１０のメモリの空き容量が予め規定された容量未満である場合に（ステップＳ２０３でＮＯ）、当該他のメンテナンスの完了までダウンロードを開始せずに待機する（ステップＳ２０５でＮＯ）。

＜第４の実施の形態＞
第１〜第３の実施の形態にかかるプログラム更新システムでは、更新用プログラムをダウンロードするスケジュールを決定する処理をゲートウェイ１０で行うものとしている。しかしながら、該スケジュール決定処理はゲートウェイ１０とは異なる装置で行われてもよい。他の例として、管理サーバ５によって行われてもよい。

一例として、第４の実施の形態にかかるプログラム更新システムでは、管理サーバ５は図５のステップＳ１で制御プログラムの更新を車両１に対して要求するに当たって当該車両１のメンテナンス予定に基づいて更新用プログラムをダウンロードするスケジュールを決定する。そして、管理サーバ５は、決定したタイミングで更新用プログラムのダウンロードを車両１のゲートウェイ１０に要求する。この場合、ゲートウェイ１０では、更新を要求されたタイミングで更新用プログラムをダウンロードし、対象のＥＣＵ３０に更新を要求する。

この場合、図４に表わされたように、管理サーバ５のＣＰＵ５１が更新用プログラムをダウンロードするスケジュールを決定するための機能として、上記の決定部１１２に相当する決定部５１１、および制御部１１３に相当する制御部５１２を有する。これらの機能は、ＣＰＵ５１がＲＯＭ５２に記憶されている１つまたは複数のプログラムを読み出して実行することによって、主にＣＰＵ５１によって実現される。しかしながら、少なくとも一部機能が電気回路などのハードウェアによって実現されてもよい。

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

１ 車両
２ 広域通信網
５ 管理サーバ
６ サーバ
１０ ゲートウェイ
１５ 無線通信部
３０ ＥＣＵ
１１，３１，５１ ＣＰＵ
１２，３２，５３ ＲＡＭ
１３，３３，５４ 記憶部
１４ 車内通信部
３４，５５ 通信部
３５ 起動部
５２ ＲＯＭ
１１１ 取得部
１１２ 決定部
１１３ 制御部
１３１，３３２ 保管用メモリ
３３１ 機能用メモリ
５１１ 決定部
５１２ 制御部

Claims (9)

1. 車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する制御装置であって、
   前記制御プログラムの更新のためのメンテナンス予定を取得する取得部と、
   前記メンテナンスの開始時に基づいて前記制御プログラムの更新用プログラムのダウンロードの開始時を決定する決定部と、
   前記更新用プログラムのダウンロードを制御する制御部と、を備え、
   前記制御部は、前記決定部によって決定された開始時に前記更新用プログラムのダウンロードを開始する、制御装置。
2. 前記決定部は、少なくとも前記メンテナンスの開始前に前記更新用プログラムのダウンロードを開始するように前記更新用プログラムのダウンロードの開始時を決定する、請求項１に記載の制御装置。
3. 前記取得部は、前記更新用プログラムのダウンロード所要時間をさらに取得し、
   前記決定部は、前記メンテナンスの開始前に前記更新用プログラムのダウンロードが完了するように前記更新用プログラムのダウンロードの開始時を決定する、請求項２に記載の制御装置。
4. 前記決定部は、前記更新用プログラムのダウンロードの完了から前記メンテナンスの開始までの期間が規定時間以下となるように前記更新用プログラムのダウンロードの開始時を決定する、請求項３に記載の制御装置。
5. 前記決定部は、前記更新用プログラムのダウンロード期間に他の制御プログラムの更新のためのメンテナンスの開始時が含まれる場合、前記更新用プログラムのダウンロードを待機する、請求項１〜請求項４のいずれか一項に記載の制御装置。
6. 前記更新用プログラムを記憶するためのメモリをさらに含み、
   前記決定部は、前記更新用プログラムのダウンロード期間に他の制御プログラムの更新のためのメンテナンスの開始時が含まれ、かつ、前記メモリの空き容量が予め規定された容量未満である場合に、前記更新用プログラムのダウンロードを待機する、請求項５に記載の制御装置。
7. 前記車載制御装置にバックアップ用メモリが含まれる場合、前記制御部は、前記更新用プログラムの前記バックアップ用メモリへの書き込みを制御し、
   前記決定部は、前記メンテナンスの開始前に前記更新用プログラムのダウンロードが完了し、かつ前記更新用プログラムの前記バックアップ用メモリへの書き込みが完了するように前記更新用プログラムのダウンロードの開始時を決定する、請求項３に記載の制御装置。
8. 車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新方法であって、
   前記制御プログラムの更新のためのメンテナンス予定を取得するステップと、
   前記メンテナンスの開始時に基づいて前記制御プログラムの更新用プログラムのダウンロードの開始時を決定するステップと、
   前記更新用プログラムのダウンロードを制御するステップと、を備え、
   前記ダウンロードを制御するステップは、前記ダウンロードの開始時を決定するステップによって決定された開始時に前記更新用プログラムのダウンロードを開始することを含む、プログラム更新方法。
9. 車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する制御装置としてコンピュータを機能させるためのコンピュータプログラムであって、前記コンピュータを、
   前記制御プログラムの更新のためのメンテナンス予定を取得する取得部、
   前記メンテナンスの開始時に基づいて前記制御プログラムの更新用プログラムのダウンロードの開始時を決定する決定部、および
   前記更新用プログラムのダウンロードを制御する制御部、として機能させ、
   前記制御部は、前記決定部によって決定された開始時に前記更新用プログラムのダウンロードを開始する、コンピュータプログラム。

Images