JP4659754B2 - 車両運転者および複数のアプリケーション間の対話方法およびシステム - Google Patents

Description

本発明は、人、特に車両運転者と、たとえばネイティブ車両アプリケーションおよび／またはアフターマーケットアプリケーションおよび／またはノマディックアプリケーションのような複数の統合および／または非統合アプリケーションとの間の通信および／または対話を行う方法およびシステムに関する。特に、本発明は、対話マネージャによって通信および／または対話を管理するためのそのような方法およびシステムに関する。

今日では、車両組み込みアプリケーションおよび機能を統合し、それらが、たとえばセンサおよびディスプレイなどの同一のハードウェアおよび／またはソフトウェアコンポーネントを少なくとも部分的に共用できるようにするといった傾向が強い。そのようなアプリケーションには特に、先進運転者支援システム（ＡＤＡＳ）および車内情報システム（ＩＶＩＳ）が含まれる。しかしながら、車両の出荷後に追加されるアフターマーケットアドオンアプリケーションも依然として非常に一般的である。さらに、多くの運転者はＰＤＡ（パーソナルデジタルアシスタント）などのポータブルコンピュータ、携帯電話および車内の他の独立アプリケーション（ノマディックシステム）も同様に使用する。

これらのアプリケーションおよび他の技術はすべて、道路の安全性を向上させるとともに、生活および仕事の質を高める可能性が大きい。

しかしながら、そのような車内アプリケーションが急増すると、たとえばアプリケーションを作動させ、メッセージ（たとえば入り診断メッセージまたはＳＭＳ（ショートメッセージサービス）メッセージ）が同時に提示されるとき、競合の危険性が増加する。これは、快適性を低下させ、安全性にクリティカルなレベルの作業負荷および注意散漫を運転者に課すであろう。さらに、異なったＡＤＡＳおよびＩＶＩＳ間の干渉は、最適とは言えない性能、ユーザの受け入れの減少、およびそれによるこれらのアプリケーションの安全性の恩恵の低下をもたらすであろう。

John A. Michon（ワシントン、ロンドンのTaylor & Francis）が１９９３年に編集した「Generic Intelligent Driver support 」には、（１）一般運転者支援機能の開発、および（２）これらの機能を統合して、それらを運転者および運転環境に適応させる技術の開発という２つの主要焦点を有するＧＩＤＳ（Generic Intelligent Driver support）プロジェクトが開示されている。ＧＩＤＳプロジェクトの重要な特徴は、情報管理であった。ＧＩＤＳで開発されたそのような機能の核心は、
１．同時に提供される異なったサポートおよびサービス機能からの情報の競合を、情報を優先順位に従って順次式に提示することによって防止する優先順位化、および
２．システム開始情報と運転タスクによって課せられるデマンドとの間の競合を、運転状況を尋ねる間に開始された、優先順位が低位または中位の情報をスケジュールし直す（たとえば、後回しにする）ことによって防止するスケジュール設定、
であった。

これらの機能は、情報を運転者に提示する各アプリケーションが、「対話コントローラ」と呼ばれるユニットに、とりわけ以下の属性、すなわち
アプリケーション識別子（ＩＤ）、（６ポイントスケールでの）メッセージ優先順位、好適な提示時、メッセージの内容、および統合ＨＭＩ（ヒューマンマシンインターフェース）用の明細、タスククラスタ内での順序、および１資源当たりに課せられる作業負荷（すなわち、各種類の感覚でメッセージが運転者にどれだけ多くの作業負荷を課すか）、
を含む「リクエスト」を送る際のデータフロープロトコルによって実現される。

作業負荷推定部によって与えられる現在の作業負荷の推定に基づいて、対話コントローラは、メッセージをいつどのように運転者に提示するかを決定する。対話コントローラは、統合ＨＭＩを介して情報を運転者に実際に提示する役割も果たす。このため、基本的なＧＩＤＳ情報管理機能は、対話コントローラの共通ＨＭＩを介して提示された情報を濾過することである。しかしながら、独自のＨＭＩを有する独立システム（たとえば、アフターマーケットおよびノマディックシステム）の統合管理を可能にする方法は開示されていない。

米国特許出願第２００２／０１２０３７４Ａ１号は、車両の内部での運転者の活動に関する運転者活動データを監視して、車両走行データ、車両環境データおよび運転者状態データを受け取る運転者動作向上システムおよび方法を開示している。運転者認知負荷を推定し、これらのデータに基づいて、車両情報を運転者に選択的に知らせるために、車両情報を優先順位化する。さらに、システムは、携帯電話、ＰＤＡおよびページャのような無線通信機器でも作動して、それぞれそれらの装置の入り呼び出し、ｅメールおよびテキストおよびデータメッセージに優先順位を付ける。

しかしながら、これらのいわゆる独立機器を本システムに統合するには、追加のハードウェハ、特にセンサ融合モジュール、および関連機器での、またはその内部の適当な処理能力が必要である。これは、不利であるとともに高コストであると見なされる。

したがって、本発明の１つの目的は、車両運転者と上記の複数の統合および／または非統合アプリケーションとの間の通信および／または対話を行うための方法およびシステムであって、それにより、この通信および／または対話が、運転者の安全性および快適性に対する危険およびそれらの低下を相当に軽減し、かつそのような通信および／または対話による運転者の作業負荷および注意散漫も相当に減少させるように行われ、または管理されるようにする方法およびシステムを提供することである。

本発明の別の目的は、独立またはモバイルアプリケーションおよびノマディックアプリケーションのようなアフターマーケットかつ非統合アプリケーションを統合し、それぞれシステムの全情報管理アーキテクチャの一部として使用することができるようにするそのような方法およびシステムを提供することである。

特に、本発明の１つの目的は、独自のヒューマンマシンインターフェースを有する非統合アプリケーションおよびノマディックアプリケーションを統合し、それぞれ同様にシステムの全情報管理アーキテクチャの一部として使用することができるようにするそのような方法およびシステムを提供することである。

最後になるが、本発明の１つの目的は、特に運転者の必要に応じたアフターマーケットおよびノマディックアプリケーションを、これらのアプリケーションによる運転者の作業負荷および注意散漫が相当に軽減されるように統合するための開放型システムアーキテクチャを提案するそのような方法およびシステムを提供することである。

これらの目的は、請求項１および１５に記載の方法、および請求項２０に記載のシステムによって解決される。

特許請求の範囲および明細書では、「アプリケーション」という用語は、起動後に、たとえば運転者への／運転者からの動作の開始、送り出しおよび／または受け取り、運転者への／運転者からのメッセージの送信および／または受信等によって、車両運転者と一方向および／または双方向に通信および／または対話することができるシステム、コンポーネント、機能、機器、ユニットおよびモジュールのすべてを包含するものとする。そのようなアプリケーションは、たとえば衝突防止システムのように非常に高性能であることもできる。

さらに、運転者／車両環境（ＤＶＥ）状態は、運転者および／または車両および／または環境のパラメータを検出するための１つまたは複数のセンサの出力信号に基づいて評価される状態である。

本発明の方法およびシステムは、出荷前に車両に実装されている統合または「ネイティブ」アプリケーションとともに、後で追加されるアフターマーケットアプリケーションなどの非統合アプリケーション、および運転者または乗員が一時的または永久的に車両に持ち込むアプリケーション（ノマディックアプリケーション）も処理することができる。

対話マネージャによる運転者およびアプリケーション間の通信および／または対話の集中管理は、高度のモジュール化、比較的簡単なシステムアーキテクチャ、および請求項１に従ってリクエストを送り、かつ応答を受け取ることができる追加アプリケーションによって簡単にシステムを拡張する可能性に対して大きな潜在性を開く。

これはまた、通信および／または対話自体が対話マネージャによって変化または変更されるのではなく（許容されるか、許容されないだけである）、関連のアプリケーションのみによって行われるためである。そのため、対話マネージャは、各アプリケーションがどの種類の通信および／または対話用に設けられているかを知る必要がなく、さらに、リクエストを送ったアプリケーションの種類を知る必要がない。

特に、リクエストおよび応答が標準化フォーマットを有する場合、本発明の方法およびシステムは、開放型システムアーキテクチャおよび標準化データプロトコルの使用を提案し、そのため、対話マネージャ自体を変化させる必要なく、それを後で組み込まれるアプリケーション（またはノマディックアプリケーション）で非常に柔軟に拡張することができる。

請求項１に従った解決策の代替または補完として、請求項１５に従って、対話マネージャが、関連のアプリケーションからのリクエストがない状態で、車両運転者との通信および／または対話を行うアプリケーション能力をＤＶＥ状態に依存して制御する場合、上記目的を解決することができる。

最後になるが、本発明の方法、システムおよびアプリケーションは、車両運転者との通信および／または対話に制限されないで、起動の場合、少なくとも１つの一定の環境状態に依存して考慮または処理されなければならない複数の信号または情報源、および／または他のそのような起動信号および／または情報源および／または他の状態にほぼ同時に直面する人との通信および／または対話にも使用される。

