2026.7.1 车型诊断问题处理

主要是以ISO13400 doip协议栈和ISO14229 2个协议为主一、问题背景台架诊断测试反馈【台架】【诊断测试】【10/10】57 08 诊断调查表不支持实际支持这里的57 08指的是 DID0x5708通常请求报文是22 57 08其中22 ReadDataByIdentifier按 DID 读数据 57 08 DID测试问题的含义是诊断调查表中没有要求支持0x5708但实际 ECU 对22 57 08给了正响应表现为“实际支持”。这会导致测试认为软件实现与诊断调查表不一致。二、协议角度说明根据 ISO 142290x22 ReadDataByIdentifier用于读取某个 DID 的数据。请求格式22 DID_H DID_L例如22 57 08如果 ECU 支持该 DID并且当前会话、安全等级、条件满足则应回复正响应62 57 08 ...如果 ECU 不支持该 DID通常应回复7F 22 31其中7F Negative Response 22 原请求服务 ID 31 requestOutOfRange请求超出范围所以如果诊断调查表明确不支持0x5708那么期望行为应是请求: 22 57 08 响应: 7F 22 31而不是响应: 62 57 08 ...三、当前代码现状本地代码确认0x5708当前确实被注册支持了。协议栈配置中存在0x5708vendor/autolink/infrastructure/doip/source/DIAG/IL/diag_il_cfg.c搜索结果0x5708U, /*D01 Input status(switch signal) 0x22*/这说明 DoIP/UDS 协议栈 DID 支持列表中包含0x5708。当收到22 57 08时协议栈 DID 校验会认为该 DID 是支持的不会在协议栈层返回7F 22 31。业务层也注册了0x5708。在vendor/autolink/midware/diagnosis/diagnosis.h中DID_INPUT_STATUS 0x5708,在vendor/autolink/midware/diagnosis/diagnosis.cpp的FillSupportDiagCmd()中DiagManager::Get().FillSupportDiagData( static_castuint8_t(ServiceId::READ_DATA_BY_IDENTIFIER), DID_INPUT_STATUS );在OnReadDidRequest()中也有对应处理case DID_INPUT_STATUS: DoReadInputSignalResult(response); break;也就是说当前代码从协议栈到业务层都把0x5708当作支持 DID 处理。四、根因分析根因不是协议解析错误也不是 ISO 14229 行为异常而是软件配置与诊断调查表不一致。当前实现链路如下Tester 发送 22 57 08 - DoIP/UDS 协议栈查 g_auDidList - 发现 0x5708 已配置 - DID 支持性校验通过 - 请求转到业务层 - DiagManager 支持表中也注册了 0x5708 - Diagnosis::OnReadDidRequest() 进入 DID_INPUT_STATUS 分支 - DoReadInputSignalResult() 填充响应 - 最终返回 62 57 08 ...因此台架看到“实际支持”是符合当前代码逻辑的。但如果诊断调查表中0x5708已经标记为不支持那么软件应该删除或屏蔽该 DID 的支持配置让请求在 DID 支持性校验阶段失败返回7F 22 31五、处理原则这个问题不应该通过修改响应发送逻辑解决也不应该把所有0x22响应强行改成负响应。正确处理原则是诊断调查表不支持的 DID不应该注册到协议栈 DID 支持列表。 业务层也不应该注册该 DID。也就是说要从“配置支持范围”上修正而不是在响应阶段临时拦截。六、建议修改方向建议分两层处理。第一层DoIP 协议栈配置中移除0x5708文件vendor/autolink/infrastructure/doip/source/DIAG/IL/diag_il_cfg.c找到{ 0x5708U, /*D01 Input status(switch signal) 0x22*/ ... },如果 诊断调查表明确不支持0x5708应将该条目删除或条件编译屏蔽。例如直接屏蔽#if 0 { 0x5708U, /*D01 Input status(switch signal) 0x22*/ ... }, #endif这样协议栈在收到22 57 08时bsl_diag_identifier_verify()查不到该 DID会返回DIAG_RC_ROOR最终响应7F 22 31第二层业务支持表中移除0x5708文件vendor/autolink/midware/diagnosis/diagnosis.cpp当前注册DiagManager::Get().FillSupportDiagData( static_castuint8_t(ServiceId::READ_DATA_BY_IDENTIFIER), DID_INPUT_STATUS );如果诊断调查表不支持应删除或屏蔽该注册#if 0 DiagManager::Get().FillSupportDiagData( static_castuint8_t(ServiceId::READ_DATA_BY_IDENTIFIER), DID_INPUT_STATUS ); #endif同时可以保留DID_INPUT_STATUS枚举和DoReadInputSignalResult()函数不动避免扩大影响范围只是不再把它暴露为支持项。七、为什么优先改协议栈配置对于22 57 08这类 DID 支持性问题最理想的返回路径是在协议栈 DID 校验阶段直接失败DID 不在 g_auDidList - bsl_diag_identifier_verify() 返回 DIAG_RC_ROOR - diag_resp.c 发送 7F 22 31这样行为最清晰也符合“未支持 DID 返回 requestOutOfRange”的诊断预期。如果只改业务层不改协议栈可能出现协议栈认为 DID 支持 业务层没有处理 最终返回 0x22、0x31、超时或其它异常这种行为不如协议栈配置层直接返回7F 22 31稳定。八、验证方法修改后编译镜像在台架发送22 57 08期望响应7F 22 31同时回归相邻 DID确认没有误伤其它 DID22 57 03 22 57 17 22 57 39如果这些 DID 在诊断调查表中仍支持应保持原有响应不变。还需要确认构建产物中确实不再包含0x5708的 DoIP DID 配置。可以通过源码搜索或编译产物验证diag_il_cfg.c 中 g_auDidList 不再注册 0x5708 Diagnosis::FillSupportDiagCmd() 不再注册 DID_INPUT_STATUS九、结论该问题的本质是诊断调查表不支持 0x5708但软件协议栈配置和业务支持表仍注册了 0x5708。因此 ECU 实际返回正响应是当前代码配置导致的不是协议栈解析错误。建议按诊断调查表收敛支持范围DoIP 协议栈 g_auDidList 移除/屏蔽 0x5708 业务 FillSupportDiagCmd() 移除/屏蔽 DID_INPUT_STATUS修改后22 57 08应返回7F 22 31即requestOutOfRange表示该 DID 不在当前 ECU 支持范围内。