智能驾驶产品开发中如何贯彻“正向开发”理念

摘要：

基于演绎法的正向开发理念，能够让智能驾驶产品在充分满足用户需求，保证产品质量的同时，确保开发目标合理且得到落实。

前段时间，微博CEO吐槽理想L9智能驾驶“行驶轨迹不居中”，在网上引发了热烈讨论。目前，问题的原因已得到澄清：维保时碰到摄像头，产生微小误差，导致远端感知产生较大偏差；理想后续会升级固件，解决该问题。

不过，从广大网友的发言来看，理想的智能驾驶确实存在“车道不居中、遇到大车不避让”的问题，希望理想后续能够优化。

我们认为，遇到问题后及时解决固然是好的，但如果能在一开始就把问题消灭在源头，那么用户对产品的体验会更好。

如果能贯彻“正向开发”的理念，理想智能驾驶的上述问题完全可以避免：摄像头安装误差对感知效果的鲁棒性，在前期产品设计和需求阶段，就可以明确要求；车道居中和大车避让的需求，作为市场上已有的成熟案例，也是可以在功能需求中明确定义的，没有必要等问题出现了再去优化。

引言

从智能驾驶的量产化进程来看，目前基本的单车道级L2功能已经普及，高速NOA功能逐渐趋于标配，城市NOA功能也逐渐铺开，但是，我们也看到，整体而言，智能驾驶产品的效果和用户体验并不能让人完全满意。

用户体验不佳的原因有很多，如软硬件协同没做好、为了控制成本而把硬件减配做得太激进，还有一个极容易被忽略但又直击本质的原因是：缺乏正向开发理念，对汽车行业的开发流程不够敬畏。

以智驾硬件方案的定义为例，需要多少颗摄像头、多少颗毫米波雷达、是否需要激光雷达、计算平台的AI算力应该多大、选用什么芯片更合理，市场上大多数玩家会从归纳法思维出发，直接套用市场上已有的传感器方案和计算平台，实现现有方案对应的功能：

“通过XXX传感器配置和XXX计算平台，可以实现XXX功能，可以达到X级智能驾驶。”这属于“先有果后有因”的逆向开发思路。

这种通过模仿、先有方案后有功能的思路，不仅容易造成产品同质化，更会导致功能受限，难以实现具有自身特色与亮点的新功能。

正确的做法应该是：从演绎法的思维出发，基于正向开发理念，从产品需求出发，正向定义出满足功能需求的传感器配置方案，并匹配相应的计算平台：

“因为要满足XXX功能，实现LX级智能驾驶，因此需要XXX传感器配置和XXX计算平台。”这是一种基于演绎法思维的开发理念，强调从本质和源头出发。

本文将从智能驾驶开发的一般流程出发，并通过硬件方案和软件方案的正向定义，结合项目实例，说明如何在智能驾驶开发过程中贯彻正向开发的理念。

一 正向开发的优势
 

我们先谈一个跟正向开发相对的概念：逆向开发。

逆向开发，即先锁定固定的配置、技术，然后再反推这些配置和技术能够实现什么样的功能。逆向开发表面上能够降低开发成本、缩短开发周期，因为一切都是对现有产品的“拿来主义”。

但是，逆向开发出来的产品，上限永远只能是别人家已有的方案，并且由于缺乏对产品的深刻理解，只“知其然”，不能“知其所以然”，导致产品质量难以保证，并且产品效果难以提升。

同时，逆向开发过程中如果出现技术难题，可能会无法解决，从而出现项目整体停滞的情况，原因就是逆向开发的本质是归纳和复刻，缺乏正向开发所具备的对产品整体的深刻理解，以及对各项技术的整体把控。

以热门话题“去高精地图”为例，如果采用逆向开发的理念，围绕是否配置高精地图，可能会有一轮又一轮的多部门讨论、开会、决策，最后公司领导拍板：“高精地图太贵了，要去掉，但是要保证功能不打折。”

在逆向开发的认知中，城市NOA功能不是目的，是否需要高精地图才是最大的问题。但是，实际上，在感知算法的水平不足的情况下，缺乏高精地图，是很难实现城市NOA等高阶功能的。

相比之下，正向开发理念将开发目标回归到需求层面，所有的设计和后续开发工作，都是为了满足用户需求，达成产品效果。

