虚拟控制器（vECU）的开发与测试

作者： 老榴

出品： 汽车电子与软件

摘要： 在过去的二十年中，汽车软件的需求和应用急剧增长，随之复杂性急剧上升，现有技术和框架不足以应对这种复杂性。现在很明显，汽车制造商（ OEM ）必须重新考虑他们生产车辆的方式以及车辆本身的生命周期。通过将重点放在软件上， OEM 可以在车辆整个生命周期中实现许多新的应用用例，并打开一个充满机遇的新世界。

01.

软件定义汽车以及虚拟化技术

1.1 软件定义汽车的概念

移动出行时代，汽车已逐渐从纯粹由机械驱动的硬件转变为软件驱动的电子产品。当今不同车厂的产品硬件配置已逐渐趋同，在成本和功能改善空间有限的情况下，传统汽车价值链的重构势在必行。车厂打造差异化的核心要素已转向原先与硬件深度耦合的汽车软件，随着汽车软件在新能源和智能化领域不断取得成功，迈入 “ 软件定义汽车（ Software Defined Vehicles ， SDV ） ” 时代已成为行业共识。

“ 软件定义汽车 ” 即软件将深度参与到汽车的定义、开发、验证、销售、服务等过程中，并不断改变和优化各个过程，是汽车从基于硬件的产品向软件为中心的电子设备不断转变的结果。

“ 软件定义汽车 ”  从表面上看是车内软件（包括电子硬件）的数量、价值超过机械硬件，背后更多的反应了汽车从高度机电一体化的机械终端，逐步转变为 一个智能化、可拓展、可持续迭代升级的移动电子终端。为实现这一目标，整车在标准操作程序前便预埋了性能超前的硬件，并通过 OTA 在生命周期中逐步解锁和释放功能和价值。在该背景下，主机厂的核心能力将从机械硬件转向电子硬件和软件；产业价值链也将从一锤子硬件销售转向持续的软件及服务溢价。

1.2 汽车软件发展的趋势

汽车 “ 新四化 ” 离不开软件和算法随着新四化的深入发展，汽车正加速从从机械设备向高度数字化、信息化的智能终端转变。

首先，软件及汽车电子占整车的研发成本逐步提高，车内软件和电子硬件价值有望超过硬件，成为整车价值的核心。据测算，预计到 2030 年软件成本占整车 BOM （物料清单， Bill Of Material ）的比重将从目前不到 10% 增长到 50% 。需指出的是，这里的软件除应用程序开发、还包括 AI 算法、操作系统，以及软硬件一体化程度高的控制器、芯片等电子硬件。

其次，软件及软件更迭所带来的性能和功能变化，将决定未来汽车的差异性。软件的更新维护是未来主机厂提供差异化体验、提升客户满意度最经济、最便捷、最快速的一种方式。前提是由硬件提供冗余，再由软件实现迭代。

最后，包括主机厂、零部件企业等产业链上企业将加强软件能力建设，并围绕 “ 软件定义汽车 ” 开启从产品开发模式、组织架构、人员构成、运营体系等的内部变革。此外，新兴的软件公司将借助软硬件协同能力，兼容产业链上下多方需求，一举跃升为汽车产业链上新的 Tier-1 企业。

1.3 汽车研发面临的困局

首先，分布式电子电气架构无法满足未来更高车载计算能力的需求。驱使 EEA 架构升级的另一个推动因素来自于更高的通讯效率和更大的带宽容量需求。成本管控黑洞：随着车内 ECU 、传感器数量增加，整车线束成本和布线难度也跟着大幅提升。

另外，汽车软件的模块化、平台化程度低，导致软件资源无法集中调度、协作性差。主机厂的 ECU 通常来自于不同的零部件供应商，事实上控制器上许多底层软件的重复性很高，这些代码主要保障控制器的正常运行，例如 CAN 总线信号的收发、任务进程的调度、 Flash 数据的读写等等。但碍于每一家供应商的软件编程语言不同、接口标准不同，而且软件又和硬件高度依赖，使得这些底层代码无法被复制和移植，从而造成 ECU 软件开发的大量重复和资源利用的低效。

其次，软硬件高度嵌套、主机厂无法执行大规模、深层次的更新和升级或定制化开发工作。分布式软件架构是一种面向信号的架构，控制器之间通过信号来传递信息，但整个系统是封闭、静态的，在编译阶段就被定义死，因此当发生例如主机厂要修改或增加某个控制器的功能定义，同时该指令还必须调用另一个控制器上的功能时，就不得不把所有需要的控制器都升级，大大延长开发周期、增加开发成本。

