SOME/IP Service Discovery (SOME/IP-SD) 第五章节

1 Introduction and overview

​ 该文档主要用于定义SOME/IP Service Discovery协议的格式，消息序列以及语义。

​ SOME/IP Service Discovery协议的主要工作是用于在车载通信环境中传输Some/IP服务实例的可用性，并且通过事件消息的发送来传输Some/IP服务实例的可用性，通过订阅的方式，Some/IP服务实例的提供者会将事件消息发送给请求事件的订阅者。这就是所谓的SOME/IP-SD协议((Scalable service-Oriented MiddlewarE over IP - Service Discovery)。

1.1 Protocol purpose and objectives

​ Some/IP-SD主要作用如下:

• 定位Some/IP服务实例
• 发现正在运行的Some/IP服务实例
• 实现服务事件/属性的发布/订阅功能

1.2 Applicability of the protocol

​ Some/IP-SD被用于在车载网络中完成服务发现功能。

1.2.1 Constraints and assumptions

​ Some/IP-SD有如下限制条件：

• Some/IP-SD仅支持IP协议作为传输层协议
• 如果一个Some/IP 客户端通过组播/多播的方式订阅另一个Some/IP服务，则网络设计的时候需要考虑如下限制：
  1. 基于端到端的通信可能会无法正常工作
  2. Some/IP服务端需要谨慎处理事件的初始值，因为所有该事件的客户端都是通过组播/多播方式订阅相同的Some/IP服务端 Service实例的，每当有新的客户端通过该组播/多播订阅Service实例后，都会收到事件的初始值。

1.3 Dependencies

1.3.1 Dependencies to other protocol layers

​ SOME/IP-SD 协议依赖SOME/IP协议。SOME/IP协议本身同时支持TCP和UDP两种传输层协议，但是SOME/IP-SD协议只能基于UDP传输层协议。

2 Use Cases

ID	Name	Description
UC_001	Service Offering （服务发布）	Some/IP服务的提供方可以动态想网络中发布服务实例，而不需要在Some/IP服务的使用方中静态配置服务实例的信息。
UC_002	Service Subscription （服务订阅）	Some/IP服务的使用方不需要知道其想订阅的Some/IP Service Instance的具体位置，就可以发现并且订阅该Some/IP Service Instance。
UC_003	Flexible communication paths （可配置的通信选项）	Some/IP应用的开发者不需要知道是哪个应用发送了其需要的数据或者数据需要发送给哪个应用，Service Discovery机制会帮助建立两者之间的通信连接。

5.1 SOME/IP Service Discovery (SOME/IP-SD)

5.1.1 General

​ SOME/IP-SD协议被用于如下工作:

• 定位Some/IP Service实例
• 发现正在运行的Some/IP Service实例
• 实现服务发布/订阅功能

​ 在车机内部网络中的Some/IP Service实例的位置是公开的，因此，应用程序更关心的是Some/IP Service实例的运行状态，Some/IP Service实例的位置信息主要包括如下信息 (IP地址，传输层协议和传输层通信端口号)。

5.1.1.1 Terms and Definitions

​ [PRS_SOMEIPSD_00238] 一个Some/IP Service只在一个网络接口上提供服务，如果需要再多个网络接口上提供该Some/IP Service，那么每个网络接口上都应当由该Some/IP Service的单独实例。

​ [PRS_SOMEIPSD_00239] 如果需要配置服务以便使用多个不同的网络接口访问，则每个网络接口应使用单独的客户端服务实例。

5.1.2 SOME/IP-SD Message Format

5.1.2.1 General Requirements

​ [PRS_SOMEIPSD_00220] SOME/IP-SD消息应当基于UDP传输层协议进行传输。(RS_- SOMEIPSD_00010)

​ [PRS_SOMEIPSD_00251] SOME/IP-SD消息的Header部分结构如下：

• Message ID (Service ID/Method ID) [32 bit]: 0xFFFF 8100
• Length [32 bit]
• Request ID (Client ID/Session ID) [32 bit]
• Protocol Version [8 bit]: 0x01
• Interface Version [8 bit]: 0x01
• Message Type [8 bit]: 0x02 (notification)
• Return Code [8 bit]: 0x00
• Flags [8 bit]
• Reserved [24 bit]
• Length of Entries Array [32 bit]
• Entries Array [variable size]
• Length of Options Array [32 bit]
• Options Array [variable size]

(RS_SOMEIPSD_00001)

​ SOME/IP-SD的Header部分结构如下图粉红色部分：

​ [PRS_SOMEIPSD_00250] Service Discovery 消息应当以 SOME/IP Header开头。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00151] Service Discovery 消息的Header中，Service ID固定为0xFFFF。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00152] Service Discovery 消息的Header中，Method ID固定为0x8100。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00153] Service Discovery 消息的Header中，长度字段为32bit（4字节），长度字段中的长度值包括从长度字段后面的Request ID字段开始到整个Service Discovery消息结尾的总长度。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00154] Service Discovery 消息的Header中，Client ID字段应当设置为0x0000，因为一个ECU中仅仅存在一个SOME/ID-SD的实例。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00156] Service Discovery 消息应当有一个Session ID字段(16bit，2字节)，Session ID字段的处理规则和SOME/IP协议中一致。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00157] 每次发送完一包SOME/IP-SD消息后，Session ID字段值需要递增加一。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00158] Session ID字段值从1开始，当达到0XFFFF后，重新回归到1开始计数。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00159] Session ID字段不应当被设置为0。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00160] SOME/IP-SD消息的Session ID字段的值递增处理，对于单播地址和组播地址是独立的，也就是每条通信通道上有自己的Session ID字段值。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00161] Service Discovery 消息应当有一个8bit长度的Protocol Version字段，值固定为0x01。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00163] Service Discovery 消息的Header中，MessageType字段值为0x02，即Notification类型。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00164] Service Discovery 消息的Header中，ReturnCode字段值固定为0x00(E_OK)。(RS_SOMEIPSD_00001)

5.1.2.2 SOME/IP-SD Header

​ [PRS_SOMEIPSD_00252] SOME/IP-SD消息通过SOME/IP消息传输（也就是在SOME/IP消息的基础上额外带了SD消息Header以及一些Service/EventGroup Entry以及Option Entry）。(RS_SOMEIPSD_00001)

​ [PRS_SOMEIPSD_00252] SOME/IP-SD消息结构如上图

​ [PRS_SOMEIPSD_00253] SOME/IP-SD的Header开始部分有一个8bit长度的Flag字段如下图：

​ [PRS_SOMEIPSD_00254] 第一个Flag标志位为Reboot Flag。(RS_SOMEIPSD_00006)

​ [PRS_SOMEIPSD_00255] 在Some/IP服务实例重启后SOME/IP-SD Header中的Reboot Flag被设置为1，直到Session ID字段到达0xFFFF后重新变成1时，Reboot Flag才会复位成0。（从代码看，如果Some/IP-SD消息从来没有向某个链路上发送过，那么第一次向该链路上发送Some/IP-SD消息的时候，Reboot Flag会被设置为1）(RS_SOMEIPSD_00006)

​ [PRS_SOMEIPSD_00256] Reboot Flag和Session ID应该根据通信链路（单播/组播以及地址）单独进行维护。(RS_SOMEIPSD_00002, RS_- SOMEIPSD_00003)

​ [PRS_SOMEIPSD_00631] 每个SOME/IP-SD消息的发送者/接收者之间都应当维护单独的Reboot Flag以及Session ID。(RS_SOMEIPSD_00002, RS_SOMEIPSD_00003)

​ 注意：

​ 对于SOME/IP-SD消息的发送和接收端，需要维护独立的Session ID计数器：

对于SOME/IP-SD消息的发送段：

• 对于组播地址的通信链路，单独维护一个Session ID计数器
• 对于每一个单播地址的通信链路，单独维护一个Session ID计数器

对于SOME/IP-SD消息的接收端：

• 对于每一个组播地址的通信链路，单独维护一个Sesion ID计数器
• 对于每一个单播地址的通信链路，单独维护一个Session ID计数器

​ [PRS_SOMEIPSD_00258] 应当按照如下方式检测Some/IP Service Instance的重启：

1. 如果上次SD消息中的RebootFlag=0，这次SD消息中的RebootFlag=1，则说明Reboot发生
2. 如果上次和本次SD消息的RebootFlag都为1，但是SessionID变小了，则说明Reboot发生

(RS_SOMEIPSD_00006)

​ [PRS_SOMEIPSD_00259] SOME/IP-SD消息Header中，Flags中第二个Flag被称为UnicastFlag。(RS_SOMEIPSD_00002)

​ [PRS_SOMEIPSD_00540] SOME/IP-SD消息Headr中，UnicastFlag应当始终被设置为1，因为SOME/IP-SD消息支持单播通信传输。(RS_SOMEIPSD_00002)

​ [PRS_SOMEIPSD_00702] SOME/IP-SD消息Header中，Flags字段中没有被使用到的Flag应当被设置为0。接收端无需处理这些Flag。(RS_SOMEIPSD_00002)

​ [PRS_SOMEIPSD_00261] SOME/IP-SD消息Header中，Flags字段（8bit）后面的24bit为保留字段，设置为0，接收端不需要处理。(RS_SOMEIPSD_00006)

