SOMEIP-SD协议介绍

1 介绍与概述

该协议规范详细说明了协议SOME/IP服务发现（SOME/IP-SD）的格式、消息序列和语义。

服务发现协议的主要任务是在车内通信中传达称为服务的功能实体的可用性，以及控制事件消息的发送行为。这允许仅向需要它们的接收方发送事件消息（发布/订阅）。此处描述的解决方案也称为SOME/IP-SD（基于IP的可扩展面向服务的中间件 - 服务发现）。

1.1 协议目的和目标

SOME/IP-SD用于

        - 定位服务实例。

        - 检测服务实例是否正在运行。

        - 实现发布/订阅处理。

1.2 协议的适用性

SOME/IP SD可用于汽车车辆网络中的服务发现。

1.2.1 约束和假设

目前SOME/IP-SD仅支持基于IP的通信。

1.3 依赖关系

1.3.1 对其他协议层的依赖

SOME/IP-SD依赖于SOME/IP。SOME/IP本身支持TCP和UDP通信，但SOME/IP SD受限于仅在UDP上使用SOME/IP。

2首字母缩写和缩写

4 协议规范

4.1 SOME/IP 服务发现（SOME/IP-SD）

4.1.1 概述

SOME/IP-SD 用于：

        - 定位服务实例。

        - 检测服务实例是否正在运行。

        - 实现发布/订阅处理。

在车载网络中，服务实例的位置通常是已知的；因此，服务实例的状态是首要关注的。服务的位置（即 IP 地址、传输协议和端口号）属于次要关注的范畴。

4.1.1.1 术语和定义

每个接口应使用单独的服务器服务实例，如果服务实例需要在多个接口上提供。 

每个接口应使用单独的客户端服务实例，如果服务实例需要配置为使用多个不同的接口访问。 

 4.1.2 SOME/IP-SD 消息格式

 4.1.2.1 通用要求

SOME/IP-SD 消息应通过 UDP 发送。

SOME/IP-SD 头格式如图 4.1 所示。

服务发现消息应以 SOME/IP 头开始，如图 4.1 所示。 

服务发现消息应使用 Service-ID（16 位）为 0xFFFF。

服务发现消息应使用 Method-ID（16 位）为 0x8100。

服务发现消息应使用由 SOME/IP 规定的 uint32 长度字段。这意味着长度以字节为单位测量，从长度字段后的第一个字节开始，到 SOME/IP-SD 消息的最后一个字节结束。 

服务发现消息的 Client-ID（16 位）应设置为 0x0000，因为只存在单个 SOME/IP-SD 实例。 

如果配置了客户端 ID 前缀，它也应用于 SOME/IP-SD

服务发现消息应具有 Session-ID（16 位），并根据 SOME/IP 要求进行处理。 

Session-ID（SOME/IP 头）应为每个发送的 SOME/IP-SD 消息递增。

 Session-ID（SOME/IP 头）应从 1 开始，并且即使包装后也应为 1。 

Session-ID（SOME/IP 头）不应设置为 0。

SOME/IP-SD Session ID 处理是基于“通信关系”进行的，即广播以及每个对等体的单播

服务发现消息的 Protocol-Version（8 位）应为 0x01。 

服务发现消息的 Interface-Version（8 位）应为 0x01。

服务发现消息的 Message Type（8 位）应为 0x02（通知）。

服务发现消息的 Return Code（8 位）应为 0x00（E_OK）。

4.1.2.2 SOME/IP-SD 头部

SOME/IP-SD 应该使用如图 4.2 所示的 SOME/IP 进行传输。 

SOME/IP-SD 头部应该以一个名为 Flags 的 8 位字段开始，参见图 4.3 中 Flags 的表示。 

 SOME/IP-SD Flags 字段的第一个标志（最高位）称为 Reboot Flag，见图 4.3 

SOME/IP-SD 头部的 Reboot Flag 在每次重新启动后设置为 1，直到 SOME/IP 头部中的 Session-ID 回绕并重新开始为 1 为止。在这个回绕之后，Reboot Flag 被设置为 0。 

 reboot flag 和 Session ID 的信息应该分别保留用于多播和单播。

 reboot flag 和 Session ID 的信息应该针对每个发送者-接收者关系（即源地址和目标地址）分别保留。

注意：
这意味着应该为发送和接收分别保留独立的计数器。
发送：
        - 应该有一个用于多播的计数器。
        - 应该为单播的每个对等体保留一个单独的计数器。
接收：
        - 应该为多播的每个对等体保留一个计数器。
        - 应该为单播的每个对等体保留一个计数器。

检测重新启动应该按照以下方式进行（使用通信伙伴的当前数据包的新值和上次收到的旧值）：
        - 如果 old.reboot==0 而 new.reboot==1，则检测到重新启动。
        - 如果 old.reboot==1、new.reboot==1 并且 old.session_id>=new.session_id，则检测到重新启动。
以下方式不够，因为我们没有可靠的通信：
        - 如果 new.reboot==1 并且 old.session_id>=new.session_id，则检测到重新启动。 

 SOME/IP-SD Flags 的第二个标志（次高位）称为 Unicast Flag，见图 4.3。 

SOME/IP-SD 头部的 Unicast Flag 应设置为 Unicast（即 1），因为这意味着支持使用单播进行接收。 

注意：
Unicast Flag 是历史 SOME/IP 版本的遗留，仅出于兼容性原因保留。除此之外的使用非常有限。

SOME/IP-SD Flags 的第三个标志（次高位）称为 Explicit Initial Data Control Flag，表示 ECU 支持显式初始数据控制，见图 4.3。

注意：
这意味着 ECU 理解并遵守 Eventgroup Entries 中的 Initial Data Requested Flag。

Explicit Initial Data Control Flag 应始终设置为 1，表示 ECU 支持此功能。 

注意：
此标志允许与旧的 SOME/IP-SD 实现（例如 AUTOSAR 4.2）保持兼容性，这些实现不支持此功能并将此标志设置为 0。新版本应始终支持该功能，因此它们必须始终将此标志设置为 1。

在 Flag 字段中的未定义位在发送时应设置为 '0'，在接收时应忽略。 

Flags 之后，SOME/IP-SD 头部应该有一个名为 Reserved 的 24 位字段。

SOME/IP-SD 头部之后应该是 Entries Array。

 Entries 应按照它们到达的顺序进行处理。

SOME/IP-SD 头部的 Entries Array 之后应该是 Option Array。

SOME/IP-SD 消息的 Entries Array 和 Options Array 应该以 uint32 的长度字段开始，该字段计算以下数据的字节数：entries 或 options。

4.1.2.3 Entry 格式

服务发现应支持将多个 entries 组合在一个服务发现消息中。 

注意：
这些 entries 用于同步服务实例的状态和 Publish/Subscribe 处理。

存在两种类型的 entries：Service Entry Type 用于Service，Eventgroup Entry Type 用于 Eventgroup。

Service Entry Type 应该是 16 字节大小，并按照以下顺序包含以下字段，如图 4.1 所示：
        - Type Field [uint8]：编码为 FindService (0x00) 和 OfferService (0x01)。
        - Index First Option Run [uint8]：此运行的第一个选项在选项数组中的索引。
        - Index Second Option Run [uint8]：此运行的第二个选项在选项数组中的索引。
        - Number of Options 1 [uint4]：描述第一个选项运行使用的选项数量。
        - Number of Options 2 [uint4]：描述第二个选项运行使用的选项数量。
        - Service-ID [uint16]：描述此 entry 所涉及的服务或服务实例的 Service ID。
        - Instance ID [uint16]：描述此 entry 所涉及的服务实例的 Service Instance ID，如果是所有服务实例，则设置为 0xFFFF。
        - Major Version [uint8]：编码服务（实例）的主版本。
        - TTL [uint24]：以秒为单位描述 entry 的生命周期。
        - Minor Version [uint32]：编码服务的次版本。

