JP2021039651A - ソフトウェア更新装置、ソフトウェア更新方法、およびプログラム - Google Patents

Abstract

【課題】より適切にソフトウェア更新処理を実行することができるソフトウェア更新装置、ソフトウェア更新方法、およびプログラムを提供すること。【解決手段】実施形態の一態様に係るソフトウェア更新装置は、外部装置と通信する通信部と、前記通信部による前記外部装置との通信により、車両に搭載された機器を制御する複数の機器制御部に組み込まれたソフトウェアのうち少なくとも一つを更新する更新制御部と、を備え、前記更新制御部は、前記車両の停止に伴って、前記複数の機器制御部のうち少なくとも一つの機器制御部に対する前記ソフトウェアの更新を行う場合に、前記ソフトウェアの更新を行わない機器制御部における通信、または、前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って実行する処理のうち、一方または双方を抑制することを特徴とする。【選択図】図２

Description

本発明は、ソフトウェア更新装置、ソフトウェア更新方法、およびプログラムに関する。

従来、サーバから更新プログラムをダウンロードし、ダウンロードした更新プログラムを、車載機器を制御する制御部に組み込まれたソフトウェアに適用して、ソフトウェアを更新するソフトウェア更新システムが知られている（例えば、特許文献１参照）。特許文献１の更新システムでは、アップデート対象機器のアップデートが未完了となった場合に、アップデートが未完了となった要因を検出し、アップデートを再開することが可能な場合にアップデートを再開する処理を行う。

特開２０１８−９７７６４号公報

しかしながら、上述した技術は、不具合が発生した後に対応を行うものであり、事前に不具合発生の原因となる可能性がある外乱要因を考慮した更新制御を行うものではなかった。したがって、適切なソフトウェア更新が行われない場合があった。

本発明の態様は、このような事情を考慮してなされたものであり、より適切にソフトウェア更新処理を実行することができるソフトウェア更新装置、ソフトウェア更新方法、およびプログラムを提供することを目的の一つとする。

この発明に係るソフトウェア更新装置、ソフトウェア更新方法、およびプログラムは、以下の構成を採用した。
（１）：この発明の一態様に係るソフトウェア更新装置は、外部装置と通信する通信部と、前記通信部による前記外部装置との通信により、車両に搭載された機器を制御する複数の機器制御部に組み込まれたソフトウェアのうち少なくとも一つを更新する更新制御部と、を備え、前記更新制御部は、前記車両の停止に伴って、前記複数の機器制御部のうち少なくとも一つの機器制御部に対する前記ソフトウェアの更新を行う場合に、前記ソフトウェアの更新を行わない機器制御部における通信、または、前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って実行する処理のうち、一方または双方を抑制することを特徴とするソフトウェア更新装置である。

（２）：上記（１）の態様において、前記複数の機器制御部は、前記車両が走行するための走行駆動力を駆動輪に出力する内燃機関を制御する第１機器制御部と、前記車両に搭載された変速機を制御する第２機器制御部とを含み、前記更新制御部は、前記第１機器制御部または第２機器制御部のうち一方または双方に対する前記ソフトウェアの更新がある場合に、前記第１機器制御部および前記第２機器制御部において前記車両の停止に伴って実行する処理を停止させることを特徴とするものである。

（３）：上記（１）または（２）の態様において、前記車両の運転情報を記憶する記憶部を更に備え、前記更新制御部は、前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って、前記運転情報を前記記憶部に記憶させる処理を実行する場合に、前記処理を延期し、前記ソフトウェアの更新後に前記処理を実行させることを特徴とするものである。

（４）：上記（１）〜（３）のうち何れか一つの態様において、前記更新制御部は、前記ソフトウェアの更新が正常に終了できない状態が所定回数以上継続した場合に、前記ソフトウェアを更新させる前に前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って実行する処理を実行させることを特徴とするものである。

（５）：上記（１）〜（４）のうち何れか一つの態様において、前記車両に搭載されたバッテリのエネルギー量を取得するエネルギー取得部を更に備え、前記更新制御部は、前記エネルギー取得部により取得された前記エネルギー量に基づいて、前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って実行する処理の実行を制御することを特徴とするものである。

（６）：上記（１）〜（５）のうち何れか一つの態様において、前記複数の機器制御部は、前記車両の操舵または速度のうち一方または双方を制御して運転制御を行う第３機器制御部を含み、前記更新制御部は、前記第３機器制御部に対する前記ソフトウェアの更新がある場合に、前記第３機器制御部によって制御される機器における処理を抑制することを特徴とするものである。

（７）：この発明の一態様に係るソフトウェア更新方法は、車両に搭載されるソフトウェア更新装置が、外部装置と通信し、前記外部装置との通信により、車両に搭載された機器を制御する複数の機器制御部に組み込まれたソフトウェアのうち少なくとも一つを更新し、前記車両の停止に伴って、前記複数の機器制御部のうち少なくとも一つの機器制御部に対する前記ソフトウェアの更新を行う場合に、前記ソフトウェアの更新を行わない機器制御部における通信、または、前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って実行する処理のうち、一方または双方を抑制することを特徴とするソフトウェア更新方法である。

（８）：この発明の一態様に係るプログラムは、車両に搭載されるソフトウェア更新装置に、外部装置と通信させ、前記外部装置との通信により、車両に搭載された機器を制御する複数の機器制御部に組み込まれたソフトウェアのうち少なくとも一つを更新させ、前記車両の停止に伴って、前記複数の機器制御部のうち少なくとも一つの機器制御部に対する前記ソフトウェアの更新を行う場合に、前記ソフトウェアの更新を行わない機器制御部における通信、または、前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って実行する処理のうち、一方または双方を抑制させることを特徴とするプログラムである。

上記（１）〜（８）の態様によれば、より適切にソフトウェア更新処理を実行することができる。

実施形態のソフトウェア更新装置１００を含むソフトウェア更新システム１の構成図である。 実施形態のソフトウェア更新装置１００を含む車両システム２の構成図である。 機器管理情報１５２の内容の一例を示す図である。 第１の更新制御パターンにおいて、更新制御部１２０が実行する処理の一例を示すフローチャートである。 第２の更新制御パターンにおいて、更新制御部１２０が実行する処理の一例を示すフローチャートである。 ＥＣＵにおけるソフトウェア更新の第１実施例について説明するための図である。 ＥＣＵにおけるソフトウェア更新の第２実施例について説明するための図である。

以下、図面を参照し、本発明のソフトウェア更新装置、ソフトウェア更新方法、およびプログラムの実施形態について説明する。なお、以下では、ソフトウェア更新装置が、車両システムの一部として車両に搭載されている例について説明する。車両は、例えば、二輪や三輪、四輪等の車両である。また、車両の駆動源は、例えば、ディーゼルエンジンやガソリンエンジン等の内燃機関、電動機、或いはこれらの組み合わせである。電動機は、内燃機関に連結された発電機による発電電力、或いは二次電池や燃料電池の放電電力を使用して動作する。なお、ソフトウェア更新装置は、車両以外の移動体（例えば、船舶、飛行体）に搭載されてもよい。

