AutoSAR系列笔记(入门篇) AutoSAR简介



前言

在汽车行业,技术的发展日新月异,其中最引人注目的就是汽车电子系统的发展。随着汽车电子化、智能化的趋势日益明显,汽车软件的重要性也日益凸显。在这个背景下,Autosar(Automotive Open System Architecture)应运而生,它为汽车电子系统提供了一个开放、标准化的软件架构。由于车载软件和重复利用和转移的发展,汽车电子和电气 (E/E) 系统日益复杂。该组织成立的初衷是为越来越复杂的汽车ECU软件建立一个标准化平台,以减少其设计复杂度,增加其灵活性,提高其开发效率,本文主要介绍了什么是AutoSAR、AutoSAR的原则及核心思想、AutoSAR的架构、以及AutoSAR的工具链。


一、什么是AutoSAR

AUTOSAR是Automotive Open System Architecture的缩写,即汽车开放系统架构。AUTOSAR是一家由汽车电子、半导体和软件行业的全球各家汽车制造商、供应商、服务提供商等公司组成的全球开发合作伙伴组,成立于2003年7月,其核心成员由德国宝马、戴姆勒及博世等9家公司构成;并联合推出了一个开放化的、标准化的汽车嵌入式系统软件架构规范。
AUTOSAR组织是这样介绍自己的

AUTOSAR (AUTomotive Open System ARchitecture) is a worldwide development partnership of vehicle manufacturers, suppliers, service providers and companies from the automotive electronics, semiconductor and software industry.

与传统的ECU软件架构相对比,AutoSAR的分成架构的高度的抽象对汽车嵌入式系统的软件和硬件系统进行解耦,大大提高了独立性,降低了他们之间的耦合性。
在这里插入图片描述


二、AUTOSAR原则及心思想

AUTOSAR提倡“在标准上合作,在实现上竞争”原则;
AUTOSAR核心思想是“统一标准,分散实现、集中配置”,即统一的开放平台、软件系统层次化模块化,降低应用与平台耦合性、统一格式的配置信息,集中配置生成系统;
一个汽车电子应用系统可包含多个相互关联的AUTOSAR组件。组件通过虚拟功能总线(VFB)提供标准通信机制与服务,实现平台无关性;

三、AutoSAR的架构

为了实现应用程序和硬件模块之间的分离,汽车电子软件架构被抽象成四层,如下图所示。由上至下依次为:应用层(Application Layer)、运行时环境(Run Time Environment,RTE)、基础软件层(Basic Software, BSW)以及微控制器(Microcontroller)。
在这里插入图片描述

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

应用软件层(Application Software Layer,ASW)其包含若干个软件组件(Software Component,SWC),软件组件间通过端口(Port)进行交互。每个软件组件可以包含一个或者多个运行实体(Runnable Entity,RE),运行实体中封装了相关控制算法,其可由RTE事件(RTE Event)触发。
在这里插入图片描述

运行时环境(Runtime Environment,RTE)

运行时环境(Runtime Environment,RTE)作为应用软件层与基础软件层交互的桥梁,为软硬件分离提供了可能。RTE可以实现软件组件间、基础软件间以及软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务,为应用层软件组件提供了标准化的基础软件和通信接口,使得应用层可以通过RTE接口函数调用基础软件的服务。此外,RTE抽象了ECU之间的通信,即RTE通过使用标准化的接口将其统一为软件组件之间的通信。由于RTE的实现与具体ECU相关,所以必须为每个ECU分别实现。

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

基础软件层(Basic Software Layer,BSW)又可分为四层,即服务层(Services Layer)、ECU抽象层(ECU Abstraction Layer)、微控制器抽象层(Microcontroller Abstraction Layer,MCAL)和复杂驱动(Complex Drivers)
在这里插入图片描述

(1)服务层

