详解AUTOSAR分层架构与软件组件

作者： 宋珂

来源：  汽车电子与软件

1.

AUTOSAR分层架构

AUTOSAR规范主要包括分层架构、方法论和应用接口三部分内容。其中，分层架构是实现软硬件分离的关键，它使汽车嵌入式系统控制软件开发者摆脱了以往ECU软件开发与验证时对硬件系统的依赖。

在AUTOSAR分层架构中，汽车嵌入式系统软件自上而下分别为应用软件层（Application Software Layer，ASW）、运行时环境（Runtime Environment，RTE）、基础软件层（Basic Software Layer，BSW）和微控制器（Microcontroller），如图2.3所示。为保证上层与下层的无关性，在通常情况下，每一层只能使用下一层所提供的接口，并向上一层提供相应的接口。

图2.3　AUTOSAR分层架构

1.1、AUTOSAR应用软件层

应用软件层（Application Software Layer，ASW）包含若干个软件组件（Software Component，SWC），软件组件间通过端口（Port）进行交互。每个软件组件可以包含一个或者多个运行实体（Runnable Entity，RE），运行实体中封装了相关控制算法，其可由RTE事件（RTE Event）触发。

1.2、AUTOSAR运行时环境

运行时环境（Runtime Environment，RTE）作为应用软件层与基础软件层交互的桥梁，为软硬件分离提供了可能。RTE可以实现软件组件间、基础软件间以及软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务，为应用层软件组件提供了标准化的基础软件和通信接口，使得应用层可以通过RTE接口函数调用基础软件的服务。此外，RTE抽象了ECU之间的通信，即RTE通过使用标准化的接口将其统一为软件组件之间的通信。由于RTE的实现与具体ECU相关，所以必须为每个ECU分别实现。

1.3、AUTOSAR基础软件层

基础软件层（Basic Software Layer，BSW）又可分为四层，即服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer，MCAL）和复杂驱动（Complex Drivers），如图2.4所示。

图2.4　AUTOSAR基础软件层

上述各层又由一系列基础软件组件构成，包括系统服务（System Services）、存储器服务（Memory Services）、通信服务（Communication Services）等，如图2.5所示。它们主要用于提供基础软件服务，包括标准化的系统功能和功能接口。

图2.5　AUTOSAR基础软件层结构

（1）服务层

服务层（Services Layer）提供了汽车嵌入式系统软件常用的一些服务，其可分为系统服务（System Services）、存储器服务（Memory Services）以及通信服务（Communication Services）三大部分。提供包括网络通信管理、存储管理、ECU模式管理和实时操作系统（Real Time Operating System，RTOS）等服务。除了操作系统外，服务层的软件模块都是与ECU平台无关的。

（2）ECU抽象层

ECU抽象层（ECU Abstraction Layer）包括板载设备抽象（Onboard Devices Abstraction）、存储器硬件抽象（Memory Hardware Abstraction）、通信硬件抽象（Communication Hardware Abstraction）和I/O硬件抽象（Input/Output Hardware Abstraction）。该层将ECU结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器或者I/O的访问，从而不需要考虑这些资源是由微控制器片内提供的，还是由微控制器片外设备提供的。该层与ECU平台相关，但与微控制器无关，这种无关性正是由微控制器抽象层来实现的。

（3）微控制器抽象层

微控制器抽象层（Microcontroller Abstraction Layer，MCAL）是实现不同硬件接口统一化的特殊层。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。微控制器抽象层包括微控制器驱动（Microcontroller Drivers）、存储器驱动（Memory Drivers）、通信驱动（Communication Drivers）以及I/O驱动（I/O Drivers），如图2.6所示。

图2.6　微控制器抽象层

（4）复杂驱动层

由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以在AUTOSAR规范中这部分没有被标准化，统称为复杂驱动（Complex Drivers）。

2.

AUTOSAR软件组件

软件组件（SWC）不仅仅是应用层的核心，也是一些抽象层、复杂驱动层等实现的载体。由于软件组件包含的概念较多，这里单独介绍AUTOSAR软件组件相关概念，这是后期进行应用层、抽象层等开发的基础。

