二萬五千字解讀OTA

導讀：本文共三大章節，分别為整車OTA為什麼困難重重、整車OTA需要注意些什麼、uboot介紹，字數接近二萬五千字，建議收藏閱讀。

整車OTA為什麼困難重重

01 什麼是汽車OTA

首先，我們先來看看各位吃瓜群衆對OTA的理解，搞清楚什麼是OTA？

群衆A:小寶，這個我清楚，無非就是升級打補丁嘛，形象一些，就是衣服穿的破爛了，然後再打一個好看點的補丁。

小寶：曾經，小寶上初中的時候，為了讓衣服顯得酷一些，在好的衣服上也弄一個超酷的補丁，現在也有一些車企也在這麼做，為了顯示自己能OTA，本來沒有必要的升級，非得弄的高大上，所謂讓用戶更有粘度。

群衆B：小寶，汽車OTA太吓人了，動不動就整“趴火”，這個不太安全吧。在2019年1月30日，蔚來ES8在長安街出糗的這條朋友圈截圖，火遍了圈裡圈外。

小寶回複：也許很多朋友會覺得整車OTA不安全，小寶要在這裡鄭重的強調一下，不錯，你的感覺沒有錯，目前整車OTA确實不太成熟。不過上次那個事件和OTA運營有一定的關系，這個駕駛員，确實有魄力，在長安街這種稍作停留都會引來警察的敏感位置敢于停車後挂P擋，且在不詳細閱讀提示的情況下進入ES8的整車OTA（記住整車OTA這個詞，後面很關鍵）升級，結果尴尬的被堵在車裡一個小時。

群衆C：小寶，OTA我知道，這個是好家夥，自從購買了特斯拉以後，隔三差五的升級新功能，解鎖新姿勢，感覺每天開得都是新車。

小寶：土豪，我們交一個朋友吧，OTA運營好，确實是主機廠發家緻富的一條好道路，正所謂要緻富，先修路。

特斯拉官方針對Model3長續航全輪驅動版車型推出了加速提升包服務。這套升級包售價為1.41萬元，升級後車輛百公裡加速能力可以從從4.6秒提升到4.1秒。車主隻需通過OTA升級功能，就可完成升級包的安裝升級。此套加速提升包是通過釋放Model3長續航全輪驅動版雙電機的冗餘性能。

不要小看這0.5s，如果是傳統汽車，就需要3-4年才能實現，因為要修改硬件參數，要重新設計一款新車，改變發動機相關性能參數，整個車的性能在設計之前就确定了。通過OTA升級，所以特斯拉一輛車讓你随時都感覺在開新車的驚喜，競争力大大提升。

說了這麼多，到底OTA是什麼？是補丁，是驚喜，是增加新體驗，到底是什麼呢？為什麼有的廠家宣傳的是OTA，有的宣傳的是FOTA，有的又說SOTA，這有什麼區别？

名詞解釋

OTA，Over The Air/空中下載，所謂“空中”指的是遠程無線方式，指通過移動通信（GSM或CDMA）的空中接口對 SIM 卡數據及應用進行遠程管理，OTA 技術可以理解為一種遠程無線升級技術。

我們先來看看軟件的一個架構，其實可以分為驅動層、系統層、應用層、不同的層級的内容是不同的，而且對于硬件的影響是不同的，就好比你手機上升級失敗騰訊視頻，不會影響到其他APP功能的正常使用，但是如果你升級整個手機OS軟件版本，如果升級不成功，那麼就極容易變磚頭了，此時需要拿到手機售後維修店進行強制修複。

FOTA說的更容易理解點就是對驅動的升級和對系統的升級。FOTA的升級是涉及硬件的，如果刷寫失敗，硬件就會變磚。所以，FOTA在技術上還是有一定難度的。汽車上有很多的控制器，車輛在什麼狀态下進行刷寫，如何确保刷寫過程穩定，安全，這些實現上的難點都是要考慮的。行業裡常規所說的整車升級，就是基于FOTA技術的。原則上，車上任何一個控制器都是可以升級的，但為什麼現在很多車還有做到這一點，主要是考慮到穩定性。畢竟，升級生成磚這種事情連蘋果都不敢說100%的避免，更何況一輛更為複雜的汽車産品。

SOTA，Software Over The Air/軟件空中升級，偏向于應用軟件升級。SOTA是在操作系統的基礎上對應用程序進行升級，整個過程相當于我們在電腦上對一個程序進行了升級，特别指出隻是程序的升級，WINDOWS系統更新打補丁的技術都比SOTA要難。市面上的安卓車機，如果想要對APP進行升級，隻要找幾個開發和測試就能幹完，幾乎沒有技術壁壘。也許有人問，既然實現起來很簡單，也沒有什麼技術含量，那為什麼很多車上都沒有呢。最主要的原因是，創建了一個應用市場，關鍵的點在于應用從哪來。即便是現在也是這樣，在導航車機上能使用的互聯網應用還是很少，即便是放的最開的後裝車機，也沒有超過上百個應用。

事實上 FOTA 與 SOTA 界限比較模糊，Windows 操作系統升級、手機升級、嵌入式系統、單片機控制程序等都的遠程升級可以籠統地稱為 FOTA；轉移到汽車電子這塊，為了方便讨論，我們将 HU 中的 APP 更新稱為 SOTA，将其他 ECU 的更新甚至于所有更新統稱為 OTA。

群衆C：小寶，你這個解釋完，我還是沒有看懂怎麼辦？

小寶：逼着我出大招了，那我用通俗易懂的方式再解釋一遍。

類似于裝修，FOTA是對驅動和系統升級，這個驅動底層就是你好比你家的塗牆的油漆，布置的走線，地磚的選擇、裝修的風格，這些都是屬于底層驅動。

你家的沙發、餐桌這些都要和家裡的這些進行搭配恰當，這個就相當于APP應用軟件。如果哪天你覺得不喜歡這個沙發的樣式了，想換一個沙發就行了，這個更換就比較容易，所以SOTA升級是比較簡單的，更換一個沙發，如果沙發沒有買來的情況下是不允許餐桌的正常使用的。

要是不喜歡這個地磚了，那就比較麻煩，需要把這些拆了重新來，此時你家餐桌、沙發都需要搬離出去，不用使用，隻有等地磚翻新完後再搬進來使用，所以FOTA是比較困難的，而且如果你裝修期間遇到事情，停下來不裝修地磚了，此時整個家裡是沒有辦法使用的，所以FOTA升級失敗的話，整個器件相關的APP是不能使用的，風險度會比較高。

02 OEM為什麼熱衷于研究OTA

1、OTA能夠給車企帶來的好處

對很多車企而言，OTA 技術上車的主要動力是出于成本節約的考慮。網絡安全則是 OTA 必須成為互聯汽車标配的另一個重要原因。

而 OTA 升級對主機廠真正具有吸引力的地方在于它能夠實現車輛重要功能的常用常新。通過 OTA，汽車制造商通過軟件升級的方式可以在産品售出後通過增加功能的方式繼續獲得收入。這也是為什麼 Musk 認為未來搭載了 FSD 的特斯拉車型會變成一件持續升值的産品。

此外，在搭載了一套雙向通信的 OTA 平台後，車輛能夠将車端系統和零部件的診斷及運行信息及時傳輸至雲服務器，這也有利于主機廠對某些潛在隐患進行預防性監測，做到将風險提前扼殺在搖籃裡。

快速修複系統缺陷

傳統汽車在用戶行駛驗證中出現了系統方面的缺陷，而這些問題的解決辦法隻有一個，汽車廠家啟動召回程序，在用戶收到召回程序後返廠進行系統的統一升級。而OTA技術則可以通過遠程快速的通過數據包的形式完成缺陷的修複，大大避免了持續數月的進廠召回帶來的風險。

快速叠代、提升産品和使用體驗

由于在産品設計中的硬件的超前配備，智聯網汽車操作系統可以通過一次次OTA升級，不斷給車主逐步開啟新功能，優化産品體驗，進行快速叠代，提供更加優質的系統服務。真正讓車主感受到什麼是“常開常新”。

進行界面優化更新，提升人機交互體驗。汽車連接互聯網，改變了過去銷售是研發過程結束的汽車銷售模式，使銷售成為廠商與客戶互動的開始，因此會帶來投訴率高的風險。而是用界面和内容的更新可以從一定程度上降低投訴率。

節約雙方的時間和金錢

傳統的召回是需要走内部及外部審批的過程，時間和金錢的成本都非常高。通過OTA升級的形式，可以大大降低由于軟件缺陷帶來的召回成本，把這個錢省下來給大家研發新産品不好麼？

2、軟件定義汽車已經形成共識，軟件風險也是趨勢

