智能汽車時代我們更關(guān)注在大算力平臺下相應(yīng)的自動駕駛技術(shù)成熟度以及車內(nèi)智能座艙所帶來人機(jī)交互的智能化體驗。作為全面智能化體驗提升的關(guān)鍵，智能汽車的軟件升級OTA正在從信息娛樂域逐步擴(kuò)大到智能駕駛域、車身域、底盤域及動力域等對安全功能要求較高的功能域，加上OTA相關(guān)監(jiān)管政策的趨嚴(yán)，OTA的技術(shù)門檻將大幅提升。

在新的商業(yè)模式及汽車價值鏈重構(gòu)中通常可以通過軟件實現(xiàn)價值鏈向中后端轉(zhuǎn)移。在汽車全生命周期下，與傳統(tǒng)燃油車銷售的一錘子買賣不同，新能源智能汽車后續(xù)通過“硬件預(yù)埋、軟件升級”的方式可以持續(xù)提升用戶體驗，增加用戶粘性，屆時主機(jī)廠可以通過OTA軟件升級實現(xiàn)軟件可售、軟件付費等新商業(yè)模式，獲得較高附加值，整車架構(gòu)和商業(yè)模式被重新定義。

本文將針對性的對智能汽車軟件可售框架及原理進(jìn)行詳細(xì)的描述，以幫助讀者更好的理解整個智能駕駛軟件在售后升級過程中的精髓。

1.智駕軟件可售整體架構(gòu)及流程

軟件可售的整個功能模塊主要包括后端管理、商城接入、車端接入、TSP接入等幾個模塊。其中后端管理涉及服務(wù)配置、服務(wù)管理、訂單管理、訂閱管理幾個模塊，所有的功能模塊都是在商場接入過程中從“可售商場”中提前進(jìn)行的主動查詢（包含車型/車輛/服務(wù)/訂單激活狀態(tài)等），并通過訂單數(shù)據(jù)同步接入到車端接入服務(wù)模塊中。隨后，由車輛接入服務(wù)模塊將對應(yīng)的車輛信息查詢、訂單數(shù)據(jù)同步、訂單激活狀態(tài)查詢等信息輸入到車輛服務(wù)模塊和可售服務(wù)模塊，實現(xiàn)對用戶精準(zhǔn)的軟件升級服務(wù)。

當(dāng)然，服務(wù)期間，軟件可售這幾個模塊都會由專門的管理員進(jìn)行相應(yīng)的管理和配置。

從可售軟件上線、銷售到用戶購買使用的宏觀層面角度上講主要是對所升級新功能模塊的下載和安裝，主要參照如下流程進(jìn)行。

以軟件服務(wù)管理為例，首先需要為車型建立服務(wù)與車型之間的對應(yīng)關(guān)系，相應(yīng)會涉及如下相應(yīng)的模塊。

軟件服務(wù)加入管理：建立車型與服務(wù)管理模塊之間的關(guān)聯(lián)，驅(qū)使服務(wù)管理綁定車型實現(xiàn)精準(zhǔn)更新，且一旦建立關(guān)聯(lián)就不能再刪除；

構(gòu)建軟件服務(wù)列表：服務(wù)列表主要是應(yīng)用于查詢車型下的所有服務(wù)Feature，同時為該車型設(shè)置并查看對應(yīng)服務(wù)所依賴的最小零部件版本；

編輯軟件可售服務(wù)：對正常且即將發(fā)布的服務(wù)編輯相應(yīng)的基本信息，同時適時的查看該服務(wù)的狀態(tài)。對未經(jīng)過管理、審核中的服務(wù)需要單獨標(biāo)識，對已通過審核及已發(fā)布的服務(wù)需要進(jìn)行凍結(jié)，禁止隨意編輯；

審核可售服務(wù)：未審核的軟件服務(wù)通常是會標(biāo)記未通過，通過查看服務(wù)審核信息，可以把編輯完善的服務(wù)提交到審核流程，審核通過后，狀態(tài)需要更新為已通過；

發(fā)布/撤回服務(wù)：對狀態(tài)為已通過的服務(wù)可以立即生效，該服務(wù)可以被商城查詢到，并包裝成商品供客戶購買。如果部分未通過審核的服務(wù)通常需要及時撤回，且撤回服務(wù)之前，需要在商城校驗該服務(wù)是否處于上架狀態(tài)，如果已上架，則需要及時將該服務(wù)置灰以避免用戶誤購買。

可售服務(wù)激活：首先，由SOTA模塊對待激活訂單進(jìn)行業(yè)務(wù)拆包，拆解后的包涉及如下信息：訂單號、激活使用時間、軟件供應(yīng)商代碼及名稱、車架號、車型代號等信息。

其次，由車聯(lián)網(wǎng)服務(wù)提供端TSP對激活失敗的訂單間隔一定時間進(jìn)行激活重試。

