本文由朱鵬波，溫小鋒，楊毅聯合創作

摘要

隨著汽車智能化和網聯化的發展，汽車已經不再只是個簡單的交通工具，車主開始關注并期待 OEM 能否像手機更新軟件那樣遠程維護升級自己的車輛，以獲得自身更好的駕駛享受及新功能體驗。同時 OEM 為了降低由于產品軟件漏洞等引發的召回風險及新功能的迭代更新，利用遠程診斷技術，也都積極構建汽車 OTA 升級體系， 實現整車 OTA 刷新應用。文章主要介紹了汽車 OTA 和遠程診斷技術，并提出一種汽車 OTA 刷新中遠程診斷設計方案，為 OTA 升級及故障診斷提供一定的指導作用。

前言

汽車 OTA 功能已經成為時下熱門話題，以 Tesla 為代表的造車新勢力突破創新將消費電子領域“空中下載技術”成功引入到了汽車領域，掀起了全球眾多 OEM 的追隨，同時也顛覆了人們對車輛的傳統認知。OTA 升級為 OEM 提供了比傳統診斷儀更快捷、低成本的更新方式，提升用戶體驗及對品牌的忠誠度，而這些收益的背后自然是少不了主機廠遠程診斷技術的支撐。本文將介紹一種汽車 OTA 刷新中遠程診斷設計方案，主要包含 OTA 云端整體架構及診斷要求、車載終端網絡診斷架構設計、軟件存儲及刷新策略、遠程故障診斷等內容。

1 汽車OTA介紹

OTA（Over-the-Air? Technology）為“空中下載技術”，與我們常見的手機更新系統固件（軟件）的情況類似，汽車也可以同樣通過無線網絡實現遠程更新車內的各控制器內部固件（FOTA）及軟件數據（SOTA），這就是所謂的汽車 OTA技術。

主機廠積極構建的汽車 OTA 升級體系，到底能帶來什么好處呢？

第一，OTA 可以快速升級修復軟件代碼缺陷。隨著市場車輛功能配置的快速迭代，主機廠整車開發周期被迫縮短，由于軟件漏洞造成的汽車召回風險持續攀升，目前高端汽車的整車代碼量已經突破 1 億行，即使按照能力成熟度集成模型的 5 級最高軟件標準開發，仍有 0.32%的代碼缺陷率，使用 OTA 升級可減少主機廠 50%的汽車返修成本。

第二，OTA 給主機廠帶來新的“營銷模式”。“軟件定義” 汽車（SDV）概念的出現，給傳統的汽車售賣硬件的方式帶來的巨大的變革，已經賣出去的車輛還可以軟件付費方式開通一些“升級包”，如 Tesla 的完全自動駕駛（FSD）升級包。統計數據顯示，預計未來五年軟件定制市場的年均復合增長率約為 30%，2023 年全球汽車軟件定制市場規模有望達到275.42 億元，因此主機廠可 OTA 升級的軟件潛力及效益可觀。如圖 1 所示：

圖 1 全球汽車軟件定制市場規模及增速?

第三，主機廠通過 OTA 方式，可改善車輛的動力、剎車、續航、人機交互系統以及智能輔助駕駛系統的更優體驗。使車輛的整體性能及功能變得更優異，增加了車主的新鮮感，也增加了車主對車輛的品牌忠誠度。

汽車 OTA 帶來眾多好處的同時也對主機廠提出了新的挑戰，無論是 OTA 云端架構設計、信息安全、后臺軟件版本管控等，還是車輛終端的車載網絡診斷架構設計、遠程故障診斷、OTA 刷新流程、ECU 軟件刷新策略等方面，都需要OEM 全面考慮和充分測試驗證，避免 OTA 推送后車輛出現“癱趴”現象，導致車主適得其反的體驗。

2 汽車遠程診斷

汽車遠程診斷是指在車輛不需要開回 4S 店的情況下， 依靠車輛具備的移動通訊能力（WIFI/4G/5G）完成主機廠后臺（或手機端 APP）對車輛進行遠程控制及診斷操作的一種診斷技術。

