学习笔记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采用的解决方案及其优点如下表所示：

     非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模块构成

   • 软件组件

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

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

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

• 可运行实体(Runnable Entities)

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

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

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

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