JP6442446B2 - 車両データシステム及び方法 - Google Patents

Description

本発明は、車両システム及び方法に関連し、例えば、少なくとも１つの気象関連条件を決定するためのシステム及び方法に関するものである。

ポータブルコンピューティングデバイス、例えばＧＰＳ（全気球測位システム）信号受信及び処理機能性を含むポータブルナビゲーションデバイス（ＰＮＤ）は周知であり、車両搭載型又は他の車両ナビゲーションシステムとして広く採用されている。既知のＰＮＤの一例には、ＴｏｍＴｏｍ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂ．Ｖ．によって製造され供給されているＧＯ ＩＩＶＥ１００５が含まれる。

そのようなＰＮＤの有用性は、主に、第１の場所（一般に、出発地又は現在地）と第２の場所（一般に、目的地）との間の経路を決定する機能にある。デバイスのユーザは、多種多様な種々の方法、例えば郵便番号、道路名及び番地、以前に格納した「既知」の目的地（有名な場所、公共の場所（運動場又は水泳プール等）又は他の地点情報等）、並びにお気に入りの目的地又は最近訪れた目的地のいずれかにより、それらの場所を入力できる。

ＰＮＤは、一般にデジタル地図の形式の格納された地理データに基づいて経路を決定する。格納された地理データは、多種多様な特徴に関するデータ、例えば道路又は他の主要道路の位置及び特性、地点情報の位置及び特性、並びに例えば川、海岸線又は山である地理的特徴の位置及び特性を含むことができる。

動作中、殆どのＰＮＤは、例えば５秒毎に時間の関数として自身の位置を周期的にログ記録する。ＰＮＤは、時間の関数として移動の速度又は方向等の他の関連するデータを更にログ記録できる。ＰＮＤ又は他のポータブルコンピューティングデバイスによりログ記録されたデータは、プローブデータ（ｐｒｏｂｅ ｄａｔａ）と呼ばれる。例えば既存のデジタル地図である既存の地理データを検査又は補足するために、多くのＰＮＤ又は他のポータブルコンピューティングデバイスからプローブデータを取得し、プローブデータを処理することが既知である。

道路又は他の経路は、デジタル地図において別個のセグメントにより表される。デジタル地図は、道路又は他の経路の各セグメントにわたる予想移動速度を表す速度データを含むことができる。そのような速度データは、種々の道路にわたる予想平均移動速度から取得されるか、あるいはデジタル地図における各道路又は他の経路における多くの車両の実際の移動を表すプローブデータから取得される。

速度データは、特定の目的地までの最速経路を決定するため、経路を計画するため及び／又は目的地への予想到着時刻（ＥＴＡ）を決定するために、既知のシステムにおいて使用可能である。このように速度データを使用するシステムの一例は、トムトム社（ＴｏｍＴｏｍ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂ．Ｖ．）により製造されるＩＱ Ｒｏｕｔｅｓ（ＲＴＭ）システムである。

速度データが好適な経路及びＥＴＡを計算するために使用される一方で、そのような計算の正確性は交通の不確実性のために損なわれる可能性がある。プローブデータから取得された速度プロファイルは、一般に、種々の交通量変動より長い期間にわたり平均された長期平均を表す。局所的な寿命の短い事象又は交通量変動は、道路セグメントの特定の速度プロファイルを無効にするか又は不正確にする可能性がある。例えば１つのそのような事象は悪天候であり、ＥＴＡを容易に２倍に一般的な気象予想データによっては表すことができない。多くの気象関連イベントは、例えば、特定の道路位置での氷の生成又は道路上の水たまりの有無は、実際には局所的に存在しており、予報気象条件と同様の局所的な地形及び道路条件に従うことができる。さらに、降水エリアの正確な境界又は範囲は気象予報データによって正確に表されていない。

本発明の第１の形態によれば、車両に実装可能なデバイスと通信を行う装置であって、車両における少なくとも１つのセンサ、又はモニタリング若しくは制御システムによって提供されるデータから得られる、少なくとも１つのデバイスからの車両データを受信する通信リソースと、気象データ及び車両データの両方に従って少なくとも１つの気象関連条件を決定するために、気象データ及び車両データを処理するように動作可能な処理リソースとを備えることを特徴とする。気象データ、例えば予報又は実際の気象データと、車両データとの両方に基づき少なくとも１つの気象関連条件を決定することによって、改善された正確性及び分解能の気象条件の決定が得られる。情報は、局所的な気象による道路条件を含む局所的な気象関連条件に関する車両データを用いて得られ、局所的な気象関連条件は、予報された気象データ又は遠隔で測定された気象データのみでは得ることができず、局所的に固定して実装されたセンサからのみ得られる。

気象関連データは、実際の又は予想（予報）された気象条件を表す気象データを含んでもよい。

車両データは、少なくとも１つのセンサ、又はモニタリング若しくは制御システムによって提供されたデータを処理することによって得られる。代替的に又は追加的に、車両データは、少なくとも１つのセンサ、又はモニタリング若しくは制御システムによって提供されたデータを含んでもよい。

データの処理は、所定の時刻及び場所の少なくとも一方の関数として実行されてもよい。

少なくとも１つの気象関連条件を決定する、気象データ及び車両データの処理は、気象データの修正又は検証を含んでもよい。このように、気象データの向上した正確性又は分解能が得られてもよい。

気象関連条件は少なくとも１つの場所での気象条件及び道路条件の少なくとも一方を含んでもよい。

車両データは、車両の動作プロパティ、及び、車両での気象関連条件を含む環境条件の少なくとも一方を表してもよい。

処理リソースは、気象データと、車両データとに基づき、気象関連条件を決定するために、統計モデルを適用するように構成され、統計モデルは、過去の車両データと、過去の気象データと、少なくとも１つの気象関連条件の過去の発生との間における関係を表す。

少なくとも１つの気象関連条件を決定する気象データ及び車両データの処理は、気象関連の警告を表す警告データの生成、修正、又は検証を含んでもよい。

車両データ及び気象データの組み合わせを処理することによって得られる気象の警告は、車両データ又は気象データを単独で使用して得られるものよりも正確性及び分解能を増大させうる。いくつかの気象関連条件は、車両データ又は気象関連データのみから正確性を得ることは難しいか又は不可能である。

例えば、特定の場所における車両スリップイベントは、気象関連でない要因の変化、例えば道路上のオイルによってでもよい。しかしながら、例えば零度付近又は氷点下を示す気象データとの組み合わせでスリップイベントデータを処理することによって、装置は、道路上の氷に起因するスリップイベントが発生しそうであると決定してもよく、例えば、所定の場所における気象関連の警告を発行してもよい。当該決定の正確性は、時間の関数としてデータを処理することによって増加しうる。例えば、スリップイベントの増加が当該領域における気温の低下と関連があれば、道路上の氷に起因するスリップイベントの可能性は増加しうる。

処理リソースは、所定の時間期間にわたる気象データ及び車両データの少なくとも一方の変動に従って警告データを生成、修正、又は検証するように構成されてもよい。

処理リソースは、所定の時間期間にわたる車両の過去の変動、所定の時間期間にわたる気象データの過去の変動、及び少なくとも１つの気象関連条件の過去の発生の間の関係を表す統計モデルを適用することによって、警告データを生成、修正、又は検証するように構成されてもよい。

警告データは、気象関連の警告の開始、終了、又は期間を表す時刻データを含み、処理リソースは、車両データを監視し、車両データに従って時刻データの生成、検証、及び修正の少なくとも１つを行うように構成されてもよい。

気象関連データは、気象のエリアの境界を表し、処理リソースは、車両データに従って境界の場所の検証、及び修正の少なくとも１つを行うように構成されてもよい。

気象関連データは、気象のエリアの境界を表す輪郭データを含み、処理リソースは、車両データに従って輪郭データを修正するように構成されてもよい。

通信リソースは、車両データと場所とを関連付けるために、デバイス及び車両の少なくとも一方の場所を表す場所データを受信するように構成されてもよい。

車両データは、車両のドライビング動作を表してもよい。処理リソースは、車両のドライビング動作が気象関連データと整合するかどうかを判定するように構成されてもよい。

車両データは、１つ以上のスリップイベントの有無を表してもよい。

車両データは、雨センサ、気温センサ、加速度センサ、角度モーメントセンサ、ブレーキセンサ、速度センサ、超音波センサ、レーダセンサ、又は、フロントワイパー、ヘッドランプ、サイドライト、フォグランプ、アンチロック・ブレーキシステム（ＡＢＳ）、エアーコンディショニングシステム、ブレーキ、暖房システムの１つ以上のセンサ若しくはモニタリングユニット、の少なくとも１つから取得されるデータを含んでもよい。

処理リソースは、複数の車両に実装される複数のデバイスから車両データを受信するように構成されてもよい。

処理リソースは、車両データが前記気象データと整合しないエリアにおける、車両の数、及び、車両の割合の少なくとも一方に従ってエリアにおける前記気象データを修正するように構成されてもよい。

処理リソースは、車両データ及び気象データの少なくとも一方の統計分析を実行するように構成されてもよい。処理リソースは、関連のある手続きを実行するように構成されてもよく、例えば、車両データ、気象データ、車両及びデバイスの少なくとも一方の位置、車両タイプ、車両識別子、及びデバイス識別子の少なくとも２つを関連付けてもよい。

処理リソースは、車両データが気象データと整合しないエリアにおける、車両の数、及び、車両の割合の少なくとも一方に従ってエリアにおける気象データを修正するように構成されてもよい。例えば、処理リソースは、車両データが気象データと整合しないエリアにおける車両の数と、車両データが気象データと整合しないエリアにおける車両の割合との少なくとも一方がそれぞれの閾値よりも大きければ、気象データを修正するように構成されてもよい。

処理リソースは、エリアの少なくとも１つの車両に実装された複数のデバイスから受信した車両データに従ってエリアにおける気象関連の警告を生成又は修正し、他のデバイスの場所に従って他のデバイスに気象関連の警告を選択的に送信、例えば、エリアに存在する他のデバイスへ気象関連の警告を選択的に送信してもよい。

装置は、サーバを含み、及び／又は、デバイスは、移動デバイス、例えば、携帯ナビゲーションデバイス（ＰＮＤ）又は移動電話機を含んでもよい。

本発明の他の形態によれば、車両に実装されたデバイスであって、車両に実装された少なくとも１つのセンサ、制御システム又はモニタリングシステムからデータを取得し、車両データを得るためにデータを処理する処理リソースと、気象データを取得し、気象データ及び車両データの両方に従って少なくとも１つの気象関連条件を決定するために、当該気象データ及び車両データを処理可能なサーバへ車両データを提供する通信リソースとを備える。

車両データは、イベントの発生又は未発生を表すイベントデータを含んでもよい。

処理リソース又はサーバは、イベントが発生したかどうかを判定するために、少なくとも１つのセンサ、制御システム又はモニタリングシステムからのデータを処理するように構成されてもよい。当該処理は、データを閾値と比較する処理を含んでもよい。

