CN114630284A - 用于广播软件更新的方法和设备 - Google Patents

Abstract

本公开提供“用于广播软件更新的方法和设备”。一种服务器可以接收软件更新文件图像，并基于与和所述软件更新相关联的适用性要求相比ATSC广播范围内的预定义多辆车辆的特性来确定所述软件更新适用于那些车辆。此外，所述服务器可以指示ATSC发射器广播所述软件更新的文件图像，所述广播包括定义所述车辆特性的至少一个参数。所述处理器还被配置为从接收所述文件图像的所述多辆车辆中的一者或多者接收反馈，并且响应于所述反馈，指示调整广播特性以增加所述多辆车辆中对所述广播文件图像的接收。

Description

用于广播软件更新的方法和设备

技术领域

说明性实施例总体上涉及用于广播软件更新的方法和设备。

背景技术

连接的车辆具有发送和接收数据两者的能力。在许多情况下，这是经由直接一对一连接来实现的，其中车辆与远程服务器建立连接并接收或发送有用数据(地图更新、软件更新等)。例如，在使用蜂窝服务促进连接的情况下，当数据的分发者(例如，原始设备制造商(OEM))必须将数据发送到大量车辆时，这可能会导致总体上的数据成本较高。

高级电视系统委员会(ATSC)3.0技术允许使用TV频率来广播数据，然后各种车辆或其他实体可以接收作为广播的一部分的数据。这提供了一对多的机会，但是通常不涉及与单个实体的预期直接通信。即，信息是广播的一部分，然后接收实体必须接收包括在广播中的数据，并且在数据可能并非旨在用于给定的接收实体或可能不适用于所述实体时处理所述数据。

发明内容

在第一说明性实施例中，一种系统包括处理器，所述处理器被配置为接收软件更新文件图像。所述处理器还被配置为基于与和所述软件更新相关联的适用性要求相比ATSC广播范围内的预定义多辆车辆的特性来确定所述软件更新适用于那些车辆。此外，所述处理器被配置为指示ATSC发射器广播所述软件更新的文件图像，所述广播包括定义所述车辆特性的至少一个参数。所述处理器还被配置为从接收所述文件图像的所述多辆车辆中的一者或多者接收反馈，并且响应于所述反馈，指示调整广播特性以增加所述多辆车辆中对所述广播文件图像的接收。

在第二说明性实施例中，一种方法包括接收软件更新文件图像。所述方法还包括基于与和所述软件更新相关联的适用性要求相比ATSC广播范围内的预定义多辆车辆的特性来确定所述软件更新适用于那些车辆。而且，所述方法包括指示ATSC发射器广播所述软件更新的文件图像，所述广播包括定义所述车辆特性的至少一个参数。所述方法另外包括从接收所述文件图像的所述多辆车辆中的一者或多者接收反馈，并且响应于所述反馈，指示调整广播特性以增加所述多辆车辆中对所述广播文件图像的接收。

在第三说明性实施例中，一种非暂时性存储介质存储指令，所述指令在由处理器执行时使所述处理器执行一种方法，所述方法包括：接收软件更新文件图像。所述方法还包括基于与和所述软件更新相关联的适用性要求相比ATSC广播范围内的预定义多辆车辆的特性来确定所述软件更新适用于那些车辆。此外，所述方法包括指示ATSC发射器广播所述软件更新的文件图像，所述广播包括定义所述车辆特性的至少一个参数。所述方法还包括从接收所述文件图像的所述多辆车辆中的一者或多者接收反馈，并且响应于所述反馈，指示调整广播特性以增加所述多辆车辆中对所述广播文件图像的接收。

附图说明

图1示出了与云服务器和多辆车辆进行通信的说明性ATSC系统；

图2示出了用于检测和报告异常的说明性过程；

图3示出了用于报告的异常处理的说明性过程；

图4示出了用于发送ATSC广播的说明性过程；

图5A和图5B示出了用于准备关于各种说明性异常的广播的说明性过程；

图6示出了用于接收的广播处理的过程的说明性示例；

图7示出了服务于多个区的自主车辆701的说明性示例；

图8示出了使用广播的自主车辆部署的说明性过程；

图9示出了用于部署处理的说明性过程；

图10示出了用于改换用途部署的说明性过程；

图11示出了用于使用广播的蜂窝提供商供应的说明性过程；

图12示出了用于蜂窝提供商供应处理的说明性过程；

图13A和图13B示出了用于使用广播和响应进行数据收集的说明性过程；

图14示出了用于选择性交通路线选择的说明性过程；

图15示出了用于选择性交通路线选择处理的说明性过程；

图16示出了用于调整自适应选择性交通路线选择模型的说明性过程；

图17示出了用于处理来自选择性路线选择广播的地图数据的说明性过程；

图18A和图18B示出了用于选择性警报处理的说明性过程；

图19示出了用于周期性充电数据更新的说明性过程；

图20示出了用于处理充电警报的说明性过程；

图21示出了用于软件更新广播的说明性过程；

图22示出了用于更新广播处理的说明性过程；以及

图23示出了用于调节软件更新广播的说明性过程。

具体实施方式

根据需要，本文公开了详细实施例；但是应理解，所公开的实施例仅仅是说明性的并且可以体现为各种和替代性形式。附图不一定按比例绘制；一些特征可能会被放大或最小化以示出特定部件的细节。因此，本文所公开的特定结构细节和功能细节不应被解释为是限制性的，而是仅仅解释为教导本领域技术人员以不同方式应用所要求保护的主题的代表性基础。

除了使示例性过程由位于车辆中的车辆计算系统执行之外，在某些实施例中，所述示例性过程还可由与车辆计算系统进行通信的计算系统来执行。这种系统可包括但不限于无线装置(例如但不限于移动电话)或通过无线装置连接的远程计算系统(例如但不限于服务器)。此类系统可以统称为车辆相关计算系统(VACS)。在某些实施例中，VACS的特定部件可以根据系统的特定实现方式来执行过程的特定部分。作为示例而非限制，如果过程具有与配对的无线装置发送或接收信息的步骤，则很可能无线装置未执行所述过程的所述部分，因为无线装置不会与自己“发送并且接收”信息。本领域普通技术人员将理解何时将特定计算系统应用于给定解决方案是不合适的。

在本文讨论的每个说明性实施例中，示出可由计算系统执行的过程的示例性的非限制性示例。关于每个过程，执行所述过程的计算系统可以为了执行所述过程的有限目的而变为被配置为用于执行所述过程的专用处理器。所有过程不需要完整地执行，并且被理解为是可执行以实现本发明的要素的过程类型的示例。可根据需要在示例性过程中添加或移除附加步骤。

关于在示出说明性过程流程的附图中描述的说明性实施例，应注意，出于执行由这些附图示出的一些或所有示例性方法的目的，可暂时启用通用处理器作为专用处理器。当执行提供执行所述方法的一些或所有步骤的指令的代码时，处理器可暂时改换用途作为专用处理器，直到所述方法完成为止。在另一个示例中，在适当的程度上，根据经预配置的处理器起作用的固件可以致使处理器充当为执行所述方法或其某一合理变型而提供的专用处理器。

结合ATSC电视台使用服务器，广播实体(例如，OEM)可以以一对多的方式准备和发送被设计为到达电视台广播范围内的多辆车辆的目标数据。即，代替经由与给定车辆的直接连接将数据单独地输送到每辆车辆的是，实体可以准备对指定的一组车辆有用的数据并且发送数据和指令以广播到ATSC电视台。然后，电视台可以发送ATSC广播，并且大量车辆可以同时接收数据。

由于数据可能仅适用于接收车辆的子集或与其相关，因此服务器还可以准备指示数据所适用的车辆的信息。例如，如果数据与道路异常有关，则服务器可以指定异常周围的坐标范围、或异常适用时的当日时间等。如果数据与软件更新有关，则服务器可以指定软件版本，或者甚至一组特定车辆识别号码(VIN)或电子序列号(ESN)元素。

当车辆接收到广播时，它可以检查与广播相关联的参数数据以确定包含在广播中的数据的适用性。如果参数数据指示车辆可以使用广播数据，则车辆可以处理广播或将其发送到适当的内部系统(更新过程、导航系统等)以进行处理。

通过说明性实施例等，可以实现向大量车辆传送数据以及加速经由广播一次向所有车辆输送的显著成本节省。广播也可以持续，使得在广播进行的同时进入广播区域的车辆仍然可以接收广播并受益于广播。

图1示出了与云111服务器113和多辆车辆121、131、141进行通信的说明性ATSC电视系统101。在该示例中，ATSC系统101是能够将ATSC广播发送到已知广播区域的ATSC电视台。电视台包括用于接收更新的某种形式的过程105，所述过程通常连接到广域网(例如，互联网)，但是也可以利用蜂窝或其他连接。通过过程105，电视台101从云111服务器113接收指令，并且在配备有处理器103的电视台计算机中处理那些指令以设计广播。一旦广播准备好，处理器103就可以指示ATSC发射器107将广播发出到接收区域内的任何车辆121、131。

在所示的示例中，车辆121、131、141中的任一者可以经由蜂窝连接或其他连接向云111服务器113报告异常。在一些情况下，车辆(诸如车辆141)可以包括传感器套件147。这些套件在自主车辆141中可能更常见，所述车辆可以包括未提供给其他车辆121、131的各种检测系统。

在其他情况下，车辆可以是人类驾驶的车辆121、131，并且可以包括处理器123、ATSC收发器125、导航过程或处理器127和其他车载过程或处理器、以及远程信息处理控制单元(TCU)129。如果并且当车辆121检测到异常(诸如车载软件错误)，则车辆121可以使用TCU 129和蜂窝连接或其他直接连接(例如，Wi-Fi)向服务器113报告异常。图1示出了车辆141通过TCU 149、通过蜂窝塔将蜂窝数据传送到云服务器113。该车辆141可以报告通过传感器147检测到的异常、交通、软件错误等。任何车辆都可能将异常传送到云111。

车辆131具有与车辆121类似的部件，但是为了展示来自电视台101的ATSC发射器107的广播是一对多的目的而被示出为简易车辆131。示例中所示的天线是ATSC接收器135。

车辆141是自主车辆或具有增强型传感器147的其他车辆，并且还可以检测各种基于道路的异常(例如，坑洞)。其他车辆121、131也可以检测交通和道路异常(例如，交通、施工)，但是可能没有充分配备来检测如坑洞等事物。当车辆141(例如，基于应共享的一组预定义的检测到的状况)检测到应与其他车辆121、131共享的路况时，车辆141(其也具有TCU149和中央处理器143)可以使用TCU 149经由蜂窝连接向服务器113报告所述状况。该车辆141还具有用于从ATSC发射器107等接收ATSC广播的ATSC接收器145。

服务器113接收任何报告的异常并确定哪些车辆可能受到异常影响，和/或如果异常是可以修复的事物(例如，软件更新)，则确定如何修复异常。然后，服务器113对输送指令以及车辆121、131、141可使用的用以确定所接收的广播是否适用的任何参数进行打包，然后服务器113将数据包输送到电视台101。然后，电视台101可以将数据包发送到各种车辆121、131、141，所述车辆可以单独地确定数据的适用性。

