JP2009184633A - 車両制御システム - Google Patents

Abstract

【課題】互いに矛盾する複数の制御を実行しようとしてしまう不具合をより低減することのできる車両制御システムを提供する。
【解決手段】車両制御システム１は、複数の車載機器の動作制御を一元管理する統括制御装置としてナビＥＣＵ２０を備える。ナビＥＣＵ２０は、動作制御を実行する条件となるシナリオとそのシナリオが成立したときに実行すべきサービスが対応付けられたシナリオ判定テーブルを記憶保持する。ナビＥＣＵ２０は、自車両が置かれる状況及びシナリオ判定テーブルに基づいて複数のシナリオから１つを選択するとともに、選択したシナリオに対応するサービスを実行する。
【選択図】図３

Description

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

従来、車両制御システムとしては、例えば特許文献１に記載の技術が知られている。この文献に記載の技術では、車両制御システムは、ＥＴＣゲートに設置された予告アンテナから発せられる電波を利用して、ＥＴＣゲートが自車両の前方に設置されていることを検出する。車両制御システムは、ＥＴＣゲートが自車両の前方に設置されていることを検出すると、ＥＴＣゲートと車載機器との間で通行料徴収に係わる交信を実行することの可能な所定速度と自車両の走行速度とを比較する。そして、車両制御システムは、自車両の走行速度が所定速度よりも高いとき、減速処理を開始する。これにより、自車両がＥＴＣゲートを通過するとき、自車両の走行速度が適正な所定速度になる。このように、特定の単一の外部状況に応じた走行態様にて自車両を走行させる技術は公知である。
特開２００４−１４４０４９号公報

近年、車両制御システムに対して、様々な状況に応じた様々な車両制御を行うことが要望されている。

しかしながら、上記従来技術では、ＥＴＣゲートが自車両の前方に設置されているという特定の単一の外部状況に対して自車両の速度を制限する専用のアプリケーションが作製されていた。このように専用のアプリケーションを用いて上記要望に対応しようとすると、状況とその状況に応じた車両制御との組み合わせ毎に専用のアプリケーションを個別に作製しなければならず、組み合わせを全て考慮した車両制御システムを構築するには手間がかかってしまう。

特に近年、例えばナビゲーション装置とエンジンを協調させたり、ナビゲーション装置とブレーキを協調させたりする等、各種車載機器を互いに協調動作する複雑なアプリケーションが増大している。そのため、上記組み合わせ毎にアプリケーションを個別に開発し、その開発後、アプリケーション間で矛盾が生じないか等を確認する適合を行うことは難しく、車両制御システムに不具合が残される可能性が増大してしまう。
本発明は、こうした実情に鑑みてなされたものであって、その目的は、互いに矛盾する複数の制御を実行しようとしてしまう不具合をより低減することのできる車両制御システムを提供することにある。

こうした目的を達成するための請求項１に記載の発明は、一つまたは複数の予め設定された車載機器を制御する複数の従属制御装置と、その複数の従属制御装置へ動作内容を指示する統括制御装置とを備えた車両制御システムであって、前記統括制御装置は、機能実行条件と、その機能実行条件が成立したときに一つまたは複数の前記従属制御装置へ指示する動作内容とが対応づけられた対応関係を複数備えており、且つ、それら複数の対応関係が一つの機能実行判定テーブルにまとめられており、その機能実行判定テーブルに含まれている複数の対応関係のうち、機能実行条件が成立したいずれか一つの対応関係に基づいて、前記複数の従属制御装置に動作内容を指示することを特徴とする。

この構成によれば、車載機器を制御する複数の制御装置が従属制御装置とされて、統括制御装置によって統括されている。統括制御装置は、機能実行条件と、その機能実行条件が成立したときに従属制御装置へ指示する動作内容との対応関係を複数備えているが、その複数の対応関係を一つの機能判定テーブルにまとめており、機能実行判定テーブルに含まれている複数の対応関係のうち、機能実行条件が成立したいずれか一つの対応関係に基づいて、従属制御装置に動作内容を指示する。そのため、複数の機能実行条件が同時に成立して、それら成立した複数の機能実行条件に基づいて、同じ制御装置に対して互いに矛盾する複数の動作内容が指示されてしまう不具合を容易に抑制することができる。そして、このように不具合を容易に抑制できるようになる結果、車両制御システムの構築は、上記従来技術ほど手間がかからなくなる。

