关于AUTOSAR的背景和架构信息，这里就不详细展开了。大家可以参看：
AUTOSAR的分层架构
一文了解。今天我们重点讲讲如何快速学习AUTOSAR架构的方法。
如何获取规范文档？
从2003年成立以来，AUTOSAR目前已经更新到AUTOSAR 4.4.0 release版本，后台回复“AUTOSAR”可以获取。当然，你也可以从官网获取最新的规范文档，网址：https://www.autosar.org/standards。
2018年，为了迎合未来汽车智能化、网联化的需求，AUTOSAR联盟推出了一个全新的平台，将AP加入到原有的AUTOSAR平台中，形成自适应AUTOSAR平台（AUTOSAR Adaptive Platform，AP），并于2018年10月迎来了适用于面向量产的首次发布，另外还将原有平台更名为经典AUTOSAR平台（AUTOSAR Classic Platform)和自适应平台AUTOSAR(AUTOSAR Adaptive Platform)，行业内大家习惯叫CP（Classic Platform）和AP（Adaptive Platform），下次有人提到CP还是AP的时候，可不要说没听过。AP目前目前国内了解的人非常少，如果你想做吃螃蟹的人，可以提前自己定位学习。
基本概念
文档命名规则
你的工作内容
有了以上了解，拿到规范文档后，你会发现内容简直太多了，多到不可能有哪位大神能将其完全拜读。那怎么去掌握个中精要呢？
你需要明确你的工作内容在整个产品生命周期的位置。简单介绍下几个流程概念。
| OEM | TIER1 | TIER2 |
| 整车厂 | 一级供应商 | 二级供应商 |
| 奔驰、宝马等（做整车的装配工作） | 大陆、博世等（给OEM供应ECU等） | 英飞凌、NXP等（为TIER1供应零件，比如ECU上的芯片、电路板等） |
圈内的同学比较了解上面提到的几个名词，研究AUTOSAR的工程师在OEM、TIER1和TIER2都会有分布，各自角色不同，研究重点也不同。我们按产品开发流程的顺序大致梳理：
整车厂以EE架构设计和应用层功能设计为主，所以如果你身在OEM中，你只需要着重了解AUTOSAR的方法论和基于方法论的SWC设计即可。这两点说着简单，其实并非我们想象中那么简单。方法论本身就是非常宏观的概念，想要把控产品流程，能为TIER1提供打开需求文档，这本身就要对功能和下游工作十分了解，才能有高质量的输出；
TIER1涉及AUTOSAR的工作分工就比较多了。
如果你是系统工程师，着重研究功能算法的实现，那么你需要对SWC的升级了如指掌，深入理解；如果你是软件架构工程师，对于上游OEM提供的需求文档要有宏观概念，所以也要对方法论和SWC审计十分了解；
如果你是基础软件工程师，需要整个团队协同实现：底层驱动工程师要深入学习芯片的抽象层MCAL应用；BSW协议栈工程师要熟悉OS，ComStack，DiagStack，Memory Stack，WgdStack等协议栈应用细节；复杂驱动工程师，要对AUTOSAR针对CDRV的接口定义方式等深入研究；
如果集成工程师，要十分清楚RTE的运行集成和相关应用配置；
TIER2要深入研究的内容和TIER1的BSW工程师侧重内容相似，主要围绕芯片MCAL和基础软件协议栈展开。
除了以上三类产品开发流程上的角色外，其实还有一个重要角色的存在：工具供应商。了解了AUTOSAR架构和实现过程后，大家可能会看到很多arxml格式的配置文件的制作都离不开工具的支持，以及编译环境、建模工具等，都离不开一直走在超前道路上的工具供应商，如博世的ETAS公司等。
画张简图大致说明一下AUTOSAR的开发流程。
了解了AUTOSAR的开发流程，结合你在整个产品开发流程中所处的位置，就可以精准地定位你的学习重点了，然后就可以选取其中的文档仔细研究。当然，说到这里，其实还有一个非常重要的前提——拥有扎实的C语言功底。
为了迎合未来汽车智能化、网联化的需求，新的平台——自适应AUTOSAR平台，需要拥有c++语言功底。
AUTOSAR开发
概述
汽车电子已成为汽车产品功能拓展与性能提升的重要技术支撑，而软件则是汽车电子的灵魂。对于汽车电子软件行业而言，AUTOSAR规范的应用打破了原有的汽车嵌入式系统软件开发模式，其快速提升软件质量及方便移植的特性降低了参与底层平台开发的门槛，对众多OEM厂商和Tier1而言可谓意义重大。
如今，汽车电子技术在动力总成控制、底盘控制、车身控制以及车载信息娱乐系统等各个部分所占的比重越来越大，在整车成本中的占比也越来越高。随着汽车“电动化、网联化、智能化、共享化”的全面推进，几乎任何一项新技术的诞生都离不开汽车电子的身影。未来，汽车电子技术将成为汽车产品差异性的驱动力。ECU作为汽车电子控制系统的核心，其软件也变得日益复杂，传统的软件架构及开发模式已经不能适应日益复杂的汽车软件需求，此时AUTOSAR就是一个非常理想的解决方案。与传统ECU软件架构相比，AUTOSAR分层架构的高度抽象使得汽车嵌入式系统软、硬件耦合度大大降低。
为助力汽车产业变革，AERI为客户提供完备的AUTOSAR开发技术方案，并且提供完善的技术支持，保证软件质量。
AERI依托现有的量产产品包括新能源车控制器VCU、BMS、MCU，以成熟的技术积淀为客户提供完整可靠的服务。
AERI现有成熟控制器产品
基于AUTOSAR开发的工作内容
AERI掌握AUTOSAR开发全过程的工程服务能力，有基于AUTOSAR的整车控制器产品供货经验和能力。依据多年嵌入式软件开发经验和能力能够迅速配合整车厂建立软硬件平台，进行实车试验。
AUTOSAR分层架构
AUTOSAR开发工具链设置
AERI具有完备的AUTOSAR开发工具链部署及应用能力。AERI可根据客户需求，协助客户进行AUTOSAR开发工具链部署、提供开发工具链使用的技术支持服务等，如下：
AUTOSAR开发实施工具：
AUTOSAR架构开发工具：ETAS-ISOLAR-AB
AUTOSAR应用层开发工具：MATLAB
AUTOSAR MCAL：TRESOS STUDIO（Infineon）
其他开发或标定工具（IDE,仿真器等）
英飞凌MCAL
ETAS ISOLAR-AB
AUTOSAR架构开发
基于多年的嵌入式软件开发经验以及服务国内主流OEM的工程服务经验，同时结合功能安全ISO26262对嵌入式软件的要求，AERI可根据需求为客户提供基于AUTOSAR的符合功能安全的软件开发服务。
a、基于英飞凌AURIX架构微控系统抽象层MCAL
基于英飞凌AURIX架构芯片，AERI具有多年的量产开发经验，可根据客户需求使用英飞凌MCAL工具进行定制化开发。
MCAL是AUTOSAR架构微控系统抽象层，与芯片直接相关。AERI根据不同客户的需求进行白盒或者黑盒开发，并提供配套的说明文件和工程服务培训。确保客户能够在最短的时间内掌握AUTOSAR MCAL相关的开发能力。
b、ETAS AUTOSAR开发
ETAS AUTOSAR根据功能开发需求和CAN总线通信拓扑，确定CAN通信矩阵。CAN矩阵需包括各控制器之间的信号传递方向，信号名称，信号描述、信号长度和报文ID等信息。根据高内聚低耦合的设计原则，充分利用AUTOSAR分层架构模块化复用的优势，需要对控制器内部功能进行软件功能组件（SWC）的划分。最后根据目标ECU软件功能对软件组件进行详细设计。
AERI可基于客户CAN通信拓扑，进行AUTOSAR架构开发。软件组件基于Matlab/Simulink完成软件组件的开发，实现内部逻辑算法，完成AUTOSAR软件组件元素的设计及其与 Simulink模型元素的映射。生成符合AUTOSAR规范的代码和描述文件，最终导入ISOLAR-A，完成RTE配置。以客户需求为导向，定制化开发AUTOSAR架构软件，并根据需求提供白盒或者黑盒的代码工程。
c、AUTOSAR代码集成
AERI可基于上述AUTOSAR开发相关的开发工具输出物进行代码集成，集成开发环境可选择HIGHTEC或者TASKING，为保证集成代码可用，AERI可根据需求同客户一起进行HIL,台架或者实车试验。一切以客户需求为导向，以解决客户实际问题为目的，用心服务客户。
HIGHTEC IDE代码集成
