基于空中激活的近場軟件升級方法

范玲玲 柳旭 張建平 徐晉吉 劉闖 沙偉華

（中國第一汽車股份有限公司研發總院，長春 130013）

1 前言

車聯網技術、高級自動駕駛技術發展迅速，對汽車軟件快速升級的能力提出了要求。當前，汽車軟件升級方法主要包括線下診斷儀升級和空中激活（Over The Air，OTA）升級[1-3]。

王棟梁等[4]提出一種安全、方便、可靠的整車OTA 解決方案，建立云服務器端與車輛客戶端之間的數據通路，使用差分算法、回滾重刷機制等關鍵技術，實現整車Ethernet/CAN/LIN 混合電子電氣架構的所有節點電子控制單元（Electronic Control Unit，ECU）的升級更新。劉志軍等[5]構建了整車網聯系統架構，并設計了一種基于OTA 技術的ECU 遠程刷寫協議，利用移動通信網絡基于OTA 更新ECU軟件。高天宇[6]提出了一種基于差分方法的遠程數據刷寫系統，實現了汽車ECU 軟件迭代升級和相關數據的更新刷寫。

上述文獻研究的整車OTA 升級技術主要分為2個階段：OTA 云端發布升級任務，車端接入獲取升級任務；經用戶確認升級或者有效期內未升級，任務結束。只要云端任務下發到車端，車端就具備了軟件刷寫的主動權，如用戶不及時確認升級，任務就無法完成，且無線網絡連接無法保證車輛實時在線，車端任務也無法及時被云端終止。

綜上，現有OTA 升級技術更適用于售后階段，同時，用戶頻繁使用車輛更有助于車端長時間接入OTA 云端，并確認完成軟件升級。售前階段主要包括試制、生產、儲存、運輸等，車輛主要處于靜止狀態，接入云端的次數非常有限，單純依靠現有OTA的升級模式無法滿足軟件快速迭代的需求，也就無法保證車輛售出時的軟件版本一致性。

因此，本文提出一種基于OTA 的智能汽車近場軟件升級技術，主要由近場設備主控車端完成軟件升級，近場設備可方便地從OTA 云端獲取某一車型的ECU 軟件信息，控制單輛車完成任意ECU軟件升級，或者控制批量車完成某一整車基線版本升級。

2 近場軟件升級技術

基于OTA 的智能汽車近場軟件升級技術復用OTA 系統已有的云端升級包管理功能、ECU 軟件刷寫功能。由近場升級設備從OTA 云端獲取車型ECU 的升級包及基線，控制車端依次完成ECU 的軟件更新，車端被動執行，其升級方式包括近場客戶端完成單輛車升級和近場服務器完成批量車升級。

其中：近場客戶端可通過有線連接或局域網無線連接的方式接入車輛，并控制車端依次完成整車ECU 的軟件升級；近場服務器可通過局域網連接的方式與車端建立連接，由車端主動發起接入請求，近場服務器依據車型基線控制車端依次完成整車ECU 的軟件升級[4-5]。近場服務器主要包括工廠服務器，近場客戶端主要包括計算機客戶端、手機APP 和USB 設備。近場軟件升級框架如圖1 所示。

圖1 近場軟件升級框架

因此，近場軟件升級技術相比現有的診斷儀刷寫，不僅在功能上更加全面，更能配合OTA 系統實現智能汽車整車軟件版本一致性的管理需求，同時節省了額外開發ECU 刷寫上位機的成本，在使用上更加靈活。

3 近場軟件升級技術

3.1 近場客戶端設計

近場客戶端采用主動升級方式，由客戶端主動發起車輛接入、軟件升級請求，升級模式分為單ECU 升級和批量多ECU 升級。近場客戶端部署的載體可以是便攜式計算機、手機或者車機，可靈活應對操作人員現場對單輛車進行整車ECU 軟件升級需求。當客戶端部署在車機上時，通過接入USB設備獲取ECU升級包。

近場客戶端為桌面式軟件，具備可視化用戶界面（User Interface，UI），主要功能包括車型管理、軟件升級、系統管理及安全管理，如圖2所示。

圖2 近場客戶端功能

車型管理功能主要完成車型與ECU 的綁定關系，可通過手動錄入或云端同步的方式更新，操作人員可依據待升級車輛進行相應的車型切換選擇。

軟件升級功能主要完成與車端的接入及數據交互，顯示車輛上報的車輛基本信息及各ECU 版本信息，操作人員依據車輛信息選擇升級包，開始升級并實時顯示升級狀態，選擇的升級包可以是單包或多包，從而執行單ECU升級或批量多ECU升級。

安全管理功能主要完成近場客戶端與OTA 云端、車端的安全通信管理，包括登錄的雙向認證、客戶端的賬號安全管理、數據傳輸的安全管理。

系統管理功能主要完成近場客戶端的相關連接設置，包括OTA 云端訪問地址、車端連接地址、本地存儲路徑的管理[7-9]。

3.2 近場客戶端升級流程設計

近場客戶端軟件升級流程主要包括：

