019 使用基于模型设计开发AUTOSAR软件组件（中）

本文翻译的是 Mathworsk 公司撰写的 Development of AUTOSAR Software Components with Model-Based Design，希望与大家一起共同学习进步，如有错误请大家指出。“ ”

可执行规范，V&V

将需求文档上的有关要求转换成为涵盖所有相关功能模型，可以避免需求文档所可能带来的二义性，可以得到明确的接口定义。工程师可以在开发的早期阶段验证Concept的正确性。通过这种方法，工程师可以在项目早期就进行测试与验证工作。测试案例可以由工程师定义，也可以由工具自动生成MC/DC覆盖率的测试用例。另外，可执行规范使得OEM与供应商的交流变得更为容易，因为规范是可以执行的，是图像化的。相比于传统方法，MBD方法在更早的阶段可以让团队完成一些重要任务。同时，MBD方法提高了产品质量，在项目早期尽可能得暴露错误，减小了修复项目后期错误所带来的巨大成本。图三为每个阶段修复错误所需要的平均成本。

“ ”

自动代码生成

例如通过使用Embedded coder可以自动将模型转化成嵌入式代码，这种平滑集成的一大优点就是可以重用已经生成与测试过的模型。在连续的V&V过程中，不断发现与修复bug，而测试软件可以重新自动生成。

“ ”

Autosar

为了应对汽车行业里电子电气应用开发中日益增加的软件复杂度，世界一流的OEM，供应商公司联合在一起决定为ECU定义一个标准架构，来应对未来软件开发的挑战。在2002年成立了Autosar组织以实现以下目标：

（1）基本系统功能的实现和标准化，并作为OEM的标准解决方案

（2）不同的车辆和平台之间的扩展性

（3）网络功能传输

（4）不同供应商的功能模块集成

（5）对可用性和安全性的考虑

（6）冗余功能

（7）整个产品生命周期的可维护性

（8）增加商用现成硬件的使用

（9）整个汽车生命周期的软件更新和升级

（10）增加商用现成硬件的使用

图四展示了Autosar软件架构，一共被分为三个区域。应用层软件包含ECU网络的应用功能，被称为Autosar Software Component（后称为SC）。RTE层用于将应用层软件从基础软件中解耦。控制器与RTE定义为基础软件包括独立、依赖于硬件的非功能服务。正如上面提到的，解耦应用软件与目标硬件是Autosar的主要目标之一，为了实现它，引入了Virtual Function Bus（虚拟功能总线，后称为VFB）。Autosar软件组件实现应用层和封装单个ECU与ECU网络的功能。这些SC有着定义好的标准接口。每个Autosar SC属于一个特定的ECU，而ECU可以有多个SC。

VFB实现了不同Autosar SC之间的通信功能，不论他们属于整车ECU网络中的哪一部分。在实现阶段，生成的运行时环境是虚拟功能总线的一个具体实例。“ ”

Autosar SC开发

MBD的概念在Autosar开发中可以发挥更大的优势，而且应该被更多的使用。一旦公司决定遵循Autosar流程开发ECU，设计或软件工程师不应该被迫改变他或她的工作流程，以生成符合AUTOSAR标准的软件。MATLAB，Simulink和Real-Time Workshop Embedded Coder生成AUTOSAR标准的代码是透明和直观的过程，它支持两种不同的工作流程：自上而下和自底向上。