汽車智能座艙軟件架構

智能座艙域控制器目前承載信息娛樂系統(tǒng)、導航系統(tǒng)、駕駛員輔助系統(tǒng)、車輛監(jiān)控和控制、安全系統(tǒng)等各種功能。

這篇博客主要是對座艙域控制器基于QNX、Android Automtive OS軟件架構做一個大致的介紹，如果想要更寬維度的了解，可以看第一篇參考文獻，我覺得寫得很好。

開篇從汽車電子電器架構的演變來講解為什么會出現(xiàn)智能座艙域控制器。最后我會描述和預測一下未來汽車域控制器軟件架構會是怎么樣的，以及傳統(tǒng)軟件架構和AI時代會有怎樣的技術融合。歡迎大家留言探討！

汽車電子電器架構演變

最早汽車中MCU都是相互相連接，互相傳遞信息，隨著MCU增多，各個MCU之間傳遞的信息增多，會導致系統(tǒng)特別的復雜，汽車電子電器架構幾乎無法發(fā)展下去。

這個時候CAN通信問世了，CAN通信確實是一個非常偉大的發(fā)明，是汽車電子電器架構發(fā)展的轉折點，核心就是CAN總線實現(xiàn)各個MCU之間的鏈接，各個MCU和CAN總線鏈接傳遞信息，不在各個ECU之間相互鏈接傳遞信息，這里也注定CAN總線是以總線信號為核心進行處理傳輸。

電子電器架構定義

汽車電子電氣架構，是指集合汽車的電子電氣系統(tǒng)原理設計、中央電器的設計、連接器的設計、電子電氣分配系統(tǒng)等一體的整車電子電器解決方案的概念。在2007年，德爾福首次提出 E/E 架構的概念，對發(fā)動機系統(tǒng)、車窗控制、車載娛樂系統(tǒng)等一切需要電力控制的軟硬件進行系統(tǒng)設計和不斷優(yōu)化。

現(xiàn)代化E/E架構

博世于2017年提出了新的電氣架構演化圖，整車的架構將從離散的分布式架構逐步集成為幾個域控制器。這種集成式的架構方案發(fā)展又來到一個轉折點的變化，整車電子電器架構演進趨勢如下圖所示：

目前在24年底基本上主流主機廠都完成域控制器架構的開發(fā)與發(fā)布，在往中央化計算架構發(fā)展。

域控制器架構主要分為幾大域控制器：動力域、底盤域、車身域、座艙域和自動駕駛域。這篇博客主要介紹智能座艙域控制器軟件架構。

但是由于中央化架構馬上已經(jīng)要到來了，這里簡單介紹主要的幾種形式和演進趨勢。

中央化架構

中體上分為三個階段：

第一階段：One Box，也就是每個域控制器單獨一塊電路板，板間通過Ethernet傳輸數(shù)據(jù)，傳輸速率大概在125MB/s。

第二階段：One Broad，每個域控制芯片都在一塊板子上面，之間通過PCIE接口傳輸數(shù)據(jù)，PCIE 4.0 x4速率可以達到8GB/s，速度比高速Ethernet提升64倍，效率大大提升。并且這個階段Body Control Domain應該可以融合到Cockpit Domain，目前定義的BC Domain主要是外置功放和CDM（Control Dignose Center），最多在加上以S32G芯片為代表的中央網(wǎng)關。以后Cockpit Chip ADSP功能強大之后可以不要外置功放，并且CDM功能可以整合到Cockpit chip中，畢竟UDS（Unified Diagnostic Services）本人認為是以座艙域控為控制中心。目前的中央計算中心要交換大量的數(shù)據(jù)，很可能S32G中央網(wǎng)關芯片還是外掛，提供為Cockpit 和ADAS Chip訪問聯(lián)網(wǎng)數(shù)據(jù)。

第三階段：One Chip，每個域控制器的功能做到整個SOC中作為一個IP core，之間通信方式為片內通信，這個速度有多快呢？可以參考M4 芯片內存帶寬可以達到120Gb/s，速率提升15倍。

目前主流主機廠One Box方案已經(jīng)上車，主要都在研發(fā)One broad方案，或者直接過渡到One Chip方案。

在域融合的過程中最主要的就是數(shù)據(jù)共享、硬件共享。

