OTA更新的設(shè)計(jì)權(quán)衡和經(jīng)驗(yàn)教訓(xùn)

抽象

許多嵌入式系統(tǒng)部署在人類操作員難以訪問或不切實(shí)際的地方。對(duì)于物聯(lián)網(wǎng) （IoT） 應(yīng)用尤其如此，這些應(yīng)用通常以較大數(shù)量部署且電池壽命有限。一些例子是監(jiān)視人或機(jī)器健康狀況的嵌入式系統(tǒng)。這些挑戰(zhàn)，加上快速的軟件生命周期，導(dǎo)致許多系統(tǒng)需要支持無線（OTA）更新。OTA更新將嵌入式系統(tǒng)的微控制器或微處理器上的軟件替換為新軟件。雖然許多人非常熟悉移動(dòng)設(shè)備上的OTA更新，但在資源受限的系統(tǒng)上進(jìn)行設(shè)計(jì)和實(shí)施會(huì)帶來許多不同的挑戰(zhàn)。在本文中，我們將介紹用于OTA更新的幾種不同的軟件設(shè)計(jì)，并討論它們的權(quán)衡。我們將看到如何在OTA更新軟件中利用兩個(gè)超低功耗微控制器的硬件功能。

積木

服務(wù)器和客戶端

OTA 更新將設(shè)備上的當(dāng)前軟件替換為新軟件，新軟件將以無線方式下載。在嵌入式系統(tǒng)中，運(yùn)行此軟件的設(shè)備通常是微控制器。微控制器是一種小型計(jì)算設(shè)備，具有有限的內(nèi)存、速度和功耗。微控制器通常包含一個(gè)微處理器（內(nèi)核）以及用于特定操作（外設(shè)）的數(shù)字硬件模塊。在有源模式下，功耗通常為30 μA/MHz至40 μA/MHz的超低功耗微控制器非常適合此類應(yīng)用。在這些微控制器上使用特定的硬件外設(shè)并將其置于低功耗模式是OTA更新軟件設(shè)計(jì)的重要組成部分。圖 1 顯示了可能需要 OTA 更新的嵌入式系統(tǒng)示例。在這里，我們看到一個(gè)與無線電和傳感器連接的微控制器，該微控制器可用于物聯(lián)網(wǎng)應(yīng)用，該應(yīng)用使用傳感器收集有關(guān)環(huán)境的數(shù)據(jù)，并使用無線電定期報(bào)告。系統(tǒng)的這一部分稱為邊緣節(jié)點(diǎn)或客戶端，是 OTA 更新的目標(biāo)。系統(tǒng)的另一部分稱為云或服務(wù)器，是新軟件的提供者。服務(wù)器和客戶端使用收發(fā)器（無線電）通過無線連接進(jìn)行通信。

圖 1.示例嵌入式系統(tǒng)中的服務(wù)器/客戶端體系結(jié)構(gòu)。

是什么造就了軟件應(yīng)用程序？

OTA更新過程的大部分是將新軟件從服務(wù)器傳輸?shù)娇蛻舳说牟僮?。該軟件在從源格式轉(zhuǎn)換為二進(jìn)制格式后，作為字節(jié)序列進(jìn)行傳輸。轉(zhuǎn)換過程編譯源代碼文件（例如，c，cpp），將它們一起鏈接到一個(gè)可執(zhí)行文件（例如，exe，elf），然后將可執(zhí)行文件轉(zhuǎn)換為可移植的二進(jìn)制文件格式（例如，bin，hex）。在較高級(jí)別上，這些文件格式包含屬于微控制器中存儲(chǔ)器特定地址的字節(jié)序列。通常，我們將通過無線鏈路發(fā)送的信息概念化為數(shù)據(jù)，例如更改系統(tǒng)狀態(tài)的命令或系統(tǒng)收集的傳感器數(shù)據(jù)。在OTA更新的情況下，數(shù)據(jù)是二進(jìn)制格式的新軟件。在許多情況下，二進(jìn)制文件太大，無法在從服務(wù)器到客戶端的單個(gè)傳輸中發(fā)送，這意味著二進(jìn)制文件將需要放入單獨(dú)的數(shù)據(jù)包中，此過程稱為打包。為了更好地可視化此過程，圖 2 演示了不同版本的軟件將如何生成不同的二進(jìn)制文件，從而在 OTA 更新期間發(fā)送不同的數(shù)據(jù)包。在這個(gè)簡單的示例中，每個(gè)數(shù)據(jù)包包含 8 個(gè)字節(jié)的數(shù)據(jù)，前 4 個(gè)字節(jié)表示客戶端內(nèi)存中用于存儲(chǔ)接下來 4 個(gè)字節(jié)的地址。