少なくとも１つのセンサ、制御システム又はモニタリングシステムからのデータは、少なくとも２つの異なるセンサ、制御システム又はモニタリングシステムから得られてもよく、処理リソース又はサーバは、イベントが発生したかどうかを判定するために、少なくとも２つの異なるシステムの組み合わせからのデータを処理するように構成されてもよい。

複数のシステムは、イベント、例えばスリップイベントが発生したかどうかを判定するために、区別して処理されうるデータをそれぞれ提供してもよく、処理リソース又はサーバは、イベントが発生したかどうかを決定するたに、複数のデバイスからのデータを処理するように構成されてもよい。

処理リソース又はサーバは、複数のイベント判定処理においてイベントが発生したかどうかを区別して、それぞれのシステムからのデータから判定してもよい。その後、処理リソース又はサーバは、イベントが発生したかどうかを判定するイベント判定処理の結果を組み合わせる少なくとも１つの規則に適用してもよい。

処理リソース又はサーバは、イベントが発生したかどうかを、複数のシステムからのデータから判定する統計モデルを適用してもよく、当該統計モデルは、過去のイベントの測定と発生との間の相互関係を表してもよい。

イベントが発生したかどうかを判定するためのデータの処理は、少なくとも２つのシステムの一方からのデータ、少なくとも２つのシステムの他方からのデータ、及び少なくとも１つの他のパラメータを、イベントが発生したかどうかの判定と関連付けるモデルを用いてもよい。

処理リソース又はサーバは、少なくとも１つの他のパラメータを表す他のデータを取得するように構成されてもよい。少なくとも１つの他のパラメータは、車両の動作のプロパティ、例えば、角度モーメント、直線力、又は遠心力の少なくとも１つを表してもよい。

少なくとも２つの異なるシステムは、専用の車両スリップ検知システムと、加速度センサ、角度モーメントセンサ、力センサ、ステアリングセンサ、及びブレーキングセンサの少なくとも１つとを備えてもよい。

イベントはスリップイベントを含んでもよい。

イベントは、例えば雨、雪、みぞれ、又はあられが降ることの有無、霧の有無、凍結の有無、積雪の有無、地表水の有無の少なくとも１つを含んでもよい。

処理リソースは、少なくとも１つのセンサ、又はモニタリング若しくは制御システムから得られるデータをフィルタリングするように構成されてもよい。

フィルタリングは、少なくとも１つのセンサ、又はモニタリング若しくは制御システムから得られるデータと、閾値とを比較し、比較結果に従って少なくともいくつかのデータを排除する処理を含んでもよい。

少なくとも１つのセンサ又はモニタリングシステムは、雨センサ、気温センサ、加速度センサ、角度モーメントセンサ、ブレーキセンサ、速度センサ、超音波センサ、レーダセンサ、又は、フロントワイパー、ヘッドランプ、サイドライト、フォグランプ、アンチロック・ブレーキシステム（ＡＢＳ）、エアーコンディショニングシステム、ブレーキ、暖房システムの１つ以上のセンサ若しくはモニタリングユニット、の少なくとも１つを備えてもよい。

デバイスは、ナビゲーションデバイス、例えば、車両内蔵型のナビゲーションデバイスを含んでもよい。

本発明の他の形態によれば、請求した又はここに記載した装置、及び請求した又はここに記載したデバイスを含むシステムを提供する。

本発明のさらに他の形態によれば、車両に実装可能なデバイスと通信する方法を提供する。当該方法は、少なくとも１つのデバイスからのデータ、即ち、少なくとも１つのセンサ、又はモニタリング若しくは制御システムによって提供されるデータから得られる車両データを受信するステップと、気象データを取得するステップと、気象データ及び車両データの両方に従って少なくとも１つの気象関連データを決定するために、気象データ及び車両データを処理するステップとを含んでもよい。

少なくとも１つの気象関連条件を決定するための気象データ及び車両データの処理は、気象データの修正又は検証を含む。気象関連条件は、少なくとも１つの場所での気象条件及び道路条件の少なくとも一方を含んでもよい。

車両データは、車両の動作のプロパティと、環境条件、例えば、車両での気象関連条件との少なくとも一方を表してもよい。

少なくとも１つの気象関連条件を決定するための気象データ及び車両データの処理は、気象関連の警告を表す警告データの生成、修正、又は検証を含んでもよい。

警告データは、気象関連の警告の開始、終了、又は期間を表す時刻データを含んでもよく、当該方法は、車両データをモニタリングし、車両データに従って時刻データを生成、検証、及び修正の少なくとも１つを行うステップを含んでもよい。

気象関連データは、気象のエリアの境界を表してもよく、当該方法は、車両データに従って境界の位置を検証及び修正の少なくとも一方を行うステップを含んでもよい。

上記方法は、デバイス及び車両の少なくとも一方を表す場所データを受信するステップと、当該場所と車両データを関連付けるステップとを含んでもよい。

車両データは、車両のドライビング動作を表してもよい。当該方法は、車両のドライビング動作が気象関連データと整合するかどうかを判定するステップを含んでもよい。

車両データは、１つ以上のスリップイベントの有無を表してもよい。

車両データは、雨センサ、気温センサ、加速度センサ、角度モーメントセンサ、ブレーキセンサ、速度センサ、超音波センサ、レーダセンサ、又は、フロントワイパー、ヘッドランプ、サイドライト、フォグランプ、アンチロック・ブレーキシステム（ＡＢＳ）、エアーコンディショニングシステム、ブレーキ、暖房システムの１つ以上のセンサ若しくはモニタリングユニット、の少なくとも１つから取得されるデータを含んでもよい。

上記方法は、複数の車両に実装された複数のデバイスから車両データを受信するステップを含んでもよい。

上記方法は、車両データが気象データと整合しないエリアにおける車両の数と、車両データが気象データと整合しないエリアにおける車両の割合との少なくとも一方に従ってエリアにおける前記気象データを修正するステップを含んでもよい。上記方法は、車両データが気象データと整合しないエリアにおける車両の数と、車両データが気象データと整合しないエリアにおける車両の割合との少なくとも一方がそれぞれの閾値よりも大きければ、気象データを修正するステップを含んでもよい。

上記方法は、エリアの少なくとも１つの車両に実装された複数のデバイスから受信した車両データに従ってエリアにおける気象関連の警告を生成又は修正し、他のデバイスの場所に従って他のデバイスに気象関連の警告を選択的に送信、例えば、エリアに存在する他のデバイスへ気象関連の警告を選択的に送信するステップを含んでもよい。

本発明の他の実施形態によれば、方法を提供する。当該方法は、車両に実装された少なくとも１つのセンサ、制御システム又はモニタリングシステムからのデータを取得するステップと、車両データを取得するためにデータを処理するステップと、気象データ及び車両データの両方に従って少なくとも１つの気象関連条件を決定するために、気象データを取得し、気象データ及び車両データを処理することが可能なサーバに車両データを提供するステップとを含んでもよい。

車両データは、イベントの発生又は未発生を表すイベントデータを含んでもよい。

少なくとも１つのセンサ、制御システム又はモニタリングシステムからのデータは、少なくとも２つの異なるセンサ、制御システム又はモニタリングシステムから得られてもよく、当該方法は、イベントが発生したかどうかを判定するために、少なくとも２つの異なるシステムの組み合わせからのデータを処理するステップを含んでもよい。

上記方法は、統計テストをデータに適用するステップを含んでもよい。

上記方法は、少なくとも２つのシステムの一方からのデータ、少なくとも２つのシステムの他方からのデータ、及び少なくとも１つの他のパラメータを、イベントが発生したかどうかの判定と関連付けるモデルを用いるステップを含んでもよい。

少なくとも２つの異なるシステムは、専用の車両スリップ検知システムと、加速度センサ、角度モーメントセンサ、力センサ、ステアリングセンサ、及びブレーキングセンサの少なくとも１つとを備えてもよい。イベントはスリップイベントを含んでもよい。

イベントは、例えば雨、雪、みぞれ、又はあられが降ることの有無、霧の有無、凍結の有無、積雪の有無、地表水の有無の少なくとも１つを含んでもよい。

上記方法は、少なくとも１つのセンサ、又はモニタリング若しくは制御システムから得られるデータをフィルタリングするステップを含んでもよい。

フィルタリングは、少なくとも１つのセンサ、又はモニタリング若しくは制御システムから得られるデータと、閾値とを比較し、比較結果に従って少なくともいくつかのデータを排除する処理を含んでもよい。

少なくとも１つのセンサ又はモニタリングシステムは、雨センサ、気温センサ、加速度センサ、角度モーメントセンサ、ブレーキセンサ、速度センサ、超音波センサ、レーダセンサ、又は、フロントワイパー、ヘッドランプ、サイドライト、フォグランプ、アンチロック・ブレーキシステム（ＡＢＳ）、エアーコンディショニングシステム、ブレーキ、暖房システムの１つ以上のセンサ若しくはモニタリングユニット、の少なくとも１つを備えてもよい。

本発明の他の形態によれば、請求した又はここに記載した方法の各ステップを実行可能なコンピュータで読み取り可能なプログラムを提供してもよい。

本明細書において添付の図面を参照して実質的に説明されるような装置又は方法が提供されてもよい。

本発明のあらゆる特徴又は態様は、あらゆる適切な組み合わせで本発明のあらゆる他の特徴又は態様と組み合わされてもよい。装置の特徴は方法の特徴として適用されてもよく、方法の特徴は装置の特徴として適用されてもよい。

次に、本発明の実施形態について説明するがそれらに限定されない。本発明の実施形態を以下の図面に示す。
一実施形態に係るナビゲーションシステムを示す概略図である。 一実施形態に係るナビゲーションデバイスを示す概略図である。 図２の処理リソースを示す概略図である。 図２のナビゲーションデバイスを実装した車両の制御モジュール、モニタリングモジュール、又はセンサモジュールを示す概略図である。 車両での図２のデバイスによる制御データ、モニタリングデータ、又はセンサデータの処理の概略を示すフローチャートである。 図１のシステムのサーバで気象データの処理の概略を示すフローチャートである。 エリアにおける気象の警告をマップに重ねた状態を示す図である。

移動デバイスからデータを取得し、気象関連条件を判定する、例えば、取得したデータを用いて気象データを検証又は修正するシステムを図１に示す。システムは、複数のポータブルデバイス、例えばＰＮＤ２００ａ〜２００ｅと通信するように動作可能であるサーバ１５０を備える。分かりやすくするために、５つのデバイス２００ａ〜２００ｅのみが示されるが、実際には数千以上のデバイスがサーバ１５０と通信していてもよいことが理解されるだろう。

図１の実施形態において、デバイス２００ａ〜２００ｅは、自身の位置を決定するために全地球即位システム（ＧＰＳ）技術を使用し、ナビゲーション又はマッピング動作を実行できる車両搭載型のＰＮＤである。デバイス２００ａ〜２００ｅは、ＰＮＤであることに限定されず、例えば移動電話機又はポータブルコンピュータであるナビゲーション機能性を有するあらゆる適切な種類のデバイスであってもよい。

