学习笔记10--自动驾驶汽车软件架构

本系列博客包括6个专栏，分别为：《自动驾驶技术概览》、《自动驾驶汽车平台技术基础》、《自动驾驶汽车定位技术》、《自动驾驶汽车环境感知》、《自动驾驶汽车决策与控制》、《自动驾驶系统设计及应用》。
此专栏是关于《自动驾驶汽车平台技术基础》书籍的笔记.

---

---

1.自动驾驶汽车软件架构

1.1 软件平台概述

• 汽车上因使用了大量的电子控制单元(Electronic Control Unit，ECU)，使得电子软件的开发难度越来越大；
• 为了实现容错操作的系统，汽车制造商必须从汽车的整体架构入手，确保将备援机制等安全措施部署在以下3个功能区：感测、运算、制动；
• 车载系统需提供更多的安全功能。多层式策略通常是解决这个安全难题的关键；首先，在应用层执行相关安全通信，加上应用访问控制，确保流动数据的可信度，这对于无线软件更新(OTA)或相关服务功能特别重要；其次，软件平台的安全模块需要包含分隔化、入侵预防和ECU验证；最后，在硬件层方面，CPU安全、针对整合硬件安全模块(HSM)的支持及ECU自身的防火墙，这些功能都有利于为汽车建立全方位的安全平台；
• 采用开放式平台/开放式系统策略有助于加快整体创新流程，促进业界开发可互通、模块化且可扩充的自动驾驶系统；
• 我国智能汽车的软件研发技术现状，在车控软件方面，"核高基"重大专项部署支持开发实时嵌入式操作系统及开发环境、汽车电子控制器嵌入式软件开发平台和国产汽车电子基础软件平台等产品；
• 国内软件平台厂商参照OSEK/VDX和AUTOSAR等国际标准，已经研发出面向ECU的操作系统产品及解决方案；
• 浙江大学ESE实验中心成功开发出符合AUTOSAR标准的集成ECU开发工具链，支持用于ECU软件架构、网络系统配置、基础软件配置、诊断、标定和仿真测试的快速迭代开发模式；
• 在车载软件方面，国内的阿里云研发出可用于车载终端的阿里云操作系统，且涌现出科大讯飞、高德等实力较强的车载应用软件供应商和普华、博思等车载终端系统供应商；

1.2 自动驾驶汽车软件架构

1.2.1 AUTOSAR软件架构

1. AUTOSAR概述

   • AUTOSAR是Automotive Open System Architecture(汽车开放系统架构)的缩写，是一家专注于制定汽车电子软件标准的联盟；

   • AUTOSAR是由全球汽车制造商、零部件供应商及其他电子、半导体和软件系统公司联合建立，各成员企业之间保持开发合作伙伴关系；自2003年起，各伙伴公司携手合作，致力于为汽车工业开发一个开放的、标准化的软件架构；

   • 整车软件系统可通过AUTOSAR架构对车载网络、系统内存及总线的诊断功能进行深度管理，并改善了系统的可靠性和稳定性；

   • 目前支持AUTOSAR标准的工具和软件供应商都已经推出相应的产品，提供需求管理、系统描述、软件构建算法模型验证、软件构建算法建模、软件构建代码生成、RTE(Real Time Environment)生成、ECU配置及基础软件和操作系统等服务，帮助软件系统提供商实现无缝的系统软件架构开发流程；

   • 传统的ECU架构的两个缺点：抽象程度低、基础软件模块少；针对这两个问题，AUTOSAR规范提出了抽象程度更高的解决措施，划分出更多的基础模块；

   • 为了实现应用软件和硬件模块的解耦，汽车电子软件架构被抽象出4层，如下图所示：
     

   • AUTOSAR层面图从上至下依次为：应用层(Application Layer)、运行时环境(Run Time Environment，RTE)、基础软件层(Basic Software，BSW)、微控制器(Microcontroller)；应用层完全独立于硬件，只有基础软件层与硬件有关，RTE实现这两者的隔离；

   • AUTOSAR组织规定的目标以及它所囊括的功能领域如下图所示：
     

   • 为了达到上述目标，针对在汽车电子行业中遇到的难题，AUTOSAR采用的解决方案及其优点如下表所示：

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

   • AUTOSAR架构是为了改善电子系统软件的更新与交换，同时更快捷有效地管理日趋复杂的汽车电子软件系统；

   • AUTOSAR规范的使用让不同结构的电子控制单元的接口特征标准化，应用软件具备良好的可扩展性和可移植性，很大程度减小了开发周期；

   • AUTOSAR提倡"在标准上合作，在实现上竞争"的原则，其核心思想是"统一标准、分散实施、集中配置"；

