對(duì)于整車OTA類型，主要分為兩類，F(xiàn)OTA（Firmware-over-the-air）和SOTA（Software-over-the-air），兩者均為主機(jī)廠重點(diǎn)關(guān)注及逐步落地的領(lǐng)域，可適應(yīng)不同場(chǎng)景的OTA需求。

FOTA和SOTA概述

FOTA通過(guò)給車輛控制器下載安裝完整的固件鏡像，來(lái)實(shí)現(xiàn)系統(tǒng)功能完整的升級(jí)更新。例如升級(jí)車輛的智駕系統(tǒng)，讓駕駛員享受越來(lái)越多的輔助駕駛功能；升級(jí)車輛的座艙系統(tǒng)，提高駕駛員疲勞檢測(cè)的準(zhǔn)確率；升級(jí)車輛的制動(dòng)系統(tǒng)，提升車輛的制動(dòng)性能。特斯拉曾在Model 3在上市后，發(fā)現(xiàn)其剎車邏輯存在優(yōu)化空間，通過(guò)FOTA對(duì)制動(dòng)系統(tǒng)進(jìn)行升級(jí)之后，制動(dòng)剎車距離由46m縮短為40m，大幅提升了行車時(shí)的安全性。
FOTA涉及控制器核心功能（控制策略）的一個(gè)完整的系統(tǒng)性更新，對(duì)整車性能影響較大，升級(jí)過(guò)程對(duì)時(shí)序、穩(wěn)定性、安全性要求極高，同時(shí)升級(jí)前置條件包括擋位、電量、車速等要求，升級(jí)過(guò)程一般不支持點(diǎn)火用車，蔚來(lái)車主曾在首都長(zhǎng)安街給全國(guó)車主免費(fèi)上過(guò)生動(dòng)的一課。
SOTA通過(guò)給車輛控制器安裝“增量包”，來(lái)實(shí)現(xiàn)控制器功能的一個(gè)“增量”更新，一般應(yīng)用于娛樂(lè)系統(tǒng)和智駕系統(tǒng)。例如更換多媒體系統(tǒng)操作界面，優(yōu)化儀表盤(pán)顯示風(fēng)格，更新娛樂(lè)主機(jī)里的地圖程序時(shí)，用到的都是SOTA升級(jí)方式。
SOTA涉及控制器應(yīng)用層一個(gè)小范圍的功能局部更新，對(duì)整車性能影響較小，升級(jí)前置條件要求較低。SOTA的增量更新策略，可以大幅減小升級(jí)包文件大小、從而節(jié)約網(wǎng)絡(luò)流量和存儲(chǔ)空間?？梢韵胂箅S著SOTA范圍的擴(kuò)大及技術(shù)的成熟，以后在車輛行駛的過(guò)程中，吃著火鍋唱著歌，車輛就可以自動(dòng)完成功能的更新迭代。
FOTA和SOTA功能定義目前沒(méi)有明確清晰的界限。遇到男同事咨詢時(shí)，我總是不負(fù)責(zé)任的舉出手機(jī)升級(jí)的例子。從iOS14更新到iOS15是FOTA，從微信7.9升級(jí)到9.0是SOTA。

本文主要介紹當(dāng)前對(duì)于整車功能的SOTA技術(shù)鏈路概述。本文介紹以下三種技術(shù)路徑，一種是針對(duì)車機(jī)、儀表APP類應(yīng)用的基于Android平臺(tái)的SOTA架構(gòu)；其二針對(duì)基于Autosar AP的控制器，通過(guò)UCM服務(wù)實(shí)現(xiàn)新功能的上線；最后一種為當(dāng)前的研究熱點(diǎn)——云邊協(xié)同策略。

Android應(yīng)用的實(shí)現(xiàn)

