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

前言
SOME/IP協議越來越多的用于汽車電子行業中，關于協議詳細完全的中文資料卻沒有，所以我將結合工作經驗并對照英文原版協議做一系列的文章。基本分三大塊：

1. SOME/IP協議講解

2. SOME/IP-SD協議講解

3. python/C++舉例調試講解

5.1.5 Non-SOME/IP protocols with SOME/IP-SD

用SOME/IP協議實現非SOME/IP的服務。（實際基本未見使用）
Besides SOME/IP other communication protocols are used within the vehicle; e.g., for
Network Management, Diagnostics, or Flash Updates. Such communication protocols
might need to communicate a service instance or have eventgroups as well.
[PRS_SOMEIPSD_00437]
Upstream requirements: RS_SOMEIPSD_00004
For Non-SOME/IP protocols (the application protocol itself doesn’t use SOME/IP but
it is published over SOME/IP SD) a special Service-ID shall be used and further information shall be added using the configuration option:
? Service-ID shall be set to 0xFFFE (reserved)
? Instance-ID shall be used as described for SOME/IP services and eventgroups.
? The Configuration Option shall be added and shall contain exactly one entry with
key "otherserv" and a configurable non-empty value that is determined by the
system department.

[PRS_SOMEIPSD_00438]
Upstream requirements: RS_SOMEIPSD_00004
SOME/IP services shall not use the otherserv-string in the Configuration Option.
[PRS_SOMEIPSD_00439]
Upstream requirements: RS_SOMEIPSD_00004
For Find Service/Offer Service/Request Service entries the otherserv-String shall be
used when announcing non-SOME/IP service instances.
[PRS_SOMEIPSD_00440]
Upstream requirements: RS_SOMEIPSD_00004

Example for valid otherserv-string: "otherserv=internaldiag".
Example for an invalid otherserv-string: "otherserv".
Example for an invalid otherserv-string: "otherserv=".

### **非SOME/IP協議與SOME/IP-SD的集成規范解析**

針對車載網絡中非SOME/IP協議（如診斷、網絡管理、刷寫）通過SOME/IP-SD發布的規則，以下是技術要點與實現指南：

---

#### **1. 非SOME/IP服務的標識規則 ([PRS_SOMEIPSD_00437])**
| **字段** ? ? ? ? | **取值要求** ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
|------------------|-----------------------------------------------------------------------------|
| **Service-ID** ? | 固定 `0xFFFE`（保留值，專用于非SOME/IP協議） ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
| **Instance-ID** ?| 按SOME/IP標準規則分配（與服務實例一一對應） ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
| **配置選項** ? ? | 必須包含一個鍵為 `"otherserv"` 的條目，值為非空字符串（由系統部門定義） ? ? ?|

**示例配置選項**： ?
```xml
<ConfigurationOption>
? ? <Item key="otherserv" value="internaldiag"/> ?
</ConfigurationOption>
```

**非法示例**： ?
- `"otherserv"`（缺少值） ?
- `"otherserv="`（值為空） ?

---

#### **2. 協議隔離性要求 ([PRS_SOMEIPSD_00438])** ?
- **禁止混用**：標準SOME/IP服務**不得**使用 `otherserv` 配置選項，避免與非SOME/IP服務混淆。 ?
- **設計意圖**：明確區分SOME/IP原生服務與代理發布的非SOME/IP服務。

---

#### **3. 服務發現條目中的使用 ([PRS_SOMEIPSD_00439])** ?
- **適用場景**： ?
? - `Find Service` / `Offer Service` / `Request Service` 條目中必須攜帶 `otherserv` 字符串。 ?
- **作用**： ?
? - 允許客戶端識別非SOME/IP服務類型（如診斷服務 `"internaldiag"`）。 ?

**報文示例**： ?
```cpp
// Offer Service條目結構示例
OfferServiceEntry {
? ? Service-ID: 0xFFFE,
? ? Instance-ID: 0x0001,
? ? Options: [
? ? ? ? ConfigurationOption {
? ? ? ? ? ? Items: ["otherserv=flashupdate"] ?// 標識為刷寫服務
? ? ? ? }
? ? ]
}
```

---

