[AUTOSAR 基础入门] - RTE虚拟总线详解

文章目录

- 一、什么是RTE
- 二、RTE的作用
- 三、RTE对Runnables的运行支撑
- 四、RTE与通信
- - 4.1. RTE – ECU之间通信
  - 4.2. RTE - Sender/Receiver 通信
  - - 4.2.1 不使用队列（直接访问）
    - 4.2.2 不使用队列（缓存访问）
    - 4.2.3 使用队列
  - 4.3 RTE - Client/Server 通信
  - 4.4 RTE - SWC内部通信
- 五、RTE对数据一致性的管理
- - 5.1. 数据一致性的概念
  - 5.2. 数据一致性的实现机制
- 六、RTE与Interface接口
- 七、RTE生成

返回总目录

在这里插入图片描述

一、什么是RTE

在这里插入图片描述
在 AUTOSAR 架构中，RTE（Runtime Environment）的作用如下：
RTE 类似于餐厅服务员，它在系统中起到桥接作用，负责协调应用层软件组件（好比顾客）与 ECU 中的不同模块（如账台、厨房、清洁工等）之间的信息流转。同时，RTE 也是软件组件（SWC）之间以及 SWC 与基础软件（BSW）之间的中介，像 SWC1、SWC2、SWCn 等不同软件组件通过它进行通信与协作。它具备输入输出管理、通信管理、任务调度和访问底层基础软件等功能，保障系统运行的标准化与模块化。

二、RTE的作用

RTE（运行时环境）具备多方面的功能与特点，它能提供跨ECU以及ECU内部的通信管理，还拥有对runnable的管理功能，像触发、唤醒等，runnable映射到Task上运行就是由它具体实现的。

在这里插入图片描述

RTE通过抽象和接口连接软件组件与底层基础硬件，实现应用软件与硬件平台的分离，像 SWC1、SWC2、SWCn 等软件组件会通过它连接到系统的I/O模块、服务模块、通信栈和操作系统（OS），且它通过硬件抽象层与通信栈支持CAN、LIN、FlexRay等通信协议，借助操作系统实现任务调度和管理。同时，RTE作为中间层屏蔽了硬件细节，提供标准化接口，让软件开发更高效、灵活，保障了软件的可移植性和平台独立性。

RTE是虚拟功能总线（VFB）的具体实现，在Vector的工具链中，它是自动生成的。对相关图示细化后可看清其关联关系，RTE统一管理，具体连接方式不用在RTE中关心，只要应用层配置好，它就会自动生成。

三、RTE对Runnables的运行支撑

RTE的配置需要将软件组件中的可运行实体runnables映射到操作系统的任务task中。
RTE通过事件机制触发runnables的执行，并自动生成调用runnables的任务代码。
在配置过程中，RTE需要定义操作系统中的任务、事件和警报，确保软件组件之间的通信。每个ECU中的RTE配置会根据不同的软件组件需求进行调整。
RTE抽象了操作系统，防止软件组件直接访问操作系统与基础软件，从而实现系统的标准化与模块化。右侧图示展示了软件组件中的runnables通过RTE触发并映射到任务执行的流程，体现了RTE在任务管理与执行中的核心作用。

在这里插入图片描述
SWC（Software Component软件组件）中的runnables通过RTE与操作系统、ECU管理模块和通信模块进行交互。RTE负责任务调度、通信管理以及资源调用，确保SWC的功能执行与数据传输。图中展示了SWC内部的runnable如何与RTE交互，并通过RTE调用操作系统的功能，例如SetRelAlarm、ActivateTask等任务调度接口。SWC通过COM模块实现通信回调函数，通过ECU管理模块实现RTE的启动与停止功能。RTE作为桥梁，连接了应用层的软件组件与底层系统资源，保证了系统的高效运行和功能协同。

在这里插入图片描述
Runnables的触发条件

定时时间
周期性触发 (例如使用OS的Alarm)
数据接收事件(S/R)
当收到数据时触发
异步服务调用返回事件(C/S)
操作调用事件(C/S)
数据接收错误事件(S/R)
数据发送完成事件(S/R)
状态切换事件

