作者：Benjamin Bucklin Brown

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

積木

服務(wù)器和客戶端

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

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

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

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

圖2.軟件應(yīng)用程序的二進(jìn)制轉(zhuǎn)換和數(shù)據(jù)包化過(guò)程。

主要挑戰(zhàn)

基于對(duì) OTA 更新過(guò)程的高級(jí)描述，OTA 更新解決方案必須解決的三個(gè)主要挑戰(zhàn)。第一個(gè)挑戰(zhàn)與記憶有關(guān)。軟件解決方案必須將新的軟件應(yīng)用程序組織到客戶端設(shè)備的易失性或非易失性存儲(chǔ)器中，以便在更新過(guò)程完成時(shí)可以執(zhí)行。解決方案必須確保將以前版本的軟件保留為備用應(yīng)用程序，以防新軟件出現(xiàn)問(wè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ù)包化方案、數(shù)據(jù)包結(jié)構(gòu)和用于傳輸數(shù)據(jù)的協(xié)議都必須在軟件設(shè)計(jì)中考慮在內(nèi)。最后一個(gè)主要挑戰(zhàn)是安全。隨著新軟件從服務(wù)器無(wú)線發(fā)送到客戶端，我們必須確保服務(wù)器是受信任的一方。此安全質(zhì)詢稱(chēng)為身份驗(yàn)證。我們還必須確保新軟件對(duì)任何觀察者進(jìn)行混淆，因?yàn)樗赡馨舾行畔ⅰ４税踩魬?zhàn)稱(chēng)為機(jī)密性。 安全性的最后一個(gè)要素是完整性，確保新軟件在無(wú)線發(fā)送時(shí)不會(huì)損壞。

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

了解引導(dǎo)順序

主引導(dǎo)加載程序是一個(gè)軟件應(yīng)用程序，永久駐留在微控制器的只讀存儲(chǔ)器中。主引導(dǎo)加載程序所在的內(nèi)存區(qū)域稱(chēng)為信息空間，有時(shí)用戶無(wú)法訪問(wèn)。每次發(fā)生重置時(shí)，此應(yīng)用程序都會(huì)執(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 更新過(guò)程的一部分。此啟動(dòng)順序如圖 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)用程序中似乎更簡(jiǎn)單，因?yàn)樗鼘⒃试S將現(xiàn)有的軟件框架、操作系統(tǒng)和設(shè)備驅(qū)動(dòng)程序無(wú)縫用于 OTA 流程。選擇這種方法的系統(tǒng)的內(nèi)存映射和引導(dǎo)順序如圖 4 所示。

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

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

許多嵌入式軟件應(yīng)用程序采用實(shí)時(shí)操作系統(tǒng)（RTOS），它允許將軟件拆分為并發(fā)任務(wù)，每個(gè)任務(wù)在系統(tǒng)中具有不同的職責(zé)。例如，圖1所示的應(yīng)用可能具有RTOS任務(wù)，用于讀取傳感器、對(duì)傳感器數(shù)據(jù)運(yùn)行算法以及與無(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)終止程序的唯一安全方法是通過(guò)重置。

根據(jù)圖 4，前一個(gè)問(wèn)題的解決方案是將主引導(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)。

通過(guò)將 SSBL 固定在地址 0 可以緩解這些問(wèn)題，如圖 3 所示。由于SSBL是一個(gè)非RTOS程序，它可以安全地分支到新的應(yīng)用程序。無(wú)需擔(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)用程序是什么（它開(kāi)始的位置），然后分支到該地址。各種應(yīng)用在微控制器存儲(chǔ)器中的位置通常保存在目錄（ToC）中，如圖3所示。這是持久內(nèi)存的共享區(qū)域，SSBL 和應(yīng)用程序軟件都使用它來(lái)相互通信。OTA 更新過(guò)程完成后，將使用新的應(yīng)用程序信息更新 ToC。部分 OTA 更新功能也可以推送到 SSBL。在開(kāi)發(fā) OTA 更新軟件時(shí)，確定哪些部分是一項(xiàng)重要的設(shè)計(jì)決策。上面描述的最小 SSBL 將非常簡(jiǎn)單、易于驗(yàn)證，并且很可能在應(yīng)用程序的生命周期內(nèi)不需要修改。但是，這意味著每個(gè)應(yīng)用程序必須負(fù)責(zé)下載和驗(yàn)證下一個(gè)應(yīng)用程序。這可能會(huì)導(dǎo)致無(wú)線電堆棧、設(shè)備固件和 OTA 更新軟件方面的代碼重復(fù)。另一方面，我們可以選擇將整個(gè)OTA更新過(guò)程推送到SSBL。在此方案中，應(yīng)用程序只需在 ToC 中設(shè)置一個(gè)標(biāo)志以請(qǐng)求更新，然后執(zhí)行重置。然后，SSBL 執(zhí)行下載順序和驗(yàn)證過(guò)程。這將最大限度地減少代碼重復(fù)并簡(jiǎn)化特定于應(yīng)用程序的軟件。但是，這帶來(lái)了可能必須更新 SSBL 本身（即更新更新代碼）的新挑戰(zhàn)。最后，決定在 SSBL 中放置哪些功能將取決于客戶端設(shè)備的內(nèi)存限制、下載的應(yīng)用程序之間的相似性以及 OTA 更新軟件的可移植性。

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

