抽象

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

積木

服務器和客戶端

OTA 更新將設備上的當前軟件替換為新軟件，新軟件將以無線方式下載。在嵌入式系統中，運行此軟件的設備通常是微控制器。微控制器是一種小型計算設備，具有有限的內存、速度和功耗。微控制器通常包含一個微處理器（內核）以及用于特定操作（外設）的數字硬件模塊。在有源模式下，功耗通常為30 μA/MHz至40 μA/MHz的超低功耗微控制器非常適合此類應用。在這些微控制器上使用特定的硬件外設并將其置于低功耗模式是OTA更新軟件設計的重要組成部分。圖 1 顯示了可能需要 OTA 更新的嵌入式系統示例。在這里，我們看到一個與無線電和傳感器連接的微控制器，該微控制器可用于物聯網應用，該應用使用傳感器收集有關環境的數據，并使用無線電定期報告。系統的這一部分稱為邊緣節點或客戶端，是 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 是非實時操作系統程序，因此它可以安全地分支到新的應用程序。無需擔心電源循環會將系統置于災難性狀態，因為地址 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到一頁高速緩存閃存。

圖5說明了OTA更新期間部分緩存的第二種方案，其中放大了圖3和圖4中應用A的閃存部分，并說明了SSBL的SRAM的功能存儲器圖。圖中顯示了一個 2 kB 的閃存頁面大小示例。最終，此設計決策將根據新應用程序的大小和 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等軟件庫來實現，這些軟件庫專門針對資源受限的設備。該庫需要用戶定義的隨機數生成函數，該函數可以使用微控制器上的真隨機數生成器硬件外設來實現。雖然這些非對稱加密操作解決了OTA更新期間的信任挑戰，但它們在處理時間方面成本高昂，并且需要與數據一起發送簽名，這會增加數據包大小。我們可以在下載結束時執行一次此檢查，使用最終數據包的摘要或整個新軟件應用程序的摘要，但這將允許第三方將不受信任的軟件下載到客戶端，這并不理想。理想情況下，我們希望驗證我們收到的每個數據包是否來自受信任的服務器，而不會每次都有簽名的開銷。這可以使用哈希鏈來實現。

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

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

實驗設置

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

硬件配置

為了驗證和確認此處討論的概念，使用ADuCM4050創建了OTA更新軟件參考設計。對于客戶端，ADuCM4050 EZ-KIT使用收發器子板馬蹄形連接器連接到ADF7242。客戶端設備如圖 9 左側所示。對于服務器，開發了一個在Windows PC上運行的Python應用程序。Python應用通過串行端口與另一個ADuCM4050 EZ-KIT通信，該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.內存占用空間（字節）。

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

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

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

審核編輯：郭婷