还是以“去高精地图”为例，如果采用正向开发的理念，思路就会变成这样：因为要搭载城市NOA功能，所以要么提升感知算法水平，要么让高精地图更精准，应该综合评估哪种方式更容易实现、成本更低。

在正向开发理念中，高精地图不是一个问题或者结论，而是一种措施和手段，最终目标是实现城市NOA功能，而不是解决高精地图的有无问题，因为除了高精地图，还会有其他多种因素，影响城市NOA功能的落地。

正向开发需要从零开始，对产品整体和开发过程的每一步都有深入的理解和完整的把握。虽然看起来正向开发需要更长的开发周期和更高的成本，但当整体流程打通后，正向开发的优势会显而易见：

它能够帮助开发者更好地理解用户需求、关注用户体验，并将需求和开发目标贯彻始终，从而提升产品质量和用户满意度，进而提高产品的竞争力和市场占有率。

不仅能确保产品开发目标得到完全落实，从根源上提升产品实力，还能让整体开发过程有序、严谨，项目的关键节点更容易得到保证，从而顺利达成预期的产品和项目效果。

如果从哲学的维度来说，正向开发更像是一种“道”，逆向开发更像是一种“术”。短期来看，“术”可以解决一些问题，但长期主义者，更应该去追求“道”，通过正向开发理念，把目标聚焦在根源，开发出经得起时间考验的产品。

二 智能驾驶的正向开发流程
 

基于正向开发的理念，在智能驾驶的开发过程中，可以借鉴软件开发的V型流程，形成适用于智能驾驶开发的V型流程体系，如图1所示。

图1 智能驾驶的V型开发流程

可以看到，按照工作流的顺序，智能驾驶V型流程依次包含产品设计与定义、系统分析与设计、硬件分析设计、软件分析设计、硬件开发、软件开发、软件模块测试、台架仿真测试、实车测试等关键阶段。

图1的开发流程是典型的正向开发流程，智能驾驶方案从产品设计与定义开始，经过对智驾系统的详细分析与架构设计，将开发目标传递到硬件和软件层面，硬件和软件分别根据产品需求，开展具体的开发工作；再经过软件测试、台架测试、实车测试等不同等级的测试验证，确认达到产品开发目标，最终完成开发任务并交付。

产品设计与定义通常由产品经理负责，基于市场发展和用户调研，结合公司战略和技术水平，并考虑法规政策限制，完成功能原理、逻辑流程、场景分解、关键参数等，形成产品需求文档（Product Requirement Document，PRD）。

系统分析与设计通常由系统工程师或架构工程师负责，根据PRD、法规和技术标准，制定系统架构、功能状态机、软硬件接口、信号定义、详细性能参数等，形成系统技术规范（System Technical Specification，STS）。

硬件分析与设计通常由硬件工程师负责，根据产品需求和系统技术规范，制定硬件详细需求与方案，包括硬件的型号、参数和技术规范等，形成零部件技术规范（Component Technical Specification，CTS）。

软件分析与设计通常由软件算法工程师负责，根据产品需求和系统技术规范，制定软件详细需求与方案，形成软件需求说明书（Software Requirement Specification，SRS）。

硬件开发包括各类传感器以及智驾域控制器的开发，通常由专业的硬件供应商完成，但也有主机厂会参与开发部分硬件，如激光雷达、毫米波雷达等。

软件开发包括操作系统、中间件和应用层算法等模块的开发，是目前行业内争夺和竞争最为激烈的环节，主机厂想要自研、Tier 1想要把控、各类算法供应商想坚持黑盒，但最终都会完成各类功能的软件算法模块。

硬件与软件开发完成后，进入到测试和验证阶段。首先在软件层面搭建软件测试环境，设计测试用例与脚本，制定软件模块测试方案，并完成软件模块测试；然后将智能驾驶的软件算法搭载到控制器上，搭建台架测试环境，完成基于台架的集成仿真测试，又称为硬件在环测试（Hardware-In-Loop，HIL）；最后，将所开发的智能驾驶系统，装载到实车上，通过场地和道路测试，最终验证智能驾驶产品的效果，包括功能、性能、交互、用户体验等内容。

