汽車(chē)智能座艙軟件架構

智能座艙域控制器目前承載信息娛樂(lè )系統、導航系統、駕駛員輔助系統、車(chē)輛監控和控制、安全系統等各種功能。

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

開(kāi)篇從汽車(chē)電子電器架構的演變來(lái)講解為什么會(huì )出現智能座艙域控制器。最后我會(huì )描述和預測一下未來(lái)汽車(chē)域控制器軟件架構會(huì )是怎么樣的，以及傳統軟件架構和AI時(shí)代會(huì )有怎樣的技術(shù)融合。歡迎大家留言探討！

汽車(chē)電子電器架構演變

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

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

電子電器架構定義

汽車(chē)電子電氣架構，是指集合汽車(chē)的電子電氣系統原理設計、中央電器的設計、連接器的設計、電子電氣分配系統等一體的整車(chē)電子電器解決方案的概念。在2007年，德?tīng)柛Ｊ状翁岢?E/E 架構的概念，對發(fā)動(dòng)機系統、車(chē)窗控制、車(chē)載娛樂(lè )系統等一切需要電力控制的軟硬件進(jìn)行系統設計和不斷優(yōu)化。

現代化E/E架構

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

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

域控制器架構主要分為幾大域控制器：動(dòng)力域、底盤(pán)域、車(chē)身域、座艙域和自動(dòng)駕駛域。這篇博客主要介紹智能座艙域控制器軟件架構。

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

中央化架構

中體上分為三個(gè)階段：

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

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

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

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

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

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

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

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

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

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

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

智能座艙域

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

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

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

智能座艙軟件架構

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

Hpervisor Architecture

使用Hypervisor技術(shù)對硬件虛擬化搭建起來(lái)，主要有下面兩種軟件架構：

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

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

系統軟件層級架構

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

Android Automotive OS為guest OS，

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

先從SOC部分開(kāi)始介紹，QNX啟動(dòng)GVM進(jìn)程加載Android，Android主要分為APP、Framework、Native service、HAL 、BSP layer。

Android特別解釋?zhuān)?/p>

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

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

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

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

QNX特別解釋?zhuān)?/p>

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

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

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

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

AUTOSAR（Automotive Open System Architecture）是一個(gè)全球性的汽車(chē)行業(yè)合作組織，同時(shí)也是一個(gè)開(kāi)放的標準化軟件架構，旨在為汽車(chē)電子系統提供一個(gè)標準化的開(kāi)發(fā)框架?？蚣芫拖喈斢谑前呀涌诙x好，但是實(shí)現是需要自己寫(xiě)代碼的，所以主機廠(chǎng)的AUTOSAR都是買(mǎi)的供應商的。

未來(lái)軟件架構猜想

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

主要原因我認為主要是：

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

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

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

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

車(chē)控功能域總體架構

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

總體軟件架構圖如下：

以打開(kāi)空調為例子介紹整個(gè)數據流程：

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

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

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

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

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

IPC Service模塊功能是把FDBUS數據序列化編碼為SPI格式化數據，通過(guò)SPI網(wǎng)絡(luò )節點(diǎn)傳輸到MCU CAN Service組件中。在QNX中的其他模塊：AVM、Cluster Service、Audio、FOTA需要接收車(chē)控總線(xiàn)信號，都是從IPC Service模塊訂閱獲取。

MCU CAN Service接收到SPI傳輸過(guò)來(lái)的數據，也先要進(jìn)行反序列化，再通過(guò)CAN / Flaxray / Ethernet等數據總線(xiàn)傳輸到CEM（Centrol Electronic Module），通過(guò)CEM再打開(kāi)空調壓縮機。

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

Android 整車(chē)信號和整車(chē)總線(xiàn)信號主要的區別：一個(gè)是Android OS下發(fā)的信號，一個(gè)是從整車(chē)總線(xiàn)獲取的信號，信號方向和類(lèi)型不一樣。一個(gè)是以Vehicle Property為標識，一個(gè)以信號為標識。

參考文章

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

智能座艙與芯片

汽車(chē)CEM模塊是什么

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

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

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