作者：Benjamin Bucklin Brown

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

積木

服務器和客戶端

OTA 更新將設備上的當前軟件替換為新軟件，并以無線方式下載新軟件。在嵌入式系統中，運行此軟件的設備通常是微控制器。微控制器是一種小型計算設備，內存、速度和功耗有限。微控制器通常包含一個微處理器（內核）以及用于特定操作的數字硬件模塊（外設）。超低功耗微控制器在活動模式下通常消耗30 μA/MHz至40 μA/MHz，非常適合此類應用。在這些微控制器上使用特定的硬件外設并將其置于低功耗模式是OTA更新軟件設計的重要組成部分?？赡苄枰?OTA 更新的嵌入式系統示例如圖 1 所示。在這里，我們看到一個與無線電和傳感器連接的微控制器，該微控制器可用于物聯網應用程序，該應用程序使用傳感器收集有關環境的數據，并使用無線電定期報告。系統的這一部分稱為邊緣節點或客戶端，是 OTA 更新的目標。系統的另一部分稱為云或服務器，是新軟件的提供商。服務器和客戶端使用收發器（無線電）通過無線連接進行通信。

圖1.嵌入式系統中的示例中的服務器/客戶端體系結構。

是什么造就了軟件應用程序？

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

圖2.軟件應用程序的二進制轉換和數據包化過程。

主要挑戰

基于對 OTA 更新過程的高級描述，OTA 更新解決方案必須解決的三個主要挑戰。第一個挑戰與記憶有關。軟件解決方案必須將新的軟件應用程序組織到客戶端設備的易失性或非易失性存儲器中，以便在更新過程完成時可以執行。解決方案必須確保將以前版本的軟件保留為備用應用程序，以防新軟件出現問題。此外，我們必須在重置和電源周期之間保留客戶端設備的狀態，例如我們當前正在運行的軟件版本以及它在內存中的位置。第二個主要挑戰是溝通。 新軟件必須以離散數據包的形式從服務器發送到客戶端，每個數據包都針對客戶端內存中的特定地址。數據包化方案、數據包結構和用于傳輸數據的協議都必須在軟件設計中考慮在內。最后一個主要挑戰是安全。隨著新軟件從服務器無線發送到客戶端，我們必須確保服務器是受信任的一方。此安全質詢稱為身份驗證。我們還必須確保新軟件對任何觀察者進行混淆，因為它可能包含敏感信息。此安全挑戰稱為機密性。 安全性的最后一個要素是完整性，確保新軟件在無線發送時不會損壞。

第二階段引導加載程序 （SSBL）

了解引導順序

主引導加載程序是一個軟件應用程序，永久駐留在微控制器的只讀存儲器中。主引導加載程序所在的內存區域稱為信息空間，有時用戶無法訪問。每次發生重置時，此應用程序都會執行，通常執行一些基本的硬件初始化，并可能將用戶軟件加載到內存中。但是，如果微控制器包含片上非易失性存儲器（如閃存），則引導加載程序不需要執行任何加載，只需將控制權轉移到閃存中的程序即可。如果主引導加載程序不支持 OTA 更新，則必須具有第二階段引導加載程序。與主引導加載程序一樣，SSBL 將在每次重置發生時運行，但將實現 OTA 更新過程的一部分。此啟動順序如圖 3 所示。在本節中，我們將描述為什么需要第二階段引導加載程序，并描述指定此應用程序的角色如何成為關鍵的設計權衡。

圖3.使用 SSBL 的內存映射和引導流的示例。

經驗教訓：始終擁有SSBL

從概念上講，省略 SSBL 并將所有 OTA 更新功能放入用戶應用程序中似乎更簡單，因為它將允許將現有的軟件框架、操作系統和設備驅動程序無縫用于 OTA 流程。選擇這種方法的系統的內存映射和引導順序如圖 4 所示。

圖4.沒有 SSBL 的內存映射和引導流程示例

應用程序A是部署在現場微控制器上的原始應用程序。此應用程序包含與 OTA 更新相關的軟件，當服務器請求時，該軟件可用于下載應用程序 B。完成此下載并驗證應用程序 B 后，應用程序 A 將通過對應用程序 B 的重置處理程序執行分支指令將控制權轉移到應用程序 B。重置處理程序是一小段代碼，是軟件應用程序的入口點，并在重置時運行。在這種情況下，重置是通過執行分支來模擬的，這相當于函數調用。此方法存在兩個主要問題：

