以智駕系統(tǒng)功能開發(fā)講解智駕底軟如何驅(qū)動功能開發(fā)

對智能駕駛系統(tǒng)的研發(fā)流程上講，一直希望從頂層系統(tǒng)架構(gòu)開始到底層之間一次性講清整個智駕系統(tǒng)是如何進(jìn)行信息交互、應(yīng)用調(diào)用和過程傳遞的。整個信息流的傳遞和過程交互包含行車控制和泊車控制，兩種應(yīng)用在實(shí)際的控制上存在一定的差異。本文將針對泊車控制功能模式從底層軟件、中間件到應(yīng)用軟件之間的信息交互和過程控制邏輯進(jìn)行詳細(xì)講解。
1.通用軟件架構(gòu)及說明舉例
當(dāng)前不同供應(yīng)商和主機(jī)廠在整個軟件架構(gòu)上基本都是一致的設(shè)計方式。通常采用的是從底向上的分層設(shè)計方式，如下圖所示。我們在這里不詳細(xì)分析軟件架構(gòu)到底是怎樣的構(gòu)造方式，我們詳細(xì)說明一下整車開發(fā)的軟件過程管理和模塊調(diào)用分工。

1）基礎(chǔ)計算平臺
Tier1通過接收主機(jī)廠的硬件架構(gòu)，包含視頻輸入、視頻輸出、超聲波、以太網(wǎng)、接插件位置等導(dǎo)致原理圖、PCB新設(shè)計。
2）外圍硬件驅(qū)動
Tier1根據(jù)主機(jī)廠硬件需求和架構(gòu)需求對傳感器進(jìn)行合適的硬件驅(qū)動。如攝像頭直連域控時，其驅(qū)動方式就是域控通過IIC配合一定的驅(qū)動算法直接驅(qū)動攝像頭開閉。同時，也包含與超聲波雷達(dá)適配、毫米波雷達(dá)適配、車身數(shù)據(jù)（線控）適配、RTK_SDK集成。
3）內(nèi)部硬件平臺
這個模塊主要tier1/tier2根據(jù)感知需求對其處理過程包含相機(jī)加速處理、深度學(xué)習(xí)模型底層服務(wù)評估所需要的算力需求，從而對所搭載的硬件平臺能力進(jìn)行總體布局。如果開發(fā)是非全棧的話，tier2需要將處理完成的感知數(shù)據(jù)集成打包并制定好接口給到tier1。
4）系統(tǒng)軟件
一般tier1會根據(jù)選型的芯片選擇其適配度較好的操作系統(tǒng)，同時配置相應(yīng)的時間管理、日志管理、安全實(shí)時內(nèi)核、標(biāo)準(zhǔn)信息服務(wù)等。
5）功能軟件
對于tier1分解的功能軟件來說，主要包含兩個層面：一種面向客戶級別的頂層功能，這些功能需求主要是通過將客戶需求直接拆解到系統(tǒng)需求來實(shí)現(xiàn)；另一種個是系統(tǒng)級別拆解到具體軟件的識別端。比如感知、定位、環(huán)境建模、規(guī)控算法參數(shù)適配。算法邏輯也涉及ODD檢測、ADAS新增元素部分檢測能力、相機(jī)標(biāo)定；支持速度、路線距離、動態(tài)感知初始化等。
6）應(yīng)用軟件
從軟件架構(gòu)設(shè)計的角度講，應(yīng)用軟件設(shè)計層主要是拆解客戶需求（主機(jī)廠輸入的功能配置表或功能規(guī)范），一般會形成一個feature list和sub feature list。開發(fā)過程，頂層APP的每個software模塊需要如上的feature list相對應(yīng)，以確保所有feature都是被開發(fā)完成的。
接下來，將就一個常見的記憶泊車場景來對整個軟件架構(gòu)如何處理ADAS功能進(jìn)行說明。
對于智能泊車（如記憶泊車）而言最重要的幾個點(diǎn)就是常規(guī)的感知到規(guī)控處理、記憶建圖處理、時間同步、日志記錄、標(biāo)準(zhǔn)通信管理。
2.感知到?jīng)Q策的底軟Pipeline設(shè)計
在總體要求的基礎(chǔ)上，智能泊車需要增加停車場動態(tài)交通信息、場景融合信息、場內(nèi)外車輛交接信息、場（路）側(cè)智能設(shè)備信息以及自定義的其他擴(kuò)展信息等相關(guān)地圖數(shù)據(jù)信息。停車場動態(tài)信息包含停車場內(nèi)或出入口關(guān)聯(lián)道路上實(shí)時發(fā)生的，會對泊車過程或行人通行產(chǎn)生影響的一系列動態(tài)信息。
以上信息都需要專門的視覺感知模塊進(jìn)行有效的檢測和處理。對于視覺感知處理這塊可以整理一個大概的數(shù)據(jù)處理通路，本文將針對性的對底層軟件角色在自動駕駛軟件中的位置及模塊劃分方式有一個大致說明。
智能泊車感知從常規(guī)處理手段上一般都是環(huán)視+超聲波融合的方式進(jìn)行。而對于記憶泊車而言，還存在建圖過程中對前方行駛車輛的軌跡探測和前方碰撞目標(biāo)的危險程度探測。因此，通常會考慮接入行車前視攝像頭信息以增強(qiáng)其前方探測能力。由于通常ADAS高階系統(tǒng)域控為行泊一體控制器，為了提升運(yùn)算效能，對于行泊感知源通常會采用分時復(fù)用的方式進(jìn)行感知數(shù)據(jù)的有效處理。同時，智能泊車內(nèi)部也是會采用合適的Pipeline進(jìn)行功能處理。
如下圖表示了智能泊車的pipeline處理策略模塊。

