Autosar总结--汽车开放系统架构—AUTomative Open System ARchitecture

汽车开放系统架构—AUTomative Open System ARchitecture

Autosar产生的原因

从上个世纪80年代汽车控制器出现开始，汽车的电子控制系统一直在高速发展，面临的挑战也越来越多，主要体现在以下几个方面：

• 电子系统的复杂性不断增长
• 软件代码量不断上升
• 生命周期差别：整车的生命周期往往长于ECU的生命周期
• 嵌入式系统不支持硬件抽象
• 有限的软件模块化
• 重用性差：当硬件（处理器型号）更换后，软件往往要推到重写
• 五花八门的硬件平台

Autosar建立的动机

• 降低与功能范围增长相关的E/E架构的复杂性
• 提高产品修改、升级和更新的灵活性
• 提高产品线内和跨产品线的解决方案的可扩展性
• 提高E/E架构的质量和可靠性

Autosar的目标

• 适用于整个产品生命周期
• 从软件中把硬件抽象出来，对于不同硬件平台具有更大的灵活性更多的配置而非实现
• 标准化AUTOSAR的代码配置/建模工具
• 通过对BSW的标准化提高了代码质量
• 竞争力只体现于对OEM的特殊功能要求的实现
• 在整个汽车生命周期中，软件可以不断更新或升级
• 重用性可以覆盖整个网络节点，甚至跨不同OEM

Autosar框架

Autosar整体框架为分层式设计，以中间件RTE(Runtime Environment)为界，隔离上层的应用层（Application Layer）与下层的基础软件（Basic Software）。

---

软件组件SWC VFB与RTE

应用层中的功能由**各软件组件（SWC）**实现，组件中封装了部分或者全部汽车电子功能，包括对其具体功能的实现以及对应描述，如控制大灯，空调等部件的运作，但与汽车硬件系统没有连接。
​ 在设计开发阶段中，软件组件通信层面引入了一个新的概念，虚拟功能总线VFB（Virtual Functional Bus），它是对Autosar所有通信机制的抽象，利用VFB，开发工程师将软件组件的通信细节抽象，只需要通过AUTOSAR所定义的接口进行描述，即能够实现软件组件与其他组件以及硬件之间的通信，甚至ECU内部或者是与其他ECU之间的数据传输。因此软件组件只需向VFB发送输出信号，VFB将信息传输给目标组建的输入端口，这样的方式使得在硬件定义之前，即可完成功能软件的验证，而不需要依赖于传统的硬件系统。

中间件RTE与面向对象的编程思想非常接近，所有ECU所对应的RTE都是特定的，它负责着软件构件间以及软件构件与基础软件之间的通信。对于软件构件来说，基础软件不能够直接访问，必须通过RTE进入。因而RTE也被理解成是VFB的接口实现。

而构件之间及构件与基础软件的通信关系如图所示：

AUTOSAR软件构件无法直接访问基础软件中的操作系统OS，因而在应用程序中不存在「task」的概念，且不能动态创建线程，因此并行的任务由RTE直接管理调入的「构件运行实体」来实现。每个软件构件也许会有一个或者多个运行实体，但是一个运行实体只对应一个入口。

基础软件层 BSW

基础软件则被抽象为四层：

服务层（Services Layer）

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

ECU抽象层（ECU Abstraction Layer）

封装了微控制器层及外围设备的驱动，并对微控制器内外设的访问进行了统一，实现了软件应用层与硬件系统的分离。

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）

位于基础软件的最底层，包含了访问微控制器的驱动（如I/O驱动、ADC驱动等），做到了上层软件与微控制器的分离，以便应用的后续的移植复用。

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

复杂驱动（Complex Device Drivers）

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

Autosar开发流程和工具

1.BSW开发

主要应用工具链（ETAS、Vector等工具）来配置，复杂驱动的代码需要手写，但是也要符合Autosar的接口标准，主要包括，CAN通信配置、数字输入配置、数字输出的配置、模拟量采集配置、UART通信配置、SPI通信配置、实时运行系统OS配置、RTE配置、故障码以及诊断配置等。

ETAS的解决方案

VECTOR的解决方案

2.ASW开发

主要工具是Simulink，首先是应用层软件架构的开发（涉及信号的输入输出以及功能模块的划分，不同的模块有不同的输入和输出），在架构的基础上进行软件策略和算法的开发，主要是Simulink中的状态机跳转以及逻辑运算等。模型开发结束后，生成代码。

3.将BSW和ASW的代码放置在同一工程下，进行编译生产HEX文件。

一致性测试

Autosar一致性测试的目的是为了验证产品是否符合Autosar规范。这些产品需要在互操作性、重用/移植性、可扩展性上证明符合Autosar标准。因为Autosar是一个开放标准，所以所有最终规范都是标准的一部分。

一致性测试中的角色有：

（1） Autosar（维护标准，监控Autosar规范的使用）。

（2） Conformance Test Agency（分为第一方CTA和第三方CTA，主要任务是提供测试包，执行测试，提供支持和证明服务）。

（3） Product Supplier（开发和测试产品）。

自适应Autosar平台（Autosar Adaptive Platform）

为了适应智能网联技术在汽车领域的应用，AUTOSAR组织推出了AUTOSAR自适应平台，此前的Autosar命名为经典平台（Classical Platform，即本文的以上内容)。

AUTOSAR经典平台侧重于满足有严格实时性要求和安全要求的车辆功能的开发，而AUTOSAR自适应平台重点关注基于高性能微处理器（如ARM）和智能操作系统（如Linux）的智能互联应用功能的开发。

功能概述

相比AUTOSAR经典平台，自适应平台运行具有多核的强大微处理器，微处理器一般要具有1 GHz以上主频，并且可以访问更多的内存（64MB到2GB）。同时，自适应平台采用了大量IT领域的软件技术：

• 采用面向对象语言C++语言进行软件开发 （经典AUTOSAR采用C语言）。
• 基于智能操作系统（POSIX OS， 例如Linux）进行APP的开发。
• 充分利用其他领域软件成熟技术，重用软件市场成熟组件（Utility Libraries， 例如boost等），缩短开发周期。

平台架构

经典平台与自适应平台对比

CP	AP
基于OSEK	基于POSIX(PSE51)
从ROM直接运行代码	应用程序从非易失性存储器加载到RAM中
所有应用程序共用相同的地址空间（MPU提供安全支持）	每个应用程序都有自己的（虚拟）地址空间（MMU提供安全支持）
基于信号的通信优化（CAN/FlexRay）	基于服务的通信
固定的任务配置	支持多（动态）调度策略

经典平台与自适应平台关系理解

自适应平台并不是经典平台的替代品，不同的版本可同时存在与同一个车辆中，两个ECU间可通过一些途径，例如以太网，将经典应用和自适应应用进行无缝衔接。简单而言，两者的应用场景不太一样：经典平台多应用与注重硬实时和安全的嵌入式系统中；自适应平台则侧重与高性能计算等应用场合，诸如ADAS、互联功能V2X、图像处理、信息娱乐系统等的开发。