车载以太网SOME/IP应用研究

摘 要：概述了车载以太网应用背景;介绍了SOME/IP协议的原理、报文格式和交互方式。通过导航功能服务的设计，文章介绍SOME/IP在ECU之间的使用方式。使用测试工具测试仪表和多媒体系统之间的导航服务，验证设计的可行性。

引言

随着汽车迈向智能化、网联化、信息化的发展方向，汽车功能普遍增加，高性能的硬件平台被用于车型的域控制器或中央域控制器。整车电子电气架构迈向域控制器架构方向。整车通信信号数量大幅增加到5-10Mbps，导致传统的CAN总线通信已经不能满足整车通信带宽。整车网络架构不在单一地采用CAN/LIN总线进行通信，而是转向高带宽的CANFD和Ethernet通信。

基于车载以太网的网络通信已经被明确为下一代网络核心架构。目前越来越多的OEM选择使用车载以太网。不同的应用场景选择不同的应用协议进行适配才能满足相关功能需求。而且基于TCP/IP的底层协议栈的稳定性和兼容性，也是OEM考虑的首要因素。综合上述考虑，越来越多的OEM和供应商选择加入AUTOSAR联盟，使用AUTOSAR协议栈[1]。

AUTOSAR规范的核心目标是实现汽车电子软件的可复用性，通过规范内的分层架构对软件开发过程进行分层分工，各个层次之间的接口部分按照统一规范开发，而层次内部则可由开发人员自由发挥。以此提高软件复用率，降低开发成本，方便軟件的更新和维护。在AUTOSAR协议设计过程中，宝马公司开发了SOME/IP（Scalable service-Oriented Middleware over IP）协议，该通信协议是面向服务的通信协议，不同ECU之间通过Client /Server的方式进行通信，数据只在有需要的时候进行传输，有效降低了总线负载[2]。

1SOME/IP简介

1.1SOME/IP协议位置

SOME/IP本身属于车载以太网通信协议架构中应用程序与传输层协议之间的中间件（Middleware），起源于复杂的软件系统开发，并涉及“服务”所需的所有功能以实现其他软件组件之间数据交换，这种数据交换需要经由网络，中间件的任务就是确保需要交换数据的软件组件在网[3]。其在车载以太网通信协议模型的位置如图1 所示。

ECU通信根据功能需求的不同，划分为Client（客户端）和Server（服务器）。Server通过SOME/IP的服务接口Service Interface向Client提供服务。Client也通过服务接口向Server请求服务。

1.2SOME/IP交互方式

SOME/IP的通讯方式与传统CAN总线方式不同。CAN总线的通信主要采用定时发送的周期型发送，不论接收方是否有需求，发送方都会发送此帧报文。这样对于总线带宽是有一定的浪费。但是考虑到传统嵌入式资源有限，这种简单的交互方式往往提高了资源利用率，降低了开发成本。SOME/IP的通信方式主要是由Client向Server索取，如果Client有需求则向Server发送请求，服务提供相关服务数据。如果Client没有需求，则Server停止响应。具体的交互方式如下：

1）请求响应：Request-Response

2）有请求无响应：Fire&Forget

3）订阅：Notification

4）数据访问：Setter/Getter

Request-Response的数据发送方式主要由Client在有工作需求时，向Server发送Request请求报文，该请求报文包含请求的服务ID和相关参数。Server将回复的响应装载到Response的有效载荷，回传给Client，最终实现2个ECU的远程调用。如果Response不带有任何有效载荷，该响应只表达Server收到Client的请求。此类发送方式，多用于车载ECU之间的功能交互，功能设定的场景下。

Fire&Forget的数据发送方式主要有客户端发送请求，但不需要服务回复应答。此类发送方式，多用于对车载ECU进行设置但不需要反馈结果的场景下，例如开关打开、配置激活等功能。

Notification的数据发送方式主要为发布和订阅。Server启动后，将自身可以提供的服务，通过SOME/IP-SD发布。Client启动后，将自身需要查找的服务通过SOME/IP-SD发布，同时Client通过SOME/IP-SD完成订阅。订阅完成后，Server会将client需要的信息封装在event中，多个event组成eventgroup，Server将eventgroup周期的发送Client。当Client不在需要此eventgroup时，可以通过SOME/IP-SD停止发送订阅Server的消息。Server停发相关的服务消息。此类发送方式，多用于车载ECU将传感器、执行器等运行状态通知其它ECU的场景下，例如环境温度、当前时间、续航里程等等。

Setter/Getter的数据发送方式实质上Request-Response的发送方式，但使用场景不同。Setter用于设置对端ECU的参数，通过Setter request的有效载荷发送设置的参数，Setter response的有效载荷反馈设置结果。而Getter用于获取对端ECU的参数，通过Getter request请求服务ID，Getter response反馈参数结果。

1.2SOME/IP报文格式

SOME/IP的报文包含SOME/IP报头和有效载荷。SOME/IP的报头，如下图所示，包含7个字段。

1）Message ID唯一确定了服务的信息。包括16bit的Service ID和16bit的Method ID。Service ID用于定义每个功能服务，Method ID是服务中具体的功能或方法。每个Method ID代表了该服务的一个功能交互或实现方法。

2）Length表示其后所有字节的长度。

3）Request ID分为Client ID和Session ID。Client ID唯一定义了服务的请求方的身份标识。Session ID可以相同在订阅构成服务的调用次数。

