什么是AUTOSAR（二）——AUTOSAR软件架构

AUTOSAR规范主要由四大部分组成：Software Architecture，Methodology&Template，Conformance Testing，Application Interfaces。其中最主要的部分就是Software Architecture。因此，我们将在这章节探讨AUTOSAR软件架构。

在前一篇文章《什么是AUTOSAR（一）——AUTOSAR概述》中介绍了，在AUTOSAR软件架构中，汽车嵌入式系统软件自上而下分别为应用软件层（Application Software Layer，ASW）、运行时环境（Runtime Environment，RTE）、基础软件层（Basic Software Layer，BSW）和微控制器（Microcontroller）。为保证上层与下层的无关性，在通常情况下，每一层只能使用下一层所提供的接口，并向上一层提供相应的接口。目前AUTOSAR规范定义最为详细的部分就是基础软件层。而且判断某个软件架构是否遵守AUTOSAR规范的主要依据就在于基础软件层。因此，我们着重介绍基础软件层相关的内容。这里，我们需要注意的是，以下的介绍说明都是基于AUTOSAR 4.0规范。

基础软件层（Basic Software Layer，BSW）又可分为四层，即服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer，MCAL）和复杂驱动（Complex Drivers）。

服务层（Service Layer）

服务层（Service Layer）又由一系列基础软件组件构成，包括系统服务（System Services）、存储器服务（Memory Services）、通信服务（Communication Services）等。它们主要用于提供基础软件服务，包括标准化的系统功能和功能接口。

系统服务（System Services）又包括Csm(Crypto Service Manager)，SchM（BSW Scheduler Module），FiM（Function Inhibition Manager），Dem（Diagnostic Event Manager），Det（Development Error Tracer）,DLT(Diagnostic Log and Trace)，ComM（Communication Manager），BswM（BSW Module Manager），EcuM（ECU State Manager），StbM（Synchronized Time-base Manager），WdgM（Watchdog Manager），AUTOSAR OS（操作系统）。

系统服务层如下图所示：

这一层级的软件基本都是由第三方软件公司提供，也是目前最为标准化的软件模块。现在我们用其中的WdgM模块举例说明。打开AUTOSAR_SWS_WatchdogManager.pdf，你就能看到如下图所示的WdgM模块与其他模块的交互、关系。

通过这张图，我们就能清楚的知道，WdgM模块和其他模块的交互关系和自身模块中的各个文件的关系。

存储器服务（Memory Services）主要由三部分组成：NvM（NVRAM Manager），Fee（Flash EEPROM Emulation），MemIf（Memory Abstraction Interface）。

通信服务（Communication Services）主要由Com（Communication），Dcm（Diagnostic Communication Manager），Dbg（Debugging），SM（State Manager，如CanSM），NM（Network Management，如CanNm），PduR（PDU Router），TP（Transport Layer），IpduM（IPDU Multiplexer），Xcp，SoAd（Socket Adaptor）等软件模块组成。这些模块几乎涵盖了汽车所有的通信标准，因此也是标准化非常高的软件模块。这一层次的软件模块大部分由第三方公司提供，也有不少的软件模块是OEM或Tier 1开发的。如Dcm软件模块，主要参考了UDS ISO-14229标准，也是汽车通用的通信协议，实力比较深厚的公司都会自己开发。

从上面的介绍，我们能了解到，除了操作系统外，服务层的软件模块都是与ECU平台无关的。

ECU抽象层（ECU Abstraction Layer）

ECU抽象层（ECU Abstraction Layer）包括板载设备抽象（Onboard Devices Abstraction）、存储器硬件抽象（Memory Hardware Abstraction）、通信硬件抽象（Communication Hardware Abstraction）和I/O硬件抽象（Input/Output Hardware Abstraction）。ECU抽象层将ECU结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器或者I/O的访问，从而不需要考虑这些资源是由微控制器片内提供的，还是由微控制器片外设备提供的。ECU抽象层正如名字一样，和ECU硬件息息相关，但和MCU无关。这种无关性正是由微控制器抽象层来实现的。其中的IO硬件抽象层和具体项目息息相关，其主要负责除了Watchdog硬件，通信硬件的所有硬件的抽象，如电机驱动，LED驱动等模块的抽象。

微控制器抽象层（Microcontroller Abstraction Layer，MCAL），是对MCU硬件的抽象，是实现不同硬件接口统一化的特殊层。此层软件模块主要由各个驱动程序构成。其中有我们常见的SPI驱动程序，CAN驱动程序，LIN驱动程序，MCU驱动程序等。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。微控制器抽象层分为微控制器驱动（Microcontroller Drivers）、存储器驱动（Memory Drivers）、通信驱动（Communication Drivers）以及I/O驱动（I/O Drivers）。这些驱动程序基本都是由MCU芯片厂商提供的。

复杂驱动层（Complex Drivers）

除此之外，AUTOSAR还有一个复杂驱动（Complex Drivers）。这个复杂驱动模块基本由主机厂或Tier1设计开发。由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以在AUTOSAR规范中这部分没有被标准化。而随着汽车电子零部件越来越多的传感器和执行器，复杂驱动模块，真的是越来越复杂，急需将一些通用的传感器、执行器标准化。

总的来说，AUTOSAR将基础软件分为了服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer，MCAL）和复杂驱动（Complex Drivers）。最后总结成如下图所示。

文章转载自公众号：软件赋能汽车