針對ADAS應(yīng)用優(yōu)化編譯程序性能分析

汽車產(chǎn)業(yè)的所有主要原始設(shè)備制造商(OEM)和軟件供貨商都在致力于研發(fā)先進(jìn)駕駛輔助系統(tǒng)(ADAS)。但如果仔細(xì)了解，你就會對ADAS應(yīng)用對編譯程序和工具集提出的要求產(chǎn)生諸多疑問。傳統(tǒng)的汽車應(yīng)用和ADAS之間有所區(qū)別，為了更好地滿足ADAS需求，需要對目前的編譯程序進(jìn)行一些升級改造。

ADAS應(yīng)用是一種挑戰(zhàn)為了更好地支持自動駕駛任務(wù)，汽車需要更清楚地了解它們的周圍環(huán)境。有幾種新的傳感器如雷達(dá)、激光雷達(dá)、攝影機(jī)等，可用來以高分辨率檢測路標(biāo)、其他車輛、障礙物和其他相關(guān)的環(huán)境數(shù)據(jù)(圖1)。過去，汽車系統(tǒng)通常只是實時處理來自一些特定執(zhí)行器(轉(zhuǎn)向角、踏板位置、各種引擎?zhèn)鞲衅鞯?的單獨測量資料。

圖1 基于傳感器的不同ADAS應(yīng)用的監(jiān)測區(qū)域。

然而，與一般的物理測量一樣，ADAS應(yīng)用采集的環(huán)境數(shù)據(jù)存在噪聲(圖2)和測量誤差。因此，這些數(shù)據(jù)在可以用于最終用途，即自動幫助司機(jī)減輕決策負(fù)擔(dān)之前，需要用硬件和軟件進(jìn)行電子后處理。然而，這種后處理并不總是處理像以前那樣的單獨測量數(shù)據(jù)，很多時候會將來自不同來源的數(shù)據(jù)合并(傳感器融合)，從而降低誤差敏感性。
、

圖2 環(huán)境傳感器產(chǎn)生的有噪聲訊號及濾波后的結(jié)果。

為了使ADAS能夠根據(jù)司機(jī)行為自動做出決策，ADAS必須能夠?qū)崟r處理大量數(shù)據(jù)。另外，這些數(shù)據(jù)很復(fù)雜，以前的做法是只處理整數(shù)或定點數(shù)類型、速率為1~5kbps的單獨傳感器數(shù)據(jù)。但今天提供的數(shù)據(jù)經(jīng)常是浮點類型(浮點/雙精度)，而且速率很高。舉例來說，攝影機(jī)影像的速率約為340kbps，雷達(dá)數(shù)據(jù)約為1.5Mbps。

很顯然，與傳統(tǒng)的汽車應(yīng)用相比，ADAS應(yīng)用要求更強(qiáng)大的處理能力，但現(xiàn)在很難預(yù)測哪種高性能的硬件架構(gòu)更適合這些類型的應(yīng)用。由于必須以可重復(fù)使用和高成本效益的方式實現(xiàn)ADAS應(yīng)用，因此很明顯對所有架構(gòu)來說都要求得到編譯程序的支持。在這種要求下，必須使用抽象、可移植的設(shè)計方法(如C++11/14)、基于模型的設(shè)計方法和包括平行程序設(shè)計(如OpenCL、Pthreads)在內(nèi)的其他技術(shù)。此外還要求高度優(yōu)化的、經(jīng)認(rèn)證的函式庫來高效、安全地實現(xiàn)標(biāo)準(zhǔn)運算，并盡可能地提高硬件的獨立性。因為ADAS應(yīng)用會干預(yù)駕駛過程，所以這些應(yīng)用和執(zhí)行它們的硬件也必須符合相關(guān)的安全標(biāo)準(zhǔn)(ASIL-B或更高階的ISO 26262)。

尋找一種合適的硬件架構(gòu)

