智能駕駛產(chǎn)品開發(fā)中如何貫徹“正向開發(fā)”理念

本文將從智能駕駛開發(fā)的一般流程出發(fā)，并通過硬件方案和軟件方案的正向定義，結(jié)合項目實例，說明如何在智能駕駛開發(fā)過程中貫徹正向開發(fā)的理念。

一 正向開發(fā)的優(yōu)勢

我們先談一個跟正向開發(fā)相對的概念：逆向開發(fā)。

逆向開發(fā)，即先鎖定固定的配置、技術(shù)，然后再反推這些配置和技術(shù)能夠?qū)崿F(xiàn)什么樣的功能。逆向開發(fā)表面上能夠降低開發(fā)成本、縮短開發(fā)周期，因為一切都是對現(xiàn)有產(chǎn)品的“拿來主義”。

但是，逆向開發(fā)出來的產(chǎn)品，上限永遠只能是別人家已有的方案，并且由于缺乏對產(chǎn)品的深刻理解，只“知其然”，不能“知其所以然”，導(dǎo)致產(chǎn)品質(zhì)量難以保證，并且產(chǎn)品效果難以提升。

同時，逆向開發(fā)過程中如果出現(xiàn)技術(shù)難題，可能會無法解決，從而出現(xiàn)項目整體停滯的情況，原因就是逆向開發(fā)的本質(zhì)是歸納和復(fù)刻，缺乏正向開發(fā)所具備的對產(chǎn)品整體的深刻理解，以及對各項技術(shù)的整體把控。

以熱門話題“去高精地圖”為例，如果采用逆向開發(fā)的理念，圍繞是否配置高精地圖，可能會有一輪又一輪的多部門討論、開會、決策，最后公司領(lǐng)導(dǎo)拍板：“高精地圖太貴了，要去掉，但是要保證功能不打折?！?/p>

在逆向開發(fā)的認(rèn)知中，城市NOA功能不是目的，是否需要高精地圖才是最大的問題。但是，實際上，在感知算法的水平不足的情況下，缺乏高精地圖，是很難實現(xiàn)城市NOA等高階功能的。

相比之下，正向開發(fā)理念將開發(fā)目標(biāo)回歸到需求層面，所有的設(shè)計和后續(xù)開發(fā)工作，都是為了滿足用戶需求，達成產(chǎn)品效果。

還是以“去高精地圖”為例，如果采用正向開發(fā)的理念，思路就會變成這樣：因為要搭載城市NOA功能，所以要么提升感知算法水平，要么讓高精地圖更精準(zhǔn)，應(yīng)該綜合評估哪種方式更容易實現(xiàn)、成本更低。

在正向開發(fā)理念中，高精地圖不是一個問題或者結(jié)論，而是一種措施和手段，最終目標(biāo)是實現(xiàn)城市NOA功能，而不是解決高精地圖的有無問題，因為除了高精地圖，還會有其他多種因素，影響城市NOA功能的落地。

正向開發(fā)需要從零開始，對產(chǎn)品整體和開發(fā)過程的每一步都有深入的理解和完整的把握。雖然看起來正向開發(fā)需要更長的開發(fā)周期和更高的成本，但當(dāng)整體流程打通后，正向開發(fā)的優(yōu)勢會顯而易見：

它能夠幫助開發(fā)者更好地理解用戶需求、關(guān)注用戶體驗，并將需求和開發(fā)目標(biāo)貫徹始終，從而提升產(chǎn)品質(zhì)量和用戶滿意度，進而提高產(chǎn)品的競爭力和市場占有率。

不僅能確保產(chǎn)品開發(fā)目標(biāo)得到完全落實，從根源上提升產(chǎn)品實力，還能讓整體開發(fā)過程有序、嚴(yán)謹(jǐn)，項目的關(guān)鍵節(jié)點更容易得到保證，從而順利達成預(yù)期的產(chǎn)品和項目效果。

如果從哲學(xué)的維度來說，正向開發(fā)更像是一種“道”，逆向開發(fā)更像是一種“術(shù)”。短期來看，“術(shù)”可以解決一些問題，但長期主義者，更應(yīng)該去追求“道”，通過正向開發(fā)理念，把目標(biāo)聚焦在根源，開發(fā)出經(jīng)得起時間考驗的產(chǎn)品。

