JP7468584B2

JP7468584B2 - 車両用調停システム

Info

Publication number: JP7468584B2
Application number: JP2022134232A
Authority: JP
Inventors: 和睦東
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2018-10-18
Filing date: 2022-08-25
Publication date: 2024-04-16
Anticipated expiration: 2038-10-18
Also published as: KR20210088486A; JP2022162110A; KR20200043898A; EP3640798B1; CN111071181A; CN117485263A; KR102395759B1; US11570252B2; EP3640798A1; KR20220061067A; US20230097207A1; KR102277368B1; US20200128082A1; JP2020064489A; KR102551126B1; US20240267430A1; US11997166B2; JP7139866B2

Description

本発明は、車両に搭載される調停システムに関する。

近年、車両技術の進展により、自動運転や自動駐車などといった機能（サービス）を実現するアプリケーションの車両への実装が増加している。車両に実装されるアプリケーションが増えると、それに応じて各アプリケーションから各車載機器（アクチュエータ、ＥＣＵなど）に対する制御要求の数も増えて、車両制御が複雑化する。このため、調停装置が、各アプリケーションから発生する複数の要求を調停し、その調停した結果に基づく指示を各車載機器に出力する制御が提案されている。例えば、特許文献１には、車両のボデー系機器を制御するための複数の要求を、処理の実行順に起因する矛盾が生じないように統合的に調停する電子制御装置が開示されている。

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

特許文献１では、車両に標準で実装されている既存アプリケーションの要求も、例えば車両に付加的に実装されている新アプリケーションの要求も、１つの電子制御装置が受け付けて調停を行っている。このため、新アプリケーションが追加実装されるたびに、新アプリケーションで発生する複数の要求に関する調停ルールだけでなく、既存アプリケーションと新アプリケーションとの間で発生する複数の要求に関する調停ルールも全体的に見直さなければならないため、新たなアプリケーションを追加して機能（サービス）を拡張することが容易にできない。

本発明は、上記課題を鑑みてなされたものであり、アプリケーションの追加及び機能（サービス）の拡張を容易に行うことができる、車両用調停システムを提供することを目的とする。

上記課題を解決するために、本発明の一態様は、複数の第１のアプリケーションから１つ以上の第１の要求を受け付け、この受け付けた１つ以上の第１の要求と所定のルールとに基づいて、第２の要求を決定するメインマネージャと、第２の要求と少なくとも１つの第２のアプリケーションから入力される第３の要求とを調停し、この調停された結果に基づいて、所定の車載機器を制御するサブマネージャと、を備え、メインマネージャ及びサブマネージャは、同一のＥＣＵ内に設けられている、車両用調停システムである。

本発明車両用調停システムによれば、アプリケーションの追加及び機能（サービス）の拡張を容易に行うことができる。

本実施形態に係る車両用調停システムを示す機能ブロック図車両用調停システムを具体的に例示した機能ブロック図メインマネージャ、各サブマネージャ、各アプリケーション実行部との関係を例示した図ドアロック制御で用いられる要求及び情報の一例を示す図ドアロック制御で用いられる要求及び情報の一例を示す図ドアロック制御で用いられる要求及び情報の一例を示す図Ｐ／Ｗ制御で用いられる要求及び情報の一例を示す図Ｐ／Ｗ制御で用いられる要求及び情報の一例を示す図Ｐ／Ｗ制御で用いられる要求及び情報の一例を示す図Ｓ／Ｒ制御で用いられる要求及び情報の一例を示す図Ｓ／Ｒ制御で用いられる要求及び情報の一例を示す図Ｓ／Ｒ制御で用いられる要求及び情報の一例を示す図Ｆｒランプ制御で用いられる要求及び情報の一例を示す図Ｆｒランプ制御で用いられる要求及び情報の一例を示す図ターン・ハザード制御で用いられる要求及び情報の一例を示す図ターン・ハザード制御で用いられる要求及び情報の一例を示す図室内イルミ制御で用いられる要求及び情報の一例を示す図室内イルミ制御で用いられる要求及び情報の一例を示す図室内イルミ制御で用いられる要求及び情報の一例を示す図ドラポジ制御で用いられる要求及び情報の一例を示す図ドラポジ制御で用いられる要求及び情報の一例を示す図ドラポジ制御で用いられる要求及び情報の一例を示す図Ｆｒワイパ制御で用いられる要求及び情報の一例を示す図Ｆｒワイパ制御で用いられる要求及び情報の一例を示す図警報制御で用いられる要求及び情報の一例を示す図警報制御で用いられる要求及び情報の一例を示す図ワイヤレスブザー制御で用いられる要求及び情報の一例を示す図ワイヤレスブザー制御で用いられる要求及び情報の一例を示す図メインマネージャが入出力する要求形式の一例を示す図車内外に形成されたエリアの一例を示す図メインマネージャが有するエリア制御対象変換テーブルの一例を示す図メインマネージャが有する点灯要求レベル変換テーブルの一例を示す図メインマネージャが有するフェード曲線変換テーブルの一例を示す図メインマネージャが有する優先度変換テーブルの一例を示す図メインマネージャがサブマネージャからフィードバックされる情報の一例を示す図メインマネージャが実施する処理を説明する図メインマネージャが実施する処理を説明する図手元追っかけ点灯処理に関する制御シーケンスの一例を示す図

＜実施形態＞
本車両用調停システムは、新たな機能（サービス）を実現するアプリケーションからの抽象的な要求を受け付けて、具体化させた要求を決定するメインマネージャと、既存の機能を実現するアプリケーションからの要求とメインマネージャで決定された具体的な要求とを調停するサブマネージャとによる、二段階処理構造を有する。この構造により、新たな機能はメインマネージャ側に追加するだけでよく、機能（サービス）の拡張性が向上する。以下、本発明の一実施形態について、図面を参照しながら詳細に説明する。

［構成］
図１は、本発明の一実施形態に係る車両用調停システム１を示す機能ブロック図である。図１に例示した車両用調停システム１は、複数の第１のアプリケーション実行部１１ａ～１１ｃと、メインマネージャ２１と、複数の第２のアプリケーション実行部２２ａ～２２ｇと、複数のサブマネージャ２３ａ～２３ｄと、複数のＡＣＴ／ＥＣＵ３１ａ～３１ｎと、センサ／スイッチ５１と、他のマネージャ５２と、を備える。

本車両用調停システム１は、一例として、ドアロック、灯火（ランプ）、照明（イルミネーション）、ミラー、シート、及びパワーウインドウなどのボデー系機器（又はアッパー系機器とも言う）について、複数の機器に対する要求を調停することに適用可能である。本実施形態では、ボデー系機器に対する調停を一例に本車両用調停システム１を説明する。

第１のアプリケーション実行部１１ａ～１１ｃは、車両に付加的に実装される機能（サービス）を実現するための装置である。一例として、第１のアプリケーション実行部１１ａ～１１ｃには、運転支援機能を実現するアプリケーションを実行することにより、自動運転、自動駐車、アダプティブクルーズコントロール、レーンキープアシスト、及び衝突軽減ブレーキなどの車両の先進運転支援を実施するための装置を含むことができる。このような装置は、運転支援機能を実現するアプリケーション（図示せず）と共に先進運転支援システムの一部を構成する。また、一例として、第１のアプリケーション実行部１１ａ～１１ｃには、乗員の利便性を向上させるエージェント機能を実現するアプリケーションを実行することにより、音声操作、行動認識操作、連携制御、提案、個人特定、及び先読み運転支援などを実施するための装置を含むことができる。このような装置は、エージェント機能を実現するアプリケーション（図示せず）と共にドライバーサポートシステムの一部を構成する。第１のアプリケーション実行部１１ａ～１１ｃの少なくとも一部（図１の例では、第１のアプリケーション実行部１１ａ）には、車両に搭載される各種のセンサ／スイッチ５１からの情報が入力される。この第１のアプリケーション実行部１１ａ～１１ｃは、典型的には、ＣＰＵなどのプロセッサとメモリとを有する電子制御装置（ＥＣＵ）によって実現される。この第１のアプリケーション実行部１１ａ～１１ｃは、複数のＡＣＴ／ＥＣＵ３１ａ～３１ｎの少なくとも１つを利用するための要求を、そのままではサブマネージャ２３ａ～２３ｄが解釈することができない抽象的な要求の形態でメインマネージャ２１に出力する。このＡＣＴ／ＥＣＵ３１ａ～３１ｎの少なくとも１つを利用するための抽象的な要求については、後述する。

メインマネージャ２１は、第１のアプリケーション実行部１１ａ～１１ｃから１つ以上の要求を受け付け、この受け付けた１つ以上の要求と所定のルールとに基づいて、ＡＣＴ／ＥＣＵ３１ａ～３１ｎを作動させるための要求を決定することができる。メインマネージャ２１は、第１のアプリケーション実行部１１ａ～１１ｃから抽象的な要求を受け付け、この受け付けた抽象的な要求を、対象となるＡＣＴ／ＥＣＵ及びそのＡＣＴ／ＥＣＵの制御内容を特定して具体化する。また、メインマネージャ２１は、複数のサブマネージャ２３ａ～２３ｄから所定の情報を入力し、サブマネージャ２３ａ～２３ｄに関する情報を一元管理する。メインマネージャ２１がサブマネージャ２３ａ～２３ｄから入力する情報は、ＡＣＴ／ＥＣＵの装備の有無、装備するＡＣＴ／ＥＣＵにおける動作受付の可否、ＡＣＴ／ＥＣＵの現在の作動状態を含む。メインマネージャ２１は、サブマネージャから入力される情報及び所定の優先度に基づいて、サブマネージャ２３ａ～２３ｄに出力する具体化された要求を決定する。これにより、メインマネージャ２１は、サブマネージャ２３ａ～２３ｄによって行われるＡＣＴ／ＥＣＵ３１ａ～３１ｎの調停及び／又は制御の内容を考慮して、第１のアプリケーション実行部１１ａ～１１ｃによって提供される複数の機能（サービス）間における要求の処理を実施する。なお、この抽象的な要求を具体化する手法及び優先度については、後述する。

