關於汽車OTA，這篇科普文能告訴你

隨着汽車中軟件發揮的做用愈來愈重要，軟件定義汽車已是行業內的共識。汽車行業的發展極有可能最終像手機產業同樣，基礎硬件差別會愈來愈小，關鍵在於汽車給用戶的體驗的多樣性，以及汽車產品在不一樣場景下知足用戶需求的程度。而這種體驗的差別性在很大程度上是由汽車的軟件來決定的。當汽車中軟件代碼行數成正比不斷增加，隨之而來的是軟件工程複雜度指數級增加和軟件故障機率的提高。車輛不管是遇到軟件故障仍是更新，若是每次更新都要去4S店，效率將很是低下，線下售後運營負荷也將沉重，既難以知足智能汽車更新迭代的需求，也使得用戶體驗不好。

OTA的出現，完美的解決了軟件頻繁更新的問題，經過OTA技術則能夠經過遠程快速完成缺陷的修復，避免了持續數月的進廠召回帶來的風險。經過OTA升級，能夠不斷給用戶開啓新功能，不斷優化產品體驗，進行快速迭代，吸引客戶。經過OTA，能夠幫助車企節省由於軟件缺陷帶來的召回成本，節省大量的金錢和時間。但與此同時，OTA也帶來了新的挑戰，因爲車載ECU衆多，網絡複雜，一旦車輛與外界創建通訊，本來封閉的網絡更容易受到入侵的可能性，創建一整套安全防禦體系是OTA的重要課題。

OTA設計要求

OTA設計主要從安全、時間、版本管理、異常處理等方面綜合考慮，具體爲：

1.升級安全是OTA的最基礎的要求。車輛上ECU的軟件運行情況直接會影響到車輛上的人員的生命安全。從升級包製做，發佈，下載，分發，刷寫等環節，OTA須要從雲，網絡，車端來保證安全。在雲端經過證書，簽名和加密機制保證升級包的不會隨意被製做和發佈，升級包內容不會被惡意獲取。經過可靠的物理鏈路和安全傳輸協議來保證網絡傳輸安全。經過汽車的功能域隔離，劃分不一樣ASIL等級，經過冗餘設計保證整車的功能可靠性，經過安全啓動來保證可信的軟件在ECU上加載啓動運行。

2.版本管控對於OTA來講很重要，由於車輛上ECU衆多，不一樣ECU有不一樣版本的軟件，不一樣車型ECU的需求有不一樣，版本也存在差別。版本的升級路徑管理，須要可以全面準確進行管控

3.整車升級進行車載ECU刷寫時，特別涉及動力域傳統ECU的刷寫，是經過CAN網絡進行安裝包的分發。因爲CAN傳輸速率很低（實際典型的速率爲500Kb/s），而且CAN總線負載率一般要控制在30%之內，所以在帶寬容許的狀況下，儘量採起並行刷寫模式，選取刷寫時間最長的節點優先處理等設計原則減小OTA升級時長。

4.防變磚等異常處理。在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提供價值。

點擊關注，第一時間瞭解華爲雲新鮮技術~