[AUTOSAR基础入门] - AUTOSAR的基本概念

点击订阅专栏不迷路

返回总目录

本篇内容只对AUTOSAR的一些概念进行简单介绍，具体内容见后续章节。

一、AUTOSAR联盟

AUTOSAR联盟是由汽车整车厂、供应商以及软件、半导体和电子行业的公司组成的全球发展合作组织。

在“标准中合作，实现上竞争”的口号下，各成员以工作组为单位，享有并承担着不同的权利和义务。核心合作伙伴决定哪些团体可加入AUTOSAR联盟，高级成员则负责制定标准。

AUTOSAR的目标如下：

• 标准化应用程序软件功能之间的接口和基本功能的接口
• 定义ECU软件参考架构
• 将分布式开发过程的数据交换格式标准化

实现这些目标后，参与的公司希望获得以下好处：

• 通过功能的灵活集成、重新分配和交换来优化ECU网络
• 掌控日益提升的产品和流程的复杂程度
• 维护整个产品生命周期

那么到底什么是AutoSAR呢

大白话来讲：AUTOSAR 就是AUTomotive Open System ARchitecture的简称，中文就是汽车开放式系统架构

再说直白一点就是：将汽车电子控制单元（ECU）的软件底层进行了标准化封装，使得各方能够共享一套统一的底层软件。用户只需调整部分参数即可适配不同的硬件和应用层软件。这样一来，开发者可以专注于应用层功能的开发，底层的复杂性则由AutoSAR工程师来处理。

二、AUTOSAR架构

首先，我们来看一张整体架构图，后续我们将在这张图上细分和深入，逐步添加细节以进行补充。可以明显看到，AutoSAR 主要分为三个层级：应用软件层（AppL）、实时运行环境（RTE）和基础软件层（BSW）。应用软件层主要用于存放我们自己的逻辑代码，实时运行环境则提供应用层所需的资源，同时实现应用层与底层的隔离。基础软件层负责对硬件进行封装，直到形成一个标准的操作系统状态，以便上层可以规范地调用系统服务。基础软件层又分为几个部分，接下来我们将详细介绍这些部分。

上图中应用层和BSW层都比其他层大一些，这是因为它们两还可以再做细分，接下来我们看下面这张图，我们将应用层和基础软件层做了细分，具体的细节后边再讨论。

2.1. 应用层(APPL)

该层是由一个一个SWC组成的，每个SWC咱们可以理解为一个.c文件，而整个应用软件层就是一个文件夹。用下面这张图应该很好的说明了对应关系：

• 图中右侧的工程仅仅是为了帮助大家理解而建立的一个样板，与 Vector 的实际工程存在很大差异，具体内容将在后续章节中详细介绍。
• 关于组合软件组件（SWC）及其他更详细的说明也将在 SWC 章节中进行讨论。
• 整体工程就是我们的 AutoSAR 架构，其中的应用软件层（AppL）、实时运行环境（RTE）和基础软件层（BSW）分别对应一个文件夹，而我们的 SWC 组件则由一个个 .c 文件和 .h 文件构成。

2.2. 虚拟总线(RTE)

• RTE（Runtime Environment，实时运行环境）同样是AUTOSAR架构的组成之一，负责控制SWC之间的连接以及从SWC到BSW的连接。
• VFB（Virtual Functional Bus，虚拟功能总线）是AUTOSAR中的概念基础，用于SWC之间的通信以及BSW服务的使用。由于SWC通信全部基于VFB，因此SWC独立于ECU硬件。从而可实现在不同项目和平台之间重用SWC。通过为每个ECU配置RTE以及相应的BSW，从而在实际车辆中实现VFB。

2.3. 基础软件层（BSW）

AUTOSAR基础软件层（Basic Software Layer，BSW）可分为四层，即服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer，MCAL）和复杂驱动（Complex Drivers）。

而上述各层又由一系列基础软件组件构成，包括系统服务（System Services）、存储器服务（Memory Services）、通信服务（Communication Services）等，如下图所示。它们主要用于提供基础软件服务，包括标准化的系统功能和功能接口。

三、AUTOSAR接口定义（Interface）

开门见山，AUTOSAR是有三种接口的，为了更好对照AUTOSAR里面的标准概念，此处保留英文名称：

1. AUTOSAR Interface：AUTOSAR接口是通用接口，定义了软件组件（SWC）和/或基础软件（BSW）模块之间交换的信息。该描述独立于特定的编程语言，ECU或网络技术。 AUTOSAR Interface用于定义软件组件和/或BSW模块的端口。通过这些端口，软件组件和/或BSW模块可以彼此通信（发送或接收信息或调用服务）。AUTOSAR使得可以在本地或通过网络在SoftwareComponents和/或BSW模块之间实现这种通信。

2. Standardized AUTOSAR Interface：标准AUTOSAR接口是由AUTOSAR标准预定义的特殊AUTOSAR接口。SWC使用这些类型的接口访问由服务层的BSW模块（例如ECU状态管理器或诊断事件管理器）提供的AUTOSAR服务。

3. Standardized Interface：标准接口是AUTOSAR 中的标准化 API，它有别于 AUTOSAR Interface 技术，通常针对特定编程语言（如 C 语言）定义，主要用于始终处于同一 ECU 上的软件模块间通信。其作为 AUTOSAR 标准用 C 语言预定义的 API 接口，可连接 BSW 模块、RTE 与操作系统或 RTE 与 Com 模块，但采用该接口通信时，软件模块间通信无法进行网络路由。