SOME/IP-SD Service Entry Type 如图 4.4 所示。 

Eventgroup Entry 应该是 16 字节大小，并按照以下顺序包含以下字段，如图 4.5 所示：
        - Type Field [uint8]：编码为 Subscribe (0x06) 和 SubscribeAck (0x07)。
        - Index First Option Run [uint8]：此运行的第一个选项在选项数组中的索引。
        - Index Second Option Run [uint8]：此运行的第二个选项在选项数组中的索引。
        - Number of Options 1 [uint4]：描述第一个选项运行使用的选项数。
        - Number of Options 2 [uint4]：描述第二个选项运行使用的选项数。
        - Service-ID [uint16]：描述此 entry 所涉及的服务或服务实例的 Service ID。
        - Instance ID [uint16]：描述此 entry 所涉及的服务实例的 Service Instance ID，如果是所有服务实例，则设置为 0xFFFF。
        - Major Version [uint8]：编码此 eventgroup 所属服务实例的主版本。
        - TTL [uint24]：以秒为单位描述 entry 的生命周期。
        - Reserved [uint8]：应设置为 0x00。
        - Initial Data Requested Flag [1 位] (I Flag)：如果 Server 应发送初始数据，则应设置为 1。
        - Reserved2 [uint3]：如果没有另外指定，则应设置为 0x0 (参见 [PRS_SOMEIPSD_00391] 和 [PRS_SOMEIPSD_00394])。
        - Counter [uint4]：用于区分相同订阅者的相同 Subscribe Eventgroups。如果未使用，则设置为 0x0。
        - Eventgroup ID [uint16]：传输 Eventgroup 的 ID。
SOME/IP-SD Eventgroup Entry Type 如图 4.5 所示。

**引用条款选项**
使用条款项的以下字段，可以通过条款项引用选项：
        - Index First Option Run：第一个选项运行的选项数组索引。索引 0 表示 SOME/IP-SD 数据包的第一个选项。
        - Index Second Option Run：第二个选项运行的选项数组索引。索引 0 表示 SOME/IP-SD 数据包的第一个选项。
        - Number of Options 1：第一个选项运行的数量。长度为 0 表示选项运行中没有选项。
        - Number of Options 2：第二个选项运行的数量。长度为 0 表示选项运行中没有选项。
存在两种不同的选项运行：First Option Run 和 Second Option Run。
支持两种不同选项运行的原因：期望存在两种不同类型的选项，即在多个 SOME/IP-SD 条目之间共享的选项和对每个 SOME/IP-SD 条目不同的选项。支持两个不同的选项运行是在保持传输格式高效的同时支持这两种选项类型的最有效方式。

每个选项运行应引用此运行的第一个选项和选项的数量。
如果选项数设置为零，则认为选项运行为空。
对于空运行，索引（即 Index First Option Run 和/或 Index Second Option Run）应设置为零。 

4.1.2.4Options 格式

选项用于传输有关条目的附加信息。这包括例如服务实例的可达性信息（IP 地址、传输协议、端口号）。

为了标识选项类型，每个选项应以以下方式开始：
        - Length [uint16]：指定选项的字节长度。
        - Type [uint8]：指定选项的类型。
        - Discardable Flag [1 位]：指定接收 ECU 是否可以丢弃该选项。
- 位 1 到位 7 保留，应设置为 0。

 长度字段应覆盖选项的所有字节，但不包括长度字段和类型字段。 
如果下一个选项跟在具有可变长度的选项后面，取决于第一个选项的长度，第二个选项可能对齐不正确。

如果接收 ECU 不支持此选项，则可丢弃标志应设置为 1。

Configuration Option

配置选项用于传输任意配置字符串。这允许编码附加信息，例如服务的名称或其配置。

配置选项的格式应如下：
        - Length [uint16]：应设置为配置选项占用的总字节数，不包括 16 位长度字段和 8 位类型标志。
        - Type [uint8]：应设置为 0x01。
        - Discardable Flag [1 位]：如果接收方可以丢弃该选项，则应设置为 1。
        - 位 1 到位 7 保留，应设置为 0。
        - ConfigurationString [变长]：应携带配置字符串。

配置选项应指定基于 DNS TXT 和 DNS-SD 格式的一组名称值对。
配置字符串的格式应以单字节长度字段开始，该字段描述了此长度字段后面的字节数。在长度字段之后，应跟随一个带有指定长度的字符序列。 

在每个字符序列之后，预期将跟随另一个长度字段和随后的字符序列，直到长度字段设置为 0x00 为止。
在将长度字段设置为 0x00 后，不应跟随任何字符。 
字符序列应编码键和可选值。  字符序列应包含等号字符（"="，0x3D），以分隔键和值。 
键不应包含等号字符，并且至少应包含一个非空格字符。 "键" 的字符应为可打印的 US-ASCII 值（0x20-0x7E），不包括 "="（0x3D）。 

"=" 不应是序列的第一个字符。
对于没有 "=" 的字符序列，该键应解释为存在。
对于以 "=" 结尾的字符序列，该键应解释为存在且值为空。
单个配置选项中的相同键的多个条目应得到支持。 
配置选项的格式如图 4.6 所示。

Load Balancing Option

**负载均衡选项**

负载均衡选项用于根据优先级和权重优化服务的不同实例，以便客户端基于这些设置选择服务实例。此选项将附加到Offer Service条目。

负载均衡选项应携带类似于 DNS-SRV 记录的优先级和权重，用于平衡不同服务实例的负载。 
在查找服务的所有服务实例（Service Instance 设置为 0xFFFF）时，客户端应选择具有最高优先级且符合客户端特定标准的服务实例。
  - 注意：客户端特定标准可能由客户端应用程序在选择提供的服务实例时应用。这些标准未在此规范中定义，例如，可能会限制适当实例 ID 的范围。
 如果具有最高优先级（优先级字段中最低值）的多个服务实例，则应基于服务实例的权重随机选择服务实例。 
如果Offer Service条目未引用负载均衡选项且提供了多个服务实例，则客户端应处理没有负载均衡选项的服务实例，就好像它们的优先级最低一样。 
在查找服务的特定服务实例（Service Instance 设置为除 0xFFFF 以外的任何值）时，不应用负载均衡选项的评估。
负载均衡选项的格式应如下：
          - Length [uint16]：应设置为 0x0005。
          - Type [uint8]：应设置为 0x02。
          - Discardable Flag [1 bit]：如果接收方可以丢弃此选项，则应设置为 1。
          - Bit 1 到 Bit 7 保留，应设置为 0。
          - Priority [uint16]：携带此实例的优先级。较低的值表示较高的优先级。
          - Weight [uint16]：携带此实例的权重。较大的值表示较高的被选择概率。

IPv4 Endpoint Option

**IPv4端点选项**

IPv4端点选项由SOME/IP-SD实例用于表示相关的端点。端点包括本地IP地址、传输层协议（例如UDP或TCP）以及发送方的端口号。这些端口也用于事件和通知事件。

