OTA更新：對云中服務器的要求

制造“聯(lián)網(wǎng)汽車？現(xiàn)實情況是，汽車行業(yè)需要創(chuàng)建一個安全的管道，連接到汽車中的所有設備，并實現(xiàn)無線（OTA）更新。

為了使“互聯(lián)汽車”成為現(xiàn)實，汽車行業(yè)需要創(chuàng)建一個安全的管道，連接到汽車中的所有設備，并實現(xiàn)無線（OTA）更新。如今，汽車制造商提供許多車型，這些車型具有各種各樣的選項和設備包，可能需要更換或升級。對于現(xiàn)場車輛處理這些 OTA 更新的服務器有何影響？

為了發(fā)送正確的更新，服務器必須準確了解每輛車中所有設備的當前詳細信息。每個型號或子型號可能有多種選項和設備包可供選擇。其中一些選項或包裝可能在生產(chǎn)過程的后期選擇，甚至在區(qū)域分銷或經(jīng)銷商庫存中進行后期生產(chǎn)。即使在售后，設備也可以更換或升級，有時通過經(jīng)銷商網(wǎng)絡，有時通過零件供應渠道（無論是通過獨立機械師還是家庭機械師）。

所有這些都增加了汽車OTA環(huán)境的復雜性?？紤]一個擁有三種不同型號汽車的汽車品牌。如果這些型號中的每一個都有五個不同的子模型，并且每個子模型都有十個不同的裝飾包，那么我們突然面臨 150 種不同的終端設備可能組合。

在表現(xiàn)出這種復雜程度的行業(yè)中，最好的方法是雙向數(shù)據(jù)管道，該管道為每個單獨的設備標準化協(xié)議和OTA相關行為。如果每個設備都可以報告其存在、正在運行的軟件、狀態(tài)和 OTA 相關功能，那么服務器就可以自動跟蹤和區(qū)分各種車輛配置。

數(shù)據(jù)管道的 eSync 規(guī)范提供此功能。在 eSync 體系結(jié)構(gòu)中，為每個設備編寫一個代理。這些代理考慮了所有不同設備的特征，同時為數(shù)據(jù)管道實現(xiàn)了一組標準的行為和協(xié)議。任何兩個設備可能具有不同的資源。例如，與安全帶張緊器相比，ADAS高性能計算平臺將具有更多的處理能力，更多的內(nèi)存和更復雜的操作系統(tǒng)。使用標準協(xié)議，這兩個設備的代理可以報告其不同的功能，使服務器能夠使用不同的技術(shù)為這兩個設備準備更新。

同樣，每輛車中的客戶端使用一組標準的行為和協(xié)議與云中的服務器相對應。標準客戶端（車輛）行為之一是向服務器報告其所有代理的完整“樹”，并在發(fā)生更改時更新服務器上的信息。

此過程完全自動化了最新車輛數(shù)據(jù)庫的維護。在每時每刻，服務器在其車隊中每輛車的每臺設備上都有最新信息。維護數(shù)據(jù)庫沒有管理負擔 - 如果每個客戶端的配置或設備樹發(fā)生更改，則每個客戶端都會自行更新數(shù)據(jù)庫。

汽車子系統(tǒng)的各種設備通常來自多個供應商，必須協(xié)同工作。標準化有助于確保所有設備都實施相同的 OTA 方法，以便可以順利高效地訪問、更新或回滾它們。標準化使認證機構(gòu)具有一定程度的透明度，以幫助政府為多個汽車供應商實施的OTA機制的安全性帶來秩序。如果每個供應商都追求自己專有的OTA方法，那么驗證將成為一個非常困難的命題。

任何符合 eSync 標準的服務器都將符合標準功能行為和消息傳遞協(xié)議。在此級別提供標準化可實現(xiàn)跨公共云和私有云的可移植性，并促進在多個地理市場中實現(xiàn)一致的功能。eSync服務器已在Amazon AWS，百度，Microsoft Azure和騰訊公共云以及OEM專有服務器上實施。根據(jù)當?shù)卣?，在多個地理區(qū)域銷售的汽車可以通過當?shù)氐姆掌鬟M行更新，即使服務器軟件托管在不同的云上或來自不同的供應商。..。..只要它符合電子同步標準。

eSync 標準提供了一種分布式策略機制?？梢栽?eSync 服務器中為每個 OTA 活動設置策略，在每個軟件組件包中設置策略以識別軟件版本中與多個設備的依賴關系，eSync 客戶端中的車輛策略以及駐留在該設備的 eSync 代理中的每個邊緣 ECU 的策略。這種分布式策略可幫助 OEM 針對不同的地理位置和政府要求完善和定制其 OTA 機制。它甚至可以優(yōu)雅地避免OEM的尷尬情況，當服務器驅(qū)動OTA更新活動與維修車庫中通過診斷測試儀提供的更新沖突時。如果在車庫中提供的更新是針對未進入 OTA 活動的特定修復完成的，則設備策略可以拒絕 OTA 更新活動，直到達到 ECU 中商店更新軟件的到期日期。

審核編輯：郭婷