一种OTA数据的传输系统及车辆

技术领域

本申请涉及OTA技术领域，尤其涉及一种OTA数据的传输系统及车辆。

背景技术

汽车OTA(Over the Air Technology，空中下载技术)升级，指通过网络从远程服务器下载新的软件更新包对汽车自身系统进行升级,这种升级方式能够快速修复系统缺陷，快速迭代、提升产品和使用体验，同时节约双方的时间和金钱。

目前汽车的OTA升级以VBOX的双核结构实现，VBOX是携带有V2X(Vehicle-to-Everything，车联网技术)功能的TBOX(Telematics Box，远程通信终端)，OTA升级也可通过无V2X功能的TBOX的双核结构实现。如图1所示，OTA主控应用部署在VBOX的MPU(MicroProcessor Unit，微处理器)上，OTA从控应用，即UDS(Unified Diagnostic Services，统一的诊断服务)服务及协议栈部署在VBOX的MCU(Mirco Controller Unit，微控制器)上。OTA主控应用通过ZMQ服务与MPU硬件层进行交互，MPU侧将ZMQ报文数据通过SPI(SerialPeripheral Interface，串行外围设备接口)接口转发至MCU的SPI接口，MCU通过MCU ZMQ服务将数据发送至OTA从控应用进行处理，OTA从控应用将数据报文通过CAN(ControllerArea Network，控制器局域网络)通道发送至各ECU(Electronic Control Unit，电子控制器单元)进行升级刷写。

然而当前双核结构的通信方式，经常出现通信失败、丢包的情况，然而目前丢包情况难以检测，基于丢包后的报文进行升级刷写，将导致文件错误，轻则影响系统正常运行，重则影响汽车的行驶安全。

因此，如何提供一种解决上述技术问题的方案是目前本领域技术人员需要解决的问题。

发明内容

有鉴于此，本申请实施例提供了一种OTA数据的传输系统及车辆，以解决现有技术中通信失败丢包的问题。

本申请实施例的第一方面，提供了一种OTA数据的传输系统，包括多个节点；

按照OTA数据的传输方向，多个节点依次为设于MPU的OTA主控节点、设于MPU的第一SPI节点、设于MCU的第二SPI节点、设于MCU的OTA从控节点、ECU节点；

除OTA主控节点外的其他每个节点均用于：

接收上一节点下发的OTA数据，并向上一节点返回节点应答信息，节点应答信息表征为当前节点已接收到OTA数据；

除ECU节点外的其他每个节点均用于：

将OTA数据下发到下一节点，并等待下一节点返回节点应答信息；

若对应的节点预设时间内收到下一节点返回的节点应答信息，则确认当前OTA数据在当前节点的发送成功；

若节点预设时间内未收到下一节点返回的节点应答信息，则确认当前OTA数据在当前节点的发送出错，再次执行将OTA数据下发到下一节点，并等待下一节点返回节点应答信息的步骤。

本申请实施例的第二方面，提供了一种车辆，包括上文任一项所述OTA数据的传输系统。

本申请实施例与现有技术相比存在的有益效果至少包括：本申请实施例通过在节点上增加接收OTA数据同时反馈节点应答信息的机制，提高了OTA数据传输的链路上各段传输的可靠性，解决了原本双核通信易丢包的问题，同时可实现故障节点的有效定位，减少升级重刷的次数，升级刷写成功率高。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1是本申请实施例的一种OTA数据的传输系统的结构分布图；

图2是本申请实施例提供的一种OTA基础硬件的结构分布图；

图3是本申请实施例提供的一种数据信息的传输过程图；

图4是本申请实施例提供的一种序号判定的过程图；

图5是本申请实施例提供的一种传输系统的程序分布架构图；

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

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

下面将结合附图详细说明根据本申请实施例的一种OTA数据的传输系统及车辆。

