使用参与式感测系统来改进道路摩擦估算

摘要

本发明公开了使用参与式感测系统来改进道路摩擦估算。公开了用于如下操作的方法和系统：通过车辆进行道路摩擦状况的参与式感测，通过中央服务器从大量车辆收集摩擦数据，对数据进行处理以便通过道路和现场对摩擦状况进行分类，以及按需要向车辆发送摩擦状况的通知。大量车辆使用参与式感测系统来识别汇报至中央服务器的道路摩擦估值——其中车辆使用传感器数据和车辆动态状况来估算摩擦。中央服务器储存和聚集摩擦数据、过滤数据并且使数据折减。请求来自中央服务器的报告的车辆会收到道路摩擦状况的通知，其重要性可取决于车辆的位置和前进方向。如果前方摩擦状况较低，则可发出驾驶员警告，并且自动车辆系统也可对通知做出回应。

说明书

技术领域

本发明大体上涉及使用来自车辆的众包数据来确定道路摩擦状况，更加具体地涉及用于使用车辆参与式感测系统来确定道路摩擦状况的方法和装置，其中，可将来自多个车辆的路面摩擦数据收集在中央服务器上并对其进行分析，以通过道路和现场识别摩擦状况，并且将道路摩擦状况的报告传达至道路上的车辆。

背景技术

如今许多车辆都包括能够感测关于车辆的操作环境的广泛参数的系统。例如，车辆动态传感器可限定车辆的动态状态，目标检测系统可检测道路上和附近的实体和其他车辆，例如制动、转向、ABS和安全气囊的车辆系统的状态可以得到，并且交通和道路状况可由多种方法来确定。主车辆对大多数这种数据进行实时地估算并且使用，在数据变得陈旧时将其丢弃。

同时，许多现代车辆上都有可用的信息通讯系统，其中，信息通讯系统连续不断地或定期地将数据从车辆传达至集中式数据库系统，集中式数据库系统又将信息传达回车辆。尽管这些信息通讯系统已经用于收集一些有限的车辆数据类型以用于特定目的——比如检测车辆中的安全气囊展开和自动地请求紧急服务——但还有更多数据可从大量车辆收集到，这些数据可用于识别广泛的交通和道路状况，这些交通和道路状况可传播至一定地理位置中的其他车辆并对其有利。

发明内容

根据本发明的教导，公开了用于如下操作的方法和系统：通过道路车辆进行道路摩擦状况的参与式感测，通过中央服务器从大量车辆收集摩擦数据，对数据进行处理以便通过道路和现场对摩擦状况进行分类，以及按需要向车辆发送摩擦状况的通知。大量车辆使用参与式感测系统来识别能够汇报至中央服务器的道路摩擦估值——其中车辆使用传感器数据和车辆动态状况来估算摩擦。中央服务器储存和聚集摩擦数据、过滤数据并且使数据折减。典型地经由信息通讯系统请求来自中央服务器的报告的车辆会收到道路摩擦状况的通知，其重要性可极大地取决于车辆的位置和前进方向。如果前方摩擦状况较低，则可发出驾驶员警告，并且自动车辆系统也可对通知做出回应。

本发明还公开了如下技术方案。

1、一种通过使用车辆参与式感测系统来估算道路摩擦状况的方法，所述方法包括：

通过多个参与式感测系统车辆提供关于道路摩擦状况的数据；

在包括处理器和存储器的服务器计算机上从所述参与式感测系统车辆收集关于所述道路摩擦状况的所述数据；

通过所述服务器计算机分析关于所述道路摩擦状况的所述数据，以便确定一般道路摩擦估值；

从所述服务器计算机向报告接收车辆和其他实体发送道路摩擦报告，其中所述道路摩擦报告包括特定道路和位置的一般道路摩擦估值；

使用所述道路摩擦报告作为输入至所述报告接收车辆中的牵引力相关系统的输入；

将所述报告中描述的任何低摩擦状况通知给所述报告接收车辆的驾驶员。

2、如方案1所述的方法，其中，提供关于道路摩擦状况的数据包括：监测来自车辆传感器和系统的数据，识别触发事件，计算道路摩擦值，以及将所述道路摩擦值和车辆位置传达至所述服务器计算机。

3、如方案2所述的方法，其中，监测来自车辆传感器和系统的数据包括：监测来自车辆动态传感器的数据、来自环境传感器的数据、以及来自车辆系统的能够在车辆数据总线上得到的数据。

4、如方案1所述的方法，其中，提供关于道路摩擦状况的数据包括：确定所述参与式感测系统车辆是否处于线性或非线性的操作规程中，确定所述参与式感测系统车辆是否正在直的或者弯曲的路径上行驶，以及按照取决于所述操作规程和所述路径的方式计算摩擦值的系数。

5、如方案1所述的方法，其中，分析关于所述道路摩擦状况的所述数据以便确定一般道路摩擦估值包括：聚集所述数据，过滤所述数据，向所述数据应用时间衰减并且清除所述数据。

6、如方案1所述的方法，其中，分析关于所述道路摩擦状况的所述数据以确定一般道路摩擦估值包括：作为来自所述参与式感测系统车辆的关于所述道路摩擦状况的当前数据、来自所述参与式感测系统车辆的关于所述道路摩擦状况的历史数据以及来自包括天气数据的在线源的摩擦相关数据的函数，来计算所述一般道路摩擦估值。

7、如方案6所述的方法，其中，用于计算所述一般道路摩擦估值的所述函数是基于交集的函数，所述基于交集的函数只考虑关于能够应用至每种特定道路和位置的所述道路摩擦状况的数据。

8、如方案1所述的方法，其中，使用所述道路摩擦报告作为输入至所述报告接收车辆中的牵引力相关系统的输入包括：使用包含在所述报告中的所述一般道路摩擦估值作为输入至稳定性控制系统、防抱死制动系统、牵引力控制系统和传输模式选择系统的输入。

9、如方案1所述的方法，其中，从所述服务器计算机向其他实体发送道路摩擦报告包括：向对存在低摩擦状况的道路负责的道路委员会发送低摩擦状况的报告。

10、如方案9所述的方法，其中，发送至所述道路委员会的所述报告包括：包括扫雪和道路撒盐以及电子标牌消息内容的需要立即关注的低摩擦状况的报告，以及包括道路设计更改和永久路标更改的需要长时期关注的长期低摩擦状况的报告。

11、一种通过使用车辆参与式感测系统来估算道路摩擦状况的方法，所述方法包括：

