JP2021045987A - 車両用制御システム - Google Patents

Abstract

【課題】所望の制御機能のための処理が複数の制御部に分散配置され、その分散配置された処理が連携して実行される場合に、制御性能の低下を回避することが可能な車両用制御システムを提供する。【解決手段】車両用制御システム１は、サービス要求が発生すると、要求されたサービスに適した達成時期を設定する。そして、設定したサービスの達成時期を基準として、要求されたサービスを達成するための、複数の制御部に分散配置され連携して処理される繰り返し処理の実行スケジュールを定める。従って、複数の制御部が、その実行スケジュールに従って、繰り返し処理を実行することで、要求されたサービスを、適切な達成時期までに達成することが可能となり、制御性能の低下を回避することができる。【選択図】図３

Description

本開示は、所望のサービス要求の発生に基づいて、車両を制御する車両用制御システムに関する。

従来、車両に搭載される制御システムは、基本的に、制御対象ごとに構成される。各々の制御システムでは、概して、所定の信号を入力し、その入力した信号に基づく演算処理を行って出力信号を生成し、その出力信号により制御対象となるアクチュエータ等を駆動するとの一連の制御が所定周期毎に実行される。

近年では、車両の各機能をより高度に協調して制御可能とすることなどを狙いとして、車両全体の制御構造を階層化することも検討されている。例えば、特許文献１には、各車載機器の役割に応じて、各車載機器を複数のドメインに区分し、それらドメイン毎に、対応するドメインに属する車載機器の制御を統括するドメイン制御部を備えた制御システムが開示されている。この制御システムでは、各ドメイン制御部の下位の階層に、対応するドメイン制御部からの指令に従い、各車載機器の動作状態を制御する機器制御部が設けられる。さらに、制御システムは、各ドメイン制御部の上位階層に位置付けられ、各ドメイン制御部を連携、協調させるための統合制御部も備えている。

特開２０１８−８５６８６号公報

特許文献１に記載されるような、階層化された制御構造を有する制御システムにおいては、各制御機能のための処理が、複数の制御部に分散されることになる。例えば、特許文献１のシステムにおいて、運転者のアクセル操作に応じて車両を加速させる制御機能の場合、パワートレインドメイン制御部では、アクセルペダルの操作量、シフトレバーの操作位置、エンジンおよびモータジェネレータ（ＭＧ）の動作状態などに基づいて、車両全体としての必要駆動トルクを算出し、さらに、エンジンおよびＭＧが分担すべき目標エンジントルクおよび目標ＭＧトルクを算出して、エンジン制御部およびＭＧ制御部に出力するとの処理が行われる。エンジン制御部では、目標エンジントルクを達成するために必要なスロットルバルブ開度、燃料噴射量と燃料噴射時期、および点火時期を算出し、これらに応じた制御信号をエンジンに出力するとの処理が行われる。また、ＭＧ制御部では、目標ＭＧトルクを発生するように、ＭＧの各ステータコイルへの通電電流を制御するとの処理が行われる。

ここで、複数の制御部に処理が分散された場合に、各制御部における処理や、各制御部間での通信に要する時間が、他の制御機能のための処理などの影響を受けて変動したとすると、例えば、上述した例のように運転者がアクセル操作を行った場合に、実際に車両が加速するまでの応答性などが変動する可能性が生じ、制御性能の低下を招くことが懸念される。

本開示は、上述した点に鑑みてなされたものであり、所望の制御機能のための処理が複数の制御部に分散配置され、その分散配置された処理が連携して実行される場合に、制御性能の低下を回避することが可能な車両用制御システムを提供することを目的とする。

上記目的を達成するために、本開示による車両用制御システムは、
車両における所望のサービス要求の発生の有無を判定する判定部（Ｓ１００）と、
判定部がサービス要求の発生を判定すると、要求されたサービスの達成時期を設定する設定部（Ｓ１２０）と、
設定部によって設定されたサービスの達成時期を基準として、要求されたサービスを達成するための繰り返し処理の実行スケジュールを定めるスケジュール設定部（Ｓ１３０）と、
それぞれに分散配置され、連携して処理される繰り返し処理を、実行スケジュールに従って実行する複数の制御部（２４〜２６、４０〜４２）と、を備える。

上述したように、本開示による車両用制御システムでは、サービス要求が発生すると、要求されたサービスに適した達成時期が設定される。そして、設定されたサービスの達成時期を基準として、要求されたサービスを達成するための、複数の制御部に分散配置され連携して処理される繰り返し処理の実行スケジュールが定められる。このように、サービスの達成時期から遡って実行スケジュールを定めているので、複数の制御部が、その実行スケジュールに従って、繰り返し処理を実行することにより、要求されたサービスを、適切な達成時期までに達成することが可能となる。その結果、所望の制御機能のための処理が複数の制御部に分散されている場合であっても、制御性能の低下を回避することができる。

上記括弧内の参照番号は、本開示の理解を容易にすべく、後述する実施形態における具体的な構成との対応関係の一例を示すものにすぎず、なんら発明の範囲を制限することを意図したものではない。

また、上述した特徴以外の、特許請求の範囲の各請求項に記載した技術的特徴に関しては、後述する実施形態の説明及び添付図面から明らかになる。

実施形態による車両用制御システムが有する各種機能の一例を示す機能ブロック図である。 実施形態による車両用制御システムにおける、統合制御部及びパワートレインドメインに属する各制御部の複数のＥＣＵへの実装例を示した図である。 所望のサービスを達成するための処理の実行を管理する管理処理のメインルーチンを示すフローチャートである。 サービスを達成するための繰り返し処理の実行スケジュールの設定処理を示すフローチャートである。 繰り返し処理の実行に遅延が生じた場合に、繰り返し処理の実行スケジュールの変更内容を決定する決定処理を示すフローチャートである。 繰り返し処理の実行に遅延が生じる原因とその対応策とを例示する図である。

以下、本開示に係る車両用制御システムの実施形態を、図面を参照しつつ説明する。以下に説明する実施形態では、車両の走行駆動源として、エンジンと電動モータ（モータジェネレータ）とを有するハイブリッド車両に搭載される各種の車載装置からなる車載システムに対して、本開示による車両用制御システムを適用した例について説明する。しかしながら、本開示による車両用制御システムは、ハイブリッド車両における車載システムの制御に適用されるばかりでなく、エンジンのみを有する通常の車両や、電動モータのみを有する電動車両の車載システムの制御に適用されても良い。また、以下にドメイン分けに関して説明しているが、このドメイン分けは車両用制御システムの制御構造に密接に関係するため、必ずしも以下に説明する例と同一のドメイン分けを行う必要なく、適宜、最適なドメイン分けを行っても良い。また、ドメイン分けに加えて、もしくは代えて、各車載機器が設置されるエリア（ゾーン）に応じて、ゾーン分けを行っても良い。

