OTA 升級能夠實現車輛重要功能的常用常新，更重要的是通過 OTA ，汽車製造商可以在產品售出後通過增加功能的方式繼續獲得收入。這也是爲什麼 Musk 認爲未來搭載了 FSD 的特斯拉車型會變成一件「持續升值的產品」。
不管大家對 Musk 的看法如何，特斯拉的整車 OTA 能力想必是很多車企十分羨慕和渴求的功能。
因爲特斯拉不只是簡單地把軟件升級包從雲端下發至車內的 T-Box（Telematics Box,負責汽車無線通訊），來升級地圖等車機內嵌的 APP 應用。它還能夠直接把補丁直接發送至相關的、獨立的 ECU，實現對汽車主被動、網絡安全甚至是關鍵控制功能的升級。
很多人之前把未來的汽車暢想成「一臺手機加四個輪子」，所以也理所當然地認爲整車 OTA 應該和我們升級手中的 iPhone 一樣簡單。但其實從架構的角度來看，智能手機基本只配備了一臺處理器來運行各種 APP，但汽車內部 ECU 的數量至少有上百個，它們連接在不同的車內通訊網絡上，同時每條網絡又有着不同的數據傳輸協議。
畢竟這個世界上不存在「沒有漏洞」的軟件。整個汽車產業都在朝着「軟件定義」的方向逐步進化，所以能夠及時通過 OTA 升級修正錯誤的能力就顯得十分必要了。特別對智能互聯汽車而言，一旦被黑客入侵，輕者造成財產損失，重者會危及到乘客生命安全。這個時候，能夠及時阻止傷害進一步發生最有效的方式就是通過 OTA 把軟件漏洞堵上。
這要比手機系統升級複雜得多。在受到特斯拉以及蔚來、小鵬等新造車勢力圍追截堵的壓力下，傳統車企希望能儘快讓自己的產品和雲端連接起來。最迫切的需求是能夠實現 OTA 軟件升級，主要功能的實時更新，車輛維修/異常探測以及防止網絡黑客的入侵。
但問題是，特斯拉的整車架構是從零開始打造的，傳統車企基於燃油車平臺規劃的電動車型與之相比還是有很大區別的。所以假設要實現類似特斯拉的 OTA 功能，在獨立規劃的電動汽車產品量產前，幾乎所有的車企都需要找到一個「合適」且足夠安全的解決方案才行。這就讓提供「汽車 OTA 升級」的供應市場變得異常火熱。
這也演化成了一個「智能汽車」的入口搶奪戰。
汽車 OTA 升級的基本原理 | HITACHI
激增的新供應商
不管是 Tier 1 還是 Tier 2 供應商，大家都感受到了主機廠客戶對 OTA 升級方案的需求在持續增長。同時，來自移動產品終端的軟件公司也開始盯上了汽車這塊「肥肉」。在它們看來，汽車不過是「輪子上的智能手機」而已。
最後的結果就是做 OTA 的軟件公司陸續被傳統供應商收入麾下，形成了各方勢力割據的總體局面：
- 2015 年早些時候，哈曼國際收購了總部位於以色列的軟件公司 Red Bend。這是一家爲互聯汽車提供軟件管理技術、OTA 軟件和固件升級服務的公司。但之後哈曼又被三星電子吃掉了。
- 2016 年，當時還是英特爾業務部門的風河（Wind River）併購了爲汽車提供 OTA 升級解決方案的 Arynga。
- 兩週之後，風河宣佈福特將使用其 OTA 升級技術。風河方面表示「Wind River Edge Sync 技術能夠提供不同的升級方式，可最小化數據容量、傳輸時間以及內存佔用」。
- 2017 年，從德爾福集團中分拆出來的安波福（Aptiv）收購了總部位於密歇根的初創公司 Movimento，並將其 OTA 平臺集成到了自家的解決方案中。安波福表示「希望幫助車企完成數據蒐集、分析的工作，監測漏洞，提升召回效率，堵上網絡安全漏洞並加速自動駕駛技術的研發進程。」
- HERE，作爲一家圖商，發佈了 OTA Connect 的產品。HERE 方面表示這款產品是開源的，能夠高效地集成至車企的後端服務器。
其他在 OTA 平臺市場知名的供應商則有大陸集團、博世、Airbiquity 和 ATS Advanced Telematics System。
誰在解決關鍵問題？
上面這種頻繁的合作和併購動態，其實也反應了整個汽車行業對 OTA 技術的旺盛需求。既渴望擁有卻不具備特定領域的 know-how，「花小錢辦大事」是最直接的解決辦法。但問題又來了，目前絕大多數 OTA 能夠做到的還只是將軟件升級包發送至車內的 T-Box，而不能實現 ECU 層面的軟件升級，譬如對氣囊、動力總成、車身控制或安全等功能做出及時更改。
之前也提到過了，互聯汽車和智能手機有着截然不同的電子架構。要在汽車上實現真正的 OTA（從雲端到 ECU），供應商首先要在計算硬件上有很深的知識儲備，比如瞭解車內不同硬件單元的區別。因爲如果要與 ECU 進行通訊直連，你得知道它是不是有兩個內存庫。這樣在 OTA 的時候，其中一個內存庫可以寫入升級包，而另一個內存庫則可以存放舊版本的程序。
顯然這種雙內存的配置十分佔用空間。儘管升級數據可以進行壓縮，但 OTA 供應商仍需要考慮它要傳輸升級包的 ECU 是否有足夠的片上內存（on-chip memory）。
其次，OTA 供應商還應該熟悉車內的通訊網絡拓撲結構。因爲不同的 ECU 連接着從 CAN 總線、FlexRay、LIN 到 MOST、以太網等不同的通訊網絡，只有對每條線路的特點有清晰的認知才能高效地實現軟件升級。
對此，芯片供應商瑞薩認爲要實現從 OTA 的第一階段（對單一 ECU 的升級）進化到能夠對整車功能更新，包括一些安全部件的更新。需要從兩個方面入手：一是降低車內通訊網絡的複雜性；二是簡化車內 API 接口同時增加 MCU 對多個系統的集成化控制。
這其實涉及到了從傳統燃油平臺向智能電動化邁進的過程中，整車電子電氣架構隨之發生的演化：從分佈式逐步向集中式過渡。而全新車用計算平臺的引入能夠簡化車內網絡的結構，加速通訊協議的編譯過程同時增強各個子版塊的安全性。同時位於整個中樞系統的 MCU 應該足夠智能，它需要把從以太網獲得的數據提前進行壓縮，然後再傳輸給 CAN 總線。
MCU 會隨着汽車電子電氣架構的變化而逐步進化 | 瑞薩
不過目前還沒有哪個量產的 MCU 能夠勝任這樣的工作。瑞薩方面表示，R-CAR Gen 3 是它們目前用於汽車 OTA 的主流產品。但隨着汽車功能集成以及中心域控制的能力逐步增強，預計 2023 年會有適配全新電子電氣架構的產品問世。
當然，安全是 OTA 升級中最關鍵的問題所在。不像手機，升級不成功頂多是「變磚」，但汽車就不一樣了，稍有不慎就可能車損人亡。所以顯然不能很隨便地做整車 ECU 升級，這就要求車企要制定相應的升級策略，特別是定義好「合適」二字，避免出現類似蔚來車主在長安街遭遇的窘迫事件。
這裏的「合適」既包括了對時間、地點、車輛狀態等要求，同時還要對軟件的功能性進行區分，比如關鍵系統一定要保持車輛靜止且電量充足等，像音樂、視頻類似的 APP 則可以在行駛過程中升級，只要確保不影響行車安全即可。
從這個角度出發考慮的話，在對汽車進行 OTA 升級時，其實要先讓雲端服務器與目標車輛進行通訊，鎖定並同時對目標進行持續監測，確保其符合升級要求。而一旦進入升級狀態，又會涉及一個新問題：中間發生錯誤怎麼辦？
其實升級過程中出現 bug 很正常，但對汽車而言，需要制定更妥善的防錯機制保證車輛功能安全不受影響。像「斷點續傳」就是目前已知的 OTA 防錯機制中一種較常見的方案。此外還有回滾機制，因爲升級後新系統如果不穩定就需要退回到之前的版本，這也是對車輛安全的一種保護方式。
Excelfore Esync 解決方案中下發軟件升級包的過程 | Excelfore
除了這兩種主流的解決方案外，業界知名的公司 Excelfore 還提出了一個「安全內核」的概念，用來保障系統與雲端的安全連接及對軟件進行升級。而初創公司 Aurora Labs 的方案中包括了「Auto Detect」和「Auto Fix」兩項核心技術。前者在 ECU 的後臺運行，通過實時監測代碼層級的錯誤來實現對宕機事件的預測。一旦錯誤被鎖定，自動修復功能會將 ECU 軟件實時滾回至上一個安全版本。理論上說，是不會出現「宕機」的情況。
再談 OTA 的重要性
整車 OTA 應該成爲汽車產業優先解決的問題。自動駕駛汽車可能確實對降低交通事故傷亡率有幫助，但假設沒有靠譜的修補軟件漏洞的方法，到時候一旦面臨大規模召回，消費者的不滿情緒對品牌而言是最大的災難。
我們細數下近些年發生的因軟件問題而導致的汽車召回事件：
1. 2016 年，日產召回了 320 萬因氣囊系統問題無法識別乘客的車輛；
2. 2016 年，通用召回了 360 萬氣囊系統自動進入診斷模式的車輛；
3. 2017 年，道奇召回了 125 萬輛安全氣囊傳感器故障的車型；
更嚴重的是，很多消費者在知曉車企發佈的召回通知後，繼續放任軟件故障存在。根據調研機構 Stout Research 發佈的數據，購買 5 年內的車輛在召回通知發佈後的九個月內，維修率只有 40%。例如，2018 年通用宣佈因方向盤軟件故障召回 100 萬輛車型，到現在約有 60 萬臺未得到修復的車輛仍行駛在道路上。
如果車企的整車 OTA 技術能夠就位的話，對付這些 bug 就變得易如反掌。而且 OTA 升級不光能讓產品的電子系統保持最新，一旦出現因軟件故障導致的召回，可以節省大量的時間和金錢成本。
「對很多車企而言，OTA 技術上車的主要動力是出於成本節約的考慮。」行業諮詢機構 IHS Markit 首席分析師 Egil Juliussen 告訴極客公園（id：geekpark）。「網絡安全則是 OTA 必須成爲互聯汽車標配的另一個重要原因。」
而 OTA 升級對主機廠真正具有吸引力的地方在於「它能夠實現車輛重要功能的常用常新」。通過 OTA，汽車製造商通過軟件升級的方式可以在產品售出後通過增加功能的方式繼續獲得收入。這也是爲什麼 Musk 認爲未來搭載了 FSD 的特斯拉車型會變成一件「持續升值的產品」。
此外，在搭載了一套雙向通信的 OTA 平臺後，車輛能夠將車端系統和零部件的診斷及運行信息及時傳輸至雲服務器，這也有利於主機廠對某些潛在隱患進行預防性監測，做到「將風險提前扼殺在搖籃裏」。
目前特斯拉使用的是 Red Bend（目前是哈曼國際旗下的公司）提供的 OTA 平臺進行車輛和雲端的通訊。但一旦涉及到整車軟件升級的問題時，特斯拉依賴的則是其內部開發的 API 端口。
OTA 升級有利於主機廠對某些潛在隱患進行預防性監測 | HERE
標準的 API 端口能夠爲 OTA 升級帶來的優勢，對平臺供應商而言是顯而易見的。目前很多 OTA 公司只有一到兩個客戶，每家都在對接一些特殊的需求，這樣是不利於整個行業的良性增長的。所以，Excelfore 牽頭成立了 eSync 聯盟，目的是解決目前汽車 OTA 普及過程中面臨的一些問題。比如有效降低開發成本，縮短產品導入市場的週期等等。
「甚至像福特、通用這樣規模的企業都對標準化的 API 產生了興趣，因爲它能夠帶來更多成本上的競爭力。」Juliussen 如是說。「對小公司而言，這無疑是天上掉餡餅，因爲這會讓消費者的選擇變得更容易些。」