来源：车载以太网小L

SOME/IP到底讲什么

01

SOME/IP

2011年，BWM设计和提出了SOME/IP，SOME/IP全称为Scalable service-Oriented MiddlewarE over IP，拆分起来理解就是以Server-Client服务形式进行通信，并且服务具备高度可扩展性，同时作为应用层协议运行于车载以太网四层以上，作为以太网通信中间件来实现应用层和IP层的数据交互，使其不依赖于操作系统，又能兼容AUTOSAR和非AUTOSAR平台，因此SOME/IP可以独立于硬件平台，操作系统和编程语言。

众所周知，在传统以太网中，OSI将以太网分层七层，但是汽车行业，只有5层，将OSI 5-7层统称为应用层，其中SOME/IP协议是一种应用层协议，运行在TCP/UDP传输协议之上。从图中可知，SOME/IP还有一个控制协议，称为SOME/IP-SD，用于服务发现，跟SOME/IP各司其职。

讲了SOME/IP所在层级，再来介绍下，SOME/IP报文的封装风格。不管是SOME/IP还是SOME/IP-SD报文，统一作为TCP/UDP Payload进行封装，四层以下封装格式遵循以太网本身的封装风格。

02

整车软件平台

目前整车电子电器软件平台如图所示，分为Classic AUTOSAR Platform(简称CP)，Adaptive AUTOSAR Platform(简称AP)和非AUTOSAR Platform。这三者是共同运行在整车电子电器架构之上，不存在谁取代谁，尤其是AP并不会取代CP和非AUTOSAR，相反AP可以很好的和其他平台交互，以丰富整车应用。

CP，AP和非AUTOSAR平台之间的通信交互主要由SOME/IP实现，借助SOME/IP协议的高度平台扩展性，实现不同平台的数据交互，因此统一的SOME/IP通信机制是不同平台通信的前提。

BWM设计SOME/IP协议之后，通过CP规范发布公开从而被广泛用于车载以太网，所以说SOME/IP起源于CP也不为过：

AUTOSAR 4.0：支持初步的SOME/IP报文AUTOSAR 4.1：增加SOME/IP-SD控制机制和发布-订阅机制AUTOSAR 4.2：增加序列化机制AUTOSAR 4.3：修复序列化机制的bug，同时增加大数据包基于UDP报文分片机制，此时的SOME/IP已经是完善的版本

为了在不同软件平台上运行SOME/IP，使得整车以太网上实现SOA架构通信机制，所以AP规范中也同步引入了SOME/IP，因此对于AUTOSAR系统，CP和AP之间实现SOME/IP通信，是比较容易的。

非AUTOSAR软件平台为了和车内CP和AP ECU更好的交互，GENIVI系统同样也开发了一套开源vSOME/IP软件源码，以便和CP/AP交互，但vSOME/IP是开源的，所以性能会差一些，因此需要统一的规范来做约束，从而做一些深层次的二次开发，我们基于AUTOSAR SOME/IP规范指定出自己的企业规范，以限制不同平台SOME/IP的通信行为。

03

SOME/IP特性

1.序列化和反序列化

将结构化的数据按照一定规则进行排序，将排完序的对象以一定形式封装到SOME/IP报文Payload中，发送给网络中。接收端收到后，通过反序列化将SOME/IP Payload按一样的排序规则重新组合成结构化数据，可以理解为将并行的结构化数据序列化成串行数据，通过以太网发送到网络中。

如图结构体中张三的个人信息按照特定规则进行编码，之后以二进制数据串形式通过以太网传输到对端，接收端收收到后反序列化出张三的个人信息。

CAN没有结构化数据这种概念，但为了实现一组功能相关信号打包在一起，从而引入信号组的概念，信号组就是人为的将CAN信号重组成结构体的一种做法。SOME/IP自身有序列化和反序列化的机制，因此SOME/IP通信行为中是绝对不会存在信号组的，所以如果你在设计CP Arxml后出现信号组的属性，那么这个Arxml就不在是SOME/IP，而是类CAN的一种基于信号的以太网通信。

2. 服务发现

