OTA是智能汽車的核心能力之一，是車輛常用常新、千車千面的基石。隨著集中化EEA架構(gòu)和SOA軟件架構(gòu)逐漸成熟走向市場，OTA技術(shù)也從單一的軟件更新演進(jìn)到融合OEM研發(fā)、生產(chǎn)、售后、市場反饋等多個系統(tǒng)及環(huán)節(jié)，以提供覆蓋整車全生命周期管理、智能制造、智能售后、數(shù)據(jù)閉環(huán)等眾多應(yīng)用。下一代OTA在更高效、安全、精準(zhǔn)、自動化地將新功能部署到目標(biāo)車輛上同時，可有效降低整車生產(chǎn)、擁有成本，更能夠通過持續(xù)的低成本高精數(shù)據(jù)采集，來開發(fā)、驗(yàn)證最新的應(yīng)用，提高客戶粘性，成為整車DevOps的核心通道。

下一代OTA的驅(qū)動力

下一代OTA的挑戰(zhàn)與需求主要來自三方面：

集中化的EEA架構(gòu)

與DevOps的集成

基于OTA的新的場景需求

除了傳統(tǒng)的執(zhí)行器和傳感器ECU，集中化的EEA架構(gòu)引入了以Ethernet為主干網(wǎng)的多元網(wǎng)絡(luò)，及域控制器或者HPC+區(qū)控制器架構(gòu)的多個功能強(qiáng)大的硬件。這些HPC或者域控制器都是多uP+uC架構(gòu)，uP也是多核異構(gòu)架構(gòu)。不僅僅在HPC或者域控制器內(nèi)部有復(fù)雜軟件版本的依賴關(guān)系，跨域之間及和傳統(tǒng)ECU之間的關(guān)系更為紛繁復(fù)雜。并且它們的升級包常常多達(dá)數(shù)GB，甚至幾十GB，升級時間更長，迫切需要新的升級協(xié)議及升級機(jī)制支持，以提高刷寫的可靠性與效率。在新能源車領(lǐng)域，除了OTA過程中的車輛安全管理及升級失敗回滾機(jī)制外，還會涉及到高低壓電源管理。在確保OTA的成功率同時，還會設(shè)置多個不同的電源模式，以適應(yīng)不同的用戶場景，以提高電量使用效率，提高用戶滿意度。

DevOps是在大規(guī)模復(fù)雜軟件領(lǐng)域廣泛使用的一個方法論。在引入智能汽車軟件行業(yè)，與OTA結(jié)合時，有其特殊的復(fù)雜性。特別是對一些頭部OEM來說，他們擁有不同平臺，不同動力類型、不同國家、不同配置、不同供應(yīng)商零配件、不同應(yīng)用場景的軟硬件配置需求，再加上下文要提到的SOTA，容器化化更新技術(shù)，讓不同的車輛擁有了千車千面的可能性，可對車主提供高度個性化服務(wù)，但是同時對于每輛車的軟件及數(shù)據(jù)管理也是一項(xiàng)新的巨大挑戰(zhàn)。在面向全球百萬量級的車輛，在市場上經(jīng)過一定時間更新迭代后，實(shí)時動態(tài)地管理車輛配置，并精準(zhǔn)地匹配目標(biāo)軟件版本，會是一個極其復(fù)雜的難題。千頭萬緒的整車軟件組件之間依賴性管理，會讓一挑戰(zhàn)更為艱巨。如果此時還是靠當(dāng)前人工管理車輛，組建升級包，監(jiān)控、管理升級任務(wù)，以實(shí)現(xiàn)軟件的精準(zhǔn)、按時交付，基本是一個不可能完成的任務(wù)。我們看到越來越多的整車廠面臨著這樣的問題。

