UDS诊断的几篇高质量博客推荐

UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是ISO 15765 和ISO 14229 定义的一种汽车通用诊断协议，位于OSI模型中的应用层，它可在不同的汽车总线（例如CAN, LIN, Flexray, Internet 和K-line）上实现。UDS协议的应用层定义是ISO 14229-1，目前大部分汽车厂商均采用UDS on CAN的诊断协议。

如下图所示，ISO 14229-1也就是UDS协议仅对应用层做出了定义，物理层有双绞线和光纤供用户选择，数据链路层采用CAN总线的ISO 11898-1协议，针对Classical CAN仅有8个字节的数据场与应用层可处理多帧数据的矛盾，ISO 15765-2对网络层进行了定义。CAN的8字节数据场会腾出一帧来表示网络层的信息。下图右侧是排放相关的协议，ISO 15031-5主要针对OBD协议，为法规强制要求车厂满足的协议。学习时，我们应在了解CAN总线基本知识的前提下，着重学习ISO 15765-2和ISO 11898-1的协议内容，并通过BootLoader作为例子，对UDS有一个大致的了解。

UDS本质上是一系列的服务，共包含6大类26种。每种服务都有自己独立的ID，即SID。

SID：Service Identifier，诊断服务ID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方给ECU发送指定的请求数据（Request），这条数据中需要包含SID。如果是肯定的响应（Positive Response），回复[SID+0x40]，就是请求10，响应50；请求22，响应62，回复的是一组数据。如果是否定的响应（Negative Response），回复7F+SID+NRC，回复的是一个声明。

肯定响应和否定响应的形式一定要熟记。

UDS的26种服务中，有7种很重要。它们分别是：$10 Diagnostic Session Control（诊断会话），$14 Clear Diagnostic Information（清除诊断信息），$19 Read DTC Information，$22 Read Data By Identifier（通过ID读数据），$27 Security Access（安全访问），$2EWrite Data By Identifier（通过ID写数据），$3E Tester Present（待机握手）。下面对这7个服务进行解读。

$10诊断会话

$10包含3个子功能，01 Default，02 Programming，03 Extended，ECU上电时，进入的是默认会话（Default）。如果您进入了一个非默认会话的状态，一个定时器会运转，如果一段时间内没有请求，那么到时间后，诊断退回到默认会话01。当然，我们有一个$3E的服务，可以使诊断保持在非默认的状态。

UDS包含4种类型，即SID，SID+SF（Sub-function），SID+DID（Data Identifier）（读写用），SID+SF+DID。

NRC：Negative Response Code（否定响应码）。如果ECU拒绝了一个请求，它会回应一个NRC。不同的NRC有不同的含义。

14229-1协议第329页

单词：Consult（查阅） Session（会话） DTC （diagnostic trouble code）故障码Handling（处理） Conditions（条件） restricted（受限的） Concept（概念）SA（source address 源地址） TA（目标地址）

例子：以CAN总线网络举例。八个帧数据字节，第一字节被网络层占用。

请求（Request）:02 10 02 xx xx xx xx xx ; 02是网络层单帧SF，数据域有2个字节，10是SID，02是子功能。

肯定响应:02 50 02 xx xx xx xx xx；02同上，10+40表示对SID的肯定回复，02是子功能。

否定响应:03 7F 10 22 xx xx xx xx；03同上，7F表示否定响应，10是SID，22是NRC。

$3E待机握手

$3E服务用于向服务器指示诊断仪仍然连接在网络上，之前已经激活的诊断服务功能可以仍然保持激活状态。

例子：02 3E 80 00 00 00 00 00，发送一个3E服务的报文，保持非默认会话状态。80表示无需回复。

$27安全访问

$27安全访问：ECU当中有很多数据是整车厂独有的，并不希望开放给所有客户，它需要做一个保密的设定。我们在读取一些特殊数据的时候，要先进行一个安全解锁。ECU上电之后是一个锁定的状态（Locked），我们通过$27服务，加上一个子服务，再加上一个钥匙，这样的服务请求可以进行解锁。比如下面的例子，2n-1是一个子服务，通过首轮种子的请求，首轮ECU会返回67+01+AA+BB+CC+DD，AA~DD就是种子了。之后第二轮，诊断端会利用种子进行运算（利用整车厂的算法），生成k1（不一定是1个字节），那么发送请求，27+02+[k1]。ECU同样也会通过种子算出k2。当k1和k2匹配时，解锁（Unlocked）成功。

$27安全访问服务的否定响应服务ID也是7F。还记得刚才否定响应的格式吗？7F+27+NRC（否定响应码）。

