自动驾驶工程化落地的障碍还有哪些(二)：微观开发篇

​​前面的文章有提到过关于很多智能驾驶汽车开发过程中需要解决的常见问题​​，其中就包括在典型（如高速路、快速路）的场景中解决感知、定位、预测、规划决策和控制相关的问题，也有专门提到针对执行能力控制设计中需要考虑的线控底盘等解决方案。

此外，对于外围传感器的应用也显得更加集中化，其中包括HDR摄像头、固态激光雷达、4D毫米波雷达等的应用也受到各方的重视。在开发中，将整个能力建设放置在中央域控制器中，确保局部集中化算法能力开发得以实现。

不仅如此，自动驾驶系统还有相当部分的极端“长尾”场景还没有得到充分的解决，比如在极端场景（如施工路、城市路）中解决对应的感知类问题。又如，如何构建数据闭环的持续高效研发框架也成为了行业共识。在此过程中，实现自动驾驶技术的阶段性落地需要以标准化、平台化设计为基础，打造量产规模化、落地商业化的开发能力。无论是成本、车规要求满足以及OTA等都需要取得最优进展。

AI模块化处理能力优化短板

一提到AI模块化处理能力我们就需要从三个层面进行区分，其一是传感器（如相机、雷达等）标定；其二是视频数据压缩，其三是AI模型加速。这里的AI实际上是广义AI，即既包括视觉AI，也包括激光点云或毫米波雷达点云几个方面。

对于第一个传感器标定为何要单独提出来作为AI模块化处理能力的部分进行说明，这是因为传感器标定的准确性。特别是针对摄像头感知来说，两者有一定关联却又是不尽相同的两个问题。压缩的目的在于减少网络参数数量，而加速的目的则是降低神经网络单元的计算复杂度，提升数据并行处理能力。

如上图所示关于AI模型加速是整个需要重点考虑的要素如下：

1）减少冗余参数：通过一定算法和样本探索模型中的参数冗余，并尝试去除其中的冗余参数。这些冗余参数可以是不重要的、重复的及不相关的参数信息；模型参数一版都采用32位bit浮点（FP32）格式表示，而这种类型的格式表示通常会有精度损失，且计算量较高。为了减少内存占用及计算功耗，并进一步减少精度损失，在参数优化过程中通常采用定点格式代替浮点格式。

2）降秩分解：CNN模型信息参数估计通过矩阵、张量来进行有效分解；分解过程中，每一层对准确性都有不同影响，因此可以使用细粒度混合精度量化方法，其中，每层权重和激活值位宽都不同。

3）卷积滤波器优化：在卷积计算过程中，通过设计特殊的结构卷积滤波器，以减少参数空间并节省存储和计算；基于CNN检测器的轻量化方法是直接设计一个轻量级的网络，而不是使用现成的检测引擎。

长期以来一直在探索网络的正确配置，以便在有限的时间成本下获得准确性。一个通用的设计原则是“更少的通道，更多的层(fewer channels and more layers)”。整个卷积优化方法包括分解卷积、批量卷积、神经结构搜索、神经结构搜索等几个大方向。

分解卷积优化：是将一个大的卷积滤波器分解成一组空间维数较小的卷积滤波器，如上图(b)所示。例如，可以将一个高维过滤器分解为多个低维过滤器，它们共享相同的接收域，但是后者效率更高。在分解卷积过程中，还可以通过频域变换后进行数值加速。

批量卷积优化：将一大组卷积分解为信道位数较小的n组，然后分别对各m组进行卷积计算，从而减少卷积层中的参数数量，在不改变其他构型，理论上卷积的计算复杂度可以降低到原来的1/n。当然利用深度可分卷积是假设数组等于信道时，在每个通道中对滤波器的每个片分别进行卷积。将计算复杂度进行指数降维。

此外，通过压缩检测器的输入层，以减少从检测管道开始的计算量。也可以压缩检测引擎的输出，使特征图变薄，使其在后续检测阶段更加高效。