大衆汽車之前宣布，組建自己的軟件部門：數字汽車與服務部（Digital Car&Service），大衆CEO迪思在今年的達沃斯世界經濟論壇上表示：“在不遠的将來，汽車将成為一個軟件産品，大衆也将會成為一家軟件驅動公司”。在汽車行業向出行服務和智能化轉型的大趨勢下，新的智能功能和服務需求幾乎每個月都需要更新，大衆的組織變革表明軟件定義汽車已經成為業界共識。

計算集中化：服務導向的系統構架（SOA）将成為主流，為軟件提供高性能實時計算平台，在這樣一個大的理念下，計算集中化将催生真正的汽車大腦：超級中央計算機。目前各個玩家對這個概念的叫法五花八門，包括車載計算平台、主機（Host）以及服務器（Server）等，但本質都一樣。

為了滿足ASIL-D功能安全的要求，一台汽車通常需要有兩台相同的主機互為備份，目前領先的Tier1如安波福、大陸等都使用這樣的理念。

伴随着計算集中化，産生了一個新的概念：區控制(zone control)，與目前流行的域控制器概念不同的是，區控制模塊沒有高級功能決策權，而是完成執行器、傳感器、診斷以及傳統I/O的連接彙總，類似于PC中的南北橋。

在這樣的構架下，決策通常都是由中央計算機來發出，但是也有例外，比如AEB緊急制動的功能，是最重要的ADAS功能，一旦前向智能傳感器發現前方有障礙而且即将發生碰撞，可以不經中央計算機決策指令，直接啟動執行機構進行刹車，或者在兩台中央計算機都出現故障的時候接管刹車執行器，從而提供更高的安全冗餘。

如果我們對照人的決策機制，會發現有高度類似的情況：假如我們在野外突然碰到一頭老虎，身體的第一反應是僵住不動，這個決策并不是來自大腦的高級理性系統（即皮質），而是來自非常原始的大腦邊緣系統（哺乳動物都有），它在緊急情況下會切斷大腦對軀幹的控制，自動接管以保證能夠在瞬間完成必須的生存反應。手碰到燙的東西立馬縮回去也是一樣的決策機制，這樣的例子不勝枚舉。

在未來，OEM交付的汽車将不是一個功能固化的産品，而是一個持續進化的機器人，在汽車整個生命周期内，硬件平台需要持續支持軟件叠代升級，這意味着，我們必須打造一個開放的、工具鍊完善的、擁有強大算力保障的計算平台，提供高達1000TOPS的算力，為各種軟件功能提供充足的算力儲備。

軟件定義汽車的其核心思想是：決定未來汽車的是以人工智能為核心的軟件技術，而不再是汽車的馬力大小、是否真皮座椅、機械性能好壞。

高端汽車控制器節點 80~100，整車代碼量已經突破 1 億行。而汽車行業80%~90% 的創新基于電子，離不開軟件的支撐，還在不斷發展。

不斷攀升的代碼量即使按照 CMMI（capability maturity Model integration，能力成熟度集成模型）5 級的最高軟件标準進行控制，代碼缺陷率仍為 0.32‰，潛在問題的規模不容小觑；OTA 可有效解決軟件故障， 通過應急響應降低開發周期短帶來的軟件風險問題，以及完成對信息安全漏洞的修複。

3、汽車由于軟件質量導緻的召回成本巨大

汽車廠家召回一輛車，需要車主把車開到4S店，有的需要下發優盤進行升級，而且需要人工去操作，整體費用算上一輛車的召回費用基本上是500-800元，如果是重要器件，費用會更貴，（比如什麼機油漏油處理，需要把整個發動機擡起來，整個汽車拆卸的費用會更貴），召回100W車的費用就是5-8億RMB，如果僅僅是通過軟件升級的話，這筆錢是非常可觀的。

整車 OTA 應該成為汽車産業優先解決的問題，自動駕駛汽車可能确實對降低交通事故傷亡率有幫助，但如果沒有靠譜的修補軟件漏洞的方法，一旦面臨大規模召回，消費者的不滿情緒對品牌而言是最大的災難。

我們細數下近些年發生的因軟件問題而導緻的汽車召回事件：

1. 2016 年，日産召回320 萬因氣囊系統問題無法識别乘客的車輛；

2. 2016 年，通用召回360 萬氣囊系統自動進入診斷模式的車輛；

3. 2017 年，道奇召回125 萬輛安全氣囊傳感器故障的車型；

更嚴重的是，很多消費者在知曉車企發布的召回通知後，繼續放任軟件故障存在。根據調研機構 Stout Research 發布的數據，購買 5 年内的車輛在召回通知發布後的九個月内，維修率隻有 40%。例如，2018 年通用宣布因方向盤軟件故障召回 100 萬輛車型，到現在約有 60 萬台未得到修複的車輛仍行駛在道路上。

如果車企的整車 OTA 技術能夠就位的話，對付這些 bug 就變得易如反掌了。而且 OTA 升級不光能讓産品的電子系統保持最新，一旦出現因軟件故障導緻的召回，可以節省大量的時間和金錢成本。

03 整車OTA升級為什麼困難重重

1、汽車電子的架構介紹

ECU(Electronic Control Unit) 是電子控制單元， 也稱“行車電腦”是汽車專用微機控制器。一般ECU由CPU、存儲器(ROM、RAM)輸入/輸出接口(I/O)、模數轉換器(A/D)以及整形、驅動等大規模集成電路組成。

最開始ECU是用于控制發動機工作， 後來随着車輛的電子化發展，ECU逐漸占領了整個汽車， 從防抱死制動系統、4輪驅動系統、電控自動變速器、主動懸架系統、安全氣囊系統，到現在逐漸延伸到了車身各類安全、網絡、娛樂、傳感控制系統等。

随着車子電子化程度越來越高，尤其是自動駕駛、主動安全等功能的增加，車子的ECU會急速增加。汽車EE架構中存在着數十到上百數量的功能ECU，這些功能ECU由不同的供應商提供，不存在統一的中央代碼倉庫，其中運行着各種不同的操作系統及應用軟件，以至于整車代碼行數規模達到上億級。過去分散的功能架構使得汽車不像現代手機一樣有中央大腦處理器集中處理軟件邏輯。在分散的EE架構中做整車OTA，就好比把30個人的腳綁在一起大家同時往前邁一步一樣，這個協調難度比起隻有2~3個人做這件事情困難很多。

傳統軟件應用開發，功能代碼耦合，程序整體打包，修改部分邏輯，需整體重新編譯跨控制器功能分散，所有相關控制器都需要更新軟件。如果我要更新一個ABS，那關聯的BCM、儀表、網關都要改，而且都分屬于不同的供應商，代碼也是别人寫的。從這一點也應證傳統車企被供應商綁架了。這個屬于牽一發而動全身，比較麻煩。

2、傳統整車廠還不具備OTA升級相關的條件

為什麼這麼說呢，目前夠實現整車 OTA 功能的新能源車型共有 7 款，分别是蔚來 ES6/ES8、特斯拉 MODEL S/X/3、理想 ONE、小鵬 G3。

可以看到這些車型無一例外都是新能源車，他們的E/E架構與傳統車的電氣架構有着很大的區别，基本上核心的域控制的軟件是在自己手裡，才能實現整車的OTA，否則隻能實現部分ECU的OTA功能。

這裡舉一個小例子，傳統車廠如果實現了OTA升級皮膚主題收取費用，這部分錢在傳統車廠找不到收費的部門，軟件部門是負責升級軟件的，沒有收費的權限，以前都是通過4S店收取費用，現在直接OTA後沒有運營部門，收費都不知道誰去收取。這就需要傳統整車廠不僅僅是技術方面的改變，對于部門架構也要做對應的調整和改變。軟件升級絕非想象的那麼簡單，在升級任務執行的過程中，會遇到各種各樣的問題，需要運營部門、服務部門、營銷部門甚至是當地的4S店參與。

前面提到了ECU複雜，整車通訊網絡也複雜，而且整車OTA升級慢，其實OTA涉及到很多部門，而且涉及到的事情非常多，舉例一個版本管理需要考慮和設計注意事項：

1、不同車型的系統适配2、不同品牌的系統适配3、同車型不同配置的系統适配4、同車型不同系統版本的适配5、不同車型不同配置不同品牌不同系統版本的适配

如果把這些問題穿插起來，你會發現跨品牌、跨車型、跨版本的OTA系統升級，将是一件工作量巨大的系統工程。甚至也超乎我們的想象。

OTA設計主要從安全、時間、版本管理、異常處理等方面綜合考慮，具體為：

升級安全是OTA的最基礎的要求。車輛上ECU的軟件運行狀況直接會影響到車輛上的人員的生命安全。從升級包制作，發布，下載，分發，刷寫等環節，OTA需要從雲，網絡，車端來保證安全。在雲端通過證書，簽名和加密機制保證升級包的不會随意被制作和發布，升級包内容不會被惡意獲取。通過可靠的物理鍊路和安全傳輸協議來保證網絡傳輸安全。通過汽車的功能域隔離，劃分不同ASIL等級，通過冗餘設計保證整車的功能可靠性，通過安全啟動來保證可信的軟件在ECU上加載啟動運行。

