汽车仪表网络管理一致性测试系统设计

2019-03-28 06:17唐华亮方红萍
仪表技术与传感器 2019年2期
关键词:测试用例网络管理报文

唐华亮,方红萍,谢 斌

(1.武汉科技大学冶金自动化与检测技术教育部工程研究中心,湖北武汉 430081;2.武汉保华显示有限公司,湖北武汉 430082)

0 引言

汽车仪表能为驾驶员提供重要的车辆信息,如车速、转速、油量、故障报警和指示信息等,一方面能有效保障驾驶员安全驾驶,另一方面也是车辆上协调控制其他节点合理运作的重要组成部分,如管理车载ECU(Electronic Control Unit)节点满足协同睡眠而又随需唤醒的低功耗需求等[1-2]。

网络管理(Network Management,简称NM)是汽车仪表的关键模块。OSEK(Open Systems and the Corresponding Interface for Automotive Electronics)和AUTOSAR (Automotive Open System Architecture)是目前两种主流的车载网络管理策略和接口服务实现规范[3-4]。但是上述规范均采用非形式化语言描述,一旦存在理解偏差就很容易导致汽车仪表网络管理协议实现和协议规范不一致,对汽车安全造成潜在隐患[5-6]。因此汽车仪表网络管理一致性测试是重要汽车仪表测试环节。

网络管理一致性测试是一种功能性黑盒测试,它通过输入测试信号触发被测仪表,通过对比仪表的响应信息与预定协议规范是否一致来评价协议测试是否合格。目前国外已有CANOE测试工具、TTCN测试套件描述语言等聚焦汽车仪表网络管理协议测试,配套使用CAN适配器CANcaseXL和CAN总线干扰设备CANstress实现一致性测试[7-8]。但是上述工具和设备均为国外商业软件和设备,设备购买价格或者相应测试套件服务收费相当昂贵。另外基于TTCN的测试用例定义过程较为复杂、繁琐,一方面容易产生较多的空表项,影响测试效率,另一方面降低了测试人员结合测试需求编写、修改测试脚本的灵活度。国内研究学者在协议形式化描述、协议一致性测试序列生成和协议一致性测试执行等方面也开展了一系列研究[9]。如文献[10]提出了一种基于分类树的OSEK协议操作系统一致性测试用例生成方法。文献[11]验证了TTCN-3语言进行AUTOSAR一致性测试的可行性,但国内总体而言在此方面的研究还不够深入。

本文参考汽车仪表网络管理一致性测试的国际标准,设计一种支持结构化编程的TSCN测试用例脚本语言,然后在此基础上设计一个基于测试脚本驱动的汽车仪表网络管理协议一致性自动测试系统,实现了测试用例编写、存储、执行和测试状态监控的全过程自动化。

1 汽车仪表NM协议一致性测试项目分析

车载网络中每个ECU节点有唯一地址编号。OSEK/VDX直接网络管理按照ECU地址递增顺序构造逻辑环,并采用逻辑环机制监控网络各ECU节点正常模式、睡眠模式及错误处理模式之间的状态切换,实现对网络节点的协同管理。AUTOSAR网络管理采用分布式直接网络管理策略,根据网络管理协议数据单元(NMPDU)接收情况来监控网络状态[12-13]。

OSEK/VDX和AUTOSAR的NMPDU均包含地址域、控制域和数据域三个部分。地址域指定通信双方ECU节点地址;操作域说明具体报文类型,OSEK/VDX网络管理报文有Alive、Ring和 Limphome 3种报文,AUTOSAR网络管理主要有RepeatMessage和NormalOperation两种报文;数据域指定报文附加信息(可选)。

NM协议一致性测试主要分为物理层、网络层和通信层测试3个部分。物理层测试通过操控某些物理模块来模拟物理干扰(如CAN干扰或电压干扰等),测试ECU节点的干扰恢复能力。网络层测试主要监控ECU节点网络状态切换,如唤醒、休眠或者逻辑环建立等。通信层测试主要测试汽车仪表网络管理报文的周期、类型或其他参数等。各层常用测试用例及所涉及到的信号类型见表1。

