Simulink FMU Builder在虚拟ECU方案中的工程价值

摘要

随着汽车行业向软件定义车辆(Software Defined Vehicle, SDV)持续演进，研发流程正转向跨团队、跨工具、跨供应链的协同开发。控制软件、物理系统模型、第三方工具模型以及测试与标定环境往往分散在不同平台之上，如何以标准化、可复用且工程可控的方式组织这些资产，已成为影响研发效率和系统级验证质量的关键因素。

FMI(Functional Mock up Interface)是面向动态系统模型交换与联合仿真的开放标准，FMU(Functional Mock up Unit)则是遵循该标准的模型封装形式。围绕 FMI 标准，Simulink 对 FMU 的支持经历了从导入、到导出、到独立运行(standalone)，再到对 FMI 3.0 的持续扩展。在此基础上，R2026a 中 Simulink FMU Builder 以独立产品形式推出，面向模型与代码的工程化封装，进一步强化了 FMU 在虚拟ECU与系统级仿真中的可落地性。

本文从汽车行业的协同挑战出发，系统阐述 FMU 的工程价值，重点说明 Simulink FMU Builder 在 R2026a 的产品化意义，并从创建、集成与工程流程三个层面，深入分析 FMU 在虚拟ECU方案中的位置。

1. 汽车研发协同进入“标准化交付”阶段

在当前汽车研发实践中，模型和软件资产的价值越来越体现在“是否能够被其他团队复用、被下游流程集成，并有效参与系统级验证”。在整车厂与 Tier 1 的协同开发过程中，控制软件、物理模型、代码组件和测试环境通常来自不同团队和不同工具链。如果缺乏统一的接口与交付形式，系统集成成本会随着模型数量和验证层级的增加而迅速放大。

从工程实践来看，当前行业用户面临的挑战主要集中在三个方面：

多工具集成复杂度持续上升：模型来源、运行依赖和版本差异导致系统级集成与调试成本高企;

模型交付与知识产权保护之间的平衡：团队希望共享算法能力，但并不希望暴露完整工程细节;

前移验证与虚拟化开发的需求增强：在 HIL 之前即完成更多闭环验证，以缩短迭代周期并降低对物理硬件的依赖。

这些问题共同指向对标准化交付形态的需求，而 FMI 作为工具无关的开放标准，为动态系统模型的交换与联合仿真提供了共同语言;FMU 则进一步将模型或代码封装为自包含、可运行的标准化组件，使其能够在不同仿真环境中执行。这一机制为跨工具、跨组织的工程协同奠定了基础。

2. FMU 的工程价值：从“可运行”到“可工程化”

从工程流程角度看，FMU 的核心价值，并不只是将模型或代码“打包导出”，而在于将其从“研发阶段的内部对象”转化为可交付、可集成、可复用的工程资产。围绕这一目标，Simulink FMU Builder 面向建模工程师、虚拟测试工程师和系统集成工程师，支持以下场景的实现：

将 Simulink 模型导出为独立 FMU，用于第三方仿真或系统级集成平台;

将既有的 C/C++ 应用软件封装为 FMU，加速其纳入系统级仿真流程;

将生成的 FMU 导入 Simulink 环境进行一致性验证，降低集成风险;

通过结构化 I/O、运行时可调参数与嵌套 FMU 支持复杂模型接口与复用。

从C/C++源码直接生成FMU

综上，FMU 将开发侧的模型/代码以统一接口交付给系统级集成与回归验证流程。此外，在控制软件开发过程中，信号观测、参数调试和迭代也是不可或缺的环节。传统 ECU 标定通常基于 XCP 协议和 A2L 文件;当验证活动前移到 SIL/虚拟 ECU 阶段，FMU是否还能延续这一成熟工作流?为此，Simulink 在封装控制逻辑或应用软件为 FMU 的同时，可集成 XCP 通信并生成 A2L 文件，使生成的 FMU 可被工业测量与标定工具识别与访问。由此，FMU 不仅是可运行组件，也可作为虚拟环境中的可标定对象，帮助在 SIL、HIL 之间保持参数管理与标定流程的连续性。

基于XCP协议的FMU标定