上記請求項１に記載の構成において、請求項２に記載の発明では、前記機能実行判定テーブルには、前記複数の対応関係毎に異なる優先度が付与されていることを特徴とする。これにより、優先度の高い機能実行条件に対応する動作内容が優先的に指示されることになるので、複数の機能実行条件が同時に成立する場合に、互いに矛盾する複数の動作内容が指示されてしまう不具合をより確実に防止できるようになる。

上記請求項１または２に記載の構成において、請求項３に記載の発明では、前記対応関係において前記従属制御装置へ指示する動作内容は、その従属制御装置が制御する車載機器の動作態様の制限させること指示するものであることを特徴とする。これにより、機能実行条件が成立する状況に応じて車載機器の動作態様を適切に制限することができるようになる。

なお、機能実行条件としてどのような条件を設けるかは任意である。例えば請求項４に記載の発明のように、機能実行条件は、自車両の位置情報、時刻情報、及び、自車両付近の走行環境のうち少なくとも１つを条件として含むこととしてもよい。

また、統括制御装置として、従属制御装置の他に別個の統括制御装置を自車両に搭載することとしてもよい。あるいは、請求項５に記載の発明のように、前記複数の従属制御装置のうちいずれか一つが前記統括制御装置を兼ねていることとしてもよい。これにより、自車両に搭載すべき制御装置の個数を低減することができるようになる。また、統括制御装置としては、たとえば、請求項６に記載の発明のように、自車両に搭載されるナビゲーション装置の制御装置を採用することができる。

以下、本発明に係る車両制御システムの一実施の形態について、図１〜図４を参照しつつ説明する。ただし、図面に基づく説明に先立ち、以下の説明で用いる「サービス」について説明する。

通常、車両には、複数の制御装置（ＥＣＵ：Electronic Control Unit）及び複数の車載機器が搭載される。各ＥＣＵは、車載機器を１つのみ制御することもあれば、複数の車載機器を制御することもある。換言すれば、車載機器は、単一のＥＣＵによって制御されることもあれば、複数のＥＣＵによって制御されることもある。そして、単一のＥＣＵがその制御対象である車載機器を制御することで、あるいは、複数のＥＣＵが各々の制御対象である車載機器を協調して制御することで、自車両の有意な機能が実現することとなる。

そこで、ＥＣＵの物理的な区分に係わらず、１つの有意な機能にまとめたものを「サービス」とする。後述するように、車両制御システムは、他の複数のＥＣＵよりも概念的に上位に位置付けられる統括ＥＣＵを備える。この統括ＥＣＵは、他の複数のＥＣＵ（以下、統括ＥＣＵ以外のＥＣＵをサブＥＣＵということもある）による車載機器の動作制御を一元管理する。これにより、一つまたは複数のサブＥＣＵが有する一つまたは複数の動作を一つの意味のある機能にまとめた概念である「サービス」を単位とした制御を行うことができる。

以下、図１（ａ）及び（ｂ）を参照して、本実施の形態のハードウエア構成について説明する。なお、図１（ａ）は、複数の制御装置間の接続態様を示すブロック図であり、図１（ｂ）は、ナビゲーション装置を示すブロック図である。

図１（ａ）に示されるように、また、既述したように、複数の制御装置（ＥＣＵ：Electronic Control Unit）が車両に搭載され、これら複数のＥＣＵによって複数の車載機器が制御される。車両制御システム１では、車載エンジンを制御するエンジンＥＣＵ１０ａ、ドアのロック制御やウインドウの開閉制御をするボデーＥＣＵ１０ｂ、運転者によるステアリング操作をアシストするパワーステアリングＥＣＵ（以下、パワステＥＣＵと記載）１０ｃ、及び、目的地への経路を運転者に案内したりオーディオ音量を管理したりするナビゲーション装置の制御装置であるナビゲーションＥＣＵ（以下、ナビＥＣＵと記載）２０が同一のバス１００に接続されている。なお、本実施の形態では、他の複数のＥＣＵ１０ａ〜１０ｃよりも上位に位置付けられる総括制御装置として、ナビＥＣＵ２０が採用されている。

