SOME/IP到底讲了什么

SOME/IP到底讲什么

参考链接&＃xff1a;

1、https://zhuanlan.zhihu.com/p/186251698

2、DDS与SOME/IP 谁主沉浮&＃xff1f;
http://www.360doc.com/content/22/0319/22/50578091_1022296376.shtml
 

01
SOME/IP

2011年&＃xff0c;BWM设计和提出了SOME/IP&＃xff0c;SOME/IP全称为Scalable service-OrientedMiddlewarEoverIP&＃xff0c;拆分起来理解就是以Server-Client服务形式进行通信&＃xff0c;并且服务具备高度可扩展性&＃xff0c;同时作为应用层协议运行于车载以太网四层以上&＃xff0c;作为以太网通信中间件来实现应用层和IP层的数据交互&＃xff0c;使其不依赖于操作系统&＃xff0c;又能兼容AUTOSAR和非AUTOSAR平台&＃xff0c;因此SOME/IP可以独立于硬件平台&＃xff0c;操作系统和编程语言。

众所周知&＃xff0c;在传统以太网中&＃xff0c;OSI将以太网分层七层&＃xff0c;但是汽车行业&＃xff0c;只有5层&＃xff0c;将OSI 5-7层统称为应用层&＃xff0c;其中SOME/IP协议是一种应用层协议&＃xff0c;运行在TCP/UDP传输协议之上。从图中可知&＃xff0c;SOME/IP还有一个控制协议&＃xff0c;称为SOME/IP-SD&＃xff0c;用于服务发现&＃xff0c;跟SOME/IP各司其职。

讲了SOME/IP所在层级&＃xff0c;再来介绍下&＃xff0c;SOME/IP报文的封装风格。不管是SOME/IP还是SOME/IP-SD报文&＃xff0c;统一作为TCP/UDP Payload进行封装&＃xff0c;四层以下封装格式遵循以太网本身的封装风格。

02

整车软件平台

目前整车电子电器软件平台如图所示&＃xff0c;分为Classic AUTOSAR Platform(简称CP)&＃xff0c;Adaptive AUTOSAR Platform(简称AP)和非AUTOSAR Platform。这三者是共同运行在整车电子电器架构之上&＃xff0c;不存在谁取代谁&＃xff0c;尤其是AP并不会取代CP和非AUTOSAR&＃xff0c;相反AP可以很好的和其他平台交互&＃xff0c;以丰富整车应用。

CP&＃xff0c;AP和非AUTOSAR平台之间的通信交互主要由SOME/IP实现&＃xff0c;借助SOME/IP协议的高度平台扩展性&＃xff0c;实现不同平台的数据交互&＃xff0c;因此统一的SOME/IP通信机制是不同平台通信的前提。

BWM设计SOME/IP协议之后&＃xff0c;通过CP规范发布公开从而被广泛用于车载以太网&＃xff0c;所以说SOME/IP起源于CP也不为过&＃xff1a;

• AUTOSAR 4.0&＃xff1a;支持初步的SOME/IP报文
• AUTOSAR 4.1&＃xff1a;增加SOME/IP-SD控制机制和发布-订阅机制
• AUTOSAR 4.2&＃xff1a;增加序列化机制
• AUTOSAR 4.3&＃xff1a;修复序列化机制的bug&＃xff0c;同时增加大数据包基于UDP报文分片机制&＃xff0c;此时的SOME/IP已经是完善的版本

为了在不同软件平台上运行SOME/IP&＃xff0c;使得整车以太网上实现SOA架构通信机制&＃xff0c;所以AP规范中也同步引入了SOME/IP&＃xff0c;因此对于AUTOSAR系统&＃xff0c;CP和AP之间实现SOME/IP通信&＃xff0c;是比较容易的。

