先说点什么
AUTOSAR已经是越来越火了，不断的有车企开始使用，并且AUTOSAR也已经蔓延到了工业界，但是现在头部的Tire1厂商，为了垄断市场、生态闭源等一系列的目的，将AUTOSAR进行了工具化，买工具就能实现快速的框架配置，这样对于车场会有很多好处，但是对于我们开发者就有很多问题了，时间长了我们可能会成为工具人，只会使用工具配置的工具人，老话说的好：
打铁还需自身硬，所以我们要学习它，理解它，掌握它，让我们拒绝工具人。起源
在2003年7月，由：
- Bavarian Motor Works (BMW)
- Continental AG(大陆)
- Daimler AG (戴姆勒)
- Volkswagen(大众)
联合推出的一套
开放式的汽车电器电子架构（E/E）行业标准，同年- Groupe PSA(标志雪铁龙)
- Toyota Motor Corporation(丰田)
- General Motors(通用)
加入并成为核心成员。
概念和原则
AUTOSAR 提供基本
软件模块的规范，定义应用程序接口并建立基于标准化交换格式的通用开发方法。 AUTOSAR是一套分层的、模块化的软件架构，AUTOSAR分层软件架构提供的基础软件模块可用于不同制造商的车辆和不同供应商的电子元件，从而加速研发并减少研发支出。AUTOSAR定义了软件框架、软件接口、还有软件方法（通过这个方法可以配置完整的AUTOSAR）
软件架构
AUTOSAR包括：
Classic Platform、Adaptive platform、Foundation、Acceptance Tests、Application InterfacesClassic Platform
一些概念
Classic Platform软件架构的主要概念是通过软件抽象层RTE（运行时环境）将独立于硬件的应用软件和面向硬件的基础软件（BSW）分离。 在 RTE 的上层，这个抽象层支持 OEM 特定和竞争性软件应用程序的开发。 在 RTE 的下侧，它实现了基础软件的标准化和 OEM 独立性。
架构
AUTOSAR的经典平台，被抽象成了3个层，分别是：
- Application
- Runtime environment (RTE)
- Basic software (BSW)
特点
- 应用层大多是独立于硬件
- 应用层的通信是用过RTE访问BSW层
- RTE层可以代表APP的所有接口
- BSW主要分为3个层和复杂的驱动程序
- 服务层
- ECU（电子控制单元）抽象层
- 微控制器抽象层
AUTOSAR 软件架构的进一步特点是 ECU 软件适用于多个汽车系列和变体的可扩展性、跨 ECU 分发应用程序（功能软件模块）的可能性，以及集成来自不同来源的软件模块的能力。
AUTOSAR有两个最大的特点
分离：如上面说的经典的框架中使用RTE将软硬分离，App与驱动分离
方法统一：由于一套完整的车机系统，不是单一硬件商或者软件供应商可以完成的，如果各自为战，很难获得一个很好的系统，这个时候就需要一种统一的思想，统一的方法给与指导，可以使各部分协作开发，AUTOSAR很大一部分内容就是这些的说明。
例如一些统一的接口，一些通信上的统一等等。
模板&方法
AUTOSAR使用（
.arxml）文件描述，基于定义正式交换格式 (AUTOSAR Schema) 的 AUTOSAR 模板和与交换格式一起出现的语义约束。描述用于保存在 AUTOSAR 方法中产生或使用的信息。各种生成器可以利用描述中的信息来支持 RTE 和 AUTOSAR 基础软件（包括操作系统）的配置和生成。Adaptive platform
一些概念
随着技术的发展，经典的AUTOSAR平台已经不能满足现在的功能需求了，所以Adaptive platform就应运而生，Adaptive platform是一种基于面向服务的架构，由
自适应应用程序、自适应应用程序运行Runtime、服务、基础的功能集群组成。例如现在市场上比较火爆的自动驾驶，在这种情况下驾驶员需要将驾驶责任交给车辆，这可能需要与交通基础设施（例如交通标志和信号灯）、云服务器（例如访问最新的交通信息或地图数据）进行通信，或者使用微处理器和高性能计算硬件进行并行处理，例如图形处理单位（GPU）。
这意味着该系统必须提供安全的车载通信、跨域计算平台的支持、智能手机集成、非 AUTOSAR 系统的集成等。此外，基于云的服务将需要专用的安全手段，例如安全的云交互和紧急车辆抢占。它们将支持远程和分布式服务，例如远程诊断、空中 (OTA) 更新、修复和交换处理。
特点
- 装配或者是组装自适应平台的功能
- 定义需求规范的集群
- 从应用软件和网络的角度描述软件平台的行为
- 但是，不要限制实现自适应平台的架构的最终软件设计
- AUTOSAR Adaptive Platform Basis 中的功能集群必须在每台（虚拟）机器上至少有一个实例，而服务可能分布在车载网络中
- 与 AUTOSAR 经典平台相比，自适应平台的 AUTOSAR 运行时环境在运行时可以动态链接服务和客户端
- Adaptive Platform是一个基于 POSIX 标准的操作系统
- Adaptive Platform使用C++开发
完美，你现在已经对AUTOSAR有了一些基本的概念级别的了解，让我们继续。Foundation
一些概念
基础标准是加强 AUTOSAR 平台之间的互操作性。该基础包含 AUTOSAR 平台之间共享的通用要求和技术规范（例如协议），以及通用方法。
包含的内容
- 目标和主要要求
软件架构说明
协议
- 一些共通的内容
Acceptance Tests
概念
从名称就可以看出，这是关于验收和测试相关的内容
AUTOSAR Acceptance Tests 是总线级别和应用级别的系统测试，用于验证 AUTOSAR 堆栈在应用软件组件和通信总线方面的行为，Acceptance Tests是在2014年被引入，目的是最大程度的减少测试工作和成本，验收测试规范是使用相应平台的指定接口的系统测试规范。
一些方法
验收测试可用于验证网络内不同 AUTOSAR 堆栈的互操作性。 AUTOSAR 提供的测试用例涵盖 RTE 需求（如从
组件生成、API 的存在、RTE 行为）、基本软件服务、库以及总线行为（如传输行为、总线关闭处理、网络管理）和总线协议（例如传输协议、网络管理、诊断通信）。 AUTOSAR 指定的测试用例数量还在不断增加。此外，
AUTOSAR 提供了一种方法，用户可以使用它来扩展标准测试套件，例如标准集未涵盖的标准功能或用户特定功能。
※这个地方有一个点，需要留意，官网首页从Acceptance Tests选项进入后，页面显示的是：
ACCEPTANCE TESTS FOR CLASSIC PLATFORM，从这个描述上看，这个验收测试是适用与经典框架的，感觉很奇怪，所以这里让我们留一个疑问，后续详细学习验收测试的文档时，再看看是否包含了AP相关的验收测试方法。