對于智駕系統(tǒng)而言，前視攝像頭會采用一種異構(gòu)的大小眼。而對于泊車功能而言，采用其中一種寬視前視即可具備足夠的識別能力同時可降低對系統(tǒng)的算力需求，一般只應(yīng)用到了前視寬角視頻圖像作為輸入來進(jìn)行目標(biāo)探測。
從處理高效能角度講，其相應(yīng)的處理方式包括：

Distortion Correction+Resize—>模擬前廣角，不丟失視場探測范圍，該前視探測信息便可適配智能泊車域；

Crop+Resize—>模擬前中距，保留一定FOV及像素密度，適用于泊車低速巡航控制；

Crop—>模擬長焦距，不丟失遠(yuǎn)處像素密度，適用于智能泊車前方小目標(biāo)緊急探測；

以上各方感知輸入源最后會在中央域控中輸入一個總體的感知融合算法模塊，從而構(gòu)建出實(shí)時的車身位姿數(shù)據(jù)以及對應(yīng)的地圖元素感知特征數(shù)據(jù)。
如上圖所示的整個Pipeline在頂層軟件運(yùn)行過程中，需要開發(fā)包含應(yīng)用場景分析、精準(zhǔn)定位、地點(diǎn)查詢、安全預(yù)警、路徑方式幾個方面的軟件模塊。其中，應(yīng)用場景模塊主要涉及停車場、停車場運(yùn)營服務(wù)平臺、MPA、APA、AVP等智能泊車系統(tǒng)。精準(zhǔn)定位包括GNSS、RTK、SLAM、VIO（視覺慣性里程計）、FLD（特征定位數(shù)據(jù)）、UWB等。地點(diǎn)查詢包括停車場及車位查詢、ODD范圍、興趣點(diǎn)、停靠泊車（如上下車點(diǎn)/充電）等。安全預(yù)警部分則包括障礙物、安全冗余、禁區(qū)、限制管控、危險路段、預(yù)警措施等。每種軟件模塊在如上三條Pipeline里面都需要調(diào)用專門的中間件模塊組合來輸入到最終的大狀態(tài)機(jī)做狀態(tài)判斷，并執(zhí)行不同的泊車輔助功能。最后通過地圖、定位、感知數(shù)據(jù)的協(xié)同技術(shù)輸出到整體大狀態(tài)機(jī)的判斷邏輯實(shí)現(xiàn)功能的激活決策控制。
建圖定位模塊的關(guān)鍵技術(shù)主要包括車輛本身定位和車位地圖掃描兩個部分。該模塊需要完成車輛周圍信息的感知和建模，車輛自身的定位和跟蹤反饋，所建立的地圖和定位信息是自動泊車路徑規(guī)劃和控制決策模塊的根源基礎(chǔ)，也是決定車輛自動泊車質(zhì)量的直接因素。
此外，需要說明的是，如上三個Pipeline的底層軟件模塊設(shè)計中，Pipeline1主要是通過接收完成里程計估算，生成自建地圖；Pipeline3是超聲波雷達(dá)數(shù)據(jù)輸入處理得到的感知語義數(shù)據(jù)，與全局高精定位輸入的原始定位數(shù)據(jù)進(jìn)行融合后生成對應(yīng)的定位相關(guān)元素；Pipeline2則是通過輸入與泊車相關(guān)的視覺感知信息到視覺加速模型數(shù)據(jù)、并融合Pipeline1和Pipeline3的數(shù)據(jù)輸入并應(yīng)用恰當(dāng)?shù)乃惴ㄟM(jìn)行融合數(shù)據(jù)更新；最后輸入泊車大狀態(tài)機(jī)里面做狀態(tài)決策判斷。通過最終輸入的不同數(shù)據(jù)鏈路可以決策狀態(tài)機(jī)最終激活何種泊車功能。
3.智能泊車在底軟中的計算資源分配
對于泊車感知視頻源處理端主要由攝像頭Sensor自身驅(qū)動模塊、視頻接口驅(qū)動模塊、異構(gòu)核IPC通信模塊以及A核接口構(gòu)成。攝像頭自身驅(qū)動主要是進(jìn)行通用的傳感器設(shè)置、曝光處理、原始數(shù)據(jù)白平衡處理、色彩空間轉(zhuǎn)換等原始操作。視頻接口驅(qū)動需要運(yùn)行在實(shí)時核R上負(fù)責(zé)整個視頻硬件加速，才能保證接入的視頻原始數(shù)據(jù)無延遲。同時，充分利用異構(gòu)核資源優(yōu)勢，作為專用核來確保視頻圖像高實(shí)時、高可靠性。R核采集的視頻數(shù)據(jù)通過管道通信機(jī)制IPC實(shí)現(xiàn)數(shù)據(jù)快速傳輸?shù)接嬎鉇核。最終A核通過通用的事件處理機(jī)制，處理所傳輸過來的視頻數(shù)據(jù)，并將是視頻數(shù)據(jù)進(jìn)行有效封裝并暴露出與硬件無關(guān)的接口供上層應(yīng)用軟件調(diào)用。
下面針對如上圖所示的幾個由底軟實(shí)現(xiàn)的功能軟件進(jìn)行說明：
總體來說，底層軟件的功能相對于之前分析的應(yīng)用軟件，其主要是需要驅(qū)動硬件獲得原始感知數(shù)據(jù)，并進(jìn)行一定的前端處理、封裝、打包等操作后生成對應(yīng)能被上層所感知的軟件模塊SWC輸入給上層應(yīng)用APP。如下圖所示表示了一種完整的泊車控制在底層軟件模塊中的示意圖。