サーバ１５０は、メモリ１５６に動作可能に接続されたプロセッサ１５４を含む。動作中、サーバメモリ１５６に格納されたソフトウェアは、プロセッサ１５４により読み出され、プロセッサ１５４が種々の処理又は通信機能を実行できるようにするソフトウェアモジュール又は他のソフトウェアコンポーネントをロードする。図１の実施形態において、ソフトウェアモジュールは、気象データ処理モジュール１７０を含む。気象データ処理モジュールの動作については、以下に更に詳細に説明する。

サーバ１５０は、大容量データ記憶装置１６０に更に動作可能に接続される。大容量記憶装置１６０は、ナビゲーションデータの記憶部を含み、サーバ１５０とは別個のデバイスであるか又はサーバ１５０に内蔵される。大容量データ記憶装置１６０は、デバイス２００ａ〜２００ｅからのプローブデータを格納するために使用される。

サーバ１５０は、例えば専用の気象フィードを提供する第三者ウェブサイト又は気象通信センターである気象データの少なくとも１つの送信元１８０と動作可能に通信している。あるいは又はそれに加えて、気象データの少なくとも１つの送信元は、気象センサ、降雨レーダ又はモデル計算を実行するコンピュータを含むことができる。サーバ１５０は、あらゆる適切な通信チャネルを介して、例えばインターネット接続、専用有線接続又は専用無線接続を介して、気象データの少なくとも１つの送信元と通信する。

サーバ１５０は、要望に応じて、複数の送信元からの正確な局地気象情報（降水量、気温、風の状態及び暴風又は道路凍結等の地域の荒天警報に関する現在の情報／予報情報を含むがこれらに限定されない）を収集及び融合できる。

プロセッサ１５４は、通信チャネル１５２を介して、例えば送信機１６２及び受信機１６４を介して、デバイス２００ａ〜２００ｅに対して情報を送受信するように動作可能である。送出及び受信された信号は、データ及び／又は他の伝播信号を含んでもよい。送信機１６２及び受信機１６４は、ナビゲーションシステムの通信設計において使用された通信要件及び通信技術に従って選択又は設計されてもよい。尚、送信機１６２及び受信機１６４の機能は、単一の送受信機に組み合わされてもよい。

ナビゲーションデバイス２００ａ〜２００ｅの正常な動作過程において、それらデバイスからのＧＰＳデータは、例えばポータブルナビゲーションデバイス自体に含まれるデータロガーモジュールの形態であるロギングデバイスにプローブデータとして定期的に記録される（例えば、あるシステムの場合は５秒毎）。

デバイス２００ａ〜２００ｅから受信したプローブデータを受信及び処理すると共に、サーバ１５０は、例えばデジタル地図データ（例えば、受信したプローブデータを考慮して更新されたデジタル地図データ）、ソフトウェアアップグレード又は交通若しくは他の更新の形式でデータをデバイス２００ａ〜２００ｅに提供できる。

図１の実施形態の通信チャネル１５２はインターネット接続を含んでもよいが、あらゆる適切なデータチャネルの形態が使用可能である。通信チャネル１５２は、特定の通信技術に限定されない。チャネル１５２は種々の技術を使用するいくつかの通信リンクを含んでもよい。例えば通信チャネル１５２は、電気通信、光通信及び／又は電磁通信のためにパスを提供するように構成される。従って、通信チャネル１５２は、電気回路、ワイヤ及び同軸ケーブル等の電気導体、光ファイバケーブル、変換器、無線周波数（ＲＦ）波、大気又は空所のうちの１つ又はそれらの組み合わせを含むが、それらに限定されない。更に通信チャネル１５２は、例えばルータ、中継器、バッファ、送信機及び受信機等の中間デバイスを含むことができる。

１つの構成例において、通信チャネル１５２は電話及びコンピュータネットワークを含む。更に通信チャネル１５２は、マイクロ波周波数通信等の無線通信、例えば赤外線通信、無線周波数通信に対応できてもよい。あるいは又はそれに加えて、通信チャネル１５２は衛星通信に対応できる。

通信チャネル１５２を介して送信された通信信号は、所定の通信技術に対して要求又は要望される可能性があるような信号を含むが、これに限定されない。例えば信号は、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、符号分割多元接続（ＣＤＭＡ）、汎ヨーロッパデジタル移動通信システム（ＧＳＭ（登録商標））等のセルラ通信技術において使用されるように構成されてもよい。デジタル信号及びアナログ信号の双方とも、通信チャネル１５２を介して送信可能である。これらの信号は、変調、暗号化及び／又は圧縮されてもよい。

一実施形態におけるナビゲーションデバイス２００を図２に示す。尚、ナビゲーションデバイス２００のブロック図は、ナビゲーションデバイスの全ての構成要素を含むわけではなく、多くの構成要素の例を表すだけである。ナビゲーションデバイス２００は筐体（不図示）内に配置される。ナビゲーションデバイス２００は、プロセッサ２０２を含む処理リソースを含み、プロセッサ２０２は、入力デバイス２０４及び例えば表示画面２０６であるディスプレイデバイスに結合される。ここで入力デバイス２０４は単数で参照されるが、入力デバイス２０４がキーボードデバイス、音声入力デバイス、タッチパネル及び／又は情報を入力するのに利用される他のあらゆる既知の入力デバイスを含む１つ又は複数の入力デバイスを表すことは当業者には理解されるべきである。同様に、表示画面２０６は、例えば液晶ディスプレイ（ＬＣＤ）等のあらゆる種類の表示画面を含むことができる。

１つの構成において、タッチパネル及び表示画面２０６は、ユーザが複数の表示選択肢のうちの１つを選択するか又は複数の仮想又は「ソフト」ボタンのうちの１つを有効にするために表示画面２０６の一部分にタッチするだけでよいように、タッチパネルスクリーンを介する情報の入力（直接入力、メニュー選択等による）及び情報の表示の双方を可能にするタッチパッド又はタッチスクリーン入力を含む一体型入力表示デバイスを提供するように一体化される。この点に関して、プロセッサ２０２は、タッチスクリーンと共に動作するグラフィカルユーザインタフェース（ＧＵＩ）をサポートする。

ナビゲーションデバイス２００において、プロセッサ２０２は、接続２１０を介して入力デバイス２０４に動作可能に接続され且つ入力デバイス２０４から入力情報を受信でき、各出力接続２１２を介して表示画面２０６及び出力デバイス２０８のうちの少なくとも一方に動作可能に接続されて情報を出力する。ナビゲーションデバイス２００は、例えば可聴出力デバイス（例えば、スピーカ）である出力デバイス２０８を含んでもよい。出力デバイス２０８は、ナビゲーションデバイス２００のユーザに対して可聴情報を生成できるため、入力デバイス２０４は、入力音声コマンドを受信するためのマイク及びソフトウェアを更に含むことができることが同様に理解されるべきである。また、ナビゲーションデバイス２００は、例えばオーディオ入出力デバイス等のあらゆる追加の入力デバイス２０４及び／又はあらゆる追加の出力デバイスを含むことができる。

プロセッサ２０２は、接続２１６を介してメモリ２１４に動作可能に接続され、接続２２０を介して入出力（Ｉ／Ｏ）ポート２１８との間で情報を送受信するように更に構成される。ここで、Ｉ／Ｏポート２１８は、ナビゲーションデバイス２００の外部のＩ／Ｏデバイス２２２に接続可能である。外部Ｉ／Ｏデバイス２２２は、例えばイヤホン等の外部リスニングデバイスを含んでもよいが、これに限定されない。更にＩ／Ｏデバイス２２２への接続は、例えばイヤホン又はヘッドフォンへの接続のため及び／又は移動電話機への接続のためのハンズフリー動作及び／又は音声起動動作のために、カーステレオユニット等の他のあらゆる外部装置への有線接続又は無線接続であってもよい。移動電話機接続は、例えばナビゲーションデバイス２００とインターネット又は他のあらゆるネットワークとの間のデータ接続を確立するため、並びに／あるいは例えばインターネット又は他のネットワークを介するサーバへの接続を確立するために使用される。

次に添付の図面の図３を参照すると、デバイス２００の内部フラッシュメモリ（不図示）は、機能ハードウェアコンポーネント２５４による実行のために記憶装置２１４からオペレーティングシステム２５０及びアプリケーションソフトウェア２５２をロードするためにプロセッサ２０２により実行可能なブートローダプログラムを格納し、これによりアプリケーションソフトウェア２５２が実行可能である環境が提供される。オペレーティングシステム２５０は、機能ハードウェアコンポーネントを制御し、アプリケーションソフトウェア２５２と機能ハードウェアコンポーネント２５４との間に常駐する。

アプリケーションソフトウェア２５２は、例えば地図閲覧、経路計画、ナビゲーション機能及びそれらと関連付けられた他のあらゆる機能であるナビゲーションデバイス２００の中核機能をサポートするＧＵＩを含む動作環境を提供する。アプリケーションソフトウェア２５２は、経路を計画でき、既知の技術を使用して経路の各セグメントの予想移動速度に基づいて目的地への予想到着時刻を決定できる。デジタル地図の道路又は他の主要道路の各セグメントの予想移動速度は速度データとしてデバイス２００に格納され、必要に応じてアクセスされる。速度データは、サーバ１５０からの速度データ更新データを介して更新される。アプリケーションソフトウェア２５２は、少なくとも１つのセンサによって実行される測定を表すデータを受信し処理し、これによりセンサ生成データを取得するデータ処理モジュール２６０と、データロギングモジュール２６２とを含む。処理モジュール２６０及びデータロギングモジュール２６２の動作の詳細については後述する。

ナビゲーションデバイス２００は、車両に配置されたドッキングステーションへドッキングさせることができる。例えば、ナビゲーションデバイス２００は、例えば、吸着カップを用いて、車両のダッシュボード又はウィンドウに固定されるアームに配置されてもよい。

図４を参照すると、車両にドッキングされると、ナビゲーションデバイス２００は、車両の少なくとも１つの電子データバス３００と通信可能となる。ナビゲーションデバイス００は、ドッキングステーションでの直接接続か、又は、無線接続かのいずれかを介して、インタフェース部３０１の手段によりバス３００と通信してもよい。例えば、インタフェース部３０１は、車両の無線インタフェース（例えば、Bluetooth（登録商標）インタフェース）を備える。

データバス３００は、車両の種々のセンサモジュール３０２と、制御又はモニタリングモジュール３０４との間で信号を伝達し、当該種々のモジュールが通信することを許容する。モジュール３０２、３０４は、車両の制御動作又はモニタリング動作における車両のシステムの一部を形成してもよい。