AUTOSAR软件组件大体上可分为原子软件组件（Atomic SWC）和部件（Composition SWC）。其中，部件可以包含若干原子软件组件或部件。原子软件组件则可根据不同用途分为以下几种类型：

• 应用软件组件（Application SWC）；
• 传感器/执行器软件组件（Sensor/Actuator SWC）；
• 标定参数软件组件（Parameter SWC）；
• ECU抽象软件组件（ECU Abstraction SWC）；
• 复杂设备驱动软件组件（Complex Device Driver SWC）；
• 服务软件组件（Service SWC）。

应用软件组件（Application SWC）主要用于实现应用层控制算法。

传感器/执行器软件组件（Sensor/Actuator SWC）用于处理具体传感器/执行器的信号，可以直接与ECU抽象层交互。

标定参数软件组件（Parameter SWC）主要提供标定参数值。ECU抽象软件组件（ECU Abstraction SWC）提供访问ECU具体I/O的能力。该软件组件一般提供引用C/S接口的供型端口，即Server端，由其他软件组件（如传感器/执行器软件组件）的需型端口（Client端）调用。此外，ECU抽象软件组件也可以直接和一些基础软件进行交互。

复杂设备驱动软件组件（Complex Device Driver SWC）推广了ECU抽象软件组件，它可以定义端口与其他软件组件通信，还可以与ECU硬件直接交互。所以，该类软件组件灵活性最强，但由于其和应用对象强相关，从而导致其可移植性较差。

服务软件组件（Service SWC）主要用于基础软件层，可通过标准接口或标准AUTOSAR接口与其他类型的软件组件进行交互。

需要指出的是，上述这些软件组件有的仅仅是概念上的区分，从具体实现及代码生成角度而言都是相通的。下面将详细介绍AUTOSAR软件组件的几个重要概念：数据类型、端口、端口接口以及内部行为。

2.1　软件组件的数据类型

AUTOSAR规范中定义了如下三种数据类型（Data Type）：

①应用数据类型（Application Data Type，ADT）；

②实现数据类型（Implementation Data Type，IDT）；

③基础数据类型（Base Type）。

应用数据类型（Application Data Type，ADT）是在软件组件设计阶段抽象出来的数据类型，用于表征实际物理世界的量，是提供给应用层使用的，仅仅是一种功能的定义，并不生成实际代码。

实现数据类型（Implementation Data Type，IDT）是代码级别的数据类型，是对应用数据类型的具体实现；它需要引用基础数据类型（Base Type），并且还可以配置一些计算方法（Compute Method）与限制条件（Data Constaint）。

在AUTOSAR中，对于Application Data Type没有强制要求使用，用户可以直接使用Implementation Data Type。若使用了Application Data Type，则必须进行数据类型映射（Data Type Mapping），即将Application Data Type与Implementation Data Type进行映射，从而来对每个Application Data Type进行具体实现。

2.2　软件组件的端口与端口接口

软件组件的端口根据输入/输出方向可分为需型端口（Require Port，RPort）与供型端口（Provide Port，PPort），在AUTOSAR 4.1.1标准中又提出了供需端口（Provide and Require Port，PRPort）。

①需型端口：用于从其他软件组件获得所需数据或者所请求的操作。

②供型端口：用于对外提供某种数据或者某类操作。

③供需端口：兼有需型端口与供型端口的特性。

需型端口可以和供型端口连接。如图2.7所示，软件组件SWC1有一个需型端口（R）和一个供型端口（P），其中需型端口与SWC2的供型端口相连，它们之间的交互关系通过连线箭头表示，由SWC2的供型端口指向SWC1的需型端口。SWC3具有一个供需端口，它可被认为自我相连。

图2.7　AUTOSAR软件组件端口

由于端口仅仅定义了方向，所以AUTOSAR中用端口接口（Port Interface）来表征端口的属性，端口接口主要有如下几种类型：

①发送者-接收者接口（Sender-Receiver Interface，S/R）；

②客户端-服务器接口（Client-Server Interface，C/S）；

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

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

⑤参数接口（Parameter Interface）；

⑥触发接口（Trigger Interface）。

