JP2022160174A - マネージャ、電子制御ユニット、システム、制御方法、制御プログラム、及び車両 - Google Patents

Abstract

【課題】制御のもたつきの発生を抑制することができるマネージャなどを提供する。
【解決手段】車両に搭載されたマネージャであって、複数のＡＤＡＳアプリケーションから複数の行動計画を受け付ける受付部と、複数の行動計画を調停する調停部と、調停部による調停結果に基づいて運動要求を算出する算出部と、運動要求を少なくとも１つのアクチュエータシステムに分配する分配部と、を備え、受付部は、調停部における調停対象に関する情報をＡＤＡＳアプリケーションから受け付ける。
【選択図】図１

Description

本開示は、車両に搭載されるマネージャなどに関する。

近年、自動運転や自動駐車などの自動運転機能を実現する先進運転支援アプリケーション（ＡＤＡＳ（Advanced Driver Assistance System）アプリケーション）が、車両に複数実装されている。特許文献１には、これらの複数のＡＤＡＳアプリケーションから出力される要求をそれぞれ受け付けて、この受け付けた複数の要求を調停し、その調停結果に基づいてアクチュエータシステム（パワートレインアクチュエータやブレーキアクチュエータなどを含むシステム）を駆動するための要求を出力する、マネージャ（制御装置）が開示されている。

特開２０２０－０３２８９４号公報

このようなマネージャには、車両を最も安全かつ安心に制御するため、複数のＡＤＡＳアプリケーションから複数の要求を受け付けた場合、複数の要求における最小の要求を採択する基本機能を有したものがある。しかしながら、この基本機能においては、複数のＡＤＡＳアプリケーションから今後出力を終えようとしている既存の要求と新たに出力された新規の要求との両方を受け付けた場合、調停の結果によっては既存の要求が終えるまで新規の要求が採択されず、制御のもたつきを発生させてしまう（乗員にもたつき感を与えてしまう）おそれがあった。

本開示は、上記課題を鑑みてなされたものであり、制御のもたつきの発生を抑制することができるマネージャなどを提供することを目的とする。

上記課題を解決するために、本開示技術の一態様は、車両に搭載されたマネージャであって、複数のＡＤＡＳアプリケーションから複数の行動計画を受け付ける受付部と、複数の行動計画を調停する調停部と、調停部による調停結果に基づいて運動要求を算出する算出部と、運動要求を少なくとも１つのアクチュエータシステムに分配する分配部と、を備え、受付部は、調停部における調停対象に関する情報をＡＤＡＳアプリケーションから受け付ける、マネージャである。

本開示によれば、今後出力を終えようとしている既存の要求を調停対象から除外するため、新規の要求が調停で採択されやすくなり、制御のもたつきの発生を抑制することができる。

本開示の一実施形態に係るシステムの構成例を示す概略図 マネージャが実行する調停処理の手順を示すフローチャート 複数の要求加速度（行動計画）の調停処理例を説明する図 複数の要求加速度（行動計画）の調停処理例を説明する図 マネージャが実行する制限処理の手順を示すフローチャート 駆動力（運動要求）の制限処理例を説明する図 駆動力（運動要求）の他の制限処理例を説明する図

本開示のマネージャは、アプリケーションからの要求が複数競合して発生している場合において、その複数の行動計画の中に今後要求を終了する予定である行動計画が含まれている場合には、この終了予定の行動計画を除外して調停を行う。これにより、終了予定の行動計画の要求が終えるまで他の行動計画の要求が採択されないといったことを回避することができる。
以下、本開示の一実施形態について、図面を参照しながら詳細に説明する。

＜実施形態＞
［構成］
図１は、本開示の一実施形態に係る車両に搭載されるシステム１の構成例を示す概略図である。図１に例示したシステム１は、マネージャ１０と、運転支援システム２０と、複数のアクチュエータシステム３０及び４０と、を備えている。システム１が備える各構成は、車載ネットワーク１００を介して通信可能に接続されている。車載ネットワーク１００は、ＣＡＮ（Controller Area Network）やイーサネット（登録商標）などを例示できる。

