UDS的基本概念-从入门开始

hk4835

配图实在太麻烦，为了形式统一，以后每次都用一辆豪车开局。

作为一个基本上没过多接触过软件开发的硬件工程师来讲，对于汽车的诊断，大概只是了解皮毛，但近期由于参与一些系统性的工作，需要参与到一些汽车诊断方面的内容，然后通过自学掌握了一些关于UDS（统一诊断服务）的基本知识，这篇文章基本上就是科普级别的内容，关于具体怎么去实现，我也暂时还没有去深入的学习。但是了解一点之后，至少能够知道怎么去读ECU的各种信息，怎么去读故障码这些简单的操作。

车辆诊断的目的，是为了能够快速准确的判断车辆或者某个控制器的故障以及故障原因，从而为维修提供可靠的依据。

在汽车的驾驶位方向盘的左下方，有一个OBD的口，一般都在下图红框这个位置附近，这个口是将车内主要的CAN总线都引过来，然后通过诊断仪读取各个ECU的故障码，根据故障码对应的故障，就能很快的定位到问题了，当然这只是UDS的一项作用而已。我们还可以通过UDS在下线检测时把一些信息（如VIN码）写入到汽车的各个零部件中。这些功能也是UDS最为核心的功能。



首先附上一个CAN数据帧的结构图，前面11位的仲裁域，也就是规定CAN数据的ID，同时称为仲裁域的原因也是由于数字小的ID优先级更高。



作为UDS的诊断ID报文，每个控制器都有2个CAN的诊断帧ID，分别对应物理寻址的收与发，通常都是由主机厂的总线系统工程师进行分配。中间8个字节的数据域，服务ID（SID）和与服务相关的参数包含在CAN数据帧的8个数据字节中，这些数据帧是从诊断工具发出的。这是我们来做UDS诊断服务介绍的基本前提，UDS的各种服务，就是通过数据域内不同的内容来实现的。

一、诊断的基本概念


车辆的诊断需要有Tester端和ECU端，Tester端和ECU端通过一问一答的形式进行通信，因而Tester端和ECU端都需要遵循同样的诊断通信协议，在乘用车领域，我们统一遵循的就是UDS协议的ISO 14229这个标准，在协议里面定义了诊断的请求，诊断响应的报文格式，以及ECU怎样处理诊断请求报文，以及诊断服务的应用。市面上很容易能够买到通用诊断仪，能够清楚故障码，读取车辆的信息等状态。淘宝出品，必属精品。

通俗一点讲，就是我如果要读故障码，我需要按照固定的规则发一个报文给到ECU端，ECU收到这个报文，就会按照一定的规则回复一个报文给我，而这个报文里面就包含我需要的故障码信息。



下面张图就描述了UDS在OSI七层模型中的应用，OSI七层模型，第一层第二层分别定义了物理层和数据链路层，第三层第四层定义了网络层和传输层，第七层是应用层。



CAN总线的物理层和数据链路层遵循的是ISO 11898，网络层和传输层遵循的是ISO15765-2，在ISO14229-3中定义了UDS基于CAN总线的应用，而我们针对UDS的服务，都是在这个标准里面体现的。单独来说这个7层结构估计是有点难理解的，待会后面讲几个例子，就知道这个层级跟实际的物理数据之间的对应关系了。

二、网络层的作用

网络层与应用层都会在诊断报文的数据域里面来体现。

网络层协议数据单元（N_PDU）有四种类型，即单帧（SF）、首帧（FF）、连续帧（CF）、流控制帧（FC），用于建立对等实体间的通信。对于这四种类型的数据单元是通过协议控制信息（N_PCI，ProtocolControl Information）进行区分的。

也就是网络层是规定UDS格式的控制信息，它规定了UDS的收发是按照什么样的格式来进行通讯。

简单举个例子：



上面这一问一答，CAN帧一共8个字节，第一字节被网络层占用，也就是02。上面的02 10 0100 00 00 00 00是Tester的10服务，其中第一个字节02的意思就是单帧，属于控制信息，表示有效的字节数是2，即表示02后面只有10 01这2个字节有效，并且10是SID（服务ID），01是子服务，后面的00无实际意义，也可以用其他字节来填充。

下面的06 50 01 00 32 00 C8 AA是ECU的肯定响应，也叫正响应。其中06也是网络层定义，表示单帧，6个字节有效，50表示正响应（正响应是SID+0x40，所以是50），01是子功能。

1、单帧（SF）

0X 单帧（SF）：首个字节为0（4bit）+ DataLength(4bit)，控制信息占用1个字节。

举例：Data 02 10 02 55 55 55 55 55，02表示接收方应知晓，这一个单帧只有2个有效字节。后续的字节是自动填充的无效字节。



