CN115129340A - 一种整车程序的升级方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种整车程序的升级方法、装置、设备及存储介质，提出了在传统的整车程序升级方法中加入了ECU的判断策略，通过ECU确定当前车辆状态是否可以进行程序的升级，以此来避免异常报错等问题。该方法包括：待升级部件接收到来自OTA云端平台的升级通知后，向ECU发送升级请求；ECU根据所述升级请求检测整车的车速和发动机的转速；基于所述车速和所述转速，生成第一请求响应或者第二请求响应；所述第一请求响应用于指示进行升级，所述第二请求响应用于指示不进行升级；向所述待升级部件发送所述第一请求响应或者所述第二请求响应。

Description

一种整车程序的升级方法、装置、设备及存储介质

技术领域

本申请涉及整车控制技术领域，尤其涉及一种整车程序的升级方法、装置、设备及存储介质。

背景技术

随着整车智能化，车辆上的智能元件的控制器越来越多。同时，针对用户需求的增加以及功能的不断优化，整车控制器和智能元件的程序也需要不断进行优化升级以满足用户需求。相关技术中提出了采用远程升级技术(Over-the-Air，OTA)来进行整车程序的升级。

但是，在升级过程中，升级中的控制器或者智能元件与发动机控制单元(ECU)之间的CAN总线报文交互通信断开。某一个智能元件或者整车控制器与ECU之间的通信断开，可能会导致ECU在根据接收到的报文进行诊断时一些逻辑无法形成闭环，从而导致出现异常报错等问题，也可能会导致升级失败等问题。

发明内容

本申请示例性的实施方式中提供一种整车程序的升级方法、装置、设备及存储介质，用以解决现有的整车程序升级的过程中出现的异常报错等问题。

第一方面，本申请实施例提供了一种整车程序的升级方法，所述方法应用于发动机控制单元ECU，所述方法包括：

接收来自待升级部件的升级请求；

根据所述升级请求检测整车的车速和发动机的转速；

基于所述车速和所述转速，生成第一请求响应或者第二请求响应；所述第一请求响应用于指示进行升级，所述第二请求响应用于指示不进行升级；

向所述待升级部件发送所述第一请求响应或者所述第二请求响应。

基于上述方案，本申请在现有的整车程序升级的架构中增加了ECU的判断策略。相较于现有技术中待升级部件直接根据云端平台的指示进行程序的升级，本申请的方案添加了ECU判断车辆状态是否可以进行升级的步骤。也就是说，待升级部件在接收到来自云端平台的升级通知之后，会进一步通过ECU来确定当前车辆的运行状态是否适合进行升级。若ECU判断可以进行升级，待升级程部件再进行升级。以此避免直接升级对发动机运行的影响，以及直接升级造成的异常报错等问题。

在一些实施例中，所述基于所述车速和所述转速，生成第一请求响应或者第二请求响应，包括：

若所述车速以及所述转速均为零，则生成所述第一请求响应；

若所述车速不为零或者所述转速不为零，则生成所述第二请求响应。

在一些实施例中，所述方法还包括：

在生成所述第一请求响应之后，启动整车静默状态；

其中，所述整车静默状态用于表征所述ECU禁止发动机起动、停止向整车中其他部件发送报文，以及停止对接收到的报文进行故障诊断。

在一些实施例中，所述方法还包括：

在停止对接收到的报文进行故障诊断之后，采用所述整车静默状态的前一时刻接收到的报文进行故障诊断。

在一些实施例中，在生成所述第一请求响应之前，所述方法还包括：

确定所述整车为上电状态，并将上电次数置为1；

在向所述待升级部件发送所述第一请求响应之后，所述方法还包括：

在检测到所述整车重新上电时，将所述上电次数置为2，并关闭所述整车静默状态。

第二方面，本申请实施例提供了另一种整车程序的升级方法，所述方法应用于整车中的待升级部件，所述方法包括：

