一文弄懂AutoSar

AutoSar是啥

AUTOSAR 由 OEM 与 Tier-1供应商联合推动，提出了统一的分层架构与接口规范，把 ECU 软件开发从“手工作坊”转变为“工业化装配”。

AUTOSAR 就是Automotive Open System Architecture的简称，是一个汽车行业的开放架构。 它将汽车电子控制单元（ECU）的软件底层做了一个标准的封装。使得大家都能共用一套底层软件，大部分情况下只需要修改其中的一些参数，就可以匹配不同硬件，也可以匹配不同的应用层软件。

早期工程师只需掌握单片机和底层驱动，而今天的整车已包含上百个 ECU、成千上万的信号交互。在这种背景下，AUTOSAR 便成了应对复杂度和保证协作可控的行业共识。对于汽车嵌入式工程师而言，掌握 AUTOSAR 已经是进入主流项目的必修课。

汽车电子正从单一 ECU 走向集中化与高度互联，软件规模和复杂度急剧膨胀，AUTOSAR 对软硬件的解耦，可以使得应用软件不依赖硬件进行开发。

它的计划目标主要有三个：一是建立分层的体系架构；二是为应用程序的开发提供方法论；三是制定各种应用接口规范。

AutoSar 架构描述

首先就能看出AutoSAR主要分为3个层级：应用软件层（AppL），实时运行环境（RTE）和基础软件层（BSW）

• 应用软件层（Application Layer）：执行用户应用层代码的地方
• 实时运行环境层（Runtime Environment）：提供应用层所需要的一些资源，同时将应用层和底层分离
• 基础软件层（Basic Software）：这一层从图中就可以看出，比其它几层都庞大，它主要是将对硬件的操作封装成统一AutoSAR标准的接口，供上层系统调用，需要将其封装到一个标准操作系统的状态才行
• 硬件层（Hardware）：由硬件工程师设计的PCBA

对于双核的处理器，也能够将应用层和底层解耦开。

AutoSAR层级

基础软件层(BSW)

基础软件层又分为四大类，分别是如下描述：

微控制器抽象层（MCAL）：就是将芯片的寄存器操作都封装成一个AutoSAR规定的统一的库API。就是说这套API是不同厂商都支持的，但是底层怎么实现，就是芯片厂商的事了。同时也有软件工具EB，可以通过界面配置MCAL功能。

没有什么问题是中间层解决不了的，如果有，那么就再加个中间层。

没错，这玩意像极了STM32的Cube，只不过ST自己做了个上位机配置软件，生成统一代码，然后它提供的各种型号的芯片的Hal库上层是一个统一的API。确切地说，这个Cube是学习的AutoSAR。

ECU抽象层：ECU层实际上是对一个PCBA板子的封装，或者说是功能模块级别的封装，如果说MCAL只封装了芯片，那么ECU抽象层就是将硬件上所有的硬件都进行了封装。

比如我们的控制器上有一个主芯片STM32，还有采样电路，电源电路，CAN电路等等。MCAL就是封装了芯片上有的外设功能。这里的ECU抽象层就是将所有的这些都做一个统一的封装，直接获取到温度，电压，电流信息。

所以，ECU抽象层要做的就是，不管硬件是如何实现的，这里封装后，也形成了统一的API，比如电流采样，不管你是基于霍尔效应的，还是通过采样电阻放大的，亦或是软件偷偷写入的，到这一层都变成了一个电流值。

确切的说，这是一个模型，一个模块的模型，不管你里面乱成什么样，你必须得两个胳膊两条腿，一个脑袋一张嘴。

服务层：这就是是更加高级的一层了，服务层里是包含操作系统的。RTOS将使用ECU抽象层的API再对上层暴露出服务接口，你看，没有什么是中间层解决不了的，刚刚ECU还是单个功能，这里直接把多个功能连在一起凑成了一个服务。

复杂驱动：又叫做CDD，主要工作是将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 规范了软件组件的端口，根据输入/输出方向可分为：

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

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

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

4. 发送者–接收者接口（Sender–Receiver Interface）；
5. 客户端–服务器接口（Client–Server Interface）；
6. 模式转换接口（Mode Switch Interface）；
7. 非易失性数据接口（Non-volatile Data Interface）；
8. 参数接口（Parameter Interface）；
9. 触发接口（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中，组件类型要么是“组合”，要么是“原子”。组合是通过相互连接的原子组件来定义的。原子组件不能进一步分解为更小的组件。