单帧PCI通常仅占用1个字节，其他是数据，所以可以后面可以跟着最多7个字节的数据。

2、首帧（FF）

1X XX 首帧（FF）：前两个字节为1（4bit）+ DataLength(12bit)，控制信息共占用2个字节。

举例：Data 10 14 2E F1 90 01 02 03，0x014表示，接收方应知晓，这一个多帧组合共有20个字节。



3、流控制帧（FC）

3X 流控制帧（简称流控帧，FC）：前三个字节为3（4bit）+流状态（FS，4bit）+块大小（BS，8bit）+最小间隔时间（STmin，8bit），控制信息共占用三个字节。

举例：Data 30 00 14 AAAA AA AA AA，多帧发送方应知晓，这是一个流控帧，允许你方继续发送，CF数量无限制，上一个连续帧的确认接收（ACK）到新的连续帧开始发出的最小间隔时间为20ms。

Flow State 流状态：0为继续发送，Continue To Send（CTS），1为Wait（WT），2为Overflow（OVFLW）。



流控帧仅有3个字节的控制信息，无数据字节。



STmin含义的解读

间隔最短时长（STmin）值的含义如下。

16进制值	说明
00 – 7F	STmin间隔时间：0ms-127ms
80 – F0	保留
F1 – F9	STmin间隔时间：100us-900us
FA – FF	保留

4、连续帧（CF）

2X 连续帧（CF）：第一个字节为2+SN（最多16个SN，溢出后从0开始重新计数），控制信息占用1个字节。

我们通常记首帧为0x20，之后的第一个连续帧自然是0x21，之后一直到0x2F，下一个是0x20，循环。



看完网络层我们再来看看这个UDS服务的备忘录，是否能够简单的知道这些格式的含义？



三、UDS诊断服务的肯定响应和否定响应

在介绍诊断服务之前，首先把一些常用的缩写通过名词定义的方式先列出来，这是后面需要经常用到的一些缩写词，这样的话作为菜鸟的我觉得可能更好理解一点。

SID：ServiceIdentifier诊断服务ID

PositiveResponse：肯定的响应

NegativeResponse：否定的响应

NRC：NegativeResponse Code（否定响应码）

DID：DataIdentifier数据标识符

DTC：diagnostictrouble code诊断故障码

testFailed：当前故障

confirmedDTC：历史故障

UDS本质上是一系列服务的集合。UDS的服务包含6大类，共26种。每种服务都有自己独立的ID，服务的ID，就称为SID。例如SID等于10，我们就称这个服务为10服务，同理还有11服务，19服务，22服务等等一共26个。



SID：ServiceIdentifier，诊断服务ID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方(Tester)给ECU发送指定的请求数据（Request），这条数据中需要包含SID，且SID处于该应用层数据的第一个字节。

如果是肯定的响应（Positive Response），首字节回复[SID+0x40]，举例子就是请求0x10，响应0x50；请求0x22，响应0x62。

如果是否定的响应（NegativeResponse），首字节回复0x7F，第二字节回复刚才询问的SID。比如Tester请求0x10服务，我想进入编程模式，ECU给出否定响应，首字节0x7F，第二字节回复0x10，代表我否定你的0x10服务请求，第三字节是NRC(否定响应码)，代表我否定你的依据。


这是一个读DID的例子，能看懂了吗？

babylemon828

UDS（统一诊断服务）是汽车诊断领域中的重要标准，为车辆诊断提供了标准化的通信方式。对于汽车硬件工程师而言，掌握UDS有助于理解车辆的诊断流程和读取故障码等操作。配图以豪车开始，确实能吸引读者兴趣。关于UDS的基本概念，它主要涉及到诊断会话管理、安全访问控制等核心要素。掌握这些基础后，可进一步学习如何通过UDS读取ECU信息、诊断故障等实际操作。汽车诊断的最终目的是快速准确地判断车辆或控制器的故障及原因，为维修提供可靠依据，确保车辆运行安全。日后我会更深入探讨UDS实现的具体方法，以及汽车诊断中的其他要点。

mqh0386

UDS（统一诊断服务）是汽车诊断领域的重要标准，它为车辆诊断提供了规范化、标准化的方法。作为汽车工程师，掌握UDS是必备技能之一。从入门开始，UDS的基本概念包括诊断会话管理、服务标识、传输协议等。通过UDS，我们可以与车辆的ECU进行通信，读取车辆状态信息、故障码等，进而实现对车辆或控制器的故障诊断。掌握UDS不仅能帮助我们快速准确地判断故障及原因，还能为维修提供可靠依据，确保车辆的安全与性能。以后深入学习UDS实现细节，将更好地服务于汽车诊断工作。配图方面确实较为复杂，为了直观理解，可以用豪车开局作为背景，突出主题。