AUTOSAR规范简介

OSEK/VDX标准

1993年，德国汽车工业界提出OSEK（Open Systems and the Corresponding Interfaces for Automotive Electronics ），中文名汽车电子开放式系统及其接口标准。该体系得到宝马、博世、戴姆勒-克莱斯勒等公司的支持。1994年，将法国汽车工业的分布式执行标准（Vehicle Distributed eXecutive，VDX）也纳入该体系；1995年，产生OSEK/VDX标准。

OSEK/VDX标准包含7部分：
1）OSEK/VDX操作系统规范（OSEK Operating System，OSEK OS）；
2）OSEK/VDX通信规范（OSEK Communication，OSEK COM）；
3）OSEK/VDX网络管理规范（OSEK Network Management，OSEK NM）；
4）OSEK/VDX实现语言规范（OSEK Implementation Language，OSEK IL）；
5）OSEK/ORTI运行时接口规范（OSEK Run Time Interface）；
6）OSEK-Time时间触发操作系统规范（OSEK Time-Triggerred Operating System）；
7）OSEK FTCom 容错通信规范（OSEK Fault-Tolerant Communication）；

OSEK/VDX标准好处：
应用层、底层软件分离，提升应用软件的可移植性；
提高代码复用率，提升开发效率、降低开发成本；

缺点：没能解决跨平台化高效地进行嵌入式系统软件的移植。

于是，出现了EAST-EEA研究项目，由ITEA资助，目标是通过建立面向汽车工业的通用嵌入式系统架构，实现接口的标准化并提升复杂系统开发的质量与效率。最终，EAST-EEA项目项目定义了一个分层软件架构，提出一个“中间件”的层次来提供支持嵌入式系统模块在不同平台间的接口、服务；EAST-EEA项目还定义了公共的架构描述语言（Architecture Description Language，ADL）。

简而言之，EAST-EEA项目是AUTOSAR规范的雏形。

AUTOSAR由来

由于硬件多样性，ECU软件开发受硬件系统制约，当硬件需要更新时，会导致ECU软件重新编写或修改+大量测试，从而导致高昂研发费用、时间成本。

当前，汽车电子网络往总线混合网络互联方向发展，电控系统硬件朝专业化、高集成度、高性能方向发展，软件架构也向模块化、平台化、标准化方向发展。

基于EAST-EEA项目，2003年，成立汽车开放系统架构联盟（AUTomotive Open System ARchitecture，AUTOSAR），联合推出开放化、标准化的汽车嵌入式系统软件架构，即AUTOSAR规范。

AUTOSAR架构 vs 传统ECU软件架构：软硬件耦合度大大降低。

AUTOSAR规范优势：
1）提高软件复用性，特别是跨平台；
2）有利于软件交换、更新；
3）软件功能可以先进行架构级别的定义、验证，从而减少开发错误；
4）减少手工代码量，减轻测试验证负担，提高软件质量；
5）使用标准化数据交换格式，方便各公司合作交流。

简而言之，保证软件质量同时，降低开发风险和成本。

AUTOSAR核心思想

原则是“在标准上合作，在实现上竞争”，即标准大家共同制定，但具体的实现方法由各公司自定义。

核心思想是“统一标准、分散实现、集中配置”。
统一标准：为给各厂商提供一个开放的、通用的平台；
分散实现：要求软件系统高度的层次化和模块化，同时降低应用软件与硬件平台间的耦合。
集中配置：不同模块可由不同公司完成，但想要完成最终系统集成，必须将所有模块的配置信息以统一格式集中整合并管理，从而配置生成一个完整的系统。

AUTOSAR现状

AUTOSAR联盟成员不断壮大，按等级分为核心成员（Core Partner）、高级成员（Premium Member）、合作成员。基本涵盖了世界上各大著名整车厂、零部件公司、半导体公司、软件工具供应商。

AUTOSAR联盟推出自适应AUTOSAR平台（AUTOSAR Adaptive Platform，AP），并将现有平台更名为经典AUTOSAR平台（AUTOSAR Classic Platform，CP），AUTOSAR官网可以查阅。

本文介绍AUTOSAR基本理论知识、AUTOSAR方法论具体实现为主，采用CP，主要版本4.2.2和4.0.3。

大众、博世、通用、德尔福、菲亚特等公司，已经将符合AUTOSAR规范的软件应用于ECU产品。

AUTOSAR分层架构

AUTOSAR规范主要包括三部分内容：分层架构、方法论、应用接口。分层架构是实习软硬件分离的关键，使软件摆脱对硬件系统的依赖。

分层架构中，自上而下分别为：应用软件层（Application Software Layer，ASW）、运行时环境（Runtime Environment，RTE）、基础软件层（Basic Software Layer，BSW）和微控制器（MCU）。

上下层无关，每层只能使用下一层所提供的接口，并向上一层提供相应的接口：

AUTOSAR应用软件层ASW

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

AUTOSAR运行时环境

运行时环境（Runtime Environment，RTE）作为应用软件层与基础软件层交互的桥梁，为软硬件分离提供了可能。

RTE可以实现：软件组件间、基础软件间、软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务，为应用层软件组件提供了标准化的基础软件和通信接口，使得应用层可以通过RTE接口函数调用基础软件的服务。

RTE抽象类ECU之间的通信，即RTE通过使用标准化的接口将其统一为软件组件之间的通信。由于RTE实现与具体ECU相关，所以需要为每个ECU分别实现。

AUTOSAR基础软件层

基础软件层（Basic Software Layer，BSW）可分为4层：服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer，MCAL）、复杂驱动（Complex Drivers）。如下图：

上述各层又由一些列基础软件组件构成，如下图：

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的访问，从而不需要考虑这些资源是由MCU提供，还是片外设备提供。该层与ECU平台相关，但与MCU无关，

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

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

AUTOSAR软件组件

软件组件（SWC）不仅是应用程的核心，也是一些抽象层、复杂驱动层等实现的载体。SWC大体上可分为原子组件（Atomic SWC）和部件（Composition SWC）。其中，部件可包含若干原子软件组件或部件。原子软件可根据不同用途分为以下几种类型：
1）应用软件组件（Application SWC）；
2）传感器/执行器软件组件（Sensor/Actuator SWC）；
3）标定参数软件组件（Parameter SWC）；
4）ECU抽象软件组件（ECU Abstraction SWC）；
5）复杂设备驱动软件组件（Complex Device Driver SWC）；
6）服务软件组件（Service SWC）；

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

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

标定参数软件组件主要提供标定参数值。

ECU抽象软件组件提供访问ECU具体I/O的能力。该软件组件一般提供引用C/S接口的供型端口，即Server端，由其他软件组件（如传感器/执行器软件组件）的需型端口（Client端）调用。

此外，ECU抽象软件组件也可以直接和一些基础软件进行交互。

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

服务软件组件主要用于基础软件层，可同感标准接口或标准AUTOSAR接口与其他类型的软件组件进行交互。

软件组件的数据类型

AUTOSAR规范定义了三种数据类型（Data Type）：
1）应用数据类型（Application Data Type，ADT）；
2）实现数据类型（Implementation Data Type，IDT）；
3）基础数据类型（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）。
1）需型端口：用于从其他软件组件获得所需数据或所请求的操作；
2）供型端口：用于对外提供某种数据或某类操作；
3）供需端口：兼有需型端口与供型端口的特性。

需型端口可以和供型端口连接。

AUTOSAR软件组件端口：

由于端口仅定义了方向，所以AUTOSAR中用端口接口（Port Interface）来表征端口的属性，端口接口类型主要有如下几种：
1）发送者-接收者接口（Sender-Receiver Interface， S/R）；
2）客户端-服务器接口（Client-Server Interface，C/S）；
3）模式转换接口（Mode Switch Interface）；
4）非易失性数据接口（Non-volatile Data Interface）；
5）参数接口（Parameter Interface）；
6）触发接口（Trigger Interface）；

最常用的端口接口是1）、2）。

如下图，软件组件SWC1具有2个端口：其中一个引用的端口接口类型为发送者-接收者（S/R）接口，另一个引用的端口接口类型为客户端-服务器（C/S）接口。
对于引用发送者-接收者接口的一组端口而言，需型接口为接收者（Receiver），供型端口为发送者（Sender）。对于引用客户端-服务器接口的一组端口而言，需型端口为客户端（Client），供型端口为服务器（Server）。