1）感知驅(qū)動
首先，對于記憶泊車而言，需要底軟調(diào)用硬件驅(qū)動文件從前端感知硬件獲取超聲波雷達(dá)、環(huán)視攝像頭、前視攝像頭的對應(yīng)RawData。然后，通過標(biāo)準(zhǔn)的Autosar處理模塊進(jìn)行消息路由PDU、轉(zhuǎn)發(fā)等。然后在數(shù)據(jù)處理模塊中需要參照一定的軟件處理算法進(jìn)行數(shù)據(jù)處理分類。分類結(jié)果是輸出車道線、車位、環(huán)境目標(biāo)等信息。
2）任務(wù)分配
對于完整的記憶泊車軟件架構(gòu)任務(wù)分配來說，擅長高計算能力的SOC需要執(zhí)行循跡巡航、探索前進(jìn)、倒車輔助、泊車出庫、泊車入庫這幾個大類的軟件任務(wù)。這些任務(wù)的實(shí)現(xiàn)主要是通過環(huán)境信息+自車定位信息來實(shí)現(xiàn)軌跡規(guī)劃和控制任務(wù)，同時通過中間件模塊的場景管理調(diào)度原子服務(wù)+提供任務(wù)參數(shù)來補(bǔ)充到整個泊車控制任務(wù)中。
3）環(huán)境建模EM
在底軟到中間件的建模過程中，需要構(gòu)建環(huán)境建模模塊EM對障礙物信息（freespace、bounding-box），路面信息（車位、阻車器、減速帶）的進(jìn)行有效的建模和封裝。改模塊對于上層應(yīng)用軟件的調(diào)度來說需要封裝成統(tǒng)一接口的。且底軟可通過頂層軟件的不同的功能輸入構(gòu)建不同的配置文件進(jìn)行不同的環(huán)境建模。
4）定位建圖
對定位建圖來說，則是需要對位置、姿態(tài)、速度、角速度、加速度、車道線的信息重建。對于記憶泊車而言，首先需要建立兼具語義特征穩(wěn)定、低層特征豐富、環(huán)境適應(yīng)性強(qiáng)的泊車地圖。因此，建圖過程中，需要充分融合包含行泊車的各方傳感器輸入（如攝像頭感知輸出的底層特征圖及地圖元素的感知輸入），既能保證各方傳感器相互獨(dú)立，又能進(jìn)行相互間的補(bǔ)充校驗，從而提高容錯性。此外，關(guān)于建圖過程中需要充分考慮IMU和輪速計之間的預(yù)融合（Pre-integration），保持建圖尺度的一致性，提升通用性。從底軟的角度講，除了建圖結(jié)果需要呈現(xiàn)的地圖調(diào)度接口應(yīng)該是能夠為上層調(diào)用外，其建圖過程通常實(shí)時更新的。因此需要考慮所有的過程是需要被實(shí)時記錄和可追溯。如果有建圖不成功的情況，應(yīng)該是需要做有效的日志記錄Log的。
5）場景管理
場景管理部分則需要對車輛狀態(tài)、探索前進(jìn)任務(wù)、巡航任務(wù)、示教軌跡、倒車輔助任務(wù)、軌跡記錄、泊入任務(wù)+車位id、泊出任務(wù)+出庫方式等整個過程控制。底軟和中間件需要調(diào)度對應(yīng)的任務(wù)分配模塊，將對應(yīng)的任務(wù)實(shí)現(xiàn)邏輯運(yùn)用到整個管理過程中。
6）控車仲裁
此外，在實(shí)時核MCU中需要對控車模塊進(jìn)行仲裁，需要考慮泊車緊急制動功能MEB的激活是否會與行車功能起沖突，因此在執(zhí)行控制過程中需要進(jìn)行指令仲裁，實(shí)現(xiàn)控車權(quán)的仲裁，最后底軟接口需要將執(zhí)行指令封裝成總線信號形式發(fā)送給執(zhí)行器執(zhí)行。
4.智能泊車在底軟中的存取資源分配
我們高階自動駕駛通常需要搭載高分辨率攝像頭，整個Capture驅(qū)動主線是基于基礎(chǔ)芯片框架實(shí)現(xiàn)，開發(fā)過程中可以對多輸入源的Graph進(jìn)行支持，異常資源釋放等功能。對于視覺感知處理這塊可以整理一個大概的數(shù)據(jù)處理通路，可以對底層軟件角色在自動駕駛軟件中的位置及模塊劃分方式有一個大致說明。
如下圖表示了從底軟的角度描述了整個視頻流在抓取、存儲和取出的整個驅(qū)動過程。無論行泊車對于輸入的三路虛擬攝像頭信息分別需要進(jìn)行如下方式的處理。