隨著整車廠SDV.OS的成熟，作為與車輛保持始終在線的SOP后車輛運(yùn)營通道，整車廠對OTA有了越來越多的期待。除了傳統(tǒng)的軟件更新，整車廠希望能夠把OTA平臺的應(yīng)用場景進(jìn)一步拓展到生產(chǎn)、售后、終端用戶場景需求采集與反饋、應(yīng)用市場等多個方面。并且能夠以低成本、高效、靈活、快速地實(shí)現(xiàn)生產(chǎn)降本，售后增效，新場景有用戶量且持續(xù)迭代。為此下一代OTA平臺除了集成智慧工廠、遠(yuǎn)程診斷外，還亟需數(shù)據(jù)閉環(huán)、大數(shù)據(jù)云平臺及應(yīng)用商店等功能，以實(shí)現(xiàn)有粘性的用戶應(yīng)用，提高用戶滿意度，實(shí)現(xiàn)持續(xù)營收。

下一代OTA的架構(gòu)

下一代OTA解決方案包含云端 (Off-board)，車端(Onboard)兩部分。

除了較為常見的云端OTA車輛管理、權(quán)限管理、設(shè)備管理、OTA Campaign管理，車端的信令交互，升級包下載，解壓，解密，升級主控，升級代理外，下文將著重介紹為解決上述挑戰(zhàn)的一些新技術(shù)與方案。

VLCS 整車全生命周期配置系統(tǒng)

VLCS（Vehicle Lifecycle Configuration System）是一套整車全生命周期配置（包括硬件，軟件，數(shù)據(jù)）管理系統(tǒng)及基于該系統(tǒng)高精準(zhǔn)，自動化的軟件交付系統(tǒng)。VLCS面向下一代集中化EEA和SOA架構(gòu)的整車軟件升級及管理、集成了整車廠的研發(fā)，生產(chǎn)，售后，市場，終端客戶等多個管理系統(tǒng)，有機(jī)地融合到DevOps環(huán)境，讓每輛車全生命周期階段的所有軟硬件配置變更都在環(huán)內(nèi)追溯，在軟件持續(xù)交付的同時，構(gòu)成一車一檔案。同時在VLCS內(nèi)可以集成軟件批準(zhǔn)，軟件發(fā)布控制，軟件依賴管理，軟件合并更新管理等核心組件。不僅為車輛的軟件管理，故障橫向?qū)Ρ扰懦峁┝擞辛Φ臄?shù)據(jù)支撐，同時也為高精準(zhǔn)的自動化軟件匹配，交付提供了基礎(chǔ)。

在VLCS系統(tǒng)內(nèi)提供兩種自動化、高精度軟件匹配交付機(jī)制。一種是在傳統(tǒng)的人工手動組包，發(fā)起更新活動的基礎(chǔ)上，基于前述的VLCS核心能力，實(shí)現(xiàn)的自動化組包更新，從而避免大量重復(fù)人工操作，以及由此引發(fā)的失誤。在VLCS系統(tǒng)中軟件批準(zhǔn)，及經(jīng)軟件發(fā)布流程驗(yàn)證成功后，進(jìn)行軟件依賴項(xiàng)及軟件合并升級配置。系統(tǒng)會自動生成差分包，自動組包，自動加密簽名，自動發(fā)起升級活動并自動生成升級報告。基于該系統(tǒng)也可以支持整車廠應(yīng)用商店客戶在線訂閱功能，能夠自動觸發(fā)針對該客戶的個性化升級活動。

另一種是面向未來SDV場景，更為靈活、高效的軟件交付策略，以實(shí)現(xiàn)針對不同應(yīng)用場景（私家車，租出，車隊），不同用戶，不同時間（短期訂閱功能），地點(diǎn)（國家，路況）來安裝或者激活對應(yīng)功能，做到軟件可售、提升服務(wù)體驗(yàn)。在該策略下，云端根據(jù)車端上報的車輛狀態(tài)及用戶信息計算目標(biāo)車輛需要達(dá)到的功能狀態(tài)，并將計算結(jié)果下發(fā)到車輛。由車輛根據(jù)計算結(jié)果決定分別下載哪些升級包或者激活哪些功能，并執(zhí)行相關(guān)操作，以盡快達(dá)到終端用戶所期待狀態(tài)。而不需要OTA運(yùn)維工作人員在云端組包以及發(fā)起更新活動，從而進(jìn)一步降低人工干預(yù)的工作，提高交付精度和效率。

面向SDV.OS的差分更新、SOTA及容器化更新