ここで、エンジンＥＣＵ１０ａは、自車両に搭載された複数のセンサ（例えばスロットルバルブ開度センサ等）からバス１００を介してそれぞれ伝送された複数のセンサ出力値（例えばスロットルバルブ開度）に基づいて、車載エンジンのエンジン回転速度を制御する。同様に、エンジンＥＣＵ１０ａは、自車両に搭載された複数のセンサ（例えば車輪速センサ等）からバス１００を介してそれぞれ伝送された複数のセンサ出力値（例えば車輪速等）に基づいて、自車両を速度制御する。また、ボデーＥＣＵ１０ｂは、上記ナビＥＣＵ２０からバス１００を介して伝送されたサービス指令値に基づき、ドアロックコントロールモータ（図示略）を駆動制御し、自車両のドア（図示略）を施錠したり開錠したりする。同様に、また、ボデーＥＣＵ１０ｂは、上記ナビＥＣＵ２０からバス１００を介して伝送されたサービス指令値に基づき、パワーウインドウモータ（図示略）を駆動制御することで、自車両のパワーウインドウ（図示略）の開度を制御する。また、パワステＥＣＵ１０ｃは、上記ナビＥＣＵ２０からバス１００を介して伝送されたサービス指令値に基づき、電動パワーステアリング装置を制御することで、自車両の運転者によるステアリング操作をアシストする。なお、ナビＥＣＵ２０からバス１００を介して各ＥＣＵ１０ａ〜１０ｃに対し伝送される各サービス指令値（サービス制限値）については後述する。

また、図１（ｂ）に示されるように、車両制御システム１では、ＧＰＳ受信機３０、外部情報受信機４０、データ記憶部５０、表示装置６０、入力部７０、音声出力部８０及び通信部９０がそれぞれ上記ナビＥＣＵ２０に接続されている。

ここで、ＧＰＳ受信機３０は、当該車両制御システム１が搭載される自車両の位置情報や時刻情報を取得し、これら取得した情報をナビＥＣＵ２０に出力する。外部情報受信機４０は、例えば自車両が走行する地域の天気情報（特に雪情報）や、自車両付近を緊急車両が走行する旨の通知及び自車両付近で事故が生じた旨の通知等を取得し、取得した天気情報及び各種通知をナビＥＣＵ２０に出力する。なお、こうした通知等は、例えば緊急車両や基地局等から発せられる。データ記憶部５０は、例えば一般道、高速道路、住宅街及び通学路等、道路の属性に関する情報を含む地図データを記憶保持しており、これら地図情報及び道路属性情報をナビＥＣＵ２０に提供する。表示装置６０は、自車両の搭乗者に報知すべき情報がナビＥＣＵ２０から伝達されると、伝達された報知情報を画面上に表示する。入力部７０は、自車両の搭乗者から目的地等の情報が与えられると、接続されたナビＥＣＵ２０に対し各種指令を伝達する。音声出力部８０は、表示装置６０と同様に、自車両の搭乗者に報知すべき情報がナビＥＣＵ２０から伝達されると、伝達された報知情報を例えばスピーカ等から音声にて出力する。通信部９０は、バス１００（図示略）及びナビＥＣＵ２０間に介在しており、ナビＥＣＵ２０から伝達された各種サービス制限値等を各ＥＣＵ１０ａ〜１０ｃに対し伝送する。

