如何看懂UDS诊断报文

Posted 2023-05-15

参考技术A

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

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

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

UDS的26种服务中，有7种很重要。它们分别是：

下面对这7个服务进行解读。

$10包含3个子功能，

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

报文包含4种类型 ，即

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

八个数据字节，第一字节被网络层占用 。

02中的0代表网络层单帧SF，2代表 数据域有2个字节； 10是SID，02是子功能 。

02同上，10+40表示对SID的肯定回复，02是子功能。

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

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

例子：

27服务，加上一个子服务，再加上一个钥匙，这样的服务请求可以进行解锁。

比如下面的例子，2n-1是某个子服务，通过首轮种子的请求，首轮ECU会返回67+01+AA+BB+CC+DD，AA~DD就是种子了。之后第二轮，诊断端会利用种子进行运算（利用整车厂的算法），生成k1（不一定是1个字节），那么发送请求，27+02+[k1]。ECU同样也会通过种子算出k2。当k1和k2匹配时，解锁（Unlocked）成功。

$22读数据，
Request（请求）：

Response（响应）：

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

$22写数据，
Request（请求）：

Response（响应）：

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

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

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

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

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

UDS 的诊断数据的发送与接收都是基于CAN，所以每个数据流都包含基本的CAN Message 的架构

根据上篇UDS文章的叙述，每一个PDU 包含控制信息PCI,数据信息Data.

网络层 PDU（协议数据单元）PCI（协议控制信息）格式：具体如下图所示：

综上所述， N_PDU =N_PCI+N_DATA , N_PCI 的值主要集中的 前三个字节 ， N_DATA 值主要集中在 后面7位字节 。其中，

先面用连个例子进行说明，请参考！

[图片上传失败...(image-b66bab-1538824826939)]

由于这个数据发送与接收都是单帧传输，所以第一个数据的高四位均为0，四个数据流中的第一个字节的低四位，02，03，02，06代表的为此帧数据含有几个字节，多余的数据位都用 00或者AA行填充。

[图片上传失败...(image-b5e84b-1538824826939)]

数据发送为单帧，所以06代表发送的数据中含有6个字节，

回复为Positive Response，为连续帧。

参考资料：

UDS协议发展历史

诊断协议那些事儿

本文为诊断协议那些事儿专栏首篇文章，旨在介绍诊断的起源、发展历史，让读者对诊断有一个基本的认识。

---

文章目录

• 诊断协议那些事儿
• 一、诊断的起源
• 二、UDS是什么？
• • 1.诊断D（诊断通信协议）
  • • 1.1 为什么汽车需要诊断？
    • 1.2 诊断的基本原理
    • 1.3 诊断的应用领域
    • 1.4 诊断实现模型
  • 2.服务S（诊断服务）
  • • ①ISO15031
    • ②ISO14230
    • ③ISO14229
  • 3.统一U（可以基于任意总线）
• 总结

---

一、诊断的起源

诊断的概念来源于医学，当病人出现头晕、发烧、呕吐、骨折等不适症状时，去医院就诊，医生通过询问、观察，或者仪器（CT、血检等）检测，利用数据对病症做出判断，并给出合理建议的过程。
车辆诊断的过程也有类似的地方，外部诊断设备，通过通信媒介（CAN、LIN、以太网等）连接车辆，获取车辆状态信息，为了能够快速准确的判断车辆或者某个控制器的故障以及故障原因，从而在不拆解整车的情况下为维修提供可靠的依据。

二、UDS是什么？

Unified Diagnostic Services：统一 诊断 服务，形象理解-就是通过一套标准的服务，对当前汽车进行数据操作。

1.诊断D（诊断通信协议）

1.1 为什么汽车需要诊断？

随着电子技术与汽车技术相结合，电子技术的不断发展，驾驶员对于车辆不再仅仅满足于代步功能的需求，迫切要求提高车辆的动力性、舒适性、经济性和安全性。因此ECU数量不断增加，由最初的几个到现在上百个。数量的不断增加虽满足了驾驶员的新需求，但给车辆售后维修带来了极大的挑战，难以判定故障类型的问题。从20世纪80年代起，美欧等地汽车制造商开始在电喷系统上装备车载自诊断模块（On-Board Diagnostics Module），便于快速界定车身发生故障部位，方便售后维修（现代车载诊断功能不仅仅局限于此）。

①汽车网络复杂性的增加
②汽车ECU的增加
③控制策略复杂性的增加
④诊断策略的增加
⑤法规和标准
⑥排放标准
⑦质量控制
⑧召回风险管控

1.2 诊断的基本原理