1.4 研发模式的转变

基于以上技术架构方面的变化，在软件定义汽车的背景下，汽车研发将由传统的瀑布式开发向敏捷开发的模式转变。

敏捷软件开发（ Agile software development ）：包括需求发现和解决方案改进。该模式通过自组织和跨职能团队与用户协作，制定适应性计划，进行渐进开发、早期交付、持续改进，灵活应对需求、能力的变化以及对需要解决问题的理解的变化。这是一种以用户需求进化为核心的迭代、循序渐进的开发方法。工程师先将用户最关注的软件原型做出来进行交付，根据用户在实际场景中反馈的问题，快速修改弥补需求中的不足。上述过程不断迭代，直至用户满意。

DevOps 是一组过程、方法和系统的统称，集文化理念、实践、工具于一身，重视开发（ Dev ）和运维（ Ops ）和质量（ QA ）部门之间的沟通合作。

与传统软件开发模式系相比， DevOps 打破了开发和运维之间的壁垒，通过自动化 “ 软件交付 ” 和 “ 架构变更 ” 的流程，使得软件的构建、测试和发布能更加快捷、频繁和可靠，从而帮助团队更快地发展和改进产品、服务客户、高效参与市场竞争。

1.5 虚拟化的价值

汽车软件开发将遵循 IT 行业的发展规律，引入中间件技术、虚拟化技术来实现软件模块化、硬件抽象化和标准化，从而进一步解锁软硬件的耦合关系，满足电子电气架构灵活、可拓展的需求。

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

那么软件在环 SiL 有什么应用场景呢？其应用场景通常是在快速变更的功能需求下敏捷开发及快速迭代。要求尽早进行软件验证并发现和纠正代码中的重要错误，特别是涉及安全相关错误。在高频率 OTA 云端升级软件的情况下自动化持续验证。在以上场景下软件在环 SIL 测试能够脱离硬件而快速验证控制器的功能代码。

软件在环 SiL 的最关键的一个核心就是虚拟化：即通过将真实控制器转化为虚拟控制器，部署到 PC 上集成环境和联合仿真平台，接入 CI/CT/CD 自动化流水线，并上云端进行大规模测试，从而搭建完整的 DevOps 的 SiL 平台。

虚拟化技术 使得在 Windows PC 上对汽车 ECU （ Electronic Control Unit ，电子控制器单元）进行闭环仿真成为可能，能有效改善 ECU 开发过程。一些开发任务得以从道路、测试平台和 HIL （ Hardware in the Loop ，硬件在环）转移到 PC 上，缩短开发时间和成本。

从 OEM 的视角来看虚拟化，可以将软件测试前移到早期开发阶段闭环，既减少了项目初期昂贵的 BOM 成本，又降低了软件开发成本和时间，在实现软件 CICT 闭环自动化的同时，可以建立供应商之间的发展生态系统，进行多团队多租户并行工作。

从工程师的视角来看虚拟化，传统汽车软件开发的流程一般为：功能开发团队使用基于模型的工具链开发 ECU 模型，生成 C 代码，然后针对目标处理器进行代码编译，并使用测试平台， HiL 系统和道路测试来测试和验证生成的 ECU ，进而将结果反馈至开发人员，结束开发周期。该过程存在的主要缺点有：迭代时间长，受原型车和测试设备的限制 — 硬件资源昂贵且稀缺。

为开发团队提供虚拟 ECU 可解决上述问题：开发人员可在 PC 机上对软件进行模拟、校准和测量，缩短开发周期，减少对稀缺资源和实际硬件的严重依赖；同时，通过虚拟 ECU ，开发人员可随时观察和修改内存变量甚至硬件状态，极大提升工作效率。

02.

vECU虚拟控制器集成

2.1 虚拟控制器的介绍

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

对于功能测试验证工程师，通常他会拿到一个带有软件的完整 ECU 控制器，并以硬件在环或实车环境作为测试环境进行测试，整个测试过程可能受硬件和线束的限制，每当遇到软件的失效时首先需要考虑线束或者硬件通信上的问题，长此以往测试效率通常受硬件资源和硬件状态的限制，难以在受限的条件下高效的完成测试。但是如果仅 ECU 内与硬件无关的功能，只需解耦 ECU 产品代码并封装成 vECU 运行在 PC 上进行测试即可。数据采集和验证过程同真实环境软件测试工具一致，如 INCA 、 Debugger 调试器等等。

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

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

2.2 虚拟控制器的分类

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

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