對于開發(fā)ADAS應(yīng)用的公司來說，直到現(xiàn)在也沒有哪種硬件架構(gòu)成為主流，這使它們面臨風(fēng)險。一般來說，一些主要的硬件加速器——包括NVIDIA GPU的衍生產(chǎn)品(Drive PX)——可以為ADAS應(yīng)用的資料平行部分提供每秒萬億次浮點運算(Teraflops)等級的足夠運算能力。然而，除了缺少足夠的安全特性外，這些組件就功耗和購買價格而言成本相當(dāng)高。另一方面，適合直到ASIL-D(包括AURIX或RH850在內(nèi))的安全關(guān)鍵型應(yīng)用的典型架構(gòu)，還沒有利用到硬件方面的機(jī)會來實現(xiàn)更高的數(shù)據(jù)速率，因為這些架構(gòu)很難通過ASIL-D的認(rèn)證。

因此，ADAS系統(tǒng)的OEM或大型供貨商存在選擇架構(gòu)的風(fēng)險，可能會由于架構(gòu)太大、太昂貴或不能滿足安全要求而賣不出去。另一方面，即使選擇了一種完全支持安全關(guān)鍵型應(yīng)用的架構(gòu)，也存在這種架構(gòu)太小無法滿足更嚴(yán)格的運算要求的風(fēng)險。在開發(fā)過程中，可能會出現(xiàn)預(yù)期應(yīng)用由于效率原因而無法實現(xiàn)的問題。

因此，ADAS項目的要求非常復(fù)雜。一方面，開發(fā)人員必須創(chuàng)建非常高效的、特定目標(biāo)的程序代碼，滿足所有安全目標(biāo)，并盡量減少上述風(fēng)險。另一方面，有必要采用可移植的高級設(shè)計方法進(jìn)行高成本效益的應(yīng)用開發(fā)。這些高級設(shè)計要求，使得原本為傳統(tǒng)嵌入式應(yīng)用設(shè)計的嵌入式編譯程序必須作出修改。

程序代碼結(jié)構(gòu)的效率

一種必要的新的編譯程序特性是需要支持ADAS應(yīng)用的典型程序代碼結(jié)構(gòu)，以便為這類應(yīng)用創(chuàng)建高效的程序代碼。ADAS應(yīng)用中使用的數(shù)據(jù)結(jié)構(gòu)及其經(jīng)歷的運算與經(jīng)典應(yīng)用中的有根本區(qū)別，用于傳感器融合和分析傳感器數(shù)據(jù)的程序代碼通常是用BASELABS等模型化工具生成的。舉例來說，ADAS程序代碼中與速度有關(guān)的部分通常涉及浮點和雙精度類型的數(shù)組(向量和矩陣)，這些數(shù)據(jù)會經(jīng)歷諸如矩陣乘法、倒數(shù)、奇異值分解(SVD)等線性代數(shù)運算。系統(tǒng)透過這些運算將傳感器數(shù)據(jù)數(shù)組組合起來運算環(huán)境的抽象表述，然后用作決策的基礎(chǔ)(例如檢查影像中的對象，或跟蹤和分配物體的空間位置)。

高度優(yōu)化的函式庫

這種數(shù)組和浮點數(shù)的大量使用，意味著需要對編譯程序進(jìn)行全新的優(yōu)化，才能提供有效的結(jié)果。舉例來說，最常用的線性代數(shù)函數(shù)一般是由針對特定目標(biāo)架構(gòu)高度優(yōu)化的函式庫所提供。因此，函式庫中沒有包含的所有運算必須用編譯程序很好地優(yōu)化，才能避免這些運算成為瓶頸。

