基于CAN FD网络的UDS诊断开发测试

施春华

（同济大学，上海 200092）

汽车作为一款机电一体化的设备，目前正在向智能化、网联化快速发展，而其中汽车网络的发展也是越来越快。其中CAN总线是被最广泛使用的汽车总线，近几十年来市场的占有率越来越高，但是因为CAN协议的特性，最多只能达到500kbit/s，限制了网络通信速度的进一步提高，这一情况催生出了在CAN总线物理设备的基础上，使用可变速率CAN通信的方式即CAN FD（CAN With Flexible Data-Rate）的出现。

汽车诊断的协议可以在不同的总线技术上实现，每一次汽车总线变革都会要求诊断协议进行相应的匹配。虽然支持CAN FD的车型以及产品越来越多，但是对于诊断在CAN FD总线上的实际使用，目前的研究还比较少。如：刘乐乐研究了在CAN FD总线的基础上，通过使用CANoe软件设计基于UDS协议的刷新系统，实现Bootloader的刷写过程；PARK P Y开发了一套基于CAN FD的刷新设备以及网关，可实现CAN FD总线与CAN总线的切换，提高数据刷写效率；TH Nguyen研究了CAN FD网络的数据场结构，通过CANoe的模拟实现了CAN FD和CAN网络的ECU刷新时间比较，说明支持CAN FD总线的优势。

本文介绍在CAN FD网络的基础上，实现通用的UDS诊断协议，开发部分相关的测试功能，并在试验台架上进行通信诊断功能的验证。

1 CAN FD总线报文结构解析

1.1 CAN FD总线特性

CAN FD为BOSCH公司在2012年推出的基于原有CAN总线物理层的高速通信技术。CAN FD在基本不改变物理设备硬件要求的基础上实现部分数据的可变速率传输。通过CAN FD网络传输的速率可达5Mbit/s，CAN FD总线与其他总线比较，在实现高速通信的前提下，可以运行在现有的CAN总线物理设备上，降低了硬件更新换代的费用，并适配目前大量使用的CAN总线物理设备场景，是下一代汽车总线技术的有力竞争者。

1.2 CAN FD总线报文结构

CAN FD实现可变速率传输的关键，在于数据帧中的不同部分实行两种传输速度。与CAN一样，CAN FD数据帧包括7个部分：帧起始、仲裁域、控制域、数据域、检验域、应答域、帧结束。以CAN扩展帧为例，图1比较了CAN FD与CAN扩展帧的区别，CAN标准帧也是同样的情况，CAN FD增加了一些标志位、更大数据域和校验位。

图1 CAN FD与CAN扩展帧报文结构比较

CAN FD帧结构与CAN比较，区别在以下几个方面。

1）CAN FD替换增加了新的标志位。CAN FD帧起始和CAN一样为一个显性位（0），之后仲裁场中的Identifier和扩展ID保持不变，RTR位变更为RRS位（远程请求取代位），总是显性，因为CAN FD不支持remote frame远程帧。控制场中，FDF（FD Format Indicator）位用于标识帧类型，FDF隐性标识帧为CAN FD帧；显性则标识为CAN帧。增加了BRS（位速率转换位），用于标识CAN FD的速率切换，只有在隐性时进行切换，显性保持原有速率；ESI（错误状态知识）位，主动错误节点为显性，被动错误节点为隐性。

2）CAN FD支持两种速率传输。当BRS位为1（隐性）时，从BRS位后到CRC界定符为止，采取数据段速率；其余位仍采取标准速率。两种速率采取不同的时间定义寄存器，时间定义tQ。

3）CAN FD支持更高的带宽。CAN FD数据域扩充到了64个字节，与CAN的8字节比较扩大了8倍，通过控制域中的DLC（数据长度控制）编码方式的扩展实现。DLC的编码方式1～8个字节同CAN，出现大于8个字节的数据场即9～64字节，编码方式为非线性增长，见表1。对于CAN FD扩展的字节容量，分别为8，12，16，20，24，32，48以及64。

表1 CAN FD DLC编码

