(58)【調査した分野】(Int.Cl.,DB名)
前記判定値演算処理は、障害事象が前記ドライバに与えるストレスが大きいほど、当該障害事象が通知され易くなるように、前記通知必要度又は前記閾値を演算するストレス事象判定処理を含むことを特徴とする請求項1乃至14の何れか1項に記載の車両用情報提供装置。
【発明の概要】
【発明が解決しようとする課題】
【0005】
ところで、走行ルート上の障害事象の通知を受けることが有益なのは自律走行車両に限られるものではない。例えば、この種の通知が一般の車両に提供されれば、その車両のドライバは、障害事象に遭遇する前にその存在を予知することができ、事前準備をすることができる。このため、特許文献1に記載の通知は、一般車両のドライバに提供することも考えられる。
【0006】
一方、車両のドライバは、有益な情報の通知は歓迎するが、無益な情報の通知には煩わしさを感じる。例えば、慣れ親しんだ通勤ルートの走行中に、いつもの合流点や立体交差でいちいち注意喚起の通知がなされれば、ドライバはその通知に煩わしさを感じる。
【0007】
特許文献1に記載のシステムは、自律走行が困難になるゾーンの接近を通知するシステムである。つまり、このシステムは、自律走行が困難になるものとして登録された全ての障害事象を常にドライバに通知するシステムである。このため、上記システムの手法を一般車両に適用した場合、車両のドライバには、既に目視確認が済んでいる事象や、経験的に予測ができている事象の通知が頻繁になされることになる。この点、特許文献1に記載のシステムは、一般車両への通知の提供に用いた場合、車両のドライバに煩わしさを感じさせ易いものであった。
【0008】
この発明は、上述のような課題を解決するためになされたもので、支援車両が遭遇する可能性のある障害事象のうち、支援車両のドライバに通知する必要度の高いものを選択して通知の対象とする車両用情報提供装置を提供することを目的とする。
【課題を解決するための手段】
【0009】
第1の発明は、上記の目的を達成するため、車両用情報提供装置であって、
交通情報データを記録する交通情報データベースと、
前記交通情報データを処理して、支援車両のドライバに通知を提供するデータ処理装置と、を備え、
前記データ処理装置は、
前記交通情報データに基づいて車両走行の障害となる障害事象を検出する事象検出処理と、
前記支援車両と遭遇する可能性のある障害事象を抽出する事象抽出処理と、
障害事象の夫々につき、通知必要度を演算する判定値演算処理と、
前記支援車両と遭遇する可能性があり、かつ、前記通知必要度が閾値を越える障害事象に関する通知を当該支援車両のドライバに提供する通知処理と、
を実行することを特徴とする
ことを特徴とする。
【0010】
また、第2の発明は、第1の発明において、前記データ処理装置は、情報提供車両から受信した交通情報データを前記交通情報データベースに記録する交通情報記録処理を実行することを特徴とする。
【0011】
また、第3の発明は、第2の発明において、前記交通情報データは、前記情報提供車両の位置情報と、前記情報提供車両の車両挙動情報と、を含むことを特徴とする。
【0012】
また、第4の発明は、第2又は第3の発明において、前記交通情報データは、前記情報提供車両の位置情報と、周辺状況を監視するために前記情報提供車両に搭載されている周辺監視センサの検出結果と、を含むことを特徴とする。
【0013】
また、第5の発明は、第1乃至第4の発明の何れかにおいて、前記判定値演算処理は、障害事象の発生頻度が低いほど、当該障害事象が通知され易くなるように、前記通知必要度又は前記閾値を演算する想定外事象判定処理を含むことを特徴とする。
【0014】
また、第6の発明は、第5の発明において、前記発生頻度は、一定期間内における前記障害事象の発生期間が短いほど低く認識されることを特徴とする。
【0015】
また、第7の発明は、第5の発明において、前記発生頻度は、前記障害事象の発生間隔が長いほど低く認識されることを特徴とする。
【0016】
また、第8の発明は、第1乃至第7の発明の何れかにおいて、前記判定値演算処理は、障害事象の発生確率が低いほど、当該障害事象が通知され易くなるように、前記通知必要度又は前記閾値を演算する想定外事象判定処理を含むことを特徴とする。
【0017】
また、第9の発明は、第8の発明において、複数状態を切り替えて実現する路上固定物の母集団が存在し、前記障害事象は、前記複数状態のうちの一つが実現されることにより発生し、前記発生確率は、前記路上固定物の夫々が前記障害事象を発生させる状態を実現する確率であることを特徴とする。
【0018】
また、第10の発明は、第9の発明において、支援車両のドライバの移動履歴を記録するドライバ情報データベースを備え、前記判定値演算処理は、前記移動履歴に基づいて、当該支援車両が走行中の場所への前記ドライバの来訪頻度を演算する来訪頻度判定処理を含み、前記想定外事象判定処理は、前記路上固定物の設置場所への当該ドライバの来訪頻度が低いほど、前記障害事象が通知され難くなるように前記通知必要度又は前記閾値を演算することを特徴とする。
【0019】
また、第11の発明は、第1乃至第7の発明の何れかにおいて、支援車両のドライバの移動履歴を記録するドライバ情報データベースを備え、前記判定値演算処理は、前記移動履歴に基づいて、前記ドライバの、当該支援車両が走行中の場所への来訪頻度を演算する来訪頻度判定処理を含み、当該ドライバの、前記障害事象の発生場所への来訪頻度が低いほど、当該障害事象が通知され易くなるように前記通知必要度又は前記閾値を演算することを特徴とする。
【0020】
また、第12の発明は、第11の発明において、前記来訪頻度判定処理は、前記ドライバの現在の時間帯における来訪頻度を演算し、前記判定値演算処理は、当該ドライバの現在の時間帯における来訪頻度に基づいて前記通知必要度又は前記閾値を演算することを特徴とする請求項11に記載の車両用情報提供装置。
【0021】
また、第13の発明は、第1乃至第12の発明の何れかにおいて、支援車両に対する障害事象に関する通知履歴を記録する通知履歴データベースを備え、前記通知処理は、同一の支援車両における同一の障害事象に関する通知の間隔を一定時間以上確保するための処理を含むことを特徴とする。
【0022】
また、第14の発明は、第1乃至第13の発明の何れかにおいて、支援車両のドライバの運転スキルに関わる情報を記録する運転スキルデータベースを備え、前記通知処理は、前記ドライバの運転スキルが高いほど、前記通知が前記ドライバに提供され難くするための処理を含むことを特徴とする。
【0023】
また、第15の発明は、第1乃至第14の発明の何れかにおいて、支援車両のドライバの、前記通知に関する設定を記録する設定データベースを備え、前記通知処理は、前記ドライバへの前記通知の提供され易さに、前記設定を反映させるための処理を含むことを特徴とする。
【0024】
また、第16の発明は、第1乃至第15の発明において、前記データ処理装置は、前記交通情報データに基づいて前記障害事象に関する確信度を演算する確信度演算処理を実行し、前記通知処理は、前記確信度が通知閾値を越える障害事象に関する通知を前記支援車両のドライバに提供することを特徴とする。
【0025】
また、第17の発明は、第1乃至第16の発明の何れかにおいて、前記判定値演算処理は、障害事象が前記ドライバに与えるストレスが大きいほど、当該障害事象が通知され易くなるように、前記通知必要度又は前記閾値を演算するストレス事象判定処理を含むことを特徴とする。
【0026】
また、第18の発明は、第17の発明において、支援車両のドライバの移動履歴を記録するドライバ情報データベースを備え、前記ストレス事象判定処理は、前記移動履歴に基づいて、前記ドライバの前記障害事象への遭遇頻度を演算する処理と、前記遭遇頻度が高いほど、当該障害事象が通知され難くなるように、前記通知必要度又は前記閾値を演算する処理と、を含むことを特徴とする。
【発明の効果】
【0027】
第1の発明によれば、交通情報データに基づいて検出される障害事象のうち、支援車両が遭遇する可能性が高く、かつ、通知必要度の高い障害事象を選択して、ドライバに通知することができる。ドライバは、自身の走行に無益な通知を受けると煩わしさを感じる。上記の通知によれば、そのような煩わしさをドライバに感じさせることなく、ドライバに、障害事象に対する準備を促すことができる。
【0028】
第2の発明によれば、データ処理装置は、情報提供車両から交通情報データを取得して交通情報データベースに記録することができる。支援車両に先行する位置を走行している情報提供車両は、支援車両の進行ルート上で生じている障害事象の情報をデータ処理装置に送信することができる。このため、データ処理装置は、支援車両が未だ遭遇していない障害事象に関する通知を、支援車両に提供することができる。
【0029】
第3の発明によれば、情報提供車両は、自車の位置情報と車両挙動情報とを、交通情報データとして送信する。データ処理装置は、情報提供車両の位置情報により障害事象の発生位置を知ることができ、また、回避行動等の車両挙動情報により、障害事象の発生を検知することができる。このため、本発明によれば、情報提供車両が遭遇した障害事象の情報を、リアルタイムで支援車両に通知することができる。
【0030】
第4の発明によれば、情報提供車両は、自車の位置情報と周辺監視センサの検出結果とを、交通情報データとして送信する。データ処理装置は、情報提供車両の位置情報により障害事象の発生位置を知ることができる。また、データ処理装置は、周辺監視センサの検出結果から情報提供車両の周辺に発生した事象を検知することができる。このため、本発明によれば、情報提供車両が遭遇した障害事象の詳細を、リアルタイムで支援車両に通知することができる。
【0031】
第5の発明によれば、発生頻度の低い障害事象を、支援車両のドライバに通知することができる。障害事象は、発生頻度が低いほど、ドライバにとって想定外な事象になり易い。本発明によれば、そのような想定外事象を選択してドライバに通知することができる。
【0032】
第6の発明によれば、特定の季節に限って現れる鹿などのように、一定期間内における発生期間が短い障害事象が発生頻度の低い障害事象と認識される。そして、本発明によれば、この種の障害事象が発生した場合に、支援車両のドライバに適切に注意を促すことができる。
【0033】
第7の発明によれば、路面に残された脱落タイヤなどのように、発生間隔の長い障害事象が発生頻度の低い障害事象と認識される。そして、本発明によれば、この種の障害事象が発生した場合に、支援車両のドライバに適切に注意を促すことができる。
【0034】
第8の発明によれば、極稀にしか赤信号とならない車両感応式信号機などのように、一定の頻度で発生はするがその発生確率が低い障害事象を、支援車両のドライバに通知することができる。発生確率が低い障害事象は、ドライバにとって想定外事象となり易い。本発明によれば、そのような想定外事象を選択してドライバに通知することができる。
【0035】
第9の発明によれば、信号機のように、複数状態を切り替えて実現する路上固定物であり、かつ、同種の路上固定物が母集団を形成しているものが、低い確率で発生させる障害事象を支援車両のドライバに通知することができる。母集団が存在することから、ドライバは、その路上固定物がある確率で障害事象を発生させることを予め理解している。一方で、特定の路上固定物が、低い確率でしか障害事象を発生させない場合は、その特性を知っているドライバは、その路上固定物が障害事象を発生させないという先入観を持つことがある。この場合、その路上固定物が低い確率で発生する障害事象は、ドライバにとって想定外事象となる。本発明によれば、そのような想定外事象を通知することで、ドライバの注意を適切に喚起することができる。
【0036】
第10の発明によれば、路上固定物が低確率の障害事象を発生させていても、その設置場所への来訪頻度が低いドライバには、その障害事象の通知が行われ難い。来訪頻度の低いドライバは、先入観に捕らわれることなく、その路上固定物が適当な確率で障害事象を発生させることを想定している。この場合、そのドライバは、障害事象の通知を受けることで煩わしさを感じ易い。本発明によれば、このような不都合の発生を適切に回避することができる。
【0037】
第11の発明によれば、障害事象の生じている場所へのドライバの来訪頻度が低いほど、そのドライバへの通知がされ易くなる。特定の場所に発生する障害事象は、来訪頻度の高いドライバにとっては想定内の事象となる。一方、そのような障害事象も、来訪頻度の低いドライバには想定外の事象となる。本発明によれば、個々のドライバの移動履歴を考慮したうえで、支援車両のドライバにとって想定外となる障害事象を適切に選択して通知を提供することができる。
【0038】
第12の発明によれば、障害事象の通知を提供するか否かを、ドライバの現在の時間帯における来訪頻度に基づいて判断することができる。特定の時間帯に発生する障害事象は、その時間帯における来訪頻度の高いドライバにとっては想定内の事象となる。一方、そのような障害事象も、その時間帯における来訪頻度の低いドライバには想定外の事象となる。本発明によれば、時間帯をも含めた個々のドライバの移動履歴を考慮したうえで、支援車両のドライバにとって想定外となる障害事象を適切に選択して通知を提供することができる。
【0039】
第13の発明によれば、同一の支援車両において、同一の障害事象に関する通知が短時間に繰り返されるのを避けることができる。ドライバは、既に通知を受けた障害事象について再度の通知を受けると煩わしさを感じる。本発明によれば、この種の煩わしさを適切に回避することができる。
【0040】
第14の発明によれば、運転スキルの高いドライバに、障害事象の通知が頻繁に行われてしまうのを防ぐことができる。運転スキルの高いドライバへの通知の必要性は、運転スキルの低いドライバへの通知の必要性に比して低い。本発明によれば、このような実情に沿って、支援車両のドライバに適切に障害事象の通知を提供することができる。
【0041】
第15の発明によれば、通知の提供され易さにドライバの好みを反映させることができる。
【0042】
第16の発明によれば、確信度の低い障害事象がドライバに通知されるのを避けることができる。このため、本発明によれば、通知の信頼度を高めることができる。
【0043】
第17の発明によれば、ドライバに強いストレスを与える障害事象を通知の対象とすることができる。通知を受けたドライバは事前準備をすることで障害事象に備えることができる。このため、本発明によれば、ドライバが感じるストレスを軽減することができる。
【0044】
第18の発明によれば、ドライバが頻繁に遭遇している障害事象についての通知は、提供され難くすることができる。一般的にドライバがストレスを感じ易い障害事象であっても、その事象に慣れているドライバには、さほどストレスを与えない場合がある。本発明によれば、このような場合に通知によってドライバが煩わしさを感じるのを適切に回避することができる。
【発明を実施するための形態】
【0046】
[本発明の実施形態の概要]
本発明の実施形態は、情報提供を介して車両のドライバを支援することを目的としている。以下、支援対象の車両を「支援車両」と称す。支援車両の進行ルート上では様々な事象が発生する。それらの事象の中には、煽り癖のある他車両や頻繁にブレーキを踏む癖のある他車両など、遭遇したドライバが強いストレスを感じるストレス事象、直前まで認知できない脱落タイヤのような想定外事象、或いは日常の出来事化している定常渋滞のような想定内事象が含まれる。
【0047】
支援情報の通知を受けるドライバは、一般に、有益な通知は歓迎するが、無益な通知には煩わしさを感じる。具体的には、上記の例の中では、ストレス事象及び想定外事象の通知はドライバに歓迎され易い。一方、想定内事象は、ドライバにとって既知であるため、その通知はドライバにとって煩わしいものになり易い。そこで、本発明の実施形態は、支援車両のドライバに通知する事象をストレス事象と想定外事象に絞り、想定内事象については通知事象から除外することとした。但し、ストレス事象と想定外事象はあくまで通知事象の一例である。通知の必要度が高い事象については、適宜通知事象に加えることができるものとする。
【0048】
図1は、本発明の実施形態における通知事象の概要を説明するための図である。
図1に示すように、本発明の実施形態において、通知事象は、ストレス事象と想定外事象とで構成される。以下、
図1と共に
図2及び
図3を参照して、通知事象の詳細について説明する。
【0049】
図2は、ストレス事象の具体例を説明するための図である。第1の具体例は「煽り車両」である。
(定義)「煽り車両」とは、車間距離を詰めて先行車を追い立てる煽り行為を頻繁に行っている車両を指す。
(判断根拠)個々の車両が「煽り車両」に該当するか否かは、煽り行為の履歴に基づいて判断することができる。また、個々の車両が煽り行為をしているか否かは、その車両と先行車の速度及び車間距離等から判断することができる。
(根拠データ)
煽り行為の判断は、個々の車両からの位置情報、速度情報、車間距離情報などのアップロードデータに基づいて行うことができる。
【0050】
第2の具体例は「低速マイペース車両」である。
(定義)「低速マイペース車両」とは、周囲又は後続の車両に比して明らかに低い速度で走行し続ける車両を指す。
(判断根拠)個々の車両が「低速マイペース車両」に該当するか否かは、律速行為、即ち、先行車両が存在しない状態で後続の車両集団の速度を律する行為の履歴に基づいて判断することができる。また、個々の車両が律速行為をしているか否かは、その車両と前後車両との車間距離、その車両の速度、及び周囲の車両又は車間距離が詰まるまでの後続車両との速度差、後続車両の数等に基づいて判断することができる。
(根拠データ)
律速行為の判断は、個々の車両からの位置情報、速度情報、車間距離情報などのアップロードデータに基づいて行うことができる。
【0051】
第3の具体例は「割り込み車両」である。
(定義)「割り込み車両」とは、走行中の車線に隣接する車線上の車両間に割り込む行為を頻繁に行っている車両を指す。
(判断根拠)個々の車両が「割り込み車両」に該当するか否かは、割り込み行為の履歴に基づいて判断することができる。また、個々の車両が割り込み行為をしているか否かは、その車両における車線変更操作や、隣接車線上の車両の挙動等から判断することができる。
(根拠データ)
車線変更操作は、個々の車両からの操舵情報、アクセル操作情報、ブレーキ操作情報、位置情報、速度情報などのアップロードデータに基づいて検知することができる。また、割り込みに伴う周辺車両の挙動は、個々の車両からの位置情報、車速情報、車間距離情報等のアップロードデータに基づいて検知することができる。
【0052】
第4の具体例は「高頻度ブレーキ車両」である。
(定義)「高頻度ブレーキ車両」とは、頻繁にブレーキ操作が行われる車両を指す。このような操作は、先行車との車間を詰めて走行する癖を持つドライバにより実行され易い。高頻度ブレーキ車両に後続すると、先行車のブレーキ操作に注意を払う必要が頻繁に生じ、ドライバはストレスを感じ易い。
(判断根拠)個々の車両が「高頻度ブレーキ車両」に該当するか否かは、その車両における操作履歴に基づいて判断することができる。より具体的には、その車両におけるブレーキ操作の頻度、ブレーキ操作がなされた際の速度、先行車両との車間距離等から判断することができる。
(根拠データ)
上記の判断は、個々の車両からの、ブレーキ操作情報、位置情報、速度情報、車間距離情報などのアップロードデータに基づいて行うことができる。
【0053】
第5の具体例は「マナー違反車両」である。
(定義)「マナー違反車両」とは、マナー違反行為を頻繁に繰り返す車両を指す。ここで、「マナー違反行為」とは、方向指示器による表示を伴わない右左折、路肩への停止、路肩からの発進などを指す。
(判断根拠)個々の車両が「マナー違反車両」に該当するか否かは、その車両におけるマナー違反行為の履歴に基づいて判断することができる。また、「マナー違反行為」は、個々の車両における方向指示器操作、右左折操作、路肩への停止操作、及び路肩からの発進操作等に基づいて検知することができる。
(根拠データ)
上記の検知は、個々の車両からの各種操作情報、位置情報、速度情報、車間距離情報等のアップロードデータに基づいて行うことができる。
【0054】
第6の具体例は「狭窄路」である。
(定義)「狭窄路」とは、道幅の狭まった道路を指す。ドライバは、狭窄路の入り口では道路幅員の減少によりストレスを感じ易い。また、狭窄路の走行中は、幅員に神経を払う必要からドライバはストレスを感じ易い。
(判断根拠)走行路が狭窄路に差し掛かるか否かは、道路の幅員又は幅員差に基づいて判断することができる。
(根拠データ)
上記の判断は、予め準備されている地図データに基づいて行うことができる。
【0055】
続いて、再び
図1を参照して、本発明の実施形態における「想定外事象」について説明する。本発明の実施形態において、「想定外事象」とは、ドライバにとって遭遇頻度が一定以下の障害事象を指す。遭遇頻度が一定以下となる事象は、
図1に示す通り3つのカテゴリ(I)、(II)、(III)に分類される。
【0056】
第1のカテゴリ(I)は、ドライバの来訪頻度が一定以下であるため、遭遇頻度が低くなる障害事象である。より具体的には、事象そのものは定常的に、又は頻繁に発生しているが、ドライバがその発生場所を滅多に訪問しない事象である。
【0057】
第2のカテゴリ(II)は、障害事象そのものの発生頻度が一定以下である事象である。カテゴリ(II)に属する事象は、更に、以下の二つに分類することができる。
(II-i)特定の時期に偏って発生する障害事象。換言すると、一定期間内の事象発生期間が閾値未満となる事象。例えば、特定の季節にのみ出現する季節の鹿などがこの分類に該当する。
(II-ii)一定期間内の事象発生回数が閾値未満である事象。又は、検出場所での前回からの経過時間が閾値以上である障害事象。例えば、高速道路の車線上に残された脱落タイヤなどがこの分類に該当する。
【0058】
第3のカテゴリ(III)は、出現頻度はさほど低くないが、出現確率が閾値未満である事象である。例えば、極稀にしか赤にならない信号機などがこのカテゴリに属する。
【0059】
図3は、想定外事象の具体例を説明するための図である。
図3では、想定外事象をその特性により4つに区分している。一つ目の区分は「常時事象」、即ち、特定の場所に常に存在する障害事象である。
(事象例)
見通しの利かないカーブの曲がり先に現れる減速ハンプ(hump)、或いは、同様のカーブの先に現れる慢性渋滞などがこの区分に属する。
(根拠データ)
これらの事象は、個々の車両や交通情報インフラストラクチャからのアップロードデータに基づいて検知することもできるが、常時事象であることから、その情報が登録された地図データに基づいて検知することもできる。以下、この種のデータをアップロードする車両及びインフラストラクチャを総称して「情報提供車両等」と称す。
(ドライバ事情)
常時事象は、それらの発生場所を生活圏としているドライバにとっては日常の出来事である。このため、支援の対象が生活圏ドライバである場合は、常時事象を想定内事象として取り扱うのが妥当である。一方、旅行の過程でその発生場所を訪れたようなドライバ、つまり、生活圏外ドライバにとっては、常時事象と雖も日常的な事象ではない。このため、本発明の実施形態では、常時事象を、生活圏外ドライバに対しては想定外事象として扱う。この取り扱いは、
図1におけるカテゴリ(I)に対応する。
【0060】
図3において、二つ目の区分は「時間帯事象」、つまり、特定の場所に特定の時間帯において定常的に表れる障害事象である。
(事象例)
日中であれば遠方からも容易に目視できるが夜間には認識し難い障害事象となる減速ハンプ、特定の場所に休日限定で表れる慢性渋滞、或いは、特定の場所に通勤時間帯に限って現れる慢性渋滞などがこの区分に該当する。
(根拠データ)
減速ハンプのように路上に固定された時間帯事象は、情報提供車両等からのアップロードデータ又はその情報が登録された地図データと時間の情報とに基づいて検知することができる。一方、慢性渋滞のような時間帯事象は、情報提供車両等からのアップロードデータに基づいて検知することができる。
(ドライバ事情)
時間帯事象は、その発生場所を生活圏とし、かつ、その発生時間帯が活動時間(その発生場所を訪れる時間)と重なっているドライバにとっては日常の出来事である。このため、時間帯事象の発生場所及び発生時間が、生活圏及び活動時間と重なっているドライバに関しては、時間帯事象を想定内事象とするのが妥当である。一方、上記の発生場所は生活圏内ではあるが、その発生時間が活動時間に重なっていないドライバにとっては、時間帯事象が日常の出来事にはならない。同様に、生活圏外ドライバにとっても、時間帯事象は日常の出来事にはならない。このため、本発明の実施形態は、活動時間外ドライバと生活圏外ドライバについてのみ、時間帯事象が想定外事象として扱う。この扱いは、
図1におけるカテゴリ(I)に対応する。
【0061】
図3に示す三つ目の区分は「低頻度事象」である。「低頻度事象」は、
図1に示すカテゴリ(II)に属する障害事象である。
(事象例)
特定の季節に集中的に現れる動物(典型的には鹿)、雪解け時期に集中して表れる路面のポットホール等がこの区分に属する(特に上述したカテゴリ(II-i)に属する)。また、路上停車中の故障車、高速道路上の脱落タイヤなどもこの区分に属する(特に、上述したカテゴリ(II-ii)に属する)。
(根拠データ)
低頻度事象に属する障害事象は、情報提供車両等からのアップロードデータに基づいて検知することができる。
(ドライバ事情)
低頻度事象は、如何なるドライバにとっても、日常の出来事にはならない。このため、本発明の実施形態では、全てのドライバについて低頻度事象が想定外事象として扱われる。
【0062】
図3に示す四つ目の区分は「低確率事象」である。「低確率事象」は、
図1に示すカテゴリ(III)に属する障害事象である。低確率事象は、より具体的には、特定の場所に設置された路上固定物において、極めて低い確率で実現される障害事象を指している。この路上固定物は、多数の同種物からなる母集団に属している。母集団に属する路上固定物は、夫々、複数の状態を切り換えて実現するように動作する。そして、それら複数の状態のうちの一つが車両の走行を妨げる障害事象となる。母集団に属する多数の固体が同様に機能することから、ドライバは、それらの固体がある確率で障害事象を発生させることを認識している。このような状況の下で、特定の路上固定物だけが、他の個体に比して著しく低い確率で障害事象を発生させるように動作していると、その動作に慣れたドライバは、その路上固定物は障害事象を発生させないであろうという先入観を持つようになる。このような状況が形成されると、そのドライバにとっては、その路上固定物が発生する障害事象が、想定外事象となる。
(事象例)
幹線道路に設置され、極稀にしか赤信号を表示しない車両感応式の信号機等がこの区分に属する。
(根拠データ)
低確率事象に属する障害事象は、情報提供車両等(路上固定物そのものを含む)からのアップロードデータに基づいて検知することができる。
(ドライバ事情)
低確率事象は、特定の路上固定物が極稀にしか障害事象を発生しないとの先入観を持つドライバにとって想定外事象となる。換言すると、そのような先入観を持っていない生活圏外ドライバにとっては、低確率事象が想定内事象となることがある。このため、本発明の実施形態は、生活圏ドライバについては低確率事象を想定外事象として扱い、生活圏外ドライバに関しては、低確率事象を想定外事象から外して取り扱うことがある。
【0063】
実施の形態1.
[実施の形態1の構成]
図4は、本発明の実施の形態1の車両用情報提供装置の構成を説明するための図である。
図4に示すように、本実施形態のシステムは、情報提供車両10を含んでいる。
図4には便宜上、情報提供車両10を1台のみ表しているが、実用上は、多数の情報提供車両10が存在するものとする。本システムにおいて、情報提供車両10は、路上で発生する様々な情報の供給源としての役割を果たす。図示を省略するが、本システムの情報供給源は、情報提供車両10の他に、交通量を検知するセンサや監視カメラなど、交通情報を取得し得る様々なインフラストラクチャを含むものとする。以下、情報提供車両10とそれらのインフラストラクチャを総称する場合には、「情報提供車両等」と称することとする。
【0064】
情報提供車両10は、車両情報部12を備えている。車両情報部12は、情報提供車両10に関わる様々な情報を取得する部分である。車両情報部12は、自律センサ部14を備えている。自律センサ部14は、情報提供車両10の自律走行に必要な情報を検出するための周辺監視センサを備えている。具体的には、自律センサ部14は、ミリ波レーダ、レーザレーダ、車載カメラ等の周辺監視センサを備えている。ミリ波レーダ、レーザレーダによれば、他車両を含む物体の存在、並びにその物体までの距離等を検知することができる。また、車載カメラによれば、路上の白線、歩行者、自転車等を認識することができる。
【0065】
車両情報部12は、車両挙動部16を備えている。車両挙動部16は、情報提供車両10の挙動を検出するための各種センサを備えている。車両挙動部16は、例えば、速度、加速度、ヨーレート、アクセル開度、ブレーキ油圧、操舵角、操舵角速度等を検出することができる。
【0066】
車両情報部12は、また、位置情報部18を備えている。位置情報部18は、GPS(Global Positioning System)装置を備えている。位置情報部18によれば、情報提供車両の位置を検知することができる。
【0067】
車両情報部12は更に、ドライバ情報部20を備えている。ドライバ情報部20には、ドライバから運転スキルの申告を受ける入力インターフェース、或いはドライバの運転スキルを診断するユニットが含まれている。ここで、ドライバの運転スキルは、例えば、車両の加加速度(Jerk)、即ち、加速度aの微分値da/dtに基づいて、周知の方法で判断することができる。また、ドライバ情報部20には、ドライバからの各種設定又は要望を受け付ける入力インターフェースも含まれている。
【0068】
車両情報部12において検出される各種の車両情報は、通信部22に供給される。通信部22は、それらの車両情報をアップロードするための通信機能を備えている。
【0069】
本実施形態のシステムは、上述した情報提供車両10に加えて、支援車両24を含んでいる。支援車両24は、当該車両24の情報を検知するための車両情報部26を備えている。本実施形態において、支援車両24の車両情報部26は、自律センサ部28、車両挙動部30、及び位置情報部32を備えている。これらの機能は、情報提供車両10に搭載されているものと同様であるため、ここでは重複した説明は省略する。
【0070】
支援車両24は、車両情報部26から検出情報の供給を受ける通信部34を備えている。通信部34は、車両情報部26から受け取った各種の検出情報を外部にアップロードするための車両情報アップロード部36を有している。また、通信部34には、支援車両24の外部から供給される支援内容を受信するための支援内容受信部38が備わっている。
【0071】
支援内容受信部38が外部から受け取る支援内容には、回避制御指令と通知指令とが含まれている。回避制御指令は、支援車両24の制御部40に供給される。制御部40は、回避制御指令を受けて各種の回避制御を実現する機能を有している。ここで、回避制御とは、各輪の駆動力又は制動力、或いは操舵角等を制御して、支援車両24に障害事象を回避させる行動を取らせる制御を指している。
【0072】
支援内容受信部38から発せられる通知指令は、車両HMI(Human Machine Interface)部42に供給される。車両HMI部42は、指令された通知を支援車両24のドライバに通知するためのインターフェースである。車両HMI部42では、具体的には、表示、音、又は音声によりその通知をドライバに提供するための表示/音/音声制御が実行される。
【0073】
本実施形態のシステムは、また、情報提供車両等及び支援車両24からのアップロードデータを処理して、支援内容を支援車両24に提供するセンター44を含んでいる。センターは、各種の記憶装置、演算装置、入出力インターフェース、通信装置等により構成されている。
【0074】
具体的には、センター44は、情報提供車両等からのアップロードデータを受信する通信部46を備えている。通信部46が受信したデータは、交通情報データベース48に記録される。交通情報データベース48には、以下の二種類の交通情報データがアップロードされる。
1.情報提供車両10のドライバに関わるデータ
(内容)・自己申告された又は診断された運転スキル。
・ドライバの設定又は要望。
2.障害事象に関わるデータ
(内容)・車載カメラの映像等に基づき存在と内容が特定された事象を表す事象データ。
・情報提供車両の車両挙動、ミリ波レーダの計測結果等、事象の存在と内容を判断するための基礎データ。
・情報の発生場所を示す位置情報。
【0075】
交通情報データベース48に蓄積されたデータは、センター44が備える事象検出部50に供給される。事象検出部50は、上記2.「障害事象に関わるデータ」に基づいて以下の処理を行う。
(1)上記「事象データ」に基づいて障害事象を検出。
(2)上記「基礎データ」に基づいて障害事象と推定できる事象を検出(以下、この事象も「障害事象」と称す)。
(3)上記「位置情報」に基づいて、上記(1)、(2)のステップで検出された障害事象の位置を特定。
【0076】
事象検出部50には、通信部52を介して支援車両24の位置情報も提供される。事象検出部50は、この位置情報に基づいて、更に下記の処理も実行する。
(4)支援車両24の進行ルートを推定。
(5)上記(3)のステップで位置が特定された障害事象の中から上記(4)のステップで推定された進行ルート上に存在するものを抽出。
【0077】
事象検出部50は、上記(1)〜(5)の処理を行うことにより、支援車両24が今後遭遇する可能性の高い障害事象を検出することができる。
【0078】
事象検出部50によって検出された障害事象のデータは、想定外事象判定部54に供給される。想定外事象判定部54では、その障害事象が想定外事象に該当するか否かを判断するべく頻度判定処理と確率判定処理とが実行される。頻度判定処理では、事象検出部50で検出された事象が発生頻度の低い事象、つまり、
図1に示すカテゴリ(II)に属する事象、換言すると、
図3に示す「低頻度事象」に該当するか否かが判定される。一方、確率判定処理では、事象検出部50で検出された事象が出現確率の低い事象、つまり、
図1に示すカテゴリ(III)に属する事象、換言すると、
図3に示す「低確率事象」に該当するか否かが判定される。
【0079】
センター44には、障害事象に関する多数のデータが記録されている。また、センター44には、障害事象毎に低頻度事象を判断するための閾値、並びに低確率事象を判定するための閾値が記憶されている。これらの閾値は、一般的なドライバが、判定対象の事象を想定外と感ずる発生頻度の下限値、又は出現確率の下限値である。想定外事象判定部54は、多数のデータを分析することで、判定の対象である障害事象の発生頻度、及び出現確率を算出し、それらを上記の閾値と比較することにより、頻度判定処理及び確率判定処理を実行する。
【0080】
事象検出部50によって検出された障害事象のデータは、ストレス事象判定部56にも供給される。ストレス事象判定部56には、通信部58を介して、支援車両24からのアップロードデータも供給されている。ストレス事象判定部56は、事象検出部50で検出された事象が、支援車両24にとってのストレス事象(
図1及び
図2参照)に該当するか否かを判定するストレス度判定処理を行う。
【0081】
センター44には、障害事象毎にストレス度を算出する各種規則(マップ等)が記憶されている。例えば、「煽り車両」については、当該車両が煽り行為を行う頻度、その煽りの程度(速度、車間距離で計算)、及びその車両と支援車両24との距離等に基づいてストレス度を算出する規則が記憶されている。低速マイペース車両や割り込み車両についても、それらの車両が障害行為を行う頻度、障害の程度、その車両と支援車両24との距離等をパラメータとしてストレス度を算出する規則が記憶されている。また、狭窄路のような路上固定物については、道路の幅員、道幅が変化する箇所の幅員差、ガードレールの有無等の地図データからストレス度を算出する規則が記憶されている。センター44には更に、一般的なドライバが耐え難いと感ずるストレス度の下限値が、閾値として記録されている。ストレス事象判定部56は、夫々の事象についてストレス度を算出し、そのストレス度と上記閾値とを比較することによりストレス度判定処理を実行する。
【0082】
想定外事象判定部54で想定外事象と判定された事象のデータ、並びにストレス事象判定部56でストレス事象と判定された事象のデータは、通知判断部60に送られる。通知判断部60では、それらの事象を支援車両24のドライバに通知するか否かを最終判断するための処理が行われる。
【0083】
センター44には、幾つかの障害事象、或いは全ての障害事象について、非通知条件が記憶されている。例えば、タイヤ等の落下物については、先行車が存在しなければ、事前準備に十分な距離だけ離れている段階で、ドライバはその事象を認識することができる。このため、タイヤ等の落下物に関しては、「支援車両24に先行車なし」が非通知条件として定められている。通知判断部60は、想定外事象又はストレス事象と判断された事象毎に、それらの事象についての非通知条件を判断する。そして、判断の対象である事象について、非通知条件が充足されていない場合は、その事象に関する通知指令、及び、必要であれば、その事象の回避を支援するための回避制御指令を発する。
【0084】
通知判断部60から発せられた通知指令及び回避制御指令は、通信部62を介して、支援車両24の支援内容受信部38に供給される。これらの指令を受けると、支援車両24において、想定外事象又はストレス事象を予告する通知がなされ、また、必要であれば、それらの事象を回避するための回避制御が実行される。
【0085】
[実施の形態1の動作]
図5は、本発明の実施の形態1において、センター44で実施される処理の概要を説明するためのフローチャートである。但し、情報提供車両等からのアップロードデータを交通情報データベース48に記録する処理は、
図5に示すルーチンとは別に適宜実行されるものとする。
【0086】
図5に示すルーチンでは、まず、障害事象の検出処理が実行される(ステップ100)。ここでは、具体的には、交通情報データベース48に記録されているデータに基づいて、想定外事象又はストレス事象となり得る事象が検出される。本ステップの処理は、
図4に示す事象検出部50が実行する上記(1)及び(2)の処理に相当する。
【0087】
障害事象となり得る事象が検出されると、次に、支援車両24が、その障害事象に遭遇する可能性があるか否かが判別される(ステップ102)。具体的には、先ず、交通情報データベース48に記録されている位置情報に基づいて障害事象の位置が特定される。次いで、支援車両24からのアップロードデータに基づいて、支援車両24の進行ルートが推定される。そして、障害事象の発生場所が、支援車両24の進行ルートと重なる可能性があれば、本ステップ102の判断が肯定される。以上の処理は、
図4に示す事象検出部50が実行する上記(3)乃至(5)の処理に相当する。
【0088】
上記の判断が否定された場合は、本サイクルの処理が終了され、改めて上記ステップ100の処理が開始される。一方、本サイクルで検出された障害事象に支援車両24が遭遇する可能性があると判断された場合は、次に、想定外事象判定部54及びストレス事象判定部56の処理が実行される(ステップ104)。
【0089】
図6は、上記ステップ104の詳細を説明するためのフローチャートである。ステップ104では、本サイクルで検出された障害事象が、ドライバに通知するべき想定外事象又はストレス事象に該当するか否かが判定される。
図6に示すように、ここでは先ず、判定対象の障害事象についてストレス度が決定される(ステップ104−1)。上述した通り、センター44には、ストレス度を定めるための各種規則(マップ等)が障害事象毎に記憶されている。ここでは、その規則に従って、障害事象のストレス度が決定される。
【0090】
上記の処理が終わると、次に、決定されたストレス度が通知を判定するための閾値を越えているか否かが判別される(ステップ104−2)。上述した通り、センター44には、障害事象毎にストレス度に関する閾値が記憶されている。本ステップでは、判定対象の障害事象に対応する閾値と、上記のストレス度とが比較される。
【0091】
ストレス度が閾値を越えていると判別された場合は、判定対象の障害事象が、ドライバに通知するべきストレス事象に当たると判断できる。この場合は、次に、そのストレス事象に関する情報をドライバに提供するかについての最終判断が行われる(ステップ106)。この処理は、
図4に示す通知判断部60における処理に相当する。つまり、ここでは、判定対象の障害事象に関する非通知条件が充足されていないかが判断される。その結果、非通知条件が充足されていれば、今回の障害事象についての最終判断は「非通知」となる。一方、非通知条件が充足されていなければ、以後、そのストレス事象をドライバに通知するための処理が実行される。
【0092】
上記ステップ104−2で、今回の障害事象のストレス度が閾値を越えていないと判別された場合は、次に、その事象が低頻度事象の第1条件、即ち、「一定期間内の事象発生期間が閾値未満」の条件を満たしているか否かが判別される(ステップ104−3)。センター44では、蓄積された多数のデータに基づいて、障害事象の発生時期に関する統計処理が行われている。ここで、上記の「一定期間」は、一年、一月、一週間等の期間を指している。また、上記「閾値」は、それらの期間に対応して定められた値であり、それらの期間に比して十分に短い期間である。本ステップでは、今回の障害事象が、一定期間内の特定の季節、期間、時間等に限って発生するものである場合に上記第1条件の成立が判定される。
【0093】
上記第1条件の成立が認められた場合は、今回の障害事象が、ドライバに通知するべき低頻度事象であると判別できる。この場合、以後、ステップ106の処理が実行される。一方、上記第1条件が成立しないと判別された場合は、次に、今回の障害事象が低確率事象の条件を満たしているか否かが判別される(ステップ104−4)。具体的には、先ず、今回の障害事象が、同種の固体の集合である母集団に属する路上固定物で生じているものであるか否かが判断される。この判断が肯定される場合は、次に、その路上固定物が今回の障害事象を発生させる確率が閾値未満であるかが判別される。この閾値は、ドライバが一般的に、その路上固定物は障害事象をほぼ発生させない、との先入観を持つに至る確率の上限値であり、例えば、10%、5%、3%、或いは1%のような数値がこれに該当する。
【0094】
上記ステップ104−4の判別が肯定された場合は、今回の障害事象が、ドライバに通知するべき低確率事象であると判別できる。この場合、以後、ステップ106の処理が実行される。一方、上記の判別が否定された場合は、次に、今回の障害事象が低頻度事象の第2条件、即ち、「一定期間内の事象発生回数が閾値未満」の条件を満たしているか否かが判別される(ステップ104−5)。センター44では、蓄積された多数のデータに基づいて、障害事象の発生回数に関する統計処理が行われている。「一定期間」は、ここでも、一年、一月、一週間等の期間を指す。また、上記「閾値」は、それらの期間に対応して定められた値であり、数回から1回程度の値が該当する。本ステップでは、今回の障害事象が、日常的に発生するものでない事象である場合に上記第2条件の成立が判定される。
【0095】
上記ステップ104−5の判別が肯定された場合は、今回の障害事象が、ドライバに通知するべき低頻度事象であると判別できる。この場合、以後、ステップ106の処理が実行される。一方、上記の判別が否定された場合は、次に、今回の障害事象が低頻度事象の第3条件、即ち、「検出された場所での前回からの経過時間が閾値以上」の条件を満たしているか否かが判別される(ステップ104−6)。センター44では、個々の障害事象について、発生場所と発生日時を記録している。ここでは、それらの記録に基づいて上記判断がなされる。本ステップの「閾値」は、例えば、数年、1年、1月等に設定することができる。
【0096】
上記ステップ104−6の判別が肯定された場合は、今回の障害事象が、ドライバに通知するべき低頻度事象であると判別できる。この場合、以後、ステップ106の処理が実行される。一方、上記の判別が否定された場合は、今回の障害事象が、ドライバに通知するべき事象ではないと判断できる。この場合、センター44は、非通知の最終判断を下して今回の処理を終了する。
【0097】
再び
図5を参照して、ステップ106以降の処理について説明する。ステップ106において、今回の事象をドライバに通知することが決定されると、次に、支援車両24に提供する指令の内容、及びその指令を提供するタイミングが決定される(ステップ108)。センター44には、障害事象毎に、支援車両24に提供するべき通知の内容(メッセージ等)と、回避制御の内容が記憶されている。ここでは、今回の障害事象についての通知及び回避制御の内容が特定される。また、通知のタイミングは、支援車両24が現実に障害事象に遭遇する時点から適切な時間だけ遡った時間に設定する必要がある。ここでは、現在地と障害事象との距離、並びに支援車両24の速度等に基づいて、通知を発するべき適切なタイミングが決定される。
【0098】
上記の処理が終わると、情報提供のタイミングが到来するまで、その判定処理が繰り返される(ステップ110)。そして、そのタイミングの到来が判定されると、センター44から支援車両24に向けて通知及び回避制御に必要な情報が提供される(ステップ112)。以後、センター44は、支援に必要な全ての処理が完了するのを待って(ステップ114)、今回の処理サイクルを終了する。
【0099】
以上説明した通り、本実施形態のシステムによれば、支援車両24に対して、ドライバが有益と感じる障害事象の情報だけを適切に通知することができる。このため、このシステムによれば、支援車両24のドライバに煩わしさを感じさせることなく、そのドライバに、安全走行を継続するうえで有益な通知を提供することができる。
【0100】
尚、上記の説明では、ステップ100〜ステップ114の処理を直列に進めることとしているが、処理の進め方はこれに限るものではない。これらの処理は、ハードウェアの仕様に応じて、適宜順番を入れ替えて、又は、並列して進めることとしてもよい。
【0101】
[実施の形態1の変形例]
上述した実施の形態1において、事象検出部50は、先ず障害事象を検出し、検出された事象の中から、支援車両24の進行ルート上に存在する事象を抽出している。しかしながら、その実行の順番はこれに限るものではない。事象検出部50は、先ず、支援車両24の進行ルート上からアップロードされてきたデータを抽出し、次に、そのデータを解析して障害事象を検知することとしてもよい。
【0102】
また、上述した実施の形態1では、障害事象の種類毎に閾値を設定し、障害事象夫々の発生頻度、出現確率、ストレス度等をその閾値を比較して事象の判定処理を行っている。しかしながら、判定処理の手法はこれに限定されるものではない。例えば、障害事象の種類毎に通知必要度を設定し、障害事象夫々の発生頻度、出現確率、ストレス度等に基づいて閾値を変化させることとしてもよい。
【0103】
また、上述した実施の形態1では、個々の障害事象に関する通知の内容と回避制御の内容を、センター44から支援車両24に提供することとしている。しかしながら、センター44から支援車両24に情報を提供する手法はこれに限定されるものではない。例えば、センター44から支援車両24へは、障害事象の内容だけを提供し、その事象に対する通知の内容と回避制御の内容は、支援車両24側で決定することとしてもよい。
【0104】
また、上述した実施の形態1では、通知のタイミングをセンター44が計ることとしているが、その手法はこれに限定されるものではない。即ち、
図5に示すステップ108以降の処理は、支援車両24側で実行することとしてもよい。更に、実施の形態1では全ての情報をセンター44のデータベースに集めることとしているが、情報の保管手法はこれに限るものではない。例えば、一部の情報については、車両内に保持することとしてもよい。
【0105】
ところで、上述した実施の形態1では、障害事象の発生頻度、出現確率、及びストレス度が、前記第1の発明における「通知必要度」に相当している。また、実施の形態1では、センター44が備える演算装置、記憶装置、及び通信装置等が前記第1の発明における「データ処理装置」を構成している。
【0106】
実施の形態2.
[実施の形態2の構成]
図7は、本発明の実施の形態2の構成を説明するための図である。以下、
図7において、
図4に示す要素と同一の要素には同一の符号を付してその説明を省略する。本実施形態において、支援車両24の車両情報部26は、ドライバ情報部64を備えている。ドライバ情報部64には、情報提供車両10のドライバ情報部20と同様に、運転スキルの申告を受ける入力インターフェース又は運転スキルの診断ユニット、及び設定又は要望を受け付ける入力インターフェースが含まれている。
【0107】
ドライバ情報部64の情報は、通信部66を介してセンター44にアップロードされる。センター44は、その情報を受け取るための通信部68と、その情報を保管するためのドライバ情報データベース70を備えている。
【0108】
ドライバ情報データベース70には、支援車両24の移動履歴が記録される。移動履歴には、車両走行時の位置及び時間に関する履歴が含まれている。このデータベース70には、また、システム稼動履歴が含まれている。システム稼動履歴には、支援車両24に提供した障害事象に関する通知及び回避制御の内容、並びにそれらを提供した日時等の情報が含まれている。更に、ドライバ情報データベース70には、ドライバ特性が含まれている。この特性には、支援車両24のドライバによる各種の設定及び要望、並びにそのドライバの運転スキルに関する情報等が含まれている。
【0109】
ドライバ情報データベースに記録されている移動履歴の情報は、来訪頻度判定部72に供給される。来訪頻度判定部72には、事象検出部50によって検出された障害事象、即ち、想定外事象及びストレス事象となり得る事象の情報も提供されている。来訪頻度判定部72は、それらの事象の中から、来訪頻度が低いことによりドライバにとって想定外事象となる事象を抽出する。
【0110】
来訪頻度判定部72によって抽出される事象は、具体的には、
図3に示す「常時事象」及び「時間帯事象」となる。これらの事象は、比較的頻繁に生ずる事象であることから、低頻度事象にも、低確率事象にも該当せず、想定外事象判定部54によっては通知事象として抽出されないことがある。来訪頻度判定部72は、判定対象の「常時事象」又は「時間帯事象」の発生場所が支援車両24のドライバの生活圏外である場合は、その事象を想定外事象として抽出する。また、来訪頻度判定部72は、判定対象の「時間帯事象」が支援車両24の活動時間外に生ずる事象である場合は、その発生場所がドライバの生活圏内であってもその事象を想定外事象として抽出する(
図3中に(I)を付して示す欄参照)。
【0111】
図7において、ドライバ情報データベース70が記憶する移動履歴の情報は、来訪頻度判定部72のみに供給されているが、この情報は、想定外事象判定部54に供給することとしてもよい。想定外事象判定部54では、上述した通り、低確率事象が想定外事象として抽出される。この低確率事象は、特定の路上固定物が極めて低い確率でしか障害事象を発生しないとの先入観を持ったドライバにとって想定外事象となる事象である。換言すると、そのような先入観を持たないドライバにとって、低確率事象は想定内の障害事象である。そして、低確率事象を生じさせる路上固定物の設置位置が生活圏外であるドライバは、その路上固定物の特性を知らないため、上記のような先入観を有しない。このため、本実施形態において、想定外事象判定部54は、低確率事象として検出された事象の発生場所が、支援車両24のドライバの生活圏外である場合には、その事象を想定外事象から除外することとしてもよい(
図3の右下角欄に示す「想定内」参照)。
【0112】
来訪頻度判定部72によって抽出された想定外事象は、想定外事象判定部54及びストレス事象判定部56によって抽出された事象と共に通知判断部60に供給される。本実施形態において、通知判断部60には、ドライバ情報データベース70に記録されているシステム稼動履歴、及びドライバの特性に関する情報が提供される。
【0113】
通知判断部60は、想定外事象判定部54等から提供された事象が、支援車両24に通知された履歴があるかを、システム稼動履歴に基づいて判断する。その結果、通知の履歴があると判断された場合は、更に、その通知から現在までの経過時間を算出する。そして、その経過時間が、予め定めた閾値に達していない場合は、当該事象を非通知の扱いとする。この処理が実行されることにより、本実施形態のシステムでは、同一の障害事象についての通知が支援車両24のドライバに短時間のうちに繰り返し提供されてしまうのを回避することができる。
【0114】
通知判断部60は、また、ドライバ情報データベース70に記録されているドライバ特性、即ち、ドライバによる各種設定及び要望、並びにドライバの運転スキルに基づいて、通知の可否を最終判断する際の閾値を変化させることができる。来訪頻度判定部72によって抽出される想定外事象については、通知必要度を表す数値としてドライバの来訪頻度が演算される。想定外事象判定部54によって抽出される想定外事象については、事象の発生頻度又は出現確率が算出される。また、ストレス事象判定部によって抽出される事象についてはストレス度が算出される。通知判断部60は、それらの数値と閾値を比較することで通知可否の最終判断を下す。そして、ドライバが、より多くの通知を要望している場合は、より多くの事象が通知されるように閾値を変更する。また、ドライバの運転スキルが高いほど、より多くの事象が非通知となるように閾値を変更する。このような処理によれば、ドライバの設定又は要望、及びドライバの運転スキルに応じた通知規則を実現することができる。
【0115】
[実施の形態2の動作]
図8は、本発明の実施の形態2において、センター44で実施される処理の概要を説明するためのフローチャートである。
図8に示すフローチャートは、ステップ104がステップ116に置き換えられている点を除いて
図5に示すルーチンと同様である。ステップ116では、想定外事象判定部54の処理及びストレス事象判定部56の処理に加えて、来訪頻度判定部72の処理が実行される。
【0116】
図9は、
図8に示すステップ116、及び通知可否を最終判断するステップ106の詳細を説明するためのフローチャートである。
図9に示すフローチャートでは、ステップ104−1〜104−6並びにステップ116−1〜116−3が、
図8に示すステップ116に相当する。
【0117】
図9に示すルーチンでは、ステップ104−2の判断が否定されると、次に、支援車両24のドライバが本サイクルの事象に遭遇する場所が、そのドライバの生活圏内であるかが判別される(ステップ116−1)。この処理は、支援車両24からのアップロードデータに含まれる現在位置の情報と、ドライバ情報データベース70に記録されているドライバの移動履歴とに基づいて判断される。
【0118】
事象への遭遇場所がドライバの生活圏内であると判別された場合は、生活圏内版の設定が選択される(ステップ116−2)。一方、その遭遇場所がドライバの生活圏内ではないと判断されると、次に、生活圏外版の設定が選択される(ステップ116−3)。これらの設定は、ステップ104−3〜104−6の処理、並びにステップ106の処理に反映される。
【0119】
ステップ116−2で選択される生活圏内版の設定は、より詳細には、更に二つの設定に区分される。即ち、ステップ116−2では、具体的には、先ず、本サイクルの事象に支援車両24が遭遇する時間帯が、そのドライバの活動時間帯に属しているかが判別される。その結果、活動時間帯に属していると判別された場合は、活動時間版の設定が選択される。一方、活動時間帯に属していないと判別された場合は、活動時間外版の設定が選択される。
【0120】
ステップ116−2で活動時間版の設定が選択された場合、ステップ104−3〜104−6では、実施の形態1の場合と同様の処理が行われる。この場合、低頻度事象及び低確率事象が想定外事象として抽出されることになる。
【0121】
ステップ116−2で活動時間外版の設定が選択された場合、低確率事象を抽出するためのステップ104−4は、実施の形態1の場合と同様に行われる。従って、全ての低確率事象が想定外事象として抽出される。一方、この設定によれば、低頻度事象を抽出するステップ104−3、104-5及び104−6では、実施の形態1で抽出される低頻度事象に加えて、現在の時間帯には頻繁に発生するがドライバの活動時間帯には発生しない時間帯事象が抽出される。そして、ドライバがその事象の発生時間帯にその事象を訪れる頻度が閾値に満たない場合は、その時間帯事象が想定外事象として抽出される。
【0122】
ステップ116−3で生活圏外版の設定が選択された場合、低確率事象を抽出するステップ104−4では、ドライバの来訪頻度が考慮されることになる。即ち、ドライバの来訪頻度が閾値に満たない場合は、抽出された低確率事象は想定外事象として抽出されない。また、低頻度事象を抽出するステップ104−3、104-5及び104−6では、実施の形態1で抽出される低頻度事象に加えて、常時事象及び時間帯事象が抽出される。そして、ドライバの来訪頻度が閾値に満たない場合は、常時事象及び時間帯事象を含めて、それらの事象が想定外事象として抽出される。
【0123】
本実施形態では、ステップ106において、システム稼動履歴及びドライバの特性に応じた通知判断がなされる。ここでは、上述した通知判断部60の処理が実行される。その結果、最後の通知からの経過時間が短い事象は非通知とされる。また、支援車両24への通知の程度にドライバの設定又は要望、並びに運転スキルが反映される。
【0124】
以上説明した通り、本実施形態のシステムによれば、ドライバの移動履歴や特性等を考慮して通知の運用を決めることができる。このため、本実施形態によれば、実施の形態1のシステムに比して、ドライバにとっての使い勝手をより一層高めることができる。
【0125】
[実施の形態2の変形例]
上述した実施の形態2においては、ドライバの移動履歴、システム稼動履歴、並びにドライバの設定、要望及び運転スキルを、想定外事象の通知に関する最終判断に反映させることとしている。しかしながら、それらの要素はストレス事象の通知に関する最終判断に反映させることとしてもよい。
【0126】
ストレス事象に対するドライバの耐性は、同種の事象への遭遇頻度が増えるに従って高まる。このため、ドライバの特性等をストレス事象についての最終判断に反映させる場合は、同種のストレス事象への遭遇回数又は遭遇頻度が高いほど非通知の判断が下され易くなるように通知判断の閾値を修正することとしてもよい。
【0127】
尚、上述した実施の形態2においては、ドライバ情報データベースにより、前記第13の発明における「通知履歴データベース」、前記第14の発明における「運転スキルデータベース」、並びに前記第15の発明における「設定データベース」が実現されている。
【0128】
実施の形態3.
[実施の形態2の構成]
図10は、本発明の実施の形態3の構成を説明するための図である。以下、
図10において、
図4に示す要素と同一の要素には同一の符号を付してその説明を省略する。本実施形態のシステムは、センター44に事象情報演算部74が備わっている点を除き、実施の形態1のシステムと同様である。
【0129】
事象情報演算部74には、事象検出部50によって検出された障害事象に関する情報が提供される。事象情報演算部74は、提供された障害事象の夫々について確信度演算処理を実行する。情報提供車両等からセンター44にアップロードされてくるデータには、車載カメラ等により確定された事象に関するものと、情報提供車両10の回避行動など、事象そのものは確定されていないものとが含まれている。確信度演算処理では、それらの情報に基づいて、事象検出部50において検出された事象の確信度を計算する。
【0130】
確信度の計算は、判定対象の事象に関してアップロードされてきたデータの数、割合、内容に基づいて行われる。例えば、特定の場所を走行する情報提供車両10から、回避行動の挙動がアップロードされている場合は、その場所に何らかの障害事象が発生していることが推定できる。そして、同種の回避行動が多数の情報提供車両10からアップロードされていれば、その事象の存在確率が高いと判断することができる。また、その場所を走行する多数の情報提供車両10が、回避行動を取る割合が高いほど、その存在確率は高いと判断することができる。更に、アップロードされたデータの中に、例えば、脱落タイヤや故障車など、事象そのものを特定したデータが含まれていれば、ほぼ間違いなくその場所に障害事象が生じていると判断することができる。このため、確信度演算処理は、上述したデータの数、割合、及び内容をパラメータとする関数により、障害事象の存在確率が高いほど高い値となるように確信度を計算する。
【0131】
事象情報演算部74によって演算された確信度は、通知判断部60に提供される。本実施形態において、通知判断部60は、通知の可否を最終判断する処理において、判断対象の障害事象の確信度が、通知閾値以上であるかを判断する。その結果、確信度が通知閾値以上であれば、その事象について通知の判断が下される。一方、確信度が通知閾値に満たなければ、その事象について非通知の判断が下される。
【0132】
上記の処理によれば、存在が曖昧な事象の情報がドライバに通知されてしまうのを適切に回避することができる。このため、本実施形態のシステムによれば、実施の形態1のシステムに比して、更に信頼度の高い通知を支援車両24のドライバに提供することができる。
【0133】
[実施の形態3の動作]
図11は、本発明の実施の形態3において、センター44で実施される処理の概要を説明するためのフローチャートである。
図11に示すフローチャートは、ステップ104がステップ118に、また、ステップ106がステップ120に置き換えられている点を除いて
図5に示すルーチンと同様である。ステップ118では、想定外事象判定部54の処理及びストレス事象判定部56の処理に加えて、事象情報演算部74の処理が実行される。また、ステップ120では通知判断部60の処理が実行される。
【0134】
図12は、
図11に示すステップ118及びステップ120の詳細を説明するためのフローチャートである。
図12に示すフローチャートでは、ステップ104−1〜104−6及び118−1が、
図11に示すステップ118に相当する。また、ステップ120-1及び120−2が、
図11に示すステップ120に相当する。
【0135】
図12に示すルーチンでは、ステップ104−2の判断が否定されると、次に、本サイクルの判断対象である障害事象について確信度が演算される(ステップ118−1)。ここでは、具体的には、以下の処理が実行される。
1.障害事象についてアップロードされているデータの数を係数。
2.障害事象の発生場所を通過する情報提供車両10から、その事象について情報がアップロードされている割合を演算。
3.障害事象の内容確定に足る情報のアップロード数を係数。
4.上記1〜3の結果に、夫々について設定された重み付け係数を掛け合わせる。
5.上記4の結果の和を確信度として計算。
【0136】
上記の処理が終わると、次に、上記の処理により演算された確信度が、通知閾値以上であるかが判別される(ステップ120−1)。その結果、確信度が通知閾値以上であれば、以後ステップ104−3以降の処理が実行される。一方、確信度が通知閾値に満たなければ、本サイクルの事象について非通知の判断が下され、今回の処理サイクルが終了される。尚、
図12に示すフローチャートにおいて、ステップ120−2では、実質的に
図6に示すステップ106と同様の処理が実行される。
【0137】
以上の処理によれば、存在確率が十分に高い障害事象だけを支援車両24のドライバに通知することができる。このため、本実施形態のシステムによれば、実施の形態1のシステムに比して、更に無駄な通知を減らすことができ、ドライバにとっての信頼度を高めることができる。
【0138】
[実施の形態3の変形例]
上述した実施の形態3においては、確信度による最終判断を想定外事象の通知に反映させることとしている。しかしながら、その判断は、ストレス事象の通知に反映させることとしてもよい。
【0139】
実施の形態4.
[実施の形態2の構成]
図13は、本発明の実施の形態4の構成を説明するための図である。本実施形態において、センター44は、
図7に示すドライバ情報データベース70と、
図10に示す事象情報演算部74を共に備えている。この点を除いて、本実施形態のシステムは実施の形態1乃至3の何れかのシステムと同様である。
【0140】
本実施形態のシステムは、実施の形態2のシステムと同様に、支援車両24のドライバの移動履歴、システムの稼動履歴、及びそのドライバの特性に応じて障害事象の通知/非通知を判断することができる。また、本実施形態のシステムは、実施の形態3のシステムと同様に、障害事象の確信度に基づいて、その事象の通知/非通知を最終判断することができる。
【0141】
このため、このシステムによれば、実施の形態1乃至3の何れかのシステムに比して、通知の信頼度を更に高めることができる。尚、本実施形態においてセンター44が実施する処理の内容は、実質的に実施の形態2又は3の場合と同様である。このため、ここでは、その重複する説明は省略する。