許多嵌入式軟件應用程序采用實時操作系統（RTOS），它允許將軟件拆分為并發任務，每個任務在系統中具有不同的職責。例如，圖1所示的應用可能具有RTOS任務，用于讀取傳感器、對傳感器數據運行算法以及與無線電接口。RTOS 本身始終處于活動狀態，并負責根據異步事件或特定的基于時間的延遲在這些任務之間切換。因此，從RTOS任務分支到新程序是不安全的，因為其他任務將繼續在后臺運行。使用實時操作系統終止程序的唯一安全方法是通過重置。

根據圖 4，前一個問題的解決方案是將主引導加載程序分支到應用程序 B，而不是應用程序 A。但是，在某些微控制器上，主引導加載程序始終運行具有中斷向量表 （IVT） 的程序，IVT 是描述中斷處理功能的應用程序的關鍵部分，位于地址 0。這意味著需要某種形式的IVT重新定位才能將重置映射到應用程序B。如果在此 IVT 重新定位期間發生電源循環，則可能會使系統處于永久損壞狀態。

通過將 SSBL 固定在地址 0 可以緩解這些問題，如圖 3 所示。由于SSBL是一個非RTOS程序，它可以安全地分支到新的應用程序。無需擔心電源循環會使系統處于災難性狀態，因為地址為 0 的 SSBL 的 IVT 永遠不會重新定位。

設計權衡：SSBL的作用

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

設計權衡：緩存和壓縮

OTA 更新軟件的另一個關鍵設計決策是如何在 OTA 更新過程中在內存中組織傳入的應用程序。微控制器上通常有兩種類型的存儲器：非易失性存儲器（例如閃存）和易失性存儲器（例如SRAM）。閃存將用于存儲應用程序的程序代碼和只讀數據，以及其他系統級數據，如 ToC 和事件日志。SRAM將用于存儲軟件應用程序的可修改部分，例如非常量全局變量和堆棧。圖2所示的軟件應用程序二進制文件僅包含程序中駐留在非易失性存儲器中的部分。應用程序將在啟動例程期間初始化屬于易失性內存的部分。

在OTA更新過程中，每次客戶端設備從服務器收到包含二進制文件一部分的數據包時，該數據包都將存儲在SRAM中。此數據包可以是壓縮的，也可以是未壓縮的。壓縮應用程序二進制文件的好處是它的尺寸更小，允許發送更少的數據包，并且在下載過程中SRAM中存儲它們所需的空間更少。這種方法的缺點是壓縮和解壓縮會增加更新過程的額外處理時間，并且必須在 OTA 更新軟件中捆綁與壓縮相關的代碼。

由于新的應用軟件屬于閃存，但在更新過程中到達SRAM，因此OTA更新軟件需要在更新過程中的某個時刻對閃存執行寫入操作。將新應用程序臨時存儲在 SRAM 中稱為緩存。在高級別上，OTA 更新軟件可以采用三種不同的方法來緩存。

無緩存：每次數據包到達時，包含新應用程序的一部分，將其寫入閃存中的目標。該方案非常簡單，將最大限度地減少OTA更新軟件中的邏輯量，但它要求完全擦除新應用程序的閃存區域。此方法會磨損閃存并增加開銷。

部分緩存：保留一個 SRAM 區域用于緩存，并在新數據包到達時將它們存儲在該區域中。當區域填滿時，將數據寫入閃存來清空它。如果數據包無序到達或新應用程序二進制文件中存在間隙，這可能會變得復雜，因為需要將SRAM地址映射到閃存地址的方法。一種策略是讓緩存充當閃存部分的鏡像。閃存被劃分為稱為頁面的小區域，這是擦除的最小分區。由于這種自然劃分，一個好的方法是在SRAM中緩存一頁閃存，當它填滿或下一個數據包屬于不同的頁面時，通過寫入該頁面閃存來刷新緩存。

