SOME/IP车载以太网服务协议的关键技术与性能分析

张毅峰，欧阳颂华，魏 鹏，丁炜超，郑佳明

（1.上海捷能汽车技术有限公司，上海 201804；2.上汽集团 商用车技术中心，上海 200438；3.上海中桥职业技术大学，上海 201514；4.华东理工大学，上海 200237）

0 引 言

随着智能化和网联化的发展，越来越多的汽车具备环境感知、人机交互、驾驶决策等功能，这就要求汽车总线具备更高的数据传输能力和适用于复杂电子系统开发的通信架构。经典总线系统（如CAN，LIN，FlexRay等）使用面向信号的数据传输，这是一种根据发送者需求实现的通信过程，当发送者发现信号值变化或发送周期到达时，就会发送信息，而不考虑接收者是否存在需求。随着ECU（Electronic Control Unit）数量和车载电子系统的复杂性日益增加，面向信号的数据传输方式已逐渐无法满足车载应用软件的通信需求[1]。以太网凭借其低成本、高带宽、网络开放互联等技术优势，被汽车行业广泛认为是下一代的主流车载网络技术[2]。BMW公司于2011年开发并指定了基于IP、可伸缩的面向服务的中间件协议——SOME/IP（Scalable Service⁃Oriented Middle⁃ware over IP）[3]，这是一个车载以太网引入的应用层开放协议，对应OSI参考模型的5~7层，是为典型的汽车用例与汽车开放系统架构（Automotive Open System Archi⁃tecture，AUTOSAR）兼容而 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 。

目前，SOME/IP协议在汽车和航空航天领域的应用都取得了很好的发展，文献[4]针对SOME/IP协议提出了一种标准汽车中间件异常检测系统，该系统对SOME/IP数据包流制定了一组特定域规则集，用以识别SOME/IP协议的攻击隐患和协议违规之处，从而降低SOME/IP的安全隐患。文献[5]设计了使用Vector MICROSAR ETH进行TCP和UDP协议的通信方案以及使用SOME/IP进行以太网通信的方案，并在英飞凌TC397单片机上运行从而验证了设计方案的可行性。文献[6]基于车载以太网SOME/IP通信及以太网诊断技术，结合音响控制器的实际功能及路径分析，对故障诊断进行定义，设计了基于车载以太网的音响诊断技术。文献[7]基于SOME/IP的服务发现特性，提出了一种只包含可扩展以太网的车载E/E（电力和电子）体系结构，并与传统总线作比较，论证了以太网在汽车应用中的必要性。

与面向信号的数据传输方式不同，车辆ECU能够通过SOME/IP所提供的订阅、发布和远程调用等服务内容来实现面向服务的信息传输，从而使得发送方仅在网络中至少有一个接收方需要此数据时才发送数据。鉴于目前SOME/IP协议的开发和应用大都处于理论研究与仿真阶段，且解决方案少、缺乏成熟的开发案例，本文针对SOME/IP中的服务[8]发现（Service Discovery，SD）和传输协议[9]（Transport Protocol，TP）两个核心功能模块进行了技术特性分析，并基于Common API[10]和vsomeip搭建了面向服务的车载应用通信架构，对SOME/IP的一致性、可靠性和可扩展性进行了测试分析，从理论和实验两个方面，论证了SOME/IP协议在降低车载服务通信复杂性以及提高整车数据通信效率等方面的优越性。

1 SOME/IP关键技术分析

1.1 SOME/IP⁃SD

SOME/IP⁃SD的主要任务是管理车载通信中服务实体的可用性以及控制事件消息的发送行为，即服务寻址与事件订阅。客户端和服务端在使用SOME/IP⁃SD进行通信时主要包括Down，Initial Wait，Repetition和Main四个阶段，下面将分别结合服务启动的时序关系来分析服务端和客户端上述四个状态的具体通信行为。

1.1.1 客户端的通信行为分析

客户端处于Down阶段时说明服务未被应用请求。若客户端有来自应用层的请求，则进入Initial Wait阶段；若客户端收到OfferService消息，且此时服务被应用请求，则存储当前服务实例状态，启动TTL计时器，直接进入Main阶段。在Initial Wait阶段，客户端从系统预先定义的时间参数INITIAL_DELAY_Min和INITIAL_DELAY_Max之间取随机值，当定时器超过随机值后，发送第一帧多播Find Service消息，并进入Repetition阶段；如果此时收到OfferService消息，则取消计时器，直接进入Main阶段。进入Repetition阶段后，客户端重复发送多播FindService消息直到达到发送消息的最大数量。发送间隔以系统预设参数REPETITIONS_BASE_DELAY为基本单位，每发送一次，间隔是前一次间隔的2倍；若在该阶段收到服务端的OfferService消息，客户端计数器将停止记时，并立即进入Main阶段。客户端进入Main阶段后将不再周期性发送FindService消息，若收到服务端OfferService消息，则发送单播SubscribeEventgroup消息；若收到服务端StopOfferService消息，则停止针对该服务的所有计时器，继续保持监听状态。

