什么是AUTOSAR

什么是AUTOSAR

附赠自动驾驶学习资料和量产经验：链接

1 什么是AUTOSAR

做汽车电控功能很难不听到AUTOSAR这个词。

AUTOSAR, Automotive Open System Architecture，汽车开放系统架构

全球各大汽车整车厂、汽车零部件供应商、汽车电子软件系统公司联合建立的一套标准协议

符合汽车电子软件开发的、开放的以及标准化的软件架构。

那AUTOSAR究竟是什么，有什么用，是怎么运行的，有什么好处？CP和AP又到底是什么？

哪怕不是专门开发软件，了解相关知识，避免被忽悠也是很必要的。

为了实现应用程序和硬件模块之间的分离，AUTOSAR架构被抽象成四层，由上至下依次为：应用层（Application Layer）、运行时环境层（Run Time Environment，即RTE）、基础软件层（Basic Software，即BSW），以及微控制器层（Microcontroller）。应用层与基础软件（BSW）被分割开来，越高层级的模块越偏重应用，越低层级的模块越靠近硬件。

2 AUTOSAR是怎么运行的

AUTOSAR软件体系结构包含了完全独立于硬件的应用层（APP）和与硬件相关的基础软件层（BSW），并在两者中间设立了一个运行时环境（RTE），从而使两者分离，形成了一个分层体系架构。

RTE是专门为应用软件（AUTOSAR软件组件和/或AUTOSAR传感器/执行器组件）提供通信服务的层。

在RTE之上，软件架构风格从“分层”转变为“组件风格”。AUTOSAR软件组件通过RTE与其他组件（内部和/或内部ECU）或服务进行通信。

3 AUTOSAR有什么用

一方面，OEM可以专注于开发特定的、有竞争力的应用层软件（位于RTE之上），另一方面，它使OEM所不关心的基础软件层（位于RTE之下）得到标准化。

不同结构的电子控制单元的接口特征标椎化，应用软件具备更好的可扩展性以及可移植性，能够实现对现有软件的重用，大大降低了重复性工作，缩短开发周期。

4 CP和AP对比

两者应用场景不一样，经典AUTOSAR平台多应用于注重硬实时和安全的嵌入式系统中；而自适应AUTOSAR平台则侧重于高性能计算等应用场合，诸如ADAS，互联功能V2X、图像处理、信息娱乐系统等的开发。

4.1 AUTOSAR CP

4.1.1 BSW

BSW划分为4层：服务层，微控制器抽象层，ECU抽象层以及复杂驱动层

基础软件层功能：

1 提供标准化的规定（针对操作系统、定时器以及错误存储器）、ECU特定的服务（ECU状态管理、看门狗管理）和库函数；

2 对内部和外部的内存（非易失性存储器）的访问入口进行标准化；

3 对汽车网络系统、ECU通信系统以及ECU内部软件的访问入口进行标准化；

4 对传感器、执行器以及ECU外设的访问入口进行标准化；

4.1.1.1 服务层（Service Layer）

**服务层（Service Layer）**提供各种类型的后台服务，例如网络服务、内存管理和总线通信服务等，操作系统就位于这一层。

系统服务System Services 包含一组模块，并且模块的函数可以被所有层的模块使用。例如实时操作系统（包括定时器服务）和错误管理器。这些服务为应用程序和基本软件（BSW）模块提供基本服务。

存储器服务 Memory Services由一个模块组成，即 NVRAM 管理器。它负责非易失性（non volatile）数据的管理（从不同的内存驱动读/写）。向应用程序提供非易失性数据。提供非易失性数据管理机制，如保存、加载、校验和保护验证、可靠存储等。

通信服务 是一组用于车辆网络通信的模块（CAN、LIN、FlexRay以及Ethernet）。通信服务通过通信硬件抽象来与通信驱动程序进行交互。其主要任务是为车辆通信网络和车载网络的诊断通道提供一个统一的接口。

服务层是基础软件的最高层，同时与应用程序也有关联。虽然对I/O信号的访问由ECU抽象层覆盖，但服务层负责提供以下接口：操作系统的功能、车辆网络通信管理服务、存储器服务（NVRAM管理）、诊断服务（包括UDS通信、错误存储和故障处理）、ECU状态管理，模式管理、逻辑和时间程序流监控（Wdg管理器）、密码服务（密码服务管理）；

