自动驾驶工程化落地的障碍还有哪些？宏观设计篇

作者 | Aimee

出品 | 焉知

知圈 | 进“计算平台群”请加微yanzhi-6,备注计算

本文主要从宏观层面分析整个自动驾驶开发的工程化落地的重难点，其中涉及行业内整体的V模型开发问题与挑战、系统设计中的场景设计重难点以及系统设计前端如何结合功能安全团队分析的过程进行详细的安全设计。整个设计过程在开发初始的左半部分是环环相扣，紧密结合的。

V模型开发的问题与挑战

汽车软件开发过程中的V模型对行业内人已经早已是司空见惯的模型。其核心思想是通过aSPICE流程来支持和管理整个开发流程，包括存档和制定计划等内容。从整个V模型上看，从需求到源代码的每个过程都有相应的测试。

重点关注系统到软件开发的左侧，按照“V-模型”指示需要实现的各阶段开发能力如下图。

使用ASPICE可实现目前在汽车领域大火的敏捷开发。过程是以灵活的方法从较少的要求开始，贯穿执行整个V-模型过程。那么，如何从敏捷的角度适配出合适的V或者类V开发模式呢？其实，比较简单那就是多v局部组合。因为敏捷开发的核心是在开发验证过程中实现多阶段验证测试。因此，对于V模型结合敏捷开发的改造优化模型应该是多W模型或者多V合并。根据上图的V-模型看，自动驾驶的开发与测试都存在一些挑战性问题。

撇开ASPICE不谈，单从整个开发过程评估整体开发能力可以实现多级评定机制。参照类似自动驾驶系统的分级机制而言，整个过程评定机制分阶段、分层级部署实现不同的过程能力。详细的流程包含如下：

为了解决这些问题，目前业界有提出了一些可用方法包括：通过依次松弛的操作场景的分阶段部署法；采用一种“监控-驱动”结构，将最复杂的自主功能和较为简单的安全功能分开；故障注入以得到更有效的边界情况（edge case）测试。驾驶员不在环情况等过于复杂的需求可以采用非确定性算法、归纳学习算法、故障注入、安全/可操作运算来实现。

客户需求定制--极端场景检测和确定难点

对于第一部分提到的V模型开发中，左半部分主要是进行客户需求识别，并定制化开发适合客户需求的功能场景。我们知道自动驾驶的下一个战场是对极端场景/边缘场景（Corner Cases）的有效检测。其核心是检测出未知期望或者未知场景工况。但是即便是在传感器如此丰富的今天，自动驾驶系统对于其检测能力适配整个功能仍然存在较多问题。