メインマネージャ２１は、決定処理として、例えば、所定のルールに基づいて、受け付けた複数の要求の中から１つの要求を選択したり、受け付けた複数の要求の実施順番を設定したり、要求を拒否したりする。また、メインマネージャ２１は、決定結果を第１のアプリケーション実行部１１ａ～１１ｃに送信する。そして、メインマネージャ２１は、決定処理によって選択した又は順番となった要求を複数のサブマネージャ２３ａ～２３ｄに指示する。具体的には、メインマネージャ２１は、対象のＡＣＴ／ＥＣＵの駆動を制御するサブマネージャに対して、特定された制御内容を指示することを行う。

第２のアプリケーション実行部２２ａ～２２ｇは、元々車両に備えられた既存の機能を実現するための装置である。一例として、第２のアプリケーション実行部２２ａ～２２ｇは、ボデー系機器の制御を実現するアプリケーションを実行することにより、ドアロック、エアコン、照明、ミラー、シート、及びパワーウインドウなどの所定の動作を実現するための装置とすることができる。この第２のアプリケーション実行部２２ａ～２２ｇは、典型的には、ＣＰＵなどのプロセッサとメモリとを有する電子制御装置（ＥＣＵ）によって実現される。第２のアプリケーション実行部２２ａ～２２ｇは、車両に搭載される各種のセンサ／スイッチ５１からの情報に基づいて、複数のＡＣＴ／ＥＣＵ３１ａ～３１ｎの少なくとも１つを利用するための要求を、複数のサブマネージャ２３ａ～２３ｄの少なくとも１つに出力する。センサ／スイッチ５１としては、車載カメラやミリ波レーダなどのセンサ、ドライバーなどから直接指示入力を受け付けるハザードボタンやターン指示レバーなどのスイッチが、例示できる。第２のアプリケーション実行部２２ａ～２２ｇがサブマネージャ２３ａ～２３ｄに出力する要求は、対象のＡＣＴ／ＥＣＵ及びその制御内容の情報を含む。

サブマネージャ２３ａ～２３ｄは、それぞれ、メインマネージャ２１から出力される要求と、第２のアプリケーション実行部２２ａ～２２ｇの少なくとも１つから出力される要求とを入力し、入力された複数の要求を調停することができる。この調停は、サブマネージャが備える機能（サービス）ごとに行われる。サブマネージャには、メインマネージャ２１と第２のアプリケーション実行部との両方から要求が入力される場合がある。例えば、照度センサに基づくヘッドライトの点灯要求と音声認識マイクが集音した「ヘッドライトオフ」に基づく前照灯の消灯要求とが、重なって入力されることが考えられる。サブマネージャは、このような相反する要求が同時に入力された場合、例えば、予め用意された選択基準に基づいていずれか一方の要求を選択する。選択基準は、車両の状態、車両の周囲の状況、アプリケーションのそれぞれに設定された優先度などに基づいて適宜設定することができる。

サブマネージャ２３ａ～２３ｄは、それぞれ、要求を調停して得られた結果に基づいて、複数のＡＣＴ／ＥＣＵ３１ａ～３１ｎの少なくとも１つの動作を制御する。動作の制御としては、例えばＡＣＴであればＯＮ／ＯＦＦ動作の制御や、ＥＣＵであれば制御パラメータ（強度、速度、温度、角度など）の制御が挙げられる。また、サブマネージャ２３ａ～２３ｄは、管理可能なＡＣＴ／ＥＣＵの状態を含む情報をメインマネージャ２１にフィードバック送信する。この情報には、サブマネージャが作動させたＡＣＴ／ＥＣＵの現在の動作状態に加え、サブマネージャが管理可能なＡＣＴ／ＥＣＵの装備の有無、及び装備するＡＣＴ／ＥＣＵにおける動作受付の可否が含まれる。また、この情報には、サブマネージャが実施した調停結果を含んでもよい。

複数のＡＣＴ／ＥＣＵ３１ａ～３１ｎは、車両に搭載されるアクチュエータ（ＡＣＴ）や電子制御装置（ＥＣＵ）などの車載機器である。このＡＣＴ／ＥＣＵ３１ａ～３１ｎは、一例として、ボデー系機器であるドアロック、イルミネーション、及びミラーなどを作動させるためのアクチュエータや、シート、ワイパ、パワーウインドウ（Ｐ／Ｗ）、及びサンルーフ（Ｓ／Ｒ）などを制御するための電子制御装置や、リレー及びモジュールなどである。

他のマネージャ５２は、一例として、車両のナビゲーション画面やメーターなどへの好適な表示やスピーカーやランプなどを用いた通知を制御するＨＭＩ（Human Machine Interface）系のマネージャとすることができる。ＨＭＩ系マネージャでは、メインマネージャ２１からの指示に基づいて、画面表示や音声、ランプによる出力を行うことができる。

なお、上記実施形態では、第１のアプリケーション実行部１１ａ～１１ｃからメインマネージャ２１へ抽象的な要求が送信され、メインマネージャ２１において抽象的な要求を具体化する一例を説明したが、第１のアプリケーション実行部１１ａ～１１ｃからメインマネージャ２１へ具体的な要求が直接送信されてもよい。

［具体的な構成例］
上述した車両用調停システム１の第１のアプリケーション実行部１１ａ～１１ｃ、第２のアプリケーション実行部２２ａ～２２ｇ、サブマネージャ２３ａ～２３ｄ、及びＡＣＴ／ＥＣＵ３１ａ～３１ｎを具体化した一例を、図２に示す。

図２に示す車両用調停システム１では、第１のアプリケーション実行部１１ａ～１１ｃである自動運転サービス、リモート駐車サービス、その他の先進運転支援サービス（ＡＤＡＳ）、及びエージェントサービスの各アプリケーションがそれぞれ出力する競合した要求を、車両アッパーメインマネージャが処理する。この車両アッパーメインマネージャで処理された結果は、蓋物サブマネージャ、灯火サブマネージャ、イルミサブマネージャ、ドラポジサブマネージャ、ワイパサブマネージャ、及び警報サブマネージャのうち、駆動対象のＡＣＴ／ＥＣＵを制御するサブマネージャに対して指示される。また、車両アッパーメインマネージャは、処理した結果を、自動運転サービス、リモート駐車サービス、その他のＡＤＡＳ、及びエージェントの各アプリケーションに返信すると共に、ＨＭＩマネージャに出力する。

蓋物サブマネージャは、窓やドアの開け閉めに関わるドアロックＡＣＴ、電子ラッチ（Ｅラッチ）ＥＣＵ、ドアＥＣＵ、パワーウインドウ（Ｐ／Ｗ）ＥＣＵ、サンルーフ（Ｓ／Ｒ）ＥＣＵ、パワーバックドア（ＰＢＤ）ＥＣＵ、及びパワースライドドア（ＰＳＤ）ＥＣＵを制御するサブマネージャである。灯火サブマネージャは、ライトやウインカーの点灯／消灯に関わるランプＥＣＵ、灯火ＡＣＴ、ターンＡＣＴ、及びクリーナリレーを制御するサブマネージャである。イルミサブマネージャは、室内外イルミネーションの点灯／消灯に関わるイルミモジュール及びイルミＡＣＴを制御するサブマネージャである。ドラポジサブマネージャは、ドライバーの運転姿勢の調整に関わるシートＥＣＵ、ミラーＥＣＵ、チルト＆テレスコピック（チルテレ）ＥＣＵ、及びミラーＡＣＴを制御するサブマネージャである。ワイパサブマネージャは、ワイパやウオッシャの作動に関わるワイパＥＣＵ及びＲｒワイパリレーを制御するサブマネージャである。警報サブマネージャは、クラクションや注意喚起の作動に関わるホーン及び接近通知ＥＣＵを制御するサブマネージャである。

蓋物サブマネージャは、第２のアプリケーション実行部としてドアロック制御のアプリケーション及びワイヤレス・スマート制御のアプリケーションがそれぞれ出力する要求と、車両アッパーメインマネージャから指示される要求とを調停する。この調停は、調停する機能に基づいて、ドアロック機能、Ｐ／Ｗ機能、Ｓ／Ｒ機能、及びドア開閉機能についてそれぞれ実施される。そして、蓋物サブマネージャは、調停結果に基づいて、ドアロックＡＣＴ、ＥラッチＥＣＵ、ドアＥＣＵ、Ｐ／ＷＥＣＵ、Ｓ／ＲＥＣＵ、ＰＢＤＥＣＵ、及びＰＳＤＥＣＵのうちの該当するＡＣＴ／ＥＣＵを制御する。また、蓋物サブマネージャは、調停結果に基づくＡＣＴ／ＥＣＵの制御に関する情報、ドアロックＡＣＴ、ＥラッチＥＣＵ、ドアＥＣＵ、Ｐ／ＷＥＣＵ、Ｓ／ＲＥＣＵ、ＰＢＤＥＣＵ、及びＰＳＤＥＣＵを装備しているという情報、これらのＡＣＴ／ＥＣＵのいずれが動作受け付け可能かに関する情報を、車両アッパーメインマネージャに送信する。

