什么是AUTOSAR, 为什么要用AUTOSAR

文章目录

• 一、为什么用AUTOSAR？
• 二、AUYTOSAR架构
• 三、AUTOSAR方法论
• 四、AUTOSAR标准化接口

一、为什么用AUTOSAR？

随着汽车电子的发展，一款现代豪华汽车可能包含多达100个ECU 包括从简单的传感器接口到复杂的信息娱乐及远程信息单元。

今天的汽车从过去的机械液压的启动转到今天的机械电子的启动，电子化的程度越来越高，要解决这个问题。

• AUTOSAR联盟提出了个口号“在标准上合作，在实现上竞争”。
• 预计到2020年，所有车辆都将拥有一些基于AUTOSAR的ECU，因此该标准不能被忽视。
• 改用AUTOSAR的一些原因和好处如下表所示：

二、AUYTOSAR架构

AUTOSARarchitecture的分层式设计，用于支持完整的软件和硬件模块的独立性(Independence)，中间RTE(Runtime Environment)作为虚拟功能总线VFB（Virtual FunctionalBus）的实现，隔离了上层的应用软件层（Application Layer）与下层的基础软件（Basic Software），摆脱了以往ECU软件开发与验证时对硬件系统的依赖。

• 软硬件分离的分层设计，对于OEM及供应商来说，提高了系统的整合能力，尤其标准化交互接口以及软件组件模型的定义提高了各层的软件复用能力，从而降低了开发成本，使得系统集成与产品推出的速度极大提升。

• 算上复杂驱动层（Complex Device Drivers），AUTOSAR架构中共分六层：
  应用软件层（Application Layer）
  运行环境RTE(Runtime Environment)
  服务层（Services Layer）
  ECU抽象层（ECUAbstraction Layer）
  微控制器抽象层（Microcontroller Abstraction Layer）
  复杂驱动（Complex Device Drivers）



• 应用层（Application）
  应用层由一个个Software component（SWC）组成，主要包括Application Software Component（控制策略、软件算法）、Sensor Software Component（传感器参数计算）、Actuator Software Component（执行器控制）。
  其中Application可以完全与MCU、ECU无关，甚至与互相关联的SWC组件所在位置无关，而Sensor和Actuator类型的SWC调用与ECU硬件平台相关。同时多个SWC可组合成为一个Composition合集被调用。



• 实时环境（RTE）
  AUTOSAR架构中各个Component之间无法直接进行的数据交换，必须通过RTE封装的API。
  因此RTE使ECU应用层与基础软件层无需形成映射关系就实现了SWC之间和SWC与BSW之间的数据交互。
  同时在AUTOSAR架构中还存在虚拟功能总线VFB（VirtualFunctional Bus）的概念。
  VFB是AUTOSAR提供的所有通信机制的总和，所有的Component（包括SWC、ECU抽象、服务、复杂驱动）之间的通信组成了VFB。
  所以说RTE属于VFB在单个ECU上的实现实例



• 基础软件（BSW）
  BSW被抽象划分为3个层面和一个组件，分别是MCU层、ECU层、服务层，以及复杂设备驱动组件。



• （1）MCU层（Microcontroller Abstraction Layer）
  MCU层的目的在于使上层软件与MCU处理器的型号选型剥离开。其中包括了关于MCU的驱动。



• （2）ECU抽象层（ECU Abstraction Layer）
  ECU层的目的在于使上层软件与ECU硬件电路设计剥离开。其中包括了关于ECU上的芯片驱动和外部设备的IO接口。



• （3）服务层（ServiceLayer）
  服务层的目的在于提供给应用层可用的服务内容，主要包括：诊断、操作系统、通信、内存管理等



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

AUTOSAR为符合该标准的汽车电子软件系统开发过程定义了一套通用的技术方法，这种方法即被称为AUTOSAR方法论（AUTOSAR Methodology）。

• 汽车OEM作为整车系统功能的规划和设计者，需要了解并掌握AUTOSAR提供的这套开发流程，才能主导和推进符合AUTOSAR标准的系统的开发过程。



• 
  

主要步骤可划分两个阶段：

• 第一个阶段是系统配置阶段，这属于系统级设计决策工作。
  首先是编写系统配置输入文件，为XML类型的文件。应用软件的描述术语在 AOTUSAR中为软件构件（Software Components），该文件将确定需要使用的软件构件（即系统具有哪些功能）和硬件资源（ECU），以及整个系统的约束条件。