​ [PRS_SOMEIPSD_00262] SOME/IP-SD消息的Header后面跟随的是Entry数组。(RS_SOMEIPSD_00006)

​ [PRS_SOMEIPSD_00263] Entry应当按照顺序被处理。(RS_SOMEIPSD_00006)

​ [PRS_SOMEIPSD_00264] Entry数组后面跟随的是Option数组。(RS_SOMEIPSD_00006)

​ [PRS_SOMEIPSD_00265] SOME/IP-SD消息的Entries数组和Options数组前面都有一个32bit（4字节）长度的长度数组，表示Entries数组或者Options数组占用多少个字节。

5.1.2.3 Entry Format

​ [PRS_SOMEIPSD_00266] Service Discovery服务发现支持在一个SD消息中包含多个entry选项。(RS_SOMEIPSD_00006)
​ 注意：

​ Entry中的数据用于同步服务实例的状态以及处理发布/订阅使用。

​ [PRS_SOMEIPSD_00267] 有两类Entry：Service Entry和EventGroup Entry。(RS_SOMEIPSD_00006)

​ [PRS_SOMEIPSD_00268] Service Entry的长度为16个字节，按顺序包含如下字段：
• Type Field [uint8]: 包括如下几个值 FindService (0x00), OfferService (0x01) 和 StopOf-
ferService (0x01)
• Index First Option Run [uint8]: 标识该Service Entry的第一个属性从Option数组中的哪一个开始。
• Index Second Option Run [uint8]: 标识该Service Entry的第二个属性从Option数组中的哪一个开始。
• Number of Options 1 [uint4]: 描述第一个属性中包括多少选项。
• Number of Options 2 [uint4]: 描述第二个属性中包括多少选项。
• Service-ID [uint16]: 描述该Service Entry对应的SOME/IP Service Instance的Service ID
• Instance ID [uint16]: 描述该Service Entry对应的SOME/IP Service Instance的Instance ID，当Instance ID=0xFF时，表示该SOME/IP Service的所有Instance（通常用在FIND报文中）。
• Major Version [uint8]: 标识该Service Entry对应的SOME/IP Service 的主版本信息。
• TTL [uint24]: 标识该Service Entry对应的SOME/IP Service Instance的生存周期（以秒为单位）。
• Minor Version [uint32]: 标识该Service Entry对应的SOME/IP Service 的最小版本信息。

(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00270] 一个SOME/IP-SD消息的EventGroup Entry 长度应当有16字节，按照顺序包括如下字段:

• Type Field [uint8]: 包括如下几个值 Subscribe (0x06), StopSubscribeEventgroup (0x06),
SubscribeAck (0x07) 和 SubscribeEventgroupNack (0x07).
• Index of first option run [uint8]: 标识该Eventgroup Entry的第一个属性从Option数组中的哪一个开始。
• Index of second option run [uint8]: 标识该Eventgroup Entry的第二个属性从Option数组中的哪一个开始。
• Number of Options 1 [uint4]: 描述第一个属性中包括多少选项。
• Number of Options 2 [uint4]: 描述第二个属性中包括多少选项。
• Service-ID [uint16]: 描述该EventGroup属于哪一个SOME/IP Service(Service ID)。

• Instance ID [uint16]: 描述该EventGroup属于哪一个SOME/IP Service Instance的(Instance ID),，当Instance ID=0xFF时，表示该SOME/IP Service的所有Instance。
• Major Version [uint8]: 表示该EventGroup所属SOME/IP Service的主版本信息。
• TTL [uint24]: 标识该Eventgroup Entry的生存周期（以秒为单位）。
• Reserved [uint12]: 保留字段，固定为 0x000。
• Counter [uint4]: 用来记录同一个订阅者对该EventGroup的订阅次数，默认设置为0x0。
• Eventgroup ID [uint16]: Eventgroup的事件组ID。

[PRS_SOMEIPSD_00845] Eventgroup Entry的Major Version主版本信息应当和其所属的SOME/IP Service 的Service Entry的Major Version主版本信息保持一致。
[PRS_SOMEIPSD_00268] 一个SOME/IP-SD消息的Service Entry 长度应当有16字节，按照顺序包括如下字段:
• Type Field [uint8]: 包括如下几个值 FindService (0x00), OfferService (0x01) 和 StopOf-
ferService (0x01)
• Index First Option Run [uint8]: 标识该Service Entry的第一个属性从Option数组中的哪一个开始。
• Index Second Option Run [uint8]: 标识该Service Entry的第二个属性从Option数组中的哪一个开始。
• Number of Options 1 [uint4]: 描述第一个属性中包括多少选项。
• Number of Options 2 [uint4]: 描述第二个属性中包括多少选项。
• Service-ID [uint16]: 描述该Service Entry对应的SOME/IP Service Instance的Service ID
• Instance ID [uint16]: 描述该Service Entry对应的SOME/IP Service Instance的Instance ID，当Instance ID=0xFF时，表示该SOME/IP Service的所有Instance（通常用在FIND报文中）。
• Major Version [uint8]: 标识该Service Entry对应的SOME/IP Service 的主版本信息。
• TTL [uint24]: 标识该Service Entry对应的SOME/IP Service Instance的生存周期（以秒为单位）。
• Minor Version [uint32]: 标识该Service Entry对应的SOME/IP Service 的最小版本信息。

(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00270] 一个SOME/IP-SD消息的EventGroup Entry 长度应当有16字节，按照顺序包括如下字段:

• Type Field [uint8]: 包括如下几个值 Subscribe (0x06), StopSubscribeEventgroup (0x06),
SubscribeAck (0x07) 和 SubscribeEventgroupNack (0x07).
• Index of first option run [uint8]: 标识该Eventgroup Entry的第一个属性从Option数组中的哪一个开始。
• Index of second option run [uint8]: 标识该Eventgroup Entry的第二个属性从Option数组中的哪一个开始。
• Number of Options 1 [uint4]: 描述第一个属性中包括多少选项。
• Number of Options 2 [uint4]: 描述第二个属性中包括多少选项。
• Service-ID [uint16]: 描述该EventGroup属于哪一个SOME/IP Service(Service ID)。

• Instance ID [uint16]: 描述该EventGroup属于哪一个SOME/IP Service Instance的(Instance ID),，当Instance ID=0xFF时，表示该SOME/IP Service的所有Instance。
• Major Version [uint8]: 表示该EventGroup所属SOME/IP Service的主版本信息。
• TTL [uint24]: 标识该Eventgroup Entry的生存周期（以秒为单位）。
• Reserved [uint12]: 保留字段，固定为 0x000。
• Counter [uint4]: 用来记录同一个订阅者对该EventGroup的订阅次数，默认设置为0x0。
• Eventgroup ID [uint16]: Eventgroup的事件组ID。

[PRS_SOMEIPSD_00845] Eventgroup Entry的Major Version主版本信息应当和其所属的SOME/IP Service 的Service Entry的Major Version主版本信息保持一致。

5.1.2.3.1Referencing Options from Entries

[PRS_SOMEIPSD_00833] 通过Entry中的下列两个字段可以找到该entry引用的Options:
• Index First Option Run: Entry的第一个Options在Option数组中的开始位置（起始下标）。
• Index Second Option Run: Entry的第二个Options在Option数组中的开始位置（起始下标）。
• Number of Options 1: Entry的第一个Options中Option的数量，0表示没有Option。
• Number of Options 2: Entry的第二个Options中Option的数量，0表示没有Option。

(RS_SOMEIPSD_00025)

​ 对于为什么每个SOME/IP-SD Entry会有两个Options集合的原因，其理由是这两个Options集合是不同类型的，其中一个Options集合中包含该Entry对于组播和单播的共同选项，另一个Options集合中包含的是该Entry对于组播和单播的有差异的选项。

[PRS_SOMEIPSD_00341] 每个Options集合被使用的时候，其Option范围从Index开始，包括起后面的Number个Option。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00342] 如果Options集合的Number为0，表示该集合没有Option。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00343] 对于Number为0的Options集合，其Index应当设置为0。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00834] 对于SOME/IP-SD消息的接收方，应当能够处理Index不为0但是Number为0的Options集合。(RS_SOMEIPSD_00025)

5.1.2.4 Options Format

​ Options用于保存Entry的额外信息，包括一个SOME/IP Servcice Instance该如何被访问的情报(IP地址，传输层协议，对外端口号)。

[PRS_SOMEIPSD_00273] 为了区别Option的类型（Type），每个Option选项应当在开始部分包括如下信息：
• Length [uint16]: 以字节为单位表示该Option的长度。
• Type [uint8]: 标识该Option的类型。
• Discardable Flag [1 bit]: 标识是否可以被丢弃（不处理）。
• Bit 1 ~ bit 7 是预留的，固定设置为0。

(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00275] Discardable Flag 设置为1表示如果收到的ECU不支持该Option，可以丢弃。(RS_SOMEIPSD_00006)

下面的具体Options中就不再具体展开了，包括Configuration，LoadBalance，IPv4 Endpoint， IPv6 Endpoint等选项类型。

