SOME/IP 详解系列（1）—— 概述

前言

随着车载以太网技术的快速发展，SOME/IP得到了更多在车内网络应用的机会，同时作为SOA架构的重要支撑，也越来越受到人们的关注。但还是有很多人并不是真正的了解SOME/IP，接下来的几篇文章，王师傅打算详细的介绍下SOME/IP的背景、定义、工作机制和应用场景，以及如何通过工具去进行SOME/IP的仿真和验证。

SOME/IP背景介绍

SOME/IP的全称是Scalable service-Oriented MiddlewarE over IP，为基于IP的可扩展的面向服务的中间件，由宝马的Lars Völker博士在2011年设计并提出。SOME/IP是车载网络的通信中间件，位于应用程序和传输层之间，可以为控制器提供一种面向服务的通信方式，适配多种操作系统（如FreeRTOS、RTA-OS、QNX、Linux、Android等），甚至在没有操作系统的嵌入式设备上也可以使用。

Lars Völker博士已于2019年从宝马离职，并加入了一家名为Technica Engineering的德国公司，上图标是这家公司的logo，相信很多对车载以太网测试有些了解的朋友都见过，我们平常测试车载以太网需要用的转换板、交换机和数据监听设备、甚至TC8测试需要用的Golden Device，很多设备都是出自这家公司。

面向服务的方式可以使网络上的控制器更灵活的通信，采用服务器/客户端的模式，提供服务的一方为服务器（Server），使用服务的一方为客户端（Client）。为了实现服务器和客户端之间数据格式的解析，服务的定位和寻找，以及数据的适时发送和高效传输等功能场景，所以需要一种位于传输层之上的通信中间件，简单地说就是需要一种双方都可以读懂的语言，定位双方位置、获取双方状态的方法，以及数据发送和交互的规则。这也是SOME/IP被设计出来的主要原因。

SOME/IP主要功能

SOME/IP主要有以下几个功能

1. 序列化 Serialization

SOME/IP协议对序列化的解释为数据在PDU（Protocol Data Units，协议数据单元）中的表示方式，展开来说就是将不同的数据结构转换为可在网络上传输的形式，或者说是数据在网络上传输时的封装和排列规则。发送端将数据以一定的规则进行序列化，接收端将数据以同样的规则进行反序列化，从而得到发送端所发送的实际内容。这部分定义既包含报文头部也包含载荷数据，不仅定义了头部的格式、各字段的长度及含义，还定义了各种数据类型在有效载荷中的排列规则。发送端和接收端通过这样的规则就能获取数据报头的含义及载荷的内容（具体的报文格式会在接下来的文章中详细介绍，本文仅介绍SOME/IP的基本功能）。下图为SOME/IP支持的基础数据类型和复杂数据类型。

2. 远程过程调用 Remote Procedure Call

远程过程调用，一般用英文缩写RPC表示，听起来又是个比较晦涩的名词，和其对应的是本地过程调用（LPC，Local Procedure Call）。简单的说如果需要和其他的控制器或节点进行交互，那么就需要RPC。通过RPC来请求其他节点上的服务或数据，基于Request/Response的模式来实现（左下图示）客户端发送请求，服务器接受请求并处理，然后返回结果给客户端。在SOME/IP中，除了这种同步调用的方式，还支持异步调用的Fire&Forget（右下图示），客户端发送请求后，无需等待服务器处理请求，可以继续执行其他操作，同时服务器也无需返回处理结果（request-no-return）。相较于Request/Response，Fire&Forget方式对系统性能和资源的要求更低。

3. 服务发现 SOME/IP SD (Service Discovery)

SOME/IP SD可以认为是SOME/IP协议的核心，提供了一种可以动态的发现和获取服务状态的机制。所谓面向服务的通信，首先需要获取网络中都有什么服务，并且需要知道服务的状态和提供方，然后才可以去使用和消费这个服务。通过SOME/IP SD，可以将自身能提供的服务以及服务的状态告诉网络中的其他节点，同时，当想要主动寻找某个服务的时候，也可以通过SOME/IP SD去实现。

4. 发布/订阅 Publish/Subscribe

