接口参数验证,接口参数动态变化

2022-07-31 17:53:14 经济时评

　　随着汽车新四化的推进，汽车主机厂在实现车联网、自动驾驶、数据驱动的同时，不得不在满足用户体验和基础服务的基础上，快速响应客户的个性化需求。为了更好地解决这些新的挑战，OEM厂商推出了高性能芯片和突破性技术产品，同时，传统的EE架构也需要改变。SOA(面向服务的架构)已经成为大多数OEM响应市场需求的首选架构。SOA的主要优势在于它可以在很大程度上解耦分布式系统的软件模块。通过升级OTA，在任何域控制器上部署服务实体都更加方便灵活。服务只需要通过简单准确定义的接口进行通信，不涉及底层编程接口和通信模型。而且ECU版本更新、信号库更新、代码修改的过程更加简单灵活。简化了注册服务和API调用，节省了时间和成本，提高了系统的健壮性和可扩展性。　　

　　SOA开发和部署步骤 　　

　　设计和部署SOA汽车软件可以大致分为以下几个步骤：3360 　　

　　图1 SOA开发部署步骤 　　

　　在界面开发阶段，往往需要选取大量规则固定、逻辑性强、重复度高的场景进行测试验证。为了快速验证，架构工程师通常使用IDL(接口描述语言)来描述服务定义，作为开发环节后续工作的输入。在业务逻辑开发阶段，服务以统一的标准实现。　　

　　市面上有很多IDL语言，如FIDL、Protobuf、vCDL、ARXML、OMG IDL、CANoe FDX等。测试人员需要从零开始学习各种IDL语法规则，转换过程中相应的操作复杂繁琐，错误率也很高。　　

　　如果软件架构采用SOA，服务于系统的功能，那么在前期的技术选择、清单定义、架构设计和中期的业务逻辑开发阶段，会出现如下几种场景。　　

　　场景一 　　

　　架构师使用PREEvision Adaptive AUTOSAR对系统建模并定义服务相关的SWC后，通常会导出不同类型的ARXML，ARXML定义了服务接口、数据类型、参数引用等。这些AP ARXML可以导入CANoe进行节点模拟和监控以太网通信，同时也支持导入达芬奇IDE生成的代码，用达芬奇开发。但是这个建模过程不是短时间能完成的，需要不断的沟通协调，考虑方便。在沟通过程中，相关方会使用Excel作为沟通输入，最后将Excel中的配置信息转换成ARXML，导入相关工具进行验证。　　

　　图2-1 接口和数据类型定义Excel 　　

　　图2-2 接口和数据类型定义Excel 　　

　　如上面简单的例子所示，结构引用、数据类型等信息。容易出错，并且在转换成ARXML之前经常需要反复修改。这个过程费时费力，从效率的角度也影响了软件的开发进度。　　

　　场景2 　　

　　测试以太网(以SOME/IP为例)时，开发人员输出Excel，测试人员需要将Excel转换成测试软件可以支持的文件格式，比如vCDL。这个环节工作量巨大，准确率无法保证。　　

　　图3-1 以太网测试接口定义Excel 　　

　　图3-2 以太网测试接口定义Excel 　　

　　场景3 　　

　　开发者在使用达芬奇进行架构设计时，为了加快开发周期，通常会先使用Excel作为模板，填写接口信息、数据类型、SWC定义、SWC和接口关系，然后由模块所有者在达芬奇开发者中对Excel中的数据进行相应的节点配置和连接关联。整个过程出错概率大，重复性高，需要工具根据Excel模板文件自动生成ARXML文件，实现SWC的转换和界面与SWC的结合，提高设计效率。　　

　　场景4 　　

　　在SOA架构中，中间件技术的应用使得应用软件和底层操作系统和硬件　　

件实现了解耦，我们可以使用 SIL （Software in loop）技术在系统开发早期对系统进行功能验证。SIL 测试的一个重要环节是 SIL Adapter 开发。SIL Adapter 实现了测试系统对被测服务实现的调用。针对各个服务接口的 SIL Adapter代码结构是相同的，只是接口参数数量、名称、类型方面有少量代码差异，整个过程重复性也较高，需要有工具能自动将架构设计产出的FIDL、XML、ARXML等文件自动转化为C++等代码，同时能根据文件中的描述/备注等内容自动生成插桩代码，这将缩短验证周期。

