SOME/IP 协议详解——信息格式

1. 头部格式

在采用端到端（E2E）通信保护时，E2E 头部放置位置的相关规定。其位置取决于所选的 E2E 头部偏移值，默认偏移值为 64 位，此时 E2E 头部会准确处于返回码和有效载荷之间（如下图所示），这样的安排旨在让 E2E 通信保护功能与 SOME/IP 协议结构兼容，保障端到端通信的可靠性和安全性，常用于汽车电子系统等场景下关键数据传输中。

出于互操作性考虑，SOME/IP 所有实现的头部布局要相同，且其字段按传输顺序呈现，左上角的字段最先传输。

1.1 消息 ID（Message ID）

• 消息 ID 是 32 位的标识符，用于识别应用程序的 RPC 调用或事件。
• 消息 ID 的分配由用户决定，但在整个系统中必须是唯一的，它类似于 CAN ID，处理过程类似。
• 方法调用的消息 ID 应按照特定结构组织，该结构包含 2¹⁶个服务和 2¹⁵个方法，如下图：
  

1.2 长度（Length）

• SOME/IP 消息中的长度字段（Length field）应包含从请求 ID / 客户端 ID 开始到 SOME/IP 消息末尾的字节长度。

1.3 请求 ID（Request ID）

• 请求 ID 的结构（Request ID [32 Bit]）

  • 在 AUTOSAR 环境中，请求 ID 由客户端 ID（Client ID）和会话 ID（Session ID）组成，各 16 位，如下图所示。
    
  • 客户端 ID 是调用客户端在内部的唯一标识符，允许 ECU 区分来自多个客户端的请求。
  • 会话 ID 是用于区分来自同一发送方的顺序消息或请求的唯一标识符。
  • 客户端 ID 还可以通过可配置的前缀或固定值在整个车辆中保持唯一，如下图所示。
    

• 请求 ID 的使用规则

  • 请求 ID 应当是提供商 - 订阅者组合唯一（即一个订阅），不能被重复使用直到响应到达或确定响应不会再到达（超时）。
  • 当生成响应消息时，提供商应当从请求复制请求 ID 到响应消息，这允许订阅者将响应映射到发出的请求。

• 会话 ID 的处理规则（根据不同场景）

  • 当会话处理不活跃时，会话 ID 应设置为 0x00。
  • 当会话处理活跃时，会话 ID 应在相应的用例中递增，并在达到 0xFFFF 时回绕到 0x01。
  • 对于请求 / 响应方法，订阅者应忽略会话 ID 不匹配的响应。
  • 对于通知消息，当会话处理不活跃时，接收者应忽略会话 ID；当会话处理活跃时，接收者应根据相应用例对待会话 ID。

1.4 协议版本（Protocol Version）：

• 协议版本的定义和位置

  • 协议版本用于识别所使用的 SOME/IP 头部格式（不包括有效载荷格式），它是一个 8 位字段，包含了 SOME/IP 协议版本信息。
  • 协议版本本身是 SOME/IP 头部的一部分，其在头部中的位置不能改变。

• 协议版本的递增规则

  • 当 SOME/IP 头部有不兼容的更改时，协议版本必须递增。如果接收方基于旧版本的协议，不会丢弃消息并错误地处理它。
  • 协议版本不应因仅影响有效载荷格式的更改而递增。

• 当前协议版本

  • 当前的协议版本应为 1。

1.5 接口版本（Interface Version）

• 版本标识功能
  • 接口版本字段是一个 8 位的标识符，其主要功能是用于标识服务接口的主版本号（Major Version of the Service Interface）。这有助于在不同的服务接口之间进行区分，尤其是在软件系统不断更新和迭代的过程中。

1.6 消息类型（Message Type）：

• 消息类型的定义和区分

  • 消息类型字段是一个 8 位的字段，用于区分不同类型的消息。其可能包含的值在上图中列出。
  • 例如，0x00 表示 REQUEST（请求一个期望有响应的操作，即使响应为空），0x01 表示 REQUEST_NO_RETURN（请求一个不期望有响应的操作），0x02 表示 NOTIFICATION（请求一个通知 / 事件回调，不期望有响应）等。

• 请求与响应的对应关系

  • 正常的请求消息（消息类型 0x00）在无错误发生时应得到一个响应消息（消息类型 0x80）。如果发生错误，则发送一个包含错误的响应消息（消息类型 0x81）。
  • 也可以发送不期望有响应的请求消息（消息类型 0x01）。对于通过通知回调机制进行的更新，存在消息类型 0x02。

• TP - Flag 的设置

  • 消息类型的第 3 高位（=0x20）应被称为 TP - Flag，并且当当前 SOME/IP 消息是一个分段消息时，应将其设置为 1。消息类型的其他位按照本节中的规定设置。
  • 例如，消息类型请求（0x00）的消息类型为（0x20），消息类型响应（0x80）的消息类型为（0x20）等。

1.7 返回码（Return Code）

• 返回码为 8 位，用于表示一个请求是否被成功处理。为了简化头部布局，每个消息都会传输返回码字段。
• 不同的消息类型有不同的允许返回码：
  

1.8 效载荷（Payload）：

• 有效载荷的作用
  • 有效载荷（Payload）字段用于携带参数。参数的序列化将在后续章节中详细说明。
• 有效载荷大小的限制
  • SOME/IP 有效载荷的大小取决于所使用的传输协议。
  • 当使用 UDP 作为传输协议时，SOME/IP 有效载荷的大小应在 0 到 1400 字节之间。这种限制是为了允许协议栈在未来进行更改（例如，切换到 IPv6 或添加安全机制）。
  • 由于 TCP 支持有效载荷的分段，因此使用 TCP 时可以自动支持更大的有效载荷。
• 有效载荷的内容
  • 有效载荷可能包含用于事件的数据元素或用于方法的参数。

2. 事件、字段和事件组

• 事件组的定义和用途
  • 事件组（Eventgroup）是对服务内的事件和字段通知事件进行逻辑分组，以便允许订阅。
• 事件和通知的传输方式
  • 事件和通知通过 RPC（远程过程调用）进行传输。事件的结构应如下：
    
• 事件 ID 的结构
  • 上图展示了事件 ID 的结构，它由服务 ID（16 位）、1 位标志和事件 ID（最后 15 位）组成。
• 事件组的使用规则
  • 不能使用空的事件组。
  • 事件和字段至少要映射到一个事件组。

3. 字节序（Endianess）

• SOME/IP 头部的字节序
  • SOME/IP 头部应按照网络字节序（大端序）进行编码。
• 有效载荷内部参数的字节序
  • 有效载荷内部参数的字节序应由配置来定义。