汽車智能座艙軟件架構(gòu)

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

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

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

汽車電子電器架構(gòu)演變

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

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

電子電器架構(gòu)定義

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

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

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

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

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

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

中央化架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

智能座艙域

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

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

娛樂功能域?qū)?shí)時(shí)性和可靠性并沒有高的要求，要求高主要是娛樂生態(tài)的豐富性，主流選用的都是Android Autotive OS，因?yàn)槟壳癆ndroid生態(tài)非常的豐富。

智能座艙軟件架構(gòu)

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

Hpervisor Architecture

使用Hypervisor技術(shù)對(duì)硬件虛擬化搭建起來，主要有下面兩種軟件架構(gòu)：

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

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

系統(tǒng)軟件層級(jí)架構(gòu)

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

Android Automotive OS為guest OS，

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

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

Android特別解釋：

Native Service：主要包含system分區(qū)除了framework 核心服務(wù)之外的一些外設(shè)服務(wù)，比如MDNSD（Multicast DNS daemon）、logcat、ADBD、Iptable、Radio Service、Factory Reset。還有和Vendor廠商相關(guān)的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，這都是標(biāo)準(zhǔn)組件。

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

QNX特別解釋：

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

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

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

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

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

未來軟件架構(gòu)猜想

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

主要原因我認(rèn)為主要是：

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

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

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

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

車控功能域總體架構(gòu)

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

總體軟件架構(gòu)圖如下：

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

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

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

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

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

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

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

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

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

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

參考文章

4W字一文帶你看懂 智能座艙域控制 主流芯片及平臺(tái)架構(gòu)

智能座艙與芯片

汽車CEM模塊是什么

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

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

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