導讀

地平線在智東西公開課開設的「地平線自動駕駛技術專場」第3講順利完結，地平線智能駕駛應用軟件部負責人宋巍圍繞《面向規模化量產的智能駕駛系統和軟件開發》這一主題進行了直播講解。

宋巍老師首先結合以往智能駕駛應用軟件開發過程中的痛點和實踐經驗，對智能駕駛應用軟件技術進行了詳細分析。之后，他從軟件視角闡述了“軟硬結合”和“軟硬解耦”的意義與價值，并對智能駕駛軟件開發平臺Horizon TogetherOS Bole進行了深度講解。最后，還展望了智能駕駛應用軟件的開發趨勢。

本次課程內容分為4個部分：

1、智能駕駛應用軟件技術拆解2、軟件視角的“軟硬結合”與“軟硬解耦”3、智能駕駛軟件開發平臺Horizon TogetherOS Bole4、智能駕駛應用軟件開發趨勢展望

01 智能駕駛應用軟件技術拆解

談到軟件，那什么是軟件呢？維基百科上的解釋是：Software is a set of instructions and documentation that tells a computer what to do or how to perform a task。在百度百科上也給了軟件中文解釋，是指一系列按照特定順序組織的計算機數據和指令的集合。對于軟件來說，它就是在執行單元上執行指令和數據，也就是在硬件之上，所有事情都是軟件。

?

整個智能駕駛中，如果從大的領域劃分，可以看到有廣義感知、地圖融合、規劃和控制幾個大領域。如果是根據算法時代來劃分，可以劃分成軟件1.0和軟件2.0。

軟件1.0是傳統的CV，或者是在端到端的深度學習落地之前，基于規則實現的一些面向自動駕駛的軟件和算法。軟件2.0是未來可以通過深度學習和數據驅動，端到端的把整個軟件算法性能迭代起來。但描述它時都是用軟件1.0和軟件2.0，這其實是一個廣義的軟件定義。那對于一個智能駕駛的軟件工程師來說，這時就要承載上面所有領域的研發工作。

一個軟件研發工程師，他的能力要求該如何被定義呢？簡單來看，因為要做嵌入式開發，懂C++就可以。但如果是面向智能駕駛業務開發的工作，那既要有豐富的軟件工程能力；還要有完備的智能駕駛業務知識體系，知道智能駕駛的業務在做什么；又要對硬件有一定理解，因為在嵌入式上開發，資源和在服務器上開發是非常不一樣的；且要有一定的算法實現能力，因為在開發過程中，如果對算法一無所知，整個開發過程會遇到非常多的困難。

?

我們可以把智能駕駛的環境感知做一些拆解。從地平線征程5 SoC芯片的系統框圖上，可以看到有OS部分，即基礎操作系統；再往上有中間件和軟件開發平臺，整個通訊的組件，基礎中間件和應用中間件；再往上就是面向自動駕駛和智能交互的上層應用。

主要看下環境感知部分。我們把它做一些簡單的拆解，如果做環境感知，首先要有一系列的傳感器，有時間同步，有攝像頭、激光雷達、毫米波、超聲波、車身的底盤信號、GPS/IMU等。然后，在一個嵌入式SoC上有很多的硬核，需要對硬核做一些調度，來執行模型。對模型也要做調度，比如模型的前處理、后處理。基于底盤信號，要做自測里程計，用到Odom。有了感知結果和Odom之后，會做感知結構化，進而可以做動/靜態的目標重建、自車的位姿估計。

同時，為了做軟件2.0，整個的數據閉環能夠以數據驅動迭代算法，還要在端上做數據緩存。對于一些特定的數據做數據觸發，把緩存信號再發出去。這個過程都是需要軟件來做的，后面也會逐一的進行拆解：先是傳感器的部分，后面講硬核調度，然后是偏算法的Odom和感知結構化。

首先是傳感器和數據。第一點要看的是時間同步。智能駕駛是一個時間敏感的測量系統。這里有兩個詞，一個是“時間敏感”，一個是“測量”。因為對于智能駕駛來說，如果時間錯了50毫秒、100毫秒，整個計算結果就會有非常大的誤差。同時，環境感知也是測量環境中不同目標距離自車的相對位置、速度、加速度等信息，它們對于時間都有一個非常重要的定義。只有各個SoC都在一個精確的時間體系下，智能駕駛才能夠正常運作。

廣泛使用的時間同步方式，有NTP。NTP通常在毫秒級精度搭建比較簡單，對硬件也沒有要求，但NTP通常會受網絡環境波動的影響，時間調整會比較大。GPS+PPS用到的也比較多，雖然精度比較高，但是當GPS信號丟失時，非常容易出現時間的波動。比如在山里面經常有隧道，有的隧道比較長，過一個隧道有可能GPS信號會丟失，當GPS信號再次獲取時，時間就很容易出現波動。同時，PPS信號也是時間同步非常重要的一個描述發源。如果一個系統里只有GPS和PPS，給多個觸發，PPS分線也會導致一些壓降、信號缺損。PTP/gPTP精度比較高，但對網絡拓撲結構要求也會比較高，各個網絡節點均需要支持時間同步協議，才能夠完成高精度的時間同步。在CAN系統里面，車內ECU間授時使用較多，普通CAN時間同步在ms級，TTCAN也會把時間同步的精度提高到微秒級精度。

