目录

往期推荐

AUTOSAR方法论的典型开发步骤顺序

1. 需求分析（Requirement Analysis）

2. 系统架构设计（System Architecture Design）

3. 软件组件设计与实现（Software Component Design and Implementation）

4. ECU配置与基础软件配置（ECU Configuration and Basic Software Configuration）

5. 代码生成与自动化（Code Generation and Automation）

6. 验证与测试（Verification and Testing）

7. 系统集成与调试（System Integration and Debugging）

8. 功能验证与验收测试（Functional Validation and Acceptance Testing）

9. 部署与生产（Deployment and Production）

10. 持续集成与维护（Continuous Integration and Maintenance）

理论视角下的 AUTOSAR 方法论

系统配置描述文件有哪些信息？

ECU配置描述文件包含哪些信息？

工具视角下的 AUTOSAR 方法论

---

往期推荐

1. ETAS工具链自动化实战指南＜一＞
2. ETAS工具链自动化实战指南＜二＞
3. ETAS工具链自动化实战指南＜三＞
4. AUTOSAR工程师必读：Artop的核心功能
5. Vector工具链自动化实战指南＜一＞
6. isolar高手秘籍| ECU Configuration三分钟速成！
7. 掌握核心步骤：RTA-BSW以太网配置全解析
8. 一文详解TC399 CAN MCAL 配置
9. LSL常见应用场景及示例＜一＞
10. LSL常见应用场景及示例＜二＞
11. LSL常见应用场景及示例＜三＞
12. 为什么Autosar钟情arxml而非json？大揭秘！

AUTOSAR 方法论定义了开发 AUTOSAR 系统的步骤/活动的顺序。尽管如此，软件组件的实现在很大程度上与 ECU 配置是独立的。这是 AUTOSAR 方法论的一个关键特点。

从开发流程上看，AUTOSAR系统的开发通常从需求分析开始，然后是架构设计、软件组件的开发与实现，再到ECU配置、测试和集成，最后是系统的部署和维护。整个流程强调模块化、解耦、可重用性和可扩展性。在此过程中，各种工具发挥了自动化、配置管理、验证和测试的关键作用。

AUTOSAR方法论的典型开发步骤顺序

1. 需求分析（Requirement Analysis）

• • 目标：定义系统需求、功能需求以及性能需求。明确系统目标及各个模块的功能。

  • 活动：

    • 确定系统功能需求、非功能需求和约束条件。

    • 确定软件组件（SWC）的功能。

    • 根据需求编写需求文档，确保需求可追溯和可验证。

  • 工具：需求管理工具（如 IBM DOORS、Polarion）。

2. 系统架构设计（System Architecture Design）

• • 目标：设计系统的高层架构，包括硬件和软件组件的结构、ECU间的通信、资源分配等。

  • 活动：

    • 定义系统架构（如SWC、ECU、通信等）。

    • 设计基础软件层（BSW）、运行时环境（RTE）和操作系统（OS）的配置。

    • 设计ECU通信协议（如 CAN、Ethernet 等）。

    • 评估系统架构的可行性、性能和成本。

  • 工具：架构设计工具（如 Vector PREEvision、Enterprise Architect、EB tresos Studio、Polarion）。

3. 软件组件设计与实现（Software Component Design and Implementation）

• • 目标：开发符合功能需求的软件组件，并确保这些组件能够与其他系统模块无缝集成。

  • 活动：

    • 设计和实现软件组件（SWC）接口。

    • 实现业务逻辑和通信协议。

    • 开发组件的代码。

    • 集成应用代码与底层软件框架。

  • 工具：集成开发环境（IDE）（如 Eclipse、Visual Studio），AUTOSAR工具（如 EB tresos Studio、Vector DaVinci Developer）。

4. ECU配置与基础软件配置（ECU Configuration and Basic Software Configuration）

• • 目标：根据系统需求和软件组件，配置ECU硬件资源、基础软件层（BSW）和中间件。

  • 活动：

    • 配置ECU硬件资源（如存储器、处理器等）。

    • 配置基础软件模块（如 MCAL、OS、COM、RTE等）。

    • 配置和生成ECU代码及通信栈。

    • 配置和调试运行时环境（RTE）。

  • 工具：配置工具（如 Vector DaVinci Configurator、EB tresos Studio、Arccore Arccore Studio）。