由于数据可以包括对软件的更新，因此例如甚至报告车辆121也可以受益于数据。在其他情况下，接收车辆141可以接收数据并基于接收到数据/解决方案的事实来确认成功报告了道路或交通异常。

图2示出了用于检测和报告异常的说明性过程。在该示例中，在201处，在车辆141处理器143上执行的过程检测可报告事件。这可以包括例如道路异常、交通异常、道路变化(新道路、道路封闭等)、软件故障或其他预定义的可报告事件。

如果存在与异常相关联的任何参数，则车辆141可以在203处设置参数。例如，道路异常可以具有与其相关联的地理坐标以及航向或当日时间。软件异常可以具有如与其相关联的软件类型或版本等参数，以及与利用或包括所述软件的特定车辆系统相对应的参数。然后，在205处，车辆141将异常和参数发送到服务器113。服务器113还可以向OEM报告，所述OEM然后可以准备软件修复以解决所报告的问题。如果软件修复尚未挂起，则OEM可能需要一些时间来解决并发布所报告问题的解决方案。

因为参数的发送可能导致发送ATSC更新，所以在该示例中，车辆141在207处确定是否已经经由ATSC接收器145接收到ATSC更新。这可以是对道路异常的报告或对修复所识别问题的软件更新。由于更新或报告可能需要一段时间来处理，因此车辆141可以在209处等待并继续检查ATSC更新。或者，一旦ATSC更新可用，车辆141就可以仅接收所述ATSC更新，而无需重复检查。

如果经过了规定时间段，则可能发生了阻止ATSC更新的错误或软件修复尚不可用。因此，在该示例中，车辆141在211处直接与更新服务器113进行通信。如果服务器113在213处通知车辆141已经处理了更新，则车辆141可以在217处删除用于报告异常的本地数据。当车辆141接收到其基于所发送的数据而预期的ATSC更新时，可能发生同一删除。在其他示例中，当车辆报告异常时，它可以仅仅删除数据，并且服务器将在到期时间解决异常。在此类示例中，车辆将不需要直接从服务器接收更新和/或向服务器核对。

如果更新存在问题，或者服务器113再次需要数据，则车辆141可以在215处重新发送数据并重复所述过程。由于服务器113可能需要时间来处理更新并且可能需要更多时间来经由电视台101发送更新，因此在该示例中，车辆141断开连接而不必接收对更新处理的初始确认，因为一旦更新被处理，车辆141就仍然可以接收ATSC广播作为确认。

图3示出了由例如服务器113执行的用于报告的异常处理的说明性过程。在该示例中，服务器113在301处接收异常的报告。因为一辆以上的车辆121、131、141可以报告同一异常，特别是关于道路的异常和交通异常，所以服务器113在303处确定是否已经处理了(即，先前接收到)异常。如果已经处理了异常，则服务器113在309处保存报告车辆的报告，以防车辆141与服务器通信以确定报告是否被处理。

如果尚未处理报告，则服务器113将在305处处理报告并设置与更新/广播所适用的车辆相对应的参数。这还可以包括获得用于分发的软件更新、识别用于软件更新的车辆参数、定义围绕道路异常的地理围栏等。服务器113还可以包括广播的持续时间和/或广播的适用当日时间和周中此日，然后在307处，服务器113将指令和数据发送到ATSC电视台101。

图4示出了可由例如电视台101执行的用于发送ATSC广播的说明性过程。在该示例中，在401处，电视台101从服务器113接收广播数据和任何适用的参数。由于数据可能需要被转换以便广播，诸如包括广播报头文件，因此电视台101可以在303处设置要包括在报头文件中的任何接收参数。这可以包括例如地理参数、航向参数或车辆VIN或ESN参数。

然后，在405处，电视台发送数据作为ATSC广播的一部分。如果广播具有在407处尚未到期的定义时间段，则电视台101可以在409处等待预定义时间段，然后重新发送广播。因为可能要求电视台101广播大量数据集，所以电视台101可能需要广播之间存在等待时间段，所述等待时间段也可以关于广播类型进行定义-例如，紧急广播将持续进行直到紧急情况消退，而除非没有其他广播挂起，否则只能每X分钟广播一次坑洞通知。一旦预定义时间段期满，或者一旦异常消退，电视台101就可以在411处从广播队列中移除广播。

图5A和图5B示出了可由例如服务器113执行的用于准备关于各种说明性异常的广播的说明性过程。当服务器113接收到给定异常时，服务器113可以将异常参数化以定义哪些车辆121、131、141应实际处理由电视台101发送的数据广播。虽然在图5A和图5B中分别示出了说明性道路异常和软件异常，但是应当理解，可以以类似方式适当地处理可以被检测到、被定义用于报告并且向多辆车辆报告的任何种类的异常。

在图5A中，服务器113在501处接收对道路异常的报告。这可以包括例如道路危险(坑洞)、新道路、道路封闭、施工区、危险状况、天气状况等。在该示例中，服务器113在503处确定适用的地理围栏半径(或周长)。例如，坑洞可能具有一英里的受限周长和与其相关联的方向性(考虑到对大多数交通的影响可能有限)，而大量施工绕行可能具有与其相关联的5至10英里的半径，从而使驾驶员在到达任何堵塞区之前有时间改变路线。

然后，在505处，服务器113设置与异常相关联的任何地理参数。这可以包括例如方向性、用于处理的边界以及任何其他相关信息。例如，对于坑洞，不仅半径可以被设置为.5英里，而且服务器113还可以设置特定的道路参数，使得仅在距坑洞半英里以内、沿指定方向且在给定道路上行驶的车辆将处理与坑洞有关的数据。

服务器113还可以在507处设置类型标志，从而定义异常类型(然后将包括在广播中)。某些车辆所有者可能想要忽略某些报告以避开过度泛滥，因此，例如，如果异常是天气类型且下雨，则一些车辆所有者可能会忽略这种异常(不关心他们是否在雨中驾驶)，而其他车辆所有者可能不会忽略。

然后，服务器113在309处准备数据包，所述数据包可以包括异常的识别以及任何处理参数，以及用于避开异常的任何建议的动作。这可以是详细的计划，或者可以像例如“避免在Telegraph路11英里路至12英里路之间的最左侧车道行驶，以避开坑洞”那样简单。当异常较大时，导航系统可能能够绕开它，但是当异常高度局部化时，GPS坐标可能不足以确定相对于异常的车辆位置，并且因此服务器可以提供附加指令以避开局部异常。

在图5B中，服务器113在511处接收对软件异常的报告。这可以包括例如软件小故障、显示器中的错误或其他报告的软件错误。错误报告还可以包括软件版本和/或软件所适用的车辆系统(例如，用于加热的车辆座椅模块的加热控制软件的版本1.02中的软件错误)。

然后，服务器113在513处确定是否存在可用的补丁或更新。即使没有补丁，服务器113也可以经由电子邮件或其他方法向已安装了受影响的软件版本的车辆所有者报告错误，服务器113也可以在513处确定所述车辆所有者。然后，服务器113可以在515处设置车辆参数，诸如车辆具有特定模块和/或软件版本。这还可以包括指示一组车辆的VIN或ESN参数，前提是更新所适用的车辆可通过此类识别利用来识别。

在517处，服务器113可以包括可用于获得软件更新或修补软件的软件修复或其他数据。例如，如果软件不能经由空中更新来修复，则所述修复可以包括安排对经销商的访问的指令(可以输送给车辆乘员的指令)。最后，在519处，服务器113准备用于输送的软件包以及广播指令，然后将数据发送到电视台101。

图6示出了可由例如车辆121执行的用于接收的广播处理的过程的说明性示例。在该示例中，车辆121在601处接收ATSC广播。由于车辆121在其在广播区域内的同时将接收所有ATSC广播，因此车辆121可能需要具有用于处理广播以避免在处理不适用的广播时浪费处理循环和能量的过程。

如果在603处广播包括地理参数，则车辆121将数据视为交通异常事故。如果在605处广播包括车辆识别参数或系统或软件参数，则车辆121将数据视为软件问题通知。其他参数也可以用于将其他类型的广播识别为合适的。

如果数据是交通异常，则车辆121在607处确定车辆121的当前GPS坐标是否与针对交通广播定义的坐标集匹配。在其他情况下，车辆航向或道路可以用于匹配或确定任何适用的坐标是否沿着车辆路线。如果存在当前匹配(即，广播立即应用于车辆)，则车辆121在615处将更新的数据发送到车辆导航系统。

如果不存在当前匹配，则这不能保证数据将永远不会应用于所述特定车辆，因为数据与邻近路况有关并且车辆正在行驶。因此，车辆121确定当前路线(或航向和道路)是否将使车辆121在相关坐标集内。如果在609处存在路线匹配，则车辆121可以在613处对数据进行排队以在当前GPS数据匹配时使用，或者否则车辆121可以在611处忽略数据。

如果数据与软件更新有关，则车辆121在617处确定车辆121是否包括相关的识别软件版本或模块。如果否，则车辆121在619处忽略数据，但是如果存在匹配，则车辆121在621处将数据发送到软件更新过程以在适当时进行处理。如果没有软件，则车辆121可以将数据发送到通知过程例如以通知驾驶员需要修复，但是所述数据不能通过空中获得。

除了前述说明性示例之外，还有许多其他功能可以基于ATSC广播消息传递的一对多模型来实现。虽然该模型面临某些挑战，但是因为不存在与接收实体的直接交互通信(尽管所述实体可以稍后报告)，所以所述模型也允许有一定的独特机会来廉价地大规模传输信息、收集数据和自适应地管理直接一对一通信可能会过度消耗带宽和/或成本过高的某些情况。

例如，自主车辆的出现将在道路上提供数千辆无人驾驶车辆。图7示出了在蜂窝网络709、711和713(例如，由于自然现象)失效时服务于多个区703、705、707的自主车辆701的说明性示例。因为自主车辆701将从云获得信息和指令，并且因为所述传输通常将通过蜂窝通信介质进行，所以这些网络709、711和713的丢失将意味着完全或部分失去对车辆701的控制。

同时，由于这些是无人驾驶车辆，因此在这种情况下它们对于运输目的都非常有用，并且至少在它们没有乘客时，因为没有人在车上，所以它们可以承受更大的风险机会。因此，当有用的车辆701将是道路上最有用的车辆701中的一些时，蜂窝通信的丢失可能会造成与那些车辆701的车队的通信的丢失。并且在大多数或所有车辆701都是自主车辆的情况下，这可能意味着道路上几乎所有或所有车辆701的整个车队接近丢失。

可以使用ATSC广播来辅助这种情况，因为可以经由来自ATSC发射器715的直接广播指示这些车辆701驾驶到特定的需要目的地。这通常具有部署全体车辆701的效果，由于在这种场景下蜂窝网络关闭，因此车辆701可能缺乏报告到达或接收指令的能力，但同样的情况是，就在蜂窝中断之前，许多车辆701的位置将基于预期目的地或当前空闲状态位置而已知。

