在智能网联汽车中，大量的功能需要控制器间的协调工作来完成，当前基于信号（Signal-Oriented）的点对点通讯将会变的异常复杂，且不具备灵活性和拓展性，微小的功能改动都会引起整车通讯矩阵的改动。

“软件定义汽车”已为产业共识，为了真正实现软件定义汽车、软件驱动创新，从技术角度来看，汽车软件架构正由“面向信号”迈向“面向服务（SOA）”。SOA是一种软件架构，同时也是一种软件设计方法和理念，在IT领域已经有数十年的应用经验。将应用程序的不同功能单元（服务）进行拆分，通过这些服务之间定义良好的接口和契约联系起来，接口是采用中立的方式进行定义，它应该独立于实现服务的硬件平台，操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互,在不增加或更换硬件的条件下通过不同的软件配置为驾驶员提供不同的服务，从而实现千人千面。

协议架构

SOME/IP：Scalable service-Oriented MiddlewarE over IP，专门用于汽车行业的中间件, 实现SOA的协议之一。

车载以太网的5层模型结构如下图所示，包括应用层、传输层、网络层、数据链路层和物理层。SOME/IP是在传输层UDP/TCP协议基础之上，拥有特定的服务交互机制，服务上线后广播告知域内其他节点，其他节点收到服务广播后，请求或者订阅相关服务接口，不同于传统车载网络的通讯方式，当有请求发出时，SOME/IP才会发送数据，否则不发送。这样总线上就没有不必要的数据，降低了负荷。

通讯方式

SOME/IP向上层应用程序提供API接口，创建Client/Server客户端，通过TCP/IP协议对应的以太网进行通讯，通讯接口如下图所示。

访问方式分为远程过程调用（RemoteProcedure Call）、事件通知（Notification）、访问进程数据（Getter、Setter）3种：

1、远程过程调用：采用Request-Response机制进行通信，由Client发送远程过程调用请求Request，用于请求相关数据或者请求执行相关操作，Server收到Request，根据内容做一些操作之后，通过Response对Client的Request做出一些反馈。

2、事件通知：一个单向的数据传输，只能是onchange类型，用于Server主动向订阅（Subscribe）了相关服务的Client发布（Publish）信息。

3、访问进程数据：Getter是Client主动获取相关操作的当前数据，该服务接口Request不携带任何数据 。Setter由Client主动设置相关操作的数据，同时Server要将Client设置的数据通过Response反馈给Client，以便Client确认设置的数据是否成功。

报文格式

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

字段

解释

MessageID(Service ID)

服务ID，16bit，标识一个服务

MessageID(Method ID)

方法ID，16bit，标识一个方法

Length

报文长度，32bit，从Request ID到报文结束的总长度

RequestID(Client ID)

客户端ID，16bit，区分不同客户端

RequestID(Session ID)

会话ID，区分同一客户端的多次调用

ProtocolVersion

协议版本号，固定为0x01

InterfaceVersion

服务接口版本

MessageType

0x00 REQUEST

请求，需要回复

0x01REQUEST_NO_RETURN

请求，不需要回复

0x02NOTIFICATION

不需要回复的事件回调

0x80 RESPONSE

响应消息

0x81ERROR

包含错误码的响应消息

ReturnCode

返回码

Payload

数据段，需要传输的相关数据

SD协议

我们了解了一条完整的SOME/IP报文应该长什么样子，但这显然是不够的，至少还有以下这几个问题并没有得到明确的解决：

1、Client如何发现服务

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

3、Client如何订阅事件

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

ServiceEntry

用于服务发现：

Type：当网络中未收到相关服务的OfferService或者暂时未收到，而Client又需要访问该服务，那Client可以发出FindService去主动寻找服务，如果Service已经就绪的话，会回复OfferService报文；服务就绪后，主动发出OfferService，用以告知组播内其他节点，该服务已经启动，可以创建连接；当服务不可用时，会主动发送StopOfferService报文，用以告知组播内其他节点，该服务目前不可用，停止发送请求，并取消订阅。Index1stoptions：Option1排在Array里第几个Index2ndoptions：Option2排在Array里第几个# of opt 1：Option1的数目# of opt 2：Option2的数目ServiceID：Entry关于哪个服务Instance ID：Entry关于服务的哪个实例，0xFFFF表示全部实例Major Version：服务的主版本号TTL：“入口”的生命周期，单位为秒，理解为发现服务时的搜索时间，提供服务时的有效时间l MinorVersion：服务的次版本号

EventgroupEntry

用于事件订阅：

Type：当Client收到服务OfferService之后，Client可以发送Subscribe报文主动跟Service订阅感兴趣的事件组；当Client订阅某个事件组之后，后续发现不再需要改事件组的数据了，可以通过StopSubscribe报文来通知Service，避免不必要的数据交互；当Service收到Client的Subscribe报文之后，需要先行判断是否符合可订阅的条件，如果该Client满足事件组订阅条件，则返回SubscribeAck，告知Client订阅成功，当事件组内的事件准备就绪之后，Service会以某种约定好的形式发送相关事件给成功订阅的Client，如果该Client不符合事件组订阅条件，Service就会直接回复SubscribeEventgroupNack，告知订阅失败。InitialDataRequested Flag：如初始值由服务发送，须置为1Counter：区分相同订阅者的订阅请求EventgroupID：事件组ID，也就是说SOME/IP事件订阅和取消订阅的颗粒度到一个事件组，而不是一个事件

下面这幅图来之于AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol，说明了一个Client发现服务和订阅事件组的过程：

总结

SOME/IP算介绍完了。是不是觉得如果要自己实现SOME/IP全部的协议，还是有点复杂的。我们需要一条重要的“纽带”来承上启下，使上层应用与底层操作系统可以紧密的“连接”起来！

为此，我们需要对SOME/IP协议进行包装，让具体的服务和底层通讯隔离开。为此，我们需要开发一个套件，在实现SOME/IP协议栈之外，同时做好协议栈的封装，让上层的应用可以无感地通过SOME/IP来发现服务、调用接口。这个所谓的套件，就是「中间件」。

「中间件」的主要任务，是负责各类应用软件模块之间的通信以及对系统资源的调度。换言之，不用关心报文长什么样，也不用关心服务发现和事件订阅的细节，拿到手已经是Payload了，代码自动生成了，Payload都用不着解析了。它的优点，是可以大大降低应用层软件的开发难度，使研发工程师可以完全把注意力集中到功能的开发上。

目前，极氪的软件及电子中心部门正在开发的ZEEKR OS，就包括了这样的核心中间件。它不仅将SOME/IP的服务进行了有效的封装，还提供基础平台及支持自动驾驶、车身及底盘电子控制的整车服务。ZEEKR OS立足于打造一套高效稳定的整车中间件，为SOA提供核心竞争力并持续赋能。