車載信息娛樂系統(tǒng)開發(fā)模式現(xiàn)狀與未來趨勢分析

朱芙蓉，劉 敏，秦文貞

（1.江西五十鈴汽車有限公司，江西 南昌 330104；2.南昌航空大學，江西 南昌 330063）

車載信息娛樂系統(tǒng)（以下簡稱車機）是車輛的綜合信息處理系統(tǒng)，承擔著座艙娛樂、通信、車身控制、輔助駕駛、保證行車安全等重要功能。隨著信息技術(shù)、車聯(lián)網(wǎng)技術(shù)、5G技術(shù)、人工智能技術(shù)、自動駕駛技術(shù)的發(fā)展，車機開始向集成化和智能化發(fā)展［1］。車機的功能越來越趨于復雜，開發(fā)難度越來越大，也隨著市場的培育，用戶對車機系統(tǒng)的功能及交互要求也越來越高、對穩(wěn)定性的要求也越來越高。因此，對于車機系統(tǒng)研發(fā)設(shè)計提出了更大的挑戰(zhàn)。

本文通過分析目前車機開發(fā)的行業(yè)現(xiàn)狀、存在的問題，調(diào)研目前原始設(shè)備制造商（OEM）、Tier1車機的開發(fā)模式偏好、OEM軟硬件開發(fā)現(xiàn)狀，并分析了車機的開發(fā)發(fā)展趨勢。

1 車機的開發(fā)發(fā)展現(xiàn)狀

系統(tǒng)軟件方案商有一套基本的工程代碼框架，此工程框架一般由平臺芯片廠商提供，為了快速開發(fā)項目，項目都在此基本框架上建立軟件分支副本，在此分支副本做增刪改，在功能上做兼容，從此形成一個新的項目。也有的項目是在前期開發(fā)的類似項目上，建立副本分支，針對需求差異點，對新項目進行定制化開發(fā)。此為系統(tǒng)軟件方案商進行新項目開發(fā)的基本模式。目前這種開發(fā)模式，存在以下不足。

1）開發(fā)到后期，代碼功能越來越多，復雜度越來越高，代碼容量越來越大，邏輯越來越雜亂，一套Android代碼能達到60GB以上。如果測試不充分，就很容易導致經(jīng)常出現(xiàn)很低級的軟件bug流到OEM。

2）后期的開發(fā)人員初期都是參考以往同事的設(shè)計方式、邏輯、架構(gòu)、或是在前人的基礎(chǔ)上做些優(yōu)化，導致軟件設(shè)計、架構(gòu)設(shè)計不清晰，風格不統(tǒng)一，特別是涉及到具體業(yè)務(wù)邏輯的應用層模塊。對人員變動后，后續(xù)接手人員交接難度大，交接耗時，交接品質(zhì)低。

3）方案公司一般進出人流量大，甚至除核心、骨干外，整個開發(fā)團隊人員都會更新，這就加速了第二點的不足。且難以形成技術(shù)沉淀，對OS的定制開發(fā)能力、BSP的裁剪能力欠缺。

4）方案公司對核心板的軟件管理，特別是對BSP，為了減少對不同的項目開發(fā)的移植難度，BSP功能大多采用兼容開發(fā)的模式，導致BSP龐大，OS運行卡頓、不流暢，軟件效率低，硬件利用率低。

5）方案公司對APP應用的開發(fā)，為了提高項目的實現(xiàn)效率，往往是針對不同客戶的差異化需求，在前期的工程上做修改，這樣容易出現(xiàn)定制化開發(fā)不徹底，APP應用容易出現(xiàn)邏輯上的混亂。

2 車機開發(fā)模式偏好

為解決此前開發(fā)模式的不足，研究技術(shù)人員開展了大量的工作。經(jīng)過調(diào)研，目前市場上，造車新勢力比較偏好的車機開發(fā)模式。

1）車機硬件，由A供應商合作完成。其主要工作任務(wù)：硬件設(shè)計、硬件功能驗證、硬件可靠性保證、硬件DVP實驗、貼片生產(chǎn)、軟件燒錄、組裝生產(chǎn)、整機功能測試、出貨。

2）車機軟件OS移植適配由B供應商完成或者也可由A供應商完成，OS移植需要根據(jù)需求適配硬件，對BSP進行定制開發(fā)，對OS進行深度裁剪，優(yōu)化OS穩(wěn)定性，刪除無用的OS功能和模塊，提升OS開機時間。此需要與A供應商緊密配合。

3）車機應用層軟件，由C供應商完成，也可拆分委托多家合作完成。應用層分為各個模塊或是各個APK，主要針對各個功能應用，例如AVM、APA、設(shè)置、電話、媒體、商城、自動駕駛、車聯(lián)網(wǎng)車機端APP等，此需要與A、B供應商以及對手件緊密配合。

