圖2. 軟件應用程序的二進制轉(zhuǎn)換和分包過程

基于對OTA更新過程的這種高層次描述，OTA更新解決方案必須應對三大挑戰(zhàn)。第一個挑戰(zhàn)與存儲器有關。軟件解決方案必須將新軟件應用程序組織到客戶端器件的易失性或非易失性存儲器中，以便在更新過程完成時可以執(zhí)行它。解決方案必須確保將前一版本的軟件保留為后備應用程序，以防新軟件出現(xiàn)問題。此外，當復位和斷電重啟時，我們必須讓客戶端器件的狀態(tài)——例如當前運行的軟件版本以及它在存儲器中的位置——保持不變。第二大挑戰(zhàn)是通信。新軟件必須以離散數(shù)據(jù)包的形式從服務器發(fā)送到客戶端，每個數(shù)據(jù)包都要放在客戶端存儲器中的特定地址。分包方案、數(shù)據(jù)包結(jié)構(gòu)和數(shù)據(jù)傳輸協(xié)議必須在軟件設計中考慮周全。最后一個主要挑戰(zhàn)是安全性。當新軟件以無線方式從服務器發(fā)送到客戶端時，我們必須確保服務器是可信任方。這種安全挑戰(zhàn)稱為身份驗證。我們還必須對新軟件進行模糊處理以防被竊，因為其中可能包含敏感信息。這種安全挑戰(zhàn)稱為保密。安全性的最后一個要素是完整性，即確保新軟件在通過無線方式發(fā)送時不會損壞。

主引導加載程序是一種軟件應用程序，永久駐留在微控制器的只讀存儲器中。主引導加載程序所在的存儲區(qū)域稱為信息空間，有時用戶無法訪問。每次復位都會執(zhí)行該應用程序，一般完成一些必要的硬件初始化，并且可能將用戶軟件加載到存儲器中。但是，如果微控制器包含片內(nèi)非易失性存儲器（如閃存），則引導加載程序不需要進行任何加載，只需將控制權轉(zhuǎn)移到閃存中的程序即可。如果主引導加載程序不支持OTA更新，則必須有第二階段引導加載程序。與主引導加載程序一樣，SSBL會在每次復位時運行，但將實施OTA更新過程的一部分。此引導序列如圖3所示。本節(jié)將說明為什么需要第二階段引導加載程序，并解釋如何設計這個應用程序是一個重要設計權衡。

圖3. 使用SSBL的存儲器映射和引導流程示例

從概念上講，省略SSBL并將所有OTA更新功能放入用戶應用程序似乎更簡單，因為這樣的話，OTA過程可以無縫利用現(xiàn)有的軟件框架、操作系統(tǒng)和設備驅(qū)動程序。圖4顯示了一個選擇此方法的系統(tǒng)的存儲器映射和引導序列。

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

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

將SSBL固定在地址0可以解決這些問題，如圖3所示。SSBL不是RTOS程序，因此可以安全地分支到新應用程序。地址0處的SSBL的IVT永遠不會重新定位，所以不必擔心斷電重啟會將系統(tǒng)置于災難性狀態(tài)。

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

OTA更新軟件中的另一個關鍵設計決策是在OTA更新過程中如何組織存儲器中傳入的應用程序。微控制器上通常有兩類存儲器：非易失性存儲器（例如閃存）和易失性存儲器（例如SRAM）。閃存用于存儲應用程序的程序代碼和只讀數(shù)據(jù)，以及其他系統(tǒng)級數(shù)據(jù)，例如ToC和事件日志。SRAM用于存儲軟件應用程序的可修改部分，例如非常數(shù)全局變量和堆棧。圖2所示的軟件應用程序二進制文件僅包含非易失性存儲器中存在的程序的某些部分。在啟動例程期間，應用程序?qū)⒊跏蓟瘜儆谝资源鎯ζ鞯牟糠帧?/span>

在OTA更新過程中，每次客戶端器件從服務器收到一個包含該二進制文件一部分的數(shù)據(jù)包時，便會將其存儲到SRAM中。該數(shù)據(jù)包可以是壓縮的，也可以是未壓縮的。壓縮應用程序二進制文件的好處是文件會變小，從而要發(fā)送的數(shù)據(jù)包會減少，下載過程中存儲數(shù)據(jù)包所需的SRAM空間相應地減小。這種方法的缺點是壓縮和解壓縮會增加更新過程的處理時間，并且必須在OTA更新軟件中捆綁壓縮相關代碼。

