特斯拉以OTA為特色，傳統車廠因為歷史包袱和成本因素，很少用OTA，特別是FOTA。新一代自適應Autosar專門為OT設計了UCM服務，降低OTA門檻和成本，同時大幅度提高OTA效能和安全性，讓使用者可以輕鬆超越特斯拉目前的OTA水準。本文由布穀鳥科技-產研首席分析師周彥武老師編寫。
OTA即空中升級，一般分FOTA和SOTA。前者為韌體OTA難度遠高於後者軟體OTA，前者可簡單看成ECU功能或控制策略的升級，後者主要是應用軟體的升級，如導航地圖等。特斯拉最早使用FOTA，其OTA供應商是三星哈曼，也是全球最大的OTA供應商，幾乎壟斷FOTA市場。三星哈曼OTA能力來自2015年收購的以色列廠家Redbend，當年收購價格為0。99億美元股票和0。71億美元現金，僅1。7億美元，收購價格可謂相當低。Redbend也是手機領域第一大OTA供應商，市場佔有率超過70%。
OTA生態結構
並非是特斯拉技術領先其他車廠才讓特斯拉擁有FOTA能力，而是絕大部分車廠為了降低研發成本，提高研發成果複用率，減少研發時間，避免新架構帶來的風險，絕大部分車廠的E/E架構都很老，傳統車廠一般一個車型生命週期是7到8年，而E/E架構延續使用一般是兩代，大多是本世紀初的水平。典型的如大眾，就算是最新的旗艦奧迪Q8，E/E架構中的Infotainment還是MOST匯流排，這是1998年的設計了。當然大眾已經痛改前非，今年匯入全新的MEB平臺。特斯拉沒有歷史包袱，可以使用最新的技術。
OTA供應商市場佔有率
實際OTA能力有限，因為目前很多功能受限於硬體的效能，中低端汽車硬體的效能落後手機領域10年以上，甚至15年以上，可能連在板程式設計或足夠的Flash空間都沒有。還有很多機械部件的缺陷或錯誤，當然無法靠OTA解決。想要軟體定義汽車對硬體要求極高，那種汽車註定只能是高階車。
OTA的三種主要型別
FOTA流程
典型的先進的FOTA流程分8個步驟，第一步是授權給電信運營商，第二步是將要更新的資料上傳到電信運營商的伺服器中，第三步是OTA的活動編排，包括與駕駛員和車輛的互動，對比前後軟體版本大小，提出差分包，詢問駕駛員升級安排。OTA供應商的主要工作就在這個環節。Redbend之所以市場佔有率超過50%就是因為其更新包最小，無需考慮作業系統，無需考慮晶片或儲存器等硬體限制。第四步是汽車上的T-Box下載更新包，下載後放在中央儲存器中。第五步是載入在FOTA主ECU上，也就是中央閘道器ECU，由中央閘道器分發到目標ECU。第六步，目標ECU確認無誤。第七步是啟用，自適應Autosar的FOTA，類似Windows的A/B分割槽升級，舊軟體在A區，新軟體在B區，新軟體不會對舊軟體造成任何中斷，檢測到發動機或驅動電機關閉且處於駐車狀態一次後（即真正重啟後），即以B區啟動。某些老舊的OTA設計不合理，一旦啟動OTA就全車鎖死，一動不動。在啟用前，ECU會診斷新軟體的可靠性或準確性，如果發現有誤，則自動回滾到升級前的狀態，並將這個錯誤回報雲端。如果準確無誤，就啟用新軟體。第八步，回報雲端伺服器。
這種FOTA離不開Redbend這樣第三方的支援，OEM或Tier1的工作量不小，沒有統一的標準。自適應Autosar為此特別增加了一個UCM模組來對應OTA，UCM定義了OTA過程中各種資料格式、介面和流程，讓FOTA變得易如反掌，人人都能像特斯拉那樣OTA。 UCM即Update and Configuration Management，它透過自適應Autosar的ara：：com服務介面實現各種功能，沒有直接的API，也就是說任何ECU裡都不需要新增UCM。而特斯拉現在有些OTA是需要自己開發API的。人人都能像特斯拉那樣OTA，並且位元斯拉更先進。此外，UCM可以將軟體包儲存到本地儲存庫中，在此處可以按照UCM Client 或UCM主Server請求的順序處理軟體包，無需等待資料緩衝。傳輸階段可以與處理階段分離，UCM支援不受限制地從多個Client接收資料。這都是特斯拉無法做到的。
UCM類似於Ubuntu裡的apt+dpkg或者yum+rpm，比如你使用163的源，然後你apt-get/yum install xxx的時候，就從你的源配置檔案中讀取位置（這裡是163的伺服器），然後可能在第一次會更新本地資料庫（這個資料庫中記錄163伺服器上擁有的軟體包，軟體包的依賴情況等），本地更新完了就從本地快取資料庫中讀取依賴情況以及軟體包的具體url，然後就會下載到本地快取目錄。下載完成後執行安裝操作。yum獲取到的是rpm，apt獲取的是deb，其實你都可以看成是一個壓縮包。裡面有對應的軟體。因為開發者不一樣，所以兩種軟體包的解包方式不一樣，和gz，rar包差不多，需要特定的命令去解，rpm包是rpm命令，deb是dpkg命令。
UCM輸入的安裝單位是軟體包。該程式包包含（Container）的一個或多個可執行檔案。除了應用程式和配置資料外，每個軟體包都包含一個軟體包Manifest，該Manifest提供元資料，例如軟體包名稱，版本，依賴關係以及可能的一些特定於供應商的資訊，以處理該軟體包。
UCM Master架構，也就是上文裡的FOTA Master。
診斷Client上傳軟體包（Software Package）透過UDS服務。之後經過分解和確認步驟進入到OEM的OTAClient裡，之後再進入UCM裡進行進一步處理。
UCM升級的全域性狀態機如上圖，跟普通的FOTA類似，多了一道清除安裝包的工序。
軟體Cluster狀態機，開始（Initial） 升級軟體（們）（SoftwareCluster） 被下載新增（ADDED）進車裡的ECU（PRESENT）， 然後經過升級（UPDATED）操作成功， 然後繼續留在ECU上（PRESENT）服務，可能過了很多年後，又有新的相同功能的軟體更新，於是我們就需要把這個之前的軟體刪除（REMOVED），之後他就完成了它的歷史使命，消失在了這輛車裡（Final）。
UCM軟體包有普通軟體A/B包，類似Windows的A/B分割槽升級，舊軟體在A區，新軟體在B區，重啟後，即以B區啟動，通常由軟體整合商提供。還有車輛包和後端包，都由OEM掌控，除了紅字部分必須以ARXML格式寫之外，其餘皆可自由發揮。車輛包的manifest中包含一、依賴關係： Dependencies繼承，軟體群集之間的依賴關係將取代軟體包清單中已定義的依賴關係。通常由車輛系統整合商用來新增與後端包裝供應商不知道的車輛系統相關的依賴項。二、Origin，URL，連結地址，用於升級日誌，跟蹤資料。三、版本。四、車輛目標Vehicles Target描述，包括與駕駛員互動，徵求其更新的意見或更新的時間與聯網方式安排。五，CampaignOrchestration。運動綜合編排。
軟體包分工模式
軟體包開發流程
Integrator必須使用和目標UCM 相容的打包工具。在整合商裝配完可執行apps，資料，Manifest等，接下來這個軟體包會和採用ARXML語言寫的整體Manifest軟體包一起嵌入到後端包中。簽名包含在軟體包清單中。為了避免軟體包清單修改，軟體包和軟體包清單以及簽名應該在一個container中。
使用自適應Autosar做FOTA的工作流程。
安全方面，自適應Autosar自然也很重視，採用的HSM硬體安全模組方式，上圖為處理器Flash儲存器內部升級流程，DCM為診斷通訊管理器，CSM為密碼服務管理器。安全車載通訊系統（SecOC）使用CSM對傳輸資料包中訊號值進行加密驗證。顧名思義，CSM管理密碼服務。透過製造商專用密碼庫實現。HSMs是由一種防火牆連線到主機系統匯流排的獨立微控制器，大部分現代車載SoC都有。HSM通常有其受保護的記憶體（RAM），程式程式碼和資料的專用快閃記憶體區，及其外圍裝置，例如定時器、用於某些密碼演算法的硬體加速器或用於真隨機數的發生器。它能夠訪問主機的所有硬體。在執行時實現系統的安全、認證啟動或主機監測。專用資料快閃記憶體可以用來儲存秘鑰，主機系統無法隨意訪問。這意味著主機可以請求HSM執行加密操作，而金鑰無需離開HMS。然而，在這方面，HSM的特殊優點是它是可自由程式設計的。作為一個獨立的微控制器，HSM能夠執行為當前用例最佳化的任何程式程式碼。這使得其安全性要求比簡單的協處理器更高。
這一切也是有代價的，那就是硬體要足夠強大，自適應Autosar中介軟體會消耗相當多的算力，雖然官方推薦使用20000DMIPS的處理器即可，但要流暢執行並保證足夠冗餘，推薦40000DMIPS算力的處理器。
