SOMEIP官方文档【4 Protocol specification】

原创

已于 2025-07-22 17:43:52 修改 · 591 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#网络 #php #开发语言

于 2025-06-16 15:47:09 首次发布

SOME/IP提供基于车载网络的面向服务的通信功能，SOME/IP的服务定义列出了该服务可以对外提供的功能。一个SOME/IP服务由一个或者多个事件(event)，方法(method)和属性(field)组成。

其中事件(event)可以按照周期，也可以在数据发生变化的时候向服务的订阅者发送数据。

方法(method)让服务的订阅者发起远程方法调用，并且方法的执行在服务的提供这这边。

属性(field)由下面的三个部分组成（实际属性可以只包含其中的get,set或者notifier中的某一个或者多个）：

notifier: 当notifier关联的属性的值发生变化时或者周期性将属性的值从服务的提供方发送给服务的订阅方
getter: 可以被服务订阅方调用的方法（本质上是服务中的method），订阅方通过getter方法获取服务提供方的该属性的当前值
setter: 可以被服务订阅方调用的方法（同上），订阅方通过setter方法设置该属性的当前值

notifer和event的主要区别就是event一般是在数据发生变化的时候才发送给订阅方（vsomeip中在event的配置中增加update-cycle属性可以做到周期发送），而notifier是可以自动并且周期的将属性值发送给对方的。

4.1 Specification of SOME/IP Message Format (Serialization)

序列化描述了PDU（Protocol Data Unit）中数据被序列化的方式，PDU中的数据作为TCP/UDP消息的Payload，通过IP网络层传输。

4.1.1 Limitation

不支持SOME/IP消息的乱序段(segments)的重新排序。

4.1.2 Header

• Message ID (Service ID/Method ID) [32 Bits]

• Length [32 Bits] • Request ID (Client ID/Session ID) [32 Bits]

• Protocol Version [8Bits] • Interface Version [8 Bits] • Message Type [8 Bits] • Return Code [8 Bits]

[PRS_SOMEIP_00941] 在E2E的通信保护机制中，E2E的Header被放置在Reture Code（SOME/IP的Header的最后一个字节）后面，偏移长度是64bit，正好将E2E的Header放置在Return Code和Payload中间。

[PRS_SOMEIP_00031] 由于互操作性的原因（不同厂商的SOMEIP实现可以互相通信），不同厂商的SOME/IP协议栈的实现版本，其的Header的布局需要完全相同（按照上文的图示），Header中的字段的顺序是从上到下，从左到右。

4.1.2.1 Message ID [32 Bit]

[PRS_SOMEIP_00034] Message ID应当是一个32bit的标识符，用于标识：

• 标识SOME/IP应用中的一个方法 • 或者标识一个事件

Note: MessageID是由用户或者整个SOME/IP应用系统的设计者分配的，用来保证不同服务的不同方法/事件的MessageID是唯一的。

4.1.2.2 Method ID [16 Bit]

[PRS_SOMEIP_00245] MessageID字段应当是有16bit长度的ServiceID标识符（可以表示2的16次方个服务）和16bit长度的MethodID标识符组成（服务中最多可以有2的16次方的元素，包括方法和事件）。

Note: 一个通常的惯例和做法是将MethodID拆分为方法(Method)和事件(Event)/通知(Notifier)，其中方法(Method)的MethodID的范围是 0x0000 - 0x7FFF (16bit的首位是0)，而事件(Event)/通知(Notifier)的MethodID的范围是 0x8000 - 0x8FFF (16bit的首位是1) 。

Eventgroup是一个包含事件(event)和通知(notifier)的逻辑组，这些事件或者通知同属于一个SOME/IP Service，并且允许其他应用订阅。

[PRS_SOMEIP_00365] 一个SOME/IP事件组至少包含一个事件(event)。

[PRS_SOMEIP_00366] 一个事件(event)至少映射到一个SOME/IP事件组。

4.1.2.3 Length [32 Bit]

[PRS_SOMEIP_00042] 长度字段从长度字段后面的Request ID/Client ID开始到该SOME/IP消息结尾部分的长度。

4.1.2.4 Request ID [32 Bit]

Request ID让SOME/IP的服务端和客户端可以区分相同方法(method)，属性(field)的设置方法(setter)和获取方法(getter)的不同调用（对于同一个ServiceID/MethodID的不同次调用）。

[PRS_SOMEIP_00043] 对于SOME/IP的request-response 类型的方法(method)的不同次调用，每次调用的request和response报文中的Request ID字段需要不同。

[PRS_SOMEIP_00704] Response报文中的Request ID需要和对应需要回复的Request报文中的Request ID一致。

Note: Request ID的机制让客户端可以将服务端的响应(response)映射到本地发出多个方法(method)的某次请求(request)上，即使存在某些请求还没有收到服务端响应的情况。

[PRS_SOMEIP_00044] 对于SOME/IP 服务的客户端来说，对于服务端方法(method)调用的Request报文，在没有收到服务端对该Request报文的对应的Response报文之前，后面对相同服务端方法(method)调用的Request报文不能使用还没有收到Response的Reqeuest报文中的Request。