ADAS應(yīng)用中許多性能關(guān)鍵型運算是基于一套標(biāo)準(zhǔn)的線性代數(shù)運算實現(xiàn)的。如果這些標(biāo)準(zhǔn)運算使用標(biāo)準(zhǔn)界面，則可以極大地減少將這些ADAS應(yīng)用移植到不同目標(biāo)架構(gòu)所造成的開銷。大多數(shù)相關(guān)的硬件平臺都提供支持標(biāo)準(zhǔn)接口的函式庫，以及針對特定目標(biāo)架構(gòu)高度優(yōu)化的函式庫，包括Tasking為嵌入式應(yīng)用開發(fā)的LAPACK、NVIDIA的cuBLAS和英特爾(Intel)的Integrated Performance Primitives。

一般來說，這些函式庫的速度要比開放原始碼產(chǎn)品或公司內(nèi)部實現(xiàn)快一個數(shù)量級。因此基于標(biāo)準(zhǔn)接口的應(yīng)用可以很快取得很好的效率，即使在新的目標(biāo)平臺上也可以，而且無需程序設(shè)計師自己優(yōu)化和測試特定目標(biāo)函式庫中的性能關(guān)鍵運算。然而請注意，不是所有的函式庫都針對安全關(guān)鍵型應(yīng)用做了充分的認(rèn)證，也不是所有函式庫都適合嵌入式系統(tǒng)。

平行程序設(shè)計

嵌入式編譯程序要求的一個額外的新功能是支持當(dāng)前的語言，如C++11/C++14。ADAS設(shè)計的目標(biāo)是提高程序代碼的可重復(fù)使用性，用更少行程序代碼實現(xiàn)更多的功能，而又不放棄接近硬件提供的效率。C++這類和繼承是經(jīng)過時間驗證的方法，非常合適在更高、更抽象的層次編寫這樣的程序代碼。

C++11以及后來的版本都支持這些方法，但與更早的C99語言標(biāo)準(zhǔn)相比具有顯著的優(yōu)勢。另外，C++11(和C11)最終還能用來編寫可移植的平行程序。許多ADAS應(yīng)用的運算開銷在考慮所有響應(yīng)時間要求后，經(jīng)常超過在單核心上實現(xiàn)的連續(xù)處理能力。因此，平行和多核心處理是常見的ADAS系統(tǒng)要求。

像C99等舊標(biāo)準(zhǔn)不支持平行機(jī)制，因此使用這些語言的程序設(shè)計師必須具有很好的硬件和編譯程序知識，才能正確編寫出平行程序。舉例來說，程序設(shè)計師必須將特定的數(shù)據(jù)范圍和代碼段排除在平行訪問之外，從而確保不會丟失數(shù)據(jù)更新或在訪問期間錯誤讀取。程序設(shè)計師還必須在程序代碼中插入屏障(互斥體)，防止關(guān)鍵部分在同一時間被一個以上的核心執(zhí)行。

然而，屏障插入技術(shù)只有在編譯程序理解這些屏障時才有用。如果沒有這樣的概念，那么在編譯程序或硬件優(yōu)化過程中，編譯程序會將這段程序代碼移出受保護(hù)的部分。在C11/C++11發(fā)明之前，還沒有統(tǒng)一的方式來將這種屏障通知給編譯程序，因此程序設(shè)計師必須禁止全部重要的優(yōu)化功能，從而導(dǎo)致嚴(yán)重的效率下降，或者他們會誤用諸如「volatile」等屬性來限制編譯程序的優(yōu)化功能。現(xiàn)在大家都已知道，使用「volatile」屬性對于編寫正確和可移植的平行程序代碼來說是不夠的。

然而，互斥體現(xiàn)在已經(jīng)是C++標(biāo)準(zhǔn)的一部分，因此C++11編譯程序理解所有的屏障概念，編譯程序在必要時能夠防止應(yīng)用出現(xiàn)優(yōu)化，而導(dǎo)致任何不必要的速度損失。與使用優(yōu)化不同，程序設(shè)計師可以使用C++/C++11引入的「atomic」屬性，編譯程序用「atomic」屬性產(chǎn)生的程序代碼，可以透過尋址硬件來揭示期望的行為，并產(chǎn)生最小的性能開銷。這樣，程序設(shè)計師就能專注于他們的主要任務(wù)，即程序代碼功能，而不用試圖透過不合適的方式(如「volatile」屬性)和優(yōu)化習(xí)慣去產(chǎn)生特定程序代碼。

