ECU电控软件开发及测试介绍_汽车电子与车联网-面包板社区

楼主

ECU电控软件开发及测试介绍

原创

经纬恒润

523 主题
527 帖子
4343 积分

身份：LV5 资深技术员

E币：1849

发消息

 761

 0

发表于 2024-9-26 15:33:45

显示全部楼层

伴随着电动化、智能化、网联化等技术发展的时代背景，各行各业电子电气架构都在发生深度变革。新型架构逐渐取代传统架构，比如汽车、工程机械、储能、船舶等领域，电子电气架构从传统分布式向域集中式，甚至向着中央集中式发展，控制器功能呈现集中化、复杂化的特点。为了提升开发效率、提高软件的稳定性以及便于平台移植，基于 AutoSar 架构开发复杂软件已成为行业共识。

另外，行业内竞争愈发激烈，开发周期大大压缩，加之软件复杂度的提升，在快速迭代的情况下确保软件质量是一个重要课题。加之 ASPICE、ISO26262 等过程体系和法规标准的要求，如何开发符合 AutoSar 架构的应用软件、评估软件质量和性能、优化软件结构、验证压力场景下的 ECU 稳定性成为各厂商面临的新挑战。

本文重点介绍符合 AutoSar 架构的应用软件开发、MBD 开发模式下的软件质量评估与优化方案、复杂场景下的 ECU 性能压力测试方案。

符合 AutoSar 架构的应用软件开发介绍

对于 AutoSar 软件架构，分为经典平台 AutoSar CP 和自适应平台 AutoSar AP，二者应用场景存在一定差别：AutoSar CP 具有高安全、高实时性，其通常部署在微控制器 MCU 类型芯片或多核异构芯片 M 核；AutoSar AP 具有动态性和可扩展性，适用于大数据并行处理和高性能计算等应用场景，通常部署在 MPU 或多核异构芯片 A 核。目前从行业内来看，无论是域控制器还是中央 + 区域控制器，通常都是多核的，甚至是多核异构的，不同核根据实际使用需求部署 AutoSar CP 或 AP，基础软件通常采用标准的 BSW 协议栈。下图所示是 AutoSar 软件架构示例：

AutoSar 软件架构

那对于应用层软件来说，如果要开发符合 AutoSar 架构的软件，需要考虑以下两个重要问题：

· 采用何种开发工具链

· 采用何种开发模式

对于应用软件开发工具链，通常涉及 SWC 软件架构设计工具和软件编程实现工具。SWC 软件架构设计工具主要对应用层软件架构进行实现，定义 SWC、配置 SWC 的交互接口、配置 Runnable、导出 ARXML 文件等，一般不同品牌的协议栈都有对应的 SWC 软件架构设计工具，经纬恒润自研 AutoSar 协议栈提供工具链方案为 EAS-SWCDesigner。

EAS-SWCDesigner 界面

而软件编程实现可基于图形化编程自动生成代码或手写代码的方式，AutoSar CP 和 AP 架构应用层软件开发实现方法略有差别，CP 架构应用层更多采用基于模型设计方法开发，工具链通常采用 Matlab/Simulink，其对 CP 架构应用层开发的支持比较完善且成熟，但是由于其对 AP 架构应用软件开发支持还存在不完善的点，故 AP 架构应用层软件开发目前更多还是基于手写 C++ 代码的方式，工具链基于一些代码编辑工具比如 Vscode。

对于应用软件开发模式，分为自上而下开发、自下而上开发和双向开发模式。自上而下开发比较适用于正向开发流程，在有 EE 架构输入的情况下采用该模式，这种模式的好处是可以继承 EE 架构的工作产品，但是缺点是工作链路会比较长，应用层和底层软件开发都需要依耐 SWC 架构设计导出的 ARXML 文件作为输入，影响开发迭代效率；自下而上开发是直接在软件编程工具实现软件，然后配置 AutoSar 接口，再导出 ARXML，然后对 ARXML 文件进行合并，这种方式比较适用于没有 EE 架构输入的情况，应用软件开发工程师独立配置 AutoSar 接口，这种模式的好处是不依耐 AutoSar 工具链，比较灵活，但是缺点是对每个应用软件开发人员 AutoSar 知识要求高些；双向开发模式就是结合自上而下和自下而上开发模式的优点，针对第一版软件采用自上而下开发模式，后续版本软件更新迭代采用自下而上开发模式。

应用软件开发模式

MBD 开发模式下的软件质量评估与优化方案

MBD 全称是 Model Based Design（基于模型设计），是一种以可视化模型开发为主的开发方式，区别于传统的以文本编码为媒介的代码开发。采用模型化的方式来描述控制算法设计，无论是可读性、可维护性、可移植性、测试验证的便利性等方面，相比于从前手工 C 代码都有长足的进步。基于以上基于模型开发的特点基于 Simulink 的模型化 + 自动代码生成的开发方式在汽车电子行业正在逐渐演变成开发的标准配置。接踵而来如何保证 MBD 开发方式下软件质量问题也成为现阶段人们热议的话题。

针对软件质量直接有效的手段便是开展完备的测试或在软件开发过程中优化软件结构减少问题的引入。

如何开展完备的模型测试？

模型验证方法可以分为静态验证和动态验证，模型静态验证，是一种通过 MAAB 和 dSPACE 等建模公司提供的建模规则指南来验证模型设计是否符合规则的测试方法。此外，还有一种模型度量元指标检查方法，可以分析模型的复杂程度，以此评判模型在可维护性、可移植性、可重用性等不同维度的质量特性。综上所述，在模型静态验证部分，可以看出有两种方法：建模规范规则检查和模型度量元指标检查。与模型静态验证不同，模型动态验证可以通过比较在执行实际模型时的输出值来进行验证。通过根据用户输入预期结果值对比实际模型结果值来动态验证模型。通过检查模型的覆盖率，可以提高测试用例针对需求的覆盖率以及测试用例的充分性。此外借助 ASPICE 过程管理的思维，在整个测试过程中加入过程管理思维，确保测试过程、测试环境、测试策略的可靠性以及测试用例的充分性、一致性、追溯性，以此确保模型质量。

如何优化软件结构？

现阶段我们模型生成的代码是否会存在以下问题：

· 生成代码一个函数可能会上万行代码

· 看不懂 matlab 生成代码后的变量的定义及过程转化

· 要不要针对模型生成的代码做修改

优化软件的前提是已经开展静态测试优化完毕模型结构。确保模型结构的规范性。针对每一个软件设计单元生成独立函数、每一个软件组件生成与之相对应的 C 文件可以确保模型生成代码的结构清晰。同时不对模型生成的代码做任何的修改是 MBD 开发过程中的软件维护准则。

综上让我们一起来期待恒润针对 MBD 开发模式下的软件质量评估与优化的解决方案。

复杂场景下的 ECU 性能压力测试方案

随着控制器数量的激增和模块交互复杂度的提升，只针对软件基础功能验证的效果存在一定的缺陷，越来越多的项目实践表明，软件的偶发性故障需要从软件性能指标、压力场景来进行补充验证，以确保软件产品的质量。

性能测试针对 ECU 电控软件的内存（堆栈、RAM/ROM/FLASH）、CPU 负载进行最差工况的分析，保证资源占用的合理性；压力测试构建通信、IO 驱动、诊断、网络管理等模块的异常注入、总线故障、高频触发等场景，保证软件功能在压力场景下不存在致命风险。

基于 AbsInt 的静态性能分析

◾ 客户收益