WO2012002231A1

WO2012002231A1 - 制御装置

Info

Publication number: WO2012002231A1
Application number: PCT/JP2011/064310
Authority: WO
Inventors: 英明菅沼; 後藤　剛
Original assignee: トヨタ自動車株式会社
Priority date: 2010-06-29
Filing date: 2011-06-22
Publication date: 2012-01-05
Also published as: JP5240248B2; EP2590077B1; CN102971713A; US20130096737A1; US9031715B2; JP2012014253A; EP2590077A4; CN102971713B; EP2590077A1

Abstract

　車両に搭載される制御手段の制御内容を変更する制御装置であって、車両に係るスケジュールを取得するスケジュール取得手段と、スケジュール取得手段によって取得されたスケジュールに基づいて車両が使用されない時間帯を推定し、当該時間帯に応じて制御内容の変更を行う変更日時を生成して出力する変更日時生成手段と、を備える。

Description

制御装置

　本発明は、車両に搭載された制御手段の制御内容を変更する制御装置に関する。

　従来、車両の内部に搭載された装置を制御するプログラムを更新する技術が提案されている。例えば、下記の特許文献１に記載の車載ゲートウェイ装置では、サーバからプログラムを受け付けると、既に車載ゲートウェイ装置に記憶されているプログラムを、当該受け付けたプログラムに更新する。

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

　ところで、電子制御装置（制御手段）であるＥＣＵ（Electronic Control Unit)のプログラムを更新する場合、プログラムの更新内容によっては、プログラムを更新している間車両を停車させていることが必要となる場合がある。しかしながら、プログラムの更新に対応するために車両を停車させておける時間帯は、ユーザ毎にまちまちである。そのため、プログラムの更新日時が一概に設定されている場合には、設定された更新日時にユーザがプログラムの更新に対応できない場合がある。重要度の高いプログラムにあっては、早めの更新が好ましい。そのためには、車両を所有するユーザの都合、すなわち車両の利用状況に応じたプログラムの更新日時を生成することが必要となる。

　本発明は、上記課題を解決するためになされたものであり、車両の利用状況に応じて制御手段の制御内容の変更日時を生成できる制御装置を提供することを目的とする。

　上記課題を解決するために、本発明に係る制御装置は、車両に搭載される制御手段の制御内容を変更する制御装置であって、車両に係るスケジュールを取得するスケジュール取得手段と、スケジュール取得手段によって取得されたスケジュールに基づいて車両が使用されない時間帯を推定し、当該時間帯に応じて制御内容の変更を行う変更日時を生成して出力する変更日時生成手段と、を備えることを特徴とする。

　この制御装置では、車両に係るスケジュールを取得し、取得したスケジュールに基づいて車両が使用されない時間帯を推定して更新日時を生成して出力する。このように、車両に係るスケジュールを取得することで、車両が使用されない時間帯、すなわち車両の利用状況を推定することができる。そのため、車両の利用状況に応じた制御内容の変更日程を生成することが可能となる。

　スケジュール取得手段は、車両の外部の端末からスケジュールを取得することが好ましい。この場合には、車両を所有するユーザのスケジュールを例えば携帯電話やパソコン等といった外部の端末のスケジューラから取得することができるため、車両の利用状況を好適に把握することができる。

　スケジュールは、車両を所有するユーザの行動予定であることが好ましい。この場合には、車両を所有するユーザの行動予定を取得することで、車両を利用しない日時（利用する日時）を推定することができる。そのため、車両を所有するユーザの都合に応じた制御手段の制御内容の変更日時を好適に生成することができる。

　スケジュールは、車両の利用状況、利用環境、利用予定の少なくとも一つを含むことが好ましい。この場合には、例えば車両が社用車やレンタカー等といった法人で管理されている場合、車両の利用状況や貸し出し状況等を取得することで、車両を利用しない日時を推定することができる。そのため、車両を所有するユーザの都合に応じた制御手段の制御内容の変更日時を好適に生成することができる。

　制御手段は、電子制御装置であり、変更日時生成手段は、スケジュール取得手段によって取得されたスケジュールに基づいて車両が使用されない時間帯を推定し、当該時間帯に応じて電子制御装置のプログラムの変更を行う変更日時を生成して出力することが好ましい。このような構成によれば、車両の利用状況に応じて電子制御装置（ＥＣＵ）のプログラムの変更日時を生成できる。

