基于CAN总线ECU诊断功能的一致性测试设计*

2013-10-22程安宇

传感器与微系统 2013年7期

程安宇，赵恬，申帅

（重庆邮电大学自动化学院，重庆 400065）

0 引言

随着汽车电子技术的发展，越来越多的汽车电子控制单元（electronic control unit，ECU）被应用于汽车控制。传统的诊断方法在诊断的准确性、使用方便性等方面都难以适应现代汽车技术的发展［1］，为解决这一问题，汽车厂商在车辆ECU软件系统中增设诊断协议部分。诊断功能的实现是ECU开发过程中的重要部分［2］。

CAN总线是目前汽车ECU实现通信的主要网络。因此，基于CAN总线的ECU诊断功能的实现已成为诊断技术的必然趋势。一致性测试是诊断协议测试的一个重要方面，是协议开发人员首要关心的问题，它测试诊断协议的实现是否符合协议规范。文献［2］和文献［3］在诊断协议的一致性测试方面测试用例较少，测试不全面，不能验证诊断功能是否符合协议。

本文根据某汽车厂商ECU的诊断需求规范，基于CAN总线诊断协议ISO 15765，设计了测试方案和测试用例，测试用例涵盖需求规范中的所有诊断数据，并通过CANoe总线分析软件中CAPL编程模块完成。

1 CAN总线的诊断系统分析

CAN总线诊断系统如图1所示，客户端向服务器ECU发送某服务的请求报文，服务器收到请求报文，对请求报文的格式和内容进行判断后，发送响应（肯定或否定响应）报文或没有响应。诊断系统通过这种方式完成通信和数据的交换。

图1 CAN总线诊断系统组成Fig 1 Composition of CAN bus diagnostic system

根据开放系统互连（open system interconnection，OSI）七层参考模型，CAN总线诊断通信系统分为4层，如图2所示。应用层遵循 ISO 14229—1UDS（unified diagnostic services）或ISO 15765—3中诊断服务的定义。网络层遵循ISO 15765—2实现数据的传输等。数据链路层和物理层遵循ISO 11898—1［4］。

图2 OSI模型中UDS在CAN总线的实现Fig 2 Implementation of UDS on CAN bus in OSI model

CAN总线诊断协议ISO 15765中，网络层为应用层提供服务接口，应用层通过访问这些服务接口实现与网络层的信息交互［5］。

2 测试方案设计

在诊断系统的开发过程中，诊断协议栈软件完成了诊断协议的一致性测试后，才能将具有诊断功能的ECU应用于整车上。诊断协议栈的测试流程如图3所示，首先，分析协议得到测试数据;然后，将此数据用于被测的诊断协议栈软件，得到测试输出;最后，将测试输出与分析协议得到的预期结果相比较，分析测试结果的正确与否。如果结果正确，则测试通过;如果结果错误，则修改被测软件存在的问题，再次测试。

图3 测试流程Fig 3 Flow chart of test process

2．1 诊断结构设计

诊断结构有3种形式:1）客户端和服务器在同一网络中直接连接;2）客户端通过网关和服务器连接;3）客户端和服务器在2个网络中，客户端与主网络连接，主网络通过网关与子网络连接。

本文的诊断结构采用第一种形式，客户端和服务器ECU在同一网络。如图4所示，服务器ECU为核心芯片为STM8的车身控制模块（body control module，BCM），此外还在其上运行诊断协议栈，其中包括:应用层、网络层和底层软件。客户端为PC机，在其上运行德国Vector公司的CANoe软件，通过CAPL编程实现测试用例来发送诊断服务请求，测试用例分为网络层测试和应用层测试。

图4 诊断系统结构Fig 4 Structure of diagnostic system

CAN总线上的数据在Trace窗口显示，以便分析诊断系统通信是否成功和ECU的诊断协议栈软件是否符合协议规定。

2．2 测试用例设计

从软件测试用例设计方法的角度，分为白盒测试和黑盒测试［6］。本文采用黑盒测试，针对软件的功能需求与实现进行测试。不需考虑程序编码结构，测试者只需了解程序输入和输出间的关系，或是程序的功能。本文依靠程序功能的需求规范和诊断协议确定测试数据，判定测试结果的正确性。

测试用例设计时，需要分析需求规范，然后确定系统正常的输入输出，以验证系统的功能是否正常。由于篇幅限制，这里只列出几项诊断数据，如表1所示，ECU诊断数据的定义，支持的SID（service identifier）、各SID对应的子功能、如表2所示支持的DID（data identifier）、如表3所示网络层时间参数值等内容。

表1 ECU支持的SID定义Tab 1 Definition of SID supported by ECU

表2 ECU支持的DID定义Tab 2 Definition of DID supported by ECU

表3 网络层计时器描述Tab 3 Timer description of network layer

测试用例中不仅有正确的输入，还应有错误的输入，来验证系统对错误情况的处理能力。因此，设计的测试用例分为正常用例和异常用例。本文测试用例的设计根据诊断协议ISO 15765和汽车厂商规定的诊断数据。

1）正常用例

正常用例，即客户端按照正确的报文格式和预定的步骤发送请求报文，以验证网络层和应用层是否符合协议和需求规范。测试要求如下:

a．正常通信下，测试网络层的数据打包，解包和流控制机制，如（客户端）发送单帧、（服务器）响应单帧、发送多帧、响应多帧［7］;

b．测试网络层是否能正确识别数据解包的错误情况;

c．测试应用层服务在合法请求下，响应报文格式是否正确，响应时间是否符合需求规定;

d．测试执行应用层服务合法的执行顺序的情况下，是否实现了其功能。

2）异常用例

异常用例，即客户端按照非法的服务执行顺序发送请求报文，或发送错误的报文格式的请求报文，以验证网络层和应用层是否符合协议规定。测试要求如下:

a．客户端发送错误的N—PDU，测试网络层对错误情况的处理能力;

b．客户端超时发送诊断请求报文，测试网络层对超时的处理情况;

c．客户端发送无效数据帧（除了定义的4种帧类型之外的）或在正常通信时发送其它报文帧打断正在进行的通信过程，测试网络层的处理能力;

d．测试应用层服务在非法请求报文下或非法的服务执行顺序时，能否做出正确的否定响应。

3 测试

3．1 测试项执行

根据分析需求规范的结果设计由DID写入数据执行的流程如图5所示，此流程涉及多个服务的执行，以及单帧、多帧数据的传输。以此为例说明设计测试项。

首先，ECU的会话模式只有进入非默认模式时，才能进行安全访问请求。安全访问请求服务成功执行后ECU解锁，如果ECU未成功解锁，则由否定报文判断失败的原因，修改请求报文后再次执行安全访问请求。ECU解锁成功后由DID读出ECU中存储的数据，然后执行由DID写入数据的服务。为了验证数据是否成功写入，将由相同的DID读出和写入的数据相比较，如果读出和写入的数据相同，证明写入成功;反之，则不成功。