SOME/IP 不是广义上的中间件,严格的来讲它是一种通信协议,但中间件这个概念太模糊了,所以我们也一般称 SOME/IP 为通信中间件。
SOME/IP 全称是 Scalable service-Oriented MiddlewarE over IP。也就是基于 IP 协议的面向服务的可扩展性通信中间件协议。
所以,要弄清 SOME/IP 需要从它的名字出发,要搞清楚它的 3 个要素:
我们带着这 3 个疑问走下去。
既然是通信中间件,那么做的就是通信相关的事情。
SOME/IP 能干的事情有 3 类:
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
前面小节讲到 CAN 是基于信号在双绞线中传输信号,而 SOME/IP 是面向服务在车载以太网中传输信号。 而 SOME/IP 中的 IP 是 Over IP ,也就是在 IP 协议层之上的意思。
我们能熟知的 TCP/IP、UDP 都是传统网络协议,网络协议是分层的,车载以太网网络协议也是一样的。
SOME/IP 和 DoIP、XCP 一样位于协议栈的应用层,并且它是基于 TCP/UDP 协议之上的应用。
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 也会常被提起。
具体到汽车软件开发,SOME/IP 有两种形态:
需要注意 GENIVI 这个组织,它针对 SOME/IP 标准实现了开源 vsomeip 方案,vsomeip 能够独立集中到操作系统中。
SOME/IP 协议一般指代具体 SOME/IP、SOME/IP-SD、SOME/IP-TP 3 种。
一个完整的 SOME/IP 消息,包含以下内容:
然后,这里面有许多细节。
可以指代一个远程调用 RPC 的 Method 或者是一个服务的 Event。
当 Message ID 代表 Method ID 时
当 Message ID 代表 Event ID 时
Method ID 和 Event ID 占据低位 15 Bit,中间 1 Bit用来区别两者,高位 16 Bit 代表 Service ID。
Client ID 用来区分不同的客户对象,Session ID 用来区分不同的对话。
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 |
根据 MessageType 不同,Return Code 不同。 一般是 E_OK(0x00),但如果是 Response 或者 Error 的话就不会是 0x0。
SOME/IP 底层可以基于 TCP 或者 UDP,这使得 Payload 的容量不一样。
如果是 UDP 协议,那么 SOME/IP 大概限制在 1400 Bytes的容量。 但如果是基于 TCP 协议,通过数据分段传输,那么 SOME/IP 可以实现更大容量传输。
所有的 SOME/IP Header 内容采用大端传输(big endian)。 而 Payload 中的数据存放顺序通过配置设置。
上面是基础数据。
结构化数据在内存中是依次存放的。
有 4 种:
最常见的通信模式之一是请求/响应模式。客户端发送请求消息,服务器给予回应。
客户端发送 Request,无需 Response 的操作称为 Fire & Forget。
Notification 代表的是一种 Publish-Subscribe 通信机制,Server 端会主动推送信息给订阅方。
但 Notification 分3种情况:
什么是 Field 呢?Autosar 说 Filed 就是一个 status,并且有一个合法值(valid value).
Field 支持 Setter、Getter 操作。 一个 Fileds 操作应当包含 Setter、Getter 与 Notification 的结合。
SD 是 Service Discovery,也就是服务发现的意思。 SD 在 Autosar 中的模块主要功能:
SD 模块位于 Autosar 中的 BswM 和 Socket Adaptor 之间。
可以看到 SOME/IP-SD 依附在 SOME/IP 消息体之上。多了一些参数,其中最明显的就是 Entries Array。
Entry 分 2 种:
谈论 Service Discovery 之前,要搞清楚几个基本概念
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 流程及细节非常复杂,需要专门的文章篇幅才能详细描述,本文只介绍基础概念,细节就不过度展开。
someip 有商业版本,也有开源版本。vsomeip 就是开源版本,它由 BWM 集团实现。
我们从 github 上下载源码,然后编译。 它有两个重要的 .so :
vsomeip 源码中有一个 helloworld 的demo,我们可以编译后运行。
但直接运行会报错。
这是路径问题,解决方案是:
cd build
sudo make install
sudo ldconfig
然后,我们分别在两个终端分别运行 ./hello_world_service 和 ./hello_world_client。
最终可以看到能够正常通信。
Client 先发送一个 World。 Server 端回应一个 Hello World。
这代表 vsomeip 基础通信已经被试验了,而更高级更精细的操作则需要开发者认真研究。
虽然本文讲的是 SOME/IP,但 DDS 同样重要。DDS 甚至可以算是 SOME/IP 最强劲的对手。 SOME/IP 与 DDS 的差异性比较如下:
然后,一个不好的信号就是 AP Autosar 从 18.03 版本开始,也把 DDS 纳入通信管理标准中。
并且 DDS 和 SOME/IP 在 Autosar 中架构处于同一层级。
问:那根据上面的描述,SOME/IP 会很快被 DDS 取代吗? 答:我认为不会。
我依据的逻辑如下: