RTE(Run-Time Environment)是AUTOSAR体系结构的核心。RTE在AUTOSAR软件架构中介于应用层和基础软件层之间，是AUTOSAR虚拟功能总线(VFB)接口的实现，从而为应用软件（Application Software）组件之间的通信提供基础设施服务，并促进对包括OS在内的基础软件(Basic Software)组件的访问。
应用软件组件包含的系统软件是与CPU和位置相关的。这就意味着，受系统设计人员施加的约束，应用程序软件组件可以在系统配置期间映射到任何可用的ECU。RTE负责确保组件能够通信，并且无论在哪里映射组件，系统都能按预期继续工作。RTE包含系统基础设施的可变元素，这些可变元素来自于组件到ECU的不同映射以及标准化的RTE服务。每个ECU生成和配置RTE，来确保RTE是ECU的最佳选择。
上面说了这么多，具象地描述下这个过程。如下图，可以将RTE理解成AUTOSAR架构中的服务员角色。它是来沟通、交互不同SW-C之间，以及SW-C与BSW之间信息的传递者。
需要解释个名词：Runnables。它是可运行实体(Runnable entities)的缩写，SWC的一部分，可以包含实际实现的函数，具体逻辑算法或者可执行操作内容，由RTE周期性或事件触发调用。概括地看RTE包含以下内容：
‰ RTE需要配置(e.g. 把runnables对应到OS的tasks中去)
‰ 通过RTE的事件触发runnables的运行
‰ 生成调用runnables的task代码
‰ 配置OS的一部分 (tasks, events, alarms)
‰ 实现SWC之间的通信
‰ 每个ECU的RTE因SWC的需求而异
‰ RTE抽象了OS，防止SWC直接访问OS和BSW
SWCs与runnables之间的调用和实现过程大致如下：
从上图的调度过程可以看出，与传统ECU进程函数调度不同，AUTOSAR通过RTE，将OS抽象出来了，SWC不会直接访问OS或BSW，均通过RTE来实现，以此解耦不同应用策略对ECU平台的依赖。当然，ECU的RTE也会由于SWC功能需求的不同而存在差异。
那么，RTE对于Runnables的触发条件有哪些呢？主要有以下几种：
‰ 定时时间
周期性触发 (例如使用OS的Alarm)
‰ 数据接收事件(S/R)
当收到数据时触发
‰ 异步服务调用返回事件(C/S)
‰ 操作调用事件(C/S)
‰ 数据接收错误事件(S/R)
‰ 数据发送完成事件(S/R)
‰ 状态切换事件
RTE作为SWC和BSW之间的通信机构，多了几个不同端口的概念：
‰ Sender-Receiver
‰ Client-Server
‰ Intra-ECU and Inter-ECU (via COM)
‰ RTE implements callbacks of AR-COM
具体这几个端口的概念和应用，后续有机会展开介绍。可以这么理解，Sender-Receiver：当成一个global变量的读写；Client-Server：就是一个function call。另外，除了上面几个接口外，保证数据一致性(e.g. exclusive area)，支持简单数据及复杂数据(records)和SWC多途径应用在RTE中也扮演着很重要的角色。
Sender-Receiver:
Client-Server:
SWC内部通信:
RTE中还有个重要的概念就是每个层级交互的接口模块Interfaces。
Interfaces：
Standardized Interface：
AUTOSAR Interface：
Standardized AUTOSAR Interface：
最后，还有RTE的生成器。
RTE生成器是基于ECU配置描述中的信息为ECU创建AUTOSAR VFB总线的一组工具。RTE生成器负责创建AUTOSAR软件API函数：将AUTOSAR软件组件链接到操作系统的组件，并管理AUTOSAR软件组件之间、AUTOSAR软件组件与BSW的通信。
RTE是AUTOSAR体系结构的核心，其中很多元素都可以展开来说，篇幅限制，后续有机会将针对各个部分分别介绍，今天就overview地介绍到这里，欢迎大家后台留言沟通交流。
作者简介：
Demu，传统汽车电控向智能驾驶转变的汽车人。从事发动机控制器系统工程师和软件工程师多年，有丰富的ECU系统和软件设计经验。欢迎大家一起留言交流，共同进步。