车辆远程软件升级方法及装置与流程

1.本技术涉及车辆技术领域，特别涉及一种车辆远程软件升级方法及装置


背景技术：

2.随着汽车电子技术的不断发展，车载ecu(electronic control unit，电子控制单元)在现代汽车中得到了广泛的应用。电子控制单元在提高汽车动力性、经济性、舒适性和安全性的同时，也使得车辆中的电子电气系统越来越复杂，控制单元及软件数量成几何倍数的增长。
3.然而，由于控制单元及软件数量爆发式增长，使得软件造成的故障问题也越来越多，亟待解决。
4.申请内容
5.本技术提供一种车辆远程软件升级方法及装置，以解决因控制单元及软件数量爆发式增长，使得软件造成的故障问题也越来越多的问题，确保售后市场使用刷写终端对车载ecu软件进行远程升级时的安全性，构建合理的升级流程来满足终端用户的需求，实现升级过程可控，且升级结果可追溯。
6.本技术第一方面实施例提供一种车辆远程软件升级方法，包括以下步骤：
7.接收刷写终端发送的鉴权信息；
8.在所述鉴权信息验证通过后，接收刷写服务器基于所述鉴权信息发送的出厂配置文件，并比较所述出厂配置文件与所述车辆的每个电子控制单元的当前配置信息；以及
9.若所述出厂配置文件、所述当前配置信息和当前升级任务判定所述车辆满足自定义升级条件和/或恢复出厂升级条件，则根据软件数据包控制所述刷写终端对所述车辆的对应的电子控制单元进行软件升级。
10.可选地，上述的车辆远程软件升级方法，还包括：
11.在所述鉴权信息验证失败后，提示鉴权确认提醒，以根据所述鉴权信息在所述刷写服务器上注册所述刷写终端。
12.可选地，所述出厂配置文件包括所述车辆的每个电子控制单元的装配信息、软件配置信息、控制器零件号、软/硬件版本号、刷写文件中的一项或多项，其中，所述接收刷写服务器基于所述鉴权信息发送的出厂配置文件，包括：
13.从所述鉴权信息中提取所述车辆的身份标识，或者接收用户输入的所述身份标识；
14.发送所述身份标识至所述刷写服务器，以得到所述出厂配置文件。
15.可选地，所述根据所述软件数据包控制所述刷写终端对所述车辆的对应的电子控制单元进行软件升级，包括：
16.判断所述软件数据包的升级类别；
17.若所述升级类别为强制类别，则直接进行软件升级；
18.若所述升级类别为非强制类别，则识别所述用户的升级需求，并在升级需求为确
认升级时进行软件升级。
19.可选地，其中，任一电子控制单元均满足所述自定义升级条件和所述恢复出厂升级条件，则自定义升级的升级顺序高于恢复出厂升级的升级顺序。本技术第二方面实施例提供一种车辆远程软件升级装置，包括：
20.接收模块，用于接收刷写终端发送的鉴权信息；
21.比较模块，用于在所述鉴权信息验证通过后，根据所述鉴权信息获取出厂配置文件，并比较所述出厂配置文件与所述车辆的每个电子控制单元的当前配置信息；以及
22.升级模块，用于若所述出厂配置文件、所述当前配置信息和当前升级任务判定所述车辆满足自定义升级条件和/或恢复出厂升级条件，则根据软件数据包控制所述刷写终端对所述车辆的对应的电子控制单元进行软件升级。
23.可选地，上述的车辆远程软件升级装置，还包括：
24.刷写模块，用于在所述鉴权信息验证失败后，提示鉴权确认提醒，以根据所述鉴权信息在所述刷写服务器上注册所述刷写终端。
25.可选地，所述出厂配置文件包括所述车辆的每个电子控制单元的装配信息、软件配置信息、控制器零件号、软/硬件版本号、刷写文件中的一项或多项，其中，所述比较模块，具体用于：
26.从所述鉴权信息中提取所述车辆的身份标识，或者接收用户输入的所述身份标识；
27.发送所述身份标识至所述刷写服务器，以得到所述出厂配置文件。
28.可选地，所述升级模块，具体用于：
29.判断所述软件数据包的升级类别；
30.若所述升级类别为强制类别，则直接进行软件升级；
31.若所述升级类别为非强制类别，则识别所述用户的升级需求，并在升级需求为确认升级时进行软件升级。
32.可选地，其中，任一电子控制单元均满足所述自定义升级条件和所述恢复出厂升级条件，则自定义升级的升级顺序高于恢复出厂升级的升级顺序。
33.由此，可以接收刷写终端发送的鉴权信息，并在鉴权信息验证通过后，根据鉴权信息获取出厂配置文件，并比较出厂配置文件与车辆的每个电子控制单元的当前配置信息，并在若出厂配置文件、当前配置信息和当前升级任务判定车辆满足自定义升级条件和/或恢复出厂升级条件，则根据软件数据包控制刷写终端对车辆的对应的电子控制单元进行软件升级。由此，解决了因控制单元及软件数量爆发式增长，使得软件造成的故障问题也越来越多的问题，确保售后市场使用刷写终端对车载ecu软件进行远程升级时的安全性，构建合理的升级流程来满足终端用户的需求，实现升级过程可控，且升级结果可追溯。
34.本技术附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本技术的实践了解到。
附图说明
35.本技术上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
36.图1为根据本技术实施例提供的一种车辆远程软件升级方法的流程图；
37.图2为根据本技术一个实施例的车辆远程软件升级方法的流程图；
38.图3为申请实施例提供的车辆远程软件升级装置的方框示意图。
具体实施方式
39.下面详细描述本技术的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本技术，而不能理解为对本技术的限制。
40.下面参考附图描述本技术实施例的车辆远程软件升级方法及装置。针对上述背景技术中心提到的因控制单元及软件数量爆发式增长，使得软件造成的故障问题也越来越多的问题，本技术提供了一种车辆远程软件升级方法，在该方法中，可以接收刷写终端发送的鉴权信息，并在鉴权信息验证通过后，根据鉴权信息获取出厂配置文件，并比较出厂配置文件与车辆的每个电子控制单元的当前配置信息，并在若出厂配置文件、当前配置信息和当前升级任务判定车辆满足自定义升级条件和/或恢复出厂升级条件，则根据软件数据包控制刷写终端对车辆的对应的电子控制单元进行软件升级。由此，解决了因控制单元及软件数量爆发式增长，使得软件造成的故障问题也越来越多的问题，确保售后市场使用刷写终端对车载ecu软件进行远程升级时的安全性，构建合理的升级流程来满足终端用户的需求，实现升级过程可控，且升级结果可追溯。
41.具体而言，图1为本技术实施例所提供的一种车辆远程软件升级方法的流程示意图。
42.如图1所示，该车辆远程软件升级方法包括以下步骤：
43.在步骤s101中，接收刷写终端发送的鉴权信息。
44.可选地，在一些实施例中，还包括：在鉴权信息验证失败后，提示鉴权确认提醒，以根据鉴权信息在刷写服务器上注册刷写终端。
45.如图2所示，刷写终端可以包括有多个功能，例如，软件升级、维修资料、本地诊断、云诊断、远程诊断、商家和特殊功能等。当售后服务站刷写终端准备与远程刷写后台进行信息交互时，后台会对刷写终端用户的合法性进行判定，只有验证合法后才能向下执行，否则刷写终端将与远程刷写后台停止信息交互，具体实现过程如下：
46.(1)售后服务站刷写终端的obd(on board diagnostics，汽车故障检测系统)接头连接到客户车辆，刷写终端联网，打开刷写终端软件，首先检查网络是否正常：如果无网络，刷写终端提示用户必须联网才能进行控制器软件在线刷写。如果有网络，用户输入鉴权相关信息。
47.(2)刷写终端自动将终端设备序列号，服务站注册信息等鉴权信息上传给远程刷写后台验证终端的合法性。
48.(3)若鉴权通过，则刷写终端将继续与远程刷写后台交互获取刷写相关信息；若鉴权失败，则刷写终端会提示用户确认鉴权信息，注册刷写终端。
49.在步骤s102中，在鉴权信息验证通过后，接收刷写服务器基于鉴权信息发送的出厂配置文件，并比较出厂配置文件与车辆的每个电子控制单元的当前配置信息。
50.可选地，在一些实施例中，出厂配置文件包括车辆的每个电子控制单元的装配信
息、软件配置信息、控制器零件号、软/硬件版本号、刷写文件中的一项或多项，其中，接收刷写服务器基于鉴权信息发送的出厂配置文件，包括：从鉴权信息中提取车辆的身份标识，或者接收用户输入的身份标识；发送身份标识至刷写服务器，以得到出厂配置文件。
51.具体地，结合图2所示，本技术实施例在鉴权信息验证通过后，需要获取车辆的出厂配置文件，出厂配置文件与车辆vin(vehicle identification number，车辆识别号码)码一一对应，文件中包含了指定整车各控制器的装配信息、软件配置信息、控制器零件号、软/硬件版本号，刷写文件等整车出厂时关联的配置信息。出厂配置文件为后续整车控制器扫描，车辆控制器软件升级更新提供了依据，具体实现过程如下：
52.(1)基于不同的年款车型，刷写终端可以通过自动读取车辆的vin码、用户手动输入车辆vin码等方式定位车辆的信息。刷写终端首先自动获取车辆vin(刷写终端根据预先定义的协议类型及相关指令，从当前车辆控制器读取车辆vin)。若刷写终端无法自动获取vin，则要求用户手动输入vin，为确保信息的正确性，需要用户重复输入两次vin进行比对，两次输入的vin一致则会进行下一步操作。
53.(2)刷写终端将自动/人工方式获取到的vin传递给远程刷写后台获取车辆出厂配置文件。
54.(3)当车辆在终检合格下线时，全车各控制器刷写相关的信息会以车辆出厂配置(.xml)文件的形式即时存储到远程刷写后台，远程刷写后台根据刷写终端提供的vin查询对应的车辆出厂配置文件。
55.(4)远程刷写后台将获取的车辆出厂配置文件输出给刷写终端。
56.在步骤s103中，若出厂配置文件、当前配置信息和当前升级任务判定车辆满足自定义升级条件和/或恢复出厂升级条件，则根据软件数据包控制刷写终端对车辆的对应的电子控制单元进行软件升级。
57.应当理解的是，结合图2所示，整车软件升级任务的判断是控制器远程刷写过程中的重要环节，需要充分考虑售后软件升级的多种场景，制定相应的升级策略，保证软件升级的过程可控。通常面对售后市场的软件升级可分为两个场景：恢复出厂和自定义软件升级。为精准提供车载控制器的升级服务，对车载控制器统一进行软件更新检查，需刷写终端与远程刷写后台建立功能逻辑，自动实现软件升级任务的判断，实现车载控制器的软件更新。具体实现过程如下：
58.(1)刷写终端解析远程刷写后台释放的车辆出厂配置文件，获取整车各控制器的装配情况，实时扫描全车各控制器相关信息(如零件号，软/硬件版本信息等)。
59.(2)刷写终端将扫描得到的车辆各控制器相关信息输出给远程刷写后台。
60.(3)当主机厂根据实际需求(软件优化，问题修复等)需要对车载控制器进行软件升级时，会创建相应的自定义升级任务(自定义升级任务的边界条件通常包括：控制器名称，零件号，软/硬件版本，vin清单等)，并推送给相应的车辆完成软件升级。远程刷写后台根据获取的车载控制器实际信息结合后台创建的各自定义升级任务的边界条件进行筛选，确认当前车辆是否存在自定义升级任务，若满足条件，会将自定义任务的相关信息传递给刷写终端。
61.(4)当用户车辆更换控制器备件时，需要将更换的控制器软件做恢复出厂的软件刷写。刷写终端将车载控制器实际的信息与出厂配置文件中获取的信息进行比对，判断是
否有车载控制器符合恢复出厂的升级条件。若某一车载控制器同时存在自定义升级和恢复出厂升级，则优先提示自定义升级。
62.可选地，在一些实施例中，根据软件数据包控制刷写终端对车辆的对应的电子控制单元进行软件升级，包括：判断软件数据包的升级类别；若升级类别为强制类别，则直接进行软件升级；若升级类别为非强制类别，则识别用户的升级需求，并在升级需求为确认升级时进行软件升级。
63.可选地，在一些实施例中，其中，任一电子控制单元均满足自定义升级条件和恢复出厂升级条件，则自定义升级的升级顺序高于恢复出厂升级的升级顺序。
64.应当理解的是，结合图2可知，刷写终端完成与远程刷写后台的交互，当前车辆的软件升级任务获取完毕后，刷写终端会自动列出当前车辆相关的软件升级任务并展示给用户，用户根据实际需求进行选择，完成车载控制器软件升级具体实现过程如下：
65.(1)刷写终端将软件升级任务展示给用户进行选择。主机厂根据实际需求，可定义强制/非强制任务，强制任务用户无法取消，非强制任务，用户可根据需求选择是否升级。用户确认升级需求后，刷写终端会根据不同的任务类型释放相应的信息(例如，恢复出厂的任务，提供vin，控制器及零件号等信息，自定义升级任务，提供vin，任务信息)给远程刷写后台查找软件升级数据包。
66.(2)远程刷写后台根据刷写终端提供的信息，查找对应的软件数据包。
67.(3)若用户不进行软件升级，则流程结束.
68.(4)控制器软件升级过程中(刷写文件下载，控制器软件数据升级)禁止用户执行退出、关闭等操作，同时刷写终端需给予用户相应的进度及出错提示，以便于用户了解车载控制器软件升级的进度及状态，必要时采取相应的应对措施。
69.(5)为便于主机厂对售后市场控制器软件升级进行管控，当控制器软件升级完成后，刷写终端需自动上报软件升级结果给远程刷写后台，升级结果通常包括：vin、控制器、零件号、当前软/硬件版本号、目标软/硬件版本号、升级时间、升级结果、刷写终端序列号等。当软件升级结果上传成功后，删除本地保存的结果。若车辆软件升级结果上报失败，则刷写终端需将软件升级结果加密保存在本地，待网络正常或下次刷写终端认证成功时，再次解密上传远程刷写后台。同时，为便于对控制器软件升级过程中出现的问题进行快速定位，对软件刷写的全过程(从诊断仪鉴权开始，到软件升级结束)，刷写终端需记录相应的日志。
70.根据本技术实施例提出的车辆远程软件升级方法，可以接收刷写终端发送的鉴权信息，并在鉴权信息验证通过后，根据鉴权信息获取出厂配置文件，并比较出厂配置文件与车辆的每个电子控制单元的当前配置信息，并在若出厂配置文件、当前配置信息和当前升级任务判定车辆满足自定义升级条件和/或恢复出厂升级条件，则根据软件数据包控制刷写终端对车辆的对应的电子控制单元进行软件升级。由此，解决了因控制单元及软件数量爆发式增长，使得软件造成的故障问题也越来越多的问题，确保售后市场使用刷写终端对车载ecu软件进行远程升级时的安全性，构建合理的升级流程来满足终端用户的需求，实现升级过程可控，且升级结果可追溯。
71.其次参照附图描述根据本技术实施例提出的车辆远程软件升级装置。
72.图3是本技术实施例的车辆远程软件升级装置的方框示意图。
73.如图3所示，该车辆远程软件升级装置10包括：接收模块100、比较模块200和升级模块300。
74.其中，接收模块100用于接收刷写终端发送的鉴权信息；
75.比较模块200用于在鉴权信息验证通过后，根据鉴权信息获取出厂配置文件，并比较出厂配置文件与车辆的每个电子控制单元的当前配置信息；以及
76.升级模块300用于若出厂配置文件、当前配置信息和当前升级任务判定车辆满足自定义升级条件和/或恢复出厂升级条件，则根据软件数据包控制刷写终端对车辆的对应的电子控制单元进行软件升级。
77.可选地，在一些实施例中，上述的车辆远程软件升级装置10，还包括：
78.刷写模块，用于在鉴权信息验证失败后，提示鉴权确认提醒，以根据鉴权信息在刷写服务器上注册刷写终端。
79.可选地，在一些实施例中，出厂配置文件包括车辆的每个电子控制单元的装配信息、软件配置信息、控制器零件号、软/硬件版本号、刷写文件中的一项或多项，其中，比较模块200具体用于：
80.从鉴权信息中提取车辆的身份标识，或者接收用户输入的身份标识；
81.发送身份标识至刷写服务器，以得到出厂配置文件。
82.可选地，在一些实施例中，升级模块300，具体用于：
83.判断软件数据包的升级类别；
84.若升级类别为强制类别，则直接进行软件升级；
85.若升级类别为非强制类别，则识别用户的升级需求，并在升级需求为确认升级时进行软件升级。
86.可选地，在一些实施例中，其中，任一电子控制单元均满足自定义升级条件和恢复出厂升级条件，则自定义升级的升级顺序高于恢复出厂升级的升级顺序。
87.需要说明的是，前述对车辆远程软件升级方法实施例的解释说明也适用于该实施例的车辆远程软件升级装置，此处不再赘述。
88.根据本技术实施例提出的车辆远程软件升级装置，可以接收刷写终端发送的鉴权信息，并在鉴权信息验证通过后，根据鉴权信息获取出厂配置文件，并比较出厂配置文件与车辆的每个电子控制单元的当前配置信息，并在若出厂配置文件、当前配置信息和当前升级任务判定车辆满足自定义升级条件和/或恢复出厂升级条件，则根据软件数据包控制刷写终端对车辆的对应的电子控制单元进行软件升级。由此，解决了因控制单元及软件数量爆发式增长，使得软件造成的故障问题也越来越多的问题，确保售后市场使用刷写终端对车载ecu软件进行远程升级时的安全性，构建合理的升级流程来满足终端用户的需求，实现升级过程可控，且升级结果可追溯。
89.在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本技术的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或n个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结
合和组合。
90.此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本技术的描述中，“n个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
91.流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更n个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本技术的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本技术的实施例所属技术领域的技术人员所理解。
92.应当理解，本技术的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，n个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，现场可编程门阵列(fpga)等。
93.本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。