然后，可以将受影响区域划分为区701、703、705。可以为每个区中的那些车辆701分配特定任务。此外，可以基于当前GPS坐标来指定区，所述当前GPS坐标可仍然是车辆已知的。在任一情况下，或者使用这两个概念，例如，靠近疏散地点的车辆701的子集可以被分配行驶到疏散地点以疏散人员的任务。虽然这可能导致额外的车辆701被发送到给定地点，但是出于足够的谨慎并且预期所有车辆701可能不会到达，因此为疏散提供过多车辆701的结果肯定比那些车辆701因没有指令而闲置更好。

当车辆701通过给定地点时，消息传递(例如，经由无线电从人类进行消息传递)可以被发回以被馈送到在政府服务器721或其他合适的协调服务器上执行的协调过程中，所述协调过程可以使前往或处于现已疏散地点的所有车辆701改换用途，并且将那些车辆701发送到一个或多个地点。通过这种方式，即使与自主车辆701的直接通信当前不可用，那些车辆701也可以继续辅助疏散和运输。由于车辆701可能能够基于车载计算和车辆对车辆(V2V)和车辆对基础设施(V2I)通信或者这种通信的某个子集(如果一些不可用)来驾驶并导航到目的地，因此缺乏蜂窝通信并不会完全阻碍自主车辆任务分配和行驶。

图8示出了用于使用广播的自主车辆部署的说明性过程。在该说明性示例中，协调过程可由例如城市服务器721执行。在801处，服务器721检测或接收对服务器721可负责的区域中的一些或全部的蜂窝中断的指示。除非在紧急情况下，否则服务器721通常可能不具有对任务车辆701的控制或权限，但是如果蜂窝网络失效，和/或如果车辆701接收到紧急广播，则车辆701可以进入允许来自城市服务器721的命令以指示车辆的目的地的模式。

如果网络中断是由于例如暂时中断引起的，或者如果紧急信号是测试，则接受此类命令的车辆701将没有问题，因为将不会接收到命令。此外，在状态切换以接受此类命令之前，车辆701可以等待直到当前路线完成，或者直到没有乘客剩余，因此可以另外保证当前占用的车辆701在已经用作运输工具的同时不会被重新分配任务。

如果服务器721是OEM服务器或已经具有控制权限的服务器，则可以基于对哪些车辆701已经在使用中或被分派了接载任务的了解来完成对哪些车辆701要重新分配任务的协调。如果需要，城市服务器721也可以访问这种馈送，并且因此可以进一步确保没有正在使用的车辆701被改换用途直到合适的时间(例如，没有乘客存在)。

然后，服务器721可以基于例如已知的疏散区域来制定部署策略。这可以包括任何种类的合理优先级排序，其通常是规划人员针对疏散场景的权限。在803处制定部署可以包括例如定义围绕已知的疏散点的地理围栏，以确保合适数量的已知车辆701将接收给定的命令以进行辅助。在一些情况下，这可以基于总车辆位置来完成(例如，将地理围栏设置在基于包括最靠近需要40辆车辆的位置的50辆车辆701的周边)，并且在其他情况下，如果不知道或不能知道所有车辆701的确切位置，则这可以是基于典型车辆密度的假设(例如，通常在城市中每个街区有10辆车辆701，则将围栏设置在以疏散点为中心的2×2街区网格处，并且假设大约40辆车辆701将是可用的)。

围栏的制定是可以随着各个点被疏散而可重复的动态过程。某些车辆701可以被调度到其他点，并且这种任务分配甚至可以来自不在那些点的围栏内的区或地理围栏。例如，可以指示车辆701的某个子集开始行驶到原本可能缺少车辆的另一点。

尽管围栏内的所有车辆701都基于在围栏内而接收到同一消息，但是这种重新分配任务可以通过相对简单的过程来实现。例如，具有某些特性(例如，高容量、高燃料续航里程、越野能力)的车辆701可以被发送到偏远地区，并且将基于车辆701的特性以及在地理围栏内的地理特性而接收该不同命令。

在另一个示例中，在疏散点A处仅需要100辆车辆701的区域中可能预计存在或已知存在200辆车辆701，并且存在在疏散点B和C处各自仅具有20辆车辆701但需要30辆车辆701的一些外围区域。

一种选项可以是将所有200辆车辆701发送到疏散点A，然后在点A处完成疏散之后使那些未使用的车辆701改换用途。然而，这将涉及将远多于需要的车辆701发送到疏散点A。仅作为示例，替代解决方案将是向200辆车辆发送指令集，其中所述指令包括两个替代位置B和C以及用于使给定车辆701运行随机数发生器的指令。

假设将150辆车辆701发送到较大型疏散点A(在一些车辆701无法发送的情况下)并将各25辆车辆发送到外围点B和C被认为是可接受的。这将使每个点需要的车辆701的150％前往相应位置。

在该示例中，每辆车辆701可以在1至4之间随机化。如果车辆701产生1或2，则它将遵循主要指令到达大型疏散点A，如果车辆701产生3，则它将前往点B，而如果它产生4，则它将前往点C。这通常将导致前往每个点的车辆701大致逼近正确数量。随机化可能会导致一些变化(例如，154辆车辆701到A，52辆车辆701到B，44辆车辆701到C)，但是在有较大数量的车辆701时，这将拉平，并且每个位置首先已经被发送了需求的150％，因此一些变化仍然应具有前往给定位置的正确数量的最少车辆701。

即使不能实现对车辆701的直接控制，这也允许有一定的控制粒度。此外，如果大型区(200辆车辆区)将车辆701分布在各处，则更靠近B或更靠近C的车辆701可以免于实现进一步的结果。这将通过例如向车辆701指示如下情况来实现：如果它基于随机化产生C作为目的地，但是在“无C选项”围栏内，则它将重新随机化或反而被具体地分配给A或B。B可能是更好的选项，因为B或C的误报可能性将是相同的(25％)，因此每个区域中相等百分比的车辆701将产生误报，但在对其他车辆没有任何直接控制或了解的情况下有效地交换它们的目的地。

可以使用加权或其他约束来改变随机性，使得大型区中也最靠近B的车辆701具有最多机会随机化到B，并且对于C也是如此。ATSC指令甚至不需要知道车辆701实际所处的位置就能实现这一点，它可以仅基于当前GPS坐标分配加权，因此给定车辆701可以确定对所述车辆701的正确加权。

当精确地知道关于车辆位置的更多信息时，可以实现更准确的控制，但是在某些天气相关情况下，或者甚至在城市峡谷中，可能难以精确地知道每辆车辆701在失去联系之前所处的位置，并且因此，仅知道200辆车辆701在A区中可能有足够多信息来使用本文提供的一些技术等。

如果每辆车辆701的确切位置是已知的，则服务器721可以仅仅重新绘制区以将正确数量的车辆701放置在服务于B和C的区中(例如，扩展围绕B和C的区以涵盖那些特定车辆)。

在制定计划部署(包括诸如前述变化等任何变化)之后，服务器721可以指示ATSC发射器715(或服务于发射器的电视台)广播用于车辆701的指令。使用疏散点A、B和C以及对应的A、B和C区的前述示例，用于所有区的指令可以包括在发射中。由于可以基于给定车辆701的GPS坐标来寻址指令，因此每辆车辆701将接收所有指令并仅仅丢弃不相关指令(或将它们保存在队列中以在当前指令集完成之后考虑)。选择遵循哪些指令可以基于诸如GPS坐标、车辆701特性(容量、燃料续航里程、越野能力、车身颜色等)或由服务器721绑定到给定的一组指令的其他合理参数等参数。如果车辆的状态集(先前参数等)与分配给一组指令的那些相匹配，则那些是车辆701将执行的指令。

ATSC发射可以周期性地继续，并且当地点(例如，A)在807处完成疏散时，服务器721可以基于不需要服务于A或已经完成疏散人员下车的所有现在可用车辆701来制定新的部署。反馈可能需要来自地点A处的某个人或通过另一个指示器，但是服务器721可以并入有该反馈并发送新的指令集，所述新的指令集可以包括根据需要重新设计区。新指令所适用的任何车辆701(其当前未在疏散人员(即，车上有乘客))可以基于如上参数匹配来执行新指令。即使可能失去与车队的直接联系，这也可以提供车队管理的措施。当在809处指示完成所有疏散时，服务器721可以制定并发送在失去联系的持续时间内将车辆701发送到合适的覆盖区的一组指令。

某些覆盖位置(诸如指定的有盖停车场)可以提供与隐蔽在那里的车辆701的局部直接通信，并且如果在蜂窝网络709、711、713重新联机之前再次需要那些车辆701，则这可以允许服务器721重新评估区域内的资源分配。由于局部通信提供直接通信，因此服务器721可以最初(当重新部署车辆701时)向每辆车辆701发送特定指令集，然后可以恢复ATSC发射，直到车辆701再次被发回覆盖区。

多个ATSC发射器也可能覆盖不同的区域，并且与给定ATSC发射器的已知覆盖区域相比，可以基于与指令相关联的地理周边的相关性来选择经由哪些发射器发射哪些指令。这可能导致一些发射重叠，但是车辆701将最终决定要遵循哪些指令，因此接收重复指令不应面临重大挑战。这甚至可以通过以下各项而得到更大缓解：使具有已分配任务的任何车辆701忽略其他指令，直到该任务完成或接收到具有例如超驰参数的指令，指示车辆701应放弃当前任务并执行超驰指令。

图9示出了可由例如车辆701执行的用于部署处理的说明性过程。如前所述，给定车辆701可以在901处接收ATSC广播，所述ATSC广播包括比预期用于给定车辆701的那些指令更多的指令。服务器721可能已经将参数集(一个或多个)分配给每个指令集，并且车辆701可以考虑与其自身的状态集(例如，位置、特性、甚至燃料或其他动态特性)相比的各种参数集来决定基于匹配参数执行哪些指令。

指令甚至可以具有基于例如剩余可行驶距离的参数。使用点A、B、C示例，如果车辆701在A区中并且被告知行驶到点C，但是剩余的可行驶距离不足，则车辆701可以忽略所述指令并重新选择作为除C之外的最接近匹配(B或A)的指令。

服务器721可能不会将诸如可行驶距离等参数绑定到指令集的初始选项，因为服务器721将不知道给定车辆701距疏散点有多远。但是一旦车辆701选择了所述集合，车辆701就可以通过知道疏散点、其当前位置和最终目的地来做出所述确定。在另一个选项中，选择参数可以通过向车辆701提供疏散和目的地坐标(其中疏散人员下车)来适应这一点，并且车辆701将具有指令来使用该坐标对以在选择所述指令集之前确定车辆701是否可以完成这种行程。

在903处，车辆701可以丢弃当前未执行的指令或将其排队。如果当前接受的指令包括要由车辆701在905处执行的一条或多条路线，则车辆701将在907处执行那些路线。例如，一些车辆701可以接收停留在原地的指令，从而将它们作为出现的任何本地需求的资源，而不会通过将它们发送太远到偏远的(从该车辆的角度来看)疏散点而耗尽它们的燃料供应。