4.1.1.2 ECU抽象层（ECU Abstraction Layer）

位于微控制器抽象层之上，对接微控制器抽象层所提供的驱动程序，并同时包含对外部设备的驱动程序，然后负责向上提供统一的访问接口实现对通信、内存或者I/O的访问，从而使得上层模块无须考虑这些资源由微处理器提供还是由外部设备提供；

ECU抽象层负责提供统一的访问接口，实现对通信、内存或者IO口的访问，从而无须考虑这些资源是由微处理器提供的还是由外部设备提供的。外部设备的驱动就位于这一层。ECU抽象层主要包括板载设备抽象、存储器硬件抽象、通信硬件抽象以及IO硬件抽象4个部分。

I/O硬件抽象是一组模块从外设I/O设备（片上或板载）和ECU硬件布局（例如µC pin脚连接和信号电平倒置）抽象出来。I/O硬件抽象不会从传感器/执行器中抽象出来。不同的I/O设备可以通过I/O信号接口访问。

通信硬件抽象是一组模块从通信控制器和ECU硬件布局抽象出来。对于所有的通信系统都需要一个特定的通信硬件抽象（e.g. for LIN, CAN, FlexRay）。例如：一个ECU微控制器有2个内部CAN通道和一个附加的板载带有4个CAN控制器的ASIC芯片，CAN-ASIC通过SPI方式连接微控制器。通信驱动被访问通过总线特定的接口（CAN Interface）。

存储器硬件抽象，存储器硬件抽象是一组模块从外设存储设备（芯片或板载）和ECU硬件布局抽象出来。例如：芯片上的EEPROM和外部的EEPROM设备都可以通过相同的机制访问。存储设备被访问通过存储器特定的抽象/仿真模块（例如EEPROM 抽象）。

板载设备抽象包含ECU板载设备驱动，例如内部或外部看门狗，这些驱动访问ECU板载设备通过µC抽象层。

4.1.1.3 微控制器抽象层（MicroController Abstraction Layer，即MCAL）

位于BSW的最底层，包含跟硬件相关的驱动程序、软件模块与直接访问微控制器内部和外围的设备，可以用来访问内存、通信和I/O等；

微控制器器抽象层（MicroController Abstraction Layer，即MCAL）位于AUTOSAR分层模型中的BSW的最底层，它包含内部驱动，可以直接访问微控制器和片内外设。进一步的，MCAL又可分为微控制器驱动模块组（Microcontroller Drivers）、存储器驱动模块组（Memory Drivers）、通信驱动模块组（Communication Drivers）、以及I/O 驱动模块组（I/O Drivers）。

存储器驱动由内部EEPROM驱动、内部Flash驱动、RAM测试和Flash测试四部分组成。

通信驱动由以太网（Ethernet）驱动、FlexRay驱动、CAN驱动、LIN驱动和SPI驱动五部分组成。

CAN驱动针对的是微控制器内部的CAN控制器，它可以实现以下功能：

对CAN控制器进行初始化；

发送和接收报文；

对报文的数据和功能进行通知（对接收报文的指示、对发送报文的确认）；

溢出和错误处理；

唤醒检测；

PWM驱动为微控制器PWM模块提供初始化和控制服务，可生成周期和占空比都可变的脉冲

4.1.1.4 复杂驱动层（Complex Drivers Layer，即CCD）

跨越于微控制器硬件层和RTE之间，其主要任务是整合具有特殊目的且不能用MCAL进行配置的非标准功能模块，将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求，提供集成特殊用途的功能，例如设备驱动程序，在AUTOSAR中未规定的、具有非常高的时间限制或用于迁移等目的；

复杂驱动（CCD）层跨越于微控制器硬件层和RTE之间，其主要任务是整合具有特殊目的且不能用MCAL进行配置的非标准功能模块，将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求。

复杂驱动程序跟单片机和ECU硬件紧密相关。其上层程序接口是根据AUTOSAR指定并且实施的；其下层程序接口受标准接口程序的限制。

复杂驱动可以使用特定的中断或是复杂的微控制器外设（如PCP/TPU）来直接访问微控制器，从而实现对复杂传感器的评估和执行器的控制，比如喷油控制，电磁阀控制，增量位置检测等。

