文章目录

- 前言
- SOME/IP概念
- SOME/IP协议格式
- SOME/IP功能介绍
- - 序列化
  - - 序列化规则
  - 发布和订阅
  - 服务发现（SOME/IP-SD）
  - SOME/IP-TP协议使用场景
  - - SOME/IP-TP协议
- 参考文章：

前言

本文介绍了SOME/IP协议的具体内容，包括报文格式，协议选择、序列化、服务发现等。同时介绍了SOME/IP-TP协议。

SOME/IP概念

SOME/IP是一种汽车中间件解决方案，SOME/IP全称：Scalable service-Oriented MiddlewarE over IP（位于IP协议蹭之上的一种面向服务的可扩展的中间件），是一种基于以太网的协议，提供面向服务的接口。由宝马集团在2011年设计开发，并在2014年集成进AUTOSAR4.X中。并且是唯一已知的集成到AUTOSAR 4.x版本中的中间件。

SOME/IP协议是在IP层之上的，属于应用层协议。

为什么需要SOME/IP？

传统汽车协议的局限性：传统的汽车协议如 CAN、MOST、LIN 和 Flexray 等，存在带宽有限的问题，难以满足现代汽车日益增长的高数据传输需求。基于IP网络，SOME/IP能够利用现有的IP网络基础设施，提供服务发现、描述、配置以及调用等功能
SOME/IP的可扩展性：SOME/IP能够实现不同硬件平台，不同操作系统或嵌入式固件之间的可扩展和互操作

SOME/IP协议格式

SOME/IP协议由消息头(header)和数据段(payload)组成。

message ID是唯一的。前16位标识服务，后16位标识方法
1. 对于Method，Method ID的第一位为0，对于Event，Method ID的第一位为1

Length(32 bit)标识后续的Request ID到payload的字节长度。
Request ID(32 bit)由2个字节的Client ID 和2个字节的Session ID组成。Client ID用于区分使用同一Method的不同客户端，session ID由数据的发送方每发送一次数据+1，从0x1加到0xffff后，从1重新开始，用于区分每一条消息

client ID只有两个字节，能够同时支持多少客户端？支持65536个

Protocol Version协议版本号，目前该值为1
Interface Version接口版本号，一般由服务者提供者定义
Message Type 用于标识消息的类型，例如Error，REQUEST, RESPONSE等

Return Code用来标识请求是否被处理
payload长度可变，携带的是真正的数据

说明：

SOME/IP报文可以选择UDP或者TCP进行传输。使用UDP时一般payload大小在0~1400字节，大于1400字节时，应当使用TCP对负载分段。

对于TCP和UDP的选择并非强制，一般来说要求低时延用UDP，数据大用TCP

要求低时延且数据大可以用UDP结合SOME/IP-TP。后文会详细介绍SOME/IP-TP

SOME/IP功能介绍

SOME/IP支持的中间件功能：序列化、远程过程调用、服务发现、发布与订阅。

序列化

序列化指的是讲数据结构或对象按照事先定义的规则转换成可存储、可传输的线性字节流或特定格式文本（如 JSON、XML）的过程。与之相反的逆过程称为 “反序列化（Deserialization）

在AUTOSAR中，软件组件将数据从应用层传递到RTE层，在RTE层调用SOME/IP Transformer，执行可配置的数据序列化或者反序列化

SOME/IP 不自动插入填充字节，若需对齐（如 32 位数据对齐到 4 字节地址），需用户在结构体定义时显式添加保留字段

序列化规则

SOME/IP 不自动插入填充字节，若需对齐（如 32 位数据对齐到 4 字节地址），需用户在结构体定义时显式添加保留字段

SOME/IP序列化与反序列采用LTV（Length-Type-Value）格式来进行的。并且Value中包含因字节对齐的填充

LTV的规则并非需要严格遵守

数据类型	是否严格遵守 LTV	说明	类比
所有基本类型 (uint8, int32, float64, boolean)	否	只有 V。L 和 T 由接口定义隐含。	就像 C 语言中的 `struct { int a; char b; }` ，成员位置和大小固定。
字符串、数组、结构体、联合体	是	必须包含显式的 L（长度字段）。T 可能显式（联合体）或隐含。	就像网络协议中的 TLV 或 JSON 中的 `{"key": "value"}`，需要自描述性。

同时为了兼容性，还可以新增一个两字节的Tag在序列化中。是否使用带Tag的序列化，取决于对应ARXML文件中的配置。当使用带有tag的序列化时，即使发送方新增结构体的成员，旧版本的接收方也可以安全跳过不认识的字段，从而实现兼容。