图10示出了用于使部署改换用途的说明性过程。如前所述，在1001处，当给定疏散点的疏散完成时，可以使用某种形式的反馈来通知服务器721完成疏散。这可以包括例如两个人之间的无线电通信，其中一个人将数据输入到服务器中，与服务器721的无线电通信指示疏散完成(例如，语音识别、已编码传输等)，或者甚至如果一辆或多辆车辆701行驶到仍然存在蜂窝通信的区并且可以再次实现与车辆701的直接通信，则那些车辆701报告成功。

此时，服务器721可能需要制定新的疏散计划以适应剩余的疏散点。由于服务器721可能已经将多辆额外的车辆721发送到疏散位置，因此服务器721可以向给定区中的车辆701发送简短的停止指令，这可以使那些车辆701在原地等待，而不是使它们都继续行进到疏散点。是否这样做可以基于例如基于关于这些车辆701的当前位置的假设或对它们都在已知的疏散区位置处开始的了解是否更容易重新部署这些车辆来确定。

在这种情况下，车辆701可以被编程为在执行当前指令的同时忽略新指令(因为车辆701不知道疏散已完成)。在这种情况下，所述指令可以是超驰指令，所述超驰指令由所有车辆接收，由给定区中的车辆701接受，然后基于超驰参数来执行(而不是排队或丢弃)，这将不会发生在不存在所述超驰参数的情况下，其中所述指令原本已经被排队或丢弃。

当车辆701等待(如果需要)时，服务器721在1005处识别供车辆701要行驶到的新的或其他疏散区或点，然后在803处(类似于803)制定新的疏散计划并在805处传输该计划。

图11示出了用于使用广播的蜂窝提供商供应的说明性过程。该过程可以由服务器721执行，但是在这种情况下，所述过程将更通常由OEM服务器721执行而不是由城市管理服务器执行。然而，为了说明起见，谁提供服务器并不重要，而重要的仅仅是与ATSC发射器715(或发射器的控制器)通信的服务器721可以指示本文讨论的各种指令和请求的发射。

在该示例中，服务器721将响应于在一个或多个蜂窝网络中检测到的故障而分发蜂窝配置文件重新编程指令。因此，例如，在禁用一个或多个蜂窝网络的天气相关事故的前述示例中，在使用ATSC技术向车辆701发送指令之前，服务器721(或另一服务器)可以尝试执行诸如该示例等过程，以便在可能的情况下维持对车辆701的直接控制。虽然在发送ATSC疏散指令之前不是必需的步骤，但是对车辆701的直接控制可以使得更容易为那些车辆701选择路线，因此如果在服务器721例如制定疏散计划的同时可以尝试重新配置丢失的蜂窝连接的简单尝试，则在一些情况下可能值得发送。

在蜂窝网络中，可能发生某些故障，其包括例如从网络A路由到后端服务器、需要使用另一网络B的网络A的完全故障等。先前已经认识到这个问题，并且解决这个问题的提议通常涉及使用A上的缩小信号来接收关于B的新信息，从而允许车辆701在A上的信号变得不可用时进行转变。这种解决方案的问题在于，如果网络A突然且意外地丢失(例如，信号塔被撞倒或禁用)，则没有计划，因此车辆701完全没有连接。

因为车辆701缺乏有效连接，所以车辆701无法请求重新编程或任何其他通信，或者甚至无法通知网络它失去了连接(例如，而非仅仅停放和断电)。因此，例如，在意外断开连接和网络禁用的情况下，基于缩小的信号或甚至即将到来的已知信号丢失来提前为断开连接计划的先前系统将不会提供太多有用的支持。

当服务器721在1101处检测到网络中断或被通知网络中断时，在该示例中，服务器721还可以确定或被通知发生了哪种类型的错误。例如，如果错误是由于网络禁用引起的，或者是由于无线电网络与后端之间的路由故障引起的，则可以通知服务器721。在前一个示例中，服务器721将确定新的运营商，并且在后一个示例中，服务器721将确定同一网络的新接入点名称(APN)，这允许在无线电网络与后端之间的先前连接故障的情况下进行不同的路由。这些是在1103处确定的，这可以包括所有类型的车辆以及AV。

例如，为了不使新网络过载，服务器721可以确定丢失网络的多个替代方案，使得所有网络流量不会立即转移到新网络。在这种情况下，如前所述，服务器721将在1105处基于参数来划分新的网络配置文件。这可以基于例如具有更好或更差的不同网络的覆盖区域(例如，网络D跨越网络E和网络F的覆盖区域，网络D失效，服务器721可以指示由E提供更好服务的区域中的车辆701使用E，并且对于F也是一样)。所述参数还可以包括例如车辆701主要使用网络D或先前连接到网络D(或有错误纠正的网络)的参数。这可以包括例如服务器721向地理围栏区域中的车辆广播新的网络配置文件以切换到为区域分配的新网络。每个地理围栏可以具有分配给其的新网络和配置文件，并且这可以使原本不知道给定替代网络并且原本缺少所述网络的配置文件的车辆适应。

服务器721可以任何合理的方式提供替代网络，这不排除指示所有车辆701切换到单个新网络。在1107处，服务器721指示发射器715发送重新编程指令。

由于在该示例中，已经失去与服务器721的通信的车辆701现在将重新获得通信，因此在1109处，一旦车辆701连接到新网络，服务器721就可以实际上接收反馈。这允许服务器721至少部分地确保重新编程指令是成功的，以及确定特定的重新编程指令是否不起作用或者新提出的网络是否似乎不起作用。

服务器721可以知道当网络失效时它与多少车辆701失去连接，这允许服务器721在某种程度上确定任何重新编程指令的成功。在该示例中，在1111处，服务器721检查一定百分比的丢失车辆701经由新网络恢复联机。即，例如，使用D、E、F网络示例，当网络D失效时，服务器721可能会失去与5000辆车辆701的通信。基于地理、网络容量等，服务器721可以向2000辆车辆701发送指令以切换到网络E，并且向3000辆车辆701发送指令以切换到网络F。由于服务器可能无法控制它经由ATSC发送消息到的车辆的数量，因为它是广播，因此地理围栏或随机化可以包括在如先前所讨论的重新编程指令中。例如，服务器可以基于地理围栏来分配配置文件，所述地理围栏应或多或少地分别覆盖2000和3000辆车辆，和/或可以向每辆车辆发送指令以在1至5之间随机化，其中1和2前往网络E并且3至5前往网络F。

当车辆701连接到网络时，它们重新建立与服务器的通信，因此服务器721可以确定已经重新连接的车辆701的百分比。在该示例中，百分比可以被预定义为可接受的某个数字，这可以调节某些车辆701仅仅断电或以其他方式故意断开连接的可能性。如果在1111处百分比达到例如网络E的90％，则服务器721可以停止用以改换用途到网络E的广播指令。

同时，网络F的重新连接百分比目前可能仅为30％。在这种情况下，服务器721可以在1113处等待超时延迟，然后重新发送广播和/或将被指示连接到F的一定百分比的车辆701重新分配到E。因此，如果E可以处理进一步增加的负载，并且服务器721知道对E的改变在很大程度上是成功的，则服务器721可以在1115处将尚未成功连接到F的那些车辆701转移到E。另外或替代地，服务器721可以重播连接到F的初始指令，因为许多车辆701可能由于某个其他原因(例如，由城市峡谷引起的干扰、在地下等)而尚未接收到指令。一旦重新连接了所有车辆701的合适百分比，服务器721就可以在1117处停止针对所有新网络或接入点名称的广播指令。

图12示出了用于蜂窝提供商供应处理的说明性过程。该示例性过程可由例如从远程服务器721接收指令的车辆701执行。

在该说明性示例中，车辆701接收指示可以由车辆701使用的新蜂窝网络或新接入点名称的ATSC消息。由于协调消息传递的服务器721可以将该信息发出到可能已经但可能尚未受到断开连接影响的所有车辆701，因此所述消息可以包括用于消息应用的一个或多个参数(例如，GPS位置、先前、现在丢失的连接识别等)，并且车辆701可以在1203处确定相关参数是否适用。

由于参数可以仅仅是GPS位置集，诸如地理围栏，因为ATSC发射器715可以覆盖大于受影响区域的区域，并且因此可以将消息指定为仅适用于受影响区域中的车辆701，所以车辆701可以在1205处另外考虑车辆701当前是否正经历丢失连接。即，即使服务器721没有在消息中识别丢失连接，车辆701也可能在受影响区域中(并且因此接收并处理消息)，但是可能不会正经历丢失连接，这将导致车辆701在1207处丢弃所述消息。在其他示例中，服务器721可以在消息中包括对丢失连接的识别，使得仅先前连接到丢失连接的车辆701实际上处理消息而不首先丢弃所述消息。

如果在1209处消息包括新的接入点名称，则接收和处理消息的车辆701可以在1211处切换所述车辆701的通信配置文件以使用新的接入点名称。替代地，如果在1213处消息包括定义要使用的新网络运营商的新蜂窝配置文件，则在1215处车辆701可以使用所述信息对远程信息处理控制单元(TCU)进行重新编程以利用新识别的网络。这可以包括在1217处使用所识别的新接入点名称(APN)。还可以指示其他通信替代方案，并且这些仅仅是若干替代方案及其利用的示例。

图13A和图13B示出了用于使用广播和响应进行数据收集的说明性过程。这是展示可以如何使用ATSC技术来从ATSC发射器的广播范围内的车辆701收集各种数据的一般概念。

出于许多原因，OEM或其他授权方可能希望一次从众多车辆701收集数据的一个或多个特定元素。例如，如果开始下雪，则相关方可能想知道有多少车辆701的速度降低到每小时25英里以下。为了免于车辆701在低速道路上行驶的结果，那些道路可以用作附加参数，并且通过向发射区域中的所有车辆701广播请求，并且通过接收响应，可以快速获得对于区域的或者对于广播半径内的某些类型的车辆701的车辆数据的几乎任何子集。

可以以各种方式制定先前的请求。呈现了若干非限制性示例，以及车辆701将如何丢弃消息或接受消息并作出响应。一种选项是设置速度<25mph和位置＝速度限制>25mph的任何道路的接受参数。然后，仅具有正确速度和位置的车辆701实际首先接受消息，并且那些车辆701可以报告它们的速度或行驶速度低于25mph的简单事实，而无需进一步考虑。可以经由车辆701远程信息处理控制单元将报告返回给OEM或授权方。

另一个示例是在报告中请求车辆701速度，但仅在速度限制>25mph的道路上请求。然后，在速度限制高于25mph的道路上行驶的所有车辆701将报告它们的速度。第三示例可以是设置“行驶速度比已知速度限制低超过10mph”的接受参数，这将避免必须确定哪些特定道路具有低于25mph的较低速度限制，并且车辆701可以确定(假设它们的导航系统指示当前速度限制或对此类数据的其他访问)它们是否都以比发布的速度限制低超过10mph的速度行驶。这可能导致一些车辆701报告在25mph的道路上以15mph的速度行驶，但这也可能是有用的信息。此外，消息本身可以包括报告限制那些车辆701进行报告的约束。

