SOME/IP协议（上）

Scalable service- Oriented Middle ware over IP
可拓展的面向服务的中间件基于ip
SOME/IP于2011年由BMW设计，2014年纳入 AUTOSAR规范，推动汽车电子从 "信号导向" 向 "服务导向service" 转型，加速功能迭代与创新。
是一种基于IP网络的可拓展面向服务的中间件协议， 应用层协议 旨在为分布式系统（车载电子系统）提供高效、灵活的服务通信能力，核心定位是作为中间件"Middleware"在 ip协议栈之上构建服务导向架构（SOA），实现不同功能模块（如车载电子控制单元ECU）之间的标准化数据交互。
该协议用于替代了信息娱乐要等MOST通信场景（MOST表示面向媒体的系统传输，正在被CAN或以太网取代），替代了如车身域等部分传统CAN通信场景，提供车内信息交互的中间件解决方案。
SOME/IP是专为车载网络设计，解决服务提供方与消费方之间网络通信的问题。类似于中间人（Middleware）的一个角色。
SOME/IP报文打包了服务接口的内容：

面向服务（服务发现、调用、发布/订阅）支持动态服务发现（SOME/IP-SD）

SOME/IP允许应用程序之间通过以太网和TCP/IP进行通信，整体属于CS架构（服务器，客户端，RPC方式）
数据包格式由服务的规范自动确认。
服务器提供一个实现服务接口的服务实例
客户端使用SOME/IP访问服务实例。

1.2、发展背景与标准化进程

