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

1. SOME/IP协议讲解

2. SOME/IP-SD协议讲解

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

---

4.2.2 Request/Response Communication

One of the most common communication patterns is the request/response pattern.
One communication partner (Client) sends a request message, which is answered by
another communication partner (Server).
最常用的通信模型 就是 请求/响应模型，client请求 server回复响应.

[PRS_SOMEIP_00920]发送请求包 按照下面的步骤 就没错
Upstream requirements: RS_SOMEIP_00007
For the SOME/IP request message the client has to do the following for payload and
header:
• Construct the payload
• Set the Message ID based on the method the client wants to call
• Set the Length field to 8 bytes (for the part of the SOME/IP header after the length
field) + length of the serialized payload
8个字节是header length字段 后面的长度 
  +
payload的长度
• Optionally set the Request ID to a unique number (shall be unique for client only)
• Set the Protocol Version according [PRS_SOMEIP_00052]
• Set the Interface Version according to the interface definition
• Set the Message Type to REQUEST (i.e. 0x00)
• Set the Return Code to 0x00

[PRS_SOMEIP_00921]
Upstream requirements: RS_SOMEIP_00028, RS_SOMEIP_00007
To construct the payload of a request message, all input or inout arguments of the
method shall be serialized according to the order of the arguments within the signature
of the method.
不管是请求还是响应的参数列表 ，在序列化payload的时必须要按照规范的参数顺序进行序列化。

[PRS_SOMEIP_00922]
Upstream requirements: RS_SOMEIP_00007
The server builds the header of the response based on the header of the client’s
request and does in addition:
• Construct the payload
• take over the Message ID from the corresponding request
• Set the length to the 8 Bytes + new payload size
8个字节是header length字段 后面的长度 
  +
payload的长度
• take over the Request ID from the corresponding request
• Set the Message Type to RESPONSE (i.e. 0x80) or ERROR (i.e. 0x81)
• set Return Code to a return code according to [PRS_SOMEIP_00191].

[PRS_SOMEIP_00923]
Upstream requirements: RS_SOMEIP_00028, RS_SOMEIP_00007
To construct the payload of a response message, all output or inout arguments of the
method shall be serialized according to the order of the arguments within the signature
of the method.

[PRS_SOMEIP_00927]
Upstream requirements: RS_SOMEIP_00007
A server shall not sent a response message for a request with a specific Request ID
until the corresponding request message has been received.
如果client请求的 requestID 与pending的回复中的requestID 重复，则忽略这个消息 不做回复。

[PRS_SOMEIP_00928]
Upstream requirements: RS_SOMEIP_00007
A client shall ignore the reception of a response message with a specific Request ID,
when the corresponding request message has not yet been sent completely.
client收到重复的 requestID 的回复不做处理

4.2.3 Fire&Forget Communication

Requests without response message are called fire&forget.
不需要响应的请求 称为 fire&forget 很多需求规范也可以简写为F&F

[PRS_SOMEIP_00924] 组装格式如下
Upstream requirements: RS_SOMEIP_00006
For the SOME/IP request-no-return message the client has to do the following for
payload and header:
• Construct the payload
• Set the Message ID based on the method the client wants to call
• Set the Length field to 8 bytes (for the part of the SOME/IP header after the length
field) + length of the serialized payload
8个字节是header length字段 后面的长度 
  +
payload的长度
• Optionally set the Request ID to a unique number (shall be unique for client only)
• Set the Protocol Version according [PRS_SOMEIP_00052]
• Set the Interface Version according to the interface definition
• Set the Message Type to REQUEST_NO_RETURN (i.e. 0x01)
• Set the Return Code to 0x00

[PRS_SOMEIP_00171]
Upstream requirements: RS_SOMEIP_00006
Fire & Forget messages shall not return an error. Error handling and return codes
shall be implemented by the application when needed.
没有错误返回 上层应用自己记录处理

4.2.4 Notification Events

Notifications describe a general Publish/Subscribe-Concept. Usually the server publishes a service to which a client subscribes. On certain cases the server will send the
client an event, which could be for example an updated value or an event that occurred.
SOME/IP is used only for transporting the updated value and not for the publishing and
subscription mechanisms. These mechanisms are implemented by SOME/IP-SD.
服务端给向自己订阅的client端 发布 事件， 这些事件可能是周期 或者变化事件。
订阅的逻辑是在SOME/IP-SD协议中实现

[PRS_SOMEIP_00925]
Upstream requirements: RS_SOMEIP_00004
For the SOME/IP notification message the server has to do the following for payload
and header:
• Construct the payload
• Set the Message ID based on the event the server wants to send
• Set the Length field to 8 bytes (for the part of the SOME/IP header after the length
field) + length of the serialized payload
• Set the Client ID to 0x00. Set the Session ID according to
[PRS_SOMEIP_00932], [PRS_SOMEIP_00933], and [PRS_SOMEIP_00521].
In case of active Session Handling the Session ID shall be incremented upon
each transmission.
clientID  --- 设置为0
SessionID -- 按照之前的规范 要递增

• Set the Protocol Version according [PRS_SOMEIP_00052]
• Set the Interface Version according to the interface definition
• Set the Message Type to NOTIFICATION (i.e. 0x02)
• Set the Return Code to 0x00

[PRS_SOMEIP_00926]
Upstream requirements: RS_SOMEIP_00004
The payload of the notification message shall consist of the serialized data of the
event.
payload 要按照要求 序列化数据

[PRS_SOMEIP_00930]
Upstream requirements: RS_SOMEIP_00042
When more than one subscribed client on the same ECU exists, the system shall handle the replication of notifications in order to save transmissions on the communication
medium.

This is especially important, when notifications are transported using multicast messages