車端ECU的安全、高效、友好的OTA更新策略是終端用戶最能直觀感受到的OTA本身功能。端到端網(wǎng)絡(luò)安全（Security），不同用車場景下的車輛安全（Safty）升級機(jī)制是下一代OTA功能的基本保障，這些需要對不同國家的法律法規(guī)，整車電子電器架構(gòu)有系統(tǒng)深入的理解。同時，針對車端豐富多樣的ECU類型，需要全面支持在新一代EEA架構(gòu)下的各種車內(nèi)升級包分發(fā)升級協(xié)議，如UDS on CAN / DoIP / Some/IP/DDS/定制協(xié)議等，也可支持多域控下的并行下載、域內(nèi)分發(fā)、并行刷寫、多分區(qū)刷寫等機(jī)制。為了進(jìn)一步提高更新效率，降低軟件更新時間，面向SDV.OS，OTA需要在差分更新、SOTA及容器化更新等多方面進(jìn)行行業(yè)領(lǐng)先的探索。

差分更新

差分更新組件分為云端差分生成工具及車端還原組件。主要是為了降低域控制器或者HPC等智能件的升級包大小，以降低網(wǎng)絡(luò)傳輸時長及網(wǎng)絡(luò)流量。這些智能件通常帶一個或者多個操作作系統(tǒng)，如Linux、Android、QNX等。待更新的軟件及數(shù)據(jù)包通常能夠達(dá)到數(shù)GB，在云端經(jīng)過差分工具利用專有差分算法識別提取新舊軟件的差異，并壓縮后制作出一個差分包。實(shí)測場景下能夠做到原包的5%，甚至2%以下。在車端完成差分包下載后，差分還原組件可以在車輛正常工作情況下，結(jié)合車端原有舊版軟件及差分軟件包執(zhí)行升級包還原操作，之后進(jìn)行軟件升級刷寫。差分更新也需要支持傳統(tǒng)嵌入式ECU差分升級。主要是為了降低升級包在車內(nèi)CAN總線上分發(fā)的時間，實(shí)測場景下能夠降低CAN總線傳輸時長70%~90%。ETAS差分工具已集成在OTA平臺中應(yīng)用在多個量產(chǎn)項(xiàng)目中，也可以作為單獨(dú)組件集成在整車廠的工具鏈或者云端后臺。

基于Autosar AP的SOTA

我們在座艙域Andriod環(huán)境下，已經(jīng)看到一部分軟件可以類似我們使用的手機(jī)中的應(yīng)用一樣，可以在“應(yīng)用市場”種下載和安裝，而不需要進(jìn)行整車的OTA升級，提供接近消費(fèi)電子的使用體驗(yàn)。目前這些應(yīng)用主要還是集中在日常手機(jī)生態(tài)中。在SDV.OS環(huán)境下，將涌現(xiàn)大量與汽車功能屬性密切相關(guān)的應(yīng)用，如智駕域，車身域、底盤域、動力域，以及跨域的功能應(yīng)用等。Autosar AP UCM組件就是提供類似應(yīng)用升級服務(wù)的，它可以支持軟件級別的升級功能。

下一代OTA方案與Autosar AP集成，提供端到端SOTA解決方案。UCM Client是一個特定于項(xiàng)目的自適應(yīng)應(yīng)用程序，用作與更新Machine的單點(diǎn)交互。其具有以下組件：

**UCM Master: **UCM Master具有多重職責(zé)，主要負(fù)責(zé)檢索Machine上軟件包的當(dāng)前狀態(tài)信息，與UCM subordinates進(jìn)行通信，并將適當(dāng)?shù)能浖鼈鬏斀oUCM。以組織更新。它可以通過使用通信管理的服務(wù)來尋址不同Machine上的UCM subordinates。

OTA Client:此客戶端處理軟件包從遠(yuǎn)程存儲庫轉(zhuǎn)移到Machine上的過程。

**Diagnostic Client: **此客戶端與診斷管理器通信，以利用診斷管理功能組織更新。

