CN113114729A - 一种用于ota可靠性的验证系统及方法 - Google Patents

Abstract

本发明公开了一种用于OTA可靠性的验证系统及方法，属于汽车电子技术领域，该方法包括交替验证、试验包验证和线下辅助验证；交替验证用于验证在实际的升级环境中，软件能否被远程OTA的可靠性；试验包验证用于为交替验证提供试错环节，减小软件开发的压力；线下辅助验证是通过诊断仪对刷写的软件进行简单的版本验证和功能验证。试验包验证对软件功能进行提前检测，及时发现问题，可以在一定程度上减小开发压力、降低开发成本、降低服务器的压力；线下辅助验证对软件进行多维检测，验证云服务器信息的准确性、使得整个升级过程更加清晰可控；交替验证可以在提前在升级环境中验证软件关于OTA方面的功能，可提前发现问题，节约成本，规避技术风险。

Description

一种用于OTA可靠性的验证系统及方法

技术领域

本发明属于汽车电子技术领域，具体涉及一种用于OTA可靠性的验证系统及方法。

背景技术

在汽车工业中，人工智能是一个越来越热门的话题。尤其在当今时代，汽车逐渐呈现出被软件而非传统的机械组件控制和定义的趋势。在过去，如果一台汽车想升级软件，那么它必须要到相应的服务站，连接上该服务站的系统或者电脑去升级。而现在，OTA解决了汽车软件升级必须在现场的依赖性问题。并且，安全、及时并且简便的OTA软件升级方法对每台车是非常必要的。OTA的手机和汽车升级方法是不一样的，相对于手机的OTA升级，汽车的OTA升级更加复杂和严苛，不正确的软件更新是有可能影响驾驶员的生命的。鉴于此，OTA软件的正确可靠性是当今亟待解决的问题。

发明内容

为了解决现有技术中存在的OTA升级不可靠等问题，本发明提供了一种用于OTA升级可靠性的验证系统及方法，该方法主要包括交替验证、试验包验证和线下辅助验证。交替验证可以验证在实际的升级环境中，软件能否被远程OTA的可靠性。试验包验证可以为交替验证提供试错环节，可以减小软件开发的压力。线下辅助验证是通过诊断仪对刷写的软件进行简单的版本验证和功能验证。三种验证结合在一起，可以为OTA升级这个功能提供可靠的验证。

本发明通过如下技术方案实现：

一种用于OTA可靠性的验证系统，包括线下诊断工具、车端及云服务器，所述线下诊断工具用于线下辅助验证，用于在刷写失败而且软件出现故障的时候，对车端进行软件的刷写；在升级成功或者升级失败但是软件没有出现故障的时候，读取版本号或者进行功能验证，车端给线下诊断工具发送的时诊断信息；所述云服务器用于给车端发送试验任务、正式任务，试验任务用于试验包验证，正式任务A和B的交替用于交替验证；车端接到任务后，将车端的升级信息反馈给服务器。

本发明的另一目的在于提供一种用于OTA可靠性的验证方法，包括交替验证、试验包验证和线下辅助验证；所述交替验证用于验证在实际的升级环境中，软件能否被远程OTA的可靠性；所述试验包验证用于为交替验证提供试错环节，减小软件开发的压力；所述线下辅助验证是通过诊断仪对刷写的软件进行简单的版本验证和功能验证。

一种用于OTA升级可靠性的验证方法，具体如下：

试验人员将试验A版升级软件制作试验包A，制作完成之后，将试验包A传到服务器上，使用试验包A布置升级任务，进行试验阶段的升级；

将B版升级软件制作成试验包B，将试验包B上传到服务器中，用试验包B部署升级任务后，进行试验阶段的升级；

所述的试验阶段的升级，存在升级成功或升级失败两种情况；

若升级失败，判断软件是否出现故障；若软件未出现故障，则重新布置升级任务，若软件出现故障，则使用诊断仪对软件进行刷写，然后在重新布置升级任务；

若升级成功，则使用诊断仪读车端软件版本号并且验证软件功能；若验证失败，则说明软件存在问题，要使用线下诊断辅助工具进行刷写，再重新升级；若升级成功，则软件在试验包验证阶段的任务完成。

