由于智能汽車集中化趨勢，導致在網絡連接上已經由傳統的低帶寬Can網絡升級轉換到高帶寬以太網網絡為主的升級過程。為了提升車輛升級能力，基于為車主提供持續且優質的體驗和服務，需要在現有系統基礎（由原始只對車機上傳統的 ECU 進行升級，轉換到實現以太網增量升級的過程）之上開發一套可兼容現有 OTA 系統的全新 OTA 服務系統，實現對整車軟件、固件、服務的 OTA 升級能力，從而最終提升用戶的使用體驗和服務體驗。

軟件升級觸及的兩大領域-FOTA/SOTA

整車軟件升級是通過OTA技術，是對車載娛樂、導航、人機互動等應用軟件及轉向、制動、車身控制等固件進行升級。整車OTA升級包是由升級對象中可升級ECU的升級包組合而成。對于整車OTA類型，主要分為兩類，FOTA（Firmware-over-the-air）和SOTA（Software-over-the-air），兩者均為主機廠重點關注及逐步落地的領域，可適應不同場景的OTA需求。

FOTA（又稱為移動終端空中下載軟件升級技術），通過給車輛控制器下載安裝完整的固件鏡像，來實現系統功能完整的升級更新。FOTA涉及控制器相關策略核心功能的一個完整的系統性更新，對整車性能影響較大，升級過程對時序、穩定性、安全性要求極高，同時升級前置條件包括擋位、電量、車速等要求，升級過程一般不支持點火用車。

FOTA通過給車輛控制器下載安裝完整的固件鏡像，來實現系統功能完整的升級更新。例如升級車輛的智駕系統，讓駕駛員享受越來越多的輔助駕駛功能；升級車輛的座艙系統，提高駕駛員疲勞檢測的準確率；升級車輛的制動系統，提升車輛的制動性能。

SOTA實際可看成一種軟件可售策略的核心需求，他是通過給車輛控制器安裝“增量包”，來實現控制器功能的一個“增量”更新，一般應用于娛樂系統和智駕系統。例如更換多媒體系統操作界面，優化儀表盤顯示風格，更新娛樂主機里的地圖程序時，用到的都是SOTA升級方式。SOTA涉及控制器應用層一個小范圍的功能局部更新，對整車性能影響較小，升級前置條件要求較低。SOTA的增量更新策略，可以大幅減小升級包文件大小、從而節約網絡流量和存儲空間。

這里我們舉例說明FOTA和SOTA分別如何在智能駕駛升級中進行有效定義。

例如升級智能駕駛汽車系統，為了讓駕駛員享受越來越多的輔助駕駛功能；通常根據功能開發難度、時間長度來確定對階段性功能的不斷更新迭代（包含從低級別功能向高級別功能進階的軟件更迭）。同時，過程中需要升級車輛的座艙系統，提高駕駛員疲勞檢測的準確率；升級智能駕駛車輛的關聯子系統（如制動、轉向系統等模塊），提升車輛的制動性能。

智駕系統中的軟件升級架構

對于整個OTA升級而言，從下至上主要包括如下三方面：升級對象、OTA管理器、OTA云服務平臺。自動駕駛域控制器與座艙域控制器通過以太網連接，升級協議一般為常用的DoIP，除開域控本身外，升級過程還包括高精定位模塊升級，傳感器升級。對于由以太網連接的攝像頭而言，其升級過程主要是通過主域控端所搭載的整個集成程序進行升級。也就是說對于純攝像頭傳感器而言，沒有單獨的程序升級過程。對于由CANFD搭載的毫米波/超聲波雷達而言，由于是自帶控制器的，其升級過程主要是通過CANFD連接控制器，域控通過CANFD接入公CAN，由座艙域負責刷寫CANFD域控制器轉發報文到各雷達控制器上。

如上圖所示，OTA云服務平臺主要對OTA升級包進行管理與下發，并完成升級任務的配置、調度及跟蹤。OTA管理器主要完成升級包的下載、解密、驗簽、差分包重構等功能，最終將升級包發送至對應的升級對象。升級對象是由一個或多個ECU構成，升級對象接收到升級包后，將對應的ECU升級包發送至對應的ECU，ECU完成升級包的刷寫。

智駕系統中的升級過程原理

