深入浅出：SOME/IP-SD的工作原理与应用

往期推荐

ETAS工具链自动化实战指南＜一＞
ETAS工具链自动化实战指南＜二＞
ETAS工具链自动化实战指南＜三＞
AUTOSAR工程师必读：Artop的核心功能
Vector工具链自动化实战指南＜一＞
isolar高手秘籍| ECU Configuration三分钟速成！
掌握核心步骤：RTA-BSW以太网配置全解析
一文详解TC399 CAN MCAL 配置
LSL常见应用场景及示例＜一＞
LSL常见应用场景及示例＜二＞
LSL常见应用场景及示例＜三＞
为什么Autosar钟情arxml而非json？大揭秘！

从 AUTOSAR 的整体视角来看，SOME/IP 和 SD 是两个不同的组件。然而，它们在许多其他组件（如 RTE、LdCom、SoAd、BswM、PduR 等）之间相互协作，我们需要在配置中关注它们之间的关系。

通常，SOME/IP-SD 依赖于 SOME/IP。SOME/IP 本身支持 TCP 和 UDP 通信，但 SOME/IP-SD 仅限于通过 UDP 使用 SOME/IP。

SOME/IP 协议概述

协议介绍

SOME/IP 是一种汽车中间件解决方案，可用于控制消息。它从一开始就设计成能够完美适应不同大小和不同操作系统的设备。

SOME/IP 提供网络上的面向服务的通信。在面向服务的数据传输中，发送方仅在网络中的至少一个接收方需要这些数据时才发送数据。这种方法的优点是网络和所有连接的节点不会被不必要的数据所负载。

SOME/IP 基于列出服务功能的服务定义。

SOME/IP 支持广泛的中间件功能：

序列化
远程过程调用（RPC）
服务发现（SD）
发布/订阅（Pub/Sub）

SOME/IP TP 模块概述和 BSW 模块依赖性

SOME/IP TP 模块的任务是对不适合放入一个 UDP 数据包中的 SOME/IP 数据包进行分段。在接收端，它将接收到的 SOME/IP 分段重新组装起来。

SOME/IP TP 模块与 PDU-R 在传输和接收路径上都进行交互。

上图显示了 SOME/IP 组件的通信组件。从 SWCs 的角度来看，我们可以通过以太网网络发送/接收通信信号。这些信号将被封装在 I-PDU 和额外的 SOME/IP 头部（N-PDU）中。

在发送信号时，我们将使用 RTE 的接口访问 LdCOM 来分配 I-PDU 到发送的数据。该 I-PDU 将被路由到 PDU-R，PDU-R 将其路由到 SOME/IP 以封装其头部到 I-PDU，然后返回 N-PDU，该 N-PDU 将从 PDU-R 路由到 SoAd 和以太网网络。接收路径则相反。

原始 SOME/IP 消息的Header格式

Header的结构如下图所示。

1.Message ID （4 字节）：消息 ID 是一个 32 位标识符，用于识别对应用程序方法的 RPC 调用或事件。消息 ID 应在整个系统（即车辆）中唯一。

- Service ID：每个服务的唯一标识符。
- Method ID：方法的范围是 0-32767，事件的范围是 32768-65535。

2.Length （4 字节）：负载的长度以字节为单位，从请求 ID/客户端 ID 开始，到 SOME/IP 消息的末尾（包括下一个 ID，即 8 个额外字节）。

3.RequestID （4 字节）：请求 ID 使提供者和订阅者能够区分对同一方法、事件、getter 或 setter 的多个并行使用。请求 ID 应仅在提供者和订阅者组合（即一个订阅）中唯一。在 AUTOSAR 中，请求 ID 由客户端 ID 和会话 ID 组成，如下所示：

- Client ID：是 ECU 内部调用客户端的唯一标识符。客户端 ID 允许 ECU 区分来自多个客户端的对同一方法的调用。
- Session ID：是订阅者为每个调用选择的唯一标识符。会话 ID 允许订阅者区分对同一方法的多个调用。请求/响应方法应使用会话处理和会话 ID。会话 ID 应在每次调用后递增。当会话 ID 达到 0xFFFF 时，应回绕并重新开始。如果响应的会话 ID 不等于请求的会话 ID，订阅者必须忽略该响应。