IPv4端点选项应使用类型0x04。
IPv4端点选项应指定IPv4地址、使用的传输层协议（ISO/OSI层4）以及其端口号。 
IPv4端点选项的格式应如下：
          - Length [uint16]：应设置为0x0009。
          - Type [uint8]：应设置为0x04。
          - Discardable Flag [1 bit]：应设置为0。
          - Bit 1 到 Bit 7 保留，应设置为0。
          - IPv4地址 [uint32]：应传输单播IP地址，使用四个字节。
          - Reserved [uint8]：应设置为0x00。
          - 传输协议（L4-Proto）[uint8]：应设置为基于IANA/IETF类型的传输层协议（ISO/OSI层4）（0x06：TCP，0x11：UDP）。
          - 传输协议端口号（L4-Port）[uint16]：应设置为第4层协议的端口。

 IPv4端点选项应如图4.9所示。

**IPv4端点选项的使用**

服务器应使用IPv4端点选项与Offer Service条目一起，以指示服务所服务的端点。这包括最多一个UDP端点和最多一个TCP端点。

服务器在Offer Service条目中引用的端点也应用作事件的源。这包括端点选项中传输协议的源IP地址和源端口号。客户端应使用IPv4端点选项与Subscribe Eventgroup条目一起，以指示其IP地址和其准备接收事件的UDP和/或TCP端口号。 

客户端应使用IPv4端点选项与Subscribe Eventgroup条目一起，以指示其准备接收事件的IP地址和UDP和/或TCP端口号。

IPv6 Endpoint Option

**IPv6端点选项的使用**

IPv6端点选项应使用类型0x06。

 IPv6端点选项的格式应如下：
          - 长度 [uint16]: 应设置为0x0015。
          - 类型 [uint8]: 应设置为0x06。
          - 可丢弃标志 [1位]: 应设置为0。
          - 第1位到第7位为保留位，应设置为0。
          - IPv6地址 [uint128]: 应以16字节的形式传输单播IP地址。
          - 保留 [uint8]: 应设置为0x00。
          - 传输协议 (L4-Proto) [uint8]: 应根据IANA/IETF类型设置为传输层协议 (ISO/OSI层4) (0x06: TCP, 0x11: UDP)。
          - 传输协议端口号 (L4-Port) [uint16]: 应设置为传输层端口号 (例如，30490)。
 

SOME/IP-SD IPv6端点选项应如图4.10所示。

服务器应使用IPv6端点选项与提供服务的条目一起，以通知服务可用的端点。即最多一个UDP端点和最多一个TCP端点。

服务器引用的Offer Service条目中的端点也应用作事件的源。也就是说，端点选项中的传输协议的源IP地址和源端口号。

客户端应使用IPv6端点选项与Subscribe Eventgroup条目一起，以通知其准备接收事件的IP地址和UDP和/或TCP端口号。

IPv4 Multicast Option

 IPv4 Multicast Option应该由服务器引用，以公告IPv4组播地址、传输层协议（ISO/OSI第4层）以及多播事件和多播通知事件发送到的端口号。当前仅支持UDP作为传输层协议。

 IPv4 Multicast Option应该使用Type 0x14。

IPv4 Multicast Option应该指定IPv4地址、使用的传输层协议（ISO/OSI第4层）以及其端口号。

IPv4 Multicast Option的格式如下：
          - Length [uint16]: 设置为0x0009。
          - Type [uint8]: 设置为0x14。
          - Discardable Flag [1 bit]: 设置为0。
          - 位1到位7被保留，应设置为0。
          - IPv4-Address [uint32]: 以四个字节传输组播IP地址。
          - Reserved [uint8]: 应设置为0x00。
          - Transport Protocol (L4-Proto) [uint8]: 根据IANA/IETF类型（0x11: UDP）设置为传输层协议。
          - Transport Protocol Port Number (L4-Port) [uint16]: 应设置为第4层协议的端口。
  

SOME/IP-SD IPv4 Multicast Option如图4.11所示。

服务器应引用IPv4 Multicast Option，该选项编码服务器将向其发送组播事件和通知事件的IPv4组播地址和端口号。

IPv6 Multicast Option

IPv6组播选项由服务器用于宣布IPv6组播地址、第4层协议和组播事件以及组播通知事件发送到的端口号。目前仅支持UDP作为传输层协议（ISO/OSI第4层）。

 IPv6组播选项应使用类型0x16。
 IPv6组播选项应指定IPv6地址、使用的传输层协议（ISO/OSI第4层）和端口号。
 IPv6组播选项的格式如下：
           - Length [uint16]: 应设置为0x0015。
           - Type [uint8]: 应设置为0x16。
           - Discardable Flag [1 bit]: 应设置为0。
           - Bit 1到Bit 7保留，应为0。
           - IPv6地址 [uint128]: 应将组播IP地址传输为16字节。
           - 保留 [uint8]: 应设置为0x00。
           - 传输协议（L4-Proto）[uint8]: 应设置为基于IANA/IETF类型的传输层协议（0x11: UDP）。
           - 传输协议端口号（L4-Port）[uint16]: 应设置为第4层协议的端口。
 Subscribe Eventgroup Ack消息应引用IPv6组播选项而不是IPv6端点选项。
 SOME/IP-SD IPv6组播选项如图4.12所示。
 服务器应引用IPv6组播选项，其中编码了服务器将发送组播事件和通知事件的IPv6组播地址和端口号。

IPv4 SD Endpoint Option

IPv4 SD Endpoint Option用于传输发送者SD实现的端点（即IP地址和端口）。这用于在无法使用IP地址和/或端口号的情况下识别SOME/IP-SD实例。

注意：
这用于在无法使用IP地址和/或端口号的情况下识别SOME/IP-SD实例。一个用例是一个ECU上的代理服务发现，它处理另一个ECU的多播流量。

IPv4 SD Endpoint Option应包含在任何SD消息中，最多一次。

 如果SOME/IP-SD消息通过IPv4传输，则应仅包括IPv4 SD Endpoint Option。

 如果存在的话，IPv4 SD Endpoint Option应该是选项数组中的第一个选项。

 IPv4 SD Endpoint Option不应由任何SD Entry引用。

如果SD消息中包含IPv4 SD Endpoint Option，则接收的SD实现应使用此选项的内容而不是源IP地址和源端口。

注意：
这对于回答接收到的SD消息（例如，在查找后提供的Offer或提供后的订阅或订阅后的订阅Ack）以及重新启动检测（基于SD Endpoint Option而不是基于地址）非常重要。

 IPv4 SD Endpoint Option应使用Type 0x24。

 IPv4 SD Endpoint Option应指定用于服务发现的发送者的IPv4地址，传输层协议（ISO/OSI层4）和端口号。

 IPv4 SD Endpoint Option的格式应如下：

        - Length [uint16]：应设置为0x0015。
        - Type [uint8]：应设置为0x24。
        - Discardable Flag [1 bit]：应设置为0。
        - Bit 1到bit 7应保留并应设置为0。
        - IPv4地址 [uint32]：应传输SOME/IP-SD的单播IP地址，以四个字节表示。
        - 保留 [uint8]：应设置为0x00。
        - 传输协议（L4-Proto）[uint8]：应设置为SOME/IP-SD的传输层协议（当前为：0x11 UDP）。
        - 传输协议端口号（L4-Port）[uint16]：应设置为SOME/IP-SD的传输层端口（当前为：30490）。

IPv6 SD Endpoint Option

IPv6 SD Endpoint Option用于传输发送者SD实现的端点（即IP地址和端口）。这用于在无法使用IP地址和/或端口号的情况下识别SOME/IP-SD实例。

注意：
这用于在无法使用IP地址和/或端口号的情况下识别SOME/IP-SD实例。一个用例是一个ECU上的代理服务发现，它处理另一个ECU的多播流量。

