autosar架构详细介绍_Autosar Part1：基础介绍

Autosar的出现主要基于两点因素：

1、 汽车电子系统复杂度和代码量的不断提升，当前整车控制系统的代码量都已达到千万行代码的级别，其复杂度远比高端的航空航天要高，只是安全性比他们要低些。

2、 软件的复习用性差，由于软件依赖于固定的硬件开发，当硬件发生变更时功能往往需要推倒重来，无疑增加重复开发的工作量和周期，这都是血琳琳的投入和成本。

对于此，圈内几位大佬岂能坐视不管，于是相约一起讨论五百回合最后搞了个Autosar出来，并成为最初的九大核心成员（博世、BMW、大陆、福特、戴姆勒、PSA、通用、丰田和大众）。

Autosar在2005年发布了第一个Release版本，其只是搭建了概念雏形，随着不断的发展和完善，Autosar3.x版本已经到了可以投产的水平，在2018年则到了更加完善的4.4版本，随之带来的也是整个规范文档的指数增长，到了4.4版本都已是几万页的规范文档，我相信没有一个人认真看过（当然你也不需要看，第三方工具帮你搞定一切，你的重点是放在应用开发上，而这也是Autosar设计的主要任务），但即便如此Autosar依然是不完善的，因此它仍然在路上。

关于Autusar的概念，在网上或者官网上你可以得到详细权威的说明，但说白了Autosar无非就是一套标准，它规范了我们ECU的整个开发流程，标准了ECU内部数据的交换格式和形式，标准了我们ECU代码如何规范如何书写，其目的就是规范化电子控制器的软件架构，提高软件的复用性和协作开发的灵活性。

Autosar的经典架构图如下，可以看到运行在Microcontroller之上的ECU软件主要有应从层（Application Layer）、RTE层和基础软件层（BSW）三层。

1、应用层：其将软件都划分为一个Atomic Software component（ASWC），包括Application Software Component、Sensor Software Component、Actuator Software Component等。

2、RTE层：Autosar最核心的RTE，其实就是借鉴IT行业的中间件，所谓的中间件就是一种独立的系统软件或服务程序，分布式应用软件借助其在不同的应用之间共享资源，因此RTE的主要任务就是提供基础的通信服务，支持Software Component之间和Software Component到BSW的通信（包括ECU内部的程序调用、ECU外部的总线通信等情况）。

3、基础软件层（BSW）:其由很多组件构成，但主要可以划归为服务层（Service Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer）和复杂设备驱动（Complex Device Drivers）四大部分。

（1）服务层（Service Layer）：为所有应用提供各种服务，如诊断服务、通讯服务和ECU内存管理服务等。

（2）ECU抽象层（ECU Abstraction Layer）：屏蔽芯片上内部资源与板上资源上的差异性，例如Windows就是一个抽象，我们在使用时不需要考虑处理器是英特尔的还是AMD的以及主板、声卡啥的，因为微软帮你搞定一切，同理，ECU抽象层包含了访问微控制器的驱动，其使上层软件与微控制器相分离，从而实现应用在不同硬件的移植

（3）微控制器抽象层（Microcontroller Abstraction Layer）：封装了微控制器层以及外围设备的驱动。将微控制器内外设的访问进行了统一从而屏蔽了芯片上的资源，它会让你感觉不到我们在使用英飞凌还是飞思卡尔的芯片。

（4）复杂设备驱动（Complex Device Drivers）：复杂设备驱动说白了就是将不能标准化的放在一起即构成复杂设备驱动，如发动机的喷油、点火驱动等，因此复杂设备是个框什么也可以往里装。

以上就是传统Autosar的基本架构，当然任何事物的发展必须跟随潮流，随着无人驾驶技术的如火如荼、车联网和云技术的日益发展，Autosar也开始自我调整，推出Autosar Adaptive Platform，实现与IT技术的相互融合。Adaptive Autosar不仅可满足现有需求，还可适用未来需求，它将支持各种自适应的部署、复杂微控制器及与各种非Autosar系统的互动。

Adaptive Autosar与传统Autosar的差异主要体现在如下几个方面：