AUTOSAR诊断栈实战手记：当UDS请求敲响ECU大门时，发生了什么？
去年冬天调试一个BMS ECU的诊断功能，客户现场用CANoe发0x19读DTC，响应始终超时。抓波形发现CAN帧都收到了，但ECU就是不回。排查三天后才发现——DcmDspSessionLevel配置里漏掉了DCM_SESSION_EXTENDED，而诊断仪默认在Extended会话下发起请求。那一刻我意识到：AUTOSAR诊断不是“配完就能跑”的黑盒，它是层层守卫、环环咬合的精密机制。今天，我们就从一次真实的0x22读取发动机转速开始，拆解这个被无数车厂写进ASIL-B级软件需求的诊断系统。
从一帧CAN报文说起：UDS请求如何唤醒沉睡的ECU
假设诊断仪发出这条CAN帧（标准帧，ID=0x7E0）：
0x7E0: 08 22 F1 01 00 00 00 00前两字节08是DLC，22是SID（ReadDataByIdentifier），F1 01是DID（Engine Speed）。这帧数据穿过物理层后，并不会直接交给应用层——它要先闯过三道关卡：
- MCAL层：CAN Driver收到硬件FIFO中的原始字节，按CAN ID
0x7E0匹配到预定义的CanIfRxPduId； - PduR层：根据
PduR路由表，将该PDU转发给DcmRxPduId对应的上层模块——也就是Dcm； - Dcm入口：Dcm终于拿到这8字节有效载荷，此时真正的协议解析才刚刚开始。
这里有个关键细节常被忽略：Dcm本身不解析CAN协议，它只认PDU内容。也就是说，无论你用CAN、LIN还是以太网传输UDS，只要PduR能正确把字节流送到Dcm手里，上层逻辑完全不用改。这种解耦，正是AUTOSAR架构的底层智慧。
Dcm：诊断协议的“交通指挥中心”
Dcm的名字容易让人误解为“诊断通信管理器”，其实它更像一个协议翻译与任务调度中枢。它不做具体业务，但决定谁来做、何时做、能不能做。
它的第一道判断：这个请求“合法”吗？
- SID合法性检查：查
DcmDspServiceTable表，确认0x22服务是否启用； - 会话权限校验：当前处于Default会话？Extended会话？Programming会话？
DcmDspSessionLevel字段像一把锁，只有钥匙（会话模式）对了，门才开； - 安全等级验证：如果该DID配置了
DCM_SEC_LEV_LOCKED，而当前未通过0x27安全访问，则直接返回