運転支援システム２０は、実装されるアプリケーションを実行することにより、少なくとも車両の駆動制御及び制動制御を含む車両の運転を支援するための様々な機能を実現するための構成である。運転支援システム２０が実装するアプリケーションとしては、自動運転の機能を実現する自動運転アプリケーション、自動駐車の機能を実現する自動駐車アプリケーション、及び先進運転支援の機能を実現するＡＤＡＳアプリケーションなどを例示できる。ＡＤＡＳアプリケーションには、衝突回避支援（ＰＣＳなど）の機能を実現するアプリケーション、前走車との車間距離を一定に保ちながら走行する前車追従走行（ＡＣＣなど）の機能を実現するアプリケーション、走行する車線の維持を行う車線維持支援（ＬＫＡ、ＬＴＡなど）の機能を実現するアプリケーション、衝突の被害を軽減させるために自動的に制動をかける衝突被害軽減ブレーキ（ＡＥＢなど）の機能を実現するアプリケーション、車両の走行車線の逸脱を警告する車線逸脱警報（ＬＤＷ、ＬＤＡなど）の機能を実現するアプリケーションなど、がある。

この運転支援システム２０の各アプリケーションは、図示しない各種センサなどから取得（入力）する車両の情報（認識センサ情報など）に基づいて、アプリケーションの要求として、アプリケーション単独での機能性（商品性）を担保した行動計画の要求を、マネージャ１０にそれぞれ出力する。この行動計画には、車両に発生させる前後加速度／減速度に関する要求などが含まれる。また、運転支援システム２０の各アプリケーションは、行動計画と共に、自身のアプリケーションを一意に特定することができる識別情報（アプリＩＤ）を、マネージャ１０にそれぞれ出力することができる。このアプリＩＤは、アプリケーションごとに予めユニークに定められている。

さらに、運転支援システム２０の各アプリケーションは、現在要求している行動計画の生成の終了を予定していることを示す情報を、マネージャ１０にそれぞれ出力する。この情報には、例えばフラグを用いることができ、行動計画の生成を終了するまでの所定の期間にフラグをＯＮ状態にすることで、マネージャ１０に対して行動計画の生成終了を事前に通知することができる。このような生成終了を予定している行動計画は優先度が低い行動計画と考えられるため、以降これらに付されるフラグを「低優先フラグ」と記すことにする。一例として、行動計画として加速度を出力しているＡＣＣアプリケーションは、自らの要求を今後終えるために要求する加速度をアクチュエータシステム３０及び４０から発生可能な駆動力の下限値に漸近させる縮退処理を実施するような場合、この縮退処理を開始した直後から加速度の要求を停止するまでの期間中は、上述した低優先フラグをＯＮ状態にしてマネージャ１０に出力することができる。

この運転支援システム２０は、ＣＰＵなどのプロセッサ、メモリ、及び入出力インターフェイス（出力部）を有する電子制御ユニット（ＥＣＵ：Electronic Control Unit）などのコンピューターによって実現される。なお、運転支援システム２０を構成するＥＣＵの数や、ＥＣＵが実装するアプリケーションの数は、特に限定されない。また、運転支援システム２０として、アプリケーションごとにそれぞれのＥＣＵが設けられてもよい。例えば、自動運転アプリケーションが実装された自動運転ＥＣＵ、自動駐車アプリケーションが実装された自動駐車ＥＣＵ、及び先進運転支援アプリケーションが実装されたＡＤＡＳ－ＥＣＵによって、運転支援システム２０が構成されてもよい。また、ＡＣＣ機能を実現するＡＤＡＳアプリケーションが実装されたＥＣＵ、ＬＫＡ機能を実現するＡＤＡＳアプリケーションが実装されたＥＣＵ、及びＡＥＢ機能を実現するＡＤＡＳアプリケーションが実装されたＥＣＵのように、複数のＡＤＡＳアプリケーションが複数のＥＣＵに実装されてもよい。

複数のアクチュエータシステム３０及び４０は、運転支援システム２０が出力する行動計画の要求を実現するための実現システムの１つである。一例として、アクチュエータシステム３０は、車両に制駆動力を発生させることが可能なパワートレインアクチュエータ（エンジンやトランスミッションなど）を含み、パワートレインアクチュエータの動作を制御することによって、行動計画の要求を実現させるパワートレインシステムである。また、一例として、アクチュエータシステム４０は、車両に制動力を発生させることが可能なブレーキアクチュエータ（油圧ブレーキ、電動パーキングブレーキなど）を含み、ブレーキアクチュエータの動作を制御することによって、行動計画の要求を実現させるブレーキシステムである。なお、車両に搭載されるアクチュエータシステムの数は、特に限定されない。