Android的SOTA技術(shù)已經(jīng)相當(dāng)成熟，點(diǎn)擊應(yīng)用商店中應(yīng)用旁的更新按鈕即可實(shí)現(xiàn)，讀者在自己的手機(jī)上已操作不下百遍，當(dāng)前不少車機(jī)、儀表的系統(tǒng)基于Android實(shí)現(xiàn)，針對(duì)Android平臺(tái)的APP應(yīng)用、主題、皮膚，實(shí)現(xiàn)路徑類似于手機(jī)的應(yīng)用商城，云端建立版本倉(cāng)庫(kù)，用戶在車機(jī)軟件商店點(diǎn)擊安裝后，車端從TSP下載安裝包(apk)，由車機(jī)或儀表執(zhí)行安裝或卸載。

基于AP AutoSAR 的SOA實(shí)現(xiàn)

Autosar CP架構(gòu)下，所有應(yīng)用都是靜態(tài)配置的，一旦軟件編譯完成就不可更改，其調(diào)用的周期也是確定。而在Autosar AP架構(gòu)下，一切都是OS中的進(jìn)程，應(yīng)用是動(dòng)態(tài)運(yùn)行的，何時(shí)調(diào)用、進(jìn)程生存周期、資源占用及進(jìn)程結(jié)束等都由系統(tǒng)動(dòng)態(tài)管理，好比你手機(jī)上的App何時(shí)打開(kāi)、運(yùn)行后其會(huì)調(diào)用的資源及何時(shí)關(guān)閉都是動(dòng)態(tài)進(jìn)行的。應(yīng)用們通過(guò)ARA(Autosar Run-time for Adaptive)進(jìn)行通訊，可支持或擴(kuò)展對(duì)SOME/IP、TSN、DDS等SOA通訊技術(shù)的應(yīng)用。

在AP平臺(tái)的服務(wù)中，UCM負(fù)責(zé)安全地更新，安裝，刪除和保留軟件記錄。類似Linux中的dpkg或YUM等軟件包管理系統(tǒng)，可以更新或修改Adaptive Platform上的軟件。
UCM實(shí)現(xiàn)SOTA功能的業(yè)務(wù)流程如下圖所示，其中包含如下幾個(gè)重要的模塊。

UCM Master：為UCM提供服務(wù)接口的客戶端，它從云端或診斷工具接收、驗(yàn)證、解析軟件包，并將軟件包傳輸至UCM或診斷應(yīng)用程序進(jìn)行后續(xù)激活、回滾等處理。
UCM：為與UCM Master處于同一網(wǎng)絡(luò)中的UCM服務(wù)實(shí)例。
OTA Client：建立云端和 UCM Master 之間的通信，以傳輸增量包的信息。
車輛狀態(tài)管理器：從多個(gè)車端ECU收集狀態(tài)，并計(jì)算相應(yīng)的安全狀態(tài)，根據(jù)車輛包中的安全策略，在發(fā)生變化時(shí)通知UCM Master。如果不滿足安全策略，UCM Master可采取相關(guān)措施，如通知用戶當(dāng)前不滿足前置條件，同時(shí)推遲、暫?；蛉∠?。
整個(gè)SOTA流程包含以下幾個(gè)過(guò)程：
一、升級(jí)包的打包和組裝 UCM的安裝單位是軟件包。該程序包包含一個(gè)或多個(gè)可執(zhí)行文件。除了應(yīng)用程序和配置數(shù)據(jù)外，每個(gè)軟件包包含Manifest，Manifest是arxml類型的文件，元數(shù)據(jù)包括軟件包名稱、版本、依賴關(guān)系等。
二、升級(jí)包傳輸
使用UCM服務(wù)接口的客戶端可以位于同一個(gè)AUTOSAR AP平臺(tái)上，也可以是遠(yuǎn)程客戶端。一個(gè)或多個(gè)軟件包傳輸?shù)経CM的內(nèi)部緩沖區(qū)。