[SOME/IP-SD IPv6 SD Endpoint Option如图4.14所示]

 IPv6 SD Endpoint Option可以包含在任何SD消息中，最多一次。

如果存在的话，IPv6 SD Endpoint Option应该是选项数组中的第一个选项。

IPv6 SD Endpoint Option不应由任何SD Entry引用。

 如果SD消息中包含IPv6 SD Endpoint Option，则接收的SD实现应使用此选项的内容而不是用于回答此SD消息的源IP地址和源端口。

IPv6 SD Endpoint Option应使用Type 0x26。

 IPv6 SD Endpoint Option应指定用于服务发现的发送者的IPv6地址，传输层协议（ISO/OSI层4）和端口号。

IPv6 SD Endpoint Option的格式应如下：

        - Length [uint16]：应设置为0x0015。
        - Type [uint8]：应设置为0x26。
        - Discardable Flag [1 bit]：应设置为0。
        - Bit 1到bit 7应保留并应设置为0。
        - IPv6地址 [uint128]：应传输SOME/IP-SD的单播IP地址，以16个字节表示。
        - 保留 [uint8]：应设置为0x00。
        - 传输协议（L4-Proto）[uint8]：应设置为SOME/IP-SD的传输层协议（当前为：0x11 UDP）。
        - 传输协议端口号（L4-Port）[uint16]：应设置为SOME/IP-SD的传输层端口（当前为：30490）。
 

4.1.2.5 Service Entries

Find Service Entry

 Find Service条目类型应用于查找服务实例，仅当服务的当前状态未知时发送（未接收到当前有效的Service Offer）。

 Find Service条目应按以下方式设置条目字段：

        - Type应设置为0x00（FindService）。
        - Service ID应设置为要查找的服务的Service ID。
        - Instance ID应设置为0xFFFF，如果要返回所有服务实例。如果只返回单个服务实例，则应将其设置为特定服务实例的Instance ID。
        - Major Version应设置为0xFF，表示将返回任何版本的服务。如果设置为与0xFF不同的值，则只返回具有此特定Major Version的服务。
        - Minor Version应设置为0xFFFFFFFF，表示将返回任何版本的服务。如果设置为与0xFFFFFFFF不同的值，则只返回具有此特定Minor Version的服务。
        - TTL应设置为Find Service条目的生存期。在此生存期之后，将视Find Service条目为不存在。
        - 如果TTL设置为0xFFFFFF，则将认为Find Service条目在下次重启之前有效。
        - TTL不应设置为0x000000，因为这被视为Stop Offer Service Entry。
 

发送方不应在Find Service Entry中引用Endpoint Options或Multicast Options。

 接收方应在Find Service Entry中忽略Endpoint Options和Multicast Options。

 在Find Service Entry中仍应允许使用其他选项（既非Endpoint也非Multicast Options）。

Offer Service Entry

 Offer Service条目类型应用于向其他通信伙伴提供服务。

 Offer Service条目应按以下方式设置条目字段：

        - Type应设置为0x01（OfferService）。
        - Service ID应设置为提供的服务实例的Service ID。
        - Instance ID应设置为提供的服务实例的Instance ID。
        - Major Version应设置为提供的服务实例的Major Version。
        - Minor Version应设置为提供的服务实例的Minor Version。
        - TTL应设置为服务实例的生命周期。在此生命周期之后，将视服务实例为未提供。
        - 如果TTL设置为0xFFFFFF，则将认为Offer Service条目在下次重启之前有效。
        - TTL不应设置为0x000000，因为这被视为Stop Offer Service Entry。
 Offer Service条目应始终引用至少一个IPv4或IPv6 Endpoint Option，以指示服务的可达性。

 对于服务所需的每个传输层协议（即UDP和/或TCP），如果支持IPv4，则应添加一个IPv4 Endpoint option。

 对于服务所需的每个传输层协议（即UDP和/或TCP），如果支持IPv6，则应添加一个IPv6 Endpoint option。

Stop Offer Service Entry

Stop Offer Service条目类型应用于停止提供服务实例。

 Stop Offer Service条目应与它们正在停止的Offer Service条目完全相同，除了：

        - TTL应设置为0x000000。
 

Options在Entries中的使用

 表4.1应显示SOME/IP-SD选项类型与允许的Entry类型的关系：

4.1.2.6 Endpoint Handling for Services and Events

 服务发现应使用Endpoint和Multicast Options中传输的IP地址和端口号覆盖静态配置的值，如果静态配置的值与这些选项中的值不同。

 Endpoint Options中的IP地址和端口号也应用于传输事件和通知事件。

在UDP的情况下，端点选项应用于事件和通知事件的源地址和源端口，也是客户端可以发送方法请求的地址。

 在TCP的情况下，端点选项应用于客户端需要打开TCP连接以接收使用TCP传输的事件的IP地址和端口。

 SOME/IP应允许服务同时使用UDP和TCP。

 发送的消息由哪个底层传输协议发送应由配置确定：服务可以同时使用UDP和TCP端点。但是，对于服务的每个元素，应配置是使用TCP还是UDP。

注意：在配置中需要限制通过TCP/UDP提供哪些方法和哪些事件。这也意味着无法通过TCP和UDP提供相同的事件。

Service Endpoints
Offer Service条目引用的Endpoint Options表示：

        - 服务器上服务实例可访问的IP地址和端口号。
        - 服务实例从中发送事件的IP地址和端口号。

 该服务实例的事件不得从Offer Service条目中的给定的端点之外的任何端点发送。

如果ECU提供多个服务实例，则这些服务实例的SOME/IP消息应由Offer Service条目引用的Endpoint Options中传输的信息区分。

Eventgroup Endpoints
Subscribe Eventgroup条目引用的Endpoint Options还应用于为该服务实例发送单播UDP或TCP的SOME/IP事件。

因此，Subscribe Eventgroup条目引用的Endpoint Options是客户端侧的IP地址和端口号。

使用TCP连接传输TCP事件，客户端在发送Subscribe Eventgroup条目之前已经打开了该连接。参见第4.1.2.4章。

初始事件应使用从服务器到客户端的单播传输。

 Subscribe Eventgroup Ack条目应引用多达1个用于Internet协议（IPv4或IPv6）的Multicast Option。

 Multicast Option应设置为UDP作为传输协议。

客户端应尽快打开Subscribe Eventgroup Ack条目引用的Multicast Option中指定的端点，以避免错过多播事件。

示例：图4.15显示了具有不同端点和多播Option的示例：

        - 服务器在Server UDP-Endpoint SU和Server TCP-Endpoint ST上提供服务实例
        - 客户端打开TCP连接
        - 客户端使用Client UDP-Endpoint CU（单播）和Client TCP-Endpoint CT发送Subscribe Eventgroup条目
        - 服务器用Multicast MU回答Subscribe Eventgroup Ack条目

然后进行以下操作：

        - 客户端在服务器上调用一个方法
        - 从CU到SU发送请求，从SU到CU发送响应
        - 对于TCP，这将是：从ST到CT发送请求，从ST到CT发送RESPONSE
        - 服务器发送单播UDP事件：从SU到CU
        - 服务器发送单播TCP事件：从ST到CT
        - 服务器发送多播UDP事件：从SU到MU

请注意，多播端点在接收端，即客户端上使用多播IP地址，并且TCP不能用于多播通信。

4.1.3 Service Discovery Messages

所有SD消息都应发送到SD_PORT。

 SD_PORT应用作SD单播/多播消息的源端口。

所有单播SD消息应具有SD_PORT作为目标端口，除非SD Endpoint选项定义了不同的端口。