如上圖左上角所示，通常一個系統都會是GPS+PPS作為一個獨立的時間源，之后會有一個時間同步的Server，然后作為一個Master，經過一些Switcher，然后給各個Slave節點或者Client做時間授時。

對于時間同步的精度，通常談到的高精度時間同步是一個理論的精度。GPS理論的時間同步精度很高。如果是純軟件實現，接收一個PPS的脈沖信號時，就會受限于軟件的調度能力，精度也會從ns級降低到us級。而在地平線的征程芯片中，為了能夠讓整個系統有更高的時間同步精度，會以軟硬結合的方式實現。對于軟件來說，會解析一個待同步的時間，硬件響應PPS信號，然后在硬件的方案下，直接對整個啟動時間進行更新，達到時間同步方案的理論精度。

同時，由于時間同步有一個PPS，所以時間同步往往也和傳感器觸發相關。很多的傳感器都依賴于PPS信號調整傳感器的一些相位差，來達到時間同步的精度和傳感器的對齊精度。

這個部分也會涉及到一些軟件和硬件的差別。對于軟件實現來說，通常需要在周期比較穩定的MCU中響應PPS信號，然后向各個傳感器發送觸發信號。而這種觸發信號對于MCU來說，達到10us級就已經比較高了。但這個精度仍然無法滿足部分傳感器的觸發要求，因為有的傳感器在曝光觸發時，觸發條件非常高，要求觸發信號在幾us級別內。如果觸發信號沒有達到精度，有可能圖像會出現一些缺損，或者圖像出現一些重曝光，對后續的影響比較大。

在硬件實現方面，地平線征程芯片支持LPWM，可以接收PPS信號。通過硬件轉發觸發信號，也可以設置不同觸發信號的相位差，達到整車傳感器的時間同步對齊作用。

當把所有的SoC和傳感器都做到一個時間同步精度下，下一步就看傳感器。

首先看攝像頭，攝像頭是視覺感知系統的核心。對于算法的同學，可能只關注ISP Tuning和圖像的成像質量，那除此之外還需要關注哪些方面呢？

在做一些高等級的自動駕駛算法時，目前已經和過去的時代不太一樣。在過去傳統的視覺感知過程中，經常是由人工標記2D的bounding box，然后做模型訓練。而對于未來一些3D算法，像特斯拉最近開放了很多的BEV算法，地平線也實現了BEV算法，這些算法中對攝像頭的同步，及其對于時間系統的要求是非常高的。所以軟件工程師和算法工程師，都需要理解攝像頭的曝光原理。

Global Shutter和Rolling Shutter大家可能都會知道，但是Rolling Shutter的曝光原理到底是什么？曝光時間是我們經常提到的ISP曝光控制時間，它和每行傳感器的數據生成時間到底是什么關系？一幀數據生成，比如曝光時間是10毫秒和一幀數據生成的30毫秒，關系到底是什么？傳感器中間的時序到底是如何設置的？這些是后續整個算法設計，視覺和其他傳感器對齊中非常重要的一點。

同時攝像頭的曝光觸發模式，也會是多種多樣的。比如一些標準的觸發模式，像Shutter Sync。剛才談到時間同步時有PPS信號，標準觸發模式一般都是接收到PPS信號，攝像頭立刻曝光觸發。Shutter Sync會有一個確定性的延遲，然后讓數據開始往外傳輸。這兩種模式得到的傳感器時間是不一樣的，它的物理的意義也是不一樣的。

在做多傳感器對齊時，不同的曝光模式對后續的算法和軟件實現差別都會非常大。對于軟件來說，一個攝像頭，除了曝光原理、觸發模式，還有很多其他的信息需要了解，因為對于攝像頭這種高頻的數據，還有很多的異常需要做檢查。像高速接口MIPI很容易受到外部電磁的干擾；MIPI校驗，CRC校驗，每一行數據寬度的校驗；有了傳感器，它會有一些復雜的功能，傳感器內部溫度是否過高，也需要做校驗。傳感器是否會被人調包，算法適配的傳感器是不是裝錯了，裝成了別的型號，這時還有一些傳感器的identity驗證。每幀數據在效應區，如上圖左上角的效應區，Embedded Data里有單幀的2A，FuSa等信息，這些都是軟件開發者需要關注的事情。

對于模組來說，還要做很多管理相關的事情，像模組的版本管理。因為在量產過程中，模組也會有很多的版本，它是AA對焦的？模組的對焦是什么狀態？模組的材質、Lens內參存儲在什么位置？機電模型到底用的是什么？模組材質在不同的溫度下，鏡頭內會不會起霧？Lens的光學特性，Lens會不會出現一些鬼影和擦散光？以上這些都是在自動駕駛開發過程中，軟件工程師需要關注的一些點，通過這些才能夠把整個系統串起來。

同時，多傳感器曝光在曝光原理部分就能很好地體現出來。如上圖右下角所示，一個傳統的機械激光雷達，處于一個360度掃描的狀態。Lidar在0時刻掃描時，攝像頭到底從哪個時刻要觸發曝光，到底是選擇用Standard trigger還是Shutter Sync，這都是整個系統中軟件工程師需要明確討論的內容。

不同的方案對于地平線來說，從征程2、征程3到征程5，它們在逐漸覆蓋越來越復雜的智能駕駛系統。從1V的2M攝像頭、到1V的8M攝像頭，到6V，再到后面10V、11V，最終能夠做一個完整的自動駕駛產品。從上圖可以看出，攝像頭在這里扮演著非常重要的角色，而且攝像頭的復雜程度也會越來越高。對于不同的攝像頭，都要理解不同攝像頭的曝光原理、觸發模式，各種安全校驗，這是非常復雜的。

