智能驾驶产品开发中如何贯彻“正向开发”理念发表时间:2023-10-30 14:03 前段时间,微博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功能已经很成熟,可以直接拿来用”。在简单了解了某款车型的泊车关键参数后,就迅速开展工作,达到了与该车型大概相同的自动泊车效果。 但在实车测试时发现,车辆泊车完成后的位置,不能够根据周围环境自动调整,导致在周围有障碍物时,有时距离障碍物过近,不方便用户开门下车。并且,在泊车过程中,多次出现方向盘大幅左右晃动、车身不稳的情况。 根源就是因为软件参数不是通过正向开发得到的,而是工程师归纳式简单参考的结果。 原本可以通过正向开发避免的问题,由于急功近利的逆向开发方式,导致泊车功能缺乏亮点,无法让用户满意,没有达到预期的产品效果。 对于这种情况,按照正向开发的流程,首先应该考虑的是在产品设计与定义阶段,通过竞品分析、用户调研等方法,提前考虑到泊车过程中对舒适度的要求,明确对横向控制稳定性的要求,以及泊车完成后的车身位置要求。即使项目时间紧张,也可以压缩各阶段的项目周期,而不能直接“裁剪”掉最重要的源头阶段。 有一次,ACC功能开发过程中,我们遇到了ACC目标车速变更和ACC跟车停止逻辑的问题。 在开发ACC功能时,我们团队的产品经理经过市场对标和用户体验分析后,在产品需求中明确提出:用户使用ACC功能时,通过“短按”方向盘的车速调节按键,控制目标车速按步长5kph不变化,通过“长按”按键,控制目标车速按步长1kph变化。 原因是,在道路中行驶时,车速变化1kph的场景极少且没有明显意义,因此通过“长按”的方式来控制;车速变化5kph对于改变车速更有意义,因此通过“短按”这一更为简单的方式来控制。 但是,在开发过程中发现,负责对应开发模块的工程师,忽略了产品需求,通过自己的判断和市场上某一款车型的做法,私自更改产品需求,导致开发结果偏离目标。 这种简单的经验式归纳,直接导致该功能的效果是由软件需求反向影响产品需求,也降低了产品效果。虽然最终得到了改正,但对项目整体来说,产生了额外的成本。 另外,ACC控制车辆停车时,出于功能一致性和连续性的考虑,产品需求中要求在任何时候,用户踩下制动踏板,ACC功能都应该完全退出,但在开发过程中,负责对应模块的工程师,忽略了产品需求,自行定义为“车辆静止状态下,哪怕用户踩下制动踏板,ACC功能仍然能保持”。这不仅违背了功能整体逻辑,也额外增加了软件工作量。 以上情况,虽然开发过程是按照正向流程,产品→系统→软件,但在执行过程中,软件模块的开发人员仍没有意识到正向开发的重要性,按照个人经验去逆向定义甚至忽略产品的需求,导致偏离开发目标,也导致项目的时间和人力成本增加。 这种是个典型的“有流程,但没有意识”的案例。很多时候,公司高层和项目负责人已经认识到正向开发的重要性,并且制定了具体的工作流程,但公司的一些研发人员却没有正向开发的意识,仍然按照个人经验,照搬过去的做法,导致正向开发难以完全贯彻落实,新产品的亮点难以得到百分百地呈现。 针对这种意识、观念层面的问题,我们能做的就是首先在团队整体明确正向开发的理念和方法,然后去培养工程师的正向开发思维,通过团队的影响力,带动个人的意识提升。 H-NOA功能开发过程中,我们遇到了默认车道策略和进入匝道前变道时机的问题。 团队在定义H-NOA功能时,对默认的行驶车道没有作出明确定义,仅要求“在合理的车道中行驶”。算法人员在开发时,为降低感知的难度,将默认车道设定为高速公路的最左侧车道。 实际上,根据大量老司机的驾驶经验,以及《道路交通安全法》的要求,高速公路中的长时间行驶车道应该是左侧第二车道,车辆不应该长期保持在最左侧车道行驶。 同样,对于进入匝道前的变道逻辑,前期也没有作明确定义,仅要求“能够在进入匝道前,变道至缓冲车道或最右侧车道”。算法人员在缺乏沟通和调研的情况下,对变道时机的参数定义过于激进,导致测试时,多次出现无法成功进入匝道的情况。 这种情况是由于在项目前期缺乏全面的考虑,导致对产品的某些参数缺乏定义,具体开发时缺乏依据。 按照正向开发流程,在产品和系统层面,相关人员应该尽可能地全面定义各项关键参数;对于NOA这类相对复杂的功能,如果前期确实遗漏了某些参数的定义,那么具体模块的开发人员在缺乏依据时,应该主动向产品或系统人员确认、沟通,而不是自作主张地“拍脑袋”。 前期产品需求全面细致,各具体模块负责人员主动沟通,这样才能让正向开发的流程更好地推进,产品效果得到保证;否则,如果需求定义不清,后续模块人员自作主张,那么实际上又变成了逆向开发的模式,正向开发也就成了表面文章。 以上,就是智能驾驶的正向开发方法,以及如何在实际工作中,贯彻正向开发理念的一些理论和经验总结。基于演绎法的正向开发理念,能够让智能驾驶产品在充分满足用户需求,保证产品质量的同时,确保开发目标合理且得到落实。 不过,本文的内容属于基本的思路和方法论,在具体的产品开发过程中,还需根据实际情况,如开发能力、成本、周期、资源等,灵活定义方案,及时调整,作出最合理、能落地的选择。 |