OTA 技術最早應用在 PC 電腦和移動手機行業(yè)，近幾年才開始在汽車行業(yè)中 廣泛應用。然而車內通訊網絡的復雜性、汽車電子系統(tǒng)的碎片化等因素限制著 OTA 技術整車范圍普及。本章從 OTA 定義與應用場景、OTA 實現流程和“云-管-端”關鍵技術進行研究，為行業(yè)從業(yè)者對 OTA 技術的設計開發(fā)、技術驗證和生產工作提供參考。
一、汽車 OTA 定義與應用場景
1.1 OTA 定義及分類
OTA 是 Over the Air 的縮寫，通常指的是遠程無線方式，OTA 技術可以理解為一種遠程無線升級技術。在無特別說明情況下，本文所指的 OTA 是所有汽車遠程升級的統(tǒng)稱。實現 OTA 的基礎是車輛具備遠程聯網功能，這意味著正是智能網聯汽車滲透率的快速增長，推動了 OTA 的快速普及。
OTA 的本質是通過技術實現軟件更新，智能網聯汽車與傳統(tǒng)汽車的軟件升級不同之處在于，通過 OTA 技術，原始設備制造商（OEM）可以不用通過售后服務中心，而是直接遠程連接目標聯網車輛，將軟件更新推動至待升級的車輛。
隨著 OTA 的應用越來越廣泛，針對升級對象的不同，延伸出來很多不同的 概念。人們在談及 OTA 相關業(yè)務時通常會在前面增加一個具體對象，用于表明使用 OTA 技術實現何種功能，比如遠程軟件升級、遠程固件升級、遠程配置、遠程數據更新等。然而在一些 OTA 解決方案中，已經模糊了不同類型遠程升級的邊界，將所有可升級的軟件對象抽象為軟件簇，而軟件簇包含了從小到配置字信息大到整個操作系統(tǒng)固件所有顆粒度的對象。并且，GB《汽車軟件升級通用 技術要求》中對軟件升級（Software Update）的定義已經涵蓋了下述幾種 OTA 概念（遠程診斷除外）。
1.1.1 遠程軟件升級(SOTA)
SOTA（Software Over-The-Air），即遠程軟件升級，是指在操作系統(tǒng)的基礎上對應用程序進行遠程升級。SOTA 通過遠程下載并給車輛安裝“應用程序升級包”，來實現控制器功能的一個“增量”更新， 一般應用于娛樂系統(tǒng)和智駕系統(tǒng)。
SOTA 一般涉及應用層小范圍的功能局部更新，不包括汽車核心系統(tǒng)，對整 車性能和安全影響較小，升級前置條件要求較低。SOTA 的增量更新策略， 可以大幅減小升級包文件大小、從而節(jié)約網絡流量和存儲空間。
1.1.2 遠程固件升級(FOTA)
FOTA（Firmware Over-The-Air），即遠程固件升級，是指囊括車輛底層算法至頂層應用的綜合升級，在不改變車輛原有配件的前提下，通過遠程下載并寫入新的固件程序進行設備升級。FOTA 包括驅動、系統(tǒng)、功能、應用等的升級，與硬件的更換沒有關系。
FOTA 涉及車輛的核心系統(tǒng)，包括但不限于汽車動力控制系統(tǒng)、底盤電子系 統(tǒng)、自動駕駛系統(tǒng)、車身控制系統(tǒng)等核心零部件的控制系統(tǒng)，可以改變車輛的充放電、動能回收、加速性能、輔助駕駛系統(tǒng)邏輯等與深度駕控有關的體驗。理論上所有支持固件更新的電子控制單元（ECU）都可以涵蓋在 FOTA 范圍中。
1.1.3 遠程配置(COTA)
COTA（Configuration Over-The-Air），即遠程配置，是指通過 OTA 的方式實現遠程修改配置字，以達到修改軟件功能配置的目的。配置字是一組以數據標識碼(DID)方式存儲在 ECU 上的數據，可通過診斷指令進行讀取和修改。它根據特定的編碼規(guī)則與車輛功能特征碼一一對應，通過配置可判斷車輛的功能配置，軟件可根據配置實現相應的功能。遠程配置常見的應用場景是遠程開啟和關閉某項功能，例如軟件訂閱功能。
1.1.4 遠程診斷/遠程數據更新(DOTA)
DOTA 有兩種常見解釋：
DOTA(Data Over-The-Air)，即遠程數據更新，是指一些獨立于軟件程序存在的數據包的更新，比如，地圖數據、語音數據和算法模型數據等。這類更新的特點是數據量比較大，更新流程相對獨立，比如，地圖數據通常由地圖應用自行更新，而數據量也可能高達幾 G 到幾十G。
DOTA(Diagnostic Over-The-Air)，即遠程診斷，通過云平臺實時數據采集監(jiān)控，主動性地檢查汽車系統(tǒng)異常問題，為遠程問題修復與人工問題修復提供決策依據。遠程診斷的觸發(fā)方式有兩種，一種是用戶在車輛上發(fā)現異常狀況的響應式；另一種是周期性收集通訊網絡、應用程序、硬件效能、使用操作記錄、系統(tǒng)程序等狀態(tài)信息，利用大數據后臺分析監(jiān)測故障。
1.1.5 其他類型(XOTA)
隨著汽車智能化程度越來越高，除了車輛本身軟件的升級外，還可能會涉及 到外部智能設備交互功能的軟件更新，比如，智能鑰匙、AR 設備等。目前有些企業(yè)和組織將所有與車輛相關聯的軟件升級統(tǒng)稱為 XOTA，即 Everything Over-The-Air 的意思。
1.2 OTA 應用場景
1.2.1 車輛生命周期維度
從開發(fā)者編譯生產出目標版本軟件，到該軟件更新至目標硬件設備上的全過 程涉及多個階段。在不同的階段，受產品形態(tài)和生產環(huán)境限制，所適用的軟件更新目的和手段也有所不同，如下表 2- 1 所示。目前，大部分車企的 OTA 主要集中在售后軟件更新，但不論是從效率上還是成本上 OTA 都體現出了巨大的優(yōu)勢。隨著 OTA 應用越來越成熟，從單一的售后升級場景向更多的應用場景發(fā)展是的必然趨勢。
表 2-1 車輛生命周期維度的軟件更新應用
| 車輛生命周期 | 軟件更新目的及手段 |
| 零部件階段 | ECU 供應商產線是最早可以切換到最新軟件版本的節(jié)點，該節(jié)點進行軟件切換可避免舊版本軟件繼續(xù)生產從而流向下游，稱為供應商產線斷點。由于該階段還是零件狀態(tài)，通常只能通過芯片燒錄工具或者供應商特定的工具進行軟件更新，不適用OTA 方式。 |
| 總裝階段 | 由于零件需提前訂購，仍有一定量的零部件在供應商產線斷點前流轉到 OEM 庫存，總裝線的電檢工位可以完成部分軟件的刷寫，稱之為 EOL(End of Line)軟件刷寫。然而 EOL軟件刷寫會影響產線節(jié)拍，導致 OEM 不會在產線進行大量軟件刷寫。 總裝完成時車輛已經具備 OTA 的條件，如果通過 OTA 方式進行產線刷寫，可實現多車并線刷寫且不受產線工位影響，將極大提高產線軟件灌裝的效率。目前，已經有個別企業(yè)實現總裝階段 OTA。 |
| 駁運階段 | 車輛從總裝線下線到經銷商庫存要經過一定的駁運過程。對于體量大且緊急程度不高的軟件，在總裝線灌裝會影響效率，如果利用駁運過程進行軟件更新，能降低對產線節(jié)拍的影響。OTA 使得利用駁運過程更新軟件成為一種可能，但在駁運過程中更新對電源供應管理及車輛安全是否有影響需要更深一步考慮。 |
| 售前庫存 | 經銷商通常有一定的庫存車輛，在正式銷售前庫存車輛可能需要對軟件版本進行升級。以往是在進行最終售前檢查時，將軟件更新到最新版本，存在更新時間長，影響用戶交付體驗等問題。 OTA 技術可將庫存車輛自動同步至最新版本，大大減少在交付過程中軟件更新的耗時，提升效率。 |
| 售后階段 | 過去的售后階段軟件更新，用戶需要將車駕駛到指定維修站完成更新。 通過OTA 技術，用戶可隨時隨地通過簡單操作完成軟件更新，使車輛“常用常新” 。目前已成為汽車企業(yè)增加用戶粘度和解決軟件售后問題及構建生態(tài)服務體系的一個重要手段。 |
1.2.2 軟件運營管理維度
從軟件運營管理的維度 OTA 的典型應用場景如下表 2-2 所示。
表 2-2 軟件運營管理維度的軟件更新典型應用場景
| 典型應用場景 | 應用場景描述 |
| 軟件召回 | 軟件引起重大功能缺陷時，例如存在功能安全、網絡安全/數據安全重大風險、法規(guī)相關問題，通過OTA 方式召回，可以在短時間內批量完成問題軟件的修復，盡可能降低軟件缺陷造成的影響，效率高且成本低。 |
| 問題修復 | 對于一些非嚴重性問題，通過OTA 方式，可以周期性推送軟件版本，進行問題修復。 |
| 性能優(yōu)化 | 與缺陷修復類似，OTA 方式的便捷性，使得性能優(yōu)化類的軟件更新也逐漸得以重視，目前已經是常見的OTA 場景之一。 |
| 軟件個性化定制 | 此應用場景通常為COTA 應用，比如用戶可根據個人需求，完成怠速調整、車下啟動/熄火，自動啟停等參數的設置更新。 |
| 新功能交付 | OTA 使得售后軟件功能持續(xù)迭代成為可能。通過 OTA 可新增功能的多少，已成為用戶評價OEM 的對重要指標之一。 |
| 付費功能訂閱 | 功能訂閱是新功能交付應用場景衍生出來的一種新的行業(yè)形態(tài)。車企在售賣車輛之后，針對部分新增軟件功能以付費方式供用戶購買使用。這使得車企除了車輛銷售之外，有了新的盈利可能性，這也是目前汽車企業(yè)非常樂于探索的一種 OTA 應用場景。 |
二、 汽車 OTA 技術體系
2.1 OTA 實現流程
汽車軟件更新的本質是將供應商或者 OEM 內部開發(fā)部門編譯出來的軟件或 者數據替換當前車輛 ECU 中的版本，以實現預期的特定功能。因此，汽車軟件升級所需要的核心工作是建立遠程傳輸鏈路并實現 OEM 云端系統(tǒng)遠程更新車輛 ECU 中的軟件數據。同時，為了準確、安全、可靠地完成 ECU 軟件的更新，OTA 系統(tǒng)需要云端管理系統(tǒng)對軟件、升級對象進行管理，以實現人工操作到自動化的轉變；車端系統(tǒng)需要完成軟件數據的接收和分發(fā)工作，并保證無專業(yè)技師操作情況下的安全升級。
圖 2-1：OTA 實現流程(來源 AutoSAR)
圖2-1 是一個典型的 OTA 系統(tǒng)框架，包含了三個基本要素，即云端的 OTA 平臺、車端 OTA 主控、OTA 對象。其中：OTA 云平臺負責 OTA 升級包管理、車輛管理及 OTA 發(fā)布等功能，車端 OTA 主控負責從 OTA 云平臺下載升級包并將其刷寫到目標 ECU ，OTA 升級對象即最終軟件刷寫的主體，從主控接收軟件并完成自身軟件更新。OTA 的基本實現流程（圖2-1）可歸納為下表 2-3 所示步驟。
表 2-3 OTA 的基本實現流程
| 步驟 | 內容 |
| 1. 升級包制作 | ECU 供應商或車企內部開發(fā)團隊完成軟件開發(fā)并編譯產生新版本的軟件， 通過約定的方式制作成升級包。 |
| 2.上傳軟件 | 供應商或 OEM 內部開發(fā)部門生產的軟件驗證合格后，經由產品生命周期管理系統(tǒng)(PLM)或類似的系統(tǒng)流轉到OTA云平臺，供更新使用。 |
| 3.OTA 任務發(fā) 布 | 發(fā)布過程是選定特定軟件，通知至指定目標車輛，通常由OTA 運營人員完成。發(fā)布之后的軟件通常經過一系列安全處理后傳至專門的文件服務端供車輛下載。 |
| 4.下載升級包 | OTA發(fā)布完成后，通常OTA云平臺需要通知車端OTA主控執(zhí)行軟件更新動作，OTA主控根據與云平臺命令交互獲取信息，從指定文件服務端地址下載所需要的升級包；不同的OTA系統(tǒng)可能由于升級對象升級包大小原因，OTA主控不會直接下載升級包而是通過相關命令控制目標ECU 完成其所需升級包的下載。 |
| 5.安裝 | 安裝過程是由 OTA 主控根據約定的協議，將目標升級軟件刷寫到對應 ECU 指定存儲介質。ECU 硬件不同、通信方式不同，通常安裝的過程會有所差異。 |
| 6.校驗 | 軟件安裝前后需要進行完整性校驗及真實性校驗。完整性校驗保證安裝過程傳輸的數據沒有被篡改，真實性校驗保證所安裝軟件沒有被仿冒偽造。 |
| 7.激活 | 根據ECU結構不同，安裝步驟可能還會包含激活操作，即雙備份分區(qū)ECU更新完成后進行分區(qū)切換。此外，OTA主控除了處理控制安裝過程外，還需要控制車輛的狀態(tài)，保證升級過程車輛的安全。 |
| 8.回滾 | 針對升級異常的情況，將軟件版本恢復到升級前版本的過程，主要目的在于保證升級失敗ECU功能仍可用。 |
| 9.狀態(tài)上報 | OTA主控需要將升級狀態(tài)同步到OTA云平臺，保證 OTA云平臺可以根據車輛最新狀態(tài)編排升級任務。同時，可根據業(yè)務實際情況，同步更新過程中各階段狀態(tài)至OTA云平臺，以便更精準地控制升級。 |
2.2 OTA 云平臺架構及關鍵技術
OTA 云平臺是支撐 OTA 業(yè)務正常運行的相關云端系統(tǒng)的集合，既包括實現 OTA 核心功能的 OTA 服務端，也包括了其他關聯系統(tǒng)如企業(yè) IT 管理系統(tǒng)、安全服務端、web 控制臺以及文件服務端。OTA 云平臺業(yè)務范圍涉及軟硬件生命周期管理、業(yè)務流程整合、軟件遠程分發(fā)等軟件更新所有相關業(yè)務，是一個軟件升級管理體系(SUMS)。
2.2.1 云平臺架構
基于 OTA 產品業(yè)務形態(tài)，結合系統(tǒng)組件之間松耦合高內聚的標準，行業(yè)內 普遍將云平臺設計為 4 層的分層架構型式，如圖 2-2 所示，包括前端展示層、路由網關層、業(yè)務服務層和數據存儲層。前端展示層是系統(tǒng)與用戶交互的 web 應用層，用戶訪問和操作云平臺系統(tǒng)的交互接口；網關路由層包括指令控制層和網關接入層，是云平臺與車端建立通信鏈接以及控制車端流程的通信中間件；業(yè)務服務層負責所有 OTA 相關業(yè)務邏輯的處理，包括車輛、軟件包管理、策略管理等諸多業(yè)務模塊，是 OTA 云平臺的核心；數據存儲層負責 OTA 所有業(yè)務相關數據存儲，包括基本的數據庫集群數據緩存和大文件存儲等。
圖 2-2 OTA 云服務框架圖
（1） 前端展示層
前端展示層的劃分，是基于前后端分離開發(fā)方式設計的架構分層模式，主要 負責 Web 端用戶交互頁面的功能。核心思想是前端頁面通過調用后端的接口并進行交互，前端專注于交互頁面的開發(fā)，業(yè)務邏輯由后端負責。對 OTA 云平臺而言，前端展示層可以理解為業(yè)務服務層的用戶交互接口，其展示功能與具體業(yè)務功能一一對應。
（2） 指令控制層
各業(yè)務平臺與網關接入層的連通介質，接收來自業(yè)務系統(tǒng)指令并將指令發(fā)送 至網關可訪問的緩存中，接收來自網關回寫的升級狀態(tài)至各業(yè)務系統(tǒng)可訪問的消息隊列中。
（3） 網關接入層
針對不同的數據格式及上層需求，接收封裝來自車載終端傳輸的數據，并流
向緩存、消息隊列等中間件。
（4）業(yè)務服務層
業(yè)務服務層是 OTA 服務所有業(yè)務及相關流程管理功能在云平臺端的實現， 除了車輛管理服務、軟件包服務、版本服務、策略管理和任務管理 5 個支撐 OTA 的核心功能外，還包括關聯系統(tǒng)審批、數據對接、信息安全服務、測試、統(tǒng)計分析、日志查詢等重要輔助功能。由于不同的企業(yè)內部管理存在差異，云平臺所支持的輔助業(yè)務可能存在較大差異，常見服務列舉見表 2-4。
表 2-4 常見服務舉例
| 常見服務 | 業(yè)務內容 |
| 車輛管理服務 | 維護所有可升級車輛的信息，包括品牌、車型、配置以及每個單車所包含的可升級設備信息等。 |
| 軟件包服務 | 用于控制器升級包的在線管理、差分包的制作及管理，相當于OTA 的倉庫管理，需要維護不同車型所有 ECU 不同版本的所有軟件實體，包含軟件包的簽名加密以及各版本與其關聯關系等。 |
| 版本服務 | 包括基線版本管理、軟硬件版本及版本號管理，每個軟硬件版本的依賴條件管理，并維護每一個軟件版本所適用的品牌、車型、配置等。 |
| 策略管理服務 | 需適配各種復雜軟件更新，提供靈活的設備群組管理、下發(fā)條件配置，支持升級任務策略配置，滿足各類升級需求。 |
| 任務管理服務 | 對升級推送任務的管理，每次選擇特定版本的軟件包向指定車輛推送即可視為一個任務。任務管理包含：1）任務條件設定，如任務所適用的車型、升級模式、升級策略、任務有效時間； 2）發(fā)布車輛選擇，指定將該任務適用于哪些車輛，可加入黑白名單，批量導入汽車唯一識別碼(VIN 碼)、標簽匹配等業(yè)務邏輯；3）任務的基本操作，如創(chuàng)建、暫停、取消等。 |
| 審批服務 | 功能在于把傳統(tǒng)的線下軟件發(fā)布的審批流程通過 OTA 平臺實現在線化，達到自動流傳，提高效率的作用。 |
| 數據對接服務 | 數據對接的系統(tǒng)包括 PLM、MES、EOL、DMS、ADS，數據對接涉及到軟件版本信息獲取、車輛信息初始化、用戶信息、售后信息同步等。 |
| 信息安全服務 | 用于保證OTA 的安全，主要通過與PKI 系統(tǒng)對接完成升級包的簽名加密，車端設備的身份認證，通信鏈路的認證和加密。 |
| 安全訪問控制 服務 | 通過云平臺端的安全訪問控制服務在線化管理會話控制的安全算法，防止未授權的系統(tǒng)或者設備對車輛 ECU 進行軟件更新，更利于對每個ECU 實現獨立的安全訪問方案。 |
| 測試服務 | 用于支持OTA 的測試，主要包括OTA 升級策略、升級配置信息和任務等，以保證升級效果符合期望目標。 |
| 統(tǒng)計分析服務 | 用于動態(tài)統(tǒng)計OTA 升級狀態(tài)，可以通過可視化展示升級狀態(tài)，快速了解升級任務進度。同時，可以根據統(tǒng)計分析結果動態(tài)調整 OTA 任務推送的車輛數，保證系統(tǒng)資源和售后資源得到最有利的分配。 |
| 日志查詢服務 | 包含云端日志、車云交互日志以及車端遠程日志等查詢功能。 |
| 基礎信息服務 | 主要針對OTA 云平臺本身的信息管理，如賬號權限管理等。 |
（5） PKI 系統(tǒng)
公鑰基礎設施（Public Key Infrastructure，PKI）：基于公鑰密碼體制實現數字證書的發(fā)布、撤銷和管理等功能，并為數字證書用戶提供相應服務的系統(tǒng)。其目的在于創(chuàng)造、管理、分配、使用、存儲以及撤銷數字證書，可以用來保證通信對象的身份真實性、軟件程序的來源真實性和完整性、通信行為的不可否認性等。
PKI 在 OTA 系統(tǒng)中的作用主要在于為相關實體發(fā)放數字證書，通過密碼技術保證升級包和升級過程的安全。主要包括車輛證書、設備證書、供應商證書等 的申請和校驗；云端對車端身份認證，車端對云端身份認證；升級包的安全認證等。
（6）外部數據系統(tǒng)
外部數據對接的系統(tǒng)可能包括整車生命周期配置系統(tǒng)（VLCS）、遠程診斷系 統(tǒng)、軟件可售系統(tǒng)及一些其他支撐系統(tǒng)組成。主機廠研發(fā)部門需要根據車型的功能規(guī)劃確定該車型所對應的軟硬件相關配置。需要進行軟件更新時， 從 VLCS 系統(tǒng)中確定所涉及的車型和影響的功能范圍，并依據確定好的范圍， 從物料信息管理系統(tǒng)(BOM)中申請軟件物料號作為版本控制依據， 供應商軟件釋放后經由產品生命周期管理系統(tǒng)（PLM）系統(tǒng)通過驗證審批后流轉到 OTA 服務端供升級使用使用。OTA 服務端管理設備中初始的車輛信息，可通過對接 MES 在車輛下線檢驗合格后將新生產車輛自動注冊到 OTA 云平臺，所有升級目標車輛應保證是已 注冊車輛。除此之外，根據實際需要還可能會從汽車經銷商管理系統(tǒng)（DMS）系 統(tǒng)獲取經銷商及售后服務站點信息，售后系統(tǒng)通常也需要與 OTA 系統(tǒng)關聯以同步最新版本信息以及線下配置更改信息等。
另外， OTA 系統(tǒng)在升級前可通過遠程診斷系統(tǒng)獲得最新的 ECU 配置信息及 狀態(tài)信息，并且當遠程診斷系統(tǒng)發(fā)現問題后，可以通過 OTA 系統(tǒng)下發(fā)經過測試驗證的補丁包來修復。對于一些有運營需求的主機廠來說，通過 OTA 系統(tǒng)配合軟件可售系統(tǒng)，可以實現軟件付費升級、功能付費使用等后向運營，真正實現“千車千面”、“用戶定義汽車”。
（7）數據存儲層
數據存儲層包括數據庫集群、緩存和存儲節(jié)點，分別用于存儲 OTA 云平臺 不同類型的數據。其中，數據庫集群，主要用于存儲車輛信息版本信息等關系型數據；緩存，為了解決數據庫性能瓶頸問題，可以通過多架設一層緩存層來減少對數據庫的直接訪問；存儲節(jié)點，針對較大的升級包、配置文件等需要提供車端下載的文件，通常可以存儲在分布式存儲節(jié)點上。
2.2.2 關鍵技術
（1）安全技術
OTA 服務端以及企業(yè) IT 管理系統(tǒng)、安全服務端、web 控制臺、文件服務端 等關聯系統(tǒng)，會面臨傳統(tǒng)云平臺的所有安全威脅。為保證 OTA 升級的安全性，常用安全技術如表 2-5 所示。
表 2-5 OTA 云平臺常用安全技術
| 名稱 | 技術要點 |
| PKI 簽名驗簽技術 | 在升級過程中，OTA 系統(tǒng)采用數字證書簽名方案，終端從 OTA 云平臺下載的升級包、升級腳本均經過簽名處理，升級前需驗簽正確后才進行升級。 |
| 安全訪問控制 | 通過云平臺端的安全訪問控制服務，OTA 車載系統(tǒng)采用網關內置或終端內置的安全訪問函數方式實現校驗方案，只有全訪問驗證通過，ECU 才會執(zhí)行后續(xù)對應安全訪問等級要求的請求。 |
| 數字證書身份認證及信息安全 | PKI 數字證書用于實現車輛身份管理，車、云身份認證；用于 OTA 云平臺與車端上下行消息的加解密、簽名、驗簽。 |
| 數據安全 | 通過在組織中建立數據安全管理體系、建設云平臺數據全生命周期的主動安全防護和數據安全運營能力，保護數據安全。 |
（2） OTA 技術
OTA 系統(tǒng)常用升級技術如表 2-6 所示。
表 2-6 OTA 云平臺常用升級技術
| OTA技術 | 技術要點 |
| 升級包管理 | 用于控制器升級包的在線管理、差分包的制作及管理。 |
| 腳本管理 | 用于控制器升級執(zhí)行腳本文件的在線管理。 |
| 升級策略管理 | 用于升級任務執(zhí)行條件（目標版本對目標車輛、整車狀態(tài)、控制器狀態(tài)、時間、信號等影響因素的依賴關系）的在線管理。 |
| 升級效率管理 | 制定相關策略提升升級效率，降低升級失敗次數。并通過日志分析其原因， 進行技術迭代開發(fā)。 |
2.3 OTA 車載端架構及關鍵技術
2.3.1 車載端架構
OTA 車載端功能模塊主要包括 2 大部分，即 OTA 主控和 OTA 對象，如圖 2-3 所示。OTA 主控是車端 OTA 系統(tǒng)的核心，車端所有 OTA 業(yè)務邏輯均由主控實現，包括上報車輛信息、下載更新文件、升級包安裝、車輛狀態(tài)管理、人機交互等。
圖 2-3 車載端功能模塊(參考 AutoSAR UCM)
（1） OTA 主控功能模塊
按照車載端的工作流程，車載端的功能模塊包括：OTA 客戶端負責與云端進 行數據交互；下載模塊負責升級包下載及分發(fā)；升級管理模塊負責升級過程的控制；升級代理負責執(zhí)行軟件刷寫或者軟件安裝；人機交互模塊負責升級信息提示、用戶輸入、升級過程的展示等，如表 2-7 所示。
表 2-7 OTA 主控功能模塊
| 功能模塊 | 功能描述 |
| 升級管理（OTA Manager） | 作為 OTA 的核心，管理車輛所有 ECU 的更新過程，控制著將固件更新分發(fā)到 ECU，并告知 ECU 何時執(zhí)行更新，這在多個 ECUs 需要同時更新的情況下尤為重要。 OTA 任務下發(fā)到車輛后，OTA Manager 需要判斷車輛條件，對于不符合條件的車輛，需要中止升級任務并上報給云平臺，安全完成軟件升級后， 也要上報云端。若想實現單車定制化功能，OTA Manager 還需能夠靈活定義升級的具體范圍，升級時機，升級內容，提示事項，失敗后給用戶的失敗處理提示等。 |
| OTA 客戶端 | 負責 OTA 主控與 OTA 云平臺交互，包括下發(fā) OTA 云平臺的 OTA 控制命令，反饋控制命令的執(zhí)行結果，發(fā)起更新檢查請求，同步升級過程狀態(tài)等。 |
| 下載管理模塊 | 負責從文件服務端下載升級所需升級包和文件，支持斷點續(xù)傳，保證升級包可以分多次下載，同時也避免部分重復下載造成流量浪費。 |
| 安裝模塊 | 負責將升級包安裝到對應的 ECU。不同的 ECU 類型會需要不同的安裝模塊，比如 FBL 安裝模塊用于僅支持 Bootloader 升級 ECU，AB 安裝模塊用于支持 AB swap 雙備份分區(qū)升級方式的 ECU, 其他安裝模塊主要是指一些采用私有協議進行升級的智能 ECU |
| 車輛狀態(tài)管理 | 負責確保車輛在安全狀態(tài)下進行升級，其功能主要包括兩個: ① 車輛狀態(tài)判斷，通過預設條件判斷判斷車輛狀態(tài)是否滿足 OTA 的要求，比如判斷車輛的電池電量是否足以支持完成升級、車輛是否處于非行駛狀態(tài)等，這些條件通常是通過監(jiān)控車輛相關的信號實現； ② 車輛狀態(tài)控制, 通過特定的控制命令或者信號值，限制車輛非升級必須的功能，保證升級過程車輛狀態(tài)不可被改變，從而維持在安全狀態(tài)。 |
| 人機交互接口 | 人機交互接口是 OTA 主控通過相關顯示設備與用戶進行交互的操作接口，控制 OTA 相關信息在車內的娛樂主機顯示屏或者手機 APP 等設備上的顯示。 |
上一篇：為什么電動汽車制造商要轉向800伏電壓
下一篇：汽車產業(yè)10大關鍵材料盤點
推薦閱讀最新更新時間：2025-04-23 11:14
智能網聯汽車產業(yè)鏈全景圖（可做求職參考）
OTA 升級
操作系統(tǒng)真相還原- 何為接近開關？如何調試接近開關一、什么是接近開關接近開關是一種無需與運動部件進行機械直接接觸而可以操作的位置開關，當物體接近開關的感應面到動作距離時，不需要機械 ...
- 影響接近開關工作距離的因素有哪些？使用接近開關有哪些注意事項一、影響接近開關工作距離的因素1、開關類型不同類型的接近開關具有不同的工作距離。例如，電感式接近開關的工作距離通常較短，而電容式或 ...
- 如何安裝接近開關？接近開關如何正確接線？一、接近開關的安裝方法1 選擇合適的接近開關在安裝接近開關之前，首先需要根據應用場景選擇合適的型號。接近開關的類型包括電感式、電容 ...
- 高速數據傳輸：構建嵌入式視覺的未來市場對高速數據傳輸的需求正迅速增長。隨著智能設備、數據中心系統(tǒng)和軟件的發(fā)展，企業(yè)需要數據在其技術基礎設施中快速傳輸的同時保持適應性 ...
- 接近開關有哪些功能？如何判斷接近開關是否已經損壞一、接近開關有哪些主要功能1 檢驗距離檢測電梯、升降設備的停止、起動、通過位置；檢測車輛的位置，防止兩物體相撞檢測；檢測工作機械的設 ...
- 接近開關有哪些分類？接近開關損壞的原因有哪些
- 接近開關的常開與常閉是怎么回事？和光電開關有什么區(qū)別？
- 實現工業(yè)設備輔助電源應用要求的高耐壓與低損耗
- 接近開關有哪些優(yōu)缺點？接近開關使用經驗分享
- LTC2440、24 位高速差分 Delta Sigma ADC 的典型應用
- AD8604DRZ-REEL 高端運算放大器電流監(jiān)視器的典型應用
- 基于HM301D的STEVAL-IME002V1，用于生物電傳感器和生物阻抗測量
- 基于STPM34的帶有2個電流互感器的雙相電能計量評估板
- 電源220V轉12V-5V
- LTC6262HMS 橋接式差分輸出運算放大器的典型應用
- 使用具有 B 類 EMI 濾波（雙輸出）的 RP10-4824SA DC/DC 轉換器的典型應用
- 具有軟啟動功能的 LT3971、5V、2MHz 降壓轉換器的典型應用電路
- AM1G-1205SH30Z 5V 1W DC-DC 轉換器的典型應用
- CY8C4127LQI-BL493 4100_BLE PSoC 可編程片上系統(tǒng)的典型應用
- 強強聯合再進階！理想AD Pro輔助駕駛正式升級搭載地平線征程6M
- 英特爾與黑芝麻智能簽署合作備忘錄，聯合發(fā)布艙駕融合平臺
- 英特爾與面壁智能宣布建立戰(zhàn)略合作伙伴關系，共同研發(fā)端側原生智能座艙
- 芯馳科技發(fā)布X10，打造全民AI時代座艙處理器新標桿
- 精準適配，輕裝全能！芯馳發(fā)布E3系列高端智控MCU三大應用場景
- 場景定義、精準創(chuàng)「芯」，芯馳全新發(fā)布AI座艙處理器和高端智控系列
- Arm 技術加持，地平線以 HSD 及征程 6P 推動汽車智能化變革
- 華為自動駕駛技術解讀
- 加速電動化轉型，邦迪汽車系統(tǒng)攜多款創(chuàng)新產品首秀2025上海車展
- 數據中心面臨電力約束挑戰(zhàn)，推動GenAI終端發(fā)展
- 試用Vishay新型“IHLP磁芯損耗計算器”，搶樓贏好禮
- LPC4370重磅來襲 有獎問答贏好禮！
- 電子工程師，如何更好地擁抱GaN？參與問卷有好禮！
- 報名贏京東卡 | 國產FPGA安路科技2024線上新品發(fā)布會
- 兆易GD32450I-EVAL免費測評試用
- 追更有驚喜：解救被FSM折磨過的你，justd0解析LSM6DSOX有限狀態(tài)機官方例程
- 電路圖站2.0版上線，公開征集網友建議，填寫調查問卷贏積分！
- 全球首款Cortex-M23內核物聯網芯片SAML10和SAM L11系列 闖關獲取SAML10/SAML11法寶，拆除電子界安全危機，贏好禮！
- 邀請好友體驗WEBENCH，禮品豐厚你有他也有！
京公網安備 11010802033920號