2、诊断会话控制（0x10）：默认会话、扩展会话、编程会话的切换逻辑与实现

各位同学，咱们今天聊聊UDS里最基础、也最容易被忽视的一个服务——0x10，诊断会话控制。

说实话，我刚入行那会儿，觉得这玩意儿不就是发个指令切个模式嘛，有啥好讲的？直到我在一个量产项目上栽了跟头——ECU死活切不进编程会话，导致远程升级失败，差点让整个产线停摆。嗯，从那以后，我再也不敢小看这个0x10服务了。

2.1 三种会话：你总得选一个待着

UDS协议里定义了三种会话状态，说白了就是ECU的三种工作模式。你想想看，ECU不可能永远用同一套规则跟你打交道——有些操作太危险，必须限制权限。

我个人习惯把这三个会话比作「门禁卡」：默认会话是普通员工卡，只能进大厅；扩展会话是技术员卡，能进设备间；编程会话是管理员卡，连服务器机房都能进。权限越高，风险越大。

2.2 切换逻辑：不是你想切就能切

会话切换不是无条件的。协议规定了几条硬性规则，我当年踩过的坑基本都跟这些规则有关。

2.2.1 切换方向与限制

• 从默认切到扩展：直接发0x10 0x02就行，不需要安全访问。我在项目中经常用这个来做产线终检——读取一些校准参数，不需要解锁。
• 从默认切到编程：同样可以直接切，但大多数BMS厂商会要求先进入扩展会话，再切到编程会话。为什么？因为编程会话通常需要先做安全访问（0x27服务），而安全访问只能在非默认会话下进行。
• 从扩展切到编程：直接发0x10 0x03即可。但注意，如果当前处于某个例程执行中（比如正在做电池均衡），切换会话会导致例程被终止。我曾经遇到过——切会话时没检查例程状态，结果均衡中断，电芯压差报警。
• 从编程切回默认：发0x10 0x01，或者等待会话超时自动回退。

2.2.2 会话超时机制

这个机制我吃过亏。协议规定，非默认会话都有一个超时时间（通常默认是5秒）。如果在这个时间内没有收到任何诊断请求，ECU会自动切回默认会话。

为什么会这样？说白了就是安全考虑——万一诊断仪掉线了，ECU不能一直停留在高权限状态，否则被恶意攻击怎么办？

我记得有一次做台架测试，诊断仪发了个扩展会话指令，然后我去接了个电话，回来发现ECU已经切回默认了。当时我还纳闷：怎么写入参数失败了？后来一查日志，原来是超时了。从那以后，我写代码时都会在循环里加个保活机制——每隔3秒发个0x3E（Tester Present）请求，防止会话超时。

2.3 代码实现：手写一个会话管理器

下面是我在一个BMS项目里实际用过的会话管理代码片段。注意，这不是完整的工程代码，但核心逻辑都在里面了。

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

/* 当前会话状态 */
static SessionType_t currentSession = SESSION_DEFAULT;
static uint32_t sessionTimer = 0;

/* 0x10服务处理函数 */
uint8_t HandleDiagnosticSessionControl(uint8_t subFunction) {
    uint8_t response = 0x00;  /* 正响应 */

    /* 检查子功能是否支持 */
    if (subFunction != SESSION_DEFAULT &&
        subFunction != SESSION_EXTENDED &&
        subFunction != SESSION_PROGRAMMING) {
        return 0x12;  /* NRC：子功能不支持 */
    }

    /* 检查切换是否允许 */
    /* 从编程会话切到其他会话，需要先终止所有例程 */
    if (currentSession == SESSION_PROGRAMMING && 
        subFunction != SESSION_PROGRAMMING) {
        /* 终止正在运行的例程 */
        TerminateAllRoutines();
    }

    /* 执行会话切换 */
    currentSession = subFunction;
    sessionTimer = 0;  /* 重置超时计时器 */

    /* 如果是切到非默认会话，启动超时监控 */
    if (currentSession != SESSION_DEFAULT) {
        StartSessionTimer();
    }

    return response;  /* 返回正响应 */
}

/* 超时监控任务（1ms周期调用） */
void SessionTimerTask(void) {
    if (currentSession == SESSION_DEFAULT) {
        return;  /* 默认会话不需要超时 */
    }

    sessionTimer++;
    if (sessionTimer >= 5000) {  /* 5秒超时 */
        /* 自动切回默认会话 */
        currentSession = SESSION_DEFAULT;
        /* 清除安全访问状态 */
        ClearSecurityAccess();
        /* 通知应用层会话已变更 */
        NotifySessionChange(SESSION_DEFAULT);
    }
}

2.4 避坑指南：我踩过的三个雷

做BMS诊断这几年，我在0x10服务上栽过不少跟头。挑三个典型的说说：

1. 会话切换时没处理DTC状态：有一次我从编程会话切回默认，发现之前清除的DTC又冒出来了。查了半天，原来是切换会话时DTC状态机没复位。记住：会话切换后，DTC的「已确认」状态可能会变化，最好重新读取一下。
2. 多核ECU的会话同步：现在的BMS很多是双核甚至多核架构。我在一个项目里遇到：Core0切到了编程会话，Core1还在默认会话，结果Core1发了个写请求，被拒绝了。解决方案是：所有核共享一个会话状态，切换时广播通知。
3. Bootloader里的会话处理：在Bootloader模式下，0x10服务的实现跟App模式不一样。Bootloader通常只支持默认会话和编程会话，不支持扩展会话。我见过有人直接把App的代码搬到Bootloader里，结果扩展会话请求进来，Bootloader直接死机了。

好了，关于0x10服务就聊这么多。下一章咱们讲安全访问服务（0x27），那个才是真正让人头疼的东西——密钥算法、种子生成、防重放攻击……嗯，到时候再细说。