那如何簡化這個過程呢？地平線有一些傳感器認證的方案，經過認證方案的傳感器，它們都經過前面提到的模式驗證，能夠很好的和地平線軟件、算法、以及芯片做匹配，能夠幫我們的用戶，盡可能把多個 攝像頭、多類型傳感器更好的搭建起來。

對于激光雷達來說，有哪方面的應用呢？高階自動駕駛可能會選擇激光雷達作為感知傳感器，低階自動駕駛會使用激光雷達作為一個真值系統。而現有的2.5D/3D算法方案，都會使用激光雷達真值做自動化的數據標注方案。

激光雷達有很多不同的種類，比如有機械激光雷達，如上圖左下角所示，是一個360度旋轉的激光雷達。激光雷達可以接收時間同步的PPS信號來調整馬達轉速，讓激光雷達在它的坐標系定義的0度上，和0時刻對齊。還有一些固態/半固態激光雷達，比如MEMS，在MEMS內會把它劃分成多區，然后進行掃描。MEMS的好處是多區可以同時掃描，但區塊之間會有一些overlap和重影。旋轉鏡跟機械激光雷達的精度差不多，也是旋轉的形式，從左至右掃描過去。也有一些非重復的、非規則的掃描，而得到的點云對于人來說，直觀理解會比較困難。也有純固態的Flash激光雷達，激光點陣模擬camera曝光方式進行掃描。

對于激光雷達的掃描方式，也都需要時間同步。通過PPS調整激光雷達和不同攝像頭曝光時刻的角度去對齊，達到右下角圖所示的情況。每一個點經過時間對齊、傳感器之間的標定，能夠讓激光雷達的點云與視覺實現一個完全對齊的方案。

激光雷達在部署過程中，也會經常會遇到很多問題。激光雷達目前主要使用UDP協議，UDP協議網絡帶寬的負載會比較高，使用時也需要設置網絡環境/VLAN隔離；Lidar網絡包比較小，一般是一個MTU發一包數據，這就會導致網絡包非常多，網絡中斷響應也會非常多，影響整個系統的響應能力；未來征程芯片也會支持硬件網絡拆包來解決這些的問題。

激光雷達在使用的過程中，也會遇到非常多的問題。雖然激光雷達的精度是比較高的，但使用過程中會碰到各種的鏡面反射，你將會得到一些預期不到的點。比如地面反射到其他的地方，或者通過車窗直接反射到遠處，或更遠的一些相鄰車，到雨、雪、霧、柳絮、臟污等。激光雷達在高速上比較不幸時，有些小蟲子可能會撞上激光雷達，導致傳感器出現一些故障；以及激光雷達對不同的物體，反射值也是不一樣的。通常我們也會設置不同反射值的映射，對于不了解激光雷達的開發者來說，有時拿到一些反射值可能會覺得比較奇怪，為什么有的反射值這么高，有的反射值這么低。

對于非純固態激光雷達，供電穩定性也會是一個很大的問題，在實車環境的供電系統不是特別好。如果做不到穩定的激光雷達供電，有可能也會導致光頭或者機械元件出現異常，從而導致點云出現異常。同時，也需要關注多傳感器對齊，這些對于軟件開發來者來說，都是非常重要的工作。

激光雷達在高頻的UDP數據包情況下，協議解析如何做到非常低的延遲，盡可能地降低CPU負載，都是軟件開發者需要關注的事情。同時，傳感器和算法之間達成一致，也是在整個自動駕駛系統軟件開發過程中，需要上下游不停拉通、對齊的事情。

對于激光雷達，地平線也有很多合作伙伴，都能夠比較好的支持地平線的感知系統構建及真值數據構建。

自動駕駛系統里還有很多其他的傳感器。

首先，車身底盤信號從CAN或CANFD，能夠拿到很多車身上其他傳感器的數據。對于CAN和CANFD來說，也有很多接入方式，比如征程5代芯片上有CAN收發器，直接使用SocketCAN，來接收CAN數據。通常車上也會引入一個MCU作為網關，MCU和SoC之間，通過SPI進行CAN協議轉發。這時就會出現數據鏈路長的問題，經過網關，SPI、OS到HAL、USER才能進行解析。

在協議中的時間敏感系統，不同的SoC之間需要保證時間同步，以及數據的時刻到底是什么，所以協議中需要對時間有非常明確的定義。然后對于CAN大小端數據的校驗，Rolling Counter和CRC，各種信號的校驗數據有效位、閾值、數據頻率、數據更新。對于軟件開發者來說，信號的校驗是功能安全處理中非常重要的一點。

毫米波雷達和4D Image Radar。它們的數據鏈路比較多，有可能會使用CANFD，有的4D Image Radar用以太網，也有4D Image Radar用MIPI，來降低數據傳輸延遲。數據類型也會比較多，目前大部分Radar都是目標級的，即通常輸出了跟蹤之后的目標數據。也有一些Radar能夠輸出一些原始的雷達回波信號，從廠商獲取有一定難度。4D Image Radar目前合作廠商都會得到一些點云數據，信息量與比較傳統的Radar相比，有明顯的提高。時間同步方面，對于不同傳感器，可以通過CAN或以太網進行時間同步。

