01 摘要

(Over-the-Air)是一種無線升級技術，為軟件提供了持續迭代更新的能力，已逐漸成為智能網聯汽車的標配。整車OTA受限于電子電氣架構、升級時間長、控制器多難以控制等限制導致發展進度緩慢，為提高整車OTA的穩定性并縮短升級時間，本文提出一種基于電子電器架構的整車OTA設計方案，實現了對升級對象的統一管理、對升級過程的集中控制，并以此提出了整車OTA的平臺化架構方案。本設計方案可應用于其他車型，解決了整車OTA涉及控制器多、升級過程不可控、升級時間長和穩定性差等問題，形成了一套從云端到車端完整的持續迭代更新能力和智能網聯汽車價值提升的新動力。

02 引言

OTA（Over-the-Air）即空中下載技術，是通過移動通信的接口實現對軟件進行遠程管理。OTA是汽車軟件升級的通道，其價值是將新軟件遠程刷寫到汽車中。軟件定義汽車逐漸成為業內共識，汽車軟件存在兩個趨勢：第一、整車廠交付的汽車將不再是一個功能固化的產品，而是一個持續更新的智能設備，在整個生命周期內，需要持續支持軟件迭代升級；第二、隨著軟件量的增加，軟件bug將成為潛在風險，OTA可以有效解決軟件故障，通過軟件升級降低開發周期短帶來的軟件風險問題，完成軟件漏洞的修復，減少軟件問題導致的召回。OTA遠程升級技術已逐漸成為智能網聯汽車的基礎功能，通過持續迭代的更新軟件，不斷提升汽車的潛在價值，從而帶動智能網聯汽車行業全新的商業模式。

03 需求分析

汽車整車OTA受限于電子電氣架構，存在很多困難。隨著汽車電子化技術的提高，電子控制單元ECU占領了諸如動力、底盤、車身、座艙以及自動駕駛等領域，ECU的數量多達幾十甚至上百個。這些ECU是由不同的供應商提供，運行著各種不同的操作系統和應用軟件，整車OTA意味著所有相關的控制器都要在一次升級過程中完成軟件版本的更新，因此升級的總時間和成功率是OTA的兩大難點。而且為了保持軟件升級的穩定性和安全性，車輛部分功能將被禁用，要求車輛處于熄火的狀態，長時間的升級會影響用戶體驗。

為了提高整車OTA的穩定性、縮短升級時間，本文提出了一種基于整車電子電器架構的OTA設計方案，實現整車版本管理和整車軟件升級。

04 總體方案設計

整車OTA的功能是控制和執行車上各類控制器的軟件升級，因此需要對所有關聯控制器提出統一的升級要求和規范，并對升級過程進行集中控制。本方案遵循“集中控制、分而治之”的原則，實現了“兩類對象、兩個過程、四種角色”：

1）兩類對象：即升級對象分為2類。

第一類是智能控制系統，基于操作系統具備自升級能力，如座艙域的車機、儀表等，駕駛域的自動駕駛控制器等；

第二類是傳統的控制器即ECU電控單元，沒有操作系統而是由刷寫上位機來完成軟件升級。

兩類升級對象須遵循各自的技術要求：智能系統要求實現版本信息維護、文件存儲、自升級以及升級異常處理等功能；傳統的控制器要求滿足UDS（汽車通用診斷服務）的刷寫規范。升級對象分類的目的在于將車上眾多的控制器按照其軟件升級方式的不同進行分類管理，對同類的控制器提出一致的技術要求規范，以便于實現OTA升級對象管理的標準化。

2）兩個過程：即升級過程分為2個過程。

第一個過程是下載部署過程，服務器將升級任務通知到車輛，車端從服務器端下載升級包到本地，這個過程可在車輛行駛中進行不會對用戶產生影響；

第二個過程是安裝過程即“車端各個控制器執行軟件升級”，這個過程需要保持車輛處于特定的狀態如車速為零、發動機熄火等，所以不能正常用車。下載部署過程和安裝過程中的執行對象、執行條件以及控制策略是不同的，將過程分段的目的在于實現OTA不同過程的差異化控制，能夠對各種過程進行集中控制，并在一個模塊中實現。

3）四種角色：即功能劃分為4個角色實現職責分離。

第一個角色是OTA服務端（OTAServer）負責web管理平臺、升級數據管理和升級文件存儲；

第二個角色是OTA客戶端（OTAClient）完成車上所有控制器的版本收集，與服務端交互獲取升級任務和上報升級狀態，下載升級包，將升級包和升級信息分發到執行升級的控制器，負責人機交互功能；

第三個角色是OTA主控模塊（OTAMaster）檢查整車的安裝條件、保持安裝狀態、按照升級策略控制安裝過程；

