■ 摘要

近年来，汽车行业所面临的最大挑战，是汽车上电子控制单元件数量的稳定增长以及驻留在这些控制器上的算法的复杂性。AUTOSAR –汽车开放系统架构–已联合100多家公司，其中包含汽车制造商、供应商和工具供应商，为电子控制单元开发标准架构。2006年底，AUTOSAR 2.1版本发行，现在OEM厂商和供应商已经开始开发与AUTOSAR兼容的功能和组件并将其集成到车辆中。本文将重点讨论工程师如何在已有模型的情况下，在不需要进行模型修改的情况下，创建符合AUTOSAR标准的件模型以及通过软件组件的描述来创建Simulink模型。在介绍之前，本文介绍了基于模型的设计Model-Based-Design（以下使用MBD）与AUTOSAR概念。

■ 介绍

自AUTOSAR 2.1标准发布以来，已经被许多公司视为是一个较为成熟的标准，其中对于指定的应用层软件组件的概念与信息的定义已经成熟。这促使工具供应商数量不断增加，并开始结合自己的技术优势，为AUTOSAR架构开发新的商业工具链。2006年，大众汽车采用了基于模型的方法，并将符合AUTOSAR要求的Comfort and Convenience ECU集成到了现有的E / E环境中。

为了解决应用程序和算法的复杂程度指数增加，汽车工程师开始使用基于模型的设计，这在业内已经被广泛接受。MBD可以在软件设计早期的开发阶段提供明确且可执行的规范，自动验证和确认以及代码生成等功能是使开发过程更加高效和有效的其他关键优势。

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

作为ECU网络的标准体系结构，在汽车工业中，AUTOSAR所发挥的作用越来越重要。 即使当前的阶段，大家主要将研究重点集中在进一步定义和完善标准，但实际上，许多OEM和供应商也在考虑导入AUTOSAR的ECU开发流程和其工具的市场前景。这就需要一系列完整的工具链，从在整车级别的ECU的架构设计，到使用MBD方法设计符合AUTOSAR标准的功能组件，以及开发运行环境与基础软件。

■ 基于模型设计

传统的嵌入式软件开发涉及书面设计和手动编码，以及一些代码验证工作，例如代码检查和单元/集成测试等。 其中许多流程缺乏工具自动化，需要手动完成。因此，传统的嵌入式软件开发即耗时又容易出错。工具链集成的缺失，为软件开发产生错误提供了“趁虚而入”的机会，这些错误通常要到设计流程的后期才会被发现，并且需要消耗很大的成本代价。

为了应对这些挑战，基于模型的设计（MBD）已成为一种在汽车行业内被广泛使用与认可的方法。 仿真测试不仅可以洞悉系统的动态和算法方面，而且模型还有以下优势，包括：

（1）作为可执行规范

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

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

（4）产品的自动生成

这些MBD的设计步骤，使工程流程始终专注于防查错以及错误的早期检测。在项目早期的V&V，可以减少晚期发生错误带来的风险。

正如图2所示，MBD使得模型位于开发流程中的核心，这样工程师可以创建可执行规范，自动生成嵌入式代码，在模型中执行V&V活动。

■ 需求与设计代码追溯

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

■ 可执行规范，V&V

将需求文档上的有关要求转换成为涵盖所有相关功能模型，可以避免需求文档所可能带来的二义性，可以得到明确的接口定义。工程师可以在开发的早期阶段验证Concept的正确性。

通过这种方法，工程师可以在项目早期就进行测试与验证工作。测试案例可以由工程师定义，也可以由工具自动生成MC/DC覆盖率的测试用例。

另外，可执行规范使得OEM与供应商的交流变得更为容易，因为规范是可以执行的，是图像化的。相比于传统方法，MBD方法在更早的阶段可以让团队完成一些重要任务。同时，MBD方法提高了产品质量，在项目早期尽可能得暴露错误，减小了修复项目后期错误所带来的巨大成本。图3为每个阶段修复错误所需要的平均成本。

■ 自动代码生成

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

■ AUTSOAR

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

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

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

（3）网络功能传输

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

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

（6）冗余功能

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

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

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

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

AUTSOSAR旨在简化汽车电子软件的联合开发，降低成本和加速产品面市时间，提高软件质量，并提供安全系统设计所需的机制。AUTOSAR重新定义了嵌入式汽车软件的编写方式，从而实现了对软件组件的重复使用、交换、升级和整合，过程十分简便。由此，各种应用情况变为现实，从第三方软件与动力传动系统ECU整合，到重复使用地盘的功能和传感器信号参数，再到复制和移动车身控制器上的软件组件，都可再AUTOSAR的平台上得以实现。

图4展示了AUTOSAR软件架构，一共被分为三个区域。应用层软件包含ECU网络的应用功能，被称为Autosar Software Component（后称为SC）。RTE层用于将应用层软件从基础软件中解耦。控制器与RTE定义为基础软件包括独立、依赖于硬件的非功能服务。

正如上面提到的，解耦应用软件与目标硬件是Autosar的主要目标之一，为了实现它，引入了Virtual Function Bus（虚拟功能总线，后称为VFB）。AUTOSAR软件组件实现应用层和封装单个ECU与ECU网络的功能。这些SC有着定义好的标准接口。每个AUTOSAR SC属于一个特定的ECU，而ECU可以有多个SC。

VFB（图5）实现了不同AUTOSAR SC之间的通信，无论它们属于车辆ECU网络中的哪一部分。 原则上，该概念允许在网络上的任何位置集成或传输AUTSOAR SC。在实现阶段，生成的运行时环境是虚拟功能总线的一个具体实例。

■ AUTOSAR CS开发

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以及与硬件相关组件的要求。这些设置可以在配置参数对话框中设置。

■ 自下而上

自下而上，工程师通过现有的诸如Vector Informatik的DaVinci工具套件之类的架构设计工具来设计车辆ECU网络的架构。然后，工程师导出架构软件所需的XML文件。该文件包含有关组件的所有必要信息，例如可运行对象，接口说明，数据类型等。借助MathWorks AUTOSAR解决方案，工程师可以导入此xml文件，并自动生成包含接口块（输入和输出）的Simulink模型以及在软件组件的描述文件中定义的这些对象的与AUTOSAR相关的设置。图6说明了工作流程。

将使用MATLAB命令行导入AUTOSAR软件组件描述文件，然后将生成模型。从该架构模型开始，设计工程师能够通过使用Simulink，Stateflow®和配套块集来开发控制器模型，如图7所示。

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

■ 结论

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