マネージャ１０は、運転支援システム２０から受け付ける行動計画の要求に基づいて、車両の運動に関する制御内容を決定し、この決定した制御内容に基づいてアクチュエータシステム３０及び／又は４０に対して必要な要求を出力する。また、マネージャ１０は、運転支援システム２０から行動計画の要求と共に取得した低優先フラグに基づいて、複数のアクチュエータシステム３０及び／又は４０に運動要求の分配を行う。

このマネージャ１０は、いわゆる車両の運動に関わるＡＤＡＳ－ＭＧＲやＶｅｈｉｃｌｅ－ＭＧＲなどとして、あるいはＡＤＡＳ－ＭＧＲやＶｅｈｉｃｌｅ－ＭＧＲの一部として機能し、車両の動きを制御する。マネージャ１０は、受付部１１と、調停部１２と、算出部１３と、分配部１４と、を含む。

受付部１１は、運転支援システム２０の複数のアプリケーションが出力する行動計画の要求及び低優先フラグを受け付ける。本実施形態における行動計画としては、車両の前後方向（縦方向）運動に関する加速度を例示することができる。また、受付部１１は、パワートレインアクチュエータを含むアクチュエータシステム３０から、発生可能な駆動力下限（アベイラビリティ下限）を受け付ける。この駆動力下限とは、パワートレインアクチュエータが現在の変速比（ギア段）においてアクセルペダルを踏み込まないアクセル全閉状態で実現可能な駆動力の下限値（最小駆動力）である。受付部１１が受け付けた行動計画の要求、低優先フラグ、及び駆動力下限は、調停部１２に出力される。

調停部１２は、受付部１１が運転支援システム２０の各アプリケーションから受け付けた複数の行動計画の要求を調停する。この調停の処理としては、所定の選択基準（例えば、Ｍｉｎ選択）に基づいて複数の行動計画の中から１つの行動計画を選択することが例示できる。また、他の調停処理として、複数の行動計画に基づいて新たな行動計画を設定することもできる。このとき、調停部１２は、受付部１１が各アプリケーションから受け付けた低優先フラグと、マネージャ１０がアクチュエータシステム３０から取得する発生可能な駆動力下限とに基づいて、複数の行動計画の要求を調停する。この調停については、後述する。

なお、受付部１１が各アプリケーションから受け付ける行動計画について、調停に関する優先順位が予め定められている場合がある。このような場合、調停部１２は、行動計画の調停に際して、この優先順位よりも先に低優先フラグを適用して複数の行動計画を調停したり、低優先フラグに基づいて優先順位を一時的に変更させてから複数の行動計画を調停したり、してもよい。

算出部１３は、調停部１２における行動計画の要求の調停結果に基づいて、運動要求を算出する。この運動要求は、アクチュエータシステム３０／又は４０を制御するための物理量であり、行動計画の要求の物理量とは異なる。例えば、行動計画の要求が加速度である場合には、運動要求として駆動力や駆動トルクを算出することができる。これにより、加速度の要求が駆動力や駆動トルクの要求に変換される。

また、算出部１３は、各アプリケーションから受け付けた低優先フラグと、マネージャ１０がアクチュエータシステム３０から取得する発生可能な駆動力下限とに基づいて、自らが算出した運動要求に対して所定の制限処理を施すことができる。この制限処理については、後述する。

分配部１４は、算出部１３によって算出された運動要求又は算出後に制限処理が施された運動要求を、少なくとも１つのアクチュエータシステム３０及び／又は４０に分配する。例えば、ブレーキを用いない場合には、分配部１４は、パワートレインアクチュエータを含むアクチュエータシステム３０のみに運動要求を分配する。また例えば、エンジンとブレーキとを併用する場合には、分配部１４は、パワートレインアクチュエータを含むアクチュエータシステム３０と、ブレーキアクチュエータを含むアクチュエータシステム４０とに、運動要求を適切に分配する。

なお、以上説明した、車両に搭載されたマネージャ１０、運転支援システム２０、及びアクチュエータシステム３０及び４０の構成は一例であって、適宜、追加、置換、変更、省略などが可能である。また、各機器の機能は適宜１つの機器に統合したり複数の機器に分散したりして実装することが可能である。

［制御］
図２乃至図７をさらに参照して、本実施形態に係るマネージャ１０が実行する制御を説明する。

