2.2.2 试验管理Layout设计
试验管理Layout设计主要是实现一个比较友好的人机界面，方便用户进行测试、分析、统计、查看等一系列测试管理工作。基于ControlDesk试验管理软件，设计测试界面Layout，主 要包括以下几个部分： ①系 统基本控制窗口；②传感器输入信号模拟窗口；③执行器输出信号采集窗口；④数据分析窗口；⑤总线数据显示窗口；⑥图标界面显示窗口。

2.2.3 传感器信号标定测试
通过界面控制，对测试机柜的传感器仿真信号进行模拟，结合标定工具CANape或INCA对传感器信号进行采集测试，并进行标定和确认。

2.2.4 执行器信号标定测试
需要对执行器的驱动负载进行模拟或采用实际负载，结合标定工具CANape或INCA对执行器的驱动信号进行测试，并进行标定和确认。
2.2.5 测试台架安装与调试
对预先设计好的方案进行台架样件安装以及线束连接，然后对台架进行调试以及信号激励测试，确保各个信号准确有效性，最后进行系统台架系统联调。
2.3 测试矩阵规范设计
测试矩阵规范是进行测试用例设计的依据，包含整个测试内容的系统功能划分、测试项和测试用例条目的概述、需求映射关系、测试执行情况的跟踪等；测试矩阵中根据测试方案及控制器功能特征、危险等级、用户体验、供应商能力、法规与标准等制定各个功能项的安全等级及测试深度。
2.4 测试用例设计
测试用例设计是测试实施的依据，根据测试方案和测试矩阵开发具体的测试指导文件，每条测试用例包括用例ID、用例名称、初始条件、测试步骤、期望结果和测试结果。每一用例名称代表一个测试点并且拥有惟一ID。通过使用测试ID，有利于测试活动的可追溯性，便于测试管理。
2.5 自动化测试脚本开发
根据测试需求和控制器功能规范，基于自动化测试软件环境，按照测试要求组织测试序列，开发测试脚本，主要针对一些流程性或实时性测试方面的测试用例。自动化测试开发采用离线测试和在线测试相结合的方法，提高测试工作效率。
2.6 网络系统测试
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来实现。

2.7 系统功能测试
要能够完整地验证系统的功能策略，需要利用硬件在环系统使控制器在一个可控的虚拟环境下进行各种功能性及分布式功能测试，以确定目前的控制策略功能可以完全满足用户的需求。
具体的功能测试需要供应商提供相关的功能规范及控制策略。依据功能控制策略，编写测试用例，在Controldesk或AutomationDesk环境下实现控制器的系统功能测试。

2.8 故障注入及诊断测试
系统的诊断功能测试，主要分为以下2个层次。
1） 电器硬件故障诊断测试。硬件故障又分为传感器故障诊断和执行器故障诊断。通过故障注入模块可产生如下的电气错误类型： 开路、对电源短路 （KL30）、对点火起动电源短路 （KL15）、搭铁短路 （KL31）、信号线短路、信号不良、信号线互相短路。
2） 系统功能故障诊断测试。系统的功能性故障诊断测试，需要获取控制器的诊断策略，通常这些是供应商或主机厂的技术核心，需要双方协商一起来实现这部分的诊断测试。

2.9 系统测试及自动化
系统自动化测试是在HIL系统基础测试的基础上，基于AutomationDesk环境，开发测试序列，并结合相关诊断工具、标定工具，对系统功能、诊断策略、网络通信进行自动化测试，测试完成形成测试报告。

3 结束语
硬件在环测试具有传统实车测试中不可比拟的优点，从 安全性 、可行性和合理的成本上考虑，硬件在环仿真测试已经成为汽车厂开发流程中非常重要的一环，不仅减少了实车路试的次数，缩短开发时间和降低成本，同时还提高电控ECU的软件品质，降低汽车厂的风险。

上一页  [1] [2]