接收来自云端平台的升级通知，向ECU发送升级请求；

若接收到所述ECU返回的第一请求响应，则从所述云端平台下载新版本的程序并进行数据刷写；

若接收到所述ECU返回的第二请求响应，则返回接收升级通知的步骤，直至接收到所述第一请求响应；

其中，所述第一请求响应和所述第二请求响应是根据整车的车速和发动机的转速确定的。

在一些实施例中，所述方法还包括：

在进行从所述云端平台下载新版本的程序包并进行数据刷写时，采用指示灯的第一亮灯机制；

在完成所述数据刷写时，采用所述指示灯的第二亮灯机制；

其中，所述第一亮灯机制和所述第二亮灯机制不相同。

通过不同的亮灯机制来控制指示灯，以提醒驾驶员区分程序升级过程以及程序升级完成，避免出现异常掉电的问题。

第三方面，本申请实施例提供了一种整车程序的升级装置，包括：

通信单元，用于接收来自待升级部件的升级请求；

处理单元，用于根据所述升级请求检测整车的车速和发动机的转速；

所述处理单元，还用于基于所述车速和所述转速，生成第一请求响应或者第二请求响应；所述第一请求响应用于指示进行升级，所述第二请求响应用于指示不进行升级；

所述通信单元，还用于向所述待升级部件发送所述第一请求响应或者所述第二请求响应。

在一些实施例中，所述处理单元，具体用于：

在所述车速以及所述转速均为零时，生成所述第一请求响应；

在所述车速不为零或者所述转速不为零时，生成所述第二请求响应。

在一些实施例中，所述处理单元，还用于：

在生成所述第一请求响应之后，启动整车静默状态；

其中，所述整车静默状态用于表征所述ECU禁止发动机起动、停止向整车中其他部件发送报文，以及停止对接收到的报文进行故障诊断。

在一些实施例中，所述处理单元，还用于：

在停止对接收到的报文进行故障诊断之后，采用所述整车静默状态的前一时刻接收到的报文进行故障诊断。

在一些实施例中，所述处理单元，还用于：

在生成所述第一请求响应之前，确定所述整车为上电状态，并将上电次数置为1；

在所述通信单元向所述待升级部件发送所述第一请求响应之后，且在检测到所述整车重新上电时，将所述上电次数置为2，并关闭所述整车静默状态。

第四方面，本申请实施例提供了另一种整车程序的升级装置，包括：

通信单元，用于接收来自云端平台的升级通知，向ECU发送升级请求；

处理单元，被配置为执行：

在接收到所述ECU返回的第一请求响应时，从所述云端平台下载新版本的程序并进行数据刷写；

在接收到所述ECU返回的第二请求响应，返回接收升级通知的步骤，直至接收到所述第一请求响应；

其中，所述第一请求响应和所述第二请求响应是根据整车的车速和发动机的转速确定的。

在一些实施例中，所述处理单元，还用于：

在进行从所述云端平台下载新版本的程序包并进行数据刷写时，采用指示灯的第一亮灯机制；

在完成所述数据刷写时，采用所述指示灯的第二亮灯机制；

其中，所述第一亮灯机制和所述第二亮灯机制不相同。

第五方面，本申请实施例提供了一种电子设备，所述电子设备包括控制器和存储器。存储器用于存储计算机执行指令，控制器执行存储器中的计算机执行指令以利用控制器中的硬件资源执行第一方面或者第二方面任一种可能实现的方法的操作步骤。

第六方面，本申请提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面的方法。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例。

图1为本申请实施例提供的一种整车程序的升级***；

图2为本申请实施例提供的一种整车程序的升级方法流程图；

图3为本申请实施例提供的一种整车程序的升级过程是示意图；

图4为本申请实施例提供的另一种整车程序的升级方法流程图；

图5为本申请实施例提供的一种整车程序的升级装置的结构示意图；