図１は、上述したハイブリッド車両における車載システムを制御するために、車両用制御システム１が有する各種機能の一例を機能ブロック図として表したものである。ただし、図１には、車両用制御システム１が有する制御機能の全てが示されている訳ではない。これは、説明の便宜のため、図１には、本実施形態に係る車両用制御システム１の特徴を説明するために必要な構成の一例しか示していないためである。

図１において、車両用制御システム１は、車載機器としてのブレーキ装置３０、ステアリング装置３１、エアコン装置３２、ドアモータ３３、エンジン３４、モータジェネレータ３５、高圧バッテリ３６、メータ３７、及びディスプレイ３８などを制御するための機能を有する。しかしながら、上述したように、車両用制御システム１は、さらに、例えば、トランスミッション、サスペンション、車室内照明などのその他の車載機器を制御するための機能を有していても良い。

図１に示すように、車両用制御システム１は、各種の車載機器３０〜３８を制御するための機能が予め複数の論理ブロック（機能ブロック）１０〜１６、２０〜２８に区分けされ、それら複数の論理ブロック１０〜１６、２０〜２８間の連結関係を規定することによって構成されている。すなわち、車両用制御システム１における各種の車載機器３０〜３８を制御するための論理構造が、論理ブロック１０〜１６、２０〜２８と、それら論理ブロック１０〜１６、２０〜２８間の連結関係によって規定されている。そして、車両用制御システム１は、複数の論理ブロック１０〜１６、２０〜２８が、規定された連結関係に従って連携して動作することにより、各種の車載機器３０〜３８を制御する。

なお、図１には示していないが、各論理ブロック１０〜１６、２０〜２８は、少なくとも１つ、通常は多数の制御ブロックを有している。各論理ブロック１０〜１６、２０〜２８は、それら多数の制御ブロックにおける演算処理を適宜組み合わせることにより、それぞれの機能（役割）を発揮する。

例えば、論理ブロックとしてのエンジン制御部２４は、エンジン３４の運転状態を検出すべく、各種のセンサからのセンサ信号を入力して、論理ブロック内で取り扱うことができる信号に変換する制御ブロックを有することができる。また、センサ信号から把握されるエンジン３４の運転状態から現状の発生トルクを算出するとともに、上位の論理ブロック（パワートレインドメイン制御部１３）から指示された目標エンジントルクと差異がある場合に、その差異をなくすための目標とするエンジン運転状態を算出する制御ブロックを有する。さらに、目標エンジン運転状態を達成するためのスロットルバルブ開度、燃料噴射量と燃料噴射時期、及び点火時期を算出する制御ブロックを有する。そして、算出したスロットルバルブ開度、燃料噴射量と燃料噴射時期、及び点火時期に応じた、スロットルアクチュエータ、燃料噴射装置、および点火装置に駆動制御信号を出力する制御ブロックを有する。その他にも、例えば、エンジン３４の発熱温度に応じて、エンジン３４の温度調節を実行する制御ブロックなども有する。ただし、これらは単なる例示であって、エンジン制御部２４は、その機能を発揮するために必要な、その他の演算処理を行う制御ブロックを有する場合もあり得る。また、例示された制御ブロックを含め、エンジン制御部２４内の制御ブロックは、適宜、統合されたり、逆に、細分化されたりすることが可能なものである。

車両用制御システム１は、実際には、各論理ブロック１０〜１６、２０〜２８を、プログラムやデータベースとして、複数の電子制御装置に振り分けて実装することにより具現化される。この場合、複数の電子制御装置は、論理ブロック１０〜１６、２０〜２８の連結関係を維持できるように、個別の通信線を介して接続されたり、各電子制御装置が共通のネットワークに接続され、連結関係に従う所望の電子制御装置同士が通信可能に構成されたりする。

本実施形態に係る車両用制御システム１では、各車載機器３０〜３８の役割に応じて、各車載機器３０〜３８を複数のドメインに区分し、それらドメイン毎に、対応するドメインに属する車載機器３０〜３８の制御を統括するドメイン制御部が設けられている。

具体的には、図１に示す例では、ブレーキ装置３０やステアリング装置３１など、車両の挙動の安定化や車両の進行方向を決定する役割を担う車載機器の制御を統括するドメイン制御部としてシャシドメイン制御部１１が設けられている。また、車室内の空調を行うエアコン装置３２やドアモータ３３などの車室内の環境を調節したり、乗員の乗降を支援したりする役割を担う車載機器の制御を統括するドメイン制御部として、ボデードメイン制御部１２が設けられている。さらに、エンジン３４およびＭＧ３５が、車両を加速させたり、減速させたり、あるいは速度を一定に保つための動力を車両に作用させる役割を担うため、それらの車載機器の制御を統括するドメイン制御部として、パワートレインドメイン制御部１３が設けられている。なお、ＭＧ３５は、車両の減速時などに回生エネルギーを発生し、パワートレインドメイン制御部１３は、その回生エネルギーの生成、及びＭＧ３５などによるエネルギーの消費も管理する。このエネルギーは高圧バッテリ３６に蓄電されるので、パワートレインドメイン制御部１３が統括するドメインには、高圧バッテリ３６も属している。また、メータ３７やディスプレイ３８など、各種の情報を乗員に提供する車載機器の制御を統括するドメイン制御部として、情報ドメイン制御部１４が設けられている。

そして、本実施形態に係る車両用制御システム１では、図１に示すように、各ドメイン制御部１１〜１４の下位の階層に、対応するドメイン制御部１１〜１４からの指令に従い、各車載機器３０〜３８の動作状態を制御する機器制御部２０〜２８が設けられている。

例えば、図１に示す例では、シャシドメイン制御部１１の下に、ブレーキ装置３０を制御するブレーキ制御部２０、およびステアリング装置３１を制御するステアリング制御部２１が設けられている。また、ボデードメイン制御部１２の下に、エアコン装置３２を制御するエアコン制御部２２、およびドアモータ３３を制御するドア制御部２３が設けられている。さらに、パワートレインドメイン制御部１３の下に、エンジン３４を制御するエンジン制御部２４、ＭＧ３５を制御するＭＧ制御部２５、及び高圧バッテリ３６を制御するバッテリ制御部２６が設けられている。また、情報ドメイン制御部１４の下に、メータ３７を制御するメータ制御部２７、及びディスプレイ３８を制御するディスプレイ制御部２８が設けられている。

また、詳しくは後述するが、運転者の運転操作などの、車両の各種操作機器への操作に関する情報を取得する論理ブロックであるヒューマン・マシン・インターフェース（ＨＭＩ）１５、さらに、車両の外部環境に関する情報を取得する論理ブロックであるエンバイロメント・ビークル・インターフェース（ＥＶＩ）１６も、それぞれドメイン制御部と位置づけられる。

