文章总结： 运行时环境RTE是AUTOSARECU体系结构的核心组成部分，作为虚拟功能总线的具体实现，为软件组件间通信提供基础服务。文章详细介绍了RTE的概念、相关AUTOSAR概念如软件组件和基础软件模块、通信样式和模式、并发性以及RTE的生成过程，包括定义阶段和生成阶段的具体步骤和配置内容。
综合评分： 75
文章分类： 应用安全,IoT安全,技术标准,解决方案
AUTOSAR学习笔记之RTE
谈思实验室
2025年12月11日 17:56
上海
点击上方蓝字谈思实验室
获取更多汽车网络安全资讯
运行时环境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和通信服务在内基础软件模块的。
01
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是最佳的。
02
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软件组件和基础软件模块。
可运行实体分为多个类别，每个类别支持不同的设备。
03
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。如下图所示：
来源：知乎@风语辰
https://zhuanlan.zhihu.com/p/99979680
谈思-汽车出海安全合规（欧洲）
交流群
谈思 AutoSec Europe 峰会旨在搭建一个能融汇全球视野与中国实践、连接技术前沿与落地应用的国际性专业平台，以助力中国汽车应对在出海过程中面临的网络与数据安全合规痛点。从前沿技术研讨、合规要点解析到经验交流，都将通过本平台为您提供持续支持。社群已超过200人，需邀请加入，如需入群，欢迎添加社群小助手微信taaslabs01。
谈思-SDV&AIDV技术出海
交流群
诚邀行业同仁加入谈思SDV&AIDV出海技术交流群，聚焦软件定义汽车、AI定义汽车、下一代EEA、智能座舱、智能驾驶、软件架构、域控制器开发、芯片技术、软件工具等核心议题，欢迎大家加群交流探讨~~社群已超过200人，需邀请加入，如需入群，欢迎添加社群小助手微信taaslabs01。
end
谈思汽车媒体门户
精品活动推荐
AutoSec系列沙龙
专业社群
部分入群专家来自：
新势力车企：
特斯拉、合众新能源-哪吒、理想、极氪、小米、宾理汽车、极越、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯……
外资传统主流车企代表:
大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚……
内资传统主流车企：
吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用……
全球领先一级供应商：
博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、赢彻科技、潍柴集团、地平线、紫光同芯、字节跳动、……
二级供应商(500+以上)：
Upstream、ETAS、BlackDuck、NXP、TUV、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信大捷安、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、加特兰微电子、浙江大学……
人员占比
公司类型占比
文章
不要错过哦，这可能是汽车网络安全产业最大的专属社区！
首发!小米雷军两会上就汽车数据安全问题建言：关于构建完善汽车数据安全管理体系的建议
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：谈思实验室 《AUTOSAR学习笔记之RTE》