（１）調停／算出処理
図２は、マネージャ１０の調停部１２及び算出部１３が実行する調停／算出処理の手順を説明するフローチャートである。この図２に示す調停／算出処理は、マネージャ１０の受付部１１が、運転支援システム２０のアプリケーションから行動計画の要求を受け付けた場合に開始される。行動計画としては、加速度を例示できる。

（ステップＳ２０１）
調停部１２は、受付部１１がアプリケーションから受け付けた行動計画の数を確認する。行動計画が２つ以上である場合は（ステップＳ２０１、２つ以上）、ステップＳ２０２に処理が進み、行動計画が１つのみである場合は（ステップＳ２０１、１つ）、ステップＳ２０６に処理が進む。

（ステップＳ２０２）
調停部１２は、受付部１１がアプリケーションから受け付けた２つ以上の行動計画の中に、低優先フラグがＯＮとなっている行動計画があるか否かを判断する。すなわち、調停部１２は、各アプリケーションから要求された複数の行動計画の中に、縮退しながら出力を終了しようとしている優先度が低い行動計画が含まれているか否かを判断する。以下、この低優先フラグがＯＮとなっている行動計画を「低優先行動計画」という。低優先フラグがＯＮとなっている低優先行動計画が１つ以上ある場合は（ステップＳ２０２、はい）、ステップＳ２０３に処理が進む（パターン［Ａ］）。一方、低優先フラグがＯＮとなっている低優先行動計画が全くない場合は（ステップＳ２０２、いいえ）、ステップＳ２０４に処理が進む（パターン［Ｂ］）。

（ステップＳ２０３）
調停部１２は、受付部１１がアプリケーションから受け付けた２つ以上の行動計画のうち低優先フラグがＯＮとなっている低優先行動計画を除外し、この低優先行動計画を除外した残りの行動計画を対象として調停を実施する。調停処理としては、調停対象となる行動計画のうち最小値を要求する行動計画を採択する手法を例示できる。行動計画の調停が実施されると、ステップＳ２０５に処理が進む。

（ステップＳ２０４）
調停部１２は、受付部１１がアプリケーションから受け付けた全ての行動計画を対象として調停を実施する。調停処理としては、全ての行動計画のうち最小値を要求する行動計画を採択する手法を例示できる。行動計画の調停が実施されると、ステップＳ２０５に処理が進む。

（ステップＳ２０５）
算出部１３は、調停部１２の調停結果に基づいて運動要求を算出する。運動要求としては、駆動力を例示できる。この算出した運動要求は、少なくとも１つのアクチュエータシステム３０及び／又は４０に分配する運動要求として、マネージャ１０の分配部１４に出力される。運動要求が算出されると、本調停／算出処理が終了する。

（ステップＳ２０６）
算出部１３は、受付部１１がアプリケーションから受け付けた１つの行動計画に基づいて運動要求を算出する。この１つの行動計画は、調停部１２によって調停結果として採択される行動計画である。運動要求としては、駆動力を例示できる。運動要求が算出されると、ステップＳ２０７に処理が進む。

（ステップＳ２０７）
算出部１３は、運動要求を算出した１つの行動計画の低優先フラグがＯＮであるか否かを判断する。すなわち、算出部１３は、１つの行動計画の要求が縮退しながら終了しようとしている状態であるか否かを判断する。１つの行動計画の低優先フラグがＯＦＦである場合は（ステップＳ２０７、いいえ）、上記ステップＳ２０６で算出した運動要求が少なくとも１つのアクチュエータシステム３０及び／又は４０に分配する運動要求として分配部１４に出力されて、本調停／算出処理が終了する（パターン［Ｃ］）。一方、１つの行動計画の低優先フラグがＯＮである場合は（ステップＳ２０７、はい）、ステップＳ２０８に処理が進む（パターン［Ｄ］）。

（ステップＳ２０８）
算出部１３は、上記ステップＳ２０６で算出した運動要求に対して所定の制限処理を施す。この制限処理については、後述する。上記ステップＳ２０６で算出した運動要求に制限処理が施された新たな運動要求が、少なくとも１つのアクチュエータシステム３０及び／又は４０に分配する運動要求として分配部１４に出力されて、本調停／算出処理が終了する。

