JPWO2018079006A1 - 制御装置、プログラム更新方法、およびコンピュータプログラム - 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）またはＲＳ２３２Ｃ等の規格に応じた通信ケーブルが接続されるコネクタを有し、通信ケーブルを介して接続された別の通信装置と有線通信を行う。
別の通信装置と管理サーバ５等の車外装置とが広域通信網２を通じた無線通信が可能である場合には、車外装置→別の通信装置→有線通信部→ゲートウェイ１０の通信経路により、車外装置とゲートウェイ１０とが通信可能になる。

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

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

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

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

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

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

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

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

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

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

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

ＥＣＵの制御プログラムを更新するタイミングに達すると、管理サーバ５は、該当する車両１のゲートウェイ１０宛てに、ＥＣＵ３０の更新プログラムの保存先ＵＲＬとダウンロード要求とを送信する（ステップＳ１）。
これにより、ゲートウェイ１０は、ＥＣＵ３０のための更新プログラムをＤＬサーバ６からダウンロードする（ステップＳ２）。ゲートウェイ１０は、受信した更新プログラムを自装置の記憶部１３に一時的に格納して保存する。

更新プログラムの保存が完了すると、ゲートウェイ１０は、ＤＬが正常に完了したことを管理サーバ５に送信する（ステップＳ３）。引き続き自動で更新を行う場合、ＤＬ完了通知を受信した管理サーバ５は、制御プログラムの更新要求をゲートウェイ１０に送信する。管理サーバ５は、ＤＬ完了後、一時中断し外部から更新要求を受けてから、制御プログラムの更新要求をゲートウェイ１０に送信してもよい（ステップＳ４）。

更新要求を受信したゲートウェイ１０は、赤信号による停車時間に基づいて、当該停車時間内における制御プログラムの更新の可否を判定する（ステップＳ５Ａ）。そして、制御プログラムの更新を許可する場合、ゲートウェイ１０は、記憶部１３に保存した更新プログラムを用いて制御プログラムを更新させるべく、該当するＥＣＵ３０に制御プログラムの更新要求を送信する（ステップＳ６）。なお、ステップＳ６では、ゲートウェイ１０は、制御プログラムの更新が可能であることをユーザに通知して、更新を開始するユーザ操作に従ってＥＣＵ３０に更新を要求してもよい。

制御プログラムの更新要求を受信すると、ＥＣＵ３０は、自身の制御モードを通常モードからリプロモードに切り替える。これにより、当該ＥＣＵは制御プログラムの更新処理が可能な状態となる。

ＥＣＵ３０は、受信した更新プログラムを展開して旧バージョンの制御プログラムに適用することにより、制御プログラムを旧バージョンから新バージョンに書き換える（ステップＳ７）。書き換えが完了すると、ＥＣＵ３０は、書き換えの完了通知をゲートウェイ１０に送信する（ステップＳ８）。ゲートウェイ１０は、書き換えの完了通知を該当するＥＣＵ３０から受信すると、更新完了通知を管理サーバ５に送信する（ステップＳ９）。

［ゲートウェイの機能構成］
ゲートウェイ１０のＣＰＵ１１は、制御プログラムの更新の可否を判定する処理（ステップＳ５Ａ）を行うための機能として、図２において予測部１１１、取得部１１２、および判定部１１３と表された機能を含む。これら機能は、ＣＰＵ１１が記憶部１３に記憶されている１つまたは複数のプログラムを読み出して実行することによって、ＣＰＵ１１において実現される機能である。しかしながら、少なくとも一部機能が、電子回路などのハードウェアによって実現されてもよい。

予測部１１１で表されたＣＰＵ１１の機能（以下、予測部１１１）は、車両１が下流に存在する交差点において、設置された信号機の赤色の点灯（以下、赤信号）によって停車する時間を予測する。

予測部１１１は、予測用の情報として、他の装置から信号機に関する情報を取得する。他の装置は、たとえば、ビーコンなどとも呼ばれる道路側に設置された通信装置である路側機８や、信号情報などの交通情報を集約する集約サーバ７である。

図１に示されるように、ゲートウェイ１０は、路側機８と無線通信を行う。無線通信は、光通信、電波通信などである。光通信を行う路側機８は光ビーコンとも呼ばれる。電波通信を行う路側機８は電波ビーコンとも呼ばれる。無線通信は、その他、ＤＳＲＣ（Dedicated Short Range Communications）、ＦＭ（Frequency Modulation）波を利用したいわゆるＦＭ通信、などである。ゲートウェイ１０は、路側機８から上記の無線通信によって送信されてくる信号情報を受信する。

