導讀：整車OTA類型主要分為兩類，FOTA（Firmware-over-the-air）和SOTA（Software-over-the-air），兩者均為主機廠重點關注及逐步落地的領域，可適應不同場景的OTA需求。
本文主要介紹當前對于整車功能的SOTA技術鏈路概述。本文介紹以下三種技術路徑：一種是針對車機、儀表APP類應用的基于Android平臺的SOTA架構；其二針對基于Autosar AP的控制器，通過UCM服務實現新功能的上線；最后一種為當前的研究熱點——云邊協同策略。
一、FOTA和SOTA概述
FOTA通過給車輛控制器下載安裝完整的固件鏡像，來實現系統功能完整的升級更新。例如升級車輛的智駕系統，讓駕駛員享受越來越多的輔助駕駛功能；升級車輛的座艙系統，提高駕駛員疲勞檢測的準確率；升級車輛的制動系統，提升車輛的制動性能。特斯拉曾在Model 3在上市后，發現其剎車邏輯存在優化空間，通過FOTA對制動系統進行升級之后，制動剎車距離由46m縮短為40m，大幅提升了行車時的安全性。
FOTA涉及控制器核心功能（控制策略）的一個完整的系統性更新，對整車性能影響較大，升級過程對時序、穩定性、安全性要求極高，同時升級前置條件包括擋位、電量、車速等要求，升級過程一般不支持點火用車，蔚來車主曾在首都長安街給全國車主免費上過生動的一課。
SOTA通過給車輛控制器安裝“增量包”，來實現控制器功能的一個“增量”更新，一般應用于娛樂系統和智駕系統。例如更換多媒體系統操作界面，優化儀表盤顯示風格，更新娛樂主機里的地圖程序時，用到的都是SOTA升級方式。
SOTA涉及控制器應用層一個小范圍的功能局部更新，對整車性能影響較小，升級前置條件要求較低。SOTA的增量更新策略，可以大幅減小升級包文件大小、從而節約網絡流量和存儲空間。可以想象隨著SOTA范圍的擴大及技術的成熟，以后在車輛行駛的過程中，吃著火鍋唱著歌，車輛就可以自動完成功能的更新迭代。
FOTA和SOTA功能定義目前沒有明確清晰的界限。遇到男同事咨詢時，我總是不負責任的舉出手機升級的例子。從iOS14更新到iOS15是FOTA，從微信7.9升級到9.0是SOTA。
本文主要介紹當前對于整車功能的SOTA技術鏈路概述。本文介紹以下三種技術路徑：一種是針對車機、儀表APP類應用的基于Android平臺的SOTA架構；其二針對基于Autosar AP的控制器，通過UCM服務實現新功能的上線；最后一種為當前的研究熱點——云邊協同策略。
二、Android應用的實現
Android的SOTA技術已經相當成熟，點擊應用商店中應用旁的更新按鈕即可實現，讀者在自己的手機上已操作不下百遍，當前不少車機、儀表的系統基于Android實現，針對Android平臺的APP應用、主題、皮膚，實現路徑類似于手機的應用商城，云端建立版本倉庫，用戶在車機軟件商店點擊安裝后，車端從TSP下載安裝包(apk)，由車機或儀表執行安裝或卸載。
三、基于AP AutoSAR 的SOA實現
Autosar CP架構下，所有應用都是靜態配置的，一旦軟件編譯完成就不可更改，其調用的周期也是確定。而在Autosar AP架構下，一切都是OS中的進程，應用是動態運行的，何時調用、進程生存周期、資源占用及進程結束等都由系統動態管理，好比你手機上的App何時打開、運行后其會調用的資源及何時關閉都是動態進行的。應用們通過ARA(Autosar Run-time for Adaptive)進行通訊，可支持或擴展對SOME/IP、TSN、DDS等SOA通訊技術的應用。
在AP平臺的服務中，UCM負責安全地更新，安裝，刪除和保留軟件記錄。類似Linux中的dpkg或YUM等軟件包管理系統，可以更新或修改Adaptive Platform上的軟件。
UCM實現SOTA功能的業務流程如下圖所示，其中包含如下幾個重要的模塊。
UCM Master：為UCM提供服務接口的客戶端，它從云端或診斷工具接收、驗證、解析軟件包，并將軟件包傳輸至UCM或診斷應用程序進行后續激活、回滾等處理。
UCM：為與UCM Master處于同一網絡中的UCM服務實例。
OTA Client：建立云端和 UCM Master 之間的通信，以傳輸增量包的信息。
車輛狀態管理器：從多個車端ECU收集狀態，并計算相應的安全狀態，根據車輛包中的安全策略，在發生變化時通知UCM Master。如果不滿足安全策略，UCM Master可采取相關措施，如通知用戶當前不滿足前置條件，同時推遲、暫停或取消更新。
整個SOTA流程包含以下幾個過程：
1、升級包的打包和組裝
UCM的安裝單位是軟件包。該程序包包含一個或多個可執行文件。除了應用程序和配置數據外，每個軟件包包含Manifest，Manifest是arxml類型的文件，元數據包括軟件包名稱、版本、依賴關系等。
2、升級包傳輸
使用UCM服務接口的客戶端可以位于同一個AUTOSAR AP平臺上，也可以是遠程客戶端。一個或多個軟件包傳輸到UCM的內部緩沖區。
傳輸完成后，會對軟件包的內容進行身份驗證。
3、升級包安裝
安裝和卸載操作通過UCM的ProcessSwPackage接口執行。值得一提的是，UCM支持A/B分區升級。對于A/B分區升級方案，讓舊版本先在A區運行，升級非活躍的B分區。處理完成重啟后，運行B分區的新版本。A/B分區的升級策略可以實現車輛行駛過程中的應用部署，即便升級失敗也不會影響整車的其他功能。
4、升級包激活
對于一些功能，UCM在升級過程中必須同時更新多個軟件，因此UCM需根據軟件包的依賴關系后激活。如升級是通過 A/B 分區的，分區之間發生交換，新的非活動分區成為新活動分區的副本。
5、升級包回滾
遇到異常應用需要回滾至穩定版本，UCM決定回滾的版本選擇，而回滾操作由Autosar AP的Persistency服務處理。
四、基于云邊協同的實現
介紹之前，先絮叨幾句虛擬化、虛擬機和容器。每位程序員的開發環境配置可能會有所不同，這會導致你的代碼直接拿到同事的電腦上無法正常運行。企業的開發環境、測試環境和生產環境在配置和所依賴的文件上也會有所不同。如何確保在不同硬件、不同環境都能正常運行你的BUG，是當前軟件行業的熱點。云原生是該理念的最佳實踐，通過微服務，容器化，持續交付等新技術，實現了開發運維一體化，讓服務生于云，長于云。
虛擬機（VM，Virtual Machine）是虛擬化技術的落地先鋒，通過軟件模擬的具有完整硬件系統功能的、運行在一個完全隔離環境中的完整計算機系統，可以顯著提高設備的工作效率，減輕了企業對硬件資源的依賴。
當前汽車行業落地的是Hypervisor 的虛擬化方案，其可以在多核異構的單芯片上運行多個不同類型的操作系統，各系統間共享硬件資源，既是彼此獨立又可交互信息。Hypervisor 即滿足了日益復雜場景下的不同業務需求，又提高了硬件資源的使用效率，大幅降低了成本，虛擬化所具備的不同操作系統間的隔離能力，大大提升了系統的可靠性和安全性。
座艙中的聯屏車機往往會采用該方案，實現主駕和副駕不同系統的需求。但是每個VM都需要安裝操作系統才能執行應用程序，倘若用戶只需在VM中運行或遷移簡單的應用程序時，采用VM不僅操作繁瑣而且浪費大量資源，因此企業迫切需要輕量級的虛擬化技術。
容器技術起源于Linux，是一種輕量化的內核虛擬化技術，通過隔離進程和資源，共享同一個操作系統內核，可以保證在開發、測試以及生產等不同環境和硬件配置下都具有移植性、一致性。虛擬機技術與容器技術的典型功能架構框圖如下。
容器技術和虛擬機技術關鍵特性的對比如下。
容器技術隨著Docker的出現才在“格子襯衫”群體中流行開來。Docker將集裝箱思想運用到軟件打包技術上，為代碼提供了一個基于容器的標準化運輸系統，其產品logo就是這一思想的最形象詮釋。
Docker 是一個開源的應用容器引擎，開發者利用Docker可以將任何應用及其依賴打包成一個輕量級、可移植、自包含的鏡像，然后發布到任何流行的 Linux、Windows等操作系統的機器上。
Docker 技術包含三個核心基礎概念：
（1）鏡像（Image），一個層疊的只讀文件系統，除了提供容器運行時所需的程序、庫、資源、配置等文件外，還包含了一些為運行時準備的配置參數。鏡像不包含任何動態數據，其被創建之后內部不會被改變。鏡像用來創建 Docker容器，同一個鏡像文件，可以生成多個同時運行的容器；
（2）容器（Container），容器是鏡像創建的運行實例，容器可以被創建、啟動、停止、刪除、暫停等。每個容器都是相互隔離；
（3）倉庫（Registry），鏡像文件存放的地方。用戶創建完鏡像后，可以將其上傳到到倉庫，需要在另一臺主機上使用該鏡像時，只需要從倉庫上下載即可。
Docker使用客戶端/服務器架構模式，運行邏輯如下圖所示。Docker守護進程作為服務端的請求，負責構建、拉取、啟動Docker容器。Docker守護進程一般在Docker主機后臺運行，用戶使用Docker客戶端直接跟Docker守護進程進行信息交互。
Docker客戶端，向 Docker守護進程發起Docker構建、拉取、啟動的請求，Docker守護進程完成操作并返回結果。Docker客戶端既可以在訪問本地Docker守護進程，也可以訪問遠程Docker守護進程。藍色虛線展示了Docker構建并存放于本地Docker的構建工作流。紫色虛線展示了從鏡像倉庫拉取鏡像至Docker主機或將Docker主機鏡像推送至鏡像倉庫的拉取工作流。紅色虛線展示了鏡像安裝及容器啟動的啟動工作流。
Docker主機，一個物理或者虛擬的機器用于執行 Docker守護進程和容器。
Docker守護進程，接收并處理Docker客戶端發送的請求，監測Docker API的請求和管理Docker對象，比如鏡像、容器、網絡和數據卷。
Docker目前在互聯網的線上行業應用非常廣泛，實現了“Write Once，Run Everywhere”的目標，常見的應用場景如下。
（1）對于開發而言，服務和應用更容易跨平臺移植。避免了由于平臺的變化而生成的Bug，同樣也避免了和測試、運維之間扯皮甩鍋。不用再抱怨“怎么在正式環境上總是BUG，測試環境可是沒這個問題的”。老板再也不用擔心環境遷移造成問題的可能性，更好給下屬們分鍋了。
（2）對于運維而言，可以通過容器編排應用（如K8S），按業務需求自動管理應用的實例，適合動態擴容和縮容。典型的場景，就是電商的雙十一活動會導致訂單服務的負載劇增，無容器技術時，運維需要“自愿”通宵加班，手動新增訂單服務的實例，并實時監控各實例的狀態。目前，運維可能左手咖啡，右手王者，眼睛盯一下就可以了。
對于上文提到的容器編排，你需要管理運行應用程序的容器，并確保不會停機。例如，如果一個容器發生故障，則需要啟動另一個容器。如果系統處理此行為，會不會更容易？這時，Kubernetes和KubeEdge就出場了。
Kubernetes提供了一個可彈性運行分布式系統的框架，滿足擴展要求、故障轉移、部署模式等。Kubernetes能夠自主的管理容器來保證云平臺中的容器按照用戶的期望狀態運行。在Kubernetes中，所有的容器均在Pod中運行，一個Pod可以承載一個或者多個相關的容器，同一個Pod中的容器會部署在同一個物理機器上并且能夠共享資源。Pod也可以包含0個或者多個磁盤卷組，這些卷組將會以目錄的形式提供給一個容器，或者被所有Pod中的容器共享。然而，Kubernetes的應用場景僅限于線上的云服務，并不支持設備端。
KubeEdge基于Kubernetes構建，可將本機容器化應用編排和管理擴展到邊緣端設備。為網絡和應用程序提供核心基礎架構支持，并在云端和邊緣端部署應用，同步元數據，主要優勢有如下四點：
（1）邊緣計算。通過在Edge上運行的業務邏輯，可以在生成數據的本地保護和處理大量數據。這減少了網絡帶寬需求以及邊緣和云之間的消耗。這樣可以提高響應速度，降低成本并保護客戶的數據隱私；
（2）簡化開發。開發人員可以編寫基于常規HTTP或MQTT的應用程序，對其進行容器化，然后在Edge或Cloud中的任何位置運行它們中的更合適的一個；
（3）Kubernetes原生支持。借助KubeEdge，用戶可以在Edge節點上編排應用，管理設備并監視應用和設備的狀態，就像云中的傳統Kubernetes 集群一樣；
（4）大量的應用。可以輕松地將現有的復雜機器學習，圖像識別，事件處理和其他高級應用程序部署和部署到Edge。
說了這么多，和SOTA又有什么關系呢？
近日，在CNCF舉辦的云原生會議上，報道了某OEM打造的車云協同案例，通過KubeEdge這一輕量化的框架，將汽車作為節點接入云端，由云端動態管理節點上的服務。
該架構引入了容器化技術，將功能與底層軟件完全解耦，容器中承載的功能包括智能座艙、遠程協作、機器學習、自動駕駛等高存儲高算力的業務。實現后能為將來的第三方開發平臺打下基礎，可構建豐富的車輛功能生態，軟件可售業務也可基于此實現。更重要的是，車輛可改變僅通過FOTA實現功能迭代變革的現狀，通過該框架，或許能夠實現不停車升級，節約用戶的時間成本。
傳統的分布式電子架構，在軟件定義汽車的浪潮中，遇到了很多發展瓶頸。在新功能的迭代問題上，系統復雜度大，缺乏靈活性和擴展性；軟硬件緊耦合導致很難實現橫跨多個ECU/傳感器的復雜功能，對FOTA也提出了更高的要求。因此，計算能力中央化，建立通用的計算平臺是各家OEM的研究方向，云邊協同作為其中功能迭代的另一條通道，解決了FOTA升級時間長、車輛狀態要求苛刻的痛點，一旦落地勢必將引起了各方的極大關注，可能成為SOTA的首選技術路徑。
六、小結
當前，車機第三方APP的SOTA生態和運營已趨于成熟，但對于整車控制器相關功能的SOTA而言，技術落地尚在進行中。不過，OEM在完成SOTA的基礎能力建設之后，內部或第三方應用的開發者，只需遵從相應的開發規范，通過調用引擎的接口即可實現SOTA。相信在落地之后，對于軟件定義汽車又是一個極大的技術進展。
作者：18號線不到安研路