さらに、車両用制御システム１は、上記の各ドメイン制御部１１〜１６の、電源、通信、安全などに係る動作環境を管理するとともに、各ドメイン制御部１１〜１６を連携、協調させるための統合制御部１０を備えている。この統合制御部１０も、各ドメイン制御部の上位のドメイン制御部として、ドメイン制御部の１つに位置づけられる。なお、図１には、１つの統合制御部１０が示されているが、例えば、ドメイン制御部１１〜１６をいくつかのグループに分け、それらグループ分けされたドメイン制御部に対して、それぞれ統合制御部を設けても良い。また、統合制御部１０を独立して設けるのではなく、いずれかのドメイン制御部１１〜１６が、統合制御部１０の機能を兼ね備えるように構成しても良い。

ここで、本実施形態に係る車両用制御システム１では、各ドメイン制御部１１〜１６が連携、協調したり、各制御部１１〜１６、２０〜２８が連携したりすることで車両において発揮可能な各種の機能をサービスと位置付け、いずれかのサービスが要求された時点で、そのサービスを達成するための処理が実行されるように構成されている。例えば、車両の運転者が、アクセルペダルを踏み込むことに応じて、統合制御部１０は、車両を加速させるサービスが要求されたと判定する。この場合、統合制御部１０は、パワートレインドメイン制御部１３に、車両を加速させるための処理の実行を指示する。より具体的には、車両の運転者がアクセルペダルを踏み込んだとき、そのアクセルペダルの踏込量や踏込速度に応じた加速度を発生させる必要がある。この場合、例えば、パワートレインドメイン制御部１３が、アクセルペダルの踏込状態に応じて車両を加速させるための目標加速トルクを定める。さらに、パワートレインドメイン制御部１３は、その目標加速トルクを達成する際、最もエネルギー効率が良くなるように、エンジン目標トルクとＭＧ目標トルクとを算出する。エンジン制御部２４及びＭＧ制御部２５は、算出されたエンジン目標トルクおよびＭＧ目標トルクに従って、エンジン３４およびＭＧ３５を制御する。

また、例えば、車両の運転者がブレーキペダルを踏み込んだとき、統合制御部１０は車両を減速させるサービスが要求されたと判定する。この場合、車両において、ブレーキペダルの踏込量や踏込速度に応じた減速度を発生させる必要がある。このため、例えば、パワートレインドメイン制御部１３が、最初に、ブレーキペダルの踏込状態に応じて車両を減速させるための目標減速トルクを定める。さらに、パワートレインドメイン制御部１３は、ＭＧ３５による回生ブレーキにより発生可能な減速トルクを算出する。この減速トルクだけでは、目標減速トルクに対して不足する場合、パワートレインドメイン制御部１３は、不足する減速トルクをシャシドメイン制御部１１へ通知する。シャシドメイン制御部１１は、その不足する減速トルクを発生するように、ブレーキ制御部２０を介してブレーキ装置３０を制御する。

各ドメイン制御部１１〜１６が連携、協調したり、各制御部１１〜１６、２０〜２８が連携したりする別の例として、例えば、ドアハンドルが操作されたとき、統合制御部１０は、ドアを開扉するサービスが要求されたと判定する。この場合、例えば、ＥＶＩ１６がドアの周囲に障害物が存在しないかどうかを確認し、その確認結果に応じて、ボデードメイン制御部１２が、ドア制御部２３を通じてドアモータ３３を制御して、ドアの開閉角度を制限する。また、例えば、統合制御部１０は、室内の目標室温が設定または変更されたことに応じて、車室内の空調状態を制御または変更するサービスが要求されたと判定する。この場合、ボデードメイン制御部１２が、ＥＶＩ１６によって検出される外部環境（外気温度、外気湿度など）を受信し、車室内温度、車室内湿度、及び日射量なども考慮した上で、エアコン制御部２２を通じて車室内の空調状態を適切に制御する。さらに、統合制御部１０は、ウインドウスイッチが操作されたことに応じて、ウインドウを開閉するサービスが要求されたと判定する。この場合、ボデードメイン制御部１２が、ドア制御部２３を通じてドアウインドウの開閉を制御する。

また、各ドメイン制御部１１〜１６が連携、協調したり、各制御部１１〜１６、２０〜２８が連携したりするさらなる別の例として、例えば、ＥＶＩ１６が車両の前方に障害物が存在することを検出したとき、統合制御部１０は、車両を制動する、および／または障害物を回避するようステアリングを操作するサービスが要求されたと判定する。この場合、シャシドメイン制御部１１は、障害物との衝突を防止するように、ブレーキ制御部２０を通じてブレーキ装置３０を制御したり、障害物を回避するように、ステアリング制御部２１を通じてステアリング装置３１を制御したりする。

さらに、例えば、統合制御部１０は、エンジン３４の温度が低いとき、エンジン３４の暖気を促進するサービスが要求されたと判定する。この際、車両のフロントグリルなどに、エンジンルームへ繋がる開口部を開閉するシャッターが設けられている場合には、パワートレインドメイン制御部１３は、シャッターを閉じるように制御する。一方、車両の乗員によりエアコンの外気導入が指示された場合、ボデードメイン制御部１２は、車室内に外気が取り入れやすくするためにシャッターを開くように制御する。このように、共通の車載機器が、異なる制御部によって制御されることが起こり得る。このような場合、共通の車載機器に対する制御が相反する場合には、優先度の高い制御が実行されるように、それぞれのドメイン制御部が連携する。

その他にも、種々のサービスが考えられる。例えば、エンジンの運転に伴い車両に振動が発生した場合には、統合制御部１０は、例えば、エンジンマウントの振動伝達特性を切り替えることにより振動を抑制するサービスが要求されたと判定する。この場合、パワートレインドメイン制御部１３が、例えばエンジン制御部２４に対して、エンジンマウントの振動伝達特性の変更を指示してもよい。また、ＭＧ３５のみによる車両の走行と、エンジン３４を利用した車両の走行を切り替えるために、エンジン３４とＭＧ３５との間にクラッチが設けられている場合、統合制御部１０は、例えば、車両の速度が上昇したことに応じて、エンジン３４を利用した車両の走行に切り替えるサービスが要求されたと判定する。この場合、統合制御部１０は、エンジン制御部２４に対して、クラッチの係合を指示する。すると、エンジン制御部２４は、エンジンの回転数と車軸との回転数差などに基づき、ショックが生じないように所定の係合期間をかけてクラッチを係合する。このように、統合制御部１０は、車両の乗員の操作や、車両の状況に応じて、種々のサービスが要求されたか否かを判定する。

次に、図１に論理ブロック１０〜１６、２０〜２８として例示した、車両用制御システム１が有する各種の機能及び各論理ブロック１０〜１６、２０〜１８の連結関係について説明する。

