SOA架构盛行
随着汽车新四化的推进，汽车整车厂在实现车辆网联、自动驾驶和数据驱动的同时，更要在满足用户体验和基本服务的基础上快速响应客户的个性化需求，为更好地解决这些新的挑战，整车厂引入了高性能的芯片、突破性的技术产品，同时传统的EE架构也需要变革，SOA（面向服务的架构）成为大多整车厂响应市场需求的首选架构。

SOA架构的主要优势是可以在很大程度上实现分布式系统软件模块间的解耦，通过软件升级OTA可以更方便灵活地将服务实体部署在任意的域控制器上，服务之间只需通过简单、精确定义的接口进行通讯，不涉及底层编程接口和通讯模型。而且对于ECU的版本更新、信号库更新、代码修改等过程更加简便和灵活。简化了注册服务与调用API，节约了时间成本，提高系统的健壮性和扩展性。

文章目录

SOA开发和部署步骤
- 场景一
- 场景二
- 场景三
- 场景四
- 场景五
- 场景六
- 场景七
- 场景八
为什么需要接口描述语言转换
PAVELINK.SOA-Converter介绍
- 主要功能
PAVELINK.SOA-Converter使用说明
- 1. Eclipse 插件转换
- 2. 命令行转换
- 3.示例说明
- 更多功能，敬请期待

SOA开发和部署步骤

设计和部署一个SOA汽车软件大概可分为以下几个步骤:

图1: SOA开发部署步骤

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

市面上的IDL语言非常多，例如FIDL、Protobuf、vCDL、ARXML、OMG IDL、C++、CANoe FDX等。测试人员对于各种IDL的语法规则需要零基础开始学习，在转换过程中相应的操作也比较复杂、繁琐，同时出错率也很高。

如果软件的架构采用了SOA，对系统中的功能进行了服务化，在前期技术选型，清单定义、架构设计以及中期的业务逻辑开发阶段都会碰到诸如以下的几种场景。

场景一

架构人员在使用PREEvision Adaptive AUTOSAR进行系统建模、定义服务相关SWC后，通常会导出不同类型的ARXML，该文件定义了各服务接口、数据类型、参数引用等，这些AP ARXML可导入到CANoe中进行节点仿真和监控以太网通信，也支持导入DaVinci IDE生成代码，配合DaVinci进行开发。但是这个建模过程短期内无法完成，需要不停地沟通协调，考虑便捷性，在沟通过程中相关方会以Excel作为沟通输入，最终会将这些Excel中的配置信息再转换为ARXML导入到相关的工具中进行验证。

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

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

如上图简单示例，其中结构体引用，数据类型等信息容易出错，时常需要反复修改后再重新转换为ARXML，这个过程费时费力，从效率角度来说也影响了软件的开发进度。

场景二

以太网测试（以SOME/IP为例）时，开发人员输出的是Excel，测试人员需要再把Excel转成测试软件可以支持的文件格式，如vCDL，此环节工作量极大，正确率也无法保证。

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

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

场景三

开发人员在使用DaVinci做架构设计时，为了加快开发周期，通常情况下会先使用Excel做模板，在Excel中填入接口信息、数据类型、SWC定义、SWC与接口关系等信息，然后再由模块责任人把Excel中的数据在DaVinci Developer中做相应的节点配置和连线关联，整个过程出错概率高并且重复性高，需要有工具能依据Excel模板文件自动生成ARXML文件，实现SWC的转换及接口与SWC结合工作，用以提高设计效率。

场景四

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

场景五

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

场景六

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

场景七

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

测试规范开发：基于需求规范和测试经验及对实现方案的理解，完成测试规范的开发。
SOA-HIL 测试系统需求分析和测试系统开发：被测对象的引脚和资源定义，HIL硬件及测试软件运行环境搭建。
测试工程开发：开发测试工程，实现测试规范所定义的测试内容的自动化/半自动化测试。
仿真模型开发：开发仿真模型，与待测节点建立接口交互。
测试环境集成调试与测试执行：针对某一具体被测对象进行测试环境搭建、工程集成调试与测试执行。

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

场景八

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

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

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

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

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

PAVELINK.SOA-Converter介绍

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

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

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

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

图5: PAVELINK.SOA-Converter工作示意图

主要功能

接口语言脚换器: 通过接口语言转换实现基于SOA架构的软件设计开发过程中各工具链间的连通。
接口语言编辑器: 通过搭建多个接口语言集中一站式编辑环境，可以实现对接口文件的二次编辑转换，同时实现语法校验、关键字提示和补全等功能。
命令行转换器: 提供无头(headless)跨平台的命令行工具，支持命令行调用转换功能。
配置库集成: 集成配置库，自动同步文件，更新提醒，当有源文件更新后实现自动转换为目标文件。
开放调用接口: 通过文件流监听方式与外部工具集成，为自动化测试提供便利。
插件灵活拓展: 通过插件的灵活拓展，快速实现新的脚本语言转换。
SOA通信方案拓展: 通过对接口描述语言的解读，自动转换为服务端(Skeleton)和客户端(Proxy)框架代码等。