對于GPS和IMU，GPS的時間同步是授時和定位系統必備的。不同的GPS精度差異也比較大；不同型號的RTK，定位精度在5厘米、10厘米、20厘米級別；不同的IMU精度差異也比較大，有溫飄。數據接口通常為UART、SPI和I2C，這些接口都是相對比較低速的，特別UART在查詢時，整個數據鏈路都會比較慢，穩定性相對較差；而且對于IMU來說，通常不具備授時能力，IMU基于內部時鐘進行數據處理；對于一個數據敏感系統不穩定的數據鏈路來說，需要使用IMU內部時間進行數據的時間校驗和優化。

超聲波雷達通常會用于一些低速的避障場景，與感知進行融合，但超聲波都不具備時間同步的能力，對于低速場景來說還是可以接受的。

前面更多的是講到傳感器自身以及傳感器的時間同步。多傳感器以及多類型的傳感器，就需要做好傳感器標定。

單傳感器標定方面有產線標定，通常在一輛汽車下線時，在產線中會有一個產線標定房，如上圖左上角所示，這張圖片是地平線的一個早期的標定間，它更多是校驗自己的算法。售后標定是車可能會出現一些問題，進行一些換件，在4S店進行的標定；對于在線標定，車輛可能會有一些胎壓變化，或經過長時間的熱脹冷縮帶來的傳感器的姿態發生變化。車輛的負載變化，都需要對傳感器進行在線標定以及動態標定。

多傳感器標定對系統的時間精度要求非常高，如果所有的傳感器不在一個時間系統下，很難獲得比較精確的時間；同時，攝像頭、激光雷達的掃描方式不同，需要理解多傳感器數據的生產原理，保障多傳感器的時間是對齊的；也要理解應該如何做傳感器數據的時間補償，如何讓多傳感器達到對齊的效果；最后，還需要多傳感器的聯合標定算法。

在這個過程中，一方面是標定算法的精度，另一方面，工程化是非常重要的，特別是在產線標定過程中，如果工程化出現了問題，產線會被block，非常影響效率。

前面提到的軟件和一些基礎性算法都準備好之后，可以開始準備數據采集或標注，進一步打造自動駕駛系統。

在安裝傳感器方面，首先需要整車裝備。在傳感器的布置方案中，檢查安裝不同傳感器是否足夠的固定，會不會天氣一熱膠就軟了；安裝的角度和系統的需求是否一致的，是否都能夠達到我們的期望。還有在安裝過程中，視野是否有遮擋，比如此前經常要做一些數模方案，看傳感器的感知范圍內，是否會被車身所遮擋。整個安裝方案是否防水密閉，像最近北京下暴雨，如果有一輛車在這種情況下開出去，傳感器是否會進水。

在整車的供電和散熱方面，在供電不穩定的情況下，有些傳感器不能夠正常工作。電磁輻射，比如整車傳感器比較多，線材也比較多，是否使用一些屏蔽線，是否影響了接收信號的穩定性。

在整車的采集設備部署過程中，整車的時間同步源精度是否足夠。當時間發生跳變時，時間同步方案是否能夠保障整個系統仍然能夠穩定的運行。傳感器是否都正常的部署。對于傳感器接入了硬件，像地平線Matrix自動駕駛計算平臺，包括工控機也要錄制所有采集到的數據。

數采軟件，需要校驗傳感器同步以及數據采集幀率是否滿足算法的要求，即數據是否滿幀率。對于視覺系統來說，還要看codec編解碼，究竟是選擇264、265還JEPG。碼率的配置、圖像的質量是否滿足算法的要求。不同的碼率配置、不同的數據格式，對整個存儲帶寬的影響都特別大。未來可能經常會看到一個11V、3L、5R的智能駕駛系統，它一秒的數據量可能都會達到GB級，存儲能力、磁盤寫入能力是否足夠，如果不足夠，應該如何改造。甚至軟件開發者要關注IO系統應該如何做優化，如通過數據緩存優化IO效率。

對于數據質量，即圖像的質量、激光雷達的質量、傳感器的時鐘，標定是否對齊。如果采集回來的數據達不到這些質量，需要判定這些數據對后續算法到底是否可用。同時，對于數據來說，有一個非常重要的點，要符合法律法規，要使用合規的數據庫，采集時也要做數據脫敏，不要有任何法律上的問題。以及在數據回傳之后，也要有一些回傳入庫和入庫質檢的步驟。數據入庫之后，批量數據才能夠進行標注。對于標注系統，如果能夠全自動化的標注，效率肯定是最高的，另外人工校驗也是非常重要的。

那有了數據文件之后，該怎么把它用起來呢？這時還需要很多的數據工具，需要開發各種數據訪存SDK，像視覺數據、雷達數據，它們的文件size都是非常大的，在數據的訪問、查詢、跳轉、反序列化過程中，或解碼過程中，效率是否足夠高。對于數據的統計能力，數據幀率、延遲、關鍵信號的穩定性，底盤數據是否丟失，數據轉碼效率是否會很高，是否能夠很明確的給這些數據一些label，讓下游真正的把數據用起來。

對于數據調試和profile工具，當拿到一個數據時，可以構成各種信號的topic，是否能夠很好的關注這些topic的波形圖。對于數據來說，是否能夠分析實際運行過程中的WCET，進而分析執行時間。由于數據都是在后臺運行，所以也需要展示工具，展示圖像、感知結果、3D信息、點云。在車內也需要有HMI，如上圖右半部分所示，是點云數據和HMI的展示狀態。