二 智能駕駛的正向開發(fā)流程

基于正向開發(fā)的理念，在智能駕駛的開發(fā)過程中，可以借鑒軟件開發(fā)的V型流程，形成適用于智能駕駛開發(fā)的V型流程體系，如圖1所示。

圖1 智能駕駛的V型開發(fā)流程

可以看到，按照工作流的順序，智能駕駛V型流程依次包含產(chǎn)品設(shè)計與定義、系統(tǒng)分析與設(shè)計、硬件分析設(shè)計、軟件分析設(shè)計、硬件開發(fā)、軟件開發(fā)、軟件模塊測試、臺架仿真測試、實車測試等關(guān)鍵階段。

圖1的開發(fā)流程是典型的正向開發(fā)流程，智能駕駛方案從產(chǎn)品設(shè)計與定義開始，經(jīng)過對智駕系統(tǒng)的詳細分析與架構(gòu)設(shè)計，將開發(fā)目標(biāo)傳遞到硬件和軟件層面，硬件和軟件分別根據(jù)產(chǎn)品需求，開展具體的開發(fā)工作；再經(jīng)過軟件測試、臺架測試、實車測試等不同等級的測試驗證，確認(rèn)達到產(chǎn)品開發(fā)目標(biāo)，最終完成開發(fā)任務(wù)并交付。

產(chǎn)品設(shè)計與定義通常由產(chǎn)品經(jīng)理負(fù)責(zé)，基于市場發(fā)展和用戶調(diào)研，結(jié)合公司戰(zhàn)略和技術(shù)水平，并考慮法規(guī)政策限制，完成功能原理、邏輯流程、場景分解、關(guān)鍵參數(shù)等，形成產(chǎn)品需求文檔（Product Requirement Document，PRD）。

系統(tǒng)分析與設(shè)計通常由系統(tǒng)工程師或架構(gòu)工程師負(fù)責(zé)，根據(jù)PRD、法規(guī)和技術(shù)標(biāo)準(zhǔn)，制定系統(tǒng)架構(gòu)、功能狀態(tài)機、軟硬件接口、信號定義、詳細性能參數(shù)等，形成系統(tǒng)技術(shù)規(guī)范（System Technical Specification，STS）。

硬件分析與設(shè)計通常由硬件工程師負(fù)責(zé)，根據(jù)產(chǎn)品需求和系統(tǒng)技術(shù)規(guī)范，制定硬件詳細需求與方案，包括硬件的型號、參數(shù)和技術(shù)規(guī)范等，形成零部件技術(shù)規(guī)范（Component Technical Specification，CTS）。

軟件分析與設(shè)計通常由軟件算法工程師負(fù)責(zé)，根據(jù)產(chǎn)品需求和系統(tǒng)技術(shù)規(guī)范，制定軟件詳細需求與方案，形成軟件需求說明書（Software Requirement Specification，SRS）。

硬件開發(fā)包括各類傳感器以及智駕域控制器的開發(fā)，通常由專業(yè)的硬件供應(yīng)商完成，但也有主機廠會參與開發(fā)部分硬件，如激光雷達、毫米波雷達等。

軟件開發(fā)包括操作系統(tǒng)、中間件和應(yīng)用層算法等模塊的開發(fā)，是目前行業(yè)內(nèi)爭奪和競爭最為激烈的環(huán)節(jié)，主機廠想要自研、Tier 1想要把控、各類算法供應(yīng)商想堅持黑盒，但最終都會完成各類功能的軟件算法模塊。

硬件與軟件開發(fā)完成后，進入到測試和驗證階段。首先在軟件層面搭建軟件測試環(huán)境，設(shè)計測試用例與腳本，制定軟件模塊測試方案，并完成軟件模塊測試；然后將智能駕駛的軟件算法搭載到控制器上，搭建臺架測試環(huán)境，完成基于臺架的集成仿真測試，又稱為硬件在環(huán)測試（Hardware-In-Loop，HIL）；最后，將所開發(fā)的智能駕駛系統(tǒng)，裝載到實車上，通過場地和道路測試，最終驗證智能駕駛產(chǎn)品的效果，包括功能、性能、交互、用戶體驗等內(nèi)容。

