汽车开放系统架构（AUTOSAR）简介

快速链接:
.
个人博客笔记导读目录(全部)

简介

汽车开放系统架构(AUTOSAR : AUTomotive Open System ARchitecture)是2003年成立的汽车相关方的开发合作伙伴。它追求的目标是为汽车电子控制单元（ECU : electronic control units）创建和建立一个开放和标准化的软件架构。目标包括对不同车辆和平台变体的可扩展性、软件的可转移性、可用性和安全要求的考虑、不同合作伙伴之间的协作、自然资源的可持续利用以及产品生命周期中的可维护性

背景和历史

AUTOSAR 于 2003 年 7 月由 Bavarian Motor Works ( BMW )、Robert Bosch GmbH、Continental AG、Daimler AG（前身为 Daimler-Benz，然后是 DaimlerChrysler）、Siemens VDO和Volkswagen 成立，旨在促进汽车电子电气的开放行业标准（ E/E) 架构。2003年11月，福特汽车公司作为核心合作伙伴加入，12月，PSA集团（原PSA标致雪铁龙）和丰田汽车公司加入。次年 11 月，通用汽车也成为了核心合作伙伴。西门子 VDO 于 2008 年 2 月被大陆集团收购后，不再是独立的核心合作伙伴。

自 2003 年以来，AUTOSAR 为其经典平台提供了四个主要的汽车软件架构版本和一个验收测试版本。工作可分为三个阶段：

• 第一阶段（2004-2006）：标准的基本开发（版本 1.0、2.0、2.1）[4]
• 第二阶段（2007-2009）：架构和方法学标准的扩展（版本 3.0、3.1、4.0）[5]
• 第三阶段（2010-2013）：维护和部分改进（版本 3.2、4.1、4.2）[6]

2013 年，AUTOSAR 为其经典平台进入持续工作模式，以保持标准并提供部分改进，包括版本 R4.2 和验收测试 1.0。

2016 年，自适应平台的工作开始了。第一个版本 (17-03) 于 2017 年初发布，随后是 2017 年 10 月的 17-10 版本[7]和 2018 年 3 月的 18-03 版本。[8]随着 2018 年 10 月的 18-10 版本，主要开发活动发表。[9]

2020 年 12 月，AUTOSAR R20-11 虚拟发布

概念和目标

AUTOSAR 提供基本软件模块的规范，定义应用程序接口并构建基于标准化交换格式的通用开发方法。AUTOSAR分层软件架构提供的基础软件模块可以用于不同制造商的车辆和不同供应商的电子元件，从而减少研发支出。[6]

基于这一原则，AUTOSAR 旨在为即将到来的技术做好准备

软件架构

AUTOSAR 使用三层架构：[12]

• 基础软件：标准化的软件模块（大部分）没有明确的汽车工作，但提供运行上层软件层功能部分所需的服务。[13]
• 运行时环境(RTE)：从网络拓扑中抽象出来的中间件，用于应用软件组件之间以及基础软件和应用程序之间的ECU内部和内部信息交换。[14]
• 应用层：与运行时环境交互的应用软件组件

方法论

系统配置说明包括所有系统信息和不同ECU 之间约定的信息（例如总线信号的定义）。
ECU 提取：包含来自特定 ECU 所需的系统配置描述的信息（例如，特定 ECU 可以访问的那些信号）。
ECU 配置说明：包含特定 ECU 本地的所有基本软件配置信息。使用这些信息来构建可执行软件、基本软件模块的代码和软件组件的代码

经典平台

AUTOSAR 经典平台是基于OSEK 的嵌入式实时ECU 的标准。它的主要交付物是规格。

该架构区分了在微控制器上运行的三个软件层：应用程序、运行时环境 ( RTE ) 和基础软件 (BSW)。应用软件层大多与硬件无关。软件组件之间的通信和对 BSW 的访问是通过 RTE 进行的，它代表了应用程序的完整接口。

BSW 分为三个主要层和复杂的驱动程序：

• 服务
• 电子控制单元 (ECU) 抽象
• 微控制器抽象

服务被进一步划分为代表系统、内存和通信服务基础设施的功能组。

经典平台的一个基本概念是虚拟功能总线 (VFB)。这个虚拟总线是一组抽象的 RTE，尚未部署到特定的 ECU，并将应用程序与基础设施分离。它通过专用端口进行通信，这意味着应用软件的通信接口必须映射到这些端口。VFB 处理单个 ECU 内和 ECU 之间的通信。从应用程序的角度来看，不需要详细了解较低级别的技术或依赖项。这支持独立于硬件的应用软件开发和使用。

