4. 诊断会话管理：默认会话、编程会话、扩展会话的切换逻辑与状态机设计

各位好，今天我们聊聊诊断会话管理。说实话，这是UDS协议栈里最基础但也最容易踩坑的部分。我见过不少项目，功能逻辑写得挺漂亮，结果会话切换没处理好，整个诊断链路就崩了。嗯，咱们今天就把这块掰开揉碎了讲清楚。

4.1 三种会话的基本定位

UDS定义了三种标准会话：默认会话（Default Session）、编程会话（Programming Session）和扩展会话（Extended Session）。我个人习惯把它们比作三种工作模式：

• 默认会话：上电后的初始状态，说白了就是“待机模式”。只允许读取基本信息和一些标准诊断服务，比如读取DTC、读取数据等。安全性最高，功能最受限。
• 扩展会话：可以理解为“调试模式”。允许执行一些需要更高权限的服务，比如写入数据、例程控制等。我在项目中经常用它来做产线标定和售后刷写前的准备工作。
• 编程会话：这是“刷写模式”。专门用于ECU固件升级。它通常会关闭大部分非必要的通信和功能，确保刷写过程稳定可靠。

4.2 会话切换逻辑：状态机设计

会话切换本质上是一个有限状态机。我给大家画个简单的逻辑图（用文字描述）：

状态：Default, Extended, Programming

允许的切换：
  Default -> Extended  (通过 10 03)
  Default -> Programming (通过 10 02)
  Extended -> Default  (通过 10 01)
  Extended -> Programming (通过 10 02)
  Programming -> Default (通过 10 01)
  Programming -> Extended (通过 10 03)

不允许的切换：
  Extended -> Extended (重复切换，需先回Default)
  Programming -> Programming (同上)

你可能会问：为什么不能直接从Extended切到Extended？其实从协议层面看，重复切换同一个会话是允许的，但实际项目中我建议避免这么做。为什么？因为每次切换都会重置一些内部状态，比如安全访问状态、定时器状态等。我曾经遇到过一个案例，客户在刷写过程中反复切换编程会话，结果导致刷写流程异常中断。嗯，从那以后我就在设计规范里明确写了：会话切换必须走“先回默认，再切目标”的路径。

4.3 状态机实现的关键点

实现会话状态机时，有几个地方特别容易出问题：

• 超时处理：每个会话都有一个S3定时器。默认会话超时后，ECU会进入“非诊断模式”或保持默认会话。但扩展会话和编程会话超时后，必须自动切回默认会话。我见过有人把超时时间设成0，结果ECU刚切进扩展会话就立刻跳回默认，调试时一脸懵。
• 安全访问状态：会话切换会重置安全访问状态。也就是说，你在扩展会话里解锁了安全访问，切回默认再切回来，又得重新解锁。这个设计是为了安全，但很多新手会忽略。
• 服务可用性：不同会话下，可用的诊断服务不同。比如$2E（写入数据）只能在扩展会话或编程会话下执行。如果客户端在默认会话下发$2E，ECU必须回复NRC 0x7F（服务不支持）。

4.4 实际项目中的切换策略

讲个我自己的经验。在做某个量产项目时，客户要求刷写过程中不能中断CAN通信。但编程会话默认会关闭非诊断报文，这就矛盾了。怎么办？

我的方案是：在编程会话下，保留一部分关键报文（比如心跳、网络管理报文），其他报文全部关闭。这样既保证了刷写稳定性，又不会让整车网络误以为ECU掉线了。具体实现就是在状态机的“进入编程会话”动作里，加一个报文过滤表。

另外，会话切换的响应时间也很重要。协议要求ECU在收到$10服务后，必须在50ms内回复响应。如果状态机处理逻辑太复杂，很容易超时。我建议把会话切换做成一个轻量级的原子操作，不要在切换过程中做太多额外工作（比如保存NVM、初始化外设等）。这些可以放到切换完成后的异步任务里去做。

4.5 代码示例：简单的会话状态机

下面是一个简化的状态机实现，用C语言伪代码表示：

typedef enum {
    SESSION_DEFAULT,
    SESSION_EXTENDED,
    SESSION_PROGRAMMING
} SessionType;

static SessionType currentSession = SESSION_DEFAULT;

// 会话切换函数
Std_ReturnType SessionControl(uint8_t sessionId) {
    SessionType targetSession;
    
    // 解析目标会话
    switch(sessionId) {
        case 0x01: targetSession = SESSION_DEFAULT; break;
        case 0x02: targetSession = SESSION_PROGRAMMING; break;
        case 0x03: targetSession = SESSION_EXTENDED; break;
        default: return E_NOT_OK;
    }
    
    // 检查切换是否允许
    if(currentSession == targetSession) {
        // 重复切换，建议先回默认
        return E_NOT_OK;
    }
    
    // 执行切换动作
    // 1. 停止当前会话的S3定时器
    // 2. 重置安全访问状态
    // 3. 更新服务权限表
    // 4. 启动新会话的S3定时器
    // 5. 更新当前会话状态
    
    currentSession = targetSession;
    return E_OK;
}

4.6 总结与建议

会话管理看似简单，但细节决定成败。我最后给大家三个建议：

1. 画好状态机图：在写代码之前，先把所有允许的切换路径画清楚。别漏了边界情况。
2. 测试要覆盖全：每个会话的切换、超时、服务可用性都要测到。我习惯用自动化测试脚本，跑一遍所有可能的切换组合。
3. 留好扩展接口：虽然标准只定义了三种会话，但有些OEM会自定义会话（比如安全会话、工厂会话）。设计状态机时，最好预留一些扩展位。

好了，关于诊断会话管理就聊这么多。下一节我们会讲安全访问机制，那才是真正考验协议栈设计能力的地方。咱们下期见。