従属請求項は、それぞれ請求項１、１５および２０に従った方法およびシステムの有利な実施形態を開示する。

本発明のさらなる詳細、特徴および利点は、図面と組み合わせた本発明の例示的な実施形態の以下の説明から明白である。

図１に従った本発明のシステムは、Bluetoothまたは任意の他の規格で働く周知のＣＡＮバスまたはＭＯＳＴバスまたは無線ＬＡＮ（ローカルエリアネットワーク）のような多重車両バスなどで実行されることができ、以下の４つの主要コンポーネントを有する。

第１主要コンポーネントは、運転者の状態および／または車両の状態および／または環境の状態の監視および／または検出用に設けられている、考えられるすべてのタイプの、一般的に１つであるが好ましくは複数のセンサを有するセンサアレイ１である。

図１に従ったセンサアレイ１は、例示として、運転者の頭部および／または目および／またはまぶたの移動を追跡するための、たとえば頭部移動センサおよび／または注視センサおよび／または閉眼センサである運転者状態センサの第１群１０を有する。（注視方向とは、人が眼球を基準として目の注意（中心窩）を瞬間的に向ける方向である。）

第２群１１の車両状態センサは、たとえば速度センサ、加速度計、ステアリング角センサ、ペダル位置センサ、ジャイロ、タイヤ圧センサ、またはさまざまな車両関連情報を検出するための他のセンサを有する。

第３群１２の環境状態センサは、たとえばレーダおよび／またはレーザセンサおよび／またはビデオカメラを有し、たとえば周囲交通の検出および／または監視用に設けられている。

第４群１３のセンサ（たとえば、マップマッチングを伴うＧＰＳセンサ）は、車両の地上位置を検出するために設けられており、第５群１４のセンサ（たとえば、車線追従センサ）は、道路上の車両の位置および／または他の環境状態を監視する。

第２主要コンポーネントは、車両に統合されている複数のユニット、モジュールまたはアプリケーション２によって形成される。好ましくは、これらのアプリケーションは、センサアレイ１（矢印Ａ１）および／または後述する共通統合ヒューマンマシンインターフェース４３（ＨＭＩ）に属する（ディスプレイ、オーディオシステム、ボタン、ノブなどのような）入出力（Ｉ／Ｏ）装置４３１を共用する。

これらの統合ユニット、モジュールまたはアプリケーション２は、車両構造内に組み込まれた先進運転者支援システム（ＡＤＡＳ）および／または車内情報システム（ＩＶＩＳ）のコア計算機も有する。図１によれば、これらの統合アプリケーション２は、たとえば注意支援システム２１、ルートガイドシステム２２、車線逸脱警報システム２３、タイヤ圧監視システム２４、およびたとえば、ラジオ、ＣＤ、ＤＶＤその他のような情報および娯楽システム２５である。

したがって、統合アプリケーション２は、センサアレイ１の出力信号に基づいて、どの動作を取るべきか（たとえば警報の発生）を決定するために必要な計算を実行する。次に、それらは共通統合ＨＭＩ４３（矢印Ａ５）を使用して、運転者Ｄと対話することができる（矢印Ａ２）。

第３主要コンポーネントは、車両構造内に組み込まれてもよいが、統合ＨＭＩ４３に組み込まれていない複数のユニット、モジュールまたはアプリケーション３である。これらは、独立アプリケーション３と見なされる。一般的に、これらのアプリケーション３は、独自のセンサ、および／またはディスプレイ、キーボードのような入出力（Ｉ／Ｏ）装置、および／または運転者Ｄとの通信および／または対話を行うための他の非統合ＨＭＩ３４を有する。

しかしながら、図１によれば、ユニット、モジュールまたはアプリケーション３は、たとえば（統合ＨＭＩ４３に統合されてない）独自のＨＭＩを用いる統合アプリケーション３１、出荷後に車両に追加されるものを含めたアフターマーケットアプリケーション３２、および携帯電話、ポータブルメディアプレーヤ（たとえば、ＣＤプレーヤ）またはＧＰＳ受信器などのハンドヘルド形ナビゲーションシステムのようなノマディックアプリケーション３３を有する。

最後になるが、第４主要コンポーネントは、運転者情報ユニット４である。このセントラルユニットは最も重要であって、対話マネージャ４１、運転者／車両環境（ＤＶＥ）状態推定部／予測部４２、および運転者Ｄとの通信および／または対話（矢印Ａ２）用の（上記した）統合ヒューマンマシンインターフェース（ＨＭＩ）４３を含む。

対話マネージャ４１は、運転者／車両環境（ＤＶＥ）状態推定部／予測部４２からの実時間入力（矢印Ａ３）に依存して、統合ＨＭＩ４３を介した統合ＡＤＡＳ／ＩＶＩＳモジュールおよびアプリケーション２との（矢印Ａ５）、および非統合ＨＭＩ３４を介した独立アプリケーション３との運転者の通信および／または対話を管理するための（たとえば、後述するように、優先順位化アルゴリズムおよび待ち行列を実現するための）ハードウェア／ソフトウェアを含む。

ＤＶＥ状態推定部／予測部４２は、センサアレイ１の出力信号（矢印Ａ４）および／または統合アプリケーション２の少なくとも１つの出力信号（矢印Ａ５およびＡ９）に基づいて、現在および／または予測ＤＶＥ状態の（場合によっては）多次元推定量を計算して、対応のＤＶＥ状態ベクトルを対話マネージャ４１に連続的に出力する（矢印Ａ３）。

たとえば、この状態ベクトルは、主タスクデマンド（たとえば、運転状況の複雑さおよび状況が運転者にとっていかにクリティカルであるか）、副タスクデマンド（たとえば、主運転タスク以外のタスクに集中している運転者の活動）、視角的注意散漫、運転者の生理的障害（眠気、薬物の影響）、運転者の特徴（年齢、経験など）、特殊な運転状況（たとえば、別の車の追い越し）、全体的な運転環境のタイプまたは状況（たとえば、高速道路、田舎の道路、市内、田舎、郊外または市内）および運転者の個性といった基準またはパラメータの少なくとも１つを有し、および／またはそれに基づいて定められる。

状態ベクトルのこれらの基準またはパラメータは、センサアレイ１内の１つまたは複数のセンサの１つまたは複数のセンサ信号（矢印Ａ４）および／または統合アプリケーション２の１つまたは複数の出力信号（矢印Ａ５およびＡ９）、たとえば運転者状態信号（たとえば、注視方向および注意換気を表すセンサ信号）、車両状態信号（たとえば、速度、加速度、ステアリング角、ペダル位置、ジャイロ信号、タイヤ圧を表すセンサ信号）および／または環境状態信号（たとえば、道路のタイプ、路面状態、周囲の障害物、地上位置などを表すセンサ信号）に基づいて、ＤＶＥ状態推定部／予測部４２内のサブモジュールによって計算されることができる。

ＤＶＥ状態推定は、未来状態の予測も含むであろう。ＤＶＥ状態ベクトルの正確な定義は、対話マネージャ４１の必要（すなわち、対話管理機能に何の情報が必要であるか）に基づく。

最後に、運転者情報ユニット４は、運転者Ｄ（矢印Ａ２）と統合ＡＤＡＳ／ＩＶＩＳモジュールおよびアプリケーション２（矢印Ａ５）との間の主インターフェースである統合ヒューマンマシンインターフェース（ＨＭＩ）４３を有し、これは、運転者Ｄが異なった感覚の種類で、または異なった感覚伝達路（視覚、聴覚、触覚）を介してシステムとの通信および／または対話を行うことができるようにする１つまたは複数のＩ／Ｏ装置４３１を含む。独立アプリケーション３は、通常は独自の組み込みＨＭＩを有するため、統合ＨＭＩ４３を使用してもよいが、その必要はない。そのため、運転者Ｄは、場合によっては独自の組み込みＨＭＩを介して（矢印３４）独立アプリケーション３との通信および／または対話を行うことができる。

図１に従ったシステムによって実行される本発明の方法の第１の主要特徴は、アプリケーション開始情報、すなわち、運転者Ｄとの通信および／または対話を、現在および／または予測運転者／車両環境（ＤＶＥ）状態に依存してスケジューリングすることである。

第２の主要特徴は、運転者Ｄとの通信および／または対話を幾つかの異なったアプリケーション２、３によって同時に開始する（リクエストが待ち行列に入れられ、是認を待っており、第２通信および／または対話のリクエストが受け取られる場合を含む）とき、システムは（一定の基準に基づく、以下を参照）優先順位化に基づいて最重要通信および／または対話を選択する。他の通信および／または対話は待ち行列に入れられて、後で優先順位の順に実行される。

次に、これらの両方の特徴をさらに詳細に説明する。

