用于通过无线进行车辆更新的处理器实施系统和方法与流程

本公开总体上涉及车辆通信系统，并且更具体地涉及用于使用车辆通信系统进行软件更新的系统和方法。

背景技术

如今制造的大多数车辆具有多个计算机控制系统。示例包括发动机控制单元或ecu、防抱死制动器、安全气囊和防盗系统。控制这些系统的计算机或处理器可互换地称为嵌入式处理器或嵌入式计算机。它们运行在制造车辆时提供给嵌入式处理器的软件。

可能存在嵌入式计算机的软件可能需要对车辆的寿命进行修改或改进的很多原因。不管原因如何，更新嵌入式处理器的软件通常需要授权服务中心或经销商的特殊设备，或者完全更换嵌入式处理器和/或存储处理器软件的存储器装置。在许多汽车上更新软件可能很困难或昂贵。

因此，期望提供促进以有效且成本有效的方式提供更新的系统和方法。还期望提供用于在不需要或以最小的方式要求使用车辆的蜂窝系统的情况下向车辆提供更新的系统和方法。另外，其它理想特征和特性从以下结合附图和前面的技术领域及背景技术进行的详细描述和所附权利要求中将变得显而易见。

技术实现要素：

提供了用于实现对多台车辆的无线更新的系统和方法。一种方法包括通过通信网络向处于监听状态的多台车辆传输唤醒信号。车辆已经在不同的时间点感测到唤醒信号并且处于接收更新的状态。更新通过wi-fi网络传输到车辆。通过wi-fi网络传输更新包括使用多播循环传输方案来克服车辆的异步通信唤醒。

在其它实施例中，一种方法包括操作唤醒信号以唤醒其wi-fi通信系统使用wi-fi睡眠-唤醒循环的车辆。

一种方法包括wi-fi睡眠-唤醒循环包括车辆的wi-fi被关闭以节省能量的睡眠时段和车辆的wi-fi监听wi-fi信道以检查接收到的数据分组的唤醒时段。

一种方法包括车辆用wi-fi芯片集接收唤醒信号，该wi-fi芯片集可被配置为以低功率模式操作并且跟踪网络地址上的流量。

一种方法包括当接收到数据分组时，wi-fi芯片集切换到正常操作模式并且唤醒wi-fi通信。

一种方法包括后端服务器向每一台车辆传输与车型相关的多播流或数据分组，其中接收到指示车辆已经成功接收到更新的完成状态更新，其中该更新是通过wi-fi网络对未成功接收更新的车辆使用单播传输方案来发送。

一种方法包括多台车辆在车辆装配之后停放在装配场地中或停放在车辆经销商处。

一种方法包括该更新包括用于重新编程多台车辆中的每一台车辆的控制模块或车辆导航地图更新的数据。

一种方法包括唤醒信号和所产生的用于更新的消息被传输到多台车辆而不需要通过蜂窝网络传输，其中所产生的用于更新的消息包括用于指示消息是针对预定车型、车辆装饰和更新类型的数据字段。

一种方法包括通信网络是wi-fi网络或蜂窝通信网络，其中传输更新包括用于指示消息是针对预定车型、车辆装饰和更新类型的数据字段。

一种用于向多台车辆提供无线更新的系统包括：计算机存储装置，其用于存储用于通过通信网络向多台车辆传输的更新；以及一个或多个数据处理器，其被配置为产生用于通过通信网络传输到处于监听状态的多台车辆的唤醒信号。多台车辆已经在不同的时间点感测到唤醒信号并且处于接收更新的状态。该一个或多个数据处理器被配置为产生消息以使用多播循环传输方案通过wi-fi网络向多台车辆传输更新来克服多台车辆的异步通信唤醒。

一种系统包括操作唤醒信号以唤醒其wi-fi通信系统使用wi-fi睡眠-唤醒循环的车辆。

一种系统包括wi-fi睡眠-唤醒循环，其包括车辆的wi-fi被关闭以节省能量的睡眠时段和车辆的wi-fi监听wi-fi信道以检查接收到的数据分组的唤醒时段。

一种系统包括车辆用wi-fi芯片集接收唤醒信号，该wi-fi芯片集可被配置为以低功率模式操作并且跟踪网络地址上的流量。

一种系统包括当接收到数据分组时，wi-fi芯片集切换到正常操作模式并且唤醒wi-fi通信。

一种系统包括后端服务器，其向每一台车辆传输与车型相关的多播流或数据分组，其中接收到指示车辆已经成功接收到更新的完成状态更新，其中该更新是通过wi-fi网络对未成功接收更新的车辆使用单播传输方案来发送。

一种系统包括多台车辆在车辆装配之后停放在装配场地中或停放在车辆经销商处。