圖 2.軟件應(yīng)用程序的二進(jìn)制轉(zhuǎn)換和打包過程。

主要挑戰(zhàn)

基于對(duì) OTA 更新過程的這種高級(jí)描述，OTA 更新解決方案必須解決三大挑戰(zhàn)。第一個(gè)挑戰(zhàn)與記憶有關(guān)。軟件解決方案必須將新的軟件應(yīng)用程序組織到客戶端設(shè)備的易失性或非易失性存儲(chǔ)器中，以便在更新過程完成時(shí)可以執(zhí)行它。該解決方案必須確保將以前版本的軟件保留為備用應(yīng)用程序，以防新軟件出現(xiàn)問題。此外，我們必須在重置和電源周期之間保留客戶端設(shè)備的狀態(tài)，例如我們當(dāng)前正在運(yùn)行的軟件版本以及它在內(nèi)存中的位置。第二個(gè)主要挑戰(zhàn)是溝通。新軟件必須以離散數(shù)據(jù)包的形式從服務(wù)器發(fā)送到客戶端，每個(gè)數(shù)據(jù)包都針對(duì)客戶端內(nèi)存中的特定地址。打包方案、數(shù)據(jù)包結(jié)構(gòu)和用于傳輸數(shù)據(jù)的協(xié)議都必須在軟件設(shè)計(jì)中加以考慮。最后一個(gè)主要挑戰(zhàn)是安全。隨著新軟件從服務(wù)器無線發(fā)送到客戶端，我們必須確保服務(wù)器是受信任的一方。此安全質(zhì)詢稱為身份驗(yàn)證。我們還必須確保新軟件對(duì)任何觀察者都進(jìn)行混淆，因?yàn)樗赡馨舾行畔?。此安全挑?zhàn)稱為機(jī)密性。安全的最后一個(gè)要素是完整性，確保新軟件在無線傳輸時(shí)不會(huì)損壞。

第二階段引導(dǎo)加載程序 （SSBL）

了解引導(dǎo)順序

主引導(dǎo)加載程序是永久駐留在只讀存儲(chǔ)器中的微控制器上的軟件應(yīng)用程序。主引導(dǎo)加載程序所在的內(nèi)存區(qū)域稱為信息空間，有時(shí)用戶無法訪問。此應(yīng)用程序在每次發(fā)生重置時(shí)執(zhí)行，通常執(zhí)行一些基本的硬件初始化，并可能將用戶軟件加載到內(nèi)存中。但是，如果微控制器包含片上非易失性存儲(chǔ)器（如閃存），則引導(dǎo)加載程序不需要執(zhí)行任何加載，只需將控制權(quán)轉(zhuǎn)移到閃存中的程序即可。如果主引導(dǎo)加載程序不支持 OTA 更新，則必須具有第二階段引導(dǎo)加載程序。與主引導(dǎo)加載程序一樣，SSBL 將在每次發(fā)生重置時(shí)運(yùn)行，但將實(shí)現(xiàn) OTA 更新過程的一部分。此引導(dǎo)順序如圖 3 所示。在本節(jié)中，我們將描述為什么需要第二階段引導(dǎo)加載程序，以及指定此應(yīng)用程序的角色如何成為關(guān)鍵的設(shè)計(jì)權(quán)衡。

圖 3.使用 SSBL 的內(nèi)存映射和引導(dǎo)流的示例。

經(jīng)驗(yàn)教訓(xùn)：始終擁有 SSBL

從概念上講，省略SSBL并將所有OTA更新功能放入用戶應(yīng)用程序中似乎更簡單，因?yàn)樗鼘⒃试S將現(xiàn)有的軟件框架，操作系統(tǒng)和設(shè)備驅(qū)動(dòng)程序無縫地用于OTA過程。選擇此方法的系統(tǒng)的內(nèi)存映射和引導(dǎo)順序如圖 4 所示。

圖 4.不帶 SSBL 的內(nèi)存映射和引導(dǎo)流程示例