灯火サブマネージャは、第２のアプリケーション実行部として灯火制御のアプリケーション及びターン・ランプ制御のアプリケーションがそれぞれ出力する要求と、車両アッパーメインマネージャから指示される要求とを調停する。この調停は、調停する機能に基づいて、フロント（Ｆｒ）ランプ機能、リア（Ｒｒ）ランプ機能、ターン・ハザード機能、及びクリーナ機能についてそれぞれ実施される。そして、灯火サブマネージャは、調停結果に基づいて、ランプＥＣＵ、灯火ＡＣＴ、ターンＡＣＴ、及びクリーナリレーのうちの該当するＡＣＴ／ＥＣＵを制御する。また、灯火サブマネージャは、調停結果に基づくＡＣＴ／ＥＣＵの制御に関する情報、ランプＥＣＵ、灯火ＡＣＴ、ターンＡＣＴ、及びクリーナリレーを装備しているという情報、これらのＡＣＴ／ＥＣＵのいずれが動作受け付け可能かに関する情報を、車両アッパーメインマネージャに送信する。

イルミサブマネージャは、第２のアプリケーション実行部としてイルミ制御のアプリケーションが出力する要求と、車両アッパーメインマネージャから指示される要求とを調停する。この調停は、調停する機能に基づいて、室内イルミ機能及び室外イルミ機能についてそれぞれ実施される。そして、イルミサブマネージャは、調停結果に基づいて、イルミモジュール及びイルミＡＣＴのうちの該当するＡＣＴ／ＥＣＵを制御する。また、イルミサブマネージャは、調停結果に基づくＡＣＴ／ＥＣＵの制御に関する情報、イルミモジュール及びイルミＡＣＴを装備しているという情報、これらのＡＣＴ／ＥＣＵのいずれが動作受け付け可能かに関する情報を、車両アッパーメインマネージャに送信する。

ドラポジサブマネージャは、第２のアプリケーション実行部としてドラポジ制御のアプリケーション及びミラー制御のアプリケーションがそれぞれ出力する要求と、車両アッパーメインマネージャから指示される要求とを調停する。この調停は、調停する機能に基づいて、シート機能及びミラー機能についてそれぞれ実施される。そして、ドラポジサブマネージャは、調停結果に基づいて、シートＥＣＵ、ミラーＥＣＵ、チルテレＥＣＵ、及びミラーＡＣＴのうちの該当するＡＣＴ／ＥＣＵを制御する。また、ドラポジサブマネージャは、調停結果に基づくＡＣＴ／ＥＣＵの制御に関する情報、シートＥＣＵ、ミラーＥＣＵ、チルテレＥＣＵ、及びミラーＡＣＴを装備しているという情報、これらのＡＣＴ／ＥＣＵのいずれが動作受け付け可能かに関する情報を、車両アッパーメインマネージャに送信する。

ワイパサブマネージャは、第２のアプリケーション実行部としてワイパ制御のアプリケーションが出力する要求と、車両アッパーメインマネージャから指示される要求とを調停する。この調停は、調停する機能に基づいて、フロント（Ｆｒ）ワイパ・ウオッシャ機能及びリア（Ｒｒ）ワイパ・ウオッシャ機能についてそれぞれ実施される。そして、ワイパサブマネージャは、調停結果に基づいて、ワイパＥＣＵ及びＲｒワイパリレーのうちの該当するＡＣＴ／ＥＣＵを制御する。また、ワイパサブマネージャは、調停結果に基づくＡＣＴ／ＥＣＵの制御に関する情報、ワイパＥＣＵ及びＲｒワイパリレーを装備しているという情報、これらのＡＣＴ／ＥＣＵのいずれが動作受け付け可能かに関する情報を、車両アッパーメインマネージャに送信する。

警報サブマネージャは、第２のアプリケーション実行部として警報制御のアプリケーションが出力する要求と、車両アッパーメインマネージャから指示される要求とを調停する。この調停は、調停する機能に基づいて、ホーン機能及び接近通知機能についてそれぞれ実施される。そして、警報サブマネージャは、調停結果に基づいて、ホーン及び接近通知ＥＣＵのうちの該当するＡＣＴ／ＥＣＵを制御する。また、警報サブマネージャは、調停結果に基づくＡＣＴ／ＥＣＵの制御に関する情報、ホーン及び接近通知ＥＣＵを装備しているという情報、これらのＡＣＴ／ＥＣＵのいずれが動作受け付け可能かに関する情報を、車両アッパーメインマネージャに送信する。

図２に示した車両用調停システム１では、メインマネージャと複数のサブマネージャとをボデーＥＣＵ内に設けている。メインマネージャと複数のサブマネージャとを同じＥＣＵ内に設けることで、実装コストを抑えることができる。また、複数のサブマネージャで調停した結果を、車内ネットワークを介さずにボデーＥＣＵ内の信号線を介してメインマネージャに素早くフィードバックできるので、メインマネージャの通信処理の負荷を軽減できる。

［メインマネージャの機能］
図３～図２８をさらに参照して、メインマネージャ２１が備える機能の詳細について説明する。図３は、第１のアプリケーション実行部１１ａ～１１ｃから出力される様々な要求と、メインマネージャ２１内で実施される各種の制御と、サブマネージャ２３ａ～２３ｄと、他のマネージャ５２との関係例を示す図である。図４～図２８は、メインマネージャ２１内で実施される各種の制御について、メインマネージャと、各アプリケーション実行部及びサブマネージャとの間でやり取りされる要求、指示、通知などの一例をそれぞれ示した図である。

図３では、第１のアプリケーション実行部１１ａ～１１ｃとして、自動運転、リモート駐車、バレット駐車、車内機器自動制御（音声認識）、車内機器自動制御（行動認識）、安心降車支援、車内子供見守り（機器操作制限）、車内子供見守り（後席置き忘れ通知）、機器作動予約設定、及び個人設定自動制御の各サービスを例示している。また、メインマネージャ２１で行われる制御として、ドアロック制御、Ｐ／Ｗ制御、Ｓ／Ｒ制御、Ｆｒランプ制御、ターン・ハザード制御、室内イルミ制御、ドラポジ制御、Ｆｒワイパ制御、警報制御、及びワイヤレスブザー制御を例示している。また、サブマネージャ２３ａ～２３ｄで調停される機能として、ドアロック、Ｐ／Ｗ、Ｓ／Ｒ、Ｆｒランプ、ターン・ハザード、室内イルミ、ドライビングポジション（シート、チルテレ、ミラー）、Ｆｒワイパ、ホーン、及びワイヤレスブザーを例示している。また、他のマネージャ５２としてＨＭＩマネージャを例示している。

（１）ドアロック制御
メインマネージャ２１は、安心降車支援、車内子供見守り（機器操作制限）、及びリモート駐車などの各サービスから受け付ける要求に基づいて、ドアロック制御を実施する。図４は、ドアロック制御に関して、メインマネージャ２１が各サービスから受け付けるアプリ要求、及びメインマネージャ２１から各サービスにフィードバックする情報の一例を示す。

メインマネージャ２１は、安心降車支援サービスから、サービスの起動又は停止を要求するアプリ要求（サービスの種類と、起動又は停止とを指示する値を含む）や、運転席（Ｄ席）、助手席（Ｐ席）、後部右席（ＲＲ席）、及び後部左席（ＲＬ席）のそれぞれについてアンラッチの不許可を要求するアプリ要求（不許可要求の有り又は無しを指示する値を含む）を、受け付ける。これに対し、メインマネージャ２１は、Ｄ席、Ｐ席、ＲＲ席、及びＲＬ席それぞれのロック／アンロック状態（ロック又はアンロックを示す値を含む）を、安心降車支援サービスにフィードバックする。フィードバックする情報は、サブマネージャ２３ａ～２３ｄから取得される。

また、メインマネージャ２１は、車内子供見守り（機器操作制限）サービスから、サービスの起動又は停止を要求するアプリ要求（サービスの種類と、起動又は停止とを指示する値を含む）や、Ｄ席、Ｐ席、ＲＲ席、及びＲＬ席のそれぞれについてアンラッチの不許可を要求するアプリ要求（不許可要求の有り又は無しを指示する値を含む）を、受け付ける。これに対し、メインマネージャ２１は、Ｄ席、Ｐ席、ＲＲ席、及びＲＬ席それぞれのロック／アンロック状態（ロック又はアンロックを示す値を含む）を、車内子供見守り（機器操作制限）サービスにフィードバックする。フィードバックする情報は、サブマネージャ２３ａ～２３ｄから取得される。

また、メインマネージャ２１は、リモート駐車サービスから、ドアのロックを要求するアプリ要求（ロック要求の有り又は無しを指示する値を含む）や、ドアのアンロックを要求するアプリ要求（アンロック要求の有り又は無しを指示する値を含む）を、受け付ける。これに対し、メインマネージャ２１は、Ｄ席、Ｐ席、ＲＲ席、及びＲＬ席それぞれのカーテシＳＷの状態（開状態又は閉状態を示す値を含む）を、リモート駐車サービスにフィードバックする。フィードバックする情報は、サブマネージャ２３ａ～２３ｄから取得される。このカーテシＳＷの状態は、リモート駐車の開始条件及び停止条件で使用される。

図４に示すように、メインマネージャ２１は、ドアロック制御に関する異なる複数のサービスから同一のＡＣＴ／ＥＣＵに対する異なる複数の要求を受け付けるが場合がある。例えば、Ｐ席ＥドアロックＡＣＴに対する、安心降車支援サービスからのＰ席アンラッチ不許可無し要求と、車内子供見守り（機器操作制限）サービスからのＰ席アンラッチ不許可有り要求とである。このような場合、メインマネージャ２１は、後述する所定のルールに則って複数の要求を処理し、Ｐ席アンラッチ不許可無し要求及びＰ席アンラッチ不許可有り要求のいずれを採用するかや要求の実行順序などを決定して、決定した要求をサブマネージャ２３ａ～２３ｄへ出力する。

