華春夢(mèng)，臧艷輝，肖志良

（佛山職業(yè)技術(shù)學(xué)院，廣東 佛山 528137）

0 引 言

車載信息娛樂(lè)系統(tǒng)（In-Vehicle- Infotainment, IVI），是基于整車CAN總線、ECU控制單元以及HMI人機(jī)交互界面的系統(tǒng)，包含儀表、空調(diào)和中控面板。信息化帶動(dòng)了智能化，智能化催動(dòng)IVI的變遷。從20世紀(jì)90年代的WinCE操作系統(tǒng)到Linux操作系統(tǒng)，再到當(dāng)下開(kāi)源的Android操作系統(tǒng)，車載系統(tǒng)也變得越來(lái)越智能、便捷。但是，由于Android系統(tǒng)復(fù)雜且龐大，故目前與之相關(guān)的電源管理邏輯多集中于底層操作。

本文通過(guò)對(duì)Android系統(tǒng)的研究與分析，基于原車底層電源管理邏輯，提出了一種與之相對(duì)應(yīng)的多任務(wù)協(xié)同方案，本方案包括開(kāi)機(jī)動(dòng)畫(huà)的時(shí)序、按鍵輸入的特殊處理以及聲音系統(tǒng)的協(xié)同，一定程度上加速了車聯(lián)網(wǎng)產(chǎn)業(yè)的發(fā)展。

1 系統(tǒng)分析

由于車載系統(tǒng)的特殊性，導(dǎo)致其與原生的Android系統(tǒng)存在明顯差異。首先，開(kāi)機(jī)動(dòng)畫(huà)要與車身的啟動(dòng)信號(hào)進(jìn)行綁定，不再遵循Android原生的啟動(dòng)流程；其次，Android系統(tǒng)為了個(gè)人隱私和手機(jī)的功耗考慮，會(huì)自動(dòng)鎖屏和休眠，但車載娛樂(lè)系統(tǒng)是伴隨車身的工作持續(xù)運(yùn)作，不存在自動(dòng)休眠和鎖屏功能；最后，按鍵功能定制，以Power按鍵舉例，傳統(tǒng)Android Mobile，長(zhǎng)按Power鍵為重啟，短按為鎖屏，而車載最常見(jiàn)的短按為顯示時(shí)鐘界面，長(zhǎng)按則可以是非重啟的其他模式。綜合來(lái)說(shuō)，由于智能座艙IVI的特殊性，本方案引入的修改點(diǎn)包括：系統(tǒng)開(kāi)機(jī)動(dòng)畫(huà)時(shí)序的調(diào)整策略，按鍵事件的響應(yīng)策略以及系統(tǒng)聲音的邏輯管理。

2 系統(tǒng)設(shè)計(jì)

Android是以Linux內(nèi)核為基礎(chǔ)，由硬件抽象層（Hardware Abstract Layer--HAL）承接，再輔之各種系統(tǒng)服務(wù)構(gòu)建起來(lái)的，所以要適配電源管理協(xié)同模塊，進(jìn)行自下而上的全局分析。本文以車載系統(tǒng)的CAN總線通信為核心，將系統(tǒng)啟動(dòng)流程、輸入子系統(tǒng)和聲音輸出子系統(tǒng)作為出發(fā)點(diǎn)，圍繞圖1所示的內(nèi)容進(jìn)行系統(tǒng)關(guān)鍵模塊的設(shè)計(jì)。

圖1 多任務(wù)協(xié)同的車載電源管理系統(tǒng)整體設(shè)計(jì)

車載系統(tǒng)的硬件由MCU+SOC構(gòu)成，其中MCU主要負(fù)責(zé)車身CAN信號(hào)的收發(fā)，同時(shí)MCU又與SOC通過(guò)SPI總線建立連接，這樣車身信號(hào)可以通過(guò)MCU通知SOC，而SOC也可以將車身的控制信號(hào)通過(guò)MCU轉(zhuǎn)發(fā)給CAN。軟件設(shè)計(jì)方面，SOC采用Android操作系統(tǒng)，而Android又是以Linux為底層，所以此系統(tǒng)可以支撐起HMI以及硬件驅(qū)動(dòng)。

