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

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

圖1 基于傳感器的不同ADAS應用的監測區域。

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

圖2 環境傳感器產生的有噪聲訊號及濾波后的結果。

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

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

尋找一種合適的硬件架構

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

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

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

程序代碼結構的效率

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

高度優化的函式庫

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

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

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

平行程序設計

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

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

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

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

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

遺憾的是，一般不可能檢測出所有對平行訪問保護錯誤的程序段和數據。有時保護錯誤的程序不會產生任何編譯程序錯誤，看起來似乎工作正常，但這些程序可能會因為不明顯的時序問題而自發產生錯誤的結果。這些錯誤一般只出現在很長的測試時間之后。另外，它們也很難重現，因為它們取決于相應的運行時間以及系統內與時間有關的干擾。

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

硬件加速器支持

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

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

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

遺憾的是，許多異構硬件架構強制要求用自己的編譯程序尋址每個可程序設計單元。為了避免應付過多的不兼容工具，防止產生新的安全風險，建議使用能夠尋址所有可程序設計單元、確保工具之間互相兼容的工具環境。比如Tasking提供的英飛凌(Infineon)AURIX/TriCore工具環境，就可以在一個集成開發環境(IDE)中程序設計和調試架構中的所有單元。因為符號信息在不同單元之間是兼容的，所以可以更安全地控制和監視單元之間的交互。

ADAS應用的安全要求

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

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

圖3 一些較新的安全要求可以利用神經網絡來理解。

目前還沒有已知的過程可以確保神經網絡的行為一直正常，而對道路使用者來說沒有風險。因此，如果沒有合適的監控實體，就不能讓神經網絡做出安全關鍵型決策。除了神經網絡自己用的硬件外(這些硬件會根據輸入數據提出難以預測的決策建議)，必須有一個在硬件上運行的、具有最高安全認證等級(ASIL-D)的監控實體。這個監控實體會使用可預測的算法工作，檢查由神經網絡做出的建議是否能被安全地執行，或者是否應該選擇更安全的方案(圖4)。舉例來說，監控實體會檢查由神經網絡建議的通行方案是否能夠在沒有風險的條件下執行，出于這個目的，它會使用自己的、可預測的運算來檢查是否沒有障礙物等。為了創建有效的監控實體，人們仍在努力研究某些領域(比如資料融合)中的可預測算法。

圖4 資料融合單元。

針對ADAS應用的許多可預測算法都是基于LAPACK和其他函式庫支持的線性代數運算實現的。可以用優化的解決方案在各種目標平臺上高效安全地實現這些算法。

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

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

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

除了解決上述安全風險外，編譯程序及其相關工具有助于減輕與ADAS應用有關的設計風險。

控制設計風險

如果選擇不合適的硬件、函式庫和開發工具組合，可能會在ADAS領域產生較大的設計風險。目前針對特定的ADAS應用，基本上無法預測特定軟硬件組合的效率。

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

目前這個問題可以用編譯程序單獨解決。然而，如果有配套的合適軟件環境的話，編譯程序可以使得這種風險完全可控。如果能夠將基于特定硬件、高效線性代數函式庫的良好建模解決方案與能夠滿足ADAS應用典型要求的編譯程序環境結合起來使用，那么得到的綜合解決方案將勝過兩者的簡單迭加。

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

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

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