車載信息娛樂系統開發模式現狀與未來趨勢分析

朱芙蓉，劉 敏，秦文貞

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

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

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

1 車機的開發發展現狀

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

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

2）后期的開發人員初期都是參考以往同事的設計方式、邏輯、架構、或是在前人的基礎上做些優化，導致軟件設計、架構設計不清晰，風格不統一，特別是涉及到具體業務邏輯的應用層模塊。對人員變動后，后續接手人員交接難度大，交接耗時，交接品質低。

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

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

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

2 車機開發模式偏好

為解決此前開發模式的不足，研究技術人員開展了大量的工作。經過調研，目前市場上，造車新勢力比較偏好的車機開發模式。

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

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

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

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

車機開發模式包含硬件和軟件，圖1是硬件的模塊開發組成和形式，圖2是軟件的分層模型［2-3］，圖3是Android系統的架構分層模型。

圖1 硬件的模塊開發組成和形式

3 OEM車機軟硬件研究發展

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

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

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

圖2 軟件的分層模型

圖3 Android系統的架構分層模型

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

OEM車機及其相關對手件設計方式如圖4所示。

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

圖4 OEM車機及其相關對手件設計

圖5 車機及其相關對手件的設計方式

4 結語

圖6 合作模式

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