導讀：汽車已經慢慢成為一個大型終端設備。對于這樣的定義，持續的功能更新是必不可少的，也意味著車輛OTA普及勢在必行(PS：如果把車看做是一個終端設備，也就能稍微理解手機、IoT廠商為什么紛紛造車了)。
來源：上海艾拉比智能科技有限公司
OTA整體架構包含OTA云端、OTA終端、OTA設計對象三部分，如下圖1所示，OTA云端為OEM專屬的云端服務器平臺，負責零部件的軟件版本管理、軟件升級任務、數據分析、云診斷/質量管理以及與車端的數據同步。
OTA終端通常采用T-Box/IVI，負責軟件包的下載，同時還負責驗簽、軟件包解密、安全刷寫、狀態上報等，要實現這些功能主要依賴終端設備中的OTA manager和Update Agent，其中OTAmanager負責車輛ECU的更新，Update Agent則兼容不同的車內網絡和通信協議。
圖1 OTA整體框圖(來源知網、頭豹)
一、汽車OTA的發展
在2012年以前，OTA升級主要為SOTA，其含義是軟件OTA，用來升級App的，打個比方就像微信在App store里推送新的版本，你點擊更新，這個就是SOTA，那會兒車輛還很少配有聯網功能。
另外一種是FOTA(固件升級)，比如我們的蘋果手機系統從iOS15.2升級到15.3，這個就是FOTA。這種是特斯拉在2012年第一次將其引入到汽車上。那一次特斯拉增加了座椅記憶、模仿油車的怠速蠕動等功能。
到2015年左右，傳統車企開始通過車輛聯網引入局部OTA。2016年豐田宣布采用OTA技術更新ECU，2017年福特宣布采用OTA技術，同年大眾宣布采用OTA技術，這個階段都還是SOTA。
到2019年，國內的新勢力開始陸續落地OTA，通過OTA的優化電池管理、自動駕駛、動力系統等系統，持續優化車輛的體驗和性能。
圖2 2019年蔚來、特斯拉、小鵬的OTA推送(來源網絡)
到今天基本大多數車企都已實現OTA(不管是SOTA還是FOTA)，不過大部分是實現重要控制器的OTA功能，比如自動駕駛控制器，中控、電池管理、電機控制等。各車企的實現情況如圖3所示。
圖3 當前各主機廠的OTA能力(來源頭豹)
為了實現整車級的OTA，各主機廠紛紛對原有的網絡架構進行的大刀闊斧的變革，如圖4列舉了部分主機廠中央計算平臺架構的落地時間。
圖4 部分主機廠的中央計算平臺
除了圖4整理的外，大部分主機廠都在進行E/E架構中引入三域/中央計算平臺、區域控制器，為什么大家都迫不及待的引入這些呢？除了傳輸數據的大幅增加外，域控架構/中央計算平臺將E/E扁平化，利于實現整車級的OTA。
如圖5所示為傳統分布式架構與域控架構下的OTA升級步驟，在傳統網關分布式架構下，由于控制器分散以及層級很深，導致在實現OTA的時候要一層一層的實現轉發和透傳，多次的轉發和透傳容易導致數據的丟失，導致升級失敗。另外需要支持OTA功能的控制器，通常需要實現軟件備份，也就是一個控制器內要存放兩份軟件，防止升級失敗后，控制器變磚。由于傳統控制器的芯片Flash和RAM本身就很小，基本不太可能實現。
對于域控架構，或者是中央計算平臺架構，大部分控制器的功能進行了整合，大幅減少控制器的數量，而且整體的E/E架構也更加扁平，這樣整車OTA實現更加容易且友好。
圖5 傳統分布式架構與域控架構OTA升級步驟(來源頭豹)
二、OTA發展的制約因素
當前汽車OTA升級面臨最主要的問題是安全問題，同時也受通訊基礎建設、軟件開發能力等因素影響。
1、在安全性方面
無論是在數據傳輸環節還是軟件更新環節，都有可能對汽車功能、個人隱私，甚至是人身安全造成危害。如何保證車輛安全的條件下對汽車更多功能域開放OTA升級是當前行業最基本的挑戰，這需要OTA流程提供商、云存儲提供商、車企多方共同合作，打造一個安全的OTA升級環境。
2、在基礎設施建設方面
隨著新車逐步具備OTA功能，需要管理的車輛也越來越龐大，這就意味著車廠需要更多的服務器來存儲大量的用戶車輛數據，車廠對數據中心的需求也會越來越大，數據中心的建設和維護對當前車企來說還是一片知識盲區，另外較高的建設和維護成本也可能成為制約OTA發展的因素。
3、在軟件開發能力方面
車企的軟件能力是保持自身競爭力的重要能力之一。較強的軟件能力將為車企帶來更豐富的OTA升級內容、更短的研發周期等，并且持續為用戶提供新的體驗，提高用戶粘性。
三、特斯拉OTA升級流程
特斯拉作為整車OTA的鼻祖，從2012年推出的Model S到最新的Model 3都具備整車OTA能力。不僅可以通過OTA升級車載娛樂系統、應用程序等，還可以實現對ECU進行軟件更新，比如電池管理系統、電驅控制單元、整車控制單元等。特斯拉的OTA框架特斯拉的OTA架構如圖6所示，首先中控系統的CID通過特斯拉的私有握手協議，將固件包從云端下載下來，并對其進行解密和完整性校驗。
圖6 OTA升級框架
從OTA升級框架來看，升級方式主要為兩種，一種為對有以太網連接的ECU，另一種為通過網關轉換為CAN總線的ECU。對于具有以太網連接的ECU，都具有ic-updater，cid-updater升級代理，其中cid-updater負責從云端獲取固件包，并進行校驗，可將cid-upadater視為本地服務器，ic-updater作為遠程代理。另外對于這類ECU而言，其采用的軟件升級方式為A/B備份，如圖7所示。例如當前使用的是A區，當軟件需要更新時，先將軟件寫入至B區， 更新完之后，B區作為主系統啟動，而A區作為備份區域。
圖7 具有以太網的ECU的A/B備份方式
對于通過網關基于CAN總線的UDS協議或者其他協議更新的ECU。其從release.tgz中提取所需要的文件，包括：
1、boot.img：在升級過程中運行，其類似于常用的flash driver；
2、Release_version.txt：包含固件的版本信息；
3、Version_map2.tsv和Signed_metadata_map.tsv：包含固件信息；
4、Internal_option_default.tsv：包含固件的默認配置信息；
5、ECU命名的文件，其格式為ECUName/ProviderID/ECUFwName.hex。其主要是hex格式的文件，真正需要下載至ECU的文件。
參考：頭豹的車OTA研究報告，網絡
