2、UDS协议栈架构：应用层、会话层、网络层（ISO 15765-2）的分层设计

大家好，我是老张。今天我们来聊聊UDS协议栈的分层架构。说实话，很多刚入行的工程师一上来就啃协议栈源码，结果被各种层之间的交互搞得晕头转向。我个人习惯是，先搞清楚每一层到底干什么，再看它们怎么配合。

UDS协议栈，说白了就是一套分层通信的规矩。它把复杂的诊断通信拆成了三个层次：应用层、会话层、网络层。每一层各司其职，互不干扰。你想想看，要是所有逻辑都揉在一起，调试起来得多痛苦？

2.1 为什么需要分层？

我在项目中遇到过这样一个场景：某次调试，ECU死活不响应诊断请求。我一开始怀疑是应用层逻辑写错了，查了半天发现没问题。后来一层层往下查，才发现是网络层的数据包长度算错了。要是没有分层，这种问题排查起来简直是大海捞针。

分层设计的好处很明显：

• 职责清晰：每层只管自己的事，不越界
• 便于调试：出问题了，能快速定位到具体层
• 易于复用：换一个底层总线，上层代码基本不用动
• 标准化：各层接口固定，不同厂商的代码也能对接

2.2 应用层（Application Layer）

应用层，就是咱们平时写诊断服务代码的地方。比如0x10（诊断会话控制）、0x22（读取数据）、0x2E（写入数据）这些服务，都在这一层实现。

应用层的职责很纯粹：

• 解析收到的诊断请求，判断是哪个服务
• 执行对应的业务逻辑（比如读DTC、写参数）
• 组装响应报文，返回给会话层

嗯，这里要注意：应用层完全不关心数据是怎么发过来的。它只知道自己收到了一个请求，然后给出一个响应。至于这个请求是CAN发来的还是LIN发来的，应用层一概不管。

举个例子，你写一个0x22服务：

// 伪代码：应用层处理0x22服务
void Handle_ReadDataByIdentifier(uint8_t* request, uint16_t length) {
    // 解析DID（数据标识符）
    uint16_t did = (request[0] << 8) | request[1];
    
    // 根据DID读取对应的数据
    uint8_t data[8];
    bool success = ReadDataByDID(did, data);
    
    if (success) {
        // 组装正响应
        BuildPositiveResponse(0x62, did, data);
    } else {
        // 组装负响应
        BuildNegativeResponse(0x7F, 0x22, NRC_GeneralReject);
    }
}

你看，这段代码里完全没有CAN帧、没有网络层地址、没有分段传输。这就是应用层该有的样子。

2.3 会话层（Session Layer）

会话层，很多人容易忽略它。其实这一层挺重要的，它负责管理诊断会话的状态。

会话层主要干三件事：

• 会话状态管理：默认会话、扩展会话、编程会话之间的切换
• 安全访问控制：解锁种子和密钥的校验
• 定时监控：S3定时器，防止会话超时

我记得有一次，客户反馈说ECU总是莫名其妙退出诊断模式。我查了半天，发现是会话层的S3定时器没处理好。默认会话的超时时间设得太短，稍微慢一点就超时了。后来我把超时时间从2秒改到5秒，问题就解决了。

会话层在应用层和网络层之间，起了一个承上启下的作用。它从网络层拿到数据，判断当前会话状态是否允许执行这个服务，然后再交给应用层处理。

2.4 网络层（Network Layer - ISO 15765-2）

网络层，也叫传输层，是UDS协议栈里最底层的部分。它遵循ISO 15765-2标准，负责把诊断数据打包成CAN帧发出去，或者把收到的CAN帧组装成完整的诊断消息。

网络层的核心功能：

• 单帧传输：数据长度不超过7字节时，一帧搞定
• 多帧传输：数据超过7字节时，拆成多个CAN帧发送
• 流控制：发送方和接收方协调节奏，防止丢帧
• 地址处理：物理寻址和功能寻址的区分

你想想看，一个诊断请求可能有几十个字节，但CAN帧一次最多只能发8个字节（数据场）。怎么办？网络层就负责把这些数据切碎，一帧一帧发出去，接收端再拼回来。

多帧传输的流程是这样的：

1. 发送方发第一帧（FF），告诉接收方总共有多少数据
2. 接收方回复流控制帧（FC），告诉发送方可以发了
3. 发送方连续发送后续帧（CF），直到发完
4. 接收方把所有帧拼起来，还原成完整的诊断消息

2.5 三层之间的交互流程

说了这么多，咱们来看看三层是怎么配合的。假设ECU收到一个诊断请求：

步骤	层级	动作
1	网络层	接收CAN帧，判断是单帧还是多帧，组装成完整数据
2	会话层	检查当前会话状态，判断是否允许执行该服务
3	应用层	解析服务ID，执行具体业务逻辑
4	应用层	组装响应数据，交给会话层
5	会话层	更新会话状态（如果需要），把响应交给网络层
6	网络层	把响应数据打包成CAN帧，发送出去

这个流程看起来简单，但实际开发中每个环节都可能出问题。我建议你在写代码时，给每一层都加上日志打印。这样出了问题，看一眼日志就知道是哪一层卡住了。

2.6 各层职责总结

最后，我用一张表总结一下各层的职责：

层级	核心职责	典型问题
应用层	诊断服务的解析与执行	服务ID写错、NRC返回不对
会话层	会话状态管理、安全访问、定时监控	会话超时、种子密钥不匹配
网络层	数据打包/解包、多帧传输、流控制	帧丢失、流控参数配置错误

嗯，这就是UDS协议栈的分层架构。说白了，每一层都有自己的活要干，别越界。你写应用层代码时，别去操心CAN帧怎么发；写网络层代码时，也别去管诊断服务是什么含义。各司其职，代码才能写得清爽。

下一章，咱们会深入网络层，看看ISO 15765-2的具体实现。到时候我会带大家手写一个简单的网络层收发模块，敬请期待。