SOME/IP 学习笔记

背景

SOME/IP (Scalable service-Oriented MiddlewarE over IP) 是车载以太网通信引入的一个面向服务的概念，位于OSI 7层模型的层4之上， 基于IP（TCP/UDP）服务面向服务的中间件，面向服务的车载以太网通信协议。

2011年宝马公司开发设计了一套中间件，该中间件能够实现以服务为导向的通信方式，该中间件区别于传统以信号为导向的通信方式，不仅能够大大减少网络负载以提高通信双方的效率，同时引入以太网通信也能够大大满足未来车辆不断增长的通信需求。

面向信号的数据传输不管网络需不需要始终会不断循环发送，而面向服务的通信方式则不同，只有当网络中至少存在一个接收方需要这些数据时，发送方才会发送数据，这是一种面向服务通信方式的显著优点。

宝马将该面向服务的通信方式叫做SOME/IP(全称为：Scalable service-Oriented MiddlewarE over IP)。SOME/IP就是运行在车载以太网协议栈基础之上的中间件，或者也可以称为应用层软件。

SOME/IP正由于其知名度被AUTOSAR接纳并计划纳入其正式标准，并且在2014年集成进AUTOSAR 4.X中，几个关键发展节点如下：

1. AUTOSAR 4.0 - 完成宝马SOME/IP消息的初步集成；

2. AUTOSAR 4.1 - 支持SOME/IP-SD及其发布/订阅功能；

3. AUTOSAR 4.2 - 添加transformer用于序列化以及其他相关优化；

4. AUTOSAR 4.3 - 修复一些transformer bug同时添加针对大量UDP数据包的SOME/IP-TP协议以及其他SOME/IP-SD的优化工作；

5. 持续优化中。。。。。。

SOME/IP协议的具体解释：

Scalable

该协议设计的初衷之一就是为了实现不同硬件平台、不同操作系统或嵌入式固件以及不同应用软件的异构设备之间的可扩展性和互操作性。

service-Oriented

表明它是一种面向服务的基本协议。因此仅当客户端请求或服务器通知特定订阅者时，才在客户端-服务器配置中交换数据 ，这就确保了永远不会浪费带宽，并且仅在需要的时间和地点进行数据通信/交换。

MiddlewarE

它也是一种中间件。即其位于应用层，有自己的通用协议层来处理更具体的操作及应用；

over IP

它也是一个基于以太网的协议。 它使用类似的硬件接口，确保高达 100Mbps 的带宽。 同时数据通过中间件（即应用层）通过网络电缆使用 TCP/IP 或 UDP 协议进行通信。

当客户端需要来自服务器的数据时，它可由客户端使用 TCP 协议进行请求。 如果服务器必须将数据传送给所有活动的订阅者，则可通过 UDP 协议传输。 UDP 协议上的数据通信可以是单播、多播或广播。

如下图1所示，展示了SOME/IP在车载以太网协议栈中的位置以及与其他模块的关系：

在AUTOSAR协议栈中，SOME/IP协议的位置如下图所示：

SOME/IP协议内容按照AUTOSAR中的描述，我们可以更进一步的拆分为三类子协议：应用层的SOME/IP标准协议，SOME/IP-SD协议以及TP层的SOME/IP-TP协议，这三部分内容相辅相成，完整详细的阐述了SOME/IP协议的全部内容。

SOME/IP协议功能介绍

SOME/IP采用C/S的通信架构， Server是服务提供者，Client是服务消费者。根据服务接口类型，使用远程服务调用（RPC）机制，通过数据序列化和反序列化（Serialization/Deserialization）使得数据在网络上传输。通过SOME/IP的SD（Service Discovery）服务机制来实现服务的动态配置。

SOME/IP主要特点包括：

SOME/IP的服务元素分为：Event，Method，Field 三种类型。

Event： 一种单向的数据传输方式，由Sever向其订阅者发布服务事件；

Method：一种远程函数调用的通信方式；

Field：类似于Event和Method的结合体，允许Client获取，设置，订阅Server端事件的状态信息；通过Service Interface实现数据信息的传输与共享。

