用于点火状态监测的方法和设备与流程

示意性实施例总体上涉及用于点火状态监测的方法和设备。

背景技术：

随着车辆变得越来越依赖于软件，对各种车辆系统上的软件的不断更新的需求持续增长。当车辆以及具有可更新软件的限制的车辆中存在限制的软件包时，原始设备制造商(oem)可依赖于经销商安装的更新。客户还可能具有用于下载更新并且手动安装更新的选项，但是在早期阶段限制的软件范围限制了更新的需求和重要性。

随着车辆软件系统的发展，按需更新正变为更为紧迫的问题。该问题的一种常用解决方案涉及通过空中(ota)更新进行发送，这允许将新的软件包传送给任何具有远程连接能力的车辆。这种系统提供接近连续的更新能力，并且帮助使车辆保持实时更新以及用户满意度。

由于软件更新在车辆中进行，所以存在关于通常在特定时间指示更新的可行性的若干考虑。当下载文件时，车辆通常需要处于点火开关接通或启动的状态。在大多数情况下，这将有助于到软件提供服务器的开放远程连接。如果服务器认为车辆处于正确的状态，则服务器可发送大的更新，这在一些情况下会花费大量的时间来进行下载。如果服务器不知道点火状态或者关于点火状态的错误，则部分或全部传输可能会失败。此外，由于车辆状态可随驾驶员的使用而波动，所以可能难以信赖基于先前检测和广播的状态的与预测的车辆状态有关的旧信息。

技术实现要素：

在第一示意性实施例中，一种系统包括处理器，所述处理器被配置为：除非环境干扰或车辆通信装置故障，否则保持与车辆通信装置的持续连接。所述处理器还被配置为：从车辆通信装置接收指示点火状态改变的数据包，并且基于所述数据包来确定当前车辆点火状态。

在第二示意性实施例中，一种系统包括处理器，所述处理器被配置为确定更新对于车辆是可用的。所述处理器还被配置为：向车辆看门狗处理查询当前车辆点火状态，所述车辆看门狗处理被设计为在不存在环境干扰或硬件故障的情况下保持持续的车辆连接。所述处理器还被配置为：响应于从车辆看门狗处理接收到关于当前车辆点火状态与被指定用于有效载荷传送的状态相匹配的指示，传送数据有效载荷。

在第三示意性实施例中，一种计算机实现的方法包括：在不存在环境干扰或车辆通信装置故障的情况下，保持与车辆通信装置的持续连接。所述方法还包括：从车辆通信装置接收指示点火状态改变的数据包，并且基于所述数据包来确定当前车辆点火状态。

根据本发明的一个实施例，被指定用于有效载荷传送的车辆点火状态包括点火接通状态。

根据本发明的一个实施例，被指定用于有效载荷传送的车辆点火状态包括附件开启状态。

根据本发明的一个实施例，被指定用于有效载荷传送的车辆点火状态包括点火断开状态。

根据本发明的一个实施例，数据有效载荷包括软件更新包。

根据本发明的一个实施例，所述方法还包括：接收对成功的有效载荷传送的确认，并且将所述确认记录在指示车辆软件状态的记录中。

附图说明

图1示出了示意性车辆计算系统；

图2示出了点火状态报告处理的示意性示例；

图3示出了传送指令处理的示意性示例；

图4示出了更新确认处理的示意性示例。

具体实施方式

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

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

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

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

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

在一个示意性实施例中，系统1使用蓝牙收发器15与用户的移动装置53(例如，蜂窝电话、智能电话、pda或具有无线远程网络连接能力的任何其它装置)进行通信(17)。移动装置随后可被用于通过例如与蜂窝塔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(applicationprograminterface，应用程序接口)的操作系统。调制解调器应用软件可访问蓝牙收发器上的嵌入式模块或固件，以完成与(诸如，在移动装置中发现的)远程蓝牙收发器的无线通信。蓝牙是ieee802pan(个域网)协议的子集。ieee802lan(局域网)协议包括wifi并与ieee802pan具有相当多的交叉功能。两者都适合于车辆内的无线通信。可在本领域使用的另一通信方式是自由空间光通信(诸如，irda)和非标准化消费者红外(ir)协议。