非統合アプリケーション３を無線または物理的リンクを介してシステム（車両ネットワーク）に接続するとき、対話マネージャ４１（またはアプリケーション３）による開始が、たとえばアプリケーション３およびシステム間の周知のハンドシェイクに含まれる。対話マネージャ４１は、アプリケーションが対話マネージャ４１と適合するか、すなわちアプリケーションを対話マネージャ４１によって制御できるかどうかをチェックする。アプリケーションが標準設定でそのような適合性を有していない場合、対話マネージャ４１（またはアプリケーション３）は、アプリケーション３を対話マネージャ４１と適合させるために必要な適当なソフトウェアをダウンロードおよび／またはインストールできるかをチェックする。

そのようなソフトウェアがアプリケーション３および／または対話マネージャ４１によってダウンロードされ、かつうまくインストールされる場合、またはアプリケーションが開始時から対話マネージャ４１と適合する場合、対話マネージャ４１は、このシステム内で独特の識別番号をアプリケーションに動的に割り当てる。このアプリケーションは、それが対話マネージャ４１に接続されている限り、すなわちアプリケーションおよびシステム間のリンクが存在する限り、割り当てられた識別番号を保持するであろう。リンクが終了した後、アプリケーションが再び接続されると、新しい（おそらくはやはり同じ）識別番号がアプリケーションに割り当てられる。

アプリケーション２、３が運転者Ｄと通信および／または対話する前に、対話マネージャ４１で第１ルーチンを実行する（矢印Ａ６およびＡ７）必要があり、たとえば、これは以下のステップを含む。

１．たとえば、情報またはメッセージの特定部分を提示する形での運転者Ｄとの通信および／または対話を許可するために、好ましくは標準化フォーマット（以下を参照）の形のリクエストを発生して、対話マネージャ４１に送る。

２．対話マネージャ４１からの（好ましくはやはり標準化フォーマットの形の、以下を参照）応答を待つ。この応答は、（ａ）「許可を承諾、前に進め」または（ｂ）「許可を拒否、待って通信および／または対話を差し控える」のいずれか一方の表示を有する。

３．一定時間内（通常は＜１秒）に応答を受け取らない場合、リクエストが再び送られる。このステップをｎ回（ｎ＝規定数＝０、１、２、・・・）繰り返すことができる。最後に、それでも応答を受け取らない場合、診断メッセージを出力する。

好ましくは、バスまたは無線ＬＡＮ上でのリクエストの紛失を考慮するために、リクエストを数回（たとえば、３〜１０回）送る。しかしながら、数回の試行後、リクエストを送るアプリケーションは、対話マネージャ４１がもはや使用できない（たとえば、対話マネージャ４１に何らかの問題がある）と考えて、アプリケーションが診断メッセージを、たとえば診断バスに出力するが、好ましくはこのメッセージに関して運転者と通信および／または対話を行わない。

このプロシージャは、アプリケーションが、特定システム内に対話マネージャ４１が存在するか否かを検出するのにも適用可能である。これは、一定のアプリケーションを対話マネージャを伴わないシステムで使用する必要がある場合、適切であろう。このアプリケーションが両システムで同一のソフトウェアを使用するために、アプリケーションは、対話マネージャが存在するか否かをチェックしなければならない。存在しない場合、アプリケーションが切り換わって、独立モードで働く、すなわち、運転者および／またはＨＭＩおよび／または車両および／または環境の状態に関係なく、それは運転者と通信／対話するであろう。そうでなければ、それは上記ルーチンに従う。このため、同一アプリケーションを対話マネージャ制御システムとともに、対話マネージャがないシステムの両方で使用することができる。これにより、（特に一定のトラックモデルで使用するための）アプリケーションのモジュール化が相当に増加する。

４．リクエストが最終的に拒否される場合、リクエストされたように運転者Ｄとの通信および／または対話を行うために、対話マネージャからの許可を待つ。

リクエストをアプリケーション２、３から受け取ったときに対話マネージャ４１が実行すべき第１ルーチン内の対応部分は、たとえば、以下のステップを含む。

１．リクエストされた通信および／または対話が現在および／または予測ＤＶＥ状態に依存して許可されることができるか、および／またはリクエストが他のアプリケーション２、３から受け取られているかどうかを決定する。

２．許可を与えることができる場合、（ａ）「許可を承諾、前に進め」の表示を有する応答を、そのリクエストを出したアプリケーション２、３に送る。

３．許可を与えることができない場合、リクエストを待ち行列内に保存して、（ｂ）「許可を拒否、待って通信および／または対話を差し控える」の表示と、おそらくはさらなる応答を待てという命令とを有する応答を関連のアプリケーション２、３に送る。

そのような応答は、待ち行列内のリクエストの数に関する表示を含むことができる。好ましくは、この場合、応答は循環的に、またはより高い優先順位の別のリクエストが待ち行列から離れるたびに繰り返される。

４．許可を与えることができ、１つまたは複数のリクエストが待ち行列内に保存されている場合、最高優先順位を有するアプリケーション２、３のリクエストをピックアップして、「前に進め」の表示を有する応答をこのアプリケーション２、３に送る。待ち行列内に保存されているリクエストがすべて許可されるまで、これが繰り返される。

アプリケーションがそのリクエストを撤回する場合、それは好ましくは、削除メッセージを対話マネージャに送り、それにリクエストを待ち行列から除去するように命令する。これは、「動的優先順位」に関する以下の説明に従って処理される。

たとえば、安全性が非常にクリティカルなメッセージタイプを発生する一定のアプリケーション２、３では、このルーチンを完全に飛び越すことができ、待ち行列内に何のリクエストが保存されているかに関係なく、メッセージを押し進める。代替として、安全性が非常にクリティカルなメッセージも（スケジューリングではなく）優先順位化に含んで、対話マネージャによって処理することもできるであろう。これにより、そのような安全性が非常にクリティカルなメッセージは、必須ではないが好ましくは、ＤＶＥ状態に関係なく処理されることができるが、それらは他のリクエストと同じプロシージャに従う。このプロシージャが必要とする時間が長すぎる場合、別の代替として、より高い優先順位のそのような安全性にクリティカルなメッセージが現時点で運転者にまったく送られていない場合のみ、安全性にクリティカルなメッセージを通過させる（それにより、幾つかのアプリケーションおよび／またはシステムが一定のシナリオで進行する場合、最高優先順位の安全性にクリティカルなメッセージだけが押し進められるであろう）。

これらの場合、好ましくは現在の安全性にクリティカルでないリクエストを、最高予想優先順位を安全性にクリティカルでないリクエストのために取ってある待ち行列に（再び）入れて、上記第１ルーチンに従って、および／または安全性にクリティカルなメッセージが提示されるとすぐに、許可する。

次に、これらのリクエストおよび応答のためのデータフロープロトコルの詳細をより詳細に説明する。

異なった統合および／または非統合アプリケーション２、３によって対話マネージャ４１に送られた、運転者Ｄとの通信および／または対話のリクエストは、対話マネージャ４１が発生して送る応答とともに、好ましくは標準化フォーマットに従う。

アプリケーションによって送られたリクエスト用のそのようなフォーマットおよびデータ構造は、たとえば以下のフィールドを有する。

１．アプリケーションの識別
このフィールドは、そのリクエストを送るアプリケーション２、３の識別子を含む。ノマディックアプリケーション３３の場合、それが車両ネットワークに接続されたとき、または接続されている限り、この識別子は、上記のような対話マネージャ４１によってアプリケーション３３に動的に割り当てられるであろう。データタイプは好ましくは「整数」である。

２．通信および／または対話の識別子
このフィールドは、アプリケーション２、３によってリクエストされた運転者Ｄとの通信および／または対話（たとえば、「低燃料」メッセージ、入り電話呼び出し、車両診断メッセージ、ルートガイドメッセージなど）の識別子を含む。データタイプは好ましくは「整数」である。しかしながら、識別子は通信／対話自体のタイプに関係なく、単に「整」数である。

３．優先順位インデックス
このフィールドは好ましくは、標準化された方法、たとえばＳＡＥ Ｊ２３９５によって定められた通信および／または対話の優先順位インデックスを表す浮動数を含む。整数ではなく浮動数によって優先順位インデックスを表すことには、独特の優先順位を生じるという利点がある。そうでなければ、同一の優先順位インデックスの２つの通信および／または対話を開始すると、好ましくは周知の先入れ先出し原理（すなわち、最初に開始されたメッセージが最初に提示される）が適用される。したがって、データタイプは好ましくは「浮動」である。

対話マネージャ４１の応答は好ましくは、たとえば以下のフィールドを含む標準化フォーマットおよびデータ構造によって表される。

１．アプリケーションの識別
このフィールドは、そのリクエストを送るアプリケーション２、３の識別子を含む。データタイプは好ましくは「整数」である。

２．通信および／または対話の識別
このフィールドは、リクエストによってリクエストされた（たとえば上記のような）通信および／または対話の識別子を表す。データタイプは好ましくは「整数」である。

