SOME/IP不等同于SOA，CommonAPI-RPC通信和vsomeip基于消息通信

最新推荐文章于 2025-03-13 17:25:00 发布

Hali_Botebie

最新推荐文章于 2025-03-13 17:25:00 发布

阅读量3.3k

点赞数 3

分类专栏： linux/ROS/DDS/autoSAR中间件操作系统文章标签：中间件

原文链接：https://blog.csdn.net/xllhd100s/article/details/112171880

版权

linux/ROS/DDS/autoSAR中间件操作系统专栏收录该内容

44 篇文章

订阅专栏

看法：

SOME/IP协议其实并不等同于SOA，只能说要实现SOA，SOME/IP是一个可行的协议选择。SOME/IP还有一个控制协议SOME/IP-SD。
基于消息的通信与RPC(Remote Procedure Call，远程过程调用)通信都可以实现SOA
用vsomeip的话，Payload的打包和解析要自己写，属于基于消息的通信
用CommonAPI的话，RPC通信，接口可以用IDL描述，这在SOA中非常有用，很多代码由工具生成，基本通信几乎不需要联调，主要的开发工作是实现服务的接口，相当于填充业务逻辑，工作量少，同时可以发挥的空间也小。

我们看到使用RPC通信和基于消息的通信是截然不同的编程体验，RPC让客户端可以像调用本地函数一样调用服务端的函数，很显然它们并不在同一个进程

在RPC框架中，桩的实现原理是非常关键的，它屏蔽了网络通信的实现，让客户端可以像调用本地接口一样调用服务端提供的接口，而不用关心用的什么通信协议、序列化方式，以及所有的通信细节。CommonAPI的桩是由代码生成器根据IDL生成的，而在有的RPC框架里，还可以用动态代理的方式得到。

SOME/IP 协议介绍

SOME/IP，全称为Scalable service-Oriented MiddlewarE over IP，是用于控制消息的汽车中间件解决方案，是一种面向服务的可伸缩的协议。SOME/IP于2011年由BMW设计，2014年纳入AUTOSAR规范。

SOME/IP的报文格式如下图所示，由消息头部(Header)和消息体(Payload)组成

在这里插入图片描述

Message ID，用于唯一标识消息，当消息为Method类型时，由Service ID和Method ID组成，当消息为Event类型时，由Service ID和Event ID组成，如下图所示：

Length，消息长度(从Request ID开始到Payload结束)；

Request ID，服务提供者和调用者可用于区分相同消息的不同调用，由Client ID和Session ID组成。通常我们称服务提供者为Service，服务调用者为Client，Service ID和Client ID用于区分，一般会在一个SOA架构中统一地配置这些ID的数值。




Protocol Version，协议头版本号，目前该值必须为1；

Interface Version，接口版本号，一般由服务提供者定义；

Message Type，用于标识消息的类型

在这里插入图片描述

消息类型和通信机制之间的映射关系

在这里插入图片描述

Payload，也叫有效载荷，是消息内容，通常它的长度是可变的。SOME/IP协议在OSI七层网络结构中位于应用层，它建立在TCP或者UDP传输层协议之上。当通过UDP传输时，由于UDP的限制，Payload的长度应该限制在1400字节以内，超了则要分组(SOME/IP-TP)，而当通过TCP传输时，可以传输更多的字节，理论上只要不超过Length字段的大小即可。对于AUTOSAR系统，Payload要遵循AUTOSAR规范进行序列化，对于非AUTOSAR系统，可以遵循AUTOSAR规范进行序列化，也可以采用其他序列化方式如常用的Google Protocol Buffer、JSON等。

SOME/IP-SD

SD通信主要涉及到3类报文：Find Service、Offer Service和Subscribe报文。

Client如何发现服务

当服务不可用时，如何通知Client

Client如何订阅事件

这些就是SOME/IP-SD要做的事情了。SOME/IP-SD也是基于SOME/IP的报文，用来实现服务发现和事件订阅机制。SOME/IP-SD消息通过UDP进行传输，报文格式如下图所示：

在这里插入图片描述

目前GENIVI的vsomeip开源库已经实现了SOME/IP协议栈，所以通常并不用再去造轮子。换言之，我们完全可以基于vsomeip开发SOME/IP应用程序，不用关心报文长什么样，也不用关心服务发现和事件订阅的细节，拿到手已经是Payload了，如果再用上GENIVI的CommonAPI，IDL一写，一条命令下去，代码自动生成了，Payload都用不着解析了，这样就实现了真正的RPC

Payload的序列化与CommonAPI-SomeIP

我们已经可以基于vsomeip实现SOME/IP应用，并且服务端和客户端之间进行消息的通信，消息的内容称为Payload。但是设想一下，如果当我们需要传递的消息内容是一个比较复杂的数据结构，比如一个结构体，一两个倒也没事，多了以后，Payload的打包、解析和联调都会是件麻烦的事。

这时，我们会想到序列化，比如用Google Protocol Buffer之类的，是不是可以解决问题呢？对于非AUTOSAR设备之间的通信，是可以解决的，但对于与AUTOSAR设备之间的通信，恐怕就行不通了，因为Payload是需要遵循AUTOSAR规范

在这里插入图片描述

于是，我们又会想到，如果有人能把符合AUTOSA规范的序列化这一步也帮我们做好那就更好了，这就是RPC(Remote Procedure Call，远程过程调用)可以做到的事了。GENIVI的CommonAPI C++是基于vsomeip实现的RPC框架

CommonAPI-RPC通信和vsomeip基于消息通信

应该选择CommonAPI还是vsomeip呢？用vsomeip的话，依赖的东西少，Payload的打包和解析要自己写，工作量大，自由发挥的空间也大，用CommonAPI的话，依赖的东西多，环境搭建相对复杂，接口可以用IDL描述，这在SOA中非常有用，很多代码由工具生成，基本通信几乎不需要联调，主要的开发工作是实现服务的接口，相当于填充业务逻辑，工作量少，同时可以发挥的空间也小。很多事都是这样吧，获得便利的同时也会损失一些自由，如何选择还是要具体分析。

我们看到使用RPC通信和基于消息的通信是截然不同的编程体验，RPC让客户端可以像调用本地函数一样调用服务端的函数，很显然它们并不在同一个进程

参考

链接：https://blog.csdn.net/xllhd100s/article/details/112798677
https://blog.csdn.net/xllhd100s/article/details/112309194
https://blog.csdn.net/xllhd100s/article/details/112171880