図５は、図３中の（Ａ）に示される、ドアロック制御に関してメインマネージャ２１からサブマネージャ２３ａ～２３ｄ（蓋物サブマネージャ）へ出力される要求、及びサブマネージャ２３ａ～２３ｄからメインマネージャ２１にフィードバックされるＡＣＴ／ＥＣＵの作動状態の一例を示す。

メインマネージャ２１は、制御の結果として、Ｄ席、Ｐ席、ＲＲ席、及びＲＬ席のそれぞれについてアンラッチの不許可要求（不許可要求の有り又は無しを指示する値を含む）や、リモート駐車によるドアロックの要求（ロック要求の有り又は無しを指示する値を含む）や、リモート駐車によるドアアンロックの要求（アンロック要求の有り又は無しを指示する値を含む）を、蓋物サブマネージャへ出力する。一方、メインマネージャ２１は、Ｄ席、Ｐ席、ＲＲ席、及びＲＬ席それぞれのカーテシＳＷの状態（開状態又は閉状態を示す値を含む）や、Ｄ席、Ｐ席、ＲＲ席、及びＲＬ席それぞれのロック／アンロック状態（ロック又はアンロックを示す値を含む）を、蓋物サブマネージャから入力する。

図６は、図３中の（ａ）に示される、メインマネージャ２１が、ドアロック制御に関して、安心降車支援サービスから受け付ける、ＨＭＩマネージャに対する要求の一例を示す。メインマネージャ２１は、安心降車支援サービスから、マルチインフォメーションディスプレイ（ＭＩＤ）の表示を要求するアプリ要求（表示内容の指示を含む）や、車内ブザーの吹鳴を要求するアプリ要求（ブザー吹鳴の指示を含む）や、画面表示を要求するアプリ要求（表示内容の指示を含む）や、音声発話を要求するアプリ要求（発話内容の指示を含む）を受け付け、ＨＭＩマネージャに出力する。

このように、メインマネージャ２１は、安心降車支援、車内子供見守り（機器操作制限）、及びリモート駐車などのサービスから個別に受け付けるドアロックに関する要求を、サブマネージャ２３ａ～２３ｄ（蓋物サブマネージャ）からのフィードバック情報に基づいて、適切に制御することができる。

（２）Ｐ／Ｗ制御
メインマネージャ２１は、車内機器自動制御（音声認識）、機器作動予約設定、及び車内子供見守り（機器操作制限）などの各サービスから受け付ける要求に基づいて、Ｐ／Ｗ制御を実施する。図７は、Ｐ／Ｗ制御に関して、メインマネージャ２１が各サービスから受け付けるアプリ要求、及びメインマネージャ２１から各サービスにフィードバックする情報の一例を示す。

メインマネージャ２１は、車内機器自動制御（音声認識）サービスから、サービスの起動又は停止を要求するアプリ要求（サービスの種類と、起動又は停止とを指示する値を含む）や、音声操作によるＰ／Ｗの操作を要求するアプリ要求（場所、開状態又は閉状態又は停止状態を指示する値を含む）を、受け付ける。これに対し、メインマネージャ２１は、Ｐ／Ｗの作動可否（許可又は不許可を示す値を含む）や、Ｐ／Ｗの作動状態（開始又は却下又は停止又は終了を示す値を含む）を、車内機器自動制御（音声認識）サービスにフィードバックする。フィードバックする情報は、サブマネージャ２３ａ～２３ｄから取得される。

また、メインマネージャ２１は、機器作動予約設定サービスから、サービスの起動又は停止を要求するアプリ要求（サービスの種類と、起動又は停止とを指示する値を含む）や、作動予約によるＰ／Ｗの制御を要求するアプリ要求（場所、開状態又は閉状態又は停止状態を指示する値を含む）を、受け付ける。これに対し、メインマネージャ２１は、Ｐ／Ｗの作動可否（許可又は不許可を示す値を含む）や、Ｐ／Ｗの作動状態（開始又は却下又は停止又は終了を示す値を含む）を、機器作動予約設定サービスにフィードバックする。フィードバックする情報は、サブマネージャ２３ａ～２３ｄから取得される。

また、メインマネージャ２１は、車内子供見守り（機器操作制限）サービスから、子供の乗車時における機器操作の制限としてＰ／Ｗの不作動を要求するアプリ要求（不作動要求の有り又は無しを指示する値を含む）を、受け付ける。

図７に示すように、メインマネージャ２１は、Ｐ／Ｗ制御に関する異なる複数のサービスから同一のＡＣＴ／ＥＣＵに対する異なる複数の要求を受け付けるが場合がある。例えば、Ｐ／ＷＥＣＵに対する、車内機器自動制御（音声認識）サービスからのＰ／Ｗ開要求と、機器作動予約設定サービスからのＰ／Ｗ閉要求とである。このような場合、メインマネージャ２１は、後述する所定のルールに則って複数の要求を処理し、Ｐ／Ｗ開要求及びＰ／Ｗ閉要求のいずれを採用するかや要求の実行順序などを決定して、決定した要求をサブマネージャ２３ａ～２３ｄへ出力する。

図８は、図３中の（Ｂ）に示される、Ｐ／Ｗ制御に関してメインマネージャ２１からサブマネージャ２３ａ～２３ｄ（蓋物サブマネージャ）へ出力される要求、及びサブマネージャ２３ａ～２３ｄからメインマネージャ２１にフィードバックされるＡＣＴ／ＥＣＵの作動状態の一例を示す。

メインマネージャ２１は、制御の結果として、Ｐ／Ｗの作動要求（場所、開状態又は閉状態又は停止状態を指示する値を含む）や、Ｐ／Ｗの許可信号要求（ＯＮ又はＯＦＦを指示する値を含む）を、蓋物サブマネージャへ出力する。一方、メインマネージャ２１は、Ｐ／Ｗの作動状態（作動又は反転又は停止を示す値を含む）や、Ｐ／Ｗの位置情報（全開位置又は途中の位置又は全閉位置を示す値を含む）を、蓋物サブマネージャから入力する。

図９は、図３中の（ｂ）に示される、メインマネージャ２１が、Ｐ／Ｗ制御に関して、車内子供見守り（機器操作制限）サービスなどから受け付ける、ＨＭＩマネージャに対する要求の一例を示す。メインマネージャ２１は、車内子供見守り（機器操作制限）サービスから、音声による通知を要求するアプリ要求（通知内容の指示を含む）や、画面表示を要求するアプリ要求（表示内容の指示を含む）を受け付け、ＨＭＩマネージャに出力する。また、メインマネージャ２１は、Ｐ／Ｗの緊急停止スイッチが押されたという情報を取得すると、緊急停止スイッチがＯＮされたというスイッチ情報をＨＭＩマネージャに出力したり、Ｐ／Ｗの作動状態の表示（例えば、作動中の表示と緊急スイッチの表示）に関する要求を受け付けると、表示をＯＮ又はＯＦＦする指示を含む要求をＨＭＩマネージャに出力したりする。

このように、メインマネージャ２１は、車内機器自動制御（音声認識）、機器作動予約設定、及び車内子供見守り（機器操作制限）などのサービスから個別に受け付けるＰ／Ｗに関する要求を、サブマネージャ２３ａ～２３ｄ（蓋物サブマネージャ）からのフィードバック情報に基づいて、適切に制御することができる。

（３）Ｓ／Ｒ制御
メインマネージャ２１は、車内機器自動制御（音声認識）及び機器作動予約設定などの各サービスから受け付ける要求に基づいて、Ｓ／Ｒ制御を実施する。図１０は、Ｓ／Ｒ制御に関して、メインマネージャ２１が各サービスから受け付けるアプリ要求、及びメインマネージャ２１から各サービスにフィードバックする情報の一例を示す。

メインマネージャ２１は、車内機器自動制御（音声認識）サービスから、サービスの起動又は停止を要求するアプリ要求（サービスの種類と、起動又は停止とを指示する値を含む）や、音声操作によるＳ／Ｒの操作を要求するアプリ要求（開状態又は閉状態又は停止状態を指示する値を含む）を、受け付ける。これに対し、メインマネージャ２１は、Ｓ／Ｒの作動可否（許可又は不許可を示す値を含む）や、Ｓ／Ｒの作動状態（開始又は却下又は停止又は終了と、位置とを示す値を含む）を、車内機器自動制御（音声認識）サービスにフィードバックする。フィードバックする情報は、サブマネージャ２３ａ～２３ｄから取得される。

また、メインマネージャ２１は、機器作動予約設定サービスから、サービスの起動又は停止を要求するアプリ要求（サービスの種類と、起動又は停止とを指示する値を含む）や、作動予約によるＳ／Ｒの制御を要求するアプリ要求（開状態又は閉状態又は停止状態を指示する値を含む）を、受け付ける。これに対し、メインマネージャ２１は、Ｓ／Ｒの作動可否（許可又は不許可を示す値を含む）や、Ｓ／Ｒの作動状態（開始又は却下又は停止又は終了と、位置とを示す値を含む）を、機器作動予約設定サービスにフィードバックする。フィードバックする情報は、サブマネージャ２３ａ～２３ｄから取得される。

図１０に示すように、メインマネージャ２１は、Ｓ／Ｒ制御に関する異なる複数のサービスから同一のＡＣＴ／ＥＣＵに対する異なる複数の要求を受け付けるが場合がある。例えば、Ｓ／ＲＥＣＵに対する、車内機器自動制御（音声認識）サービスからのＳ／Ｒ停止要求と、機器作動予約設定サービスからのＳ／Ｒ開要求とである。このような場合、メインマネージャ２１は、後述する所定のルールに則って複数の要求を処理し、Ｓ／Ｒ停止要求及びＳ／Ｒ開要求のいずれを採用するかや要求の実行順序などを決定して、決定した要求をサブマネージャ２３ａ～２３ｄへ出力する。

図１１は、図３中の（Ｃ）に示される、Ｓ／Ｒ制御に関してメインマネージャ２１からサブマネージャ２３ａ～２３ｄ（蓋物サブマネージャ）へ出力される要求、及びサブマネージャ２３ａ～２３ｄからメインマネージャ２１にフィードバックされるＡＣＴ／ＥＣＵの作動状態の一例を示す。

メインマネージャ２１は、制御の結果として、Ｓ／Ｒの作動要求（開状態又は閉状態又は停止状態を指示する値を含む）を、蓋物サブマネージャへ出力する。一方、メインマネージャ２１は、Ｓ／Ｒの作動状態（作動又は反転又は停止を示す値を含む）や、Ｓ／Ｒの位置情報（全開位置又は途中の位置又は全閉位置を示す値を含む）を、蓋物サブマネージャから入力する。

図１２は、図３中の（ｃ）に示される、メインマネージャ２１が、Ｓ／Ｒ制御に関してＨＭＩマネージャに要求する内容の一例を示す。メインマネージャ２１は、Ｓ／Ｒの緊急停止スイッチが押されたという情報を取得すると、緊急停止スイッチがＯＮされたというスイッチ情報をＨＭＩマネージャに出力したり、Ｓ／Ｒの作動状態の表示（例えば、作動中の表示と緊急スイッチの表示）に関する要求を受け付けると、表示をＯＮ又はＯＦＦする指示を含む要求をＨＭＩマネージャに出力したりする。

このように、メインマネージャ２１は、車内機器自動制御（音声認識）及び機器作動予約設定などのサービスから個別に受け付けるＳ／Ｒに関する要求を、サブマネージャ２３ａ～２３ｄ（蓋物サブマネージャ）からのフィードバック情報に基づいて、適切に制御することができる。

（４）Ｆｒランプ制御
メインマネージャ２１は、リモート駐車及び自動運転などの各サービスから受け付ける要求、指示、通知などに基づいて、Ｆｒランプ制御を実施する。図１３は、Ｆｒランプ制御に関して、メインマネージャ２１が各サービスから受け付ける要求、指示、通知、及びメインマネージャ２１から各サービスにフィードバックする情報の一例を示す。

メインマネージャ２１は、リモート駐車サービスから、出庫時における、前進後退制御の起動指示や、前進後退制御起動の通知や、前進後退制御による出庫完了の通知を、受け付ける。また、メインマネージャ２１は、リモート駐車サービスから、入庫時における、前進後退制御の起動指示や、前進後退制御起動条件の確認通知や、前進後退制御の起動通知、前進後退制御による入庫完了の通知を、受け付ける。各指示や通知は、ＯＦＦ又はＯＮの値を含む。また、メインマネージャ２１は、リモート駐車サービスからリモート駐車の状態を受け付ける。これに対し、メインマネージャ２１は、入庫時における、前進後退制御の起動完了通知や、前進後退制御においてドライバーの降車が完了したことの通知や、前進後退制御の起動条件応答通知や、前進後退制御の起動応答通知や、前進後退制御による入庫完了の応答通知を、リモート駐車サービスにフィードバックする。各通知は、ＯＦＦ又はＯＮの値を含む。フィードバックする情報は、サブマネージャ２３ａ～２３ｄから取得される。

また、メインマネージャ２１は、自動運転サービスから、自動運転によるオートライトの設定を要求するアプリ要求（起動又は待機又は終了を指示する値を含む）を受け付ける。また、メインマネージャ２１は、所定の車両システムへリモート駐車の予約スイッチがオフされた通知を送信する。

図１４は、図３中の（Ｄ）に示される、Ｆｒランプ制御に関してメインマネージャ２１からサブマネージャ２３ａ～２３ｄ（灯火サブマネージャ）へ出力される要求及び通知の一例を示す。

メインマネージャ２１は、制御の結果として、ヘッドライトの点灯又は消灯に関する要求（点灯又は消灯を指示する値を含む）や、既存のライトアプリに対するオートライトの要求（ＯＦＦ又はＯＮの値を含む）を、灯火サブマネージャへ出力する。また、自動運転モードであるか否かの状態（ＯＦＦ又はＯＮの値を含む）を灯火サブマネージャへ通知する。

このように、メインマネージャ２１は、リモート駐車及び自動運転などのサービスから個別に受け付けるＦｒランプに関する要求を、サブマネージャ２３ａ～２３ｄ（灯火サブマネージャ）からのフィードバック情報に基づいて、適切に制御することができる。

（５）ターン・ハザード制御
メインマネージャ２１は、リモート駐車、自動運転、及び車内子供見守り（後席置き忘れ通知）などの各サービスから受け付ける要求、指示、通知などに基づいて、Ｆｒランプ制御を実施する。図１５は、ターン・ハザード制御に関して、メインマネージャ２１が各サービスから受け付ける要求、指示、通知、及びメインマネージャ２１から各サービスにフィードバックする情報の一例を示す。

また、メインマネージャ２１は、自動運転サービスから、自動運転による車線変更時の左右ターンランプの点滅を要求するアプリ要求や、自動運転による右左折時の左右ターンランプの点滅を要求するアプリ要求を、受け付ける。各要求は、ＯＦＦ又はＯＮの値を含む。また、メインマネージャ２１は、車内子供見守り（後席置き忘れ通知）サービスから、車両後席への子供などの置き忘れを防止するためにハザードの点滅を要求するアプリ要求（ＯＦＦ又はＯＮの値を含む）を、受け付ける。また、メインマネージャ２１は、所定の車両システムへリモート駐車の予約スイッチがオフされた通知を送信する。

図１６は、図３中の（Ｅ）に示される、ターン・ハザード制御に関してメインマネージャ２１からサブマネージャ２３ａ～２３ｄ（灯火サブマネージャ）へ出力される要求及び通知の一例を示す。

メインマネージャ２１は、制御の結果として、フラッシャの点滅に関する要求（無し又はハザード点滅を指示する値を含む）や、車線変更に伴う左右のターンランプ点滅の要求（無し又は右をＸ回点滅又は左をＸ回点滅を指示する値を含む）や、右左折に伴う左右のターンランプ点滅の要求（無し又は右ターン点滅又は左ターン点滅を指示する値を含む）を、灯火サブマネージャへ出力する。

このように、メインマネージャ２１は、リモート駐車、自動運転、及び車内子供見守り（後席置き忘れ通知）などのサービスから個別に受け付けるターン・ハザードに関する要求を、サブマネージャ２３ａ～２３ｄ（灯火サブマネージャ）からのフィードバック情報に基づいて、適切に制御することができる。

（６）室内イルミ制御
メインマネージャ２１は、車内機器自動制御（音声認識）及び車内機器自動制御（行動認識）などの各サービスから受け付ける要求に基づいて、室内イルミ制御を実施する。図１７は、室内イルミ制御に関して、メインマネージャ２１が各サービスから受け付けるアプリ要求の一例を示す。

メインマネージャ２１は、車内機器自動制御（音声認識）サービスから、サービスの起動又は停止を要求するアプリ要求（サービスの種類と、起動又は停止とを指示する値を含む）や、イルミの点灯又は消灯を要求するアプリ要求（エリア、点灯状態又は切り替え状態又は消灯状態を指示する値を含む）を、受け付ける。また、メインマネージャ２１は、車内機器自動制御（行動認識）サービスから、サービスの起動又は停止を要求するアプリ要求（サービスの種類と、起動又は停止とを指示する値を含む）や、イルミの点灯又は消灯を要求するアプリ要求（エリア、点灯状態又は切り替え状態又は消灯状態を指示する値を含む）を、受け付ける。

図１７に示すように、メインマネージャ２１は、室内イルミ制御に関する異なる複数のサービスから同一のＡＣＴ／ＥＣＵに対する異なる複数の要求を受け付けるが場合がある。例えば、Ｓ／ＲＥＣＵに対する、車内機器自動制御（音声認識）サービスからのイルミ点灯要求と、車内機器自動制御（行動認識）サービスからのイルミ消灯要求とである。このような場合、メインマネージャ２１は、後述する所定のルールに則って複数の要求を処理し、イルミ点灯要求及びイルミ消灯要求のいずれを採用するかや要求の実行順序などを決定して、決定した要求をサブマネージャ２３ａ～２３ｄへ出力する。

図１８は、図３中の（Ｆ）に示される、室内イルミ制御に関してメインマネージャ２１からサブマネージャ２３ａ～２３ｄ（イルミサブマネージャ）へ出力される要求、及びサブマネージャ２３ａ～２３ｄからメインマネージャ２１にフィードバックされるＡＣＴ／ＥＣＵの作動状態の一例を示す。

メインマネージャ２１は、制御の結果として、室内イルミの点灯又は消灯の要求（有り又は無し、対象、到達輝度、制御パターン、及び時間を指示する値を含む）を、イルミサブマネージャへ出力する。一方、メインマネージャ２１は、室内イルミの点灯又は消灯の状態（ＯＫ又はＮＧを示す値を含む）を、イルミサブマネージャから入力する。

図１９は、図３中の（ｄ）に示される、メインマネージャ２１が、室内イルミ制御に関して、ＨＭＩマネージャに要求する内容の一例を示す。メインマネージャ２１は、イルミの点灯状態を画面に表示させる（ＯＮ）又は表示させない（ＯＦＦ）という要求をＨＭＩマネージャに出力したり、画面表示停止の要求をＨＭＩマネージャに出力したりする。

このように、メインマネージャ２１は、車内機器自動制御（音声認識）及び車内機器自動制御（行動認識）などのサービスから個別に受け付ける室内イルミに関する要求を、サブマネージャ２３ａ～２３ｄ（イルミサブマネージャ）からのフィードバック情報に基づいて、適切に制御することができる。

