日本无码免费高清在线|成人日本在线观看高清|A级片免费视频操逼欧美|全裸美女搞黄色大片网站|免费成人a片视频|久久无码福利成人激情久久|国产视频一二国产在线v|av女主播在线观看|五月激情影音先锋|亚洲一区天堂av

  • 手機站
  • 小程序

    汽車測試網(wǎng)

  • 公眾號

    • 汽車測試網(wǎng)

    • 在線課堂

    • 電車測試

軟件定義汽車 (第七集) : 高性能計算單元架構(gòu)

2020-07-20 18:22:47·  來源：汽車電子與軟件  作者：Leo Huang SDV  
　
導讀：前一篇文章中介紹了傳統(tǒng)ECU的特點及開發(fā)模式，在中央計算電子電氣架構(gòu)下，中央計算單元都會采用高性能的SOC來作為主運算單元，由于其資源的豐富性，其開發(fā)
導讀：
前一篇文章中介紹了傳統(tǒng)ECU的特點及開發(fā)模式，在中央計算電子電氣架構(gòu)下，中央計算單元都會采用高性能的SOC來作為主運算單元，由于其資源的豐富性，其開發(fā)模式和開發(fā)的復雜度，相比與傳統(tǒng)的ECU都大有不同，因此，對應(yīng)的軟件架構(gòu)（邏輯，物理，運行，部署等架構(gòu)視圖）、軟件工程中各個環(huán)節(jié)（設(shè)計、開發(fā)、測試、部署等過程）都不相同。本篇主要介紹中央計算單元的軟件架構(gòu)，闡述各個軟件模塊主要工作任務(wù)。
 
1. 高性能計算單元
 
中央計算單元，其實就是一臺經(jīng)過特殊設(shè)計的專用計算機，其中最核心的是主芯片，一般會采用一顆或多顆高性能的SOC。SOC是System on Chip的縮寫，就是在單塊芯片上集成多個微處理器、模擬IP核、數(shù)字IP核和存儲器等部件，比如CPU、GPU、DSP、ISP、Codec、NPU、Modem等模塊。
 
在傳統(tǒng)PC時代，各個核心芯片都是以獨立的方式存在，比如英特爾和AMD的CPU、NVIDIA的GPU等，到了移動互聯(lián)網(wǎng)時代，由于體積功耗方面的要求，主芯片都會進行高度的集成，除了大家熟知的CPU和GPU，通常還包含了音頻、多媒體、顯示、安全、通信、AI計算等子單元。
 
這些單元，在一套總線系統(tǒng)的連接下，構(gòu)成了一個系統(tǒng)。大家所熟知的各種手機SOC芯片，如蘋果的A系列、高通的驍龍系列、華為的麒麟系列，或者各類的AI SOC芯片，車載領(lǐng)域的各種SOC芯片，都逃不出以上范式。
雖然都是同一范式，但是由于使用的場景不同，各個芯片的側(cè)重點不太一樣：
  • 娛樂系統(tǒng)芯片，其實和消費電子幾乎一模一樣，關(guān)注音頻、視頻、顯示、圖像等、Modem等。
  • 自動駕駛芯片，注重高性能計算，一般配備有強大的NPU、GPU、DSP等。
  • 網(wǎng)關(guān)芯片，主要特點是外設(shè)接口較多，有的也會集成swtich。
 
高性能計算單元.png
上一篇中，為大家介紹了傳統(tǒng)ECU芯片的架構(gòu)，其計算資源相對有限，結(jié)構(gòu)也比較簡單，一般NVM和SRAM都集成在了芯片內(nèi)部，大小在KB級別，處理器一般采用Cortex-M內(nèi)核。高性能的SOC其計算資源和外設(shè)都更加豐富，一般會集成多個Cortex-A內(nèi)核，其存儲單元采用外掛的形式，大小在GB級別。
一般的應(yīng)用場景中，集成一個主芯片就能夠滿足計算資源的需求，但是自動駕駛對算力有著更高的要求，有時候 于安全的考慮，也需要同時集成多個主芯片，其結(jié)構(gòu)一般如下圖所示：
 
多個芯片在需要在PCIe Switch的連接下共同組成一個計算單元，如果以后發(fā)展成可動態(tài)拓展的形式（類似于刀片機），該結(jié)構(gòu)依然適用，以下是采用兩個Xavier芯片組成的一個高性能計算單元的示意圖：
 