第四個角色是OTA子控模塊（SubMaster）保存升級包、完成所在控制器的升級功能，能夠通過車內總線或者USB等其它的物理通道對其他控制器或者固件進行升級。 

OTAClient、OTAMaster和SubMaster這三個模塊運行在車端，基于整車電子電器架構被部署到不同的控制器中。角色劃分的目的在于對功能進行模塊化設計，便于在不同車型上實現復用，從而實現該OTA方案的平臺化和可移植性。

基于上述的設計原則和設計思路，系統設計方案如圖1所示：

圖1 系統設計方案

在車端，下載部署過程，包括圖1中的步驟1.1和步驟1.2，由OTAClient發起，先從OTAServer下載文件，再將升級信息和升級包分發到各個執行升級的SubMaster；安裝過程包括圖1中的步驟2.1和步驟2.2，由OTAMaster發起，進行安裝控制，判斷整車安裝條件是否滿足，維持整車安裝狀態，按照安裝順序向各個SubMaster發出安裝命令；SubMaster分別執行具體的升級操作，完成自升級或者對其他控制器的刷寫。各個SubMaster的升級可以獨立執行，因此需要OTAMaster總體協調。

05 詳細設計

5.1 服務器端設計

服務器端,OTA Serve主要實現OTA數據的管理，為了支持整車升級，本方案設計了車型配置管理、整車版本管理、升級任務管理這三個功能。

1）每個車系需要設置車型配置組，一個組對應一個或多個車型配置，一個車型配置只能對應唯一的一個組。每個組需要配置所有控制器的軟件集合，通過軟件ID和控制器的軟件保持對應關系。

2）整車版本的管理粒度為車型配置組，每個車型配置組的軟件版本按整車大版本來進行管理，大版本是一個虛擬的版本，是車型配置組下的所有控制器軟件版本的集合標識。

3）升級任務包括升級的控制器對象、安裝策略、升級范圍。新增任務時需要設置車系、車型配置組以及對應的目標整車版本。每個升級對象可設置其軟件更新的方式、安裝的時間和異常處理的上限次數。安裝策略包括安裝條件、安裝順序和軟件版本依賴。

a)安裝條件包括：行車檔位、電池電量范圍、溫度下限、電源檔位等。在OTA管理平臺設置可設置每次OTA的安裝條件，并生成信息到升級任務中。

b)安裝順序包括升級對象的并行或者串行升級順序。在OTA管理平臺設置SubMaster和升級對象的包含關系以及升級對象之間的安裝依賴關系，在創建升級任務時根據上述關系自動生成升級任務的安裝順序。

c）軟件版本依賴包括多個關聯組，關聯組內的升級對象版本要支持同升同降。在OTA管理平臺設置控制器之間的關聯關系，創建升級任務時根據關聯設置自動生成升級任務的關聯組。

5.2 汽車端設計

5.2.1流程設計

在車端，包括下載部署過程和安裝過程，這兩個過程分別由不同的功能模塊來執行，保證各個過程中有相同的控制主體和統一的控制流程。

OTAClient通常部署在車機或者T-BOX上，具有車聯網功能、人機交互功能、文件存儲和分發的功能。OTAMaster通常部署在中心節點網關上，對升級過程進行控制和協調。SubMaster會有多個，通常部署在有操作系統（android、qnx、linux等）的智能控制器上，如車機、儀表、智能駕駛控制器等。另外，網關負責傳統控制器的刷寫功能，也需要部署一個SubMaster模塊。車端的架構如圖2所示：

圖2 車端的架構設計

1）下載部署過程，OTAClient將下載過程和分發過程進行同步處理，使兩個過程可以并發執行，以縮短升級包下載部署的時間，同時減少對儲存空間的需求。OTAClient根據硬件通道的不同，優先下載數據傳輸速率低的SubMaster節點的升級包，最后下載OTAClient所在的SubMaster節點的升級包；單個SubMaster的升級包下載完成就可以進行文件部署。如果在下載部署過程中，車輛熄火，則停止下載和部署；下次點火后，繼續在斷點處執行。整個過程可以在行車中執行，不影響用戶用車。

2）安裝過程，由OTAMaster集成控制，用戶確認發起安裝后，OTAMaster根據升級信息中安裝條件，檢測整車安裝條件是否滿足，發起安裝后一直保持安裝的狀態，如電源檔位、行車檔位、整車OTA狀態等。OTA Master依次向各個的SubMaster發送安裝請求；收到安裝請求，SubMaster各自執行升級，SubMaster之間可以進行并行升級。通常網關作為傳統控制器的SubMaster，實現各個網段之間的并行刷寫。OTA Master按照升級任務中安裝順序執行，安裝順序由多個子任務組成，子任務之間串行執行，而子任務內的升級對象則是并行執行升級。如果控制器的安裝順序存在依賴，則需要把被依賴和依賴的控制器劃分到不同的子任務中，并分配為先后的順序。升級任務的安裝總時間如公式（1）所示：

