揭开那层面纱，自动驾驶可靠性就是这么简单！

怎么才能让用户放心的让车辆接管驾驶呢？

从预期功能安全（SOTIF）的角度来说，这个问题其实是个确认措施的实施问题。

如果我们想要证明一个自动驾驶的功能至少和驾驶员一样可靠，需要积累数以亿计里程的功能开启安全记录。从这个意义上来讲，确认测试将是一项长期的，持续性的工作。与提供出行服务的公司压力有所不同，吉利旗下品牌每年的车型出货量对比出行公司初期不到千台的车辆数量 —— 如果出行服务技术公司一年出一次事故，那恐怕每一天吉利车型都得上新闻。

面对如此复杂的挑战，仍然只能从将大块儿的问题分解为独立的一系列小问题开始。简单具象地描述自动驾驶功能和架构虽然困难，但我们可以简化为环境感知、策略规划、执行控制三个出发点，分模块地确认自动驾驶功能的能力。

执行控制长期以来就在进行非常苛刻的验证测试，我们做智能驾驶方面的开发工程师会将更多的精力倾斜在前面两个方面，着力确认我们的感知系统没有误读环境，我们的策略规划没有关键时刻“犯傻”。

有一个很简单的评判标准可供参考：足够证明可靠性的里程数据。自动驾驶有五种方式来做长期可靠性的确认，分别是长期的试验场测试、道路测试、仿真测试、影子模式、降级开放。其中后三者是自动驾驶系统着重在意的新兴领域。

实际的仿真测试包含两种数据输入来源和三种结果确认方式：使用实际录制的真实数据和使用计算生成的虚拟数据两种数据输入来源；将仿真的测试结果和有实验驾驶员、参考系统的结果、假定结果对比三种结果确认方式。

提起仿真测试，大家可能都会觉得给自动驾驶做仿真测试应该和让电脑自己玩侠盗猎车手差不多。然而实际情况远不止这么简单，如果真的每天只做个陪练，看着电脑自己玩游戏的话，工程师的工作就不会那么忙了

但话说回来，“AI玩侠盗猎车手”式的测试也是要有的，实际上它是一种使用计算生成的虚拟数据作为输入，和假定的结果做对比确认的模式。这种模式做的过程很轻松欢乐：把带有自动驾驶能力的车辆扔到一个虚拟的环境中，让它和算法生成的交通流搅在一起。这种方式可以确认我们是否有充分考虑工程师有没有把车辆行为的参数设置到合理的状态—— 譬如跟车巡航状态时，是否会出现在颠簸的路段上因为目标距离估计的不稳定而产生异常的加减速呢？

当然只有这种模式是不够的，毕竟他还无法覆盖足够多样的环境，也无法重建出如现实般丰富的车辆传感器输入。我们投入了数十PB 级的数据中心，来建立实验数据库。道路试验中，设备会记录车辆的所有内外部状态信号。数据被转移到数据中心后，会结合自动化的方式对数据进行标注，为以数据回放为输入的仿真做好准备。

为了验证安全机制的有效性，在回放数据测试的过程中，会使用算法对原属数据进行干扰，进而测试我们工程师设计的安全机制的有效性。你可以大致这么理解，你在走路的时候不停的有人推搡你看你是否摔倒，很简单粗暴，同时相当有挑战性。

此外与传统的HIL 测试有所升级的地方还在于以往HIL 跑case 的方式是无法遍历无限变化场景的，使用带有权重的蒙特卡洛采样方式使得我们可以巧妙的用有限的计算时间覆盖更加具有挑战性的场景。

仿真虽好，但我们也并不迷信。道路试验除了为仿真测试采集数据之外，本身也肩负着测试系统在实地中工作的重任。与仿真不同，道路测试面临苛刻的自然环境挑战。然而想发现我们的试验车辆可没有那么容易 —— 适用于大规模量产的自动驾驶系统不会采取外置大量传感器的感知系统布置形式。视觉会躲在挡风玻璃之后，微波雷达会藏在保险杠内侧。甚至连激光雷达我们也更喜欢悄悄的躲在车标背后的空间里。在第一代可释放双手的自动驾驶功能上市之前，将会至少完成五十万公里以上的功能道路里程。

影子模式是很多主机厂都在引入的功能确认方式。在这种模式下，功能会在车辆满足ODD 的条件下隐式的开启。除了会记录一些场景特征之外，还会匿名的记录一些功能对车辆操作与驾驶员的差异。我们真的很重视用户的隐私，不会区别驾驶员的身份。

自动驾驶功能在道路测试、仿真、影子等种种测试方式的确认之后，最终还是要交付给用户的。而没有实证的系统就是没有实证，小心翼翼地选择降级的、逐步的开放策略是我们必然要走的过程。

正可谓路漫漫其修远兮，吾将上下而求索。

分享没有终点，在接下来的时间里，我会持续更新，与行业内专家和知友们沟通想法，希望可以不断碰撞出思考的火花，大家如果感兴趣，可以关注我。

【文章转载自知乎杭州湾汽车人】