［ソフトウェア更新システム］
図１は、実施形態のソフトウェア更新装置１００を含むソフトウェア更新システム１の構成図である。ソフトウェア更新システム１は、例えば、一以上の車両Ｍ−１〜Ｍ−ｎ（ｎは１以上の自然数）に搭載されたソフトウェア更新装置１００−１〜１００−ｎと、サーバ装置２００と、を備える。車両Ｍの符号の末尾のハイフン以下の数字は、車両を区別するための識別子であるものとする。いずれの車両であるかを区別しない場合、単に車両Ｍと称する場合がある。また、以下では、車両Ｍに含まれる構成要素は同様であるものとする。ソフトウェア更新装置１００と、サーバ装置２００とは、ネットワークＮＷを介して互いに通信可能である。ネットワークＮＷは、例えば、セルラー網や、Ｗｉ−Ｆｉ網、Ｂｌｕｅｔｏｏｔｈ（登録商標）、インターネット、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、公衆回線、プロバイダ装置、専用回線、無線基地局等を含む。また、これらの構成要素は、それぞれネットワークＮＷを介さずに、直接、無線通信を行ってもよい。サーバ装置２００は、「外部装置」の一例である。

ソフトウェア更新装置１００は、車両Ｍに搭載された機器にインストールされるソフトウェアの更新制御を行う。例えば、ソフトウェア更新装置１００は、サーバ装置２００から更新用ソフトウェアをダウンロードし、ダウンロードしたソフトウェアに基づいて、車両Ｍに搭載された機器のうち少なくとも一部の機器を制御するソフトウェアを更新する。

サーバ装置２００は、ソフトウェア更新装置１００からの問い合わせ情報に基づいて、ソフトウェア更新装置１００が管理するソフトウェア情報（バージョン情報等）がサーバ側で管理される最新のソフトウェアでない場合に、ソフトウェア更新装置１００に更新用ソフトウェアをダウンロードさせて、ソフトウェアを更新させる。また、サーバ装置２００は、ソフトウェアが更新された場合に、対象のソフトウェアがインストールされている車両を抽出し、抽出した車両に搭載されたソフトウェア更新装置１００に更新用ソフトウェアの実行を指示してもよい。

［ソフトウェア更新装置］
図２は、実施形態のソフトウェア更新装置１００を含む車両システム２の構成図である。車両システム２は、例えば、車載機器１０と、操作部９０と、表示部９２と、イグニッション装置９４と、ソフトウェア更新装置１００とを備える。車載機器１０は、例えば、エンジンＥＣＵ（Electronic Control Unit）２０と、トランスミッションＥＣＵ３０と、ステアリングＥＣＵ４０と、ブレーキＥＣＵ５０と、運転制御ＥＣＵ６０と、バッテリＥＣＵ７０と、ナビゲーションＥＣＵ８０とを備える。また、車載機器１０には、例えば、オーディオ装置、キーレスエントリシステム、サスペンションシステム、エアバッグ装置等を制御する各種ＥＣＵが含まれてよい。車載機器１０に含まれる複数のＥＣＵのそれぞれは、「機器制御部」の一例である。エンジンＥＣＵ２０は、「第１機器制御部」の一例である。トランスミッションＥＣＵ３０は、「第２機器制御部」の一例である。運転制御ＥＣＵ６０は、「第３機器制御部」の一例である。

車載機器１０に含まれる複数のＥＣＵのそれぞれは、例えば、プロセッサ、記憶部、および外部通信インターフェース等が、バス等で接続されている。また、ＥＣＵには、ソフトウェアが組み込まれており、ソフトウェアを実行することで、対応する機器の少なくとも一部の制御が実行される。ソフトウェアは、少なくとも一以上のプログラムモジュールを含む。プログラムモジュールとは、例えば、一以上のプログラムを含み、ソフトウェアによって実現できる機能のうち部分的な機能を実行するものである。ソフトウェアは、例えば、更新制御部１２０の制御によってモジュール単位の更新が可能である。以下では、更新用ソフトウェアをＯＴＡ（Over The Air）等の通信により外部装置（例えば、サーバ装置２００）から受信して、複数のＥＣＵに組み込まれたソフトウェアのうち少なくとも一つを更新する一連の処理を「ＯＴＡによる更新処理」と称する。

各ＥＣＵ内の記憶部（図２の例では、記憶部２０Ａ、３０Ａ、４０Ａ、４０Ａ、５０Ａ、６０Ａ、７０Ａ、および８０Ａ）は、例えば、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read Only Memory）やフラッシュメモリ等の不揮発性メモリ（Non Volatile Memory）である。記憶部２０Ａ〜８０Ａには、各ＥＣＵに組み込まれたソフトウェアやＥＣＵに関する構成情報が記憶される。構成情報には、例えば、機器識別情報（以下、ハードウェア識別情報と称する）、ソフトウェア識別情報等が含まれる。ハードウェア識別情報には、例えば、機器の部品番号（ハードウェア部番）、ユニークＩＤ（シリアルナンバー）等が含まれる。ソフトウェア識別情報には、ソフトウェアのモジュールごとの識別情報（ソフトウェア部番）、バージョン情報等が含まれる。ハードウェア部番やソフトウェア部番には、例えば、機能種別、構成種別、部品類別、バリエーション情報、その他の補足情報（例えば、メーカー別番号）等が含まれてもよい。

また、車載機器１０の各ＥＣＵのそれぞれは、所定のネットワークにより他のＥＣＵやソフトウェア更新装置１００等と通信を行う。所定のネットワークとは、例えば、ＣＡＮ（Controller Area Network）や、ＣＡＮ−ＦＤ（CAN with Flexible Data rate）、イーサネット（登録商標）等に準拠したネットワークである。

エンジンＥＣＵ２０は、車両Ｍが走行するための走行駆動力を駆動輪に出力するエンジン（内燃機関の一例）２２を制御する。例えば、エンジンＥＣＵ２０は、運転制御ＥＣＵ６０から入力される情報、或いは操作部９０に含まれるアクセルペダルによって入力される情報に従って、エンジン２２の回転数等の情報を取得し、取得した情報に基づき、エンジン２２が目標エンジントルクを発生するように、スロットルバルブ開度や燃料供給量等を調節してエンジン２２の運転状態を制御する。

トランスミッションＥＣＵ３０は、車両Ｍに搭載されたトランスミッション（変速機）３２を制御する。例えば、トランスミッションＥＣＵ３０は、運転制御ＥＣＵ６０から入力される情報、或いは操作部９０に含まれるクラッチやシフトレバーの操作によって入力される情報に従って、シフトを切り替えて指示された変速段となるように、トランスミッション３２を制御する。

ステアリングＥＣＵ４０は、ステアリング装置４２による車両Ｍの操舵を制御する。ステアリング装置４２は、例えば、電動モータを備える。電動モータは、例えば、ラックアンドピニオン機構に力を作用させて転舵輪の向きを変更する。ステアリングＥＣＵ４０は、運転制御ＥＣＵ６０から入力される情報、或いは操作部９０に含まれるステアリングホイールから入力される情報に従って、ステアリング装置４２の電動モータを駆動し、転舵輪の向きを変更させる。