版本管控對于OTA來說很重要，因為車輛上ECU衆多，不同ECU有不同版本的軟件，不同車型ECU的需求有不同，版本也存在差異。版本的升級路徑管理，需要能夠全面準确進行管控。

整車升級進行車載ECU刷寫時，特别涉及動力域傳統ECU的刷寫，是通過CAN網絡進行安裝包的分發。由于CAN傳輸速率很低（實際典型的速率為500Kb/s），并且CAN總線負載率通常要控制在30%以内，因此在帶寬允許的情況下，盡可能采取并行刷寫模式，選取刷寫時間最長的節點優先處理等設計原則減少OTA升級時長。

防變磚等異常處理。在OTA傳輸過程中，外界幹擾或者其他因素導緻刷寫異常或者中斷，車載ECU必須支持軟件回滾、斷點續傳、丢失重傳等處理機制。

3、目前電子架構下，整車OTA時間非常長

人們都是利用自己熟悉的事物去思考和理解新事物的，講到升級大部分人對升級的理解是手機上APP的升級，手機系統的升級，windows系統的更新等這些熟悉的事物，覺得升級是一件相對比較容易的事情。汽車軟件升級要比手機和電腦升級所消耗的時間長，主要的原因是：

汽車内部各控制器的刷寫需要時間。汽車内部各個控制器是有安全防護的，不是誰給我發刷寫指令我就認的，首先要通過控制器的安全認證，然後将文件傳輸給控制器，控制器再重啟完成刷寫。如果中間出了錯誤，刷寫不成功，還需要重試。這個過程類似于我們給電腦的硬件升級驅動程序，整個過程需要較長的時間。如果是遇到那種運算能力和存儲空間小的控制器，需要将數據按照一定的格式慢慢的寫進控制器裡去。那消耗的時間就更多的。

汽車内部通訊網絡的傳輸速度較慢。手機和電腦内部的數據傳輸是非常快的，為了保證數據傳輸的速度，内部總線的條數和傳輸頻率都是很高的。汽車則大不相同，汽車内現在主流的還是采取CAN網絡，理論上高速CAN的傳輸速率是1M/s,低速CAN的傳輸速率是125K/S，這些都是理論上，實際的傳輸速度要遠低于這個速度，如果我們将一個100M的文件從一個零件傳輸到另外一個零件，消耗的時間本身就比較長。可能有人會問，為啥汽車裡不能用網線呢。現在是有的，但關鍵就是成本啊。

基于以上兩點，整車軟件OTA的耗時會是小時來計算，升級的控制器越多，升級的時間也就越長。所以，各位車主如果想要給自己的愛車進行軟件升級，最好是選擇一個網絡條件好，停車方便的地方，同時還得關注一下，自己的電瓶電量是不是夠。另外，升級過程中車輛的一些設備是不能夠使用的，也有可能會出現屏幕或者是儀表的突然黑屏或者是閃動等現象，不用擔心，現在汽車軟件遠程升級技術已經非常成熟，所有的升級過程都是經過了非常嚴格的測試才準予上線的，有點小異常，隻要等待的時間不是太長，完全可以忽略。

4、整車OTA對于硬件底層的架構知識要求非常清晰

很多人之前把未來的汽車暢想成「一台手機加四個輪子」，所以也理所當然地認為整車 OTA 應該和我們升級手中的 iPhone 一樣簡單。但其實從架構的角度來看，智能手機基本隻配備了一台處理器來運行各種 APP，但汽車内部 ECU 的數量至少有上百個，它們連接在不同的車内通訊網絡上，同時每條網絡又有着不同的數據傳輸協議。

目前絕大多數 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 總線。

汽車OTA從經銷商推廣有難度，這點我們不難看出，以前我們車要升級都要去經銷商升級，升級同時會幫你檢測車輛然後推廣一些用品和服務，一旦OTA全面實行難免會使客戶與經銷商的接觸少了很多，這是一個面包與愛情的故事，所以是不可避免的

由于上述OTA升級要求非常高、目前傳統車廠的電氣架構又不能滿足車廠OTA、而且整車電氣架構非常複雜，各個零部件的耦合度高、傳統車廠又對于ter1非常依賴，自己開發軟件能力非常弱，升級某個零部件就會涉及到關聯件的升級，而且整車上基本上沒有自己的服務器，需要ter1去搭建雲平台，而且會涉及到遠程升級安全問題，升級策略、綜合因素造就了整車OTA升級困難重重。

04 汽車OTA典型架構簡單介紹

上圖展示車輛内從主機廠服務器更新程序到指定 ECU 的過程中的主要部件。首先通過蜂窩網絡建立車輛與服務器之間的安全連接，确保全新的，待更新的固件安全地傳輸到車輛的 TelemaTIcs Unit，然後再傳輸給 OTA Manager。OTA Manager 管理車輛所有 ECU 的更新過程。它控制着将固件更新分發到 ECU，并告知 ECU 何時執行更新 - 在多個 ECUs 需要同時更新的情況下尤為重要 - 例如推送一項新功能，而該新功能涉及多個 ECUs。更新過程完成後，OTA Manager 将向服務器發送确認。

針對 OTA Manager 它可能需要外挂 NAND flash 用來存儲固件包，同樣也可以用來存儲其他車輛 ECUs 的備份，以期在 ECU 升級失敗之後進行調用。這些備份應該通過加密&認證的方式進行防護避免外部攻擊。

OTA Manager 内部有一個表格，包含各個車輛 ECU 的相關信息，譬如 SN 号以及當前的固件版本。這樣便于 OTA Manager 核實接收到的固件升級包并确保是通過授權的。如果是正在更新的 ECU 不具備加密能力那麼 OTA Manager 同樣需要負責更新過程的解碼及驗簽。

從上圖不難看出 OTA Manager 的重要性，也正是基于此，并結合網關的安全性、隔離性以及天然的多連接屬性，部分主機廠啟動自研網關（集成 OTA Manager 角色），譬如蔚來、FF。

汽車OTA升級過程中有哪些技術問題需要注意？

綜合看來汽車上實現OTA在線升級軟硬件，主要考量的還是安全問題，包括Telematics以及通信技術都已成熟并且在電腦、手機這些設備上都經過實踐的驗證，把這種技術轉移到汽車上就需要考慮更多環境、汽車工況等安全因素。歸納起來主要包括以下兩個方面：

信息安全：主要是通信加密、軟件包驗簽、更新隔離以及安全芯片等；

功能安全：主要包括OTAManager的啟動條件判斷（車輛狀态等）、ECU升級的預編程條件判斷、整車模式配合以及升級方案考量（A/B法等）；對于汽車OTA，我們不能很随便地做整車ECU升級，而必須要在一個合适的時間、合适的地點以及車輛合适的狀态下進行升級。

這就要求車企制定相應的升級策略，特别是對“合适”二字進行定義，以盡可能安全、經濟的方式來開展這項操作，而不是像手機一樣在任何時間、任何地點實施升級。

當然，安全是 OTA 升級中最關鍵的問題所在。不像手機，升級不成功頂多是「變磚」，但汽車就不一樣了，稍有不慎就可能車損人亡。所以顯然不能很随便地做整車 ECU 升級，這就要求車企要制定相應的升級策略，特别是定義好「合适」二字，避免出現類似蔚來車主在長安街遭遇的窘迫事件。

這裡的「合适」既包括了對時間、地點、車輛狀态等要求，同時還要對軟件的功能性進行區分，比如關鍵系統一定要保持車輛靜止且電量充足等，像音樂、視頻類似的 APP 則可以在行駛過程中升級，隻要确保不影響行車安全即可。

從這個角度出發考慮的話，在對汽車進行 OTA 升級時，其實要先讓雲端服務器與目标車輛進行通訊，鎖定并同時對目标進行持續監測，确保其符合升級要求。而一旦進入升級狀态，又會涉及一個新問題：中間發生錯誤怎麼辦？

其實升級過程中出現 bug 很正常，但對汽車而言，需要制定更妥善的防錯機制保證車輛功能安全不受影響。像「斷點續傳」就是目前已知的 OTA 防錯機制中一種較常見的方案。此外還有回滾機制，因為升級後新系統如果不穩定就需要退回到之前的版本，這也是對車輛安全的一種保護方式。

OTA場景策略與規則

從OEM車聯網運營角度劃分，根據車輛銷售前和銷售後不同，OTA升級場景一般會區分為靜默升級和非靜默升級。靜默升級主要用于銷售前處于庫存狀态的車輛升級。OTA雲平台通過發送遠程喚醒命令，通過TBOX喚醒車輛上電，連接到平台進行升級任務的處理。