所有SD多播消息应使用SD_MULTICAST_IP发送。

利用先前指定的标头格式，可以构建包含一个或多个条目的不同条目和消息。下面详细解释了具体的条目及其标头布局。

4.1.3.1 Eventgroup Entry

Subscribe Eventgroup Entry

1. 订阅事件组（Subscribe Eventgroup）条目类型应用于订阅事件组（RS_SOMEIPSD_00015）。
2. 订阅事件组条目应按以下方式设置条目字段：
   - Type应设置为0x06（SubscribeEventgroup）。
   - Service ID应设置为包含所订阅事件组的服务实例的Service ID。
   - Instance ID应设置为包含所订阅事件组的服务实例的Instance ID。
   - Major Version应设置为所订阅事件组的服务实例的Major Version。
   - Eventgroup ID应设置为所订阅事件组的Eventgroup ID。
   - Minor Version应设置为所订阅事件组的服务实例的Minor Version。
   - TTL应设置为订阅的生命周期。
     - 如果设置为0xFFFFFF，则Subscribe Eventgroup条目将被视为有效，直到下次重新启动。
     - TTL不应设置为0x000000，因为这被视为Stop Offer Service Entry。
   - Reserved应设置为0x00，直到另行通知。
   - Initial Data Requested Flag应设置为1，如果客户端发送序列中的第一个订阅以触发发送初始事件，则设置为0。
   - Reserved2应设置为三个0位。
   - Counter应用于区分同一服务的同一事件组的并行订阅（仅在端点上的差异）。如果未使用，则设置为0x0。
   （RS_SOMEIPSD_00015）

3. Subscribe Eventgroup条目应引用一个或两个IPv4和/或一个或两个IPv6 Endpoint Options（一个用于UDP，一个用于TCP）（RS_SOMEIPSD_00015, RS_SOMEIPSD_00025）。

Stop Subscribe Eventgroup Entry

Stop Subscribe Eventgroup entry类型用于停止订阅事件组。

Stop Subscribe Eventgroup条目应设置与停止的Subscribe Eventgroup条目完全相同的字段，除非：
- TTL应设置为0x000000。
 

停止Subscribe Eventgroup条目应引用与Subscribe Eventgroup条目相同的选项。这包括但不限于Endpoint和Configuration选项。

Subscribe Eventgroup Acknowledgement (Subscribe Eventgroup Ack) Entry

 Subscribe Eventgroup Acknowledgment entry类型用于指示Subscribe Eventgroup条目已被接受。

Subscribe Eventgroup Acknowledgment条目应设置以下字段：
        - Type应设置为0x07 (SubscribeEventgroupAck)。
        - Service ID、Instance ID、Major Version、Eventgroup ID、TTL、Reserved、Initial Data Requested Flag、Reserved2和Counter应与正在回答的Subscribe Eventgroup中的值相同。
 

引用通过多播传输的事件和通知事件的Subscribe Eventgroup Ack条目应引用IPv4 Multicast Option和/或IPv6 Multicast Option。c(RS_SOMEIPSD_00015)

Subscribe Eventgroup Negative Acknowledgement (Subscribe Eventgroup
Nack) Entry

Subscribe Eventgroup Negative Acknowledgment entry类型用于指示Subscribe Eventgroup条目未被接受。

Subscribe Eventgroup Negative Acknowledgment条目应设置以下字段：
        - Type应设置为0x07 (SubscribeEventgroupAck)。
        - Service ID、Instance ID、Major Version、Eventgroup ID、Counter和Reserved应与正在回答的Subscribe中的值相同。
        - TTL应设置为0x000000。
 

 不接受Subscribe Eventgroup的原因包括（但不限于）：
        - Service ID、Instance ID、Eventgroup ID和Major Version的组合是未知的
        - 客户端未打开所需的TCP连接
        - 引用选项时发生问题
        - 服务器的资源问题
 

当客户端收到SubscribeEventgroupNack作为对需要TCP连接的SubscribeEventgroup的回答时，客户端应检查TCP连接，并在需要时重新启动TCP连接。

Rational:
服务器可能已经丢失了TCP连接，而客户端没有。
检查TCP连接可能包括以下内容：
        - 检查是否接收到其他Eventgroups的数据。
        - 发送Magic Cookie消息并等待TCP ACK。
        - 重新建立TCP连接。

4.1.4 Service Discovery Communication Behavior

 SOME/IP服务发现应通过尽可能合并条目来减少服务发现消息的数量。

4.1.4.1 Startup Behavior

 就发送条目而言，服务发现对于每个服务实例或事件组至少应具有以下三个阶段：
        - 初始等待阶段
        - 重复阶段
        - 主要阶段
 

注意：
一个实际实现的状态机将需要不仅仅是这三个阶段的状态。例如，本地服务可能仍然处于停机状态，而远程服务可能已经是已知的（不再需要查找）。

当用于该服务实例的接口上的链路正常且应用程序请求客户端服务时，服务发现应进入初始等待阶段。

当用于该服务实例的接口上的链路正常且服务器服务可用时，服务发现应进入初始等待阶段。

注意：
链路可能已经建立，但服务在服务器端尚不可用。这里的"Systems has started"意味着已启动所需的应用程序以及可能的外部传感器和执行器。基本上，该服务实例所需的功能必须准备好提供服务，并且在某个应用程序要求之后才适用于查找服务。

 在进入初始等待阶段后，在为服务实例发送第一条消息之前，服务发现应等待基于INITIAL_DELAY的时间。

 INITIAL_DELAY应定义为最小延迟和最大延迟。

 等待时间应通过选择在INITIAL_DELAY的最小值和最大值之间的随机值来确定。

为了减少消息数量，服务发现应对以下情况使用相同的随机值：
        - 不同类型的多个条目，以便将它们合并在一起。
        - 不同的服务实例，以便可以将多个提供一起合并。
 

当不涉及随机延迟但可以同时发送消息时，SOME/IP服务发现应将条目合并在一起。

例如，一个消息中的所有Subscribe Eventgroup条目应该一起回答。

发送第一条消息后，将进入此服务实例/这些服务实例的重复阶段。

服务发现应在重复阶段等待基于REPETITIONS_BASE_DELAY的时间。

在重复阶段每发送一条消息后，延迟时间将加倍。

 在重复阶段，服务发现应仅发送最多REPETITIONS_MAX条目。

 在接收相应的Offer条目后，应停止发送Find条目，跳转到主要阶段，该阶段不发送Find条目。

如果将REPETITIONS_MAX设置为0，则应跳过重复阶段，并在初始等待阶段之后进入主要阶段。

在重复阶段之后，将进入服务实例的主要阶段。

在进入主要阶段后，提供者应在发送第一条Offer条目消息之前等待1*CYCLIC_OFFER_DELAY。

在主要阶段，如果配置了CYCLIC_OFFER_DELAY，Offer消息应周期性地发送。

对于特定服务实例的每条消息后，服务发现将在1*CYCLIC_OFFER_DELAY后等待发送此服务实例的下一条消息。

在主要阶段，不允许对Find条目（Find Service和Find Eventgroup）进行周期性消息。

 Subscribe EventGroup条目应由周期性发送的Offer条目触发。

[PRS_SOMEIPSD_00416] d 例子：
初始等待阶段：
        - 在范围(INITIAL_DELAY_MIN, _MAX)内等待random_delay
        - 发送消息（Find Service和Offer Service条目）