可以看出，對于正向開發(fā)來說，智能駕駛的開發(fā)應(yīng)該嚴(yán)格遵循圖1所示的V型流程，在產(chǎn)品設(shè)計與定義階段，明確產(chǎn)品需求與開發(fā)目標(biāo)，并逐層傳遞到具體的開發(fā)工作中，然后再逐步集成化測試，在整車層面驗證產(chǎn)品達到目標(biāo)的效果。

不過，在現(xiàn)階段，由于市場競爭激烈、缺乏統(tǒng)一規(guī)范等原因，智能駕駛實際的開發(fā)過程，往往難以遵循正向開發(fā)流程，出現(xiàn)了一些違背正向開發(fā)理念的做法，導(dǎo)致產(chǎn)品質(zhì)量難以保證，用戶體驗不佳，并增加了大量的改進成本。

下面，我們分別從硬件方案和軟件方案2個方面，展開講述在智能駕駛開發(fā)過程中，如何按正向開發(fā)流程開展工作，并避免出現(xiàn)簡單歸納法思維以及逆向開發(fā)的情況。

三 硬件方案的正向定義

【本文提到的硬件方案，有些已經(jīng)是眾所周知的知識，但我們?nèi)韵Ｍㄟ^本文的解釋，能讓讀者“知其然，更知其所以然”，獲得“先有產(chǎn)品定義，后有硬件方案”的正向開發(fā)理念?！髡咦ⅰ?/p>

我們經(jīng)常在發(fā)布會上聽到這樣的說法：“我們的產(chǎn)品配置了激光雷達，擁有三十多個傳感器，還用了先進的高算力芯片，是先進的智能駕駛?！?/p>

也經(jīng)常在工作中聽到這樣的說法：“我們?nèi)ズ?a class="article-link" target="_blank" href="/manufacturer/1000151/">英偉達/地平線合作，先把芯片定下來，再看看能做到什么程度?！?/p>

甚至?xí)牭焦靖邔舆@么說：“你們?nèi)タ纯葱※i/蔚來/理想/大疆的選型方案，我們跟他們用一樣的，效果應(yīng)該差不多。”

以上現(xiàn)象的背后，是一種典型的硬件方向逆向開發(fā)的思維方式。在逆向開發(fā)的認(rèn)知中，“配置了高端的硬件，就有了高端的智能駕駛；把市場上別人用的硬件方案歸納一下，選擇差不多的方案，就能做出類似的效果”。

但事實很可能是：你用8M像素的攝像頭，做出的功能體驗不一定比得上別人5M攝像頭的效果；你用100TOPS算力的芯片，實現(xiàn)的功能未必有別人30TOPS芯片實現(xiàn)的功能多。

這種情況與軟、硬件的綜合能力有關(guān)，但更本質(zhì)的原因還是在于：沒有按照正向開發(fā)的思路，前期開發(fā)目標(biāo)不明確。

根據(jù)前面提到的正向開發(fā)流程，在定義硬件方案前，更重要的是做好產(chǎn)品層面、系統(tǒng)層面的分析、設(shè)計與定義。也就是說，硬件方案應(yīng)該是服務(wù)于功能需求、性能要求和產(chǎn)品整體開發(fā)目標(biāo)的，應(yīng)該是“需求先行”，而不是“硬件先行”。

下面，我們以功能需求展開，說明如何按照正向開發(fā)流程，根據(jù)功能需求定義硬件（傳感器+計算平臺）方案。

在九章智駕之前的文章《詳解智能駕駛的功能與場景體系》中，已經(jīng)系統(tǒng)化地總結(jié)了目前主要的智能駕駛功能，包含行車功能、泊車功能、主動安全功能等。

智能駕駛的傳感器主要包括攝像頭、毫米波雷達、超聲波雷達與激光雷達，通過在車身的不同位置布置多種類型的傳感器，實現(xiàn)對車輛周圍區(qū)域的檢測；廣義的傳感器還包括地圖定位。傳感器的分布和作用，大部分人已經(jīng)非常熟悉，在此不作贅述，直接參考圖1即可。

