SOME/IP协议：汽车通信的核心技术解析

SOME/IP协议：汽车通信的核心技术解析

引用

CSDN

1.

https://blog.csdn.net/autosar_org/article/details/146061342

在汽车技术飞速发展的今天，以太网技术的广泛应用正在重塑车载通讯网络，带来了带宽和速度的显著提升。SOME/IP（Scalable service-Oriented MiddlewarE over IP）作为基于IP可拓展的面向服务的中间件，在汽车通讯领域发挥着关键作用。它不仅仅是一种通信协议，更是实现面向服务架构（SOA）的核心手段，通过支持远程服务调用（RPC）、事件通知和底层序列化等功能，为汽车内部复杂的通信需求提供了高效、灵活的解决方案。

SOME/IP核心要素

1.1 事件（Event）

• 单向数据传输：Event 是从服务端到客户端的单向数据传输形式，提供周期性或基于变化的数据发送机制，主要通讯方式为 event notifications。
• 订阅过程：客户端先订阅服务端的 event group，服务端返回 ACK 确认订阅结果。成功订阅后，服务端依据设定的触发条件发送 event notification。
• 发送方式：支持 Cyclic update（周期发送）、Update on change（发生改变时发送）、Epsilon change（发生改变且超过预设条件发送）三种方式，后两种发送方式的触发条件基于数据值或条件的变化，且 Epsilon change 还需满足差值超过预设值的要求。

1.2 方法（Method）

• 可调用实体：Method 是在服务端运行的可被调用的方法、程序函数或子程序，主要通讯方式包括 request response communication（R2，一发一回）和 fire forget communication（FF，仅客户端发起请求，服务端不回应）。

1.3 字段（Field）

• 数据表示：Field 用于表示包含确切变量的数据，变量访问由 Notifier、Getter、Setter 三种元素组成，且至少存在一种。Notifier 负责从服务端向客户端推送数据，Getter 用于获取服务端的值（读访问），Setter 用于修改服务端的值（写访问）。

SOME/IP报文格式

2.1 报文头结构

• SOME/IP 报文头包含 16 个 Byte，由 Message ID、Length、Request ID、Protocol Version、Interface Version、Message Type、Return Code 等字段组成，Length 计算从 Requset ID 开始到 Payload 尾部结束。在使用 E2E 的情况下，E2E Header 默认放置在 Return Code 和 Payload 之间，其长度可变，具体取决于所选的 E2E profile。

2.2 各字段含义

• Message ID：长度 32Bit，由 Service ID（16Bit）和 Method ID（16bit）组成，用于区分不同服务及服务中的 Method、Event、Field，在整车中应保持唯一。
• Request ID：同样为 32Bit，由 Client ID（16Bit）和 Session ID（16bit）组成，用于区分同一服务的多次请求，确保在多条 Request 报文中能准确追踪 Response 报文的状态及对应关系。
• Protocol Version 和 Interface Version：分别为 8bit，前者标识 SOME/IP 的协议版本，后者用于区分不同版本的服务支持范围。
• Message Type：8bit，用于标识消息类型，如 REQUEST、REQUEST_NO_RETURN、NOTIFICATION、RESPONSE、ERROR 等，不同类型对应不同的通讯场景和预期响应。
• Return Code：8bit，在不同类型的报文中有不同含义，用于指示请求的处理结果或错误信息，如 E_OK 表示无错误，E_NOT_OK 表示未指定错误等。
• Payload：长度取决于传输层协议，TCP 支持 payload 分段，适用于传输较大字节长度的数据；UDP 的 payload 长度为 0 - 1400 Byte。所有报头字段均按网络字节顺序（big endian）编码。

SOME/IP报文序列化

3.1 序列化定义

序列化是将对象的状态信息转换为可存储或传输形式的过程，反之则为反序列化。SOME/IP支持多种基础数据格式类型的序列化，包括布尔型、无符号整型、有符号整型、浮点型和双浮点型等。

3.2 结构体序列化

结构体的序列化需接近内存布局，参数按顺序序列化到缓冲区，同时要考虑内存对齐，以确保数据在内存中的存储和访问效率。

3.3 带标识符和可选成员的结构化数据类型和参数

为保证前向和后向兼容性，在结构体成员和方法参数前可增加额外的Data ID，Data ID与Wire type组成Tag（2 bytes）。Wire Type影响后续Member Data的数据类型和数据长度，当Wire Type为0 - 3时，Tag直接置于Member data之前，Length Field省略；当Wire Type为4 - 7时，Length Field生效。

3.4 数组序列化

支持一维数组和多维数组，以及定长度和可变长度数组。定长和可变长度由LengthField决定，数组维度决定其是一维还是多维数组。

3.5 其他数据类型序列化

字符串支持固定长度和动态长度，编码格式包括UTF - 8和UTF - 16，且必须以“\0”结尾，UTF - 16编码的字符串长度需为偶数。枚举和位字段作为无符号整型传输，联合体由长度、类型、Payload组成，Payload需进行内存对齐，建议采用四字节对齐以提升访问效率。

SOME/IP传输协议

4.1 UDP绑定

UDP支持单播和多播，其payload最大为1400Byte，若需传输更大数据，需使用SOME/IP - TP协议栈。UDP响应速度快，适用于对实时性要求较高、设置较短超时时间（如100ms）的应用场景，但仅支持Checksum进行数据完整性校验。

4.2 TCP特性

TCP协议支持分片，允许更大配置，具有更好的健壮性，可解决数据包丢失、重排序和重复等问题。在车载以太网中，TCP协议关闭了相关算法。使用TCP作为传输协议时，SOME/IP报文的可靠性达到exactly once。

4.3 可靠性语义

SOME/IP定义了不同的可靠性语义，UDP传输达到“maybe”可靠性，即报文可能送达；TCP传输达到“exactly once”可靠性，确保报文只送达一次。在UDP传输的RR通信中，若发生单次超时，SOME/IP会向客户端发送E_TIMEOUT信号。

4.4 SOME/IP - TP协议

当使用UDP传输超过1400Byte的SOME/IP报文时，需使用SOME/IP - TP进行分包。在SOME/IP Header之后有TP Header Offset标识分段信息，Message Type中bit5为TP - Flag，值为1代表TP报文。Offset表示已传输长度，首个分段offset为0，除最后一个分段外，其余分段长度建议为16字节整数倍，More Segment为分段结束标志，值为1表示后续还有分段，值为0表示为最后一个分段。

SOME/IP应用

5.1 在CP AUTOSAR中的应用

在CP AUTOSAR中，SOME/IP通过RTE与SWC交互，数据经序列化后通过communication stack传输到总线，反之则经反序列化后由SWC读取。对于大于1400字节的数据包，如通过UDP传输的SOME/IP报文，先由LD COM传输到PDUR，再由SOME/IP TP拆分后回传给PDUR，经路由通过UDP协议发送到以太网总线。

5.2 在AP AUTOSAR中的应用

在AP AUTOSAR中，SOME/IP位于ARA com的cluster中，可实现ECU内部及不同ECU之间的服务访问和订阅，为构建灵活、可扩展的汽车软件架构提供支持。

总结与展望

SOME/IP协议凭借其丰富的功能和灵活的架构，在汽车以太网通信中占据着重要地位。它不仅满足了现代汽车对高效、可靠通信的需求，还为未来汽车技术的发展奠定了坚实基础。随着汽车智能化、网联化程度的不断提高，SOME/IP协议将继续演进，为汽车行业带来更多创新和变革。期待未来SOME/IP在汽车领域的应用能够不断拓展，为我们带来更加智能、便捷、安全的出行体验。