AUTOSAR软件组件开发中，通常有一些方面被误解，基于模型的设计和AUTOSAR的完美配合，这有助于解除工程师们的疑虑。最重要的事实是：无须向模型添加模块，便可使得它与AUTOSAR兼容。

AUTOSAR元信息争论

在ECU网络内将应用程序从目标硬件层分离，从而增强灵活性必须有更多的考虑，这一点是确定的，而对于开发人员而言这也的确不会带来非常大的系统开销。开发使驾驶更安全、油耗更低、甚至最新的驱动控制的算法是非常困难的。通过提供详尽的设计、仿真和分析功能，以及自动将模型转为代码的方法，使用Simulink和Stateflow的基于模型的设计已被广泛接受并被公认为可使生活更加轻松。但是，现在我们是否允许AUTOSAR使一切再次变得复杂？基于模型的设计的目标是使得功能开发更加简化，预防错误并尽早找到遗漏问题。我们的目标仍然是：节省时间和经费—— 对于AUTOSAR同样如此。两者都讨论了与硬件抽象层的分离以及对组件更轻松的重复利用。因此，将AUTOSAR概念加入到Simulink时，The MathWorks公司明白在不同目标之间进行平衡是基本准则。

问题是：开发工程师对于AUTOSAR应掌握到什么程度？除了解分层的软件架构（见图1）的基本概念外，是否真的需要详细掌握运行环境和底层基本软件？这是否有助于他做出高质量的工作呢？从功能开发角度来看，AUTOSAR软件构架中的哪些部分需要重点去掌握？

图1   AUTOSAR软件构架

结果表明，RTE层以下的所有部分对于功能方面而言影响很小。当然通讯还是要进行的，但是幸运的是目前这已经被封装。当然ECU的外围设备必须通过设备驱动程序来寻址使用，这部分也被封装起来。如果两者均未使用，开发流程将需要更改，以帮助开发人员避免这些复杂的工作。

模块集陷阱

这意味着什么？首先，无需向模型添加模块，便可使得它与AUTOSAR兼容。设计工程师照原样保持模型的结构，只需应用不同的配置。Simulink的配置概念在这里非常重要，因为它能够改变实施细节，而算法保持不变，不管模型输入端口是普通的Simulink端口、AUTOSAR接收器还是直接访问AUTOSAR基本软件的端口。这仅仅是配置问题。

因此，无需更改模型而使用某些AUTOSAR模块集。事实上，并没有此类模块集。客户无法从The MathWorks购买一些AUTOSAR包，并且他们也不需要它，因为所有这些都在现有工具产品的增强功能中了。但是，对于特殊的应用开发，通常有一些可提高建模效率的额外模块集，对AUTOSAR软件组件建模时不需要引入任何新的模块。

Simulink中的模块集是将功能进行封装，例如可用于创建高级信号处理算法（如过滤器、光谱分析或通信编解码器或视频及图像处理）的功能。其他模块包含求解器和构件，以根据控制器设备的物理原理对它们建模，而不考虑方程式。所有这些解法具有共同点，即它们可用比基本模块更简单的方法对行为和架构建模。例如，物理建模添加了可在建立的模块之间进行双向信号连接的功能，从而可双向传递信息，而不是采用普通Simulink中的直接信号线路。这简化了建模中的连接关系，可在一条线路中抽象表达“应力”和“惯性”。

相应地，开发AUTOSAR软件组件所需的基本建模构件已存在于Simulink和Stateflow中，其端口作为端口、多个可运行程序作为多速率模型，或是函数调用子系统，或是复杂的数据类型。

运行时的系统开销和代码容量

关于AUTOSAR的其中一个最著名谬论是由它引起的系统开销的运行效率问题和代码容量的问题。通常，工程师和项目经理担心生成的AUTOSAR兼容代码（包括RTE和基本软件）会导致代码容量增加2～3倍，同时执行时间和效率降低。AUTOSAR 2.1版是专门用于实施和集成与AUTOSAR兼容的应用程序的第一个版本。许多OEM和供应商已经有一个内部“基本软件”库——有时称为“标准核”。这些库与AUTOSAR标准不兼容，但是依据相同目标进行开发：从硬件目标中分离应用程序。目前的AUTOSAR项目通常以这些库的封装版本为基础，允许使用和开发AUTOSAR软件组件。