其中，t_n 為子任務n中的耗時最長的SubMaster的安裝時間。

5.2.2協議設計

為了滿足車端OTA過程中功能模塊之間數據交互的，本方案中設計了兩套通信協議，如圖3所示。

圖3 車端的通信協議

1）部署協議，主要在部署過程和人機交互過程中使用。協議采用的是客戶端和服務端（C/S）的模式，OTAClient作為客戶端，SubMaster和OTA Master作為服務端。物理的通道包括CANFD、以太網、USB等。部署協議的交互覆蓋四個子過程。

a）子過程1.1版本收集：OTAClient向各個SubMaster發出版本收集請求，SubMaster收集版本的范圍包括其所部署的控制器的軟件版本、以及所負責刷寫的其他控制器或者控制升級的其他固件的軟件版本。

b）子過程1.2升級信息和升級包的分發：OTAClient下載完成后，要向各個Sub Master傳輸升級包，以及升級對象的信息。OTAClient向OTAMaster發送升級任務信息。

c）子過程1.3發起安裝請求：OTAClient根據人機交互的觸發，發送安裝請求到OTAMaster；如果支持升級取消，也通過該子過程發送請求。

d）子過程1.4安裝狀態查詢：OTAClient查詢OTAMaster的安裝條件檢查及結果、安裝執行的狀態、安裝進度和安裝結果，用于人機交互界面的顯示。

2）安裝控制協議，主要是在安裝過程中使用，通過診斷服務，借助診斷通道到達全車所有的控制器。安裝控制協議的交互覆蓋了兩個子過程分別是，子過程2.1安裝控制：OTAMaster按照升級任務，向子任務中的各個SubMaster發出安裝命令請求，查詢安裝的進度，SubMaster返回執行狀態。子過程2.1回滾控制：當所有的子任務安裝執行完成后，OTAMaster讀取安裝結果，判斷是否有升級對象安裝失敗；并讀取升級任務中的關聯組新，如果升級失敗的對象和其他升級對象是在一個關聯組內，則向該組內其他升級對象的SubMaster發出回滾命令請求，查詢回滾的進度，SubMaster返回執行狀態。

06 應用案例

按照以上的整車OTA設計，在某車型項目上開發整車OTA功能，如圖4所示，部署升級功能模塊和搭建升級通道。車機作為OTAClient，網關作為OTA Master，實現對座艙域、車身域、動力域、底盤域、自動駕駛域的控制器的OTA功能；覆蓋了18個控制器，其中包括4個智能控制系統，14個傳統控制器；部署了5個SubMaster節點，分別是車機、儀表、網關、自動駕駛控制器、駕駛輔助控制器。

圖4 某項目整車OTA方案

在OTA管理平臺配置車型信息和控制器的升級依賴關系，發布升級任務，選擇對18個控制器，即所有升級對象進行升級，云端自動生成升級任務信息，其中的安裝順序如圖5所示。

圖5 某項目整車OTA安裝順序 

按照圖5的安裝順序，對車端OTA的過程進行記錄，下載部署過程和安裝過程的時間分別如表1和表2所示。從下載到安裝一共需要44分鐘，影響用戶體驗的升級時間主要是安裝過程，用戶需要等待升級完成的時間是28分鐘。如果所有控制器都采用串行的升級順序，安裝過程的時間是77分鐘。本方案用戶等待升級時間明顯縮短，相比串行升級時間降低63.6%，大幅提升了OTA的用戶體驗滿意度。

表1 下載部署過程的時間

表2 安裝過程的時間

如表2所示，安裝過程的耗時瓶頸主要在CANFD1網段，如果在其他網段上適當增加控制器則不會影響總的時間。如果要縮短總時間，需要對CANFD1網段的控制器進行優化，優化方向主要是減少升級包大小、將傳統控制器改為智能控制系統等。

07 結論

本文提出的一種基于電子電器架構的整車OTA設計方案，實現了對升級對象的統一管理、對升級過程的集中控制、對升級功能的模塊化設計。從試驗的效果來看，通過OTA管理平臺配置升級策略、明顯縮短了升級時間，是一個可實施、可平臺化的設計。本設計方案可應用于其他車型的整車OTA，解決了整車OTA控制器多、升級過程不可控、升級時間長和穩定性差等問題，形成了一套從云端到車端完整的持續迭代更新能力和智能網聯汽車價值提升的新動力。