空中更新的方法和设备与流程

说明性的实施例总体上涉及空中(overtheair)更新的方法和设备。

背景技术：

很多车辆包括远程信息处理单元以及车辆计算系统和车辆信息娱乐系统。这些系统允许集成来自远程源的应用、车辆中的媒体和内容的播放、与远程源的通信，并通常提供更良好的驾驶员体验。这些系统和其它车辆电子控制单元(ecu)可包括例如可更新的软件/固件组件以提供组件之间的兼容性。然而，客户可能需要到访经销商以接收更新和/或将系统扫描以确定更新的软件是否可用。当前的策略可能需要将车辆物理连接至编程系统来由经销商安装更新。这允许经销商确保最新的模块和版本被安装，并允许原始设备制造商(oem)获取安装在车辆上的当前软件和固件版本的简况(snapshot)。

技术实现要素：

在第一说明性实施例中，一种系统包括处理器，所述处理器被配置为：响应于从远程网络接收到的对车辆软件的更新是可用的通知，汇编安装的车辆软件版本的列表。所述处理器还被配置为：将所述安装车辆软件版本的列表发送至远程更新服务器。所述处理器还被配置为：响应于所述发送，接收与所述安装的车辆软件版本兼容的可用更新的列表。此外，所述处理器还被配置为下载所述可用更新中的至少一个并安装下载的更新。

在第二说明性实施例中，一种系统包括处理器，所述处理器被配置为接收应用可用软件更新的车辆识别码(vin)的列表。所述处理器还被配置为针对每个vin确定车辆拥有者是否允许空中(overtheair，ota)更新并向车辆拥有者已经允许空中更新并应用可用软件更新的通过对应的车辆识别码识别的每个车辆发送通知。

根据本发明，提供了一种系统，所述系统包括处理器，被配置为接收应用可用软件更新的车辆识别码(vin)的列表。所述处理器还被配置为针对每个vin确定车辆拥有者是否允许空中(overtheair，ota)更新并向通过车辆拥有者已经允许空中更新并应用可用软件更新的对应的车辆识别码识别的每个车辆发送通知。

根据本公开的一个实施例，所述处理器响应于数据库查询，从包含通过车辆识别码识别的每个车辆的当前安装的软件版本的数据库接收所述列表。

在第三说明性实施例中，一种系统包括一个或更多个处理器，所述一个或更多个处理器被配置为接收软件更新。所述一个或更多个处理器还被配置为向车辆提供通知，并从所述车辆接收软件更新下载请求，其中，针对所述车辆，数据库记录指示应用接收到的软件更新的已安装软件版本。所述处理器还被配置为：响应于所述请求发送所述软件更新，接收包括所述软件更新的安装成功或失败的更新日志，并基于所述更新日志更新所述数据库记录。

附图说明

图1示出了说明性的车辆计算系统；

图2a示出了用于提供车辆软件/固件更新的说明性云端处理；

图2b示出了用于更新处理的说明性车辆侧处理；

图3示出了用于更新通知的说明性处理；

图4示出了另一说明性的更新通知处理；

图5示出了用于召回处理的说明性处理。

具体实施方式

根据需要，在此公开了具体实施例；然而，将理解的是，所公开的实施例仅为要求保护的主题的说明，要求保护的主题可以以各种替代形式来实现。附图不必按比例绘制；一些特征可被夸大或极小化以示出特定组件的细节。因此，在此公开的具体结构和功能细节不应被解释为具有限制性，而仅仅作为用于教导本领域技术人员以多种方式利用要求保护的主题的代表性基础。

图1示出用于车辆31的基于车辆的计算系统(vcs)1的示例框式拓扑图。这种基于车辆的计算系统1的示例为由福特汽车公司制造的sync系统。设置有基于车辆的计算系统的车辆可包含位于车辆中的可视前端界面4。如果所述界面设置有例如触摸敏感屏幕，则用户能够与所述界面进行交互。在另一说明性实施例中，通过按钮按压和/或具有自动语音识别和语音合成的口语对话系统来进行交互。