4.1.2 RTE

运行时环境( RTE )是应用软件和基础软件通信的桥梁，无论通信发生在 ECU之间( 如通过CAN、LIN、FlexRay、MOST等网络) ，还是在ECU内部，RTE均通过提供一致的接口和服务来实现SWC之间的通信抽象。一般情况下，每一层只能使用下一层的接口，并向上一层提供服务接口。

AUTOSAR定义了三种接口：标椎化接口（Standardized Interface）、AUTOSAR接口（AUTOSAR Interface）和标准化的AUTOSAR接口（Standardized AUTOSAR Interface）。

AUTOSAR接口是一种与应用相关的接口，与RTE一并生成。基于AUTOSAR接口的端口可以用于软件组件（Software Component,SWC）之间或者软件组件与ECU固件之间（例如复杂驱动）的通信；

标准化AUTOSAR接口是一种特殊的AUTOSAR接口。这些在AUTOSAR规范中定义过的接口被SWC用于访问AUTOSAR BSW模块提供的服务，比如ECU管理模块或者诊断事件管理模块；

标椎化接口是AUTOSAR规范中用C语言定义的API。这些接口用于ECU内部BSW模块之间，RTE和操作系统之间或者RTE和COM模块之间；

基础软件之间通过标椎化接口进行数据通信和操作调用的。故基础软件之间可以相互调用各自的API函数，但是微控制器抽象层只能被ECU抽象层所调用，底层驱动信息通过ECU抽象层传递给服务层使用。

4.1.3 ASW

应用层中的功能由**各软件组件（SWC）**实现，组件中封装了部分或者全部汽车电子功能。

对于软件构件来说，基础软件不能够直接访问，必须通过RTE进入。

定义方向

R 需型端口

P 供型端口

PR 供需型端口

表征端口属性

Port interface：

1 发送者-接收者 S/R

2 客户端-服务器 C/S

3 模式转换接口

4 非易失性数据接口

Non-volatile data interface

5 参数接口

6 触发接口

AUTOSAR软件构件无法直接访问基础软件中的操作系统OS，因而在SWC中就不存在「task」的概念，且不能动态创建线程，因此并行的任务由RTE直接管理调入的「构件运行实体」来实现。每个软件构件也许会有一个或者多个运行实体，但是一个运行实体只对应一个入口。

4.2 AUTOSAR AP

Adaptive Autosar中保留了部分Classic的基础服务，例如诊断、网络管理等，而新增了很多新的服务如升级与配置、健康管理、执行管理、状态转移等。操作系统由之前的Autosar OS 变为POSIX（可移植操作系统）如Linux等。

架构分层主要分为硬件层，基础服务层，ARA（实时运行环境），以及应用层。

CP平台中的ASW/RTE/BSW三层架构不见踪影。整个BSW被划分为自适应平台基础（Adaptive Platform Foundation）和自适应平台服务（Adaptive Platform Services）两大块；另外，原基础软件中的各小模块都不见了，被一个个功能集群（如运行管理集群Execution Management Cluster）所取代；而CP中重要的RTE（Runtime Environment）也被ARA（AUTOSAR Runtime Environment for Adaptive Applications）所代替。

AA（adaptive application)在ARA (AUTOSAR Runtime for Adaptive Applications) 上运行。

ARA包含了所有功能集合的应用接口。这些功能属于 Adaptive Platform foundation 和 Adaptive Platform Service。任何AA可以为其他AA提供服务。这些功能接口对应用程序来说没有差别，不论这些功能属于Adaptive Platform Foundation还是Adaptive Platform Service。

这些API使用的语言是C++，并且C++标准库是ARA的一部分。

4.2.1 基础服务层

基础服务层中，主要服务包括，通信服务（COM）、加密服务（crypto）、日志记录服务（Log）、诊断服务（Diag）、存储服务（Per）、状态管理（SM）、执行管理（Exec）、时间同步（Tsync）、升级配置管理（UCM）等。

4.2.1.1 通信服务ara::com

采用Proxy/Skeleton的通信架构，同时采用中间件SOME/IP。

客户端 -->服务端

具体服务请求：1. 代理请求服务–2.服务传输–3.调用服务–4.结果响应–5.获取结果。

具体事件请求：1.服务端事件请求–2.事件传输–3.事件存储–4.用户事件处理。