图6为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请技术方案的一部分实施例，而不是全部的实施例。基于本申请文件中记载的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请技术方案保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”和“第二”是用于区别不同对象，而非用于描述特定顺序。此外，术语“包括”以及它们任何变形，意图在于覆盖不排他的保护。例如包含了一系列步骤或单元的过程、方法、***、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请中的“多个”可以表示至少两个，例如可以是两个、三个或者更多个，本申请实施例不做限制。

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，在不做特别说明的情况下，一般表示前后关联对象是一种“或”的关系。

为了便于理解本申请提出的整车程序升级方法，首先对于本申请涉及的技术用于进行简单介绍：

(1)远程升级技术(Over-the-Air，OTA)：指通过无线通信网络(数据网络或者WiFi)对整车中各个部件上运行的程序进行远程升级技术。可以实现程序的远程管理和云端下载。OTA技术的实现具体为：OTA云端平台获取更新后的程序(可以是技术人员配置的数据包)，OTA云端平台通过无线通信网络将更新后的程序发送到整车端，整车端相应的部件接收更新后的程序并进行刷写。

(2)带电可擦可编程只读存储器(Electrically Erasable Programmable ReadOnly Memory，EEPROM)：是指一种掉电后数据不丢失的存储芯片。

(3)整车控制器(Vehicle Control Unit，VCU)：作为智能汽车的中央控制单元，是整个控制***的核心。VCU采集电机及电池状态，采集加速踏板信号、制动踏板信号、执行器及传感器信号，根据驾驶员的意图综合分析做出相应判定后，监控下层的各部件控制器的动作，它负责汽车的正常行驶、制动能量回馈、整车驱动***及动力电池的能量管理、网络管理、故障诊断及处理、车辆状态监控等，从而保证整车在较好的动力性、较高经济性及可靠性状态下正常稳定的工作。

(4)驾驶循环：指的是车辆的T15开关(发动机ECU的供电开关)从上电到下电的中间过程。

(5)控制器局域网络(Controller Area Network，CAN)：是由以研发和生产汽车电子产品著称的德国BOSCH公司开发的，并最终成为国际标准(ISO11898)，是国际上应用最广泛的现场总线之一。车辆内部的ECU与整车的其他部件通信采用的就是CAN总线。

下面，为了便于理解本申请实施例提供的整车程序升级方案，首先对本申请涉及的***架构机型介绍。参见图1，为本申请实施例提供的一种整车程序升级***，用于实现本申请所提供的整车程序升级方法。该***具体包括：OTA云端平台和待升级部件。需要说明的是，图1仅作为一种示例，本申请对于***中包括的待升级部件的数量不作具体限定，图1中仅以一个待升级部件为例进行介绍。

其中，OTA云端平台，也可以称为OTA云端服务器平台，包括整车厂支持OTA升级的全部完整的升级包。OTA云端平台具有的功能包括：版本更新检查、提供升级包下载接口、提供升级结果汇报接口以及升级通知等。OTA云端平台的框架结构主要包括五部分：OTA管理平台、OTA升级服务、任务调度、文件服务和任务管理。具体功能分别为：

OTA管理平台：用于负责OTA软件管理、OTA版本管理、OTA升级计划管理、升级条件管理、程序版本管理、OTA差分包制作、OTA包的加密和分发。

OTA升级服务：用于OTA版本更新检查、升级包签名计算、OTA升级下载进度汇报、OTA升级进度汇报、OTA升级结果汇报和OTA升级通知。

任务调度：用于任务发布、任务调度、任务的分批处理、任务的分时处理以及任务的错误重试。

文件服务：主要提供OTA升级包的存储和下载服务。

任务管理：用于查看已提交的任务以及任务的手动重启等。

可选地，待升级部件可以理解为整车上用于运行待升级程序的部件，可以为整车中的一些智能元件，例如风扇控制单元等。也可以为整车控制器VCU。待升级部件可以在接收到OTA云端平台发送的升级通知之后，从OTA云端平台下载升级包，也就是下载升级后的程序包。并可以在接收到程序包之后进行数据刷写完成程序升级。