通过多个参与式感测系统车辆提供关于道路摩擦状况的数据，包括监测来自车辆传感器和系统的数据，识别触发事件，计算道路摩擦值，以及将所述道路摩擦值和车辆位置传达至服务器计算机；

在包括处理器和存储器的服务器计算机上从所述参与式感测系统车辆收集关于所述道路摩擦状况的所述数据；

通过所述服务器计算机分析关于所述道路摩擦状况的所述数据，以便确定一般道路摩擦估值；

从所述服务器计算机向报告接收车辆发送道路摩擦报告，其中所述道路摩擦报告包括特定道路和位置的一般道路摩擦估值；

使用所述道路摩擦报告作为输入至所述报告接收车辆中的牵引力相关系统的输入；

将所述报告中描述的任何低摩擦状况通知给所述报告接收车辆的驾驶员；以及

从所述服务器计算机向对存在低摩擦状况的道路负责的道路委员会发送低摩擦状况的报告，其中，所述报告包括：包括扫雪和道路撒盐以及电子标牌消息内容的需要立即关注的低摩擦状况的报告，以及包括道路设计更改和永久路标更改的需要长时期关注的长期低摩擦状况的报告。

12、如方案11所述的方法，其中，提供关于道路摩擦状况的数据包括：确定所述参与式感测系统车辆是否处于线性或非线性的操作规程中，确定所述参与式感测系统车辆是否正在直的或者弯曲的路径上行驶，以及按照取决于所述操作规程和所述路径的方式计算摩擦值的系数。

13、如方案11所述的方法，其中，分析关于所述道路摩擦状况的所述数据以确定一般道路摩擦估值包括：作为来自所述参与式感测系统车辆的关于所述道路摩擦状况的当前数据、来自所述参与式感测系统车辆的关于所述道路摩擦状况的历史数据以及来自包括天气数据的在线源的摩擦相关数据的函数，来计算所述一般道路摩擦估值。

14、一种用于估算道路摩擦状况的车辆参与式感测系统，所述系统包括：

具有配置用于提供关于道路摩擦状况的数据的处理器和传感器的多个参与式感测系统车辆，其中，所述处理器监测来自车辆动态传感器的数据、来自环境传感器的数据、以及来自车辆系统的能够在车辆数据总线上得到的数据，所述参与式感测系统车辆还包括用于传达关于所述道路摩擦状况的数据的无线通信系统；

包括处理器和存储器的服务器计算机，所述服务器计算机配置为：从所述参与式感测系统车辆接收关于所述道路摩擦状况的所述数据，分析关于所述道路摩擦状况的所述数据以便确定一般道路摩擦估值，以及发送道路摩擦报告，其中，所述道路摩擦报告包括用于特定道路和位置的所述一般道路摩擦估值；以及

多个报告接收车辆，其具有用于接收所述道路摩擦报告的无线通信系统以及配置用于将所述报告中描述的任何低摩擦状况通知给驾驶员的处理器。

15、如方案14所述的系统，其中，所述参与式感测系统车辆中的所述处理器配置用于监测来自所述车辆动态传感器的数据、来自所述环境传感器的数据和来自所述车辆数据总线的数据，识别触发事件，计算道路摩擦值，以及将所述道路摩擦值和车辆位置传达至所述服务器计算机。

16、如方案14所述的系统，其中，所述参与式感测系统车辆中的所述处理器配置用于：确定所述参与式感测系统车辆是否处于线性或非线性的操作规程中，确定所述参与式感测系统车辆是否正在直的或者弯曲的路径上行驶，以及按照取决于所述操作规程和所述路径的方式计算摩擦值的系数。

17、如方案14所述的系统，其中，所述服务器计算机配置用于：作为来自所述参与式感测系统车辆的关于所述道路摩擦状况的当前数据、来自所述参与式感测系统车辆的关于所述道路摩擦状况的历史数据以及来自包括天气数据的在线源的摩擦相关数据的函数，来计算所述一般道路摩擦估值。

18、如方案17所述的系统，其中，用于计算所述一般道路摩擦估值的所述函数是基于交集的函数，所述基于交集的函数只考虑关于能够应用至每种特定道路和位置的所述道路摩擦状况的数据。

19、如方案14所述的系统，其中，所述报告接收车辆中的所述处理器配置用于：使用包含在所述报告中的所述一般道路摩擦估值作为输入至稳定性控制系统、防抱死制动系统、牵引力控制系统和传输模式选择系统的输入。

20、如方案14所述的系统，其中，所述服务器计算机配置用于：向对存在低摩擦状况的道路负责的道路委员会发送低摩擦状况的报告，其中，所述报告包括：包括扫雪和道路撒盐以及电子标牌消息内容的需要立即关注的低摩擦状况的报告，以及包括道路设计更改和永久路标更改的需要长时期关注的长期低摩擦状况的报告。

参照如下说明书和所附权利要求书，并结合附图，本发明的附加特征将变得显而易见。

附图说明

图1是具有参与式感测系统和用于将数据传达至收集系统的信息通讯系统的车辆的示意图；

图2图示了在道路上行驶的几个车辆，其中某些车辆可向中央服务器提供道路事件数据，服务器可将警告传达出至接近事件位置的其他车辆；

图3是示出了流入中央服务器并流出至车辆和其他有关方的数据的框图；

图4是组合的框图和流程图，其示出了由参与式感测车辆使用的方法、流到云系统并在云系统中进行处理的数据、以及由请求报告的车辆使用的方法；

图5是路面状况分类器的框图，该路面状况分类器可用在车辆中以确定路面摩擦状况；

图6是示出了用于基于车辆动态状况计算车辆的估算摩擦系数的方法的流程图；

图7示出了如下情景：多个参与式感测车辆向中央服务器提供道路摩擦数据，并且服务器将摩擦估值传达回车辆；

图8是示出了流入图7的中央服务器并流出至车辆和其他兴趣方的数据的框图；以及

图9是组合的框图和流程图，其示出了由参与式感测车辆使用的摩擦估算方法、流到云系统并在云系统中进行处理的数据、以及由请求道路摩擦报告的车辆使用的方法。

具体实施方式

本发明涉及通过使用车辆参与式感测系统来确定道路摩擦状况的方法和装置，以下对本发明的实施例的讨论在性质上仅仅是示例性的，决不意在限制本发明或其申请和使用。