在这里插入图片描述

四、RTE与通信

4.1. RTE – ECU之间通信

RTE实现了ECU之间的软件组件通信，具体通过Sender-Receiver机制进行。左侧的ECU 1包含SWC 1与Runnable，通过RTE和BSW通信栈完成数据发送，而右侧ECU 2的SWC 2接收数据。发送端通过Rte_Write函数进行数据写入，而接收端通过Rte_Read函数完成数据读取。此外，BSW中的通信栈通过Com_SendSignal和Com_ReceiveSignal函数进行信号传输，保证数据在ECU之间的正确传递。

在这里插入图片描述

4.2. RTE - Sender/Receiver 通信

4.2.1 不使用队列（直接访问）

RTE在Sender-Receiver通信中提供直接数据访问的机制，即Last is Best原则。RTE可以直接访问数据地址，实现1:n通信，初始值即为默认值，适用于对实时性要求较高的数据。通过Rte_Read和Rte_Write 接口提供数据读写功能，同时简化了系统的通信流程。直接访问机制的优势在于数据的实时传输，减少了传输延迟。

Std_ReturnType Rte_Read_<p>_<d> (OUT <DataType> *data)  
Std_ReturnType Rte_Write_<p>_<d> (IN <DataType> data)

在这里插入图片描述

4.2.2 不使用队列（缓存访问）

RTE在进入runnable之前为数据建立副本，runnable运行结束后将副本数据拷贝回实际数据地址。在runnable运行过程中，操作的仅是数据副本，而不会影响实际数据。这种方式适用于数据一致性要求较高的场景，防止数据竞争和不一致问题的发生。Rte_IRead 和 Rte_IWrite 接口提供了数据的读写功能，同时确保数据访问的安全性和一致性。

<DataType> Rte_IRead_<r>_<p>_<d> (void)
void Rte_IWrite_<r>_<p>_<d> (IN <DataType> data)

在这里插入图片描述

4.2.3 使用队列

RTE在使用队列的情况下提供事件触发的Sender-Receiver通信，适用于需要数据排队的场景。RTE通过查询接收或等待接收的方式从队列中读取数据，并提供超时处理机制，保证数据传输的可靠性。通过Rte_Receive 和 Rte_Send 接口，Sender端负责数据发送，Receiver端从队列中获取数据。队列机制确保了数据按顺序传输，适用于有数据缓存需求的应用场景。

Std_ReturnType Rte_Receive_<p>_<d> (OUT <DataType> *data)  
Std_ReturnType Rte_Send_<p>_<d> (IN <DataType> data)

在这里插入图片描述
在 AUTOSAR RTE 的 Sender/Receiver 通信机制中，“无效数据元素” 起着重要作用。它主要应用于表示 sensor 发送的数据无效这一情况。需要注意的是，对于无效数据元素，不能使用队列来进行处理。其具有 “Invalid Value” 这一属性，可以通过Rte_Invalidate_<p><d>()函数来完成无效值的设置。

在接收方对无效值的处理方面，有多种方式。一方面，可通过回调函数 Rte_Feedback<p><d>() 来进行反馈处理；另一方面，Rte_Read<p>_<d>() 的返回值会变为 RTE_E_INVALID，以此来标识数据无效。此外，还有一种有趣的情况，那就是可以通过收到无效值来激活 runnable 的运行，这为系统的灵活运作提供了一种特殊的触发机制，使得系统在面对无效数据时能够按照预设的逻辑进行相应的处理和响应，保障了整个通信过程的稳定性和可靠性。

4.3 RTE - Client/Server 通信

在 AUTOSAR RTE 的 Client/Server 通信模式中，具有特定的通信方式和服务调用机制。通信方式采用 n:1 的模式，即多个 Client 可以与一个 Server 进行通信。