重复阶段（REPETITIONS_BASE_DELAY=100ms，REPETITIONS_MAX=2）：
        - 等待20 * 100ms
        - 发送消息（Find Service和Offer Service条目）
        - 等待21 * 100ms
        - 发送消息（Find Service和Offer Service条目）
主要阶段（只要消息处于活动状态且定义了CYCLIC_OFFER_DELAY）：
        - 等待

CYCLIC_OFFER_DELAY
        - 发送消息（Offer Service条目）
4.1.4.2 Server Answer Behavior

4.1.4.2 服务器应答行为
 服务发现应延迟回答通过多播SOME/IP-SD消息接收的条目，使用配置项REQUEST_RESPONSE_DELAY。对于以下两种情况有效：
        - 在接收多播的Find条目（多播）后，接收Offer条目（单播或多播）
        - 在接收多播的Offer条目后，接收Subscribe条目（单播）

如果单播消息以单播消息作为回答，则REQUEST_RESPONSE_DELAY不适用。

REQUEST_RESPONSE_DELAY应由最小值和最大值指定。

 实际延迟应在REQUEST_RESPONSE_DELAY的最小值和最大值之间随机选择。

对于基本实现，所有Find Service条目（无论单播标志的状态如何）都应通过单播回答，使用Offer Service条目进行传输。

出于优化目的，应作为选项支持以下行为：
        - 在主要阶段接收到Unicast Flag设置为1的Find消息，如果上次Offer发送时间不到1/2 CYCLIC_OFFER_DELAY，则应通过单播响应进行回答。
        - 在主要阶段接收到Unicast Flag设置为1的Find消息，如果上次Offer发送时间为1/2 CYCLIC_OFFER_DELAY或更长，则应通过多播RESPONSE进行回答。
        - 接收到Unicast Flag设置为0（多播）的Find消息，应通过多播响应进行回答。（注意：这仅在早期迁移方案中需要，将来将不再需要）

4.1.4.3 Shutdown Behavior

 当ECU的服务器服务实例处于重复和主要阶段并正在停止时，应发送Stop Offer Service条目。 

当服务器服务实例在初始等待阶段、重复阶段或主要阶段因链路中断时，服务发现应在链路恢复且服务仍然可用时进入初始等待阶段。

当客户端服务实例在初始等待阶段、重复阶段或主要阶段因链路中断时，服务发现应在链路恢复且服务仍然被请求时进入初始等待阶段。

 当服务器发送Stop Offer Service条目时，应在服务器端删除此服务实例的所有订阅。

当客户端接收到Stop Offer Service条目时，应在客户端删除此服务实例的所有订阅。

当客户端接收到Stop Offer Service条目时，客户端不应发送Find Service条目，而应等待Offer Service条目或状态更改（应用程序、网络管理、以太网链路或类似状态）。

当ECU的客户端服务实例处于主要阶段并正在停止（即释放服务实例）时，SD应发送Stop Subscribe Eventgroup条目以取消订阅所有订阅的Eventgroup。

当整个ECU被关闭时，应发送Stop Offer Service条目以停止所有服务实例，并对于Eventgroups，应发送Stop Subscribe Eventgroup条目。

4.1.4.4 State Machines
本节显示了客户端和服务器的状态机。
SOME/IP服务状态机服务器显示在图4.16中。

SOME/IP服务状态机客户端显示在图4.17中。

4.1.4.5 SOME/IP-SD Mechanisms and Errors

在本节中，将讨论SOME/IP-SD在出现错误的情况下（例如，丢失或损坏的数据包）的情况。这也可以理解为对使用的机制和可能的配置的基本原理。

软状态协议：SOME/IP-SD被设计为软状态协议，这意味着条目具有生命周期，并且需要刷新以保持有效（将TTL设置为最大值将关闭此功能）。

初始等待阶段：引入初始等待阶段有两个原因：为了去除启动ECU的事件以避免流量突增，并允许ECU在SD消息中收集多个条目。

重复阶段：引入重复阶段是为了实现客户端和服务器的快速同步。如果客户端启动较晚，它将非常快地找到服务器。如果服务器较晚启动，客户端可以很快被找到。重复阶段以指数方式增加两个消息之间的时间，以避免过载情况阻止系统同步。

主要阶段：在主要阶段中，SD试图稳定状态，从而通过不再发送查找服务而减少数据包的传输速率，而只在周期间隔内发送提供服务（例如，每1秒一次）。

请求-响应延迟：SOME/IP-SD应配置为通过请求-响应延迟延迟对组播消息中的条目的响应。这在具有许多ECU的大型系统中非常有用。当发送具有许多条目的SD消息时，许多来自不同ECU的响应会同时到达，并对接收所有这些响应的ECU施加很大的压力。

4.1.4.6 Error Handling

图4.18显示了对于传入的SOME/IP-SD消息的简化错误处理过程。

检查是否至少有足够的字节用于一个空的SOME/IP-SD消息，即消息至少为12字节长。如果检查失败，将丢弃该消息，不采取进一步的操作。

如果接收到的条目的服务ID未知，则应忽略该条目。

如果接收到的条目的实例ID未知，则应忽略该条目。

如果接收到的条目的主版本未知，则应忽略该条目。

如果接收到的条目的事件组ID未知，则应忽略该条目。这仅适用于事件组条目。

如果Entries数组的长度具有无效的大小（即，条目数组将超过消息大小），则应在不采取进一步操作的情况下丢弃该消息。

检查每个接收到的条目的引用选项：
          - 引用的选项存在。
          - 条目引用所有必需的选项（例如，使用单播的提供的事件组在接收到Subscribe Eventgroup条目时需要一个单播端点选项）。
          - 条目仅引用受支持的选项（例如，不支持多播数据接收的必需事件组不支持Subscribe Eventgroup ACK条目中的多播端点选项）。
          - 条目引用的选项之间没有冲突（即，具有相互矛盾内容的同一类型的两个选项）。
          - 引用条目的选项的类型已知或者丢弃标志设置为1。
          - 引用选项的类型对于该条目是允许的[PRS_SOMEIPSD_00583]，或者丢弃标志设置为1。
          - 引用选项的长度与选项的类型一致。
          - 端点选项具有有效的L4-Protocol字段。
          - 选项是有效的（例如，多播端点选项应使用多播IP地址）。

  注意：如果一个条目引用了由服务发现实现知道但服务不需要的选项（例如，Offer引用了TCP和UDP选项，而客户端仅使用UDP，或者Subscribe Eventgroup条目引用了UDP端点选项，而服务器仅使用多播事件传输），则应处理该条目。

检查TCP连接是否已存在（仅适用于配置了TCP用于Eventgroup和接收到Subscribe Eventgroup条目的情况）。

检查是否有足够的资源剩余（例如，套接字连接）。

 如果接收到的Find条目的[PRS_SOMEIPSD_00130]检查失败，则应忽略该条目。

 如果接收到的Offer条目的[PRS_SOMEIPSD_00130]检查失败，则应忽略该条目。

如果接收到的Subscribe Eventgroup条目的[PRS_SOMEIPSD_00130]、[PRS_SOMEIPSD_00131]或[PRS_SOMEIPSD_00132]检查失败，则应发送一个Subscribe Eventgroup NACK条目。

如果接收到的Subscribe Eventgroup ACK条目的[PRS_SOMEIPSD_00130]或[PRS_SOMEIPSD_00132]检查失败，则应处理该条目，但不应将订阅视为成功。

条目引用的选项如果：
          - 选项类型未知（即尚未指定或接收方不支持），并且丢弃标志设置为1。
          - 该选项是冗余的（即，该条目引用了相同类型和相同内容的另一个选项）。
          - 该选项不是必需的（例如，只使用多播的提供的事件组在接收到Subscribe Eventgroup条目时不需要一个单播端点选项，尽管仍然允许）。

  则应忽略引用条目的选项。