目前的升級方式主要是靜默升級。即包含常態化模式下的有感升級和非常態模式下的無感升級。常態模式實際就是在工廠模式下，多媒體接收升級命令后，在滿足升級條件的情況下下載升級包，進行車輛的自動化升級。升級過程中，如收到解閉鎖/開車門/按下啟動按鈕/云服務解鎖信號后，車輛顯示屏不顯示 OTA 升級，常規升級過程中車輛處于靜默狀態。

非工廠模式下做無感升級，在用戶不感知的情況下進行升級作為一保留方案。由于受國家相關法律的限制，這種方案的實現需要智能駕駛所有模塊滿足兩面分區升級策略。這里的兩面區分指的是A/B雙面升級過程。即針對域控中的SOC開辟A/B兩個存儲空間，每個存儲空間上均安裝有一個系統，其中一個系統處于激活使用狀態時，另一個系統就會處于待命備用狀態。在進行系統升級時，可在激活的系統中對備用系統進行升級，升級完成后重啟切換成新升級的系統。由此，在智駕域控的SOC中的升級過程可描述為當運行區為 A 區，則升級 B 區，升級完成后，從 B 區重啟，啟動后，擇時將 B 區同步到 A 區。且當 SOC 升級失敗的時候，不允許使用使能駕駛。

此外，對于域控中的MCU刷寫而言，最好采用雙APP機制。即MCU采用bootloader單區+app雙區部署方式，bootloader一般沒有升級需求。因此，對MCU的升級過程只需要對雙區部署的APP進行即可。

整個升級過程中，需要完成如下升級過程中的任務：

1）升級前置條件判斷：

通過以太網、CAN 等車內網絡獲取車輛當前狀態檢查，根據項目實際需求定制包含但不限于蓄電池電量、發動機轉速、車輛速度、車輛檔位、手剎狀態、座椅傳感器狀態、門狀態、鎖狀態等。座艙域控制器在升級開始前，需要針對升級車輛進行狀態檢查后繼續后續動作。其當前狀態的檢查項目包括：模塊剩余內部存儲空間、模塊硬件版本、模塊固件版本、模塊軟件版本。通常情況下，升級過程中需要判斷是否滿足車輛是否靜止，檔位是否為P檔，域控制器的SOC電量是否大于一定閾值條件。在適當的情況下，由中控界面/電檢電腦顯示屏上彈出預約升級或立即升級指示。有兩種情況會觸發升級：上下電自檢與用戶主動觸發。升級條件觸發，觸發成功進入下一步，否則退出本次升級流程。

2）下載升級包：

在云端升級策略和升級包下發過程中，云端需要檢測版本號是否更新，OTA升級服務器下發升級策略包到座艙域控制器，此過程中用戶不會感知。座艙域控制器支持常規的刷寫升級方式，DoIP 和 CAN燒寫。

基于CAN協議的軟件刷寫

CAN 燒寫過程實際是一種根據規范（規范主要是根據 ISO 14229 ）進行編程的過程。編程過程中需要指定參照如下幾種類型的不同步驟進行有效的尋址及服務訪問：

標準步驟作為一種強制性的步驟，要求無論任何情況下客戶端和服務器都應按照規定行事。推薦步驟是可選的，他需要使用特定的診斷服務標識符，并包含有關如何執行操作的建議。這種可選的方案僅要求在使用指定的功能的情況下，客戶端和服務器應按照規定行事。OEM實施步驟：其使用和內容（例如，使用的診斷服務標識符）由車輛制造商自行決定，當然也可作為另一種可選的步驟。

CAN軟件刷寫主要分三個階段：預編程階段，編程階段，結束階段。相應的各階段需要進行的業務流程如下圖所示：

基于DoIP協議的軟件刷寫詳解

DoIP（Diagnostic communication over Internet Protocol）作為基于車載以太網的診斷，主要存在于OSI 七層模型中的傳輸層，DoIP是在以太網網絡上傳輸UDS診斷數據的傳輸協議。DoIP具有高帶寬，適合傳輸大量數據的場景，這就非常適合作為車上更新的OTA軟件升級。相較于CAN，DoIP主要是在物理層和傳輸層對數據的傳輸進行了優化并提升了速度。在應用層和診斷服務環節，CAN與DoIP的實現均基于14229協議。ODX數據庫部分，除需增加DoIP協議通訊參數和相關控制器外，一般情況下，不需要進行額外調整，這大大節省了診斷數據開發時間與成本。