2. AUTOSAR模块构成

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

3. 对分层各层的介绍

   1. Application Layer(应用层)

      • 应用层中的功能由各软件组件(Software Component，SWC)实现，组件中封装了部分或全部汽车电子功能，如下图所示：
        

      • 软件组件

        • 软件组件由最小逻辑单元(Atomic Component)组成；最小逻辑单元有Application、Sensor/Actuator两种类型；

• 其中：Application是算法实现类型，能在各ECU上自由映射；Sensor/Actuator是为Application提供I/O端口类型，用于与ECU绑定，但不像Application能在各ECU上自由映射；

  • 数个SWC的逻辑集合组合成Composition，如下图所示：
    

  • 端口

    • 端口用来和其他SWC通信；通信内容分为：Data Elements与Operations；其中：Data Elements用发送端-接收端(Sender/Receiver)通信方式，Operations用客户端-服务器端(Client/Server)通信方式，如下图所示：
      
    • 发送端-接收端(Sender/Receiver)用来传输数据，具有一个通信端口可以包含多种数据类型的特点；但如果一个数据类型要通过总线传输，那么它必须与一个信号对应起来，数据类型既可以是简单的数据类型，也可以是复杂类型；通信方式是1：n或n：1，如下图所示：
      
    • 客户端-服务器端口(Client/Server)用来提供Operation服务，具有一个客户端-服务器端口可以包含多种Operation和同步或是异步通信的特点，一个客户端-服务器端口可以包含多种Operations操作，Operations操作也可以被单独调用；通信方式是1：n或n：1，如下图所示：
      

  • 可运行实体(Runnable Entities)

    可运行实体(Runnable Entities)，亦称Runnables；可运行实体包含实际实现的函数，可以是具体的逻辑算法或是实际操作；可运行实体由RTE周期性或是事件触发调用，如接收到数据，如下图所示：
    

  2. RunTime Environment(中间件)

     • 中间件(RTE)部分给应用层提供了通信手段，应用层与其他软件的信息交互有两种，第一种是应用层中不同模块之间的信息交互，第二种是应用层模块同基础软件之间的信息交互；RTE的特征图如下图所示：
       

     • RTE是这些交互使用的接口的集散地，汇总了所有需要和软件体外部交互的接口；从某种意义上看，设计符合AUTOSAR规范的系统就是在设计RTE；

     • SWC间的通信是通过调用RTE API函数而非直接实现的，均有RTE管理和控制；每个API遵循统一的命名规则且仅与软件组件自身的描述有关；具体通信实现取决于系统设计和配置，由工具供应商提供的RTE Generator自动生成；

     • 在设计开发阶段，软件组件通信层面引入了一个新的概念，虚拟功能总线(Virtual Functional Bus，VFB)，如下图所示：
       

     • VFB是对AUTOSAR所有通信机制的抽象，利用VFB，开发工程师将软件组件的通信细节抽象，只需要通过AUTOSAR所定义的接口进行描述，即能够实现软件组件与其他组件及硬件之间的通信，甚至是ECU内部或与其他ECU之间的数据传输；

     • 虚拟功能总线的3种接口描述：

       1. Standardized Interface(标准接口)：标准接口是在AUTOSAR规范中被标准化的接口，但并未使用AUTOSAR接口技术，标准接口通常被用于某个ECU内部的软件模块之间的通信，不能用于网络通信；
       2. Standardized AUTOSAR Interface(标准AUTOSAR接口)：标准AUTOSAR接口是在AUTOSAR规范中使用AUTOSAR接口技术标准化的接口，这种接口的语法和语义都被规定好了，通常在AUTOSAR服务中使用，是基础软件服务提供给应用程序的；
       3. AUTOSAR Interface(AUTOSAR接口)：AUTOSAR接口定义了软件模块和BSW模块(仅仅是I/O抽象和复杂驱动)之间交互的方式，AUTOSAR接口以Port的形式出现，将ECU内部的通信和网络通信使用的接口进行统一；

     • 第一和第二类接口都是语法语义标准化的接口，即接口函数的数量、函数的名字、函数参数名字及数量、函数的功能、函数的返回值都已经在标准里定义好了，第三类接口，AUTOSAR仅仅规定了简单的命名规则，这类接口和应用高度相关，这类接口必须通过RTE交互，如下图所示：
       

  3. Basic Software(基础软件)

     • 现代汽车中有多种ECU，各自具有不同功能，但实现这些功能所需要的基础服务是可以抽象出来的，如：I/O操作、AD操作、诊断、CAN通信、操作系统等；

     • 不同的ECU功能所操作的I/O、AD代表不同的含义，所接收和发送的CAN消息具有不同的内容，操作系统调度的任务周期优先级不同；

     • 这些可以被抽象出来的基础服务被称为基础软件；根据不同的功能对基础软件可继续细分为：服务层(Service Layer)、ECU抽象层(ECU Abstract Layer)、复杂驱动(Complex Drivers)和MCAL层(Microcontroller Abstraction Layer)，这4部分相互依赖程度不尽相同，如下图所示：
       

       • 服务层(Service Layer)

         此层基础软件提供了汽车ECU非应用相关的服务，包括：操作系统(OS)、网络通信、内存管理(NVRAM)、诊断(UDS，故障管理等)、ECU状态管理模块等，它们对ECU的应用层功能提供辅助支持；

       • ECU抽象层(ECU Abstract Layer)

         此层基础软件提供了ECU应用相关的服务，是对一个ECU的抽象，包括：ECU的所有输入输出，如：数模转换(AD)、PWM等；此层软件直接实现了ECU的应用层功能，可以读取传感器状态，可以控制执行器输出；

       • MCAL层(Microcontroller Abstraction Layer)

         此层软件是对ECU所使用的主控芯片的抽象，跟芯片的实现紧密相关，是ECU软件的最底层部分，直接和主控芯片及外设芯片进行交互；其作用是将芯片提供的功能抽象成接口，再将这些接口提供给服务层或ECU抽象层使用；

       • 复杂驱动(Complex Drivers)

         现代汽车中有一些领域的ECU会处理复杂的硬件信号，执行复杂的硬件动作，如：发动机控制、ABS等；这些功能相关的软件很难抽象出来适用于所有类型ECU，其与ECU应用及ECU所使用的硬件紧密相关，属于在AUTOSAR构架中无法移植于不同ECU的部分；

     • BSW层各个子模块说明如下图所示：
       

  4. System Services(系统服务)

     • 系统服务是一组可以由所有层模块调用的模块和功能，如：实时操作系统、错误管理器和库功能，为应用和基本软件模块提供基本服务；具体包括：AUTOSAR OS、BSW调度器、模式管理器3个部分，如下图所示：
       

     • AUTOSAR OS介绍

       AUTOSAR OS为实时应用提供了所有基本服务，即中断处理、调度、系统时间和时钟同步、本地消息处理，及错误检测机制；所有服务都隐藏在良好定义的API之后，应用层与OS和通信层的连接只通过API；其基本特征包括：静态配置、能推断实时系统性能和提供基于优先级的调度策略等；

     • BSW调度器

       BSW调度器是系统服务的一部分，它向所有层的所有模块提供服务；但与其他BSW模块不同，BSW调度器提供了集成的概念和服务，BSW调度器可提供方法把BSW模块的实现嵌入AUTOSAR OS中，并应用BSW模块的数据一致性机制；集成者的任务是应用所给的方法，在特定项目环境中以良好定义和有效的方式，把BSW模块装配起来，意味着BSW调度器只是使用AUTOSAR OS，与AUTOSAR OS调度器不冲突；

     • 模式管理

       模式管理包括3个基本软件模块：①ECU状态管理器：控制AUTOSAR BSW模块的启动阶段，包括OS的启动；②通信管理器：负责网络资源管理；③看门狗管理器：基于应用软件的生存状态触发看门狗；

