前 言

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

01 汽車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推送后車輛出現“癱趴”現象，導致車主適得其反的體驗。

02 汽車遠程診斷

汽車遠程診斷是指在車輛不需要開回4S店的情況下，依靠車輛具備的移動通訊能力（WIFI/4G/5G）完成主機廠后臺（或手機端APP）對車輛進行遠程控制及診斷操作的一種診斷技術。 遠程OTA刷新就屬于遠程診斷應用的一種場景。 此外，遠程診斷技術通過與物聯網、大數據、云計算等前沿技術融合后，還可為主機廠在研發試驗、產線電檢、售后診斷等領域提供重要支撐。

首先，遠程診斷可以在線采集數據，降低開發周期及成本。 研發階段車輛需要進行大量道路試驗、耐久試驗，而試驗車配備的數據采集設備有限，通過遠程診斷，試驗過程中出現的車輛故障現象可以及時反饋給研發人員分析和仿真，快速協助解決故障問題。 其次，遠程診斷可以在產線電檢跨工位實現初始化及功能檢測、產線OTA刷新，實現汽車軟件定制化生產，滿足車主定制化需求。 最后，遠程診斷可以周期性監控車輛狀態，實時診斷車輛健康，結合大數據統計分析進行車輛故障預警，通過后臺推送給廠家售后4S店進行車輛保養及維修指導建議。

03 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云平臺必須符合高可用、高性能、可擴展、可監控的診斷要求。 具體表現為以下幾個方面：

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

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

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

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

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

3.2 OTA車載終端

OTA車載終端作為OTA升級的執行方，以OTA推送方式為例，用戶可感知體驗的部分較多，車載終端的設計重點需考慮人機交互、網絡診斷架構設計、ECU刷新時長、軟件存儲及刷新策略、遠程故障診斷機制。車載終端網絡框架如圖4所示，OTA主控節點由TBOX和中央網關（GW）負責，升級界面由車機負責，被刷新的ECU要求支持車載以太網（DoIP）或CAN總線（DoCAN）通訊協議，若ECU升級包較大（如上百兆）需要支持數據差分算法。

圖4 OTA車載終端框架

3.2.1 OTA人機交互設計

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

3.2.2 網絡診斷架構設計

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

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

圖5 網絡診斷架構圖

3.2.3 ECU軟件存儲及刷新策略

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

升級管理模塊主要負責刷新機刷新策略控制，OTA刷新需要設計多次冗余刷新策略，即OTA后臺發起一次升級任務后，同一輛車內OTA主控節點刷新機通常會對同一個ECU執行多次刷新嘗試請求，減少偶發失敗因素，提高OTA刷新成功率。被刷新ECU主要分為傳統嵌入式芯片ECU和復雜帶操作系統（如Linux、Android、AutoSAR）的ECU。

根據ECU的硬件資源情況，我們又設計了如下ECU內部存儲及刷新策略：如圖11所示的帶操作系統ECU，硬件存儲資源豐富，控制器內分配了兩個不同啟動區分，具體刷新過程如下：

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

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

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

當OTA發起第三次V1.3版本刷新請求時，刷新數據會存儲在備份分區（分區2），刷新成功后激活啟動分區2，并交換備份分區（分區1），下次上電后程序由啟動分區2啟動并正常工作。如此循環交換分區刷新，即便遇到刷新失敗當前啟動分區無法正常啟動時，ECU也還可以通過自回滾從備份分區啟動，確保系統工作正常。

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

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

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

3.2.4 OTA遠程故障診斷設計

OTA刷新目前主要是通過診斷通訊方式實現的ECU刷新條件檢查、刷新過程數據傳輸及刷新后復位重啟等操作，刷新過程中被刷新ECU由于進BOOT或其它原因無法保證應用程序正常運行（無感刷新方式除外）時，需要提前進行ECU故障屏蔽設計以免刷新過程造成整車出現一些故障碼，誤導后續遠程故障診斷及統計分析。OTA刷新過程中，診斷故障屏蔽可采用UDS診斷協議中的0x85（Control DTC Setting）服務來實現。OTA遠程故障診斷，還要解決的一個難點是與本地故障診斷的沖突問題。OTA云平臺難以識別本地診斷設備，因此，必須要在車端集成遠程診斷與本地診斷的仲裁判斷邏輯。由中央網關（GW）負責仲裁協調，當OTA刷新過程中，網關屏蔽本地故障診斷路由轉發功能；同理，當有本地診斷設備時，網關屏蔽遠程故障診斷路由轉發功能，屏蔽只在當前點火循環有效。

04 結 論

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

審核編輯：湯梓紅