所述试验包A及试验包B的文件版本号及文件功能不同。

一种用于OTA升级可靠性的验证方法，包括如下步骤：

(1)、流程开始后，试验者将A版升级软件制作成试验升级包A，然后将试验升级包上传至服务器；在云服务器上用试验升级包A部署任务，接着试验车接到试验升级任务A，这个时候，由试验者选择是否进行升级；如果选择升级，那么车端就进行软件升级；如果选择不升级，则间隔若干时间继续向车端发送升级申请；发送申请前，要先判断是否超时，每个任务由自己的计时器，如果超过了计时器的时间，则不再发送升级申请，如果升级需要试验者重新在云端部署升级任务；如果没有超过计时器的时间，则继续让试验者判断是否升级即可；

(2)、用户开始升级后，可能出现升级成功和升级失败的情况；如果升级失败了，要分为软件是否出现故障两种情况；如果升级失败但是软件未出现故障，则在云端重新部署试验升级任务A即可；然后试验车又会接到升级任务A；如果升级失败了但是出现了故障，则需要试验者使用诊断仪对软件进行刷写，再在云端对任务进行重新部署；

(3)、如果用户升级成功，则使用诊断仪读车端软件版本号并且验证软件功能，如果验证失败，则说明软件存在问题，要使用线下诊断辅助工具进行刷写，再重新升级；如果升级成功了，则软件A在试验阶段的任务完成；

(4)、下面要将升级软件A制作成正式升级包并且上传至服务器；然后将正式的任务推送给车端；试验员要自行选择是否升级，如果选择不升级，则间隔若干时间要再推送升级；推送之前要进行是否超时的判断，如果超时了，需要试验员重新在服务器上部署正式的升级任务A，再由试验员进行选择是否升级；

(5)、如果选择升级，有升级成功和升级失败两种情况；如果升级失败的话，也要看软件是否出现故障，如果未出现故障，则要在云端重新部署正式的升级任务A，再向试验车推送升级任务；如果软件出现故障的话，则需要用线下辅助工具对软件进行刷写；

(6)、如果升级成功的话，需要用诊断仪读车端软件的版本号并简单验证功能，如果验证失败的话，还需要用线下诊断工具对软件重新进行刷写；如果成功的话，则软件A正式的升级包通过验证，下面进入交替验证的阶段；

(7)、交替验证的策略是用A和B在升级环境中对OTA功能进行验证；首先要将B版升级软件制作成试验升级包B，接着上传到服务器中，用升级包部署任务后，将任务推送给试验车，由试验员来选择是否进行升级，如果选择不升级，则下一次推送升级的时候会判断是否超时，如果超时，需要试验员重新在服务器上部署试验任务，如果未超时，则正常推送即可；

(8)、如果试验员选择升级，也是分为升级成功和升级失败两种可能，如果升级失败，则要看软件是否出现故障，如果出现故障，要用诊断仪进行刷写软件，如果未出现故障，则在云端重新部署任务即可；

(9)、如果升级成功，则用线下的辅助工具诊断仪来读车端版本号并且验证功能，如果验证失败，则需要用诊断仪对软件进行刷写，再到云端部署任务即可；

(10)、试验阶段完成后，要将B版升级软件制作成正式升级包，将升级包上传至服务器，在服务器上部署正式升级任务。将正式升级任务推送到车端后，由试验员选择是否升级，如果选择不升级，则下次升级前要进行条件判断，判断是否超时，如果未超时，由试验员判断下次是否升级即可，如果已经超时，需要试验员在云端重新部署正式升级任务；

(11)、试验员选择升级后，分为升级失败和升级成功两种情况，如果升级失败，要看软件是否出现故障，如果未出现故障，则在云端重新部署正式升级任务B即可，如果出现了故障，则需要在线下使用诊断仪进行刷写；

(12)、如果升级成功，则用诊断仪读取版本号并对软件的功能进行验证；如果验证失败，则也需要诊断仪在线下对软件进行刷写；如果验证成功，整个软件的OTA功能验证结束。

与现有技术相比，本发明的优点如下：

(1)、利用试验包验证对软件功能进行提前检测，及时发现问题，可以在一定程度上减小开发压力、降低开发成本、降低服务器的压力；