Type-4 vECU 虽然可执行的是同一个目标 hex 文件，但缓慢的运行效率及芯片迭代所带来大量工程服务来屏蔽当前 ECU 项目的部分二进制控制指令，当前大部分用户仍会采用基于 PC 编译器 Type1 Type2  和 Type3 的方式。基于 PC 编译器编译控制器 C 代码的诸多优势，比如： vECU  的更快的运行效率、仿真时的在线 Debug 、解耦真实硬件以及对实验结果更快的反馈时间。

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

2.3 FMU介绍

FMU 是对动态链接库 DLL 进行的二次封装，它是基于 FMI 协议进行封装的模型文件。 FMI 协议是独立于 建模 软件的标准接口协议，可以用于集成不同的软件建立的不同详细程度的模型，进行 MiL/SiL 仿真。

FMI 的全称叫 Functional Mockup Interface 。 FMI 是为了仿真领域定义的。 FMI 定义了二进制的标准格式仿真模型交换。 FMU 数学模型的代码实现就是将提供的  C 头文件里面定义的函数都实现，如果需要做到源码保密，则将其封装成动态链接库  .dll 就行。

一般商业化的仿真工具比如  CarSim 、 CarMaker 、 AVL Cruise 、 Amesim 和 Simulink 、 ASCET 等都由官方提供  FMU 。在  FMI 官网上列出了目前提供了  FMU 的软件可以在以下路径找到 https://fmi-standard.org/

2.4 vECU自动化生成流程

以ETAS的VECU-BUILDER为例，这是一个基于Python和CMake的Windows工具。

为了创建一套生成 PC Target 的虚拟控制器 FMU 文件，我们需要有一套软件集成和编译工具链：自动化 vECU 编译工具链。这个工具链需要一旦配置完成后，可实现一键生成虚拟控制器。

初次生成 vECU 工作流程：

Rebuild 生成 vECU 工作流程：

03.

集成环境及联合仿真

下面介绍一下关于 FMU 的集成环境和联合仿真平台。

3.1 COSYM介绍

COSYM （系统协同仿真）产品是一个仿真和集成平台，作为系统级软件在环的主干，能够方便支持 ECU 间通信，并使能 OEM 厂商成为虚拟车辆集成商。一旦 OEM 厂商开发了自有的构建模块库，将能够方便采用 COSYM 进行模块集成与连接，使能控制器之间精确地通信。 COSYM 具有 “ 时序主控 ” ，能够协调所集成模块时间同步。  

COSYM 提供了图形配置界面（ GUI ）和实时操作环境（ CEE ），以实现有效的用户交互。旨在为用户提供：

► 模块导入，集成和部署；

► 多平台仿真：

基于 Windows 的自适应时间（ ATS ），软实时 (MiL/SiL) ；

基于云端的并行加速运算 (MiL/SiL) ；

基于 Linux 的实时仿真 (HiL) ；

► 离散和连续仿真系统的交互操控及结果可视化 (CEE) ；

► 高级程序员/用户可以使用ASAM XiL和RestAPI（Python接口等）接 口 与COSYM进行交互。

通用模型集成器主要优势：

► 通用 FMI2.0 集成接口，可快速复用被控对象模型，虚拟控制器模型和帧级虚拟总线模型

► COSYM 提供 Rest API ，可启动后台运行模式，支持自动化流水线工具接入

► 可实现基于 Windows 和 Linux* 增量编译，提升集成效率

联合仿真器主要优势：

► 支持 ASAM-XiL 标准接口，调用 API 即可运行仿真环境

► 支持基于 Windows 和 Linux* 系统下的自动化集成测试

► 支持基于云原生和容器镜像技术的仿真计算

► 支持第三方工具交互式测试，例如：测试管理与标定工具和 总线仿真与信息安全工具 功能

3.2 COSYM功能

功能模块集成：

► COSYM 支持用于联合仿真的功能模型接口标准（ FMI ） V2.0 ；

► 提供了用于虚拟 ECU （ vECU ）集成和仿真的环境；

► 建模工具 ASCET 和 ASCMO 模型；

► Labcar 系列半物理模型，基于 Simulink 的   模型编译导入；

► 支持模板化的 C 模块；

模块间通信连接：

COSYM 提供了基于 CAN/CANFD, 车载以太网， FlexRay, LIN 的的汽车总线虚拟仿真技术。

基于共享内存，该虚拟总线仿真为被动和分散式，分布式系统因此可以由任意数量的模块构建。不需要真实的网络接口，可在虚拟 vNet 接口上捕获网络流量并将其转发到真实的网络接口。虚拟 CAN 和车载以太网支持在 ISO / OSI 第二层级及以上的逻辑总线行为模拟，模拟可到帧的传输而非电压电平。

