隨着汽車中軟件發揮的作用越來越重要，軟件定義汽車已經是行業內的共識。汽車行業的發展極有可能最終像手機產業一樣，基礎硬件差異會越來越小，關鍵在於汽車給用戶的體驗的多樣性，以及汽車產品在不同場景下滿足用戶需求的程度。而這種體驗的差異性在很大程度上是由汽車的軟件來決定的。當汽車中軟件代碼行數成正比不斷增長，隨之而來的是軟件工程複雜度指數級增長和軟件故障概率的提升。車輛無論是遇到軟件故障還是更新，如果每次更新都要去4S店，效率將非常低下，線下售後運營負荷也將沉重，既難以滿足智能汽車更新迭代的需求，也使得用戶體驗很差。
OTA的出現，完美的解決了軟件頻繁更新的問題，通過OTA技術則可以通過遠程快速完成缺陷的修復，避免了持續數月的進廠召回帶來的風險。通過OTA升級，可以不斷給用戶開啓新功能，不斷優化產品體驗，進行快速迭代，吸引客戶。通過OTA，可以幫助車企節省因爲軟件缺陷帶來的召回成本，節省大量的金錢和時間。但與此同時，OTA也帶來了新的挑戰，由於車載ECU衆多，網絡複雜，一旦車輛與外界建立通信，原本封閉的網絡更容易受到入侵的可能性，建立一整套安全防護體系是OTA的重要課題。
OTA設計要求
OTA設計主要從安全、時間、版本管理、異常處理等方面綜合考慮，具體爲：
- 升級安全是OTA的最基礎的要求。車輛上ECU的軟件運行狀況直接會影響到車輛上的人員的生命安全。從升級包製作，發佈，下載，分發，刷寫等環節，OTA需要從雲，網絡，車端來保證安全。在雲端通過證書，簽名和加密機制保證升級包的不會隨意被製作和發佈，升級包內容不會被惡意獲取。通過可靠的物理鏈路和安全傳輸協議來保證網絡傳輸安全。通過汽車的功能域隔離，劃分不同ASIL等級，通過冗餘設計保證整車的功能可靠性，通過安全啓動來保證可信的軟件在ECU上加載啓動運行。
- 版本管控對於OTA來說很重要，因爲車輛上ECU衆多，不同ECU有不同版本的軟件，不同車型ECU的需求有不同，版本也存在差異。版本的升級路徑管理，需要能夠全面準確進行管控。
- 整車升級進行車載ECU刷寫時，特別涉及動力域傳統ECU的刷寫，是通過CAN網絡進行安裝包的分發。由於CAN傳輸速率很低（實際典型的速率爲500Kb/s），並且CAN總線負載率通常要控制在30%以內，因此在帶寬允許的情況下，儘可能採取並行刷寫模式，選取刷寫時間最長的節點優先處理等設計原則減少OTA升級時長。
- 防變磚等異常處理。在OTA傳輸過程中，外界干擾或者其他因素導致刷寫異常或者中斷，車載ECU必須支持軟件回滾、斷點續傳、丟失重傳等處理機制。
OTA方案架構
一般而言，OTA方案架構,如下圖所示。
OTA雲平臺，主要包括了OTA雲端的升級模型管理，升級包管理，升級任務，升級策略以及日誌管理的功能。OTA雲端的設計要求是物理上實現租戶隔離的雲平臺，能夠支持多種協議下升級接入，支持多車型、多品牌、多種類型ECU軟件版本管理，升級包製作，升級模型定義和升級策略和規則配置。能夠支持批量升級任務的調度和分發。能夠提供適配層與TSP平臺和OEM的IT系統進行集成。性能上能否實現100萬以上車輛升級併發，差分效率能夠不小於90%，可靠性能否實現3個9的要求和7*24小時的系統連續服務。
升級模型是用於定義目標升級設備模型的基本信息和設備模型所具備的升級能力支持情況的功能。在整車升級中，因爲涉及到車型與ECU的配套關係，因此升級模型一般能夠體現一個車型下各個零部件ECU的依賴關係，例如多個零部件ECU直接軟件包配套關係和升級順序控制，對於升級任務在設備側的準確完整執行非常重要。此外，升級模型還包含了升級規則的定義。升級規則可以用於描述升級流程中，用於允許升級能否繼續進行的判定條件。在整車升級中，一般包括了一款車型在升級下載前，下載中，安裝前，和安裝中的判定規則配置。
軟件包是用於升級使用的程序或配置。軟件包包含有設備軟件修復的缺陷或者要加入的新功能，更新前和更新後需要做哪些驗證檢查邏輯等，都會被打包到這個文件裏。軟件包一般都是由設備軟件供應商提供的，會通過特定渠道，發佈給OTA服務方。在整車升級中，OTA 分爲兩類，一種是 FOTA（Firmware-over-the-air，固件在線升級），指的是給一個零部件的ECU閃存下載完整的固件鏡像，或者修補現有固件、更新閃存。而固件之外的軟件更新，就是 SOTA（Software-over-the-air，軟件在線升級）。例如，車機屏應用程序和車載地圖的升級，都屬於 SOTA 的範疇。這兩種文件形態，都屬於軟件包管理的範疇，通過軟件包分類進行區分。軟件包管理允許軟件包能夠基於軟件包版本進行分版本的存儲和管理，並維護軟件類型，全量與差分等屬性。
升級包是在升級任務中，用於真正下載和安裝部署的文件。升級包可以是設備軟件供應商發佈的軟件包文件，也可以是經過OTA平臺完成了打包處理的文件。常見的升級包製作處理包括文件壓縮合並，生成特定的文件描述信息，文件簽名和加密處理。許多物聯網設備和車輛設備的閃存都比較小，升級包需要要能在嵌入式設備的小內存中完成安裝。因此，升級包會盡可能地壓縮大小。爲了保證效率和成功率，OTA平臺在升級包製作中提供了差分生成的離線和在線工具。升級差分包之前，通過比較新舊版本之間的差異，生成差異文件。差分更新的核心技術是各家OTA供應商掌握的字節差分算法。
升級任務是OTA平臺用於執行和監控一組設備的升級活動的集合。升級任務可針對特定範圍的設備，使用相應的升級包和升級策略，進行升級任務創建，下發，監控，狀態維護等整組活動的管理。升級任務的監控功能，提供了對一組升級活動中，升級任務狀態，進度和結果的反饋。按照升級任務狀態的狀態，主要包含了成功，失敗，升級中等設備的數量和各個狀態下的比例。升級任務的控制功能，提供了對一組升級活動中，升級任務的啓動，停止，暫停，恢復，重啓，撤銷等操作能力，實際上是維護了任務狀態機的狀態變遷干預能力。
升級策略是升級活動中的用於描述任務特徵和目標設備升級行爲的配置。升級主要會涉及到下載和安裝兩個階段，升級策略中，一般會包含升級包下載策略和升級包安裝的策略，以及異常情況下的處理策略。例如，在整車升級中，升級策略包括靜默升級，常規升級和緊急升級的分類，也包括了升級包下載前，是否需要通知給用戶下載確認的配置。
升級日誌包括雲平臺的日誌，車端與雲平臺通信產生的日誌和車端升級程序蒐集上來的日誌。主要用於升級失敗後的分析和支撐升級運維運營管理。
OTA車端主要包含通信終端和各功能域的ECU。OTA通信終端一般由TBOX負責，上面運行OTA升級管理程序和升級代理程序。其中，OTA升級管理程序OTA Manager是負責連接車輛與OTA雲平臺的管理程序。它實現了端雲的安全通信，包括協議通信鏈接管理，升級指令接收和升級狀態發送，升級包下載、升級包解密、差分包重構等功能。升級代理Update Agent，是爲了兼容不同的車內通信網絡和通信協議，以及不同OEM間各品牌車型的接口差異，進行封裝適配的部分。升級代理提供了統一接口，由OTA廠商負責實現接口，完成接口和業務邏輯的適配。
車端架構按功能域劃分，分爲動力系統域、車身系統域、影音娛樂域、ADAS主動安全域、自動駕駛域，不同的功能域有着不同的通信網絡和功能安全等級設計。 。自動駕駛域或者影音娛樂域等部分ECU存在主備分區的設計，即ECU內部用於兩片區域，一部分用於存儲當前運行的程序，一部分用於存儲備份程序。除第一次安裝或者設備下線時，ECU內部只有一份軟件外，之後更新安裝的軟件都會與上一份共存。當前運行的是最新的軟件，如果升級過程中發生錯誤或者刷寫的程序不能運行，ECU根據OTA Manager的升級策略要求，能否自動回滾至上一個版本的程序，防止車輛ECU變磚。
OTA場景策略與規則
從OEM車聯網運營角度劃分，根據車輛銷售前和銷售後不同，OTA升級場景一般會區分爲靜默升級和非靜默升級。靜默升級主要用於銷售前處於庫存狀態的車輛升級。OTA雲平臺通過發送遠程喚醒命令，通過TBOX喚醒車輛上電，連接到平臺進行升級任務的處理。非靜默升級主要是用於是銷售後車輛歸屬於車主後的升級場景，軟件升級變更需告知給車主，在車主知情和同意的下進行升級。非靜默升級其中又分爲普通升級和緊急升級，緊急升級一般是用於特別重要安全補丁的推送升級，車主知情但是無法拒絕。
OTA升級任務下發到車輛後，升級管理程序OTA Manager也必須判斷車輛條件是否符合。對於不符合條件的車輛，升級管理程序必須中止升級任務並上報給雲平臺。在OTA架構中，升級規則定義了各個車型在升級包下載，安裝刷寫階段的判斷條件。升級規則會隨着雲平臺上的升級任務下發到車輛。例如最低版本要求，車輛運行狀態、車輛位置。某電動車廠商的車輛在長安街街心升級導致交通堵塞的新聞曾在互聯網上議論紛紛，如果在升級執行前能否判斷車輛處於一個不適合升級的地點，那麼升級任務也不會推送給停車等候紅綠燈的車主了。一個好的OTA系統一定是能夠靈活的配置升級條件，並且合理準確控制升級和用戶推送的系統。
最後，結合OEM運營的要求，OTA升級還需要能夠靈活定義升級的具體範圍，升級時機，升級內容，提示事項，失敗後給用戶的失敗處理提示，提升大規模升級中的運營效率和運營體驗，持續爲車主和OEM提供價值。
點擊這裏，瞭解更多精彩內容