把服务发现机制落到关键对象的触发条件、可观察状态和复查材料上，先判断问题从哪里收窄。
在车载以太网通信中，服务发现（Service Discovery, SD）是动态建立通信关系的核心环节。本节聚焦于通过Wireshark抓取SOME/IP-SD报文，验证车载网关与ECU之间的服务发现状态机转换。你将掌握如何从报文中识别Offer/Subscribe交互，并确认状态机是否按AUTOSAR规范正确流转
在实车或测试台架上，将Wireshark配置为监控车载网关的以太网端口，过滤条件设为someip-sd。启动网关与目标ECU后，观察Offer Service与Subscribe Eventgroup报文的时序与标志位，这是验证服务发现状态机的第一手证据
服务发现机制用服务发现机制、Subscribe报文抓包、状态机验证连接到服务发现机制的调试、验证和交付动作。
服务发现机制（SOME/IP-SD）定义了服务提供者（Server）与消费者（Client）之间的状态转换规范。若状态机实现有误，会导致服务订阅失败、通信超时或网络风暴。本节的核心目标是：通过抓包验证车载网关的SOME/IP状态机验证是否覆盖了Initial Wait、Repetition、Main和Termination阶段，并确认Offer/Subscribe调试验证中报文类型、TTL（Time to Live）和Entry ID的匹配关系
状态机验证不能仅依赖日志打印，必须通过Wireshark抓取原始报文，核对Entry Type（0x00表示Offer，0x06表示Subscribe）和TTL字段。TTL归零意味着服务或订阅进入终止状态，是判断状态机是否正常释放资源的关键信号
服务发现机制落地前要同时核对服务发现机制的Subscribe报文抓包、失败路径和状态机验证。
SOME/IP-SD状态机包含四个主要阶段：Initial Wait（启动后等待）、Repetition（重复发送Offer）、Main（稳定期，按周期发送Offer）和Termination（TTL超时后停止）。车载网关作为服务提供者，在Main阶段收到客户端的Subscribe Eventgroup后，应回复Subscribe Ack，并开始发送事件报文
someip-sd过滤器，捕获所有SD报文Entry Type为0x00的报文，确认Service ID、Instance ID和TTL（通常为3秒或5秒）Entry Type为0x06的报文，包含Eventgroup IDMain阶段，若客户端未收到Subscribe Ack，则状态机可能卡在Repetition阶段在某Tier 1供应商的网关项目中，客户反馈空调控制服务偶发不可用。通过Wireshark抓包发现，网关在Main阶段发送的Offer报文TTL被错误地设为0，导致客户端认为服务已终止，不断发起Subscribe请求，形成订阅风暴。修复TTL配置后，状态机恢复正常
服务发现机制是否合格，要看车载网关SOME/IP通信是否进入真实处理链路，以及可观察信号能不能说明结果不是偶然通过。如果指标对照卡和服务发现机制给出的信息互相矛盾，先暂停扩大范围，把结果材料补成一份能复查的最小材料。继续推进前只保留一个判断重点：哪一项条件最先改变结论，再围绕关键对象决定补测、调参还是重新划定验收边界。下次迁移到新现场时，优先比较服务发现机制和项目成果是否同源；如果指标对照卡偏离，就回到服务发现机制补一条可复查证据。第04节后续复用时，不复述整段结论，只检查项目成果、指标对照卡和服务发现机制是否仍然同向。