从4月份直播开始到现在我们累计收集问题不下200个，于是我们专门针对童鞋们提出的这些问题做了一次分析，其中占比最高的居然是SOME/IP？但是SOME/IP真的有那么难吗？其实在怿星往期的文章中已经有不少介绍基本的汽车以太网通信和SOME/IP的文章，例如：《SOME／IP有那么难吗？》、《SOME／IP SD的通信行为》......鉴于童鞋们如此强烈的求知欲，我们今天再来聊一聊SOME/IP测试吧，也许，看完你就懂了~

 

SOME/IP协议简介

 

SOME/IP（Scalable service-Oriented MiddlewarE over IP）是车载以太网通信引入的一个协议概念，因为其优良的面向服务的可扩展性，被众多地使用到SOA架构车型的各个功能领域。从名字上即可看出其几个主要的特点：Scalable-可拓展可伸缩的、service-Oriented-面向服务的、Middleware-中间件、over IP-基于IP协议。SOME/IP 在AUTOSAR中有一套标准协议，SOME/IP协议测试，测的就是这一套协议。

 

SOME/IP SD（Service Discovery）- 服务发现

 

服务发现，是用来在通信开始阶段构建服务的客户端与服务端之间的通信关系的，通过服务发现机制，客户端能够找到服务端在哪里，服务端也能够告诉客户端自己的服务在哪里，同时也能够用于建立订阅与发布的关系。

 

SOME/IP SD包含4种报文类型，即FindService、OfferService、SubscribleEventgroup、SubscribleEventgroupAck。SD报文在传输时使用专用端口号30490，且Message ID固定为0xFFFF8100。

SOME/IP测试内容中，有很大的部分就是针对SOME/IP SD进行测试的。

 

SOME/IP服务接口

 

SOME/IP协议在通信过程中，共提供了四种接口（Service Interface）如下。针对这些接口的测试，也是SOME/IP测试中的重要部分。

 

• F&F Method：Fire&Forget Method是客户端向服务器发出的无需应答的请求，一般用于指令式的报文。

• R&R Method：Request&Response Method是客户端向服务器发出的待响应请求，一般用于客户端向服务器发送请求，调用服务器的数据。

• Event：属于事件通知类报文，仅在订阅成功后服务器向客户端发送，发送方式可由上层应用决定，可以周期性发送、可以由客户端使用Method触发，也可以在服务器状态值改变时发送。

• Field：多用于状态值的管理，相关报文有三种：一种是通过Event进行通知，第二种是可以通过Getter进行状态值的获取，第三种可以通过Setter进行状态值的设置。

 

SOME/IP序列化与反序列化

 

序列化与反序列化的过程，通俗的理解：信息装载为报文的过程就是序列化的过程，报文解析为信息的过程就是反序列化的过程。

序列化过程

 

如图所示的是一种序列化的过程示例，序列化需要将结构化的数据依次按照各自数据的长度放入报文，若数据结构中存在动态长度的数据，则需要加上长度字段进行长度描述，一般为4个字节，也可以根据规范配置16bit/8bit。按照SOME/IP的序列化规则，数据元素无需对齐，但是报文整体需要对齐。

针对SOME/IP序列化与反序列化的测试，也是SOME/IP测试的重要部分。

 

SOME/IP测试

 

接下来，我们进入主题，从SOME/IP测什么、SOME/IP怎么测、DUT怎么准备、SOME/IP测试经常会测出什么问题等几个方面展开介绍一下。

 

SOME/IP测试测什么：

SOME/IP测试主要验证的是SOME/IP协议栈，即SOME/IP协议在通过代码实现时，其代码的实现效果与协议本身要求是否一致。主要包含SOME/IP SD的报文格式和通信行为以及SOME/IP的报文格式和通信行为，也即我们前文所描述的SOME/IP的基本内容。测试主要遵循OPEN Alliance的TC8 3.0测试标准，分为Server和ETS两部分：

 

1、Server测试主要测试SOME/IP在被测对象作为Server节点时的协议栈实现情况，通过一个测试仪与某一个已有的服务进行交互，从而实现测试的目的；

2、ETS测试，全文Enhanced Testability Service（“增强可测试性服务”或者简称“增强测试服务”），这是一个服务（Service），是为了实现更多的测试功能专门制定的一个服务，该服务在TC8里给出了服务接口及服务的基本运算逻辑的定义，这个服务需要集成到被测件（DUT）里，集成之后能够实现与测试仪（Tester）之间的互动，从而实现对协议栈的测试目的。下面简单介绍两种测试的内容：

 

• SOME/IP Server测试

Server测试覆盖SOME/IP协议一致性测试，重点关注SD过程、报文结构、RPC机制等内容，目前SERVER部分一共涵盖93条测试用例：

 

SERVER测试用例概览

 

• SOME/IP ETS测试

我们先来看看ETS测什么：ETS测试包括SOME/IP的序列化、远程调用、服务发现、服务发布和服务订阅等内容。可分为6大类：报文格式测试(Message Format)、序列化(Serialization)、客户端模式(Client Mode)、测试Event(Test Event)、测试Field(Test Field)、SD测试(Service Discovery)。这些测试包括正向测试(使用有效消息进行测试)、逆向测试(测试错误处理)、负载测试和回归测试，共137条测试用例。

如下图示例：SOMEIP_ETS_77: Wrong_Service_ID

 