図１に示すように、車両用制御システム１は、種々の情報を取得するため、ＨＭＩ１５及びＥＶＩ１６を備えている。ＨＭＩ１５は、ハイブリッド車両の運転のためや各種の車載機器の操作のために、運転者によって操作される操作部の操作量や操作位置を取得するための論理ブロックである。なお、運転者によって操作される操作部には、アクセルペダル、ブレーキペダル、シフトレバー、ステアリングホイールなどの他、エアコン装置の操作部、ドアハンドルなども含まれる。それら操作部における各々の操作量や操作位置がセンサ等によって検出され、ＨＭＩ１５にて取得される。また、ＥＶＩ１６は、ハイブリッド車両が置かれた外部環境に関する情報を取得するもので、例えば、先行車両や障害物などを検出するレーダ装置、車両の周囲の画像を取得するカメラ、及び車両の位置や走行路の形状を提供するナビゲーションシステムなどから情報を取得する。さらに、ＥＶＩ１６は、外気温度、外気湿度などに関する情報も取得する。なお、ＨＭＩ１５、ＥＶＩ１６、あるいは他の論理ブロックを用いて、車両の走行状態（例えば、速度、加速度など）や、各種の車載機器の動作状態（例えば、エンジン回転数、モータ回転数、ブレーキ油圧、操舵角など）を示す情報も取得される。

上記したＨＭＩ１５において取得した操作量、操作位置に関する情報や、ＥＶＩ１６にて取得した外部環境に関する情報は、車両用制御システム１の統合制御部１０及び各ドメイン制御部１１〜１４に与えられる。これにより、例えば、統合制御部１０では、乗員の操作や、車両が置かれた状況を把握し、その状況に応じて必要となるサービスを決定することが可能となる。

シャシドメイン制御部１１には、例えば、車両の外部環境に関する情報が与えられる。これにより、シャシドメイン制御部１１において、例えば、画像から白線を認識し、その白線によって区画される走行車線を逸脱しないように、ステアリング装置３１のアシスト力を調整する（レーンキープコントロール）ことが可能となる。さらに、シャシドメイン制御部１１にて、例えば、先行車両や障害物との衝突を避けるように、ブレーキ装置３０やステアリング装置３１を制御することが可能となる。

ブレーキ制御部２０は、シャシドメイン制御部１１から出力された制御信号に従い、ブレーキ装置３０の動作を制御する。また、ステアリング制御部２１も、シャシドメイン制御部１１から出力された制御信号に従い、ステアリング装置３１の動作を制御する。

ボデードメイン制御部１２には、車両のメインスイッチ信号、エアコン装置３２の操作信号、ドアハンドルの操作信号、乗員検出信号などの情報が入力される。そして、例えば、車両に乗員が乗車しており、エアコン装置３２の操作信号が検出されて、統合制御部１０から車室内の空調状態を制御するよう指示されると、ボデードメイン制御部１２は、エアコン制御部２２を通じて車室内の空調状態を制御する。また、例えば、運転者が、車両のエンジンを停止させ、車両を停車した状態で、ドアハンドルを操作した場合、統合制御部１０は、乗員により車両を降車するためのサービスの要求があったと判定する。この場合、ボデードメイン制御部１２とＥＶＩ１６との連携制御が開始され、ＥＶＩ１６によりドア周囲に障害物が検出されると、ボデードメイン制御部１２は、ドアモータ３３によりドアが障害物に衝突しないよう、ドアの開閉角度を制御する。

エアコン制御部２２は、ボデードメイン制御部１２からの指示に応じて、車室内空調の制御を実行する。具体的には、エアコン制御部２２は、エアコン装置３２の操作信号に加えて、車室内外の温度検出信号、日射量の検出信号などの情報を入力する。そして、エアコン制御部２２は、操作信号や各種の検出信号に基づいて、車室内環境を、車両の乗員によって指示された環境に一致させるべく、エアコン装置３２を制御するための制御信号を生成して、出力する。この結果、エアコン装置３２のファンの回転数や、エアミックスドアの開度が制御され、車室内の温度や湿度が、乗員が所望する状態に制御される。また、ドア制御部２３は、ボデードメイン制御部１２からの指示に従って、ドアモータ３３を制御し、ドアの開閉角度を制限する。

パワートレインドメイン制御部１３には、例えば、アクセルペダル及びシフトレバーの操作量、操作位置の他、エンジン３４やＭＧ３５の動作状態を示す情報が与えられる。そして、パワートレインドメイン制御部１３は、統合制御部１０からの指令に応じて、それらの情報に基づき、運転者の操作に対応して車両を加速させたり、車速を維持させたりするための、車両全体としての必要駆動トルクを算出する。さらに、パワートレインドメイン制御部１３は、車両全体の必要駆動トルクからエンジン３４及びＭＧ３５が分担すべき駆動トルク（目標エンジントルク、目標ＭＧトルク）を算出して、エンジン制御部２４及びＭＧ制御部２５に出力する。また、パワートレインドメイン制御部１３は、高圧バッテリ３６の蓄電量や、各ドメインにおける電力使用量に基づき、車両の減速時等において、ＭＧ３５が発生すべき回生電力量を定め、ＭＧ制御部２５に出力する。

エンジン制御部２４は、パワートレインドメイン制御部１３から出力された目標エンジントルクを達成するために必要な制御信号をエンジン３４に出力する。より詳細には、エンジン制御部２４は、エンジン３４の運転状態を検出する各種のセンサ（回転数、温度、空気流量等）からの情報を入力する。そして、センサからの情報により把握されるエンジン３４の運転状態から現状の発生トルクを算出する。一方、エンジン制御部２４は、目標エンジントルクとの差分のトルクを増減するためのエンジン運転状態を算出する。エンジン制御部２４は、算出したエンジン運転状態を達成するための、スロットルバルブ開度、燃料噴射量と燃料噴射時期、及び点火時期を算出し、これらに応じた制御信号をエンジン３４に出力する。

ＭＧ制御部２５も、パワートレインドメイン制御部１３から出力された目標ＭＧトルクを実現するための制御信号をＭＧ３５に出力する。例えば、ＭＧ制御部２５は、ＭＧ３５が発生する駆動トルクによりエンジントルクをアシストする場合、ＭＧ３１が目標ＭＧトルクを発生するように、ベクトル制御などによりＭＧ３１の各ステータコイルへの通電電流を制御する。また、ＭＧ制御部２５は、回生ブレーキ時には、パワートレインドメイン制御部１３において定められた回生電力量が得られるように、ＭＧ３５のインバータを制御する。

情報ドメイン制御部１４には、車両のメインスイッチ信号、乗員による表示操作信号などの情報が入力される。そして、情報ドメイン制御部１４は、統合制御部１０からの指示に応じて、メインスイッチ信号の状態、及び乗員による表示操作信号などに基づき、メータ制御部２７及びディスプレイ制御部２８に、情報の表示を実行するように指示する。