傳輸完成后，會(huì)對(duì)軟件包的內(nèi)容進(jìn)行身份驗(yàn)證。
三、升級(jí)包安裝
安裝和卸載操作通過(guò)UCM的ProcessSwPackage接口執(zhí)行。值得一提的是，UCM支持A/B分區(qū)升級(jí)。對(duì)于A/B分區(qū)升級(jí)方案，讓舊版本先在A區(qū)運(yùn)行，升級(jí)非活躍的B分區(qū)。處理完成重啟后，運(yùn)行B分區(qū)的新版本。A/B分區(qū)的升級(jí)策略可以實(shí)現(xiàn)車輛行駛過(guò)程中的應(yīng)用部署，即便升級(jí)失敗也不會(huì)影響整車的其他功能。
四、升級(jí)包激活
對(duì)于一些功能，UCM在升級(jí)過(guò)程中必須同時(shí)更新多個(gè)軟件，因此UCM需根據(jù)軟件包的依賴關(guān)系后激活。如升級(jí)是通過(guò) A/B 分區(qū)的，分區(qū)之間發(fā)生交換，新的非活動(dòng)分區(qū)成為新活動(dòng)分區(qū)的副本。
五、升級(jí)包回滾
遇到異常應(yīng)用需要回滾至穩(wěn)定版本，UCM決定回滾的版本選擇，而回滾操作由Autosar AP的Persistency服務(wù)處理。

基于云邊協(xié)同的實(shí)現(xiàn)

介紹之前，先絮叨幾句虛擬化、虛擬機(jī)和容器。每位程序員的開(kāi)發(fā)環(huán)境配置可能會(huì)有所不同，這會(huì)導(dǎo)致你的代碼直接拿到同事的電腦上無(wú)法正常運(yùn)行。企業(yè)的開(kāi)發(fā)環(huán)境、測(cè)試環(huán)境和生產(chǎn)環(huán)境在配置和所依賴的文件上也會(huì)有所不同。如何確保在不同硬件、不同環(huán)境都能正常運(yùn)行你的BUG，是當(dāng)前軟件行業(yè)的熱點(diǎn)。云原生是該理念的最佳實(shí)踐，通過(guò)微服務(wù)，容器化，持續(xù)交付等新技術(shù)，實(shí)現(xiàn)了開(kāi)發(fā)運(yùn)維一體化，讓服務(wù)生于云，長(zhǎng)于云。
虛擬機(jī)（VM，Virtual Machine）是虛擬化技術(shù)的落地先鋒，通過(guò)軟件模擬的具有完整硬件系統(tǒng)功能的、運(yùn)行在一個(gè)完全隔離環(huán)境中的完整計(jì)算機(jī)系統(tǒng)，可以顯著提高設(shè)備的工作效率，減輕了企業(yè)對(duì)硬件資源的依賴。
當(dāng)前汽車行業(yè)落地的是Hypervisor 的虛擬化方案，其可以在多核異構(gòu)的單芯片上運(yùn)行多個(gè)不同類型的操作系統(tǒng)，各系統(tǒng)間共享硬件資源，既是彼此獨(dú)立又可交互信息。Hypervisor 即滿足了日益復(fù)雜場(chǎng)景下的不同業(yè)務(wù)需求，又提高了硬件資源的使用效率，大幅降低了成本，虛擬化所具備的不同操作系統(tǒng)間的隔離能力，大大提升了系統(tǒng)的可靠性和安全性。
座艙中的聯(lián)屏車機(jī)往往會(huì)采用該方案，實(shí)現(xiàn)主駕和副駕不同系統(tǒng)的需求。但是每個(gè)VM都需要安裝操作系統(tǒng)才能執(zhí)行應(yīng)用程序，倘若用戶只需在VM中運(yùn)行或遷移簡(jiǎn)單的應(yīng)用程序時(shí)，采用VM不僅操作繁瑣而且浪費(fèi)大量資源，因此企業(yè)迫切需要輕量級(jí)的虛擬化技術(shù)。
容器技術(shù)起源于Linux，是一種輕量化的內(nèi)核虛擬化技術(shù)，通過(guò)隔離進(jìn)程和資源，共享同一個(gè)操作系統(tǒng)內(nèi)核，可以保證在開(kāi)發(fā)、測(cè)試以及生產(chǎn)等不同環(huán)境和硬件配置下都具有移植性、一致性。虛擬機(jī)技術(shù)與容器技術(shù)的典型功能架構(gòu)框圖如下。