神经结构搜索：即通过自动设计网络体系结构代替原来在神经网络结构参数计算中对于经验和先验知识的依赖，在搜索过程中考虑了预测精度和计算复杂度的限制，这将有利于大规模图像分类、目标检测和图像分割任务。

4）自学习模型提升：机器学习能力提升需要训练更加紧凑和精确的神经网络；这一过程涉及将深层网络压缩成浅层网络，其中压缩模型模拟了负责模型所学习的函数。

降秩分解过程和卷积滤波器优化主要针对端到端的设计框架，可以由CPU/GPU通过一定的运算轻松实现。参数修剪过程需要采用降维、稀疏矩阵化、编码优化及矢量量化等几个方面。

数据闭环平台设计缺陷

对于要实现真正的自动驾驶甚至无人驾驶，其重要的一环就是考虑如何设计可靠的系统处理边缘场景CornerCase。这里，我们又称之为长尾效应。我们知道大量少见的极端情况无法被有效处理。因为前期没有搜集到足够的用于开发的训练数据，而这些开发数据要求我们在一个闭环中不断的发现有价值的数据，然后标注这些有价值的数据并放入到训练集中，同时也放入我们的测试集或者仿真数据库中，在CNN或RNN模型得到迭代升级后，会在交付到自动驾驶实车后便进入新的循环。

数据驱动的时代，OEM普遍面临多个痛点及建议解决方案：

1、缺乏数据闭环经验

数据挖掘中主要涉及对高效难例场景挖掘迭代。包括400+场景标签,场景库构建。端云实时同步挖掘规则，难例场景归因及迭代更新。由于数据闭环涉及大量的数据计算和处理，通常不会在单车/单机中实现所有处理。需要的是一个云计算/边缘计算的大平台，在数据批处理/流处理、工作流管理、分布式计算、状态监控和数据库存储等方面提供了数据闭环的基础设施支持。在开发过程中，是否能够做到自动数据挖掘将原始数据通过图片抽帧放入GPU集群，然后通过以图搜图、CV分析、模型感知后生成特殊目标标签、图像去重、图像质量标签、主动学习标签、场景描述标签、目标统计标签等。

很多主机场对于从０到１的数据模型搭建过程存在一定困难，如何挖掘数据价值方法也不明确，仿真评测标准不够一致，影子模式经验缺乏。解决这类问题需要开箱即用的SaaS平台，赋能经量产验证的闭环范式，端到端的全链条评测体系，端云一体化方案，模块化部署，全面开放API接口等。

2、数据安全合规问题

采集数据通常是不能直接用于算法构建的，其中涉及相关法规约束，缺乏相关经验，数据脱敏流程和资质就无法实现数据的有效处理。针对这类问题，可以利用甲级测绘资质支持权限管理及多租户隔离数据脱敏及分级分类。

3、投入成本高，价值创造不明确

投入成本包括算力、存储成本的增加，人工数据标注成本高、流程无法自动化，GPU利用率太低。对于这类问题可以采用自动化数据清洗及冷热分层存储DAG工作流效率提升明显，且集群管理GPU分配率也可以大幅度提升。

对于完全以数据驱动的开发模式，是否创造差异化亮点，目标收益不明确，数据是否有衍生价值，这些要素都不确定。解决这个问题需要差异化亮点打造经验，研发收益指标及效益展示数据衍生用途赋能。

4、AI自研门槛高

模型训练是数据闭环的核心，在云端部署深度学习模型训练时一般采用的是分布式方式。即按照数据并行（多GPU处理不同网络层）和模型并行（多GPU副本负责不同数据处理）两种方式将GPU处理数据的方式进行不同分层。对于数据并行处理而言，涉及到每个GPU之间如何进行模型参数是同步处理还是异步处理。从数据筛选标注、模型训练到发版通知，其研发效率提高很多倍。