　本発明によれば、車両の利用状況に応じて制御手段の制御内容の変更日時を生成できる。

図１は、一実施形態に係る制御装置であるプログラム配信センターを含むプログラム更新システムの構成を示す図である。図２は、個人ユーザのスケジュールに係るデータを保持されているテーブルの一例を示す図である。図３は、法人ユーザのスケジュールに係るデータが保持されているテーブルの一例を示す図である。図４は、プログラム配信センターの構成を示す図である。図５は、プログラム配信センターの動作を示すフローチャートである。図６は、個人ユーザのリプロスケジュール生成処理を示すフローチャートである。図７は、個人ユーザにおけるプログラム配信システムのシーケンス図である。図８は、法人ユーザのリプロスケジュール生成処理を示すフローチャートである。図９は、法人ユーザにおけるプログラム配信システムのシーケンス図である。

　以下、図面を参照しながら、実施形態について詳細に説明する。なお、説明において、同一要素又は同一機能を有する要素には、同一符号を用いることとし、重複する説明は省略する。

　図１は、一実施形態に係る制御装置であるプログラム配信センターを含むプログラム更新システムの構成図である。図１に示すように、プログラム更新システム１は、プログラム配信センター２と、データセンター３と、オペレータセンター４と、車両５とを含んで構成されている。プログラム配信センター２、データセンター３及びオペレータセンター４は、ネットワークを介して互いに通信可能に接続されている。

　データセンター３は、例えば自動車メーカによって運営されており、自動車といった車両５が有する電子制御装置（制御手段）であるリプロ対象ＥＣＵ（Electronic Control Unit）５４（後述）の制御内容の変更であるプログラム更新（以下、リプログラミング）、追加及び削除の際の案内や指示を行う。データセンター３は、車両５に関する各種のデータを保持する情報ＤＢ（データベース）３０を備えている。情報ＤＢ３０は、車両５に関する車両情報を格納する車両情報ＤＢ、車両５の整備履歴に関する情報を格納する整備記録ＤＢ、ドライバーの運転特性等のドライバー学習情報を格納するドライバー学習ＤＢ、車両５に搭載されるナビゲーションシステムの設定（ホーム設定等）に関するナビ設定情報を格納するナビ設定情報ＤＢから構成されている。また、データセンター３は、ドライバー学習情報及びナビ設定情報から特定される顧客情報を管理している。

　また、データセンター３は、保持している情報ＤＢ３０に格納されたデータに基づいて、ユーザへのリプログラミングの案内方法を設定する。具体的には、データセンター３は、車両５のユーザの特性情報（性別、年齢、ナビゲーションシステムの利用状況、リプログラミング実施頻度等）に基づいて、ユーザへのリプログラミングの案内方法を設定する。プログラム更新の案内方法としては、リプログラミングの通知のみ（ユーザがガイドに沿って更新）、オペレータセンター４のオペレータによってユーザに直接更新の手順を案内するといった手法がある。

　また、データセンター３は、プログラム配信センター２やオペレータセンター４から出力されたデータを車両５に転送すると共に、車両５から送信されたデータをプログラム配信センター２やオペレータセンター４に転送する。

　オペレータセンター４は、オペレータが常駐しており、オペレータによって各車両５で実行されるリプログラミングの管理や監視をサポートするセンターである。オペレータセンター４は、データ通信機能を有しており、データセンター３とデータを送受信する。したがって、オペレータセンター４と車両５とのデータ通信は、データセンター３を介して行われる。

　オペレータセンター４は、プログラム配信センター２から送信されるリプロデータ（リプログラミングの開始予定時刻、処理時間、車両停車位置等）を受信すると、リプロデータに基づいて、リプログラミングを行う間のオペレータを確保できるか否かを判断し、オペレータの確保情報をプログラム配信センター２に送信する。ここで、オペレータが確保できた場合、そのオペレータは、開始予定時刻前に待機することになる。この際、オペレータセンター４では、その予約している車両５に接続し、オペレータが目的地付近でオペレータの監視の元でリプログラミングを実行することをドライバーに対して通知する。また、予約している車両５のリプロ管理ＥＣＵ５３からオペレータセンター４に自動接続されると、オペレータセンター４では、待機しているオペレータが対応する。