图1是本申请实施例中OTA数据的传输系统的结构分布图，该传输系统包括多个节点，按照OTA数据的传输方向，多个节点依次为设于MPU的OTA主控节点101、设于MPU的第一SPI节点102、设于MCU的第二SPI节点103、设于MCU的OTA从控节点104、ECU节点105。

可以理解的是本实施例的传输系统基于车辆中的OTA基础硬件，如图2所示，车辆的OTA基础硬件包括VBOX、VGW和ECU，其中VBOX中包括MPU和MCU，MPU和MCU被称为双核，OTA主控节点和第一SPI节点配置于MPU中，第二SPI节点和OTA从控节点配置于MCU中，ECU节点105配置于ECU中，MPU与MCU之间通过SPI接口通信，VGW和MCU之间通过CAN接口通信，VGW和ECU之间通过CAN接口通信。

通常情况下，按照OTA数据的传输方向，TSP将OTA数据下发到MPU中的OTA主控节点，OTA主控节点将OTA数据传递到第一SPI节点，第一SPI节点将OTA数据传递到第二SPI节点，即第一SPI节点通过核间通信的方式以SPI协议与第二SPI节点通信；第二SPI节点将OTA数据传递到OTA从控节点，OTA从控节点将OTA数据通过VGW以CAN协议传递到对应的ECU节点，即，OTA从控节点通过网关以CAN协议与ECU节点通信，ECU节点将根据该OTA协议进行刷写。

具体的本实施例的传输系统中各节点并非存在硬件结构的实际节点，而是设于对应的各硬件内部用于提供特定服务的线程节点，其中，OTA主控节点是用于提供OTA升级主控(UMC)服务应用的线程节点，第一SPI节点和第二SPI节点是用于提供其所在核的硬件层SPI服务应用的线程节点，OTA从控节点是用于提供OTA升级从控服务应用的线程节点，ECU节点是用于提供其所在ECU的OTA刷写服务。

在以上节点的基础服务功能前提下，在OTA数据的传输过程中，各节点还需要实现以下特定的功能，以确保OTA数据的传输可靠性：

除OTA主控节点外的其他每个节点均用于：

接收上一节点下发的OTA数据，并向上一节点返回节点应答信息，节点应答信息表征为当前节点已接收到OTA数据；

除ECU节点外的其他每个节点均用于：

将OTA数据下发到下一节点，并等待下一节点返回节点应答信息；

若对应的节点预设时间内收到下一节点返回的节点应答信息，则确认当前OTA数据在当前节点的发送成功；

若节点预设时间内未收到下一节点返回的节点应答信息，则确认当前OTA数据在当前节点的发送出错，再次执行将OTA数据下发到下一节点，并等待下一节点返回节点应答信息的步骤。

以上数据信息的传输过程可如图3所示，其中图3中第一条传输过程为OTA主控节点发送OTA数据到第一SPI节点后第一SPI节点反馈节点应答信息到OTA主控节点，OTA主控节点在节点预设时间内收到了节点应答信息。图3中第二条传输过程为第一SPI节点在节点预设时间内未收到节点应答信息，即节点应答信息超时，因此第一SPI节点重传OTA数据到第二SPI节点，后续节点传输正常，当ECU节点确认收到OTA数据后，向OTA从控节点返回节点应答信息，OTA从控节点基于此节点应答信息生成链路应答信息向上传递至OTA主控节点，最终OTA主控节点判断是否在链路预设时间内收到链路应答信息，根据图3所示，第二条传输过程中OTA主控节点在链路预设时间内收到了链路应答信息。如图3的第三条传输过程，第二SPI节点向OTA从控节点传输OTA数据后得到应答失败的反馈，该反馈可能是节点应答信息超时，也可能是下发的OTA数据存在错误，第二SPI节点根据该反馈重传OTA数据，OTA从控节点返回正常的节点应答信息，将OTA数据下发到ECU节点，与第二条传输过程类似，当ECU节点确认收到OTA数据后，向OTA从控节点返回节点应答信息，OTA从控节点基于此节点应答信息生成链路应答信息向上传递至OTA主控节点，最终OTA主控节点判断是否在链路预设时间内收到链路应答信息，根据图3所示，第三条传输过程中OTA主控节点收到链路应答信息时已经超出了链路预设时间，即链路应答信息超时。