随着汽车通信总线及整车电子电气架构的不断发展，基于CAN总线的面向信号的通信模式已不能满足智能汽车的SOA架构的发展要求，SOME/IP协议是当前汽车通信实现SOA架构最核心的通信协议之一。

SOME/IP协议被广泛应用于车载以太网控制器中，尤其是智驾域，座舱域，车身域控等通信数据量大，对通信带宽要求高的控制器中。基于SOME/IP实现Signal to Service的转换，已经是域控制器中必不可少的技术。

SOME/IP消息结构

Header： 16个字节；

• Message ID [32 bit]：

Message ID 用于唯一标识服务的 Method 或 Event，可区分不同的服务。Message ID 对于整个车辆系统来说必须是唯一的 。

Message ID 的结构：

Message ID 前 16 位是 Service ID，每个服务需要有一个唯一的服务 ID，由系统集成商进行标识。后 16 位是 Method ID。

对于 Method ，Message ID 的结构如下：

其中 Method ID 的第一个位（bit）是 0。使用 16 位的 Service-ID 和从 0 位开始的16位的 Method-ID (对于实际值，Method-ID中还剩下15位)，这将允许最多 65536个服务，每个服务最多 32768 个方法。

对于 Events 和 Notifications ，Message ID 的结构如下：

对于 Events 来说，Method ID 的第一个位（bit）是 1。这意味着每个服务最多可以有32768 个事件或通知。

可以看出，MethodID 的最高位可用来判断具体的通信方式，即采用的是 Method 还是Event 。

• Length [32 bit]：

Length 字段长度为 32位，包含从 Request ID 开始到 SOME/IP 消息结束的长度，长度是以字节为单位的。注意，Length 不包括 Message ID 和 Length 。

• Request ID [32 bit]：

Request ID 是客户端的唯一标识符，要能在响应到达前或超时前不被重用。

在生成响应消息时，服务器必须将 Request ID 从请求中复制到响应消息中去，这才使得客户端可以将响应对应到发出的请求上。

Request ID 前 16 位是 Client ID，用来区分特定的客户端，在整车系统中该值必须唯一；后 16 位是 SessionID，用来标识同一客户端的多次请求。

SessionID 主要用于 Request&Response 类型的多次调用，每调用一次，SessionID 增加 1。

如果会话不在活动状态，SessionID 设置为 0x00，当会话处于活动状态时，SessioID 设置为 [0x1, 0xFFFF] 范围内的值。当 Session ID 为 0x00 时，服务器并不会对这个请求作出反应。

• Protocol Version [8 bit]：

该字段存放 SOME/IP 协议的版本号，用来识别使用的 SOME/IP 头格式（不包括 payload 的格式）。目前固定为 1。

• Interface Version [8 bit]：

该字段存放服务接口的版本号，用来识别服务接口的主版本号。

• Message Type [8 bit]：

Message Type 字段用于区分不同类型的消息，包含如下值：

当没有错误发生时，常规请求 (Message Type 0x00) 应由响应 (Message Type 0x80) 响应。如果发生错误，将响应包含错误的消息 (Message Type 0x81)。

Message Type 的第三高位(=0x20=0b00100000) 被称为TP-Flag，设置为 1 表示当前的SOME/IP 消息是一个 segment。

• Return Code [8 bit]：

Return Code 用来表示请求是否被成功处理。为了简化 header 布局，每个消息中都会传输 Return Code 字段。

 PRS_SOMEIP_00191 表：

• Payload [variable size]：

Payload 由 Event 的数据元素或 Method 的参数组成，大小取决于所使用的传输层协议，对于UDP，payload 介于 0 到 1400个字节之间，由于 TCP 支持 payload 分段，所以支持更大的长度。

注意：SOME/IP 所有的 Header 字段必须以网络字节顺序(大端字节序)编码。Payload 内参数的字节顺序应由配置来定义。

SOME/IP-SD协议介绍

SOME/IP-SD协议是SOME/IP协议的一种， 基于服务的通信需要Server/Client共同完成，在服务创建并且可用之后，Server和Client需要通过SOME/IP-SD动态创建两者之间的连接。Client在订阅服务之前，需要知道Server提供的服务列表；这个过程是通过“服务发现”来实现的。

