一文搞懂车载以太网之SOME/IP

前言

首先，请问大家几个小小问题，你清楚：

• 你知道什么是SOME/IP吗？

• 你知道为什么会产生SOME/IP即相关背景吗？

• 你知道SOME/IP与SOA又有着哪些千丝万缕的联系呢？

• SOME/IP在实践中到底应该如何使用呢？

今天，我们就来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：

---

正文

总体介绍

正如之前文章一文入门车载以太网，吐血整理! 不看可惜！中所介绍的那样，车载以太网协议栈总共可划分为五层，分别为物理层，数据链路层，网络层，传输层，应用层，其中今天所要介绍的内容SOME/IP就是一种应用层协议。

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

由于SOME/IP协议内容较多且关联复杂，为了让大家对SOME/IP有一个循序渐进的了解过程，限于篇幅本文将主要讲解应用层的SOME/IP标准协议，其他协议内容会在下篇继续给大家分享，敬请大家多多关注！

产生背景与动机

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

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

宝马将该面向服务的通信方式叫做SOME/IP(全称为：Scalable service-Oriented MiddlewarE over IP)。正如其名，可见该协议跟以太网密切相关。

没错！SOME/IP就是运行在车载以太网协议栈基础之上的中间件，或者也可以称为应用层软件。

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

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

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

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

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

• 持续优化中。。。。。。

什么是SOME/IP

正如上节所提到SOME/IP的全称，接下来我们就来通过其全称一起来了解下SOME/IP到底是个什么东西：

• Scalable

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

• service-Oriented

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

• MiddlewarE

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

• over IP

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

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

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

图1 SOME/IP 与车载以太网协议栈关系

那么在AUTOSAR协议栈中，SOME/IP协议又处于一个什么样的位置呢？如下图所示：

如上图可知，SOME/IP协议涉及到与RTE，COM，PDUR以及SOAd这些AUTOSAR标准模块的交互，而用于服务发现的SOME/IP-SD则涉及到BswM，SD以及SoAd模块的交互。

SOME/IP协议与各个模块的交互关系会在后续文章讲到，提及于此让大家对SOME/IP协议与AUTOSAR协议栈的关联有个整体概念，此文中不做过多展开。

SOME/IP 最初是作为另一种 RPC 机制开发的，以确保与 AUTOSAR 设备的兼容性并提供汽车用例所需的最大功能，同时它也是专为ECU间客户端-服务器序列化而设计的网络层协议。

目前，该协议可以在多种不同的操作系统上实现，包括 AUTOSAR、OSEK 和 GENIVI。它也可以在不运行操作系统的嵌入式固件上实现。

摄像头、主机、远程信息处理设备、AUTOSAR 设备，甚至信息娱乐系统等大型设备，都可以使用 SOME/IP 协议有效地交换 ECU 间消息。自 Wireshark 3.2 SOME/IP 发布以来，SOME/IP 支持就已公开，可以在 Wireshark 上解析SOME/IP数据。

综上所述，我们便可以总结出SOME/IP作为一种面向服务的通信协议，一种基于车载以太网协议栈基础上的应用层协议的基本特点有哪些，如下表1所示展现了SOME/IP协议的五大基本特点：

表1 SOME/IP协议五大基本特点

SOME/IP与SOA的关系

SOA

SOA简而言之就是一种面向服务的架构(Service-Oriented Architecture), 当然也是一种软件设计的重要方式，IT研究与顾问咨询公司 Gartner 在 1996 年提出的，其本身并不是新鲜概念，而且已经在IT互联网领域风靡了20余年。

按照W3C对它的定义 : “SOA是一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。

服务： 服务是一种比构件粒度更大的信息集合，实际是包含实现了多个关联业务需求的逻辑组合，并且允许每个服务使用特定的平台，架构或技术方案；

可调用接口： 面向服务的接口不同于构件的接口，他的实现与特定语言无关，与特定的平台也无关，可十分方便的实现不同异构平台的交互；

联系与区别：

• 首先需要明确的是SOME/IP不是SOA，SOA也不是SOME/IP；

• 由于SOME/IP本身也是一种面向服务的协议，所以一般认为SOME/IP只不过是一种实现SOA可行的协议选择；

• 一般而言，基于消息的通信与RPC(Remote Procedure Call 远程过程调用)通信都可以实现SOA，而SOME/IP就是一种基于RPC框架的协议；

• 可以通过SOME/IP用来实现SOA，但SOA的实现却不一定非得用SOME/IP;

