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知道