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

什么是中间件（Middleware）

在了解SOME/IP之前，我们先要了解“中间件（Middleware）”技术。简单来说，中间件是存在于操作系统和用户软件之间的一些中间层软件。它将操作系统提供的接口重新封装，并添加一些实用功能，以提供给用户软件更好的服务。

举例来说，在设计复杂的软件系统时，我们往往会设计很多互相独立的软件单元，一个很大的难题是如何在不同软件单元之间交换数据。对于开发者而言，如果在实现应用软件的同时，再把很多精力放在软件单元之间的通信上，会非常影响效率。于是我们可以设计一个“中间件”，用来管理不同软件之间的数据交互，这使得开发者不用去关心底层的通信，不同软件单元之间的“墙”变得透明。 

中间件也有它的缺点，那就是体积和对计算资源的消耗。但是随着时代的发展，硬件的计算能力不断提高，所以中间件的缺点也就不那么明显了。为了简化复杂软件系统的开发（尤其是分布式系统），提高软件的可靠性，中间件技术越来越不可缺少。除此之外，由于中间件使得用户软件和操作系统实现了“解耦”，也为测试工作带来便利。

在汽车电子领域也存在类似问题。在汽车电子的研发过程中，软件部分的占比越来越高，软件复杂度不断上升，当然ECU的计算能力也不断提升。类似传统的CAN通信——只是简单地把信号广播到总线上——越来越捉襟见肘，难以适应软件/ECU开发新要求。另外，不同的ECU可能有不同的软件架构（不同的操作系统），比如Linux、QNX或AUTOSAR，那么中间件技术将是这些不同系统之间重要的桥梁。

SOME/IP 简史

车载以太网技术伊始，AUTOSAR联盟最初的想法是直接移植现有的中间件解决方案，最好是开源的。列入备选清单的有Etch，Google Protocol Buffers，Bonjour等，理论上这些技术都可以移植到嵌入式系统这种计算能力有限的平台上，但最大的问题并不在于此。需要解决的问题是：

兼容性问题

我们知道AUTOSAR架构下有很多软件组件，它们已经实现了一些类似中间件的功能，并且可以通过专门的工具进行配置。为了避免不兼容，在集成中间件时必须绕过这些AUTOSAR 组件，或者使用完全相同的数据类型，而且需要对中间件进行重新拆分，才能“塞进”AUTOSAR的架构里。

开源软件的知识产权问题

虽然在备选清单上的这些方案都是开源的，但是当采用这些技术时却回避不了相应的知识产权及专利问题。这些开源软件的知识产权一般都掌握在大型IT公司手中，存在不可预知的变数，即便解决了所有技术问题，也无法完全避开这些知识产权及专利问题。这也是AUTOSAR联盟决定开发一个全新的中间件解决方案（SOME/IP）的主要原因。

所以，SOME/IP天生就是为AUTOSAR量身打造的。从AUTOSAR 4.1起，SOME/IP就是AUTOSAR规范体系的一部分了。

SOME/IP的特点

为了满足汽车内的应用，SOME/IP进行了特殊的设计，特点如下：

面向服务的通信

轻量化

兼容AUTOSAR（唯一兼容AUTOSAR的中间件）

适配不同规模的计算平台

报头格式

图1：SOME/IP 报头格式

（图片引用自《AUTOSAR SOME/IP Protocol Specification》）

Message ID

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

他们都有一个唯一的Method ID，也就是Message ID的后两个字节，其中0 - 32767为方法（包括Method，Field.Getter以及Field.Setter），32768 – 65535为事件（包括Event和Field.Notify）。比如，多媒体系统中的“音乐播放器”可以作为一个服务“，切换到下一曲目”可以作为一个方法。

Length

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

Request ID

Request ID的前两个字节称为Client ID，可以用来识别一个具体的客户端。在整车范围内，Client ID必须是唯一的。比如用户想要通过多功能方向盘模块（客户端）向多媒体系统（服务端）发送请求来切换到下一首音乐，而后排娱乐影音控制面板也可以做出相同的请求，那么这两个请求就可以通过Client 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/IP TP。

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

如果有时间延迟的要求（小于100毫秒），使用UDP传输

如果传输的数据长度超过1400字节，同时要求较小的延迟，可以使用SOME/IP TP

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

远程过程调用（RPC）

