AutoSAR技术整理.docx

AutoSAR技术整理.docx

《AutoSAR技术整理.docx》由会员分享，可在线阅读，更多相关《AutoSAR技术整理.docx（15页珍藏版）》请在冰点文库上搜索。

AutoSAR技术整理

AUTOSAR技术概述

前言

为了各个功能实现“模块性”、“可量测性”、“可移植性”和“复用性”，AUTOSAR为车辆系统提供了如下图所示的基于不同层面的标准接口的通用的软件底层基础结构。

AUTOSAR能够进行全系统和组态过程的优化（比如分区和资源使用），在需要时也允许那些为了满足特定的设备和硬件限制的运行需求的局部优化。

如要进一步的详细信息，请点击右侧的相应模块。

模块性

汽车软件元件的模块性是指根据某些电子控制单元及其任务的个别需求，可以对软件模块进行裁减。

可量测性

函数的可量测性将保证通用软件模块在不同的车辆平台的适应性，来禁止实现类似功能时发生软件增生。

可移植性

函数的可移植性将优化对现有的整个车辆电子结构资源的使用。

复用性

函数的复用性将会提高软件产品的质量和可靠性，并增强不同生产线之间的公司品牌形象。

标准化接口

功能接口的标准化穿越制造商和供应商之间，不同软件层之间接口的标准化可以看成是AUTOSAR实现其技术目标的一个基础。

下图显示了AUTOSAR实现途径的一个缩影。

其基本理念就是：

AUTOSAR软件构件（SW-C）。

AUTOSAR软件构件封装了一个能在AUTOSAR底层基础结构上运行的应用。

AUTOSAR软件构件具有由AUTOSAR描述和标准化的明确定义的接口。

软件构件描述

为了AUTOSAR软件构件集成所需的接口和其他方面，AUTOSAR提供了一套标准的描述格式，也就是软件构件描述。

虚拟功能总线（VFB）

虚拟功能总线（VFB）是所有通讯机制和对AUTOSAR提供的基本软件的核心接口在技术独立和技术水平上的抽象的总和，对于一个具体的系统，当定义了AUTOSAR软件构件间的连接后，VFB将在开发过程的初期对构件进行虚拟集成。

系统约束和ECU描述

为了将AUTOSAR软件构件集成到ECU网络中，AUTOSAR为成套系统提供了和单个ECU资源和配置一样的描述格式。

这些描述和软件构件描述保持独立。

在ECU上的映射

为了建立具体的ECU系统，须将不同的描述元件的信息收集到一起，AUTOSAR定义了其所需的方法论和工具支持。

这里面特别包括了在每个ECU上的运行期环境和基本软件的配置和生成。

运行期环境

从AUTOSAR软件构件的角度来看，运行期环境实现了指定ECU的虚拟功能总线的功能。

同时运行期环境能够尽可能分发这些任务给基本软件。

基础软件

基础软件提供ECU的底层基础结构功能。

1、AUTOSAR软件构件的实现与底层基础结构无关

AUTOSAR的基本设计理念是：

应用与底层结构的分离。

AUTOSAR中的应用由AUTOSAR软件构件的互联组成。

下图显示了一个应用由三个AUTOSAR软件构件组成，它们之间由几个“连接器”互联。

AUTOSAR软件构件互联实例

每个AUTOSAR软件构件封装了应用的部分功能。

AUTOSAR没有规定软件构件有多大。

根据不同应用领域的要求，一个AUTOSAR软件构件可能是一个可以复用的小函数（比如滤波器），或者是一个封装了整个汽车功能的大模块。

但是AUTOSAR软件构件是所谓的“软件元构件”，它不能被分布在几个AUTOSAR控制器中。

因此在一部车辆中一个AUTOSAR构件的实例只能分配给一个ECU。

1.1、AUTOSAR软件构件描述

AUTOSAR软件构件描述包括以下信息：

∙构件需要的和能提供的作用和数据；

∙底层结构上的构件需求；

∙构件所需的资源（内存，CPU处理时间等）；

∙构件指定的执行动作的有关信息。

AUTOSAR软件构件描述的结构和格式称为“软件构件模版”。

1.2、AUTOSAR软件构件的实现与底层基础结构无关

AUTOSAR构件的实现要从根本上与以下几点无关：

∙AUTOSAR构件映射的ECU微控制器种类；

∙AUTOSAR构件映射的ECU种类。

AUTOSAR底层结构关注于给构件提供一个ECU的标准的视图（比如ECU外围输入输出）；

∙与本构件有互相影响的其他构件的位置。

构件描述精确地描述了构件所提供和所需的数据和服务。

构件不需要知道在其所在的ECU或其它ECU中是否有构件为其提供数据和服务。

因此构件的实现与网络技术无关；

∙构件在一个系统或ECU中被实例化的次数。

1.3、传感器/执行器软件构件