• AUTOSAR提供了一系列的模板（软件构件模板，ECU资源模板和系统模板）和标准的信息交换格式，工具供应商可据此提供相应的工具支持，从而简化系统设计的工作，最终系统设计者只需要使用工具填充或编辑相应的模板即可导出系统配置输入文件。
  系统配置输入包含三部分内容:
  第一个输入是软件构件描述，定义每个需要的软件构件的接口内容，包括数据类型，端口，接口等；
  第二个输入是ECU资源描述，定义了每个ECU的资源需求，如处理器、外部设备、存储器、传感器和执行器等；
  第三个输入是系统约束描述，定义总线信号，拓扑结构和软件构件的映射关系。
  系统配置阶段接下来的工作是将初步获得的系统配置输入文件,借助系统配置生成器生成系统配置描述文件，同样为XML文件，这是系统配置阶段的最终工作成果。
  该文件将包含所有的系统信息，包括将软件构件映射到相关的ECU上（这种映射需要考虑到构件的需要、构件的连接、资源需求以及约束条件，有时也需要考虑成本等方面的因素），以及通信矩阵（整车的网络结构、时序以及网络数据帧的内容）。

• 第二个阶段是ECU的配置，这阶段的工作需要对系统中每个ECU分别进行。
  首先是使用第一个阶段的工作成果——系统配置描述文件，从中提取出与各个ECU相关的系统配置描述信息，提取的信息包括ECU通信矩阵、拓扑结构、顶级功能组合（据此产生需映射到该ECU上的所有软件构件），将放在另一个XML文件中。

• 提取信息的工作可借助工具完成。

• 然后进入ECU配置的实际工作中，这一步负责往输入对象中添加具体应用所必需的信息，如任务调度、必要的BSW模块、BSW配置信息、给任务分配的可运行实体等。
  这一步的结果被放在ECU 配置描述文件中，它包含了具体ECU所需的所有信息。

• 最后一步是生成具体ECU的可执行程序，此步将根据ECU配置描述文件中的配置信息,构建完成ECU的基础软件的设置和基于AUTOSAR构件的应用软件的集成，最终生成ECU的可执行代码。

此外，要说明的是，AUTOSAR系统的设计过程使用了虚拟功能总线（Virtual Functional Bus）的概念。

• 虚拟功能总线（VirtualFunctional Bus）将AUTOSAR软件构件相互间的通信以及软件构件与基础软件之间的通信进行了抽象，同时使用预先定义的标准接口。
• 而对于虚拟功能总线来说，ECU内部通信和外部总线通信并没有什么区别，这种区别要等到系统布局以及ECU的具体功能最终确定才会体现出来。软件构件本身对于这种区别并不关注，因此我们可以在独立的情况下开发软件构件。
• 在系统实现过程中，虚拟功能总线所代表的功能最终以RTE的生成来体现。

通过RTE实现AUTOSAR软件构件（即应用程序）相互间的通信以及软件构件与基础软件之间的通信的前提是，软件构件必须具有标准的 AUTOSAR接口。

目前，AUTOSAR已定义了一些典型的汽车电子应用领域（动力，车身/舒适和底盘）的标准接口。

• AUTOSAR按照功能逻辑分别将这些领域的系统划分成若干个模块，这些模块可被视为一个软件构件或多个软件构件的组合，这些功能性的软件构件的接口被明确定义，所定义的接口的内容包括名称，含义，范围，数据类型，通信类型，单位等。
• 应用软件开发者在软件构件的设计与开发时需要应用这些接口定义。
  这里以车身/舒适系统的雨刷管理的软件构件的接口定义为示例，如下图：

1）CmdWashing接口由WiperWasherManager构件提供，其数据内容为FrontWasher构件的Activation接口所使用。 

2）CmdWashing包含一个“Command”的数据元素。 

3）“Command”的数据类型为“t_onoff”。 

4）“t_onoff”属于“RecordType”，该类型描述一般的开/关信息。

• 应用软件开发者应该意识到，面向AUTOSAR运行时环境（RTE）接口的应用软件设计的重要性，及早地将AUTOSAR应用层接口引入到实际的项目中来，为实现应用软件的可复用性做好准备，从而优化整个软件开发流程。

• 参考：链接