xavier.png
 
2.  中央計算單元上的軟件架構(gòu)
 
高性能計算單元上是需要運行操作系統(tǒng)的，如果完全用裸機程序去控制，幾乎無法完成。從下到上，依次可分為以下幾個部分，硬件驅(qū)動層，操作系統(tǒng)內(nèi)核，分布式中間件，并行計算中間件，應(yīng)用及服務(wù)。
 
硬件驅(qū)動層(BSP)
在嵌入式軟件開發(fā)當中，軟件工程師經(jīng)常要直接和硬件進行交互，但是在高性能計算單元上，由于有富操作系統(tǒng)的存在，這部分工作一般由BSP工程師完成。
 
BSP（Board Support Package）板級支持包，是介于硬件和操作系統(tǒng)中驅(qū)動層程序之間的一層，一般認為它屬于操作系統(tǒng)一部分，主要是實現(xiàn)對操作系統(tǒng)的支持，為上層的驅(qū)動程序提供訪問硬件設(shè)備寄存器的函數(shù)包，不同的操作系統(tǒng)對應(yīng)于不同形式的BSP，盡管實現(xiàn)的功能一樣，可是寫法和接口定義是完全不同的，BSP的編程過程大多數(shù)是在某一個成型的BSP模板上進行修改，芯片廠商一般會基于其開發(fā)板，提供一個可運行的軟件基線，開發(fā)廠商基于該基線進行修改。
 
BSP的調(diào)試工作是和硬件強相關(guān)的，目前普遍會選擇由硬件Tier1做掉這部分工作，由于本身的技術(shù)壁壘不高，所以有余力的玩家選擇自己做也完全不是什么問題。
 
操作系統(tǒng)內(nèi)核
在軟件定義汽車1-3合集中，我對操作系統(tǒng)的概念做過辨析，為了避免歧義，這里我直接稱操作系統(tǒng)內(nèi)核，很多玩家所謂的做自己的操作系統(tǒng)，其實都只是內(nèi)核之上的中間件。這部分不是主機廠該做的事情，用QNX、Vxworks、Linux、FreeRTOS等，或者以后的鴻蒙微內(nèi)核即可。雖然這種不直接面向C端用戶的操作系統(tǒng)對應(yīng)用生態(tài)的要求不高，但是對于開發(fā)者生態(tài)的要求還是挺高的。使用這些操作系統(tǒng)的時候，有幾個因素至關(guān)重要：
  • POSIX兼容性
  • 工具鏈
POSIX是一個操作系統(tǒng)的接口標準，如果一個操作系統(tǒng)對于POSIX兼容性好，那么開源世界中的很多軟件模塊是可以復用的。舉一個例子，cocos2dx 是一個開源的游戲引擎，支持windows、Linux、Mac等系統(tǒng)，不支持QNX系統(tǒng)，但是由于QNX系統(tǒng)良好的兼容了POSIX，我們只花了很少的功夫就把其移植到了QNX上，雖然cocos2dx依賴了好幾十個開源的軟件庫，但調(diào)用的都是標準的POSIX接口，所以也都能非常方便的進行移植。有些網(wǎng)關(guān)開發(fā)中會使用FreeRTOS，其也有專門的拓展庫來支持POSIX調(diào)用。
 
舉一個反面的例子，Halide是一個專用的圖像處理引擎，其構(gòu)建是基于LLVM編譯器框架的，由于QNX官方支持的編譯器是基于GNU GCC的，我曾經(jīng)嘗試過要把Halide移植到QNX，但是由于編譯器不支持，遷移過程就碰到了很大的困難。所以系統(tǒng)所支持的編譯器框架，也決定了很多最新的開源項目是否能被使用。
 
傳統(tǒng)主機廠，不喜歡開源軟件，其中最重要的一個原因，是其技術(shù)實力太弱，出了問題自己無法解決，但是新的科技玩家，會更加的擁抱開源軟件。
 
主機廠自己做軟件，雖然不用去碰內(nèi)核，但是必須有幾個系統(tǒng)方面的高手，主要是應(yīng)對系統(tǒng)的穩(wěn)定性問題，這個對于安全性較高的控制器尤為重要，軟件進度上的問題堆人力可以彌補，但涉及到架構(gòu)、性能、穩(wěn)定性、安全等，做這部分工作就不是靠堆人力能解決的。
 