非靜默升級主要是用于是銷售後車輛歸屬于車主後的升級場景，軟件升級變更需告知給車主，在車主知情和同意的下進行升級。非靜默升級其中又分為普通升級和緊急升級，緊急升級一般是用于特别重要安全補丁的推送升級，車主知情但是無法拒絕。

OTA升級任務下發到車輛後，升級管理程序OTA Manager也必須判斷車輛條件是否符合。對于不符合條件的車輛，升級管理程序必須中止升級任務并上報給雲平台。在OTA架構中，升級規則定義了各個車型在升級包下載，安裝刷寫階段的判斷條件。升級規則會随着雲平台上的升級任務下發到車輛。例如最低版本要求，車輛運行狀态、車輛位置。

某電動車廠商的車輛在長安街街心升級導緻交通堵塞的新聞曾在互聯網上議論紛紛，如果在升級執行前能否判斷車輛處于一個不适合升級的地點，那麼升級任務也不會推送給停車等候紅綠燈的車主了。一個好的OTA系統一定是能夠靈活的配置升級條件，并且合理準确控制升級和用戶推送的系統。

最後，結合OEM運營的要求，OTA升級還需要能夠靈活定義升級的具體範圍，升級時機，升級内容，提示事項，失敗後給用戶的失敗處理提示，提升大規模升級中的運營效率和運營體驗，持續為車主和OEM提供價值。

整車OTA需要注意些什麼

上期我們聊了由于OTA升級要求非常高、目前傳統車廠的電氣架構又不能滿足車廠OTA、而且整車電氣架構非常複雜，各個零部件的耦合度高、傳統車廠又對于ter1非常依賴，自己開發軟件能力非常弱，升級某個零部件就會涉及到關聯件的升級，而且整車上基本上沒有自己的服務器，需要ter1去搭建雲平台，而且會涉及到遠程升級安全問題，升級策略、綜合因素造就了整車OTA升級困難重重。

這期重點來講講OTA中需要注意的問題點，整個升級流程中需要注意的地方。本文有借鑒參考艾比拉李總的演講和PPT内容，一家專注于OTA升級的公司，非常的牛。

01 OTA方案架構

汽車OTA系統是一個雲管端的系統方案。雲端主要負責升級策略、升級任務、軟件版本、數據分析等升級管理工作。車端主要負責軟件包下載，軟件包刷寫，差分還原、安全及完整性校驗等單車軟件升級工作。車端與雲端的連接方式也有很多種，如WiFi、蜂窩網絡、近場通訊（藍牙、LoRa、ZigBee等），無論哪種連接方式，都是讓雲端與車端建立連接，讓軟件包和車輛刷寫策略能夠下發到車端執行，完成汽車軟件升級的最終目标。

OTA雲平台，主要包括了OTA雲端的升級模型管理，升級包管理，升級任務，升級策略以及日志管理的功能。OTA雲端的設計要求是物理上實現租戶隔離的雲平台，能夠支持多種協議下升級接入，支持多車型、多品牌、多種類型ECU軟件版本管理，升級包制作，升級模型定義和升級策略和規則配置。能夠支持批量升級任務的調度和分發。能夠提供适配層與TSP平台和OEM的IT系統進行集成。性能上能否實現100萬以上車輛升級并發，差分效率能夠不小于90%，可靠性能否實現3個9的要求和7*24小時的系統連續服務。

車端架構按功能域劃分，分為動力系統域、車身系統域、影音娛樂域、ADAS主動安全域、自動駕駛域，不同的功能域有着不同的通信網絡和功能安全等級設計。。自動駕駛域或者影音娛樂域等部分ECU存在主備分區的設計，即ECU内部用于兩片區域，一部分用于存儲當前運行的程序，一部分用于存儲備份程序。除第一次安裝或者設備下線時，ECU内部隻有一份軟件外，之後更新安裝的軟件都會與上一份共存。當前運行的是最新的軟件，如果升級過程中發生錯誤或者刷寫的程序不能運行，ECU根據OTA Manager的升級策略要求，能否自動回滾至上一個版本的程序，防止車輛ECU變磚。

升級任務是OTA平台用于執行和監控一組設備的升級活動的集合。升級任務可針對特定範圍的設備，使用相應的升級包和升級策略，進行升級任務創建，下發，監控，狀态維護等整組活動的管理。升級任務的監控功能，提供了對一組升級活動中，升級任務狀态，進度和結果的反饋。按照升級任務狀态的狀态，主要包含了成功，失敗，升級中等設備的數量和各個狀态下的比例。升級任務的控制功能，提供了對一組升級活動中，升級任務的啟動，停止，暫停，恢複，重啟，撤銷等操作能力，實際上是維護了任務狀态機的狀态變遷幹預能力。

升級日志包括雲平台的日志，車端與雲平台通信産生的日志和車端升級程序搜集上來的日志。主要用于升級失敗後的分析和支撐升級運維運營管理。

OTA車端主要包含通信終端和各功能域的ECU。OTA通信終端一般由TBOX負責，上面運行OTA升級管理程序和升級代理程序。其中，OTA升級管理程序OTA Manager是負責連接車輛與OTA雲平台的管理程序。它實現了端雲的安全通信，包括協議通信鍊接管理，升級指令接收和升級狀态發送，升級包下載、升級包解密、差分包重構等功能。升級代理Update Agent，是為了兼容不同的車内通信網絡和通信協議，以及不同OEM間各品牌車型的接口差異，進行封裝适配的部分。升級代理提供了統一接口，由OTA廠商負責實現接口，完成接口和業務邏輯的适配。

02 OTA升級流程簡單介紹

汽車軟件升級一般從ECU的軟件新版本産生開始，到車端升級結果反饋回雲端結束。升級過程涉及雲端（由OEM來掌控）和車端（由用戶來掌控），雙方的交界點就在于升級任務的發布，用戶開始接受到升級通知。大緻的流程描述如下：

• 軟件新版本：OEM自身或供應商研發了某個電子元器件（ECU）的軟件新版本，經過測試後，将軟件包上傳到OTA的雲端系統。

• 升級包生成：OTA雲端會依據上傳的軟件包和零部件當前的軟件版本情況，自動或手動生成軟件升級包。其中包含對體量較大升級包的差分等相關功能。

• 升級包測試：為了确保升級過程中不出現問題，所有的升級包都必須經過測試，經過測試後的升級包才會被下發給真實的用戶。好的OTA系統還會有測試車輛的管理能力。

• 升級策略：不同的車型的不同控制器升級，在升級過程、升級條件及安全上都有不同的要求，雲端要能夠将這些升級所需的操作制作成升級策略。升級策略測試通過後，再跟軟件包一起下發到車端。升級策略制定的靈活性，決定了OTA系統的優劣。

• 升級任務：升級策略約定的是一輛車的升級過程，升級任務則是約定一批車輛的升級過程。升級任務一般都會約定哪些車的哪些零部件要升級，升級前要給用戶發什麼樣的通知，向用戶提示哪些内容等。升級任務在内部還需要有必要的審核機制。升級任務發布後，車輛就可以接受到相應的升級通知。

• 獲取通知：OEM在雲端發布升級任務後，在升級範圍内的車輛就會獲取到升級通知，通知内容一般情況下是雲端約定好的内容，包含升級範圍、升級耗時等内容。

• 用戶授權：車輛銷售給用戶後，其搭載的程序和存儲空間都是用戶的私人财産，OEM想要在車輛上做軟件改動必須要經過用戶授權。用戶授權後才能夠下載軟件包，并執行相應的升級操作。

• 升級包下載：車端從雲端獲取本次升級所需的軟件包和相應的升級執行腳本。在車端進行安全性和完整性校驗，确保安全後才能夠執行升級。

• 升級包安裝：升級包的安裝就是汽車軟件升級的具體過程。不同的零部件有不同的升級方式，這個過程類似我們在電腦上對某個軟件進行升級，但實際上區别較大。

• 升級結果反饋：車端在升級過程執行完成後，無論成功還是失敗，都需要向雲端報告相關的情況，車端數據的回傳是做好管理的基礎。

03 汽車OTA升級重點的幾個地方

1、升級包的生成考驗OTA廠家的算法功力

軟件包是用于升級使用的程序或配置。軟件包包含有設備軟件修複的缺陷或者要加入的新功能，更新前和更新後需要做哪些驗證檢查邏輯等，都會被打包到這個文件裡。軟件包一般都是由設備軟件供應商提供的，會通過特定渠道，發布給OTA服務方。在整車升級中，OTA 分為兩類，一種是 FOTA固件在線升級），指的是給一個零部件的ECU閃存下載完整的固件鏡像，或者修補現有固件、更新閃存。而固件之外的軟件更新，就是 SOTA（軟件在線升級）。例如，車機屏應用程序和車載地圖的升級，都屬于 SOTA 的範疇。這兩種文件形态，都屬于軟件包管理的範疇，通過軟件包分類進行區分。軟件包管理允許軟件包能夠基于軟件包版本進行分版本的存儲和管理，并維護軟件類型，全量與差分等屬性。