遠程 OTA 刷新就屬于遠程診斷應用的一種場景。此外，遠程診斷技術通過與物聯網、大數據、云計算等前沿技術融合后，還可為主機廠在研發試驗、產線電檢、售后診斷等領域提供重要支撐。

首先，遠程診斷可以在線采集數據，降低開發周期及成本。研發階段車輛需要進行大量道路試驗、耐久試驗，而試驗車配備的數據采集設備有限，通過遠程診斷，試驗過程中出現的車輛故障現象可以及時反饋給研發人員分析和仿真，快速協助解決故障問題。

其次，遠程診斷可以在產線電檢跨工位實現初始化及功能檢測、產線 OTA 刷新，實現汽車軟件定制化生產，滿足車主定制化需求。

最后，遠程診斷可以周期性監控車輛狀態，實時診斷車輛健康，結合大數據統計分析進行車輛故障預警，通過后臺推送給廠家售后 4S 店進行車輛保養及維修指導建議。

3 OTA刷新遠程診斷設計

OTA? 刷新系統架構主要由服務器（云平臺）、傳輸媒介（3G/4G/WIFI/5G）和車載終端（ECU）三部分構成。本文基于如圖 2 所示的 OTA 刷新系統架構設計，重點針對服務器（云平臺）和車載終端（ECU）進行遠程診斷詳細方案介紹。

3.1 OTA 服務器?

圖 2 OTA 刷新系統架構

OTA 服務器又稱為 OTA 云平臺，在軟件刷新過程中起連接用戶（車廠、車主）與車輛的作用，為實現車輛遠程智能診斷及故障預測分析，OTA 云平臺設計一般要求都部署在車廠的私有服務器上，能夠支持多種車型 OTA 升級。

3.1.1 OTA 云平臺整體架構

OTA 云平臺主要包含用戶管理、固件管理、車輛管理、升級任務管理、統計分析管理、用戶操作日志管理模塊，如圖 3 所示。

圖 3 OTA 云平臺整體架構

用戶管理模塊：OTA 云平臺為車廠提供的是一套軟件系統，因此需要有用戶管理模塊來實現用戶權限分配及管理工作。系統搭建環境默認創建超級管理員用戶，由超級管理員用戶登錄后在用戶管理模塊實現用戶新增，用戶查看，用戶信息修改等功能操作。

固件管理模塊：主要為用戶提供固件上傳，固件查詢及編輯（版本管理）功能。用戶將車廠測試通過的固件上傳到OTA 云平臺，用以升級任務創建。

車輛管理模塊：主要包含車輛 ECU 信息同步、車輛 ECU 信息獲取及車輛信息查看功能。車輛 ECU 信息同步子模塊對接主機廠 MES（生產制造）系統，可導入不同車型配置信息用以 OTA 升級時對目標車輛篩選及升級策略配置。

升級任務管理模塊：主要負責為用戶提供升級任務創建、升級任務審批、升級任務查詢、升級進度查詢功能。

統計分析管理模塊：主要負責統計分析已發布的升級任務執行結果情況。用戶可以查看每個升級任務對應的升級車輛的成功率、失敗原因統計及未執行升級原因統計分析。

用戶操作日志管理模塊：主要負責為超級管理員用戶提供所有登錄 OTA 云平臺的用戶的所有功能操作記錄。

3.1.2 OTA 云平臺診斷要求

OTA 云平臺必須符合高可用、高性能、可擴展、可監控的診斷要求。具體表現為以下幾個方面：

（1）采用微服務的 Browser/Server(瀏覽器/服務器)的服務框架，能夠支持多種負載均衡模式（服務消費者從提供者列表中，基于軟負載均衡算法（隨機、權重、輪詢、最少并發優先等）選一臺服務提供者進行遠程調用，如果調用失敗， 需自動診斷并切換另一臺服務提供者）；