可以看出，对于正向开发来说，智能驾驶的开发应该严格遵循图1所示的V型流程，在产品设计与定义阶段，明确产品需求与开发目标，并逐层传递到具体的开发工作中，然后再逐步集成化测试，在整车层面验证产品达到目标的效果。

不过，在现阶段，由于市场竞争激烈、缺乏统一规范等原因，智能驾驶实际的开发过程，往往难以遵循正向开发流程，出现了一些违背正向开发理念的做法，导致产品质量难以保证，用户体验不佳，并增加了大量的改进成本。

下面，我们分别从硬件方案和软件方案2个方面，展开讲述在智能驾驶开发过程中，如何按正向开发流程开展工作，并避免出现简单归纳法思维以及逆向开发的情况。

三 硬件方案的正向定义

【本文提到的硬件方案，有些已经是众所周知的知识，但我们仍希望通过本文的解释，能让读者“知其然，更知其所以然”，获得“先有产品定义，后有硬件方案”的正向开发理念。——作者注】 

我们经常在发布会上听到这样的说法：“我们的产品配置了激光雷达，拥有三十多个传感器，还用了先进的高算力芯片，是先进的智能驾驶。”

也经常在工作中听到这样的说法：“我们去和英伟达/地平线合作，先把芯片定下来，再看看能做到什么程度。”

甚至会听到公司高层这么说：“你们去看看小鹏/蔚来/理想/大疆的选型方案，我们跟他们用一样的，效果应该差不多。”

以上现象的背后，是一种典型的硬件方向逆向开发的思维方式。在逆向开发的认知中，“配置了高端的硬件，就有了高端的智能驾驶；把市场上别人用的硬件方案归纳一下，选择差不多的方案，就能做出类似的效果”。

但事实很可能是：你用8M像素的摄像头，做出的功能体验不一定比得上别人5M摄像头的效果；你用100TOPS算力的芯片，实现的功能未必有别人30TOPS芯片实现的功能多。

这种情况与软、硬件的综合能力有关，但更本质的原因还是在于：没有按照正向开发的思路，前期开发目标不明确。

根据前面提到的正向开发流程，在定义硬件方案前，更重要的是做好产品层面、系统层面的分析、设计与定义。也就是说，硬件方案应该是服务于功能需求、性能要求和产品整体开发目标的，应该是“需求先行”，而不是“硬件先行”。

下面，我们以功能需求展开，说明如何按照正向开发流程，根据功能需求定义硬件（传感器+计算平台）方案。

在九章智驾之前的文章《详解智能驾驶的功能与场景体系》中，已经系统化地总结了目前主要的智能驾驶功能，包含行车功能、泊车功能、主动安全功能等。

智能驾驶的传感器主要包括摄像头、毫米波雷达、超声波雷达与激光雷达，通过在车身的不同位置布置多种类型的传感器，实现对车辆周围区域的检测；广义的传感器还包括地图定位。传感器的分布和作用，大部分人已经非常熟悉，在此不作赘述，直接参考图1即可。

图1 传感器检测范围

智能驾驶各项功能的实现，依赖于传感器对相关区域的检测，因此不同的功能需求，对应着不同的传感器方案。根据各项智驾功能的效果，以及图1所示的传感器检测范围，可以得出各项功能所需的传感器配置，如表1所示。需要说明的是，表1中勾选的传感器配置，是该功能至少需要的传感器，如果成本允许，当然是越多传感器越好。

表1 智驾功能与传感器对应关系

根据表1，在定义传感器方案时，对于行车功能，单车道L2级功能如LCC只需前视摄像头+前向毫米波雷达；多车道L2级功能涉及相邻车道，还需要前、后角毫米波雷达；点到点的领航驾驶功能，需要增加侧视摄像头与后视摄像头，而城区路况更加复杂，因此C-NOA还需要激光雷达。

对于泊车功能时，停车位区域的自动泊车需环视摄像头+超声波雷达，而停车场范围的记忆泊车、智能召唤、自主代客泊车等功能，涉及低速行驶的场景，因此需要增加行车功能相同的传感器。

主动安全功能的传感器，主要与功能所覆盖的方位有关。