1.1.2 服务端通信行为分析

服务端在Down阶段无法提供服务，当服务状态更改为可访问时，服务端进入Initial Wait阶段。在Initial Wait阶段，服务端从系统预先定义的时间参数INITIAL_DELAY_Min和INITIAL_DELAY_Max之间取随机值，当定时器超过随机值后，发送第一帧多播OfferService消息，并进入Repetition阶段；与客户端不同，服务端在Initial Wait阶段接收到的任何FindService消息都将被忽略。进入Repetition阶段后，为了让客户端快速发现服务，服务端重复发送OfferService消息，发送间隔以系统预设参数REPETITIONS_BASE_DELAY为基本单位，每发送一次，间隔是前一次间隔的2倍；当服务端在Repetition阶段收到客户端FindService消息时，延迟一定时间，单播OfferService消息给服务请求端；上述单播行为不影响Repetition阶段的正常多播行为，服务端会继续发送多播OfferService消息，直到达到OfferService消息的最大数量后进入Main阶段；在Main阶段，服务端周期性发送OfferService消息，以显示其可用性；如果该阶段收到客户端的Find Service消息，服务端在延迟一定时间后单独发送单播OfferService消息给服务请求端；类似地，如果服务端在Main阶段收到SubscribeEventgroup（StopSubscribeEventgroup）消息后，发送单播Ack（Nack）消息，并启动（终止）此订阅Entry的TTL计时器。

1.2 SOME/IP⁃TP

SOME/IP⁃TP模块的任务是对超过UDP有效负载的消息进行分段和组装。SOME/IP⁃TP在接收到软件上层消息传输的通知后，协议数据单元路由（Protocol Data Unit Router，PDUR）模块首先向传输协议（Transport Protocol，TP）模块发送SomeIpTp_Transmit（）消息请求传输，TP模块接收到传输请求后，若返回E_OK，则同意PduR模块的请求，开始传输过程。对于每个消息分段，TP模块首先向PDUR模块发送PduR_SomeIpTransmit（）消息请求传输协议数据单元（Protocol Data Unit，PDU），PDUR模块接收到TP模块的请求后，PDUR的上层模块检查可用数据是否符合PduInfoPtr⁃>SduLength报告的缓冲区大小，若符合（返回E_OK：SDU已被复制，SduLength表示复制的字节数），则复制由PduInfoPtr⁃>SduDataPtr提供的数据到缓冲区，并更新实际复制的数据长度（PduIn⁃foPtr⁃>SduLength）；若不符合，则返回E_NOT_OK而不更改PduInfoPtr（没有复制任何SDU数据）。

SOME/IP⁃TP接收到PDUR模块的SomeIp_RxIndi⁃cation（）消息后，指示TP模块开始接收数据。对于不期望接收到的数据，TP模块通过PduR_SomeIpRxIndica⁃tion（）接口向PDUR模块报告E_NOT_OK消息，表示传输出错；若传输未出错，则对于接收到的第一个PDU，TP模块通过CreateHeader（）接口为其创建消息头，然后调用PduR_SomeIpTpStart OfReception（）接口开始接收数据；对于接收到的非第一个PDU，TP模块只需调用PduR_SomeIpTpCopyRxData（）接口将接收到的数据提供给上层；对于接收到的最后一个PDU，TP模块在调用PduR_SomeIpTpCopyRxData（）接口将接收到的数据提供给上层后，还需调用PduR_SomeIpTpRxIndication（）接口通知PDUR模块传输是否成功。

2 面向服务的车载应用开发环境构建

面向服务的车载应用开发架构是在Arm Linux环境下基于CommonAPI C++[10]框架来构建。CommonAPI C++框架由上至下分为两部分，分别是独立于中间件的部分CommonAPI C++Core和依赖于具体中间件的部分CommonAPI C++Binding。CommonAPI C++Core的代码由接口描述语言Franca IDL定义接口规范；CommonAPI C++binding的代码生成器需要特定的中间件参数，即部署参数，例如String数据类型的编码/解码格式。这些参数在Franca部署文件*.fdepl中定义，主要独立于接口规范，用于选择使用的IPC协议。

CommonAPI的用户API可进一步划分为基于Franca IDL的生成部分和基于Runtime API的生成部分。其中，基于Franca IDL部分包含与Franca IDL文件的类型、属性和方法有关的API函数；基于Runtime API部分包含用于加载运行时环境，创建proxy等的API函数。在部署CommonAPI项目之前需要先部署SOME/IP环境。SOME/IP环境部署好后，基于CommonAPI框架的项目基本搭建过程分为以下四步，其工作流程如图1所示。

图1 CommonAPI工作流程

1）创建Franca IDL文件（*.fidl）和Franca部署文件（*.fdepl）；

2）通过代码生成器生成CommonAPI代码和CommonAPI绑定代码；

3）编写应用程序代码，将应用程序代码和CommonAPI绑定代码编译生成CommonAPI Binding Runtime库和可执行程序；