如今许多车辆都配备有广泛的传感器和系统，这些传感器和系统可提供指示车辆正在操作的状况和车辆附近可能发生的事件的数据。通过从大量车辆收集这种数据并将其聚集用于检测趋势，可推断出相当多的信息，这些信息可传达至附近的其他车辆并对其有利。

图1是具有参与式感测系统和能够将数据传达至收集系统的信息通讯系统的车辆10的示意图。车辆10包括用于确定车辆动态状况和其他相关参数的车俩动态模块20。车辆动态模块20从至少一个传感器22接收数据。通常，会提供很多传感器22，包括车轮速度传感器，纵向、横向和垂直加速传感器，以及偏航率传感器。传感器22也可包括车轮载荷传感器和其他类型的传感器。车辆动态模块20从所有传感器22收集数据并且根据需要执行计算以提供车辆10的动态状况的完整表述——包括位置、速度、加速度和影响车辆10的力。

车辆10也包括目标检测模块30。目标检测模块30从至少一个目标检测传感器32接收数据——至少一个目标检测传感器32可以是摄像机传感器或者可以使用雷达、激光雷达或一些其它类型的目标检测技术（包括比如专用短程通信[DSRC]或超宽频[UWB]等短程通信技术）。可提供不止一个这种目标检测传感器32，包括前视图传感器、后视图传感器和侧视图传感器。目标检测模块30可通过使用来自传感器32的数据来识别车辆10附近的目标，其中，目标可包括其他车辆、路缘或其他道路界线、行人以及可能处于道路上或附近的任何目标。目标检测模块30可辨别常规尺寸的汽车、轻型卡车等以及比如运货卡车和半挂卡车的大型车辆。目标检测模块30还可确定道路上其他车辆的速度以及识别通常应移开停止的车辆（比如在高速公路上）的情形。此外，目标检测模块30可识别车道界线标记并且计算车辆10相对于道路上车道或多个车辆的位置。

车辆10还可包括系统状态模块40，系统状态模块40从车辆数据通信总线收集关于几乎任何车辆系统的状态的数据。例如，系统状态模块可确定如下状况，比如：雨刮器开启、断开或间歇性；车前灯开启或断开；节气门位置；制动压力；防抱死制动系统（ABS）的致动情况；牵引力控制系统（TCS）的致动情况；安全气囊布置；客座率；方向盘位置；环境温度；包括车辆内手机使用情况的信息娱乐系统使用情况；暖通空调（HVAC）系统的设置等。由系统状态模块40收集的数据可用于识别许多不同类型的驾驶情况和状况，这将在下文详细地讨论。

车辆10还包括车辆至车辆（V2V）通信模块50，该车辆至车辆（V2V）通信模块50通过使用专用短程通信（DSRC）或其他通信技术在通信范围内与其他相似配备的车辆相沟通。V2V通信模块50可从附近的车辆收集相当多的数据，尤其包括位置、速度和加速数据——这是“智能高速公路”或自主驾驶车辆系统所需要的。

将来自车辆动态模块20、目标检测模块30、系统状态模块40和V2V通信模块50的数据提供至数据收集模块60。数据收集模块可60与信息通讯系统70相沟通，信息通讯系统70经由移动通信塔80或其他技术与信息通讯服务中心相沟通。其他通信技术可包括但不限于DSRC或其他车辆至基础设施（V2I）通信、Wi-Fi、卫星通信等。

应理解，车辆动态模块20、目标检测模块30、系统状态模块40、V2V通信模块50和数据收集模块60由至少处理器和存储器模块组成，其中，处理器配置有设计用于执行上文所述的数据收集和计算的软件。

应进一步理解，在不背离所公开的发明的精神的状况下，可将车辆动态模块20、目标检测模块30、系统状态模块40、V2V通信模块50和数据收集模块60的特征和计算分配为与本文所描述的不同。例如，尽管在本公开中模块20-60的功能描述为具有区别，但是事实上它们都可在相同的处理器上进行编程，或者多于或者少于所示的五个有区别的模块。

图2图示了几个车辆在道路上行驶的情景100，其中，某些车辆可向中央服务器提供道路事件数据，服务器可将报告传达出至接近事件位置的其他车辆。情景100包括在2车道道路102上行驶的车辆110-150，其中，车辆110、120和130沿着一个方向行驶，而车辆140和150沿着另一个方向行驶。事件位置160由虚线框指示，其中，事件位置160可以是糟糕的坑洼、一段滑路、处于路面上的树木或其它目标、或者任何多个其他状况。车辆120和130已经穿过事件位置160，并且已经收集到指示事件或状况的数据。例如，大的坑洼可由一个车辆的车轮载荷针和另一个车辆的防范性转向操纵检测，滑路面可由牵引力控制系统和/或防抱死制动系统致动检测，以及路面上的目标可由目标检测模块30检测。

车辆120和130将关于事件位置160的数据传达至中央服务器170。中央服务器170图示为云设备，这意味着其可以是存在于全球互联网中任何地方的一个或多个服务器。中央服务器170可以是信息通讯服务的一部分，比如由信息通讯系统70和车辆10使用的服务。中央服务器170还可由任何企业实体和政府实体操作，这些企业实体和政府实体可从具有参与式感测系统的大量车辆收集和传播数据。

在道路102上有树木或其他障碍物的情况下，作为示例，车辆120和130均可检测到路面上未知位置处的大型静止目标。车辆120和130还可响应于障碍物的存在执行了制动和/或转向操纵。可以以针对图1的车辆10描述的方式将该数据传达至中央服务器170。在某些情况下，即使是单个车辆汇报的事件或状况也足以引起中央服务器170的注意从而向其他车辆发送报告。但是数量大更加有力，这样，服务器170可通过从许多车辆聚集数据更加准确地确定更多状况的存在。

在情景100中，基于车辆120和130的在道路上存在障碍的汇报，服务器170向即将碰到该状况的车辆110发送报告。车辆110可响应于其接收的信息以多种不同的方式采取行动，包括向驾驶员发送警告；如果在致动的情况下那么就终止巡航控制；通过应用制动器而使车辆110减速；采取防范性转向行动；以及重新聚焦于车辆110上的目标检测传感器以试图定位障碍物。在由车辆120和130经由中央服务器170作出其他类型的汇报——比如坑洼、滑路面、交通事故等——的情况下，车辆110也可采取相似类型的行动等（例如，更换导航路线、调整安全系统警告计时）。

