汽车软件通信中间件SOME/IP简述

Posted 2023-02-04 frank909

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了汽车软件通信中间件SOME/IP简述相关的知识，希望对你有一定的参考价值。

文章目录

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 取代吗？
答：我认为不会。

我依据的逻辑如下：

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

参考

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

以上是关于汽车软件通信中间件SOME/IP简述的主要内容，如果未能解决你的问题，请参考以下文章

汽车软件通信中间件SOME/IP简述

通信中间件 Fast DDS 基础概念简述与通信示例

粗略聊聊中间件与SOME/IP之一