このように、各アプリケーションから受け付けた複数の行動計画の中に今後要求を終了する予定である低優先行動計画がある場合には、この低優先行動計画を調停の対象から除外する。これにより、低優先行動計画以外の行動計画が採択されるようになるので、制御のもたつきの発生を抑制することができる。

なお、上記実施形態では、行動計画の低優先フラグがＯＮであるか否かの判断を、調停部１２及び算出部１３がそれぞれ行う例を説明した。しかし、この判断を別の構成（例えば、フラグ判断部など）が行って、その判断結果を調停部１２及び算出部１３にそれぞれ出力するようにしてもよい。

図３及び図４を参照して、マネージャ１０が実行する調停／算出処理を具体的に説明する。この具体例では、運転支援システム２０の各アプリケーションから行動計画として前後方向の加速度が要求され、調停処理においては複数の加速度の中から最小の加速度が採択される場合（Ｍｉｎ選択）を説明する。

図３は、アプリケーションＡから要求される行動計画（以下「アプリＡ要求」という）とアプリケーションＢから要求される行動計画（以下「アプリＢ要求」という）との両方が発生した後で、アプリＡ要求の低優先フラグがＯＮ状態となる例を示している。

アプリＡ要求のみである時間Ｔ＜ｔ１の期間では、アプリケーションＡの行動計画で要求される加速度（以下「アプリＡ要求加速度」という）が調停によって採択される（図２のパターン［Ｃ］）。

アプリＡ要求とアプリＢ要求とが競合して調停が行われる時間ｔ１≦Ｔ＜ｔ３の期間のうち時間ｔ１≦Ｔ＜ｔ２の期間では、アプリＡ要求の低優先フラグがまだＯＦＦ状態であるため、最小値であるアプリＡ要求加速度が調停によって採択される（図２のパターン［Ｂ］）。

アプリＡ要求とアプリＢ要求とが競合して調停が行われる時間ｔ１≦Ｔ＜ｔ３の期間のうち時間ｔ２≦Ｔ＜ｔ３の期間では、アプリＡ要求の低優先フラグがＯＮ状態になり、アプリＡ要求加速度が調停の対象から除外されるため、アプリケーションＢの行動計画で要求される加速度（以下「アプリＢ要求加速度」という）が調停によって採択される（図２のパターン［Ａ］）。

アプリＡ要求が終了してアプリＢ要求のみである時間ｔ３≦Ｔの期間では、アプリＢ要求加速度が調停によって採択される。

図４は、アプリＢ要求が発生する前に、既に発生しているアプリＡ要求の低優先フラグがＯＮ状態となっている例を示している。

アプリＡ要求のみである時間Ｔ＜ｔ２の期間のうち時間Ｔ＜ｔ１の期間では、アプリＡ要求加速度が調停によって採択される（図２のパターン［Ｃ］）。

アプリＡ要求のみである時間Ｔ＜ｔ２の期間のうち時間ｔ１≦Ｔ＜ｔ２の期間では、時間Ｔ＜ｔ１の期間と同様にアプリＡ要求加速度が調停によって採択されるが、アプリＡ要求の低優先フラグがＯＮ状態であるため、アプリＡ要求加速度に基づいて算出される駆動力（運動要求）に後述する制限処理が施される（図２のパターン［Ｄ］）。

アプリＡ要求とアプリＢ要求とが競合して調停が行われる時間ｔ２≦Ｔ＜ｔ３の期間では、アプリＡ要求の低優先フラグがＯＮ状態であるためアプリＡ要求加速度が調停の対象から除外されて、アプリＢ要求加速度が調停によって採択される（図２のパターン［Ａ］）。

アプリＢ要求のみである時間ｔ３≦Ｔの期間では、アプリＢ要求加速度が調停によって採択される。

上述した例のように、アプリケーションからの要求が複数競合して発生している場合では、低優先フラグがＯＮ状態であるアプリケーションの要求を調停の対象から除外する。このため、例えば縮退処理によって極端に低い加速度を要求しているアプリケーションの行動計画が調停で採択されることを回避できるので、制御のもたつきの発生を抑制することができる。

（２）制限処理
次に、図５を参照して、上述した調停／算出処理においてマネージャ１０の算出部１３が運動要求に施す制限処理（図２のステップＳ２０８）を説明する。図５は、マネージャ１０が実行する制限処理の手順を説明するフローチャートである。

