多任務協(xié)同的車載電源管理系統(tǒng)研究

華春夢，臧艷輝，肖志良

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

0 引 言

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

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

1 系統(tǒng)分析

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

2 系統(tǒng)設計

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

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

車載系統(tǒng)的硬件由MCU+SOC構成，其中MCU主要負責車身CAN信號的收發(fā)，同時MCU又與SOC通過SPI總線建立連接，這樣車身信號可以通過MCU通知SOC，而SOC也可以將車身的控制信號通過MCU轉發(fā)給CAN。軟件設計方面，SOC采用Android操作系統(tǒng)，而Android又是以Linux為底層，所以此系統(tǒng)可以支撐起HMI以及硬件驅動。

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

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

圖2 Binder IPC通信序列

圖3 開機動畫的修改點

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

3.1 開機動畫

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

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

3.2 按鍵事件

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

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

3.3 Audio

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

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

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

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

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

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

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

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

（3）對音頻焦點（AudioFocus）做適當?shù)膿屨寂c釋放，適配車載的Power按鍵功能。

3.4 CAN總線及實車測試

通過模塊CAN電源管理信號和實車環(huán)境，對上述方案做綜合測試，實驗結果表明，開機動畫和按鍵的實現(xiàn)較為完整，因為這兩個模塊的功能測試用例較為直接，但是車載IVI的音源遠多于原生Android，所以僅對常用的主流音源做交互測試，實驗結果同樣達到了預期目標。

4 結 語

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

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

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