AUTOSAR，全称为Automotive Open System Architecture，即汽车开放系统架构。它是由全球各家汽车制造商、零部件供应商以及各种研究、服务机构共同参与的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（ECU）标准软件架构。

在AUTOSAR架构中，系统软件被规规整整的进行了分层，看起来井然有序，如同一篇逻辑清晰的文章。

整个架构从上到下分层依次为：应用层（Application Software Layer），运行时环境（Runtime Environment，RTE），基础软件层（Basic Software Layer，BSW），微控制器（Microcontroller）。

每层之间为保持独立性，每一层只能调用下一层的接口，并为其上一层提供接口。

分层架构是实现软硬件分离的关键，它也使得汽车嵌入式系统控制软件开发者，得以在ECU软件开发与验证过程中，摆脱对硬件系统的依赖。

AUTOSAR的出现极大的解决了车企和供应商们最大的苦恼，大大降低了软硬件之间的耦合度。它所带来的好处是显而易见的：

1.有利于提高软件的复用度，使软件可以跨平台复用；

2. 便于软件的交换与更新；

3. 软件功能可以进行先期架构级别的定义和验证，从而减少开发错误；

4. 减少手工代码量，减轻测试验证负担，提高软件质量；

5. 使用一种标准化的数据交换格式，方便各个公司之间的交流合作。

这些优势，使得各个企业在保证软件质量的同时，大大降低了开发的风险与成本。

AUTOSAR不仅在软件的功能、接口上进行了一系列的标准化，还提出了一套规范化的开发流程与方法，使得更多的软件供应商进入汽车电子行业，大家都遵循同一个标准去开发。

总而言之，有了AUTOSAR架构，车企可以完全成为“甩手掌柜”，不需要再管难度最大的底层软件问题。

Autosar分层架构

在AUTOSAR分层架构中，汽车嵌入式系统软件自上而下分别为应用软件层（Application Software Layer，ASW）、运行时环境（Runtime Environment，RTE）、基础软件层（Basic Software Layer，BSW）和微控制器（Microcontroller）。为保证上层与下层的无关性，在通常情况下，每一层只能使用下一层所提供的接口，并向上一层提供相应的接口。分层架构是实现软硬件分离的关键，它使汽车嵌入式系统控制软件开发者摆脱了以往ECU软件开发与验证时对硬件系统的依赖。

AUTOSAR应用软件层

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

主机厂（整车厂）一般会掌握主要控制器的应用层开发。因为软件定义汽车的时代，主要控制器会影响车的驾驶性、舒适性、经济性等一系列指标，它蕴含着整车厂的传承与风格。

AUTOSAR运行时环境

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

AUTOSAR基础软件层

基础软件层（Basic Software Layer，BSW）包含众多基础软件模块，它所负责的是ECU非应用相关的功能。基础软件最重要的功能之一是ECU间的通信，即信号交互。

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

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

（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），如图所示。

微控制器抽象层

（4）复杂驱动层

由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以在AUTOSAR规范中这部分没有被标准化，这种方法旁通了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软件组件的几个重要概念：数据类型、端口、端口接口以及内部行为。

软件组件的数据类型

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进行具体实现。

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

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

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

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

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

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

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

　AUTOSAR软件组件端口接口

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

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

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

　发送者-接收者接口定义

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

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

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

　客户端-服务器接口定义

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

2.3　软件组件的内部行为

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

　软件组件的内部行为

①运行实体（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）。

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

　运行实体的RTE事件示意

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

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

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

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

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

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

（4）运行实体间变量

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

运行实体间变量示意

3.Autosar的开发方法

AUTOSAR方法论描述了从系统底层配置到ECU可执行代码产生过程的设计步骤，可以分为建立抽象系统描述（需求）、建立VFB系统描述、开发软件组件、开发系统和子系统、开发BSW、软件集成这几个步骤，从大的阶段来讲可分为系统配置、ECU设计与配置、软件集成三个阶段。下图表述了从SWC描述阶段到ECU提取的过程。

虚拟功能总线（Virtual Functional Bus，VFB），它是为SWC之间的通信和对BSW服务的调用提供一个虚拟的中间层。这样整车厂在初期进行系统设计（1）时，就可以专注于软件功能模块的设计，而无需考虑硬件的限制。SWC因而也可以重复利用，并在不同项目里自由组合。

AUTOSAR开发方法

通过建立抽象系统描述，可描述为1个或多个SWC组件，通过VFB系统，将1个或多个SWC组件组合起来构成整个系统。使用支持SWC软件开发组件的工具根据ECU描述、系统约束描述将软件需求映射到ECU上。下图描述了借助AUTOSAR配置工具从系统底层配置到ECU可执行代码生成的过程。

AUTOSAR开发方法

首先借助配置工具生成系统配置描述文件，再提取各个ECU相关的描述将SWC映射到各个ECU上，再将子系统独立出来，之后就可以开发单个ECU的SWC、BSW最后将生成的代码集成，生成可执行文件下载到ECU上运行