01 AUTOSAR基础简介及方法论
01 AUTOSAR基础简介及方法论
AUTOSAR（Automotive Open System Architecture）是一种专为汽车电子系统设计的开放式系统架构，旨在解决汽车电子系统日益复杂带来的开发挑战。本文将详细介绍AUTOSAR的基础知识、分层架构及其方法论，帮助读者全面了解这一重要的汽车电子系统开发标准。
AUTOSAR基础简介
一、AUTOSAR是什么
在探讨AutoSar之前，需要了解其背景知识。随着汽车控制器的快速发展，同一供应商不同代别产品之间的移植和复用问题日益突出，不同供应商之间的兼容性问题也愈发严重。软件开发成本居高不下，欧洲各OEM的软件和系统能力较强，ECU供应商主要负责软件底层和硬件服务，不同供应商平台的不兼容性给OEM带来了很大困扰。为了解决这些问题，2003年，以宝马为首的几家OEM与Tier1成立了AUTOSAR联盟，旨在开发一套支持分布式、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案。
Figure1：Architecture – Overview of Software Layers Detailed view
传统软件开发方式存在诸多问题，如电子系统复杂性不断增长、软件代码量急速上升、整车生命周期长于ECU生命周期、嵌入式系统不支持硬件抽象、软件模块化程度有限、兼容性差等。AutoSar的出现，主要追求以下目标：
- 适用于整个产品生命周期
- 从软件中抽象出硬件，提高对不同硬件平台的灵活性
- 更多的配置而非实现
- 标准化AUTOSAR的代码配置/建模工具
- 通过BSW的标准化提高代码质量
- 竞争力体现在对OEM特殊功能要求的实现上
- 在整个汽车生命周期中，软件可以不断更新或升级
- 兼容性覆盖整个网络节点，甚至适用于不同OEM
二、为什么要使用AUTOSAR
下表总结了传统软件与AUTOSAR软件的主要区别：
传统软件面临的挑战 | AUTOSAR解决方案 | AUTOSAR优势 |
|---|---|---|
对功能需求缺乏追溯手段，没有兼容性的工具链 | 需求交互格式交互化（ARXML） | 从内容和格式上改进规范围无缝的工具链提供可能 |
基础软件模块不能复用带来的时间和精力浪费 | 基础软件BSW | 提高软件质量、供应商提供基础软件 |
升级主芯片带来大量的重新设计 | 微控制器抽象层MCAL | 主芯片可以随意替换、MCAL有芯片厂家提供 |
集成工作繁琐 | 运行时环境RTE | 集成自动化 |
软件耦合性大 | 接口标准化 | 不同供应商可以交互组件 |
具体来说：
- 使用WORD或EXCEL等文档传递需求时，规范与格式难以统一，信息传递不准确。而AUTOSAR使用ARXML作为数据载体，具有格式规范、存储容量大且准确的特点。
- 在没有AUTOSAR之前，每个新的ECU项目都需要重新编写通信协议栈，需要大量时间和人力。使用AUTOSAR后，可以通过配置工具快速生成基础软件代码。
- 使用AUTOSAR后，更换MCU芯片变得更加简单。芯片厂商会根据接口标准提供MCAL代码，只需替换即可。
- 在没有AUTOSAR时，架构师可能通过Excel文档管理模块接口，直到编译代码时才能发现接口问题。使用AUTOSAR工具后，可以实现软件接口的自动化集成。
三、AUTOSAR的缺点
尽管AUTOSAR具有诸多优点，但仍存在一些局限性：
- 高昂的价格：开发完整的AUTOSAR环境需要购买第三方软件，如DAVINCI、ISOLAR等，价格动辄百万人民币，导致门槛较高。
- 复杂的文档规范：虽然AUTOSAR标准文档易于获取，但数量众多且难以理解，学习曲线陡峭。
四、AUTOSAR分层架构
AUTOSAR规范主要由分层架构、方法论和应用接口三部分组成。其中，分层架构是实现软硬件分离的关键思想。
Figure2：Architecture – Overview of Software Layers Detailed view
AUTOSAR架构从底层到应用层可分为：
- 微控制器抽象层（Microcontroller Abstraction Layer）
- 基础软件层（Basic Software Layer）
- 运行环境RTE（Runtime Environment）
- 应用软件层（Application Software Layer）
每一层只能使用下一层的软件接口，并向上一层提供相应的接口。基础软件层负责硬件服务，应用软件层负责逻辑应用，实现了软硬件的隔离。这种设计使得应用工程师在开发和验证时不再依赖硬件系统，提升了系统的整合能力。
4-1、应用层ASW（Application Software Layer）
应用层由多个SoftWare component（SWC）组成，每个SWC内部可以实现算法。SWC可以由多个运行实体（Runnable Entity）组成，通过Port进行连接。可以将SWC理解为一个.C模块，Runnable Entity则类似于模块中的函数，Port则用于模块间的数据传递和函数调用。
Figure3：车灯控制系统的功能软件组件示意图
4-2、运行环境RTE（RealTime Environment）
RTE是基础软件层与应用层之间交互的基础通道，主要功能包括：
- 抽象应用层SWC之间的通信，将模块间的通信封装成标准化接口。
- 封装基础软件层提供的通信与服务，如ECU间通信（CAN、LIN、ETH）和基础软件服务（诊断、存储）。
- 抽象基础软件层之间的通信，特别是复杂驱动模块与IoHWab模块间的通信。
因此，RTE可以被视为AUTOSAR中的虚拟总线（Virtual Functional Bus）。
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（Microcontroller Abstraction Layer）位于AUTOSAR软件架构的基础软件底层，可以直接访问MCU寄存器和内部外设的底层驱动。MCAL根据MCU底层驱动功能的相似性，可分为六个驱动组：
- 微控制器驱动组（Microcontroller Drivers Group）
- 存储驱动组（Memory Drivers Group）
- 通信驱动组（Communication Drivers Group）
- 加密驱动组（Crypto Drivers Group）
- 无线通信驱动组（Wireless Communication Drivers Group）
- 输入/输出驱动组（I/O Drivers Group）
4-3-2、ECU抽象层
ECU抽象层的目的是使上层软件与ECU硬件电路设计分离。它包括板载设备硬件抽象（如外挂看门狗）、存储器硬件抽象（如EEPROM）、通信硬件抽象（如CAN收发器）和I/O硬件抽象。ECU层为应用层和系统服务层提供统一标准化的接口，使上层软件无需关心硬件资源的具体来源。
4-3-3、服务层
服务层提供给应用层可用的服务内容，主要包括诊断、操作系统、通信、内存管理等。除了操作系统之外，服务层的软件模块都是与ECU平台无关的。
4-3-4、复杂驱动层
复杂设备驱动组件提供复杂传感器和执行器的驱动，使应用层可以直接访问硬件资源。通常对于实时性要求高的应用，如电机驱动控制、PWM控制等，可以利用该组件实现控制管理。
AUTOSAR方法论
一、AUTOSAR方法论是什么
AUTOSAR为汽车电子软件系统开发定义了通用的技术方法，即AUTOSAR方法论。
二、AUTOSAR方法论的作用
AUTOSAR方法论描述了从系统底层配置到整个ECU可执行代码的产生过程的设计步骤。AUTOSAR的开发方法是基于虚拟功能总线（VFB）的开发方法。
以辣椒炒肉为例，AUTOSAR方法论就像菜谱，按照菜谱上的原料、工具和步骤，就能做出美味的辣椒炒肉：
- 工具：使用AUTOSAR工具完成整个过程的软件开发。
- 原料：ARXML文件承载了AUTOSAR配置过程中所有的信息。
- 出锅：系统配置 => ECU设计与配置阶段 => 生成代码。
接下来详细介绍AUTOSAR设计和开发流程：
- 第一阶段：定义系统配置文件。这是系统设计者或架构师的任务，包括选择硬件和软件组件，定义整个系统的约束条件。系统配置的输入是ARXML类型的文件，输出是系统配置描述文件，主要作用是把软件组件的需求映射到ECU上。
- 第二阶段：根据系统配置描述文件提取单个ECU资源相关的信息，生成ECU提取文件。根据这个提取文件对ECU进行配置，例如操作系统任务调度、必要的BSW模块及其配置、运行实体到任务的分配等，从而生成ECU配置描述文件。
- 第三阶段：生成代码，基于ECU配置描述文件指定的配置来产生代码、编译代码，并把相关代码链接起来形成可执行文件。
Figure5：AUTOSAR软件开发全过程