【UDS诊断服务入门】

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）成功。

例子：

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

ECU： 06 67 05 08 27 11 F0 00 肯定响应，回复了对应安全级别的种子

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

ECU： 03 7F 27 78 00 00 00 00 若为否定响应，7F+27+NRC

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

细说下安全验证算法。安全验证算法包括1个核心，3个主体。

第一个主体通常和ECU有关。比如我们先用22服务读取ECU的SN，取其中4个字节，作为“调味料”参与，显然这个“调味料”对于这个ECU来说是不变的，也能通过22服务方便的读取到。

第二个主体seed，通常与ECU的运行时间有关系，是主料，在27服务发送奇数子功能时回复。seed通常一直在发生变化，无法发现其规律。

第三个主体是执行次数，就是算法要执行几轮。执行1轮和2轮得到的结果肯定是不一样的对吧。

最大的核心就是算法了。举个简单的算法，比如seed和ECU SN前4个字节加一下，循环左移两位，执行3轮，return这个数作为key，结束。安全验证就是一把锁，算法越复杂，短时间解开的成本越高，越不易被破解掉。如果失败次数过多还会触发惩罚机制，一段时间内都无法再尝试解锁，防止人为的破解。

https://zhuanlan.zhihu.com/p/37310388这个是我借鉴的博客里面很多内容，不利于新手入门，我提取了我的理解希望能帮组到你