遺憾的是，一般不可能檢測出所有對平行訪問保護(hù)錯誤的程序段和數(shù)據(jù)。有時保護(hù)錯誤的程序不會產(chǎn)生任何編譯程序錯誤，看起來似乎工作正常，但這些程序可能會因為不明顯的時序問題而自發(fā)產(chǎn)生錯誤的結(jié)果。這些錯誤一般只出現(xiàn)在很長的測試時間之后。另外，它們也很難重現(xiàn)，因為它們?nèi)Q于相應(yīng)的運行時間以及系統(tǒng)內(nèi)與時間有關(guān)的干擾。

因此，即使是用C11/C++11編寫正確的平行程序代碼，也不是小事一樁了。自己編寫的平行程序代碼也可能存在雖然正確但只比更易維護(hù)的、功能相當(dāng)?shù)捻樞虺绦虼a快一點點(甚至更慢)的風(fēng)險。幸運的是，像EMB2和LAPACK等函式庫用起來相對風(fēng)險就很小，因為它們都是這個領(lǐng)域中的專家編寫的。作為額外的優(yōu)勢，這些函式庫由于其平行機(jī)制及優(yōu)化，可以確保相對較大的速度提高。

硬件加速器支持

編譯程序還需要具備一些新的功能來滿足越來越異構(gòu)的硬件架構(gòu)要求。這些架構(gòu)擁有差別很大的核心(ARM、AURIX、RH850、NVIDIA等)和補(bǔ)充的加速器(如AURIX中的FFT、ARM和NVIDIA中的SIMD)，也有多種解決方案。一種方案是原生支持，最直接的方法是支持硬件加速器。這些構(gòu)造可以用來處理來自C/C++的特殊硬件指令。

更高級的編譯程序可以支持加速器供貨商提供的特殊高級語言(大多數(shù)類似于C)，從而說明程序設(shè)計師高效滿足硬件要求。例子包括NVIDIA的OpenCL(NVIDIA的編譯程序)、GTM的C(Tasking的編譯程序)和德州儀器(TI)的EVE擴(kuò)展C語言。雖然這些高級語言要求編譯和優(yōu)化，但它們與底層硬件的接近簡化了整個過程。

作為最后一個選項，編譯程序可以自動檢測可被加速器高效執(zhí)行的程序代碼區(qū)域，以便自動生成合適的程序代碼，如同Intel的icc之于SIMD架構(gòu)。然而，在大多數(shù)情況下這種全自動的發(fā)現(xiàn)是受限的，因為標(biāo)準(zhǔn)C/C++程序代碼不是明確為特定加速器編寫的。不過，只需修改少量的程序代碼，編譯程序的自動發(fā)現(xiàn)就能產(chǎn)生很好的結(jié)果，盡管為了在合理的開銷條件下尋找和實現(xiàn)必要的修改，一款合適的調(diào)節(jié)工具是必不可少。

遺憾的是，許多異構(gòu)硬件架構(gòu)強(qiáng)制要求用自己的編譯程序?qū)ぶ访總€可程序設(shè)計單元。為了避免應(yīng)付過多的不兼容工具，防止產(chǎn)生新的安全風(fēng)險，建議使用能夠?qū)ぶ匪锌沙绦蛟O(shè)計單元、確保工具之間互相兼容的工具環(huán)境。比如Tasking提供的英飛凌(Infineon)AURIX/TriCore工具環(huán)境，就可以在一個集成開發(fā)環(huán)境(IDE)中程序設(shè)計和調(diào)試架構(gòu)中的所有單元。因為符號信息在不同單元之間是兼容的，所以可以更安全地控制和監(jiān)視單元之間的交互。