#### **4. 實現邏輯與校驗** ?
##### **4.1 服務發布方（Server）** ?
```python
def publish_non_someip_service(service_type, instance_id):
? ? entry = OfferServiceEntry(
? ? ? ? service_id=0xFFFE,
? ? ? ? instance_id=instance_id,
? ? ? ? options=[
? ? ? ? ? ? ConfigurationOption(items={"otherserv": service_type}) ?# 必須非空
? ? ? ? ]
? ? )
? ? if not validate_otherserv_string(service_type):
? ? ? ? raise InvalidConfigError("otherserv格式錯誤")
? ? send_sd_message(entry)
```

##### **4.2 服務發現方（Client）** ?
```python
def handle_offer_entry(entry):
? ? if entry.service_id == 0xFFFE: ?# 非SOME/IP服務
? ? ? ? otherserv = entry.options.get("otherserv")
? ? ? ? if not otherserv:
? ? ? ? ? ? log_error("缺失otherserv配置選項")
? ? ? ? ? ? return
? ? ? ? route_to_protocol_handler(otherserv) ?# 根據類型路由到診斷/刷寫等模塊
```

---

#### **5. 典型應用場景** ?
| **服務類型** ? ? ? | **otherserv值示例** ? ?| **用途** ? ? ? ? ? ? ? ? ? ? |
|--------------------|-----------------------|-----------------------------|
| 車載診斷 ? ? ? ? ? | `"internaldiag"` ? ? ?| UDS/OBD診斷服務代理 ? ? ? ? ?|
| 網絡管理 ? ? ? ? ? | `"nmalive"` ? ? ? ? ? | AUTOSAR NM報文發布 ? ? ? ? ? |
| ECU刷寫 ? ? ? ? ? ?| `"flashupdate"` ? ? ? | 通過DoIP或XCP協議更新固件 ? ?|
| 傳感器原始數據 ? ? ?| `"rawsensordata"` ? ? | 非SOME/IP格式的傳感器流 ? ? ?|

---

#### **6. 錯誤處理與邊界條件** ?
- **無效Service-ID**：若非SOME/IP服務未使用 `0xFFFE`，接收方應忽略該條目。 ?
- **缺失otherserv**：丟棄條目并記錄錯誤日志（違反[PRS_SOMEIPSD_00437]）。 ?
- **值沖突**：同一Instance-ID對應多個 `otherserv` 值時，以最新接收的為準。 ?

---

### **設計驗證要點** ?
1. **靜態檢查**： ?
? ?- 代碼審查確保 `0xFFFE` 僅用于非SOME/IP服務。 ?
2. **動態測試**： ?
? ?- 注入非法 `otherserv` 字符串（如空值），驗證系統是否拒絕處理。 ?
3. **交互測試**： ?
? ?- 混合SOME/IP與非SOME/IP服務，確認客戶端能正確路由。 ?

此規范通過標準化標識和配置選項，實現了SOME/IP-SD對異構協議的統一管理，擴展了車載網絡的兼容性。

5.1.6 Publish/Subscribe with SOME/IP and SOME/IP-SD
Note: In contrast to the SOME/IP request/response mechanism there may be cases in
which a client requires a set of parameters from a server, but does not want to request
that information each time it is required. These are called notifications and concern
events and fields.
[PRS_SOMEIPSD_00443]
Upstream requirements: RS_SOMEIPSD_00013, RS_SOMEIPSD_00014, RS_SOMEIPSD_-
00015, RS_SOMEIPSD_00016
All clients needing events and/or notification events shall register using the SOME/IPSD at run-time with a server.

客戶端需要服務端的信息不是每次需要時請求，要先訂閱

?MOST（Media Oriented Systems Transport）?是一種專為汽車多媒體和娛樂系統設計的高速多媒體網絡通信協議，主要用于傳輸音頻、視頻、語音和數據等實時媒體流。