COSYM  可提供 vPIN 级别的 vECU 信号互连插件 - 虚拟电器层（ vEL ），以实现例如故障存储器， EEPROM ，通讯堆栈和输入 / 输出的测试验证；相比真实硬件，该插件简化或删除了部分特定硬件和复杂驱动程序相关的仿真。

3.3 COSYM应用场景

► 虚拟控制器自动寻优标定（节能减排）

► 大规模云端并行计算及多租户协同工作（降本增效）

► 虚拟整车及产品级代码白盒持续集成与测试（加速迭代）

► 被控对象模型自动参数化（精度提升）

04.

云上大规模测试

ETAS 的Cloud Service整体概览

从 ECU 到 VECU 实现了控制器硬件的虚拟化；从物理控制器测试联调到联合仿真平台实现了测试环境的虚拟化；前序两阶段的虚拟化为云上大规模测试仿真提供了可能。

4.1 快速的基础设施扩展

依托于云供应商（ AWS 、 Ali Cloud ）的弹性伸缩服务，秒级创建用于大规模测试仿真所需的计算资源。应对复杂被控对象模型和海量信号数据输入也能够实现即时处理；仿真任务完成后资源即刻销毁。相较于传统本地仿真运行，能够有效避免由于硬件计算资源不足导致的运行崩溃，仿真等待时间长，从成本上看按量付费模式可减少基础设施建设投入，减少计算资源闲置。

4.2 并行测试仿真

基于容器云的编排能力和云供应商容器服务 （ AWS: EKS 、 Lambda, Ali Cloud: ACK 、 FC ）能够完成大规模并行仿真任务，并行测试执行。能够对车辆网络等复杂系统进行仿真，包括虚拟车辆控制单元、车辆总线和仿真模型。每次仿真运行可测量 1000 个信号，输出报告支持用户自定义格式。相较于本地运行仿真时的垂直扩展方式， Cloud Service 能够以分布式架构水平扩展计算节点，完成各节点间仿真任务的数据同步，最大可支持 1000 个仿真任务并行执行。

云上仿真测试用例释义

4.3 高度安全的云环境

Cloud Service  上的仿真应用 Model-Simulator 已通过 ISO/IEC 27000 和 27001 认证。达到博世安全等级 3( 严格保密 ) 。

4.4 兼容的适配性

Cloud Service 兼容 COSYM 、 VECU Builder 、 ETAB 之外，还兼容其它第三方产品，如 ECUTest 、 AVL 、 Synopsis 、 Vector 等。

4.5 多租户团队协同

多个仿真测试团队可同时登录进行仿真测试。各租户之间模型和信号等数据隔离；租户之间仿真任务并行运 行互不影响；各云上租户资源可无限扩展。

05.

CICT自动化流水线

在虚拟控制器生成 和虚拟整车平台 SIL 环境搭建的基础上，通过一系列工具链实现持续集成与持续测试的 CICT 自动化流水线。

CICT 方案为客户带来的显著收益：

► 开发与测试环节的全面加速

► 尽早发现错误并有效反馈

► 可重复使用现有工具

► 数据安全保障

► 使员工可以专注于价值创造，而非工具与工具链

► 多方工程协作的支持

支持构建用户自定义的持续集成及持续测试自动化流水线

流水线步骤举例：

► 代码变更，保存并推送代码仓库， Jenkins 触发 CICT Pipeline 流水线。

► 拉取代码变更到本地 PC ，生成虚拟控制器 FMU 并进行校验。

► COSYM 集成并进行冒烟测试。

► 持续测试通过 ，报告生成和查看分析，上传测试通过虚拟ECU文件至JFrog制品仓库。

06.

应用案例

以下是基于ETAS虚拟化开发工具链，列举一些应用案例。

6.1 虚拟标定和虚拟总线应用，虚拟整车POC

客户面临的挑战和困难：

► 仿真平台能够支持接入第三方的模型（如： ML/SL 、 GT 、 AMESim 、 CarMaker 等）。

► 能够减少车辆标定工作时间，特别是重复性标定（如：工况脉谱图的扫点标定）。

使用 虚拟化方案实现的成果：

► 成功通过 COSYM 仿真平台完成软件在环的闭环工作。

► 标定软件 INCA 通过 XCP 协议与虚拟控制器建立通讯。

► 自动化标定软件 INCA-FLOW 通过 ASAM-XIL 接口与 ETAS COSYM 进行连接，实现对被控对象（如：运行工况点）的控制，并通过设计好的标定流程自动实施标定工作。

6.2 基于模型在环和软件在环的功能测试

客户面临的挑战和困难：