场景分类	工况	场景关键点说明	难点说明	解决措施建议
城市道路场景	无保护左转	1、十字路口识别（无专用信号灯，礼让直行车辆）； 2、提前向直行车辆传递左转意图； 3、判断左转安全距离并加速通过； 4、转向穿越后，立即减速避让行人和非机动车；	1、传感器缺乏超视距感知，无法提前获取被遮挡执行车辆（包含直行来车的距离、速度及减速意图等）； 2、转向控制下，行人、非机动车运动识别情况受限（包含行人眼神、挥手及减速意图等）； 3、人类驾驶意图无法准确识别导致决策能力受限；	1、增加车端传感器的分辨率/点云密集度； 2、融合路端感知能力以及其他车辆数据，优化单车智能控制；
环岛控制	1、驶入环岛前，变换到可驶入环岛入口车道； 2、无红绿灯指引完成斑马线礼让行人、非机动车； 3、第二个让行标志前礼让正在环岛上行驶的车辆，并伺机驶入环岛道路； 4、环岛内行驶时，选择驶出环岛的内、中、外侧车道，做到提前变道；	1、环岛内侧行驶：工况简单，但变道次数增多；对轨迹规划控制决策提出较大挑战； 2、环岛外侧行驶：工况复杂，随时有入口车辆驶入加塞等，但驶出环岛容易；对近距离感知及决策控制提出较大挑战； 3、车辆驶出环岛意图传递受限；	系统开发过程中，有效的选择变道驶出的时间点，及时传递驶出环岛意图并安全快速驶出环岛，同时注意斑马线处的行人；
高速路/快速路场景	匝道控制	1、提前2km之前识别匝道； 2、提前变道至匝道最近的车道； 3、提前减速至匝道要求的车速； 4、减速后驶入匝道并适时持续减速控制； 5、（可选）匝道内持续对中控制，并向内侧有一定偏移； 6、驶出匝道提前感知分岔路执行车辆，并适时加速至目标车道；	1、匝道提前检测定位； 2、多车道变道行驶决策能力；（场景中两次变道存在一定时间间隔，如果车道数过多可能错过匝道口）； 3、匝道限速控制（有可能边减速边变道，存在一定风险）；	1、融合高精定位及导航数据提前定位匝道信息； 2、增加视觉感知能力（如高分辨率摄像头），提前探测匝道限速信息； 3、通过多曲线拟合提前预瞄变道轨迹，提前判定入匝道变道风险，提前规划入匝道能力；
并道控制	1、提前检测前方道路变窄迹象； 2、提前检测旁车道路况； 3、适时发起变道控制； 4、适时提速/减速并与并道目标车道保持同步；	1、车道宽度检测距离不足（一般依靠摄像头感知能力只能检测到前方200m左右距离车道宽度）； 2、并道属于被动发起变道，可能直到本车道消失，仍无法顺利并道入目标车道，车辆有一定风险；	1、融合高精定位地图提升对车道信息的检测能力； 2、增加视觉感知能力（如高分辨率摄像头），提前探测车道宽度信息；
恶劣天气	雨、雪、雾、粉尘	1、摄像头探测能力受限； 2、激光雷达探测能力受限；	1、激光雷达采用近红外光，其传播易受雨雪雾等恶劣天气影响；包括小雨导致激光脉冲散射导致能量衰减，容易导致漏识别；中大雨导致激光脉冲回波能量变强，穿过雨滴脉冲能量变小，容易导致虚假障碍物； 2、摄像头探测容易受到大雨直接影响，造成探测能力受阻而造成模糊等； 3、当雪开始在路面积聚遮挡车道线时，基于车道线的的定位、可通行区域判断将会失效。	1、通过多次回波测量算法过滤雨滴散射后的回波脉冲，甚至通过波形hi别可有效减少误识别； 2、增加雨量传感器、雨刮数据等信息输入识别实际环境雨、雪天气等，减少对激光雷达、摄像头感知数据的置信度，增加对毫米波雷达、高精定位信息的置信度；
不规则路面	坑洼、突起、断头路等	1、通过传感器识别路面状态，并及时发送给控制端； 2、控制端根据实际车身姿态、加减速度、距离等判定适时的风险规避措施；	1、识别路面实际状态是个大难题，因为未曾被训练过，很多奇异工况，系统根本无法理解； 2、即便能够理解实际路况，单纯从系统的角度也无法十分智能的决策哪种措施更好：比如前方有异型障碍物，当识别到后是选择转向还是避撞那种造成的危害更低。	1、前期进行数据闭环，丰富对这类路面的识别逻辑； 2、系统功能设计中，多探索与之相关连系统的控制逻辑优势，实现控制优化；比如结合底盘智能悬架技术，提前识别前方坑洼目标后，提前举升车辆以规避入坑产生的较大颠簸。

对于系统开发层面来讲，通常由于缺乏包含所有类型边缘场景的大规模数据集，各个与自动驾驶测试相关的corner cases检测通常是一个开放世界问题。因为有些CornerCase倾向于关注集中样本特性，比如某一类异常车辆识别、某种异常车道识别、某种异常道路标示识别等等。而有些Conner Case则是更加倾向于从现实世界去推理出未知世界的内容。比如从当前前车急减速工况推测前方可能出现不可知的车祸或类似施工区域的部分。又或者从BEV建图后推测前方是否存在断头路等等。此外，对于城市道路自动驾驶而言还包括了诸如无保护左转、环岛、人车混流、狭窄路端超车、大型路口掉头等复杂工况下得自动驾驶能力。甚至这些能力对于手动驾驶都存在一定问题，当然就会成为整个自动驾驶系统开发的挑战。

目前看来通过无监督方法或者仅在正常样本上训练异常场景的方法是最有效检测边缘场景的方法。过程中依赖于异常场景数据训练过程中需要相对较为复杂、专业的训练集。

以自动驾驶系统相机为例，如下列举了典型的几种检测极端场景过程。整体来说主要包括未知场景、新颖场景、风险场景、目标对象、作用域、像素级/点云别场景等。而针对这些一常场景的检测主要包括预测、重建、自发生成、特征提取、后处理、置信度求解、场景自学习等。

1、像素级/点云级场景分析

对于像素级/点云级这类微观的场景检测方式，通常是针对图像或整个激光成像过程的，其中涉及诸如图像曝光度，点云实时检测，像素损坏/不清晰等等这类微观场景。以修复受损像素所显示的场景为例，前面我们讲到可以通过自学习来进行场景识别，那么怎么做呢，这里可以通过自监督学习来进行像素修复。方法是通过模拟相应像素的可能性，加入同类型像素，并逐个像素进行标注，从而给出损坏像素的位置，与实际位置进行比较。一些情况下，实际位置与根据光流学习得到的预测位置不会完全一致，甚至相反。这时就可以通过语义分割方法来处理检测问题。