OTA 更新軟件的另一個(gè)關(guān)鍵設(shè)計(jì)決策是如何在 OTA 更新過(guò)程中在內(nèi)存中組織傳入的應(yīng)用程序。微控制器上通常有兩種類(lèi)型的存儲(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更新過(guò)程中，每次客戶端設(shè)備從服務(wù)器收到包含二進(jìn)制文件一部分的數(shù)據(jù)包時(shí)，該數(shù)據(jù)包都將存儲(chǔ)在SRAM中。此數(shù)據(jù)包可以是壓縮的，也可以是未壓縮的。壓縮應(yīng)用程序二進(jìn)制文件的好處是它的尺寸更小，允許發(fā)送更少的數(shù)據(jù)包，并且在下載過(guò)程中SRAM中存儲(chǔ)它們所需的空間更少。這種方法的缺點(diǎn)是壓縮和解壓縮會(huì)增加更新過(guò)程的額外處理時(shí)間，并且必須在 OTA 更新軟件中捆綁與壓縮相關(guān)的代碼。

由于新的應(yīng)用軟件屬于閃存，但在更新過(guò)程中到達(dá)SRAM，因此OTA更新軟件需要在更新過(guò)程中的某個(gè)時(shí)刻對(duì)閃存執(zhí)行寫(xiě)入操作。將新應(yīng)用程序臨時(shí)存儲(chǔ)在 SRAM 中稱(chēng)為緩存。在高級(jí)別上，OTA 更新軟件可以采用三種不同的方法來(lái)緩存。

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

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

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

圖5.使用SRAM到一頁(yè)緩存閃存。

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

安全與通信

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

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

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

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

解決安全挑戰(zhàn)

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

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

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

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

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

哈希鏈將我們?cè)诒竟?jié)中討論的加密概念合并到一系列數(shù)據(jù)包中，以在數(shù)學(xué)上將它們綁定在一起。如圖 8 所示，第一個(gè)數(shù)據(jù)包（編號(hào) 0）包含下一個(gè)數(shù)據(jù)包的摘要。第一個(gè)數(shù)據(jù)包的有效載荷不是實(shí)際的軟件應(yīng)用程序數(shù)據(jù)，而是簽名。第二個(gè)數(shù)據(jù)包（編號(hào) 1）有效負(fù)載包含二進(jìn)制文件的一部分，以及第三個(gè)數(shù)據(jù)包（編號(hào) 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ù)包來(lái)自受信任的服務(wù)器，而無(wú)需執(zhí)行簽名檢查的所有開(kāi)銷(xiāo)。生成此鏈的昂貴任務(wù)留給服務(wù)器，客戶端必須在每個(gè)數(shù)據(jù)包到達(dá)時(shí)簡(jiǎn)單地緩存和哈希，以確保數(shù)據(jù)包到達(dá)時(shí)未損壞、完整性和經(jīng)過(guò)身份驗(yàn)證。

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

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

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

硬件配置

為了驗(yàn)證和驗(yàn)證本文討論的概念，使用ADuCM4050創(chuàng)建了一個(gè)OTA更新軟件參考設(shè)計(jì)。對(duì)于客戶端，ADuCM4050 EZ-KIT使用收發(fā)器子板馬蹄形連接器連接到ADF7242。客戶端設(shè)備如圖 9 左側(cè)所示。對(duì)于服務(wù)器，開(kāi)發(fā)了一個(gè)在Windows PC上運(yùn)行的Python應(yīng)用程序。Python應(yīng)用程序通過(guò)串行端口與另一個(gè)ADuCM4050 EZ-KIT通信，該模塊也以與客戶端相同的排列方式連接了ADF7242。但是，圖9中的右側(cè)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)。請(qǐng)注意，雖然我們有時(shí)將整個(gè)應(yīng)用程序稱(chēng)為 SSBL，但在圖 10 中，從現(xiàn)在開(kāi)始，我們?cè)谶壿嬌蠈⒄嬲?SSBL 部分（藍(lán)色）與 OTA 更新部分（紅色）分開(kāi)，因?yàn)楹笳卟灰欢ㄐ枰谇懊嬗懻摰耐粦?yīng)用程序中完全實(shí)現(xiàn)。圖 10 中所示的硬件抽象層使 OTA 客戶端軟件保持可移植性，并且獨(dú)立于任何底層庫(kù)（以橙色顯示）。

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

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