升級包是在升級任務中，用于真正下載和安裝部署的文件。升級包可以是設備軟件供應商發布的軟件包文件，也可以是經過OTA平台完成了打包處理的文件。常見的升級包制作處理包括文件壓縮合并，生成特定的文件描述信息，文件簽名和加密處理。許多物聯網設備和車輛設備的閃存都比較小，升級包需要要能在嵌入式設備的小内存中完成安裝。因此，升級包會盡可能地壓縮大小。為了保證效率和成功率，OTA平台在升級包制作中提供了差分生成的離線和在線工具。升級差分包之前，通過比較新舊版本之間的差異，生成差異文件。差分更新的核心技術是各家OTA供應商掌握的字節差分算法。

2、升級策略至關重要

升級策略是升級活動中的用于描述任務特征和目标設備升級行為的配置。升級主要會涉及到下載和安裝兩個階段，升級策略中，一般會包含升級包下載策略和升級包安裝的策略，以及異常情況下的處理策略。例如，在整車升級中，升級策略包括靜默升級，常規升級和緊急升級的分類，也包括了升級包下載前，是否需要通知給用戶下載确認的配置。

OTA升級場景一般會區分為靜默升級和非靜默升級。靜默升級主要用于銷售前處于庫存狀态的車輛升級。OTA雲平台通過發送遠程喚醒命令，通過TBOX喚醒車輛上電，連接到平台進行升級任務的處理。

非靜默升級主要是用于是銷售後車輛歸屬于車主後的升級場景，軟件升級變更需告知給車主，在車主知情和同意的下進行升級。非靜默升級其中又分為普通升級和緊急升級，緊急升級一般是用于特别重要安全補丁的推送升級，比如某些發動機的軟件故障等等，車主知情但是無法拒絕。

某電動車廠商的車輛在長安街街心升級導緻交通堵塞的新聞曾在互聯網上議論紛紛，如果在升級執行前能否判斷車輛處于一個不适合升級的地點，那麼升級任務也不會推送給停車等候紅綠燈的車主了。一個好的OTA系統一定是能夠靈活的配置升級條件，并且合理準确控制升級和用戶推送的系統。

手機升級扔在一邊等手機自動升級，反正升級時間也快，尤其汽車是一個大件物品，很多老司機在升級的時候生怕有什麼問題，就會熄火坐在車裡等整車OTA，目前的升級速度又慢，一做就是1個小時，而且涉及到娛樂系統&空調系統升級的時候，大夏天30多℃，汗流浃背的焦急等待1個小時，确實不會是一個好的體驗，哪怕你告訴升級後汽車能飛，我都不想升級。

其實此時可以通過手機授權，在車停在地上停車場後，通過手機聯網授權，預約OTA升級，在空調房裡面吹着冷風，吃着西瓜，升級成功後把信息反饋到手機給你提示，下班後就是一輛升級完後的新車了，這樣的體驗是不是超級perfect。

在整車升級中，因為涉及到車型與ECU的配套關系，因此升級模型一般能夠體現一個車型下各個零部件ECU的依賴關系，例如多個零部件ECU直接軟件包配套關系和升級順序控制，對于升級任務在設備側的準确完整執行非常重要。此外，升級模型還包含了升級規則的定義。升級規則可以用于描述升級流程中，用于允許升級能否繼續進行的判定條件。在整車升級中，一般包括了一款車型在升級下載前，下載中，安裝前，和安裝中的判定規則配置。

3、OTA的運營管理是OTA能否展開工作

現在OTA系統的兩大核心目的是修複車輛上的軟件問題，給車輛新增更好的功能。針對OTA發揮價值的這兩個點上，運營的目标是怎樣的呢？

（1）針對問題修複類的軟件升級運營。運營目标很明顯，那就是在最短的時間内修複所有有問題的車輛，讓可能會發生的質量問題或者是投訴都被扼殺在搖籃裡。這就要求OTA系統在升級效率上要有所保障。現在很多人說OTA系統運營難，其實大部分指的是想要快速的讓新版本取代舊版本是一件非常難的事情。升級任務的執行總是會給你一開始的驚喜，然後是焦灼的期待和漫長的等待，最後是手足無措的放棄。

（2）針對新增軟件功能類的軟件升級運營。我們就是奔着把軟件功能成功賣給用戶賺錢這個目标去的。之前聽說過一句話，講的很有意思，世界上最難的事情有兩種，一種是把别人口袋裡的錢拿到自己口袋裡，另一種是把自己的思想放到别人的腦子裡去。想要在車上軟件掙錢，行的通，但很多OEM還沒有這方面成功的商業模式。且不說商業模式，後面我們會說，想要賣功能掙錢，首先得有東西賣才行。

行業裡大家都在拿着特斯拉、小鵬、蔚來等企業來說OTA，每每說到的時候都會說，你看人家有更新了什麼功能，所以他們的OTA技術一定很牛。這裡我想澄清一下，OTA是軟件更新的通道，主機廠通過這個通道升級什麼并不是通道來決定的。所以，看到特斯拉更新了新功能，例如賽道模式，就下結論說特斯拉的OTA技術做的好，這兩者之間是沒有什麼本質聯系的。隻能說，新銳電動車廠商在軟件功能定義上做的好，運營做的好，而不是他們的OTA技術多牛。所以，對于想急切進步的傳統OEM，OTA運營才是關鍵所在，隻有經曆過項目打磨，做過深度思考的供應商，在運營上才會有真知灼見。“技術+服務+運營”才是OTA系統的全部。

汽車軟件遠程升級絕對不是在系統上下發一個升級任務，然後新版軟件機會乖乖的跑到用戶車上的過程。車輛已經銷售給客戶，我們在用戶車輛上下載文件、安裝程序必須要經過用戶同意。因為車輛的所有者是用戶，而不是OEM。所以，在升級的過程中，我們必須獲取用戶的授權，否則我們升級就如同電腦中的流氓軟件，自己下載自己安裝，還會彈消息。

在以往的軟件升級運營活動中，遇到的最大的問題不是升級刷寫速度的問題，不是網絡不暢通的問題，而是如何獲取用戶授權，用戶不授權升級任務就隻能等待，這個等待的時間可能會比車輛升級過程的真正耗時要長很多倍。升級任務下發後，如果時間設置的好，通知設計的巧妙，一開始會有很多用戶配合進行升級，但一段時間後，升級用戶的數量會逐漸減少，甚至是停滞。究其原因，是用戶對升級這件事情的不理解。

車輛用戶會想，我的車現在挺好的，為什麼要升級？升級會不會給自己的車輛帶來新的問題？升級後會不會像蘋果手機一樣，老機型會卡頓和變慢啊？還有的用戶會開始懷疑OEM升級的動機，沒有問題為什麼樣升級呢？這車肯定是哪出問題了，要是遇到幾個較真的用戶，解釋起來都是一件讓售後服務頭疼的事情。

其實，提出問題的用戶我們一般都不擔心，至少他們關注到了車輛的軟件版本更新，最怕的是那種什麼反饋都沒有，反正就是不升級的用戶，想要調用他們的積極性，那可是十分困難的事情。

用戶不是OEM的木偶，發一個指令就會讓用戶有相應的動作。對于運營人員而言，可以說無所不用，甚至用其極啊。個人總結出來的經驗是，打着車輛安全旗号的軟件更新往往會執行的比較快，但同樣的方法用的多了，用戶也不會信你了。他們會甩給你一個表情包：我信你個鬼！

從本質上來說，需要用戶配合的升級運營活動，要從用戶意願，時間和操作說明幾個點上去思考。任何一個升級活動在開始宣傳的時候就要思考清楚，如果我作為車主，我為什麼要對車輛進行升級，如果不升級對我有什麼壞處？我們應該怎樣發通知，怎樣描述軟件的變化才會讓用戶更容易接受。

做的再精細點，不同的用戶群體也需要有不同的運營策略。依托用戶的用車時間和用車習慣，以及用戶的活躍度等信息，給一個固定的群體制定細分的升級方案，是升級效率提升的有效手段。隻不過，OEM要有人來負責這個事情，如果我們把這個事情交給OTA系統建設的信息部或者是技術部門，那效果可想而知。

OTA的運營是需要專業人才的，這些人要懂車，懂車主，懂互聯網運營，同時還需要有一個功能足夠強大的OTA系統。OEM還是要騰出點時間來關注系統的運營功能，一開始做好了，就會減少很多後期的煩惱。例如：升級任務的重要度排序，升級任務中未升級車輛的額外通知，升級任務的灰度發布設置等等。每一個功能設計的細節都是經驗的積累啊。正所謂，一分錢一分貨，有些供應商之所以價格低肯定是有原因的。