メータ制御部２７は、情報ドメイン制御部１４からの指示に従って、メータ３７による表示を制御する。例えば、メータ制御部２７は、車速、エンジン回転数、エンジン水温、残燃料などの情報や、車両と周囲の障害物との距離情報などを入力する。そして、メータ３７を用いて、車速、エンジン回転数、水温、残燃料、あるいは障害物との接近度合などを表示したりする。なお、メータ制御部２７は、情報ドメイン制御部１４からの指示に従い、情報の表示数や表示の態様を変化させる。

ディスプレイ制御部２８は、例えば、車両の周囲の状況を撮影するカメラからの画像情報や、ステアリング操舵角の情報を取得する。そして、ディスプレイ３８に表示する画像情報を制御する。例えば、ディスプレイ制御部２８は、カメラ画像に車両の予定進路を重畳表示したり、障害物の存在を知らせる表示を行ったりする。

次に、本実施形態の車両用制御システム１の実装例について、図２を参照して説明する。図２は、統合制御部１０及びパワートレインドメインに属する各制御部の複数のＥＣＵへの実装例を示している。図２に示すように、統合制御部１０とパワートレインドメイン制御部１３が、同じセントラルＥＣＵ４０に実装されている。このように、複数のドメイン制御部が、共通の電子制御装置であるセントラルＥＣＵ４０に実装されてもよい。そして、統合制御部１０及びパワートレインドメイン制御部１３が実装されたセントラルＥＣＵ４０の下位の階層には、第１ゾーンＥＣＵ４１と第２ゾーンＥＣＵ４２とが設けられている。第１ゾーンＥＣＵ４１は、主に、車両のエンジンルームの近傍のゾーンに配置されるＥＣＵやセンサと、統合制御部１０及びパワートレインドメイン制御部１３との間で行われる通信を中継する役割を果たす。また、第２ゾーンＥＣＵ４２は、主に、車両のキャビンの近傍のゾーンに配置されるＥＣＵやディスプレイと、統合制御部１０及びパワートレインドメイン制御部１３との間で行われる通信を中継する役割を果たす。

第１ゾーンＥＣＵ４１は、図２に示すように、アクセルセンサ５０によって検出されるアクセル信号、およびブレーキセンサ５１によって検出されるブレーキ信号を入力し、セントラルＥＣＵ４０へ向けて出力する送信処理部４３を有する。この送信処理部４３は、図１のＨＭＩ１５の一部に相当する役割を果たす。また、第１ゾーンＥＣＵ４１は、パワートレインドメイン制御部１３によって算出される目標エンジントルクおよび目標ＭＧトルクを受信し、エンジン制御部が実装されたエンジンＥＣＵ２４およびＭＧ制御部が実装されたＭＧＥＣＵ２５に出力する受信処理部４４を有する。

例えば、車両の運転者が、アクセルペダルを踏み込むと、その踏込状態に応じたアクセル信号がアクセルセンサ５０から出力される。このアクセル信号は、第１ゾーンＥＣＵ４１の送信処理部４３を介して、セントラルＥＣＵ４０に送信される。セントラルＥＣＵ４０に実装された統合制御部１０は、このアクセル信号に基づいて、車両を加速させるサービスが要求されたと判定する。そして、統合制御部１０は、パワートレインドメイン制御部１３に、車両を加速させるための処理の実行を指示する。この際、詳しくは後述するが、統合制御部１０は、車両を加速させるための処理の実行スケジュールを生成してパワートレインドメイン制御部１３に提供する。パワートレインドメイン制御部１３は、提供された実行スケジュールに従って処理を実行する。具体的には、パワートレインドメイン制御部１３は、アクセル信号に基づいて、車両を加速させるための目標加速トルクを定め、さらに、その目標加速トルクを達成するためのエンジン目標トルクとＭＧ目標トルクとを算出する。算出されたエンジン目標トルクとＭＧ目標トルクは、第１ゾーンＥＣＵ４１の受信処理部４４を介して、エンジンＥＣＵ２４およびＭＧＥＣＵ２５に与えられる。エンジンＥＣＵ２４及びＭＧＥＣＵ２５は、与えられたエンジン目標トルクおよびＭＧ目標トルクに従って、エンジン３４およびＭＧ３５を制御する。このような処理が、統合制御部１０によって提供された実行スケジュールの完了次期まで、実行スケジュールで規定された制御周期で繰り返される。

第２ゾーンＥＣＵ４２は、バッテリ制御部が実装されたバッテリＥＣＵ２６によって出力されるＳＯＣ（State of Charge：残存容量）、ＳＯＨ（State of Health：劣化状態）を入力し、セントラルＥＣＵ４０へ向けて出力する送信処理部４５を有する。この送信処理部４５も、図１のＨＭＩ１５の一部に相当する役割を果たす。また、第２ゾーンＥＣＵ４２は、パワートレインドメイン制御部１３によって生成される、高圧バッテリの充電、放電状態や、残容量等を表示するための表示信号を受信し、エネルギーディスプレイに出力する受信処理部４６を有する。

上述したように、本実施形態による車両用制御システム１では、所望のサービスが要求されたことに応じて実行される処理が、複数の制御部１０、１３、２４〜２６、４３〜４６に分散されている。このため、各制御部１０、１３、２４〜２６、４３〜４６における処理や、各制御部１０、１３、２４〜２６、４３〜４６間での通信に要する時間が、他のサービスのための処理などの影響を受けて変動したとすると、要求されたサービスを達成する際の制御性能の低下を招くことが懸念される。

そのため、本実施形態による車両用制御システム１は、サービス要求が発生したと判定すると、まず、その要求されたサービスに適した達成時期を設定する。そして、設定したサービスの達成時期を基準として、要求されたサービスを達成するための、複数の制御部１０、１３、２４〜２６、４３〜４６に分散配置され連携して処理される繰り返し処理の実行スケジュールを定める。このように、サービスの達成時期から遡って実行スケジュールを定めているので、複数の制御部１０、１３、２４〜２６、４３〜４６が、その実行スケジュールに従って、繰り返し処理を実行することにより、要求されたサービスを、適切な達成時期までに達成することが可能となる。その結果、所望のサービスを達成するための処理が複数の制御部１０、１３、２４〜２６、４３〜４６に分散されている場合であっても、制御性能の低下を回避することができる。

以下、所望のサービスを達成するための処理の実行を管理する管理処理について、図３のフローチャートを参照して説明する。図３は、管理処理のメインルーチンを示すフローチャートである。この管理処理は、統合制御部１０において定期的に実行される。ただし、セントラルＥＣＵ４０に統合制御部１０とは別個の専用の制御部を設け、その専用の制御部において管理処理を行うようにしてもよい。