经典平台还可以通过使用 Franca 接口定义语言 ( Franca IDL )来集成非 AUTOSAR 系统，例如GENIVI

自适应平台

新的用例需要开发自适应平台。一个例子是自动驾驶，在这种情况下，驾驶员暂时和/或部分地将驾驶责任转移给车辆。这可能需要与交通基础设施（例如交通标志和信号灯）、云服务器（例如访问最新的交通信息或地图数据）进行通信，或使用微处理器和高性能计算硬件进行并行处理，例如图形处理单元（GPU）。

此外，Car-2-X 应用需要与车辆和非车载系统进行交互。这意味着系统必须提供安全的机载通信、跨域计算平台的支持、智能手机集成、非 AUTOSAR 系统的集成等。此外，基于云的服务将需要专门的安全手段，例如安全的云交互和紧急车辆抢占。它们将启用远程和分布式服务，例如远程诊断、无线 (OTA) 更新、修复和交换处理。

为了支持客户应用程序的动态部署并为需要高端计算能力的应用程序提供环境，AUTOSAR 目前正在对 AUTOSAR 自适应平台进行标准化。它的核心是一个基于POSIX标准的操作系统。根据IEEE1003.13（即 PSE51），可以通过 POSIX 的子集从应用程序中使用操作系统。自适应平台的关键特性之一是面向服务的通信，因为该平台基于面向服务的架构。[19]

自适应 AUTOSAR 是使用 C++ 开发和编写的，C++ 是一种面向对象的编程语言。车载网络使用的通信协议是SOME/IP，基于以太网。有两种类型的接口可用：服务和应用程序编程接口(API)。该平台由按服务分组的功能集群和 AUTOSAR 自适应平台基础组成。

功能集群：

• 组装自适应平台的功能
• 定义需求规范的聚类
• 从应用和网络的角度描述软件平台的行为
• 不要限制实现自适应平台的架构的最终软件设计。

AUTOSAR Adaptive Platform 中的功能集群每台（虚拟）机器必须至少有一个实例，而服务可能分布在车载网络中。

自适应平台服务包括：

• 更新和配置管理
• 状态管理
• 网络管理
• 诊断

自适应平台包含规范和代码。与经典平台相比，AUTOSAR 开发了一个实现来缩短验证周期并说明底层概念。此实施适用于所有 AUTOSAR 合作伙伴

基金会

基础标准的目的是加强 AUTOSAR 平台之间的互操作性。该基础包含 AUTOSAR 平台之间共享的通用要求和技术规范（例如协议），以及通用方法

验收测试

2014 年，引入了验收测试以最大限度地减少测试工作量和成本。验收测试规范是使用相应平台的指定接口的系统测试规范。此外，他们正在考虑总线上的特定行为。它们可以被视为给定平台功能的黑盒测试用例。标准验收测试的规范有助于实现这些目标

标准化的应用程序接口

跨制造商和供应商的功能接口标准化以及不同软件层之间接口的标准化被视为实现 AUTOSAR 技术目标的基础。[28] [29]只有通过在物理和时间表示中标准化具体接口内容，才能实现所需的集成兼容性

组织
AUTOSAR 定义了六个不同级别的成员资格。合伙人的贡献因合伙类型而异：

• 核心合作伙伴
• 战略合作伙伴
• 高级合作伙伴
• 合伙人
• 开发伙伴
• 参加者

核心合作伙伴包括创始合作伙伴宝马、博世、大陆集团、戴姆勒股份公司、福特、通用汽车、PSA 标致雪铁龙、丰田和大众。[32]这些公司负责 AUTOSAR 开发伙伴关系的组织、管理和控制。[30]在这个核心范围内，执行委员会定义了总体战略和路线图。[33]指导委员会管理日常非技术运营和合作伙伴的接纳、公共关系和合同问题。[34]主席和副主席，任期一年，为此目的代表指导委员会。[35] AUTOSAR 发言人接管了与外界的沟通。[36][37]

战略合作伙伴从高级合作伙伴圈中任命，任期为两年，并在各种技术、组织和日常流程中为项目领导团队提供支持。他们还为项目领导轮提供了新的战略投入。

Premium 和 Development 成员为由核心合作伙伴建立的项目领导团队协调和监控的工作包做出贡献。[30] [38]合作伙伴正在使用 AUTOSAR 已经发布的标准文件。[39]与会者目前正在参与学术合作和非商业项目