71 DCM与PduR的“路由迷宫”：如何从0x22请求到应用层响应的完整路径
“老王，昨晚产线上又堵死了三台ECU！”凌晨两点，小李在电话里急得声音发颤——新批次的UDS诊断仪同时发起了0x22读取VIN码和0x2E写入配置的请求，结果两台ECU都卡在“请求-响应”的死锁中，连TP层重传都救不回来。
我盯着CANalyzer抓到的报文，发现所有请求都堆在PduR的同一个端口上，DCM根本没收到任何数据。
这不是硬件故障，是软件层面的“路由迷宫”——诊断请求从CAN总线进入后，要经过PduR（PDU路由器）的端口映射、DCM（诊断通信管理器）的协议解析，最终才能触达应用层。任何一步的优先级或缓冲配置失误，都会导致请求“迷路”。
痛点拆解：你以为的“直通路径”其实是个迷宫
常见错误1：把PduR当成“透明管道”
很多人认为诊断请求从CAN接口进来后，直接通过PduR传给DCM就行。但PduR实际是一个“多路复用器”——它要同时处理网络管理报文、XCP测量报文、诊断请求等不同优先级的PDU。
如果你把所有诊断请求都塞进同一个“邮箱”（即同一个PDU ID），高优先级的0x22请求会被低优先级的0x2E响应阻塞。
反例代码（错误实现）：
# 伪代码：错误地将所有诊断PDU绑定到同一端口