4）Protocol Version表示SOME/IP协议的版本，目前默认为0x1。

5）Interface Version表示服务接口的更新版本，可以根据实际应用随着版本变更进行累计。

6）Message Type表示SOME/IP的报文类型。包括Request（0x00），Response（0x80），Request_NoReturn（0x01），Notification（0x02）和Error（0x81）。

7）ReturnCode表示错误代码类型，此字段与MessageType=Error配合使用，用于说明交互过程中的错误。

1.3SOME/IP-SD报文格式

SOME/IP-SD是服务发现报文。报文格式如下图所示。

SOME/IP-SD作为特殊的SOME/IP报文，其报头采用固定的0xFFFF 8100作为Message ID。Protocol Version固定为0x1，Interface Version固定为0x1，Message Type固定为0x2，Return Code固定值为0x00。

在SOME/IP-SD报头后具有8个bit的Flags标志位，该信号用于描述重置状态和单播狀态。

条目数组（Entries Array）和其长度字段描述该ECU支持的服务列表，包括可以提供（Offer）的服务和需要订阅（Find）的服务。

选项数组（Options Array）是为条目数组中的服务列表提供详细描述信息的，例如提供节点选项信息，描述该服务的发送IP地址和发送的端口号等。

车载ECU在启动运行后，Server发布SOME/IP-SD的消息提供其全部的服务列表。而Client在启动后也会发布其需要订阅的项目列表。并且在收到Server的服务列表后，发送订阅请求，实现服务的注册。

2SOME/IP服务设计

面向服务的设计是指将各种功能以服务的形式提供给最终用户或者其他服务。将相关联的一组信号或者功能执行所需要的参数合集，整体定义为一个服务。取代CAN总线的面向单个信号传输，通过以太网将所有功能执行需要的信息全部封装在一个服务中。上层应用只要调用此服务接口，即可实现对功能控制。

以仪表显示导航信息为例，解释具体服务设计过程。如下图所示，导航功能位于车载多媒体系统IVI中，液晶仪表IP可以显示建议导航信息，提示驾驶员方向。

功能描述：方向盘开过按键触发导航功能，通过语音设置目的地，激活导航功能，IVI向IP发送导航信息服务NAVIService，IP收到NAVIService后，切换导航界面，显示导航数据。

导航功能是有IVI提供和实现的，所以对于此功能IVI是服务提供方，也视为服务发送方。而IP显示导航信息，是该服务的消费方。根据功能交互场景进行分析，功能激活后由Server将数据推送给Client，所以需要Client提前实现订阅，实现NAVIService的注册。

通过订阅的方式，IP可以获取IVI的导航信息。由于IVI的导航信息的时效性较高，按照100ms周期发送给IP。其交互等内容如下图所示。

NAVIService定义如下：

3SOME/IP测试验证

通过使用Vector公司的VN5640工具，测试IP和IVI系统在导航激活过程的数据传输。IP和IVI在整车上连接到交换机SWITCH的端口1和端口2，为了不破坏链路，将VN5640连接到交换机的第3路端口，配置交换机，将端口1和端口2的数据转发到端口3上。

系统上电运行后，IVI发送0xFFFF 8100的SOME/IP-SD报文，提供了ServiceID=0x100E的服务。通过IPv4 Endoption字段描述可以看出，该服务位于IP地址为172.16.100.119，传输协议采用UDP，端口号为30501。该消息清楚的描述了IVI可以提供的服务ID和该服务的位置。

IP收到此消息后，立刻发送Subscribe的SOME/IP-SD报文，请求在IVI的注册中心实现订阅注册。而IVI收到此消息后，通过Subscribe Acknowledge回复IP，成功完成订阅。

激活IVI的导航功能，从下图中可以看出，IVI的周期100ms向IPK发送消息。该消息的ServiceID=0x100E，Method ID=8007，与设计要求相同。

从数据长度可以看出，SOME/IP报文可以装置更多的字节，相比CAN总线大大提升了传输效率。

4 结论

车载以太网通过SOME/IP的通信方式，将多个数据封装为服务，通过订阅和发布的方式，或者请求/响应的方式，实现灵活的调度。每个ECU定义好服务接口，任何控制器都可以实现对此服务的调用和控制，简化了设计方法，便于后期功能的扩展。通过面向服务的设计方法，使车载ECU通信设计提升到了新的高度，

参考文献：

[1]张海涛，胡胜，仇林至.基于AUTOSAR的SOME IP通信及其多核应用的实现[J].上海汽车.2021，（01）：17-22.

[2]张弛，吴志红，朱元，等.基于AUTOSAR标准的ETH基础通信及SOME/IP通信实现[J].信息通信，2020（2）：7-12.

[3]李阳春.基于SOME/IP的整车电气通信网络设计研究[J].汽车文摘，2020（08）：32-37.

[4]AUTOSAR.SOME/IP Specification of Transformer， Release version 4.3.1[EB/OL].[2020-2-29].https：//www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_SWS_SOMEIPTransformer.pdf

[5]AUTOSAR_SWS_ServiceDiscovery.pdf[EB/OL].https：//www.autosar.org/fileadmin/user_upload/standards/classic/4-2/AUTOSAR_SWS_ServiceDiscovery.pdf

作者简介：

邓戬（1987- ），女，辽宁沈阳人，工程师，硕士，研究方向为车辆工程。