vECU/SIL: OEM从“技术尝鲜”到“研发标配”

 

01

SIL测试——从“尝试”变为“趋势”

在整车厂与供应商的项目中，以下场景屡见不鲜：

ECU软件已进入跨团队/公司级的功能联调，硬件板子却还未到位；

算法工程师写好控制策略，却找不到真实环境进行验证；

软硬件均已更新，HIL台架资源却需要排队等待。

过去，这些瓶颈往往只能靠“等”——等硬件、等设备、等协调。但随着软件在整车系统中的复杂度占比持续攀升，等待直接意味着项目延期、返工和成本飙升，更有甚者出现测试两班倒。于是，越来越多团队开始采用一项关键手段——SIL（Software-in-the-Loop，软件在环测试）。

什么是SIL？

SIL相当于为ECU软件打造一个“虚拟机”，使其脱离具体硬件也能正常运行、通信与信号处理。SIL模拟ECU的执行环境、网络交互与传感器输入，让软件提前跑起来，无需等待硬件、台架甚至整车。无论是控制策略、诊断流程，还是通信配置，均可在SIL环境中提前验证。

图1：SIL测试覆盖软件组件到系统验证

SIL测试“左移”的工程哲学

项目初期实现“系统级联调”
 传统流程中“软件等硬件”的断层被打破。只要软件编译通过，即可在虚拟ECU上模拟通信（CAN/LIN/ETH）、诊断、控制逻辑、任务调度及信号链路。算法工程师甚至能在本地电脑上跑通完整的车辆控制流程。

测试能力无限扩展，奠定CI/CT基础
 SIL支持同时启动数十甚至上百个虚拟ECU，实现全流程回归测试，并能在每次编译后自动执行全量测试。这为持续集成（CI）与持续测试（CT）提供了基础，彻底告别低频次的“周测”、“月测”。

摆脱硬件、台架与人工依赖
 整个测试过程无需真实ECU、复杂台架或人工重复操作。通过脚本自动化执行，结果具备完全一致性与可回溯性。

调试成本大幅降低
 在SIL环境中，工程师可直接在IDE（如Visual Studio）中打断点，实时查看变量、堆栈与任务状态，不再受硬件调试器的限制，显著提升排查效率。

安全模拟危险、极限与难复现工况
 例如传感器断连、总线报文突发丢失、信号越界、服务器中断及极端温度电压等场景，在实车或硬件测试中难以安全复现，而SIL可无限次模拟，为软件鲁棒性验证提供关键支撑。

正因如此，SIL测试已不再局限于先进团队的PoC验证尝试，而是正在快速重塑汽车软件开发与测试的验证体系。

02

vECU的不同等级与应用场景

为覆盖从模型验证到量产代码测试的全流程，虚拟ECU（vECU）常被划分为不同等级。每个等级对应着不同的软件集成度、模拟程度，以及对底层软件（BSW）和硬件的依赖程度。接下来将系统介绍从最轻量的Level 0到最接近真实硬件的Level 4，共五种vECU类型及其典型应用。

图2：不同层级的vECU

Level 0 vECU（应用模型/MIL）
 最轻量级形态，仅包含控制器模型（如Simulink生成的代码），不涉及RTE或BSW。主要用于模型在环（MIL）测试，适用于算法验证与功能早期评估。

Level 1 vECU（应用层+RTE桩函数）
 在量产应用软件组件（SWC）基础上，通过工具生成运行环境（如RTE与OS的桩函数或框架），使应用层代码能在仿真中执行。除了Level 0阶段测试的SWC应用逻辑外，Level 1 SIL测试还可以验证完整的ECU软件架构与RTE接口集成，显著前移缺陷暴露的时间。

Level 2 vECU（应用层+模拟BSW）
 在Level 1基础上加入模拟的底层软件模块（如COM、NvM、DCM/DEM等），可进行更全面的功能测试。该层级还支持总线级仿真，支持利用虚拟网络实现系统级交互测试。

Level 3 vECU（应用层+真实BSW+虚拟硬件）
 进一步集成真实量产的BSW，并通过硬件抽象模拟MCU资源（如MCAL、OS）。涵盖全量产软件栈，支持复杂通信配置、存储流程及AUTOSAR全栈集成测试，可在HIL测试前承担大量系统验证任务。

Level 4 vECU（目标代码/全量产软件）
 包含为具体ECU编译的全套量产代码（含硬件相关部分），通常需在指令集模拟器中运行。因建模复杂、执行效率低、成本高，多用于芯片级验证，在常规汽车软件测试中较少使用。

03

软件先行：基于AUTOSAR架构的ECU虚拟化“加速器”vVIRTUALtarget 

为构建并完善软件在环（SIL）测试的vECU生态体系，Vector将在ECU虚拟化领域深耕近十年的技术积淀集成在vVIRTUALtarget pro SE（以下简称vVIRTUALtarget）中，协助用户高效构建运行于Windows或Linux环境下的Level 1至Level 3虚拟控制器，为软件定义汽车的敏捷开发提供坚实的虚拟化仿真基础。