新應用軟件應該存放在閃存，但在更新過程中到達SRAM，因此OTA更新軟件需要在更新過程中的某個時刻執(zhí)行對閃存的寫操作。暫時將新應用程序存儲在SRAM中的操作稱為緩存。概言之，OTA更新軟件可以采取三種不同的緩存方法。

圖5. 使用SRAM緩存閃存的一頁

圖5顯示了OTA更新過程中的第二種方案——部分緩存，來自圖3和圖4的應用程序A所對應的閃存部分被放大，并且顯示了用于SSBL的SRAM的功能存儲器映射。示例閃存頁面大小為2kB。最終，此設計決策將取決于新應用程序的大小和OTA更新軟件容許的復雜度。

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

OTA更新軟件中必須構(gòu)建的通信功能量最終將取決于現(xiàn)有通信協(xié)議提供的抽象程度。現(xiàn)有通信協(xié)議具有用于在服務器和客戶端之間發(fā)送和接收文件的工具，OTA更新軟件可以簡單地將該工具用于下載過程。但是，如果通信協(xié)議較為原始，只有發(fā)送原始數(shù)據(jù)的工具，那么OTA更新軟件可能需要執(zhí)行分包處理，并提供元數(shù)據(jù)和新應用程序二進制文件。這也適用于安全挑戰(zhàn)。如果通信協(xié)議不支持，OTA更新軟件可能要負責對無線保密發(fā)送的字節(jié)進行解密。

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

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

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

解決身份驗證這一最終挑戰(zhàn)的常見技術是使用非對稱加密。對于此操作，服務器會生成一個公鑰-私鑰對。私鑰只有服務器知道，客戶端知道公鑰。服務器使用私鑰可以生成給定數(shù)據(jù)塊的簽名，例如要無線發(fā)送的數(shù)據(jù)包的摘要。簽名被發(fā)送給客戶端，后者可以使用公鑰驗證簽名。這樣，客戶端就能確認消息是從服務器而不是惡意第三方發(fā)送的。此序列如圖7所示，實線箭頭表示函數(shù)輸入/輸出，虛線箭頭表示無線發(fā)送的信息。

圖7. 使用非對稱加密驗證消息

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

解決本文所述存儲器、通信和安全設計挑戰(zhàn)的超低功耗微控制器是ADuCM3029和ADuCM4050這些微控制器包含本文討論的用于OTA更新的硬件外設，例如閃存、SRAM、加密加速器和真隨機數(shù)發(fā)生器。這些微控制器的器件系列包(DFPs)為在這些器件上構(gòu)建OTA更新解決方案提供了軟件支持。DFP包含外設驅(qū)動，以便為使用硬件提供簡單靈活的接口。

為了驗證本文討論的概念，我們利用ADuCM4050創(chuàng)建了OTA更新軟件參考設計。對于客戶端，一個ADuCM4050EZ-KIT? 使用收發(fā)器子板馬蹄形連接器連接到ADF7242?？蛻舳似骷鐖D9左側(cè)所示。對于服務器，我們開發(fā)了一個在WindowsPC上運行的Python應用程序。Python應用程序通過串行端口與另一個ADuCM4050EZ-KIT通信，后者也以與客戶端相同的配置連接一個ADF7242。但是，圖9中右邊的EZ-KIT不執(zhí)行OTA更新邏輯，只是將從ADF7242接收到的數(shù)據(jù)包中繼給Python應用程序。

圖9. 實驗硬件設置

軟件參考設計對客戶端器件的閃存進行分區(qū)，如圖3所示。主要客戶端應用程序具有非常好的移植性和可配置性，以便其他方案或6模擬對話52-11，2018年11月其他硬件平臺也可以使用。圖10顯示了客戶端器件的軟件架構(gòu)。請注意，雖然我們有時將整個應用程序稱為SSBL，但在圖10中，并且從現(xiàn)在開始，我們在邏輯上將真正的SSBL部分（藍色）與OTA更新部分（紅色）分開，因為后者不一定需要完全在上述應用程序中實現(xiàn)。圖10所示的硬件抽象層使OTA客戶端軟件可移植并獨立于任何底層庫（以橙色顯示）。

圖10. 客戶端軟件架構(gòu)

軟件應用程序?qū)崿F(xiàn)圖3中的引導序列（一個用于從服務器下載新應用程序的簡單通信協(xié)議）和哈希鏈。通信協(xié)議中的每個數(shù)據(jù)包都有12字節(jié)的元數(shù)據(jù)頭、64字節(jié)的有效載荷和32字節(jié)的摘要。此外，它還有如下特性：