在图1所示的说明性实施例1中，处理器3控制基于车辆的计算系统的至少一部分操作。设置在车辆内的处理器3允许对命令和程序进行车载处理。另外，处理器连接到非持久性存储器5和持久性存储器7两者。在此说明性实施例中，非持久性存储器是随机存取存储器(ram)，持久性存储器是硬盘驱动器(hdd)或闪存。通常，持久性(非暂时性)存储器可包括当计算机或其它装置掉电时保持数据的所有形式的存储器。这些存储器包括但不限于hdd、cd、dvd、磁带、固态驱动器、便携式usb驱动器和任何其它适当形式的持久性存储器。

处理器3还设置有允许用户与处理器3进行交互的多个不同的输入。在此说明性实施例中，麦克风29、辅助输入25(用于输入33)、usb输入23、gps输入24、屏幕4(其可为触摸屏显示器)和蓝牙输入15全部被设置。还设置有输入选择器51，以允许用户在各种输入之间进行切换。对麦克风和辅助连接器两者的输入在被传送到处理器之前，由转换器27对所述输入进行模数转换。尽管未示出，但是与vcs进行通信的众多车辆组件和辅助组件可使用车辆网络(诸如但不限于can总线)向vcs1(或其组件)传送数据并传送来自vcs(或其组件)的数据。

系统的输出可包括但不限于视觉显示器4以及扬声器13或立体声系统输出。扬声器被连接到放大器11，并通过数模转换器9从处理器3接收其信号。还可分别沿19和21所示的双向数据流产生到远程蓝牙装置(诸如个人导航装置(pnd)54)或usb装置(诸如车辆导航装置60)的输出。

在一说明性实施例中，系统1使用蓝牙收发器15与用户的移动装置53(例如，蜂窝电话、智能电话、pda或具有无线远程网络连接能力的任何其它装置)进行通信(17)。移动装置53随后可用于通过例如与蜂窝塔57的通信(55)来与车辆31外部的网络61进行通信(59)。在一些实施例中，蜂窝塔57可以是wifi接入点。

移动装置和蓝牙收发器之间的代表性通信由信号14表示。可通过按钮52或类似的输入来指示将移动装置53与蓝牙收发器15配对。相应地，cpu被指示车载蓝牙收发器将与移动装置中的蓝牙收发器进行配对。

可利用例如与移动装置53关联的数据计划、话上数据或dtmf音在cpu3与网络61之间传送数据。可选地，可期望包括具有天线18的车载调制解调器63，以在cpu3与网络61之间通过语音频带传送数据(16)。移动装置53随后可用于通过例如与蜂窝塔57的通信(55)来与车辆31外部的网络61进行通信(59)。在一些实施例中，调制解调器63可与蜂窝塔57建立通信(20)，以与网络61进行通信。作为非限制性示例，调制解调器63可以是usb蜂窝调制解调器，并且通信(20)可以是蜂窝通信。

在一说明性实施例中，处理器设置有包括用于与调制解调器应用软件进行通信的api的操作系统。调制解调器应用软件可访问蓝牙收发器上的嵌入式模块或固件，以完成与(诸如在移动装置中发现的)远程蓝牙收发器的无线通信。蓝牙是ieee802pan(个域网)协议的子集。ieee802lan(局域网)协议包括wifi并与ieee802pan具有相当多的交叉功能。两者都适合于车辆内的无线通信。还可使用自由空间光通信(诸如irda)和非标准化消费者红外协议。

在另一实施例中，移动装置53包括用于语音频带或宽带数据通信的调制解调器。在话上数据的实施例中，当移动装置53的拥有者可在数据被传送的同时通过装置说话时，可实施已知为频分复用的技术。在其它时间，当拥有者没有在使用装置时，数据传送可使用整个带宽(在一示例中是300hz至3.4khz)。尽管频分复用对于车辆与互联网之间的模拟蜂窝通信而言会是常见的并仍在被使用，但其已经在很大程度上被用于数字蜂窝通信的码域多址(cdma)、时域多址(tdma)以及空域多址(sdma)的混合体所替代。在另一实施例中，移动装置53被安装至车辆31的蜂窝通信装置(未示出)所替代。在另一实施例中，移动装置(nd)53可以是能够通过例如(而不限于)802.11g网络(即，wifi)或wimax网络进行通信的无线局域网(lan)装置。

