上海建网站服务器/郑州网络推广服务

1.SOME/IP 是中间件吗?

SOME/IP 不是广义上的中间件，严格的来讲它是一种通信协议，但中间件这个概念太模糊了，所以我们也一般称 SOME/IP 为通信中间件。

SOME/IP 全称是 Scalable service-Oriented MiddlewarE over IP。也就是基于 IP 协议的面向服务的可扩展性通信中间件协议。

所以，要弄清 SOME/IP 需要从它的名字出发，要搞清楚它的 3 个要素：

• 面向服务 SOA
• 基于 IP 协议之上的通信协议
• 中间件

我们带着这 3 个疑问走下去。

2. SOME/IP 能干嘛？

既然是通信中间件，那么做的就是通信相关的事情。

SOME/IP 能干的事情有 3 类：

• 服务发现 (Service Discovery)
• 远程服务调用 （RPC,remote producer call）
• 读写进程信息 （Getter & Setter）

3. SOME/IP 与 CAN 的不同？

CAN 是传统的汽车软件通信协议，CAN FD 是其扩展，它们与 SOME/IP 的主要区别如下：

协议	通信负荷	通信速度	通信方式
CAN	8 Byte	512 Kbps ~ 1 Mbps	基于信号
CAN FD	64 Byte	2Mbps ~ 8 Mbps	基于信号
SOME/IP	~1500 Byte	1000 Mbps	面向服务

CAN 协议是汽车软件开发最重要的通信协议，但随着汽车智能化程度越来越高，CAN 通信遇到的瓶颈越来越大，表现在 2 个维度:

通信速度

CAN 一般是 512kb/s，CAN FD 能到 1MB/s，而基于 SOME/IP 的以太网能到

通信负荷

CAN 是 8Byte，CAN FD 能到 64Byte,而 SOME/IP 能到 1500 Byte

4. SOME/IP 和车载以太网、IP有什么关系？

前面小节讲到 CAN 是基于信号在双绞线中传输信号，而 SOME/IP 是面向服务在车载以太网中传输信号。
而 SOME/IP 中的 IP 是 Over IP ，也就是在 IP 协议层之上的意思。

我们能熟知的 TCP/IP、UDP 都是传统网络协议，网络协议是分层的，车载以太网网络协议也是一样的。

SOME/IP 和 DoIP、XCP 一样位于协议栈的应用层，并且它是基于 TCP/UDP 协议之上的应用。

4. SOME/IP 和 Autosar、SOA 的关系？

SOME/IP 最初由宝马公司设计，2013 年被收录到 Autosar 4.1 规范。
AP Autosar 同样支持 SOME/IP 协议。
并且，未来一辆汽车中可能同时存在基于 AP Autosar 的 ECU 和基于 CP Autosar 的 ECU，它们之间存在 Signal2Service 操作，通过车载以太网中的 SOME/IP 之类的协议通信。

那 SOME/IP 和 SOA 有什么关系呢？

AP Autosar 是基于 SOA 理念设计的软件框架，而 SOME/IP 作为其通信协议，可以实现 Service 的 Publishe/Subscribe 通信，所以在汽车领域一般讲 SOA 不能不提到 AP Autosar，而讲到 SOME/IP 时，SOA 也会常被提起。

5. SOME/IP 的形态？

具体到汽车软件开发，SOME/IP 有两种形态：

• 集成到 Autosar 中的 Module
• 集成到 Posix 系统中的独立的 Lib
  
  需要注意 GENIVI 这个组织，它针对 SOME/IP 标准实现了开源 vsomeip 方案，vsomeip 能够独立集中到操作系统中。

6. SOME/IP 的消息格式?

SOME/IP 协议一般指代具体 SOME/IP、SOME/IP-SD、SOME/IP-TP 3 种。

SOME/IP 消息结构

一个完整的 SOME/IP 消息，包含以下内容：

• Message ID 代表 Sevice ID 或者 Method ID
• Length 消息长度，从 Request ID 算起到
• Request ID
• Protocal Version 协议版本号
• Interface Version 接口版本号
• Message Type 消息类型
• Return Code 返回编码
• Payload 数据负载

然后，这里面有许多细节。

Message ID

可以指代一个远程调用 RPC 的 Method 或者是一个服务的 Event。

当 Message ID 代表 Method ID 时

当 Message ID 代表 Event ID 时

Method ID 和 Event ID 占据低位 15 Bit，中间 1 Bit用来区别两者，高位 16 Bit 代表 Service ID。

Request ID

Client ID 用来区分不同的客户对象，Session ID 用来区分不同的对话。

Message Type

Message Type 用来标记消息类型。共有如下几种：

0x00	REQUEST	单纯的Request，无 Response
0x01	REQUEST_NO_RETURN	一个 Fire&Forget类型Request
0x02	NOTIFICATION	一个关于Event 的callback的 Request，无 Response
0x80	RESPONSE	一个Response
0x81	ERROR	一个带ERROR信息的Response
0x20	TP_REQUEST	单纯的TP Request，无 Response
0x21	TP_REQUEST_NO_RETURN	一个 Fire&Forget类型TP Request
0x22	TP_NOTIFICATION	一个关于Event 的callback的TP Request，无 Response
0xa0	TP_RESPONSE	一个TP Response
0xa1	TP_ERROR	一个带ERROR信息的TP Response

Return Code

根据 MessageType 不同，Return Code 不同。
一般是 E_OK(0x00)，但如果是 Response 或者 Error 的话就不会是 0x0。

Payload

SOME/IP 底层可以基于 TCP 或者 UDP，这使得 Payload 的容量不一样。

如果是 UDP 协议，那么 SOME/IP 大概限制在 1400 Bytes的容量。
但如果是基于 TCP 协议，通过数据分段传输，那么 SOME/IP 可以实现更大容量传输。