提到语义分割，我们通常会想到一个常用的方法就是特征匹配，也就是从所识别到的图像中通过寻找合适的损失函数，将所检测到的感兴趣区域与SoureDomain中的样本进行比较，然后以损失函数最小的代价得出相应的匹配特征值。

2、目标级场景分析

这类检测过程其实很好理解，就是针对之前未检测过的目标和对象场景进行识别（比如我们自动驾驶经常会遇到前方出现异常障碍物，如掉落轮胎、落石、异型车等），这类目标如果依靠纯视觉感知，很多情况会被误识别或者直接漏识别。我们知道，对于场景识别过程不能完全依赖于无止境的丰富极端场景的训练样本来作为场景库。因为对于现实世界而言，永远没办法穷举所有未知场景工况，这时我们就需要注意，是否可以通过将每次出现的未知工况进行自监督学习。在学习过程中，通过贝叶斯置信度得分，求解一个与那些未知目标相关的高不确定性模型，这类模型虽然不具备与场景库中完全的一致性，但是自监督学习结果却是可以为下一步感知输出提供必要的备证。

在智能汽车视觉感知中，我们常用的特征提取很可能无法捕获整个场景的复杂性目标。因此，许多现有方法给出置信度得分或目标重建误差值等手段来区分正常样本和异常样本。上述深度学习过程中得出的置信度得分和误差偏差值可以有效表明模型的不确定性，得分低或偏差值大的目标可以直接定义为异常场景，这类异常上下文的场景工况中通过监督训练可以直接定位到相关异常目标。

3、帧间级场景分析

这里为啥专门提到帧间呢，是因为前面两种情况都是涉及图像级别的检测能力。通过也是在图像中识别ConnerCase的异常目标物。但是，接下来的帧间场景分析则是为了从类似光流的角度出发探讨整体视频流的异常工况，他的范围限定是以时间轴出发的。为什么这么说呢？因为对于整个视频流分析而言单帧并不存在任何异常，但是整体就是极端异常的。

这里举个例子，比如前方急减速车辆，对于单帧图像而言只是识别到前方的一个车辆而已，而对于整个感知而言，则是需要考虑利用帧间图像匹配方式识别出汽车的减速运动趋势（当然如果期间有雷达数据也可以进行融合）。这种减速趋势过于猛烈则说明前方有异常的CornnerCase出现。

这里对于整个视觉感知的帧间异常而言就有多种方式可以介入，首先最常用的还是帧间运动估计（motionestimation）, 其核心是直接通过查找两帧之间相同的像素或分割图像块在两幅图像中的不同位置，然后相减得到相应的向量估计。这个向量乘以投影矩阵的逆就可以认为是现实世界中的车辆运动向量。当然，评估其是否为CornnerCase的方式就是当该向量与前一时刻向量比较出现较大偏差时，肯定就是异常工况出现了。那么我们的感知训练模块可以给出一个策略目标。

这里需要注意，有些帧间场景分析寻找Corner Case时，可能突发状况会完全不受控。例如，从遮挡车辆后面突然跑到街道的行人（自动驾驶领域有个专用的名词叫鬼影），需要识别由于被遮挡或不在视场范围内的场景像素，而这类像素却未包括在前一帧的逐帧像素掩码中。因此过程中要求在极短时间内，当帧中仅出现行人的像素时，就可以实现有效的检测。这就要求不仅是别需要极快，而且还需要实时的智能学习该场景的异常表象信息，而这方面能力还需要有非常大的能力提升。

检测corner cases包括在线和离线方法，在线情况是可以作为安全监控和警告系统，离线情况是用于实验室开发新的视觉感知算法，选择合适的训练和测试数据。

怎样设计真正的安全控制系统

主机厂为了将自己的产品推进准入，通常要提供相应的安全评估报告和准入申请书，其中不乏涉及到对自身产品安全性的说明。主要包括如下几个方面：

安全冗余系统实际上是一种系统状态“即当给定的控制任务无法完成时，可能导致碰撞风险。比如，对于L3级自动驾驶系统而言，当接近ODD出口或出现自动驾驶故障时，一个善于接受的“应变准备就绪用户”，应准备好接管驾驶任务，这时需要自动将车辆停在其当前行驶车道或靠边到旁车道”。

为了对整个安全冗余系统进行有效分析，主机厂会通过功能安全进行危险分析和安全风险评估（hazard analysis and safety risk assessment）。这个评估制定了关于整个系统研发中的硬件功能安全等级和软件功能安全等级。对于高度安全相关的功能，内置了特定的冗余，以便这些系统的故障不会造成不合理的安全风险。