應(yīng)用程序 A 是部署在現(xiàn)場微控制器上的原始應(yīng)用程序。此應(yīng)用程序包含與 OTA 更新相關(guān)的軟件，當(dāng)服務(wù)器請求時(shí)，該軟件可用于下載應(yīng)用程序 B。在此下載完成并且應(yīng)用程序 B 經(jīng)過驗(yàn)證后，應(yīng)用程序 A 將通過對(duì)應(yīng)用程序 B 的重置處理程序執(zhí)行分支指令，將控制權(quán)移交給應(yīng)用程序 B。重置處理程序是一小段代碼，它是軟件應(yīng)用程序的入口點(diǎn)，并在重置時(shí)運(yùn)行。在這種情況下，通過執(zhí)行分支來模擬重置，這相當(dāng)于函數(shù)調(diào)用。這種方法有兩個(gè)主要問題：

許多嵌入式軟件應(yīng)用程序采用實(shí)時(shí)操作系統(tǒng)（RTOS），這允許將軟件拆分為并發(fā)任務(wù)，每個(gè)任務(wù)在系統(tǒng)中具有不同的職責(zé)。例如，圖1所示的應(yīng)用程序可能具有讀取傳感器、對(duì)傳感器數(shù)據(jù)運(yùn)行算法以及與無線電接口的RTOS任務(wù)。RTOS本身始終處于活動(dòng)狀態(tài)，并負(fù)責(zé)根據(jù)異步事件或基于時(shí)間的特定延遲在這些任務(wù)之間切換。因此，從 RTOS 任務(wù)分支到新程序是不安全的，因?yàn)槠渌蝿?wù)將繼續(xù)在后臺(tái)運(yùn)行。使用實(shí)時(shí)操作系統(tǒng)終止程序的唯一安全方法是通過重置。

根據(jù)圖 4，解決上述問題的解決方案是將主引導(dǎo)加載程序分支到應(yīng)用程序 B 而不是應(yīng)用程序 A。但是，在某些微控制器上，主引導(dǎo)加載程序始終運(yùn)行具有其中斷向量表 （IVT） 的程序，IVT 是描述中斷處理功能的應(yīng)用程序的關(guān)鍵部分，位于地址 0。這意味著需要某種形式的 IVT 重定位才能將重置映射到應(yīng)用程序 B。如果在 IVT 重新定位期間發(fā)生電源循環(huán)，則可能會(huì)使系統(tǒng)處于永久中斷狀態(tài)。

通過將 SSBL 修復(fù)到地址 0 可以緩解這些問題，如圖 3 所示。由于 SSBL 是非實(shí)時(shí)操作系統(tǒng)程序，因此它可以安全地分支到新的應(yīng)用程序。無需擔(dān)心電源循環(huán)會(huì)將系統(tǒng)置于災(zāi)難性狀態(tài)，因?yàn)榈刂?0 處的 SSBL IVT 永遠(yuǎn)不會(huì)重新定位。

設(shè)計(jì)權(quán)衡：SSBL 的作用

我們花了很多時(shí)間討論SSBL及其與應(yīng)用軟件的關(guān)系，但是這個(gè)SSBL程序有什么作用呢？至少，程序必須確定當(dāng)前應(yīng)用程序是什么（它從哪里開始），然后分支到該地址。微控制器存儲(chǔ)器中各種應(yīng)用的位置通常保存在目錄（ToC）中，如圖3所示。這是持久內(nèi)存的共享區(qū)域，SSBL 和應(yīng)用程序軟件都使用它來相互通信。OTA 更新過程完成后，將使用新的應(yīng)用程序信息更新 ToC。部分 OTA 更新功能也可以推送到 SSBL。在開發(fā)OTA更新軟件時(shí)，決定哪些部分是一個(gè)重要的設(shè)計(jì)決策。上述最小SSBL將非常簡單，易于驗(yàn)證，并且在應(yīng)用程序的生命周期內(nèi)很可能不需要修改。但是，這意味著每個(gè)應(yīng)用程序必須負(fù)責(zé)下載和驗(yàn)證下一個(gè)應(yīng)用程序。這可能導(dǎo)致無線電堆棧、設(shè)備固件和 OTA 更新軟件方面的代碼重復(fù)。另一方面，我們可以選擇將整個(gè)OTA更新過程推送到SSBL。在這種情況下，應(yīng)用程序只需在 ToC 中設(shè)置一個(gè)標(biāo)志來請求更新，然后執(zhí)行重置。然后，SSBL 執(zhí)行下載序列和驗(yàn)證過程。這將最大限度地減少代碼重復(fù)并簡化特定于應(yīng)用程序的軟件。但是，這帶來了一個(gè)新的挑戰(zhàn)，即可能必須更新SSBL本身（即更新更新代碼）。最后，決定在SSBL中放置什么功能將取決于客戶端設(shè)備的內(nèi)存約束，下載的應(yīng)用程序之間的相似性以及OTA更新軟件的可移植性。