可选地，OTA云端平台与待升级部件之间的通信可以采用无线网络(比如数据网络或者WiFi)。例如，在下发升级通知或者下载升级包时，可以通过无线网络来实现收发。

在相关技术中，当整车中有正在进行OTA升级的部件时，该部件与ECU的通信是中断的状态，但是与此同时，整车中其他部件与ECU是正常通信的状态。因此，ECU在根据接收到的报文进行故障诊断时一些诊断逻辑无法形成闭环，所以会出现诊断失误的问题，出现异常报错的情况，从而可能会影响发动机的运行。例如，若由于一些程序的升级导致ECU对于风扇开启关闭的状态进行了误判，已知风扇的开启和关闭状态下分别对应的发动机的转速是不相同的，因此风扇状态的误判会影响到发动机的运行。为了解决这类问题，本申请提出了一种整车***的升级方法，改变了原有升级流程中仅有待升级部件和OTA云端平台的交互，增加了ECU的判断逻辑。通过ECU根据当前的车速和发送机转速来确定当前的车辆状态是否可以进行升级，并由ECU指示待升级部件进行升级。以此来解决现有的升级方式带来的影响发动机运行等问题。

下面，结合图1所示的架构对本申请提出的方案进行介绍，参见图2，为本申请实施例提供的一种整车程序的升级方法流程图具体包括：

201，待升级部件接收来自OTA云端平台的升级通知。

可选地，OTA云端平台可以通过无线通信网络向待升级部件发送升级通知。比如通过数据网络(2/3/4/5G网络)或者WiFi来发送升级通知。

202，待升级部件向ECU发送升级请求。

可选地，升级请求中可以包括待升级部件的标识，比如待升级部件的ID。升级请求中还可以包括相应的升级数据，比如用于指示待升级部件的哪一个程序需要进行升级的数据。

203，ECU根据升级请求检测整车的车速和发动机的转速。

作为一种可能实现的方式，ECU可以在接收到升级请求之后，通过相应的速度传感器来获取车速和发动机转速。

204，ECU基于车速和发动机转速生成第一请求响应或者生成二请求响应。

其中，第一请求响应用于指示可以进行升级，第二请求响应用于指示不能进行升级。

205，ECU向待升级部件发送第一请求响应或者第二请求响应。

具体地，若ECU基于车速和转速生成的是第一请求响应，则向待升级部件发送第一请求响应。若ECU基于车速和转速生成的是第二请求响应，则向待升级部件发送第二请求响应。

基于上述方案，本申请在现有的整车程序升级的架构中增加了ECU的判断策略。相较于现有技术中待升级部件直接根据云端平台的指示进行程序的升级，本申请的方案添加了ECU判断车辆状态是否可以进行升级的步骤。也就是说，待升级部件在接收到来自云端平台的升级通知之后，会进一步通过ECU来确定当前车辆的运行状态是否适合进行升级。若ECU判断可以进行升级，待升级程部件再进行升级。以此避免直接升级对发动机运行的影响，以及直接升级造成的异常报错等问题。

本申请的升级方案相较于现有技术增加了ECU的判断策略，下面，结合具体的场景对于ECU的判断策略进行介绍。

场景一：允许升级的场景。

