JP2023001152A - 制御システム - Google Patents

Abstract

【課題】複数のアプリケーションからの要求を調停する制御装置等を提供する。【解決手段】車両に搭載された制御装置であって、複数の運転支援アプリケーションから、複数の要求信号を受け付け、複数の運転支援アプリケーションからの要求を調停する要求調停部と、要求調停部による調停結果に基づいて、アクチュエータに対する駆動要求を生成する要求生成部とを備え、要求調停部は、要求調停部が異常でない場合、複数の運転支援アプリケーションに対してアクチュエータの状態情報を出力し、要求調停部が異常である場合、要求調停部が異常であることを表す情報を、アクチュエータを制御する制御部に出力する、制御装置。【選択図】図４

Description

本発明は、制御装置、システム、制御方法及び車両に関する。

特許文献１には、フロントステア、リアステア及びブレーキのそれぞれに設けられたアクチュエータを駆動することにより、車両の横方向の運動を制御する車両横方向運動制御システムが記載されている。特許文献１に記載のシステムでは、各アクチュエータの制御可能範囲を表すアベイラビリティを取得し、取得したアベイラビリティを用いて、各アクチュエータをフィードフォワード制御するためのＦ／Ｆ要求値と、各アクチュエータをフィードバック制御するためのＦ／Ｂ要求値とを算出し、算出したＦ／Ｆ要求値及びＦ／Ｂ要求値に基づいて、制御対象となる機構と当該機構に最終的に発生させる制御量とを決定している。

特開２０１２－９６６１９号公報

近年、車両に実装される運転支援機能の増加に伴って、複数のアプリケーションからの要求に対してアクチュエータが実行する処理が複雑化している。そこで、複数のアプリケーションと複数のアクチュエータとの間で信号の送受信を中継すると共に、複数のアプリケーションからの要求を調停する調停機能部を車両に設け、各アクチュエータの状態を、調停機能部を介して各アプリケーションにフィードバックするシステム構成が考えられる。

本発明は、複数のアプリケーションからの要求を調停する制御装置等を提供することを目的とする。

本発明の一実施態様は、車両に搭載された制御装置であって、複数の運転支援アプリケーションから、複数の要求信号を受け付け、複数の運転支援アプリケーションからの要求を調停する要求調停部と、要求調停部による調停結果に基づいて、アクチュエータに対する駆動要求を生成する要求生成部とを備え、要求調停部は、要求調停部が異常でない場合、複数の運転支援アプリケーションに対してアクチュエータの状態情報を出力し、要求調停部が異常である場合、要求調停部が異常であることを表す情報を、アクチュエータを制御する制御部に出力する。

本発明によれば、複数のアプリケーションからの要求を調停する制御装置等を提供できる。

実施形態に係る車両制御装置の機能ブロック図 図１に示した要求調停部の機能ブロック図 図１に示した制御部の機能ブロック図 図１に示した制御部が実行する制御処理を示すフローチャート

（概要）
本発明に係る車両制御装置は、運転支援機能を実現する複数のアプリケーション実行部と、アクチュエータを制御する制御部との間に、複数のアプリケーション実行部からの要求を調停する要求調停部を備える。アクチュエータを制御する制御部は、要求調停部の正常動作時には、アクチュエータの状態を示す情報を、要求調停部を通じてアプリケーション実行部にフィードバックし、要求調停部の異常時には、アクチュエータの状態を示す情報を直接アプリケーション実行部にフィードバックする。したがって、要求調停部の動作状態にかかわらず、運転支援機能を実現するアプリケーション実行部に対して、アクチュエータの状態を確実にフィードバックすることができる。

（実施形態）
＜構成＞
図１は、実施形態に係る車両制御装置の機能ブロック図である。図１において、実線の矢印は、アプリケーション実行部５からアクチュエータ４までの要求信号の伝達経路を表し、破線の矢印は、アクチュエータ４からアプリケーション実行部５までの信号のフィードバック経路を表す。

車両制御装置１０は、複数のアプリケーション実行部５からの要求に基づいて、車両に備わるアクチュエータ４を制御する装置である。アプリケーション実行部５は、自動運転や自動駐車、アダプティブクルーズコントロール、レーンキープアシスト、衝突軽減ブレーキ等の車両の運転支援機能を実現するアプリケーションを実行する装置であり、典型的には、ＥＣＵによって実現される。利用される運転支援機能に応じて、複数のアプリケーション実行部５が同時にアプリケーションを実行する場合がある。尚、図１においては、説明を簡略化するため、３つのアプリケーション実行部５を示しているが、運転支援機能を実現するアプリケーション実行部の数は限定されず、２以下または４以上のアプリケーション実行部が車両に実装される場合もある。アプリケーション実行部５は、アクチュエータ４を動作させるための要求信号を、後述する要求調停部１に出力する。アクチュエータ４は、パワートレイン（ドライブトレインと呼ばれる場合もある）やブレーキ装置、ステアリング装置等を動作させる駆動機構であり、後述する制御部３によって制御される。

