01 AUTOSAR基础简介及方法论

GalaxySinCos

已于 2025-02-26 09:41:44 修改

阅读量1k

点赞数 20

CC 4.0 BY-SA版权

分类专栏： AUTOSAR模块配置文章标签：单片机 mcu 嵌入式硬件

于 2025-02-11 13:32:16 首次发布

本文链接：https://blog.csdn.net/weixin_45906411/article/details/145565206

AUTOSAR模块配置专栏收录该内容

2 篇文章

订阅专栏

文章目录

AUTOSAR基础简介
AUTOSAR方法论
- 一、AUTOSAR方法论是什么
- 二、AUTOSAR方法论的作用
参考文献

AUTOSAR基础简介

一、AUTOSAR是什么

谈及AutoSar前，要先稍微了解下AutoSar的背景知识。汽车上控制器迅速地发展，逐渐出现同一供应商不同代别的产品无法相互移植和复用的现象，更别提不同的供应商的兼容性了。不同代别控制器无法复用，导致软件开发成本居高不下。另外，欧洲各OEM的软件和系统能力比较强，ECU供应商主要负责软件底层和硬件服务，不同供应商平台的不兼容性，导致OEM十分头痛，问题迟迟无法得到解决。2003年，以宝马为首的几家OEM与Tier1成立AUTOSAR联盟，希望为汽车工业开发一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案，也就是我们说的AUTOSAR（AUTomotive Open System Architecture，汽车开放系统架构），旨在摆脱软件对硬件和系统的依赖，降低OEM长期开发成本。
在这里插入图片描述

Figure1：Architecture – Overview of Software Layers Detailed view

总之，传统软件能够开发被AutoSar取代，主要有这么几个原因：电子系统的复杂性不断增长；软件代码量急速上升；生命周期差别：整车的生命周期往往长于ECU的生命周期；嵌入式系统不支持硬件抽象；有限的软件模块化；兼容性差，当硬件更换后，软件要推倒重写。那么AutoSar的应运而生，主要追求的目标就是：适用于整个产品生命周期；从软件中把硬件抽象出来，对于不同硬件平台具有更大的灵活性；更多的配置而非实现；标准化AUTOSAR的代码配置/建模工具；通过对BSW的标准化提高了代码质量；竞争力只体现于对OEM的特殊功能要求的实现；在整个汽车生命周期中，软件可以不断更新或升级；兼容性将覆盖整个网络节点，甚至适用不同OEM。

二、为什么要使用AUTOSAR

Table1. 传统软件与AUTOSAR软件的区别

传统软件面临的挑战	AUTOSAR解决方案	AUTOSAR优势
对功能需求缺乏追溯手段，没有兼容性的工具链	需求交互格式交互化（ARXML）	从内容和格式上改进规范围无缝的工具链提供可能
基础软件模块不能复用带来的时间和精力浪费	基础软件BSW	提高软件质量、供应商提供基础软件
升级主芯片带来大量的重新设计	微控制器抽象层MCAL	主芯片可以随意替换、MCAL有芯片厂家提供
集成工作繁琐	运行时环境RTE	集成自动化
软件耦合性大	接口标准化	不同供应商可以交互组件

如果使用WORD或者EXCEL等文档去传递需求，使用文档传递需求具有规范与格式难以统一的缺点，所以很难准确传递信息。AUTOSAR使用ARXML作为数据的载体，具有格式规范，存储数据容量大并且准确的特点。
在没有AUTOSAR之前，每一个新的ECU项目都需要重新编写通信协议栈，存储协议栈等，需要大量的时间与人力，应用AUTOSAR之后，使用AUTOSAR基础软件配置工具可以快速配置并且生成基础软件的代码。
使用AUTOSAR后，如果某个ECU需要更换MCU芯片，那么只需要使用芯片厂商提供的MCAL生成工具生成MCAL代码，将这部分替换之前的MCAL代码即可。为什么这么方便呢？因为AUTOSAR将MCAL与其他模块的接口规定好了，各芯片厂商都会根据这些接口编写MCAL代码，所以切换MCAL变得非常简单了，具体的规则，笔者将在后面为大家详细说明。
按照之前没有AUTOSAR时的软件开发方式，架构师可能通过Ecxel文档管理各模块的之间的接口，但是直到编译代码的时候才能发现各模块的接口是否是连接上的，这种方式一方面不直观，另一方面对整个开发进度是不利的。如果使用了AUTOSAR工具，架构师就能够对软件接口进行自动化集成，为后面的软件开发顺利进行奠定基础。