4.Protocol Version（1 字节）：协议版本应为一个 8 位字段，包含 SOME/IP 协议版本。

5.Interface Version（1 字节）：接口版本应为一个 8 位字段，包含服务接口的主要版本号。

6.Message Type（1 字节）：消息类型字段用于区分不同类型的消息，应包含以下值：

- 正常请求（消息类型 0x00）应由响应（消息类型 0x80）回答，如果没有发生错误。如果发生错误，则发送错误消息（消息类型 0x81）。
- 还可以发送没有响应消息的请求（消息类型 0x01）。用于通过通知更新值的回调接口存在（消息类型 0x02）。
- 消息类型的第 3 高位（0x20）称为 TP-标志，应设置为 1，以表明当前的 SOME/IP 消息是一个段。消息类型为请求（0x00）的段具有消息类型（0x20），消息类型为响应（0x80）的段具有消息类型（0xa0），依此类推。

7.Return Code（RetCode - 1 字节）：返回码用于指示请求是否成功处理。为了简化头部布局，每个消息都会传输返回码字段。

PRS_SOMEIP_00191 如下所示：

SOME/IP-SD 模块概述

模块介绍

AUTOSAR 服务发现（SD）模块提供了在车载网络中检测和提供可用服务（即功能实体）的功能。为此，它利用了 IP 多播和所谓的 SOME/IP-SD 消息。

SD 模块的主要任务是管理车载通信中称为服务的功能实体的可用性，以及控制事件消息的发送行为。这允许仅将事件消息发送给需要它们的接收者（发布/订阅）。这里描述的解决方案也被称为 SOME/IP-SD。

AUTOSAR_TR_SomeIpExample_4.2.1

本地 ECU 需要处理两种不同类型的服务：

Server Services：本地 ECU 向车辆其他部分提供服务器服务实例（即本地实例），可以被视为该服务实例的服务器。
Client Services：本地 ECU 可以使用另一 ECU 提供的服务器服务实例，可以被视为该服务实例的客户端。

对于Server Services，本地 ECU 的 SD 模块需要（server 角色）：

- 在服务可用时提供本地服务；即提供服务的 SWC 已准备就绪，并且服务在当前 ECU 状态下可用。
- 当服务不再可用时，撤回本地服务的提供（停止提供）。
- 回应并响应其他 ECU 的发现请求。

对于Client Services，本地 ECU 的 SD 模块需要（Client 角色）：

- 根据配置监听服务提供和发现，然后将这些信息存储在易失性内存中。
- 根据配置监听停止提供消息，并将这些信息存储在易失性内存中。
- 根据当前 ECU 及其 SWC 的状态发送发现请求。

BSW modules依赖

SOME/IP-SD 使用服务，这些服务由 BswM 管理。当我们启动系统时，我们应该从 BswM 激活配置好的 SD 服务，之后通信将由 SD 组件及其邻接组件 Pdu-R、SoAd、BswM 和以太网网络处理。

如下图所示，展示了在 AUTOSAR 架构中 SOME/IP-SD 模块与其他 BSW 模块的交互关系。

对于控制路径，SOME/IP-SD 包括 SOME/IP 头部，但不包含 Message-ID 和 Length 字段本身。

客户端-服务器通信示例

下图展示了使用 SOME/IP-SD 协议的客户端与服务器实体之间的消息交换示例。

具体步骤如下：

客户端发送 FindService 消息：客户端在多播中请求一个服务实例。
服务器接收 FindService 消息：服务器收到多播的 FindService 消息，并回复一个对应的 OfferService 消息，以告知服务实例的地址和端口，供客户端进行单播通信。
客户端收到 OfferService 消息后：根据 Sd 配置中指定的路由组，启用到 OfferService 消息中指定的单播地址的开放套接字连接：
1. SdClientServiceActivationRef：用于执行远程过程调用（ConsumedMethod）。
2. SdConsumedEventGroupUdpActivationRef：用于接收服务器事件（ConsumedEventGroup）。
客户端在服务器的 ProvidedMethod 上执行远程过程调用：使用单播，通过在第 3 步中打开的套接字连接进行。RPC 调用可以是“fire & forget"，也可以返回值。
客户端请求订阅特定的 Eventgroup：通过 SubscribeEventgroup 消息进行订阅。
服务器确认订阅：服务器通过 SubscribeEventgroup 消息确认订阅。
服务器向订阅的客户端发送事件：事件可以是单播或多播，具体取决于配置。

