传统V型开发流程向DevOps开发流程转换

一

传统V型开发流程向DevOps开发流程转换

伴随着汽车行业向新四化的推动，车辆的功能越来越丰富，车内控制器的软件迭代速度更是不断提升，从智能座舱、信息娱乐到先进驾驶辅助系统，消费者希望这些功能像手机应用一样时刻保持最新，导致汽车软件开发由V型开发流程转向DevOps敏捷开发，以帮助软件团队缩短开发周期，加速软件迭代。    DevOps全称Developemt and Operations，提倡Continueous Integration(持续集成)，CT(持续测试)，CD(持续交付)，通过工具平台使得构建、测试、发布软件能够更加的快捷、频繁和可靠。”

  为应对流程转变上的挑战，开发团队可将软硬件解耦后，硬件和软件的部分各自按照独立时间线来开发，并在进行软件更改后无需对整个车辆进行重新验证，纯软件的开发和验证过程从原型车或者硬件在环测试过渡到软件在环(SIL)的测试验证。这种软硬解耦的方式同时也迎合了当下将ECU功能整合到中央计算单元或域控制器的趋势，在多合一控制器融合的过程中发挥作用，软件模块可以在不同的硬件平台运行, 并在车辆整个生命周期内更新。

二

软件在环的应用场景

快速变更的功能需求下敏捷开发及快速迭代。

尽早进行软件验证并发现和纠正代码中的重要错误，特别是涉及安全相关的错误。

在高频率OTA云端升级软件的情况下自动化持续验证。

在以上场景下软件在环SIL测试能够脱离硬件而快速验证控制器的功能代码。

软件在环（SIL）包括三个部分：虚拟控制器（vECU）、被控对象模型或环境模型（Plant Model）及联合仿真平台(Simulation Middleware Platform)。

三

什么是虚拟ECU

虚拟ECU简称vECU，表示脱离真实硬件依赖后基于PC独立编译和运行的软件，vECU所包含的内容通常可由ASW,vBSW,vCDD以及RTE这几个部分构成，在集成编译后封装成基于PC的可执行文件。

对于功能测试验证工程师，通常他会拿到一个带有软件的完整ECU，在硬件在环或实车环境下进行测试，整个测试过程可能受硬件和线束的限制，每当遇到软件的失效首先考虑线束或者硬件通信上的问题，测试效率受硬件条件限制，难以高效的完成测试任务。但对于ECU内与硬件无关功能，解耦ECU代码后生成vECU即可运行在PC上直接测试目标代码，数据采集和验证过程同真实环境软件测试工具一致，如INCA、Debugger调试器等。

对功能开发工程师来说，验证功能时需要在完整ECU软件上进行集成并验证功能，该集成过程通常由软件集成工程师负责，软件集成工程师在集成该功能同时还需考虑ECU平台化bugfix,底层芯片配置等方方面面因素，导致反馈过程冗长，迭代效率低效的问题。其实对于生成的ECU功能代码，依然将这一部分代码封装成一个vECU并进行仿真测试，可以在任意时间终止仿真并进行Debug，还可以在功能验证过程中根据需要对vECU做预标定从而提前验证预设数据。

随着vECU复杂程度的逐步提升，vECU使用场景也会越来越多。如下图中随着虚拟化和自动化程度提升，vECU使用场景能逐步过渡到第二和第三个阶段。

简而言之，就是将控制器C代码基于PC环境编译后生成FMU格式的可执行文件运行在常规PC仿真环境上，以更早和更快的方式进行测试及调试。

四

虚拟控制器vECU的分类

生成虚拟控制器的方式有两种，一种是通过C源码经过PC的x86编译器(MinGW或者Visual Studio)后生成vECU目标文件，并于PC上进行系统测试和验证后反馈给研发工程师。另一种是将C源码编译成目标芯片的程序（hex文件）后，运行在目标芯片的指令模拟器上来进行系统测试后再将结果反馈给研发工程师。