车辆701不一定丢弃不适用的消息，它们还可以基于适用参数对某些消息进行排队。例如，如果参数是动态的并且可以由车辆满足，则消息可以排队持续预定时间段或持续经消息定义的时间段。如果参数是静态的(例如，车辆_类型＝SUV)并且车辆701可能永远不会满足参数(例如，车辆701不是也永远不会是SUV)，则可以丢弃消息。

在所示的示例中，服务器721在1301处接收数据请求。这可能来自另一远程服务器(例如，城市服务服务器从OEM服务器721请求先前的数据以测量交通对暴风雪的响应)或来自另一OEM内部系统。例如，工程师可能正在处理项目，并且可能需要数据点来理解当前系统的使用方式。工程师可以设计相关参数(例如，在高于90度的温度条件下行驶的车辆701、配备有冷却座椅的车辆701，以确定那些车辆701中有多少车辆在那些温度下使用冷却座椅)并请求服务器721经由多个ATSC发射器715向很大范围内(诸如全国)的车辆701发出此类报告请求。

服务器721可以在1303处分配用于接受消息的相关参数和/或用于排队的相关参数和/或在报告时供车辆701考虑的相关参数。然后，服务器721指示多个ATSC发射器715发出广播，并且接收广播(广播所适用)的车辆701可以在适当时并且如广播所定义的那样进行自我报告。

当车辆701在1307处接收到广播时，车辆701在1309处基于接受参数来确定消息或请求是否适用于所述车辆701。同样，这可以包括例如环境参数、地理参数、车辆701特性等。如果不满足参数，则车辆701可以在1311处确定是否存在与消息相关联的排队参数。在一些示例中，可能没有排队参数，而是如前所述，车辆701可以基于车辆701在未来的某个时间点是否可以满足接受参数(例如，是否可以实现天气或速度、是否不能改变车辆701车身类型)来对消息排队或不排队。

如果车辆701确定不需要排队，则车辆701可以在1315处丢弃消息。否则，车辆701可以在1317处对消息进行排队，这可能导致在1309处满足参数时处理消息。一旦车辆处理了消息，车辆701就在1313处再次根据消息中指定的任何指令和/或约束来响应消息中的查询。

在ATSC技术的又一个示例性用例中，车辆701离开某一地点的动态路线选择可以不使在增加的流量下可能已经陷入困境的网络负担过重的方式来实现。蜂窝网络在某些高容量事件(诸如体育赛事)期间变得过载是很常见的。数以万计或数十万计附加装置可能试图使用网络，这可能给网络响应带来极大压力。

虽然所有这些人都倾向于在很长一段时间内到达，但他们都倾向于在事件结束时大致相同的时间离开。这意味着网络可能必须支持的导航信息数据请求为其曾经支持的导航信息数据请求的100倍或1000倍。一种解决方案是仅仅使车辆701依赖于它们自己的内部导航计算机，所述内部导航计算机即使在没有有效蜂窝网络的情况下也可以提供路线选择，但是某些车辆701缺少此类计算机，并且如在上述情况下，特别是当交通将非常繁忙时，许多其他用户更喜欢使用也指示当前交通状况的路线选择。如果所有这些请求都在大致相同的时间范围内发送到网络，特别是如果由于如交通更新等原因而正在进行请求，则网络通常无法响应大部分这些请求，从而导致车辆交通进一步减速。

通过使用ATSC技术，可以策略性地将车辆701引导出某一地点，提供近实时的交通报告，并适应不断变化的交通状况，同时对蜂窝网络施加有限的压力。在一些情况下，说明性实施例对网络施加非常有限的压力或可能没有施加压力(如果车辆701不回报)，在具有一些反馈方面的那些的其他情况下，对网络施加有限压力，但压力远小于所有用户都依赖于蜂窝传输的数据来进行所有与交通相关决策的情况。

例如，如果50,000辆车辆701正离开通常不承载如此多车辆交通的基础设施中的某一地点，则说明性实施例允许基于当前位置、相对于当前位置的最佳路线以及甚至调节适合于一些车辆701而不适合于其他车辆的某些替代路线(例如，低桥)来选择性地为那些车辆701选择路线。

在这些相同的情况下，即使单个实体正在统一交通控制，通过蜂窝网络访问所述实体也可能受到极大限制。然而，在说明性实施例中，诸如城市或OEM服务器721的统一指导系统可以基于车辆701当前所处的位置来设计那些车辆701的离开路线。即，代替所有车辆701被给予通向某些主要出口大道(例如，高速公路)的一般优选路线或主要路线的是，服务器721可以划分指令并利用地理围栏输送指令，使得给定地理围栏中的车辆701可以基于所述车辆的位置接收与所述车辆701相关的指令，即使服务器721不具体知道车辆701在那里。

可以针对单独的地理围栏或作为大地图数据集发送指令，其中车辆701可以基于它们自己的特定位置数据选择性地接收或利用数据。将关于制定的协调地图来描述解决方案，其中车辆701遵循来自地图的与车辆的当前坐标集相关的指令，但是应当理解，也可以发送与坐标集相关的各个指令块，或者与坐标集相关的较小地图数据块，其中给定车辆701将基于其当前坐标和/或特性来接受消息、对消息排队或丢弃消息。

因为数据的传输不依赖于蜂窝网络，而是依赖于可以一次到达任何数量的车辆701的广播介质，所以只要车辆在广播的通信范围内，服务器721也可以在适当时更新和重新发送地图数据或指令。因此，例如，如果发生事故，则服务器721可以用有限或完整地图更新快速地改变某些地理围栏中的车辆701的路线，从而提供反应性的、协调的交通指导，并合理地保证指导将到达包括ATSC接收器的所有或大多数车辆701并且可为其使用。

地图数据可以还包括基于车辆701类型或甚至基于车辆701最终目的地的指导。例如，出城的主要道路可以通向两条高速公路N和M。如果车辆701将前往高速公路N，则可能存在比车辆701将前往高速公路M的情况更好的路线。出口策略的数据(地图子集)将被地理围栏X中的所有车辆701接受，即使一些车辆701本来将前往M并且一些车辆701本来将前往N。

一种选项是仅仅让车辆701基于适用的地图数据导出它们自己的最佳路线(例如，服务器721推荐道路或要避开的道路以实现M或N)。然而，该解决方案的潜在问题是，如果每辆车辆701选择同一子路线，则所述子路线将变得次优，因为例如，所有M交通都将前往子路线M_1。解决对这种情况的任何担忧的一种方式是使用本文先前提出的一些随机化提议，由此例如，服务器721计算3个合理的替代方案，然后给定的车辆701机载随机化以便选择路线。这将具有对在替代方案之间均匀划分交通的合理预期，并且例如，如果一条道路的容量是其他两条道路的两倍，则可以将1/2随机化分配给所述道路，并且将1/4随机化分配给其他两条道路中的每一者，以平衡容量差异。

延迟一些车辆701使得所有车辆701不会同时到达M或N也可能是合理的，因此一些替代路线可以被设计成延迟车辆701到达，但是可能具有保持所有交通移动的净效果。由于诸如此类的解决方案，驾驶员可能选择不遵循推荐的路径(知道他们在“较慢”路径上)。如果车辆701偏离计划路径，则可以向服务器721报告以允许服务器721调整建模并输送新的解决方案以继续保持交通尽可能平稳地流动。

因此，即使区域X中的所有车辆701最初都在前往M和N的同一道路上，那些车辆701也可以基于需要哪个高速公路以及路线替代方案之间的一些合理分配来接收并处理产生子路线M_1、M_2、M_3、N_1和N_2的方向。也可以包括提供给定道路的有用性(或在某些情况下，不可能性)的道路指示器，这可以帮助避免驾驶员沿道路行驶，否则将导致显著的交通增加和/或无法通行的情况。并且，当交通转移并且车辆701倒退或通过某个区域时，服务器721可以生成完整或部分改变路线和新推荐并将其输送到车辆701，而无需担心蜂窝网络是否过载成为输送指导的阻碍。

而且，在许多城市中，某些道路仅仅暂时关闭，并且导航数据可能无法指示这一点。为了避免许多车辆701选择看似明智的路线，却遇到封闭且不可通行的道路，然后必须返回并再次进入一般交通流中，地图可以包括此类封闭，使得导航系统可以适应它们。

图14示出了可由例如服务器721执行的用于选择性交通路线选择的说明性过程。在该示例中，服务器721基于车辆701类型、车辆位置、预期交通、当前交通、最终目的地等来计划离开城市的多条出口路径的出口策略。最终目的地不需要是车辆的实际目的地，而是例如车辆701想要优先到达的主要出口干线。假设最终目的地在城外，则实际上出城的每条路径都将包括此类干线，即使总共有几十条这样的干线。

服务器721可以例如在1401处基于道路容量和车辆701当前通常所处位置的预期或了解来确定优选的流出量。基于出城交通的合适路线，服务器721然后可以在1403处以合理地调节预期交通流量的方式划分路线。

这可以包括例如在1405处为每条路线分配地理和/或随机参数(例如，基于那些车辆701当前所处位置来指定哪些车辆701应使用哪条路线的参数)。然后，在1407处，服务器721可以将地图数据发送到ATSC发射器715并指示地图数据的广播。

图15示出了可由例如给定车辆701执行的用于选择性交通路线选择处理的说明性过程。在该示例中，车辆701在其处于ATSC广播覆盖区域中时接收ATSC广播。地图数据可以由所有车辆701接收和处理，或者例如，对地图数据的处理可以基于车辆701在由广播指定的地理边界(例如，跨越确定了出口路径的整个地点的边界)内来预测。如果在1503处处理参数匹配，则车辆701处理地图数据，这可以包括暂时将地图数据并入到车辆自己的导航集中。

如果不存在匹配，则车辆701可以在1513处丢弃数据，或者如果车辆路线例如包括将承载车辆701的坐标在参数坐标内(使数据适用)，则车辆701可以存储发生这种情况的条件和时间的数据。

如果数据适用于车辆701(例如，在该示例中，车辆701在用于处理数据的参数边界内)，则车辆701可以在1504处访问地图数据内的本地数据集。即，如果地图数据被细分为所述地点内的地理围栏位置，则车辆701可能在那些地理围栏位置中的一者内。如果车辆701在所述地点内，但不在所述地点内定义了出口路径的任何地理围栏位置中(例如，车辆701只是做本地业务的当地居民)，则车辆701可以选择使用先前的车载导航数据。

区分当地居民与出口交通的另一种方式是将一条或多条主要出口大道与服务器721从所述地点内部的给定地理围栏位置计划的出口路径相关联。这些通常是车辆701离开城镇的中间目的地(例如，回家途中的高速公路)，但是实际上离开城镇的大多数交通将可能利用这些大道中的一者。因此，如果接收数据的给定车辆701具有包括这些大道中的一者的设定导航路径，则车辆701被认为离开城镇，并且可以基于中间大道目的地与出口路径的关联而知道要使用数据。如果车辆701缺少此类中间目的地(或没有设定路径)，则车辆701可以被认为正在参与本地行驶，并且可以依赖于包括在地图数据中的信息数据(诸如道路封闭)，但是可以避开出口路径策略，以便仅仅选择路径通向当地驾驶员在某个地点要前往的任何地方。