關(guān)于視頻數(shù)據(jù)流的抓取的驅(qū)動過程包含如下幾個步驟：攝像頭初始化Camera Init——>圖像抓取Camera Capture——>完成視頻圖像采集——>形成攝像頭視頻序列Camera Quenue——>進(jìn)行視頻序列Buffer管理——>實(shí)現(xiàn)處理視頻數(shù)據(jù)的零拷貝；
從底層軟件架構(gòu)的角度分析，對于如上圖所示的視頻序列的存取處理機(jī)制（如神經(jīng)網(wǎng)絡(luò)CNN）所涉及的幾個過程主要是通過CPU對DSP的調(diào)度實(shí)現(xiàn)。首先，通過CPU實(shí)現(xiàn)模型創(chuàng)建生成加載模型，開辟合適的內(nèi)存；其次，通過CPU實(shí)現(xiàn)模型計算，反饋合適的計算結(jié)果；最后，模型退出后，CPU又需要釋放所占用的的內(nèi)存資源。
5.底層軟件在智能泊車中的處理流程

最后，通過一個詳細(xì)的底軟架構(gòu)圖分析說明如何對應(yīng)用軟件模塊進(jìn)行調(diào)用。
①SOC硬件層調(diào)度傳感器硬件相機(jī)驅(qū)動，傳輸原始感知數(shù)據(jù)流給到上層操作系統(tǒng)。這里的原始感知數(shù)據(jù)時可以通過感知框架中的任務(wù)管理模塊（接收所要執(zhí)行的ADAS任務(wù)子項）、相機(jī)管理模塊（相機(jī)輸入數(shù)據(jù)配置、相機(jī)硬線配置、相機(jī)曝光配置）、配置管理模塊（主要是根據(jù)輸入的ADAS任務(wù)管理子項配置合理的傳感器輸入數(shù)據(jù)來進(jìn)行感知檢測）進(jìn)行數(shù)據(jù)預(yù)處理、模型搭建和數(shù)據(jù)并行處理后，生成了車道線、交通標(biāo)志、障礙物信息、可行駛區(qū)域、泊車位置空間。