智能駕駛各項功能的實現(xiàn)，依賴于傳感器對相關(guān)區(qū)域的檢測，因此不同的功能需求，對應(yīng)著不同的傳感器方案。根據(jù)各項智駕功能的效果，以及圖1所示的傳感器檢測范圍，可以得出各項功能所需的傳感器配置，如表1所示。需要說明的是，表1中勾選的傳感器配置，是該功能至少需要的傳感器，如果成本允許，當(dāng)然是越多傳感器越好。

表1 智駕功能與傳感器對應(yīng)關(guān)系

根據(jù)表1，在定義傳感器方案時，對于行車功能，單車道L2級功能如LCC只需前視攝像頭+前向毫米波雷達；多車道L2級功能涉及相鄰車道，還需要前、后角毫米波雷達；點到點的領(lǐng)航駕駛功能，需要增加側(cè)視攝像頭與后視攝像頭，而城區(qū)路況更加復(fù)雜，因此C-NOA還需要激光雷達。

對于泊車功能時，停車位區(qū)域的自動泊車需環(huán)視攝像頭+超聲波雷達，而停車場范圍的記憶泊車、智能召喚、自主代客泊車等功能，涉及低速行駛的場景，因此需要增加行車功能相同的傳感器。

主動安全功能的傳感器，主要與功能所覆蓋的方位有關(guān)。

在定義傳感器配置方案時，通?？梢愿鶕?jù)產(chǎn)品的功能需求，參考表1的匯總結(jié)果，根據(jù)功能，逐一確定所需配置的傳感器類型。至于傳感器的具體參數(shù)、型號，則需進一步根據(jù)產(chǎn)品性能要求，按照同樣的思路來定義。

智能駕駛的計算平臺，主要是指域控制器，其重點是SoC芯片與MCU芯片。其中SoC芯片主要用于AI計算，即處理大量的環(huán)境感知與定位數(shù)據(jù)，以及作出任務(wù)決策和軌跡規(guī)劃等；MCU主要負(fù)責(zé)執(zhí)行指令，以及安全可靠性。

SoC芯片的最重要任務(wù)是處理環(huán)境感知與定位信息，因此，智駕方案對SoC的AI算力的需求與環(huán)境數(shù)據(jù)的豐富程度緊密相關(guān)。

根據(jù)正向開發(fā)流程，在傳感器配置方案完成后，應(yīng)該根據(jù)各傳感器的數(shù)據(jù)量，評估SoC芯片所需的算力水平。由于各家的算法不同，不同SoC芯片的內(nèi)部架構(gòu)不同，因此同一套傳感器配置，可能會出現(xiàn)不同的AI算力要求，但算力水平的大概量級，應(yīng)該是一致的。

例如，單車道L2級智能駕駛只需要前視攝像頭與前向毫米波雷達，5TOPS以內(nèi)的AI算力足以滿足；多車道L2級智能駕駛還需要角毫米波雷達，因此需要5TOPS以上的AI算力；高速領(lǐng)航駕駛H-NOA還涉及側(cè)視攝像頭的數(shù)據(jù)，通常需要30TOPS以上的AI算力；城區(qū)領(lǐng)航駕駛C-NOA由于需要處理大量的激光雷達點云數(shù)據(jù)，通常要求AI算力達到200TOPS以上。

表2匯總了現(xiàn)階段的主要智駕SoC芯片。在確定智駕產(chǎn)品所需的AI算力水平后，可以從表2中，選取相應(yīng)的SoC芯片，完成計算平臺的核心選型。不過，在實際應(yīng)用中，AI算力只是關(guān)鍵參數(shù)，此外還要綜合考慮軟件與芯片的匹配度、平臺成熟度、成本等多種因素，定義出最適合自己的方案。

表2 智駕SoC芯片匯總

以上，就是從功能需求→硬件方案的正向定義方法，這種正向演繹的思維，能夠從功能需求出發(fā)，在充分理解各傳感器用途和算力分布的基礎(chǔ)上，定義出最優(yōu)的硬件方案。

四 軟件方案的正向定義

在軟件方案中，操作系統(tǒng)和中間件往往是成熟的方案，并且難以在產(chǎn)品效果層面直接體現(xiàn)；但應(yīng)用層算法，尤其是各項功能的實現(xiàn)邏輯和關(guān)鍵參數(shù)，是影響智駕產(chǎn)品最終效果的重要因素。