　また、オペレータセンター４は、顧客情報ＤＢ４０を備えている。顧客情報ＤＢ４０には、データセンター３の車両情報ＤＢの車両情報に紐付けられた顧客情報が格納されている。また、オペレータセンター４は、ネットワークＮＷを介してスケジュールＤＢ６及び企業ＤＢ７に接続されている。スケジュールＤＢ６及び企業ＤＢ７は、例えばネットワーク上で共有されるデータベースサーバである。

　スケジュールＤＢ６は、車両５を所有するユーザの個人的なスケジュールを格納しているデータベースである。スケジュールＤＢ６には、個人ユーザのパソコン、携帯電話、ＰＤＡ（Personal Digital Assistant）等の車両５の外部の端末によりスケジューラに入力されたスケジュールが格納されている。ユーザのスケジューラとスケジュールＤＢ６との連携は、ユーザの登録によって行われる。図２は、個人ユーザのスケジュールに係るデータが保持されているテーブルの一例を示す図である。図２に示すように、スケジュールＤＢ６には、顧客情報に紐付けられた「ユーザＩＤ」、「用件名」、「場所」、「時間」、「用件種別」が対応付けて保持されている。

　企業ＤＢ７は、社用車・商用車を有する企業やレンタカー会社等のスケジュールを格納しているデータベース（車両管理システム）である。企業ＤＢ７には、法人ユーザのパソコン、車両を所有するオーナーの携帯電話やＰＤＡ等によりスケジューラに入力されたスケジュールが格納されている。図３は、法人ユーザのスケジュールに係るデータが保持されているテーブルの一例を示す図である。図４に示すように、企業ＤＢ７には、顧客情報に紐付けられた「車両ＩＤ」、「車種」、「用途」、「用件名」、「保管場所」が対応付けて保持されている。

　プログラム配信センター２は、リプロ対象ＥＣＵ５４のプログラムを遠隔操作により更新管理するプログラム更新装置（制御装置）である。プログラム配信センター２は、図４に示すように、ユーザ情報取得部２１と、プログラム管理ＤＢ２２と、スケジュール取得部（スケジュール取得手段）２３と、時間帯推定部２４と、リプロスケジュール生成部（変更日時生成手段）２５と、リプロスケジュール設定部２６とを備えている。プログラム配信センター２は、データ通信機能を有しており、データセンター３とデータを送受信する。したがって、プログラム配信センター２と車両５とのデータ通信は、データセンター３を介して行われる。なお、プログラム配信センター２であるプログラム更新装置は、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、通信モジュール等を備えるサーバ装置である。

　ユーザ情報取得部２１は、プログラムの更新が必要な車両を所有するユーザの情報を取得する部分である。ユーザ情報取得部２１は、各車両５のサポートを行う事業者等によって、電子制御装置のプログラムを管理するプログラム管理ＤＢ２２に更新用プログラムが新たに格納されると、そのプログラムの更新が必要な該当車両のユーザに係る情報を取得する。具体的には、ユーザ情報取得部２１は、データセンター３に登録情報取得要求を送信し、更新用プログラムに含まれる対象車両を示す情報から車種、年式、車体番号に係る車両情報を取得する。ユーザ情報取得部２１は、車両情報を取得すると、オペレータセンター４に顧客情報取得要求を送信し、車両情報に紐付けられた車両の所有者名義等を示すユーザ情報（顧客情報）を取得する。ユーザ情報取得部２１は、取得したプログラム更新の該当車両に係るユーザ情報をスケジュール取得部２３に出力する。

　スケジュール取得部２３は、車両５に係るスケジュールを取得する部分である。スケジュール取得部２３は、ユーザ情報取得部２１から出力されたユーザ情報を受け取ると、ユーザ情報が示すユーザのスケジューラがスケジュールＤＢ６、企業ＤＢ７と連携されている場合に、車両を所有するユーザのスケジュールを取得する。具体的には、スケジュール取得部２３は、ユーザ情報に基づいて、スケジュールＤＢ６又は企業ＤＢ７からユーザのスケジュールを取得する。ユーザのスケジュールとは、ユーザが個人である場合には、車両５を所有するユーザの個人的な行動予定（例えば、出張、会議等）であり、ユーザが法人である場合には、所有者となっているオーナーのスケジュールや車両の管理状況、レンタカーの利用状況・予約状況等である。スケジュール取得部２３は、取得した車両に係るスケジュールを示すスケジュール情報を時間帯推定部２４及びリプロスケジュール生成部２５に出力する。

