一种软件包处理方法、装置、电子设备以及存储介质与流程

1.本技术涉及车辆信息安全技术领域，具体涉及一种软件包处理方法、装置、电子设备以及存储介质。


背景技术：

2.随着汽车的电动化、智能化、共享化及网联化的发展，人们对汽车的要求越来越高，现在不仅要求汽车满足驾驶舒适性，同样还对汽车功能的多样化有了更多的要求。目前，汽车的各种功能是在汽车的控制系统的控制下实现，如若需要对汽车的各种功能进行升级，通常需要对汽车的控制系统进行更新升级。
3.在现有技术中，通常在车辆上搭载有用于执行控制功能的多个车载设备(称为“ecu”)。该ecu具备处理器和存储部，通过处理器执行存储于存储部的软件来实现ecu的控制功能。另外，具体而言，在维修工厂等中，能够使用经由设置于车辆的诊断用连接控制器连接的外部设备来更新或开发软件。然而在更新或开发软件的过程中，由于每个连接控制器的block不一致或者安全算法不一致，导致针对每个不同的控制器进行单独的开发，导致开发效率较低。
4.因此，如何提高车辆空中下载技术的软件升级效率，是目前急需解决的问题。


技术实现要素：

5.本技术提供一种软件包处理方法、装置、电子设备以及存储介质，以提高基于车辆空中下载技术的软件升级的效率。
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.处理模块，其用于基于所述开发控制期策略对目标软件升级包进行处理，获取与车载终端相匹配的文件。
34.进一步的，所述处理模块还包括：
35.判断子模块，其用于判断所述目标软件升级包是否加密；
36.解密子模块，其用于若加密，则利用解密策略对所述目标软件升级包进行解密，得到解密后的目标软件包文件；
37.第一识别子模块，其用于基于所述开发控制器策略对所述目标软件包文件进行识别。
38.进一步的，所述第一识别子模块，包括：
39.标识获取单元，其用获取所述目标软件包文件的识别标识；
40.标识匹配单元，其用于若所述识别标识与控制器策略配置的标识一致，则对所述目标软件包进行处理。
41.进一步的，所述策略匹配模块包括：
42.参数标准获取模块，其用于基于各安全算法的输入参数以及输出参数，获取各安全算法的参数标准；
43.算法库封装模块，其用于基于安全算法函数、安全算法文件名、安全密钥以及所述各安全算法的参数标准，封装成各安全算法库。
44.进一步的，所述策略匹配模块还包括：
45.时长获取子模块，其用于获取各安全算法的安全密钥的有效时长；
46.第一密钥确定子模块，其用于将所述有效时长大于第一阈值的安全密钥确定为第一安全密钥；
47.第一存储子模块，其用于将所述第一安全密钥对应的安全算法库存储在车载数据库中。
48.进一步的，所述策略匹配模块还包括：
49.第二密钥确定子模块，其用于将所述有效时长小于第一阈值的安全密钥确定为第二安全密钥；
50.第二存储子模块，其用于将所述第二安全密钥对应的安全算法库存储在云端数据库中。
51.本技术提供的技术方案带来的有益效果包括：
52.在目标车辆的ota平台上基于各种类型的软件升级包的需求标准，配置开发控制器策略；获取目标软件升级包；基于所述开发控制期策略对目标软件升级包进行处理，获取与车载终端相匹配的文件。覆盖当前所有的控制器现状以及制定的各类标准的软件需求，同时需开发控制器策略所关联需要使用的动态执行文件库、安全算法管理库、静态解密库、差分工具库。当发布软件更新包时，首先将控制器在策略库里面进行配置，当软件包从生产系统传递过来时，依据接口逻辑以及所对应的控制器策略进行详细的处理，最终实现车端脚本能识别的文件，实现基于车辆空中下载技术的软件的可拓展性。
附图说明
53.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
54.图1为本技术实施例中提供的软件包处理方法的步骤流程图；
55.图2为一申请实施例中提供的软件包处理方法的应用环境图。
具体实施方式
56.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术的一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
57.以下结合附图对本技术的实施例作进一步详细说明。
58.本技术实施例提供一种软件包处理方法、装置、电子设备以及存储介质，以提高基于车辆空中下载技术的软件升级的效率。
59.为达到上述技术效果，本技术的总体思路如下：
60.参见图1所示，一种软件包处理方法，该方法包括以下步骤：
61.s1、基于各种类型的软件升级包的需求标准，配置开发控制器策略；
62.s2、获取目标软件升级包；
63.s3、基于所述开发控制期策略对目标软件升级包进行处理，获取与车载终端相匹
配的文件。
64.以下结合附图对本技术的实施例作进一步详细说明。
65.参见图1所示，本技术实施例提供一种软件包处理方法，该方法包括以下步骤：
66.s1、基于各种类型的软件升级包的需求标准，配置开发控制器策略；
67.其中，汽车ota功能是指空中下载技术，通过移动通信的接口实现对软件进行远程管理，到汽车修理店通过整车obd对相应的ecu进行软件升级。ota更新范围涉及人机交互、自动驾驶、动力、电池系统等模块，提升续航里程、提高最高速度、提升乘坐舒适度。ota技术对于新能源汽车来说非常重要，其就是可以对车辆系统进行远程操控，或者是说对车辆远程进行升级的。目前通过ota方式升级软件广泛应用于智能手机，通过网络自动下载升级包、自动升级。
68.pdm的中文名称为产品数据管理(product data management)，是一门用来管理所有与产品相关信息(包括零件信息、配置、文档、cad文件、结构、权限信息等)和所有与产品相关过程(包括过程定义和管理)的技术。通过实施pdm，可以提高生产效率，有利于对产品的全生命周期进行管理，加强对于文档，图纸，数据的高效利用，使工作流程规范化。
69.具体地，在目标车辆的ota平台上获取上一次更新的软件升级包，从该软件升级包中获取参数脚本、升级脚本、程序包传输脚本、回滚脚本、取消升级脚本等，再基于上述脚本对控制器策略中的工作电源模式、升级相关的标准、安全算法等级及库以及异常处理标准进行相配置。
70.s2、获取目标软件升级包；
71.s3、基于开发控制期策略对目标软件升级包进行处理，获取与车载终端相匹配的文件。
72.如图2所示，本技术实施例中的软件包处理方法可以运用在该软件环境中：
73.pdm平台基于目标车辆中的产品数据的变动生成软件更新包，并通过pdm平台与ota平台之间的连接通道将该软件更新包发送给就ota平台；
74.而ota平台在接收该软件更新包之前就依据获取参数脚本、升级脚本、程序包传输脚本、回滚脚本、取消升级脚本等脚本进行了策略配置，然后调用控制器策略对软件更新包进行解密或者解压缩，然后再对经过解压缩或者解密的软件更新文件进行预处理，再将预处理的更新文件发送给车载终端。
75.可以理解的是，车载终端可以对经过预处理的软件更新文件进行识别。因此，车载终端在接收到对经过预处理的软件更新文件后，对其进行识别与处理。
76.在本技术实施例中，在目标车辆的ota平台上基于各种类型的软件升级包的需求标准，配置开发控制器策略；获取目标软件升级包；基于所述开发控制期策略对目标软件升级包进行处理，获取与车载终端相匹配的文件。覆盖当前所有的控制器现状以及制定的各类标准的软件需求，同时需开发控制器策略所关联需要使用的动态执行文件库、安全算法管理库、静态解密库、差分工具库。当发布软件更新包时，首先将控制器在策略库里面进行配置，当软件包从生产系统传递过来时，依据接口逻辑以及所对应的控制器策略进行详细的处理，最终实现车端脚本能识别的文件，实现基于车辆空中下载技术的软件的可拓展性。
77.在一申请实施例中，步骤s3包括：
78.判断目标软件升级包是否加密；若加密，则利用解密策略对目标软件升级包进行
解密，得到解密后的目标软件包文件；基于开发控制器策略对所述目标软件包文件进行识别。
79.需要说明的是，软件包处理及识别逻辑主要是设计各种状态的逻辑关系来识别到数据源头传递过来的软件包，并将其放置在每个零件号下的每一个供应商各自的软件管理清单中。整体设计需覆盖前期研究的所有软件结构关系。软件包处理模块需要依据数据层输入的软件零件号、软件唯一标识码、软件类型、软件包上层状态、是否为加密、软件包的类型、供应商信息参数进行进行对不同的软件结构体进行处理和识别。
80.软件唯一标识和软件类型是用于关联在系统中的控制器策略，便于后续的软件特殊处理和刷写逻辑方式处理；根据软件唯一标识确定软件包是否加密；若加密则调用控制器策略中的解密策略对软件包进行解密；若不加密，则无需处理直接跳转至软件包内部的识别逻辑进行处理。
81.在一申请实施例中，步骤s3之前，包括：
82.获取目标软件包文件的识别标识；若识别标识与控制器策略配置的标识一致，则对目标软件包进行处理。
83.具体地，可以设计解析软件包里面首个英文的“_”的第一个字母为控制器策略配置的供应商标识配置；解析标识配置与控制器策略配置的标识是否一致，范围内则进行识别，不在范围内则异常不进行处理；若无解析标识配置，则需判断软件供应商数量，若该软件供应商数量为1，则进行识别处理；若该软件供应商数量大于1，则判断为处理异常不再进行处理，最后需要调用控制器策略里面判断必须判断的版本信息，保证信息完整性。
84.在一申请实施例中，步骤s1包括：
85.s101，基于各安全算法的输入参数以及输出参数，获取各安全算法的参数标准；
86.将安全算法的入参和出参形成标准，在封装库接口里面将每种安全算法标准开发完成，当在ota云端进行上传安全算法，需对安全算法进行标准选择、配置函数名称、文件名称，最终在调用的时候，通过控制器策略里面配置的安全算法函数名以及安全算法等级输入给封装库接口转换成对应的入参和出参要求，调用对应的安全算法文件，输出安全密钥。
87.s102，基于安全算法函数、安全算法文件名、安全密钥以及各安全算法的参数标准，封装成各安全算法库。
88.获取各安全算法的安全密钥的有效时长，将有效时长大于第一阈值的安全密钥确定为第一安全密钥，将第一安全密钥对应的安全算法库存储在车载数据库中。
89.a1、若安全密钥的有效时间小于10s时，将其内置在车载终端，需要在车载终端开放一个专门用于存放内置安全算法库的存储区域，约定安全算法的入参和出参的标准，在车端将其约定完成的安全算法标准开发完成。然后通过云端下发的安全算法函数、安全算法文件名、seed的长度、key的长度以及对应的执行安全算法执行标准按需灵活动态调用内置的安全算法库；
90.a2、若安全密钥的有效时间大于10s时，则将其置于云端，在云端上传对应的.so的安全算法文件，选择其安全算法的标准，以及对应安全算法函数、安全算法文件名、seed的长度、key的长度。
91.本技术中首先通过驾驶员实时人体特征信息以及驾驶员历史患病信息确定驾驶员疑似患病类型，再根据目标车辆的异常行驶行为信息来确定驾驶员的患病概率，也就是
本技术中通过摄像装置获取驾驶员的人体特征信息，再基于该人体特征信息利用算法推断出驾驶员患病类型，避免了直接通过在目标车辆上安装体征参数检测物联网设备获取人体健康状态的稳定性较差以及误报率高的问题，从而提高了车辆在行驶过程中对驾驶员的健康状态进行识别的效率。
92.在一申请实施例中，步骤s2还包括以下步骤：
93.a，定义一个识别控制器软件刷写的唯一标识码；
94.b，工作电源模式配置:依据不同控制器在不同的车型平台或者不同的驾驶室网络拓扑以及工作电源模式都存在有所不一样的情况，可以进行动态配置；
95.c，升级相关的标准及脚本配置：根据控制器的状态配置其标准以及每种标准所对应的刷写脚本，车端会依据刷写标准判断刷写脚本和执行的详细逻辑；
96.d，首先先进行安全算法库设计，依据安全算法key的有效时间进行分类设计：设计安全算法库的执行函数。
97.e，设计特殊升级模块：特殊升级模块主要是用于一些非标准，需要进行特殊处理的控制器的特定操作，在设计过程中默认该部分为否：
98.数据填充，数据填充默认为否，当选择是后则需要选择其对应的执行填充的标准。其作用主要是对控制器的基础软件刷写程序进行数据填充，将需要进行不同的数据填充做成对应的标准库，在配置的时候，将约定好的配置标准通过ota云端输入给数据填充动态库进行调用其内部的不同执行代码，最终达到动态处理数据填充的方案，且每一个数据充填标准模块相对独立，通过入参调用不同的执行函数便于后续的可拓展性。
99.数据分块，数据分块是用于解决控制器的程序文件虽然为s19或hex，但是有非标准的情况时调用该模块进行处理，在云端处理后到车端变成标准的刷写文件。先将需要进行特殊数据分块处理的控制器在数据分块库文件里面包含，同时输入的type支持在数据字典里面配置后，在控制器策略模块里面进行选择。在使用的时候ota云端将数据分块的type、需要处理的包地址给到数据分块库文件，库文件按照刷写的block顺序进行文件排序，并且将处理后的文件置于根目录压缩成.zip文件，然后在需要升级的时候下发给车端。该模块设计较为独立，不同的数据分块类型处理完全独立。
100.boot升级，该功能默认关闭，当控制器需要进行boot,且boot跟主程序是两个不同的程序包、不能随着升级的目标程序包在生产系统中发布且需要升级主控对其进行直接刷写的控制器就需要选择boot升级，该功能主要是将boot包放置在云端，然后通过ota配置清单下发至车端，当需要对该控制器进行升级时，优先调用boot文件升级后，再调用程序包进行升级。
101.f，否定码设计：依据各控制器的内部设计逻辑和整车ota整体设计逻辑，对每个控制器的否定码进行处理，用于在升级过程中出现执行失败后的处理逻辑判断以及在整车ota其他的模块中用于维护故障排查手册所使用，可实现在线动态快速化排查问题，提高运营人员解决问题的效率。
102.在ota平台上，覆盖当前所有的控制器现状以及制定的各类标准的软件需求，同时需开发控制器策略所关联需要使用的动态执行文件库、安全算法管理库、静态解密库、差分工具库。当发布软件更新包时，首先将控制器在策略库里面进行配置，当软件包从生产系统传递过来时，依据接口逻辑以及所对应的控制器策略进行详细的处理，最终实现车端脚本
能识别的文件，实现基于车辆空中下载技术的软件的可拓展性。
103.需要说明的是，本技术实施例中的各步骤的步骤标号，其并不限制本技术技术方案中各操作的前后顺序。
104.需要说明的是，本技术实施例提供的软件包处理装置，其对应的技术问题、技术手段以及技术效果，从原理层面与软件包处理方法的原理类似。
105.基于与车辆控制方法实时例相同的发明构思，本技术实施例提供一种软件包处理装置，该装置包括：
106.策略配置模块，其用于基于各种类型的软件升级包的需求标准，配置开发控制器策略；
107.升级包获取模块，其用于获取目标软件升级包；
108.处理模块，其用于基于所述开发控制期策略对目标软件升级包进行处理，获取与车载终端相匹配的文件。
109.具体地，在目标车辆的ota平台上获取上一次更新的软件升级包，从该软件升级包中获取参数脚本、升级脚本、程序包传输脚本、回滚脚本、取消升级脚本等，再基于上述脚本对控制器策略中的工作电源模式、升级相关的标准、安全算法等级及库以及异常处理标准进行相配置。
110.pdm平台基于目标车辆中的产品数据的变动生成软件更新包，并通过pdm平台与ota平台之间的连接通道将该软件更新包发送给就ota平台；
111.而ota平台在接收该软件更新包之前就依据获取参数脚本、升级脚本、程序包传输脚本、回滚脚本、取消升级脚本等脚本进行了策略配置，然后调用控制器策略对软件更新包进行解密或者解压缩，然后再对经过解压缩或者解密的软件更新文件进行预处理，再将预处理的更新文件发送给车载终端。
112.可以理解的是，车载终端可以对经过预处理的软件更新文件进行识别。因此，车载终端在接收到对经过预处理的软件更新文件后，对其进行识别与处理。
113.软件唯一标识和软件类型是用于关联在系统中的控制器策略，便于后续的软件特殊处理和刷写逻辑方式处理；根据软件唯一标识确定软件包是否加密；若加密则调用控制器策略中的解密策略对软件包进行解密；若不加密，则无需处理直接跳转至软件包内部的识别逻辑进行处理。
114.可以设计解析软件包里面首个英文的“_”的第一个字母为控制器策略配置的供应商标识配置；解析标识配置与控制器策略配置的标识是否一致，范围内则进行识别，不在范围内则异常不进行处理；若无解析标识配置，则需判断软件供应商数量，若该软件供应商数量为1，则进行识别处理；若该软件供应商数量大于1，则判断为处理异常不再进行处理，最后需要调用控制器策略里面判断必须判断的版本信息，保证信息完整性。
115.本技术中首先通过驾驶员实时人体特征信息以及驾驶员历史患病信息确定驾驶员疑似患病类型，再根据目标车辆的异常行驶行为信息来确定驾驶员的患病概率，也就是本技术中通过摄像装置获取驾驶员的人体特征信息，再基于该人体特征信息利用算法推断出驾驶员患病类型，避免了直接通过在目标车辆上安装体征参数检测物联网设备获取人体健康状态的稳定性较差以及误报率高的问题，从而提高了车辆在行驶过程中对驾驶员的健康状态进行识别的效率。
116.进一步的，所述基于所述开发控制器策略对目标软件升级包进行处理，包括以下步骤：
117.判断所述目标软件升级包是否加密；
118.若加密，则利用解密策略对所述目标软件升级包进行解密，得到解密后的目标软件包文件；
119.基于所述开发控制器策略对所述目标软件包文件进行识别。
120.进一步的，所述方法还包括以下步骤：
121.若不加密，则直接基于所述开发控制器策略对所述目标软件升级包内的文件进行识别。
122.在一申请实施例中，所述基于所述开发控制器策略对所述目标软件包文件进行识别，包括以下步骤：
123.获取所述目标软件包文件的识别标识；
124.若所述识别标识与控制器策略配置的标识一致，则对所述目标软件包进行处理；
125.若所述识别标识与控制策略配置的标识不一致，则不对所述目标软件包进行处理。
126.在一申请实施例中，所述基于各种类型的软件升级包的需求标准，配置开发控制器策略，包括以下步骤：
127.基于各安全算法的输入参数以及输出参数，获取各安全算法的参数标准；
128.基于安全算法函数、安全算法文件名、安全密钥以及所述各安全算法的参数标准，封装成各安全算法库；
129.在一申请实施例中，所述方法包括：
130.获取各安全算法的安全密钥的有效时长；
131.将所述有效时长大于第一阈值的安全密钥确定为第一安全密钥；
132.将所述第一安全密钥对应的安全算法库存储在车载数据库中。
133.在一申请实施例中，所述将所述有效时长小于第一阈值的安全密钥确定为第二安全密钥；
134.将所述第二安全密钥对应的安全算法库存储在云端数据库中。
135.第二方面，本技术实施例提供一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器执行时实现第一方面提及的软件包升级方法。
136.第三方面，本技术实施例提供一种电子设备，包括存储器和处理器，存储器上储存有在处理器上运行的计算机程序，该处理器执行计算机程序时实现第一方面提及的软件包处理方法。
137.需要说明的是，在本技术中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
138.以上仅是本技术的具体实施方式，使本领域技术人员能够理解或实现本技术。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。