传感器/执行器构件是特殊的AUTOSAR构件，用来封装应用中的传感器或执行器的属性。

如图举例说明了从物理信号到软件信号（如汽车速度）和软件信号到物理信号（如车灯）的典型转换过程。

AUTOSAR底层结构注重隐藏微控制器和ECU的电子细节。

硬件之间的相互作用

AUTOSAR底层结构并不隐藏传感器和执行器具体细节。

作为一种特殊的“AUTOSAR软件构件”，一个具体的传感器或执行器的属性被称为“传感器/执行器构件”。

传感器/执行器构件与其所要映射的ECU无关，而与所要设计的传感器或执行器有关。

举个例子，传感器构件的输入是一个ECU输入端子上的电信号的软件表达（如传感器产生的电流），输出则是传感器采集的物理量（如现在的车速）。

由于性能和时效的原因，这类构件必须在有和传感器或执行器物理连接的ECU上才能运行。

2、虚拟功能总线（VFB）

为了实现可重定位性这个目标，AUTOSAR软件构件被设计成与底层硬件无关。

将虚拟功能总线作为虚拟硬件及独立系统集成映射的方法，可以实现构件的无关性。

这样可以实现AUTOSAR构件的虚拟集成，从而可以在比现行开发进程更早的设计阶段进行汽车软件集成的部分工作。

2.1、概念

虚拟功能总线是整个车辆的AUTOSAR软件构件互联关系的抽象。

不同构件以及构件和环境（如硬件驱动，操作系统，服务，等等）之间的通讯被定义成与任何底层硬件无关。

VFB的功能由明确定义的通讯模式来提供。

服务和通讯协议由基础软件实现。

就如编程语言的标准库为用户增加扩展功能一样，AUTOSAR服务为VFB用户提供扩展功能。

为了重复使用所有AUTOSAR构件的扩展功能，AUTOSAR服务接口必须标准化。

从VFB的角度来看，AUTOSAR构件端口、复杂设备驱动、ECU抽象和AUTOSAR服务是连在一起的。

复杂设备驱动、ECU抽象和AUTOSAR服务是基础软件的一部分。

AUTOSAR服务的接口是标准化的，而负责设备驱动和ECU抽象与ECU特征有关。

连接到虚拟功能总线的软件元构件和AUTOSAR服务示意图

2.2、构件、端口和AUTOSAR接口

构件是AUTOSAR的核心结构元件。

构件具有明确定义的端口，构件通过这些端口与其它构件互联。

一个端口明确归属于一个构件。

AUTOSAR接口概念定义了构件端口所提供或所需要的服务或数据。

AUTOSAR接口既可以是一个客户端－服务器接口（定义了一系列可能涉及的操作），也可以是发送端－接收端接口（允许使用通过VFB的面向数据的通讯机制）。

一个端口可以是PPort或RPort。

PPort提供AUTOSAR接口，而RPort则需要AUTOSAR接口。

当一个构件的Pport端口提供接口时，此端口所属的构件提供在客户端－服务器接口中的操作的实现，（构件）并各自产生在面向数据的发送端－接收端接口中描述的数据。

当构件的Rport需要一个AUTOSAR接口时，此构件能调用操作（接口是客户端－服务器接口），也能读取发送端－接收端接口描述的数据元素。

2.3、通讯

客户端－服务器模式通讯

在分布式系统中广泛应用的通讯模式是客户端－服务器模式，在此模式中服务器提供服务，客户端使用服务。

客户端初始化通讯时，请求服务器运行服务，并传送需要的参数集。

服务器等待从客户端传入的通讯请求，运行所请求的服务，并发送对该客户端请求的响应。

不管AUTOSAR软件构件是客户端还是服务器，初始化的方向过去习惯于分类。

单个构件要看软件实现的情况，既可以是客户端，也可以是服务器。

在服务器请求初始化之后，同步通讯客户端可被阻塞，异步通讯客户端不能被阻塞，直到收到服务器的响应之后。

如图显示了在虚拟功能总线视图中一个由三个软件构件组成，模拟两个连接的客户端－服务器通讯的情况。

在虚拟功能总线视图中的客户端－服务器通讯模式

在虚拟功能总线视图中异步非阻塞通讯的数据发送

发送端－接收端通讯模式

发送端－接收端通讯模式给出了一个异步信息发送解决方案，由发送端给一个或多个接收端发送信息。

发送端不会被阻塞（异步通讯），既不等待也不获取从接收端来的响应，也就是说，发送端只管提供信息，接收端自行决定何时以及如何使用此信息。

发送信息是通讯基础结构的职责。

发送端构件不知道支持AUTOSAR软件构件移植性和互换性的接收端的特性和数目。

如图举例说明了如何在AUTOSAR视图中模拟发送端－接收端通讯。

3、AUTOSAR电子控制单元软件结构

下图显示了电控单元的软件结构。

下面将描述其层次和主要元件。

AUTOSAR电控单元软件结构示意图