ブレーキＥＣＵ５０は、ブレーキ装置５２による車両Ｍの制動を制御する。ブレーキ装置５２は、例えば、ブレーキキャリパーと、ブレーキキャリパーに油圧を伝達するシリンダと、シリンダに油圧を発生させる電動モータとを備える。ブレーキＥＣＵ５０は、運転制御ＥＣＵ６０から入力される情報、或いは操作部９０に含まれるブレーキペダルから入力される情報に従って、電動モータを制御し、制動操作に応じたブレーキトルクが各車輪に出力されるようにする。ブレーキ装置５２は、ブレーキペダルの操作によって発生させた油圧を、マスターシリンダを介してシリンダに伝達する機構をバックアップとして備えてよい。なお、ブレーキ装置５２は、上記説明した構成に限らず、運転制御ＥＣＵ６０から入力される情報に従ってアクチュエータを制御して、マスターシリンダの油圧をシリンダに伝達する電子制御式油圧ブレーキ装置であってもよい。

運転制御ＥＣＵ６０は、例えば、物体認識装置６２による車両Ｍの周辺の認識結果に基づいて車両Ｍの運転制御を行う。運転制御とは、例えば、車両Ｍの操舵または速度のうち一方または双方を制御して車両Ｍの乗員の運転を支援することである。運転制御には、例えば、ＡＣＣ（Adaptive Cruise Control System）、ＬＫＡＳ（Lane Keeping Assistance System）、ＴＪＰ（Traffic Jam Pilot）、ＡＬＣ（Auto Lane Changing）、ＣＭＢＳ（Collision Mitigation Brake System）、ＶＳＡ（Vehicle Stability Assist）等が含まれる。各運転制御は、例えば、イベントとして実行され、実行されたイベントや、イベント実行による運転制御の内容は、運転情報として記憶部６０Ａに記憶される。

物体認識装置６２は、車載機器１０であるカメラ６４と、レーダ装置６６と、ファインダ６８からの情報を取得して車両Ｍの周辺の物体認識を行う。カメラ６４は、車両Ｍの周辺を撮像し、撮像画像を生成する。カメラ６４は、例えば、ＣＣＤ（Charge Coupled Device）やＣＭＯＳ（Complementary Metal Oxide Semiconductor）等の固体撮像素子を利用したデジタルカメラである。カメラ６４は、車両システム２が搭載される車両Ｍの任意の箇所に取り付けられる。車両Ｍの周辺とは、車両Ｍの前方を含み、車両Ｍの側方又は後方を含んでいてもよい。例えば、車両Ｍの前方を撮像する場合、カメラ６４は、フロントウインドシールド上部やルームミラー裏面等に取り付けられる。カメラ６４は、ステレオカメラであってもよい。

レーダ装置６６は、車両Ｍの周辺の所定の照射方向に対してミリ波等の電波を放射するとともに、物体によって反射された電波（反射波）を検出して少なくとも物体の位置（距離および方位）を検出する。物体とは、例えば、車両Ｍの周辺に存在する他車両、障害物、構造物等である。レーダ装置６６は、車両Ｍの任意の箇所に一つまたは複数が取り付けられる。レーダ装置６６は、ＦＭＣＷ（Frequency Modulated Continuous Wave）方式によって物体の位置および速度を検出してもよい。

ファインダ６８は、車両Ｍの周辺の所定の照射方向に対して照射された照射光に対する散乱光を測定し、物体までの距離を検出するＬＩＤＡＲ（Light Detection and Ranging、或いはLaser Imaging Detection and Ranging）である。ファインダ６８は、車両Ｍの任意の箇所に一つまたは複数が取り付けられる。

物体認識装置６２は、カメラ６４、レーダ装置６６、およびファインダ６８のうち一部または全部による検出結果に対してセンサフュージョン処理を行って、車両Ｍの周辺に存在する物体の位置、種類、速度等を認識する。また、物体認識装置６２は、センサフュージョン処理によって、車両Ｍの周辺の道路形状、標識、車線等を認識してもよい。物体認識装置６２は、認識結果を運転制御ＥＣＵ６０に出力する。

運転制御ＥＣＵ６０は、物体認識装置６２からの認識結果等に基づいて、所定の運転制御が実行されるように、エンジンＥＣＵ２０やトランスミッションＥＣＵ３０、ステアリングＥＣＵ４０、ブレーキＥＣＵ５０に制御情報を取得する。所定の運転制御とは、例えば、車両Ｍの走行状態や乗員による運転状態に基づく運転制御であり、より具体的には、車両Ｍと物体との接触を回避するような運転制御や、走行車線を逸脱することを抑制する運転制御、前走車両に追従して走行する運転制御等が含まれる。

バッテリＥＣＵ７０は、車両Ｍに搭載されたバッテリ７２のエネルギー量や充放電等のエネルギー制御を行う。バッテリＥＣＵ７０は、例えば、車載機器１０や操作部９０、表示部９２、ソフトウェア更新装置１００、およびその他の車両Ｍ内の電気機器等にバッテリ７２の電力を供給する。また、バッテリＥＣＵ７０は、イグニッション装置９４に対する操作内容に基づいて所定の機器にバッテリ７２からの電力を供給してもよい。ソフトウェア等の更新処理の実行時に用いられるエネルギーは、主にバッテリ７２から更新対象のＥＣＵに供給される。

また、バッテリＥＣＵ７０は、例えば、ブレーキ装置５２の作動によって発生した回生電流を用いてバッテリ７２を充電する制御を行ってもよい。また、バッテリＥＣＵ７０は、例えば、充電コネクタ等を介して外部の充電設備から供給されるエネルギーをバッテリ７２に蓄える制御を行ってもよい。また、バッテリＥＣＵ７０は、バッテリ７２の端子電圧を測定し、測定した端子電圧の大きさに基づいてエネルギー残量を取得する。また、バッテリＥＣＵ７０は、例えば、電流検出抵抗を使って充電時に蓄えられた電流量を積算しておき、放電時に出力された電流量を求めることでエネルギー残量を取得してもよく、バッテリの放電特性や温度特性等のデータベースを予め記憶部７０Ａ等に記憶しておき、計測した電圧値や電流値と、データベースとに基づいてエネルギー残量を取得してもよい。バッテリ管理ＥＣＵ７０は、上述したエネルギー残量に代えて充電率（ＳＯＣ；State Of Charge）を取得してもよい。

ナビゲーションＥＣＵ８０は、車両Ｍに搭載されたナビゲーション装置８２を制御する。ナビゲーション装置８２は、例えば、ＧＮＳＳ（Global Navigation Satellite System）受信機と、ナビＨＭＩ（Human Machine Interface）と、経路決定部とを備える。ＧＮＳＳ受信機は、ＧＮＳＳ衛星から受信した信号に基づいて、車両Ｍの位置を特定する。ナビＨＭＩは、ディスプレイ、スピーカ、タッチパネル、キー等を含む。ナビＨＭＩは、画像や音声等を用いて乗員に目的地等を設定させたり、目的地までの走行経路を乗員に案内する。経路決定部は、例えば、ＧＮＳＳ受信機により特定された車両Ｍの位置（或いは入力された任意の位置）から、ナビＨＭＩを用いて乗員により入力された目的地までの経路（以下、地図上経路）を、地図情報等を参照して決定する。ナビゲーションＥＣＵは、地図上経路に基づいて、ナビＨＭＩや表示部９２による地図画像表示やスピーカ（不図示）による音声出力によって、経路案内等を行う。

操作部９０は、車両Ｍの乗員による入力操作を受け付ける。例えば、操作部９０は、タッチパネル、スイッチ、キーなどを含む。操作部９０のタッチパネルは、表示部９２と一体に構成されてよい。また、操作部９０には、乗員が車両Ｍを手動で運転するための運転操作子が含まれてよい。運転操作子には、例えば、アクセルペダル、クラッチ、シフトレバー、ステアリングホイール、ブレーキペダル等が含まれる。

