【UDS诊断服务入门】

最新推荐文章于 2025-03-16 16:35:30 发布

.桃花依旧笑春风

最新推荐文章于 2025-03-16 16:35:30 发布

阅读量3.6k

点赞数 8

分类专栏： # 智能驾驶（入门）文章标签： mcu autosar

本文链接：https://blog.csdn.net/qq_43620805/article/details/122810174

版权

智能驾驶（入门）专栏收录该内容

20 篇文章

订阅专栏

本文介绍了UDS（统一诊断服务）的基本概念，包括为什么需要诊断功能，UDS的服务分类以及寻址模式。重点讲解了两个常见服务：诊断会话控制和安全访问。诊断会话控制分为默认、编程和扩展会话，用于权限管理。安全访问服务涉及ECU的数据保密，通过多轮安全验证实现解锁。文章通过实例解释了这两个服务的工作原理和安全验证算法，旨在帮助初学者理解UDS的诊断流程。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

UDS诊断入门

写在前面：UDS实践性强，逻辑复杂，很多服务非要体验过一次才能理解，导致包括我在内的初学者感觉晦涩难懂，不明觉厉，因此将自己的理解写下来、整理下来，与君共勉。

1备忘录

在这里插入图片描述

2.UDS定义

2.1首先思考下我们为什么需要诊断的功能？？
解答：为什么我们要设计UDS这样的诊断协议呢？因为在汽车诊断协议诞生之前，修车只能靠师傅的经验，因为汽车零部件不会告诉你它哪里出了问题。但有了诊断协议之后，一旦零部件出了问题或者出过问题，它们会把故障信息保存在内存里面，维修师傅就可以通过通信总线读取这些故障信息，比如一个ECU经历欠压故障之后，它会将欠压故障代表的DTC（诊断故障码）存储起来，可选择性保存的还有发生故障时的快照信息（比如此时的车速、读到的电压值等）。快照信息有助于测试工程师和售后技师查找发生故障的原因。
除了CAN总线以外，UDS也可在不同的汽车总线（例如 LIN, Flexray, Internet 和K-line）上实现。
2.2在代码中我们如何体现诊断的功能呢？
解答：其实就是26个服务（你可以理解成26个功能）UDS本质上是一系列服务的集合。UDS的服务包含6大类，共26种。每种服务都有自己独立的ID，即SID。

SID：Service Identifier，诊断服务ID。UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方(Tester)给ECU发送指定的请求数据（Request），这条数据中需要包含SID，且SID处于该应用层数据的第一个字节。如果是肯定的响应（Positive Response），首字节回复[SID+0x40]，举例子就是请求0x10，响应0x50；请求0x22，响应0x62。如果是否定的响应（Negative Response），首字节回复0x7F，第二字节回复刚才询问的SID。比如Tester请求0x10服务，我想进入编程模式，ECU给出否定响应，首字节0x7F，第二字节回复0x10，代表我否定你的0x10服务请求，第三字节是NRC(否定响应码)，代表我否定你的依据。

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

通常，在CAN总线中，Addressing information寻址信息会在CAN的帧ID中体现出来，例外是远程寻址，但不常使用。所谓的寻址信息包含了源地址(Source Address)和目标地址(Target Address)，就是这条信息是由谁发给谁的，类似于收件人和发件人。当然，ECU回信给Tester时，ECU就变成源地址了。因此源地址和目标地址在UDS中并不是一成不变的。

UDS的寻址模式分两种，一种是物理寻址（点对点、一对一），根据物理地址的不同进行访问，但只能访问单个ECU节点，Tester为SA源地址，ECU作为TA目标地址；对应的，另一种是功能寻址（广播、一对多），根据功能的不同进行访问，它能访问多个ECU节点，对于标准帧来说，通常是0x7DF。

每一个ECU都有2个CAN的诊断帧ID，分别对应物理寻址的收与发。通常由主机厂来确定不同ECU的这两个特定的诊断ID。比如0x701对应接收Tester的消息，0x709对应发给Tester的消息。

这篇文章只会拿出我目前经常用的服务去举例具体的每个服务的意思可以在网上搜一大堆，我这篇文档的目的就是让你在大的方面去理解诊断，至于细节的东西可以参考下其他内容

3 例子1：诊断会话 Diagnostic Session Control(0x10)服务

$10包含3个子功能，01 Default默认会话，02 Programming编程会话，03 Extended扩展会话，ECU上电时，进入的是默认会话（Default）。

为什么设计三个会话模式呢？因为权限问题。默认会话权限最小，可操作的服务少；扩展模式通常用于解锁高权限诊断服务，例如写入数据/参数、读写诊断码；编程模式用于解锁bootloader相关的诊断服务，即程序烧录。

题外话，讲个故事。这三个会话模式好比普通项目成员（默认会话）、项目组长（扩展会话）和会计（编程会话）的关系，小职员权限最小，小职员有的权限项目组长全有，项目组长还多了些其他的高端权限（如写数据、例程控制）。会计则不同，它有些自己独有的权限（刷写程序），但项目组的很多权限它没有（读/擦故障码），因为它只干会计相关的事，本身不参与项目。

这三个子功能就像是三个容器，其他的服务都是在这个容器中发挥作用（0x27服务也同样类似）

3 例子2：27安全访问(0x27)服务

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

27流程图
例子：