設(shè)計(jì)權(quán)衡：緩存和壓縮

OTA更新軟件的另一個(gè)關(guān)鍵設(shè)計(jì)決策將是如何在OTA更新過程中在內(nèi)存中組織傳入的應(yīng)用程序。微控制器上通常存在的兩種類型的存儲(chǔ)器是非易失性存儲(chǔ)器（例如，閃存）和易失性存儲(chǔ)器（例如，SRAM）。閃存將用于存儲(chǔ)應(yīng)用程序的程序代碼和只讀數(shù)據(jù)，以及其他系統(tǒng)級(jí)數(shù)據(jù)，如ToC和事件日志。SRAM將用于存儲(chǔ)軟件應(yīng)用程序的可修改部分，例如非恒定全局變量和堆棧。圖2所示的軟件應(yīng)用程序二進(jìn)制文件僅包含位于非易失性存儲(chǔ)器中的程序部分。應(yīng)用程序?qū)⒃趩?dòng)例程期間初始化屬于易失性內(nèi)存的部分。

在OTA更新過程中，每次客戶端設(shè)備從服務(wù)器接收到包含部分二進(jìn)制文件的數(shù)據(jù)包時(shí)，它都會(huì)存儲(chǔ)在SRAM中。此數(shù)據(jù)包可以是壓縮的，也可以是未壓縮的。壓縮應(yīng)用程序二進(jìn)制文件的好處是，它的大小會(huì)更小，允許發(fā)送更少的數(shù)據(jù)包，并且在下載過程中SRAM中存儲(chǔ)它們所需的空間更少。這種方法的缺點(diǎn)是壓縮和解壓縮會(huì)增加更新過程的額外處理時(shí)間，并且必須在OTA更新軟件中捆綁與壓縮相關(guān)的代碼。

由于新的應(yīng)用軟件屬于閃存，但在更新過程中進(jìn)入SRAM，因此OTA更新軟件需要在更新過程中的某個(gè)時(shí)刻對(duì)閃存執(zhí)行寫入。將新應(yīng)用程序臨時(shí)存儲(chǔ)在 SRAM 中稱為緩存。在高層次上，OTA更新軟件可以采用三種不同的方法來緩存。

無緩存：每次包含新應(yīng)用程序的一部分的數(shù)據(jù)包到達(dá)時(shí)，請將其寫入閃存中的目的地。該方案非常簡單，可以最大限度地減少OTA更新軟件中的邏輯量，但它要求完全擦除新應(yīng)用程序的閃存區(qū)域。此方法會(huì)磨損閃存并增加開銷。

部分緩存：保留一個(gè) SRAM 區(qū)域進(jìn)行緩存，當(dāng)新數(shù)據(jù)包到達(dá)時(shí)，將它們存儲(chǔ)在該區(qū)域中。當(dāng)區(qū)域填滿時(shí)，通過將數(shù)據(jù)寫入閃存來清空它。如果數(shù)據(jù)包無序到達(dá)，或者新的應(yīng)用程序二進(jìn)制文件中存在間隙，這可能會(huì)變得復(fù)雜，因?yàn)樾枰环N將SRAM地址映射到閃存地址的方法。一種策略是讓高速緩存充當(dāng)部分閃存的鏡像。閃存被劃分為稱為頁面的小區(qū)域，這是擦除的最小區(qū)域。由于這種自然劃分，一個(gè)好的方法是在SRAM中緩存一頁閃存，當(dāng)它填滿或下一個(gè)數(shù)據(jù)包屬于另一頁時(shí)，通過寫入該頁面閃存來刷新緩存。

完全緩存：在OTA更新過程中將整個(gè)新應(yīng)用程序存儲(chǔ)在SRAM中，并且僅在從服務(wù)器完全下載后將其寫入閃存。這種方法克服了以前方法的缺點(diǎn)，最大限度地減少了對(duì)閃存的寫入次數(shù)，并避免了OTA更新軟件中的復(fù)雜緩存邏輯。但是，這將限制正在下載的新應(yīng)用程序的大小，因?yàn)橄到y(tǒng)上的可用SRAM量通常遠(yuǎn)小于可用閃存量。

圖 5.使用SRAM到一頁高速緩存閃存。

圖5說明了OTA更新期間部分緩存的第二種方案，其中放大了圖3和圖4中應(yīng)用A的閃存部分，并說明了SSBL的SRAM的功能存儲(chǔ)器圖。圖中顯示了一個(gè) 2 kB 的閃存頁面大小示例。最終，此設(shè)計(jì)決策將根據(jù)新應(yīng)用程序的大小和 OTA 更新軟件允許的復(fù)雜性來確定。

