徐永新，刘建飞，华 典，朱 娟

（潍柴动力股份有限公司，山东 潍坊 261061）

科技的进步与发展使得人们的生活与工作更加电子化、自动化与智能化，汽车电子技术也在不断地创新与发展。随着控制器功能的不断扩张，各个厂家对自身产品的控制和信息读取提出了更多的要求，为了规范各个制造商的产品的质量和规范性，国际规定了统一的协议来满足制造商的需求。

基于控制器局域网 （controller area network, can）总线的统一诊断服务（unified diagnostic services, uds）协议诊断被广泛应用到国内外的控制器开发中，来满足自身的开发需求和客户的下线与使用需求。电子控制单元（electronic control unit, ecu）的uds协议及功能的正确性必须得到充分的保证，便于产品的推广及应用。

目前测试方法更多的偏向使用报文收发工具进行手动测试或使用专用诊断工具测试；专用工具无法提前开发，常常会出现因工具未及时交付导致控制器本身没有全面测试而出现质量问题，导致ecu软件开发成本的增加。uds诊断系统自动化测试可以高效完成基于报文交互的全面测试，从而降低缺陷率，减少软件开发成本。

ecu的uds诊断测试主要分为诊断协议测试和诊断功能测试。

uds协议是基于开放系统互联（open systems interconnection, osi）参考模型设计，采用分层结构，主要包括物理层、数据链路层、网络层、会话层和应用层。iso14229协议定义了通用诊断服务，这些诊断服务允许诊断仪控制车辆内部ecu内的诊断功能，但是iso14229协议仅定义了应用层的服务，而iso15765协议是基于can总线实现了uds协议，二者与osi的映射关系如表1所示。

表1 uds协议与osi的映射关系

本文主要阐述的uds诊断协议为应用层的iso14229协议。

uds协议诊断功能单元主要有诊断和通信管理功能单元、数据传输功能单元、传输储存的数据功能单元、输入输出控制功能单元、远程激活例程功能单元、上传下载功能单元，本文主要阐述表2中uds相关服务。

表2 uds服务列表

uds诊断系统中有三种会话模式，分别是正常会话模式、扩展模式及编程模式。其中正常会话模式，是ecu根据输入接口信号的变化进行逻辑计算从而控制车辆行驶；扩展模式主要用于外部维修及执行器测试；而编程模式则是进行ecu内部数据刷写。当存在外部请求时，会根据0x10服务进行会话模式的切换。

然而为保证ecu数据的安全性及软件的正常运行，扩展模式及编程模式下的外部请求操作需要经过0x27服务的密钥安全校验，顺利通过安全校验则解锁ecu，进行维修测试或数据刷写等操作，否则外部请求无效，ecu会回复响应以提示安全校验失败。具体流程如图1所示。

图1 安全访问流程图

诊断协议主要测试国际标准化组织（international organization for standardization, iso）标准协议中规定的内容，借助canoe等诊断工具即可完成；而诊断功能主要测试ecu的输入输出功能是否满足软件开发需求，比如外部设备请求ecu输出启动继电器吸合的控制信号，则需要观察启动继电器负载是否有输出。本文着重介绍uds诊断功能的自动化测试。

测试uds诊断功能需要搭建一个闭环系统，从硬件输入信号的变化到ecu的响应输出最终到执行器的实际动作检测，才是一条完整的测试流程并能保证测试的有效性及功能的正确性。通常的闭环测试系统如图2所示，主要包括被测ecu、硬件在环测试设备（hareware in the loop, hil）台架（含有虚拟或真实负载）、诊断工具（vector hardware）、标定工具（integrated calibration and acquisition systems, inca）、上位机。

图2 测试闭环系统

依据上述的测试平台，需要工程师对ecu中的每一条数据流、每一个执行器的诊断进行测试，数量之多，耗时耗力，且uds的诊断测试操作相似，非常适合自动化测试及测试用例的移植。本文依据自动化测试软件ecu-test进行测试用例的开发。

ecu-test工具可以与hil设备、inca、vector-hardware进行链接，并通过应用程序编程接口（application programming interface, api）函数对hil设备上位机软件、inca、vector-hardware进行读写操作，而且ecu-test软件支持二次开发，可以通过开发python脚本实现特殊的测试需求，保证测试用例的顺利进行。

根据图2所示的测试环境，通过ecu-test自动化测试软件将vector、inca及hil上位机软件连接起来，形式闭环测试系统，并在ecu-test中编制测试用例及相应的脚本实现uds诊断系统的自动化测试。

数据流测试是根据iso14229协议中的0x22服务获取ecu中相关变量的数值，该服务不需要经过ecu的安全访问。

数据识别符（data identifier, did）数据流信息汇总如表3所示，在测试过程中根据did码获取ecu的响应，并将返回值根据其基础数据类型、因子及偏移进行换算与inca（xcp:1协议）监测值进行对比，判断did码返回值是否正确。

表3 did数据流信息

did数据流的自动化测试采用ecu-test的parameter generator功能实现，可以在20 min内完成300条did数据流的自动化测试，其测试流程如图3所示。该测试方法简单、高效且便于移植。

图3 did数据流测试流程

uds的执行器测试与服务诊断测试，使用iso14229协议的0x2f服务及0x31服务，需要经过ecu的安全访问才可以进行后续操作，如图1所示。

为确保ecu软件及整车的行驶安全性，不同的控制器、相同的控制器不同的功能都会有各自的安全校验算法。因此，诊断功能的自动化测试难点及关键点就是如何与ecu完成安全校验。

ecu安全校验算法文件是ecu的门户，在ecu的生命周期中密级是最高的，所以无法获取该文件中的具体算法，因而可以使用脚本调用该算法文件间接实现全面的自动化测试。通过ecu-test调用vector的api函数模拟图1的安全访问过程，在获取到seed时调用python脚本计算出key，然后再通过vector的api函数发送给ecu，从而实现与ecu的安全校验。安全访问的自动化测试用例流程如图4所示，图5为某ecu安全访问自动化测试顺利通过安全访问的测试报告。

图4 安全访问测试流程

图5 安全访问报告

将安全访问的自动化测试用例封装成模块库，可以被ecu各执行器的测试任意调用。诊断功能的自动化测试流程如图6所示，其中“安全访问”是对安全访问自动测试用例模块库的调用。

图6 执行器自动化测试

某发动机ecu执行器测试的自动化测试用例如图7所示，测试报告如图8所示。

图7 某发动机ecu执行器诊断自动测试用例

图8 测试报告

通过对某发动机ecu执行器诊断功能的测试，充分证明该自动测试方法可以顺利通过ecu的安全访问并完成对ecu数据流读取、执行器测试和服务诊断功能的验证，大大缩减了ecu软件开发过程中的重复性测试的工作量，保证了软件测试的高效性和一致性，有效保障了软件的开发进度及uds诊断系统质量。