由于智能汽車集中化趨勢，導致在網絡連接已經由傳統的低帶寬Can網絡升級轉換到高帶寬以太網網絡為主的升級過程。為了提升車輛升級能力，基于為車主提供持續(xù)且優(yōu)質的體驗和服務，需要在現有系統基礎（由原始只對車機上傳統的 ECU 進行升級，轉換到實現以太網增量升級的過程）之上開發(fā)一套可兼容現有 OTA 系統的全新 OTA 服務系統，實現對整車軟件、固件、服務的 OTA 升級能力，從而最終提升用戶的使用體驗和服務體驗。
2.智駕系統中的軟件升級架構 對于整個OTA升級而言，從下至上主要包括如下三方面：升級對象、OTA管理器、OTA云服務平臺。自動駕駛域控制器與座艙域控制器通過以太網連接，升級協議一般為常用的DoIP，除開域控本身外，升級過程還包括高精定位模塊升級，傳感器升級。對于由以太網連接的攝像頭而言，其升級過程主要是通過主域控端所搭載的整個集成程序進行升級。也就是說對于純攝像頭傳感器而言，沒有單獨的程序升級過程。對于由CANFD搭載的毫米波/超聲波雷達而言，由于是自帶控制器的，其升級過程主要是通過CANFD連接控制器，域控通過CANFD接入公CAN，由座艙域負責刷寫CANFD域控制器轉發(fā)報文到各雷達控制器上。 如上圖所示，OTA云服務平臺主要對OTA升級包進行管理與下發(fā)，并完成升級任務的配置、調度及跟蹤。OTA管理器主要完成升級包的下載、解密、驗簽、差分包重構等功能，最終將升級包發(fā)送至對應的升級對象。升級對象是由一個或多個ECU構成，升級對象接收到升級包后，將對應的ECU升級包發(fā)送至對應的ECU，ECU完成升級包的刷寫。 3.智駕系統中的升級過程原理 目前的升級方式主要是靜默升級。即包含常態(tài)化模式下的有感升級和非常態(tài)模式下的無感升級。常態(tài)模式實際就是在工廠模式下，多媒體接收升級命令后，在滿足升級條件的情況下下載升級包，進行車輛的自動化升級。升級過程中，如收到解閉鎖/開車門/按下啟動按鈕/云服務解鎖信號后，車輛顯示屏不顯示 OTA 升級，常規(guī)升級過程中車輛處于靜默狀態(tài)。 非工廠模式下做無感升級，在用戶不感知的情況下進行升級作為一保留方案。由于受國家相關法律的限制，這種方案的實現需要智能駕駛所有模塊滿足兩面分區(qū)升級策略。這里的兩面區(qū)分指的是A/B雙面升級過程。即針對域控中的SOC開辟A/B兩個存儲空間，每個存儲空間上均安裝有一個系統，其中一個系統處于激活使用狀態(tài)時，另一個系統就會處于待命備用狀態(tài)。在進行系統升級時，可在激活的系統中對備用系統進行升級，升級完成后重啟切換成新升級的系統。由此，在智駕域控的SOC中的升級過程可描述為當運行區(qū)為 A 區(qū)，則升級 B 區(qū)，升級完成后，從 B 區(qū)重啟，啟動后，擇時將 B 區(qū)同步到 A 區(qū)。且當 SOC 升級失敗的時候，不允許使用使能駕駛。 此外，對于域控中的MCU刷寫而言，最好采用雙APP機制。即MCU采用bootloader單區(qū)+app雙區(qū)部署方式，bootloader一般沒有升級需求。因此，對MCU的升級過程只需要對雙區(qū)部署的APP進行即可。 整個升級過程中，需要完成如下升級過程中的任務： 1）升級前置條件判斷： 通過以太網、CAN 等車內網絡獲取車輛當前狀態(tài)檢查，根據項目實際需求定制包含但不限于蓄電池電量、發(fā)動機轉速、車輛速度、車輛檔位、手剎狀態(tài)、座椅傳感器狀態(tài)、門狀態(tài)、鎖狀態(tài)等。座艙域控制器在升級開始前，需要針對升級車輛進行狀態(tài)檢查后繼續(xù)后續(xù)動作。其當前狀態(tài)的檢查項目包括：模塊剩余內部存儲空間、模塊硬件版本、模塊固件版本、模塊軟件版本。通常情況下，升級過程中需要判斷是否滿足車輛是否靜止，檔位是否為P檔，域控制器的SOC電量是否大于一定閾值條件。在適當的情況下，由中控界面/電檢電腦顯示屏上彈出預約升級或立即升級指示。有兩種情況會觸發(fā)升級：上下電自檢與用戶主動觸發(fā)。升級條件觸發(fā)，觸發(fā)成功進入下一步，否則退出本次升級流程。 2）下載升級包： 在云端升級策略和升級包下發(fā)過程中，云端需要檢測版本號是否更新，OTA升級服務器下發(fā)升級策略包到座艙域控制器，此過程中用戶不會感知。座艙域控制器支持常規(guī)的刷寫升級方式，DoIP 和 CAN燒寫。 基于CAN協議的軟件刷寫 CAN 燒寫過程實際是一種根據規(guī)范（規(guī)范主要是根據 ISO 14229 ）進行編程的過程。編程過程中需要指定參照如下幾種類型的不同步驟進行有效的尋址及服務訪問： 標準步驟作為一種強制性的步驟，要求無論任何情況下客戶端和服務器都應按照規(guī)定行事。推薦步驟是可選的，他需要使用特定的診斷服務標識符，并包含有關如何執(zhí)行操作的建議。這種可選的方案僅要求在使用指定的功能的情況下，客戶端和服務器應按照規(guī)定行事。OEM實施步驟：其使用和內容（例如，使用的診斷服務標識符）由車輛制造商自行決定，當然也可作為另一種可選的步驟。 CAN軟件刷寫主要分三個階段：預編程階段，編程階段，結束階段。相應的各階段需要進行的業(yè)務流程如下圖所示：
基于DoIP協議的軟件刷寫詳解 DoIP（Diagnostic communication over Internet Protocol）作為基于車載以太網的診斷，主要存在于OSI 七層模型中的傳輸層，DoIP是在以太網網絡上傳輸UDS診斷數據的傳輸協議。DoIP具有高帶寬，適合傳輸大量數據的場景，這就非常適合作為車上更新的OTA軟件升級。相較于CAN，DoIP主要是在物理層和傳輸層對數據的傳輸進行了優(yōu)化并提升了速度。在應用層和診斷服務環(huán)節(jié)，CAN與DoIP的實現均基于14229協議。ODX數據庫部分，除需增加DoIP協議通訊參數和相關控制器外，一般情況下，不需要進行額外調整，這大大節(jié)省了診斷數據開發(fā)時間與成本。 對于DoIP的文件刷寫主要包括無文件系統控制器的DoIP刷寫和有文件系統控制器的DoIP刷寫。針對無文件系統控制器的刷寫，其總方案類似于 CAN 節(jié)點刷寫方案。多媒體主機按地址傳輸，控制器按地址寫入方式。對于有文件系統的控制器，多媒體主機只需要將升級包傳到控制器（當然過程中需要能支持斷點續(xù)傳），并沒有其他的要求。 目前常用的DoIP診斷連接方式分為兩種：其一，是以太網線纜直連形式：在整車情況下，制作OBD-Ethernet線纜直連；其二，是兼容CAN/CAN FD通訊，并滿足生產和售后需求，通過使用診斷VCI集成以太網激活功能，實現DoIP通訊。數據庫創(chuàng)建完成后，使用相關診斷工具，即可實現車輛刷寫過程。 座艙域控收到服務器下發(fā)的整車工廠模式自動化升級指令后，在滿足升級條件的情況下請求服務器自動下載升級包，并對車輛進行自動化升級，支持斷點續(xù)傳，完整性校驗，存儲空間管理等功能。 3）智駕域控制器升級狀態(tài)反饋： 智駕域控制器上報域控制器信息到座艙域控制器完成升級前置條件判斷，條件滿足時方可進入 OTA 升級，升級這類信息需要上傳到OTA服務器。這類信息包括域控制器各個模塊的軟/硬件版本號、序列號(SN) 、定位信息(GPS)等。 4）執(zhí)行升級任務： 座艙域控制器將根據服務器下發(fā)的升級包，升級策略等信息，進行 OTA 升級。如果同時需要進行多 ECU 聯合升級刷寫時，需要根據下發(fā)的升級任務序列，按照升級順序與對應控制器發(fā)送點對點升級交互信息，即可完成對應的升級任務。 5）斷點接續(xù)升級： 斷點接續(xù)升級是指基于狀態(tài)機的管理，在升級過程中，對當前升級的文件或塊設備進行備份存儲。如果在升級過程中出現中斷，斷電，或其它干擾，導致正在升級的文件被破壞，那么，控制器會記錄當前升級狀態(tài)，后續(xù)在下次重啟程序時，控制器會執(zhí)行一定的校驗算法（如hash 校驗）評估該文件是否已經遭到破壞，如果程序完好，則會直接按照未被標記升級過的程序進行順序升級。如果文件已損壞，則會用備份的存儲來恢復升級。 對于整個升級過程一般要求刷寫失敗后有數次重試機會。且有關聯模塊依賴時，對于已升級的關聯模塊需要全部回滾。 6）聯動升級管理： 針對功能相關聯的 ECU（比如前毫米波雷達升級可看成同性質下的聯動升級），后臺可以設定聯動升級，也可以針對關聯 ECU 設置升級順序。升級過程為當座艙域控制器自后臺取得升級任務后，會檢測升級指令中是否有聯動升級要求，如果有便會依照順序進行逐一升級并關聯 ECU。 座艙域控制器在整個升級過程中會管理并不間斷派發(fā)升級包，監(jiān)控整個升級過程直到所有 ECU完成升級，再統一上報后臺升級結果。當檢測到有任一ECU升級失敗需要進行回滾時，控制器會聯動所有關聯 ECU 同步進行版本回滾。同時，座艙域控制器會有效上報因為哪一個 ECU 升級失敗導致回滾。 相應的軟件升級時序圖如下： 基于如上說明，整車各模塊升級可概括為：由 OTA 服務器下發(fā)升級策略文件決定升級順序，在服務器上配置升級時生成策略文件，座艙域控根據策略文件制定各 ECU 升級方案和順序。智能駕駛相關模塊的升級順序則按照如下優(yōu)先級順序進行先后升級控制：CAN 模塊—>DoIP 無文件系統模塊—>DoIP 有文件系統。 相較于CAN，DoIP主要是在物理層和傳輸層對數據的傳輸進行了優(yōu)化并提升了速度。在應用層和診斷服務環(huán)節(jié)，CAN與DoIP的實現均基于14229協議。
