03 SOME/IP-SD服务发现机制在AUTOSAR AP上的配置与抓包分析

⭐SOME

最小片段或样例检查项

在基于 AUTOSAR Adaptive Platform (AP) 的分布式系统中，服务实例的动态发现与状态维护完全依赖 SOME/IP 服务发现（SOME/IP-SD）协议。开发者常遇到的困惑是：明明配置了服务接口，但客户端（Client）始终收不到服务端（Server）的 Offer 报文，或订阅请求（Subscribe）后得不到响应。这通常不是代码逻辑错误，而是 SOME/IP-SD 配置项与服务发现状态机不匹配。本节将围绕 SOME/IP 服务发现配置（SOME/IP-SD Configuration）的工程要点，通过 Wireshark 抓包分析 Offer/Subscribe 交互，定位配置与网络行为之间的偏差

💻服务发现配置的关键参数与链路

AUTOSAR 服务发现配置（AUTOSAR Service Discovery Configuration）的核心是定义服务实例的发布与订阅行为。在 AP 平台中，服务端需配置 Service ID、Instance ID、Major Version、Minor Version 以及 OfferCyclicDelay（Offer 报文重发周期，单位 ms）。客户端则需配置相同的 Service ID、Instance ID 和，并设置 FindCyclicDelay（Find 报文重发周期）与 InitialDelayMin/InitialDelayMax（启动后首次发送 Find 报文的随机延迟范围）

一条典型的服务发现主链路如下：

1. 服务端启动：服务端在 OfferCyclicDelay 间隔内，组播发送 Offer 报文，宣告 Service ID、Instance ID 及端点信息（IP + Port）
2. 客户端启动：客户端在 InitialDelayMin 至 InitialDelayMax 之间的随机时刻，发送 Find 报文（组播），请求特定 Service ID 的服务实例
3. 匹配与订阅：服务端收到 Find 报文后，若服务 ID 匹配，则单播回复 Offer 报文（或直接等待客户端发送 Subscribe 报文）。客户端收到 Offer 后，发送 Subscribe 报文（单播），请求订阅该服务实例的 Event 或 Method
4. 确认与数据流：服务端回复 SubscribeAck 报文，确认订阅成功。此后，服务端开始向客户端推送 Event 数据或响应 Method 调用

⭐Wireshark 抓包分析：Offer

验证配置正确性的最直接手段是抓包分析。使用 Wireshark 捕获 SOME/IP-SD 报文时，需设置过滤条件 someip-sd 或 udp.port == 30490（SOME/IP-SD 默认端口）。重点关注以下报文序列：

• Offer 报文：检查 Service ID、Instance ID、Major Version 是否与配置一致。若服务端配置了 OfferCyclicDelay = 2000 ms，则 Wireshark 中应每隔约 2 秒出现一条 Offer 报文
• Find 报文：客户端启动后，应在 InitialDelayMin 至 InitialDelayMax 之间发出 Find 报文。若未出现，说明客户端的服务发现模块未正确初始化或网络组播路由未配置
• Subscribe 报文：客户端收到 Offer 后，应发送 Subscribe 报文。若客户端持续发送 Find 报文而不发送 Subscribe，通常是因为客户端配置的 Service ID 或与服务端不匹配

常见异常现象与排查

当抓包发现服务端持续发送 Offer，但客户端始终不发送 Subscribe 时，应优先检查客户端配置的 Service ID 与 Instance ID。若客户端配置了 FindCyclicDelay = 1000 ms，但 Wireshark 中无 Find 报文，则可能是客户端网络栈未绑定到正确的 VLAN 或 IP 地址。此外，部分平台要求客户端在发送 Subscribe 前，必须收到至少一次 Offer 报文；若网络中存在延迟或丢包，客户端可能因超时而放弃订阅