| 编辑推荐: |
本文主要简单的介绍AUTOSAR的系统架构，以及各个模块的主要功能。希望对您的学习有所帮助。
本文来自于MBD开发，由火龙果软件Linda编辑、推荐。 |
|
一 AUTOSAR系统架构概述
AUTOSAR架构在最高抽象级分了三个软件层：应用层，实时运行环境（RTE）和运行在微控制器上的基础软件（BSW）。
AUTOSAR的基础软件可以进一步分为这几层：服务层，ECU抽象层，微控制器抽象层和复杂驱动。
Microcontroller Abstraction Layer
微控制器抽象层是基础软件中最低的软件层级。他包含可以直接访问微控制器以及外围设备的驱动。
比微控制器抽象层高的软件层级就跟微控制器的类型无关了。
微控制器抽象层的实现是和微控制器的类型相关的。他向比他高的层级提供的标准接口，并且是和微控制器类型无关的。
ECU Abstraction Layer
ECU抽象层与微控制器抽象层中的驱动相关联，他还包含外部设备的驱动。
ECU抽象层提供了一个访问设备的API接口，而不用去考虑设备的位置以及与处理器的连接方式。
比ECU抽象层高的软件层级就和ECU的硬件布局无关了。
ECU抽象层的实现与微控制器无关，他向比他高的层级提供的接口与微控制器类型和ECU的硬件布局都无关。
Complex Drivers
复杂驱动层的跨度从硬件到RTE。他提供了可以集成特殊功能函数的可能性，比如：
设备的驱动程序在AUTOSAR中没有被指定
设备的驱动程序对执行时间有很高的要求
方便设备驱动程序的移植等
复杂驱动层的实现和提供的接口可能和应用层，微控制器的类型以及ECU硬件都相关。
System Layer
系统服务层是基础软件的最高层，他与应用层有很紧密的关系，服务层提供如下的功能：
操作系统功能
车辆网络通信和网络管理服务
存储服务（NVRAM管理）
诊断服务（包括UDS通信，故障处理等）
ECU状态管理，模式管理
逻辑和时序流程监控（看门狗管理）
服务层的主要功能是为应用层软件，RTE以及其他基础软件模块提供上述的服务。
服务层的实现几乎与微控制器类型以及ECU硬件不相关。
服务层向上提供的接口与微控制器类型以及ECU硬件不相关。
Runtime Environment
RTE层的功能是为应用软件提供通信服务。这里的应用软件包括AUTOSAR软件组件，AUTOSAR传感器/执行器组件以及系统服务。
有了RTE层，使得AUTOSAR软件组件与特定ECU无关。
RTE层的实现与ECU以及指定的应用有关，RTE向上提供的接口与ECU无关。
基础软件层级还可以进一步再分为若干个功能组。
比如：
输入输出：
传感器、执行器和ECU外设的标准化访问。
在微控制器抽象层定义了I/O驱动模块。
在ECU抽象层定义了I/O硬件抽象模块。
通信:
对车辆网络系统，ECU车载通信系统，ECU内部软件的标准化访问。
在微控制器抽象层定义了各种通信的驱动模块。
在ECU抽象层定义了各种通信硬件抽象模块。
在服务层定义了通信服务模块，向应用层提供完全独立与通信硬件和通信矩阵的接口。
非车载通信:
车辆到其他X设备的通信，车内无线网络系统，ECU非车载通信系统的标准化访问。
加密:
对加密原语（包括内部/外部硬件加速器）的标准化访问。
存储:
对内部/外部存储器（非易失性存储器）的标准化访问。
系统:
提供标准化的操作系统，计时器，错误存储等，规定ECU的服务（状态管理，看门狗管理），提供库函数。
这些功能组还可以再细分。
库函数
库函数是用于相关目的的函数集合，以下是库函数的一些特点：
库函数可以被BSW模块，RTE，SWC，以及其他库函数或者集成用的代码所调用
库函数是运行在与被调用代码相同的保护环境中
库函数中只能是可以独立运行的代码或者是调用别的库函数
库函数可以再次进入
库函数不能含有内部状态
库函数不需要任何初始化
库函数是同步的
在AUTOSAR中指定了以下的库函数：
Fixed point mathematical
Floating point mathematical
Interpolation for fixed point data
Interpolation for floating point data
Extended functions
Bit handling
E2E communication
CRC calculation
Atomic multicore safe operations
基础软件的模块类型大致可以分为四类：
Driver
Interface
Handler
Manager
驱动
驱动程序包含控制和访问内部或外部设备的功能。
内部设备位于微控制器的内部。比如有以下的内部设备：
内部EEPROM
内部 CAN 控制器
内部模拟数字转换器
驱动内部设备的驱动程序位于微控制器抽象层。
外部设备位于微控制器外部的ECU硬件上。比如有以下的外部设备：
外部EEPROM
外部看门狗
外部闪存
外部设备驱动位于ECU抽象层。他通过微控制器抽象层访问外部设备。对于集成在系统基础芯片（SBCs）上的组件，比如收发器和看门狗，AUTOSAR也支持这种方式。
比如，一个可以通过SPI接口访问的外部EEPROM的驱动，可以通过处理和控制SPI总线的方式来实现。
接口
一个接口（接口模块）包含从别的的模块中抽象出来的功能，这些模块在架构上位于接口（接口模块）的下面。比如可以从特定设备的硬件实现中抽象出一个接口模块。他提供了一个通用的API来访问特定类型的设备，该API不依赖于该类型的现有设备的数量，也不依赖于不同设备的硬件实现。
接口不能修改数据的内容。通常，接口位于ECU抽象层。
比如，CAN通信系统提供了一个通用的API，用于访问不依赖于CAN控制器数量以及硬件实现的CAN网络。
Handler
Handler是一个种特殊的接口，他控制一个或多个客户端对一个或多个驱动程序的并发访问，多重访问或异步访问。他还负责执行缓冲，队列，仲裁和多路复用。
Handler不能修改数据的内容。
Handler通常包含在驱动程序或接口中（比如SPIHandlerDriver、ADCDriver）
Manager
Manager为多个终端提供特定的服务。在仅仅使用Handler功能不足以从多个终端抽象出所有的情况的时候，都需要用到Manager。
除了Handler功能外，Manager还可以评估，修改或调整数据的内容。
通常Manager位于服务层。
比如，NVRAM Manager 管理对内部或外部存储器设备（闪存以及EEPROM）的并发访问。他还负责分布式和可靠的数据存储、数据检查、提供默认值等。
二 AUTOSAR软件层级的详细介绍
2.1 Microcontroller Abstraction Layer
Microcontroller Abstraction Layer 可以把类似功能的模块分为以下几组：
Microcontroller Driver
里面包含一些内设的驱动，比如看门狗，通用计时器等，以及直接访问控制器的功能，比如Core test
Communication Drivers
ECU硬件设备间的通信（比如SPI）和车辆间的通信（比如CAN）
Memory Drivers
片上存储设备的驱动（比如内部闪存，内部EEPROM）和内存映射的外部存储设备（比如外部闪存）
I/O Drivers
模拟和数字输入输出的驱动（比如ADC，PWM，DIO等）
Crypto Drivers
片上加密设备的驱动，比如SHE（安全硬件扩展）或者HSM（硬件安全模块）
Wireless Communication Drivers
无线网络系统的驱动（车内或车外通信）
2.2 I/O Hardware Abstraction
硬件输入输出层是从外围输入输出设备（片上或板上）的位置和ECU硬件布局（如微控制器引脚连接和信号电平反转）抽象出来的一组模块。
硬件输入输出层的作用是体现连接到ECU硬件的输入和输出信号（比如电流，电压，频率）
对于较高的软件层比如应用层SWC，就可以不用考虑ECU硬件的布局了
硬件输入输出层的实现和微控制器类型无关和ECU硬件的布局有关。
硬件输入输出层向上提供的接口与微控制器类型以及ECU硬件的布局都无关，而是取决于信号的类型和以及如何实现的
2.3 Communication Hardware Abstraction
通信硬件抽象层是从通信控制器的位置和ECU硬件布局中抽象出来的一组模块。对于所有通信系统，都需要对应的通信硬件模块抽象（例如LIN、CAN、FlexRay）
比如，一个ECU有一个自带两路CAN通道的微控制器和一个带4个CAN控制器的车载附加专用集成电路（ASIC）。CAN-ASIC通过SPI连接到微控制器。通过总线特定接口（比如CAN接口）访问通信驱动程序。
通信硬件抽象层的作用是提供相同的机制来访问总线通道，而不用考虑CAN控制器的位置（片上或ECU上）。
通信硬件抽象层的实现和微控制器类型无关，和ECU硬件以及外部设备相关。
通信硬件抽象层向上提供的接口和总线相关，与微控制器类型以及ECU硬件都无关。
2.4 Memory Hardware Abstraction
存储器硬件抽象是从外部存储器设备（片上或板上）的位置和ECU硬件布局中抽象出来的一组模块。
比如，片上EEPROM和外部EEPROM设备可以通过相同的机制访问。
存储器驱动程序通过特定于存储器的抽象（例如EEPROM抽象）访问。
通过在Flash硬件单元上模拟EEPROM，可以通过内存抽象接口对两种硬件进行通用访问。
无论是访问内部（片上）或外部（板上）存储器设备以及不同的存储器硬件类型（EEPROM、Flash），存储器硬件抽象都可以提供同等机制。
存储器硬件抽象层的实现和微控制器无关和ECU的硬件布局有关。
存储器硬件抽象层向上提供的接口与微控制器类型，ECU硬件布局以及存储器类型都无关。
2.5 Onboard Device Abstraction
板载设备抽象包含ECU板载硬件设备的驱动程序，这些设备不能被视为传感器或执行器，如内部或外部看门狗。这些驱动程序通过微控制器抽象层访问ECU板载设备。
板载设备抽象的作用是抽象特定的ECU板载设备。
板载设备抽象的实现和微控制器无关，和外部的设备有关。
板载设备抽象向上的接口与微控制器无关，部分依赖于ECU硬件相关。
2.6 Crypto Hardware Abstraction
加密硬件抽象是从加密原语（基于内部或外部硬件或软件）抽象出来的一组模块。
比如AES加密算法是在SHE（安全硬件扩展）或提供的软件库中实现。
加密硬件抽象的作用是对于内部片上的加密设备或者软件加密设备提供同样的访问机制。
加密硬件抽象的实现与微控制器无关。
加密硬件抽象向上的接口与微控制器，ECU硬件以及加密设备种类都无关。
2.7 Crypto Services
加密服务由两个模块组成。
Crypto Service Manager 负责管理密码任务。
Key Manager 负责与密钥配置主机（在NVM或者加密驱动中）进行交互，并且管理存储和验证证书链。
加密服务的任务是以统一的方式为应用层程序提供加密原语和密钥存储。
加密服务的实现与微控制器，ECU硬件无关。高度可配置。
加密服务向上提供的接口与微控制器，ECU硬件无关。是标准的AUTOSAR接口
2.8 Communication Services
通信服务是一组用于车辆网络通信的模块（CAN、LIN、FlexRay和以太网）。他们通过通信硬件抽象与通信驱动程序连接。
通信服务的作用是：
为车辆网络提供统一的通信接口
为网络管理提供统一服务
为车辆网络提供统一的诊断通信接口
使得应用程序不依赖于通信协议和消息属性
通信服务的实现不依赖于微控制器类型和ECU硬件，部分依赖于总线类型
通信服务向上提供的接口与微控制器类型，ECU硬件，总线类型都不相关
2.8.1 CAN Communication Services
CAN通信服务是一组利用CAN通信系统进行车辆网络通信的模块。
CAN通信服务的任务是为CAN网络提供统一的接口。使得应用程序不依赖于CAN通信协议和消息属性。
CAN通信协议栈支持：
经典的CAN通信（CAN 2.0）
如果硬件支持，可以进行CAN FD通信
CAN通信服务的实现与微控制器类型和ECU硬件都无关，部分依赖于CAN。
AUTOSAR的COM模块，通用网络管理（NM）模块，接口和诊断通信管理（DCM）模块，对于所有车辆网络系统都是相同的，并且每一个ECU都有一个实例。
通用网络管理接口只包含一个调度程序，不包含其他的功能。如果是网关ECU，他还可以包含NM协调函数，该功能允许同步多个不同的网络（相同或不同类型）的唤醒和关闭。
CAN NM是专门用于CAN网络的网络管理，每一个CAN车辆网络系统都有一个CAN NM实例。
通信系统指定CAN State Manager（SM）来处理通信系统的启动和关闭。此外，CAN SM还控制COM发送PDU和监控信号是否超时。
2.8.2 J1939 Communication Services
J1939通信服务扩展了普通的CAN通信协议栈，通常用于重型车辆的车辆网络通信，以及直流充电与充电桩的通信。
J1939通信服务的任务是提供J1939要求的协议服务。使得应用程序不依赖于通信协议和消息属性。
在CAN协议栈中有两种传输协议模块（CanTp和J1939Tp），可以在不同的通道分别使用或者同时使用。使用场景如下：
CanTp:标准诊断（DCM），标准CAN总线上的长PDU传输
J1939Tp:J1939诊断，J1939CAN总线上的长PDU传输
J1939通信服务的实现与微控制器和ECU硬件无关，支持配置动态帧标识符。
J1939网络管理处理分配给每个ECU的唯一地址，但不支持睡眠/唤醒处理之类的功能，比如部分网络。
提供J1939诊断以及请求处理。
2.8.3 LIN Communication Services
LIN通信服务是一组利用LIN通信系统进行车辆网络通信的模块。
LIN通信服务的任务是为LIN网络提供统一的接口。使得应用程序不依赖于通信协议和消息属性。
LIN通信服务包含符合ISO 17987标准的通信协议栈，包括
调度表管理器，用于处理切换到其他调度表的请求（对于LIN主节点）
不同LIN帧类型的通信处理
传输协议，用于诊断
唤醒和休眠接口
潜在的LIN驱动程序：
实现LIN协议并访问特定硬件
支持简单的UART和基于LIN硬件的复杂帧
将LIN集成到AUTOSAR中的注意点
LIN接口控制唤醒/睡眠，并允许从机保持总线唤醒状态（分散方法）。
通信系统指定LIN State Manager（SM）处理与通信相关的启动和关闭功能。此外，它还控制来自通信管理器的通信模式请求。LIN
SM还通过COM的接口来控制I-PDU。
当发送LIN帧时，LIN接口在他需要数据的时间点（即发送LIN帧之前），从PDU路由器请求帧数据（I-PDU）。
2.8.4 TCP/IP Communication Services
是一组利用TCP/IP通信系统进行车辆网络通信的模块。
TCP/IP通信服务的任务是为TCP/IP网络提供统一的接口。使得应用程序不依赖于通信协议和消息属性。
TCP/IP模块实现TCP/IP协议家族的主要协议（TCP、UDP、IPv4、IPv6、ARP、ICMP、DHCP），并通过以太网提供基于套接口的动态通信。
插座适配器模块（SoAd）是TCP/IP模块的唯一上层模块。
2.9 Memory Services
存储服务由NVRAM Manager组成。他负责管理非易失性数据（从不同的内存设备中读性）
存储服务的作用是以统一的方式向应用程序提供非易失性数据。是从存储器位置和属性中抽象出来的。提供的机制包括，非易失性数据的保存，读取，校验保护，验证，可靠存储等。
存储服务的实现和微控制器类型以及ECU硬件无关，配置灵活。
存储服务向上提供的接口与微控制器类型以及ECU硬件无关，是标准AUTOSAR接口
2.10 System Services
系统服务是一组功能模块，可供各层模块使用。例如实时操作系统（包括计时器服务）和错误管理。
一些服务依赖于微控制器（比如OS），以及可能支持特殊的微控制器的功能（如时间服务）
部分服务依赖于ECU硬件和应用程序（如EcuM）
还有一些服务是与硬件和微控制器无关的
系统服务的作用是为应用程序和基础软件模块提供基础服务。
系统服务的实现，部分与微控制器类型，ECU硬件和特定的应用程序相关
系统服务向上提供的接口与微控制器类型，ECU硬件无关
2.11 Error Handling, Reporting and Diagnostic
AUTOSAR中有专门的错误处理模块，例如：
Diagnostic Event Manager模块负责处理和存储诊断事件（错误）和相关冻结数据帧。
Diagnostic Log and Trace模块支持应用程序的日志和跟踪。他收集用户定义的日志消息并将其转换为标准格式。
基础软件中检测到的所有开发错误都报告给Default Error Tracer。
Diagnostic Communication Manager 提供一个通用的API接口给诊断服务
总结：
以上介绍了AUTOSAR的总体架构，主要是基础软件中所包含的模块，以及其功能。这样大体上知道什么功能应该在哪个模块里配置。个人感觉AUTOSAR架构的核心，一个是按功能分类，另一个是尽量把跟微控制器以及与ECU硬件布局相关模块独立出来，这样如果要移植项目到不同的平台，就只需要修改跟硬件相关的那些模块，而应用层和大部分系统服务都不需要更改。 |