a.車型同步及升級包下載。近場客戶端首先連接OTA 云端同步所有車型及ECU，操作人員選擇即將應用的車型后，近場客戶端向OTA 云端獲取該車型對應ECU 的升級包列表，操作人員可根據需要下載相應升級包，近場客戶端可詳細顯示升級包下載進度，并將已下載的升級包名稱加入本地升級包列表[10]。

b. 連接車輛及身份認證。近場客戶端通過有線或者無線局域網的方式連接車輛后，向車端發起登錄請求并上傳證書等身份信息，車端對近場客戶端完成身份認證后，上報車端基本信息于近場客戶端顯示。

c. ECU 軟件同步更新。操作人員依據近場客戶端上的車輛顯示信息可批量選擇需升級的ECU及對應的升級包，開始逐一更新ECU 軟件，近場客戶端可顯示詳細升級進度。

d. 升級結束及斷開連接。所有ECU 升級完成后，近場客戶端顯示車端最新狀態，操作人員依據車輛信息分析該車輛是否已完成軟件升級，并斷開連接[11-12]。

3.3 近場服務器設計

近場服務器采用車輛主動接入、服務器主動升級方式，由車輛主動發起接入服務器，服務器依據車輛信息下發升級指令，升級模式為整車版本升級。近場服務器可部署在服務器集群中，通過局域網網頁訪問，處于同一局域網中的車輛可接入近場服務器，完成整車控制器版本升級。近場服務器適用于對批量車輛進行軟件版本拉齊，如工廠階段下線車輛軟件灌裝、運輸階段批量車輛軟件升級等場景[13]。

近場服務器以微服務器加網頁訪問的方式實現，可實現車輛信息收集，主要包括車型管理、車輛管理、軟件升級、車輛接入、系統管理及安全管理功能，如圖3所示。

圖3 近場服務器功能

車型管理主要完成車型、配置、ECU 及基線的管理，可通過手動錄入、批量導入或云端同步的方式更新。

車輛管理功能主要完成接入車輛的狀態管理，包括車輛識別碼（Vehicle Identification Number，VIN）、車型、配置、整車軟件版本、ECU 版本信息、連接狀態、升級狀態的管理。車輛首次接入近場服務器后，車輛管理模塊登記該車輛的基本信息，后續每次接入均會記錄接入狀態及升級狀態。

軟件升級功能主要實現升級任務的創建、任務狀態查詢、任務終止功能。服務器端為某一個車型配置建立升級任務后，該車型配置的車輛接入后將執行一次軟件升級任務。

安全管理功能主要完成近場服務器與OTA 云端、車端的安全通信、服務器賬號管理，包括車輛接入的雙向認證、服務器端的賬號安全管理、數據傳輸的安全管理。

系統管理功能主要完成用戶管理、日志管理、導入導出日志管理、同步日志管理。該功能支持新增用戶、修改用戶、刪除用戶、重置密碼、查詢操作日志、導出操作日志、查詢導入導出日志、下載導入導出文件、查詢同步日志、導出同步日志、查看同步日志。

3.4 近場服務器端升級流程設計

近場服務器端升級流程為：

a.車型、基線及升級包同步。近場服務器首先連接OTA 云端同步所有車型及ECU，操作人員可手動同步某車型對應的所有基線及升級包，也可手動新建或者導入某個基線。

b. 車輛接入及身份認證。車端開啟近場升級服務后，會周期性地嘗試請求接入近場服務器，近場服務器收到車輛接入請求后進行身份認證，認證通過后上報車輛基本信息，近場服務器記錄保存。

c. ECU 軟件同步更新。近場服務器依據車輛上報信息查看該車型配置是否有升級任務，若有則下發需要更新的ECU 軟件包，完成該車輛的基線拉齊操作，近場服務器可顯示詳細升級進度。

d. 升級結束及斷開連接。車端完成下發ECU軟件更新后上報車輛最新狀態，近場服務器依據狀態信息判斷車輛軟件是否為最新基線狀態并顯示，之后斷開連接[14-15]。

3.5 近場服務器與近場客戶端的差異

近場客戶端采用與單一車輛進行點對點連接方式，人為觸發每一次軟件升級，因此同一時刻只能有一輛車連接近場客戶端進行升級，升級完成后近場客戶端也無需記錄車輛的狀態，故只需要在軟件升級功能模塊中實時完成接入車輛的信息顯示、軟件升級執行等。

而近場服務器采用車輛主動接入方式，可接受批量車輛同時接入，無需人為觸發，服務器建立升級任務后，車輛接入即可自動觸發軟件升級，因此服務器的車輛管理功能需要記錄每一輛接入車輛的升級信息。

近場客戶端與近場服務器的功能異同如表1所示。

表1 近場客戶端與近場服務器功能異同

4 關鍵技術

4.1 近場升級工具跨平臺設計

近場升級工具形式多樣，包括便攜式計算機、手機、車機、工廠服務器，但實現的功能基本一致，且近場客戶端、近場服務器與車輛的連接方式有所區別，因此需要設計實現既能兼容不同載體平臺，又能滿足不同車輛連接方式的近場升級技術。近場工具采用QT 框架開發，車端通信采用基于傳輸層安全協議（Transport Layer Security，TLS）通道的消息隊列遙測傳輸（Message Queuing Telemetry Transport，MQTT）協議[16]。MQTT 是一個基于客戶端-服務器的消息發布/訂閱傳輸協議，該協議輕量、簡單、開放且易于實現。

