什么是AUTOSAR规范？

AUTOSAR的由来与发展历程

AUTOSAR的由来

电子技术在动力总成控制、底盘控制、车身控制以及车载信息娱乐系统等各个部分所占的比重越来越大，所占的整车成本也越来越高。电子技术已悄然成为汽车各方面功能拓展和性能提升的重要技术支撑。

由于汽车电子硬件系统的多样性，ECU软件的开发受到硬件系统的制约，每当需要更新硬件时，都会导致ECU软件重新编写或大规模修改，之后还要进行一系列测试，从而导致了高昂的研发费用与漫长的研发周期。

目前，汽车电子网络正向多总线混合网络互联方向发展；电控系统硬件正向专业化、高集成度、高性能方向发展，其软件架构也正向模块化、平台化、标准化方向发展。并且，未来随着汽车新能源化和智能化的普及，以及对于一些非功能需求的增加，汽车电子/电气系统的复杂度也将进一步提升。这都将进一步导致新产品开发周期、成本的急剧增加。整车厂为了降低汽车控制软件开发的风险，于是开始寻找提高软件复用度的方法。

为解决上述问题，基于先前EAST-EEA项目的研究成果，在2003年，由全球汽车制造商、零部件供应商及其他电子、半导体和软件系统公司联合建立了汽车开放系统架构联盟（AUTomotive Open System ARchitecture，AUTOSAR），并联合推出了一个开放化的、标准化的汽车嵌入式系统软件架构——AUTOSAR规范。与传统ECU软件架构相比，AUTOSAR分层架构的高度抽象使得汽车嵌入式系统软硬件耦合度大大降低。

AUTOSAR规范的出现，将带来如下主要优势：

①有利于提高软件复用度，尤其是跨平台的复用度；

②便于软件的交换与更新；

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

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

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

这些优势对将来愈发复杂的汽车嵌入式系统软件的开发过程可谓是大有裨益，在保证软件质量的同时，可以大大降低开发的风险与成本。

AUTOSAR的原则及核心思想

AUTOSAR联盟自成立至今，一直提倡“在标准上合作，在实现上竞争”的原则，标准大家共同制定，但具体的实现方法是由各公司自己去探索的。其核心思想在于“统一标准、分散实现、集中配置”。“统一标准”是为了给各厂商提供一个开放的、通用的平台；“分散实现”要求软件系统高度的层次化和模块化，同时还要降低应用软件与硬件平台之间的耦合；不同的模块可以由不同的公司去完成开发，但要想完成最终软件系统的集成，就必须将所有模块的配置信息以统一的格式集中整合并管理起来，从而配置生成一个完整的系统，这就是“集中配置”。

采用AUTOSAR将为OEM（主机厂）带来很大的好处，使得其对于软件采购和控制拥有更灵活和更大的权利。因为AUTOSAR不仅在软件的功能上、接口上进行了一系列的标准化，还提出了一套规范化的开发流程与方法，这就使得能有更多的软件供应商进入汽车电子行业，大家都遵循同一个标准去开发，最终比的是产品的功能和质量。

AUTOSAR的发展历程及应用现状

AUTOSAR联盟从2003年成立至今，成员队伍不断壮大，标准内容日臻完美。AUTOSAR联盟成员按等级分为核心成员（Core Partner）、高级成员（Premium Member）以及合作成员三类正式成员，基本涵盖了世界上各大著名整车厂、零部件公司、半导体公司以及软件工具提供商。

目前，AUTOSAR平台最新版为4.3.1。为了迎合未来汽车智能化、网联化的需求，AUTOSAR联盟推出了一个全新的平台——自适应AUTOSAR平台（AUTOSAR Adaptive Platform，AP），并将现有平台更名为经典AUTOSAR平台（AUTOSAR Classic Platform，CP），AUTOSAR官网（https：//www.AUTOSAR.org/）也进行了更新，给人一种耳目一新的感觉。

AUTOSAR规范在国外的应用相较于国内更早、更普遍、更成熟。大众、博世、通用、德尔福、菲亚特等公司已将符合AUTOSAR规范的软件应用于它们的ECU产品。

德国大众集团与MathWorks、Elektrobit（EB）等公司联合开发了符合AUTOSAR规范的车身舒适控制系统，并应用于帕萨特车型。

玛涅蒂玛瑞利公司将AUTOSAR应用于菲亚特汽油发动机平台，并进行了硬件在环测试和不同工况下2万千米行程的实车测试。此外，他们还将AUTOSAR运用于车灯控制、动力总成控制等电控系统。