5.1.2.4.1 Configuration Option

​ 配置选项用于传输任意配置字符串，可以表示Service的名称或者别的配置。

[PRS_SOMEIPSD_00276] 配置选项的格式应当按照如下顺序的字段：

• Length [uint16]: 以字节为单位表示该配置选项所占用的大小（这个大小不包括当前length字段和下面的Type字段）
• Type [uint8]: 固定为 0x01.
• Discardable Flag [1 bit]: 标识是否可以被丢弃（不处理）。**
• Bit 1 ~ bit 7 是预留的，固定设置为0。
• ConfigurationString [动态长度]: 携带任意配置字符串。

5.1.2.5 Service Entries

5.1.2.5.1 Find Service Entry

[PRS_SOMEIPSD_00350] Find Service这种Entry 类型被用于发现SOME/IP Service Instance，并且只有客户端在对请求的SOME/IP Service Instance状态位置的情况下，才会发送Find Service Entry。(RS_SOMEIPSD_00008, RS_SOMEIPSD_00021)

[PRS_SOMEIPSD_00351] Find Servie Entry的内部成员按照顺序如下：

• Type 字段应当被设置为 0x00 表示FindService。
• Service ID 字段应当被设置为所请求的SOME/IP Service的Service ID。
• Instance ID 在请求某个SOME/IP Service的所有instance时候，应当被设置为 0xFFFF, 如果请求某个确定的instance的时候，则Instance ID设置为想请求的那个Instance的ID。
• Major Version 在无视SOME/IP Service主版本的情况下，可以设置为0xFF，否则，需要将Major Version设置为对应SOME/IP Service的主版本号。
• Minor Version 在无视SOME/IP Service最小版本的情况下，可以设置为0xFFFF，否则，需要将Major Version设置为对应SOME/IP Service的最小版本号。
• TTL 在Find Service Entry中使用不到TTL，可以设置为任意值，接收端可以忽略Find Service Entry中的TTL字段。
(RS_SOMEIPSD_00008, RS_SOMEIPSD_00021)

注意，一般SOME/IP 服务的客户端都是期望指定版本的SOME/IP Service实例被Find到的，因此一般会手动设置Find Service Entry中的Major Version，不同Major Version的SOME/IP Instance之间一般差异比较大，可能存在不兼容的情况。

[PRS_SOMEIPSD_00528] 在Find Service Entry的Options中不应当出现IP 终结点信息或者组播配置的Option选项。(RS_SOMEIPSD_00008, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00529] SOME/IP-SD Find Service Entry的接收方应当忽略该Find Service Entry中的组播和IP Endpoint Option选项。(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00530] 除了组播和IP Endpoint Option选项，SOME/IP-SD Find Service Entry的接收方应当处理Find Service Entry中的其他Option选项。(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00825] 当收到SOME/IP-SD消息中 FindService Entry后，当Service ID, Instance ID，Major和Minor Version和本地Service Instance配置完全相同才处理，除非Find Service Entry中的Service ID， Instance ID，Major或者Minor Version为任意值(Service ID= 0xFFFF, Instance ID= 0xFFFF，Major VErsion= 0xFF和Minor Version= 0xFFFFFFFF)

[PRS_SOMEIPSD_00839] 如果SOME/IP Service Instance的提供方在initial Wait阶段收到Find Service Entry，则应当忽略该次Find。

5.1.2.5.2 Offer Service Entry

[PRS_SOMEIPSD_00355] Offer Service Entry用于对外发布SOME/IP Service Instance给请求该Service Instance的客户端。(RS_SOMEIPSD_00013)

[PRS_SOMEIPSD_00356] Offer Service Entry中的字段按照顺序如下：

• Type 字段应当设置为0x01表示OfferService。
• Service ID 字段应当设置为所发布的SOME/IP Service的Service ID。
• Instance ID 字段应当设置为所发布的SOME/IP Service Instance 的Instance ID。
• Major Version 字段应当被设置为所发布的SOME/IP Service Instance的Major Version。
• Minor Version 字段应当被设置为所发布的SOME/IP Service Instance的Minor Version。
• TTL 字段应当被设置为该SOME/IP 服务实例的存活时间，超过该存活时间，客户端可以认为该SOME/IP 服务实例不再对外提供服务了。
• 如果 TTL 设置为 0xFFFFFF，则代表该SOME/IP Service Instance一直有效，除非重启。
• 如果 CYCLIC_OFFER_DELAY 配置被定义了，那么 TTL值应当比CYCLIC_OFFER_DELAY设置的要大。
• 除非要停止对外发布该Service Instance，否则TTL就不应当被设置为0。
(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00357] Offer Service的Entries可以引用Ipv4或者Ipv6的Entpooint用于让Client能找到Service Entry中的Service Instance。(RS_SOMEIPSD_-
00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00358] 如果用于对外做SOME/IP-SD通信的网卡支持IPv4，那么该Service Entry的Options中应当包含TCP的IPv4地址和/或UDP的IPv4地址。(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00359] 如果用于对外做SOME/IP-SD通信的网卡支持IPv6，那么该Service Entry的Options中应当包含TCP的IPv6地址和/获UDP的IPv6地址。(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00826] 当收到SOME/-IP SD OfferService Entry的客户端所请求的Service Instance的Service ID, Instance ID， Major 和 Minor Version和Entry中的一致，客户端才会有下一步动作。

5.1.2.5.3 Stop Offer Service Entry

[PRS_SOMEIPSD_00363] Stop Offer Service Entry用于对外停止发布某个SOME/IP Service Instance。(RS_SOMEIPSD_00014)

[PRS_SOMEIPSD_00364] Stop Offer Service Entry的格式内容和Offer Service Entry基本一致，除了TTL字段需要设置为0x000000。(RS_SOMEIPSD_00014)

5.1.2.5.4 Usage of Options in Entries

[PRS_SOMEIPSD_00583]

5.1.2.6 Endpoint Handling for Services and Events