ECU在接收到升级请求之后，会根据升级请求进行检测当前的车速和发动机的转速。一种可能实现的情况下，若ECU检测到的车速和转速均为零时，ECU可以生成用于指示进行升级的第一请求响应。进一步地，ECU可以启动整车静默状态。例如，ECU可以禁止发动机起动、停止通过CAN总线向整车中的其他部件发送报文以及对于接收到的报文不进行故障诊断，所有的故障诊断可以都保持启动静默状态之前的诊断结果。也就是说，此时ECU保持停帧状态。再进一步地，ECU可以向待升级部件发送第一请求响应，以指示待升级部件进行升级。可选地，待升级部件在接收到第一请求响应后，可以从OTA云端平台下载新版本的程序包，并进行数据刷写，以完成程序的升级。作为一种可能实现的方式，待升级部件在升级过程中以及升级完成时，可以采用不同的方式来点亮指示灯。可选地，待升级部件在下载新版本的程序包以及进行数据刷写的过程中可以采用指示灯的第一亮灯机制，在数据刷写完成时，可以采用指示灯的第二亮灯机制，其中第一亮灯机制和第二亮灯机制不相同。例如，待升级部件可以在升级过程中使指示灯闪烁点亮，在升级完成后使指示灯长亮或者使指示灯熄灭，以此来提示驾驶员，从而保证在升级完成之前不会出现异常断电的问题，保障升级的成功率。

在一种可能实现的方式中，ECU还可以通过设置各类变量来表征判断的结果。作为一种举例，ECU可以设置两个变量：变量B-用于表征ECU是否允许进行升级(变量B取值为1表示允许，变量B取值为0表示不允许)。变量C-用于表征ECU是否接收到来自待升级部件的升级请求(变量C取值为1表示已接收到，变量C取值为0表示未接收到)。变量B和变量C的初始值均为0。下面，结合这两个变量对场景一下ECU的判断策略进行介绍：

可选地，ECU在接收到来自待升级部件的升级请求时，可以将变量C的取值从0变为1。并启动检测车速和发动机的转速，若检测到车速和转速均为0，则可以将变量B的取值从0变为1。进一步地，ECU还可以进行整车静默状态，即停止向整车中其他部件发送报文，禁止发动机启动，以及对于接收到的报文不做处理以及不进行故障诊断，所有的报文信号以进入静默状态之前的接收值为准。再进一步地，ECU可以生成并向待升级部件发送第一请求响应。为了便于理解，下面结合具体的实施例对于场景一下的整车程序升级方法进行介绍。参见图3，为本申请实施例提供的一种整车程序升级方法流程图，具体包括：

301，ECU接收来自待升级部件的升级请求。

可选地，待升级部件可以通过CAN总线向ECU发送升级请求。ECU在接收到升级请求之后，可以将变量C的取值从0变为1。

302，ECU确定整车的车速和发动机的转速均为0。

可选地，ECU在确定车速和转速都为0之后，可以将变量B的取值从0变为1。并可以启动整车静默状态。其中，关于整车静默状态的描述可以参见上述实施例中的介绍，在此不再进行赘述。

303，ECU生成并向待升级部件发送第一请求响应。

304，待升级部件根据第一请求响应从OTA云端平台下载新版本的程序包并进行数据刷写。

在一些实施例中，若发生异常掉电，ECU还保持整车静默状态，那么在下一次上电时(也就是下一个驾驶循环中)，可能会出现报文收发故障的问题。因此，需要在异常掉电时，关闭整车静默状态。可选地，针对该问题，本申请提出了ECU中还可以设置变量T15ON_Counter-用于表征T15的上电次数，变量C可以存储在EE中，避免掉电丢失。可选地，ECU可以在接收到升级请求，将变量C的取值设置为1之后，将变量T15ON_Counter的取值从0变为1，并存储到EE中。若ECU检测到T15下电(包括短下电和完全下点)再重新上电，则ECU可以将EE中存储的变量T15ON_Counter的取值从1变为2。当ECU确定变量T15ON_Counter的取值变为2时，即可以关闭整车静默状态，ECU可以正常收发报文，发动机也可以正常起动。

场景二：不允许升级的场景。

可选地，ECU在检测到车速不为零或者发动机转速不为零时，可以生成用于指示不进行升级的第二请求响应，并将第二请求响应发送给待升级部件。待升级部件接收到第二请求响应之后，还可以向OTA云端平台反馈用于表征无法升级的信息，以便于OTA云端平台备份。