4）执行应用程序。

3 实 验

本文实验环境包括2台PC机和1台路由器。其中，PC机操作系统为Ubuntu 16.04，CPU为IntelⓇCoreTMi3⁃4160，内存为8 GB，vSomeIp版本为3.1.20.3；路由器的WAN口和LAN口均为百兆。

3.1 一致性测试

一致性测试使用订阅通知服务来验证SOME/IP协议实体与协议规范的符合程度。具体测试内容包括：

1）节点1和节点2各运行3个服务，每个服务单独提供一个event；

2）每个服务运行前都要等待，直到所有其他服务都可用；

3）每个服务要向其他的服务进行订阅，直到所有服务都订阅了其他服务的event；

4）每个服务为订阅其event的其他服务发送10次notify；

5）每个服务都需要等待，直到收到来自所有其他服务的notify的数量是正确的；

6）如果所有应该收到的notify都被收到，服务关闭。

从图2的实验结果可知，服务1、服务2和服务3运行在节点1上，服务4、服务5和服务6运行在节点2上。用时即为每一个服务收到所有其他服务通知的总耗时。但是可以发现，机器2上的三个服务用时明显小于机器1上的三个服务用时，原因是在测试中首先开启机器1上的三个服务后再开启机器2上的三个服务，存在时间误差。

图2 订阅通知功能一致性测试

3.2 可靠性测试

可靠性测试旨在评估协议实体在不同环境下的可用性，包括服务异常启停和大负载消息通信时延。启停测试包括启停应用、多次启停应用、未终止应用重启、从线程终止应用、异常捕获。异常捕获是指在注册消息处理器时，将方法ID变换后能否正确捕获到相应异常。测试结果如表1所示，可以看出应用程序的启停（包括应用层正常启停和线程层异常启停）可以正常执行，相应异常也能够捕获，但未终止应用无法执行二次重启，且提供服务应用的启停时间（301.1 ms/次）明显高于未提供服务的应用（100.8 ms/次）。

表1 异常启停测试

大负载测试用于评估在使用TCP通信时发送更大有效负载消息的可能性。具体测试内容是从客户端向服务端发送大负载消息，服务端接收消息后向客户端返回响应。

从表2实验结果中可以看出：第1个测试项目中客户端向服务端发送消息的负载大小是600 KB，重复收发10次，每次耗时约400 ms；第2个测试项目中客户端向服务端发送的消息负载大小随机，随机范围为0~10 MB，重复收发50次，每次耗时约600 ms；第3个测试项目中10次消息收发只有5次成功，原因是失败的5次发送的消息大小超过了配置文件中规定的最大消息大小（614 417 B）。第3个测试主要是检验配置文件中max⁃payload⁃size⁃reliable规定最大消息负载的可靠性。

表2 大负载测试

3.3 可扩展性测试

可扩展性测试以响应时间为指标，用于评估协议实体成功处理服务请求数量的能力，包括单用户顺序执行测试和多用户并发执行测试。单用户顺序执行测试主要用来测试单个服务顺序处理请求的可扩展性能。具体地，启动一个虚拟用户作为负载量，然后对同一测试用例按照1，10，100，1 000的比例增加请求数（请求顺序执行），并分别记录从客户端发送请求到服务端收到请求再响应给客户端的时间间隔，最后计算出这些测试结果的平均值作为平均响应时间。

实验结果如图3a）所示，可以看出当并发请求数量低于100时响应时间变化不大，当并发请求数达到1 000时响应时间会有明显的增加。

多用户并发执行测试主要用来测试单个服务并发处理请求的可扩展性能。具体地，用户数量按照1，2，4，8的比例增加，每个用户并发请求数量设置为100，分别记录不同用户数量从客户端发送请求到服务端收到请求再响应给客户端的时间间隔，最后计算出这些测试结果的平均值作为平均响应时间。

实验结果如图3b）所示，可以看出与传统的基于CAN总线的服务相比，基于SOME/IP的服务在为多用户提供服务情况下优势明显，并且在单用户并发请求数小于100，用户数量小于4时，系统响应时间增长较缓。

图3 可扩展性测试响应时间

4 结 语

本文从车载以太网服务通信的角度对SOME/IP协议中TP和SD功能模块所涉及UDP分段与重组、服务启动时序等关键技术特性进行了详细分析，并基于CommonAPI搭建了面向服务的车载应用通信架构，在该架构下对SOME/IP协议实体的一致性、可靠性和可扩展性进行了测试分析。实验结果表明，面向服务的SOME/IP通信协议具备较高的可靠性和可扩展性，能够有效解决车载服务使用的复杂性问题，降低车载应用软件的开发成本。值得注意的是，在研究过程中发现TP模块在进行信息传输的过程中缺乏针对网络异常的重发及重组机制，因此，后续研究会聚焦在如何获取SOME/IP服务通信过程中UDP传输性能和可靠性之间的权衡。

注：本文通讯作者为魏鹏。

-全文完-