5. 代码生成与自动化（Code Generation and Automation）

• 目标：自动生成基础软件、RTE、SWC集成代码，减少手动编码和集成的错误。活动：

  • 自动化测试和验证生成的代码是否符合需求。

  • 生成运行时环境（RTE）代码并进行验证。

  • 使用自动化工具生成应用软件和基础软件的代码。

  • 工具：代码生成工具（如 Vector DaVinci Developer、EB tresos Studio、Arccore Arccore Studio）。

6. 验证与测试（Verification and Testing）

• • 目标：验证系统的功能和性能，确保系统符合设计需求。

  • 活动：

    • 软件单元测试：对单个软件组件进行功能测试。

    • 集成测试：验证多个软件组件的协同工作。

    • 硬件在环（HIL）测试：验证ECU在真实硬件平台上的功能。

    • 性能测试：验证系统性能是否符合要求（如延迟、带宽、可靠性等）。

  • 工具：测试工具（如 Vector CANoe、dSPACE、EB Assist、NI VeriStand）。

7. 系统集成与调试（System Integration and Debugging）

• • 目标：将所有的软件组件、基础软件和硬件集成在一起，进行调试和性能优化。

  • 活动：

    • 将已实现的软件组件与ECU、基础软件和硬件资源进行集成。

    • 进行集成调试和问题排查。

    • 解决集成过程中出现的兼容性和性能问题。

  • 工具：集成调试工具（如 Vector CANoe、dSPACE HIL系统）。

8. 功能验证与验收测试（Functional Validation and Acceptance Testing）

• • 目标：确保系统按预期功能运行，并通过客户的验收测试。

  • 活动：

    • 进行系统级功能验证，确保所有需求都已实现。

    • 进行验收测试，确保系统符合客户的期望。

    • 完成项目文档和合规性检查。

  • 工具：验证工具（如 CANoe、dSPACE、EB Assist）。

9. 部署与生产（Deployment and Production）

• • 目标：将系统部署到量产环境中，确保产品按计划投入生产。

  • 活动：

    • 将经过验证的代码部署到生产环境。

    • 进行生产前的最终验证。

    • 完成产品的最终配置和部署，准备生产。

10. 持续集成与维护（Continuous Integration and Maintenance）

• • 目标：进行版本管理、持续集成，并根据需求进行后续维护。

  • 活动：

    • 使用版本控制系统（如 Git、SVN）进行代码管理。

    • 进行系统的持续集成，确保代码始终是可构建的。

    • 定期更新和维护系统，修复bug，进行功能扩展。

  • 工具：版本控制工具（如 Git、SVN）、持续集成工具（如 Jenkins、GitLab CI）。

理论视角下的 AUTOSAR 方法论

理论视角关注的是整个开发过程的原则、步骤和活动的组织方式。它主要侧重于概念、标准和系统架构设计，着眼于如何在高层次上理解和规范化开发流程。如下图所示：理论视角下的 AUTOSAR 方法论：

上图显示了从系统配置到 ECU 可执行文件的 ECU 代码生成流程。虽然上图显示可执行文件为.exe，但不要将其与Windows PC 的 .exe 文件混淆。这里的 .exe 文件是指一般的可执行文件，可以是 .elf、.bin 等。AUTOSAR 使用特定的文件格式在流程中的不同步骤之间交换信息。该文件格式类似于XML  ，但在 AUTOSAR 上下文中，它称为 .arxml（ AUTOSAR 可扩展标记语言 ） 文件。配置软件将解释此文件并根据此文件中包含的信息生成代码。

汽车中所有 ECU 和整个网络的组合称为系统，首先配置系统，然后配置该系统的每个 ECU。

配置中的一些步骤：

1. 系统配置：在此步骤中，汽车（系统）所需的整体 ECU 及其硬件与 SWC一起配置，并将组合 SWC映射到各自的 ECU。

2. 生成系统配置描述：第一步配置完成后，第一步的输出称为系统配置描述文件，为.arxml文件格式。