从上图可以看出，简单地理解：

1、AUTOSAR接口主要用于应用软件组件(SWC)之间以及应用软件组件与基础软件之间(BSW)的通信。
2、标准化AUTOSAR接口主要用于应用软件组件(SWC)与基础软件(BSW)的标准化服务之间的通信。
3、而标准化接口则主要用于不同基础软件模块之间的通信(OS、通信模块可以通过标准化接口与SWC通信)。

软件模块间接口规则（白色框框可以参考BSW层那张图）

• 服务层：允许横向接口。例如：错误管理器使用 NVRAM 管理器保存故障数据。
• ECU 抽象层：允许横向接口。
• 复杂驱动程序可以使用选定的其他基础软件模块。
• 微控制器抽象层：不允许横向接口。例外情况：由于性能原因，允许可配置的通知。
• 一个层可以访问下方软件层的所有接口。
• 应避免绕过一个软件层；
• 绕过两个或更多软件层是不允许的；
• 绕过微控制器抽象层是不允许的。
• 一个模块可以访问另一个层组的下层模块（例如，外部硬件的 SPI）。
• 所有层都可以与系统服务进行交互。

如下图为一般规则层交互矩阵，表示了 AUTOSAR 基础软件层之间允许的交互。

• √ 代表允许使用
• × 不允许使用
• △ 受限使用（仅限回调）

例如：“I/O 驱动程序可以使用系统服务和硬件，但不可以使用其他层。”

四、AUTOASR方法论（Methodology）

AUTOSAR 方法论是应用于汽车电子系统开发的通用技术方法，用于指导关键步骤。它并非完整的过程说明，而是汇聚了 AUTOSAR 的各类关键元素，呈现出将这些元素整合以开发完整系统的方式。其结构设计能满足不同 AUTOSAR 利益相关者的需求：

• 组织方面：以模块化格式进行建模，方便组织按需定制，使其融入自身内部流程，还能明确与其他组织的互动节点。
• 工程师层面：涵盖的范围能助力不同角色的工程师迅速定位与其特定需求相关的 AUTOSAR 信息。
• 工具供应商角度：提供了 AUTOSAR 成员间通用的语言，也明确了对工具应支持功能的共同期望。

不过，AUTOSAR 方法论既不是完整的过程描述，也不属于商业模式，它未对 “角色” 与 “责任” 加以定义，仅仅是一个 “工作产品流程”，且规定了其中存在的依赖关系。

依据 AUTOSAR 方法论，完整的 AUTOSAR 规范配置过程包含系统配置和 ECU 配置两部分，这两部分并无先后顺序要求。

4.1 系统配置

系统配置的输入涵盖了 ECU 配置的相关模块，同时 ECU 配置也会向系统配置进行反馈。在系统级，主要依照功能需求、硬件资源以及系统约束来构建系统架构；而在 ECU 级，则是基于经过抽象处理后的信息去完成相应配置。系统级与 ECU 级的设计工作同步开展，并且都有软件组件开发作为辅助。各环节之间通过良好的通信接口相互连接，且统一采用 arxml（AUTOSAR Extensible Markup Language）文件格式来进行描述。

• 软件组件描述（SW-Component Description）：包含系统中所涉及的软件组件的接口信息，例如数据类型、端口接口、端口等。
• ECU 资源描述（ECU Resource Description-HW only）：包含系统中每个 ECU 需要的处理器及其外设、传感器、执行器等信息。
• 系统约束描述（System Constraint Description）：包含总线信号、软件组件间的拓扑结构和一些映射关系等信息。

系统配置文件通过配置系统（configure-system）将软件组件映射到符合资源和时序要求的ECU 上，输出为系统配置描述文件（system configuration description）。该文件包含软件组件与 ECU 映射时需遵循的约束条件，以及通信矩阵（Communication-Matrix），其中定义了整车网络结构中的数据包内容及其时序关系。

4.2 ECU 配置

系统配置完成后，生成了系统配置描述文件，作为 ECU 配置过程的输入。系统级向 ECU 级的过渡操作被称为 ECU 信息抽取（ECU Extract）。在系统配置阶段，每个 ECU 所需的软件组件、网络通信等信息已被封装，ECU 信息抽取阶段则从中提取出特定ECU 所需信息，以便进行后续配置。在图示中，Extract ECU-Specific Information 负责从系统配置文件中提取各 ECU 的相关配置信息，如通信矩阵、拓扑结构和顶级功能组合，并生成 ECUExtract of System Configuration。

ECU 配置过程主要涉及 RTE 和 BSW 的配置。在 RTE 配置阶段，将软件组件的运行实体映射到相应的操作系统任务；在 BSW 配置阶段，需详细配置所需 BSW 层模块，包括操作系统、通信服务、ECU 抽象层和微控制器抽象层等。基于 ECU 配置信息生成 BSW 和 RTE 代码，结合应用代码，完成代码集成、编译和链接，生成可执行文件。

AUTOSAR 的统一标准化特性确保了 ECU 底层硬件升级时不必影响其他软件系统。凭借这一标准化优势，越来越多企业正加入 AUTOSAR 生态，为未来汽车电子行业内高效管理和复用复杂汽车软件系统奠定了坚实基础。

参考文档：AUTOSAR_EXP_LayeredSoftwareArchitecture