在一种可能实现的方式中，场景二中，ECU也可以通过设置各类变量来表征判断的结果。作为一种举例，ECU可以设置两个变量：变量B-用于表征ECU是否允许进行升级(变量B取值为1表示允许，变量B取值为0表示不允许)。变量C-用于表征ECU是否接收到来自待升级部件的升级请求(变量C取值为1表示已接收到，变量C取值为0表示未接收到)。变量B和变量C的初始值均为0。下面，结合这两个变量对场景二下ECU的判断策略进行介绍：

可选地，ECU在接收到来自待升级部件的升级请求时，可以将变量C的取值从0变为1。并启动检测车速和发动机的转速，若检测到车速不为零或者转速不为零，则不会修改变量B的取值，变量B取值依然为0。进一步地，ECU可以生成并向待升级部件发送用于指示不进行升级的第二请求响应。

在一种可能实现的方式中，待升级部件在接收到第二请求响应之后，可以向OTA云端平台反馈用于表征无法升级的信息。进一步地，待升级部件还可以继续返回接收OTA云端平台发送的升级通知的步骤，直至接收到第一请求响应。

在另一种可能实现的方式中，待升级部件可以在向OTA云端平台反馈用于表征无法升级的信息，可以不进行任何操作。ECU可以根据自身变量C取值为1，直接在后续检测到车速和转速均变为零时开启整车静默状态。

下面，为了更进一步地理解本申请提出的整车程序的升级方法，结合具体的实施例进行介绍。参见图4，为本申请实施例提供的一种整车程序的升级方法流程图，具体包括：

401，待升级部件接收到来自OTA云端平台的升级通知。

402，待升级部件向ECU发送升级请求。

可选地，ECU在接收到升级请求之后，可以将变量C的取值从0变为1。

403，ECU判断车速和转速是否均为零。

若否，则继续步骤404。

若是，则继续步骤406。

404，ECU生成并向待升级部件发送第二请求响应。

405，待升级部件向OTA云端平台发送用于表征无法升级的信息。

可选地，待升级部件在发送用于表征无法升级的信息之后，可以返回执行步骤401。

406，ECU启动整车静默状态，以及生成并向待升级部件发送第一请求响应。

可选地，ECU在启动整车静默状态时，可以将变量B的取值从0变为1。并将EE中存储的变量T15ON_Counter的取值从0变为1。

407，待升级部件根据第一请求响应从OTA云端平台下载新版的程序包，并进行数据刷写。

408，ECU持续检测T15的上电状态，在检测到T15重新上电时关闭整车静默状态。

可选地，ECU在检测到T15重新上电之后，还可以将变量T15ON_Counter的取值从1变为2。

基于与上述方法的同一构思，参见图5，为本申请实施例提供的一种整车程序的升级装置500。装置500可以用于执行上述方法中的各个步骤，为了避免重复，此处不再进行赘述。装置500包括：通信单元501和处理单元502。

在一种可能的场景下：

通信单元501，用于接收来自待升级部件的升级请求；

处理单元502，用于根据所述升级请求检测整车的车速和发动机的转速；

所述处理单元502，还用于基于所述车速和所述转速，生成第一请求响应或者第二请求响应；所述第一请求响应用于指示进行升级，所述第二请求响应用于指示不进行升级；

所述通信单元501，还用于向所述待升级部件发送所述第一请求响应或者所述第二请求响应。

在一些实施例中，所述处理单元502，具体用于：

在所述车速以及所述转速均为零时，生成所述第一请求响应；

在所述车速不为零或者所述转速不为零时，生成所述第二请求响应。

在一些实施例中，所述处理单元502，还用于：

在生成所述第一请求响应之后，启动整车静默状态；

其中，所述整车静默状态用于表征所述ECU禁止发动机起动、停止向整车中其他部件发送报文，以及停止对接收到的报文进行故障诊断。

在一些实施例中，所述处理单元502，还用于：

