软件定义汽车vECU虚拟控制器集成开发与测试

摘要

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

一

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

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，开发人员可随时观察和修改内存变量甚至硬件状态，极大提升工作效率。

二

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工作流程：

三

集成环境及联合仿真

下面介绍一下关于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应用场景

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

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

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

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

四

云上大规模测试

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 多租户团队协同

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

五

CICT自动化流水线

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

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

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

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

►可重复使用现有工具

►数据安全保障

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

►多方工程协作的支持

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

流水线步骤举例：

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

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

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

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

六

应用案例

以下是基于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进行连接，实现对被控对象（如：运行工况点）的控制，并通过设计好的标定流程自动实施标定工作。

七

总结

7.1 应用领域

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

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

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

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

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

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

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

7.2 功能特色

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

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

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

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

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

►可基于国内云端部署

7.3 收益优势

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

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

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

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

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

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

 

编辑：黄飞