分布式中間件
參考軟件定義汽車1-3，所謂的分布式中間件，就是在實時的RTOS內(nèi)核上，基于POSIX的API，構(gòu)建的一個跨平臺的操作系統(tǒng)中間件，為上層的應(yīng)用提供良好的計算、通信的開發(fā)框架，其作用類似于Android的framework，只不過主要是針對實時、高可靠性應(yīng)用場景的。
這類framework中間件，有三個核心要素：
  • Library（提供一系列基礎(chǔ)庫，封裝特定功能）
  • Service （獨立運行的基礎(chǔ)服務(wù)節(jié)點，作為邏輯處理的后端）
  • SDK （為上層應(yīng)用提供良好的API接口）
從功能上講，這類framework中間件，一般需要包含以下功能：
  • 包管理（應(yīng)用管理）：基于基礎(chǔ)軟件平臺開發(fā)的上層應(yīng)用，在編譯之后會被打成一個應(yīng)用程序包，在這個包中一般會有一個manifest文件，該文件聲明該包的版本，依賴，所需權(quán)限，生命周期，啟動選項等。當該應(yīng)用安裝到系統(tǒng)中的時候，包管理程序會解析該manifest文件，得到的元數(shù)據(jù)會保存到數(shù)據(jù)庫當中，這些數(shù)據(jù)是后續(xù)該應(yīng)用能夠正常運行，正常升級的關(guān)鍵。
  • 運行管理：系統(tǒng)在啟動階段，各個應(yīng)用程序需要按照預先定義的啟動順序被拉起來；在運行階段，管理程序需要記錄當前應(yīng)用的狀態(tài)，處理應(yīng)用生命周期的各種事件。比如手機和PC程序都會有前臺應(yīng)用的概念，當打開、關(guān)閉、重啟、切換等事件發(fā)生的時候，系統(tǒng)的運行管理程序都會發(fā)送一個消息給應(yīng)用，讓其做好相應(yīng)的處理工作。不同的點在于，面向消費者的操作系統(tǒng)，都是可以讓用戶操作的，所以大部分的邏輯是與人機交互事件有關(guān)的，而面向車輛底層的系統(tǒng)，更多的是在后臺處理相關(guān)的事件請求，其設(shè)計策略與邏輯完全不同。
  • 通信管理：運行在分布式系統(tǒng)上的各個應(yīng)用程序，是需要進行數(shù)據(jù)交互的，這就需要一類IPC/RPC的框架來支撐；IPC是指本機間的進程通信，RPC是指跨機器的間的遠程調(diào)用，在分布式系統(tǒng)當中這兩種通信都會碰到。比如在linux中常用的dbus，Android中使用的binder，以及前面文章中提到的DDS與some/IP。作為一個基礎(chǔ)軟件平臺，一般是不會把這些原始的通信方法暴露給上層應(yīng)用的，framework會有自己的API去屏蔽底層通信協(xié)議的差異，這在架構(gòu)設(shè)計中很關(guān)鍵，決定了框架是否和某一通信中間件綁死。如果還在拿dds與someip的原始接口寫程序，意味著根本就沒有進行平臺化設(shè)計。
  • 權(quán)限管理：安全在車上是一個更加重要的問題，一個用戶和應(yīng)用程序具有哪些權(quán)限，應(yīng)該是被嚴格控制的。在應(yīng)用程序的manifest當中，一般會聲明該程序具有哪些權(quán)限，權(quán)限管理程序會根據(jù)包管理程序解析的元數(shù)據(jù)來嚴格控制應(yīng)用程序的訪問權(quán)限。一些高安全等級要求的訪問權(quán)限，一般還會需要經(jīng)過特別簽名，以此來防止一些非法應(yīng)用獲得系統(tǒng)權(quán)限。在類unix系統(tǒng)當中，權(quán)限系統(tǒng)一般會根據(jù)UID和GID為基礎(chǔ)進行設(shè)計，但是在車載環(huán)境中，此類權(quán)限系統(tǒng)也還不夠，還需要進行更加嚴格的權(quán)限控制。
  • 升級管理：能夠不斷的進行軟件升級是軟件定義汽車的基礎(chǔ)，傳統(tǒng)的ECU，一般都會生成一個bin文件，是沒有所謂的包管理程序的概念的，要升其實就是把整個分區(qū)給刷掉了。這種方式針對傳統(tǒng)的ECU并沒有什么問題，但是針對高性能計算單元，這種方式的效率就很低，刷KB級的數(shù)據(jù)和刷GB級的數(shù)據(jù)，完全不是一個概念。為了高效的進行迭代，平臺升級和應(yīng)用升級一定是需要分開。平臺升級類似于手機的ROM升級，而應(yīng)用升級類似于手機的APP升級，一個長周期，一個短周期。要實現(xiàn)這種升級方式，是需要一個良好設(shè)計的基礎(chǔ)軟件平臺的，應(yīng)用與系統(tǒng)必須徹底解耦，這對架構(gòu)設(shè)計是非常大的挑戰(zhàn)。很遺憾，國內(nèi)目前沒一家能夠做到這個水平，大家都會拿車的復雜性說事，其實是因為設(shè)計上的短板造成的，國內(nèi)的幾個先驅(qū)公司都被這個事情所困擾。因為在前期發(fā)展的過程中，都只注重短期功能的實現(xiàn)，沒有真正的在工程能力方面下功夫。
  • 其他的還有像診斷、日志、持久化、加密等功能性的模塊，就不一一展開，后續(xù)可以針對每一部分的設(shè)計進行詳細闡述。
