从架构到代码：PREEvision与MATLAB联合开发AUTOSAR软件组件

PREEvision与MATLAB联合开发AUTOSAR软件组件一条从架构到代码的实战路径做汽车电子软件开发的同行对PREEvision和MATLAB这两款工具应该都不陌生。PREEvision负责E/E架构设计把整车级的控制器、传感器、总线网络、软件架构理得清清楚楚MATLAB/Simulink则负责控制算法的建模与仿真在电机控制、电池管理、车身控制这些领域几乎是标配。而AUTOSAR标准的存在让这两套工具能够通过ARXML文件这个“共同语言”完成从架构设计到代码落地的完整闭环。这篇文章我想重点聊一个非常具体的开发场景在PREEvision里定义好AUTOSAR软件组件SWC的架构和接口然后导入到MATLAB/Simulink里去实现Runnable的内部逻辑再把生成的代码和ARXML文件回导到PREEvision做集成最终产出可供RTE生成的完整软件组件描述。整个过程踩过的坑、需要注意的版本匹配、数据映射规则、代码生成配置我会尽量按实操顺序写清楚。无论你是刚接触AUTOSAR的入门工程师还是已经在项目里用了这套流程但经常卡壳的同学这篇文章都值得花十分钟读完。1. 先搞清楚三者的关系PREEvision管什么MATLAB管什么AUTOSAR连接了什么1.1 为什么要组合使用而不是二选一很多刚入行的朋友会有一个困惑既然PREEvision也能画SWC内部的行为模型Simulink也能建Runnable为什么还要把两套工具串起来用这里面的核心逻辑是分工不同而不是功能重叠。PREEvision的价值在于全局架构治理。它能把某个ECU的软件架构放在整车E/E架构的上下文里统一管理比如哪个SWC负责跟CAN总线交互、哪个SWC提供标定接口、哪个SWC的Runnable需要被OS调度到某个优先级这些信息都要在架构层面确定下来。而MATLAB/Simulink的价值在于算法快速迭代控制器开发早期你需要在Simulink里反复调PID参数、验证状态机跳转逻辑、跑仿真看波形这些工作放在PREEvision里做会非常笨拙因为它的强项不是控制算法仿真。所以实际的工程做法是架构工作在PREEvision里完成算法开发在MATLAB里完成AUTOSAR标准负责把两条线串起来。PREEvision导出ARXML描述SWC的静态架构Simulink导入这个ARXML确认接口然后模型内部实现算法逻辑最后通过Embedded Coder生成C代码和更新后的ARXML再回到PREEvision做后续的RTE生成与应用层集成。1.2 AUTOSAR软件组件到底是什么AUTOSAR软件组件Software ComponentSWC是AUTOSAR分层架构中应用层的基本功能单元可以理解成一辆车上某个ECU里面一个可独立设计、独立测试的功能模块。比如一个座椅控制ECU可能有座椅调节SWC、记忆功能SWC、通风加热SWC它们各自通过端口Port对外通信端口上挂的是发送/接收接口Sender-Receiver Interface或客户端/服务端接口Client-Server Interface。SWC内部的核心是Runnable也就是真正要被调度执行的可运行实体。一个SWC可以包含多个Runnable每个Runnable对应不同的触发事件有的每隔10ms定时跑一次有的收到某条CAN信号后触发有的在某个标定参数被写时执行。这些触发关系的配置在Simulink里通常通过Function Call子系统加上AUTOSAR事件映射来实现。1.3 这套流程覆盖的典型项目阶段我实际走下来的经验是PREEvision与MATLAB的联合流程主要覆盖下面这几个阶段阶段一系统架构设计。在PREEvision中定义ECU列表、SWC划分、端口接口、数据类型、Runnable的触发事件完成虚拟整车环境下的功能验证。阶段二算法级开发。把PREEvision导出的SWC描述文件导入Simulink开发人员只需要在模型里专注实现Runnable内部的控制逻辑、状态机、查表逻辑。阶段三自动代码生成与集成。用Embedded Coder和AUTOSAR Blockset生成规范化的应用层C代码和ARXML软件组件描述然后回到PREEvision完成RTE契约检查、生成RTE、与BSW模块做集成。阶段四MiL / SiL / HiL验证。模型在环、软件在环、硬件在环三个阶段验证算法实现与架构定义是否一致。说白了前三步决定了软件“能不能跑起来、跑得对不对”第四步决定“跑起来之后和真实环境配合得怎么样”。这套流程越早跑通后续项目越省心。2. 环境准备版本匹配与工具链配置这是最容易踩坑的一步2.1 版本匹配永远是第一位如果你去Vector官方文档和MATLAB官方文档里翻一圈会发现两边都会给出一个兼容性列表。很多项目卡壳不是流程不熟悉而是工具版本之间不兼容ARXML导来导去格式解析不了。我个人的经验基于AUTOSAR 4.x版本做开发的话建议的匹配组合大致是工具建议版本说明PREEvision9.5 / 9.10 / 10.0 及以上不同版本对AUTOSAR 4.2.x、4.3.x的支持程度不同越新越好MATLAB / SimulinkR2021a以后的版本R2021a之前AUTOSAR Blockset的成熟度不够接口映射经常出问题Embedded Coder随MATLAB版本需要单独安装许可证AUTOSAR Blockset随MATLAB版本老版本叫AUTOSAR Target Configuration功能差别较大AUTOSAR标准版本4.2.2 或 4.3.0全链路必须统一PREEvision选什么版本MATLAB侧就要按同版本生成这里有个非常重要的提醒ARXML的版本号在文件头里就有你可以在XML文件的根节点看到类似xsi:noNamespaceSchemaLocationAUTOSAR_4_2_2.xsd这样的声明。导入时哪边报错先看这个版本号是不是两边一致。我碰到过好几次PREEvision侧用的4.3.0MATLAB默认配置生成的是4.2.2导入时报了一堆看不懂的Schema校验错误。2.2 PREEvision侧需要做的配置PREEvision作为一个重型的E/E架构工具第一次上手确实有点劝退。它不只是画架构图还带数据库版本管理所有对象都有版本状态。在导入外部ARXML之前建议先把下面几件事确认好确认工作区的AUTOSAR版本设置。路径一般在菜单栏的Project Settings或Options里找到AUTOSAR选项把版本设置成和MATLAB一致的AUTOSAR版本。确认模型库Model Library中已加载了完整的AUTOSAR元素定义。如果缺元素导入外部ARXML时会出现“无法解析”的提示。针对版本管理Baseline Management导入前先创建一条工作分支避免直接在主分支上做实验。工具内部的对象锁定机制比较严格在未锁定状态下导入外部文件容易造成冲突。PREEvision还有一个特性它不只是把ARXML当作数据导入而是会把XML里的元素转成工具内部的模型对象。这意味着ARXML里的元素名字、数据类型引用路径必须和PREEvision内部库的定义完全一致否则导入会失败或产生悬空引用。2.3 MATLAB侧需要装的组件如果你只用Simulink做建模仿真而不涉及AUTOSAR那基本不需要额外的设置。要走代码生成和ARXML导入导出这条路必须在MATLAB的Add-On Explorer或License Center里确认以下几项Simulink基础不用多说。Embedded Coder生成嵌入式C代码的核心工具箱。AUTOSAR Blockset负责AUTOSAR特定配置、ARXML导入导出、Runnable与Simulink模型之间的映射。Simulink CoderEmbedded Coder的上游依赖自动一起安装。安装完之后在MATLAB命令行输入autosar或打开Simulink的Configuration Parameters如果能看到AUTOSAR这个配置页就说明环境OK了。看不到的话多半是AUTOSAR Blockset没有正确安装或者许可证没有包含这个工具。这里再多说一句MATLAB中设置AUTOSAR相关参数最核心的入口是autosar.Configuration这个类。你可以用命令行创建一个配置对象也可以直接在Simulink模型配置界面里操作。两种方式实质改的是同一个XML配置文件熟悉命令行之后用脚本批量处理会方便很多。3. 完整实操流程从SWC定义到代码生成回导3.1 第一步在PREEvision中定义软件组件架构拿到一个实际需求比如“开发一个BMS的SOC估算SWC”第一步不是在Simulink里画模型而是先在PREEvision里把这个SWC的外部骨架定下来。要定义的内容包括SWC本身在PREEvision的AUTOSAR浏览器中新建一个Atomic Software Component类型选择Application SWC。名字建议符合公司命名规范比如Bms_SocEstimation因为这个名字会一路带到代码和ARXML里中途改名的代价非常高。端口Port根据需求文档定义需要对外交互的信号。比如SOC估算结果需要周期发送那就定义一个PPort挂在一个Sender-Receiver接口上接口里有一个数据元素SocEstimate_Val类型是float32。又从CAN接收电池总电压和总电流那就需要两个RPort。注意端口名字和接口定义在PREEvision里就固定了后续MATLAB导入时完全依赖这层定义。Runnable与事件在SWC内部创建Runnable。最常见的是周期触发比如Runnable_10ms触发事件是TimingEvent周期10ms。也可能是DataReceivedEvent表示收到某个数据元素时触发。这些事件类型在AUTOSAR规范里定义得很清楚PREEvision的操作界面一般通过属性面板直接配置。数据类型与标定量AUTOSAR的数据类型系统比较严格分为Application Data Type、Implementation Data Type、Base Type三层。PREEvision中需要把接口的数据元素和Implementation Data Type关联起来否则代码生成时无法确定最终C语言里用uint16还是float32。标定量Parameter和测量量Measurement在PREEvision里也有对应的定义方式通常通过ParameterDataPrototype挂在SWC上。这个阶段一定要花足够时间把接口定义清楚因为一旦进入后续流程接口的变动会引起连锁反应。我见过太多项目因为前期端口定义不完整后面在Simulink里发现少了一个信号不得不回到PREEvision改架构、再导一遍ARXML、再重新映射模型白白浪费两三天时间。3.2 第二步导出ARXML并导入MATLAB在PREEvision里完成SWC定义后选中这个Component在右键菜单或菜单栏中找到“Export AUTOSAR”相关命令。导出时要留意几个选项AUTOSAR版本选择你在工程里统一约定的版本比如AUTOSAR 4.2.2。导出内容范围建议同时勾选SWC描述SWC Description和相关的接口、数据类型定义。有些情况下PREEvision会把依赖的接口和数据类型拆到不同的包里导出时要确保引用完整。文件路径导出的ARXML文件命名不要带空格和特殊字符Bms_SocEstimation.arxml这样的命名比较稳妥。然后切换到MATLAB侧。在Simulink里新建一个空白模型或者在现有模型上操作。打开代码生成配置选择作为AUTOSAR软件组件导入% 创建AUTOSAR配置 arProps autosar.api.getSimulinkMapping(modelName); % 或者从ARXML创建模型 autosar.importer.createModelFromARXML(Bms_SocEstimation.arxml, ModelName, Bms_SocEstimation);autosar.importer.createModelFromARXML这个接口会自动解析ARXML在Simulink模型中自动创建对应的Inport、Outport以及Function Call子系统对应PREEvision里定义的Runnable。导入后模型从外观看就是一个带若干输入输出端口、内部有几个触发子系统的普通Simulink模型但模型的配置参数里已经带上了AUTOSAR相关的属性比如端口名对应ARXML里的元素名、子系统触发条件对应ARXML里的事件。导入成功后务必要做一次模型更新CtrlD确认没有任何解析错误。如果ARXML里面有PREEvision特有的属性或扩展标记MATLAB虽然不会崩溃但可能在日志里输出Warning。这时不用太紧张先看Warning是否影响模型结构如果只是“Unsupported element ignored”这类提示一般不影响主流程。3.3 第三步在Simulink中实现SWC内部行为导入完成后SWC的骨架已经在Simulink里准备好了。现在要做的事情和平时做Simulink建模几乎一样在每个Function Call子系统内部添加你的算法逻辑。以SOC估算为例10ms周期触发的Runnable内部可能是一个查表/滤波算法或者一个Kalman滤波的迭代更新逻辑。你可以把整个过程拆成几个子系统也可以直接在Function Call子系统内部画状态机。如果用到Stateflow确保状态机可以被Embedded Coder正确翻译成C代码注意Stateflow里的事件名、数据名避免使用MATLAB关键字。有几个在AUTOSAR模式下特别要注意的点函数原型Runnable对应的子系统会生成一个对应的C函数函数名就是ARXML里定义的Runnable名。如果Runnable定义的是Runnable_10ms生成出来的C函数就是void Runnable_10ms(void)。函数内部的局部变量和全局变量作用域则取决于你在模型里怎么定义信号线。显式数据访问AUTOSAR规范要求数据访问要通过端口或接口尽量不要用Model中的全局Data Store Memory。虽然Embedded Coder也支持生成全局变量但在AUTOSAR架构下这种做法会破坏SWC的封装性集成阶段很容易和RTE变量发生冲突。标签与注释模型里每个模块、每条信号线的标注会直接影响生成代码的注释质量和可读性。建议花点时间把信号线命名成有意义的物理量名字比如BatteryCurrent_A而不是Signal1。仿真验证先行在做代码生成之前建议先在Simulink里用测试数据把模型逻辑跑通。纯Simulink仿真环境下没有OS调度和RTE开销行为大概率符合预期这一步能排除掉很多算法层面的低级错误。3.4 第四步代码生成与ARXML输出模型内部逻辑开发完毕并完成仿真验证后进入代码生成阶段。在Simulink的Configuration Parameters里找到Code Generation按下面的关键项配置系统目标文件选择autosar.tlcAUTOSAR模式或者ert.tlcEmbedded Coder模式。如果走AUTOSAR Blockset通常会直接定位到AUTOSAR目标并自动生成ARXML文件。生成的代码语言选C编译器优化级别、代码样式按公司规范配置。代码生成时是否生成日志文件、注释格式、变量命名规则都要按要求在Embedded Coder选项里设置。配置完成后点击Build按钮。Embedded Coder会做下面几件事检查模型中所有端口和AUTOSAR端口的映射是否完整。缺一个映射报告里会明确列出。生成C源码文件通常按SWC分组例如Bms_SocEstimation.c和Bms_SocEstimation.h。生成ARXML输出文件其中包含了SWC描述、Runnable与事件的配置、端口接口定义以及生成代码的代码描述信息Code Descriptions即ARXML中CODE相关描述RTE生成时依赖这些信息找到函数原型。这里生成出来的ARXML比PREEvision导出的那份要更完整因为它增加了与代码实现相关的描述。后续RTE生成工具就是依靠这份ARXML里的代码描述把Runnable函数名和RTE调度事件绑定起来。特别提醒生成ARXML的文件名、路径要和PREEvision侧导入设置保持一致否则导入PREEvision后可能出现文件引用找不到的情况。3.5 第五步回导PREEvision并生成RTE在MATLAB生成了代码和ARXML之后回到PREEvision执行反向集成。操作步骤是在PREEvision里选中之前导出ARXML的SWC使用导入功能把MATLAB生成的新ARXML文件导回来。这一走流程PREEvision会用新的ARXML内容更新SWC对象补充代码相关描述并校验架构定义、代码实现的契约是否一致。比如说ARXML里Runnable的周期变成了10ms但PREEvision里原来定义的是5ms这里就会产生一个一致性检查的报错。完成回导后PREEvision里就可以继续做后续的RTE生成了。RTE生成工具会依据SWC描述和BSW模块配置生成RTE相关的C代码把Runnable的调用挂到OS任务上。Runnable内部的应用逻辑代码已经由MATLAB生成好了RTE部分又把这些Runnable组织到周期任务或事件链路上两部分拼起来就是完整的应用层C runtime代码可以直接拿去和底层MCAL、BSW代码做链接了。4. 常见问题与排查技巧实录4.1 ARXML导入导出时版本不兼容这是出现频率最高的问题。表现是MATLAB弹出类似Unable to parse ARXML because the AUTOSAR schema version ... is not supported的报错或者PREEvision导入时直接拒绝打开文件。排查思路很简单依次确认三处的AUTOSAR版本PREEvision导出界面上选的版本MATLAB的autosar.Configuration里配置的Target Release生成的ARXML文件头标注的Schema版本。三者必须一致。如果你项目里混用了不同版本的AUTOSAR例如BSW配置用的是4.2.2而SWC描述是4.3.0集成阶段工具经常会报错因为RTE生成工具要求所有输入文件的Schema版本严格一致。4.2 接口映射失败或者映射后对不上在Simulink的Model Data Editor里经常能看到端口映射状态显示为“unmapped”或者“incompatible”。原因主要集中在以下几个方面端口名字不一致。PREEvision里端口叫BatteryVoltage但Simulink模型里Inport的名字叫Volt两者对不上映射失败。解决办法是在Simulink里用映射工具将Inport绑定到指定的接口端口而不是自动匹配名字。方向不对。PREEvision里这个端口是输入口RPortSimulink模型里却放了一个Outport映射当然失败。接口类型不一致。ARXML中定义的数据元素是某个结构体或数组但Simulink模型端口的数据类型是double两者不匹配。这里推荐一个检查技巧在Simulink里打开AUTOSAR映射视图逐端口查看映射状态。操作路径是在模型上右键选择AUTOSAR AUTOSAR Component Designer在Software Mapping面板下可以看到每个Inport/Outport/Function Call与AUTOSAR Port/Runnable的映射情况状态一目了然。4.3 数据类型不匹配导致代码生成报错AUTOSAR的数据类型三层结构Application Type / Implementation Type / Base Type容易让人头晕。比如你在PREEvision里给数据元素定义了Application Type Voltage_TImplementation Type uint16但Simulink模型里对应的数据端口是single类型生成代码时就会报类型不匹配或者做隐式转换轻则报警告重则直接报错。解决办法有两种一是严格按ARXML中的Implementation Type来设置Simulink端口的类型。比如Implementation Type是uint16就把端口的数据类型也设为uint16注意Simulink的uint16和AUTOSAR的uint16语义完全对应可以直接用。二是通过AUTOSAR Blockset提供的Type Mapping机制在Simulink的内部类型和AUTOSAR类型之间建立映射关系。比如模型内部用single算SOC对外接口的类型是uint16映射之后代码生成时会自动插入比例变换或类型转换代码。实际操作中我建议尽量在PREEvision侧就把类型定义好Simulink侧完全按照接口类型建模这样生成代码的逻辑最清晰不容易出现隐藏的精度问题。4.4 Runnable触发配置错误导致行为异常有些项目里Simulink模型仿真没问题集成到真实环境后功能却不对比如某个状态机不按时更新或者某个信号接收不到。这时候大部分原因出在Runnable的触发配置上。常见的错误包括PREEvision中定义的是DataReceivedEvent但Simulink里Function Call子系统的触发源配置成了一个时钟信号。这样一来生成代码的Runnable函数实际是周期调用而不是数据到达时调用RTE生成的调度逻辑就和原架构不符。ARXML里定义了多个事件触发同一个Runnable比如既配置了10ms周期事件又配置了数据接收事件实际使用中Runnable可能会被多次调用或者因为优先级冲突导致行为不确定。建议在PREEvision阶段就严格控制一个Runnable只关联一种事件类型如果确实需要多事件触发最好在架构评审阶段充分讨论避免一个Runnable承担太多触发条件。4.5 集成后跑测出现时序问题代码和RTE都生成好了把应用层与底层集成后在HiL台架上面跑测试经常出现时序相关的诡异问题比如某条信号偶尔延迟一个周期某个标定值写入后没有立即生效。这类问题的本质通常是Runnable的周期、优先级和它访问的数据元素之间存在跨任务竞争。AUTOSAR规范要求Runnable访问数据时通过RTE接口RTE会保证数据一致性但如果有代码绕过RTE直接操作了底层缓冲区或者两个Runnable被分配到了不同优先级任务且访问同一个数据元素那就可能产生竞争条件。排查建议先在PREEvision或RTE配置工具里检查Runnable到Task的映射确认没有把存在数据依赖的Runnable放在相互抢占的任务中。另外在生成的C代码里搜索函数级全局变量确认没有绕过端口直接访问共享内存的情况。这类问题在代码Review阶段发现成本最低到了台架测试阶段定位往往要花数周。5. 我的几点实操体会这套PREEvision与MATLAB联动的流程我自己完整走下来最大的感受是工具链本身并不复杂难的是对流程纪律的坚持。接口定义必须在PREEvision侧先行冻结Simulink模型只做内部算法实现代码生成参数全局统一这样每一步的产出物才是可预期、可复现的。一旦某个环节图省事跳过了架构评审或者直接在Simulink侧胡改了端口名后面必然要付出数倍的时间去回补。另外有两个小的实用经验分享一下一是在Simulink模型里做开发时建议开Git做本地版本管理每次把模型和生成的ARXML一起提交。模型是二进制文件不方便diff把ARXML的文本差异作为Review依据非常有效。第二个经验是最好在PREEvision侧和MATLAB侧都使用脚本或模板来固化流程PREEvision的API模型操作和MATLAB的autosar.api函数都可以批处理项目量大时能省掉大量重复操作。最后再补一个容易被忽视的细节MBD工具链的浏览器缓存和临时文件目录需要定期清理特别是在跨项目切换时PREEvision和MATLAB都会在用户目录下缓存很多配置文件积累过多后可能引发一些匪夷所思的导入导出故障。遇到莫名其妙的问题先清缓存重启工具再考虑查版本和配置。希望这些踩坑经验能帮你少走一些弯路如果你也有类似的联合开发经历欢迎一起交流。