AUTOSAR——AUTOSAR基础

本文介绍了AUTOSAR(汽车开放系统体系结构)的概念及其核心思想,包括分层模型、虚拟功能总线(VFB)等内容。重点阐述了应用软件层、运行时环境、基础软件层的组成及功能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、AUTOSAR

AUTOSAR全称为“AUTomotive Open System ARchitecture”,译为“汽车开放系统体系结构”。

二、AUTOSAR核心思想

1)提倡“在标准上合作,在实现上竞争”原则;
2)核心思想是“统一标准,分散实现、集中配置”,即统一的开放平台、软件系统层次化模块化,降低应用与平台耦合性、统一格式的配置信息,集中配置生成系统;
3)应用系统可包含多个相互关联的AUTOSAR组件;

4)组件通过虚拟功能总线(VFB)提供标准通信机制与服务,实现平台无关性。

三、AUTOSAR分层模型

(1)应用软件层(Application Software Layer,ASW)

包含若干个软件组件(Software Component,SWC),软件组件间通过端口(Port)进行交互。每个软件组件可以包含一个或者多个运行实体(Runnable Entity,RE),运行实体中封装了相关控制算法,其可由RTE事件(RTE Event)触发。

应用层包括应用软件组件、传感器、执行器软件组件。
应用层软件组件通过RTE进行内部通信和ECU资源访问。

(2)运行时环境(Runtime Environment,RTE)

RTE封装了基础软件层的通信和服务,为应用层软件组件提供了标准化的基础软件和通信接口。

RTE层与ECU、具体应用相关,为每个ECU分别实现;
RTE层为组件之间的通信提供支持;
RTE层实现应用软件与硬件的无关性;

(3)基础软件层(Basic Software Layer,BSW)

AUTOSAR BSW:提供基础软件服务,包括标准化的系统功能以及功能接口,并且由一系列的基础服务软件组件构成,包括系统服务、内存服务、通信服务等。

A.系统服务层

系统服务层包括OS操作系统、系统服务、存储器服务,通信服务
系统服务层的实现与微控制器、ECU、具体应用相关

1)系统服务

DLT诊断逻辑
DET诊断错误
DEM诊断管理
ComM通信管理
BSWM基础软件管理
看门狗管理
ECU状态管理

2)存储服务

NVM:NVRAM Manager存储服务

MEMIF:Memory Abstraction Interface内存抽象接口

FEE:Flash EEPROM Emulation内存抽象硬件层

EA:EEPROM Abstraction

FLS:Flash Driver 驱动

EEP:EEPROM Driver

3)通信服务

BSW主要配置5个模块:Com、PduR(通讯架构中间模块)、CanTp(CAN运输协议)、CanIf(CAN接口)、Can。

4)OS操作系统

A.任务分类:

用户任务:基本任务/扩展任务;系统任务:空闲任务

B.任务状态:

基本任务:运行、就绪、挂起;扩展任务:运行、就绪、挂起、等待

C.任务的调度策略(Scheduling Policy)

OS的任务调度是基于优先级:调度策略(非抢占式;完全抢占式;混合抢占式;)

D.计数器与报警器

E.调度表:每个报警器只能激活一个任务或者设置一个事件,需要定义多个报警器来实现在同一时刻激活多个任务或者设置多个事件

F.中断处理

两类中断服务程序(ISR):不能使用操作系统的服务,中断不会影响系统对任务的管理;可以使用一部分操作系统提供的服务,如激活任务、设置事件等

G.资源管理

H.自旋锁:是一种为保护共享资源而提出的锁机制,一般用于多核处理器解决资源互斥问题

I.一致类(Conformance Class)

J.可扩展性等级(Scalability Class)

SC1: 在OSEK OS基础上加入调度表;(堆栈监控)

SC2:在SC1基础上加入时间保护;

SC3:在SC1基础上加入存储保护;

SC4:在SC1基础上加入时间保护和存储保护;(多核通信IOC)

B.微控制器ECU抽象层

微控制器抽象层实现的不同硬件接口的统一,实现了对硬件的封装;
微控制器抽象层包括板载设备(看门狗)抽象,存储器硬件抽象,通信硬件抽象,IO硬件抽象

C.微控制器驱动

MCAL驱动层:微控制器驱动,存储器驱动,通信驱动,IO驱动。

1)微控制器驱动

通用定时器驱动:操作系统定时器;硬件定时器
看门狗驱动
MCU驱动:直接访问微控制器硬件
内核测试
2)存储器驱动
存储器驱动
内部EEPROM驱动:初始化;内部EEPROM读写、写、擦除
内部Flash驱动:初始化;内部Flash读、写、擦除;将Flash访问代码下载至RAM
RAMFlash测试
3)通信驱动
SPI驱动:
微控制器内部同步通信串行接口驱动EEPROM/看门狗读写访问服务
以太网、CANLINFlexRay驱动
4)IO驱动
ICU驱动:正常模式和休眠模式
PWM驱动:为微控制器PWM模块提供初始化和控制服务,可生成周期和占空比可变的脉冲
DIO驱动:数字化输入输出
PORT驱动:初始化;进行引脚功能服用
ADC驱动:数模转换

D.复杂驱动模块

复杂驱动模块是复杂传感器和执行器操作模块的映射。

(4)硬件层(HardWare)

MCU芯片 

四、VBF

VFB将软件构件间、软件构件与基础软件间的通信进行了抽象;
VFB是虚拟硬件和独立映射系统的集合;
VFB为构件提供了标准的通信机制和服务;
VFB包含SWC标准化接口、设备驱动(底层软件中实现)、ECU抽象层(底层软件中实现)、AUTOSAR服务(底层软件中实现);

 五、 AUTOSAR接口分类