這類中間件的平臺，是一個基礎(chǔ)的工具，各家之間沒必要重復造輪子，行業(yè)是有一個adaptive autosar，但是目前還遠遠不夠完善，特別是在并行計算方面。不只是在車載領(lǐng)域，整個中國的軟件行業(yè)就沒有一家像樣的中間件公司，和一些投資機構(gòu)的朋友也聊到了這個問題，我認為最大原因還是這類產(chǎn)品屬于工程產(chǎn)品，客戶都更愿意看到一個完整的解決方案，而不是給他提供一個中間件，之前快的節(jié)奏讓大家都只愿意做來錢快的事情，這些慢活兒也沒有成長的土壤。
 
但是在目前的政治環(huán)境之下，這種情況似乎迎來了一絲改變，一些貿(mào)易沖突，也讓大家意識到了，老老實實打基礎(chǔ)還是挺重要的。中國汽車行業(yè)最大的問題在于，這些玩家都覺得自己挺牛逼的，誰也不買誰的單，都想自己搞一套，但是在這個事情上，真心不是哪一個能獨自搞定的。所以我還是建議，大家能夠聯(lián)合起來做點事情，哪怕是投點錢支持一些創(chuàng)業(yè)公司搞開源，也比自己搞要靠譜。就算是一家主機廠發(fā)起了一個開源項目，大概率其他的主機廠也不會用，必須以中立的身份來做，才能獲得大家共同的認可。
 
服務(wù)及應(yīng)用層
參考軟件定義汽車1-3， 在一個標準的基礎(chǔ)軟硬件平臺之上，各家主機廠可以構(gòu)建自己的服務(wù)和應(yīng)用體系，這也是各家能夠形成差異化的地方。針對不同的應(yīng)用場景（智駕、座艙、網(wǎng)關(guān)、車控等），以及各自差異化的硬件設(shè)備，抽象一套屬于自己的服務(wù)體系，SOA只是實現(xiàn)目的的一種方式，大家可以根據(jù)自己的理解去拆解、分層、分類，然后形成一套自己的SDK體系，以支持產(chǎn)品業(yè)務(wù)的快速迭代。
在此基礎(chǔ)上，我也期待有一天，能在各個車廠之間形成統(tǒng)一的接口定義的標準，那樣一個應(yīng)用就能夠部署到所有車上，這其實是在從Tier1的角度看問題，Classic AutoSAR就是在這個愿景上產(chǎn)生的，對主機廠來說，只要自己所有車型能夠統(tǒng)一，就是一個偉大的成就了。
 
3.  并行計算框架
隨著自動駕駛與智能座艙的發(fā)展，大量的以視覺為主的傳感器部署到了車上，產(chǎn)生的數(shù)據(jù)需要高算力的計算單元來處理，就需要一個并行計算的框架來支撐應(yīng)用程序的開發(fā)與部署。原則上來講，該框架應(yīng)該屬于上面介紹的分布式計算框架的一部分，主要是這部分內(nèi)容與傳統(tǒng)的應(yīng)用框架不太一樣，所以拿出來單獨講。
 