针对数据算法人力等基建不足，验证周期较长等问题，需要持续性的增加数据/场景/算法赋能，快速部署验证实例。实施完整的数据管理及挖掘，包括完整的半自动化数据标注平台，加强对训练模型的参数精细化引用，量产触发场景的自动化处理，支持训练过程的数据回灌及相关设备管理等。

5、全链条问题分析评测效果

对于数据闭环需要考虑的量产车/采集问题数据可视化管理，问题数据自动化分类追踪等问题，需要构建关键场景数据库，自动化CI/CD回归报告，集成多维标注的纯视觉GT评测，支持动态障碍物、静态目标、车道线、定位评测等多方面应用。

如何应用好中间件平台

由于目前很多OEM已经开始采用自研域控的方式进行高性能计算平台设计，因此，其中涉及的AI芯片及其SOC、传感器技术的研发进程也取得阶段性成果。比如SOC以国外为首的英伟达设计的Xavier、Orinx，以国内为首的地平线征程系列，黑芝麻的华山系列，华为的麒麟芯片等都在智能驾驶行业内取得了不俗的表现。部分已经在OEM中实现了量产。比如小鹏P7使用Xavier（30 TOPs）实现了自动上下匝道功能的智能驾驶量产，理想One使用J5基本实现了下一代自动驾驶高性能计算平台的设计，长城也首次使用高通Snapdragon芯片实现了自动驾驶系统架构高性能计算平台设计开发。

下一代自动驾驶系统开发中，为了更加灵活、高效的开发应用软件，需要在不同的技术之间共享资源并管理整体网络通信。作为独立于操作系统的软件框架，其正常运行于网络、操作系统及基础数据库之上，应用软件之下。很好的为不同开发上提供对应的软件模块，用于统一标准、分散实现以及集中配置，同时十分有利的实现了软件更新和升级。但是中间件实际上有各种不同的实现模式，如实时车载操作系统RTOS、机器人开放系统ROS、经典的汽车开放架构Classic Autosar和自适应的汽车开放架构平台Adaptive Autosar。

1、广义中间件——操作系统RTOS&ROS

由于自动驾驶、车联网对车载端的数据处理实时性要求较高。为了更好的支持这类开发应用，车载操作系统必然是实时操作系统（real time operating system，RTOS）。RTOS是一种通常没有缓冲区延迟的操作系统，具有最小的中断延迟和线程切换延迟，可以很好为实时处理数据的应用程序提供服务，且处理时间要求仅为（包括任何OS延迟）0.1秒甚至更短。

机器人开放系统Robot Operating System (ROS) 是一种成熟且灵活的控制编程框架。在ROS的官方网页上有着大量的开源软件库，在很多国内很多不具备Autosar开发能力的tier1那里就可以很好的配置和开启一个自动驾驶项目。然而，即便应用成熟度和便利性更大，ROS仍旧存在一些无法解决的开发问题：

其一，单组件依赖性高，容易单点失效。由于ROS应用完全依赖于一个软件组件核心来处理其中不同模块之间的进程调度；

其二，不安全性。目前ROS无法有效组织第三方进入ROS网络，节点间读取过程通信也无法实现；

其三，工作模式相对单一。需要指出的是ROS的组织架构由组织信息收发的Topic和系统周边的各个节点node组成。虽然也引入了服务的概念，但是其工作方式仍旧相对单一，采用的是发布+订阅的模式进行节点间通信。比如，自动驾驶内部的摄像头传感器数据作为ROS的其中一个节点Node，其对外输出的信息模式通常是以信息流的模式发布其所获得的相关信息，且发布的信息的流入节点可能是用于融合的模块Node，也可以是另一个用于显示的模块节点。一个topic可以连接多个node，一个node也可以对接多个topic。

如上说明，尽管引入部分SOA的概念，ROS要适配更多更大更前沿的自动驾驶项目应该还是会比较吃力。因此，很多单纯用ROS开发的开发商都已经向更加先进的汽车开放架构Autosar进军了。这套标准源自于国外主流车企，在国内的开发商中还没有哪家真正做到了极为成熟的将Autosar应用到自动驾驶的开发中。