[PRS_SOMEIPSD_00446]
Upstream requirements: RS_SOMEIPSD_00013, RS_SOMEIPSD_00014, RS_SOMEIPSD_-
00015, RS_SOMEIPSD_00016
With the SOME/IP-SD entry Offer Service the server offers to push notifications to
clients; thus, it shall be used as trigger for Subscriptions.
[PRS_SOMEIPSD_00449]
Upstream requirements: RS_SOMEIPSD_00015
Each client shall respond to a SOME/IP-SD Offer Service entry from the server with
a SOME/IP-SD Subscribe Eventgroup entry as long as the client is still interested in
receiving the notifications/events of this eventgroup. If the client is able to reliably detect
the reboot of the server using the SOME/IP-SD messages reboot flag, the client shall
handle the reboot as if a StopOffer entry was received and proceed with the received
entries after all actions upon a StopOffer have been finalized.
[PRS_SOMEIPSD_00862] Client based distinction between field notifiers and
pure events
Upstream requirements: RS_SOMEIPSD_00015
The distinction between field notifiers and pure events shall be taken based on the
configuration of the client.
Reasons for the client to explicitly request initial values for field notifiers (see
[PRS_SOMEIPSD_00463]) include but are not limited to:
? The client is currently not subscribed to the Eventgroup.
? The client has seen a link-down/link-up after the last Subscribe Eventgroup entry.
? The client has not received a Subscribe Eventgroup Ack after the last regular
Subscribe Eventgroup
? The client has detected a Reboot of the Server of this Services
[PRS_SOMEIPSD_00570]
Upstream requirements: RS_SOMEIPSD_00015
If the client subscribes to two or more eventgroups including one or more identical
events or field notifiers, the server shall not send duplicated events or field notifiers.
This applies to the sending of regular events and regular field notifiers. This does not
apply to the sending of initial values for field notifiers (see [PRS_SOMEIPSD_00571]).
[PRS_SOMEIPSD_00450]
Upstream requirements: RS_SOMEIPSD_00015
Publish/Subscribe with link loss at client side is described as follows:
1. No prior registrations + Client subscribes
(a) Server: OfferService()
(b) Client: SubscribeEventgroup[Session ID=x, Reboot=0]
(c) Server: updateRegistration()
(d) Server: SubscribeEventgroupAck + Events()
2. Link loss at client side
(a) Client: linkDown()
(b) Client: deleteEntries()
(c) Client: linkUp()
3. Client subscribes again, Client Reboot detected
(a) Server: OfferService()
(b) Client: SubscribeEventgroup[Session ID=1, Reboot=1]
(c) Server: updateRegistration()
(d) Server SubscribeEventgroupAck + Events()

client 收到 server的offer 如果里面的entries有自己需要那就必須發送訂閱包。
server 周期發布offer是為了看自己需不需要發送事件包（如果沒人訂閱就不需要發送了）

client 離線后重新上線，Reboot標志要設置為1
server收到client reboot標志后需要更新自己的訂閱列表

[PRS_SOMEIPSD_00452]
Upstream requirements: RS_SOMEIPSD_00017, RS_SOMEIPSD_00020
A client shall deregister from a server by sending a SOME/IP-SD Subscribe Eventgroup message with TTL=0 (Stop Subscribe Eventgroup see
[PRS_SOMEIPSD_00389]).
[PRS_SOMEIPSD_00453]
Upstream requirements: RS_SOMEIPSD_00015, RS_SOMEIPSD_00017

Publish/Subscribe Registration/Deregistration behavior is described as follows:
1. Client 1 subscribes
(a) Server: OfferService() to Client 1 and Client 2
(b) Client 1: SubscribeEventgroup()
(c) Server: updateRegistration()
(d) Server: SubscribeEventgroupAck + Events() to Client 1
2. Client 2 subscribes
(a) Client 2: SubscribeEventgroup()
(b) Server: updateRegistration()
(c) Server: SubscribeEventgroupAck + Events() to Client 2
3. Client 2 stops subscription
(a) Client 2: StopSubscribeEventgroup()
(b) Server: updateRegistration()
4. Client 1 remains registered

Note: Description is also shown in Figure 5.22.

client 發送停止訂閱（TTL=0）就可以讓server去訂閱，server要從自己的訂閱列表中刪除此client，此后的event不能再發送給client

多個client之間的訂閱是獨立的

[PRS_SOMEIPSD_00457]
Upstream requirements: RS_SOMEIPSD_00013, RS_SOMEIPSD_00015

Publish/Subscribe with link loss at server is described as follows:
1. No prior registrations + Client subscribes
(a) Server: OfferService()
(b) Client: SubscribeEventgroup()
(c) Server: updateRegistration()
(d) Server: SubscribeEventgroupAck + Events()
2. Link loss at server side
(a) Server: linkDown()
(b) Server: deleteRegistrations()
(c) Server: linkUp()
3. Server offers again, Server Reboot detected by client
(a) Server: OfferService()[Session ID=1, Reboot=1]
(b) Client: SubscribeEventgroup()
(c) Server: updateRegistration()
(d) Server SubscribeEventgroupAck + Events()

如果 server 下線后重新上線，要發送reboot 標志位為1 ，讓client知道