表示部９２は、例えば、ＬＣＤ（Liquid Crystal Display）や有機ＥＬ（Electro Luminescence）ディスプレイ等の表示装置である。表示部９２は、例えば、表示制御部１４０により生成された画像を表示する。表示部９２は、例えば、タッチパネル装置として、乗員からの操作内容を受け付ける機能を備えていてもよい。また、表示部９２は、ナビＨＭＩと一体に構成されてもよい。

イグニッション装置９４は、車両Ｍの乗員の操作等によりエンジン２２等の起動または停止を行うスイッチ装置である。スイッチのオン・オフによってエンジン２２の起動および停止が制御される。具体的には、スイッチがオン状態（以下、イグニッション・オン状態と称する）の場合に、エンジンＥＣＵ２０によりエンジン２２が起動状態となり、スイッチがオフ状態（以下、イグニッション・オフ状態と称する）の場合に、エンジンＥＵＣ２０によりエンジン２２が停止状態となる。イグニッション装置９４は、エンジン２２の起動および停止の他、他の車載機器に対する起動や停止またはバッテリ７２による電力の供給の有無を制御するスイッチ（アクセサリースイッチ）を備えていてもよい。

ソフトウェア更新装置１００は、例えば、通信部１１０と、更新制御部１２０と、エネルギー取得部１３０と、表示制御部１４０と、記憶部１５０とを備える。更新制御部１２０、エネルギー取得部１３０、および表示制御部１４０は、例えば、ＣＰＵ（Central Processing Unit）等のハードウェアプロセッサがプログラム（ソフトウェア）を実行することにより実現される。また、これらの構成要素のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）、ＧＰＵ（Graphics Processing Unit）等のハードウェア（回路部；circuitryを含む）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。プログラムは、予めソフトウェア更新装置１００のＨＤＤ（Hard Disk Drive）やフラッシュメモリ等の記憶装置（非一過性の記憶媒体を備える記憶装置）に格納されていてもよいし、ＤＶＤやＣＤ−ＲＯＭ等の着脱可能な記憶媒体に格納されており、記憶媒体（非一過性の記憶媒体）がドライブ装置に装着されることでソフトウェア更新装置１００のＨＤＤやフラッシュメモリにインストールされてもよい。

記憶部１５０は、上記の各種記憶装置、或いはＥＥＰＲＯＭ、ＲＯＭ（Read Only Memory）、またはＲＡＭ（Random Access Memory）等により実現される。記憶部１５０には、例えば、機器管理情報１５２、プロセッサによって読み出されて実行されるプログラム、その他各種情報等が格納される。

図３は、機器管理情報１５２の内容の一例を示す図である。機器管理情報１５２は、例えば、車両Ｍの車載機器１０に含まれるＥＣＵを識別する識別情報としてのＥＣＵ−ＩＤに、ソフトウェア識別情報、バージョン情報、実行処理内容、実行条件、および実行履歴が対応付けられた情報である。ソフトウェア識別情報は、ＥＣＵ−ＩＤに組み込まれるソフトウェアを識別する識別情報である。ソフトウェア識別情報には、例えば、ソフトウェアの種類やバージョン情報、更新日等の情報が含まれる。実行処理内容とは、ＥＣＵ−ＩＤで識別されるＥＣＵが所定の実行条件を満たす場合に実行する処理（以下、スタンバイ処理と称する）の内容である。処理の内容には、例えば、走行結果や運転結果等に基づく学習処理や走行履歴の記録処理、補正処理等が含まれる。実行条件は、実行処理内容に含まれるスタンバイ処理を実行するための各種条件である。実行条件には、例えば、車両Ｍの状態（例えば、イグニッション・オフ等の車両Ｍの停車時）や時間帯（例えば、夜間）の情報が含まれる。実行処理内容および実行条件は、例えば、車両Ｍの製造時や出荷時、メンテナンス時等の所定のタイミングで作業者等により登録または変更されてもよく、サーバ装置２００等の外部装置からの制御により登録または変更されてもよい。実行履歴には、例えば、スタンバイ処理の実行履歴が含まれる。実行履歴には、スタンバイ処理が実行済みであるか否かの情報や、実行が抑制されたか否かの情報、実行を抑制した回数、実行を抑制した理由、次の実行に関する情報（例えば、実行条件や実行内容）が含まれてもよい。また、実行履歴には、更新処理の実行に関する履歴情報が含まれてもよい。

通信部１１０は、所定の通信手段（通信方式）により外部装置と通信を行う。通信部１１０は、例えば、セルラー網やＷｉ−Ｆｉ網、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＤＳＲＣ（Dedicated Short Range Communication）等を利用して、サーバ装置２００等の外部装置と通信する。通信部１１０は、例えば、ＴＣＵ（Telematics control unit）であってもよい。通信部１１０は、例えば、ＯＴＡ等の無線通信によりサーバ装置２００と通信を行い、対象機器のＥＣＵに組み込まれているソフトウェアの更新を行う（ＯＴＡによる更新を実行する）ための更新用ソフトウェアを受信する。

更新制御部１２０は、車載機器１０に含まれるＥＣＵに対するソフトウェアの更新を制御する。例えば、更新制御部１２０は、記憶部１５０に記憶された機器管理情報１５２を参照し、ＥＣＵごとのソフトウェア識別情報を取得する。また、更新制御部１２０は、取得したソフトウェア識別情報を用いてソフトウェアの更新の有無を問い合わせる問い合わせ情報を生成し、生成した取り合わせ情報を、通信部１１０を介してサーバ装置２００に送信する。また、更新制御部１２０は、通信部１１０により受信されたサーバ装置２００からの問い合わせ結果に基づいて、対象のＥＣＵに組み込まれたソフトウェアの更新を行う。また、更新制御部１２０は、更新処理の結果に基づいて、機器管理情報１５２を更新する。

また、更新制御部１２０は、車載機器１０に含まれるエンジンＥＣＵ２０、トランスミッションＥＣＵ３０、ステアリングＥＣＵ４０、ブレーキＥＣＵ５０、運転制御ＥＣＵ６０、バッテリＥＣＵ７０、およびナビゲーションＥＣＵ８０の各記憶部から各機器の制御情報等を取得し、取得した状態に基づいて、ソフトウェアの更新を制御してもよい。

また、更新制御部１２０は、ソフトウェアを更新するタイミングで、更新対象ＥＣＵが予め決められた実行条件を満たす場合に実行される更新処理以外の処理（スタンバイ処理）が実行されようとしている場合には、スタンバイ処理の実行タイミングや更新処理の実行タイミングを制御してもよい。また、更新制御部１２０は、エネルギー取得部１３０により取得されるバッテリ７２のエネルギー量に基づいて、スタンバイ処理を実行するか否かの制御を行ってもよい。更新制御部１２０の機能の詳細については、後述する。

エネルギー取得部１３０は、所定のタイミングで、バッテリＥＣＵ７０からバッテリ７２のエネルギー量を取得する。所定のタイミングとは、例えば、所定周期でもよく、ソフトウェアの更新処理またはスタンバイ処理が実行されるタイミングでもよい。