一种系统包括该更新包括通信网络是wi-fi网络或蜂窝通信网络，并且该更新包括用于重新编程多台车辆中的每一台车辆的控制模块或车辆导航地图更新的数据。

一种系统包括唤醒信号和所产生的用于更新的消息被传输到多台车辆而不需要通过蜂窝网络传输，其中所产生的用于更新的消息包括用于指示消息是针对预定车型、车辆装饰和更新类型的数据字段。

一种非暂时性计算机可读介质，其上面存储有用于向多台车辆提供无线更新的指令。指令在被执行时使一个或多个数据处理器：产生唤醒信号以通过通信网络传输到处于监听状态的多台车辆。多台车辆已经在不同的时间点感测到唤醒信号并且处于接收更新的状态。该指令还产生消息以使用多播循环传输方案通过wi-fi网络向多台车辆传输更新来克服多台车辆的异步通信唤醒。

附图说明

下文将结合以下附图描述示例性实施例，其中相同标号表示相同元件，且其中：

图1是描绘在一个实施例中用于更新嵌入机动车辆中的软件的系统的框图；

图2是描绘在一个实施例中通过wi-fi网络向车辆无线(ota)传递更新的框图；

图3是描绘了一个实施例中的软件更新操作场景的流程图；

图4描绘了在一个实施例中用于处理车辆的异步唤醒的传输方案；

图5描绘了在一个实施例中用于循环数据传输方案的消息内容；

图6描绘了在一个实施例中用于向车辆发送更新的传输方案；

图7是描绘用于向车辆提供更新的操作场景的流程图；并且

图8是描绘涉及用于处理向车辆提供更新的车辆侧操作的操作场景的流程图。

具体实施方式

以下详细描述本质上仅仅是示例性的，并且不旨在限制应用和用途。另外，不存在被任何前述的技术领域、背景、摘要或以下详细描述中提出的任何明确的或暗示的理论约束的意图。如本文所使用，术语模块是指专用集成电路(asic)、电子电路、处理器(共享、专用或成组)以及执行一个或多个软件或固件程序的存储器、组合逻辑电路和/或提供所述功能性的其它合适部件。

本公开的实施例在本文可以依据功能和/或逻辑块部件和各个处理步骤来描述。应当明白的是，这些块部件可由被配置为执行指定功能的任何数量的硬件、软件和/或固件部件来实施。例如，本公开的实施例可以采用各种集成电路部件(例如，存储器元件、数字信号处理元件、逻辑元件、查找表等，其可以在一个或多个微处理器或其它控制装置的控制下执行多种功能)。另外，本领域技术人员将明白的是，本公开的实施例可以结合任何数量的系统来实践，且本文所述的系统仅仅是本公开的一个示例性实施例。

为了简明起见，本文可以不详细描述与信号处理、数字传输、信令、控制以及该系统(和该系统的单个操作部件)的其它功能方面有关的常规技术。另外，本文所包含的各个图式中所示的连接线旨在表示各个元件之间的示例性功能关系和/或物理联接。应当注意的是，在本公开的实施例中可以存在许多替代或附加的功能关系或物理连接。

图1以100描绘了多个移动平台，例如车辆，其可操作以与根据一个实施例构造的远程系统130进行无线通信。虽然描绘了三台车辆，但是应当理解的是，在其大体邻近处可以有各种建构配置的大量车辆。车辆100各自包括机动车辆，例如汽车，并且如所描绘般在上市之前位于与车辆装配车间170相邻的装配场地中。每一台车辆100配备有通信收发器140(或多个收发器)。远程系统130以信号连接到wi-fi网络175。远程系统130可操作以经由收发器140通过wi-fi网络175与每一台车辆100进行无线通信。车辆100通过wi-fi网络175与远程系统130建立通信以在其间传输电子数据。

如所描绘的车辆100包括在公共高速公路上使用的常规客车，并且如所示般停放在车辆装配车间170附近。应当理解的是，多台车辆共同所处的其它类型的地点可以与本文描述的系统和方法(例如，经销商等)一起使用。每一台车辆100具有被称为vin的唯一标识号，其提供与车辆制造商、包括发动机和变速器配置的车辆属性、型号年份、制造工厂和序列号有关的信息。对于客车，参考如本领域一般技术人员所知的iso标准3779和3780来描述vin。

车辆100的特定元件进一步包括在120处描绘的控制模块(“cm”)。控制模块120可包括具有用于控制车辆的各种操作的数据处理器的一个或多个电子控制装置，并且可不同地配置或者可包含不同的操作和控制算法，这取决于可能需要针对升级、错误修复等进行软件更新的车辆配置。配置差异包括但不限于与以下项有关的差异：不同发动机配置的操作方案、与手动和自动变速器有关的操作方案；以及与两轮驱动和四轮驱动或全轮驱动系统有关的操作方案。这种车辆可被装配在单个装配车间中，从而具有操作和控制算法的变化。通信总线160促进各种电子控制装置与收发器140之间格式化的电子数据的通信。电子控制装置包括可操作以控制车辆操作的各个方面(包括，例如动力系控制、悬架和制动控制以及气候控制(例如，hvac系统))的通用或专用电子装置。