（2）立體化監控，能夠對系統資源（CPU、負載、內存、網絡和磁盤等）基礎指標進行詳細的監控，對于系統的每一次服務調用響應時間和出錯率進行故障診斷和預警；

（3）系統具備高可靠和高性能，確保整個系統上運行的業務體系能夠為客戶系統提供 99.9%可用性的高效優質服務；

（4）采用服務集群的管理技術，利用多個計算機并行計算從而獲得高性能和冗余備份，即便單機故障時整個系統仍能正常工作；

（5）系統具備故障隔離機制，在應用軟件系統發生故障時，通過故障隔離可將故障危害限制在最小范圍內，提高系統對外服務的整體能力。

3.2 OTA 車載終端?

OTA 車載終端作為 OTA 升級的執行方，以 OTA 推送方式為例，用戶可感知體驗的部分較多，車載終端的設計重點需考慮人機交互、網絡診斷架構設計、ECU 刷新時長、軟件存儲及刷新策略、遠程故障診斷機制。

車載終端網絡框架如圖 4 所示，OTA 主控節點由 TBOX 和中央網關（GW）負責，升級界面由車機負責，被刷新的ECU 要求支持車載以太網（DoIP）或 CAN 總線（DoCAN） 通訊協議，若 ECU 升級包較大（如上百兆）需要支持數據差分算法。

圖 4 OTA 車載終端框架

3.2.1 OTA 人機交互設計

OTA 升級時除了云平臺推送升級任務到車主 APP 提醒外，還需車端（車機或中控）配合開發顯示一些升級界面（如升級進度、升級條件提醒等），用于提醒車主車輛設防及離車等配合操作，如圖 5~圖 9 所示。

圖 5 OTA 系統更新推送

圖 6 OTA 更新日志

圖 7 OTA 升級通知用戶授權同意

圖 8 OTA 升級過程中

圖 9 OTA 升級成功

3.2.2 網絡診斷架構設計

目前車載網絡主干網仍以成熟的 CAN 總線通訊為主， 但對于軟件包較大的ECU 由于刷新時長等因素，使用了車載以太網技術來突破CAN 總線的帶寬限制，如圖 10 所示。

主要架構包含 OTA 主控節點（TBOX 和GW）和被刷新ECU。TBOX 主要負責對外與云平臺的連接通道安全可靠， 其內部集成了PKI 認證及身份鑒權等安全模塊；GW 主要負責對內部網絡的連接通道及集成診斷刷新機功能。刷新 ECU 根據軟件包大小及理論刷新時長（如不超過20分鐘），在 CAN 總線拓撲架構上增加了以太網接口設計，使用 DoIP 協議進行ECU 診斷刷新。

圖 10 網絡診斷架構圖

3.2.3 ECU 軟件存儲及刷新策略

OTA 刷新前 ECU 軟件升級包由云平臺下發到車端 OTA 主控節點內存儲，由文件存儲模塊來負責整車軟件升級包的存儲及備份包的管控。

升級管理模塊主要負責刷新機刷新策略控制，OTA 刷新需要設計多次冗余刷新策略，即 OTA 后臺發起一次升級任務后，同一輛車內 OTA 主控節點刷新機通常會對同一個 ECU 執行多次刷新嘗試請求，減少偶發失敗因素，提高 OTA 刷新成功率。

被刷新 ECU 主要分為傳統嵌入式芯片 ECU 和復雜帶操作系統（如Linux、Android、AutoSAR）的 ECU。根據 ECU 的硬件資源情況，我們又設計了如下 ECU 內部存儲及刷新策略：

如圖 11 所示的帶操作系統 ECU，硬件存儲資源豐富， 控制器內分配了兩個不同啟動區分，具體刷新過程如下：

a）默認出廠狀態啟動分區 1 激活，運行 V1.0 版本程序，啟動分區 2 內無備份程序；