在一实施例中，传入数据可经由话上数据或数据计划通过移动装置，通过车载蓝牙收发器，并进入到车辆的内部处理器3。例如，在特定临时数据的情况下，数据可被存储在hdd或其它存储介质7上，直至不再需要所述数据时为止。

可与车辆进行接口连接的其它源包括：具有例如usb连接56和/或天线58的个人导航装置54、具有usb62或其它连接的车辆导航装置60、车载gps装置24、或具有连接到网络61的能力的远程导航系统(未示出)。usb是一类串行联网协议中的一种。ieee1394(火线^tm(苹果)、i.link^tm(索尼)和lynx^tm(德州仪器))、eia(电子工业协会)串行协议、ieee1284(centronics端口)、s/pdif(索尼/飞利浦数字互连格式)和usb-if(usb开发者论坛)形成了装置-装置串行标准的骨干。多数协议可针对电通信或光通信来实施。

此外，cpu可与各种其它的辅助装置65进行通信。这些装置可通过无线连接67或有线连接69被连接。辅助装置65可包括但不限于个人媒体播放器、无线保健装置、便携式计算机等。

另外或可选地，可使用例如wifi(ieee803.11)收发器71将cpu3连接到基于车辆的无线路由器73。这可允许cpu3连接到在本地路由器73的范围内的远程网络。

除了由位于车辆中的车辆计算系统执行代表性处理之外，在某些实施例中，还可由与车辆计算系统通信的计算系统来执行所述处理。这样的系统可包括但不限于无线装置(例如但不限于，移动电话)或通过无线装置连接的远程计算系统(例如但不限于，服务器)。总体上，这样的系统可被称为与车辆关联的计算系统(vacs)。在某些实施例中，vacs的特定组件可根据系统的特定实施而执行处理的特定部分。通过示例而并非限制的方式，如果处理包括与配对的无线装置进行发送或者接收信息的步骤，则很可能由于无线装置不会与其自身进行信息的“发送和接收”而使得无线装置不执行处理的该部分。本领域的普通技术人员将理解何时不适合对给定解决方案应用特定的计算系统。

在此讨论的每个说明性的实施例中，示出了可由计算系统执行的处理的代表性的、非限制的示例。关于每个处理，执行处理的计算系统为了执行处理的有限目的而可以变成被配置为专用处理器以执行处理。所有的处理不需要被全部执行，并被理解为可被执行以实现发明的要素的处理类型的示例。可根据需要在示例性处理中添加额外的步骤或者移除额外的步骤。

虽然当前车辆计算系统允许通过经销商界面完成软件和固件的更新，但是这种系统还需要客户到访经销商或其它许可的服务提供商。由于客户经常要等到车辆需要物理维修、车辆应该进行机油更换或轮胎调位或者客户不能使软件一同被更新，因此这将导致获取更新的延迟。由于软件和固件更新经常提升性能，因此客户可能无法从他们的车辆获取完整的最优体验，除非他们特别注意保持它们的软件是最新的，保持它们的软件是最新的处于经销商更新模式下，可能需要为了更新而经常去往经销商或维修地点。

说明性的实施例提供了用于获取空中(over-the-air，ota)更新的代表性系统和方法，所述系统和方法允许客户更新车辆软件而不需要到访经销商。提出的方案和示例提供了有效且可靠的具有最少的用户交互和影响的更新车辆软件和固件的手段。此外，oem可跟踪对哪些车辆提供和/或应用了哪些更新，因此，可以良好地感知到哪些软件和固件版本在部署的车辆中非常普遍，从而可帮助专注于更新工作和允许早期的问题识别，以及在例如出现任何特定版本的问题的情况下通知适当的相关方。

图2a示出了用于提供车辆软件/固件更新的说明性的云端处理。关于在该图中描述的说明性实施例，应注意，通用处理器可临时作为专用处理器以用于执行在此示出的示例性方法中的一些或全部的目的。当执行提供指令的代码以执行所述方法的一些或全部步骤时，处理器可被临时转用为专用处理器，直到方法完成时为止。在另一示例中，在适当的程度上，根据预配置的处理器运行的固件可使处理器作为用于执行所述方法或其一些合理变型的目的的专用处理器。