Message 结构

SOME/IP-SD 头部格式应遵循以下规范：

Message ID (Service ID/Method ID) [32 位]：0xFFFF 8100
- Service ID [16 位]：服务发现消息中的服务 ID 始终设置为 0xFFFF。
- EventID/MethodID [16 位]：服务发现消息中的事件 ID/方法 ID 始终设置为 0x8100。
Request ID [32 位]：
- Client ID [32 位]：静态设置为 0x0000。
- 第一个发送到多播地址的 SD 消息的会话 ID 为 0x0001，而发送给任何单播通信伙伴的第一个 SD 消息的会话 ID 也为 0x0001。
Protocol Version [8 位]：字段值静态设置为 0x01。
Interface Version [8 位]：字段值静态设置为 0x01。
Message Type [8 位]：字段值静态设置为 0x02。
Return Code：字段值静态设置为 0x00。
Flags [8 位]：SOME/IP-SD 头部以此字段开始。它用于传递全局服务发现信息，包括当前的最后重启状态以及接收单播消息的能力。Reboot Flag在重启后的所有消息中设置为 ‘1’，直到请求 ID 字段的会话 ID 包装并重新开始为 0x0001 为止。之后，Reboot Flag应设置为 ‘0’。
- bit 0: Reboot Flag
- bit 1: Unicast Flag
- bit 2: Explicit Initial Data Control Flag
- bit 3-7: 保留
Length of Entries Array [32 位]：条目数组的第一个字段应包含条目数组的字节数（不包括此 32 位字段）。
Entries Array Type 1
- 服务

- Type 1 Entry format layout 的 Type 字段应携带以下值之一：
  - 0x00：表示 FindService。
  - 0x01：表示 OfferService 和 StopOfferService。
- “Index First Option Run” 字段应携带此条目在选项数组中第一次选项运行的第一个选项的索引。
- “Index Second Option Run” 字段应携带此条目在选项数组中第二次选项运行的第一个选项的索引。
- “Number of Option 1” 字段应携带第一次选项运行所使用的选项数量。
- “Number of Option 2” 字段应携带第二次选项运行所使用的选项数量。
- “Service ID” 字段应携带服务的服务 ID（用于 Find、Offer 或 Stop Offering）。
- “Instance ID” 字段应携带服务的实例 ID（用于 Find、Offer 或 Stop Offering）。如果不是单个实例而是所有实例都被寻址，则 “Instance ID” 字段应设置为 **0xFFFF**。
- “Major Version” 字段应携带服务的主要版本。
- “TTL” 字段定义了条目的有效时间（以秒为单位），对于 Stop-Entries，TTL 为 0。
- “Minor Version” 字段应携带服务的次要版本。

Entries Array Type 2
- 事件组

- Type 2 Entry format layout的 Type 字段应根据发送消息的目的携带以下值之一：
  - 0x06：表示 SubscribeEventgroup 和 StopSubscribeEventgroup。
  - 0x07：表示 SubscribeEventgroupAck 和 SubscribeEventgroupNack。
- “Index Second Option Run” 字段应携带此条目在选项数组中第二次选项运行的第一个选项的索引。
- “Number of Option 1” 字段应携带第一次选项运行所使用的选项数量。
- “Number of Option 2” 字段应携带第二次选项运行所使用的选项数量。
- “Service ID” 字段应携带事件组服务的服务 ID。
- “Instance ID” 字段应携带事件组服务的实例 ID。
- “Major Version” 字段应携带 Sd 服务器服务的主要版本。
- “TTL” 字段定义了条目的有效时间（以秒为单位），Stop-Entries 或 Nack-Entries 使用 TTL 为 0。
- Reserved 字段应静态设置为 0x000。
- Counter 字段用于区分相同的 Type 2 条目（例如，对同一事件组的多个订阅）。