一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

一种新能源整车控制器硬件在环测试系统及测试方法与流程

2022-05-11 15:35:38 来源:中国专利 TAG:


1.本发明属于硬件在环测试系统领域,具体涉及一种新能源整车控制器硬件在环测试系统及测试方法。


背景技术:

2.整车控制系统是新能源汽车的核心控制系统,新能源汽车的安全性、动力性、能耗经济性及驾驶平顺性都与整车控制系统有密切的关系。整车控制系统作为新能源汽车的核心控制系统,整车控制系统的硬件在环测试尤其对新能源汽车的安全性验证至关重要。如何改进整车控制系统硬件在环测试质量、提高整车控制系统硬件在环测试效率是整车控制系统研发和管理人员最为关心的一个问题。
3.传统上,针对整车控制系统硬件在环测试,仅进行收集硬件在环测试数据、硬件在环测试需求分析、硬件在环测试执行、硬件在环测试总结,硬件在环测试执行之前不进行缺陷度量,不利于硬件在环测试结束后对测试充分性、测试质量有效评估,尤其针对新开发的整车控制系统。


技术实现要素:

4.为了提高硬件在环测试质量和效率,本发明设计了一种基于缺陷预估的新能源车整车控制系统的硬件在环测试方法。
5.为了解决现有技术存在的上述问题,本发明所采用的技术方案为:
6.一种新能源整车控制器硬件在环测试系统,所述系统包括:
7.上位机、测试柜以及整车控制器。
8.所述上位机与所述测试柜通过以太网连接。
9.所述测试柜与所述整车控制器通信连接。
10.进一步的,所述测试柜包括实时仿真系统,所述实时仿真系统用于运行测试模型,所述测试模型包括:整车动力模型,包含车辆动力学模型、驱动电机模型、电池模型。其中,车辆动力学模型主要参数包括整备质量、质心位置、迎风面积、轮胎半径、主减速比等;驱动电机模型主要参数为电机额定/峰值功率效率特性数据;电池模型主要包括串并联数目、不同温度的单体的充放电特性数据;驾驶环境模型包括风速、道路滚动阻力系数、海拔等;路谱模型包括各种典型工况数据;驾驶员和驾驶室模型分为驾驶员模型和驾驶室模型。驾驶员模型根据实车路试的加速踏板和制动踏板的开度信息,模拟不同驾驶员的驾驶习惯;驾驶室模型模拟一些驾驶室面板信号,方便进行硬件在环测试输入;极限工况模型主要用来快速方便设置各种异常故障信息。
11.进一步的,所述上位机与整车控制器通过标定观测工具连接,用于读取测试运行结果,整车控制器和测试柜之间通过线束连接,线束传输的信号主要包括各类硬线信号和can线信号。
12.一种新能源整车控制器硬件在环测试方法,包括以下步骤:
13.步骤a:获取整车控制器的硬件在环测试数据,进行硬件在环测试需求分析,并编辑测试需求矩阵分析列表。
14.所述整车控制器的硬件在环测试数据包括控制系统通讯网络拓扑、整车控制器通讯矩阵、软硬件接口规范、整车控制器功能规范。
15.所述步骤a包括:在所述需求分析矩阵中定义整车控制器的硬件在环测试范围、硬件在环测试功能项、硬件在环测试深度及硬件在环测试目标。
16.步骤b:根据硬件在环测试需求分析,搭建整车控制器的硬件在环测试环境,根据步骤a所述的测试深度搭建的极限工况模型。
17.所述硬件在环测试环境包括车型模型、驾驶环境模型、路谱模型、驾驶员和驾驶室模型、电池模型、电机模型。
18.步骤b1:在上位机的建模软件中搭建整车控制器的硬件在环测试环境,并进行编译。
19.步骤b2:依据整车控制器网络拓扑结构在上位机的veristand测试管理软件中配置节点的网络映射关系、整车控制器的硬件与测试柜的硬线信号映射关系。
20.步骤b3:在veristand软件中将配置后的整车控制器的硬件在环测试环境,部署到测试柜中,由测试柜模拟实时运行整车控制器的在环测试环境。
21.步骤c:基于测试需求矩阵分析列表及硬件在环测试环境,确定硬件在环测试缺陷预估算法及硬件在环测试结果评估,生成硬件在环测试缺陷预估。
22.步骤d:基于硬件在环测试缺陷预估,设定整车控制器的测试架构、各子功能的测试用例设计方法、各子功能的测试用例数量、测试执行的优先级、测试截至准则。
23.步骤e:进行硬件在环测试,具体包括如下步骤:
24.根据所设定的测试用例设计方法进行测试用例设计。
25.根据所设定的测试执行优先级进行测试用例执行,并记录测试用例执行结果。
26.根据预估的测试截至准则截止测试测试执行。
27.步骤f:硬件在环测试评价。
28.根据测试用例执行结果和硬件在环测试结果评估,评价整车控制器硬件在环测试,得到硬件在环测试评价结果。
29.步骤g:所述的硬件在环测试优化,基于硬件在环测试评价结果,对硬件在环测试缺陷评估进行改进或者对所设定的测试环境进行改进。
30.步骤h:基于改进的硬件在环测试缺陷预估算法,重复步骤d-步骤f,直到所述的测试评价达到所述的硬件在环测试目标。
31.进一步的,所述步骤c具体包括步骤c1:利用python软件编写脚本文件,识别测试需求矩阵分析列表及搭建的整车控制器测试环境,确定硬件在环测试缺陷预估算法及缺陷结果度量准则,硬件在环测试缺陷预估根据bugnum计算;
32.公式一:
33.bugnum=a
×
λa (in1 in2 out)
×
λ
port
max{num1,num2}
×
λ
num
ff
×
λf34.公式一中:
35.a为相关模拟输入信号数目。
36.λa为历史统计模拟输入信号数目对bug数量的贡献率。
37.in1为除模拟信号外其他硬线输入信号数目。
38.in2为can输入信号数目。
39.out为输出信号数目。
40.λ
port
为历史统计接口测试对bug数量的贡献率。
41.num1为相关测试项数目。
42.num2为该测试项相关零部件的数目。
43.λ
num
为历史统计功能相关分析测试对bug数量的贡献率。
44.ff为该测试项的子功能项数目。
45.λf历史统计子功能项数目对bug数量的贡献率。
46.步骤c2:进行硬件在环测试缺陷预估,生成硬件在环测试缺陷预估。
47.进一步的,所述步骤e中,完成优先级最高的测试用例执行,如果满足测试截止准则,则对硬件在环测试执行结果评价。
48.进一步的,所述步骤f中,计算硬件在环测试结果评估bugeval,当硬件在环测试结果评估绝对值不小于27,则分析硬件在环测试环境的设定;当硬件在环测试结果评估绝对值小于27,但是缺陷预估不小于1.5倍的实际测试结果,分析测试缺陷预估算法;当硬件在环测试结果评估绝对值小于27,且缺陷预估小于1.5倍的测试结果,则认为本次hil测试充分、可以终止本次测试。
49.公式二:
[0050][0051]
公式二中:
[0052]
n为测试架构中划分的测试模块数量;
[0053]
λi为第i个测试模块的权重。
[0054]
k1为bug预估系数,该系数与功能模块复杂程度,测试设计成熟度,功能设计成熟度密切相关;
[0055]
bugrel为每个功能模块实际测试对应的测试缺陷数目;
[0056]
bugnum为每个功能模块预估的测试缺陷数目;
[0057]
通过公式二,得出硬件在环测试缺陷预估。
[0058]
公式二中的k1根据式公式三得出。
[0059]
公式三:
[0060]
k1=c1
×
m1 c2
×
m2 c3
×
m3
[0061]
公式三中,约束条件为c1 c2 c3=1,
[0062]
c1为功能复杂程度权重;
[0063]
m1为功能复杂程度,根据功能模块实现的功能类型进行评级。
[0064]
c2为测试设计成熟度权重;
[0065]
m2为测试设计成熟度,根据模块的历史测试经验及测试设计人员经验评级。
[0066]
c3为功能设计成熟度权重;
[0067]
m3为功能设计成熟度,设计模块的历史应用经验及设计人员经验评级。
[0068]
本发明的有益效果为:
[0069]
(1)本发明通过增设硬件在环测试缺陷预估算法及缺陷结果度量准则,硬件在环测试执行之前能够进行缺陷度量,有利于硬件在环测试结束后对测试充分性、测试质量有效评估,尤其针对新开发的整车控制系统。
[0070]
(2)本发明通过将硬件在环测试缺陷预测结果分布与实际测试缺陷结果进行比对并分析,当误差较大时,再返回之前步骤,对算法进行调整,经过多次测试后,能够获得充分、有效的测试结果。
附图说明
[0071]
图1为本发明中整车控制器硬件在环测试系统;
[0072]
图2为本发明中整车控制器硬件在环测试流程;
[0073]
图3为本发明中硬件在环测试环境设定;
[0074]
图4为本发明中硬件在环测试缺陷评估。
具体实施方式
[0075]
下面结合附图及附图标记对本发明作进一步阐述。
[0076]
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。
[0077]
因此,以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围,而是仅仅表示本发明的选定实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
[0078]
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
[0079]
在本发明实施例的描述中,术语“第一”、“第二”、“第三”等仅用于区分描述,而不能理解为指示或暗示相对重要性。
[0080]
在本发明实施例的描述中,“多个”代表至少2个。
[0081]
在本发明实施例的描述中,还需要说明的是,除非另有明确的规定和限定,若出现术语“设置”、“安装”、“相连”、“连接”应做广义理解,例如,可以是固定连接,也可以是可拆卸连接,或一体地连接;可以是机械连接,也可以是电连接;可以是直接相连,也可以通过中间媒介间接相连,可以是两个元件内部的连通。对于本领域的普通技术人员而言,可以根据具体情况理解上述术语在本发明中的具体含义。
[0082]
以下结合附图对本发明的具体实施方式进行详细说明。应当理解的是,此处所描述的具体实施方式仅用于说明和解释本发明,并不用于限制本发明。
[0083]
实施例1:
[0084]
如图1所示,一种新能源整车控制器硬件在环测试系统,所述系统包括:
[0085]
上位机、测试柜以及整车控制器。
[0086]
所述上位机与所述测试柜通过以太网连接。
[0087]
所述测试柜与所述整车控制器通信连接。
[0088]
所述测试柜包括实时仿真系统,所述实时仿真系统用于运行测试模型,所述测试模型包括:整车动力模型、驾驶环境模型、路谱模型、驾驶员和驾驶室模型、极限工况模型。
[0089]
所述上位机与整车控制器通过标定观测工具连接,用于读取测试运行结果。
[0090]
整车控制器和测试柜之间通过线束连接,线束传输的信号主要包括各类硬线信号和can线信号。
[0091]
实施例2:
[0092]
如图1-4所示,一种新能源整车控制器硬件在环测试系统,所述系统包括:
[0093]
上位机、测试柜以及整车控制器。
[0094]
所述上位机与所述测试柜通过以太网连接。
[0095]
所述测试柜与所述整车控制器通信连接。
[0096]
所述测试柜包括实时仿真系统,所述实时仿真系统用于运行测试模型,所述测试模型包括:整车动力模型、驾驶环境模型、路谱模型、驾驶员和驾驶室模型、极限工况模型。所述整车动力模型,包含车辆动力学模型、驱动电机模型、电池模型。其中,车辆动力学模型主要参数包括整备质量、质心位置、迎风面积、轮胎半径、主减速比等;驱动电机模型主要参数为电机额定/峰值功率效率特性数据;电池模型主要包括串并联数目、不同温度的单体的充放电特性数据;驾驶环境模型包括风速、道路滚动阻力系数、海拔等;路谱模型包括各种典型工况数据;驾驶员和驾驶室模型分为驾驶员模型和驾驶室模型。驾驶员模型根据实车路试的加速踏板和制动踏板的开度信息,模拟不同驾驶员的驾驶习惯;驾驶室模型模拟一些驾驶室面板信号,方便进行硬件在环测试输入;极限工况模型主要用来快速方便设置各种异常故障信息。
[0097]
所述上位机与整车控制器通过标定观测工具连接,用于读取测试运行结果。
[0098]
整车控制器和测试柜之间通过线束连接,线束传输的信号主要包括各类硬线信号和can线信号。
[0099]
一种新能源整车控制器硬件在环测试方法,包括以下步骤:
[0100]
步骤a:获取整车控制器的硬件在环测试数据,进行硬件在环测试需求分析,并编辑测试需求矩阵分析列表(如表1)。
[0101]
测试项测试优先级相关模拟输入信号相关can输入信号输出信号相关测试项相关零部件测试结束准则软硬件接口14542538fun1上下电管理11235823fun2故障管理28506216fun3车辆运行模式切换24345416fun4车辆驱动215238223fun5
[0102]
表1
[0103]
所述整车控制器的硬件在环测试数据包括控制系统通讯网络拓扑、整车控制器通讯矩阵、软硬件接口规范、整车控制器功能规范。
[0104]
所述步骤a包括:在所述需求分析矩阵中定义整车控制器的硬件在环测试范围、测试功能项、测试深度及测试目标。
[0105]
步骤b:根据硬件在环测试需求分析,搭建整车控制器的硬件在环测试环境,根据步骤a所述的测试深度搭建的极限工况模型。
[0106]
所述硬件在环测试环境包括车型模型、驾驶环境模型、路谱模型、驾驶员和驾驶室
模型、电池模型、电机模型。
[0107]
步骤b具体包括:
[0108]
步骤b1:在上位机的建模软件中搭建整车控制器的硬件在环测试环境,并进行编译。
[0109]
步骤b2:依据整车控制器网络拓扑结构在上位机的veristand测试管理软件中配置节点的网络映射关系、整车控制器的硬件与测试柜的硬线信号映射关系。
[0110]
步骤b3:在veristand软件中将配置后的整车控制器的硬件在环测试环境,部署到测试柜中,由测试柜模拟实时运行整车控制器的在环测试环境。
[0111]
步骤c:基于测试需求矩阵分析列表及硬件在环测试环境,确定硬件在环测试缺陷预估算法及硬件在环测试结果评估,生成硬件在环测试缺陷预估。
[0112]
所述步骤c具体包括
[0113]
步骤c1:利用python软件编写脚本文件,识别测试需求矩阵分析列表及搭建的整车控制器测试环境,确定硬件在环测试缺陷预估算法及缺陷结果度量准则,硬件在环测试缺陷预估根据bugnum计算;
[0114]
公式一:
[0115]
bugnum=a
×
λa (in1 in2 out)
×
λ
port
max{num1,num2}
×
λ
num
ff
×
λf[0116]
公式一中:
[0117]
a为相关模拟输入信号数目;
[0118]
λa为历史统计模拟输入信号数目对bug数量的贡献率;
[0119]
in1为除模拟信号外其他硬线输入信号数目;
[0120]
in2为can输入信号数目;
[0121]
out为输出信号数目;
[0122]
λ
port
为历史统计接口测试对bug数量的贡献率;
[0123]
num1为相关测试项数目;
[0124]
num2为该测试项相关零部件的数目;
[0125]
λ
num
为历史统计功能相关分析测试对bug数量的贡献率;
[0126]
ff为该测试项的子功能项数目;
[0127]
λf历史统计子功能项数目对bug数量的贡献率;
[0128]
步骤c2:进行硬件在环测试缺陷预估,生成硬件在环测试缺陷预估。
[0129]
步骤d:基于硬件在环测试缺陷预估,设定整车控制器的测试架构、各子功能的测试用例设计方法、各子功能的测试用例数量、测试执行的优先级、测试截至准则。
[0130]
步骤e:进行硬件在环测试,具体包括如下步骤:
[0131]
根据所设定的测试用例设计方法进行测试用例设计。
[0132]
根据所设定的测试执行优先级执行测试用例,并记录测试用例执行结果。
[0133]
根据预估的测试截至准则截止测试测试执行。
[0134]
所述步骤e中,完成优先级最高的测试用例执行,如果满足测试截止准则,则对硬件在环测试执行结果评价。
[0135]
步骤f:硬件在环测试评价。
[0136]
根据测试用例执行结果和硬件在环测试结果评估,评价整车控制器硬件在环测
试,得到硬件在环测试评价结果。
[0137]
所述步骤f中,计算硬件在环测试结果评估bugeval,当硬件在环测试结果评估绝对值不小于27,则分析硬件在环测试环境的设定;当硬件在环测试结果评估绝对值小于27,但是缺陷预估不小于1.5倍的实际测试结果,分析测试缺陷预估算法;当硬件在环测试结果评估绝对值小于27,且缺陷预估小于1.5倍的测试结果,则认为本次hil测试充分、可以终止本次测试。
[0138]
公式二:
[0139][0140]
公式二中:
[0141]
n为测试架构中划分的测试模块数量;
[0142]
λi为第i个测试模块的权重。
[0143]
k1为bug预估系数,该系数与功能模块复杂程度,测试设计成熟度,功能设计成熟度密切相关;
[0144]
bugrel为每个功能模块实际测试对应的测试缺陷数目;
[0145]
bugnum为每个功能模块预估的测试缺陷数目;
[0146]
通过公式二,得出硬件在环测试缺陷预估。
[0147]
公式二中的k1根据式公式三得出。
[0148]
公式三:
[0149]
k1=c1
×
m1-tc2
×
m2 c3
×
m3
[0150]
公式三中,约束条件为c1 c2 c3=1,
[0151]
c1为功能复杂程度权重;
[0152]
m1为功能复杂程度,根据功能模块实现的功能类型进行评级。
[0153]
c2为测试设计成熟度权重;
[0154]
m2为测试设计成熟度,根据模块的历史测试经验及测试设计人员经验评级。
[0155]
c3为功能设计成熟度权重;
[0156]
m3为功能设计成熟度,设计模块的历史应用经验及设计人员经验评级。
[0157]
步骤g:所述的硬件在环测试优化:基于硬件在环测试评价结果,对硬件在环测试缺陷评估进行改进或者对所设定的测试环境进行改进。
[0158]
步骤h:基于改进的硬件在环测试缺陷预估算法,重复步骤d-步骤f,直到所述的测试评价达到所述的硬件在环测试目标。
[0159]
本发明不局限于上述可选实施方式,任何人在本发明的启示下都可得出其他各种形式的产品,但不论在其形状或结构上作任何变化,凡是落入本发明权利要求界定范围内的技术方案,均落在本发明的保护范围之内。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献