許多嵌入式系統部署在操作人員難以、或無法接近的地方。物聯網(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個位元組的位址。

主要挑戰

基於對OTA更新過程的這種高層次描述，OTA更新解決方案必須因應三大挑戰。第一個挑戰與記憶體有關，軟體解決方案必須將新軟體應用程式組織到用戶端元件的揮發性或非揮發性記憶體中，以便在更新過程完成時可以執行它。解決方案必須確保將前一版本的軟體保留為後備應用程式，以防新軟體出現問題。此外，當復位和斷電重啟時，必須讓用戶端元件的狀態——例如當前運行的軟體版本，以及它在記憶體中的位置——保持不變。第二大挑戰是通訊，新軟體必須以離散資料封包的形式從伺服器發送到用戶端，每個資料封包都要放在用戶端記憶體中的特定位址，分包方案、資料封包結構和資料傳輸協定必須在軟體設計中考慮周全。最後一個主要挑戰是安全性，當新軟體以無線方式從伺服器發送到用戶端時，必須確保伺服器是可信任方，這種安全挑戰稱為身份驗證。我們還必須對新軟體進行模糊處理以防觀察者偷窺，因為其中可能包含敏感資訊，這種安全挑戰稱為保密。安全性的最後一個要素是完整性，即確保新軟體在通過無線方式發送時不會損壞。

圖2 軟體應用程式的二進位轉換和分包過程。

瞭解引導序列

主引導載入程式(SSBL)是一種軟體應用程式，永久駐留在微控制器的唯讀記憶體中。主SSBL所在的儲存區域稱為資訊空間，有時使用者無法存取，每次重設都會執行該應用程式，一般完成一些必要的硬體初始化，並且可能將使用者軟體載入到記憶體中。但是，如果微控制器包含片內非揮發性記憶體(如快閃記憶體)，則SSBL不需要進行任何載入，只需將控制權轉移到快閃記憶體中的程式即可。如果主SSBL不支援OTA更新，則必須有第二階段SSBL。與主SSBL一樣，SSBL會在每次復位時運行，但將實施OTA更新過程的一部分。此引導序列如圖3所示。本節將說明為什麼需要第二階段SSBL，並解釋如何指定此應用程式的作用是一個重要設計權衡。

圖3 使用SSBL的記憶體映射和引導流程示例。

經驗教訓：務必有一個SSBL

從概念上講，省略SSBL並將所有OTA更新功能放入使用者應用程式似乎更簡單，因為若是如此，OTA過程可以無縫利用現有的軟體框架、作業系統和設備驅動程式。圖4顯示了一個選擇此方法的系統的記憶體映射和引導序列。

圖4 沒有SSBL的記憶體映射和引導流程示例。

應用程式A是部署在現場微控制器上的原始應用程式。此應用套裝程式含OTA更新相關軟體，當伺服器請求時，利用該軟體可下載應用程式B，下載完成且應用程式B經過驗證之後，應用程式A將對應用程式B的重設處理常式執行分支指令，以將控制權轉移給應用程式B。重設處理常式是一小段程式碼，用作軟體應用程式的入口點，並在復位時運行。在這種情況下，重設是透過執行一個分支來類比，這相當於函式呼叫。這種方法有兩大問題：

˙許多嵌入式軟體應用程式採用即時作業系統(RTOS)，其允許將軟體拆分為多個併發任務，每個任務在系統中具有不同的職責。例如，圖1所示的應用程式可能有用於讀取感測器的RTOS任務，對感測器資料運作某種演算法的RTOS任務，以及與無線電介面的RTOS任務。RTOS本身始終處於活動狀態，負責根據非同步事件或特定的基於時間的延遲切換這些任務。因此，從RTOS任務分支到新程式是不安全的，因為其他任務會在後台繼續運行。對於RTOS，終止某個程式的唯一安全方法是透過復位；

˙基於圖4，上述問題的解決辦法是讓主SSBL分支到應用程式B而不是應用程式A。但在某些微控制器上，主SSBL總是運行具有中斷向量表(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顯示了OTA更新過程中的第二種方案——部分快取記憶體，來自圖3和圖4的應用程式A所對應的快閃記憶體部分被放大，並且顯示了用於SSBL的SRAM的功能記憶體映射。示例快閃記憶體頁面大小為2KB。最終，此設計決策將取決於新應用程式的大小和OTA更新軟體容許的複雜度。

圖5 使用SRAM快取記憶體快閃記憶體的一頁。

設計權衡：軟體與協定

OTA更新解決方案還必須解決安全和通訊問題。如圖1所示，許多系統會在硬體和軟體中實現通訊協定，以支援系統的普通(非OTA更新相關)操作，例如交換感測器資料，這意味著伺服器和用戶端之間已經建立了(可能是安全的)無線通訊的方法。類似圖1所示的嵌入式系統可以使用的通訊協定有低功耗藍牙(BLE)或6LoWPAN等。有時候，這些協定支援安全性和資料交換，OTA更新軟體在OTA更新過程中可以利用。

OTA更新軟體中必須構建的通訊功能量最終將取決於現有通訊協議提供的抽象程度。現有通訊協議具有用於在伺服器和用戶端之間發送和接收檔的工具，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)的摘要，用戶端驗證第一個資料封包中的簽名並快取記憶體摘要H0以供以後使用。當第二個資料封包到達時，用戶端對有效載荷進行雜湊處理並將其與H0進行比較，如果它們匹配，用戶端便可確定該後續資料封包來自可信伺服器，而無需費力進行簽名檢查。生成此鏈的高開銷任務留給伺服器完成，用戶端只需在每個資料封包到達時進行快取記憶體和雜湊處理，確保到達的資料封包完整無損並驗明正身。

圖8 將雜湊鏈應用於資料封包序列。

實驗設置

解決本文所述記憶體、通訊和安全設計挑戰的超低功耗微控制器是ADuCM3029和ADuCM4050。這些微控制器包含本文討論的用於OTA更新的硬體周邊，例如快閃記憶體、SRAM、加密加速器和真亂數發生器，這些微控制器的元件系列包(DFP)為在這些元件上構建OTA更新解決方案提供了軟體支援，DFP包含周邊驅動，以便為使用硬體提供簡單靈活的介面。

硬體設定

為了驗證本文討論的概念，利用ADuCM4050創建了OTA更新軟體參考設計。對於用戶端，一個ADuCM4050 EZ-KIT使用收發器子板馬蹄形連接器連接到ADF7242。用戶端元件如圖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所示，整個應用程式使用大約15KB的快閃記憶體。鑒於ADuCM4050包含512KB快閃記憶體，此佔用空間非常小，真正的應用軟體(為OTA更新過程開發的軟體)僅需1.5KB左右，其餘用於庫，例如DFP、Micro-ECC和ADF7242堆疊。這些結果有助於說明SSBL應在系統中扮演什麼角色的設計權衡。15KB佔用空間的大部分是用於更新過程，SSBL本身僅佔用大約500位元組的空間，另外還有1~2KB的DFP程式碼，用於訪問快閃記憶體驅動器之類的元件。

圖11 快閃記憶體佔用空間(位元組)。

圖12 SRAM佔用空間(位元組)。

為了評估軟體的開銷，在每次接收資料封包時計數週期，然後計算每個資料封包平均消耗的週期數。每個資料封包都需要AES-128解密、SHA-256雜湊處理、快閃記憶體寫入和某種資料封包中繼資料驗證。資料封包有效載荷為64位元組且不用快取記憶體時，處理單個資料封包的開銷為7,09個週期；使用26MHz核心時脈時，大約需要285微秒的處理時間。該值是利用ADuCM4050 DFP中的週期計數驅動程式計算(未調整週期數)，並且是100KB二進位檔案下載期間(約1,500個數據封包)的平均值。為使每個資料封包的開銷最小，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更新軟體解決方案時遇到的常見問題和權衡。

參考文獻

Nilsson、Dennis Kengo和Ulf E. Larson。“智慧車輛的無線安全韌體更新”。ICC研討會——2008年IEEE國際通訊會議，2008年5月。

活動簡介

未來寬能隙半導體元件會在哪些應用成為主流？元件供應商又會開發出哪些新的應用寬能隙元件的電路架構，以協助電力系統開發商進一步簡化設計複雜度、提升系統整體效率？TechTaipei「寬能隙元件市場與技術發展研討會」將邀請寬能隙半導體的關鍵供應商一一為與會者解惑。

贊助廠商

立即報名