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)定义,并且在可能的情况下应采用网络字节顺序,如果没有指定其他字节顺序。
欢迎关注公众号