SOME/IP协议解析

接下来就让小T带领大家通过解析SOME/IP一起来揭开SOME/IP的神秘面纱！，以便为后续车载以太网的学习打好基础。

相关标识符与版本说明

如下图2所示为SOME/IP协议的Header结构体：

图2 SOME/IP协议Header

如上图中标记的Message ID，Request ID, Protocal Version 以及Interface Version的详细解释如下表2所示：

表2 相关标识符与版本说明

Length

Length正如上图2所示，其涵盖的范围是Request ID开始至SOME/IP报文结束。

Message Type

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

图3 Message Type表

Return Code

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

图4 Return Code定义表

SOME/IP通信机制

认识完了SOME/IP协议标准的详细定义内容之后，接下来就需要来探讨车载ECU需要按照何种规则来实现数据的传输，因此熟悉这部分内容将对车载以太网SOME/IP的开发与测试至关重要。

服务发现(Service Discovery)

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

在通过SOME/IP协议传输数据之前，我们需要知道当前整个车载网络到底存在哪些服务，服务的可用性如何，客户端如果订阅服务端所提供的服务。

由于SOME/IP-SD协议也是一块十分重要的内容，在此就不过多展开，仅简要介绍其基本功能与作用机理，后续会单独介绍SOME/IP-SD协议的具体内容，敬请关注！

如下图5所示即为SOME/IP-SD的基本功能，展现了Client与Server之间的交互关系。

图5 SOME/IP-SD Client与Server交互关系图

由上图可知，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中的一种；其基本通信模型如下图6所示：

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

图6 Request-Response通信模型

• Fire&Forget通信模式，可归纳为Method中的一种；

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

  

  
  

图7 Fire&Forget通信模型

• Notification Event通信模式；

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

图8 Notification event通信模型

• 远程进程控制(Field)

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

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

  

  
  

  图9 Field的通信模型

由上图可知，在Getter与Setter的方式中我们使用的Request/Response机制。在Getter的请求报文中是一个空的Payload，响应报文中的Payload才是需要获取的值；使用Setter请求时，请求消息中的Payload则是要设置的值，如果设置成功，那么响应报文中Payload就是设定成功的值。

同时我们也可得出服务实体在SOME/IP协议中是一个十分重要的概念。一个服务实体可以是Field，Events以及Method的任意组合。

SOME/IP错误处理机制

在任何通信过程中总是会存在各种各样的 错误，SOME/IP作为一种面向服务的应用协议也不例外，因此AUTOSAR为了更为高效的定位到通讯过程中的问题所在，因此制定了一套检查SOME/IP协议格式内容的错误处理机制。

比如版本信息检查，服务ID等，其他故障信息可以在Payload中进行详细定义。目前SOME/IP支持以下两种错误处理机制，这两种uowu处理机制可以根据配置进行选择。

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

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

如下图10为SOME/IP处理一般性错误的基本流程：

图10 SOME/IP错误处理流程

SOME/IP-SD协议解析

SOME/IP-SD协议头

首先，依照惯例我们先来看下SOME/IP-SD的报文格式如下图11所示：

图11 SOME/IP-SD Message Format

一般而言，如果没有特别要求，在SD报文格式中的内容均按照大端方式传输。

由于SOME/IP-SD报文实际上也只是SOME/IP报文的一种，只不过是在SOME/IP标准协议的基础上扩展了Entry，Option等字段，其中Entry用于同步服务实例的状态以及发布/订阅关系的管理，Options则用于传输Entry的附加信息。

接下来，我们将针对上述的协议中各种字段为大家一一解释如下表1：

表1 SOME/IP-SD 协议内字段解释

Entry Array

如上表1中所述，Entry Array按照SD的定义可分为以下两种：

• Service Type：用于FindService，OfferService，StopOfferService这几种场景；

• EventGroup Type： 用于 SubscribeEventgroup， StopSubscribeEventgroup，SubscribeEventgroupAck，SubscribeEventgroupNack这几类场景。

如下图12所示，首先我们介绍下为Service Entry Array中定义的各个字段内容：

图12 Service Entry Array定义

对上述Service Entry Array定义的各个Field解释说明如下表2所示：

表2 Service Entry Array字段解释说明

介绍完Service Entry Array，相比之下EventGroup Entry Array又存在哪些差异呢？

如下图13为EventGroup Entry Array的各个字段内容的定义：

图13 EventGroup Entry Array定义