收发器140包括无线通信收发器，其在正常车辆操作期间，每个收发器140适于接收和认证无线信号以及传输信息。存储器存储管理器在适当的时间将格式化的电子数据传送给控制模块120。

当车辆关闭时，例如，由于点火钥匙断开而停放时，收发器140关闭并且吸收最小的电流。在该状态下，它具有最小的功能，主要包括响应唤醒或激活信号的能力。收发器140在激活信号之后的一段时间内激活，并且操作以与远程系统130建立无线通信链路。存储器存储管理器可操作地连接到嵌入式和可移动存储装置以提供数据存储。

远程系统130包括被配备的并且适于与车辆100进行通信的一个或多个独立计算机。远程系统130可经由局域网(例如，专用网络132)或可替换地公共因特网连接到其它计算机装置。远程系统130以信号连接到wi-fi网络175，以在预定条件下经由收发器140与车辆进行无线通信以在其间传输电子数据。wi-fi网络175包括可操作以广播可由收发器140接收和解译的公共电子消息的装置。

在操作中，操作员命令远程系统130与装配场地中的车辆100进行通信，通常传送用于重新编程一个或多个电子控制装置的信息或提供其它类型的更新。

图2以200描绘了用于通过多播wi-fi网络175向车辆100传递无线(ota)更新的系统。在该示例中，车辆100停放在装配车间170并且可被配置为接收更新。这可包括更新位于车辆的软件、固件、控制模块、数据库等中的信息(例如，潜在的大指令集)。示例包括更新车辆导航地图、信息娱乐数据、车辆控制单元和车辆部件。

为了促进更新过程，车辆100处于监听状态以从wi-fi网络175接收数据。可为数据分组的唤醒信号通过wi-fi网络175被传输到车辆100。车辆100感测唤醒信号并且开始接收通过wi-fi网络175传输的无线数据分组。车辆100感测唤醒信号并且开始接收数据传输。然后，更新通过wi-fi网络175在无线数据分组中通过车辆的收发器传输到车辆100。通过该示例中的这种过程，无线程序的连接成本被降低，因为当车辆100停放在停车场时，wi-fi用于唤醒和传输更新，而不需要用于这样的操作的蜂窝连接。

图3是描绘了软件更新操作场景的流程图。在过程框300处，软件更新过程开始。在过程框302处，利用唤醒机制来将车辆置于通信状态以通过wi-fi接收更新。车辆预先被提供有网络信息以识别要监控和连接的wi-fi网络。网络信息可包括ssid(服务集标识符)、密码和多播流信息。信息可作为控制模块的配置的一部分提供，或通过蜂窝(例如，使用onstar)作为唤醒信号的一部分而传递。过程框302可使用不同的方法来执行唤醒操作。例如，唤醒程序可基于车辆的wi-fi睡眠-唤醒循环。wi-fi睡眠-唤醒循环涉及wi-fi被关闭以节省能量的睡眠时段和监听适当的wi-fi信道以检查是否传输数据分组的唤醒时段。

作为另一个示例，唤醒程序可基于wi-fi网络感知(nan)方法，其中车辆的wi-fi芯片集被配置为以低功率模式操作并且跟踪某个ip地址上的流量(例如，单播或多播)。当接收到数据分组时，芯片集切换到正常操作模式并且唤醒整个系统。

在过程框302处完成唤醒程序之后，在过程框304处开始软件更新程序的传输。可使用不同的传输方案，使得尽管车型和装饰不同(例如，识别车辆已装备的不同级别的车辆名称)，但是仍然可针对所有车辆执行软件更新。例如，多个多播流可用于针对每种车型和装饰而格式化的更新。

如果所有车辆已经接收到在判决分支306处确定的更新，则更新过程如过程框308处所指示完成。然而，如果车辆未接收到更新，则可在过程框310处使用诸如单播传输方案等不同传输方案来提供更新。在单播传输情况下，车辆可指示丢失的数据分组，并且服务器可专门传递它们。

图4以400描绘了克服异步车辆唤醒情况的传输方案。在该示例中，为了清楚起见，示出了两台车辆，但是应当理解的是，传输方案涉及许多更多的车辆，诸如停放在装配车间、经销商等处的大量车辆。

时间线栏402指示在404处软件更新被触发之后，发生循环数据传输404。在该示例中，车辆1在与车辆2不同的时间点唤醒，如分别在406和408处所示。车辆1基于循环数据传输404在410处完成其更新，并且车辆2基于这样的传输404完成其更新412。单个循环长度是基于用于传输的分组数量和传输速率(速度)。一个循环结束后，另一个循环开始。可在服务器中配置/控制循环次数。例如，循环可运行直到所有车辆接收到更新。