ナビＥＣＵ２０は、経路計算部２０ａ、地図描画部２０ｂ及びシナリオ計算部２０ｃを内部に備える。経路計算部２０ａは、ＧＰＳ受信機３０から伝達される自車両の位置情報、入力部７０から入力された目的地情報及びデータ記憶部５０に記憶保持されている地図データに基づいて、自車両がたどるべき経路を計算する。そして、こうして計算された経路は、地図描画部２０ｂによって上記表示装置６０に表示される。また、シナリオ計算部２０ｃは、上記ＧＰＳ受信機によって取得された自車両の位置情報及び時刻情報、並びに、外部情報受信機４０によって取得された天気情報及び通知に基づき、自車両の置かれる状況を判断する。そして、シナリオ計算部２０ｃは、シナリオ判定テーブル及び自車両の置かれる状況に基づいて、複数のシナリオから１つを選択し、選択したシナリオに対応するサービスを制限あるいは制御する。

本実施の形態の車両制御システムの概念上の構成を図２に示す。この図２に示されるように、車両制御システム１は、車載エンジンの回転速度を制御するエンジン回転速度制御サービスＳＳ１、自車両の速度を制御する車両速度制御サービスＳＳ２、パワーウインドの開度を制御するパワーウインドウ開閉サービスＳＳ３、自車両の運転者によるステアリング操作を補助するパワーステアリング制御サービスＳＳ４、ステレオ音量を調節するオーディオ管理サービスＳＳ５、及び、ドアの開錠及び施錠をするドアロックサービスＳＳ６等々のサービスを備える。これら各種サービスＳＳ１〜ＳＳ６は、既述したように、各種ＥＣＵ１０ａ〜２０の物理的な区分に関係なく、１つの有意な機能に概念的にまとめられたものであり、シナリオ計算部２０ｃに通信部９０を介して接続されている。なお、サービスＳＳは、サービスＳＳ毎に、動作するＥＣＵ１０とそのＥＣＵ１０の動作内容とが予め定められたものである。従って、通信部９０は、サービスＳＳを行なうＥＣＵ１０とシナリオ計算部２０ｃを備えたナビＥＣＵ２０との間の通信を行うものである。

また、図２に示されるように、車両制御システム１は、時刻情報についての情報源Ｉ１及び位置情報についての情報源Ｉ２並びに外部からの通知についての通知源Ｉ３を備える。これら各種情報源Ｉ１〜Ｉ３もシナリオ計算部２０ｃに接続されている。ちなみに、時刻情報源Ｉ１及び位置情報源Ｉ２はＧＰＳ受信機３０に相当し、通知源Ｉ３は外部情報受信機４０に相当する。

こうしたシナリオ計算部２０ｃには、図３（ａ）にその一例を示すシナリオ判定テーブルが記憶保持されている。なお、このシナリオ判定テーブルは、請求項の機能実行判定テーブルに相当するものである。

次に、シナリオ判定テーブルについて説明する。図３（ａ）のシナリオ判定テーブルは、走行時に実行する各種「走行時シナリオ」を備えたものであり、この図３（ａ）に示されるシナリオ判定テーブルでは、各種走行時シナリオ毎に、互いに異なるシナリオＩＤ及び互いに異なるシナリオ優先度が付与されている。なお、ここでのシナリオ（すなわち走行時シナリオ）とは、シナリオ名に対応づけられたサービスＩＤにて特定される一つまたは複数のサービスを意味するが、この走行時シナリオを、搭乗時に実行する一連のサービスを意味する搭乗時シナリオなど、他のサービスと時系列的につなぎ合わせることによって、より包括的なシナリオを形成することができる。

また、シナリオ判定テーブルでは、各種走行時シナリオ毎に、自車両の走行位置に関する条件、自車両の走行時間帯に関する条件、自車両が走行する地域の天気に関する条件、及び、自車両周辺における状況に関する条件が設定されている。これらの条件が請求項の機能実行条件に相当する。さらに、シナリオ判定テーブルでは、各種走行時シナリオ毎に、実行あるいは制限すべきサービスに付与されたサービスＩＤが対応付けられている。