**车载网络复杂度激增:**传统汽车电子以机械控制为主，ECU(电子控制单元)数量通常在10-30个，通信依赖CAN(控制器局域网)、LIN(本地互联网络)等总线协议。随着智能化、网联化发展，现代汽车ECU数量已突破100个(高端车型达150+)，涉及自动驾驶、信息娱乐、车身控制等多个域，传统总线存在带宽低(CAN最高1Mbps)、拓扑固定、难以支持跨域通信等局限。
**服务导向架构(SOA)转型:**传统车载通信采用"信号导向"模式(如CAN信号)，需预先定义信号的传输周期、优先级，修改成本高。而SOA架构将功能封装为"服务"(如"导航服务"灯光控制服务")，支持动态调用与组合，更适应自动驾驶等场景的灵活功能迭代需求。
**IP化趋势:**以太网凭借高带宽(100Mbps/1Gbps)、灵活拓扑(星型、环型)、IP兼容性，逐渐成为车载主干网络。SOME/P作为以太网之上的中间件，填补了IP协议与车载应用之间的适配空白--IP协议仅解决"数据如何传输""，而SOME/P解决"传输什么服务"如何调用服务'
标准化进程：
SOME/IP的标准化主要由AUTOSAR(汽车开放系统架构)组织推动:
2014年，AUTOSAR4.2版本首次引入SOME/IP规范，定义核心通信机制;
2017年，AUTOSAR4.5版本完善服务发现(SOME/IP-SD)与诊断功能;
2021年，AUTOSAR4.9版本新增安全扩展(SOME/IP-Sec)与时间敏感网络(TSN)适配;
目前最新版本为AUTOSAR4.10(2023年发布)，强化对5G车联网与L4自动驾驶的支持。

1.3、协议栈层级

SOME/IP 位于 OSI 模型的会话层与应用层之间，其协议栈结构如下：

物理层：车载以太网（100BASE-T1/1000BASE-T1）或其他物理介质；
数据链路层：IEEE 802.3（以太网），支持 TSN（时间敏感网络）增强；
网络层：IPv4（主要）或 IPv6；
传输层：UDP（实时性优先）或 TCP（可靠性优先）；
中间件层：
- SOME/IP 核心：消息封装、路由、序列化；
- SOME/IP-SD：服务发现；
- SOME/IP-Sec：安全增强（加密、认证）；
应用层：车载服务（如 ADAS 服务、车身控制服务）。
其数据流转路径为：应用层数据经 SOME/IP 序列化与封装后，通过 TCP /UDP 传输，经 IP 路由至目标节点，再由接收方 SOME/IP 解析为应用层数据。

1.4、传输层的选择：TCP vs UDP

SOME/IP支持UDP和TCP两种传输层协议，根据场景动态选择：
SOME/IP 通过配置制定服务的传输层协议，例如："碰撞预警时间"使用 UDP（需要快速响应），"软件升级服务"使用 TCP（需要确保数据完整）

1.5、SOME/IP的功能

序列化： 将数据结构或对象依据事先定义的规则转换成二进制的过程，以便于数据在网络传输
**远程过程调用（RPC）：**通过在网络传输消息实现一个节点对另一个节点的方法调用
服务发现（SD）： 一种特殊的服务，基于该服务，客户端可以寻找所需服务，服务端可以告诉大家那些服务可用，客户端和服务端动态建立通信连接
**订阅/发布：**客户端可以向服务端订阅所需的数据，服务端以周期或者事件触发的方式发布这些数据
**UDP报文分段（AUTOSAR4.3）:**允许通过UDP传输大型SOME/IP报文，而无需在IP层分片。（避免了ip层分片，因为UDP没有数据重传如果ip层分片数据丢失很麻烦）
SOME/IP的设计围绕车载场景的核心需求展开，包括：

**可扩展性:**支持从简单ECU到复杂域控制器的规模扩展，服务数量可动态增减(理论无上限);
实时性:支持硬实时(如转向控制，延迟<10ms)与软实时(如信息娱乐，延迟<100ms)场景，通过传输层选择(UDP/TCP)与优先级机制适配:
**服务导向:**以"服务"为核心抽象，支持请求-响应(Request-Response)、发布-订阅(Publish-Subscribe)等交互模式;
**轻量化:**协议overhead低(最小消息头仅8字节)，适合资源受限的ECU(如8位/32位MCU);
**兼容性:**兼容现有IP网络(IPv4/IPv6)、传输层协议(UDP/TCP)与传统总线(通过网关转换)
**灵活性:**支持静态配置(预定义服务关系)与动态发现(服务即插即用)

1.6、服务导向架构（SOA）

SOME/IP 基于SOA架构，其核心思想是：将车载功能封装为 "服务"，通过标准化接口实现跨 ECU 调用，而非直接操作硬件或底层信号。
SOA 在 SOME/IP 中的体现如下：

服务（Service）：功能的最小封装单元，由唯一标识符（Service ID）标识。例如 "雨刮控制服务"" 电池状态服务 "。
服务提供者（Service Provider）：提供服务的实体（如 ECU），负责实现服务逻辑并响应调用。
服务消费者（Service Consumer）：使用服务的实体（如另一个 ECU），通过接口调用服务功能。
接口（Interface）：服务的对外交互规范，定义可调用的方法、可订阅的事件与可访问的字段。
什么是SOA（Service Oriented Architecture面向服务的架构）

1.7、标识符体系

SOME/IP 通过多级标识符确保消息准确路由与解析，核心标识符如下：

二、SOME/IP的服务接口

在车载领域里，服务接口Service Interface就是获取服务的方式，
SOME/IP支持三种核心交互模式，覆盖车载场景绝大多数通信需求
服务接口（Service Interface）

Method------方法
Property/Field------属性/字段（有点像Python字典的参数一样）
Event------事件

2.1、Method------方法麦森得

客户端向服务端发送请求报文（有2种类型） 典型的RPC机制

服务端收到客户端发送的Request会回复响应报文（RR-Method） Request/Pesponse
服务收到客户端发送的Request不需要回复响应报文（FF-Method） Fire&Forget

2.1.1、请求-响应（Request/Response）

定义：消费者想提供者发送"请求"消息，提供者执行操作后返回"响应"消息。
适用场景：需要即使反馈的操作，如"查询当前车速""设置空调温度"。
流程：

消费者发送包含"方法调用"的请求信息（Message Type=Requets）；
提供者接收后执行方法逻辑；
提供者返回包含"执行结果"的响应消息（Message Type=Response）,若失败则携带错误码。

2.1.2、请求-无需响应（Fire/Forget）

不需要回复响应报文（FF-Method） Fire&Forget

2.2、Event---事件（发布订阅）

客户端需要订阅一个服务，服务端发布该服务（周期性发送，或者发生变化时发送）（Notification机制）
定义： 提供者主动 "发布" 事件（Event），消费者 "订阅" 后接收事件数据，无需主动请求。
适用场景： 周期性或触发式数据推送，如 "车速变化事件"" 碰撞预警事件 "。

流程：

消费者发送订阅请求（通过 SOME/IP-SD）；
提供者确认订阅后，当事件触发时发送通知消息（Message Type=NOTIFICATION）；
消费者接收并处理通知。

2.3、 Propert/Field---属性/字段交互

1） Getter/Setter （字段Field交互）客户端请求获取/设置某一属性或者状态
**定义：**字段是服务中可读写的数据项（如 "当前油量"），支持消费者读取（Get）或修改（Set）。
**适用场景：**需要直接访问状态数据的场景，兼具请求 - 响应（读写操作）与发布 - 订阅（数据变化通知）特性。
流程：

消费者发送 Get 请求获取字段值（响应模式）；
消费者发送 Set 请求修改字段值（响应模式）；
字段值变化时，提供者主动发布通知（订阅模式）。

2）Notification（变更通告 ） :客户端订阅某一属性/值后，服务端发布该服务，发布条件同Event，不同的是订阅后服务端会立即发送此 Field的内容
变更通知 字段数值发生变化时，服务端 主动异步上报推送。

两者不同对比：

Getter和Setter都是通过Requst-Response的方式，或取或者设置某一字段
Notifier是在Subscribe（订阅）之后，如果字段发生变化，主动的推送Notification去告知。

**总结：**Event和Field都有订阅的相关内容，以下做一下区分：
Event（事件）类似通知的功能，例如收到新消息提醒。
Field（字段）类似状态监控的功能，例如手机设置中的亮度调节，可以读取当前亮度，设置新亮度，并在亮度变化时收到通知。

三、SOME/IP报文格式

SOME/IP的报文格式由消息头（Header）和消息体（Payload）组成

Meggage ID： 消息ID 32bit，报文的唯一标识符（高16位 Service ID+ 低 16 位 Method/Event/Field ID）例如 Service ID=0x1234、Method ID=0x0001，则 Message ID=0x12340001。 ------0x表示16进制

如果第17bit=0后面15bit就是Method id方法；
如果第17bit=1后面15bit就是Event id事件。

Length： 载荷长度 32bit，(不包含消息头本身，标识length字段之后的数据的长度）
Request ID：请求标识ID 32bit，消费者生成，确保并发请求可以区分，用于匹配请求和响应。
Client ID：16bit，区分请求同一服务Service的不同客户端
Session ID：16bit，同意客户端请求同一服务Service的次数

Protocol version： SOME/IP协议版本 8bit，当前固定为0x01
Interface version ：服务接口的版本号 8bit,（主要做服务一致性和兼容检测支持 "向后兼容"------ 消费者使用 v1 接口，提供者支持 v2 接口时，需兼容 v1 的方法与数据格式）
Message Type ：报文/消息类型 8bit （重点）

Return Code ：响应状态 8bit ，表示请求是否被成功处理，仅在 RESPONSE 或 ERROR 消息中有效，常见值包括：
E_OK(0x00):成功
E_NOT_OK(0x01):未知错误
E_UNKNOWN_SERVICE（0x02）：服务不存在/未知的服务ID
E_UNKNOWN_METHOD（0x03）：方法不存在
E_INVALID_ARGUMENT（0x04）：参数无效
**Payload：**载荷，不定长度
Payload 是消息的实际数据部分，格式由服务接口定义，支持基本数据类型、复杂类型（结构体、数组）等。
Payload 的结构需通过接口描述文件（如 ARXML）预先定义，确保消费者与提供者的解析一致性。
报文示例