AUTOSAR架构

AUTOSAR定义：

        AUTOSAR是AUTOmotive Open System Architecture（汽车开放系统架构）的首字母缩写，由汽车制造商，供应商以及工具开发商联合开发。致力于为汽车工业开发一个开放的、标准化的软件架构。

        AUTOSAR这个架构有利于车辆电子系统软件的交换与更新，并为高效管理愈来愈复杂的车辆电子、软件系统提供了一个基础。此外，AUTOSAR在确保产品及服务质量的同时，提高了成本效率。

体系结构——软件层的概述（Architecture – Overview of Software Layers）

1、AUTOSAR体系结构在最高抽象级别上分为三个软件层：应用程序层、运行时环境层和在微控制器上运行的基本软件层。

AUTOSAR三层结构

2、AUTOSAR基础软件（BSW）进一步划分为服务层、ECU抽象层、微控制器抽象层和复杂驱动层。

BSW进一步划分

3、基本的软件层进一步划分为功能组。有系统服务、存储器服务和通信服务。

BSW进一步划分为功能组

4、微控制器抽象层（Microcontroller Abstraction Layer）

微控制器抽象层在BSW的最底层，它包含内部驱动,软件模块与直接访问μC内部和外围设备。

微控制器抽象层

ECU抽象层（ECU Abstraction Layer）

ECU抽象层对接微控制器抽象层的驱动程序。它还包含外部设备的驱动程序。

它提供一个API接口，访问外设和uC内部或外部的设备连接到μC(port pins, type of interface)。

服务层（Services Layer）

服务层是基础软件的最高层，同时与应用程序也有关联；虽然对I/O信号的访问由ECU抽象层覆盖，但服务层提供：操作系统的功能、车辆网络通信管理服务、存储器服务(NVRAM管理)、诊断服务(包括UDS通信、错误存储和故障处理)、ECU状态管理，模式管理、逻辑和时间程序流监控(Wdg管理器)、密码服务(密码服务管理)

复杂驱动层（Complex Drivers）

复杂驱动层从硬件跨越到RTE。提供集成特殊用途的功能，例如设备驱动程序：在AUTOSAR中未规定的、具有非常高的时间限制或用于迁移等目的。

RTE层（AUTOSAR Runtime Environment (RTE)）

RTE是为应用软件(AUTOSAR软件组件和/或AUTOSAR传感器/执行器组件)提供通信服务的层。

在RTE之上，软件架构风格从“分层”转变为“组件风格”。

AUTOSAR软件组件通过RTE与其他组件(内部和/或内部ECU)或服务进行通信。

服务类型介绍（Introduction to types of services）

基本软件可细分为以下几类服务：

（1）系统：提供标准化的规定（针对操作系统、定时器以及错误存储器）、ECU特定的服务（ECU状态管理、看门狗管理）和库函数；

（2）内存：对内部和外部的内存（非易失性存储器）的访问入口进行标准化；

（3）通信：对汽车网络系统、ECU通信系统以及ECU内部软件的访问入口进行标准化；

（4）输入/输出：对传感器、执行器以及ECU外设的访问入口进行标准化；

基本软件模块类型介绍（Introduction to Basic Software Module Types）

基础软件层模块按照类型可以分为驱动模块、接口模块、处理模块以及管理器。

1、驱动模块

驱动模块包含了控制和使用内部或者外部器件的功能，分为内部驱动和外部驱动。

（1）内部驱动

内部器件位于微控制器（单片机）的内部，例如内部EEPROM、内部CAN控制器、内部ADC模块等。

内部驱动程序就是针对单片机内部器件资源的驱动程序，这部分驱动程序属于微控制器抽象层（MCAL）。

（2）外部驱动

外部器件是指单片机外部的ECU硬件，比如外部EEPROM、外部看门狗、外部Flash等。外部驱动程序就是针对单片机外部硬件资源的驱动程序，属于ECU抽象层。外部驱动程序需要通过微控制器抽象层（MCAL）驱动程序来实现对外部器件的驱动。这种方法下AUTOSAR也支持嵌入在系统基础芯片（SBCs）中的组件，像收发器以及看门狗等。例如，使用SPI通信接口的外部EEPROM驱动程序是通过SPI总线处理程序来驱动外部EEPROM的。但是有一种例外，对于和内存映射相关的外部器件（如外部Flash存储器），其驱动程序是可以直接对微控制器进行存取访问的，所以这部分驱动程序属于微控制器抽象层（MCAL）。

2、接口模块

接口模块包含了对其次级模块进行抽象的功能，比如对一个特定功能的硬件进行抽象。它提供一个通用的接口函数（API）来访问一种特定的器件类型，且与该类型器件的数目无关，同时也与器件的具体硬件实现无关。

接口模块不会改变数据的内容。一般来说，接口属于ECU抽象层。例如，CAN通信系统的接口模块提供一个通用的接口函数来访问CAN通信网络，并且与ECU上CAN控制器的数目以及硬件实现无关。

3、处理模块