[PRS_SOMEIPSD_00476] Service Discovery模块如果本地配置了Service Instance的IP Endpooint，但是和收到的OfferService 的Options中的单播/组播 IP Endpoint不同，应当使用Options中的IP Endpoint。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00360] ServiceEntry关联的Options中的Endpooint Option对应的IP地址和端口还可以用于传输该Service Instance的event和notification。(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00361] Endpoint Option中传输类型为UDP的情况下，该Option中的IP地址和端口会成为event和notificaiton的源IP和端口，此外也可以成为客户端发送的REQEUST消息的目标IP和端口。(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00362] Endpoint Option中传输类型为TCP的情况下，所关联的SOME/IP Service Instance的客户端应用需要先和该Option中的IP地址+端口建立TCP连接才能接收该Instance发送的Event和Notification。(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00801] SOME/IP允许SOME/IP Service的实例同时使用TCP和UDP两种Endpoint Option。(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00802] 一个SOME/IP消息（不是SD消息）通过TCP还是UDP发送，这个取决于配置。虽然SOME/IP允许SOME/IP Service的实例同时使用TCP和UDP两种Endpoint Option，但是该Service中的元素（Method， Event， Field）只能选择TCP/UDP其中一种作为其传输层链路。(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

5.1.2.6.1 Service Endpoints

​ OfferService Entry所关联的EndPoint Options主要用于：

• Option中的IP地址和端口表示Service Entry中的SOME/IP Service Instance在该地址端口上对外开放。
• Service Entry中的SOME/IP Service Instance通过该IP地址和端口对外发送event消息。

[PRS_SOMEIPSD_00480] 该OfferService Entry中的Service Instance只会在所关联的EndPoint Options中的IP地址和端口上对外发送event消息。(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00481] 如果一个ECU上提供多个SOME/IP Service Instance，这些Instance的OfferServcie Entry关联的Endpiont Option中的地址+端口应当要不同，不同的Service Instance需要在不同的IP地址+端口上对外提供服务。(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

5.1.2.6.2 Eventgroup Endpoints

[PRS_SOMEIPSD_00484] 和Subscribe Eventgroup Entry关联的Endpoint Option中的IP地址和端口是客户端提供的，服务端会通过TCP/UDP将Event消息发送到该IP地址和端口上。(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00486] 如果某个Event是按照配置是TCP传输的，那么客户端在发送Subscribe Event Entry（订阅报文）之前，首先需要和该Eventgroup所属的Service的TCP Endpoint建立TCP连接。(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00487] 服务端应当使用单播的方式发送Event的初始消息。(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00488] Subscribe Eventgroup Ack Entry关联的Options中，最多只能有一个组播Endpoint Option。(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00489] 如果Endpoint Option中的地址为组播地址，那么该Endpooint Option中的传输类型应当是UDP (0x11)。 (RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00490] 当客户端收到Subscribe Eventgroup Entry后，应当尽快打开关联的Endpoint Option中的组播地址和端口，以免错过通过该组播地址端口发送的Event消息。

范例:

• 服务端在UDP-Endpoint SU和TCP-Endpoint ST上发布SOME/IP 服务实例。
• 客户端通服务端建立TCP连接。
• 客户端发送SD消息给服务端，其中带有Subscribe EventGroup Entry，关联客户端的UDP Endpoint CU (单播) 和TCP Endpint CT。
• 服务端回复客户端SD消息，其中包括一个Subscribe Eventgroup Ack Entry，entry关联一个组播Endpoint MU。

接着会发生下列操作：

• 客户端调用服务端的方法。
• Request消息从CU发送给SU，Response消息从SU发送给CU。
• 如果配置中Method走的是TCP传输，那么Request消息从动态TCP Endpoint(dyn)发送给ST，然后Response消息从ST发送给CT。
• 服务端发送基于UDP单播传输的Event：SU -> CU
• 服务端发送基于TCP单播传输的Event：ST -> CT
• 服务端发送基于UDP组播传输的Event: SU to MU

5.1.3 Service Discovery Messages

[PRS_SOMEIPSD_00600] 所有的SD消息应当通过SD_PORT配置的端口进行发送。(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00601] SD_PORT配置为SD消息发送是的源端口（UDP单播/组播）。(RS_SOMEIPSD_00002, RS_SOMEIPSD_00003)

[PRS_SOMEIPSD_00602] 所有单播的SD消息都以SD_PORT作为发送的目标端口，除非在SD消息的Endpoint Option中有不同的端口配置(RS_SOMEIPSD_00002)

[PRS_SOMEIPSD_00603] 所有组播的SD消息都应当使用SD_MULTICAST_IP配置的IP地址进行发送。(RS_SOMEIPSD_00003, RS_SOMEIPSD_00022)

[PRS_SOMEIPSD_00841] 当收到SD消息时，接收端应该忽略Entry中Type为未定义值的Entry条目。

5.1.3.1 Eventgroup Entry

[PRS_SOMEIPSD_00385] Subscribe Eventgroup Entry被用于订阅某个Eventgroup。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00386] Subscribe Eventgroup Entry中按照顺序包含如下字段：

• Type 字段应当被设置为 0x06 (SubscribeEventgroup).
• Service ID 字段被设置为包含要订阅的事件组所属的SOME/IP Service Instance的Service ID。
• Instance ID 字段被设置为包含要订阅的事件组所属的SOME/IP Service Instance的Instance ID。
• Major Version 字段被设置为事件组所属的SOME/IP Service的Major Version。
• Eventgroup ID 字段被设置为要订阅的事件组的ID。
• TTL 字段被设置为本次订阅的市场。
– 如果TTL字段被设置为0xFFFFFF，则代表对Entry中的事件组订阅时间无限长（直到订阅的客户端重启为止）。
– TTL字段不应设置为0x000000，因为0x000000被认为事件组停止订阅。
• Reserved 保留字段应当被设置为0x0000
• Counter 字段对于同一个事件组的每个订阅者都是单独进行计数的，默认设置为0x00。

(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00846] 一个Subscribe Eventgroup Entry关联的Endpoint Options中的地址和端口是客户端希望在该IP和端口上接收到Eventgroup中的Event消息。客户端应用应当使用一个单播Endpoint或者一个组播Endpoint订阅同一个Eventgroup。

• 如果一个客户端使用单播Endpoint订阅了Eventgroup，那意味着客户端希望在这个给定的单播Endpoint地址和端口上收到单播的Event消息。
• 如果一个客户端使用组播Endpoint订阅了Eventgroup，那意味着客户端希望收到发到这个给定的组播Endpoint地址和端口上的组播的Event消息。

[PRS_SOMEIPSD_00387] SubscribeEventgroup Entries应当根据下面的规则引用Options：

• 引用的Options中最多只能有两个Ipv4或者Ipv6类型的Endpoint Option（分别对应TCP和UDP传输类型）
• 引用的Options中最多只能有一个IPv4或者IPv6类型的组播Endpoint Option（只能是UDP传输类型的）

(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

注意：

这个规则也就清晰的说明了一个SOME/IP Service Instance可以同时在TCP和UDP Endpoint上对外提供服务。网络设计时需要考虑下面三点：

• 如果一个SOME/IP Service只使用组播的方式对外提供Event，那么对该Event所属事件组进行订阅的Subscribe Eventgroup Entry就不需要引用一个UDP Endpoint Option了（因为组播通信的时候，客户端不需要提供自己的IP和端口）
• 如果一个SOME/IP Service会发送初始Event (initial Event)，也就是包含Notifier的Field属性，那么订阅该Event的客户端需要在Subsceibe Eventgroup Entry引用的Options中带上单播的Endpont Option（因为初始Event只能通过单播传输 PRS_SOMEIPSD_00487）

​ 网络设计者需要考虑如下3点：

• 如果服务端仅使用组播IP用于传输事件，那么客户端的SubscribeEventGroup报文中的EventGroup Entry就不需要引用UDP Endpoint Option。
• 如果服务端需要传输事件的初始值(属性中的Notifier)'，那么客户端的SubscribeEventgroup报文中的EventGroup Entry必须引用一个单播的Endpoint Option（因为[PRS_SOMEIPSD_00487]）
• 如果客户端订阅的时候在Eventgroup Entry关联的Endpont Option中提供了组播地址，那么服务端需要向该客户端发送事件的初始值

5.1.3.1.2 Stop Subscribe Eventgroup Entry

[PRS_SOMEIPSD_00388] Stop Subscribe Eventgroup Entry用于对EventGroup停止订阅。(RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00389] Stop Subscribe Eventgroup Entry中的字段值应当和Subscribe Eventgroup Entry中的字段值一直，除了TTL，TTL应当被设置为0x000000。(RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00574] 一个 Stop Subscribe Eventgroup Entry引用的Options应当和该Eventgroup之前的Subscribe Eventgroup Entry引用的相同。(RS_SOMEIPSD_00017)

5.1.3.1.3 Subscribe Eventgroup Acknowledgement (Subscribe Eventgroup Ack) Entry

[PRS_SOMEIPSD_00390] Subscribe Eventgroup Acknowledgment Entry 用于表示对应的Subscribe Eventgroup Entry是否被服务端接收，也就是服务端是否接收对该事件组的订阅。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00391] Subscribe Eventgroup Acknowledgment Entry 应当按照如下规则设置Entry中的字段值：

• Type 字段应当被设置为0x07 (SubscribeEventgroupAck)。
• Service ID, Instance ID, Major Version, Eventgroup ID, TTL, Reserved 和 Counter 的值应当和要回复的 Subscribe Eventgroup Entry中的值一致。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00392] Subscribe Eventgroup Ack Entries中事件组里面的事件或者属性中的通知如果是依赖组播通信的，那么Entry需要关联IPv4组播 Endpoint Option或者IPv6组播Endpoint Option。后续服务端会将事件消息发送到这个组播Endpoint上。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00829] 当客户端接收到Subscribe Eventgroup Ack Entry后，需要检查Entry中的字段值是否和自己发送的Subscribe Eventgroup Entry中的字段值一致。

5.1.3.1.4 Subscribe Eventgroup Negative Acknowledgement (Subscribe Eventgroup Nack) Entry

[PRS_SOMEIPSD_00393] Subscribe Eventgroup Negative Acknowledgement Entry用于只是客户单的Subscribe Eventgroup Entry不被服务端接受。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00394] Subscribe Eventgroup Acknowledgment Entry 应当按照如下规则设置Entry中的字段值：

• Type 字段应当被设置为0x07 (SubscribeEventgroupAck)。
• Service ID, Instance ID, Major Version, Eventgroup ID, TTL, Reserved 和 Counter 的值应当和要回复的 Subscribe Eventgroup Entry中的值一致。

• The TTL 字段值应当被设置为 0x000000。

(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00566] 对于客户端发送的Subscribe Eventgroup Entry拒绝的原因主要有如下几个：

• Combination of Service ID, Instance ID, Eventgroup ID, and Major Version is un-
known
• Subscribe EventGroup Entry引用了TCP Endpoint Option，但是客户端还没有建立对应的TCP通信链路。
• Subscribe Eventgroup Entry引用的Options中存在有问题的Option。
• Server端存在资源问题，无法接受更多的订阅。
• 安全问题

(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00527] 当客户端发送的Subscribe Eventgroup Entry引用了TCP Endpoint Option，并且收到了服务端的NACK消息，则应当检查TCP连接是是否正常，必要的情况下进行重连。(RS_SOMEIPSD_00015)

注意：[PRS_SOMEIPSD_00527] 涉及到网络安全协议的检查。

检查当前订阅事件组的TCP连接状态是否正常可以有如下手段：

• 检查是否从其他事件组收到了事件消息。
• 发送Magic Cookie消息并且等待TCP ACK。
• 重新建立TCP连接

[PRS_SOMEIPSD_00842]

5.1.4 Service Discovery Communication Behavior

[PRS_SOMEIPSD_00800] SOME/IP ServiceDiscovery机制应当减少SD消息的数量，这可以通过将不同的Entry打包在一个消息中一起发送，例如：

• 一个SD消息中可以包含多个SOME/IP Service实例的多个Entry。
• 上面的多个Entry的类型可以是不同的 (e.g. Offer entries, answers of Subscribed EventGroup entries …)。

(RS_SOMEIPSD_00025)

5.1.4.1 Startup Behavior

[PRS_SOMEIPSD_00395] 对于每个SOME/IP Service instance，SOME/IP Service Discovery机制至少包含下面三个阶段，每个阶段都会发送对应的Entry条目。