用戶獲取軟件升級的正式通知，了解到自己的車輛已經有新版本可以使用。雖然就是一個簡單的通知，但有的時候細節上好的設計也能夠讓人耳目一新，特斯拉這個升級通知就一目了然。

4、升級的信息安全才是整個OTA升級的守門員

去年有兩名白帽黑客遠程控制了一輛吉普切諾基，當然這次“事故”隻是潛在的危險，并沒有造成嚴重的損失，随後克洛斯勒召回了140萬輛車。

今年已經看到歐洲最大的汽車俱樂部（ADAC）的研究人員展示了無鑰匙的“舒适鎖定”機制在市場上的普及程度，無疑是技術精明的小偷。在阿爾法羅密歐，雪佛蘭，福特，藍旗亞，歐寶，标緻和雷諾等大衆汽車集團中，可以使用廉價且易于使用的硬件工具繞過整個車輛系列的鎖定機構。

車輛網絡安全的核心挑戰之一是汽車的各種ECU通過内部網絡連接。因此，如果黑客設法訪問易受工具的外圍ECU（比如汽車的藍牙或者信息娛樂系統），那麼黑客們就可以控制關鍵的ECU，如制動器或者發動機，從而造成嚴重的破壞。

如今的汽車有多達100多個ECU，超過1億行的代碼，這就給與了巨大的供給面。困難的是汽車制造商是從許多不同的供應商裡獲取ECU，意味着沒有一個黑客可以控制甚至熟悉車輛的所有源代碼。

汽車越來越附能也就意味着攻擊汽車的點越來越多，上圖中顯示有很多點都是新能源汽車相對于傳統汽車的“高大上”功能，比如手機的遠程控制，雲端的遠程監控等。通信和娛樂系統特别容易受到攻擊，并且可以通過逆向工程來訪問API庫，從而促進系統之間的數據共享。從這裡，攻擊甚至可以将惡意代碼注入到電子控制單元（ECU）和控制器區域網絡（CAN）總線中，該總線控制關鍵系統，如電動轉向和制動。OBD設備是廠商用來診斷汽車的各種數據，該接口集成了很多ECU的CAN總線接口，通過OBD接口可以變向的訪問汽車其他設備，比如雨刷，空調等，現在有很多創業公司在做基于OBD外設控制汽車，但目前做的都不溫不火，甚至有些公司在基于該接口做自動駕駛的方案。

很多汽車廠商的服務器甚至都沒有提供安全加密的算法，當然網絡攻擊隻是入侵汽車的步驟之一，汽車攻擊相對于PC或者手機難以攻擊的點在于汽車本身是個集成度很高的産品，裡面有大量不同廠商的ECU，每家零部件供應商或者整車廠都有一套自己的車載協議，而且這些協議是不公開的，這是黑客們攻擊汽車最難以逾越的屏障，同時也是汽車最安全的一道保護層。

說了這麼多，其實在OTA升級中最重要的就是需要涉及到數據加密的身份校驗的問題，數據加密在整個物聯網中都比較成熟了，一般都是采用非對稱加密的算法。這裡簡單對加密的邏輯進行一下說明。

最簡單易懂的非對稱加密

北京的張三發了一個快遞到廣州的李四，途中經過了上海，上海快遞中心出現了一個黑客老王，他偷偷打開了張三給李四的快遞，然後偷偷把裡邊的衣服剪爛，再按照原樣包裝好發往廣州，可以看到對于這樣簡單包裝的傳輸在中途是可以偷偷修改裡邊的東西。

HTTP的數據包是明文傳輸，也即是如果中途某個黑客嗅探到這個HTTP包，他可以偷偷修改裡邊包的内容，至于張三跟李四是互相不知道這個動作的，因此我們必須要有一個方案來防止這種不安全的篡改行為，有個方法就是加密！

非對稱加密

張三将衣服放到一個保險箱裡邊鎖起來，他打了個電話告訴李四保險箱開櫃密碼是1234，而黑客老王不知道密碼，所以他看不到保險箱裡邊的東西，李四收到快遞後用預先溝通好的密碼就可以打開保險箱了。這裡保護的手段就是張三對物品進行加密，同時給了告訴李四解密的方法！

那如果現在要求張三的密碼隻能通過快遞傳給李四呢？如果張三直接傳密碼給李四，老王如果嗅探到這個快遞，那老王也知道密碼了，這就無法保護快遞的安全性了。因此還需要有個方案，讓張三能夠告訴李四密碼的同時，老王又無法查看到張三跟李四通信的數據。

非對稱加密在這個時候就發揮作用了，來看看怎麼回事：

張三擁有兩把鑰匙，一把叫做公鑰，一把叫做私鑰。公鑰是公開讓全社會都知道，沒關系，張三告訴所有人，你們要傳遞數據給我的時候請先用這個密鑰(公鑰)去加密一下你們的數據，加密後的數據隻能通過張三私自藏着的私鑰才能解密。

回到剛剛例子，

張三先發給保險櫃（張三公鑰）給李四，接着李四把自己的保險櫃（李四公鑰）放到張三的保險櫃(即使用張三的公鑰加密李四的公鑰)裡邊發還給張三，接着張三拿到李四的數據包後，用自己的私鑰解開了外層保險櫃(張三的公鑰)，拿到了裡邊李四保險櫃(李四的公鑰)。此時李四跟張三都有了各自的公鑰(并且都有他們自己的私鑰)，接着隻要保證每次互相傳遞數據的時候，把數據放在對方的保險櫃裡邊即可(即每次都用對方的公鑰加密數據)，這樣無論如何，老王都無法解開保險櫃（因為隻有各自的私鑰才能解開各自的保險櫃）。

從OTA基本流程中的安全防護來說。主要包含了升級包的加密與簽名，服務器端對于升級包的安全存儲，基于身份驗證建立安全鍊接通道，以及汽車端信息安全防護，對升級包的驗簽和解密管控，需要配合OEM定義清晰的信息安全防護架構以及升級流程，最終還要通過專業第三方的滲透測試來驗證OTA的信息安全防護能力達到預定的防護等級。

加密，是不讓别人看見我傳輸的是什麼内容。認證，就是确保車輛端、雲端是我期望的、認可的對象。

比如車機進行軟件升級時，要發出認證請求到服務器；服務器收到車端請求信息後，發回反饋，要求發送數字證書自證身份。車端發送數字證書到服務器端；服務器對數字證書進行校驗是否存在問題；驗證無誤後終端管理系統向終端發送驗證結果，這時才可以開始進行相應的軟件升級。更新包會被加密後傳輸到車端，在T-box解密後再分發到車機。另外一個比較重要的車端部分是網關，可以避免ECU與聯網的遠程信息處理單元直接接觸，提高了OTA更新的安全性。

uboot介紹

前面提到FOTA，需要升級的時候如果涉及到uboot部分，這部分會要求非常高，畢竟我是硬件出身，就在這裡班門弄斧簡單通過有趣的内容給大家介紹一下uboot，為什麼需要uboot。

先進行一下科普吧，大家都在家炒過菜吧，其實你發現做一頓晚餐的過程就特别像安卓系統的工作原理。

1、首先要有基本的炒菜的環境，廚房要有電、天然氣要通氣，有鍋和鏟子等工具，這些類似底層硬件的電源管理，需要有這些基本的電氣條件滿足。

2、其次要有炒菜的基本佐料，包括鹽、醬油、白醋、陳醋,糖、味精、雞精,生抽、老抽、香油,芝麻油,蔥,姜,蒜,孑然,耗油、白胡椒、黑胡椒,番茄醬,花椒,辣椒,辣椒油。

無論你炒什麼菜，都首先把這些佐料準備好，可能炒爆炒肥腸和番茄炒蛋所需要的佐料有很多不同的，但是鹽和油肯定是都需要的，隻是其他佐料有區别，這個不影響提前把這些炒菜的佐料進行準備好，盡可能的把這些佐料都準備齊全。

這裡就相當于Linux内核層，進行USB接口、藍牙、wifi、攝像頭、音視頻、顯示屏等基本服務，可能不同的APP應用所需要調用的這些服務不同，比如一款聊天軟件可能需要使用到WIFI、攝像頭、顯示等等，不需要使用USB接口，但是不影響另外APP會可能調用到USB、存儲等等。

3、不知道你們炒菜是否需要菜譜，至少小寶我炒菜需要使用到菜譜的，需要百度一下某個菜需要什麼佐料，什麼樣的配比材料，沒錯小寶這期内容修改為美食欄目去了，下面是網上水煮肉片的菜譜。

其實這裡使用到的菜譜就可以理解為安卓系統裡面的硬件抽象層，這裡簡單理解為，就是你如果知道這個菜譜中佐料的比例，在你自己家裡炒菜和在朋友家裡炒菜，這個炒出來的味道基本上也就味道相同，就可以理解為為什麼這個在安卓系統中硬件抽象層可以在不同的平台進行移植，也就是掌握了菜譜的精髓，功夫我有，天下我走。