在这个说明性示例中，oem工程师或被指定提供软件和固件更新的其它方可将软件上传至初始系统资源库(诸如被指定为从一方或更多方接收更新的车内软件系统(in-vehiclesoftwaresystem，ivs))。这些文件随后被发送至全球车内信息系统(globalin-vehicleinformationsystem，givis)，软件可被存储在全球车内信息系统(givis)中以用于通过车辆工具下载。在givis系统从ivs系统接收到软件之后(操作201)，givis系统可将软件推送给云(操作203)，在所述云中，软件可被提供至远程连接的车辆远程信息处理控制单元(telematiccontrolunit，tcu)。

除了将文件推送至云(或者以其它方式使文件无线可用)，givis系统还可告知服务传输网络(sdn)以通知特定车辆对安装的软件或固件包的更新可用于下载和安装(操作205)。

在说明性的实施例中，后台的oem系统跟踪哪些模块和版本被安装在允许ota更新的各种车辆上。这种信息可从例如车辆tcu接收和存储在远程oem数据库中。对于配置已知的车辆，sdn可识别哪些车辆适合更新(基于已知的安装的软件和固件版本)，并可向那些车辆发送新的安装包已经准备好被下载的消息。对于还未报告的其它车辆，例如，系统可基于初始构造针对更新识别车辆，并且还可通知这些系统。在这个示例中，由于处理将在提供更新之前检查安装的软件，因此当系统被通知实际配置时，任何不兼容性均可被处理。

由于识别的车辆联机(例如，而非限制，它们是启动的)，因此它们可基于例如来自sdn的通知登入更新服务器。系统接收登记(操作207)以及安装在车辆上的软件和固件的清单(操作209)。这可以是完整的列表，或者，在另一示例中，可与被指定更新的软件包和固件包特别相关。完整的列表将向oem提供车辆的当前简况，但简短的列表可花费更少的时间来汇编和发送。报告可基于传输时间、完整性、数据量等之间的权衡来按照需要被配置。

一旦从车辆接收到清单(操作209)，处理可确定哪些软件和固件适合更新，并汇编可用更新的列表(操作211)。识别可用于下载的可更新的软件/固件和/或版本的更新清单随后可被发送至车辆(操作213)。如图2b所示，所述车辆将下载适当的软件，在适当的时候安装软件更新。一旦软件更新被成功安装，处理就将接收识别多个更新的安装成功或失败的状态日志(操作215)。这可在稍后的时间进行，这是因为例如下载可能发生在启动时而安装可能发生在关闭时(当车辆没有被使用时)。远程系统可随后存储安装的软件版本和固件版本中的部分或全部的更新的简况(取决于在初始的清单和更新状态日志中提供了多少数据)(操作217)。

图2b示出了用于更新处理的说明性的车辆侧处理。关于在该图中描述的说明性实施例，应注意，通用处理器可临时作为专用处理器以用于执行在此示出的代表性方法中的一些或全部的目的。当执行提供指令的代码以执行所述方法的一些或全部步骤时，处理器可被临时转用为专用处理器，直到方法完成时为止。在另一示例中，在适当的程度上，根据预配置的处理器运行的固件可使处理器作为用于执行所述方法或其一些合理变型的目的的专用处理器。

在这个说明性示例中，处理是车辆侧的处理，所述处理不必没有暂停地运行至完成(即，在特定步骤之间可以存在明显的时间间隙)。车辆通常通过车辆tcu被通知更新的软件包可用于该车辆(操作221)。例如，这种sdn通知可被用于使车辆处于当车辆下一次启动时所述车辆将检查更新的状态。

在启动时，响应于sdn通知，或者在另一合适的时间，处理将生成安装在车辆上已有的软件和固件版本的清单(操作223)。这可以是软件和固件的完整列表，或者例如可被限制为更新可用于的软件和固件的版本。第三个列表的示例可以是可更新的软件和固件的版本，以及兼容性目的所需的其它模块的版本(例如，尽管模块z不可更新，但针对模块n的更新，模块z必须处于2.0.1版本以保持兼容性，因此模块z和n两者的版本都可被提供)。随后，再次处于启动或其它指定时间时，处理将登入givis云(或其它提供服务的软件/固件)(操作225)以获取更新的软件。