对于当前研发自动驾驶系统面向服务SOA的架构来说，从功能安全角度来看，也会设计服务发现同时支持“动态发现”与“静态配置”两种方式，以起到在服务访问过程中就能实现冗余备份的作用。比如，当雷达感知数据和摄像头感知数据两个服务访问之间，通过“动态发现”来实现感知数据融合时，可能出现诸如“服务名称错误”、“广播丢失无应答”等故障时，则必须允许最基础的服务部分（如雷达基础状态数据）通过“静态表”被发现。

如上提到的服务名称错误在整个满足功能安全要求的冗余设计中也是有相应的需求的。比如按照不同功能安全要求，“名称服务”至少要有一个备份的实例才能满足在主服务名称访问失效时，可以通过备份名称访问对应内容的服务。且关键服务必须要有多个实例存在，其提供的服务名称、标识、方法、事件等等都必须一模一样。

这里我们需要列举几个典型的例子：

1）故障运行（fail operational）

以自动驾驶系统故障运行响应为例，这类设计原理实际时考虑了纯双冗余系统的模式，对于很多主机厂而言，设计这类系统实际是需要充分将六大冗余设计概念步步到位的设计到整个架构中的。除开我们传统方式要求的通信冗余、制动冗余、转向冗余、电源冗余外，最重要的就是在域控制器内部所需要完整的实现感知信息冗余和控制指令冗余。在下一代高性能计算平台中，其感知系统涉及多方面的信息输入，且各自位于不同的内部芯片中，比如对于不同的SOC而言，需要同时接入不同的传感器信息，以确保最终的传感器信息能够在其中一个SOC出现感知信息处理故障的时候，保证该传感器所需要的信息还能够在另外的SOC中被及时的处理到位。即比如在设计自动驾驶传感器架构时，通常会考虑在主探测传感器（如摄像头）在SOC#1号发生故障过程中，该摄像头同时接入点SOC#2可以及时的处理并弥补该传感器信息的探测缺失。此外，SOC#3还可以通过其他互补传感器（如激光雷达）的持续性探测保证系统安全运行，这整个控制能力完全未受影响，该过程甚至不会被驾驶员所感知到。

2）故障安全/故障降级（fail degraded）

故障安全则是相对于故障过程的另一个比较典型的安全冗余设计。这种控制逻辑下，系统将不再能够正常的控制车辆持续运行了。这里很有可能不仅是某个感知端无法正常提供数据用于规划控制，更多的可能是整个主域控出现了不可逆转的问题了。

为了应对这类故障安全问题，很多主机厂在设计端就通过既定的预期功能安全设计，当前，对于OEM来说，SOTIF仍旧是一个设计之初比较难以完美解决的话题。因为，通常的系统设计会对目标场景考虑的不周到，系统也无法对环境做出正确响应；同时，功能逻辑仲裁、算法不合理，也会导致决策出现问题；此外，执行机构的输出与理想输出发生偏差，难以完美控制也会导致整个系统不安全。对于如上问题的分析解决过程，以预期功能安全所涉及的方面，是完全可以通过分析预先功能的剩余风险，验证已知情况下的意外行为，验证情况的确认那些可能导致意外行为的剩余未知情况。从而做到覆盖已知安全，解决已知不安全，识别未知安全，探索未知不安全几大方面问题。

3）安全责任设计（fail safe）

这里的安全责任是不仅从法律上，也涵盖了道德层面的分析。前面提到的无论功能安全还是预期功能全都是考虑了系统中电子电器故障、通信层面及基础控制逻辑上的安全运行问题。那么问题来了，如果考虑是否能够正确控制的层面呢？比如，车辆运行过程中，监测到超出ODD范围，需要驾驶员接管（但是系统本身并无相关故障，不算异常失效），那么整个过程还需要系统持续性的控制车辆自动行驶，直到驾驶员正常接管车辆为止。那么这整个过程要怎样完成安全控制呢？又会提出那些关键需求？这种安全接管能力控制需要系统提前具备哪些能力呢？这些都是我们要思考的问题。此外，对于智能车辆控制而言，如果在行驶过程中，为了避免与可见的危险情况发生碰撞而制造了另一个不可预知的碰撞，（比如识别到前车紧急制动，为了避免与前车碰撞，自车不得不紧急制动，但是有致使后车撞上了本车，如果转向变道，可能会规避此风险，但是也会造成另外的变道风险，也有可能导致错过路口等不利因素。）那么在设计之初是否会同步考虑将安全风险、运行效率和道德层面要素都考虑进来呢？这些都是我们值得思考的问题。

对于下一代自动驾驶系统来说，需要准确升级整个ODD/OEDR的应变能力，其提升过程包括把系统性地当前智能驾驶系统中为解决的相关ODD外的设计问题暴露出来，看看系统接管的性能是否满足要求。系统性的训练和测试系统对于极端工况的目标事件监测和反应能力，评估系统的响应是否正确。