朱芙蓉,劉 敏,秦文貞
(1.江西五十鈴汽車有限公司,江西 南昌 330104;2.南昌航空大學(xué),江西 南昌 330063)
車載信息娛樂系統(tǒng)(以下簡稱車機(jī))是車輛的綜合信息處理系統(tǒng),承擔(dān)著座艙娛樂、通信、車身控制、輔助駕駛、保證行車安全等重要功能。隨著信息技術(shù)、車聯(lián)網(wǎng)技術(shù)、5G技術(shù)、人工智能技術(shù)、自動駕駛技術(shù)的發(fā)展,車機(jī)開始向集成化和智能化發(fā)展[1]。車機(jī)的功能越來越趨于復(fù)雜,開發(fā)難度越來越大,也隨著市場的培育,用戶對車機(jī)系統(tǒng)的功能及交互要求也越來越高、對穩(wěn)定性的要求也越來越高。因此,對于車機(jī)系統(tǒng)研發(fā)設(shè)計提出了更大的挑戰(zhàn)。
本文通過分析目前車機(jī)開發(fā)的行業(yè)現(xiàn)狀、存在的問題,調(diào)研目前原始設(shè)備制造商(OEM)、Tier1車機(jī)的開發(fā)模式偏好、OEM軟硬件開發(fā)現(xiàn)狀,并分析了車機(jī)的開發(fā)發(fā)展趨勢。
系統(tǒng)軟件方案商有一套基本的工程代碼框架,此工程框架一般由平臺芯片廠商提供,為了快速開發(fā)項目,項目都在此基本框架上建立軟件分支副本,在此分支副本做增刪改,在功能上做兼容,從此形成一個新的項目。也有的項目是在前期開發(fā)的類似項目上,建立副本分支,針對需求差異點,對新項目進(jìn)行定制化開發(fā)。此為系統(tǒng)軟件方案商進(jìn)行新項目開發(fā)的基本模式。目前這種開發(fā)模式,存在以下不足。
1)開發(fā)到后期,代碼功能越來越多,復(fù)雜度越來越高,代碼容量越來越大,邏輯越來越雜亂,一套Android代碼能達(dá)到60GB以上。如果測試不充分,就很容易導(dǎo)致經(jīng)常出現(xiàn)很低級的軟件bug流到OEM。
2)后期的開發(fā)人員初期都是參考以往同事的設(shè)計方式、邏輯、架構(gòu)、或是在前人的基礎(chǔ)上做些優(yōu)化,導(dǎo)致軟件設(shè)計、架構(gòu)設(shè)計不清晰,風(fēng)格不統(tǒng)一,特別是涉及到具體業(yè)務(wù)邏輯的應(yīng)用層模塊。對人員變動后,后續(xù)接手人員交接難度大,交接耗時,交接品質(zhì)低。
3)方案公司一般進(jìn)出人流量大,甚至除核心、骨干外,整個開發(fā)團(tuán)隊人員都會更新,這就加速了第二點的不足。且難以形成技術(shù)沉淀,對OS的定制開發(fā)能力、BSP的裁剪能力欠缺。
4)方案公司對核心板的軟件管理,特別是對BSP,為了減少對不同的項目開發(fā)的移植難度,BSP功能大多采用兼容開發(fā)的模式,導(dǎo)致BSP龐大,OS運行卡頓、不流暢,軟件效率低,硬件利用率低。
5)方案公司對APP應(yīng)用的開發(fā),為了提高項目的實現(xiàn)效率,往往是針對不同客戶的差異化需求,在前期的工程上做修改,這樣容易出現(xiàn)定制化開發(fā)不徹底,APP應(yīng)用容易出現(xiàn)邏輯上的混亂。
為解決此前開發(fā)模式的不足,研究技術(shù)人員開展了大量的工作。經(jīng)過調(diào)研,目前市場上,造車新勢力比較偏好的車機(jī)開發(fā)模式。
1)車機(jī)硬件,由A供應(yīng)商合作完成。其主要工作任務(wù):硬件設(shè)計、硬件功能驗證、硬件可靠性保證、硬件DVP實驗、貼片生產(chǎn)、軟件燒錄、組裝生產(chǎn)、整機(jī)功能測試、出貨。
2)車機(jī)軟件OS移植適配由B供應(yīng)商完成或者也可由A供應(yīng)商完成,OS移植需要根據(jù)需求適配硬件,對BSP進(jìn)行定制開發(fā),對OS進(jìn)行深度裁剪,優(yōu)化OS穩(wěn)定性,刪除無用的OS功能和模塊,提升OS開機(jī)時間。此需要與A供應(yīng)商緊密配合。
3)車機(jī)應(yīng)用層軟件,由C供應(yīng)商完成,也可拆分委托多家合作完成。應(yīng)用層分為各個模塊或是各個APK,主要針對各個功能應(yīng)用,例如AVM、APA、設(shè)置、電話、媒體、商城、自動駕駛、車聯(lián)網(wǎng)車機(jī)端APP等,此需要與A、B供應(yīng)商以及對手件緊密配合。
4)車聯(lián)網(wǎng)部分由D供應(yīng)商完成,目前此部分功能在車機(jī)中越來越重要,涉及到車機(jī)的智能化埋點,后臺云TSP服務(wù)的穩(wěn)定,以及后續(xù)AI算法的融入,考慮到后期連接數(shù)量越來越大,數(shù)據(jù)量越來越大,為減少切換供應(yīng)商所帶來的數(shù)據(jù)遷移和方案修改所帶來的巨大成本,普遍趨于選一家技術(shù)穩(wěn)定可靠的供應(yīng)商長期合作。
車機(jī)開發(fā)模式包含硬件和軟件,圖1是硬件的模塊開發(fā)組成和形式,圖2是軟件的分層模型[2-3],圖3是Android系統(tǒng)的架構(gòu)分層模型。
圖1 硬件的模塊開發(fā)組成和形式
目前OEM車機(jī)軟硬件主流開發(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ù)復(fù)用、移植和兼容,不會投入太多的人力完成系統(tǒng)穩(wěn)定性的優(yōu)化,和系統(tǒng)效率的提升。從而造成硬件利用率低、OS不穩(wěn)定,卡、慢、死機(jī)等現(xiàn)象很難從根本上解決。②同時,Tier2也完成servises修改和移植,和APP的設(shè)計,與BSP的開發(fā)存在同樣的現(xiàn)象和不足。③Tier1的CAN和MCU團(tuán)隊完成CAN的設(shè)計和MCU相關(guān)的設(shè)計。主要實現(xiàn)整車的CAN通信和診斷,電源管理相關(guān)的設(shè)計。
圖2 軟件的分層模型
圖3 Android系統(tǒng)的架構(gòu)分層模型
3)與車機(jī)相關(guān)的對手件APA、AVM、DVR設(shè)計成獨立零件,通過數(shù)據(jù)線、信號線、CAN與車機(jī)通信。車機(jī)主要是應(yīng)用層的APP做UI界面顯示,APP通過車機(jī)MCU與獨立零件通過CAN信號實現(xiàn)控制信號的交互,通過數(shù)據(jù)信號線與車機(jī)OS做視頻傳輸,獨立零件設(shè)計成本高、聯(lián)調(diào)難度大。APA、AVM、DVR、人臉識別等功能與車機(jī)集成式的設(shè)計可以降低至少20%~30%的成本,但對軟件開發(fā)能力要求更高,特別是BSP的開發(fā)能力[4]。
OEM車機(jī)及其相關(guān)對手件設(shè)計方式如圖4所示。
越來越多的OEM車廠為了后期為提高軟件品質(zhì)和穩(wěn)定性,提高硬件資源使用效率,節(jié)約硬件成本,加快車機(jī)以及智能座艙系統(tǒng)軟件開發(fā)平臺化進(jìn)程,節(jié)約零部件成本,已經(jīng)在慢慢放棄使用軟件方案公司的開發(fā)模式,特別是造車新勢力和處于頭部的傳統(tǒng)車廠,他們越來越傾向于前期加大軟件開發(fā)的投入,做好前期規(guī)劃的預(yù)研,陸續(xù)采取如圖5的車機(jī)及其相關(guān)對手件的設(shè)計方式。具體合作模式參考圖6。
圖4 OEM車機(jī)及其相關(guān)對手件設(shè)計
圖5 車機(jī)及其相關(guān)對手件的設(shè)計方式
圖6 合作模式
本文概述了目前車機(jī)開發(fā)的行業(yè)現(xiàn)狀、存在的問題,調(diào)研了目前原始設(shè)備制造商(OEM)、Tier1車機(jī)的開發(fā)模式偏好、OEM軟硬件開發(fā)現(xiàn)狀,并分析了車機(jī)的開發(fā)發(fā)展趨勢、對未來信息娛樂新系統(tǒng)開發(fā)設(shè)計發(fā)展方向進(jìn)行了探討,對未來信息娛樂系統(tǒng)開發(fā),帶給用戶更好的體驗,具有實際價值和意義。