表示制御部１４０は、表示部９２に表示させる画像等を生成し、生成した画像を表示部９２に表示させる。例えば、表示制御部１４０は、更新制御部１２０によりソフトウェアの更新に関する情報（例えば、更新結果や更新時の異常情報等）を取得した場合に、取得した情報を車両Ｍの乗員に通知するための画像を生成して、所定のタイミングで表示部９２に表示させる。所定のタイミングとは、例えば、イグニッション・オン状態となったタイミングや、ソフトウェアの更新が正常に終了したタイミング、更新に異常が発生したタイミングである。また、表示制御部１４０は、乗員からの更新指示を受け付けるための画像を生成してもよい。また、表示制御部１４０は、更新情報が、ＯＴＡによる更新が可能な更新である場合には、更新を行うか否かを確認するための画像を生成してもよい。

[更新制御部]
次に、更新制御部１２０の処理の詳細について説明する。以下では、更新制御部１２０で実行させる更新制御の各態様を幾つかのパターンに分けて説明するものとする。

＜第１の更新制御パターン＞
第１の更新制御パターンにおいて、更新制御部１２０は、車両Ｍの停止に伴って、複数のＥＣＵのうち少なくとも一つのＥＣＵに対するソフトウェアの更新を行う場合に、ソフトウェアの更新を行わないＥＣＵ（更新対象外ＥＣＵ）における通信、または、ソフトウェアの更新を行うＥＣＵ（更新対象ＥＣＵ）が制御する機器が車両Ｍの停止に伴って実行する予定であったスタンバイ処理のうち、一方または双方を抑制する。

図４は、第１の更新制御パターンにおいて、更新制御部１２０が実行する処理の一例を示すフローチャートである。第１の更新制御パターンにおいて、更新制御部１２０は、車両Ｍが停止しかたか否かを判定する（ステップＳ１００）。具体的には、更新制御部１２０は、エンジンＥＣＵ２０から取得したエンジン２２の制御が起動状態から停止状態となった場合、またはイグニッション装置９４がイグニッション・オン状態からオフ状態となった場合に車両Ｍが停止した判定する。また、ステップＳ１００の処理において、更新制御部１２０は、予め所定の時刻にソフトウェアの更新の有無等を問い合わせるように設定されている場合には、所定の時刻に車両が停止中であるか否かを判定してもよい。

車両Ｍが停止したと判定された場合、更新制御部１２０は、機器管理情報１５２を参照し、車載機器１０の各ＥＣＵに対応付けられたＥＣＵ−ＩＤおよびソフトウェア識別情報を含む問い合わせ情報を生成する（ステップＳ１０２）。なお、更新制御部１２０は、車両Ｍが停止したと判定された場合に、ステップＳ１０２の処理を実行する前に、各ＥＣＵの起動を継続する継続制御信号を各ＥＣＵに送信してもよい。次に、更新制御部１２０は、生成した問い合わせ情報を通信部１１０によりサーバ装置２００に送信させて、ソフトウェアの更新の有無等の問い合わせを行う（ステップＳ１０４）。

ここで、サーバ装置２００は、ソフトウェア更新装置１００からの問い合わせ情報を受信し、受信した情報に含まれるＥＣＵ−ＩＤのソフト識別情報（例えば、バージョン情報）と、サーバ装置２００の記憶部に記憶されたＥＣＵ−ＩＤに対応付けられた最新のソフトウェア識別情報（バージョン情報）とを照合する。そして、サーバ装置２００は、問い合わせ情報に含まれるソフト識別情報と、サーバ装置２００で管理される最新のソフトウェア識別情報とが合致する場合に、そのＥＣＵ−ＩＤに対応付けられた車載機器１０のＥＣＵは、最新のソフトウェアがインストールされているものと判断し、ソフトウェアの更新をしない（更新無し）と判定する。また、サーバ装置２００は、問い合わせ情報に含まれるソフト識別情報と、サーバ装置２００で管理される最新のソフトウェア識別情報とが合致しない場合に、そのＥＣＵ−ＩＤに対応付けられたＥＣＵのソフトウェアの更新を行う（更新有り）と判定する。そして、サーバ装置２００は、問い合わせ情報に含まれる全てのＥＣＵ−ＩＤに対する更新の有無を判定し、その結果を問い合わせ結果として問い合わせのあった車両Ｍのソフトウェア更新装置１００に送信する。なお、問い合わせ結果には、更新するソフトウェア（プログラム）のデータが含まれていてもよい。

ソフトウェア更新装置１００の通信部１１０は、サーバ装置２００からの問い合わせ結果を受信する（ステップＳ１０６）。次に、更新制御部１２０は、問い合わせ結果に基づいて、更新対象のＥＣＵが存在するか否かを判定する（ステップＳ１０８）。更新対象ＥＣＵが存在すると判定された場合、更新制御部１２０は、更新対象外のＥＣＵに通信を抑制する制御信号を送信する（ステップＳ１１０）。通信を抑制するとは、更新対象外のＥＣＵにおける通信を停止させることである。また、通信を抑制するとは、上記の内容に代えて、所定時間において通信可能なデータ量を通常時（ソフトウェア更新を行わない状態での通信時）よりも少なくすることであってもよい。

次に、更新制御部１２０は、更新対象のＥＣＵのＥＣＵ−ＩＤに基づいて、機器管理情報１５２の実行処理内容および実行条件を参照し（ステップＳ１１２）、ソフトウェアを更新するタイミングと同じタイミングで実行される処理（スタンバイ処理）が存在するか否かを判定する（ステップＳ１１４）。同じタイミングとは、同時に実行されるだけでなく、更新を開始してから終了するまでの間に処理が実行されるタイミングや、更新を開始する時刻よりも所定時間前に実行される処理が含まれる。

同じタイミングで実行されるスタンバ処理が存在する場合、更新制御部１２０は、更新対象ＥＣＵに対するスタンバイ処理の実行を抑制させてソフトウェアの更新を実行させる（ステップＳ１１６）。処理の実行を抑制するとは、処理を実行しない（停止する）ことや、処理を延期すること、処理途中で一時停止することである。また、処理の実行を抑制するとは、上記の内容に代えて、所定時間における処理量を通常時（更新を行わない状態での処理の実行時）よりも少なくすることであってもよい。

また、ステップＳ１１４の処理において、同じタイミングで実行される処理が存在しない場合には、更新対象ＥＣＵにソフトウェアの更新を実行させる（ステップＳ１１８）。ステップＳ１１６およびステップＳ１１８の処理後、更新制御部１２０は、機器管理情報１５２を更新する（ステップＳ１２０）。具体的には、更新制御部１２０は、更新が正常に終了した場合には、ソフトウェア識別情報を更新すると共に、実行履歴を更新する。また、更新制御部１２０は、スタンバイ処理に関する制御内容を実行履歴に登録する。例えば、スタンバイ処理を抑制した場合、更新制御部１２０は、スタンバイ処理の緊急度や優先度等に基づいて、抑制後の処理内容を決定し、決定した処理内容を実行履歴に登録する。例えば、更新制御部１２０は、スタインバイ処理の優先度が基準よりも低い場合、次回のスタンバイ処理の実行時に纏めて処理を実行することを示す情報を実行履歴に登録する。また、スタインバイ処理の優先度が基準よりも高い場合、更新制御部１２０は、更新処理の終了後にスタンバイ処理を実行させることを示す情報を実行履歴に登録する。これにより、本フローチャートの処理は、終了する。また、ステップＳ１００の処理において、車両Ｍが停止していないと判定された場合、またはステップＳ１０８の処理において、問い合わせ結果に更新対象ＥＣＵが存在しないと判定された場合、本フローチャートの処理は、終了する。