一例として、制御又はモニタリングモジュールは、エンジン制御部（ＥＣＵ）３０４ａ、トラクション制御モジュール３０４ｂ、サスペンション及びスタビリティ制御モジュール３０４ｃ、ヘッドランプ制御モジュール３０４ｄ、フロントワイパー制御モジュール３０４ｅ、フォグランプモジュール３０４ｆ、アンチロック・ブレーキシステム３０４ｇ、送信制御モジュール３０４ｈ、ブレーキモジュール３０４ｉ、及び気候制御モジュール３０４ｊを含む。一例として、センサモジュールは、降雨センサ３０２ａ、ステアリング位置センサ３０２ｂ、光センサ３０２ｃ、外部環境気温センサ３０２ｄ、１つ以上の送信及びエンジン性能センサ３０２ｅ、少なくとも１つの角度モーメントセンサモジュール３０２ｆ、１つ以上の車両速度センサ３０２ｇ、レーダモジュール３０２ｈ、及び超音波モジュール３０２ｉを含む。特定の車両が制御モジュール、モニタリングモジュール、及びセンサモジュールの任意の組み合わせを有することができることは理解されるであろう。代替的に又は追加的に、車両は、車両のステータス又は性能の任意の適切な形態を測定するか、又は、車両が対象となる任意の適切な環境条件を測定するための、種々の制御モジュール、モニタリングモジュール、及びセンサモジュールの少なくとも１つを含んでもよい。

データバス３００は、種々のモジュール間の情報転送や質問又はモジュールからの情報の受信を可能にする。データバス３００は、配信通信ネットワークを実装するために自動車産業において広く使用される制御エリアネットワークバス（ＣＡＮ−ｂｕｓ）プロトコルなどの、確立されたデータバスプロトコルに従って動作してもよい。

センサモジュール３０２の少なくとも１つは、代替的に又は追加的に、バス３００を介して、専用の直接接続（不図示）を介して各制御モジュール３０４と通信を行ってもよい。そのような直接接続は、例えば、センターからの連続した信号が制御モジュールによって必要とされる場合、又は、信号が安全なデータパスを介して送信される必要がある場合に使用されうる。センサ信号がバス３００から利用されるだけでなく、本実施形態によって使用されるデータはバス３００及びインタフェース部３０１の少なくとも一方を介して直接的に又は間接的に取得可能である。

代替の実施形態において、車両は、拡張されたフローティング・カー・データ（ｘＦＣＤ）機能を備える。ｘＦＣＤインタフェースがデバイス２００の代わりに或いはデバイス２００とともに設けられる。ｘＦＣＤインタフェースは、車両の不可欠な部分として製造業者によって提供される専用のインタフェースであってもよい。そのような代替の実施形態において、種々のモジュール３０２、３０４からのデータは、車両の現在の位置とともにｘＦＣＤインタフェースによって直接的にサーバに送信されてもよい。或いは、デバイス２００が車両のｘＦＣＤインタフェースと通信し、データを取得するために使用されるｘＦＣＤインタフェースを含んでもよい。

ユーザがナビゲーションデバイス２００の電源を投入すると、デバイス２００は、ＧＰＳフィックスを取得し、ナビゲーションデバイス２００の現在地を計算する（既知の方法で）。ユーザは、ナビゲーションデバイス２００が配置されると決定されるローカル環境を疑似３次元で示し且つローカル環境の下のディスプレイの領域において一連の制御及び状態メッセージを示すディスプレイが提示される。

ローカル環境のディスプレイをタッチすることにより、ナビゲーションデバイス２００はアイコンにより表される一連の仮想又はソフトボタンを表示するように切り替え、これにより、ユーザはナビゲートしたい目的地を入力し且つナビゲーションデバイス２００の制御又はディスプレイ上のデータの表示に関連する他の種々の機能を実行できる。

ナビゲーションデバイス２００の動作中、例えば車両の動作中において、ステータスデータ又はセンサ出力（センサから生成された）データなどの車両データを取得するために、センサ、制御又はモニタリングモジュール３０２、３０４からのデータがデバイス２００によって取得されて処理され、その後、サーバ１５０に送信されることが本実施形態の特徴である。車両データは、各イベントのイベントデータを含むことができる。サーバ１５０は、少なくとも１つの気象関連条件を決定するため、例えば、気象データの検証又は修正を行うため、或いは、気象の警告の検証、修正、又は生成を行うために、多数のデバイスから受信されうる、車両データを使用する。このように、システムは、気象予報から取得されるよりも正確性又は分解能の高い気象関連情報を提供することができる、個々の車両の測定結果や動作を考慮することができる。

車両データを考慮する車両の動作については、以下で詳細に説明する。まず、車両に実装された単一のデバイス２００によって処理データ及びロギングデータについて以下に説明する。

図５は、図１、２、４の実施形態における１つの動作モードを図示したフローチャートである。

本実施形態の特徴は、車両に設けられたセンサ、制御又はモニタリングシステムから取得するデータであり、例えば、車両の通常の動作中に１つ以上のモジュール３０２、３０４からのデータであり、局所的な気象条件を測定するか又は推測するために使用されうる。このように、ＰＮＤ２００の処理リソースにおける処理モジュール２６０は、図５の段階４００に示すように、モジュール３０２、３０４の１つ以上から受信されるデータをモニタリングする。

異なる車両内蔵のセンサ、制御システム又はモニタリングシステムから得られる種々のパラメータの広範囲の何れかが、センサ、制御システム又はモニタリングシステムの本体の目的を意図していない場合であっても、局所的な気象条件に関する情報を決定するために使用される。

図５の動作モードにおいて、処理モジュール２６０は、例えば、ジャイロスコープ、加速度メータ、及び全てのホイールからのホイール速度から受信されるデータをモニタリング（監視）する。処理の段階４０２において、処理モジュール２６０は、センサ間の不整合がホイールスリップとして警告を与えるべきであるかどうかを決定するために、受信データを処理する。当該不整合は、車の動力や動的モデルに基づいて判定される。（単一の）スリップの所定の種別は、ホイール速度の不整合のみから判定される。サイドのコンポーネントは、ジャイロスコープ、動的モデル（動力モデル）、及び理想的な（可能な限り間接的な）力測定を必要とする。

図５の実施形態では、スリップスケールが、道路スリップ条件（又は、接着条件）にスリップイベントをマッピングするように定義されている。実際の全ての関連ケースでは、道路条件の測定は、単一の数値で表現することができ、例えば、０から１の間のスケールである。ここで、０は車両のホイールに対してゼロの摩擦力の極端な例を示し、１は、理想的な乾燥した表面の他の極端な例を示す。本目的においては、種々の種別のホイール、種々の種別の路面（極端でなければ）、道路接触領域当たりの種々の圧力、及び接触摩擦と動的摩擦との間の差異の効果（これらは、大体２つに満たない要因により異なることが想定される）は、我々がゼロに近い車依存のスリップスケールと懸念しているように、実際には無視される。

処理モジュール２６０は、ＧＰＳデータ、角度モーメント、及び速度データの少なくとも１つを処理し、スリップスケールに従ってスリップ値を決定する。スリップスケールは、テスト車両を用いて、前もって行われた多くの測定に対して調整されうる。

次に段階４０４において、ロギングモジュール２６２は、デバイス２００の場所（及び車両の場所）を表す場所データとともに、算出されたスリップ値を格納する。スリップ値は、気象条件の指標、例えば、道路の凍結又は水たまりの存在を提供することができる。

他の実施形態において、処理モジュール２６０は、スリップ値と、閾値とを比較し、比較結果に基づきスリップ又は未スリップを示すバイナリのスリップデータを決定する。この場合、スリップ値よりもむしろバイナリスリップデータがロギングモジュール２６２によって格納される。

段階４００乃至４０４でのデータの読み取り、処理、格納は、例えば５秒ごとに定期的に繰り返して実行される。続いてログデータはサーバ１５０に送信される。当該データは、当該データが事後統計解析に使用される場合に、無線接続を介して、例えば５分ごとに定期的に送信されてもよく、或いは、デバイス２００が車両から取り除かれ、例えば、ＰＣへ接続されたドッキングステーションを介してインターネットへ接続された際に送信されてもよい。イベントベースの送信アプローチも使用されてもよく、当該データ（例えば、以下の任意のフィルタリングプロセスが行われたデータ）が興味が有り、可能性のあるイベントを表すと思われる場合にのみ送信されてもよい。いくつかのケースにおいて、そのようなスリップイベントが検知されることに応じて、スリップイベントを表すデータのみがサーバ１５０へ送信され、送信されるデータ量を低減する。

図５は、スリップイベントに関連するデータのモニタリング及び格納に関して説明している。代替の実施形態において、データが気象関連パラメータを表す、又は、気象関連パラメータを決定するために使用されうるのであれば、車両センサ又は他のデバイスから任意の適切なデータが処理され格納されうる。

例えば、代替の実施形態又は動作モードにおいて、モジュール２６０は、フロントワイパー３０４ａ、降雨センサ３０２ａ、光センサ３０２ｃ、気温センサ３０２ｄ、ヘッドランプ制御モジュール３０４ｄ、ブレーキモジュール３０４ｉ、フォグランプ制御モジュール３０４ｆ、レーダモジュール３０２ｈ、及び超音波モジュール３０２ｉの少なくとも１つからデータを受信する。受信データストリームは、モジュール２６０により処理され、ロギングモジュール２６２により記録される。

いくつかのケースにおいて、モジュール２６０による処理は、単にデータをロギングモジュール２６２に転送する処理を含む。他のケースにおいて、モジュール２６０によって追加の処理が実行される。例えば、モジュール２６０は、特定のイベントが発生したかどうかを判定するためにデータを処理することができ、その後、ロギングモジュール２６２は、イベントの発生又は未発生を表すイベントデータを格納する。例えば、モジュール２６０は、平均気温が０度又はいくつかの閾値を下回る場合には、少なくとも所定の期間ごとに（例えば、１分ごとに）、気温をモニタリングして低温イベントデータを生成してもよい。他の例において、モジュール２６０は、フロントワイパーの動作をモニタリングし、フロントワイパーが所定の期間の間（例えば、１分）の所定の閾値部分（例えば、７５％）よりも長く動作していれば降雨イベントデータを生成してもよい。イベントデータ、他のステータス、又はセンサ出力データは、サーバ１５０へ送信されるのに続いてロギングモジュール２６２によって格納される。

ロギングモジュール２６２は、また、車両データを取得する時間に車両の場所を表す場所データを格納し、場所データと車両データとを関連付ける。場所データは、また、サーバ１５０へ送信される。多くの実施形態において、例えば速度データを含んでもよいいくつかの種々の種別の車両データは、場所データとともに記録され、サーバ１５０へ提供される。

データ転送の要件を低減するために、例えばデータ及びイベントの記録前後の何れかにおいてモジュール２６０によって、データ及びイベントの知的フィルタリングがデバイスに直接実装されうる。そのようなフィルタリングは、例えば、通常のブレーキアプリケーション又は特定の急加速中における転送されてくるホイールのスリッピングなどの共通イベントを防止することができる。

異なるフィルタリング処理は、種々の種別のイベント、例えば、滑りやすい路面、降雨、道路上の障害や渋滞などのイベントを対象とする。

我々が滑りやすい道路条件に起因するスリップイベントのみに興味がある場合、フィルタリングの目的は、例えば急加速又は急ブレーキなどの他の要因から発生するときは単純に説明されうるスリップイベントであって、滑りやすい路面を示す必要がないスリップイベントを抑えることである。種々の異なるイベント（滑りやすい道路条件のみではない）と関連付けられたフィルタリング処理の一例について以下の段落で説明する。

