智能驾驶系统是怎么被设计出来的？

本文来自郭继舜分享的部分内容节选。6月8日晚，「X研讲」第一季第一期邀请均胜电子副总裁郭继舜分享

核心观点：

产品定义包括目标、逻辑、结构、功能，系统设计包括功能模块、实体设计、逻辑关系、核心架构。

我们要为可能的所有用户设计安全的产品，为目标用户设计舒适度更高的产品。

L3智能驾驶不是一个好的产品形态，L2++及L4将长期共存。

01 什么是智能驾驶产品定义和系统设计？

首先，要知道产品定义是做什么，系统设计怎么做。

产品定义与系统设计是相辅相成的。在实际过程中发现无法孤立地先做产品定义，再做系统设计，特别是在软件定义汽车阶段，原因在于有非常多的想法和创意。

例如一键超车功能功能，它可能是一个比较好的产品定义，但它在系统设计方面非常难做，尤其是在安全性、人机交互、稳定性等方面。

因此，我们将产品定义和系统设计做成一个循环，一方面由产品经理提出产品定义，另一方面系统工程师和工作安全工程师对于系统设计做一个推演之后重新回溯给产品工程师，最后形成可行方案。

那么如何设计智能驾驶产品？

运用马斯洛需求理论，从底层的生理需求到安全需求、社交需求、尊重需求、自我实现需求，最终实现让智能驾驶产品有持续成长性。

产品定义之后是系统设计。

需要注意的是，系统设计在生命周期里处在相对前期，后续可能还有OTA 升级，但在 OTA 升级过程中，我们更多时候是在前期进行充分的硬件预埋和接口预留。同时需要重新走一遍系统设计过程。

在智能驾驶产品生命开发过程中，分为三个方面的需求：

需求挖掘，目的是让系统工程师看得懂；

系统需求定义，主要是让测试人员看得懂；

系统架构设计，让程序员看得懂。

不懂产品设计的系统架构师不是好的程序员。

程序员想要了解产品功能是如何实现的，需具备一些系统架构和软件架构的知识。系统架构工程师要了解产品设计，包括用户心理、人机交互的一些认知和分析。

02 智能驾驶功能设计的第一性原理

智能驾驶功能设计的第一性原理：尽量减少人在路上（车上）的时间，如果做不到，那就让他轻松快乐。

TJA就是L2，TJP就是L3，并不太合理，全速功能不可少；

高级别泊车更能提升用户体验，因为低速封闭场地，更容易和行车级别错配搭载；

L4大规模应用时，内容生态会有新的增长支撑。

03 功能设计原则

原则1：信息充分和信息过载

L4 级Robotaxi车可以充分展示路况，用户获得的行驶信息越多，安全感就会越强。这个方式同时也达到了法律免责的目的，就是已经把相关信息都给到了人。但容易出现信息过载。

例如，用户经常抱怨车的预警功能声音过于频繁，系统显示退出时红色太刺眼等系列问题。换言之，人们理解结构化信息需要一个思考的过程，太多的结构化信息会让人们焦虑。

所以我们在不断地寻找用户的信息充分认知和信息过载之间的一个平衡点。

原则2：为什么样的用户设计？

为可能的所有用户设计安全的产品。传统汽车在设计智能驾驶功能时，都把智能驾驶功能尽量设计得不那么容易被误触发。

为目标用户设计舒适度更高的产品。特斯拉只为目标用户设计服务，比如都是相对容易尝鲜并有一定认知能力的年轻人，设计一些功能安全考量相对不那么严格的产品。

所以，我们该用什么样的思考维度去设计这个产品，也是现在面临的问题。

在保证安全的前提下，我们要学习特斯拉的设计理念和设计方式，从目标用户着手去进行系统设计。

原则3：人工智能的智能驾驶的恐怖谷理论

随着人工智能体越来越像人，人们对于它的好感度会增加。比如工业机器人，它的好感度就不如像人的机器人。但是，随着机器人越来越像人，越来越逼近人，也会让人产生一些恐惧。

