基于CAN的UDS诊断服务功能解析与测试项之车载控制器
一、UDS功能的作用->下线检测。写入相应的数据以及读取整车是否存在故障情况。读取ECU的信息（零件号，软件版本，硬件版本等），然后将该信息与生产系统中该车应该安装的ECU的信息做比较，及时发现零件错装的问题，以及车辆下线的传感器自学习与标定等。
->故障记忆与存储。能够存储记忆汽车故障，能够实时提供汽车各种运行参数。
->故障维修。外部诊断设备通过一定的诊断通信规则与ECU建立诊断通信，并读取这些故障和参数，同时解析出来供外部测试人员分析。
->程序更新。依据ISO14229的UDS协议，定义的控制器软件升级流程。
二、UDS功能概述
UDS本质上是一种定向的通信，是一种交互协议（Request/Response），采用的是Client/Server的模式，基本是Client发送一个请求报文，Server根据请求报文做出回应；Client一般情况下是指测试仪（Tester），Server一般是指电控单元（ECU）。UDS协议栈中，协议分为常规的七层，其中主机厂最为关注的也是第七层应用层。根据协议的类型，采用何种通讯协议都会有对应的诊断服务类型，UDS协议可以是UDSonCAN、UDSonLIN、UDSonIP等。
http://www.51testing.com/attachments/2023/06/15326880_202306091352181EpTL.jpg
三、UDS功能服务
ISO14229-1协议中定义了6类功能，26种服务，UDS功能服务主要依托于UDS报文的信息不同，UDS报文的格式为：SID+SF+DID的通用格式，可以衍生出SID、SID+SF、SID+DID的报文格式。
服务中SID的定义规则及规范如下表所示。
http://www.51testing.com/attachments/2023/06/15326880_202306091352211cmsl.jpg
正响应：SID+40；
负响应：7F+SID+NRC；
->SID：0x10、0x11、0x27、0x28、0x3E、0x83、0x84、0x85、0x86、、、、、、
http://www.51testing.com/attachments/2023/06/15326880_202306091352271OSmv.jpg
->SF：主要应用在传输的数据比较大的服务中，例如更新程序，数据的下载。
网络层分为单帧和多帧，单帧(SF)就是一帧can报文8字节内就可以把数据处理完毕。多帧就是一帧can报文8字节内无法发送完毕,需分为首帧(FF)，流控帧(FC)，连续帧(CF)来进行处理。多帧信息传输。SF_DL单帧的字节数，FF_DL多帧的字节数。SN表示连续帧的序号，第一帧为1，第二帧为2，第三帧为3等。FS表示的是流控状态参数。例如0表示的是继续发送，1表示的是等待，2表示溢出。BS表示的是块的大小，即发送端一次性能够发送多少个连续帧，00的代表持续发送到完毕。-Stmin发送两个连续帧需要等待的最短时间。
http://www.51testing.com/attachments/2023/06/15326880_202306091352331M72x.jpg
应用举例：
Tester请求：22 F1 90 （单帧传输）
ECU响应：62 F1 90 31 30 35 30 30 30 30 31 32 33 34 35 36 37 38 39 39（多帧传输），其多帧传输的具体过程为：
ECU响应首帧(FF): 10 14 62 F1 90 31 30 35（10代表首帧，14代表传输的字节总数，62代表22的正响应）
Tester收到首帧，发送流控帧（FC）： 30 00 64（30代表流控帧，00代表连续发送到完毕，64代表100ms周期发送）
ECU收到流控帧，发送第一条续帧（CF）：21 30 30 30 30 31 32 33（21中的2代表连续帧，1代表连续帧的第一帧）
ECU间隔10ms（即0x0A）后，发送第2条续帧（CF）： 22 34 35 36 37 38 39 39（22中的2代表连续帧，2代表连续帧的第二帧）
->DID：例如常见的F185、F190等ISO标准定义的DID，以及用户自己定义的DID。
->NRC：在ISO 14229 中，负响应代码范围可以划分为3个范围：0x00：正响应参数值；
0x01 ~ ->0x7F：与通信相关的否定响应代码；0x80 ~ 0xFF：针对特定条件的否定响应代码。每一个服务对应的NRC都会根据具体的功能不同。例如22服务支持的NRC包括0x13、0x14、0x22、0x31、0x33等。所有的NRC参考ISO 14229-1 的第325页。
http://www.51testing.com/attachments/2023/06/15326880_202306091352361mt5k.jpg
举例：22 F1 90
负响应，2F F1 90 13（出现错误的原因是NRC为0x13的描述导致的）
诊断和通信管理功能单元（Diagnostic and Communication Management）
$10 - 诊断会话控制（Diagnostic Session Control）
服务请求ECU在各种会话模式中跳转。包含三个子功能：01-Default、02-Programming、03-Extended。
$11 - 电控单元复位（ECU Reset）
该服务请求ECU执行复位。ECUReset请求参数的示例包括：HardReset、KeyOffOnReset、SoftReset。
$27 - 安全访问（Security Access）
此服务用于在对某些特殊数据读取和写入功能上加入一层保护功能。通过SecurityAccess请求来解锁并访问受保护的功能及数据。
$28 - 通讯控制（Communication Control）
该服务请求ECU控制其通信行为。CAN总线中的ECU关闭和开启通信，以提高通信的速率。
$3E - 待机握手（Tester Present）
Tester Present请求定期发送的一帧报文，它反映测试仪一直处于连接状态。
$85 - 诊断故障码设置控制（Control DTC Setting）
该服务要求ECU停止/恢复DTC的设置。关闭和开启诊断功能，例如可以在程序更新过程中，防止程序更新过程中会报通讯丢失故障等。
数据传输功能单元（Data Transmission）
$22 - 通过ID读数据（Read Data By ldentifier）
该服务请求读取由DID参数标识的数据记录值。
$2E - 通过ID写数据（Write Data By ldentifier）
通过此服务，可以将由标识符（DID）指定的数据记录写入ECU存储器。
存储数据传输功能单元（Stored Data Transmission）
$14 - 清除诊断信息（Clear Diagnostic Information）
清除（复位）DTC格式，它可以改变DTC的状态。
$19 - 读取故障码信息（Read DTC Information）
诊断故障代码（DTC）用于编码和识别检测到的与动力系统有关和无关的故障。
输入输出控制功能单元（Input & Output Control）
$2F - 通过标识符控制输入输出（Input Output Control By Identifier）
该服务主要用于模拟输入的值和控制ECU的输出。通常，此服务会跳过ECU的应用程序软件直接读取传感器的数据或者直接输出控制负载的信号。
例行程序功能单元（Remote Activation of Routine）
$31 - 例行程序控制（Routine Control）
该服务用于维护和停止ECU内部例行程序。可以读取例程的结果以进行分析。该例行程序由两个字节的例行程序identifier标识。
上传下载功能单元（Upload & Download）
$34 - 请求下载（Request Download）
此服务启动从测试仪到ECU的数据传输。当ECU准备从测试仪接收数据时，它会发送肯定响应，其中包含用于后续数据传输的可用块大小（每个传输数据请求的数据字节数）
$35 - 请求上传（Request Upload）
此服务启动从ECU到测试仪的数据传输。当ECU准备好将数据发送到测试仪时，它会发送一个肯定的响应，其中包含用于后续数据传输的块大小（每个传输数据请求的数据字节数）
$36 - 数据传输（Transfer Data）
此服务用于在测试仪和ECU之间（下载）或在ECU和测试仪之间（向上）传输数据。
$37 - 请求退出传输（Request Transfer Exit）
该服务用于终止transfer Data服务。
四、DTC故障码
http://www.51testing.com/attachments/2023/06/15326880_202306091352401Wlil.jpg
诊断故障码（Diagnostic Trouble Code，DTC），是故障类型的具体描述，标准中对应的故障码所代表的意思全部进行了列举，用于汽车故障时对故障部位及原因的排查。一般情况下，主机厂会针对其中的含义或者信息进行修改，一个DTC信息占用3-4个字节，其中前2-3个字节如下，最有一个字节为DTC的状态字节：
http://www.51testing.com/attachments/2023/06/15326880_202306091352431lYR3.jpg
每个DTC均由DTC内容和DTC状态表示：
DTC内容
描述该故障的具体故障信息。其中，DTCHighByte、DTCMiddleByte这两个字节表示故障码，DTCLowByte的内容是描述故障种类和子类型，该部分内容在ISO 15031-6中122页有具体描述，是否加入该字节的信息具体看项目是否有需要。
故障码具体描述如下：
1、DTCHighByte（bit6-7）
http://www.51testing.com/attachments/2023/06/15326880_202306091352461jxXG.jpg
2、DTCHighByte（bit4-5）
00代表ISO标准定义的故障码，01代表制造商自己定义的故障码
3、DTCHighByte（bit0-3），表示故障所属的子系统，主机厂或者Tier1自己定义的内容。
4、DTCMiddleByte（bit0-7），表示具体故障对象和类型，主机厂或者Tier1自己定义的内容。
DTC状态
则表示当前的故障处于什么状态，它由8位组成，每个位代表了不同的DTC状态信息。
http://www.51testing.com/attachments/2023/06/15326880_202306091352491jWzW.jpg
举例：
Bit0：testFailed；当pendingDTC或confirmedDTC被置1时，DTC才会存储testFailed被置1的位。
Bit3：confirmedDTC；当confirmedDTC=1时，testFailed=1时，则说明这个DTC表示的故障过去存储的故障，现在已经不存在该故障了。当confirmedDTC=1时，testFailed=0时，则说明这个DTC表示的故障现在发送的故障。
五、UDS功能的测试方法
UDS协议栈测试包括诊断服务类测试项目和故障码测试类测试项目，一般故障码需要在台架上设置相应的输入条件进行联合测试，诊断服务类测试通过CANOE工具测试。
->通过系统输出的诊断规范文件，在CANdelaStudio环境中编辑CDD诊断数据库文件，导入到CANOE工具中，进行手动测试；
->通过CANdiva工具生成自动化测试工程进行测试；
->通过CAPL语言编写测试程序进行自动化测试。
六、UDS功能的测试
·诊断报文的格式测试
· 诊断报文长度测试
· 诊断报文响应时间测试
· 诊断报文负响应测试
· 诊断报文正响应测试
· 会话模式测试
· 安全模式测试
· 多帧信息发送测试
· ECU硬件复位
· 清除故障信息
· 读取故障信息
· 信息与数据的读取
· 信息与数据的写入
· 通信控制
页:
[1]
