(57)【要約】【課題】更新プログラムに起因して車両装備の動作が不調に陥ることを極力回避することが可能な車両用制御システムを提供すること。【解決手段】車両用制御システムは、車両に搭載された複数の車両装備を制御するための制御予定計画を立案する立案部（Ｓ１６０）と、制御予定計画に基づき、変更が予定されている制御を把握し、その制御を、制御実行部（Ｓ２６０）が正常に実行しえるか否かを判定する判定部（Ｓ２３０、Ｓ２４０）を備えている。制御実行部（Ｓ２６０）は、正常に実行しえることが確認された場合にのみ、当初の制御予定計画に従って制御の変更を実施する。【選択図】図４
2019137243.tif 000002
【特許請求の範囲】
【請求項１】
車両に搭載された少なくとも１つの車両装備を制御する制御プログラムが、当初に使用されていた当初制御プログラムから別の制御プログラムに更新される車両に適用される車両用制御システムであって、
車両が使用される際、事前に、車両に搭載された複数の車両装備を制御するための制御予定計画を立案する立案部（Ｓ１６０）と、
前記立案部によって立案された前記制御予定計画に従って、前記複数の車両装備を制御する制御実行部（Ｓ２６０）と、
前記制御予定計画において制御の変更が予定されている場合、実際に制御が変更される前に、予定されている変更後の制御を前記制御実行部が正常に実行しえるか否かを判定する判定部（Ｓ２３０、Ｓ２４０）と、を備え、
前記制御実行部は、前記判定部において正常に実行しえるとの判定がなされたことを条件として、前記制御予定計画に従い、制御の変更を実施する車両用制御システム。
【請求項２】
前記判定部は、前記制御実行部において変更が予定されている制御の実行により、前記制御実行部が保有するリソースの不足に起因する異常が発生するか否かに基づいて、前記制御実行部が、変更が予定されている制御を正常に実行しえるか否かを判定する請求項１に記載の車両用制御システム。
【請求項３】
前記リソースは、ＣＰＵ、メモリ、通信インターフェース、及び電源の少なくとも１つを含む請求項２に記載の車両用制御システム。
【請求項４】
前記判定部は、変更が予定されている制御の制御プログラムを実際に処理するリハーサル処理を実行し、そのリハーサル処理の実行中における前記リソースの使用状況から、前記リソースの不足に起因する異常の発生の有無を判定する請求項２又は３に記載の車両用制御システム。
【請求項５】
前記判定部は、変更が予定されている制御の制御プログラムのプログラム量と制御周期とに基づいて前記制御実行部の処理負荷を見積り、その見積り結果から、予定されている変更後の制御を前記制御実行部が正常に実行しえるか否かを判定する請求項１に記載の車両用制御システム。
【請求項６】
前記判定部は、前記制御実行部における処理状況に基づいて処理余裕が有るか否かを判定し、処理余裕が有る場合には、変更が予定されている制御の制御プログラムを実際に処理するリハーサル処理を実行し、そのリハーサル処理の実行中における前記リソースの使用状況から、前記リソースの不足に起因する異常の発生の有無を判定し、処理余裕が無い場合には、変更が予定されている制御の制御プログラムのプログラム量と制御周期とに基づいて前記制御実行部の処理負荷を見積り、その見積り結果から、予定されている変更後の制御を前記制御実行部が正常に実行しえるか否かを判定する請求項２又は３に記載の車両用制御システム。
【請求項７】
前記判定部は、前記制御予定計画における制御の変更が、制御対象となる車両装備の変更、追加であるか否かを判定し、車両装備の変更、追加である場合には、変更が予定されている制御の制御プログラムを実際に処理するリハーサル処理を実行し、そのリハーサル処理の実行中における前記リソースの使用状況から、前記リソースの不足に起因する異常の発生の有無を判定し、車両装備の変更、追加でない場合には、変更が予定されている制御の制御プログラムのプログラム量と制御周期とに基づいて前記制御実行部の処理負荷を見積り、その見積り結果から、予定されている変更後の制御を前記制御実行部が正常に実行しえるか否かを判定する請求項２又は３に記載の車両用制御システム。
【請求項８】
前記判定部は、前記リハーサル処理の実行によって算出された処理結果を破棄する請求項４、６、７のいずれかに記載の車両用制御システム。
【請求項９】
変更が予定されている制御の制御プログラムは、制御機能として、少なくとも基本機能と拡張機能とを有するものであり、
前記判定部は、前記リハーサル処理を実行する際、最初に、基本機能を発揮する制御プログラム部分を実行し、その実行中に、前記リソースの不足に起因する異常の発生の兆候が見られない場合に、拡張機能を発揮する制御プログラム部分を実行する請求項４、６、７のいずれかに記載の車両用制御システム。
【請求項１０】
前記制御予定計画における制御の変更は、制御対象となる車両装備が変更、追加されることを含む請求項１乃至９のいずれかに記載の車両用制御システム。
【請求項１１】
前記制御予定計画における制御の変更は、制御対象となる車両装備は同じであるが、当該車両装備に対する制御内容が変更されることを含む請求項１乃至９のいずれかに記載の車両用制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両に搭載された車両装備のための制御予定計画を立案し、当該制御予定計画に従って車両装備の制御を可能とする車両用制御システムに関する。
【背景技術】
【０００２】
例えば、特許文献１には、走行予定ルートが決定されると、走行予定ルートでの走行のために消費する消費電力量を推定した上で、車両バッテリの充電量に基づく供給電力量と対比し、供給電力量にて走行予定ルートを走行可能か否か推定する車両の目的地到達推定装置が開示されている。消費電力量の推定精度を高めるために、特許文献１の装置では、車速ごとに当該車速に達した際の加速度を順次取得し、速度・加速度ヒストグラムとして路面状況（坂道やカーブ）に応じてそれぞれ区分けして蓄積する。さらに、平坦路における各速度域とその速度域に達した際の加速度情報と関連つけて、実績値に基づく単位距離あたりの平坦路走行消費電力量を走行消費電力マップとして保存する。
【０００３】
そして、特許文献１の装置では、走行予定ルートが設定されると、まず、走行予定ルート全域を平坦路と見做して、平坦路用の速度・加速度ヒストグラムと走行消費電力マップとを用いて、単位距離あたりの平坦路走行相当分消費電力値を算出する。さらに、算出した単位距離あたりの平坦路走行相当分消費電力値に走行予定ルートの走行距離を乗算することにより、平坦路と見做した走行予定ルートの走行に必要な消費電力予測値を算出する。その上で、平坦路と見做した場合の消費電力予測値に、上り勾配情報に基づく、加算補整係数により補正した上り路消費電力量と、下り勾配情報に基づく、回生補正係数により補正した下り路回生電力量を加えて、全走行路での走行消費電力予測値を演算する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１４−２０２６４３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述した特許文献１の目的地到達推定装置は、結局のところ、目的地までの走行予定ルートを走行するために消費される走行消費電力量の予測値と、車両バッテリの充電レベル情報から算出される供給可能電力量の予測値とを対比して、目的地まで到達可能であるかどうかを判断しているものにすぎない。
【０００６】
ここで、近年では、衝突被害軽減ブレーキ機能、車線逸脱警報機能、ブラインドスポットモニタリング機能など、車両装備を用いた運転支援のための各種の機能が実現されている。さらに、高速道路などの自動車専用道路では、いわゆるレベル３に相当する自動運転機能が実用化されつつある。このため、例えば、目的地までの走行予定ルートが設定された場合、その走行予定ルートを走行する際に、各道路の形状、車線数、道路種別などに応じていずれの機能を利用するかを決定し、予めそれらの機能を発揮させるための車両装備の制御予定計画を立案することが可能である。
【０００７】
その一方、同様に近年の傾向として、車両が市場に投入された後、ディーラーでの点検時や、オンラインにて随時、車両に搭載された車両装備を制御するための一部の制御プラグラムが、性能向上や新規な機能を付加するために更新されることがある。しかし、このように一部の制御プログラムだけが更新された場合、残りの制御プログラムとの不整合や、更新プログラム自体に起因する不具合などにより、上述した各種の機能を発揮するための車両装備の動作が不調に陥る可能性も否定できない。
【０００８】
本発明は、上述した点に鑑みてなされたもので、少なくとも１つの車両装備を制御する制御プログラムが、当初に使用されていた当初制御プログラムから別の制御プログラムに更新される車両に適用され、車両装備を制御するための制御予定計画を利用することによって、更新プログラムに起因して車両装備の動作が不調に陥ることを極力回避することが可能な車両用制御システムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、本発明による車両用制御システムは、車両に搭載された少なくとも１つの車両装備を制御する制御プログラムが、当初に使用されていた当初制御プログラムから別の制御プログラムに更新される車両に適用されるものであって、
車両が使用される際、事前に、車両に搭載された複数の車両装備を制御するための制御予定計画を立案する立案部（Ｓ１６０）と、
立案部によって立案された制御予定計画に従って、複数の車両装備を制御する制御実行部（Ｓ２６０）と、
制御予定計画において制御の変更が予定されている場合、実際に制御が変更される前に、予定されている変更後の制御を制御実行部が正常に実行しえるか否かを判定する判定部（Ｓ２３０、Ｓ２４０）と、を備え、
制御実行部は、判定部において正常に実行しえるとの判定がなされたことを条件として、制御予定計画に従い、制御の変更を実施するように構成される。
【００１０】
このように、本発明による車両用制御システムは、車両に搭載された複数の車両装備を制御するための制御予定計画を立案する立案部を備えている。さらに、本発明による車両用制御システムは、制御予定計画に基づき、変更が予定されている制御を把握し、その制御を、制御実行部が正常に実行しえるか否かを判定する判定部を備えている。これら立案部及び判定部を備えることにより、制御予定計画に基づき、実際に制御が変更される前に、予定されている変更後の制御が正常に実行されるかどうかを判定することができる。そして、正常に実行しえることが確認された場合にのみ、制御実行部は、当初の制御予定計画に従って制御の変更を実施する。換言すれば、制御実行部は、正常に実行しえることが確認できなければ、当初の制御予定計画における変更後の制御をそのまま実行することはない。従って、予定されている変更後の制御を行う制御プログラムに更新プログラムが含まれており、その更新プログラムのために、変更が予定されている制御が正常に実行しえない場合には、変更後の制御がそのまま実行されることを防止することができるので、更新プログラムに起因して車両装備の動作が不調に陥ることを極力回避することができる。
【００１１】
上記括弧内の参照番号は、本発明の理解を容易にすべく、後述する実施形態における具体的な構成との対応関係の一例を示すものにすぎず、なんら本発明の範囲を制限することを意図したものではない。
【００１２】
また、上述した特徴以外の、特許請求の範囲の各請求項に記載した技術的特徴に関しては、後述する実施形態の説明及び添付図面から明らかになる。
【図面の簡単な説明】
【００１３】
【図１】実施形態による車両用制御システムの全体構成をブロック図として示した構成図である。
【図２】各車両に搭載される車載ユニットの構成の一例を示す構成図である。
【図３】車載ユニットにおいて、制御予定計画を立案するために実行される処理を示すフローチャートである。
【図４】車載ユニットにおいて、制御予定計画が立案された場合に実行される処理を示すフローチャートである。
【図５】車載ユニットにおいて、立案した制御予定計画に基づいて、変更が予定されている制御を正常に実行することができるかどうかを判定する異常判定処理の一例を示すフローチャートである。
【図６】図５の異常判定処理における、異常兆候監視処理の一例を示すフローチャートである。
【図７】異常判定処理の別の例を示すフローチャートである。
【図８】情報管理センターにおいて実行される処理を示すフローチャートである。
【発明を実施するための形態】
【００１４】
以下、本発明の実施形態による車両用制御システムについて、図面を参照しつつ説明する。図１は、車両用制御システムの全体構成をブロック図として示した構成図である。
【００１５】
本実施形態による車両用制御システムは、図１に示すように、各車両１０、２０に搭載された車載ユニット１０ａ、２０ａと、情報管理センター１００とを有する。車載ユニット１０ａ、２０ａは、情報管理センター１００から、走行予定ルートの候補に関する実際の交通状況、天気などの情報を取得する。車両１０、２０の運転者は、情報管理センター１００から取得した情報に基づき、該当する走行予定ルートを、実際に利用する走行予定ルートとするかどうかを決定する。そして、車載ユニット１０ａ、２０ａは、決定した走行予定ルートに基づき、車両１０、２０の車両装備を制御するための制御予定計画を立案し、その立案した制御予定計画の概要を車両１０、２０の乗員に提示したり、当該制御予定計画に従って車両１０、２０の車両装備の制御を行ったりする。
【００１６】
以下においては、制御予定計画として、車両１０が目的地に達するための走行予定ルートを走行する際に、各種の車両装備によって実現される、車両の運転を支援するための種々の運転支援機能や、自動車専用道路における自動運転機能などを発揮させるための車両装備の制御予定計画を立案するケースについて説明する。ただし、制御予定計画は、これに限られない。例えば、制御予定計画は、運転支援機能や自動運転機能を発揮させるための車両装備の制御予定計画に加えて、もしくは代えて、他の車両装備の制御予定計画（例えば、ワイパやエアコンの制御予定計画）を含んでもよい。
【００１７】
車両１０に搭載された車載ユニット１０ａは、通信ネットワーク１１０を介して、情報管理センター１００と通信可能に構成されている。通信ネットワーク１１０は、携帯電話網やインターネット等の電気通信事業者によって提供される公衆通信ネットワークなどを含む。
【００１８】
情報管理センター１００は、各道路の実際の交通量を示す情報を定期的に収集し、各道路に対応付けて保存する。この各道路の交通量は、新たな情報が取得される毎に更新される。また、情報管理センター１００は、各道路を網羅する範囲を複数のエリアに分割し、各エリアの天候情報（天気、気温、湿度など）も定期的に収集して保存する。この各エリアの天候情報も、新たな情報が取得される毎に更新される。ただし、情報管理センター１００が保存する情報は上述した情報だけに限られない。例えば、情報管理センター１００は、各道路における事故の発生情報、工事などによる規制情報なども収集して保存しても良い。さらに、情報管理センター１００は、車両１０の少なくとも１つの車両装備を制御するための制御プログラムを更新する更新制御プログラムを配信することが可能に構成されてもよい。なお、制御プログラムの更新の態様としては、従前の制御プログラムに対して更新制御プログラムの追加や、従前の制御プログラムの一部の更新制御プログラムによる置換などを含む。
【００１９】
情報管理センター１００は、車両１０から送信された走行予定ルートを示す情報を受信すると、当該走行予定ルートに含まれる各道路の交通状況に基づき、当該走行予定ルートの通行の許可、禁止を判定する。例えば、情報管理センター１００は、走行予定ルートに含まれる各道路の交通量が閾値以上である場合、走行予定ルートの通行不可と判定してもよい。さらに、情報管理センター１００は、事故情報や規制情報を参照し、走行予定ルートが、事故が発生していたり、規制がかけられていたりする道路を含む場合には、走行予定ルートの通行不可と判定してもよい。情報管理センター１００は、走行予定ルートの通行可否に関する判定結果を、車両１０に返送する。
【００２０】
情報管理センター１００は、走行予定ルートの通行を許可する判定結果を車両１０に返送すると、引き続き、保存している情報を送信する。具体的には、情報管理センター１００は、保存している交通量情報、天候情報などを送信する。ただし、情報管理センター１００は、保存しているすべての情報を送信するのではなく、各車両１０、２０の走行予定ルートに関連する情報だけを選別して送信する。例えば、交通量情報については、走行予定ルートに含まれる各道路の交通量だけが選別されて送信される。天候情報についても、走行予定ルートを含むエリアの天候情報だけが選別されて送信される。
【００２１】
次に、車両１０に搭載される車載ユニット１０ａの構成の一例を、図２を参照して説明する。なお、図１に示す各車両１０、２０には、同一の構成を有する車載ユニット１０ａ、２０ａがそれぞれ搭載される。
【００２２】
図２に示すように、車載ユニット１０ａは、通信部３０、周辺監視部３１、地図データベース３２、センサ群３３、操作入力部３４、表示装置３５、駆動力制御装置３６、制動力制御装置３７、ステアリング制御装置３８、及びメインコントローラ３９を備える。通信部３０は、通信ネットワーク１１０を介して情報管理センター１００とデータ通信を行うためのものである。さらに、通信部３０は、他の車両に搭載された車載ユニットの通信部と、いわゆる車々間通信を行うことが可能に構成してもよい。周辺監視部３１は、車両１０の各所に設けられたセンサ（カメラ、ミリ波センサ、レーザセンサ、超音波センサなど）を含み、車両１０の周囲の障害物（自動車、二輪車、歩行者、その他の物体）を検出したり、車両１０の走行車線（区画線）を検出したりする。さらに、周辺監視部３１は、前方車両、後方車両、側方車両などの、車両１０の近傍を走行する他車両を検出する。
【００２３】
地図データベース３２は、道路の形状、道幅、車線数、制限速度、一時停止線の位置、信号機の位置、道路の種類、各種の施設の場所、名称などを含む道路地図データを格納している。センサ群３３は、例えば、車両１０の現在位置に関する情報に加えて、走行速度、前後方向加速度、操舵角、横方向加速度など、車両１０の実際の挙動に関する情報を検出するものである。操作入力部３４は、車両１０の出発地、目的地、出発時間を設定するための入力や、その出発地から目的地に達する走行予定ルートを決定するための入力などを行うためのものである。
【００２４】
車載ユニット１０ａのメインコントローラ３９は、地図データベース３２及び操作入力部３４を利用して走行予定ルートを設定する。この走行予定ルートの通行が情報管理センター１００によって許可され、さらに、車両１０の運転者によって実際に利用する走行予定ルートとして決定されると、メインコントローラ３９は、その走行予定ルートに基づいて、車両１０が走行予定ルートを走行する際の各種の車両装備の制御予定計画を立案する。例えば、車両１０が一般道の１車線道路を直進する際には、運転支援機能として、衝突被害軽減ブレーキ機能と車線逸脱警報機能とを発揮するように車両装備の制御予定計画を立案することができる。また、車両１０が一般道の複数車線道路を走行する際には、それらの両機能に加えて、斜め後方の接近車両を監視するブラインドスポットモニタリング機能を発揮するように車両装備の制御予定計画を立案することができる。さらに、車両１０が自動車専用道路を走行する際には、自動運転機能を発揮するように車両装備の制御予定計画を立案することができる。
【００２５】
なお、運転支援機能を発揮させるための制御予定計画には、少なくとも走行予定ルートと、当該走行予定ルートを分割した各区間において発揮させる運転支援機能と、各運転支援機能を発揮させるために作動状態（又は作動可能状態）とすべき車両装置（周辺監視部、走行駆動源、ブレーキ装置、及びそれらの制御部など）などが含まれる。また、自動運転機能を発揮させるための制御予定計画には、少なくとも走行予定ルートと、当該走行予定ルートを分割した各区間の中で自動運転機能を発揮させる区間と、自動運転時の車両１０の目標走行速度、その際に作動状態（又は作動可能状態）とすべき車両装備（例えば、周辺監視部、走行駆動源、ブレーキ装置、ステアリング装置、及びそれらの制御部など）などが含まれる。
【００２６】
メインコントローラ３９は、このようにして制御予定計画を立案すると、内蔵している揮発性又は不揮発性のメモリ４０に制御予定計画を保存する。そして、メインコントローラ３９は、メモリ４０に保存した制御予定計画に基づき、表示装置３５を用いて制御予定計画の概要を車両１０の乗員に提示したり、制御予定計画に従って車両１０の車両装備の制御を行って、運転支援機能や自動運転機能を発揮させたりする。
【００２７】
車両１０は、上述した自動運転機能を実現するため、運転者による手動運転によらず、自動運転を行うことが可能に構成されている。以下に、自動運転を可能とするための構成について説明する。
【００２８】
駆動力制御装置３６は、メインコントローラ３９からの制御信号に応じて、車両１０を走行させる走行駆動源の出力を制御する。例えば、駆動力制御装置３６は、車両１０の制御予定計画に含まれる目標走行速度にて車両１０を走行させるように指示する制御信号をメインコントローラ３９から受信したとき、車両１０の走行速度が目標走行速度に一致するように、走行駆動源の出力を制御する。また、駆動力制御装置３６は、車両１０を加速するように指示する制御信号（目標加速度を含む）をメインコントローラ３９から受信したとき、車両１０の加速度が目標加速度に一致するように、走行駆動源の出力を制御する。なお、走行駆動源は、通常の内燃機関、電動機、あるいは内燃機関と電動機との組み合わせのいずれであってもよい。
【００２９】
制動力制御装置３７は、メインコントローラ３９からの制御信号に応じて、運転者によるブレーキペダルの操作に係わらず、ブレーキ装置を用いて車両に発生する制動力を制御する。例えば、制動力制御装置３７は、車両１０を減速するように指示する制御信号（目標減速度を含む）をメインコントローラ３９から受信したとき、車両１０の減速度が目標減速度に一致するように、ブレーキ装置による制動力を制御する。ステアリング制御装置３８は、メインコントローラ３９からの制御信号に応じて、ステアリング装置のステアリングシャフトを回転させ、操舵輪の角度を制御する。例えば、走行予定ルートの道路が曲線路であるとき、あるいは、突発的な障害物を回避する必要が生じたときなど、メインコントローラ３９は、ステアリング制御装置３８に対して、目標操舵角度及びその目標操舵角度まで操舵角を変化させる際の操舵角速度を指示する制御信号を出力する。ステアリング制御装置３８は、その制御信号に従ってステアリング装置の操舵角を制御する。
【００３０】
このように、メインコントローラ３９は、制御予定計画に従って、駆動力制御装置３６、制動力制御装置３７、ステアリング制御装置３８に制御信号を出力し、それによって走行駆動源、ブレーキ装置、ステアリング装置などの車両装備を制御する。これにより、車両１０が自動運転される。なお、車両１０が自動運転される際には、周辺監視部３１によって車両１０の周囲の物体が監視されるとともに、地図データベース３２に格納された道路地図データとセンサ群３３の位置検出センサによって検出される車両位置とに基づき、車両１０の現在位置や、周囲の物体との相対位置が把握される。そして、メインコントローラ３９は、周囲の状況から車両１０を目標走行速度にて走行させることができないと判断した場合には、そのときの周囲の状況に対応するように車両１０の移動を制御する。
【００３１】
また、メインコントローラ３９は、運転支援機能を発揮させる場合、周辺監視部３１によって車両１０の前方、斜め後方を監視したり、走行車線の検出を行いつつ、必要に応じて、車両１０を減速させたり、操舵したりするために制動力制御装置３７やステアリング制御装置３８に制御信号を出力する。
【００３２】
メインコントローラ３９は、上述した各種の機能を車両装備の制御によって発揮させるための各種の制御プログラムを、例えば、フラッシュメモリ等の不揮発性のメモリに保存している。すなわち、メモリ４０は、フラッシュメモリ等の不揮発性メモリを含んでいる。このメモリ４０に保存されている各種の制御プログラムは、車両が市場に投入された後に、ディーラーでの点検時や、情報管理センター１００との通信にて随時、性能向上や新規な機能を付加するために更新されることがある。
【００３３】
例えば、車両１０が自動車専用道路を自動運転されているときであって、僅かな下り勾配道路を走行する場合など、燃料消費量を低減するために、コースティング走行モードでの走行が可能となるように、クラッチを含む駆動源を制御するための制御プログラムが更新されることが考えられる。コースティング走行モードは、車両１０の走行中にクラッチを切断することにより、エンジンブレーキによる速度低下が起こらないようにする走行モードである。このような制御プログラムの更新が行われると、自動運転中に、車両１０がコースティング走行モードに適した区間の走行を開始したとき、車両１０の車両装備は、更新制御プログラムにより、コースティング走行モードとなるように制御することが可能となる。この場合、更新制御プログラムの実行前後で、すなわち、更新制御プログラムが実行されていない制御から、更新制御プログラムが実行される制御へと制御が変更されるとき、制御対象となる車両装備は、クラッチを含む駆動源、ブレーキ装置、及びステアリング装置などで変わりはないが、それらの車両装備に対する制御内容が変更されることになる。
【００３４】
また、車両１０が自動車専用道路を、常に目標走行速度にて単独走行するのではなく、他の車両と車群を形成して走行するように、制御プログラムが更新されることも考えられる。車両１０が他の車両と車群を形成して走行可能であれば、走行時の空気抵抗が低減され、燃費の向上を図ることができる。車両１０が車群を形成する以前は、車両１０は目標走行速度にて単独走行する。しかし、車群を形成可能な少なくとも１台の他車両を見つけると、車両１０は、その少なくとも１台の他車両と車群を形成して走行する。この場合、更新制御プログラムの実行前は、車両の走行速度を目標走行速度に維持しつつ走行予定ルートに沿って車両を走行させるため、制御対象となる車両装備は、周辺監視部３１、駆動源、ブレーキ装置、及びステアリング装置などである。それに対し、更新制御プログラムの実行後は、車群を形成する他車両の状況の把握等のため、他車両と通信を行う通信部３０も制御対象となる車両装備に含まれることになる。換言すれば、更新制御プログラムの実行後は、通信部３０が制御対象となる車両装備に追加されることになる。
【００３５】
更新制御プログラムの実行後に、制御対象となる車両装備が変更、追加される他の例として、例えば、ウインカースイッチ操作による自動車線変更機能を発揮させる制御プログラムが更新により追加された場合も該当する。自動車線変更機能は、ウインカースイッチ操作によって車線変更が指示されたと判定すると、変更後の車線を走行している他車両の存在を確認し、自車の側方や後方に他車両が存在しない場合、ステアリング装置を自動的に操舵させて、目標とする車線への車線変更を行う機能である。走行予定ルートが決定されて、右左折地点が定まると、その右左折地点に向けて車両が直進しているとき、運転支援機能としてブラインドスポットモニター機能が有効化される。この場合、このブラインドスポットモニター機能により、車両１０の側方や後方が周辺監視部３１によって監視され、他車両を検知したときには、車両１０の運転者に警告される。そして、右左折地点に接近すると、制御予定計画に従って自動車線変更機能が作動される。この場合、車載ユニット１０ａは、ウインカースイッチ操作よって車線変更が指示されたと判定すると、目標車線に他車両がいないことを確認後、目標車線への車線変更を自動的に行う。従って、自動車線変更機能が作動するように制御を変更した後は、周辺監視部３１に加えて、ウインカースイッチ、ステアリング装置などが制御対象となる車両装備に追加されることになる。
【００３６】
メインコントローラ３９は、制御プログラムが更新されるときに、更新制御プログラムを、メモリ４０内の従前の制御プログラムが保存されていた領域とは別の領域に保存する。さらに、メインコントローラ３９は、更新後の制御プログラムの機能を示す更新情報も取得して保存する。そして、メインコントローラ３９は、取得した更新情報に基づいて、更新後の制御プログラムによる機能を活用するように、制御予定計画を立案する。つまり、メインコントローラ３９における制御予定計画を立案するためのプログラムは、各車両の車両装備にて発揮可能な機能に応じた制御予定計画を立案することができるように構成されている。なお、制御予定計画を立案するためのプログラムが想定していない機能を追加するような場合には、制御予定計画を立案するためのプログラムも併せて更新すればよい。
【００３７】
更新後の制御プログラムによる機能を活用するように制御予定計画を立案する一例としては、例えば、制御プログラムの更新によりコースティング走行モードでの走行が可能となった場合に、メインコントローラ３９は、走行予定ルートにおける道路種別や勾配情報に基づき、コースティング走行モードにて走行する区間を決定し、その決定内容を、制御予定計画に含めるようにすることが考えられる。また、制御プログラムの更新により自動車線変更機能を使用できるようになった場合、例えば、一般道における右左折地点に達する所定距離前に、自動車線変更機能を発揮させるための車両装備を作動状態とすることを制御予定計画に織り込むことが考えられる。
【００３８】
次に、車載ユニット１０ａ及び情報管理センター１００において実行される具体的な処理の一例を図３〜８のフローチャートを参照して説明する。図３〜７のフローチャートは車載ユニット１０ａにおいて実行される処理を示し、図８のフローチャートは情報管理センター１００において実行される処理を示している。ただし、図３のフローチャートに示す処理は、車載ユニット１０ａではなく、車両１０の乗員が保有する携帯端末などで処理し、立案した制御予定計画を車載ユニット１０ａに転送するようにしてもよい。
【００３９】
図３のステップＳ１００において、車両１０の乗員が、出発地、目的地などを設定するための入力を行うと、メインコントローラ３９は、地図データベース３２の道路地図データを参照して、走行予定ルートの候補を選択して乗員に提示する。乗員が提示された走行予定ルートを承認することにより、車両１０の走行予定ルートが設定される。なお、乗員によって出発地の設定入力が行われない場合、出発地は現在地に設定される。
【００４０】
続くステップＳ１１０では、設定した走行予定ルートを情報管理センター１００に送信する。そして、ステップＳ１２０では、情報管理センター１００からの応答（通行可否の判定結果）を受信する。ステップＳ１３０では、受信した判定結果が、走行予定ルートの通行許可であるか通行不可であるかを判定する。通行許可の場合、ステップＳ１４０の処理に進む。通行不可の場合、ステップＳ１７０の処理に進む。
【００４１】
ステップＳ１４０では、情報管理センター１００から、走行予定ルートに関連する交通情報や天候情報などの情報を受信する。ステップＳ１５０では、受信した情報を車両１０の乗員に提示し、車両１０の乗員が、それらの情報を考慮した上で、最終的に実際に利用する走行予定ルートとして決定したか否かを判定する。すなわち、ステップＳ１５０では、車両１０の乗員によって実際に利用する走行予定ルートして決定する操作がなされたか否かを判定する。実際に利用する走行予定ルートして決定する操作がなされたと判定すると、ステップＳ１６０の処理に進み、そのような操作がなされなかったと判定すると、図３のフローチャートに示す処理を終了する。ステップＳ１６０では、決定された走行予定ルートに基づいて、各車両装備を制御するための制御予定計画を立案する。
【００４２】
一方、情報管理センター１００から走行予定ルートの通行不可との判定結果を受信した場合に実行されるステップＳ１７０では、出発地から目的地へ達する別ルートが設定可能かどうかを判定する。例えば、車両１０乗員に対して、設定した走行予定ルートとは異なる１以上の別ルートを提示し、乗員によっていずれかの別ルートが承認された場合、別ルートの設定可と判定し、承認されなかった場合、別ルートの設定不可と判定することができる。別ルートの設定可と判定するとステップＳ１８０の処理に進み、別ルートの設定不可と判定するとステップＳ１９０の処理に進む。
【００４３】
ステップＳ１８０では、乗員によって承認された別ルートを走行予定ルートに設定し、その後、ステップＳ１１０からの処理を繰り返す。一方、ステップＳ１９０では、所定時間待機した後、ステップＳ１１０に進み、通行不可と判定された走行予定ルートを再度、情報管理センター１００に送信する。
【００４４】
図４のフローチャートは、図３のフローチャートのステップＳ１６０において、制御予定計画が立案された場合に、車載ユニット１０ａにて実行される処理を示している。
【００４５】
最初のステップＳ２００では、走行を開始したか否かが判定される。走行を開始したと判定するとステップＳ２１０の処理に進む。ステップＳ２１０では、車載ユニット１０ａのメインコントローラ３９が、表示装置３５に制御予定計画の概要の提示を指示する。すなわち、メインコントローラ３９は、制御予定計画の概要を提示するためのデータを表示装置３５に送信する。表示装置３５に制御予定計画の概要を提示することにより、車両１０の乗員は、走行を予定している各道路で、どのような運転支援機能による運転支援を受けうるか、もしくは自動運転機能による自動運転を利用する予定であるかを把握することができる。なお、制御予定計画は、車両１０の運転者が自身の好み・趣向に合致するように修正できるようにしてもよい。
【００４６】
ステップＳ２２０では、メインコントローラ３９は、制御予定計画を参照して、所定時間内に又は所定距離走行する間に、制御の変更の予定があるかどうかを判定する。制御の変更には、上述したように、制御対象となる車両装備に変わりはないが、当該車両装備に対する制御内容が変更される場合と、制御対象となる車両装備が変更、追加される場合とが含まれる。制御の変更の予定が有ると判定した場合にはステップＳ２３０の処理に進み、制御の変更の予定が無いと判定した場合にはステップＳ２６０の処理に進む。ステップＳ２３０では、異常判定処理を実行する。この異常判定処理では、変更が予定されている制御を実行しようとしたときに、主として車載ユニット１０ａのメインコントローラ３９のリソース不足により、予定されている制御を適切に実行しえない可能性があるかどうかを判定する。この異常判定処理の具体例は、後に、図５〜図７のフローチャートを参照して詳しく説明する。
【００４７】
このような異常判定処理を実行する理由は、上述したように、車両装備を制御する制御プログラムが更新される可能性があるためである。一部の制御プログラムが更新された場合、例えば、その更新制御プログラムを実際に車両装備の制御に利用しようとした際に他の制御プログラムとの想定外の組み合わせが生じて、車載ユニット１０ａのメインコントローラ３９のリソース不足が発生するかもしれない。メインコントローラ３９のリソース不足、具体的には、ＣＰＵの処理能力不足、メモリ容量不足、通信遅延、電源の消費電力の増大などが発生すると、メインコントローラ３９は、予定している制御を適切に実行しえない可能性が生じる。そのため、本実施形態では、制御予定計画に基づき、実際に制御が変更される前に、予定されている変更後の制御が、車載ユニット１０ａにて正常に実行されるかどうかを判定する。
【００４８】
ステップＳ２４０では、ステップＳ２３０の異常判定処理の判定結果に基づいて、車載ユニット１０ａは変更後の制御を正常に実行しえるか、それともその制御に異常が発生する可能性があるかどうかを判定する。この判定処理において、制御に異常が発生する可能性があると判定すると、ステップＳ２５０の処理に進む。一方、車載ユニット１０ａは、正常に制御を実行しえると判定すると、ステップＳ２６０の処理に進む。
【００４９】
ステップＳ２５０では、変更後の制御をそのまま実行すると異常が発生する可能性があるため、異常の発生を回避するための対応処置を採る。例えば、変更後の制御をスキップして現状の制御を継続させたり、変更後の制御が複数段階の機能を備えている場合には（例えば、基本機能と拡張機能）、利用する機能を基本的な機能だけに制限したりするように制御予定計画を修正する。また、車載ユニット１０ａのメインコントローラ３９が複数のＣＰＵを備え、変更後の制御の実行により特定のＣＰＵの過剰な温度上昇が予想される場合には、特定のＣＰＵにおける処理の一部を他のＣＰＵに割り振ったり、その特定のＣＰＵを使用しないようにしたりする。
【００５０】
そして、ステップＳ２６０では、制御予定計画に従い車両装備の制御を実行する。上述したように、変更後の制御を正常に実行しえると判定した場合には、当初の制御予定計画通りに車両装備の制御を実行する。しかし、制御に異常が発生する可能性があると判定すると、制御予定計画の修正等の対応処置を採る。このように、制御が正常に実行しえることが確認できなければ、変更後の制御がそのまま実行されることはない。従って、予定されている変更後の制御を行う制御プログラムに更新プログラムが含まれており、その更新プログラムのために、変更が予定されている制御が正常に実行しえないと予想される場合には、変更後の制御がそのまま実行されないので、更新プログラムに起因して車両装備の動作が不調に陥ることを極力回避することができる。
【００５１】
ステップＳ２７０では、車両１０が目的地に到達し、制御予定計画が完了したか否かを判定する。まだ制御予定計画が完了していなければ、ステップＳ２１０の処理に戻る。一方、制御予定計画が完了した場合、図４のフローチャートに示す処理を終了する。
【００５２】
次に、異常判定処理の具体例について、図５〜図７のフローチャートを用いて説明する。図５のフローチャートは、異常判定処理の一例を示すものである。
【００５３】
図５において、最初のステップＳ３００では、例えば、現時点でのＣＰＵの使用率やメモリ４０の使用量などに基づいて、メインコントローラ３９が、変更後の制御のリハーサル処理を実行できる処理余裕あるか否かを判定する。なお、リハーサル処理とは、実際に、変更後の制御の制御プログラムを走らせて、その制御プログラムに応じた演算処理を実行することをいう。ステップＳ３００において、変更後の制御のリハーサル処理を実行できる処理余裕がないと判定した場合ステップＳ３１０の処理に進み、リハーサル処理を実行できる処理余裕があると判定した場合ステップＳ３５０の処理に進む。
【００５４】
ステップＳ３１０では、変更後の制御プログラムのプログラム量（コード量）と制御周期とに基づき、車載ユニット１０ａのメインコントローラ３９における処理負荷を見積もる。この処理負荷の見積りは、各制御プログラムに、当該制御プログラムの実行による処理負荷の増加分を示すデータを含ませておき、メインコントローラ３９は、各制御プログラムから負荷増加分データを読み出して積算することにより算出してもよい。
【００５５】
続くステップＳ３２０では、算出した処理負荷が、所定の基準値以上であるか否かを判定する。処理負荷が所定の基準値未満であると判定すると、ステップＳ３３０の処理に進んで、変更後の処理は正常に実行できると判定する。一方、ステップＳ３２０において処理負荷が所定の基準値以上であると判定すると、ステップＳ３４０の処理に進んで、変更後の処理は正常に実行し得ない可能性があるため、異常と判定する。
【００５６】
ステップＳ３００において、メインコントローラ３９は処理余裕があると判定された場合に実行されるステップＳ３５０では、変更後の制御のリハーサル処理を実行する。次いで、ステップＳ３６０において、リハーサル処理が実行されている間に、メインコントローラ３９のリソース不足を示す異常兆候が生じているかを監視する。この異常兆候監視処理の一例を図６のフローチャートを参照して説明する。
【００５７】
図６において、最初のステップＳ４００では、変更後の制御を実行するための複数の制御プログラムの中で、少なくとも１つの制御プログラムの処理が、予定している周期よりも遅れて実行される処理の遅延が発生しているか否かを判定する。処理の遅延が発生していると判定した場合、ステップＳ４６０に進んで、異常判定を行う。一方、処理の遅延が発生していないと判定した場合には、ステップＳ４１０の処理に進む。
【００５８】
ステップＳ４１０では、メインコントローラ３９のＣＰＵに異常が発生しているか否かを判定する。ＣＰＵの異常には、例えば、ＣＰＵ使用率が基準値を超えた状態の継続、ＣＰＵ温度の基準値以上の上昇などが含まれる。このＣＰＵの異常は、メインコントローラ３９が複数のＣＰＵを有している場合には、個々のＣＰＵについて個別に検出される。ＣＰＵに異常が発生していると判定した場合、ステップＳ４６０に進んで、異常判定を行う。一方、ＣＰＵに異常は発生していないと判定した場合には、ステップＳ４２０の処理に進む。
【００５９】
ステップＳ４２０では、ＣＰＵの作業用メモリ（ＲＡＭ、レジスタなど）に異常が発生しているか否かを判定する。ＣＰＵの作業用メモリの異常には、作業用メモリの使用量の所定値以上の増加などが含まれる。作業用メモリに異常が発生していると判定した場合、ステップＳ４６０に進んで、異常判定を行う。一方、作業用メモリに異常は発生していないと判定した場合には、ステップＳ４３０の処理に進む。
【００６０】
ステップＳ４３０では、メインコントローラ３９が、内部回路や外部回路との通信を行うための通信インターフェースに異常が生じているか否かを判定する。通信インターフェースの異常には、通信インターフェースを介しての通信量の基準値以上の増加や、通信遅延の発生などが含まれる。通信インターフェースに異常が生じていると判定した場合、ステップＳ４６０に進んで、異常判定を行う。一方、通信インターフェースに異常は生じていないと判定した場合には、ステップＳ４４０の処理に進む。
【００６１】
ステップＳ４４０では、メインコントローラ３９の電源に異常が生じているか否かを判定する。メインコントローラ３９の電源の異常には、メインコントローラ３９における消費電力の基準値以上の増加が含まれる。メインコントローラ３９の電源に異常が生じていると判定した場合、ステップＳ４６０に進んで、異常判定を行う。一方、メインコントローラ３９の電源に異常は生じていないと判定した場合には、ステップＳ４５０の処理に進んで、正常判定を行う。
【００６２】
このように、変更後の制御の制御プログラムを実際に走らせるリハーサル処理の実行中に、メインコントローラ３９のリソース不足を示す異常兆候が生じているかを監視することにより、リソース不足に起因して、予定されている変更後の制御を正常に実行しえるか否かをより高精度に判定することができる。なお、上述した例では、ＣＰＵ、作業用メモリ、通信インターフェース、及び電源の各々について、異常の兆候が生じていないかを判定したが、少なくとも１つの項目について判定するようにしてもよい。
【００６３】
再び、図５のフローチャートの説明に戻る。上述したステップＳ３６０の異常兆候監視処理の後に実行されるステップＳ３７０では、リハーサル処理により実際に実行された制御プログラムにより、制御対象としての車両装備を制御するための制御信号が算出されたか否かを判定する。制御信号が算出されていないと判定すると、ステップＳ３５０の処理に戻り、リハーサル処理を継続する。一方、制御信号が算出されたと判定すると、ステップＳ３８０の処理に進む。ステップＳ３８０では、リハーサル処理された制御プログラムによる、上述した制御信号を含む演算処理結果を破棄する。リハーサル処理は、実際に車両装備を制御するためのものではなく、車載ユニット１０ａのメインコントローラ３９が、予定されている制御を正常に実行しえるか否かを確認するためのものだからである。
【００６４】
なお、上述した異常判定処理では、メインコントローラ３９の処理余裕の有無に応じて、予定されている変更後の制御を正常に実行しえるか否かを判定する手法を切り換えた。しかしながら、処理余裕の有無に係わらず、処理負荷の見積りに基づいて、予定されている変更後の制御が正常に実行しえるか否かを判定してもよい。また、処理余裕の有無に係わらず、リハーサル処理を行って、予定されている変更後の制御を正常に実行しえるか否かを判定してもよい。ただし、処理余裕の有無に係わらずリハーサル処理を行う場合、変更後の制御の制御プログラムが、例えば基本機能と少なくとも１つの拡張機能とを発揮可能なものであれば、基本機能から順番にリハーサル処理を行うことが好ましい。より具体的には、リハーサル処理を実行する際、最初に、基本機能を発揮する制御プログラム部分を実行し、その実行中に、リソースの不足に起因する異常の発生の兆候が見られない場合に、拡張機能を発揮する制御プログラム部分を実行する。これにより、メインコントローラ３９が車両装備を制御するために実行中の制御に、極力、影響を与えないようにすることができる。
【００６５】
また、異常判定処理の別の例として、図７のフローチャートに示すように、メインコントローラ３９の処理余裕の有無の判定に代えて、変更後の制御が、制御対象となる車両装備を変更したり、追加したりするものであるか否かにより、変更後の制御を正常に実行しえるか否かを判定する手法を切り換えてもよい。制御の変更前後で、制御対象となる車両装備が変更、追加される場合、実行される制御プログラムの変化の度合いが相対的に大きくなると予想される。このため、リハーサル処理を行って、変更後の制御を正常に実行しえるかに関して、より精度の高い判定手法により判断することが好ましいためである。
【００６６】
次に、情報管理センター１００において実行される処理を、図８のフローチャートを参照して説明する。
【００６７】
最初のステップＳ５００では、情報管理センター１００は、各車両の車載ユニットから送信された走行予定ルートを示す情報を受信したか否かを判定する。走行予定ルートを示す情報を受信したと判定すると、ステップＳ５１０の処理に進む。ステップＳ５１０では、受信した走行予定ルートに含まれる各道路の交通状況を確認する、そして、ステップＳ５２０では、その確認結果に基づいて、走行予定ルートに含まれる各道路の交通量が閾値以上であるか否かを判定する。そして、走行予定ルートに含まれる各道路の交通量が閾値以上であると判定した場合、ステップＳ５５０の処理に進み、車載ユニットへ走行予定ルートは通行不可である旨を送信する。一方、交通量が閾値未満であると判定した場合には、ステップＳ５３０の処理に進む。なお、情報管理センター１００は、事故情報や規制情報を参照し、走行予定ルートが、事故が発生していたり、規制がかけられていたりする道路を含む場合には、走行予定ルートの通行不可と判定してもよい。
【００６８】
ステップＳ５３０では、情報管理センター１００は、車載ユニットへ走行予定ルートの通行を許可する旨を送信する。続くステップＳ５４０では、保存している情報を送信する。具体的には、情報管理センター１００は、車載ユニットに対して、交通量情報、天候情報などを送信する。ただし、情報管理センター１００は、保存しているすべての情報を送信するのではなく、各車両の走行予定ルートに関連する情報だけを選別して送信する。
【００６９】
以上、本発明の好ましい実施形態について説明したが、本発明は、上述した実施形態になんら制限されることなく、本発明の主旨を逸脱しない範囲において、種々変形して実施することが可能なものである。
【００７０】
例えば、上述した実施形態は、制御予定計画において制御の変更が予定されている場合、その予定されている変更後の制御に関して事前に異常判定処理を行って、変更後の制御を正常に実行しえるか否かを確認するものであった。しかしながら、車載ユニット１０ａのメインコントローラ３９は変更後の制御を正常に実行しえると一旦判定された場合には、以降、制御予定計画における同様の制御の変更については、異常判定処理の実行を省略してもよい。また、異常判定処理を実施するのは、変更後の制御を行うための制御プログラムに更新制御プログラムが含まれている場合のみに制限してもよい。
【００７１】
また、上述した実施形態では、制御予定計画として、車両が走行予定ルートを走行する際に、車両の運転を支援するための種々の運転支援機能や、自動車専用道路における自動運転機能などを発揮させるための車両装備の制御予定計画を立案する例について説明した。しかしながら、制御予定計画の内容や、制御対象となる車両装備は、上述した例に限定されない。要するに、本発明による車両用制御システムは、制御予定計画を立案し、その制御予定計画に従って車両装備を制御する場合には、適用可能である。
【００７２】
例えば、車両１０が走行駆動源としてエンジン及び駆動用モータを備え、かつ自動運転される場合、エンジン及び駆動用モータを含む走行駆動源を制御対象とし、制御予定計画として、走行駆動源が発生する駆動力に関する制御計画を立案しても良い。これにより、車載ユニット１０ａは、制御計画に基づき、走行予定ルートの形状、勾配、制限速度、交通状況等に見合った駆動力を効率良く発生させることができるように、走行駆動源を制御することが可能になる。この場合、走行予定ルート上において、割込車両や路上駐車車両等の突発的な外乱が生じた場合には、車載ユニット１０ａは、その外乱に対応すべく、駆動力を制御する。例えば、割込車両が発生した場合、その割込車両との車間距離を確保するように駆動力を制御する。また、路上駐車車両が存在している場合には、安全を確認しつつ隣接車線に車線変更したり、路上駐車車両を迂回するように一時的に対向車線を走行したりするように、走行駆動源による駆動力やステアリング装置による操舵量を制御する。割込車両との車間が確保できたり、路上駐車車両を迂回したりした後に、制御計画に従う制御に復帰させることが可能な状況となると、車載ユニット１０ａは、制御計画に従う駆動力制御を再開する。
【００７３】
この場合、制御プログラムの更新の例としては、上述したコースティング走行モードでの車両１０の走行を可能とする制御プログラムの追加などが考えられる。
【００７４】
また、車載ユニット１０ａは、エアコンを制御対象として、エアコンの制御に関する制御予定計画を立案し、その立案した制御予定計画に従って、エアコンを制御しても良い。走行予定ルート全体に渡る気温や天気に関する天候情報を外部サーバなどから入手することで、エアコンの制御状態が、走行する予定ルートの状況に適した状態となるように制御予定計画を立案することができる。そして、立案した制御予定計画に従ってエアコンを制御することにより、走行予定ルート上の各地点で温度や天気の変化があっても、乗員の手を煩わせることなく、乗員に快適な車室環境を提供することができる。
【００７５】
そして、エアコンの制御に関しても、例えば天候の急変やトンネル内などでの一時的な温度変化などの突発的な外乱が生じた場合には、車載ユニット１０ａは、その外乱に対応すべく、エアコンを制御する。例えば、ゲリラ豪雨のような天候の急変に対しては、外気温の低下や湿度の上昇に対応するように、エアコンを制御する。
【００７６】
この場合、制御プログラムの更新の例としては、温度や湿度に関する制御精度を向上するために、制御プログラムを更新することなどが考えられる。
【００７７】
上述した実施形態や変形例では、走行予定ルートが決定された場合に、その走行予定ルートの状況に応じて車両装備の制御予定計画を立案する例について説明した。しかしながら、走行予定ルートが決定されなくとも、車両の使用予定内容が決定された場合には、特定の車両装備に対する制御予定計画を立案することが可能である。例えば、車中泊を行うことや、車両のバッテリを非常用電源として使用することを使用予定内容として決定することも可能である。そして、車中泊が使用予定内容として決定された場合には、例えば、車中泊を行う時間帯に渡って車室内の環境を車中泊に適した環境となるように、エアコンの制御予定計画を立案するとともに、そのエアコンの動作電源の確保のため、エンジン及び発電用モータの制御予定計画を立案することができる。また、車両のバッテリを非常用電源として用いることが使用予定内容として決定された場合には、非常用電源の使用期間に渡って、バッテリから電源が供給できるように、エンジン及び発電用モータの制御予定計画を立案することができる。
【符号の説明】
【００７８】
１０：車両、１０ａ：車載ユニット、２０：車両、２０ａ：車載ユニット、３０：通信部、３１：周辺監視部、３２：地図データベース、３３：センサ群、３４：操作入力部、３５：表示装置、３６：駆動力制御装置、３７：制動力制御装置、３８：ステアリング制御装置、３９：メインコントローラ、４０：メモリ、１００：情報管理センター、１１０：通信ネットワーク
【図１】
2019137243.tif 000003
【図２】
2019137243.tif 000004
【図３】
2019137243.tif 000005
【図４】
2019137243.tif 000006
【図５】
2019137243.tif 000007
【図６】
2019137243.tif 000008
【図７】
2019137243.tif 000009
【図８】
2019137243.tif 000010