地平線艾迪平臺，能夠支撐完整的數據閉環鏈路。在智能駕駛終端上部署整個地平線的智能駕駛軟件，然后通過數據觸發、關鍵場景的問題挖掘，能夠把這些經過脫敏之后的原始數據加密傳輸。之后在云端能夠進行端側的問題挖掘，半自動或者全自動的標注工具進行數據標注，自動化的模型訓練，長尾場景的管理，自定義迭代工作流，軟件自動集成，自動化回歸測試，OTA升級等。最后，再回歸到車上，這也是一個軟件2.0非常重要的概念。

接下來講解硬核調度和感知算法部分的內容。

硬核調度如上圖所示，今天簡單講解兩個部分，首先是Codec。

征程3和征程5提供4K@60fps Codec + 4K@60fps JPEG編碼能力。對于Codec，如果只是使用它，不會有什么問題，我們的軟件工程師需要看Codec編碼到底是做什么用的。對于數據采集來說，Codec要盡可能的調高圖像效果。

Codec碼率應該如何設置，QP值該如何調整。如果是JPEG，quality配置究竟調成什么質量，才能夠滿足后續算法的迭代過程。除了給算法進行訓練，Codec還有一些DVR數據回傳的需求，當帶寬不足時，又要權衡究竟設置什么樣的碼率和圖像質量，能夠滿足數據傳輸的size要求。

通常Codec在單SoC只有一個加速硬核。但單SoC有6V、10V、11V的系統，雖然Codec能力很強，但Codec也需要一個比較好的調度器。如上圖下半部分所示，是一個簡單的調度器，它主要是在硬件響應過程中，與硬件交互，讓中斷更加及時響應到用戶層。

更重要的還有模型前處理、后處理以及BPU調度。通常算法開發者更多的是在云端工作，拿到一些標注好的數據，訓練模型，并通過地平線的編譯器，轉換成地平線芯片可以運行的模型文件在BPU上去運行。

對于軟件開發者來說，要調度一個模型，和調度CPU不會有本質的差別，那差別是什么呢？是要理解算法的一些數據排布。要理解地平線芯片，在實現計算時這些數據排布到底是如何實現高效率。對于深度學習來說，數據排布通常有vector、matrix和tensor。如果對于軟件開發者來說，通常習慣將數據轉換為Native Layout（NHWC）。但對于硬件來說，硬件在輸出時，數據排布往往也不Native，轉換Native Layout往往不是最高效的。這時就要做權衡。Native Layout用戶的編程邏輯會比較簡單。但不同芯片的原生Layout，性能往往是最優的，所以這對軟件開發者的要求也會更高，因為數據不會經常是連續的一個數據塊會存在一個區域，另外一個數據塊會存在另外一個區域；開發者需要理解硬件原生數據存儲格式。

開發者也需要理解定點化的概念。在模型的前處理和后處理過程中，算法往往會做定點化，定點化會讓模型的效率運行的更高。對于軟件工程師來說，如果不理解這個模型本身數據輸出的含義，通常在實現的過程會出現一些代碼效率上的問題，即把定點直接轉成浮點。在模型計算過程中使用定點計算，而結果解析使用浮點計算，造成了性能上的損失。

這就要求軟件工程師理解一些基礎算法處理的邏輯。像Bounding box regression究竟是怎么做的，它的原理是什么？NMS是怎么做的？軟件實現為什么可以把整個計算過程實現成定點而不是浮點？即便是不同模型，也需要理解攝像頭的一些 projection model，distortion model。因為未來更多的是2.5D和3D的算法，模型inference出來后，可能會是不同坐標系下的數據，需要進行坐標系轉換。

對于軟件工程師來說，如果不理解projection model和distortion model，這些數據很難轉換成駕駛系統里面真正上下游需要的一些數據，包括一些Heatmap、Max Pooling如何實現？代碼的效率如何才是最高的？一些關鍵點回歸的原理是什么？這些都是對軟件工程師提的更高要求。

BPU調度，和SoC中CPU是比較類似的。CPU會有非常多復雜的任務調度。地平線征程芯片擁有雙核高性能BPU。如果一個系統中有11路攝像頭，通常會面臨著50~100個模型的調度。這時整個模型管理、調度編排非常重要；哪些模型是重要的？到底能不能搶占？通過軟件方案做一些模型的搶占，還是硬件方案做模型搶占？模型搶占是否會對DDR帶寬帶來一些沖擊？整個體系架構從DDR到SRAM，再到BPU的執行，如何才是最優的？這些都是軟件工程師需要關注的一些點。在地平線Bole開發平臺發布EasyDNN，它可以幫用戶更好的面向復雜的模型調度、調度編排和搶占，解決相關調度上的問題。

在傳統的感知方案中都是一些2D的方案，而現代的一些算法方案，不管是3D方案，還是未來的BEV的方案，都需要在模型后期，再增添一些傳統的CV算法。在感知模型基礎上，進行感知結構化處理。

首先，要有一個自車的位姿估計。位姿估計可以使用車輛底盤積分，對于簡單的行車模式下，Speed+yaw rate就足夠了。而對于一些低速場景，還需要引入輪脈沖輪速、方向轉角等方法。對于每輛車的yaw rate，即橫擺角速度，也會存在一些bias。當車輛處于靜態時，就會有一個靜態偏置，動態時也可能會有一個動態偏置。把 bias估計好才能夠得到一個更好的自車里程計。

