SOME/IP--協議英文原文講解10

前言
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 發送事件也是支持這三種模式：
周期、變化、門限