Endianess

所有的 SOME/IP Header 内容采用大端传输(big endian)。
而 Payload 中的数据存放顺序通过配置设置。

7. SOME/IP 支持的数据结构类型

基础数据类型

上面是基础数据。

结构化数据类型

结构化数据在内存中是依次存放的。

8. SOME/IP 消息通信类型

有 4 种：

• R & R (Request & Response)
• F & F (Fire & Forget)
• Notification
• Event

R&R

最常见的通信模式之一是请求/响应模式。客户端发送请求消息，服务器给予回应。

F&F

客户端发送 Request，无需 Response 的操作称为 Fire & Forget。

Notification Event

Notification 代表的是一种 Publish-Subscribe 通信机制，Server 端会主动推送信息给订阅方。

但 Notification 分3种情况：

• Cyclic Update 周期性的发送相关 value 的变化
• Update On Change 如果 value 发生变化，则向外推送
• Epsilon Change 如果 value 的值大于相应的 epsilon值，那么对外推送消息

Fields

什么是 Field 呢？Autosar 说 Filed 就是一个 status，并且有一个合法值(valid value).

Field 支持 Setter、Getter 操作。
一个 Fileds 操作应当包含 Setter、Getter 与 Notification 的结合。

• 执行 Setter 时，由 Client 发起 Request，并且在 Request 中的 payload 中设置确定值，并且在 Response 中的 payload 要同步返回这个值，代表 Client 向 Server 针对某个 Field 进行赋值操作
• 执行 Getter 时，由 Client 发起 Request，Request 需要包含一个空的 payload，Sever 端收到 Request 后将 Field 的值填充到 Response 中的 payload 中

9. SOME/IP-SD

SD 是 Service Discovery，也就是服务发现的意思。
SD 在 Autosar 中的模块主要功能：

• 探测服务
• 向外提供服务

SD 模块位于 Autosar 中的 BswM 和 Socket Adaptor 之间。

消息体结构

可以看到 SOME/IP-SD 依附在 SOME/IP 消息体之上。多了一些参数,其中最明显的就是 Entries Array。

Entry 分 2 种：

• 标记 Service
• 标记 Event Group

服务发现的流程

谈论 Service Discovery 之前，要搞清楚几个基本概念

• Service 指代 functional entities，代表的是一项功能.
• find 是一项操作，用于标识 available 状态的 service 及它的们的位置
• event Service Discovery 传送的 Message 被称为 event
• Eventgroups event 的集合

Service 中有许多细节。

Service 有 2 类：Server Service 和 Client Service。
Service 有 2 种状态: Down 和 Available。

一个 ECU 需要处理两种 Service:Server Service 和 Client Service。

也就是说，一个 ECU 可以对外提供服务,这个时候由它的 Server Service 模块负责，也可以对外请求服务，这个时候由 Client Service 提供。

当然，实际的流程非常复杂，一个 Service 从 Down 状态到 Available 状态之间的切换有一系列的状态阶段转换。

Service Discovery 流程及细节非常复杂，需要专门的文章篇幅才能详细描述，本文只介绍基础概念，细节就不过度展开。

10. vsomeip 及示例

someip 有商业版本，也有开源版本。vsomeip 就是开源版本，它由 BWM 集团实现。

我们从 github 上下载源码，然后编译。 它有两个重要的 .so ：

• libvsomeip3.so 对应 SOME/IP
• libvsomeip3-sd.so 对应 SOME/IP-SD

vsomeip 源码中有一个 helloworld 的demo，我们可以编译后运行。

但直接运行会报错。

这是路径问题，解决方案是：

cd build
sudo make install
sudo ldconfig

然后，我们分别在两个终端分别运行 ./hello_world_service 和 ./hello_world_client。

最终可以看到能够正常通信。

Client 先发送一个 World。
Server 端回应一个 Hello World。

这代表 vsomeip 基础通信已经被试验了，而更高级更精细的操作则需要开发者认真研究。

11. SOME/IP 会被 DDS 吊着打吗？

虽然本文讲的是 SOME/IP，但 DDS 同样重要。DDS 甚至可以算是 SOME/IP 最强劲的对手。
SOME/IP 与 DDS 的差异性比较如下：

然后，一个不好的信号就是 AP Autosar 从 18.03 版本开始，也把 DDS 纳入通信管理标准中。

并且 DDS 和 SOME/IP 在 Autosar 中架构处于同一层级。

问：那根据上面的描述，SOME/IP 会很快被 DDS 取代吗？
答：我认为不会。

我依据的逻辑如下：

1. SOME/IP 有先发优势，而 DDS 目前尚未被真正收录到 AP Autosar中;
2. DDS 看起来功能更完善，但功能完善不代表工程化程度高，汽车讲车规，很多经验需要积累,一般车企不敢贸然行动;
3. 技术方案有惯性，当前 SOME/IP 用在整车领域挺好的，没必要因 DDS 的介入一票否决它，况且 DDS 需要在汽车领域证明自己;
4. DDS 需要证明自己是因为 SOME/IP 从设计初就是面向汽车软件开发，而 DDS 不是。DDS 是从航天、工业、机器人领域开始迁移，这里存在裁剪、适配的过程;
5. 未来很长一段时间，汽车会存在各类 ECU，ECU 可能基于 AP，也可能基于 CP，这个时候 SOME/IP 比 DDS 应用代价要低;
6. SOME/IP 和 DDS 共存也是没有关系的，如果做不到万无一失，那为何要直接替换它呢？风险怎么算？

参考

1. AUTOSAR_PRS_SOMEIPProtocol.pdf
2. https://www.36kr.com/p/1725052829697
3. https://blog.csdn.net/Aliven888/article/details/122557080