表1 NM协议一致性测试分层表

2 测试用例脚本语言TSCN设计

基于表1中测试用例和信号响应类型的对应关系,借鉴C语言结构化控制思路[14],本文设计了一种新的测试用例脚本语言TSCN (Test Script Control Notation )。TSCN语言中主要包含标识符、指令关键字和控制关键字3个部分。

标识符由字母和数字组成。

指令关键字包含主关键字和次关键字。指令主关键字VOL、IO、TIMER、CAN和RESULT依次对应电压信号、IO口信号、TIMER定时器信号、CAN信号和结果返回指令类型。次关键字则指定相应测试指令具体操作码,见表2。

表2 TSCN语言关键字

部分基础指令结构展示,见表3。

为了实现对测试指令执行逻辑的有效控制,参考结构化语言的特点,TSCN脚本语言中引入TEST、IF和WHILE等控制关键字。

表3 基础指令结构

TSCN用例中包含两类指令语句。一类基础指令语句以“<”开始,以“>”结束。每条基础指令包含指令主关键字、指令次关键字、参数三个部分见表3。如VOL、IO、TIMER、CAN和RESULT语句。第二类复合指令语句,控制多条基础指令按照指定逻辑执行,如IF、WHILE语句。

TSCN用例语法规则树见图1。按照语法规则测试人员可以快速编写测试用例脚本,同时用例编译器也会按照语法规则树对脚本进行语法检查。

图1 TSCN语法规则树

3 NM协议一致性测试系统设计与实现

一致性测试系统(Conformance Test System,CTS)由上位机监测仪、下位机测试仪和被测仪表三部分组成,见图2。

图2 NM协议一致性测试系统总体架构

基于PC平台的上位机监测仪主要实现测试用例编辑、编译、编码下载和测试过程状态自动监控等功能,它和下位机测试仪采用串口通信方式。

基于STM32的下位机测试仪存储上位机下载的测试用例指令,并采用解释执行方式自动执行测试用例脚本。下位机测试仪和被测仪表通过CAN、IO和VOL接口连接。CAN接口实现报文传输,IO接口实现对被测仪表IO端口对应的开关信号的检测,VOL接口实现给被测仪表供电。

3.1 下位机测试仪的硬件设计

下位机测试仪选用STM32F105RCT6作为主控芯片,硬件框架见图3。其主要功能模块包括物理层程控电压模块、物理层干扰模拟(含电压干扰和CAN干扰)、CAN通信模块、显示报警模块、定时器实时控制模块。

图3 测试仪硬件主框架图

程控电压模块:选用LM2596-ADJ(简称ADJ)芯片输出程控可调电压。ADJ芯片内含基准稳压器(1.23 V),通过ADJ输出引脚、地线和主控芯片DAC引脚分别相对于反馈引脚FB接一个电阻R1、R2和R3,电阻阻值根据需求进行计算和设计。控制数模转换器的输出电压,实现ADJ变换器输出电压的调整。

干扰模块:电压干扰模块采用继电器多级串联方式控制可调电压输出线路的短路、断路、悬空几种状态,实现被测设备供电电压的拉高、拉低、悬空情况的模拟。CAN干扰模块采用继电器多级串并联方式,控制CAN高、CAN低和电源输出线多种组合接触情况的CAN干扰模拟。

CAN通信模块:STM32F105RCT6主芯片有两路CAN接口,满足系统多路CAN同时工作的需求,且CAN收发器的型号选用TJA1040芯片,输出端通过导线连接CAN干扰模块。

显示报警模块:添加LED、显示屏和报警装置,实时监控测试状态。

定时器实时控制模块:STM32F105RCT6芯片有10个定时器且支持引脚重映射功能。系统将部分定时器用于程序中断或周期性操作,另一部分供用户配置使用,实现报文收发计时、延时等操作。

3.2 基于TSCN脚本的测试用例编写