（７）ドラポジ制御
メインマネージャ２１は、個人設定自動制御、リモート駐車、自動駐車、及び車内子供見守り（機器操作制限）などの各サービスから受け付ける要求に基づいて、ドラポジ制御を実施する。図２０は、ドラポジ制御に関して、メインマネージャ２１が各サービスから受け付けるアプリ要求、及びメインマネージャ２１から各サービスにフィードバックする情報の一例を示す。

メインマネージャ２１は、個人設定自動制御サービスから、各個人に予め設定済みのドライビングポジション（ドラポジ）の設定値を要求するアプリ要求（シート、チルテレ、ミラーの設定値を含む）や、乗車前におけるドライビングポジションの自動調整の開始を要求するアプリ要求（開始要求の有り又は無しを指示する値を含む）や、乗車後におけるドライビングポジションの自動調整の開始を要求するアプリ要求（開始要求の有り又は無しを指示する値を含む）や、自動運転と手動運転を切り替え時におけるドライビングポジションの自動調整の開始を要求するアプリ要求（開始要求の有り又は無しを指示する値を含む）を、受け付ける。これに対し、メインマネージャ２１は、個人設定されたドライビングポジションの自動調整（再生）の終了したこと、及びドライビングポジションの位置情報（シート、チルテレ、ミラー）を、個人設定自動制御サービスにフィードバックする。フィードバックする情報は、サブマネージャ２３ａ～２３ｄから取得される。

また、メインマネージャ２１は、リモート駐車サービスから、リモート駐車時における制御モード（リモート駐車の開始又は終了）の設定を要求するアプリ要求や、シート制御モード（リラックスモード、シートフルフラットモードなど）の設定を要求するアプリ要求を、受け付ける。また、メインマネージャ２１は、自動運転サービスから、自動運転時における制御モード（リモート駐車の開始又は終了）の設定を要求するアプリ要求や、シート制御モード（リラックスモード、シートフルフラットモードなど）の設定を要求するアプリ要求を、受け付ける。また、メインマネージャ２１は、車内子供見守り（機器操作制限）サービスから、シートの作動禁止を要求するアプリ要求（シートの種類と、要求有り又は要求無しを指示する値を含む）を、受け付ける。

図２０に示すように、メインマネージャ２１は、ドラポジ制御に関する異なる複数のサービスから同一のＡＣＴ／ＥＣＵに対する異なる複数の要求を受け付けるが場合がある。例えば、シートＥＣＵに対する、リモート駐車サービスからのシート制御モード（リラックスモード）設定要求と、自動運転サービスからのシート制御モード（シートフルフラットモード）設定要求とである。このような場合、メインマネージャ２１は、後述する所定のルールに則って複数の要求を処理し、シート制御モード（リラックスモード）設定要求及びシート制御モード（シートフルフラットモード）設定要求のいずれを採用するかや要求の実行順序などを決定して、決定した要求をサブマネージャ２３ａ～２３ｄへ出力する。

図２１は、図３中の（Ｇ）に示される、ドラポジ制御に関してメインマネージャ２１からサブマネージャ２３ａ～２３ｄ（ドラポジサブマネージャ）へ出力される要求、及びサブマネージャ２３ａ～２３ｄからメインマネージャ２１にフィードバックされるＡＣＴ／ＥＣＵの作動状態の一例を示す。

メインマネージャ２１は、制御の結果として、ドラポジの設定値（シート、チルテレ、ミラー）の要求、ドラポジ自動調整の開始要求（開始要求の有り又は無しを指示する値を含む）、ドラポジ自動調整の停止要求（停止要求の有り又は無しを指示する値を含む）、ドラポジ位置の記憶要求（記憶要求の有り又は無しを指示する値を含む）、自動運転時のシート制御モード（ＯＮ又はＯＦＦの指示値）の設定要求、サイドミラーの格納又は展開の要求、シート制御モード（リラックスモード、シートフルフラットモード、サポートなど）の設定要求、シート作動の禁止要求、ニューマチックリフレッシュ要求を、ドラポジサブマネージャへ出力する。一方、メインマネージャ２１は、ドラポジの再生が終了したことの通知をドラポジサブマネージャから入力する。

図２２は、図３中の（ｅ）に示される、メインマネージャ２１が、ドラポジ制御に関して、車内子供見守り（機器操作制限）サービスなどから受け付ける、ＨＭＩマネージャに対する要求の一例を示す。メインマネージャ２１は、車内子供見守り（機器操作制限）サービスから、音声による通知を要求するアプリ要求（通知内容の指示を含む）や、画面表示を要求するアプリ要求（表示内容の指示を含む）を受け付け、ＨＭＩマネージャに出力する。また、メインマネージャ２１は、ドラポジの緊急停止スイッチが押されたという情報を取得すると、緊急停止スイッチがＯＮされたというスイッチ情報をＨＭＩマネージャに出力する。

このように、メインマネージャ２１は、個人設定自動制御、リモート駐車、自動駐車、及び車内子供見守り（機器操作制限）などのサービスから個別に受け付けるドライビングポジションに関する要求を、サブマネージャ２３ａ～２３ｄ（ドラポジサブマネージャ）からのフィードバック情報に基づいて、適切に制御することができる。

（８）Ｆｒワイパ制御
メインマネージャ２１は、リモート駐車及び自動運転などの各サービスから受け付ける要求、指示、通知などに基づいて、Ｆｒワイパ制御を実施する。図２３は、Ｆｒワイパ制御に関して、メインマネージャ２１が各サービスから受け付ける要求、指示、通知、及びメインマネージャ２１から各サービスにフィードバックする情報の一例を示す。

また、メインマネージャ２１は、自動運転サービスから、自動運転によるオートワイパの設定を要求するアプリ要求（起動又は待機又は終了を指示する値を含む）を受け付ける。また、メインマネージャ２１は、所定の車両システムへリモート駐車の予約スイッチがオフされた通知を送信する。

図２４は、図３中の（Ｈ）に示される、Ｆｒワイパ制御に関してメインマネージャ２１からサブマネージャ２３ａ～２３ｄ（ワイパサブマネージャ）へ出力される要求及び通知の一例を示す。

メインマネージャ２１は、制御の結果として、既存のワイパアプリに対するオートワイパの要求（ＯＦＦ又はＯＮの値を含む）を、ワイパサブマネージャへ出力する。また、自動運転状態であるか否かの状態（自動運転モード）をワイパサブマネージャへ通知する。

このように、メインマネージャ２１は、リモート駐車及び自動運転などのサービスから個別に受け付けるＦｒワイパに関する要求を、サブマネージャ２３ａ～２３ｄ（ワイパサブマネージャ）からのフィードバック情報に基づいて、適切に制御することができる。

（９）警報制御
メインマネージャ２１は、自動運転サービスから受け付ける要求に基づいて、警報制御を実施する。図２５は、警報制御に関して、メインマネージャ２１がサービスから受け付ける要求の一例を示す。

メインマネージャ２１は、自動運転サービスから、自動運転においてドライバーが死亡や意識不明などの事態に陥ったこと、又はドライバーが不用意に運転位置を離れたことを検出（デッドマン検出）したときにホーンの吹鳴を要求するアプリ要求（要求の有り／無しを指示する値を含む）を、受け付ける。

図２６は、図３中の（Ｉ）に示される、警報制御に関してメインマネージャ２１からサブマネージャ２３ａ～２３ｄ（警報サブマネージャ）へ出力される要求の一例を示す。メインマネージャ２１は、制御の結果として、ホーンの吹鳴を要求又は停止する要求を、警報サブマネージャへ出力する。

このように、メインマネージャ２１は、自動運転サービスから受け付けるホーンに関する要求を適切に制御することができる。

（１０）ワイヤレスブザー制御
メインマネージャ２１は、車内子供見守り（後席置き忘れ通知）サービスから受け付ける要求に基づいて、ワイヤレスブザー制御を実施する。図２７は、ワイヤレスブザー制御に関して、メインマネージャ２１がサービスから受け付ける要求の一例を示す。

メインマネージャ２１は、車内子供見守り（後席置き忘れ通知）サービスから、後席に子供などを置き忘れたことを検出したときにワイヤレスブザーの吹鳴を要求するアプリ要求（要求有り／無しを指示する値を含む）を受け付ける。

図２８は、図３中の（Ｊ）に示される、ワイヤレスブザー制御に関してメインマネージャ２１からサブマネージャ２３ａ～２３ｄ（警報サブマネージャ）へ出力される要求の一例を示す。メインマネージャ２１は、制御の結果として、ワイヤレスブザーの吹鳴の要求（要求の有り／無しを指示する値を含む）を、警報サブマネージャへ出力する。

このように、メインマネージャ２１は、自動運転サービスから受け付けるワイヤレスブザーに関する要求を適切に制御することができる。

［具体的な制御処理の一例］
図２９～図３７を用いて、手元追っかけ点灯機能を一例に挙げて、メインマネージャ２１で行われる制御処理を説明する。

メインマネージャ２１は、車内機器自動制御（行動認識）サービスなどのアプリケーションから、例えば図２９の左表に示した、手元追っかけ点灯機能に関わる抽象的なイルミネーション点灯要求を受け付ける。このイルミネーション点灯要求では、手元追っかけ点灯機能を特定するサービスＩＤとして「０００１ｂ：手元追っかけ」が指定され、また図３０に示すように区分された車内外における各エリアＡ～Ｌにおける照明の具合について、例えば照明を点灯させない「０００ｂ：点灯要求無し」、照明の暗い点灯を要求する「００１ｂ：暗く照らす」、及び照明の明るい点灯を要求する「１０１ｂ：明るく照らす」のいずれかが指定される。そして、メインマネージャ２１は、この抽象的なイルミネーション点灯要求を、例えば図２９の右表に示したサブマネージャ向けの具体化した要求に変換する。この具体化する手順を以下に説明する。