4）車聯(lián)網(wǎng)部分由D供應商完成，目前此部分功能在車機中越來越重要，涉及到車機的智能化埋點，后臺云TSP服務(wù)的穩(wěn)定，以及后續(xù)AI算法的融入，考慮到后期連接數(shù)量越來越大，數(shù)據(jù)量越來越大，為減少切換供應商所帶來的數(shù)據(jù)遷移和方案修改所帶來的巨大成本，普遍趨于選一家技術(shù)穩(wěn)定可靠的供應商長期合作。

車機開發(fā)模式包含硬件和軟件，圖1是硬件的模塊開發(fā)組成和形式，圖2是軟件的分層模型［2-3］，圖3是Android系統(tǒng)的架構(gòu)分層模型。

圖1 硬件的模塊開發(fā)組成和形式

3 OEM車機軟硬件研究發(fā)展

目前OEM車機軟硬件主流開發(fā)方式有3種。

1）硬件電子開發(fā)模式是芯片平臺的SOC+外圍電路設(shè)計，此部分SOC為芯片原廠為方案公司提供基本一致的IC平臺+軟硬件基礎(chǔ)包，此部分硬件電子由Tier1根據(jù)硬件電子基礎(chǔ)包設(shè)計，并且添加OEM需求相關(guān)的外圍電路設(shè)計。形成OEM的硬件電路方案形態(tài)。

2）軟件開發(fā)模式：①Tier1的外包Tier2（如果有）方案商完成OS+driver的BSP移植工作，基本不做OS的深度裁剪，僅在基本框架方案上建立軟件分支副本，在此分支副本做增刪改，在功能上做兼容，從此形成OEM的OS，因為Tier2是系統(tǒng)軟件方案商，考慮的是快速地完成項目開發(fā)，完成項目功能，且利于以后新項目的延續(xù)復用、移植和兼容，不會投入太多的人力完成系統(tǒng)穩(wěn)定性的優(yōu)化，和系統(tǒng)效率的提升。從而造成硬件利用率低、OS不穩(wěn)定，卡、慢、死機等現(xiàn)象很難從根本上解決。②同時，Tier2也完成servises修改和移植，和APP的設(shè)計，與BSP的開發(fā)存在同樣的現(xiàn)象和不足。③Tier1的CAN和MCU團隊完成CAN的設(shè)計和MCU相關(guān)的設(shè)計。主要實現(xiàn)整車的CAN通信和診斷，電源管理相關(guān)的設(shè)計。

圖2 軟件的分層模型

圖3 Android系統(tǒng)的架構(gòu)分層模型

3）與車機相關(guān)的對手件APA、AVM、DVR設(shè)計成獨立零件，通過數(shù)據(jù)線、信號線、CAN與車機通信。車機主要是應用層的APP做UI界面顯示，APP通過車機MCU與獨立零件通過CAN信號實現(xiàn)控制信號的交互，通過數(shù)據(jù)信號線與車機OS做視頻傳輸，獨立零件設(shè)計成本高、聯(lián)調(diào)難度大。APA、AVM、DVR、人臉識別等功能與車機集成式的設(shè)計可以降低至少20%～30%的成本，但對軟件開發(fā)能力要求更高，特別是BSP的開發(fā)能力［4］。

OEM車機及其相關(guān)對手件設(shè)計方式如圖4所示。

越來越多的OEM車廠為了后期為提高軟件品質(zhì)和穩(wěn)定性，提高硬件資源使用效率，節(jié)約硬件成本，加快車機以及智能座艙系統(tǒng)軟件開發(fā)平臺化進程，節(jié)約零部件成本，已經(jīng)在慢慢放棄使用軟件方案公司的開發(fā)模式，特別是造車新勢力和處于頭部的傳統(tǒng)車廠，他們越來越傾向于前期加大軟件開發(fā)的投入，做好前期規(guī)劃的預研，陸續(xù)采取如圖5的車機及其相關(guān)對手件的設(shè)計方式。具體合作模式參考圖6。

圖4 OEM車機及其相關(guān)對手件設(shè)計

圖5 車機及其相關(guān)對手件的設(shè)計方式

4 結(jié)語

圖6 合作模式

本文概述了目前車機開發(fā)的行業(yè)現(xiàn)狀、存在的問題，調(diào)研了目前原始設(shè)備制造商（OEM）、Tier1車機的開發(fā)模式偏好、OEM軟硬件開發(fā)現(xiàn)狀，并分析了車機的開發(fā)發(fā)展趨勢、對未來信息娛樂新系統(tǒng)開發(fā)設(shè)計發(fā)展方向進行了探討，對未來信息娛樂系統(tǒng)開發(fā)，帶給用戶更好的體驗，具有實際價值和意義。