4.1.5 Announcing non-SOME/IP protocols with SOME/IP-SD

除了SOME/IP之外，车辆内部还使用其他通信协议，例如网络管理、诊断或闪存更新。这些通信协议可能需要通信服务实例或具有事件组。

针对非SOME/IP协议（应用程序协议本身不使用SOME/IP，但通过SOME/IP SD发布），应使用特殊的Service-ID，并使用配置选项添加进一步的信息：
          - Service-ID应设置为0xFFFE（保留）。
          - 应使用与SOME/IP服务和事件组描述的Instance-ID。
          - 应添加Configuration Option，并包含一个键为"otherserv"的条目，以及由系统部门确定的可配置非空值。
  
SOME/IP服务不应使用Configuration Option中的otherserv字符串。

 在宣布非SOME/IP服务实例时，对于Find Service/Offer Service/Request Service条目，应使用otherserv字符串。

有效otherserv字符串示例："otherserv=internaldiag"。无效的otherserv字符串示例："otherserv"，以及无效的otherserv字符串示例："otherserv="。

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

注：与SOME/IP请求/响应机制相反，可能存在这样的情况，即客户端需要从服务器获取一组参数，但不希望每次都请求该信息。这些称为通知，涉及事件和字段。

 所有需要事件和/或通知事件的客户端应在运行时使用SOME/IP-SD向服务器注册。

使用SOME/IP-SD条目Offer Service，服务器提供向客户端推送通知的功能；因此，它应该用作订阅的触发器。

每个客户端应对来自服务器的SOME/IP-SD Offer Service条目作出响应，只要客户端仍然对接收此事件组的通知/事件感兴趣，就应使用SOME/IP-SD Subscribe Eventgroup条目。
如果客户端能够通过SOME/IP-SD消息的重新启动标志可靠地检测到服务器的重新启动，那么客户端可以选择仅在服务器重新启动后才回答Offer Service消息，如果配置为这样做（TTL设置为最大值）。客户端确保在服务器的SOME/IP-SD消息丢失时，这可以可靠地工作。 

如果客户端对Eventgroup没有活动的订阅，它应通过设置Initial Data Requested Flag来明确请求初始事件。

如果客户端发送额外的Subscribe Eventgroup条目，并且先前的Subscribe的TTL尚未过期，则客户端不应请求Initial Events。客户端明确请求Initial Events的原因包括但不限于：
          - 客户端当前未订阅Eventgroup。
          - 在上一个Subscribe Eventgroup条目之后，客户端看到了链路断开/链路重新连接。
          - 客户端在上一个常规Subscribe Eventgroup之后未收到Subscribe Eventgroup Ack。
          - 客户端检测到此服务的服务器的重新启动。

如果客户端订阅了包括一个或多个相同事件或字段的两个或更多事件组，则服务器不应为该字段发送重复的事件或通知事件。这不包括初始事件。

 具有客户端链路丢失的发布/订阅如图4.21所示。

作为隐式发布发送Offer Service条目的服务器必须维护Subscribe Eventgroup消息的状态，以便知道是否必须发送通知/事件。

客户端应通过发送TTL=0的SOME/IP-SD Subscribe Eventgroup消息（Stop Subscribe Eventgroup参见[PRS_SOMEIPSD_00389]）从服务器中注销。 

发布/订阅的注册/注销行为如图4.22所示。

服务器上的SOME/IP-SD应在发送事件或通知事件后发生相关的SOME/IP错误时删除订阅。错误包括但不限于无法与通信伙伴建立联系和TCP连接的错误。

如果在发送事件或通知事件后发生相关的SOME/IP错误，服务器上的SOME/IP-SD应删除订阅。错误包括但不限于无法与通信伙伴建立联系和TCP连接的错误。

在服务器上的发布/订阅中发生链路丢失的情况如图4.23所示。

客户端在发送Subscribe Eventgroup条目之前，应与服务器建立TCP连接，如果服务通过TCP提供并且客户端根据配置请求通过TCP获取Eventgroup。 

如果服务通过TCP提供并且客户端根据配置请求通过TCP获取Eventgroup，则客户端在发送Subscribe Eventgroup条目之前应与服务器建立TCP连接。

客户端发送Subscribe Eventgroup条目后，服务器应发送Subscribe Eventgroup Ack条目。

 客户端应在等待对Subscribe Eventgroup条目的Subscribe Eventgroup Ack条目进行确认。如果在下一个Subscribe Eventgroup条目发送之前未收到该Subscribe Eventgroup Ack条目，则客户端应执行以下操作：
            - 如果服务器的“Explicit Initial Data Control Flag”设置为0，则在相同的SOME/IPSD消息中发送Stop Subscribe Eventgroup条目和Subscribe Eventgroup条目。
            - 如果服务器的“Explicit Initial Data Control Flag”设置为1，则将下一个Subscribe Eventgroup Entry的“Initial Data Requested Flag”设置为1。

 对于由Find Service条目触发的Offer Service条目，不应用要求[PRS_SOMEIPSD_00463]。这意味着由单播Offer Service条目触发的Subscribe Eventgroup Ack条目也不会被监视，正如在单播Offer Service条目时不会发送Stop Subscribe Eventgroup条目/Subscribe Eventgroup条目一样。

  解释：如果客户端作为对单播提供的响应发送Subscribe Eventgroup条目，并且在之后立即而在服务器发送Subscribe Eventgroup Ack条目之前立即接收到多播提供，那么客户端不应投诉（即停止订阅/订阅）尚未收到的确认。

如果初始值对于字段（如字段）的值是关键的，并且客户端的SOME/IP-SD标头中的“Explicit Initial Data Control Flag”设置为0，则服务器应在发送Subscribe Eventgroup Ack之后立即发送第一批通知/事件（即初始事件）。

如果服务器收到了一个Subscribe Eventgroup条目，其中“Initial Data Requested Flag”设置为0，且SOME/IP-SD标头中的“Explicit Initial Data Control Flag”设置为1，则服务器不应发送通知/事件（即初始事件）。

 如果服务器收到了一个Subscribe Eventgroup条目，其中“Initial Data Requested Flag”设置为1，且SOME/IP-SD标头中的“Explicit Initial Data Control Flag”设置为1，则服务器应在发送Subscribe Eventgroup Ack之后立即发送通知/事件（即初始事件）。

不允许在订阅时发送事件的初始值（纯事件而不是字段）。

字段通知器的事件消息应在订阅时发送（字段而不是纯事件）。

如果订阅已经有效并且通过Subscribe Eventgroup条目进行更新，不应发送初始事件。

接收Stop Subscribe / Subscribe组合将触发字段通知器的初始事件。

初始事件应在Subscribe Eventgroup Ack之后发送。

以图4.24所示的方式进行发布/订阅状态图（服务器对于单播eventgroups的行为）。

如果客户端订阅了同一服务实例的不同eventgroups，这些eventgroups都包含同一字段但在不同的SOME/IP-SD消息中，则服务器应分别为每个订阅发送该字段的初始事件。

如果客户端订阅了同一服务实例的不同eventgroups，这些eventgroups都包含同一字段但在不同的SOME/IP-SD消息中，则服务器应分别为每个订阅发送该字段的初始事件。

如果客户端订阅了同一服务实例的不同eventgroups，这些eventgroups在同一SOME/IP-SD消息中都包含同一字段，则服务器可以选择不发送该字段的初始事件超过一次。

  注：这意味着服务器可以通过仅在其体系结构支持的情况下发送初始事件一次来进行优化。