4、最後就是炒菜的動作了，其實熟練的廚師是可以至少掌握好幾個菜同時操作，這個不僅考驗廚師的速度，也考驗廚師的精準度，對于火候的掌控要精準，對于佐料使用要合理分配。

其實這裡炒不同的菜就類似于使用不同的APP的應用，這裡如果有一個菜炒胡了，不能影響到另外一個菜的正常發揮，類似于多線程中的某個APP挂掉了，但是不能影響到其他APP的正常使用。

這裡也會出現占用資源的情況，比如同時用兩個鍋炒菜，左邊那個鍋在炒爆炒肥腸，直接把所有的鹽都一不小心全部倒完了，此時右邊鍋裡面的菜也就報廢掉了，沒有鹽的菜不能稱之為一道菜。這個是不是類似于某個APP調用内存洩露，把全部的内存占用沒有釋放，導緻機器隻能重啟。

01 安卓系統啟動簡單介紹

1、安卓系統平台架構

可以看出整個架構由5部分構成，從下到上分别為：

（1） Linux内核層：Android 的核心系統服務基于Linux 内核，在此基礎上添加了部分Android專用的驅動。系統的安全性、内存管理、進程管理、網絡協議棧和驅動模型等都依賴于該内核。

（2）硬件抽象層（HAL)：硬件抽象層是位于操作系統内核與硬件電路之間的接口層，其目的在于将硬件抽象化，為了保護硬件廠商的知識産權，它隐藏了特定平台的硬件接口細節，為操作系統提供虛拟硬件平台，使其具有硬件無關性，可在多種平台上進行移植。HAL 由多個庫模塊組成，每個模塊都為特定類型的硬件組件實現了一個接口，例如相機或藍牙模塊。當框架 API 調用設備硬件時，Android 系統為該硬件組件加載庫模塊。

（3）系統運行庫層（Native)：系統運行庫層分為兩部分，分别是C/C++程序庫和Android運行時庫。C/C++程序庫被Android中不同的部分使用 runtime庫主要是Java核心庫（提供了Java語言核心功能因此開發者可以使用Java編寫應用）和ART（Android 5.0 之前是Dalvik）該虛拟機不同于JVM是專門用于移動設備的虛拟機 允許在有限的内存内運行多個虛拟機實例 并且每個應用都是獨立的linux進程這樣可以防止虛拟機崩潰時不會導緻所有的進程被關閉。

（4）應用框架層（Java Framework)：應用框架層為開發人員提供了可以開發應用程序所需要的API，我們平常開發應用程序都是調用的這一層所提供的API，當然也包括系統的應用。這一層的是由Java代碼編寫的，可以稱為Java Framework

（5）應用層：系統内置的應用程序以及非系統級的應用程序都是屬于應用層。負責與用戶進行直接交互，通常都是用Java進行開發的

2、安卓系統啟動介紹

上圖是車載中控導航的系統啟動的簡單介紹

（1） POWER 部分：目前的導航系統基本上都是CPU+MCU的架構，MCU進行電源部分的管理，CAN通訊的處理、收音部分的處理，所以這裡的開電源的時候，一定是MCU完成整個中控導航系統的電源初始化。

MCU内部的電源管理器(regulator)将系統置于POR複位狀态，直到VDD電壓上升到超過POR複位門限電平，然後低電壓檢測模塊會接管系統複位，直到VDD電壓上升超過其LVR複位門限電平。在完成POR和LVR複位後，MCU系統的電源系統已經能夠為内部時鐘(FIRC、SIRC和LPO等)和存儲器(NVM)模塊以及CPU内核提供穩定的工作電壓了。

這裡的加載時間一般是500ms，這裡考驗的時間其實更多的是MCU的啟動時間，一些整車的網絡管理也要求ECU在低功耗模式喚醒後，能夠盡快響應CAN/LIN總線報文，也要求MCU的啟動時間要足夠快。

一些功能安全要求較高的汽車ECU應用，比如電子助力轉向(EPS)、電子檔位控制(gear control)等，對于ECU的啟動時間(startup/boot time)有嚴格的要求， 希望ECU使用的MCU能夠盡快完成系統啟動初始化，執行功能程序。

（2）uboot 部分：這裡的uboot主要進行CPU狀态檢查、DDR/emmc/usb等初始化，同時也有電源管理、USB升級檢測等等，這裡耗時基本上1S左右。

（3）kernel部分：linux内核的啟動，包括硬件初始化，驅動模塊加載，包括USB、video、camera、touch等初始化，init進程，這裡耗時1.5S左右。

（4）Android初始化：init進程啟動程序，zygote加載進程，系統啟動服務。這裡其實就是我們常見的開機動畫就在這個初始化的時候完成的，這包含窗口管理服務，藍牙服務、GPS服務，這裡的GPS默認設置為打開狀态，即服務初始化完成後就可以馬上啟動GSP定位開始，所以GPS的冷啟動定位時間不是進入主界面開始算的時間，而且在動畫界面初始化完成後就可以算時間了，這樣可以讓用戶感覺體驗更快就能GPS定位了。

（5）主界面：系統啟動，以下應用啟動工作：收音、音視頻播放、導航、語音、倒車、DVR、360全景、藍牙等其他應用，這裡的時間為2S左右。

一般的安卓系統啟動時間為18S左右，應用啟動2S，總計20S就可以正常操作APP應用了，這就是為什麼安卓車機開機時間都會很久的，不太适合用于儀表，因為儀表要求開機5S左右就能正常顯示工作。

從這個耗時來看，Android初始化的時間15S最長，所以要優化整個系統的啟動時間的話，可以優先考慮這部分的優化時間。

吃瓜群衆：小寶，你說的這些我都不懂，我們還是說回炒菜吧。

小寶：好的，那我們再來看看uboot在整個炒菜中，它是起到什麼作用，初始化uboot，如果是炒菜，就是準備了哪些東西。

其實這裡的uboot主要進行CPU狀态檢查、DDR/emmc/usb等初始化，同時也有電源管理、USB升級檢測等等，想想炒菜之前是不是要檢查鍋是否幹淨，是否需要重新洗一遍，然後佐料這些是否足夠，炒菜的燃氣是否夠大，有一個初步的火量大小的控制，等後面放好佐料後根據實際運氣的情況再調節燃氣大小的控制，就類似于前面初始化DDR和FLASH的運行速率，後面實際還可以調整這部分的運行速率。

02 Uboot的簡單介紹

1、為什麼需要uboot

計算機系統的組成部件非常多，不同的計算機系統組成部件也不同。但是所有的計算機系統運行時需要的主要核心部件都是3個東西：CPU+外部存儲器（Flash/硬盤+内部存儲器（DDR SDRAM/SDRAM/SRAM）。

而一般的PC機啟動過程為：PC上電後先執行BIOS程序（實際上PC的BIOS就是NorFlash），BIOS程序負責初始化DDR内存，負責初始化硬盤，然後從硬盤上将OS鏡像讀取到DDR中，然後跳轉到DDR中去執行OS直到啟動（OS啟動後BIOS就無用了）。

總結：嵌入式系統和PC機的啟動過程幾乎沒有兩樣，隻是BIOS成了uboot，硬盤成了Flash。

從第一章節中我們簡單介紹了Android系統的啟動流程，Android系統的啟動流程大緻分為三個階段：

（1）電源鍵按下後加載引導程序Bootloader到RAM 然後Bootloader把OS拉起；（2）Linux 内核層面的啟動；（3）Android系統層面的啟動。

這裡的uboot就是剛開始被放到flash中，闆子上電後，會自動把其中的一部分代碼拷到内存中執行，這部分代碼負責把剩餘的uboot代碼拷到内存中，然後uboot代碼再把kernel部分代碼也拷到内存中，并且啟動，内核啟動後，挂着根文件系統，執行應用程序。

2、uboot有什麼特點

uboot 屬于bootloader的一種，是用來引導啟動内核的，它的最終目的就是，從flash中讀出内核，放到内存中，啟動内核。

（1）自身可開機直接啟動

①一般的SoC都支持多種啟動方式，譬如SD卡啟動、NorFlash啟動、NandFlash啟動等·····uboot要能夠開機啟動，必須根據具體的SoC的啟動設計來設計uboot。

上圖是安霸A12的boot支持的啟動方式，有NOR FLASH，NAND FLASH，USB、EMMC等多種存儲設備，但是要注意，這裡啟動的地址默認都是從第一個零地址開始，比如NAND FLASH就是BLOCK 0啟動，如果這個block損壞那麼就無法啟動，如果要跳轉到block 1，那麼就需要CPU芯片内部支持存儲代碼進行判斷，否則隻能從默認block 0啟動。

