一文聊聊智慧駕駛系統與軟體升級的關聯設計方案

由於智慧汽車集中化趨勢，導致在網路連線上已經由傳統的低頻寬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協定。

對於智慧駕駛系統而言，軟體升級已作為不可或缺的一部分。在為客戶提供即時線上升級功能的同時，網域控制器需要滿足雲端安全通信，包括協議通信連結管理，升級指令接收和升級狀態發送，升級包下載、升級包解密、差分包重構、對升級包進行合法性驗證,還包括金鑰憑證管理服務，資料加密服務，數位簽章服務等功能。可以說，智駕等級的軟體升級是引領起其不斷發展的源源動力。

以上是一文聊聊智慧駕駛系統與軟體升級的關聯設計方案的詳細內容。更多資訊請關注PHP中文網其他相關文章！