3. UDS服务分类：强制服务与可选服务、功能单元分组、常用服务ID（SID）速查
好，咱们进入第三章。这一章我打算把UDS服务的分类讲透。说白了，就是让你搞清楚：哪些服务是ECU必须支持的，哪些可以偷懒不实现？服务之间是怎么分组的？以及最常用的那些SID，你能不能一眼认出来？
我在做第一个UDS项目时，就吃过分类不清的亏。当时照着规范把能实现的服务全堆上去了，结果内存爆了。后来才明白——不是所有服务都得做，关键看你的ECU是什么角色。
3.1 强制服务 vs 可选服务
UDS协议里，服务分两类：强制（Mandatory）和可选（Optional）。强制服务，是每个ECU都必须支持的。可选服务，看你的ECU需不需要。
举个例子，你想想看：一个简单的车窗控制器，需要支持会话切换吗？当然要。需要支持例程控制吗？不一定。这就是强制和可选的区别。
| 服务类别 | 说明 | 典型SID |
|---|---|---|
| 强制服务 | 所有ECU必须实现，否则不符合UDS规范 | 0x10（诊断会话控制）、0x3E（Tester Present） |
| 可选服务 | 根据ECU功能需求选择实现 | 0x2E（写入数据）、0x31（例程控制） |
核心原则：强制服务是ECU的“身份证”，没有它，诊断仪连话都跟你搭不上。可选服务是ECU的“技能包”，按需配置。
我个人习惯，在项目初期先列一个表格，把强制服务全部勾上，然后跟系统工程师一起讨论可选服务。这样能避免后期返工。
3.2 功能单元分组
UDS把服务按功能分成了几个组。这个分组不是随便分的，它反映了诊断服务的逻辑层次。我把它总结成四类：
- 诊断管理组：负责会话控制、安全访问、通信控制等。说白了，就是管“能不能干活”的。
- 数据访问组：负责读写数据、标识符、内存等。这是最常用的组，OTA升级全靠它。
- 程序控制组：负责例程控制、请求下载/上传等。刷写固件时，这个组是主角。
- 故障诊断组：负责读取/清除DTC。嗯，修车师傅最爱的组。
我记得有一次，客户要求ECU支持“安全刷写”。我一看，这不就是跨组协作吗？数据访问组负责读取版本号，程序控制组负责下载固件，诊断管理组负责安全访问。三个组缺一不可。
小技巧：设计诊断功能时，按功能单元分组来规划代码模块。每个组一个源文件，维护起来特别清爽。
3.3 常用服务ID（SID）速查
下面这张表，是我做项目时经常翻的。你最好把它记在脑子里，或者打印出来贴在工位上。
| SID（十六进制） | 服务名称 | 强制/可选 | 功能分组 |
|---|---|---|---|
| 0x10 | 诊断会话控制 | 强制 | 诊断管理 |
| 0x11 | ECU复位 | 强制 | 诊断管理 |
| 0x27 | 安全访问 | 可选 | 诊断管理 |
| 0x28 | 通信控制 | 可选 | 诊断管理 |
| 0x3E | Tester Present | 强制 | 诊断管理 |
| 0x22 | 读取数据标识符 | 可选 | 数据访问 |
| 0x2E | 写入数据标识符 | 可选 | 数据访问 |
| 0x23 | 读取内存地址 | 可选 | 数据访问 |
| 0x24 | 读取缩放数据标识符 | 可选 | 数据访问 |
| 0x31 | 例程控制 | 可选 | 程序控制 |
| 0x34 | 请求下载 | 可选 | 程序控制 |
| 0x35 | 请求上传 | 可选 | 程序控制 |
| 0x36 | 传输数据 | 可选 | 程序控制 |
| 0x37 | 请求传输退出 | 可选 | 程序控制 |
| 0x19 | 读取DTC信息 | 可选 | 故障诊断 |
| 0x14 | 清除诊断信息 | 可选 | 故障诊断 |
避坑指南：我曾经在0x34（请求下载）的实现上栽过跟头。当时没注意它和0x36（传输数据）的配合关系，导致刷写时数据包顺序乱了。记住：请求下载只是“握手”，真正的数据搬运靠0x36。
嗯，这里要注意：SID的命名虽然看起来复杂，但规律性很强。比如0x2X系列都是数据访问，0x3X系列都是程序控制。你只要记住这个规律，看到SID就能猜出它大概干什么。
最后，我建议你把这个表格做成一个速查卡。调试时遇到不认识的服务，扫一眼就能定位。我自己就在IDE里贴了一张，省了不少翻规范的时间。