今天从整体阐述下AutoSar的架构。
谈及AutoSar架构前，要稍微了解下AutoSar的背景知识。
汽车上控制器迅速地发展，逐渐出现同一供应商不同代别的产品无法相互移植和复用的现象，更别提不同的供应商的兼容性了。不同代别控制器无法复用，导致软件开发成本居高不下。另外，欧洲各OEM的软件和系统能力比较强，ECU供应商主要负责软件底层和硬件服务，不同供应商平台的不兼容性，导致OEM十分头痛，问题迟迟无法得到解决。
2003年，以宝马为首的几家OEM与Tier1成立AUTOSAR联盟，希望为汽车工业开发一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案，也就是我们说的AUTOSAR（AUTomotive Open System ARchitecture），旨在摆脱软件对硬件和系统的依赖，降低OEM长期开发成本。
概括起来，传统软件开发被AutoSar取代，主要有这么几个原因：电子系统的复杂性不断增长；软件代码量急速上升；生命周期差别:整车的生命周期往往长于ECU的生命周期；嵌入式系统不支持硬件抽象；有限的软件模块化；兼容性差，当硬件更换后，软件要推倒重写；
那么AutoSar的应运而生，主要追求的目标就是：适用于整个产品生命周期；从软件中把硬件抽象出来，对于不同硬件平台具有更大的灵活性；更多的配置而非实现；标准化AUTOSAR的代码配置/建模工具；通过对BSW的标准化提高了代码质量；竞争力只体现于对OEM的特殊功能要求的实现；在整个汽车生命周期中，软件可以不断更新或升级；兼容性将覆盖整个网络节点，甚至适用不同OEM。
AutoSar的思想是将ECU的整个系统分层处理，将系统功能和硬件依赖性剥离开，通过AutoSar联系起来。AutoSar提供标准的应用程序(SWC)接口，运行环境(RTE)，基础软件(BSW) ，总线通信和开发流程及数据交换格式。
上面提到的分层结构，从物理层意义看，主要是Application、RTE和BSW三层。
应用层将软件划分成一个原子软件组件ASWC(Atomic Software component),包括Application Software Component，Sensor Software Component和Actuator Software Component等。不同ASWC之间，以及ASWC与BSW之间都是通过VFB(Virtual Functional Bus)通信。
RTE提供基础的通信服务，支持Software Component之间和Software Component到BSW的通信（包括ECU内部的程序调用、ECU外部的总线通信等情况）。RTE使应用层的软件架构完全脱离于具体的单个ECU和BSW。
BSW层主要包括任务调度，系统服务，诊断服务、存储服务、通讯协议栈，微控制器抽象层、外部硬件抽象层和复杂驱动。这里偷个懒，截取几张图放这里，大家overview地了解一下，后续有机会针对每一项详细介绍的。
今天先介绍这么多，大概感性地了解下，有问题后台留言沟通。
文章首发于微信公众号“汽车控制与人工智能”，欢迎关注。