b）當 OTA 發起第一次 V1.1 版本刷新請求時，刷新數據會存儲在備份分區（分區 2），刷新成功后激活啟動分區 2，并交換備份分區（分區 1），下次上電后程序由啟動分區 2 啟動并正常工作；

c）當 OTA 發起第二次 V1.2 版本刷新請求時，刷新數據會被存儲在備份分區 1，刷新成功后激活啟動分區 1 并交換備份分區（分區 2），下次上電后程序由啟動分區 1 啟動并正常工作；

d）當 OTA 發起第三次 V1.3 版本刷新請求時，刷新數據會存儲在備份分區（分區 2），刷新成功后激活啟動分區 2，并交換備份分區（分區 1），下次上電后程序由啟動分區 2 啟動并正常工作。

如此循環交換分區刷新，即便遇到刷新失敗當前啟動分區無法正常啟動時，ECU 也還可以通過自回滾從備份分區啟動，確保系統工作正常。

圖 11 帶操作系統的 ECU 軟件存儲及刷新策略圖

對于傳統嵌入式 ECU，通常采用 BOOT+APP 的軟件架構，如圖 12 所示。功能越復雜的 ECU，其選擇的主控芯片APP 容量越大，為了實現 ECU 內部軟件自回滾功能，需要將 APP? 空間劃分一部分用于軟件備份存儲（如 APP2）。當 ECU 被刷新時，由 BOOT 代碼負責提供升級流程引導，將升級包存儲到 APP 區域（一般為程序啟動入口地址空間）。由于嵌入式芯片ECU 程序啟動入口通常只有一個，因此，當刷新失敗（APP 激活不了）時，由 BOOT 引導程序指引復制APP2 的備份程序到 APP 區域進行回滾操作并啟動，確保 ECU 工作正常。對于 APP 容量較小不支持 APP2 空間劃分的 ECU，只能依靠 OTA 主控節點實現升級包的備份存儲。

圖 12 嵌入式 ECU 軟件存儲及刷新策略圖

3.2.4 OTA 遠程故障診斷設計

OTA 刷新目前主要是通過診斷通訊方式實現的 ECU 刷新條件檢查、刷新過程數據傳輸及刷新后復位重啟等操作，刷新過程中被刷新 ECU 由于進 BOOT 或其它原因無法保證應用程序正常運行（無感刷新方式除外）時，需要提前進行 ECU 故障屏蔽設計以免刷新過程造成整車出現一些故障碼， 誤導后續遠程故障診斷及統計分析。

OTA 刷新過程中，診斷故障屏蔽可采用 UDS 診斷協議中的 0x85（ControlDTCSetting）服務來實現。

OTA 遠程故障診斷，還要解決的一個難點是與本地故障診斷的沖突問題。OTA 云平臺難以識別本地診斷設備，因此，必須要在車端集成遠程診斷與本地診斷的仲裁判斷邏輯。如圖 13 所示，由中央網關（GW）負責仲裁協調，當 OTA 刷新過程中，網關屏蔽本地故障診斷路由轉發功能；同理，當有本地診斷設備時，網關屏蔽遠程故障診斷路由轉發功能，屏蔽只在當前點火循環有效。

4 結論

汽車 OTA? 刷新為遠程診斷技術帶來了迫切的需求和絕佳的發展機遇，主機廠積極部署的 OTA 升級體系和遠程診斷平臺，不僅是為了當下車輛的軟件漏洞修復和功能快速更新，更是為了適應“軟件定義”汽車（SDV）的趨勢及更高階的自動駕駛的技術發展，而主機廠遠程診斷平臺積累的數據，正是考驗其大數據挖掘與智能診斷應用相結合的綜合能力。身為“領頭羊”的特斯拉，通過遠程診斷技術已經實現 90% 情況下的車輛部件故障診斷，每年可為車主節省一天維修工時。國內車企要奮起直追，為車主提供更便捷、滿意的服務體驗，仍需較長的發展歷程。

總結

以上是生活随笔為你收集整理的远程诊断技术在汽车 OTA 刷新应用的研究的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。