1 AUTOSAR架构概览

之前文章《 老板说项目要上AUTOSAR，我慌得一批 》讲过，在新世纪，汽车产业蓬勃发展，欧洲大陆的车企们，瞄准了这是一块大蛋糕，于是在2002年成立了一个联盟，搞了个叫AUTOSAR的标准，以期一统天下。次年，他们就开搞了，开始制作这个AUTOSAR的草图。

话说，这是要定义一套标准，一个统一的架构，那这架构有什么内容呢？

一位工程师，将其想法用草图表达了出来

并解释说，这个架构大概分三层，然后看看在座的各位。会议上的其他人面面相觑，都想说，这么简陋，能统一江湖？这位工程师也不理会，不慌不忙，继续画下去：

工程师解释说，关键在这个BSW，还可以分个三四层：

还有，Application就是应用，跟其他架构写的应用类似，就不用多说了。而这个Runtime Environment(RTE)呢？

RTE是给应用提供通信服务的，Applcation通过它可以访问BSW的功能，做统一标准的接口，从而实现非常方便的可移植性了，各模块也独立了。

工程师言简意赅，没有做更多的解释，然后就想细化这个架构图：

然后，他微微笑了下：这应该清晰了吧，横着看竖着看都很好理解。比如说这个Memory Service，就可以让Application通过RTE调用，做了很多方法application访问的接口，它是通过调用Memory Hardware Abstraction来访问Memory Drivers的。

通过这三层关系就实现市面上大部分功能需求了。但是，总会有这几层实现不了的功能吧，怎么办？Complex Drivers就可以提供给用户自己定义啦，可以做一些复杂的驱动。

总的来说，基础软件（BSW）可以按以下类型分：

等等，还有个东西差点漏了—— Library

2 AUTOSAR的基础软件

基础软件，即BSW。工程师打算详细讲解下这个BSW，因为它非常重要。

话说，座上的与会大咖听这位工程师讲的津津有味，越来越觉得AUTOSAR一统江湖指日可待，并期望能讨论更多细节。

工程师也准备好了设计原稿，对这些细节娓娓道来。 MCAL 从底下往上讲，第一个Microcontroler Abstraction Layer（即MCAL），其有以下模块：

举例说明， SPIHandlerDriver 是允许多业务并发访问，为了抽象出SPI的所有功能，这些已经用为SPI功能的IO是不能做他用的。

CDD

CDD即Complex Driver，上文也提到了，它是用来实现BSW里面非标准化功能的。也就是说，标准化定义以外的功能可以通过CDD来实现，如UART，MCAL是没有定义UART的标准化的。

（这个话题，后续再详细讲解。）

I/O Hardware Abstraction

I/O Hardware Abstraction是一组模块，从外围I/O设备（片上或板上）的位置和ECU硬件布局（例如µC引脚连接和信号电平反转）中抽象出来。I/O硬件抽象不会从传感器/执行器中抽象出来！ 可以通过I / O信号接口访问不同的I/ O设备。

Communication Hardware Abstraction

Communication Hardware Abstraction 是一组模块，从通信控制器的位置和ECU硬件布局中抽象出来。对于所有通信系统，都需要特定的通信硬件抽象（例如，对于LIN，CAN，FlexRay）。

例如，ECU具有带2个内部CAN通道的微控制器和带4个CAN控制器的附加板载ASIC。CAN-ASIC通过SPI连接到微控制器。

可通过总线特定的接口（例如CAN接口）访问通信驱动程序。

Memory Hardware Abstraction

Memory Hardware Abstraction 是一组模块，从外围存储设备（片上或板载）的位置和ECU硬件布局中抽象出来。

例如，可以通过相同的机制访问片上EEPROM和外部EEPROM器件。可以通过特定于存储器的抽象/仿真模块（例如EEPROM抽象）访问存储器驱动程序。通过在闪存硬件单元顶部模拟EEPROM抽象，可以通过存储器抽象接口对两种类型的硬件进行通用访问。