　時間帯推定部２４は、ユーザのスケジュールから車両５が使用されない時間帯を推定する部分である。時間帯推定部２４は、スケジュール取得部２３から出力されたスケジュール情報を受け取ると、このスケジュール情報に基づいて車両が使用されない時間帯を推定する。具体的には、時間帯推定部２４は、予め設定されたリプログラミングの候補時間に予定があるか否かを判定し、候補時間に予定がある場合、その候補時間の時間帯が車両５が使用されない時間帯であるか否かを推定する。時間帯推定部２４は、スケジュール情報において、あいまい検索や行動補間推定等の処理を行い、例えば「打ち合わせ（打合せ）」、「出張」等の予定を抽出し、当該予定の時間帯を取得する。

　より詳細には、時間帯推定部２４は、個人ユーザの場合には、図２に示すように、例えば通勤に毎日車両を使用（過去の蓄積情報から推定）しているユーザ（例えば、ユーザＩＤ：０００１）のスケジュール情報において、スケジュールに「打ち合わせ（場所：勤務先（会議室））」の予定が入っている場合には、打ち合わせの時間帯には勤務先の会議室に在室し、車両を使用しない可能性が高いとして、当該時間帯（９：００～１１：００）を車両が使用されない時間帯として推定する。あるいは、時間帯推定部２４は、例えば車両をユーザのみが使用（過去の蓄積情報から推定）しており、東京在住であるユーザ（ユーザＩＤ：０００２）のスケジュール情報において、スケジュールに「国内出張（場所：名古屋）」の予定が入っている場合には、新幹線での移動時間は車両を使用しない可能性が高いとして、当該時間帯（８：００～１１：００）を車両が使用されない時間帯として推定する。

　また、時間帯推定部２４は、法人やレンタカー会社の場合には、スケジュール情報の保管場所（図３参照）に基づいて、車両５が電波の届かない場所（例えば、屋内（地下）駐車場）において保管されているか否かを判定し、車両５が電波の届かない場所に保管されていると判定した場合には、電波の届かない場所に停車している時間帯をスケジュール情報から推定する。時間帯推定部２４は、推定した時間帯を示す時間帯情報をリプロスケジュール生成部２５に出力する。

　リプロスケジュール生成部２５は、スケジュール取得部２３によって取得されたユーザのスケジュール及び時間帯推定部２４によって推定された時間帯に応じて、リプログラミングを行うリプロスケジュールを生成して出力する部分である。リプロスケジュール生成部２５は、ユーザが個人の場合には、時間帯推定部２４から出力された時間帯情報を受け取ると、この時間帯情報が示す時間帯をリプログラミングのスケジュール（リプロスケジュール）として生成する。

　また、リプロスケジュール生成部２５は、ユーザが法人の場合には複数台車両を所有していることが多いため、時間帯推定部２４から時間情報を受け取ると、複数の車両が短時間で集中的にプログラミングが実施できるリプロスケジュールを生成する。また、リプロスケジュール生成部２５は、車両の種別、用途（スケジュール情報）に応じて、利用頻度が低いと想定される日時（曜日）を優先してリプロスケジュールを生成する。具体的には、リプロスケジュール生成部２５は、車両が社用車である場合には、利用頻度が高い平日の日中はリプログラミングの候補日程の優先度を低くし、車両がレジャー用のレンタカーである場合には、土日・繁忙期はリプログラミングの候補日程の優先度を低くして、リプロスケジュールを生成する。リプロスケジュール生成部２５は、生成したリプロスケジュールを示すリプロスケジュール情報をデータセンター３に送信（出力）する。リプロスケジュール情報を受け取ったデータセンター３は、リプロスケジュール情報を車両５に転送する。