4）检验域CRC计算方式扩展。CAN总线CRC检验域采用CRC_15，CAN FD增加了CRC_17，用于小于等于16字节的数据长度；CRC_21用于小于等于64的数据长度。其多项式定义见表2。

表2 CRC校验多项式定义

1.3 CAN FD总线报文发送方式

对于诊断，CAN FD同CAN总线，在传输层定义了4种帧格式，即Single Frame、First Frame、Consecutive Frame、Flow Control。数据发送方式也与CAN类似，对于数据容量满足单帧的数据直接发送；对于数据容量超过单帧承载能力的数据，按照协议进行分割重组，然后进行多帧的传递方式。CAN FD数据传输方式见图2。

图2 CAN FD数据传输方式

与CAN总线不同的是因为CAN FD帧数据承载量变大，对于Single Frame和First Frame的SF_DL和FF_DL进行了扩展，见表3。为了适应数据容量的增加，红色圈出部分为CAN FD新增加的PCI定义。

表3 CAN FD N PCI信息

2 UDS诊断协议研究

2.1 UDS诊断协议介绍

2006年ISO组织发布了ISO 14229标准UDS（Unified Diagnostic Services），不依赖于任何实际的总线技术，单独定义的通用诊断服务标准。此协议独立于具体的汽车总线之外，构建了应用层的诊断服务和标准。ISO 14229-1描述应用层的服务内容；ISO 14229-2描述会话层，对于诊断时间参数进行定义；其余部分为UDS协议在不同总线上的使用。针对于诊断在CAN上的使用，ISO发布了ISO 15765，其中ISO 15765-2在2015年增加CAN FD的网络和传输层的内容，ISO 15765-3为UDS在CAN网络上的使用。UDS诊断可以实现如下功能：模块故障码DTC读取；模块存储信息（Data ID）读取；模块内存数据的上传下载；模块安全等级切换，I/O功能激活；诊断路由控制以及刷新模块软件或软件下载等。

2.2 UDS诊断协议内容

UDS协议通过请求-响应（C-S）模式实现诊断过程。外接测试设备作为客户端对于服务器端模块提出请求Request，模块根据服务请求情况给出响应Response，见图3。一般情况下请求响应应当成对出现，即客户端提出请求时，服务器端应该给出回应，但UDS为了提高网络传输效率，还定义了一种特殊情况，即服务Service ID的子服务最高位为响应抑制位（suppressPosRspMsgIndicationBit），当其值为1时，则服务器端无需给出响应答复。

图3 UDS请求-响应模式

在CAN或者CAN FD总线上，总线的模块都可以收到客户端外接检测设备发出的诊断报文。对于目标诊断模块，UDS定义了两种寻址方式，功能寻址和物理寻址。功能寻址为服务器端设备在总线上发出寻址ID，总线上一个或者多个模块给出响应；物理寻址为服务器端设备对于某个固定的ECU ID请求诊断，固定模块给出响应。两种寻址帧的报文结构见图4。

图4 UDS服务请求、响应格式

UDS的 诊 断 报 文 请 求 格 式 为SID （+Sub function）+Parameter，SID为UDS定义的26种功能服务；Sub function为服务子功能，作为报文的可选项补充说明诊断服务的内容；Parameter为诊断参数。其中子服务的响应抑制位可以定义服务是否请求服务器端的反馈响应。

响应分为两种情况，第1种为肯定响应即服务器端接受了服务内容，标志为请求服务Service ID+0x40以及诊断反馈参数；第2种为否定响应，否定响应服务的Service ID为0x7F，标识服务器端拒绝了响应请求，并给出否定响应的原因即反馈码。

UDS协议定义的26种服务SID见表4：可以分为6个大类，分别为数据上传下载、模块内置程序函数调用、总线通信管理、输入输出信号控制、DTC处理、数据传输。

表4 ISO 14229 UDS服务Service ID

3 系统功能开发

CAN FD部分诊断系统主要由3部分组成，分别为诊断应用模块、数据处理模块、数据通信模块。使用Microsoft Visual Studio作为IDE，通过C++进行编写，支持常用的部分诊断功能。

3.1 诊断应用模块

