智能驾驶赛道的竞争越来越激烈，参与的玩家越来越多：主机厂在争取全栈自研，传统Tier 1在加大投入，互联网与科技公司纷纷入局，甚至传统的一些代工厂和消费电子厂商，也在布局智能驾驶业务。“越来越卷”，是今年智能驾驶业内人士的共同感慨。

在激烈的竞争中，有的玩家利用先发优势，始终保持领头羊的地位；有的玩家厚积薄发，形成了自己的一套特色方案；但更多的玩家，在汽车智能化的浪潮中起起伏伏，始终难以拿出具有竞争力的智能驾驶产品，无法在市场中占据一席之地。

诚然，决定一家公司产品实力的因素中，资金实力、技术实力、公司规模等，是不可忽视的重要因素，但笔者认为，对于智能驾驶来说，系统性的思维方式，是决定产品能否持续赢得市场的关键，也是区分一家公司是“正规军”还是“杂牌军”的重要标志。

本文将从智能驾驶整体内容出发，通过功能场景、软硬件开发、测试、安全等方面的案例，展开说明系统性思维对于智能驾驶的重要意义，以及如何在智能驾驶的开发过程中，贯彻系统性思维。

在回答“什么是智能驾驶的系统性思维”之前，我们先看一段对话——

然后，就没有后续了。

实际上，上面对话中A提到的交通拥堵辅助（TJA），就是低速场景中ACC与LKA功能的结合，既然B公司已经开发出了ACC与LKA功能，那么实际上当两项功能同时开启时，就可以实现堵车场景的TJA功能。

因为意识不到“通拥堵辅助功能其实已经有了，只是没有明确提出而已”，B白白丢错过了一个本来有可能拿下的订单机会。

那么，B为何会“回答不恰当”呢？

因为，他没有系统性思维。

所谓系统性思维，是一种从全局出发的结构化思维方式，通过将一件事物看成一套整体的系统，并研究系统中的各项元素及其相互间的作用和关联，让事物体系化、结构化，成为强逻辑性的有序系统。

系统性思维有如下特点：

智能驾驶作为人工智能与汽车工程相结合的学科，所涉及的知识非常丰富，覆盖的内容也相当广泛，是多学科交叉融合的典型代表：计算机视觉、机器学习、人机工程、车辆动力学、汽车设计等等。如此多的知识内容，想要集成在智能驾驶中，以产品的形式呈现给用户，必然需要有系统性思维，从面到线、从线到点、从整体到局部地去思考和应用，否则难免出现考虑不周、缺失、重复等现象。

例如，在看待智能驾驶时，非系统性思维的认知是：

我们常听到传统主机厂的人认为“智能驾驶和之前的电子系统差不多，只是加了一堆传感器，用了更高算力的芯片而已”；也常听到消费电子行业的人认为“做智能驾驶和做手机差不多，无非是把手机变成车载控制器而已”。这些认知都是因为缺乏对智能驾驶的系统性思考，只看到局部，看不到整体。

如果是系统性思维，就会有这样的认知：

并且会思考：

可见，思维方式的不同，会导致认知的不同，进而影响智能驾驶的开发方法不同，以及产品的效果不同，最终体现就是市场的反馈不同。

用系统性思维开发智能驾驶，会让智能驾驶成为一套系统，呈现出体系化、结构化的特点，并且智能驾驶各项要素之间，会存在逻辑关系和关联关系。

从用户层面来看，智能驾驶包含多样化的应用场景和多种功能，例如应用于车道内行驶场景的自适应巡航ACC功能和车道居中LCC功能，应用于变道场景的自动变道功能，应用于堵车场景的交通拥堵辅助TJA功能，应用于高速公路场景的高速领航驾驶NOA功能，应用于停车场景的自动泊车APA等等。

功能与场景作为智能驾驶直接呈现给用户的内容，不是单独存在的，而是一套完整的系统，可以根据特定的分类标准，分成不同的类别，再结合各项功能之间的关联，形成一套场景与功能体系。

在九章智驾之前的文章《详解智能驾驶的功能与场景体系》中，我们已经将场景分为行车场景、泊车场景，并对应地将功能分为行车功能、泊车功能和主动安全功能等3大类。在不同功能之间，也梳理出了逻辑关系。

详细的功能与场景体系内容，读者可以直接参考《详解智能驾驶的功能与场景体系》这篇文章，这里就不再赘述了。

从整车架构来看，智能驾驶是始终作为其中的一个模块、或者说一个域存在的；智能驾驶相关的所有硬件与软件，最终都是为了让智能驾驶的效果达到预期，因此，智能驾驶的各类硬件与软件，也不是独立的，而是存在内在关联，应该整体布局，用系统性思维去开发。