在服务调用方面，Client 会调用 Server 端的操作。Server 端 SWC（Software Component，软件组件）中的操作通常是 runnables（可运行实体）。这里的调用分为同步和异步两种方式。对于 Server 端的 runnables，存在两种情况：一种是没有分配到 Task 中，可直接被调用；另一种是分配到了 Task 中。

Std_ReturnTypeRte_Call_<p>_<o>([IN | IN/OUT | OUT <param_1>],... [IN | IN/OUT | OUT <param_n>])

例如，在一个汽车电子系统中，多个不同的功能模块（Client）可能需要获取某个传感器的数据或使用某个特定的服务（Server 提供），此时就会通过这种 Client/Server 通信方式来完成交互，保障汽车电子系统的各个部分协同工作。

在这里插入图片描述

在同步通信中，Client端会等待Server端的响应，期间处于阻塞状态，直到服务完成后才继续执行其他任务。下边的时序图展示了Client端通过RTE调用Server端的GetTime服务的过程，包括任务阻塞、信号发送和接收等步骤。Server端的runnable负责提供具体的服务功能，通过GetTime函数实现时间数据的获取，而RTE Client API通过Rte_Call接口完成服务的调用与结果传递。

在这里插入图片描述
在异步通信模式下，Client端不会停止运行，而是通过RTE提供的Rte_Result接口获取Server端的响应。Client可以采用轮询（Polling）或等待（Waiting）机制检查服务是否完成，同时支持超时处理。RTE通过接收到的响应激活Client端的runnable，实现异步操作的调度与执行。异步通信提高了系统的执行效率，确保Client端在不等待结果的情况下继续完成其他任务。

4.4 RTE - SWC内部通信

在 AUTOSAR RTE 架构下，SWC（Software Component，软件组件）内部通信面临着一个关键问题，即同一个 SWC 内运行在不同 Task 上的 runnable 之间的通信。其核心目标是保证数据一致性，确保在复杂的任务调度和数据交互过程中，数据的准确性和可靠性不受影响。为解决这一问题，提供了以下几种办法：

专用区域（Exclusive Areas）
- 保护范围：整个代码块或由 RTE 进行保护。
- 相关函数：通过Rte_Enter_()函数来实现进入专用区域的操作。当进入该区域后，能够确保在该区域内的操作不会受到其他任务的干扰，从而保障数据在特定操作过程中的一致性。
内部变量（Inter-runnable variables）
- 保护特点：仅对变量进行保护。
- 相关函数：使用Rte_IrvWrite__函数来处理内部变量的写入操作。这种方式专注于对变量的保护，在变量被操作时确保其数据的一致性，避免因多个 runnable 同时访问和修改而导致的数据混乱。

此外，需要注意的是，不同 SWC 之间的通信，无论是在 ECU（Electronic Control Unit，电子控制单元）内部还是 ECU 之间，都不会遇到上述 SWC 内部通信中关于数据一致性的问题，因为 RTE 会负责保证这部分数据的一致性，这体现了 AUTOSAR 架构在设计上对不同层次和场景下数据一致性保障的全面考虑和有效机制。

例如，在汽车电子系统中，某个 SWC 可能包含多个负责不同功能的 runnable，如一个负责传感器数据采集，一个负责数据处理和分析，它们运行在不同的 Task 上。当采集到的数据需要传递给处理分析的 runnable 时，就需要通过上述的 SWC 内部通信机制来确保数据在传递和处理过程中的一致性，以保障汽车电子系统的稳定运行和准确控制。下边的示意图展示了 Task A 和 Task B 与变量 X 之间的交互过程，进一步直观地说明了在不同 Task 操作下如何通过相关机制保证数据一致性的原理和流程。
在这里插入图片描述

五、RTE对数据一致性的管理

5.1. 数据一致性的概念

数据一致性指当多个用户试图同时访问一个数据库，其事务同时使用相同的数据时，可能会出现以下四种情况：丢失更新、未确定的相关性、不一致的分析和幻想读。通俗来讲，就是多个操作同时读写同一个数据时，很可能因优先级问题导致数据被篡改，出现不符合预期的数据结果。

