4. UDS服务基础：服务分类、SID与响应机制
好，咱们进入UDS协议栈的核心部分——服务基础。这部分内容，说白了就是UDS的“语法”和“词汇表”。你只有搞懂了这些，才能跟ECU顺畅地“聊天”。
我个人习惯把UDS服务比作一个工具箱。每个工具（服务）都有特定的用途，有的工具是标配（强制），有的则是选配（可选）。咱们今天就把这个工具箱翻个底朝天。
4.1 UDS服务分类：强制与可选
UDS协议（ISO 14229）定义了一大堆服务，但并不是所有服务ECU都必须支持。这就像买车，有的配置是出厂自带，有的得加钱选装。
强制服务（Mandatory）：这是ECU的“出厂标配”。任何符合UDS规范的ECU，都必须支持这些服务。少了它们，诊断仪连最基本的通信都建立不起来。
可选服务（Optional）：这些是“选装包”。根据ECU的功能复杂度和应用场景，厂商可以自由选择实现哪些。比如一个简单的车窗控制器，可能就不需要0x31（例程控制）服务。
我给大家列个表，看看哪些是“标配”，哪些是“选装”：
| SID（服务ID） | 服务名称 | 强制/可选 | 我的备注 |
|---|---|---|---|
| 0x10 | 诊断会话控制 | 强制 | 没有它，诊断进不了门 |
| 0x11 | ECU复位 | 强制 | 重启大法好 |
| 0x27 | 安全访问 | 强制 | 保护ECU不被乱搞 |
| 0x28 | 通信控制 | 可选 | 控制网络通信的开关 |
| 0x3E | Tester Present | 强制 | 告诉ECU“我还活着” |
| 0x22 | 读取数据标识符 | 可选 | 最常用的读数据服务 |
| 0x2E | 写入数据标识符 | 可选 | 写参数、配置用 |
| 0x31 | 例程控制 | 可选 | 执行特定程序，比如自学习 |
| 0x19 | 读取DTC信息 | 可选 | 读故障码，诊断必备 |
| 0x14 | 清除DTC信息 | 可选 | 清故障码 |
4.2 服务ID（SID）与子功能
每个UDS服务都有一个唯一的ID，这就是SID（Service IDentifier）。它占一个字节，范围是0x00到0x3E。诊断仪发送请求时，第一个字节就是SID。
但光有SID还不够。很多服务还需要一个“子功能”（SubFunction）来进一步细化操作。比如0x10服务（诊断会话控制），你要告诉ECU切换到哪个会话——是默认会话（0x01），还是编程会话（0x02）？这个0x01或0x02就是子功能。
子功能的编码规则：子功能占请求报文的第二个字节。其中，最高位（bit 7）有特殊含义：
- bit 7 = 0：表示这是一个“请求并响应”的子功能。ECU处理完请求后，必须回复一个正响应。
- bit 7 = 1：表示这是一个“请求但不响应”的子功能（也叫“抑制正响应”）。ECU处理完请求后，不会发送正响应。这个功能在刷写程序时特别有用，可以减少总线负载。
举个例子：
- 请求：
10 01—— 切换到默认会话，并要求ECU回复。 - 请求：
10 81—— 切换到默认会话，但ECU不需要回复。
4.3 正响应与负响应
ECU收到诊断请求后，要么说“好的，搞定了”（正响应），要么说“不行，出错了”（负响应）。这就是UDS的响应机制。
正响应（Positive Response）：格式是 [SID + 0x40] + [子功能/参数]。说白了，就是把请求的SID加上0x40，然后带上处理结果。
- 请求：
10 01（切换到默认会话） - 正响应：
50 01（0x10 + 0x40 = 0x50，后面跟着子功能0x01）
负响应（Negative Response）：格式是 0x7F + [SID] + [NRC]。其中NRC（Negative Response Code）是一个字节，告诉你具体错在哪了。
- 请求：
10 03（切换到不存在的会话） - 负响应：
7F 10 12（0x7F是负响应标识，0x10是请求的SID，0x12是NRC，表示“子功能不支持”）
常见的NRC码我列一下，大家混个脸熟：
| NRC（十六进制） | 含义 | 常见场景 |
|---|---|---|
| 0x10 | 一般拒绝 | 请求格式不对 |
| 0x11 | 服务不支持 | ECU没实现这个SID |
| 0x12 | 子功能不支持 | SID支持，但子功能没实现 |
| 0x13 | 报文长度错误 | 参数个数不对 |
| 0x22 | 条件不满足 | 比如没解锁就尝试写数据 |
| 0x31 | 请求超出范围 | 参数值非法 |
| 0x33 | 安全访问拒绝 | 没通过安全解锁 |
| 0x78 | 请求正确，但正在处理 | ECU需要时间，让你等等 |
4.4 UDS会话控制（0x10服务）
0x10服务，全称“诊断会话控制”（DiagnosticSessionControl）。它是UDS世界的“大门”。任何诊断操作，都得先通过这个服务进入正确的“会话模式”。
ECU通常有几种会话模式：
- 默认会话（Default Session, 0x01）：ECU上电后的默认状态。在这个模式下，只有少数强制服务可用（比如0x10、0x3E）。说白了，就是“待机模式”，功能受限。
- 编程会话（Programming Session, 0x02）：用于刷写固件。在这个模式下，ECU会开放内存访问相关的服务。注意，进入这个会话通常需要安全解锁。
- 扩展诊断会话（Extended Diagnostic Session, 0x03）：用于更深入的诊断和标定。比默认会话开放更多服务，但比编程会话权限低一些。
- 安全系统诊断会话（Safety System Diagnostic Session, 0x04）：用于安全相关系统（如气囊、ESP）的诊断。这个会话有更高的访问权限。
会话切换的规则：
- ECU上电后，自动进入默认会话。
- 你可以从默认会话切换到任何其他会话。
- 从非默认会话切换回默认会话，不需要安全解锁。
- 从非默认会话切换到另一个非默认会话，通常需要重新进行安全解锁。
- 如果一段时间内没有收到任何诊断请求（超时），ECU会自动切回默认会话。这个超时时间由厂商定义，通常是5秒左右。
来看一个完整的会话切换例子：
// 诊断仪请求：切换到扩展诊断会话
请求：10 03
// ECU正响应：成功切换到扩展会话
响应：50 03
// 现在ECU处于扩展会话模式，可以执行更多服务了
// 比如读取一些敏感数据
请求：22 F1 90
响应：62 F1 90 01 02 03 04
// 如果一段时间没有通信，ECU自动切回默认会话
// 此时再发送0x22请求，ECU会回复负响应
请求：22 F1 90
响应：7F 22 7F // 0x7F表示“服务在当前会话中不支持”
嗯，关于UDS服务基础，咱们今天就聊到这儿。这些概念是后续所有服务的基础，一定要吃透。下一节，咱们会深入讲解0x22和0x2E这两个最常用的数据服务，到时候我会结合一个实际项目中的标定案例来展开。