在這里我可以舉個例子給大家思考：ADAS 感知數(shù)據(jù)產(chǎn)生是存在ADAS Domain，但是繪制顯示是在Cockpit Domain，這就需要把數(shù)據(jù)跨域發(fā)送。如果是分布式域控制器架構，一般的感知數(shù)據(jù)幀率是在10Hz左右，這個幀率人眼還是明顯發(fā)現(xiàn)有卡頓，受限與Ethernet帶寬，不可能把幀率做得太高。但是如果在One Broad架構方案下，可以很輕松的做到30Hz以上，顯示數(shù)據(jù)會非常流暢。

但是如果是One Chip方案，這種數(shù)據(jù)場景完全不夠發(fā)揮這么高帶寬的價值，我認為最高的價值應該在硬件共享，使用Hpervisor 技術對CPU、GPU、DSP等硬件虛擬化，讓Cockpit and ADAS Domain都可以訪問硬件資源。

目前大模型在座艙和自動駕駛域都特別火，并且都在車端部署大模型階段，我認為以后得趨勢一定是共享大模型域資源，架構圖如下：

大模型域獨立于其他兩個域，并且可以讓Large Model 通過Hypervisor給Cockpit和ADAS Domain提供AI能力，給座艙提供語音大模型，給ADAS Domain提供End To End Large Model能力。

這樣可以更好的利用One Chip高帶寬能力，讓所有軟件域共享數(shù)據(jù)和算力。

這里可以看到目前中間架構下是沒有底盤域和動力域控制器的，因為這兩個域控制器技術相對都比較封閉。特別是底盤域，目前都是使用Bosch EMB為代表的One box系統(tǒng)，這套系統(tǒng)的算法和控制單元Bosch都是沒有開放出來的，也是統(tǒng)一一個模組來賣，所以目前這種技術方案是沒有辦法集成到中央控制中心。

智能座艙域

智能座艙域有兩大功能，其中一個是In Vehicle Information娛樂功能域，第二個是儀表顯示功能域。

最早這兩個功能模塊是兩顆芯片在同一塊電路板子，因為這兩個功能域所要求的功能完全不同。對于儀表顯示功能域最重要的點就是實時性、可靠性，所以對其特點就開發(fā)對應的實時操作系統(tǒng)。

娛樂功能域對實時性和可靠性并沒有高的要求，要求高主要是娛樂生態(tài)的豐富性，主流選用的都是Android Autotive OS，因為目前Android生態(tài)非常的豐富。

智能座艙軟件架構

隨著芯片算力能力增強，這兩個功能域融合為一顆芯片，但是這個功能域還是區(qū)分為兩個操作系統(tǒng)，怎么把兩個OS跑在同一顆芯片上？這就需要Hypervisor Technology。

Hpervisor Architecture

使用Hypervisor技術對硬件虛擬化搭建起來，主要有下面兩種軟件架構：

這兩種Hypervisor Type不同點就在于Type2中，Host OS 和 Hypervisor 是一個系統(tǒng)，比如Qualcomm 方案中QNX使用GVM 進程作為Hypervisor功能運行Android Automotive OS。而Type1中Hypervisor 相對于Host OS是兩個獨立的系統(tǒng)。

目前域控制器方案中MCU都是單獨的芯片，所以單獨羅列出來。

系統(tǒng)軟件層級架構

本人主要是基于Qualcomm 平臺軟件架構開發(fā)，Qualcomm 平臺是以QNX為Host OS，并且其中包含Hypervisor 功能，Type 2軟件架構方案。

Android Automotive OS為guest OS，

對Type 2軟件架構分級進一步詳細，再加上MCU 軟件部分。

先從SOC部分開始介紹，QNX啟動GVM進程加載Android，Android主要分為APP、Framework、Native service、HAL 、BSP layer。

Android特別解釋：

Native Service：主要包含system分區(qū)除了framework 核心服務之外的一些外設服務，比如MDNSD（Multicast DNS daemon）、logcat、ADBD、Iptable、Radio Service、Factory Reset。還有和Vendor廠商相關的Native Service，比如：Thermal Engine、CNSS（Compass Navigation Satellite System）-Daemon、Power Daemon 、IPACM（IP Access Control Manager）。

Extend Service：主要是Vendor 廠商定制化的system Service，比如Speech Service、OMS（Occupation Monitor Service）、Car Audio Service。

Android Runtime：Ueventd 、VOLD、LMKD、 Tombstone、Zygote、Service Manager，這都是標準組件。

