UDS中Transfer data service(0x36)未发0x78 NRC及响应时机问询

核心结论 #

• 待处理响应（0x78 NRC，即pending响应）必须在P2Server计时窗口内发送，而P2Server的计时起点是服务器成功接收并确认请求帧的时刻（即确认帧ack发送完成后），而非客户端发送请求帧的时刻。
• 若服务器无法在P2Server时长内准备好最终响应，必须先返回0x78延长响应时间，之后再发送最终响应（如0x24 NRC）；直接跳过0x78超时后返回其他NRC属于不符合UDS规范的行为。

场景对应分析 #

1. 你的测试中，从确认帧ack开始计时，最终NRC响应在20ms以内（符合25ms要求），但服务器未返回0x78反而在180ms后返回0x24，问题出在服务器的计时逻辑错误：它误将客户端发送请求帧的时刻作为P2Server的计时起点，导致误判自己无法在25ms内完成响应，却未触发0x78发送流程，直接延迟返回了最终NRC。
2. 根据UDS ISO 14229规范，P2Server的定义是服务器成功接收请求后，到发送响应（含pending响应）的最大允许时间差，这里的“成功接收”指服务器完成请求帧的确认（ack帧发送完成），只有此时服务器才完成请求接收同步，计时才具备合理性。

排查方向 #

• 核查服务器端计时触发逻辑，确认是否将ack帧发送时刻作为P2Server计时的起点。
• 验证服务器在检测到无法在P2Server内完成响应时，是否会优先触发0x78 NRC的发送流程，而非直接延迟返回最终响应。

内容的提问来源于stack exchange，提问作者Romulus