李志涛， 姬志博， 耿伟峰

（长城汽车股份有限公司技术中心， 河北 保定 071000）

随着汽车电子技术的发展与智能网联汽车产业大变革，汽车硬件体系逐渐趋于一致， 软件定义汽车的趋势逐步被行业认可， 软件成为汽车开发的关键。 汽车高级驾驶辅助系统 （ADAS）、 高性能车载娱乐系统、 车联网系统及云服务等新技术已在车辆上应用， 使得车辆上的软件变得越来越复杂。 而传统汽车采用的分布式E/E架构因计算能力不足、 通信带宽不足、 不便于软件升级等瓶颈， 已经不能满足现阶段汽车发展的需求， 需要一种新的软件开发方法来打破僵局， 于是， SOA设计理念应用于软件开发中， 新型的车载通信架构由传统的CAN/LIN 总线向车载以太网总线方向发展， 以满足车辆高速、 低延迟等性能需求。 同时，汽车行业对可靠性和安全性要求越来越高， 车载以太网在应用的过程中， 为了保证其可靠性与安全性， 就迫切需要对其开展测试工作。

1 SOME/IP协议概述

在IT行业， SOA软件开发方式已经很普及， 用来满足用户的多样化需求及敏捷开发的要求。 在汽车行业， 随着车辆功能的持续增加， 功能开发需更加高效， 功能集成需更加便捷， 功能增加及升级更加灵活， 因此引入SOA软件开发方式， 来满足日益复杂的功能增长的需求。

SOA即面向服务的架构， 是一种软件架构设计的模型和方法论， 它将应用程序的不同功能单元 （服务， 包含各种控制算法和应用程序）， 通过服务之间定义良好的接口和契约联系起来， 通过服务订阅与推送的方式建立动态的通信关系。 在汽车软件开发中， 通过基于软件的模块化和以太网的通信， 提供标准的服务组件， 使软件与硬件解耦，从而可以灵活地设计和扩展上层的应用。 总之， 通过构建灵活可变的平台系统， 实现服务间松耦合、 无状态、 无依赖； 服务内高内聚且完整、 可复用、 可灵活重组； 服务通信标准化。 从中可看到服务通信标准化是SOA实现的重要环节， 而SOME/IP是实现服务通信标准化的一个中间件协议， 也是车载以太网技术中的核心内容。

SOME/IP 全称为Scalable service-Oriented MiddlewarE over IP， 是一种面向服务的可伸缩的协议。 宝马公司开发了SOME/IP协议并在AutoSar标准中进行了车载应用的相关规范定义， 该通信协议是面向服务的通信协议， 不同ECU之间通过Client/Server的方式进行通信， 数据只在有需要的时候进行传输， 有效降低了总线负载， 其适配不同规模的操作系统且具备轻量化特性， 在车载以太网协议中得到广泛应用。

2 SOME/IP协议解析

车载以太网协议架构对应OSI参考模型， 主要分为物理层、 数据链路层、 网络层、 传输层、 应用层， 每一层都有各自的功能， 车载以太网及其支持的上层协议的技术架构见图1。

图1 车载以太网协议技术架构

SOME/IP协议位于OSI 7层模型的应用层。 该协议存在于操作系统和用户软件之间， 将操作系统提供的接口重新封装， 并添加一些实用功能， 可用于控制消息及应用数据传输， 提供给用户软件更好的服务， 是SOA架构的重要支撑。

基于SOME/IP协议通信的电气架构， ECU根据功能需求的 不 同， 划 分 为Client （客 户 端） 和Server （服 务 器）。Server 通过SOME/IP 的服务接口Service Interface 向Client提供服务， Client也通过服务接口向Server请求服务。 SOME/IP通信机制大致可以划分为服务发现、 远程过程调用、 访问进程数据。

2.1 服务发现

服务发现的通信机制是通过SOME/IP-SD来实现的， 主要是为了在车载通信中告知服务实例的可用性及其访问方式， 通过Find Service和Offer Service 消息实现，见图2。 服务发现通信机制的主要作用， 用于客户端寻找、 了解可订阅或调用的服务实例状态、 服务实例访问信息等内容； 同时服务器端， 可告知其它节点它可以提供的服务， 以及检测到提供的服务出现问题时， 告知接收方做出相应的处理。

图2 Find与Offer Service

2.2 远程过程调用