安全與通信

設(shè)計(jì)權(quán)衡：軟件與協(xié)議

OTA 更新解決方案還必須解決安全性和通信問題。許多系統(tǒng)（如圖 1 所示）將在硬件和軟件中實(shí)現(xiàn)通信協(xié)議，用于正常（與 OTA 更新相關(guān)）的系統(tǒng)行為，如交換傳感器數(shù)據(jù)。這意味著在服務(wù)器和客戶端之間已經(jīng)建立了一種（可能是安全的）無線通信方法。如圖 1 所示的嵌入式系統(tǒng)可能使用的通信協(xié)議包括低功耗藍(lán)牙 （BLE） 或 6LoWPAN。有時(shí)，這些協(xié)議支持安全性和數(shù)據(jù)交換，OTA 更新軟件可能能夠在 OTA 更新過程中利用這些支持。

OTA更新軟件中必須內(nèi)置的通信功能量最終將取決于現(xiàn)有通信協(xié)議提供的抽象程度。現(xiàn)有的通信協(xié)議具有在服務(wù)器和客戶端之間發(fā)送和接收文件的功能，OTA更新軟件可以簡單地利用這些工具進(jìn)行下載過程。但是，如果通信協(xié)議更原始，并且僅具有發(fā)送原始數(shù)據(jù)的功能，則OTA更新軟件可能需要執(zhí)行打包并提供元數(shù)據(jù)以及新的應(yīng)用程序二進(jìn)制文件。這也適用于安全挑戰(zhàn)。如果通信協(xié)議不支持，則 OTA 更新軟件可能有責(zé)任解密通過無線方式發(fā)送的字節(jié)以保持機(jī)密性。

總之，在OTA更新軟件中構(gòu)建自定義數(shù)據(jù)包結(jié)構(gòu)，服務(wù)器/客戶端同步，加密和密鑰交換等設(shè)施將根據(jù)系統(tǒng)通信協(xié)議提供的內(nèi)容以及對(duì)安全性和健壯性的要求來確定。在下一節(jié)中，我們將提出一個(gè)完整的安全解決方案，解決前面介紹的所有挑戰(zhàn)，我們將展示如何在此解決方案中利用微控制器的加密硬件外設(shè)。

解決安全挑戰(zhàn)

我們的安全解決方案需要對(duì)通過無線方式發(fā)送的新應(yīng)用程序保密，檢測新應(yīng)用程序中的任何損壞，并驗(yàn)證新應(yīng)用程序是否從受信任的服務(wù)器而不是惡意方發(fā)送。這些挑戰(zhàn)可以使用加密（加密）操作來解決。具體而言，可以在安全解決方案中使用兩種稱為加密和哈希的加密操作。加密將使用客戶端和服務(wù)器之間的共享密鑰（密碼）來混淆以無線方式發(fā)送的數(shù)據(jù)。微控制器的加密硬件加速器可能支持的特定類型的加密稱為 AES-128 或 AES-256，具體取決于密鑰大小。與加密的數(shù)據(jù)一起，服務(wù)器可以發(fā)送摘要以確保沒有損壞。摘要是通過對(duì)數(shù)據(jù)包進(jìn)行哈希處理來生成的，數(shù)據(jù)包是一種不可逆的數(shù)學(xué)函數(shù)，可生成唯一的代碼。如果在服務(wù)器創(chuàng)建消息或摘要后修改了消息或摘要的任何部分，例如在無線通信期間翻轉(zhuǎn)了一個(gè)位，則客戶端在對(duì)數(shù)據(jù)包執(zhí)行相同的哈希函數(shù)并比較摘要時(shí)會(huì)注意到此修改。微控制器的加密硬件加速器可能支持的特定類型的哈希是 SHA-256。圖6顯示了微控制器中加密硬件外設(shè)的框圖，其中OTA更新軟件位于Cortex-M4應(yīng)用層中。此圖還顯示了對(duì)外設(shè)中受保護(hù)密鑰存儲(chǔ)的支持，可在 OTA 更新軟件解決方案中利用該支持來安全地存儲(chǔ)客戶端的密鑰。

圖 6.ADuCM4050上加密加速器的硬件框圖。

