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

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

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

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

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

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

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

Message box

Firmware gathering

Job management

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

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

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

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

固件包通過(guò)CDN加密渠道分發(fā)，cid-updater會(huì)進(jìn)行下載、驗(yàn)證和解密

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

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

中控臺(tái)和儀表盤(pán)是特斯拉車(chē)中兩個(gè)主要的更新組建，都有一個(gè)名為cid-updater和ic-updater的updater守護(hù)進(jìn)程，這些二進(jìn)制文件之間共享了一些代碼，但這兩個(gè)守護(hù)進(jìn)程的主要目的是不同的。

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

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

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

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

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

3.遠(yuǎn)程代理下載更新文件，下載文件并驗(yàn)證其簽名后，更新程序?qū)⑦M(jìn)行分段

4.將更新文件刷入ECU，對(duì)于儀表盤(pán)來(lái)說(shuō)

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

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

將新的Kernal寫(xiě)入Part B

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

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

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

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

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

這些ECU的更新文件存儲(chǔ)在文件夾（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文件在升級(jí)時(shí)運(yùn)行，并從release.tgz讀取固件文件。 boot.img包含一個(gè)簽名，在其原始EOF之后填充。 發(fā)送更新命令時(shí)，將檢查此簽名是否通過(guò)公鑰驗(yàn)證。

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

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

1.制作固件包，cid-updater將從網(wǎng)關(guān)獲得最新的ECU硬件信息。對(duì)于每個(gè)ECU，cid-updater將搜索signed_metadata_map.tsv以查看哪條線與當(dāng)前汽車(chē)具有相同的Requirements字段。找到后，它會(huì)將PATH_TO_FILE中的文件復(fù)制到名為New_name的tar文件中。為了簡(jiǎn)化更新包，cid-updater只會(huì)將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)。

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