　リプロスケジュール設定部２６は、ユーザに送信したリプロスケジュールに対して、ユーザから承諾を示す応答があった場合に、リプロスケジュールを設定する部分である。リプロスケジュール設定部２６は、リプロスケジュール生成部２５からリプロスケジュールが出力された後に、データセンター３を介してリプロスケジュールを承諾する旨の応答情報を車両５から受け取った場合、提案したリプロスケジュールに沿ったリプログラミングのスケジュールを設定する。また、リプロスケジュール設定部２６は、車両５が電波の届かない場所に保管されている場合には、車両の利用中に更新用のプログラムのダウンロードを実施するように設定する。リプロスケジュール設定部２６は、設定したリプログラミングのスケジュールを示すリプロデータをオペレータセンター４に送信する。

　車両５は、通信部５１と、センサ５２と、リプロ管理ＥＣＵ５３と、リプロ対象ＥＣＵ５４とを備えている。通信部５１は、データセンター３とデータの送受信を行う部分であり、データセンター３から送信されたデータを受信してリプロ管理ＥＣＵ５３に出力すると共に、リプロ管理ＥＣＵ５３から出力されたデータをデータセンター３に送信する。

　センサ５２は、生体情報やシート着座位置等の情報を取得する部分である。センサ５２は、取得した情報をリプロ管理ＥＣＵ５３に出力する。

　リプロ管理ＥＣＵ５３は、リプログラミングに関する処理を統括する部分である。リプロ管理ＥＣＵ５３では、リプログラミングの管理、リプログラミングの要求受付、リプログラミング実施の可否判断（車両が停止中か否かの判断等）、リプログラミングの操作手順の通知、センサ５２によって取得された情報に基づいてドライバーの運転特性を学習して送信する処理等が行われる。リプロ管理ＥＣＵ５３は、プログラム配信センター２から送信されたリプロスケジュール情報を受信すると、リプロスケジュール情報を例えばナビゲーションシステムのディスプレイに表示（ユーザに提示）する。リプロ管理ＥＣＵ５３は、リプロスケジュール情報をユーザに提示した後に、入力受付手段（タッチパネル、スイッチ等）にリプロスケジュール情報に対する回答（承諾／キャンセル）がユーザによって入力された場合、その旨を示す応答情報を通信部５１によってプログラム配信センター２に送信する。

　また、リプロ管理ＥＣＵ５３では、リプロ対象ＥＣＵ５４にてリプログラミングが終了した後、リプログラミングが成功したか否かを判断する。そして、リプロ管理ＥＣＵ５３では、リプログラミングが成功／失敗の判定結果をデータセンター３を介してオペレータセンター４に送信する。

　リプロ対象ＥＣＵ５４は、プログラミングの更新対象となる電子制御ユニットである。リプロ対象ＥＣＵ５４は、リプロ管理ＥＣＵ５３から出力された更新プログラムを受け取ると、リプログラミング対象のソフトウェアのプログラムを書き換える。リプロ対象ＥＣＵ５４は、ＣＰＵ、ＲＯＭ、ＲＡＭを含むコンピュータを主体として構成されており、リプロ対象ＥＣＵ５４の各機能は、ＲＯＭやＲＡＭ上に車両５の制御に係るプログラムを読み込ませ、このプログラムをＣＰＵによって実行することで実現される。

（個人ユーザのリプロスケジュール設定）
　続いて、プログラム配信センター２の動作について、図５，６を参照しながら説明する。図５は、プログラム配信センターの動作を示すフローチャートであり、図６は、リプロスケジュール生成処理を示すフローチャートである。なお、以下の説明においては、ユーザが個人である場合について例示する。

　図５に示すように、まずリプロスケジュール生成処理が実行される（ステップＳ０１）。

　リプロスケジュール生成処理では、図６に示すように、まずリプログラミングの対象車両を所有するユーザが、ユーザ情報取得部２１にて特定される（ステップＳ１１）。次に、特定されたユーザのスケジューラがスケジュールＤＢ６と連携済みであるか否かがスケジュール取得部２３によって判定される（ステップＳ１２）。ユーザのスケジューラがスケジュールＤＢ６と連携済みであると判定された場合には、ステップＳ１３に進む。一方、ユーザのスケジューラがスケジュールＤＢ６と連携済みであると判定されなかった場合には、ステップＳ１８に進む。

