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

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

 

◾ 客户收益

       · 评估资源使用率，指导芯片选型和工程优化

       · 保证软件的任务、中断预留堆栈空间和分配周期合理性

       · 保证芯片内存占用率和 CPU 负载在阈值范围内

       · 开展符合功能安全和 ASPICE 流程要求的测试

 

◾ 测试内容

       · 内存：自动化分析最差工况的堆栈用量、RAM/ROM/Flash 占用率

       · WCET：分析最差工况下的执行时间，测试周期稳定性和任务实时性

       · 调度仿真：模拟任务调度，建模仿真 CPU 负载率和任务占比

 

◾ 方案特点

       · 借助 AbsInt 工具，针对工程二进制可执行文件进行自动化分析，无需依赖源码

       · 支持 PPC、V850、Tricore、ARM 等多种架构芯片的堆栈、时间分析

       · 分析遍历工况，结果涵盖程序的各个入口

       · 图形化展示最差工况下的执行路径和占比用量，指导性能优化

       · 不依赖测试用例，执行效率高，项目周期短

       · AbsInt 工具满足 ASIL D 等级功能安全标准

 

基于 AbsInt 的测试流程

 

函数调用关系及用量显示

 

数据化表格用量展示

 

 基于 RVS 的动态性能测试

 

◾ 客户收益

       · 在 PIL、HIL、车载环境下进行时序分析，确保软件行为安全

       · 可视化监测任务调度和 CPU 负载，为系统升级提供优化参考

       · 保证多任务和多核运行的合理性，规避优先级反转、死锁等时序问题

       · 开展符合功能安全和 ASPICE 流程要求的测试

 

◾ 测试内容

       · WCET：分析任务 / 中断的最差工况执行时间，测试周期稳定性和响应实时性

       · 任务调度：评估 WCRT，监测任务时序特征，图形化显示多核、多任务调度关系

       · 负载率：基于实际工况对 CPU 负载率进行实时统计和分析，评估极限负载下的 CPU 负载率占用情况

 

◾ 方案特点

       · 借助 RVS 分析套件进行实时数据采集和分析，还原实际环境下的执行工况

       · 支持全量数据采集和长时间监测运行，追踪定位软硬件交互情况

       · 自定义程度高，项目复用性强，可针对任意函数、模块或代码段进行时序分析

       · 支持集成多种处理器 + 编译器环境，实现 PIL/HIL/ 车载环境下分析

       · RVS 工具可以支持产品功能安全认证等级 ASIL D

 

基于 RVS 的测试流程

 

时序调度分析

 

 基于自动化测试框架的压力测试

 

◾ 客户收益

       · 保证通信、诊断、操作系统、IO 驱动、网络管理等模块在压力场景下不存在致命风险

       · 作为功能验证的补充，发现软件质量潜在问题，确保软件鲁棒性、稳定性

       · 构建标准化的压力测试用例模板，有助于形成符合功能安全要求的测试流程

       · 测试用例搭载自动化测试框架进行测试执行、用例管理、问题追溯

 

◾ 测试内容

       · 针对 NVM、IO 驱动、CAN、LIN、ETH、COM 等模块进行压力场景构建

       · 分析系统不同组件间的时延特性，验证模块运行时间稳定性

       · 验证在异常注入、高频触发、总线故障等因素影响下的功能稳定性

       · 验证极限工况下的核心功能有效性及软件后续响应的合理性

 

◾ 方案特点

       · 借助自动化测试框架执行测试用例，测试周期短、测试效率高、测试复用性强

       · 支持软硬件交互，可监测底层函数、上层报文、外部信号等

       · 支持在 PIL/HIL 环境下开展测试，可同步注入多种激励进行测试验证

 

测试流程示意

 

测试框架示意