用于调节从车辆要求软件数据的可变频度的方法和装置

摘要

本发明涉及用于调节从车辆要求软件数据的可变频度的方法和装置。提供了一种用于调节为车辆车载计算机系统请求软件数据的可变频度的方法。该方法确定在第一软件数据已经被检索到后所执行的点火循环的次数；并且当点火循环的次数大于阈值时，减少生成软件请求的频率以获得减少的频率。

说明书

技术领域

本文描述的主题的实施例总体上涉及车辆车载计算机系统的软件检索。更具体地，该主题的实施例涉及调节在车辆车载计算机系统上要求下载软件数据的可变频度。

背景技术

车辆越来越多地装备由车载计算机系统，该车载计算机系统提供了信息、娱乐、和系统管理能力。为了跟上基于新软件的技术和特征，并且为了实现车辆的内部系统的最新的功能，必须定期地在车辆上下载相关的软件。车辆车载计算机系统可与远程服务器通信以请求软件下载，并且如果能获得，还在车辆车载计算机系统上获取并利用该软件。

 一般而言，车辆不会维持到远程服务器的持续通信连接并且也不会意识到必要的软件下载是可获得的。必须进行自主的算法决定来确定车辆应该多长时间请求一次软件下载，例如软件更新。当车辆更新或者当车辆最近已经下载了额外的软件时，软件更新就得更加频繁。在车辆的最初发动期间以及继更新之后，必须频繁地请求额外的软件，因为可能有错误需要修正。不过，更老的车辆和/或在相当长的时间内没有下载新的或更新的软件的车辆可能不要求额外的软件下载，除非在极少的情况下。停止对软件下载的检查是不可取的，因为这可能会错过鲜有的却重要的软件更新。另一方面，如果具有成熟软件的车辆继续按照当车辆还是新车时就被编程进该车辆的同样时间表请求软件下载，那么这种相当大量的不必要的软件下载请求可能消耗很大的资源，这包括无线通信带宽和远程服务器处理循环。

 因此，期望减少服务器在任何给定时间所接收的软件更新请求的次数。另外，其它可取的特征和特点将从下面的具体描述和所附的权利要求并结合附图以及前面的技术领域和背景技术而变得易于理解。

发明内容

一些实施例提供了一种用于调节为车辆车载计算机系统请求软件数据的可变频度的方法。该方法确定在第一软件数据已经被检索到后所执行的点火循环的次数；并且当点火循环的次数大于阈值时，减少生成软件请求的频率以获得减少的频率。

 一些实施例提供了用于调节在车辆上请求软件更新的可变频度的系统。该系统包括通信模块，其构造成请求并接收车辆车载计算机系统的软件更新；控制逻辑，其构造成确定在第一软件更新被执行后所执行的点火循环的次数；以及软件更新安排模块，其构造成在点火循环的次数大于阈值时减少请求软件更新的频率。

 一些实施例提供了非瞬态计算机可读存储介质，其包含存储在其上的指令，其中当由处理器执行时，这些指令使处理器执行调节车辆上对软件更新的请求的可变频度的方法。该方法确定在车辆被关停之前是否执行过车辆上软件更新，其中该车辆利用包括默认频率的更新请求时间表；并且当在车辆被关停之前没有执行过车辆上软件更新时，实施包括减少的频率的更新请求时间表。

 提供这个发明内容是以简化形式介绍所选的概念，这些概念将在具体实施方式中被进一步描述。这个发明内容不是用来确认所要求保护的主题的关键特征或必要特征，也不是用来辅助确定所要求保护的主题的范围。

本申请还提供了如下方案：

方案1. 一种用于调节为车辆车载计算机系统请求软件数据的可变频度的方法，该方法包括：

确定在已经检索到第一软件数据之后所执行的点火循环的次数；以及

当所述点火循环的次数大于阈值时，减少生成软件请求的频率，以获得减少的频率。

方案2. 如方案1所述的方法，还包括：

从远程服务器检索所述第一软件数据；

其中对所述第一软件数据的所述检索包括从所述远程服务器下载软件更新。

方案3. 如方案1所述的方法，还包括：

当所述点火循环的次数小于或等于所述阈值时，利用默认频率生成软件请求。

方案4. 如方案1所述的方法，还包括：