SOME/IP-SD是服务的信息清单及管理机制，主要实现服务寻址及事件订阅两种功能。对服务进行寻址时，服务提供者（Server）通知Client某服务可用，并间接通知该服务的地址信息（Server端IP地址，端口号，协议），Client了解到某服务状态后，能够调用该服务的相关内容。

SOME/IP-SD主要有两个功能：

1） 应用之间传达自己的服务或获取对方的服务是否可用。

2） 向其他应用程序订阅服务。

 SOME/IP-SD消息结构

• SOME/IP-SD消息应以SOME/IP首部开始

• SOME/IP-SD消息的Service ID为0xFFFF

• SOME/IP-SD消息的Method ID为0x8100

• SOME/IP-SD消息中SOME/IP首部里的Length字段，表示从Length字段后的第一个字节开始，到SOME/IP-SD消息的最后一个字节结束的长度

• SOME/IP-SD消息的Client ID设置为0x0000，因为只存在一个单独的SOME/IP-SD实例

• 如果配置了Client ID前缀，它也同样适用于SOME/IP-SD

• SOME/IP-SD消息应具有Session ID并根据SOME/IP要求进行处理

• 每发送一条SOME/IP-SD消息，都要增加Session ID的值

• Session ID应该从1开始

• Session ID不能设置为0

• SOME/IP-SD的Session ID的处理是按照“通信关系”完成的，即广播和单播作为一个配对

• SOME/IP-SD的Protocol Version应该为0x01

• SOME/IP-SD的Interface Version应该为0x01

• SOME/IP-SD的Message Type应该为0x02（Notification）

• SOME/IP-SD的Return Code应该为0x00（E_OK）

下面是SOME/IP-SD的一个例子：

可以看出，报文中存在两组 Entry Array，一个 SD 报文可能包含多个 Entry，每个 Entry大小都是 16 个字节，一个 Entry 可能包含 0-2个 Option。

下面来看具体每项的含义：

MessageID：

对于 SD，ServiceID 固定为 0xFFFF ，MethodID 固定为 0x8100。

Request ID：

ClientID 一般固定为 0x0000。SessionID 初始为 0x0001，每发送一次数据后便加 1。

Protocol Version：

固定为 0x01。

Interface Version：

固定为 0x01。

Message type：

固定为 0x02 (Notification)。

ReturnCode：

固定为 0x00 (E_OK)。

Flags：

SOME/IP-SD 报头以一个 8位的 Flags 字段开始，它用于标识全局 Service Discovery 信息。Flags = 重启标志(Reboot Flag) + 单播标志(Unicast Flag) ，如下图所示：

 Unicast Flag 应设置为单播标志（即设置为 ‘1’），这意味着声明该 ECU 支持接收单播消息。

Flag 字段中的未定义位应静态设置为 ‘0’。

Reserved：

为空，当前不需要考虑；

Entries Array：

Entry 可以理解为“入口”，包含了服务实例以及需要订阅的事件组的信息，Entries Array 分为两类，针对服务的 Service Entry 和针对事件组的 Eventgroup Entry。

格式分别如下：

Service Entry：

Service Entry 用于服务发现。

Type：FindService (0x00)、OfferService (0x01)、StopOfferService (0x01)；

网络中未收到相关服务的 OfferService 或者暂未收到时，而客户端又需要访问该服务，那么客户端可以发出 FindService 去主动寻找服务，如果服务已经就绪，会回复 OfferService 报文；服务就绪后，会主动发出 OfferService，用以告知组播内其他节点，该服务已经启动，可以创建连接；当服务不可用时，会主动发送 StopOfferService 报文，用以告知组播内其他节点，该服务目前不可用，停止发送请求，并取消订阅。

Index First Option Run：Option Array 中第一个 Option 的索引；

Index Second Option Run：Option Array 中第二个 Option 的索引；

# of opt 1：第一个 Option 使用的选项数；

# of opt 2：第二个 Option 使用的选项数；

Service ID：表示该 Entry 所涉及的服务或服务实例的 Service ID；

Instance ID：表示该 Entry 涉及服务实例的 Instance ID，如果包含一个服务的所有服务实例，则设置为 0xFFFF；

Major Version：服务的主版本号；

TTL：Entry 的生命周期，单位为秒；

Minor Version：服务的次版本号。