3.1、AUTOSAR软件

AUTOSAR软件（位于AUTOSAR运行时环境之上）由映射于ECU的AUTOSAR软件构件组成。

在AUTOSAR软件构件和软件元构件之间所有的相互作用都由AUTOSAR运行时环境引导。

AUTOSAR接口则保证AUTOSAR运行时环境周围软件元件的连通性。

AUTOSAR电控单元软件结构示意图

3.2、AUTOSAR运行时环境

在系统设计级（即在不考虑硬件情况下绘制整个系统逻辑图时）RTE充当ECU内部和ECU之间信息交换的通讯中心。

不管是使用ECU间通讯通道（比如CAN、LIN、FlexRay、MOST等）还是在ECU内部通讯，通过提供相同的接口和服务，RTE为AUTOSAR软件构件提供通讯抽象。

因为运行在RTE顶端的软件构件的通讯需求与应用有关，RTE需要剪裁，部分取决于指定ECU的生成，部分取决于配置。

因此作为结果，各个ECU之间RTE将不同。

AUTOSAR电控单元软件结构示意图

3.3、AUTOSAR基础软件

基础软件是标准化的软件层，它为AUTOSAR软件构件提供服务，是运行软件功能部件所必须的。

基础软件位于AUTOSAR运行时环境下面，并不完成任何功能工作本身。

基础软件包含ECU特定的标准的构件。

标准的构件包括：

∙服务

系统服务，比如诊断协议，NVRAM（NonVolatileRandomAccessMemory,非易失随机存储器），FLASH（闪存）和内存管理

∙通讯

通讯构架（如CAN，LIN，FlexRay…），输入/输出管理，网络管理

∙操作系统

因为AUTOSAR的目标是对所有车辆领域通用的体系结构，所以也规定了AUTOSAR操作系统的要求。

下列是一些要求的例子：

操作系统是

o静态设定和缩减；

o经得起实时性能的论证；

o提供基于优先级的时序调度；

o提供运行时的保护功能；

o可在低端控制器上运行而不需外部资源

AUTOSAR允许在基础软件构件中包含第三方的操作系统。

为了使第三方的操作系统的接口适应AUTOSAR标准，必须将其提取到AUTOSAR操作系统中。

标准的OSEK操作系统（ISO17356-3）作为AUTOSAR操作系统的基础。

∙微控制器抽象

为了避免从上层软件直接存取微控制器寄存器，硬件操作必须通过微控制器抽象层（MCAL，MicrocontrollerAbstractionlayer）。

MCAL是用来确保与基础软件构件连接的标准接口的硬件特征。

它管理微控制器外设，并提供带有与微控制器无关的数据的基础软件构件。

MCAL实现通知机制，用以支持对不同处理器发布命令、响应和信息。

除此之外，MACL还包括：

o数字输入输出（DIO）

o模拟/数字转换（ADC）

o脉宽调制器（PWM波，PWD）

oEEPROM

oFLASH

o捕获比较单元（CCU）

o看门狗

o串行外围接口

oI2C总线

ECU特定构件是：

∙ECU抽象

为了减弱上层软件与所有下层硬件的相关性，ECU抽象为任何特定ECU的电气数值提供了软件接口。

∙复杂设备驱动（CDD）

CDD允许对硬件的直接操作，特别是在资源要求严格的应用中。

AUTOSAR电控单元软件结构示意图

3.4、接口分类

在图中显示有三种不同的接口，分别是“AUTOSAR接口”，“标准AUTOSAR接口”和“标准接口”。

请注意不要把定义不同模块接口分类的方框，也就是图中的接口方框，看作是单独的模块或层。

这几个类别的含义如下：

∙AUTOSAR接口

一个AUTOSAR接口描述构件所需或所提供的数据和服务，接口通过AUTOSAR接口定义语言来指定和实现。

AUTOSAR接口的一部分由AUTOSAR标准化，即接口包含原始设备制造商的指定特征。

使用AUTOSAR接口可以使软件构件在几个ECU中分布。

ECU的RTE将维护软件构件分布的透明性（开放性）。

∙标准AUTOSAR接口

标准AUTOSAR接口是由AUTOSAR项目实现标准化。

∙标准接口

如果存在一个具体的标准API（ApplicationProgrammingInterface应用编程接口，比如OSEK通讯接口），则软件接口称为标准接口。

AUTOSAR电控单元软件结构示意图

4、AUTOSAR方法

图1显示了用AUTOSAR方法建立系统的设计步骤。

请注意这是一个信息流，不是一个文档说明。

术语描述如下：

∙系统配置描述：

包括所有系统信息和不同ECU间必须认可的信息。

∙系统配置提取器：

从系统配置描述中提取指定ECU所需信息。

∙ECU提取物：

指定ECU所需的来自系统配置描述的信息。

∙ECU配置描述：

指定ECU本地的所有信息。

图AUTOSAR方法