３．返答
このフィールドは、（ａ）「許可を承諾、前に進め」または（ｂ）「許可を拒否、待って通信および／または対話を差し控える」のいずれか一方についての表示を有する、リクエストに対する返答を含む。データタイプは好ましくは「ブーリアン」、たとえば（ａ）の場合は「１」、（ｂ）の場合は「０」である。

これらのルーチンは、対話マネージャ４１がすべてのアプリケーション２、３の更新リストおよび（関連のアプリケーションが実行することができる）すべての通信および／または対話の更新リストおよび（ＧＩＤＳプロジェクトに従った従来技術のように）それらの優先順位を保持する必要なく、上記の標準フォーマットおよびデータ構造に従った、アプリケーション２、３を制御する簡単な方法を構成する。これは、近い将来の、たとえば(Bluetoothのような)無線リンクを介した車両データバスへの継ぎ目のない接続を予想することができるノマディックアプリケーション３３の場合に特に有益である。

これらのルーチンの可能な実現を以下に例によって説明する。

ノマディックアプリケーション製造者は、一定のＰＤＡを開発している。それは、ＰＤＡによって開始されるすべての可能な通信および／または対話のリストを作成して、標準化方法を使用し（たとえば、ＳＡＥＪ２３９５に従って）、関連テーブルをＰＤＡに保存することにより、その各々に優先順位インデックスを割り当てている。実際に、これは認定機関によって行われることもできる。すべての可能な対話および／または通信のリストを作成する代わりに、製造者は可能な対話および／または通信群のリストを作成し、群全体に同一の優先順位を割り当てることができる。これは、すべての可能な対話および／または通信を予想することが不可能である場合、特に動的対話および／または通信がある場合に好都合であろう。

対話マネージャ４１へのリクエストの送信およびそれからの応答の受信に関する上記ルーチンは、ＰＤＡでも実行され、それにより、車両バスに接続されたとき（かつ対話マネージャ４１が上記のようにＰＤＡにアプリケーション識別子を割り当てた後）、それは常に所望の通信および／または対話（およびその優先順位）に関するリクエストを対話マネージャ４１に送って、運転者Ｄとの通信および／または対話（たとえば、情報の提示および／または動作の開始）を行う前に、該許可を表す応答を待つ。

別の可能性は、特に上記テーブルの保存および／または上記ルーチンの実行に適さないアプリケーション用のアダプタを設けることである。この場合、アダプタは、システムとのインターフェースの機能を有して、上記ルーチンを実行する。

対話マネージャに適合しないアプリケーション、たとえば携帯電話の場合、アプリケーションまたは対話マネージャはインターネットから、またはサービスプロバイダを介して、アプリケーションおよび対話マネージャ間の対話を可能にするソフトウェアをダウンロードすることもできるであろう。これは、（たとえば、これが有料である場合）適正な人／アプリケーションがそのようなアダプタプログラムを必要としているという認可／防護対策を必要とする契約などに付されるであろう。これを防護するために、たとえば公開鍵暗号化方法などの暗号化を使用することができる。

要約すると、対話マネージャ４１は、どのアプリケーション２、３がリクエストを送ったかを知る必要がない。対話マネージャ４１は、アプリケーションＸが、好ましくは優先順位インデックスＰが付いた通信および／または対話Ｙ（たとえば、メッセージの提示）を行う許可を求めていることを知ることで、ＸおよびＹが何であるかを知らなくても、十分である。必要とされる唯一の余分な標準化は、たとえば上記に開示されているように、リクエストおよび返答用の特定フォーマットおよびデータ構造またはプロトコルである。

フォーマットおよびデータ構造は、実行すべき通信および／または対話の追加情報を含むように拡張させることができる。この情報はオプションである（この情報が欠落している場合、それはデフォルト値に置き換えられる）。

デフォルト値を有する事前設定されたデータシーケンス構造の代替として、一定データが欠落している場合、固有のコードまたはアドレスであって、それにつながれたデータに先行し、かつ対話マネージャがこのコード／アドレスに続くデータタイプを識別できるようにする固有のコードまたはアドレスを、各可能タイプのデータ（上記したようなアプリケーション識別、通信および／または対話識別、優先順位インデックスなど）に割り当てることが可能である。言い換えると、これは一種の動的プロトコルであり、それは、たとえば「アプリケーションＩＤ」：ＸＸ、「メッセージＩＤ」：ＹＹ、「優先順位インデックス」：ＺＺのように見え、その場合、次のフィールドは任意の他のデータであることができるが、好ましくはデータに先行するものであり、識別子、たとえば「継続時間」：ＡＡまたは「聴覚負荷」：ＢＢがある。

リクエストに追加されることができる追加情報の幾つかの例を以下に示す。

４．通信および／または対話の継続時間
このフィールドは、運転者が通信および／または対話に必要とする、たとえばメッセージの場合、メッセージを理解するのに必要である推定時間を表す。これはまた、後続の通信および／または対話を実行することができるまでの時間（秒単位）でもある。データタイプは好ましくは「浮動」である。

しかしながら、安全性関連リクエスト（または一定の事前設定された優先順位の任意の他のリクエスト）は、優先順位がより低い別のメッセージ／動作が現在活動中であるかどうかに関係なく、常に直ちに処理される。優先順位が高いメッセージ／動作は、他のメッセージ／動作に割り込んで進められるであろう。要約すると、安全性にクリティカルなメッセージ、たとえば（一定閾値より上の優先順位の）警報を処理するための好適なプロシージャを以下に示す。
ａ．）ＤＶＥ状態に関係なく、メッセージを押し進める。
ｂ．）そのメッセージは、現在活動中である低位または中位の優先順位のいずれのメッセージもオーバーライドし、好ましくはそのような現在メッセージを、最高予想優先順位を安全性にクリティカルでないメッセージ（またはリクエスト）のために取ってある待ち行列に入れて保持する。
ｃ．）ほぼ同時に開始される幾つかの安全性にクリティカルなメッセージを優先順位の順に提示する。

５．視覚負荷
このフィールドは、運転者の視覚伝達路に加えられる負荷を表す。データタイプは好ましくは「整数」である。

６．聴覚負荷
このフィールドは、運転者の聴覚伝達路に加えられる負荷を表す。データタイプは好ましくは「整数」である。

７．触覚負荷
このフィールドは、運転者の触覚伝達路に加えられる負荷を表す。データタイプは好ましくは「整数」である。

本発明の方法の第１の好適な拡張は、動的優先順位の処理である。

幾つかのアプリケーション２、３では、リクエストの優先順位が経時的に変化するであろう。この一例は、「次の交差点で右折してください」というようなルートガイドメッセージであり、それは、車両がその交差点に近づくほど、それに応じて緊急かつ重要になる。そのような動的優先順位を考慮する簡単な方法は、識別子が同一であるが、優先順位が異なる多数リクエスト、たとえば、交差点まで１００〜２００メートルあるときのメッセージの第１リクエスト、および交差点まで１００メートル未満であるときの同じメッセージの第２リクエストを使用することである。しかしながら、これは、第１リクエストが不適切になって、更新リクエストに置き換えられるとき、それを対話マネージャ４１で待ち行列から取り除くことを必要とする。他の場合では、リクエストを置き換えないで待ち行列から削除することが必要であろう。

別の例は、入り呼び出しのリクエストが対話マネージャによって拒否される場合である。電話アプリケーションは、一定時間、たとえば５秒後にはより高い優先順位の更新リクエスト（同一のメッセージＩＤ）を送るが、それは、発信者が電話を切る危険性が時間とともに高まるので、呼び出しに応えることの緊急性が高まるからである。このシステムの重要な特徴は、呼び出しまたは情報が失われる危険性を低減させることである。好ましくは、発信者は、待ち行列内での呼び出しの回数または段階について定期的に更新された情報を得る。

そのような動的優先順位を達成するために、リクエストの標準フォーマット（プロトコル）を、待ち行列上のリクエストされた操作を追加＿リクエスト、置換＿リクエストまたは削除＿リクエストのいずれかとして特定するフィールドによって拡張する。

８．リクエストのタイプ
このフィールドは、リクエスト（または動作）のタイプを表し、これは３つの値、すなわち０＝追加＿リクエスト、１＝置換＿リクエストおよび２＝削除＿リクエストをとることができる。データタイプは好ましくは整数である。

本発明の方法の第３主要特徴は、アプリケーション２、３の運用状態を対話マネージャ４１により、現在および／または予測ＤＶＥ状態に基づき、かつそれに依存して制御すること（すなわち、操作または機能のモードの制御）である。これは、たとえばアプリケーション２、３（または全アプリケーションの１つまたは複数）の機能の使用可能および／または使用不可、および／または関連ＨＭＩ３４、４３の実時間再設定を含むことができる。

本発明の例示的かつ好適な実施形態によれば、これは、統合ＨＭＩ４３について、それを図１の矢印Ａ８に示されているように対話マネージャ４１の直接制御状態下で設定することによって達成される。

