自己做网站如何赚钱,建设美食网站的意义,河北邯郸中考成绩查询网站,做球迷网站摘要#xff1a;
基于演绎法的正向开发理念#xff0c;能够让智能驾驶产品在充分满足用户需求#xff0c;保证产品质量的同时#xff0c;确保开发目标合理且得到落实。
前段时间#xff0c;微博CEO吐槽理想L9智能驾驶“行驶轨迹不居中”#xff0c;在网上引发了热烈讨论…摘要
基于演绎法的正向开发理念能够让智能驾驶产品在充分满足用户需求保证产品质量的同时确保开发目标合理且得到落实。
前段时间微博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 DocumentPRD。 系统分析与设计通常由系统工程师或架构工程师负责根据PRD、法规和技术标准制定系统架构、功能状态机、软硬件接口、信号定义、详细性能参数等形成系统技术规范System Technical SpecificationSTS。 硬件分析与设计通常由硬件工程师负责根据产品需求和系统技术规范制定硬件详细需求与方案包括硬件的型号、参数和技术规范等形成零部件技术规范Component Technical SpecificationCTS。 软件分析与设计通常由软件算法工程师负责根据产品需求和系统技术规范制定软件详细需求与方案形成软件需求说明书Software Requirement SpecificationSRS。 硬件开发包括各类传感器以及智驾域控制器的开发通常由专业的硬件供应商完成但也有主机厂会参与开发部分硬件如激光雷达、毫米波雷达等。 软件开发包括操作系统、中间件和应用层算法等模块的开发是目前行业内争夺和竞争最为激烈的环节主机厂想要自研、Tier 1想要把控、各类算法供应商想坚持黑盒但最终都会完成各类功能的软件算法模块。 硬件与软件开发完成后进入到测试和验证阶段。首先在软件层面搭建软件测试环境设计测试用例与脚本制定软件模块测试方案并完成软件模块测试然后将智能驾驶的软件算法搭载到控制器上搭建台架测试环境完成基于台架的集成仿真测试又称为硬件在环测试Hardware-In-LoopHIL最后将所开发的智能驾驶系统装载到实车上通过场地和道路测试最终验证智能驾驶产品的效果包括功能、性能、交互、用户体验等内容。 可以看出对于正向开发来说智能驾驶的开发应该严格遵循图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这类相对复杂的功能如果前期确实遗漏了某些参数的定义那么具体模块的开发人员在缺乏依据时应该主动向产品或系统人员确认、沟通而不是自作主张地“拍脑袋”。 前期产品需求全面细致各具体模块负责人员主动沟通这样才能让正向开发的流程更好地推进产品效果得到保证否则如果需求定义不清后续模块人员自作主张那么实际上又变成了逆向开发的模式正向开发也就成了表面文章。 五 结语 以上就是智能驾驶的正向开发方法以及如何在实际工作中贯彻正向开发理念的一些理论和经验总结。基于演绎法的正向开发理念能够让智能驾驶产品在充分满足用户需求保证产品质量的同时确保开发目标合理且得到落实。 不过本文的内容属于基本的思路和方法论在具体的产品开发过程中还需根据实际情况如开发能力、成本、周期、资源等灵活定义方案及时调整作出最合理、能落地的选择。 来源 | 九章智驾