服务器170也向车辆140和150发送道路102中存在障碍的报告，车辆140和150正朝着事件位置160前进。尽管车辆140和150正朝着与所汇报的障碍物的车辆120和130的方向相反的方向和车道行进，但从图2中明显地是他们也受益于该报告。服务器170在确定应将报告发送给哪些车辆时可考虑许多因素——包括所汇报的事件或状况的性质、路面（车道中央、左肩处等）上事件或状况的具体位置、道路102是否有划分以及每个方向有多少可用的行进车道等。这些因素将在下文进一步讨论。

上文描述和图2图示的三类状况（坑洼、滑路、障碍物）仅仅是示例性的，许多其他类型的安全相关道路和车辆状况可由车辆检测到并传达至中央服务器170。可由车辆120/130汇报的其他状况包括一个或多个车辆显著地超过了速度限制、车辆以显著地低于速度限制的速度行驶、降雨、降雪或浓雾、任何显著地或不寻常地使用车辆控制，比如转向、节气门或制动器、安全气囊布置等。进一步地，尽管情景100描述为关于车辆120和130将数据传达至服务器170并且车俩110、140和150从服务器170接收数据，但实际上，所有车辆110-150都可连续不断地与服务器170进行双向沟通。

如可从上文的讨论中理解的是，车辆110-150中的每一个车辆都会连续不断地从车载系统——比如车辆10的车辆动态模块20、目标检测模块30、系统状态模块40和V2V通信模块50——收集数据。然而，要让每个车辆都将其所有的原始数据传达至服务器70，这不可能是实际的。相反，在一个优选实施例中，每个参与式感测系统车辆110-150局部地执行计算以确定存在什么威胁或者危险事件或状况、哪些警告应发送汇报至服务器170。

由每个参与式感测系统车辆进行的计算可在数据收集模块60上执行，该计算可包括几个部分。例如，经由目标检测检测到的、大于某个预定尺寸的道路上的障碍物或目标可触发向服务器170立即汇报。同样，交通事故或者导致车轮载荷大于某个阈值的坑洼撞击也可触发向服务器170立即汇报。

然而，其他类型的威胁或危险状况只可通过估算多个参数来确定。作为示例，可确定特定周围车辆正在以危险的方式行驶。特定车辆i的威胁水平TL_i可计算为：

其中，w_j是与具体属性j有关的加权值，pⁱ_j是车辆i的属性（比如制动、加速或速度）。属性pⁱ_j反过来计算为：

其中，是从原始数据获得的车辆参数，原始数据来自车辆动态模块20、目标检测模块30、系统状态模块40和V2V通信模块50。

可通过使用上述计算来计算车辆i的威胁水平TL_i。在示例性实施例中，如果威胁水平超过第一阈值，那么可向服务器170发送“当心”汇报。当心汇报可指示车辆表现出中等危害行驶行为，该中等危害行驶行为在服务器170处被跟踪以看看是否会接收到其他证实汇报。如果车辆的威胁水平超过第二更高的阈值，那么可向服务器170发送“警告”汇报。警告汇报可指示车辆表现出严重危险行驶行为，该严重威胁行驶行为可触发服务器170立即向周围车辆发送出报告。

上述示例基于特定周围车辆的几种不同的属性描述了计算周围车辆的威胁水平。相似的方法可用于基于多个车辆的属性（比如多少辆车辆在高速公路上意外地制动）来计算道路上一个位置的威胁水平。参与式感测系统车辆120（作为示例）因此可基于关于其自身的单个或累计数据（比如坑洼停顿或失去牵引力）、基于聚焦于另一个车辆的计算（比如危险行驶行为）或者基于聚焦于道路上一个位置的计算（比如交通缓慢）来向服务器170发送危险状况汇报。

图3是示出了流入中央服务器170并流出至车辆和其他有关方的数据的框图200。在框210处，从许多参与式感测车辆（比如图1的车辆10和图2的车辆110-150）收集了数据。尽管单个车辆对比如交通事故等事件的汇报可足以明确地导致将报告发送至周围的其他车辆，但本文公开的方法的真正力量在于从大量车辆收集的连续不断的数据。例如，单个车辆驾驶员在高速公路上轻踩制动器不会引起其自身或对其的注意。但是如果许多车辆在高速路上的某个位置汇报制动器轻踩，那么这可能指示在发生拥堵交通状况，这可能很快会恶化为走走停停的交通情况。如果拥堵交通区域还存在减弱能见度或者潮湿/结冰道路状况的话，那么如果车辆速度仍然较高，则前面的制动行动的报告就可作为警告发给正接近该制动区域的车辆。这只是一个示例，显示来自许多车辆的数据可用于识别不可由单个车辆或少量车辆推断出的状况。

服务器170会连续不断地从数以千计或者数百万车辆接收数据。因此，必须采取方法来分析这些数据以便检测或推断多种类型的潜在危险行驶状况，并且确定应将这些危险行驶状况传达至哪些人或车辆。用于做这件事的一种技术就是将潜在危险行驶情况区分为三个类型：与其他具体车辆和其驾驶员的行为有关的潜在危险行驶情况；与出现在道路上特定固定位置的长期状况有关的潜在危险行驶情况；以及与道路上多个位置处短暂的状况有关的潜在危险行驶情况。

在框220处，从框210收集的数据识别出了与其他具体车辆和其驾驶员的行为有关的危险行驶情况。如前文所讨论的，比如图1的车辆10的车辆可收集关于其邻近的其他车辆的大量数据并且将这些数据汇报至中央服务器170——这些数据至少由目标检测模块30和V2V通信模块50收集。对来自其他车辆的速度和加速数据进行分析，这尤其可揭示潜在行驶威胁，比如威胁行驶行为、分心行驶、酒后行驶或不清醒行驶等。这些行为可以通过如下情况检测到：车辆速度远高于速度限制；不是由拥堵交通引起然而速度低于速度限制；加速度超过阈值（比如0.1g）和/或超过阈值（比如0.3g）进行大力制动事件，尤其是在加速或制动事件重复地发生时；极端追尾；超过阈值（比如10deg/sec）进行大力转向行动；在车道上偏离中心行驶和/或部分地跨国车道界线等。设想可以识别出具体危险驾驶员/车辆（或者危险类型的拥挤行为）并且对附近的其他车辆发出警告，这个想法是非常强大的。当然，由于危险驾驶员/车辆的位置是不断变化的，所以在向其他车辆发送威胁警告时可能会对预期位置作出考虑。例如，可以发送这样的危险警告“在下一个十字路口可能会遇到正从右侧驶近的危险驾驶员”。进一步地，通过聚集来自道路上的许多车辆的参与式感测数据，对危险驾驶员/车辆或危险行驶区域的识别将更加强有力。