可以理解的是，OTA主控节点将OTA数据传递到第一SPI节点；如果第一SPI节点接收到OTA主控节点下发的OTA数据，则向OTA主控节点返回节点应答信息，以表征第一SPI节点已接收到当前OTA数据；OTA主控节点在下发OTA数据后立刻开始计时，如果节点预设时间内收到了第一SPI节点返回的节点应答信息，则确认当前OTA数据在OTA主控节点的发送成功，即当前OTA数据已顺利从OTA主控节点下发到第一SPI节点；如果节点预设时间内没有收到第一SPI节点返回的节点应答信息，即出现超时，此时OTA数据在OTA主控节点的发送丢失或故障，第一SPI节点未能顺利收到OTA数据，OTA主控节点将再次发送OTA数据，并等待节点应答信息。

类似的，第一SPI节点将OTA数据传递到第二SPI节点；如果第二SPI节点接收到第一SPI节点下发的OTA数据，则向第一SPI节点返回节点应答信息，以表征第二SPI节点已接收到当前OTA数据；第一SPI节点在下发OTA数据后立刻开始计时，如果节点预设时间内收到了第二SPI节点返回的节点应答信息，则确认当前OTA数据在第一SPI节点的发送成功，即当前OTA数据已顺利从第一SPI节点下发到第二SPI节点；如果节点预设时间内没有收到第二SPI节点返回的节点应答信息，即出现超时，此时OTA数据在第一SPI节点的发送丢失或故障，第二SPI节点未能顺利收到OTA数据，第一SPI节点将再次发送OTA数据，并等待节点应答信息。

类似的，第二SPI节点将OTA数据传递到OTA从控节点；如果OTA从控节点接收到第二SPI节点下发的OTA数据，则向第二SPI节点返回节点应答信息，以表征OTA从控节点已接收到当前OTA数据；第二SPI节点在下发OTA数据后立刻开始计时，如果节点预设时间内收到了OTA从控节点返回的节点应答信息，则确认当前OTA数据在第二SPI节点的发送成功，即当前OTA数据已顺利从第二SPI节点下发到OTA从控节点；如果节点预设时间内没有收到OTA从控节点返回的节点应答信息，即出现超时，此时OTA数据在第二SPI节点的发送丢失或故障，OTA从控节点未能顺利收到OTA数据，第二SPI节点将再次发送OTA数据，并等待节点应答信息。

类似的，OTA从控节点将OTA数据传递到ECU节点；如果ECU节点接收到OTA从控节点下发的OTA数据，则向OTA从控节点返回节点应答信息，以表征ECU节点已接收到当前OTA数据；OTA从控节点在下发OTA数据后立刻开始计时，如果节点预设时间内收到了ECU节点返回的节点应答信息，则确认当前OTA数据在OTA从控节点的发送成功，即当前OTA数据已顺利从OTA从控节点下发到ECU节点；如果节点预设时间内没有收到ECU节点返回的节点应答信息，即出现超时，此时OTA数据在OTA从控节点的发送丢失或故障，ECU节点未能顺利收到OTA数据，OTA从控节点将再次发送OTA数据，并等待节点应答信息。

可以理解的是，不同节点对于发出OTA数据后开始计时等待接收节点应答信息时，用于判定发送是否成功的节点预设时间并不一致，例如OTA主控节点的节点预设时间可设为500ms，第一SPI节点的节点预设时间可设为500ms，第二SPI节点的节点预设时间可设为150ms，OTA从控节点的节点预设时间可设为127ms，各节点的节点预设时间可根据实际工况和传输要求进行设置，此处不作限制。