三、AUTOSAR的缺点

AUTSAOR虽然具有很多优点，但是到目前为止，仍具有一些缺点。

AUTOSAR软件的价格十分高昂：如果需要开发完整的AUTOSAR环境的话，需要购买第三方软件，目前主流的AUTOSAR软件有DAVINCI,ISOLAR等，这些软件动辄百万级RMB，导致AUTOSAR的门槛非常高。
AUTOSAR文档规范非常多而且复杂：获得AUTOSAR标准文档的方式非常方便，在AUTOSAR官网上下载即可。但是这些AUTOSAR的正式文档是作为规范而不是作为指南编写的。更糟糕的是，如果你时间有限，并且希望通过阅读AUTOSAR文档学习AUTOSAR，那么你将陷入痛苦的深渊，AUTOSAR文档不仅数量多而且难以理解，AUTOSAR文档的具体格式笔者将在后面的文章中做具体介绍。

四、AUTOSAR分层架构

AUTOSAR规范主要由分层架构、方法论、以及应用接口三部分组成。分层架构是AUTOSAR中最厉害的思想，也是实现软硬件分离的关键。
在这里插入图片描述

Figure2：Architecture – Overview of Software Layers Detailed view

AUTOSAR架构从底层至应用层可以分为：

微控制器抽象层（Microcontrollrer Abstraction Layer）
基础软件层（Basic Software Layer）
运行环境RTE（Runtime Environment）
应用软件层（Application Software Layer）

根据AUTOSAR分层架构理论，每一层只能使用下一层的软件接口，并向上一层提供相应的接口，这样可以保证AUTOSAR的严格分层。基础软件层属于为硬件服务的层级，应用软件层属于纯逻辑应用层，软硬件的隔离，对于应用工程师来说，摆脱了以往ECU软件开发与验证时对硬件系统的依赖；对于OEM及供应商来说，提升了系统的整合能力，比如，OEM自己开发应用软件层，供应商开发基础软件层，有了AUTOSAR，这种开发模式变得非常简单了。

4-1、应用层ASW（Application Software Layer）

应用层是由一个个SoftWare component组成，这些SWC内部可以实现算法，每个SWC可以由多个运行实体（Runnbale Entity）组成，并且SWC通过Port连接起来。如何理解SWC与Runnable Entity的关系呢？如果大家写过C语言，那么SWC可以理解为一个.C模块，而Runnable Entity就可以认为是.C模块中的函数。Port能够理解成模块之间函数调用或者模块之间为了进行数据传递通过封装函数对全局变量进行读写。
如下图中车灯控制系统组件示意图，整个控制系统由多个SWC组成，每个SWC负责处理相应的功能，SWC通过Port传递需要的数据。
在这里插入图片描述

Figure3：车灯控制系统的功能软件组件示意图

4-2、运行环境RTE（RealTime Environment）

RTE是基础软件层与应用层之间交互的基础通道。应用层的软件组件SWC间、应用层软件与BSW基础软件间、以及基础软件间的通信需要通过RTE实现。所以RTE具有如下几个主要功能：

抽象应用层SWC之间的通信：无论是模块之间的数据传递以及函数调用，都将封装成标准化的接口。
封装基础软件层提供的通信与服务：ECU之间的通信（CAN,LIN,ETH）在通过基础软件层BSW的处理后，RTE通过使用标准化的接口将其统一为软件组件的通信。同时，基础软件提供的服务（诊断、存储等），也被RTE定义成标准的服务接口，提供给应用层使用。
抽象基础软件层之间的通信：基础软件中复杂驱动模块与IoHWab模块通常被认为是软件组件，他们之间的通信也需要通过RTE定义的标准接口进行通信。
所以可认为RTE是AUTOSAR中的虚拟总线(Virtual Functional Bus )，VFB是AUTOSAR提供的所有通信机制的总和。

4-3、基础软件层BSW（Basic Software Layer）

基础软件层（BSW）从软硬件分层可以抽象划分为四个层级：微控制器抽象层（Mcal，Microcontroller Abstraction Layer），ECU抽象层（Ecal，ECU Abstraction Layer）、服务层（Srv，Services Layer）和复杂驱动（Cdd，Complex Drivers Layer）。
在这里插入图片描述

Figure3：Architecture – Overview of Software Layers Detailed view

4-3-1、微控制器抽象层