IPC OS：這個都是主機廠為了SOA Service所使用的模塊，Android OS可以直接和外域OS通信。

QNX特別解釋：

Infrastructure Service：在QNX系統(tǒng)中提供核心服務的模塊：收集QNX Log Service（一般會同時收集MCU log，然后通過UFS映射到Android 分區(qū)，直接通過ADB就可以查看，非常方便，不是需要通過MCU廠商提供的軟件來導出MCU Log，很麻煩）、管理QNX power Service、接收Android系統(tǒng)界面信號vehicle Signal Service、接收整車車控信號的IPC Service、OMS、DMS、管理CSD屏幕和儀表屏幕的Display Service。

Cluster Service：主要是為儀控HMI APP提供基礎服務能力，比如：接收IPC Service發(fā)送過來的車控信號，在儀表界面顯示的各種狀態(tài)燈提供處理分析邏輯；在多屏互動過程中提取Android map的圖像數(shù)據(jù)和設置顯示圖層的基礎Service；接收ADAS傳輸過來的自動駕駛感知數(shù)據(jù)Service。

APP：主要指HMI 模塊，這個layer一般都會使用Unity或者Unreal Engine提供的解決方案和產(chǎn)品，讓儀表屏幕能夠顯示各種圖像和數(shù)據(jù)。再包括一些數(shù)據(jù)消息緩存隊列

MCU軟件架構主要是以AUTOSAR為標準進行搭建的，主要是處理總線信號的功能（包括各種車控信號和整車電源信號），主機廠能夠開發(fā)的應該是SWC Layer，其他部分都是買的定制化AUTOSAR系統(tǒng)組件。

AUTOSAR（Automotive Open System Architecture）是一個全球性的汽車行業(yè)合作組織，同時也是一個開放的標準化軟件架構，旨在為汽車電子系統(tǒng)提供一個標準化的開發(fā)框架。框架就相當于是把接口定義好，但是實現(xiàn)是需要自己寫代碼的，所以主機廠的AUTOSAR都是買的供應商的。

未來軟件架構猜想

未來軟件架構本人認為，應該主要是往第一種方向發(fā)展，Qualcomm和NVIDIA已經(jīng)在這么做了。

主要原因我認為主要是：

第二種架構中Host OS會融合Hypervisor功能，所以當Host OS出現(xiàn)各種功能異常的情況，一定是會影響到Guest OS，兩個OS耦合性還是太高。

第一種架構只是比第二種架構在CPU loading角度多增加一個微內核，一個微內核的CPU loading只占一個大核loading的2%左右（主要是proc 進程），負載是非常低的，付出這一點點代價換來兩個操作系統(tǒng)解耦、不相互影響是非常劃算。

還有一個發(fā)展方向我個人認為會發(fā)生，就是把MCU芯片集成到SOC芯片中，作為一個獨立IP核。目前MCU單獨一顆芯片的核心原因是因為SOC Chip需要在整車下電的工況斷電，而MCU是一直正常低功耗運行，并且在車輛啟動過程中喚醒SOC。還有一個功能就是處理總線信號，接收車輛總線傳輸過來的信號，然后把總線信號（模擬信號）轉換之后轉發(fā)到SOC。

我本人認為這兩個功能作為獨立IP都可以實現(xiàn)，現(xiàn)在SOC可以對單獨一顆IP單獨供電，解決功耗問題。也可以添加一個ADC IP處理數(shù)模轉換問題，但是這樣高的集成度，也涉及到成本、研發(fā)投入、市場接受程度等各種問題。而且目前MCU主要使用Infineon的芯片，Qualcomm自己不知道有沒有MCU Chip，所以讓Qualcomm或者NVIDIA去把MCU功能集成到SOC 作為一顆獨立IP也是需要技術挑戰(zhàn)的。

車控功能域總體架構

座艙軟件架構中車控功能主要是接收各種車控信號，比如空調打開和設置溫度、座椅調整方位、整車燈光使用等各種車控相關的信號。車控系統(tǒng)的軟件架構我認為最能代表出智能座艙域控軟件架構的數(shù)據(jù)鏈路。

總體軟件架構圖如下：

以打開空調為例子介紹整個數(shù)據(jù)流程：