1)AUOSAR接口:描述原件接收和发送的数据和服务

2)标准化AUTOSAR接口:AUOSAR框架定义的接口

3)标准化接口:软件中具有的API

接口结构图

 注:

SWC - Software Component  软件组件
RTE - Run-Time Environment 实时运行环境
BSW - Basic Software 基础软件
BswM - Basic-software mode Manager 基础软件管理模块
CAN IF - CAN interface CAN接口
CAN TP - CAN Transport CAN运输协议
CAN SM - CAN State Manager CAN状态管理模块
DCM - Diagnostic Communication Manager 诊断通讯管理模块
DEM - Diagnostic Event Manager 诊断事件管理模块
DLT - Diagnostic Logger Tracer 诊断日志追踪模块
DET - Development Error Tracer 开发错误追踪模块
DIO - Digital Input/Output 数字输入输出
EcuM - ECU State Manager ECU状态管理模块
EcuC - ECU Configuration ECU配置模块
FEE - Flash EEPROM Emulation 内存抽象硬件层
IoHwAb -  I/O Hardware Abstract I/O 硬件抽象层
MemIf - Memory Interface 内存接口
NvM - Non-Volatile Manager 非易失数据管理模块
PduR - Protocol Data Unit Route 通讯架构中间模块
XCP - University Calibration Protocol 多用传输协议
CDD - Complex Device Driver 复杂设备驱动

这里的NM主要是针对Can协议的网路管理。 AUTOSAR CanNM的核心思想主要归纳为以下两条: 1.  如果节点需要保持通信,则节点需要周期的发送NMPDUs,否则停止发送NMPDUs 2.     如果总线上的所有节点不需要使用总线,那么总线上过了一段时间没有NMPDUs时,则会进入Bus-Sleep Mode。   工作模式和状态   CanNm一共有三个工作模式 1.  Network Mode 2.  PrepareBus-Sleep Mode 3.  Bus-Sleep Mode 模式的改变应该通过回调函数通知上层。 下面单独说每种模式   (1)Network Mode Network Mode又包括三个内部状态 1. Repeat Message State 2. Normal Operation State 3. Ready Sleep State ①Repeat Message State 这个模式被用来确保从Bus-Sleep or Prepare Bus-Sleep到Network Mode的节点被总线上面其他节点发现。这个状态可以用来检测总线上的节点。 当进入Repeat Message State时,节点应该开始传送NMPDUs。 在Repeat Message State时,当NM-Timeout Timer溢出,CanNm模块应该重载Timer。 CanNm模块应该在Repeat Message State 下保持一段时间,这段时间可以通过CANNM_REPEAT_MESSAGE_TIME来进行配置。 当离开Repeat Message State的时候,如果节点需要通信,则进入Normal Operation State;如果节点不需要通信,则进入Ready Sleep State。并且清空Repeat Message Bit。   ②Normal Operation State 这个状态可以保持总线处于唤醒状态。从Ready sleep state进入这个状态的时候应该发送NMPDUs。 在Normal Operation State当NM-Timeout Timer溢出,CanNm模块应该重载Timer。 如果节点不需要使用通信,则网络应该被释放,节点应该进入Ready Sleep State。 如果节点接收到Repeat Message Request Bit,则节点进入Repeat Message State。如果节点自身需要进入Repeat Message State,则该节点进入Repeat Message State并且设置Repeat Message Request Bit。   ③ReadySleep State 这个状态是为了如果本节点已经准备释放总线,而其他节点还需要使用总线的时候,在这个状态下等待其他总线上的节点进入Perpere Bus-Sleep Mode。进入这个状态之后,CanNm模块应该停止NMPDUs的传送。 如果NM-Timeout Timer溢出,节点将会进入Prepare Bus-Sleep Mode。 如果该节点需要使用总线,则节点进入Nomal Operation State。 如果节点接收到Repeat Message Request Bit,则节点进入Repeat Message State。如果节点自身需要进入Repeat Message State,则该节点进入Repeat Message State并且设置Repeat Message Request Bit。 (2)PrepareBus-Sleep Mode   这个状态是为了等待总线上的所有节点能够在进入Bus-Sleep Mode之前,有时间停止节点的active状态如清空队列中为发送的报文。在Prepare Bus –Sleep Mode下,所有节点都静默下来。 当节点进入PrepareBus Mode时,应该通知上层应用。通过配置CANNM_WAIT_BUS_SLEEP_TIME参数,可以改变节点在PrepareBus-Sleep Mode停留的时间,在这段时间之后节点将会进入其他状态。 在Prepare Bus-Sleep Mode下面接收到NMPDU或者被上层应用请求通信时,节点将进入Network Mode中的Normal operation State。   (3)Bus-SleepMode   Bus-Sleep Mode的目的是当没有消息被传送的时候可以减少能量的消耗。在Bus-Sleep Mode下面,节点可以被唤醒(如本地唤醒源和CAN线唤醒源)。CANNM_TIMEOUT_TIME+CANNM_WAIT_BUS_SLEEP_TIME两个参数在整个总线上面的节点都应该时一样的配置,保证了总线上的节点能够统一的进行休眠。 当进入Bus-Sleep Mode时候,应该通知上层应用。 在Bus-Sleep Mode下,如果成功接收到NMPDU,CAN NM模块应该调用Nm_NetworkStartIndication。 如果CanNm_PassiveStartUp被调用,则CAN NM模块进入Network Mode 中的Repeat Message State。 ———————————————— 版权声明:本文为CSDN博主「cococenstar」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/cococenstar/article/details/84096689
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

汽车人——EEA

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值