路側機８は、交差点に関連付けられ、当該交差点の上流側に設置されている。交差点に進入する車両に対して当該交差点に関する信号情報を送信するためである。そのため、車両１が路側機８から信号情報を受信すると、交差点に進入する手前（上流側）にいる、つまり、すぐ下流に交差点がある、ということになる。

路側機８から送信されてくる信号情報は、当該情報の有効時間を示す情報、下流に存在する交差点の位置情報、当該交差点に設置されている信号のサイクル長、などを含む。好ましくは、信号情報は、車両１の位置に応じたこれら情報を含む。信号情報には、さらに、当該位置から発信する際の流速度を示す情報（発信交通流速度情報）が含まれてもよい。これらの情報は、ゲートウェイ１０が集約サーバ７に対して自身の位置情報を送信して要求することによって、集約サーバ７から得られてもよい。

予測部１１１の取得する信号情報は、車両１から最も近い下流に位置する１つの交差点のみに関する情報であってもよいし、車両１から所定範囲内の下流に位置する１つ以上の交差点に関する情報であってもよい。また、予測部１１１が集約サーバ７から信号情報を取得する場合、図示しないナビゲーション装置に設定されている経路を予測経路として集約サーバ７に渡し、当該経路上の１つ以上の交差点に関する情報を取得してもよい。

予測部１１１は、取得した信号情報と、エンジン制御ＥＣＵなどから得られる当該車両１の走行状態（位置・速度等)を示す情報とに基づいて、当該交差点での赤信号による停車時間（信号待ちによる停車時間）Ｔｓを予測する。

赤信号による停車時間Ｔｓの予測方法は、すでに様々な方法が提案されている。たとえば、特開２００７−５６７３４号公報は、赤信号の時間に加えて、青信号に変化してからの発進遅れの時間を考慮して停止時間Ｔｓを予測する方法を開示している。予測部１１１での停止時間Ｔｓの予測方法は特定の方法に限定されず、たとえば、特開２００７−５６７３４号公報に開示された方法であってもよい。

取得部１１２で表されたＣＰＵ１１の機能（以下、取得部１１２）は、制御プログラムの更新に要する時間である更新時間Ｔｒを取得する。取得部１１２は、一例として、管理サーバ５から更新時間Ｔｒを取得する。また、取得部１１２は、他の例として、更新プログラムのサイズおよび対象のＥＣＵ３０の処理能力に基づいて更新時間Ｔｒを算出してもよい。

ステップＳ７での制御プログラムの更新は、図５に表わされたように、ＥＣＵ３０の記憶部３３から旧プログラムを消去する処理（ステップＳ７１）と、旧プログラムに更新プログラムを適用することで生成された新プログラムを記憶部３３に書き込む処理（ステップＳ７２）と、ＥＣＵ３０を再起動する処理（ステップＳ７３）とからなる。

ステップＳ７でのＥＣＵ３０が行う制御プログラムの更新は、対象のＥＣＵ３０のメモリ構成によって異なる。図３を参照して、ＥＣＵ３０の記憶部３３の構成は、次の２つの構成が挙げられる。
第１の構成：機能用メモリ３３１が含まれ待機用メモリ３３２が含まれない
第２の構成：待機用メモリ３３２と機能用メモリ３３１との両方が含まれる
ただし、待機用メモリ３３２はプログラムのバックアップに用いられる領域である。機能用メモリ３３１はＣＰＵ３１が読み出して実行するプログラムを格納するための領域である。

第１のメモリ構成である場合、すなわち待機用メモリ３３２が含まれない場合、図２に表わされたように、ゲートウェイ１０の記憶部１３に待機用メモリ１３１が用意される。ゲートウェイ１０は管理サーバ５から受信した更新プログラムを旧プログラムに適用することで新プログラムを生成し、新プログラムを待機用メモリ１３１に格納する。次に、ゲートウェイ１０からの要求を受けたＥＣＵ３０のＣＰＵ３０は、リプロモードにおいて上記ステップＳ７１〜Ｓ７３のすべてを実行して、ゲートウェイ１０から受信した新プログラムを機能用メモリ３３１に書き込む。従って、第１のメモリ構成である場合、更新時間ＴｒはステップＳ７１〜Ｓ７３それぞれの処理時間Ｔ１，Ｔ２，Ｔ３を用いて、次の式で表わされる。
Ｔｒ＝Ｔ１＋Ｔ２＋Ｔ３