这样做是因为服务端还在处理之前的REQUEST，如果又收到同一个Request ID的Request报文，那么服务端就会困惑这次Response是应答客户端的哪一次Request了。

Request ID的结构：

Note:

一个ECU的实现方可以根据需求定义SOME/IP客户端的Client ID，而SOME/IP的服务端不需要关心和客户端的Client ID，它只需要在回复Response报文的时候拷贝完整的Request ID就可以了。

[PRS_SOMEIP_00702] Client ID是ECU中一个SOME/IP客户端的唯一标识符，ECU通过Client ID区分同一个SOME/IP 方法的不同调用方。

[PRS_SOMEIP_00703] Session ID是用于区分来自同一个SOME/IP客户端/服务端发送的连续的消息或者请求（服务端也会主动发送Event/Notifier）。

实际测试下来，对于Event/Notifier来说，因为是FF类型的通信，客户端不会有Response消息响应，因此对于一次事件变更/属性值变化，SOME/IP服务端进程发送出去的Notification(通知)报文，无论到达几个SOME/IP客户端，其Session ID是相同的，只有下一次发送该事件/属性的时候，Session ID才会递增+1。

[PRS_SOMEIP_00532] Client ID应当支持整车环境下的唯一性，可以通过配置ClientID前缀或者设置固定值的方式（例如，Client ID的最高位字节设置为诊断地址或者给特定应用程序/SWC配置的Client ID），例如：

[PRS_SOMEIP_00932] 在SOME/IP会话功能还未打开的时候，Session ID应该被设置为 0x00 (实际发送的SOMEIP报文中，是不存在Session ID等于0的报文的)。

[PRS_SOMEIP_00933] 在SOME/IP会话功能打开后，Session ID的范围在 0x01 - 0xFFFF 。

[PRS_SOMEIP_00934] 在SOME/IP会话功能打开后，Session ID应该在各自的应用场景内进行递增（关于应用场景的说明在formation about dedicat [PRS_SOMEIP_00533]和 (RS_SOMEIP_00027) 中)

[PRS_SOMEIP_00533] Request/Response方法应当使用Session ID来处理会话，Session ID应当在每次Request/Response调用对完成后递增（SOME/IP客户端发出Request报文，然后收到SOME/IP服务端响应的Response报文）。

[PRS_SOMEIP_00521] 当Session ID到达 0xFFFF后，需要从 0x01 重新开始。

[PRS_SOMEIP_00739] 对于Request/Response 类型的SOME/IP 方法，当客户端收到的Response报文中的Session ID和发送的Request报文中的Session ID不一致（例如找不到哪个Request报文中有该Session ID），那么客户端需要无视该Response报文。

[PRS_SOMEIP_00935] 对于SOME/IP Header中MessageType为Notificaiton消息来说，收到Notification消息的SOME/IP应用如果还没有打开会话功能，那么就应当无视收到的Notification消息。

[PRS_SOMEIP_00936] 对于SOME/IP Header中MessageType为Notificaiton消息来说，打开会话功能后的SOME/IP应用收到Notification消息后应当根据应用场景处理Session ID(具体的应用场景在[PRS_SOMEIP_00741])。

4.1.2.5 Protocol Version [8 Bit]

Protocol Version（协议版本号）可以确定SOME/IP消息Header部分的格式。

[PRS_SOMEIP_00052] Protocol Version应当是一个8bit的字段，包含了SOME/IP协议版本号。

[PRS_SOMEIP_00050] 当在SOME/IP Header中存在不兼容的修改时，Protocol Version应当递增，当使用旧协议版本(Protocol Version)来解析SOME/IP消息的应用去解析新版本的SOME/IP消息时，是无法正确解析，只能丢弃该消息。

Note:

SOME/IP消息处理和异常处理的行为在4.2.6.3章节定义。

Note:

Protocol Version是SOME/IP Header中的一个字段，因此其在Header中的位置是不能发生变化的。

Note:

SOME/IP payload部分格式的改动不会影响Protocol Version（只有SOME/IP Header部分的调整才会）。

[PRS_SOMEIP_00051] 当前Protocol Version的版本号值为 1。

4.1.2.6 Interface Version [8 Bit]

[PRS_SOMEIP_00053] Interface Version应当是一个8bit的字段，包含了SOME/IP Service中所包含接口的版本信息。

4.1.2.7 Message Type [8 Bit]

[PRS_SOMEIP_00055] Message Type字段值如下：

字段值	定义	描述
0x00	REQUEST	期待SOME/IP服务端返回RESONSE消息作为响应
0x01	REQUEST_NO_RESPONSE	SOME/IP客户端发送，属于Fire&Forget请求，不期待服务端返回RESPONSE
0x02	NOTIFICATION	SOME/IP服务端发送，带有通知(notification)/事件(event)数据的REQUEST请求，并且不期待客户端返回RESPONSE
0x80	RESPONSE	RESPONSE消息，由SOME/IP服务端发送
0x81	ERROR	带有错误信息的RESPONSE消息，由SOME/IP服务端发送
0x20	TP_REQUEST	TP类型的REQUEST消息，并且期待SOME/IP服