3. ECU 提取生成：通过使用步骤 2 中的系统配置描述 arxml 文件作为输入，生成一个新文件，称为 ECU 提取 arxml 文件。它仅包含单个 ECU 的信息，而系统配置描述文件则包含汽车中所有 ECU 的信息。

4. ECU 配置：在此步骤中，ECU extract用作输入，并根据应用要求配置相应的 ECU。配置包括BSW 配置、OS 配置等。

5. 生成 ECU 配置描述：此步骤将用于生成步骤 4 的输出，即生成 ECU 配置描述 arxml 文件，该文件将进一步用于生成可执行文件。

6. 生成可以在硬件（ECU）中刷写的可执行文件。

需要注意文件命名法，带有后缀“Description”的文件是相应步骤 或过程的输出。例如，系统配置描述 arxml 是系统配置步骤的输出。

系统配置描述文件有哪些信息？

系统配置描述文件（系统配置后生成）包含所有系统配置信息，例如：

• 系统中的 ECU

• 连接这些 ECU 的通信系统及其配置

• 通信矩阵将指示这些通信系统将发送和接收的数据。由于 AUTOSAR 旨在标准化整个开发，因此需要在配置时配置将要发送或接收的所有数据、大小等。

• SWC 及其端口、接口和连接的定义。

• 将 SWC（软件组件）映射到 ECU。

此文件用作 ECU 配置的输入。ECU 提取文件与系统配置描述相同，但仅包含与相关 ECU 相关的信息。

ECU配置描述文件包含哪些信息？

ECU Extract 仅定义了系统中所有 ECU 需要同意的配置元素，但这不足以生成可在硬件上运行的代码。因为此文件没有任何可用于配置 AUTOSAR 架构较低层的低级配置信息。因此，ECU 配置描述具有配置软件利用并生成 .c 和 .h 文件的信息，这些文件进一步编译并在硬件上运行。

工具视角下的 AUTOSAR 方法论

从工具视角来看，AUTOSAR方法论强调了自动化、配置、代码生成和测试工具在整个开发过程中的作用。工具的使用可以帮助简化、加速和验证各个开发阶段，减少人为错误，提高系统的一致性和质量。

我们使用 AUTOSAR 编写工具创建一个高层设计，其中包括软件组件描述、ECU 资源描述和系统描述文件（包括通信矩阵、拓扑等）。一旦有了这三个组件，使用 AUTOSAR 方法论的软件开发过程可以大致分为两个部分，即应用软件开发和 ECU 配置过程。

在应用软件组件（SWC）开发过程中，SWC 描述文件描述了需要开发的软件组件，将其作为输入。

如下图所示：从工具的角度解释的 AUTOSAR 方法论

例如，我们可能有三个软件组件：控制器软件组件、拨号 LED 软件组件和加热元件软件组件。我们使用 AUTOSAR 编写工具构建一个系统级文件（arxml 文件）。

下一步是将系统级文件转换为 <*.c> 和 <*.h> 代码。许多编写工具具有此功能。这些 <*.c> 和 <*.h> 代码是通用代码，仅包含连接 RTE 和 SWC 的接口定义信息，例如 API 函数的声明、SWC 数据结构和可运行实体原型。

例如，这些头文件（框架）允许开发人员在不需要了解底层基础软件和硬件的具体知识的情况下，开始实现 SWC。这些头文件然后被导入到基于模型的代码开发环境中，以生成实际的可执行代码，或者使用手动编码机制构建应用软件组件，即 <*.c> 和 <*.h>。

在 ECU 配置过程中，我们使用软件组件描述、ECU 资源描述和系统描述文件生成系统描述。系统描述包含所有的映射信息，即它包含所有 ECU 的详细信息、映射到 ECU 的软件组件的详细信息以及通信矩阵、拓扑等信息。BSW 配置工具用于配置 ECU。BSW 配置工具需要完成 RTE 生成、OS 生成、BSW 生成和 MCAL 配置。输出将是 <*.c> 和 <*.h>。这些 <*.c> 和 <*.h> 文件与在应用软件组件开发过程中生成的 <*.c> 和 <*.h> 文件集成在一起，并生成最终的 make 文件。