同時，也可以使用IMU和GPS來提高里程計的精度。上圖右上角是一個行車的軌跡圖，它有兩種顏色，一個藍色和一個橙色，通過Odom的提高，展示出了兩種不同方法的實現結果。

使用IMU，還能夠進行3D姿態估計，特別是在跨層輔助泊車的場景。在這個過程中，也會遇到很多工程上的問題，對于CAN數據、底盤數據到SoC系統里，它的鏈路是比較長的，如何更好的提高系統的響應，保障Odom延遲在一個可接受的范圍內，這也是軟件工程師需要解決的一些問題。

在動態目標建模方面，要處理的是一些多目標跟蹤、運動學的建模，（CV、CA、CTRA等），以及不同的濾波器（EKF、UKF、PF等）。在處理過程中，也需要圖像空間與3D空間進行交叉驗證。同時，動態目標建模也是一個時間敏感的系統。對于場景的不同，會有一些不確定性。因為傳統CV和多目標跟蹤，它的耗時是隨著目標數量而增長的。而對于深度學習，耗時的確定性是比較高的。對于軟件工程師來說，一方面需要用數據工具，profiling整個系統，能夠動態的調整數據流，讓整個系統盡可能壓低負載和延遲。

同時，也要去考慮對于確定性和不確定性，后面應該如何解決它。對于軟件2.0的系統，或端到端的系統來說，需要把更多的傳統CV部分，轉移到深度學習模型或BPU模型，能夠被硬件確定性執行的部分，來提高整個系統的確定性、穩定性和延遲優化。

講到調度，Bole Dataflow調度框架，能夠幫助開發者快速構建自動駕駛應用數據流圖。整個系統里會有各種的傳感器、硬核調度、傳統CV的處理模塊。各個的模塊都會有自己的執行單元，整個自動駕駛應用也被分解成很多的程序。

Bole Dataflow調度框架，也提供ROS-like的編程接口。為什么是ROS-like？因為對于很多自動駕駛算法開發者，特別是學校里的一些同學，他們在學校上學時都是用ROS，所以ROS-like能夠讓這些算法開發者更容易的在嵌入式上進行開發。程序整個建立在Bole Dataflow的節點之上，節點可以被應用集成、被配置。同時，也會在細粒度的模塊化節點內，進行深入細化的DAG節點拆分，確保調度模塊的原子性，提升實時性。像上圖右下角，就是DAG數據流圖描述的應用。

在SoC上，也有很多的硬核，不同的硬核都有不同的計算能力和性能。全局異構調度管理，傳感器、硬件加速引擎、DSP、BPU、CPU、通信鏈路等參與統一的數據流調度管理。只有把所有的調度管理統一起來，才能使各個資源有條不紊的運行，充分利用硬件引擎。這樣基于硬件中斷觸發的零拷貝數據流轉，不經過CPU，直接觸發硬件加速引擎處理數據，來增強實時性。而時間觸發基于WCET分析的確定性時序執行，確保關鍵程序的實時性。

在多個模塊、多個進程，甚至多個SoC的過程中，除了調度，通訊也是非常重要的。Bole Communication通訊框架，支持集成多種消息中間件DDS、ZeroMQ、AutoSAR ARA：：COM、PCIe等。關于PCIe，由于未來還有跨SoC、多SoC這種非常大量的數據傳輸。面向未來的架構，在多SoC時，數據傳輸通常是在幾十兆每幀級的feature map，而傳統的以太網肯定不能很好的承載。PCIe在未來會是一個非常重要的數據通訊鏈路。

Bole也會提供Zero-Copy共享內存通信機制，同時也會內置一些自適應通信策略，來保障節點部署是一個最佳通訊的模式。Bole提供多平臺的支持。開發者除了在地平線的芯片上開發，還會在不同設備上進行開發。很多的算法開發者在做算法開發時，不管是調度框架還是通訊框架，在個人的電腦集群上都需要提供編譯、調試能力。同時，對于通訊來說，算法在集群上做模型訓練，也可以通過Python接口，讓算法簡單的替換嵌入式模塊的一個程序，這樣也能夠快速的進行算法原型驗證。

調度和通訊是大的框架級別，再深入是每一個Node。如果一個Node的運行時間過長，什么樣的調度框架和通訊框架都很難進一步的提升性能，所以軟件性能優化也是整個軟件團隊非常重要的一部分，這一塊也需要非常深入的了解才能夠完成。

做軟件的性能優化，需要理解芯片的一些架構設計。首先，需要理解整個Memory Hierarchy，即整個內存的層級系統，也需要理解總線帶寬、DDR帶寬、DDR控制器到底是如何運作的，還有DDR工作模式。因為現在大算力的SoC，DDR通常是雙通道和多通道，DDR到底是運行在并發模式，還是在其他的模式下運行，DDR的QoS到底給哪個硬核才能讓它的響應最高，這些都需要考慮到。

對于CPU來說，CPU L2 Cache，L1 Cache工作模式是什么，各級Cache Size對系統性能影響是什么？系統中什么樣的數據需要自動去刷新，什么樣的數據不需要？對于BPU來說，一個模型有多級的SRAM，它的工作機制、模型調度與IO之間的overhead到底是什么樣子的？