智能驾驶包含丰富的硬件配置和多种软件算法。硬件有各种传感器如摄像头、激光雷达、毫米波雷达、超声波雷达，以及多种芯片如SoC芯片、MCU芯片等，另外地图和高精定位装置，也可以看作广义的传感器；软件有操作系统、中间件、以及各种算法如BEV视觉感知算法、PID控制算法等，并可以封装成特定的功能算法如ACC算法、APA算法等。

如果用非系统性思维来设计5R1V的硬件方案，可能是这样的：

然后被告知J2芯片不适合处理8M像素摄像头的数据，方案被推翻重来。

如果具备系统性思维，则会这样考虑：

这样，5R1V方案中的每一个硬件需求和选型，都有理有据，并且等达到整体的统一，能够形成一套完整的系统，而不是单独存在的5个雷达+1个摄像头+1个芯片。

在设计软件方案时，由于软件算法的逻辑和参数，能直接体现在功能和性能层面，因此更需要系统性思维。

以典型的Corner Case Cut-In为例：当车辆在车道内激活ACC时，如果前方出现紧急Cut-In，那么自车应该及时减速。产生的问题是：减速度应该是多大？如果情况过于紧急，达到触发AEB的要求，此时AEB与ACC之间的交互应该是怎么样的？ESC输出的制动力应该如何变化？

如果缺乏系统性思维，可能根本不会意识到这些问题，只是将ACC和AEB作为2个单独的算法模块来开发，直到问题暴露。

如果具备系统性思维，则在一开始就会定义好Cut-In场景触发AEB时，ACC的功能状态和AEB介入的时机，以及两者对制动力的详细控制逻辑，实现制动力的平稳过渡，同时达到安全和舒适的效果。

系统性思维应用于软件方案开发的另一个典型案例是智能驾驶各项功能的开关设计。

严格地说，功能开关设置属于人机交互，也就是智能座舱的开发内容，但座舱中跟智能驾驶功能相关的开关设置，通常也需要智能驾驶的开发人员参与。

在早期的汽车机械化和电气化时代，智能驾驶功能很少，ACC已经算是比较先进的功能，所以通常不会系统性地设计智能驾驶功能开关，常规做法是有一项功能，就加一个开关项。

如今智能驾驶的功能多达30多种，如果仍按照之前的思路，那么可能会存在30多个开关选项，这种情况在寸土寸金的车载屏幕中，显然是不被允许的。此时就需要系统性思维，从全局思考如何设计智能驾驶各种功能的开关：

对于法规强制要求的功能，可以默认常开，无需开关；对于同类型功能，可以统一成一个一级开关，然后通过一级开关，弹出二级开关，例如将FCW与AEB统一为前向安全功能；对于存在包含关系的功能，分为两级开关，例如NOA功能开关下设置自主变道功能的开关；对于用户大概率不会更改设置的功能，可以隐藏，只保留一个统一入口供用户做个性化设置。如图1所示。

a）   同类型功能开关

b）   包含关系的功能开关

图1 功能开关示例

按照这种系统性地做法，智能驾驶的功能开关将得到极大简化，并且最大程度地考虑到用户使用的频率和场景。对于开发来说，开关信号逻辑也更加清晰，不会产生多个功能的开关信号优先级冲突的情况。

经常在发布会上听到这类宣传语：“我们的智能驾驶目前行业领先，全国领先，能够达到XX公里零接管，已经超越了特斯拉。”此时我们的疑问是：XX公里零接管的场景和工况是什么？能够覆盖哪些路段？零接管是在台架测试阶段的仿真结果，还是实车路试结果？所谓的超越特斯拉，是哪些场景下的哪些参数或者性能表现超越，还是说所有指标都超越？

遗憾的是，目前没有人能够系统地回答这些问题，一种可能的情况是：这些玩家在高调宣传的同时，自己其实并没有非常系统地去完成测试与验证工作，也缺乏系统性的思考：在什么阶段，应该测什么内容？测试用例应该怎么编写，才能保证测试过程不重复、不遗漏？需要多少测试数据，才能确保测试结果的可靠性？

需要经过系统化的全面测试与验证，在不同阶段，从不同维度去全方位地验证产品的效果，才能保证让用户满意，并且符合法规和标准要求。

