一、诊断分类
汽车诊断通常分为OBD和UDS：
关键区别与关系总结
| 特性 | OBD（法规诊断） | UDS（增强/工程诊断） |
|---|---|---|
| 核心目标 | 排放监控，法规符合性 | ECU开发、测试、生产、深度售后诊断 |
| 强制性 | 法规强制，面向市场准入 | 行业标准，非强制但已成事实全球标准 |
| 标准化 | 接口、协议、DTC完全统一 | 服务格式统一 ，具体内容由车厂自定义 |
| 功能范围 | 窄而固定（约9项服务，仅限排放相关） | 宽而灵活（约30项服务，覆盖ECU所有功能） |
| 使用场景 | 快速排放故障排查，通用扫描仪 | ECU开发、软件刷写、深入故障分析、专业设备 |
| 通信协议 | 一套完整的物理层到应用层规范 | 仅定义应用层，可承载于CAN、Ethernet等 |
| 诊断对象 | 主要为与排放相关的ECU（如发动机ECU） | 车辆上几乎所有ECU（车身、底盘、动力、娱乐等） |
UDS协议定义基础的编码规则和服务逻辑，但具体的DID编码、对应的数据内容都是由车厂自主定义的。
诊断过程是诊断仪按照严格的协议规范 和时序要求 ，通过与ECU建立受控的会话状态 ，在通过安全验证 后，发送格式化的诊断请求 ，然后解析ECU返回的结构化响应 （可能是肯定响应、否定响应或等待响应），并基于此进行系统化的故障分析和车辆维护的完整工程流程。
服务ID（Service Identifier，SID） 就是UDS协议中那些十六进制代码 ，比如0x22、0x10、0x19等。它们就像是诊断服务的"命令代码"或"功能编号"。
UDS请求报文格式
二、26个服务的分类
ISO 14229-1 标准定义的核心服务
2.1 诊断和通信管理单元
2.2 故障码传输功能类
2.3 数据传输类
2.4 输入输出控制类
2.5 例行程序控制单元
三、UDS报文格式
标准诊断会话模式（单次服务）
一个完整的诊断操作通常由多个"请求-响应"对按特定顺序组成。
【举例】
目标：写入配置数据（0x2E 服务），该服务需要先通过安全访问（0x27）解锁。
| 步骤 | 请求方 | 请求 (SID + 参数) | 响应方 | 响应 (RSID/NRC + 数据) | 说明 |
|---|---|---|---|---|---|
| 1 | Tester | 0x10 03 (进入扩展会话) |
ECU | 0x50 03 (肯定响应) |
切换会话模式 |
| 2 | Tester | 0x27 01 (请求种子) |
ECU | 0x67 01 [Seed] (肯定) |
获取随机种子 |
| 3 | Tester | 0x27 02 [Key] (发送密钥) |
ECU | 0x67 02 (肯定) |
密钥正确，解锁 |
| 4 | Tester | 0x2E [DID] [Data] (写数据) |
ECU | 0x6E [DID] (肯定) |
执行受保护操作 |
| 5 | Tester | 0x10 01 (返回默认会话) |
ECU | 0x50 01 (肯定) |
退出诊断模式 |
模式总结 ： 复杂的诊断任务实质是多个原子化的"请求-响应"对，按业务逻辑串行组合而成的状态机。
3.1 诊断请求和响应
本质是一段十六进制的报文。
【诊断请求】
注：01 07是电压的DID。
DID（Data Identifier，数据标识符），它是每一条数据的"身份证号"，在整个ECU系统中唯一对应一项具体信息。比如，车辆VIN码的DID是F1 90，软件版本的DID是F1 87（具体DID由车厂定义）。有了DID，我们就可以对车辆信息进行读（22）、写（2E）等操作。
【肯定响应】
【否定响应】
3.2 UDS的否定响应码
否定响应码是一个字节（0x00~0xFF）的标准化代码，用于精确告知诊断仪服务请求失败的具体原因 。格式固定为：7F [Requested SID] [NRC]。
常见的否定响应码：
常见NRC分类与实例
1. 与条件不满足相关的NRC
这类NRC表示ECU理解请求，但当前状态不允许执行。
| NRC | 助记符 | 说明 | 典型场景实例 |
|---|---|---|---|
| 0x22 | conditionNotCorrect |
条件不正确。这是最常遇到的NRC之一，表示请求的服务在当前车辆或ECU状态下无法执行。 | 1. 0x31 RoutineControl (例: 0x31 01 02 00) ：请求执行"燃油泵测试"例程，但发动机正在运行 。ECU会回复 7F 31 22。 2. 0x2E WriteDataByIdentifier ：尝试写入一个只允许在"点火开关ON，车辆静止"状态下写入的DID，但车速>0。 |
| 0x12 | subFunctionNotSupported |
子功能不支持。请求的服务子功能参数无效或在此ECU上未实现。 | 0x10 DiagnosticSessionControl ：请求进入 0x10 04 (排放相关诊断会话)，但该ECU不支持此子功能。响应：7F 10 12。 |
| 0x24 | requestSequenceError |
请求序列错误。请求的步骤顺序不正确。 | 0x27 SecurityAccess ：未先请求种子（0x27 01），直接发送密钥（0x27 02 [Key]）。响应：7F 27 24。 |
2. 与参数错误相关的NRC
这类NRC表示请求中的参数值本身有问题。
| NRC | 助记符 | 说明 | 典型场景实例 |
|---|---|---|---|
| 0x31 | requestOutOfRange |
请求超出范围。请求的参数值（如DID、RID）无效、未知或不支持。 | 1. 0x22 ReadDataByIdentifier ：请求读取 DID=0xF1C7，但ECU不支持此DID。响应：7F 22 31。 2. 0x19 ReadDTCInformation ：使用不支持的子功能，如 0x19 08。 |
| 0x33 | securityAccessDenied |
安全访问被拒绝。尝试执行需要安全解锁的服务，但未解锁或解锁失败。 | 0x2E WriteDataByIdentifier 或 0x31 RoutineControl ：在未通过0x27服务成功解锁 的情况下，尝试写入关键配置或执行刷写例程。响应：7F 2E 33 或 7F 31 33。 |
| 0x35 | invalidKey |
无效密钥 。在0x27服务中，提供的密钥与ECU计算的期望密钥不匹配。 |
0x27 SecurityAccess ：发送密钥 0x27 02 [Key]，但Key计算错误。响应：7F 27 35。 |
3. 与协议/格式错误相关的NRC
这类NRC表示请求不符合UDS报文格式或通信规则。
| NRC | 助记符 | 说明 | 典型场景实例 |
|---|---|---|---|
| 0x13 | incorrectMessageLengthOrInvalidFormat |
报文长度不正确或格式无效。请求报文的长度与预期不符，或参数格式错误。 | 1. 0x22 ：请求DID时只发送了22 01（缺少低字节）。响应：7F 22 13。 2. 多帧传输错误：流控帧参数设置矛盾。 |
| 0x14 | responseTooLong |
响应太长 。用于服务器告知客户端，其响应数据太长，但客户端未支持多帧传输（即未正确初始化流控）。现已较少使用。 | 在单帧请求 模式下，请求了一个会产生长响应的服务（如读取所有DTC信息 0x19 0A）。 |
| 0x72 | generalProgrammingFailure |
常规编程错误。在ECU编程（刷写）过程中发生非特定的失败。 | 0x34 RequestDownload 或 0x36 TransferData ：尝试写入闪存时，发生校验和错误、电压不稳或硬件故障。响应：7F 34 72。 |
4. 与会话/安全状态相关的NRC
这类NRC与诊断会话层级和安全状态直接相关。
| NRC | 助记符 | 说明 | 典型场景实例 |
|---|---|---|---|
| 0x11 | serviceNotSupported |
服务不支持。当前会话中不支持请求的服务ID。 | 在默认会话（0x01） 下，尝试执行只能在扩展会话（0x03） 中使用的服务，如 0x27、0x28、0x2E、0x31 等。响应：7F [SID] 11。 |
| 0x7E | subFunctionNotSupportedInActiveSession |
活动会话中不支持此子功能。请求的服务子功能在当前激活的诊断会话中不可用。 | 在编程会话（0x02） 中，尝试执行 0x28 01 (恢复通信)，但该子功能在编程会话中被禁用。响应：7F 28 7E。 |
| 0x7F | serviceNotSupportedInActiveSession |
活动会话中不支持此服务。与0x11类似，但更具体地指向会话限制。 |
总结表：从现象快速定位问题
| 你尝试做什么？ | 可能收到的NRC | 首要排查方向 |
|---|---|---|
| 读取/写入数据 | 0x31 |
DID/RID是否正确？ECU型号是否支持？ |
| 执行例程/控制 | 0x22 |
车辆状态是否满足（停车、熄火、特定电压等）？ |
| 进行安全解锁 | 0x35 |
种子算法或密钥计算是否正确？ |
| 在默认会话做高级操作 | 0x11 |
是否已切换到扩展会话（0x03）？ |
| 任何需要解锁的操作 | 0x33 |
是否已完成0x27安全访问并成功？ |
3.3 请求和响应的寻址
UDS诊断通信的报文是通过CAN协议传输的，UDS诊断的报文就是CAN报文；UDS请求和响应的ID就是CAN报文的ID。请求和响应的信息
每个ECU在UDS诊断通信中拥有两个专属的、唯一的CAN ID，一个用于"接收"诊断请求，一个用于"发送"诊断响应。
2. 通信过程解析（以ECU A为例）
诊断仪希望与 ECU A 对话，过程如下：
步骤1：诊断仪发送请求
-
诊断仪将诊断命令（如
22 01 07读取车速）封装在CAN报文的数据场中。 -
将这条报文的 CAN ID（仲裁场） 设置为 ECU A的请求地址
0x701。 -
报文被广播到CAN总线上。
步骤2：ECU A接收并处理请求
-
总线上所有ECU（A、B、C）都"听到"了这条ID为
0x701的报文。 -
ECU A 的CAN控制器硬件或软件过滤器识别出
0x701是自己的"专属呼叫ID"，于是接收并处理这条请求。 -
ECU B和C发现ID（
0x702,0x703）与自己的不匹配，于是忽略此报文。
步骤3：ECU A发送响应
-
ECU A处理完请求后，准备回复（如
62 01 07 00 50）。 -
它将响应数据封装在新的CAN报文数据场中。
-
将这条响应报文的 CAN ID 设置为自己的响应地址
0x709，并发送到总线上。
步骤4：诊断仪接收响应
-
诊断仪一直在监听总线，当看到ID为
0x709的报文时，就知道这是来自ECU A的回复。 -
诊断仪根据ID
0x709即可将响应数据与之前发给0x701的请求关联起来，完成一次完整的诊断对话。
3. 为什么这样设计？（优点）
-
精准寻址：诊断仪可以通过设置不同的请求ID，与网络上任意一个特定的ECU进行一对一通信，避免多个ECU同时响应造成总线混乱。
-
高效过滤 ：ECU的CAN硬件可以通过ID过滤器，只接收发给自己的请求（ID=
0x701），大大减轻CPU处理无关报文的中断负担。 -
明确溯源 ：诊断仪只需看响应报文的ID（如
0x709），就能立即知道是哪个ECU回复的，无需解析响应数据中的地址信息，处理更快速、可靠。 -
标准化与隔离：为每个ECU分配独立的ID空间，符合Autosar等标准架构，也使不同供应商的ECU集成更简单。
总结
-
0x709/70A/70B是ECU的"回信签名"或"说话时的自称" ，用于在广播式的CAN总线上表明"这句话是谁说的"。 -
诊断仪通过同时监听所有已知ECU的"回信签名"，来准确、高效地接收来自不同ECU的响应。
-
这样设计，不是为了对应多个诊断仪 ，而是为了让一个诊断仪 能够清晰、无冲突、高效率地与多个ECU在一个共享的、广播式的网络中进行可靠对话。
所以，您的图中，诊断仪就像一个总机接线员，它知道：
-
要呼叫ECU A，就拨
0x701。 -
之后，它会留意来电显示是
0x709的电话，那一定是ECU A打回来的。
4.物理寻址&功能寻址
| 特性 | 物理寻址 (Physical Addressing) | 功能寻址 (Functional Addressing) |
|---|---|---|
| 本质 | "一对一"私聊 | "一对多"群发 |
| 目标 | 唯一的、特定的ECU | 一组满足条件的ECU（通常是全部） |
| CAN ID | 目标ECU唯一的物理请求ID (如 0x701) |
通用的功能地址 (如 0x7DF) |
| 响应ID | 目标ECU唯一的物理响应ID (如 0x709) |
各ECU用自己的物理响应ID回复 |
| 通信关系 | 点对点 | 广播 |
| 主要用途 | 针对特定ECU的诊断、刷写、标定 | 全局控制、批量读取、功能发现 |
| 类比 | 打电话给张三（有他的手机号） | 在学校广播里喊："所有三年级同学集合！" |
在一个完整的诊断流程中，两者经常协同使用：
场景：准备为ECU A刷写软件
-
步骤1（功能寻址） ：诊断仪发送
0x7DF[28 01 03]，命令所有ECU（除编程会话中的A）静默通信。 -
步骤2（物理寻址） ：诊断仪发送
0x701[10 02]，命令特定的ECU A进入编程会话。 -
步骤3（物理寻址） ：诊断仪持续与
0x701通信，向ECU A发送刷写数据 (0x34,0x36服务)。 -
步骤4（功能寻址） ：刷写完成，诊断仪发送
0x7DF[28 01 00]，命令所有ECU恢复正常通信。
5.面试考点
现在需要通过UDS诊断升级某一ECU，要暂停其他所有ECU的网络通信，可以怎么做？
要给总线上所有ECU（除当前需要升级的ECU以外）发送28服务(用功能寻址)。也就是用诊断仪发送一帧ID为7DF的28服务的诊断请求报文，这样总线上所有ECU都会停止网络通信了。
核心原理：功能寻址 + 诊断服务权限
1. 功能寻址 (Functional Addressing)
-
当诊断仪发送目标ID为
0x7DF的报文时，总线上所有支持功能寻址的ECU都会接收并处理这条请求 ，无论它们各自的物理地址（0x701，0x702等）是什么。 -
这就像是老师在教室里喊："所有同学请注意！" 而不是点某一个人的名字。
2. 28服务：CommunicationControl（通信控制）
-
这是一个UDS标准服务，允许诊断仪临时控制ECU的非诊断类通信行为。
-
它有一个关键子功能：
0x01- suppressPositiveResponseMessage (抑制肯定响应消息) 。这意味着当ECU收到这个请求时，它被要求保持沉默，不发送任何肯定响应。这是为了避免所有ECU同时响应造成总线瘫痪。 -
它的关键参数是
controlType(控制类型)：-
0x00- enableRxAndTx： 恢复正常通信（开启接收和发送）。 -
01- enableRxAndDisableTx ： 允许接收，但禁止发送（最常用）。 -
02- disableRxAndEnableTx`： 禁止接收，但允许发送（极少用）。 -
03- disableRxAndTx ： 禁止接收和发送（即"禁言"）。
-
3.目标ECU (ECU A) 的特殊处理
目标ECU A 也收到了这条广播命令。但因为在刷写流程中，它即将或已经切换到"编程会话" 。
* 在编程会话下，ECU的行为是预定义的：它只响应物理寻址的诊断请求 （尤其是来自诊断仪的下载0x34、传输0x36等刷写服务），并自动忽略功能寻址的0x28服务 ，或者该服务在编程会话下被配置为无效。
* 因此，ECU A不会执行这个"禁言令"，它会继续保持与诊断仪的通信，准备接收刷写数据。
四、具体服务
4.1 10服务
10服务 是UDS中最基础、最核心的服务之一。它的核心功能是控制ECU（电子控制单元）内部的诊断状态 ，即切换不同的"诊断会话"。
你可以把"诊断会话"想象成ECU的不同工作模式。每个模式解锁不同等级的功能和权限。10服务就是用来在这些模式间切换的"钥匙"。
4.1.1 会话分类
1. 标准会话
这是诊断会话的基础分类。
-
默认会话（Default Session, 0x01）：
-
状态 ：ECU上电后自动进入的模式。
-
功能 ：在此模式下，只能执行最基本、安全的诊断服务，如读取故障码（19服务）、读取数据（22服务）等。无法执行写入、编程等具有潜在风险的操作。
-
目的：保证ECU在车辆正常运行时的安全性和稳定性。
-
-
非默认会话（Non-default Session）：
-
需要主动通过10服务请求才能进入的模式。主要包含：
-
扩展会话（Extended Session, 0x03）：
-
解锁更多诊断功能，例如写入数据（2E服务）、控制输入输出（2F服务）等。
-
是进入更高级会话（如编程会话）的必经之路。
-
-
编程会话（Programming Session, 0x02）：
-
用于执行ECU软件/固件刷写（编程）的特殊模式。
-
前提：必须先进入扩展会话（0x03），然后再切换到编程会话（0x02）。这是为了增加一层安全检查，防止误操作。
-
-
-
-
自定义会话：
- 正如你图片中第一行所注，ECU制造商可以自定义额外的会话（例如，0x40-0x5F），用于特定的测试、标定或工厂模式，提供更特殊的权限。
会话切换流程 ：
ECU上电 → 默认会话 (0x01) → [10 03] → 扩展会话 (0x03) → [10 02] → 编程会话 (0x02)
4.1.2 会话超时
会话超时是UDS中一个非常重要的安全机制。
-
什么是会话超时？
-
当ECU处于非默认会话 （如扩展会话、编程会话）时，如果在一段规定的时间内没有收到任何诊断请求 ，ECU会自动退回到默认会话（0x01）。
-
这个规定的时间就是会话超时时间。
-
-
为什么需要超时机制？
-
安全性：防止诊断工具异常退出或通信中断后，ECU长期处于高权限模式，从而带来安全风险（如被恶意利用）。
-
资源管理：非默认会话可能占用更多内存或CPU资源，超时机制有助于释放这些资源。
-
-
超时时间的管理
-
超时时间通常由ECU制造商定义，并写入诊断规范。
-
3E服务（Tester Present，诊断仪保持连接） 就是专门用于重置和保持这个超时计时器的。诊断工具需要定期发送3E服务（如每隔几秒），以告知ECU"我还在"，从而维持当前的非默认会话状态。
-
最大超时时间指的是ECU允许的最长无通信时间，超过此时间，强制退回默认会话。
-
4.1.3 10服务请求与响应格式
请求（诊断仪 → ECU）：
10 [Session Type]肯定响应（ECU → 诊断仪）：
50 [Session Type] [P2 Server Max] [P2* Server Max]例如：50 03 32 64
-
50： 10服务 + 0x40（肯定响应标识）。 -
03： 当前成功进入的会话类型。 -
32 64： 通常是两个时间参数（单位一般为毫秒），用于告诉诊断仪P2服务器最大响应时间 和P2*服务器最大响应时间（在编程会话下）。诊断工具会根据这些时间来调整等待响应的超时设置。
否定响应：
如果切换失败（如请求直接进入编程会话但未先进入扩展会话），ECU会回复以7F开头的否定响应码，例如7F 10 22（条件不正确）。
4.1.4 P2 Server Max 和 P2 Server Max*
1. P2 Server Max
-
定义 ：当ECU对上一个诊断请求的肯定响应已经发出 后，到它准备好接收下一个新请求 所需的最大时间。
-
通俗解释 ："我（ECU）刚回答完你一个问题，我的大脑需要稍微整理一下，请你至少等待
P2 Server Max这么久之后，再问我下一个问题。如果我还没准备好，你提前问了，我可能无法正确处理。" -
主要目的：保护ECU，防止诊断仪在ECU内部状态未就绪时连续发送请求，导致ECU过载或响应错误。
2. P2* Server Max
-
定义 ：当ECU收到一个请求后，到它必须发出对应的肯定或否定响应 所需的最大时间。
-
通俗解释 ："你（诊断仪）问我任何一个问题，我保证在
P2* Server Max这段时间内，一定会给你一个明确的答复（成功或失败）。请你耐心等待这么久，不要认为我死机了。" -
主要目的 ：给诊断仪一个明确的响应超时等待时间 。诊断仪发送请求后，会启动一个计时器，时长设为
P2* Server Max。如果在此时间内未收到响应，诊断仪就会判定为超时（Timeout），认为通信失败。
例子：
诊断仪发送 10 02 请求进入编程会话。
ECU肯定响应：50 02 00 C8 05 DC
-
50： 肯定响应 -
02： 已进入编程会话 -
00 C8：P2 Server Max= 0x00C8 = 200毫秒 -
05 DC：P2* Server Max= 0x05DC = 1500毫秒
这意味着诊断工具知道：
-
在这个编程会话下，ECU处理完一个请求后，需要最多200毫秒来准备接收下一个。
-
在这个编程会话下，对任何请求的响应，最多可能需要等待1500毫秒。因此，诊断工具必须将自己的响应超时阈值调整为至少1500毫秒，否则会误报超时错误。
总结
-
P2 Server Max ： 请求间间隔时间。告诉诊断仪"发完一个请求后，请间隔这么久再发下一个"。
-
*P2 Server Max**： 请求响应超时时间。告诉诊断仪"问我问题后，请等我这么久，我肯定会回答"。
-
它们在 10服务响应 中提供，其值随诊断会话的变化而变化（通常是编程会话下值最大）。
-
诊断工具必须根据这些值来动态调整其通信时序和超时设置，这是实现鲁棒性UDS通信的关键。
-
它们与会话超时（S3） 是完全不同维度的两个概念，共同构成了UDS协议的双重超时管理机制。
4.2 0x27服务
27服务（SecurityAccess） ，是一个专门用于安全访问的服务。你可以把它理解为ECU（电子控制单元，即车载电脑）的一道"安全锁"。
它的核心作用是保护ECU内部关键的、或者涉及安全和排放的数据与功能，防止未授权的诊断设备（如第三方诊断仪）进行非法读取或篡改。例如，固件刷写、防盗匹配等高风险操作，通常都需要先通过27服务的身份验证。
4.2.1 工作原理："种子-密钥"机制
详细步骤拆解：
-
请求种子 (Request Seed) ：诊断仪发送
27 01请求种子。这里的01是子功能，代表请求种子 。不同的奇数子功能（如 01, 03, 05）代表不同的安全等级。 -
生成并返回种子 ：ECU收到请求后，会内部算法随机生成一串数据（种子，Seed） ，例如
4A 3F 2C 91，然后回复67 01 4A 3F 2C 91。同时，ECU内部也会用同样的种子，通过保密的Seed-Key算法计算出正确的密钥（Key）。 -
计算并发送密钥 ：诊断仪收到种子后，必须使用与ECU完全相同的、保密的Seed-Key算法 ，基于收到的种子计算出密钥（Key），例如
B7 C0 D3 6E，然后发送27 02 B7 C0 D3 6E。这里的02是偶数子功能，代表发送密钥 ，并且必须与请求种子时的奇数子功能（01）对应。 -
验证密钥并解锁 ：ECU将收到的密钥与自己内部计算出的密钥进行比较。如果两者一致 ，则ECU返回
67 02表示解锁成功；否则会返回否定响应码（NRC，否定响应代码），解锁失败。
📋 关键规则
-
安全等级独立 ：不同安全等级（如
01/02和03/04）通常是独立的，解锁了高等级不代表低等级也自动解锁。 -
锁定与解锁 ：ECU上电后默认处于锁定状态 。成功执行27服务后变为解锁状态，才能进行后续的高权限操作。
-
防暴力破解 ：为防止暴力破解，ECU有安全策略。例如，连续多次输入错误密钥，ECU会返回NRC
0x36（超过尝试次数），并进入一段时间的延时锁定 ，期间任何安全访问请求都会回复NRC0x37（要求延时）。
4.2.2 27服务的安全级别
（1）安全等级的真实含义
在UDS（统一诊断服务）中，27服务是为了保护ECU（电子控制单元）中不同安全级别的数据和功能而设计的。不同的安全等级对应不同的权限，例如：
-
一个等级可能只允许读取车辆识别码（VIN）等敏感数据。
-
另一个更高的等级可能才允许写入数据，如进行固件刷写或参数标定
（2）子功能：安全等级的"身份证"
在27服务的请求中，是通过子功能来指定要操作哪个安全等级的。
-
请求种子 ：使用奇数 子功能，如
0x01,0x03,0x05... -
发送密钥 ：使用对应的偶数 子功能，如
0x02,0x04,0x06...
0x01和0x02、0x03和0x04......这样奇偶成对出现的子功能，就定义了一个独立的安全等级。例如：
-
安全等级A：由
27 01（请求种子）和27 02（发送密钥）定义。 -
安全等级B：由
27 03（请求种子）和27 04（发送密钥）定义。
数字01、03仅仅是一个ID，用于区分不同的安全等级。ECU制造商可以自由定义这些等级，编号是任意的，不带有层级关系。
（3）重要规则
-
独立解锁 ：每个安全等级是独立的。解锁了等级
01/02并不意味着自动解锁等级03/04。如果需要更高权限，必须再次执行对应安全等级（如03/04）的握手流程。 -
单一活跃 ：在任何时刻，ECU中有且只有一个安全等级可以处于解锁状态。当成功解锁一个新等级时，之前已解锁的等级会被自动锁定。
-
状态依赖：ECU上电后默认所有等级均处于锁定状态。此外，27服务通常需要在非默认会话（如扩展会话或编程会话）下才能使用，在默认会话中是不支持的。
4.2.3 否定响应码NRC
当解锁失败时，ECU会返回7F 27开头并跟一个NRC，常见的错误码有：
-
0x12：子服务不支持 -
0x13：报文长度错误 -
0x22：条件不满足 -
0x24：请求顺序错误 -
0x35：密钥无效 (最常见) -
0x36：超过最大尝试次数 -
0x37：延时未到，请等待
27服务是UDS诊断中保障ECU安全的核心机制，通过"种子-密钥"的握手协议，有效防止了对车辆核心电子系统的非法操作。
4.3 19服务
4.3.1 核心功能概述
简单来说，19服务能帮你回答以下几个问题：
-
ECU当前或历史上发生过哪些故障？
-
这些故障目前是否还存在？
-
故障发生时，车辆的关键参数（如车速、电压、里程）是什么？
-
某个故障发生过几次？是否已经被确认或"老化"清除？
4.3.2 常用子服务详解
19服务拥有多达28个子功能（Sub-function），其中5个是最常用、最重要的。它们通过不同的子功能参数（Sub-function）来区分。
| 子服务 | 名称 | 功能描述 | 典型应用场景 |
|---|---|---|---|
19 01 |
reportNumberOfDTCByStatusMask | 根据状态掩码，返回匹配的DTC数量。 | 快速确认是否有故障，并根据数量决定后续操作。 |
19 02 |
reportDTCByStatusMask | 根据状态掩码，返回所有匹配的DTC列表及其状态。 | 获取当前所有"待处理"或"已确认"的故障码清单。 |
19 04 |
reportDTCSnapshotRecordByDTCNumber | 根据指定的DTC，返回其关联的快照记录。 | 查看某个具体故障发生时记录的冻结帧数据。 |
19 06 |
reportDTCExtDataRecordByDTCNumber | 根据指定的DTC，返回其关联的扩展数据记录。 | 获取故障发生的次数、老化计数器等额外信息。 |
19 0A |
reportSupportedDTC | 返回ECU支持的所有DTC及其当前状态。 | 在开发或测试阶段，验证ECU支持的DTC列表是否完整。 |
4.3.3 DTC状态位 (Status of DTC)
在19服务的响应中，每个DTC都会附带一个1字节的状态位，用于精确描述该DTC的生命周期状态。这8个bit的含义如下：
| Bit位 | 名称 | 含义解释 |
|---|---|---|
| bit 0 | testFailed | 最近一次测试结果为失败（即当前存在故障）。 |
| bit 1 | testFailedThisOperationCycle | 在当前操作循环（如本次点火周期）中，测试曾失败过。 |
| bit 2 | pendingDTC | 待处理故障。在当前或上个操作循环中检测到故障，但尚未确认。 |
| bit 3 | confirmedDTC | 已确认故障。故障已被存储到非易失性存储器中（历史故障）。 |
| bit 4 | testNotCompletedSinceLastClear | 自上次清除后，针对该DTC的测试尚未完成。 |
| bit 5 | testFailedSinceLastClear | 自上次清除后，该DTC测试至少失败过一次。 |
| bit 6 | testNotCompletedThisOperationCycle | 在当前操作循环中，针对该DTC的测试尚未完成。 |
| bit 7 | warningIndicatorRequested | 该DTC请求点亮警告指示灯（如发动机故障灯MIL）。 |
4.3.4 报文格式与实例
（1） 请求格式示例
以最常用的 19 02 为例，请求读取所有当前确认的故障码：
请求报文 ：19 02 09
-
19：服务ID -
02：子功能，reportDTCByStatusMask -
09：状态掩码（二进制0000 1001），代表匹配confirmedDTC(bit3)或testFailed(bit0)为真的DTC。
（2）响应格式示例
假设ECU中存在一个DTC，其16进制表示为0x123456，状态为0x09（bit0和bit3为1，即当前存在的已确认故障）。
肯定响应报文 ：59 02 01 02 09 12 34 56 09
-
59：肯定响应ID（19+0x40） -
02：响应的子功能 -
01：DTCStatusAvailabilityMask，表示ECU支持哪些状态位 -
02：DTCFormatIdentifier，表示DTC的格式 -
12 34 56：DTC编号（3字节） -
09：该DTC的状态位
【19 01实例】
4.3.5 19 02
简单总结：
-
19 02 08：读取已确认故障 （状态掩码08→confirmedDTC= 1） -
19 02 09：读取当前或历史故障 （状态掩码09→confirmedDTC= 1 或testFailed= 1）
4.4 UDS报文传输的四种帧
CAN协议中的数据帧
单帧传输 --- 少量字节的UDS报文（一帧CAN报文容纳得下）
多帧传输 ---大量字节的UDS报文（一帧CAN报文容纳不下）
ISO-15765-2 协议规定了基于CAN总线进行UDS报文传输的细节（包括四种帧）。
4.4.1 单帧传输
4.4.2 多帧传输
4.4.3 流控帧
五、诊断故障码
五位码 (如 P0420) ：主要用于 OBD-II 诊断 ，遵循SAE J2012 / ISO 15031-6标准。它是为了满足法规（如排放法规）而必须公开的标准化故障码。不同品牌的车，同一个 P0420 含义几乎完全相同。
诊断仪读取"五位故障码"：
【逐位详细拆解】
按照 ISO 15031-6 标准，P0420 可以拆解为：
| 字符位置 | 值 | 类型 | 含义解读 |
|---|---|---|---|
| 第一位 | P | 系统 (System) | 动力总成 (Powertrain)。表示这是一个与发动机、变速箱及其相关传感器（如氧传感器）有关的故障。 |
| 第二位 | 0 | 类型 (Type) | ISO/SAE 标准化故障。这是一个全球统一的、标准化的故障码，所有品牌的车辆定义基本一致。如果是"1"，则代表是制造商自定义的特殊故障码。 |
| 第三位 | 4 | 子系统 (Subsystem) | 辅助排放控制 。在P码中，数字"4"通常指向与排放系统相关的辅助部分。具体到P0420，它明确指向了催化剂系统。 |
| 第四、五位 | 20 | 具体故障 | 标识具体的故障模式 。对于催化剂系统，"20"这个组合代表的含义是系统效率低于阈值。 |
5.1 五位故障码的格式
P0420拆解：
-
第一位：字符 (系统) - 标识故障所属的系统大类。
-
P (Power train)：动力总成 (发动机、变速箱等)。
-
C (Chassis)：底盘 (ABS、ESP等)。
-
B (Body)：车身 (车门、空调、气囊等)。
-
U (Network)：网络通信。
-
-
第二位：数字 (类型) - 标识故障码的标准化程度。
-
0 ：ISO/SAE 标准化定义的故障码。
-
1 ：OEM 自定义的故障码。
-
-
第三位：字符 (子系统) - 标识故障发生的具体子系统
-
第四、五位：数字 (具体故障) - 标识具体的故障模式 (如：02-信号范围/性能问题，11-短路到地等)。
5.2 UDS的三字节故障码
三字节码 (如 0xC0FFEE) ：主要用于 UDS 诊断 ，遵循 ISO 14229-1标准。它是 ECU 内部开发和售后深度诊断使用的内部故障码 。每个字节的含义由汽车制造商自定义，通常承载了更丰富、更具体的信息。
简单来说，OBD码是"通用语言"，用于法规和通用诊断；UDS三字节码是"内部语言"，用于深入开发和故障分析。
【OBD故障码与UDS故障码的关系】
UDS三字节故障码的前两个字节通常就是OBD诊断的五字节故障码。
5.2.1 故障类型FTB
5.2.2 UDS故障码状态位
19 服务返回的 DTC 旁边，总会跟着一个 状态字节 (Status Byte)，这与之前介绍的 OBD 状态位含义一致。它描述了该 DTC 的生命周期状态。
例如，读取到一个三字节码 01 21 05 时，还会读到一个状态字节 0x09 (二进制 0000 1001)，含义如下：
-
Bit 0= 1 (当前故障存在) -
Bit 3= 1 (这是一个已确认的故障) -
这意味着："当前确实存在一个对地短路的故障，并且这个故障已经被确认了。"