1.2.2 Apollo软件架构

1. Apollo概述

   • Apollo是百度面向汽车行业及自动驾驶领域合作伙伴发布的，一个开放、完整、安全的自动驾驶平台；
   • 通过这个平台，开发者可整合车辆和硬件系统，搭建完整的自动驾驶系统；
   • Apollo平台提供的软硬件和服务，包括：车辆平台、硬件平台、软件平台、云端数据服务等4大部分；

2. Apollo软件架构

   • Apollo软件架构由以下几个模块组成：校准模块、车辆CAN总线控制模块、控制模块、决策模块、可视化模块、驱动模块、人机交互模块、端到端强化学习、定位模块、高精地图模块、监控模块、感知模块、预测模块及通用监控与可视化工具；

   • 自动驾驶系统先通过起点终点规划出全局路径(Routing)；然后在行驶过程中感知(Perception)当前环境(识别车辆行人路况标志等)，并预测下一步发展；然后将采集到信息传入规划模块(Planning)，规划车辆行驶轨迹；控制模块(Control)将轨迹数据转换成对车辆的控制信号，通过汽车交互模块(Canbus)控制汽车，如下图所示：
     

   • 各模块介绍

     1. 校准模块

        使用前必须对传感器校准和标定，包括激光雷达与摄像头、毫米波雷达与摄像头等；校准是对齐激光雷达、摄像头及毫米波雷达获得的信息；激光雷达可以获取详细的三维环境信息，但不能获得颜色信息；摄像头可以获取颜色信息，但无法获得深度等三维信息；毫米波雷达不能获取颜色信息，但可以获得三维信息；将三者采集的信息对齐后，就可以同时了解实际环境中的三维信息和颜色信息；

     2. 车辆CAN总线控制模块

        接收控制指令，同时给控制模块Control发送车身状态信息；CanBus有两个数据接口，第一个数据接口是基于计时器的发布者，回调函数是OnTimer；如果启用，此数据接口会定期发布底盘信息；第二个数据接口是一个基于事件的发布者，回调函数是OnControlCommand，当CanBus模块接收到控制命令时，会触发该函数；

     3. 控制模块

        基于决策规划的输出路径及车身状态，使用不同的控制算法来输出控制命令，如：转向、制动、加速等；有3个主要的数据接口：OnPad、OnMonitor、OnTimer；OnPad和OnMonitor是仿真和HMI的交互接口，主要数据接口OnTimer会定期产生实际的控制命令；

     4. 决策模块

        在接收全局路径后，根据从感知模块得到的环境信息，及本车当前的行驶路径等状态信息，做出具体的行为决策；

     5. 可视化模块

        查看规划的轨迹及实时的转向、制动和节气门信息；

     6. 驱动模块

        GNSS设备驱动，包括：NovAtel、Applanix、u-blox、激光雷达、Velodyne驱动，用来读取传感器内容并输出对应的消息；

     7. 人机交互模块

        可视化自动驾驶模块的输出，如：规划轨迹、汽车定位、底盘状态等，为用户提供人机交互界面，以查看硬件状态，打开或关闭模块，及启动自动驾驶汽车；

     8. 端到端强化学习

        端到端指：由传感器的输入信息，直接决定车的行为，如：节气门、制动、方向等；学习数据主要来源于传感器的原始数据，包括：图像、激光雷达、毫米波雷达等；端到端输入以图像为主，输出车辆的控制决策指令，如：方向盘角度、加速、制动等；

        通过深度神经网络连接输入输出两端，即神经网络直接发送车辆控制指令，从而对车辆进行横向和纵向控制，此过程没有人的参与；横向控制指：通过方向盘控制车身横向移动，即方向盘角度；纵向控制指：通过节气门和制动控制车身纵向的移动，即加速、制动等；横向模型的输出不是方向盘角度，而是道路行驶的曲率；

     9. 定位模块

        聚合各种数据以定位自动驾驶车辆，有两种类型的定位模式：OnTimer和多传感器融合；第一种基于RTK的定位方法，通过计时器的回调函数"OnTimer"实现；第二种是多传感器融合(MSF)方法，其中注册了一些事件触发的回调函数；

     10. 高精地图模块

         输出结构化地图信息，如：车道线、十字路口等；其显著特征是表征路面特征的准确性；

     11. 监控模块

         包括硬件在内的，车辆中所有模块的监控系统；监控模块从其他模块接收数据并传递给HMI，以便驾驶员查看并确保所有模块都正常工作；如果模块或硬件发生故障，监控会向Guardian发送警报，然后决定需要采取哪些操作来防止系统崩溃；

     12. 感知模块

         感知依赖LiDAR点云数据和摄像头原始数据；除了传感器数据输入外，交通灯检测需要依赖定位及高精地图，需要依赖定位确定何时何地开始通过摄像头捕获的图像检测交通灯。

         在感知模块中，Apollo平台有以下几个特点：

         • CIPV检测/尾随，可实现远程精确度；摄像头安装有高低两种不同的安装方式；
         • 异步传感器融合，因为不同传感器的帧速率差异，毫米波雷达为10ms，摄像头为33ms，LiDAR为100ms，所以异步融合LiDAR、毫米波雷达、摄像头数据，并获取所有信息得到数据点的功能非常重要；
         • 在线姿态估计，自动驾驶汽车在出现颠簸或斜坡时需确定与估算角度变化，以确保传感器随汽车移动且角度或姿态相应地变化；
         • 超声波传感器，作为安全保障传感器，与Guardian一起用于自动紧急制动和停车；

     13. 预测模块

         负责预测所有感知到的障碍物的未来运动轨迹，输出预测消息封装了感知信息；预测定位和感知障碍物消息时，当接收到定位更新后，预测模块更新其内容状态；当感知模块发布感知到障碍物信息时，触发预测模块实际执行；

     14. 通用监控与可视化工具

         包括一些可视化工具，bag包录制及回放脚本；