摘 要

本文展示了工程师如何在已有模型的情况下，在不需要进行模型修改的情况下，创建符合Autosar标准的件模型以及通过软件组件的描述来创建Simulink模型。在介绍之前，本文介绍了基于模型的设计Model-Based-Design（以下使用MBD）与Autosar概念，并建立了一些术语来解释为什么我们要将Autosar与Simulink相结合。

介 绍

随着整车内ECU数量以及单个ECU内软件的复杂度的逐步增高，汽车软件行业需要一个开放，标准的软件架构来将未来整车、单个ECU内软件的复杂程度限定在一个可以控制的范围内。Autosar （Automotive Open System Architecture，汽车开放系统架构）就是这样的一个组织，目前组织已经联合了超过100个整车厂、零配件供应商、工具链供应商、半导体电子公司来为未来的ECU共同建立一个标准架构。目前已经许多OEMS以及供应商已经开始在部分车内开发、整合、集合符合Autosar标准的功能组件。

Autosar2.1标准已经被许多公司视为是一个较为成熟的标准，其中对于指定的应用层软件组件的概念与信息的定义已经成熟。许多工具链供应商纷纷开始结合自己的技术为Autosar架构开发新的商业工具链。在2006年大众公司已经成功使用MBD方法来设计符合Autosar标准的ECU并整合在已有的E/E电子电气环境中。

为了应队软件、算法的复杂程度指数增加，汽车工程师开始使用MBD方法，这个已经在业内被广泛接受。MBD可以在软件早期开发阶段提供明确、可执行的规范，自动V&V（Verification、Validation）以及自动代码生成这些额外的优点使得开发效率显著提高。

作为ECU网络的标准架构，Autosar在汽车行业变得越来越重要，尽管现阶段大家只是将关注点放在标准的定义与完善，但许多OEMS以及供应商已经开始将Autosar纳入未来软件开发流程中。这就需要一系列完整的工具链，从上到整车级别的ECU的架构设计，下到使用MBD方法设计符合Autosar标准的功能组件，以及开发运行环境与基础软件。

基于模型设计

传统的嵌入式软件开发包括书面设计、手工编码，以及如代码检查，单元集成测试等验证工作。其中许多流程缺少工具的自动化需要手工完成，因此既耗时又容易产生错误。工具链的集成的缺失是另一个容易产出错误的方面，此类错误在软件开发过程中往往探测较晚而且需要花费很大代价。

为了应队这些挑战，MBD已经成为汽车行业广泛使用与认可的方法，仿真测试不仅可以洞悉系统的动态、算法方面，而且模型还有如下优点：

（1）作为可执行规范

（2）交流软件需求规范，为顾客与供应商之间提供接口定义

（3）为开发算法提供汽车系统以及驾驶员、环境、路况条件等模型提供虚拟原型

（4）产品的自动生成

这些MBD的活动使工程流程更加专注于防查错以及错误的早期检测。项目早期的V&V可以降低晚期发生错误带来的风险。正如图1所示，MBD使得模型位于开发流程中的核心，这样工程师可以创建可执行规范，自动生成嵌入式代码，在模型中执行V&V活动。

需求与代码追溯

使用MBD开发嵌入式软件始于客户对软件需求要求的大幅提高，工程师必须确保模型以及最终生成的代码满足系统需求。因此，需要关联每一个需求至相应的模型部分，这种追溯能力是十分重要的。工程师搭建一个详细的软件设计模型，并通过持续不断的V&V流程来确保所搭建的模型是满足需求的！由状态机以及基础模块组成的模型可以双向直接链接到需求文档或者需求管理工具中。测试用例（由工程师定义或者自动生成）也可以被直接链接到对测试覆盖率的需求中。在开发的后期阶段，生成模型代码后，Mathworks公司的Embedded Coder可以产生代码声明与模型之间的链接，正如工业标准IEC61508、Aspice所规定的。

可执行规范，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标准的代码是透明和直观的过程，它支持两种不同的工作流程：自上而下和自下而上。

自上而下

自上而下，从架构模型到Autosar SC。在自上而下的开发流程中，系统工程师使用架构生成工具（如davinci tool suite）来设计整车ECU网络。当然，工程师也可以使用其他的架构设计工具。架构软件会输出一个XML来描述对应的组件，该文件里包含了组件的一些必要信息比如：runnables，接口，数据类型等等。Matlab软件可以利用架构软件生成的XML文件自动创建Simulink架构模型，里面包含了接口模块以及相应的Autosar相关设置。之后系统工程师就可以在该框架模型的基础上，完善内部的控制模块。

同时该模型可以像普通模型一样照常进行V&V测试，设计工程师也可以对Autosar模型添加有关的接口或runnables。工程师必须在相应的地方进行设置来保证所生成的代码满足标准，来满足基础软件层中的RTE以及与硬件相关组件的要求。这些设置可以在配置参数对话框中设置。

自下而上

自下而上，通过现有的Simulink控制模型来自动生成架构软件所需的XML文件。因为汽车产业已经非常成熟，许多公司已经有许都测试好的库与模型。这些模型能够重用到不同的平台，比如Autosar架构中，而不需要对模型进行任何人力修改，这点非常重要。自下而上的工作流程，与自上而下的工作流程都需要相同的Autosar配置， 尤其是接口对象需要被正确设置，来保证SC可以被正确集成。

结 论

随着汽车ECU软件程度的复杂性增加，OEM与供应商联合建立了行业中最大的标准——Autosar标准，这被视为是应付软件复杂性挑战中的最重要的一步。Autosar专注于各SC之间的通信，并解耦了应用层软件与基础软件。使用MBD方法设计功能软件，由于这两种方法的双向性，MBD与Autosar不仅是相互兼容的，也是互补的。这种组合不仅方便了架构设计、系统设计工程师，也方便了OEM与供应商。