在另一实施例中，移动装置53包括用于语音频带或宽带数据通信的调制解调器。在话上数据的实施例中，当移动装置的拥有者可在数据被传送的同时通过装置说话时，可实施已知为频分复用的技术。在其它时间，当拥有者没有在使用装置时，数据传送可使用整个带宽(在一个示例中是300hz至3.4khz)。尽管频分复用对于车辆与互联网之间的模拟蜂窝通信而言会是常见的并仍在被使用，但是其已经在很大程度上被用于数字蜂窝通信的码域多址(cdma)、时域多址(tdma)、空域多址(sdma)的混合体所替代。如果用户具有与移动装置53关联的数据计划，则所述数据计划可允许宽带传输并且系统可使用宽得多的带宽(加速数据传送)。在另一实施例中，移动装置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将cpu连接到基于车辆的无线路由器73。这可允许cpu在本地路由器73的范围内连接到远程网络。

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

在在此讨论的示意性实施例中的每一个实施例中，示出了可由计算系统执行的处理的示例性的、非限制性的示例。针对每个处理，执行处理的计算系统出于执行处理的有限目的而变成被配置为专用处理器以执行处理是可行的。所有的处理不需要全部被执行，并且应被理解为是可被执行以实现本发明的要素的多种类型的处理的示例。可根据需要向示例性处理添加额外的步骤或者从示例性处理去除额外的步骤。

针对在示出示意性处理流程的附图中描述的示意性实施例，应注意的是，通用处理器可被临时用作专用处理器，以用于执行通过这些附图示出的部分或全部示例性方法的目的。当执行提供用于执行所述方法的部分或全部步骤的指令的代码时，处理器可被临时改用作专用处理器，直到所述方法完成时为止。在另一示例中，在适当的程度上，根据预先配置的处理器运行的固件可使得处理器充当为了执行所述方法或所述方法的某种合理变型的目的而被提供的专用处理器。

远程信息处理和连接的服务向车辆计算机提供各种功能。远程信息处理系统的一种用途是经由空中(ota)更新来更新车辆软件。这些更新通常基于原始设备制造商(oem)指定的参数而被下载和安装，所述参数可包括对点火状态的引用。不同的模型可被用于ota更新的下载和安装，并且许多模型基于当前车辆点火状态来实施处理的一个方面。

在现有模型中，车辆使用sms(shortmessagingservice，短消息服务)将点火状态传送到负责管理更新的后台服务器。然而，使用sms存在潜在的问题，诸如sms传送并不总是得到保证的事实。此外，sms可具有与sms关联的传送时延，前述的两种因素均可导致关于实际点火状态的不确定性。如果基于云的更新管理系统基于点火状态实施用于发送二进制文件(用于更新车辆模块的文件)的下载指令，则对于所述管理系统而言知道当前的点火状态是有用的，使得下载可根据需要被启动或中断。

当系统使用sms时，当前状态报告可被延迟或者甚至无法被传送，这在后台可产生实际上并不反映当前点火状态的车辆点火状态预期。例如，可能由于电路交换失败而发生所述失败，由此存在不足的电路交换信道来发送sms消息，不足的电路交换信道会延迟或中断用于向远程服务器(所述远程服务器依赖于sms消息)通知当前点火状态的sms消息。由于在远程更新服务器端对当前车辆点火状态的错误理解，所以这会导致更新最终失败。

这种情况实际上产生了许多与更新有关的无目的的事务，其中，更新服务器实质上被迫发送盲目的更新并且希望由最近一次成功的sms消息报告的车辆点火状态仍为当前点火状态。