例子：

Rx： 02 27 05 00 00 00 00 00 安全访问，05子功能

Tx： 07 67 05 08 27 11 F0 77 肯定响应，回复了对应安全级别的种子

Rx： 06 27 06 FF FF FF FF 00 发送密钥，4个FF。注意06是与05成对使用的。

Tx： 03 7F 27 78 00 00 00 00 否定响应，7F+27+NRC

Tx： 02 67 06 00 00 00 00 00 肯定响应，通过安全校验

$22读数据

$22读数据，Request（请求）：22+DID（Data Identifier，通常是两个字节）

Response（响应）：62+DID+Data

DID有一部分已经被ISO 14229-1规定了。比如0xF186就是当前诊断会话数据标识符，0xF187就是车厂备件号数据标识符，0xF188就是车厂ECU软件号码数据ID，0xF189就是车厂ECU软件版本号数据标识符。

14229-1协议第339页

$2E写数据

$22写数据，Request（请求）：2E+DID+Data

Response（响应）：6E+DID

注意，比如0xF186这个DID不支持直接写入数据，需要用$10来进行会话转换。也就是说，对于写数据的请求，一般来说需要在一个非默认会话，和解锁的状态下才能进行。

$19 读DTC

DTC（diagnostic trouble code）：如果系统检测到了一个错误，它将存储为DTC。DTC可表现为：一个显而易见的故障；通讯信号的丢失（不会使故障灯亮起）；排放相关的故障；安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常DTC占用3个字节，OBD II占用两个字节。图中FTB为Fault Type Byte。

故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态。前两个字节是我们熟知的类似P0047的故障码。LowByte暂不清楚。

$19拥有28个子服务（Sub-Function）。常用的子服务有02（通过DTC状态掩码读取DTC），04（读取快照信息），06（读取扩展信息），0A（读ECU支持的所有DTC数据）。

刚才提到，一个DTC除了它自己的3个字节，还有一个字节专门用于表达DTC的状态。这个状态字节每个位的含义可以查询ISO 14229-1。注意，并不是所有的DTC状态都是支持的。下图是Request/Response。括号标识循环，可以读出很多DTC。

$14清除DTC

清除（复位）DTC格式，它可以改变DTC的状态。3个FF代表清除所有DTC。

Request：14+FF+FF+FF；

Response：54 。

 

我们刚才学完了7种重要的服务，SID。除此之外，在CAN总线中，Addressing information寻址信息通过CAN帧ID体现出来。

通讯的模式分两种，一种是物理寻址（点对点），根据物理地址的不同进行访问，但只能访问单个ECU节点，Test为SA源地址，ECUX作为TA目标地址；对应的，另一种是功能寻址（广播），根据功能的不同进行访问，它能访问多个ECU节点。

每一个ECU都有2个CAN帧ID，分别对应收和发的物理寻址。

以上只是一些粗浅的理解。对26种服务更详细的解读请拉到屏幕下方参考张老师的8篇文章。张老师也开通了微信公众号，可以了解一下。

UDS应用的设备

在UDS 诊断产品中知名度最高，应用最广泛的是德国Vector公司的CAN case 配合其CANoe 软件，Vector 产品功能齐全，适合系统级汽车总线开发，被大部分汽车厂商采用。Vector 产品因不开放API，不能做二次开发且价格昂贵，不适用于硬件开发团队和生产线的自动化测试。目前市面上有很多CAN 厂商（如Kvaser, ZLG 等）能提供低成本、体积小、驱动简单、开放API 的设备，很适合进行二次开发。

杂记

变速器控制单元TCU和防抱死系统ABS是CAN车载网络上的两大电子控制单元， 这2个ECU要通过CAN网络进行大量的信息交互。但是由于电磁干扰、串扰、静电等外界干扰或电控单元本身控制策略引起的通信停止等原因， 2个控制单元之间可能会出现通信丢失的现象。控制系统需要将故障信息（例如通信丢失故障信息） 诊断出来， 以处理通信被破坏时出现丢失帧的故障现象， 并记录为DTC （diagnostic trouble code）。

ECU的输入信号主要有4种形式： ①模拟信号（水温、油压、蓄电池电压等）； ②数字信号（各种开关信号等）； ③PWM信号（脉冲信号、频率信号等）； ④网络信号（CAN、LIN上传输的信号）。微控制器可以通过监测这些信号来判别输入电路的工作状况。输出的信号往往用作控制电磁阀、指示灯、步进电机等， 大多数为数字信号。

https://blog.csdn.net/u012252959/article/details/83063899