按照正向開發(fā)的流程，智能駕駛算法的邏輯和參數(shù)，應(yīng)該是在產(chǎn)品設(shè)計與定義階段提出，經(jīng)系統(tǒng)分析與設(shè)計階段細化后，傳遞到軟件開發(fā)層面。但在實際的開發(fā)過程中，往往容易出現(xiàn)需求定義不清、具體模塊開發(fā)人員不聞不問，隨便拍腦袋，甚至直接照搬其他車型方案的情況，導(dǎo)致最終開發(fā)出來的功能，偏離最初的開發(fā)目標(biāo)。

下面通過幾個功能的真實案例來說明，軟件方案的常見逆向開發(fā)做法，以及正確的正向開發(fā)方式。

案例一：自動泊車APA

某公司的APA功能開發(fā)時，由于項目時間緊任務(wù)重，在缺乏產(chǎn)品需求和系統(tǒng)關(guān)鍵參數(shù)的情況下，算法工程師認(rèn)為“目前市場上的APA功能已經(jīng)很成熟，可以直接拿來用”。在簡單了解了某款車型的泊車關(guān)鍵參數(shù)后，就迅速開展工作，達到了與該車型大概相同的自動泊車效果。

但在實車測試時發(fā)現(xiàn)，車輛泊車完成后的位置，不能夠根據(jù)周圍環(huán)境自動調(diào)整，導(dǎo)致在周圍有障礙物時，有時距離障礙物過近，不方便用戶開門下車。并且，在泊車過程中，多次出現(xiàn)方向盤大幅左右晃動、車身不穩(wěn)的情況。

根源就是因為軟件參數(shù)不是通過正向開發(fā)得到的，而是工程師歸納式簡單參考的結(jié)果。

原本可以通過正向開發(fā)避免的問題，由于急功近利的逆向開發(fā)方式，導(dǎo)致泊車功能缺乏亮點，無法讓用戶滿意，沒有達到預(yù)期的產(chǎn)品效果。

對于這種情況，按照正向開發(fā)的流程，首先應(yīng)該考慮的是在產(chǎn)品設(shè)計與定義階段，通過競品分析、用戶調(diào)研等方法，提前考慮到泊車過程中對舒適度的要求，明確對橫向控制穩(wěn)定性的要求，以及泊車完成后的車身位置要求。即使項目時間緊張，也可以壓縮各階段的項目周期，而不能直接“裁剪”掉最重要的源頭階段。

案例二：自適應(yīng)巡航ACC

有一次，ACC功能開發(fā)過程中，我們遇到了ACC目標(biāo)車速變更和ACC跟車停止邏輯的問題。

在開發(fā)ACC功能時，我們團隊的產(chǎn)品經(jīng)理經(jīng)過市場對標(biāo)和用戶體驗分析后，在產(chǎn)品需求中明確提出：用戶使用ACC功能時，通過“短按”方向盤的車速調(diào)節(jié)按鍵，控制目標(biāo)車速按步長5kph不變化，通過“長按”按鍵，控制目標(biāo)車速按步長1kph變化。

原因是，在道路中行駛時，車速變化1kph的場景極少且沒有明顯意義，因此通過“長按”的方式來控制；車速變化5kph對于改變車速更有意義，因此通過“短按”這一更為簡單的方式來控制。

但是，在開發(fā)過程中發(fā)現(xiàn)，負(fù)責(zé)對應(yīng)開發(fā)模塊的工程師，忽略了產(chǎn)品需求，通過自己的判斷和市場上某一款車型的做法，私自更改產(chǎn)品需求，導(dǎo)致開發(fā)結(jié)果偏離目標(biāo)。

這種簡單的經(jīng)驗式歸納，直接導(dǎo)致該功能的效果是由軟件需求反向影響產(chǎn)品需求，也降低了產(chǎn)品效果。雖然最終得到了改正，但對項目整體來說，產(chǎn)生了額外的成本。

另外，ACC控制車輛停車時，出于功能一致性和連續(xù)性的考慮，產(chǎn)品需求中要求在任何時候，用戶踩下制動踏板，ACC功能都應(yīng)該完全退出，但在開發(fā)過程中，負(fù)責(zé)對應(yīng)模塊的工程師，忽略了產(chǎn)品需求，自行定義為“車輛靜止?fàn)顟B(tài)下，哪怕用戶踩下制動踏板，ACC功能仍然能保持”。這不僅違背了功能整體邏輯，也額外增加了軟件工作量。