• 緩存：根據(jù)用戶配置，支持不緩存或緩存閃存的一頁。

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

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

除了滿足功能要求并通過各種測試之外，軟件的性能對于判斷項目成功與否也很重要。通常使用兩個指標來衡量嵌入式軟件的性能：占用空間和周期數(shù)。占用空間是指軟件應用程序在易失性(SRAM)和非易失性（閃存）存儲器中占用的空間大小。周期數(shù)是指軟件執(zhí)行特定任務所使用的微處理器時鐘周期數(shù)。它與軟件運行時間相似，但在執(zhí)行OTA更新時，軟件可能進入低功耗模式，此時微處理器處于非活動狀態(tài)，不消耗任何周期。雖然軟件參考設計沒有針對任何一個指標進行優(yōu)化，但它們對于程序基準測試和比較設計權衡非常有用。

圖11和圖12顯示了在ADuCM4050上實現(xiàn)的OTA更新軟件參考設計的占用空間（不緩存）。這些圖根據(jù)圖10所示的組件進行劃分。如圖11所示，整個應用程序使用大約15kB的閃存。鑒于ADuCM4050包含512B閃存，此占用空間非常小。真正的應用軟件（為OTA更新過程開發(fā)的軟件）僅需1.kB左右，其余用于庫，例如DFP、Micro-ECC和ADF7242堆棧。這些結(jié)果有助于說明SSBL應在系統(tǒng)中扮演什么角色的設計權衡。1kB占用空間的大部分是用于更新過程。SSBL本身僅占用大約500字節(jié)的空間，另外還有1kB到2kB的DFP代碼，用于訪問閃存驅(qū)動之類的器件。

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

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

為了評估軟件的開銷，我們在每次接收數(shù)據(jù)包時計數(shù)周期，然后計算每個數(shù)據(jù)包平均消耗的周期數(shù)。每個數(shù)據(jù)包都需要AES-128解密、SHA-256哈希處理、閃存寫入和某種數(shù)據(jù)包元數(shù)據(jù)驗證。數(shù)據(jù)包有效載荷為64字節(jié)且不緩存時，處理單個數(shù)據(jù)包的開銷為7409個周期。使用26MHz內(nèi)核時鐘時，大約需要285微秒的處理時間。該值是利用ADuCM4050DFP中的周期計數(shù)驅(qū)動程序計算的（未調(diào)整周期數(shù)），并且是100kB二進制文件下載期間（約1500個數(shù)據(jù)包）的平均值。為使每個數(shù)據(jù)包的開銷最小，DFP中的驅(qū)動程序應利用ADuCM4050上的直接存儲訪問(DMA)硬件外設來執(zhí)行總線事務，并且驅(qū)動程序在每次事務處理期間將處理器置于低功耗休眠狀態(tài)。每個事務中不存在一個萬能的狀態(tài)，如果我們禁用DFP中的低功耗休眠并將總線事務更改為不使用DMA，則每個數(shù)據(jù)包的開銷將增加到17,297個周期。這說明了高效使用器件驅(qū)動程序?qū)η度胧杰浖贸绦蚴怯杏绊懙?。雖然減少每個數(shù)據(jù)包的數(shù)據(jù)字節(jié)數(shù)也可以降低開銷，但每個數(shù)據(jù)包的數(shù)據(jù)字節(jié)數(shù)翻一倍達到128時，周期數(shù)僅有少量增加，相同實驗得到的周期數(shù)為8362。

周期數(shù)和占用空間也解釋了先前討論的權衡——緩存數(shù)據(jù)包數(shù)據(jù)而不是每次都寫入閃存。使能緩存一頁閃存后，每個數(shù)據(jù)包的開銷從7409減少到5904個周期。此20%減幅來自于更新過程跳過了大多數(shù)數(shù)據(jù)包的閃存寫入，僅在緩存已滿時才執(zhí)行閃存寫入。其代價是SRAM占用面積增加。不使用緩存時，HAL只需要336個字節(jié)的SRAM，如圖12所示。但是，當使用緩存時，必須保留一個相當于閃存一整頁的空間，故SRAM占用增加到2388字節(jié)。HAL使用的閃存也會少量增加，原因是需要額外代碼來判斷緩存何時必須清空。

ADI網(wǎng)站再度更新升級

不點“在看”不準走