SOME/IP--协议英文原文讲解2

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

1. SOME/IP协议讲解

2. SOME/IP-SD协议讲解

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

4.1 Specification of SOME/IP Message Format (Serialization)

SOME/IP消息格式规范--序列化

Serialization describes the way data is represented in protocol data units (PDUs) as payload of either UDP or TCP messages, transported over an IP-based automotive in-vehicle network.

序列化描述了基于UDP/TCP传输层的 的发送、接收的数据包的数据组织方式。简单的理解：我们用UDP/TCP发送、接收我们的自定义数据。不过现在是把这个自定义数据 替换成SOME/IP定义好的格式。用SOME/IP定义数据的方式 组织 数据的过程 就称为序列化。

4.1.1 Limitation

Reordering of out-of-order segments of a SOME/IP message is not supported. 

SOME/IP由于网络差或干扰数据乱序，这种乱序SOME/IP协议本身是不支持恢复的

也就是说SOME/IP协议本身不负责 传输数据的 稳定完整性。

简单理解：需要数据传输可靠则选择TCP传输协议，否则可选择UDP协议（具体怎么选择，后面章节有专门讲解）

4.1.2 Header -- 消息头的数据格式 -- 后面有详解
[PRS_SOMEIP_00030]
Upstream requirements: RS_SOMEIP_00027
[The structure of header layout shall consist of -- 消息头结构的布局（内存布局）组成
• Message ID (Service ID/Method ID) [32 Bits]
• Length [32 Bits]
• Request ID (Client ID/Session ID) [32 Bits]
• Protocol Version [8Bits]
• Interface Version [8 Bits]
• Message Type [8 Bits]
• Return Code [8 Bits]
]

[PRS_SOMEIP_00941]
Upstream requirements: RS_SOMEIP_00027
In case of E2E communication protection being applied, the E2E header is placed
after Return Code, depending on the chosen Offset value for the E2E header. The
default Offset value is 64 bit, which puts the E2E header exactly between Return Code
and Payload

E2E保护 是一种数据校验，E2E的header的大小 和 配置有关，具体参见AUTOSAR_FO_PRS_E2EProtocol.pdf 此专题不做讨论。

[PRS_SOMEIP_00031]
Upstream requirements: RS_SOMEIP_00027
For interoperability reasons the header layout shall be identical for all implementations
of SOME/IP. The fields are presented in transmission order i.e. the fields on the top left
are transmitted first

头部布局的互操作性要求

• 互操作性原因：

  • 为了实现互操作性，SOME/IP 的头部布局在所有实现中必须保持一致。

• 字段传输顺序：

  • 字段按照 传输顺序 描述：
    • 位于左上角的字段 最先被传输。（网络字节序）
    • 依次向右下角的字段传输。

这确保了不同系统之间在使用 SOME/IP 协议时，能够正确解析和处理数据包头部。

4.1.2.1 Message ID [32 Bit]
[PRS_SOMEIP_00034]
Upstream requirements: RS_SOMEIP_00021, RS_SOMEIP_00022, RS_SOMEIP_00023, RS_-
SOMEIP_00027
The Message ID shall be a 32 Bit identifier that is used to identify
• the RPC call to a method of an application
• or to identify an event.
Note: The assignment of the Message ID is up to the user / system designer. However,
the Message ID is assumed be unique for the whole system (i.e. the vehicle).

消息 ID 的定义和用途

• 消息 ID（Message ID） 是一个 32 位标识符，用于以下目的：
  1. 标识应用程序中 方法的 RPC 调用。
  2. 标识一个 事件。

注意事项

• 消息 ID 的分配由用户或系统设计者决定。
• 系统范围内唯一性：
  • 消息 ID 应在整个系统中（如车辆范围内）保持唯一。

 4.1.2.2 Method ID [16 Bit]
[PRS_SOMEIP_00245]
Upstream requirements: RS_SOMEIP_00016, RS_SOMEIP_00027
The Message ID header field shall be structured into a 16 Bit Service ID header field
(to distinguish up to 2^16 services) and a 16 bit Method ID header field to distinguish
up to 2^16 service elements (namely methods and/or events). This structuring of the
Message ID header field is illustrated as shown in [PRS_SOMEIP_00755].
Note: It is common practise and recommended to split the ID space of the Method ID
between Methods and Events/Notifications. Methods would be in the range 0x0000-
0x7FFF (first bit of Method-ID is 0) and Events/Notifications would use the range
0x8000-0x8FFF (first bit of the Method-ID is 1).

