AUTOSAR入门介绍
AUTOSAR官网：https://www.autosar.org/
一、AUTOSAR由来
1、AUTOSAR背景
在汽车创新应用不断涌现的推动下，汽车的电子控制系统一直在高速发展，当前汽车电子电汽（E/E）架构日益复杂，面临的挑战也越来越多，主要包括以下几个方面：
- 控制器数量增加，网络复杂度增加。
- 软件功能数量急剧增加。
- 硬件平台多样型，软件可复用性差。
- 软件开发周期缩短。
- 软件成本占比增加。
汽车原始设备制造商（Car OEM）和一级供应商（Tier 1）为了奠定行业协作创新发展基础，同时打造一个继续鼓励功能创新和质量竞争的平台，建立了一种汽车开放系统架构（AUTomotive Open Source ARchitecture, AUTOSAR）的开发合作伙伴关系：AUTOSAR联盟。当前AUTOSAR联盟的核心成员有：
除核心成员外，AUTOSAR联盟还有高级成员、开发成员和合作成员等众多伙伴：
AUTOSAR是由来自电子、半导体和软件行业的汽车制作商、供应商和其他公司组成的全球开发合作联盟。自2003年以来，他们一直在为汽车行业的开发引入开放、标准化的软件架构。
AUTOSAR的基本思想是复用（Re-use）软件组件，以便应对未来日益复杂的汽车电子系统开发。
2、AUTOSAR概述
AUTOSAR联盟旨在共同开发和建立汽车E/E架构的开放行业标准，并将其作为未来汽车ECU应用程序中功能管理的基础措施和标准软件模块。
AUTOSAR适用范围包括所有汽车电子应用领域（Vehicle Domains），重点关注车身、动力传动和底盘安全领域。所有车辆控制应用都可以使用AUTOSAR标准，特别是分布式系统相关功能（例如通过总线）。
AUTOSAR将作为未来汽车应用实施的平台，并有助于最小化功能领域之间的障碍。因此可以将功能网络映射到系统中的不同控制节点，从而实现ECU功能与底层硬件平台的独立。
3、AUTOSAR目的
AUTOSAR开发合作的主要目标是基本系统功能和功能接口的标准化。这使得开发合作伙伴能够在汽车网络中实现集成、交换和传递功能，并大大改进汽车生命周期内的软件更新和升级。考虑到这一目标，AUTOSAR推动了从ECU到基于功能的系统设计尝试在汽车软件开发中的范式转变——实现从基于ECU到基于功能的系统设计，并且能够降低技术和经济方面日益增加的E/E架构的复杂性。
AUTOSAR联盟自成立至今，一直提倡“在标准上合作，在实现上竞争”的原则，标准大家共同制定，但具体的实现方法由各公司自己去探索。其核心思想在于“同一标准，分散实现，集中配置”。
- “统一标准”是为各个厂商提供一个开放的、通用的平台；
- “分散实现”要求软件系统高度的层次化和模块化，同时还要降低应用软件与硬件平台之间的耦合；
- “集中配置”是指不同的模块可以由不同公司去完成开发，但想要完成最终软件系统的集成，就需要将所有模块的配置信息以统一的格式集中整合并管理起来，从而配置生成一个完整的系统。
AUTOSAR的官网介绍可以访问以下链接：
https://www.autosar.org/fileadmin/user_upload/AUTOSAR_EXP_Introduction_Part1.pdf
https://www.autosar.org/fileadmin/user_upload/AUTOSAR_EXP_Introduction_Part2.pdf
二、AUTOSAR发展
AUTOSAR的发展，分为几个阶段，详细描述可以参考官网的历史页面：https://www.autosar.org/about/history/
初始化（2002 - 2003）
| 时间线 | 内容 |
|---|---|
| 2002.08 | 启动研讨会，成立团队 |
| AUTOSAR战略的第一个路线图 | |
| 宝马、博世、大陆、戴姆勒克莱斯勒和大众汽车就共同面临的挑战和目标进行了初步讨论 | |
| 西门子VDO加入合作伙伴的行业 | |
| 2002.10 | 基本伙伴关系定义 |
| 2003.05 | 项目里程碑，阶段1：启动伙伴关系：指定并商定项目计划 |
| 2003.07 | 经典平台架构起草 |
| 核心合作伙伴签署初始化AUTOSAR开发协议 |
阶段1（2003 - 2006）
| 时间线 | 内容 |
|---|---|
| 2003.09 | AUTOSAR在Baden-Baden VDI 会议上首次正式发布，介绍AUTOSAR目标 |
| 2003.11 | 福特汽车作为核心合作伙伴加入 |
| 2003.12 | 标致雪铁龙和丰田汽车公司作为核心合作伙伴加入 |
| 2004.06 | 项目里程碑，阶段1：结构和基本规范：创建了AUTOSAR概念和第一个规范，并批准了可执行性 |
| 2004.11 | 通用汽车成为核心合作伙伴 |
| 2005.06 | 经典平台1.0版本 |
| 2005.08 | 项目里程碑，阶段1：软件组件的标准化：选定软件组件的AUTOSAR兼容性获得批准。First tools and generators were in place。 |
| 2006.05 | 经典平台2.0版本 |
| 2006.08 | 项目里程碑，阶段1：测试和集成过程：AUTOSAR规范在应用程序上进行了测试和验证。 |
| 2006.12 | 经典平台2.1版本 |
| 开发阶段1结束 |
阶段2（2007 - 2009）
| 时间线 | 内容 |
|---|---|
| 2007.12 | 经典平台3.0版本 |
| 2008.02 | 西门子VDO成为大陆集团的一部分。从此西门子VDO不再是AUTOSAR自成一体的核心合作伙伴。 |
| 2008.08 | 经典平台3.1版本 |
| 2008.10 | 第一届AUTOSAR底特律公开会议 |
| 2009.12 | 经典平台4.0版本，阶段2 |
阶段3（2010 - 2012）
| 时间线 | 内容 |
|---|---|
| 2010.05 | 第二届AUTOSAR东京公开会议 |
| 2011.05 | 经典平台3.2版本，阶段3 |
| 第三届AUTOSAR法兰克福公开会议 | |
| 2012.06 | 第四届AUTOSAR巴黎公开会议 |
| 2012.11 | 第五届AUTOSAR北京公开会议 |
AUTOSAR可持续发展（2013 - 至今）
| 时间线 | 内容 |
|---|---|
| 2013.03 | 经典平台4.1.0，进入稳定阶段 |
| 2013.09 | 第六届AUTOSAR慕尼黑公开会议 |
| 2014.06 | 验收测试版本1.0.0 |
| 2014.10 | 第七届AUTOSAR底特律公开会议 |
| 经典平台4.2.1版本 | |
| 2015.07 | 经典平台4.2.2版本 |
| 2015.10 | 第八届AUTOSAR东京公开会议 |
| 验收测试版本1.1.0 | |
| 2016.09 | 第九届AUTOSAR哥德堡公开会议 |
| 2016.10 | 经典平台4.3.0版本 |
| 基本版本1.0.0 |
启动自适应平台AP，标准化经典平台CP（2017 - 至今）
| 时间线 | 内容 |
|---|---|
| 2017.03 | 为自适应平台开发“示例软件” |
| 自适应平台发布 |
三、AUTOSAR方法论（Methodology）
除了软件架构外，AUTOSAR为汽车电子软件系统开发过程定义了一套通用的技术方法，即AUTOSAR方法论。该方法描述了从系统底层配置到ECU可执行代码产生过程的设计步骤。
参考经典AUTOSAR中的介绍：
AUTOSAR提供了一种方法来指定在ECU上集成软件组件所需的所有方面，并将不同的ECU集成到各种不同总线系统上的整个网络通信中。该方法定义了活动对工作产品的依赖关系，并预计将支持AUTOSAR中工具的活动、描述和使用。
AUTOSAR方法论中车用控制器软件的开发涉及系统级、ECU级和软件组件级。系统级主要考虑系统功能需求、硬件资源、系统约束，然后建立系统架构；ECU级别根据抽象后的信息对ECU进行配置；系统级和ECU级设计的同时，伴随着软件组件级的开发。上述每个环节都有良好的通信接口，以此构建了AUTOSAR方法论。
基于AUTOSAR方法论，在开发之前，需要先编写系统配置输入描述文件，其中包含三部分内容：
- 软件组件描述（SW-Component Description）：包含系统中所涉及的软件组件的接口信息，例如数据类型、端口接口、端口等。
- ECU资源描述（ECU ResourceDescription-HW only）：包含系统中每个ECU所需要的处理器及其外设、传感器、执行器等信息。
- 系统约束描述（System Constraint Description）：包含总线信息、软件组件间的拓扑结构和一些映射关系等信息。
AUTOSAR相关规范：
https://www.autosar.org/fileadmin/user_upload/standards/classic/3-0/AUTOSAR_TechnicalOverview.pdf
https://www.autosar.org/fileadmin/user_upload/standards/foundation/21-11/AUTOSAR_RS_Methodology.pdf
https://www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_TR_Methodology.pdf
https://www.autosar.org/fileadmin/user_upload/standards/adaptive/21-11/AUTOSAR_TR_AdaptiveMethodology.pdf
四、AUTOSAR接口
AUTOSAR规范中，将不同模块间通信的接口主要分为以下三类：
- AUTOSAR接口（AUTOSAR Interface）
- 标准AUTOSAR接口（Standardized AUTOSAR Interface）
- 标准接口（Standardized Interface）
AUTOSAR接口输入应用接口，是从软件组件的端口衍生来的通用接口，描述数据或服务。它由RTE提供给软件组件，可以作为软件组件间通信的接口，描述数据或者服务，可以作为软件组件间通信的接口。AUTOSAR接口非标准接口，可自定义。（在AUTOSAR规范中已对车身、地盘及动力传动系统控制领域的应用接口做了一些标准化工作。）
标准AUTOSAR接口是一种特殊的AUTOSAR接口，在AUTOSAR规范中有明确的定义。
标准接口在AUTOSAR规范中以C/C++语言中API的形式明确定义。主要用于ECU上各个模块间、进程和操作系统间，一般应用软件组件不可直接访问。
五、AUTOSAR标准规范
AUTOSAR标准包括基本标准、经典平台、自适应平台。其中，
- AUTOSAR基础（Foundation，FO）标准的目的是强制AUTOSAR平台的之间的互操作性，其中包含AUTOSAR标准之间的共享的共同要求和技术规范（如协议）。
基于基础标准，又分为经典平台（Classical Platform， CP）和自适应平台（Adaptive Platform， AP）。其中，
- 经典平台是AUTOSAR针对基于MCU的硬实时和安全约束较高的嵌入式系统的解决方案；
- 自适应平台是AUTOSAR的高性能技术MPU/CPU的ECU解决方案，可构建用于娱乐导航和高度自主驾驶等用例的操作系统。
基于经典平台平台，也衍生了验收测试标准（Acceptance Tests，AT）和应用接口（Application Interface，AI）标准。而自适应平台，由于还在发展中，当前并没有相对应的规范提取整理。
1、文档类型
在AUTOSAR官方网站（https://www.autosar.org/），大家可以下载AUTOSAR开发合作伙伴发布的文档，其中包含如下两类不同类型的规范。
- 标准规范。标准规范是描述AUTOASR开发合作伙伴关系规范结果的文档、模型或格式。产品必须实现AUTOSAR要求的指定内容。
- 辅助材料。辅助材料支持文档、模型或格式，旨在进一步解释和/或改进AUTOSAR开发合作伙伴关系标准规范的可用性。阅读使用辅助材料可以更好的了解或统一使用AUTOSAR标准。
在文件命名上面，AUTOSAR使用不同的缩写表时不同的文档类型。
| 缩写 | 全拼 | 解析 |
|---|---|---|
| RS | Requirements Specification | 需求规范 |
| PRS | Protocol Requirements Specification | 协议需求规范，如some/ip，dlt |
| SRS | Software Requirement Specification | 软件需求规范，用于对各个软件模块功能需求进行说明 |
| SWS | Software Specification | 软件规范，详细介绍模块设计和实现原理，包括模块功能的详细介绍，API接口介绍，数据类型介绍，软件的流程图 |
| TR | Technical Report | 技术报告，技术规格详细介绍 |
| EXP | Explanatory Documents | 说明文档，对其他文档中提到的内容进行解释说明 |
| MMOD | Meta Model | AUTOSAR的标准化元模型 |
| MOD | Model | AUTOSAR的标准化模型 |
| TMPL | Template | AUTOASR模板 |
| TPS | Template Specification | 模板规范，用于介绍模块的处理架构、层次关系等 |
2、基本标准
这个基本标准的目前是加强AUTOSAR平台之间的互操作。Foundation包含了AUTOSAR平台之间共享的通用要求和技术规范（例如协议）。
3、经典平台
AUTOSAR 经典平台架构在最高抽象级别上区分了在微控制器上运行的三个软件层：应用程序、运行时环境 (RTE) 和基本软件 (BSW)。
- 应用软件层大多独立于硬件。
- 软件组件之间的通信以及通过 RTE 访问 BSW。
- RTE 代表应用程序的完整接口。
- BSW 分为三个主要层和复杂的驱动程序：
- 服务、ECU（电子控制单元）抽象和微控制器抽象。
- 服务进一步划分为代表系统、内存和通信服务基础设施的功能组。
4、自适应平台
AUTOSAR 自适应平台实现了自适应应用程序的 AUTOSAR 运行时 (ARA)。 有两种类型的接口可用，服务和 API。 该平台由按服务和自适应 AUTOSAR 基础分组的功能集群组成。
功能集群…
- 组装自适应平台的功能
- 定义需求规范的集群
- 从应用和网络的角度描述软件平台的行为
- 但是，不要限制实现自适应平台的架构的最终软件设计。
AUTOSAR Adaptive Platform Basis 中的功能集群必须在每台（虚拟）机器上至少有一个实例，而服务可能分布在车载网络中。
与 AUTOSAR 经典平台相比，自适应平台的 AUTOSAR 运行时环境在运行时动态链接服务和客户端。
附1：术语表
| 缩写 | 全拼 | 含义 |
|---|---|---|
| AUTOSAR | AUTomotive Open Source ARchitecture | 汽车开放架构 |
| E/E | Electronic/Electrical | 电子/电气 |
| ECU | Electronic Control Unit | 电子控制单元 |
| ASW | Application Software Layer | 应用软件层 |
| SWC | Software Component | 软件组件 |
| RTE | Runtime Environment | 运行时环境 |
| BSW | Basic Software Layer | 基础软件层 |
| MCAL | Microcontroller Abstraction Layer | 微控制器抽象层 |
附2：参考资料
- 《汽车软件架构》
- 《AUTOSAR规范与车用控制器软件开发》
- 《AUTOSAR MCAL的原理与实践》