在停止对接收到的报文进行故障诊断之后，采用所述整车静默状态的前一时刻接收到的报文进行故障诊断。

在一些实施例中，所述处理单元502，还用于：

在生成所述第一请求响应之前，确定所述整车为上电状态，并将上电次数置为1；

在所述通信单元501向所述待升级部件发送所述第一请求响应之后，且在检测到所述整车重新上电时，将所述上电次数置为2，并关闭所述整车静默状态。

在另一种可能的场景下：

通信单元501，用于接收来自云端平台的升级通知，向ECU发送升级请求；

处理单元502，被配置为执行：

在接收到所述ECU返回的第一请求响应时，从所述云端平台下载新版本的程序并进行数据刷写；

在接收到所述ECU返回的第二请求响应，返回接收升级通知的步骤，直至接收到所述第一请求响应；

其中，所述第一请求响应和所述第二请求响应是根据整车的车速和发动机的转速确定的。

在一些实施例中，所述处理单元502，还用于：

在进行从所述云端平台下载新版本的程序包并进行数据刷写时，采用指示灯的第一亮灯机制；

在完成所述数据刷写时，采用所述指示灯的第二亮灯机制；

其中，所述第一亮灯机制和所述第二亮灯机制不相同。

图6示出了本申请实施例提供的电子设备600结构示意图。本申请实施例中的电子设备600还可以包括通信接口603，该通信接口603例如是网口，电子设备可以通过该通信接口603传输数据。例如，通信接口603可以用于实现上述图5中的通信单元501的功能。

在本申请实施例中，存储器602存储有可被至少一个控制器601执行的指令，至少一个控制器601通过执行存储器602存储的指令，可以用于执行上述方法中的各个步骤，例如，控制器601可以实现上述图5中的处理单元502的功能。

其中，控制器601是电子设备的控制中心，可以利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器602内的指令以及调用存储在存储器602内的数据。可选的，控制器601可包括一个或多个处理单元，控制器601可集成应用控制器和调制解调控制器，其中，应用控制器主要处理操作***和应用程序等，调制解调控制器主要处理无线通信。可以理解的是，上述调制解调控制器也可以不集成到控制器601中。在一些实施例中，控制器601和存储器602可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

控制器601可以是通用控制器，例如中央控制器(CPU)、数字信号控制器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用控制器可以是微控制器或者任何常规的控制器等。结合本申请实施例所公开的数据统计平台所执行的步骤可以直接由硬件控制器执行完成，或者用控制器中的硬件及软件模块组合执行完成。

存储器602作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器602可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等。存储器602是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器602还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

通过对控制器601进行设计编程，例如，可以将前述实施例中介绍的神经网络模型的训练方法所对应的代码固化到芯片内，从而使芯片在运行时能够执行前述的神经网络模型训练方法的步骤，如何对控制器601进行设计编程为本领域技术人员所公知的技术，这里不再赘述。

本领域内的技术人员应明白，本申请的实施例可提供为方法、***、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的控制器以产生一个机器，使得通过计算机或其它可编程数据处理设备的控制器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其它可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上，使得在计算机或其它可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (14)

1.一种整车程序的升级方法，其特征在于，所述方法应用于发动机控制单元ECU，所述方法包括：

接收来自待升级部件的升级请求；

根据所述升级请求检测整车的车速和发动机的转速；

基于所述车速和所述转速，生成第一请求响应或者第二请求响应；所述第一请求响应用于指示进行升级，所述第二请求响应用于指示不进行升级；

向所述待升级部件发送所述第一请求响应或者所述第二请求响应。

2.根据权利要求1所述的方法，其特征在于，所述基于所述车速和所述转速，生成第一请求响应或者第二请求响应，包括：

若所述车速以及所述转速均为零，则生成所述第一请求响应；

若所述车速不为零或者所述转速不为零，则生成所述第二请求响应。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

在生成所述第一请求响应之后，启动整车静默状态；