处理模块是一个专用的接口，它控制一个或多个客户端对一个或多个驱动程序进行并行、多重以及异步地访问。也就是说，它起着缓冲、队列、仲裁以及多路复用的功能。同时，处理程序也不会改变数据本身的内容。处理模块通常会并入驱动程序或是接口模块中（如SPIHandlerDriver、ADC Driver等）。

4、管理器

管理器为多重的客户端提供特定的服务。当单纯的处理程序不能满足对多重的客户端进行抽象时，就需要用到管理器来进行处理。除了处理功能外，管理器还可以对数据内容进行评估、改变或是适应数据内容。

一般而言，管理器属于服务层。例如，非易失性随机存储器（NVRAM）的管理器负责对内部或是外部存储设备进行并行的访问，如Flash、EEPROM存储器等。同时，它也可以完成分布式并且可靠的数据存储、数据校验以及默认值的规定等。

软件层内容（Content of Software Layers）

1、微控制器抽象层（Microcontroller Abstraction Layer）

μC抽象层包括以下模块组:

（1）通信驱动模块组（Communication Drivers）

板载ECU(如SPI)和车辆通信(如CAN)的驱动程序。osi层:数据链路层的一部分。

（2）I/O 驱动模块组（I/O Drivers）

模拟和数字I/O驱动程序(如ADC、PWM、DIO)

（3）存储器驱动模块组（Memory Drivers）

用于片上存储器设备(例如内部Flash，内部EEPROM)和内存映射外部存储器设备(例如外部Flash)的驱动程序。

（4）微控制器驱动模块组（Microcontroller Drivers）

内部外设（例如：看门狗，General Purpose Timer）驱动程序。直接uC访问的函数（例如内核测试）。

驱动模块组 模块划分

2、微控制器抽象层：SPIHandlerDriver

SPIHandlerDriver程序允许多个客户机并发访问一个或多个SPI总线。

2、复杂驱动层（Complex Drivers）

复杂驱动（CCD）层跨越于微控制器硬件层和RTE之间，其主要任务是整合具有特殊目的且不能用MCAL进行配置的非标准功能模块，将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求。复杂驱动程序跟单片机和ECU硬件紧密相关。其上层程序接口是根据AUTOSAR指定并且实施的；其下层程序接口受标准接口程序的限制。复杂驱动可以使用特定的中断或是复杂的微控制器外设（如PCP/TPU）来直接访问微控制器，从而实现对复杂传感器的评估和执行器的控制，比如喷油控制，电磁阀控制，增量位置检测等。

复杂驱动层 复杂驱动层举例说明

抽象层

1、ECU抽象：I/O硬件抽象（ECU Abstraction: I/O Hardware Abstraction）

I/O硬件抽象是一组模块从外设I/O设备(片上或板载)和ECU硬件布局(例如µC pin脚连接和信号电平倒置)抽象出来。I/O硬件抽象不会从传感器/执行器中抽象出来!

不同的I/O设备可以通过I/O信号接口访问。

I/O硬件抽象 举例说明

2、ECU Abstraction: Communication Hardware Abstraction

通信硬件抽象是一组模块从通信控制器和ECU硬件布局抽象出来。对于所有的通信系统都需要一个特定的通信硬件抽象 (e.g. for LIN, CAN, FlexRay)。

例如：一个ECU微控制器有2个内部CAN通道和一个附加的板载带有4个CAN控制器的ASIC芯片，CAN-ASIC通过SPI方式连接微控制器。

通信驱动被访问通过总线特定的接口（CAN Interface）。

3、Scope: Memory Hardware Abstraction

存储器硬件抽象是一组模块从外设存储设备（芯片或板载）和ECU硬件布局抽象出来。

例如：芯片上的EEPROM和外部的EEPROM设备都可以通过相同的机制访问。

存储设备被访问通过存储器特定的抽象/仿真模块（例如EEPROM 抽象）。

4、Onboard Device Abstraction

板载设备抽象包含ECU板载设备驱动，例如内部或外部看门狗，这些驱动访问ECU板载设备通过µC抽象层。

服务层（通信服务：Communication Services）

1、Communication Services – General

通信服务是一组车辆网络通信模块（CAN，LIN and FlexRay），他们通过通信硬件抽象对接通信驱动。

一般通信栈属性：

信号网关（Gateway）是AUTOSAR COM的一部分，用于路由信号；

基于网关（Gateway）PDU是PDU路由器（router）的一部分；

（1）Communication Stack – CAN

CAN通信服务是一组带有CAN通信系统的车辆网络通信。为CAN网络提供统一的接口。应用程序中隐藏协议和消息属性。

CAN通信服务的实施与单片机和ECU硬件无关，但部分依赖于CAN通信本身；

AUTOSAR COM、Generic NM (Network Management)Interface 和 Diagnostic Communication Manager对于所有车辆网络系统都是相同的，并且每个ECU作为一个实例存在。

Generic NM Interface 只包含一个调度程序，不包含其他功能，对于网关ECUs，它还可以包括NM协调器功能，允许同步多个不同的网络(相同或不同类型的)同步唤醒它们或关闭他们。