１つのフィルタリング処理は、過度の加速度に起因するよりもむしろ道路又は他の条件に起因する真のスリップを示すように、低直線加速度、所定レベル未満のアクセルペダルの動作と関連付けられるスリップイベントを検知するために角度モーメントフィルタを適用するステップを含む。他のフィルタリング処理は、高加速又は減速が通常の道路条件を示す測定された角度モーメントと整合するイベントを検知するために角度モーメント分析を用いるステップを含む。さらに他のフィルタリング処理は、信号の横断又は通路の横断（後者においては、通常の平凡な交通シナリオとしてもっともらしい加速のみ）の際のもっともらしい加速又は減速を除去するために、現在の位置、デジタル地図データ、及び加速又は減速データを相互に関連付けるステップを含む。さらに他のフィルタリング処理は、ブレーキングイベントが障害の存在に関連付けられるかどうかを判定するために、超音波距離センサからの測定とブレーキングイベントとを相互に関連付けるステップを含む。さらに他のフィルタリング処理は、降雨よりもむしろ、ワイパーの操作、及び洗浄液のアプリケーションによる検知された水の存在の少なくとも一方を識別することができる、外部の水センサの動作、洗浄液のアプリケーション、及びフロントワイパーの動作とを相互に関連付けるステップを含む。

スリップイベントの検出に関連して上述したように、モジュール２６０は、１つ以上のセンサ、制御又はモニタリングモジュールから受信されるデータに基づき、イベントの発生又は未発生を決定するように動作可能である。いくつかの車両では、製造業者は、特定のイベントが発生するかどうかえお自動的に決定するシステムを備え、そのようなイベントの発生を表すイベント信号がＣＡＮバスから読み出される。例えば、いくつかの製造業者は、ＣＡＮバスからのスリップイベントを表すイベント信号の読出しを許容するスリップ検知システムを有する。

所定の車両における製造業者のスリップ検知システムは、スリップが発生するか発生しないかを表す解釈又は閾値に基づいている。検知システムが有益な情報を配信しうるため、それは製造業者のスリップ検知システムからのデータを使用するのに役立つ。製造業者は車両の動的なプロパティを認識しており、製造業者のみがアクセス可能な場所に直接力センサ又は角度モーメントセンサなどの高機能な感覚システムを実装することができる。製造業者のシステムは製造業者の特定のキャリブレーションに基づくものであるため、デバイス２００のモジュール２６０が製造業者の専用のスリップ検知システムからのデータを検証又はキャリブレーションするために、専用のスリップ検知システムと他のセンサからの出力とを合成することはいくつかの実施形態における特徴である。

製造業者のスリップ検知システムは、適切な解釈可能な情報であって、路面に平行して道路に対して車両の力を判定するために解釈されうる又は表す情報を配信できれば、路面の滑りの改善されキャリブレーションされた測定全体に寄与することができる。

特定の有用な専用のスリップ検知システムの一例は、レギュラーインターバル（例えば、ミリ秒のオーダのインターバル）での力又は角度モーメントデータと、瞬間的なスリップあり／なしを示す出力データとを、可能な限りスリップ距離とともに発行することである。他の有用なシステムは、スリップ距離とともにスリップイベント信号と、スリップイベント後の（最小の）力又は角度モーメントデータを発行することである。上記２つのシステムの両方は、所定の力又は角度モーメントの閾値及び距離の閾値を下回る場合にのみ指標データを出力するようにしてもよく、これにより、極端なドライバの動作による明らかなスリップを無視することができる。

有用な専用のスリップ検知システムの他の例は、標準の距離インターバル（例えば、キロメータごと）で、スリップイベント又はゆっくり蓄積された（小さいスリップ又は連続した複数のスリップを介して）ヘディング不一致を表すいくつかの測定を含む数値を発行することであるか、或いは、ＡＢＳが起動しているかどうかを示す信号を出力し、より好ましくはさらに角度モーメント情報を配信することである。横向きのスリップ又はスピンは、ＡＢＳシステムのみからでは判定できないが、動的な不一致の探索により検知されることに注意しなければならない。それぞれの専用スリップ検知システムが各ホイールごとに区別してデータを提供するのであれば、ここでは最も有用である。

上述したように、製造業者の専用のスリップ検知システムからの出力は、所定のキャリブレーションされたスケールに従ってスリップイベントが発生したか否かを確実に判定するために、他のシステムからの出力、例えば、力又は角度モーメントデータ、ＧＰＳデータ及び速度データと合成して処理されうる。異なるシステムからのデータを合成するために３つの異なるアプローチについて説明する。それらのシステムは、システムＡ（例えば、製造業者の専用のスリップ検知システム）と、システムＢ（例えば、他のセンサからのスリップの有無、又はＣＡＮバスを介して取得される制御システムデータを判定するモジュール２６０）として参照される。

第１のアプローチにおいて、２つのシステムＡ、Ｂのそれぞれは、可能な限り重要な結合可能密度で、バイナリデータ（スリップ有り／無し）を生成する。単純な論理ＡＮＤ操作は、システムＡ，Ｂの両方がスリップイベントを示した場合にのみ発生するモジュール２６０によって判定されるスリップイベントと、２つのソースからのデータを合成する最もダイレクトなアプローチであろう。しかしながら、システムＡ及びシステムＢからの結果が全ての状況下で偽ポジティブ及び偽ネガティブの等しい可能性からは連帯して独立しているということが想定されるであろう。当該想定は、多くのケースにおいて実際に正しいことはないであろう。完全な検知を行う４つの理想のケースがある。
−システムＡが常に正しい（特異性及び感度＝１）。
−システムＢが常に正しい（特異性及び感度＝１）。
−システムＡがスリップ有りを検知する場合は間違っていなく、システムＢがスリップ無しを検知する場合は間違っていない。
−システムＢがスリップ有りを検知する場合は間違っていなく、システムＡがスリップ無しを検知する場合は間違っていない。
さらに２つの可能な中間ケースがある。
−システムＡがスリップ有りを検知する場合はほぼ間違っていなく、システムＢがスリップ無しを検知する場合はほぼ間違っていない。
−システムＢがスリップ有りを検知する場合はほぼ間違っていなく、システムＡがスリップ無しを検知する場合はほぼ間違っていない。

実際に、問題になっている車両やシステムに依存する全ての４つのケース間ではシームレスにシフトすることができる。特定の車両の種別及びシステムの種別において、キャリブレーション手続きは、テスト車両を用いて実行される。可能であれば、テストに使用されるハードウェア／ソフトウェアは、個々の動作と、システムＡ及びＢ両方の結果に対する結合の可能性とを決定するために、全ての現実的で関連のあるスリップ（ほぼスリップ）シナリオに対してデータを測定する。テストから得られるキャリブレーションデータから導出されるモデルがその後デバイス２００に提供され、当該デバイス２００で格納される。理論的には、エラー動作がスリップシナリオに依存するであろうために、上記シチュエーションは複雑になりうる。

複雑なケースにおいて、測定されたパラメータは、力、速度、現在の曲り、及び遠心力の規模や、例えば、ますっぐなのか横向きなのかその両方なのか、加速に起因したスリップなのか、ブレーキに起因したスリップなのかを示すスリップの種別である。スリップが有るのか無いのかの決定者を判定するために、２つのシステムＡ及びＢからの出力の合成は、以下の表１に示すように、空間の各ポイントが感度−特異性テーブルによって表される多次元のパラメータベクトル空間の関数である。

実際に、最終的なパラメータ空間は、適当な数の感度−特異性テーブルをもたらす少しの変数と、変数当たりの少しのインターバルを含むであろう。スリップが有ったか無かったかに関する決定的でない結果（それ自身が有用な情報を表す）を決定者が与える閾値パラメータ以下での選択は、操作者の優先事項及びリスクマネジメント基準に基づいて判定されうる。一般的に、ここでは、偽ネガティブ”スリップ無し”の結果による潜在的なダメージは、偽ポジティブ”スリップ有り”の結果よりも大きい。

システムＡ及びシステムＢからのデータに基づきスリップが有るかスリップが無いかを判定する第２のアプローチは、連続した測定と、加重決定処理とを用いる。閾値ベースのバイナリ決定処理（スリップの有り／無し）に使用される適切なパラメータは、ホイールスリップを起こさせるの必要な（道路と並行の）力である。これは、そのような力が１つの数字で表され、必要であればモデル解釈可能な物理量であるため、特に有用である。実際には、我々は、ノイズレベルより十分に上であり、かつ、スリップの共通理解を反映する、ホイール当たりのスリップ距離の適当な閾値を使用する。このアプローチは、製造業者の専用のスリップ検知システムからの出力が（道路と並行の）力を含むか、又は、当該出力が（道路と並行の）力を判定するために使用されることを必要とする。

２つの道路に平行な力の検知システム（システムＡ及びシステムＢ）が技術的に同等であり、かつ、同等の期待値を配信するが、共同の独立した相互に関係の無いノイズがあることが想定されるのであれば、真値に最も近似し、且つ不偏な値は、以下の数式によって推定される。
ｆ＝１／２（ｆ_Ａ＋ｆ_Ｂ）
ここで、ｆ_Ａ及びｆ_Ｂは、２つのシステムＡ及びシステムＢによって測定される値である。この推定は、実際には完全には正しくないであろう。測定値ｆ_Ａ及びｆ_Ｂの統計プロパティは、前述のパラメータベクトル（スリップシナリオ）に依存するであろう。例えば、低い力での急カーブにおいて、システムＡは、高い統計精度（例えば、再現性）を有するものの、大幅に真値から過大評価するかもしれない、或いは、高い統計スプレッドを有するものの不偏の期待値を配信するかもしれない。実際には、本実施形態では第２のケースを扱うことを想定している。

車両の特定の種別及びシステムの特定の種別に関して、キャリブレーション手続きがテスト車両を用いて実行される。テストにおいて、ハードウェア／ソフトウェアは、現実的な関連のある全てのスリップ（及びほぼスリップ）に対するデータを適切な回数のシナリオで測定する。この回数は、力値ｆ_Ａ及びｆ_Ｂの統計スプレッドと、スリップの有無に関する正しい決定と誤った決定との割合とに依存する。回数Ｎのシナリオは、必要統計精度１／ｓｑｒｔ（Ｎ）に依存して繰り返される。ここで、Ｎは最も発生しづらいイベントの数となる。続く分析は各システムの加重要因ａ及びｂと関連付けられる。
ｆ＝１／ａ＋ｂ（ａ＊ｆ_Ａ＋ｂ＊ｆ_Ｂ）
ここで、ａ及びｂは、上述したパラメータ空間の関数であり、例えば、力のパラメータ、カーブ、速度、ブレーキ／アクセスのレベル（量）及び任意の適切なパラメータを含む。