可以理解的是，每个节点在节点预设时间内未收到节点应答信息后会进行数据重发，但重发次数并非无限制，如果数据重发次数达到预设次数，则不再重发，而是直接确认当前节点对应的下行链路故障，并上传故障信息到应用层，此处预设次数可根据实际需求进行设置，例如3次或4次，因此本实施例中，除ECU节点外的其他每个节点还用于：

若节点预设时间内未收到下一节点返回的节点应答信息，且执行将OTA数据下发到下一节点，并等待下一节点返回节点应答信息的步骤的次数已达到预设次数，则确认节点对应的下行链路故障，并上传对应的故障信息。

可以理解的是，各节点对上行节点反馈节点应答信息，是为了反馈该节点的上行链路通信正常未丢包，各节点等待下行节点的节点应答信息，是为了确认该节点的下行链路通信是否正常未丢包，除了对具体节点的上下行链路的故障判断外，还可进一步确定包括所有节点的完整传输链路是否通信正常，即在最末的ECU节点收到OTA数据后一路向上反馈链路应答信息，直至OTA主控节点收到该链路应答信息并确认该OTA数据已成功发送至ECU节点。

基于以上分析，OTA从控节点还用于：

当接收到ECU节点返回的节点应答信息，生成链路应答信息，并上传到上一节点；

第二SPI节点、第一SPI节点还用于：

当接收到下一节点返回的链路应答信息，将链路应答信息上传到上一节点；

OTA主控节点还用于：

当接收到第一SPI节点返回的链路应答信息，则确认当前OTA数据已正确发送至ECU节点。

类似于节点应答信息存在节点预设时间的超时判定，链路应答信息也存在链路预设时间的超时判定，具体的，OTA主控节点还用于：

向第一SPI节点下发OTA数据后开始计时；

若链路预设时间内收到第一SPI节点返回的链路应答信息，则确认当前OTA数据已正确发送至ECU节点；

若链路预设时间未收到第一SPI节点返回的链路应答信息，则确认当前OTA数据发送超时。

其中，链路预设时间的设置可根据实际工况和需求进行设置，例如OTA数据的发送对数据传递时间没有限制要求，只要确定OTA数据被发送到ECU节点，则可以将以上各节点的节点应答时间与对应的预设次数相乘后累加，最后作为链路预设时间，例如链路预设时间可设为2s。但是如果OTA主控节点对于发送时效有要求，即使在节点重复发送最终成功到达ECU节点，只要发送时长超过链路预设时间，也可认为当前链路出现传送故障，此时链路预设时间可设为1s。需要注意的是，确认OTA数据发送超时，并不意味着停止后续OTA数据的下发，此处发送超时的记录和最终是否收到链路应答信息的记录，都可作为整个传输系统的性能表现数据，后续可根据这些记录评价整个传输系统的数据传输稳定性。

可以理解的是，整个OTA数据的传输系统，通常要连续传递多个OTA数据，这些OTA数据的发送顺序、接收顺序应当保持一致，如果多个OTA数据在传递到ECU节点时，出现某一OTA数据丢失的丢包情况，或OTA数据的顺序发生错误，即接收到的OTA数据与发送出的OTA数据不一致，都会导致ECU节点上刷写错误，因此各OTA数据之间的顺序也是本实施例的传输系统中需要注意的地方。

进一步的，在各节点数据下发并接收节点应答信息确认下行节点已收到OTA数据的基础上，还可进一步在OTA数据中设置序号，从而节点可以确定当前收到的OTA数据与上一OTA数据是否为顺序连接关系，如果不是则存在丢包情况，需要上一节点重新发送序号正确的OTA数据。

因此，各节点传输的OTA数据包括实际数据和对应当前OTA数据的实际序号；第一序号节点和第二序号节点为两个节点，第一序号节点在传输方向上先于第二序号节点；

第一序号节点用于：

