域控制器OTA升級策略研究

劉曉冬 趙星陽 劉曉波

摘要：目前市場主流對域控制器OTA升級采用A/B分區(qū)系統(tǒng)方案，極大地浪費硬件存儲資源。因此，提出一種新的OTA升級策略，對需要升級的文件進行備份。當升級失敗時，將備份文件直接替換升級文件，這樣既做到安全升級，又能降低硬件存儲資源消耗。

關鍵詞：域控制器；OTA；升級策略

中圖分類號：U463? 收稿日期：2023-11-12

DOI：10.19999/j.cnki.1004-0226.2024.02.014

1 前言

在汽車行業(yè)“電動化、網(wǎng)聯(lián)化、智能化、共享化”新“四化”的影響和推動下，各家汽車廠商紛紛推出集成大量智能硬件的汽車平臺，進而對相關軟件數(shù)量和質(zhì)量的要求也在不斷提升。伴隨國家對汽車行業(yè)相關法規(guī)的逐漸完善與硬件平臺的標準化，如何通過軟件服務的差異化在眾多汽車品牌中突出重圍成為各大汽車廠商思考的核心問題。

在傳統(tǒng)的汽車研發(fā)過程中，一旦汽車生產(chǎn)下線，那么其性能和提供的服務都被確定下來，而車輛發(fā)生任何故障，消費者也基本只有去4S店才能解決。這種僵化的生產(chǎn)服務體系顯然已不符合時代的要求，消費者需要更加快速和便捷的服務以及持續(xù)不斷的新鮮體驗。OTA技術的出現(xiàn)使得汽車廠商迎來了曙光，解決了發(fā)展的困境。汽車廠商不但可以通過OTA快速解決汽車故障缺陷降低召回成本，還可以借助OTA持續(xù)優(yōu)化車輛性能和添加新的功能元素，為消費者提供個性化優(yōu)質(zhì)服務。

2 汽車OTA發(fā)展與現(xiàn)狀

汽車OTA（Over-The-Air，空中下載技術）指車輛通過無線網(wǎng)絡與遠程服務器交互，下載安裝軟件升級包，修復汽車軟件故障，為汽車增加新功能或優(yōu)化軟件功能等[1]。早在2000年左右，OTA的雛形已在日本汽車廠商中間出現(xiàn)，即使用遠程升級服務對T-Box（Telematics Box，汽車的通信模塊）進行升級。但此時，各大汽車廠商并沒有意識到OTA這項技術對汽車行業(yè)所帶來的強大變革力量。直至2012年，特斯拉Model S的推出及其后續(xù)依賴OTA表現(xiàn)出的“自我進化”能力才吸引了眾多汽車廠商的持續(xù)關注，特斯拉也被視為整車OTA的鼻祖[2]。隨著汽車智能化、網(wǎng)聯(lián)化等趨勢的發(fā)展以及“軟件定義汽車”理念在全球的風靡，OTA也越來越被各大汽車廠商視為未來汽車行業(yè)發(fā)展的核心技術之一。到2022年為止，全球各大汽車廠商已在不同程度上實現(xiàn)了汽車OTA功能。

3 汽車OTA的優(yōu)勢與缺點

汽車OTA主要分為FOTA（Firmware-OTA，固件在線升級）和SOTA（Software-OTA，軟件在線升級）。前者是對驅動和系統(tǒng)的升級，技術實現(xiàn)難度高，對車輛安全與駕駛影響大，并且難以保證百分之百成功；后者偏向對于應用軟件的升級，技術實現(xiàn)難度稍低，升級失敗也不會對整車駕駛安全造成影響。

OTA技術的優(yōu)勢表現(xiàn)在以下幾點：

a.汽車出現(xiàn)軟件質(zhì)量問題時可通過OTA快速進行修補，節(jié)約召回費用，避免影響品牌價值。

b.能夠通過OTA實現(xiàn)對汽車原有功能與服務的快速迭代，提升產(chǎn)品的使用體驗。

c.為汽車安裝性能與功能冗余的硬件，通過OTA服務逐步解鎖新功能，為汽車廠商創(chuàng)造新的業(yè)務增長點。

然而，OTA技術的使用也為汽車的安全帶來了新的隱患：

a.為汽車提供OTA服務的云服務器可能被黑客入侵，非法獲取車輛信息等[3]。

b.汽車通過OTA終端從服務器下載的軟件升級包可能被黑客截獲和篡改，造成升級失敗，甚至影響車輛駕駛安全等。