また、上述した図４の例では、更新対象外ＥＣＵにおける通信、および更新対象ＥＣＵが制御する機器が車両Ｍの停止に伴って実行する予定であった処理の両方を抑制したが、何れか一方のみを抑制する制御を行ってもよい。また、図４の処理において、更新制御部１２０は、ステップＳ１０２〜ステップＳ１０６の処理を、ステップＳ１００の処理の前の所定のタイミング（例えば、所定周期）で行ってもよい。

以上説明した第１の更新制御パターンによれば、ソフトウェアの更新時に更新対象外ＥＣＵの通信や更新対象ＥＣＵの更新処理以外に実行される処理（スタンバイ処理）を抑制することで、通信負荷や更新処理以外の処理の実行による処理負荷等を抑制することができる。これにより、更新時の外乱要因を抑制することができると共に、迅速に更新処理を実行することができる。また、通信や処理が抑制されることで、更新処理におけるバッテリ７２の電力を確保することができる。したがって、第１の更新制御パターンによれば、より適切にソフトウェア更新処理を実行することができる。

＜第２の更新制御パターン＞
第２の更新制御パターンにおいて、更新制御部１２０は、更新対象外ＥＣＵにおける通信、または、更新対象ＥＣＵのスタンバイ処理のうち、少なくともスタンバイ処理の抑制を行ってソフトウェア更新を行い、ソフトウェアの更新が正常に完了できない状態が所定回数以上継続した場合に、ソフトウェアを更新させる前にスタンバイ処理を実行させる。

図５は、第２の更新制御パターンにおいて、更新制御部１２０が実行する処理の一例を示すフローチャートである。図５に示す処理は、図５に示す第１の更新制御パターンにおけるステップＳ１００〜Ｓ１２０の処理と比較して、更にステップＳ１３０〜Ｓ１３６の処理が追加されている点で相違する。したがって、主に以下では、ステップＳ１３０〜Ｓ１３６の処理を中心として説明するものとし、それ以外の処理の説明は省略する。

第２の更新制御パターンにおいて、更新制御部１２０は、ステップＳ１１６の処理後、ソフトウェアの更新が正常に終了したか否かを判定する（ステップＳ１３０）。正常に終了したと判定された場合、ステップＳ１２０の処理を行う。また、正常に終了していない（例えば、更新時にエラー等の異常が発生した）と判定された場合、更新制御部１２０は、更新処理が正常に終了できなかった回数（以下、異常終了回数と称する）が所定回数以上であるか否かを判定する（ステップＳ１３２）。異常終了回数は、図５に示すフローチャートが開始されるごと（より具体的には、更新処理が実行されるＥＣＵごと）に初期化されるものである。

異常終了回数が所定回数以上ではないと判定された場合、更新制御部１２０は、異常終了回数を１増加させて、ステップＳ１１６の処理に戻る。異常終了回数が、所定回数以上であると判定された場合、更新制御部１２０は、ステップステップＳ１１６の処理において、抑制していたスタンバイ処理をソフトウェアの更新前に実行させ（ステップＳ１３４）、その後、ソフトウェアの更新を実行させる（ステップＳ１３６）。また、更新制御部１２０は、ステップＳ１３６の処理後、ステップＳ１２０の処理を行う。なお、ステップＳ１３６の処理において、ソフトウェアの更新が正常に終了しない場合には、更新制御部１２０は、表示制御部１４０によりエラーメッセージ等を含む画像を生成させて、表示部９２に表示させてもよい。

以上説明した第２の更新制御パターンによれば、第１の更新制御パターンと同様の効果を奏する他、何らかの理由で更新が完了できない状態が所定回数以上継続した場合に、抑制していた処理を更新前に実行させることで、スタンバイ処理の影響による更新処理の不具合を改善することができる。また、スタンバイ処理を実行させることで、更新処理が正常に終了できる可能性を高めることができる。

［ＥＣＵにおけるソフトウェアの更新の具体例］
ここで、ＥＣＵにおけるソフトウェアの更新の具体例について説明する。図６は、ＥＣＵにおけるソフトウェア更新の第１実施例について説明するための図である。図６の例において、横軸は時刻Ｔを示し、時刻Ｔ１〜Ｔ４は、「Ｔ１＜Ｔ２＜Ｔ３＜Ｔ４」の関係が成立しているものとする。また、図６の例では、車載機器１０に含まれるＥＣＵの一例として、エンジンＥＣＵ２０におけるソフトウェア更新の様子を示しているが他のＥＣＵも同様の処理を行う。また、図６の例において、時刻Ｔ１からＴ２までの第１期間および時刻Ｔ３からＴ４までの第３期間は、イグニッション・オン状態であるものとし、時刻Ｔ２からＴ３までの第２期間は、イグニッション・オフ状態（ダウンタイム）であるものとする。

図６の例における第１期間では、記憶部２０Ａに更新前ソフトウェアが格納されており、エンジンＥＣＵ２０は、更新前ソフトウェアを用いてエンジン制御を実行する。また、エンジンＥＣＵ２０は、第２期間において、ソフトウェアの更新処理として記憶部２０Ａに格納された更新前ソフトウェアを削除し、削除した記憶領域に更新後ソフトウェアを格納して更新処理を行う。なお、第２期間に実行予定のスタンバイ処理が存在する場合、エンジンＥＣＵ２０は、更新制御部１２０の制御に基づく、スタンバイ処理を抑制して更新処理を実行する。

また、エンジンＥＣＵ２０は、第２期間内に更新後ソフトウェアのアクティベート処理を行ってもよい。アクティベート処理とは、例えば、更新後ソフトウェアの使用に対して正規のライセンスを持っていること等を確認するための認証処理である。認証が成功すると、エンジンＥＣＵ２０は、第３期間において、更新後ソフトウェアを用いたエンジン制御を実行する。

図７は、ＥＣＵにおけるソフトウェア更新の第２実施例について説明するための図である。第２実施例では、第１実施例と比較して、記憶部２０Ａに更新前のソフトウェアを格納する第１記憶領域Ａ１と、更新後のソフトウェアを格納する第２記憶領域Ａ２とを備えている点で異なる。この場合、エンジンＥＣＵ２０は、第１期間において、第１記憶領域Ａ１に記憶された更新前ソフトウェアを用いてエンジン制御を実行する。また、エンジンＥＣＵ２０は、第１期間において、ソフトウェアの更新を行う場合に、第２記憶領域Ａ２に更新後ソフトウェアを格納する更新処理を行う。なお、第１期間に実行予定のスタンバイ処理が存在する場合、エンジンＥＣＵ２０は、更新制御部１２０の制御に基づき、スタンバイ処理を抑制して更新処理を実行する。

また、エンジンＥＣＵ２０は、第２期間において、更新後ソフトウェアのアクティベート処理を行い、第３期間において、更新後ソフトウェアを用いたエンジン制御を実行する。第１実施例は、第２実施例よりもコストを削減することができる。また、第２実施例は、第１実施例よりもイグニッション・オフ状態の期間（ダウンタイム時間）が短いため、回生電流等によりバッテリ７２内のエネルギー量を確保し易い。また、第２実施例は、更新処理に異常が発生した場合の復帰（リカバリ）がし易い。なお、エンジンＥＣＵ２０は、他の手法でソフトウェアの更新を行ってもよい。