处理将安装的版本的清单发送至givis系统(操作227)，允许givis系统检查以确保安装的软件的数据库记录是正确的。如果车辆系统具有非预期的更新的版本(例如用户可能已经手动安装更新的版本)，则更新可被放弃，或被改变为不同的版本。一旦更新的适当性被验证或修正，则车辆系统将接收到包含可用于下载的可更新的软件模块的列表的清单(操作229)。

车辆系统随后将下载合适的更新(可以是全部更新，或者一些系统或用户从全部更新中选择的子集)(操作231)。更新也将在某些时候被安装(操作233)，但是如之前提到的这可以发生在不同的时间。由于对车辆模块的更新可能在安装的同时影响驾驶性，因此，可能希望在安装更新之前等到车辆不被使用时(诸如关闭时)。在另一示例中，为了快速更新，系统可在实施更新时在有线的时间段内阻止驾驶。后一种模式可例如在高优先级的安全更新被下载以用于安装时被使用，或者在任意其它合适的时间被使用。一旦更新被安装，则处理可向givis系统发送更新后的日志(操作235)，所述更新后的记录可包括更新成功或失败，并且如果需要使关于当前车辆配置的信息尽量多，则所述更新后的记录还可包括当前安装的软件和固件模块的另一完整列表。

尽管未示出，但是例如处理还可记录或记载对车辆的特定软件版本更新的传输。例如，这可有助于在车辆重复接收更新版本但当尝试更新时不能成功应用所述更新时，识别更新问题。

图3示出了用于更新通知的说明性处理。关于在该图中描述的说明性实施例，应注意，通用处理器可临时作为专用处理器以用于执行在此示出的示例性方法中的一些或全部的目的。当执行提供指令的代码以执行所述方法的一些或全部步骤时，处理器可被临时转用为专用处理器，直到方法完成时为止。在另一示例中，在适当的程度上，根据预配置的处理器运行的固件可使处理器作为用于执行所述方法或其一些合理变型的目的的专用处理器。

在这个说明性示例中，处理运行在服务传输网络或被指定为向车辆通知新更新的可用性的其它通信系统上。在这个示例中，处理接收(或检索)被特定更新影响的车辆的车辆识别码(vin)(操作301)。

每个车辆的软件和固件配置被存储在数据库中，可使用多种源(源于车辆报告、经销商报告、生产时的已知的安装版本等)填充和更新所述数据库。例如，数据库可被查询以识别被安装了软件n的特定版本的车辆，诸如具有例如2.0.3版本的车辆，新更新2.0.4将被应用在该车辆上。在另一示例中，版本为2.0.3或版本低于2.0.3的所有车辆根据例如特定更新可被识别为更新至2.0.4的候选车辆。

车辆可通过vin被识别，vin可被用于查找允许消息被发送至特定的vin被识别的车辆的通信数据。在这个示例中，为了防止通知不想要ota更新的用户，处理检查每个vin以查看用户是否同意ota更新(操作303)。不在数据库中的vin可对应于不允许ota更新的用户，或者对应于由于多种原因不想要ota更新的用户(诸如想要所有车辆处于相同版本水平的车队经理)。如果给定的vin具有与此相关的许可(操作305)，则sdn可将该vin添加至列表以用于通知(操作307)。只要vin保留以用于许可验证(操作309)，该处理就可继续。一旦允许ota更新的vin已经被验证，则处理可向具有关联的vin的车辆发送更新指令、通知等(操作311)。

图4示出了另一说明性的更新通知处理。关于在该图中描述的说明性实施例，应注意，通用处理器可临时作为专用处理器以用于执行在此示出的示例性方法中的一些或全部的目的。当执行提供指令的代码以执行所述方法的一些或全部步骤时，处理器可被临时转用为专用处理器，直到方法完成时为止。在另一示例中，在适当的程度上，根据预配置的处理器运行的固件可使处理器作为用于执行所述方法或其一些合理变型的目的的专用处理器。