- [Publish/Subscribe State Diagram (server behavior for multicast eventgroups)](链接到图表4.25)的行为如图4.25所示。

Publish/Subscribe State Diagram (server behavior for adaptive unicast/multicast eventgroups)的行为如图4.26所示。

SOME/IP-SD应支持在达到订阅者数量的配置阈值时自动从单播切换到多播。

SOME/IP SD协议应支持通信端点的隐式配置和订阅者的注册。这些配置应基于静态配置，不使用网络上的任何SD消息。

注：根据项目的不同，可能存在在根本不使用网络上的任何服务发现的情况下，基于静态配置使用服务的用例。在这种隐式注册的情况下，没有交换任何查找或订阅消息，但服务可以直接使用。这种预配置不是SOME/IP或SOME/IP SD的一部分。因此，它们的配置和实现是项目特定的。

以下条目应仅通过单播传输：
- Subscribe Eventgroup
- Stop Subscribe Eventgroup
- Subscribe Eventgroup Ack
- Subscribe Eventgroup Nack
 

4.1.7 Reserved and special identifiers for SOME/IP and SOME/IP-SD.

保留和特殊的Service-ID概述：表4.2

保留和特殊的Instance-ID概述：表4.3

保留和特殊的Method-ID/Event-ID概述：表4.4

保留的Eventgroup-ID概述：表4.5

Service 0xFFFF的Method-ID和Event-ID：表4.6

除了"otherserv"，配置选项还支持其他名称。以下列表概述了保留名称：表4.7

5 配置参数

以下章节总结了所有使用的配置参数。

6 协议使用

6.1 SOME/IP-SD 选项的安全考虑

应检查接收的SOME/IP-SD消息，确保在Endpoint选项和SD Endpoint选项中接收的IP地址在拓扑上是正确的（即在SOME/IP-SD所用的IP子网的参考IP地址），并且应忽略不正确的拓扑的IP地址以及引用这些选项的条目。
注意：
这意味着只有相同子集中的客户端和服务器是可访问的。

6.2 强制特性集和基本行为

在本节中，讨论了服务发现的强制特性集以及相关的配置约束。这允许进行最小限度的实现，不包括可能对当前用例不需要的可选或信息性功能。
以下信息被定义为合规性检查清单。如果某个功能没有实现，那么该实现被认为不符合SOME/IP-SD的基本功能集。
 应实现以下条目类型：
- Find Service
- Offer Service
- Stop Offer Service
- Subscribe Eventgroup
- Stop Subscribe Eventgroup
- Subscribe Eventgroup Ack
- Subscribe Eventgroup Nack

当需要IPv4时，应实现以下选项类型：
- IPv4 Endpoint Option
- IPv4 Multicast Option
- Configuration Option
- IPv4 SD Endpoint Option（至少接收）

当需要IPv6时，应实现以下选项类型：
- IPv6 Endpoint Option
- IPv6 Multicast Option
- Configuration Option
- IPv6 SD Endpoint Option（至少接收）
 服务器端应实现以下行为/反应：
- 服务器应根据配置在初始等待阶段、重复阶段和主要阶段提供服务。
- 服务器应在多播地址（由SD_MULTICAST_IP定义）上使用多播提供服务（重复阶段和主要阶段）。
- 服务器在重复阶段不需要回复Find Service。
- 服务器应在主要阶段回答Find Service，并使用单播（不基于单播标志的优化）的Offer Service。
- 服务器在关闭时应发送Stop Offer Service。
- 服务器应根据本规范收到的Subscribe Eventgroup和Stop Subscribe Eventgroup做出反应。
- 服务器应发送Subscribe Eventgroup Ack和Subscribe Eventgroup Nack使用单播。
- 服务器应支持基于SOME/IP-SD订阅的发送（即扇出）SOME/IP事件消息的控制。这可能包括基于多播发送事件。
- 服务器应支持触发初始SOME/IP事件消息。
 客户端端应实现以下行为/反应：
- 客户端应使用Find Service条目和多播（在SD_MULTICAST_IP定义的多播地址上）仅在重复阶段查找服务。
- 如果定期Offer Service到达，则客户端应停止查找服务。
- 客户端应对服务器的Offer Service做出响应，使用单播SD消息，该消息包括客户端当前希望订阅的服务器消息的所有Subscribe Eventgroups。
- 客户端应按照本文档中规定的方式解释并响应Subscribe Eventgroup Ack和Subscribe Eventgroup Nack。
 客户端应支持以下行为和配置约束：
- 客户端应能够处理仅指定SD定时的情况下的Eventgroups。这意味着对于初始等待阶段、重复阶段和主要阶段的所有定时中，只有TTL被配置。这意味着客户端仅应对服务器的Offer Service做出反应。
- 客户端应对Offer Service作出响应，并在没有配置Request-Response-Delay的情况下即时回答，这意味着它不应等待而是立即回答。
 

] 客户端和服务器应按照本文档中规定的方式实现"Reboot Detection"并相应地做出反应。这包括但不限于：
- 根据本规范设置Session ID和Reboot Flag。
- 仅用于发送多播SD消息的Session ID计数器。
- 用于与该ECU交换多播SD消息的每个Unicast关系的Session ID计数器。
- 根据本规范理解Session ID和Reboot Flag。
- 为与该ECU交换Unicast SD消息的每个ECU保留的Multicast Session ID计数器。
- 为与该ECU交换Unicast SD消息的每个ECU保留的Unicast Session ID计数器。
- 根据本规范检测重新启动并相应地做出反应。
- 根据本规范正确解释IPv4和IPv6 SD Endpoint Options以进行重新启动检测。
c(RS_SOMEIPSD_00018, RS_SOMEIPSD_00007)
[PRS_SOMEIPSD_00504] d 客户端和服务器应按照本文档中规定的方式实现"服务和事件的端点处理"。这包括但不限于：
- 如果需要UDP，则将1个Endpoint Option UDP添加到Offer Service。
- 如果需要TCP，则将1个Endpoint Option TCP添加到Offer Service。
- 如果需要通过UDP发送事件，则将1个Endpoint Option UDP添加到Subscribe Eventgroup。
- 如果需要通过TCP发送事件，则将1个Endpoint Option TCP添加到Subscribe Eventgroup。
- 如果需要多播事件，则将1个Multicast Option UDP添加到Subscribe Eventgroup Ack。
- 根据上述描述传输的Endpoint和Multicast选项的理解和操作。
- 用这些Endpoint和Multicast选项的信息覆盖预配置的值（例如IP地址和端口）。
- 将传入的IPv4和IPv6 Endpoint Options解释为SD端点而不是外层的地址和端口号。
 客户端和服务器应实现显式请求初始事件。

6.3 迁移和兼容性

6.3.1 支持同一服务的多个版本

为了支持迁移方案，ECU应支持作为不同不兼容版本的同一服务的服务和使用。
为了支持具有多个版本的服务，需要以下操作：
- 服务器应为该服务的每个主版本提供该服务实例一次。
- 客户端应为每个支持的主版本或应使用Major Version为0xFF（所有版本）的每个支持的主版本查找服务实例。
- 客户端应订阅其需要的服务版本的事件。
- 所有SOME/IP-SD条目应使用相同的Service-ID和Instance-ID，但使用不同的Major Versions。
- 服务器必须根据它们到达的套接字、Message-ID、Major Versions的情况将消息进行多路复用，并根据这些条件在内部传递到正确的接收者。