吕 峰,欧增开
(东风柳州汽车有限公司技术中心,广西 柳州 545005)
近年来,国内自主品牌企业在整车电控系统研发设计方面投入了很多资金和人员力量,并且配备自主开发的控制器的车型也陆续上市。但从研发设计到实车测试验证阶段,整体来说还不具备较完善的测试环境和测试流程,尤其是控制器控制策略及故障诊断策略的测试验证方面,还处于简单的车身台架及手动测试阶段。这种模式只能对常规的逻辑类功能进行验证,不能覆盖到包括复杂交互式性能、故障 (电器、功能)注入、极限工况以及对时间参数有严格要求的逻辑功能测试,况且这些工况在实车测试环节中也未必能遇到。由于测试环节的不够完善,导致上市的车辆会存在没有及时发现的潜在问题[1],因此自主企业针对电控单元的研发、测试及验证过程,建立先进的测试环境条件以及完善的测试流程至关重要,本文针对某车型整车电控系统进行硬件在环测试的方案原理及测试流程进行阐述。
某车型的整车系统网络拓扑架构如图1所示。整个测试过程需要搭建系统硬件在环 (HIL)仿真测试环境,基于该平台环境,实现对整车系统电器系统的功能策略进行验证测试,实现网络系统的复杂测试,对被控对象进行工况模拟,实现电控系统的故障模式注入 (电器故障和功能故障)及诊断测试。
系统硬件设计需求分析是搭建HIL测试环境的前提。需要根据以下设计输入 (客户及供应商提供)对HIL系统进行电器接口配置设计:①整车电气原理图;②电控单元引脚定义;③电控单元输入输出接口电路;④电控单元传感器特性参数;⑤电控单元执行机构特性参数;⑥电控单元插接件及连接线束;⑦执行机构插接件及连接线束;⑧整车网络拓扑定义;⑨整车网络通信数据库 (dbc文件和ldf文件);⑩诊断协议及诊断数据库 (cdd文件);11故障码列表及故障注入方式。
系统软件设计需求主要是基于用户需求、被测对象功能测试需求分析基础之上,确定测试管理Layout、数据采集及数据分析环境、系统测试控制软件界面以及自动化测试环境等。
HIL系统功能测试除了搭建系统硬件环境,即满足电控单元所需的整车电气环境、测试软件管理环境之外,还需要搭建整车系统运行环境,需要构建发动机系统、动力传动系统、车辆动力学系统、道路环境及驾驶员模型等车辆运行环境模型。
HIL测试系统主要包括硬件仿真平台 (dSPA-CE Simulator和测试台架)、实时仿真ASM模型以及测试管理软件 (控制台操作界面)等几部分。
2.1.1 硬件仿真平台Simulator
硬件仿真平台采用的是德国dSPACE Simulat-or,该平台主要用于和真实电控单元进行电气连接及通信,提供控制器所需的各种传感器输入信号,并接受控制器发出的各种控制信号,反馈给车辆模型进行计算仿真,同时可以产生 (模拟)各种故障用于故障工况仿真。
2.1.2 实时仿真模型
实时仿真模型包括IO模型和车辆模型,IO模型主要负责把传感器等的物理信号通过转换关系得到电气信号值,同时把采集到的电气信号值通过转换关系得到物理值;车辆模型包括发动机、传动系(包括变速器和差速器等)、车辆动力学以及道路环境模型。图2为实时仿真模型外层基本框架。
通过ModelDesk利用提供的发动机、变速器等车辆参数对车辆模型进行参数化,使实时仿真模型能够正确模拟车辆运动,被控对象能够及时准确响应控制器的控制动作并把运动状态反馈给控制器。
2.1.3 系统测试控制管理
利用ControlDesk测试管理软件创建图形化界面(图3),对整个测试过程进行控制和管理,能够进行硬件管理、虚拟仪表显示、数据监控、变量及参数设置,并进行模型的下载[2]。
基于AutomationDesk自动化测试管理平台,按照测试规范,编制相应的测试序列,实现测试用例的实现及自动化测试脚本开发,并形成测试报告。
2.2.1 系统硬件接口配置
根据控制器的引脚功能定义、传感器与驱动器的电气特性,对HIL测试系统进行I/O通道的建立与配置管理,并且根据客户的需求完善系统配置。在此基础之上,设计测试系统的信号列表Signal List,该信号列表全面地反映了HIL测试系统的功能配置,并根据需求与定义,完善此列表。主要工作如下:①控制器相关板卡配置;②控制器与仿真柜的硬线连接;③dSPACE相关实时系统软件配置;④I/O模型配置与映射;⑤传感器及执行机构参数匹配;⑥集成CANLIN通信模型。
2.2.2 试验管理Layout设计
试验管理Layout设计主要是实现一个比较友好的人机界面,方便用户进行测试、分析、统计、查看等一系列测试管理工作。基于ControlDesk试验管理软件,设计测试界面Layout,主要包括以下几个部 分[3]:①系 统 基 本 控制窗口;②传感器输入信号模拟窗口;③执行器输出信号采集窗口;④数据分析窗口;⑤总线数据显示窗口;⑥图标界面显示窗口。
2.2.3 传感器信号标定测试
通过界面控制,对测试机柜的传感器仿真信号进行模拟,结合标定工具CANape或INCA对传感器信号进行采集测试,并进行标定和确认。
2.2.4 执行器信号标定测试
需要对执行器的驱动负载进行模拟或采用实际负载,结合标定工具CANape或INCA对执行器的驱动信号进行测试,并进行标定和确认。
2.2.5 测试台架安装与调试
对预先设计好的方案进行台架样件安装以及线束连接,然后对台架进行调试以及信号激励测试,确保各个信号准确有效性,最后进行系统台架系统联调。
测试矩阵规范是进行测试用例设计的依据,包含整个测试内容的系统功能划分、测试项和测试用例条目的概述、需求映射关系、测试执行情况的跟踪等;测试矩阵中根据测试方案及控制器功能特征、危险等级、用户体验、供应商能力、法规与标准等制定各个功能项的安全等级及测试深度。
测试用例设计是测试实施的依据,根据测试方案和测试矩阵开发具体的测试指导文件,每条测试用例包括用例ID、用例名称、初始条件、测试步骤、期望结果和测试结果。每一用例名称代表一个测试点并且拥有惟一ID。通过使用测试ID,有利于测试活动的可追溯性,便于测试管理。
根据测试需求和控制器功能规范,基于自动化测试软件环境,按照测试要求组织测试序列,开发测试脚本,主要针对一些流程性或实时性测试方面的测试用例。自动化测试开发采用离线测试和在线测试相结合的方法,提高测试工作效率。
2.6.1 CAN网络系统测试
CAN网络通信测试主要是根据特定的整车网络拓扑图 (或dbc文件),为待测电控单元建立网络测试环境,进行残余总线仿真,通过专用CAN配置工具RTICANMM来实现。基于HIL实时测试平台,可以进行以下测试:①报文ID;②报文长度;③报文传输率;④支持ECU本身节点BUS OFF;⑤CHK确认 (报文中包含CHK信息);⑥计数器确认 (报文中包含计数器信息);⑦总线负载率确认 (Bus navigator中可观测总线负载率)。
为了对整车网络系统进行完整的测试和仿真,需要将网络测试设备与硬件在环测试设备一起协同工作,如Vector公司的CANStress或CANoe等。
2.6.2 LIN网络节点仿真测试
LIN网络通信测试主要根据LIN网络通信数据库(ldf文件),为待测电控单元建立网络测试环境,进行LIN总线节点的仿真测试,通过专用的LIN配置工具RTILINMM来实现。
要能够完整地验证系统的功能策略,需要利用硬件在环系统使控制器在一个可控的虚拟环境下进行各种功能性及分布式功能测试,以确定目前的控制策略功能可以完全满足用户的需求。
具体的功能测试需要供应商提供相关的功能规范及控制策略。依据功能控制策略,编写测试用例,在Controldesk或AutomationDesk环境下实现控制器的系统功能测试。
系统的诊断功能测试,主要分为以下2个层次。
1)电器硬件故障诊断测试。硬件故障又分为传感器故障诊断和执行器故障诊断。通过故障注入模块可产生如下的电气错误类型:开路、对电源短路 (KL30)、对点火起动电源短路 (KL15)、 搭铁短路 (KL31)、信号线短路、信号不良、信号线互相短路。
2)系统功能故障诊断测试。系统的功能性故障诊断测试,需要获取控制器的诊断策略,通常这些是供应商或主机厂的技术核心,需要双方协商一起来实现这部分的诊断测试。
系统自动化测试是在HIL系统基础测试的基础上,基于AutomationDesk环境,开发测试序列,并结合相关诊断工具、标定工具,对系统功能、诊断策略、网络通信进行自动化测试,测试完成形成测试报告。
硬件在环测试具有传统实车测试中不可比拟的优点[4],从安全性、可行性和合理的成本上考虑,硬件在环仿真测试已经成为汽车厂开发流程中非常重要的一环,不仅减少了实车路试的次数,缩短开发时间和降低成本,同时还提高电控ECU的软件品质, 降低汽车厂的风险[5]。
[1]雷叶红,张记华,张春明.基于dSPACE_MATLAB_Simulink平台的实时仿真技术研究[J].系统仿真技术,2005 (3):13-17.
[2]Susanne Kohl, Dirk Jegminat.How to Do Hardware-in-the-Loop Simulation Right[J].SAE Paper.2005 (1):1657.
[3]李幼德,刘巍,李静,等.汽车稳定性控制系统硬件在环仿真[J].吉林大学学报, 2007 (4):3-6.
[4]胡朝峰.汽车电子电器硬件在环仿真实验系统的研究[J].汽车电器,2010(6):50-52.
[5]范莹.基于dSPACE的列控车载控制器测试方法的研究(硕士学位论文)[D].北京:北京交通大学,2012.