什么是AutoSar - 实时运行环境层

上一篇介绍了 AutoSar 的来历，以及其中最底层的 BSW 层：啥是AutoSar，AutoSar是啥？

这一篇文章聊聊 --?实时运行环境层

关于完整介绍 AutoSar 的文章可以点击文末阅读原文

RTE(Run-Time Environment)?是 AutoSar的 ECU架构的核心。它实现了AutoSar VFB(Virtual Functional Bus)的接口，通过AutoSar 提供的基础服务，使得上层应用之间能够进行通信。并充当上层应用访问操作系统和BSW层的中间层。

RTE可以在逻辑上分为两个部件：上层应用的调度，上层应用之间的通信。

这和操作系统是一个逻辑。

RTE为不同的上层应用之间的通信提供了不同的范例：

sender-receiver(消息传递)

client-server（函数调用）

mode switch（模式切换）

每个通信范例都可以应用到intra-task software component分发、inter-partition software component分发、inter-ECU software component转发。

VFB

Virtual Functional Bus(虚拟功能总线)，在AutoSar中，应用都是互联组件的组成。

在以整车为系统设计时，每个组件会被映射到了特定的ECU，这样就会出现有些组件在不同的ECU内。

这时组件之间的虚拟连接会出现两种情况，被映射到本地连接（同一个ECU内），或者通过网络技术特定的通信机制（例如CAN或FlexRay），映射到不同的ECU上。

VFB 的作用，就是给应用层屏蔽这些通信差异，让应用组件设计时，只感知端口即可。

也就是说，每个应用组件可能在同一个ECU中实现，也可能跨越多个ECU，那么就分成两种通信接口，又出现不同情况了，怎么办呢？

加中间层，都虚拟成对端口的通信，上层只认端口，不认ECU。

从下图可以看出，实际上在VFB上面把所有SWC都独立出来，我猜这也是为了方便硬件设计的灵活性。

PortPrototype

AutoSar 规范了软件组件的端口，根据输入/输出方向可分为：

需型端口（Require Port，RPort），用于从其他软件组件获取所需数据或者请求的操作；供型端口（Provide Port，PPort），用于对外提供某种数据或者某类操作；供需端口（Provide and Require Port，PRPort），兼有需型与供型两种端口的特性。

所谓的供需，可以理解为发送和接受，P 是发送者，R 是接受者。由于端口仅仅定义了方向，在 AutoSar 中，端口的属性则用端口接口（Port Interface）来表征。

那么，在端口接口类型上主要有以下几种类型：

发送者–接收者接口（Sender–Receiver?Interface）；

客户端–服务器接口（Client–Server?Interface）；

模式转换接口（Mode Switch?Interface）；

非易失性数据接口（Non-volatile Data?Interface）；

参数接口（Parameter?Interface）；

触发接口（Trigger?Interface）；

以上端口接口类型中，最为常用的端口接口是发送者–接收者接口（Sender–Receiver Interface）和客户端–服务器接口（Client–Server Interface）。

下面就拿这两个常用的端口接口来做进一步的了解。

对于发送者–接收者接口（Sender–Receiver Interface），其主要用于数据的传递，即可以一对多发，也可以多对一发。

该类型接口中定义了一系列的数据元素（Data Element，DE），并且彼此相互独立。如下图所示，该SR接口中定义了两个数据元素，名字为DE1和DE2，并且每个数据元素的数据类型各不相同。

需要说明的是，一个软件组件的多个需型端口、供型端口、供需端口可以引用同一个发送者–接收者接口，并且它们可以使用该接口中所定义的任意一个或者多个数据元素，而不一定使用所有数据元素。

也就是说，对于一个接收者来说，它可以接收任意一个发送者端口中的任意个元素数据。这本质是上就是一个灵活的数据交换通道，非常类似于 CANOpen 中的 PDO 数据包格式，只需要配置好，就可以从通道上拿到自己想要的数据。

对于客户端–服务器接口（Client–Server Interface），其主要用于操作（Operation，OP）即函数调用关系，服务器是操作的提供者，多个客户端可以调用同一个操作，但同一客户端不能调用多个操作。

客户端（Client）主动发起一个请求（Request），然后等待服务器（Server）处理并返回一个响应（Response）。这是一个典型的请求-应答模式。

客户端–服务器接口定义了一系列操作函数，它们由引用该接口的供型端口所在的软件组件来实现，并提供给引用该接口的需型端口所在的软件组件调用。

下图展示了客户端–服务器接口定义的两个操作OP1和OP2，并对每个操作都定义了相关参数和方向，即函数的形参。

这里有一个注意的点，每一个端口只能被配置为一种端口类型，要么是发送接收模型，要么是服务客户模型，并且只有相同类型的端口才能通信。

端口的具体例子

我们以一个简单的汽车功能为例：控制车内阅读灯。

一个灯光控制器软件组件（LightControllerSWC）：负责最终执行灯光的打开和关闭。多个用户请求软件组件，例如：

车门软件组件（DoorSWC）：车门打开时，请求打开阅读灯。

顶棚开关软件组件（OverheadSwitchSWC）：用户手动按下开关，请求打开或关闭阅读灯。

车身域控制器（BCM）：根据延时设置，请求关闭阅读灯。

我们看看使用 Sender-Receiver (SR) 接口

接口定义：ILightStatus_IF

数据元素 (DE):DE_LightOnOffRequest

• • :

boolean

• • (True=开, False=关)

DE_LightDimmingLevel

• • :