在框22处，从框210处收集的数据识别出了与出现在道路上特定固定位置的长期状况有关的危险行驶情况。这些长期或静止的状况是重复地和定期地出现的事件类型——比如在工作日的高峰时间在特定十字路口或者特定高速公路段出现的交通阻塞。这些长期状况可能是由于如下情况引起：比如复杂的合并设计或过紧的道路曲率等不良道路设计；定时不良的交通信号；道路建设或者仅仅是由于车道不足或其他因素引起的道路或十字路口不能吞吐如此大的交通量。通过监测在几天或几个月内来自许多车辆的数据以及检测行驶速度远低于标示的速度限制的密集交通，这可轻易地在框222处识别出长期状况。相似地，也可识别出发生交通事故的数量过多的位置。在定期地检测处这些状况时，就识别出了长期危险的交通位置。可将这些长期危险的交通位置通知给驶近的车辆，并且通知给对有问题的道路负责的任何政府交通部门或道路委员会。

在框224处，从框210处收集的信息识别出了与道路上多个位置处短暂的状况有关的危险行驶情况。与在框222处识别出的长期状况不同，在框224处识别出的短暂的状况在性质上是暂时的。短暂的危险行驶状况可由如下事件引起：天气状况；交通事故；不良的道路状况；交通信号中断或其他事件，并且可包括不良能见度、潮湿或结冰路表面、道路上的坑洼或残骸、道路或路肩上的事故车辆和/或紧急车辆等。这些状况可由参与式感测系统车辆提供的许多不同类型的数据识别出——包括低车辆速度、目标检测数据（停在不该停的道路上的停止车辆或其他目标）、指示坑洼和防抱死制动的车轮载荷数据或者指示滑路表面的牵引力控制系统致动等。可基于在框224处识别出的数据来发送危险警告，比如“前方右车道上有严重的坑洼”或“前方左肩上有不能行使的车辆”。

在框230处，执行了来自框220/222/224的安全指标的数据融合。安全指标的融合将上文描述的三个类型的危险行驶状况——加上其相关的通信参数——组合为用于传播的单个数据库。该融合还识别出了三个类型的危险行驶状况之间的相互关联——比如来自框224的交通事故与框222处的长期高峰时间拥塞。

框210-230处的数据优选地具有施加至其上的一个或多个衰减函数。例如，在框210处来自单个车辆的原始事件数据可具有用于半衰期清除和最终清除的某些规则，其中，每个单个事件汇报均可带有用于预定时间量的完全加权，接着在这之后就衰减加权因素。相似地，在框220/222/224处确定的（在框230处融合的）危险条件可具有不同的衰减函数，其中，在框220处检测到的危险驾驶员状况可快速地衰减，在框22处检测到的长期状况则可非常缓慢地衰减，而在框224处检测到的短暂的状况可立即衰减。

最后，由服务器170收集的、聚集的并分析的数据产生报告，这些报告可发送至比如车辆110-150的车辆。这些报告呈两种一般的形式。

在框240处，报告以可称为“宽松的实时”形式发送。其中，“实时”可表示报告在发生事件后的几毫秒内被发送，而“宽松的实时”表示报告通常在几秒内被发送至可从该信息受益的车辆。这并不表示报告不可由服务器170实时地发送。例如，在车辆以高速行驶以及前方刚发生事故的情况下，可发送实时报告。另一方面，在受到交通状况或前方的道路状态的警告的许多情况下，可发送宽松的实时报告。在这些情况中的某些情况下，事件要发展为存在明显的危险状况，这要花些时间，因此就需要在数秒中或数分钟内从多个车辆收集信息。在其他情况下，已知存在比如坑洼或交通事故等危险状况，但是最有利的是延迟直到每个车辆与该状况的位置相隔某一距离或某一时间段，再通知这些其他车辆。最佳通知提前时间可取决于许多因素在几秒到几分钟或者更长。这些因素包括危险状况的类型和严重性、比如速度和密集度等交通状况、比如滑路或低能见度等道路条件等等。

在框242处，将具有长时期特征的报告发送至车辆或其他实体。发送至车辆的具有长时期特征的报告可包括：可用于路线规划的报告——比如建议避免走在预定行程时间长期拥塞的某个路线，或者指出某个道路经常用于竞赛以及在深夜进行的其他危险行驶的报告。发送至其他实体的具有长时期特征的报告可包括发送至道路委员会的关于危险交通状况的报告，这些危险交通状况由于如下事件导致：道路设计（复杂的合并设计、车道不足）、交通信号定时、坑洼、结冰道路和其他状况。这些报告中的某些报告（比如关于道路设计的报告）可基于在几周或几个月内对数据的分析，而其他报告（需要迫切关注并纠正的报告——比如关于结冰道路或交通信号中断）则可在一两分钟之后就发送。

来自在框240处的数据的报告优选地通过使用信息通讯系统70发送，信息通讯系统70与中央服务器170直接且连续不断地沟通。如前文所提到的，信息通讯系统70可取决于报告的性质执行许多不同的动作，包括：向驾驶员发送音频、视觉和/或触觉警告；如果在致动的情况下那么就终止巡航控制；通过应用制动器而使车辆减速；采取防范性转向行动；以及重新聚焦于目标检测传感器。在向车辆发送报告的情况下，来自在框242处的信息的报告可经由信息通讯系统70发送，而在向道路委员会、车队服务人员或其他车辆管理员发送报告的情况下，来自在框242处的信息的报告可经由电子邮件、短信或其它通信媒介发送。

图4是是组合的框图和流程图，其示出了由参与式感测车辆使用的方法、流到云系统并在云系统中进行处理的数据、以及由请求报告使用的方法。数据收集车辆270可以是前文所讨论的车辆10或110-150中的任何一个。即，收集车辆270具有参与式感测系统以便收集关于其自身、周围车辆和状况的数据，并且发送这些数据以进行集中式收集、聚集和传播。车辆270经历一个过程，开始于数据被监测的框272处。在框272处被监测的数据包括关于车辆279本身、周围车辆和状况的所有数据，如前文详细地讨论的。