Eventgroup Entry：用于事件订阅。

Type：SubscribeEventgroup（0x06）、StopSubscribeEventgroup（0x06）、 SubscribeEventgroupAck（0x07）、SubscribeEventgroupNack（0x07）；

当客户端收到服务 OfferService 之后，客户端可以发送 Subscribe 报文主动跟服务器订阅感兴趣的事件组；当客户端订阅某个事件组之后，如果后续发现不再需要该事件组的数据了，可以通过 StopSubscribe 报文来通知服务器，避免不必要的数据交互；当服务器收到客户端的 Subscribe 报文之后，需要先行判断是否符合可订阅的条件，如果该客户端满足事件组订阅条件，则返回 SubscribeAck ，告知客户端订阅成功，当事件组内的事件准备就绪之后，服务器会以某种约定好的形式发送相关事件给成功订阅的客户端，如果该客户端不符合事件组订阅条件，那服务器就会直接回复 SubscribeEventgroupNack，告知订阅失败。

Index First Option Run：Option Array 中第一个 Option 的索引；

Index Second Option Run：Option Array 中第二个 Option 的索引；

# of opt 1：第一个 Option 使用的选项数；

# of opt 2：第二个 Option 使用的选项数；

Service ID：表示该 Entry 所涉及的服务或服务实例的 Service ID；

Instance ID：表示该 Entry 涉及服务实例的 Instance ID，任何实例的 Instance ID 都不能设置为 0xFFFF（这一点和在 Service Entry 中的不同）；

Major Version：服务的主版本号；

TTL：Entry 的生命周期，单位为秒；

Reserved：应被设置为 0x000;

Counter：用于区分同一订阅者的订阅事件组。如果不使用，设置为0x0；

Eventgroup ID：事件组 ID。

Option Array：

主要存放 Entry 的附属选项信息，对于不同类型的消息，要配置的选项也不一样。

比如 Type=0x04 时，用于传输 IPv4 相关的参数，包括服务的 IP 地址、TCP 还是 UDP、端口号等：

 SOME/IP-SD通信过程

 SOME/IP-SD时序图

SOME/IP-TP协议

SOME/IP-TP模块的主体功能就是为了实现对应用层发送数据过大时进行的必要拆包与组包的工作，进而完成大量数据包的发送与接收。

SOME/IP作为一种应用层协议，即可以运行在TCP之上，也可以运行在UDP之上，由于TCP协议本身支持发送大量数据同时还支持流控等特点因此无需用到SOME/IP-TP,该协议仅针对运行在UDP协议基础上的SOME/IP协议。

该模块作为AUTOSAR中定义的标准模块，如下图所示，则较为清晰的表明了SOME/IP-TP在CP AUTOSAR的具体位置以及与其他模块的交互关系：

从图中可以直接看出SOME/IP-TP直接与PDUR层进行交互，当上层应用模块发送大量数据时，会通过PDUR发送数据给到SOME/IP-TP模块进行拆包，拆分的包按将照协议格式再通PPDUR模块依次发送。

对于接收方而言，则是接收来自PDUR的报文，通过SOME/IP-TP模块进行组包，组包后的结果给到PDUR，然后由PDUR再传输至上层应用模块。

SOME/IP-TP消息结构

SOME/IP-TP作为SOME/IP报文的一种，因此前面的SOME/IP Header则保持一致，只是SOME/IP-TP存在自身的协议头。如下图13为SOME/IP-TP层的协议头字段内容：

 其中Message Type更为细节地定义如下图14所示：

图14 Message Type 字段内容

当且仅当TP-Flag==1时，OffsetField，Reserved Field以及More Segement Flag才会存在；

当TP-Flag == 1时，表示当前SOME/IP报文为被分割的报文，即Segement报文；

1. Offset Field 表示当前已发送或者接收的数据量，其基本单位为16Byte，如该值等于92，表示截至目前为止已发送了92X16=1472字节长度的Payload。同时该长度并不包含SOME/IP header的长度。

2. Reserved Field为未来预留，目前默认为0即可；

3. More Segments Flag用来表示是否还有Segement报文，当其值为1时表示还有剩余的Segement，当其值为0时则表示没有剩余的Segement，当前Segement就是最后一条。

