SOMEIP到底讲什么_新能源技术.docVIP

SOMEIP到底讲什么 01 SOME/IP 2011年，BWM设计和提出了SOME/IP，SOME/IP全称为Scalable?service-Oriented MiddlewarE over IP，拆分起来理解就是以Server-Client服务形式进行通信，并且服务具备高度可扩展性，同时作为应用层协议运行于车载以太网四层以上，作为以太网通信中间件来实现应用层和IP层的数据交互，使其不依赖于操作系统，又能兼容AUTOSAR和非AUTOSAR平台，因此SOME/IP可以独立于硬件平台，操作系统和编程语言。 众所周知，在传统以太网中，OSI将以太网分层七层，但是汽车行业，只有5层，将OSI 5-7层统称为应用层，其中SOME/IP协议是一种应用层协议，运行在TCP/UDP传输协议之上。从图中可知，SOME/IP还有一个控制协议，称为SOME/IP-SD，用于服务发现，跟SOME/IP各司其职。 讲了SOME/IP所在层级，再来介绍下，SOME/IP报文的封装风格。不管是SOME/IP还是SOME/IP-SD报文，统一作为TCP/UDP Payload进行封装，四层以下封装格式遵循以太网本身的封装风格。 02 整车软件平台 目前整车电子电器软件平台如图所示，分为Classic AUTOSAR Platform(简称CP)，Adaptive AUTOSAR Platform(简称AP)和非AUTOSAR Platform。这三者是共同运行在整车电子电器架构之上，不存在谁取代谁，尤其是AP并不会取代CP和非AUTOSAR，相反AP可以很好的和其他平台交互，以丰富整车应用。 CP，AP和非AUTOSAR平台之间的通信交互主要由SOME/IP实现，借助SOME/IP协议的高度平台扩展性，实现不同平台的数据交互，因此统一的SOME/IP通信机制是不同平台通信的前提。 BWM设计SOME/IP协议之后，通过CP规范发布公开从而被广泛用于车载以太网，所以说SOME/IP起源于CP也不为过： AUTOSAR 4.0：支持初步的SOME/IP报文 AUTOSAR 4.1：增加SOME/IP-SD控制机制和发布-订阅机制 AUTOSAR 4.2：增加序列化机制 AUTOSAR 4.3：修复序列化机制的bug，同时增加大数据包基于UDP报文分片机制，此时的SOME/IP已经是完善的版本 为了在不同软件平台上运行SOME/IP，使得整车以太网上实现SOA架构通信机制，所以AP规范中也同步引入了SOME/IP，因此对于AUTOSAR系统，CP和AP之间实现SOME/IP通信，是比较容易的。 非AUTOSAR软件平台为了和车内CP和AP ECU更好的交互，GENIVI系统同样也开发了一套开源vSOME/IP软件源码，以便和CP/AP交互，但vSOME/IP是开源的，所以性能会差一些，因此需要统一的规范来做约束，从而做一些深层次的二次开发，我们基于AUTOSAR SOME/IP规范指定出自己的企业规范，以限制不同平台SOME/IP的通信行为。 03 SOME/IP特性 1.序列化和反序列化 将结构化的数据按照一定规则进行排序，将排完序的对象以一定形式封装到SOME/IP报文Payload中，发送给网络中。接收端收到后，通过反序列化将SOME/IP Payload按一样的排序规则重新组合成结构化数据，可以理解为将并行的结构化数据序列化成串行数据，通过以太网发送到网络中。 如图结构体中张三的个人信息按照特定规则进行编码，之后以二进制数据串形式通过以太网传输到对端，接收端收收到后反序列化出张三的个人信息。 CAN没有结构化数据这种概念，但为了实现一组功能相关信号打包在一起，从而引入信号组的概念，信号组就是人为的将CAN信号重组成结构体的一种做法。SOME/IP自身有序列化和反序列化的机制，因此SOME/IP通信行为中是绝对不会存在信号组的，所以如果你在设计CP Arxml后出现信号组的属性，那么这个Arxml就不在是SOME/IP，而是类CAN的一种基于信号的以太网通信。 2. 服务发现 服务发现称为Service Discovery，简称SOME/IP-SD，在服务创建并且可用之后，Server和Client需要通过SOME/IP-SD动态的创建两者连接，SOME/IP-SD报文主要： OfferService：Server服务就绪后，满足服务发布条件后，主动发出OfferService，用以告知组播内其他节点，该服务已经启动，可以创建服务连接。 FindService：当网络中未收到相关服务的OfferService或者暂时未收到，而且Client又需要该访问该服务，那Client可以使用FindService去主动寻找服务，如果Server服务Ready的话