(57)【要約】本発明は、車両における少なくとも１つの運転者支援機能（２０，２２）のための環境仮（２６，２８）を、車両の環境に関するセンサデータを評価して作成する環境仮説作成方法であって、センサデータを１つの運転者支援機能に依存しないセンサ言語として情報プラットフォーム（１２）に出力するステップと、センサ言語をセンサに依存しない機能言語に翻訳するステップとを有することを特徴とする、車両における少なくとも１つの運転者支援機能のための環境仮説を、車両の環境に関するセンサデータを評価して作成する環境仮説作成方法に関する。【選択図】図１
2009505906.tif 000002
【特許請求の範囲】
【請求項１】
車両における少なくとも１つの運転者支援機能（２０，２２）のための環境仮説（２６，２８；３２，３４，３８，４０）を、車両の環境に関するセンサデータを評価して作成する環境仮説作成方法において、
センサデータを、運転者支援機能に依存しないセンサ言語として出力するステップと、
前記センサ言語を、センサに依存しない機能言語に翻訳するステップと、
を有することを特徴とする、環境仮説作成方法。
【請求項２】
少なくとも１つのセンサ（１６，３０）で測定された対象物に関する対象物仮説を作成する請求項１に記載の環境仮説作成方法において、
センサ言語が出力された対象物の測定時間のそれぞれが、センサ固有の座標系で表されており、機能言語への翻訳の際に車両固有の座標系に換算されることを特徴とする、請求項１に記載の環境仮説作成方法。
【請求項３】
前記センサ（１６，３０）のセンサデータは、周期的に測定されて出力され、センサ言語で表されたセンサ言語のそれぞれは、出力された時点の測定周期に関連付けられており、
機能言語により前記環境仮説が作成される際に、連続する測定周期に含まれるセンサデータの履歴が考慮されることを特徴とする、請求項１又は請求項２に記載の環境仮説作成方法。
【請求項４】
複数の前記運転者支援機能（２０，２２）のための前記環境仮説（２６，２８；３８，４０）が、同時に同一のセンサデータに基づいて作成されることを特徴とする、請求項１〜請求項３のいずれかに記載の環境仮説作成方法。
【請求項５】
前記環境仮説（３８，４０）が作成される際に、複数の前記センサ（１６，３０）のセンサデータが互いに融合されることを特徴とする、請求項１〜請求項４のいずれかに記載の環境仮説作成方法。
【請求項６】
個々のセンサ（１６，３０）毎のデータに基づいて、最初にセンサ固有の環境仮説（２６’，２８’；３２，３４）が作成され、
次いで前記センサ固有の環境仮説（２６’，２８’；３２，３４）が、後続のステップにおいて複数の前記運転者支援機能（２０，２２）のための前記環境仮説（３８，４０）に融合されることを特徴とする、請求項５に記載の環境仮説作成方法。
【請求項７】
前記環境仮説が、前記対象物仮説（２６，２８；３８，４０）及び車線仮説（４２，４４）を含むことを特徴とする、請求項１〜請求項６のいずれかに記載の環境仮説作成方法。
【請求項８】
前記車線仮説（４４）が、対象物を測定するための少なくとも１つのセンサ（３０）のデータと、自車両センサ（１８）のデータとを融合して作成されることを特徴とする、請求項７に記載の方法。
【請求項９】
少なくとも１つの運転者支援機能（２０，２１）と、車両の環境を検出するための少なくとも１つのセンサ（１６，１８）と、を備えた車両のための運転者支援システムにおいて、
前記センサ（１６，３０）と前記運転者支援機能（２０，２２）との間のインタフェースを形成し、請求項１〜請求項８のいずれかに記載の環境仮説作成方法を実行するために構成された情報プラットフォーム（１２）を有することを特徴とする、運転者支援システム。
【請求項１０】
設けられているセンサ（１６，３０）の種類及び数と、前記設けられているセンサの車両における配置位置と、実現された前記運転者支援機能（２０，２２）の種類及び数と、に関する情報が、前記情報プラットフォーム（１２）に集中していることを特徴とする、請求項９に記載の運転者支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両における少なくとも１つの運転者支援機能のための環境仮説を、車両の環境に関するセンサデータを評価して作成する方法及び当該方法が実現されている運転者支援システムに関する。
【背景技術】
【０００２】
一般的に、運転者支援システムは、運転者による車両の操縦をサポートする車両の装置として理解される。このような運転者支援システムとしては、例えば適応速度制御器（Adaptiver  Geschwindigkeitsregler）があり、ＡＣＣシステム（車間距離適応走行制御システム、Adaptive  Cruise  Control）とも呼ばれている。このシステムでは、例えばレーダセンサ（Radarsensor）などのセンサを用いて先行車両との間の間隔を測定し、その間隔に従って、自車両の速度を制御することが可能である。従って、先行車両は、適切で安全な間隔を保って追走される。
【０００３】
運転者支援システムは、危険を可能な限り回避するか、又は損害を制限するために、運転者に対する危険の警告、及び／又は自動的な車両操縦への介入を行う安全システムとしても理解される。又、運転者支援システムは、事故の影響を軽減するために、エアバック・シートベルト等を早期に作動させるパッシブセーフティシステム（事後安全性、passive  Sicherheitssystem）としても理解される。パッシブセーフティシステムは、例えばプリクラッシュシステム（Pre-Crash-System）又はＰＳＳシステム（衝突予知安全システム、Predictive  Safety  System）とも呼ばれている。
【０００４】
一般的に、運転者支援システムは、レーダセンサ等の少なくとも１つのセンサ及びそれに付属しデータの初期調整のための電子装置を備えた交通環境を検出するためのセンサ部（センサ構成要素、sensorische  Komponente）と、車両の駆動システム、ブレーキシステム又は操縦等への介入、及び／又は、運転者に対する警告信号の出力を行うための運転者インタフェースを有するアクチュエータ部（アクチュエータ構成要素、aktorische  Komponente）と、センサ部により提供されたデータを用いてアクチュエータ部のための制御信号を生成するデータ処理装置と、を含む。
【０００５】
データ処理装置の機能は、センサデータがどのような形式で解釈されるかを設定する１又は複数の環境仮説（Umwelthypothese）     に、少なくとも潜在的に基づいている。例えば、ＡＣＣ支援機能のための環境仮説（自車両の周囲の状況（環境）に対する仮説又は仮定）としては、「自車両との関連で、間隔ｄ、相対速度ｖの追従車両（先行車両）が存在する」というものが挙げられる。これは、自車両の環境に存在する特定の対象物についての対象物仮説（Objekthypothese）の一例とも言える。環境仮説の更なる別の例としては、車線仮説があり、例えば「自車両は、車道の一番右側の車線に存在している」又は「車線は、カーブ（曲率）ρ、幅Ｂを有している」という形式のものが挙げられる。
【０００６】
従来の運転者支援システムでは、環境仮説を作成するプロセスが、様々なセンサシステムにおけるデータの初期調整、すなわち、レーダセンサ又はビデオシステムにおけるデータの初期調整の際に、すでに明示的又は潜在的に存在する。一方、通常、マイクロコンピュータ又はマイクロコンピュータ・システムで構成されるデータ処理装置でも、環境仮説作成のためのプロセスが存在する。センサ部によって出力されるデータは、目標の支援機能のために既に調整されている。反対に、データ処理装置のプログラミングは、組み込まれるセンサ部のために調整されている。
【発明の開示】
【０００７】
特許請求の範囲に記載の請求項１に述べられた構成要件を含む本発明は、運転者支援システムにおける構成部材に対する柔軟性をより向上させることができ、特に、センサ部の交換、新しい構成要素の追加、又は運転者支援システムの機能性の変更・拡張を容易にすることができる。
【０００８】
このことは、センサと運転者支援システムの機能とを切り離す事が可能な環境仮説作成方法によって達成される。
第１ステップでは、センサ側において、センサデータが機能（運転者支援システムの機能）に依存しないセンサ言語として出力される。
第２ステップでは、センサデータは、センサに依存しない機能言語に翻訳される。環境仮説は、このセンサに依存しない機能言語において、（１又は複数の）支援機能により評価されうるように表わされる。
【０００９】
この構成によれば、センサ言語は機能に依存しないので、センサ構成の際には、どの機能がセンサに使用されるのか、更に、個々の機能がどのように機能するのかに関して考慮する必要がない。反対に、（１又は複数の）支援機能のプログラミング及び実行の際には、車両の環境に関する全情報（全知識）は、機能言語で表現された環境仮説によって表わされる。よって、どのセンサを用いて仮説が作成されたのか、更に、センサがどのように機能するのかに関して考慮する必要がない。
【００１０】
従って、様々なセンサ部及び支援機能を、非常に可変的に互いに組み合わせることが可能である。構成を変更する際には、センサ側でも、本来の支援機能側でも、特別に調整する必要をなくすことができる。その際、環境仮説を作成し、センサと（１又は複数の）機能との間のインタフェースとしてある程度は機能する特別なデータ処理モジュールが調整される必要はある。
【００１１】
本発明の好適な実施形態は、特許請求の範囲に記載の従属請求項から明らかになる。
【００１２】
本発明の利点として、センサ言語は、車両に依存しない。つまり、どの車両に配置され、車両のどの箇所に関連するセンサが組み込まれるかに関して情報は、センサ側に存在する必要はなく存在しない。その情報は、環境仮説のレベルでようやく使用されうる。環境仮説のレベルにおいて、それぞれセンサ固有の座標系に関連しているセンサデータを、車両固有の座標系に関連し機能言語として出力されて利用される値に換算するために、その情報が利用される。このように、柔軟性が向上し、運転者支援システムの新たな又は更なる別の車両タイプへの調整が非常に容易になる。特に、運転者支援システムの主機能が実現されているプログラムモジュールは、変更されずに引き継がれる。
【００１３】
車両の環境は運転者支援システムの駆動中に動的に変化するので、連続して更新されたデータがセンサによって検出される。例えばセンサは周期的に機能する。各センサには特定の測定周期があり、この測定周期内でデータが更新される。従って、連続して更新されたデータが正しく解釈されるように、システム全体がある種の記憶部を備えていなければならない。例えば、ある対象物が、複数の連続するセンサ測定周期において少しずつ異なる位置で測定された場合、システムは、常に１つの同一の対象物が測定されていることが検出できなければならない。すなわち、ある程度の対象物に関する仮説形成（能力）を前提条件とする。
従って、本発明の利点として、本発明に基づく方法において、実際のデータは「履歴（Historie）」によって調整される。すなわち、仮説作成レベルにおいてようやく、センサとセンサデータの出力時に利用されたセンサ言語に関する記録に関係なく（Gedaechtnisfrei）、実際のデータが、既に検出されたデータを用いて調整される。
【００１４】
本発明の利点は、特に、様々なセンサ部のデータが互いに融合されることにある。一般的に、様々なセンサの測定周期は互いに同期し合わない。従って、同一の対象物についてのデータが、様々なセンサによって様々な時間に検出され、直接互いに比較されることは不可能である。データをセンサ言語から機能言語へ翻訳するステップにおいて、データは、その都度のセンサ固有の座標系から車両固有の座標系に換算される。更に、履歴を考慮することによって、対象物の状態（Objektzustaende）の経過（zeitliche  Entwicklung）に関する仮説を立て、様々なセンサ部から非同期に届けられるデータを補間して（interpolieren）、同期させることが可能である。最終的に、複数のセンサのデータに基づくが、センサには依存せずに表現された対象物仮説が獲得される。
【００１５】
本来の運転者支援システムの枠組みにおいて環境仮説を評価する際には、その都度の環境仮説がいかに正確で、信頼性があるかということが非常に重要である。仮説の正確さ及び信頼性は、仮説の側において、使用されているセンサの性質、投入条件、及び数に、依存する。ここでの関連でも、センサと機能の分離を実現するため、本発明の利点として、センサ言語は、例えば信号−ノイズ比（Ｓ／Ｎ比）、エラーに対する耐性（Fehlertoleranz）、又は個々の測定値の分散（Steuung）等のデータの品質に関する情報を与える様々な値及びパラメタを含んでいる。この品質データ（センサの品質に関するデータ）は、それぞれセンサ固有であり、特定の支援機能に特別に関連していない。この品質値は、機能言語に翻訳される際にようやく、測定値の存在確率や分散等が関連し、環境仮説を特徴づけ、対応する品質パラメタに換算される。その際、履歴に依拠することによって、過去のデータの統計的なゆれも考慮される。同様に、様々なセンサによって獲得されたデータが、どの程度まで、互いに有効であることを認め合うのか、又は互いに矛盾し合うのか、ということが、センサデータの融合の関連において考慮される。
【００１６】
本発明の利点として、環境仮説の立案及び評価には、仮説が妥当と思われる（説得力がある、plausibel）、又は妥当と思われない（unplausibel）と評価することを容認する特定の機能固有の仮定も加わる。
【００１７】
数の互いに独立しているが共通のセンサデータにアクセスする支援機能を運転者支援システムが有する限り、様々な機能のための環境仮説を、「情報プラットフォーム（Informationsplattform）」の共通の処理ステップ及び／又は共通のデータ処理モジュールにおいて構築する点で利点がある（zweckmaessig）。従って、データ評価の際の相乗効果が、最大限に利用される。
【発明を実施するための最良の形態】
【００１８】
本発明の実施形態は添付の図に示されており、以下の明細書で詳細に解説される。
【００１９】
図１には、車両のための運転者支援システムが非常に簡略化されたブロック図として示されている。この運転者支援システムは、３つの段階、すなわち、センサステップ１０と、情報プラットフォーム１２と、機能ステップ１４とから構成される。ここで示される実施形態において、センサステップ１０は、特に先行車両の測定を行う車両前部に組み込まれたレーダセンサ１６（LRR＝Long  Range  Radar  長距離レーダ）と、「独自」の車両、すなわち、運転者支援システムを実装した車両、に関するデータを提供する自車両センサ１８とを含んでいる。ここで示される実施形態において、機能ステップ１４は、２つの支援機能、すなわち、車間距離適応走行制御（ＡＣＣ＝Adaptive  Cruise  Control）のための支援機能２０と、安全性システム（ＰＳＳ＝Predictive  Safety  System）のための支援機能２２とを含んでいる。支援機能２０（ＡＣＣ）によって、独自（自車両）の軌道（Spur）に先行車両がない場合（自由走行  Freifahrt）、自車両の速度は、運転者に選択された所望の速度に調整される。又は、先行車両がある場合（追従走行  Folgefahrt）、先行車両との間の所定の目標間隔又は目標時間差に合わせる間隔制御が行われる。支援機能２２（ＰＳＳ）は、例えば、差し迫っておりおそらくもはや回避不可能な衝突に備えて、エアバック及びシートベルト等、車両のパッシブセーフティシステムを準備するのに役立つ。しかし、支援機能２２にも、衝突をまだ回避するか、又は少なくとも衝突の影響を低減しようと試みる対応策が備えられている。例えば、ブレーキ圧力シリンダを前もって満たすことによって、車両ブレーキへの迅速な準備、又は場合によっては緊急ブレーキ機能の自動始動が可能になる。
【００２０】
センサステップ１０及び機能ステップ１４の基本構成は、上記のように公知であり、従ってここでは詳細な解説を行わない。機能ステップ１４は、付属ソフトウェアを備えた電子的なデータ処理システムによって形成されており、センサステップ１０から電子形態で提供されたデータを評価する。すなわち、すでにセンサステップのセンサ部も、データ事前処理のための電子的構成要素を含んでいることが暗示されている。
【００２１】
情報プラットフォーム１２は、センサステップ１０のデータを用いて環境仮説、特に対象物仮説、すなわち、先行車両又はその他の障害物等のレーダセンサ１６によって測定された対象物に関する仮説を立てる。この環境仮説は、機能ステップ１４の本来の支援機能を実行するための基盤となる。
【００２２】
本来の運転者支援システムにおいて、センサステップ１０及び機能ステップ１４は直接相互に通信し、センサステップ１０及び機能ステップ１４の電子装置に分散されている処理プロセスによって、暗示的に仮説形成が行われる。その一方、ここで提案される運転者支援システムの特徴は、仮説形成が情報プラットフォーム１２において明示的に行われることにある。情報プラットフォーム１２は、センサステップ１０と機能ステップ１４との間のインタフェースとして機能する。更に、様々なセンサ部又はセンサ部の組み合わせ、及び様々な支援機能に調節可能な独立したモジュールとして、例えば電子的データ処理システムのソフトウェアモジュールとして構成されている。
【００２３】
センサステップ１０によって出力されたデータを、最終的に機能ステップ１４で処理されるデータに翻訳するために必要とされる情報は、情報プラットフォーム１２に集中している。すなわち、例えば、レーダセンサ１６の、センサデータの事前処理及び出力を行う電子装置には、車両のどの箇所に関連するセンサが組み込まれているのかに関する情報は、存在しない。同様に、レーダセンサ１６は、測定値の解釈に関連する情報を持っていない。レーダセンサ１６は、レーダセンサ１６によって測定された対象物が何であるかに関して、例えば、車両、飛行機、静止物等であるかに関して、比喩的に言えば「白紙」（weiss）である。更に、レーダセンサ１６には、どの支援機能のためにセンサデータが利用されるべきなのかに関する情報も存在しない。従って、センサデータがレーダセンサ１６によって出力される際のフォーマットは、機能及び車両に依存しないセンサ言語に相当する。それに従って、レーダセンサ１６によって出力されるデータも車両の座標系ではなく、センサ固有の座標系に関連している。例えば、センサによって測定された対象物の位置は、極座標で表される。すなわち、間隔ｄによって、縦座標の起点（原点）としてのセンサと、センサの光軸に関するアジマス角φによって表される。測定された対象物の相対速度ｖは、レーダ反射波のドップラー偏移をもとに測定され間隔ｄの時間導関数として定義される。
【００２４】
更に、レーダセンサ１６によって出力されたセンサデータは、測定データの信頼性又は正確さに関する情報を与える様々な値σφ、ｑを含んでいる。例えば、アジマス角φは、サイドに互いに向かい合って設置されたレーダセンサの複数のパッチアンテナによって受信される信号の位相関係の評価によって算定される。その際、アジマス角に関する厳密に定義された値が獲得されるのではなく、（値）σφのように分散（Steuung）した、特定の角度に分散した値が（Winkelverteilung）獲得される。測定値ｑは、例えば、測定された対象物のための信号の信号／ノイズ関係、及び／又は、対象物が複数の連続する測定周期において測定される検出の回数等の対象物の安定性に関わっている。（通常、対象物の安定性についての情報は、後の処理ステップにおいて提供される）。
【００２５】
例えば、レーダセンサ１６がＦＭＣＷレーダ（Frequency  Modulated  Continuous  Wave）である場合、どの測定された対象物に対しても、受信された信号の周波数スペクトルにピークが存在する。このピークの状態は、間隔ｄ及び相対速度ｖに依存しているので、信号はその限りにおいて多義的である。このような多義性を解消するため、送信されたレーダ信号は、各測定周期内で、少なくとも２つの異なるランプの上昇（ランプ（傾斜）状の増加）によって変調される。２つの異なるランプのために、間隔ｄ及び相対速度ｖがスペクトルにおけるピークの状態に基づいて算定される。複数の対象物が同時にレーダセンサの測定領域に存在する場合、個々のピークと関連する対象物との対応に関して、更に多義性が追加される。このような多義性は、更なる別のランプの上昇によって、少なくとも１つの追加的なランプのスペクトルを評価することによって解消される。このような多義性は、センサステップ１０でのレーダセンサ１６の電気装置におけるデータ事前処理によって解消される。
【００２６】
センサ言語で出力されたレーダセンサ１６のデータは、データがそれぞれレーダセンサの目下の測定周期（現在の測定周期）に関わっているという意味において「記憶が空いている」。しかし、センサステップ１０において、すでにある程度のデータ格納が行われる。場合によっては、複数の測定周期をまたいで格納される。例えば、様々なランプにおいて受信されたスペクトルの評価のために、ある程度、データを一時的に格納する必要がある。更に、複数の対象物がある際の多義性をより容易に又はより迅速に解消するため、先行する測定周期のデータに依拠することが可能である。同様に、特に、検出回数や信号の安定性を示す品質パラメータを決定する際に、先行測定周期のデータが遡って参照される。しかし、重要なのは、各測定された対象物のため、最終的に情報プラットフォーム１２に出力されるデータが、目下の測定周期のみに関連していることである。同じことが、センサステップ１０の残りのセンサ部にも言える。
【００２７】
自車両センサ１８は、車両に搭載された独自のセンサによって検出される自車両に関するデータ、例えば、走行速度ｖ、車両の（縦方向における）現在の加速度ａ、車両の現在のヨーレートφ（Giergeschwindigkeit）と、場合によってはヨー加速度等とを伝達する。これらの他に、運転者支援システムには、様々な車両データが関連している。この車両データは、必ずしもセンサで検出される必要はなく、例えば、車両固有のパラメタとして固定されて入力されることも可能である。その重要な例として、レーダセンサ１６の車両内での配置位置、及びセンサの調整状態を特徴付けるデータが挙げられる。このデータは、自車両センサ１８に割り当てられる。
【００２８】
従って、様々なセンサ部の、ここの例ではレーダセンサ１６のセンサデータを自車両と関連付けるために必要な情報は、情報プラットフォームのステップで使用可能である。特に、このステップでは、センサデータに対して、センサ固有の座標系から車両固有の座標系への換算、例えば、Ｘ軸が車両の縦方向において車両の中央を通るデカルト座標系への換算が行われる。
【００２９】
同様に、情報プラットフォーム１２のステップにおいて、「記憶が空いている」センサデータが、履歴と、すなわち、先行測定周期の対応するデータと融合される。従って、様々な対象物の測定データは、複数の測定周期をまたぐ時間領域にわたって追跡される。一般に、追跡手順（Tracking-Prozedur）として知られる手順である。そのため、情報プラットフォーム１２は、追跡モジュール２４を有している。追跡は、車両固有の座標系で行われるのが好ましい。それによって、複数のセンサ部が存在する場合に、様々なセンサ部のセンサデータが追跡手順の際に考慮される。すなわち、センサデータが「融合される」。その際、様々なセンサのデータが、１つの同一の対象物に関連付けられるという意味で、既にある程度のセンサデータに関する解釈が行われる。
【００３０】
情報プラットフォーム１２の本質的な機能は、対象物仮説、すなわち、センサデータによって表されている対象物の性質についての仮説を立てることにある。例えば、レーダセンサ１６に測定された対象物の相対速度ｖを自車両の走行速度Ｖと比較すると、対象物が、静止物なのか動く対象物なのか、例えば、先行車両なのか対抗車両なのかを決定することができる。機能ステップ１４で実行される（１つ又は複数の）機能の形式に従って評価を進める際に、特定の対象物クラスを無視することが可能である。例えば、本来のＡＣＣ機能（発進・停止機能（Stop  ＆  Go）を含まない限り）において、通常、走行方向に存在する動く目標物のみが考慮される。静止物は、他の支援機能に必要とされない限り、最初から拒否されることが可能である（無視される）。従って、追跡モジュール２４の作業負荷も低減される。
【００３１】
更なる別の観点においても、対象物仮説、及び仮説を立てる際に基づく判定基準は、その都度特定の支援機能に特別に調整される。それに従って、図１では、情報プラットフォーム１２内に、２つの対象物仮説２６及び２８が象徴的に示されている。この対象物仮説は、データ構造であり、対象物を定義するための判定基準の集合、及び／又は、対象物を複数の対象物カテゴリの１つに関連付けるための判定基準の集合、及び、対象物をその都度の支援機能に調節された機能言語で記述する変数の集合を含んでいる。この変数は、対象物の位置及び動作データに関連する限り車両固有の座標系で表される。図１において、この変数は、例えば、車両固定の座標系の起点に基づく、対象物の位置座標系ｄｘ及びｄｙと、車両の縦方向にある対象物の相対速度ｖｘと、車両等の横方向にある対象物の相対速度ｖｙ等を含んでいる。更に、この変数は、ここで示される実施形態において、各対象物について少なくとも１つの変数Ｐｅｘを、つまり、存在確率を、すなわち、位置及び動作データで記述される対象物が事実上存在する確率、又は、該当する対象物カテゴリの定義判定基準を満たす確率を含んでいる。例えば、ＡＣＣ機能のために、対象物仮説「追従走行対象物（追従走行するための対象物）」が定義されたとする。ここでは、同じ車線における自車両のすぐ前の先行車両に関連しており、この車両に対して間隔制御が行われなければならない。存在確率Ｐｅｘは、この対象物が事実上追走されているという確率に依存している。この確率の計算においては、特に、レーダセンサ１６から伝達された測定値σφが用いられる。
【００３２】
同様に、ある対象物仮説についての変数集合は、（車両固有の座標系に関する）位置及び動作データの正確さ又は信頼性を特徴づける種類の異なる更なる別の変数を含むことが可能性である。例えば、許容限界、分散、場合によっては履歴の評価によって算定された統計的な揺れ等が挙げられる。
【００３３】
対象物仮説２６及び２８の変数集合は、センサ言語からの換算又は翻訳によって計算される。しかし、最終的には、関連する対象物を車両固有の座標系で記述し、従って、関連する支援機能２０又は２２によって評価される。その際、どの特別なセンサで、又はどのセンサの組み合わせを用いて対応する情報が獲得されたのかに関して、何らかの情報が使用可能である必要はない。その限りにおいて、データが機能ステップ１４に出力される際の媒体としての機能言語は、センサに依存しない。
【００３４】
図１に示された実施形態において、支援機能２０及び２２に出力される変数集合は、形式的には同一であるが、その都度関連する機能に特別に調整されるので、その都度の値及び意味が異なっている可能性がある。例えば、ある対象物が測定され、測定の正確さを考慮した上で、対象物が静止物である可能性が高いほど、その絶対速度が遅い場合、ＡＣＣ機能のための対応する対象物仮説２６において、「追従走行対象物」の存在確率Ｐｅｘは非常に低い。その一方、対象物仮説２８においては、静止した障害物の可能性が高い対象物「障害物」の存在確率Ｐｅｘは、明らかに高くなる。同様に、ＡＣＣ機能のための対象物仮説２６における値ｄｘは、通常、関連する対象物との間隔において最も確率が高い値を示す。その一方、安全機能ＰＳＳのための対象物仮説２８においては、むしろ非常に不都合なケースになり、ｄｘは、ここでの測定の正確さの枠内で、最も可能性が低い対象物との間隔を表している。このように、機能言語においては、個々の変数の意味が機能によって異なる可能性がある。
【００３５】
それにもかかわらず、対象物仮説２６及び２８の変数は、通常起点が共通しており部分的にも一致している、又は少なくとも互いに依存関係にある。従って、対象物仮説２６及び２８を共通の手順で立てるのが好ましく、不必要な並行又は二重計算の計算作業が節約されうる。このことは、図１において、対象仮説２６及び２８のブロックが重なり合っていることにより象徴的に示される。
【００３６】
様々な対象物仮説のための定義判定基準には、更に、情報プラットフォーム１２で算定された仮定が加わる。この仮定は、その都度の支援機能に関連している物理的な境界条件を表わしている。例えば、ＡＣＣ機能の枠内において、追従走行対象物の横速度ｖｙが相対的に遅いこと、すなわち、例えば、｜ｖｙ｜＋＜＋３  ｍ／ｓであることは妥当と思われる仮定である。それに対して、この仮定がＰＳＳ機能の枠内での対象物仮説「障害物」にとって有効である必要はない。すなわち、例えば、横加速ａｙの値が、例えば１０  ｍ／ｓ２を越えないであろうという仮定は妥当と思われる。このような仮定の実現性又は非実現性は、特に存在確率Ｐｅｘに作用し、場合によっては仮説が完全に拒否されることになる。
【００３７】
上記の明細書において述べたように、提案される運転者支援システムにおいて、情報プラットフォーム１２は、センサデータが機能に依存しないセンサ言語から、関連する機能のためのセンサに依存しない機能言語へと翻訳される場所である。また、この翻訳に必要な情報、特に関連する支援機能に関して妥当と思われる仮定と、自車両やセンサステップ１０に設けられているセンサ部の数及びタイプに関する情報と、センサ部の車両での配置位置に関する情報と、が集中している場所でもある。例えば、レーダセンサ１６が、更なる別の車両、又は同一車両内の更なる別の箇所に組み込まれている場合、本来の支援機能２０及び２２を実現するのに影響はなく、情報プラットフォーム１２が調整される必要がある。例えば、レーダセンサ１６がビデオシステムと置き換えられたり、又はセンサ部が追加される場合にも、同様のことが該当する。反対に、支援機能２０及び２２が変更されたり、又は新機能が加えられる場合にも、使用されているセンサ部に対して調整される必要は全くない。この場合にも、情報プラットフォーム１２が、調整される必要がある。
【００３８】
図２には、修正された実行形態における情報プラットフォーム１２が詳細に示されている。
【００３９】
この実施形態において、自車両センサ１８及びレーダセンサ１６の他に、対象物を測定するための第２センサ部として、ビデオシステム３０が設けられている。センサステップ１０の３つのセンサ部はすべて、センサデータをその都度の独自のセンサ言語で（出力して）情報プラットフォーム１２に伝える。この場合、情報プラットフォーム１２は、レーダセンサ１６のデータとビデオシステム３０のデータとを融合する機能を担っている。
【００４０】
最初に、その都度のセンサ部のデータを用いて、センサ固有の環境仮説が形成される。レーダセンサ１６の場合、支援機能２０及び２２のための対象物仮説２６’及び２８’がこれに該当する。この対象物仮説は、レーダセンサ１６のデータのみに関連している。これに対応して、ビデオシステム３０のデータを用いて、２つの支援機能のための対象物仮説３２及び３４が形成される。ここで提案される情報プラットフォームのコンセプトの論理に従えば、自車両センサ１８のデータからも環境仮説が、この場合車両仮説（Fahrzeughypothese）３６が形成される。この車両仮説は、例えば、「自車両は直進している」等となるであろう。又は、自車両センサ１８が、車道の摩擦係数に関する情報を伝える電子安定性システムと接続されている限り、車両仮説は、例えば、「車両は、つるつるした車道を走行している」となる。
【００４１】
このような形式の車両仮説は、図２の太いはっきりした矢印が示すように、必然的に対象仮説２６’、２８’、３２及び３４の作成に影響を及ぼす。例えば、車線変更が差し迫っている場合、測定された対象物が追従走行対象物として評価されるかどうかについて、影響を及ぼす。ＰＳＳ機能のための対象物仮説「障害物」は、最大に見積もって、関連する障害物と自車両との間に特定の最大間隔があってもよいという仮定に基づいている。更に、この最大間隔を道路状態に関連付けるのも利点がある。
【００４２】
２つのセンサ特有の（既に機能言語で表現された）ＡＣＣ機能のための対象仮説２６’及び３４は、レーダセンサ１６及びビデオシステム３０によって獲得された情報をまとめることにより、融合された対象仮説３８を形成する。これに対応して、ＰＳＳ機能のためのセンサ固有の対象仮説２８’及び３２に基づいて、ＰＳＳ機能のための融合された対象物仮説４０が形成される。情報プラットフォーム１２ではセンサデータの履歴も評価されるので、レーダセンサ１６及びビデオシステ３０の測定周期が、互いに同期させられる必要はない。対象物仮説２６’及び３４、２８’及び３２における時間に依存する（zeitabhaengig）変数は、同一時点に関連しているため直接的に相互に比較可能であって、融合された対象物仮説へと融合される値が獲得されるように、既知の時間依存性（Zeitabhaengigkeit）に基づいて、その都度補間される（内挿、interpolieren）。
【００４３】
図２に基づく情報プラットフォーム１２を実現する際、対象物仮説２６’及び２８’を作成するモジュールは、図１の対応するモジュールと同一であってもよい。融合された対象物仮説３８及び４０の作成は、特別なモジュールにおいて行われる。この特別なモジュールは、入力データとして、既にその都度の機能言語で表現された仮説の記述（Hypothesenbeschreibungen）を受信している。また、この記述を、例えば、対象物仮説３２及び３４、又はセンサ固有の他の（図２に示されていない）センサ部のための対象物仮説等の他の対象物仮説によって獲得されるデータにより、補足することが可能である。このモジュール構成によって、システムの高い可変性（Flexibility）が達成される。
【００４４】
ここで示された実施形態において、ビデオシステム３０のセンサデータは、更なるセンサ固有の環境仮説、すなわち、車線仮説（Spurhypothese）４２を形成する。ビデオシステムを使用して、更なる別の車両等の対象物だけではなく、車道の車線標識、路側帯標識、ガードレール及び／又はその他の中央線（中央分離帯）も検出する。従って、レーダシステムしか使用しない場合よりも厳密に、自車両が存在する車線、更に、車線の進路を識別することできる。また、それに応じて、「自車両は一番右側の車線に存在し、車線は左向きのカーブｋを有している」というような形式の車線仮説を生成することが可能になる。ビデオデータのみに基づいて立てられた車線仮説４２は、車両仮説３６と共に一般的な車線仮説４４に融合される。従って、（操縦動作等に関する）車両センサのデータも、車線仮説に加えることが可能である。更に補足的に、例えば「確実に検出された動く対象物（車両）は車道境界の外側にないだろう」という妥当と思われる仮定に基づいて融合された対象物仮説３８及び４０の情報も加えられる。
【００４５】
それに応じて、ビデオデータを用いて、車線への侵入車両の検出等、特別な走行状況に関する環境仮説が形成されることも可能である。
【００４６】
支援機能２０及び２２には、その都度の機能言語で、融合された対象仮説３８及び４０のみならず、車両仮説３６と、車線仮説４４とが出力される。従って、その都度の支援機能には、環境に関する多様なインプレッション（differenziertes  Bild、diverse  impression）が提供される。その際、支援機能は、どのセンサがどのようにこのインプレッションに貢献したのかに関して「知る」必要はない。様々な援助機能及び／又は様々なセンサ部の組み合わせへの調整は、この場合も、情報プラットフォーム１２のステップでのみ行われる。
【図面の簡単な説明】
【００４７】
【図１】本発明の一実施形態に基づく運転者支援システムのブロック図である。
【図２】本発明の更なる別の実施形態に基づく、運転者支援システムのブロック図である。
【図１】
2009505906.tif 000003
【図２】
2009505906.tif 000004
【国際調査報告】
2009505906.tif 000005
2009505906.tif 000006
2009505906.tif 000007
2009505906.tif 000008