服务层(Services Layer)提供了汽车嵌入式系统软件常用的一些服务,其可分为系统服务(System Services)、存储器服务(Memory Services)以及通信服务(Communication Services)三大部分。提供包括网络通信管理、存储管理、ECU模式管理和实时操作系统(Real Time Operating System,RTOS)等服务。除了操作系统外,服务层的软件模块都是与ECU平台无关的。

(2)ECU抽象层

ECU抽象层(ECU Abstraction Layer)包括板载设备抽象(Onboard Devices Abstraction)、存储器硬件抽象(Memory Hardware Abstraction)、通信硬件抽象(Communication Hardware Abstraction)和I/O硬件抽象(Input/Output Hardware Abstraction)。该层将ECU结构进行了抽象,负责提供统一的访问接口,实现对通信、存储器或者I/O的访问,从而不需要考虑这些资源是由微控制器片内提供的,还是由微控制器片外设备提供的。该层与ECU平台相关,但与微控制器无关,这种无关性正是由微控制器抽象层来实现的。

(3)微控制器抽象层

微控制器抽象层(Microcontroller Abstraction Layer,MCAL)是实现不同硬件接口统一化的特殊层。通过微控制器抽象层可将硬件封装起来,避免上层软件直接对微控制器的寄存器进行操作。微控制器抽象层包括微控制器驱动(Microcontroller Drivers)、存储器驱动(Memory Drivers)、通信驱动(Communication Drivers)以及I/O驱动(I/O Drivers)

(4)复杂驱动层

由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题,难以抽象,所以在AUTOSAR规范中这部分没有被标准化,统称为复杂驱动(Complex Drivers)。


四、AutoSAR的工具链

AutoSAR的开发工具及调试工具有很多,如:
MathWorks Simulink:一个用于AUTOSAR模型建模和仿真的工具,支持多种AUTOSAR版本和硬件平台。
Lauterbach TRACE32:一个用于AUTOSAR软件调试的工具,支持多种MCU和调试接口。

EB tresos Studio:一个用于AUTOSAR配置和代码生成的工具,支持多种AUTOSAR版本和硬件平台。
Vector CANoe:一个用于AUTOSAR通信协议测试和仿真的工具,支持多种通信协议和ECU。

Vector CANape:一个用于AUTOSAR应用程序调试和校准的工具,支持多种通信接口和ECU。

Tasking by Altium:一个用于AUTOSAR应用程序编译和调试的工具,支持多种MCU和编译器。

ETAS:一款用于AUTOSAR系统调试和测试的工具,支持多种MCU和总线协议。ETAS是Bosch旗下的一家汽车电子开发工具和测试系统提供商。

Davinci:一款用于AUTOSAR系统调试和测试的工具,支持多种MCU和总线协议。ETAS是Bosch旗下的一家汽车电子开发工具和测试系统提供商。

当前主流的组合有
1、Matlab + Davinci
2、Matlab + ETAS

SWC应用层主要使用Matlab开发,使用Simulink模型开发应用,优点在于生成代码,逻辑清晰,不易出出现误编码,缺点是开发周期大于手写代码。
在这里插入图片描述

BSW层主要是使用Davinci / ETAS配置BSW基础软件的服务层、ECU抽象层、以及部分手写的复杂驱动层和自动生成RTE。
在这里插入图片描述

MCAL微控制器抽象层主要使用EB tresos Studio来配置微控制器的抽象驱动层。
在这里插入图片描述


总结

AutoSAR的目标就是建议一套优秀的框架的软件代码,实现软硬件分离的分层设计,提高系统的整合能力,尤其标准化交互接口以及软件组件模型的定义提高了各层的软件复用能力,从而降低了开发成本,使得系统集成与产品推出的速度极大提升。同时使得汽车软件开发更加规范化、标准化、快速化、简洁化、经济化。

这里的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
评论 54
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

科研路上的绊脚石

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

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

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

打赏作者

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

抵扣说明:

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

余额充值