電子發燒友App
1 OTA技術概念
隨著高級輔助駕駛的發展和自動駕駛的引入，汽車變得越來越智能，這些智能汽車被軟件控制，裝有巨量的軟件程序，當出現一個軟件程序問題或者更新時，如果按照傳統的解決方式，那都將是一項很繁重的任務。以某車上市后出現的剎車邏輯問題為例，按照傳統的解決方案，那么所有該車輛先將被召回，然后派人更新軟件。這樣，一方面影響用戶體驗和滿意度，另一方面又要耗費大量的人力物力來修復問題。
為了解決傳統方式的痛點，使得軟件更新更迅速，一種遠程升級軟件的技術OTA被引入到汽車行業。汽車遠程升級技術OTA(Over-the-Air)是指通過移動通信網絡（2G/3G/4G或Wifi）對汽車的零部件終端上固件、數據及應用進行遠程管理的技術。簡單來說OTA技術實現分三步：首先將更新軟件上傳到OTA中心，然后OTA中心無線傳輸更新軟件到車輛端，最后車輛端自動更新軟件。
Source：OTA Software Update Technology for Vehicles – Highly Reliable and Quick Updates
也就是上述剎車邏輯問題的解決方式就變成了更新軟件無線傳輸到車輛并自動完成更新，完美地解決傳統方式的痛點，顯然我們可以看出OTA技術的優勢：
能有效提升用戶體驗與滿意度
能大范圍大批量升級系統并提供升級成功率
能快速修復車輛故障
能有效降低售后維護成本
而且隨著汽車行業已進入軟件定義汽車的時代，對售后汽車售賣各種各樣功能的新商業模式興起，也要求汽車必須具備OTA功能。這里準確地說，OTA分為兩類，一類是固件在線升級FOTA（Firmware-Over-the-Air），是指不改變車輛原有配件的前提下，通過寫入新的固件程序，使擁有聯網功能的設備進行升級，包括車輛的發動機，電機，變速箱，底盤等控制系統，比如特斯拉曾通過FOTA新增過自動駕駛功能、增加過電池容量和改善過剎車距離等。另一類是軟件在線升級SOTA（Software-Over-the-Air），是在操作系統的基礎上對應用程序進行升級，是指那些離用戶更近的應用程序，UI界面和車載地圖、人機交互界面等功能，像娛樂系統更新操作界面或主題。
下面將以FOTA技術應用來進一步了解：
?
2 OTA技術架構
當前智能網聯汽車的OTA架構由OTA云端，OTA終端和OTA升級三部分組成，如下所示。
Source: 智能網聯汽車的OTA升級方案
這里，OTA云端為OEM專屬的云端服務器平臺，OTA終端采用TBox，網絡架構采用功能域劃分方式?？紤]到本文對OTA技術介紹的完整性，但重點不在說明OTA技術架構，而是旨在說明車內嵌入式設備ECU等的升級方案，故引用《智能網聯汽車的OTA升級方案》供相關朋友再做進一步研究。
? 
Source: 智能網聯汽車的OTA升級方案
針對ECU升級的過程描述：FOTA 系統主要通過車載移動互聯網進行數據上報及下行傳輸，通過車內網對車內設備單元進行數據刷寫。典型的 FOTA 系統網絡安全主要由 OTA 遠程管理平臺端、 TBox 端（4G LTE）、中央網關、域控制器端及數個 ECU 等節點組成。
? 
Source:來自網絡，未知
FOTA 系統網絡安全性需要確保升級包在遠程服務器端的安全存儲、后臺服務器到車端的安全加密通訊、中央網關的升級包解密、防火墻和 OTA 管理，以及車內網絡基于對稱加密的安全通訊和安全 Bootloader 等要素。
? 
Source:?Software_Update_and Upgrade Over thr Air
?
3 ECU的OTA技術實現方案
本部分主要介紹車內嵌入式設備ECU的OTA技術實現方案，也就是整車控制器，發動機控制器，變速箱控制器和電池管理控制器等實現OTA升級，可以采用怎樣的實現方案。
從上文可知，在車輛端，OTA實現是從TBox 端（4G LTE）經網關，通過總線通訊（CAN或以太網）將軟件刷寫到車內嵌入式設備ECU（目標ECU）。
那么具體刷寫到目標ECU還是其他存儲設備？以及又將如何啟動新軟件運行？下面將詳細介紹，不過為了更好地理解ECU的OTA實現方案，先解釋下分區刷寫和地址映射的概念：
3.1 分區刷寫與地址映射的概念
關于軟件刷寫，經常會看到需求“要求支持Bootloader，BSW，ASW和標定等獨立刷寫”，這是怎么個概念呢？下面進行詳細解釋：對于汽車ECU軟件研發來說，所謂軟件要么是模型，要么是C/C++代碼，但最終都會變成一個二進制文件，比如HEX, S19, Bin等格式。這個文件將會被刷寫到ECU的非易失性存儲單元（內存）。
? 
Source:?英飛凌TC2xx用戶手冊
像英飛凌TC2xx系列采用的內存是Flash，存儲程序叫做PFlash，存儲數據叫做DFlash。為了合理有效使用這些內存，同時也方便管理，通常我們會分配這些內存的用途，以下圖的PFlash分配為例，分配2MB存啟動軟件Bootloader，2MB存底層軟件BSW和2MB存應用層軟件ASW。
針對前面需求，不難理解客戶的意思，就是需要能只更新其中一個，比如ASW，而其他不變，即Bootloader和BSW不變。當然，OTA本質上就是實現軟件遠程刷寫，當然會有這樣的需求，所以在此先介紹
第1個概念--分塊刷寫、分區刷寫。
僅做示意，不代表實際應用情況
第2個概念--地址映射
上面進行了內存分配，那么我們寫代碼時候，怎么保證代碼就能放入規定的內存空間，比如說ASW的軟件代碼怎么能放在規定的內存空間，更準確第地說，ASW代碼編譯完成后的地址怎么會在0x8040 0000 - 0x805F FFFF范圍。需要使用#pragma用法來實現，以一個ASW函數QxyDemo的定義為例，
Qianyixing_sdata的地址范圍屬于上圖規定的ASW內存空間，通過所示#pragma的用法，那么QxyDemo編譯后二進制代碼的地址將在Qianyixing_sdata內，也就意味著在0x8040 0000 - 0x805F FFFF范圍。
通過上述這個過程，其實我們建立ASW C/C++代碼與ECU Flash地址的映射，這樣就能保證ASW二進制代碼刷寫到預期的ECU PFlash地址，同理Bootloader和BSW。當軟件運行時，就可以通過有序地訪問來自PFlash地址的ASW內容，執行ASW預期的操作和運算。
3.2 幾種OTA實現方案
在介紹了分區刷寫和地址映射的概念后，下面來了解ECU的OTA實現方案。總的來說，OTA實現方案分為兩種，一種與通常的刷寫方式一樣，即先擦除當前版本軟件，再刷寫新版本軟件，但這種方法有個隱患，就是新軟件有問題時，由于舊軟件已經被擦除，沒有備份，恢復會很麻煩，因此就提出了另一種，即A/B交換。
Source:?TA Updates - Requirements for a Full System Solution
A/B交換就是內存中會分兩塊區域，
一塊存放當前版本軟件，另一塊存放舊版本軟件。當OTA升級新版本軟件時，新版本軟件將代替舊版本軟件，這時，一塊放的是當前版本軟件，另一塊放的是新版本軟件。再激活運行新版本軟件，此時原先的當前版本就變為舊版本軟件，作為備份，以防運行的新版本軟件有問題，可以及時回滾恢復。
Source:?TA Updates - Requirements for a Full System Solution
這里，對于A/B交換方案，其實有三種實現方案：
?
第1種，基于硬件輔助的A/B交換方案。
該方案要求ECU內存足夠，而且支持地址重映射，也就是當新版本軟件刷寫完成，通過更新映射地址來激活新版本軟件，即新版本軟件運行的入出地址不變。
Source：Software_Update_and Upgrade Over thr Air
?
第2種，A/B交換方法
與第1類的差別在于ECU硬件不支持地址重映射，激活新版本軟件的入出地址變化。
Source：Software_Update_and Upgrade Over thr Air
?
第3種，基于外擴內存的A/B交換方案
該方案是需要額外的外擴內存，備份當前版本軟件和舊版本軟件，新版本軟件會先刷寫原先的舊版本軟件空間，然后擦除ECU內存的當前版本軟件，刷寫新版本軟件，完成激活。
Source：Software_Update_and Upgrade Over thr Air
針對以上三種A/B交換方案，
這三種方案在新版本軟件有問題時，都支持舊版本軟件回滾；
第1，2方案的激活時間都較短，但第1種方案一般需要高級版本的ECU才支持，比如英飛凌TC39x；第2種方案軟件實現較復雜，因為需要處理不同的復位向量和中斷地址；
第3種方案則是通用的方案，因為對已有的MCU平臺不需要做很大改動，只需要增加額外的外擴內存就能實現。
注：回滾（Rollback）指的是程序或數據處理錯誤，將程序或數據恢復到上一次正確狀態的行為?；貪L包括程序回滾和數據回滾等類型。
3.3?新版本軟件
上述OTA升級刷寫的新版本軟件，一般分為兩類。一類是通常理解的新軟件替換舊軟件。
? 
Source:?TA Updates - Requirements for a Full System Solution
像車輛ECU的大部分軟件很小，都采用這類，但像車輛的娛樂信息系統和車載地圖等的軟件很大，可能采用另一類：差分文件。
引自[6]:由于車載網絡的帶寬資源和計算資源等有限，通常不在其上直接傳輸完整升級文件而是選擇通過差分算法傳輸增量升級文件然后再通過相應還原算法計算出原完整升級文件，以減少傳輸過程中的時間消耗以及對車載網絡本身的使用負載。差分算法是指在云服務器端比較新、舊版本之間的差異并生成差分 delta 文件，然后將該文件傳輸到車輛客戶端，由車輛客戶端根據接收到的差分delta 文件和舊版文件還原成新版文件。因差分 delta文件的大小遠小于源文件，所以有利于無線傳輸，同時節省流量，能夠提升整個傳輸過程的安全可靠性和經濟性。
? 
Source:?TA Updates - Requirements for a Full System Solution
以上就是從ECU角度介紹了OTA技術實現方案的大體思路，具體采用何種方案，主要取決整車網絡架構和ECU情況，接下來借助AutoSAR OTA相關文檔來談談OTA都有哪些典型需求。
?
4 OTA相關需求
為了實現OTA功能，一般會提什么樣的需求？下面通過對OTA升級過程和OTA軟件實現架構的理解，來逐步分析。
?
4.1 OTA升級過程
根據AutoSAR相關文檔，OTA升級的完整過程如下示意：
Source：AUTOSAR_EXP_FirmwareOverTheAir
這里假設新軟件已經下載到FOTA Master ECU, 那么還需將新軟件下載到Target ECU，驗證新軟件的完整性和正確性，并激活新軟件等動作，即執行installation, verification和 activation幾個過程：
installation是指將新軟件下載到target ECU，這個過程中車輛保持正常運行，即車一邊跑一邊再下載軟件到target ECU, 所謂的 read while write.
在這個過程，Master ECU為了協調OTA升級，需要實時了解進展；軟件installation需要多幀傳輸，這時Target ECU需要進行數據處理；installation過程也可能不是如預期順利，比如會出現取消或中斷等情況。因此，針對這些情況就會產生相應的需求，比如：
verification是指通過預定算法驗證新軟件。這時需求：Completeness of new software，以及指定相應的驗證算法
activation是指車輛處于安全狀態下，備份舊軟件，激活新軟件。這里，如果采用外部Flash來實現，其過程可能為先備份舊軟件到外部Flash，然后復制新軟件到ECU，再激活新軟件。
此時需求為：
以上通過對各個過程描述和分析，示例了各個過程會產生怎樣的需求。以此思路，那么對Target ECU又怎樣的需求，從AutoSAR文檔可見如下需求：
總的來說，需求一方面取決于整車的OTA架構和ECU情況，另一方面又取決于OTA功能的自身定義和特性。
4.2 OTA軟件實現
根據AutoSAR架構，OTA軟件實現方案如下所示：
Source:?AUTOSAR_EXP_FirmwareOverTheAir
對于Target ECU來說，主要分3塊工作，支持UDS服務通過通訊模塊傳輸進新軟件；OTA handle模塊執行處理OTA各個過程，比如上節所述的installation, verification和activation等功能；內存模塊寫入新軟件等。
那么有
（引自[AUTOSAR_RS_FirmwareOverTheAir]）：
? ?
審核編輯：劉清
?
工商網監
評論