远程过程调用机制分为Method、 Event， 见图3。 Request/Response通信是最常见的通信模式之一， 通过SOMEI/IP协议实现， 主要用于实现客户端发送请求消息， 服务器端收到请求， 处理后进行响应； Fire&Forget通信是一种请求但不需要回复的机制， 也是通过SOME/IP协议实现， 实现客户端向服务端发送请求， 服务端接收请求并进行处理， 不返回响应消息。 Notification Events通信主要描述了发布/订阅消息内容， 用于实现客户端向服务端订阅需要的事件组，当事件发生或值更新时， 服务器端需要向客户端发送更新的内容。

图3 Method与Event

2.3 访问进程通信

访问进程通信机制主要是对应用程序数据 （Field） 的配置， 见图4。 客户端进行数据的获取和设置， 客户端可以远程访问的服务端中的变量， 通过SOME/IP协议实现， 实现客户端通过Getter方法获取值， 通过Setter方法设置值。Getter/Setter使用的是请求/响应机制调用。 使用Getter时， 请求消息中是空的有效载荷， 响应消息中的有效载荷是获取的值， 使用Setter时， 请求消息中的有效载荷是需要设置的值， 响应消息中的有效载荷是设置成功的值。 与Event相比而言， Field是一个持续存在的变量， 而Event指的是一个事件， 事件没有发生就不存在。

图4 Field配置

SOME/IP通信机制主要定义了车载ECU信息交互的收发逻辑、 数据传输规则， 在测试阶段需依据通信协议、 功能规范等内容来确定消息的收发逻辑， 数据交互行为是否正确， 故熟悉SOME/IP的通信过程与通信机制对车载以太网测试至关重要。

3 SOME/IP协议测试

对于整车测试来说， 最常采用的是V模型的验证方式。参 考V 模 型， SOME/IP 协 议 测 试 划 分 为3 个 层 级， 分 别 为ECU级测试、 系统级测试与实车级测试。 在ECU级测试，主要开展SOME/IP协议一致性测试， 验证ECU协议的符合性； 系统及实车级测试， 主要开展SOME/IP系统通信测试， 验证SOME/IP系统配置需求的正确性及自定义需求的符合性。

3.1 SOME/IP协议一致性测试

车载以太网控制器的SOME/IP协议一致性测试， 主要基于OPEN Alliance中的TC8规范开展。 测试内容分为两大部分： SOME/IP Server测试和SOME/IP ETS 测试， 协议一致性测试示意见图5。

图5 协议一致性测试

SOME/IP Server 测试依赖于被测DUT的SOME/IP应用功能， 从中选取一些典型的服务、 方法， 在测试中， 应用测试系统仿真客户端发送请求， 接收DUT的响应。 除此之外， 在触发应用产生特定行为时， 部分测试可能需要某些特殊手段， 如触发DUT发送Event报文时， 需要I/O仿真输入等。 SOME/IP Server主要测试内容为验证被测控制器是否具备最基本的offer报文发送和响应请求的能力， 服务发现报文的报头格式、 服务报文载荷中的选项排列格式、 各种服务报文及其功能、 控制器建立连接后的各阶段的通信行为， SOME/IP的基本功能定义与线性格式、 远程调用协议机制等。

SOME/IP本身只是中间件， 它提供了若干接口， 运行在其上的应用可以使用这些接口来完成通信， 为验证SOME/IP协议的一致性， 需要依赖应用触发SOME/IP产生特定的行为。 SOME/IP ETS这部分测试需要借助TC8定义的ETS （Enhanced Testability Service） 服 务， 补 充SOME/IP Service 测试中的未覆盖的测试需求。 在ETS 中包含各种Method、 Event、 Field等， 覆盖了SOME/IP所支持的全部数据类型， 被测控制器集成了ETS 后， 能够对SOME/IP 及SOME/IP-SD进行充分而且全面的的验证， 对SOME/IP服务发现、 序列化等进行测试， 验证不同类型数据长度异常处理、 字节顺序与位域的发送接收、 不同类型数据相应参数的发送和接收、 通信行为的处理机制等。

SOME/IP协议的一致性测试， 是SOME/IP通信测试的基础， 各种数据类型及通信行为的符合性及一致性， 利于后续服务功能的扩展及配置， 是实现功能服务通信及系统交互的关键。

3.2 SOME/IP通信测试

SOME/IP 通信测试迥异于SOME/IP 协议一致性测试。SOME/IP通信测试， 基于应用SOME/IP协议通信的功能系统开展测试， 侧重于通信接口、 信息交互行为等方面的测试。SOME/IP通信测试对应用SOME/IP通信的功能服务开展测试验证， 依据OEM定义的SOME/IP接口矩阵与服务功能的流程图， 在系统或实车环境下， 采用Vector公司的VN5640工具监测系统中各个以太网链路的通信数据， 进行测试数据分析与测试结果的判定。 SOME/IP通信测试连接示意见图6。

