Michael Seibt 是 Mentor Graphics 的产品经理

Guido Sandmann 是 MathWorks 在欧洲、中东及非洲 (EMEA) 地区的汽车营销经理

汽车行业的电子开发始终是一个迭代过程，甚至在实现 AUTOSAR 之前很长时间已经如此。

在项目过程中，需求被不断修改或完善;设计不断改变，架构不断调整。在不同设计作品的整个规格格式标准化过程中，AUTOSAR 明确定义了执行这些处理步骤的方式。同时，借助于高级工具支持，正逐渐将 AUTOSAR 标准成功应用于产品开发的许多领域。这些项目所面临的挑战是，确保在各个工具之间进行数据交换时保持一致，不会丢失设计信息。在开发各个软件组件及功能性软件时，应特别注意基于架构和基于模型设计工具之间的交互。支持自上而下和自下而上设计方法。

本文使用 MathWorks 的 MATLAB、Simulink 和 Embedded Coder 及 Mentor Graphics 的 AUTOSAR 编写工具 VSA 作为示例，旨在根据 AUTOSAR 定义的机制，分五个步骤演示基于架构和基于模型设计环境的交互和互操作性。

自上而下和自下而上工作流程

在实际运行中，自上而下和自下而上工作流程都能找到。通常，这两种方法都不会单独使用，而是因为上面提到的迭代过程，会被混合使用。

如果从头开发某个新功能，则通常使用自上而下方法。这意味着，包括软件组件和接口规格在内的软件架构最初使用编写工具进行描述。根据具体需求和数据可用性，也可能会在此时开发内部行为(表示可运行的架构)。内在的及用户定义的一致性检查和设计规则都有助于检查所导入数据集的正确性和完整性。然后，将最后导出的规格格式导入到诸如 Simulink 这样的设计工具中。在这个导入软件组件规格的过程中，将自动生成包含所有相关信息(如接口或可运行架构)的模型框架。使用生成的模型框架，软件工程师可以照常在 Simulink 中基于功能需求对功能行为进行建模。完成建模后，将借助于 Embedded Coder 生成符合 AUTOSAR 的 C 代码。同时，导出新的软件组件规格，依次可由 VSA 导入进行进一步集成。

另一方面，如果某个功能的模型已经存在且已经用在生产中，可以重复使用这些模型。这些模型必须使用 AUTOSAR 特定信息进行扩展。完成后，将生成符合 AUTOSAR 的 C 代码及相应的 AUTOSAR 软件组件规格，然后编写工具可依次导入进行进一步处理。因此，自下而上方法主要解决对现有 IP(知识产权)的重复使用。

如开头所述，某个过程的不同步骤会重复执行多次，以便进行完善或修改。因此，使用的工具必须支持迭代开发过程。在此特定场景中，它们必须支持双向工程，这意味着基于架构和基于模型的设计工具必须能够进一步互相处理更新后的数据。

在下文中，将详细介绍在双向工程中执行的所有步骤。

图 1. 使用 Simulink 和 VSA 的 AUTOSAR 双向工程

步骤 1：软件架构和组件生成

在 AUTOSAR 编写工具(如 VSA)中，生成软件组件并将其连接到软件架构中。根据所需精细度，也可以按照可运行架构、访问点和 RTE 事件的形式对各个软件组件的内部行为进行建模。

下图基于座椅加热系统示例显示了软件架构(软件构成)，包括 SWR 行为引用。可以使用不同领域特定的编辑器来创建各种复杂程度的设计。根据需求，用户可以选择树状编辑器、表格式编辑器或图形编辑器。

图 2 VSA – AUTOSAR 编写工具

通过众多预先实现的一致性检查，可以在架构建模过程中连续检查设计的完整性和合理性。可以通过自定义的一致性检查或设计规则 (DRC) 来补充这些检查。现有的软件组件、接口规格和其他设计作品也可以通过库的形式导入并将其重新应用于新设计中。每个 AUTORSAR 对象都将通过自动生成 UUID(通用唯一标识符)和分配短名称来收到唯一标记，以便在设计迭代期间识别。

步骤 2：从编写工具导出数据

通过在 VSA 中使用的元模型技术，可以获得完整的 AUTOSAR 模型规格以支持完整导出。不同的 AUTOSAR 版本可适用于各种模型到模型转换。在 VSA 的软件架构中进行定义后，便可以按照 AUTOSAR 定义的标准规格导出特定软件组件。还将导出一个 MATLAB 脚本，它支持后面导入到 MATLAB 和 Simulink。

步骤 3：将软件组件规格导入 Simulink

Simulink 包含允许导入步骤 2 中所生成作品的接口功能。各个接口和端口规格、内部可运行变量或有关可运行架构(内部行为)的信息都将被导入。然后，将生成包括软件组件结构在内的模型框架作为函数调用子系统。将从规格中生成相关变量(包括其数据类型)，并在工作区自动创建这些变量。下图显示了导入的软件组件，其中包含座椅加热系统的可运行架构和内部可运行变量：

图 3 将 SWC 规格导入 Simulink

步骤 4：功能行为建模和代码生成

在接下来的步骤中，将通过基于模型的设计来实现功能行为。模型将通过 Simulink 和 Stateflow 逐渐创建和完善，然后在项目过程中，将模型用于各种用途。在最初的阶段中，通过仿真来验证功能行为。稍后，可以借助于“快速建立硬件原型”的帮助直接在车辆中测试优化后的版本，直到模型最终足够成熟，可以使用 Embedded Coder，以生成符合 AUTOSAR 代码。在此过程中，可以使用传统 Simulink 元素，这些元素可以直观地映射到 AUTOSAR 作品。至关重要的一点是，基于模型的设计及相关设计和验证工具可以照常应用。此步骤最终生成符合 AUTOSAR 的 C 代码和 arxml 格式的 AUTOSAR 软件组件规格，该规格将被导入以在下一个步骤中与 VSA 集成。

步骤 5：AUTOSAR 比较和合并

为了完成往返行程，需要提供一个选项，将修改后的设计数据反馈回到 AUTOSAR 编写工具，并将其与原始设计数据同步。为此，VSA 提供了 AUTOSAR 比较和合并功能，借助该功能，可以在 AUTOSAR 对象面比较并具体合并设计对象。可以根据 UUID(唯一通用标识符)或短名称执行此操作。

图 4 VSA 比较和合并工具

其他“规则”

虽然已经使用 AUTOSAR 和协调良好的工具在各个公司实现可靠的双向工程。但是，只有在遵守其他“规则”的情况下才能实现。

必须在考虑现有和新定义流程的情况下协调用户角色和权利。必须应用内部“风格指南”

(例如建模指南和命名约定)以具体限制 AUTOSAR 框架中的自由度。最后，必须与一级供应商协调这些风格指南，以便不仅在内部，而且在供应链的各个公司之间实现双向工程。

再次，软件工具在 OEM 及其供应商之间交换 AUTOSAR 作品也起着重要的作用。