初识AUTOSAR

news2025/1/11 16:56:57

应用层

Runnable

Port

运行时环境

基础软件层

总结

AUTOSAR，全称为Automotive Open System Architecture，即汽车开放系统架构。它最初于2003年由当时全球各家顶级汽车制造商（奔驰、宝马、大众等）、零部件供应商（博世、大陆、德尔福等）以及各种研究、服务机构共同参与的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（ECU）标准软件架构。行至今日，虽然AUTOSAR软件架构并非强制性行业标准，但AUTOSAR 软件标准已成为事实上的汽车电子软件开发标准，熟悉AUTOSAR软件架构、掌握AUTOSAR架构软件开发工具已成为汽车电子软件开发从业工程师的必备职业技能。

AUTOSAR的出现是为了满足日益增长的汽车电子软件开发需求，在设计上，采用分层软件架构，大大降低了软件与软件、软件与硬件之间的依赖性。

AUTOSAR软件架构图

在AUTOSAR软件架构设计中，从上至下依次为：应用层（Application Layer）、运行时环境（Runtime Environment）、基础软件层（Basic Software Layer）、微控制器（Microcontroller），每个层为相邻层提供访问接口、跨层之间不可直接访问。特别是RTE的设计，使得汽车嵌入式软件开发开发与验证，摆脱对硬件系统的依赖。这种设计的好处是显而易见的：

1. 软硬件解耦，使软件可以跨平台复用，有利于提高软件的复用度，缩短开发周期；

2. 模块化设计，使软件功能可以进行先期架构级别的定义和验证，从而减少开发错误；

3. 统一使用标准化的数据交换格式，方便车企与供应商之间的合作。

4. 引入AUTOSAR工具链，减少了手动代码量，提供软件质量；

5. 便于维护升级

接下来简单介绍下AUTOSAR架构下的每一个层及其作用。

应用层

在AUTOSAR架构下，应用层是最上层，通过RTE（Runtime Environment，运行时环境）与下层进行交互。

应用层是由多个SWC（Sotware Component）组成。每一个SWC可视为一个功能模块，不同的SWC之间通过AUTOSAR接口交互。

AUTOSAR应用层SWC之间交互示意图

一个典型的SWC由Runnable和Port组成（有人会有疑问：一个模块都没数据吗？有，但是AUTOSAR中数据一般不是由SWC维护，SWC只负责使用，特殊Pim数据除外，因此这里博主个人认为，数据结构不是一个SWC的典型组成部分），下面简单介绍下SWC的Runnable和Port。

Runnable

Runnable，可以理解为函数。由SWC创建，根据Runnable的触发类型，可分为三类：

Initial Runnable, 用于本SWC初始化函数,由SWC初始化动作触发运行；
Server Runnable, 是由一个server触发运行的函数；
Runnable，普通任务函数，由定时器触发运行；

有人喜欢将Runnable看做Task，在本质上是不太准确的。一个Task中一般会执行很多个Runnable，但是在便于理解的层面上去看，理解为Task也勉强说得通。毕竟，runnable的运行不是由普通函数调用产生，而是由定时器、初始化或事件触发，又跟我们通常理解的Task比较像。但，本质上一个Runnable就是一个函数，这点在生成代码中可以清晰看到。

Port

Port是SWC之间进行交互的接口，可分为三类：

1.Sender Ports：用于SWC发送数据到另一个SWC或RTE，可分为两种：

数据发送Port：这种Port用于发送数据；
Trigger发送Port：这种Port用于发送trigger，通常为一个代表某事件发生的信号；

2.Receiver Ports ：用于从SWC或RTE接收数据，可分为两种：

数据接收Port：用于从数据发送方接受数据；
Trigger接收Port：用于从Trigger发送方接收Trigger信号；

3.Client-Server Ports:用于client和server方，分为两种：

Client Port：用于client方发送请求到server方；
Server Port：用于server方接受client方的请求；

在AUTOSAR软件开发中，应用层SWC需要由工程师使用第三方工具设计实现，然后进行代码生成，生成具体的.c和.h文件，再有工程师完成业务逻辑代码的开发。

运行时环境

RTE是AUTOSAR软件架构的核心，但其本身并不实现任何业务逻辑。它就像一个隔离层，将应用软件和基础软件分离；又像是一个管道，一端连接应用层，一端连接基础软件，应用软件与基础软件通过它实现交互。

RTE是应用层与底层之间的一个抽象层，它负责管理通信和SWC之间的数据交互，提供如下服务：

通信管理：RTE处理不同模块间的数据传输，保证数据的一致性，同步通信时间；
资源管理：RTE管理SWC使用的资源，例如：内存、CPU时间等，保证模块可以访问它们所需的资源；
错误管理：RTE提供错误处理机制，用于处理在软件模块运行时可能发生的错误，如：数据传输错误、内存分配错误等。
时间管理：RTE管理软件模块的时间，以确保他们以同步的方式运行，这对于安全相关的应用是至关重要的。

正是由于RTE这种特性，才实现了AUTOSAR软件模块解耦，在项目开发中，应用软件开发可以脱离基础软件进行（使用模拟环境），大大提高开发效率。

基础软件层

从AUTOSAR软件架构图可以看出，基础软件（BSW）包括非常多模块。随着AUTOSAR的发展，BSW还在不断丰富。但总体自下而上又可将BSW分为四个部分：微控制器抽象层（Micro-controller Abstract Layer，MCAL ）、电子控制单元抽象层（ECU Abstract Layer）、服务层（Service Layer）和复杂驱动（Complex Driver，Cdd）

MCAL：主要是微控制器驱动，包括Dio，Port，Pwm，Spi，Can，Memory等驱动，这部分和硬件强相关；
ECU抽象层：主要是将通信、内存、IO等资源抽象成统一接口，掩盖下层硬件的不同，供上层使用；
服务层：这部分主要是提供系统服务、通信服务、内存服务等；
复杂驱动：Cdd是AUTOSAR架构中特殊的一部分，在AUTOSAR架构中，上层只能通过相邻的下层，层层递进，访问硬件资源。但通过复杂驱动，上层可以直接访问硬件资源，复杂驱动的设计主要是为了满足汽车电子软件某些时效性要求苛刻的使用场景；
微控制器虽然出现在AUTOSAR软件架构图中，但是微控制器不属于AUTOSAR软件包含的内容。

以上就是AUTOSAR软件架构的初步介绍。