发布和订阅也是由SOME/IP SD实现的，上文中提到了，SOME/IP可以实现只在需要的时候才进行数据的发送，这主要归功于发布/订阅的机制。客户端在发现想要使用的服务后，会对服务进行订阅，当满足服务的触发条件时，服务器就会将客户端所需的服务内容发出。发送的方式是单向的事件型通知，对于客户端来说，只需要订阅一次即可。这同样是一个动态的过程，当客户端不需要使用服务的时候，也可以停止订阅该服务。

以王师傅的公众号“汽车以太网”为例，假设王师傅每月15日会准时发布一篇文章，如果你订阅了这个公众号，那么在每个月的15日，你就会收到这篇文章。这和SOME/IP发布/订阅的机制是一样的，只不过在SOME/IP里，订阅的内容从公众号变成了控制器所能提供的服务。

5. SOME/IP-TP 传输协议 Transport Protocol

SOME/IP-TP是SOME/IP在数据传输层面定义的规则，主要用于解决数据有可能被分片的问题。在网络层，数据都是通过IP协议传输的，由于链路MTU的限制，导致可能会出现IP分片。由于IP分片存在诸多的问题（这里就不展开讲了，有兴趣的朋友可以自己查查），为了防止IP出现分片的情况，所以设计了SOME/IP-TP，可以简单理解成TP是SOME/IP自己的分片传输机制。

SOME/IP标准文档

想了解SOME/IP，我们应该去看哪些标准呢？目前有三个组织发布过SOME/IP相关的内容，分别是COVESA、ISO和AUTOSAR。

> COVESA

vSOMEIP，是由GOVESA联盟（Connected Vehicle Systems Alliance，之前的名字为GENIVI）编制的一版SOME/IP协议栈，主要由宝马在维护。这套SOME/IP协议栈是开源的，在GitHub上可以免费下载，网址为https://github.com/COVESA/vsomeip。网页上注明了版权归属宝马，原文为vsomeip Copyright© 2015-2022, Bayerische Motoren Werke Aktiengesellschaft。

【扩展小知识】 Bayerische Motoren Werke是宝马的德文全称，直译过来大概意思是巴伐利亚州发动机厂，并没有很高大上，简称为BMW。

> ISO

ISO也同样制定过一份SOME/IP相关标准ISO 17215-2:2014 Road vehicles — Video communication interface for cameras (VCIC) — Part 2: Service discovery and control其中定义了SOME/IP和SOME/IP SD相关的需求，以及一套如何通过SOME/IP实现摄像头服务的方法。

> AUTOSAR

以上两个组织发布的内容仅作参考即可，现在想了解SOME/IP，主要还是看AUTOSAR的标准。SOME/IP从2013年开始被纳入AUTOSAR，相关的标准分为三类，CP（Classic Platform），AP（Adaptive Platform）和FO（Foundation），所涉及的标准文档见下图（R22-11版）

因为文档的名字比较类似，容易混淆，所以通常用文档ID来表示是哪一份标准，另外文档ID也是这份文档PDF文件的名字，在电脑里会更容易查找。这三类SOME/IP的文档的内容如下：

SWS（SoftWare Specification）
软件需求，内容包括AP和CP平台SOME/IP软件模块的设计和实现原理、API接口、功能函数、数据类型及配置参数等内容，主要供软件开发人员参考使用

PRS（Protocol Requirement Specification）
协议需求，主要定义SOME/IP协议的具体机制，如报文格式、序列化方法、传输方式、RPC交互机制、错误处理等内容。所以如果想了解SOME/IP在通信层面如何工作，可以主要阅读这两份PRS的标准，即上图中绿色背景颜色的两份

RS（Requirement Specification）
需求，RS的标准主要定义SOME/IP应提供和支持哪些机制，如需实现基于服务的通信、需支持双向的PRC通信和事件类型的通信、需支持哪些数据类型等基础内容，可以理解为RS是SOME/IP协议制定的参考依据或需求。这类文档对学习SOME/IP协议如何工作帮助不大，简单了解即可

SWS通常属于AP和CP的标准，PRS和RS则属于FO的标准，FO的标准是独立于实现平台的，AP和CP均可遵循FO的标准来实现相关协议。以上这些标准均可在AUTOSAR官网直接下载https://www.autosar.org/。

今天就先介绍这么多，希望通过这篇文章能帮助大家对SOME/IP有个初步的了解。下一篇，王师傅将会介绍SOME/IP的报文格式、传输协议和具体的交互机制。

欢迎关注王师傅的微信公众号“汽车以太网”