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

您所在的位置：网站首页 › someip协议栈开源 › 汽车软件通信中间件SOME/IP简述

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

2024-07-17 16:53| 来源: 网络整理| 查看: 265

文章目录1.SOME/IP 是中间件吗?2. SOME/IP 能干嘛？3. SOME/IP 与 CAN 的不同？通信速度通信负荷4. SOME/IP 和车载以太网、IP有什么关系？4. SOME/IP 和 Autosar、SOA 的关系？5. SOME/IP 的形态？6. SOME/IP 的消息格式?SOME/IP 消息结构Message IDRequest IDMessage TypeReturn CodePayloadEndianess7. SOME/IP 支持的数据结构类型基础数据类型结构化数据类型8. SOME/IP 消息通信类型R&RF&FNotification EventFields9. SOME/IP-SD消息体结构服务发现的流程10. vsomeip 及示例11. SOME/IP 会被 DDS 吊着打吗？参考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 IDLength 消息长度，从 Request ID 算起到Request IDProtocal 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)NotificationEventR&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 被称为 eventEventgroups 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/IPlibvsomeip3-sd.so 对应 SOME/IP-SD

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

但直接运行会报错。

在这里插入图片描述

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

代码语言：javascript复制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.pdfhttps://www.36kr.com/p/1725052829697https://blog.csdn.net/Aliven888/article/details/122557080

【本文地址】

公司简介

联系我们

今日新闻

推荐新闻

专题文章