诊断应用模块按照UDS协议应用层的定义，生成诊断报文，并解析响应服务内容，诊断应用模块逻辑见图5，系统定义结构体UDSSrvTx_SIDXX，通过请求-响应的流程实现诊断应用层的通信。

图5 诊断应用模块逻辑图

3.2 数据处理模块

数据处理模块用于生成组织数据报文，对于从诊断模块收集到的数据进行分段重组，以及对于收到的响应数据报文进行解析。发送流程逻辑见图6，本模块通过结构体CANFD_REQUEST_STRUCT定义实现。

图6 数据处理模块发送流程逻辑图

数据处理模块接收流程见图7，通过函数CANFD_DATA_CONSTRUCTION实现诊断报文的重组构建。

图7 数据处理模块接收流程逻辑图

3.3 通信模块

通信模块由两个数据存储队列组成，分别为发送队列和存储队列。工作时通过两个线程完成数据的发送和接收工作。通信模块发送接收进程逻辑见图8，发送线程为主线程，接收线程为次线程。发送线程根据发送队列中的数据帧PCI信息处理数据帧的发送工作，即单帧直接发送，多帧根据流控帧的要求分步发送。接收线程处理从总线上收到的存储队列数据帧，首先判断是否是反馈给测试设备地址的有效数据，再根据数据帧的类型，把帧信息传递给发送线程或者是数据处理模块。

图8 通信模块发送接收进程逻辑图

4 台架测试验证

4.1 测试方案

检测系统在为某款车型搭建的测试台架上进行验证，网络拓扑结构见图9，其中，有部分模块ECU支持CAN FD通信诊断。

图9 某款车型支持CAN FD的网络拓扑图

测试检测设备上位机电脑通过VCI卡与车载DLC口相互连接。DLC口定义了支持CAN总线的报文发送针脚等物理媒介，作为整车系统对外通信的媒介，所有的物理信号都会汇集到车辆的中央网关。诊断报文就经由中央网关模块路由至相应的CAN FD模块。

4.2 测试内容

测试时，通过第三方软件记录总线上的报文，验证系统的诊断功能。部分测试报文如图10所示。

图10 部分测试报文

1）诊断系统通过SID 0x22命令，读取CAN ID：94DA58F1，DID为0xF0 CD的数据。以0x03标识CAN FD单帧，封装3个字节的诊断指令，其余部分以0x55填充。

2）模块反馈时因为数据量较大，首先反馈First Frame，以0x10标识，0xED标识传递的数据总长度为237。数据起始为SID的肯定响应0x22+0x40=0x62，DID的echo 0xF0 CD以及DID部分数据信息。

3）诊断系统发送流控帧0x30 00 00，FS为0x00同意接收连续帧，并以STmin 0x00标识以默认的时间间隔接收连续帧。

4）连续帧的第1帧以0x21标识，后接部分DID数据内容。

5）连续帧第2帧以0x22标识，后接部分DID数据内容。

6）连续帧第3帧以0x23标识，后接部分DID数据内容。虽然连续第3帧中不需要占满64字节的数据量就可以传递完237字节的全部数据，但因为CAN FD数据场的大小为固定的几个可选值，所以64字节的数据场多余部分填充0x00组成完整的CAN FD数据帧。

测试验证了CAN FD系统的部分诊断功能，按照预先设计的流程，从支持CAN FD功能的模块上读取了相关诊断参数，实现了基于CAN FD的UDS诊断通信。

5 结论

CAN FD网络实现了在原有CAN物理设备基础上，进行更高速的数据通信，而CAN FD结合ISO标准的通用诊断协议UDS的使用，是汽车诊断领域重要的研究课题。本文以CAN FD网络通信以及UDS诊断协议为理论基础，比较了CAN FD为实现高速诊断的帧结构变更内容以及编码形式的更新；同时对UDS诊断实现的流程进行了阐述，并对诊断服务进行了说明。本文开发了一套在CAN FD网络中，使用UDS诊断协议进行诊断通信的系统，支持部分常用的诊断功能，使用时结合系统的其他硬件，对诊断功能进行了台架测试验证。系统也为支持CAN FD完整UDS诊断的开发提供了扩展可能，可以在工程实践中进一步完善更新。