对于智能驾驶而言，从 L0 开始其实不算逼真性，应该叫做智能性，就是机器营造的安全感和人类安全感之间的一个对比。从 L0开始，那么它的智能性不太够，主要是帮助人来刹一脚，AEB就是典型的L0 的功能。L1能够减少人的一部分的这个疲劳感。

我认为L2 ++是比较好的一个状态。

L3会造成人们对这个系统不信任，因为当他失去注意力的时候，他认为把自己的生命安全交到了一个还不完备的系统手里。同时法律责任以及对于车辆的管理权在人和车之间不断地切换。一旦报警，人就要接管，然后一旦正常行驶车还要再去控制车辆。

所以 L3 现在是一个大家信任度最低的状态，到了 L4、L5 其实它的状态会提升。

人工智能的智能驾驶恐怖谷理论存在两种两种矛盾：

一是，驾驶员恢复时间和需要驾驶员介入的时间存在矛盾。

部分高级别智能驾驶功能（比如L3）触发时，允许驾驶员短时间内不需要参与驾驶任务；

驾驶员恢复正常驾驶能力时间从6秒到几分钟，难以保证较短时间内完全接管车辆；

某些紧急工况只能留3秒左右时间给驾驶员（针对不支持自动换道的自动驾驶车辆）。

二是，权责模糊地带的界定。

用户能力与责任矛盾上，L3自动驾驶工作期间，驾驶员不参与驾驶任务，驾驶员是否能及时发现或接管车辆，尤其驾驶员在过于信赖L3系统后。但这与赋予驾驶员责任不匹配。

04 系统设计原则

原则1：硬件复用的设计原则

功能安全只能向下兼容；

算力资源的使用，重要度大于时序

原则2：易用和安全的天然矛盾

现阶段，功能上能实现的AVP，在大规模应用过程中往往会被设计成HPA。

05 智能驾驶的降级必然、兜底必然和收敛必然

智能驾驶的降级必然、兜底必然和收敛必然是我们最近讨论出来的结果。

这三者本质是冗余、异构、相互独立的系统，主要解决的是单点失效、软硬件系统性失效、公因失效等问题。诚然，这三者的最终目的是降低功能安全开发难度。

06 只有模块化才能生存

1. 即使OEM定义和主导开发，Tier 1依然不会没有生存空间，不同OEM的协同方式是不同的；

2. 做全栈，但不见得卖全栈；

3. 从经济的角度来说，Tier 2做交付是不划算的。

OEM、Tier 1、Tier 2它们是如何赚钱的？

OEM：用标准化模块做个性化逻辑连接。

Tier1：用模块化产品提供标准化服务。

Tier2：用标准化高技术产品形成壁垒。

以NVIDIA 为例，软硬件尽可能充分的解耦，才能使软件层部分功能更好地迁移到不同的硬件上。简言之，硬件平台化、软件模块化，同时软硬件能够充分地解耦。

07 一些思考

没有显性错误的设计就是好的设计吗？

比如关于刹车，前段时间特斯拉车主公开道歉，说承认把油门当成刹车。但问题在于特斯拉是没有责任的，单踏板模式是否是对的。

在我看来是是因为它的能量回收设计的太明显了，一松油门就停，使大家已经不会踩刹车了。因此容易让人造成误解。

一键直达是好的设计吗？

例如关于智能驾驶使能，是不是一次性开启一个功能就是好的设计，到底误触发会不会有风险？这个是我们后续在功能设计里面应该思考的问题。

实用主义极简是好的设计吗？

例如关于取消毫米波雷达，在 ADAS使用方面主要依靠摄像头，现在确实毫米波雷达的使用权重很低。因为毫米波雷达对金属物体过分敏感，可能也不是那么好的一种置信度高的信号。

但是因为传感器的异构冗余等特点，我们依然认为毫米波雷达不应该被取消，就是激光雷达、毫米波雷达、摄像头应该充分地在该系统上形成冗余。

本文来自微信公众号“XEV研究所”（ID:XEVLab），作者：郭继舜，整理：闫小瑜，36氪经授权发布。

该文观点仅代表作者本人，36氪平台仅提供信息存储空间服务。