5.2. 数据一致性的实现机制

利用 RTE 管理:通过 RTE 来管理相关数据以防止 bug 出现。例如 IRead，大家操作的是备份数据，并非直接操作原数据。
SWC 内部变量:SWC 内部变量比较特殊，能直接在 DaVinci 中配置，runnable 可直接调用，类似在 c 文件中定义的全局变量（未被 extern 出去），在 c 文件内定义的函数可直接使用它。但存在问题，同一个 c 文件中的函数可能放在不同 Task 上运行，就可能出现同一时刻运行并调用该全局变量的情况，进而导致 bug 出现。对此，AutoSAR 提供了以下两种解决方式：
- EAs（Exclusive Areas，专用区域）：通过以下两句代码实现，相当于关中断，把调用变量的语句放在中间，运行时不会有更高级的 Task 打断被保护的语句。
```
Rte_Enter_<name>();
//这里放置被保护的语句
Rte_Exit_<name>();
```
- IRVs（Inter-runnable variables，跨函数变量）：同样是两句代码，与 EAs 不同的是，EAs 是对整段代码段进行保护，而 IRVs 是在改变变量的时候进行保护，也就是这两句话执行的时候被保护，代码如下：
```
Rte_IrvWrite_<re>_<name>()
Rte_IrvRead_<re>_<name>()
```

六、RTE与Interface接口

AUTOSAR架构中，RTE处于应用软件层与基础软件层之间，起到了数据传输与接口抽象的作用。在应用软件层，包含了多个AUTOSAR软件组件（SWC），如应用软件、执行器软件和传感器软件等，这些组件通过标准化的AUTOSAR接口与RTE交互。RTE向下连接基础软件层，包括操作系统、通信栈、ECU抽象和复杂设备驱动等模块，这些模块通过标准接口提供服务与功能。

整个架构实现了软硬件的分离，通过标准化接口与模块化设计，保证了软件的可移植性和硬件的无关性。RTE作为核心中间层，统一了软件组件与底层功能之间的数据流与功能调用，提升了系统开发的标准化与高效性

在这里插入图片描述
RTE通过标准接口实现对操作系统、通信模块和ECU管理模块的功能访问，确保了软件组件与底层功能的分离与解耦。

在操作系统接口方面，RTE通过Schedule和WaitEvent等API实现任务调度与事件管理；
在通信模块接口方面，RTE通过Com_SendSignal接口管理通信回调与数据发送；
在ECU管理接口方面，RTE通过Rte_Start和Rte_Stop实现ECU的生命周期管理。

RTE通过这些标准接口，确保了上层应用软件与底层基础软件之间的高效通信与功能调用，同时提供了跨平台与模块化的开发环境。

在这里插入图片描述
RTE将I/O硬件接口与软件组件中的端口（Ports）和runnables进行标准化映射，确保了数据传输的准确性与一致性。ECU抽象层作为固件的角色，仅允许传感器和执行器软件组件访问，进一步屏蔽了硬件细节。RTE提供了标准API接口，其中Sender-Receiver模式通过Rte_Write实现数据传输，如Rte_Write_DimmLight_DimmValue，而Client-Server模式通过Rte_Call实现服务调用。

RTE标准接口的实现，使得软件组件在不同硬件平台上可以复用，并提高了接口调用的标准化与可维护性。

在这里插入图片描述

RTE通过向基础软件提供特定的服务端口（Service Ports），实现了应用软件与基础软件的标准化通信与服务访问。在接口调用方面，RTE支持软件组件通过Rte_Call访问基础服务，同时支持DEM模块的事件操作，如SetEventStatus用于设置事件状态。服务端口机制确保了RTE向基础软件提供的标准化功能接口，进一步实现了应用层与底层软件模块的高效协同与功能抽象。通过这种服务调用机制，软件组件能够在标准化的接口框架下访问基础功能，保证了系统通信的灵活性与标准化。

在这里插入图片描述