解決身份驗(yàn)證最終挑戰(zhàn)的常用技術(shù)是使用非對(duì)稱加密。對(duì)于此操作，服務(wù)器將生成一個(gè)公鑰-私鑰對(duì)。私鑰僅由服務(wù)器知道，公鑰由客戶端知道。使用私鑰，服務(wù)器可以生成給定數(shù)據(jù)塊的簽名，例如將通過無線方式發(fā)送的數(shù)據(jù)包的摘要。簽名將發(fā)送到客戶端，客戶端可以使用公鑰驗(yàn)證簽名。這使客戶端能夠確認(rèn)郵件是從服務(wù)器發(fā)送的，而不是從惡意第三方發(fā)送的。該序列如圖 7 所示，實(shí)心箭頭表示函數(shù)輸入/輸出，虛線箭頭表示通過無線方式發(fā)送的信息。

圖 7.使用非對(duì)稱加密對(duì)消息進(jìn)行身份驗(yàn)證。

大多數(shù)微控制器沒有用于這些非對(duì)稱加密操作的硬件加速器，但它們可以使用Micro-ECC等軟件庫來實(shí)現(xiàn)，這些軟件庫專門針對(duì)資源受限的設(shè)備。該庫需要用戶定義的隨機(jī)數(shù)生成函數(shù)，該函數(shù)可以使用微控制器上的真隨機(jī)數(shù)生成器硬件外設(shè)來實(shí)現(xiàn)。雖然這些非對(duì)稱加密操作解決了OTA更新期間的信任挑戰(zhàn)，但它們在處理時(shí)間方面成本高昂，并且需要與數(shù)據(jù)一起發(fā)送簽名，這會(huì)增加數(shù)據(jù)包大小。我們可以在下載結(jié)束時(shí)執(zhí)行一次此檢查，使用最終數(shù)據(jù)包的摘要或整個(gè)新軟件應(yīng)用程序的摘要，但這將允許第三方將不受信任的軟件下載到客戶端，這并不理想。理想情況下，我們希望驗(yàn)證我們收到的每個(gè)數(shù)據(jù)包是否來自受信任的服務(wù)器，而不會(huì)每次都有簽名的開銷。這可以使用哈希鏈來實(shí)現(xiàn)。

哈希鏈將我們在本節(jié)中討論的加密概念合并到一系列數(shù)據(jù)包中，以在數(shù)學(xué)上將它們聯(lián)系在一起。如圖 8 所示，第一個(gè)數(shù)據(jù)包（數(shù)字 0）包含下一個(gè)數(shù)據(jù)包的摘要。第一個(gè)數(shù)據(jù)包的有效負(fù)載不是實(shí)際的軟件應(yīng)用程序數(shù)據(jù)，而是簽名。第二個(gè)數(shù)據(jù)包（數(shù)字 1）有效負(fù)載包含二進(jìn)制文件的一部分，以及第三個(gè)數(shù)據(jù)包的摘要（數(shù)字 2）?？蛻舳蓑?yàn)證第一個(gè)數(shù)據(jù)包中的簽名，并緩存摘要 H0 以供以后使用。當(dāng)?shù)诙€(gè)數(shù)據(jù)包到達(dá)時(shí)，客戶端對(duì)有效負(fù)載進(jìn)行哈希處理，并將其與 H0 進(jìn)行比較。如果它們匹配，則客戶端可以確定此后續(xù)數(shù)據(jù)包來自受信任的服務(wù)器，而無需執(zhí)行簽名檢查的所有開銷。生成此鏈的昂貴任務(wù)留給服務(wù)器，客戶端必須在每個(gè)數(shù)據(jù)包到達(dá)時(shí)簡單地緩存和散列，以確保數(shù)據(jù)包到達(dá)時(shí)未損壞，完整性并經(jīng)過身份驗(yàn)證。

圖 8.將哈希鏈應(yīng)用于數(shù)據(jù)包序列。

實(shí)驗(yàn)設(shè)置

解決本文提到的存儲(chǔ)器、通信和安全設(shè)計(jì)挑戰(zhàn)的超低功耗微控制器是ADuCM3029和ADuCM4050。這些微控制器包含為OTA更新而討論的硬件外設(shè)，例如閃存、SRAM、加密加速器和真隨機(jī)數(shù)生成器。這些微控制器的設(shè)備系列包 （DFP） 為在這些設(shè)備上構(gòu)建 OTA 更新解決方案提供了軟件支持。DFP 包含外設(shè)驅(qū)動(dòng)程序，這些驅(qū)動(dòng)程序?yàn)槭褂糜布峁┝撕唵?、靈活的接口。

硬件配置

