诊断会话与扩展会话：不是“开不开权限”，而是“在哪一层设防”
你有没有遇到过这样的现场问题？
产线工程师用CANoe发了一条0x10 0x03，ECU没响应，抓包一看——回了个0x7F 0x10 0x22（Conditions Not Correct）；
售后技师在诊断仪上点“读取标定参数”，界面卡住几秒后报错Security Access Denied (0x33)；
更糟的是，某次调试中刚进扩展会话，ECU突然丢掉所有CAN报文，连0x3E都收不到回应……
这些不是协议栈写错了，也不是CAN物理层坏了。它们都指向一个被很多工程师轻描淡写带过的底层机制：会话控制（Session Control）的语义边界与执行约束。而真正决定诊断行为是否可靠、安全、可追溯的，恰恰不是0x27那几行密钥计算，而是0x10之后那一毫秒内ECU内部状态机的跳转逻辑。
默认会话：ECU的“出厂静默态”，不是“默认能干啥”，而是“默认不准动啥”
很多人以为默认会话就是“啥都不用配，自然就有”。但ISO 14229-1第8.2.1条写得非常清楚：它不是“无状态”，而是“受控的最小状态”。ECU上电后进入默认会话，不是因为开发者没写切换代码，而是诊断栈在初始化阶段就主动将SessionState置为DEFAULT_SESSION——这是一个有明确定义、有资源裁剪、有超时兜底的防御性初始态。
它的本质，是ECU对“外部世界”的第一道信任隔离墙：
- 它不依赖任何安全等级，不是因为“安全不重要”，而是因为连安全校验的入口都不开放；
- 它只允许
0x22读数据，但禁止读0xF1A0（标定表起始地址），不是协议限制，而是OEM在DID定义表里把该DID的AccessLevelMask设为了0x00； - 它的P2=50ms，不是为了“慢”，而是为兼容UART辅助通道、低速LIN或老旧诊断仪预留的通信容错窗口；
- 它甚至会主动屏蔽某些
0x2E写请求——哪怕DID本身在白名单里，只要其属性标记为WriteProtectedInDefaultSession，Dcm模块就会直接返回0x7F 0x2E 0x31（Request Out Of Range）。
📌关键洞察