自诊断模块能在汽车运行过程中实时监测电控系统及其电路元件的工作状况，如有异常，根据特定的算法判断出具体的故障，并以诊断故障代码(DTC，Diagnostic Trouble Codes)的形式存储在汽车电脑芯片内。可以为车辆的维修和保养提供帮助，维修人员可以利用汽车原厂专用仪器读取故障码，从而可以对故障进行快速定位，故障排除后，采用专用仪器清除故障码。
OBD的工作原理（参考）：汽车在正常运行时，汽车的电子控制系统输入和输出的信号（电压或电流）会在一定的范围内有一定规律地变化；当电子控制系统电路的信号出现异常且超出了正常的变化范围，并且这一异常现象在一定时间（几 个连续行程）内不会消失，ECU 则判断为这一部分出现故障，故障显示灯点亮，同时监测器把这一故障以代码的形式存入存储设备中，被存储的故障代码在检修时可以通过故障显示灯或 OBDⅡ诊断仪来读取。如果故障不再存在，监控器在连续 3 次未接收到相关信号后，将指令故障显示灯熄灭。故障显示灯熄灭后，发动机暖机循环约 40 次，则故障代码会自动从存储器中被清除掉。

1.3 诊断的应用领域

广泛应用于开发、生产、售后等各个领域。

结合ISO14229诊断服务看，车辆诊断的作用涉及故障检测（DTC）、程序升级、EOL下线检测（车型配置、IO控制）、读取软硬件版本号/VIN等。

1.4 诊断实现模型

车辆的诊断需要有Tester端和ECU端，Tester端和ECU端通过一问一答的形式进行通信，因而Tester端和ECU端都需要遵循同样的通信协议。常用的诊断协议有ISO 14230，ISO 15031，ISO 15765，还有我们熟悉的ISO 14229就是UDS协议，在协议里面定义了各个服务的请求、响应的报文格式，以及ECU怎样处理诊断请求报文。

2.服务S（诊断服务）

诊断通信机制：基于C/S架构的请求/响应机制
Client客户端：诊断请求的提出者——Tester（诊断仪）
Sever服务器：诊断响应的提供者——ECU（电子控制单元）

各个协议规定了不同的服务，不同的诊断服务代表着不同的功能，具体如下：

①ISO15031

服务	描述
01	Request current powertrain diagnostic data 请求当前动力总成诊断数据
02	Request current powertrain diagnostic data 请求当前动力总成诊断数据
03	Request emission-related diagnostic trouble codes 请求与排放相关的诊断故障代码
04	Clear/Reset emission-related diagnostic information 清除/重置排放相关诊断信息
05	Request oxygen sensor monitoring test results 请求氧气传感器监测测试结果
06	Request on-board monitoring test results for specific monitored systems 请求特定监控系统的车载监控测试结果
07	Request emission-related diagnostic trouble codes detected during current or last completed driving cycle 请求在当前或上次完成的驾驶循环中检测到的与排放相关的诊断故障代码
08	Request control of on-board system, test, or component 请求控制车载系统、测试或组件
09	Request vehicle information 请求车辆信息
0A	Request emission-related diagnostic trouble codes with permanent status 请求具有永久状态的与排放相关的诊断故障代码

②ISO14230

③ISO14229

详情请查阅：UDS诊断服务列表

3.统一U（可以基于任意总线）

①OBD：On-Board Diagnostics
第一代OBD（OBD-I）
i.加州环保局（CARB）1985年立法，1988年开始实施
ii.要求对硬件失效（包括氧传感器、废气在循环阀、供油系统和发动机系统）实施监控
iii.没有统一的故障码和通讯协议标准
第二代OBD（OBD-II）
建立了标准化故障码和通讯协议标准

②ISO 14230：Keyword Protocol 2000（KWP2000）
该协议实现了一套完整的车载诊断服务，并且满足 E-OBD（European On Board Diagnose）标准。最初使用K-Line串行传输，最大通信速率10.4Kbps。由于 K 线物理层和数据链路层在网络管理和通讯速率上的局限性，使得 K 线无法满足日趋复杂的车载诊断网络的需求。而 CAN网络（Controller Area Network）由于其非破坏性的网络仲裁机制、较高的通讯速率（可达 1M bps）和灵活可靠的通讯方式被广泛使用，发展为基于CAN总线的KWP2000（ISO 15765）。

③ISO 15765 Diagnostic On CAN
基于CAN总线传输，最大速率达1Mbps

④ISO 15031 On-Board Diagnostic（OBD）
与排放相关的诊断通信，是由法规要求，具有强制标准需要参照的，最初目的是环保（同时方便售后维修）。

⑤ISO 14229-1：Unified Diagnostic Services
定义了诊断服务，只是一个应用层协议，不涉及网络，可以基于任意总线。
与OBD最大的区别就在Unified（统一）上，它是面向整车所有ECU的，而OBD是面向排放系统ECU的。

因为全球有许多OEM，假如每家OEM都定义自己的诊断通信标准，则会造成社会资源不必要浪费（Supplier要根据不同OEM搭建功能实现平台）。因此定义统一的诊断协议，让大家都遵守，避免浪费社会资源，这也是ISO组织定义车载诊断行业标准的目的（ISO 14229、ISO 15765、ISO 14230、ISO 15031等）。在协议中定义诊断通信的准则：诊断请求、诊断响应的规则； 诊断服务类型；ECU处理诊断请求的规则、诊断请求和诊断响应的内容；诊断通信的参数，数据传输的准则等等。

---

总结

以上就是今天要讲的内容，本文仅仅简单介绍了UDS的起源和发展，还有许多值得去挖掘和研究的内容，后续小编会不断介绍ISO协议，以此来加深对诊断的理解。