域控制器發展趨勢
域控制器的興起對傳統的汽車MCU廠商造成了極大的挑戰，“因為MCU使用量將大大減少，傳統的MCU產品其演進路線將不復存在”。
在分布式ECU時代，計算和控制的核心是MCU芯片，傳輸的基礎核心是基于傳統的CAN、LIN和FlexRay等低速總線。但在域控制器時代，高性能、高集成度的異構SoC芯片作為域的主控處理器，將成為域控制器的計算與控制的核心芯片。而汽車TSN（Time-Sensitive Network）以太網因為具有高帶寬、實時和可靠的數據通信能力等特點，必將成為整車通信的核心基礎設施，尤其是域主控處理器之間的通信主干網。
下面我們來簡單分析一下域控制器以及核心的主控處理器的一些關鍵技術和趨勢。
3.1 高性能
總的來說，對算力的需求提升一直是域控制器核心芯片發展的主要推動力。一方面原本由多個ECU完成的功能，現在需要依靠單一的域主控處理器來完成，并且還需要管理和控制所連接的各種傳感器與執行器等。比如：底盤、動力傳動系統和車身舒適電子系統的域主控處理器，其算力需求大約在10000DMIPS-15000DMIPS左右。
圖2-5 汽車域控制器對CPU DMIPS算力的需求預測
新的智能汽車，除了要更多的與人交互外，更需要大量的對環境進行感知，這就需要計算和處理海量的非結構化數據，因此座艙域和自動駕駛域都要求高性能的CPU，比如就座艙儀表的CPU算力而言，它其實跟一部高端智能手機的CPU算力差不多，約為50000DMIPS左右。此外，為了支持L2輔助駕駛功能或者更高級別的自動駕駛功能，需要運行很多視覺DNN模型算法，這就又額外需要上百TOPS的AI算力。
所以，各芯片廠商總是會盡量使用更先進的制程工藝、更先進的CPU核于與NPU核來盡量提高域主控芯片的CPU核心性能與NPU性能。
3.2 高異構性
伴隨著AI技術在視覺領域的應用，基于視覺的自動駕駛方案逐漸興起，這就需要在CPU的基礎上加裝擅長視覺算法的GPU芯片，從而形成“CPU+GPU”的解決方案。不過，“CPU+GPU”組合也并非最優解決方案，因為 GPU 雖然具備較強的計算能力，但成本高、功耗大，由此又逐步引入了FPGA和 ASIC 芯片。
總體來看，單一類型的微處理器，無論是 CPU、GPU、FPGA還是ASIC，都無法滿足更高階的自動駕駛需求，域控制器中的主控芯片會走向集成“CPU+xPU”的異構式 SoC（xPU 包括 GPU/FPGA/ASIC等），從而能較好的支撐各種場景的硬件加速需求。
3.3 高集成度
從功能層面上，域控制器會整合集成越來越多的功能。比如動力系統域可能把發動機的控制、電機控制、BMS、車載充電機的控制組合在一起。有些主機廠甚至直接一步到位，將底盤、動力傳動以及車身三大功能域直接整合成一個“整車控制域（Vehicle Domain Controller，VDC）”。
要支持這些功能的整合，作為域控制器的大腦，域主控處理器SoC就需要集成盡可能多的接口類型，比如：USB、Ethernet、I2C、SPI、CAN、LIN以及FlexRay等等，從而能連接和管理各種各樣的ECU、傳感器和執行器。
3.4 硬件虛擬化
對硬件虛擬化技術的需要主要來自兩方面：（1）硬件資源的分區與隔離；（2）支持混合安全等級。
原本需要多個ECU實現的多個功能都整合到域控制器上后，勢必會導致域控制器的軟件更為復雜，這勢必會導致整個軟件系統的出錯概率增加、可靠性下降。而且多個應用混合運行在同一個操作系統上，經常會出現故障傳播（Failure Propagation），也就是一個應用出現問題后，會使得整個系統底層軟件和硬件都處于紊亂狀態，從而導致其它原本正常的應用也會開始出現故障。因此通過硬件虛擬化技術對硬件資源進行分區（Partition），使得各個功能對應的軟硬件之間互相隔離（Isolation），以此保證整個系統的可靠性。
另一方面，在汽車電子系統中，通常不同的應用其對實時性要求和功能安全等級要求都不同。例如，根據ISO 26262標準，汽車儀表系統與娛樂信息系統屬于不同的安全等級，具有不同的處理優先級。汽車儀表系統與動力系統密切相關，要求具有高實時性、高可靠性和強安全性，要求運行在底層實時操作系統上（比如QNX）。而信息娛樂系統主要為車內人機交互提供控制平臺，追求多樣化的應用與服務，以Linux和Android為主。為了實現混合安全等級的應用，實現不同的操作系統運行在同一個系統上，這就需要虛擬化技術的支持。
車載硬件虛擬化技術的核心是Hypervisor，它是一種運行在物理服務器和操作系統之間的中間層軟件，可以允許多個不同虛機上的操作系統和應用共享一套基礎物理硬件。當系統啟動時，首先運行Hypervisor，由它來負責給每一臺虛擬機分配適量的內存、CPU、網絡、存儲以及其它硬件資源等等（也就是對硬件資源進行分區），最后加載并啟動所有虛擬機的客戶操作系統。
一句話總結一下基于Hypervisor的優點：它提供了在同一硬件平臺上承載異構操作系統的靈活性，同時實現了良好的高可靠性和故障控制機制, 以保證關鍵任務、硬實時應用程序和一般用途、不受信任的應用程序之間的安全隔離，實現了車載計算單元整合與算力共享。
3.5 ISO 26262功能安全
功能安全是汽車研發流程中非常關鍵的要素之一。隨著系統復雜性的提高，來自系統失效和隨機硬件失效的風險日益增加。ISO 26262標準制定的目的就是更好的規范和標準化汽車全生命周期中的功能安全管理和要求，包括：概念階段、系統研發、硬件研發、軟件研發、生產和操作過程、售后等環節，尤其重點在產品設計階段如何定義和實現功能安全的目標。
載汽車功能安全標準ISO26262-5 2018 “產品開發：硬件層面附錄D”中對處理器單元的診斷覆蓋率推薦的安全技術措施中，雙核鎖步(dual-core lockstep)、非對稱冗余和編碼計算是三種典型的硬件冗余技術措施。除此之外，硬件BIST、軟硬件Self-Test技術、ECC等也是常見的提高處理器安全特性的設計措施。
圖2-6 ISO26262標準中的功能安全芯片設計技術
雙核鎖步CPU是一種CPU冗余技術，在一個芯片中包含兩個相同的處理器，一個作為master core，一個作為slave core，它們執行相同的代碼并嚴格同步，master可以訪問系統內存并輸出指令，而slave不斷執行在總線上的指令（即由主處理器獲取的指令）。slave產生的輸出，包括地址位和數據位，發送到比較邏輯模塊，由master和slave總線接口的比較器電路組成，檢查它們之間的數據、地址和控制線的一致性。檢測到任何總線的值不一致時，就會發現其中一個CPU 上存在故障，但不會確定是哪個CPU故障。
這種CPU架構使得CPU自檢獨立于應用軟件，不需要執行專門的指令集自檢，實際運行的軟件指令在每個時鐘都進行比較，只需要測試軟件用到的CPU資源，但這種架構不會對內存和總線進行檢測，需要增加單獨的檢測方法以避免兩個CPU的共模故障。
3.6 網絡卸載引擎
汽車網絡會存在多種通信總線。骨干網未來勢必會基于TSN以太網來構建，但是從域主控處理器到ECU或者傳感器之間的通信則仍然是基于傳統的車載低速總線，比如：CAN、FlexRay等。域主控處理器作為域控制器的核心，是所有ECU和傳感器通信的匯聚中心。因此如果要依靠CPU的算力來完成不同總線間的協議轉換，以及跨域通信的網絡包處理的話，勢必會占用寶貴的CPU算力資源。
因此基于硬件來實現網絡協議轉換處理的網絡卸載引擎，對于各個域（包括中央網關）的域主控處理器是非常重要的技術。
3.7 Security引擎
連接性（Connectivity）是汽車智能化發展的一個很重要的趨勢，未來的汽車一定會像今天的手機一樣隨時保持連接到互聯網中。因此如何阻止未經授權的網絡訪問，以保護汽車免于受到黑客的攻擊，對未來的智能汽車而言就會變得極為重要。下一代硬件安全模塊（Hardware Security Module，HSM）正在成為下一代車載網絡通信的重要基礎設施之一。
HSM對于完全的安全車載通信（Secure Onboard Communication，SecOC）是必不可少的。HSM能確保所接收到的數據的真實性，防止攻擊者繞過相關的安全接口，入侵車載網絡。
基于硬件的安全模塊主要解決兩個問題：
-
密鑰泄漏問題：如果密鑰存儲在應用程序的代碼或數據中，很容易被泄漏。所以有必要增加一個硬件模塊，專門存儲密鑰。
-
Crypto算法加速：通過內核來直接進行加密或解密運算會占用大量CPU算力資源。因此，有必要通過硬件模塊來進行加密解密算法的加速。
SHE（Secure Hardware Extension）標準是由奧迪和寶馬公司合作制定的、針對硬件安全模塊HSM的規范，它主要包括密碼模塊的硬件、硬件軟件接口。這個規范已被廣泛接受，很多針對汽車行業的微處理器都支持這個規范。
3.8 面向服務的軟件架構SOA
ECU原先運行的軟件大多數是按照Classic AutoSAR規范開發的軟件系統，其中的應用軟件一般都是靜態調度（Static Scheduling）模式的，也即在系統運行時，程序中不同功能的函數按照事先定義好的排序文件依次調用、逐個運行。靜態調度的優點是資源分配問題都是事先安排好的，車輛量產后就不會再改變，每個功能對應的函數代碼具體運行時間也被提前鎖定，是確定性的。因此這種設計對于汽車上很多對功能安全要求苛刻的場景是非常適合的。比如：決定安全氣囊是否打開的功能函數就是固定地每隔幾毫秒運行一次，以便緊急情況下可以及時打開。
承載計算和控制的底層硬件從分散的多個ECU集中到多核、異構的高性能域主控處理器后，相應的軟件也會從分散向集中、從簡單向復雜、從靜態向動態進化。下圖2-7顯示了以后汽車域控制器上的典型軟件架構：
圖2-7 域控制器上基于空分虛擬化技術的典型軟件架構
- 操作系統層：最底層利用Hypervisor虛擬化技術對硬件資源進行分區(partition)，從而可以在每個虛機運行不同的操作系統。比如在上圖中，虛機VM1中運行兼容POSIX實時操作系統標準（比如PSE 52）的RTOS，RTOS上通常要承載功能安全相關的應用和服務；虛機VM2中運行Linux這種完全POSIX標準的分時操作系統，上面通常運行管理相關的功能和服務；虛機VM3中運行的可能是原來在ECU上運行的Legacy應用。
- 中間件層：操作系統是不做任何與“車”特定相關工作的。為了讓域主控處理器在汽車場景下使用，需要有很多軟件或者中間件用于讓域控制器滿足汽車的電源管理標準、網絡管理標準以及診斷標準等；車載域控制器需要比一般工業嵌入式系統有更高的可靠性要求，這樣就需要在計算機OS基礎上再附加對存儲和通訊等各方面的安全保護和容錯機制；同時，位了讓車載域控制器能夠在整車EE架構下運行，還需要提供時鐘同步、日志跟蹤以及服務管理和發現等功能。Adaptive AutoSAR規范定義了運行在Linux或者完全兼容POSIX 1003.1標準RTOS上的這一層與“車”相關的中間件標準；而傳統運行在POSIX子集的RTOS或者BareMetal模式的中間件規范則由Classic AutoSAR標準定義。
- 應用層：上層應用基于AutoSAR標準的中間件來進行開發。隨著汽車智能化和網聯化相關的功能越來多，上層應用軟件也越來越復雜。位了降低單個應用的整體復雜性，我們可以借鑒互聯網的面向服務架構（SOA）的軟件設計思想，將一個復雜應用拆分多個服務。每個服務實現得盡可能小，盡量實現成無狀態方式的服務，以利于整個系統的開發、測試和軟件重用。服務與服務之間通過事件或者消息總線（發布/訂閱工作模式）來進行通信，并降低互相之間的耦合度。通過服務配置來管理服務之間的依賴性、服務的部署和啟動，以及服務的健康狀態檢測等。
汽車以太網給車載系統通信帶來一個革命性的變化，在中央計算式汽車EE架構下，整個車載系統可以被看作是一個分布式網絡系統：中央計算平臺是一個小型服務器集群，區域計算平臺是邊緣計算節點。在互聯網或者大型分布式系統中，SOA架構設計理念已經被廣泛使用了。因此當IP網絡技術被廣泛應用于汽車后，很多在互聯網或者分布式計算中已經很成熟的軟件技術，自然會被借鑒到新的汽車軟件架構設計中來，比如：RPC技術、事件/消息總線、RESTful API設計等。
大型互聯網數據中心中的服務器集群動輒幾百、上千臺服務器，每秒百萬、千萬級別的并發。車載系統盡管可以被看作是一個分布式網絡系統，但是它卻沒有互聯網大型服務器系統的高并發特征，相反，它更注重通信的實時性和可靠性。
車載系統在物理上是向集中式發展的，也就是原來通過多個分散ECU來實現的功能，漸漸集中到幾個主要的高性能域控制器上。因此，盡管在軟件設計上，我們會盡量按照SOA的思路拆分成一個一個小的服務，但是這些服務在部署上其實是集中式的。鑒于這種物理部署上的“集中”與運行時的“分布式”并存的特點，因此我們可以通過一系列技術手段來優化服務與服務之間的通信延遲（比如：通過共享內存技術）。這是車載分布式系統與互聯網強調高并發特性的分布式系統之間另一個顯著的差別。
4.
小結
域集中式EE架構會是未來相當長一段時間占主要地位的汽車EE架構，域控制器作為域集中式EE架構的核心，會在整個汽車產業鏈中占據越來越重要的地位。其相應的芯片和硬件方案、操作系統和算法等將會成為整個產業鏈各上下游廠家的爭奪焦點。
轉自汽車ECU開發