OEM和供应商已经发表了对AUTOSAR项目的初期的经验，并且结果非常好。趋势表明在这一领域中代码和内存消耗最多增加20%（而不是200%或者更高）！另一方面，他们做出了明确声明，确认AUTOSAR是降低复杂性的好方法。这些经验是最好理由，使得不用害怕AUTOSAR本身，也不用惧怕去接受先前关于代码和内存容量增加的事实。

AUTOSAR符合基于模型的设计

既然我们已经谈论过很多次，开发人员和其管理团队无需关心的部分，我们应了解一下当谈论到AUTOSAR时，哪些手段能充分发挥基于模型的设计的优点。意识到并非所有使用MATLAB和Simulink的人已经进行基于模型的设计非常重要，因此，让我们强调一下采用基于模型的设计的一些最佳方法，这些已经被多次讨论过，这些方法特别适用于工程师及其工具使用。

将模型用于至少两个目的

通常企业进行了大量建模工作，但是仅仅将该模型用于一个目的。我们发现客户仅仅将模型用于代码生成，从未在Simulink中按过“仿真”按钮。为了使在软件、人员培训和机构重组等方面的投资得到更好的回报，模型应该用于至少两个不同的目的。除了生产代码生成之外，首先通过仿真确认需求，并自动生成文档。或使用Simulink控制设计工具箱以线性控制理论为基础，使用模型对控制器进行参数调整，然后进行快速原型，可以使用xPC或利用dSPACE的硬件解决方案进行。

将模型看作获得正确结果的惟一途径

这也是下一个最佳做法的结果。如果您在其中一个下游工作产品中发现系统缺陷，不要在发现的地方修改它，因为这样会把可执行规范与实际产品分离，从而妨碍未来的重复利用。在模型中解决缺陷。整个工具链应当能够通过自动代码生成步骤，快速地回到抽象层。如果要更改一些内容，那么在模型中更改，以获得分析、仿真以及即时实施等一系列好处。

着重于设计，而非代码

建模考虑系统功能，而不是过早地考虑实施。但是，工作人员建模时脑子里总是出现需要的C代码。如果是这样，将不再是建模，您是在用图形化方式编程，因此浪费了模型的功用。如果在模型中确实需要使用一些代码，不需要重新去搭建。通过Legacy Code工具将代码包括进来。除此之外，思考功能，而非代码。

与工具供应商合作

明智的企业从其自身错误中学习。聪明的企业从他人的错误中学习。但是，谁能够收集这些错误，并将它们转换为学习机会？由于工具供应商很大程度地参与到基于模型的设计的推行，他们积累了经验并能利用此经验显著减少学习的难度。这样做使得企业能够比预期更快地体会到基于模型的设计的优势。从而，促使很快到达投资回报（ROI）盈亏平衡点。因此，与供应商紧密合作并让他们积极参与你的转换方案，将使你能够利用他们的经验，避免常见错误，并实现成功转换。

AUTOSAR如何适合基于模型的设计

在本文的前面部分中已经介绍了OEM和供应商的开发过程中基于模型的设计的角色以及重要性。ECU在功能、互相连接以及变量等方面的复杂性迫使汽车工程师改变方法适应竞争，从而符合AUTOSAR的座右铭——“在标准上合作，在实施时竞争”。

不仅仿真可深入了解系统的动力和算法方面，而且模型通常也可用于几个有帮助的任务，包括：

（1） 充当可执行的规范；

（2） 在客户和供应商之间确定组件需求和接口定义；

（3） 提供汽车系统的虚拟原型和驾驶员模型、道路状况、以及用于算法开发的其他环境状况；

（4） 对产品级系统实现软件算法的自动代码生成。

这些基于模型的设计活动保持工程流程着重于错误预防以及早期的错误检测。项目中的早期验证和确认可降低后期发现错误的相关风险。

AUTOSAR阐明汽车领域的工程师需要采取下一步骤；由驾驶员可识别的功能拓扑结构（如ACC自适应巡航控制系统）不会局限于ECU。对于这样的应用程序可能分布于汽车上许多控制单元上——这甚至不是一个固定的ECU数量，但是会基于整车平台而变化。AUTOSAR提供一种引入另一级别抽象层的方法；系统层面的考虑变得重要，而节点相关方法（就单个ECU而言）变得较不重要。