　ステップＳ１３では、スケジュール取得部２３によってユーザのスケジュールが取得される。そして、予め設定された候補時間帯に、ユーザの予定があるか否かが判定される（ステップＳ１４）。ユーザの予定があると判定された場合には、ステップＳ１５に進む。一方、ユーザの予定があると判定されなかった場合には、ステップＳ１８に進む。

　ステップＳ１５では、ユーザの予定が車両５を使用しない予定であるか否か、つまり車両５を使用しない時間帯が時間帯推定部２４にて判定される。ユーザの予定が車両５を使用しない予定であると判定された場合には、ステップＳ１６に進む。一方、ユーザの予定が車両５を使用しない予定であると判定されなかった場合には、ステップＳ１８に進む。

　ステップＳ１６では、車両５を使用しない時間帯の前後に予定がないか否かが時間帯推定部２４によって判定される。車両５を使用しない時間帯の前後に予定がないと判定された場合には、リプロスケジュール生成部２５によってリプロスケジュールが生成され（ステップＳ１７）、リプロスケジュール生成処理が終了する。一方、車両５を使用しない時間帯の前後に予定がないと判定されなかった場合には、ステップＳ１８に進む。ステップＳ１８では、リプロスケジュールの候補日程の見直しが行われ、プログラム配信センター２の処理が終了する。

　図５に戻って、リプロスケジュール生成処理によってリプロスケジュールが生成されると、サーバの状態が良好であるか（混雑していないか）否かが判定される（ステップＳ０２）。サーバの状態が良好であると判定された場合には、リプロスケジュールが車両５に送信される（ステップＳ０３）。一方、サーバの状態が良好であると判定されなかった場合には、処理が終了する。

　続いて、リプロスケジュールを車両５に送信したことに応じて、車両５から送信された応答情報においてユーザがリプロスケジュールを承諾したことを示しているか否かが判定される（ステップＳ０４）。ユーザがリプロスケジュールを承諾したと判定された場合には、リプロスケジュール設定部２６によって車両５のリプロスケジュールが設定される（ステップＳ０５）。一方、ユーザがリプロスケジュールを承諾したと判定されなかった場合には、ステップＳ０１に戻って処理を繰り返す。

　次に、プログラム更新システム１の動作について、図７を参照しながら説明する。図７は、プログラム更新システムの動作を示すシーケンス図である。

　図７に示すように、まずプログラム配信センター２からデータセンター３に登録情報取得要求が送信される（ステップＳ２１）。プログラム配信センター２から送信された登録情報要求を受信したデータセンター３では、情報ＤＢ３０を参照して車両情報等の登録情報が抽出され、その登録情報がプログラム配信センター２に送信される（ステップＳ２２）。データセンター３から送信された登録情報を受信したプログラム配信センター２では、登録情報に対応する顧客情報の取得を要求する顧客情報取得要求がオペレータセンター４に送信される（ステップＳ２３）。プログラム配信センター２から送信された顧客情報取得要求を受信したオペレータセンター４では、顧客情報ＤＢ４０を参照して車両情報に対応する顧客情報が抽出され、その顧客情報がプログラム配信センター２に送信される（ステップＳ２４）。

　オペレータセンター４から送信された顧客情報を受信したプログラム配信センター２では、顧客情報に示されるユーザのスケジュールの取得を要求するスケジュール情報取得要求がスケジュールＤＢ６に送信される（ステップＳ２５）。プログラム配信センター２から送信されたスケジュール情報取得要求を受信したスケジュールＤＢ６では、ユーザに対応するスケジュール情報が抽出され、そのスケジュール情報がプログラム配信センター２に送信される（ステップＳ２６）。

　スケジュールＤＢ６から送信されたスケジュール情報を受信したプログラム配信センター２では、リプロスケジュールが生成され（ステップＳ２７）、このリプロスケジュールがデータセンター３を介して車両５に送信される（ステップＳ２８）。プログラム配信センター２から送信されたリプロスケジュールを受信した車両５では、リプロスケジュールがユーザに対して提示され、リプロスケジュールの可否に対する応答情報がプログラム配信センター２に送信される（ステップＳ２９）。車両５から送信された応答情報を受信したプログラム配信センター２では、リプロスケジュールが設定される（ステップＳ３０）。