對于DSP來說，又會出現一個TCM，TCM和DDR之間使用DMA。對于TCM的使用，到底是使用什么樣子代碼固化在TCM上，什么樣的代碼固化到DSP的cache上。

以上這些對整個的系統，整個Memory帶寬、軟件性能有非常大的影響。

同時，要理解整個芯片設計的Interrupt Hierarchy。當一個系統里有十幾個攝像頭、幾個激光雷達，整個系統的中斷是非常多的。我們的軟件究竟如何配置中斷，中斷和CPU之間中斷響應是如何綁定的？

也需要在純計算優化的方式上，深入理解向量化編程。向量化編程一般都稱它為SIMD，在ARM上有NEON，在PC上有SSE以及DSP這種SIMD指令，這都是非常重要的軟件優化手段。

內存訪問需要靜態化。因為現在大家開發都在 OS以上，不管是Linux也好，QNX也好，對內存的靜態化非常重要。特別是在QNX系統上開發，QNX對內存每次申請釋放都會有很多的安全性校驗，如果是太多的碎面化內存，整個系統的overhead會非常重。

CPU計算的定點化。定點運算肯定比浮點運算要快，什么樣的算法能夠定點化，這也是軟件工程師和算法工程師需要去深入溝通的。系統里到底哪一部分算法是非常重的overhead，能否把它定點化實現。

對于整個復雜的自動駕駛系統，像11V、3L的系統，它的線程/進程非常多。線程和進程的優先級到底是什么樣子？在一個實時系統里面，不同的功能模塊的實時優先級配置，線程是否能夠合并、綁定。

在系統整個的通訊優化方面，因為系統里面會有各種各樣的信號，可能會有非常高的高頻信號，也有一些低頻信號，哪些信號是可以合并的，哪些高頻信號可以做一些打包。例如可以把一些高頻信號，比如每個信號都是100赫茲，有幾十個信號能否把它們全部打包成一個100赫茲，減少通訊的開銷。

更高要求是一些算法復雜度的優化。算法復雜度的優化，通常有可能把一個算法耗時降低一個數量級。

最痛苦的有可能就是純代碼級的優化。因為需要在代碼中一個點一個點去check，發現到底有哪些點可以再進一步的優化，能夠把系統的性能進一步的提升。特別是量產的最后階段，有可能花很長的時間都是零點幾個點的CPU降低，但這也是非常值得的。

綜上所述，在地平線各代的征程芯片上，上面講到的各種軟件相關的開發事項，遇到的各種問題，以及問題的解決，它們在地平線的量產落地的項目中都有體現。

過去地平線已經完成了從0到1的突破，現在也準備和行業伙伴一起實現從1到N的開放共贏。大規模量產是驗證智能駕駛產品技術領先性的首要標準，剛剛講到了很多在量產過程中遇到的問題和解決這些問題的經驗。而把這些問題和經驗分享出來，也是希望能夠幫助大家在后續量產的過程中更好地應對這些問題。

02 軟件視角的“軟硬結合”與“軟硬解耦”

新一代汽車智能芯片領導者，必須也是世界級 AI 算法公司。地平線是在2015年成立，而我是在2016年加入地平線，當時還是處于芯片開發的初期階段。我個人也非常幸運能夠在早期加入地平線，經歷芯片軟硬結合，協同設計的整個過程。

對于一個軟件開發者來說，當你從市面上拿到一款芯片，芯片可能有各個不同的硬件設置，它的DDR、各個硬核的IP，深度學習芯片的一些算子，到底是不是工程上需要的，這些都無法改變。

地平線在每一代芯片的設計、BPU設計、整個SoC的設計過程中，都和我們的軟件開發者、算法開發者進行了非常深入的討論，以軟硬結合的方式，讓芯片真的是為后續的應用場景、為軟件去服務的，即我們的芯片設計，真正的從實際場景出發，從軟件中來，到軟件中去。

地平線的芯片DDR帶寬到底需要多少，BPU算力需要多少，CPU、SP、Codec等，是否真的是一個極具性價比，極具能耗比的設計？是不是能夠把AI芯片的能力在自動駕駛的系統里充分展示出來，這個都是在開發過程中軟硬結合的體現。

芯片設計出來后，面向芯片，需要在軟件層級上，從OS到基礎中間件，再到應用中間件，打造不同的模塊單元，讓不同的開發者使用不同的、已經封裝的、比較成熟的模塊。像剛才介紹在自動駕駛系統設計中遇到的各種各樣問題，這些模塊都能很好地解決，并提供給開發者去使用，讓開發者能夠自定義的完成他們的應用開發。

因而，從芯片到上層的操作系統，基礎中間件、應用中間件的軟硬結合，再向上提供給我們的應用開發者，去開發各種各樣的智能汽車應用，達到軟硬解耦。

03 智能駕駛軟件開發平臺Horizon TogetherOS Bole

在征程5芯片發布時，也發布了TogetherOS，Bole是TogetherOS中的應用中間件部分，即軟件開發平臺。Horizon TogetherOS Bole是面向高等級自動駕駛的軟件開發平臺及中間件。

首先，介紹下高等級自動駕駛系統面臨的難點與挑戰。第一，自動駕駛車載軟件的架構復雜度是陡增的。在過去的兩三年，L2級別單目的視覺系統比較主流。而從2021年開始，一輛車裝載多個攝像頭，完成NOA（領航輔助駕駛）等功能，已經逐漸開始是一個標準化的過程。未來到城區自動駕駛，傳感器會越來越多，整個自動駕駛的車載軟件架構設計，復雜度也是陡增的。在快速迭代過程中，如何能夠提高開發效率，實現快速的復制，加速量產開發的進程，都是會變得非常重要。