第１のアプローチの場合のように、最終的なパラメータ空間は、変数当たりの少しの変数及び少しのインターバルのみを含むであろう。システムからのより信頼できないデータ（高い統計スプレッド）の場合（低いａ及びｂ）、当該決定は、有用な情報を表す、スリップ有り／なしよりもむしろ、”結論の無い”結果を与えるかもしれない。

各システムＡ及びＢは、力の測定値（評価値）ｆ_Ａ及びｆ_Ｂとともに、スリップ有り、スリップ無しを表すイベントデータを提供する。スリップ有り／スリップ無しの信頼性は、力値（評価値）ｆ_Ａ及びｆ_Ｂと、格納されたａ及びｂの値とを用いて決定される。

続いて発生するスリップイベント又は長いスリップイベントは、異なる時間での一連の評価され、測定された力を提供することができる。１つのスリップイベントから次のスリップイベントへのスリップ閾値の力の一貫性は、特定の車の現在の道路条件の測定の総合的な信頼性を判定するために使用されうる。

テストから決定されるパラメータ空間の複数のパラメータの関数としてａ及びｂの値を表すキャリブレーションデータは、デバイス２００へ連続的に提供され、格納される。運転中において、スリップ有り又はスリップ無しを表すイベントデータ、及び力ｆ_Ａ又はｆ_Ｂの測定値（又は評価値）は、システムＡ及びシステムＢから取得される。モジュール２６０は、モデルを用いて、スリップが有ったか又は無かったかを判定し、或いは、データに基づき結論のない結果を提供する。

第３のアプローチにおいて、一般的な統計メソッドを用いて融合分類が行われる。当該アプローチにおいて、単一のシステムＡ及びＢのバイナリ決定（スリップ有り又はスリップ無し）、力値ｆ_Ａ及びｆ_Ｂ、所定の期間にわたる力値の各標準偏差、Ｄｆ_Ａ及びＤｆ_Ｂ、及び追加の利用可能なパラメータ（例えば、限定はしないが、カーブ、遠心力、速度、ブレーキ／アクセル）に基づいて、システムＡ及びＢの何れかによって検知されるスリップイベントが本当にスリップイベントである可能性は、限定はしないが、多次元線形分類、多次元線形判別、支援ベクトルマシン、ニューラルネットワーク、期待値最大に基づくクラスタリングアルゴリズム、又は決定木を含む、一般的な統計アルゴリズム及び方法を用いてモデル化されうる。

第１の２つのアプローチで使用される同様の方法において、統計アルゴリズム及び方法は、各システムで区別した可能性よりもより堅固な分類を目的とし、全てのイベントに対して個々のスリップ条件の誤判別の可能性を最小化するために、意味のある方法でシステムＡ及びＢの決定を融合するために使用されうる。一方、上述した種別のより高度な一般的なアプローチは、原則として、数少ない単純化した仮定を作成し、より少ない事前知識のみを必要とし、第１の１つのアプローチよりもより良い分類性能を提供する可能性を有する。一方、それらは、上述したようなテスト車両を用いて実行されるキャリブレーション測定から導出される利用可能なトレーニングデータの十分な量をより重く必要とし、またデバイス２００でより精密なソフトウェア機能を必要とする。

ハイブリッドのアプローチにおいて、第２のアプローチの加重機能ａ及びｂは、第３のアプローチに関連して記載された種類の統計モデル化アプローチを用いて判定される。これは、必要な統計分析及び生成されたモデルの複雑性を低減し、デバイスの機能を単純化し、且つ包括的なキャリブレーションデータへの依存を軽減することができる。

３つのアプローチのそれぞれで必要とされるキャリブレーションは、種々の速度でのブレーキやアクセス、カーブ又は他のパラメータの値におけるすべての要望されるシナリオ通じて実行されるコンピュータ化されたドライバを用いて自動化された方法で実行されうる。収集されたデータは、多次元のパラメータ空間に対応するデータ構造で保存される。１つ以上の所望のアプローチに従ってシステムＡ及びＢからのデータを融合又は合成する融合／合成モデル及び関連するキャリブレーションデータがデバイス２００で格納される。いくつかの実施形態において、複数のモデル及びキャリブレーションのセットがデバイス２００で格納され、異なるモデルは、異なる製造業者からの複数のデバイスに特定される。そのようないくつかの実施形態において、デバイス２００は、接続された車の製造業者（又は、局所的なスリップ検知機能）を自動的に検知し、適切なモデルを選択する。キャリブレーション測定及びモデル生成が検知された車両又はシステムに対して実行されない場合、より単純なデフォルトモデルが使用される。

モジュール２６０が２つのシステムＡ及びＢからのデータに基づいてスリップイベントがあったか否かを判定すると、スリップがあったかどうかを表すスリップイベントデータを生成する。上述したように、スリップイベントデータは、データロギングモジュール２６２によって記録され、その後サーバ１５０へ提供される。

異なるソースからのデータの合成についてスリップ検知システムに関連して説明したが、説明したアプローチは、任意の適切なソース、例えば、任意の適切なセンサ又はイベント検知システムからのデータを合成するために使用されてもよい。

上述したように、デバイス２００は、ステータス又はセンサ出力データをサーバ１５０へ提供する。サーバ１５０は、少なくとも気象関連条件を決定するため、例えば、気象データを検証又は修正するために受信したデータを使用する。詳細については図６が提供するフローチャートを用いて説明する。

第１段階の処理において、サーバ１５０は、気象関連データ、例えば、気象データソース１８０からの気象データを受信する。

１つのモデルの動作において、サーバ１５０は、気象データソース１８０から、定期的に、例えば１５分ごとに現在の気象データを受信する。一般に現在の気象データは、最新の測定気象データと、未来の時間、例えば未来の３時間の間の１５分間隔の予報気象条件を表す予報気象データセットとを含む気象データセットを含む。

各気象データセットは、各々が領域の各場所における気象条件（例えば、降雨量）を表す複数のデータ点を含んでもよい。いくつかの例において、データ点は、領域にわたる等間隔の点に対応してもよい。いくつかの実施形態において、あらゆる適切なデータ形式が使用可能であるが、気象データはテキストデータ又はＸＭＬデータの形式である。いくつかの例において、気象データセットは、特定の時間における領域の気象条件を表す画像を表示するために使用される気象データのフレームを含むか又はそれを生成するために使用される。

いくつかの動作モードにおいて、サーバ１５０は、各々が１つの特定の時間における異なる気象条件（例えば、降雨量、気温、風速）を表す複数の気象データセットを受信してもよい。

段階１５２において、サーバ１５０はまた、車両内臓のデバイス、例えば、上述したＰＮＤデバイスなどから車両データを受信する。サーバ１５０は、大抵、多くのデバイス、例えば、複数のＰＮＤデバイスからのデータを受信する。

気象データ処理モジュール１７０は、位置依存の車両データと、受信した位置依存の気象データとを関連付け、これにより気象データを検証又は修正する。このように、不確かな外部ソースからの情報は、検証又は修正され、気象の警告は生成され、修正され、及び特定のエリアでよりフォーカスされるかの少なくとも１つが行われる。気象データと局所的な車両データとの融合は、実質的に制限された信頼性内のソースから情報を有効にし、気象条件、例えば、豪雨や凍結の位置特定をより改善するために使用され、さもなければ対応するセンサが備え付けられた道路の類似の程度に局所化されうる。

上述したように、ステータス又はセンサ出力データの多くの異なる種別は、デバイス、例えば、デバイス２００によって提供される。モジュール１７０によって実行されるデータの処理と、関連付け又は他の統計手続きとは、データの特定の種別問題のあるアプリケーションに依存して検証されうる。

動作の１つのモードにおいて、気象データ処理モジュール１７０は、多くの車両デバイスから受信されるステータス又はセンサ出力データによって表されるように、場所及び時間の関数として、フロントワイパーの動作量、降雨センサデータ、及び昼間のヘッドライト起動を判定する。例えば、（種々の他の環境パラメータ又はトラフィックパラメータも表すことができる）モデルに基づき、特定の場所及び時間間隔における、フロントワイパーの動作量、降雨センサデータ、及び昼間のヘッドライト起動の少なくとも１つが降水がある、例えば、降雨があることを提案するのであれば、モジュールは、モデルに基づく場所及び時間で降水がある、例えば、降雨があることを決定する。単純なケースにおいて、モデルは、フロントワイパーの動作、降雨センサデータ、及びヘッドライトの起動を閾値と比較することを単に含んでもよい。

その後、モジュール１７０は、各場所に対して、雨の実際の若しくは予測の有無又は他の降水を示す気象データと、後述する閾値手続きでの受信した車両データから決定される降水の有無とを比較する。特定の場所において、気象データが当該期間の間は降水がないであろうことを示すものの、車両データが（フロントワイパーの動作、ヘッドライトの起動及び雨センサデータからのデータ）降雨又は他の降水があることを示す場合、モジュール１７０は、気象データを当該場所において、降水があることを示すように修正する。

閾値は、所定の気象条件の存在を確実に示すために、所定の時間間隔内で超えるべき必要のある特定の領域又は特定の場所からを起源とする、指標イベント（例えば、フロントワイパーの動作、ヘッドライトの起動、又は雨の存在を示す雨センサデータ）の数に基づき定義されうる。

特定のケースで使用される閾値は、問題となる気象条件の本質及び重大性に依存することができる。例えば、より高い閾値は、豪雨の有無を判定するために使用されることができ、より低い閾値は、小雨の有無を判定するために使用されることができる。閾値は、気象条件を示すデータを生成できる適切に装備された車両の評価された数にも依存することができる。利用可能な車両の数は、現在の交通密度、例えば、車両間の距離を示す車両超音波及びレーダセンサデータから、同様に、Ｔｏｍ−ＴｏｍＩＱ経路システムで使用されるような、時間分解された道路指定の履歴交通統計から得られる交通密度についての情報に基づいて決定されてもよい。本実施形態において、閾値と多くの車両又はイベントを比較する処理は、車両（例えば車両の数と比較される）又はイベント（例えば、可能性のあるイベントの数と比較される）の割合と、ここで示される閾値とを比較する処理を等しく含む。

所定の気象条件の有無を示すために必要な閾値を定義するのに使用されるモデルが判定されうる。或いは、全ての収集されたイベントデータ、他のデータ、又は、センサ出力データは、過去の外部の気象データ、他の関連パラメータ、及び事後検証された気象条件とそれらのデータと関連付けることにより、履歴のデータベースに格納され、統計的に分析される。そのような過去の統計分析を用いることによって、所定のシチュエーションにおける必要な閾値を計算するモデルは、外れる予報の可能性を最小限にするように、生成されうる。データベースが成長するにつれて、統計分析は、生成されたモデルを継続的に改善するために、定期的に繰り返し行われる。 十分な量の履歴データ及び領域データを収集するために、モデルは、例えば、時刻、季節、領域種別（例えば、沿岸、山、砂漠、街）に、又は特定の領域（例えば、濃霧の可能性のある領域）に依存しうる。