PAVELINK.SOA-Converter使用说明

PAVELINK.SOA-Converter的使用操作十分便捷，在Eclipse中只需要点击鼠标，或者使用简单的命令即可完成转换工作。

1. Eclipse 插件转换

在Eclipse中安装好插件，选择文件后右击->SOA-Converter->选择需要转换的格式类型即可。

图6: PAVELINK.SOA-Converter图形化示意图

2. 命令行转换

也可通过命令执行转换。

常用参数说明:

[-sf]指定转换的源文件类型。
[-tf]指定转换后生成的文件类型。
[-sp]指定需要转换的文件或位置。
[-d]指定转换后文件输出位置。
[-dv]忽略版本校验。

图7: PAVELINK.SOA-Converter命令行示意图

3.示例说明

某OEM 基于SOA架构的服务接口测试项目，使用PAVELINK.SOA-Converter实现FIDL转CANoe系统变量XML，简化测试验证过程。

图8: FIDL转CANoe系统变量示例

转换完成后，按步骤在CANoe中直接导入转换后的XML文件即可，如下图。

图9:转换后的系统变量XML文件导入CANoe软件示例

CCU域控制器的测试规范、脚本开发及测试服务，使用PAVELINK.SOA-Converter实现FIDL转SOA功能实现服务端和客户端C++代码示例。

图10: SOA通信实现节点示意图

如上图所示，调用PAVELINK.SOA-Converter转换PREEvision等设计工具输出的服务接口文件，生成对应的Proxy、Skeleton、Stub代码。

图11: 服务接口文件转换C++示例图

某供应商网联类控制器SOA功能规范测试开发项目，使用PAVELINK.SOA-Converter实现Excel转ARXML，接口和SWC关联示例

图12: Excel模板示意图

转换后ARXML内容如下：

图13: ARXML截图示意

SOA架构/测试阶段接口描述语言转换方案相关推荐

基于AgileEAS.NET企业应用平台实现基于SOA架构的应用整合方案-开篇
为什么80%的码农都做不了架构师?>>> 开篇系统架构的文章,准备在这段时间好好的梳理和整理一下,然后发布基于AgileEAS.NET平台之上的企业级应用架构实践,结合具体的 ...
论SOA架构的几种主要开发方式
论SOA架构的几种主要开发方式面向服务架构soa以其独特的优势越来越受到企业的重视,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署.组合和使用.服务层是SOA的基础,可以直接被应用调 ...
[转]论SOA架构的几种主要开发方式
面向服务架构soa以其独特的优势越来越受到企业的重视,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署.组合和使用.服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理 ...
转换实体类_yue-library 2.3.0发布，替换Db JavaBean转换方案，性能提升约300%+
yue-library简介 yue-library是一个基于SpringBoot封装的增强库内置丰富的JDK工具自动装配了一系列的基础Bean与环境配置项快速构建SpringCloud项目,让微 ...
《浅谈整车SOA架构》终篇：整车SOA系统设计
<浅谈整车SOA架构>终篇:整车SOA系统设计参考链接: 1.https://zhuanlan.zhihu.com/p/330973653 2.<浅谈整车SOA架构>第1篇: ...
单体架构--＞SOA架构--＞微服务架构
上诉架构图采用了分层架构,按照调用顺序,从上到下为表示层.业务层.数据访问(DAO)层.DB层.表示层负责用户体验,业务层负责业务逻辑,包括电影.订单和用户三个模块.数据访问层负责DB层的数据存取,实 ...
SOA架构设计经验分享—架构、职责、数据一致性
1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DDD+GRAS ...
T系统和应用集成-从SOA架构思想到服务架构规划设计
T系统和应用集成-从SOA架构思想到服务架构规划设计原创人月聊IT 2020-09-23 13:48:20 作者:人月神话,新浪博客同名简介:多年SOA规划建设,私有云PaaS平台架构设计经验, ...
分布式与微服务——Iaas，Paas和Saas、单体应用和缺点、微服务概念、传统分布式 SOA 架构与微服务架构的区别、微服务实战、什么是RPC、CAP定理和BASE理论、唯一ID生成、实现分布式
文章目录 1-什么是Iaas,Paas和Saas 一 IaaS基础设施服务二 paas平台即服务三saas软件即服务四总结 2-单体应用和缺点一单体应用二单体应用的缺陷 3-微服务概念 ...

SOA架构/测试阶段接口描述语言转换方案