为基于模型设计的混合动力汽车电池管理系统开发符合AUTOSAR和ISO 26262标准的软件

当我们的团队为沃尔沃XC90插电式混合动力车开发电池管理系统(BMS)时，使用AUTOSAR是沃尔沃的要求，但我们可以自由选择自己的开发方法和工具。我们将这个项目视为一个建立基于模型设计的工作流的机会。使用此工作流，我们可以将基础软件层中特定于硬件的模块的开发留给在该领域具有专业知识的供应商，而将重点放在建模、模拟和验证应用程序层中的控制逻辑上。

基于模型的MATLAB设计^®和仿真软件^®使我们能够增加组件重用，减少手工编码，改善与客户的沟通，并交付更高质量的BMS。在引入基于模型的设计之后，在每个软件版本中确定的软件问题的数量从大约22个下降到少于9个——远远低于我们的项目目标。

为什么基于模型的设计?

我们选择基于模型的设计，部分原因是它使我们能够建模和模拟构成BMS核心的复杂算法和行为。我们希望在客户验收测试之前，通过软件在环(SIL)和硬件在环(HIL)测试自动化质量检查并彻底验证我们的设计。

我们需要开发的算法需要来自不同学科和背景的工程师的贡献，包括电化学、数学、控制设计和软件工程。我们知道基于模型的设计将为他们提供一个共同的平台和共享的语言来进行设计上的协作。

可重用性是推动我们做出决定的另一个关键因素。我们已经组装了一个我们想在沃尔沃BMS项目中使用的组件库，我们想继续开发这个库，以加快与原始设备制造商未来项目的开发。到目前为止，在Volvo项目中，我们已经跨五个不同的模型使用了核心库。有了这个核心库，我们启动一个新的变量模型，甚至一个新的项目所需的时间就少得多了。

开发AUTOSAR软件组件

通过在AUTOSAR创作工具中建模系统架构和定义软件组件描述，我们开始了自顶向下的开发方法。然后我们将组件描述(作为ARXML文件导出)导入到Simulink中。

在Simulink和statflow中工作^®，我们使用在导入过程中自动创建的骨架模型对BMS的控制逻辑和算法行为建模。我们还将Simulink模型中的信号映射到AUTOSAR组件描述中的信号。在这个阶段中，我们重用Simulink组件，用于SoC(充电状态)估计、SoH(健康状态)估计、控制逻辑、诊断逻辑等等，这些都来自于我们从早期项目中组装的核心库。我们增加了定制逻辑以满足沃尔沃对这个特定项目的要求，包括插电式混合动力汽车的马达仲裁逻辑。

在Simulink中开发控制器模型时，我们经常使用model Advisor检查样式指南和建模标准的遵从性。我们还使用Simulink design Verifier™检查了死逻辑、除以零的错误和模型中的其他设计错误。

LG化学的电化学模拟小组建立了电池组电化学电池的数学模型。我们将这个团队的MATLAB代码合并到一个Simulink植物模型中，用它来模拟我们的控制器模型。

生成代码和自动化测试

一旦我们完成了初始设计，我们的目标就是尽可能地自动化剩下的工作流，包括代码实现和测试执行。我们使用嵌入式编码器从我们的控制器模型中生成符合autosar的C代码^®以及AUTOSAR标准的嵌入式编码器支持包。

为了验证生成的代码，我们使用测试用例执行SIL测试，测试用例集中在三个方面:核心库组件、映射信号和自定义逻辑。

在自动化SIL测试期间，我们使用Simulink coverage™测量了执行覆盖率、修改的条件/决策覆盖率(MC/DC)、查找表覆盖率和周期复杂度。这些指标使我们能够确保我们的测试执行了整个设计。在依赖手工编码的开发过程中，几乎不可能诊断在集成测试中发现的难以调试的问题，特别是对于来自软件组件(SWC)的输出由第二个SWC处理，然后反馈到原始SWC的系统。通过基于模型的设计，我们可以在模拟过程中显示每一层的信号，并看到错误是如何通过反馈循环中的SWCs传播的，这使得潜在的问题更容易识别和纠正。

我们将生成的代码部署到目标嵌入式处理器中进行HIL测试，在HIL测试中模拟车辆的全电动动力系统。这些最终测试导致由我们的客户进行车辆验证测试。如果客户测试发现了错误，我们可以使用测试日志文件在Simulink中再现问题，通过模拟识别根本原因，并调整模型以解决问题。我们作为工作流程的一部分进行的广泛测试导致了软件问题的显著减少(图1)。

下一个步骤

我们使用AUTOSAR和基于模型的设计为沃尔沃开发的BMS已经获得了ISO 26262基于功能安全的汽车安全完整性C级(ASIL C)认证。对于这个初始项目，我们手动完成了大部分认证任务。我们已经自动化了许多任务，并减少了生成认证报告所需的资源。

我们的团队现在正在使用我们为沃尔沃BMS建立的工作流程，为越来越多的汽车OEM客户开发AUTOSAR软件组件。