ETS_77测试规范

 

SOMEIP_ETS_77是报文格式测试(Message Format)的逆向测试，测试协议栈是否能对格式不正确的报文做出符合协议的响应，和其他TC8中的测试用例类似，主要包含如下四个关键部分：测试目的、测试步骤、通过条件、测试用例来源（即所参考的通信协议内容，亦即测的是啥）。SOMEIP_ETS_77测试用例流程如上图所示，测试规范要求协议栈接收到携带错误Service ID的SOME/IP报文时，响应报错报文或者无视该报文。

 

SOME/IP怎么测？

讲了这么多测试的内容，接下来看一下怎么开展测试。SOME/IP的测试主要遵循OPEN Alliance的TC8 3.0测试标准，标准中给出的测试拓扑如下图所示：

 

SOME/IP测试拓扑

 

EPT提供的SOME/IP测试方案，主要基于Vector CANoe所提供的免费开源的TC8 以太网测试脚本，并经过EPT团队进行优化和完善，严格参考TC8 V3.0的要求，配合对被测件的ETS的开发支持，实现了完整的对于Server及ETS的测试。（说起来容易做起来难，这里面我们可是花了不少精力趟了不少坑才完善起来的）

 

如下为基于CANoe12.0的基本测试拓扑：

 

SOME/IP基于CANoe进行测试的拓扑

 

被测件DUT怎么准备？

对于测试环境来讲，CANoe中的测试脚本俺们EPT都做好了，至于电源啦、接线啦，那对于各位专家都不是难事了。而另外的难点就在于被测件中的ETS集成与开发了。

ETS的实现主要在于两个模块：ETS通信协议栈配置及ETS算法开发。

 

ETS的通信协议栈配置就是要根据标准的要求对协议栈进行配置，针对不同的操作系统会有不同的方式，有的可能用数据库配置，有的可能将参数在文本文档里进行配置。工程师实现这些配置，既要有软件开发经验-对开发环境比较熟悉，也要对SOME/IP协议本身比较了解，还需要对测试过程和测试标准理解。因此这对综合能力是很强的考研，绝对不是啥简单的活儿。而针对此块内容，EPT在经过多位专家趟过n多坑经过两三年的摸爬滚打之后，才有了比较完善的解决方案。目前我们可以提供arxml数据库文件并提供代码工具的配置指导，也能够针对POSIX系统做文本类的参数配置。

 

ETS算法开发，是在SWC的接口函数中，进行基本的逻辑算法的实现。同样依据不同的操作系统，会有不同的开发环境。在开发环境中，对接口函数的逻辑运算主体进行编写，此处通常都是由产品开发团队的代码开发人员来做，EPT可以提供相关指导。EPT也是经过多位专家淌过n多坑服务过多家客户之后，已能够为开发人员提供清晰的开发指导了。当然如果您的开发人员太忙，我们也可以直接提供代码。

 

SOME/IP常见问题

EPT为众多客户提供过非常多的协议一致性测试服务，下面我们就简单罗列一些在SOME/IP测试中经常遇到的一些问题：

 

• UTF格式数据传输

遇到问题：UTF存在定长测试，例如64byte的定长UTF8传输，其BOM与结束符是否应该包含于64byte之内？

解决办法：UTF格式的定长传输，应将BOM和结束符包含在定长长度之中。

 

• TCP服务订阅

遇到问题：通过TCP传输的服务，客户端直接订阅该服务会被服务器NACK。

解决办法：SOME/IP的客户端与服务器的TCP连接必须由客户端建立，因此客户端订阅TCP服务之前必须主动建立TCP连接。如果TCP链接未建立而直接去订阅，则会收到服务器的NACK。

 

• 服务器休眠问题

遇到问题：SOME/IP服务器在有休眠需求时会主动断开TCP连接。

解决方法：SOME/IP协议文档规定，TCP连接应由客户端建立，且服务器不应主动断开TCP连接。从网络管理的角度出发，客户端若未断开TCP连接，意味着对服务尚有需求，此时服务器不应该主动断开TCP连接进行休眠。若服务器满足休眠状态，有休眠需求时，应发出stop offer service报文，客户端收到该消息后，需要主动发起断开连接请求，在连接全部断开后，服务器方可进入休眠状态。

 

• Session ID的处理机制问题

遇到问题：SOME/IP协议栈对Session ID字段的处理逻辑与规范要求不符。

解决方法：SOME/IP协议标准对Session ID有标准定义：Session ID是client用来标记每次call的独特标记；Session ID区分‘通信关系’，如单播和组播；Session ID区分发送和接收方的关系；错误的Session ID会导致有效的SOME/IP报文被丢弃。总结来说，Session ID应该区分不同的sockets分别计数。

 

以上介绍了SOME/IP协议的内容，包括服务发现的流程和远程调用的几种实现形式，另外也介绍了TC8 v3.0中关于SOME/IP测试用例的要求、主要测试方法、以及ETS怎么开发，文章结尾介绍了一些常见的测试会遇到的问题。

SOME/IP协议正在被国内外各主流OEM大规模应用，相信未来的使用也会越来越广泛，对SOME/IP协议的理解以及对相关测试的深入研究相信也会做得越来越好。希望看完这篇文章能帮助童鞋们解答部分疑惑，想要了解更多以太网相关知识，请在下方留言区让我看到你呀~