盡管OTA存在以上安全弊端，但它給各大汽車廠商帶來的好處卻遠遠大于其弊端，因此對于OTA的熱情有增無減。然而，由于傳統(tǒng)汽車廠商的生產(chǎn)研發(fā)模式和歷史包袱導致其軟件研發(fā)能力存在不足，自研OTA的進展一直不容樂觀，反而是以特斯拉、蔚來、理想等造車新勢力在OTA技術方面發(fā)展迅猛，都取得了不錯成果。從長遠來看，OTA技術必將成為未來汽車的標準配置[4]。

4 域控制器OTA升級方案設計

本文提出一種汽車域控制器軟件升級框架，如圖 1所示，該方案將整個域控制器軟件升級流程分為三個階段，每個階段又分為三個步驟。

a.服務器將軟件升級信息推送給預期需要升級服務的目標車型，汽車上的通信模塊收到升級推送信息后，立馬回復服務器“收到”，服務器收到車輛反饋后不再向其發(fā)送信息，最后通信模塊通過車上的人機交互系統(tǒng)詢問車主是否升級。

b.汽車的通信模塊收到車主的反饋信息后，進行下一步的升級操作。若是不同意升級，整個流程到此終止；反之，汽車的通信模塊便向服務器請求下載軟件升級包，服務器在確認車輛信息后便與車輛建立穩(wěn)定、安全的網(wǎng)絡連接，為其傳輸軟件升級包。

c.汽車在升級完成后，需要向服務器報告自己的升級結果及相關日志信息。若升級成功，服務器僅需要更新該車輛搭載的軟件版本信息；若反饋升級失敗，服務器則需要根據(jù)相關日志信息分析升級失敗的原因，為客戶提供升級幫助。

本框架前兩個階段的主要目的是將軟件升級包從服務器上下載到汽車需要升級的域控制器上，關鍵點在于網(wǎng)絡傳輸安全，需要網(wǎng)絡安全人員為云服務器與汽車之間的信息交互進行加密處理，同時又不能影響二者之間的信息傳輸效率。本文對上述升級流程框架中的第三階段進行重點研究。詳細介紹域控制器上搭載的Linux操作系統(tǒng)是如何完成升級與如何處理升級失敗結果的。

4.1 EMMC分區(qū)

域控制器上Linux系統(tǒng)的升級主要分為兩大部分：Linux內(nèi)核的升級與根文件系統(tǒng)的升級。在本文中，存儲Linux相關系統(tǒng)文件的存儲介質(zhì)為EMMC（Embedded Multi-Media Card，嵌入式多媒體控制器）。為了方便描述上述二者的升級流程，本文需要先行介紹一下EMMC的分區(qū)、各分區(qū)內(nèi)部存儲的內(nèi)容以及各分區(qū)在域控制器Linux系統(tǒng)的升級過程中分別發(fā)揮了什么樣的作用。

如圖2所示，EMMC被分為5個分區(qū)。第一個分區(qū)用來放置Linux內(nèi)核，假設內(nèi)核-0為正在使用的Linux內(nèi)核，內(nèi)核-1為舊版內(nèi)核。如果需要對內(nèi)核進行升級，那么就使用新版內(nèi)核替換內(nèi)核-1的內(nèi)容，然后可以通過修改U-Boot的啟動參數(shù)引導啟動內(nèi)核-1。此時，內(nèi)核-1變?yōu)檎谑褂玫膬?nèi)核，內(nèi)核-0變?yōu)榕f版內(nèi)核。第二和第三個分區(qū)分別存儲根文件系統(tǒng)-0與輔助更新根文件系統(tǒng)-0的一個占用內(nèi)存小且功能相對簡單的Linux系統(tǒng)。這種根文件系統(tǒng)的分區(qū)方案與采用A/B分區(qū)雙備份的模式相比，盡管在系統(tǒng)的穩(wěn)定性上有所下降并且更新算法相對復雜，但是該方案占用存儲空間小，可有效降低成本。隨后便是數(shù)據(jù)區(qū)與日志區(qū)，分別用來保存系統(tǒng)和應用的關鍵數(shù)據(jù)與運行日志。

4.2 內(nèi)核升級策略

假設新版本內(nèi)核的名稱為內(nèi)核-2，如圖3所示，在進行內(nèi)核升級之前，首先需要啟動Linux操作系統(tǒng)，提前將內(nèi)核-2下載至根文件系統(tǒng)-0之中。升級流程開始后，需將內(nèi)核所在EMMC分區(qū)掛載到根文件系統(tǒng)-0之下，然后使用內(nèi)核-2覆蓋內(nèi)核-1的內(nèi)容。如若不考慮升級失敗的情形，那么接下來就是在Linux環(huán)境下重寫U-Boot的內(nèi)核引導參數(shù)，將從內(nèi)核-0啟動改為從內(nèi)核-2啟動。最后重啟Linux，由U-Boot引導內(nèi)核-2啟動Linux操作系統(tǒng)。