第２のメモリ構成である場合、すなわち待機用メモリ３３２が含まれる場合、ＥＣＵ３０のＣＰＵ３０は、ゲートウェイ１０から受信した更新プログラムを旧プログラムに適用することで新プログラムを生成し、新プログラムを待機用メモリ３３２に格納する。この処理は機能用メモリ３３１に影響しないため、リプロモード以前の通常モードに行なわれる。そして、ＣＰＵ３０は、リプロモードにおいてＥＣＵ３０を再起動することによって待機用メモリ３３２と機能用メモリ３３１との役割を入れ替える。つまり、第２のメモリ構成である場合、ステップＳ７での制御プログラムの更新はステップＳ７３の再起動する処理のみとなる。従って、第２のメモリ構成である場合、更新時間Ｔｒは次の式で表わされる。
Ｔｒ＝Ｔ３

そこで、好ましくは、取得部１１２は、対象のＥＣＵ３０のメモリ構成が第１のメモリ構成であるか第２のメモリ構成であるかに応じた更新時間Ｔｒを取得する。または、取得部１１２は、対象のＥＣＵ３０のメモリ構成が第１のメモリ構成であるか第２のメモリ構成であるかに応じて、すなわち待機用メモリ３３２が含まれるか否かに応じて更新時間Ｔｒを算出する。このように更新時間Ｔｒが取得または算出されることによって、判定精度を向上させることができる。

判定部１１３で表されたＣＰＵ１１の機能（以下、判定部１１３）は、予測部１１１によって予測された停車時間Ｔｓと、取得部１１２によって取得された更新時間Ｔｒとを比較して、その比較結果に基づいて制御プログラムの更新の可否を判定する。判定部１１３は、停車時間Ｔｓが更新時間Ｔｒよりも長い場合に、制御プログラムの更新が可能であると判定する。一例として、判定部１１３は、次の判定式に従って制御プログラムの更新の可否を判定する。
更新時間Ｔｒ＜停車時間Ｔｓ …更新可能
更新時間Ｔｒ≧停車時間Ｔｓ …更新不可

好ましくは、判定部１１３は、更新時間Ｔｒに所定のマージン（余裕代）ｍを加えて停車時間Ｔｓと比較して、その比較結果に基づいて制御プログラムの更新の可否を判定する。これにより、停車中に制御プログラムの更新が確実に完了するか否かが判定されることになる。なお、マージンｍは、たとえば更新時間Ｔｒが２０秒である場合、１０秒程度である。一例として、判定部１１３は、次の判定式に従って制御プログラムの更新の可否を判定する。
更新時間Ｔｒ＋マージンｍ＜停車時間Ｔｓ …更新可能
更新時間Ｔｒ＋マージンｍ≧停車時間Ｔｓ …更新不可

更新時間Ｔｒに所定のマージンｍを加えることは、更新時間Ｔｒから所定のマージンｍを差し引くことと同じである。すなわち、上記の判定式は言い換えると、次の判定式と同じでもある。
更新時間Ｔｒ＜停車時間Ｔｓ−マージンｍ …更新可能
更新時間Ｔｒ≧停車時間Ｔｓ−マージンｍ …更新不可

または、上のマージンｍと同様に、判定部１１３は、更新時間Ｔｒと停車時間Ｔｓの所定割合α分の時間とを比較して、その比較結果に基づいて制御プログラムの更新の可否を判定してもよい。一例として、所定割合αは０．８程度である。判定部１１３は、次の判定式に従って更新プログラムの可否を判定する。
更新時間Ｔｒ＜停車時間Ｔｓ×α …更新可能
更新時間Ｔｒ≧停車時間Ｔｓ×α …更新不可

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

図６を参照して、ゲートウェイ１０のＣＰＵ１１は管理サーバ５から制御プログラムの更新が要求されると（ステップＳ１０１でＹＥＳ）、更新時間Ｔｒを取得する（ステップＳ１０５）。ＣＰＵ１１は、管理サーバ５からの要求に変えて、管理サーバ５から受信した更新プログラムがメモリに格納されていることが検出されると以降の判定を行ってもよい。

次に、ＣＰＵ１１は、路側機８などから信号情報の受信を待つ。信号情報を受信すると（ステップＳ１０７でＹＥＳ）、ＣＰＵ１１は、取得した信号情報と、当該車両１の走行状態（位置・速度等)を示す情報とに基づいて、下流に存在する交差点での赤信号による停車時間Ｔｓを予測する（ステップＳ１０９）。

