前言
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).