原创 SOME/IP概述及TC8 SOME/IP 测试实践

·开放源代码软件中的知识产权问题

虽然 这些 方案 在 任择 名单 上 是 开放 源代码,但当这些技术被采用时,就无法避免相应的知识产权和专利问题。这些开放源代码软件的知识产权一般由大型资讯科技公司持有,有不可预测的变量,即使解决了所有的技术问题,也无法完全避免这些知识产权和专利问题。这就是为什么AutoSAR联盟决定开发一个新的中间件解决方案(SOME/IP)。

因此,SOME/IP是为AutoSAR设计的。 从AutoSAR4开始,SOME/IP是AutoSAR规范系统的一部分。

SOME/IP的特征

为了满足汽车的用途,SOME/IP特别设计,其特点如下:

· 面向服务的通信

· 轻量化

-自动SAR兼容(唯一自动SAR兼容中间体)

·不同尺寸的兼容计算平台

报头格式

图1:SOME/IP字节格式

(Photo from AutoSAR SOME/IP Protocol Specification)

Message ID

Message ID的前两个字节是服务（Service）的唯一识别号，定义为服务ID。每个服务都分配了一个独特的服务ID。该服务包含了一系列方法,事件（Event）和字段（Field）。

他们有一个独特的方法ID,这是消息ID的最后两个字符,其中,0-32767是方法(包括方法,Field.Getter以及Field.Setter），32768 - 65535 for Events ( 包括 Event 和 Field 。比如，多媒体系统中的音乐播放器可以作为服务,可作为方法使用“切换到下一个轨道”。

Length

包括Request ID，Protocol Version，Interface Version，Message Type，Return Code，Payload在内的长度，占用4个字节。

Request ID

请求ID的第一个两个字母叫做客户端ID,它可以用于识别特定客户。在整车范围内，客户端ID必须是唯一的。例如,用户希望通过多功能目录模块(一个客户端)向多媒体系统发送请求,以便切换到下一个音乐。后排娱乐视频控制面板也可以提出同样的要求,因此,两个请求可以通过客户端ID来区分。

接下来的两个字符串叫做 Session ID,它可以用于识别同一客户端的多个请求。例如,多功能目录模块(客户端)不断向多媒体系统(服务端口)发送多个请求。服务端可以通过使用这个字段来区分不同的请求。而服务端也会把Request ID复制到响应消息的相同字段中，这样客户端也能通过Request ID来判断收到的响应是针对哪个请求的。

Protocol Version

SOME/IP版本编号目前为1。

Interface Version

用来识别服务接口的主版本号，由用户定义。比如当服务增加了新的功能，或者发生变更，用户可以定义新的版本号，而客户端或服务端可以通过这个版本号来自动判断兼容性。

Message Type

为了识别不同类型的讯息,目前分别有五个类型:

· REQUEST(0x00)

· REQUEST_NO_RETURN(0x01)

· NOTIFICATION(0x02)

· REPONSE(0x80)

· ERROR(0x81)

Return Code

用来表示请求是否成功处理.

Payload

包含用户定义的数据。

传输层协议

在SOME/IP中使用的传输层协议可以是TCP、UDP或SOME/IPTP。

如果数据长度超过1400字节,并且没有严格的时间延迟要求,则使用TCP传输

如果需要时间延迟(不到100毫秒),使用UDP传输

·如果数据传输长于1400字节,需要较小的延迟,则可以使用SOME/IPTP

具体使用哪一种传输层协议跟具体的应用场景有关，如果以上提到的传输层协议均不能满足需求，用户还可以选择其他协议，比如1722等。

远程过程调用(RPC)

SOME/IP客户端与服务端之间的通信支持几个机制:

有响应的方法（Method with response）

客户端发送请求消息(Request),调用方法,服务器通过响应消息(Response)返回结果给客户端。

图2：有响应的方法

无响应的方法（Method fire & forget）

客户端发送请求消息(请求),调用某种方法,而服务器不响应。

图3：无响应的方法

事件（Event）

客户端首先订阅（Subscribe）某一事件组（Event Group），当事件组中包含的事件发生时,服务端将通过Notification消息（Notify）通知客户端。Notification 消息不需要接收方进行回复，这一点有点像Fire & Forget消息。

图4：事件

字段（Field）

一个字段是客户端远程访问的服务端中的变量。

客户端可以通过远程调用Getter方法获取该字段的值,也可以通过远程调用发送方法设置该字段的值。类似于事件,当客户端加入一个事件组时,如果在事件组中包含的字段更改,服务端会主动的通过Notification消息通知客户端；当然，用户也可以选择周期发送Notification消息，这与传统的定期CAN报告类似。

Field和Event的区别是：Field是一个持续存在的变量，比如多媒体音量，内灯亮度，车速，环境温度等；而Event指的是一个事件，事件没有发生就不存在，比如发生碰撞，出现故障等。

图5：字段

SOME/IP-SD

SOME/IP-SD（Service Discovery，服务发现）是SOME/IP中的服务发现机制，客户端可以通过SOME/IP-SD定位服务,判断服务的可用性，或订阅活动组等,基于SD可以实现车内节点的“即插即用（Plug & Play）”。

SD不是传统IT行业中新事物,但当这一机制被引入汽车电子领域时,它引起了许多争议,因为内部环境相对固定,和互联网完全不同，我们可以完全固化所有配置以增加速度.但需求和技术不断动态发展。我们不能用静态的眼睛来评价技术的存在.那么SD到哪里去了?现在还很难下结论，只给时间核查。

SOME/IP协议一致性测试

OPEN Alliance的TC8是目前的标准测试标准之一,在2.Version 0中增加了SOME/IP协议的测试。

这里需要解释的是，SOME/IP本身只是中间体,它只提供几个接口,运行在它上的应用程序可以使用这些接口完成通信。所以为了验证中间体的一致性,我们必须依靠应用程序来触发中间体产生特定的行为。该应用可以成为DUT自带应用功能,或者是专门为了测试而开发的应用（也就是Test Stub）。根据申请的类型,TC8的SOME/IP测试分为两部分:

SOME/IP Server

这个测试部分取决于DUT本身的SOME/IP应用程序功能,我们将从中提取一些典型的服务和方法来验证一些基本内容,例如报告格式、基本RPC和SD机制等。

在测试中，我们通过测试系统模拟客户发送请求,并接收DUT响应。除此之外，当触发应用程序产生特定的行为时,有些测试可能需要一些特殊的手段。例如,当调用DUT来发送事件消息时,你可能需要模拟I/O输入,或者开发测试软件接口.

下面是典型的测试例,例如SOMEIPSRV_FORMAT_01,以详细说明测试过程(见 TC8,原始测试规格):

1.启动DUT服务

2.测试器监控DUT的发送端口

3. DUT发送Offer Service报文

4. 确认DUT发送的Offer Service报文的Client ID字段为0x0000

5.停止DUT服务

该测试例中的索引要求是如图6所示,也就是说,不要在SD消息中使用客户端ID,这个字段必须配置为0x00。此条测试用例检验DUT发送的SD Offer Service报文中的Client ID字段是否和AUTOSAR规范中定义的是否一致。

图6:SOMEIPSRV_FORMAT_01引用的AutoSAR要求

（图片引用自《Specification of Service Discovery》）

下面的图表显示了一些通过 Cisco TTsuite完成的SOE/IP Server测试报告和测试数据。

图7:一些SOE/IP服务器测试报告和测试数据

这里需要注意的是，对某些测试例的执行有特殊要求,例如,需要DUT实现多个服务,或者实现同一服务的多个实例。然而,DUT的实施与具体业务流程有关,不一定能满足这一要求,所以如果你想执行这些测试例,必须对现有的应用程序进行一些修改,满足测试的先决条件。

SOME/IP ETS

这部分测试突破了被测控制器自身应用的限制，能够弥补上面提到的Server测试在覆盖度方面的不足。简言之，TC8定义了一个服务，称为ETS（Enhanced Testability Service）。

ETS中包含的各种Method，Event，Field等覆盖了SOME/IP所支持的全部数据类型，并包含了一些特殊的Method，比如resetInterface（用于重启ETS服务）等。

被测控制器集成了ETS后，我们能够对SOME/IP以及SOME/IP-SD进行充分而且全面的验证。关于ETS的更多信息，欢迎垂询北汇信息来进一步了解，我们可为您提供ETS集成的咨询服务。

我们还选择了一个典型的测试例子,例如SOMEIP_ETS_21:echoINT8,它描述了ETS的测试过程(参见 TC8的原始测试规范):

1. “伪造”一个SOME/IP Request 报文，Method ID为0x000E，也就是echoINT8，在Payload中填入一个INT8类型的数据

2.发送“错误”的SOE/IP请求消息

3. DUT返回Response报文，Payload中的值和第一步中发送的值相同

如图8所示,本测试实例索引的AutoSAR要求,也就是说,SOME/IP需要支持的基本数据类型。这个测试例验证了SINT8(INT8)类型。收到测试系统仿真的SOME/IP请求后,DUT将先将请求中的 payload 重新排序,如果你得到合法的INT8数据,然后用序列填入响应消息的 payload中,这验证了INT8类型的序列函数。

图8:SOMEIP_ETS_21:echoINT8指数的AutoSAR要求

(引用自《SOME/IP Protocol Specification》)

下面的图显示了一些SOME/IP ETS测试报告和通过 Cisco TTsuite完成的测试数据。

图9:一些SOME/IPETS测试报告和测试数据

总结

人们常把车载以太网看作是一种仅仅是带宽更大的车内总线技术而已，实际上车载以太网还带来了很多更重要的变革。

例如,由汽车载入的Ethernet提供“面向服务”的架构的想法。 直到那时,只有MOST总线是为此目的设计的,由于其高成本和封闭性,目前只有少数制造商在信息娱乐部门使用MOST总线。

站在技术的角度，最优的巴士使用服务导向的设计并非无缘无故,由于信息娱乐领域所需的软件接口和数据类型往往非常复杂,近年来,在非信息娱乐领域控制网络中,类似的情况正在逐渐出现,而面向服务的架构，包括远程过程调用(RPC)，它能够很好地简化系统设计.

目前,除了发展较不乐观的MOST,其他通信方式,几乎完全是信号导向的,是专属的。包括CAN，LIN等。但近年来出现的这些新需求,这种基于信号的通信方法,与CAN相似,变得越来越不适用。随着汽车电子系统的功能不断扩大和汽车装载 Ethernet的应用,我们相信，面向服务的通讯将成为未来。

组件级的SOME/IP一致性测试在测试条件和方法方面与传统的载体通信测试不同。TC8测试标准和测试工具链在迭代和完善中,它给测试人员带来了许多挑战。测试过程中的问题需要与数据结合分析,必须积累持续的实践经验,这是作者的更深远的经验。

此外,从组件级的SOME/IP定制应用程序测试、系统级和实时级的验证的角度来看,SOME/IP测试已经模糊了传统的网络测试和功能测试的界限,这也是知识需要事先存储的新阶段。

参考文献：

《Automotive Ethernet》KIRSTEN MATHEUS and THOMAS KÖNIGSEDER

《AUTOSAR SOME/IP Protocol Specification》

《AUTOSAR SOME/IP Service Discovery Protocol Specification》