CN116192625A - 车辆配置信息的更新方法、车辆ota系统及可读介质 - Google Patents

Abstract

本发明提供了一种车辆配置信息的更新方法、车辆OTA系统及可读介质，车辆配置信息的更新方法应用于车辆OTA系统，包括：车辆OTA系统启动后，加载本地车辆配置信息，本地车辆配置信息包括第一配置文件；将第一配置文件的md5值和第一配置文件的版本号发送给云端；当接收到云端发送的配置信息不一致的通知时，获取并保存云端车辆配置信息，云端车辆配置信息包括第二配置文件；解析云端车辆配置信息，将云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能。本发明通过将车辆配置信息与OTA系统解耦，配置信息可实时线上更新。

Description

车辆配置信息的更新方法、车辆OTA系统及可读介质

技术领域

本发明主要涉及车联网技术领域，尤其涉及一种车辆配置信息的更新方法、车辆OTA系统及可读介质。

背景技术

随着空中下载技术(Over-The-Air Technology，简称OTA)的发展，越来越多的厂商将OTA技术应用到车辆上，通过OTA在云端下载升级包对汽车的电子控制单元(Electronic Control Unit，简称ECU)进行远程升级。

在传统的车载OTA系统中，配置信息与OTA系统版本绑定，需要OTA系统软件更新，且所处控制器升级版本后，才能加载最新的配置，整个更新流程繁琐滞后。如果OTA系统软件所处控制器未能升级版本，则不能加载最新配置，有OTA任务失败风险。

因此，亟需一种能实时更新车辆OTA系统配置信息的方法。

发明内容

本发明要解决的技术问题是提供一种车辆OTA系统配置的更新方法，解决配置信息更新流程繁琐滞后的问题。

为解决上述技术问题，本发明提供了一种车辆配置信息的更新方法，应用于车辆OTA系统，包括：车辆OTA系统启动后，加载本地车辆配置信息，所述本地车辆配置信息包括第一配置文件；将所述第一配置文件的md5值和第一配置文件的版本号发送给云端；当接收到所述云端发送的配置信息不一致的通知时，获取并保存云端车辆配置信息，所述云端车辆配置信息包括第二配置文件；解析所述云端车辆配置信息，将所述云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能。

可选地，在将所述云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能之前还包括：对解析出的第二配置文件进行文件格式校验和数据格式校验，当其中任一项校验失败时，结束更新流程。

可选地，在将所述云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能之前还包括：判断解析出的第二配置文件与所述第一配置文件是否一致，如果一致，则结束更新流程。

可选地，在将所述云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能之前还包括：判断所述云端车辆配置信息涉及的OTA系统服务是否在执行其他任务，如果是，则等待其他任务执行完毕。

为解决上述技术问题，本发明提供了一种车辆OTA系统，包括：配置获取单元，配置为车辆OTA系统启动后，加载本地车辆配置信息所述本地车辆配置信息包括第一配置文件；通信单元，配置为将所述第一配置文件的md5值和第一配置文件的版本号发送给云端，以及当接收到云端发送的配置信息不一致的通知时，获取云端车辆配置信息；存储单元，配置为保存所述云端车辆配置信息，所述云端车辆配置信息包括第二配置文件；控制单元，配置为解析所述云端车辆配置信息，将所述云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能。

可选地，所述控制单元还配置为对解析出的第二配置文件进行文件格式校验和数据格式校验，当其中任一项校验失败时，结束更新流程。

可选地，所述控制单元还配置为判断解析出的第二配置文件与所述第一配置文件是否一致，如果一致，则结束更新流程。

可选地，所述控制单元还配置为判断所述云端车辆配置信息涉及的OTA系统服务是否在执行其他任务，如果是，则等待其他任务执行完毕。

为解决上述技术问题，本发明提供了一种车辆配置信息的更新系统，包括：如上所述的车辆OTA系统；云端，配置为接收第一配置文件的md5值和第一配置文件的版本号，根据所述第一配置文件的md5值和第一配置文件的版本号判断是否产生配置信息不一致的通知，以及将云端车辆配置信息发送给所述车辆OTA系统，所述云端车辆配置信息包括第二配置文件。

可选地，根据所述第一配置文件的md5值和第一配置文件的版本号判断是否产生配置信息不一致的通知的步骤包括：对比所述第一配置文件的md5值与所述第二配置文件的md5值是否一致，且对比所述第一配置文件的版本号与所述第二配置文件的版本号是否一致，当其中任一项不一致时，产生所述通知。