独自の組み込みＨＭＩ３４を有する非統合（独立）アプリケーション３１の場合、これらのアプリケーション３１に命令を送ることにより、設定が対話マネージャ４１によって制御される。

これらの命令は、追加メッセージタイプと見なされ、標準フォーマット（プロトコル）を有し、そのため、それは対話マネージャ４１により、たとえば、これらのアプリケーション２、３の運用状態または操作または機能（複数可）モードの制御、または全アプリケーションの１つまたは複数２、３の使用可能および／または使用不可を含めた関連ＨＭＩ３４、４３の設定に使用されることができる。

これを実現するための１つの可能性は、ＤＶＥ状態推定部／予測部４２によって認識されることができる１組の標準運転状態Ｓ_１・・・Ｓ_ｎを定めて提供することである。簡単な場合は２タイプの状況、すなわちＳ_１＝車両停止中およびＳ_２＝車両移動中であろう。より高度なＤＶＥ監視技術を使用する場合、状況には、たとえばＳ_１＝停止中（エンジン停止＝駐車中）、Ｓ_２＝停止中（エンジンアイドリング＝交通信号灯または交差点での一時停止）、Ｓ_３＝高速道路走行中、Ｓ_４＝市内を走行中、Ｓ_５＝追い越し中、Ｓ_６＝運転者が眠いなどが含まれる。

次に、現在運転状況インデックスＳ_ｎを対話マネージャ４１によってすべての非統合（独立）アプリケーション３に（おそらくは統合アプリケーション２にも）分散させる。その場合、これらのアプリケーション３の開発者は、運用状態または操作または機能（複数可）モードが現在運転状況インデックスＳ_ｎによっていかに決定されるかを規定する参照テーブルを定める必要があるであろう。非統合アプリケーション３の運用状態または操作または機能（複数可）モードの状況依存制御のためのそのような参照テーブルが図２に例示されている。本例では、運用状態は、運転者状況インデックスＳ１〜Ｓ４に依存した、関連アプリケーションの一定の機能Ｆ１〜Ｆ８の使用可能／使用不可によって定められる。

簡単な例として、Ｆ５＝「ＤＶＤプレーヤ」、かつＳ１＝「車両停止（エンジン停止＝駐車中）」と仮定する。したがって、図２のテーブルは、ＤＶＤプレーヤは車両の駐車時のみ使用可能であるように規定している（ブラックボックスは機能が使用可能であることを表し、ホワイトボックスは機能が使用不可であることを表す）。

参照テーブルは、単なる機能の使用可能／使用不可より複雑な運用状態を表すために一般化されることもできる。簡単な例では、このテーブルは、「オン」／「オフ」または「大音量」／「静穏」または「明」／「暗」などのタイプの二重状態を含む。より高度なシステムでは、このテーブルはｎ状態（非常に大音量、大音量、中、より静穏、絶対静穏）を有してもよく、その場合、これは同様にＤＶＥパラメータの関数である。

このため、この制御は、対話マネージャ４１が運転状況インデックスＳ_ｎを分散させるために利用することができるメッセージタイプを必要とする。（対話マネージャによって分散された）使用可能／使用不可機能用に提案されたメッセージフォーマットは好ましくは、以下のように特定される１つのインデックスだけを有する。

運転状況インデックス
このフィールドは、好ましくは現在の一般的運転状況インデックスＳ_ｎを表す整数値である。

本発明の方法の第２の好適な拡張は、テキストコンバータによってテキスト−音声またはテキスト−表示出力を処理することである。

テキスト−音声またはテキスト−表示は、未来の自動車におけるＨＭＩの一般形式になりそうである。基本的な着想は、より長いテキスト（たとえば、ｅメール）への運転者のアクセスを、それ全体をディスプレイから読むときに過度な視覚的注意散漫を加えることなく、提供することである。しかしながら、音声テキストの理解はそれでも運転者に認知負荷を加え、これは、大変および／またはクリティカルな運転状況における過負荷に起因するであろう。車内で運転者に話しかける乗員は通常、運転者の作業負荷が運転タスクによって増加するときに中断することによって、この問題を回避する。提案された機能の着想は、ＤＶＥ状態推定部／予測部からの出力に基づいてテキスト出力をスケジュールすることである。この一般的な原理が図３に示されている。

図３は、統合または非統合アプリケーション２、３であることができるアプリケーションの特殊形と見なされることができるテキストコンバータ２６の好適な実施形態を示す。出力すべきテキストに関して、２種類のケース、すなわち
ａ）事前チャンクドメッセージ、たとえばルートガイドシステムＡが発生するルートガイドメッセージ、および
ｂ）非事前チャンクドメッセージ、たとえばｅメールまたはＳＭＳシステムＢが発生する、実時間構文解析が必要であるｅメール、
を考慮しなければならない。

アプリケーション２６は一般的に、概略的に上述した方法に従って処理される。図３に示されているような好適な実施形態では、以下のプロシージャが実行される。

１）生テキスト表現「Ｘ１−Ｘ２−Ｘ３」（音声に変換されて出力されるべきテキストセグメントＸ１、Ｘ２、Ｘ３を有する任意のテキストを表す）を、ルートガイドシステムＡおよび／またはｅメールまたはＳＭＳシステムＢのような情報システムによって開始する。（ Ｘ１、Ｘ２、Ｘ３は段落、文、句、語、文字、図などであることができる。）

２ａ）第１の場合（ルートガイドシステム）では、テキストは、情報システム自体によって予めチャンクされることができる。これは一般的に、事前に定められたメッセージ（ルートガイドメッセージまたは同様のメッセージ）で可能である。この場合、メッセージは、直接的にアプリケーション２６内に設けられた待ち行列２６２に進められる。

２ｂ）別法として、ｅメールおよびＳＭＳ（Ｂ）の場合のように、メッセージを事前チャンクしなくてもよい。この場合、生テキストは構文解析部２６１に送られ、それはテキストを文法カテゴリに分化する（構文解析部２６１は、たとえばテキストを段落、文、句、語などのような階層的文法カテゴリに分化するために記憶辞書および文法を用いるソフトウェアの一部である）。

このため、構文解析部２６１は、テキスト「Ｘ１−Ｘ２−Ｘ３」をチャンクＸ１、Ｘ２およびＸ３（句）にスライスし、それを提示の順序で待ち行列２６２に入れる。

文法的構文解析のより簡単な代替例は、テキストを意味のあるチャンクに分割するために、特定の分割記号、たとえばコンマ、句読点および／またはコロンを探すだけであろう。

３）テキストチャンクＸ１、Ｘ２およびＸ３は、上記の方法に従った通信および／またはアプリケーションのように処理される。このため、音声発生器２６３は対話マネージャ４１にリクエストを送って、提示が許可されたことを確認する応答を待つ。

４）チャンクＸ１、Ｘ２および／またはＸ３が一定の第１時間より長く、たとえば１０秒間保持される場合、理解を容易にするために、好ましくは先行のチャンクを繰り返す。チャンクＸ１、Ｘ２および／またはＸ３が第２時間より長く（たとえば２０秒間）保持される場合、２つの先行チャンクを繰り返す、などを行う。

繰り返しチャンクが論理単位を形成するかどうかに関係なく、個々のテキストチャンクまたはそのようなチャンクの群を待ち時間に応じて繰り返す代わりに、より進歩したシステムでは、システムは論理単位を形成するチャンク（特に待ち時間が長すぎる場合、語または句の代わりに文全体、または文の代わりに段落全体）を繰り返すであろう。構文解析部２６１は、文法構造だけでなく内容も認識する知的なもの（意味構文解析部）であろう。そのような論理単位を識別するために、自然言語処理システムに使用される方法がこの場合に適用可能であろう。

５）メッセージが中断された（すなわち、チャンクが保持された）場合、好ましくは運転者にこれを、たとえば特徴的な音または「メッセージ中断」または「停止」などの短い音声メッセージによって知らせる。

音声発生器２６３の代わりに、適当なディスプレイ（図示せず）を設け、それが、リクエストを対話マネージャ４１に送り、かつディスプレイ上でのチャンクの表示が許可されることを確認する応答を待つように（追加手段によって）設けられる場合、それによってテキストチャンクＸ１、Ｘ２、Ｘ３を表示することができる。

最後になるが、各テキストチャンクＸ１、Ｘ２、Ｘ３を音声として出力し、かつ同時に、または時間遅れを伴ってディスプレイ上に表示することができ、それにより、運転者はそのテキストを聴くとともに、ディスプレイ上で読むことの両方ができる。

本発明のこの実施形態は、音声メッセージの管理および出力用であるが、図３に示されている一般的原理は、他のメッセージタイプにも同様に適用されることができるであろう。

図４は、本発明に従ったシステムの例示的かつ好適な実施形態の第２機能的アーキテクチャを示す。このシステムは実質的に、１つのセントラルユニット５１と複数のローカルユニット、本例では２つのローカルユニット５２、５３とを有する。

