长城汽车&迈斯沃克：使用MBD进行AUTOSAR平台的SOA软件开发

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软件开发》主题演讲。）