其中，最常用的端口接口是发送者-接收者接口（Sender-Receiver Interface，S/R）与客户端-服务器接口（Client-Server Interface，C/S）。如图2.8所示，软件组件SWC1具有两个端口，其中一个引用的端口接口类型为发送者-接收者（S/R）接口，另一个引用的端口接口类型为客户端-服务器（C/S）接口。从中也可以看出，对于引用发送者-接收者接口的一组端口而言，需型端口为接收者（Receiver），供型端口为发送者（Sender）。对于引用客户端-服务器接口的一组端口而言，需型端口为客户端（Client），供型端口为服务器（Server）。

图2.8　AUTOSAR软件组件端口接口

下面详细讨论发送者-接收者接口（Sender-Receiver Interface，S/R）与客户端-服务器接口（Client-Server Interface，C/S）的特性。

（1）发送者-接收者接口

发送者-接收者接口用于数据的传递关系，发送者发送数据到一个或多个接收者。该类型接口中定义了一系列的数据元素（Data Element，DE），这些数据元素之间是相互独立的。如图2.9所示，该发送者-接收者接口SR_Interface中定义了两个数据元素，名字分别为DE_1与DE_2，并且需要为每个数据元素赋予相应的数据类型。

图2.9　发送者-接收者接口定义

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

（2）客户端-服务器接口

客户端-服务器接口用于操作（Operation，OP），即函数调用关系，服务器是操作的提供者，多个客户端可以调用同一个操作，但同一个客户端不能调用多个操作。客户端-服务器接口定义了一系列操作（Operation），即函数，它（们）由引用该接口的供型端口所在的软件组件来实现，并提供给引用该接口的需型端口所在的软件组件调用。如图2.10所示，该客户端-服务器接口CS_Interface中定义了两个操作OP_1与OP_2，对于每一个操作需要定义相关参数及其方向，即函数的形参。

图2.10　客户端-服务器接口定义

需要注意的是，每个端口只能引用一种接口类型，并且引用相同端口接口类型的端口才可以进行交互。

2.3　软件组件的内部行为

软件组件的内部行为（Internal Behaviour，IB）如图2.11所示，其主要包括：

图2.11　软件组件的内部行为

①运行实体（Runnable Entity，RE）；

②运行实体的RTE事件（RTE Event）；

③运行实体与所属软件组件的端口访问（Port Access）；

④运行实体间变量（Inter Runnable Variable，IRV）。

（1）运行实体

运行实体（Runnable Entity，RE）是一段可执行的代码，其封装了一些算法。一个软件组件可以包含一个或者多个运行实体。

（2）运行实体的RTE事件

每个运行实体都会被赋予一个RTE事件（Trigger Event），即RTE事件（RTE Event），这个事件可以引发这个运行实体的执行。对于RTE事件可以细分为很多种类，这将在后续章节介绍软件组件的内部行为设计时结合工具进行介绍。较常用的RTE事件有以下几种：

①周期性（Periodic）事件，即Timing Event；

②数据接收事件（Data-received Event）；

③客户端调用服务器事件（Server-call Event）。

如图2.12所示，其中Runnable_1、Runnable_2和Runnable_3分别采用了Timing Event、Data-received Event以及Server-call Event。

图2.12　运行实体的RTE事件示意

（3）运行实体与所属软件组件的端口访问

运行实体与所属软件组件的端口访问（Port Access）是和端口所引用的端口接口类型密切相关的。

对于S/R通信模式，可分为显示（Explicit）和隐式（Implicit）两种模式。若运行实体采用显示模式的S/R通信方式，数据读写是即时的；当多个运行实体需要读取相同的数据时，若能在运行实体运行之前先把数据读到缓存中，在运行实体运行结束后再把数据写出去，则可以改善运行效率，这就是隐式模式。显示模式与隐式模式的对比如图2.13所示，可见后者的实现方式中，会在运行实体被调用之前读数据，在运行结束后写数据。

图2.13　显式模式与隐式模式的对比

对于C/S通信模式，可分为同步（Synchronous）和异步（Asynchronous）两种模式，它们的对比如图2.14所示。

图2.14　同步模式和异步模式的对比

（4）运行实体间变量

运行实体间变量（Inter Runnable Variable，IRV）即两个运行实体之间交互的变量，如图2.15所示

图2.15　运行实体间变量示意

会议推荐

车载电源通讯录