KPIT通过基于模型的设计建立了符合autosar的软件开发的端到端流程

除了解耦后处理系统的软件和硬件之外，KPIT的客户还需要向系统添加新功能。他们还需要解决现有开发工作流的缺陷，这是基于手工编写嵌入式C代码。在这个工作流程中，工程师很少有机会验证系统需求，直到进入项目，这时需求可以在电子控制单元(ECU)上进行测试。客户希望减少手工编码，并在开发早期验证他们的设计。

同时，客户需要一个开放的、标准的汽车软件架构，以确保交付的软件与运行在同一ECU上的其他软件兼容。

KPIT工程师为客户建立了基于AUTOSAR和基于模型的设计的软件开发工作流。

在这个工作流程中，工程师首先分析系统需求，并定义由各个AUTOSAR软件组件组成的架构。

接下来，团队定义各个组件的软件需求，使用AUTOSAR创作工具设置接口并添加其他配置细节。

遵循自顶向下的方法，团队从创作工具导出软件组件描述ARXML文件。他们将这些文件直接导入到Simulink中，以创建一个包含接口块和在创作工具中定义的autosar相关设置的Simulink骨架模型。

在Simulink和Stateflow中工作^®，他们详细阐述了应用软件的骨架模型，添加了顺序逻辑和其他块来实现新功能。

在检查模型是否符合MathWorks汽车咨询委员会(MAAB)的指导方针后，团队运行了循环模型模拟，以根据需求测试设计的功能。

团队使用Embedded Coder生成了符合autosar的C代码以及更新的软件组件描述ARXML文件^®以及AUTOSAR标准的嵌入式编码器支持包。

他们使用生成的C代码进行软件在环测试，验证这些测试的结果与Simulink模型的仿真结果相匹配。

团队将更新后的ARXML文件导入到AUTOSAR创作工具中，这样新的应用软件就可以在部署到ECU之前与其他AUTOSAR软件组件集成。

利用这一工作流程，KPIT及其客户成功完成了后处理系统软件，目前正在进行最终测试。KPIT的客户现在正在其他AUTOSAR项目中使用基于模型的设计。

• 开发时间最多减少40%。与标准开发实践相比，使用Simulink的基于模型的设计将开发时间减少了10%到40%，标准开发实践由于手动编码和无法在刷新ECU之前验证需求而变得更慢。
• 建立AUTOSAR往返工程工作流程。在AUTOSAR创作工具中的接口配置完成后，KPIT将它们导入Simulink，以在两个工具中的软件组件之间建立一对一的映射。符合autosar的代码和组件描述文件从他们的Simulink模型自动生成，ARXML文件被导入到KPIT的创作工具中。
• AUTOSAR实现简化了基于模型的设计。Mahesh说:“我们的客户现在可以专注于开发他们的应用软件和控制策略，因为他们不再需要担心AUTOSAR的工作流程或工具链。“MathWorks一直在增强Simulink对AUTOSAR的支持，我们相信对AUTOSAR标准的任何更改也将得到支持。”