3 系統(tǒng)實(shí)現(xiàn)及測(cè)試

修改原生Android系統(tǒng)，通過(guò)Binder IPC進(jìn)程間通信，便于獲取其他各項(xiàng)服務(wù)，并回饋電源管理的信號(hào)。Binder IPC是基于內(nèi)存映射（mmap）實(shí)現(xiàn)的C/S軟件構(gòu)架，其客戶端與服務(wù)端通過(guò)Binder驅(qū)動(dòng)進(jìn)行數(shù)據(jù)交互?？蛻舳诉M(jìn)程和服務(wù)端進(jìn)程通過(guò)Binder驅(qū)動(dòng)進(jìn)行橋接，其進(jìn)程間的通信序列如圖2所示，開(kāi)機(jī)動(dòng)畫(huà)的修改點(diǎn)如圖3所示。

圖2 Binder IPC通信序列

圖3 開(kāi)機(jī)動(dòng)畫(huà)的修改點(diǎn)

基于以上論述，我們需要向Android的服務(wù)管理中心（Service Manager）注冊(cè)新系統(tǒng)服務(wù)，用以處理MCU上報(bào)的CAN報(bào)文，而其他進(jìn)程可以訂閱感興趣的CAN報(bào)文，比如本文重點(diǎn)關(guān)注的電源管理信號(hào)等。

3.1 開(kāi)機(jī)動(dòng)畫(huà)

車載系統(tǒng)的特殊性決定了開(kāi)機(jī)動(dòng)畫(huà)不能像傳統(tǒng)手機(jī)一樣，而是需要等待ACC ON（點(diǎn)火）信號(hào)觸發(fā)后才能執(zhí)行，故需要對(duì)BootAnimation（開(kāi)機(jī)動(dòng)畫(huà)）時(shí)序做圖3所示的定制修改。第一：屏蔽原生的啟動(dòng)時(shí)序；第二：在新增的讀寫CAN信號(hào)進(jìn)程中，等待車輛ACC ON點(diǎn)火信號(hào)觸發(fā)后再執(zhí)行。此舉可滿足車載系統(tǒng)對(duì)開(kāi)機(jī)動(dòng)畫(huà)的特殊要求。

圖4 車載按鍵事件處理流程

3.2 按鍵事件

車載系統(tǒng)按鍵分為兩種：一種是來(lái)自于方向盤的線控，另一種是來(lái)自中控觸摸屏的按鍵。前者由MCU控制，后者來(lái)自Linux的觸摸中斷。本文所提出的按鍵管理方案如圖4所示，其中面板的按鍵元素沿著Linux路徑，經(jīng)事件總線上報(bào)給Framework層，而來(lái)自MCU的按鍵則會(huì)跳過(guò)Linux，直接轉(zhuǎn)為Android的Input事件供Framework層讀取，這樣二者都由輸入管理服務(wù)IMS（Input Manager Service,IMS）傳輸?shù)酱绑w管理服務(wù)WMS（Window Manager Service,WMS）中處理。在WMS中，可以由WindowPolicyManager的實(shí)現(xiàn)類PhoneWindow-Manager統(tǒng)一決策進(jìn)行預(yù)處理，實(shí)現(xiàn)對(duì)兩種類型按鍵事件的統(tǒng)一操作和攔截。

以某汽車廠家的真實(shí)需求為例，正常情況下，短按Power按鍵，需要全屏顯示時(shí)鐘界面，在時(shí)鐘界面下再短按Power，則退出時(shí)鐘界面。但是在ACC OFF車輛熄火情況下，短按Power按鍵，可以使用戶進(jìn)入一小時(shí)模式，即車輛熄火，用戶依然可以正常體驗(yàn)中控娛樂(lè)系統(tǒng)的音樂(lè)和收音功能，在一小時(shí)模式未結(jié)束時(shí)再點(diǎn)擊Power按鍵，則會(huì)關(guān)閉一小時(shí)功能。特殊情況下，還可以長(zhǎng)按Power 8 s，重啟系統(tǒng)。其他要求，例如在某些場(chǎng)景下（比如倒車過(guò)程中）拒絕按鍵的響應(yīng)?；谏弦蕴厥獾陌存I需求，本文在梳理了Android輸入子系統(tǒng)的事件流程后，提出了車載系統(tǒng)硬按鍵和面板按鍵的統(tǒng)一預(yù)處理及攔截分發(fā)方案，可以實(shí)現(xiàn)特殊按鍵的處理。