次に、ＣＰＵ１１は、停車時間Ｔｓと更新時間Ｔｒとを比較して、比較結果に基づいて制御プログラムの更新の可否を判定する。一例として、更新時間Ｔｒ＜停車時間Ｔｓであるとき（ステップＳ１１１でＹＥＳ）、ＣＰＵ１１は、制御プログラムの更新が可能と判定し、対象のＥＣＵ３０に制御プログラムの更新を要求する（ステップＳ１１３）。これにより、更新が実行される。

一方、更新時間Ｔｒ≧停車時間Ｔｓであるとき（ステップＳ１１１でＮＯ）、ＣＰＵ１１は、制御プログラムの更新が可能ではないと判定する。ＣＰＵ１１はこの判定結果に基づいて、ＥＣＵ３０に制御プログラムの更新を要求しない。この場合、ＣＰＵ１１は、次に路側機８などから信号情報の受信を待つ。そして、次に信号情報を受信すると、再度、上記ステップＳ１０９から処理を繰り返してもよい。

［第１の実施の形態の効果］
第１の実施の形態にかかるプログラム更新システムによれば、車両１が赤信号による停車時間Ｔｓが更新時間Ｔｒよりも長い場合に（Ｔｒ＜Ｔｓ）、当該赤信号による停車中に制御プログラムの更新が実行され、発進前に制御プログラムの更新が完了する。そのため、更新中に当該ＥＣＵの制御対象とする機能が使用できなくなるような制御プログラムの更新であっても、当該更新によって車両の走行が妨げられることがない。つまり、適切なタイミングに制御プログラムを更新することができる。

＜第２の実施の形態＞
制御プログラムには、走行中の信号待ちのタイミングで更新することが許可されていない制御プログラムがある。このような走行中の更新が不可な制御プログラムを不可プログラムとも称する。

不可プログラムには、更新の前後で運転者の運転操作性が異なる制御プログラムが挙げられる。たとえば、ＥＰＳ（電動パワーステアリング：Electrical Power steering）、ＥＦＩ（電子制御燃料噴射装置：Electronic Fuel Injection）などの制御を行うＥＣＵの制御プログラムである。不可プログラムではないプログラムは、たとえば、ＡＢＳ（Antilock Brake System）、ＥＳＰ(横滑り防止装置：Electronic Stability Program)、自動運転、などの制御を行うＥＣＵの制御プログラムである。

不可プログラムが走行中の信号待ちで更新されると、信号待ちの停車を介在することによって運転者の運転操作性が異なる。そのため、運転者に違和感や戸惑いを与えることになる。

そこで、好ましくは、判定部１１３は、管理サーバ５から更新を要求された制御プログラムが不可プログラムでない場合に更新の可否を判定し、不可プログラムであった場合には更新の可否を判定することなく、更新の開始を許可しない。この判定を行うために、判定部１１３は、不可プログラムに該当する制御プログラムの識別情報、および／または不可プログラムに該当しない制御プログラムの識別情報を予め記憶しておく。なお、制御プログラムが不可プログラムであるか否かの判定は管理サーバ５で行われてもよい。この場合、管理サーバ５は更新を要求する制御プログラムについて予め当該判定を行い、その判定結果を示す情報と共にゲートウェイ１０に対して更新を要求する。つまり、この場合、判定部１１３は、管理サーバ５から更新を要求された制御プログラムが不可プログラムであるか否かの判定結果を管理サーバ５から取得する。

図７は、第２の実施の形態にかかる、制御プログラムの更新の可否の判定処理の具体的な内容を表したフローチャートである。図７のフローチャートに表された処理もまた、ゲートウェイ１０のＣＰＵ１１が記憶部１３に記憶された１つまたは複数のプログラムをＲＡＭ１２上に読み出して実行することによって、主にＣＰＵ１１により実現される。図７のフローチャートのうち図６のフローチャートと同じステップ番号が付加された処理は図６のフローチャートに示された処理と同じである。そのため、ここでの説明を繰り返さない。

図７を参照して、ＣＰＵ１１は、管理サーバ５から制御プログラムの更新が要求されると（ステップＳ１０１でＹＥＳ）、当該制御プログラムが不可プログラムであるか否かを判別する。そうである場合には（ステップＳ１０３でＹＥＳ）、ＣＰＵ１１は以降の判定を行なわず、対象のＥＣＵ３０に制御プログラムの更新を要求しない。これにより、車両１の走行中に該制御プログラムの更新は行われない。

