2025 年 3 月 19 日，在第六届软件定义汽车论坛暨 AUTOSAR 中国日上，长城汽车总工程师杜建福介绍了 EE 架构从传统单一 ECU 向整车 SOA 架构的演变，指出系统被划分为技术服务层和应用服务层等多个层级。随着技术发展，中央计算单元向 AP 平台迁移，但平台选择尚未统一。在 SOA 开发过程中，面临多核处理器环境兼容、C++ 人才稀缺以及 Simulink 开发模式迁移等挑战。这些问题要求汽车行业在人才和技术上不断创新，以适应新的开发环境。

杜建福 | 长城汽车总工程师

随后，迈斯沃克首席应用工程师 / 技术客户经理龚小平介绍了 MathWorks 针对 SOA 开发的解决方案。通过提供架构设计工具、自动代码生成技术和中间件服务栈，MathWorks 助力汽车行业实现高效 SOA 开发。其解决方案支持从架构设计到代码生成、部署的完整流程，同时提供虚拟仿真功能，加速开发进程。此外，推荐采用增量式部署方法，简化软件问题排查。

龚小平 | 迈斯沃克首席应用工程师 / 技术客户经理

以下为演讲内容整理：

EE架构的演变与软件体系结构

在传统架构设计中，我们主要聚焦于单一的 ECU，关注其应用层或底层软件架构的构建。着 SOA 理念在汽车行业中的兴起，架构设计的视角已拓展至整车的层面。在此架构下，系统被划分为技术服务层、应用服务层等多个层级，上层承载着各类应用，而下层则由中央区域控制器及一系列原子服务等构成。

图源：演讲嘉宾素材

当前，车辆仍运行于传统的 CP 平台，诸如 VCU 或车身控制器等组件均部署在此类平台上。然而，随着技术的发展，部分中央计算单元已开始向 AP 平台迁移。关于未来平台的选择，目前业界尚未达成共识，各方均在按照自身战略进行探索。但长远来看，或许 " 分久必合，合久必分 "，最终或将趋向于一种归一化的解决方案。

在 SOA 开发过程中，我们面临着一系列挑战。中央架构中不仅包含 A 核，还融合了 M 核与 R 核等多种类型的处理器。SOA 软件的开发需兼顾运行于 Posix 兼容系统内核的环境，以及运行于经典实时操作系统（RTOS）的 M 核（或 R 核）环境。

在 SOA 开发过程中，我们遭遇了诸多挑战。在项目初期，一个显著的问题便是 C++ 人才的匮乏，因为当前符合 AP 规范的开发普遍采用 C++ 语言，而市场上此类专业人才资源稀缺，招聘工作变得尤为困难。即便能够招募到相关人才，我们也面临着如何将汽车行业广泛使用的 Simulink 开发模式有效迁移到 AP 平台的问题。Simulink 原有的模型如何在新平台下实现复用，成为亟待解决的关键议题。

此外，对于习惯于基于 Simulink 模型开发的开发者而言，转向手工代码编写后，代码的可视化效果显著减弱。相较于 MBD 开发，后者在可视化方面存在不足，对于算法进行仿真验证的便捷性亦有所降低。

测试环节亦面临挑战。在模型开发环境下，开发者能够借助多种测试工具和仿真工具来辅助完成工作。然而，在手工代码编写的情境下，测试工作的便利性大打折扣，增加了开发难度和复杂度。

MathWorks SOA 解决方案

当前，EE 架构正经历着从分布式架构向域控制器、区域控制器乃至中央集成架构的演变，软件也随之发生相应的变革。我们面临的一大挑战在于如何构建一个系统，该系统既能支持基于信号的方式，又能兼容面向服务的架构，并最大程度地共享这两种方式的流程。

MathWorks 在此领域提供了一套相对完备的解决方案。架构方面，随着软件复杂度的不断提升，行业普遍认同 " 架构先行 " 的理念。在架构设计阶段，需要全面考虑服务的定义、功能划分、端口创建以及服务接口和端口的分配等关键要素。

目前有两种实施路径可供选择。第一种路径是，采用其他架构工具完成设计工作后，通过导出 AI Excel 文件的形式与 Simulink 进行对接。另一种路径是直接在 Simulink 环境中运用架构设计工具进行设计，其显著优势在于能够直接从架构组件中创建 Simulink 模型，从而避免了中间文件信息可能丢失的问题。

对于 C++ 代码开发而言，要撰写高质量代码颇具挑战性，很大程度上依赖于开发人员的经验水平，这种依赖性可能导致代码质量的不一致性。为了规避这一问题，我们可以利用自动代码生成技术。该技术能够减少人为因素带来的错误，提高代码生成的准确性和效率。我们可以从 Simulink 自动生成符合 AUTOSAR 规范的 C++ 代码。