図３のシナリオ判定テーブルにおいて同じ列に含まれる情報を一組とするものが請求項の対応関係に相当するものであり、図３のテーブルは、自車両の走行位置が一般道路であるときの走行時シナリオである「通常走行シナリオ」、自車両の走行位置が高速道路であるときの走行時シナリオである「高速道路走行シナリオ」、自車両の走行位置が踏み切り前であるときの走行時シナリオである「踏み切り前走行シナリオ」、自車両の走行位置が雪山であるときの走行時シナリオである「雪山走行シナリオ」、自車両の走行位置が山道であるときの走行時シナリオである「山道走行シナリオ」、自車両の走行時間帯が通学時間帯であるとともに走行位置が通学路であるときの走行時シナリオである「通学路走行シナリオ」、自車両の走行時間帯が深夜帯であるとともに走行位置が住宅街であるときの走行時シナリオである「夜間住宅街走行シナリオ」、及び、自車両の周辺を緊急車両が走行するときの走行時シナリオである「緊急車両走行シナリオ」等々を備える。

そして、シナリオ計算部２０ｃは、上記各種情報源Ｉ１〜Ｉ３に基づき自車両の置かれる状況を判断するとともに、このシナリオ判定テーブルに基づき走行時シナリオを１つ選択する。なお、例えば「高速道路走行Ａシナリオ」、「高速道路走行Ｂシナリオ」、「高速道路Ｃシナリオ」及び「高速道路走行Ｄ」にそれぞれ設定される条件は同時に成立することがある。このように複数の条件が同時に成立する場合にあっては、シナリオ計算部２０ｃは、各種走行時シナリオ毎に付与された優先度の最も高い走行時シナリオを選択する。また、例えば「通常走行シナリオ」にはサービスＩＤが対応付けられていない。そのため、シナリオ計算部２０ｃが通常走行シナリオを選択した場合、対応付けられたサービスに対してサービス制限値が設けられない。

図３（ｂ）に、本実施の形態が有するサービス例を一覧にて示す。この図３（ｂ）に示されるように、互いに異なるサービスＩＤが各種サービス毎に付与されている。また、各種サービス毎に指令値あるいはサービス制限値が設けられている（図３（ｂ）では、サービス制限値とのみ表記）。例えばエンジン回転速度制御サービスではエンジン回転速度が制御対象とされており、選択される走行時シナリオに応じて、例えば１０００［ｒｐｍ］から４０００［ｒｐｍ］までの指令されたサービス制限値にエンジン回転速度は制限される。また、例えばパワーウインドウサービスではウインドウの開度が制御対象とされており、選択される走行時シナリオに応じて、例えば０（全開に相当）から１０（全閉に相当）までにおいて指定されたサービス指令値にウインドウの開度が制御される。なお、こうしたサービス制限値及びサービス指令値はシナリオ計算部２０ｃによって指定される。また、他のサービスについては重複する説明となるため割愛する。

以上のように構成された車両制御システムによって実行されるシナリオ選択処理の手順を図４に示す。なお、図４に示す一連の処理は、所定時間毎に繰り返し実行されている。

まず、シナリオ選択処理が実行開始されると、シナリオ計算部２０ｃは、ステップＳ１０の処理として、ＧＰＳ受信機３０（情報源Ｉ１及びＩ２）並びに外部情報受信機４０（通知源Ｉ３）を通じて、時刻情報及び自車両の位置情報並びに外部情報を取得する。そして、シナリオ計算部２０ｃは、取得した各種情報に基づき、自車両の置かれる状況を判断する。

ステップＳ１０の処理において各種情報を取得するとともに自車両の置かれる状況を判断すると、次に、シナリオ計算部２０ｃは、先の図３（ａ）に一例を示したシナリオ判定テーブルに基づいて、予め定められた複数のシナリオの中から１つを選択する。なお、シナリオに設定される条件は互いに競合することがあるため、競合する場合にあっては、シナリオ計算部２０ｃは、各種走行時シナリオ毎に付与された優先度の最も高い走行時シナリオを選択することは既述した通りである。

ステップＳ２０の処理においてシナリオを選択すると、シナリオ計算部２０ｃは、ステップＳ３０の判断処理として、シナリオに変更があるか否かを判断する。すなわち、今回選択したシナリオが前回選択したシナリオと同一か否かを判断する。

