当前位置：首页 > news >正文

SOME/IP协议详解基础解读涵盖SOME/IP协议解析 SOME/IP通讯机制协议特点错误处理机制

news 来源：原创 2025/8/10 11:54:57

车载以太网协议栈总共可划分为五层，分别为物理层，数据链路层，网络层，传输层，应用层，其中今天所要介绍的内容SOME/IP就是一种应用层协议。

SOME/IP协议内容按照AUTOSAR中的描述，我们可以更进一步的拆分为三类子协议：应用层的SOME/IP标准协议，SOME/IP-SD协议以及TP层的SOME/IP-TP协议。

SOME/IP协议特点

特点	描述
Serialization(序列化)	在ECU内部进行序列化及反序列化以实现信息的高效传输
Remote Procedure Calls(远程调用)	该协议可以传递消息(作为字段发送)以及方法的远程调用(实现过程/函数调用)
Service Discovery(服务发现)	SOME/IP协议的数据通信发生在客户端-服务器模型中,同时服务器提供客户端可以订阅的许多不同服务。该协议允许客户端动态查找服务、订阅服务并配置对服务的访问。
Publish/Subscribe(发布与订阅)	SOME/IP中的数据通信通过发布/订阅进行。客户端可以订阅服务器提供的服务,服务器可以向活跃的订阅者发布通知。
Segementation of UDP message	每当服务器必须向活动订阅者发送通知时，他们是通过UDP协议发送的。SOME/IP能够在不需要任何分段的情况下传送大型UDP消息。

SOME/IP协议解析

如果应用了 E2E 通信保护，则 E2E 报头将放置在 Return Code 之后，具体取决于为 E2E 报头选择的偏移值。默认偏移值为 64 位，这将 E2E 报头恰好放置在 Return Code 和 Payload 之间。

SOME/IP协议Header包含Message ID，Request ID, Protocal Version 以及Interface Version。

各字段解释如下：

