您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
AUTOSAR学习笔记之RTE
 
作者: 风语辰
   次浏览      
 2023-2-8
 
编辑推荐:
本文主要介绍了AUTOSAR中的RTE概述、RTE相关的重要AUTOSAR概念及RTE生成过程。希望对你的学习有帮助。
本文来自于知乎,由火龙果软件Linda编辑、推荐。

运行时环境RTE是AUTOSAR ECU体系结构的核心组成部分。RTE是AUTOSAR虚拟功能总线(Virtual Function Bus,VFB)的接口(针对某个特定ECU)的实现,因此,它为应用程序软件组件之间的通信提供了基本的服务,同时也便于访问包含OS的基本软件组件。

RTE和OS,AUTOSAR COM和其他的基础软件模块(BSW)是VFB(Virtual Functional Bus)概念的实现。RTE实现了AUTOSAR VFB的接口,从而实现了AUTOSAR软件组件之间的通信。

RTE是AUTOSAR ECU体系的核心,它提供了在AUTOSAR软件组件间通信的基础服务,扮演了一些方法,通过这些方法AUROSAR软件组件能访问包括OS和通信服务在内基础软件模块的。

1、AUTOSAR中的RTE概述

RTE是AUTOSAR ECU体系的核心。RTE是对特定ECU的AUTOSAR虚拟功能总线(VFB)的具体实现,支持AUTOSAR的软件组件间、基础软件间、软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务,为应用层的软件组件提供标准化的基础软件和通信接口,使得应用层可以通过API函数调用基础软件的服务。

RTE包含系统基础设施的可变元素,这些元素来自组件到ECU的映射和标准化的RTE服务。

原则上,RTE从逻辑角度可以分为两个部分实现:

(1)软件组件间的通信

(2)软件组件的调度

为了充分描述RTE的概念,还必须考虑基础软件调度程序。基础软件调度程序调度基础软件模块的可调度实体。在一些文档中,可调度实体也被称作主要处理函数。

由于同一OS任务可能用于调度软件组件和基础软件模块,因此RTE的调度部分与基础软件调度程序有着紧密的联系,不能清晰的分开。

为每个ECU生成RTE和基础软件调度程序,以确保RTE和基础软件调度程序对于ECU是最佳的。

2、RTE相关的重要AUTOSAR概念

2.1、AUTOSAR软件组件

在AUTOSAR中,应用软件架构上位于RTE的上方,由应用组件组成,应用组件中有一种特殊的应用组件就是传感器/执行器组件,这些组件依赖于ECU硬件,因此由于性能/效率原因不容易重新定位。在系统配置期间,AUTOSAR软件组件可以被部署到任何可用的ECU上。RTE负责确保组件可以通信,并且确保无论组件部署在哪,系统都能按预期工作。考虑到传感器/执行器软件组件,他们能够直接寻址本地ECU抽象层,因为需要通过一个中间传感器/执行器软件组件将信息广播给远端ECU来实现对远端ECU抽象层的访问,因为在不同的ECU上移动传感器/执行器软件组件,可能意味着也会将连接的设备(传感器/执行器)移动到相同的ECU(前提是能够有效访问)。

软件组件按类型定义。在组件被部署到一个ECU上时,组件类型会被实例化。组件类型可以在同一个ECU上实例化多次,在这种情况下,组件类型被称作“多重实例化”。RTE支持每实例一个内存段,来确保每个组件实例具有私有状态。

RTE既支持源代码可用的软件组件(源代码软件组件),又支持仅目标代码可用的软件组件(目标代码软件组件)。

2.2、基础软件模块

基础软件模块可以直接访问ECU 抽象层和其他基础软件模块,因此既不独立于ECU,也不独立于位置。

软件组件不能直接访问基础软件模块,所有的通信都通过AUTOSAR接口,因此受RTE控制。不直接访问的要求适用于所有基础软件模块,包括操作系统和通信服务。