完全緩存：在OTA更新過程中將整個新應用程序存儲在SRAM中，并且僅在從服務器完全下載后將其寫入閃存。這種方法克服了以前方法的缺點，最大限度地減少了對閃存的寫入次數，并避免了OTA更新軟件中復雜的緩存邏輯。但是，這將限制正在下載的新應用程序的大小，因為系統上的可用SRAM量通常遠小于可用閃存量。

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

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

安全與通信

設計權衡：軟件與協議

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

OTA更新軟件中必須內置的通信功能量最終將取決于現有通信協議提供的抽象程度?，F有的通信協議具有在服務器和客戶端之間發送和接收文件的功能，OTA 更新軟件可以簡單地利用這些工具進行下載過程。但是，如果通信協議更原始并且只有用于發送原始數據的工具，則 OTA 更新軟件可能需要執行數據包化并提供元數據以及新的應用程序二進制文件。這也適用于安全挑戰。如果通信協議不支持，OTA 更新軟件可能有責任解密通過無線發送的字節以確保機密性。

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

解決安全挑戰

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

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

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

圖7.使用非對稱加密對消息進行身份驗證。

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

哈希鏈將我們在本節中討論的加密概念合并到一系列數據包中，以在數學上將它們綁定在一起。如圖 8 所示，第一個數據包（編號 0）包含下一個數據包的摘要。第一個數據包的有效載荷不是實際的軟件應用程序數據，而是簽名。第二個數據包（編號 1）有效負載包含二進制文件的一部分，以及第三個數據包（編號 2）的摘要?？蛻舳蓑炞C第一個數據包中的簽名，并緩存摘要 H0 供以后使用。當第二個數據包到達時，客戶端對有效負載進行哈希處理并將其與 H0 進行比較。如果它們匹配，則客戶端可以確定此后續數據包來自受信任的服務器，而無需執行簽名檢查的所有開銷。生成此鏈的昂貴任務留給服務器，客戶端必須在每個數據包到達時簡單地緩存和哈希，以確保數據包到達時未損壞、完整性和經過身份驗證。

圖8.將哈希鏈應用于數據包序列。

實驗設置

解決本文所述存儲器、通信和安全設計挑戰的超低功耗微控制器是ADuCM3029和ADuCM4050。這些微控制器包含整篇文章中討論的用于 OTA 更新的硬件外設，例如閃存、SRAM、加密加速器和真隨機數生成器。這些微控制器的器件系列包 （DFP） 為在這些器件上構建 OTA 更新解決方案提供軟件支持。DFP 包含外圍驅動程序，這些驅動程序為使用硬件提供簡單、靈活的接口。

硬件配置

為了驗證和驗證本文討論的概念，使用ADuCM4050創建了一個OTA更新軟件參考設計。對于客戶端，ADuCM4050 EZ-KIT使用收發器子板馬蹄形連接器連接到ADF7242?？蛻舳嗽O備如圖 9 左側所示。對于服務器，開發了一個在Windows PC上運行的Python應用程序。Python應用程序通過串行端口與另一個ADuCM4050 EZ-KIT通信，該模塊也以與客戶端相同的排列方式連接了ADF7242。但是，圖9中的右側EZ-KIT不執行OTA更新邏輯，只是將從ADF7242接收的數據包中繼到Python應用。?

圖9.實驗性硬件設置。

軟件組件

軟件參考設計對客戶端設備的閃存進行分區，如圖3所示。主客戶端應用程序被設計為非?？梢浦埠涂膳渲茫员憧梢栽谄渌才呕蚱渌布脚_上利用它。圖 10 顯示了客戶端設備的軟件體系結構。請注意，雖然我們有時將整個應用程序稱為 SSBL，但在圖 10 中，從現在開始，我們在邏輯上將真正的 SSBL 部分（藍色）與 OTA 更新部分（紅色）分開，因為后者不一定需要在前面討論的同一應用程序中完全實現。圖 10 中所示的硬件抽象層使 OTA 客戶端軟件保持可移植性，并且獨立于任何底層庫（以橙色顯示）。

圖 10.客戶端軟件體系結構。

軟件應用程序實現了圖 3 中的引導順序、用于從服務器下載新應用程序的簡單通信協議以及哈希鏈。通信協議中的每個數據包都有一個 12 字節元數據標頭、64 字節有效負載和 32 字節摘要。此外，它還具有以下功能：

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