いくつかの実施形態において、修正又は検証された気象データは移動デバイス、例えば、ＰＮＤ２００ａ乃至２００ｅへ送信され、アプリケーション又は処理に関連する任意の所望の気象のために見られるか又は使用されうる。多くのケースにおいて、ＰＮＤ又は他の移動デバイスへの送信パスは、資源された帯域幅であり、ＰＮＤ又は他の移動デバイスへ送信されるデータの量は、制限されることが望ましい。これは、気象予報の更新のように、例えば１５分ごとの間隔でデータの大量送信が行われる、気象データの送信に関する特定のケースである。

いくつかの実施形態において、サーバ１５０は、気象データソース１８０から受信される気象データを処理し、気象データが特定のエリアに対する荒天を示すのであれば、気象の警告を生成するように構成される。

気象の警告の生成は、気象の警告が車両データと整合することを保障するために、車両データに従って実行されうる。いくつかのケースにおいて、気象の警告は、車両データの全体に基づいて生成されうる。問題となる気象条件の種類に従って、同一の車両からのデータから識別されるいくつかの異なるイベントの整合、又は、複数の車両からのデータから複数の類似したイベントの整合は、特定の気象条件指標を強化し、これにより、対応する警告のトリガとなる。同一の又は異なる車両からのデータによって示される複数のイベントの融合、及び外部のソース、例えば、データソース１８０からの気象データとの相互関連は、特定の状況（例えば、ガレージ又はトンネルにおける車両の存在、又は車両の暖房の効果）によって信頼のない車両センサデータに依存する比較において、気象の警告のロバスト性をより改善することができる。

図７は、嵐の警告が発生しているドイツのエリア６００、６０２、６０４、６０８（他の同様のエリア）を示す。サーバ１５０は、受信した気象データに基づき、嵐の警告のエリアを判定し、それらのエリアを表す気象の警告データを、ＰＮＤ又は他の移動デバイス、例えばデバイス２００へ送信する。

動作の１つのモデルにおいて、サーバ１５０は、定期的に気象警告データを含み、一般的には領域内の全てのナビゲーションデバイスへ送信する。本実施形態の変形例において、個々の車両又は複数の車両によって報告される特定のイベントに応じて、追加の専用の気象関連の警告、例えば、路面上の氷、非常に厳しい荒天は、それらの現在の位置及び経路が警告が着雪関連するであろうことを示すオリジナルの個別の車両又は複数の車両付近における全ての接続された車両へ送信する。サーバ１５０は、影響のある車両が気象関連のデータを、定期的な気象の警告の送信（局所化された警告も含んでよいが）を介するよりも早く受信するように、優先的な基準での局所化された警告などを配信するように構成される。受信した気象警告のデータは、経路を適合しＥＴＡを修正するために、デバイス、例えば、デバイス２００ａ乃至２００ｅによって使用される。

各ケースにおいて、サーバ１５０から送信される気象警告のデータは、気象警告の開始時刻、終了時刻又は継続期間を表す時間データを含むことができる。少なくとも１つの気象関連条件の判定、例えば、気象データの検証又は修正において、デバイスから受信される車両データの使用については既に上述している。図７のケースにおいて、そのようなデータは、気象の警告が適用されるエリアの判定、修正又は検証を行うために、そのようなデータが使用されるうる。上記データは、また気象警告の期間を修正又は検証するために使用されうる。

いくつかの実施形態において、サーバ１５０は、気象データなどの外部情報と合成して、車両から受信される車両データによって表される所定の気象関連のイベントの有無を分析することによって、気象の警告の寿命を判定する。例えば、サーバ１５０は、道路の特定の凍結の警告終了するために、ソース１８０からの気象データによって示され、車両から受信されるステータス又はセンサ出力データから決定される正常に戻る平均車両速度と認められる、領域の気温の上昇と、所定の時間間隔でのホイールスリップイベントの有無とを関連付けてもよい。

サーバ１５０はまた、古い道路に沿った降雨の警告を描画するために、例えば、気象データソース１８０からの最近の及び予報の降雨レーダ情報と、特定の道路に沿った車両におけるライト起動のないフロントワイパーの動作とを関連付けてもよい。

瞬間的な車両データ及び気象データに基づくよりもむしろ、所定時間にわたる車両データ及び気象データの変動に基づく気象警告の分析を行うことによって、気象の警告の正確性やその期間は、改善されるであろう。例えば、非常に寒い条件が発生したと判定され、多くスリップイベントの検知により気象警告が発行される場合、当該気象警告は、スリップイベントの数が減少しても、気象データが気温が上がっていないことを示せば、気性警告は維持される。この場合、スリップイベントの減少は、っ問えばドライバがより注意深く（例えば、気象警告によって）運転したことに起因するものであるかもしれない。

気象警告の正確性は、所定期間にわたる車両データ及び気象データの少なくとも一方の過去変動と、特定の気象条件の発生との間の関係を示す統計モデルを提供することよってさらに増大されうる。

気象条件の種別に依存して、サーバ１５０は、気象警告を終了するか否かを判定する才に、気象条件に関連する特定の気象警告の現在の継続時間とともに問題となる気象条件の典型的な継続時間の既存の情報を使用することができる。

いくつかの実施形態において、サーバ１５０は、車両からのデータによって表される個々のイベントの不足だけでなく、警告を終了するために所定の逆の意味示すイベントの存在も必要としない。

いくつかの実施形態において、車両から受信されるステータス又はセンサ出力データに基づき、閾値は、警告がサーバ１５０によって廃止されるべきと判定される前に、認識されたイベント発生割合が低下する下での時間間隔の中で、個々のイベントの数で定義される。そのような閾値は、第１の場所での警告を発行するために定義された閾値と等しい必要はなく、代わりにそれよりも低くてもよい。そのような閾値は、通常、自然のかつ過酷な気象条件に、警告の継続時間に、外部気象ソースから抽出された影響のあるパラメータの値及び信頼性に、且つ、問題のある道路又はエリアでの現在の潜在的なイベントソース（すなわち、適切に装備された車両）の評価された数に関する情報に依存する。警告をキャンセルするための予め定義された閾値基準が満たされた後に、いくつかの実施形態において、サーバ１５０は、問題のある気象条件の本質に、且つ、気象条件を示してもよい任意の他のパラメータに依存して警告の遅延として参照されうる、継続期間に対する警告を維持する。

警告パラメータ及び他のパラメータの年齢への閾値及び警告遅延の依存関係は、発見的に決定されることができるが、より高度な改良において、改善されたパラメータについての履歴データが履歴の存続期間、事後検証された気象の警告と相互に関連付けられる、オフライン統計分析からも得られる。モデル生成処理は、利用可能なデータが増大するに従って繰り返し行われる。気象の警告を生成又は除去する閾値を決定するための十分な量の履歴データ及び局所的なデータを収集することや、当該モデルは、同様に、時刻、シーズン、領域種別に基づくことができ、或いは、個別の領域に特定されてもよい。

車両データ、例えば、車両から受信されるステータス又はセンサ出力データの使用は、気象データ及び気象の警告の検証、修正又は生成において説明された。そのようなデータは、交通の状況を気象条件と関連付けるための統計手続きにおいて使用されうる。そのような手続きの一例は、種々の道路セグメントに沿った運行の速度での気象条件の効果の決定に関する。

図１の実施形態の変形例において、サーバ１５０は、速度プロファイルでの気象条件の効果を決定するために相互に関連する手続きにおいて、デバイス２００などの車両内蔵デバイスからの履歴車両データを使用する。

第１段階の手続きにおいて、サーバ１５０は、ある長い期間、例えば１年にわたるデジタル地図により表された領域の気象条件を表す履歴気象データを取得する。サーバ１５０は、データ記憶部１６０に格納され且つデジタル地図により表された道路又は他の主要道路における車両の移動を表す大量のプローブデータにアクセスできる。プローブデータは、例えば時間ビン毎の個々の道路セグメントに沿う平均車両速度、時間ビン毎の個々の道路セグメントにおける交通密度（例えば、ナビゲーションデバイスの外挿及び正規化された密度から取得されるか、あるいは車両の前後に配置された超音波距離検出器から取得される）、道路セグメント及び時間ビンの各々に対する速度の統計的分布、並びに個々の道路セグメント及び時間ビンに対する渋滞の確率のうちの１つ以上を取得するために処理される。

この場合、プローブデータは、車両データ、例えば、車両内蔵のデバイスから取得されたステータス又はセンサ出力データであり、特定の気象条件を表すか若しくは特定の気象条件を関連付けれる車両データも含む。個々の車両から得られるそのような気象関連データは、上述したような、例えば、スリップイベント、フォグランプの動作、フロントワイパーの動作、気温測定若しくは降雨検知を表すデータ、又は、任意の他の適切なパラメータを含むことができる。

気象データは、例えば雨、あられ又は雪等が降ること又はその降水量、風速、風向、凍結の有無又は凍結量、積雪の有無又は積雪量、地表水の発生又はその量、霧の有無又は霧の量、視界レベル、並びに気温のうちの１つ以上である１つ以上の種々の気象種別を表せる。あらゆる適切な送信元から取得された気象データ、例えば政府又は民間の機関により維持された公式の気象レコード。複数の送信元からの気象データが使用されてもよい。いくつかの実施形態において、適切に装備された個々の車両から取得された気象関連データも使用できる。

サーバ１５０は、気象に依存する速度平均及びそれらの重要性の統計的に重要な測定を可能にするために気象データ及びプローブデータの非常に大きなアーカイブにアクセスできる。サーバ１５０は、デジタル地図の道路又は他の主要道路の種々のセグメントの平均速度の変動と各気象条件の変動とを互いに関連付ける相関技術を適用する。モデル化モジュール１７０は、要望に応じて、気象条件と、ステータス又はセンサ出力データなどの取得した車両データとの統計的な相関、同様に、例えば渋滞の確率、運転者の経路の好み又は他のあらゆる交通関連パラメータとの統計的な相関を導出できる。サーバ１５０は、速度プロファイル及び気象の影響を計算するためにオフライン統計解析を提供する。

気象条件に対する感度に基づく種々の道路種別の分類は、相関手順を実行する際に有用であることが分かっている。例えば降水強度のみでは、全ての道路に対する平均速度変更を与えるある代数式のパラメータとしては不十分であることが多い。降水量の影響は、局地交通の例及び道路のレイアウトによっては非線形的であり且つ不連続である可能性がある。

１つの動作モードにおいて、各道路セグメントは、複数の道路種別の分類子のうちの１つに分類される（例えば、５個の種々の道路種別の分類子が使用されてもよい）。各分類子は、１つ以上の特性、例えば幅、車線数、路面の種類、通常の状態の平均速度又は交通量、都心又は地方、交通の分岐点又は信号機までの近接度を有する道路を表してもよい。トムトム社（ＴｏｍＴｏｍ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｂ．Ｖ．）が自身の製品において使用するような機能道路分類（ＦＲＣ）は道路分類子として使用されてもよい。各道路セグメントは、その道路セグメントのプロパティの演繹的な評価に基づいて分類子を割り当てられてもよく、あるいは気象条件によりどのようにセグメントの速度プロパティが変動するかの演繹的決定に基づいて分類子を割り当てられてもよい。２番目の例において、各分類子は、少なくとも１つの気象条件に対する各感度レベルを表してもよい。