非AUTOSAR软件平台为了和车内CP和AP ECU更好的交互&＃xff0c;GENIVI系统同样也开发了一套开源vSOME/IP软件源码&＃xff0c;以便和CP/AP交互&＃xff0c;但vSOME/IP是开源的&＃xff0c;所以性能会差一些&＃xff0c;因此需要统一的规范来做约束&＃xff0c;从而做一些深层次的二次开发&＃xff0c;我们基于AUTOSAR SOME/IP规范指定出自己的企业规范&＃xff0c;以限制不同平台SOME/IP的通信行为。

03

SOME/IP特性

1&＃xff09;序列化和反序列化

将结构化的数据按照一定规则进行排序&＃xff0c;将排完序的对象以一定形式封装到SOME/IP报文Payload中&＃xff0c;发送给网络中。接收端收到后&＃xff0c;通过反序列化将SOME/IP Payload按一样的排序规则重新组合成结构化数据&＃xff0c;可以理解为将并行的结构化数据序列化成串行数据&＃xff0c;通过以太网发送到网络中。

如图结构体中张三的个人信息按照特定规则进行编码&＃xff0c;之后以二进制数据串形式通过以太网传输到对端&＃xff0c;接收端收收到后反序列化出张三的个人信息。

CAN没有结构化数据这种概念&＃xff0c;但为了实现一组功能相关信号打包在一起&＃xff0c;从而引入信号组的概念&＃xff0c;信号组就是人为的将CAN信号重组成结构体的一种做法。SOME/IP自身有序列化和反序列化的机制&＃xff0c;因此SOME/IP通信行为中是绝对不会存在信号组的&＃xff0c;所以如果你在设计CP Arxml后出现信号组的属性&＃xff0c;那么这个Arxml就不在是SOME/IP&＃xff0c;而是类CAN的一种基于信号的以太网通信。

2&＃xff09;服务发现

服务发现称为Service Discovery&＃xff0c;简称SOME/IP-SD&＃xff0c;在服务创建并且可用之后&＃xff0c;Server和Client需要通过SOME/IP-SD动态的创建两者连接&＃xff0c;SOME/IP-SD报文主要&＃xff1a;

• OfferService&＃xff1a;Server服务就绪后&＃xff0c;满足服务发布条件后&＃xff0c;主动发出OfferService&＃xff0c;用以告知组播内其他节点&＃xff0c;该服务已经启动&＃xff0c;可以创建服务连接。
• FindService&＃xff1a;当网络中未收到相关服务的OfferService或者暂时未收到&＃xff0c;而且Client又需要该访问该服务&＃xff0c;那Client可以使用FindService去主动寻找服务&＃xff0c;如果Server服务Ready的话&＃xff0c;会回复响应的OfferService报文。
• StopOfferService&＃xff1a;Server端发现服务不可用&＃xff0c;不满足提供服务条件时&＃xff0c;会主动发送StopOfferService报文&＃xff0c;用以告知组播内其他节点&＃xff0c;该服务已不可用&＃xff0c;取消服务请求和订阅。
• Subscribe&＃xff1a;事件组的交互机制采用订阅-发布形式&＃xff0c;当收到服务OfferService之后&＃xff0c;Client通过Subscribe报文主动跟Server订阅相关事件组。
• SubscribeACK/SubscribeNACK&＃xff1a;当Server收到Client的订阅报文之后&＃xff0c;需要先行判断是否符合可订阅的条件&＃xff0c;如果该Client满足事件组订阅条件&＃xff0c;则返回SubscribeACK&＃xff0c;告知Client订阅成功&＃xff0c;当事件组内的事件准备就绪之后&＃xff0c;Server会以某种约定好的形式发送相关事件给成功订阅的Client&＃xff0c;如果该Client不符合事件组订阅条件&＃xff0c;那Server就会直接回复SubscribeNACK&＃xff0c;告知订阅不成功。
• StopSubscribe&＃xff1a;当Client订阅某个事件组之后&＃xff0c;发现后续并不在需要改事件组的数据了&＃xff0c;则通过StopSubscribe报文来通知Server&＃xff0c;以断开两者事件组的交互。

