RS SOME/IP
1. 文档范围¶
本文档规定面向 IP 的可扩展服务导向中间件（SOME/IP）协议的需求——一种汽车/嵌入式协议及其底层序列化/线上格式，可用于请求/响应通信和基于事件的通信。
规定「又一种 RPC 机制」而非使用既有基础设施/技术的基本动机，是获得一种能够：
- 在尽可能多的用例和通信伙伴之间兼容
- 提供汽车用例所需的特性
- 从小型平台可扩展到大型平台
- 可实现于不同操作系统（即 AUTOSAR、GENIVI 和 OSEK）甚至无操作系统的嵌入式设备之上
的技术。
1.1. 文档约定¶
AUTOSAR 文档中需求的表述遵循约束 TPS_STDT_00078 规定的表格，见 Standardization Template 的「Support for Traceability」章（[1]）。
需求的表达应使用约束 TPS_STDT_00053 规定的义务表达动词形式，见 Standardization Template 的「Support for Traceability」章（[1]）。
2. 缩略语和缩写¶
以下收录与 SOME/IP 规范相关、且未被 [2, AUTOSAR glossary] 收录的缩略语和缩写。
Event
事件（Event）：仅在变化时或周期性调用的单向数据传输，从数据的生产者发送给消费者。
Eventgroup
事件组（Eventgroup）：服务内的事件以及字段的通知事件的逻辑分组，以允许订阅。
Field
字段（Field）：字段表示一种状态，因此在任意时刻都持有一个有效值，getter、setter 和 notifier 作用于其上。
Getter
读取器（Getter）：允许对字段进行读访问的请求/响应调用。
Method
方法（Method）：被调用/调用的方法、过程、函数或子例程。
Notification Event
通知事件（Notification Event）：字段的通知器（Notifier）发出的事件消息。
Notifier
通知器（Notifier）：在字段的值发生变化时，发送带有新值的事件消息。
Remote Procedure Call (RPC)
远程过程调用（RPC）：从一个 ECU 到另一个 ECU、使用消息传输的方法调用。
Service
服务（Service）：零个或多个方法、零个或多个事件以及零个或多个字段的逻辑组合。
Service Instance
服务实例（Service Instance）：服务的实现，可以在车辆中出现多次，也可以在一个 ECU 上出现多次。
Setter
写入器（Setter）：允许对字段进行写访问的请求/响应调用。
SOME/IP
面向 IP 的可扩展服务导向中间件（Scalable service-Oriented MiddlewarE over IP）。
TCP
传输控制协议（Transmission Control Protocol）。
UDP
用户数据报协议（User Datagram Protocol）。
Union
联合（Union）：动态采用不同数据类型的数据结构。
3. 需求¶
3.1. General（通用）¶
3.1.1. SOME/IP 协议应提供基于服务的通信¶
| 描述 | SOME/IP 协议应提供在运行时建立通信路径的基于服务的通信。 |
|---|---|
| 理由 | 基于服务的通信允许一种在系统设计阶段未预先定义的通信方式。 |
| 用例 | 合作伙伴之间的通信不在系统设计阶段静态定义。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.2. SOME/IP 协议应提供协议多版本支持¶
| 描述 | SOME/IP 协议应提供协议的多版本支持，以区分网络上消息的版本。 |
|---|---|
| 理由 | 需要版本号，才能区分报头或载荷结构不同的不同版本的 SOME/IP 消息。 |
| 用例 | SOME/IP 的向后不兼容扩展和修改，此时旧协议和新协议在同一网络中使用。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.3. SOME/IP 协议应提供服务接口的多版本支持¶
| 描述 | SOME/IP 协议应提供服务接口的多版本支持，以检测服务接口的不兼容变更。 |
|---|---|
| 理由 | 通信伙伴需要区分同一服务的不同版本。 |
| 用例 | 服务接口的向后不兼容变更。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.4. SOME/IP 协议应支持事件通信¶
| 描述 | SOME/IP 协议应支持事件通信，它是一种由服务提供者产生并发送的单向通信。 |
|---|---|
| 理由 | 基于事件的通信需要在网络通信中予以考虑。 |
| 用例 | 以事件为基础产生的数据的通信，例如换挡。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.5. SOME/IP 协议应支持事件通信的不同策略¶
| 描述 | SOME/IP 协议应支持事件通信的不同更新策略，以实现周期性通信或在值发生变化时通信。 |
|---|---|
| 理由 | 不同的数据需要在不同的条件下通信。 |
| 用例 | 一些基于事件的数据只在变化时通信，另一些以周期方式通信，例如为避免 ECU 在运行期间重启时出错。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.6. SOME/IP 协议应支持基于单播和多播的事件通信¶
| 描述 | SOME/IP 协议应支持基于单播和多播的事件通信，并支持基于可配置阈值在单播与多播之间自动切换。 |
|---|---|
| 理由 | 根据接收者数量，单播或多播通信更高效。单播消息是一种对某些接收者隐藏数据的机制，这些接收者无需为接收不需要的数据耗费处理资源。多播在多个接收者应接收相同数据时可以节省带宽。 |
| 用例 | 订阅者数量在运行期间急剧变化。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.7. SOME/IP 协议应支持单向 RPC 通信¶
| 描述 | SOME/IP 协议应支持单向 RPC 通信，它触发一个 RPC 的执行而不将结果告知调用方。 |
|---|---|
| 理由 | 如果调用方无需被告知 RPC 的结果，单向通信即可满足。 |
| 用例 | 执行调用方只关心触发而不关心结果的 RPC。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.8. SOME/IP 协议应支持双向 RPC 通信¶
| 描述 | SOME/IP 协议应支持双向 RPC 通信，并将结果告知调用方。 |
|---|---|
| 理由 | 如果调用方需要被告知 RPC 的结果，则必须将该结果回传给调用方。 |
| 用例 | 执行 RPC 并将结果回传给调用方。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.9. SOME/IP 协议应支持 RPC 通信的错误处理¶
| 描述 | SOME/IP 协议应支持 RPC 通信的错误处理，并将被调用方一侧的错误回传给调用方。 |
|---|---|
| 理由 | 调用方需要能够对被调用方的远程错误作出反应。 |
| 用例 | 一个 RPC 失败，且该失败在调用方的错误处理例程中被考虑。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.10. SOME/IP 协议应支持字段通信¶
| 描述 | SOME/IP 协议应支持带 getter、setter 和通知事件的字段通信。 |
|---|---|
| 理由 | 对于由中央一方持有的属性，该通信模式提供了所需的访问功能。 |
| 用例 | 车辆中的一个方持有中央属性，该属性被多个其他方设置和/或使用。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.11. SOME/IP 协议应支持下层的不同传输协议¶
| 描述 | SOME/IP 协议应支持下层的不同传输协议。SOME/IP 协议应基于 TCP/IP 和 UDP/IP 传输数据。 |
|---|---|
| 理由 | SOME/IP 不直接操作 IP，而是需要一个基于 IP、提供基本传输服务的传输协议。 |
| 用例 | 时间关键通信使用基于 UDP 的 SOME/IP，时间非关键的大数据通信使用基于 TCP 的 SOME/IP。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.12. SOME/IP 协议应支持不同长度的消息¶
| 描述 | SOME/IP 协议应支持不同长度的消息。PDU 大小应随待传输数据的大小而可变。 |
|---|---|
| 理由 | 消息长度是应用特定的。 |
| 用例 | 一些应用发送小的数据块，另一些发送大的数据块。同一应用发送的数据长度在执行期间可以变化。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.13. SOME/IP 协议应支持会话处理¶
| 描述 | SOME/IP 协议应支持会话处理，并提供区分相同参与方之间多个并行通信的机制。 |
|---|---|
| 理由 | 会话处理用于区分相同参与方之间针对同一服务的多个并行通信。 |
| 用例 | 一个客户端发出多个 RPC，它们被分别处理，且响应被正确地分配给相应的请求。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.14. SOME/IP 协议应支持接收侧协议错误的处理¶
| 描述 | SOME/IP 协议应支持接收侧协议错误的处理，并定义由接收方执行的检查。 |
|---|---|
| 理由 | 接收侧接收到的消息与期望消息之间的任何不匹配都可能导致错误行为。 |
| 用例 | 由错误配置（发送方或接收方一侧）导致的错误可以在接收侧被识别。如果数据不被应用所期望，则接收到的数据不会从通信栈传递给接收应用。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.15. SOME/IP 协议应提供大数据分段传输的支持¶
| 描述 | SOME/IP 协议应提供大数据分段传输的支持。发送方应能够将一条大消息拆分为多个较小的分段。这些分段被传输给接收方。接收方应能够重组出原始消息。 |
|---|---|
| 理由 | 时间关键数据无法通过 TCP 传输，必须使用 UDP。UDP 的最大数据包长度为 4KB。IP 分片最多只能用于 65KB。因此，没有一种既有技术提供合适的分段手段。对于这些情形，分段需要由 SOME/IP 完成，而不是由应用自身完成。 |
| 用例 | 大于 65KB 数据的时间关键传输。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2. Services（服务）¶
3.2.1. SOME/IP 协议应使用唯一标识符标识服务¶
| 描述 | SOME/IP 协议应使用车辆范围内唯一的标识符标识服务。 |
|---|---|
| 理由 | 需要在车辆范围内区分服务。 |
| 用例 | 发现一个特定的服务。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.2. SOME/IP 协议应支持一个服务的多个实例¶
| 描述 | SOME/IP 协议应为提供相同功能的服务支持多个实例。 |
|---|---|
| 理由 | 一种系统设计可能提供一个服务带多个实例，另一种系统设计可能定义多个服务、每个带一个实例。 |
| 用例 | 同一服务由车辆中的多个方提供，以实现故障转移处理，使订阅者能够在某一服务实例的提供者发生故障时切换到另一个服务实例。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.3. SOME/IP 协议应支持将多个 RPC 方法、事件和字段组合在一个服务中¶
| 描述 | SOME/IP 协议应支持将多个 RPC 方法、事件和字段组合在一个服务中。基于服务的功能（例如服务发现）应将它们作为一个整体对待，但被封装的 RPC 方法、事件和字段自身应可单独使用。 |
|---|---|
| 理由 | 如果多个功能经常一起使用，或从架构角度看存在其他分组理由，那么为每个功能提供单独的服务并不合适。 |
| 用例 | 总是一起使用的功能的组合。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.4. SOME/IP 协议应支持将事件分组到事件组¶
| 描述 | SOME/IP 协议应支持将同一提供者的事件分组到事件组，以便一步完成对特定事件组全部事件的订阅。 |
|---|---|
| 理由 | 如果事件由同一方提供，分组到事件组可以实现更高效的服务订阅。 |
| 用例 | 大量相关事件由同一方提供。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.5. SOME/IP 协议应支持将字段分组到事件组¶
| 描述 | SOME/IP 协议应支持将同一提供者的字段分组到事件组，以便一步完成对特定事件组全部字段的订阅。 |
|---|---|
| 理由 | 如果字段由同一方提供，分组到事件组可以实现更高效的服务订阅。 |
| 用例 | 大量相关字段由同一方提供。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.6. SOME/IP 协议应使用唯一标识符标识服务的 RPC 方法¶
| 描述 | SOME/IP 协议应使用对该服务唯一的标识符标识 RPC 方法、字段的 getter 和字段的 setter。 |
|---|---|
| 理由 | 一个服务内的方法、getter 和 setter 需要与同一服务内的其他方法、getter 或 setter 可区分。 |
| 用例 | 由多于一个方法、getter 或 setter 组成的服务。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.7. SOME/IP 协议应使用唯一标识符标识服务的事件¶
| 描述 | SOME/IP 协议应使用对该服务唯一的标识符标识事件和字段的通知器。 |
|---|---|
| 理由 | 一个服务内的事件需要与同一服务内的其他事件可区分。 |
| 用例 | 由多于一个事件组成的服务。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.8. SOME/IP 协议应使用唯一标识符标识服务的事件组¶
| 描述 | SOME/IP 协议应使用对该服务唯一的标识符标识服务的事件组。 |
|---|---|
| 理由 | 一个服务内的事件组需要与同一服务内的其他事件组可区分。 |
| 用例 | 由多于一个事件组组成的服务。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.9. SOME/IP 协议应定义保留标识符¶
| 描述 | SOME/IP 协议应为特殊服务定义保留标识符。这些标识符不能用于普通服务。 |
|---|---|
| 理由 | 出于兼容性原因，需要定义一段保留 ID。之后 OEM 可以使用它们而不干扰其余服务。 |
| 用例 | 非 SOME/IP 服务的服务发现。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.10. SOME/IP 协议应支持使用唯一标识符标识 RPC 的调用方¶
| 描述 | SOME/IP 协议应支持使用系统中对该 RPC 唯一的标识符标识 RPC 的调用方。 |
|---|---|
| 理由 | 当同一 ECU 上、使用同一套接字连接的多个调用方使用同一 RPC 方法时，需要标识调用方，以便将响应正确地分配给相应的请求。 |
| 用例 | 从位于一台或多台远程机器上的多个调用方调用一个 RPC 方法。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3. On Wire Representation（线上表示）¶
3.3.1. SOME/IP 协议应定义消息的报头布局¶
| 描述 | SOME/IP 协议应为相应版本定义消息的报头布局。 |
|---|---|
| 理由 | 通信伙伴需要理解报头的布局。 |
| 用例 | 不同参与方之间的通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.2. SOME/IP 协议应规定数据的序列化算法¶
| 描述 | SOME/IP 协议应规定数据的序列化算法，以将机器特定的内存表示转换为统一的网络表示。 |
|---|---|
| 理由 | 数据的内存表示高度依赖处理器架构和编译器设置，而车辆内各机器的这些设置互不相同。 |
| 用例 | 使用不同处理器架构的通信伙伴之间的载荷通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.3. SOME/IP 协议应规定载荷中数据的对齐方式¶
| 描述 | SOME/IP 协议应规定载荷中数据的对齐方式。这包括基本数据类型的起始位置以及它们之间的间隙。 |
|---|---|
| 理由 | 如果速度很重要，能够影响对齐并进行优化会很有用。 |
| 用例 | 对结构化数据类型的序列化表示的快速访问。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.4. SOME/IP 协议应定义报头和载荷的字节序¶
| 描述 | SOME/IP 协议应定义报头和载荷中数据表示的字节序。通信伙伴在网络上应使用该字节序。 |
|---|---|
| 理由 | 如果字节序不同的机器相互通信，则需要定义网络上的格式。 |
| 用例 | 一台小端机器与一台大端机器通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.5. SOME/IP 协议应支持传输整数数据类型¶
| 描述 | SOME/IP 协议应支持传输 8、16 和 32 位长度的有符号和无符号整数数据类型。 |
|---|---|
| 理由 | 为了规定 SOME/IP 的序列化算法，SOME/IP 需要支持一组基本数据类型。 |
| 用例 | C 数据类型的通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.6. SOME/IP 协议应支持传输布尔数据类型¶
| 描述 | SOME/IP 协议应支持传输布尔数据类型。 |
|---|---|
| 理由 | 为了规定 SOME/IP 的序列化算法，SOME/IP 需要支持一组基本数据类型。 |
| 用例 | 布尔值的通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.7. SOME/IP 协议应支持传输浮点数据类型¶
| 描述 | SOME/IP 协议应支持传输称为单精度和双精度的浮点数据类型（在 IEEE 754 [3] 中定义为 binary32 和 binary64）。 |
|---|---|
| 理由 | 为了规定 SOME/IP 的序列化算法，SOME/IP 需要支持一组基本数据类型。 |
| 用例 | C 数据类型的通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.8. SOME/IP 协议应支持传输结构化数据类型¶
| 描述 | SOME/IP 协议应支持传输结构化数据类型，它们可以由一个或多个固定或可变大小的结构化数据类型和/或基本数据类型组成。 |
|---|---|
| 理由 | 为了规定 SOME/IP 的序列化算法，SOME/IP 需要支持一组数据类型。 |
| 用例 | 多于一个基本数据类型的一致性通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.9. SOME/IP 协议应支持传输联合数据类型¶
| 描述 | SOME/IP 协议应支持传输联合数据类型，其中具体数据类型在执行期间确定。 |
|---|---|
| 理由 | 为了规定 SOME/IP 的序列化算法，SOME/IP 需要支持一组数据类型。 |
| 用例 | 可动态选择表示方式的数据通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.10. SOME/IP 协议应支持传输一维和多维数组数据类型¶
| 描述 | SOME/IP 协议应支持传输一维和多维数组数据类型。 |
|---|---|
| 理由 | 为了规定 SOME/IP 的序列化算法，SOME/IP 需要支持一组数据类型。 |
| 用例 | 同一类型的多个数据元素的一致性通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.11. SOME/IP 协议应支持传输固定长度的数组数据类型¶
| 描述 | SOME/IP 协议应支持传输固定长度的数组数据类型，它们表示数组元素的固定数量。 |
|---|---|
| 理由 | 为了规定 SOME/IP 的序列化算法，SOME/IP 需要支持一组数据类型。 |
| 用例 | 特定数量的同类型数据元素的一致性通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.12. SOME/IP 协议应支持传输灵活长度的数组数据类型¶
| 描述 | SOME/IP 协议应支持传输具有灵活数据元素数量的一维和多维数组数据类型。应提供数据元素的最大数量。 |
|---|---|
| 理由 | 为了规定 SOME/IP 的序列化算法，SOME/IP 需要支持一组数据类型。 |
| 用例 | 可变数量的同类型数据元素的一致性通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.13. SOME/IP 协议应支持传输固定长度的字符串类型¶
| 描述 | SOME/IP 协议应支持传输固定长度的字符串类型。 |
|---|---|
| 理由 | 为了规定 SOME/IP 的序列化算法，SOME/IP 需要支持一组数据类型。 |
| 用例 | 字符串的通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.14. SOME/IP 协议应支持传输灵活长度的字符串数据类型¶
| 描述 | SOME/IP 协议应支持传输灵活长度的字符串数据类型。应提供最大长度。 |
|---|---|
| 理由 | 为了规定 SOME/IP 的序列化算法，SOME/IP 需要支持一组数据类型。 |
| 用例 | 字符串的通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.15. SOME/IP 协议应支持在载荷中提供序列化数据元素的长度¶
| 描述 | SOME/IP 协议应支持在载荷中提供序列化数据元素的总长度，而无需解析该元素的内容。 |
|---|---|
| 理由 | 长度信息可用于在不解析数据或不了解内部结构的情况下确定下一个序列化数据元素的起始位置。 |
| 用例 | 通过在末尾添加附加元素实现结构体的向后兼容扩展。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.16. SOME/IP 协议应支持可扩展数据结构体的序列化¶
| 描述 | SOME/IP 应支持带标签数据元素的结构体的序列化，以支持可选元素和接口定义的简便扩展。标签充当各元素的标识符。附加的长度字段允许在反序列化期间跳过未知元素。 |
|---|---|
| 理由 | 允许紧凑传输带可选元素的复杂数据结构，允许在不重新编译既有代码的情况下兼容扩展现有接口。 |
| 用例 | 带标识符和可选成员的结构化数据类型的序列化。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4. 参考文献¶
AUTOSAR_FO_TPS_StandardizationTemplate
AUTOSAR_FO_TR_Glossary
[3] IEEE Standard for Floating-Point Arithmetic (IEEE Std 754-2008)
A. AUTOSAR 可追溯项变更历史¶
A.1. 本文档依据 AUTOSAR 版本 R23-11 的可追溯项变更历史¶
A.1.1. R23-11 中新增的需求¶
无
A.1.2. R23-11 中变更的需求¶
无
A.1.3. R23-11 中删除的需求¶
无