通信中间件Someip服务化通信

前言

近年来，车辆智能化，网联化的需求愈演愈烈，“软件定义汽车”的势头甚嚣尘上，相信大家在听到这些术语的同时，一定也会听到“中间件Someip”。为了将“软件定义汽车”落地，使软件真正帮助汽车实现更好的进化，在整车软件软件层面，正由“面向信号”迈向“面向服务SOA”，通过将整车的不同功能以服务为形式进行拆分，通过中间件Someip以合理的接口以及协议将这些服务串联起来，实现新型的整车服务化通信。

那么，Someip到底是什么？如何发挥通信中间件的服务化作用呢？接下来将从如下几个方面对Someip进行剖析。

正文

1.什么是someip？

2011年，宝马提出和设计了Someip，SOME/IP全称Scalable service-Oriented Middleware over IP，即基于IP的可扩展面向服务的中间件。因此，从Someip的名字出发，有三个典型要素：

因此，要了解Someip，首先得理解Someip为什么要具备三个典型要素。

1.1 面向服务

提到面向服务，很多人会联想到面对对象编程的C++与python语言，someip的面向服务与python语言中的“类”是一致的，即把方法以及数据抽象出来，供多方使用。

即someip通信的本质是：一个控制器通过服务的方式使用另一个控制器的方法或者数据。

以车内温度值获取方式为例：

在基于can通信的电器架构中，一个特定的功能就需要一个人特定的信号。比如对于车窗控制功能，就需要一个can信号来表示车窗的上升与下降。当需要控制车窗上升时，对应的can信号的将设置为上升，并且周期发送。

基于can信号开启车窗

在基于Someip通信的电器架构中，一个特定的功能将被抽象成“服务”。这服务中可以有多种不同的方法，比如：车灯控制器服务，喇叭控制服务等。当需要控制车窗上升时，只需要通过将服务中的车窗控制方法设置为上升，并且只需要发送一次即可。

基于Someip信号开启车窗

那基于服务的通信方式有什么优势呢？

基于服务的通信方式的最大优势在于可扩展性强，便于更新。举个例子：

如果在车内有另一个控制器ECU3也需要对车窗升降进行控制，比如语音控制车窗。

1）如果使用Can通信，那么需要增加哪些工作呢？

l整车通信设计：增加Can网段或者Can信号（修改硬件或者修改通信矩阵），提供另一个车窗指令信号给ECU3使用。

lECU2软件设计：ECU2需要专门为了ECU3设计对应的车窗控制逻辑，因此需要修改软件。

2）如果使用Someip为基础的面向服务的通信，需要增加哪些工作呢？

l整车通信设计：只需要在整车通信设计层面，增加ECU3消费ECU2车窗服务。

面向服务是将功能抽象成服务，如ECU2将车窗功能抽象成车窗控制服务，车内任意节点需要使用车窗控制服务，只需要给ECU2发送对应的服务someip报文，而ECU2对应的车窗逻辑代码完全不需要修改。即面向服务的通信与信号完全解耦，扩展性强。

综上所述，面向服务的通信将原子功能服务化，软件功能逻辑与信号解耦，具有更强的可扩展性，降低修改需求时的成本。

1.2基于IP之上的协议

以太网是一种使用十分广泛的协议，由标准的七层架构组成，但CP中的以太网其实仅用了5层协议，Someip为第5层协议。

以太网第一层是物理层，既可以理解为硬件层，在MCU的软硬件系统中由Phy芯片完成。Phy芯片能对模拟信号与数字信号进行转换，接收报文时，将模拟信号转换成数字信号给MCU芯片处理；发送报文时，将数字信号转换成模拟信号发送至以太网总线上。

以太网第二层是数据链路层。链路层即Mac层，规定了数据帧能被网卡接收的条件，最常见的方式是利用利用网卡的 MAC 地址，发送方会在欲发送的数据帧的首部加上接收方网卡的 MAC 地址信息，接收方只有监听到属于自己的 MAC 地址信息后，才会去接收并处理该数据。以太网第三层是网络层。每一台搭载了以太网的ECU都需要定义ip地址，主机的网络地址该如何定义，以及如何在网络地址和 MAC 地址之间进行映射，即 ARP 协议；网络层实现了数据包在ECU之间的传递。