图3：vECU生成器vVIRTUALtarget工作流

vVIRTUALtarget是一款带有图形界面的应用软件，集成Visual Studio和CMake编译器。用户可通过拖拽操作轻松使用，并支持一键导出脚本工程和后续的命令行持续集成（CI）。

图4：vVIRTUALtarget工程配置界面

对于Level1/2 vECU生成过程，vVIRTUALtarget支持：

标准AUTOSAR OS及RTE生成；

A2L文件自动生成；

vECU运行环境（CANoe工程）及交互接口自动生成；

构建Visual Studio/Visual Studio Code项目仓库，支持后续代码编写、软件编译及工程调试。

图5：vVIRTUALtarget中vECU编译配置

在进行虚拟控制器开发过程中，除了软件编译环节外，主要技术挑战还包括以下几个方面：

如何在虚拟ECU运行平台上访问SWC（软件组件）端口？

如何高效地监控vECU内部端口的数据流动？

如何有效刺激应用层，以验证SWC在虚拟环境中的正常运行？

为应对上述问题，vVIRTUALtarget在构建vECU时会自动生成相关接口，便于用户对软件系统进行观察与调试，包括：

开放RTE端口（Open RTE Ports）

- 支持直接访问Open Port的数据元素（Data Elements）

- 能从CANoe中直接采集与激励应用端口数据

端口监控（Port Monitoring）

- 支持SWC内部连接的信号流监控

- 支持XML文件（*.vttpm）管理RTE端口

Open RTE Ports进行外部输入输出设置，Port Monitoring打开内部视野，它们共同让AUTOSAR vECU“可监控、可调试、可验证”。

04

Level 1 vECU-虚拟调试、虚拟诊断、虚拟标定、虚拟存储

通过vVIRTUALtarget生成的vECU支持在CANoe中一键导入并映射I/O接口，有效打通从SIL到HIL的测试链路，确保测试脚本与仿真模型在不同阶段的完全复用。这种方法极大提升了CANoe的应用维度，使其在虚拟验证阶段即可开展自动化测试与异常调试。除常规功能验证外，该方案进一步拓展了虚拟诊断、标定及存储测试的能力。以下通过实际案例展示其应用效果。

图6：有效的vECU与HIL复用

虚拟诊断

车门控制器SWC功能说明：该模块用于监测车门节点及车辆电瓶电压状态。在发生车门节点丢失或检测到电瓶电压异常（过高或过低）时，将通过标准DEM诊断接口上报相应的DTC故障码。

图7：vECU在CANoe中实现虚拟诊断

在CANoe环境下导入Level 1 vECU后，可清晰展示其输入输出接口。通过Panel界面能够直观地监控故障注入过程，并结合诊断控制台读取相关DTC，实现对SWC功能的全面测试。此外，所有操作均可借助CANoe自动化脚本实现流程自动化，从而大幅提升验证工作的完整性与效率。

虚拟标定

车灯控制器SWC的算法逻辑包括：系统根据光线传感器采集的亮度数据自动执行大灯启闭操作，其开启与关闭阈值可通过标定进行调整，以实现精确控制。

图8：vECU配置在CANoe实现CCP/XCP变量测试

在CANoe环境中导入Level 1 vECU后，可通过加载相应的A2L文件进行阈值参数读写。将不同亮度信号输入至Level 1 vECU，经由Panel面板可直观展示控制算法运行过程及效果。此外，标定变量亦可利用CANoe自动化脚本完成，实现参数调整的自动化操作。

虚拟存储

仪表控制器SWC的功能主要负责管理车辆里程表和车外后视镜位置等在ECU软复位后需持续保留的数据信息。该模块核心体现AUTOSAR非易失性存储（NvM）机制的应用。在Level 1 vECU环境中，EcuM与NvM模块由vVIRTUALtarget进行模拟并协同运行，以演示ECU生命周期管理及运行数据的存储和恢复过程。

图9：vECU实现虚拟存储

在CANoe环境下导入Level 1 vECU后，可通过CANoe的面板、信号或CAPL程序模拟驾驶员操作、车辆状态及ECU状态（如点火、档位、EcuM_State等），并将相关信号通过接口变量传递至Level 1 vECU，以便对里程表及后视镜设置在运行及复位前后的行为变更进行观测。Level 1 vECU在控制器断电后会将非易失性变量存储到文件，上电时则从对应文件读取值并赋予相应变量，实现功能测试与验证流程。

05

SDV标配vECU解决研发“内卷”

在软件定义汽车（SDV）的趋势下，算法集成正由分散转向ZCU/HPC，多方代码的集成测试与质量把控迫在眉睫。为了支撑整车厂的数字孪生战略及AI驱动的数据闭环测试，供应商必须提供可量产化的vECU。采用CANoe实现从HIL到SIL的无缝迁移，不仅能最大化利用既有测试资产，还能打破开发壁垒，提升业务链整体交付效率。而vECU的方式使得开发与测试同步，从而避免传统迭代的技术“瓶颈”。

图10：CANoe贯通SIL与HIL全链路验证