第二，自動駕駛平臺軟件關鍵技術還沒有標準化。傳統車載應用軟件的開發范式，很難做到以數據為中心的數據閉環。整個數據閉環過程中，傳統的軟件開發方式會顯得比較困難。AutoSAR AP、ROS等高等級自動駕駛場景還處在初期摸索階段。在落地過程中，各有千秋，目前行業中還沒有形成統一的面向高等級自動駕駛的軟件開發平臺及中間件。

第三，高等級自動駕駛也需要更高的安全性保障。關于功能安全部分，此前也有同事有過相關的分享。

最后，高等級自動駕駛也需要高算力的支撐。L3+自動駕駛算法復雜度及功能安全的冗余設計，隨著自動駕駛等級的提高，其所需算力呈指數提升，需要BPU/DSP等異構執行單元對算法進行加速。同時，當前單芯片的很難滿足算力要求，多個異構芯片混合，軟件與計算平臺協同也變得越來越困難，自動駕駛計算平臺的有效算力很難得到充分發揮。以上這些都是高級自動駕駛系統面臨的一些難點和挑戰。

總結一下，需要安全可靠、極致效能，簡單易用，而且也要面向下一代智能駕駛，是一個能夠很好達成軟件開發的系統，而且也需要是一個開放且兼容的系統。

Bole，希望能夠解決自動駕駛量產軟件開發中的難題，面向高等級自動駕駛，完成上圖右半部分所示的數據閉環、軟件2.0的開發方式，能夠做到數據的錄制、實際的開發，然后部署。我們將Design、Develop、Deploy、Build、Drive，Measure，Record，Store等等，把它整個閉環起來，和艾迪平臺一起，配合著完成數據閉環。

Bole會產出一套面向高等級自動駕駛的開發范式；BoleStudio IDE，能夠把不同的模塊、不同的node，以DAG的形式展現出來；BoleViewer，能夠完成數據可視化；還有一些數據工具，像Recorder、Repaly、SensorCenter；包括車身的一些通訊VehicleIO；也有之前談到的Bole Dataflow調度框架，通訊框架Communication，BPU調度框架EasyDNN等，它們都是為了能夠快速的開發和集成。同時，HobotCV也是面向征程芯片不同的硬核計算單元，提供高效的接口抽象。

數據閉環，也是以數據驅動開發，助力自動駕駛應用快速落地。在實車的環境下，要實時抓取傳感器的數據，在實車的應用軟件下，能夠把傳感數據與日志進行錄制，包括傳感器的標定、常規數據采集。數據回來之后，剛才也提到數據工具也會非常重要。在云端要有數據回灌的能力，特別是在云端和艾迪的配合，對于批量的數據、批量的設備來說，艾迪平臺和Bole一起協同，能夠把數據的開發、回灌、回歸、數據可視化總體整合起來。同時，也提供一個BoleStudio的AI應用開發集成環境，能夠做到持續的改進與開發。

04 智能駕駛應用軟件開發趨勢展望

對于自動駕駛的應用開發，未來會是什么形態呢？

在Bole之上，剛才也談到會有各種各樣不同的模塊。在Dataflow框架中也會把各種各樣的模塊，抽象成不同的一些module，或者node，可能會執行在不同的計算單元上。有多模傳感器、攝像頭、激光雷達、毫米波雷達、超聲波雷達等。感知要在一個大的感知模塊下，要執行BPU、傳感器，執行傳統的CV算法。然后在定位地圖上，還要與做地圖的一些localization或者自身的定位信息，組成整個動靜態環境模型。在融合與規劃部分，得到自車的軌跡規劃。之后到整車控制，所有的數據可視化，包括整個的車身通訊，各種各樣的信號，這些都會是自動駕駛開發系統中需要實現的一些模塊。

如果要去做一個自動駕駛系統，從零開始實現這些內容，是非常困難的。如果能夠有一個很好的baseline，地平線也是很希望把這樣的一個baseline開放出來，能夠把我們在量產過程中積累的軟件開發經驗，以這種module，或以node的形式，和各個合作伙伴一起把它作為一種開發的基礎模板，加速合作伙伴的量產過程，這樣會是一個更快的開發方式。

基于整個開發框架，會有各種各樣不同的模塊。上圖所示藍色的部分是地平線所做的開放框架，把在軟件框架以及量產工程實現過程中，遇到的一些經驗和問題抽象出來，作為一些開放的框架。同時，用戶也可以自定義的完成各種不同模塊，包括一些新傳感器的接入，一些新的傳統CV算法的實現，以及不同模型的前處理、后處理，都可以在我們的調度框架下完成。

同時，在整套框架的定義下，也能夠把這些感知模塊、融合模塊、規劃模塊、控制模塊的接口很好的定義抽象出來，幫助開發者快速實現全棧的自動駕駛開發過程。一方面，能夠在一個相對比較成熟的軟件baseline下，完成自動駕駛量產的開發；另一方面，把我們實現規模化量產過程中的一些經驗也分享出來，通過協同開發，大幅提升開發效率，從而達到一個開放共贏的狀態，加速智能駕駛應用落地。