相比Service Entry Array，EventGroup Entry少了Minor Version，但是多出了Counter以及EventGroup ID内容，接下来我们将对上述EventGroup Entry Array定义的各个Field解释说明如下表3所示：

表3 EventGroup Entry Array字段解释说明

Option Array

Option Array作为SOME/IP-SD报文最后的部分，其主要作用就是为了提供在通信的过程中提供下附加信息，如配置信息，IP地址，端口号等。不过其作为SD报文的一部分也存在着自身的字段内容。

AUTOSAR将Option Array主要分为以下三种：

• Configuration Options：用于配置通信过程的必要的信息

• Endpoint Options(IPV4/IPV6):用于传递IPV4或者IPV6的Endpoint信息(IP地址 Port号)以及使用的传输层协议；

• Multicast Options(IPV4/IPV6):用于广播IPV4或者IPV6的IP地址及Port号，其中传输层协议只能使用UDP协议；

Configuration Options

接下来我们来对这三种Option进行一一解读。首先来看看Configuration Option的字段定义：

图14 Configuration Option 字段定义

注意：configuration options仅适用于任意Service ID的Service Entry Array以及Service ID为0xFFFE的EventGroup Entry Array。

针对上述字段解释如下表4所示：

表4 Configuration Option Array 字段解释说明

对于那些非标准的SOME/IP 服务，由于不能够被Service ID进行标识，此时就需要通过一个key “otherserv”的值来进行标识，这类服务则可通过使用0xFFFE作为Service ID同时附带otherserv的value的configuration option来完成双方的通信。

IPV4 Endpoint Option

如下图15为IPV4 Endpoint Option的字段定义：

图15 IPV4 Endpoint Option字段定义

IPV6 Endpoint Option

如下图16为IPV6 Endpoint Option的字段定义：

图16 IPV6 Endpoint Option字段定义

IPv4 Multicast Option

如下图17为IPv4的Multicast Option各字段内容定义：

图17 IPv4 Multicast Option

IPv6 Multicast Option

如下图18为IPv6的Multicast Option各字段内容定义：

图18 IPv6 Multicast Option定义

IPv4 SD Endpoint Option

如下图19为IPv4 SD Endpoint Option的字段定义：

图19 IPv4 SD Endpoint Option定义

IPv6 SD Endpoint Option

如下图20为IPv6 SD Endpoint Option的字段定义：

图20 IPv6 SD Endpoint Option定义

由于上述六种IPV4与IPV6字段内容大体结构一致，因此我们将该两者放在一起来对各字段内容进行解释说明：

表5 IPv4/IPv6 六类Option字段解释说明

SD 状态机

SD状态机状态机这部分由于涉及的内容细节较多且较为独立，同时限于篇幅有限，后期会专门针对SD状态机，SD报文接收发送等环节给大家单独分享，敬请期待SOME/IP-SD状态机专题篇！

SOME/IP-TP主体功能

我们知道CAN-TP是用来对当总线CAN数据过大时，就需要对CAN整包数据进行分割拆包进行发送，这个时候发送方的TP层就起作用，同理对于接收方而言，也需要将分割的数据包进行组包完成整包数据的重组还原。

因此，举一反三，我们便可以知道SOME/IP-TP模块的主体功能就是为了实现对应用层发送数据过大时进行的必要拆包与组包的工作，进而完成大量数据包的发送与接收。

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

该模块作为AUTOSAR中定义的标准模块，在AUTOSAR中与各个模块的交互关系又是如何的呢？

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

图21 SOME/IP-TP在AUTOSAR的位置及交互关系

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

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

SOME/IP-TP协议解析

了解了SOME/IP-TP的主体功能以及大概的工作过程，接下来我们一起解析下SOME/IP-TP协议。

SOME/IP-TP作为SOME/IP报文的一种，因此前面的SOME/IP Header则保持一致，只是SOME/IP-TP存在自身的协议头，让我们一起来学习一下。

SOME/IP-TP协议头

如下图22为SOME/IP-TP层的协议头字段内容：

图22 SOME/IP-TP 协议头字段内容

针对上图中每个字段内容地详细解释请参考上篇链接《一网打尽车载以太网之SOME/IP(上)》

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

图23 Message Type 字段内容

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

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

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

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

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

Tx Path

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

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

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

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

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

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

图24 Tx Path函数调用关系图

Rx Path

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

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

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

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

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

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

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

图25 Rx Path函数调用关系图

------------- END --------------