以某款汽车仪表物理CAN干扰一致性测试用例为例,介绍基于TSCN的测试用例脚本编写过程。

3.2.1 测试目的

该款汽车仪表ECU节点(地址:X430)正常通信时,测试CAN干扰后的通信恢复能力。

3.2.2 测试步骤

(1)通过CAN高和CAN低短路产生CAN干扰;

(2)延时1 s;

(3)CAN高和CAN低短路恢复正常,消除干扰;

(4)检测Busoff恢复时间内是否接收Limphome报文,如果接受到,测试合格返回通过信号;如果没接受到,测试不合格返回失败信号。

3.2.3 预期结果

(1)总线短路后,若停止收发报文则说明总线进入Busoff状态,干扰模拟测试成功,否则失败;

(2)干扰消除后,测试仪在Busoff恢复时间(200 ms)内接收到第一帧Limphome报文,则说明CAN干扰恢复测试符合测试协议标准,否则测试不合格。

测试用例的TSCN语言脚本

//CAN高和CAN低短路,Busoff模拟

//延时1s的时间

//消除故障,Busoff恢复

IF(TEST

//检测条件,ID号为X430,数据为3004

[

//接收Limphome报文,时间0~200 ms

]>) //CAN接收,X430:仪表节点地址,2:检测的数据长度DLC,

{

//延时1 s的时间

//返回TP_1项目测试结果,合格

}

ELSE

{

//延时1s的时间

//返回TP_1项目测试结果,不合格

}

3.3 TSCN脚本驱动的NM协议一致性自动测试

下位机测试仪采用解释执行方式顺序执行。脚本中指令语句的合理存储是脚本有效执行的关键。

TSCN测试脚本从上至下由若干条指令语句组成,指令语句分为基础指令和复合指令两类。测试脚本对应的指令数据存储结构如下:

#include MaxsizeComm 200

//基础指令数据结构

typedef struct baseCom

{char mainKey[10];

char subKey[10];

char paramData[100];

struct baseComm *nextComm;

};

typedef struct //命令行数据结构

{

char comType[10];

char commCondiiton[50];

struct baseCom *condition0pter;

struct baseComm *success0pter;

struct baseComm *fail0pter;

}commandLine;

commandLine com[MaxsizeComm];

经分析不难发现,在执行过程中IF或者WHILE等复合指令语句实际上是依据一定逻辑条件控制多条基础指令语句组合执行。如果将基础指令语句看作逻辑条件恒为真的特殊复合指令语句,这样两类指令语句就可以统一用命令行(commandLine)结构描述。commandLine结构包含5个数据子项,前两项描述指令语句的类型和执行条件,后三项分别是基础指令baseComm链表的头指针域,描述条件判断、条件成立和不成立时要执行的多个基础测试指令集合。基础指令语句对应的commandLine结构中,commCondition子项默认为’’,conditionOpter和failOpter指针默认NULL;WHILE复合语句对应的commandLine结构中,failOpter指针默认为NULL。基础测试指令采用baseComm结构体描述,分别对应VOL、IO、TIMER、CAN和RESULT等基础指令的主关键字、次关键字和参数信息。TSCN脚本中所有指令语句从上至下依次存储到comm结构顺序表中。3.2中的CAN干扰测试用例脚本传输到测试仪中的指令存储形式如图4所示。

图4 测试用例指令存储结构

基于以上指令存储结构,用例脚本解释执行算法如下:

先取出当前指令语句的指令类型,如果是基础指令,直接执行成功指令集,如果不是,判断是否为IF语句;如果为IF语句,直接执行条件指令集,然后根据结果对比条件文本串,满足条件时则执行成功指令集,不满足则执行失败指令集;如果不是IF语句,则为WHILE语句,条件指令集执行后,结果满足条件时,会执行成功指令集,进而跳转到条件指令集继续执行,如果条件指令集执行后结果不满足条件,执行失败指令集,而后判断下一条指令,如图5所示。

图5 NM协议一致性自动测试流程

4 测试结果与分析

