第2章：UDS协议基础：协议栈架构、OSI七层模型与UDS服务分类
各位同学，欢迎来到第二章。上一章我们聊了诊断协议的整体面貌，这一章咱们要扎进去，看看UDS协议栈到底是怎么搭起来的。说实话，UDS协议栈的架构，是很多工程师容易忽略但又极其重要的基础。你想想看，如果连协议栈的层次都搞不清楚，后面排查问题的时候，就像在黑夜里找东西，全靠瞎摸。
2.1 UDS协议栈架构：从物理层到应用层
UDS协议栈，说白了就是一套分层通信的规则。它基于OSI七层模型，但实际应用中，我们通常只关心其中的几层。我个人习惯把UDS协议栈分成三个核心层次：传输层、网络层和应用层。
为什么这么分？因为诊断仪和ECU之间的对话，本质上就是“发请求-收响应”的过程。但这个过程不是直接扔数据就完事的，中间要经过层层封装和解封装。
核心要点：UDS协议栈的每一层都有明确的职责，不能越级。我曾经在项目中遇到过一位同事，直接在应用层修改了网络层的参数，结果导致整个诊断会话无法建立。嗯，这个坑我踩过，你们别踩。
2.2 OSI七层模型在诊断中的应用
OSI七层模型，大家在学校都学过。但在诊断领域，我们真正打交道的只有下面几层。我列个表格，大家看得更清楚：
| OSI层 | 诊断中的角色 | 常见协议/标准 |
|---|---|---|
| 应用层（第7层） | UDS服务本身，如读取数据、写入数据 | ISO 14229-1 |
| 表示层（第6层） | 数据编码与格式化 | 通常与应用层合并 |
| 会话层（第5层） | 会话管理，如诊断会话控制 | ISO 14229-2 |
| 传输层（第4层） | 数据分段与重组，保证可靠传输 | ISO 15765-2（DoCAN） |
| 网络层（第3层） | 寻址与路由，如CAN ID的分配 | ISO 15765-2 |
| 数据链路层（第2层） | 帧的封装与错误检测 | CAN 2.0 / CAN FD |
| 物理层（第1层） | 电气信号与物理连接 | ISO 11898 |
你看，从物理层到应用层，每一层都在做自己的事。我记得有一次调试一个CAN总线通信问题，怎么都收不到响应。查了半天，最后发现是物理层的终端电阻没焊好。你说冤不冤？但这就是现实，每一层都不能掉链子。
2.3 UDS服务分类：强制与可选
UDS服务，按照ISO 14229-1的定义，分为强制服务和可选服务。强制服务是每个ECU都必须支持的，可选服务则根据ECU的功能需求来决定。
为什么会这样设计？你想想看，如果所有ECU都支持所有服务，那存储空间和计算资源根本扛不住。所以标准制定者很聪明，把最核心的诊断功能定为强制，其他的留给开发者自己选择。
2.3.1 强制服务（Mandatory Services）
强制服务，说白了就是ECU的“诊断基本功”。如果一个ECU连这些服务都不支持，那它就不符合UDS规范。我个人习惯把强制服务称为“诊断三件套”：
- 诊断会话控制（0x10）：用于切换诊断会话模式，比如从默认会话切换到扩展会话或编程会话。
- ECU复位（0x11）：用于复位ECU，比如硬复位或软复位。
- 安全访问（0x27）：用于解锁ECU的安全等级，防止未授权操作。
- 通信控制（0x28）：用于控制ECU的通信行为，比如禁用或启用某些报文。
- 测试仪在线（0x3E）：用于保持诊断会话的激活状态，防止超时退出。
- 读取数据（0x22）：用于读取ECU内部的数据，比如传感器值或状态信息。
- 写入数据（0x2E）：用于写入数据到ECU，比如配置参数。
- 清除诊断信息（0x14）：用于清除ECU中存储的故障码。
- 读取故障码（0x19）：用于读取ECU中存储的故障码信息。
个人经验：我曾经在项目中遇到一个ECU，它不支持0x3E服务。结果每次诊断会话都会在30秒后自动退出，搞得测试人员很崩溃。后来我们强制加上了这个服务，问题就解决了。所以，强制服务真的不能省。
2.3.2 可选服务（Optional Services）
可选服务，顾名思义，ECU可以根据自身需求选择是否支持。常见的可选服务包括：
- 例程控制（0x31）：用于执行ECU内部的特定例程，比如自检或校准。
- 请求下载（0x34）：用于启动固件下载流程。
- 请求上传（0x35）：用于启动固件上传流程。
- 传输数据（0x36）：用于在下载或上传过程中传输数据块。
- 请求传输退出（0x37）：用于结束数据传输流程。
- 输入输出控制（0x2F）：用于控制ECU的输入输出引脚，比如强制某个引脚输出高电平。
- 读取扩展数据（0x22的扩展）：用于读取更复杂的数据结构。
嗯，这里要注意，可选服务虽然叫“可选”，但如果你要支持某个功能，对应的服务就必须实现。比如你要做OTA升级，那0x34、0x36、0x37这些服务一个都不能少。
2.4 服务分类的实战意义
你可能会问，知道这些分类有什么用？我告诉你，用处大了去了。在项目开发中，我们经常需要编写ECU的诊断规范文档。这时候，强制服务和可选服务的分类就是你的“清单”。
我曾经参与过一个项目，客户要求ECU支持所有UDS服务。我当时就笑了，直接告诉他们：强制服务必须支持，可选服务根据功能需求来定。最后我们只实现了十几个服务，既满足了功能需求，又节省了资源。
避坑指南：千万不要为了“省事”而省略强制服务。我曾经见过一个团队，为了赶进度，把0x3E服务给省略了。结果在整车测试时，诊断会话频繁超时，最后不得不返工。记住，强制服务是底线，不能碰。
2.5 小结
这一章我们聊了UDS协议栈的架构、OSI七层模型在诊断中的应用，以及UDS服务的分类。说白了，UDS协议栈就是一套分层通信的规则，每一层都有自己的职责。强制服务是ECU的“诊断基本功”，可选服务则根据功能需求来定。
下一章，我们会深入讲解UDS的报文格式和寻址方式。到时候，我会带大家手撕一个实际的诊断报文，看看数据到底是怎么在总线上跑的。嗯，敬请期待。