为解决上述技术问题，本发明提供了一种存储有计算机程序代码的计算机可读介质，所述计算机程序代码在由为解决上述技术问题，本发明提供了处理器执行时实现如上所述的方法。

与现有技术相比，本发明具有以下优点：

本发明的车辆配置信息的更新方法通过将车辆配置信息与OTA系统解耦，只需要云端对车辆配置信息更新升级，车端OTA系统就能接收最新配置信息，配置信息可实时线上更新，车辆即时生效，无需重启车辆OTA系统。

附图说明

包括附图是为提供对本申请进一步的理解，它们被收录并构成本申请的一部分，附图示出了本申请的实施例，并与本说明书一起起到解释本发明原理的作用。附图中：

图1是根据本发明一实施例的车辆配置信息的更新方法的流程图。

图2是根据本发明一实施例的车辆配置信息的更新系统的系统框图。

具体实施方式

为了更清楚地说明本申请的实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其他的步骤或元素。

除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本申请的范围。同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

此外，需要说明的是，使用“第一”、“第二”等词语来限定零部件，仅仅是为了便于对相应零部件进行区别，如没有另行声明，上述词语并没有特殊含义，因此不能理解为对本申请保护范围的限制。此外，尽管本申请中所使用的术语是从公知公用的术语中选择的，但是本申请说明书中所提及的一些术语可能是申请人按他或她的判断来选择的，其详细含义在本文的描述的相关部分中说明。此外，要求不仅仅通过所使用的实际术语，而是还要通过每个术语所蕴含的意义来理解本申请。

本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或下面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。同时，或将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

正如背景技术提到的在传统的车载OTA系统中，配置信息与OTA系统版本绑定，需要OTA系统软件更新，且所处控制器升级版本后，才能加载最新的配置，整个更新流程繁琐滞后。针对上述问题，本发明提供一种车辆配置信息的热更新方法，能实时更新车辆OTA系统配置信息。

图1是根据本发明一实施例的车辆配置信息的更新方法的流程图。如图1所示，车辆配置信息的更新方法100包括如下步骤：

步骤S11：车辆OTA系统启动后，加载本地车辆配置信息，本地车辆配置信息包括第一配置文件。

车辆OTA系统启动后，开启配置服务，配置服务加载当前的本地车辆配置信息。具体地，配置服务加载第一配置文件并对第一配置文件进行解析，以供系统执行OTA升级任务使用。第一配置文件包括ECU标定配置信息和ECU物流配置信息。ECU标定配置信息包括但不限于是ECU信息、ECU诊断信息、升级重试次数、升级模式等。ECU物流配置信息包括但不限于是ECU诊断ID信息，ECU地址，ECU网络类型等。

步骤S12：将第一配置文件的md5值和第一配置文件的版本号发送给云端。

车辆OTA系统启动后与云端建立通信，车辆OTA系统将第一配置文件的md5值和第一配置文件的版本号发送给云端。云端上存储有云端车辆配置信息，云端车辆配置信息包括第二配置文件。云端接收到第一配置文件的md5值和第一配置文件的版本号之后，将第一配置文件的md5值和第一配置文件的版本号与第二配置文件的md5值和第二配置文件的版本号进行对比。具体地，对比第一配置文件的md5值与第二配置文件的md5值是否一致，且对比第一配置文件的版本号与第二配置文件的版本号是否一致，当其中任一项不一致时，产生配置信息不一致的通知，将该通知发送给车辆OTA系统。当两项对比的结果都是一致时，结束配置信息更新流程，车辆OTA系统等待执行OTA任务。

步骤S13：当接收到云端发送的配置信息不一致的通知时，获取并保存云端车辆配置信息，云端车辆配置信息包括第二配置文件。

当接收到云端发送的配置信息不一致的通知时，车辆OTA系统向云端请求云端车辆配置信息，云端将云端车辆配置信息发送给车辆OTA系统。车辆OTA系统接收云端车辆配置信息并备份保存。

步骤S14：解析云端车辆配置信息，将云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能。

车辆OTA系统的配置服务解析云端车辆配置信息，之后通知OTA系统加载云端车辆配置信息。OTA系统主进程接收配置服务的通知，通知该云端车辆配置信息涉及的OTA系统服务加载第二配置文件，然后重置OTA功能。