まず、メインマネージャ２１は、図３１に例示するエリアを制御対象となる照明機器に変換するテーブルを用いて、イルミネーション点灯要求に示されるエリアを制御可能な照明機器に変換する。図３１の例では、エリアＡではＦｒドーム及びＦＬ席マップランプが該当し、エリアＢではＲｒドーム及びＲＬ席マップランプが該当し、エリアＤではＦｒドーム及びＦＲ席マップランプが該当し、エリアＪではアウトサイドハンドル照明が該当し、エリアＫ及びＬには該当する照明機器がないことを示している。

次に、メインマネージャ２１は、図３２に例示する抽象的な点灯要求を照明機器の具体的な輝度レベルに変換するテーブルを用いて、イルミネーション点灯要求に示される照明の具合を具体化する。より詳細には、メインマネージャ２１は、受け付けたイルミネーション点灯要求に基づいて、その要求を実現するための照明機器（ＦｒドームやＦＬ席マップランプなど）の制御量を表すレベルを特定する。図３２の例では、アプリケーションから受け付けた「０００ｂ：点灯要求無し」をサブマネージャ向けの「０００ｂ：要求無し」に変換してレベルを特定し、アプリケーションから受け付けた「００１ｂ：暗く照らす」をサブマネージャ向けの「０１０ｂ：点灯（輝度レベル２）」に変換してレベルを特定し、アプリケーションから受け付けた「１０１ｂ：明るく照らす」をサブマネージャ向けの「１００ｂ：点灯（輝度レベル４）」に変換してレベルを特定することを示している。この輝度レベルは、点灯要求の付加情報であり、一例として、輝度が最も高い場合に「４」を輝度が最も低い場合に「１」を設定することができる。

また、メインマネージャ２１は、図３３に例示する抽象的な点灯要求を照明機器のフェード機能に変換するテーブルを用いて、イルミネーション点灯要求に示される照明の具合をさらに具体化する。このフェード曲線変換テーブルでは、サービスごとに最適な点け方が予め定義されている。図３３の例では、アプリケーションから受け付けた「００００ｂ：手元照らして」をサブマネージャ向けの「００ｂ：普通」に変換し、アプリケーションから受け付けた「０００１ｂ：手元追っかけ」をサブマネージャ向けの「０１ｂ：ゆっくり」に変換し、アプリケーションから受け付けた「００１０ｂ：ここ照らして」をサブマネージャ向けの「１０ｂ：早め」に変換することを示している。

さらに、メインマネージャ２１は、図３４に例示する抽象的な点灯要求の優先度を決定するテーブルを用いて、イルミネーション点灯要求の優先度を特定する。図３４の例では、アプリケーションから受け付けた「００００ｂ：手元照らして」、「０００１ｂ：手元追っかけ」、「００１０ｂ：ここ照らして」のいずれにも、「０ｂ：普通（優先度３）」の優先度が設定されていることを示している。この優先度は、サービスＩＤごとに、メインマネージャ２１が設定することができる。例えば、最も高い優先度を「１」に、最も低い優先度を「５」に、設定することができる。なお、１つのサービスＩＤに対応する優先度は、複数設定されてもよく、競合する要求に応じて優先度を使い分けてもよい。

上述したエリア制御対象変換テーブル（図３１）、点灯要求レベル変換テーブル（図３２）、フェード曲線変換テーブル（図３３）、及び優先度変換テーブル（図３４）を用いて、図２９の左表に示した手元追っかけ点灯機能に関わる抽象的なイルミネーション点灯要求が、図２９の右表に示した具体化したイルミサブマネージャ向けの要求に変換される。

次に、メインマネージャ２１は、具体化したサブマネージャ向けの要求についてイルミサブマネージャに出力する要求を決定する制御を実施する。決定に先立ち、メインマネージャ２１は、イルミサブマネージャからフィードバックされるＡＣＴ／ＥＣＵに関する装備情報及び動作受け付け可能か否かの状態に基づいて、図３５の表に示すような制御対象となるエリア又は照明機器ごとに装備の有無及び受付可否を把握することを行う。図３５の表では、例えば、エリアＡに照明機器の装備があり、かつ、その照明機器に対して点灯及び点灯禁止のいずれも要求が可能であることを示している。図３５の表は、イルミサブマネージャから情報がフィードバックされるたびに更新される。

そして、メインマネージャ２１は、このエリア又は照明機器ごとに装備の有無及び受付可否の情報（図３５）に基づいて、イルミサブマネージャ向けの要求（図２９の右表）が可能か否かを判断する。図２９の右表の例では、Ｆｒドーム及びＦＬ席マップランプを点灯するという要求であるため、図３５を参照して、Ｆｒドーム及びＦＬ席マップランプの装備の有無及び受付可否の情報を確認する。この例では、Ｆｒドーム及びＦＬ席マップランプ共に装備有りかつ受付可能であるため、図３６における「◎印」で示されるように、イルミサブマネージャ向けの要求が可能であるとの判断がなされる。装備無し又は受付不可能である要求については、その要求は棄却される。なお、要求が絶対的なもの（◎印）か推奨する程度のもの（○印）かは、優先度や他の所定のパラメータなどに基づいて要求の単位で適宜設定することができる。

サブマネージャ向けとして要求可能であると判断された要求が複数存在する場合、メインマネージャ２１は、所定のルールに基づいてサブマネージャに出力する要求を決定する処理を実施する。所定のルールには、一例として、各ＡＣＴ／ＥＣＵについて優先度の高い要求を採用する、同じＡＣＴ／ＥＣＵに対する複数の要求である場合は優先度にかかわらず複数採用する、互いに排他的となる複数の要求がある場合は優先度の高い要求の方を採用する、といったルールが予め定義されている。

図３７に、サブマネージャ向けとして要求可能であると判断された５つの要求Ａ～Ｅが発生している場面を示している。要求Ａは、例えば車内機器自動制御（行動認識）サービスによるイルミサブマネージャ向けの要求を含む優先度３の要求であり、要求Ｂは、例えば自動運転サービスによるワイパサブマネージ及び蓋物サブマネージャ向けの要求を含む優先度１の要求であり、要求Ｃは、例えばレーンキープアシストサービスによるワイパサブマネージャ向けの要求を含む優先度２の要求であり、要求Ｄは、例えば車内子供見守り（機器操作制限）サービスによるイルミサブマネージャ及びワイパサブマネージャ向けの要求を含む優先度４の要求であり、要求Ｅは、例えば車内機器自動制御（音声認識）サービスによる蓋物サブマネージャ向けの要求を含む優先度４の要求である。優先度は、アプリ要求のサービスＩＤから特定することができる。なお、図３７において同じ要求グルーピング番号（ILL-1、ILL-2、WIP-3、DLK-1）が付されている複数の要求は、排他的な要求である。

図３７のような５つの要求Ａ～Ｅが発生している場面では、まず、メインマネージャ２１は、優先度１である要求Ｂを採用する。次に、メインマネージャ２１は、優先度２の要求Ｃについて検討し、フロントワイパ払拭要求が採用した要求Ｂのフロントワイパ払拭要求と同じでありかつその他の要求が競合しないため、要求Ｃを採用する。次に、メインマネージャ２１は、優先度３の要求Ａについて検討し、採用した要求Ｂ及び要求Ｃともに競合しないため、優先度にかかわらず要求Ａも採用する。一方、メインマネージャ２１は、優先度４である要求Ｄを検討し、Ｆｒドーム点灯禁止要求及びＦＬ席マップランプ点灯禁止要求が採用した要求ＡのＦｒドーム点灯要求及びＦＬ席マップランプ点灯要求と排他的となるため、要求Ｄを不採用とする。また、メインマネージャ２１は、優先度４である要求Ｅを検討し、ドアアンロック要求が採用した要求Ｂのドアロック要求と排他的となるため、要求Ｅを不採用とする。よって、この処理例では、５つの要求Ａ～Ｅのうち要求Ａ、要求Ｂ、及び要求Ｃの３つが採用される結果となる。

さらに、メインマネージャ２１は、上述した処理の結果、採用した要求が複数ある場合であって同じＡＣＴ／ＥＣＵに対する複数の要求がある場合には、どの要求の付加情報を選択するかを決定する。この決定は、高い要求を実行すれば低い要求も満足することができるとの考えに基づいて行われ、複数の要求を包含して実現するためのＡＣＴ／ＥＣＵの制御量を表すレベルが特定される。例えば、輝度レベル３のＦｒドーム点灯要求と輝度レベル５のＦｒドーム点灯要求とが採用された場合、輝度レベル５の明るさで照らしておけば輝度レベル３の明るさも満足することができると考えられるので、付加情報として輝度レベル３を包含する輝度レベル５が選択される。また例えば、Ｈｉ作動のフロントワイパ払拭要求とＬｏ作動のフロントワイパ払拭要求とが採用された場合、フロントワイパをＨｉ作動させておけば前方視界を確保するという観点からＬｏ作動の要求も満足することができると考えられるので、付加情報としてＬｏ作動を包含するＨｉ作動が選択される。図３７のように、要求Ｂと要求Ｃとでフロントワイパ払拭要求が採用された場合において、例えば要求ＢがＨｉ作動のフロントワイパ払拭要求であり、要求ＣがＬｏ作動のフロントワイパ払拭要求であれば、Ｌｏ作動の要求を満足することができるＨｉ作動の要求Ｂの付加情報が選択される。

