Autosar_RTE基础概念整理

Autosar_RTE

1.Runnables:可运行实体,被定义位由相应软件组件给出并且由RTE执行的最小代码片段或者指令片段

1.1.应用层中SW-C的类型
(1)传感器/执行器软件组件
(2)复合软件组件
(3)应用软件组件
(4)校准参数组件

1.2 AUTOSAR 虚拟功能总线VFB接口
RTE:运行时环境,是VFB接口特定于某个ECU的具体实现

  1. IPO模型:输入处理输出
    软件组件:应用SWC组件和传感器执行器组件
    2.1 一个SWC包含以下各项
    端口
    内部的具体实现行为Internal Behavior,描述SWC的具体行为
    RunnableEntities 运行实体实际上就是一个函数,由这个SWC提供
    RTEEvents:可以触发RunnableEntities的运行
    Timing Event:设置Timing Event,Runnable Event会周期的触发执行,Runnable会被映射到Os task,因为Os Task可能有多个Runnables
    OperationInvokedEvent
    DataReceivedEvent
    2.2 创建软件组件
    类型设计和实列化->多重实列化
    软件组件的类型
    原子软件组件
    复和组件

  2. 3.1 通过VFB,RTE支持两种基本的通信方式
    Client-Server:提供函数调用
    Sender_Receiver:提供信息传递,SWC配置相应的端口来提供两种demo
    Intra-Partition 进一步包括认为内和任务间,前者用于映射到同一操作系统任务的组件,而在后者中映射到不同的任务
    分区间通信发生在属于不同分区但位于同一ECU中的组件之间,因此跨域内存隔离边界
    最后ECU间的通信通常发送在不同的ECU间,并且涉及通过车辆总线进行传输,因此本质上是并发且不可靠的
    3.2 SR和CS的接口
    Sender/Receiver introduction:发送者-接收者通信:
    隐式数据读取访问:接收器可以运行访问数据副本,该副本在接收器执行期间将保持不变
    显示数据读取访问:允许可运行的接收器执行启用轮询行为的非阻塞API调用。在这种模式下,接收者需要明确的请求数据才能接收他
    wake up for wait point:与显示访问类似,允许可运行的接收器显示请求数据,但是不是使用非阻塞API调用而是使用阻塞调用,一旦数据可用,调用就会返回
    RTE在新数据到达的时候自动调用接收器可运行实体的可运行实体的激活,然后为了访问新到达的数据,接收者需要使用隐式或者显示数据读取访问
    3.3 SR通信方式
    一对一或者一对多的通信方式
    Explicit方式
    当调用显性发送和接收的API后,数据的接收和发送会立即发生
    RTE直接访问数据
    适用于是实现要求高的

<think>嗯,用户想了解AUTOSAR RTE层的功能与特性,我需要先整理一下相关的知识点。根据提供的引用内容,RTE层是AUTOSAR架构的核心,负责实现虚拟功能总线(VFB)。首先,我应该从基本概念入手,解释RTE是什么,它在整个ECU架构中的位置和作用。 然后,用户可能需要知道RTE的具体功能。根据引用[2],RTE与COM、OS等模块协作,实现组件间通信。需要详细说明通信机制,比如端口和接口的作用,以及SWC之间的交互方式。此外,引用[3]提到RTE负责触发和调用runnable,这部分需要展开,说明RTE如何管理runnable的执行,包括周期触发和事件触发。 接下来是特性部分,应该强调标准化接口、虚拟化通信、运行时调度和资源管理。这些特性帮助实现软硬件解耦,提升系统的模块化和可移植性。需要结合引用中的信息,说明RTE如何隔离硬件依赖,支持不同厂商的组件集成。 用户可能还想知道RTE的优势和应用场景,比如在汽车电子中的实际应用,如何简化开发流程。这部分可以引用提到的VFB概念,说明RTE如何作为中间件促进组件通信。 最后,生成的相关问题需要考虑用户可能进一步想了解的内容,比如RTE与COM的关系,设计时的注意事项,以及如何实现runnable的触发机制。这些问题需要覆盖技术细节和实际应用,帮助用户深入理解RTE层。</think>### AUTOSAR RTE层的功能与特性介绍 #### 一、**RTE层的核心功能** 1. **实现虚拟功能总线(VFB)** RTE(Runtime Environment,运行时环境)是AUTOSAR架构中实现VFB的核心模块。VFB通过抽象化硬件和通信细节,使不同软件组件(SWC)能够以统一的方式交互[^2]。例如,传感器组件与控制器组件通过RTE的接口通信,无需关注底层硬件差异。 2. **组件间通信管理** - **端口与接口标准化**:SWC通过`Port`(端口)定义输入/输出行为,RTE负责将端口映射到具体的通信协议(如CAN、LIN)或服务(如AUTOSAR COM)[^1]。 - **数据与事件传输**:支持同步/异步通信,例如周期性的信号传递(如车速信号)或事件触发(如故障报警)。 3. **Runnable的调度与触发** Runnable(可运行实体)是SWC中的最小执行单元,RTE根据以下条件触发其执行: - **周期触发**:如每10ms执行一次传感器数据采集。 - **事件触发**:如接收到特定消息后触发控制逻辑[^3]。 ```c /* 示例:Runnable通过RTE事件触发 */ Rte_Receive_CAN_Msg(&data); // 从RTE接收CAN数据 if (data.error_flag) { Rte_Send_Error_Event(); // 通过RTE发送事件 } ``` 4. **资源管理** RTE为SWC提供对BSW(基础软件)模块的访问接口,例如调用`NvM`(非易失性存储管理器)读写数据,或通过`OS`(操作系统)管理任务调度。 --- #### 二、**RTE层的核心特性** 1. **标准化接口** RTE通过ARXML(AUTOSAR XML)定义SWC接口与通信关系,确保不同供应商的组件可无缝集成。例如,制动控制组件与电机控制组件的接口协议在ARXML中统一描述。 2. **虚拟化通信机制** SWC之间的通信完全基于逻辑连接(如`Sender-Receiver`或`Client-Server`模式),RTE负责将其映射到物理总线或进程内通信。例如: $$ \text{SWC_A} \xrightarrow[\text{VFB}]{\text{逻辑信号}} \text{SWC_B} \xrightarrow[\text{RTE}]{\text{映射}} \text{CAN总线} $$ 3. **运行时动态调度** RTE与OS协同实现任务调度,支持多核ECU的并行执行。例如,高优先级的制动任务可抢占低优先级的空调控制任务。 4. **硬件抽象与解耦** SWC通过RTE访问硬件资源(如ADC模块),避免直接依赖具体硬件。更换硬件时,仅需修改RTE配置,无需重构SWC代码。 --- #### 三、**RTE的优势与应用场景** - **优势**: - 提升软件复用性(如同一雷达算法可部署到不同ECU)。 - 简化集成测试(通过VFB模拟组件交互)。 - **典型应用**: - 新能源汽车的电池管理系统(BMS)中,多个SWC通过RTE共享电压/温度数据。 - 自动驾驶系统中,感知模块与规划模块通过RTE传递障碍物信息。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

Sumerking

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

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

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

打赏作者

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

抵扣说明:

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

余额充值