為了驗(yàn)證和確認(rèn)此處討論的概念，使用ADuCM4050創(chuàng)建了OTA更新軟件參考設(shè)計(jì)。對(duì)于客戶端，ADuCM4050 EZ-KIT使用收發(fā)器子板馬蹄形連接器連接到ADF7242?？蛻舳嗽O(shè)備如圖 9 左側(cè)所示。對(duì)于服務(wù)器，開發(fā)了一個(gè)在Windows PC上運(yùn)行的Python應(yīng)用程序。Python應(yīng)用通過串行端口與另一個(gè)ADuCM4050 EZ-KIT通信，該ADUCM4050 EZ-KIT也以與客戶端相同的排列方式連接了ADF7242。但是，圖9中的正確EZ-KIT不執(zhí)行OTA更新邏輯，只是將從ADF7242接收到的數(shù)據(jù)包中繼到Python應(yīng)用程序。

圖 9.實(shí)驗(yàn)性硬件設(shè)置。

軟件組件

軟件參考設(shè)計(jì)對(duì)客戶端設(shè)備的閃存進(jìn)行分區(qū)，如圖 3 所示。主客戶端應(yīng)用程序被設(shè)計(jì)為非常便攜和可配置，因此可以在其他安排或其他硬件平臺(tái)上使用。圖 10 顯示了客戶端設(shè)備的軟件體系結(jié)構(gòu)。請注意，雖然我們有時(shí)將整個(gè)應(yīng)用程序稱為 SSBL，但在圖 10 中，從現(xiàn)在開始，我們在邏輯上將真正的 SSBL 部分（藍(lán)色）與 OTA 更新部分（紅色）分開，因?yàn)楹笳卟灰欢ㄐ枰耆谇懊嬗懻摰耐粦?yīng)用程序中實(shí)現(xiàn)。圖 10 中所示的硬件抽象層使 OTA 客戶端軟件保持可移植性，并且獨(dú)立于任何底層庫（以橙色顯示）。

圖 10.客戶端軟件體系結(jié)構(gòu)。

軟件應(yīng)用程序?qū)崿F(xiàn)了圖 3 中的引導(dǎo)順序、用于從服務(wù)器下載新應(yīng)用程序的簡單通信協(xié)議以及哈希鏈。通信協(xié)議中的每個(gè)數(shù)據(jù)包都有一個(gè) 12 字節(jié)的元數(shù)據(jù)標(biāo)頭、64 字節(jié)的有效負(fù)載和一個(gè) 32 字節(jié)的摘要。此外，它還具有以下功能：

緩存：支持無緩存或緩存一頁閃存，具體取決于用戶配置。

目錄：ToC 設(shè)計(jì)為僅保存兩個(gè)應(yīng)用程序，并且新應(yīng)用程序始終下載到最舊的位置，以保留后備應(yīng)用程序。這稱為 A/B 更新方案。

消息傳遞：支持 ADF7242 或 UART 進(jìn)行消息傳遞，具體取決于用戶配置。使用 UART 進(jìn)行消息傳遞可消除圖 9 中左側(cè)的 EZ-KIT，將套件保留在右側(cè)供客戶端使用。這種在線更新方案對(duì)于初始系統(tǒng)啟動(dòng)和調(diào)試非常有用。

結(jié)果

除了滿足功能要求和通過各種測試外，軟件的性能對(duì)于確定項(xiàng)目成功也至關(guān)重要。通常用于衡量嵌入式軟件性能的兩個(gè)指標(biāo)是占用空間和周期。占用空間是指軟件應(yīng)用在易失性 （SRAM） 和非易失性（閃存）存儲(chǔ)器中占用的空間。周期是指軟件用于執(zhí)行特定任務(wù)的微處理器時(shí)鐘周期數(shù)。雖然與軟件運(yùn)行時(shí)類似，但它解釋了這樣一個(gè)事實(shí)，即軟件在執(zhí)行OTA更新時(shí)可能會(huì)進(jìn)入低功耗模式，其中微處理器處于非活動(dòng)狀態(tài)，并且不消耗任何周期。雖然軟件參考設(shè)計(jì)沒有針對(duì)這兩個(gè)指標(biāo)進(jìn)行優(yōu)化，但它們對(duì)于對(duì)程序進(jìn)行基準(zhǔn)測試和比較設(shè)計(jì)權(quán)衡非常有用。