[更新対象ＥＣＵの種類に応じた更新制御の具体例]
次に、更新対象ＥＣＵの種類に応じた更新制御部１２０における更新制御の具体例について説明する。

［更新対象ＥＣＵがエンジンＥＣＵ２０またはトランスミッションＥＣＵ３０である場合］
例えば、更新対象ＥＣＵが、エンジンＥＣＵ２０またはトランスミッションＥＣＵ３０である場合、更新制御部１２０は、スタンバイ処理の一例であるエンジンＥＣＵ２０およびトランスミッションＥＣＵ３０の制御によるクラッチの零点（０点）学習処理を停止させる。クラッチは、車両Ｍの走行時には、エンジン２２の回転を駆動輪等に伝達させ、車両Ｍの発進時や変速時、シフトレバー操作時にはエンジン２２の回転を駆動輪等に伝達させないように回転の伝達のオン・オフを行う装置である。クラッチは、使用による摩耗等により、回転の伝達のオン・オフの切り換わり基準点（零点）が異なる。そのため、エンジンＥＣＵ２０は、トランスミッションＥＣＵ３０と連動して零点学習として、それまでの走行時におけるお互いのクラッチ制御に関する履歴情報を送受信して、その履歴情報から零点のより正確な位置を学習し、学習結果に基づいて零点を適切な位置に補正する。

更新制御部１２０は、エンジンＥＣＵ２０またはトランスミッションＥＣＵ３０のソフトウェア更新を実行させる場合に、上述した零点学習を停止させることで、更新処理にとってノイズとなる零点学習における履歴情報の送受信が行われなくなる。そのため、通信網（例えば、ＣＡＮ通信）における通信負荷（通信の占有等）を削減することができる。また、更新制御部１２０は、ソフトウェア更新時にエンジンＥＣＵ２０またはトランスミッションＥＣＵ３０以外のＥＣＵにおける通信を抑制させることで、通信負荷をより削減することができる。

更に、エンジンＥＣＵ２０およびトランスミッションＥＣＵ３０は、零点学習処理が実行されないため、ソフトウェア更新処理を迅速に行うことができると共に、バッテリ７２からの電力を確保することができる。なお、１回の走行におけるクラッチの摩耗は大きくないため、零点学習処理の優先度は低い。したがって、更新制御部１２０は、零点学習処理が抑制された場合には、次回の学習時に纏めて実行させるように制御を行う。

また、エンジンＥＣＵ２０は、ソフトウェアの更新を行う場合に、他のスタンバイ処理も抑制してもよい。他のスタンバイ処理とは、例えば、アクセルペダルの操作に基づくＤＢＷ（Drive By Wire）の学習処理である。ＤＢＷの学習処理とは、例えば、エンジン２２のスロットル制御（電子制御スロットル）において、車両Ｍのアイドリング時等にスロットルバルブの開度を微小開度に制御する必要があるため、開度の適正値を開度履歴やイグニッション・オフ状態での強制実行によって学習する処理である。

［更新対象ＥＣＵが運転制御ＥＣＵ６０である場合］
次に、更新対象ＥＣＵが運転制御ＥＣＵ６０である場合について説明する。運転制御ＥＣＵ６０は、スタンバイ処理として、運転制御時における制御データを記憶部１５０に書き込む処理（運転情報記憶処理）を行う。例えば、運転制御ＥＣＵ６０は、物体認識装置６２から得られる情報や車両Ｍへの運転制御の状態等に関する情報（例えば、運転制御の各イベント情報）を運転情報として記憶部６０Ａに書き込んでおき、実行条件を満たす場合に、運転情報を運転制御ＥＣＵ６０の記憶部６０Ａからソフトウェア更新装置１００の記憶部１５０に記憶させる運転情報記憶処理を実行する。

更新制御部１２０は、運転制御ＥＣＵ６０のソフトウェア更新を実行させる場合に、上述した走行履歴記録処理を一時的に延期させ、ソフトウェアの更新の完了後に再開させる。これにより、大容量の走行履歴情報の通信によって、通信負荷（通信の占有等）が発生することを抑制することができる。また、更新制御部１２０は、ソフトウェア更新時に運転制御ＥＣＵ６０以外のＥＣＵにおける通信を抑制させることで、通信負荷をより削減することができる。更に、運転制御ＥＣＵ６０は、運転情報記憶処理を実行しないため、ソフトウェア更新処理をより迅速に行うことができる。

なお、更新制御部１２０は、ソフトウェアの更新後に、運転情報記憶処理を実行させる場合に、エネルギー取得部１３０により取得されたバッテリ７２のエネルギー量を取得し、取得したエネルギー量が所定量以上である場合に運転情報記憶処理の実行を行う。また、更新制御部１２０は、バッテリ７２のエネルギー量が所定量未満である場合に次回に纏めて処理を行うように機器管理情報１５２の実行履歴に登録する。このように、エネルギー残量によって、延期したスタンバイ処理を実行するか否か判定することで、更新処理等を行ったことによる電力不足によって、スタンバイ処理が処理の途中で終了してしまうことを抑制することができる。

また、運転制御ＥＣＵ６０が実行するスタンバイ処理に、車両Ｍの走行履歴を学習し、学習結果に基づいて運転制御の内容を調整する走行エイミング学習処理が含まれる場合、更新制御部１２０は、ソフトウェアの更新時の走行エイミング学習処理を抑制する。また、更新制御部１２０は、運転制御ＥＣＵ６０で実行される更新だけでなく、運転制御ＥＣＵ６０が制御する機器（例えば、物体認識装置６２）で実行される処理を抑制してもよい。例えば、物体認識装置６２は、車両周辺の物体の認識精度を高めるため、カメラ６４やレーダ装置６６、ファインダ６８から得られる情報を用いた物体の認識学習処理等を行う。この場合、運転制御ＥＣＵ６０は、スタンバイ処理を抑制する制御情報を更新制御部１２０から取得した場合に、物体認識装置６２に対して認識学習処理を抑制するように制御する。このように、運転制御ＥＣＵ６０が制御する機器の動作を抑制することで、運転制御ＥＣＵ６０の処理負荷をさらに削減することができ、より適切にソフトウェアの更新処理を行わせることができる。なお、更新制御部１２０は、走行エイミング学習処理や認識学習処理を延期させている場合には、更新処理が正常に完了した後に、上記処理を実行させる。

［変形例］
上述した実施形態では、外部装置の一例としてサーバ装置２００を用いたが、これに代えて（または加えて）、ディーラーの作業者（メンテナンス作業者）等が利用する端末装置を用いてもよい。通信部１１０は、例えば、ＵＳＢ（Universal Serial Bus）ケーブル等を用いた有線接続により端末装置と通信することで、特定の端末装置からリプログラミングによる更新を行うための更新用ソフトウェアを受信する。なお、通信部１１０は、特定の端末または作業者との通信しか行わないように端末装置や作業者の識別情報等による認証を行ってもよい。ソフトウェア更新装置１００は、上述した端末装置に代えて、ＵＳＢメモリ等の機器と直接接続し、メモリ内に記憶された更新用ソフトウェア等のデータを取得してもよい。