②uboot必須進行和硬件相對應的代碼級别的更改和移植，才能夠保證可以從相應的啟動介質啟動。uboot中第一階段的start.S文件中具體處理了這一塊。

（2）能夠引導操作系統内核啟動并給内核傳參

①uboot的終極目标就是啟動内核。

②linux内核在設計的時候，設計為可以被傳參。也就是說我們可以在uboot中事先給linux内核準備一些啟動參數放在内存中特定位置然後傳給内核，内核啟動後會到這個特定位置去取uboot傳給他的參數，然後在内核中解析這些參數，這些參數将被用來指導linux内核的啟動過程。

（3）能提供系統部署功能

①uboot必須能夠被人借助而完成整個系統（包括uboot、kernel、rootfs等的鏡像）在Flash上的燒錄下載工作。

②裸機教程中刷機（ARM裸機第三部分）就是利用uboot中的fastboot功能将各種鏡像燒錄到iNand中，然後從iNand啟動。

（4）能進行soc級和闆級硬件管理

①uboot中實現了一部分硬件的控制能力（uboot中初始化了一部分硬件），因為uboot為了完成一些任務必須讓這些硬件工作。譬如uboot要實現刷機必須能驅動iNand，譬如uboot要在刷機時LCD上顯示進度條就必須能驅動LCD，譬如uboot能夠通過串口提供操作界面就必須驅動串口。譬如uboot要實現網絡功能就必須驅動網卡芯片。

②SoC級（譬如串口）就是SoC内部外設，闆級就是SoC外面開發闆上面的硬件（譬如網卡、iNand）

（5）uboot的'生命周期'

①uboot的生命周期就是指：uboot什麼時候開始運行，什麼時候結束運行。

②uboot本質上是一個裸機程序（不是操作系統），一旦uboot開始SoC就會單純運行uboot（意思就是uboot運行的時候别的程序是不可能同時運行的），一旦uboot結束運行則無法再回到uboot（所以uboot啟動了内核後uboot自己本身就死了，要想再次看到uboot界面隻能重啟系統。重啟并不是複活了剛才的uboot，重啟隻是uboot的另一生）

③uboot的入口和出口。uboot的入口就是開機自動啟動，uboot的唯一出口就是啟動内核。uboot還可以執行很多别的任務（譬如燒錄系統），但是其他任務執行完後都可以回到uboot的命令行繼續執行uboot命令，而啟動内核命令一旦執行就回不來了。

總結：uboot的一切都是為了啟動内核。

①uboot主要作用是用來啟動操作系統内核。體現在uboot最後一句代碼就是啟動内核。

②uboot還要負責部署整個計算機系統。體現在uboot最後的傳參。

③uboot中還有操作Flash等闆子上硬件的驅動。例如串口要打印，ping網絡成功，擦除、燒寫flash是否成功等。

④uboot還得提供一個命令行界面供人來操作。很簡單，至少你能看到。

3、Uboot完成後進入的模式有哪些。

安卓開機後，硬件系統上電，首先是完成一系列的初始化過程，如 CPU、串口、中斷、timer、DDR 等硬件設備，然後接着加載 bootloader，為後面内核的加載作好準備。在一些系統啟動必要的初始完成之後，系統會通過檢測三個條件來判斷要進入何種工作模式，流程如圖。

這裡重點說說Recovery模式，我們可以簡單的理解為工程模式，手機進入Recovery模式可以進行重啟手機、清空SD卡數據、恢複出廠設置、刷機、備份與恢複數據等諸多功能。

以前買到小米手機，手機無法正常開機進入不了系統了，此時就從百度上搜索怎麼強制恢複出廠設置，方法是先關閉小米手機，然後同時按住“小米3音量+鍵”和“電源鍵”，大約3s左右，即可進入小米3Recovery模式了。

03 怎麼加快uboot的啟動時間

1、使用通訊速率快的存儲，接口需要不占用

一些功能安全要求較高的汽車ECU應用，比如電子助力轉向(EPS)、電子檔位控制(gear control)等，對于ECU的啟動時間(startup/boot time)有嚴格的要求， 希望ECU使用的MCU能夠盡快完成系統啟動初始化，執行功能程序。此外，一些整車的網絡管理也要求ECU在低功耗模式喚醒後，能夠盡快響應CAN/LIN總線報文，也要求MCU的啟動時間要足夠快。

在有雙核的CPU的時候，可以在不同的内核執行不同的程序，這樣可以縮短啟動時間。

液晶儀表的開機速度要求比較快，一般要求在6S之内要進行開機進行工作，這樣就可以更快的讓用戶處理相關的車身檢測和報警功能。

其實這裡比較簡單粗暴的方便就是使用通信速度更快的存儲，下圖就是東芝産品介紹boot time的在使用普通NOR flash，EMMC、UFS的存儲設備，可以看到UFS接口的EMMC在64MB的數據下，也就115ms可以運行完成，而SPI NOR FLASH需要1185ms，基本上差了10倍時間的差距。

這裡唯一的不同就是存儲設備的通訊速率不同，UFS的通訊速率可以達到850MB/S，而NOR FLASH最快也就是54MB/S。

在儀表賽普拉斯推薦的平台上，使用hyperflash，可以讓開機時間在2S之内。

賽普拉斯主推的hyperflash，獨占帶寬無搶占的情況下，目标帶寬為200MB/s，1280x480的标清屏的開機速度可以達到0.7S。目前創維汽車智能在使用這個平台供貨儀表，做的非常棒。

2、優化一些時鐘、ECC校驗等方法加快啟動速度（參考淺談嵌入式MCU軟件開發之S32K1xx系列MCU的啟動過程和啟動時間優化方法詳細）

下圖是S32KXX系列的MCU的啟動流程圖，首先是關閉CPU到的全局中斷，把CPU的内核寄存器清零，初始化SRAM的ECC，然後進行系統的初始化等等。

比如在MCU的硬件加密模塊CSEc的安全啟動(Secure boot)功能，建議使用串行(Sequential) Secure boot而不是并行(Parallel) Secure boot, 因為後者工作時CSEc和CPU内核都會訪問P-Flash，從而導緻CPU内核從P-Flash取指令的速度變慢，從而拉長Startup運行時間，而且Secure boot運行完之前不允許修改系統時鐘配置(尤其是Flash的工作時鐘FLASH_CLK)：

Freescale S12G系列汽車MCU的外部晶振時鐘起振時間如下，作為參考，也是頻率越高，啟動越快(start-up時間越短)

04 BOOT升級的模式

正常情況下，下載了升級固件，肯定是要把新固件替換到老固件，這個時候就涉及到兩種模式。

其實這個最容易理解了，小寶給你說一個生活中的例子就好理解了，你手裡拿着一個冰淇淋，現在老闆告訴你有新款的冰淇淋來了，可以免費領取一個，你會怎麼做呢？

有的人是把手裡的冰淇淋扔掉，直接去領取新的冰淇淋，這樣的做法是不占用手的資料，反正都隻占用一個手，缺點就是可能去排隊的時候，老闆新的冰淇淋都領取完了，這個時候你就一個冰淇淋都沒有了。

有的人的做法是先排隊，确認領用到新的冰淇淋後再把老的冰淇淋扔掉，此時在領用的過程中會耗費掉兩個手的資源，不過這樣最保險，哪怕沒有領用到最新的冰淇淋，老的冰淇淋還可以繼續吃。

同樣的道理，新固件替換老固件覆蓋的兩種方式：雙區模式和單區模式。

雙區模式：

雙區模式中老固件和新固件在flash中各占一塊bank（存儲區）。假設老固件放在bank0（運行區）中，新固件放在bank1（下載區）中，升級的時候，應用程序先把新固件下載到bank1中，隻有當新固件下載完成并校驗成功後，系統才會跳入BootLoader程序，然後擦除老固件所在的bank0區，并把bank1的新固件拷貝到bank0中。後台式下載必須采用雙區模式進行升級。

優點：升級過程中出現問題或者新固件有問題，它還可以選擇之前的老固件老系統繼續執行而不受其影響。

缺點：多占用flash空間的一個存儲區，在系統資源比較緊張的時候較為困難。

單區模式：

單區模式的非後台式下載隻有一個bank0（運行區），老固件和新固件共享這一個bank0。升級的時候，進入bootloader程序後先擦除老固件，然後直接把新固件下載到同一個bank中，下載完成後校驗新固件的有效性，新固件有效升級完成，否則要求重來。

優點：跟雙區模式相比，單區模式節省了Flash空間的一個bank，在系統資源比較緊張的時候，單區模式是一個不錯的選擇。

缺點：如果升級過程中出現問題或者新固件有問題，單區模式碰到這種情況就隻能一直待在bootloader中，然後等待再次升級嘗試，此時設備的正常功能已無法使用，從用戶使用這個角度來說，可以說此時設備已經“變磚”了。

相比較，雙區模式雖然犧牲了很多存儲空間，但是換來了更好的升級體驗。