这段内容（[PRS_SOMEIP_00930]）描述了在 **SOME/IP** 中，当同一 ECU（电子控制单元）上有多个订阅客户端时，系统应如何处理通知消息的复制，以减少通信介质上的传输负载。以下是详细解释：

---

### 核心要求
1. **多客户端订阅**：
   - 当同一 ECU 上有多个客户端订阅了相同的服务或事件时，系统需要高效地处理通知消息的复制和分发。

2. **减少传输负载**：
   - 系统应优化通知消息的传输，避免在通信介质上重复发送相同的通知消息。
   - 特别是在使用 **组播（multicast）** 传输通知消息时，这种优化尤为重要。

---

### 关键点
1. **通知消息的复制**：
   - 当多个客户端订阅了相同的服务或事件时，服务端可能会生成相同的通知消息。
   - 系统需要在 ECU 内部复制这些通知消息，而不是通过通信介质多次发送。

2. **组播传输的优化**：
   - 组播是一种高效的通信方式，允许将单个消息发送给多个接收方。
   - 如果通知消息通过组播传输，系统应确保同一 ECU 上的多个客户端共享同一组播消息，而不是为每个客户端单独发送。

3. **通信介质的负载**：
   - 减少重复传输可以显著降低通信介质的负载，提高网络效率。
   - 这对于资源受限的嵌入式系统（如汽车电子系统）尤为重要。

---

### 实现建议
1. **ECU 内部消息复制**：
   - 在 ECU 内部实现消息复制机制，确保多个客户端可以共享同一通知消息。
   - 例如，使用共享内存或消息队列来分发通知消息。

2. **组播消息的共享**：
   - 如果通知消息通过组播传输，ECU 应确保所有订阅客户端都能接收到同一组播消息。
   - 避免为每个客户端单独发送组播消息。

3. **订阅管理**：
   - 实现高效的订阅管理机制，跟踪哪些客户端订阅了哪些服务或事件。
   - 在通知消息生成时，根据订阅列表进行消息分发。

4. **性能优化**：
   - 在 ECU 内部优化消息复制和分发的性能，确保实时性和低延迟。
   - 避免因消息复制导致的性能瓶颈。

---

### 示例场景
假设一个 ECU 上有三个客户端（Client A、Client B 和 Client C）订阅了同一个服务的事件通知。

#### 传统方式（未优化）：
- 服务端为每个客户端单独发送通知消息，导致通信介质上传输三次相同的消息。

#### 优化方式：
1. 服务端通过组播发送一次通知消息。
2. ECU 接收到组播消息后，在内部复制并分发给 Client A、Client B 和 Client C。
3. 通信介质上只传输一次通知消息，减少了传输负载。

---

### 总结
[PRS_SOMEIP_00930] 强调了在 SOME/IP 中，当同一 ECU 上有多个订阅客户端时，系统应优化通知消息的复制和分发，以减少通信介质上的传输负载。特别是在使用组播传输通知消息时，这种优化可以显著提高网络效率和系统性能。实现时需要注意 ECU 内部的消息复制机制、组播消息的共享以及订阅管理的高效性。

4.2.4.1 Strategy for sending notifications

For different use cases different strategies for sending notifications are possible. The
following examples are common:
• Cyclic update — send an updated value in a fixed interval (e.g. every 100 ms for
safety relevant messages with Alive)
• Update on change — send an update as soon as a "value" changes (e.g. door
open)
• Epsilon change — only send an update when the difference to the last value is
greater than a certain epsilon. This concept may be adaptive, i.e. the prediction is
based on a history; thus, only when the difference between prediction and current
value is greater than epsilon an update is transmitted.
notifications 通知的 三种发送策略
1. 周期
2. 变化
3. 门限 -- 接触几家车企的规范 没看到使用这个

4.2.5 Fields

A field represents a status and has a valid value. The consumers subscribing for the
field instantly after subscription get the field value as an initial event.
一个Field 代表一种状态 并带有个有效值
client第一次订阅后 能立刻收到event的值

[PRS_SOMEIP_00179]
Upstream requirements: RS_SOMEIP_00009
A field shall be a combination of getter, setter and notification event.
Field是 getter / setter / notify的集合体

[PRS_SOMEIP_00180]
Upstream requirements: RS_SOMEIP_00009
A field without a setter and without a getter and without a notifier shall not exist. The
field shall contain at least a getter, a setter, or a notifier.
field 至少含有 getter/ setter/ notify 一种

[PRS_SOMEIP_00181]
Upstream requirements: RS_SOMEIP_00009
The getter of a field shall be a request/response call that has an empty payload in the
request message and the value of the field in the payload of the response message.
getter的 请求报文 不能带参数 ，只能响应包中携带返回值

[PRS_SOMEIP_00182]
Upstream requirements: RS_SOMEIP_00009
The setter of a field shall be a request/response call that has the desired value of the
field in the payload of the request message and the value that was set to the field in
the payload of the response message.
Note:
If the value of the request payload was adapted (e.g. because it was out of limits) the
adapted value will be transported in the response payload.
setter有请求 有响应。
请求 是想要设置的值。
返回 是设置后的实际值（如果请求的值超范围 server端会把调整后的值返回回去）

[PRS_SOMEIP_00909]
Upstream requirements: RS_SOMEIP_00002, RS_SOMEIP_00009
The notifier shall send an event message that transports the value of the field to the
client when the client subscribes to the field.
谁订阅field给谁发送 事件

[PRS_SOMEIP_00183]
Upstream requirements: RS_SOMEIP_00005, RS_SOMEIP_00009
The notifier shall send an event message that transports the value of a field and shall
follow the rules for events. Sending strategies include on change, on epsilon change,
and cyclic sending.
field的notify 发送事件 也是支持这三种模式：
周期 、变化、门限