容器技術(shù)和虛擬機(jī)技術(shù)關(guān)鍵特性的對(duì)比如下。

容器技術(shù)隨著Docker的出現(xiàn)才在“格子襯衫”群體中流行開(kāi)來(lái)。Docker將集裝箱思想運(yùn)用到軟件打包技術(shù)上，為代碼提供了一個(gè)基于容器的標(biāo)準(zhǔn)化運(yùn)輸系統(tǒng)，其產(chǎn)品logo就是這一思想的最形象詮釋。

Docker 是一個(gè)開(kāi)源的應(yīng)用容器引擎，開(kāi)發(fā)者利用Docker可以將任何應(yīng)用及其依賴打包成一個(gè)輕量級(jí)、可移植、自包含的鏡像，然后發(fā)布到任何流行的 Linux、Windows等操作系統(tǒng)的機(jī)器上。Docker 技術(shù)包含三個(gè)核心基礎(chǔ)概念：

（1）鏡像（Image），一個(gè)層疊的只讀文件系統(tǒng)，除了提供容器運(yùn)行時(shí)所需的程序、庫(kù)、資源、配置等文件外，還包含了一些為運(yùn)行時(shí)準(zhǔn)備的配置參數(shù)。鏡像不包含任何動(dòng)態(tài)數(shù)據(jù)，其被創(chuàng)建之后內(nèi)部不會(huì)被改變。鏡像用來(lái)創(chuàng)建 Docker容器，同一個(gè)鏡像文件，可以生成多個(gè)同時(shí)運(yùn)行的容器； （2）容器（Container），容器是鏡像創(chuàng)建的運(yùn)行實(shí)例，容器可以被創(chuàng)建、啟動(dòng)、停止、刪除、暫停等。每個(gè)容器都是相互隔離； （3）倉(cāng)庫(kù)（Registry），鏡像文件存放的地方。用戶創(chuàng)建完鏡像后，可以將其上傳到到倉(cāng)庫(kù)，需要在另一臺(tái)主機(jī)上使用該鏡像時(shí)，只需要從倉(cāng)庫(kù)上下載即可。 Docker使用客戶端/服務(wù)器架構(gòu)模式，運(yùn)行邏輯如下圖所示。Docker守護(hù)進(jìn)程作為服務(wù)端的請(qǐng)求，負(fù)責(zé)構(gòu)建、拉取、啟動(dòng)Docker容器。Docker守護(hù)進(jìn)程一般在Docker主機(jī)后臺(tái)運(yùn)行，用戶使用Docker客戶端直接跟Docker守護(hù)進(jìn)程進(jìn)行信息交互。