圖11和圖12顯示了在ADuCM4050上實(shí)現(xiàn)的OTA更新軟件參考設(shè)計(jì)的封裝，無需緩存。這些圖根據(jù)圖 10 中所示的組件進(jìn)行了分區(qū)。如圖 11 所示，整個(gè)應(yīng)用使用大約 15 kB 的閃存?？紤]到ADuCM4050包含512 kB閃存，這個(gè)值非常小。真正的應(yīng)用軟件（為OTA更新過程開發(fā)的軟件）只需要大約1.5 kB，其余的用于DFP、Micro-ECC和ADF7242堆棧等庫。這些結(jié)果有助于說明SSBL在系統(tǒng)中應(yīng)發(fā)揮何種作用的設(shè)計(jì)權(quán)衡。15 kB 占用空間的大部分用于更新過程。SSBL本身僅占用約500字節(jié)的占用空間，并額外增加了1 kB至2 kB的DFP代碼，用于閃存驅(qū)動(dòng)程序等設(shè)備訪問。

圖 11.閃存占用空間（字節(jié)）。

圖 12.內(nèi)存占用空間（字節(jié)）。

為了評(píng)估軟件的開銷，我們在每次收到數(shù)據(jù)包時(shí)執(zhí)行周期計(jì)數(shù)，然后查看每個(gè)數(shù)據(jù)包消耗的平均周期數(shù)。每個(gè)數(shù)據(jù)包都需要 AES-128 解密、SHA-256 哈希、閃存寫入和一些數(shù)據(jù)包元數(shù)據(jù)驗(yàn)證。數(shù)據(jù)包有效負(fù)載大小為 64 字節(jié)且無緩存的情況下，處理單個(gè)數(shù)據(jù)包的開銷為 7409 個(gè)周期。使用26 MHz內(nèi)核時(shí)鐘，這大約是285微秒的處理時(shí)間。該值是使用位于ADuCM4050 DFP（未調(diào)整周期）中的周期計(jì)數(shù)驅(qū)動(dòng)程序計(jì)算的，是100 kB二進(jìn)制下載（約1500個(gè)數(shù)據(jù)包）期間獲得的平均值。每個(gè)數(shù)據(jù)包的最小開銷可歸因于DFP中的驅(qū)動(dòng)程序在執(zhí)行總線事務(wù)時(shí)利用ADuCM4050上的直接存儲(chǔ)器訪問（DMA）硬件外設(shè)，以及驅(qū)動(dòng)程序在每個(gè)事務(wù)期間將處理器置于低功耗休眠狀態(tài)。如果我們在 DFP 中禁用低功耗休眠，并將總線事務(wù)更改為不使用 DMA，則每個(gè)數(shù)據(jù)包的開銷將增加到 17，297 個(gè)周期。這說明了有效使用設(shè)備驅(qū)動(dòng)程序?qū)η度胧杰浖?yīng)用程序的影響。雖然每個(gè)數(shù)據(jù)包具有少量的數(shù)據(jù)字節(jié)也保持了較低的開銷，但將每個(gè)數(shù)據(jù)包的數(shù)據(jù)字節(jié)增加一倍到128只會(huì)產(chǎn)生周期的小幅增加 - 導(dǎo)致同一實(shí)驗(yàn)的8，362個(gè)周期。

周期和占用空間還說明了前面討論的緩存數(shù)據(jù)包數(shù)據(jù)而不是每次都寫入閃存的權(quán)衡。啟用一頁閃存緩存后，每個(gè)數(shù)據(jù)包的開銷從 7，409 個(gè)周期減少到 5，904 個(gè)周期。這 20% 的減少來自跳過大多數(shù)數(shù)據(jù)包的閃存寫入功能，并且僅在緩存已滿時(shí)才執(zhí)行閃存寫入。這種減少是以SRAM占位面積為代價(jià)的。如果不進(jìn)行緩存，HAL 只需要 336 字節(jié)的 SRAM，如圖 12 所示。但是，當(dāng)使用緩存時(shí)，我們必須保留相當(dāng)于整頁閃存的空間，這會(huì)將SRAM利用率增加到2，388字節(jié)。HAL的閃存利用率也增加了一小部分，因?yàn)榇_定何時(shí)必須刷新緩存需要額外的代碼。

這些結(jié)果表明，設(shè)計(jì)決策將對(duì)軟件性能產(chǎn)生切實(shí)的影響。沒有放之四海而皆準(zhǔn)的解決方案——每個(gè)系統(tǒng)都有不同的要求和約束，OTA更新軟件需要進(jìn)行調(diào)整才能解決這些問題。希望本文能夠闡明在設(shè)計(jì)、實(shí)現(xiàn)和驗(yàn)證 OTA 更新軟件解決方案時(shí)遇到的常見問題和權(quán)衡。

審核編輯：郭婷