• Initial Wait Phase
• Repetition Phase
• Main Phase

注意：

实际的SOME/IP实现版本可能不止上面三个阶段。

[PRS_SOMEIPSD_00397] 对于SOME/IP Service Instance的客户端来说，当Service Discovery依赖的组播通信的网络接口已经准备就绪，并且客户端应用已经发起对Service Instance的请求时，Service Discovery机制就使该SOME/IP Service Instance的客户端进入Initial Wait Phase。(RS_SOMEIPSD_00025, RS_SOMEIPSD_00012)

[PRS_SOMEIPSD_00133] 对于SOME/IP Service Instance的服务端来说，当Service Discovery依赖的组播通信的网络接口已经准备就绪，并且Service Instance对外状态已经是Available时，Service Discovery机制就使该SOME/IP Service Instance的服务端进入Initial Wait Phase。(RS_SOMEIPSD_00025, RS_SOMEIPSD_00012)

注意：
当Service Discovery依赖的组播通信网络接口已经准备就绪，但是此时可能所请求的SOME/IP Service Instance还未处于Available状态，这种情况完全可能存在。

​ 对于SOME/IP Service Instance的服务端来说，实现该Instance的Service功能的功能模块必须就绪后才可以对外发布该Service Instance。

​ 对于SOME/IP Service Instance的客户端来说，只有客户端明确请求了该Service Instance，在组播网络中find 该Service Instance才是合适的。

[PRS_SOMEIPSD_00399] Service Discovery机制规定，当SOME/IP的客户端/服务端处于Initial Wait Phase后，应当基于INITIAL_DELAY配置的参数进行延时等待，然后才能够发送第一包关于该SOME/IP Service Instance的消息(FIND/OFFER)。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00400] INITIAL_DELAY参数一般配对有MIN和MAX值(INITIAL_DELAY_MIN和INITIAL_DELAY_MAX)。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00401] 应用程序会在INITIAL_DELAY_MINhe INITIAL_DELAY_MAX中间选取随机值作为本次的INITIAL_DELAY值。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00404] 当SOME/IP Service Instance的客户端/服务端发送第一包SOME/IP-SD消息后，就进入了Service Discovery机制的Repetitions Phase（重复阶段）。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00405] Service Discovery机制规定，在Repetitions Phase阶段，SOME/IP Service Instance的客户端/服务端发送SD消息的间隔以REPETITIONS_BASE_DELAY配置的时长为基础。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00406] 在Repetitions phase阶段，每次发送SOME-IP/SD消息后，下次的发送间隔会在上一次基础上翻倍（REPETITIONS_BAE_DELAY * N， N为该阶段第几次发送SD消息）。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00407] 在Repetitions Phase阶段，最多发送的SOME-IP/SD消息的数量由REPETITIONS_MAX配置参数决定。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00408] 对于SOME/IP Service Instance的客户端来说，如果在Repetitions Phase阶段收到包含所请求的Service Instance的Entry的Offer消息，则立刻停止发送FIND消息，并且进入Main Phase阶段。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00409] 如果REPETITIONS_MAX配置参数设置为0，则意味着Initial Phase阶段结束后直接跳过Repetitions Phase进入Main Phase。

[PRS_SOMEIPSD_00410] Repetitions phase阶段结束后进入Main Phase阶段。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00411] 在进入Main Phase阶段后，SOME/IP Service Instance的服务端应当根据CYCLE_OFFER_DELAY配置的值进行延时等待后，才发送第一包OFFER消息。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00412] 在Main Phase阶段，Offer消息应当按照CYCLE_OFFER_DELAY配置的间隔进行发送。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00415] 在Main Phase阶段不允许发送Find消息。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00582] 对于Eventgroup Entry的订阅是基于收到服务端周期Offer消息中对应的Entry触发的。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00416] 范例如下：

Initial Wiat Phase:

• 等待一段时间（时间从INITIAL_DELAY_MIN和INITIAL_DELAY_MAX中取随机值）
• 发送Find或者Offer消息

Repetition Phase (REPETITIONS_BASE_DELAY=100ms, REPETITIONS_MAX=2):

• 等待 1 (2的0次方) ∗ 100ms
• 发送Find或者Offer消息
• 等待 2 (2的1次方) ∗ 100ms
• 发送Find或者Offer消息

Main Phase:

• SOME/IP Service Instance的服务端:
– 假设CYCLIC_OFFER_DELAY 配置
∗ 等待 CYCLIC_OFFER_DELAY对应的时延
∗ 发送Offer消息
• SOME/IP Service Instance的客户端:
– as long as offer service messages are received, Subscribe Eventgroup message is sent

(RS_SOMEIPSD_00025)

5.1.4.2 Server Answer Behavior

[PRS_SOMEIPSD_00417] 对于通过组播收到的SOME/IP-SD消息，接收方应当按照REQUEST_RESPONSE_DELAY配置的参数进行时延，然后才进行回复，消息的回复场景如下：

• 从组播地址上收到Find消息，然后发送Offer entry (通过单播或者组播)
• 从组播地址上收到Offer消息后，通过单播通信发送Subscribe消息

(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00419] REQUEST_RESPONSE_DELAY时延参数仅针对从组播上收到的SD消息的回复，如果SD消息时从单播链路上收到的则不需要该时延。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00420] REQUEST_RESPONSE_DEYAL有MIN和MAX值（和INITIAL_DELAY一样）(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00421] 和INITIAL_DELAY一样，实际的延时值在REQUEST_RESPONSE_DELAY_MIN和REQUEST_RESPONSE_DELAY_MAX之间取随机值。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00422] 对于SOME/IP协议的实现方来说获，所有的Find Service Entry应当被实现该Entry的服务端回复（使用单播通信回复Offer消息）。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00423] 为了优化性能，下面的措施应当被支持：

• 如果SOME/IP Service Instance在Main Phase阶段从单播链路收到对该Instance的Find消息，如果在小于1/2 CYCLE_OFFER_DELAY的时延内发送过一次Offer消息，则应当通过单播链路回复一条Offer消息。
• 如果SOME/IP Service Instance在Main Phase阶段从单播链路收到对该Instance的Find消息，如果最后一次发送包含该Instance的Offer消息的时间距今超过了1/2 CYCLE_OFFER_DELAY的时延，则应当通过组播链路回复一条Offer消息。

(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00843] 如果收到SD消息中，SD Header中的Unicast Flag设置为0，则不需要通过单播链路进行回复。(RS_SOMEIPSD_00025)

5.1.4.3 Shutdown Behavior

[PRS_SOMEIPSD_00427] 当一个ECU上的SOME/IP Service Instance的服务端处于Repetition Phase和Main Phase阶段，并且其服务端进程想要停止时，需要发送Stop OfferService Entry。(RS_SOMEIPSD_00017, RS_SOMEIPSD_00012)

[PRS_SOMEIPSD_00751] 当依赖的网络接口下线(Down)时，无论Service Instance的服务端处于Initlal Wait Phase还是Repetitions Phase或者Main Phase，都需要进入Down Phase，然后等待网络接口上线恢复(Up)后，重新进入Initial Wait Phase。(RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00752] 当依赖的网络接口下线(Down)时，无论Service Instance的客户端处于Initlal Wait Phase还是Repetitions Phase或者Main Phase，都需要进入Down Phase，然后等待网络接口上线恢复(Up)后，重新进入Initial Wait Phase。(RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00428] 当SOME/IP Service Instance的服务端发出Stop Offer Service Entry后，服务端上该Service Instance目前的所有订阅应当被删除作废。(RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00429] 当SOME/IP Service Instance的客户端收到Stop Offer Service Entry后，客户端应该删除所有对该Service Insance的订阅。(RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00430] 当SOME/IP Service Instance的客户端收到Stop Offer Service Entry后，客户端不应该发送Find Service消息，而是等待重新收到Offer Service Entry。(RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00431] 当一个ECU上的SOME/IP Service Instance的客户端端处于Repetition Phase和Main Phase阶段，并且其客户端进程想要停止时，需要发送Stop Subscribe Eventgroup Entry取消已经订阅的Eventgroup。(RS_SOMEIPSD_00017)

5.1.4.4 State Machines

[PRS_SOMEIPSD_00433] 这个章节中将描述SOME/IP服务端和客户端的状态机。(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00434] SOME/IP 服务状态的状态机大致如下：

• SD Server State Machine(Service)
	– Not Ready
	– Ready
	∗ Initial Wait Phase
		· Timer Set
	∗ Repetition Phase
		· Timer Set
	∗ Main Phase
		· Timer Set

SOME/IP Service Discovery机制对于SOME/IP Service Instance的Server来说，其状态有以下几个：

• SD Server State Machine(Service)
	– Ready
		∗ Initial Wait Phase
		∗ Repetition Phase
		∗ Main Phase

Server端的内部状态跳转规则如下：

FROM entry point SD Server State Machine(Service)
TO Not Ready
WITH [ifstatus!=up_and_configured or service-status==down]

FROM entry point SD Server State Machine(Service)
TO Not Ready
WITH [ifstatus==up_and_configured or service-status==up]