在定义传感器配置方案时，通常可以根据产品的功能需求，参考表1的汇总结果，根据功能，逐一确定所需配置的传感器类型。至于传感器的具体参数、型号，则需进一步根据产品性能要求，按照同样的思路来定义。

智能驾驶的计算平台，主要是指域控制器，其重点是SoC芯片与MCU芯片。其中SoC芯片主要用于AI计算，即处理大量的环境感知与定位数据，以及作出任务决策和轨迹规划等；MCU主要负责执行指令，以及安全可靠性。

SoC芯片的最重要任务是处理环境感知与定位信息，因此，智驾方案对SoC的AI算力的需求与环境数据的丰富程度紧密相关。

根据正向开发流程，在传感器配置方案完成后，应该根据各传感器的数据量，评估SoC芯片所需的算力水平。由于各家的算法不同，不同SoC芯片的内部架构不同，因此同一套传感器配置，可能会出现不同的AI算力要求，但算力水平的大概量级，应该是一致的。

例如，单车道L2级智能驾驶只需要前视摄像头与前向毫米波雷达，5TOPS以内的AI算力足以满足；多车道L2级智能驾驶还需要角毫米波雷达，因此需要5TOPS以上的AI算力；高速领航驾驶H-NOA还涉及侧视摄像头的数据，通常需要30TOPS以上的AI算力；城区领航驾驶C-NOA由于需要处理大量的激光雷达点云数据，通常要求AI算力达到200TOPS以上。

表2汇总了现阶段的主要智驾SoC芯片。在确定智驾产品所需的AI算力水平后，可以从表2中，选取相应的SoC芯片，完成计算平台的核心选型。不过，在实际应用中，AI算力只是关键参数，此外还要综合考虑软件与芯片的匹配度、平台成熟度、成本等多种因素，定义出最适合自己的方案。

表2 智驾SoC芯片汇总

以上，就是从功能需求→硬件方案的正向定义方法，这种正向演绎的思维，能够从功能需求出发，在充分理解各传感器用途和算力分布的基础上，定义出最优的硬件方案。

四 软件方案的正向定义
 

在软件方案中，操作系统和中间件往往是成熟的方案，并且难以在产品效果层面直接体现；但应用层算法，尤其是各项功能的实现逻辑和关键参数，是影响智驾产品最终效果的重要因素。

按照正向开发的流程，智能驾驶算法的逻辑和参数，应该是在产品设计与定义阶段提出，经系统分析与设计阶段细化后，传递到软件开发层面。但在实际的开发过程中，往往容易出现需求定义不清、具体模块开发人员不闻不问，随便拍脑袋，甚至直接照搬其他车型方案的情况，导致最终开发出来的功能，偏离最初的开发目标。

下面通过几个功能的真实案例来说明，软件方案的常见逆向开发做法，以及正确的正向开发方式。

案例一：自动泊车APA

某公司的APA功能开发时，由于项目时间紧任务重，在缺乏产品需求和系统关键参数的情况下，算法工程师认为“目前市场上的APA功能已经很成熟，可以直接拿来用”。在简单了解了某款车型的泊车关键参数后，就迅速开展工作，达到了与该车型大概相同的自动泊车效果。

但在实车测试时发现，车辆泊车完成后的位置，不能够根据周围环境自动调整，导致在周围有障碍物时，有时距离障碍物过近，不方便用户开门下车。并且，在泊车过程中，多次出现方向盘大幅左右晃动、车身不稳的情况。

根源就是因为软件参数不是通过正向开发得到的，而是工程师归纳式简单参考的结果。

原本可以通过正向开发避免的问题，由于急功近利的逆向开发方式，导致泊车功能缺乏亮点，无法让用户满意，没有达到预期的产品效果。

对于这种情况，按照正向开发的流程，首先应该考虑的是在产品设计与定义阶段，通过竞品分析、用户调研等方法，提前考虑到泊车过程中对舒适度的要求，明确对横向控制稳定性的要求，以及泊车完成后的车身位置要求。即使项目时间紧张，也可以压缩各阶段的项目周期，而不能直接“裁剪”掉最重要的源头阶段。

案例二：自适应巡航ACC

有一次，ACC功能开发过程中，我们遇到了ACC目标车速变更和ACC跟车停止逻辑的问题。