2.3、通信

AUTOSAR软件组件的通信接口由多个端口组成。AUTOSAR软件组件可以通过它的接口与其他AUTOSAR软件组件(无论该组件位于同一个ECU或不同的ECU上)或同一ECU上的基础软件模块进行通信。此通信只能通过组件端口进行。端口可以归为两类:发送方-接收方,客户端-服务端。发送方-接收方提供消息传递功能,客户端-服务端提供函数调用。

2.3.1、通信样式

RTE为软件组件实例间的通信提供了不同的样式

(1)发送方-接收方(信号传递)

(2)客户端-服务端(功能调用)

(3)模式切换

(4)非易失性数据交互

每个通信样式都可以应用于分区内的软件组件分发(包括同一分区内的任务内和任务间分发),分区间的软件组件分发和ECU间的软件组件分发。任务内通信发生在映射到同一OS任务的可运行实体之间,而任务间通信发生在影射到同一分区的不同任务的可运行实体之间,因此涉及关联转换。分区间通信发生在影射到同一个ECU的不同分区的组件中的可运行实体之间,因此涉及关联转换和跨越保护边界(内存保护,定时保护,核心隔离)。ECU间通信发生在影射到不同ECU的组件中的可运行实体之间,本质上是冰法,并且可能涉及不可靠通信。

2.3.2、通信模式

对于发送方-接收方通信,RTE提供两种模式:

显式:组件使用显式API调用发送和接受数据元素;

隐式:RTE在调用可运行实体之前自动读取指定的一组数据元素,并且在可运行实体终止后自动写入(不同的)一组数据元素。这里使用术语“隐式”是因为可运行实体不会主动启动数据的接收和传输。

2.3.3、静态通信

RTE应仅支持静态通信。静态通信仅包括那些在生成RTE时所有通信的源和目的就已知的通信连接。由于运行时间和代码开销会限制适用RTE的设备规模,因此不支持通信的动态重新配置。

2.3.4、多重性

除了点对点通信,RTE还支持含有多个提供者或多个需求者的通信连接。

当使用发送方-接收方通信时,RTE支持1:n(即一个发送方,多个接收方),n:1(即多个发送方,一个接收方)通信,并且限制不允许多个发送方进行模式切换通知;

RTE不协调多个发送方或多个接收方的执行过程,这意味着不同软件组件的行为是独立的,RTE不确保不同发送方同时传输数据,也不确保所有接收方同时接收数据或接收事件。

当使用客户端-服务端通信时,RTE支持n:1(即多个客户端,一个服务端),不支持1:n(即一个客户端,多个服务端)。

无论使用1:1,n:1,1:n通信,RTE负责实现通信连接,因此,AUTOSAR软件组件不知道具体配置,这样就允许一个AUTOSAR软件组件在不修改的情况下重新部署到不同的配置中。

2.3.5、并发性

AUTOSAR软件组件不能直接访问操作系统,因此AUTOSAR应用层中没有任务。相反,AUTOSAR中的并发操作是基于RTE引用的组件中的可运行实体的。

AUTOSAR VFB规范将可运行实体定义为“可由RTE启动的指令序列”。一个组件提供一个或多个可运行实体,每个可运行实体只有一个入口点。入口点在提供可运行实体执行的软件组件代码中定义标记。

RTE负责调用可运行的实体-AUTOSAR软件组件无法(动态)创建私有控制线程。因此,AUTOSAR应用层中的所有活动都是由RTE触发可运行实体来发起的,作为RTE事件的结果。

RTE事件包含所有可能的情况,这些情况可以触发RTE执行可运行实体。

RTE支持任何具有AUTOSAR接口的软件组件的可运行实体,包括AUTOSAR软件组件和基础软件模块。

可运行实体分为多个类别,每个类别支持不同的设备。

3、RTE生成过程