車両制御装置１０は、要求調停部１と、要求生成部２と、制御部３とを備える。

要求調停部１は、複数のアプリケーション実行部５から出力された要求信号を受け付け、所定の選択基準に基づいて、受け付けた複数の要求信号の中から１つの要求信号を選択することにより、複数のアプリケーション実行部５からの要求を調停する。

要求生成部２は、要求調停部１による調停結果、すなわち、要求調停部１によって選択された要求信号に基づいて、アクチュエータ４に対する駆動要求を生成し、生成した駆動要求を制御部３に出力する。

制御部３は、アクチュエータ４を制御するＥＣＵである。図１の例では、１つの制御部３が１つまたは２つのアクチュエータ４を制御しているが、制御部３が制御するアクチュエータの数は３以上であっても良い。

要求調停部１、要求生成部２、制御部３、アクチュエータ４及びアプリケーション実行部５は、通信ネットワークを介して通信可能に接続されており、図１に示すように、アクチュエータ４からアプリケーション実行部５への信号のフィードバック経路として、要求調停部１を経由してアプリケーション実行部５に信号を伝達する第１のフィードバック経路と、要求調停部１を経由せずに直接アプリケーション実行部５に信号を伝達する第２のフィードバック経路とが設けられている。この２種類のフィードバック経路の詳細は後述
する。要求調停部１を介してアクチュエータ４及びアプリケーション実行部５を接続する通信ネットワークと、ダイレクトにアクチュエータ４及びアプリケーション実行部５を接続する通信ネットワークとは同一であっても良いし、異なっていても良い。

尚、図１の例では、車両制御装置１０が３つの要求生成部２と３つの制御部３とを備える例を説明したが、要求生成部２及び制御部３の数はこれに限定されない。

以下、図２及び図３を参照しながら、要求調停部１及び制御部３の詳細な構成を説明する。

図２は、図１に示した要求調停部の機能ブロック図である。

要求調停部１は、調停処理部１１と、状態情報受信部１２と、状態情報出力部１３とを備える。

調停処理部１１は、複数のアプリケーション実行部５からの要求信号を受信し、調停処理、すなわち、受信した複数の要求信号から１つの要求信号を選択する処理を実行する。

状態情報受信部１２は、アクチュエータ４の状態を表す状態情報を制御部３から受信する。状態情報は、アクチュエータ４が正常であるか、または、故障しているかを表す情報であり、アクチュエータ４を制御する制御部３によって取得または生成される。アクチュエータ４が故障している場合は、状態情報は、アクチュエータ４の故障モード、すなわち、アクチュエータ４がどのような故障状態にあるかを表す情報を含む。状態情報にアクチュエータ４の故障モードが含まれていれば、状態情報を受信したアプリケーション実行部５が、故障状態にあるアクチュエータ４に対して指示できる駆動要求と指示できない駆動要求とを切り分けることができる。

状態情報出力部１３は、状態情報受信部１２によって受信された状態情報をアプリケーション実行部５に対して出力することにより、アクチュエータ４の状態のフィードバックを行う。

図３は、図１に示した制御部の機能ブロック図である。

制御部３のそれぞれは、検出部１９と、状態取得部２０と、第１の送信部２１と、第２の送信部２２とを備える。

検出部１９は、要求調停部１が異常であるか否かを検出する。検出部１９による要求調停部１の異常の判定方法は特に限定されず、例えば、要求調停部１が異常であることを表す情報を要求調停部１から受信したことに基づいて異常を判定しても良いし、要求調停部１からの要求信号や応答信号が所定時間検出できないことに基づいて異常を判定しても良いし、要求生成部２から受信した駆動要求が正常でないことに基づいて異常を判定しても良い。