在一些实施例中，将云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能之前还包括：对解析出的第二配置文件进行文件格式校验和数据格式校验，当其中任一项校验失败时，结束更新流程。其中第二配置文件的格式包括但不限于是JSON格式或XML格式。文件格式校验是指通过JSON协议或XML协议校验第二配置文件的文件格式是否正确。数据格式校验是指对第二配置文件中的配置项数据格式进行校验，例如，判断配置项数据是否符合整数型(int)格式、判断是否符合布尔值格式等。当其中任一项校验失败时，结束更新流程。在一些实施例中，当其中任一项校验失败时，结束更新流程并根据错误原因向云端反馈错误码，以便提醒云端修改车辆配置信息。当两项校验都成功时，将云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能。

在一些实施例中，将云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能之前还包括：判断解析出的第二配置文件与第一配置文件是否一致，如果一致，表示不需要进行更新，结束更新流程。如果不一致，则继续进行配置信息更新流程，例如将云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能。

在一些实施例中，在将云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能之前还包括：判断云端车辆配置信息涉及的OTA系统服务是否在执行其他任务，如果是，则等待其他任务执行完毕。如果OTA系统服务正在执行OTA升级任务或其他高优先级任务，此时加载第二配置文件可能会对当前任务造成影响，导致任务失败。因此，在将云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能之前需要判断OTA系统服务的状态，当OTA系统服务在执行其他任务时，等待其他任务执行完毕，然后再执行配置信息更新。

本发明的车辆配置信息的更新方法通过将车辆配置信息与OTA系统解耦，只需要云端对车辆配置信息更新升级，车端OTA系统就能接收最新配置信息，配置信息可实时线上更新，车辆即时生效，无需重启车辆OTA系统。

图2是根据本发明一实施例的车辆配置信息的更新系统的系统框图。如图2所示，车辆配置信息的更新系统200包括车辆OTA系统21和云端22。车辆OTA系统21包括配置获取单元211、通信单元212、存储单元213和控制单元214。

其中，获取单元211配置为车辆OTA系统启动后，加载本地车辆配置信息所述本地车辆配置信息包括第一配置文件。通信单元212配置为将所述第一配置文件的md5值和第一配置文件的版本号发送给云端22。

云端22配置为接收第一配置文件的md5值和第一配置文件的版本号，根据所述第一配置文件的md5值和第一配置文件的版本号判断是否产生配置信息不一致的通知。云端22上存储有云端车辆配置信息，云端车辆配置信息包括第二配置文件。在一些实施例中，根据所述第一配置文件的md5值和第一配置文件的版本号判断是否产生配置信息不一致的通知的步骤包括：对比所述第一配置文件的md5值与所述第二配置文件的md5值是否一致，且对比所述第一配置文件的版本号与所述第二配置文件的版本号是否一致，当其中任一项不一致时，产生配置信息不一致的通知。

通信单元212还配置为当接收到云端22发送的配置信息不一致的通知时，获取云端车辆配置信息。具体地，当通信单元212接收到云端22发送的配置信息不一致的通知时，向云端22请求云端车辆配置信息。云端22还配置为接收到通信单元212的请求时，将云端车辆配置信息发送给通信单元212。

存储单元213配置为保存所述云端车辆配置信息。控制单元214配置为解析所述云端车辆配置信息，将所述云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能。

在一些实施例中，控制单元214还配置为对解析出的第二配置文件进行文件格式校验和数据格式校验，当其中任一项校验失败时，结束更新流程。

在一些实施例中，控制单元214还配置为判断解析出的第二配置文件与第一配置文件是否一致，如果一致，则结束更新流程。

在一些实施例中，控制单元214还配置为判断云端车辆配置信息涉及的OTA系统服务是否在执行其他任务，如果是，则等待其他任务执行完毕。

本申请还包括一种存储有计算机程序代码的计算机可读介质，该计算机程序代码在由处理器执行时实现前文的车辆配置信息的更新方法。

车辆配置信息的更新方法实施为计算机程序时，也可以存储在计算机可读存储介质中作为制品。例如，计算机可读存储介质可以包括但不限于磁存储设备(例如，硬盘、软盘、磁条)、光盘(例如，压缩盘(CD)、数字多功能盘(DVD))、智能卡和闪存设备(例如，电可擦除可编程只读存储器(EPROM)、卡、棒、键驱动)。此外，本文描述的各种存储介质能代表用于存储信息的一个或多个设备和/或其它机器可读介质。术语“机器可读介质”可以包括但不限于能存储、包含和/或承载代码和/或指令和/或数据的无线信道和各种其它介质(和/或存储介质)。

应该理解，上文所描述的实施例仅是示意。本文描述的实施例可在硬件、软件、固件、中间件、微码或者其任意组合中实现。对于硬件实现，处理器可以在一个或者多个特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器和/或设计为执行本文功能的其它电子单元或者其结合内实现。