(2)、利用线下辅助验证对软件进行多维检测，验证云服务器信息的准确性、使得整个升级过程更加清晰可控；

(3)、利用交替验证可以在提前在升级环境中验证软件关于OTA方面的功能，可以提前发现问题，节约成本，规避技术风险。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍。在所有附图中，类似的元件或部分一般由类似的附图标记标识。附图中，各元件或部分并不一定按照实际的比例绘制。

图1为本发明的系统框图；

图2为本发明的验证方法的流程示意图。

具体实施方式

下面将结合附图对本发明技术方案的实施例进行详细的描述，以下实施例仅用于更加清楚地说明本发明的技术方案，因此只作为示例，而不能以此来限制本发明的保护范围。

需要注意的是，除非另有说明，本申请使用的技术术语或者科学术语应当为本发明所属领域技术人员所理解的通常意义。

实施例1

如图1所示，本发明的一种用于OTA升级可靠性的验证系统，包括线下诊断工具、车端及云服务器，所述线下诊断工具用于线下辅助验证，用于在刷写失败而且软件出现故障的时候，对车端进行软件的刷写；在升级成功或者升级失败但是软件没有出现故障的时候，读取版本号或者进行功能验证，车端给线下诊断工具发送的时诊断信息；所述云服务器用于给车端发送试验任务、正式任务，试验任务用于试验包验证，正式任务A和B的交替用于交替验证；车端接到任务后，将车端的升级信息反馈给服务器。

如图2所示，本发明的验证方法的流程示意图；

本发明的一种用于OTA升级可靠性的验证方法，包括交替验证、试验包验证和线下辅助验证；所述交替验证用于验证在实际的升级环境中，软件能否被远程OTA的可靠性；所述试验包验证用于为交替验证提供试错环节，减小软件开发的压力；所述线下辅助验证是通过诊断仪对刷写的软件进行简单的版本验证和功能验证。

实施例2

一种用于OTA升级可靠性的验证方法，包括如下步骤：

(1)、流程开始后，试验者将A版升级软件制作成试验升级包A，然后将试验升级包上传至服务器；在云服务器上用试验升级包A部署任务，接着试验车接到试验升级任务A，这个时候，由试验者选择是否进行升级；如果选择升级，那么车端就进行软件升级；如果选择不升级，则间隔若干时间继续向车端发送升级申请；发送申请前，要先判断是否超时，每个任务由自己的计时器，如果超过了计时器的时间，则不再发送升级申请，如果升级需要试验者重新在云端部署升级任务；如果没有超过计时器的时间，则继续让试验者判断是否升级即可；

(2)、用户开始升级后，可能出现升级成功和升级失败的情况；如果升级失败了，要分为软件是否出现故障两种情况；如果升级失败但是软件未出现故障，则在云端重新部署试验升级任务A即可；然后试验车又会接到升级任务A；如果升级失败了但是出现了故障，则需要试验者使用诊断仪对软件进行刷写，再在云端对任务进行重新部署；

(3)、如果用户升级成功，则使用诊断仪读车端软件版本号并且验证软件功能，如果验证失败，则说明软件存在问题，要使用线下诊断辅助工具进行刷写，再重新升级；如果升级成功了，则软件A在试验阶段的任务完成；

(4)、下面要将升级软件A制作成正式升级包并且上传至服务器；然后将正式的任务推送给车端；试验员要自行选择是否升级，如果选择不升级，则间隔若干时间要再推送升级；推送之前要进行是否超时的判断，如果超时了，需要试验员重新在服务器上部署正式的升级任务A，再由试验员进行选择是否升级；

(5)、如果选择升级，有升级成功和升级失败两种情况；如果升级失败的话，也要看软件是否出现故障，如果未出现故障，则要在云端重新部署正式的升级任务A，再向试验车推送升级任务；如果软件出现故障的话，则需要用线下辅助工具对软件进行刷写；

(6)、如果升级成功的话，需要用诊断仪读车端软件的版本号并简单验证功能，如果验证失败的话，还需要用线下诊断工具对软件重新进行刷写；如果成功的话，则软件A正式的升级包通过验证，下面进入交替验证的阶段；