图2示出了点火状态报告处理的示意性示例。在该示例中，在201，处理在车辆与云之间建立连接。该连接是始终在线连接，并且可被意图用于仅在环境变量(没有可用于连接的信号)指示连接无法被保持时被中断。这可以是在用户处于停车场内的深处或者以其它方式无法访问蜂窝连接选项或其它远程连接选项时的情形。

如果在203信号丢失，则在205，处理将循环以检查任何将允许连接被重新建立的可用连接选项。如果连接可用以及当连接可用时，处理再次重新连接两个实体(车辆和云)，使得连接尽可能地持续保持。

危险的低电力状态和其它驾驶员经验相关的考虑可能是连接为什么会断开的其它原因，在这些情况下，一旦驾驶员影响的可能性被减轻(例如，车辆电池被充分地充电)，则连接就会重新建立。如果在207处理遇到很有可能影响驾驶员体验的危急状况(所述危急状况可以是oem或驾驶员定义的)，则在209，处理可自动地断开以其它方式可用的连接。例如，这可能是车辆电池电量低，或者针对不同的驾驶员请求需要附件或本地电力。只要在211危急状况持续存在，处理就不重新连接。一旦危急状况结束，则处理可将车辆重新连接到云。

当处理被连接时，在215，处理使用包数据来报告任何在213检测到的点火状态改变。该报告是接近即时的，并且将能够具有传送保证(在连接被建立的情况下)以及准确性保证(这是因为在点火状态改变的情况下报告可被连续和快速地发送)。这允许远程系统在确信报告的状态数据准确地反映车辆点火状态的情况下对车辆更新进行操作。

图3示出了传送指令处理的示意性示例。在该示意性示例中，在301，处理检测软件更新可用、确定软件更新可用、被通知软件更新可用等。在303，处理随后与看门狗服务器进行通信，看门狗服务器由于与车辆计算系统持续连接而能够确定当前点火状态。

如果在305处理确定车辆点火处于接通，则在307，处理开始传送更新。如果车辆点火状态在任何时间点改变，则处理可立即被通知关于状态改变，并且可暂停更新。这允许处理知道有多少更新是以一定程度的准确性被传送，并且至少在处理尝试更新时，确保点火状态处于“接通”。

图4示出了更新确认处理的示意性示例。在该示例中，在401，处理再次检测更新，或者被通知更新的存在。在403，处理随后与看门狗服务器进行通信，以确定车辆的当前点火状态。

再次，由于看门狗服务器与车辆持续连接，所以当处理询问时，服务器将得知点火状态是否处于“接通”。如果在405点火处于接通，则在407，处理将传送任何相关数据(例如，更新)。

此外，在该示例中，车辆端的处理可在更新完成时进行响应。如果在409更新处理接收到用于确认成功更新传送的肯定响应，则在411，处理随后记录成功传送。处理随后指示车辆安装更新，并且在413，提交在处理端登记的更新，以指示更新被传送并且被安装在车辆中。只要处理(随着时间)具有需要安装的更新，上述处理就可重复执行，这可在车辆的寿命中一直持续进行。

依靠sms消息进行状态指示的系统的另一个可能的问题是：如果运营商重新定位频谱，则这可能会导致网络拥塞并且引起电路交换失败。或者，例如，如果运营商通过另一种通信技术将格式从sms电路交换转换为sms，则后台服务器可能与新的sms技术不兼容，并且所有sms消息可能失效，直到后台可针对兼容被升级为止。

通过使用由示意性实施例提供的看门狗连接，oem可避免由于错误的点火状态报告而导致的多个失败的传输。这样可显著地削减了无意义的传输(无意义的原因在于点火状态并不是服务器知晓的状态)，并且可节省在通过空中更新进行发送时的时间和成本两者。

尽管上面描述了示例性实施例，但是并不意在这些实施例描述了本发明的所有可能形式。更确切地，说明书中使用的词语为描述性词语而非限制性词语，并且应理解的是，可在不脱离本发明的精神和范围的情况下做出各种改变。此外，可以以逻辑方式组合各种实现的实施例的特征，以产生在此描述的实施例的情境适当的变型。