莫慌，淡定，先来看看AUTOSAR是个什么鬼……
▍AUTOSAR是什么
AUTOSAR(AUTomotive Open System ARchitecture)，中文是“汽车开放系统架构”，是一家致力于制定汽车电子软件标准的联盟。他们制定了一套专门用于汽车的开放性的框架和行业标准，它将用作管理将来的应用程序和标准软件模块中功能的基本基础结构。
▍AUTOSAR的历史故事
自从德国人卡尔·佛里特立奇·本茨发明汽车后，在后来的岁月里，汽车不断地改进不断地演化，车内的系统和零部件越来越复杂和繁多。时至今日，汽车行业，变成了一个蓬勃发展的行业，同时也是一个竞争非常激烈的行业，以致各车企各相关供应链都在争分夺秒地“攻城略地”。
同时，这个汽车行业在竞争中，也迎来各种各样的挑战。
作为汽车发源地的欧洲大地，准确地讲，德国，于2002年8月，有一群车企大佬（宝马、博世、大陆集团、戴姆勒克莱斯勒和大众汽车公司，后来西门子威迪欧也加入了）就共同的挑战和目标进行了讨论，成立一个联盟，制定标准，准备一统江湖。
很快，在2003年，他们就将AUTOSAR kickoff了，同时也制定了AUTOSAR Classic Platform的Draft版。
在后来几年，这个联盟吸引了无数车企和相关设备商加入，规模不断地发展壮大，所制定的标准框架也日益完善。
逐渐地，后来发现Classic Platform只覆盖了低端的设备，是基于微处理器之上的，上面更高端的系统或服务（有哪些？想想手机业务的发展情况），没有覆盖到。他们的野心是大大的，目标是宏伟的，到了2017年，一个Adaptive Platform就这样诞生了。
▍AUTOSAR的标准化
AUTOSAR到底做了什么？
AUTOSAR通过以下内容作了标准化：
软件接口
交换格式
方法论
同时具备以下优点或特点：
硬件和软件彼此广泛独立。
可以通过水平层将开发分离（通过抽象），从而减少开发时间和成本。
重复使用软件可提高质量和效率
将汽车系统的基础软件标准化为一个跨OEM的“标准栈”
集成不同供应商生产的功能模块，适用于不同的车辆及不同的车型
从软件中把硬件抽象出来，对于不同硬件平台具有更大的灵活性
通过对BSW的标准化提高了代码质量
竞争力只体现于对OEM的特殊功能要求的实现
重用性可以覆盖整个网络节点，甚至跨不同OEM
▍AUTOSAR带来了什么好处
对于OEM车厂
在供应商之间建立分布式开发
通过增加设计灵活性来竞争创新功能
简化软件和系统集成
降低总体软件开发成本
对于供应商
启用更有效的变体处理
跨OEM复用软件模块
提高应用程序开发效率
发明新的商业模式
对于工具供应商
与开发流程交互
将工具嵌入整个工具环境
对于新入市场者
通过标准化接口启用新的业务模型
轻松了解汽车软件的开发方式
▍AUTOSAR的合作伙伴
在上面的“历史故事”中讲到，AUTOSAR是一个强大的联盟。发展到现在，它现在拥有284 个合作伙伴！
其中有9个核心成员：
还有其他类型的合作伙伴：
这些合作伙伴遍布世界各地
这个联盟还专门设立了一个机构
这个机构就像一个项目团队，有各种分工
| Group | Type | Initiated By | Main Tasks | Coaching | Contect Person |
| Lead WG | Permanent | PL Team | - Technical supervision of WGs and concept groups - Harmonization of technical content - Assignment of concepts to WGs | PL Coach | WG Speaker |
| WG | Permanent | PL Team | - Expert statements - Responsibility for documents and code development - Assessment of concepts | PL Coach | WG Speaker |
| Subgroup | Permanent | WG | WG substructure for a dedicated branch of WG content | - | Subgroup Speaker |
| Control Board | Permanent | PL Team | Controlling task within AUTOSAR processes (e.g. CM, QM, SDE or RM) such as CCB, CF-CCB and OSS-CB | PL Team | CM, QM or RM |
| Concept Group | On demand (project-based) | CP/SP/PP/DP | Creation and processing of a concept or a set of concepts according to concept process Responsibility for concept validation | - | Concept Owner(s) |
| Task Force | On demand (project-based) | WG or PL Team | Dedicated task with defined due date | - | TF Speaker |
| UG | On demand (project-based) | PP/DP/AP | Creation of documents or implementations based on existing releases | PL or SC Team | UG Speaker |
（上面都是英文，我没翻译，感兴趣的同学，将就点看，另外里面有几个缩写，可以对着图上看，例如：WG就是Working Group，PL即Project Leader等）
▍AUTOSAR是如何交付的
从这个图可以看出，这是从一个叫“Foundation”出发的，扩展出Classic Platform（简称CP）和Adaptive Platform（简称AP）两大平台，继而定义各种接口和测试等。
▍关于Foundation，CP和AP
Foundation
Foundation目的是增强AUTOSAR平台之间的互操作性。
其基础包含在AUTOSAR平台之间共享的通用要求和技术规范（例如协议）。
Foundation确保了不同AUTOSAR标准的兼容性，因此包含了所有常见工件，例如
提供了描述AUTOSAR体系结构及其所有接口的方法
定义交换格式和描述模板（例如清单）以启用
无缝集成完整的车辆E / E架构，
µC和µP软件堆栈的自动配置，以及
无缝集成应用软件
支持确保系统安全性的手段
提供用于记录标准的模板
AUTOSAR Classic平台体系结构在运行在微控制器上的三个软件层之间的最高抽象层上有所区别：应用程序（Application），运行时环境（RTE）和基本软件（BSW）。
应用软件层主要与硬件无关。
软件组件之间的通信以及通过RTE访问BSW。
RTE代表应用程序的完整接口。
BSW分为三个主要层和复杂的驱动程序：
服务，ECU（电子控制单元）抽象和微控制器抽象。
服务进一步分为代表系统，内存和通信服务基础结构的功能组。
AUTOSAR Adaptive平台为 Adaptive Applications（ARA）实现AUTOSAR Runtime 。提供两种类型的接口：Service和API。该平台由按服务和Adaptive AUTOSAR基础分组的功能集群组成。
集成Adaptive平台的功能
定义需求规范的聚类
从应用程序和网络角度描述软件平台的行为
不限制实施Adaptive平台的体系结构的最终软件设计。
每台（虚拟）计算机的AUTOSAR Adaptive平台基础中的功能集群必须至少具有一个实例，而服务可能会在车载网络中分布。
与AUTOSAR Classic Platform相比，用于Adaptive Platform的AUTOSAR Runtime Environment在运行时动态链接服务和客户端。
▍基于AUTOSAR开发
上了AUTOSAR后，从应用角度看，似乎和平台无关，像是无缝结合
不同ECU通过底层BUS通信
应用和平台无关
无缝结合
那么，基于AUTOSAR是怎么做到这些效果的，其标准化（软件接口、交换格式、方法论）到底做了什么？里面有神秘的方法么？
