AUTOSAR（汽车开放系统架构）合作伙伴关系成立于 2003 年，是一种面向汽车行业内各组织的开发伙伴关系。该联盟为汽车电子控制装置开发开放的、标准化的软件架构。
| AUTOSAR |
|---|
 |
| 公司類型 | 开发合作关系 |
|---|
| 成立 | 2003 年 |
|---|
| 代表人物 | Michael Niklas-Höret (主席， 2024)
Thomas Rüping（副主席，2024） |
|---|
| 總部 | 德国巴伐利亚州（管理中心） |
|---|
| 产业 | 汽车、 E/E、软件、半导体 |
|---|
| 員工人數 | 366家 公司（ 2023年 12月） |
|---|
| 网站 | www.autosar.org |
|---|
AUTOSAR 由宝马集团（BMW）、博世公司（Bosch）、大陆集团（Continental）、梅赛德斯奔驰（Mercedes-Benz Group AG）、西门子威迪欧（Siemens VDO）汽车电子公司以及大众公司（Volkswagen）于 2003年 7 月联合建立，旨在为汽车电气/电子构架开发一套开放的行业标准。2003 年福特汽车公司（Ford Motor Company）加入联盟，成为其核心成员。2003 年 12 月，Stellantis公司（Stellantis）和丰田汽车公司（Toyota Motor Corporation）加入联盟。2004 年 11 月通用汽车公司（General Motors）成为其核心成员[1] 。
2008 年 2 月，西门子威迪欧（Siemens VDO）汽车电子公司被大陆集团（Continental）收购，不再是 AUTOSAR 独立核心成员[1]。
自 2003 年起，AUTOSAR 共推出了四版主要的标准化汽车软件构架和一个验收测试版。AUTOSAR 的开发成果可以分为三个阶段：
- 第一阶段（2004-2006）：标准规范的初步开发阶段（1.0、2.0 和 2.1版）
- 第二阶段（2007-2009）：标准规范中的架构及其方式的补充阶段（3.0、3.1 和 4.0版）
- 第三阶段（2010-2013）：维持和部分改进阶段（3.2、4.1 和 4.2版） [2] [3]
2013 年 AUTOSAR 始终努力维持着现有标准规范，并对部分标准加以改进（包括 R4.2 版和验收测试标准 1.0）。
2016年，AUTOSAR开始着手自适应平台的开发工作。 2017年初发布首个版本（17-03），2017年10月和2018年3月相继发布版本17-10和18-03。 其目标是在2018年10月联合发布AUTOSAR经典平台、自适应平台和基础，以此为节点结束主要开发活动。
从2019年开始，经典AUTOSAR的新版本都在11月发行，版本号以年份加11标定，如AUTOSAR Classic Release R23-11、AUTOSAR Adaptive Release R23-11。
AUTOSAR 制订一系列标准规范，包括基础软件模块规范介绍、应用接口定义规范以及基于标准转换形式建立一套通用的开发方法论，以应用于不同厂家生产的车辆以及不同供应商提供的电子部件。
AUTOSAR采用三层架构[4]：
- 基础软件：大多数标准化的软件模块本身并不参加实际工作，但能够为上层软件功能正常运行提供必需服务[5] 。
- 运行环境（RTE）：源自网络扑拓结构中的中介软件，用以实现ECU内部及不同 ECU 间的通信交换（应用软件组件之间以及基础软件和应用软件之间）[6]。
- 应用层：应用软件组件与运行环境相辅相成[7]。
- 系统配置描述：包含所有系统信息以及不同ECU之间约定的信息（例如总线信号的定义）。
- ECU信息抽取：包含从系统配置描述抽取的特定ECU所需要的信息（例如特定ECU获取的信号）。
- ECU配置描述：包含特定ECU所需要的所有基础软件配置信息。 根据这些信息生成执行软件、基础软件模块代码以及软件组件代码。[8]
AUTOSAR经典平台（Classic Platform）是基于OSEK标准的嵌入式实时ECU标准。 其可交付成果主要为规范。
AUTOSAR经典平台架构，在最高抽象级别上对运行在微控制器上的三个软件层做出了区分：应用程序层（Application Layer）、运行时环境（RTE）、基础软件（BSW）[9]：
- 应用程序层大多与硬件无关。
- 软件组件之间、软件组件和基础软件之间都通过RTE进行通信。
- 运行时环境RTE代表所有应用的完整接口。
- 基础软件BSW分为三个主要层以及复杂驱动层：
- 服务层
- 电子控制单元抽象层（Electronic Control Unit, ECU）
- 微控制器抽象层
- 服务层可视作由多个功能组组成的架构，包括系统服务、内存服务、加密服务、车外通信服务、通信服务
- 电子控制单元抽象层包括：车载设备抽象、内存硬件抽象、加密硬件抽象、无线通信硬件抽象、通信硬件抽象、输入输出硬件抽象
- 微控制器抽象层包括：微控制器驱动器、内存驱动程序、加密驱动程序、无线通信驱动程序、通信驱动程序、输入输出驱动程序
经典平台的一个基本概念是虚拟功能总线（Virtual Function Bus，VFB）。 该虚拟总线是尚未部署到特定ECU的RTE抽象集，这些RTE将应用程序与基础架构分离。 它通过专用端口进行通信，这意味着应用软件的通信接口必须映射到这些端口。 VFB处理单个ECU内和多个ECU之间的通信。 从应用程序角度来看，不需要了解有关低级别技术或依赖关系的详细知识。 这样就使得应用软件的开发和使用无需依赖硬件进行。
经典平台还可以使用Franca接口描述语言（IDL）集成GENIVI等非AUTOSAR系统。
为适应新用例的需求，AUTOSAR开发了自适应平台（Adaptive Platform）。 一个突出的例子是
高度自动化驾驶，在该环境中，驾驶员暂时和/或部分地将驾驶责任转移给车辆。 这种情况下需要与交通基础设施（例如交通标志、交通灯）、云服务器（例如访问最新的交通信息或地图数据）等进行通信，或使用微处理器和高性能计算硬件进行并行处理（例如GPU）。
此外，Car-2-X应用还需要与车辆和车外系统进行交互沟通。 这意味着该系统必须具备安全的车载通信功能、支持跨域计算平台、智能手机集成、非AUTOSAR系统集成等。 此外，还需要采取专门的措施，保证云服务的安全，例如安全云交互和应急车辆优先。 它们可支持远程和分布式服务，例如远程诊断、空中下载（OTA）更新、修复和交换处理。
AUTOSAR目前正在对AUTOSAR自适应平台进行标准化处理，使其支持客户应用的动态部署，并为需要高端计算能力的应用提供适宜的环境。 该平台的核心是基于 POSIX 标准的操作系统。 根据IEEE1003.13（即PSE51），操作系统可以通过POSIX的子集从应用中调用。 自适应平台的一个关键特性是面向服务的通信。
自适应平台可以使用两种类型的接口：服务和应用程序编程接口（API）。 该平台由分布在服务层中的功能聚类和AUTOSAR自适应平台基础组成。
功能聚类：
- 汇编自适应平台的功能
- 确定需求规格说明书的聚类
- 从应用和网络角度描述软件平台的行为
- 但是，不得限制实现自适应平台的架构的最终软件设计
AUTOSAR自适应平台基础中的功能聚类在每台（虚拟）机器中必须至少有一个实例，而服务则可以分布在车内网络中。
自适应平台服务包括：
- 更新和配置管理
- 状态管理
- 网络管理
- 诊断
AUTOSAR自适应平台包含规范和代码。 与经典平台相比，AUTOSAR开发的实现可缩短验证周期并说明基本概念。 该实现适用于所有AUTOSAR成员。
基础标准的目的是加强AUTOSAR平台之间的互操作性。 基础包含AUTOSAR平台之间共享的通用需求和技术规范（例如协议）以及常用方法。
为了降低测试的工作量及测试成本，AUTOSAR验收测试规范于2014年应运而生。 验收测试规范实则为利用相应平台指定接口的系统测试规范。 另外也考虑了在总线上的指定行为。 可将其视为针对特定平台功能的黑盒测试用例。 标准验收测试规范有助于实现以上目标。[8]
AUTOSAR以制造商和供应商之间功能性接口的标准化以及软件各分层接口的标准化为基础，实现其技术目标[10]。
AUTOSAR入会形式分为六种。 成员合作方式不同，身份职责也不同： [14]
- 特技合作伙伴
- 高级合作伙伴
- 一般合作伙伴
- 开发合作伙伴
- 观察员
- 个人用户
核心合作伙伴为宝马、博世、大陆、梅赛德斯奔驰、福特、通用汽车、Stellantis、丰田和大众9位创始伙伴。 [15] 这些公司主要负责AUTOSAR开发联盟的组织、管理和调控。 [14] 其中，执行董事会负责制定全局策略和整体发展路线图。 [16] 指导委员会负责处理非技术性日常事务、会员入会、公共关系以及合约问题。 [17] 指导委员会任命主席和副主席，任期为九个月。 [11] AUTOSAR发言人负责外联工作。[12][13] [14]
特技合作伙伴在多种技术、组织和日常流程工作中支持项目项目主管团队。同时，他们将在项目主管层面输入新的战略观点。
高级合作伙伴和开发合作伙伴在核心合作伙伴组建的项目领导小组的协调和监督下开展工作。[15] [16] 一般成员根据AUTOSAR已发布的标准文件开展工作[17]。 观察员目前以学术合作和非商业项目的形式参与联盟活动[18]。
截至2023年12月，AUTOSAR开发联盟的成员公司已超过360家。[15]