一方、更新が要求された制御プログラムが不可プログラムでない場合には（ステップＳ１０１でＮＯ）、ＣＰＵ１１は、上述した判定を行って、判定結果に従って対象のＥＣＵ３０に制御プログラムの更新を要求する。

［第２の実施の形態の効果］
制御プログラムが不可プログラムである場合に停車時間と更新時間との比較を行うことなく、車両の走行中における当該制御プログラムの更新が許可されないことによって、車両１の走行中に該制御プログラムの更新が行われない。そのため、信号待ちの停車を介在することによって運転者の運転操作性が異なるために運転者が違和感を覚えたり戸惑ったりすることを防止できる。

＜第３の実施の形態＞
第１〜第２の実施の形態にかかるプログラム更新システムでは、プログラムの更新の可否をゲートウェイ１０で判定する。しかしながら、プログラムの更新の可否はゲートウェイ１０とは異なる装置で判定されてもよい。他の例として、管理サーバ５が判定してもよい。第３の実施の形態にかかる管理サーバ５は、図５のステップＳ５Ｂのタイミングで更新の可否を判定する。すなわち、管理サーバ５は、ゲートウェイ１０から更新プログラムのダウンロードの完了が通知されると、次に、更新の可否を判定し（ステップＳ５Ｂ）、更新可能と判定されたタイミングでゲートウェイ１０に対して更新を要求する（ステップＳ４）。

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

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

１ 車両
２ 広域通信網
５ 管理サーバ（制御装置）
６ ＤＬサーバ
７ 集約サーバ
８ 路側機
１０ ゲートウェイ（制御装置）
１１ ＣＰＵ（判定部）
１２ ＲＡＭ
１３ 記憶部
１４ 車内通信部
１５ 無線通信部
３０ ＥＣＵ（車載制御装置）
３１ ＣＰＵ
３２ ＲＡＭ
３３ 記憶部
３４ 通信部
３５ 起動部
５１ ＣＰＵ（判定部）
５２ ＲＯＭ
５３ ＲＡＭ
５４ 記憶部
５５ 通信部
１１１，５１１ 予測部
１１２，５１２ 取得部
１１３，５１３ 判定部
１３１，３３２ 待機用メモリ
３３１ 機能用メモリ

Claims (7)

1. 車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する制御装置であって、
   信号情報に基づいて、信号待ちによる前記車両の停車時間を予測する予測部と、
   前記制御プログラムの更新に要する時間である更新時間を取得する取得部と、
   前記停車時間と前記更新時間との比較結果に基づいて、前記信号待ちにおける前記制御プログラムの更新の可否を判定する判定部と、を備える、制御装置。
2. 前記判定部は、前記更新時間が前記停車時間よりも短いときに、前記信号待ちにおける前記制御プログラムの更新を許可する、請求項１に記載の制御装置。
3. 前記判定部は、前記制御プログラムが走行中の信号待ちでの更新が許可されていない制御プログラムである場合には、前記停車時間と前記更新時間との比較を行うことなく、前記車両の走行中における当該制御プログラムの更新を許可しない、請求項１または請求項２に記載の制御装置。
4. 前記判定部は、所定のマージンを用いて前記更新時間を長めに算出するか、または前記停車時間を短めに算出する、請求項１〜請求項３のいずれか一項に記載の制御装置。
5. 前記更新時間は、前記制御プログラムのバックアップ用メモリの有無に応じて異なる演算式によって算出されるものである、請求項１〜請求項４のいずれか一項に記載の制御装置。
6. 車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新方法であって、
   信号情報に基づいて、信号待ちによる前記車両の停車時間を予測するステップと、
   前記制御プログラムの更新に要する時間である更新時間を取得するステップと、
   前記停車時間と前記更新時間との比較結果に基づいて、前記信号待ちにおける前記制御プログラムの更新の可否を判定するステップと、を備える、プログラム更新方法。
7. 車両に搭載された対象機器を制御する車載制御装置の制御プログラムの更新を制御する制御装置としてコンピュータを機能させるためのコンピュータプログラムであって、前記コンピュータを、
   信号情報に基づいて、信号待ちによる前記車両の停車時間を予測する予測部、
   前記制御プログラムの更新に要する時間である更新時間を取得する取得部、および、
   前記停車時間と前記更新時間との比較結果に基づいて、前記信号待ちにおける前記制御プログラムの更新の可否を判定する判定部、として機能させる、コンピュータプログラム。

Images