図３のフローチャートのステップＳ１００では、各種のセンサ信号やスイッチ信号に基づき、車両の乗員の操作や、車両の状況に応じて、いずれかのサービスが要求されたか否かを判定する。ステップＳ１００の判定処理にて、いずれのサービスも要求されていないと判定した場合、図３のフローチャートに示す処理を一旦終了する。一方、いずれかのサービスが要求されていると判定した場合、ステップＳ１１０の処理に進む。ステップＳ１１０では、要求されたサービスを達成するための処理が、設定した周期で繰り返し実行される繰り返し処理であるか、１度の処理で済むイベント処理であるかを判定する。例えば、上述した車両を加速させるサービス、車両を減速させるサービス、ドアを開扉するサービス、車室内の空調状態を制御するサービス、ウインドウを所望の位置まで開閉するサービス、前方障害物との衝突を避けるためのサービスなどは、サービスを達成するための処理が繰り返し処理であると判定され得る。一方、エンジンルームへ繋がる開口部に設けられたシャッターを開閉するサービスや、エンジン振動を抑制するサービスなどは、サービスを達成するための処理がイベント処理であると判定され得る。繰り返し処理と判定された場合、ステップＳ１２０の処理に進む。一方、イベント処理であると判定されると、ステップＳ１７０の処理に進む。

ステップＳ１２０では、要求されたサービスを達成するべき達成時期を設定する。なお、サービスと、その達成時期との関係については、予め定められメモリに記憶されている。例えば、車両を加速させるサービスが要求された場合、要求される加速の大きさに応じて数百ｍｓから数秒の達成時期が設定される。従って、達成時期が経過した後には、要求される加速の大きさに対応する加速度が発生することになる。また、車室内の空調状態を制御するサービスが要求された場合には、目標とする空調状態と現状の空調状態との偏差に応じて、数十秒から数分の達成時期が設定される。従って、達成時期が経過した後には、車室内の空調状態は、目標とする空調状態にほぼ一致することになる。このように、ステップＳ１２０では、要求されたサービスの内容に応じて、適切なサービス達成時期が設定される。

続くステップＳ１３０では、サービスを達成するための繰り返し処理の実行スケジュールを設定する。この実行スケジュール設定の詳細な処理が、図４のフローチャートに示されている。以下、図４のフローチャートを参照して、実行スケジュールの設定に関して説明する。

図４のフローチャートのステップＳ２００では、設定されたサービス達成時期に基づいて、繰り返し処理の完了時期を設定する。例えば、車両を加速させるためのサービスを達成する処理は、パワートレインドメイン制御部１３において、目標エンジントルクおよび目標ＭＧトルクが算出する処理が、実行スケジュールによって規定される制御周期毎に定期的に繰り返される。しかし、パワートレインドメイン制御部１３において、実行スケジュールの最後の制御周期において、最終的な目標エンジントルクおよび目標ＭＧトルクが算出されても、エンジン３４およびＭＧ３５において、それらの目標エンジントルクおよび目標ＭＧトルクに相当するトルクが発生され、その結果として、車両の実際の加速度が、加速要求に応じた加速度となるまでには遅れ時間が存在する。ステップＳ２００では、その遅れ時間を考慮して、サービスの達成時期よりも前に繰り返し処理の完了時期を設定する。

続くステップＳ２１０では、既に実行中の繰り返し処理が有るか否かを判定する。実行中の繰り返し処理は無いと判定するとステップＳ２２０の処理に進む。一方、実行中の繰り返し処理があると判定するとステップＳ２４０の処理に進む。

ステップＳ２２０では、制御周期として、要求されたサービスに対して予め定められた制御周期を選択する。例えば、車両を加速させたり減速させたりするサービスについては、高応答性が求められるので、数ｍｓの比較的短い制御周期が予め定められている。一方、ドアを開扉するサービスや車室内の空調状態を制御するサービスについては、それほど高い応答性が求められる訳ではないので、数十ｍｓの比較的長い制御周期が予め定められている。なお、ステップＳ２２０では、選択した制御周期で、繰り返し処理を繰り返す繰り返し数も設定される。そして、ステップＳ２３０では、完了時期および繰り返し処理の繰り返し数に基づき、完了時期までに繰り返し処理が完了するように、制御開始時期を設定する。

一方、ステップＳ２１０において、実行中の繰り返し処理があると判定されたときに実行されるステップＳ２４０では、後に実行が開始される繰り返し処理の制御周期を、先に実行が開始され、実行中の繰り返し処理の制御周期に対して、整数倍もしくは１／整数倍の制御周期を選択する。この際、要求されたサービスに対して予め定められた制御周期に最も近い整数倍もしくは１／整数倍の制御周期が設定される。さらに、ステップＳ２４０では、選択した制御周期で繰り返し処理を繰り返す繰り返し数も設定される。続くステップＳ２５０では、完了時期および繰り返し処理の繰り返し数に基づき、完了時期までに繰り返し処理が完了し、かつ、後に実行が開始される繰り返し処理の制御周期の位相が、先に実行が開始され実行中の繰り返し処理の制御周期の位相からずれるように、制御開始時期を設定する。このように、制御周期の長さを整数倍または１／整数倍に合わせつつ、制御周期の位相をずらすことにより、先に実行が開始された繰り返し処理の実行タイミングと、後に実行が開始される繰り返し処理の実行タイミングとが重なることを防止することができる。

最後に、ステップＳ２６０において、設定した制御周期および制御開始時期、すなわち繰り返し処理の実行スケジュールを、その繰り返し処理を実行する制御部（例えば、ドメイン制御部）へ提供する。

再び、図３のフローチャートに戻って、説明を続ける。ステップＳ１３０において、繰り返し処理の実行スケジュールが設定され制御部へ提供されると、当該制御部は、提供された実行スケジュールに従って繰り返し処理の実行を開始する。統合制御部１０は、ステップＳ１４０において、この繰り返し処理の実行状況を示す情報を取得する。例えば、車両を加速させるサービスの場合、パワートレインドメイン制御部から、パワートレインドメイン制御部が、エンジン回転数などのセンサ信号を取得するタイミング（周期）、バッテリＥＣＵ２６からＳＯＣ／ＳＯＨを取得するために要した時間、第１ゾーンＥＣＵ４１に目標エンジントルクおよび目標ＭＧトルクを出力したタイミング（周期）などの情報を取得する。このような情報を取得することにより、統合制御部１０は、繰り返し処理を実行するドメイン制御部において、繰り返し処理の制御周期に合わせて、必要な情報が入力され、また、指令信号が出力されているかを判定することが可能となる。すなわち、統合制御部１０は、制御周期毎に入力および出力があり、それが完了時期まで継続した場合、繰り返し処理が実行スケジュール通りに行われ、完了時期までに完了したと判定することができる。

