以下、本開示の実施の形態について、図面を参照しながら詳細に説明する。なお、図中同一または相当部分には同一符号を付してその説明は繰り返さない。
[実施の形態1]
図1は、本実施の形態1による車両制御システム1の全体構成の一例を模式的に示す図である。車両制御システム1は、複数の車両10と、クラウドサーバ30とを含む。
車両10の各々は、クラウドサーバ30との間で無線通信可能に構成される、いわゆるコネクティッド車両である。車両10の各々は、現在位置、走行負荷(走行パワー)などの車両の走行に関する複数の情報(以下、単に「車両走行データ」ともいう)を、所定周期(たとえば数秒程度毎)でクラウドサーバ30に送信している。
クラウドサーバ30は、各車両10から受信した情報(上述の車両走行データ等)を、各車両10毎に層別して蓄積する。クラウドサーバ30は、各車両10からの要求に応じて、車両10から要求されたデータをその車両10に送信可能に構成される。
以下では、車両10のうち、本開示による制御を実行する車両を「自車11」とも記載し、自車11以外の車両10を「他車12」とも記載する。本実施の形態において、自車11は、駆動力源としてモータとエンジンとを備えるハイブリッッド車両である。他車12は、クラウドサーバ30に対して上記の車両走行データを送信可能な車両であれば特に車両タイプは限定されず、たとえば、ハイブリッッド車両であってもよいし、駆動力源としてモータを備える電気自動車あるいは燃料電池自動車であってもよいし、駆動力源としてエンジンを備える従来の車両(エンジン車両)であってもよい。
図2は、車両10およびクラウドサーバ30の構成の一例をより詳細に示す図である。図2に示す例では、自車11は、いわゆるプラグインハイブリッッド車両である。具体的には、自車11は、インレット13と、充電器14と、蓄電装置15と、駆動装置16と、通信装置17と、HMI(Human Machine Interface)装置18と、制御装置19と、GPS(Global Positioning System)モジュール100とを含む。クラウドサーバ30は、通信装置31と、管理装置32と、メモリ33とを備える。
インレット13は、車両外部の給電設備41のコネクタ42と接続可能に構成される。充電器14は、インレット13と蓄電装置15との間に設けられ、給電設備41から入力される外部電力を蓄電装置15に充電可能な電力に変換し、変換された電力を蓄電装置15へ出力する。以下、外部電力を用いた蓄電装置15の充電を「外部充電」ともいう。
蓄電装置15は、再充電可能に構成された、たとえばニッケル水素電池やリチウムイオン電池等の二次電池である。なお、蓄電装置15は、大容量のキャパシタであってもよい。
駆動装置16は、車両10の駆動力を発生する。駆動装置16は、エンジン16Aと、第1MG(Motor Generator)16Bと、第2MG16Cと、動力分割装置16Dと、PCU(Power Control Unit)16Eとを含む。
エンジン16Aは、たとえば、ガソリンエンジンやディーゼルエンジン等の内燃機関である。エンジン16Aは、制御装置19からの制御信号により制御される。エンジン16Aが発生する動力は、動力分割装置16Dによって、駆動輪へ伝達される経路と、第1MG16Bへ伝達される経路とに分割される。
第1MG16Bおよび第2MG16Cは、PCU16Eによって駆動される三相交流回転電機である。第1MG16Bは、動力分割装置16Dによって分割されたエンジン16Aの動力を用いて発電する。第2MG16Cは、蓄電装置15に蓄えられた電力および第1MG16Bにより発電された電力の少なくとも一方を用いて自車11の駆動力を発生する。また、第2MG16Cは、アクセルオフ状態(ユーザがアクセルペダルを踏んでいない状態)での惰性走行中において、駆動輪から伝達される車両10の運動エネルギを用いて回生発電する。第2MG16Cが発電した回生電力は蓄電装置15に回収される。
動力分割装置16Dは、エンジン16A、第1MG16Bおよび第2MG16Cを機械的に連結する、遊星歯車機構を含む(後述の図7参照)。
PCU16Eは、蓄電装置15に蓄えられた直流電力を第1MG16Bおよび第2MG16Cを駆動可能な交流電力に変換する。また、PCU16Eは、第1MG16Bおよび第2MG16Cで発電された交流電力を蓄電装置15に充電可能な直流電力に変換する。
通信装置17は、クラウドサーバ30の通信装置31との間で無線通信可能に構成される。通信装置17は、制御装置19と通信線で接続されており、制御装置19から伝達された情報(上述の車両走行データ等)をクラウドサーバ30に送信したり、クラウドサーバ30から受信した情報を制御装置19に伝達したりする。
HMI装置18は、車両10に関するさまざまな情報をユーザに提供したり、ユーザの操作を受け付けたりする装置である。HMI装置18は、室内に設けられたディスプレイ、スピーカなどを含む。
GPSモジュール100は、衛星測位システムにおいて用いられる受信装置である。GPSモジュール100は、受信された信号に基づいて車両10の現在位置を算出し、算出結果を制御装置19に出力する。なお、GPSモジュール100は、地図データベースを備えたナビゲーション装置に組み込まれていてもよい。
さらに、図示していないが、車両10は、車速を検出する車速センサ、蓄電装置15の状態(電圧、電流、温度など)を検出する監視センサ、車両10の加速度を検出する加速度センサなど、車両10の制御に必要なさまざまな物理量を検出するための複数のセンサを備える。これらの各センサは検出結果を制御装置19に出力する。
制御装置19は、図示しないCPUおよびメモリを内蔵し、当該メモリに記憶された情報や各センサからの情報に基づいて車両10の各機器(充電器14、駆動装置16、通信装置17、HMI装置18など)を制御する。
クラウドサーバ30は、各車両10の車両走行データを集約可能に構成される。具体的には、クラウドサーバ30は、上述のように、通信装置31と、管理装置32と、メモリ33とを備える。
通信装置31は、車両10の通信装置17との間で無線通信可能に構成される。通信装置31は、管理装置32と通信線で接続されており、管理装置32から伝達された情報を車両10に送信したり、車両10から受信した情報(上述の車両走行データ等)を管理装置32に伝達したりする。
管理装置32は、図示しないCPUを内蔵し、各車両10から受信した車両走行データ等の情報をメモリ33に記憶する。また、管理装置32は、メモリ33に記憶された各車両10の車両走行データを用いてさまざまな演算を行なう。たとえば、管理装置32は、各車両10からの要求に応じて、各車両10の走行経路と走行負荷との対応関係を示すデータ(以下「走行負荷データ」ともいう)をメモリ33に記憶された情報を用いて演算し、その演算結果を各車両10に送信する(後述の図5等参照)。
<車両の制御モード>
車両10の制御装置19は、CDモードおよびCS(Charge Sustaining)モードのいずれかを選択し、選択されたモードに応じて駆動装置16(エンジン16A、PCU16E等)を制御する。
CDモードとは、蓄電装置15のSOC(State Of Charge)を消費する制御モードである。CSモードとはSOCを所定の範囲に維持する制御モードである。CDモードおよびCSモードについては後程詳しく説明する。
制御装置19は、蓄電装置15のSOCが所定値Stgに低下するまではCDモードを選択し、SOCが所定値Stgに低下した後はCSモードを選択する。本実施の形態による自車11においては、3種類のCDモードおよび1種類のCSモードが用意されている。3種類のCDモードは、EV−AUTOモード、EV−CITYモード、および、EV優先モードである。制御装置19は、CDモードを選択する場合には、上記の3種類のCDモードからいずれか1つを選択する。
図3は、CDモードのうちのEV−AUTOモードと、CSモードとを説明するための図である。図3において、横軸は時間を示し、縦軸の上段はSOCの変化の一例を示し、縦軸の中段は要求パワー(ユーザのアクセル操作により要求される走行パワー)の変化の一例を示し、縦軸の下段はエンジン16Aの状態の一例を示す。図3に示す例では、外部充電により蓄電装置15が満充電状態(SOC=MAX)となった後、EV−AUTOモード(CDモード)で走行が開始された場合が示されている。
EV−AUTOモードにおいては、基本的には、蓄電装置15に蓄えられた電力(主には外部充電による電気エネルギ)が消費される。EV−AUTOモードでの走行中においては、SOCを維持するためにはエンジン16Aは作動しない。したがって、減速中の第2MG16Cの回生電力等により一時的にSOCが増加することはあるものの、結果的に充電よりも放電の割合の方が大きくなり、全体としてはSOCが徐々に減少する。
一方、CSモードにおいては、SOCが所定の範囲に維持される。一例として、時刻t1において、SOCが所定値Stgに低下すると、CSモードが選択され、その後、SOCは所定の範囲に維持される。具体的には、制御装置19は、SOCが低下するとエンジン16Aを作動させ、SOCが上昇するとエンジン16Aを停止させることによってSOCを所定の範囲に維持する。すなわち、CSモードにおいては、SOCを維持するためにエンジン16Aが作動する。
EV−AUTOモードおよびCSモードのいずれのモードにおいても、要求パワーが所定のエンジン始動しきい値未満である場合には、エンジン16Aが停止され、第2MG16C単独あるいは第1MG16Bおよび第2MG16Cの双方(以下、単に「モータ」ともいう)によって走行パワーが生成される(EV走行)。一方、要求パワーがエンジン始動しきい値以上である場合には、第2MG16Cおよびエンジン16Aによって走行パワーが生成される(HV走行)。エンジン16Aの作動に伴ない第1MG16Bが発電した電力は、第2MG16Cに直接供給されたり、蓄電装置15に蓄えられたりする。なお、EV−AUTOモードにおけるエンジン始動しきい値は、CSモードにおけるエンジン始動しきい値よりも大きい(後述の図4参照)。
このように、EV−AUTOモード(CDモード)においても、要求パワーがエンジン始動しきい値以上である場合には、エンジン16Aが作動する。また、要求パワーがエンジン始動しきい値未満であったとしても、エンジン16Aを熱源とする温水暖房の要求時およびエンジン16Aの暖機時等、エンジン16Aの作動が許容される場合もある。一方、CSモードにおいても、SOCが上昇すればエンジン16Aは停止する。すなわち、EV−AUTOモードは、エンジン16Aを常時停止させて走行するEV走行に限定されるものではなく、CSモードも、エンジン16Aを常時作動させて走行するHV走行に限定されるものではない。EV−AUTOモードにおいても、CSモードにおいても、EV走行とHV走行とが可能である。
自車11においては、CDモードとして、上記のEV−AUTOモードに加えて、EV−CITYモードおよびEV優先モードが用意されている。
図4は、各モードの走行パワーとその生成源の一例を模式的に示す図である。CSモードにおいては、要求パワーがエンジン始動しきい値P1未満である場合には、モータによって走行パワーが生成され、要求パワーがエンジン始動しきい値P1以上である場合には、モータおよびエンジン16Aによって走行パワーが生成される。CSモードの上限走行パワーは所定値P5に設定される。
EV−AUTOモードにおいても、CSモードと同様、エンジン16Aの作動が許容されるが、EV−AUTOモードにおけるエンジン始動しきい値P3は、CSモードにおけるエンジン始動しきい値P1よりも大きい値に設定されている。これにより、EV−AUTOモードにおいては、CSモードに比べて、モータによる走行領域が拡大されている。具体的には、要求パワーがエンジン始動しきい値P3(P3>P1)未満である場合には、モータによって走行パワーが生成され、要求パワーがエンジン始動しきい値P3以上である場合には、モータおよびエンジン16Aによって走行パワーが生成される。なお、EV−AUTOモードの上限走行パワーは、CSモードと同様、所定値P5に設定される。
EV優先モードにおいては、走行パワーを得るためにはエンジン16Aの作動は許容されず、かつ上限走行パワーがEV−AUTOモードにおけるエンジン始動しきい値P3よりも大きい所定値P4に設定される。したがって、EV優先モードにおいては、所定値P4未満の範囲でモータによって走行パワーが生成され、要求パワーが所定値P4以上になったとしてもエンジン16Aは作動しない。
EV−CITYモードにおいては、走行パワーを得るためにはエンジン16Aの作動は許容されず、かつ、上限走行パワーがEV−AUTOモードにおけるエンジン始動しきい値P3よりも小さい所定値P2に設定される。したがって、EV−CITYモードにおいては、所定値P2未満の範囲でモータによって走行パワーが生成され、要求パワーが所定値P2以上になったとしてもエンジン16Aは作動しない。
<制御モードの選択>
上述のように、自車11においては、蓄電装置15のSOCが所定値Stgに低下するまでは、CDモードが選択される。CDモードでの走行中において、ユーザは、HMI装置18あるいは図示しないモード選択用スイッチなどに対してモード選択操作を行なうことによって、上記3つのCDモード(EV−AUTOモード、EV−CITYモード、およびEV優先モード)のうちのいずれか1つを選択することができる。
たとえば、ユーザは、自車11の走行負荷履歴などを考慮して自車11の走行予定経路の走行負荷を把握し、把握された走行負荷に応じてモードを選択することができる。
しかしながら、自車11が走行したことのない経路においては、ユーザは、走行予定経路の走行負荷を正確には把握できない。その結果、選択されたモードが実際の走行負荷に応じた適切なモードではなく、要求パワーをレスポンスよく出力することができなくなることが懸念される。
上記の点に鑑み、本実施の形態による自車11の制御装置19は、クラウドサーバ30に集約された複数の車両10(他車12)の走行負荷データを用いて、自車11の走行予定経路の走行負荷を算出する。これにより、走行予定経路が自車11の走行したことのない経路であったとしても、走行予定経路の走行負荷を精度よく算出することができる。そして、制御装置19は、ユーザによるモード選択操作の有無に関わらず、算出された走行負荷に応じて、選択されるモード(以下、単に「選択モード」ともいう)を自動的に変更する。
たとえば、制御装置19は、EV優先モード中において、走行予定経路の走行負荷がしきい値よりも大きいエリア(以下「高負荷エリア」ともいう)があると判定された場合、自車11が高負荷エリアを走行する前に予め選択モードをEV優先モードからEV−AUTOモードに変更する。EV優先モードではエンジン16Aは作動しないのに対し、EV−AUTOモードでは要求パワーがエンジン始動しきい値P3以上である場合にエンジン16Aが作動される。言い換えれば、EV−AUTOモードは、EV優先モードよりもエンジン16Aの始動条件が成立し易いモードといえる。また、EV−AUTOモードの上限走行パワーP5は、EV優先モードの上限走行パワーP4よりも大きい。したがって、選択モードをEV優先モードからEV−AUTOモードに予め変更しておくことによって、自車11が高負荷エリアを走行する前にエンジン16Aを始動して上限走行パワーを所定値P4から所定値P5(P5>P4)に増加させておくことができる。その結果、自車11が高負荷エリアを走行する際に、要求パワーをレスポンスよく出力することができる。
図5は、自車11の制御装置19がEV優先モード中に実行する処理手順の一例を示すフローチャートである。このフローチャートは、所定周期で繰り返し実行される。なお、図5には、自車11の制御装置19の処理に加えて、制御装置19の処理に応じてクラウドサーバ30(管理装置32)が行なう処理についても併せて示される。
自車11の制御装置19は、EV優先モード中において、走行負荷リクエストをクラウドサーバ30に送信する(ステップS10)。走行負荷リクエストとは、クラウドサーバ30に対して、自車11の走行予定経路の走行負荷データを自車11に送信するように要求する信号である。走行負荷リクエストには、自車11を特定するために車両識別情報、自車11の走行予定経路を特定するための経路情報などが含まれる。なお、経路情報は、たとえば自車11の現在位置および進行方向とすることができる。これにより、クラウドサーバ30側で自車11の走行予定経路を予測することができる。また、経路情報は、自車11の目的地が設定される場合には、自車11の現在位置および目的地(自車11がナビゲーション装置を備える場合にはナビゲーション装置が演算した走行予定経路でもよい)とすることができる。これにより、クラウドサーバ30側で自車11の走行予定経路を把握することができる。
クラウドサーバ30は、自車11から走行負荷リクエストを受信したことに応じて、走行負荷リクエストに含まれる経路情報から自車11の走行予定経路を予測あるいは把握し、得られた走行予定経路の走行負荷データを集約する(ステップS100)。具体的には、クラウドサーバ30は、走行予定経路と同じ走行経路の走行負荷をメモリ33に記憶された各車両10の走行負荷データから集約(抽出)し、集約された走行負荷を走行予定経路の走行負荷データとする。そして、クラウドサーバ30は、集約された走行予定経路の走行負荷データを自車11に送信する(ステップS102)。
自車11の制御装置19は、クラウドサーバ30から走行予定経路の走行負荷データを受信したことに応じて、走行予定経路の走行負荷を算出する(ステップS12)。たとえば、クラウドサーバ30から受信した走行負荷データに、ハイブリッッド車両(プラグインハイブリッド車両を含む)、電気自動車、通常のエンジン車両のデータが含まれる場合、制御装置19は、自車11の車両タイプであるハイブリッッド車両のデータを抽出し、抽出されたデータから走行予定経路の走行負荷を算出する。
次いで、自車11の制御装置19は、算出された走行予定経路の走行負荷がしきい値よりも大きい高負荷エリアがあるか否かを判定する(ステップS14)。
走行予定経路の走行負荷がしきい値よりも大きい高負荷エリアがあると判定された場合(ステップS14にてYES)、自車11の制御装置19は、予め選択モードをEV優先モードからEV−AUTOモードに変更する(ステップS16)。これにより、自車11が高負荷エリアを走行する前に予めエンジン16Aを始動して上限走行パワーを大きくしておくことができる。
一方、走行予定経路の走行負荷がしきい値よりも大きい高負荷エリアがあると判定されない場合(ステップS14にてNO)、自車11の制御装置19は、EV優先モードを継続する(ステップS18)。
図6は、自車11の制御装置19がEV−AUTOモード中に実行する処理手順の一例を示すフローチャートである。なお、図6に示したステップのうち、前述の図5に示したステップと同じ番号を付しているステップについては、既に説明したため詳細な説明はここでは繰り返さない。
自車11の制御装置19は、EV−AUTOモード中において、走行負荷リクエストをクラウドサーバ30に送信する(ステップS10)。クラウドサーバ30は、自車11から走行負荷リクエストを受信したことに応じて走行予定経路の走行負荷データを集約し(ステップS100)、集約された走行予定経路の走行負荷データを自車11に送信する(ステップS102)。
自車11の制御装置19は、クラウドサーバ30から走行予定経路の走行負荷データを受信したことに応じて走行予定経路の走行負荷を算出し(ステップS12)、算出された走行予定経路の走行負荷がしきい値よりも小さいか否かを判定する(ステップS20)。
走行予定経路の走行負荷がしきい値よりも小さい場合(ステップS20にてYES)、自車11の制御装置19は、選択モードをEV−AUTOモードからEV優先モードに変更する(ステップS22)。これにより、走行負荷の低いエリアを走行する際にエンジン16Aが作動することが抑制され、燃費が向上し得る。
一方、走行予定経路の走行負荷がしきい値よりも大きい場合(ステップS20にてNO)、自車11の制御装置19は、EV−AUTOモードを継続する(ステップS24)。
以上のように、本実施の形態による自車11の制御装置19は、クラウドサーバ30に集約された複数の車両10(他車12)の走行負荷データを用いて、自車11の走行予定経路の走行負荷を算出する。そして、制御装置19は、EV優先モード中において、走行予定経路の走行負荷がしきい値よりも大きい高負荷エリアがあると判定された場合、選択モードを、EV優先モードから、エンジン16Aの始動条件が成立し易くかつ上限走行パワーがより大きいEV−AUTOモードに変更する。これにより、自車11が高負荷エリアを走行する前に予めエンジン16Aを始動して上限走行パワーを大きくしておくことができる。その結果、自車11が高負荷エリアを走行する際に、要求パワーをレスポンスよく出力することができる。
<変形例1>
上述の実施の形態においては、EV優先モード中に走行予定経路の走行負荷がしきい値よりも大きいと判定された場合、EV優先モードよりもエンジン16Aの始動条件が成立し易くかつ上限走行パワーが大きいEV−AUTOモードに変更するする例を示した。
しかしながら、変更前のモードおよび変更後のモードは、それぞれEV優先モードおよびEV−AUTOモードに限定されない。
たとえば、変更前のモードに対して、エンジン16Aの始動条件が同じで、上限走行パワーが大きいモードに変更するようにしてもよい。具体的には、エンジン16Aの作動が許容されておらず、上限走行パワーが所定値P2である「EV−CITYモード」中に走行予定経路の走行負荷がしきい値よりも大きいと判定された場合、同じくエンジン16Aの作動が許容されておらず、かつ上限走行パワーが所定値P2よりも大きい所定値P4である「EV優先モード」に変更するようにしてもよい。このようにしても、自車11が高負荷エリアを走行する前に上限走行パワーを大きくしておくことができるため、要求パワーをレスポンスよく出力することができる。
また、たとえば、変更前のモードに対して、エンジン16Aの始動条件が成立し易く、かつ上限走行パワーが同じモードに変更するようにしてもよい。具体的には、要求パワーがエンジン始動しきい値P3以上である場合にエンジン16Aが作動され、かつ上限走行パワーが所定値P5である「EV−AUTOモード」中に走行予定経路の走行負荷がしきい値よりも大きいと判定された場合、要求パワーがエンジン始動しきい値P1(P1<P3)以上である場合にエンジン16Aが作動され(すなわちエンジン16Aの始動条件が成立し易く)、かつ上限走行パワーが同じ所定値P5である「CSモード」に変更するようにしてもよい。このようにしても、自車11が高負荷エリアを走行する前にエンジン16Aを予め始動しておくことができる(エンジン16Aの始動に伴う応答遅れを回避できる)ため、要求パワーをレスポンスよく出力することができる。
<変形例2>
上述の図5、6のフローチャートにおいては、走行予定経路の走行負荷を算出する処理(ステップS12)および走行予定経路の走行負荷としきい値とを比較する処理(ステップS14、S20)を、自車11が実行する例を説明した。しかしながら、これらの処理をクラウドサーバ30が行なうようにしてもよい。たとえば、走行負荷リクエストを受信したクラウドサーバ30が走行予定経路の走行負荷を算出し、走行予定経路の走行負荷としきい値との比較結果を自車11に送信するようにしてもよい。この場合、自車11は、クラウドサーバ30から受信した比較結果に応じてモードを変更するようにすればよい。
[実施の形態2]
上述の実施の形態1による制御装置19は、EV優先モード中に走行予定経路の走行負荷がしきい値よりも大きいと判定される場合にEV−AUTOモードに変更する処理を行なった。
これに対し、本実施の形態2による制御装置19は、上記の処理に加えて、両モータ走行禁止処理を行なう。その他の構造、機能、処理は、前述の実施の形態1と同じであるため、ここでの詳細な説明は繰返さない。
両モータ走行禁止処理とは、両モータ走行およびエンジン16Aの作動が許容されるモード(EV−AUTOモードあるいはCSモード)中において、走行予定経路の走行負荷がしきい値よりも大きいと判定される場合に、両モータ走行を禁止する処理である。なお、以下では、主に、EV−AUTOモード中の両モータ走行禁止処理について説明するが、CSモード中においても同様の両モータ走行禁止処理を実行可能である。
両モータ走行とは、エンジン16Aを停止した状態で、第1MG16Bおよび第2MG16Cの両方の動力を用いて駆動輪90を回転させる走行モードである。
以下、自車11の駆動装置16の詳細構成、両モータ走行を含む自車11の走行態様、および両モータ走行禁止処理について、順に説明する。
<駆動装置の詳細構成>
図7は、自車11の駆動装置16の詳細構成の一例を示す図である。駆動装置16は、上述のエンジン16A、第1MG16B、第2MG16C、および動力分割装置16Dに加えて、カウンタ軸(出力軸)70、デファレンシャルギヤ80、および駆動輪90を含む。
図7に示す例では、第1MG16Bの回転軸は、エンジン16Aのクランク軸と同軸上に配置されている。第2MG16Cの回転軸は、第1MG16Bの回転軸と平行に配置される。カウンタ軸70は、第1MG16Bの回転軸および第2MG16Cの回転軸と平行に配置される。
動力分割装置16Dは、サンギヤSと、ピニオンギヤPと、キャリアCAと、リングギヤRとを含むシングルピニオン式の遊星歯車機構と、ワンウェイクラッチOWCとを備える。キャリアCAは、エンジン16Aのクランク軸と連結される。ピニオンギヤPは、サンギヤSとリングギヤRとの間に配置され、サンギヤSおよびリングギヤRとそれぞれ噛み合う。ピニオンギヤPは、キャリアCAによって自転および公転可能に支持される。
サンギヤSの回転速度(すなわち第1MG16Bの回転速度)、キャリアCAの回転速度(すなわちエンジン16Aの回転速度)、リングギヤRの回転速度は、後述するように、共線図上で直線で結ばれる関係(すなわち、いずれか2つの回転速度が決まれば残りの回転速度も決まる関係)になる。
ワンウェイクラッチOWCは、エンジン16Aのクランク軸に連結され、クランク軸の正方向への回転を許容し、負方向への回転を抑制する。
エンジン16Aおよび第1MG16Bの動力は、動力分割装置16Dを介してカウンタ軸70に伝達される。また、第2MG16Cの動力も、カウンタ軸70に伝達される。そして、カウンタ軸70は、デファレンシャルギヤ80を介して左右の駆動輪90に連結される。
<車両の走行態様>
本実施の形態による自車11は、EV走行(モータ走行)と、HV走行(ハイブリッド走行)のいずれかの走行態様で走行可能である。EV走行は、さらに、単モータ走行と両モータ走行とに細分化される。単モータ走行では、自車11は、第2MG16Cのみ動力で走行する。両モータ走行では、自車11は、第1MG16Bおよび第2MG16Cの両方の動力で走行する。
図8は、両モータ走行中におけるエンジン16A、第1MG16Bおよび第2MG16Cの制御状態の一例を動力分割装置16Dの共線図上に示す図である。図9は、HV走行中におけるエンジン16A、第1MG16Bおよび第2MG16Cの制御状態の一例を動力分割装置16Dの共線図上に示す図である。図8、図9に示す「S」、「CA」、「R」、「OWC」は、それぞれ動力分割装置16DのサンギヤS、キャリアCA、リングギヤR、ワンウェイクラッチOWCを示す。
図8を参照して、両モータ走行中に自車11が前進走行している場合の制御状態について説明する。両モータ走行では、エンジン16Aは停止されるとともに、ワンウェイクラッチOWCによってエンジン16Aの負方向への回転が規制される。この状態で、制御装置19は、第1MG16Bおよび第2MG16Cをモータとして動作させる。
具体的には、制御装置19は、第2MG16Cのトルク(以下「第2MGトルクTm2」ともいう)を正方向に作用させるとともに、第1MG16Bのトルク(以下「第1MGトルクTm1」ともいう)を負方向に作用させる。第2MGトルクTm2は、カウンタ軸70に伝達され、車両10の駆動力として作用する。第1MGトルクTm1は、キャリアCAを支点としてリングギヤRに伝達される。リングギヤRに伝達される第1MGトルクTm1(以下「第1MG伝達トルクTm1c」という)は、正方向に作用し、カウンタ軸70に伝達される。そのため、両モータ走行では、第1MG伝達トルクTm1cと第2MGトルクTm2とを用いて、自車11は走行する。
図9を参照して、HV走行中に自車11が前進走行している場合の制御状態について説明する。HV走行では、制御装置19は、エンジン16Aを作動させるとともに、第2MG16Cをモータとして動作させる。この状態で、制御装置19は、第1MGトルクTm1を負方向に作用させる。これにより、第1MGトルクTm1は、キャリアCAに入力されたエンジン16Aのトルク(以下「エンジントルクTe」ともいう)をリングギヤRに伝達するための反力トルクとして作用する。
リングギヤRに伝達されたエンジントルクTe(以下「エンジン伝達トルクTec」という)は、カウンタ軸70に伝達され、車両10の駆動力として作用する。また、第2MGトルクTm2は、カウンタ軸70に伝達され、車両10の駆動力として作用する。したがって、HV走行では、エンジン伝達トルクTecと第2MGトルクTm2とを用いて、自車11は走行する。
EV−AUTOモードにおいては、要求パワーがエンジン始動しきい値P3未満である場合にモータによって走行パワーが生成されるEV走行が行われ、要求パワーがエンジン始動しきい値P3以上である場合にモータおよびエンジン16Aによって走行パワーが生成されるHV走行が行われる(上述の図4参照)。
また、EV走行中(要求パワーがエンジン始動しきい値P3未満である場合)において、要求パワーがしきい値P6(P6<P3)未満である場合に単モータ走行が行われ、要求パワーがしきい値P6以上である場合には両モータ走行が行われる。したがって、EV−AUTOモード中における自車11の走行態様は、通常時(両モータ走行が禁止されない場合)においては、要求パワーの増加に伴って、単モータ走行、両モータ走行、HV走行の順に切り替えられることになる。
<両モータ走行禁止処理>
上述のように、EV−AUTOモード中における自車11の走行態様は、通常時(両モータ走行が禁止されない場合)においては、要求パワーの増加に伴って両モータ走行からHV走行に切り替えられるシーンが生じ得る。
しかしながら、両モータ走行からHV走行へ移行するには、停止中のエンジン16Aを第1MGトルクTm1を用いてクランキングして始動させる必要がある。この際、駆動トルクが一時的に急減する現象(以下「トルク抜け」ともいう)が生じることが懸念される。
図10は、両モータ走行からHV走行へ移行する際におけるエンジン16A、第1MG16Bおよび第2MG16Cの制御状態の一例を動力分割装置16Dの共線図上に示す図である。
両モータ走行からHV走行へ移行する際には、制御装置19は、負方向に作用させていた第1MGトルクTm1を正方向に作用させる。これにより、エンジン16Aがクランキングされる。この際、リングギヤRには、エンジン16Aのフリクションの反力として負方向のトルクが作用することになる。すなわち、要求パワーの増加に伴って両モータ走行からHV走行へ移行しようとすると、エンジン16Aをクランキングする際に、正方向に作用していた第1MG伝達トルクTm1cが一時的に負方向に作用することになる。その結果、ユーザがアクセル操作量を大きくして要求パワーを増加させているにも関わらず上記のトルク抜けが発生することになるため、ユーザに違和感を与えてしまうおそれがある。
上記の点に鑑み、本実施の形態2による制御装置19は、EV−AUTOモード中において、クラウドサーバ30に集約された走行負荷データを用いて算出された走行予定経路の走行負荷がしきい値(たとえばエンジン始動しきい値P3)よりも大きい高負荷エリアがあると判定される場合には、予め両モータ走行を禁止する。これにより、上記のトルク抜けを未然に防止することができる。
図11は、EV−AUTOモード中における走行パワーと走行態様との対応関係の一例を模式的に示す図である。
走行予定経路の走行負荷がしきい値(たとえばエンジン始動しきい値P3)よりも大きいと判定される場合、要求パワーがエンジン始動しきい値P3を超える可能性は低いため、制御装置19は、両モータ走行許容モードを選択する。両モータ走行許容モードでは、制御装置19は、通常どおり、要求パワーがエンジン始動しきい値P3未満である場合にEV走行を行なう。そして、EV走行中において、要求パワーがしきい値P6(P6<P3)未満である場合に単モータ走行を行ない、要求パワーがしきい値P6以上である場合には両モータ走行を行なう。なお、万が一、要求パワーがエンジン始動しきい値P3を超えた場合には、制御装置19は、エンジン16AをクランキングしてHV走行へ移行する。
一方、走行予定経路の走行負荷がしきい値(たとえばエンジン始動しきい値P3)よりも大きいと判定される場合、高負荷エリアを走行する際に要求パワーがエンジン始動しきい値P3を超える可能性が高いため、制御装置19は、両モータ走行禁止モードを選択する。両モータ走行禁止モードでは、制御装置19は、要求パワーがしきい値P6未満である場合に単モータ走行を行ない、要求パワーがしきい値P6以上である場合には両モータ走行を行なうことなく、エンジン16AをクランキングしてHV走行へ移行する。これにより、両モータ走行からHV走行への移行が生じなくなるため、上記のトルク抜けは生じない。その結果、トルク抜けを未然に防止することができる。
なお、両モータ走行禁止モードにおけるエンジン始動しきい値P6は、両モータ走行許容モードにおけるエンジン始動しきい値P3よりも低い。したがって、両モータ走行禁止モードは、両モータ走行許容モードよりも、エンジン16Aの始動条件が成立し易いモードである。
図12は、本実施の形態2による自車11の制御装置19がEV−AUTOモード中に実行する処理手順の一例を示すフローチャートである。なお、図12に示したステップのうち、前述の図5に示したステップと同じ番号を付しているステップについては、既に説明したため詳細な説明はここでは繰り返さない。
自車11の制御装置19は、クラウドサーバ30から走行予定経路の走行負荷データを受信したことに応じて走行予定経路の走行負荷を算出し(ステップS12)、算出された走行予定経路の走行負荷がしきい値よりも大きいか否かを判定する(ステップS30)。
走行予定経路の走行負荷がしきい値よりも大きいと判定されない場合(ステップS30にてNO)、自車11の制御装置19は、両モータ走行許容モードを選択する(ステップS34)。
一方、走行予定経路の走行負荷がしきい値よりも大きいと判定される場合(ステップS30にてYES)、自車11の制御装置19は、両モータ走行禁止モードを選択する(ステップS32)。これにより、トルク抜けが未然に防止される。
以上のように、本実施の形態2による制御装置19は、クラウドサーバ30に集約された走行負荷データを用いて算出された走行予定経路の走行負荷がしきい値よりも大きいと判定される場合には、予め両モータ走行を禁止する。これにより、両モータ走行からHV走行への移行を生じない状態となる。その結果、トルク抜けを未然に防止することができる。
上述した実施の形態1、2および変形例1、2については、技術的に矛盾が生じない範囲で適宜組合せることが可能である。
今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本開示の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。