把服务发现协议SD落到关键对象的触发条件、可观察状态和复查材料上，先判断问题从哪里收窄。
服务发现协议SD用服务发现协议SD、StopOffer状态机、实现服务发现状态机连接到服务发现协议SD的调试、验证和交付动作。
在 SOME/IP 多 ECU 通信中，服务发现协议（Service Discovery, SD）是节点间建立会话的“握手层”。若状态机设计不当，轻则服务注册延迟，重则引发全网广播风暴。本节聚焦 Offer/Subscribe/StopOffer 三个核心状态的触发条件、超时参数配置及调试验证，确保 ECU 交付物在实车网络中具备稳定的服务发现能力
服务发现状态机的核心矛盾在于“快速发现”与“网络负载”的平衡。Offer 重发间隔过短会引发广播风暴，Subscribe 超时过长则导致服务切换迟钝。工程实践中，OfferCyclicDelay 推荐值 1000-2000 ms，SubscribeResponseTimeout 推荐值 500-1000 ms
服务发现协议SD落地前要同时核对服务发现协议SD的StopOffer状态机、失败路径和实现服务发现状态机。
图表解读：对应正文“Offer/Subscribe/StopOffer 状态机触发与超时参数配置”。这张图以最终 Mermaid 图中的真实节点为准，先观察“服务发现协议SD：Offer/Subscribe/StopOffer状态机与超时”的主链。读图顺序：ECU指向SD；SD指向ECU；SD指向Offer；Offer指向SD
节点说明：【服务发现协议】表示可观察对象，标出该节点在主线中的位置；检查重点：相关操作、判断条件或常见问题。
服务发现状态机由三个主状态构成：Offer（服务提供方宣告可用）、Subscribe（服务消费方请求订阅）、StopOffer（服务提供方停止宣告）。每个状态均包含启动条件、重试逻辑与超时回退机制
以服务提供方（ECU-A）为例，其状态机触发路径如下：
Service::OnAvailable 回调触发），ECU-A 立即发送 Offer 报文。若未收到任何 Subscribe 应答，则在 OfferCyclicDelay 超时后重发，最大重试次数由 OfferMaxRepetitions 控制（通常 3-5 次）SubscribeResponseTimeout。若超时未收到 SubscribeAck，ECU-B 重发 Subscribe，重试次数由 SubscribeMaxRetries 限制（通常 2-3 次）TTL（生存时间）内未收到新的 Offer 或 SubscribeAck，则自动将服务标记为不可用以下为关键超时参数表，供 SD 调试验证阶段对照检查：
| 检查项 | 标准 | 是否通过 | 常见遗漏 |
|---|---|---|---|
| OfferCyclicDelay | 1000-2000 ms | 控制 Offer 报文重发间隔 | 过短→广播风暴；过长→服务发现延迟 |
| SubscribeResponseTimeout | 500-1000 ms | 等待 SubscribeAck 的超时 | 过短→误判服务不可用；过长→切换迟钝 |
| TTL | 3000-5000 ms | 服务生存时间，超时后自动移除 | 过短→服务频繁抖动；过长→僵尸服务 |
| OfferMaxRepetitions | 3-5 次 | 最大 Offer 重发次数 | 限制广播风暴上限 |
在 SOME/IP 调试验证阶段，使用 Wireshark 过滤 someip-sd 报文，重点检查 Offer 报文中的 TTL 字段与 SubscribeAck 的响应时间。若发现连续 3 次以上 Offer 重发后仍无 Subscribe，应优先排查消费方的网络可达性与服务 ID 匹配
SD 调试验证的核心交付物包括：服务发现协议栈配置表、状态机日志记录、网络抓包文件。以下为 ECU 交付物检查清单，用于验收阶段逐项确认：
在某 ADAS 域控制器与网关的联调中，网关（ECU-B）持续无法订阅到域控制器（ECU-A）的感知服务。抓包发现 ECU-A 的 Offer 报文正常发送，但 ECU-B 的 Subscribe 报文始终未触发。排查发现 ECU-B 的 SubscribeResponseTimeout 配置为 200 ms，而 ECU-A 因高负载导致 SubscribeAck 响应延迟 300 ms。将超时调整为 500 ms 后，订阅成功建立
服务发现协议最常见的故障模式是网络风暴与状态机死锁。前者由 Offer/Subscribe 重发间隔过短或重试次数过大引发；后者常因 TTL 与重试超时参数不匹配导致双方互相等待
判断标准如下：
OfferCyclicDelay 小于 500 ms，则广播报文将占用超过 30% 的网络带宽。此时应增大间隔或启用随机延迟（Jitter）TTL 小于 ECU-B 的 SubscribeResponseTimeout 时，ECU-B 可能在等待 SubscribeAck 期间将服务标记为不可用，导致订阅永远无法完成。工程约束：TTL > SubscribeResponseTimeout × 2部分开发者在配置 OfferCyclicDelay 时直接套用 AUTOSAR 默认值 1000 ms，却未考虑实际网络带宽。在 100Base-T1 车载网络中，若 20 个 ECU 同时发送 Offer，每 1000 ms 产生 20 个广播帧，带宽占用仅 0.2%，安全；但在 CAN FD 网络中，同样配置将导致总线负载超过 60%。因此，参数配置必须结合物理层特性
在 Offer 调试验证与 Subscribe 交付物验收阶段，建议使用以下命令片段快速验证状态机行为：
# 使用 tshark 过滤 SOME/IP-SD 报文，提取 Offer 与 Subscribe 交互 tshark -r sd_trace.pcapng -Y "someip-sd" -T fields -e someip-sd.entry_type -e someip-sd.ttl -e someip-sd.接口
该命令输出每个 SD 报文的条目类型（Offer=0x01, Subscribe=0x06, StopOffer=0x04）、TTL 值与接口。若发现连续 5 个 Offer 报文后仍无 Subscribe 条目，应优先检查消费方的服务 ID 与实例 ID 是否匹配，而非盲目调整超时参数
服务发现协议SD的细节补充应直接说明可复查对象：先确认现场任务对应的输入、输出和结果材料，再用IP多ECU通信开发实战训练解释哪一处条件会影响判断。
服务发现协议SD的主要风险来自服务发现协议SD边界、状态和验证口径不清；落地前先核对示例片段，并确认例外场景和结果记录。
如果把服务发现协议SD放到陌生问题里，先不要套结论，先确认SOME/IP多ECU通信、训练和指标对照卡谁是原因、谁是约束、谁是结果。可观察信号可以作为校验点：它能解释当前变化，说明机制链路还完整；解释不了，就回到服务发现协议SD补前提。这样的收束更适合理解型课程，因为它留下的是判断方法，不是固定步骤，也不是孤立名词。遇到相邻章节结论冲突时，不直接替换答案，先对照服务发现协议SD与方法框架，再确认训练记录的是原因、过程还是结果。第04节的交接重点是概念联动，它决定训练是短暂波动还是可复现证据。