對于DoIP的文件刷寫主要包括無文件系統控制器的DoIP刷寫和有文件系統控制器的DoIP刷寫。針對無文件系統控制器的刷寫，其總方案類似于 CAN 節點刷寫方案。多媒體主機按地址傳輸，控制器按地址寫入方式。對于有文件系統的控制器，多媒體主機只需要將升級包傳到控制器（當然過程中需要能支持斷點續傳），并沒有其他的要求。

目前常用的DoIP診斷連接方式分為兩種：其一，是以太網線纜直連形式：在整車情況下，制作OBD-Ethernet線纜直連；其二，是兼容CAN/CAN FD通訊，并滿足生產和售后需求，通過使用診斷VCI集成以太網激活功能，實現DoIP通訊。數據庫創建完成后，使用相關診斷工具，即可實現車輛刷寫過程。

座艙域控收到服務器下發的整車工廠模式自動化升級指令后，在滿足升級條件的情況下請求服務器自動下載升級包，并對車輛進行自動化升級，支持斷點續傳，完整性校驗，存儲空間管理等功能。

3）智駕域控制器升級狀態反饋：

智駕域控制器上報域控制器信息到座艙域控制器完成升級前置條件判斷，條件滿足時方可進入 OTA 升級，升級這類信息需要上傳到OTA服務器。這類信息包括域控制器各個模塊的軟/硬件版本號、序列號(SN) 、定位信息(GPS)等。

4）執行升級任務：

座艙域控制器將根據服務器下發的升級包，升級策略等信息，進行 OTA 升級。如果同時需要進行多 ECU 聯合升級刷寫時，需要根據下發的升級任務序列，按照升級順序與對應控制器發送點對點升級交互信息，即可完成對應的升級任務。

5）斷點接續升級：

斷點接續升級是指基于狀態機的管理，在升級過程中，對當前升級的文件或塊設備進行備份存儲。如果在升級過程中出現中斷，斷電，或其它干擾，導致正在升級的文件被破壞，那么，控制器會記錄當前升級狀態，后續在下次重啟程序時，控制器會執行一定的校驗算法（如hash 校驗）評估該文件是否已經遭到破壞，如果程序完好，則會直接按照未被標記升級過的程序進行順序升級。如果文件已損壞，則會用備份的存儲來恢復升級。

對于整個升級過程一般要求刷寫失敗后有數次重試機會。且有關聯模塊依賴時，對于已升級的關聯模塊需要全部回滾。

6）聯動升級管理：

針對功能相關聯的 ECU（比如前毫米波雷達升級可看成同性質下的聯動升級），后臺可以設定聯動升級，也可以針對關聯 ECU 設置升級順序。升級過程為當座艙域控制器自后臺取得升級任務后，會檢測升級指令中是否有聯動升級要求，如果有便會依照順序進行逐一升級并關聯 ECU。

座艙域控制器在整個升級過程中會管理并不間斷派發升級包，監控整個升級過程直到所有 ECU完成升級，再統一上報后臺升級結果。當檢測到有任一ECU升級失敗需要進行回滾時，控制器會聯動所有關聯 ECU 同步進行版本回滾。同時，座艙域控制器會有效上報因為哪一個 ECU 升級失敗導致回滾。

相應的軟件升級時序圖如下：

基于如上說明，整車各模塊升級可概括為：由 OTA 服務器下發升級策略文件決定升級順序，在服務器上配置升級時生成策略文件，座艙域控根據策略文件制定各 ECU 升級方案和順序。智能駕駛相關模塊的升級順序則按照如下優先級順序進行先后升級控制：CAN 模塊—>DoIP 無文件系統模塊—>DoIP 有文件系統。

相較于CAN，DoIP主要是在物理層和傳輸層對數據的傳輸進行了優化并提升了速度。在應用層和診斷服務環節，CAN與DoIP的實現均基于14229協議。

對于智能駕駛系統而言，軟件升級已作為不可或缺的一部分。在為客戶提供實時在線升級功能的同時，域控制器需要滿足云端安全通信，包括協議通信鏈接管理，升級指令接收和升級狀態發送，升級包下載、升級包解密、差分包重構、對升級包進行合法性驗證,還包括密鑰證書管理服務，數據加密服務，數字簽名服務等功能。可以說，智駕級別的軟件升級是引領起其不斷發展的源源動力。