FROM Not Ready
TO Ready
WITH
if-status-changed() or service-status-changed() [ifsta-
tus==up_and_configured and service-status==up]

FROM Ready
TO Not Ready
WITH if-status-changed [ifstatus!=up_and_configured] /clearAll-
Timers()
FROM Ready
TO Not Ready
WITH service-status==down /clearAllTimers() send(StopOfferSer-
vice)

FROM TimerSet
OF Initial Wait Phase
TO Repetition Phase
WITH Timer expired /send(OfferService)

FROM TimerSet
OF Repetition Phase
TO TimerSet
OF Repetition Phase
WITH receive(FindService) /waitAndSend(OfferService) ResetTimer
()

FROM TimerSet
OF Repetition Phase
TO TimerSet
OF Repetition Phase
WITH
Timer expired [run<REPETITIONS_MAX] /send(OfferService)
run++ setTimer((2r̂un)*REPETITIONS_BASE_DELAY

FROM TimerSet
OF Repetition Phase
TO Main Phase
WITH Timer expired [run==REPETITIONS_MAX]

FROM entry point Ready
TO Initial Wait Phase

FROM entry point Initial Wait Phase
TO Timer Set
OF Initial Wait Phase
WITH SetTimerInRange(INITIAL_DELAY_MIN,INITIAL_DELAY_MAX)

FROM entry point Repetition Phase
TO Timer Set
OF Repetition Phase
WITH
[REPETITIONS_MAX>0] /run=0 setTimer((2r̂un)*REPETI-
TIONS_BASE_DELAY)

FROM entry point Repetition Phase
TO Main Phase
WITH [REPETITIONS_MAX==0]

FROM entry point Main Phase
TO Timer Set
OF Main Phase
WITH /setTimer(CYCLIC_ANNOUNCE_DELAY) send(OfferService)

FROM Timer Set
OF Main Phase
TO Timer Set
OF Main Phase
WITH
Timer expired /setTimer(CYCLIC_ANNOUNCE_DELAY) send(Of-
ferService)

FROM Timer Set
OF Main Phase
TO Timer Set
OF Main Phase
WITH receive(FindService) /waitAndSend(OfferService) resetTimer
()

SOME/IP Service Discovery机制对于SOME/IP Service Instance的Client来说，其状态有以下几个：

• SD Client State Machine(Service)
    – Not Requested
        ∗ Service Not Seen
        ∗ Service Seen
    – Requested_but_not_ready
    – Main
        ∗ Service Ready
        ∗ Stopped
    – Searching for Service
        ∗ Initial Wait Phase
        	· Timer Set
        ∗ Repetition Phase
        	· Timer Set

Client状态机的入口状态如下：

• SD Client State Machine(Service)
	– Not Requested
• Searching for Service
	– Initial Wait Phase
	– Repetition Phase

Server端的内部状态跳转规则如下：

FROM entry point SD Client State Machine(Service)
TO Not Requested
WITH [Service Not Requested]   // 客户端应用还未请求Service Instance

FROM entry point SD Client State Machine(Service)
TO Requested_but_not_ready
WITH Service Not Requested and ifstatus!=up_and_configured  // 客户端应用还未请求Service Instance并且网卡也未启动

FROM entry point SD Client State Machine(Service)
TO Searching for Service
WITH Service Requested and ifstatus==up_and_configured  //客户端应用请求Service Instance并且网卡也已经启动

FROM entry point Not Requested TO Service Not Seen

FROM Not Requested TO Requested_but_not_ready
WITH InternalServiceRequest [ifstatus!=up_and_configured]  //客户端应用请求Service Instance但是网卡还未启动

FROM Service Not Seen   // 还未收到Service Instance 的Offer
TO Service Seen 
WITH receive(OfferService) /setTimer(TTL)   // 收到Offer，然后设置Timer等待延时进入下一个状态

FROM Repetition Phase
TO Stopped
WITH Repetition Expired

FROM Repetition Phase
TO Stopped
WITH receive(StopOfferService)

FROM Stopped
TO Service Not Seen
WITH [ServiceNotRequired]

FROM Service Seen
TO Service Not Seen
WITH if-status-changed() [ifstatus!=up_and_configured]

FROM Service Seen
TO Service Not Seen
WITH Timer expired (TTL)

FROM Repetition Phase
TO Stopped
WITH Repetition Expired
FROM Service Seen
TO Service Not Seen
WITH receive(StopServiceOffer)

FROM Service Seen
TO Service Seen

FROM Service Seen
TO Service Ready
WITH InternalServiceRequest [ifstatus==up_and_configured]

FROM Service Ready
TO Service Seen
WITH [ServiceNotRequest]

FROM Service Ready
TO Service Ready
WITH receive(OfferService) /resetTimer(TTL)

FROM Service Ready
TO Stopped
WITH receive(OfferService) /chancelTimer(TTL)

FROM Stopped
TO Service Ready
WITH receive(OfferService) /resetTimer(TTL)

FROM Service Ready
TO Searching for Service
WITH Timer expired (TTL)

FROM Searching for Service
TO Service Ready
WITH receive(OfferService) /setTimer(TTL)

FROM Searching for Service
TO Requested_but_not_ready
WITH if-status-changed() [ifstatus!=up_and_configured] /cancel-
Timer(TTL)

FROM Requested_but_not_ready
TO Searching for Service
WITH if-status-changed() [ifstatus!=up_and_configured]

FROM entry point Searching for Service
TO Initial Wait Phase

FROM entry point Initial Wait Phase
TO Timer Set
OF Initial Wait Phase
WITH /setTimerInRange(INITIAL_DELAY_MIN, INITIAL_DELAY_MAX)

FROM Timer Set
OF Initial Wait Phase
TO Repetition Phase
WITH TimerExpired /send(FindService)

FROM entry point Repetition Phase
TO Timer Set
OF Repetition Phase
WITH
[REPETITONS_MAX>0] /run=0 setTimer((2r̂un)*REPETI-
TIONS_BASE_DELAY)

FROM Timer Set
OF Repetition Phase
TO Timer Set
OF Repetition Phase

FROM Not Requested
TO Requested_but_not_ready
WITH InternalServiceRequest [ifstatus!=up_and_configured]

5.1.4.5 SOME/IP-SD Mechanisms and Errors

​ 在这个章节将讨论SOME/IP-SD的错误处理机制，这也可理解为所用机制和可能配置的原理。

​ SOME/IP-SD被设计为一个软状态协议，这意味着每个Service Discovery涉及到的Entry都有一个生命周期，，并且需要定期刷新保活 (设置TTL到最大值就可以关闭这个保活设置)。

​

Initial Wait Phase:

​ 用于处理ECU启动时的去偏移动作以避免网络风暴，让ECU可以手机多个SD消息的Entries。

Repetition Phase:

​ 用于快速同步SOME/IP Service Instance的客户端和服务端两边的状态，如果客户端启动的玩，那么客户端会非常快的Find到服务端。如果服务端启动的比较晚，客户端也会被服务端较快发现（收到Find消息）。Repetitions Phase阶段指数增长发出的SD消息可以就避免网络的负载。

Main Phase:

​ 在Main Phase阶段，客户端就不再发送Find消息，而服务端也周期发送offer消息（通常是1秒），这样整个SD的负载就趋于稳定。

Request-Response-Delay:

​ SOME/IP-SD有配置选项可以延迟回复通过组播链路收到的SD消息中的Entry，这个配置是REQUEST_RESPONSE_DELAY，在大型系统中有很多ECU，这个机制是有用的。当通过组播链路发送SD消息的应用收到许多不同的ECU的回复消息时，会导致较大的处理压力。

5.1.6 Publish/Subscribe with SOME/IP and SOME/IP-SD

​ 和SOME/IP request/response通信不同的是，某些场景下，客户端会需要一组服务端的参数信息，但是并不想每次需要这些参数的时候就想服务端去请求一次(Request/Response)，这种情况下，就用到了通知，事件以及属性。

[PRS_SOMEIPSD_00443] 所有依赖SOME/IP event，notificaiton的客户端应用需要再提供这些event，notification的服务端进行注册。(RS_SOMEIPSD_00013,
RS_SOMEIPSD_00014, RS_SOMEIPSD_00015, RS_SOMEIPSD_00016)

[PRS_SOMEIPSD_00446] 客户单对于事件/通知的订阅是被服务端发送的SOME/IP-SD消息中的Offer Service Entry触发的。(RS_SOMEIPSD_00013, RS_SOMEIPSD_00014, RS_SOMEIPSD_00015, RS_SOMEIPSD_00016)

[PRS_SOMEIPSD_00449] 每个客户端应当对服务端发送的Offer Service Entry进行应答，回复SOME/IP-SD Subscribe Eventgroup Entry给服务端，只要客户端还对该Service Instance中的Eventgroup有兴趣。如果客户端通过SD消息检测到了服务端发生了Reboot（通过SD Header中的Reboot Flag以及Some/IIP Header中的Session ID），那么客户端应当按照收到了服务端的Stop Offer消息的处理流程去处理（参照[PRS_SOMEIPSD_00429]）。

[PRS_SOMEIPSD_00703] 如果目前客户端没有订阅某个属性所属的事件组的情况下，客户端应当通过发送一个同时包含Stop Subscribe Eventgroup Entry和Subscribe Eventgroup entry的SOME/IP-SD消息来显式地一个Field属性中的notifier的初始值。(这个只针对属性Field中的通知Notifier，不适用于事件Event)

[PRS_SOMEIPSD_00811] 对于纯Event事件，不存在所谓的Initial Value。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00704] 如果客户端已经发送了Subscribe Eventgroup Entry，并且这些已经发送的Entry的TTL还没有过期，那么客户端是不能去请求订阅的属性的Initial Value的。(RS_SOMEIPSD_00015, RS_SOMEIPSD_00020)