整体来讲，ROS和Autosar在一定程度上存在不同的着重点。

对于ROS/RTOS这类操作系统重在响应速度，而不是执行的工作量。因此，其短板也有所体现，那就是大规模数据驱动调度是做不到的。为了弥补这类缺陷，通常有如下两种模式的中间件架构可以供开发商或车企进行选择。

2、CP Autosar和AP Autosar

相信CP和AP两种模式的Autosar对于业内并不陌生，对于已经广泛应用于互联网的经典Autosar而言，其应用于车端也是手到擒来的事。然而，以面向服务应用SOA为核心的应用自适应应用开发中间件AP Autosar而言，开发起来也就并不是那么容易，并且容易在开发过程中出现很多的问题。

其一，就是由于SOA具有松耦合的特征，也就是其定义的中间接口适配应用程序软件组件SWC和功能Function，没有强制绑定，底层的SWC模块是通过接口暴露出去，只要上层应用能够定义出适配该底层协议的接口程序就可以很好的调用底层软件组件。

看到了么？这种模式有着很明显的风险，那就是容易受到黑客攻击。因为只要接口协议模式暴露，尽管底层是黑盒，仍旧可以通过调用其功能对车辆进行控制。因此，对于下一代自动驾驶系统来说，想要很好的利用SOA的架构进行开发，解决调用过程中的网络安全、信息安全就显得尤为必要了。

此外，由于程序之间的调用都是采用中间件模式进行。虽然有多种形式的服务访问方式（比如Method/Event/Field/Eventgroups），但是服务调用过程仍旧需要一定时间的通信建立与服务转发等。这种模式下，就会导致整个过程中存在较大的时间和信息延迟。这对于争分夺秒地自动驾驶开发来说有可能是致命的。因此，想要很好的解决这类问题，除了提升调用算法本身执行效率外，做一些记忆模式的常规调用缓冲池也显得比较靠谱。

此外，对于AP Autosar而言，其主流通信协议为Some/IP，这种协议适用于SOA的服务调用模式，但是对于数据通信效率和数据安全确实个大问题。相反，DDS作为一种成熟的数据分发系统，已经在CP端应用了很多年了，因此，能够达到很好的执行效果。但是DDS在AP端却很难适配起来。目前业界已经有人在研究将DDS的各宗优势部署在AP Autosar上面。当然，实现这个过程相对还是比较漫长。

这里我们不得不提到关于AP Autosar的平台配置与开发应用，其中包括提供高性能计算与通讯机制，提供灵活的软件配置，远程软件更新等。AP Autosar在自动驾驶中的重要性不言而喻，他不仅是对于计算能力和带宽的有效支撑，也尽可能地从其他领域（如消费电子产品）的发展中获益，且仍然着重考虑了汽车的特定要求，如功能安全、信息安全等。对于AP Autosar而言需要支持的服务是可以在Autosar Runtime  for Adaptive Application（ARA）上跑起来的，且其中的两类功能集群可以提供一系列应用接口。该功能集群可以是自适应基础功能和自适应平台服务（对于一个应用而言，可以自适应的为其他应用提供服务时，这类型服务称之为自适应平台服务）。此外，在AP Autosar中，通常是将硬件看作机器（Machine），如何配置高效的Manifest程序文件驱动机器运行，也是各家开发过程中的重难点。其中重点涉及通过各种管理程序执行相关技术的虚拟化，实现一致的平台视图。

总结

对于自动驾驶的量产开发来说，其实并非一蹴而就的过程，过程中会涉及多方面的曲折。​​除开前序（一）提到的系统设计、场景等方面的问题外​​，其应用算法设计以以及很多从平台底层、就可能存在的问题需要一一解决。特别是将纳入人工智能后可能存在的一系列开发短板将成为整个开发过程中不得不面对的重大问题。我们希望的是在开发之初或过程中就能完全被看到和识别，将问题解决于萌芽阶段，避免后期做大量的设计变更，产生更多的成本损失。

文章转载自公众号：焉知智能汽车