uint8

• • (0-100% 调光等级)

端口配置：DoorSWC有一个?Sender端口?P_DoorStatus，引用?ILightStatus_IF接口。当车门打开时，它发送?DE_LightOnOffRequest?=?True。它不关心谁会收到这个信号。OverheadSwitchSWC有一个?Sender端口?P_SwitchStatus，引用?ILightStatus_IF接口。当用户按下开关，它发送?DE_LightOnOffRequest（在True/False间切换）。LightControllerSWC有一个?Receiver端口?P_LightCommand，引用?ILightStatus_IF接口。它被配置为接收来自?P_DoorStatus和?P_SwitchStatus的?DE_LightOnOffRequest数据。它只关心“开关”这个数据，不关心“调光等级”，所以它只接收它需要的数据元素。数据流：

多个Sender -> 一个Receiver。LightControllerSWC会收到来自不同发送者的开关请求，它需要实现一些逻辑（例如：优先级仲裁）来决定最终执行哪个命令。

SR接口的本质：传递状态信息。就像在车上贴了一张便签（数据），谁需要看谁就去看一眼。发送者只负责贴便签，不负责确保有人看到。

再来看看 Client-Server (CS) 接口

接口定义：ILightControl_IF

操作 (OP) :OP_SetOnOff(IN?OnOff:?boolean): 无返回值。命令灯打开或关闭。

OP_SetDimmingLevel(IN?Level:?uint8): 返回?E_STATUS（成功/失败）。命令灯设置到特定亮度。

端口配置 ：LightControllerSWC是服务的提供者，它有一个?Server端口?P_LightServer，引用?ILightControl_IF接口。它内部实现了?OP_SetOnOff和?OP_SetDimmingLevel这两个函数的具体逻辑（如驱动芯片、控制PWM输出等）。刚刚的DoorSWC,?OverheadSwitchSWC, 以及BCM都是服务的消费者，它们各自有一个?Client端口?（P_DoorClient,?P_SwitchClient,?P_BCMClient），都引用?ILightControl_IF。

操作流 ：车门打开时，DoorSWC通过它的Client端口调用?OP_SetOnOff(True)。这个调用请求被发送到?LightControllerSWC的Server端口。LightControllerSWC执行该操作，打开灯，然后流程结束（无返回值）。

用户操作顶棚开关时，OverheadSwitchSWC通过它的Client端口调用?OP_SetDimmingLevel(50)，请求设置50%的亮度。LightControllerSWC执行操作，尝试设置亮度，然后返回一个状态码（如?E_OK）给?OverheadSwitchSWC。

CS接口的本质：执行远程命令。就像你（Client）打电话（调用）给餐厅（Server）点餐（操作），餐厅告诉你餐已做好（响应）。这是一个有明确交互和应答的过程。

如果做过 CANOpen，发现他们如出一辙，放在我们普通的通信中理解也很容易，这里就等于为不同的 SWC 组件建立了两种联系。

Component组件

Autosar中，在VFB 级构建系统时使用的中心结构元素是“组件”，Application就是由一个个组件组成。

组件有定义良好的“端口”，通过这些端口，该组件可以与其它组件交互。一个端口总是只属于一个组件，并表示一个组件与其他组件之间的交互点。

组件可以有多个端口，如下图，显示了一个“座椅加热控制”的组件类型的定义示例，该组件类型基于几个信息源控制座位上的加热元件。

在上图中，组件类型需要以下信息作为输入：

乘客是否坐在座位上（通过端口“SeatSwitch”，S/R端口）座位温度刻度盘的设置（通过端口“Setting”，C/S端口）来自中央电源管理系统的一些信息（通过端口“PowerManagement”，S/R端口），这个系统可以在某些条件下禁用座位加热。

这个组件控制着如下信息：

与座椅温度相关的LED仪表盘。（通过端口“DialLED”，S/R端口）加热电子元件（通过端口“HeatingElement”，C/S端口）

最后，组件可以校准（通过端口“Calibration”），需要组件运行所在ECU的状态（端口“ECU Mode”），并访问本地非易失存储器（“端口nv”）。

对于组件，Autosar还支持组件的多次实例化，比如可以把座椅加热组件，实例化为左前座椅加热，右前座椅加热，这里就非常具有面向对象编程中类的意思了，他方便我们定义一种组件，然后在实例化多个继承的子组件，我想，子组件肯定支持新增端口，来让不同的子组件可以实现独特功能。

Composition与原子组件

一个由多个组件和连接器组成的子系统被打包成一个“组合”。

构成组合的组件，被称作原型。一个组合本身就是一个组件类型，可以有自己的端口。组合可以作为结构元素来构建任意数量的层次系统。

以上类比我们在 AD 中画原理图时的多层级绘图机制，不能说完全相同，简直是一模一样。

如下图，描述了组合“座椅加热控制与驱动”的定义。

这一组合包含三个原型:

原型“SHDial”(组件类型“加热刻度盘”)原型“SHC”(组件类型“座椅加热控制”)原型“SH”(组件类型“座椅加热”)

该组合本身是一个组件类型，有6个端口。

在AUTOSAR中，组件类型要么是“组合”，要么是“原子”。组合是通过相互连接的原子组件来定义的。原子组件不能进一步分解为更小的组件。

不得不说，这个 AutoSar 还是非常复杂的一套系统，希望汽车这个行业能一直持续发展下去，不然把很多工程师练就了 AutoSar 上层应用的能力，在转行也是有点费劲，里外都是门槛。