車端部署MQTT Broker，用于管理近場工具與車端通信的MQTT 消息。MQTT 消息格式如圖4 所示，依據主題（TOPIC）類型分為控制類（CTRL）、狀態類（REPORT）、文件傳輸類（XFER）、控制響應（CTRL/REPLY）、狀態響應（REPORT/REPLY）。其中車端管理模塊訂閱CTRL和XFER消息，近場工具訂閱REPORT、CTRL/REPLY 和REPORT/REPLY 消息。

圖4 MQTT協議格式

對于近場服務器，由車端主動訪問服務器后，再由服務器主動發起升級，所以近場服務器中同時部署MQTT Broker，用于監管車輛的登錄服務請求。

近場升級工具與OTA 云端通信方式統一采用RESTful API 方式。實現的接口主要有：查詢ECU軟件信息、查詢指定車型下的ECU 列表、查詢指定車型下的軟件版本列表、查詢指定車型整車版本列表、指定ECU軟件升級包的下載[17-18]。

近場工具依據功能邏輯及多平臺設計要求，分為核心功能、數據業務、功能組件及基礎組件，如圖5 所示。近場工具軟件設計盡量模塊化，以實現不同平臺最大程度共用軟件模塊，只在界面設計及響應邏輯上區別開發。

圖5 近場升級工具軟件架構

4.2 整車基線同步策略

將智能汽車每個ECU的軟件狀態進行標記，所有ECU的軟件標識組成一個基線標識，一個基線標識包含唯一一組ECU軟件標識，如圖6所示。通過基線標識可以很好地管理整車ECU軟件，智能汽車每一次的功能升級都對應唯一的基線標識，按照基線標識更新迭代可以實現整車ECU軟件版本的有序管理，防止各ECU軟件版本不兼容帶來的功能異常問題。

圖6 整車基線管理

近場升級服務器需要對每個車型配置的所有整車基線進行管理，包括自定義基線和同步基線，自定義基線標識和同步基線標識應唯一。

自定義基線可通過手動建立，建立時選定各ECU 對應軟件標識：如果當前系統中已存在該基線標識且為自定義基線則更新已存在基線；如果當前系統中已存在該基線標識且為同步基線，則新建自定義基線無效。

同步基線可通過操作人員手動執行實現。同步基線后如果當前系統中已存在該基線標識且為自定義基線，則以新同步基線為準更新自定義基線；如果存在該基線標識且為同步基線，則更新同步基線。

升級任務已綁定的基線，無論是自定義基線或同步基線，同步時均需要顯示警告，由操作人員決定是否停止或更新升級任務。

5 試驗驗證

5.1 試驗方案

針對上述方案搭建臺架驗證環境，原理如圖7所示。車載通信終端（Telematics-BOX，T-BOX）、中央網關（Central Gateway，CGW）、車載診斷系統（On-Board Diagnostics，OBD）組成車端環境，其中OTA 車端軟件集成在CGW 中。便攜式計算機通過有線方式連接到OBD 上，可通過OBD 直接與CGW建立安全通道。手機連接T-BOX 熱點后，可與CGW 建立安全通道。工廠服務器通過有線方式與路由器連接，路由器提供局域網WiFi，車端T-BOX可直接連接WiFi 與工廠建立安全通道，同時計算機端可以通過局域網訪問工廠服務器進行近場軟件升級管理。

通過上述驗證環境可對近場升級客戶端進行功能驗證，部分測試項如表2 所示。對近場升級服務器進行功能驗證，部分測試項如表3所示。

表2 近場升級客戶端功能測試項

表3 近場升級服務器功能測試項

5.2 試驗結果

對近場升級工具分別進行功能測試，測試結果均滿足功能設計要求。

將車輛軟件升級時間劃分為車輛接入及任務下發時間、升級包下載時間、升級包傳輸時間、用戶確認時間及軟件升級時間，以全景影像功能為例，升級包大小408.61 MB，升級所需時間如表4 所示，近場服務器升級時間較OTA 升級時間縮短一半以上，且無需人員在車機上進行操作。

表4 OTA與近場服務器升級全景影像功能時間 s

6 結束語

針對當前智能汽車軟件更新迭代快，導致售前車輛的軟件版本難以統一的問題，本文設計了一種近場軟件升級方法。

該方法基于現有OTA 車云系統，使用便攜式計算機、手機或USB 設備進行單輛車軟件快速升級，使用工廠服務器通過局域網進行批量車整車軟件基線版本快速拉齊。臺架試驗結果表明，該升級方法所需升級時間較OTA 系統升級時間縮短一半以上，可有效提升軟件升級效率。該方法的應用場景可有效補充OTA 系統升級場景，應用于智能汽車試制階段、工廠階段、運輸階段的軟件版本快速更新。未來，可協同OTA 云平臺完成車輛整車軟件版本實時、同步管理，實現車輛全生命周期軟件可控。