SOME/IP-SD--协议英文原文讲解1

前言 SOME/IP协议越来越多的用于汽车电子行业中，关于协议详细完全的中文资料却没有，所以我将结合工作经验并对照英文原版协议做一系列的文章。基本分三大块：

1. SOME/IP协议讲解

2. SOME/IP-SD协议讲解

3. python/C++举例调试讲解

---

1 Introduction and overview This protocol specification specifies the format, message sequences, and semantics of the Protocol SOME/IP Service Discovery (SOME/IP-SD). The main tasks of the Service Discovery Protocol are communicating the availability of functional entities called service instances in the in-vehicle communication as well as controlling the send behavior of event messages. This allows sending only event messages to receivers requiring them (Publish/Subscribe). The solution described here is also known as SOME/IP-SD (Scalable service-Oriented MiddlewarE over IP - Service Discovery). SD报文 负责： 1. 声明 服务实例-功能实体 的可用性（哪些event） 2. 控制这些事件的发送行为

1.1 Protocol purpose and objectives SOME/IP-SD is used to • Locate service instances. 锁定服务实例 • Detect when service instances are available. 检测可用的服务实例 • Implement the Publish/Subscribe handling. 实现 发布和订阅的 处理 通过接收到的SOME/IP-SD报文的header解析 实现

1.2 Applicability of the protocol SOME/IP-SD can be used for service discovery in vehicle networks. 1.2.1 Constraints and assumptions The SOME/IP-SD has the following constraints: • SOME/IP-SD supports only IP-based communication. • The network communication design has to consider the following limitations, if a subscription is handled via multicast communication: – Initial events should be transported via unicast. 限制： 1. 仅支持IP 通信 2. 多播通信处理订阅 -- 初始事件发送应是单播发送

1.3 Dependencies 1.3.1 Dependencies to other protocol layers SOME/IP-SD depends on SOME/IP. SOME/IP itself supports both TCP and UDP communications but SOME/IP-SD uses only UDP (See [PRS_SOMEIPSD_00220]). 协议依赖：SD报文 全使用UDP报文

服务实例相关的配置及可用性 不能静态配置到 client端

客户端发现自己需要的服务并订阅对应的事件组，是不需要提前知道服务端ip/port的

client需要动态连接到server 不需静态配置。

什么是静态配置： client端 配置了哪个服务 谁提供 server端配置哪个服务谁订阅

 

5 Protocol specification

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

5.1.1 General SOME/IP-SD is used to • Locate service instances. • Detect if service instances are running. • Implement the Publish/Subscribe handling. Inside the vehicular network service instance locations are commonly known; therefore, the state of the service instance is of primary concern. The location of the service (i.e. IP-Address, transport protocol, and port number) are of secondary concern. 发现谁有自己需要的服务 就订阅谁 -- 的过程 整个过程的实现 先判断 服务是否提供 实例是否可用 在判断ip port 传输协议的合理性

5.1.1.1 Terms and Definitions [PRS_SOMEIPSD_00238] Upstream requirements: RS_SOMEIPSD_00003 A separate server service instance shall be used per network interface if a service needs to be offered on multiple network interfaces. 如果一个服务需要在多个网络接口端提供，则实例ID要不一样

[PRS_SOMEIPSD_00239] Upstream requirements: RS_SOMEIPSD_00003 A separate client service instance shall be used per network interface if a service needs to be configured to be accessed using multiple different network interfaces. 如果一个服务 需要被多个网络接口 访问 则需要不通的client实例区分

5.1.2 SOME/IP-SD Message Format

5.1.2.1 General Requirements [PRS_SOMEIPSD_00220] Upstream requirements: RS_SOMEIPSD_00010 SOME/IP-SD messages shall be sent over UDP. SD报文只能通过UDP传输

SD报文的格式如下：

 

[PRS_SOMEIPSD_00250] Upstream requirements: RS_SOMEIPSD_00001 Service Discovery Messages shall start with a SOME/IP header. SD报文开始应该是SOME/IP头

[PRS_SOMEIPSD_00250] can be seen in Figure 5.1. [PRS_SOMEIPSD_00151] Upstream requirements: RS_SOMEIPSD_00001 Service Discovery messages shall use the Service-ID (16 Bits) of 0xFFFF.固定值

[PRS_SOMEIPSD_00152] Upstream requirements: RS_SOMEIPSD_00001 dService Discovery messages shall use the Method-ID (16 Bits) of 0x8100.固定值

[PRS_SOMEIPSD_00153] Upstream requirements: RS_SOMEIPSD_00001 Service Discovery messages shall use a uint32 length field as specified by SOME/IP. That means that the length is measured in bytes and starts with the first byte after the length field and ends with the last byte of the SOME/IP-SD message. SOME/IP-SD头中 三个Length字段描述的长度 并不包含自己字段本身长度的4个字节 描述了length字段后面的SOME/IP头的字节 到 SD报文结束后的所有字符。

[PRS_SOMEIPSD_00154] Upstream requirements: RS_SOMEIPSD_00001 Service Discovery messages shall have a Client-ID (16 Bits) set to 0x0000, since there exists only a single SOME/IP-SD instance. 如果只有一个client实例订阅对应的服务，那么client-id 要设置为0

[PRS_SOMEIPSD_00157] Upstream requirements: RS_SOMEIPSD_00001 The Session-ID (SOME/IP header) shall be incremented for every SOME/IP-SD message sent. 递增