SOME/IP客户端和服务端之间的通信支持以下几种机制：

有响应的方法（Method with response）

客户端发送请求消息（Request）调用某一方法，服务端通过响应消息（Response）将结果返回给客户端。

图2：有响应的方法

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

客户端发送请求消息（Request）调用某一方法，服务端不回复响应。

图3：无响应的方法

事件（Event）

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

图4：事件

字段（Field）

字段（Field）是客户端可以远程访问的服务端中的变量。

客户端可以通过远程调用Getter方法获取Field的值，也可以通过远程调用Setter方法设置Field的值。另外和Event相似，当客户端订阅了某个事件组，若事件组中包含的Field发生变化，服务端会主动的通过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联盟发布的TC8是目前行业内关于车载以太网的标准测试规范之一，在2.0版本中加入了对SOME/IP协议的测试。

这里需要解释的是，SOME/IP本身只是中间件，它仅提供了若干接口，运行在其上的应用可以使用这些接口来完成通信。所以为了验证中间件的一致性，我们必须依赖应用来触发中间件产生特定的行为。这个应用可以是DUT自带的应用功能，或者是专门为了测试而开发的应用（也就是Test Stub）。按照应用类型的不同，在TC8中SOME/IP的测试分成以下两个部分：

SOME/IP Server

这部分测试依赖DUT自身的SOME/IP应用功能，我们会在其中抽取一些典型的服务、方法，用来验证一些比较基础的内容，比如报文格式，基本的RPC和SD机制等。

在测试中，我们通过测试系统来仿真客户端发送请求，并接收DUT的响应。除此之外，在触发应用产生特定行为时，部分测试可能需要某些特殊手段。比如在触发DUT发送Event报文时，可能需要仿真I/O输入，或者开发一个测试用的软件接口。

下面我们通过一条典型测试用例，比如SOMEIPSRV_FORMAT_01，来具体说明测试过程（测试规范原文可参考TC8）：

启动DUT的服务

Tester监听DUT的发送端口

DUT发送Offer Service报文

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

停止DUT运行的服务

在这条测试用例中索引的需求为如图6所示，即在SD报文中不使用Client ID，必须将这个字段配置为0x0000。此条测试用例检验DUT发送的SD Offer Service报文中的Client ID字段是否和AUTOSAR规范中定义的是否一致。

图6：SOMEIPSRV_FORMAT_01引用的AUTOSAR需求

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

下图展示了通过思博伦的TTsuite 完成的部分SOME/IP Server测试报告与测试数据。

图7：部分SOME/IP Server测试报告与测试数据

这里需要注意的是，有些测试用例的执行有一些特殊要求，比如要求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）：

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

发送“伪造”的SOME/IP Request 报文

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

这条测试用例索引的AUTOSAR需求如图8所示，即SOME/IP需支持的基本数据类型。在这条测试用例中验证了SINT8（INT8）类型。收到测试系统仿真的SOME/IP请求后，DUT首先会将请求中的Payload进行反序列化，如果得到了一个合法的INT8数据，那么再将这个数据通过序列化填入响应报文的Payload中，这样就验证了INT8类型的序列化功能。

图8：SOMEIP_ETS_21: echoINT8索引的AUTOSAR需求

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

下图展示了通过思博伦的TTsuite 完成的部分SOME/IP ETS测试报告与测试数据。

图9：部分SOME/IP ETS测试报告与测试数据

总结

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

比如车载以太网提供的“面向服务”的架构思想。在此之前只有MOST总线才有这种设计，而受制于高昂的成本以及封闭性，目前仅有少数几家厂商在信息娱乐域使用了MOST总线。

站在技术的角度，MOST总线使用面向服务的设计不是没有原因的，因为信息娱乐域所需要的软件接口和数据类型往往十分繁杂，而近些年来在非信息娱乐域的控制器网络中，类似的情况也逐渐显现，而面向服务的架构，包括远程过程调用（RPC），能够很好地简化系统设计。

目前除了发展不太乐观的MOST，其他几乎全被面向信号的通信方式独占了，包括CAN，LIN等。但是近些年来兴起的这些新需求，类似CAN的这种面向信号的通信方式已经越来越不适用了。随着汽车电子系统的功能不断丰富以及车载以太网的应用，我们相信，面向服务的通信将是未来。

部件级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》