以太网第四层是传输层。传输层主要是实现UDP以及TCP协议功能，在一个ECU内可能存在不同的应用程序，这些程序可能会使用到不同的IP地址，那么传输层就能区分数据包是属于哪个应用程序的，即传输层可以实现数据包端到端的传递，即ECU1的应用程序至ECU2的应用程序。

Someip，Someipsd，Doip位于以太第五层应用层：Someip协议，，Someipsd协议，doip协议本质上是规定了对网络层传递的数据的处理，适应了不同的应用场景。在CP中，实际上Soad，SD，Doip，Soemipxf都是在实现应用层功能。

1.3 通信中间件

中间件本来是在互联网行业十分流行的术语，是基础软件一类，位于操作系统，网络，数据库之上，应用软件的下层。作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。在不同的技术之间共享资源并管理计算资源和网络通信。

中间件的核心思想在于“统一标准、分散实现、集中配置”。Someip这套协议具备了中间件的显著特征，能够运行于车内不同的操作系统之上，并且能满足同一套标准协议。

2.SOMEIP服务化通信

在面向服务的Someip通信中，Someip提供了三种接口将帮助使用者将原子功能服务化：事件Events:事件通知主要提供事件型的接口，该事件可以是突发型的事件，也可以是周期性的事件。

方法Methods:远程过程调用, 主要用于远程调用方法。

字段Fields:访问进程数据（Field）。访问进程通信机制主要是为了实现针对对应用程序的数据获取与更改

看完上面对于someip接口的解释，相信很多人还是对这些官方的抽象解释一脸疑惑，接下来为大家提供接地气的描述。

2.1 设定不同Someip接口的目的

本质上一个服务抽象的是一个大功能，每个功能会有不同的子功能以及不同的应用场景，所以就需要不同的接口满足不同场景需求。

以上文中提到的车窗服务为例，如果车窗服务有如下使用需求：

需求1：某ECU需要ECU2周期性提供车窗开度状态信息。

需求2：某ECU需要ECU2在车窗开度信息有变化时提供车窗开度信息。

需求3：某ECU在有需要时远程单次获取车窗开度信息。

需求4：某ECU需要设置当前的车窗开度信息

需求5：某ECU需要直接开关车窗

上面的不同功能需求都可以通过Someip提供的三种接口实现。

需求1：该需求为需要提供周期性事件信息，选Event接口。

需求2：该需求为需要提供突发型事件型的数据，选Event接口。

需求3：有需要时获取数据，即访问进程中的内容，选Field接口。

需求4：设置当前的车窗开度信息，也是访问进程中的内容，选Filed接口。

需求5：直接开关车窗，实现车窗的远程控制，需要远程调用开关服务，这是典型的远程调用，选Method接口。

看到这儿，大家是否对Someip接口有所认识，本质上Method/Event/Filed都是上层的概念，用以体现服务中子功能的特征，根据子功能的特点选择合适的接口。

比如事件型的子功能选Event，过程访问（比如车辆运行过程中获取空调温度，设置空调温度）选Filed，远程调用（比如App远程直接控制空调开关）选Method。

2.2 Someip服务的通信机制

Method/Event/Filed三个接口只是上层概念，是对于功能层面概念的抽象，在整车架构中实现这几种概念，还需要通信机制的支撑。

比如：打工仔有很好的针对业务上的建议（Method/Event/Filed），需要获取领导的资源支持，那么就需要使用PPT进行汇报，PPT就是底层的通信机制。

Someip提供了三种通信方式：

l请求/响应

l请求不响应

l服务发现/订阅发布

上述三种方式对应着四种真正的通信机制：

lRequest/response

lFire&Forget

lNotification

lGetter/Setter

通信方式描述的是通信机制的特点，通信机制是支撑Someip接口功能实现的底层通信机制。

通信机制有如下图中的对应关系，下面将介绍各接口中的通信机制。

1）Method

Method的特点是远程调用，根据是否需要服务端发出响应报文可以分为两类：

1.请求响应，即Request/Response机制

简而言之，Client端（某个ECU）有需求的时候，向Server端（某个ECU）发送Request请求Someip报文，Server接收报文后处理该请求，并向Client端发送响应Someip报文，响应Someip报文中将携带请求处理结果。

2.请求不响应，即Fire/Forget机制

Fire/Forget机制相对于Request/Response机制，区别在于前者不需要Server端发送响应报文，而后者需要。