(7)、交替验证的策略是用A和B在升级环境中对OTA功能进行验证；首先要将B版升级软件制作成试验升级包B，接着上传到服务器中，用升级包部署任务后，将任务推送给试验车，由试验员来选择是否进行升级，如果选择不升级，则下一次推送升级的时候会判断是否超时，如果超时，需要试验员重新在服务器上部署试验任务，如果未超时，则正常推送即可；

(8)、如果试验员选择升级，也是分为升级成功和升级失败两种可能，如果升级失败，则要看软件是否出现故障，如果出现故障，要用诊断仪进行刷写软件，如果未出现故障，则在云端重新部署任务即可；

(9)、如果升级成功，则用线下的辅助工具诊断仪来读车端版本号并且验证功能，如果验证失败，则需要用诊断仪对软件进行刷写，再到云端部署任务即可；

(10)、试验阶段完成后，要将B版升级软件制作成正式升级包，将升级包上传至服务器，在服务器上部署正式升级任务。将正式升级任务推送到车端后，由试验员选择是否升级，如果选择不升级，则下次升级前要进行条件判断，判断是否超时，如果未超时，由试验员判断下次是否升级即可，如果已经超时，需要试验员在云端重新部署正式升级任务；

(11)、试验员选择升级后，分为升级失败和升级成功两种情况，如果升级失败，要看软件是否出现故障，如果未出现故障，则在云端重新部署正式升级任务B即可，如果出现了故障，则需要在线下使用诊断仪进行刷写；

(12)、如果升级成功，则用诊断仪读取版本号并对软件的功能进行验证；如果验证失败，则也需要诊断仪在线下对软件进行刷写；如果验证成功，整个软件的OTA功能验证结束。

以上结合附图详细描述了本发明的优选实施方式，但是，本发明并不限于上述实施方式中的具体细节，在本发明的技术构思范围内，可以对本发明的技术方案进行多种简单变型，这些简单变型均属于本发明的保护范围。

另外需要说明的是，在上述具体实施方式中所描述的各个具体技术特征，在不矛盾的情况下，可以通过任何合适的方式进行组合，为了避免不必要的重复，本发明对各种可能的组合方式不再另行说明。

此外，本发明的各种不同的实施方式之间也可以进行任意组合，只要其不违背本发明的思想，其同样应当视为本发明所公开的内容。

Claims (5)

1.一种用于OTA可靠性的验证系统，其特征在于，包括线下诊断工具、车端及云服务器，所述线下诊断工具用于线下辅助验证，用于在刷写失败而且软件出现故障的时候，对车端进行软件的刷写；在升级成功或者升级失败但是软件没有出现故障的时候，读取版本号或者进行功能验证，车端给线下诊断工具发送的时诊断信息；所述云服务器用于给车端发送试验任务、正式任务，试验任务用于试验包验证，正式任务A和B的交替用于交替验证；车端接到任务后，将车端的升级信息反馈给服务器。

2.一种用于OTA可靠性的验证方法，其特征在于，包括交替验证、试验包验证和线下辅助验证；所述交替验证用于验证在实际的升级环境中，软件能否被远程OTA的可靠性；所述试验包验证用于为交替验证提供试错环节，减小软件开发的压力；所述线下辅助验证是通过诊断仪对刷写的软件进行简单的版本验证和功能验证。

3.如权利要求2所述的一种用于OTA可靠性的验证方法，其特征在于，具体步骤如下：试验人员将试验A版升级软件制作试验包A，制作完成之后，将试验包A传到服务器上，使用试验包A布置升级任务，进行试验阶段的升级；

将B版升级软件制作成试验包B，将试验包B上传到服务器中，用试验包B部署升级任务后，进行试验阶段的升级；

所述的试验阶段的升级，存在升级成功或升级失败两种情况；

若升级失败，判断软件是否出现故障；若软件未出现故障，则重新布置升级任务，若软件出现故障，则使用诊断仪对软件进行刷写，然后在重新布置升级任务；

若升级成功，则使用诊断仪读车端软件版本号并且验证软件功能；若验证失败，则说明软件存在问题，要使用线下诊断辅助工具进行刷写，再重新升级；若升级成功，则软件在试验包验证阶段的任务完成。

