特斯拉的OTA升級過程大致可由幾個關(guān)鍵步驟描述。

1）OTA過程云端通過特斯拉自有的握手協(xié)議下發(fā)固件下載地址后，特斯拉中控屏上的cid-updater會從云端下載固件，進行解密并校驗其完整性

通過類似于A/B Update的方式，車內(nèi)其他強運算力的聯(lián)網(wǎng)組件（如IC、APE等）根據(jù)cid-updater提供的固件文件進行升級。

CID-updater還會負責(zé)根據(jù)固件包中的目錄信息與車輛配置做比照，據(jù)此產(chǎn)生release.tgz文件，并和升級軟件boot.img一同提供給網(wǎng)關(guān)。然后網(wǎng)關(guān)執(zhí)行上述升級軟件，更新在網(wǎng)關(guān)上連接的二十余個ECU。

備注：Tesla的OTA機制中的一些關(guān)鍵文件，boot.img和release.tgz，負責(zé)向ECU提供固件。 這些文件無法直接在特斯拉服務(wù)器發(fā)布的更新包中找到，關(guān)于如何從特斯拉的服務(wù)器獲取更新包以及汽車方面的整個更新過程仍然不清楚，這個過程仍未公開。

1）整車企業(yè)的云端：握手和固件包（FIRMWARE BUNDLE）

特斯拉有一個OTA框架，完成OTA程序需要這些模塊：

Message box

Firmware gathering

Job management

大多數(shù)模塊放在CID上的QtCar和QtCarServer中，作為云代理的一部分。 一旦建立了可信通道，代理就會設(shè)置一個端口，遠程服務(wù)器可以將消息直接推送到汽車。必要時將從服務(wù)器端消息框中提取未讀消息。 在OTA更新期間，這些代理主要用來傳遞信息，而不是執(zhí)行實際更新操作。

FOTA過程以消息開頭，開始的時候用帶有命令initiate_firmware_handshake的消息，收到消息后，代理會將握手命令發(fā)送到cid-updater，與服務(wù)器進行握手。 握手期間需要執(zhí)行以下步驟：

cid-updater把整車的硬件配置字符串和package_signature一起發(fā)送到遠程服務(wù)器，package_signature是根據(jù)整車ECU現(xiàn)有版本生成

整車企業(yè)的云端（固件服務(wù)器）將驗證該信息，根據(jù)當(dāng)前版本提供固件包（FIRMWARE BUNDLE），包括固件包的下載地址、校驗和和解密信息。 SquashFS包含除了Autopilot以外的其他所有ECU文件

固件包通過CDN加密渠道分發(fā)，cid-updater會進行下載、驗證和解密

一旦提供了合法固件，cid-updater根據(jù)汽車配置收集正確的文件，并將這些文件分發(fā)到汽車的ECU內(nèi)。 在OTA更新過程中，作業(yè)管理器負責(zé)向遠程服務(wù)器報告當(dāng)前狀態(tài)和錯誤信息， 每個更新作業(yè)都有一個用于跟蹤使用情況的作業(yè)ID。

2）車輛端：以太網(wǎng)連接的ECU

中控臺和儀表盤是特斯拉車中兩個主要的更新組建，都有一個名為cid-updater和ic-updater的updater守護進程，這些二進制文件之間共享了一些代碼，但這兩個守護進程的主要目的是不同的。

cid-updater負責(zé)在可靠的通信通道建立后與遠程服務(wù)器通信，獲取固件包，并提供必要的文件和信息作為輔助服務(wù)器，

ic-updater則專注于更新儀表盤本身?？蓪id-updater視為本地服務(wù)器，ic-updater視為遠程代理。

cid-updater和ic-updater都有一個名為command_service_listener的服務(wù)，此服務(wù)將打開一個端口，服務(wù)器可以執(zhí)行RPC直接調(diào)用代理上的函數(shù)。一旦準備好所有內(nèi)容，代理將使用此服務(wù)獲取客戶端的更新代理。服務(wù)器使用以下過程控制遠程代理：

1.遠程單元將停止所有其他工作并準備好gostaged，會嘗試下載目標(biāo)的文件包。

2.本地服務(wù)器啟動HTTP服務(wù)器并提供更新文件，文件準備好后，將通知遠程代理。

3.遠程代理下載更新文件，下載文件并驗證其簽名后，更新程序?qū)⑦M行分段

4.將更新文件刷入ECU，對于儀表盤來說

假設(shè)當(dāng)前在Part A運行

將新的rootfs圖像和DTB刷入 Part B

將新的Kernal寫入Part B

將主引導(dǎo)鏈和恢復(fù)引導(dǎo)鏈切換到Part B

檢查引導(dǎo)鏈以確保下次引導(dǎo)是可接受的

完成所有這些操作后，設(shè)備將處于暫停和非活動狀態(tài)。

5.經(jīng)過最后的準備工作后，設(shè)備將重新啟動：代理和服務(wù)器之間將持續(xù)連接，服務(wù)器可以獲得有關(guān)當(dāng)前更新狀態(tài)的最新信息

3）車輛端：網(wǎng)關(guān)轉(zhuǎn)換的CAN總線ECU

這些ECU的更新文件存儲在文件夾（squashfs-root）/ deploy / seed_artifacts_v2中 ：boot.img、release_version.txt 、version_map2.tsv和Signed_metadata_map.tsv、internal_option_defaults.tsv、ECUNAME/, like esp/, gtw/ etc

boot.img文件在升級時運行，并從release.tgz讀取固件文件。 boot.img包含一個簽名，在其原始EOF之后填充。 發(fā)送更新命令時，將檢查此簽名是否通過公鑰驗證。

Boot.img中的一個重要步驟是讀取固件包release.tgz，包含網(wǎng)關(guān)用來更新相應(yīng)ECU的所有文件，每個ECU只有一個固件文件。 從ECUNAME / PROVIDERID / ECUFWNAME.hex復(fù)制特定的固件文件。 在打包tar文件時，cid-updater從網(wǎng)關(guān)獲取ECU信息和汽車信息，并根據(jù)signed_metadata_map.tsv中的表選擇正確的PROVIDERID，文件格式如下：

以下是刷寫ECU的關(guān)鍵步驟：

1.制作固件包，cid-updater將從網(wǎng)關(guān)獲得最新的ECU硬件信息。對于每個ECU，cid-updater將搜索signed_metadata_map.tsv以查看哪條線與當(dāng)前汽車具有相同的Requirements字段。找到后，它會將PATH_TO_FILE中的文件復(fù)制到名為New_name的tar文件中。為了簡化更新包，cid-updater只會將signed_metadata_map.tsv中的相應(yīng)行復(fù)制到release.tgz中具有相同名稱的文件中。

2.根據(jù)更新模式，在SD卡中創(chuàng)建UPD文件, updater讀取此文件以了解其當(dāng)前狀態(tài)。

3.更新程序boot.img上傳到SD卡，并使用文件名重新啟動。

當(dāng)updater執(zhí)行時，未修改的boot.img將每個文件讀入內(nèi)存，使用signed_metadata_map.tsv中相應(yīng)行中的前幾個字段填充，并使用符號值和啟動時保存的公鑰驗證其簽名.IMG。更新程序一旦找到不正確的固件文件就會退出，更新將導(dǎo)致失敗。所有簽名和散列算法都使用帶有SHA512的Ed25519，并仔細選擇所有公鑰和常量。