3. Simulink 对 FMU 支持的能力演进

Simulink 对 FMU 的支持是随着行业需求与 FMI 标准的演进逐步扩展的。从时间维度看，这一路线包括：

支持 FMU 导入，用于跨工具模型集成;

支持 FMU 导出与 standalone 运行，降低对原建模环境的依赖;

支持 FMI 3.0，扩展可用场景与接口能力。

在 R2026a 中，Simulink FMU Builder 以独立产品形式推出，其意义并不仅在于功能增加，而在于 FMU 工作流从“分散的能力集合”转变为面向工程交付的清晰产品形态。这意味着，FMU 不再只是附属于编译或部署流程中的一个选项，而是被明确定位为“模型与代码工程化封装”的核心能力，包括：

更清晰的封装入口：通过向导化配置，降低 FMU 工程化封装的门槛;

更广的资产覆盖范围：支持从 Simulink 模型与 C/C++ 代码生成 FMU;

更贴近虚拟ECU与系统级仿真的能力组合：包括多实例 FMU、ERT based FMU、跨平台运行以及参数与接口的工程化管理。

4. FMU 在虚拟ECU方案中的位置：连接创建、集成与工程流程

在虚拟 ECU 体系中，FMU 不仅提供标准化封装与接口，更定义了组件交付、系统接入与验证迭代的统一边界。以下从创建、集成与工程流程三个维度说明其作用。

创建侧：虚拟ECU组件的工程封装形态。在虚拟 ECU 创建阶段，FMU 提供面向交付的封装形态：将控制模型或应用软件转化为自包含组件，并以标准接口暴露信号与参数，使得部分以应用层软件与控制逻辑为核心的虚拟ECU场景可直接以FMU作为交付单元。

集成侧：系统级仿真的统一接入边界。在虚拟 ECU 集成阶段，FMU 的核心价值在于为不同来源的虚拟组件提供统一接入边界。Simulink 可被定位为虚拟 ECU 的系统级集成平台，可以集成来自不同工具链的虚拟 ECU、FMU 与代码组件。FMU 在其中承担的角色，是将“不同来源、不同实现方式的虚拟对象”纳入同一系统级仿真环境。这种定位意味着，FMU 并不是要取代所有集成方式，而是作为最重要的标准化接口之一，降低虚拟 ECU 集成的复杂度。

流程侧：观测、调参与前移验证的承载体。在工程流程层面，FMU 的位置体现在它是否能够承接验证、观测与调参流程。结合前述基于 XCP 的虚拟标定能力，FMU 可以在虚拟 ECU 与 SIL 场景中，成为可观测、可调参、可验证的工程对象。这使得 FMU 不再只是“被系统调用的执行单元”，而是直接参与工程迭代与验证闭环。因此，FMU 在此层面的关键价值是把“可执行组件”扩展为“可观测、可调参、可追溯”的验证对象，从而缩短从软件生成到系统级验证的闭环路径。

MathWorks虚拟ECU解决方案

5. 结论

随着汽车研发向虚拟化与前移验证演进，模型和代码的工程价值正在从"能开发、能运行”转向“可交付、可复用、可观测、可标定、可验证”。

FMU 作为 FMI 标准的核心载体，为跨工具协同与系统级验证提供了统一的交付单元;Simulink FMU Builder 的产品化进一步强化了这一工程化路径。

对汽车行业用户而言，评估重点不在单一功能点，而在于 FMU 能否进入主流程：支撑跨工具协同与虚拟 ECU 集成，承载参数观测与虚拟标定，并在更早阶段完成闭环验证。

从这一角度看，Simulink FMU Builder 正在推动 FMU 从“模型交换文件”走向“虚拟化研发流程中的工程对象”。

关于作者

龚小平，MathWorks 中国

MathWorks 中国区资深应用工程师，负责基于模型设计和系统工程在汽车行业的应用，关注 AUTOSAR、功能安全和信息安全等行业标准在传统电控和新能源及自动驾驶方向的应用。在加入 MathWorks 之前曾从事多年的汽车底盘电控系统和软件研发，在系统工程和软件工程领域具有丰富的经验。