在Machine上安裝、更新或刪除的軟件包的接收由UCM Master負(fù)責(zé), UCM Client負(fù)責(zé)處理跨多臺機(jī)器的更新協(xié)調(diào), UCM client獲取關(guān)于AUTOSAR自適應(yīng)平臺軟件的信息，并通過使用UCM API傳輸和處理軟件包來執(zhí)行更新過程。

ETAS OTA 方案

容器化更新

容器化是在SDV.OS發(fā)展趨勢下，從ICT行業(yè)引入到汽車行業(yè)的又一個“泊來”品。其有助于開發(fā)人員更快地創(chuàng)建和部署應(yīng)用程序，無論是在訓(xùn)練過程中還是在運(yùn)行時，尤其在諸如ADAS、手勢識別、語音識別、面部識別等功能的AI/ML模型中非常常見。它提供了更高的可移植性、靈活性，并讓應(yīng)用程序更接近“編寫一次，隨處運(yùn)行”的期望狀態(tài)，可以在多個硬件上靈活運(yùn)行。容器化應(yīng)用程序不會捆綁操作系統(tǒng)的副本，它們在真正的意義上是“隔離”的。因此容器化更新在應(yīng)對多個版本和配置管理挑戰(zhàn)，以及管理應(yīng)用程序和中間件組件的依賴關(guān)系，容器可以發(fā)揮重要作用。這與其在IT和云環(huán)境中變得流行的原因基本相同。

SDV.OS下的車輛功能將是微服務(wù)、軟件應(yīng)用程序、ML/AI模型等的組合，將這些不同的部分打包成容器集，作為單個單元推送到不同車輛上。雖然云端的容器現(xiàn)在已成為事實(shí)上的標(biāo)準(zhǔn)，但要應(yīng)用到智能汽車領(lǐng)域，形成車云一體化的架構(gòu)，也有其獨(dú)特的復(fù)雜性。

OTA的增值場景應(yīng)用

以ETAS的下一代OTA方案為例，進(jìn)一步把OTA的應(yīng)用向生成、售后、終端用戶場景需求采集與反饋、應(yīng)用市場等多個方面延申。提供遠(yuǎn)程診斷，智能診斷，智能工廠，數(shù)據(jù)閉環(huán)等服務(wù)。

遠(yuǎn)程診斷

ETAS整合了傳統(tǒng)的診斷業(yè)務(wù)和功能，實(shí)現(xiàn)了從傳統(tǒng)診斷到遠(yuǎn)程診斷。基于傳統(tǒng)診斷的知識積累和工具集合，重新定義了車端診斷的運(yùn)行環(huán)境。使用診斷開發(fā)的IDE工具GRADE-X Authoring，通過拖拉拽的操作，用所見即所得的方式編輯診斷序列，編輯的診斷包支持ISO國際標(biāo)準(zhǔn)ODX和OTX協(xié)議。

該方案有如下幾個優(yōu)點(diǎn)：

1.整合博世傳統(tǒng)診斷業(yè)務(wù)能力，在車端提供集成診斷的運(yùn)行環(huán)境。實(shí)現(xiàn)不依賴傳統(tǒng)診斷設(shè)備連接車輛，執(zhí)行診斷指令。

2.支持ODX與OTX標(biāo)準(zhǔn)的可視化編輯工具。實(shí)現(xiàn)一次編輯，到處執(zhí)行的能力。

3.多年的車載診斷經(jīng)驗(yàn)，具備了診斷數(shù)據(jù)分析的能力。

目前已經(jīng)有多個國內(nèi)落地的項(xiàng)目經(jīng)驗(yàn)：例如工廠EOL，OTA和診斷賦能OEM在產(chǎn)線電檢環(huán)節(jié)替代傳統(tǒng)的診斷設(shè)備，進(jìn)行產(chǎn)線電檢和刷寫，不僅節(jié)省了產(chǎn)線設(shè)備同時還提高了產(chǎn)線的診斷效率。

遠(yuǎn)程診斷主要有如下幾個應(yīng)用場景：

1.故障診斷：遠(yuǎn)程診斷技術(shù)可以實(shí)時監(jiān)測車輛的運(yùn)行數(shù)據(jù)和故障信息，提供精準(zhǔn)的故障診斷和解決方案。