在决定菱形274处，确定是否发生了事件触发。事件触发可以是单个具体事件，比如碰上了一个大的坑洼或在一段结冰道路上打滑，或者事件触发可以是累计观察事件，比如在一段不平整的道路上延长行进或被另一车辆不断地追尾。如果没有检测到事件触发，那么该过程回到框272处继续监测数据。如果检测到了事件触发，那么在框276处计算一个或多个安全指标。安全指标通过使用上文描述的技术来计算，包括方程式（1）和（2）。在框278处，将一个或多个安全指标提交至云服务器300以进行聚集。也可将其他信息与安全指标一起提交至云服务器300——在最低限度上包括收集车辆270的位置。

报告接收车辆280——也可等于前文讨论的车辆110-150——是配备有通信系统（比如信息通讯系统或V2V/V2I系统）的任何道路车辆，通信系统能够从云服务器300接收报告。如果车辆280启动接收报告，那么其就会经历如图4所示的过程。在框282处，车辆280通过使用GPS获取其地理位置。如果车辆280没有配备GPS，那么其仍然可通过其他技术获取其位置，比如与具有GPS的其他车辆和相对于其他车辆的已知位置进行V2V沟通。在框284处，车辆280基于其地理位置从云服务器300请求安全标签。如前文所讨论的，服务器300可具有来自数百万车辆的安全事件和状况信息并且覆盖大量地理区域，因此车辆280需要识别其位置以便仅获得相关安全标签（应用至车辆280前方道路或者可能的交集（intersecting）道路的安全标签）。

在框286处，向车辆280应用自定义菜单设置。这些设置包括比如：开启或断开接收报告；待接收的报告类型；是否使用音频或视觉系统来通知接收到报告的驾驶员等等。

在框288处，车辆280处理从云服务器300接收的响应标签。在决定菱形290处，车辆280基于接收的响应标签（报告）确定是否向驾驶员发送警告。是否发送警告的决定是基于如在框286处建立的设置来作出。例如，驾驶员可能已经设置了偏好，只接收紧急警告水平报告的通知，在这种情况下，例如，车辆280就不会发送关于前方中等交通缓慢的信息报告的警告。

如果没有发送警告，那么该过程就从决定菱形290回到框282以重新获取地理位置并再次请求报告。如果发送了警告，那么在框290处，基于在框282处接收的响应标签的内容，该警告就以驾驶员选择的任何形式（音频/视觉/触觉）被传送至驾驶员。接着该过程回到框282。

图4的云服务器300等于图2的中央服务器170。云服务器300的功能主要是：从许多车辆接收安全相关数据；储存并处理该数据；将安全相关报告传播至许多车辆，因为这与每个单个车辆息息相关。如前文讨论的，云服务器300可以是在单个物理位置处的服务器或服务器集群，或者服务器300可以是真正的基于云的构架，包括在多个位置处的、具有复制数据和共享数据的多个服务器。

云服务器300中的数据经历的生命周期包括：储存、聚集、过滤、衰减和最终清除。这些生命周期步骤——尤其是聚集、过滤和衰减——已在前文相对图3的框图进行了讨论。

使用上文公开的方法，安全相关交通事件和状况可通过使用来自许多参与式感测系统车辆的数据被检测到。通过聚集和过滤来自大量参与式车辆的数据，可识别出在其他情况下是不能被检测到的安全相关事件和状况。此外，凭借安全相关事件和状况基于的大量汇报，可增加所识别出的安全相关事件和状况的准确性和及时性。车辆驾驶员可受益于包含在准确、及时并相关的安全相关报告中的信息——从而避免在缺乏报告时可发生的危险情况。

参与式感测系统也可用于收集和传播除了安全相关事件可状况外的其他类型的信息。可收集的、并且也可得益于大量样品车辆的其他数据的一个示例是路面摩擦。

如前文相对于安全相关事件和状况讨论的，从大量车辆搜集数据会增加得以测量的参数的准确性。在路面摩擦的情况下，多个车辆（其中每个车辆穿过略微不同的轮胎接触道路、并且每个车辆可处于制动或加速的不同阶段）提供了丰富的数据源。在聚集和融合了来自许多车辆的路面摩擦数据之后，可将产生的道路摩擦估值传播至行驶车辆，其中，该道路摩擦估值可显示给驾驶员也可由比如牵引力控制等车辆系统自动地使用。

由车辆系统使用道路摩擦数据的几个示例很明显。自适应动力系管理系统可基于估算的路面摩擦以连续地方式更改当前的传输模式选择（例如，标准、运动、冬天）。同样，全轮驱动（AWD）车辆可基于道路摩擦数据适应性地更改车轮扭矩分布以最优化牵引力。此外，稳定性控制系统可基于道路摩擦数据调整其控制参数，并且还可警告驾驶员即将遇到弯曲状况，或者甚至是在存在在当前的摩擦状况下不能安全地度过的即将遇到的弯曲道路的情况下，自动地使车辆减缓速度。最后，当然，可提供低摩擦状况的驾驶员通知。

通常，使用参与式感测系统车辆的路面摩擦估值的工作方式与前文讨论的安全相关事件和状况检测的方式一样。即，比如图1的车辆10的单个参与式感测系统车辆包括传感器和系统以便检测当前状况、计算估算的道路摩擦和向数据收集服务传达该摩擦。许多车辆——比如图2的车辆110-150——将其摩擦数据传达至中央服务器170，中央服务170处理这些数据并且将其传播回到车辆110-150等。

除了车辆10的系统和传感器外，用于道路摩擦估算的参与式感测系统车辆还需要路面状况分类器400。图5是路面状况分类器400的框图，路面状况分类器400可以是孤立处理器或者可并入或具体化在车辆10的数据收集模块60（或其他处理器模块）中。路面状况分类器400接收输入，包括：线路402上的来自车辆传感器的数据（车辆动态等）、自线路404上的来环境传感器的数据（来自雷达或摄像机等的温度、湿度、降雨状况）、线路406上的稳定性控制系统状态数据（防抱死制动系统、牵引力控制和/或稳定性控制是否已被致动）以及线路408上的雨刮器系统状态（断开/间歇性/低/高）。路面状况分类器400使用这些输入来计算当前时间和车辆位置的道路摩擦状况值，其中，将道路摩擦状况值分类为从等级1（非常低——比如结冰或大雪、温度在零度以下、经常性防抱死制动和牵引力控制致动）至等级10（非常高——温暖、干燥道路、无摩擦减轻因素）。