（ステップＳ５０１）
マネージャ１０は、車両がブレーキ制御を実行している最中（実行中）であるか否かを判断する。ブレーキ制御が実行中であるか否かは、アクチュエータシステム４０がブレーキアクチュエータを動作させているか否かによって判断可能である。ブレーキ制御が実行中である場合は（ステップＳ５０１、はい）、ステップＳ５０２に処理が進む。一方、ブレーキ制御が実行中ではない場合は（ステップＳ５０１、いいえ）、ステップＳ５０３に処理が進む。

（ステップＳ５０２）
マネージャ１０は、ブレーキ制御の実行状態を保持する。すなわち、マネージャ１０の分配部１４は、ブレーキアクチュエータによるブレーキ制御がそのまま継続して実行されるように、運動要求をアクチュエータシステム４０に適切に分配する。ブレーキ制御の実行状態が保持されると、ステップＳ５０４に処理が進む。

（ステップＳ５０３）
マネージャ１０は、ブレーキ制御を実行しない状態を保持する。すなわち、マネージャ１０の分配部１４は、ブレーキアクチュエータによるブレーキ制御が新たに発生しないように、アクチュエータシステム４０への運動要求の分配を制限（又は禁止）する。ブレーキ制御を実行しない状態が保持されると、ステップＳ５０５に処理が進む。

（ステップＳ５０４）
マネージャ１０の算出部１３は、行動計画の調停結果に基づいて算出した運動要求を所定の下限値に基づいて制限する。この所定の下限値は、運動要求が駆動力である場合、現在の変速比におけるパワートレインアクチュエータが実現可能な駆動力の下限値（駆動力下限）とすることができる。マネージャ１０は、パワートレインアクチュエータを含むアクチュエータシステム３０からフィードバック入力することで、駆動力下限を取得することができる。駆動力下限に基づいて制限された運動要求は、分配部１４によってアクチュエータシステム３０及び／又は４０に分配される。運動要求が駆動力下限に基づいて制限されると、ステップＳ５０６に処理が進む。

（ステップＳ５０５）
マネージャ１０の算出部１３は、行動計画の調停結果に基づいて算出した運動要求に制限を施さない。すなわち、制限がされていない運動要求が、分配部１４によってアクチュエータシステム３０及び／又は４０に分配される。その後、ステップＳ５０６に処理が進む。

（ステップＳ５０６）
マネージャ１０は、受付部１１がアプリケーションから受け付けていた既存の行動計画の要求が終了したか否か、又は受付部１１が他のアプリケーションから新たな行動計画の要求を受け付けたか否かを、判断する。既存の行動計画の要求が終了した場合又は新たな行動計画の要求があった場合は（ステップＳ５０６、はい）、ステップＳ５０８に処理が進む。一方、既存の行動計画の要求が終了せずかつ新たな行動計画の要求もない場合は（ステップＳ５０６、いいえ）、ステップＳ５０７に処理が進む。

（ステップＳ５０７）
マネージャ１０は、受付部１１がアプリケーションから受け付けていた既存の行動計画の要求における低優先フラグがＯＦＦになったか否かを判断する。既存の行動計画の要求における低優先フラグがＯＦＦになった場合は（ステップＳ５０７、はい）、ステップＳ５０８に処理が進む。一方、既存の行動計画の要求における低優先フラグがＯＮのままである場合は（ステップＳ５０７、いいえ）、ステップＳ５０６に処理が進む。

（ステップＳ５０８）
マネージャ１０は、上記ステップＳ５０２又はＳ５０３で行ったブレーキ制御の保持状態、及び上記ステップＳ５０４で行った運動要求の制限状態を、それぞれ解除する。保持及び制限の状態が解除されると、本制限処理が終了する。

このように、アプリケーションから受け付けた行動計画が１つのみであった場合、この行動計画が縮退を経て要求を終えようとしている低優先行動計画であれば、行動計画に基づいて算出される運動要求を所定の下限値に制限する。これにより、例えば、駆動力である運動要求をパワートレインアクチュエータが発生可能な駆動力の下限値（駆動力下限）に制限することで、要求駆動力が駆動力下限を跨いで変化することがなくなり、ブレーキアクチュエータの動作／非動作の状態が頻繁に切り替わって車両の乗り心地が悪化してしまうといった現象を抑制することができる。

