4、诊断会话控制(0x10)：默认会话、编程会话、扩展会话的切换逻辑

大家好，我是老张。今天我们来聊聊UDS诊断里一个非常基础但又极其重要的服务——0x10 诊断会话控制。说白了，它就是ECU的“工作模式切换器”。你想想看，ECU不可能永远用一种状态干活，平时跑着要省电，刷写时要开放权限，调试时要解锁更多功能。这三种状态，就是通过0x10服务来切换的。

我个人习惯把会话控制比作“门禁系统”。默认会话是普通员工卡，只能进大厅；编程会话是VIP卡，能进核心机房；扩展会话是管理员卡，能进设备间调参数。嗯，这个比喻虽然糙了点，但道理是一样的。

4.1 三种会话的定义与用途

先明确一下三种会话各自是干什么的。我在项目中遇到过不少新手，上来就问“为什么我发0x22读数据读不到？”——多半是会话没切对。

这里有个关键点：默认会话是唯一一个“非主动请求”就能进入的会话。ECU上电后，或者会话超时后，都会自动回到默认会话。我刚开始做UDS时，就因为这个自动回退机制吃过亏——调试到一半，去喝了杯咖啡，回来发现会话已经切回去了，所有诊断请求都报错。嗯，从那以后我养成了一个习惯：每次发诊断请求前，先确认当前会话状态。

4.2 会话切换的请求与响应格式

0x10服务的报文格式非常简洁。请求报文就两个字节：0x10 + sub-function。响应报文也是两个字节：0x50 + sub-function。你可能会问，为什么响应是0x50而不是0x10？这是UDS的规矩——肯定响应SID = 请求SID + 0x40。

// 切换到编程会话
发送: 0x10 0x02
接收: 0x50 0x02  // 肯定响应

// 切换到扩展会话
发送: 0x10 0x03
接收: 0x50 0x03  // 肯定响应

// 切回默认会话
发送: 0x10 0x01
接收: 0x50 0x01  // 肯定响应

当然，不是每次都能成功。如果当前条件不允许切换，ECU会返回否定响应。比如，你在编程会话中正在刷写数据，这时候想切回默认会话，ECU可能会拒绝——因为刷写还没完成。

4.3 会话切换的约束条件

这里我要重点讲一下切换逻辑。很多初学者以为会话可以随便切，其实不然。我总结了几条“铁律”：

• 默认会话 → 任何会话：都可以。默认会话是“起点”，没有限制。
• 编程会话 → 默认会话：可以。但要注意，如果正在刷写，必须先终止刷写流程。
• 编程会话 → 扩展会话：不可以。编程会话是“单向门”，只能切回默认会话。
• 扩展会话 → 编程会话：可以。但通常需要先通过安全访问（0x27服务）解锁。
• 扩展会话 → 默认会话：可以。没有限制。

4.4 会话超时机制

这个机制我觉得是UDS里最容易被忽视的。每个非默认会话都有一个超时时间（S3 Server timeout）。如果在这个时间内没有收到任何诊断请求，ECU会自动切回默认会话。

标准规定，S3超时时间一般是5秒。但实际项目中，我见过3秒的，也见过10秒的。这个值通常在ECU的配置文件中定义。我个人建议：不要设得太短，否则刷写过程中稍微慢一点就会超时；也不要设得太长，否则会占用资源。

4.5 实际项目中的切换逻辑实现

好了，理论讲完了，我们来看看代码怎么实现。下面是一个简化的会话切换逻辑，我用C语言写的，大家感受一下。

// 会话状态枚举
typedef enum {
    SESSION_DEFAULT = 0x01,
    SESSION_PROGRAMMING = 0x02,
    SESSION_EXTENDED = 0x03
} SessionType;

// 当前会话状态
static SessionType currentSession = SESSION_DEFAULT;

// 会话切换函数
UdsResponse handleSessionControl(uint8_t subFunction) {
    // 检查当前会话是否允许切换
    if (!isTransitionAllowed(currentSession, subFunction)) {
        return NRC_CONDITIONS_NOT_CORRECT;  // 0x22
    }

    // 执行切换前的清理工作
    if (currentSession == SESSION_PROGRAMMING) {
        // 关闭刷写相关资源
        closeProgrammingResources();
    }

    // 更新会话状态
    currentSession = (SessionType)subFunction;

    // 启动超时定时器（仅非默认会话）
    if (currentSession != SESSION_DEFAULT) {
        startS3Timer(S3_TIMEOUT_MS);
    }

    return RESPONSE_OK;
}

// 检查切换是否允许
bool isTransitionAllowed(SessionType from, SessionType to) {
    // 默认会话可以切到任何会话
    if (from == SESSION_DEFAULT) return true;

    // 编程会话只能切回默认
    if (from == SESSION_PROGRAMMING) {
        return (to == SESSION_DEFAULT);
    }

    // 扩展会话可以切到编程或默认
    if (from == SESSION_EXTENDED) {
        return (to == SESSION_PROGRAMMING || to == SESSION_DEFAULT);
    }

    return false;
}

这段代码看起来简单，但实际项目中要考虑的细节远不止这些。比如，切换编程会话时，是否需要先通过安全访问？扩展会话切到编程会话时，是否需要重新初始化某些外设？这些都要根据具体需求来定。

4.6 避坑指南

最后，我分享几个我在项目中踩过的坑，希望能帮大家少走弯路。

• 坑一：会话超时后，没有及时通知应用层。 我曾经有一个项目，ECU在扩展会话中超时切回了默认会话，但应用层还在用扩展会话的权限访问资源，结果导致数据错乱。后来我加了一个回调函数，每次会话切换时通知所有模块。
• 坑二：编程会话中，忽略了Tester Present。 有一次刷写过程中，刷写工具发送数据块的速度太慢，导致S3超时，ECU自动切回了默认会话。刷写工具还在傻等响应，结果超时失败。从那以后，我要求所有刷写工具必须定期发送0x3E。
• 坑三：扩展会话中，没有正确处理安全访问状态。 有些ECU在扩展会话中解锁了安全访问，但切回默认会话后，安全访问状态没有重置。这会导致安全隐患。我建议：每次会话切换时，都重置安全访问状态。

好了，关于0x10诊断会话控制，今天就聊到这里。下一章我们会讲0x27安全访问服务，到时候再跟大家分享一些“解锁”的技巧。记住一句话：会话控制是UDS的基石，搞不懂它，后面的所有诊断服务都是空中楼阁。