ADAS應(yīng)用的安全要求

為了滿足ADAS應(yīng)用的特殊安全要求，所有工具(包括建模工具、編譯程序和分析工具)，以及與這些應(yīng)用相關(guān)的軟件組件(操作系統(tǒng)、函式庫等)必須依據(jù)ISO 26262進(jìn)行開發(fā)和認(rèn)證。

一些較新的安全要求可以利用神經(jīng)網(wǎng)絡(luò)來理解(圖3)。神經(jīng)網(wǎng)絡(luò)是一些軟件組件，經(jīng)常用于檢測和處理ADAS應(yīng)用中的傳感器數(shù)據(jù)。雖然市場上有許多基于神經(jīng)網(wǎng)絡(luò)的有趣原型，但仍然不清楚如何確保這些網(wǎng)絡(luò)在極端情形下有正確的行為。

圖3 一些較新的安全要求可以利用神經(jīng)網(wǎng)絡(luò)來理解。

目前還沒有已知的過程可以確保神經(jīng)網(wǎng)絡(luò)的行為一直正常，而對道路使用者來說沒有風(fēng)險。因此，如果沒有合適的監(jiān)控實體，就不能讓神經(jīng)網(wǎng)絡(luò)做出安全關(guān)鍵型決策。除了神經(jīng)網(wǎng)絡(luò)自己用的硬件外(這些硬件會根據(jù)輸入數(shù)據(jù)提出難以預(yù)測的決策建議)，必須有一個在硬件上運行的、具有最高安全認(rèn)證等級(ASIL-D)的監(jiān)控實體。這個監(jiān)控實體會使用可預(yù)測的算法工作，檢查由神經(jīng)網(wǎng)絡(luò)做出的建議是否能被安全地執(zhí)行，或者是否應(yīng)該選擇更安全的方案(圖4)。舉例來說，監(jiān)控實體會檢查由神經(jīng)網(wǎng)絡(luò)建議的通行方案是否能夠在沒有風(fēng)險的條件下執(zhí)行，出于這個目的，它會使用自己的、可預(yù)測的運算來檢查是否沒有障礙物等。為了創(chuàng)建有效的監(jiān)控實體，人們?nèi)栽谂ρ芯磕承╊I(lǐng)域(比如資料融合)中的可預(yù)測算法。

圖4 資料融合單元。

針對ADAS應(yīng)用的許多可預(yù)測算法都是基于LAPACK和其他函式庫支持的線性代數(shù)運算實現(xiàn)的?？梢杂脙?yōu)化的解決方案在各種目標(biāo)平臺上高效安全地實現(xiàn)這些算法。

ADAS應(yīng)用的其余部分可以用有助于滿足各種ISO 26262要求的多種工具和技術(shù)進(jìn)行認(rèn)證。簡單的程序設(shè)計錯誤(包括沒有初始化的數(shù)據(jù))可以用靜態(tài)分析工具(Polyspace、Klocwork等)實現(xiàn)高效檢測。為了檢測與安全相關(guān)的訪問違例(具有不同ASIL類別的軟件組件彼此訪問，并在內(nèi)存保護(hù)單元(MPU)中創(chuàng)建保護(hù)故障)，使用編譯程序整合的安全檢查器擴(kuò)展是很有好處的——它能用來定義不同的安全類別(比如ASIL-A到D)，將項目中用到的數(shù)據(jù)和函數(shù)分配到不同的安全類別，并管理這些類別之間的訪問權(quán)限。

然后，這個信息可以用于兩個目的。首先，編譯程序無法執(zhí)行某些優(yōu)化(反向程序代碼嵌入、程序代碼壓縮)，因為這些優(yōu)化在執(zhí)行時，如果沒有考慮訪問權(quán)限問題，可能會導(dǎo)致安全訪問違例。其次，可以用安全檢查器工具，將這個相同信息用于識別可能產(chǎn)生MPU例外、未檢測到的訪問違例，而不會有任何額外的測試開銷，而且有很高的程序代碼覆蓋率。