下面结合下图详细说明&＃xff0c;服务可用之后&＃xff0c;Server通过SD OfferService组播报文告诉client&＃xff0c;该服务已经可用&＃xff0c;Client收到offerService报文之后&＃xff0c;首先启动了事件组订阅流程&＃xff0c;先发送Subscribe报文给Server&＃xff0c;Server验证相关权限之后&＃xff0c;发送订阅成功SubscribeACK给Client&＃xff0c;之后&＃xff0c;当Server该事件组的事件准备就绪之后&＃xff0c;会主动发送Event给Client。同时Client在OfferService有效期内&＃xff0c;随时都可以发送服务请求Request&＃xff0c;跟Server进行相关数据的交互。

4&＃xff09;服务接口

服务发现章节讲了服务发现相关报文的交互机制&＃xff0c;那大家对SOME/IP控制报文有了一定的了解&＃xff0c;同时对服务双方如何建立连接有一定的认识&＃xff0c;接下来我们来讲下服务数据交互。所有的服务数据交互所采用的报文我们统称为服务接口&＃xff0c;服务接口主要分为两大类&＃xff1a;

• Method&＃xff1a;一种远程过程调用&＃xff0c;采用Request-Response机制进行通信&＃xff0c;由Client发送远程过程调用请求Request&＃xff0c;用于请求相关数据或者请求执行相关操作&＃xff0c;Server收到Request&＃xff0c;根据内容做一些操作之后&＃xff0c;通过Response对Client的Request做出一些反馈。Method是一种可靠传输的服务接口&＃xff0c;需要关系Request是否被送达。
• Event&＃xff1a;订阅-发布机制是控制事件组的交互&＃xff0c;之后事件组是以单个Event报文进行就交互&＃xff0c;从而向Client发送相关数据。Event是一种单向传输&＃xff0c;无法保证数据是否被准确送达。
  针对以上两类服务接口&＃xff0c;SOME/IP进行了服务接口扩展&＃xff0c;从而还有了Fire&Forget报文和Field&＃xff1a;
• Fire&Forget&＃xff1a;一种特殊的Method&＃xff0c;但和Method又有本质的区别&＃xff0c;因为Fire&Forget只有Request&＃xff0c;没有Response报文&＃xff0c;主要有两种作用&＃xff0c;一种是作为某些Trigger触发Server做相应操作&＃xff0c;一种是充当Client的Event&＃xff0c;向Server发送相关数据
• Field&＃xff1a;Field关联三种服务接口&＃xff0c;以组合的形式来呈现&＃xff0c;三者对同一个数据做相关联的操作。
  • Getter&＃xff1a;Client主动获取相关操作的当前数据&＃xff0c;该服务接口Request不携带任何数据
  • Setter&＃xff1a;Client主动设置相关操作的数据&＃xff0c;同时Server要将Client设置的数据通过Response反馈给Client&＃xff0c;以便Client确认设置的数据是否成功。
  • Notification&＃xff1a;通信行为和Event极为类似&＃xff0c;也遵循订阅-发布机制&＃xff0c;以事件组的形式来订阅&＃xff0c;但所发布的数据和Getter/Setter是同一套。

以上是我对SOME/IP的一些见解&＃xff0c;因为篇幅有限&＃xff0c;并不能完整的讲述SOME/IP的内容&＃xff0c;比如SOME/IP报文格式&＃xff0c;Server和Client服务启动流程等等也都是比较重要的内容&＃xff0c;如果大家感兴趣&＃xff0c;可以自己看看AUTOSAR SOME/IP相关规范&＃xff0c;就会有比较深入的了解。规范列表如下&＃xff1a;

• • 《AUTOSAR_SWS_ServiceDiscovery.pdf》
  • 《AUTOSAR_SWS_SOMEIPTransformer.pdf》