4.1 一致性用例测试及结果分析

采用CTS,以物理CAN干扰、逻辑环稳定性两个测试用例为例进行一致性测试。

4.1.1 CAN高低短路干扰测试用例

该用例的测试目的、步骤、预期结果见3.2。

测试结果如图6所示当CAN干扰产生时,被测仪表停止接受报文,表明仪表进入Busoff状态,干扰模拟成功。干扰清除后的第185 ms测试仪表开始正常接收报文,时间处于Busoff恢复周期200 ms内。测试结果表明被测仪表抗CAN干扰能力良好。

图6 CAN高低短路测试结果截图

4.1.2 多ECU节点逻辑环建立测试用例

4.1.2.1 测试目标

测试地址分别为X450和X480的ECU节点能否和被测仪表(地址X430)建立稳定逻辑环。

4.1.2.2 测试步骤

(1)虚拟ECU节点(X450和X480)发送Alive报文;相隔100 ms,再次发送指向自身的Ring报文;

(2)检测被测仪表(X430)响应的Ring报文。

(3)间隔100 ms,X450节点发送指向X480的Ring报文;再间隔100 ms,X480节点发送指向X430的Ring报文,

(4)循环操作步骤(2)和步骤(3)。

4.1.2.3 预期结果

(1)虚拟节点发送指向自身的Ring报文之后,检测到仪表响应的指向X450的Ring报文。则虚拟节点成功申请建环,否则申请失败。

(2)虚拟节点发送完指向后继节点的Ring报文之后,检测到仪表响应的指向X450的Ring报文;且任何Ring-Ring报文时间戳在100 ms±10%之内,则说明逻辑环稳定,否则不稳定;

图7测试结果说明虚拟ECU节点(X450和X480)和被测仪表逻辑建环成功,且稳定。

图7 3个节点逻辑建环测试结果截图

4.2 测试效率对比与分析

实验内容:采用东南DX7车型仪表(载有OSEK协议NM)和吉利5HA车型仪表(载有AUTOSAR协议NM)为被测设备,以50个标准测试用例的制作、编译、测试,测试报告生成等几个阶段分别对比平均测试耗时。实验方法:采用手动测试和本文提出的一致性自动测试平台分别测试。测试结果见表4。

表4 测试时间对比 s

由表4可知,针对OSEK和AUTOSAR两种协议测试,采用本系统进行一致性测试,在用例制作、检错/编译、测试执行和报告生成等4个阶段均大幅度缩短了测试时间,总的测试时间相比原来的手动测试均减少将近2/3的时间。

5 结束语

汽车仪表网络管理协议的一致性测试是保障汽车安全必不可少的测试环节。本文设计了一种基于TSCN脚本驱动的汽车仪表网络管理一致性自动测试系统。该平台具有如下优点:

(1) 提出的TSCN测试用例脚本语言能有效描述目前两种主流车载网络管理协议测试用例,提高了系统的通用性,另外该脚本支持结构化编程,能有效描述测试逻辑,增加了测试用例设计的灵活度;

(2)下位机测试仪提供的物理层干扰模块和接口驱动支持,实现了对被测汽车仪表的实时物理层测试,相对目前的测试方式,有效保证了协议测试的实时性能;

(3) 实现了汽车仪表网络管理协议一致性测试全过程自动化。

基于本文提出的一致性测试系统,对多款不同车型汽车仪表进行了网络管理协议一致性测试,测试效果良好,且测试效率有明显提高。

猜你喜欢
测试用例网络管理报文
基于J1939 协议多包报文的时序研究及应用
数控机床DNC网络管理平台在智能制造中的应用
回归测试中测试用例优化技术研究与探索
基于SmartUnit的安全通信系统单元测试用例自动生成
CTCS-2级报文数据管理需求分析和实现
浅析反驳类报文要点
基于OpenStack虚拟化网络管理平台的设计与实现
电动汽车充电服务网络管理初探
基于EOC通道的SHDSL网络管理技术
ATS与列车通信报文分析