图5以500说明了数据传输的内容。如在502处所示，每个单独的传输包括“n”个消息。这些消息的传输在预定循环次数(“k次循环”)发生之后停止。如果所有循环已结束，则可为车辆和它们的消息添加附加的一层单播传输。

在504处针对第一消息506示出了循环传输中涉及的消息内容的示例。数据字段508和510指示该消息是针对特定的车型和更新类型。这些字段允许支持多种车型和更新包的并发传输。数据字段512指示该特定消息中的哪个消息编号在预期要接收的消息的总数量之外，如数据字段514中所指示。数据字段516包含消息的实际数据。

图6以600描绘了可发送到车辆以进行软件更新的传输方案。多播传输方案602可包含不同的流以提供不同类型的更新。例如，流606是要传输给车辆的信息娱乐流。流604是也传输给车辆的hvac更新流。多播传输方案602克服了车辆之间的差异，因为多个多播流被配置为是车型所特有的，并且如果需要的话，被配置为是车辆装饰所特有的。每个车型也可使用单个传输方案608。在该方案中，车辆根据分组报头来过滤分组(例如，仅存储相关分组)。

图7描绘了用于向车辆提供更新的操作场景。在过程框700处，触发软件更新过程。这涉及通过通信网络(例如，wi-fi网络或蜂窝通信网络)向处于监听状态的车辆传输唤醒信号。在过程框702处，车辆已经在不同的时间点感测到唤醒信号(例如，异步)并且处于接收更新的状态。

在过程框704处，优化更新循环使得第一优先级是广播传输机制，第二优先级是多播传输机制，并且第三优先级是单播传输机制。可基于更新所需的车辆数量、内容大小、更新次数等在传输之前执行优化。例如，如果只需要更新两台车辆，则系统可选择两个单播传输。如果在判决分支706处确定的所有循环都没有完成，则传输在过程框708处继续直到循环完成。当发生这种情况时，执行检查以查看是否所有车辆已经接收到在判决分支710处确定的更新。该检查可涉及使用代表车辆标识符的vin作为该过程的一部分。如果车辆已经正确地接收到更新，则如过程框714所指示般完成更新循环。然而，如果情况并非如此，则使用不同的传输方案(诸如单播)将更新发送到相关车辆(例如，如用vin识别的车辆)。

图8描绘了用于处理软件更新的车辆操作。在过程框900处，车辆接收唤醒触发。在过程框902处，车辆的wi-fi站连接到适当的接入点(ap)和多播组。如果使用单流传输，则车辆仅接收该流。可在唤醒消息中传递多播数据。如果存在多个流，则唤醒消息可包括关于哪个流涉及哪个更新的数据。另一种选择是车辆接收所有流并过滤与其相关的消息。在过程框904处，触发监听超时，以便执行关于超时是否到期的后续检查。

在过程框906中，车辆监听多播组并且接收数据分组。判决分支908检查下载是否完成。如果有，则处理返回到过程框906。如果监听超时还没有到期，则处理也返回到过程框906，使得车辆能够继续监听多播组。

在下载完成之后，判决分支910检查监听超时是否到期。如果没有，则过程框912在返回到其睡眠序列(过程框914)之前通过wi-fi或蜂窝通信网络向后端服务器传送成功更新。当使用蜂窝通信网络时，连接可产生费用，而wi-fi是免费网络。如果监听超时已经如在判决分支910处所检查的那样过期，则在过程框916处向后端服务器提供关于丢失分组的更新。在过程框918中，利用不同的传输方案使得可通过单播接收分组。如判决分支920确定，在下载完成之后，处理在过程框912处继续进行，在过程框912中，在车辆在过程框914处返回其睡眠序列之前向后端服务器传送更新成功。

然而，如果下载没有完成，则处理在过程框922处继续进行，在过程框922中，向后端服务器传送更新失败。此时，车辆在过程框914处返回到睡眠序列。

虽然前述详细描述中已经提出了至少一个示例性实施例，但是应当明白的是，存在许多变化。还应当明白的是，示例性实施例或多个示例性实施例仅仅是示例并且不旨在以任何方式限制本公开的范围、适用性或配置。实情是，前文详细描述将给本领域技术人员提供用于实施示例性实施例或多个示例性实施例的便捷指引。应当理解的是，在不脱离所附权利要求书和其合法等同物的范围的情况下，可对元件的功能和设置作出各种改变。

作为本文公开的系统和方法的变型的示例，该系统和方法可被配置为对停放在相同区域(例如，工厂停车场)中的大量车辆执行同时的ota软件更新，而不需要消耗昂贵的蜂窝数据或使用昂贵和长期的手动程序。