Air Condition APP會調用Car Service提供的API接口下發(fā)打開空調的指令。這個過程擴展說一點，一般的主機廠會在這里添加一個中轉進程Service。因為這樣可以讓APP Layer和HAL高度解耦。在實際的環(huán)境中只有Google定義的Vehicle property信號是遠遠不夠的，需要主機廠定義自己的Vehicle property ID。如果各種原因導致Property ID發(fā)生改變，這個時候APP是需要修改ID Number，但是APP眾多各個都去適配代價很大。所以一般會做一個中轉信號的進程Service，對Vehicle Property ID進行封裝為標準帶有特定含義的API提供給APP使用，這個時候ID Change只需要中間Service修改就可以，大大減少工作量。

CarService再把Vehicle Property通過HIDL接口傳遞到Vehicle HAL（Android 14之間都是使用HIDL，14之后全部替換為AIDL）。VehicleHALManger對信號的轉發(fā)進行權限校驗，SubscriptionManger對只有訂閱Vehicle Property信號服務的用戶端才會產(chǎn)生信號交互功能，這兩個功能組件都是Vehicle HAL中模塊。Vehicle HAL這個時候就需要跨域通信把信號發(fā)送到QNX，一般是選用SOME/IP或者FDBUS建立Client。

圖中CAN和POWER的意思代表：一般會把普通車控信號和POWER信號分別建立Client區(qū)分發(fā)送，因為普通車控信號和POWER信號在QNX是兩個Server來接收的。SOC POWER信號功能非常重要，會在QNX中開發(fā)Power Manager Service模塊對POWER狀態(tài)機進行管理，會把SOC各種Power電源狀態(tài)廣播到Cluster Layer、Infrastructure Layer、Android OS（通過Vehicle HAL）。

不知道大家這里是否有想到Vehicle HAL中的FDUBS 都是Client，卻Server都在QNX。因為核心服務的提供者都在QNX，通過QNX去管理Android狀態(tài)。所以兩個系統(tǒng)高度耦合依賴，一旦QNX狀態(tài)出現(xiàn)問題，Android 對整個SOC狀態(tài)的感知將全部失效。

Vehicle Signal Service接收到請求信號之后，也會通過FDBUS 把信號傳遞給一個IPC Service模塊。Vehicle Signal Service作為中間件模塊會提供Android界面下發(fā)信號聯(lián)動功能，如果空調功能打開的同時需要在儀表界面顯示一個通知，就會通過FDBUS發(fā)送消息到Cluster APP繪制圖標；如果需要Audio播放聲音，也是需要把信號發(fā)送到Audio module使其通過揚聲器播放出“打開空調”的聲音。并且控制信號需要記憶化存儲也是此模塊完成，比如空調溫度設置到20°C，下次空調打開就是上次設置的溫度，也是Vehicle Signal Service把信號值傳遞到Persistency Module寫入到Persistency分區(qū)，在SOC下次上電時從Persistency分區(qū)讀取恢復記憶。并且如果需要把Android傳遞過來的數(shù)據(jù)發(fā)送外域其他ECU，可以調用SOA Client發(fā)送信號值到其他SOA Server。

IPC Service模塊功能是把FDBUS數(shù)據(jù)序列化編碼為SPI格式化數(shù)據(jù)，通過SPI網(wǎng)絡節(jié)點傳輸?shù)組CU CAN Service組件中。在QNX中的其他模塊：AVM、Cluster Service、Audio、FOTA需要接收車控總線信號，都是從IPC Service模塊訂閱獲取。

MCU CAN Service接收到SPI傳輸過來的數(shù)據(jù)，也先要進行反序列化，再通過CAN / Flaxray / Ethernet等數(shù)據(jù)總線傳輸?shù)紺EM（Centrol Electronic Module），通過CEM再打開空調壓縮機。

到這個流程結束時候之后，會通過以上鏈路對設置的數(shù)據(jù)進行返回，讓鏈路中所有模塊對信號值進行確認，只有CEM返回正確的信號值才能代表整個鏈路打開空調的操作正確無誤。

Android 整車信號和整車總線信號主要的區(qū)別：一個是Android OS下發(fā)的信號，一個是從整車總線獲取的信號，信號方向和類型不一樣。一個是以Vehicle Property為標識，一個以信號為標識。

參考文章

4W字一文帶你看懂 智能座艙域控制 主流芯片及平臺架構

智能座艙與芯片

汽車CEM模塊是什么

————————————————

版權聲明：本文為博主原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權協(xié)議，轉載請附上原文出處鏈接和本聲明。 

原文鏈接：https://blog.csdn.net/chinamaoge/article/details/143466179