Message ID 的结构

• Message ID 的头部字段由以下两个部分组成：

  1. 16 位服务 ID（Service ID）：
     • 用于区分多达 2162^{16}216 个服务。
  2. 16 位方法 ID（Method ID）：
     • 用于区分多达 2162^{16}216 个服务元素（包括方法和/或事件）。

• Message ID 的结构示例可以参考 [PRS_SOMEIP_00755]。

推荐的 Method ID 分配规则

• 分配方法：（这个是建议的通用做法，如果有人自己定制规则区分方法和事件也是可以的）
  • 方法（Methods）：使用范围 0x0000 - 0x7FFF（即 Method ID 的第一位为 0）。
  • 事件/通知（Events/Notifications）：使用范围 0x8000 - 0x8FFF（即 Method ID 的第一位为 1）。

备注

• 推荐做法：将 方法（Methods） 和 事件/通知（Events/Notifications） 的 ID 空间分开管理。

[PRS_SOMEIP_00755] Message ID header field

Eventgroup is a logical grouping of events and notification events of fields inside a service in order to allow subscription.

Eventgroup 是服务内部的一种逻辑分组，用于将以下内容组织在一起：

1. 事件（Events）
2. 字段的通知事件（Notification Events of Fields）

目的

• Eventgroup 的设计是为了便于 订阅（Subscription）。

事件有 事件ID ，事件组有组ID（后面会讲）

简而言之，Eventgroup 是一种机制，用来将服务内相关的事件和通知逻辑地组织起来，以便客户端可以通过订阅 Eventgroup 来获取这些事件的更新或通知。（因此订阅是以组来订阅的）

下面截图 是订阅报文解析的截图：

[PRS_SOMEIP_00365]

A SOME/IP Eventgroup shall at least contain one event.

事件组不能为空，至少要包含一个事件。

[PRS_SOMEIP_00366]

Events as well as field notifiers shall be mapped to at least one SOME/IP Eventgroup

事件必须要绑定在一个 或 多个事件组上。

4.1.2.3 Length [32 Bit] -- 长度字段
[PRS_SOMEIP_00042]
Upstream requirements: RS_SOMEIP_00027, RS_SOMEIP_00040
Length field shall contain the length in Byte starting from Request ID/Client ID until
the end of the SOME/IP message

解释了length从哪里开始计算 -- 从后一个字段（Request ID/Client ID)到整条消息的最后。

4.1.2.4 Request ID [32 Bit]
The Request ID allows a server and client to differentiate multiple parallel uses of the
same method, getter or setter.

给同一个client标记请求的顺序的。
client给server发送的requestID 是多少，server就得回复多少。
client并发发送多个同样的请求，但是携带的参数不通，则需要通过这个requestID 来区分

仅用于method/getter/setter

[PRS_SOMEIP_00043]
Upstream requirements: RS_SOMEIP_00025, RS_SOMEIP_00027
[The Request ID shall be unique for a request-response pair to differentiate between
multiple calls of the same method.]（证明了回复和请求的requestID 是相同的）

[PRS_SOMEIP_00704]
Upstream requirements: RS_SOMEIP_00027
When generating a response message, the provider shall copy the Request ID from
the request to the response message.（证明了请求和回复的requestID 相同）

服务端不需要关系RequestID的合理性 只需要拷贝回复就行，如果不合理则需要client端自己负责。
Note:
This allows the client to map a response to the issued request even with more than one
request outstanding.

规则说明

• 在生成响应消息时，提供方（Provider） 应该将请求消息中的 Request ID 复制到响应消息中。

注意事项

• 这种机制的意义在于：
  • 即使客户端同时发出了多个请求，也能通过 Request ID 将响应消息与对应的请求进行正确匹配。

总结

这种设计确保了在 并发请求 场景下，客户端能够可靠地识别和处理每个响应消息，避免数据混淆或误匹配问题。

[PRS_SOMEIP_00044]
Upstream requirements: RS_SOMEIP_00025
Request IDs must not be reused until the response has arrived or is not expected to
arrive anymore (timeout).

保证并发时的唯一性：
在未收到回复之前，或者认为回复超时之前，Request ID 不能重复。
收到回复了 可以重复 -- 由client 负责。

0voice · GitHub