4.如权利要求2所述的一种用于OTA可靠性的验证方法，其特征在于，所述试验包A及试验包B的文件版本号及文件功能不同。

5.如权利要求2所述的一种用于OTA可靠性的验证方法，其特征在于，包括如下步骤：

(1)、流程开始后，试验者将A版升级软件制作成试验升级包A，然后将试验升级包上传至服务器；在云服务器上用试验升级包A部署任务，接着试验车接到试验升级任务A，这个时候，由试验者选择是否进行升级；如果选择升级，那么车端就进行软件升级；如果选择不升级，则间隔若干时间继续向车端发送升级申请；发送申请前，要先判断是否超时，每个任务由自己的计时器，如果超过了计时器的时间，则不再发送升级申请，如果升级需要试验者重新在云端部署升级任务；如果没有超过计时器的时间，则继续让试验者判断是否升级即可；

(2)、用户开始升级后，可能出现升级成功和升级失败的情况；如果升级失败了，要分为软件是否出现故障两种情况；如果升级失败但是软件未出现故障，则在云端重新部署试验升级任务A即可；然后试验车又会接到升级任务A；如果升级失败了但是出现了故障，则需要试验者使用诊断仪对软件进行刷写，再在云端对任务进行重新部署；

(3)、如果用户升级成功，则使用诊断仪读车端软件版本号并且验证软件功能，如果验证失败，则说明软件存在问题，要使用线下诊断辅助工具进行刷写，再重新升级；如果升级成功了，则软件A在试验阶段的任务完成；

(4)、下面要将升级软件A制作成正式升级包并且上传至服务器；然后将正式的任务推送给车端；试验员要自行选择是否升级，如果选择不升级，则间隔若干时间要再推送升级；推送之前要进行是否超时的判断，如果超时了，需要试验员重新在服务器上部署正式的升级任务A，再由试验员进行选择是否升级；

(5)、如果选择升级，有升级成功和升级失败两种情况；如果升级失败的话，也要看软件是否出现故障，如果未出现故障，则要在云端重新部署正式的升级任务A，再向试验车推送升级任务；如果软件出现故障的话，则需要用线下辅助工具对软件进行刷写；

(6)、如果升级成功的话，需要用诊断仪读车端软件的版本号并简单验证功能，如果验证失败的话，还需要用线下诊断工具对软件重新进行刷写；如果成功的话，则软件A正式的升级包通过验证，下面进入交替验证的阶段；

(7)、交替验证的策略是用A和B在升级环境中对OTA功能进行验证；首先要将B版升级软件制作成试验升级包B，接着上传到服务器中，用升级包部署任务后，将任务推送给试验车，由试验员来选择是否进行升级，如果选择不升级，则下一次推送升级的时候会判断是否超时，如果超时，需要试验员重新在服务器上部署试验任务，如果未超时，则正常推送即可；

(8)、如果试验员选择升级，也是分为升级成功和升级失败两种可能，如果升级失败，则要看软件是否出现故障，如果出现故障，要用诊断仪进行刷写软件，如果未出现故障，则在云端重新部署任务即可；

(9)、如果升级成功，则用线下的辅助工具诊断仪来读车端版本号并且验证功能，如果验证失败，则需要用诊断仪对软件进行刷写，再到云端部署任务即可；

(10)、试验阶段完成后，要将B版升级软件制作成正式升级包，将升级包上传至服务器，在服务器上部署正式升级任务。将正式升级任务推送到车端后，由试验员选择是否升级，如果选择不升级，则下次升级前要进行条件判断，判断是否超时，如果未超时，由试验员判断下次是否升级即可，如果已经超时，需要试验员在云端重新部署正式升级任务；

(11)、试验员选择升级后，分为升级失败和升级成功两种情况，如果升级失败，要看软件是否出现故障，如果未出现故障，则在云端重新部署正式升级任务B即可，如果出现了故障，则需要在线下使用诊断仪进行刷写；

(12)、如果升级成功，则用诊断仪读取版本号并对软件的功能进行验证；如果验证失败，则也需要诊断仪在线下对软件进行刷写；如果验证成功，整个软件的OTA功能验证结束。

Images