3. SOMEIP-SD 服务发现：服务发现机制、Offer/Find/Subscribe 流程、会话管理
好，咱们今天聊聊 SOMEIP-SD。说实话，这是整个 SOMEIP 协议里最核心、也最容易踩坑的部分。你想想看，一辆车上几十个 ECU，谁提供什么服务、谁需要什么服务，总不能靠人工去配死表吧？SOMEIP-SD 就是干这个的——让节点之间自己“打招呼”、自己“找活儿干”。
3.1 服务发现机制：到底在发现什么？
服务发现，说白了就是两个问题：“谁在提供这个服务？” 和 “谁需要这个服务？”。SOMEIP-SD 用三种报文来解决：OfferService、FindService 和 SubscribeEventgroup。
我个人习惯把服务发现分成两个阶段：
- 初始阶段：节点启动后，不知道自己该找谁，也不知道谁在找自己。
- 稳定阶段：通过周期性报文，维持一个“服务目录”的实时状态。
我记得在做一个 ADAS 域控项目时，有个摄像头节点死活连不上融合算法节点。查了半天，发现是 SD 报文的重复周期没对齐——一个发 100ms，一个等 500ms，你说能碰上吗？
核心要点：SOMEIP-SD 不是“一次发现、永久有效”。它靠的是周期性重发 + 生存时间（TTL）来保证状态新鲜度。TTL 一到，没收到续约报文，服务就视为下线。
3.2 OfferService 流程：服务提供者的“广播”
服务提供者（Server）启动后，会主动发 OfferService 报文。这个报文告诉网络：“嘿，我上线了，我能提供某某服务，谁需要就来找我。”
流程其实很简单：
- Server 进入 Initial Wait Phase，等待一个随机时间（避免所有节点同时发报文造成风暴）。
- 然后进入 Repetition Phase，以递增间隔重复发送
OfferService（比如第一次 100ms，第二次 200ms，第三次 400ms……直到最大值）。 - 最后进入 Main Phase，以固定周期（比如 1000ms）持续发送，维持服务在线状态。
这里有个坑——重复次数和间隔。我曾经在项目中遇到过，某个供应商把重复次数设成了 0，结果服务只发一次 Offer 就停了。客户端如果刚好在那段时间没启动，就永远找不到这个服务。嗯，后来我们在规范里加了硬性要求：重复次数至少 3 次。
实战建议：Initial Wait 的随机范围建议设为 0~100ms，重复间隔的递增因子建议 2.0，最大间隔不超过 1000ms。这样既能快速发现，又不会把总线冲垮。
3.3 FindService 流程：服务消费者的“寻人启事”
客户端（Client）如果不知道某个服务在哪，就发 FindService 报文。这就像在群里喊一嗓子：“谁有某某服务？请回复我。”
流程和 Offer 类似，也有三个阶段：
- Initial Wait：随机等待，避免冲突。
- Repetition Phase：递增间隔重发
FindService。 - Main Phase：周期性发送，持续寻找。
但有个关键区别：FindService 不携带具体的实例信息，只带 Service ID。收到报文的 Server 如果匹配，就会回复 OfferService（单播或组播，取决于配置）。
你可能会问：为什么不直接让客户端订阅？因为客户端得先知道服务在哪，才能发 Subscribe 啊。Find 就是“先找到门牌号”的过程。
注意：FindService 不能用于已经建立连接的服务。如果客户端已经收到了某个服务的 Offer，就不应该再发 Find 了。否则会造成网络冗余，甚至引发状态混乱。
3.4 SubscribeEventgroup 流程：建立事件通道
找到服务之后，客户端如果想接收服务端的事件（Event）或通知（Notification），就需要发 SubscribeEventgroup 报文。这相当于说：“我找到你了，现在我想订阅你的某个事件组。”
流程分几步：
- 客户端发
SubscribeEventgroup，带上 Service ID、Instance ID、Eventgroup ID。 - 服务端收到后，检查客户端是否有权限订阅（基于 UDP 源 IP 或端口）。
- 如果允许，服务端回复
SubscribeEventgroupAck（确认）或SubscribeEventgroupNack（拒绝）。 - 确认后，服务端开始向客户端发送事件报文。
这里有个容易忽略的点：订阅确认后，客户端需要周期性发送 SubscribeEventgroup 来续约。如果 TTL 到期没收到续约，服务端会认为客户端已离线，停止发送事件。
我记得在调试一个座舱域的项目时，发现中控屏偶尔收不到空调状态更新。抓包一看，原来是中控屏的 Subscribe 续约报文因为网络抖动丢了几包，TTL 刚好设得短，服务端就把订阅给清了。后来我们把 TTL 从 3 秒改到 5 秒，问题就解决了。
| 报文类型 | 方向 | 触发条件 | 关键字段 |
|---|---|---|---|
| OfferService | Server → 组播 | 服务上线 / 周期性 | Service ID, Instance ID, TTL |
| FindService | Client → 组播 | 客户端启动 / 周期性 | Service ID |
| SubscribeEventgroup | Client → Server | 找到服务后 / 续约 | Service ID, Instance ID, Eventgroup ID, TTL |
| SubscribeEventgroupAck | Server → Client | 订阅允许 | 相同的 ID + 确认标志 |
| SubscribeEventgroupNack | Server → Client | 订阅拒绝 | 相同的 ID + 拒绝原因 |
3.5 会话管理：状态机与生命周期
SOMEIP-SD 的会话管理，本质上是一个有限状态机。每个服务实例在 SD 层都有自己独立的状态。
服务端的状态机大致是：
- Available：服务可用，正在发送 Offer。
- Unavailable：服务不可用，停止发送 Offer。
- Shutdown：服务即将下线，发送 Final Offer（TTL=0）后进入 Unavailable。
客户端的状态机：
- Idle：未发现服务。
- Finding：正在发送 FindService。
- Subscribed：已订阅事件组，正在接收事件。
- Unsubscribed：取消订阅或 TTL 到期。
这里我特别想强调一点：状态切换的时机。比如，客户端收到 Offer 后，应该立即停止 FindService 的重复发送，而不是等到下一个周期。我在一个项目中见过，客户端一边收 Offer，一边还在发 Find，白白浪费带宽。
关键设计原则：SD 状态机必须严格遵循 AUTOSAR 规范中的状态转换图。任何“偷懒”的实现，比如跳过 Initial Wait、合并重复阶段，都会在实车测试中暴露问题。
3.6 知识体系总览
下面这张图，是我自己总结的 SOMEIP-SD 核心逻辑。你可以把它当作一个快速参考。
3.7 避坑指南
最后，我把自己这些年踩过的坑总结一下，希望能帮你少走弯路：
- TTL 设置：别设太短（< 3 秒），也别设太长（> 10 秒）。太短容易误判离线，太长导致状态更新慢。我一般用 5 秒。
- 重复次数：至少 3 次。有些节点启动慢，一次 Offer 可能收不到。
- Initial Wait：一定要加随机延迟。不加的话，多个节点同时启动，SD 报文能把总线打满。
- Subscribe 续约：客户端必须在 TTL 到期前重发 Subscribe。建议在 TTL 的 70% 时间点就发，留足余量。
- Final Offer：服务下线前，一定要发 TTL=0 的 Offer。否则客户端会一直等，直到 TTL 超时。
嗯，以上就是 SOMEIP-SD 服务发现的核心内容。记住，SD 不是“配一次就完事”的，它是一个持续交互的过程。理解状态机、掌握报文交互时机，你就能在实车调试中游刃有余。