3.3 Audio

Google在2018年專為車載系統(tǒng)發(fā)布了Android O Car，引入Car-Service中間件來(lái)管理外設(shè)和音頻邏輯。從官方發(fā)布的汽車音頻架構(gòu)圖不難看出，此設(shè)計(jì)是以聲音流為中心而設(shè)計(jì)，如圖5（a）所示。系統(tǒng)將媒體播放、導(dǎo)航聲音、收音機(jī)的聲音統(tǒng)一作為邏輯聲音流，送入AudioFlinger中做混音合成，最終再以總線尋址的方式找到對(duì)應(yīng)的聲卡設(shè)備進(jìn)行輸出。按照官方的Porting（移植）步驟，主要做如下3點(diǎn)的適配：

圖5 Android車載系統(tǒng)音頻交互方案

（1）. devicePorts：包含可從模塊訪問(wèn)的輸入輸出設(shè)備（包括永久連接和可移除設(shè)備）的描述序列表；

（2）. mixPorts：包含由音頻HAL提供的所有輸入和輸出聲音流列表；

（3）. routes：定義輸入和輸出設(shè)備或聲音流與設(shè)備之間可能存在的連接列表。

除此之外，相比原生Android音頻，IVI系統(tǒng)擁有更多的音源類型。除AudioFocus之外，還存在其他音源間的混音和衰減等需求?？紤]車載電源管理的特殊性，我們還要結(jié)合電源管理對(duì)車載音頻做如圖5（b）所示的補(bǔ)充。

（1）新增音源持久化記憶模塊，使車載娛樂(lè)系統(tǒng)在斷電及重新啟動(dòng)后，可以恢復(fù)上次正在使用的音源；

（2）在聲音的流類型上，加入優(yōu)先級(jí)矩陣管理，用以協(xié)同導(dǎo)航、收音、電話、媒體間的交互。

（3）對(duì)音頻焦點(diǎn)（AudioFocus）做適當(dāng)?shù)膿屨寂c釋放，適配車載的Power按鍵功能。

3.4 CAN總線及實(shí)車測(cè)試

通過(guò)模塊CAN電源管理信號(hào)和實(shí)車環(huán)境，對(duì)上述方案做綜合測(cè)試，實(shí)驗(yàn)結(jié)果表明，開(kāi)機(jī)動(dòng)畫(huà)和按鍵的實(shí)現(xiàn)較為完整，因?yàn)檫@兩個(gè)模塊的功能測(cè)試用例較為直接，但是車載IVI的音源遠(yuǎn)多于原生Android，所以僅對(duì)常用的主流音源做交互測(cè)試，實(shí)驗(yàn)結(jié)果同樣達(dá)到了預(yù)期目標(biāo)。

4 結(jié) 語(yǔ)

本文提出了一種多任務(wù)協(xié)同的車載電源管理系統(tǒng)，將車身CAN信號(hào)中的電源管理引入Android系統(tǒng)，研究并給出與此相關(guān)的三大核心模塊（開(kāi)機(jī)動(dòng)畫(huà)、用戶按鍵輸入以及聲音的輸出）的協(xié)同控制策略，本方案可適應(yīng)車載中控娛樂(lè)系統(tǒng)的不同場(chǎng)景。略顯不足之處是系統(tǒng)的耦合性較強(qiáng)，修改難度大，所以有兩條建議可持續(xù)深入研究：

（1）以CarService服務(wù)為核心，對(duì)各模塊進(jìn)行解耦，提升系統(tǒng)整體的穩(wěn)定性；

（2）遵循Android Project Treble，使更多的制造商以更低的成本接入，并完成系統(tǒng)的升級(jí)迭代。