本申请的一些方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。处理器可以是一个或多个专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理器件(DAPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器或者其组合。此外，本申请的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。例如，计算机可读介质可包括，但不限于，磁性存储设备(例如，硬盘、软盘、磁带……)、光盘(例如，压缩盘CD、数字多功能盘DVD……)、智能卡以及闪存设备(例如，卡、棒、键驱动器……)。

计算机可读介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等等、或合适的组合形式。计算机可读介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机可读介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、射频信号、或类似介质、或任何上述介质的组合。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其他的步骤或元素。

除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本申请的范围。同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，技术、方法和设备应当被视为授权说明书的一部分。在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

此外，需要说明的是，使用“第一”、“第二”等词语来限定零部件，仅仅是为了便于对相应零部件进行区别，如没有另行声明，上述词语并没有特殊含义，因此不能理解为对本申请保护范围的限制。此外，尽管本申请中所使用的术语是从公知公用的术语中选择的，但是本申请说明书中所提及的一些术语可能是申请人按他或她的判断来选择的，其详细含义在本文的描述的相关部分中说明。此外，要求不仅仅通过所使用的实际术语，而是还要通过每个术语所蕴含的意义来理解本申请。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述申请披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

Claims (11)

1.一种车辆配置信息的更新方法，应用于车辆OTA系统，其特征在于，包括：

车辆OTA系统启动后，加载本地车辆配置信息，所述本地车辆配置信息包括第一配置文件；

将所述第一配置文件的md5值和第一配置文件的版本号发送给云端；

当接收到所述云端发送的配置信息不一致的通知时，获取并保存云端车辆配置信息，所述云端车辆配置信息包括第二配置文件；

解析所述云端车辆配置信息，将所述云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能。

2.如权利要求1所述的更新方法，其特征在于，在将所述云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能之前还包括：对解析出的第二配置文件进行文件格式校验和数据格式校验，当其中任一项校验失败时，结束更新流程。

3.如权利要求1所述的更新方法，其特征在于，在将所述云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能之前还包括：判断解析出的第二配置文件与所述第一配置文件是否一致，如果一致，则结束更新流程。

4.如权利要求1所述的更新方法，其特征在于，在将所述云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能之前还包括：

判断所述云端车辆配置信息涉及的OTA系统服务是否在执行其他任务，如果是，则等待其他任务执行完毕。

5.一种车辆OTA系统，其特征在于，包括：

配置获取单元，配置为车辆OTA系统启动后，加载本地车辆配置信息所述本地车辆配置信息包括第一配置文件；

通信单元，配置为将所述第一配置文件的md5值和第一配置文件的版本号发送给云端，以及当接收到云端发送的配置信息不一致的通知时，获取云端车辆配置信息；

存储单元，配置为保存所述云端车辆配置信息，所述云端车辆配置信息包括第二配置文件；

控制单元，配置为解析所述云端车辆配置信息，将所述云端车辆配置信息涉及的OTA系统服务加载第二配置文件并重置OTA功能。

6.如权利要求5所述的系统，其特征在于，所述控制单元还配置为对解析出的第二配置文件进行文件格式校验和数据格式校验，当其中任一项校验失败时，结束更新流程。

7.如权利要求5所述的系统，其特征在于，所述控制单元还配置为判断解析出的第二配置文件与所述第一配置文件是否一致，如果一致，则结束更新流程。

8.如权利要求5所述的系统，其特征在于，所述控制单元还配置为判断所述云端车辆配置信息涉及的OTA系统服务是否在执行其他任务，如果是，则等待其他任务执行完毕。

9.一种车辆配置信息的更新系统，其特征在于，包括：

如权利要求5-8任一项所述的车辆OTA系统；

云端，配置为接收第一配置文件的md5值和第一配置文件的版本号，根据所述第一配置文件的md5值和第一配置文件的版本号判断是否产生配置信息不一致的通知，以及将云端车辆配置信息发送给所述车辆OTA系统，所述云端车辆配置信息包括第二配置文件。

10.如权利要求9所述的系统，其特征在于，根据所述第一配置文件的md5值和第一配置文件的版本号判断是否产生配置信息不一致的通知的步骤包括：

对比所述第一配置文件的md5值与所述第二配置文件的md5值是否一致，且对比所述第一配置文件的版本号与所述第二配置文件的版本号是否一致，当其中任一项不一致时，产生所述通知。

11.一种存储有计算机程序代码的计算机可读介质，所述计算机程序代码在由处理器执行时实现如权利要求1-4任一项所述的方法。

Images