► 虚拟化实践需要基于目前使用的软件开发工具。

► 虚拟控制器能够使用优化后的标定参数，并通过 DCM 文件进行。

► 虚拟化实践除了在单机上进行，也支持在云端运行。

使用 虚拟化方案实现的成果：

► 通过 VECU-Builder 工具实现了 Type-1 虚拟控制器的生成，并使用了 DCM 文件中优化后的标定参数。

► 成功通过 COSYM 仿真平台完成软件在环的闭环工作。

► 单机性能：比实时仿真快 2+ 倍。

► 通过 Cloud Service 实现了云端运行的预研评估工作。

6.3 持续集成和持续测试 CI/CT

客户面临的挑战和困难：

► 有计划、分步骤地进行虚拟化实践。

► 适用于 AUTOSAR 架构的和非 AUTOSAR 架构的软件。

► 不能因为引入虚拟化实践，大幅增加开发工程师的工作负荷。

► 虚拟化实践要满足未来软件定义汽车的大趋势。

使用 虚拟化方案实现的成果：

► 根据客户的实际情况成功建立起点是源代码，终点为测试报告的自动化 Pipeline 。

► Pipeline 中可以自动地生成虚拟控制器，关联被控对象模型，接入仿真平台。并进行虚拟控制器的冒烟测试后，按照设定的测试用例进行软件在环测试，最后生成报告。

► Pipeline 可以在本地服务器中部署，也可以移植到云端运行。

6.4 虚拟标定和云端队列

客户面临的挑战和困难：

► 需要减少车辆道路测试和标定的人力投入和费用。

► 最大限度兼容目前使用的工具（ INCA 、 ASCMO 和 MOCA 等）。

► 提高测试和标定工作的效率。

使用 虚拟化方案实现的成果：

► 成功通过 VECU-Builder 工具实现了 Type-1 虚拟控制器的生成。

► 成功通过 COSYM 仿真平台完成软件在环的闭环工作。

► INCA 、 ASCMO 和 MOCA 等工具能够在虚拟环境中无缝衔接。

► 标定效率：比实车测试快 5+ 倍。

► 测试效率： 2 小时仿真 =25,000 公里路测。

6.5 虚拟标定自动化

客户面临的挑战和困难：

► 仿真平台能够支持接入第三方的模型（如： ML/SL 、 GT 、 AMESim 、 CarMaker 等）。

► 能够减少车辆标定工作时间，特别是重复性标定（如：工况脉谱图的扫点标定）。

使用 虚拟化方案实现的成果：

► 成功通过 COSYM 仿真平台完成软件在环的闭环工作。

► 标定软件 INCA 通过 XCP 协议与虚拟控制器建立通讯。

► 自动化标定软件 INCA-FLOW 通过 ASAM-XIL 接口与 ETAS COSYM 进行连接，实现对被控对象（如：运行工况点）的控制，并通过设计好的标定流程自动实施标定工作。

07.

总结

7.1 应用领域

► 针对功能开发、集成测试工程师可以在应用层代码开发阶段完成 SIL 仿真测试

► 针对标定测试工程师可以在 SIL 仿真环境中进行多控制器联合虚拟标定

► 实车数据与虚拟整车相互促进

► 打造敏捷软件开发的研发生态

► 助力车企打造软件定义汽车和整车数字孪生应用案例

► 整车物理模型的搭建、集成与精度提升

► 工具兼容性可支持低成本及跨车型通用

7.2 功能特色

► 支持跨软件架构和操作平台，生成不同类型的虚拟控制器vECU，操作流程简易成熟

► 联合仿真平台支持标准 FMU 集成，跨平台联合仿真，灵活度和兼容性高

► 支持三方工具多控制器联合虚拟标定

► 支持构建用户自定义的持续集成及持续测试自动化流水线

► 各类帧级虚拟总线标准插件。包括 CAN 、 CANFD 、 LIN 、以太网等虚拟总线

► 可基于国内云端部署

7.3 收益优势

► 虚拟控制器可灵活应用在软件开发前期、中期和后期，提升开发效率

► 标准化仿真平台，兼容各类虚拟控制器和被控对象模型，实现软件在环测试，仿真速率高

► 通过建立持续集成、持续测试 Pipeline ，减少开发人员的重复工作，加速迭代过程

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

► 减少硬件测试台架的投资，加快整车开发测试和上市周期

► 建立多团队间的协同开发软件的生态

 

-end-

本专栏是由 汽车电子与软件 打造的中立性技术科普专栏，将系统地阐述软件定义汽车下的关键挑战和工程实践。 欢迎订阅本专栏！