MCAL是Micro-Controller Abstraction Layer（微控制器抽象层）的缩写。MCAL位于AUTOSAR软件架构中基础软件的底层。可以直接访问MCU寄存器和内部外设的底层驱动。这样划分可以使ECU抽象层、系统服务层可以独立于MCU，保证上层软件的标准化和通用性。
AUTOSAR规范根据MCU底层驱动功能的相似性，把MCAL可以分为6个驱动组，分别是微控制器驱动组（Microcontroller Drivers Group）、存储驱动组(Memory Drivers Group)、通信驱动组(Communication Drivers Group)、加密驱动组(Crypto Drivers Group)、无线通信驱动组(Wireless Communication Drivers Group)、输入/输出驱动组（I/O Drivers Group）。
在这里插入图片描述

Figure4：Architecture – Content of Software Layers Microcontroller Abstraction Layer

4-3-2、ECU抽象层

ECU抽象层的目的在于使上层软件与ECU硬件电路设计进行剥离。其中包括：板载设设备硬件抽象（外挂看门狗）、存储器硬件抽象（如EEPROM）、通信硬件抽象(如CAN收发器)、I/O硬件抽象（I/O电路处理）。而且ECU层将会给应用层和系统服务层提供统一标准化的接口，应用层与系统服务层通过这些接口可以直接访问存储或者I/O等的访问，并不需要关心这些接口的资源是来自于芯片本身还是外设。BSW通过MCAL抽象MCU芯片，ECU抽象层抽象ECU硬件电路将整个硬件剥离开来，因此，ECU抽象层之上的软件层级只需要关注于软件而不需要关注硬件了。

4-3-3、服务层

服务层的目的在于提供给应用层可用的服务内容，主要包括：诊断、操作系统、通信、内存管理等。其中，除了操作系统之外，服务层的软件模块都是与ECU平台无关的。

4-3-4、复杂驱动层

复杂设备驱动组件的目的在于提供复杂传感器和执行器的驱动，使应用层可直接访问硬件资源。通常对于实时性有着非常高需求的应用可以利用该组件实现控制管理，或是将过去已经应用非常成熟的功能代码移植到该架构下时可放在该组件中，比如电机的驱动控制，MCU的PWM控制（电磁阀、三相电机、EPB电机），轮速驱动控制等等。

AUTOSAR方法论

一、AUTOSAR方法论是什么

AUTOSAR为汽车电子软件系统开发定义了通用的技术方法，即AUTOSAR方法论。

二、AUTOSAR方法论的作用

AUTOSAR方法论描述了从系统底层配置到整个ECU可执行代码的产生过程的设计步骤。AUTOSAR的开发方法是基于虚拟功能总线(VFB)的开发方法。
举例：先用一道非常著名的辣椒炒肉来给大家简要解释AUTOSAR方法论。AUTOSAR方法论就像菜谱，我们只需要按照菜谱上写好的原料、工具和步骤，就能做出一道美味的辣椒炒肉。

做菜的工具锅、碗瓢盆：我们可以使用AUTOSAR工具完成整个过程的软件开发。
辣椒、肉（ARXML文件）：AUTOSAR中基础软件层与应用层，MCAL与BSW之间都需要文件进行交互，但是不可能用Word交换这些信息。比如OEM想要告诉TIER1车辆的CAN报文有哪些内容，使用WORD的话，OEM编辑起来费时费力，TIER1阅读起来也费事费力。所以AUTOSAR规定了一种新的文件格式：ARXML，用ARXML可以很简洁的表现大量的数据，所以ARXML承载了AUTOSAR配置过程中所有的信息。
炒菜出锅：（系统配置 => ECU设计与配置阶段 => 生成代码）

接下来详细介绍AUTOSAR设计和开发流程：系统配置、ECU设计与配置阶段、代码生成阶段。

第一阶段：定义系统配置文件。这是系统设计者或架构师的任务。包括选择硬件和软件组件，定义整个系统的约束条件。AUTOSAR通过使用信息交换格式和模板描述文件来减少初始系统设计时的工作量。系统配置的输入是ARXML类型的文件，输出是系统配置描述文件，系统配置的主要作用是把软件组件的需求映射到ECU上。
第二阶段：根据系统配置描述文件提取单个ECU资源相关的信息，提取出来的信息生成ECU提取文件。根据这个提取文件对ECU进行配置，例如操作系统任务调度，必要的BSW模块及其配置，运行实体到任务的分配等，从而生成ECU配置描述文件。该描述文件包含了特定ECU的所有信息。
第三阶段：生成代码，是基于ECU配置描述文件指定的配置来产生代码、编译代码，并把相关代码链接起来形成可执行文件。

在这里插入图片描述