对于客户端来说，显式地请求Field属性的初始值的原因大致有如下：

• 客户端当前还没有订阅事件组
• 客户端在上一次订阅后出现过网卡下线又上线的情况，担心错过一次属性的事件通知
• 客户端在发送Subscribe Eventgroup后没有收到Subscribe Eventgroup Ack
• 客户端检测到服务端service instance有重启(reboot flag+request sessionid综合判断)

[PRS_SOMEIPSD_00570] 即使客户端发送的订阅消息中有多个Subscribe Eventgroup Entry的Eventgroup包含了同一个EventID的事件/属性的通知，服务端也不能重复发送这个EventID的事件/属性的值给客户端。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00450]

客户端侧如果发生了网络断联的情况，那么发布/订阅的操作如下：

1. 客户端未向服务端注册 + 客户端订阅
   (a) 服务端: OfferService()
   (b) 客户端: SubscribeEventgroup[Session ID=x, Reboot=0]
   © 服务端: updateRegistration()
   (d) 服务端: SubscribeEventgroupAck + Events()

2. 客户端侧网络丢失
   (a) 客户端: linkDown()
   (b) 客户端: deleteEntries()
   © 客户端: linkUp()

3. 客户端再次订阅/客户端发生Reboot
   (a) 服务端: OfferService()
   (b) 客户端: SubscribeEventgroup[Session ID=1, Reboot=1]
   © 服务端: updateRegistration()
   (d) 服务端: SubscribeEventgroupAck + Events()

注意: 服务端发送Offer Service Entries用于收集Subscribe Eventgroup Entry，这样服务端才能知道某个事件/属性是否需要向客户端发送(没有订阅自然就不需要发送)。

[PRS_SOMEIPSD_00452] 客户端在取消事件组订阅的时候，应当发送发送TTL=0的Subscribe Eventgroup Entry (Stop Subscribe Eventgroup [PRS_SOMEIPSD_00389])。(RS_SOMEIPSD_00017, RS_SOMEIPSD_00020)

[PRS_SOMEIPSD_00453]

SOME/IP Service Instance的客户端和服务端之间的Publish/Subscribe Registration/Deregistration 操作的流程如下：

1. Client 1 subscribes
   (a) Server: OfferService() to Client 1 and Client 2
   (b) Client 1: SubscribeEventgroup()
   © Server: updateRegistration()
   (d) Server: SubscribeEventgroupAck + Events() to Client 1
2. Client 2 subscribes
   (a) Client 2: SubscribeEventgroup()
   (b) Server: updateRegistration()
   © Server: SubscribeEventgroupAck + Events() to Client 2
3. Client 2 stops subscription
   (a) Client 2: StopSubscribeEventgroup()
   (b) Server: updateRegistration()
4. Client 1 remains registered

(RS_SOMEIPSD_00015, RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00454] 如果服务端侧在发送事件或者属性的通知给客户端时发生了错误（例如TCP Connection Error），那么SOME/IP-SD在服务端侧应当删除该客户度的订阅。(RS_SOMEIPSD_00017, RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00457]

SOME/IP Service Instance服务端发生网卡下线的处理流程如下:

1. 客户端未向服务端注册 + 客户端订阅
   (a) Server: OfferService()
   (b) Client: SubscribeEventgroup()
   © Server: updateRegistration()
   (d) Server: SubscribeEventgroupAck + Events()

2. 服务端网卡下线
   (a) Server: linkDown()
   (b) Server: deleteRegistrations()
   © Server: linkUp()

3. 服务端重新上线并且发送Offer消息，服务端的Reboot被客户端检测到
   (a) Server: OfferService()[Session ID=1, Reboot=1]
   (b) Client: SubscribeEventgroup()
   © Server: updateRegistration()
   (d) Server SubscribeEventgroupAck + Events()
   
   [PRS_SOMEIPSD_00461] 如果服务端的Eventgroup中的Event配置了TCP Endpoint，那么客户端应当首先建立和服务端Service Instance的TCP连接，然后发送带有TCP Endpoint Option的Subscribe Eventgroup Entry。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00462] 如果客户端请求的SOME/IP Service要求有安全关联的要求，那么客户端应当首先简历安全连接，然后再基于建立完成的安全连接上发送Subscribe Eventgroup Entry。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00831] 对于要求仅允许一个参与者开始建立安全关联的安全关联（如TLS)，每个ECU应使用不同的端点进行服务器服务和客户端服务，以确保ECU在每个安全连接中作为客户端（启动建立安全关联）或作为服务器。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00462] 客户端发送Subscribe Eventgroup Entry后，服务端应当发送Subscribe Eventgroup ACK Entry作为回复。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00463] 客户端发送Subscribe Eventgroup Entry后，应当等待服务端回复Subscribe Eventgroup ACK Entry，如果客户端在又一次收到Offer Service Entry需要发送Subscribe Eventgroup Entry时还没有收到服务端对上一次应当回复的Subscribe Eventgroup ACK Entry，那么客户端应当如下操作：

• 在同一个SOME/IP-SD 消息中同时包含Stop Subscribe Eventgroup entry 和 Subscribe Eventgroup entry。

[PRS_SOMEIPSD_00577] 上面[PRS_SOMEIPSD_00463]条目的要求对于Find Service Entry和OfferService Entry并不适用。也就是说，如果客户端收到的Offer报文是通过单播发送的，那么

[PRS_SOMEIPSD_00465] 不允许在订阅是发布初始值（针对纯事件，而不是属性中的通知）。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00120] 收到客户端的订阅后，服务端应当通过事件消息发送属性的当前值给客户端（只针对属性中的通知，不适用于纯事件）。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00121] 如果客户端发送的订阅Entry被服务端判定为非法的，那么服务端不应该发送属性的初始值给该客户端。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00122]服务端收到客户端的SD消息中包含对某个属性所属事件组的取消订阅和订阅Entry时，应当给该客户端发送属性的初始值。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00123] 服务端应当首先回复Subscribe ACK消息给客户端，然后再通过事件消息发送属性的初始值给客户端。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00466] SOME/IP Service 服务端处理发布/订阅状态如下（要求事件组通过单播通信）：

• Eventgroup_PubSub (Unicast Eventgroup)
    – Service Down
    – Service Up
    	∗ Not Subscribed
    	∗ Subscribed

单播事件组的发布订阅的入口点如下：

• Eventgroup_PubSub (Unicast Eventgroup)
	– Service Up

单播事件组的发布订阅的状态切换如下：

FROM entry point Eventgroup_PubSub (Unicast Eventgroup) 
TO Service Down
WITH [Service==Down]

FROM Service Down
TO Service Up
WITH ServiceUp

FROM Service Up
TO Service Down
WITH ServiceDown

FROM entry point Eventgroup_PubSub (Unicast Eventgroup)
TO Service UP
WITH [Service==Up]

FROM entry point Service Up
TO Not Subscribed

FROM Not Subscribed
TO Subscribed
WITH
receive(SubscribeEventgroup) /enableEvents() send(Sub-
scribeEventgroupAck)

FROM Subscribed
TO Subscribed
WITH receive(SubscribeEventgroup) /send(SubscribeEventgroupAck)

FROM Subscribed
TO Not Subscribed
WITH receive(StopSubscribeEventgroup) /disableEvents()

FROM Subscribed
TO Not Subscribed
WITH TTL_expired [SubscriptionCounter==1] /disableEvents()

(RS_SOMEIPSD_00015，RS_SOMEIPSD_00016)

[PRS_SOMEIPSD_00571] 如果一个客户端使用不同的SOME/IP-SD消息订阅同一个SOME/IP Service Instance的不同的Eventgroup，并且所订阅的这些Eventgroup包含相同的Event，那么服务端在每次收到该客户端发送的SOME/IP-SD Subscribe Eventgroup Entry中包含这个Event时，都需要发送该Event所属的属性的初始值给客户度。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00572] 如果客户端使用同一个SOME/IP-SD消息订阅了同一个SOME/IP Service Instance的不同事件组，并且这些事件组包含了同一个Event事件，那么服务端可能只会仅发送一次该Event所属属性的初始值。(RS_SOMEIPSD_00015)

注意：

这意味着服务端可以优化属性的初始值的发送。

[PRS_SOMEIPSD_00467] 包含依赖组播通信的事件的事件组，其发布/订阅的状态和子状态有如下几个：

• Eventgroup_PubSub (Multicast Eventgroup)
    – Service Down
    – Service Up
        ∗ Not Subscribed
        ∗ Subscribed