次に、図６及び図７を参照して、マネージャ１０が実行する制限処理を具体的に説明する。この具体例では、マネージャ１０の算出部１３によって運動要求として駆動力が算出される場合を説明する。

図６は、ブレーキアクチュエータによるブレーキ制御が実行されていない状態（未実行）で、アプリケーションＡから要求される行動計画（以下「アプリＡ要求」という）の低優先フラグがＯＮ状態となる例を示している。

図６の例では、低優先フラグがＯＮ状態になった時点（時間ｔ１）でブレーキアクチュエータによるブレーキ制御が実行されていないため、そのブレーキ制御が実行されていない状態が保持される。よって、その後、要求駆動力（実線）がパワートレインアクチュエータの駆動力下限（一点鎖線）を下回ったとしても（時間ｔ２≦Ｔ≦ｔ３）、ブレーキ制御が実行されない（ブレーキアクチュエータが非動作）。つまり、アプリＡ要求がなくなる又は低優先フラグがＯＦＦ状態になる時点（時間ｔ４）まで、アプリケーションＡから要求されるがまま（成り行き）の駆動力がパワートレインアクチュエータに分配されることとなる。

図７は、ブレーキアクチュエータによるブレーキ制御が実行されている状態（実行中）で、アプリＡ要求の低優先フラグがＯＮ状態となる例を示している。

図７の例では、アプリＡ要求の駆動力（実線）がパワートレインアクチュエータの駆動力下限（一点鎖線）を下回った時点（時間ｔ１）で、ブレーキ制御が実行される。その後、低優先フラグがＯＮ状態になった時点（時間ｔ２）で、ブレーキ制御が実行中の状態が保持される。さらに、要求駆動力が駆動力下限を超えないように制限される。この制限により、アプリＡ要求が駆動力下限を超える駆動力（点線）を要求する内容だったとしても、ブレーキ制御の実行を継続するように、駆動力がブレーキアクチュエータとパワートレインアクチュエータとに適切に分配される。従って、アプリＡ要求がなくなる又は低優先フラグがＯＦＦ状態になるまで（時間ｔ４）、実行しているブレーキ制御が停止する（ブレーキアクチュエータが非動作に切り替わる）ことがなくなる。

＜作用・効果＞
以上のように、本開示の一実施形態に係るシステムでは、アプリケーションから行動計画の要求が複数競合して発生している場合において、その複数の行動計画の中に今後要求を終了する予定である行動計画（低優先行動計画）が含まれている場合には、この終了予定の行動計画を除外して調停を行う。これにより、終了予定の行動計画（例えば、縮退処理によって極端に低い加速度を要求しているアプリケーションの行動計画）以外の行動計画が採択されやすくなる。よって、終了予定の行動計画の要求が終えるまで他の行動計画の要求が採択されないといったことを回避し、制御のもたつきの発生を抑制することができる。

また、本実施形態に係るシステムでは、アプリケーションから受け付けた行動計画が１つのみであった場合でも、この１つの行動計画が低優先行動計画であるならば、低優先行動計画に基づいて算出される運動要求を所定の下限値に制限する。これにより、例えば、駆動力である運動要求をパワートレインアクチュエータから発生可能な駆動力下限に制限することで、運動要求が下限値を跨いで変化することがなくなり、ブレーキアクチュエータの動作／非動作の状態が頻繁に切り替わって車両の乗り心地が悪化してしまうといった現象を抑制することができる。

以上、本開示技術の一実施形態を説明したが、本開示は、車両に搭載されるマネージャだけでなく、電子制御ユニット、電子制御ユニットとマネージャとを含むシステム、プロセッサとメモリを備えたマネージャが実行する制御方法、制御プログラム、制御プログラムを記憶したコンピューター読み取り可能な非一時的な記憶媒体、あるいはマネージャを備えた車両など、として捉えることが可能である。

本開示は、車両などに搭載されるマネージャなどに有用である。

１ システム
１０ マネージャ
１１ 受付部
１２ 調停部
１３ 算出部
１４ 分配部
２０ 運転支援システム
３０、４０ アクチュエータシステム
１００ 車載ネットワーク

Claims (14)

1. 車両に搭載されたマネージャであって、
   複数のＡＤＡＳアプリケーションから複数の行動計画を受け付ける受付部と、
   前記複数の行動計画を調停する調停部と、
   前記調停部による調停結果に基づいて、運動要求を算出する算出部と、
   前記運動要求を少なくとも１つのアクチュエータシステムに分配する分配部と、を備え、
   前記受付部は、前記調停部における調停対象に関する情報を前記ＡＤＡＳアプリケーションから受け付ける、
   マネージャ。
