主要是以ISO13400 doip协议栈和ISO14229 2个协议为主
一、问题背景
台架诊断测试反馈：
【台架】【诊断测试】【10/10】57 08 诊断调查表不支持，实际支持这里的57 08指的是 DID：
0x5708通常请求报文是：
22 57 08其中：
22 = ReadDataByIdentifier，按 DID 读数据 57 08 = DID测试问题的含义是：诊断调查表中没有要求支持0x5708，但实际 ECU 对22 57 08给了正响应，表现为“实际支持”。这会导致测试认为软件实现与诊断调查表不一致。
二、协议角度说明
根据 ISO 14229，0x22 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当前确实被注册支持了。
协议栈配置中存在0x5708：
vendor/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_cast<uint8_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_cast<uint8_t>(ServiceId::READ_DATA_BY_IDENTIFIER), DID_INPUT_STATUS );如果诊断调查表不支持，应删除或屏蔽该注册：
#if 0 DiagManager::Get().FillSupportDiagData( static_cast<uint8_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，确认没有误伤其它 DID：
22 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 支持范围内。
)