状態取得部２０は、アクチュエータ４の状態を検出し、アクチュエータ４の状態を表す状態情報を生成する。例えば、状態取得部２０は、アクチュエータ４に対して出力した駆動信号に応答してアクチュエータ４から出力される応答信号や、アクチュエータ４またはその近傍に設けられたセンサ類の出力等に基づいて、アクチュエータ４の状態が正常であるか否かを判定し、アクチュエータ４が故障していると判定した場合は、どのような故障状態であるか（故障モード）を特定する。状態取得部２０は、アクチュエータ４の状態の判定結果と特定した故障モードを含む状態情報を生成する。

第１の送信部２１は、状態取得部２０によって生成された状態情報を要求調停部１に送信する。第１の送信部２１によって要求調停部１に送信された状態情報は、要求調停部１の状態情報出力部からアプリケーション実行部５に出力される。第１の送信部２１から要求調停部１を経由してアプリケーション実行部５に状態情報を送信する経路が上述した第１のフィードバック経路に相当する。

第２の送信部２２は、検出部１９によって要求調停部１が異常であると判定された場合、または、アクチュエータ４が特定の故障状態にあると判定された場合に、状態取得部２０によって生成された状態情報を、要求調停部１を介さずに、アプリケーション実行部５に送信する。ここで、アクチュエータ４の特定の故障状態とは、車両を速やかに安全な状態に遷移させることが必要とされる程度の故障が生じている状態をいう。第２の送信部２２から要求調停部１を経由せずに、アプリケーション実行部５に状態情報を送信する経路が上述した第２のフィードバック経路に相当する。

＜制御処理＞
図４は、図１に示した制御部が実行する制御処理を示すフローチャートである。図４の制御処理は、車両の始動スイッチがオンされたことを契機に開始され、車両の動作がオフされるまで繰り返し実行される。

ステップＳ１：検出部１９が、要求調停部１が異常であるか否かを判定する。ステップＳ１の判定がＹＥＳの場合、処理はステップＳ４に進み、それ以外の場合、処理はステップＳ２に進む。

ステップＳ２：状態取得部２０が、アクチュエータ４が故障しているか否かを判定する。ステップＳ２の判定がＹＥＳの場合、処理はステップＳ３に進み、それ以外の場合、処理はステップＳ５に進む。

ステップＳ３：状態取得部２０は、アクチュエータ４が特定の故障状態であるか否かを判定する。ステップＳ３の判定がＹＥＳの場合、処理はステップＳ４に進み、それ以外の場合、処理はステップＳ５に進む。

ステップＳ４：第２の送信部２２が、アクチュエータ４の状態情報をアプリケーション実行部５に直接送信する。その後、処理はステップＳ１に進む。

ステップＳ５：第１の送信部２１が、アクチュエータ４の状態情報を要求調停部１に送信する。その後、処理はステップＳ１に進む。尚、要求調停部１において、状態情報受信部１２が第１の送信部２１から送信された状態情報を受信すると、状態情報出力部１３が受信した状態情報をアプリケーション実行部５に出力する。

＜効果等＞
本実施形態に係る車両制御装置１０には、運転支援機能を実現するために各アクチュエータ４を動作させる複数のアプリケーション実行部５と、アクチュエータ４の制御部３との間に、要求調停部１が設けられている。要求調停部１は、アプリケーション実行部５と制御部３との間の信号の送受信を中継し、複数のアプリケーション実行部５からの要求を調停する機能を有する。要求調停部１を設けることにより、運転支援機能を実現するアプリケーション実行部５の数が増えた場合でも、アクチュエータ４に対する制御干渉を防止し、アプリケーション実行部５とアクチュエータ４との間の信号経路が複雑化することを抑制することができる。

ただし、アプリケーション実行部５とアクチュエータ４との間の全ての信号の送受信を要求調停部１を経由して行う構成において、要求調停部１に故障等の異常が発生した場合、アクチュエータ４の状態情報をアプリケーション実行部５にフィードバックすることができず、制御性が悪化する可能性がある。また、車両を安全な状態に遷移させることが必要とされる程度の故障がアクチュエータ４に発生した場合、速やかに車両を安全な状態に制御できるように、アクチュエータ４の状態情報を遅延なくアプリケーション実行部５に伝達できることが好ましい。これらの技術的課題を解決するために、アクチュエータ４の状態情報を常時アプリケーション実行部５に直接送信することも考えられるが、この場合、車両に搭載された多数のアクチュエータ４からの信号により通信インフラストラクチャへの負荷の増大を招くという問題が生じる。