其他车辆701可能没有指定目的地，但是可以具有例如在所述地点之外的“起始位置”。为了确定出口路径策略对这些车辆701的适用性，没有出口路径但具有外地起始位置的车辆701可以将起始位置视为当前目的地以确定出口路径策略的适用性和选择特定的中间目的地(预期的主大道)。

在1505处，一旦车辆701已经确定了与车辆在所述地点内的当前坐标相对应的给定出口路径或出口路径集的适用性，车辆701就可以根据与所述地点相关的服务器推荐的出口路径来调整当前路线。这可以包括例如单条推荐路径、通向若干不同中间目的地的若干路径、或者甚至通向单个中间目的地的多条路径。在后一种情况下，车辆701可以在全部终止于同一中间位置(主大道)的多条路径之间随机或半随机地选择(或根据其他合理策略进行选择)。

在一些情况下，车辆701还将在1507处向服务器721发回报告。这可是可能的或可是不可能的，取决于蜂窝流量水平，但是车辆701也可以用指示预期路径的简单文本消息或其他基本数据元素进行报告，这可以使服务器721保持被通知而不会使网络因数据而负担过重。例如，每条出口路径可以仅仅具有分配给其的编号，并且车辆701可以报告选定路径的编号，因此几个字符的简单文本消息可以用于报告车辆的意图并允许服务器721基于多少车辆报告了对给定路径的预期使用来调整出口路径策略。其他反馈可能来自安装在路边的相机的相机视频或直升机监控。

当服务器721可以获得反馈时，它可以快速确定给定路径是否不堪重负或是否将不堪重负，并且可以立即采取步骤并重播以在情况完全发展之前缓解这种情况。例如，如果100辆车辆701意图使用服务器721仅意图用于50辆车辆的路径，则服务器721可以围绕通向该路径的道路子集(并且因此可能涵盖这些车辆的子集)重新绘制一个或多个地理围栏，并且经由ATSC广播推荐不同的出口路径。因此，可以在不依赖于蜂窝网络进行输送的情况下全体并且按需输送更新的和自适应推荐。

当车辆701沿着路径行驶时，驾驶员可能出于任何原因选择偏离路径。如果车辆701保持在路径上，则为了保持蜂窝流量低，并且因为服务器721已经知道为所述车辆701选择了哪条路径，所以可能无需报告。但是如果驾驶员在1509处偏离路径，则车辆701可以在1511处报告偏离，因此服务器721可以做出调节，特别是如果最终与路径存在大幅偏离，这也可能倾向于表明路径是不良路径或过于拥挤。

图16示出了用于调整自适应选择性交通路线选择模型的说明性过程。这是服务器721如何响应于车辆701报告位置的各种变化、路径使用、偏离等而针对某个地点内的地理围栏位置调整出口路径的示例。

由于服务器721可能确切不知道在发送初始数据和出口路径时有多少车辆701处于任何给定的地理围栏位置中、或者有多少车辆701将选择使用给定路径，因此如果服务器721可以适应报告和重新平衡任何预期交通过载可能是有用的。因此，当车辆701报告位置或路径选择时，服务器721可以调整出口路径建模，这可以包括为地理围栏位置提供附加的出口路径或将一个位置的未使用的出口路径针对另一个位置(例如，相邻位置)改换用途，或者出于诸如本文所述的那些原因等而根据需要简单地重新绘制地理围栏边界。模型调整可以包括将车辆701指定到选定的出口路径、或者在车辆701仅仅报告当前位置的情况下的预测，并且如果在1605处发生或将发生明显的过载状况，则服务器721可以在1607处通过以建议替代出口路径用于被预测为导致过载的车辆701的至少一个子集的某种方式划分出口路径来调整过载。

服务器甚至可以检测到例如给定的十字路口被预测为在单个方向上有30辆车辆拥塞，当初始策略是将这种拥塞缓解到不超过20辆车辆时。选择性重新选择路径可以重新绘制边界，使得排队的最后10辆车辆701(如果以及当排队基于那些车辆701被预测所处的位置形成时)被指示采用阻止那些车辆701在十字路口处等待的新的或不同的出口路径。前20辆车辆701适合原始策略，但是其他10辆车辆701(近似)可以立即选择阻止30辆车辆拥塞发生或持续的新的出口路径。在前20辆车辆701等待时，即使是进入最后10辆车辆701的边界的新车辆701也将知晓重新选择路径，因此这应有效地帮助阻止拥塞继续，直到如果和当替代路径也过载为止。然后，在1405处设置用于使用新路径的相关参数(例如，如果车辆701处于在交通信号灯处所述车辆701前方预期20辆汽车拥塞的位置)，并且服务器721可以在1407处指示经由ATSC输送更新后的地图数据。

图17示出了用于处理来自选择性路线选择广播的地图数据的说明性过程。同样，该示例使用整个地图的概念，包括地图的地点内的给定地理围栏位置或地图内的地点的指定出口路径，但是类似概念可以扩展到一系列指令，每个指令具有与接收车辆701当前所处的给定地理围栏区域相对应的相关接受参数。

在该示例中，车辆701在1701处接收整个地图并在1703处确定一组车辆适用参数，诸如例如当前位置、车辆701特性(高度、宽度等)、中间目的地(主大道)等。使用地图数据和分配给具有对象车辆701的特性和位置的车辆701的出口路径，车辆701可以在1705处基于车辆的当前位置和预期的中间目的地来示出一个或多个推荐的出口路径。

在该示例中，只要车辆701遵循推荐路径中的一者，就不使用报告，但是在任何情况下都可以发送预期或当前出口路径的初始报告。如果在1707处车辆701偏离推荐的出口路径，则车辆701可以在1709处报告车辆701的当前位置和/或正在使用的任何预期的新出口路径(如果正在使用出口路径)。驾驶员对偏离的选择也可能在1711处导致新的参数是适用的，这可以包括例如进入具有不同出口路径的新的地理围栏边界。如果没有新参数适用，则在1713处，车辆701可以恢复使用标准导航，这仍然可以适应由地图数据指示的任何道路封闭或其他数据，但是可能不依赖于任何特定的服务器定义的出口路径。

在该示例中，如果在1715处导航系统使车辆701在任何时间处于其中应用新参数和/或新参数返回到先前数据的适用参数内的情况，则车辆701可以基于参数示出更新后的推荐路径。

例如，地理围栏X中的用户最初可以选择使用出口路径M_1。这可以被报告，并且车辆701可以开始在出口路径M_1上行驶。然后，用户可以决定绕行到杂货店，所述杂货店不在任何出口路径上但存在于X内。用户离开M_1，并且车辆701报告离开。由于用户仍在X内，因此仍然可以示出针对X的路径选择，但是车辆701正使用车载导航来导航到杂货店，这不对应于任何服务器指定的策略。

如果杂货店在地理围栏Y内邻近X，则当车辆701进入区域Y时，出口路径推荐可以更新(示出出城的推荐路线)，但是车辆701仍将使用车载导航数据选择通向杂货店的路径。当用户完成到杂货店的行程时，用户然后可以重新进入推荐的出口路径R_1，所述推荐的出口路径R_1对应于车辆701现在所处的区域Y，并且可以报告该数据，并且车辆701可以基于车辆701现在所处位置和车辆701现在正行驶的路径而开始依赖针对Y和R_1的出口策略。所有这些都可以通过说明性实施例来调节，其中服务器721与车辆701之间几乎没有通信，因此蜂窝网络上的负担非常低，即使车辆701(从驾驶员的角度来看)正接收与其当前位置和明显意图密切相关的高度相关且特定的信息。

图18A和图18B示出了用于选择性警报处理的说明性过程。这是允许向广播区域内的所有车辆701广播车辆警报但是仅警报所适用的车辆701需要处理消息的概念。这种情况的基本示例可以包括召回通知，其中服务器721将在1801处接收通知并确定具有某些特性(品牌、型号)或某些零件(XYZ制动系统)的车辆701需要接受该消息，因此可以在1803处将该参数(特性)设置为对消息的接受和处理参数。然后，服务器721可以指示ATSC收发器广播消息。

然后，车辆701可以在1811处接收广播，并且在1813处确定所述车辆701是否包括用于处理消息的必要特性(例如，品牌、型号、XYZ制动系统等)。如果不存在匹配，则车辆701可以在1815处丢弃消息。除非参数是最终可以满足的条件(例如，当前发动机温度加上品牌和型号，其中车辆701满足品牌和型号但不满足当前发动机温度)，否则可能几乎没有理由对消息进行排队。

而且，在该示例中，可以设想，给定的乘员(例如，所有者)可以是用于输送消息的条件，因此，例如，具有所述特性的所有车辆701都可以处理所述消息，但是然后当接收到消息时，那些车辆701可以在1817处进一步确定所有者或其他指定的接收者(通常由车辆701可以确定的特性指定，例如，不是“Bob Smith”，而是“预定义的主用户”)是否存在于车辆701中。可以基于与所有者或主要用户相对应的当前配对装置或当前装置、通过使用相机或其他生物特征或其他数量的类似方法来确定用户存在。

如果用户存在，则车辆701可以在1819处在车载显示器上显示消息。如果用户不存在，则车辆701可以在1821处尝试将消息中继到已知的用户装置(例如，电话)。这也可能导致在1823处在车辆701中对消息进行排队。如果消息被排队，则在1825处如果并且当用户稍后存在，并且假设消息在1827处未超时，则可以在车内输送消息。一些消息可能仅在时间上相关，并且因此可能具有与其相关联的超时，因此现在不相关的消息的稍后输送不会使用户感到困惑。

图19示出了用于周期性充电数据更新的说明性过程。这是使用ATSC技术来提供关于电动车辆(EV)充电可用性的实时更新的另一个示例。相对于汽油动力车辆701可以加燃料的地方的数量，世界上可以对EV充电的地方有限。而且，与汽油车辆不同，EV需要明显更长的时间来补充能量。这些因素的组合可能使得期望知道EV充电的可用性，所述可用性可能在任何时间以及与充电相关联的任何等待时间处受到限制，这相对于其他补给能量时间可能是显著的。

一种可能性是车辆701经由直接连接请求EV充电的更新。这是实时更新的周期性解决方案，并且总体上还需要大量带宽。即使将该信息单独推送到车辆，此类信息在全球范围内消耗的带宽量也将是持续的且庞大的。此外，车辆701将需要太多信息，或者将需要报告它们的位置，以便接收有用的信息，并且任一解决方案都消耗附加的带宽并招致附加的成本。

使用ATSC，可以不使用蜂窝带宽以有限的成本向所有车辆701实时地广播本地EV充电可用性。由于仅在广播范围内的车辆701接收信息，因此不需要使车辆701报告坐标。而且，由于所有可用性都可以与相关的地理参数相关联，因此给定的车辆701可以忽略在地理上不相关的大多数信息。因此，可以针对给定的广播区域呈现所有可用EV站的单个广播，从而表示当前可用性，并且车辆701可以决定哪些信息是相关的以及哪些信息应当被忽略。

