UDS诊断是汽车软件中无论如何都绕不过去的技术主题。即便作为一名不写代码的软件管理者，也十分有必要理解这类基础的专业概念，推荐下这篇科普文。后续我们也会间断性推一些深入浅出的技术文章，供大家学习。
作者 | 窦明佳
出品 | 汽车电子与软件
#01
UDS作为汽车电子领域必备技能，而很多入行者甚至工作多年的老工程师们却难以精准掌握，可能是你学习方法有问题；
搞明白这三个问题，轻松掌握UDS；
是什么？（ISO14229-1）
怎么发？（ISO15765-2）
怎么做？（AUTOSAR Dcm, Dem）
前两问适用于所有汽车电子开发者、管理者等，本篇文章将针对前两个问题展开描述。
第三问适用于软件工程师及对软件感兴趣的朋友，将在后续文章中讲解AUTOSAR中UDS的软件实现方法。
#02
UDS (Unified Diagnostic Services) 是一种用于车辆诊断和通信的标准化协议，它是ISO 14229标准的一部分，也被称为UDS协议或UDS服务。UDS协议定义了一系列的服务和子服务，用于在诊断设备和车辆ECU（电子控制单元）之间进行通信，以执行各种诊断任务，如读取和清除故障码、配置ECU参数、请求和设置数据等。
图1，看病诊断（来源于网络）
车载诊断非常类似医生与病人的关系。
本质上讲，UDS就是服务于Client与Server之间用于信息交互的标准协议。
2.1 什么是Client与Server？
图2，车载诊断（来源于网络）
Client：外部诊断设备，如诊断仪、CANoe等
Server：车身电子件（ECU）
诊断的最基本的内容其实就是请求和响应，请求即由Client端发出的数据指令，响应为由Server端返回的数据信息；搞明白UDS，最先需要搞明白请求和响应的通用格式，即做到一通百通。
2.2 掌握通用格式，即掌握所有
所有的UDS指令都直接套用如下请求和响应格式
请求格式：
负响应：
响应（正）：50 01 00 32 01 F4（“50”为Response SID，“01 00 32 01 F4”为data-parameter）
【例子2】：
请求：22 F1 90（“22”为Request SID，“F1 90”为data-parameter）
响应（正）：62 F1 90 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10（“62”为Response SID，“F1 90 00……0E 0F 10”为data-parameter）
2.3 具体的服务该怎么看？
理解了如上通用的诊断格式后，非常简单的学习服务的方法，一般情况仅仅需要从字面意思既能了解内涵；本文以10服务为例展开描述，其余服务大家可以自行查阅ISO14229-1。
DiagnosticSessionControl (10 hex) service
10服务的字面意思就是Session控制。
UDS 10服务用于控制ECU（电子控制单元）在不同诊断会话之间的切换。在车辆诊断过程中，诊断仪与ECU之间需要建立通讯会话，以执行各种诊断任务。UDS 10服务允许诊断仪通过发送请求报文来控制这些诊断会话的建立、切换和结束。
它允许诊断仪通过发送请求报文来建立、切换和结束与ECU之间的诊断会话，从而执行各种诊断任务。UDS 10服务支持多种会话类型和控制类型，以满足不同的诊断需求。
DiagnosticSessionControl (10 hex) service请求（来源：ISO14229-1）
10服务，请求长度固定为2个字节，第一个字节为SID 10，第二个字节为子功能；
DiagnosticSessionControl (10 hex) service响应（来源：ISO14229-1）
正响应中除了DataByte#1 为Response SID和 DataByte#2 diagnosticSession外，sessionParamaterRecord的参数格式可以参考客户需求规范。
UDS 10服务支持多种会话类型，较为常用的几个子功能服务为：
默认会话（01 Default Session）：上电/远程ECU初始化后，完成初始化的ECU默认启动默认会话模式。这是基础状态，不需要任何诊断应用程序的在线服务来保持此模式激活。
扩展会话（03 Extended Session）：此状态支持在ECU存储器中进行操作，如#2E写服务、#28通信控制、#31例程等操作。
编程会话（02 Programming Session）：此会话下支持ECU内存编程操作，一般在此会话下执行bootloader操作。
2.4 DTC相关内容
DTC（Diagnostic Trouble Code，诊断故障码）是指车辆电子控制单元（ECU）存储的车辆故障代码，它是一种数字编码，用于标识车辆的故障问题。
车辆在运行过程中ECU会持续监控车辆运行状态，检测到故障时，它会记录相应的DTC，并将其存储在车辆的故障存储器中。通过读取故障存储器中的DTC，可以快速确定车辆的故障问题，并采取相应的修复措施。
2.4.1 DTC Status
DTC状态为1个字节，包含8个Bit的状态。基本上可以直接翻译从字面意思即可理解含义；详细的可以参见ISO14229-1附录。
状态位 | 名称 | 描述 |
Bit0 | testFailed | 最近的一次测试是否失败 |
Bit1 | testFailedThisOperationCycle | 当前循环，故障检测是否失败 |
Bit2 | pendingDTC | 是否有待处理的故障 |
Bit3 | confirmedDTC | 故障是否确认 |
Bit4 | testNotCompletedSinceLastClear | 清除DTC之后，是否完成过故障检测 |
Bit5 | testFailedSinceLastClear | 清除DTC之后，故障检测是否失败 |
Bit6 | testNotCompletedThisOperationCycle | 当前循环，是否完成过故障检测 |
Bit7 | warningIndicatorRequested | ECU是否请求点亮警告灯 |
2.4.2 与DTC相关的诊断服务
1. DTC状态更新控制ControlDTCSetting (85 hex) service
UDS 85服务，字面意思为控制诊断故障代码设置服务，是UDS协议中的一个重要部分，该服务用于停止或继续ECU中DTC状态位的更新。
客户端可以指示ECU停止或继续更新DTC状态位。这在某些特殊场景下非常有用，例如在ECU刷写过程中，为了避免因刷写操作导致的DTC误报，可以临时停止DTC状态位的更新。
ControlDTCSetting (85 hex) service（来源：ISO14229-1）
2. DTC信息的读取ReadDTCInformation (19 hex) service
UDS 19服务，字面意思即读取诊断故障代码信息（DTC），是UDS协议中的一个重要组成部分，用于读取诊断故障代码（DTC）相关信息。
UDS 19服务允许诊断仪/上位机从车辆内的任何ECU（电子控制单元）读取故障诊断码（DTC）信息的状态。
在ECU运行过程中如检测到故障，会记录对应的故障码，并根据故障严重及危害程度确定是否需要点亮仪表盘的发动机故障灯。
UDS 19服务包含28个子服务（Sub-Function），每个子服务都有其特定的功能，常用的几个服务如下：
01子服务：读取符合掩码条件的DTC数量。这里的掩码由客户端定义，可以指定读取当前故障、历史故障或全部故障。
02子服务：读取符合掩码条件的DTC列表及其状态。同样，掩码的定义与01子服务相同。
04子服务：读取DTC快照信息，即与DTC关联的已存储数据记录。这些数据可以帮助工程师在ECU出现故障时了解车辆的历史和实时故障信息。
06子服务：读取扩展信息，包括DTC状态、优先级、发生次数、时间戳、里程等。
0A子服务：读取ECU支持的所有DTC列表及其状态，此服务不需要掩码。
3. DTC的清除ClearDiagnosticInformation (14 hex) service
UDS 14服务的字面意思就是清除存储的故障诊断信息，这些信息可以是某一个特定的故障码（DTC），也可以是某个类别的故障诊断码（如动力总成、车身、底盘等），甚至是所有的故障诊断码。
ClearDiagnosticInformation (14 hex) service（来源：ISO14229-1）
#03
我们所常用的CAN/LIN诊断报文消息只有8个Byte长度，而上文描述的请求和响应多则几十个的Byte，本章节将阐述诊断消息如何收发；
CAN诊断由发送端的请求与接收端的响应构成，诊断即为发送端与接收端数据往来。有的诊断一条消息完成，有的诊断需要多条消息完成，毕竟在诊断中，一条CAN消息只包含8个字节长度。对于一条CAN诊断消息的分段发送问题，即为网络层需要讨论的内容。
网络层的作用可以看作是把CAN诊断通信上层需要传输的数据进行封装准备发送的过程，若数据量小于等于7个字节数据（本文只讨论正常地址模式），则用单帧发送，数据量大于7个字节数据（ISO 15765规定最大传输数据量为4095个字节），则用多帧发送。网络层的作用就好比一堆货物准备发货，货物量少，即使用一辆车托运，货物量多，则需要使用多辆车进行托运。
如下图所示，当需要传输的字节小于等于7个字节时，网络层只需将数据封装成一个单帧发送即可；
单帧数据收发（来源：ISO15765-2）
当需要传输的字节大于7个字节时，网络层需要将数据封装成一个首帧加若干个连续帧，然后再发送。
多帧数据收发（来源：ISO15765-2）
【例子1】：
CANoe Trace界面
请求10 01
响应 50 01 00 32 00 C8
请求和响应长度都在单帧范围内，则消息Trace中报文序列为：
请求 710：[02] 10 01 [00 00 00 00 00]
响应 720：[06] 50 01 00 32 00 C8 [AA]
【例子2】：
CANoe Trace界面
请求22 F1 90
响应 62 F1 90 31 32 33 34 37 38 20 20 20 20 20 20 20 20 20 20 20
请求在单帧范围内，响应长度需要使用首帧+连续帧传输，则消息Trace中报文序列为：
请求 710：[03] 22 F1 90 [00 00 00 00]
响应 720：[10 14] 62 F1 90 31 32 33
响应 720：[21] 34 37 38 20 20 20 20
响应 720：[22] 20 20 20 20 20 20 20
#04
4.1推荐的学习技巧
自己尝试编辑诊断调查问卷文件，有条件的同学可以编辑Cdd文件
使用CANoe（或其余设备）调试诊断请求和响应，观察Trace报文
按照诊断需求，软件改写简单指令，并测试验证
诊断服务列表
DID列表
DTC列表
参考文件：
[1] CAN诊断轻松入门第一讲-网络层与应用层基本知识讲解 - 知乎 (zhihu.com)
[2] CAN诊断轻松入门第二讲-UDS服务讲解 - 知乎 (zhihu.com)
[3] CAN诊断轻松入门第三讲-DTC知识讲解 - 知乎 (zhihu.com)
[4] 《UDS协议从入门到精通》系列——到底什么是DTC？_uds dtc-CSDN博客
[5] 微信公众号“汽车电子与软件”：小公司如何使用”AUTOSAR”？
[6] ISO14229-1, Unified diagnostic services (UDS) – Part 1: Application layer (Release 2015)
[7] ISO15765-2, Road vehicles – Diagnostics on Controller Area Networks (CAN) – Part2: Network layer services
/ END /