ここで、シナリオに変更がないと判断されるとき（ステップＳ３０の判断処理において「Ｎｏ」）、シナリオ計算部２０ｃはシナリオ選択処理をそのまま終了する。一方、シナリオに変更があると判断されるとき（ステップＳ３０の判断処理において「Ｙｅｓ」）、シナリオ計算部２０ｃは続くステップＳ４０の処理に移行する。

ステップＳ４０の処理では、シナリオ計算部２０ｃは、シナリオ判定テーブルに基づき、先のステップＳ２０の処理において選択されたシナリオに対応付けられたサービスを実行する。具体的には、シナリオ計算部２０ｃは、前回選択していたシナリオに対応付けられたサービスに対し、実行終了あるいは制限撤廃の旨の通知を出力する一方、今回選択したシナリオに対応付けられたサービスに対し、実行開始あるいは制限開始の旨通知を出力する。すなわち、シナリオ計算部２０ｃは、今回選択したシナリオに対応付けられたサービスに対し、上記サービス指令値あるいは上記サービス制限値を出力する。そして、これらサービス指令値あるいはサービス制限値に従って各種サービスが実行されることになる。

以下、シナリオ判定テーブル中の「踏み切り前走行シナリオ」が選択されたときの動作例について説明する。なお、当初、ナビＥＣＵ２０（正確にはシナリオ計算部２０ｃ）は、「通常走行シナリオ」を選択しているものとする。

ここで、自車両が踏み切りの手前例えば「３０ｍ」に達し、「踏み切り前走行シナリオ」の実行条件が成立したとする。このとき、シナリオ計算部２０ｃは、シナリオ判定テーブル（図３（ａ））に基づき、「通常走行シナリオ」から「踏み切り前走行シナリオ」へ選択するシナリオを変更する。

このようにシナリオが変更されると、シナリオ計算部２０ｃは、踏み切り前走行シナリオに対応付けられた車両速度制御サービスＳＳ２及びオーディオ管理サービスＳＳ５並びにパワーウインドウサービスＳＳ３を実行する。

具体的には、シナリオ計算部２０ｃは、車両速度制御サービスＳＳ２に対しサービス制限値（「３０ｋｍ／ｈ」）を出力する。これにより、自車両の運転者がアクセルを踏み込み車両速度を上げようとしたところで、サービス制限値以上の車両速度にならなくなる。また、シナリオ計算部２０ｃは、オーディオ音量管理サービスＳＳ５に対しサービス制限値「０（最低音量に相当）」を出力する。これにより、自車両の搭乗者がオーディオの音量を大きくしようとしたところで、最低音量以外の音量に設定することはできなくなる。また、シナリオ計算部２０ｃは、パワーウインドウサービスＳＳ３に対しサービス制限値「０（全開に相当）」を出力する。これにより、自車両の搭乗者がパワーウインドウを全閉にしようとしたところで、全開以外の開度に設定することはできなくなる。このように、踏み切り前という状況に応じて各種機能が制限されるため、踏み切り前の安全確認及び一時停止を補助することができるようになる。ちなみに、踏み切りを横断後にあっては、「踏み切り前走行シナリオ」から「通常走行シナリオ」へ選択するシナリオが変更され、各種機能に対する制限が解除されることになる。

以上説明したように、本実施の形態の車両制御システム１では、他のＥＣＵ１０ａ〜１０ｃよりも概念的に上位に位置付けられる統括ＥＣＵとしてナビＥＣＵ２０を採用するとともに、他のＥＣＵ１０ａ〜１０ｃによる車載機器の動作制御をナビＥＣＵ２０にて一元管理することとした。これにより、他の複数のＥＣＵ１０ａ〜１０ｃによる動作制御の矛盾が解消し、各種サービスＳＳ１〜ＳＳ６が実現されるようになる。そのため、自車両の置かれる様々な状況に応じたシナリオにて自車両を走行させるべく複数のサービスの追加変更を行ったとしても、追加変更されたサービスと既存のサービスとの間で矛盾が生じにくくなる。したがって、シナリオとサービスとの組み合わせを全て考慮した車両制御システムを構築するにあたり、上記従来技術ほど手間がかからなくなる。