2）Event

Event服务接口支持的通信机制是Notification，有如下特性：

l由Server向Client发送报文

l可周期性发送或者根据事件状态（值改变或者特定条件满足）发送通知类消息。

l在Server端发送报文之前，需要Client端先对服务进行订阅。

3）Field

Field访问进程通信支持了三种通信机制，Notification，Getter，Setter三种。

1.Notification

Filed支持Notification时，具有如下特性：

1）由Server端主动发送报文

2）在Server端提供的服务整个生命周期中，即在服务上线后的任意时刻，Server端可以Filed数据报文发送给Client端。Filed强调的是全生命周期的数据，Event强调的是变化的事件。

3）在Server端发送报文之前，需要Client端先对服务进行订阅。

2.Getter

Client主动从Server端获取field数据。

3.Setter

Client主动设置Server端的Field数据。

3.Someip的软件实现

在AUTOSAR架构中，Someip服务化通信的实现需要依赖于底层以太协议栈与应用层的共同完成。

如上文所描述，服务接口的抽象由应用层完成，即Event，Filed,Method的抽象，具体的通信机制由以太栈支持。

即以太协议栈与Rte将完成数据的序列化与反序列化，报文的组装与分解以及notify，RR，Getter/Setter等通信机制。

应用层SWC将完成Event与Method或者Filed特性的实现。

3.1 Method请求代码实现

下图为Method接口请求/响应中请求的代码实现方式。

Request/Response中Request即是典型的请求。

实际上，Method接口中请求在AUTOSAR架构中体现为函数调用。Client向Server端通过Method接口请求车窗开启，本质上就是，Client端向Server端请求调用对应的车窗控制函数，只不过函数调用请求需要通过Someip报文从Client端发送至Server端实现。

如下图，Client端Rte_Call_OpenTheWindowMethod(State)执行后，Someip报文将此请求传输至Server端，Re_OpenTheWindowMethod被调用。

注意：Request/Response中Response的实现方式与Request一致，不同点在于变为Server端请求调用Client端中的函数。

3.2 Event主动发送代码实现

下图为Event服务接口在代码中的实现方式。

在AUTOSAR架构中，Event实现的即为ECU间的数据传输。

Server端使用Rte_Write_WindowStateEvent(State)接口，通过Someip报文将State数据传送给Client端，Client端通过Rte_read_WindowStateEvent(State)获取数据。

注意：Fire/Forget.Field之notifation的实现机制与Event一致。

总结

本文对Someip的来源本质，Someip的服务化通信，以及Someip服务化通信在AUTOSAR中代码实现方式做了详细的介绍，如果需要深入了解Someip，还需要对Someip的报文格式，SomeipSD的机制以及AUTOSAR的以太栈模块进行学习。

---

End

「汽车电子嵌入式在CSDN上同步推出AUTOSAR精进之路专栏，本专栏每个模块完全按实际项目中开发及维护过程来详细介绍。模块核心概念介绍、实际需求描述、实际工程配置、特殊需求介绍及背后原理、实际工程使用经验总结。目的是让读者看完每一个章节后能理解原理后根据需求完成一个模块的配置或者解决一个问题。」

点击文章最后左下角的阅读原文可以获取更多信息

或者复制如下链接到浏览器获取更多信息

https://blog.csdn.net/qq_36056498/article/details/132125693

---

注：本公众号文章中使用了一些第三方工具和文档，若有侵权，请联系作者删除!

推荐阅读

汽车电子嵌入式精彩文章汇总第一期：20210530-20230703

AUTOSAR 架构下EcuM唤醒源事件详解

AUTOSAR架构下NVM Block连续写及Default Value问题分析

AUTOSAR架构下报文掉线超时不上报问题分析

Classic Autosar下的以太网通讯架构概览

AUTOSAR架构下Fee详细分析

TC37x芯片FLASH基本概念介绍

AUTOSAR架构下Fls详细分析

TC3xx芯片DMU介绍

AUTOSAR架构下NVM Block连续写及Default Value问题分析

End

---

欢迎点赞，关注，转发，在看，您的每一次鼓励，都是我最大的动力！

汽车电子嵌入式

微信扫描二维码，关注我的公众号

原文始发于微信公众号（汽车电子嵌入式）：通信中间件Someip服务化通信