在开发ACC功能时，我们团队的产品经理经过市场对标和用户体验分析后，在产品需求中明确提出：用户使用ACC功能时，通过“短按”方向盘的车速调节按键，控制目标车速按步长5kph不变化，通过“长按”按键，控制目标车速按步长1kph变化。

原因是，在道路中行驶时，车速变化1kph的场景极少且没有明显意义，因此通过“长按”的方式来控制；车速变化5kph对于改变车速更有意义，因此通过“短按”这一更为简单的方式来控制。

但是，在开发过程中发现，负责对应开发模块的工程师，忽略了产品需求，通过自己的判断和市场上某一款车型的做法，私自更改产品需求，导致开发结果偏离目标。

这种简单的经验式归纳，直接导致该功能的效果是由软件需求反向影响产品需求，也降低了产品效果。虽然最终得到了改正，但对项目整体来说，产生了额外的成本。

另外，ACC控制车辆停车时，出于功能一致性和连续性的考虑，产品需求中要求在任何时候，用户踩下制动踏板，ACC功能都应该完全退出，但在开发过程中，负责对应模块的工程师，忽略了产品需求，自行定义为“车辆静止状态下，哪怕用户踩下制动踏板，ACC功能仍然能保持”。这不仅违背了功能整体逻辑，也额外增加了软件工作量。

以上情况，虽然开发过程是按照正向流程，产品→系统→软件，但在执行过程中，软件模块的开发人员仍没有意识到正向开发的重要性，按照个人经验去逆向定义甚至忽略产品的需求，导致偏离开发目标，也导致项目的时间和人力成本增加。

这种是个典型的“有流程，但没有意识”的案例。很多时候，公司高层和项目负责人已经认识到正向开发的重要性，并且制定了具体的工作流程，但公司的一些研发人员却没有正向开发的意识，仍然按照个人经验，照搬过去的做法，导致正向开发难以完全贯彻落实，新产品的亮点难以得到百分百地呈现。

针对这种意识、观念层面的问题，我们能做的就是首先在团队整体明确正向开发的理念和方法，然后去培养工程师的正向开发思维，通过团队的影响力，带动个人的意识提升。

案例三：高速领航H-NOA

H-NOA功能开发过程中，我们遇到了默认车道策略和进入匝道前变道时机的问题。

团队在定义H-NOA功能时，对默认的行驶车道没有作出明确定义，仅要求“在合理的车道中行驶”。算法人员在开发时，为降低感知的难度，将默认车道设定为高速公路的最左侧车道。

实际上，根据大量老司机的驾驶经验，以及《道路交通安全法》的要求，高速公路中的长时间行驶车道应该是左侧第二车道，车辆不应该长期保持在最左侧车道行驶。

同样，对于进入匝道前的变道逻辑，前期也没有作明确定义，仅要求“能够在进入匝道前，变道至缓冲车道或最右侧车道”。算法人员在缺乏沟通和调研的情况下，对变道时机的参数定义过于激进，导致测试时，多次出现无法成功进入匝道的情况。

这种情况是由于在项目前期缺乏全面的考虑，导致对产品的某些参数缺乏定义，具体开发时缺乏依据。

按照正向开发流程，在产品和系统层面，相关人员应该尽可能地全面定义各项关键参数；对于NOA这类相对复杂的功能，如果前期确实遗漏了某些参数的定义，那么具体模块的开发人员在缺乏依据时，应该主动向产品或系统人员确认、沟通，而不是自作主张地“拍脑袋”。

前期产品需求全面细致，各具体模块负责人员主动沟通，这样才能让正向开发的流程更好地推进，产品效果得到保证；否则，如果需求定义不清，后续模块人员自作主张，那么实际上又变成了逆向开发的模式，正向开发也就成了表面文章。

五 结语
 

以上，就是智能驾驶的正向开发方法，以及如何在实际工作中，贯彻正向开发理念的一些理论和经验总结。基于演绎法的正向开发理念，能够让智能驾驶产品在充分满足用户需求，保证产品质量的同时，确保开发目标合理且得到落实。

不过，本文的内容属于基本的思路和方法论，在具体的产品开发过程中，还需根据实际情况，如开发能力、成本、周期、资源等，灵活定义方案，及时调整，作出最合理、能落地的选择。

来源 | 九章智驾