ETAS公司成功将宝马5系发动机管理系统开发为符合AUTOSAR规范的控制系统。开发人员利用ASCET进行软件组件开发，管理软件组件端口及其运行实体；使用RTA-OS开发AUTOSAR操作系统，配置、划分、管理任务；应用RTA-RTE连接应用层和基础软件层；代码集成后，进行了硬件在环仿真，结果表明与传统开发方法相比复杂度降低50%。整个博世集团已将AUTOSAR架构应用于自适应巡航系统ECU、动力总成系统ECU、底盘控制系统ECU和车身控制模块（Body Control Module，BCM）的开发，并且今后将运用于更多的ECU开发过程。

近年来，随着国内新能源汽车相关控制器正向开发需求的增长，AUTOSAR规范在国内越来越受到大家的关注，并且应用需求也越来越大。目前，上汽、北汽等国内主流整车厂以及一些零部件供应商都开始致力于符合AUTOSAR规范的车用控制器软件开发。AUTOSAR规范也有望成为未来整个汽车电子行业所普遍使用的软件标准。

AUTOSAR分层架构

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

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

应用软件层

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

运行时环境

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

基础软件层

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

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

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

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

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

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

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抽象软件组件（ECUAbstractionSWC）提供访问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中用端口接口（Port Interface）来表征端口的属性，端口接口主要有如下几种类型：

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

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

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

④非易失性数据接口（Nonvolatile 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）。

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

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

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

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

软件组件的内部行为

软件组件的内部行为（Internal Behaviour，IB）主要包括：

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

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

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

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

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

每个运行实体都会被赋予一个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。

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

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

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

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

什么是AUTOSAR规范？相关推荐

【读书笔记】AUTOSAR规范与车用控制器软件开发01
ECU(Electronic Control Unit)电子控制单元:汽车专用微机控制器汽车开放系统架构联盟(AUTomotive Open System ARchitecture,AUTOSAR) ...
基于AUTOSAR规范的电机控制器软件开发
基于AUTOSAR规范的电机控制器软件开发本系列文章主要介绍如何开发符合AUTOSAR规范的电机控制器软件的详细过程. 全系类分为基础篇和实战篇:基础篇内简要介绍最新的AUTOSAR规范,嵌入式软件 ...
【读书笔记】AUTOSAR规范与车用控制器软件开发02
第3章本书示例及AUTOSAR系统解决方案介绍系统解决方案介绍第4章 AUTOSAR软件组件级设计与开发举例介绍第5章 AUTOSAR系统级设计与配置 ETAS ISOLAR-A工具第6章 ...
精心整理吐血推荐的AUTOSAR科普介绍材料
一.AUTOSAR的背景介绍 AUTOSAR是AUTOmotive Open System Architecture(汽车开放系统架构)的首字母缩写,是由全球各大汽车整车厂.汽车零部件供应商.汽车电子 ...
AUTOSAR从入门到精通100讲（八十五）-AUTOSAR基础篇之BswM
前言首先,请问大家几个小小问题,你清楚: 你知道BswM是做甚的吗? 常说的APP Mode或者System状态机与BswM关系又是如何的呢? BswM模块作为AUTOSAR的一个标准模块,内部工作 ...
AUTOSAR I-PDU的理解以及I-PDU的Callout
1. 什么是I-PDU? 我理解的 I-PDU 应该就是一个 Message,Message 是由多个信号组成的.比如下图中多路复用 Multiplexor = 0 时,无数个信号组成了一个 Mes ...
“使用达芬奇软件实现Autosar架构：配置和注意事项“
Autosar (Automotive Open System Architecture) 是一种开放式的汽车电子系统架构.它通过规范化电子控制单元 (ECU) 之间的通讯和软件架构,以实现不同厂商之 ...
详解AUTOSAR：什么是AUTOSAR？（理论篇—1）
目录 1.为什么需要AUTOSAR 2.AUTOSAR简介 3.AUTOSAR的发展历程及应用现状 4.AUTOSAR的特点和优势终于要讲到心心念念的AUTOSAR系列专栏了.第一次知道AUTOSA ...
Autosar MCAL开发必知的“术语”+“缩写”概念
如何使用该博文? ==>您可以将该篇博文当做"字典",遇到疑惑的Autosar"关键字",使用组合键Ctrl+F,快速查找该关键字. 推荐Autosar培 ...

什么是AUTOSAR规范？

什么是AUTOSAR规范？相关推荐

最新文章

热门文章