嫌自動駕駛不可靠？那你先來看看車載視覺處理有多難

今天，大家對自動駕駛都充滿了期待，任何一場科技大秀上，總少不了自動駕駛的身影。不過與之伴生的，還有與自動駕駛相關的事故數量的增加，特斯拉、Uber前後腳都發生了在自動駕駛狀態下的致死事故。

可能你會覺得自動駕駛商用進程有些慢，現在的方案還不可靠，但考慮到其應用場景的特殊性，以及開發上的難度，你就不會有太多抱怨了。比如就車載視覺處理，這個自動駕駛的核心要素來說，其對開發者提出的挑戰就不一般。

姑且不提自動駕駛，今天想做好一款像樣的ADAS就不簡單。一方面，ADAS視覺處理需要應對越來越複雜的應用環境，暗光、惡劣天氣下也要確保可靠的表現；另一方面，為了提升視覺系統識別判斷的準確性，甚至讓其具有自我學習提升的能力，引入機器學習、神經網路等AI演算法也勢在必行。

這些需求必然會增加視覺處理工作的複雜性和負荷，耗費更多的計算資源和時間，而這又恰恰和車載應用這個資源受限的嵌入式環境，以及“硬”即時性的要求構成矛盾……這就是車載視覺應用開發者每天面對的困局。

圖1，車載視頻處理典型流程

要想“破局”，我們首先來看看車載視覺處理典型的流程。這個流程包括四個步驟：

第一步

預處理：包括成幀、顏色調整、白平衡、對比度均衡、圖像扭正等工作，這種圖元級的處理特點是資料量非常大，而且每圖元之間相互獨立，彼此沒有很強的依賴關係，要求高頻寬的並行資料處理能力。

第二步

特徵提取： 是在預處理的基礎上，提取出圖像中的特徵點，特別是關鍵的邊緣角點

第三步

目標識別： 基於特徵資料的輸出，對圖像中的物體進行識別分類——人、車、交通標誌等，這其中就會運用到一些機器學習、神經網路的演算法。

第四步

目標跟蹤：對上述單幀圖像進行記錄，並累計多幀後做出判定，實現穩定的識別和判斷。

通常前三步被認為是底層和中層的處理，運算的並行度較高，第四步由於有前後的邏輯判斷關係，所以屬於循序執行，需要連續處理。可見，車載視覺處理流程中的這些任務，需求各不相同，單一架構的硬體平臺很難滿足所有要求，所以就需要有更加複雜、綜合的異構硬體平臺，以不同的硬體資源去應對不同的計算處理任務，這樣才能勝任。

以恩智浦半導體的S32V車載視覺處理器為例，它對應車載視覺處理的不同步驟配置了不同的針對性的計算單元。

圖2，恩智浦半導體S32V車載視覺處理器框圖（圖片來源：NXP）

對於預處理到特徵提取這種圖元級的工作，S32V提供了一個可程式設計的ISP（圖像信號處理器），對於流處理進行加速；而其可程式設計性也為底層處理提供了靈活性，以應對不同應用中的預處理需求。

對於特徵提取到目標識別這個層次的處理任務，由於要運行AI演算法，特別需要視覺加速，為此S32V引入了兩個專用的APEX-2輔助處理器，實現高速並行的單指令多資料架構的加速計算。

在目標識別到目標跟蹤高層處理，涉及到串列計算，S32V通過運行頻率高達1GHz的多核Arm Cortex-A53處理器（最高配置可達四核）來完成，同時S32V在處理器系統中還集成了一個頻率高達133 MHz的Cortex-M4內核，去實現一些控制功能，以及即時性的工作。

在加上其他諸如3D GPU、硬體安全加密、存儲和外設介面等功能，S32V構成了一個完整的汽車級的安全嵌入式視覺處理平臺。

為了達到這一目的，一個基礎性的工作就是：要對應用中典型的計算模式做出分析和分類，找出有並行加速需求或者潛力工作，將其安排給最適合的硬體去加速。實際的工作中，可以嘗試幾種不同的平行計算加速方式：

• 資料並行：將需要並行處理的資料，交給有平行計算能力的單元去做，如APEX-2這種專用的輔助處理器——專用的肯定比通用的處理器速度快。
• 流水線並行：綜合調度各種計算單元，在同一時間上讓所有單元都處於滿負荷運行狀態，誰也不閑著。
• 任務並行：在同一時間安排進行不同的視覺處理任務。

經過上述全面的優化，軟硬體的緊密配合，車載視覺處理速度和綜合性能才能得到大幅的提升。

圖3，車載視頻處理流程和對應S32V硬體資源（圖片來源：NXP）

車載視覺可以說是嵌入式視覺處理領域難度較高的一個領域，需要各方面資源更緊密的協作、全方位的配合——硬體開發者需要充分理解目標應用的需求，提供最高效的硬體加速架構；軟體發展者也要吃透硬體的特性，合理調配資源，將硬體性能發揮到極致。雖然不容易，但這就是我們通往自動駕駛的必經之路。