基于模型的设计与AUTOSAR方法完全一致。从系统架构角度，自上而下进行考虑。为了解决AUTOSAR特定标记法，使用一个设计工具，例如Vector Informatik的DaVinci，来适当地描述ECU网络的拓扑结构。AUTOSAR定义的描述格式可实现与其他工具的轻松集成，以开发功能和控制算法以及实施这些功能的软件代码。

AUTOSAR的成功基于V流程中的工具互用性。设计工具需要与功能和代码生成环境，以及基本软件配置和RTE生成环境一起工作。

具有Real-Time Workshop Embedded Coder的Simulink和Stateflow如何支持AUTOSAR的重要功能要求

为了说明上面提到的一些方面，让我们看看它们如何一起工作。基于MATLAB、Simulink、Stateflow以及Real-Time Workshop Embedded Coder用于生成兼容于AUTOSAR的代码的The MathWorks方法遵循一个清晰且直观的过程，它支持两种不同的工作流程，即自上而下及自下而上。

自上而下：从架构模型到AUTOSAR软件组件

在自上而下的工作流程中，系统工程师使用架构设计工具（在AUTOSAR术语中称为“Authoring Tool”，如Vector Informatik的DaVinci工具套件），来设计汽车的ECU网络的架构。当然，这并不限制使用其他设计工具的可能性。然后，工程师可导出相应组件的XML说明：AUTOSAR软件组件说明。此文件包含关于组件的所有必需信息，例如可运行程序、接口说明、数据类型等。利用MathWorks AUTOSAR解决方案，工程师可导入此XML文件并自动生成基础Simulink模型，该模型如同定义的那样，包含接口模块（输入和输出）以及与AUTOSAR相关的这些对象的设置。图2说明了该工作流程。从此框架模型开始，设计工程师利用Simulink、Stateflow以及图3中所示的辅助模块集来开发控制器模型。

图2  DaVinci架构导出并导入到MATLAB与Simulink中

图3   控制器设计（其他示例）

模型的模块结构可保持不变，并且如之前所述，指定稳定的接口根本不需要进行大量更改。尤其可照常应用验证和确认功能，并在关于基于模型的设计的相关章节中有所描述。通常，设计工程师可改进与AUTOSAR相关的模型，例如使得子系统可调用，从而使得它们成为独立的“可运行系统”或接口对象。在这种特殊情况下，必须进行相应的设置，以确保生成的代码与标准兼容，并适合其他软件环境，该环境包含运行环境和基本软件层的硬件相关组件，可通过适当的配置参数对话框进行这些设置。对于代码生成，需要选择Real-Time Workshop Embedded Coder中的相应AUTOSAR系统目标。该工作流程的第二部分与下述工作流程的步骤相同，并进行了图解说明。

自下而上：重新利用已有模型生成与AUTOSAR兼容的代码

由于基于模型的设计是汽车行业广泛采用的方法，因此各公司通常具有庞大的成熟且经过大量测试的模型库。可重新利用这些模型以针对不同的平台（如AUTOSAR），且无需对模型的模块进行任何更改，这一点很重要。

为了使得现有模型与AUTOSAR兼容，执行下列操作：

1. 在Real-Time Workshop Embedded Coder中将目标转换为“AUTOSAR”。

2. 转至AUTOSAR选项栏，打开接口配置对话框，并让它获得默认配置。

3. 进行任意更改，将端口设置为不同于默情况的“发送器”或“接收器”，并按“确认”。

4. 开始代码生成。

自下而上的工作流程要求与自上而下的工作流程中描述的相同AUTOSAR配置。尤其应配置接口对象，以确保可正确集成生成的软件组件。除了代码文件外，还将自动生成更新后的XML格式的AUTOSAR软件组件说明文件（见图4）。

图4  Simulink AUTOSAR 代码生成，XML 导出并导入到DaVinci

到此为止，下一步是什么？

AUTOSAR显然不像有时看起来那样令人害怕。尽管系统架构师需要有关AUTOSAR的深厚知识，但是功能开发工程师不必掌握同样程度的信息。

确实应考虑其他性能和方案。AUTOSAR的下一版本将展示该标准可解决行业中复杂问题的能力。最后，工程师必须能够应对其挑战，而工具供应商需要尽可能地支持他们。