智能驾驶作为涉及到安全、可靠、舒适等多个评价维度的复杂产品，通常需要经过软件单元测试、软件在环测试（Software-In-Loop，SIL）、硬件在环测试（Hardware-In-Loop，HIL，通常也可称为台架测试）、实车场地测试、实车道路测试、法规认证等多个测试环节，从软件层、系统层、整车层等多个层面，逐一验证，以便及时发现问题，及时调整优化。并且，在产品验证过程中，应该有一套系统化的测试大纲和全面的测试用例，实现对智能驾驶产品的系统、全面测试。

智能驾驶的测试应该是系统而完整的，应该覆盖所有可能的场景，并且对产品性能的测试应该具有统计学意义，而不是仅通过个别几次的测试结果，就对产品性能得出结论。

如果采用系统性思维，首先列出一套智能驾驶产品的所有应用场景和功能，以及各项功能的性能要求；然后根据不同阶段的测试边界能力，安排不同的测试任务；最后再根据产品和系统需求，以功能为单元，从全局考虑，编写测试用例，形成测试方案，测试用例应该注意合理性和可复现。

以系统性思维下的自动泊车功能实车测试为例，自动泊车分为检测车位和泊入车位2个过程，有时还会有泊出车位的效果，那么自动泊车的测试就应该按检测车位、泊入车位、泊出车位的过程，分别开展。

测试检测车位效果时，主要测试的是检测成功率，应该将目前所有常见的车位类型都列入测试用例，例如标线车位的标线有全封闭、半封闭、开口、角点等类型，空间车位的参照物有其他车辆和各种障碍物等，更详细的车位类型介绍，可参考九章智驾之前的文章《特斯拉、小鹏、蔚来的自动泊车产品测评》。然后根据不同的车位类型，分别多次测试自动泊车的检测效果，并分别统计各类车位的检测成功率。

需要注意的是，成功率应该具有统计学意义，不能仅仅以某几次的测试结果去计算成功率，而是至少测试100次以上，才能得出具有统计学意义的结论。

另外，还要考虑天气和光照的影响，也作为测试用例的一部分。

对于泊入车位和泊出车位的测试，应该列出所有需要测试的参数，例如成功率、用时、揉库次数、泊车空间要求、平稳性等等。一方面，应该针对各项参数，有针对性地制定测试用例；另一方面，测试结果也应该具有统计学意义，例如测试得出的泊车用时，不应该是某一次泊车所用的时间，而应该是多次泊车用时的均值。

对于安全的片面认知，是目前很多玩家缺乏系统性思维的典型代表。

曾听不止一位同行说：“我们的智能驾驶功能肯定是安全的，因为通过了CNCAP的认证。”甚至听到过有些非汽车行业出身的高层建议：“反正都是SoC，我们也未必要用英伟达/地平线，用XX芯片（某消费级芯片）应该也可以，只要过了认证就行，你们产品和研发一起评估一下。”

对基于这种认知下所开发出的智能驾驶产品，我们的建议是：为了自身安全，碰都不要碰。

安全，作为智能驾驶区别于AI在其他行业应用的一项关键特性，也需要系统性地考虑。

从目前来说，交通法规、NCAP、功能安全、预期功能安全等，已经从多个方面对智能驾驶的安全性提出了要求；另外，用户使用智能驾驶时的安全感受，也是安全性的一部分，这些应该在智能驾驶开发时综合考虑，并分解到相应的功能需求和软、硬件模块中。

目前有很多法规和标准，对智能驾驶的安全性提出了要求，耳熟能详的有NCAP标准、ISO26262功能安全标准、ISO21448预期功能安全标准等等，以及容易被工程师，尤其是缺乏驾驶经验的工程师所忽略的《道路交通安全法》。另外，智能驾驶作为车载模块，也应该严格遵守车规级的要求。

图2 智能驾驶安全法规示例

因此，从系统性思维出发，智能驾驶的安全，需要从各个维度综合考虑，并且分解、落实到开发的相关内容和目标中，而不仅仅是通过了某项认证、达到某个分数，就认为安全已经做好了。

以上，就是我们对智能驾驶的系统性思维的解读，并从智能驾驶涉及的主要内容，通过案例讲述如何在智能驾驶产品开发中，贯彻系统性思维。除了本文列举的案例外，智能驾驶与整车其他模块的交互、智能驾驶的开发流程等，也应该贯彻系统性思维。

可以说，系统性思维作为一种结构化的全局思维方式，对于智能驾驶这类复杂系统工程，是非常适用且必要的。对于长期主义的玩家来说，长久且稳定地保持智能驾驶产品竞争力和市场份额，一定是系统性思维主导开发的结果；并且，系统性思维，也是一家“正规军”区别于“杂牌军”的重要标志。