其中，所述整车静默状态用于表征所述ECU禁止发动机起动、停止向整车中其他部件发送报文，以及停止对接收到的报文进行故障诊断。

4.根据权利要求1-3任一项所述的方法，其特征在于，在生成所述第一请求响应之前，所述方法还包括：

确定所述整车为上电状态，并将上电次数置为1；

在向所述待升级部件发送所述第一请求响应之后，所述方法还包括：

在检测到所述整车重新上电时，将所述上电次数置为2，并关闭所述整车静默状态。

5.一种整车程序的升级方法，其特征在于，所述方法应用于整车中的待升级部件，所述方法包括：

接收来自云端平台的升级通知，向ECU发送升级请求；

若接收到所述ECU返回的第一请求响应，则从所述云端平台下载新版本的程序并进行数据刷写；

若接收到所述ECU返回的第二请求响应，则返回接收升级通知的步骤，直至接收到所述第一请求响应；

其中，所述第一请求响应和所述第二请求响应是根据整车的车速和发动机的转速确定的。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

在进行从所述云端平台下载新版本的程序包并进行数据刷写时，采用指示灯的第一亮灯机制；

在完成所述数据刷写时，采用所述指示灯的第二亮灯机制；

其中，所述第一亮灯机制和所述第二亮灯机制不相同。

7.一种整车程序的升级装置，其特征在于，包括：

通信单元，用于接收来自待升级部件的升级请求；

处理单元，用于根据所述升级请求检测整车的车速和发动机的转速；

所述处理单元，还用于基于所述车速和所述转速，生成第一请求响应或者第二请求响应；所述第一请求响应用于指示进行升级，所述第二请求响应用于指示不进行升级；

所述通信单元，还用于向所述待升级部件发送所述第一请求响应或者所述第二请求响应。

8.根据权利要求7所述的装置，其特征在于，所述处理单元，具体用于：

在所述车速以及所述转速均为零时，生成所述第一请求响应；

在所述车速不为零或者所述转速不为零时，生成所述第二请求响应。

9.根据权利要求8所述的装置，其特征在于，所述处理单元，还用于：

在生成所述第一请求响应之后，启动整车静默状态；

其中，所述整车静默状态用于表征所述ECU禁止发动机起动、停止向整车中其他部件发送报文，以及停止对接收到的报文进行故障诊断。

10.根据权利要求7-9任一项所述的装置，其特征在于，所述处理单元，还用于：

在生成所述第一请求响应之前，确定所述整车为上电状态，并将上电次数置为1；

在所述通信单元向所述待升级部件发送所述第一请求响应之后，且在检测到所述整车重新上电时，将所述上电次数置为2，并关闭所述整车静默状态。

11.一种整车程序的升级装置，其特征在于，包括：

通信单元，用于接收来自云端平台的升级通知，向ECU发送升级请求；

处理单元，被配置为执行：

在接收到所述ECU返回的第一请求响应时，从所述云端平台下载新版本的程序并进行数据刷写；

在接收到所述ECU返回的第二请求响应，返回接收升级通知的步骤，直至接收到所述第一请求响应；

其中，所述第一请求响应和所述第二请求响应是根据整车的车速和发动机的转速确定的。

12.根据权利要求11所述的装置，其特征在于，所述处理单元，还用于：

在进行从所述云端平台下载新版本的程序包并进行数据刷写时，采用指示灯的第一亮灯机制；

在完成所述数据刷写时，采用所述指示灯的第二亮灯机制；

其中，所述第一亮灯机制和所述第二亮灯机制不相同。

13.一种电子设备，其特征在于，所述电子设备包括处理器和存储器，

所述存储器，用于存储计算机程序或指令；

所述处理器，用于执行存储器中的计算机程序或指令，使得权利要求1-6任一项所述的方法被执行。

14.一种计算机可读存储介质，其上存储有计算机程序指令，其特征在于，该计算机程序指令被处理器执行时实现权利要求1-6任一项所述方法的步骤。

Images