代码生成完成后，我们仍需面对一个关键问题，即如何将这些代码编译并部署到中间件平台上。通常，与第三方中间件进行匹配时，都会经历一个适配过程。为了加速这一部署流程，我们自行提供了一套中间件服务栈，该服务栈涵盖了通信、存储、日志记录、执行等软件开发中最常用的组件，旨在使用户无需依赖第三方服务栈，即可直接将生成的代码编译并部署到一个可运行环境中。此外，我们还提供了一个上位机交互界面以及测试与标定界面，作为正式部署到量产中间件之前的准备阶段。

在此基础上，我们推荐采用增量式或渐进式的方法来部署 AUTOSAR 的 SOA 开发。第一步是在硬件虚拟环境中运行我们的原型栈，包括应用层算法，主要目的是验证服务的功能和接口。随后，我们可以将虚拟环境替换为实际的目标硬件，例如基于 IMA 的芯片，继续运行 SOA 服务。在这一阶段，我们可以进一步验证驱动层的性能。

在第三步中，我们将原型栈替换为面向量产的中间件，这一过程允许我们检查中间件与其他应用层软件之间的兼容性。增量式方法的一个显著优势在于，它有助于软件解耦，从而在面对软件问题时，能够迅速定位问题源头。软件问题的排查往往复杂且耗时，而此方法能有效简化这一过程。

此外，我们还具备虚拟仿真功能。以前门预警系统为例，当我们将算法部署到原型硬件上时，可以利用 UDP 协议、SUMIP 协议以及 consume LINK 进行原型联合仿真。在 Simulink 中运行的车辆模型能够模拟各种场景，从而实现完整的闭环仿真。

除了 A 核能够实现虚拟化之外，M 核同样具备虚拟化的能力。我们与合作伙伴在亚马逊云平台上共同实施的一个案例中，我们分别虚拟了 A 核与 M 核，其中 A 核上运行的是 VCU，M 核上运行 BMS。两者通过商用 IP 进行通信。相较于 A 核，M 核的虚拟化过程稍显复杂，因为它需要借助第三方软件进行硬件模拟。通过这一虚拟化验证过程，我们能够实现整个开发流程的提前，即流程左移。

SOA 开发实践

SOA 开发层面，我们总体上可以采用三种方法。第一种方法是手工编写，同时也可融入部分自动化手段，整个 APP 的框架可以通过自动代码生成来完成，而算法部分则仍需手工编写。

第二种方法是纯 Simulink 开发，即完全在图形化环境中进行。此时，利用 Simulink 生成整个框架和算法代码，并采用 AUTOSAR 的 TLC 模板，直接利用其主函数和特定函数等原生组件。

第三种方法是将手工与 Simulink 两种方法相结合，开发者可以选择使用自动或手工方式编写 APP 框架，随后利用 Simulink 生成算法代码。接着，通过 AUTOSAR 的 ERP 模板生成第三方代码，这些代码随后被手工代码或框架代码所调用。

针对采用 Simulink 进行纯粹的 AUTOSAR 开发，我们进行了一些实践探索。在 AUTOSAR 框架下，存在一个数据词典，它支持 Events 和 Methods 的定义。对于 Events，可以通过常规的 input 与输出 output 以及添加一个 message box 来实现；而对于 Methods，则可通过 Simulink Function 和 Function Caller 模块来实现。Field 是 Event 和 Method 的组合体。

我们利用了一款架构工具，来定义服务的接口和方法，从而生成了服务架构图。在 Simulink 环境中进行建模时，只需将架构工具生成的 ARXML 文件导入，并添加两行代码，即可轻松构建服务端和客户端。

在服务端的模型中，需要更新一些相关配置，例如某些实体或 IDEA 在导入时可能因版本未更新而不被支持，因此需要进行相应的更新。同样，客户端的相关参数也可能需要更新。

在 SOA 开发过程中，我们不可避免地会涉及到 A 核与 R 核的开发。A 核中运行着各种应用，而这些应用需要与 R 核进行信号交互。因此，服务与信号之间的设计成为了一个重要环节。在该项目中，我们选择将 S2S 功能放在 A 核中实现信号与服务的转换，但同样也可以在传统的 M 核中完成这一任务。

在使用 MBD 开发过程中，我们遇到了一些小问题。由于各家厂家对标准的理解存在差异，他们在生成代码以及应用层与底层结合时，可能会遇到一些兼容性问题，这需要工艺厂家不断优化和改进。

在 CP 环境下，我们的工作流程相对成熟。首先进行网络拓扑设计，然后进行软硬架构设计。接下来，将设计文件导入到另一个架构工具中，进行内部行为的设计。最终，在 Simulink 中进行建模和算法开发。

（以上内容来自长城汽车总工程师杜建福和迈斯沃克首席应用工程师 / 技术客户经理龚小平于 2025 年 3 月 18 日 -19 日在第六届软件定义汽车论坛暨 AUTOSAR 中国日发表的《使用 MBD 进行 AUTOSAR 平台的 SOA 软件开发》主题演讲。）