目前有各種各樣的AI計算芯片，但總體上都是CPU+協(xié)處理器的基本構(gòu)型；CPU可以是基于ARM的IP，協(xié)處理可以是GPU、NPU、DSP、FPGA等，這些異構(gòu)的計算單元，都會有自己的指令集。CPU擅長于做邏輯處理，這些并行計算單元擅長于做高性能計算，汽車電子軟件公眾號之前有文章介紹這幾種計算單元的差異，有興趣的可以去了解。
 
工作原理
大部分SOC都會采用這種主+從的方式，比如NVIDIA采用是CPU+GPU，高通采用CPU+GPU+ NPU+DSP，TI也采用CPU+GPU+ NPU+DSP，賽靈思采用CPU+FPGA等。
 
開發(fā)人員寫的程序，雖然都在一個工程當中，但是在編譯階段，通過芯片廠商提供的工具鏈，代碼會被編譯成為兩個部分：運行在CPU上的，與運行在異構(gòu)單元上的，芯片廠商會提供一個基礎(chǔ)的通信框架，來處理這部分邏輯。
 
在程序運行階段，這兩部分程序都會被加載到內(nèi)存當中，由于SOC的總線設(shè)計當中很容易做到內(nèi)存共享，各個計算單元會各自讀取運行的指令與參數(shù)，通過芯片廠商提供的RPC框架，主程序可以很方便與協(xié)處理器進行邏輯通信。
 
需要注意的是，高性能計算的并不僅是運行CNN網(wǎng)絡(luò)，還有其他的很多計算任務(wù)需要用到并行計算，并且每種計算單元的程序開發(fā)模型都不太一樣，如果每部分都需要開發(fā)人員自己去處理，開發(fā)過程會非常復雜。
 
比如NVIDIA提供CUDA庫來支持GPU上的并行計算，在CUDA之上又構(gòu)建了TensorRT來運行神經(jīng)網(wǎng)絡(luò)；高通提供的SNPE框架，能夠支持任務(wù)自動調(diào)度到CPU、GPU、NPU、DSP之上。當前階段，這些框架都是和芯片高度綁定的，目前還沒有一個通用的框架來屏蔽所有的差異。
 
除了底層的運行框架不統(tǒng)一之外，上層的應(yīng)用開發(fā)框架也沒有一個統(tǒng)一標準。比如NVIDIA提供了DRIVE AV平臺，用于支持使用自家芯片進行自動駕駛應(yīng)用的開發(fā)；很多公司基于ROS開發(fā)原型系統(tǒng)；也有創(chuàng)業(yè)公司基于ROS2進行車規(guī)化改造；還有一些使用Adaptive AutoSAR進行開發(fā)，但這部分恰好是其短板。
 
這部分實現(xiàn)想統(tǒng)一的確有比較大的困難，因為與芯片架構(gòu)強相關(guān)，現(xiàn)階段AI芯片的種類五花八門，在硬件構(gòu)型不統(tǒng)一的的狀態(tài)下，只能先選擇芯片，再決定技術(shù)架構(gòu)。
 
4. 結(jié)語
 
本篇從大的維度上介紹了高性能計算單元上軟件架構(gòu)的幾個重要部分，每個一個部分其實都值得繼續(xù)進行深入。硬件單元的不同，也會導致軟件框架的設(shè)計出現(xiàn)一些特性差異，比如在一個雙冗余的計算單元中，除了硬件的fallback設(shè)計，軟件上如何進行fallback，可選方案有多種，也不是非此即彼的問題。
此類專業(yè)的問題，沒人給出最佳實踐，即使是特斯拉也是在不斷的摸索當中，解決此類問題，模仿只是一種途徑，正向的去思考，去設(shè)計，也是一種有效途徑。軟件定義汽車社區(qū)，慢慢已經(jīng)積累了不少專家，后續(xù)將會開展一些技術(shù)研討會，也歡迎各位提供問題與素材。
 
寫于2020年7月18日下午
 
—END—
《軟件定義汽車》專輯
作為一個技術(shù)的愛好者，搞算法，玩芯片，攢系統(tǒng)，并不只是工作，也是自己所追求的很重要的部分。寫這個系列，是為了梳理這幾年的所學、所思、所想，從而形成一個完整的知識體系，也供大家參考。
作者：leo_huang_ 
加入汽車軟件開發(fā)者社區(qū)（僅限技術(shù)人員）：
管理員微信號：18918250345
 
 
分享到：
 
反對 0 舉報 0 收藏 0 評論 0
滬ICP備11026917號-25