举例如下：

ECU A（软件版本 1.0）向 ECU B 发送一个结构体VehicleData，包含speed和rpm两个成员。
后来，软件升级了。ECU A 更新到版本 2.0，VehicleData结构体增加了一个新成员 gear。 ECU B 没有升级（还是版本 1.0），它收到来自版本 2.0 的 VehicleData 消息时，遇到gear对应的tag，会自动跳过解析这个字段。

发布和订阅

Method方法（请求/响应交互模式）
1. Request/Reponse客户端发送请求，服务端应答
2. Fire/Forget 客户端发送请求，服务端不需要应答
Event事件（事件通知模式）
1. 单项数据传输，client订阅Server服务，Server发布信息到Client（当数据变化时才发送，适合实时状态监控，告警通知等）
Field字段（远程属性访问模式）
1. 分为Notifier、Getter、Setter，分别表示Server向Client主动发送消息、client向server请求数据，以及Client修改Server的数据

一些区别：

Method：是客户端主动发起的 “请求 - 响应”（如 “查询当前车速”），只需知道服务地址即可直接调用，无需提前订阅；
Event 和 Field中的notifier：Event是服务端主动推送的 “通知”（如 “车速超过 100km/h 时自动推送警告”）， Field中的notifier是客户端必须先通过 SD 服务告知服务端 “我需要接收这些通知”，服务端才会针对性推送。
Field和Event的区别：Field是一个持续存在的变量，如多媒体音量、车速、环境温度等。这些可以在任何时刻获取；而Event指的是一个事件，事件没有就不发生，比如发生碰撞、出现故障等

服务发现（SOME/IP-SD）

SOME/IP-SD（Service Discovery）是 SOME/IP 协议中用于服务发现的一种机制，允许网络中的客户端动态地发现和定位服务实例。

SOME/IP-SD服务只能采用UDP的两点原因：

SD服务需要进行组播，而TCP协议是点对点协议，无法进行组播；
SD服务往往需要快速广播或组播通知，UDP无连接特性更适合这种场景

功能：

定位服务实例：帮助在车载网络中确定服务实例的位置，虽然在车载网络中服务实例的位置通常是已知的，但 SOME/IP-SD 仍能提供更准确和动态的定位信息。
检测服务实例状态：能够检查服务实例的运行状态，及时了解服务是否可用。
实现发布 / 订阅处理：支持发布 / 订阅模式，使得消息仅发送给对其感兴趣的接收者，提高了通信效率和灵活性。

工作原理：

初始等待阶段：服务提供者和客户端在启动后，会等待一段时间（在 InitialDelayMin 和 InitialDelayMax 之间随机）再发送第一条 SD 消息，以避免启动时的网络拥塞，允许节点在网络中稳定后再进行通信。
重复阶段：服务提供者和客户端按照固定的时间间隔（如 100ms 的倍数）重复发送 SD 消息，加快两者之间的同步速度，确保服务信息的及时更新。
主阶段：服务提供者进入周期性发送 Offer Service 消息的阶段，客户端则根据需求发送 Find Service 消息，实现服务的持续发现和动态管理，确保客户端能够及时获取到最新的服务信息。

消息格式：

传输协议：SOME/IP-SD 消息通过用户数据报协议（UDP）发送。
服务 ID：固定为 0xFFFF，表示这是一个服务发现相关的消息。
方法 ID：固定为 0x8100。
长度字段：使用由 SOME/IP 指定的 uint32 长度字段，该字段从长度字段之后的第一个字节开始，一直到 SOME/IP-SD 消息的最后一个字节结束。
客户端 ID：应设置为 0x0000。

SOME/IP-TP协议使用场景

由于TCP协议需要连接过程，因此针对低时延的数据传输，往往采用UDP传输数据。而使用UDP传输大数据时，例如4M数据。由于UDP头部的长度采用2字节记录，因此UDP报文的最大长度约为64K。但其实在数据链路层MTU的长度为1500字节，除去头部占用的字节，大概真正携带的数据有1400多字节。因此超过这个字节数就会被IP层被动分片。而采用UDP传输时，由于无重传机制等，任意一个分片丢失都将会导致UDP这次传输的数据全部不可用，这是无法接受的。因此在使用UDP传输时，一般由应用层主动分片，并配有序号、校验、重传的机制。这也是SOME/IP-TP、QUIC等应用层协议处理UDP的思路