Docker客戶端，向 Docker守護(hù)進(jìn)程發(fā)起Docker構(gòu)建、拉取、啟動(dòng)的請(qǐng)求，Docker守護(hù)進(jìn)程完成操作并返回結(jié)果。Docker客戶端既可以在訪問(wèn)本地Docker守護(hù)進(jìn)程，也可以訪問(wèn)遠(yuǎn)程Docker守護(hù)進(jìn)程。藍(lán)色虛線展示了Docker構(gòu)建并存放于本地Docker的構(gòu)建工作流。紫色虛線展示了從鏡像倉(cāng)庫(kù)拉取鏡像至Docker主機(jī)或?qū)ocker主機(jī)鏡像推送至鏡像倉(cāng)庫(kù)的拉取工作流。紅色虛線展示了鏡像安裝及容器啟動(dòng)的啟動(dòng)工作流。 Docker主機(jī)，一個(gè)物理或者虛擬的機(jī)器用于執(zhí)行 Docker守護(hù)進(jìn)程和容器。 Docker守護(hù)進(jìn)程，接收并處理Docker客戶端發(fā)送的請(qǐng)求，監(jiān)測(cè)Docker API的請(qǐng)求和管理Docker對(duì)象，比如鏡像、容器、網(wǎng)絡(luò)和數(shù)據(jù)卷。
Docker目前在互聯(lián)網(wǎng)的線上行業(yè)應(yīng)用非常廣泛，實(shí)現(xiàn)了“Write Once，Run Everywhere”的目標(biāo)，常見(jiàn)的應(yīng)用場(chǎng)景如下。
（1）對(duì)于開(kāi)發(fā)而言，服務(wù)和應(yīng)用更容易跨平臺(tái)移植。避免了由于平臺(tái)的變化而生成的Bug，同樣也避免了和測(cè)試、運(yùn)維之間扯皮甩鍋。不用再抱怨“怎么在正式環(huán)境上總是BUG，測(cè)試環(huán)境可是沒(méi)這個(gè)問(wèn)題的”。老板再也不用擔(dān)心環(huán)境遷移造成問(wèn)題的可能性，更好給下屬們分鍋了。
（2）對(duì)于運(yùn)維而言，可以通過(guò)容器編排應(yīng)用（如K8S），按業(yè)務(wù)需求自動(dòng)管理應(yīng)用的實(shí)例，適合動(dòng)態(tài)擴(kuò)容和縮容。典型的場(chǎng)景，就是電商的雙十一活動(dòng)會(huì)導(dǎo)致訂單服務(wù)的負(fù)載劇增，無(wú)容器技術(shù)時(shí)，運(yùn)維需要“自愿”通宵加班，手動(dòng)新增訂單服務(wù)的實(shí)例，并實(shí)時(shí)監(jiān)控各實(shí)例的狀態(tài)。目前，運(yùn)維可能左手咖啡，右手王者，眼睛盯一下就可以了。

對(duì)于上文提到的容器編排，你需要管理運(yùn)行應(yīng)用程序的容器，并確保不會(huì)停機(jī)。例如，如果一個(gè)容器發(fā)生故障，則需要啟動(dòng)另一個(gè)容器。如果系統(tǒng)處理此行為，會(huì)不會(huì)更容易？這時(shí)，Kubernetes和KubeEdge就出場(chǎng)了。
Kubernetes提供了一個(gè)可彈性運(yùn)行分布式系統(tǒng)的框架，滿足擴(kuò)展要求、故障轉(zhuǎn)移、部署模式等。Kubernetes能夠自主的管理容器來(lái)保證云平臺(tái)中的容器按照用戶的期望狀態(tài)運(yùn)行。在Kubernetes中，所有的容器均在Pod中運(yùn)行，一個(gè)Pod可以承載一個(gè)或者多個(gè)相關(guān)的容器，同一個(gè)Pod中的容器會(huì)部署在同一個(gè)物理機(jī)器上并且能夠共享資源。Pod也可以包含0個(gè)或者多個(gè)磁盤(pán)卷組，這些卷組將會(huì)以目錄的形式提供給一個(gè)容器，或者被所有Pod中的容器共享。然而，Kubernetes的應(yīng)用場(chǎng)景僅限于線上的云服務(wù)，并不支持設(shè)備端。

KubeEdge基于Kubernetes構(gòu)建，可將本機(jī)容器化應(yīng)用編排和管理擴(kuò)展到邊緣端設(shè)備。為網(wǎng)絡(luò)和應(yīng)用程序提供核心基礎(chǔ)架構(gòu)支持，并在云端和邊緣端部署應(yīng)用，同步元數(shù)據(jù)，主要優(yōu)勢(shì)有如下四點(diǎn)：
 （1）邊緣計(jì)算。通過(guò)在Edge上運(yùn)行的業(yè)務(wù)邏輯，可以在生成數(shù)據(jù)的本地保護(hù)和處理大量數(shù)據(jù)。這減少了網(wǎng)絡(luò)帶寬需求以及邊緣和云之間的消耗。這樣可以提高響應(yīng)速度，降低成本并保護(hù)客戶的數(shù)據(jù)隱私； （2）簡(jiǎn)化開(kāi)發(fā)。開(kāi)發(fā)人員可以編寫(xiě)基于常規(guī)HTTP或MQTT的應(yīng)用程序，對(duì)其進(jìn)行容器化，然后在Edge或Cloud中的任何位置運(yùn)行它們中的更合適的一個(gè)；