目錄：ToC 設計為僅容納兩個應用程序，并且新應用程序始終下載到最舊的位置，以保留回退應用程序。這稱為 A/B 更新方案。

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

結果

除了滿足功能要求和通過各種測試外，軟件的性能對于確定項目成功也至關重要。通常用于衡量嵌入式軟件性能的兩個指標是占用空間和周期。占用空間是指軟件應用程序在易失性 （SRAM） 和非易失性（閃存）存儲器中占用的空間。周期是指軟件用于執行特定任務的微處理器時鐘周期數。雖然與軟件運行時類似，但它解釋了這樣一個事實，即軟件在執行 OTA 更新時可能會進入低功耗模式，其中微處理器處于非活動狀態，并且不消耗任何周期。雖然軟件參考設計沒有針對這兩個指標進行優化，但它們對于對程序進行基準測試和比較設計權衡非常有用。

圖11和圖12顯示了在ADuCM4050上實現的無緩存OTA更新軟件參考設計的尺寸。這些圖根據圖 10 中所示的組件進行分區。如圖 11 所示，整個應用使用大約 15 kB 的閃存。 考慮到ADuCM4050包含512 kB閃存，這是相當小的。真正的應用軟件（為OTA更新過程開發的軟件）只需要大約1.5 kB，其余的用于DFP、Micro-ECC和ADF7242堆棧等庫。這些結果有助于說明SSBL在系統中應具有什么角色的設計權衡。15 kB 占用空間的大部分用于更新過程。SSBL 本身僅占用大約 500 字節的占用空間，還有額外的 1 kB 到 2 kB 的 DFP 代碼用于設備訪問，如閃存驅動程序。

圖 11.閃存占用空間（字節）。

圖 12.SRAM 占用空間（字節）。

為了評估軟件的開銷，我們在每次收到數據包時執行周期計數，然后查看每個數據包消耗的平均周期數。每個數據包都需要 AES-128 解密、SHA-256 哈希、寫入閃存和一些數據包元數據驗證。數據包有效負載大小為 64 字節且無緩存，處理單個數據包的開銷為 7409 個周期。使用 26 MHz 內核時鐘，這大約是 285 微秒的處理時間。該值是使用ADuCM4050 DFP（未調整周期）中的周期計數驅動程序計算得出的，是100 kB二進制下載（約1500個數據包）期間的平均值。每個數據包的最小開銷可歸因于DFP中的驅動器在執行總線事務時利用ADuCM4050上的直接存儲器訪問（DMA）硬件外設，以及驅動程序在每次事務期間將處理器置于低功耗睡眠狀態。如果我們禁用 DFP 中的低功耗休眠并將總線事務更改為不使用 DMA，則每個數據包的開銷將增加到 17，297 個周期。這說明了有效使用設備驅動程序對嵌入式軟件應用程序的影響。雖然每個數據包的數據字節數較少也保持較低開銷，但將每個數據包的數據字節數加倍到 128 個只會產生周期的小幅增加，導致同一實驗的周期為 8362 個。

周期和占用空間還說明了前面討論的緩存數據包數據而不是每次都寫入閃存的權衡。啟用一頁閃存緩存后，每個數據包的開銷從 7409 個周期減少到 5904 個周期。這 20% 的減少來自于能夠跳過大多數數據包的閃存寫入，并且僅在緩存已滿時執行閃存寫入。這種減少是以SRAM占用空間為代價的。如果沒有緩存，HAL 只需要 336 字節的 SRAM，如圖 12 所示。但是，當使用緩存時，我們必須保留等于一整頁閃存的空間，這會將SRAM利用率增加到2388字節。由于確定何時必須刷新緩存所需的額外代碼，HAL 的閃存利用率也會略有增加。

這些結果表明，設計決策將對軟件性能產生切實影響。沒有放之四海而皆準的解決方案——每個系統都有不同的要求和約束，需要調整 OTA 更新軟件以解決這些問題。希望本文能夠闡明在設計、實施和驗證 OTA 更新軟件解決方案時面臨的常見問題和權衡。

審核編輯：郭婷