②為了給上層感知處理模塊提供可靠、高效的視頻源。中間件需要進(jìn)行傳感器時間同步管理、通信管理、資源管理、配置管理、OTA管理等。
時間同步管理：將輸入的各類不同的傳感數(shù)據(jù)按照系統(tǒng)自定的時間管理策略標(biāo)識打上時間戳。這類算法需要參照具體的系統(tǒng)架構(gòu)來定，比如攝像頭作為純傳感器，其曝光、視頻輸出處理都是完全由域控來打時間戳同步；而如果超聲波雷達(dá)外接了處理ECU，則其輸入輸出則需要由子ECU自己控制打時間戳。但是通常底軟在這部分時間同步算法上會遵循標(biāo)準(zhǔn)的Autosar標(biāo)準(zhǔn)。
通信管理：BCU通過喚醒信號控制相應(yīng)CAN消息的通信使能（交流、直流幀），RTE將應(yīng)用層SWC信號轉(zhuǎn)化為通信信號（Com Signals），并通過Com, PduR, CanIf, Can driver之間的標(biāo)準(zhǔn)接口函數(shù)實(shí)現(xiàn)CAN信號收發(fā)。
資源管理：對于從底層軟件配置、中間件調(diào)度、頂層軟件調(diào)度和運(yùn)算中需要利用的資源進(jìn)行相應(yīng)的存儲管理和算力分配。
配置管理：配置管理可以用于對輸入傳感器的數(shù)據(jù)進(jìn)行分時控制，從不同的場景角度上講，這塊可以很好的提升對傳感數(shù)據(jù)的處理效率。
③在感知處理模塊包含三個層面的處理邏輯。視頻輸入鏈路進(jìn)行ISP處理、Camera數(shù)據(jù)接口、Sensor驅(qū)動、輸入接口驅(qū)動。計算加速模塊進(jìn)行神經(jīng)網(wǎng)絡(luò)（CNN/RNN）推理、圖像去畸變、圖像Crop+Resize預(yù)處理、圖像顏色空間轉(zhuǎn)換。Display輸出模塊需要創(chuàng)建數(shù)據(jù)接口、輸出接口底層驅(qū)動。
④頂層軟件調(diào)用底層軟件封裝的軟件模塊接口對對應(yīng)的軟件模塊進(jìn)行調(diào)用。其中通信中間件需要為應(yīng)用層用戶提供統(tǒng)一的調(diào)度接口，包含初始化、注冊、發(fā)送/接收等接口。通信中間件可以基本實(shí)現(xiàn)多節(jié)點(diǎn)分布式軟件模塊的發(fā)布訂閱通信（類似于SOA中面向服務(wù)的通信機(jī)制進(jìn)行初始化、訂閱注冊、發(fā)送注冊、消息推送、接收），且通常位于SOC和MCU之間的異地通信以及SOC內(nèi)部的本地通信。