セントラルユニット５１は、主情報を制御する対話マネージャまたは運転者車両環境マネージャ５１１と、資源マネージャ５１２とを有する。この主情報および資源マネージャ５１２は、情報管理用および資源管理用に設けられて、たとえばディスプレイおよび／またはスピーカのような１つまたは複数のＨＭＩ装置５１３を制御する。さらに、主情報および資源マネージャ５１２は、複数のアプリケーション５１４（たとえば、ラジオ、電子制御装置ＥＣＵ、ＶＥＣＵなど）からリクエストを受け取って、ＨＭＩ装置５１３との通信を許可する、または許可しないという応答を上記のようにこれらのアプリケーション５１４に送り、ここでアプリケーション５１４は少なくとも１つのＨＭＩ装置５１３に接続されている。

図４は、たとえば、後述する第２ローカルユニット５３用のＣＡＮまたはＬＩＮバスＢ２を介してゲートウェイユニットとしても追加的に機能している第１ローカルユニット５２を示す。ユニット５２は、情報管理用ではなく、資源管理用に設けられ、かつ、たとえば統合または非統合ＨＭＩの形の、たとえばディスプレイおよび／またはスピーカのような１つまたは複数のＨＭＩ装置５２３を再び制御するローカル資源マネージャ５２２を有する。

第１ローカルユニット５２はさらに、携帯電話、ハンズフリー電話および／またはフリート管理システムなどのような複数のアプリケーション５２４を有し、図１〜図３に関連して上述したように、これらのアプリケーションはローカル資源マネージャ５２２にリクエストを送り、それから応答を受け取る。アプリケーション５２４もやはり、ＨＭＩ装置５２３に接続されてそれと通信できるようになっている。

さらに、ローカル資源マネージャ５２２は、たとえばＣＡＮバスＢ１を介して、セントラルユニット５１内の主情報および資源マネージャ５１２に接続されて、図１〜図３を参照しながら開示した方法に従って、それにリクエストを送り、それから応答を受け取るようになっている。

たとえば、車両の他のシステムの形の第２ローカルユニット５３も、情報管理ではなく資源管理用に設けられているローカル資源マネージャ５３２を有する。

やはり図４による第２ローカルユニット５３は、独自の、および／または統合または非統合ＨＭＩ装置５３３を有する少なくとも１つのアプリケーション５３４（たとえば、ノマディックアプリケーション、携帯電話、ナビゲーションシステムなど）を有し、それにより、上述したように、ローカル資源マネージャ５３２にリクエストを送り、それから関連応答を受け取った後、そのアプリケーションを制御することができる。

最後になるが、ローカル資源マネージャ５３２は、たとえばＣＡＮバスまたはＬＩＮバスＢ２を介して、ゲートウェイとして機能している第１ローカルユニット５２のローカル資源マネージャ５２２に接続されており、それにより、ローカル資源マネージャ５３２は、セントラルユニット５２内の主情報および資源マネージャ５１２にリクエストを送り、それから応答を受け取ることができる。

この第２アーキテクチャにより、中央情報管理であるが、分散資源管理が行われる。これは、ローカルユニット５２、５３内で（かつ、おそらくはローカルユニット５２、５３間で）ローカル資源マネージャ５２２、５３２によって資源管理だけが行われるが、ローカルユニット５２、５３とセントラルユニット５１との間で（おそらくはゲートウェイとして別のローカルユニットを介して）情報管理が、また必要ならば、資源管理も行われることを意味する。

異なった必要および異なったローカルユニットを有する異なった車両により容易に適応することができ、かつ特に共通バスシステム（特にＣＡＮバス）Ｂ１、Ｂ２が使用されている場合、さらなるローカルユニットをシステムに接続することが比較的容易であるため、このアーキテクチャはより高い柔軟性を与える。

セントラルユニット５１が、すべての製造車両にとって標準装備であり、かつそのような車両の一般的なユーザの必要を満たす基本機能性を備えていれば、特に有利である。任意選択であるが、特別な必要の場合、特別な機能を果たし、かつ同様に車両の製造後に個別に組み込まれることができる１つまたは複数の特定またはローカルユニット（「アドオンモジュール」）５２、５３によってそのような基本システムの機能性を拡張することができる。

図５は、本発明に従ったシステムの例示的かつ好適な実施形態であるが、図４に示されたゲートウェイアーキテクチャとは異なって、スター形ネットワークアーキテクチャを有する第３機能的アーキテクチャを示す。しかしながら、両方のアーキテクチャを組み合わせることもできる。

やはり、図４のセントラルユニット５１とほぼ同一のコンポーネントを有するセントラルユニット５１が設けられている。しかしながら、主情報および資源マネージャ５１２は、スター形ネットワークアーキテクチャの必要に応じて設けられている。好ましくは、やはり図４に開示されているように、第１ローカルユニット５２および第２ローカルユニット５３にそれぞれ対応する第１ローカルユニット５２および第２ローカルユニット５３が同様に設けられている。これらのユニット５１、５２および５３に関しては、上記の図４に関連した説明を参照されたい。

図５に従ったシステムアーキテクチャはさらに、第３ローカルユニット６４および第４ローカルユニット６５を有する。第３ローカルユニット６４は、たとえば安全性および／または警報（警告）装置の形の、たとえば時間がクリティカルな機能性を備え、その装置は、たとえばＦＣＷ（正面衝突警報）、ＬＤＷ（長距離警報）、ＡＣＣ（適応定速走行制御）のような複数の関連の安全性アプリケーション６４４からリクエストを受け取り、応答を送る能動安全性ＨＭＩマネージャ６４２を有する。

さらに、これらのアプリケーション６４４によって制御されるディスプレイ６４３が設けられている。この第３ローカルユニット６４とその他のローカルユニット５２、５３および６５との基本的な違いは、それが同様に安全性にクリティカルなアプリケーション６４４の少なくとも１つから関連リクエストを受け取った（かつそれらの応答を送って、ディスプレイ６３４上に警報または警告信号を発生する）場合、その時間がクリティカルな機能性のために、能動安全性ＨＭＩマネージャ６４２は警報状態を知らせる情報信号をバスＢ３を介してセントラルユニット５１内の主情報および資源マネージャ５１２に送信するだけであることにある。

システムアーキテクチャに接続されることができる別のローカルユニットの一例として、図５は、関連のディスプレイ６５３を制御するＡＭＩ−Ｃ（自動車マルチメディアインターフェースコラボレーション）内容ベースのＨＭＩマネージャ６５２の形のローカル資源ＨＭＩマネージャを有するローカルユニット６５を示す。

このユニット６５はさらに、好ましくはＸＭＬフォーマットの内容ベースの情報をユニット６５２を介してディスプレイ６５３に送るために設けられた複数のアプリケーション６５４を有する。ＡＭＩ−Ｃ内容ベースのＨＭＩの原理は、２００４年３月のSAE Technical Paper Series ２００４−０１−０２７２のL. JalicsおよびF. Szczublewskiによる「AMI-C Content-Based Human Machine Interface (HMI)（ＡＭＩ−Ｃ内容ベースのヒューマンマシンインターフェース）」に開示されており、この論文は参照により本開示の一部に援用される。

再び、図１ないし３を参照しながら説明されている上記方法に従って、ＨＭＩマネージャ６５２はリクエストをセントラルユニット５１内の主情報および資源マネージャ５１２に（バスＢ２を介して）送ることができ、かつ、それから応答を受け取った後、たとえばアプリケーション６５４の１つによって送られた内容をディスプレイ６５３上に表示することができる。

たとえば警報信号が能動安全性ＨＭＩマネージャ６４２から主情報および資源マネージャ５１２にバスＢ３を介して送られた場合、ＨＭＩマネージャ６５２は関連の応答信号をバスＢ２を介して受け取り、内容をディスプレイ６５３に送ろうとしているアプリケーション６５４をオフに切り換える。内容ベースのアプリケーション６５４はノマディックアプリケーションであることもできる。

図５に示されているようなシステムアーキテクチャは、図４に関連して述べたものとほぼ同一の利点を有する。一般的に、セントラルユニットおよびローカルユニット間の通信は、車両内に設けられた同一の、または異なったローカルバスシステムＢ１、Ｂ２、Ｂ３、Ｂ４を介して行われることができ、Blue Toothなどの無線通信システムも同様に使用することができる。さらに、ユニット間およびユニット内で信号を送るためのプロトコルは、同一でも、異なってもよい。

冒頭部分に述べたように、本発明の方法、システムおよびアプリケーションは、車両運転者との通信および／または対話に制限されない。

たとえば、車両運転者の代わりに、人がモーターボート、帆船または他のヨットまたは船の船長またはスキッパであることができる。これらの場合、ノマディックアプリケーション３３は、たとえば携帯電話、ポータブル媒体（たとえばＣＤ）プレーヤ、携帯ラジオ、ＰＤＡおよび／またはＧＰＳ受信器のようなハンドヘルド形ナビゲーションシステムなどであって、船長またはスキッパがそれを搭載して、ヨット、ボートまたは船の操縦中に使用し、かつそれは上記ノマディックアプリケーション３３に関する開示内容に従って処理される。