图6 SOME/IP通信测试连接示意图

SOME/IP系统测试时， 通过人工操作用户功能， 触发被测ECU发送SOME/IP通信信息， 验证SOME/IP协议通信服务的接口、 发送时序、 发送数据值、 时间参数的正确性，系统交互时的SOME/IP通信交互逻辑、 性能要求等。

SOME/IP协议测试， 各层级测试内容与测试目标不同，同时与传统总线测试方面也有一定的差异。 SOME/IP协议一致性测试在测试条件和方法上与传统车载通信测试迥然，而且TC8测试规范以及测试工具链都处于迭代和完善中， 测试过程中的问题需要结合数据进行分析， 需不断积累实践经验。 SOME/IP系统通信测试， 重在服务功能应用的测试，测试过程中需要从功能使用的角度， 触发SOME/IP通信报文， 验证SOME/IP信息交互行为、 机制， 对于功能逻辑，触发方式需要熟悉， 同时需掌握SOME/IP报文数据类型及理解参数含义。

4 SOME/IP通信测试实例

SOME/IP协议一致性测试， 参照TC8规范， 同时可添加OEM自定义测试项开展测试， 在此不再赘述。 SOME/IP通信测试， 该部分测试与功能应用紧密相关， 将各种功能以服务的形式提供给最终用户或者其他服务， 将相关联的一组信号或者功能执行所需要的参数合集， 整体定义为一个服务。 通过以太网将所有功能执行需要的信息全部封装在一个服务中。 上层应用只要调用此服务接口， 即可实现对功能控制。

以T_BOX紧急救援电话功能为例， T_BOX为服务提供方 （Server）， HUT为服务订阅方 （Client）。 系统启动后，HUT订阅T_BOX紧急救援电话功能服务， 实现服务的注册。当紧急救援开关按键触发紧急救援服务后， T_BOX发送紧急救援电话信息 至HUT， 按2s 周期持续发送 给HUT， 在HUT 屏幕上显示紧急救援电话信息界面，直至紧急救援事件退出或电话挂断， 取消屏幕上的信息显示， 紧急救援功能信息交互示意见图7。

图7 紧急救援功能信息交互示意图

通过使用Vector公司的VN5640测试工具， 测试HUT和T_BOX的通信机制及在紧急救援激活的数据传输。系统上电运行后，T_BOX发送MessageId为0xFFFF 8100的SOME/IP-SD（Offer） 报文， 提供了ServiceID=0x0201的服务， 从此报文的IPv4 Endoption字段描述可以看出， 该服务位于IP 地址为172.16.12.97， 传输协议采用UDP， 端口号为55000， 该消息清楚地描述了T_BOX可以提供的服务ID和该服务的位置。HUT收到此消息后， 立刻发送Subscribe的SOME/IP-SD报文，请求在T_BOX的注册中心实现订阅注册， T_BOX收到此消息 后， 通 过Subscribe Acknowledge 回 复HUT， 成 功 完 成 订阅。 服务发布订阅测试结果见图8。

图8 服务发布订阅测试结果

激活紧急救援电话功能， 触发紧急救援按键开关，T_BOX 发出紧急救援电 话信息 （T_BoxCallState） 至HUT，T_BoxCallState以2s周期持续向HUT发送该信息， 直至救援电话挂断或再次按键退出。 该消息的ServiceID=0x0201，Method ID=0x8001， 相关参数与设计要求相同， SOME/IP通信测试结果见图9。

图9 SOME/IP通信测试结果

车载以太网通过SOME/IP的通信方式， 将功能转化为服务， 以服务形式进行数据的传递， 通过订阅和发布的方式或者请求/响应的方式， 实现灵活的调度。 因此， SOME/IP通信测试， 既要测试人员掌握SOME/IP协议通信机制、 交互行为， 还要熟悉车辆功能逻辑， 同时具备相应的功能感知、 评价等综合能力。

5 结束语

车载以太网推进了车辆智能化的发展。 未来， SOME/IP在车载以太网方面的应用将越来越广泛。 车载以太网SOME/IP测试， 涵盖总线协议、 系统通信， 关联车辆电器性能、 功能等多个方面， 其测试工作是一个系统、 庞大的工程， 需要测试工程师具备多种专业知识、 测试理论与技能。 因此， 需对车载以太网SOME/IP协议的测试进行深入研究， 构建相应的测试能力与测试体系。