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.2SOME/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协议栈内容具体如何实现，可以参考由BMW公司主导在GitHub上的开源代码，在GitHub中搜索"vsomeip"关键字便可找到对应的开源代码学习。 值得注意的是vsomeip是一种基于Linux平台采用C++语言进行开发的SOME/IP协议栈。

审核编辑：彭静