したがって、本発明の方法、システムおよびアプリケーションは、港および／または航行密度が高い他の領域または水路の付近で船の制御および案内を行うための制御ステーションで適用可能である。これらの場合、人は、船の航行の監視中、たとえば自分の携帯電話または他のノマディックアプリケーション３３を使用する航行管理官または職員であり、移動電話などは、上記ノマディックアプリケーション３３に関する開示内容に従って処理される。

したがって、本発明の方法、システムおよびアプリケーションはさらに、発電所や工業に、特に人が、たとえばプロセスが正確に進行していることを監視して確認しなければならないオペレータである管理室に適用可能である。この場合、さまざまな事象に対して異なったアラーム／メッセージを、上記開示内容に従った対話マネージャによって制御することができる。たとえば、故障が発生した場合、最重要かつクリティカルな情報（オペレータが直ちに反応する必要がある情報）だけが通されるであろう。異なったプロセスまたはプロセスのコンポーネントは、独自の識別子を有する異なったアプリケーションと見なされることができる。追加的または代替として、オペレータは、たとえば発電所の監視中に自分の携帯電話または別のノマディックアプリケーション３３を使用することができ、そのような携帯電話なども、やはり上記ノマディックアプリケーション３３に関する開示内容に従って処理される。

本発明の方法、システムおよびアプリケーションは、たとえば航空機管制にも適用されることができる。この場合、ＨＭＩ４３は、航空機管制コンピュータと、航空機管制官などの人との間のインターフェースであることができる。航空機は、航空機管制塔によって制御されている管制区域内へ、またその外へ飛行するノマディック装置であると見なされることができる。管制区域に入る航空機は、それらのトランスポンダ信号を識別子として使用する。その場合、航空機管制官と航空機のパイロットとの間のすべての通信は、上記の本発明の方法、システムおよびアプリケーションに従って行われる。航空機は動的優先順位を使用することができ、それにより、たとえば航空機が管制塔により近づくと、それに応じてメッセージの緊急性が高まる。ＤＶＥ状態は、航空機管制官によって現在処理されている情報の量および／または彼の管制区域内を現在飛行中の航空機の数に基づくことができる。たとえば、２機の航空機が互いに非常に接近して飛行しているとき、安全性クリティカルメッセージは、安全性クリティカルメッセージに関して以上に開示したものと同じやり方で処理される。管制官が自分の携帯電話または上記のような別のノマディックアプリケーションを使用する場合、これも、やはり上記ノマディックアプリケーション３３に関する開示内容に従って処理される。

本発明に従ったシステムのそのような例示的かつ好適な実施形態の第１機能的アーキテクチャである。 本発明に従った車内アプリケーションの運用状態または機能のＤＶＥ状態依存制御のための参照テーブルである。 本発明に従った別のアプリケーションの一実施形態である。 本発明に従ったシステムの例示的かつ好適な実施形態の第２機能的アーキテクチャである。 本発明に従ったシステムの例示的かつ好適な実施形態の第３機能的アーキテクチャである。

Claims (48)

1. 車両運転者と複数の統合および／または非統合アプリケーションとの間の通信および／または対話方法において、運転者との通信および／または対話を行う前に対話マネージャにより実行される第１ルーチンおよび各アプリケーションによる通信および／または対話方法であって、第１ルーチンは、
   運転者との通信および／または対話の許可を得るために、アプリケーションによるリクエストを対話マネージャに送るステップと、
   現在および／または予測運転者／車両環境（ＤＶＥ）状態および／または該アプリケーションおよび／または他のアプリケーションから前に受け取られている他のリクエストに依存して、リクエストされた通信および／または対話に対する許可を与えることができるかどうかを対話マネージャによって決定するステップと、
   リクエストされた通信および／または対話の許可または不許可に関する表示を有する応答を対話マネージャによって発生してアプリケーションに送るステップと、
   を含み、
   その表示が許可すれば、リクエストされた通信および／または対話をアプリケーションによってのみ実行し、そして、その表示が許可されなければ、そのような許可はアプリケーションによって待ち受けられる、通信および／または対話方法。
2. 優先順位インデックスが、アプリケーションの少なくとも１つの通信および／または対話の少なくとも１つに割り当てられ、該優先順位インデックスは、リクエストと一緒に送られ、許可／不許可の決定は、優先順位インデックスに依存して対話マネージャによって行われる、請求項１に記載の方法。
3. 優先順位インデックスは、標準方法によって定められる、請求項２に記載の方法。
4. リクエストされた通信および／または対話に対して現時点では許可を与えることができないと対話マネージャが決定した場合、関連のリクエストは第１待ち行列内に保存される、請求項１に記載の方法。
5. リクエストの少なくとも１つは、リクエストを送っているアプリケーションの識別子、リクエストによってリクエストされた通信および／または対話の継続時間および／または識別子、リクエストされた通信および／または対話によって運転者にそれぞれ加えられる視覚負荷、聴覚負荷および／または触覚負荷、およびリクエストのタイプに関する情報の少なくとも１つを含む、請求項１に記載の方法。
6. リクエストされた通信および／または対話に対して許可を与えることができないと対話マネージャが決定した場合、同一リクエストを、異なった優先順位インデックスを付けて繰り返し送ることができる、請求項２に記載の方法。
7. 繰り返し送る場合、リクエストは、このリクエストを第１待ち行列に追加するか、第１待ち行列内にすでに保存されている別のリクエストと置換するか、またはそれを削除するかどうかを表すそれのタイプに関する情報を有する、または対話マネージャから応答をまったく受け取らない場合、リクエストをｎ回（ｎ＝１、２、３、・・・）送る、請求項６に記載の方法。
8. 応答の少なくとも１つは、関連のリクエストを送ったアプリケーションの識別子、リクエストされた通信および／または対話の識別子、および／またはリクエストされた通信および／または対話に対する許可を与えることができるか否かの決定に関連した返答に関する情報の少なくとも１つを含む、請求項１に記載の方法。
9. アプリケーションは、テキスト−音声および／またはテキスト−ディスプレイコンバータのようなテキストコンバータであり、通信および／または対話は、
   運転者に非テキストメッセージ、好ましくは音声メッセージを、および／または
   ディスプレイ上にメッセージを
   出力するために設けられている、請求項１に記載の方法。
10. テキストは、それぞれチャンクドセグメントの形で、音声として出力され、および／またはディスプレイ上に表示され、各セグメントは、１つの通信および／または対話と見なされる、請求項９に記載の方法。
11. チャンクドセグメントが組み合わされ、それにより、出力時に少なくとも１つの論理単位が形成される、請求項１０に記載の方法。
12. チャンクドセグメントは、１つのセグメントを出力するリクエストが、そのような出力を許可する応答を対話マネージャから受け取るまで、第２待ち行列内に保存される、請求項１０に記載の方法。
13. チャンクドセグメントは、すべてのセグメントが出力されてしまうまで、第２待ち行列内に保存され、セグメントが所定時間より長く第２待ち行列内に保存されている場合、保存セグメントの少なくとも１つを再び出力することができる、請求項１２に記載の方法。
14. チャンクドセグメントは、構文解析部によって非事前チャンクドメッセージから生成される、請求項１０に記載の方法。
15. 車両運転者と複数の統合および／または非統合アプリケーションとの間の、対話マネージャにより実行される第２ルーチンによる通信および／または対話方法であって、第２ルーチンは、
    現在および／または予測運転者／車両環境（ＤＶＥ）状態を決定するステップと、
    アプリケーションの少なくとも１つのヒューマンマシンインターフェース（ＨＭＩ）の構造および／または運用状態および／または作動または機能（複数可）のモードを、運転者／車両環境（ＤＶＥ）状態に依存して対話マネージャによって制御するステップと、
    を含む、方法。