以上の処理によって、メインマネージャ２１は、第１のアプリケーション実行部１１ａ～１１ｃから出力される複数の要求を処理して、サブマネージャ２３ａ～２３ｄ向けの要求を決定する。この処理結果は、サービスＡＣＫとして要求元である第１のアプリケーション実行部１１ａ～１１ｃに返信される。処理結果を受けた第１のアプリケーション実行部１１ａ～１１ｃは、メインマネージャ２１から取得した処理結果に基づいて、自らの要求に基づいてＡＣＴ／ＥＣＵが動作しているか否か、ＡＣＴ／ＥＣＵが動作が完了したか否かなど、制御処理の実行状況をモニターすることができ、必要に応じての制御処理の変更や中止を判断することができる。また、メインマネージャ２１がサービスＡＣＫを第１のアプリケーション実行部１１ａ～１１ｃに返信することにより、メインマネージャ２１と第１のアプリケーション実行部１１ａ～１１ｃとの間の通信量の増加を抑制することができる。

図３８に、図３７に示した要求Ａの一例として、車内機器自動制御（行動認識）サービスのエージェントアプリによって実現される手元追っかけ点灯処理に関する制御シーケンスの一例を示す。図３８の例では、ドライバーがオーバーヘッドに手をかざして、手元を照らすサービスの提供開始を意思表示した場合を示している。ドライバーの意思を確認したエージェントアプリは、メインマネージャにエリアＡの点灯要求を出力する。メインマネージャは、エリアＡの点灯要求をエージェントアプリから受け付け、図３７に示したように自動運転などの他のサービスから受け付ける複数の要求を処理して、イルミサブマネージャに出力する最終的な要求を決定する。イルミサブマネージャは、メインマネージャからエリアＡの点灯要求を入力すると、イルミ制御アプリからエリアＡの点灯に関する他の要求があるか否かを判断し、他の要求がある場合には複数の要求を調停する。図３７の例では、他の要求がないためイルミモジュールを介して照明Ｌ１、Ｌ２を点灯させる。ドライバーの手がコンソールのエリアＡからエリアＥに移動すると、エージェントアプリは、メインマネージャにエリアＡの消灯要求及びエリアＥの点灯要求を出力する。メインマネージャは、エージェントアプリから受け付けるエリアＡの消灯要求及びエリアＥの点灯要求についても同様に、他の複数の要求との競合を判断してイルミサブマネージャに出力する要求を決定する。イルミサブマネージャは、メインマネージャからエリアＡの消灯要求及びエリアＥの点灯要求を入力すると、イルミ制御アプリからエリアＡの消灯要求及びエリアＥの点灯に関する他の要求があるか否かを判断し、他の要求がある場合には複数の要求を調停する。例えば、乗員によってエリアＡの照明Ｌ１の点灯ボタンが押されていることをイルミ制御アプリから入力した場合、イルミサブマネージャは、メインマネージャからの要求よりも乗員操作を優先する調停を行って、エリアＡの点灯を継続する制御を行う。このようにして、ドライバーが手元を照らすサービスの提供終了を意思表示するまで、メインマネージャは、エージェントアプリによる手元追っかけ点灯処理要求を適切に処理しつつ、イルミサブマネージャでは、乗員によるイルミネーション操作を優先する調停を実施する。これにより、メインマネージャとサブマネージャとによる二段階処理を実現することができる。

＜作用・効果＞
以上のように、本発明の一実施形態に係る車両用調停システム１によれば、第１のアプリケーション実行部１１ａ～１１ｃからの要求を受け付けてサブマネージャ２３ａ～２３ｄ向けの要求を決定するメインマネージャ２１と、第２のアプリケーション実行部２２ａ～２２ｇからの要求とメインマネージャ２１で決定された要求とを調停するサブマネージャ２３ａ～２３ｄとによる、二段階処理構造を有している。この構造によって、メインマネージャ２１は、第２のアプリケーション実行部２２ａ～２２ｇからの要求を処理しなくて済む。よって、車両に新たな機能を追加する場合には、新たな機能を実現するアプリケーション及びそのアプリケーションを実行する第１のアプリケーション実行部をメインマネージャ２１側に追加するだけで、機能（サービス）拡張を容易に行うことができる。従って、例えば搭載する第１のアプリケーション実行部１１ａ～１１ｃが異なるといった車両間での仕様差や機能差に伴う影響は、メインマネージャ２１の制御処理によって吸収することができるので、サブマネージャ２３ａ～２３ｄに及ばなくなる。また、例えば装備するＡＣＴ／ＥＣＵ３１ａ～３１ｎの違いによる車両間での仕様差や機能差に伴う影響は、サブマネージャ２３ａ～２３ｄの調停処理によって吸収すると共にメインマネージャ２１に情報提供するので、メインマネージャ２１における制御処理の負荷を軽減できる。

また、本実施形態に係る車両用調停システム１によれば、メインマネージャ２１は、サブマネージャ２３ａ～２３ｄからＡＣＴ／ＥＣＵの状態を含む情報のフィードバックを受ける。これにより、第１のアプリケーション実行部１１ａ～１１ｃによって実現される新たな機能（サービス）と、第２のアプリケーション実行部２２ａ～２２ｇによって実現される既存の機能（サービス）とを、情報に基づいて適切に制御することができる。この情報には、サブマネージャが作動させたＡＣＴ／ＥＣＵの現在の動作状態に加えて、サブマネージャが管理可能なＡＣＴ／ＥＣＵの装備の有無、及び装備しているＡＣＴ／ＥＣＵによる動作受付の可否が含まれている。これにより、処理不可能な要求をメインマネージャ２１による処理の段階で排除できるため、サブマネージャ２３ａ～２３ｄにおける調停の負荷を軽減できる。

また、本実施形態に係る車両用調停システム１によれば、メインマネージャ２１は、第１のアプリケーション実行部１１ａ～１１ｃから受け付けた要求に優先度を付与したり、第１のアプリケーション実行部１１ａ～１１ｃから受け付けた要求を実現するためのＡＣＴ／ＥＣＵの制御量を表すレベルを特定したりする。これにより、メインマネージャ２１は、第１のアプリケーション実行部１１ａ～１１ｃから、複数の要求を受け付けた場合には複数の要求に付与された優先度に基づいて１つ以上の要求を採用することができたり、互いに排他的な複数の要求を受け付けた場合には優先度の高い要求を採用することができたり、同一のＡＣＴ／ＥＣＵに対する要求を複数受け付けた場合には複数の要求を包含して実現するためのＡＣＴ／ＥＣＵの制御量を表すレベルを採用することができる。よって、複数の要求に対する最適な処理を実施することができる。

なお、本発明は、車両用調停システムとして捉えるだけでなく、車両用調停システムが備える各システムのコンピューターが実行する方法、プログラム、プログラムを格納したコンピューター読み取り可能な非一時的な記憶媒体、あるいは、車両用調停システムを搭載した車両として捉えることも可能である。

本発明の調停システムは、複数のアプリケーションからの要求を調停して車両の動作を制御する車両に利用可能である。

１車両用調停システム
１１ａ～１１ｃ第１のアプリケーション実行部
２１メインマネージャ
２２ａ～２２ｇ第２のアプリケーション実行部
２３ａ～２３ｄサブマネージャ
３１ａ～３１ｎＡＣＴ／ＥＣＵ
４１～４４出力部
５１センサ／スイッチ
５２他のマネージャ

Claims

複数の第１のアプリケーションから１つ以上の第１の要求を受け付け、当該受け付けた１つ以上の第１の要求と所定のルールとに基づいて、第２の要求を決定するメインマネージャと、
前記第２の要求と少なくとも１つの第２のアプリケーションから入力される第３の要求とを調停し、当該調停された結果に基づいて所定の車載機器を制御するサブマネージャと、を備え、
前記メインマネージャ及び前記サブマネージャは、同一のＥＣＵ内に設けられ、
前記サブマネージャは、前記所定の車載機器の状態を示す情報を前記メインマネージャに通知する、車両用調停システム。
前記第２の要求及び前記第３の要求は、前記第１の要求よりも前記車載機器に対してより具体化した要求である、請求項１に記載の車両用調停システム。
前記サブマネージャは、前記所定の車載機器が搭載される車両の状態及び前記車両の周囲の状況の少なくともいずれか一方に基づいて、前記第２の要求と前記第３の要求とを調停する、請求項１に記載の車両用調停システム。
前記メインマネージャは、前記第１の要求を複数受け付け、当該受け付けた複数の第１の要求に対応する複数の処理の実施順番を決定することにより前記第２の要求を決定する、請求項１に記載の車両用調停システム。
請求項１乃至４のいずれか１項に記載の前記車両用調停システムを搭載した、車両。
複数の第１のアプリケーションから１つ以上の第１の要求を受け付け、当該受け付けた１つ以上の第１の要求と所定のルールとに基づいて、第２の要求を決定するメインマネージャと、前記第２の要求と少なくとも１つの第２のアプリケーションから入力される第３の要求とを調停し、当該調停された結果に基づいて所定の車載機器を制御するサブマネージャと、を備える、車両用調停システムのコンピューターが実行する方法であって、
前記メインマネージャが前記第２の要求を決定するステップと、
前記メインマネージャと同一のＥＣＵ内に設けられた前記サブマネージャが前記車載機器を制御するステップと、
前記サブマネージャが前記所定の車載機器の状態を示す情報を前記メインマネージャに通知するステップと、を含む、方法。
複数の第１のアプリケーションから１つ以上の第１の要求を受け付け、当該受け付けた１つ以上の第１の要求と所定のルールとに基づいて、第２の要求を決定するメインマネージャと、前記第２の要求と少なくとも１つの第２のアプリケーションから入力される第３の要求とを調停し、当該調停された結果に基づいて所定の車載機器を制御するサブマネージャと、を備える、車両用調停システムのコンピューターに実行させるプログラムであって、
前記メインマネージャが前記第２の要求を決定するステップと、
前記メインマネージャと同一のＥＣＵ内に設けられた前記サブマネージャが前記車載機器を制御するステップと、
前記サブマネージャが前記所定の車載機器の状態を示す情報を前記メインマネージャに通知するステップと、を含む、プログラム。