なお、統合制御部１０は、必ずしもドメイン制御部だけから、繰り返し処理の実行状況を示す情報を取得する必要はない。ドメイン制御部からの情報に加えて、または代えて、ゾーンＥＣＵから入力および出力に関する情報を取得したり、エンジン等の車載機器を直接的に制御するエンジンＥＣＵ２４等のＥＣＵから出力に関する情報を取得したりしてもよい。

続くステップＳ１５０では、ステップＳ１４０にて取得した繰り返し処理の実行状況を示す情報に基づいて、繰り返し処理が完了時期までに完了したか否かを判定する。繰り返し処理が完了時期までに完了したと判定した場合、図３のフローチャートに示す処理を終了する。一方、繰り返し処理が完了時期までに完了しなかったと判定した場合、ステップＳ１６０の処理に進む。

繰り返し処理が完了時期までに完了しなかった場合、同じ期間に実行されていた他の繰り返し処理の影響などにより、対象とする繰り返し処理の実行に遅延が生じて、完了時期までに完了しなかったと考えられる。そのため、次回、遅延が生じた繰り返し処理を必要とするサービスの要求があったとき、再び遅延が生じないように、今回のサービス要求時の実行スケジュールから変更した実行スケジュールを設定する。ステップＳ１６０では、次回、実行スケジュールをどのように変更するか変更内容を決定する。この実行スケジュールの変更内容の決定処理の詳細が、図５のフローチャートに示されている。以下、図５のフローチャートを参照して、次回の実行スケジュールの変更内容の決定に関して説明する。

次回の実行スケジュールの変更内容の決定処理では、図５のフローチャートのステップＳ３００において、図３のフローチャートのステップＳ１４０で取得した繰り返し処理の実行状況に基づいて、繰り返し処理の実行に遅延が生じた原因を特定する。例えば、図６に示すように、繰り返し処理は正常に開始されたにも係わらず、データ取得のための通信遅延が大きかったことが原因で遅延が生じたのか、処理順序が、他の繰り返し処理よりも後だったため、他の繰り返し処理の遅延の影響を受けて、自らの繰り返し処理も遅延したのか、あるいは、処理順序は他の繰り返し処理よりも前であったにも係わらず、自らの繰り返し処理自体の処理の遅延により遅延したのか、等を特定する。繰り返し処理が遅延する原因としては、上述したような場合以外にも、図６に示すように、繰り返し処理の開始が遅延したことや、繰り返し処理が開始されなかったことなどが考えられる。

続くステップＳ３１０では、特定した原因に応じて、実行スケジュールの変更内容を決定する。例えば、図６に示されるように、遅延の原因が、データ取得のための通信遅延が大きかったことである場合、データ取得のための通信回数を間引きし、例えば数回の制御周期ごとに通信を行う実行スケジュールに変更する。この場合、新たなデータが取得されるまでは、取得済みのデータが繰り返し利用される。また、遅延の原因が、処理順序が他の繰り返し処理よりも後だったことにある場合、処理順を前出しする実行スケジュールに変更する。遅延の原因が、自らの繰り返し処理自体の処理の遅延にある場合、制御開始時期を前倒しした実行スケジュールに変更する。遅延の原因が、繰り返し処理の開始の遅延にある場合も、制御開始時期を前倒しした実行スケジュールに変更する。遅延の原因が、繰り返し処理が開始されなかったことにある場合には、実行スケジュールそのものではなく、制御開始時期を計測するタイマを別タイマに変更したり、繰り返し処理が割り付けられるコアを別コアに変更したりといった、繰り返し処理の実行環境を変更する。決定された実行スケジュールの変更内容は保存され、次回のサービス要求の発生に応じて、繰り返し処理の実行スケジュールを設定する際にその変更内容が反映される。

なお、図３のフローチャートのステップＳ１１０において、要求されたサービスを達成するための処理がイベント処理と判定されたときに実行されるステップＳ１７０では、統合制御部１０は、イベント処理の開始時期を設定する。そして、ステップＳ１８０において、イベント処理を実行する制御部に、設定した開始時期を指示する。

以上、本発明の好ましい実施形態について説明したが、本発明は上述した実施形態になんら制限されることなく、本発明の主旨を逸脱しない範囲において、種々変形して実施することが可能である。

例えば、上述した実施形態では、繰り返し処理の実行スケジュールを設定する際、既に実行中の繰り返し処理があった場合、後に実行が開始される繰り返し処理の制御周期を、先に実行が開始され、すでに実行中の繰り返し処理の制御周期に対して、整数倍もしくは１／整数倍の制御周期を選択した。しかしながら、後に実行が開始される繰り返し処理の実行スケジュールを定める際、後に実行が開始される繰り返し処理の制御周期を基準とし、先に実行が開始された繰り返し処理の制御周期との間で整数倍もしくは１／整数倍との関係が満たされるように、先に実行が開始された繰り返し処理の制御周期を変更するようにしてもよい。

また、上述した実施形態では、統合制御部１０は、繰り返し処理を実行するドメイン制御部、ゾーンＥＣＵ、車載機器を直接的に制御するＥＣＵなどから繰り返し処理の実行状況を示す情報を取得し、この取得した情報に基づいて、繰り返し処理が完了時期までに完了したか否かを判定した。しかしながら、繰り返し処理が完了時期までに完了したかどうかは、上述したような繰り返し処理の実行状況を示す情報に基づくことに加えて、もしくは代えて、要求されたサービスに対応する車両の変化（例えば、加速度など）を検出する検出部を設け、設定したサービスの達成時期に、要求されたサービスに見合う車両の変化が生じているか否かを判定することにより、繰り返し処理が完了時期までに完了されたか否かを判定するようにしてもよい。

さらに、上述した実施形態では、繰り返し処理の実行に遅延が生じた場合、その遅延が生じた原因を特定して実行スケジュールの変更内容を決定し、次回の実行スケジュールに反映するようにした。しかしながら、同時期に実行された他の繰り返し処理が遅延の主な原因であった場合には、次回も、同じ他の繰り返し処理が同時期に実行される場合にのみ、
実行スケジュールの変更内容を反映するようにしてもよい。

また、上述した実施形態では、繰り返し処理の実行スケジュールを設定する際、その制御周期を一定とする例について説明した。しかしながら、時間の経過とともに制御周期が変動する実行スケジュールを設定してもよい。例えば、車両を加速させるサービスが要求された場合、そのサービスを達成するための繰り返し処理の制御周期として、加速の開始直後は、加速度の変化が緩慢であるため、制御周期を相対的に短く設定して細やかな制御を行い、加速度がある程度大きくなる時点で制御周期を相対的に長く設定し、加速完了直前になる時点で、再び目標加速度への到達のため制御周期を相対的に短く設定してもよい。なお、時間の経過とともに制御周期が変動する実行スケジュールを設定する場合、同時に実行している他の繰り返し処理があれば、制御周期が変化するタイミングで、同時に実行している他の繰り返し処理の制御周期も、上述したように整数倍もしくは１／整数倍との関係が満たされるように変更することが好ましい。逆に、他の繰り返し処理の制御周期を基準として、その制御周期の整数倍もしくは１／整数倍となるように、時間の経過とともに制御周期が変動する実行スケジュールの変化後の制御周期を変更してもよい。