本実施形態に係る車両制御装置１０においては、通常時は、第１の送信部２１から要求調停部１を介してアプリケーション実行部５にアクチュエータ４の状態情報を送信する。ただし、要求調停部１が異常であると判定された場合、または、アクチュエータ４が特定の故障状態にあると判定された場合には、第２の送信部２２が、要求調停部１を介さずに、アクチュエータ４からアプリケーション実行部５へと直接状態情報を送信する。このように構成することにより、要求調停部１に異常が発生した場合においても、アクチュエータ４の状態情報をアプリケーション実行部５に確実にフィードバックすることができる。また、アクチュエータ４が、速やかに安全な状態に遷移させる必要がある程度の特定の故障状態となった場合、要求調停部１を介さず、アクチュエータ４の状態情報を直接アプリケーション実行部５に送信することにより、信号伝達の遅延を回避することができる。また、アクチュエータ４からアプリケーション実行部５に対して状態情報を直接フィードバックするのは、特定の条件下に限られるため、通信インフラストラクチャへの負荷の増大を最小限に留めることができる。

（その他の変形例）
尚、上記の実施形態においては、アクチュエータ４が特定の故障状態にあることが検出された場合に、第２の送信部２２がアプリケーション実行部５に状態情報を直接フィードバックしているが、要求調停部１が異常でない場合には、通常時と同様に、第１の送信部２１が要求調停部１を経由してアプリケーション実行部５に状態情報をフィードバックしても良い。ただし、上記の実施形態のように、アクチュエータ４が特定の故障状態にあることが検出された場合にも、第２の送信部２２がアプリケーション実行部５に状態情報を直接フィードバックした方が、状態情報の伝達の遅延をより抑制できるので好ましい。

本発明は、運転支援機能が実装された車両を制御するための車両制御装置として利用できる。

１ 要求調停部
２ 要求生成部
３ 制御部
４ アクチュエータ
５ アプリケーション実行部
１０ 車両制御装置
１１ 調停処理部
１２ 状態情報受信部
１３ 状態情報出力部
１９ 検出部
２０ 状態取得部
２１ 第１の送信部
２２ 第２の送信部

本発明は、制御システムに関する。

本発明は、複数のアプリケーションからの要求を調停する制御システムを提供することを目的とする。

本発明の一実施態様は、車両に搭載された制御システムであって、複数の運転支援アプリケーションから複数の要求を受け付け、複数の要求を調停する要求調停部と、要求調停部による調停結果に基づいて、アクチュエータを制御する制御部とを備え、制御部は、要求調停部を介さずに、複数の運転支援アプリケーションに対してアクチュエータの状態情報を出力する。

本発明によれば、複数のアプリケーションからの要求を調停する制御システムを提供できる。

Claims (4)

1. 車両に搭載された制御装置であって、
   複数の運転支援アプリケーションから、複数の要求信号を受け付け、前記複数の運転支援アプリケーションからの要求を調停する要求調停部と、
   前記要求調停部による調停結果に基づいて、アクチュエータに対する駆動要求を生成する要求生成部とを備え、
   前記要求調停部は、前記要求調停部が異常でない場合、前記複数の運転支援アプリケーションに対して前記アクチュエータの状態情報を出力し、前記要求調停部が異常である場合、前記要求調停部が異常であることを表す情報を、アクチュエータを制御する制御部に出力する、制御装置。
2. 車両に搭載された制御装置と、前記車両のアクチュエータを制御する制御部とを備えるシステムであって、
   前記制御装置は、
   複数の運転支援アプリケーションから複数の要求信号を受け付け、前記複数の運転支援アプリケーションからの要求を調停する要求調停部と、
   前記要求調停部による調停結果に基づいて、前記アクチュエータに対する駆動要求を生成する要求生成部とを備え、
   前記要求調停部は、前記要求調停部が異常でない場合、前記複数の運転支援アプリケーションに対して前記アクチュエータの状態情報を出力し、前記要求調停部が異常である場合、前記要求調停部が異常であることを表す情報を、アクチュエータを制御する制御部に出力する、システム。
3. 車両に搭載された電子制御ユニットが実行する制御方法であって、
   複数の運転支援アプリケーションから複数の要求信号を受け付け、前記複数の運転支援アプリケーションからの要求を調停するステップと、
   調停結果に基づいて、アクチュエータに対する駆動要求を生成するステップと、
   前記電子制御ユニットが異常でない場合、前記複数の運転支援アプリケーションに対して前記アクチュエータの状態情報を出力するステップと、
   前記電子制御ユニットが異常である場合、前記電子制御ユニットが異常であることを表す情報を、アクチュエータを制御する制御部に出力するステップと、を含む、制御方法。
4. 請求項１に記載の制御装置を備える、車両。

Images