1. 引言和功能概述

本文档规定了可扩展面向服务基于IP的中间件（SOME/IP）——一种用于汽车/嵌入式RPC机制和底层序列化/传输格式的示例，作为由RTE调用的序列化器。

唯一有效的缩写是SOME/IP。其他缩写（例如Some/IP）是错误的，不应使用。

从新实现“另一种RPC机制”而不使用现有基础设施/技术的基本动机是：

• 为了拥有一种满足嵌入式世界中资源消耗的严格要求的技术。
• 与尽可能多的用例和通信伙伴兼容，至少在传输格式层面与AUTOSAR兼容。
• 能够与AUTOSAR标准进行无修改的PDUs接收和发送通信。AUTOSAR内的映射应根据SOME/IP规范进行选择。
• 提供了汽车用例所需的功能。
• 从小型到大型平台都具备可扩展性。
• 可以在不同的操作系统上实现（例如AUTOSAR、GENIVI和OSEK），甚至可以在没有操作系统的嵌入式设备上实现。

SOME/IP仅是一个可用于ECU之间的客户端/服务器序列化的事例。SOME/IP的实现允许AUTOSAR解析RPC PDUs并将信号传输给应用程序。

因此，该示例定义了几个功能集。功能集“基本”与AUTOSAR 4.1.1兼容。其他功能集正在进行集成到AUTOSAR中。目标是增加与更高级功能集的兼容性。然而，也可以在非AUTOSAR节点中使用这些功能，或者使用经过精心设计的接口和适当的工具链，在AUTOSAR应用程序内部实现它们。

对于不使用AUTOSAR的ECU，目前可以支持完整的功能集，但在与AUTOSAR ECU进行通信时，只能使用有限的功能集。

在AUTOSAR中，如图1.1，SOME/IP和SOME/IP-SD可以在不同的模块中实现。目前，Socket适配器可以通过标头模式来写入消息ID和长度字段。
对于数据路径（SOME/IP），消息可以通过COM（Communication Manager）、RTE（Run-Time Environment）中的可插拔序列化器或代理SWS（Software Stack）进行序列化/反序列化。

对于控制路径（SOME/IP-SD），服务发现模块实现了SOME/IP-SD，包括SOME/IP标头，但不包括消息ID和长度字段。

限制

请注意，并非所有的SOME/IP部分都在AUTOSAR中实现。
SOME/IP的某些部分在 SWS SOME/IP Transformer、SWS Socket Adaptor 和 SWS Service Discovery 中得到了实现。
其他功能目前在AUTOSAR中不受支持。其中，以下功能在AUTOSAR中未实现：
• 异常和特定异常错误数据结构
• 变长结构体
• 将SOME/IP消息通过CAN和FlexRay进行隧道传输会导致 SWS Socket Adaptor 插入的部分头信息丢失

2. 标识符的定义

服务应使用Service-ID进行标识。Service-ID为0xFFFE应用于非SOME/IP服务的编码。Service-ID为0x0000和0xFFFF应保留用于特殊情况。同一车辆内的不同服务应具有不同的Service-ID。系统部门随时可以覆盖此要求。

使用Service-Instance-ID来识别服务实例。Service-Instance-ID应为16位长度的无符号整数（uint16）类型。Service-Instance-ID的0x0000和0xFFFF不应用于服务，因为0x0000用于描述无服务实例，而0xFFFF用于描述所有服务实例。同一车辆内的不同服务实例应具有不同的Service-Instance-ID。在服务内部，方法和事件应使用16位Method-ID进行标识，对于事件和通知，也可以称为Event-ID。

方法应使用将最高位设置为0的Method-ID，而对于事件和通知，Method-ID的最高位应设置为1。系统部门随时可以覆盖此要求。
使用Eventgroup-ID来标识事件组。Eventgroup-ID应为16位长度的无符号整数（uint16）类型。同一车辆内的不同事件组应具有不同的Eventgroup-ID。

注意：
这意味着两个不同的相机服务应具有两个不同的ServiceInstanceIDs，即SI-ID-1和SI-ID-2。对于一个AUTOSAR系统（设计车辆产品线），SI-ID-1在所有车辆中应保持相同。对于SI-ID-2也是如此。如果考虑另一个AUTOSAR系统（设计另一条车辆产品线），可以使用不同的ID，但在不同的AUTOSAR系统中使用相同的ID可以方便测试和集成。

3. SOME/IP在传输线上的格式规范

序列化描述了数据在汽车车载网络中传输的协议数据单元（PDU）中的表示方式。

3.1. 传输协议

SOME/IP可以使用UDP或TCP进行传输。在进一步通知之前，SOME/IP的端口号必须在本地从私有端口范围49152-65535中定义。在车辆中使用时，OEM将在接口规范中指定使用的端口。
建议尽可能使用UDP进行尽可能多的消息传输，并将TCP视为需要更大尺寸消息的备用方案。UDP允许应用程序更好地控制发生错误时的超时和行为。

3.1.1. 消息长度限制

结合常规以太网，IPv4和UDP可以传输最多1472字节的数据包而无需分片，而IPv6则额外使用20字节。特别是对于小型系统，应避免分片，因此SOME/IP标头和负载应具有有限的长度。使用安全协议可能进一步限制SOME/IP消息的最大大小。
当使用UDP作为传输协议时，SOME/IP消息可以使用最多1416字节的SOME/IP标头和负载，因此可用于负载的字节数为1400字节。

使用TCP允许传输更大的数据流来传输SOME/IP标头和负载。然而，用于CAN和FlexRay的当前传输协议将消息限制为4095字节。当需要与这些协议兼容时，SOME/IP消息（包括SOME/IP标头）的长度不得超过4095字节。

3.2. 字节序

所有RPC标头应以网络字节顺序（大端序）[RFC 791]进行编码。负载内部参数的字节顺序应由接口定义（例如FIBEX）定义，并且在可能的情况下应采用网络字节顺序，如果没有指定其他字节顺序。

欢迎关注公众号