读取点火循环计数器值以确定在已经检索到所述第一软件数据之后所执行的点火循环的次数；

响应于所述车辆的点火增加所述点火循环计数器值；以及

将所述增加的点火循环计数器值与所述阈值相比较。

方案5. 如方案4所述的方法，还包括：

通过根据所述减少的频率请求第二软件数据来确定所述第二软件数据是否可获得；以及

当所述第二软件数据是可获得的时，

检索该第二软件数据；

将所述第二软件数据合并到所述车载计算机系统；以及

重置所述点火循环计数器值。

方案6. 如方案5所述的方法，其中重置所述点火循环计数器值的步骤还包括开始使用默认频率以生成软件请求。

方案7. 如方案5所述的方法，还包括：

使用无线通信协议，从远程服务器获得所述第二软件数据。

方案8. 如方案5所述的方法，还包括：

使用局域网（LAN）连接，从远程服务器获得所述第二软件数据。

方案9. 一种用于调节在车辆上请求软件更新的可变频度的系统，该系统包括：

通信模块，其构造成请求并接收车辆车载计算机系统的软件更新；

控制逻辑，其构造成确定在执行了第一软件更新之后所执行的点火循环的次数；以及

软件更新安排模块，其构造成在所述点火循环的次数大于阈值时减少请求软件更新的频率。

方案10. 如方案9所述的系统，其中软件更新安排模块还被构造成： 

当所述点火循环的次数小于或等于所述阈值时，利用默认频率请求软件更新。

方案11. 如方案9所述的系统，其中所述控制逻辑还被构造成：

读取点火循环计数器值以确定在执行所述第一软件更新之后所执行的点火循环的次数；

响应于所述车辆车载计算机系统被通电而增加所述点火循环计数器值；以及

将所述增加的点火循环计数器值与所述阈值相比较。

方案12. 如方案11所述的系统，其中所述控制逻辑还被构造成：

通过根据所述减少的频率请求所述第二软件更新来确定所述第二软件更新是否可获得；以及

当所述第二软件更新是可获得的时，

检索该第二软件更新；

将所述第二软件更新合并到所述车载计算机系统；以及

重置所述点火循环计数器值。

方案13. 如方案12所述的系统，其中，当需要所述第二软件更新时，所述控制逻辑还被构造成：

开始使用默认频率请求软件更新。

方案14. 如方案12所述的系统，其中所述通信模块还被构造成使用无线通信协议从远程服务器获得所述第二软件更新。

方案15. 如方案12所述的系统，其中所述通信模块还被构造成使用局域网（LAN）连接从远程服务器获得所述第二软件更新。

方案16. 一种非瞬态计算机可读存储介质，其包含存储在其上的指令，其中当由处理器执行时，所述指令使该处理器执行调节车辆上的软件更新请求的可变频度的方法，该方法包括： 

确定在车辆被关停之前是否执行了车辆上软件更新，其中所述车辆利用包括默认频率的更新请求时间表；以及

当在所述车辆被关停前没有执行车辆上软件更新时，实施包括减少的频率的更新请求时间表。

方案17. 如方案16所述的非瞬态计算机可读存储介质，其中由所述指令执行的所述方法还包括：

当在所述车辆被关停前执行了车辆上软件更新时，利用所述更新请求时间表的所述默认频率；

其中，所述默认频率包括请求软件更新的恒定定期频度。

方案18. 如方案16所述的非瞬态计算机可读存储介质，其中由所述指令执行的所述方法还包括：

使用无线通信协议，从远程服务器获得所述第二软件更新。

方案19. 如方案16所述的非瞬态计算机可读存储介质，其中由所述指令执行的所述方法还包括：

读取点火循环计数器值以确定在执行所述第一软件更新之后所执行的点火循环的次数；

增加所述点火循环计数器值；以及

将所述点火循环计数器值与所述阈值相比较。

方案20. 如方案19所述的非瞬态计算机可读存储介质，其中由所述指令执行的所述方法还包括：

通过根据所述减少的频率请求所述第二软件更新来确定是否需要所述第二软件更新；以及

当需要所述第二软件更新时，

检索该第二软件更新；

将所述第二软件更新合并到所述车载计算机系统；以及

重置所述点火循环计数器值。

附图说明