如下時序圖可以完整的說明軟件可售服務(wù)模塊如何能夠滿足整個業(yè)務(wù)服務(wù)需求。

其中，軟件服務(wù)模塊的主導(dǎo)端是OTA Master。由該模塊發(fā)起激活請求給SOTA Access，SOTA首先進(jìn)行參數(shù)自檢，再將車型對賬信息請求發(fā)送給車輛服務(wù)模塊，并根據(jù)返回的車型信息重新進(jìn)行車型信息重校驗。隨后，SOTA模塊從銷售商城獲取訂單信息后對訂單進(jìn)行進(jìn)行信息校驗，計算功能配置信息并返回特征配置。通過對TSP服務(wù)模塊請求第三方服務(wù)（如第三方支付系統(tǒng)）的非同步激活，從而更新銷售商城的最新狀態(tài)。最后，系統(tǒng)將功能配置結(jié)果反饋到OTA Master端，整個軟件可售服務(wù)就完成了整體的功能售出及校驗。

2.云端可售軟件系統(tǒng)架構(gòu)及交互邏輯

細(xì)化到智駕系統(tǒng)而言，整個軟件可售模塊主要包括如下幾部分：軟件升級模塊SOTA、車聯(lián)網(wǎng)服務(wù)提供端TSP、云端服務(wù)器、智能座艙域控制器、智能駕駛域控制器。其中，交互過程包括域控與云端交互以及域控與車端交互兩個方面。

1、云端交互系統(tǒng)架構(gòu)及原理如下：

1）應(yīng)用推送：

系統(tǒng)通過遠(yuǎn)程推送相應(yīng)的升級軟件包到用戶手機(jī)端，用戶在激活所購買的功能包后，生成對應(yīng)的激活信號會被傳送到SOTA平臺；

2）軟件包驗簽：

激活成功后，SOTA模塊對功能配置信息中添加簽名信息，完成后下發(fā)對應(yīng)的功能配置信息到智能座艙端。隨后智能座艙控制器讀取該功能配置信息，并立即轉(zhuǎn)發(fā)給智駕域控進(jìn)行驗簽，驗簽完成后保存對應(yīng)的功能配置信息。如果驗簽失敗，則需要重復(fù)請求SOTA發(fā)送功能配置信息；

3）功能配置信息讀取：

智駕域控成功收到配置信息并存儲后，反饋成功標(biāo)志位給SOTA平臺。智駕域控中的功能管理模塊讀取新功能配置信息后，在下個點火周期控制對應(yīng)的功能開啟、關(guān)閉。

4）傳遞車型信息：

SOTA平臺將購買車輛的VIN號提供給TSP，TSP平臺將VIN轉(zhuǎn)換成對應(yīng)的id號，發(fā)送到云端服務(wù)器進(jìn)行激活并反饋激活結(jié)果。

5）配置信息比對：

在車輛首次上電后，座艙域控向智駕域控請求云端下發(fā)的配置文件信息。由智駕域控將對應(yīng)的配置信息回傳座艙域控后，再由座艙域控轉(zhuǎn)發(fā)給SOTA模塊，并與其中的平臺數(shù)據(jù)進(jìn)行比對，若比對不成功還需要重新進(jìn)行驗簽及信息下發(fā)。

3.車端可售軟件系統(tǒng)架構(gòu)及交互邏輯

智駕域控與車機(jī)的交互過程主要關(guān)注域控內(nèi)部芯片之間如何通過一定的數(shù)據(jù)流交互傳輸對應(yīng)的可售軟件包數(shù)據(jù)。我們知道智駕域控的整體模塊劃分主要包括高計算能力感知處理芯片SOC，以及高功能安全能力規(guī)控處理芯片MCU。整個軟件可售的車端運行過程主要是針對其功能配置文件的讀取來判斷是否開啟某項特殊的智駕功能，智能駕駛域控制器還需要依靠激活RTK，高精地圖等模塊，通過云端獲取相應(yīng)的功能配置文件來激活功能。

整體來說，車端可售軟件模塊在智駕系統(tǒng)中的交互過程主要涉及如下幾個流程。

1）讀取功能配置信息：

在上電啟動后，智駕域控中先啟動讀取存儲其中的配置信息，并按照配置信息轉(zhuǎn)發(fā)出相應(yīng)的車型配置信息給到座艙域控。

2）信息完整性校驗：

智駕域控通過電源配置模塊啟動系統(tǒng)內(nèi)對應(yīng)的配置信息讀取模塊，并通過密碼散列函數(shù)—MD5校驗其數(shù)據(jù)信息的完整性。

3）時間源獲取：

對于可售的軟件需要在發(fā)布更新時間為其打上對應(yīng)的時間戳。為了獲取精準(zhǔn)的時間戳，通常功能管理模塊會優(yōu)先讀取GPS提供的衛(wèi)星時間，如果無法及時獲取到衛(wèi)星時間，則考慮從CAN網(wǎng)絡(luò)中直接獲取由TBOX存儲到整車上的時間。