緩存：支持無(wú)緩存或緩存一頁(yè)閃存，具體取決于用戶配置。

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

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

結(jié)果

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

圖11和圖12顯示了在ADuCM4050上實(shí)現(xiàn)的無(wú)緩存OTA更新軟件參考設(shè)計(jì)的尺寸。這些圖根據(jù)圖 10 中所示的組件進(jìn)行分區(qū)。如圖 11 所示，整個(gè)應(yīng)用使用大約 15 kB 的閃存。 考慮到ADuCM4050包含512 kB閃存，這是相當(dāng)小的。真正的應(yīng)用軟件（為OTA更新過(guò)程開(kāi)發(fā)的軟件）只需要大約1.5 kB，其余的用于DFP、Micro-ECC和ADF7242堆棧等庫(kù)。這些結(jié)果有助于說(shuō)明SSBL在系統(tǒng)中應(yīng)具有什么角色的設(shè)計(jì)權(quán)衡。15 kB 占用空間的大部分用于更新過(guò)程。SSBL 本身僅占用大約 500 字節(jié)的占用空間，還有額外的 1 kB 到 2 kB 的 DFP 代碼用于設(shè)備訪問(wèn)，如閃存驅(qū)動(dòng)程序。

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

圖 12.SRAM 占用空間（字節(jié)）。

為了評(píng)估軟件的開(kāi)銷(xiāo)，我們?cè)诿看问盏綌?shù)據(jù)包時(shí)執(zhí)行周期計(jì)數(shù)，然后查看每個(gè)數(shù)據(jù)包消耗的平均周期數(shù)。每個(gè)數(shù)據(jù)包都需要 AES-128 解密、SHA-256 哈希、寫(xiě)入閃存和一些數(shù)據(jù)包元數(shù)據(jù)驗(yàn)證。數(shù)據(jù)包有效負(fù)載大小為 64 字節(jié)且無(wú)緩存，處理單個(gè)數(shù)據(jù)包的開(kāi)銷(xiāo)為 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ù)包的最小開(kāi)銷(xiāo)可歸因于DFP中的驅(qū)動(dòng)器在執(zhí)行總線事務(wù)時(shí)利用ADuCM4050上的直接存儲(chǔ)器訪問(wèn)（DMA）硬件外設(shè)，以及驅(qū)動(dòng)程序在每次事務(wù)期間將處理器置于低功耗睡眠狀態(tài)。如果我們禁用 DFP 中的低功耗休眠并將總線事務(wù)更改為不使用 DMA，則每個(gè)數(shù)據(jù)包的開(kāi)銷(xiāo)將增加到 17，297 個(gè)周期。這說(shuō)明了有效使用設(shè)備驅(qū)動(dòng)程序?qū)η度胧杰浖?yīng)用程序的影響。雖然每個(gè)數(shù)據(jù)包的數(shù)據(jù)字節(jié)數(shù)較少也保持較低開(kāi)銷(xiāo)，但將每個(gè)數(shù)據(jù)包的數(shù)據(jù)字節(jié)數(shù)加倍到 128 個(gè)只會(huì)產(chǎn)生周期的小幅增加，導(dǎo)致同一實(shí)驗(yàn)的周期為 8362 個(gè)。

周期和占用空間還說(shuō)明了前面討論的緩存數(shù)據(jù)包數(shù)據(jù)而不是每次都寫(xiě)入閃存的權(quán)衡。啟用一頁(yè)閃存緩存后，每個(gè)數(shù)據(jù)包的開(kāi)銷(xiāo)從 7409 個(gè)周期減少到 5904 個(gè)周期。這 20% 的減少來(lái)自于能夠跳過(guò)大多數(shù)數(shù)據(jù)包的閃存寫(xiě)入，并且僅在緩存已滿時(shí)執(zhí)行閃存寫(xiě)入。這種減少是以SRAM占用空間為代價(jià)的。如果沒(méi)有緩存，HAL 只需要 336 字節(jié)的 SRAM，如圖 12 所示。但是，當(dāng)使用緩存時(shí)，我們必須保留等于一整頁(yè)閃存的空間，這會(huì)將SRAM利用率增加到2388字節(jié)。由于確定何時(shí)必須刷新緩存所需的額外代碼，HAL 的閃存利用率也會(huì)略有增加。

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

審核編輯：郭婷