Item	Description
Message ID	前2个字节为Service ID，后2个字节为Method ID（每个服务仅定义一个唯一的Service ID，Method ID的最高位为0即为方法（包括Method Filed.Getter及Filed.Setter），最高位为1就为事件（包括Event和Filed.Notify））
Length	标识从Request ID开始至SOME/IP报文结束的长度
Request ID	前2个字节为Client ID，用来识别一个客户端；后2个字节为Session ID，用来识别同一个客户端的多次请求。（其中Client ID可通过配置前缀或者固定值来实现唯一性，可不进行Session处理，如果需要，则Session ID需根据各自的用例从0x0001递增）
Protocol Version	协议版本号，目前固定为1
Interface Version	用来识别服务接口的主版本号，由用户定义
Message Type	用来识别不同的消息类型，Message Type（8Bits）的Bit5标识TP-Flag，当TP-Flag=1时，标识一个TP类型的Message Type (当SOME/IP下层通信协议为UDP，且SOME/IP传输大数据（>1452Bytes）时，将使用SomeIpTp进行分段）
Return Code	用来指示Message是否被成功处理了，或针对请求中的错误内容进行反馈
E2E Header	可选是否使能，并且可变长度（默认长度是8Bytes），可选使用一种E2E profile（常用E2E Profile4）
Payload	有效载荷，序列化和反序列化定义了 PDU 中所有数据结构的确切位置，并且考虑了内存对齐

Message Type

用来识别不同的消息类型，目前存在的类型如下所示，其中TP表示分包的报文,按照AUTOSAR标准(R21-11)定义如下：

ID	Name	Description
0x00	REQUEST	A request expecting a response 请求并期待响应
0x01	REQUEST_NO_RETURN	A fire&forget request 请求但不期待响应
0x02	NOTIFICATION	A request for a notification expecting no response 通知/事件回调的请求，不期待有响应
0x40	REQUEST_ACK	Acknowledgment for REQUEST (optional) REQUEST的ACK确认
0x41	REQUEST_NO_RETURN_ACK	Acknowledgment for REQUEST_NO_RETURN (informational) REQUEST_NO_RETURN的ACK确认
0x42	NOTIFICATION_ACK	Acknowledgment for NOTIFICATION (informational) NOTIFICATION的ACK确认
0x80	RESPONSE	The response message 响应
0x81	ERROR	The response containing an error 响应中包含的错误
0x20	TP_REQUEST	TP segment of a Request Message for methods TP请求并期待响应
0x21	TP_REQUEST_NO_RETURN	TP segment of a Request Message for Fire & Forget methods TP请求但不期待响应
0x22	TP_NOTIFICATION	TP segment of an Event (Notification) Message TP通知/事件回调的请求，不期待有响应
0xA0	TP_RESPONSE	TP segment of a Response Message for methods TP响应
0xA1	TP_ERROR	TP segment of an Error Message for methods TP响应中包含的错误

Return Code

用来指示Message是否被成功处理了，或针对请求中的错误内容进行反馈，如下为AUTOSAR(R21-11)中定义的Return Code类型：

ID	Name	Description
0x00	E_OK	没有错误发生
0x01	E_NOT_OK	发生了未定义的错误
0x02	SOMEIPXF_E_UNKNOWN_SERVICE	未知的服务ID
0x03	SOMEIPXF_E_UNKNOWN_METHOD	未知的Method ID
0x04	SOMEIPXF_E_NOT_READY	应用程序未就绪
0x05	SOMEIPXF_E_NOT_REACHABLE	运行该服务的系统不可用
0x06	SOMEIPXF_E_TIMEOUT	发生超时
0x07	SOMEIPXF_E_WRONG_PROTOCOL_VERSION	SOME/IP协议版本不支持
0x08	SOMEIPXF_E_WRONG_INTERFACE_VERSION	接口版本不匹配
0x09	SOMEIPXF_E_MALFORMED_MESSAGE	反序列化错误
0x0A	SOMEIPXF_E_WRONG_MESSAGE_TYPE	接收到不符合预期的消息类型
0x0B	E_E2E_REPEATED	E2E重复错误
0x0C	E_E2E_WRONG_SEQUENCE	E2E错误的时序
0x0D	E_E2E	没有进一步的E2E错误
0x0E	E_E2E_NOT_AVAILABLE	E2E不可用
0x0F	E_E2E_NO_NEW_DATA	没有E2E计算的新数据
0x10-0x1F	RESERVED	预留给到SOME/IP一般性错误
0x20-0x5E	RESERVED	预留给到服务及方法的特定错误

Payload的序列化与反序列化

SOME/IP报文收发的过程中，上层应用所定义的Method、Event、Field参数都是面向用户的struct，string等，序列化就是将这些输出参数转换为字节流的过程；而反序列化的过程正好相反，就是将字节流反向解析成struct、string等具体的参数。

大小端：

SOME/IP报文的payload(负载)大小端(字节序)指的是数据在内存中的存储和传输顺序。在计算机系统中,数据的存储和传输顺序主要有两种标准:大端字节序(Big-Endian)和小端字节序(Little-Endian)。

-大端字节序(Big-Endian):是指数据的高位字节存放在低地址处,而低位字节存放在高地址处。也就是说,从内存的起始位置开始,第一个字节是最高位字节。

-小端字节序(Little-Endian):是指数据的低位字节存放在低地址处,而高位字节存放在高地址处。在这个模式下,内存起始位置存放的是最低位字节。

SOME/IP报文的payload部分可以采用上述两种字节序中的任何一种,这取决于数据交换双方的协议约定或者通信端点的实现。在网格协议中,端字节序通常由协议规范明确指出。开发者在处理SOME/IPP报文时,必须确保发送方和接收方在端字节序上保持一致,以避免数据解析错误。

SOME/IP通信机制

服务发现(Service Discovery)

服务发现的通信机制是通过SOME/IP-SD协议实现的，主要是为了实现在车载以太网中告知客户端当前服务实例的可用性及访问方式，可通过Find Service 和Offer Service来实现。

SOME/IP 服务发现流程可以分为以下三大基本步骤：

Client通过发送Find Service的报文去寻找车载网络中可用的服务实例；

Server接收到Client的Find Server后通过UDP发送Offer Service响应；

Client通过发送Subcribe Event Group去订阅相关Event；

Server检查是否满足Client是否满足订阅条件，如果满足回复ACK，如果不满足，则回复NACK；

Client成功订阅相关事件后，Server会按照事件本身属性来实现对已订阅该事件的Client的发布；

远程进程调用(RPC)

远程进程调用主要可分为四种通信模式：

Request/Response通信模式

可归纳为Method中的一种；其基本通信模型如下图所示：

Request-Response模型作为一种最为常见的通信方式，其主要任务就是客户端发送请求信息，服务端接收到请求，进行相关处理之后进行相应的响应。

Fire&Forget通信模式

可归纳为Method中的一种；

该通信模型的主要任务就是客户端向服务端发送请求，服务端无需进行任何响应，有点类似诊断服务中的抑制正响应。

Notification Event通信模式

该通信模式主要描述了发布 /订阅消息内容，主要任务就是为了实现客户端向服务端订阅相关的事件组，当服务端的事件组发生或者值发生变化时，就需要向已订阅该事件组的客户端发布更新的内容。

远程进程控制(Field)

访问进程通信机制主要是为了实现针对对应用程序的数据获取与更改，主要任务就是实现客户端通过Getter获取Server的值，通过Setter设置Server的值。

Field就可理解为一个Service的基本属性，可包含Getter，Setter，Notifier三种方式。其中Getter就是读取Field中某个值的方法，Setter就是一种改变Field值的方法，而Notifier则是一种当Field中的值发生变化的触发事件，发生变化时就通知Client。

错误处理机制

AUTOSAR为了更为高效的定位到通讯过程中的问题所在，制定了一套检查SOME/IP协议格式内容的错误处理机制。比如版本信息检查，服务ID等，其他故障信息可以在Payload中进行详细定义。目前SOME/IP支持以下两种错误处理机制，这两种uowu处理机制可以根据配置进行选择。

-消息类型0x80，Response信息，即可以通过Response Message中的Return Code来定位到问题所在；

-消息类型0x81，显式的错误信息；

主要是校验协议首部结构，对Message Type和Return code进行赋值，通知对端。

参考：

AUTOSAR SOME/IP Protocol Specification：https://www.autosar.org/fileadmin/standards/R19-11/FO/AUTOSAR_PRS_SOMEIPProtocol.pdf

智猩猩