16. 構造の制御は、対話マネージャによってメッセージをアプリケーションに送ることによって行われ、メッセージは、現在および／または予測運転者／車両環境（ＤＶＥ）状態に基づいて評価される運転状況インデックスを含み、メッセージを受け取るアプリケーションは、そのヒューマンマシンインターフェース（ＨＭＩ）および／またはその運用状態および／またはその作動または機能（複数可）のモードを、受け取ったメッセージ内に含まれる運転状況インデックスに従って制御するために設けられている、請求項１５に記載の方法。
17. 現在および／または予測運転者／車両環境（ＤＶＥ）状態は、主タスクデマンド、副タスクデマンド、視覚的注意散漫、運転者の生理的障害、運転者の特徴、特殊な運転状況、全体的な運転環境のタイプまたは状況および運転者の個性といった基準の少なくとも１つに基づいて評価される、請求項１または１５に記載の方法。
18. 基準の少なくとも１つは、運転者状態および／または車両状態および／または環境状態を検出するための少なくとも１つのセンサの出力信号から評価される、請求項１７に記載の方法。
19. 通信および／または対話は、車両運転者に代わる人と、起動の際に少なくとも１つの一定状態に依存して考慮または処理されなければならない複数の信号または情報源、および／または他のそのような起動信号または情報源との間で行われる、請求項１に記載の方法。
20. 対話マネージャ（４１）、運転者／車両環境（ＤＶＥ）状態の推定および／または予測を行う推定部／予測部（４２）、および複数の統合および／または非統合アプリケーション（２、３）を有する、請求項１ないし１９の少なくとも１項に記載の方法を実行するためのシステム。
21. 運転者／車両環境（ＤＶＥ）状態の推定および／または予測を行うための推定部／予測部（４２）に接続された複数のセンサ（１０、１１、１２、１３、１４）を備えるセンサアレイ（１）を有する、請求項２０に記載のシステム。
22. 非統合アプリケーション（３１）の少なくとも１つは、独自のヒューマンマシンインターフェース（３４）を備えている、請求項２０に記載のシステム。
23. 統合ヒューマンマシンインターフェース（４３）を有する、請求項２０に記載のシステム。
24. 対話マネージャ（４１）、運転者／車両環境（ＤＶＥ）状態の推定および／または予測を行うための推定部／予測部（４２）および統合ヒューマンマシンインターフェース（４３）のコンポーネントの少なくとも１つを含む運転者情報ユニット（４）を有する、請求項２０に記載のシステム。
25. アプリケーションの１つは、チャンクドテキストセグメント（Ｘ１、Ｘ２、Ｘ３）を第２待ち行列（２６２）内に保存し、かつそれぞれテキストセグメント（Ｘ１、Ｘ２、Ｘ３）を音声として出力し、および／またはそれらをディスプレイ上に表示するために設けられているテキストコンバータ（２６）である、請求項２０に記載のシステム。
26. テキストコンバータ（２６）は、テキストをチャンクドテキストセグメント（Ｘ１、Ｘ２、Ｘ３）にスライスし、かつそれらを第２待ち行列（２６２）内に保存するための構文解析部（２６１）を有する、請求項２５に記載のシステム。
27. テキストコンバータ（２６）は、チャンクドテキストセグメント（Ｘ１、Ｘ２、Ｘ３）を生成してそれぞれそれを音声として出力し、および／またはディスプレイ上に表示する前に、請求項１に記載の第１ルーチンを実行するために設けられている音声発生器（２６３）および／またはディスプレイを有する、請求項２５に記載のシステム。
28. 請求項１〜１９の少なくとも１項に記載の方法を実行するためのマイクロコンピュータを有する、請求項２０に記載のシステム。
29. １つのセントラルまたは主ユニット（５１）と、少なくとも１つのローカルまたは従属ユニット（５２、５３、６４、６５）とを、互いにスター形ネットワークおよび／またはゲートウェイアーキテクチャに接続して有する、請求項２０に記載のシステム。
30. セントラルユニット（５１）は、主情報を制御する対話マネージャまたは運転者車両環境マネージャ（５１１）と、システム用の情報および資源管理を行うための資源マネージャ（５１２）とを有し、少なくとも１つのローカルユニット（５２、５３、６４、６５）は、ローカル資源管理用に設けられた１つのローカル資源マネージャ（５２２、５３２、６４２、６５２）を有する、請求項２９に記載のシステム。
31. ローカルユニット内および／またはその間で資源管理が行われ、セントラルユニットおよび少なくとも１つのローカルユニット間で情報および資源管理が行われる、請求項２９に従ったシステム内で実行される請求項１または１５に記載の方法。
32. 請求項２９に記載のシステム用、またはその一部に適したセントラルまたは主ユニット（５１）であって、対話マネージャまたは運転者車両環境マネージャ（５１１）と、請求項２９に記載のシステム用の情報管理および資源管理を行うための主情報および資源マネージャ（５１２）とを有する、セントラルまたは主ユニット（５１）。
33. 請求項２９に記載のシステム用、またはその一部に適したローカルまたは従属ユニット（５２、５３、６４、６５）であって、ローカル資源管理用に設けられているローカル資源マネージャ（５２２、５３２、６４２、６５２）を有する、ローカルまたは従属ユニット（５２、５３、６４、６５）。
34. 請求項２０に記載のシステム用、またはその一部に適した運転者情報ユニット（４）であって、対話マネージャ（４１）、運転者／車両環境（ＤＶＥ）状態の推定および／または予測を行う推定部／予測部（４２）、および統合ヒューマンマシンインターフェース（４３）のコンポーネントの少なくとも１つを有する、運転者情報ユニット（４）。
35. 請求項３４に記載の運転者情報ユニット（４）内で実行する、またはそれによって行われる方法であって、請求項１に記載の第１ルーチンに従ってリクエストを受け取り、応答を発生し、および／または請求項１５に記載の第２ルーチンに従ってアプリケーションを制御するための方法。
36. 請求項２０に記載のシステムまたは請求項３４に記載の運転者情報ユニット（４）用、またはその一部に適した対話マネージャであって、請求項１に記載の第１ルーチンおよび／または請求項１５に記載の第２ルーチンを実行するために設けられている対話マネージャ。
37. 請求項３６に記載の対話マネージャ（４１）内で実行する、またはそれによって行われる方法であって、請求項１に記載の第１ルーチンに従ってリクエストを受け取り、応答を発生し、および／または請求１５に記載の第２ルーチンに従ってアプリケーションを制御するための方法。
38. 対話マネージャによって実行される第３ルーチンによる、車両運転者および複数の統合および／または非統合アプリケーション間の通信および／または対話方法であって、
    運転者との通信および／または対話の許可を得るために、アプリケーションからリクエストを受け取るステップと、
    現在および／または予測運転者／車両環境（ＤＶＥ）状態および／または該アプリケーションおよび／または他のアプリケーションから前に受け取られている他のリクエストに依存して、リクエストされた通信および／または対話に対する許可を与えることができるかどうかを決定するステップと、
    リクエストされた通信および／または対話の許可または不許可に関する表示を有する応答を発生してアプリケーションに送るステップと、
    を含む方法。
39. 請求項２０に記載のシステムまたは請求項３４に記載の運転者情報ユニット（４）用、またはその一部に適したＤＶＥ状態推定部／予測部（４２）であって、運転者／車両環境状態の推定および／または予測を行うために設けられている、ＤＶＥ状態推定部／予測部。
40. 請求項３９に記載のＤＶＥ状態推定部／予測部（４２）内で実行する、またはそれによって行われる方法であって、運転者／車両環境状態の推定および／または予測を行うための方法。
41. 請求項２０に記載のシステム用、またはその一部に適した、統合および／または非統合アプリケーション（２、３）の形のアプリケーションであって、請求項１に記載の第１ルーチンを実行し、および／または請求項１５に記載の第２ルーチンに従って制御されるように設けられている、アプリケーション。
42. 請求項４１に記載のアプリケーション内で実行する、またはそれによって行われる方法であって、第１ルーチンに従ってリクエストを発生し、応答を受け取り、および／または第２ルーチンに従って制御される方法。
43. 対話マネージャ、およびアプリケーションの少なくとも１つによって実行される第４ルーチンによる、車両運転者と複数の統合および／または非統合アプリケーションとの間の通信および／対話方法であって、第４ルーチンは、
    運転者との通信および／または対話の許可を得るために、リクエストを対話マネージャに送るステップと、
    対話マネージャから応答を受け取るステップと、
    応答が許可する表示を有する場合、リクエストされた通信および／または対話をアプリケーションによってのみ行い、そして、応答が許可する表示を有しない場合、そのような許可はアプリケーションによって待ち受けられるステップと、
    を含む方法。
44. 請求項２０に記載のシステム用、またはその一部に適したアプリケーション（２；３）用、またはその一部に適したアダプタであって、アプリケーションをシステムに接続し、かつアプリケーションに請求項１に従った第１ルーチンを実行する能力を与え、および／または請求項１５に記載の第２ルーチンに従って制御されるようにした、アダプタ。
45. 請求項４４に記載のアダプタ内で実行する、またはそれによって行われる方法であって、請求項１に記載の第１ルーチンに従ってリクエストを発生し、かつ応答を受け取る能力をアプリケーションに与え、および／またはアプリケーションを請求項１５に記載の第２ルーチンに従って制御する方法。
46. コンピュータプログラムであって、該プログラムをプログラマブルマイクロコンピュータで走らせるとき、請求項１〜１９の少なくとも１項に記載の方法を実行できるようにしたコンピュータプログラムコード手段を有するコンピュータプログラム。
47. インターネットに接続されたコンピュータで走らせるとき、請求項２０に記載のシステムまたはそのコンポーネントの１つにダウンロードされるようにした、請求項４６に記載のコンピュータプログラム。
48. コンピュータ使用可能媒体に保存されるコンピュータプログラム製品であって、請求項４６に記載のコンピュータプログラムコード手段を有する、コンピュータプログラム製品。

Images