4. SOME/IP-SD服务发现深入

SOME/IP-SD（Service Discovery）是SOME/IP协议栈的“服务黄页”，它让ECU在运行时动态地发布、查找和订阅服务，而不必把所有服务地址硬编码在代码里。SD报文本身也是SOME/IP消息，使用固定的服务ID 0xFFFF、方法ID 0x8100，通过UDP传输，默认端口30490。理解SD的关键在于三件事：Entry的二进制格式、Offer/Find/Subscribe/SubscribeAck四种交互语义，以及TTL驱动的状态机。

Entry格式：SD报文的原子单元

一条SD报文由Flags、Reserved和若干Entry组成，每个Entry又携带若干Option。Entry分两类：Type 0x01是Service Entry，用于Offer/Find/StopOffer；Type 0x02是Eventgroup Entry，用于Subscribe/SubscribeAck。Service Entry的字段依次为：Type、Index First Option Run、Index Second Option Run、Number of Options、Service ID、Instance ID、Major Version、TTL、Minor Version。Eventgroup Entry则把Service ID、Instance ID、Major Version、TTL、Reserved、Counter、Eventgroup ID作为核心字段，其中Counter用于区分同一订阅者的多次订阅请求。

TTL是Entry里最容易被忽视却最关键的字段。TTL为0xFFFFFF表示“一直有效”，直到显式StopOffer；TTL为0表示停止（StopOffer/StopSubscribe）；其余值是以秒为单位的有效期。接收方必须为每个Entry维护一个TTL定时器，超时未收到刷新就认为服务消失。Option则承载Endpoint信息，常见的有IPv4 Endpoint Option（0x04）、IPv4 Multicast Option（0x14）、Configuration Option（0x01）和Load Balancing Option（0x02）。Entry通过Index First/Second Option Run指向Option数组中的区间，实现“一个Entry引用多个Option”。

Offer / Find / Subscribe / SubscribeAck 的交互语义

Offer由服务端发出，声明“我提供某服务，实例ID为X，版本为Y，入口在某个Endpoint”。Find由客户端发出，声明“我需要某服务，版本范围是……”。两者都使用Service Entry，区别在于TTL和Option内容：Offer通常携带Endpoint Option，Find通常只带Service ID和版本，等待对方用Offer回应。StopOffer是TTL=0的Offer，表示服务下线。

Subscribe由客户端发出，针对某个Eventgroup，表示“我要订阅这个事件组，请把事件发到我的Endpoint”。SubscribeAck由服务端回应，表示订阅被接受或拒绝。SubscribeAck同样使用Eventgroup Entry，TTL表示订阅有效期，Counter必须与请求一致，以便客户端匹配。若服务端拒绝，通常通过不回应或返回TTL=0的Ack来表达。Subscribe还分“事件组订阅”和“字段订阅”两种粒度，字段订阅在Eventgroup Entry中通过Eventgroup ID区分。

TTL与状态机

SD的核心是状态机。服务端维护每个服务实例的“Down/Up”状态：初始Down，收到本地应用注册后进入Up并周期发送Offer；TTL到期前必须重发Offer刷新，否则对端会认为服务消失。客户端维护每个服务的“Not Available/Available”状态：收到Offer后进入Available并启动TTL定时器；定时器超时未收到新Offer则回到Not Available。订阅侧同样有“Not Subscribed/Subscribed”状态，SubscribeAck的TTL到期前需重发Subscribe。

工程上，TTL通常取3～5秒，重发周期取TTL的1/2～2/3，例如TTL=3s、重发间隔2s。这样即使丢一两个包，对端也不会误判服务消失。TTL=0xFFFFFF用于静态服务，但会失去故障检测能力，一般不推荐在车载动态服务上使用。

组播与单播策略

SD的传输策略直接影响网络负载。典型做法是：Offer和Find使用组播，让所有潜在订阅者都能收到；Subscribe和SubscribeAck使用单播，避免订阅关系被无关节点处理。组播地址通常使用239.x.x.x范围内的管理范围地址，端口30490。S32G上需要配置组播组加入、IGMP snooping配合，以及多播Option中的地址与端口。

另一个策略是“Offer组播 + Subscribe单播 + 事件组播/单播”。事件本身可以走组播（如周期状态）或单播（如诊断响应），由Eventgroup的传输方式决定。若事件走组播，SubscribeAck中应携带Multicast Option；若走单播，则携带Endpoint Option。S32G的SD模块需要根据Eventgroup配置自动选择Option类型。

S32G上的SD配置要点

在S32G的SOME/IP栈中，SD配置通常分为三部分：服务实例表、事件组表和网络端点表。服务实例表定义Service ID、Instance ID、版本、TTL、Offer/Find角色；事件组表定义Eventgroup ID、订阅方式、事件传输方式（单播/组播）；网络端点表定义本地IP、端口、组播地址。配置时需注意：同一Service ID的不同Instance ID要分别建表；TTL与重发周期要匹配；组播地址不能与已有服务冲突。

最后，SD的健壮性依赖“超时—重发—状态回退”的闭环。建议在S32G上为每个服务实例设置独立的TTL定时器，并在状态切换时记录日志（如“Service 0x1234 Instance 0x0001: Available → Not Available”），便于定位是网络丢包还是服务端未刷新。掌握Entry格式、四种交互、TTL状态机和组播/单播策略后，就能在S32G上把SD配置得既可靠又高效。