Onboard Device Abstraction

Onboard Device Abstraction 包含用于ECU板载设备的驱动程序，不能将其视为传感器或执行器，例如内部或外部看门狗。这些驱动程序通过µC抽象层访问ECU车载设备。

Crypto Hardware Abstraction

Crypto Hardware Abstraction 是从加密基元（内部或外部硬件或基于软件）的位置抽象的一组模块。 例如， AES原语在SHE中实现或作为软件库提供。

Crypto Services

Crypto Services包含两个模块：

Communication Services Communication Services是一组用于车辆网络通信（CAN，LIN，FlexRay和以太网）的模块。它们通过通信硬件抽象与通信驱动程序接口。

讲到这里，会上的其他人听着听着有些懵逼，越讲越复杂了，工程师停了下，说，通信服务这部分，涉及到CAN、LIN甚至TCP/IP等，内容很多也很重要，后续我们另外召开会议讨论吧。

Memory Services

Memory Services由一个模块NVRAM管理器组成。它负责非易失性数据的管理（从不同的内存驱动器读取/写入）。

它以统一的方式向应用程序提供非易失性数据。内存位置和属性的摘要。提供非易失性数据管理机制，例如保存，加载，校验和 保护和验证，可靠的存储等。

System Services

System Services是一组模块和功能，可由所有层的模块使用。示例包括实时操作系统（包括计时器服务）和错误管理器。

其中一些服务是：

它提供基本的申请服务以及基本软件模块。

有专门的模块可用于AUTOSAR中错误处理的不同方面， 例如：

3 AUTOSAR的多核处理

此刻，有人提问，市面上μC更新换代非常快，性能也不断提升，甚至有多核处理器，这个架构如何应对多核处理？ 工程师想了想，show出了下图

并结合下图给出解释：

4 AUTOSAR的Safety功能

那么，安全功能如何？工程师都有考虑和准备：

AUTOSAR提供了一种灵活的方法来支持与安全相关的ECU，可以使用两种方法：

注意： 分区基于OSApplications， O S -Application的TRUSTED属性与ASIL / non-ASIL不相关。

使用不同BSW分区的示例， 看门狗堆栈放置在自己的分区中

经过以上的解答和分解，会议上的各位都点头表示同意，但是还是有人提了个问题，我们定义这么多功能模块，不一定所有产品都会用到，如何裁剪？

5 AUTOSAR的ICC

好了，我们接下来讨论ICC （Implementation Conformance Class）：

下图显示了基本软件模块到AUTOSAR层的映射

我们称这个为ICC3，那ICC2是怎样的？

这个便是ICC2了。

到目前为止，本文档中显示的集群是该项目定义的集群。

当前，AUTOSAR并未将ICC2级别上的群集限制为专用群集，因为许多不同的约束和优化标准可能会导致不同的ICC2群集。 可能存在不同的AUTOSAR ICC2集群，可以根据要定义的ICC2遵从性方法声明符合性。

ICC1呢？

在符合ICC1的基本软件中，不需要模块或集群。未指定此专有基本软件的内部结构。

纳尼？又回到原来的三层结构？

兼容AUTOSAR（ICC1-3）的基本软件（包括RTE）必须具有ICC3模块规范指定的外部性能。 例如，针对以下行为：

另外，关于ICC3中的系统描述，ICC1 / 2配置应兼容。

也是说，这个架构能屈能伸，只需遵循相关标准要求即可，非常灵活。

5 后话

会上 响起了经久不绝的 掌声， 结构 做到这份上， 也是非常 详尽了。 但是 ，问题还是有的， 架构中定义了那么多 模块，模块之间的接口是如何的？

工程师，想了想，面对座上的期盼的目光，慢悠悠地说，我们下次会议再讨论吧……（因为要下班了，万恶资本主义的欧洲，他们的工程师，不！加！班！！）