為了依據(jù)ISO 26262對工具(建模工具、編譯程序、靜態(tài)分析、安全檢查器等)進(jìn)行認(rèn)證，大多數(shù)制造商提供可極大簡化必要過程的ISO套件。在這種情況下，選用在汽車領(lǐng)域中具有悠久歷史的工具和制造商會很有幫助。出于這個目的，ISO 26262-8使用了術(shù)語「久經(jīng)考驗(proven in use)」，它的假設(shè)是，一款在很長時間內(nèi)得到頻繁使用而且?guī)缀鯖]有問題的工具，與新工具相比可能不太容易出錯。

除了解決上述安全風(fēng)險外，編譯程序及其相關(guān)工具有助于減輕與ADAS應(yīng)用有關(guān)的設(shè)計風(fēng)險。

控制設(shè)計風(fēng)險

如果選擇不合適的硬件、函式庫和開發(fā)工具組合，可能會在ADAS領(lǐng)域產(chǎn)生較大的設(shè)計風(fēng)險。目前針對特定的ADAS應(yīng)用，基本上無法預(yù)測特定軟硬件組合的效率。

舉例來說，可能存在所用硬件太大、太耗能或者太小的風(fēng)險。遺憾的是，目前沒有連續(xù)的系列可用：結(jié)果證明太小的硬件無法用尺寸稍大一些的兼容硬件直接替換。設(shè)計人員可以在具有較低安全認(rèn)證等級的很大配置和具有較高認(rèn)證等級但小得多的配置之間做出選擇。目前兩種選擇之間的轉(zhuǎn)換會產(chǎn)生過多的開銷，因為在架構(gòu)及其最佳使用所要求的程序代碼結(jié)構(gòu)之間存在顯著的差異。

目前這個問題可以用編譯程序單獨解決。然而，如果有配套的合適軟件環(huán)境的話，編譯程序可以使得這種風(fēng)險完全可控。如果能夠?qū)⒒谔囟ㄓ布?、高效線性代數(shù)函式庫的良好建模解決方案與能夠滿足ADAS應(yīng)用典型要求的編譯程序環(huán)境結(jié)合起來使用，那么得到的綜合解決方案將勝過兩者的簡單迭加。

ADAS應(yīng)用很大程度上可以使用建模解決方案并以獨立于硬件的方式實現(xiàn)。底層的編譯程序和函式庫支持將基于模型的通用實現(xiàn)移植到有很大差異的硬件平臺上，并且開銷很小，效率很高。由此導(dǎo)致的少量效率不高可以透過性能分析(profiling)來實現(xiàn)快速識別和消除。

對通用程序代碼來說，這種組合方案可以在各種目標(biāo)平臺上提供實現(xiàn)最佳效率的確定性快捷方式。透過利用一組額外的、根據(jù)目標(biāo)硬件和輸入數(shù)據(jù)分辨率記錄有所有工具的組合效率的基準(zhǔn)，這些數(shù)據(jù)可以用來預(yù)測新的ADAS應(yīng)用在新的目標(biāo)硬件上的期望效率，并且具有較高的精度。這將極大地降低選擇到不適合預(yù)期ADAS應(yīng)用的目標(biāo)硬件風(fēng)險。

目前市場上的編譯程序沒有哪種能夠滿足所有要求，完整解決方案所要求的一些工具和函式庫也不是唾手可得。因此，編譯程序的路線圖很清晰：必須在不忽略整體解決方案的條件下滿足剩余要求。舉例來說，Tasking正在規(guī)劃新的產(chǎn)品，包括用于AURIX的認(rèn)證過的LAPACK函式庫，這些產(chǎn)品得到了工具合作伙伴和用戶的大力支持。