如下图所示，Type-1 vECU、Type-2 vECU和Type-3 vECU为第一类通过C源码的构建方式生成的vECU，Type-4为第二类通过目标程序运行在目标芯片指令模拟器的方式实现vECU。  

Type-4 vECU虽然可执行的是同一个目标hex文件，但考虑到Type-4 vECU本身缓慢的运行效率及芯片迭代所带来大量工程，当前多数用户会采用基于源码的Type-1、Type-2 和Type-3的vECU生成方式，它可以获得的更快的运行效率、仿真时的在线Debug、解耦硬件（芯片）以及对实验结果更快的反馈时间。

虽然采用vECU来验证有诸多优势，但用其进行测试和仿真时仍有一定限制，比如无法评估和分析诸如软件上的时间表现、CPU负载、内存资源的消耗以及模拟硬件中断等特性。

五

构建虚拟ECU

VECU-BUILDER 是一款生成虚拟ECU的工具，它将C代码源文件或者预编译后的二进制库文件构建成虚拟 ECU。

虚拟ECU可在虚拟仿真环境中对ECU软件进行仿真、调试和标定。

作为集成vECU的环境，它的输入可以是C代码、静态库文件(lib)或动态链接库(dll)，与通过ARXML配置 Classic Autosar 代码不同，进行vECU集成和配置时只需维护唯一个YAML文件，YAML文件是一个文本形式的配置文件。VECU-BUILDER通过YAML文件的配置信息将代码封装成FMU格式的目标文件。

YAML文件包含编译配置信息、所需集成的C代码或者库文件、vECU的输入输出端口以及任务调度的入口函数，该配置文件可在vECU增量编译的过程中重复使用。

构建虚拟ECU工具演示

vECU生成演示

vECU测试及Debug

六

软硬件解耦后的vECU应用案例

软硬件解耦后vECU的集成和测试可以覆盖从模块测试到系统集成测试。

以下列举5个典型的应用案例

案例1（ 短周期内在SIL环境下ASW的持续性开发）

案例描述：

1.集成ECU应用层软件产品代码成vECU，生成可执行SIL文件。

2.在试验环境上运行SIL，该测试环境等价于目标环境（相同仿真、测试和标定工具）。

3.预集成虚拟化通讯协议栈的vECU可以是该SIL环境的一部分。

案例2 （仿真时间或实时时间下的SIL集成测试）

案例描述：

1.集成测试带有一个或多个vECU，满足相关的功能需求。

2.基于不同的应用案例，可在时间基准上调节仿真时间。

3.使用ECUTest或TPT或Robot Framework框架进行vECU的集成测试。

案例3（ vECU虚拟标定）

案例描述：SIL环境用于执行vECU以及经标定过的被控对象模型，针对软件在环中特定客户项目或者车辆调整vECU的标定参数，从而实现预标定。

案例4（多方协作在云端集成SIL测试环境）

案例描述：

为虚拟控制器测试人员提供结合云端的软件测试SIL测试环境以测试vECU功能。

案例5（ Software Sharing）

案例描述：

对第三方代码（以静态或动态库文件的方式）在软件在环的环境下进行集成和测试。

相关案例:

七

结语：

ETAS 可提供：

1.虚拟控制器vECU工具链

2.联合仿真平台（Simulation Middleware Platform）支持标准FMU集成及跨平台联合仿真，各类虚拟总线

3.持续集成持续测试的自动化流程 (Automation Pipeline)

4.专业的工程服务

用户收益：

1.支持生成不同类型的虚拟控制器，可灵活应用在软件开发前期、中期、后期，提升开发效率。

2.标准化仿真平台，易于接入各种虚拟控制器和被控对象模型等，实现软件在环测试,尽早发现关键错误。

3.通过建立持续集成、持续测试的pipeline，减少开发人员的重复工作，加速集成和测试过程。

4.支持帧级的虚拟总线、国内云端部署，更好地协助开发部门进行数字化转型。

审核编辑 ：李倩