服务发现称为Service Discovery，简称SOME/IP-SD，在服务创建并且可用之后，Server和Client需要通过SOME/IP-SD动态的创建两者连接，SOME/IP-SD报文主要：

OfferService：Server服务就绪后，满足服务发布条件后，主动发出OfferService，用以告知组播内其他节点，该服务已经启动，可以创建服务连接。FindService：当网络中未收到相关服务的OfferService或者暂时未收到，而且Client又需要该访问该服务，那Client可以使用FindService去主动寻找服务，如果Server服务Ready的话，会回复响应的OfferService报文。StopOfferService：Server端发现服务不可用，不满足提供服务条件时，会主动发送StopOfferService报文，用以告知组播内其他节点，该服务已不可用，取消服务请求和订阅。Subscribe：事件组的交互机制采用订阅-发布形式，当收到服务OfferService之后，Client通过Subscribe报文主动跟Server订阅相关事件组。SubscribeACK/SubscribeNACK：当Server收到Client的订阅报文之后，需要先行判断是否符合可订阅的条件，如果该Client满足事件组订阅条件，则返回SubscribeACK，告知Client订阅成功，当事件组内的事件准备就绪之后，Server会以某种约定好的形式发送相关事件给成功订阅的Client，如果该Client不符合事件组订阅条件，那Server就会直接回复SubscribeNACK，告知订阅不成功。StopSubscribe：当Client订阅某个事件组之后，发现后续并不在需要改事件组的数据了，则通过StopSubscribe报文来通知Server，以断开两者事件组的交互。

下面结合下图详细说明，服务可用之后，Server通过SD OfferService组播报文告诉client，该服务已经可用，Client收到offerService报文之后，首先启动了事件组订阅流程，先发送Subscribe报文给Server，Server验证相关权限之后，发送订阅成功SubscribeACK给Client，之后，当Server该事件组的事件准备就绪之后，会主动发送Event给Client。同时Client在OfferService有效期内，随时都可以发送服务请求Request，跟Server进行相关数据的交互。

4.服务接口

服务发现章节讲了服务发现相关报文的交互机制，那大家对SOME/IP控制报文有了一定的了解，同时对服务双方如何建立连接有一定的认识，接下来我们来讲下服务数据交互。

所有的服务数据交互所采用的报文我们统称为服务接口，服务接口主要分为两大类：

Method：一种远程过程调用，采用Request-Response机制进行通信，由Client发送远程过程调用请求Request，用于请求相关数据或者请求执行相关操作，Server收到Request，根据内容做一些操作之后，通过Response对Client的Request做出一些反馈。Method是一种可靠传输的服务接口，需要关系Request是否被送达。Event：订阅-发布机制是控制事件组的交互，之后事件组是以单个Event报文进行就交互，从而向Client发送相关数据。Event是一种单向传输，无法保证数据是否被准确送达。

针对以上两类服务接口，SOME/IP进行了服务接口扩展，从而还有了Fire&Forget报文和Field：

Fire&Forget：一种特殊的Method，但和Method又有本质的区别，因为Fire&Forget只有Request，没有Response报文，主要有两种作用，一种是作为某些Trigger触发Server做相应操作，一种是充当Client的Event，向Server发送相关数据Field：Field关联三种服务接口，以组合的形式来呈现，三者对同一个数据做相关联的操作。Getter：Client主动获取相关操作的当前数据，该服务接口Request不携带任何数据Setter：Client主动设置相关操作的数据，同时Server要将Client设置的数据通过Response反馈给Client，以便Client确认设置的数据是否成功。Notification：通信行为和Event极为类似，也遵循订阅-发布机制，以事件组的形式来订阅，但所发布的数据和Getter/Setter是同一套。

以上是我对SOME/IP的一些见解，因为篇幅有限，并不能完整的讲述SOME/IP的内容，比如SOME/IP报文格式，Server和Client服务启动流程等等也都是比较重要的内容，如果大家感兴趣，可以自己看看AUTOSAR SOME/IP相关规范，就会有比较深入的了解。规范列表如下：

《AUTOSAR_SWS_ServiceDiscovery.pdf》《AUTOSAR_SWS_SOMEIPTransformer.pdf》