此外，可以在空间释放和/或预约时更新该信息，并且因此如果需要，可以以低的财务和带宽开销来输送本地可用充电的合理的近乎连续的库存。这可以另外减少蜂窝网络的压力，并且车辆701在它们行驶时不需要连续地搜索和请求电视台信息，除非它们在任何ATSC发射的范围之外并且需要再充电信息。

在广播方面，图19示出了可以用于提供EV可用性更新的若干说明性过程。服务器721可以执行两个过程，一个路径是请求路径，并且一个路径是推送路径。在该示例中，在1901处的每个特定时间间隔，服务器721可以在1903处请求更新后的充电使用/预约信息。预约信息可以被视为使用信息，因为预约可以表示保持时段和使用时段两者。在另一路径中解决最终未履行的预约，但是在该示例中，当请求信息时，服务器721将预约隔间视为已用隔间。

一旦服务器721在1905处从给定ATSC发射器715的广播区域内的各种EV站接收到更新，服务器721就可以在1907处如下面所讨论的那样设置参数。单个服务器721可以处理来自各种ATSC广播区域的数据的接收，因此服务器721可以例如接收州或甚至全国性数据，并且在1906处基于哪些报告位置对应于哪些ATSC广播区域对数据进行分类。由于服务器721可以在大多数情况(如果不是全部的话)下通过有线网络连接获得该信息，因此与车辆701请求该信息时相比，存在更少的成本和带宽约束。并且由于服务器721可以经由ATSC输送该信息，因此蜂窝网络可以基本上无负担。

在推送模型中，服务器721可以在1911处接收关于给定站处的状态改变的信息。这可以对应于充电完成、充电接近完成、预约完成、预约接近完成或预约取消。服务器721接收何种数据可以取决于服务器721跟踪可用性信息的粒度。

响应于在1911处从站接收到通知，服务器721可以在1913处调整其自身的内部数据，这可能导致发送新的ATSC通知，或者可以修改即将到来的ATSC通知。例如，服务器721可以每5分钟、10分钟等发出更新。如果服务器721没有不断地收集实时数据直到通知，则相对于发送通知时，从收集数据时开始可能发生某些状态变化。通过具有如上的站报告状态变化，虽然不是必需的，但是在一些情况下可以提高所报告信息的准确性，这取决于数据收集和报告策略。

一旦已经收集了合适的数据，并且当服务器721将要发出报告时，服务器721就可以为报告和/或报告中的数据子集设置接受参数或适用性参数。例如，接受参数可以在数据内定义围绕各种充电站的相对地理围栏，并且车辆701可以仅在其位于这些充电站中的一者的范围内时才接受数据。

在其他情况下，车辆701可以具有经所有者定义的接受参数，从而知道数据仅仅是充电数据，并且车辆701可以仅在例如车辆701在距充电站的X距离内或在Y处电量％时才接受和处理数据。在其他情况下，只要某个范围内的充电站可用，就可以通知所有EV，以防所有者想要充满电，即使不是立即需要充电，因为所有者将至少知道隔间在即刻可能是可用的并且靠近车辆701。

一旦已经设置了任何相关参数，服务器721就可以指示给定的ATSC发射器715或控制发射器715的电视台在1909处发出更新。

图20示出了用于处理充电警报的说明性过程。车辆701可以在2001处接收ATSC广播，然后可以选择数据是否相关。缺乏EV能力的车辆701仍然可以接收消息，并且丢弃消息，因为那些车辆701不需要所述信息。广播范围内的其他车辆701可能离站太远，或者可能不需要充电，因此也可能在2005处丢弃消息。可以对消息进行排队，但是由于该信息表示实时数据并且不断变化，因此在任何显著时间段内排队可能都不太有用。然而，在某些情况下或在适当时(例如，当车辆701即将过电量阈值时或者当车辆701接近适用范围但尚未在所述范围内时)，排队是可能的。

当在2003处存在参数匹配时，指示车辆701应采取动作，车辆701可以在2007处呈现关于本地可用充电站的推荐或信息。由车辆701设想和呈现的数据也可以是电量状态的函数，例如，仅作为充满电候选者(例如电量高于50％)的车辆701可能仅看到非常接近的充电站，但是例如低于10％的车辆701可以得到更宽区域的数据，因为那些车辆701可能更迫切地需要充电。

而且，在该示例中，车辆701可以在2009处预约充电站。这可以包括向充电站发送请求预约的消息。如果车辆701在2009处不想预约充电站隔间，则车辆701可以丢弃当前数据集并等待下一次报告的更新。否则，车辆701可以在2011处联系站并尝试预约隔间。如果请求不成功，则车辆701可以从显示器移除所述数据(因为已经预约或使用了隔间)并重新呈现具有修改的信息。

如果车辆701在2013处成功预约充电站，则车辆701也可以直接向服务器721报告该信息，因此服务器721可以将这视为所述充电站的状态变化并且可以相应地更新要发送的下一个数据。当车辆701使用隔间、到达充电站、结束充电等时，可以发送类似更新，使得服务器721不必依赖于充电站本身来更新各个充电站的充电状态。

ATSC发射的又一可能用途是广播软件更新以一次到达多辆车辆701，同时缓解发射成本。在广播更新时被供电的车辆701可以接收更新，但是这可能仅是给定区域中的车辆701的子集。更新广播计划的挑战是确定合适数量的车辆701何时已经经由广播接收到更新，然后可能使用直接发射来使更新到没有更新的车辆701。此外，虽然使用ATSC的成本可能比与单个广播将到达的车辆相同数量的车辆701直接通信低得多，但是成本可能是非零的，因此希望不过度广播可能仅在发射范围内的极小百分比的车辆701需要的数据，特别是当甚至不知道那些车辆701是否联机时。

为了平衡更新的发送以及衡量发射的成功，该说明性示例包括反馈部件，其中车辆701可以报告成功、部分成功、失败、安装完成等。系统可以不进行实时错误校正，但是知道发射区域中的车辆701的较大子集未能接收到更新可能是立即重新发送更新或考虑可能存在的问题、修复感知到的问题然后重新发送更新的充分理由。

此外，可能存在与ATSC相关联的多个信道，并且仅那些信道的子集可以用于更新。广播可以使用增加的信道和增加的频率，或者任一者的减少量，以便适应所报告的更新和问题。更新的关键性也可能决定使用水平。

例如但不限于，如果广播文件图像的不完整下载的百分比高于第一阈值，则服务器721可以请求增加用于广播的信道使用和/或增加频率。百分比高于较低阈值(指示更多的成功)可能会仅导致频率增加。百分比低于某个阈值(指示普遍成功)可能导致服务器721选择使用直接通信来完成文件图像与仍然缺少完整文件图像的车辆701的传输。

图21示出了可由例如服务器721执行的用于软件更新广播的说明性过程。在该示例中，服务器721在2102处接收将前往ATSC广播区域内的一辆或多辆车辆701的更新。如果已知或预计在广播区域内的车辆701的总数低于预定义阈值，所述预定义阈值可以是预计的广播成本和接收可能性对仅仅直接联系那些车辆701的成本的函数，则服务器721可以在2103处设置接受和/或执行参数。如前所述，这些参数可以包括车辆701特性(例如，品牌、型号、软件版本、软件包、适用部件等)或任何其他合适的参数。

然后，服务器721可以指示从ATSC发射器发射更新的文件图像以及参数。当车辆701接收并处理更新时，那些车辆701可以在2107处向服务器回报，从而允许服务器721确定有多少车辆701接收到更新中的一些、有多少车辆接收到更新的全部、有多少车辆能够处理更新等。由于许多更新无法处理直到车辆701停止和/或断电，因此关于成功安装的信息可能会延迟。因此，在一些情况下，反馈可能不是瞬时的，但是服务器721可能能够相当快速地估计至少有多少车辆701成功地接收到整个文件图像。

当服务器721在2107处接收反馈时，服务器721可以基于文件图像的完全或部分接收的所报告水平来确定所报告的明显故障和/或预测故障原因。例如，在2109处的第一故障阈值(例如，30％+未能接收完整文件图像)可以使服务器721在2111处增加信道使用请求，并且在2117处将广播频率增加到第一水平。在2113处的第二故障阈值(例如，20％至30％未能接收到完整文件图像)可以使服务器721在2117处增加响应频率，但是可能不需要使用附加的或更多的信道。在2115处的第三阈值(例如，10％至20％未能接收到完整文件图像)可能导致在2117处设置数量更少的重复请求。如果故障率低于最后阈值，意味着预定义的可接受百分比或数量的车辆701已经报告完全接收到更新，则服务器721可以在2119处反而选择仅仅直接联系其余车辆721。

虽然服务器721可能不确切地知道在给定时间哪些车辆701在ATSC广播区域中，或者哪些车辆701是活动的，但是它可以具有旨在进行更新的所有车辆701的列表(例如，VIN列表)。当车辆701回报时，服务器721可以从列表中删除那些车辆701，并且当剩余车辆701的百分比或数量足够低时，服务器721可以开始选择性地联系那些车辆701。

图22示出了用于更新广播处理的说明性过程。在该示例中，车辆701在2201处从服务器721接收更新或补丁通知。基于与广播相关联的参数(例如，车辆品牌、型号、软件版本、部件等)，车辆701在2203处确定任何所需的车辆701特性是否与参数匹配以供接受和处理。如果否，则车辆701可以在2205处丢弃消息。否则，车辆701可以在2207处记录关于下载的统计信息，例如，使用哪个信道、下载需要多长时间、完整性等。

在2209处车辆701保存文件之后，车辆701还可以在2211处向服务器721报告所记录的统计信息。这可以允许服务器721进行所述调整，以及确定某些信道是否提供足够的覆盖，以及是否有任何信道具有可通过针对车辆701使用性能比其他信道更差的给定信道的反馈确定的问题。这也可能导致改变广播信道。这还可以揭示车辆701的性能问题，诸如车辆701从对其他车辆701正常工作的信道接收到不良性能，从而可以揭示车辆701接收器的问题并提供纠正那些问题的机会。

图23示出了可由例如服务器721执行的用于调节软件更新广播和解决所述问题的说明性过程。在该示例中，服务器721在2301处接收车辆701反馈。这可以包括例如由车辆701使用的信道、下载的完整性、下载时间、下载速度等。

如果使用特定信道的一辆或多辆车辆701都报告所述信道的不良性能统计(例如，低于阈值预期或相对于其他信道)，则服务器721可以在2303处尝试确定给定信道是否存在问题。如果信道看起来有问题，则服务器721可以分支到2109处的故障评估过程。

在其他情况下，故障可能看起来是车辆方面的。如果单辆车辆或不共享特定的统一特性(例如，同一地理区域或与其他车辆接近的位置、某些硬件、共同的软件版本或固件版本等)的车辆701报告了问题，则服务器721可以在2305处确定问题在于车辆701本身(例如，零件或软件故障)，并且服务器721可以在2307处联系各辆车辆701以尝试诊断和解决问题。