（3）Kubernetes原生支持。借助KubeEdge，用戶可以在Edge節(jié)點(diǎn)上編排應(yīng)用，管理設(shè)備并監(jiān)視應(yīng)用和設(shè)備的狀態(tài)，就像云中的傳統(tǒng)Kubernetes 集群一樣；
（4）大量的應(yīng)用?？梢暂p松地將現(xiàn)有的復(fù)雜機(jī)器學(xué)習(xí)，圖像識(shí)別，事件處理和其他高級(jí)應(yīng)用程序部署和部署到Edge。

說(shuō)了這么多，和SOTA又有什么關(guān)系呢？

近日，在CNCF舉辦的云原生會(huì)議上，報(bào)道了某OEM打造的車云協(xié)同案例，通過(guò)KubeEdge這一輕量化的框架，將汽車作為節(jié)點(diǎn)接入云端，由云端動(dòng)態(tài)管理節(jié)點(diǎn)上的服務(wù)。

該架構(gòu)引入了容器化技術(shù)，將功能與底層軟件完全解耦，容器中承載的功能包括智能座艙、遠(yuǎn)程協(xié)作、機(jī)器學(xué)習(xí)、自動(dòng)駕駛等高存儲(chǔ)高算力的業(yè)務(wù)。實(shí)現(xiàn)后能為將來(lái)的第三方開(kāi)發(fā)平臺(tái)打下基礎(chǔ)，可構(gòu)建豐富的車輛功能生態(tài)，軟件可售業(yè)務(wù)也可基于此實(shí)現(xiàn)。更重要的是，車輛可改變僅通過(guò)FOTA實(shí)現(xiàn)功能迭代變革的現(xiàn)狀，通過(guò)該框架，或許能夠?qū)崿F(xiàn)不停車升級(jí)，節(jié)約用戶的時(shí)間成本。
傳統(tǒng)的分布式電子架構(gòu)，在軟件定義汽車的浪潮中，遇到了很多發(fā)展瓶頸。在新功能的迭代問(wèn)題上，系統(tǒng)復(fù)雜度大，缺乏靈活性和擴(kuò)展性；軟硬件緊耦合導(dǎo)致很難實(shí)現(xiàn)橫跨多個(gè)ECU/傳感器的復(fù)雜功能，對(duì)FOTA也提出了更高的要求。因此，計(jì)算能力中央化，建立通用的計(jì)算平臺(tái)是各家OEM的研究方向，云邊協(xié)同作為其中功能迭代的另一條通道，解決了FOTA升級(jí)時(shí)間長(zhǎng)、車輛狀態(tài)要求苛刻的痛點(diǎn)，一旦落地勢(shì)必將引起了各方的極大關(guān)注，可能成為SOTA的首選技術(shù)路徑。

小結(jié)

當(dāng)前，車機(jī)第三方APP的SOTA生態(tài)和運(yùn)營(yíng)已趨于成熟，但對(duì)于整車控制器相關(guān)功能的SOTA而言，技術(shù)落地尚在進(jìn)行中。不過(guò)，OEM在完成SOTA的基礎(chǔ)能力建設(shè)之后，內(nèi)部或第三方應(yīng)用的開(kāi)發(fā)者，只需遵從相應(yīng)的開(kāi)發(fā)規(guī)范，通過(guò)調(diào)用引擎的接口即可實(shí)現(xiàn)SOTA。相信在落地之后，對(duì)于軟件定義汽車又是一個(gè)極大的技術(shù)進(jìn)展。