RTE生成的主要过程是:创建与操作系统系统功能相适应的AUTOSAR软件构件API,并管理软件构件间的通信。

这些生成的代码在运行时:

(1)为软件构件分配所需的系统资源,如消息号、任务运行环境等

(2)负责具体执行软件构件间通过端口进行的通信

(3)根据软件构件描述中的信息,在适当时刻为软件构件提供事件或调度。

RTE生成包含两个阶段:

(1)定义阶段(RTE Contract phase)

(2)生成阶段(RTE Generation phase)。

在(1)定义阶段中,将软件构件和RTE交互描述信息定义为头文件,作为软件构件与RTE的契约,双方都使用相同数据结构进行编程。在此阶段,需要完成的工作是:

(1)软件构件类型描述

(2)构件内部行为描述

(3)真实源代码或目标代码及其API(头文件)生成

(4)实现语言描述

从上图中可以清晰的看到,其实定义阶段就是扫描一下Internal Behavior这个xml的标签。然后生成它的头文件。

Internal Behavior中可以包含的内容如下:

在(2)生成阶段中,将所有软件构件、相关系统和ECU信息联合起来,为每一个ECU生成一个RTE。

由上图可以看出,生成阶段之前要先收集ECU配置信息,然后进行配置,可配置的内容有:

(1)SW-Component的接口和它们的通信关系;

(2)运行体和它们的RTE-Events。

还有就是把SWC的端口映射成为COM的信号。映射的规则已经被系统配置生成器AUTOSAR System Configuration Generator所描述。

RTE生成器使用COM和操作系统已有的对象(如:task),同时也创建自己的新对象(如调度表和周期时钟)。但是如果一个对象OS已经提供,RTE就必须使用。

AUTOSAR OS被ECU配置描述文件所配置。RTE配置器/生成器需要将其需求传达给OS,因此使用相同的格式顺序似乎是明智的,以允许通信所生成的RTE所需的OS对象集。

生成的RTE所使用的OS对象(以下称为OsNeeds)的规范可以仅在配置时完成,也可以在配置和生成时混合完成,具体取决于RTE和OS的配置和生成工具所支持的方法 。 因此,可以由RTE配置编辑器或RTE生成器提供输出信息OsNeeds。

如果是操作系统特别需要的对象,就标记上OsNeed。如下图所示:

   
次浏览       
相关文章

中央计算的软件定义汽车架构设计
汽车电子控制系统中的软件开发过程
一文读懂汽车芯片-有线通信芯片
OTA在汽车上有哪些难点痛点?
相关文档

汽车设计-汽车的整体结构及动力系统
自动驾驶汽车软件计算框架
SysML在汽车领域的应用实践
电子电气架构-大陆汽车系统架构平台
相关课程

AutoSAR原理与实践
功能安全管理体系(基于ISO26262)
MBSE(基于模型的系统工程)
基于SOA的汽车电子架构设计与开发

最新活动计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]
 
 
最新文章
在EA中内嵌文档- Artifact
EA中模型视图
EA中的实体关系图
使用EA进行风险建模
EA中的项目词汇表
EA的模型导出或导入csv文件
自定义表格(Custom Table)在EA中的使用
Gap Analysis Matrix(差距分析矩阵)
更多...   
MBSE工具
MBSE平台
建模工具 EA
模型库-Model Center
需求管理-ReqManager
自动建模-Modeler
多级仿真-Sys Simulator
代码工程-Code Engineer
文档生成器-DocGenerator
更多...   
成功案例
广汽研究院 SysML+EA+软件分析设计
高合汽车研发部门 建模工具EA、WebEA、学习视频
国汽智联 建模工具EA、模型库、WebEA和iSpace
亿咖通 MBSE工程体系与工具链咨询
中航无人机 MBSE工具链
吉利汽车 购买EA工具
华科汽车零部件 购买EA工具
东风岚图汽车 购买EA工具 以及EA定制开发
更多...