2. 前記調停対象に関する情報は、前記行動計画が、前記調停部による調停の対象とする優先度が低い低優先行動計画であることを示す情報である、
   請求項１に記載のマネージャ。
3. 前記低優先行動計画には、前記ＡＤＡＳアプリケーションが生成の終了を予定している前記行動計画が含まれる、
   請求項２に記載のマネージャ。
4. 前記ＡＤＡＳアプリケーションが生成の終了を予定している前記行動計画では、縮退処理がなされている、
   請求項３に記載のマネージャ。
5. 前記縮退処理は、前記行動計画を、前記アクチュエータシステムから発生可能な駆動力下限に漸近させる処理である、
   請求項４に記載のマネージャ。
6. 前記調停部は、前記低優先行動計画を除外した残りの前記行動計画を調停する、
   請求項２乃至５のいずれか１項に記載のマネージャ。
7. 前記調停部は、前記受付部によって前記複数のＡＤＡＳアプリケーションから前記低優先行動計画のみが受け付けられた場合、前記低優先行動計画を調停結果として出力し、
   前記算出部は、前記調停結果である前記低優先行動計画に基づいて算出した前記運動要求を、ブレーキ制御の実行状態に応じて前記アクチュエータシステムから発生可能な駆動力下限に基づいて制限する、
   請求項６に記載のマネージャ。
8. 前記算出部は、前記ブレーキ制御が実行中である場合に、前記アクチュエータシステムから発生可能な駆動力下限に基づいて前記運動要求を制限する、
   請求項７に記載のマネージャ。
9. 前記駆動力下限は、現在の変速比におけるパワートレインアクチュエータが実現可能な駆動力の下限値であり、
   前記少なくとも１つのアクチュエータシステムは、前記パワートレインアクチュエータを含むパワートレインシステムを含む、
   請求項５、７、８のいずれか１項に記載のマネージャ。
10. 車両に搭載され、１つ以上のＡＤＡＳアプリケーションを実装する電子制御ユニットであって、
    前記ＡＤＡＳアプリケーションの行動計画と、前記行動計画の調停処理における調停対象に関する情報とを、マネージャに出力する出力部を備える、
    電子制御ユニット。
11. 車両に搭載され、１つ以上の電子制御ユニットに実装された複数のＡＤＡＳアプリケーションとマネージャとを備える、システムであって、
    前記１つ以上の電子制御ユニットは、前記複数のＡＤＡＳアプリケーションが要求する複数の行動計画を前記マネージャに出力する出力部を備え、
    前記マネージャは、
    前記複数のＡＤＡＳアプリケーションから前記複数の行動計画を受け付ける受付部と、
    前記複数の行動計画を調停する調停部と、
    前記調停部による調停結果に基づいて、運動要求を算出する算出部と、
    前記運動要求を少なくとも１つのアクチュエータシステムに分配する分配部と、を備え、
    前記受付部は、前記調停部における調停対象に関する情報を前記ＡＤＡＳアプリケーションから受け付ける、
    システム。
12. 車両に搭載されたマネージャのコンピューターが実行する制御方法であって、
    複数のＡＤＡＳアプリケーションから、行動計画と、前記行動計画の調停処理における調停対象に関する情報とを、それぞれ受け付けるステップと、
    前記受け付けた複数の前記行動計画を調停するステップと、
    前記調停の結果に基づいて、運動要求を算出するステップと、
    前記情報に基づいて、前記運動要求を少なくとも１つのアクチュエータシステムに分配するステップと、を含む、
    制御方法。
13. 車両に搭載されたマネージャのコンピューターに実行させる制御プログラムであって、
    複数のＡＤＡＳアプリケーションから、行動計画と、前記行動計画の調停処理における調停対象に関する情報とを、それぞれ受け付けるステップと、
    前記受け付けた複数の前記行動計画を調停するステップと、
    前記調停の結果に基づいて、運動要求を算出するステップと、
    前記情報に基づいて、前記運動要求を少なくとも１つのアクチュエータシステムに分配するステップと、を含む、
    制御プログラム。
14. 請求項１乃至９のいずれか１項に記載のマネージャを搭載した、車両。

Images