Autosar的由来

在汽车创新应用不断涌现的推动下，当代汽车电子电气（E/E—Electronic/Electrical）架构已经非常复杂，需要有创新的技术突破才能有效地进行管理，满足日益增长的乘客需求和法律要求。这个需求对汽车制造商及一级供应商（Tier 1）提出了严峻的挑战，他们面临着以下冲突：

● 法律法规执行方面—关键项目包括环境方面和安全要求；

● 舒适性和娱乐功能方面—乘客便利和个性化服务要求；

● 驾驶员辅助和自动驾驶方面—关键项目包括检测和抑制高密度交通环境中的关键动态车辆状态和导航等。

领先的汽车原始设备制造商（Car OEM）和一级供应商逐渐认识到这已经成为行业范围内的挑战，因而需要共同努力应对。他们的共同目标是奠定行业协作创新发展基础，同时打造一个继续鼓励功能创新和质量竞争的平台。为此，建立了一种称为汽车开放系统架构（AUTomotive Open Source ARchitecture，AUTOSAR）的开发合作伙伴关系。

Autosar的目标：AUTomotive Open System ARchitecture

AUTOSAR建立的动机如下：

● 降低与功能范围增长相关的E/E架构的复杂性。

● 提高产品修改、升级和更新的灵活性。

● 提高产品线内和跨产品线的解决方案的可扩展性。

● 提高E/E架构的质量和可靠性。

AUTOSAR建立的最终目标如下。

● 满足未来汽车需求，如可用性和安全性，提高汽车软件升级、更新的灵活性、可维护性。

● 提高集成和传输功能的可扩展性和灵活性。

● 提供更高的“商品离岸”SW和HW组件在产品线上的渗透率。

● 降低产品的封测过程的复杂性、风险性。

● 降低可扩展系统的成本。

Autosar出现之前，每个芯片厂、每款芯片的软硬件不同，造成了软硬件耦合严重、开发效率低下、可重用性差等问题。

Autosar出现，将应用软件和芯片硬件完全隔离。

隔离后芯片厂专注硬件与autosar的适配，开发应用的人专注使用autosar做应用而不用过多关注硬件情况。

Autosar的基础架构

Autosar整体架构图如下所示：

应用软件层[AUTOSAR运行时环境（RTE）以上的层]由映射在标准化汽车电控单元(ECU)上的AUTOSAR软件组件组成。AUTOSAR软件组件和其他软件组件之间的所有交互都是通过AUTOSAR运行时环境（Run Time Environment，RTE）进行的。

实时运行环境（RTE）在系统设计层面（无论硬件如何起草整个系统的逻辑视图），AUTOSAR运行时环境都是ECU间信息交换的通信中心。无论是ECU内部通信通道（如CAN、LIN、FlexRay、MOST等）还是ECU外部通信通道，RTE都可以通过提供相同的接口和服务向AUTOSAR软件组件提供通信抽象。由于运行在RTE之上的软件组件的通信主要取决于具体应用，所以，需要定制RTE—部分由ECU特定生成，部分通过配置生成。因此，所得到的RTE不同，ECU之间也不同。

基础软件层（BSW）是标准化软件层，为AUTOSAR软件组件提供服务，是运行软件功能部件所必需的。它不具有任何功能性的任务本身，并且位于AUTOSAR运行时环境之下。基本软件包含标准化和ECU特定模块。

对基本结构进一步细分，得到：

基础软件层分为4大部分：

硬件抽象层（MCAL）：MCAL是硬件特定的层，可以确保基本软件组件的标准接口。MCAL管理微控制器的各种片上外设，并提供基本软件组件与微控制器无关的值。MCAL通过通知机制，支持将命令、响应和信息分发到不同的进程，MCAL就是将芯片的寄存器操作都封装成一个AutoSAR规定的统一的Api。就是说这套Api是定死的，但是不同厂商的具体实现可能不同（很重要的一点）。

ECU抽象层：ECU抽象提供了任何特定ECU的电气值的软件接口，以便将更高级别的软件与所有底层硬件依赖关系分离。也就是说如果MCAL只封装了芯片，那么ECU抽象层就是将板级所有的硬件都进行了封装。比如我们的控制器上有一个主芯片英飞凌的TC275，还有采样电路，电源电路，CAN电路等等。MCAL就是封装了芯片上有的功能。而ECU抽象层就是将所有的这些都做一个统一的封装。

服务层：这里是更加高级的一层了，服务层里是包含诊断协议等系统服务、NVRAM管理及操作系统（OS）等。OS将使用ECU抽象层的Api，再对上层暴露出服务接口，其实就是嵌入式实时操作系统（RTOS）所作的工作。

复杂驱动：又叫做CDD，主要工作是将AutoSAR未定义的一些功能封装起来，给应用层提供接口来调用这些功能。复杂设备驱动程序允许直接访问硬件，特别是对于资源关键型应用。