以上情況，雖然開發(fā)過程是按照正向流程，產(chǎn)品→系統(tǒng)→軟件，但在執(zhí)行過程中，軟件模塊的開發(fā)人員仍沒有意識到正向開發(fā)的重要性，按照個人經(jīng)驗去逆向定義甚至忽略產(chǎn)品的需求，導(dǎo)致偏離開發(fā)目標(biāo)，也導(dǎo)致項目的時間和人力成本增加。

這種是個典型的“有流程，但沒有意識”的案例。很多時候，公司高層和項目負(fù)責(zé)人已經(jīng)認(rèn)識到正向開發(fā)的重要性，并且制定了具體的工作流程，但公司的一些研發(fā)人員卻沒有正向開發(fā)的意識，仍然按照個人經(jīng)驗，照搬過去的做法，導(dǎo)致正向開發(fā)難以完全貫徹落實，新產(chǎn)品的亮點難以得到百分百地呈現(xiàn)。

針對這種意識、觀念層面的問題，我們能做的就是首先在團隊整體明確正向開發(fā)的理念和方法，然后去培養(yǎng)工程師的正向開發(fā)思維，通過團隊的影響力，帶動個人的意識提升。

案例三：高速領(lǐng)航H-NOA

H-NOA功能開發(fā)過程中，我們遇到了默認(rèn)車道策略和進入匝道前變道時機的問題。

團隊在定義H-NOA功能時，對默認(rèn)的行駛車道沒有作出明確定義，僅要求“在合理的車道中行駛”。算法人員在開發(fā)時，為降低感知的難度，將默認(rèn)車道設(shè)定為高速公路的最左側(cè)車道。

實際上，根據(jù)大量老司機的駕駛經(jīng)驗，以及《道路交通安全法》的要求，高速公路中的長時間行駛車道應(yīng)該是左側(cè)第二車道，車輛不應(yīng)該長期保持在最左側(cè)車道行駛。

同樣，對于進入匝道前的變道邏輯，前期也沒有作明確定義，僅要求“能夠在進入匝道前，變道至緩沖車道或最右側(cè)車道”。算法人員在缺乏溝通和調(diào)研的情況下，對變道時機的參數(shù)定義過于激進，導(dǎo)致測試時，多次出現(xiàn)無法成功進入匝道的情況。

這種情況是由于在項目前期缺乏全面的考慮，導(dǎo)致對產(chǎn)品的某些參數(shù)缺乏定義，具體開發(fā)時缺乏依據(jù)。

按照正向開發(fā)流程，在產(chǎn)品和系統(tǒng)層面，相關(guān)人員應(yīng)該盡可能地全面定義各項關(guān)鍵參數(shù)；對于NOA這類相對復(fù)雜的功能，如果前期確實遺漏了某些參數(shù)的定義，那么具體模塊的開發(fā)人員在缺乏依據(jù)時，應(yīng)該主動向產(chǎn)品或系統(tǒng)人員確認(rèn)、溝通，而不是自作主張地“拍腦袋”。

前期產(chǎn)品需求全面細致，各具體模塊負(fù)責(zé)人員主動溝通，這樣才能讓正向開發(fā)的流程更好地推進，產(chǎn)品效果得到保證；否則，如果需求定義不清，后續(xù)模塊人員自作主張，那么實際上又變成了逆向開發(fā)的模式，正向開發(fā)也就成了表面文章。

五?結(jié)語

以上，就是智能駕駛的正向開發(fā)方法，以及如何在實際工作中，貫徹正向開發(fā)理念的一些理論和經(jīng)驗總結(jié)?；谘堇[法的正向開發(fā)理念，能夠讓智能駕駛產(chǎn)品在充分滿足用戶需求，保證產(chǎn)品質(zhì)量的同時，確保開發(fā)目標(biāo)合理且得到落實。

不過，本文的內(nèi)容屬于基本的思路和方法論，在具體的產(chǎn)品開發(fā)過程中，還需根據(jù)實際情況，如開發(fā)能力、成本、周期、資源等，靈活定義方案，及時調(diào)整，作出最合理、能落地的選擇。