根据上一OTA数据的实际序号和预设序号算法确定当前OTA数据的计算序号，作为当前OTA数据的实际序号；

第二序号节点用于：

根据上一OTA数据的实际序号和预设序号算法，确定当前OTA数据的计算序号，作为当前OTA数据的理论序号；

比较当前OTA数据的实际序号和理论序号是否一致；

若是，确认当前OTA数据与上一OTA数据之间无丢包情况；

若否，确认当前OTA数据与上一OTA数据之间存在丢包情况。

此处第一序号节点和第二序号节点在传输方向上，第一序号节点先于第二序号节点，OTA数据从第一序号节点向下传递，将达到第二序号节点。此处可设置第一序号节点为OTA主控节点，第二序号节点为OTA从控节点，除了该设置外，还可根据实际需求设置其他节点作为第一序号节点和第二序号节点，例如第一SPI节点和第二SPI节点。

可以理解的是，第一序号节点和第二序号节点使用相同的预设序号算法，预设序号算法的目的在于基于上一OTA数据的实际序号生成接下来的当前OTA数据的计算序号，算法逻辑为N(i)＝f(N(i-1))，N(i)为当前OTA数据的计算序号，N(i-1)为上一OTA数据的实际序号，f为预设序号算法。其中第一序号节点的预设序号算法用于生成当前OTA数据的实际序号，第二序号节点的预设序号算法用于生成当前OTA数据的理论序号，第二序号节点在接收到当前OTA数据后，如果当前OTA数据的实际序号与理论序号一致，则证明传递过程中未出现丢包，接收到的当前OTA数据是第一序号节点发送的当前OTA数据。