AUTOSAR软件组件端口接口：

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

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

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

客户端-服务器端口定义：

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

软件组件的内部行为

软件组件的内部行为（Internal Behaviour，IB），如下图：

主要包括：
1）运行实体（Runnable Entity，RE）；
2）运行实体店RTE事件（RTE Event）；
3）运行实体与所属软件组件的端口访问（Port Access）；
4）运行实体间变量（Inter Runnable Variable，IRV）；

1）运行实体
是一段可执行代码，封装了一些算法。一个软件组件可包含一个或多个运行实体。

2）运行实体的RTE事件
每个运行实体都会被赋予一个RTE事件（Trigger Event），即RTE事件（RTE Event），该事件可引发这个运行实体的执行。

RTE事件可细分为很多种类，常用有：
①周期性（Periodic）事件，即Timming Event；
②数据接收事件（Data-received Event）；
③客户端调用服务器事件（Server-call Event）；

如下图所示，Runnable_1、Runnable_2和Runnable_3分别采用Timming Event、Data-received Event及Server-call Event。

运行实体的RTE事件示意：

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

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

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

显示模式 vs 隐式模式：

对于C/S通信模式，可分为同步（Synchronize）和异步（Asynchronous）两种模式。

4）运行实体间变量
运行实体间变量，即两个运行实体之间交互的变量，如下所示：

AUTOSAR虚拟功能总线

软件组件的架构——从整车级别看待整车所有功能模块，它们之间的通信形式主要有2种：
①在单个ECU内部的通信（Intra-ECU Communication）；
②在多个ECU之间的通信（Inter-ECU Communication）；

AUTOSAR为实现一种“自顶向下”的整车级别的软件组件定义，提出来虚拟功能总线（Virtual Function Bus，VFB）的概念。VFB可以使得应用程序员不用关心一个软件组件最终在整车中哪个ECU中具体实现，即使得应用软件开发独立于ECU开发。这样，应用软件开发人员可专注于应用软件组件的开发。

VFB是AUTOSAR提供的所有通信机制的抽象。对于应用软件开发者，单个ECU内部通信、多个ECU之间通信没有本质区别。两种通信的区别，只有等到系统级设计与配置阶段，将软件组件分配到不同的ECU之后，才会体现出来。最终，VFB的真实通信实现可以由RTE和基础软件保证。因此，RTE是AUTOSAR VFB的具体实现。

AUTOSAR方法论

AUTOSAR方法论（AUTOSAR Methodology）中，车用控制器开发涉及系统级、ECU级、软件组件级：
1）系统级主要考虑系统功能需求、硬件资源、系统约束，然后建立系统架构；
2）ECU级根据抽象后的信息对ECU进行配置；
3）系统级和ECU级设计的同时，伴随着软件组件级的开发。

上面每个环节都有良好的通信接口，并使用统一的arxml（AUTOSAR Extensible Markup Language）描述文件，以此构建了AUTOSAR方法论。

开发之前，需要先编写系统配置输入描述文件，包含以下三部分：
①软件组件描述（SW-Component Description）：包含系统中所涉及的软件组件的接口信息，例如数据类型、端口接口、端口等。
②ECU资源描述（ECU Resource Description-HW only）：包含系统中每个ECU所需要的处理器及其外设、传感器、执行器等信息。
③系统约束描述（System Constraint Description）：包含总线信号、软件组件间的拓扑结构和一些映射关系等信息。

基于上面的描述文件，系统配置根据ECU资源和时序要求，将软件组件映射到对应的ECU上，生成系统配置描述文件（System Configuration Description）。系统配置描述文件，包含系统通信矩阵（.dbc），描述了网络中所有运行的数据帧及其对应的时序和内容。

ECU配置主要对RTE、BSW配置。在RTE配置阶段，需要将软件组件的运行实体映射到相应的OS任务；在BSW配置阶段，需要将详细配置BSW层需用到的模块，如OS、通信服务、ECU抽象层、MCAL等。根据ECU配置信息生成BSW和RTE代码，再结合软件组件级实现的应用代码，最终进行代码集成，编译链接，生成MCU可执行文件（elf/hex/s19等）。