包含组播通信的事件的事件组，其发布/订阅的入口点如下：

• Eventgroup_PubSub (Multicast Eventgroup)
	– Service Up

包含组播通信的事件的事件组，其发布/订阅的状态跳转如下：

FROM entry point Eventgroup_PubSub (Multicast Eventgroup)
TO Service Down
WITH [Service==Down]

FROM Service Down
TO Service Up
WITH ServiceUp

FROM Service Up
TO Service Down
WITH ServiceDown

FROM entry point Eventgroup_PubSub (Multicast Eventgroup)
TO Service UP
WITH [Service==Up]

FROM entry point Service Up
TO Not Subscribed

FROM Not Subscribed
TO Subscribed
WITH receive(SubscribeEventgroup) /enableEvents() Subscription Counter++ send(SubscribeEventgroupAck)

FROM Subscribed
TO Subscribed
WITH receive(SubscribeEventgroup) /SubscriptionCounter++ /send   // 这里的SubscriptionCounter是指对该事件组的订阅的客户端数量
(SubscribeEventgroupAck)

FROM Subscribed
TO Not Subscribed
WITH receive(StopSubscribeEventgroup) [SubscriptionCounter==1]
/SubscriptionCounter- /disableEvents()

FROM Subscribed
TO Subscribed
WITH
receive(StopSubscribeEventgroup) [SubscriptionCounter>1]
/SubscriptionCounter-

FROM Subscribed
TO Not Subscribed
WITH TTL_expired [SubscriptionCounter==1] /SubscriptionCounter-   // 客户端的订阅Entry TTL超时了，并且没有新的订阅Entry到达服务端
disableEvents()

FROM Subscribed
TO Subscribed
WITH TTL_expired [SubscriptionCounter>1] /SubscriptionCounter-

[PRS_SOMEIPSD_00468] 如果一个事件组中既包含单播事件也包含组播事件，那么该事件组的发布订阅有下面几个状态和子状态

• Eventgroup_PubSub (Unicast-to-Multicast Eventgroup)
    – Service Down
    – Service Up
        ∗ Not Subscribed
        ∗ Subscribed (Unicast)
        ∗ Subscribed (Multicast)

这样的事件组的发布订阅入口点是：

• Eventgroup_PubSub (Unicast-to-Multicast Eventgroup)
	– Service Up   // 服务启动

同时包含单播事件和组播事件的事件组的发布订阅的状态迁移如下：

FROM entry point Eventgroup_PubSub (Unicast-to-Multicast Event-
group)
TO Service Down
WITH [Service==Down]

FROM Service Down
TO Service Up
WITH ServiceUp

FROM Service Up
TO Service Down
WITH ServiceDown

FROM entry point Eventgroup_PubSub (Unicast-to-Multicast Event-
group)
TO Service UP
WITH [Service==Up]

FROM entry point Service Up
TO Not Subscribed

FROM Not Subscribed
TO Subscribed (Unicast)
WITH
receive(SubscribeEventgroup) [UnicastLimit>0] /en-
ableEvents() SubscriptionCounter++ send(SubscrieEventgroupAck)

FROM Subscribed (Unicast)
TO Subscribed (Unicast)
WITH
receive(SubscribeEventgroup) [UnicastLimit>Subscription-
Counter] /SubscriptionCounter++ send(SubscribeEventgroupAck)

FROM Subscribed (Unicast)
TO Not Subscribed
WITH receive(StopSubscribeEventgroup) [SubscriptionCounter==1]
/SubscriptionCounter- disableEvents()

FROM Subscribed (Unicast)
TO Not Subscribed
WITH TTL_expired [SubscriptionCounter==1] /SubscriptionCounter-  // 仅剩的一个客户端订阅还超时了
disableEvents()

FROM Not Subscribed
TO Subscribed (Multicast)
WITH
receive(SubscribeEventgroup) [UnicasLimit==0] /enable-
MulticastEvents() SubscriptionCounter++ send(SubscribeEvent-
groupAck)

FROM Subscribed (Multicast)
TO Not Subscribed
WITH
receive(StopSubscribeEventgroup) [SubscriptionCounter==1
&& UnicasLimit==0] /SubscriptionCounter- disableMulticastEvents
()

FROM Subscribed (Multicast)
TO Not Subscribed
WITH TTL_expired [SubscriptionCounter==1 && UnicasLimit==0] /-
SubscriptionCounter- disableMulticastEvents()

FROM Subscribed (Multicast)
TO Subscribed (Multicast)
WITH receive(SubscribeEventgroup) /SubscriptionCounter++

FROM Subscribed (Multicast)
TO Subscribed (Multicast)
WITH receive(StopSubscribeEventgroup) [SubscriptionCounter>UnicastLimit+1] /SubscriptionCounter-

FROM Subscribed (Multicast)
TO Subscribed (Multicast)
WITH
TTL_expired [SubscriptionCounter>UnicastLimit+1] / SubscriptionCounter-

FROM Subscribed (Unicast)
TO Subscribed (Unicast)
WITH
receive(StopSubscribeEventgroup) [SubscriptionCounter>1] / SubscriptionCounter-

FROM Subscribed (Unicast)
TO Subscribed (Unicast)
WITH TTL_expired [SubscriptionCounter>1] /SubscriptionCounter-

FROM Subscribed (Unicast)
TO Subscribed (Multicast)
WITH
receive(SubscribeEventgroup) [SubscriptionCounter>=Uni-
castLimit] /SubscriptionCounter++ send(SubscribeEventgroupAck)
switchToMulticastEvents()

FROM Subscribed (Multicast)
TO Subscribed (Unicast)
WITH
receive(StopSubscribeEventgroup) [Subscrip-
tionCounter==UnicasLimit+1] /switchToUnicastEvents()
SubscriptionCounter-

FROM Subscribed (Multicast)
TO Subscribed (Unicast)
WITH TTL_expired [SubscriptionCounter==UnicasLimit+1] /switch-
ToUnicastEvents() SubscriptionCounter-

Figure 5.26: Publish/Subscribe State Diagram (server behavior for adaptive unicast/multicast eventgroups)

[PRS_SOMEIPSD_00134] 单播事件和通知切换到组播时会依赖UDP通信[所以这些能切换到组播的事件/通知在配置endpoint的时候要选择UDP，即unreliable ([PRS_SOMEIPSD_00802])，SOME/IP-SD支持自动从单播切换到组播模式来传输事件和通知，这个需要再事件/通知的配置上这配置订阅的threshold数量。(RS_SOMEIPSD_00025, RS_SOMEIPSD_00016)

注意:

SOME/IP-SD将事件/通知的传输方式自动从单播切换到组播，这个特性为什么只支持UDP的原因如下：

• TCP只能使用单播
• 有些场景下，例如发送的数据过大，受限于MTU，只能使用TCP。

[PRS_SOMEIPSD_00470] SOME/IP-SD隐式支持静态配置通信的Endpoint以及订阅者的注册，这样就可以不依赖SD消息获取服务实例的位置和订阅者的信息。(SOMEIPSD_00025, RS_SOMEIPSD_00015)

注意:

使用静态配置取代SOME/IP-SD消息来完成服务实例的定位和订阅并不是标准SOME/IP-SD协议中的内容。

[PRS_SOMEIPSD_00472] 下列Entry项目还能通过单播通信传输：

• Subscribe Eventgroup
• Stop Subscribe Eventgroup
• Subscribe Eventgroup Ack
• Subscribe Eventgroup Nack

(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00808] 如果配置了SUBSCRIBE_RETRY_MAX选项，并且这个SUBSCRIBE_RETRY_MAX大于0，客户端在发送了Subscribe Eventgroup Entry并且在指定时间 (SUBSCRIBE_RETRY_DELAY配置) 没有收到ACK/NACK的情况下应当尝试重新订阅事件组。重试次数超过了SUBSCRIBE_RETRY_MAX，那么客户端就应当放弃重新发送订阅。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00809] SOME/IP Service的服务端发送的Offer Service Entry中TTL如果设置为0xFFFFFF，那么客户端就可以将SUBSCRIBE_RETRY_MAX设置为INF (Inifinate)，只要没有收到服务端发送的Subscribe Eventgroup ACK/NACK，那么客户端就应当继续发送订阅消息。(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00851] 事件/通知的发送从单播切换到组播是依赖了 MULTICAST_THRESHOLD :

• 如果 MULTICAST_THRESHOLD 配置为0，那么会禁用从单播到组播的自动切换功能，根据客户端的订阅报文中的Endpoint是单播还是组播决定使用哪种方式。
• 如果 MULTICAST_THRESHOLD 配置为1，那么会禁用从单播到组播的自动切换功能，SOME/IP 客户端和服务端之间该事件/通知的通信方式只能走组播。
• 如果 MULTICAST_THRESHOLD 配置大于1，并且当前该事件/通知的订阅者数量（根据Endpoint数量来算）大于等于 MULTICAST_THRESHOLD ，那么服务端应当使用组播的方式发送事件/通知。
• 如果 MULTICAST_THRESHOLD 配置大于1，而当前当前该事件/通知的订阅者数量（根据Endpoint数量来算）小于 MULTICAST_THRESHOLD，那么