同样可能的是，路面状况分类器400不仅用于计算相关状况值，还用于计算当前路面的估算摩擦系数μ。图6是示出了用于基于车辆动态状况来计算车辆的估算摩擦系数μ的方法的流程图500。在框502处，工作摩擦系数设置为等于初始摩擦系数μ₀，或者前文计算出的摩擦系数。在决定菱形504处，确定车辆是否处于轮胎性能的线性范围内，其中，轮胎滑移率几乎是纵向力的线性函数，且轮胎滑移角几乎是侧向力的线性函数。可使用车辆传感器数据（包括例如转向车辆角、侧向加速度和偏航率）和稳定性控制系统数据来确定线性范围。

如果车辆在非线性范围中操作，那么在决定菱形506处，确定车辆是否以直线行驶或者以曲线行驶。该确定也可使用比如转向车轮角、侧向加速度和偏航率等车辆传感器数据来作出。如果车辆正以直线行驶（即，没有侧向加速度），那么在框508处，仅基于纵向滑移/摩擦来计算摩擦系数μ。可在于2013年7月30日公布的名称为“纵向轮胎-道路摩擦系数的线性和非线性识别”的美国专利No.8,498,775中发现一种用于计算仅在纵向状况下的轮胎-道路摩擦的方法，该美国专利转让给本申请的受让人。

如果车辆以曲线行驶，那么在框510处，使用如下方程式来计算车辆操作的非线性范围的摩擦系数μ：

其中，a_y是车辆侧向加速度，t是当前时间，（t-ΔT）是前一个时间步骤或测量，g是重力加速度。换句话说，在具有足够的侧向加速度的非线性规程中，侧向加速度由摩擦系数限制和支配，从而允许可直接从侧向加速度计算出摩擦系数。

在框508或框510处计算出摩擦系数μ之后，就储存μ的值并且该过程结束于终点站512处。

如果车辆在线性范围中操作（如在决定菱形504处所确定的），那么在决定菱形514处，确定车辆是否以直线或曲线行驶。如果车辆以直线行驶（即，没有侧向加速度），那么在框516处，仅基于纵向滑移/摩擦来计算摩擦系数μ，如前文针对框508所讨论。

如果车辆以曲线行驶，那么在框518处，使用如下方程式来计算车辆操作的线性范围的摩擦系数μ：

其中，C_of和C_or（分别）是干燥人行道上前轮胎侧向刚度和后轮胎侧向刚度，其可根据轮胎特征预先确定，和（分别）是在连续的基础上计算出的、在任何给定表面上的估算的前轮胎侧向刚度和后轮胎侧向刚度。可在于2012年3月6日公布的名称为“车辆侧向滑移速度估算”的英国专利No.GB2461551中发现一种用于计算估算的当前状况轮胎刚度和的方法，其转让给本申请的受让人。

在框516或框518处计算出摩擦系数μ之后，就储存μ的值并且该过程结束于终点站512处。

如前文所述，图5的路面状况分类器400通过使用图6的流程图500中所示的方法使得任何参与式感测系统车辆可估算其局部路面摩擦（相关状况值和真实的摩擦系数）。通过从许多参与式感测系统车辆聚集道路摩擦数据，可以提供非常准确的道路摩擦估值，其针对于特定道路和特定位置。如若不然，要从移动通过一个地理区域的单个车辆来实时地、以需要的准确性确定这些信息是极其困难的。

图7示出了情景600：多个参与式感测车辆向中央服务器提供道路摩擦数据，并且服务器将摩擦估值传达回车辆。多个车辆610包括如前文相对于车辆10描述的参与式感测系统车辆、车辆110-150等。车辆610在许多不同的道路上行驶，并且可定位为互相相距很远的现场，以便使其经历不同的天气状况。如前文所提到的，可具有数以千计或数百万的车辆610。车辆610包括配置为连续不断地计算局部道路摩擦状态的传感器和处理器，如上文所讨论。

车辆610经由移动通信塔620或其他无线通信技术将其局部道路摩擦状况与其位置一起汇报至云服务器630。服务器630基于来自多个车辆610的数据和可从互联网640和其他源头得到的其他信息来连续不断地计算道路摩擦估值。服务器630计算针对单个现场的单个道路的道路摩擦估值，并将该摩擦估值传达出至车辆610。车辆610可基于其特定行进方向分别从前方道路的道路摩擦收益。例如，特定车辆可能在具有当前摩擦系数为0.6的道路上行驶，但正驶近一段还没有处理积雪和移除结冰的道路，该道路因此是结冰道路且具有更低的摩擦系数。

服务器630基于三个类型的数据来计算道路摩擦估值：来自车辆610的当前摩擦估值；来自车辆610的历史摩擦估值；以及来自数字地图和现场的当前天气状况的比如路面类型等其他数据。因此按照如下方程式计算具体现场中具体道路的道路摩擦估值：

其中，是来自610的当前摩擦估值，、是来自车辆610的历史摩擦估值，以及是来自在线源（比如道路类型和天气数据）的摩擦相关数据。这些术语都示出为交集（intersection），因为计算是只基于与特定道路和现场有关的数据点作出的。进一步地，f_synthesis是三个类型的数据的合成函数（synthesisfunction），其可为任何合适的函数，比如加权平均数。最后，计算出的friction可以是相关道路摩擦性值（例如，范围从1至10），或者可以是估算的摩擦系数，或者均可单独地通过使用不同的合成函数来计算。

对于有可用数据的所有道路和现场，其道路摩擦估值由服务器630计算。例如，由于天气状况不同，所以延伸数百英里的特定州际高速公路在每英里都指定有独立的摩擦值。将由服务器630计算的道路摩擦估值传达出至车辆610以供其使用，如下文将讨论。

图8是示出了流入中央服务器630并流出至车辆610和其他有关方的数据的框图700。在框710处，从许多参与式感测车辆610收集道路摩擦数据。如前文所讨论的，所公开的方法的真正力量在于从大量车辆连续不断地收集数据。在道路摩擦数据的情况下，不同的车辆将处于不同的行驶模式，即，某些车辆会笔直行驶，而其他车辆则会弯曲行驶，某些车辆会加速，而某些会减速等。因此，每个车辆将会经历不同的状况，且每个车辆的道路摩擦估值基于该不同的状况。服务器630可从许多不同的单个车辆估值计算道路摩擦，该不同的单个车辆估值反过来又基于不同的车辆动态状况，因此而获得无限样品中内涵的准确性优势。进一步地，服务器630会接收用于许多不同道路和现场中的每一个道路和现场的多个摩擦估值，从而为不同的摩擦估值技术提供基础。