2.預(yù)防性維護(hù)：遠(yuǎn)程診斷技術(shù)可以通過分析車輛的運(yùn)行數(shù)據(jù)，提前預(yù)判潛在故障，并提供相應(yīng)的維護(hù)建議，避免故障的發(fā)生。

3.遠(yuǎn)程協(xié)助：遠(yuǎn)程診斷技術(shù)可以通過視頻會議、遠(yuǎn)程協(xié)助等方式，為維修服務(wù)提供商提供遠(yuǎn)程技術(shù)支持，提高維修服務(wù)的效率和減少維修成本。

4.車輛健康管理：遠(yuǎn)程診斷技術(shù)可以實(shí)現(xiàn)對車輛的健康狀況進(jìn)行實(shí)時監(jiān)測和分析，為車主提供個性化的駕駛建議和維護(hù)建議，提高車輛的使用壽命和安全性。

數(shù)據(jù)閉環(huán)

車輛量產(chǎn)上市后，會面臨車輛的維護(hù)，既有功能的持續(xù)迭代，新應(yīng)用場景的挖掘、開發(fā)與驗(yàn)證。以實(shí)現(xiàn)對終端用戶有意義和粘性的千車千面應(yīng)用，這才是SDV的終極意義。這些需求都涉及到量產(chǎn)后圍繞車輛不同類型數(shù)據(jù)的持續(xù)采集。

如車輛的維護(hù)，遠(yuǎn)程診斷能夠解決一定的問題，但是當(dāng)我們需要定位問題的根因時，往往靠遠(yuǎn)程診斷采集的數(shù)據(jù)類型和數(shù)據(jù)量遠(yuǎn)遠(yuǎn)不夠，特別是對一些偶發(fā)、難以復(fù)現(xiàn)的故障排查，整車廠花費(fèi)了大力的精力和財力在這方面。再比如自動駕駛算法corner case的持續(xù)收集與算法迭代，針對不同用戶群的各種潛在應(yīng)用場景挖掘及推向市場后的反饋等，這些都需要收集不同類型的數(shù)據(jù)，并且采集的信號類型和頻率都可能會因不同部門，不同目的，不同場景的具體需求而異。同時顯然車輛的無線通道帶寬是有限的，數(shù)據(jù)流量及存儲的費(fèi)用也不菲，整車廠只對高價值區(qū)間的數(shù)據(jù)感興趣。

ETAS的下一代OTA還推出了數(shù)據(jù)閉環(huán)解決方案。該方案的目標(biāo)是動態(tài)、靈活地采集整車高精度數(shù)據(jù)，包括：

·全車總線數(shù)據(jù)，包括CAN/CAN FD，以太網(wǎng)等

·診斷數(shù)據(jù)

·ECU內(nèi)部標(biāo)定數(shù)據(jù)

·域控制器或者HPC的中間件數(shù)據(jù)

·傳統(tǒng)嵌入式ECU內(nèi)部有業(yè)務(wù)價值的數(shù)據(jù)（與硬件部門合作）

在云端可以動態(tài)配置所采集信號類型及頻率，設(shè)置數(shù)據(jù)觸發(fā)上傳邏輯及采集時間段，并將任務(wù)發(fā)送到車端。由車端邊緣引擎負(fù)責(zé)解析執(zhí)行，獲取到目標(biāo)價值數(shù)據(jù)后，經(jīng)壓縮上傳到云端。基于云端的大數(shù)據(jù)平臺可以進(jìn)行故障分析、軟件迭代、新的應(yīng)用挖掘與驗(yàn)證等服務(wù)。

下一代OTA技術(shù)已經(jīng)在多個客戶落地量產(chǎn)，幫助整車廠不僅僅實(shí)現(xiàn)了安全、高效、便捷的OTA軟件更新，更面向SDV的趨勢，推出了切合新一代EEA需求的軟件組件產(chǎn)品，真正實(shí)現(xiàn)車輛上市后的數(shù)據(jù)驅(qū)動的持續(xù)迭代，軟件可售新的商業(yè)模式。

審核編輯：湯梓紅