また、上述した実施形態では、要求されたサービスを達成するための処理が、イベント処理であると判定した場合、イベント処理の開始時期を設定するだけであった。しかしながら、イベント処理に関しても、繰り返し処理と同様に、サービスの達成時期に基づく完了時期および開始時期を含む実行スケジュールを定めてもよい。そして、イベント処理が完了時期までに完了しなかったと判定した場合には、イベント処理の開始時期を早めるように、次回のサービス要求時の実行スケジュールを変更してもよい。なお、イベント処理と同時期に、繰り返し処理が実行される場合には、イベント処理の開始時期は、繰り返し処理の空き時間または繰り返し処理の完了後に設定されることが好ましい。

１：車両用制御システム、１０：統合制御部、１１：シャシドメイン制御部、１２：ボデードメイン制御部、１３：パワートレインドメイン制御部、１４：情報ドメイン制御部、１５：ＨＭＩ、１６：ＥＶＩ、２０：ブレーキ制御部、２１：ステアリング制御部、２２：エアコン制御部、２３：ドア制御部、２４：エンジン制御部、２５：ＭＧ制御部、２６：バッテリ制御部、２７：メータ制御部、２８：ディスプレイ制御部、３０：ブレーキ装置、３１：ステアリング装置、３２：エアコン装置、３３：ドアモータ、３４：エンジン、３５：モータジェネレータ、３６：高圧バッテリ、３７：メータ、３８：ディスプレイ、４０：セントラルＥＣＵ、４１：第１ゾーンＥＣＵ、４２：第２ゾーンＥＣＵ

Claims (12)

1. 車両における所望のサービス要求の発生の有無を判定する判定部（Ｓ１００）と、
   前記判定部が前記サービス要求の発生を判定すると、要求されたサービスの達成時期を設定する設定部（Ｓ１２０）と、
   前記設定部によって設定された前記サービスの達成時期を基準として、要求されたサービスを達成するための繰り返し処理の実行スケジュールを定めるスケジュール設定部（Ｓ１３０）と、
   それぞれに分散配置され、連携して処理される前記繰り返し処理を、前記実行スケジュールに従って実行する複数の制御部（２４〜２６、４０〜４２）と、を備える車両用制御システム。
2. 前記スケジュール設定部は、前記サービスの達成時期を基準とする完了時期までに、前記繰り返し処理が完了するように実行スケジュールを定めることを特徴とする請求項１に記載の車両用制御システム。
3. 前記スケジュール設定部は、前記繰り返し処理の実行スケジュールとして、制御周期および制御開始時期を定めるものであり、
   前記複数の制御部は、少なくとも第１のサービスを達成するための第１の繰り返し処理と、第２のサービスを達成するための第２の繰り返し処理を同じ期間に実行可能なものであり、
   前記スケジュール設定部は、前記第１の繰り返し処理と前記第２の繰り返し処理との内、先に実行が開始された繰り返し処理の実行タイミングと、後に実行が開始される繰り返し処理の実行タイミングとが重ならないように、後に実行が開始される繰り返し処理の実行スケジュールを定める請求項２に記載の車両用制御システム。
4. 前記スケジュール設定部は、時間の経過とともに制御周期が変動する実行スケジュールを設定する請求項３に記載の車両用制御システム。
5. 前記スケジュール設定部は、後に実行が開始される繰り返し処理の制御周期を、先に実行が開始された繰り返し処理の制御周期に対して、整数倍もしくは１／整数倍に設定するとともに、後に実行が開始される繰り返し処理の制御周期の位相を、先に実行が開始された繰り返し処理の制御周期の位相に対してずらした実行スケジュールを定めることにより、それぞれの繰り返し処理の実行タイミングが重なることを防止する請求項３または４に記載の車両用制御システム。
6. 前記スケジュール設定部は、後に実行が開始される繰り返し処理の実行スケジュールを定める際、後に実行が開始される繰り返し処理の制御周期を基準とし、先に実行が開始された繰り返し処理の制御周期との間で整数倍もしくは１／整数倍との関係が満たされるように、先に実行が開始された繰り返し処理の制御周期を変更する請求項３または４に記載の車両用制御システム。
7. 前記第１の繰り返し処理および前記第２の繰り返し処理が、それぞれの完了時期までに完了されたか否かを判定する完了判定部（Ｓ１５０）と、
   前記完了判定部により、前記第１の繰り返し処理および前記第２の繰り返し処理の少なくとも一方の繰り返し処理が前記完了時期までに完了されなかったと判定されると、次回、前記スケジュール設定部が、前記完了時期までに完了しなかった繰り返し処理の実行スケジュールを定める際に、前記完了時期までに完了するように、前回の実行スケジュールとは異なる実行スケジュールを設定するように前記スケジュール設定部に指示する指示部（Ｓ１６０）と、を備えることを特徴とする請求項３乃至６のいずれか１項に記載の車両用制御システム。
8. 前記指示部は、前回の実行スケジュールとは異なる実行スケジュールとして、制御開始時期の前倒し、前記複数の制御部間の通信回数の間引き、および、前記第１の繰り返し処理と前記第２の繰り返し処理との処理順序の変更の、少なくとも１つを採り入れた実行スケジュールを設定するように前記スケジュール設定部に指示する請求項７に記載の車両用制御システム。
9. 前記複数の制御部における前記繰り返し処理の処理状況、および前記複数の制御部間における通信状況を監視する監視部（Ｓ３００）を備え、
   前記指示部は、前記監視部の監視結果に基づいて、実行スケジュールの変更内容を決定して、前記スケジュール設定部に指示する請求項７または８に記載の車両用制御システム。
10. 前記完了判定部は、前記監視部の監視結果に基づき、前記繰り返し処理が前記実行スケジュールに従って前記完了時期までに完了したか否かを判定する請求項９に記載の車両用制御システム。
11. 要求された前記サービスに対応する、車両の変化を検出する検出部を備え、
    前記完了判定部は、前記サービスの達成時期において、要求されたサービスに見合う車両の変化が生じているか否かを判定することにより、前記繰り返し処理が前記完了時期までに完了されたか否かを判定する請求項７乃至１０のいずれか１項に記載の車両用制御システム。
12. 前記設定部は、要求されたサービスを達成するための処理が１度の処理で済むイベント処理の達成時期も設定し、
    前記スケジュール設定部は、前記設定部によって設定された前記サービスの達成時期を基準として、イベント処理の完了時期および開始時期を含む実行スケジュールを設定する請求項１乃至１１のいずれか１項に記載の車両用制御システム。

Images