4.2.1.2 执行管理 ara::exec

执行管理负责系统初始化以及Adaptive Applications的启动和关闭。 它使用Manifest文件中包含的信息来执行这些任务，包括何时以及如何启动可执行文件。

启动阶段：进行OS的启动，根据应用的manifest文件中的描述，进行应用程序的启动与执行。

运行阶段：使应用运行在状态机所期望的状态，并监测状态机状态的改变和进程的终止。

关闭阶段：在操作系统中结束结束应用实例的进程。

4.2.1.3 诊断管理ara:diag

Adaptive Autosar也同样使用UDS诊断服务，只是物理层采用以太网方式，同时也可以看到应用层通过com服务来请求诊断服务。

4.2.1.4 存储管理ara::per

主要通过per模块的服务来针对关键数据进行存储或实现流存储。

4.2.2 ARA（实时运行环境）

Classic RTE基本是静态配置的，而Adaptive ARA则是动态的，并且Application就像我们在电脑上安装软件一样可以安装、升级、卸载。

4.2.3 应用层

在AP架构下每个Application都是一个App，每个App都包含OS、COM、API

Adaptive AUTOSAR中，主要包含两种Application：

1）Application-Level的Application

2）Platform-Level的Application

5 如何应用AUTOSAR

具体开发流程：

编写系统配置输入描述文件

在AUTOSAR中，所有的描述文件都是XML类型的文件。系统配置输入文件包含三部分内容：

1）软件组件描述，定义了每个涉及的软件组件的接口内容，如数据类型，端口，接口等。

2）ECU资源描述，定义了每个ECU的资源需求，如处理器、存储器、外围设备、传感器和执行器等。

3）系统约束描述，定义了总线信号，软件组件间的拓扑结构和映射关系。

系统配置

系统配置的功能主要是在资源和时序关系的前提下，把软件组件映射到各个ECU上，然后借助系统配置生成器生成系统配置描述文件。这个描述文件包括总线映射之类的所有系统信息以及软件组件与某个ECU的映射关系。

提取特定ECU的描述

从系统配置描述文件中提取出与各个ECU相关的系统配置描述信息，提取的信息包括ECU通信矩阵、拓扑结构、映射到该ECU上的所有软件组件，并将这些信息放在各个ECU的提取文件中。

ECU配置

ECU配置主要是为该ECU添加必要的信息和数据，如任务调度、必要的基础软件模块及其配置、运行实体及任务分配等，并将结果保存在ECU配置描述文件中，该文件包含了属于特定ECU的所有信息，换言之，ECU上运行的软件可根据这些信息构造出来。

生成可执行文件

根据ECU配置描述文件中的配置信息，生成RTE和基础软件配置代码，完成基础软件和软件组件的集成，最终生成ECU的可执行代码。

OEM：

1 为了实现需求，需要有几个Component SWC，之间的逻辑接口如何。

2 物理系统设计。逻辑接口对应真实的物理接口，如FlexRay，CAN等。

3 物理通信设计。定义通信矩阵。

OEM需要输出的是ECU模型提取物，ECU Extract，通常是一个arxml文件。

Tier1：

1 物理ECU设计。SWC细化成若干个原子软件组件（Atomic SWC）。

2 功能开发。即实现代码，要么手写，要么Simulink。

3 基础软件配置。AUTOSAR将BSW最后的产物定义成了两部分，一部分是基础的功能性代码，另一部分是通过配置器生成的配置代码。配置工程师需要用Tier2的软件来实现客户需要的诊断需求、通信矩阵和网络管理需求等。

Tier1的输出物是SWC代码（应用层，复杂驱动等）和BSW配置代码。

Tier2：

基础软件开发

Tier2提交给Tier1的应该是BSW配置软件及BSW的基础代码。

通常从属于BSW的MCAL（Micro Controller Abstraction Layer）会被单独提起，MCAL和BSW主体部分的Tier2也不一定是一家公司。

软件集成工程师：

将SWC代码，BSW配置代码，BSW基础代码集成在一起。

Adatptive AUTOSAR并不是Classic AUTOSAR的替代品，不同的版本可同时存在于一辆车中，两个ECU可通过一些途径，例如以太网，将经典应用和自适应应用进行无缝衔接。