また、更新制御部１２０は、エネルギー取得部１３０により取得したエネルギー量が所定量未満である場合に、抑制した（例えば、延期した）スタンバイ処理の実行を中止することに加えて、ソフトウェアの更新処理の実行を中止してもよい。これにより、ソフトウェアの更新処理の途中で電力不足により処理が終了することを抑制することができる。この場合、更新制御部１２０は、表示制御部１４０に電力不足により更新処理が実行できなかったことを示す情報や、更新タイミングを調整させるための情報を含む画像を生成させ、イグニッション・オン状態となった場合に、表示部９２に表示させる。

また、更新制御部１２０は、スタンバイ処理の種類によって、ソフトウェアの更新時であっても抑制を行わないようにしてもよい。例えば、更新制御部１２０は、車両Ｍに搭載されるＧセンサの零点補正等のように、運転制御のＶＳＡの中で完結でき、処理量も少なく、更新処理における外乱要因とならないスタンバイ処理については、運転制御ＥＣＵのソフトウェアの更新であっても処理を実行させる。これにより、ソフトウェアの更新処理とスタンバイ処理とを効率的に実行することができる。

また、本実施形態では、ソフトウェア更新装置１００からサーバ装置２００にソフトウェア更新の問い合わせを行ったが、これに代えて、問い合わせを行わずにサーバ装置２００等の外部装置から更新ソフトウェアに関する情報（例えば、更新指示）を取得した場合に、上述した更新制御処理を実行してもよい。この場合、更新制御部１２０は、サーバ装置２００の更新指示に基づいて、更新対象ＥＣＵの更新用ソフトウェアをダウンロードし、上述したようにスタンバイ処理の実行を抑制してソフトウェアの更新処理を実行する。

以上、説明したように実施形態によれば、ソフトウェア更新装置１００は、サーバ装置（外部装置の一例）２００と通信する通信部１１０と、通信部１１０によるサーバ装置２００との通信により、車両Ｍに搭載された機器を制御する複数の機器制御部（ＥＣＵ）に組み込まれたソフトウェアを更新する更新制御部１２０と、を備え、更新制御部１２０は、車両Ｍの停止に伴って、複数の機器制御部のうち少なくとも一つの機器制御部に対するソフトウェアの更新を行う場合に、ソフトウェアの更新を行わない機器制御部における通信、または、ソフトウェアの更新を行う機器制御部が車両Ｍの停止に伴って実行する処理のうち、一方または双方を抑制することにより、より適切にソフトウェア更新処理を実行することができる。

また、本実施形態によれば、例えば、所定のＥＣＵのスタンバイ処理の実行を抑制することで、ソフトウェア更新処理における電力を確保することができ、他のＥＣＵにおける通信を抑制することで、通信路の付加を軽減することができる。これにより、従来では、イグニッション・オフ状態になった後に、ソフトウェアのインストールやアクティベート処理を行う場合に、更新対象ＥＣＵの準備を待ってから実行していたのに対して、正確かつ早期にＯＴＡを実行することができる。

以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

１…ソフトウェア更新システム、２…車両システム、１０…車載機器、２０…エンジンＥＣＵ、３０…トランスミッションＥＣＵ、４０…ステアリングＥＣＵ、５０…ブレーキＥＣＵ、６０…運転制御ＥＣＵ、７０…バッテリＥＣＵ、８０…ナビゲーションＥＣＵ、９０…操作部、９２…表示部、９４…イグニッション装置９４、１００…ソフトウェア更新装置、１１０…通信部、１２０…更新制御部、１３０…エネルギー取得部、１４０…表示制御部、１５０、２０Ａ〜８０Ａ…記憶部、２００…サーバ装置、Ｍ…車両

Claims (8)

1. 外部装置と通信する通信部と、
   前記通信部による前記外部装置との通信により、車両に搭載された機器を制御する複数の機器制御部に組み込まれたソフトウェアのうち少なくとも一つを更新する更新制御部と、を備え、
   前記更新制御部は、前記車両の停止に伴って、前記複数の機器制御部のうち少なくとも一つの機器制御部に対する前記ソフトウェアの更新を行う場合に、前記ソフトウェアの更新を行わない機器制御部における通信、または、前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って実行する処理のうち、一方または双方を抑制することを特徴とするソフトウェア更新装置。
2. 前記複数の機器制御部は、前記車両が走行するための走行駆動力を駆動輪に出力する内燃機関を制御する第１機器制御部と、前記車両に搭載された変速機を制御する第２機器制御部とを含み、
   前記更新制御部は、前記第１機器制御部または第２機器制御部のうち一方または双方に対する前記ソフトウェアの更新がある場合に、前記第１機器制御部および前記第２機器制御部において前記車両の停止に伴って実行する処理を停止させることを特徴とする請求項１に記載のソフトウェア更新装置。
3. 前記車両の運転情報を記憶する記憶部を更に備え、
   前記更新制御部は、前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って、前記運転情報を前記記憶部に記憶させる処理を実行する場合に、前記処理を延期し、前記ソフトウェアの更新後に前記処理を実行させることを特徴とする請求項１または２に記載のソフトウェア更新装置。
4. 前記更新制御部は、前記ソフトウェアの更新が正常に終了できない状態が所定回数以上継続した場合に、前記ソフトウェアを更新させる前に前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って実行する処理を実行させることを特徴とする請求項１から３のうち何れか１項に記載のソフトウェア更新装置。
5. 前記車両に搭載されたバッテリのエネルギー量を取得するエネルギー取得部を更に備え、
   前記更新制御部は、前記エネルギー取得部により取得された前記エネルギー量に基づいて、前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って実行する処理の実行を制御することを特徴とする請求項１から４のうち何れか１項に記載のソフトウェア更新装置。
6. 前記複数の機器制御部は、前記車両の操舵または速度のうち一方または双方を制御して運転制御を行う第３機器制御部を含み、
   前記更新制御部は、前記第３機器制御部に対する前記ソフトウェアの更新がある場合に、前記第３機器制御部によって制御される機器における処理を抑制することを特徴とする請求項１から５のうち何れか１項に記載のソフトウェア更新装置。
7. 車両に搭載されるソフトウェア更新装置が、
   外部装置と通信し、
   前記外部装置との通信により、車両に搭載された機器を制御する複数の機器制御部に組み込まれたソフトウェアのうち少なくとも一つを更新し、
   前記車両の停止に伴って、前記複数の機器制御部のうち少なくとも一つの機器制御部に対する前記ソフトウェアの更新を行う場合に、前記ソフトウェアの更新を行わない機器制御部における通信、または、前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って実行する処理のうち、一方または双方を抑制することを特徴とするソフトウェア更新方法。
8. 車両に搭載されるソフトウェア更新装置に、
   外部装置と通信させ、
   前記外部装置との通信により、車両に搭載された機器を制御する複数の機器制御部に組み込まれたソフトウェアのうち少なくとも一つを更新させ、
   前記車両の停止に伴って、前記複数の機器制御部のうち少なくとも一つの機器制御部に対する前記ソフトウェアの更新を行う場合に、前記ソフトウェアの更新を行わない機器制御部における通信、または、前記ソフトウェアの更新を行う機器制御部が前記車両の停止に伴って実行する処理のうち、一方または双方を抑制させることを特徴とするプログラム。

Images