SOME/IP-TP通信过程

对于发送一个基于UDP完整的SOME/IP报文而言，报文的发送需要经历以下几个模块：

1. 应用层调用Rte_Send函数来实现数据SOME/IP序列化；

2. 通过LdCom模块间接调用SomeIpTp_Transmit来开启发送；

3. 通过循环调用SOME/IP-TP的主函数来遍历发送每一个Segement；

4. 同时发送出去的报文也会回复Txconfirmation中断最终传递至RteLdCom模块；

TX Path

具体发送流程中的函数调用关系如下图所示：

RX Path

针对被分割的segment，接收方需要通过下列几个步骤进行接收：

1. 通过SoAd模块来获取来自总线的SOME/IP数据；

2. PDUR模块接收到来自SoAd模块的数据后会触发SomeIpTp_Rxindicaion表明存在segement数据，准备开启接收；

3. SOME/IP-TP模块通过调用PDUR_SomeIpTpStartOfReception开启接收第一个Segement；

4. 剩余的Segment则可以通过不断触发PDUR_SomeIpTpCopyRxData来接收，最终传送至RTE层；

5. 当最后一个segment被接收到后，则通过调用函数PduR_SomeIpRxIndication来完成最终的接收并使得RTE反序列化给到应用层读取；

具体接收流程的函数调用关系如下图所示：

SOME/IP应用场景

• 场景一：汽车启动时

汽车启动是汽车系统设计中最复杂的任务之一。汽车中的每个 ECU 在启动时均有不同的行为。有些 ECU 启动速度快，有些则很慢。一些 ECU 即使在电压下降到 3.5V 的情况下，仍能正常启动，而可能对于一些 ECU 而言 8V 的启动电压都还不够。因此，汽车在启动时，各个功能就绪所需要花费的时间都不一样。如果不使用服务发现协议（ SD )，则需要规定一个确定所有功能就绪的时间点。这需要根据花费最长启动时间的功能或 ECU 来定义。如果使用 SD ，则每个功能/ECU 都可以在准备就绪时宣布其可用性，且通常可以提前提供用户功能。在启动过程中，SD 在交换式以太网网络中还具有另外一个优势：交换机可以直接通过 SD 消息建立地址表。

• 场景二：客户变更时

客户在购买汽车时，汽车厂商向客户提供了许多选择。作为一条经验法则，汽车越大，价格越高，可供选择的选件或功能就越多。大量的选择意味着汽车制造商根据特定客户的要求制造专属汽车。如果没有 SD ，每个 ECU 需要通过静态配置确定汽车中其他 ECU 功能的可用性。但是通过 SD , ECU 则可以自行建立车辆中可用的功能/ECU 列表，而不需要任何特定组合的预配置。这一方式显然更为可靠。因此，汽车越复杂，SD 的优势就越大。

• 场景三：事件传输失败时：

在仅支持 Fire&Forget 通信方式的网络中，发送方很难察觉接收方消息的接收是否成功，没有接收到任何消息的接收 ECU 始终认为没有事件发生、或者没有参数变更。那么，如果 SD 在后台工作的话， ECU 会立即掌握服务器/另一个 ECU 何时不再提供某种功能。这样，更容易发现通信故障，并且可以在特定的时间范围内激活相应的故障模式。

• 场景四：局部网络保证能源效率时：

随着车载网络规模的不断扩大和 ECU 数量的增加，能耗问题不容忽视。如果能够做到在特定时刻仅对使用的 ECU 进行100％供电那是最理想的。比如，客户已经抵达目的地且停放好车辆，但是希望通过内置的免提系统完成呼叫，那么汽车应该停用网络上不需要的其他 ECU ，包括发动机控制系统或传动系统等。这个例子表明，车载网络可能会动态变化。在变化的环境中，工作的 ECU 必须知道哪些功能仍然可用，哪些不可用。假如没有 SD ，也可以通过超时来实现上述目的。但是，在使用场景相同的情况下，使用超时方法的响应速度不如 SD 快。通过 SD 获取功能可用信息将更具有时效性。车载网络越复杂，就越能体现基于服务的通信方式和 SD 的优势。

参考资料

B_比较详细_详解SOME/IP-SD协议文档-翻译版