其中预设序号算法的具体实现过程和难易程度可根据实际需求进行设置和选择，例如预设序号算法可选择最为简单的向上递加算法，具体的预设序号算法为：对上一OTA数据的实际序号加1确定当前OTA数据的计算序号，即：N(i)＝(N(i-1)+1。除此外，也可以选择其他难度和其他参数的预设序号算法，此处不作限制。

进一步的，第二序号节点具体用于：

当确认当前OTA数据与上一OTA数据之间无丢包情况，向第一序号节点返回比较结果，并将OTA数据下发到下一节点；

当确认当前OTA数据与上一OTA数据之间存在丢包情况，向第一序号节点返回比较结果，以接收第一序号节点根据比较结果下发对应当前OTA数据的理论序号所对应的OTA数据，然后再次执行比较当前OTA数据的实际序号和理论序号是否一致的步骤。

可以理解的是，不论有没有丢包情况，都需要返回比较结果作为应答，第一序号节点将根据比较结果确定接下来的操作，无丢包情况则继续发送后续OTA数据，有丢包情况则发送与理论序号对应的OTA数据。

进一步的，如果实际序号和理论序号一致，则可认为当前OTA数据的实际序号有效，第二序号节点的下一次理论序号计算以该OTA数据的实际序号为依据，如果实际序号和理论序号不一致，则认为当前OTA数据的实际序号无效，仍以上一OTA数据的实际序号作为计算理论序号的依据。

而对于第一序号节点而言，每次新的OTA数据的实际序号的计算，均以上次已发送的OTA数据的实际序号为基础进行计算，如果本次OTA数据是基于丢包情况下发送的，此时不需要根据前一OTA数据为基础确定实际序号，而是直接从已有实际序号的所有OTA数据中，选择实际序号与第二序号节点发送来的理论序号相同的OTA数据进行发送。

以上述预设序号算法为例，OTA数据的序号判定过程可参见图4所示：

此处假设第二序号节点已接受实际序号为0的OTA数据；

当第一序号节点发送实际序号为1的OTA数据，第二序号节点在收到实际序号为1的OTA数据后，基于上一OTA数据的实际序号0计算，0+1＝1，得出当前OTA数据的理论序号为1，比较实际序号和理论序号，二者一致，因此确认OTA数据发送正确，无丢包情况，继续向下一节点发送当前OTA数据。

当第二序号节点收到第一序号节点下发的实际序号为3的OTA数据，基于接收到的上一OTA数据的实际序号1计算，1+1＝2，得出当前OTA数据的理论序号为2，比较实际序号和理论序号，二者不一致，因此判定当前OTA数据发送有误，存在丢包情况，向第一序号节点反馈比较结果。第一序号节点根据比较结果重新下发实际序号为2的OTA数据，第二序号节点接收到实际序号为2的OTA数据后确认其实际序号与理论序号一致，判定当前OTA数据发送正确，无丢包情况，继续向下一节点发送当前OTA数据。

实际上在产生丢包情况时，可能是第一序号节点下发的OTA数据本身有误，即实际序号为3，也可能是第一序号节点下发了正确的实际序号为2的OTA数据，但在第一序号节点向第二序号节点传递数据的过程中，OTA数据发生了丢包，从而第二序号节点没有收到实际序号为2的OTA数据，只收到下一个实际序号为3的OTA数据，接收数据发生错误的原因多种多样，而以本实施例中的传输系统中各节点的运行策略工作，能够很大程度上避免以上错误情况的发生，从而提高数据传输的安全性和稳定性。

基于以上实施例的描述，整个传输系统中的程序分布架构可如图5所示，其中OTA主控应用可由OTA主控节点运行；OTA从控应用可由OTA从控节点运行；LOOP中重传处理、错误检测、错误处理可由对应的节点运行，其调用即实现各节点在本实施例中描述的关于OTA数据的接收和应答返回、重新发送；其中ZMQ(ETH)<->SPI由第一SPI节点运行，实现OTA数据从以太网协议转换到SPI协议；其中SPI<->CAN由第二SPI节点运行，实现OTA数据从SPI协议转换到CAN协议；此外MPU的中间件包括ZMQ/ETH/SPI/UART协议栈，操作系统为LINUX，硬件层设有SPI接口；MCU的中间件包括CAN/SPI/UART协议栈，实现OTA数据从SPI协议转换到CAN协议，操作系统为RTOS，硬件层设有SPI接口和CAN接口，其中第一SPI节点和第二SPI节点之间的通信传输通过这两个SPI接口进行；CAN接口还与VGW的上行CAN接口连接，VGW的下行CAN接口还与多个ECU连接，VGW对上行CAN接口接收到的OTA数据分发到下行CAN接口的各ECU，各ECU中ECU节点调用US服务实现ECU内部ECU节点对OTA数据的接收和处理。

本申请实施例通过在节点上增加接收OTA数据同时反馈节点应答信息的机制，提高了OTA数据传输的链路上各段传输的可靠性，解决了原本双核通信易丢包的问题，同时可实现故障节点的有效定位，减少升级重刷的次数，升级刷写成功率高。

上述所有可选技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。应理解，上述实施例中各动作描述的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本申请实施例还公开了一种车辆，包括一种OTA数据的传输系统，该系统包括多个节点；

按照OTA数据的传输方向，多个节点依次为设于MPU的OTA主控节点、设于MPU的第一SPI节点、设于MCU的第二SPI节点、设于MCU的OTA从控节点、ECU节点；

除OTA主控节点外的其他每个节点均用于：

接收上一节点下发的OTA数据，并向上一节点返回节点应答信息，节点应答信息表征为当前节点已接收到OTA数据；

除ECU节点外的其他每个节点均用于：

将OTA数据下发到下一节点，并等待下一节点返回节点应答信息；

若对应的节点预设时间内收到下一节点返回的节点应答信息，则确认当前OTA数据在当前节点的发送成功；

若节点预设时间内未收到下一节点返回的节点应答信息，则确认当前OTA数据在当前节点的发送出错，再次执行将OTA数据下发到下一节点，并等待下一节点返回节点应答信息的步骤。

在一示例性的实施例中，除ECU节点外的其他每个节点还用于：

若节点预设时间内未收到下一节点返回的节点应答信息，且执行将OTA数据下发到下一节点，并等待下一节点返回节点应答信息的步骤的次数已达到预设次数，则确认节点对应的下行链路故障，并上传对应的故障信息。

在一示例性的实施例中，OTA数据包括实际数据和对应当前OTA数据的实际序号；第一序号节点和第二序号节点为两个节点，第一序号节点在传输方向上先于第二序号节点；

第一序号节点用于：

根据上一OTA数据的实际序号和预设序号算法确定当前OTA数据的计算序号，作为当前OTA数据的实际序号；

第二序号节点用于：

根据上一OTA数据的实际序号和预设序号算法，确定当前OTA数据的计算序号，作为当前OTA数据的理论序号；

比较当前OTA数据的实际序号和理论序号是否一致；

若是，确认当前OTA数据与上一OTA数据之间无丢包情况；

若否，确认当前OTA数据与上一OTA数据之间存在丢包情况。

在一示例性的实施例中，第二序号节点具体用于：

当确认当前OTA数据与上一OTA数据之间无丢包情况，向第一序号节点返回比较结果，并将OTA数据下发到下一节点；

当确认当前OTA数据与上一OTA数据之间存在丢包情况，向第一序号节点返回比较结果，以接收第一序号节点根据比较结果下发对应当前OTA数据的理论序号所对应的OTA数据，然后再次执行比较当前OTA数据的实际序号和理论序号是否一致的步骤。

在一示例性的实施例中，预设序号算法为：对上一OTA数据的实际序号加1确定当前OTA数据的计算序号。

在一示例性的实施例中，第一序号节点为OTA主控节点，第二序号节点为OTA从控节点。

在一示例性的实施例中，OTA从控节点通过网关以CAN协议与ECU节点通信。

在一示例性的实施例中，OTA从控节点还用于：

当接收到ECU节点返回的节点应答信息，生成链路应答信息，并上传到上一节点；

第二SPI节点、第一SPI节点还用于：

当接收到下一节点返回的链路应答信息，将链路应答信息上传到上一节点；

OTA主控节点还用于：

当接收到第一SPI节点返回的链路应答信息，则确认当前OTA数据已正确发送至ECU节点。

在一示例性的实施例中，OTA主控节点还用于：

向第一SPI节点下发OTA数据后开始计时；

若链路预设时间内收到第一SPI节点返回的链路应答信息，则确认当前OTA数据已正确发送至ECU节点；

若链路预设时间未收到第一SPI节点返回的链路应答信息，则确认当前OTA数据发送超时。

本申请实施例通过在节点上增加接收OTA数据同时反馈节点应答信息的机制，提高了OTA数据传输的链路上各段传输的可靠性，解决了原本双核通信易丢包的问题，同时可实现故障节点的有效定位，减少升级重刷的次数，升级刷写成功率高。

图6是本申请实施例提供的电子设备6的示意图。如图6所示，该实施例的电子设备6包括：处理器601、存储器602以及存储在该存储器602中并且可在处理器601上运行的计算机程序603。处理器601执行计算机程序603时实现上述各装置实施例中各模块/单元的功能。

电子设备6可以是车辆系统、桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备6可以包括但不仅限于处理器601和存储器602。本领域技术人员可以理解，图6仅仅是电子设备6的示例，并不构成对电子设备6的限定，可以包括比图示更多或更少的部件，或者不同的部件。

处理器601可以是中央处理单元(Central Processing Unit，CPU)，也可以是其它通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。

存储器602可以是电子设备6的内部存储单元，例如，电子设备6的硬盘或内存。存储器602也可以是电子设备6的外部存储设备，例如，电子设备6上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。存储器602还可以既包括电子设备6的内部存储单元也包括外部存储设备。存储器602用于存储计算机程序以及电子设备所需的其它程序和数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读存储介质中，例如计算机可读存储介质。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。可读存储介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。