使用される分類の数及び種類は、気象条件に対する種々のセグメントの異なる反応の数及び交通に対する重要度に依存し、一般に分類の数が多いほどデバイスに送信される必要があるデータ量は多いため、チャネル１５２を介してデバイス２００ａ〜２００ｅにデータを送信するための帯域幅の制限にも依存しうる。１つの動作モードにおいて、各道路セグメントの分類を表す分類データは、デバイス２００ａ〜２００ｅへ送信され、デジタル地図データとして格納される。

各分類に対して、種々の種類及びレベルの気象条件に対する反応は、その分類の各セグメントの速度データとその道路セグメントにおける気象条件を表す対応する気象データとを互いに関連付けることにより決定される。一般に反応は、気象により低下されない速度プロファイルに対する速度の変更を表す。混雑の推定は、一般に、自由走行速度の偏差として時間に依存する速度プロファイルを介して暗示される。相関処理は時間に依存する処理であり、日又は週の同一時間に対して取得された気象データ及び速度データを互いに関連付け、これにより特定のセグメントに対する平均速度の日毎又は週毎の予想される変動を考慮に入れる。

相関処理は、ある期間にわたる気象条件の変動、並びに速度又は他の移動条件の関連した変化を考慮に入れることができる。例えば相関処理は、ある期間にわたる気温又は他の気象条件の所定の変動に対して、１つ又は複数の所定の道路セグメント、あるいは所定の道路の分類の種別に対する積雪又は凍結がなくなったか又は除去されたことが分かるまでの速さを決定できる。例えば特定の気温の上昇を仮定して、ある道路に対して積雪及び凍結が他の道路より速くなくなると予想される可能性があることが分かるだろう。多くの道路セグメントに対する大量の履歴データを仮定すると、そのような複数パラメータの相関は相対的に正確に決定される。

相関処理は、１つ以上の種類及び荒天レベルの気象条件に応答して、平均速度の予想変更を表す道路セグメントの分類の種類の各々に対して気象反応データが生成される結果となりうる。

道路セグメントの分類の種類の各々に対する荒天に伴う速度の変動は、例えば速度変更が特定の荒天程度と共に指数関数的に変動する指数関数モデルである量的モデルを使用して効果的にモデル化されることが分かっている。気象反応データは、既知のフィッティング技術を使用して選択されたモデルにフィッティングされる。

相関処理及びフィッティング処理は、計算コストがかかり、いくつかの動作モードにおいて、３〜６ヶ月毎にだけ繰り返されるか、あるいは交通エンジニア又は他のオペレータが結果に影響を及ぼす変化が起きたと考えた時にのみ繰り返される。

２つの量の相関についての参照は、１つの量の変動と他の量の変動との間で任意の関係が確立することを参照してもよい。上記相関は履歴データに基づいてもよい。

上述した詳細な説明において説明した実施形態はＧＰＳを参照したが、ナビゲーションデバイスは、ＧＰＳの代わりに（又は実際にはＧＰＳに加えて）あらゆる種類の位置検知技術を利用してもよい。例えばナビゲーションデバイスは、欧州のＧａｌｉｌｅｏシステム等の他のグローバルナビゲーション衛星システムを利用してもよい。同様に、実施形態は衛星を用いたシステムを使用することに限定されず、地上ビーコン、慣性センサ又はデバイスが地理的場所を決定できるようにする他のどんな種類のシステムを使用しても容易に機能できる。

本明細書で説明した実施形態において、特定の機能性はサーバにおいて提供されるものとして説明され、他の機能性は例えばＰＮＤ又は他の移動デバイスであるデバイスにおいて提供されるものとしてされる。その一方で、別の実施形態においては、説明した機能性のいずれもサーバ又はデバイスで提供可能である。例えば、サーバがナビゲーションデバイスとして動作してもよいいくつかの実施形態では、ほぼ全て機能性はサーバにおいて提供される。他の実施形態において、ほぼ全ての機能性は、気象データ又は他のデータをサーバからではなくデータ送信元から直接受信してもよいデバイスにおいて提供される。

本発明の別の実施形態は、コンピュータシステムと共に使用するコンピュータプログラムとして実現可能であり、コンピュータプログラムは、例えばディスケット、ＣＤ−ＲＯＭ、ＲＯＭ又は固定ディスク等の有形データ記録媒体に格納される一連のコンピュータ命令であるか、あるいは例えばマイクロ波又は赤外線である無線媒体又は有形の媒体を介して送信されるコンピュータデータ信号において具現化される一連のコンピュータ命令である。一連のコンピュータ命令は上述の機能性の全て又は一部を構成でき、半導体メモリ素子、磁気メモリ素子、光メモリ素子又は他のメモリ素子等のあらゆる揮発性又は不揮発性メモリ素子に更に格納できる。

本明細書において特定のモジュールを説明したが、別の実施形態において、それらモジュールの１つ以上の機能性は単一のモジュール又は他の構成要素により提供されるか、あるいは単一のモジュールにより提供される機能性は２つ以上のモジュール又は他の構成要素の組み合わせにより提供される。

好適な実施形態は、特定の機能性をソフトウェアにより実現するが、その機能性はハードウェアでのみ（例えば、１つ以上のＡＳＩＣ（特定用途向け集積回路）により）同様に実現可能であり、あるいは実際はハードウェア及びソフトウェアの組み合わせにより実現可能であることも当業者にはよく理解されるだろう。そのため、本発明の範囲は、ソフトウェアで実現されることのみに限定されると解釈されるべきではない。

本発明は単なる例として説明され、本発明の範囲内でその詳細が変更されてよいことが理解されるだろう。

説明、並びに請求項及び図面（必要に応じて）において開示される各特徴は、個別に又はあらゆる適切な組み合わせで提供されてもよい。

最後に、添付の請求の範囲は本明細書で説明した特徴の特定の組み合わせを記載するが、本発明の範囲は、以下に請求される特定の組み合わせに限定されず、特定の組み合わせが添付の請求の範囲に特に記載されているか否かに関わらず、本明細書で開示された特徴又は実施形態のどんな組み合わせも含む。

Claims (14)

1. 複数の車両に実装される複数のデバイスと通信を行うように構成されたサーバシステムであって、
   前記複数の車両からの、前記車両のパラメータを示す車両データを受信する通信リソースと、
   気象データを取得し、前記気象データ及び前記車両データの両方に従って少なくとも１つの気象関連条件を決定するために、前記気象データ及び前記車両データを処理するように動作可能な処理リソースと
   を備え、
   前記少なくとも１つの気象関連条件を決定する前記気象データ及び前記車両データの処理は、前記車両データの少なくとも一部に基づいて、前記気象データを修正又は検証し、
   前記車両データは、前記車両のドライビング動作を表し、
   前記処理リソースは、前記車両の前記ドライビング動作が前記気象データと整合するかどうかを判断し、当該判断結果に応じて前記気象データを修正又は検証するように構成されることを特徴とするサーバシステム。
2. 前記気象関連条件は、気象条件及び道路上の少なくとも１つの場所の条件の少なくとも一方を含むことを特徴とする請求項１に記載のサーバシステム。
3. 前記車両データは、前記車両の動作プロパティ、及び、前記車両での気象関連条件を含む環境条件の少なくとも一方を表すことを特徴とする請求項１又は２に記載のサーバシステム。
4. 前記処理リソースは、前記気象データと、前記車両データとに基づき、前記気象関連条件を決定するために、統計モデルを適用するように構成され、
   前記統計モデルは、過去の車両データと、過去の気象データと、少なくとも１つの気象関連条件の過去の発生との間における関係を表すことを特徴とする請求項１乃至３の何れか１項に記載のサーバシステム。
5. 前記少なくとも１つの気象関連条件を決定する前記気象データ及び前記車両データの処理は、気象関連の警告を表す警告データを生成、修正又は検証することを特徴とする請求項１乃至４の何れか１項に記載のサーバシステム。
6. 前記処理リソースは、所定の時間期間にわたる前記気象データ及び前記車両データの少なくとも一方の変動に従って前記警告データを生成、修正、又は検証するように構成されることを特徴とする請求項５に記載のサーバシステム。
7. 前記処理リソースは、所定の時間期間にわたる車両データの過去の変動、所定の時間期間にわたる気象データの過去の変動、及び前記少なくとも１つの気象関連条件の過去の発生の間の関係を表す統計モデルを適用することによって、前記警告データを生成、修正、又は検証するように構成されることを特徴とする請求項５又は６に記載のサーバシステム。
8. 前記警告データは、前記気象関連の警告の開始、終了、又は期間を表す時刻データを含み、
   前記処理リソースは、前記車両データを監視し、前記車両データに従って前記時刻データの生成、検証、及び修正の少なくとも１つを行うように構成されることを特徴とする請求項５乃至７の何れか１項に記載のサーバシステム。
9. 前記車両データは、１つ以上のスリップイベントの有無を表すことを特徴とする請求項１乃至８の何れか１項に記載のサーバシステム。
10. 前記処理リソースは、エリアの少なくとも１つの車両に実装された複数のデバイスから受信した車両データに従って前記エリアにおける気象関連の警告を生成又は修正し、他のデバイスの場所に従って前記他のデバイスに前記気象関連の警告を選択的に送信し、
    前記他のデバイスは、前記エリアに存在することを特徴とする請求項１乃至９の何れか１項に記載のサーバシステム。
11. 前記車両データは、第１の車両システムから取得される第１の車両データと、該第１の車両システムとは異なる第２の車両システムから取得される第２の車両データとを含み、
    前記処理リソースは、イベントが発生したかどうかを前記第１及び第２の車両データから決定するように構成されることを特徴とする請求項１乃至１０の何れか１項に記載のサーバシステム。
12. 前記イベントは、スリップイベントであり、
    前記第１の車両システムは、専用の車両スリップ検知システムを備え、
    前記第２の車両システムは、加速度センサ、角度モーメントセンサ、力センサ、ステアリングセンサ、及びブレーキングセンサの少なくとも１つを備えることを特徴とする請求項１１に記載のサーバシステム。
13. 複数の車両に実装される複数のデバイスと通信する方法であって、
    前記複数の車両からの、前記車両のパラメータを示す車両データをサーバで受信するステップと、
    前記サーバで気象データを取得するステップと、
    前記気象データ及び前記車両データの両方に従って少なくとも１つの気象関連条件を決定するために前記気象データ及び前記車両データを処理するステップと
    を含み、
    前記車両データを処理する前記ステップは、前記車両データの少なくとも一部に基づいて、前記気象データを修正又は検証するステップを含み、
    前記車両データは、前記車両のドライビング動作を表し、
    前記処理するステップは、前記車両の前記ドライビング動作が前記気象データと整合するかどうかを判断し、当該判断結果に応じて前記気象データを修正又は検証することを特徴とする方法。
14. 請求項１３に記載の方法の各ステップを実行するコンピュータで実行可能なコンピュータ読み取り可能命令を含むコンピュータプログラム。