CAN NM是针对特定CAN网络的，并且通过车辆CAN网络系统进行具体实现。可以通过底层网络适配器(CAN NM)与CAN Generic NM interfaces 连接。

通信系统特定的CAN状态管理器能够管控与通信系统相关的启动和关闭功能。此外，它还可以通过控制COM的不同选项来实现发送PDU以及监控信号超时的功能；

（2）Communication Stack Extension – TTCAN （略）

（3）Communication Stack Extension – J1939

如下图所示，显示了J1939通信所包含的所有模块。

J1939通信服务是对普通CAN通信协议栈的拓展，主要应用在商用车上。其主要任务是提供J1939通信所需的协议服务，同时从应用程序中隐藏不需要的协议和消息属性。

J1939通信服务具有以下属性：

J1939通信服务的实施与单片机和ECU硬件无关，它是基于CAN通信的；

AUTOSAR COM、通用网络管理接口（Generic NM Interface）以及诊断通信管理器（Diagnostic Com.Manager）对所有的车辆网络系统都是通用的，并且作为每个ECU的一个实例而存在；

支持在配置阶段未知的动态帧标识符；

J1939网络管理器管控每一个ECU的特定地址分配，但它不支持休眠/唤醒处理以及其他相关的概念，如局部网络等；

提供J1939诊断和请求处理；

（4）Communication Stack – LIN (LIN Master)

如下图所示，显示了LIN通信所涉及的所有模块。

LIN通信服务是一组车辆LIN通信系统的模块。其主要任务是为LIN通信网络提供一套统一的接口，同时从应用程序中隐藏协议内容和消息属性。

LIN（主）通信服务具有以下属性：

与LIN 2.1兼容的通信协议栈：调度表管理器，用于传输LIN帧和处理切换到其他调度表的请求；传输协议，用于诊断；一个唤醒和休眠接口；

底层LIN驱动：实现LIN协议并对特定硬件进行调整；支持简单的UART和基于LIN硬件的复杂框架；

注意：将LIN集成到AUTOSAR：

Lin Interface 控制唤醒/休眠 API ，并且允许从节点保持总线 awake (分散管理的方法 decentralized approach)；

通信系统特定LIN State Manager 依靠 Start-up 和 Shutdown 特性处理通信。此外，它还控制来自通信管理器的通信模式请求。LIN state manager 还通过接口COM 控制 I-PDU 组。

当发送LIN帧时，LIN接口需要数据的时刻（即在发送LIN帧之前）从PDU路由器请求帧(I-PDU)的数据。

（5）Communication Services – LIN Slave

LIN Slave 通常是 “智能” 执行器，并且被视为黑盒。由于它们提供的硬件能力和资源非常少，并不打算将AUTOSAR软件组件转移到这样的系统上。因此，没有必要在LIN Slave 上安装AUTOSAR系统。

LIN Slave 可以连接为完整的ECUs。但他们不被迫使用AUTOSAR SW架构。也许他们可以使用同样标准的AUTOSAR模块(比如EEPROM，DIO)。

（6）Communication Stack – FlexRay （略）

（7）Communication Stack – TCP/IP

TCP/IP通信服务是一组用于车辆TCP/IP通信系统的模块。其主要任务是为Ethernet通信网络提供一套统一的接口，同时从应用程序中隐藏协议内容和消息属性。

TCP/IP通信服务具有下属属性：

TCP/IP模块实现TCP/IP协议家族（TCP/UDP/IPv4/IPv6/ARP/ICMP/DHCP）主要协议，并通过以太网（Ethernet）提供动态的、基于Socket的通信；

Socket适配器模块是TCP/IP模块中的唯一上层模块；

服务层（存储器服务： Memory Services）

Memory Services由一个模块组成，即 NVRAM 管理器。它负责非易失性（non volatile）数据的管理(从不同的内存驱动读/写)。向应用程序提供非易失性数据。提供非易失性数据管理机制，如保存、加载、校验和保护验证、可靠存储等。

服务层（系统服务： System Services）

System Services 包含一组模块，并且模块的函数可以被所有层的模块使用。例如实时操作系统(包括定时器服务)和错误管理器。

其中一些服务是：

µC相关的(如操作系统：OS)，并可能支持特殊µC功能(如加密服务管理：Crypto Service Manager)，部分ECU硬件和应用程序相关(如ECU状态管理器：ECU State Manager)等。

这些服务为应用程序和基本软件（BSW）模块提供基本服务。

错误处理、报告和诊断（Error Handling, Reporting and Diagnostic）

在AUTOSAR中，有专门的模块对不同方面的错误处理。例如：Debugging 模块支持AUTOSAR BSW调试，它通过通信对接ECU内部模块和外部主机系统；Diagnostic Event Manager模块负责处理和储存诊断事件（错误）和相关的FreezeFrame数据；Diagnostic Log and Trace模块支持应用程序的日志记录和跟踪，它收集用户定义的日志消息并将其转换为标准格式；所有在基本软件（BSW）中检测到的开发错误都报告给Development Error Tracer模块；Diagnostic Communication Manager模块为诊断服务提供一个公共API接口；等等。