场景5

SOA架构设计、测试验证等阶段，工程师在使用相关工具软件时，会使用许多配置文件作为输入或输出文件，但是鉴于使用的工具众多，且文件格式之间的标准并不统一，所使用的各个开发工具及测试工具也并不能支持所有的格式，所以各个工具间的串联并不流畅，影响工程师的工作效率，需要有工具能自动将这些不同格式的文件进行互相转换以实现工具的高效串联。

场景6

测试用例通常是在Doors或Polarion中管理，测试用例中的测试步骤或测试标准正常是以自然语言的方式描述，在测试执行过程中软件无法识别这些描述性语言，测试人员需要先将这些自然语言转换为脚本文件，再把测试脚本放到测试工程中执行，在测试用例较多的时候这个工作量将会非常庞大，需要有工具能集成相关用例管理软件，将测试用例能自动转换为相应的测试软件的脚本文件，在提高效率的同时减少出错机率。

场景7

SOA测试开发过程大体上需要进行以下几个步骤：

1.测试规范开发：基于需求规范和测试经验及对实现方案的理解，完成测试规范的开发。

2.SOA-HIL 测试系统需求分析和测试系统开发：被测对象的引脚和资源定义，HIL硬件及测试软件运行环境搭建。

3.测试工程开发：开发测试工程，实现测试规范所定义的测试内容的自动化/半自动化测试。

4.仿真模型开发：开发仿真模型，与待测节点建立接口交互。

5.测试环境集成调试与测试执行：针对某一具体被测对象进行测试环境搭建、工程集成调试与测试执行。

以上各个步骤中所需的输入物类型较多，如：SOA功能的需求规范、服务接口规范，资源定义文件，测试范围定义，ARXML 等类型数据库文件，测试系统第三方编程脚本，测试规范，通信数据库，通信矩阵文件，被测节点交互数据格式定义等，需要有工具能够按测试项目进行统一分类管理，同时能够支持相关输入物间进行格式转换，转换后的结果能够便捷地加载到相关的测试软件中或能够通过网络自动上传到配置库的对应位置下方便后续操作。

场景8

目前SOA架构软件普遍采用敏捷开发方式进行管理，软件版本的高频迭代极大考验了测试人员工作量和自动化测试能力，目前大多整车厂和零部件供应商基本上已在进行或正在研案持续集成测试方案来解决这一问题。

如下图所示，随着SOA架构的盛行，输入物或规范文件已经出现了多样化，但是持续集成测试推进的前提条件是需要预先将这些测试软件不可识别的接口文件或用例文件转换为符合测试软件定义的规范脚本，并且能够与相关的工具进行集成自动转换。

图4 持续集成测试文件转换需求示意图

为什么需要接口描述语言转换

以上几个场景都需要测试人员手动录入或转换后才能继续推动项目进度，此环节尤为关键，但往往转换周期较长，且该工作耗时又费力，出错率也较高，导致经常返工，这些问题一直困扰着的开发/测试人员。

PAVELINK.

SOA-Converter介绍

针对以上问题，北汇信息开发出了接口描述语言转换工具――PAVELINK.SOA-Converter。

PAVELINK.SOA-Converter是一个基于Eclipse开发的IDL转换工具。可实现对常用IDL语言的批量转换（FIDL、OMG IDL、Protobuf、vCDL、CANoe FDX、ARXML等），例如FIDL转CANoe FDX，FIDL与Protobuf互转，同时也支持直接通过Protobuf转换CANoe FDX等便捷的转换功能，转换前可根据用户需求自定义输出目录、是否忽略注释信息、是否批量转换、是否转换为多个文件等配置。

PAVELINK.SOA-Converter结合测试代理引擎进行自动化回归测试，可以解决整个链路的沟通问题并缩短测试验证的时间。

用户通用使用PAVELINK.SOA-Converter实现对文件的快速转换，相较于人工转换，不但很大程度上节约了时间成本，而且保障了转换的正确率，提高了开发测试的进度，同时有效降低了维护的成本。