如果服务器721观察到在经历故障的车辆701之间存在统一特征，但是同一信道上的其他车辆701没有经历故障(确认故障不在于信道本身)，则服务器721可以确定的问题在于例如软件版本。在此类情况下，ATSC发射器715可以用于通知车辆701所有者车辆701需要修理。服务器721可以在2309处联系车辆701或零件的制造商并确定是否存在应发出的警报，然后可以分支到1801处的警告车辆701的所有者。如果可能，服务器721还可以布置以将针对问题(和/或车辆701无法接收的当前更新)的补丁直接发送到那些车辆701。如果可以及时地解决通信问题，则那些车辆701可以受益于它们先前无法接收的补丁的进一步ATSC发射。

虽然上文描述了示例性实施例，但这些实施例并不意图描述本发明的所有可能形式。相反，本说明书中所使用的字词为描述性而非限制性的字词，并且应理解，可在不脱离本发明的精神和范围的情况下做出各种改变。另外，各种实现实施例的特征可以逻辑方式组合以产生本文描述的实施例的情境上合适的变型。

根据本发明，提供了一种系统，所述系统具有：处理器，所述处理器被配置为：接收软件更新文件图像；基于与和所述软件更新相关联的适用性要求相比ATSC广播范围内的预定义多辆车辆的特性来确定所述软件更新适用于那些车辆；响应于确定所述软件更新适用于所述预定义的多辆车辆，指示ATSC发射器广播数据，所述数据包括所述软件更新的文件图像和将所述适用性要求定义为车辆特性的至少一个参数，所述参数指定具有所述特性的哪些车辆应当接受并处理所述数据；从接受所述数据并接收所述文件图像的所述多辆车辆中的一者或多者接收反馈；以及响应于所述反馈，指示调整广播特性以增加所述多辆车辆中对所述广播文件图像的接收。

根据实施例，基于来自所述多辆车辆中的每一者的所报告车辆位置在所述ATSC广播范围内，已知所述预定义的多辆车辆在所述广播范围内。

根据实施例，基于来自所述多辆车辆中的每一者的先前报告车辆位置在所述ATSC广播范围内，预计所述预定义的多辆车辆在所述广播范围内。

根据实施例，所述至少一个参数包括车辆软件版本。

根据实施例，所述至少一个参数包括车辆部件识别。

根据实施例，所述至少一个参数包括车辆识别号码。

根据实施例，所述至少一个参数包括车辆品牌和型号。

根据实施例，所述反馈指示多于第一预定义阈值的车辆未能接收到完整文件图像，并且其中所述调整包括指示使用附加的广播信道和增加的广播频率。

根据实施例，所述反馈指示多于第二预定义阈值但小于所述第一预定义阈值的车辆未能接收到完整文件图像，并且其中所述调整包括指示增加的广播频率。

根据实施例，所述反馈指示由报告车辆用于接收所述文件图像的信道，并且使用给定信道的多于预定义百分比的车辆未能接收到所述文件图像，并且其中所述调整包括指示用新的信道替换所述给定信道并重播所述文件图像。

根据实施例，所述反馈指示单独故障，所述单独故障包括给定车辆在接收所述文件图像和由所述给定车辆使用的信道方面的故障，其中来自使用同一信道的其他车辆的反馈不指示所述故障，并且其中所述处理器还被配置为响应于所述单独故障而直接通知所述给定车辆在所述车辆处发生潜在通信故障。

根据实施例，所述反馈指示组故障，所述组故障包括所述多辆车辆的子集在接收所述文件图像和所述车辆子集使用的一个或多个信道方面的故障，并且其中来自所述多辆车辆中不在所述子集中但使用所述相同的一个或多个信道的其他车辆的反馈不指示故障，并且其中所述多辆车辆的所述子集共享共同的通信相关车辆特性，并且其中所述处理器还被配置为响应于所述组故障而联系车辆制造商并且报告所述共同特性。

根据本发明，一种方法包括：接收软件更新文件图像；基于与和所述软件更新相关联的适用性要求相比ATSC广播范围内的预定义多辆车辆的特性来确定所述软件更新适用于那些车辆；响应于确定所述软件更新适用于所述预定义的多辆车辆，指示ATSC发射器广播数据，所述数据包括所述软件更新的文件图像和将所述适用性要求定义为车辆特性的至少一个参数，所述参数指定具有所述特性的哪些车辆应当接受并处理所述数据；从接受所述数据并接收所述文件图像的所述多辆车辆中的一者或多者接收反馈；以及响应于所述反馈，指示调整广播特性以增加所述多辆车辆中对所述广播文件图像的接收。

根据实施例，所述反馈指示多于第一预定义阈值的车辆未能接收到完整文件图像，并且其中所述调整包括指示使用附加的广播信道和增加的广播频率。

根据实施例，所述反馈指示多于第二预定义阈值但小于所述第一预定义阈值的车辆未能接收到完整文件图像，并且其中所述调整包括指示增加的广播频率。

根据实施例，所述反馈指示由报告车辆用于接收所述文件图像的信道，并且使用给定信道的多于预定义百分比的车辆未能接收到所述文件图像，并且其中所述调整包括指示用新的信道替换所述给定信道并重播所述文件图像。

在本发明的一个方面中，所述反馈指示单独故障，所述单独故障包括给定车辆在接收所述文件图像和由所述给定车辆使用的信道方面的故障，其中来自使用同一信道的其他车辆的反馈不指示所述故障，并且其中所述方法进一步包括响应于所述单独故障而直接通知所述给定车辆在所述车辆处发生潜在通信故障。

在本发明的一个方面中，所述反馈指示组故障，所述组故障包括所述多辆车辆的子集在接收所述文件图像和所述车辆子集使用的一个或多个信道方面的故障，并且其中来自所述多辆车辆中不在所述子集中但使用所述相同的一个或多个信道的其他车辆的反馈不指示故障，并且其中所述多辆车辆的所述子集共享共同的通信相关车辆特性，并且其中所述方法进一步包括响应于所述组故障而联系车辆制造商并且报告所述共同特性。

根据本发明，提供了一种存储指令的非暂时性存储介质，所述指令在由处理器执行时使所述处理器执行一种方法，所述方法包括：接收软件更新文件图像；基于与和所述软件更新相关联的适用性要求相比ATSC广播范围内的预定义多辆车辆的特性来确定所述软件更新适用于那些车辆；响应于确定所述软件更新适用于所述预定义的多辆车辆，指示ATSC发射器广播数据，所述数据包括所述软件更新的文件图像和将所述适用性要求定义为车辆特性的至少一个参数，所述参数指定具有所述特性的哪些车辆应当接受并处理所述数据；从接受所述数据并接收所述文件图像的所述多辆车辆中的一者或多者接收反馈；以及响应于所述反馈，指示调整广播特性以增加所述多辆车辆中对所述广播文件图像的接收。

在本发明的一个方面中，当所述反馈指示多于第一预定义阈值的车辆未能接收到完整文件图像时，所述调整包括指示使用附加的广播信道和增加的广播频率；并且其中当所述反馈指示多于第二预定义阈值但小于所述第一预定义阈值的车辆未能接收到完整文件图像时，所述调整包括指示增加广播频率。

Claims (15)

1.一种系统，其包括：

处理器，所述处理器被配置为：

接收软件更新文件图像；

基于与和所述软件更新相关联的适用性要求相比ATSC广播范围内的预定义多辆车辆的特性来确定所述软件更新适用于那些车辆；

响应于确定所述软件更新适用于所述预定义的多辆车辆，指示ATSC发射器广播数据，所述数据包括所述软件更新的文件图像和将所述适用性要求定义为车辆特性的至少一个参数，所述参数指定具有所述特性的哪些车辆应当接受并处理所述数据；

从接受所述数据并接收所述文件图像的所述多辆车辆中的一者或多者接收反馈；以及

响应于所述反馈，指示调整广播特性以增加所述多辆车辆中对所述广播文件图像的接收。

2.根据权利要求1所述的系统，其中基于来自所述多辆车辆中的每一者的所报告车辆位置在所述ATSC广播范围内，已知所述预定义的多辆车辆在所述广播范围内。

3.根据权利要求1所述的系统，其中基于来自所述多辆车辆中的每一者的先前报告车辆位置在所述ATSC广播范围内，预计所述预定义的多辆车辆在所述广播范围内。

4.根据权利要求1所述的系统，其中所述至少一个参数包括车辆软件版本。

5.根据权利要求1所述的系统，其中所述至少一个参数包括车辆部件识别。

6.根据权利要求1所述的系统，其中所述至少一个参数包括车辆识别号码。

7.根据权利要求1所述的系统，其中所述至少一个参数包括车辆品牌和型号。

8.根据权利要求1所述的系统，其中所述反馈指示多于第一预定义阈值的车辆未能接收到完整文件图像，并且其中所述调整包括指示使用附加的广播信道和增加的广播频率。

9.根据权利要求8所述的系统，其中所述反馈指示多于第二预定义阈值但小于所述第一预定义阈值的车辆未能接收到完整文件图像，并且其中所述调整包括指示增加的广播频率。

10.根据权利要求1所述的系统，其中所述反馈指示由报告车辆用于接收所述文件图像的信道，并且使用给定信道的多于预定义百分比的车辆未能接收到所述文件图像，并且其中所述调整包括指示用新的信道替换所述给定信道并重播所述文件图像。

11.根据权利要求1所述的系统，其中所述反馈指示单独故障，所述单独故障包括给定车辆在接收所述文件图像和由所述给定车辆使用的信道方面的故障，其中来自使用同一信道的其他车辆的反馈不指示所述故障，并且

其中所述处理器还被配置为响应于所述单独故障而直接通知所述给定车辆在所述车辆处发生潜在通信故障。

12.根据权利要求1所述的系统，其中所述反馈指示组故障，所述组故障包括所述多辆车辆的子集在接收所述文件图像和所述车辆子集使用的一个或多个信道方面的故障，并且其中来自所述多辆车辆中不在所述子集中但使用所述相同的一个或多个信道的其他车辆的反馈不指示故障，并且其中所述多辆车辆的所述子集共享共同的通信相关车辆特性，并且

其中所述处理器还被配置为响应于所述组故障而联系车辆制造商并且报告所述共同特性。

13.一种方法，其包括：

接收软件更新文件图像；

基于与和所述软件更新相关联的适用性要求相比ATSC广播范围内的预定义多辆车辆的特性来确定所述软件更新适用于那些车辆；

响应于确定所述软件更新适用于所述预定义的多辆车辆，指示ATSC发射器广播数据，所述数据包括所述软件更新的文件图像和将所述适用性要求定义为车辆特性的至少一个参数，所述参数指定具有所述特性的哪些车辆应当接受并处理所述数据；

从接受所述数据并接收所述文件图像的所述多辆车辆中的一者或多者接收反馈；以及

响应于所述反馈，指示调整广播特性以增加所述多辆车辆中对所述广播文件图像的接收。

14.根据权利要求13所述的方法，其中所述反馈指示多于第一预定义阈值的车辆未能接收到完整文件图像，并且其中所述调整包括指示使用附加的广播信道和增加的广播频率。

15.根据权利要求14所述的方法，其中所述反馈指示多于第二预定义阈值但小于所述第一预定义阈值的车辆未能接收到完整文件图像，并且其中所述调整包括指示增加的广播频率。

Images