在这个说明性的示例中，例如，运行在givis上的处理从oem工程师或被指定提供更新的其它方接收更新文件(操作401)。在这个示例中，givis存储车辆配置的记录(或者访问存储记录的数据库)，并仅向sdn提供可应用的vin的列表以用于通知(该处理是参照图3描述的代表性处理)。这里，处理利用数据库来(在这个示例中，通过vin)确定哪些车辆具有符合接收的更新的条件的软件(操作403)。在这个示例中，处理首先根据软件模块分类(操作403)，以确定哪些车辆被安装了可更新的模块。随后，针对每个车辆，处理确定软件是否已经被更新(操作405)，或者处于不适合更新的状态。如果所述软件已经被更新或者处于不适合更新的状态(操作405)，则处理将继续下一个记录(操作409)。否则，该车辆的vin被添加至将被发送至sdn的更新列表(操作407)。当然，由于示出的处理仅是说明性的，因此查询数据库和汇编记录的列表的任意方法可被使用。一旦分析了所有记录，则处理可向sdn发送合适的vin的列表(操作411)，如图3所示，sdn可检查存储的ota许可。尽管图4中的givis处理和图3中示出的ota许可验证相对于分开的系统被描述，但如果需要并且合适，根据提供ota软件更新的后台网络的布局和配置，givis处理和ota许可验证可被合并。

图5示出了用于召回处理的说明性处理。关于在该图中描述的说明性实施例，应注意，通用处理器可临时作为专用处理器以用于执行在此示出的示例性方法中的一些或全部的目的。当执行提供指令的代码以执行所述方法的一些或全部步骤时，处理器可被临时转用为专用处理器，直到方法完成时为止。在另一示例中，在适当的程度上，根据预配置的处理器运行的固件可使处理器作为用于执行所述方法或其一些合理变型的目的的专用处理器。

图5示出了通过具有当前安装的软件和固件版本的更加新的记录来促进的说明性的召回通知处理。尽管所述处理可利用报告安装在车辆中的软件和固件版本的任意记录集来被使用，但记录越新，召回通知的传输越精确。例如，如果oem不具有关于当前软件版本的任何信息，则oem必须向具有需要特定更新的一些版本的特定软件或固件模块的所有车辆型号发送召回通知。另一方面，如果更新仅应用于例如3.3.1版本，则完整的或更完整的记录集可避免向不适合的至少一部分车辆发送召回通知。对于当前配置是未知的车辆，或者对于更新已经过去很长时间的车辆，处理可出于慎重考虑仍然选择发送通知。然而，处理可避免向已知更新已经被应用和/或具有需要更新的版本之后的版本(例如版本3.3.2)的车辆发送通知。

处理接收应用于安装在特定车辆中的特定软件或固件模块的召回通知(操作501)。通过如上所述地使用数据库查询，处理可识别已知哪些车辆需要更新，或者另外地或可选地，哪些车辆不需要更新(操作503)。处理可随后汇编应对其发送通知的vin的列表(或者在可选的配置中，肯定不需要通知的vin的列表)(操作505)。这两种形式的列表可被用于限制向其发送通知的车辆的列表，因此，至少一些驾驶员不需要被通知不应用到他们的车辆上的召回。召回通知可随后被发送至合适的车辆(操作507)。

如提到的，基于不完整的信息，使用该处理仍然存在一些通知的重复和冗余，但是，例如从客户车辆和经销商更新接收的信息越好，召回通知的定向越精确。基于已知哪些模块和版本被安装在哪些特定车辆上，类似的方法还可被用于其它的目标车辆的消息传送。由于ota更新允许在不需要客户到访经销商的情况下更频繁地维护软件和固件模块，因此，如果这些信息由oem采集，则增加的频率可提供提升的简况精确度。

虽然以上描述了示例性实施例，但这些实施例并不意在描述本发明的所有可能形式。更确切地，说明书中所使用的词语是描述性词语而非限制性词语，并且应理解的是，可在不脱离本发明的精神和范围的情况下做出各种改变。此外，可将各种实施的实施例的特征进行组合以形成本发明的进一步的实施例。