（法人ユーザのリプロスケジュール設定）
　続いて、法人ユーザの場合におけるプログラム配信センター２の動作について、図８を参照しながら説明する。なお、図６に示す処理については、個人ユーザの場合と同様の処理であるためその説明を省略する。

　リプロスケジュール生成処理では、図８に示すように、まずリプログラミングの対象車両を所有するユーザが、ユーザ情報取得部２１にて特定される（ステップＳ３１）。次に、特定されたユーザ（オーナー、企業）のスケジューラが企業ＤＢ７と連携済みであるか否かがスケジュール取得部２３によって判定される（ステップＳ３２）。ユーザのスケジューラが企業ＤＢ７と連携済みであると判定された場合には、ステップＳ３３に進む。一方、ユーザのスケジューラが企業ＤＢ７と連携済みであると判定されなかった場合には、ステップＳ３９に進む。

　ステップＳ３３では、スケジュール取得部２３によってユーザのスケジュールが取得される。そして、予め設定された候補時間帯に、ユーザの予定（社用車の使用やレンタカーの予約等）があるか否かが判定される（ステップＳ３４）。ユーザの予定があると判定された場合には、ステップＳ３５に進む。一方、ユーザの予定があると判定されなかった場合には、ステップＳ３９に進む。

　ステップＳ３５では、候補時間帯の前後に予定がないか否かが時間帯推定部２４によって判定される。車候補時間帯の前後に予定がないと判定された場合には、ステップＳ３６に進む。一方、車候補時間帯の前後に予定がないと判定されなかった場合には、ステップＳ３９に進む。

　ステップＳ３６では、車両５の保管場所が電波の届かない場所であるか否かが時間帯推定部２４によって判定される。車両５の保管場所が電波の届かない場所であると判定された場合には、リプロスケジュール設定部２６によってダウンロード日程が調整される（ステップＳ３７）。一方、車両の保管場所が電波の届かない場所であると判定されなかった場合には、ステップＳ３８に進む。

　ステップＳ３８では、リプロスケジュール生成部２５によってリプロスケジュールが生成され、リプロスケジュール生成処理が終了する。ステップＳ３９では、リプロスケジュールの候補日程の見直しが行われ、プログラム配信センター２の処理が終了する。

　次に、プログラム更新システム１の動作について、図９を参照しながら説明する。図９は、プログラム更新システムの動作を示すシーケンス図である。

　図９に示すように、まずプログラム配信センター２からデータセンター３に登録情報取得要求が送信される（ステップＳ４１）。プログラム配信センター２から送信された登録情報要求を受信したデータセンター３では、情報ＤＢ３０を参照して車両情報等の登録情報が抽出され、その登録情報がプログラム配信センター２に送信される（ステップＳ４２）。データセンター３から送信された登録情報を受信したプログラム配信センター２では、登録情報に対応する顧客情報の取得を要求する顧客情報取得要求がオペレータセンター４に送信される（ステップＳ４３）。プログラム配信センター２から送信された顧客情報取得要求を受信したオペレータセンター４では、顧客情報ＤＢ４０を参照して車両情報に対応する顧客情報が抽出され、その顧客情報がプログラム配信センター２に送信される（ステップＳ４４）。

　オペレータセンター４から送信された顧客情報を受信したプログラム配信センター２では、顧客情報に示されるユーザのスケジュールの取得を要求するスケジュール情報取得要求がスケジュールＤＢ６に送信される（ステップＳ４５）。プログラム配信センター２から送信されたスケジュール情報取得要求を受信したスケジュールＤＢ６では、ユーザに対応するスケジュール情報が抽出され、そのスケジュール情報がプログラム配信センター２に送信される（ステップＳ４６）。

　企業ＤＢ７から送信されたスケジュール情報を受信したプログラム配信センター２では、車両５の保管場所を示す車両保管場所情報の取得を要求する車両保管場所情報取得要求が企業ＤＢ７に送信される（ステップＳ４７）。プログラム配信センター２から送信された車両保管場所情報取得要求を受信した企業ＤＢ７では、車両５の保管場所情報が抽出され、その車両保管場所情報がプログラム配信センター２に送信される（ステップＳ４８）。