通过参照具体实施方式和权利要求，并结合附图进行考虑，可得到对本主题的更全面的理解，在各附图中相同的附图标记表示相似的元件。

图1是根据一些实施例的包括车载计算机系统的车辆的功能框图；

图2是说明了根据一些实施例的调节从远程服务器请求软件数据的可变频度的方法的流程图；

图3是说明了根据一些实施例的使用确定的请求频率请求软件下载的流程图；以及

图4描绘了根据一些实施例的自上一次软件下载以来执行的点火循环的次数相对于每小时的软件数据请求的次数的绘图。

具体实施方式

下面的具体描述本质上仅仅是示例性的，并非用于限制本主题的实施例或者这些实施例的应用和使用。在本文使用时，词语“示例性”表示“用作示例、例子或说明”。本文描述的任何示例性的实施方式都不一定被理解为相比其它实施方式是优选的或有利的。而且，并不意在受在前面的技术领域、背景技术、发明内容或者后面的具体实施方式中出现的任何明示或暗示的理论的约束。

 本文给出的主题是关于用于调节从远程服务器请求为车辆车载计算机系统的软件下载的可变频度的方法。在一些实施例中，车辆车载计算机系统以预定的、定期的频率请求软件下载。在一些实施例，请求软件下载的可变频度基于在车辆被断电之前是否执行过软件下载而在点火时被降低。在一些实施例中，请求软件下载的可变频度基于车辆的使用年限和/或自在车辆处接收到上一次软件下载以来所经过的时间长度而被降低。这个车辆使用年限和/或自上一次下载以来的时间可通过所执行的点火循环的次数、里程值、时间和/或日期值、维修保养数据等来确定。

 现在参照附图，图1是根据一些实施例的包括车载计算机系统102的车辆100的功能框图。车载计算机系统102可使用车辆100上的任意数量的（包括仅有一个）电子控制模块来实施。在某些实施方式中，本文描述的特征和功能是与车辆100的一个或多个电子控制模块中的操作相关联。车辆100可以是多种不同类型的汽车（轿车、货车、卡车、摩托车、运动型多用途车、大篷货车等）、航空器（例如，飞机、直升机等）、水路交通工具（船艇、舰船、水上摩托等）、火车、全地形车辆（雪地车、四轮车等）、军事交通工具（高机动多功能轮式运输车、坦克、卡车等）、救援车（消防车、云梯消防车、警车、紧急医疗服务卡车和急救车等）、航天器、气垫船等中的任一种。

 车载计算机系统102被构造成调节从远程服务器请求下载软件数据的频率、根据确定的频率请求软件数据、和在合适的时间下载合适的软件数据。车载计算机系统102可包括但不限于： 处理器架构104、系统存储器106、车辆数据收集模块108、通信模块110、软件请求和下载模块112、和软件请求安排模块114。车载计算机系统102的这些元件和特征可操作性地彼此相关联、彼此联接、或者以其他方式被构造成按照需要彼此协作以支持期望的功能——具体来说，控制在车辆车载计算机系统102处请求软件下载的可变频度，如本文中所描述。为了便于说明和清楚，这些元件和特征的各种物理的、电的、和逻辑的联接和互连没有描述在图1中。而且，应该意识到，车辆车载计算机系统102的实施例将包括其他的元件、模块、和特征，它们协作以支持期望的功能。简单起见，图1仅描述了与软件下载请求的可变频率的调节有关的某些元件。下面更具体地描述与这个可变频率的调节有关的技术。

 处理器架构104可用一个或多个通用目的处理器、内容可寻址存储器、数字信号处理器、专用集成电路、现场可编程门阵列、任何合适的可编程逻辑设备、离散的门和晶体管逻辑、离散的硬件部件、或者被设计成执行这里所描述的功能的任何组合来实施或执行。具体而言，处理器架构104可被实现为一个或多个微处理器、控制器、微控制器、或状态机。而且，处理器架构104可被实施为计算设备的组合，例如数字信号处理器和微处理器的组合、多个微处理器、与数字信号处理器芯联合的一个或多个微处理器、或者任何其它的此类构造。

 系统存储器106可使用任意数量的设备、部件、或模块来实现，视本实施例的情况而定。而且，车辆车载计算机系统102可包括集成在其内的系统存储器106和/或与其操作联接的系统存储器106，视具体实施例的情况而定。实践中，系统存储器106可被实施为RAM存储器、闪存、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移除磁盘、或本领域已知的任何其他形式的存储介质。在某些实施例中，系统存储器106包括硬盘，其也可被用于支持车载计算机系统102的功能。系统存储器106可被联接到处理器架构104使得处理器架构104可从系统存储器106读取以及向系统存储器106写入信息。在另一变型中，系统存储器106可集成到处理器架构104。作为示例，处理器架构104和系统存储器106可存在于适当设计的专用集成电路（ASIC）中。

 车辆数据收集模块108被合适地构造成收集并提供车辆数据给车载计算机系统102。车辆数据可由任意数量的车载传感器、仪器、或设备来获得或生成，这是熟知的。车辆数据可包括影响从远程服务器请求软件数据的可变频度的因素，这包括自由车辆车载计算机系统102执行的上一次软件下载以来所执行的点火循环的次数、时间测量（例如，车辆的使用年限和/或自上一次软件下载所流逝的时间）、里程表读数、维修保养数据等。车辆数据收集模块108与车载计算机系统102的多个元件通信以在请求软件数据的安排频率的构造和/或调节期间获得并传输所请求的信息。

 通信模块110被合适地构造成建立在车载计算机系统102和一个或多个远程服务器之间的连接并传输数据。如下面更具体地描述的，由通信模块110接收的数据可包括与车载计算机系统102兼容的可下载的软件数据，这包括软件更新、修订、修正等。由通信模块110提供的数控可包括但不限于下载软件应用程序的请求等。

 在某些实施例中，通信模块110利用无线局域网（WLAN）连接、蜂窝电信网络、和/或短程无线通信协议来建立与远程服务器的连接，从该远程服务器下载软件数据。在一些实施例中，通信模块110被实施为车载车辆通信或远程信息处理系统，例如由OnStar?公司商业上市场推广并销售的OnStar?模块，其是即时应用的受让人，目前总部在密歇根州底特律城的通用汽车公司的子公司。在通信模块110是OnStar?模块的实施例中，内部收发器能够提供双向移动电话语音和数据通信，这被实施为码分多址连接方式（CDMA）。在一些实施例中，其他的3G技术可被用于实施通信模块110，包括但不限于： 通用移动通信系统（UMTS）宽带CDMA（W-CDMA）、增强型数据速率GSM演进技术（EDGE）、演进的EDGE、高速分组接入（HSPA）、CDMA2000等。在一些实施例中，其他的4G技术可单独地或者与3G技术组合地被用于实施通信模块110，这包括但不限于： 演进的高速分组接入（HSPA＋）、长期演进（LTE）和/或长期演技-高级（LTE-A）。

 软件请求和下载模块112被合适地构造成询问软件数据是否变为能够获得并下载，以及获得用于车辆车载计算机系统102的可获得的软件数据。在某些实施例中，可下载的软件数据包括可应用于车辆100内的一个或多个电子控制单元（ECU）的软件更新信息。在其他的实施例中，可下载的软件数据包括适合于能实现车辆车载计算机系统102的具体特征的软件，例如与现存的车辆100特征相关联的可下载软件应用程序和/或增强的功能。例如，软件可被下载以更新车辆用户指南，使得能使用车辆上的免提特征操作新版本的蜂窝电话等。

 一般而言，使用“下拉”方法来获得车辆车载计算机系统102的软件数据。利用这个方法，车辆车载计算机系统102将直接向一个或多个远程服务器提交请求以确定软件数据的下载可获得性。这些请求通过无线通信连接（由通信模块110建立）传输。

 软件请求和下载模块112根据由软件请求安排模块114确定的安排频率请求可获得的软件数据以下载到车辆车载计算机系统102。软件请求安排模块114被构造成确定并设置用于从一个或多个远程服务器请求可下载的软件数据的定期频率。

 车辆车载计算机系统102发送下载可获得的软件数据的请求的默认频率是预定的，并且这个频率被保存在系统存储器106内以在车辆100及其相关联的车载计算机系统102的整个寿命中使用。软件请求安排模块114基于车辆100的使用年限和车载计算机系统102最近是否被更新来调节这个默认频率。应该意识到，软件请求安排模块114可还被构造成基于其他因素、标准、度量等改变默认的探询频率。一般而言，软件请求安排模块114，其与车辆数据收集模块108通信，接收指示在规定时间段内所执行的点火循环的次数的数据值。在某些实施例中，规定时间段包括车辆100的整个寿命。在这个示例中，请求软件下载信息的频率由在车辆的寿命期间所执行的点火循环的总次数确定，这指示了车辆的使用年限。在其他的实施例中，车辆的使用年限可使用里程表读数、时间测量、和/或维修保养数据来确定。在一些实施例中，规定时间段开始于由车辆车载计算机系统102所执行的上一次软件下载并结束于当前时间。在这个示例中，请求软件下载信息的频率由自上一次软件下载完成起所执行的点火循环的次数确定，这指示了最近的软件下载的使用时间。

 在软件下载包括软件更新的实施例中，车辆车载计算机系统102在其目前现存软件为“新的”时要求更频繁的软件下载。现存软件在下面两种情况的任一种中都被认为是“新的”： （i）车辆本身是新车，并且因此正被用在车载计算机系统102和/或ECU中的整个软件包是新的，和（ii）刚刚完成向车辆车载计算机系统102的新软件下载或者软件更新。在这些情形中的每一个中，车辆100所正在使用的软件最近刚刚被建立或改变，并且软件中错误、缺陷、或者“漏洞”可能还没有被发现。当软件问题出现时，更新和修正被开发并变成是可获得的以用于下载。

 当车辆100的使用年限增加并且修订了大多数软件使用问题时，车辆100要求更少的软件更新形式的软件下载。不过，车辆100仍以在系统存储器106中保存的并且在软件寿命循环的开始，即在以更加频繁的方式要求软件更新时就使用的同样的预定或默认频率请求软件下载（在这种情况下，是更新）。软件请求安排模块114根据车辆的使用年限和/或自软件更新被执行后所流逝的时间量来调节（例如，减少）这个频率。

 图2是说明了调节从远程服务器请求软件数据的可变频度的过程200的实施例的流程图。与本文描述的过程200相关地被执行的各种任务可由软件、硬件、固件、或它们的任意组合来执行。出于说明目的，对过程200的描述可参考上面在图1中提及的元件。实践中，所描述的过程的多个部分可由所描述的系统的不同的元件执行，例如，系统固件、在车辆车载计算机系统中的逻辑、或系统中的其他逻辑。应该意识到，所描述的过程可包括任意数量的额外的或替换的任务，在附图中示出的任务不一定按照图示的顺序被执行，并且所描述的过程可包含在更综合的程序或过程中，其具有未在本文中具体描述的额外功能。而且，在附图中示出的任务中的一个或多个可从所描述的过程的实施例被省略，只要所想要的整个功能保持完整。

 为了便于描述和清楚，本示例假设过程200在车辆点火循环被执行时（步骤202）开始，或者换句话说，当车辆被通电且发动机被起动时开始。在某些实施例中，可在点火装置中使用钥匙来执行车辆点火循环，以及在其他实施例中，按钮起动或者其他点火技术可被使用。在此时，过程200开始读取内部点火循环计数器，其被用于跟踪自已经执行了车辆的上一次软件下载以来所执行的点火循环的次数。在其他的实施例中，过程200开始读取内部时钟、里程表、或者其他传感器装置以获得相关的车辆数据。

 点火循环计数器通过每次下载软件数据都被重置（即，设置为零）而操作，这可发生在过程300的末尾（在图3中示出）。在过程200的开始，当点火循环被执行时，检索点火循环计数器，以确定何时执行了上一次的软件下载。如果在上一次点火循环期间已经下载了软件数据，那么点火循环计数器就已经被重置为零，并且过程200开始读取零值。一旦读取了点火循环计数器，它就被增加，以“计数”刚刚已经被执行的当前点火循环。

 过程200通过比较当前点火循环计数器值和阈值来确定在上一次点火循环期间在车辆被关停（步骤204）之前是否被执行了软件下载。在某些实施例中，阈值被设置为二，并且点火循环计数器反映了最近的软件下载（例如，计数器被重置为零）以及最新被执行的点火循环（例如，零值被增加到等于一）。在这个示例中，点火循环计数器值等于一，这小于阈值二。当点火循环计数器值小于阈值时，那么就确定在车辆被关停之前已经执行了软件下载（204的“是”支路），并且过程200使用默认频率来请求软件数据（步骤206）。

 请求软件数据的频率可被定义为在规定时间段内的由车辆车载计算机系统请求从远程服务器下载软件数据的次数。规定时间段被定义并保存在系统存储器内以供过程200使用。默认频率可以是对更新的车辆或者最近已经下载了新软件和/或软件更新的车辆车载计算机系统来说被认为是“正常的”的任何频率。一般而言，更新的车辆或最近已经更新了其软件的车辆将要求更频繁的更新，这是由于在车辆软件中要求修正的错误或“漏洞”的可能性增加。因此，使用默认频率，车辆车载计算机系统将经常地请求软件数据下载。

 当点火循环计数器值大于阈值时，那么就确定在车辆被关停之前没有执行了软件下载（204的“否”支路），并且过程200使用软件数据请求的减少的频率（步骤208）。减小的频率可以是对于更旧的车辆或最近没有下载新软件和/或软件更新的车辆车载计算机系统来说被认为是“正常的”的任何频率。一般而言，更旧的车辆或最近没有更新其软件的车辆不会要求频繁的更新，这是由于在车辆软件中要求修正的错误的可能性降低。换句话说，车辆软件被使用得越长，该软件中的任何错误已经被修正的可能性越大。因此，使用减小的频率，车辆车载计算机系统不会像默认频率那样经常地请求软件数据下载。

 在已经确定了请求软件下载的合适频率后，过程200接着使用该确定的请求频率请求软件下载（过程300，在图3中示出）。第一，过程300确定根据合适的频率是否到了发出软件数据请求（步骤302）的时候了。使用过程200确定合适的频率（在图2中示出）。如果没有到发出软件数据请求的时候（302的“否”支路），那么过程300返回到过程300的开始并且继续监测是否到了发出软件数据请求（步骤302）的时候了。当发出软件数据请求是合适的时过程300进行到下一步骤。

 如果到了发出软件数据请求的时候（302的“是”支路），那么过程300根据默认或调节后的频率开始软件数据请求（步骤304），并且确定软件下载是否是可获得的（步骤306）。一般而言，当新版本或更新已经发布并且在远程服务器被指定为可用于下载时，软件数据就是可获得的以供下载。在某些实施例中，软件数据可能与车辆的付费特征相关联，这在完成购买时才变为是可获得的以供下载。在一些实施例中，软件数据可能与车辆的基于许可的特征相关联，这在授予许可后才变为是可获得的以供下载。

 如果软件下载目前是可获得的以供下载（306的“是”支路），那么软件就被下载（步骤310）。此时，内部点火循环计数器被重置（即，设置为零），使得自上一次软件下载以来的被识别的点火循环的次数是准确的。此时，过程300结束直到车辆被关停且执行另一点火循环以起动车辆。一旦执行了新的点火循环，过程200（在图2中示出）再次开始。

 如果软件数据目前不是可获得以供下载的（306的“否支路”），那么过程结束（步骤308）直到车辆被关停且另一点火循环被执行。点火循环计数器保持其值，并且当新的点火循环被执行时，计数器再被增加。

 图4描绘了根据一些实施例的自上一次软件下载402以来执行的点火循环的次数相对于每时段404的软件数据请求的次数的绘图400。在某些实施例中，一旦在车辆处完成了软件下载，内部计数器就被重置（即，设置为零）。内部计数器在绘图400被记为“I”。在执行下一点火循环时，并且其后的每个点火循环都没有紧随软件下载，那么内部计数器被增加（I＝I＋1）。内部计数器的当前值（I）反映了自上一次软件下载402之后的所执行的点火循环的次数。

 如前面参照图1-3所述的， 在车辆车载计算机系统处定期地从远程服务器请求下载软件数据。在绘图400中使用的时间段是任意的，并且是在过程（在图2中被示出为200）的执行前被选择并设置在车载计算机系统的系统存储器内。这个预先设置的时间段提供了时间度量，条件满足时，在该时间度量上可减少请求下载软件数据的次数。在某些实施例中，当自上一次软件下载402以来所执行的点火循环的次数（I）小于预定阈值时，那么每时段的下载请求的次数是默认频率值，这由恒定的x-值代表。例如，如果阈值被设置为二，并且自上一次软件下载402以来所执行的点火循环的次数（I）是一（例如，开始该过程的当前点火循环），那么每时段的软件请求的次数（F（I））404也是一。在这个示例中，车辆车载计算机系统将以每时段一次请求的频度（F（I））404来请求下载更新的软件数据。绘图部分406和410说明了这一原理。

 在其他实施例中，当自上一次软件下载402以来所执行的点火循环的次数（I）大于预定阈值时，那么每时段的下载请求的次数就等于y值除以内部计数器值（I）。例如，当阈值被设置为二时，并且自上一次软件下载402以来所执行的点火循环的次数是三，那么每时段软件请求的次数（F（I））404就是y值除以内部计数器值（I），或者每时段软件请求的次数404除以自上一次软件下载402以来的点火循环的次数（F（I）/I）。这里，每时段软件请求的次数（F（I））404随着内部计数器值（I）增加而继续降低，产生了图中的线性下跌。绘图部分408和412说明了这一原理。

 在一些实施例中，当每时段软件请求的次数（F（I））404线性下跌超过预定低阈值时，那么每时段软件请求的次数（F（I））404就等于零。一般而言，随着自上一次软件下载402以来的点火循环的次数（I）的增加，进一步要求的软件下载的可能性降低。关于这个概念，当自上一次软件下载402以来的点火循环的次数（I）增加时，Y/I值持续降低。一旦Y/I值已经降低到低于预定低阈值点的点，那么就假设车辆不在要求软件更新，并且将每时段软件请求的次数（F（I））404设置为零。换句话说，当车辆使用年限增加时，可能要求更少的软件下载以实现更新目的，并且当下载更少的软件更新时，车辆将以持续降低的频度（例如，Y/I）请求额外的更新。一旦Y/I值落到预定低阈值点以下，那么车辆将不再请求软件更新。例如，1981年的雪佛兰牌下的雪维特（Chevrolet Chevette）不要求软件下载（以用于更新目的或其他目的）。因为不再会开发软件以考虑到这些更旧的车辆，例如1981年的雪维特，所以再不必从远程服务器请求软件下载。

 技艺和技术在本文中可能是在功能和/或逻辑框部件的方面以及参照可由不同的计算部件或设备执行的操作、处理任务、和功能的符号表示被描述的。这种操作、认为和功能有时被称为被计算机执行、计算、软件实施、或计算机实施。实践中，一个或多个处理器设备可通过在系统存储器中的存储器位置处操纵代表数据位的电信号，以及其它的信号处理来实现所描述的操作、任务和功能。数据位被维持的存储器位置是具有对应该数据位的特定电的、磁的、光的、或其它性质的物理位置。但是，应该意识到附图中示出的各种不同的框部件可以任何数量的构造成执行具体说明的功能的硬件、软件和/或固件部件实现。例如，系统或部件的一个实施例可采用各种集成电路部件，例如内存元件、数字信号处理元件、逻辑元件、查询表等，这可在一个或多个微处理器或其它控制设备的控制下执行多种功能。

 当在软件或固件中实施时，本文描述的系统的各种元件基本上是执行各种任务的代码段或指令。程序或代码段可被存储在处理器可读的介质中或通过传输介质或通信路径由包含在载波中的计算机数据信号传输。“处理器可读介质”或“机器可读介质”可包括能存储或转移信息的任何介质。处理器可读介质的示例包括电子电路、半导体存储器设备、ROM、闪存、可擦除ROM（EROM）、软盘、CD-ROM、光盘、硬盘、光学纤维介质、射频（RF）链接等。计算机数据信号可包括能通过传输介质，例如电子网络信道、光纤、空气、电磁路径、RF链接，传播的任何信号。代码段可通过计算机网络被下载，例如因特网、内联网、LAN等。

 虽然已经在前面的具体描述中给出了至少一个示例性实施例，但应当意识到存在大量的变型。还应意识到，本文描述的一个或多个示例性实施例决不是用来限制所要求保护的主题的范围、应用性、或构造。更确切地说，前面的具体描述将给本领域技术人员提供用于实施所描述的一个或多个示例性实施例的方便的路线图。应该理解，在不脱离由权利要求限定的范围的情况下，可对元件的功能和布置进行各种改变，这包括在提交本专利申请时已知的等同方式和可预见的等同方式。