[PRS_SOMEIPSD_00158] Upstream requirements: RS_SOMEIPSD_00001 The Session-ID (SOME/IP header) shall start with 1 and be 1 even after wrapping. 按1递增翻转后从1开始

[PRS_SOMEIPSD_00159] Upstream requirements: RS_SOMEIPSD_00001 The Session-ID (SOME/IP header) shall not be set to 0. 不能设置为0

[PRS_SOMEIPSD_00160] Upstream requirements: RS_SOMEIPSD_00001 SOME/IP-SD Session ID handling is done per "communication relation", i.e. multicast as well as unicast per peer (see [PRS_SOMEIPSD_00255]).

[PRS_SOMEIPSD_00255] Upstream requirements: RS_SOMEIPSD_00006 The Reboot Flag of the SOME/IP-SD Header shall be set to one for all messages after reboot until the Session-ID in the SOME/IP-Header wraps around and thus starts with 1 again. After this wrap around the Reboot Flag is set to 0. 这两段内容（[PRS_SOMEIPSD_00160] 和 [PRS_SOMEIPSD_00255]）描述了 **SOME/IP-SD（Service Discovery）** 协议中 **Session ID** 和 **Reboot Flag** 的处理规则。以下是详细解释：

---

### **[PRS_SOMEIPSD_00160]** #### 核心内容 1. **Session ID 的处理**：    - SOME/IP-SD 的 Session ID 是按 **通信关系（communication relation）** 处理的。    - 通信关系包括：      - **组播（multicast）**：向多个接收方发送消息。      - **单播（unicast）**：向特定对等方（peer）发送消息。

2. **通信关系的定义**：    - 每个通信关系都有独立的 Session ID 管理。    - 例如，组播通信和每个单播对等方的通信都有各自的 Session ID 空间。

---

### **[PRS_SOMEIPSD_00255]** #### 核心内容 1. **Reboot Flag 的设置**：    - 在系统重启后，SOME/IP-SD 消息的 **Reboot Flag** 应设置为 `1`。    - 该标志表示系统已重启，接收方可以根据此标志采取适当的处理措施。

2. **Session ID 回绕**：    - 当 SOME/IP 头部的 **Session ID** 回绕（即从最大值回到 `1`）时，Reboot Flag 应设置为 `0`。    - 这表示系统已完成重启后的初始化，Session ID 重新开始计数。

---

### 关键点 1. **Session ID 的作用**：    - Session ID 用于标识消息的会话上下文，特别是在需要处理多个并发消息时。    - 在 SOME/IP-SD 中，Session ID 是按通信关系独立管理的。

2. **Reboot Flag 的作用**：    - Reboot Flag 用于通知接收方系统已重启。    - 接收方可以根据 Reboot Flag 决定是否需要重新初始化或重新订阅服务。

3. **Session ID 回绕**：    - Session ID 是一个有限范围的计数器（例如 8 位或 16 位）。    - 当 Session ID 达到最大值并回绕时，Reboot Flag 应设置为 `0`，表示系统状态已稳定。

---

### 实现建议 1. **Session ID 管理**：    - 为每个通信关系（组播和每个单播对等方）维护独立的 Session ID 计数器。    - 在发送 SOME/IP-SD 消息时，递增相应的 Session ID。

2. **Reboot Flag 设置**：    - 在系统重启后，将所有 SOME/IP-SD 消息的 Reboot Flag 设置为 `1`。    - 当 Session ID 回绕时，将 Reboot Flag 设置为 `0`。

3. **接收方处理**：    - 接收方在接收到 Reboot Flag 为 `1` 的消息时，应重新初始化或重新订阅服务。    - 接收方在接收到 Reboot Flag 为 `0` 的消息时，可以正常处理消息。

---

### 示例场景 #### 场景 1：系统重启 - 系统重启后，发送 SOME/IP-SD 消息：   - Reboot Flag = `1`   - Session ID = `1` - 接收方检测到 Reboot Flag 为 `1`，重新初始化或重新订阅服务。

#### 场景 2：Session ID 回绕 - 系统运行一段时间后，Session ID 达到最大值并回绕：   - Reboot Flag = `0`   - Session ID = `1` - 接收方检测到 Reboot Flag 为 `0`，正常处理消息。

---

### 总结 1. **Session ID 管理**：    - SOME/IP-SD 的 Session ID 是按通信关系（组播和单播）独立管理的。

2. **Reboot Flag 设置**：    - 系统重启后，Reboot Flag 应设置为 `1`，直到 Session ID 回绕。    - Session ID 回绕后，Reboot Flag 应设置为 `0`。

3. **接收方处理**：    - 接收方根据 Reboot Flag 决定是否需要重新初始化或重新订阅服务。

[PRS_SOMEIPSD_00161] - 固定值 Upstream requirements: RS_SOMEIPSD_00001 Service Discovery messages shall have a Protocol-Version (8 Bits) of 0x01. [PRS_SOMEIPSD_00162] - 固定值 Upstream requirements: RS_SOMEIPSD_00001 Service Discovery messages shall have a Interface-Version (8 Bits) of 0x01. [PRS_SOMEIPSD_00163] - 固定值 Upstream requirements: RS_SOMEIPSD_00001 Service Discovery messages shall have a Message Type (8 bits) of 0x02 (Notification). [PRS_SOMEIPSD_00164] - 固定值 Upstream requirements: RS_SOMEIPSD_00001 Service Discovery messages shall have a Return Code (8 bits) of 0x00 (E_OK).