　企業ＤＢ７から送信されたスケジュール情報及び車両保管情報を受信したプログラム配信センター２では、リプロスケジュールが生成され（ステップＳ４９）、このリプロスケジュールがデータセンター３を介して車両５に送信される（ステップＳ５０）。プログラム配信センター２から送信されたリプロスケジュールを受信した車両５では、リプロスケジュールがユーザに対して提示され、リプロスケジュールの可否に対する応答情報がプログラム配信センター２に送信される（ステップＳ５１）。車両５から送信された応答情報を受信したプログラム配信センター２では、リプロスケジュールが設定される（ステップＳ５２）。

　以上説明したように、プログラム配信センター２は、車両５に搭載されたリプロ対象ＥＣＵ５４のプログラムを更新するためのプログラム更新装置であって、車両５に係るスケジュールをスケジュール取得部２３によって取得し、取得したスケジュールに基づいて車両５が使用されない時間帯を時間帯推定部２４が推定して、リプロスケジュール生成部２５がリプロスケジュールを生成して出力する。このように、車両５に係るスケジュールを取得することで、車両５が使用されない時間帯、すなわち車両５の利用状況を推定することができる。そのため、車両５の利用状況に応じたリプログラミングのスケジュールを生成することが可能となる。

　また、スケジュールは、車両５を所有するユーザの行動予定である。この場合には、車両５を所有するユーザの行動予定を取得することで、車両５を利用しない日時（利用する日時）を推定することができる。そのため、車両５を所有するユーザの都合に応じたリプロ対象ＥＣＵ５４のリプログラミングのリプロスケジュールを好適に生成することができる。

　スケジュールは、車両５の利用状況、利用環境、利用予定を含んでいる。この場合には、車両５が社用車やレンタカー等といった法人で管理されている場合、車両５の利用状況や貸し出し状況等を取得することで、車両５を利用しない日時を推定することができる。そのため、車両５を所有するユーザの都合に応じたリプロ対象ＥＣＵ５４のリプログラミングのリプロスケジュールを好適に生成することができる。

　本発明は、上記実施形態に限定されるものではない。例えば、上記実施形態では、プログラム配信センター２、データセンター３及びオペレータセンター４のそれぞれが独立して設けられている構成としたが、プログラム配信センター２、データセンター３及びオペレータセンター４は同一のセンターであってもよい。また、プログラム更新装置（制御手段）は、車両５に搭載されてもよい。

　また、上記実施形態では、本発明の制御装置をリプロ対象ＥＣＵ５４のリプログラミングに適用したが、制御手段であるＦＰＧＡ（Field Programmable Gate Array）のプログラムの書き換えに適用してもよい。ＦＰＧＡは、論理回路が書き込み可能なゲートアレイであり、論理回路のプログラムが書き換え（制御内容の変更）可能とされている。ＦＰＧＡでは、メモリからプログラムを読み込むことで、機能が実現される。

　２…プログラム配信センター（制御装置）、５…車両、２３…スケジュール取得部（スケジュール取得手段）、２５…リプロスケジュール生成部（変更日時生成手段）。

Claims

　車両に搭載される制御手段の制御内容を変更する制御装置であって、
　前記車両に係るスケジュールを取得するスケジュール取得手段と、
　前記スケジュール取得手段によって取得された前記スケジュールに基づいて前記車両が使用されない時間帯を推定し、当該時間帯に応じて前記制御内容の変更を行う変更日時を生成して出力する変更日時生成手段と、
を備えることを特徴とする制御装置。
　前記スケジュール取得手段は、前記車両の外部の端末から前記スケジュールを取得する請求項１記載の制御装置。
　前記スケジュールは、前記車両を所有するユーザの行動予定である請求項１又は２記載の制御装置。
　前記スケジュールは、前記車両の利用状況、利用環境、利用予定の少なくとも一つを含む請求項１～３のいずれか一項記載の制御装置。
　前記制御手段は、電子制御装置であり、
　前記変更日時生成手段は、前記スケジュール取得手段によって取得された前記スケジュールに基づいて前記車両が使用されない時間帯を推定し、当該時間帯に応じて前記電子制御装置のプログラムの変更を行う変更日時を生成して出力する請求項１～４のいずれか一項記載の制御装置。