把SOME落到关键对象的触发条件、可观察状态和复查材料上，先判断问题从哪里收窄。
记录输入、环境、时序或操作动作，先保留现场证据。
优先保留日志、返回码、状态位或波形片段。
把命令、配置和日志放到同一时间窗口，再只调整一个会改变链路状态的条件。
把返回码、计数器和吞吐变化分开留存，避免把一次偶然恢复当成结论。
SOME落地前要同时核对IP服务发现的报文结构、失败路径和状态机解析。
SOME用IP服务发现、报文结构、状态机解析连接到IP服务发现的调试、验证和交付动作。
图表解读：对应正文“服务发现（SD）报文拆解：从Find到StopSubscribe的故障定位路径”。这张图以最终 Mermaid 图中的真实节点为准，先观察“SOME/IP服务发现（SD）报文结构与状态机解析”的主链。读图顺序：UDS调试验证指向SD交付物；SD交付物指向UDS调试验证；SD交付物指向cribe；cribe指向SD交付物
节点说明：【SOMEIP节点】表示可观察对象，标出该节点在主线中的位置；检查重点：相关操作、判断条件或常见问题。
在SOME/IP（Scalable service-Oriented MiddlewarE over IP）诊断通信与UDS（Unified Diagnostic Services）集成开发中，服务发现（Service Discovery, SD）报文是建立通信会话的“握手信号”。当UDS调试验证失败时，超过70%的根因可追溯到SD阶段——要么是Find/Offer报文未匹配，要么是Subscribe/StopSubscribe状态机异常。本节聚焦于四种核心报文的触发条件、关键检查点与判定标准，帮助你在集成测试中快速定位故障
SD报文不是简单的广播，而是状态机驱动的有限状态机（FSM）。Find报文由客户端（Client）发起，用于探测服务实例；Offer报文由服务端（Server）响应，宣告可用性；Subscribe报文确认订阅关系；StopSubscribe报文则用于优雅释放。任何一步的报文丢失或超时，都会导致UDS诊断会话无法建立
SD状态机遵循AUTOSAR规范，核心状态包括：INIT（初始化）、WAITING（等待）、AVAILABLE（可用）、SUBSCRIBED（已订阅）。故障排查的关键在于理解状态转换的触发条件与超时参数
以Find/Offer交互为例：客户端在INIT状态发送Find报文，启动T_FIND定时器（默认1秒）。若在超时前收到匹配的Offer报文，状态迁移至AVAILABLE；否则触发重传，最多重试MAX_FIND_RETRIES（通常3次）。若重传后仍无响应，则判定服务不可达，UDS诊断会话失败
在某OEM的UDS刷写集成测试中，诊断仪（客户端）发送Find报文后始终未收到ECU（服务端）的Offer。排查发现：ECU的SD_Offer_Delay参数配置为5秒，而诊断仪的T_FIND超时仅2秒。调整超时参数后，SD握手成功，UDS刷写流程正常启动
Subscribe/StopSubscribe的故障模式类似：客户端在AVAILABLE状态发送Subscribe报文，服务端回复ACK或NACK。若收到NACK（如服务实例不可用），客户端应停止重试并记录DTC（Diagnostic Trouble Code）。StopSubscribe报文则用于主动取消订阅，常见于诊断会话切换或ECU复位场景
在UDS调试验证中，需重点检查以下参数：T_FIND（Find超时）、T_OFFER（Offer延迟）、T_SUBSCRIBE（订阅超时）、MAX_RETRIES（最大重试次数）。这些参数通常在配置.xml或ARXML中定义。若发现SD交付物（如DBC或LDF文件）中的参数与实际测试不符，需优先对齐
SD交付物包括：配置.xml（参数配置）、接口.arxml（服务接口定义）、DBC/LDF（信号矩阵）。在UDS集成开发中，这些文件需通过静态验证工具（如Vector CANdelaStudio）检查一致性。以下为SD报文调试的流程日志表，记录典型故障的排查步骤：
| 维度 | 方案A | 方案B | 判断建议 |
|---|---|---|---|
| 1 | 诊断仪发送Find报文 | 捕获CAN/CAN FD总线报文，检查 Service… | 若匹配，继续；否则检查服务配置 |
| 2 | ECU未回复Offer | 检查ECU的 SD_Offer_Delay 与 T_F… | 若参数不一致，更新配置并重测 |
| 3 | 收到Offer但Subscribe失败 | 检查Subscribe报文中的 Eventgroup… | 若未注册，更新ARXML文件 |
| 4 | StopSubscribe后无法重新订阅 | 检查ECU的 SD_State 是否回退至 WAITI… | 若状态卡死，需ECU复位或重新初始化 |
在UDS调试验证中，使用CANoe或PCAN-Explorer的SD窗口实时监控报文交互。若发现Find/Offer不匹配，优先检查Service ID（16位）和Instance ID（16位）是否在配置.xml中正确映射。对于Subscribe失败，需确认Eventgroup ID（8位）与Major Version（8位）的一致性
SD故障的判定需结合状态机与超时参数。以下为判断标准表，用于区分“配置错误”与“通信异常”：
很多开发者误以为StopSubscribe报文是可选操作，但在UDS诊断会话切换（如从默认会话切换到扩展会话）时，若未发送StopSubscribe，ECU可能持续发送Event报文，导致诊断请求被淹没。正确做法：在切换会话前，先发送StopSubscribe释放订阅关系
在UDS集成开发中，SD交付物的验证需包含以下检查清单：Service ID唯一性、Instance ID范围、Eventgroup ID映射、T_FIND与T_OFFER的匹配性。若发现参数冲突，需通过核心步骤交付物（如SD_Validation_Report.xlsx）记录并推动修改。最后，建议在测试环境中使用CANoe SD Simulator模拟服务端行为，验证客户端的超时重传逻辑是否符合预期
SOME的细节补充应直接说明可复查对象：先确认现场任务对应的输入、输出和结果材料，再用IP诊断通信解释哪一处条件会影响判断。
SOME的主要风险来自IP服务发现边界、状态和验证口径不清；落地前先核对示例片段，并确认例外场景和结果记录。
本节的验收可以从失败表现倒推：当可观察信号不符合预期时，先区分是常见偏差没有建立，还是把IP服务发现直接写进主流程影响了输出。合格材料应能说明只验证能跑通在什么条件下成立，并用结果材料留下结果变化，而不是只写“已经完成”。继续实操前先保留一个最小复现入口，再根据留下IP服务发现边界判断问题属于输入、处理过程还是输出结果。本节最值得带走的不是固定句式，而是围绕项目成果建立复查路径：看见把IP服务发现直接写进主流程，找到只验证能跑通，再校验可运行材料的适用边界。第03节的交接重点是可运行材料，它决定把IP服务发现直接写进主流程是短暂波动还是可复现证据。