Autosar_RTE基础概念整理

原创 已于 2025-02-27 08:05:31 修改 · 757 阅读 · 5 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-NC-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mcu #AutoSar

于 2025-02-26 14:24:52 首次发布

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直接访问数据
    适用于是实现要求高的

最低0.47元/天 解锁文章
AUTOSAR学习之RTE - 基础入门
EcmFsharp的博客
09-18 498
为了解决这个问题，AUTOSAR（Automotive Open System Architecture）联盟提出了一种标准化的软件架构，旨在帮助开发人员更好地组织和管理汽车电子系统的软件。在AUTOSAR架构中，RTE（Run-Time Environment）扮演着重要的角色，它负责处理软件组件之间的通信和调度。在主循环中，RTE轮流调用各个软件组件的运行函数（如ComponentA_Run和ComponentB_Run），并等待下一个事件的触发。如果您有更多问题，欢迎继续提问！
CP AUTOSAR标准之DiagnosticCommunicationManager(AUTOSAR_CP_SWS_DiagnosticCommunicationManager)(一)
CoolBreeze的博客
06-12 325
Dcm SWS描述了AUTOSAR基础软件模块Dcm(诊断通信管理器)的功能、API和配置。Dcm模块为诊断服务提供了通用API。Dcm模块的功能在开发、制造或服务期间由外部诊断工具使用。 外部诊断工具与车载AUTOSAR应用程序之间的通信概览Dcm模块确保诊断数据流并管理诊断状态，尤其是诊断会话和安全状态。此外，Dcm模块根据诊断状态检查诊断服务请求是否受支持以及是否可以在当前会话中执行服务。Dcm模块提供表1中的OSI层5至7：诊断协议和OSI层。
AutoSAR/RTE一个配置实例
软件领域
10-26 2211
AUTOSAR RTE的一个配置实例，有助于了解RTE配置过程。
【AUTOSAR】 项目和代码详解（三）----RTE配置
hellotzx的博客
04-27 8894
实时运行环境(RTE)是AUTOSAR ECU体系结构的核心。RTE是AUTOSAR接口的实现(对于特定的ECU)虚拟函数总线(VFB)。RTE提供基础设施服务，使AUTOSAR软件组件之间能够进行通信，并充当AUTOSAR软件组件访问包括操作系统和通信服务在内的基本软件模块的手段。
AUTOSAR方法论（RTE 运行时环境）
bill.chengzhi的博客
05-08 1493
运行时环境(RunTimeEnvironment,RTE)位于AUTOSAR软件架构的中间层，介于应用层和基础软件层之间，它实现了特定ECU上的虚拟功能总线（VFB），支持AUTOSAR的软件组件间、基础软件间、软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务，为应用层的软件组件提供标准化的基础软件和通信接口，使得应用层可以通过API函数调用基础软件的服务，例如操作系统的任务激活、等待等功能，基础软件模块管理，ECU状态管理等服务，实现了对软件生命周期的控制。除此之外，
[AutoSar]RTE运行逻辑、通信逻辑与接口实现
热门推荐
Hali_Botebie的博客
04-10 1万+
文章目录1、RTE 介绍2、具体实现1）RTE 事件触发Runnable2）通讯2.1 Sender-Receiver（S/R方式）2.2 Client-Server（C/S方式）SWC内部通信ECU和ECU之间通讯生成阶段参考 1、RTE 介绍 1）RTE是AUTOSAR虚拟功能总线（Virtual Function Bus，VFB）的接口的实现，它为应用程序软件组件之间的通信提供了基本的服务，同时也便于访问包含OS的基本软件组件 2）提供基础的通信服务，支持AUTOSAR的软件组件间、基础软件间、软件
AutoSar_Com 基础概念整理
Sumerking的博客
02-27 830
SWC–>Rte(Rte_Write)–>Com(Com_Signal)->PduR(PduR_ComTransmit)–>CanIf(CanIf_Transmit)–>CAN(Can_write)–>can仲裁胜出–>can总线。没有分配I-PDU组的I-PDU被始终处于活动状态。CAN驱动程序应该支持接收和传输具有标准ID和扩展ID的L-PDU，包括在一个硬件对象上同时接收和传输具有标准ID和扩展ID的L-PDU。当且仅当他所属的至少一个I-PDU组是活动的时候，一个I-PDU才是活动的。
AutoSar_Mode基础概念整理
Sumerking的博客
03-05 300
COM:Com中的I-PDU组的处理可以由BswM执行作为I-PDU组启动/停止的一部分，可以将包含的信号重置为其相应的初始化值，BswM处理COM中信号截止期限监视的启用和禁用，也可以触发I-PDU的传输。看门狗管理器是AUTOSAR的标准化基本软件体系结构的基本软件模块，他监控与记时约束有关的应用执行的可靠性。我们首先通过考虑应将子状态的条件信息组合成复合的状态来定义必要的状态，每个关联规则的复合状态以条件表达式的形式表示，以创建状态转换条件，并将输出与该转换条件关联。时间触发的更多非工作状态。
任务通信与管理协同之道：深入AUTOSAR_OS机制
随着汽车软件系统的日益复杂化，AUTOSAR_OS操作系统因其模块化、可配置的特点成为汽车电子领域的重要标准。本文首先概述了AUTOSAR_OS的基本架构和组成部分。接着，详细分析了其任务管理、任务间同步与通信机制，以及...
AUTOSAR学习之RTE - 基本概念
weixin_30587025的博客
08-06 1777
1.什么是RTE？ The Run-Time Environment (RTE) is at the heart of the AUTOSAR ECU architecture. The RTE is the realization (for a particular ECU) of the interfaces of the AUTOSAR Virtual Function B...
AutoSAR系列解析——RTE概览
EcmFsharp的博客
09-19 761
上述代码中，RTE_Config是RTE的配置结构体，其中的data变量用于传输数据，flag变量用于标志是否有新数据可读。在实际的AutoSAR开发中，开发者需要深入理解RTE的机制和原理，并根据具体的需求进行配置和使用。RTE是AutoSAR架构中的一个组件，它提供了一种标准的方式，使得应用软件可以在不同的ECU（Electronic Control Unit，电子控制单元）上进行分布式开发。在实际的AutoSAR开发中，开发者需要根据具体的应用场景和需求，配置合适的RTE参数和接口。
AutoSAR系列深入解析：RTE的数据一致性管理
带你成为别人眼中的大佬！
07-27 731
RTE通过定义数据传输接口、管理数据读写和数据缓冲等方式，确保了软件组件间数据的准确性和可靠性。通过数据缓冲区，RTE可以在合适的时间点进行数据的传输，从而保证数据的完整性和有效性。例如，当一个软件组件正在写入数据时，其他组件需要等待，以保证数据的一致性和正确性。这样，在不同的软件组件之间，就能按照相同的规范进行数据的读取和写入，确保数据的一致性。通过这种方式，RTE确保了在数据写入和读取过程中的一致性，防止了多个软件组件同时对数据进行访问导致的冲突和错误。获取数据写入权限，写入数据后通过。
AutoSAR系列深度解析：RTE与接口接连
带你成为别人眼中的大佬！
08-02 1338
在AutoSAR（汽车开放系统架构）中，软件组件的交互是通过服务端/客户端的通信机制实现的。为了确保这种交互的可靠性和一致性，AutoSAR引入了Runtime Environment（运行时环境），简称RTE，并定义了一套接口规范。在Sender和Receiver组件中，它们会包含对应的RTE头文件，并使用特定的宏来声明和定义接口函数。通过RTE和接口的使用，Sender组件可以向Receiver组件发送整数值，并且Receiver组件能够对接收到的整数值进行处理后返回给Sender。
AUTOSAR 运行时环境 (RTE)
2201_75514516的博客
05-21 1616
运行时环境 (RTE)也称为运行时系统，是一种执行环境，可帮助特定语言或软件运行并访问硬件。例如，JAVA 语言使用 JVM（JAVA 虚拟机）或Python使用 Python 解释器。RTE 通过抽象不同的低级分配（如函数、变量到内存映射等）来帮助程序在硬件上正确运行。RTE 还具有软件库、运行进程所使用的环境变量。RTE 主要用于高级语言。运行时环境的作用就是为程序提供一个适合执行的环境，确保它能够顺利运行，处理内存管理、任务调度、输入输出等各种操作。
AutoSAR 原理与实践：RTE 与 Interface 接口详解
weixin_50547796的博客
03-21 1567
Interace 接口定义了软件组件之间的教据交换格式和涌信规则，在 Au0SAR 中，接口可以分为两类:提供方接口(Provider nteraces)和请求方接口(Recueste Interfaces)。本文介绍了 Aut0SAR 架构中的 RTE和 interace 接口的原理和使用方法，RTE 负责管理和调度软件组件之间的通信，而lnterace 接口定义了数据交换的格式和规则，这种架构能够提供高效可靠的汽车嵌入式软件开发解决方案。注意:以上示例代码仅为演示目的，并非真实可运行的代码。
汽车电子学习笔记---AutoSAR之RTE
weixin_42399934的博客
06-23 1万+
汽车电子学习笔记—AutoSAR之RTE - 1、概念 1）RTE是AUTOSAR虚拟功能总线（Virtual Function Bus，VFB）的接口的实现，它为应用程序软件组件之间的通信提供了基本的服务，同时也便于访问包含OS的基本软件组件 2）提供基础的通信服务，支持AUTOSAR的软件组件间、基础软件间、软件组件与基础软件之间的通信 3）从逻辑上RTE可以分为两部分： - 软件组件间的通信 - 软件组件的调度 - 2、具体实现 1）RTE 事件触发Runnable AUTOSAR SWC不能
autosar RTE模块功能介绍
汽车软件开发
06-05 996
它通过标准化的接口和通信规范，实现了软件组件的解耦、复用和高效通信，为汽车电子系统的发展和创新提供了坚实的基础。RTE 模块的功能包括通信管理、信号处理、数据管理、资源管理、事件管理、诊断管理、网络管理、安全管理和系统管理等。在传统系统中，软件组件之间的通信往往是杂乱无章的，缺乏统一的标准和规范，导致系统的开发和维护困难重重。对于从事汽车电子系统开发和研究的人员来说，深入理解和掌握 RTE 的基本概念、原理和应用是至关重要的。例如，随着自动驾驶技术的发展，对 RTE 的实时性和可靠性将提出更高的要求。
RTE (Run-Time Environment)
erroror的专栏
10-22 2212
是 AUTOSAR 架构的关键组成部分，提供了软件组件间通信和调度的中间件层，使得软件组件能够独立于底层硬件进行开发。通过标准化接口和自动化工具，RTE 提高了系统的模块化、可移植性和可复用性。理解和实现 RTE 对于保证汽车电子系统的高效和可靠运行至关重要。
Autosar - 【2 RTE模块】
hammershr2012的博客
07-28 3105
AUTOSAR RTE(Run Time Environment)实现了AUTOSAR系统中的虚拟功能总线（VFB），提供了SWC(Software Component)之间的访问接口和SWC对于BSW资源的访问接口。简化的AUTOSAR架构图如下：如上图，AUTOSAR架构是分层设计的，并且其理念是将软件与硬件解耦，使得软件可以重分配和复用，这些都要依赖RTE来实现。但是RTE是不可复用的，因为RTE是匹配应用需求的，所以如果应用修改了RTE也就需要修改。
autosar下rte的代码函数构成
最新发布
06-07
<think>嗯，用户的问题聚焦在AUTOSAR中RTE的代码函数构成上。从ta的表述“可能是为了学习其架构或进行相关开发”来看，用户应该是个汽车电子领域的开发者或学习者，需要深入理解RTE的实现机制。这类技术问题通常出现在两种场景：要么是新人要系统性学习AUTOSAR架构，要么是老手在做具体开发时遇到了底层实现问题。用户引用了四份资料，但其中三份（RTE概述、事件机制、IRV）都是概念性描述，只有引用[3]涉及工具链配置参数。这说明用户可能已经掌握了基础概念，现在需要向下钻取实现层面的知识。尤其值得注意的是ta特意强调“代码函数构成”，这比单纯问“RTE如何工作”要更技术向。整理下用户可能的深层需求：1架构层面：想知道RTE如何组织各种通信函数、管理实体和接口2开发实操：可能需要手写RTE适配层或调试生成的RTE代码3性能优化：从引用[3]提到的优化模式看，ta可能关心代码生成策略用户没有明确说明开发场景，但提到“函数构成”通常会关联到内存分配和调度开销。可以补充些冷知识：RTE函数调用在单核ECU上通常5-15个时钟周期，多核会翻倍。这点虽然用户没问，但对性能敏感的开发很重要。在回答策略上要避免两个坑：第一不能简单堆砌函数名（比如只列Rte_Write_PortName这种模板），必须说明设计逻辑第二要注意AUTOSAR版本差异（用户没提版本，按惯例默认4.x）从技术储备看需要覆盖：核心函数类别（通信、调度、管理）隐藏机制（如Rte_InternalBuffer是工具生成的临时内存池）多核通信特有的路由函数优化模式的影响（速度优先时函数会内联汇编）用户引用的IRV概念是个关键切入点，可以借此展开静态数据管理函数群。另外ta上次没问但可能需要的知识点：RTE函数命名规范（venderID位置）、错误回调函数扩展方式。这些都应该在回答里埋好线索。最后用IRV当案例说明函数级交互很合适——既呼应了用户引用的[4]，又能展示数据流如何穿透多个函数。不过要控制深度，避免把简单问题复杂化。</think> 以下是针对AUTOSAR RTE代码函数构成的详细解析，结合其架构设计和运行时机制分层说明： --- ### **一、RTE代码核心构成模块** RTE的代码由工具链（如Vector/ETAS/EB）基于ARXML配置自动生成，主要包含以下函数类型： #### **1. 通信接口函数** - **端口读写操作** - `Rte_Write_<Port>_<DataElement>`：写入端口数据 *例：发送信号到其他SWC* - `Rte_Read_<Port>_<DataElement>`：读取端口数据 *例：从传感器接口获取值 [^1]* - **触发事件函数** - `Rte_Send_<Port>_<Event>`：触发发送端事件 - `Rte_Receive_<Port>_<Event>`：处理接收端事件 [^2] #### **2. 运行实体（Runnable）调度函数** - **实体映射函数** - `Rte_Start_<RunnableName>`：初始化时运行 - `Rte_Stop_<RunnableName>`：终止时执行 - **事件触发入口** - `Rte_Trigger_<RunnableName>`：时间/数据事件触发时由RTE调用 [^4] #### **3. 数据管理函数** - **跨Runnable变量（IRV）操作** - `Rte_IrvWrite_<Runnable>_<Variable>`：写入IRV - `Rte_IrvRead_<Runnable>_<Variable>`：读取IRV *注：用于SWC内部多任务间数据共享 [^4]* - **缓冲区管理** - `Rte_Buffer_<DataElement>`：管理队列式数据（如FIFO） #### **4. 系统级服务** - **多核通信路由**（如涉及多ECU） - `Rte_IocSend_<Port>`：跨核数据发送 - `Rte_IocReceive_<Port>`：跨核数据接收 [^3] - **错误处理回调** - `Rte_ErrorHook()`：超时/传输失败时调用 --- ### **二、函数实现机制** #### ▶ **代码生成逻辑** ```c /* 示例：自动生成的RTE通信函数 */ Status_t Rte_Write_PortA_SignalX(uint8 value) { if (Rte_InternalBuffer.PortA.SignalX != value) { Rte_InternalBuffer.PortA.SignalX = value; // 写缓冲区 Rte_Flag_Set(TRIGGER_RunnableB); // 设置接收方激活标志 } return RTE_E_OK; } ``` - **优化模式影响**： - `RteOptimizationMode=SPEED` → 函数内联减少调用开销 - `RteOptimizationMode=SIZE` → 复用通用函数模板 [^3] #### ▶ **与OS的交互** ```mermaid graph LR OS_Task --> Rte_Scheduler Rte_Scheduler --> |事件触发| Rte_Trigger_RunnableX Rte_Trigger_RunnableX --> SWC_RunnableX ``` - RTE通过`Rte_Scheduler()`映射Runnable到OS任务 - 事件激活时，OS调用调度器执行目标实体 [^2] --- ### **三、典型代码流程示例** **场景：周期运行实体读取传感器数据** ```c /* 由RTE自动生成的调用链 */ void Rte_Trigger_Runnable_10ms() { // 1. 读取端口数据 Rte_Read_SensorPort_Temperature(&temp); // 2. 处理IRV（跨任务数据） Rte_IrvWrite_PrevTemp(prev_temp); // 3. 调用SWC内部逻辑 SWC_ProcessData(temp); // 4. 发送结果到执行器 Rte_Write_ActuatorPort_Command(output); } ``` --- ### **四、开发注意事项** 1. **无直接OS访问** SWC只能通过RTE函数交互，禁止直接调用OS API [^2] 2. **并发安全** - IRV操作需考虑数据一致性（通常依赖RTE临界区保护） 3. **配置依赖** 函数接口由ARXML中端口/事件定义决定，修改需重新生成代码 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

Sumerking

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

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

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

打赏作者

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

抵扣说明：

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

余额充值