OTA這個詞放在不同圈子里意思完全不一樣。搞模擬電路的人看到它想到的是跨導放大器做手機的人想到的是系統(tǒng)升級搞嵌入式的腦子里會冒出一堆RT-Thread、A/B分區(qū)之類的關(guān)鍵詞。而到了汽車行業(yè)OTA指的是把新固件從云端安全可靠地送到一臺正在路上跑的車里——這大概是我見過最難的一類遠程升級。2023年Airbiquity帶著它的OTAmatic軟件平臺拿下了Evolution Award。這個獎在圈內(nèi)算是有分量的行業(yè)認可專門獎勵那些在技術(shù)創(chuàng)新和商業(yè)落地之間找到平衡的產(chǎn)品。很多做車載互聯(lián)服務的老兵看到這個消息并不意外因為OTAmatic確實是少數(shù)幾個把車規(guī)級OTA這事兒做到能規(guī)模化交付的平臺之一。這篇文章我想從獲獎這件事切入把車載OTA的核心要點、平臺架構(gòu)的底層邏輯以及我在實際項目里踩過的坑都拆開來聊一遍希望能給正在做或者準備做OTA的朋友一些參考。1. OTAmatic獲獎背后車載OTA到底難在哪1.1 一個手機都能升級的活兒怎么車機就這么費勁手機OTA的流程大家都熟收到推送、連Wi-Fi、下載、重啟、完事兒。失敗的代價最多是手機變磚刷個機就救回來了。但車不一樣整車控制器加起來可能超過幾十個從座艙域、智駕域到車身域、動力域每個ECU都有自己的固件和升級方式。更關(guān)鍵的是車輛升級失敗不能停在路邊不動它涉及行車安全也涉及用戶對品牌的信任。車載OTA還要面對網(wǎng)絡(luò)環(huán)境的復雜性。手機升級時你大概率在Wi-Fi下車不行——車可能在高速上可能在山區(qū)地庫可能在地下停車場網(wǎng)絡(luò)信號忽好忽壞。弱網(wǎng)、斷網(wǎng)、基站切換這些都是常態(tài)。就算網(wǎng)絡(luò)穩(wěn)定還有一個法規(guī)和認證的硬約束需要滿足比如功能安全標準ISO 26262、網(wǎng)絡(luò)安全標準ISO 21434。這些標準要求的不只是功能跑通而是你有完整的流程證明這個升級是安全可控的。所以手機都能做的事車機做不了不是車機廠商技術(shù)落后而是約束條件完全不是一個量級。車載OTA真正要解決的問題不是能不能刷進去而是在五花八門的網(wǎng)絡(luò)、車型、配置、用車狀態(tài)下能不能每次都安全、可靠、合規(guī)地刷進去并且失敗還能救回來。1.2 Airbiquity和OTAmatic是什么來頭Airbiquity是一家做汽車互聯(lián)服務的老牌公司總部在西雅圖做了二十多年汽車遠程信息處理相關(guān)業(yè)務。它的核心產(chǎn)品線之一就是OTAmatic一個面向整車軟件升級管理的端到端平臺。與某些只做云端、不管車端的方案不同OTAmatic覆蓋了從云端軟件包管理、策略下發(fā)、車端升級代理到升級完成后的確認和報告這整條鏈路。OTAmatic比較能打的地方在于它對車規(guī)級這件事理解得透。比如它支持對多個ECU進行協(xié)同升級能夠處理復雜的依賴關(guān)系——有些模塊必須先升A再升B有些模塊升級過程中不能斷電有些模塊升級需要整車進入特定狀態(tài)。這些在手機OTA里幾乎不會遇到的約束在車上是一件需要認真設(shè)計的事。OTAmatic把這些能力做成了通用的平臺能力而不是每個車廠從零開始造輪子。我有段時間在幫客戶做OTA選型對比過市面上好幾家方案Airbiquity的OTAmatic在整車級升級編排上確實成熟尤其是對全車軟件版本狀態(tài)的管理和歷史記錄追溯做得非常細。后來聽說它拿了Evolution Award我的第一反應是這獎給得不算意外。1.3 這個獎的分量Evolution Award一般是行業(yè)研究和咨詢機構(gòu)評選的年度獎項評審維度通常覆蓋技術(shù)創(chuàng)新、市場表現(xiàn)、客戶價值和未來潛力。它不只看產(chǎn)品做得有多炫更看這個產(chǎn)品有沒有真正解決行業(yè)痛點、有沒有進入規(guī)?；逃秒A段。OTAmatic獲獎意味著評委會認為它在車用軟件升級領(lǐng)域做到了既有創(chuàng)新又有落地。對一個細分賽道來說這類獎項的價值不在那張證書本身而是給整個行業(yè)釋放了一個信號OTA已經(jīng)從選配功能變成了整車標配并且頭部玩家已經(jīng)開始用平臺化的方式來做這件事。對正在做技術(shù)選型的團隊來說參考成熟方案的設(shè)計思路比閉門造車要省力得多。2. 拆解OTAmatic一個OTA平臺應該長什么樣2.1 端云一體的整體架構(gòu)一個完整的OTA平臺從架構(gòu)上分三層云端管理端、傳輸管道、車端執(zhí)行端。OTAmatic的思路也是這樣但它在每一層的設(shè)計上都考慮到了車規(guī)場景的特殊性。云端管理端做的事情包括軟件包的版本管理、升級包的構(gòu)建和簽名、升級任務的策略配置、設(shè)備分組和灰度規(guī)則、升級過程的監(jiān)控和報表。這些聽起來很常規(guī)但關(guān)鍵在于它是不是真的能支撐整車幾十個ECU同時或分時升級這種復雜場景。我見過一些號稱能做OTA的平臺其實只能管理某個域控制器其他ECU全靠手工刷寫這就沒到整車OTA的層面。傳輸管道決定了升級包怎么從云端到車端。這里要考慮的事情很多下載連接是走4G/5G還是Wi-Fi升級包怎么加密分片弱網(wǎng)情況下怎么斷點續(xù)傳是不是支持邊緣節(jié)點加速。OTAmatic在傳輸這塊把可靠性放在了第一位下載失敗、校驗失敗、網(wǎng)絡(luò)切換這些異常狀態(tài)都有明確的處理機制。車端執(zhí)行端是OTA能不能落地的最后一公里。它需要做設(shè)備狀態(tài)檢測電量是否足夠、車速是否為0、擋位是否在P擋、下載管理、升級包校驗、刷寫執(zhí)行、結(jié)果回傳、失敗回滾。這層最考驗功底因為整車環(huán)境極其多樣一個異常狀態(tài)沒考慮到就可能引發(fā)線上問題。OTAmatic的車端SDK和代理設(shè)計比較成熟這也是它能在多個量產(chǎn)車型上跑起來的原因之一。2.2 A/B分區(qū)與斷點續(xù)傳為什么它們比功能本身重要很多剛接觸OTA的人會問為什么不能像手機一樣直接覆蓋升級答案跟安全性和可用性有關(guān)。A/B分區(qū)方案是目前業(yè)界比較主流的思路簡單說就是把存儲分成兩個槽位Slot A和Slot B。當前系統(tǒng)在A槽跑著升級包寫入B槽寫完以后把啟動引導切到B槽下次開機就是新版系統(tǒng)。好處有兩個一是升級過程中如果斷電或者寫入失敗當前系統(tǒng)還在A槽完好無損可以繼續(xù)正常用不會變磚二是升級結(jié)束前隨時可以回滾只要啟動引導還沒切換退回舊版本就是換個槽位的事。Android從7.0開始支持A/B分區(qū)嵌入式RTOS生態(tài)里RT-Thread的OTA組件也普遍采用A/B策略STM32平臺上用Keil做A/B分區(qū)升級的教程一搜一大把。車載場景更是把A/B分區(qū)當成一項基本設(shè)計因為車的生命周期動輒十年以上升級失敗的容錯空間極小。斷點續(xù)傳則是針對車載弱網(wǎng)環(huán)境的關(guān)鍵設(shè)計。車輛可能在地下車庫、高速隧道或者偏遠地區(qū)下載升級包網(wǎng)絡(luò)隨時可能中斷如果每次斷網(wǎng)都得從頭下載那升級體驗會非常糟糕。實現(xiàn)斷點續(xù)傳的思路是把升級包切分成多個分片每個分片獨立校驗下載到哪里就記錄到哪里網(wǎng)絡(luò)恢復后從斷點繼續(xù)。這個機制看起來不復雜但細節(jié)很多比如服務端返回的數(shù)據(jù)范圍處理、本地緩存完整性校驗、并發(fā)下載時的狀態(tài)同步都需要工程上仔細打磨。2.3 安全設(shè)計簽名、加密、防回滾汽車OTA安全目標可以概括成四句話升級包沒人能偽造傳輸途中不被篡改設(shè)備上不能跑非授權(quán)代碼升級后不能隨意回退到帶漏洞的舊版本。簽名是OTA安全的第一道防線。服務端給升級包做數(shù)字簽名車端在安裝前校驗簽名簽名不合法直接拒絕安裝。常見的做法是使用RSA或ECDSA算法生成密鑰對私鑰存放在云端安全區(qū)域公鑰預置在車端安全存儲中。簽名機制保證的是這個包是官方發(fā)布的不是路邊隨便一個人改過的包。加密解決的是傳輸途中被偷看的問題。升級包內(nèi)容通常用對稱加密算法如AES加密而對稱密鑰再用非對稱加密的方式協(xié)商下發(fā)。這樣即使傳輸通道被監(jiān)聽攻擊者拿到的也只是密文拿不到實際內(nèi)容。對整車的核心控制器固件來說這種保護是必要的因為一個熟悉逆向的工程師完全可以從明文固件里分析出系統(tǒng)漏洞。防回滾可能是一些團隊容易忽略的點。攻擊舊版本固件里的已知漏洞然后誘導系統(tǒng)降級到舊版本接著利用這是常見的攻擊路徑。解決思路是在升級包的元數(shù)據(jù)里帶上版本號和防回滾計數(shù)器車端在安裝時校驗新版本不低于當前版本或者使用安全存儲里的單調(diào)遞增計數(shù)器來防止回滾。OTAmatic在設(shè)計上把這三層安全機制都做了進去并且在密鑰管理和證書輪換方面也比較完善。2.4 OTAmatic讓我覺得值錢的幾個設(shè)計第一它把線上灰度發(fā)布做得很成熟。汽車不像手機一個嚴重的升級事故可能影響幾十萬臺車灰度發(fā)布是剛需。OTAmatic支持按VIN車輛識別代號來定向推送也可以按比例灰度比如先推1%的車觀察幾天沒問題再擴大范圍。這套機制在手機領(lǐng)域很成熟但在車載領(lǐng)域能做得這么順滑的不多。第二升級窗口的管控能力。車輛不能邊開邊升級所以O(shè)TA一定要考慮車輛的可用狀態(tài)。OTAmatic支持配置升級條件比如車速為0、電量高于某個閾值、擋位在P擋、引擎關(guān)閉只有條件滿足了才真正執(zhí)行升級。這些條件還可以按ECU類型靈活組合比如座艙域的升級條件可以寬松一些動力域的升級條件就得嚴格得多。第三升級過程的全程可視化。從云端下發(fā)到車端下載到安裝執(zhí)行到結(jié)果確認每一步都有狀態(tài)記錄。出了問題能回溯整個鏈路找出是網(wǎng)絡(luò)問題、簽名問題、還是刷寫流程問題。這一點在量產(chǎn)環(huán)境里價值非常大排障效率完全不是一個量級。3. 實操視角一個完整的車載OTA升級流程怎么搭建3.1 升級包制作差分算法怎么選做OTA平臺第一步要解決的是包怎么做。全量包大小可能幾百MB到幾個GB如果每次升級都推全量包流量成本和時間成本都扛不住。所以差分升級是標配思路只推從舊版本到新版本的差異部分車端把差異跟本地舊文件合并生成新版本。常用的差分算法有bsdiff、HDiffPatch、xdelta等選擇時要綜合考慮壓縮率、內(nèi)存占用、生成耗時和合并耗時。bsdiff在壓縮率上表現(xiàn)好但合并時內(nèi)存開銷大適合內(nèi)存充足的現(xiàn)代座艙平臺HDiffPatch的內(nèi)存占用做了優(yōu)化適合內(nèi)存受限的嵌入式控制器。實測數(shù)據(jù)上一個50MB的固件包差分包一般能壓縮到原來的10%到30%當然具體效果取決于兩個版本之間的差異程度。這里也順帶提一下Android OTA里常見的updater-script腳本。它是Android系統(tǒng)升級時執(zhí)行腳本定義了分區(qū)掛載、文件寫入、權(quán)限設(shè)置、格式化等動作。很多做Android車載系統(tǒng)的人都會手動改過這個腳本比如調(diào)整升級時擦除哪個分區(qū)、拷貝哪些文件。腳本改造的本質(zhì)是在控制升級過程的行為序列車載場景雖然不一定直接用Android的機制但思路是通的——升級行為必須定義清楚每一步干什么并且要能處理失敗時的恢復。升級包做好之后還要加元數(shù)據(jù)信息適用車型、適用ECU列表、前置版本號、目標版本號、校驗和、簽名等。這些信息會用于車端的升級前置校驗是升級包能不能被接受的關(guān)鍵依據(jù)。我的經(jīng)驗是元數(shù)據(jù)規(guī)范一定要在一開始就設(shè)計好否則后期車型多了、ECU多了狀態(tài)管理會變成一場災難。3.2 云端分發(fā)灰度、優(yōu)先級、批量控制云端分發(fā)的核心是兩個詞策略和可靠性。策略層面你需要回答幾個問題這批升級包要推給哪些車是按車型、按配置、還是按VIN列表是按比例灰度推還是按地理區(qū)域推推送優(yōu)先級怎么定是緊急修復優(yōu)先還是新功能優(yōu)先AWS IoT OTA這類公有云服務也會提供用戶策略配置能力允許你定義物聯(lián)網(wǎng)設(shè)備的升級策略、權(quán)限和批量推送規(guī)則思路可以借鑒。把這些東西落到具體實施上通常是這樣的流程先在云端創(chuàng)建升級任務選擇目標設(shè)備組關(guān)聯(lián)升級包設(shè)置灰度比例。系統(tǒng)會自動生成一批升級任務實例下沉到設(shè)備維度。每個設(shè)備實例的狀態(tài)流轉(zhuǎn)——等待下發(fā)、下載中、下載完成、安裝中、安裝完成、安裝失敗——全部記錄在案。監(jiān)控面板上可以看到整體成功率、失敗原因分布、設(shè)備在線率等關(guān)鍵指標?；叶饶Ｊ较氯绻谝慌扑偷某晒β实陀陂撝迪到y(tǒng)應該能自動暫停后續(xù)推送?？煽啃詫用嬷饕紤]的是大規(guī)模并發(fā)場景。幾十萬臺車同時升級對云端的下載服務和網(wǎng)絡(luò)帶寬是個考驗。常見方案是采用CDN或邊緣節(jié)點分發(fā)升級包而不是讓車機全部直連源站下載。OTAmatic這類平臺在架構(gòu)設(shè)計時一般會把下載鏈路做成可擴展的避免因硬件升級活動導致云端服務過載。3.3 車載端安裝UDS刷寫的流程到了車端安裝執(zhí)行的動作就要跟具體的ECU通訊協(xié)議打交道了。車控類ECU比如發(fā)動機控制器、車身控制器大多數(shù)走CAN/CAN FD刷寫流程一般基于UDS協(xié)議。UDS刷寫核心就三步進入編程會話、傳輸數(shù)據(jù)、退出并校驗。具體到服務ID0x34RequestDownload用來請求下載并協(xié)商地址和大小0x36TransferData用來分塊傳輸數(shù)據(jù)0x37RequestTransferExit表示傳輸結(jié)束并請求校驗。整個過程還要配合0x31RoutineControl來執(zhí)行擦除操作或檢查編程依賴條件。刷寫之前通常需要先通過0x10DiagnosticSessionControl切換到擴展會話或編程會話部分ECU還需要安全解鎖流程即0x27SecurityAccess。做車載OTA的團隊尤其是做中央網(wǎng)關(guān)升級的一定要對這些UDS服務很熟。因為OTA平臺最終落地時云端做得再好車端刷寫環(huán)節(jié)如果時序不對——比如先復位后校驗、先擦除后寫入的順序錯了——整個升級就會失敗甚至把控制器刷成磚。我見過一個項目就是因為在刷寫前沒有正確處理ECU的喚醒狀態(tài)導致大量升級超時失敗最后排查了很久才發(fā)現(xiàn)是UDS會話保持的問題。CAN FD和以太網(wǎng)出現(xiàn)后刷寫速度有了質(zhì)的提升。CAN FD單幀最大支持64字節(jié)數(shù)據(jù)比經(jīng)典CAN的8字節(jié)提高了不少但跟以太網(wǎng)動輒幾MB/s的速率比起來還是有差距。所以現(xiàn)在很多車型的OTA刷寫尤其是大容量控制器的刷寫會優(yōu)先走車載以太網(wǎng)CAN FD主要用于小體量ECU。3.4 驗證與回滾如何兜底升級完成不等于萬事大吉關(guān)鍵是要驗證新系統(tǒng)能不能正常工作。驗證分兩個層級一是刷寫層級的驗證刷完以后回讀校驗確保寫入的固件和升級包一致二是功能層級的驗證ECU啟動后用診斷服務確認軟件版本號、運行狀態(tài)、故障碼都正常。車端OTA代理會把驗證結(jié)果上報云端云端根據(jù)結(jié)果更新設(shè)備狀態(tài)。如果驗證失敗就觸發(fā)回滾流程?；貪L機制依賴前面說的A/B分區(qū)。當前分區(qū)是新版本備用分區(qū)還是舊版本遇到啟動失敗或者驗證失敗Bootloader就切換啟動槽位回到舊版本。整個過程用戶無感或者只有短暫的重啟等待?；貪L之后系統(tǒng)需要把失敗原因記錄到日志中方便研發(fā)團隊定位問題。需要提醒的一點是回滾動作本身也要設(shè)置閾值和防抖。如果系統(tǒng)在A/B槽位之間反復橫跳說明有嚴重問題不能無限循環(huán)切換必須進入安全模式等待人工介入。這個細節(jié)很隱蔽但常見故障直接決定整車OTA的穩(wěn)定性。4. 常見問題與排查實錄4.1 分區(qū)空間不足升級包放不下怎么辦做OTA最常遇到的第一個坑就是Flash空間不足。升級包下載到車端以后要解壓、可能要合并差分補丁臨時文件占用可能比升級包本身還大。如果車端存儲分區(qū)規(guī)劃不合理升級就會在空間不足這個環(huán)節(jié)反復失敗。排查思路是做一次端到端的空間測算分別估算升級包大小、解壓后臨時文件大小、A/B分區(qū)中目標分區(qū)的大小再對比實際可用空間。如果發(fā)現(xiàn)空間不夠優(yōu)先考慮用差分包減小傳輸體積差分包還是不夠就需要重新做分區(qū)規(guī)劃或者用流式寫入的方式來降低臨時空間占用——邊下載邊寫入而不是先完整緩存再刷寫。我在一個嵌入式項目里還遇到過另一種情況分區(qū)表調(diào)整后Bootloader里的分區(qū)偏移信息沒同步更新導致OTA寫入數(shù)據(jù)寫到了錯誤的位置系統(tǒng)無法啟動。排查了很久才發(fā)現(xiàn)是分區(qū)表配置和Bootloader配置不一致引起的。這里強烈建議做分區(qū)相關(guān)改動后要進行一次全流程的OTA回歸測試。4.2 升級到一半斷網(wǎng)了如何保證不翻車車載場景網(wǎng)絡(luò)復雜升級到一半斷網(wǎng)是必然會發(fā)生的事不是如果的問題而是什么時候的問題。斷網(wǎng)之后最基礎(chǔ)的處理是斷點續(xù)傳。車端下載代理要記錄已下載分片信息網(wǎng)絡(luò)恢復后從斷點繼續(xù)下載。這里有幾個細節(jié)容易被忽視一是分段下載后要做整體校驗不能只校驗最后一段否則中間某些分片損壞會漏過去二是下載過程中網(wǎng)絡(luò)切換如4G切到Wi-Fi時的連接重建策略要避免頻繁重連導致的任務卡死三是下載超時的判斷不同網(wǎng)絡(luò)環(huán)境下超時時間應該不一樣。升級包下載完成、安裝執(zhí)行過程中如果斷電或網(wǎng)絡(luò)中斷那就不是續(xù)傳能解決的了。此時要靠A/B分區(qū)兜底——當前系統(tǒng)還在A槽正常跑著B槽寫入失敗最多是下次重新寫不影響當前功能。整套設(shè)計最核心的原則是任何異常都不能讓車輛失去基本功能。4.3 簽名校驗失敗的坑簽名校驗失敗的案例我在不同項目里至少碰到過三五回原因五花八門。最常見的是時間不同步。如果車端系統(tǒng)時間沒有同步證書有效期的判斷就可能出錯導致明明沒過期的證書被判定為失效。解決方法是確保車端有可靠的時間同步機制比如用車載T-Box的GPS時間或NTP服務來同步。另外一個常見的坑是密鑰輪換。運維同學在云端換了簽名密鑰但車端的公鑰沒有同步更新結(jié)果升級包全部校驗失敗。這個問題在測試環(huán)境不容易暴露因為測試車輛少、密鑰更新不頻繁一旦到了量產(chǎn)環(huán)境密鑰管理體系沒做好就會踩雷。我的建議是密鑰管理系統(tǒng)要提前設(shè)計好輪換流程和多版本支持做好灰度切換不要出現(xiàn)換了新密鑰、老設(shè)備全掛這種事故。還有一種是證書格式問題。不同安全芯片對證書格式的要求不一樣有的要求DER格式有的要求PEM格式有的對證書長度有硬性限制。這些細節(jié)在集成階段就要確認清楚不然后期排查非常痛苦。4.4 容易忽略但必須處理的細節(jié)升級條件檢測的順序問題是先檢查電量再檢查擋位還是先檢查擋位再檢查電量順序不同可能導致某些場景下升級任務永遠卡在等待中。低電量保護升級過程中不能斷電所以一定要設(shè)定電量閾值低于閾值時禁止升級任務啟動或者暫停已下載的升級任務。用戶在開車過程中被提醒升級升級提醒時機要避開駕駛場景最好在車輛熄火后或者用戶主動操作時再提示避免影響用戶體驗和安全。日志管理升級失敗時的日志自動上傳機制要提前設(shè)計好否則出了問題不知道車端發(fā)生了什么只能讓車主去4S店讀數(shù)據(jù)效率極低。多語言界面提示面向用戶的升級提示文案要清晰準確很多用戶升級失敗是因為看不懂提示在升級過程中誤操作導致中斷。5. 從OTAmatic看OTA行業(yè)的走向5.1 軟件定義汽車時代的OTA角色OTA在汽車行業(yè)已經(jīng)不只是一個升級功能它變成了整個商業(yè)模式的底層能力。過去汽車賣出去之后功能就固定了有問題只能召回成本極高。現(xiàn)在不一樣很多功能可以先用OTA推送到車端軟件成了車輛體驗的一部分。Airbiquity的OTAmatic拿到Evolution Award我理解評委看重的其實不只是它能做OTA而是它幫助企業(yè)把OTA做成了可靠的、可規(guī)?；能浖\營能力。這背后的意義是有了這條通路車企可以更快地修復安全問題、持續(xù)迭代用戶功能、甚至通過軟件訂閱服務創(chuàng)造新的收入來源。這正好印證了OTA正在從工程功能轉(zhuǎn)向商業(yè)基礎(chǔ)設(shè)施。對做技術(shù)的人來說這意味著OTA相關(guān)的技能棧會越來越值錢云端的后臺開發(fā)、車端的升級代理、安全體系設(shè)計、設(shè)備管理和數(shù)據(jù)分析每一個方向都有大量需求。而那些只會做單一功能、不懂全鏈路的人競爭力會越來越弱。5.2 對中小團隊有什么可借鑒的如果你的團隊也想做OTA但資源有限不建議一上來就自研全套平臺。更務實的路徑是先梳理清楚自己的核心場景是只升級座艙域還是需要升級多個域控制器是走云端協(xié)同還是先做本地U盤升級這些選型決定了第一步的復雜度。中小團隊可以借鑒OTAmatic的思路先做最小可行閉環(huán)把升級包制作-下載-校驗-安裝-回滾這條鏈路跑通哪怕只有兩個ECU也行。第一步不要追求大而全而是把穩(wěn)定性和安全性打牢。等你的升級鏈路跑過幾千臺設(shè)備的驗證再逐步擴展ECU類型和復雜策略成功率會高很多。另外不管團隊大小OTA開發(fā)的測試工作一定要前置。很多OTA事故不是因為開發(fā)時邏輯寫錯了而是測試環(huán)節(jié)覆蓋不全——弱網(wǎng)場景沒測、斷電場景沒測、分區(qū)寫滿場景沒測。我見過一個項目開發(fā)只用了兩周測試花了兩個月最后量產(chǎn)版本一次事故都沒出。這個投入產(chǎn)出比是非常值得的。拿我自己做OTA項目這幾年來說最大的體會是OTA這個領(lǐng)域80%的工作不是把升級包推下去這個動作而是把各種異常場景都想清楚、把安全邊界設(shè)計好、把探測和恢復機制做完善。真正的高手不是能把正常流程跑通的人而是能在斷電、斷網(wǎng)、信號干擾、存儲損壞、用戶誤操作同時發(fā)生的時候還能保證車輛安全可用的人。OTAmatic獲獎是一個信號——這個行業(yè)尊重那些把復雜問題做扎實的團隊。以后有機會我再把OTA相關(guān)的一些底層細節(jié)比如差分算法實現(xiàn)、UDS刷寫時序、證書生命周期管理逐個展開來聊。