然而，升級內(nèi)核并不能保證百分之百成功。為了使得內(nèi)核升級失敗后，能夠使得系統(tǒng)再次恢復正常使用狀態(tài)，本文額外設立了一個標志位F，其被保存在存儲器的某個地址空間，用來指示U-Boot進行內(nèi)核切換操作。在將內(nèi)核-2覆蓋內(nèi)核-1的同時，系統(tǒng)應同時將標志位F進行置位，表示下次啟動時，U-Boot會從內(nèi)核-2啟動Linux。若內(nèi)核-2啟動失敗，系統(tǒng)再次重啟，U-Boot仍然檢測到標志位F為1，那么U-Boot會自行改變啟動參數(shù)，從內(nèi)核-2啟動切換為從內(nèi)核-0啟動，恢復到原本正常的狀態(tài)。不管內(nèi)核是否成功升級，Linux最終會將標志位F清零，表示下次啟動時U-Boot會從引導當前使用的內(nèi)核啟動，不再選擇切換內(nèi)核啟動Linux系統(tǒng)。

4.3 根文件系統(tǒng)升級策略

為了節(jié)約存儲空間，本文在設計Linux根文件系統(tǒng)的升級方案時并沒有選擇A/B分區(qū)的方式，而是選擇在一個根文件系統(tǒng)上進行迭代升級。如圖4所示，首先將升級根文件系統(tǒng)的軟件包下載到根文件系統(tǒng)-0之中。由于根文件系統(tǒng)中不同的文件更新時所需的解決的依賴以及要求的狀態(tài)不同，所以對于不同文件的升級需要執(zhí)行的指令以及過程都存在差異。為了解決這個難題，本文提出在軟件升級包中額外包含一份“升級方案”來決定本次升級的具體實現(xiàn)。

具體地，升級過程存在兩種路徑：a.在當前運行的根文件系統(tǒng)中進行原地更新操作；b.啟用toolsys這個工具系統(tǒng)，將根文件系統(tǒng)-0掛載到toolsys下進行更新。toolsys是一個僅僅具備更新文件系統(tǒng)能力的小型Linux操作系統(tǒng)。采用第一種更新方案時應謹慎處理文件的依賴關系，及時停止依賴需要升級的文件運行的應用，防止系統(tǒng)功能異常的出現(xiàn)，該方法適合于少量非系統(tǒng)核心文件的更新；采用第二種升級方案則相對安全，不過執(zhí)行的更新步驟也要更加繁瑣，適合大量系統(tǒng)文件同時更新。如圖5所示。選用上述哪種方式升級根文件系統(tǒng)取決于更新的文件是否會影響Linux系統(tǒng)的正常運轉以及更新的文件規(guī)模大小。若升級失敗，則根據(jù)升級過程中記錄的日志進行反向操作，直到將根文件系統(tǒng)恢復原貌。

5 結語

OTA技術的出現(xiàn)與發(fā)展給傳統(tǒng)汽車行業(yè)注入了新的活力，通過OTA為汽車增加新功能拓展了汽車服務的邊界，也為汽車廠商創(chuàng)造了新的盈利模式。此外，OTA可以快速、有效地解決軟件故障和風險問題，使得汽車發(fā)生駕駛安全問題的風險大大降低。

本文提出了一種搭載Linux操作系統(tǒng)的域控制器OTA升級框架，并給出了具體的Linux內(nèi)核與根文件系統(tǒng)的升級方案，簡要探討了升級過程中可能存在的問題以及解決方法，對汽車域控制器OTA技術開發(fā)人員具有一定參考意義。

參考文獻：

[1]姜楠，姜姍姍，韓小鵬.汽車在線升級系統(tǒng)（OTA）開發(fā)淺析[J].時代汽車，2021（21）：11-12.

[2]南夕.OTA技術正在引領和改變汽車行業(yè)[J].產(chǎn)品可靠性報告，2022（1）：74-80.

[3]叢聰;孫瀟;史家濤.基于OTA場景的電控信息安全研究[J].電子技術與軟件工程，2020（18）：232-235

[4]武翔宇，趙德華，郝鐵亮.淺談汽車OTA的現(xiàn)狀與未來發(fā)展趨勢[J].汽車實用技術，2019（3）：214-216.

作者簡介：

劉曉冬，男，1995年生，研究方向為智能駕駛技術。