なお、本発明に係る車両制御システムは、上記実施の形態にて例示した構成に限定されるものではなく、本発明の趣旨を逸脱しない範囲において、種々に変形して実施することが可能である。すなわち、上記実施の形態を適宜変更した例えば次の形態として実施することもできる。

上記実施の形態では、統括制御装置として、ナビゲーション装置の制御装置であるナビＥＣＵを採用していたが、これに限られず、統括制御装置として、例えばエンジンＥＣＵ１０ａやボデーＥＣＵ１０ｂ等を採用してもよい。

上記実施の形態（変形例を含む）では、統括制御装置として、制御対象とする車載機器を有するＥＣＵを採用していたがこれに限らない。他に例えば、制御対象とする車載機器を持たず、他の複数の制御装置を統括する単一の統括ＥＣＵを別個に備えることとしてもよい。

上記実施の形態（変形例を含む）では、先の図３（ｂ）に一覧にて示したサービスを備えていたが、これに限らない。サービスを追加変更することは任意である。同様に、上記実施の形態（変形例を含む）では、先の図３（ａ）に示したシナリオを備えていたが、これにも限らない。シナリオを追加変更することも任意である。

本発明に係る車両制御システムの一実施の形態について、（ａ）は、当該システムを構成する複数のＥＣＵの接続態様を示すブロック図。（ｂ）は、当該システムを構成するナビゲーション装置を示すブロック図。 本実施の形態の概念上の構成を示すブロック図。 （ａ）は、本実施の形態が有するシナリオ判定テーブルの一例を示す図。（ｂ）は、本実施の形態が有するサービス例を一覧にて示す図。 本実施の形態にて実行されるシナリオ判定処理についてその処理手順を示すフローチャート。

符号の説明

１…車両制御システム、１０ａ…エンジンＥＣＵ、１０ｂ…ボデーＥＣＵ、１０ｃ…パワステＥＣＵ、２０…ナビＥＣＵ（統括制御装置）、２０ａ…経路計算部、２０ｂ…地図描画部、２０ｃ…シナリオ計算部、３０…ＧＰＳ受信機（位置情報取得手段、時刻情報取得手段）、４０…外部情報受信機（通知受信手段）、５０…データ記憶部、６０…表示装置、７０…入力部、８０…音声出力部、９０…通信部、１００…車内ネットワーク。

Claims (6)

1. 一つまたは複数の予め設定された車載機器を制御する複数の従属制御装置と、その複数の従属制御装置へ動作内容を指示する統括制御装置とを備えた車両制御システムであって、
   前記統括制御装置は、
   機能実行条件と、その機能実行条件が成立したときに一つまたは複数の前記従属制御装置へ指示する動作内容とが対応づけられた対応関係を複数備えており、且つ、それら複数の対応関係が一つの機能実行判定テーブルにまとめられており、
   その機能実行判定テーブルに含まれている複数の対応関係のうち、機能実行条件が成立したいずれか一つの対応関係に基づいて、前記複数の従属制御装置に動作内容を指示することを特徴とする車両制御システム。
2. 前記機能実行判定テーブルには、前記複数の対応関係毎に異なる優先度が付与されていることを特徴とする請求項１に記載の車両制御システム。
3. 前記対応関係において前記従属制御装置へ指示する動作内容は、その従属制御装置が制御する車載機器の動作態様を制限させること指示するものであることを特徴とする請求項１または２に記載の車両制御システム。
4. 前記機能実行条件は、自車両の位置情報、時刻情報、及び、自車両付近の走行環境のうち少なくとも１つを条件として含むことを特徴とする請求項１〜３のいずれか一項に記載の車両制御システム。
5. 前記複数の従属制御装置のうちいずれか一つが前記統括制御装置を兼ねていることを特徴とする請求項１〜４のいずれか一項に記載の車両制御システム。
6. 前記統括制御装置は、自車両に搭載されるナビゲーション装置の制御装置であることを特徴とする請求項１〜５のいずれか一項に記載の車両制御システム。

Images