在框720处，对道路摩擦数据进行过滤和初步地分析。例如，可将相关摩擦数据（从1至10的值）从来自车辆610的摩擦系数估值中分开，并且可通过道路和现场将数据区分开。在框730处，在道路摩擦数据上执行数据融合。可通过使用方程式（5）来执行框730处的数据融合，从而产生针对特定道路和现场的摩擦估值。

对于来自框730的融合的道路摩擦数据，三种不同的使用情况是明显的。在框740处，可通过使用关于特定车辆的前方道路的摩擦数据来执行车辆驾驶员通知。例如，驾驶员可收到前方有一段结冰道路上有恶化摩擦状况的通知，或者是即将遇到在当前的摩擦状况下不能安全地度过的弯曲状况的通知。在框742处，可将摩擦估值传达至车辆610并且将其用作输入至比如传输控制和稳定性控制等车辆系统的输入。尽管这种使用情况仍然涉及向车辆进行传达，但导致的行动却明显发生在驾驶员身上。在框744处，可基于随着时间的流逝形成的摩擦数据趋势来实现长时期道路摩擦特征。例如，可观察到，即使是在最近没有降雪的情况下，特定道路段也倾向于经历结冰状况。这可能是由于在有融雪流下的倾斜的路面上，这些融雪在晚上再次结冰。

在框750处，将恰当的道路摩擦状况信息传达至政府交通部门和道路委员会。这些信息可包括当前状况信息，其可用于进行实时电子标志牌通知或者用于派遣撒盐车处理路面。这些信息还可包括长期重复出现的状况，其可用于指示布置永久路标或者建议更新和改善道路几何设计。

图9是组合框图和流程图，其示出了由参与式感测车辆使用的摩擦估算方法、流到云系统并在云系统中进行处理的数据、以及由请求道路摩擦报告的车辆使用的方法。数据收集车辆800可以是前文讨论的车辆610中的任何一个。即，收集车辆800具有参与式感测系统，该参与式感测系统用于收集关于其正经历的道路摩擦状况的数据、并且发送该数据以进行集中式收集、聚集和传播。车辆800经历一个过程，开始于数据被监测的框802处。在框802处被监测的数据包括关于车辆800的所有数据，这些数据可用于进行摩擦估算，如前文相对于图5所讨论的。

在决定菱形804处，确定是否发生了事件触发。事件触发可以仅仅是某个距离的通路或者是自前一个摩擦估算以来的时间，或者可以是路面类型的变化、进入不同道路的转弯、明显的天气变化、比如ABS或TCS致动等具体低摩擦时间等等。如果没有检测到事件触发，那么该过程回到框802处继续监测数据。如果检测到了事件触发，那么在框806处计算道路摩擦估值。摩擦估值通过使用上文描述的技术来计算，包括图6的流程图500。在框808处，将道路摩擦估值提交至云服务器630以进行聚集。也可将其他信息与摩擦估值一起提交至云服务器630——在最低限度上包括收集车辆800的位置和其正行驶的道路。

报告接收车辆820是配备有通信系统（比如信息通讯系统或V2V/V2I系统）的车辆610中的任何一个，通信系统能够从云服务器630接收报告。如果车辆820启动接收报告，那么其就会经历如图9所示的过程。在框822处，车辆820通过使用GPS获取其地理位置。如果车辆820没有配备GPS，那么其仍然可通过其他技术获取其位置，比如与具有GPS的其他车辆和相对于其他车辆的已知位置进行V2V沟通。在框824处，车辆820基于其地理位置从云服务器630请求道路摩擦标签。如前文所讨论的，服务器630可具有来自数百万车辆的道路摩擦状况信息并且覆盖大量地理区域，因此车辆820需要识别其位置以便仅获得相关摩擦标签（应用至车辆820正行驶的道路和在相同地理现场的摩擦标签）。

在框826处，向车辆820应用自定义菜单设置。这些设置包括比如：开启或断开接收道路摩擦报告；是否使用音频或视觉系统来通知接收到报告的驾驶员等等。

在框828处，车辆820处理从云服务器630接收的响应标签（与车辆820相关的道路摩擦数据）。在框830处，将从服务器630接收的道路摩擦数据提供至车辆系统，比如全轮驱动控制、稳定性控制系统、ABS和TCS。这些车辆系统可以基于前方道路上的预期道路摩擦状况来优化性能。

在决定菱形832处，车辆820基于接收的响应标签（摩擦报告）确定是否向驾驶员发送警告。是否发送警告的决定是基于如在框826处建立的设置来作出。例如，驾驶员可能已经设置了偏好，只接收紧急警告水平报告的通知，在这种情况下，例如，车辆820就不会发送关于前方潮湿路面的信息报告的警告。

如果没有发送警告，那么该过程就从决定菱形832回到框822以重新获取地理位置并再次请求报告。如果发送了警告，那么在框834处，基于在框822处接收的响应标签的内容，该警告就以驾驶员选择的任何形式（音频/视觉/触觉）被传送至驾驶员。接着该过程回到框822。

云服务器630的功能主要是：从许多车辆接收摩擦相关数据汇报；储存并处理该数据；将摩擦相关报告传播至许多车辆，因为这取决于每个单个车辆的现场和其正行驶的道路与每个单个车辆息息相关。如前文讨论的，云服务器630可以是在单个物理位置处的服务器或服务器集群，或者服务器630可以是真正的基于云的构架，包括在多个位置处的、具有复制数据和共享数据的多个服务器。

云服务器630中的数据经历的生命周期包括：储存、聚集、过滤、衰减和最终清除。这些生命周期步骤——尤其是聚集、过滤和衰减——已在前文进行了讨论。

使用上文公开的方法，路面摩擦状况可通过使用来自许多参与式感测系统车辆的数据被检测到。通过聚集和过滤来自大量参与式车辆的数据，可准确地估算在许多不同现场中许多不同道路的道路摩擦状况。车辆驾驶员可受益于包含在准确、及时并相关的摩擦相关报告中的信息——从而避免在缺乏报告时可发生的危险情况。此外，可基于前方道路上预期的路面摩擦状况来定制比如ABS和TCS等车辆系统以优化性能。

上文的讨论仅仅公开和描述了本发明的示例性实施例。本领域的技术人员应轻易地从这些讨论以及所附附图和权利要求书中认识到，在不背离如以下权利要求书限定的本发明的精神和范围的条件下，可对本发明作出多种变化、更改和变更。