4）功能開啟判斷：

智駕系統(tǒng)的功能管理模塊會根據(jù)讀取的當(dāng)前時間信息以及存儲時間信息綜合判斷各個功能是否能被打開，并將該開啟信息同步進(jìn)行存儲。

同時，智駕系統(tǒng)功能管理模塊會判斷數(shù)據(jù)是否異常，如果異常，則報文內(nèi)容按照新的配置重新發(fā)送。發(fā)送完成后，控制對其中各個子功能的開啟和關(guān)閉。

4.智駕域控內(nèi)部系統(tǒng)架構(gòu)及交互邏輯

具體來說，域控內(nèi)部模塊的交互方式是參照如下架構(gòu)圖實現(xiàn)軟件傳輸、下載及交互。

1）座艙域控在每次上電后會智駕域控發(fā)起請求，獲取到智駕域控發(fā)送到云端的配置信息；

2）域控制器接收到座艙域控發(fā)出的讀取配置信息指令后。在其內(nèi)部的操作過程會做如下動作：

由于智駕域控中MCU和SOC會有不同的分工，SOC主要是進(jìn)行頂層功能管理，該模塊會負(fù)責(zé)上傳下達(dá)最新的功能配置信息，并存儲在SOC功能管理模塊中。其中，以太網(wǎng)SOMEIP協(xié)議通信、功能管理、配置信息管理在域控制器的SOC中處理。MCU主要是進(jìn)行核心配置信息管理（其中包括云端配置和底層一些默認(rèn)信息的管理），自學(xué)習(xí)報文發(fā)送在域控制器的MCU中處理，提取到的配置信息在 MCU 中存儲。

智駕域控相關(guān)配置信息（高階智駕系統(tǒng)功能和低階智駕系統(tǒng)功能分別源自于默認(rèn)配置的兩個組成部分，可從軟件配置字和下線配置信息中獲取）是由MCU端在上電后從SOC讀取的，同時，MCU通過發(fā)送對應(yīng)的自學(xué)習(xí)報文給到座艙域控，從而告知到座艙域控當(dāng)前的功能配置信息是啥樣的。然后，智駕域控會啟動SOC中的功能管理模塊來讀取SOC內(nèi)存儲的配置信息，并驗證MD5數(shù)據(jù)完整性。

3）隨后，智駕域控通過以太網(wǎng)ETH 將SOC模塊升級軟件相關(guān)的配置信息發(fā)送至座艙域控。然后，接收對應(yīng)的時間信息。方式可以有幾種：域控制器優(yōu)先讀取定位模塊提供的UTC衛(wèi)星時間，在獲取不到衛(wèi)星時間時則采用RTC內(nèi)部晶振時間，如果以上兩種時間都獲取不到時就從CAN網(wǎng)絡(luò)上讀取整車時間。

4）座艙域控接收到相應(yīng)的自學(xué)習(xí)報文后，參照接收時間點對比當(dāng)前的功能版本的狀態(tài)信息。通過SOTA下發(fā)配置信息和域控制器中默認(rèn)配置信息來管理域控制器中智能駕駛功能，并進(jìn)行相應(yīng)的可用信息標(biāo)注。

5）根據(jù)標(biāo)注的功能可用性信息可以綜合判斷各個功能的使能狀態(tài)，從而在智駕域控中可以很好的對各個功能進(jìn)行控制。

6）本次功能配置信息已完成更新后，判斷是否數(shù)據(jù)正常，正常的數(shù)據(jù)需要將相應(yīng)的更新后的功能存儲到MCU模塊。

如下圖表示了相應(yīng)的配置文件結(jié)構(gòu)圖：

5.總結(jié)

智能汽車的軟件可售,意味著開發(fā)的軟件真正進(jìn)入運營階段,對于不斷迭代升級的智能汽車軟件（比如剛開始量產(chǎn)的智駕汽車軟件為L2及以下（如ACC、ICC、LKA、APA等）軟件，量產(chǎn)后的軟件為L2+軟件（如NGP、AVP等）對接到應(yīng)用商店的生態(tài)體系，從而可實現(xiàn)軟件的增值變現(xiàn)，同時基于用戶的個性化需求可實現(xiàn)千人千面的內(nèi)容推送。

因此，對于智駕系統(tǒng)對于軟件可售系統(tǒng)的依賴顯得越來越多，那么軟件可售的整個過程原理主要是通過對從云端、車機(jī)端到智駕系統(tǒng)的整個配置信息處理過程。那么如何獲取功能配置信息，如何進(jìn)行信息校驗，如何更新到車端這整個過程顯得尤為重要。此外，關(guān)于如何進(jìn)行可售軟件商城的布置，如何進(jìn)行收費/續(xù)費也是后期必須要考慮的要素。

審核編輯：劉清